우리의 개발문화는 이렇게 성장합니다
안녕하세요, FINDA 현금그로스 PG 자산/신용관리 PT 백엔드 개발자 김형래 입니다.
이번 글에서는 제가 팀빌딩을 하면서 고민했던 내용과 FINDA 현금그로스 PG 개발문화의 과거와 현재에 대해서 이야기 해 보려고 합니다. FINDA 내에는 다양한 PT 가 있고, 여러 PT 가 하나의 PG 로 모여 일합니다. 다수의 인원과 다양한 직군이 만나 일 하는 방식에서 더 일 잘하는 개발문화에 대한 주제가 필요해 보여서 해당 주제로 이야기하려고 합니다. 사례 중심으로 개발문화란 무엇이고, FINDA 현금그로스 PG 자산/신용관리 PT 의 개발문화는 어떻게 변화가 되었는지 알아 볼게요!
개발 문화란 무엇 일까요?
개발 [명사]
새로운 물건을 만들거나 새로운 생각을 내어놓음.문화 [명사]
자연 상태에서 벗어나 일정한 목적 또는 생활 이상을 실현하고자 사회 구성원에 의하여 습득, 공유, 전달되는 행동 양식이나 생활 양식의 과정 및 그 과정에서 이룩하여 낸 물질적ㆍ정신적 소득을 통틀어 이르는 말.
위와 같이 포털사이트에서 검색하면 사전에서 볼 수 있는데요. 위에 내용으로는 개발 문화에 대한 개념을 잡기엔 무리가 있어 보이네요. 실무에서 사용된 방법과 기술을 접목시켜 보면 아래와 같이 재해석 할 수 있습니다.
간단하게, ‘개발자들이 어떻게 일 하는가’ 로 해석 가능
좋은 개발 문화를 만들기 위해 다양한 방법 및 기술들 사용하기
- 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(15min)
- 작업 진행(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(과거) → 15min(현재)
- Ice Breaking(과거) → X(현재)
Code Review : Code 품질 개선
- Code Review X(과거) → Code Review O, 승인자 1명 이상 Merge 제한(현재)
각자 서로 다른 경험을 가진 팀원들 간의 화합과 협업을 위해서 FINDA 현금그로스 PG 자산/신용관리 PT 만의 Scrum Process 를 적용했습니다.
그 결과, 초기 팀원들의 역량(슬램덩크 초기 모습) 보다 한층 성장한 모습(서태웅과 강백호의 하이파이브 모습)으로 발전되어 팀과 PG 내에서 좋은 결실을 맺었다고 생각합니다.
