[코드스테이츠 PMB 8] 개발절차
왜 PM이 개발 절차까지 이해하고 있어야 할까?
흔히들 개발 지식을 알아야 해서라고 생각하기도 한다. 하지만 모든 이유는 커뮤니케이션 때문이다. 개발 절차를 이해하는 이유도 개발자와의 커뮤니케이션을 통해 우리의 서비스가 기획대로 잘 만들어지고 있는지 확인하기 위함이다. PM은 지휘자이기 때문에 모든 악기를 능수능란하게 연주할 줄 알아야 하는 것이 아니라, 모든 악기들 간의 조화로움을 능수능란하게 다뤄 완벽한 하모니를 만드는 것에 집중해야 한다.
PM이 개발절차를 이해하기 위해 참고하면 좋은 사이트들이 있다. 바로 각 기업들의 개발 블로그이다. 개발 블로그에는 개발에 전문적으로 담긴 내용들뿐 아니라, 기업 문화부터, 기획, 디자인 등 기업이 해결하고자 하는 문제들을 어떤 방식으로 해결했는지까지 기술되어 있다.
여러 기술 블로그를 살펴보았는데 그중 배달의 민족 서비스를 만든 '우아한형제의 기술 블로그'에서 재미난 이야기를 볼 수 있었다. 서비스를 기획하는 과정에서 생긴 불필요한 소통으로 인해 낭비되는 리소스가 많아, 이를 개선하는 시스템을 팀 자체적으로 구축했다는 이야기였다. 업무 프로세스 안의 개발 절차와 함께 협업에 대한 내용을 함께 알아볼 수 있었다. 이 팀은 바로 '배민셀프서비스팀'으로 배달의민족내에서 '사장님광장'서비스에 속해있으며, 사장님을 위한 서비스를 만드는 팀이다. 그렇다면 '배민셀프서비스팀'의 개발 이야기와 함께 PM의 역할에 대해 자세하게 살펴보자.
사장님들이 장사를 더 잘 하실 수 있게 집중합니다
배민셀프서비스 팀은 배달의 민족의 또 다른 고객인 사장님들이 더 쉽고, 빠르고, 효과적으로 장사하실 수 있도록 '셀프서비스'를 만드는 팀이다. 약 일 10만 명, 월 30만의 사장님이 가게, 메뉴, 리뷰 등의 정보를 관리하기 위한 셀프서비스를 제공하고 있다. 사장님들이 오직 장사에만 집중할 수 있는 환경을 만들어, 결국 이 노력이 배달의민족 앱을 통해 주문하는 고객에게 더 나은 가치로 전달되는 것을 목표로 일하는 팀이다.
'좋은 음식을 먹고 싶은 곳에서'라는 배달의 민족 비전의 B2C, B2BC 고객의 통로에 있는 서비스로 고객의 데이터를 사장님이 관리할 수 있도록 서비스를 제공한다. 배달의민족 앱에 보이는 가게 로고, 메뉴, 리뷰, 정산내역 등에 대한 정보를 셀프서비스를 통해 스스로 관리할 수 있다. 셀프서비스는 20대부터 60대까지 폭 넒은 연령층이 사용하기 때문에, IT가 익숙하지 않은 사장님도 쉽게 가게를 관리할 수 있도록, IT가 익숙한 사장님은 더 많은 기능을 활용해 더 많은 매출을 낼 수 있도록 하는 서비스를 제공하고 있다.
2020년 초에 배민셀프서비스 전면 개편 프로젝트를 하며 운영하는 과정부터 기획, 개발, 사업 등 여러 직군들 과의 협업이 있었다. 그 과정에서 일을 더 잘하기 위한 시스템, 즉 '복잡한 사회적 체계의 맥락에서 구조와 행동을 통제하는 규칙들의 집합체'를 만들기 위해 '디자인 시스템'을 만들었다.
우아한형제들의 개발/플랫폼 조직은 도메인별로 분리되어 있었다. 또한, B2B, B2C 서비스가 서로 얽혀있어 서로 다른 조직들에게 다양한 요구 사항이 들어오는데, 서로 다른 방식으로 요구 사항을 전달하게 되었다. 그렇다 보니 여러 조직의 요구 사항을 취합하여 문서화 후 디자인과 개발이 진행되어 일관성 있는 UX를 제공하기 어려웠다.
배민셀프서비스 전면 개편 프로젝트를 진행하며, 시간 내에 해당 테스크를 수행하기 위해 새롭게 일하는 프로세스를 찾기로 했다. '어떤 종류의 기능은 항상 이렇게 동작한다. 어떤 종류의 정보는 항상 이렇게 표현한다.' 모든 협업자에게 이런 생각을 싱크 한다면?이라는 생각을 반영할 수 있는 규칙을 만들기로 했다. 그렇게 된다면 기획은 UI 배치와 순서 때문에 정책 결정이 늦어지지 않을 것이고, 개발은 디자인 없이도 화면을 만들어 낼 수 있을 것이고, 디자인은 UX를 거시적인 관점에서 고민할 수 있게 될 거라고 생각했다.
협업자들간에 원칙을 고민했더니 자연스레 일관성이 생겨났다. 큰 틀이 결정된 후 라이브러리가 구축됐고, 완전히 싱크 된 6명의 프론트엔드 개발자들은 프로토콜에 따라 React 컴포넌트를 구현해 일주일 만에 디자인 시스템이 만들어졌다. 디자인 시스템을 만들고 나니 업무 프로세스에서 변화가 생겼다.
1. 기획자 - 기획 단계 : 기획자는 기존에 화면 그리는 시간을 단축하고 시스템 정책 정의에 더 집중할 수 있게 됨.
2. 디자이너 - 디자인 / 마크업 : 디자이너는 User Flow를 그리는데 집중하고, UX 개선에 시간을 투자할 수 있게 됨. 세부 화면 작업은 기획자와 같이 Figma로 그려진 화면을 보면서 기획 의도, 컴포넌트 사용 등 실시간 코멘트로 의견을 주고받음. 모바일 화면만 그려서 전달하고 나머지 디바이스 별 화면은 개발 이후 디자인 QA 진행 시 검토. 픽셀 단위의 오차는 찾아낼 필요가 없어져 디자인 QA 시간 단축
3. 개발자 - 개발 : 개발자는 기획 화면을 기반으로 디자인을 기다릴 필요 없이 개발 작업에 바로 들어갈 수 있음. 컴포넌트를 조합해 모바일 화면만 만들면 나머지 해상도/디바이스 별로 고민하지 않아도 됨. 코드가 깔끔해지고 생산성은 좋아짐.
해야 할 일들에 대해 싱크 하는 시스템을 만들었기 때문에, 각 직군들의 업무 프로세스에서 낭비되는 시간을 줄이고 중요한 부분에 더 집중할 수 있도록 업무를 진행할 수 있게 되었다.
PM이 함께 알아야 할 기술 스택에 빗대어 개발자들이 사용하는 기술 스택을 살펴보면, 웹 기반의 JavaScript와 그리고 React 프레임 워크, API를 활용하고, AWS 서버를 활용해 RDBMS로 MYSQL로 데이터를 분석하는 것을 알 수 있다. 이는 배민셀프서비스가 웹 기반 하이브리드 앱 서비스를 만들고, API를 사용해 클라이언트와 서버가 소통하고, 서버는 AWS(아마존 웹 서비스)를 사용하며 RDBMS(관계형데이터베이스)로 데이터를 관리한다는 것을 알 수 있다.
배민셀프서비스의 개발 절차는 정보를 노출하는 원칙을 정하고 이것들을 컴포넌트화하는 디자인 시스템 구조로 개발이 진행된다. 컴포넌트란 프로그래밍에 있어 재사용이 가능한 각각의 독립된 모듈을 뜻한다. 그래서 컴포넌트 기반 프로그래밍을 하면 마치 레고 블록처럼 이미 만들어진 컴포넌트들을 조합해 화면을 구성할 수 있다.
디자인 시스템 구조를 이용해 위의 사진과 같이 정보를 노출하는 원칙을 정하고 이것들을 Core Componet, Core Library로 컴포넌트화했다. 그래서 재사용성을 높여 효율적으로 빠른 시간 안에 개발할 수 있도록 개발 절차를 개선했다. 이런 각각의 컴포넌트들이 UI를 구현한 컴포넌트가 아니라, 각 컴포넌트 간의 관계에 따른 다양한 규칙들을 정의해 화면 구성에 대한 고민의 시간을 줄일 수 있도록 했다.
우아한형제들 기술 블로그에 디자인 시스템 각 컴포넌트별 기능에 대해 코드가 상세히 나와 있었지만, 모든 기능이 어떻게 구현되는지 까지는 이해하지 못했다. 하지만 거시적 관점에서 개발 절차 진행과정을 이해할 순 있었다.
디자인 시스템에서는 대부분의 코드들이 객체지향 추상 클래스로 구성되어 있다. 이 말은 간단하게 말하면 완성되지 않은 메서드, 즉 동작 방식을 결정할 수 없거나 확정할 수 없을 때 동작 부분을 기술하지 않고 비워두는 추상메서드를 가진다는 뜻이다. 그래서 공통된 UI/UX와 규칙을 정의하여 스타일에 대한 고민 없이 큰 틀에서의 디자인은 그래도 이어가면서, 새로운 컨텍스트가 필요한 부분들만 Cascading(어떤 스타일을 적용받을지에 대한 우선순위 체계)로 구성해 커뮤니케이션 시간을 줄이고 업무 속도를 향상했다. 이렇게 미리 정해둔 원칙대로 개발을 진행하기 때문에 불필요한 커뮤니케이션이 줄어들고, 대신 고객의 피드백을 기반으로 각 화면을 끊임없이 탐구하고 유저 동선과 컨텍스트를 경험하며 더 나은 UX를 고민할 수 있게 되었다.
배민셀프서비스는 하나의 단독적인 서비스가 아니다. 배민에서 제공되는 여러 서비스들과 연결되어 있다. 사장님(업주) 지향 모든 서비스들이 '우리의 서비스는 각각 다르지만 서비스를 이용하는 사용자는 같아'라는 전사적인 공감대가 생겨났고, 이를 통합적 관점에서 보기 시작하면서 서비스들의 사용성과 일관성에 대해 고민하게 되었다고 한다. 이렇게 서비스가 성장하는 과정에서 PM은 어떤 기술 요소를 이해해야 더 나은 서비스를 고민할 수 있을까?
API 구조를 이해해 고객, 사장님이 데이터들이 어떻게 서로 구조화되어 있는지 알아야 한다. API의 구조가 곧 제품의 정보 교환의 구조를 의미하기 때문에, 제품 기능을 이해하고 관리하는 목적에서 API를 파악하고 분석할 수준의 능력을 갖추어야 한다. 배민셀프서비스는 결국은 사장님이 장사에만 집중할 수 있도록 가게를 관리하는 것이기 때문에, 고객과 주문 데이터 등 가게 운영에 있어 필요한 정보들을 서버에 저장하고 이를 클라이언트를 통해 사장님에게 어떻게 보여주는지를 이해해야 한다. 이 구조를 이해하고 있어야 사장님에게 더 직관적이고 효율적인 정보를 제공하는 서비스를 관리할 수 있기 때문이다.
고객으로부터, 사장님으로부터 얻는 다양한 데이터들을 모아 어떤 관계로 구성되어 있는지 이해해야 한다. 각 데이터들의 구조를 파악하고 있다면 데이터별 상관관계를 분석해 더 나은 서비스를 기획할 수 있을 것이다. 예를 들어 리뷰 데이터의 별점과 주문 횟수의 상관관계를 보고 매출과 직결된다는 인사이트를 얻었다. 그러면 사장님은 배민셀프서비스를 통해 별점과 주문 횟수별로 단골 고객을 관리할 수 있는 서비스를 만들 수 있다. 또한, 사장님이 고객리뷰를 일주일 안에 답변할 수 있도록 푸시 알람을 보내, 고객의 재주문율을 높일 수도 있을 것이다. 또 다른 예로는, 지난주 매출, 메뉴 통계를 확인할 수 있는 데이터를 제공한다면, 주간 별 가장 인기 있는 메뉴 주문 횟수를 보고 사장님이 재고를 관리하는 데에 도움이 될 수 있다. 이렇게 어떤 데이터를 모아 관리하는지 이해한다면, 사장님이 더 효율적으로 매장을 관리할 수 있는 서비스를 제공할 수 있다.
배민셀프서비스 팀은 개발자의 개발 과정과 디자이너의 디자인 과정을 PM이 이해하고 이 사이에서 문제를 발견할 수 있었기 때문에, 서로 소통하는 데 있어 불필요한 시간들을 줄일 수 있는 디자인 시스템 구조를 만들 수 있었던 것이다. PM은 더 나은 서비스를 고민하기 위해, 우리 팀은 과연 고객의 문제를 해결하기 위해 많은 시간을 쏟고 있는지를 확인해야 한다. 서로 소통하는 데 시간을 보내고, 서로의 결과물을 이해하는 데 시간이 걸린다면 불필요한 리소스를 낭비하고 있지는 않은지 생각해 봐야 한다. 개발 스택을 이해한다는 것은 개발 과정을 이해하는 것이다. 더 나은 서비스를 만들기 위해서는 기획한 대로 서비스가 만들어지는지 확인할 수 있어야 하기 때문이다. 그렇기 때문에 개발과정에서 원활한 커뮤니케이션은 PM에게 있어 중요한 역량이 된다. 이를 잘 이해하고 있어야 디자이너와 개발자 간의 소통도 원활하게 조율할 수 있다. 결국 PM이 개발과정을 이해한다는 것은, 결과물을 만드는 시간을 최대한 줄이고 고객에게 더 집중할 수 있는 시간을 늘려 더 좋은 서비스를 제공하기 위해서이다.
건축을 설계하다 서비스까지 설계하는 본 투 비 설계자의 PM도전 프로젝트
참고 자료
https://techblog.woowahan.com/6305/
https://techblog.woowahan.com/5327/
https://b2bservice.notion.site/34057310bbaa4386bb0a231b388239f1
https://m.blog.naver.com/da91love/220942227768
https://victorydntmd.tistory.com/190