소개
안녕하세요. 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이 데마에칸 서비스의 각 도메인에서 얼마나 활용되고 있는지 간략히 나타낸 것입니다.
이로써 저희는 서비스 내에 폭넓은 접점을 확보했고, 더 이상 데마에칸에 없어서는 안 될 필수 도메인으로 자리매김했습니다.
리드에 대한 고찰
ABC Platform 팀이 만들어지고 그 팀을 맡게 되면서, 어떻게 하면 함께하는 멤버들이 일을 잘할 수 있는 환경을 만들 수 있을지 고민했습니다. 이는 결국 제가 어떤 사람이 되고 싶은가에 대한 고민이기도 하더라고요. 그 고찰을 말씀드려봅니다.
다중 인격
'나'라는 사람은 물리적으로 한 명의 사람이지만 주어진 상황에 따라 부여되는 역할이 다릅니다. 부모님에게 는 자식이고, 아내에게는 남편이며, 자녀에게는 아빠이듯 말입니다. 각 역할에는 주위에서 기대하는 말과 행동이 있으며, 종종 그 역할의 이해관계가 상충되는 상황이 발생합니다.
이로 인해 ABC Platform 팀이 만들어졌을 때 때 혼란스러운 부분이 있었습니다. 저는 그동안 회사에서 언제나 직책없이 개발자로 정의돼 왔고, 아직도 여전히 하나의 프로덕트를 담당하는 개발자이지만, 팀 운영을 겸하게 되면서 주위에서 기대하는 역할이 또 하나 추가되었습니다. 개발자로서의 저는 직설적이며 충돌을 피하지 않습니다. 반면 리드로서는 그렇게 하면 안 되거나 보다 조심해야 할 경우가 훨씬 더 많습니다.
그래서 팀원분들께 다중 인격이 되겠다고 말씀드렸습니다. 농담이 조금 섞인 상황이기는 했습니다만, 개발자로서의 저 때문에 힘들다면 팀을 보살펴야 할 또다른 제가 잘 정리해 보겠다며 3자 화법을 쓴 적도 있었습니다.
물론 언제나 그렇듯 저는 종종 실수를 하고 있고, 간혹 역할간 스위칭을 제대로 못해서 후회하고 반성할 때도 있습니다.
개발자로서의 자신도 중요하고, 멤버들과 함께 이 팀을 잘 꾸려나가야 하는 것도 잘해내야 합니다. 그럼에도 때때로 다중 인격내에서 최적화된 하나를 고르기가 힘들때도 있습니다. 어떻게 스위칭할지 딜레마를 느끼는 순간이 있는 것인데요. 저는 그 고민마저도 솔직하게 멤버에게 말하고 양해를 구하며 최대한 모두에게 실용적인 방향으로 나아가려고 합니다.
매니징을 최소화
매니징은 필수 업무입니다. 그러나 소위 마이크로 매니징을 하게 되면 팀원들의 피로도가 상당히 높아집니다. 마이크로 매니징은 자신이 편하게 일하고 싶거나 혹은 권 위를 행사하고 싶을 때 벌어지는 큰 실수 중 하나라고 생각합니다. 따라서 매니징으로 인한 팀원의 피로도가 불만으로 터지지 않도록, '알아서 잘 파악하는 것'도 리더에게 필요한 소양이라고 생각합니다. 저는 최대한 알아서 파악하려고 노력하고 있고, 보고를 받는 등의 행위를 최대한 지양하고 있습니다.
이를 위해 회사의 시스템을 최대한 활용해 자체적인 트래킹을 진행하고 있는데요. 예를 들어 이슈 티켓을 기반으로 실질적으로 진행하는 업무가 무엇인지를 모니터링합니다. 저희 팀 모두를 조회할 수 있는 필터 조건 하나만 등록하면, 아래와 같이 각 팀원별 이슈 진행 상황을 대시보드로 시각화할 수 있습니다.
또한 GitHub과 Confluence에서는 Watching 기능을 사용하고 있습니다. Watching을 등록하는 것만으로도 메일을 통해 저희 팀 내에서 어떤 작업들이 진행되고 있는지 알 수 있기 때문입니다.
커뮤니케이션 도구로 사용 중인 Slack에서는 저희 팀 멤버들이 어떤 채널에서 누구와 무슨 대화를 나누고 있는지 쉽게 검색해 볼 수 있습니다.
위와 같은 과정을 통해서 어떤 주제로 업무를 진행하고 있고, 도움이 필요한 것은 없을지 등을 파악하기 위해 노력합니다. 물론 그럼에도 팀 운영 관점에서 최소한의 그라운드 룰은 필요하다고 생각합니다. 그래서 저희는 아래와 같이 그라운드 룰을 정했습니다.
- 금요일마다 본인의 주간 업무를 간략하게 적는다. (회의는 하지는 않으며, 각자 알아서 적으면 됨)
- 팀 회의는 월 1회로 한다.
- 업무는 티켓으로 관리한다.
- 1 on 1(전사적으로 시행하는 리드와 팀원의 일대일 미팅)할 때는 반드시 법인 카드로 음료를 마신다.
1, 2, 3번에 해당하는 주간 업무와 팀 회의, 티켓 관리의 경우 강제는 아닙니다. 다만 지속적으로 룰을 어긴다는 것은 무언가 어려운 사정이 있다는 뜻이기도 하기에 이런 경우 1 on 1을 통해서 대화하며 풀어나가려고 합니다(솔직히 이마저도 강제성을 두지 않습니다).
여기서 오해하면 안되는 점은, 매니징을 최소화한다는 것이 팀원에 대한 관심을 끊는 것은 아니라는 점입니다. 포인트는 매니징으로 인한 '팀 멤버의 스트레스를 최소화한다'는 것입니다. 그렇기에 회사 시스템을 최대한 이용하면서 조용히, 그리고 알아서 잘 파악하려고 노력해야 합니다. 비유하자면 마치 더 좋아하는 사람이 더 많은 관심을 갖고 시간을 쏟게 되는 논리와 같습니다. 그들에게 '매니징 당한다'는 느낌을 주지 않으면서도 목적을 달성할 수 있는 환경을 만들어 줄 수 있도록 노력해야 하며, 이때 중요한 것은 그 노력을 팀원에게 전가해서는 안됩니다.
개인의 업무적 이기심은 최대화
개인은 이기적입니다. 그리고 일을 더 잘 하고 싶은 업무적 욕심에서 나오는 이기심은 최대한 들어주는 게 리더의 역할 중 하나라고 생각합니다. 이를 위해 저는 각 팀원에게 가장 좋은 환경이 무엇인지 함께 고민하고, 각자에게 최선의 상황을 만들어 주기 위한 방법을 함께 모색하고 있습니다. 그 결과 지금까지 두 개의 프로젝트를 더 좋은 업무 환경 혹은 동료 간 시너지를 더욱 잘 낼 수 있는 조직으로 이동시키거나 TF로 구성해 주는 등의 조치를 취했는데요. 이를 통해 프로젝트의 실무 멤버들은 업무에 더욱 몰입할 수 있는 환경에서 일할 수 있게 됐습니다.
물론 이런 결정을 내릴 때 그 방향이 프로젝트를 담당하는 각자에게 최선의 선택이란 합의가 있었습니다. 제게 권한이 많은 것은 아니지만, 그럼에도 멤버의 이기심에 당위성을 부여하고 논리적인 바탕을 만들어서 그래야만 하는 이유를 함께 주장합니다. 이해할 수 있는 개인의 업무적 이기심은 함께 응원하고 도와야 한다고 생각하기 때문입니다.
개인의 잠재력을 극대화하는 방법 중 하나는 해야만 하는 일이자 하고 싶은 일을 할 수 있는 환경을 만드는 것입니다. '이기심'이란 단어에 마냥 부정적인 생각을 가질 필요는 없습니다. 일을 더 잘 하고 싶어서 생겨난 이기심은 개인의 전문성과 열정을 실현하려는 욕구로 재정의할 수 있으며, 이는 저희 팀의 독특한 에너지를 만들어 내는 힘이라고 생각합니다.
팀 운영 체계를 엔지니어링하기
여러 명이 하나의 팀으로서 프로젝트를 만들어 가기 위해서는 체계가 필요합니다. 그 체계는 업무 프로세스가 될 수도 있고, 그라운드 룰이 될 수도 있으며, 회사의 방침이 될 수도 있습니다.
이런 체계 속에서 실무자와 가장 가까이 맞닿아 있는 위치에서 누가 리드가 되느냐는 팀원에게 매우 중요한 사안일 수 있는데요. 그럼에도 저는 누가 해도 잘 운영되는 팀으로 만들고 싶습니다. 이는 하나의 역할일 뿐이라고 생각하며, 팀의 질적 수준이 그 한 사람에 의해 좌우되지 않는 체계를 만들고 싶습니다. 이를 위해 불필요한 업무 진행 단계를 축소하는 등 한 사람에게 몰리는 의존도를 낮추는 방향으로 ABC Platform 팀의 운영 체계를 엔지니어링해 나가고 있습니다.
ABC Platform의 미래와 현재
저희가 생각하는 ABC Platform 팀의 미래와 현재는 다음과 같습니다.
미래
각 프로젝트는 자신들마다의 마일스톤을 하나씩 달성해 가면서 각자의 장밋빛 청사진을 그리고 있습니다. 앞으로 저희 팀이 해내야 할 것은 지금까지 해 온 것들보다 더 많습니다. 준비해 왔던 각 프로젝트의 주요 기능을 새롭게 선보일 것이고, 이를 통해 더 많은 사용자의 요청과 트래픽을 처리할 것이고, 결과적으로 고객 경험을 극대화해 서비스의 효율을 높여 갈 것입니다. 그렇게 언젠가 각 프로젝트는 독립적인 팀으로써의 방향성과 의지를 갖고 각자의 방향으로 뻗어 나가리라고 기대합니다.
현재
저희의 당면 목표는 데마에칸 서비스가 성공할 수 있도록 최선의 힘을 다하는 것입니다. 이를 통해 또 하나의 성공 사례를 만드는 것이 중요합니다. 이 사례가 그다음에 그릴 미래의 첫 페이지가 될 것이기 때문입니다.
마치며
ABC Platform 팀은 2023년 4월 1일에 탄생해서 이제 갓 한 살이 되었습니다. 당 연하게도 일 년 동안 마냥 좋은 일만 있었던 것은 아닙니다. 팀이라는 것은 작은 사회이다 보니 때때로 불협화음이 생기기도 하는데요. 부끄러운 반성과 격려와 응원을 주고받으며 그렇게 팀도 개인도 성장해 왔고, 앞으로도 성장해 갈 것입니다.
구체적으로 프로젝트나 팀원 이야기가 나오지 않아 아쉬운 독자분들이 계실 것 같습니다. 이 글에서 다하지 못한 저희의 이야기를 앞으로 하나씩 소개하며 풀어 나갈 예정이니 기대해 주시기 바랍니다.
