[배민스토어] 서비스개발 팀장의 일반셀러 프로젝트 진행기
배달의민족 앱에는 ‘배민스토어’라는 서비스가 있습니다. 유명 브랜드부터 동네 상점까지 다양한 가게의 상품들을 배달하는 서비스예요.
이 글에서는 배민스토어 서비스를 확장하면서 두 마리 토끼(비즈니스와 기술)를 잡기 위해 고군분투하는 배민스토어서비스개발팀의 에피소드와 그 과정에서 만들어간 팀 문화에 대한 이야기를 해 볼까 합니다.
배민스토어란?
먼저, 배민스토어는 어떤 서비스인지 소개해 보겠습니다.
필요한 모든 것을 오늘 문 앞으로
“필요한 모든 것을 오늘 문 앞으로”
배민스토어는 유명 브랜드의 신상품부터 우리 동네 상점까지 가게에서 구매할 수 있는 다양한 상품들을 문 앞까지 배달하는 서비스입니다.
편의점, 디지털, 뷰티, 패션, 꽃, 리빙용품 등 다양한 카테고리의 상품을 2시간 이내에 배달해 주죠.
음식 배달뿐만 아니라 우리 동네의 모든 상품을 배달해 주자는 목표로 퀵커머스라는 새로운 시장을 만들고 있어요.
간단히 설명하면 유명 브랜드부터 동네 상점까지 다양한 가게의 상품들을 배달하는 서비스입니다.
여러분들이 필요한 것이 있다면 무엇이든 오늘 문 앞으로 받아보실 수 있어요!
이제 앱을 한번 살펴볼까요?
배달의민족 앱을 켜면 배민스토어에 접속할 수 있습니다. 현재 위치에서 배달 가능한 여러 가게와 상품들이 보일 거예요. (가게는 지역별로 다를 수 있어요.)
배민스토어에 입점한 업체를 셀러라고 합니다.
작년까지는 브랜드셀러 위주로 서비스했고 올해부터는 일반셀러를 도입해 서비스를 확장해 나가고 있어요. 서비스를 어떻게 확장해 나갔는지 자세히 살펴보겠습니다.
일반셀러 도입 프로젝트 배경
올해 초부터 4개월간 일반셀러 도입 프로젝트를 진행한 결과 이제는 일반셀러의 다양한 상품들도 고객의 문 앞까지 배달할 수 있게 되었습니다.
결론만 얘기하면 참 쉬운 것 같죠? 진행 과정은 시작부터 쉽지 않았어요.
왜냐하면 일반셀러가 무엇인지, 일반셀러를 왜 도입해야 하는지 처음에는 잘 이해되지 않았기 때문이죠! (항상 처음은 어렵더라고요.)
일반셀러란?
일단 일반셀러를 이해하는 것부터 시작했습니다. 개발팀에게는 든든한 기획팀이 있어서 아주 잘 설명해 주셨어요.
- 일반셀러란
- 본사를 가진 프랜차이즈 브랜드가 아닌, 우리 동네에서 만날 수 있는 소상공인(로컬) 가게들을 의미합니다.
- 상품 등록, 프로모션 진행, 정산 등의 과정을 본사가 아닌 개별 사장님과 진행한다는 점이 특징이에요.
- 예시) 브랜드셀러 : CU, LUSH / 일반셀러 : ㅇㅇ축산, ㅁㅁ청과, ㅇㅇ두부
설명을 들어보니, 우리 집 주변에 있는 일반 동네 상점들을 일반셀러라고 하는 거군요. 그런데 어떤 장점이 있길래 이렇게 큰 프로젝트를 해서라도 일반셀러를 빠르게 도입하려는 걸까요?
- 왜 일반셀러를 도입하는지?
- 배민스토어는 퀵커머스 경험을 일상화하려는 목표를 가지고 있었는데요. 브랜드 셀러만으로는 이 목표를 이루는 데에 한계가 있었어요.
- 일반셀러를 입점시켜서 다양한 카테고리의 셀러 풀을 확보하고, 도심 외곽지를 포함해 브랜드 셀러가 없는 지역에도 촘촘한 커버리지를 확보할 수 있을 것으로 기대했습니다.
이렇게 간단히 설명드리긴 하지만, 이미 일반셀러에 대한 사업적 검토와 기획, 정책에 대한 무수한 논의가 있었다고 하더라고요.(정말 대단…)
수많은 기술 부채
일반셀러 도입이 필수인 비즈니스 상황에서, 우리 팀이 담당하는 시스템에는 많은 기술 부채가 산재해 있었습니다.
- 초창기 배민스토어는 다른 서비스의 기반 위에서 빠르게 만들어졌어요. 그러다 보니 레거시들을 품고 있었던 상태였는데, 서비스를 분리할 때도 이걸 개선하지는 못했었어요.
- 배민스토어는 작년에 전시 도메인과 커머스플랫폼 도메인으로 나뉘어, 앱에서 보이는 부분과 커머스플랫폼이 별도로 개발 및 유지보수 되었는데요.
- 전시에서 커머스플랫폼을 직접 API로 연동했기 때문에 급격한 트래픽이 몰리면 커머스플랫폼 내부까지 영향을 받는 구조였어요.
- 앱에 제공하는 API의 느린 응답속도로 인해 고객 사용성이 좋지 않았어요.
- 상품 목록들 중 페이징 처리가 없는 지면들도 존재했습니다.
- 등등… (
숨어있는 버그들)
무엇부터 해야 할지 많이 고민되었습니다.(할 것은 많고…)
우선, 일반셀러 도입은 비즈니스 필수 요구사항이기 때문에 가장 중요한 1순위 목표로 생각했습니다. 하루빨리 일반셀러를 도입해서 셀러와 상품 구색을 확대하고 고객에게 더 나은 쇼핑 경험을 제공해야 하니까요.
또한, 기술적 개선도 중요한 상황이었습니다. 일반셀러를 도입해도 사용성이 너무 떨어지면 고객은 불편함을 느끼고 서비스를 사용하지 않을 것이 분명했어요.
그래서 쉽지 않겠지만,
비즈니스 속도를 늦추지 않으면서 시스템 개선에 도전하기로 결정했어요.
그럼 저희는 기존 서비스에 큰 영향을 주는 비즈니스 과제를 진행함과 동시에 어떻게 기술적 개선을 이룰 수 있었을까요?
프로젝트를 진행하면서 4가지 항목을 가장 신경 썼는데요. 하나씩 설명해 보겠습니다.
- 프로젝트 목표와 범위 설정하기
- 팀 문화와 분위기
- 명확한 역할 부여
- 플랫폼에 올라타기
프로젝트 목표와 범위 설정하기
목표 설정하기
프로젝트를 시작하기에 앞서 프로젝트 목표에 대해 생각해 봤습니다. 일정 내에 무엇을 할지 정리하고 우선순위를 정해야 순서대로 일을 진행할 수 있으니까요. 그런데 프로젝트의 목표를 설정하는 것은 쉽지 않았어요…!
비즈니스 적으로는 ‘일반셀러 도입’ 만 진행하면 되지만, 저희가 시스템을 이대로 놔두면 프로젝트 오픈 후, 대규모 트래픽을 받거나 새로운 기능을 추가할 때, 현재 시스템에 발목을 잡힐 것이 분명했습니다.
일반셀러 기능들을 추가하면서, 기존 시스템을 필수로 개선해야 했어요.
아래 표는 일반셀러 프로젝트를 시작할 때 팀에 가이드를 하면서 작성했던 목표 부분이에요.
목표를 3개로 압축하고 이것만은 집중해서 꼭 진행해야 한다고 생각했습니다. 그 외 다른 일들은 못해도 괜찮으니 프로젝트 오픈 이후에 하나씩 챙기기로 했어요.
선택과 집중을 해야 프로젝트를 잘 오픈할 수 있겠더라고요. (사실 이 3가지 목표도 다 할 수 있을지 걱정이었죠)
범위 설정하기
목표를 정했다면 이제 최종 스펙을 확정 지어야 합니다. 프로젝트는 보통 오픈 일을 확정하고 진행하게 되는데요. 이럴 때 과한 욕심을 부린다면 오픈 자체가 힘들어질 수 있어요. 그렇다면, 최종 스펙을 어떻게 결정하는 것이 좋을까요?
개발 스펙과 비즈니스 스펙을 나눠서 생각해 봤습니다.
먼저, 개발 스펙은 정리하는 것이 크게 어렵지 않았습니다.
기술적으로 가능한 부분을 검토하고 설계, 개발하면 되니까요. 너무 쉽게 얘기하는 걸까요? 기술 검토는 경험이 쌓여있어 조금은 쉽게 정리되기도 하고, 저희가 선택 가능한 부분이 많아서 조율하기도 어렵진 않았어요.
그런데 비즈니스 스펙을 검토하는 것은 꽤 힘들었습니다.
개발팀에서는 비즈니스 요구사항을 사업팀으로부터 직접 듣기보다 보통 기획팀을 통해 정리된 상태로 공유 받습니다. 그래서 날것(?)의 목소리를 듣기 어렵기도 하고, 어느 정도 정리된 버전의 요구사항을 듣다 보니 기획 내용을 넘어서는 논의를 하기는 더욱 힘듭니다. 또한, 오픈 일이 확정된 큰 프로젝트에서는 비즈니스 스펙을 MVP에 어디까지 포함시킬 것인지가 프로젝트의 난이도를 크게 좌우하기 때문에 개발팀은 굉장히 신경 써서 스펙을 검토해야 합니다.
또한, 저희 팀은 백엔드 개발자로만 이루어진 기능 조직입니다.
기획 리뷰 후, 백엔드를 설계하고 개발 완료하면 끝~ 이런 과정을 반복하다 보니 기획자만 바라보고 일하는 경우가 많아요.
그런데 이렇게 기획 내용을 보고 그대로 개발하기만 한다면, 더 좋은 결과를 만들어낼 수 있음에도 불구하고 조금은 아쉬운 결과물을 만들어내는 경우가 있습니다. 수동적으로 개발하게 되니 확장성이 고려되지 않아 요구사항이 추가될 때 빠르게 대응하지 못하기도 하고요. 기능의 연속성을 생각하지 못해서 기능이 추가되면 다시 새롭게 만들어야 할 때도 있습니다.
그래서 이번엔 협업 부서와 전체 흐름을 더 넓게 고려하면서 검토하기 시작했습니다. 사업/기획/디자인/개발(앱,웹,백엔드)/QA 등 전체 흐름에서 협업 부서의 요구사항과 방향성 등을 더 면밀히 살피고, 오픈 시나리오까지 생각해 보았어요.
아래 그림은 이전보다 더 신경 썼던 부분을 표현해 본 그림이에요.(붉은색) 앱과 웹팀과도 평소보다 더 많은 커뮤니케이션을 나눴어요.
사업의 요구사항을 초기에 대략적으로라도 공유 받아 기획팀과 함께 검토하다 보니 똑같은 기능이어도 더 다양한 설계를 생각해 볼 수 있었습니다. 그리고 가끔은 기획팀에서 기획하는 과정에서 요구사항을 서비스에 어떻게 적용해야 할지 판단이 어려운 경우도 있었는데요. 이럴 때는 개발팀에서 먼저 시스템적으로 고려할 만한 부분을 공유함으로써 기획/개발팀이 함께 비즈니스와 시스템을 검토하여 최적의 스펙을 도출할 수 있었습니다. 이렇게 더 넓은 협업 부서를 대상으로 스펙 검토를 진행해 보니 우리가 어떤 비즈니스 기능을 MVP에 포함시키고, 어떤 기술 과제를 추가하고 제외할 것인지 더 잘 판단할 수 있었던 것 같습니다.
한정된 리소스 내에서 어디까지 진행할 것인지 범위를 정하는 것은 프로젝트를 진행할 때마다 어려웠습니다. 사람과 시간은 항상 부족하기 마련이니까요.. 그럼에도 늘 그랬듯이, 일이 되는 방향으로 답을 찾아봐야 합니다.
이미지 출처 : 영화 인터스텔라
신뢰할 수 있는 팀 문화와 분위기 만들기
당시 배민스토어서비스개발팀은 백엔드 개발 조직 3개가 통합된 지 3개월이 막 지난 팀이었습니다.
저도 팀장이 되어 처음으로 큰 개발 조직을 이끌게 되었고요. 이런 상황에서 일반셀러 프로젝트를 시작하게 되었고 킥오프 전부터 모두가 기대 반 걱정 반으로 프로젝트를 준비하고 있었습니다.(걱정만 100%였을지도요?;)
평소 여느 과제처럼 내용 소개하고, 담당자 선정하고, 일정 추산하고… 이렇게 진행할 수도 있었겠지만, 이때는 팀원들의 마음가짐을 먼저 점검할 필요가 있겠다는 생각이 들었어요. 팀은 이제 막 합쳐져서 기존 서비스를 계속 운영하느라 정신없는데 큰 프로젝트를 시작하게 되었으니 팀 분들의 멘탈이 걱정되기도 했거든요.
마음가짐
팀 전체를 앉혀두고 괜히 무거운 얘기를 하듯 분위기를 잡아봤습니다.
“자, 오늘 일반셀러 도입 프로젝트에 대해 중요한 공유 내용이 있으니 잘 들어주세요!”
팀원들은 어떤 얘기일지(오픈 일이 앞당겨졌다든지?) 궁금해하며 살짝 긴장하신 것 같아 보였는데요.
저는 장난이었다며(힝! 속았지?) 팀원들을 안심시키고 3가지 마음가짐에 대해 얘기하기 시작했습니다.(마음가짐도 중요한 공유 내용이에요!)
1. 우리팀의 첫 번째 큰 도전
우리 팀은 이제 막 통합돼서 기존 서비스를 운영하면서도 새롭게 큰 프로젝트를 하게 되었던 터라 동기부여가 필요했습니다.
거듭되는 짧은 일정에 정말 바쁘게 일해 온 팀원들도 있었고, 큰 기술적 개선 없이 기존 레거시에 기능만 추가하면서 기술적 성장에 갈증이 있던 팀원들도 있었어요. 팀원들에게 동기부여를 하면서 동시에 불안감을 줄여주고 싶었습니다.
2. 즐기자
일반셀러 도입 프로젝트는 상당히 도전적인 과제가 될 것으로 예상했어요.
비즈니스 과제와 기술 과제를 동시에 진행해야 했고, 현재 배민스토어의 시스템을 모르는 분들도 많은 상황이었으니까요. 쉽진 않겠지만, 힘들 수도 있겠지만, 이 상황에서도 한번 즐기면서 일하면 좋을 것 같았어요.
3. 항상 방법은 있다.
프로젝트를 진행하면서 마주칠 어려움이 예상되기에 빠져나갈 구멍(?)에 대한 얘기도 했었어요.
개발하다가 막혀서 검토했던 설계대로 진행하지 못할 수도 있고, 일정을 못 맞출 수도 있겠죠. 그럼에도 항상 방법은 있더라고요.
동료와 이런저런 방법을 생각하다 보면 자연스럽게 해결책이 떠오르기도 하고, 다른 팀에 도움을 요청해서 해결하거나, 정 안되면 스펙을 조정할 수도 있으니까요. 무조건 처음에 정해진 대로 해내기 위해 너무 큰 스트레스를 받으며 일하진 않으면 좋을 것 같았습니다.
자신감을 높이기 위한 팀 스터디
저희 팀은 매월 KPT 회고를 진행하며 그라운드룰을 계속 업그레이드하기도 하고, 매주 기술 논의 시간을 가지는 등 기술력을 향상시키기 위해 노력해왔어요. 그럼에도 일을 잘하기 위한 활동들은 항상 부족한 것 같다고 생각했습니다. 게다가 이번에는 평소보다 더 큰 기술적 도전이 필요한 상황인데, 필요한 것은 무엇일까 많이 고민했습니다.
기능을 잘 만들 수는 있을 것 같은데, 새롭게 도입하는 기술을 적용해서 만들 수 있을지는 모두가 확신하지 못했어요. 팀원들이 잘 모르는 기술을 한정된 시간 내에 도입한다는 것이 우려되기도 하고, 자신감이 부족해서 진행 자체가 어렵게 느껴지기도 했습니다.
지금은 비즈니스를 발전시키면서도 동시에 새로운 기술에 도전할 수 있다는 자신감을 가져야 했습니다.
일단 자신감을 향상시키기 위해 팀 스터디를 시작했어요.
매주 화요일 1시간 팀 스터디를 진행하기로 하고, 우리가 개발할 시스템에 필요한 기술을 습득하는 시간을 확보했습니다.
팀 스터디는 기본적으로 현재 진행하는 과제에 직접적으로 도움이 되어야 하고, 모든 팀원들의 기술력이 상향 평준화되는 것으로 목표를 정하고 시작했는데요. 업무 시간을 할당한 만큼 치열하게 진행해야 함을 요청드렸어요.
팀원들은 새로운 기술에 관심도 많고 성장에 진심인 분들이어서 스터디 시간을 정말 알차게 사용했습니다.
각자 잘하는 부분이 다른 팀원들이다 보니 자기가 잘 아는 부분은 스스로 더 공부하고 정리해와서 팀원들에게 설명해 주시더라고요. 그리고 자신이 부족한 점은 동료에게 도움을 받아 빠르게 알아가고요. 이 과정에서 팀 분들이 성취감을 느끼면서 자신감을 가지기 시작했던 것 같습니다.
또한, 스터디를 통해 신규 입사자분들도 기존 팀원들만큼의 기술 수준에 빠르게 다다를 수 있었던 것 같습니다. 특히 우아한테크코스/우아한테크캠프를 수료한 분들은 경험은 부족해도 기본 학습력과 이해도가 좋아 빨리 습득하더라고요.
팀원분들이 2월에 진행했던 스터디 기록을 가져와봤습니다.
팀 스터디를 통해 짧은 시간 동안 이벤트 드리븐 아키텍처, DDB, Redis, Kotlin, WebFlux, Kafka 등 다양한 기술에 대한 기술력을 쌓을 수 있었습니다. 이렇게 스터디로 쌓은 지식과 경험을 바로 프로젝트에 적용하며 시스템을 척척 만들어가는 모습을 보니 살짝 감동했습니다.(ㅠㅠ)
팀 스터디는 지금도 꾸준히 진행하고 있어요. 현재는 각자가 관심 있는 분야로 그룹을 나누어 깊이를 쌓아가고 있습니다.
심리적 안정감
당시 팀 구성원 MBTI를 보니 I가 80%를 넘었는데요. (MBTI를 전적으로 신뢰하지는 않지만요;) 그래서인지? 팀원들이 모여있을 때 먼저 얘기를 꺼내기 어려워하는 느낌을 받았었습니다. 팀이 합쳐진지 얼마 되지 않았기에 서로 많이 친해지지도 못했었어요.
말을 편하게 할 수 없는 팀 분위기이면, 일을 어찌어찌 진행하다가도 결국 문제가 폭탄처럼 터지게 됩니다. 도저히 일정 내에 못할 것 같을 때에도 말을 못 한다거나, 이건 이렇게 하면 반드시 문제가 생길 것 같은데도 얘기를 못하게 되는 거죠. 시간이 흐르면 더 큰 문제가 돼서 수습하기 어려운 상황으로 이어지게 됩니다. 저 또한 그랬던 경우가 있었고 계속 자기검열을 하면서 말이 적어지니 퍼포먼스가 떨어질 때도 있었어요. 성과도 줄어들었고요. 이런 부분은 만약 팀을 이끌게 된다면 많이 신경 써야겠다 생각하고 있었습니다.
이제, 팀이 더 편하게 얘기할 수 있도록 방법을 찾아야 했습니다. 저희 팀은 매월 회고를 진행하며 그라운드룰(Ground Rule)을 끊임없이 개선했어요. 그라운드룰을 팀원 모두가 함께 정하고 그 룰을 지키려고 노력하기로 팀원들과 합의 봤습니다.(?)ㅋ
아래 표는 팀 그라운드룰의 한 부분입니다.
여러 항목들 중에 한 가지를 소개하자면 ‘같은 질문이 100번이 되더라도, 착실히 답변해 주자.’를 소개하고 싶어요.
일을 하다 보면 모르는 것들 투성인데요. 모르는 것이 있다면 100번을 똑같이 물어봐도 답변해 주어야 합니다.(100번까지 물어보는 분은 아직까진 없었어요;) 100번이라고 굳이 써 놓은 이유는, 횟수에 상관없이 최대한 잘 대답하고 설명해 주자는 것을 강조하기 위해서예요.
신규 입사자분들이나 팀 이동을 통해 새롭게 팀에 합류한 분들은 현재 시스템을 잘 모를 수밖에 없습니다. 어떤 API가 있는지, 특정 로직이 어떤 코드에 있는지, 운영 업무를 어떻게 처리하는지 모를 수밖에 없죠. 모르는 것을 잘 알려줘서 동료가 빠르게 퍼포먼스를 낼 수 있게 도와야 해요. 또한, 물어보는 것이 어렵거나 문제를 입 밖에 내기 어려워지면, 팀의 생산성은 떨어지게 됩니다. 이슈가 발생할 때 근본적으로 해결하는 방법을 찾기 어려울 수도 있고요.
팀원이 더 편하게 얘기할 수 있도록 항상 신경 써야 합니다.
일은 항상 쉽지만은 않은 것 같아요.
리더와 동료에게 자유롭게 표현할 수 있고 털어놓을 수 있도록 분위기를 만들어서 조금이나마 마음 편하게 일하면 좋을 것 같습니다.
명확한 역할 부여
아무리 큰 프로젝트여도 한 명이 모든 것을 진행할 수는 없을 거예요.
각자의 역할을 명확하게 나누어 프로젝트를 빠르게 진행할 수 있도록 가이드가 필요했어요. 동료를 믿고 각자가 제 역할을 해낸다면 전체 일은 자연히 잘 마무리될 거라고 생각했습니다.
개발 환경, 아키텍처(데이터 저장소, 이벤트 연동 임포터, 배치), 어드민, API(External, Internal), 배포시스템, 오픈 준비 등 업무 전체를 나열한 후 업무를 분배했습니다. 분배할 때도 각자 자신이 더 흥미롭고 해보고 싶은 부분을 맡을 수 있도록 밀어줬는데요. 그래서 모두가 더 재밌게 집중하면서 개발할 수 있었던 것 같아요.
프로젝트 진행 과정에서 각자가 오늘, 내일, 다음 주, 그리고 그 이후에 무엇을 할 것인지 예상하면서 일의 연속성을 인지할 수 있어 일이 수월하게 진행되었어요. 역할이 명확하니 자기가 맡은 부분을 확실하게 끝내면서 주변 동료를 도와주기도 하고, 각 작업 사이 그레이 영역에 있는 드러나지 않은 작업들을 찾아내서 이슈를 미리 방지하기도 했습니다.
그리고 이 스프레드시트는 기획팀에도 공유를 했었는데요. PM분들이 아주 잘 활용했다고 얘기해 주셨어요. 프로젝트 영역이 너무 넓어서 개발 담당자를 찾기 힘들었는데 그때마다 좋은 이정표가 되어주었고, ‘개발은 이런 단위로 업무를 쪼개는구나~’ 하며 이해하기에 너무 좋았다고 하시더라고요. 생각 못 하고 있던 부분인데 함께 일하는데 조금이나마 도움이 됐던 것 같습니다.
플랫폼에 올라타기
직접 개발하기 vs 플랫폼 연동하기
상황에 따라 플랫폼과 비슷한 큰 시스템을 직접 개발해야 하는 경우가 생깁니다.
새로운 기능을 만들어야 하는데 연동해서 활용할 시스템이나 플랫폼이 없는 경우죠. 이럴 땐 스펙을 줄여 기본 기능만이라도 직접 만들어야 합니다. 이럴 경우 기능이 많이 부실할 수도 있을 거예요. 확장성도 부족해서 새롭게 기능을 하나씩 추가하다 보면 중복 코드가 많아지기도 하고요. 그렇더라도 당장은 빠르게 개발해나갈 수 있어요.
최근엔 사내의 많은 시스템들이 플랫폼화되어 활용할 수 있게 되었습니다. 음식이나 상품을 검색하고 리스팅 할 수 있는 검색플랫폼, 리뷰 데이터를 관리하는 리뷰플랫폼, 고객에게 최적의 가게/상품을 추천하는 추천시스템 등 배달의민족 내의 여러 서비스를 위해 플랫폼들이 운영되고 있습니다. 플랫폼은 연동하는 서비스들에게 안정적이고 풍부한 공통 기능을 제공하고 있어요.
그런데 배민스토어는 이런 사내 플랫폼들을 대부분 연동하지 못하고 있었습니다.(ㅠㅠ)
배민스토어는 스타트업과 같은 속도로 빠르게 개발하여 비즈니스를 검증하면서 발전해 왔습니다. 사내 플랫폼들은 푸드서비스와 관련된 기능은 이미 안정적으로 잘 구축되어 있지만, 신사업인 배민스토어와 같은 커머스서비스에 제공되는 기능은 상대적으로 부족한 상황이었기 때문에 배민스토어의 속도를 항상 맞춰주지는 못했어요. 그러다 보니 플랫폼에 연동하지 못하고 직접 개발하는 것들이 많을 수밖에 없었고요. 당연히 기능들은 고도화되지 않은 기본 기능 정도밖에 없었죠.
이번에 일반셀러 프로젝트를 진행하면서 전시 전체를 새롭게 만드는 만큼, 사내 플랫폼과 배민스토어를 연동하면서 다양한 기능을 구현했습니다.
플랫폼 상황을 이해해야 연동이 쉽다
플랫폼 연동이 뚝딱 쉽게 되면 좋겠지만, 아시다시피 쉽지는 않은 작업입니다.
플랫폼은 연동되는 서비스의 요구사항을 꾸준히 적용하면서 발전해 나가는데요. 아직 한 번도 연동하지 않았던 서비스라면, 처음 연동을 시작할 때 많은 논의가 필요합니다. 서비스의 요구사항을 적용하려면 플랫폼 내부에 DB나 API를 새로 추가해야 하거나, 기존 API를 버전업해서 제공해야 할 때도 있습니다. 플랫폼 입장에서는 내부 설계와 구조를 모두 생각하면서 지원해야 하기 때문에 생각보다 많은 작업이 필요하죠.
저희는 먼저 각 플랫폼의 역할과 방향성을 이해하고자 플랫폼 담당자와 밀접하게 논의를 시작했습니다.
현재 제공되고 있는 기능은 무엇이 있고, 어디까지 추가 가능한지, 앞으로 어떤 방향으로 플랫폼이 발전하게 될 것인지를 이해하고자 노력했어요. 플랫폼이 어떤 방향성과 로드맵이 있는지 모르는 상황에서 우리의 요구사항만 나열하게 되면 일정을 맞추기도 어렵고 정책, 로직이 충돌해서 진행이 어려울 수 있습니다. 저희 서비스를 위한 기능을 일방적으로 추가해달라고 요구하고 싶지는 않았어요.
우리 서비스는 우리가 제일 잘 알고, 플랫폼은 플랫폼이 제일 잘 알고 있습니다. 서비스와 플랫폼을 연결하려면 우리부터 플랫폼을 정말 잘 알아야 하고, 우리 서비스를 플랫폼에 빠르게 연동할 수 있도록 가능하면 플랫폼 상황에 맞추는 방향으로 진행해야 합니다. 우리 서비스에 대한 많은 정보를 제공해서 더 좋은 방법을 끌어내야 하고요.
각 플랫폼들의 기능, 시스템 구조를 검토하고 로드맵까지 확인하기 시작했습니다. 그리고 우리 서비스와 이번에 어느 기능까지 연동 가능한지, 추가 연동 일정은 언제인지 함께 검토하면서 플랫폼을 하나하나 연동해나갔어요.
이번엔 검색플랫폼을 새롭게 연동했고 브랜드셀러, 일반셀러의 가게/상품 정보에 대해 키워드 검색뿐 아니라 정렬, 필터링을 통해 다양한 목록 지면에 노출할 수 있게 되었습니다. 기능, 성능, 리소스 절약 등 많은 이점이 있었고요.
결국 15개의 사내 플랫폼이 연동되었습니다. 모두 이번 프로젝트에서 새롭게 연동된 것들은 아니지만, 크고 작은 변화에 대응하는 작업들이 있었어요. 저희는 하나의 서비스를 만들어가는 조직으로써 사내 플랫폼을 제공하는 팀들이 정말 고마웠습니다. 많은 기능을 통합해 제공해 줌으로써 저희가 신경 쓸 부분을 덜고 서비스의 중요한 부분에 집중할 수 있었거든요.
위기가 없던 프로젝트가 있었던가요?
드러나지 않았던 회색 지대
이제 프로젝트 오픈 한 달 전, 본격적인 QA를 시작하게 되었는데요. 갑작스럽게 이슈가 제기됐습니다.
주문과 리뷰의 관리 기능에 대한 QA를 진행해야 하는데 앱에 가게나 상품이 제대로 노출되지 않고, 주문을 할 수가 없으니 제대로 테스트를 할 수 없다는 이슈였어요.
앱에 가게와 상품이 노출되는 전시 지면의 백엔드를 맡고 있던 저희 팀은 이슈를 공유 받고 당황스러웠습니다. 저희 전시 지면에 대한 QA는 지금부터 시작되는 일정인데, 주문/리뷰 관리 QA도 동시에 시작되어야 한다고요?! 왜 일정이 이렇게 겹친 걸까요?!!
이슈를 해결하기 위해 전체 프로젝트 미팅이 급하게 하나 잡혔습니다. 하나씩 얘기를 하다 보니 문제가 보였는데요. 커뮤니케이션이 부족하여 각자의 일정 상황이 적절하게 공유되지 않았던 것 같았습니다. QA 일정이 어드민 → 전시 → 주문 → 리뷰 등의 순서로 진행되어야 하는데 참여한 조직도 많고 시스템들이 나누어져 있다 보니 커뮤니케이션에 약간의 빈틈이 생겨 일정을 세밀하게 맞추지 못한 것 같았어요.
프로젝트 오픈이 얼마 남지 않은 상황에서 어떻게 해야 할지 얘기를 나누었습니다. 그리고 3일 뒤까지도 전체 QA를 정상적으로 진행하기 어렵다면 그때 프로젝트 오픈을 연기하는 것에 대해 논의하기로 했습니다. 보통 프로젝트 오픈 연기는 쉽게 결정하기 어려운데요. 이번 프로젝트도 마찬가지였습니다. 이미 일반셀러 사장님들과 계약이 진행되고 있었고(계약 날짜ㅠ), 대외적으로는 기사도 발행된 상태였어요. (윽 어떻게든 오픈해야 해…!)
해결
3일의 시간을 확보한 상태로 일단, 저희는 전체 흐름의 정상 케이스들이 모두 동작할 수 있도록 빠르게 기능을 살펴보았습니다.(집중해!)
배민스토어 서비스의 흐름은 단순하게 표현해 보면 아래와 같아요.
여기서 가게/상품 데이터를 연동 받아 앱에 잘 노출하는 것이 우리 팀의 역할이에요.
전체 흐름의 중간에 있기 때문에, 우리가 제 역할을 하지 못하면 서비스 전체가 정상 작동하지 않게 됩니다.
배민스토어 전시 기획/개발팀 이 한 회의실에 모여 모든 기능들을 살펴보고, 버그들을 찾아 정상 작동하도록 수정해 나갔어요. 이때가 프로젝트에서 가장 숨도 안 쉬고 일했던 때 같기도 합니다.(거짓말)
상품이 노출되지 않으면 팀의 상품 연동 담당자들이 이벤트 연동 Kafka부터 노출 로직, 앱 API를 빠르게 확인했습니다. 리뷰 작성이 안되면 리뷰 담당자가 리뷰플랫폼 연동 로직을 검토하고 데이터를 확인했고요.
저는 서비스 전체 흐름이 잘 진행될 수 있도록 문제 되는 부분을 발견해 팀원에게 빠르게 공유하고 해결해나갔습니다. 정책이 이슈일 땐 PM 분과 논의해서 정리하고, MVP에서 제외해도 될 부분은 과감하게 제외하도록 빠르게 결정하고 처리해나갔어요.
결국 2일 만에 주문, 리뷰까지 흘러갈 수 있도록 모든 기능을 확인하고 정상화했습니다. 모두가 집중해서 노력했던 결과였어요!
다시 생각해 보는 프로젝트의 범위와 역할
이 과정에서, 앞서 얘기했던 프로젝트의 범위에 대해 다시 한번 생각하게 되었는데요.
프로젝트를 진행하면서 사업, 기획, 개발 부분을 잘 챙기고, 저희 전시 기능의 QA까지만 잘 신경 쓴다면 오픈은 문제없을 것만 같았어요. 그런데 이 프로젝트는 주문/리뷰(+관리 기능) 등 서비스의 전체 흐름까지 테스트 되어야 하는 큰 규모의 프로젝트였습니다. 또한, QA 측면에서도 전시 기능의 QA 일정뿐 아니라 다른 팀의 QA 일정까지 고려해서 한판 정리해야 했다는 생각이 들었습니다. 그러면 더 원활하게 진행되었을 것 같더라고요. 이번 경험을 통해 더 넓은 시각으로 프로젝트를 바라보게 되었습니다.
그리고 미리 역할을 명확하게 나누어 놓았던 것이 이 위기를 잘 극복할 수 있었던 원천이었던 것 같습니다. 각자가 맡았던 부분을 확실히 알고 있기에 현재 어느 부분에서 어떤 에러가 발생하는지, 어떤 부분의 데이터가 잘못 연동되고 있는지, 어떻게 해결해야 하는지 빠르게 찾을 수 있었어요.
짧은 시간에 집중해서 빠르게 진행하느라 모두가 신경을 많이 쓰기도 했는데요. 이렇게 정상화 작업을 완료하고 보니, 오히려 QA 일정을 많이 사용하지 않고도 전시 기능들을 안정화할 수 있었던 것 같습니다. 이후 성능 테스트와 오픈 준비에 시간을 더 쏟을 수 있어서 오히려 좋기도 했고요.^^ㅋ
이미지 출처: 침착맨, https://youtu.be/KShzSpdjNL0
비즈니스 성과 + 기술적 성과
이제 일반셀러 도입 프로젝트를 무사히(?) 오픈했어요. 최종적으로 어떤 성과를 만들어냈는지 말씀드려볼게요.
비즈니스 성과
일반셀러 도입 프로젝트에서는 비즈니스 요구사항을 로직에 담는 작업이 가장 중요했어요.
브랜드셀러 위주의 지면들을 모두 새롭게 개편하면서 브랜드셀러와 일반셀러를 함께 고민했고 그 결과 일반셀러 상품들을 효과적으로 노출할 수 있게 되었습니다.
- 일반셀러의 상품을 탐색하고 구매할 수 있도록 서비스홈, 가게홈, 가게/상품 목록 등 주요 전시 지면 개편을 진행했습니다.
- 일반셀러가 입점하며 고객이 보는 셀러의 수가 엄청 많아진 상황에서, 고객의 탐색 경험이 불편하지 않도록 카테고리를 도입했습니다.
기술적 성과
프로젝트를 시작할 때는 이 모든 것들을 다 해낼 거라고 생각하지 못했었는데요. 주변의 많은 도움과 팀원들의 노력으로 해낼 수 있었던 것 같습니다.
기술적인 부분은 좀 더 세세하게 적어봤어요.
- 이벤트 기반 전시 아키텍처 개발
‘가게/상품 등의 데이터를 커머스플랫폼 API에서 바로 앱으로 전달하는 대신, 이벤트 연동을 통해 전시 자체 데이터를 구축한 뒤 앱에 전달하는 방식으로 아키텍처를 개선했어요. - 앱에 제공하는 백엔드 API 전체 재개발(약 60개 API)
앱에 제공되는 모든 API는 새로 스펙을 맞추고 API를 나누고, 합치기도 하면서 모두 새롭게 개발했습니다. 페이징이 없는 지면은 페이징을 추가해 성능 개선을 도모했어요. 또한, 주요 앱 API의 응답시간이 획기적으로 개선되었어요. - Java에서 Kotlin 전환
프로젝트 기반 언어를 Java에서 Kotlin으로 전환하여 생산성을 향상시켰습니다. - Spring WebFlux 도입
앱에 제공되는 API 서버에 WebFlux를 도입해 최대한의 성능을 발휘하고자 했어요. - 15개 이상의 사내 플랫폼 연동
사내 플랫폼들을 연동하여 빠르게 기능을 추가했습니다. 서비스 개발에 집중할 개발 리소스를 확보할 수 있었어요. - 공통 배포시스템으로 전환
공통 배포시스템으로 전환하여 생산성을 높였고 사내 지원 용이성을 확보했습니다.
결국 개발도 일
우리가 개발을 하다 보면 가끔은 놓치는 것들이 생기기도 합니다. 어느 로직 한 부분에 깊이 몰입하다 보면 다른 시스템을 생각하지 못하기도 하고요. 이럴 때마다 계속 왜?를 물어봐야 합니다.
- 지금 내가 만드는 코드의 목적은?
- 내가 만드는 시스템의 역할은?
- 이 과제의 의미는?
이런 부분들을 계속 생각하면서 개발해야 합니다. 그렇지 않으면 내가 만든 코드가, 시스템이, 기능이, 만드는 순간 레거시가 될 수 있으니까요.
개발도 결국 일이라고 생각합니다.
왜?를 알고 일하면 정확하면서도 더 많은 일을 해낼 수도 있습니다.
‘일반셀러 도입’이라는 비즈니스 과제를 들었을 때, 이 일을 왜 하는지 최대한 이해하고자 노력했던 결과, 고객과 사업이 원하는 기능들을 더 정확하게 더 적은 리소스로 해낼 수 있었습니다. 이렇게 확보한 리소스를 잘 활용해, ‘전시 아키텍쳐 개선’, ‘전체 API 재개발’ 등 기술 과제를 동시에 진행할 수도 있었고요.
우리는 서비스를 만들고 계속 운영하면서 동시에 새롭게 개선해나가야 합니다.
쉽지 않은 일이지만, 왜?를 물으며 한 발씩 나아간다면 조금은 수월하게 해나갈 수 있지 않을까요?
끝으로
앞으로 배민스토어에는 또 다른 재밌는 일들이 기다리고 있습니다.
배민스토어서비스개발팀은 고객이 가게/셀러를 손쉽게 탐색하고 주문까지 이어질 수 있도록 더 다양하고 안정적인 기능을 고객에게 제공하기 위해 계속 노력하려고 합니다.
배민스토어서비스개발팀에 관심이 생겼다면?! 아래 링크를 참고해 주세요.
이 글은 배민스토어서비스개발팀에서 발행하는 ‘[배민스토어] 일반셀러 프로젝트’ 시리즈의 첫 번째 글입니다. 이후 글도 많은 관심 부탁드립니다.
[배민스토어] 일반셀러 프로젝트 시리즈 더 보기