Codemap 프로젝트 (소프트웨어 마에스트로 13기) - 개요

현재 소프트웨어 마에스트로에서 13기 연수생으로 활동 중이다.

 

나는 두 명의 고수들과 함께 프로젝트를 진행하고 있다.

소프트웨어 마에스트로에서는 팀원끼리 자유롭게 팀을 꾸려서 자유주제를 정해 약 6개월간 프로젝트를 진행하는데, 나는 내가 팀원을 직접 모았다. 

 

처음에는 코딩테스트 대비를 위한 모의고사 전용 플랫폼이 부족하다고 느껴서 해당 주제로 타겟을 잡고 알고리즘 고수들을 영입했다. (두명 다 다이아에 코포 퍼플)

그러나 여러 멘토님들과 기획에 대한 멘토링을 진행하면서 현재 존재하는 여러 플랫폼들(백준, 프로그래머스, 코드트리 등)을 이길 수 있는 차별성이 부족했다.

 

따라서 코딩테스트 모의고사 플랫폼은 잠깐 접어두고 올림피아드나 ICPC같은 프로그래밍 대회를 준비하기 위한 플랫폼으로 노선을 바꿨다. 

현재 존재하는 많은 플랫폼들은 코딩테스트를 대비하기 위함으로 초점이 맞추어져 있다. 따라서 코딩테스트에 나오는 알고리즘들만을 공부할 수 있다. (제일 어려운게 세그먼트 트리정도?)

그러나 올림피아드나 ICPC같은 전문 PS 대회에선 훨씬 어려운 그 이상의 알고리즘들이 등장한다. 이를 대비하기 위한 플랫폼은 현재로썬 백준밖에 없는데, 백준은 무슨 알고리즘부터 학습해야 할지 감이 잘 안잡힌다.

 

따라서 프로그래밍 대회를 준비하기 위한 로드맵이 갖춰진 플랫폼이 있다면 경쟁력이 있을 것이라고 생각했고 이 주제를 선택했다. 이름은 코드맵이다.

 

우리의 플랫폼은 기초부터 심화 알고리즘 까지 알고리즘 학습자료들을 제공하고 기출 문제(KOI, ICPC 등)등을 가져와 사용자가 시험을 보는 것처럼 모의고사 기능을 제공할 계획이다.

 

요즘 프로그래머스에서 코딩테스트 대비 모의고사를 실시하고 있다. 주제 그대로 했으면 큰일날뻔 ㅠ

 

ROLE

---

지난 4년간 대학을 다니며 팀 프로젝트를 하면서 느낀건데 역할 나누는게 제일 어렵고 중요하다.

특히 개발 프로젝트는 여러명의 코드가 섞이면 대참사가 발생하기 때문에 공용으로 사용할 수 있는 문서의 중요성이 극대화되고, git같은 협업 툴의 사용성도 높아져야 한다.

 

우리는 크게 프론트와 백으로 나누었다.

프론트는 한 명이 전담하고, 나와 다른 팀원은 백엔드를 맡았는데 서버개발을 한번도 해보지 않은 나와 나의 팀원은 일단 공부가 필요했다. 

 

지난 예비 프로젝트에서는 서버를 node.js로 구축해보았고, 쉽고 좋아서 이거를 쓰려고 했다.

그런데 개발 전 멘토링을 하며 생각이 바뀌었다. 한 멘토님이 어차피 다들 노력하고 시간도 많은데 좀더 어렵고 실무에서 많이 쓰이는 Spring을 공부해보는게 좋을 것 같다고 조언해주셨다.

생각해보니 내가 예비 프로젝트에서 Spring을 선택하지 않고 node.js를 선택한 건 배우기 쉬워서가 다였다. 

그래서 이왕 공부해보는거 더 어려운거 해보자! 라는 마음으로 팀원과 상의 후에 프레임워크를 Spring으로 채택했다.

 

소프트웨어 마에스트로에서는 인프런 강의를 최대 96만원까지 지원해준다. 

https://www.inflearn.com/

인프런 - 미래의 동료들과 함께 성장하는 곳 | IT 정보 플랫폼

이거 하기전에는 몰랐는데 진짜 좋은 강의 사이트다. 

 

여기서 김영한님의 Spring 강의를 들었다. 아직도 다 듣지는 못했는데 현재 개발이 어느정도 완료된 상태라 손이 잘 가지 않는다.. 들어야 하는데..

 

 

Server

---

우선 우리는 PS대비를 위한 플랫폼이고 모의고사를 지원하기 때문에 백준이나 프로그래머스 처럼 웹 IDE를 이용해 코드를 제출해보고 테스트할 수 있어야 한다. 따라서 채점서버가 필요했다.

 

채점서버를 메인서버 밑에 둘지 따로 놓을지 선택을 해야 했는데 아무래도 따로 놔야 관리도 편하고 메인 서버의 부담도 덜수 있다고 판단해서 따로 놓기로 했다.

 

소프트웨어 마에스트로에서는 일정 금액 안에서 AWS를 사용할 수 있도록 지원해주기 때문에  EC2  두개정도 사는건 나쁘지 않은 선택이었다.

 

사용자가 어떤 코드를 넣을지 모르기 때문에 독립적으로 안전하게 코드를 컴파일 할 수 있는 환경이 필요했다.

이를 샌드박스라고 하는데, 팀원이 찾아온 국제 올림피아드에서 사용하는 샌드박스 오픈소스를 사용했다.

https://github.com/ioi/isolate

GitHub - ioi/isolate: Sandbox for securely executing untrusted programs

참 잘만들어 놓았다. 역시 IOI

이 isolate는 사용한 메모리, 시간 등 여러 메타 정보들을 반환해주고 심지어 런타임 에러, 컴파일 에러, 시간초과 등 채점서버에 필요한 결과를 모두 지원해준다.

 

샌드박스는 가져왔으니 이제 사용자가 제출한 코드를 처리해서 서버가 원하는 형식대로 반환해줄 채점서버의 기능이 필요했다. 

처음에는 각자 짜보기로 했는데 나는 빠르게 C++로 짜봤다. 돌아가긴 하지만 메인서버가 Java이다 보니 아무래도 Java로 짜는 것이 호환성 측면에서 좋을 것 같았고, 가독성이 너무 안좋아서 일단 보류했다. 

 

같이 서버를 구현하는 팀원이 Java로 짜보고 잘 안되면 내가 짠걸로 쓰고 좋으면 팀원이 짠걸로 하기로 했는데 1주일 정도 뒤에 팀원이 너무 잘 구현해왔다. 천재인듯!

 

따라서 내껀 버리기로 했다.

 

메인서버가 채점서버로 채점정보를 넘겨줄 때 무작정 넘겨주면 채점서버의 오버헤드를 감당하지 못할 수 도 있다. 때문에 중간에 Queue가 필요했다. 내가 짤때는 그냥 한 프로세스 안에 큐를 하나 구현해서 거기서 처리를 했는데 역시 비상한 우리 팀원은 Rabbit MQ같은 미들 큐를 사용했다. 

현재는 로컬 MQ가 아닌 AWS에 큐를 올려서 사용하고 있다.

 

현재 구조는 프론트에서 메인서버로 채점 정보를 POST로 넘겨주면 메인서버는 해당 정보를 Queue로 넘겨준다. Queue를 바라보고 있는 채점서버는 해당 정보를 받아 isolate시켜서 실행해본 뒤 실행 결과를 다시 POST로 메인서버로 전송한다.

해당 채점 결과를 받은 메인서버는 처음 프론트에서 받은 정보와 채점서버로부터 받은 정보를 잘 짬뽕시켜 DB에 저장한다.

 

이때 프론트에서 메인서버로 채점정보를 넘겼을 때 채점이 끝났는지 진행중인지를 판별해 유저에게 보여줄 필요가 있다. (기다리고 있는지 채점 중인지 채점이 완료되었는지) 이를 구현하기 위해서는 크게 두가지 방법이 있다.

 

1. 프론트에서 무지성으로 while 돌려서 기다린다.

2. 프론트와 메인서버의 적절한 통신을 하나 이용한다.

 

누가봐도 2번이 좋아보인다. 그래서 웹소켓을 사용하기로 했다. 그냥 소켓프로그래밍만 해봤지 웹소켓은 처음듣는 개념이었다. 이 역시 팀원이 알려주었다. 웹소켓을 공부하고 바로 다음날 구현에 성공했다.

현재는 잘 작동한다.

 

팀원이 채점서버를 구현하는 1주일 동안 나는 메인서버의 기초 틀을 만들었다.

 

인프런에서 김영한님의 강의를 들으며 MVC 패턴을 배웠고 최대한 그 틀에 맞게 짰는데, 사실 우리 프로젝트는 프론트 전담이 따로 있기 때문에 View영역은 중요하지 않았다.

 

그래서 Rest API 서버를 구현하기로 했다. 팀원들과 함께 API문서를 만들고 DB를 구축했다.

DB는 내가 많이 써본 MySQL을 사용했다. 다른 것도 사용해볼까 생각했지만 Spring도 처음배우고 있는데 DB까지 처음쓰는 걸로 하면 대참사가 날 것 같았다.

 

우리는 공용문서를 노션으로 관리하고 있는데 API도 이 문서에 있다.

더 있지만 대충 이런식으로 정리했다. 

 

처음에는 로그인을 구현하지 않고 나머지 기능들을 완성했다. 아무래도 로그인부터 처리를 하면 나중에 뭐 건들때마다 로그인해서 인증받고 해야할 것 같아서 귀찮을 것 같았다.

 

DB에 접근하기 위해서 ORM을 사용했는데 김영한님의 강의를 보며 Data JPA를 사용했다. 진짜 너무 편했다. 실제 쿼리를작성한게 3~4개 정도밖에 되지 않을 정도로 Data JPA는 거의 대부분을 지원해줘서 좋았다.

 

우리는 거의 2주정도에 80퍼센트를 완료할 정도로 개발 속도가 좀 빠른편에 속했는데 가장 큰 덕은 IntelliJ이고 두번째가 이 DataJPA인 것 같다.

 

옆에 보이는 필요 불필요는 로그인을 할 때 JWT 인증에 필요한 토큰의 필요성이다. 

JWT또한 몰랐던 부분이지만 팀원이 알려주었고 인프런을 통해 학습했다.

 

협업

---

소프트웨어 마에스트로 에서는 깃랩을 지원해준다. 

깃헙과 별로 차이는 없지만 CI/CD구성이라든지 이슈처리라든지 여러 부분에 있어서 협업에 강점이 있는 툴이다.

 

깃랩은 학교에서 진행하던 OAI 오픈소스 프로젝트에서 OAI가 오픈소스를 깃랩으로 관리했는데 해당 소스에 접근하려면 OAI에게 승인을 받아야해서 메일을 보냈던 기억이 난다. 는 너무 TMI이고 어쨌든 코드를 가져다 쓰는 정도로만 써봤다.

 

깃랩 CI/CD 구성, 그리고 깃헙의 여러 커맨드들은 멘토링을 통해 배웠다. 

 

현재 우리 프로젝트의 깃랩은 크게 세가지 레퍼지토리로 구성이 되어있다.

협업에서 깃랩은 처음써봤는데 좋은 기능도 많고 배울 것도 많다.

 

파이프라인은 팀원이 구축해놓았는데 빌드-배포 두개의 스테이지로만 되어있다.

 

현재 진행 상황

---

나는 메인서버를 구현하고 있고, 메인서버로만 따지면 80퍼센트 이상은 구현이 끝났다.

모든 API에 대한 처리는 끝난 상태이고 로그인에 대한 처리도 다 했다. (비밀번호 찾기 등) 남은건 부가적인 기능들 (모의고사 페널티 계산, 알고리즘 추천 등)인데 아마 중간평가(8월 말)이후에 구현할 것 같다.

 

지난 3주정도간의 빡센 구현을 끝내고 현재는 잠깐 쉬며 다가올 중간평가를 준비하고 있다.

 

중간평가 이후, 프론트가 거의 완성된 이후에 다시 글을 쓰도록 하겠다.

 

커밍순!