
구름톤 풀스택 4회차 이론 기간이 끝났다.
1, 2차 스터디 발표가 끝나고 한 달간 이뤄지는 1차 프로젝트 기간이 시작됐다.
1차 프로젝트의 경우, 아쉽게도 구름에서 주제를 제공한다. 주제는 아래와 같다.
우리는 1번. 코드 편집기 사이트를 만들기로 결정했다.
보통 4~6명의 인원으로 프로젝트를 진행하게 된다.
스터디 때 부터 같이 진행해온 팀원들을 바탕으로 팀을 꾸렸고,
추가로 한 명의 팀원을 더 배정 받게 되었다.
그러나 팀원 중, 아예 참여가 어려운 팀원들이 있었다.
시작 당시, 우리는 프로젝트를 너무 쉽게 생각했다. 나 역시 프로젝트를 과거 2번 진행한
경험이 있었기 때문이다. 지금 되돌이켜 생각한다면 정말 오만했다.
그러나 당시에는 정말 괜찮다고 생각했다.
기본 기능만 충실히 만든다면, 오히려 시간이 남지 않을까? 라는 생각을 할 정도였다.
확실히 프로젝트에 참여 가능한 인원은 BE 2명, FE 2명이었다.
BE의 경우, Social Login과 CI/CD의 역할을 나누는 과정이 필요했다.
Social Login의 경우 JWT, Oauth2.0, Spring Security의 개념이 필요하고
CI/CD는 Docker 등의 개념이 필요했으므로 당시 Docker 강의를 듣고 있던 팀원이 CI/CD의 역할을 가져갔다. 당시엔 참 고마웠다.
팀장이 바로 나!

의 기능을 주축으로 나눠 코드 작업을 시작했다.
과거 프로젝트를 진행할 당시, 내가 했던 기획이라고는 주제 선정과 ERD 짜기 정도에 불과했다. Spring MVC구조로 진행했기 때문에 BE와 FE 구분이 명확하지 않았으므로 WireFrame이나 API 명세서는 작성하지 않았기 때문이다.
많은 교육생들이 이 부분을 놓치듯, 나 역시 기획을 신경쓰지 않았다.
중요한건 '기능을 어떻게 잘 만드느냐'에 초점이 맞춰져 있었기 때문이었다.
그러나, 구름톤의 경우, 기획의 중요성을 상당히 강조했다.
기획 멘토링과 발표가 그 사례인데, 처음엔 이 중요성을 몰랐기 때문에 왜 이런 불필요한 시간을 낭비할까? 하고 생각했다. 심지어 이 타이밍을 또 놓쳐서 나는 두 번째 프로젝트 DEEP 때에서야 철저히 느꼈다. 아주 늦다 내가~ 하하
내가 아는 기술 문서는 ERD와 WireFrame이 전부였다. 가장 중요한 API 명세서는 작성해보지 않아 어떤 형식으로 만들어야하는지도 몰랐다. 열심히 찾아보고 표로 만들어 팀원들과 같이 API 명세서에 대해 이야기를 나누기도 했다.

간단히 말하면 API 명세서는 한 기능을 두고 FE와 BE가 하는 약속이다.
BE가 먼저 만들고 FE가 만들고 하는게 아니라 한 기능을 동시에 만들기 때문에 주고받을 데이터에 대한 규칙이 있어야한다.
앞서 말했듯 아방하게 이게 뭘까^^ 하는 생각으로 만들었고, 부분 수정을 많이 했다.
실무에서는 API 명세서 작성 후, 수정이 필요하다 판단된다면 수정 대신 새로운 API를 만든다고 배웠는데... 처음이었으므로 부분적으로 수정을 했다.
API 명세서, ERD, WireFrame, 요구사항 정의서 등.. 여러 기술 문서들을 작성하며 우리는 하루종일 회의를 했다. 디자인 관련해서는 다 같이 웃고 떠들기도 했고, ERD를 짤 때에는 왜 관계설정을 이렇게 하는지 의견을 주고 받기도 했다. 아주 허술하고 재밌게 기획을 진행했다.

그렇게 탄생한 사이트의 주제는 자:몽 IDE였다. 자몽 색을 바탕으로 Python, C/C++, Java, Javascript 코드 편집기를 만들어보자는 의도였다.

나름 열심히 기획을 준비했다고 생각했는데, 기획 멘토님과의 관점에서는 많이 엇나가있었다.
우리는 해당 기획을 이런 문서들을 바탕으로 준비했다! 라는 느낌으로 어필했다면,
멘토님께서는 기획을 세우며 우리는 어떤 규칙을 준비해 운영했는지, 또 기획을 준비하며 어떤 성장을 했고 어떻게 느꼈는지 등도 같이 평가하셨기 때문이다. 우리는 이런 부분이 아예 없었다. 많이 부족했다고 느낀다.