항해99 실전 프로젝트 1주차 회고록

1. 팀 빌딩

드디어 항해99의 꽃이라고 불리우는 실전 프로젝트 주가 되었는데, 지금 심정은 기대 반, 걱정 반인 상태이다. 며칠 전만 하더라도 팀 리더를 지원할 생각은 1도 없었다. 그렇게 생각했던 이유로는 다음과 같다. 취업하면 어떠한 환경인지 제대로 모르는 상태에서 주어진 프로젝트를 잘 완수해나갈 수 있도록 적응력을 키워야겠다는 마인드가 더 컸기 때문이다. 물론, 스스로 계획을 세우고, 아이디어를 제안해보긴 하겠지만, 직장 생활을 해오면서 리더십보다는 적응력을 키우는 편이 더 낫겠다고 생각했기 때문이다. 그런데도 불구하고, 실전 프로젝트 하루 전날, 1주차 미니 프로젝트 당시 같은 조였던 프론트엔드 분께 먼저 한 팀을 꾸려보자고 제안하였다. 변덕스럽다고 생각할 수도 있겠지만, 막상 실전 프로젝트가 코앞에 다가오니, 전혀 모르는 사람과 함께하게 되었을 때의 도박보다는 비교적 확실한 누군가와 함께 하는게 훨씬 낫겠다고 생각했기 때문이었다.

2. 많은 선택지 속에서의 방황

나와 기존에 알던 프론트엔드 분은 각각 리더, 부리더를 하기로 하였고, 새로운 팀원 2명이 투입되었다. 이들은 기존에 한 번씩은 거쳐갔던 인원들이라 한편으로는 매우 다행이었던 것 같다. 마지막으로는 디자이너 2명이 투입되었는데, 두 분 모두 경험이 있으신 분들이라 그런지 적극적이시고, 신박한 아이디어를 많이 제공해주셨던 것 같다. 나름의 우여곡절 끝에 기획 초안과 와이어프레임이 구성되었고, ERD 설계와 API 설계를 진행하였다. 그런데, 이 과정에서 다음과 같은 어려움이 있었다.

2.1. 리더 & 부리더 세션

실전 프로젝트 전날에 리더 & 부리더 세션을 진행하였다. 이 세션에서는 스파르타측 매니저님이 리더와 부리더의 역할과 책임, 프로젝트 주제 선정 시 유의해야할 점 등에 대해서 말해주었다. 이 내용을 간략하게 요약하면 다음과 같다.

• CRUD를 구현하는 형태의 서비스는 가급적이면 제외시키자.
  • 예를 들어, 맛집 공유, 협업 툴 등의 주제는 너무 흔하다.
  • 채용자로 하여금 관심을 이끌어낼 수 있는 주제로 선정하는 것이 좋다.
  • 즉, 참신함이 필요하다.
• 기술적 챌린지를 반드시 선정하자.
  • 앞서 언급하였듯이 CURD만으로 구성된 서비스는 너무 뻔하다.
  • Socket.io, three.js, WebRTC 등을 활용하면 고수준의 기술력을 어필할 수 있다.

즉, 채용 담당자가 보기에 호기심을 가질만한 주제를 정하거나, 기술력을 높이면 될 것이라고 생각하였다. 이를 토대로 팀원들과 상의하여 추려본 주제는 다음과 같다.

• 부트캠프 및 개발자 양성 교육기관 비교 & 리뷰 플랫폼
• 맛집 공유 서비스
• 팸투어 모집 광고 플랫폼 서비스
• 크라우드 펀딩 사이트
• 실시간 코드 에디터

이 말을 듣고 머릿속은 온통 의문으로만 가득차게 되었다. 내가 자주 즐겨보던 유튜브 채널 개발바닥에서의 내용과는 상반된 내용이었을 뿐더러, 내가 생각했던 프로젝트의 진행 방향과는 다소 차이가 있었기 때문이다. 나는 개인적으로 프로젝트에 사용된 다양한 기술보다는 안정적으로 서비스되는 프로젝트의 아키텍처와 코드를 더 중시하는 방향이었다. 그런데, 위와 같은 제한사항은 마치 이 프로젝트를 취업을 위한 포트폴리오로 사용할 것이다라는 느낌보다도 실제로 서비스를 할 만한 독창적인 것을 만들어야만 해라고 들렸기 때문이다. 다행히도 유능하신 디자이너님들 덕에 한 가지 괜찮은 주제를 선정하였고, 이를 토대로 팀원들의 동의를 얻어 팀 프로젝트를 진행하기로 하였다.

• 점심시간, 저녁시간 등을 활용하여 낯선 사람들과 식사를 하되, 단지 식사에서만 끝나는 게 아니라 전문적인 지식 또는 고민 상담까지 진행될 수 있도록 도와주는 매칭 서비스

2.2. 기획 멘토링과 기술 멘토링

기획 멘토링에서는 우리가 기획한 내용에 대해 어떠한 기능을 더 추가하면 좋을 것인지 등의 세부적인 피드백을 기대했었다. 그러나, 나와 우리팀이 기획을 정말 기획 그 자체로만 생각해서 그런지 기획에 대한 내용보다는 기술적 챌린지에 관한 내용을 더 많이 들었던 것 같다. 기획 멘토링 시간이 끝나고 팀원 모두의 의견이 달라서 다소 혼란스러운 상황이 연출되었는데, 그 이유는 아마도 저마다 생각하고 있는 기술적 챌린지에 대한 정의에 차이가 있기 때문이라고 생각한다.

내 기준에서의 기술적 챌린지는 다음과 같다.

서비스 안정성과 서버 성능 향상

최신 기능, 화려한 기능을 추가하는 것은 언제나 신선하다. 그러나, 새로운 것을 사용하고자 할 때에는 명확한 이유가 있어야 한다고 생각한다. 단지 새롭기 때문에, 남들이 다 하기 때문에라는 이유로 당위성, 목적 적합성에 맞지도 않는 것들을 도입하려는 자세가 팀 전체를 위험에 빠뜨릴 수 있기 때문이다. 이는 꼭 개발자가 아니더라도 직장 생활을 해보았다면 알 수 있는 내용이라고 생각한다. 최신 기술을 배우고, 적용시키는 것은 언제나 설렘을 가져다주지만, 단지 최신 기술들을 사용해보았다는 자세보다 기본을 얼마나 잘 알고 있고, 이를 통해 어떻게 서비스를 운영해 나가는지 직접 경험해보는 것이 매우 큰 공부가 될 것 같다는 생각이 들었다.

코드의 확장성, 재사용성, 유지보수성 확보

같은 코드를 작성하더라도 OOP로 작성할 수도 있고, FP 방식으로 작성할 수도 있다. 중요한 것은 그렇게 작성한 자신만의 기준이 있어야 된다는 것이다. 실제로, 프로젝트의 서버 측 프로토타입 코드를 작성할 때 NestJS를 사용하였다. 그런데, DI, IoC 등 주로 Java Spring 진영에서의 개념을 알아야만 자유자재로 NestJS를 사용할 수 있을 것 같은 느낌이 들었다. 즉, 이러한 개념을 알지 못한다면, 단지 NestJS의 사용법을 아는 것이지, NestJS를 제대로 사용할 줄은 모른다고 생각이 들었다. 따라서, 프레임워크를 Express로 전환하여 NestJS의 동작 방식을 접목시켜보기로 하였다. Decorator(@Controller, @Get, @Post 등)로 class의 metadata를 변경하는 기능을 직접 구현하면서, 의존성 주입이 왜 필요한지, IoC 컨테이너가 왜 필요한지, NestJS가 왜 편리한 프레임워크인지에 대한 이유가 명확해졌고, 다시 NestJS로 프레임워크를 변경하였다. 1~2일 정도는 날려먹은 것 같지만, 스스로는 굉장히 유익한 시간이었다고 생각한다.

팀원 간 큰 마찰 없이 무사히 프로젝트를 수행할 수 있는 협업 능력

혼자 사이트 프로젝트를 하면 재미있다. 그 이유는 혼자서 자유자재로 기획, 설계, 구현까지 할 수 있기 때문이다. 그러나, 팀 단위로 프로젝트를 진행할 때에는 변경된 부분에 대해서 모든 팀원과 공유를 해야만 한다. 이 과정에서 의견 충돌이 발생할 수 있고, 심한 경우 감정 싸움까지 번질 수 있기에 조심스러울 수 밖에 없다. 따라서, 팀장으로서 팀원들 간 최대한 병목 현상이 발생하지 않도록 의견을 조율하고, 분위기를 조성하고, 소통을 원활히 진행시키는 것 또한 하나의 기술력이라고 생각하였다.

약 3시간 동안 고민하고, 기획을 변경하려다가 먼저 담당 매니저님께 찾아가서 스파르타 측에서 요구하는 기술적 챌린지의 정의에 대해 여쭤보기로 하였다. 다행인건지는 모르겠으나, 담당 매니저님께서도 해당 기술을 왜 사용하는지, 어떻게 해결하였고, 왜 그렇게 해결하였는지 등에 초점을 맞춰 말씀해주셨다. 이후, 팀원들과 소통하며 각자 프로젝트의 방향성에 대해 어떻게 생각하는지 글로 남긴 후 공유하는 시간을 가짐으로써 프로젝트의 방향성을 하나로 일치시킬 수 있었다.

3. 트러블 슈팅

실전 프로젝트가 시작된 이후로 밤을 지새우는 일수가 급격히 증가하고는 있으나, 아직까지는 기술적으로 크게 부딪히지는 못한 것 같다.

금요일, 토요일은 새벽 4~5시에 잠이 들었고, 일요일은 오전 6시에 일어나서 현재(월요일 오후 18시)까지 한 숨도 못자고 있다.

물론, AWS elasticbeanstalk를 처음 접해보며, NestJS 애플리케이션의 CI/CD를 구축하는 과정에서 꼬박 하루라는 시간을 쏟거나, Kakao Login API, TypeORM 관계 설정 및 QueryBuilder를 사용할 때 트러블이 계속해서 발생하고 있으나, 이는 사용 방법을 명확하게 알지 못해서 발생하는 문제라고 생각이 들었기 때문에 기술적인 난관이라고는 할 수 없을 것 같다. 일단, 이번 주는 기본 기능을 전부 구현해놓기로 하였고, 심화 기능(현재 위치 기반 데이터 조회, 정렬, 필터 등)은 다음 주부터 구현하기로 계획되어 있어서 그 때부터 본격적으로 기술적 난관에 부딪힐 수 있다고 생각이 된다. 항상 느끼는 거지만, 문제와 맞딱드렸을 때 겁이 나거나, 불안하지는 않는 것 같다. 다만, 현재로써는 짧은 프로젝트 기간에 그 문제를 해결하는 동안, 시간이 매우 빠르게 지나가 버린다는 사실이 불안하게 느껴지는 것 같다.

4. 마치며

여기까지 1주차 회고록을 마치겠다. 실전 프로젝트를 시작한 지 1주일이 조금 넘었다. 장점이라고 한다면, 하고픈 말과 느낀 것이 매우 많다는 것인데, 단점이라고 한다면, 아직까지는 기술적으로 크게 얻은 것이 없는 느낌이다. 개발에 조금 더 집중하고 싶은데, 문서 작성, 회의, 설명 등으로 인해 개발에 집중할 수 없는 상황이 욕구 불만으로 느껴지는 것 같다. 앞으로 약 2주 정도 남았는데, 팀원들에게도 자주 하는 말이지만, 이거 끝나고 병원가겠다는 마인드로 불태워보려고 한다.