🔎 프로젝트 상황
1. 프로젝트 설명
위 이미지를 통해 알 수 있는 것처럼 무인 로봇 주방이 트럭 안에서 자체 앱으로 들어온 주문을 이동 중에 요리 후 배달하는 서비스입니다. 런칭 지역은 샌프란시스코 런칭 지역이며, 이러한 서비스의 특수성 때문에 유저가 주문을 넣는 client app부터 드라이버가 배달을 할 때 사용하는 driver app, 이 모든 것을 관리하는 admin web를 모두 자체적으로 개발해야했다.
2. 현재 개발한 프로젝트
driver app (React Native) : 드라이버가 배달 진행 시 사용하는 앱
client app (React Native) : 실제 유저가 음식을 주문하는 앱
admin web (React) : 관리자가 드라이버, 트럭, 재고, CS 대응, 이벤트 생성 등 우리 서비스를 컨트롤하는 전체 웹 페이지
3. 프로젝트 주요 기능 및 성격
- driver app (React Native)
성격) client app을 통해 받은 주문을 실시간으로 확인하고 배달을 처리하기 위한 앱이다. 트럭은 이동하며 조리와 배달을 진행한다. 트럭이 주문을 받고, 조리 시작 시간을 설정하고, 배달 완료 시간을 계산하기 위해서는 트럭이 실시간으로 주문 리스트를 갱신하여야 하고, 트럭의 위치값을 업데이트하는 것이 중요하다. 이를 위해 socket i.o를 통한 실시간 주문 리스트 갱신, 트럭의 상태 업데이트, 트럭의 위치값 업데이트, socket이 끊겼을 경우, 주문 리스트가 갱신되지 않는 경우, 위치값이 업데이트 않는 경우에 초점을 맞춰 작업하였다.
주요 기능) 로그인, 소켓 연결, 실시간 주문 리스트 갱신, 트럭 상태 업데이트, 트럭 위치값 업데이트, 사진 촬영, 배달 완료 처리, 재고 확인, 비상 상황 요청, 쉬는 시간 요청, 운행 시작, 운행 종료
- client app (React Native)
성격) 배달의 민족, uber eats, doordash, yep과 같은 성격과 기능을 가진 음식 배달 앱이다. 다만, 우리 메뉴만을 주문할 수 있다.
주요 기능) 로그인, 소셜 로그인, 주소 필터링, 메뉴 리스트, 장바구니, checkout 계산, 실결제 , 주문, 주문 취소, 영수증, 예약 주문, 배달 진행 현황, 리워드, 쿠폰, 리뷰, CS 등
- admin web (React) :
4. 프로젝트 기간(기획 ~ 현지 테스트 ~ 런칭)
11개월 (2023년 4월 ~ 2024년 5월)
5. 프로젝트 인원
프론트엔드 개발자(본인) 1명, 백엔드 개발자 1명, 디자이너 1명, 기획자 및 PM 없음
최종 결정자 : CEO 1명, CFO 1명
(프로젝트 일부 기능은 외주 진행)
6. 프로젝트 진행상태
- driver app (React Native) : 구글 플레이 스토어, 앱 스토어 등록 완료 / 현지 테스트 후 런칭 완료 / 사용자 경험 개선중
- client app (React Native) : 구글 플레이 스토어, 앱 스토어 등록 완료 / 현지 테스트 후 런칭 완료 / 로그 관리 및 에러 대응 중
- admin web (React) : aws cloudfront로 배포 완료 / 현지 테스트 완료
🚨 문제점
언어 선택과 기획도 되지 않았던 제로 베이스에서 두 가지 앱을 출시하고, 어드민 웹을 배포하는 과정에서 여러 어려움이 있었다.
기획자 및 PM의 부재로 개발자가 직접 기획과 정책을 세워야 했고, 국내 출시가 아닌 미국 출시를 준비하면서 해당 국가의 특수성을 고려해야 했다. 예를 들어, 썸머타임, 인증번호 발송 정책, 세금 계산법, 결제 모듈 업체 선정, 좋지 않은 인터넷 환경 등을 신경 써야 했다. 또한, 앱 출시 경험이 없는 1년 미만 경력의 주니어 개발자 2명(프론트엔드 1명, 백엔드 1명)과 함께 개발을 진행하며, 각 스토어 계정 생성부터 초기 세팅, 심사 요청, 거절 사유 대응 등을 혼자 처리해야 하는 리소스 문제도 있었다.
하지만 무엇보다 우리 팀 그리고 나를 힘들게 한 문제는 '커뮤니케이션 문제'였다. 리소스 부족이나 기술적인 문제보다 더 큰 장애물이었다.
1. 개인 단위로 이뤄지는 소통
가장 큰 문제는 소통이 개인 단위로 이루어지는 경우가 많다는 점이었다. 각기 다른 성격의 채널이 있음에도 불구하고, 개인 단위로 소통하고 일을 진행하며 결정을 내리다 보니 팀원마다 프로젝트에 대한 이해도가 달랐다. 이로 인해 동일한 작업을 두 번 하게 되는 경우가 빈번해졌다. 리소스가 부족한 상황에서 같은 일을 반복하는 것은 매우 비효율적이었다.
2. 업데이트 규칙의 부재
다음으로, 업데이트 규칙이 없었다. 이는 개인 단위로 요청되고 진행되었다. 우리 앱 팀은 리더가 없는 상태에서 트럭 엔지니어 팀의 리더들과 직접 소통하며 수정 요청을 받았다. CFO나 CEO와 같은 운영진의 요청 또한 직접적으로 전달되었다. 이러한 구조에서 개인에게 업데이트 요청이 이루어지고 진행되다 보니 팀원들 간의 오해가 생기고, 프로젝트에 대한 이해도가 달라져 동일한 작업을 여러 차례 반복하게 되었다.
3. 흔들리는 기획과 정책
마지막으로, 기획과 정책이 자주 변경되었다. 보다 정확히 이야기하자면, 개인의 요청으로 기획이 수정되고 하나의 피드백으로 정책이 바뀌었다. 초기 서비스에서는 기획이 변경되고 수정되는 것이 자연스러운 프로세스이지만, 합당한 이유 없이 기획이 수정되고 피드백에 대한 검증 없이 정책이 변경되는 것은 큰 문제였다.
🛠️ 문제 해결 방법
앞으로 남은 스프린트를 진행하는 데 있어 방향성을 잃지 않도록 위의 문제들을 해결하는 것이 중요하다고 생각했다. 이러한 이슈와 인시던트를 잘 대응하는 것이 기술 조직에 매우 중요하다고 판단했다. 또한, 이러한 인시던트는 우리 조직만의 문제가 아니라 조직 전체가 함께 고민해야 하며, 경영진과 실무자들의 시각차를 계속해서 좁혀 나가는 것이 중요하다고 생각했다.
그래서 아래와 같은 대응 방법들을 고민하였고, 팀원들과 협업하는 다른 분들과 미팅을 잡아 해당 안건을 다루었다. 아래와 같은 프로세스를 설정하여 처리해보는 것이 어떨지 제안하였고, 팀원들도 해당 프로세스를 적용해보는 것이 좋다고 생각하여 우리 조직에 적용하고 있는 중이다.
진행하던 기술적인 이슈 외에 커뮤니케이션 문제를 해결하는 데 리소스를 투입하는 것에 부담을 느끼는 분들도 계셨고 쉽지 않았지만, 결론적으로 현재는 오히려 커뮤니케이션 이슈가 줄어들어 두 번 일하는 경우가 없어지고 여러 가지 이슈가 동시다발적으로 생겨도 부담 없이 각각의 담당자가 본인이 맡고 있는 스프린트에만 집중할 수 있게 되었다.
📍 각각의 채널에서 소통하자
[문제점]
개인 간 소통을 하니 팀원 각각의 이해도가 달라 일을 두번 하고, 추후에 이 문제를 인지했을 때 책임을 전가하는 문제가 생겼다.
[적용 프로세스]
이슈가 생기면 기존처럼 개인간 소통하지 않고 각각의 채널에 인시던트를 공유한다. 각각의 담당자들이 함께 소통한다. 발생 시 "누가 문제를 일으켰냐"에 집중하기 보다는 "왜 문제가 발생했나", "어떻게 대응할 것인가", "어떻게 재발 방지를 할 것인가"에 집중하자. 이슈를 모두 인지했다면 지라에 스프린트로 등록하고, 담당자를 지정하자. 만약, 개인 간 소통을 한 경우에는 슬랙 채널에 공유하자.
📍 업데이트 프로세스를 세우자
[문제점]
개인이 요청한다고 하여 바로 업데이트하고 기존의 스프린트 작업 순서를 변경하니 실무자들이 작업하는데 어려움을 겪었으며, 앱의 프로세스도 꼬이는 문제가 생겼다.
[적용 프로세스]
개인이 개인에게 요청하였다고 하여 바로 업데이트 하거나 수정하지 않는다. 이슈로 만들어 미팅을 잡는다. 미팅 인원은 앱 팀 실무자, 업데이트 요청팀 실무자, 경영진을 참석시킨다. 모두가 이슈로 인지하고 업데이트 하는 것이 필요하다고 판단된다면 지라에 이슈로 등록한다. 핫픽스인 경우에만, 최우선 스프린트를 진행하며이외에는 마지막에 처리하는 스프린트로 등록 후 처리한다. 만약 스프린트 작업 순서를 변경하고자 한다면, 미팅을 잡아 변경한다.
📍 문서화를 하자
[문제점]
앱의 프로세스, 기능, 정책 등이 자주 변경되나 피그마로만 소통하니 팀원들간에도 이해도가 다를 뿐만 아니라 경영진에서도 이해도가 달랄 이를 바로 잡는데 많은 리소스를 투입해야했다.
[적용 프로세스]
문서화를 하자. 피그마 뿐만 아니라 정책 정의서, 유저 플로우, 화면 설계서 등을 작성하여 이해도를 잡는데 들어가는 리소스를 최소화하기로 하자. 그래서 현재 정책 정의서, 유저 플로우 등을 정리해나가는 중이다.
🎁 내가 얻게 된 것
사실만을 기반으로 작성하다 보니 새로운 서비스를 기획하고 런칭하며 운영하는 과정에서 생겼던 이슈와 그 해결 과정이 간단하게 느껴질 수 있지만, 실제로는 스프린트가 많은 상황에서 기술적인 이슈뿐만 아니라 커뮤니케이션 관련 이슈까지 생기면서 그 문제를 해결하는 과정이 결코 쉽지 않았다.
그러나 이러한 문제 상황을 해결해 나가는 과정에서 많은 것을 얻을 수 있었다. 마지막으로, 그 과정에서 얻게 된 것들에 집중하고 이에 대해 정리해보고자 한다.
📍 동시다발적으로 일어나는 여러 이슈에 대한 우선순위 정리 및 관리 문제를 극복한 경험
📍 새로운 서비스의 기획부터 개발, 운영까지 모든 사이클을 관리해 본 경험
📍 논리를 바탕으로 다양한 이해관계자(디자이너, 백엔드, 경영진, 외부 업체)와 커뮤니케이션 및 협업한 경험
📍 조직 내부에서 니즈 혹은 문제를 파악하여 주도적으로 기획해본 경험
