Elice AI트랙 1차 프로젝트 (밈팔이닷컴) 회고

이번 글에서는 1월 30일부터 2월 10일까지 약 2주 조금 안되는 시간동안 진행하였던 Elice AI 트랙의 1차 프로젝트에 대해서 시간 순서대로 회고를 해보고자합니다.

0. 팀 결정

팀 결정 자체는 1월 20일에 결정되었습니다. 6인 팀으로 결정이 되었는데, 1명은 저와 같이 백엔드 스터디를 하던 분이었고, 나머지 4명은 부트캠프를 하면서 한번도 말도 안 섞어보았던 사람들과 팀이 결성되었습니다.

 

우선 팀으로 결정된 사람들과 먼저 친해지는 것이 중요하다고 생각하였기 때문에 팀이 결정되자마자 서로 인사를 해보는 시간을 가졌던 것으로 기억합니다! 그렇게 설날을 쉬고 조금의 회복 기간을 가지다가 1월 30일에 본격적으로 프로젝트를 시작하게됩니다.

1. 프로젝트 시작

1월 30일에 본격적으로 1차 프로젝트를 시작하였습니다. 프로젝트를 시작하기 이전에 각자의 개발 경험을 공유하며 각자 어떤 포지션을 가져갈지 결정을 하였습니다.

 

저희 팀원들은 개발 경험이 1도 없는 비전공자 출신들이었으며, 저희 팀 중에서 유일하게 저만 전공자였으며 백엔드 개발 경험이 거의 1년 정도 있는 상황이었습니다.

 

따라서 어떻게 포지션을 나눌지 결정한 결과, 팀 구성을 팀장 1명, 백엔드 리더 1명, 프론트 리더 1명을 두기로 결정합니다. 그리고 팀 포지션을 분배한 결과 저희 5지는팀 의 포지션 분배는 아래와 같이 되었습니다.

• 팀장: 김도엽(나) -> 팀의 DevOps까지 담당
• 백엔드 리더: 김도엽(나)
• 프론트 리더: 정민님
• 백엔드 총 3명, 프론트 총 3명

그렇게 저는 5지는팀 이라는 배를 모는 선장이 되었습니다. 위의 구성을 하고보니 백엔드의 경우 제가 개발 경험이 1년 정도 있었다보니 1주일 정도면 1차 프로젝트로 요구한 요구사항을 다 구현할 자신이 있었으나, 프론트는 그것을 보장할 수가 없어서 일주일만에 백엔드를 끝내고 어떻게든 남은 기간에 프론트엔드를 도와주자 라는 마인드로 참여를 하였습니다.

2. 기술스택의 선정

기술 스택의 선정은 백엔드 위주로 설명을 해드리겠습니다. 프론트엔드의 경우 엘리스에서 가르쳐준 리액트, CSS, Styled Component가 전부이기 때문입니다.

 

우선 저희 1차 프로젝트의 요구사항 중에서 몇 가지의 요구사항만 인용해서 소개를 해드리겠습니다.

• 카테고리 삭제 - 관리자는 관리자 페이지에서, 상품이 속할 카테고리 관련 데이터를 삭제할 수 있다
• 주문 수정 - 사용자는 주문 완료 후 배송이 시작되기 전까지 주문 정보를 수정할 수 있다

백엔드는 저 혼자 하는것이 아닌, 3명이서 일감을 분배해서 진행을 해야하기 때문에 위의 2가지 요구사항을 보고 고민에 빠지게 됩니다.

카테고리, 주문을 진행하면서 유저의 토큰을 검증하고, 토큰에 대해서 RBAC을 수행해야하는데, 내가 방법을 알려준다한들 이걸 개발경험이 1도 없는 나머지 두 분이 무사히 진행해줄 수 있을까?

따라서 회원 서버와 그 외의 기능들을 수행하는 서버를 분리 구현하여서, 회원 인증/인가에 대해서 나머지 2분에 대해서 블랙박스로 처리하기로 결심을 하게됩니다. 즉, 나머지 2분은 카테고리, 품목, 주문을 구현함에 있어서 사용자 권한 인증/인가에 대해서 신경을 쓰지 않고 코딩을 할수있는 환경을 구성해주기로 생각을 하게 된것입니다.

 

그렇게 결국, 카테고리, 품목, 주문을 다루는 백엔드 서버는 ExpressJS, MongoDB로 구성을 하여 나머지 두 분에게 코딩에 대해서 전반적으로 맡기도록 하는 방향으로 가닥을 잡았고, 저의 경우는 프로젝트 진행 이전에 TypeScript, NestJS를 공부했기 때문에 NestJS로 토이프로젝트를 해보는 겸사로 한번 해보자는 마음으로 TypeScript, NestJS로 회원 서버를 진행하게 되었습니다.

 

그리고 배포의 경우 Docker, Docker-Compose로 하기로 결정하게됩니다. 물론 둘 다 NodeJS 위에서 돌아가는 프레임워크이기 때문에 Docker로 하지않고 PM2를 다이렉트로 써서 배포를 진행해도 상관은 없겠지만, 그래도 둘의 배포 방법은 엄연히 다르기도 한데다가, NestJS는 배포 과정에서 tsc 빌드 과정을 거치기 때문에 그거를 자동화 하기 위해서라도 Docker로 배포하기로 결심하게됩니다. (Dockerfile 적는데 시간이 얼마 안 걸리기도 하고...)

3. 본격적인 백엔드 개발

프로젝트의 컨셉, api 리스트업을 완료한 뒤에 1월 31일부터 본격적으로 시작하게 됩니다.

 

본격적으로 개발을 시작하는 첫 단추는 ExpressJS 뼈대 코드 작성, 즉 아키텍처링 이었습니다. ExpressJS의 아키텍처링은 저희 백엔드 팀의 나머지 두 분에게 전적으로 맡겨드리고 후에 아키텍처링에 대해서 제가 코드리뷰를 해주는 방식으로 진행하였습니다.

 

나머지 두 분은 백엔드 관련해서 개발 경험이 1도 없었기 때문에 제가 이거 3계층 아키텍처로 설계해주세요 했을 때 매우 막막해하였던 모습이 기억이 납니다. 그래서 레퍼런스를 하나 주고, 이거 비슷하게 클론코딩만 하면 아키텍처링 할수있어요! 라고 말을 했습니다.

백설기-레이어드 아키텍처 예시

GitHub - elice-bsg/express-layerd-architecture

그리고 뼈대 코드에서 모자란 부분은 코드리뷰 및 라이브코딩을 진행하며 채워주는 방식으로 진행했습니다.

 

나머지 카테고리, 품목, 주문 백엔드 로직을 짜면서도 나머지 두 분에게 코드 작성을 맡기고, PR시에 코드 리뷰를 하고, 코드 리뷰 이후에 코드를 고쳐서 Dev 브랜치에 Merge를 하는 식으로 백엔드 개발을 진행하였습니다.

4. 1주차 코드리뷰

저희 엘리스 AI트랙은 1주차에 지금까지 작성해온 코드에 대해서 코치님께서 리뷰를 진행해주십니다. 저희는 회원 서버, 그 외의 서버가 분리된 형태였기 때문에 코치님께서 2개의 리포지토리에 대해서 리뷰를 해주시는데, 우선 회원 서버에 대해서 리뷰가 먼저 올라왔습니다.

 

코치님의 코드리뷰. 이 정도면 극찬이지 아니한가?

물품 서버에 대해서는 2주차 첫번째 오피스아워에서 리뷰를 해주셨는데요, 크게 코드 내용으로 지적(?)을 받은건 없으나, ExpressJS또한 결국 나머지 두 분이 코드를 작성하시면 그것을 제가 리뷰하여 PR을 날리다보니 아래의 지적 사항이 나왔습니다.

• 전체 백엔드 팀이 저 혼자에게 잡아먹히는 느낌이 없잖아 있다. 팀원을 조금만 더 믿어달라.
• 결국 프로젝트를 평가하는 사람들은 팀원 전체의 Commit 수도 보기 때문에, MR마다 코드리뷰를 해주는건 좋지만 MR은 나머지 두 팀원이 하도록 해주셨으면 좋겠다.

5. 프론트에서의 SOS

사실상 2주차 월요일까지 백엔드 코딩은 모두 끝이 났습니다. 하지만 프론트엔드의 경우 진척도가 그렇게 많이 나오지 않던 상황인데요, 화요일 즈음에 스크럼을 진행하면서, 그리고 코치님의 오피스아워 시간에 이러한 결론에 도달하였습니다.

백엔드가 거의 마무리 되어간다면, 백엔드 분들은 모두 프론트를 도와드리는게 어떨까요?

그래서 화요일 저녁부터 시작해서 프론트 분들을 도와주는 최선의 방법을 물색하기 시작하였는데요, 제가 선택한 방법은 프론트엔드의 Repository를 백엔드 측에서 모두 작성해줘서 프론트가 백엔드 api를 호출하는걸 간단화 시키는 것이었습니다.

 

그래서 Axios를 이용한 백엔드 API 호출을 Repository 계층을 이용해서 추상화 시킨 다음, 프론트 분들에게 알려주고, 프론트분들이 시간이 부족해서 못하는 뷰와 컴포넌트 부분들을 백엔드 분들이 맡아주는 방법으로 하여 1차 프로젝트를 무사히 마무리 하였습니다.

6. 프로젝트 발표

이제 대망의 프로젝트 발표입니다. 발표자료는 팀원 분들이 다 같이 만들고나서, 발표는 제가 맡게 되었습니다.

이거를 최대한 생동감있게 발표를 해달라길래....매우 난감했다

발표 이후에 QnA 과정에서 간단하게 두 개의 질문만을 다른 코치님께 받았는데요, 제가 받았던 질문은 아래와 같았습니다.

• 혹시 팀에 현업자가 있었나요? 개발 환경이 저랑 많이 비슷하던데...
• 굳이 서버를 NestJS만으로 구성할 수도 있었는데 굳이 왜 ExpressJS랑 병행한 이유가 있으실까요?

두 번째 질문에 대한 답은 제가 위에서 말했던 사항과 어느 정도 통하는데요, 이유는 저희 팀의 백엔드는 저를 제외하고는 Express도 겨우 하던 사람들이었기 때문에 제가 NestJS로 전부 수행을 하게된다면 나머지 두 분들에게 배움의 기회, 코딩의 기회를 앗아가는 나쁜 행동이기 때문이었습니다.

 

모든 개발은 협업으로 이뤄져야만이 최선의 결과를 가져올 수가 있기 때문에, 다른 인원들의 개발 수준을 차차하고서라도, 그리고 제가 모든 코드를 가르쳐주는 한이 있더라도 나머지 서버는 Express로 하는 방향으로 잡았던 이유도 있긴합니다.

7. 프로젝트를 하며 느낀점이 있다면?

사실 이번 팀 프로젝트를 하기 이전에, 다른 분에게 이런 말을 들은적이 있었습니다.

팀에 불화가 안 일어나게 팀장이 이끌어나가는거는, 단순하게 팀장인 너의 실력만 뛰어나서는 절대로 안돼. 팀원을 배려하고, 그리고 팀원의 장점을 최대한 보려하고 칭찬하는 문화를 너가 직접 이끌어나가야만이 팀에 불화가 안 일어나고 최선의 결과를 얻을 수 있지 않을까?

본격적으로 1차 팀 프로젝트를 하기 이전에 이 말을 새겨듣고, 또 새겨들으면서 최대한 서로 짜증, 불만, 불평을 하지 않는 문화. 그리고 남이 못하더라도 절대로 조급하게 굴지않는 문화. 그리고 서로에게 관심을 가지는 문화를 이끌어내려 많이 노력했던 것 같습니다.

 

결론적으로, 저희 팀은 짜증, 불평 그런거는 하나도 없이 오히려 서로에게 사과하는 문화, 지식을 공유하는 문화가 형성되어 매우 화목하게(?) 프로젝트를 끝낼 수 있었던 것 같습니다.

 

제 주변의 많은 분들은, '팀장하면 탈모 온다', '팀장하면 스트레스만 오지게 받을걸?' 이라는 등의 제가 팀장을 맡는것에 대해서 걱정 섞인(?) 조언들을 해주었지만, 저는 오히려 매우 즐거운 팀장 생활을 하였던 것 같습니다.

 

절대로 저 혼자만 잘해서는 팀이 잘 굴러가지는 않습니다. 제가 즐겁게 팀장으로 2주간 활동할 수 있었던데에는 저뿐만이 아닌, 팀원들의 몫이 대부분이었을 것입니다. 제가 팀의 문화를 잘 이끌어간다고 한들, 제가 형성하고자하는 팀의 문화를 받아들일 수 없는 팀원이 존재했다면 말짱 도루묵이었기 때문입니다. 

 

마지막으로, 저와 2주 동안 함께 해주었던 팀원들에게 감사하다는 말을 전하며 글을 마치겠습니다.

8. Repositories

https://github.com/BrianDYKim/memepari-3A

GitHub - BrianDYKim/memepari-3A: 밈팔이닷컴 3A (Authentication/Authorization/Access-Control) 관련 리포지토리입니

https://github.com/BrianDYKim/memepari-item

GitHub - BrianDYKim/memepari-item: 밈팔이닷컴 카테고리/품목/주문 서버입니다