'핀다' 개발팀이 스크럼, 코드리뷰 개선한 방법

국내 유명 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하는 걸까요?

이번 글에서는 핀테크 기업 핀다의 백엔드 개발자가 핀다의 개발 문화를 소개합니다.

안녕하세요, FINDA 현금그로스 PG 자산/신용관리 PT 백엔드 개발자 김형래입니다.

이번 글에서는 제가 팀빌딩을 하면서 고민했던 내용과 FINDA 현금그로스 PG 개발 문화의 과거와 현재에 대해서 이야기해 보려고 합니다. FINDA 내에는 다양한 PT가 있고, 여러 PT가 하나의 PG로 모여 일합니다. 다수의 인원과 다양한 직군이 만나 일하는 것을 넘어, 일을 더 잘하는 개발 문화를 주제로 이야기하려고 합니다. 개발문화란 무엇이고, FINDA 현금그로스 PG 자산/신용관리 PT의 개발문화는 어떻게 변화되었는지 사례를 중심으로 알아볼게요!

*PG는 Product Group(프로덕트 그룹)의 약자, PT는 Product Team(프로덕트 팀)의 약자로, FINDA의 조직은 하나의 PG 내에 서로 의존성 있는 PT 2~3개가 묶여 있는 구조로 이뤄져 있습니다. PT는 PO(Product Owner), PD(Product Designer), 개발자 등 다양한 직군이 소속된 목적 조직 형태입니다.

개발 문화란 무엇일까요?

개발 [명사]
새로운 물건을 만들거나 새로운 생각을 내어놓음.

 

문화 [명사]
자연 상태에서 벗어나 일정한 목적 또는 생활 이상을 실현하고자 사회 구성원에 의하여 습득, 공유, 전달되는 행동 양식이나 생활양식의 과정 및 그 과정에서 이룩하여 낸 물질적ㆍ정신적 소득을 통틀어 이르는 말.

포털 사이트에서 검색하면 위와 같이 ‘개발’과 ‘문화’에 대한 사전적인 개념을 찾아 볼 수 있는데요. 위 내용으로는 개발 문화에 대해 개념을 잡기엔 무리가 있어 보이네요. 실무에서 사용된 방법과 기술을 접목시켜 보면 아래와 같이 재해석할 수 있습니다.

간단하게, ‘개발자들이 어떻게 일하는가’로 해석 가능

 

좋은 개발 문화를 만들기 위해 다양한 방법 및 기술들 사용하기

- Agile, Scrum, Code Review, CI/CD, Git Flow, Convention, Test, Study 등등

 

위 방법들은 ‘일종의 규칙들’이며, 더 나은 것을 만들기 위해 함께 소통, 성장 및 공유하는 일련의 생태계 또는 방향성으로 정의

개발 문화에 대해 생각해 보기

FINDA에 입사한 후, 한 팀의 리드를 맡게 되었어요. 오래된 레거시와 새로 모인 팀원들 간의 화합과 협업을 가장 잘 이끌어 낼 수 있도록 많은 생각이 필요했어요. 개발 문화가 무엇인지, 팀에서 어떻게 활용할 수 있을지 여러모로 고민하며 위의 MindMap으로 정리해 보았습니다.

우선, 팀원들의 성향 파악, 공통된 규격과 프로세스 정립, 코드 리뷰, 데일리 스크럼, 회고 등을 고려해서 올바른 커뮤니케이션 방법을 모색했어요.

커뮤니케이션에 관해 예를 하나 들면 아래와 같아요!

팀원의 개발 진행상황을 물어볼 경우,

진행상황을 물어보는 것이지, 빨리 못 끝냈다고 Push 하는 것이 아니고, 문제가 있다면 도와줄 수 있는 부분이 있는지 알고 싶은 거예요.

개발 문화에 필수 요소는 무엇일까?

다양한 실무 경험을 쌓아오면서 자연스레 개발 문화에 대한 관심이 따라왔습니다. 책과 미디어를 통해 생각을 많이 정리하면서, 개발 문화에 필수적인 요소에 대해 아래의 3가지 문장으로 정리해볼 수 있었어요.

공유하고 신뢰하기

서로의 상황을 공유(이슈)

서로를 이해하며 신뢰 관계 유지

각자의 다양성을 존중하며 자율적으로 일하기

자연스러운 학습 및 Insight 발견 및 발전

공개하고 참여하기

수평적인 팀 구성원들과 동반자 관계로서 함께 만들기

모든 영역에서 팀 구성원들이 참여 및 의견을 낼 수 있는 분위기 조성(친해지기)

모든 정보를 팀 구성원에게 공개 및 방향성 공유(음지에서 양지로, 부족한 코드도 피드백으로 훌륭한 코드로 재탄생)

자극받고 성장하기(레드퀸 효과의 극대화!)

함께 성장할 수 있도록 주변에 긍정적인 영향으로 성장의 씨앗이 되는 부분을 응원 및 지지

서로 돕고 자극을 받아 팀 구성원 모두가 빠르게, 지속 가능한 성장 만들기

FINDA 커스텀 워크

FINDA는 자율 출퇴근 제도와 리모트 근무로 시간과 장소에 구애받지 않는 최상의 업무 컨디션을 발휘합니다. 워케이션 제도가 있어서 해외에서도 근무가 가능합니다. 코어타임은 11시~ 16시이고, 출퇴근 시간은 승인 없이 스스로 정할 수 있어요. 그래서 코어타임에는 더 집중해서 일하게 됩니다. 이렇게 시간을 유연하게 관리하다 보니 각자에 맞는 업무 집중시간에 일을 하며 집중도가 높아집니다. 저는 FINDA 만의 커스텀 워크 방식을 통해 업무에 더욱 몰입할 수 있고, 제대로 해낼 수 있길 바랐어요. 아래에서 FINDA 현금그로스 PG 자산/신용관리 PT의 Scrum Process에 대해 알아볼게요.

FINDA 현금그로스 PG 자산/신용관리 PT의 과거

Scrum Process를 그림으로 살펴본다면, Maker들이 모여서 Sprint 기간 동안 작업을 진행합니다. 작업을 진행하는 동안, Daily Scrum을 통해 업무 진행 상황과 이슈를 공유합니다. Sprint 기간이 종료되면 회고를 통해 잘한 점, 못한 점을 확인합니다.

과거에는 어떻게 Sprint를 진행했는지 좀 더 상세하게 살펴볼게요.

흐름

- Item 선정 및 Design Document 작성

- Tech Spec 작성(Jira Epic 생성)

-일정 논의 및 공수 산정(Jira Task 생성)

- Daily Scrum(unlimited)

- 작업 진행 및 종료(Status 변경)

장점

- Jira/Confluence 등 툴 사용성 Low

단점

- 전반적인 Sprint 진행상황 공유가 느림

- 회고가 부족해서 KPT 공유 부족

- Problem 되풀이 가능성 High

과거의 흐름에서 살펴보면, ‘Daily Scrum(unlimited)’와‘Jira/Confluence 등 툴 사용성 Low’가 문제였어요.

Daily Scrum에서 시간을 정했지만, 항상 정해진 시간을 초과하다 보니 업무에 집중할 시간이 부족했어요. Jira/Confluenec 등 툴이 있었지만, 적극적으로 활용되지 않아서 Sprint 진행상황이 한눈에 보이지 않고, 담당자에게 물어봐야 알 수 있었죠. 회고도 PT 내에서만 진행하고 Tech 쪽 회고는 없어서 KPT의 Problem이 되풀이될 가능성이 매우 높았어요.

그렇게 반복되는 Sprint 일정 속에서 동료들은 지쳐가고, Backlog를 제대로 챙겨서 다음 Sprint에 반영할 수 없었어요.

FINDA 현금그로스 PG 자산/신용관리 PT의 현재

자, 이번엔 현재 FINDA 현금그로스 PG 개발문화가 어떻게 변화되었는지 알아볼 시간이에요!

흐름

- Item 선정 및 Design Document 작성

- Tech Spec 작성(Jira Epic)

-일정 논의 및 공수 산정(Jira Task, Story Point, Start Date, End Date, Work Log)

- Daily Scrum(15 min)

- 작업 진행(WorkLog 추가, Status 변경)

- Code Review

-작업 종료(Status 변경)

- 회고, Backlog 기록(PT 별, 개발 그룹별)

장점

- 전반적인 스프린트 진행상황 공유가 빠름

- 회고를 통해 KPT 공유

- Code Review를 통해 품질 향상

- Problem 되풀이 가능성 Low

단점

- Jira/Confluence 등 툴 사용성 High(처음은 귀찮아질 수도 있어요!)

FINDA에서는 아래의 문서 템플릿을 업무에 공통적으로 적용하고 있어요.

과거 Daily Scrum 전에 아이스 브레이킹 시간이 있었습니다. 하지만, 현재는 몰입도를 최고로 생각하고자 아이스 브레이킹 시간을 없애고, 매일 Scrum Master(Round Robin 방식)가 이슈로만 진행합니다. 또한, 과거에는 각자 진행한 업무도 이야기했지만, 현재는 과감하게 서면으로 대체하기를 선택해서 15분이라는 Ground Rule을 지키고 있어요! 이 부분은 사실 팀원들 간의 친밀도가 높을수록 좋고, 어색하지 않게 진행할 수 있습니다.

그리고 Jira/Confluence를 적극 활용합니다. Story Point(1 point 4 hours), Start/End Date, Work Log를 각 Jira Ticket에서 꼭 사용하면서 모든 Maker 가 진행상황과 업무일정을 투명하게 볼 수 있도록 했어요. 사실 과거에는 개발자 이외의 직군은 업무에 대해서 Jira Ticket을 잘 사용하지 않았지만, 현재는 많이 사용하고 계십니다.

또한, Code Review도 반드시 하고 승인자가 있어야만 배포할 수 있는 Rule을 적용했어요. 이전에는 Code Review가 없어서 테스트 코드가 거의 0% 였지만, 현재 많이 끌어올리고 있고, 목표치 70% 까지 열심히 작업해 볼게요!

리뷰, 회고 및 Backlog는 PT 그룹과 백엔드 그룹별 각각 진행하면서 Product/Sprint Backlog를 챙기면서 다음 Sprint를 준비했어요.

마지막으로 레드퀸 효과를 적극적으로 활용했습니다. 레드퀸 효과는 서로 자극을 주면서 건강하게 성장하도록 유도하는 방식으로, <거울나라의 앨리스>를 보신 분들이라면 익히 알고 계실 거라 생각됩니다. 서로 기술적 탐색을 통해 설계 진행과 논의에 직접 참여하고, 스터디와 기술적 공유를 통해 적극적으로 반영할 수 있는 환경과 분위기를 만들었어요.

결과적으로 Sprint 진행상황 공유가 빠르고 Code Review로 코드 품질이 향상되었습니다. KPT에서 Problem의 되풀이 가능성도 최소화시킬 수 있었습니다.

개발 프로세스 변화 후 결과는 어떨까요?

지금까지의 이야기를 정리해 볼게요.

Confluence(Wiki) : 부족한 점을 다음 스프린트에서 보완 가능

- 회고, Back Log 기록

Jira : 작업 상태 공유로 현재 스프린트 파악 및 업무 Scope 측정 용이

- Story Point(1 point 4 hours), Start/End Date, Work Log

Daily Scrum : 짧고, 집중도 있는 의사소통

- Unlimited(과거) → 15 min(현재)

- Ice Breaking(과거) → X(현재)

Code Review : Code 품질 개선

- Code Review X(과거) → Code Review O, 승인자 1명 이상 Merge 제한(현재)

각자 서로 다른 경험을 가진 팀원들 간의 화합과 협업을 위해서 FINDA 현금그로스 PG 자산/신용관리 PT 만의 Scrum Process를 적용했습니다.

그 결과, 초기 팀원들의 역량(슬램덩크 초기 모습) 보다 한층 성장한 모습(서태웅과 강백호의 하이파이브 모습)으로 발전되어 팀과 PG 내에서 좋은 결실을 맺었다고 생각합니다.

<원문>

우리의 개발문화는 이렇게 성장합니다

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.

[콘텐츠문의]ㅤ[email protected]