Contents
0. 시작하기 앞서
1. 주제 범위 좁히기
2. 주제는 "배달의민족 중계 서비스"로 정했습니다.
3. 유저 플로우를 정의했습니다.
4. 마치며....
5. 참고 자료들
0. 시작하기 앞서
팀프로젝트 주제 선정은 왜 중요하고, 왜 어려울까요?
우선 주제는 명확할수록 개발 과정에서 협의가 순조롭게 진행될 수 있기 때문입니다.
또한 주제는 프로젝트 이름에 반영되고 프로젝트 이름은 git repo와 소스 코드에 조금이라도 반영되기 때문입니다.
저는 과거 여러 프로젝트들을 거치면서 나름의 주제 선정 전략을 다듬어왔고
이번 프로젝트 주제를 기대 이상으로 순조롭게 정할 수 있었습니다.
주제도 팀 전체가 만족하는 것으로 보입니다. (please!)
그래서 오늘은 이번에 적용해본 주제 선정 과정을 여러 단계로 나누어 소개해보겠습니다.
1. 주제 범위 좁히기
기존 서비스 클론 vs 새로운 서비스 개발
주제 회의 결과 기존 서비스를 클론하기로 협의되었습니다..
클론 시 얻을 수 있는 장점은 "공통된 최선의 선택의 기준"을 세울 수 있다는 것입니다.
예상하기를 서비스 분석 과정부터 프로젝트 후반부까지
많은 선택의 순간들이 찾아올 것이며,
이때, 타겟 서비스의 존재는 팀의 훌륭한 가이드가 되리라 믿습니다.
물론 클론코딩으로 경험의 차별화를 줄 수 있을지 걱정될 수도 있습니다.
하지만 "프로젝트를 시작합니다" 부분에서도 소개한 목표들을 성공적으로 반영했을 경우
그 결과는 충분히 만족스러울 것이라 생각합니다.
주제 범위는 팀의 공통분모로
공통분모 적용 기법을 통해 민주주의적인 결정을 하고자 했습니다.
각자 원하는 분야와 서비스들을 나열한 후,
그중 공통되는 부분을 찾아 선정하는 방향으로 진행했습니다.
제시된 여러 분야들 중 공통분모는 배달과 중고거래였습니다.
그래서 존재하는 서비스들 중 팀원들이 많이 접해본
배달의민족과 당근 마켓을 비교 후 결정하기로 했습니다.
배달과 중고거래 서비스를 선정한 이유는?
첫째, 공감대를 형성하기 용이합니다.
두 서비스 모두 사람들의 많은 관심을 받는 서비스들입니다.
그만큼 개발과정에서 공통적으로 이해하는 부분이 많을 것이니 협력하기 수월합니다.
또한 프로젝트를 소개하거나 설명해야 하는 상황에서 적절한 공감대를 형성하기도 유리하다 생각했습니다.
둘째, 논리적으로 타당한 테스트 케이스 시나리오를 도출할 수 있습니다.
배달과 중고거래 모두 다들 익숙하니 그만큼 테스트 코드 한 줄이라도 더 나오겠지요?
또한 부하 테스트시에도 이벤트, 할인 행사 등 현실적인 시나리오를 쉽게 생각해볼 수 있습니다.
셋째, 참고할 서비스들이 많습니다.
국내에 많은 배달과 중고거래 서비스가 이미 존재하기 때문에 여러 관점에서 서비스를 분석해볼 수 있습니다.
넷째, 위치기반 및 실시간 서비스를 경험해볼 수 있습니다.
요즘의 웹 서비스는 정보전달 이상의 의미를 가지고 있다 생각합니다.
그중 이웃과 이웃을 연결하고 고객과 사장님을 연결하는
위치기반 실시간 서비스를 경험하고자 합니다.
2. 주제는 "배달의민족 중계 서비스"로 정했습니다.
한 주 동안 배달의민족과 당근 마켓 클론 시 구현하게 될 기능들을 취합했습니다.
그리고 프로젝트를 통해 팀원 각자 무엇을 얻어갈 수 있는지를 고민했습니다.
최종적으로 "배달의민족 중계 서비스"를 선택하게 되었는데요,
그렇게 도달하게 된 과정을 부분 부분 나누어 설명드리겠습니다.
"배달의민족" 서비스를 선택한 이유
생각해보면 중고거래 대비 팀원들이 배달 서비스를 이용하는 빈도가 상대적으로 더 높습니다. 이 점은 테스트 작성, 개발 협의 과정에서 긍정적으로 효과를 낼 것으로 생각되었습니다.
그리고 배달의민족 서비스는 일 평균 트래픽, 시간별 분포도 등 성능적으로 벤치마킹할 부분들이 많이 공유된 점도 반영되었습니다.
***Tip : 주제 선정 과정에서 어느 서비스가 좋다 나쁘다는 의견은 발생하지 않았습니다.
전체 서비스 vs 하나의 유저 플로우
첫 목표로 구현할 서비스의 범위를 고민했습니다.
서비스 전체를 구현하려는 경우와 하나의 유저 플로우에 우선적으로 집중할지를 저울질했습니다.
전체 서비스를 구현하게 될 경우를 생각해보겠습니다.
예를 들어 배달의 민족 서비스 전체를 구현하게 될 경우,
제한된 시간 동안 많은 유저 시나리오들을 구현하느라 시간에 쫓겨 좋은 코드가 나오기 힘들고 그로 인해 결과물의 성능은 상대적으로 떨어질 것이라 생각이 되었습니다.
하나의 유저 플로우를 목표로 잡고 시작하면 어떨까요?
우선 좋은 코드를 작성하는 시도를 더 많이 해 볼 수 있습니다.
테스트 코드도 더 많이 작성할 수 있겠지요.
성능적인 고민도 더 깊게 해볼 기회가 있을 것입니다.
또한 시간적 여유가 된다면 새로운 유저 시나리오를 추가해볼 수 있습니다.
신규 기능/유저 플로우를 추가하는 과정에서 기존 서비스의 어느 부분을 추상화하고 어느 부분을 코어 모듈로 남겨둘지를 고민하는 등 실제 분산 환경의 개발 프로세스를 경험해 볼 수 있을 것이라는 멘토님의 의견도 긍정적으로 받아들였습니다.
그래서 프로젝트의 스코프를 좁혀 배달의민족 서비스의 여러 부분들 중 하나를 고르기로 결정했습니다.
배달의민족의 "중계 서비스"를 선택한 이유
위 이미지는 "배민 플랫폼실"에서 소개한 중계시스템팀의 역할입니다.
중계 서비스란 고객님이 주문을 한 이후의 프로세스를 담당하는 부분인데요, 주요 기능들로는 주문현황, 주문 접수, 배달 대행사 연동, 정보 암호화 등이 있습니다.
배달의민족의 많은 서비스들 중 "중계 서비스"를 선택한 이유는 서비스의 역할과 관련이 있습니다.
이 기능들은 "프로젝트를 시작합니다"에서 소개한 프로젝트의 목표에서 소개한 목표들과도 연관성이 높습니다.
이런 이유로 배달의민족 중계 서비스를 주제로 정하게 되었습니다.
3. 유저 플로우를 정의했습니다.
주제를 선정하고 난 후, 서비스의 전체적인 흐름을 정의했습니다.
참고한 자료 목록은 마지막 "참고자료들" 부분에 정리해두었습니다.
중계 서비스 관련 자료들은 정말 많이 찾을 수 있었고 놓고 보니 양은 2배 정도 더 많았습니다.
유저 플로우 정의의 핵심 사항을 "중계서버가 제공하는 서비스"에 두고 핵심적인 기능들로 추려내었습니다.
이후 프로젝트 개발 과정에서 위 다이어그램이 좋은 가이드가 되기를 간절히 소망하며 초기 서비스 분석을 마무리했습니다.
4. 마치며....
이렇게 저희는 배달의민족의 중계 서비스 개발을 결정하고 유저 플로우를 정의했습니다.
돌이켜보면 멘티님과 멘토님의 적극적인 의사표현 덕분에 순조롭게 진행할 수 있었던 것 같습니다.
아쉬웠던 점이라면 프로젝트 회의 진행 관련 부분들이 좀 있겠네요.
회의시간 때 사전에 이야기된 주제들 외에 제가 추가로 제안하는 부분들이 있었습니다.
당일 이야기하는 대신 미리 공유할 수 있는 채널을 만들어 두었으면 팀원분들이 사전에 생각해볼 여지를 가질 수 있지 않았을까 싶습니다.
다음부터는 개선할 수 있기를 ^^
앞으로의 프로젝트 개발 과정도 기대가 되는군요.
오늘은 20000...!
5. 참고 자료들
사장님 튜토리얼
중계시스템팀 채용공고 참고자료
이미지 출처
'in-bob-we-trust' 카테고리의 다른 글
| [Reactive한 라이더위치 기능구현 ] 요구사항 분석부터 위치정보 저장 기능 구현까지 (0) | 2022.01.13 |
|---|---|
| Github 프로젝트 & Intellij 전반에 걸쳐 Google Java Style Guide 를 강제하기 (0) | 2022.01.09 |
| 중계서비스 Swagger 도큐먼트 툴 적용 + 단점 보완 (0) | 2021.12.13 |
| 배달 중계서비스를 설계하고있습니다. part.1 (0) | 2021.12.10 |
| 프로젝트를 시작합니다. (0) | 2021.11.28 |
