소 개
안녕하세요. ABC Studio의 송재욱입니다. 저는 이곳에서 ABC Platform 팀을 맡고 있습니다. 이 글은 지난 1년간 ABC Platform 팀이 데마에칸(出前館, Demaecan) 서비스를 만들어 오며 저희만의 방식으로 일해 온 여정을 돌아보는 회고입니다.
- 데마에칸: 일본에서 제공하고 있는 배달 서비스입니다. 잘 나갑니다. 앞으로 더 잘 나갈 예정입니다.
- ABC Platform: LINE+ ABC Studio의 하위 조직으로, 통합과 효율을 추구하며 프로덕트를 만드는 사람들이 모여 있습니다.
ABC Platform 팀의 시작
ABC Platform의 상위 조직은 ABC Studio입니다. ABC Studio는 조직 규모가 점점 커지면서 팀원이 선택과 집중을 할 수 있도록 하위 조직을 만들어 역할과 책임을 나누고 있습니다. 각 팀은 서로에게 최선이 무엇인지 치열하게 고민하며 최적의 해법을 찾아가고 있는데요. 그 과정에서 작년 4월에 플랫폼 프로젝트를 아우르기 위한 ABC Platform 팀이 만들어졌습니다.
보통 하나의 팀은 하나의 연관된 서비스를 담당하거나, 혹은 몇 개의 서로 다른 프로젝트를 진행하더라도 각 프로젝트가 서로 유기적으로 연관돼 있는 경우가 대부분입니다. 팀 구성원 전체가 서로 업무적 연관성이 있다는 것인데요. ABC Platform 팀은 사정이 조금 달랐습니다. 이미 따로따로 진행되고 있던 프로젝트들을 플랫폼이라는 논리적인 속성으로 묶은 팀이었기 때문입니다(참고로 저희에게 '플랫폼'이란, 독립적이고 범용적인 속성의 프로젝트를 아우르는 개념입니다). 이런 이유로 팀이 생성된 후 이 팀을 어떻게 하나로 묶을 수 있을지, 팀의 방향성은 무엇인지 혼란스러웠습니다. 따라서 제가 팀을 위해 처음 했던 일은 자연스럽게 팀의 정체성을 정의하는 것이었습니다.
팀의 정체성
처음 팀이 구성될 때에는 6명의 엔지니어가 5개의 개별 프로젝트를 진행하고 있었습니다. 아래는 당시 각 프로젝트 혹은 업무에 대한 한 줄 요약입니다. 보시다시피 각각의 고유한 문제를 해결하는 데 집중했기에 업무 컨텍스트 역시 뚜렷이 구분됩니다.
- MessagingHub: 독립적이고 범용적인 메시징 플랫폼
- AccountService: 계정/인증/인가를 처리하는 인증 플랫폼
- UserFeedback: 사용자의 피드백을 수집하고 고객 중심의 제품을 만들어 가기 위한 ABC Studio의 자체 오픈소스
- Itemlisting: 데마에칸의 서비스 화면에 노출되는 가게 정보 등을 제공하기 위해 최적화된 데이터 파이프라이닝 프로젝트
- SRE: 팀 내 각 프로젝트의 인프라 구성과 이슈 대응 및 안정적인 운영을 담당하는 역할
데마에칸은 업력이 최소 10년이 넘은 서비스였기에 이미 오랜 시간에 걸쳐 핵심 도메인 영역이 완성돼 있었습니다. 긴 시간 이 핵심 도메인 영역을 벗어나지 못하고 쌓아 올리듯 개별 프로젝트가 진행되어 왔는데요. 최근에서야 핵심 도메인뿐 아니라 범용적인 사용까지 전제로 삼은 프로젝트들이 생겨나면서 데마에칸에 '플랫폼'이라는 개념을 도입할 수 있게 됐습니다. 그 선봉이 ABC Platform 팀입니다.
한편 그렇기 때문에 초기에는 사내에서조차 플랫폼 프로젝트를 하나의 도메인으로 인식하는 사람들이 적었습니다. 이는 업무를 진행하면서 설득에 필요한 비용이 크다는 의미이기도 하지만, 긍정적으로 생각해 보면 그만큼 해야 할 일이 많고 기여할 부분도 크다는 뜻이기도 했습니다. 레거시의 유지 보수 나 산재한 기술적인 문제 등을 해결해 나가는 방법을 근본적으로 저희만의 해법으로 전환하는 것이 ABC Platform 팀의 존재 이유라고 생각했습니다.
그렇게 저희는 '도메인 의존성을 최소화한 기반 기술로 변화를 주도하는 팀'이라는 하나의 문장으로 팀을 정의했습니다.
일하는 방식
저희가 일하는 방식은 최소 1년간 이 팀에서/회사에서/서비스에서 살아가기 위해 체득한 방법론이자 누구에게도 물러설 수 없는 팀의 핵심 가치입니다. 다음 세 가지 키워드를 중심으로 이를 소개하겠습니다.
- 프로세스 개선
- 성공 사례
- 태도
프로세스 개선
저희는 프로덕트를 만드는 팀이면서 동시에 프로세스를 개선하는 것에도 관심이 많습니다. 몰입하기 위해서는 당연히 일하기 좋은 환경을 만들어야 하기 때문입니다. 저희가 일하는 환경조차 고칠 수 없다면 사용자에게 전달하는 프로덕트의 엣지를 만드는 것은 더욱 어려울 것입니다.
업무 진행 과정의 라이프 사이클을 도식화하면 대략 아래와 같이 그릴 수 있습니다. 일반적으로는 크게 문제 될 만한 부분은 보이지 않습니다. 그러나 이 프로세스가 실제로 어떻게 운영되고 있는지 그 속내를 들여다보면, 소위 "회사의 방침"이라는 늪에 빠져 과도한 제한이나 추가 절차를 강요받는 경우가 있습니다.
실제로 저희도 초기에는 굉장히 복잡한 업무 프로세스를 요구받았습니다. 이는 내부 감사 결과, 개발 진행에 있어서 보다 엄격한 승인 절차가 필요해졌기 때문입니다. 일례로 작업을 위한 티켓을 만들 때마다 사전 승인을 받고, 승인 후 업무를 시작해야 한다는 가이드라인이 있었습니다. 아래 그림은 개발 과정을 세분화한 것으로, 각 단계에서 어떤 보고와 승인을 거쳐야 하는지 보여줍니다. 빨간색 박스가 보고, 승인, 확인이 필요한 단계인데요. 빨간색 박스의 개수를 보면 얼마나 많은 보고와 승인이 업무의 허들을 만들고 있었는지 나타냅니다.
그 누가 와서 일하더라도 이런 복잡한 절차와 승인 구조를 이해하는 것은 어려웠고, 급기야 업무 진행에 병목이 되기도 했습니다. 스스로도 이런 불합리한 프로세스를 납득할 수 없었기에 개선안을 제안하고 협의했습니다.
물론 보고와 승인은 조직 운영 측면에서 꼭 필요한 과정입니다. 그러나 그 빈도와 타이밍을 적절히 배치하지 않으면 오히려 서비스의 생산성을 하락시키고 조직을 위축시키는 엉뚱한 상황을 초래하며, 그 피해는 고스란히 사용자에게 전파됩니다. 지나친 절차와 방침은 때때로 배보다 배꼽이 더 큰 상황을 만듭니다. 저는 이 절차에 격렬히 반대했고, 다행히 함께 문제를 개선해 나갈 좋은 리더들이 있었기에 불만과 징징거림을 곁들인 몇 번의 설득을 거친 끝에 현재는 업무 프로세스가 꽤나 단순해졌습니다.
이처럼 저희 팀은 너무 복잡하거나 불필요한 업무 프로세스와 마주했을 때 '어? 이상한데?'라고 본능적으로 느껴지는 감각을 문제로 도출하고 이의를 제기하며 개선해 나갑니다.
성공 사례
전체를 한 번에 바꿀 수 없다면 부분부터 변화시키며 작은 성공 사례를 쌓아 나가야 합니다. 때때로 한 번에 모든 것을 바꾸려는 과욕이 생기기도 하지만 저희가 하는 일은 혼자서 할 수 있는 일이 아니기에 전체를 한 번에 바꾸려는 시도는 꽤 많은 위험을 떠안아야 합니다. 따라서 저희 팀은 한 번에 바꾸기보다는 확실한 작은 성공을 쌓아가는 것을 성과로 여기고 있습니다. 추상적으로 큰 그림을 그리는 것은 누구나 할 수 있지만, 작더라도 확실한 성공을 만들어 쌓아가는 것은 누구나 하지 못하기 때문입니다.
ABC Platform 팀의 모든 프로젝트는 한 번에 여러 문제를 해결하는 게 아니라 단순하지만 하나의 문제를 잡고 핵심까지 파고 들어가 확실하게 해결하는 것을 중요하게 생각합니다. 이를 통해 저희는 그동안 작고 소중한 성공 사례를 쌓아왔습니다.
예를 들어 MessagingHub의 사례를 살펴보겠습니다. 이 프로젝트는 폴링 이슈를 서버 푸시로 전환하는, 단 하나의 문제만 해결하기 위해 시작했는데요. 이제는 플랫폼 속성을 유지한 채 메시징(서버 푸시, 앱 푸시, 이메일, SMS, 채팅 등) 영역 전반으로 기능을 확장해 나가고 있습니다. 아래 그림을 보면 서버 푸시에서 시작된 MessagingHub가 현재에 이르기까지 어떻게 기능적으로 확장하며 성공 사례를 쌓아왔는지 알 수 있습니다.
비단 MessagingHub만이 아닙니다. AccountService, UserFeedback은 물론 앞으로 선보일 또 다른 플랫폼 프로젝트까지, 모두 작은 성공을 차곡차곡 쌓아가면서 동료와 사용자에게 신뢰를 얻으며 성장하고 있습니다. 이 신뢰가 결국 프로덕트를 확장해 나가는 힘을 만듭니다.
태도
저희 팀은 뛰어난 소수로 구성돼 있습니다. 하지만 항상 저희보다 더 뛰어난 다수와 함께 하고 있다는 것을 잊지 않습니다. 소수는 결코 다수를 이길 수 없습니다. 많은 경우 실무에서의 상식도 다수의 논리로 결정됩니다. 그렇기에 자신의 의지로 만들어 가는 것도 중요하지만 다른 사람의 지적을 흡수할 수 있는 포용력과 자존감도 겸비해야 합니다.
물론 때때로 충돌이 발생하는 것은 불가피합니다. 싸워야 할 때 싸우지 않는 것도 비겁하니까요. 그럼에도 중요한 것은 그와 같은 충돌도 건설적인 결론에 도달할 수 있는 소중한 기회로 여기고 생산적인 결과를 도출하려는 태도를 갖는 것입니다.
저희 팀에서 운영하는 각 프로젝트가 지금처럼 확장해 나갈 수 있었던 것은 프로젝트 본연의 필요성뿐 아니라, 이를 만들어 나가는 멤버 한 사람, 한 사람의 마음가짐이 가장 큰 영향력을 끼쳤다고 생각합니다.
팀의 성과
플랫폼 프로젝트의 관점에서 중요한 성과 지표 중 하나는 '얼마나 다양한 서비스 도메인과 컴포넌트에서 활용되고 있는가'일 것입니다. 아래 그림은 MessagingHub와 AccountService, UserFeedback이 데마에칸 서비스의 각 도메인에서 얼마나 활용되고 있는지 간략히 나타낸 것입니다.
이로써 저희는 서비스 내에 폭넓은 접점을 확보했고, 더 이상 데마에칸에 없어서는 안 될 필수 도메인으로 자리매김했습니다.