뱅크샐러드 기술 블로그로 엿보는 개발 문화.
PM이 알아야 할 개발 지식
22년의 시작과 함께 핀테크 업계에서는 마이 데이터로 인한 변화의 물결이 시작되었습니다. 뱅크샐러드에서도 직관적으로 변한 UIUX, 연동 절차 등 여러모로 이전보다 사용성이 높아진 변화를 발견할 수 있었습니다. 뱅크샐러드는 이번 개편을 위해 스쿼드 조직을 새로 꾸려서 야심차게 준비했다고 하는데요, 효과적인 업데이트를 위해 내부적으로 상당한 논의가 있었을 것입니다.
프로덕트의 개선을 위해 개발자, PM, 디자이너 등의 이해관계자가 어떠한 논의를 했는지, 어떠한 결과물을 배출할 수 있었는지는 기술 블로그를 통해 어렴풋이나마 엿볼 수 있습니다. 뱅크샐러드가 지금의 형태를 갖추기까지는 1.0 - 2.0과 같은 업데이트를 거치며 서비스에 커다란 변화가 있었어요. 과연 어떤 개발 문화와 함께 뱅크샐러드가 성장해왔을지 개발 블로그를 통해 들여다보도록 하겠습니다.
기술 스택
따로 개발 블로그에 정리되어있지는 않아 직접 찾아서 정리했습니다.
SQL(관계형 데이터베이스)인 MySQL과 NoSQL(비관계형 데이터베이스)인 MongoDB를 같이 사용한다는 점이 흥미로웠습니다. 뱅크샐러드 기술 블로그에 따르면, 원래는 MongoDB로 데이터를 관리했으나 복잡도가 늘어나면서 NoSQL의 유연함이 성장의 발목을 잡았다고 합니다. 따라서 MySQL을 도입해 기술 복잡도를 낮춘 것으로 보입니다.
복잡도를 제어하기 위한 방법은 아래 포스팅에 자세히 나와있습니다.
개발 문화
기술 블로그 통해 눈에 띄는 뱅크샐러드의 코드 리뷰 개발 문화를 살펴보겠습니다.
(1) 작은 PR 규칙, Github와 비동기 커뮤니케이션
코드 리뷰란 개발자가 작성한 코드를 다른 사람들이 검토하고 피드백을 전달하며, 다시 작성자가 반영하는 과정을 말합니다. 코드 리뷰를 통해 서로의 개발 스타일을 이해할 수 있으며 일관된 아키텍쳐를 유지할 수 있습니다. 또한, 잠재적 오류의 발생 가능성을 낮춰 전반적인 서비스 운영 비용을 절약할 수도 있습니다. 뱅크샐러드는 코드 리뷰를 통해 조직이 스케일업하며 겪을 수 있는 복잡한 문제들을 해결해왔다고 합니다. 그 이면에는 작은 PR 규칙 문화가 있습니다.
작은 PR 규칙
코드 리뷰 문화가 성숙해지기 전에는 PR의 코드 라인 수에 대한 규칙이 없었다고 합니다. 따라서 코드의 길이는 점점 늘어났고 리뷰어의 집중도는 떨어지는 문제점이 발생했다고 합니다. 이를 해결하기 위해 탄생한 것이 '작은 PR 규칙'입니다. 이 규칙은 <1개의 PR은 1,000 Line을 넘을 수 없다> 는 내용을 담고 있습니다. 도입 초기에는 여러 의문과 우려가 생산되었지만, 몇 차례의 코드 리뷰를 진행하면서 노하우가 쌓여나갔고 이는 리뷰 병목 해소와 조직의 확장성에 큰 영향을 주었다고 합니다.
출처 = 뱅크샐러드 기술 블로그 / 작은 PR 규칙 피드백Gihub와 비동기 커뮤니케이션
비동기 커뮤니케이션은 Jira, Slack, 메일 등을 통한 커뮤니케이션을 뜻합니다. 뱅크샐러드는 비동기 커뮤니케이션을 통해 개인의 업무시간을 존중하며, 조직의 성장과 함께 커지는 커뮤니케이션 비용을 줄이기 위해 노력하고 있다고 합니다. 코드 리뷰 또한 비동기 커뮤니케이션으로 하기 위해 Github Pull Request(이하 PR)를 코드 리뷰의 툴로 사용하고 있다고 합니다.
(2) 실험 플랫폼
뱅크샐러드는 스스로를 진정한 실험 조직이라고 칭합니다. 2020년 11월 기준 뱅크샐러드 iOS 앱 내에서는 50개의 크고 작은 실험들이 동시에 진행되었다고 하는데요, 이는 모바일 개발자의 관점에서는 50개의 대조군, 50개의 실험군의 코드를 동시에 제어해야 한다는 것을 뜻합니다. 추가적으로 신규 실험이나 기존 실험의 종료도 대처해야 하므로 높은 복잡도를 제어해야 합니다.
출처 = 방크샐러드 / 주차별 누적 실험 생성 추이기술 블로그를 보며 무척이나 흥미로웠던 부분은 작은 PR 규칙과 실험 플랫폼이 만나 이뤄낸 시너지 효과였습니다. 이 조합은 2020년 6월 출시한 뱅크샐러드 2.0 UI UX 개편 프로젝트에 큰 영향을 끼쳤다고 합니다.
출처 = 뱅크샐러드 기술 블로그 / UI/UX 개편뱅크샐러드 2.0 개편은 많은 화면이 신규 개발되는 규모 있는 프로젝트였습니다. 매주 정기 배포를 병행하는 상황이었기 때문에 메인 브랜치와 뱅크샐러드 2.0 개발 브랜치를 효율적으로 관리할 수 있는 Git Branch 전략이 필요했다고 합니다.
뱅크샐러드는 복잡도를 최소화하기 위해 '작은 PR'과 '실험 플랫폼'의 특징을 살려 Git Branch 전략을 세웠습니다. (작은 PR - 개발하고자 하는 기능을 최소 단위로 분리한 코드, 실험 플랫폼 - 고객이 사용하는 OS, 앱 버전에 따라 실험군 / 대조군을 지정)
이 두 가지의 특징을 살리면 전체 기능이 개발 완료되지 않더라도 리뷰가 완료된 작은 PR이 메인 브랜치에 merge(합병)할 수 있어집니다. 이는 결과적으로 빠른 실험을 가능하게 만듭니다.
출처 = 뱅크샐러드 기술 블로그 / 실험 플랫폼 이전의 Git Flow
출처 = 뱅크샐러드 기술 블로그 / 실험 플랫폼 이후의 Git Flow이 두 이미지를 비교해보면 이전의 Git Flow에서는 완성된 뱅크샐러드 2.0 브랜치를 메인 브랜치와 Merge(합병)해야 하기 때문에 감당할 수 없는 양이 충돌이 발생할 것으로 예상됐습니다. 하지만, 실험 플랫폼 이후의 Git Flow에서는 개발하고자 하는 기능을 최소 단위로 분리해 전체 기능 개발이 완료되지 않더라도 작은 PR로서 메인 브랜치 merge(합병)이 가능해집니다.
결과적으로 뱅크 샐러드 2.0 프로젝트는 약 2달의 기간 동안 +6만 -3만 라인의 변경점의 규모 있는 코드를 세분화/개발하여 충돌과 리뷰로 인한 병목 없이 고객에게 성공적으로 오픈할 수 있었다고 합니다.
(3) 커뮤니케이션 문화 - 저 문맥(Low Context) 커뮤니케이션, Pn 룰
저 문맥(Low Context) 커뮤니케이션
뱅크샐러드는 코드 리뷰 과정에서 리뷰의 요청과 피드백도 충분한 문맥을 제공해야 한다는 원칙을 가져가고 있다고 합니다. 추가적인 커뮤니케이션이나 미스 커뮤니케이션으로 발생하는 비용이 매우 비싼 비용이라는 문제의식을 갖고 있기 때문이라고 하네요. 따라서 리뷰 요청자는 리뷰어가 사전 지식이 없는 상태에서 리뷰에 참여한다는 가정으로 모든 문맥을 제공해야 한다고 합니다.
출처 = 뱅크샐러드 기술 블로그간단하지만 리뷰어에게 PR에 대한 모든 Context를 공유하고 있는 모습입니다. 복잡한 유저 액션이 포함된 PR의 경우 GIF를 적극 활용하여 리뷰어의 이해를 돕고 있다고 합니다.
Pn룰
뱅크샐러드 기술 조직에서는 코드 리뷰의 코멘트에 Pn룰을 사용하여 리뷰어가 코멘트를 강조하고 싶은 정도를 표현한다고 합니다. 이 부분이 굉장히 흥미로웠는데요, 비언어적 표현으로 인해 표현하고자 하는 바를 명료하게 정리할 수 있는 좋은 문화 같습니다.
P1 : 꼭 반영해주세요 (Request changes)
P2 : 적극적으로 고려해주세요 (Request changes)
P3 : 웬만하면 반영해 주세요 (Comment)
P4 : 반영해도 좋고 넘어가도 좋습니다 (Approve)
P5 : 그냥 사소한 의견입니다 (Approve)
이러한 Pn룰은 코드 리뷰 외에도 슬랙 등 텍스트로 커뮤니케이션을 하는 곳에도 활용되고 있다고 합니다.
PM이 이해해야 할 기술 요소의 범주
지금까지 (PM의 시선으로) 뱅크샐러드의 기술 블로그를 엿보았습니다. PM은 개발을 할 줄 알아야 하는 것은 아니지만 효과적인 커뮤니케이션을 위해 최소한 개발단의 상황이 어떻게 진행되고 있는지 파악할 수 있을 정도의 개발 지식은 필요합니다.
개인적으로 기술 요소의 기본을 이해하는 데 가장 도움이 되었던 책은 <비전공자를 위한 이해할 수 있는 IT 지식>입니다. IT업계 비전공자들에게는 거의 필독서이죠. 데이터베이스, API, JSON, GIT 등에 대한 다양한 지식이 아주 쉬운 언어로 담겨있습니다. (그러고 보니 오늘은 GIT에 대한 내용을 꽤 다뤘네요.)
PM은 이해관계자와 원활한 소통을 위해 프론트엔드, 백엔드 그리고 이 둘을 잇는 API에 대한 기본적인 이해를 갖추고 있어야 합니다. 또 하나 알아두면 좋을 부분이 SQL에 관련된 부분인데요. SQL로 직접 데이터를 추출해야만 하는 것은 아니지만 분석해야하는 데이터가 어디로부터 오는지, 데이터에 대한 기본적인 이해는 갖추고 있는 것이 좋습니다. 담당 서비스에서 실제 어떠한 방식으로 데이터가 추출되고 있는지 확인해보며 알아나가는 것도.. 노가다일테지만 좋은 방법인 듯합니다. (개발자분들은 비개발자들이 배우려는 열의를 보였을 때 굉장히 친절하게 알려주신다고 해요?! ㅎㅎ)
PM의 주요 업무
개발 블로그로 뱅크샐러드 PM의 주요 업무를 살펴볼까요?
1. Task managing
PM은 Github, Jira 등의 업무 공간에서 이뤄지는 팀원들의 모든 Action을 이메일로 받아 실시간 Task를 파악하고 여러 팀의 프로덕트 스펙을 개발 가능한 단계까지 리뷰해야 합니다. Jira 티켓으로 여러 팀의 요청 업무를 파악하고 우선순위에 따라 적절한 담당자를 배정합니다. 팀원이 일을 진행하는 동안 실시간으로 팔로업하며 Blocker를 제거하며 모든 팀원을 서포팅해야 합니다.
2. 문제를 함께 해결하기
PM은 팀원의 문제를 빠르게 파악하고, 같이 고민하고, 적절한 해결방법을 제시해야 합니다. 업무 디렉션, 팀원 충원 등 팀원이 해결하기 원하는 문제를 각각 적절한 방법으로 함께 해결해 나가야 하기 때문에 높은 역량이 요구됩니다.
3. 프로세스 만들어 생산성 올리기
PM은 팀원들이 일하는 방식을 미리 고민해야 합니다. 예를 들어, 신규 입사자를 위한 온보딩 문서를 만들거나 면접 기준을 만들거나 코드 리뷰 규칙(엔지니어링 PM)을 만드는 등 여러 업무 단계에서의 기준을 세워야 합니다. 사람 손이 필요한 절차는 최대한 자동화하여 실행 비용을 낮추는 것이 좋습니다.
기술 블로그를 엿보는 일은 꽤 재밌습니다. 비록 너무(?) 개발 이야기가 가득할 때에는 정신이 아득해지지만 여러모로 배울 부분이 많아요. 개인적으로 저는 서비스마다 사용하는 데이터베이스의 차이나 그 원인을 알아가는 과정이 꽤 흥미로웠어요. 부트캠프 세션 때는 NoSQL을 사용하는 서비스가 생각보다 많지 않다고 스쳐 지나가듯 들었던 것 같은데 NoSQL인 몽고DB를 사용하는 서비스나 관계형, 비관계형 데이터베이스를 같이 사용하는 프로덕트가 엄청 많더라구요. 그 이유를 알아가는 재미 :> 외계 개발자 분들 머릿속을 엿보는 느낌... 입니다. 하하. 강남 언니, 우아한형제들, 뱅크샐러드, 스포티파이 등 굉장히 많은 서비스가 기술 블로그를 운영 중입니다. PM, 개발자 분들에게 도움이 될만한 여러 기술 블로그를 첨부하며 포스팅을 마쳐보겠습니다.
본 포스팅은 PM 부트캠프 당시 제출했던 과제를 옮겨 작성하였습니다.
참고 자료
뱅크샐러드 기술 블로그
