스타트업은 체계가 없는 곳이에요. 일을 주먹구구식으로 한다니까요?
스타트업에 있다 보면 “우리 회사는 일하는 체계가 없다“ 라는 이야기를 심심치 않게 듣습니다. 일하는 방식이 정해져 있지 않고, 그때그때 구두로 내려온 일을 쳐내기 급급하다는 불만을 같이 토로하기도 합니다. 일을 잘하기 위해 글을 찾아보면 ‘개발을 잘하고 커뮤니케이션을 잘하자’라는 좋은 글이 많지만, 팀이 어떻게 움직이는지에 대한 글은 흔치 않습니다.
오늘은 하나의 로드맵을 향해서 모인 히어로들이 일하는 방법에 대한 이야기를 풀어볼까 합니다. 예시로 광고 성과 측정 파트너(MMP) 중에서 Airbridge가 최초로 제공한 카카오 비용 연동 작업을 함께 살펴보겠습니다.
Airbridge 프로덕트 개발 프로세스
1. 고객사 요청사항과 아이디어 수집
작업의 첫 시작은 해결하고자 하는 문제를 잘 정의하는 것으로부터 시작합니다. 고객의 목소리로부터, 혹은 AB180 내부로부터 프로덕트를 사용하면서 느꼈던 불편한 점이나 개선해야 할 기능들을 ideapark로 불리는 기능 제안 목록 시트로 보냅니다. 이렇게 쌓인 제안은 주기적으로 그루밍을 진행합니다. 문제를 해결하면 어떤 고객에게 영향을 미치는지에 대해서 맥락을 파악하고 목표를 정하며 티켓화합니다.
.png&blockId=9151b030-a773-4492-b61a-a2269a5dce33)
고객사에게 필요한 기능인 ‘카카오 비용 연동’에 대해서 전달해주시는 Marketing 팀 리드 재문님.
카카오 비용 연동 작업도 고객의 아픔에서 시작했습니다. 마케터는 광고의 성과를 보기 위해서 성과 측정 서비스에서 측정한 데이터와 광고 매체에 사용한 비용 데이터를 각각 다운로드받아서 합쳐보고 있었습니다. 고객은 리포트를 만드는 과정을 시간을 들여 손수 하고 있었고 이를 빠르고 손쉽게 자동화 하길 원하고 있었습니다. 마케팅 팀에서는 고객의 아픔을 파악하였고 프로덕트를 개선하기 위해 ideapark로 의견을 제안했습니다.
2. 우선순위를 고려해여 해결 해야하는 문제 선정
ideapark에 쌓인 제안들은 주마다 우선순위를 산정합니다. 어떤 문제가 있는지, 문제를 해결하면 어떤 고객에게 영향을 미치는지에 따라서 맥락을 파악하고 목표를 정한 다음 티켓화합니다. 티켓은 우선순위에 따라 분류되어 다음 할 일은 스프린트로 올라갑니다.
3. 선정된 문제를 작업
할 일이 잘 선정되었다면 이제는 본격적으로 작업을 시작할 때 입니다. 작업은 다음 단계로 구성됩니다.
•
Kick-off 진행
•
Tech Spec 작성
•
Code 작업
•
QA & Code Review
•
Release
이제 각 단계에서 개발자가 어떻게 참여하는지 살펴봅시다.
API 팀이 주도하는 프로세스
1. Kick-off
더 많은 맥락을 작업 전에 가져가기
카카오 비용 데이터를 연동하기 위해 PM과 UX 담당자는 어떤 식으로 기능을 제공해야 고객이 만족할 수 있는지 고민하기 시작합니다. 킥오프 과정에서는 사용자 흐름에 대한 화면을 설계하며 티켓의 목표, 범위, 사용자 시나리오를 구체화 시켜나갑니다. 이 과정에는 개발자 역시 참여합니다.
왜 킥오프에 개발자가 참여해야 하나요?
개발자는 개발만 하면 되니까 킥오프에 참여하지 않아도 될까요? 아닙니다. IT회사에서 기술 없이 기획은 불가능합니다. 킥오프에 참여해서 개발자는 다음의 목적을 달성합니다.
1.
어떠한 작업인지 파악하고 학습
•
광고 도메인은 여러 플레이어와 함께 움직이고 있으며 빠르게 변화하고 있습니다. 그 때문에 해당 티켓이 어떤 맥락에서 나왔는지 확인하고 필요한 도메인 지식을 습득합니다.
•
킥오프 과정은 새로 참여하는 개발자나 오랜 기간 개발해온 시니어 개발자에게도 같은 맥락을 가지고 해결해야 하는 문제를 공유할 수 있게 합니다.
2.
사용자 시나리오를 보고 기술적인 의견을 제시
•
해당 기능이 기술적으로 구현 가능한지 확인합니다.
•
UX를 해치지 않는 선에서 좀 더 빠르게 사용자에게 기능을 제공할 방법을 함께 모색합니다.
카카오 비용 연동 티켓에서도 개발자가 킥오프에 참여했습니다. 카카오 연동은 API를 사용함에 있어서 일반적인 OAuth 연동 방식에 추가로 REST API Key가 필요했던 등 여러 고려해야 하는 사항들이 있었는데요. 개발자가 킥오프 준비 과정에서 같이 파악하고 공유하면서 유저 시나리오를 같이 설계했습니다. 만약 개발자가 참여하지 않았다면 어떻게 되었을까요? 잘못된 시나리오 설계로 인해 개발하던 도중 다시 재설계 해야 하는 아찔한 상황을 겪게 될 수도 있었겠네요.
2. Tech Spec 작성
기술적으로 더 나은 방향으로 갈 수 있게 동료와 함께 검증하기
구현해야 하는 기능에 대한 논의가 충분히 이루어지고, 사용자 흐름에 대한 화면 정의를 구체화하면 개발자는 테크 스펙을 작성합니다. 테크 스펙은 개발자가 티켓의 목표대로 기능을 구현하기 전에 어떤 방식으로 구현할 것인지 작성한 문서인데요. 작업 전 문서를 작성함으로써 다음과 같은 효과를 얻습니다.
•
티켓이 잘못된 방향으로 흘러가는 것을 막아줍니다.
•
동료 작업자도 비슷한 수준의 맥락을 가질 수 있게 됩니다.
•
기술적으로 타당한지 미리 검토하고 오버 엔지니어링을 막을 수 있습니다.
어떤 내용이 들어가나요?
작성된 테크 스펙의 Expected FAQ 일부. Platform API 팀 도현님이 논의하는 모습
또한 API팀에서는 30% 룰을 가져가고 있는데요. 해결해야 하는 목표와 목표가 아닌 것을 명확히 한 다음, 어떤 방식으로 수행할 것인지에 대해 전체 계획의 30% 정도 되는 핵심 코드를 문서에 포함해서 하도록 합니다. 미리 코드를 살펴보는 과정으로 이미 비슷하게 구현된 다른 구현체들도 파악하고, 실현 가능한 계획을 세울 수 있도록 합니다.
Tech Spec을 리뷰하는 방식
작성을 시작하면서 한 가지 더 정해야 하는 것이 있는데요. 바로 카운터파트입니다. 테크 스펙을 만들고 코드를 구현할 메인 작업자와 스펙을 검토하고 이후 코드를 검토할 같은 팀의 카운터파트가 작업에 함께 합니다. 작성된 문서는 카운터파트가 기술적으로 문제없는지 검수하고, 더불어 Front의 담당자와 함께 Request / Response의 스펙을 검토하고, 티켓의 방향과 설계가 일치하는지 PM, UX, UI 담당자가 함께 리뷰합니다.
3. 코드 작업
테크 스펙에 작성한 대로 작업하기
작업은 테크 스펙에 적은 계획대로 수행합니다. 작업 간 해결해야하는 이슈가 있거나 동료 작업자가 알아야할 내용이 생겼다면 적극적으로 작업 티켓 채널에 공유합니다. 꼼꼼하게 리뷰를 거친 테크 스펙이었지만 예상치 못했던 부분이 생기는 것은 너무나도 당연합니다. 이럴 경우 스펙 문서의 수정이 필요함을 티켓 채널에 알리고 해당하는 부분을 다시 리뷰 받습니다.
.png&blockId=232900a8-747e-4dbe-be52-c5868488d407)
우선 순위가 급한 작업으로 인해서 작업 Due가 변경되었음을 알려주는 Platform API팀의 범수님
모든 코드는 테스트 코드가 필요하다
모든 코드는 상응하는 테스트 코드의 작성이 필요합니다. AB180 엔지니어링 그룹은 테스트 코드를 매우 중요하게 생각합니다. 테스트 코드를 통해 기능을 손수 테스트하는 과정을 줄이고 함수와 기능들이 입력에 대해 기대한 결과를 보장할 수 있도록 합니다. 예를 들어서 카카오 비용 연동을 위해 외부 API를 호출하는 테스트는 1. 원하는 입력을 받아서 API를 호출하는지, 2. 잘못된 입력이 왔을 때는 함수가 어떻게 처리하는지, 3. API가 기대한 응답이 아닐 땐 어떤 에러를 내는지 등 다양한 케이스에 대해서 테스트 코드를 작성하여 스펙대로 동작함을 검증합니다.
4. QA & Code Review
자동화된 시스템으로 사람이 덜 검증하기
QA를 도와주는 시스템
만들어진 API는 어떻게 테스트하고 QA 해야 할까요? 검수를 위해서 로컬 서버를 띄우고 담당자들을 모두 불러서 테스트하도록 해야 할까요? API팀은 github 브랜치를 생성하면 CD(Continuous Deployment)를 통해서 작업의 결과물을 서버에서 확인할 수 있도록 Feature branch 파이프라인을 구성해두었습니다.
작업자는 브랜치를 생성하기만 하면 됩니다. 미리 구성된 파이프라인은 AWS Lambda에 해당 코드를 배포하고, 로드밸런서와 연결해서 접속할 수 있는 Endpoint를 제공합니다. 해당 과정은 모두 자동화 되어있기 때문에 개발자는 배포에 대해 신경 쓸 필요가 없습니다. 이렇게 생성된 Feature branch에 Front 팀은 작업한 카카오 연동 UI 페이지를 연결함으로써 PM, UX, UI팀이 QA를 진행할 수 있도록 만들어줍니다. 한곳에 모이지 않고 QA 해도 되겠네요!
모든 테스트와 배포는 개발자가 직접 하지 않고 자동화
Code Review를 도와주는 시스템
QA가 어느 정도 진행되고 코드 변경사항이 줄어들면 코드 리뷰를 시작합니다. 코드 리뷰 단계에서는 테크 스펙을 검토했던 카운터파트를 중심으로 리뷰를 진행합니다. 카운터파트는 테크 스펙에 적힌 대로 구현이 되었는지 확인하고 혹시나 있을지 모르는 버그를 찾아내는데 주력합니다. 이때 리뷰어를 도와주는 자동화된 시스템이 두 가지가 있습니다.
1.
CI를 통한 테스트 코드 수행 자동화 및 코드 커버리지 측정
•
수정사항에 대한 기존 기능의 원활한 동작을 보장할 수 있도록 CI에서 테스트를 수행합니다. 영향을 받는 다른 함수들도 기존의 동작을 보장받을 수 있습니다.
•
새로 작성된 코드에서 테스트가 작성되지 않은 부분을 체크하고 리뷰어에게 알려줍니다. 작업자는 특별한 이유가 없다면 반드시 테스트 코드를 작성하는 것을 원칙으로 합니다.
2.
누가 만들더라도 일관된 코드가 나올 수 있도록 검사
•
black이나 flake8 같은 코드 스타일 체크, 코드 정적 검사 도구를 CI에서 실행합니다.
•
이를 통해 문제를 미리 발견하고, 일관된 코드 스타일을 유지합니다.
CI에서 실패한 PR은 Master로 병합될 수 없습니다. 자동화된 시스템을 통해서 사전에 코드를 검증함으로써 개발자가 신경 써야 하는 일을 줄이고 해야 할 일에 집중할 수 있게 만들어줍니다.
5. Release
동료와 함께 더 나은 프로덕트를 만들었음을 축하하기 
리드로부터 릴리즈 사인을 받으면 기능을 릴리즈합니다. 코드를 master에 반영하면 배포 파이프라인을 통해서 자동으로 배포됩니다. 릴리즈 후 해당 기능을 다시 테스트해보며 production 서버에 릴리즈가 반영되었는지 확인하고, 모니터링을 통해 배포가 문제 없이 되었는지 확인합니다.
.png&blockId=2f019560-5db8-4a4b-8f80-d397ae14d648)
kakao da 비용 연동 기능이 릴리즈 되었음을 알리는 Design 팀 리드 양연님
성공적으로 끝났다면 더 나은 프로덕트가 되었음을 구성원 전체에게 알립니다. 카카오 비용 연동이 배포되었고 어떻게 연동할 수 있는지를 정리해서 공유합니다. 릴리즈 노트를 읽는 분들은 티켓과 함께한 작업자분들을 이모지로 달면서 함께 축하합니다. 이렇게 광고 성과 측정 파트너(MMP) 중에서 Airbridge는 최초로 카카오 비용 연동 기능을 제공할 수 있게 되었습니다.
프로세스를 통해서
프로세스를 통해 동료 작업자들이 피드백을 받을 수 있는 사이클을 짧게 만들고, 개발 단계를 투명하게 만들었기에 기능에 오류가 날 가능성은 점차 줄었습니다. 실제로 지금의 프로세스가 점차 발전하면서 새 기능 배포로 인한 에러 발생 비율은 같은 기간 대비 18%까지 낮아졌습니다. 또한 작업자들은 각 단계에서 해야 할 목표가 명확하기에 기민하게 움직일 수 있게 되었고, 단위가 작은 티켓은 5일 만에 릴리즈 할 수 있게 되었습니다.
처음부터 우리가 이런 견고한 프로세스를 가지고 있던 것은 아니었습니다. 테크 스펙, Feature branch, QA 등의 프로세스가 지금처럼 발전하고 성숙해진지 그리 오랜 시간이 흐르지 않았습니다. 프로덕트가 발전되는 만큼 업무 프로세스도 같이 개선했고, 블록 쌓아가듯 개선된 개발 프로세스는 견고한 프로덕트를 빠르게 제공할 수 있는 환경을 만들었습니다. 앞으로 새로운 문제가 나타나 지금 프로세스가 작동하지 않을지도 모릅니다. 하지만 우리는 계속 개선해 갈 겁니다. 늘 그랬듯이요.
ᴡʀɪᴛᴇʀ
Wonkyun Lim @Corikachu
Backend Software Engineer @AB180
