프로젝트 소개🎙

프로젝트 '투게더'는 한마디로 소마고 사이드 프로젝트 매칭 플랫폼이다.
전국 소마고 네트워크 구축과 프로젝트 규모의 제약을 해소시키는 것을 목표로 제작되었다.
무려 3개월에 걸친 처음이자 대규모 프로젝트인 투게더, 나는 PM과 백엔드를 맡았다.

지금부터 나의 다사다난했던 첫 프로젝트의 A to Z를 소개하겠다

기획, 별거 맞네⭐️

프로젝트 기획을 위해 우선 해결하고 싶은 문제점을 찾아보았다.
당시는 프로젝트 전성시대. 모두가 프로젝트를 하나씩은 맡게 되는 시기여서 프로젝트의 근본적인 문제에 대해 생각해보니, 자신과 친한 친구들끼리만 모여서 프로젝트를 하게 되어서 친하지 않은 친구들은 실력과 별개로 프로젝트에 참여하기 어렵다는 사실과 이로인해 프로젝트의 규모가 한정된다는 사실을 찾게 되었다.

이를 해결하기 위해서는 같은 문제점을 공유하는 소마고 학생들 모두 프로젝트 참가/모집이 가능한 플랫폼을 만드는 것이라고 판단했고. 결국 '소마고 사이드 프로젝트 플랫폼'을 기획하게 된 것이다!

시장 조사

기존의 사이드 프로젝트 플랫폼들을 조사해 보았다.

1. 스프(soup)-홈화면, 검색화면, 글쓰기 화면, 커뮤니티 등으로 구성된 웹페이지다. 쉽게 프로젝트를 모집할 수 있지만 따로 연락할 수 있는 방법이 없어서 게시글에 연락용 링크를 따로 달아야 한다. 또한 웹페이지에서 다른 회원의 프로필을 조회할 수가 없어 어떤 기술 스택을 사용하는지 알 수가 없었다. 마지막으로 앱을 지원하지 않는다는 점이 매우 아쉬웠다.

2. 렛플(LET’S PL)-홈화면, 프로젝트 목록 화면(+검색), 스토리(여러 소식들), 라운지(커뮤니티)으로 구성된 웹/앱 플랫폼이다. 게시글에 모집 현황과 멤버 등을 구체적으로 확인할 수 있고, 각자의 프로필을 조회할 수 있어서 개발 포지션과 기술 스택, 그동안 진행한 프로젝트 목록도 조회가 가능하다. 또한 1:1채팅을 할 수 있어서 연락하기도 매우 편리하다. 하지만 렛플의 큰 특징은 ‘프로덕트 출시’를 목적으로 하는 게시글이 대다수이기 때문에 개발을 공부한지 얼마 안된 주니어 개발자들과 학생들이 단순히 실력증진을 목적으로 참가하기 어렵다.

결론

• 웹/앱 을 동시에 출시하여 언제 어디에서나 플랫폼에 접속할 수 있게 하고 1:1 채팅기능을 구현하여 ‘투게더’안에서 모든 모집/참가 과정을 완료할 수 있게 하기
• 소마고 전용 계정만 가입이 가능하게 해서 오직 소마고 학생들만의 실력증진과 네트워킹을 목표로 하는 플랫폼이 되도록 하기

팀원찾아 삼만리🚗

기획을 했으니 프로젝트를 함께할 팀원들을 모아야 했다. 우선 실력이 좋은 2명의 친구들(iOS, 디자인)을 구했고, 그 다음 협업할 백엔드 1명, iOS 1명, 그리고 안드로이드 1명을 구했다. 마지막으로 프로젝트의 아이덴티티를 위해 소마고 연합 토크쇼의 인연으로 다른 소마고 학생 (프론트) 1명을 구하게 되었다

애자일..해보죠?

처음에는 별 생각없이 프로젝트를 진행했다. 먼저 기본적인 기능을 짜고(나름 MVP) 이를 API 명세로 만들었다. 그 후 백엔드 개발&디자인 → 클라이언트 개발 순으로 물 흐르듯이 진행시켰지만, 여러 문제가 발생했다

1. 복합적인 이유(사용할 기술스택 공부, 에러 핸들링)로 인한 마감일 지체
2. 서로의 프로젝트 진행 사항 파악이 어려움

위와 같은 문제로 인해 애자일을 도입시켜보았다.

애자일은 린 프로세스를 착안한 소프트웨어 개발 방법론으로, 이슈에 빨리 대응하는 것을 목표로 한다. 우리는 스크럼 프레임워크를 사용하여 앞서 말했던 문제를 해결하려고 아래와 같이 노력했다

1. 스탠드업 미팅을 대신한 간단한 스크럼 채팅(오늘 할일, 어제 했던 일, 문제점을 말하여 진척 상황 파악)를 통해 팀원의 작업과 이슈를 간단하게 파악함
2. 스프린트(현재 구현할 기능들의 업무를 주기로 나누어서 작업을 하고, 회고를 통해 좋았던 점과 개선점을 피드백하는 프로세스)로 업무를 효율적으로 관리함

사실 이미 프로젝트가 이미 진행되고 있는 상황이라서, 이미 기획된 MVP(최소 기능 제품)구현을 목표를 남은 작업들을 스프린트로 관리하는 시스템으로 진행시켰다.

문제점

진행상황을 한눈에 파악하기 힘들고, 스프린트의 주기가 너무 길어서 피드백 주기도 길어졌다

해결 방법

2차 스프린트에는 스크럼 보드를 사용하여 프로젝트 진행상황을 시각화하고, 스프린트 주기를 2주로 줄여서 실행했다

24시간 운영 Devops⏰

이번 프로젝트를 진행하면서 직접 AWS에 배포하고, 여러 에러들을 핸들링하는 이른바 ‘데브옵스’ 업무도 수행하였다

CI/CD

CI/CD는 지속적 통합, 지속적 배포라는 뜻이다. 쉽게 말해 협업 시 일어나는 브랜치 오류 방지와 커밋 시, 변경된 코드를 다시 배포하는 과정을 자동화하는 시스템이다. 우리 팀은 깃허브 액션과 도커, AWS를 이용해서 CI/CD를 구축하였다.(다음에 배포 방법도 포스팅하겠다). 이를 통해 코드가 바뀔 때마다 배포하는 번거로운 과정을 생략하여 훨씬 효율적으로 작업할 수 있었다.

QA 똑바로 안해?

이번 프로젝트를 하면서 클라이언트와의 통신에서 생기는 여러 에러들을 해결하는데 꽤 많은 시간을 할애했다. Postman을 사용해서 기능 테스트를 하였지만 꼼꼼하게 하지 못한 탓에 연결하면서 많은 오류가 터졌다…얻은 교훈은 더욱 꼼꼼한 테스트보다는 ‘테스트 코드’ 였다.

위의 테스트 피라미드를 보면, 가장 근본적인 테스트는 단위 테스트인 것을 확인할 수 있다. 단위 테스트 코드를 짬으로서 각 클래스 작동여부를 확인할 수 있고, 문제 발생시 원인을 빠르게 찾을 수 있게 된다.

Postmortem⚰️

우리 팀의 특별한 것중 하나는 바로 요기요에서 배운 Postmortem(부검)이다.
요기요 포스팅 읽으러 가기

프로젝트 진행 중 발생하는 오류의 발생 원인과 해결 방법을 기록해서, 재발을 방지하는 데이터베이스를 구축하는 것이다. 예를 들어 가장 골치 아팠던 CORS 파트를 아래와 같이 작성했다.

사실 Postmortem의 효과는 많이 체감하지 못했다. 왜냐하면 문제 해결시 다음에 재발할 가능성은 현저히 낮았고, 또한 대처법을 기억하고 있으므로 동일한 문제 발생 시 바로 해결 가능했다. 하지만 시간이 지나서 다른 프로젝트 진행 중에 같은 문제가 재발하는 상황을 막기 위해서, 또한 발생시 해결하기 위해서는 데이터베이스에 정보를 저장해놓는 것이 최선의 방법이라 생각했고, 지금까지도 잘 구축한 팀 문화중 하나라고 생각한다.

부실한 코드리뷰😈

위와같이 Pull Request를 통한 코드리뷰는 서로의 코드의 품질을 향상시키는데 도움을 주며, 프로젝트 코드의 구조를 이해하는 필수적인 과정이지만 다른 공부를 우선시하여 코드 리뷰 간격이 늦어지게 됐고, 서로 리뷰를 기다리지 않고 바로 머지해버리는 악순환이 반복되었다. 이로 인해 분명 내가 참여하는 프로젝트인데 내가 모르는 부분이 생겨서 코드 수정이나 기능 추가시 접근하기에 까다로워지는 치명적인 문제점이 생겼었다.

후기

첫 팀 프로젝트라 많은 문제가 있었지만, 이를 극복했다는 점에서 상당히 뿌듯했다. 느낀 점을 간단히 추려보자면

1. 코드리뷰는 결국 모두를 위한 것이다. 어쩌면 커밋보다 우선순위가 높을 수도 있다.
2. 프로젝트 트래킹에 상당한 어려움을 겪었다. 이를 해결하기 위해서는 시각화를 통해 팀원 전체가 진행 상황을 직관적으로 파악할 수 있게 하고, 스탠드업 미팅에서 이와 관련한 업무 내용, 이슈 상황 등을 얘기하는 문화를 구축할 필요성을 느꼈다
3. 다음에는 여러 기술 스택들을 사용하여 더욱 실제 프로덕트에 가깝게 코드를 짤 예정이다
4. 문서화는 모든 일의 근본이다. 요구사항을 정확히 파악한 ERD, 기능들이 확실히 정리된 API 명세를 포함한 최대한 많은 기록이 필요하다

프로젝트 레포 : https://github.com/D-PRlME