안녕하세요 오늘의집 시공서비스(O2O) backend 개발자 스테파노입니다.

지난 9월 1일(수) 오픈한 시공서비스 홈 개편 프로젝트 진행 과정을 통해 오늘의집에서 개발 프로젝트를 어떤 식으로 런칭하는지 설명드리고자 합니다. 모든 개발팀이 이와 동일하게 일하는 것은 아니지만 대동소이하다는 점 말씀드립니다.

프로젝트 진행 여부 검토

프로젝트 진행 여부는 아래와 같은 상황 시 검토됩니다.

• 데이터 분석을 통해 신규 서비스 혹은 대규모 서비스 개편이 필요하다고 판단될 때
• 운영/사업팀의 시장상황 분석 결과 서비스 변경이 필요할 때
• 서비스에 좋은 영향을 줄 아이디어가 짧은 일정으로 진행이 불가능할 때

이번에는 7월 초쯤 사업팀에서 먼저 의견을 주셔서 진행하게 됐지만, 대부분의 프로젝트는 위에 언급한 사유들로 진행이 결정되는 경우가 더 많습니다.

진행 여부가 확정되면 KPI 선정과 주요 피쳐(features)들을 정리합니다. 사업팀에서 원하는 주요 피쳐는 아래와 같았습니다.

• 광고 영역과 일반 영역의 확실한 분리
• 업체마다 노출되는 범위를 다양하게 지정할 수 있을것

서비스 스펙 논의

큰 스펙이 결정됐기 때문에 상세 스펙 논의를 진행합니다. 상세 기획 단계에서는 다음과 같은 것을 논의합니다.

• 서비스 방향에 나쁜 영향을 줄 만한 요소가 없는가
• 사용자에게 좋은 경험을 주는가
• 추가로 더 해볼 수 있는 기능이 있는가  

오늘의집의 프로덕트 팀은 목적 조직으로 구성되어 있어서 PO, 기획, 디자인, 개발이 모두 한 팀에 속해 있습니다. 실제 서비스를 만드는 사람들이 같은 조직에 있으니 위와 같은 논의를 수시로 만나서 할 수 있는 것이 큰 강점으로 느껴지곤 합니다.

데이터 분석

기능이 추가될 경우 어떤 영향을 줄 수 있을지 다양한 분석을 통해 시뮬레이션을 진행합니다.

기존 데이터만으로 측정이 불가능할 경우 A/B Test를 진행하기도 합니다.

아이데이션

시키는 일만 하면 오늘의집 구성원이 아니죠. 긴 논의 끝에 사업팀이 제시한 요구사항 이외에 다음 기능을 추가하기로 결정했습니다.

‘거리 및 활동 점수 기반의 소팅만 제공할 것이 아니라 다양한 소팅 및 필터링을 제공하자!’

원래 스펙대로라면 유료 업체를 우선적으로 노출할 수 밖에 없게 되고, 이는 나에게 꼭 맞는 업체를 찾고 싶은 유저의 선택권을 제한할 수 밖에 없게 됩니다. 따라서 다양한 sorting 및 filter 기능을 추가하여 유저가 원하는 업체를 쉽게 찾을 수 있도록 하였습니다.

기획서 작성 및 디자인

모든 피쳐들이 정리되면 기획서를 작성하고 디자인이 만들어집니다. 디자인은 figma를 이용하고 있고, 기획서는 사내 WIKI와 PPT 문서를 병행해서 사용하고 있습니다. 개발이 진행되면서 기획서가 변경되는 경우가 종종 있기 때문에 아래와 같은 versioning을 통해 관리합니다.

태스크 및 예상 시간 산정

기획서를 검토하면서 태스크를 뽑고 예상 시간을 산정합니다. (* 오늘의집은 jira를 이용해 태스크를 관리하고 소요시간과 이슈를 매일 아침 스크럼을 통해 공유합니다.)

태스크당 예상 시간 산정은 코로나19로 인해 많은 구성원들이 재택근무 중인 상황을 고려하여 https://planningpokeronline.com 을 사용해 온라인으로 진행합니다.

팀원 개개인이 예상한 작업 시간에 차이가 클 경우에는 왜 그렇게 생각하는지 의견을 물어보고, 비슷할 경우에는 평균 혹은 큰 값으로 산정합니다. 그리고 예상 시간 산정이 완료되면 오픈 일자를 검토합니다. 사업/운영 팀으로부터 문제 없다는 의견을 전달 받았으니 이제 열심히 달릴 일만 남았습니다.

설계

시공서비스에서는 주요 데이터베이스를 2020년부터 RDB에서 MongoDB로 전환하고 있습니다. 기존 서비스에 영향을 주지 않으면서 MongoDB 전환도 함께 진행해야하기 때문에 설계에 소요되는 시간이 많습니다.

Database 설계가 끝나면 API 스펙을 정의합니다. 저희 팀은 주로 swagger를 이용해 API 문서를 공유합니다. API를 만들면서 mock API도 같이 만들어서 frontend 개발자들에게 공유합니다. backend 개발자들이 database를 설계하는동안 frontend 개발자들은 layout 및 필요한 component를 설계합니다.

또한 설계 과정에서 기술적으로 도전해 볼 만한 것들이 있는지 검토해 봅니다. 이번에는 s2 geometry를 검토해서 적용해보기로 했습니다. 향후 요구사항의 변경과 서비스 방향에 적절하다고 판단했기 때문입니다.

s2 geometry를 선택한 이유는 아래와 같습니다.

• MongoDB에서 쿼리로 질의 가능
• 원, 다각형, 선 등의 표현 가능
• Multi Polygon을 이용한 특정 지역 설정 가능

s2 geometry에 대한 보다 자세한 설명은 https://s2geometry.io/ 을 참고해주시기 바랍니다.

사실 사업팀에서 요청했던 요구사항은 s2 geometry를 사용하지 않고 업체의 좌표만 저장한 뒤에 질의하는 것만으로도 구현이 가능했습니다. 하지만 추후에 동 단위로 설정하거나 특정 영역을 제외하는 기능을 추가하고자 할 때 대응이 힘들 것 같다는 우려가 있었습니다.

우아한 형제들에서 적용한 s2 geometry 기술 블로그를 참고하여 시뮬레이션 해본 결과 우리 서비스에 적절하다는 판단이 들었고, 이를 바탕으로 설계를 진행했습니다. (우아한 형제들 땡큐!) 이 내용은 추후에 다른 문서로 좀 더 자세히 공유하겠습니다.

개발

이제 본격적으로 자신에게 할당된 태스크들을 치는 시간입니다.

작업 순서

개발은 아래와 같은 순서로 진행합니다.

• github의 master branch에서 각자 jira issue 번호로 된 feature들로 branch를 생성
• 개발이 완료되면 PR을 보내서 code review
• 최소 2명의 approve가 있을 경우에만 develop branch에 merge

배포

merge가 되면 github action을 통해서 자동으로 dev server에 배포됩니다. github action에는 다음 작업들을 등록해 두었습니다.

• source build
• 공통 library일 경우 사내 nexus에 publish
• argoCD를 이용해 배포
• slack에 배포 완료 노티

MSA 전환

오늘의집은 대다수의 코드가 Ruby On Rails로 개발된 모놀리틱 구조로 되어 있습니다. 신규 기능 추가 시에는 MSA 전환도 함께 해서 기술 부채를 줄이고자 노력하고 있고, 이번 프로젝트에서도 함께 진행을 했습니다.

MSA 전환은 아래와 같은 과정을 통해 진행해 왔습니다.

0. 전환 준비

• 트래킹 고도화 : 분리되는 API들이 많아짐에 따라 어떤 요청이 왔고 어떻게 응답이 나갔는지가 중요해졌습니다. Request(header, parameter, body)와 Response(header, body)의 개인정보를 제거한 후 Athena에 저장해 실제 연동되는 데이터들을 모니터링 할 수 있게 했습니다. 또한 API 연동 시 Request header에 Trace ID를 함께 전달해 장애 발생시 원인 파악이 쉽도록 했습니다.
• 모니터링 강화 : Datadog과 Grafana를 이용해 metric을 관찰할 수 있게 했습니다.

1. 조회 API 분리

1단계는 아래처럼 database의 조회만을 MSA의 역할로 축소해서 적용했습니다. 비즈니스 로직에 대한 전환 부담이 너무 커서 Response DTO의 변환은 함께 진행하지 않았습니다.

2. 데이터 Owner 전환

Read뿐만 아니라 CUD에 해당하는 API들을 모두 MSA로 연동합니다. 이로써 data의 관리 주체가 이전됐기 때문에 Cache 관리 정책과 Event 발행도 이관했습니다.

3. Front Server(API Aggregator) 추가

이번 프로젝트에선 이 단계까지 적용됐습니다. front server를 추가하면서 DTO까지 모두 옮기고 기존 Rails 코드에는 인증만 남겨놨습니다. 비로소 Rails는 Proxy 형태로만 쓰이게 됐습니다.

4. 최종 단계

최종 단계는 물론 Rails를 없애는 것입니다. 현재 사내에서 활발하게 논의가 되고 있고, 아마도 Gateway Layer가 추가될 것으로 보여집니다. 또한 MSA API들간의 통신 protocol도 gRPC로 전환될 예정입니다.

QA

긴 시간 끝에 드디어 개발이 완료됐네요. QA팀에게 QA를 의뢰합니다. 사실 QA는 PDG 팀 내에서 PDG QA를 먼저 진행하고 나면 이후에 QA팀의 정식 QA가 진행됩니다. 기획자가 스펙을 가장 잘 알기 때문에 정식 QA 전에 주요 기능들에 대해 사전 점검을 한다고 생각하시면 됩니다.

PDG QA가 끝나면 정식 QA로 전환되고 이슈 폭탄을 맞게 됩니다. 정식 QA 전에는 기획자가 스펙을 QA팀에 리뷰해주고 QA팀은 기획서를 바탕으로 체크리스트를 작성한 뒤 테스트를 진행합니다.

흠.. 이상하게 보고되는 버그가 별로 없네요? (실제로 2건만 등록되었습니다.)

왠지 더 불안하지만 오픈을 준비합니다.

오픈 준비

오픈 준비는 QA가 완료되고 진행하는 것이 아니고 QA와 동시에 진행됩니다

• 쿼리 검수 → DBA
• 신규 eks 생성 요청 혹은 변경 요청 → DevOps
• 모델 공유 및 지표 요청 → DA
• 성능 테스트 → 인프라

그 외 유관 부서들에게는 기획서와 함께 실제 오픈 일자를 공지하기도 합니다. 이번에는 어드민 기능도 함께 추가되었기 때문에 사내 시연도 같이 진행됐습니다. 운영팀과 함께 시연 후 피드백을 받고 수정이 되는 경우도 있습니다.

오픈 및 모니터링

드디어 오픈 날입니다. 초긴장상태로 출근 후 전날 빌드해둔 소스로 실 서비스에 배포합니다. Production 환경의 배포는 자동배포가 아니라서 argoCD에서 직접 버튼을 눌러줘야 합니다.

서비스가 오픈되면 아래와 같은 툴들로 모니터링을 진행합니다.

• Sentry : error log
• Grafana : metric(cache hit, response time, http status code)
• Datadog : error log, access log, metric(slow query, response time)
• Athena : access log

지표분석

즐거운 지표 분석 시간이네요. 대폭발은 아니지만 기대한 정도는 나오는 것 같아서 다행입니다.

지표를 다양하게 뽑아보며 사용자 이탈은 없는지 어떤 항목에서 클릭이 많이 되는지를 점검합니다.

KPI에 나쁜 영향을 줄 수 있는 다른 것들이 보이는지도 같이 확인합니다.

회고

서비스를 오픈한 뒤에는 프로젝트 참가자들과 같이 회고를 진행합니다. 재택근무가 많은 요즘엔 miro를 주로 사용하고 있습니다. 

다들 같이 고생한 사이라 그런지 칭찬과 격려의 말이 많네요.

회고가 끝난 뒤에는 개선할 사항들을 논의해보고 action item으로 지정합니다. 이렇게 함으로써 다음 프로젝트에는 더 나은 과정을 경험하게 됩니다.

맺는 말

이 글을 작성하며 약 2개월 간 진행한 이번 프로젝트를 다시 돌아보니 저 역시 감회가 새롭네요. 이번 프로젝트도 MSA 전환과 동시에 진행되어 힘든 점도 있었지만 서비스가 점점 안정화 되어 가는 것 같아서 즐거운 마음으로 일한 것 같습니다.

함께 해준 팀원 분들 사사.. 아니 좋아합니다.