사실 최근 9월 말부터 10월까지 군 장병 SW 해커톤에 참여하면서 해당 프로젝트에 시간을 거의 대부분 투자했다. 그래서 블로그 활동 간격이 꽤 벌어졌다.
또 해커톤 마감 바로 다음 날 코로나에 확진되어 일주일을 격리하고 왔기 때문에 컴퓨터를 사용할 수 없어 커밋도 일주일이 비어있는 상태이다...
그래도 이제 프로젝트도 마무리되었고, 프로젝트를 통해서 배운 것들이 많이 있기 때문에 지금부터 하나씩 정리해보려고 한다!!
WILIM 의 시작
원래도 공군에 있는 내 친구와 함께 프로젝트를 하나 같이 하고자 하는 생각이 있었다. 때마침 시기 좋게 군 장병 해커톤 지원자를 모집했고, 친구에게 바로 말해서 같이 지원을 하게 되었다.
군 장병 해커톤 같은 경우 분야별(Web, Android, IOT, Cloud) 기본 이론 강의들을 국방오픈소스아카데미에서 수강하도록 하여 지원자 간에 지식 간격을 줄이고, 해당 강의에 대한 이론 평가 -> 코딩 테스트의 순서로 지원자를 선별한다.
분야는 나와 내 친구 모두 Web을 선택하였고, 강의의 경우 JS의 기본 문법과 프론트는 React, 백엔드는 Node 기본 정도를 학습한다. 또한 git 관련 강의가 있어 기본 지식을 다지기에는 나쁘지 않은 수준이라고 생각했다.
JS나 React, Node의 경우 생각보다 강의 구성이 좋게 되어있어 처음 기술을 접하는 사람들도 입문하기 좋은 정도의 강의였던 것 같다. React 강의 같은 경우 Web 필수 강의 이외에도 강의가 하나 더 있는데 TS나 Redux, React Memo같이 React의 응용에 필요한 것들에 대한 맛보기 강의들이 제공되니 이것 또한 볼만한 것 같다. 물론 맛보기이니 제대로 하려면 관련 자료들을 직접 찾아보자.
어찌어찌 이론 강의를 다 수강하고 나면 이론 평가가 진행되는데, 강의를 잘 들었고 내용을 숙지했다면 문제없이 풀 정도의 기본 내용들이 주어진다. 물론 구글링을 통해 공식문서를 찾아보는 것도 상관이 없으니 만점을 받을 수 있도록 하자. 지원자 선별 과정에서 이론평가는 다들 만점을 받아오는 것 같았다. 참고로 4지선다 40문제가 출제되었다!
이후 코딩 테스트는 4문제가 출제되었는데, 프로그래머스와 협력해서 제대로 된 코딩 테스트를 치렀다. 프로그래머스에서 문제를 풀어야하며, 한 문제 정도는 괜찮은 수준, 다른 한 문제는 그보다 조금 어렵게, 나머지 두 문제는 많이 어려운 수준으로 출제되었다. 첫 문제는 그리디 알고리즘 문제였고, 두 번째 문제는 구현 문제였는데 케이스 분리가 매우 까다로웠던 것으로 기억한다. 예외처리를 제대로 해주지 못해 요 문제에서 50점만 받았다(문제 당 100점 총 400점). 나머지 두 문제는 시간 상 건드리지도 못했는데, 일단 보자마자 생각을 많이 요구하는 문제인 것으로 봐서 백준 골드 2~1 이상의 난이도였던 것 같다.
결과적으로 150/400이라는 처참한 점수를 받고 나서...진짜 CS 공부 좀 해야겠다고 생각했다. 근데 나중에 성적을 보니 선별된 200명 중에서 60등 정도여서...조금 위안이 되었을지도...? 역시 군대가 사람을 바보로 만드는게 맞았다.
결과적으로는 나와 친구 모두 합격하여 해커톤에 참가하게 되었다! 처음에 팀 빌딩을 하는 과정이 있기 때문에 친구와 미리 주제를 정하고 팀을 얼추 꾸릴 수 있다는 장점이 있어 이 글을 보게되는 지원자들이 있다면 주변 지인과 함께하는 것을 권한다.
주제 선정 및 기획
주제 선정은 내 친구와 둘이서 군 장병들에게 도움이 될 수 있는 서비스를 떠올려보고, 브레인스토밍한 주제들을 각자 얘기해보면서 개발 난이도나 평가 기준등을 고려하며 선정했다. 이런저런 주제들이 있었지만, 결과적으로는 군 장병 자기계발 도우미 서비스(What I learned in military) 줄여서 WILIM으로 최종 결정을 하게 되었다.
컨셉은 이곳 저곳에 흩어져 있는 자기계발 관련 정보들을 수집하고 가공하여 사용자가 이용하기 좋은 형태로 제공해주는 것이다. 그래서 유저가 자신의 목표를 설정하면 해당 목표를 키워드로 하여 웹에서 정보를 수집하고, 수집된 정보를 유저에게 가공하여 보여주는 것이 메인 서비스가 되었다. 추가적으로는 커뮤니티 게시판이나, 일일 플래너 등을 제공하고자 하였다.
기능적인 측면에서 기획을 얼추 마친 뒤에는, Notion에는 API 라우터를 작성하여 백엔드에서 어떻게 API를 제작할지 미리 틀을 짜두었다.
다음은 제출된 프로젝트 리드미에 있는 API 명세 관련 내용이다.
📙API 명세
WILIM의 백엔드 API 는 크게 총 4가지로,
로그인/회원가입 및 유저에 관한 전반적인 정보를 다루는 /userSchemaAPI,
유저의 플랜 수립과 관련된 정보를 다루는 /userPersonalPlanAPI,
유저의 목표 및 자격증정보를 다루는 /userGoalElementAPI,
커뮤니티 CRUD와 관련된 /communityAPI 로 나누어져 있습니다.
-
/userSchemaAPI 세부 라우팅 리스트
- / - DB 에 있는 모든 유저를 Return.
- /register/local - local 회원가입
- /login/local - local 로그인
- /register/kakao - kakao 로그인 후 db에 없는 유저일때 회원가입
- /login/kakao - kakao 로그인 라우터
- /login/kakao/callback - kakao 로그인 콜백 라우터
- /register/naver - naver 로그인 후 db에 없는 유저일때 회원가입
- /login/naver - naver 로그인 라우터
- /login/naver/callback - naver 로그인 콜백 라우터
- /loginerror - 로그인 에러 발생시 넘어가는 페이지
- /id/:id
- GET - id 을 파라매터로 받아 db에서 찾아 해당 유저 정보 return
- PUT - 해당 유저 수정
- DELETE - 해당 유저 삭제- **/session** - 로그인된 세션이 있을시 그 유저정보를 보여주는 페이지 - **/resetPassword** - 임시 패스워드 생성 라우터 -
/userPersonalPlanAPI 세부 라우팅 리스트
- **/:username/plans** - - GET - 유저의 전체 Plan List 가져오기 - POST - 새로운 Plan Element 추가 - **/:username/plans/:id** - - GET - :id에 해당하는 Plan Element 가져오기 - PUT - :id에 해당하는 Plan Element의 내용 수정 - DELETE - 해당 Plan Element 삭제 -
/userGoalElementAPI 세부 라우팅 리스트
- **/ctfInfo** - - GET - 모든 자격증 정보 가져오기 - POST - 새로운 자격증 정보 생성하기 - **/ctfInfo/:id** - - GET - :id에 해당하는 GoalElemnt 가져오기 - PUT - :id에 해당하는 GoalElement의 내용 수정 - DELETE - 해당 GoalElement 삭제 - **/goal/:username** - - GET - 유저의 목표 가져오기 - POST - 기존 GOAL 있으면 삭제하고 새로운 GOAL 생성 - DELETE - 해당 GOAL 삭제 -
/communityAPI 세부 라우팅 리스트
- **/post/:id** - - GET - 해당 id의 포스트 가져오기 - PUT - 해당 id의 포스트 내용 업데이트(단, 작성자가 로그인한 경우만 허용) - DELETE - 해당 id의 포스트 삭제(단, 작성자가 로그인한 경우만 허용) - **/user/:username/posts** - - GET - 해당하는 user의 포스트 가져오기 - POST - 새로운 포스트 생성 - **/comments/:id** - - GET - 해당 id의 댓글 가져오기 - PUT - 해당 id의 댓글 수정하기(단, 작성자가 로그인한 경우만 허용) - DELETE - 해당 id의 댓글 삭제(단, 작성자가 로그인한 경우만 허용) - **/post/:id/comments** - - POST - 해당 id의 포스트에 댓글 추가 - (GET 방식은 따로 만들지 않고,포스트를 불러올 때 populate 기능으로 댓글도 같이 불러오는 것으로 대체합니다.)
물론 처음에는 큰 Main API에 대한 줄기들만 작성하고, 나머지 세부 정보는 백엔드 팀원들이 개발을 진행하면서 수정해주었다.
위와 같이 백엔드 API 기획을 마친 뒤에는, Figma를 이용해서 프로토타입을 제작하였다.
아래는 캡쳐본이다.
기존에 디자인 시스템을 제작하는 과정에서 Figma를 사용했었기 때문에, 프로토타입 제작에는 내 디자인 시스템을 끌어왔다(resonance-design-system). 새로 디자인 하기도 쉬운 것이 아니었고, 시간이 많은 것이 아니었기에 빠르게 기획하고자 했다.
프로젝트 본격 시작
이렇게 초기 기획을 마친 뒤에는 본격적으로 Github Repository를 파서 팀원들과 개발 초기 구성을 시작하였다. 나는 프론트엔드 개발과 팀장을 맡았기 때문에, 프론트엔드 아키텍쳐 구성을 어떻게 할지 고민하면서 이런저런 자료들을 많이 찾아보았던 것 같다. 프론트 아키텍쳐에 관련된 글은 따로 작성하려고 하니, 해당 글을 살펴보자!
또한 해커톤 주최측에서 개발환경을 제공해주기는 했지만, 배포를 할 수 있는 환경을 제공해준 것은 아니었고 최종 제출에서도 코드만 제출하라고 하였다. 그러나 나는 배포를 진행해서 실제 서비스와 같이 구성을 해보고 싶었고, QA 테스트도 진행하고픈 마음이 있었기 때문에 배포를 진행할 방법을 여럿 찾았었다.
결과적으로 프론트엔드는 평소 자주 사용하던 Netlify 서비스를 이용했고, 백엔드는 AWS Elastic Beanstalk(이하 EB)을 사용하였다. 군 사이버지식정보방 환경에서 EC2를 사용하지 못하는 것은 아니었지만, 근본적으로 터미널을 열 수 없는 컴퓨터였기 때문에 중간에 문제가 생겨도 제대로 해결하지 못할 것 같았다. 또한 추가적인 설정들을 해주면서 발생하는 문제들에 대한 해결을 진행할 시간이 부족할 것이라고 생각했기에, 백엔드 서버를 자동으로 구축해주는 EB 서비스를 이용하여 문제없이 배포를 진행하였다.
요 배포 관련 내용도 포스트를 하나 추가로 하려고 한다. 혹시 내용이 궁금하면 해당 포스트를 살펴보자...!
최종적인 개발 세팅을 마치고 정해진 주요 스택은 다음과 같다.
Front-end | Typescript, React, Redux(Redux-toolkit)
Back-end | Express, Passport, Mongoose
DB | MongoDB
Infra(DevOps) | AWS Elastic Beanstalk, Github Action
혹시라도 추가적인 내용을 살펴보고 싶다면 아래 리드미 링크를 참고하자!!
프로젝트에 대한 초기 개요는 이정도로 마치고, 이제는 개발을 하면서 겪었던 수많은 문제들에 대한 해결 과정들과 그 과정에서 배운 것들을 천천히 적어보고자 한다!!
