[Tech Note] 혁신 조직의 첫 발걸음, "애자일(Agile)" - 2편
2022.11.25
Editor's Note
2021년 재직중인 회사 내에서 운영 중이었던 신기술연구모임(R&D)에서 도출된 과제들을 보고하던 중 한 아이템을 실제 추진했습니다. 파괴적 서비스를 시장에 던진 기업들을 벤치마킹을 하며 당시 연구모임의 리더 및 사내 소프트웨어공학 전문가인 팀장과 함께 ‘일 하는 방식’의 변화를 도모하게 되었습니다. 변화의 과정은 제게 깊은 영감을 주었고, 이는 혁신을 추구하는 그 어떤 조직에서도 유용한 정보가 될 것이라고 판단했습니다. 그 첫번째 콘텐츠로 지난 1년간 제가 몸담고 있는 BC카드 pay-Z TF가 어떠한 애자일 방법론을 적용했는 지 관련 개념들을 소개하며 실제 효과들에 대해 적어볼까 합니다.이 글을 통해 금융권에서 기술 및 SW 역량을 내재화하거나, 신사업을 추진하는 데 있어 애자일 조직 문화를 고민하는 데 조금이나마 도움이 되길 바래봅니다.
목차
- 애자일 방법론의 기본 개념
- 스크럼과 몰입
- 애자일의 성과, 그리고 최고의 복지는 "뛰어난 동료"
| 애자일 SCRUM
애자일은 곧 스크럼(Scrum)이라고 불릴 정도로 스크럼은 애자일 방법론을 수행하는 프레임워크입니다. 스크럼은 애자일 조직에서 에픽과 스토리의 복잡하게 도출되는 문제들을 즉시 적응하여 해결하는데 목적이 있습니다.
1) 스크럼(Scrum)
스크럼의 사전적 의미는 "럭비 경기 중 반칙이 있을 때 반칙이 행해진 장소로부터 되도록 가까운 곳에서 하나의 집단을 형성하여 상태 팀을 앞으로 밀치는 대형"을 뜻합니다. 이를 소프트웨어 개발 프로세스에 적용하면서 스크럼이란 목표를 위해 ‘팀’이라는 의미를 적용하여 효율적인 성과를 얻기 위한 방법을 일컫는 용어로 쓰이게 됩니다. 기술경영(MoT)에서 시작된 단어지만 소프트웨어 개발 프로세스에 국한되지 않고 이제는 조직의 개선과 프로젝트 관리를 위해 사용되고 있으며, 협업이 필요한 소규모 기능 개선 팀을 위해서 보편적으로 사용되는 방식이 되었습니다.
<자료 3. Scrum Framework(출처 : Kshitij Yelkar)>2) 프로덕트 백로그(Product Backlog)
프로덕트(제품)를 구성하는 핵심 기능을 목록화 시킨 것을 프로덕트 백로그라고 합니다. 이 백로그를 구성하는 아이템은 PBI (Product Backlog Item)이며, 고객에게 제공되는 서비스의 핵심 기능 단위입니다. PBI는 에픽과 스토리 하위의 개념입니다. PO(Product Owner)는 BO(Business Owner)와 협의를 통해 업무의 시급성, 난이도, 구현 가능성 등을 고려하여 PBI의 우선순위를 관리합니다.
PBI의 예를 들면, pay-Z 서비스의 초기 에픽의 스토리들 중 ‘SNS 소셜 로그인 기반의 계정 관리 및 본인 인증’과 ‘쇼핑몰에 준하는 판매자 기본 서비스 필요’가 있습니다. 스토리를 구성하는 핵심 기능들인 PBI를 나열하면 다음과 같습니다.
<표 1. 스토리별 PBI 예시>
| 스토리 | PBI |
|---|---|
| SNS 소셜 로그인 기반 계정 관리 및 본인인증 | 소셜 로그인 OAuth2 인증 |
| 로그인 된 인증 정보에 기반한 계정 관리 | |
| 구매를 위한 본인인증 (CI 취득) | |
| 본인인증 계정은 그룹별로 관리 | |
| 쇼핑몰에 준하는 판매자 기본 서비스 필요 | 판매를 위한 상품 등록/수정/재고 관리 |
| 배송 상태에 따른 배송 관리 | |
| 입금 내역/정산 관리 |
3) 스프린트 백로그(Sprint Backlog)
스프린트 백로그는 PBI를 달성하기 위한 하위 세부 업무들의 집합입니다. 스크럼에서 실무적으로 가장 활성화되는 영역입니다. 스프린트는 사전적 정의로 짧은 거리를 전속력으로 질주하는 것을 의미합니다. PBI를 달성하기 위해 실무자들 사이에서 세부적인 기술 요소와 프로세스 정립이 이뤄져야 합니다. 스프린트 백로그를 구성하는 SBI(Sprint Backlog Item)는 업무(Task) 단위가 됩니다. SBI는 계획 단계부터 스프린트 도중에도, 완료 이후 리뷰를 거쳐서 새롭게 생성 되기도, 업무 도중에 제외 되기도 합니다.
<자료 4. PBI Priority(출처: quickscrum)>스프린트 백로그의 주체는 실무자들(기획, 개발, 디자인)입니다. 실무진들에 의해서 결정되므로 협업과 공유는 필수입니다.
<자료 5. SBI Structure(출처: The scrum guide, Ken Schwaber and Jeff Sutherland)>SBI(Sprint Backlog Item)는 1주, 혹은 길면 4주에 거쳐서 진행되지만, 긴급하거나 업무량이 적을 경우 데일리 스크럼(Daily Scrum) 과정을 통해 생성되어 단 하루 만에 추진되어 완료 되기도 합니다.
만약 ‘소셜 로그인 OAuth2 인증’이라는 PBI를 구성하는데 SBI는 다음과 같이 정해볼 수 있습니다. SBI는 실무 관점에서 태스크이기 때문에 언제까지, 누가 참여하는지 등록되어야 합니다. 특이사항이 있을 경우 내부 공유를 통해 일정을 조정할 수는 있습니다.
<표 2. PBI별 SBI 정의 예시>
| PBI | 구분 | 아이템 | 담당자 | 완료일 |
|---|---|---|---|---|
| 소셜 로그인 OAuth2 인증 | SBI | Spring Security OAuth2 인증 필터 구현 | 씬 | 20210701 |
| SBI | Google, Kakao, Naver OpenAPI 등록 | 흑기사 | 20210615 | |
| SBI | 토큰 기반 Authentication Filter 구현 | 씬 | 20210701 | |
| SBI | 계정/권한 도메인 엔티티 객체 Factory 구현 | 씬 | 20210705 |
| 데일리 스크럼(Daily Scrum)
데일리 스크럼은 개인과 팀 차원에서 생산성을 높이는 업무 공유 방법론입니다. 매일 팀 구성원들에게 스프린트 목표를 달성하기 위해 책임을 공유하고 스스로를 관리하는데 필요한 정보를 주는 과정을 갖습니다. 데일리 스크럼에서 PBI, SBI에 대해 빠르게 현황을 공유하여 확인할 수 있습니다. 데일리 스크럼이 필요한 또 다른 이유는 모든 구성원과 시간을 효율적으로 사용하게 할 뿐만 아니라, 조직의 최우선 목표에 대해 구성원들이 일치(Alignment) 시킬 수 있다는 장점이 있습니다. 데일리 스크럼의 필요성은 크게 3가지로 정할 수 있습니다.
- 개인의 생산성과 팀의 생산성 향상
- 스케줄을 공유함으로써 협업을 원활하게 진행하도록 함
- 업무가 공유되기 때문에 불필요한 업무 진행 사전 방지
데일리 스크럼은 10분~15분내로 진행합니다. 조직 내에서 다양한 형태로 운영이 되지만 필수적으로 공유되는 정보는 다음과 같습니다.
- 나는 오늘 무엇을 할 것인가?
- 다른 팀원과 협업이 필요한 일이 있는가?
- 내 업무를 가로막는 것은 무엇인가?
데일리 스크럼은 관리자가 주관하지 않습니다. 실무자들이 각자 하루를 어떻게 계획하는지 공유하는 자리입니다. 데일리 체크인이라는 업무에 적힌 내용만 봐도 되겠지만 협업이 필요한 경우 협업 대상자에게 업무를 상기시킬 수도 있습니다. 협업이 필수로 이뤄지는 애자일 조직에서는 각 구성원들의 생각하는 조직의 최우선 목표가 다르면 기민한 업무를 추진하며 성장하는 것은 불가능에 가깝기 때문입니다.
pay-Z TF는 데일리 체크인이라는 이름으로 그라운드 룰을 정하여 팀원들이 돌아가며 데일리 스크럼을 주관하고 발표합니다. 발표라는 용어가 거창하게 들릴 수도 있지만 짧으면 한 사람당 10초 이내로 끝나기도 합니다. pay-Z TF에서는 필수적으로 업무에 대한 3가지 사항 외 개인적인 것들도 공유합니다. 저희 팀이 데일리 스크럼에서 공유하는 항목은 다음과 같습니다.
- 오늘의 업무
- 컨디션
- 협업 필요 업무
- 논의가 필요한 부분
- 오늘의 키워드
- 점심 뭐 먹지?
- 오늘의 TMI (Too Much Information)
<자료 6. Daily Scrum(출처 : The LeSS Company B.V. “Scrum Planning”)>코로나19 사태가 심각해진 상황에서 재택근무로 인해 직원들이 비대면 데일리 스크럼에 참가하는 경우 다른 팀원들의 현상을 이해하기 위해 개인적인 정보도 작성하도록 했습니다. 덕분에 팀원들의 상황이 공유되고 구성원들의 상황과 어려움이 무엇인지 서로 이해할 수 있게 되었습니다. 덕분에 지난 1년간 휴가를 제외하고는 단 하루도 빠짐없이 모든 직원들을 프로덕트에 참여시킬 수 있었습니다.
<자료 7. 실제 데일리 스크럼 활용 예시> | 스크럼과 칸반 혼용
pay-Z TF팀은 애자일에 대한 시행착오를 겪으며 정착시킨 방법은 스크럼과 칸반 방법의 혼용입니다. 스크럼에서 도출된 PBI, SBI 등 스크럼 아이템을 칸반보드에 우선순위를 분류하고, 비즈니스 파트와 개발 파트 간 이슈/공유 사항들을 관리하고 있습니다. 소프트웨어공학에서는 스크럼은 스프린트를 통해 이용할 수 있는 작업 시간을 통제하여 생산성을 제어하지만, 칸반은 동시에 처리할 수 있는 이슈의 수를 명확히 함으로써 생산성과 기간을 제어할 수 있는 장점이 있습니다. 스프린트는 SW개발 조직에는 어울리지만 pay-Z TF팀과 같은 비즈데브옵스(BizDevOps) 조직에서는 스프린트로만 업무 진행에 한계가 있다는 점을 알게 되었고 칸반을 혼용하여 Biz 파트와 Dev 파트 간 우선순위와 일정을 통제하고 담당자는 이슈를 처리하는데 집중하도록 하였습니다.
<자료 8. 데일리 스크럼 Rule 예시>pay-Z TF팀에서는 협업 툴에 등록된 스크럼 아이템을 선택하면 각 아이템별로 진입하게 되면서, 이슈들을 댓글로 형태로 커뮤니케이션을 합니다. 이는 모든 직원들에게 공개되어 누구나 의견을 제시할 수 있습니다.
<자료 9. 실제 스크럼 칸반 활용 예시>[3편에서 계속]
상기 콘텐츠의 모든 저작권은 BC카드 신금융연구소 (이하 'BCiF')에 있으며, 무단 도용을 금합니다.
본 자료를 인용 및 발췌하고자 할 경우 출처를 명확하게 표기해야 합니다.
본 자료를 인용 및 발췌하고자 할 경우 출처를 명확하게 표기해야 합니다.
이태영
BC카드 pay-Z TF에서 풀스택 개발자이자 Tech 리더로서, 차세대 프로젝트 아키텍트 및 IT신기술 기획, 검토 등 다양한 개발 경험을 바탕으로 사내특허심사위원으로도 활동하고 있습니다. 개발자의 길을 걸어오며 삶의 다양한 문제를 기술적으로 분석해보는 즐거움 덕에 사내외에서 인공지능 및 데이터분석 관련 강의도 펼치고 있습니다.
