웨이팅 캐치 프로젝트 과정 및 회고

0. 여는 글

K-Digital Training 내일배움캠프 스프링 과정은 프로젝트 기반 교육(Project Lead Educate)을 실행한다. 그 중 마지막 장식인 5주간 진행되는 최종프로젝트가 어제부로 마무리가 되었고, 살짝 아련해져서 프로젝트 과정을 톺아볼겸 회고를 해보려고한다. 긴 기간동안 진행되었기 때문에, 모든일들을 다 적을 순없고 스프린트 별 인상깊었던 사건들 위주로 적어보려고 한다.

1. 프로젝트 소개

'테X블X' 이라는 서비스에서 많은 영감을 받은 서비스이다. 전국 레스토랑의 정보를 불러모아 집, 카페등 편한 장소에서 줄서기를 한 뒤 레스토랑 관리자가 호출 시 방문하도록 유도하는 서비스이다. 손님 입장에서는 식당 앞에 찾아가 줄을 설 필요없는 편의성이 있고, 가게 관리자 입장에게는 붐비지 않는 가게 앞을 만들고 손님관리를 손쉽게 할 수 있다는 장점이 있다.

클라이언트 페이지
판매자 페이지 (sel119 / Test1234!)
관리자 페이지 (admin01 / Test1234!)

2. 프로젝트 진행 과정

2-1. 프로젝트 아이템 선정 및 기획 (23.02.06 ~ 23.02.10)

[아이템 선정]
우리조는 내일배움캠프 측에서 따로 면접을 보고 모인 챌린지팀이 었다. 기존에 홍보할때 해당 팀에서는 다양한 기술적 도전을 할 수 있고, 특히 '대용량 트래픽'을 경험 할 수 있다고 말씀해주셨다. 이전 프로젝트까지 해왔던 것은, 내가 이전 경험에서 했던 것들이라 막막함이 없었지만, '대용량 트래픽'을 경험할 기회는 한 번도 없었기 때문에, 한치의 고민없이 지원하게 되었다.

그래서 그런지 팀원모두 새로운 경험에 관심이 많았고, 특히나 '대용량 트래픽'에 관심을 가지고 있었다.

총 3개의 아이디어가 나왔는데 채팅, 줄서기, 내배캠 통합 플랫폼 이었다. 채팅의 경우엔 타 프로젝트에 서브기능으로 들어갈 수 있었으며, 내배캠 통합 플랫폼은 아이디어는 좋지만, '대용량 트래픽'을 발생시키기엔 억지스러운 것들이 많다고 판단했다.

따라서, 아이템은 줄서기 서비스로 정하고 이름은 '기다림을 잡는 서비스'라는 뜻으로 '웨이팅 캐치'라고 짓게 되었다.
[팀장 선정]
팀원들의 만장일치로 감사하게도 팀장이 내가 되게 되었다. 팀장이란게 사실 거창한 자리는 아니고, 일정을 관리하고 회의 개최하고 그런 역할이라서 나도 큰 부담은 없었고, 그동안 프로젝트를 진행해오면서 일정관리에 대한 경험을 해보고 싶다는 니즈가 있었다. 따라서, 투표결과를 겸허히 받아들이고 팀장의 역할을 수행해보기로 했다.
[일정 수립]
기간을 정하고, 각 스프린트에 대한 due를 정했다. 여기까지는 반드시 해야한다! 라는 공통된 목표날짜를 잡고, 그에따라 날짜를 분배했다. 지나고 생각해보면 계획대로 거의 된 것 같아서 뿌듯하긴 하다 ㅎㅎㅎ 각설하고, 내배캠 측에서 정해놓은 due도 있어서, 그에 맞게 기획-개발-개선-최종 의 기간을 정했다.
[그라운드 룰]
프로젝트 진입 전 원활한 프로젝트 진행을 위해, 팀원들이 어떤 약속을 지켜야 할지에 대한 약속을 정했다. 계속해서 수정되긴했지만, 아침 10시와 저녁 20시에는 반드시 모여서 오늘 무슨일을 할지 공유하고, 무슨일을 했는지 공유하기로 했다. 또한, 인상깊었던 룰은 '투표'였는데, 개발을 하다보면 각자의 생각이 부딫히는 순간이 오는데, 서로의 말이 모두 옳기 때문에 대화가 계속 수평으로 가기만 하고 마무리는 되지않는 상황이 발생했다. 거의 반나절 이상을 한 주제로 토론하고, 그 과정에서 감정이 상하는 과정이 너무 에너지 소비라고 생각되서 '투표'라는 정책을 마련했다.

'투표'가 개최되기 위해선 아래와 같은 조건이 필요했다.
- 2지 선다로 의견이 좁혀진 상태에서 서로의 의견이 논리적으로 타당하다고 생각했을 때
- 팀원 전체가 '투표'에 대해서 동의 할 때
이 정책 도입 후, 우리 팀은 불필요한 토론이 사라져서 빠르게 다음단계로 넘어갈 수 있었다. 대신, 토론은 언제든지 주최 할 수 있도록 제한을 두진 않았다. 추가적으로 우리조는 코드리뷰를 모든 팀원이 해야지 merge될 수 있는 룰이 있었는데, 따라서, 오전은 코드리뷰에 시간을 쏟고 오후에는 개발에 몰두하기로 했다.
[기능 선정]
서비스가 정해졌으니, 그에 따른 기능들을 선정을 해야했다. 기본 기능 외에 '대용량 트래픽'을 실험해볼만한 기능에 대해서, 선정해야했다. 다른 생각하는 기능들이 다르고, 이 과정에서 선정 서비스에 대해서 충분히 토론했음에도 불구하고, 우리가 어떤 서비스를 개발하려고하는지 오해하고 계신 팀원들도 계셨다. 따라서, 이 시간을 통해 다시금 '우리가 뭘 개발하려고 하는지' 싱크를 맞추게 되었다. 다들 욕심이 많고, 개발에 대한 두려움이 없으신 분들이라, 너무 많은 기능들을 개발하고자 하셨다.

나는 이전에 프로젝트를 해온 경험도 있고, 이번 프로젝트는 프론트엔드도 우리가 직접 개발해야했기 때문에, 이 모든 기능들을 개발한다는 것이 불가능 할 것이란게 어렴풋이 느껴졌다. 따라서, 기능들을 필수/추가/추추가 로 나눈 뒤, 필수기능들을 우선적으로 구현 한 뒤, 다른 기능들을 붙혀보잔 제안을 드렸다.
[ERD작성]
정해진 기능에 따라, Entity Relation Diagram을 작성해보았다. 구현하려는 기능에 따라 엔티티가 필요한 항목들이 있었고, 그것에 어떻게 접근할 것이며, 분리하는 것이 효율적인지 쪼개는 것이 효과적인지 지속적으로 토론하며 수정해나갔다. 팀원 중에 최적화에 대해 신경을 많이쓰시는 분이 계셨는데, 한편으로 고맙긴 했지만 추후에 테스트 해보고 진행해도 될 법한 것들을 지속적으로 제안주셔서 당황스러웠다. 개인적인 판단으로 오버엔지니어링이 될 것 같은 부분들이 있어서, 해당 팀원을 설득하고 다른 팀원들의 의견을 구하면서 필요한 부분들은 수용하고, 불필요한 부분들은 추후에 시도해보기로 합의보고 메모하면서 진행했다.

논의중에 가장 기억에 남는 토론들이 있었는데, 지금은 해결된 문제였지만.. 거의 하루종일 토론했던 기억이 있다.
- 이미지만 관리하는 테이블을 만들어서 사용 vs 엔티티 별로 이미지 테이블을 만들어서 관리 vs 엔티티안에 이미지를 넣어서 관리 : 이미지를 그냥 주소만으로 관리하고 추가적인 정보가 필요하지 않기 때문에 '엔티티안에 이미지를 넣어서 관리'하기로 합의
- 줄서기 테이블을 하나로 관리 vs 두개로 분리 : 지속적인 조회가 필요한 상황이 생기면, 풀 스캔을 해야하는 상황이 지속발생하기에 하루단위로 줄서기 기록을 쌓고 그것을 영구저장 테이블에 올려서 관리하기로 함.
- 리뷰 남겨야 할 줄서기를 줄서기 내역을 통해서 알게 할지 vs 유저가 곧바로 자신이 리뷰를 남겨야 할 줄서기 내역을 알 수 있도록 할지 : 유저가 리뷰를 남겨야 할 무조건적인 책임은 없기 때문에 '리뷰 남겨야 할 줄서기를 줄서기 내역을 통해서' 알 수 있도록 함.
  
  치열한 토론 끝에 엄청 복잡한.. 구조의 ERD구조가 완성되었다. (이후에도 계속 변경된 것은 안비밀..)
[API 문서]
완성된 ERD 기반으로 정해진 기능을 페이지 별로 나누어 재 리스트업 한 뒤, 페이지별로 탭을 나누어 해당문서안에 기능 별 API를 정의하기 시작했다. RESTful 한 상태를 유지하면서 진행하려고 했지만, 우리가 기능별, 권한별로 api를 구분 짓하고 약속을 한 상태라 무조건 적으로 RESTful 하게 작성하기는 어려웠다. 따라서, 어떤 자원을 가지고 올때는 RESTful하게(GET /members, /members/3), 그게 아닌 단순히 기능(POST /login, /logout)을 나타 낼 때는 단수를 써서 자원을 가지고 오는 것과 그렇지 않은 것을 구분짓기로 약속했다.
[역할분리]
우리조는 원활한 협업을 위해 많은 토론을 나눴고, 결론적으로 '도메인'기준으로 분리하는 것이 좋겠다는 결론이 지어졌다. 기존에는 API에서 원하는 기능들을 개발하자는 방식으로 하려고 했지만, 그러다보니 파일 혹은 디렉토리의 분리라던지, 브랜치 별로 개발하는 것이 힘들겠다는 판단이 들었다. 컨플릭트가 매우 많이 날것 같다는 우려가 있었다ㅎㅎ 따라서, '도메인'기준으로 나누기로 했는데, '도메인'이라는 개념이 매우 추상적이었기 때문에 튜터님께 문의를 드려보니 '바운더리 컨텍스트'라는 개념을 말씀해주셨다. '바운더리 컨텍스트'는 어떤 서비스를 기능, 역할 단위로 쪼개어 그룹핑하는 개념이다. 따라서, 우리의 서비스의 기능과 역할을 쪼개보았다. 그러니 다음과 같은 그룹이 나뉘어 졌다.
- 줄서기 : 우리 서비스의 핵심 도메인
- 유저 : 서비스의 이용자. 관리자, 판매자, 고객이 될 수 있다.
- 레스토랑 : 줄서기의 대상이 되는 도메인
- 이벤트 : 유저에게 부여될 수 있는 도메인으로서, 서비스 전체적인 이벤트와 레스토랑 개인의 이벤트로 분리 할 수 있다.
팀원 5명이 각자 하고 싶은 도메인을 담당하게 되었고, 나는 인증,인가에 대한 지식이 부족하다고 생각하여 '유저' 도메인을 담당하게 되었다.

2-2. 개발 (23.02.13 ~ 23.02.22)

유저 도메인을 개발하면서 가장 인상 깊었던 기억은, 인증 인가 시 스프링 시큐리티를 거쳐야하는데, 우리조는 JWT 토큰을 이용한 인증인가를 사용했기 때문에, 토큰이 만료되는 상황을 고려해야했다. 이전 프로젝트에서는 다음과 같이 처리했다.

로그인 성공 시, 클라이언트에게 access token, refresh token 을 발급하고, 클라이언트는 해당 값을 로컬스토리지에 저장한다.
일반 요청에는 access token을 전달하고, 토큰 만료 시 특정 요청을 보내어 토큰 재 갱신 API에 요청을 할 수 있도록 한다.
재 갱신 API에는 refresh token을 발급하여 전달하고, 서버에서 refresh token의 유효여부를 판단 한 뒤, 유효하다면 새로운 access token을 발급한다.

하지만, 리프레시 토큰 탈취를 예방하기 위해 redis를 사용하여 다음의 플로우를 만들었다.

로그인 성공 시, 클라이언트에게 access token를 발급하고, refresh token은 redis에 저장한다.
일반 요청에는 access token을 전달하고, 토큰이 만료되면 redis에 refresh token이 살아있는지 확인한다.
refresh token이 있다면, 새롭게 access token을 발급할 수 있도록 성공응답을 보내고, 없다면 오류를 뱉는다.

위 플로우에서 갱신 API를 제외하고는 모두 만들어놓았다. redis연결도 끝내서, key-value 형태로 토큰을 저장하고, 토큰 만료 시 유효성을 redis를 이용해 유효성을 판별하여 결과값을 뱉어주는 것에 성공했다.

하루만에 기능구현을 끝내고 PR을 올렸는데, 리뷰가 굉장히 많이 남겨졌다. 이 때, dirty checking과 remove를 가로채서 soft delete 시키는 방법이 리뷰로 달렸는데, 해당 부분을 학습하고 적용하는 과정이 매우 재미있고, 흥미롭게 다가왔다.

동시에, 프론트작업을 실시했는데, 우리가 영감을 받은 테X블X이라는 서비스와 캐X테X블의 디자인을 어느정도 참고하고, meterial UI에서 제공하는 무료 아이콘들과 이미지를 가지고 작업을 시작했다. 개발해야할 페이지가 20개정도 되었는데, 2일에 걸쳐서 10개씩 작업하니깐 금방 마무리 할 수 있었다. 본래 리액트를 사용하려다가, props를 엄청 내리거나 올릴 필요도 없고, css 파일을 따로 분리하여 관리하기엔 시간이 부족하다고 생각하여, 한 화면에서 컴포넌트에 해당되는 모든 파일을 모아놓고 볼 수 있는 vue.js를 기술스택으로 선정하였다. 밤을 좀 새긴 했지만, 어쨋던 2일만에 화면작업을 완료했다.

API를 화면에 붙혀야하는데, 의도대로 백엔드에서 데이터를 내려주지 않고 있어서, 해당 도메인 담당자들께 데이터 형식수정을 요청드리고 그것이 코드리뷰를 거쳐서 적용 될 때까지 기다려야했기 때문에, 시간이 꽤나 걸렸다. 따라서, 비는 시간동안은 다른 사람의 코드를 찬찬히 보면서 리뷰를 드렸다. 문제가 발생할 우려가 있는 것, 컨벤션이 약속한 것과 일치하지 않는 것에 대해 주로 리뷰를 드렸다.

이후에 API를 모두 마친 뒤, 프론트와의 기본 연결작업을 마쳤다.

2-3. 중간발표 준비 및 발표실행 (23.02.23 ~ 23.02.24)

1차적으로 기본 구현 기능으로 계획해 놓았던, 모든 기능의 구현을 마무리했다. 지금까지 해 온 것 들을 기반으로 영상촬영 및 중간발표준비를 시작했다. 본래는 나혼자 진행하려고했는데, 생각보다 할 일이 많아질 것 같아서, 팀원들에게 분담을 제안드렸다. 협의 끝에 5개의 포지션으로 나눌 수 있었고, 각 포지션에 맞게 작업을 시작했다.

1. 영상촬영
2. 영상편집
3. 발표
4. 발표자료준비
5. 현재까지 기능 QA 및 개선사항 정리  # 아직 프로젝트가 끝나지 않았기 때문에 다음 단계 개발을 위해서 마련한 포지션

해당 과정을 기록하며 진행하였고, 문서화 하여 관리하니 팀원들이 불필요한 커뮤니케이션을 할 필요 없이 원활하게 업무가 진행되었다.

모든 팀원들이 자신의 역할을 충실히 이행해주셔서, 성공적으로 중간 발표를 마무리 할 수 있었다.

중간 발표 이후, 팀 차원에서 회고를 진행하였고, 남은 기간을 어떻게 진행하면 좋을지에 대한 토론을 진행했다. 팀원들도 직접 코드를 작성하고 프로젝트를 진행하시다보니, 조금은 계획이 바뀌신 부분들도 있었다. 따라서, 그에 따라, 모두가 하고 싶은 것을 충족하고 프로젝트의 완성도도 높힐 수 있도록, 다시금 전략을 수립했다. 역시나, 해당과정은 문서화 하여 시각적으로 모든 팀원들이 리마인드 할 수 있도록 했다.

총 3개의 스프린트로 쪼갤 수 있었고, QA 바탕으로한 기능보완 및 개선을 우선적으로 진행 한 뒤, 대용량 테스트를 진행하고자 했다. 우선적으로 각자 남은 업무에 대해서 리스트업하고 체크리스트를 만들었다.

2-4. 기능보완 및 개선 (23.02.27 ~ 23.03.05)

우리는 기능이 마무리 되었지만, 아주아주 디테일 한 부분들이 작업이 되어있지 않은 상황이었다. 예를들어 로그인이 풀린 뒤 대응이 안되어있는 상황이었다. 또한, 판매자 페이지도 UI가 아직 완성이 되지 않은 상황이라서, 그런 부분들에 대한 개선도 진행되어야 했다. 추가적으로, 예외처리, 배포, 테스트 코드 작성과 같은 부분들도 남아있었다.

내가 맡은 기능 중에서 가장 이슈가 되었던 부분은 토큰 만료로 로그인이 풀린 뒤, 그 뒤에 대한 대처방안이 없다는 것이었다. 나를 포함한 모든 팀원이 로그인이 풀리면 다시 로그인해야하는 상황을 겪었고, 이를 반드시 해결해서 부드럽게 흘러가는 서비스를 만들어야 했다.

또한, 나를 제외한 모든 팀원들이 프론트엔드 작업에 익숙하지 않아서, fetch나 ajax를 이용하여, 서버와 소통하는 일은 최대로 줄여야 했다. 기존에는 로컬스토리지에 저장해놓고 필요 시 마다 요청에 토큰을 담아서 사용하던 방식을, 팀원들을 위해 쿠키에 담는 로직으로 변경하였고, 그에 따라 jwt filter에 쿠키에서 토큰을 꺼내와서 검증하는 방식도 추가되었다.

또한, 팀원들이 갱신된 access token을 발급받기 위해 서버에 다시 요청하는일이 없도록 로직을 아래와 같이 변경하였다.

로그인 성공 시 access token과 refresh token을 발급한다. access token 은 헤더에 실어서 보내고, refresh token은 redis에 저장한다.
access token이 만료되면, refresh token이 유효한지 검증하고, 유효하다면 새로운 토큰을 발급하여 일단 로직을 수행하도록 한다.
응답 결과와 함께 헤더에 새로발급한 토큰을 싣어 보낸다.

이 과정으로 클라이언트에 특정로직만 추가되면 지속적으로 로그인이 끊기지 않게 되었다. 정말 극단적으로 1초뒤에 access token이 만료되어도, refresh token이 살아있다면 지속적으로 세션이 유지되는 것을 확인해보았다.

refresh token이 redis에 지속적으로 쌓이고 있는 상황에서 TimeToLive를 적용하여, 일정 시간이 지나면, 해당 토큰이 사라지도록 하였다.

위 개선 외에도, 프론트 단에 아직 연결되지 않은 로직들과, 변경된 이후로 바뀐 데이터 포맷에 대한 대응이 되지 않아서, 그것들을 연결하는데 일주일을 보냈다. 또한, 서버에 테스트 코드가 작성되어있지 않기에, 로직 수행에 대한 검증이 전혀되지 않고 있었는데, 팀원 전체가 테스트를 작성하여 빌드 시 한번더 검증하여 코드가 배포되어도 안전 할 수 있는 장치를 마련하는 시간을 가졌다.

2-5. 퍼포먼스 테스트 및 배포 (23.03.06 ~ 23.03.11)

이제 완전히 약속한 기능들에 대한 작업을 마치고, 이제는 정말 모든 기능들이 정상동작하는지 테스트 해보고 버그들을 잡는 수순을 밟아야 했다. 또한, 배포를 시켜 유저의 피드백도 돌려야 했었다. 따라서, 팀원 중 한분이 배포 및 CI/CD 연결을 담당해주시고, 다른 팀원은 기능테스트를 하고, 다른 팀원은 부하 성능 테스트도구인 nGrinder와 PINPOINT환경을 셋팅하는데 시간을 쓰기로 했다. 나는 유저 기능테스트 담당이라서, QA문서를 작성하고 기능테스트 하는 것에 집중했다. 또한, 배포 후 도메인 구매 및 ssl연결 등 디테일한 부분은 시간 단축을 위해 경험자인 내가 맡았다. 다른 조에서는 몇일씩 걸렸다고 했는데, 나는 경험이 있기에 금방 해내었다. 또한, 완전한 테스트를 하기 위해서는 더 많은 레스토랑 정보들이 필요했는데, 나는 쉘파일을 작성하여 for 문을 이용해 해당 쉘을 실행함으로서, DB에 전국 각지의 레스토랑 데이터가 쌓이게 만들었다. 그리고, 그렇게 생성된 더미데이터들을 실제 DB에 반영하였다. 꼬박 반나절이 걸렸다. 위의 작업들이 진행되는 동안 부하 성능 테스트 담당 팀원들은 해당 툴에 대한 학습을 한 뒤, 시나리오 스크립트를 작성하였다.

배포 작업이 마치고, 도메인 연결도 끝난 뒤 주변 지인들과 내배캠 수강생들에게 해당 프로젝트의 설문지를 돌렸다. 그와 동시에 모든 팀원들은 퍼포먼스 테스트 시나리오를 갖추는 것에 집중했다.

문제는 nGrinder라는 프로그램이 아무래도 환경적인 이슈가 있는 지 잘 동작을 하지않는 상황들이 발생했고, 또한, 스크립트를 직접 코드로 작성해야되다 보니, 지친 팀원들에게는 오히려 독으로 다가왔다. 따라서, 부하성능 테스트 도구를 조금더 시각화 되어있는 도구인 Jmeter를 이용하기로 하였다.

이렇게 셋팅을 마치고, 내배캠 측에서 요구하는 자료의 제출이 3.11일까지여서, 모든 팀원들이 해당 자료 제출을 위해 개발을 잠시 놓고 내 업무를 도와주셨다.

2-6. 최종 발표 준비 (23.03.11 ~ 23.03.14)

최종 발표를 원래 주말에 하려고 했는데, 시간 관계 상 주말동안 퍼포먼스 테스트를 해야했다. 우리의 셋팅이 너무 늦게 끝났기 떄문이다. 우리는 사전에 여러 테스트 시나리오를 고려했는데, 시간 관계 상 하나의 퍼포먼스에 집중하기로 했다.

그것은 바로 우리의 핵심기능인 '줄서기'였다. 10만개 이상의 트래픽을 동시다발적으로 한 레스토랑에 몰아넣어서, 어떻게 동작하는지 보고자 했다. 그렇다면, '이걸 이용해 우리는 어떤 개선을 할 것인가'가 우리 모두를 혼란스럽게 했다.

가장 먼저 우리가 들이부을 트래픽 수에 대한 기준을 잡아야했다. 대한민국 평균 외식인구, 서울 평균 외식인구 등등 외식인구에 대한 자료를 찾아보려고했는데, 다 2~3년 이상된 자료였다. 팀원 중 한 분이 테x블x어플리케이션에 대한 지표들을 찾아주셨고, 추가적으로 22년 말 기준으로 총 가입자 대비 MAU가 얼마나 있는지에 대한 기준도 찾을 수 있었다.

현재 우리 서비스에 mock 유저가 10만명이 있었기 때문에, 위 서비스 기준으로 인원기준을 잡으니 2.5만이라는 기준이 잡혔다. 또한, 일평균 트래픽이 2만이상이라, 우리의 서비스는 최소 2만이상을 감당할 수 있는 서비스여야 한다라는 기준을 잡을 수 있었다. 이렇게 실험에 대한 모수는 2.5만으로 잡게 되었다.

그다음 몇번 트래픽을 부어보니, PINPOINT 상에서 딱봐도 응답속도가 너무 느린것을 볼 수 있었고, 우리가 들이붓는 트래픽 대비 실제 줄서기 성공률도 매우 낮았다. 거의 8%가 안되었을거니깐.. 우리는 10번의 시도를 한 뒤, 어떤 기준으로 이 실험을 할 것인지 다시 얘기해보았다.

나는 지금 사용하고 있는 컴퓨터 사양이 좋지 않기 때문에, 트래픽 응답속도가 느린것이라고 판단했고, 그렇기에 일단 줄서기 성공률을 최대한으로 높이는게 좋겠다는 제안을 했다. 하지만, 다른 팀원은 '우리가 사용하고 있는 낙관적락의 설정때문에 서비스가 받아들이지 못하는 트래픽이 너무 많다보니, 설정 수치를 조정해가면서 일단 서비스 자체가 받아들이는 트래픽을 높이자'라는 제안을 했다. 다시 생각해보니, 1명의 성공률이 높다고 해도, 나머지 사람들이 이 1명의 성공을 위해 대기열조차 들어오지 못하는 상황이 말이안된다는 생각을 했다. 따라서, 팀원의 제안을 받아들이고, 들이붓는 트래픽대비 받아들이는 트래픽의 비율을 높히기로 했다.

또한, 응답속도가 너무 낮았는데, PINPOINT 내역을 확인해보니 getConnection 하는 속도가 너무나 느렸다. 이 문제는 미리 커넥션풀을 만들어 놓고, 서비스에게 할당하는 식으로 하면 해결된다고 했다. 하지만, 얼마나 미리 커넥션풀을 생성해야 그 수치가 적당할지 감이 오질 않았고, 팀원들과 실험을 통해 조정해보기로 했다.

팀원들과 많은 실험을 통해 적정한 양의 커넥션 풀과 락 설정을 정할 수 있었다.

많은 실험을 통해, 우리의 서비스가 아무리 트래픽을 100% 받아들인다고 해도, 100% 줄서기를 성공시킬 수 없는 구조였다는 것을 찾을 수 있었다. 따라서, 해결방법을 찾아보니, 메시지큐를 사용해서 성공률을 높일 수 있다고 했다. 따라서, 아래의 구조와 같이 변경하여 줄서기 성공률을 높혀보기로 팀원들과 협의를 본 뒤, 시간관계 상 실험을 마무리했다.

2-7. 최종 발표 (23.03.14)

실험이 마무리된 뒤, 우리 팀은 곧바로 해당 결과를 바탕으로 발표자료를 준비하기 시작했다. 중간 발표 때 PPT자료에는 너무 줄글이 많아서 가독성이 떨어지는 이슈가 있었다. 따라서, 나와 영상편집을 담당했던 팀원이 해당 페이지들을 이미지로 바꾸는 작업을 진행했다. 발표를 하시는 팀원과 실시간으로 해당 자료들을 공유하면서, 스크립트를 짜시는데 다시금 일을 하시지 않도록 신경썼다.

이렇게 각자의 업무를 한 뒤, 최종 리허설을 진행했다. 발표자에게 좋았던 점과 수정했으면 하는 점들을 피드백드리고, 최종발표 전까지 피드백을 반영하시는데 막히는 게 없으시도록 빠르게 팔로우업 해드렸다.

정신없이 준비하다보니.. 어느새 발표시간이 점점 다가오고 있었고, 드디어 3월 14일 오후 19시가 되었다!

2-8. 최종발표 결과

2등과 4표차를 내면서 최고의 프로젝트로 뽑혔다! 매니저께서 좋은 피드백도 많이 들어왔다며 공유도 해주셨다. 또한, 현업 선배개발자들이 우리조에 오셔서, 인상깊었다고 피드백도 많이 해주셨다.

이렇게 우리조는 23.03.14를 유종의 미를 거두며 마무리 할 수 있었다.

3. 프로젝트 회고

우리의 서비스가 규모가 세세하게 신경쓸 부분이 많았다보니, 자칫하면 많은 부분에서 삐끗했을 가능성이 높았던 프로젝트였다고 생각한다. 하지만, 팀원들이 모두 프로젝트에 애착을 가지고 있었고, 나 또한 이 프로젝트를 성공적으로 운용하는 것에 대한 집착이 있어서 성공적으로 결과물을 낼 수 있었어서 나름 뿌듯했다.

주요 기술을 하지못한 것에 대한 아쉬움이 많이 남긴하지만, 코드리뷰를 통해 대략적인 플로우는 알고 있기 때문에 너무 아쉽지는 않다.

하지만, 커뮤니케이션 부분이 정말 많이 아쉬웠던 것 같다. '기분이 태도가 되지말자'라는 주의지만, 컨디션과 일정의 압박이 있는 경우 내가 어떻게 변하는지 나도 모르는 내모습을 볼 수 있었다. 아무래도 나는 목표를 향해 계속 팀을 앞으로 밀어야 하는 역할을 가지고 있는데, 조금의 브레이크가 걸리려는 액션이 있을 때, 예민하게 반응했던 것 같다. 되돌아봤을 때, 조금만 여유를 가지고 둥글게 말했다면 어땟을까 하는 후회가 많다.

이전까지는 커뮤니케이션을 많이하지않던 환경에 있다보니, 내 이런 모습을 돌아볼 기회가 없었다고 생각한다. 그래서, 내배캠에서 운용하는 이 프로젝트 베이스 교육이 정말 맘에 들었다. 내 모습을 돌아보고 고치는 시간을 확보 할 수 있었기 때문이다. 또한, 같은 목표를 가지고 달려가는 동료들이 많기에, 커뮤니케이션을 많이많이 시도해 볼 수 있는 환경이 마련된 것도 너무 좋았다.

사람들을 많이 마주하면서 좋은 점은, 많은 타인들의 많은 장점들을 볼 수 있고, 그것들을 흡수 할 수 있었다는 점 이었다. 사람은 성장의 동물이기에, 최종프로젝트에서 했던 실수들을 반복하지 않음으로서 조금 더 '함께 일 하고 싶은 동료'에 가까워질 것 이다.