(회고) 크래프톤 정글 0주차 회고록 - 팀프로젝트 진행 과정

0주차 회고록

잠이 안와서 적는 회고록 ...

크래프톤 정글에서의 첫 주차가 끝났다.
사실 1주차라고 해야 맞는 것 같은데, 정글 커리큘럼에서 첫 번째 과제를 맛보기 식으로 선정해서 0주차라고 칭하고 있어서... 0주차라고 해야 할 것 같다.

크래프톤 정글에서 처음 받은 과제는 이거였다.

3박 4일간, 3명의 조원과 함께 HTML Flask MongoDB AWS 사용해서 프로젝트 빌드하기!!

 

조금 당황했던 점이 처음 웹개발 하는 사람들끼리 한 조라고 가정하면 너무 빡센 과제 아닌가 하는 생각이 들었다.
나 국비 다닐 때 이런 과제 받았으면 그냥 포기했을 것 같다.

첫날. 주제 정하기

첫날...
우리 조는 먼저 주제를 정했다.

각자 떠오르는 거 생각해서 말하고, 나온 의견들 중에 추리는 식으로 골랐는데
한 조원 분이 굉장히 좋은 아이디어를 말해주셔서 거기에 꽂혀서 그걸로 하게 됐다.

아이디어는 세탁기 예약 서비스였다. 합숙소 세탁기가 인원수에 비해 적은데, 마땅히 이용 시스템이 없기 때문에... 잘 하면 실생활에서 접목할 수 있을 것 같아서 해당 주제를 선택했다.
그리고 각자 머리를 맞대서 ui를 짜고 그 화면설계서를 그려서 발표 준비를 했다.

둘째날. 개발환경 세팅하기

ui 발표가 끝나고, 약간의 기능을 컷한 뒤 각자 이제 개발을 하자. 싶어서 세팅에 들어갔다.

깃허브 세팅하기

먼저 한 일은 깃허브 레파지토리 파기.
형상관리 시스템으로 git을 고르는 건 그냥 고민의 여지가 없었다.
많은 기업에서도 git 경험을 요구하고,

다른 걸 안써봤고

익숙해지면 엄청 편하니까...

해당 프로젝트를 만들고 Flask 개발환경을 세팅하고 온갖 라이브러리를 install하고 git에 올렸다.
근데 .venv에서 깃에 올라가는 파일이 1k가 넘어가길래...
어라 이거 맞나? 싶어서 찾아보니, git에 .venv 내 파일들을 직접 올리는 것은 충돌 및 에러의 위험이 크다는 말이 있어서 .gitignore를 만들고 .venv 내부의 파일은 제외한 후, pip install 목록들은 requirements.txt에 pip freeze하는 방식으로 버전 관리 방법을 정하게 되었다.
이후 버전을 freeze하는 방식과 git에서 받은 뒤 install하는 방식들은 readme.md로 기록하여 팀 내에서 공유했다.

ui 툴 선택하기 - No Bootstrap, Yes tailwind

그 다음엔 이제 본격적으로 이용할 툴들을 정했는데...
우선 프론트 쪽에서는, tailwind css를 이용했다.
이유는 참 단순하게도... 내가 이 툴을 주변에서 얘기를 많이 들었어서 너무 궁금해서 강력 어필했다...
근데 사실 그렇게 좋은 선택은 아니었던 것 같다.

죄송합니다

tailwind css는 먼저 css 자체에도 빠삭해야 하고, 어느 정도의 클래스명을 외우고 있어야 개발속도가 단축되는 러닝커브 있는 라이브러리였다.
모두가 이 라이브러리를 처음 써보는 데다가 3일 내에 플젝을 완성시켜야 하는 우리의 상황과는 맞지 않았다...
근데 지금 찾아보니까 우리는 그냥 쌩 tailwind css를 이용해서 직접 컴포넌트를 개발하는 식으로 썼는데, 부트스트랩 식으로 이용할 수 있는 tailwind ui라는 게 있는 것 같다......
앞으로는 라이브러리를 쓰고 싶다고 말하기 전에 기본적인 조사를 하고 들어가야겠다는 깨달음을 얻었다.....

그리고 우리는 부트스트랩을 쓰지 않았다. 그냥 tailwind를 사용하기로 정했으니 별도로 깔지 않았고 필요성도 못 느껴서 이용하지 않았는데, 부트스트랩과 테일윈드가 혼용 가능한지는 잘 모르겠다.
부트스트랩을 쓰지 않게 되어서 ajax를 못 쓰게 된 이슈가 있었는데, 팀원 한 분이 js의 fetch api를 알려주셔서 이를 활용하여 서버와의 연결을 구현하게 되었다.

공통 소통 페이지 생성하기 - Notion

그리고 팀원분이 팀 스페이스를 하나 파셔서 해당 프로젝트를 위한 노션 공유 페이지를 하나 파게 되었다.

프로젝트 중 공용 소통페이지는 정말 필요한 것 같다. 여러 회의 내역과 이슈 사항과 공유해야 하는 문서 파일 등등을 올릴 수 있는 창구가 필요했고... 노션은 괜찮은 툴인 것 같다.

DB 테이블 정의서 만들기

다음으로 프로젝트에서 사용할 MongoDB의 컬렉션 이름과 각 필드명, 필드에 들어갈 type, enum값 등등을 정의한 문서를 조원들끼리 만들어 노션에 공유했다.

테이블 정의서를 만드는 이유는... 각자 기능 개발을 할 때 필드명을 제멋대로 짓는 불상사를 방지하기 위해서, 그리고 한쪽은 string으로 개발하고 한쪽은 int로 개발해서 나중에 합치면 에러 나는 참사를 방지하기 위해서이다.
무엇보다 해당 정보들을 논의하면서 합의해 두는 시간이 필요하다.

MongoDB는 dynamic type을 표방하고 있지만, 타입체킹 로직을 일일이 달 게 아니라면 type를 정해 두는 게 여러모로 편한 것 같다.

컬렉션은 단 두개가 끝이다.
우리의 작은 테이블 정의서...
개발하면서 엄청 많이 들여다봤다.
진짜 테이블 정의서는 필수라고 생각한다.

API 문서 만들기

쿠팡 개발자 페이지의 API 문서 형식을 참고해서 api 문서를 만들었다.

대충 api 요청마다 이런 식으로 실행되는 순간, http method, path, request 파라미터, response가 있을 경우 response data 등을 정리해서 문서화해 노션에 공유했다.

지금 보니까 세팅 과정이 되게 길었구나 싶은데...
팀플 시 문서화는 많을수록 좋다고 본다...
문서화하는 과정에서 데이터 타입이나 api 요청경로 등을 미리 논의하고 합의를 봤기 때문에, 개발하면서 서로의 설계가 어긋나는 일이 없었고 수월하게 진행할 수 있었다.

나머지 시간... 개발하기

나머지 시간 중에는 기능을 나눠서 개발했다.
개발을 프론트/백 이렇게 영역별로 나눌지, 로그인/예약하기 이렇게 기능별로 나눌지 긴 논의를 했었는데, 기능별로 나눠서 하는 쪽으로 뜻이 모아졌다.

영역별로 나누면 맡지 않은 분야의 프레임워크는 익히지 않아도 된다는 점에서 러닝커브를 줄일 수 있다는 장점은 있지만, 백엔드 쪽 로직을 맡을 경우 프론트가 완성되기 전까진 테스팅이 어렵다는 애로사항이 있다.
postman 같은 API 테스트 툴을 사용하면 해결할 수도 있는 문제겠지만 사용해본 적이 없기에 그 툴을 익히는 데 또 시간이 걸릴 상황이었다.
여러 가지로 복잡해서 그냥 기능별로 나눠서 개발하기로 합의를 보았다.

완성!

그렇게 해서 완성된 우리의 프로젝트.
http://jglaundry.shop/

너무 뿌듯하다...ㅋㅋㅋㅋㅋㅋ
기능이 많은 것은 아니고 ui가 다소 투박한 감은 있지만, 서비스가 터지지 않고 안정성 있게 운영되는 것에 초점을 두었다.
저 단순한 기능에서 얼마나 많은 오류가 파생되었고... ... 그것들을 고치는 과정을 거쳤는지 ... ...

되게 많은 일이 있었는데 막상 기록하려니까 기억이 잘 안 난다. 이슈 로그를 하나 작성할 걸 그랬나 싶다.
다음에 개발할 땐 하나 만들어봐야겠다.

짧은 시간이었지만 알차게 개발했고, 많은 걸 배울 수 있는 시간이었다.
grid ui 숙련도도 높이고... tailwind도 써보고... 파이썬도 엉금엉금 익히고... jinja2도 써보고...
무엇보다 팀원 분들이 되게 잘 맞았다. 팀플경험이 많지는 않지만, 경험했던 팀워크 중에 가장 이상적으로 잘 진행된 팀플이었다.
각자 잘하는 부분이 달라서 서로 부족한 부분을 채워줄 수 있었던 느낌...

0주차 시작이 좋은 것 같다. 이제 1주차를 맞이하러 자야겠다...