1. 서비스 개발 동기

지난여름 js-piscine에 참여하여 rush 과제(팀 프로젝트)로 Markdown 기반 게시판을 만들어 보았습니다. 2일이라는 짧은 기간 동안 진행하였지만 결국 완성시키지 못하여 rush 과제를 함께 진행했던 팀원들과 함께 js-piscine 과정 이후 마저 완성시켜보기로 하였습니다.

이후 우리는 욕심이 생겨 단순히 rush 과제가 아니라 좀 더 발전시켜 실제 이용자가 있는 서비스를 만들어 보기로 하였습니다. 나는 팀 프로젝트로 이런 서비스를 만들어 본 경험이 없었지만 실력 있고 열정 넘치는 팀원들과 함께 한다면 못 만들 것이 없을 거라 생각하여 4개월에 걸친 프로젝트를 시작하게 되었습니다.

2. 프로젝트 과정

2.1 문제점 파악

우리가 만들려는 프로젝트에서 핵심은 실제 이용자가 있어야 한다는 것입니다. 이를 위해 우리는 42 Seoul이라는 우리가 속한 커뮤니티를 활용하기로 하였습니다. 42 Seoul에서 불편한 점을 파악하여 이를 개선하는 서비스를 만드는 것입니다. 며칠 동안 팀원들과 아이디어 회의를 하다 42 Seoul의 Slack에서 코딩과 관련된 질문을 주고받는 채널이 general 채널에 주목했습니다.

general 채널은 42 Seoul에서 많은 카뎃들이 과제에 대한 질문을 주고받아서 매우 많은 정보가 담겨있습니다. 실제로 과제를 하다 궁금한 점이 생겨 general 채널에서 찾아보면 대부분 이미 같은 질문과 답변을 찾을 수 있습니다. 그러나 general 채널은 Slack이라는 앱의 채널이다 보니 몇 가지 아래와 같은 문제점들을 찾을 수 있었습니다.

2.2 서비스 수요 조사

위에서 찾은 문제점들이 다른 카뎃들도 공감하고 있는지 설문 조사를 진행했습니다. 팀원 4명 모두 이 문제점들을 개선한 서비스의 필요성에 공감하였지만 다른 카뎃들도 우리와 같은 생각인지 확인이 필요했습니다.

짧은 기간 동안 진행된 조사이기 때문에 표본이 큰 조사는 아니었지만 많은 카뎃들이 general 채널의 문제점에 대해 공감하고 있음을 확인할 수 있었고 우리는 이를 개선한 42 Seoul의 스택오버플로우, Q&A 서비스를 만들어 보기로 결정했습니다.

2.3 서비스 정의

프로젝트 진행에 앞서 이 프로젝트에서 구현할 서비스에 대해 정의할 필요가 있었습니다. 앞서 진행한 설문 조사를 바탕으로 general 채널의 문제점을 정리하고 이를 해결할 방법들을 고민하였습니다.

결정한 해결 방법들을 구현하기 위해 필요한 선행 지식들을 하나씩 공부를 해나가고 notion에 정리하여 공부한 지식들을 팀원들과 공유하였습니다.

2.4 멘토링 진행

프로젝트를 진행한지 한 달이 조금 넘었을 때, 저희는 지금 잘하고 있는 것이 맞는지 확인이 필요했습니다. 모르는 것은 계속해서 팀원과 함께 고민하고 구글링을 통해 해결해나가고 있었기 때문에 실제 서비스를 이렇게 만드는 것이 맞는가 하는 의문이 들었습니다. 42 Seoul의 여러 멘토님들에게 멘토링을 요청하여 저희 서비스에 대해 다양한 관점에서 피드백을 받을 수 있었습니다.(박수현 멘토님, 이태영 멘토님, 차경묵 멘토님, 허광남 멘토님 감사합니다 ㅎㅎ)

멘토링을 통해 가장 크게 배운 것은 유저 입장에서 생각해야 된다는 것이었습니다. 저희는 프로젝트를 진행하며 최대한 다양하고 어려운 기술들을 사용하여 있어 보이는 프로젝트를 만드는 것에 집중하고 있었습니다. 그러나 프로젝트에 있어서 중요한 것은 신기한 기술을 사용하여 있어 보이는 프로젝트를 만드는 것이 아니라 유저가 필요한 서비스를 잘 작동하도록 구현하는 것이었습니다

이후 우리는 유저에게 필요한 서비스가 잘 작동하도록 구현하는 것에 중점을 두고 이를 구현하는 데에 필요한 기술을 공부하고 적용하였습니다. 기술 중심 개발에서 유저 중심 개발로 개발 방식을 바꾸고 프로젝트는 나아가야 할 방향이 분명해졌습니다.

3. 프로젝트 과정 문서화

프로젝트를 진행하며 많이 신경 쓴 부분 중 하나는 문서화였습니다. 우리가 어떤 생각을 가지고 개발을 진행하였는지 또 어떻게 진행했는지 가장 쉽게 설명할 수 있는 방법은 문서화입니다. 문서화에는 GitHub의 wiki를 적극적으로 활용했고 문서화한 내용들은 다음과 같습니다.

3.1 배포 환경 설정

ec2 환경 준비

Nginx Reverse Proxy 설정

Nginx SSL 설정

Sentry 적용

데이터베이스 자동화 백업

Google Analytics 적용

3.2 단위 기능 설명

Error Class 사용

Validation 사용

API 보안 (access token, refresh token)

SWR 사용

CustomHook 사용

3.3 성능 이슈 개션

질문 상세 페이지 API 속도 테스트

다른 사용자 조회 API 속도 테스트

covering index 사용으로 페이지네이션 속도 개선 테스트

4. 협업 방식

특정한 작업을 시작하기 전에 기능에 대한 정의와 구현해야 할 세부사항 checklist를 GitHub 이슈에 작성하고 해당 작업 branch를 생성하고 해당 작업의 commit 메시지에 이슈 번호를 태그 하여 풀리 퀘스트를 하고 팀원의 코드 리뷰를 거쳐 머지되는 방식으로 진행되었습니다.

위의 방식으로 진행했을 때 지금 누가 어떤 작업을 하고 있는지 쉽게 파악이 가능했으며 또 어떤 작업을 해야 할지 또한 쉽게 파악이 가능했습니다. 또 코드 리뷰를 통해 서로의 코드를 이해할 수 있을 뿐만 아니라 코드에서 놓친 부분을 발견하여 미리 수정할 수도 있었습니다.

혼자서 작업하기 어렵거나 구현이 잘 안되는 부분이 있는 경우 디스코드로 팀원과 함께 페어 코딩(두 명이 고민하며 둘 중 한 명만 코드를 작성하는 방식)을 진행하여 하루 종일 고민해도 해결하기 어렵던 문제를 금방 해결할 수 있었습니다.

아래는 디스코드로 집합시키는 ji-park 님의 카톡입니다.

5. 오픈을 앞두고


팀원들과 함께 정신없이 개발을 하다 보니 어느새 서비스 오픈 직전이 되었습니다. 베타서비스로 배포를 하고 회원가입하는 유저들이 하나 둘 생기고 질문 글과 답변 글이 하나씩 올라오는 것을 보니 오픈 직전이라는 사실이 더욱 와닿았습니다. 그러나 그런 감상에 빠지려 하면 알 수 없는 버그가 하나둘씩 튀어나와서 다시 정신없이 버그 수정을 하고 있습니다.

저희의 최종 서비스의 이름은 42SWIM 입니다! 이유는 라피신을 통해 수영장에 내던져진 카뎃들이 알아서 수영을 배웠으니 수영을 하고 있는 본과정을 비유한 의미입니다. 많은 카뎃들이 42SWIM 을 통해 좀 더 적극적인 동료학습을 하고 궁금한 점을 빠르게 해결해나가도록 돕고 싶습니다.

nkim

  • 저는 이번 42SWIM 서비스 개발을 하면서 협업에 대해서 가장 많이 배우게 되었습니다. 특히 Git으로 협업하는 법, React 로 협업하는 법을 가장 크게 배웠습니다. 이전에는 Git의 pull, push, commit 만 알았던 제가 이번 프로젝트를 통해 PR, naming 컨벤션, GitHub Actions 등을 사용하게 되었습니다. 팀원들과 프로젝트의 퀄리티를 위해 고민한 결과였던 것 같습니다.
  • React 는 저와 yejeong 언니가 같이 진행하였는데 같이 component 구조를 어떻게 짤까에 대한 고민부터 React 의 TDD 까지 고민해보면서 나중에 유지보수성 및 사용자 경험에 대해 깊게 생각해보는 기회가 되었습니다.
  • 프로젝트로 끝이 아니라 앞으로 생길 많은 버그들(?) 그리고 모니터링 및 유지보수를 위한 작업들을 어떻게 관리해나갈지 배워나가고 있습니다. 앞으로 저희가 없더라도 인수인계를 통해 서비스가 유지되기 위해 문서화가 가장 중요하고 공을 들여야 한다는 점을 깨달았습니다.
  • 프론트 영역에서 매달, 매주 많은 기술들이 나오고 트렌드가 바뀌는 것을 몸소 느끼게 되는 시간이었습니다. 버전에 따른 에러들과 충돌들..그리고 많은 라이브러리들을 경험해보면서 앞으로 프론트엔드 엔지니어로서 어떤 방향을 가지고 나아갈지 조금 알게되는 순간이었습니다.

yejeong

  • 프론트엔드 백엔드 역할을 나눠서 진행한 건 이번이 처음이었습니다. 백엔드와 통신을 하며 새로운 문제와 버그들을 만났고, 풀어가는 과정에서 많은 걸 배우게 되었습니다.
  • 컴포넌트 재사용성을 어떻게 극대화시킬지에 대해서 nkim과 다양한 이야기를 나누었습니다. 논의 끝에 아토믹 디자인 패턴을 사용했습니다. 개발 시작 단계에서 이렇게 다양한 이야기를 나누며 풀어가는게 무척 좋은 경험이었습니다.
  • 42서울 아카데미를 통해 다양한 멘토님께 멘토링을 받았습니다. 그 덕분에 기술스택과 코드에 대한 다양한 리뷰를 받을 수 있어서 프로젝트 완성단계에 많은 도움을 받을 수 있었습니다.
  • 프로젝트를 만드는데서 그치지 않고, 42서울 카뎃들에게 배포까지 진행하면서 생각지 못한 더 많은 에러들을 마주했습니다. 유저들은 절대 우리가 예상한대로 행동하지 않는다는걸 또 한번 깨달았고, UX에 대해서도 깊게 고민하게 되는 경험이었습니다.

iha

  • 웹 프로젝트 경험도 없고 api가 무엇인지도 모르던 제가 성능을 고려한 api 설계와 작성부터 swagger를 사용하여 api 문서화 및 다양한 방법을 직접 성능 테스트하여 좋은 방법을 선택하는 등 이번 프로젝트를 통해 정말 많이 성장했음을 느꼈습니다.
  • 이번 프로젝트를 진행하며 페어 코딩을 처음 경험해 봤는데 정말 신세계였습니다. 하루 종일 붙잡고 있어서 전혀 해결되지 않던 문제가 혹은 놓치고 있던 부분이 페어 코딩을 하면 허무할 정도로 쉽게 해결되었습니다. 앞으로도 페어 코딩을 자주 이용할 예정입니다.
  • 페어 코딩으로 해결하지 못한 고민들은 멘토님들이 항상 잘 해결할 수 있는 길로 인도해 주셨습니다. 방향을 모를 때 도움을 받을 수 있는 멘토님들이 존재가 얼마나 큰 것인지 느낄 수 있었습니다.
  • js-piscine에 참여하여 rush 과제의 랜덤으로 팀원 매칭된 인연이 이렇게 좋은 성장의 기회가 된 것이 신기하고 항상 팀원들에게 감사한 마음을 가지고 있습니다.

ji-park

  • ”엘리베이터가 느리면 누구는 엘리베이터 알고리즘을 바꾸어 속도를 최적화 할것이고, 누구는 거울을 달 수도 있다.” 라는 말처럼 개발하면서 생겼던 문제들을 여러가지 방법으로 시도했고, 우리에게 알맞는 방법을 찾아 해결했습니다. 이 과정이 행복했습니다.