안녕하세요, 우아한형제들 상품시스템팀의 손권남입니다.

가끔씩 저는 우리팀의 팀 문화에 대한 질문을 받곤 합니다. 그때마다 매번 단편적인 답을 드리곤 하면서 한 번 정도 우리의 팀문화를 정리했으면 좋겠다고 생각했습니다.

하지만 우리팀이 행하는 팀 문화 자체보다는 그 문화가 형성되어 가는 과정이 더 중요하지 않을까 하는 생각이 들어 그 둘을 함께 정리해보았습니다.

언제나 그렇듯, 이 글은 개인적인 경험과 의견을 담은 것이므로 회사의 의견과 다를 수 있습니다.

팀 문화 탄생의 뼈대

우리팀은 기본적으로 2주 단위 스프린트를 진행합니다. 스프린트의 시작 첫날(보통 월요일)에 플래닝을 하고, 마지막날(보통 금요일)에 회고를 합니다.

플래닝된 결과로 도출된 업무는 포스트잇으로 만들어 벽의 보드에 나뉘어 그려둔 Plan, In Progress(Doing), In Review, Done(완료,배포됨) 칸을 따라 이동하며 현재 플래닝대로 어느정도 진척되고 있는지를 벽만 봐도 알수 있게 하였습니다. 그리고, 매일 아침 데일리 스탠드업 미팅을 통해서 “어제 한일, 오늘 할 일, 문제 될만한 것들”을 매우 짧게 서로 공유하고 업무를 시작합니다.

그리고 스프린트 마지막날 회고를 하며 이런 그간 있었던 일이나, 각자의 감정 등을 나누는 등의 활동과 함께 Keep / Problem -> Try 활동을 진행합니다. 바로 이 KPT 를 통해 팀의 문화가 탄생하고 변화하고 폐기되기도 합니다.

이 글은 저희팀의 Keep/Problem/Try 에 관한 이야기입니다.

Keep, Problem, Try란 무엇인가?

KPT 는 회고 과정중에 진행하는 한 부분입니다. Keep/Problem/Try 는 다음을 의미합니다.

Keep : 잘하고 있는 점. 계속 했으면 좋겠다 싶은 점.
Problem : 뭔가 문제가 있다 싶은 점. 변화가 필요한 점.
Try : 잘하고 있는 것을 더 잘하기 위해서, 문제가 있는 점을 해결하기 위해서 우리가 시도해 볼 것들

Keep/Problem/Try 보드

Keep/Problem/Try 보드 http://code-artisan.io/retrospective-method-kpt/

위와 같은 보드를 만들고,

먼저 Keep 과 Problem 을 각자 포스트잇 한 장에 한 항목씩만 적어서 붙입니다. Keep 은 파란색 계통, Problem 은 빨간색 계통으로 적어 넣으면 보드가 명확히 구분이 안 되더라도 알아보기 쉽습니다.
이제 각자 Keep은 우리가 뭘 잘하고 있고 그것을 지속했으면 하는지 Problem 은 우리에게 어떤 문제가 있고 개선됐으면 하는지를 얘기를 나눕니다.
이제 마지막으로 Keep 중에서도 더 개선할 점이 있거나, 새로운 시도를 해보고 싶은게 있다면 그런 점을, 그리고 Problem 을 해결하기 위해 우리가 시도 해볼만한 점을 각자 포스트잇 한장에 한 항목씩만 적어서 Try 보드에 붙입니다.
이제 Try 쪽지들을 보면서 서로 토론을 하며 더 다듬고, 투표를 통해 다음 스프린트에서 해볼 Try 아이템을 선택해서 Action Item 으로 명명합니다. Action Item 을 선택할 때는 보통 투표를 해서 2~3개 정도만 골라냈는데, 너무 많이 나와버리면 오히려 집중력이 떨어지기 때문에 갯수를 줄이는 편입니다. 투표는 작은 하트 스티커등을 각자 3개정도씩 가지고 원하는 아이템에 투표해서 가장 많은 표를 받은 것을 선택합니다.
이제 선정된 Action Item 에 대해서 실제로 그것을 수행하거나, 혹은 잘 수행되는지를 확인하고 가이드할 사람을 한명 지정하고, 팀 스프린트 보드에 잘 보이게 써 둡니다.

그리고 실제로 이를 행합니다.

이제 KPT 를 통해 만들어진 우리 팀의 Action Item들 몇가지만 살펴보도록 하겠습니다.

똑같은 질문을 100번하면 100번이라도 대답해주겠어요

Keep : 마음 편히 질문할 수 있는 분위기가 좋다.

우리 팀에서 경계하는 것 중에 하나가 “반복된 같은 질문에 신경질 적인 반응을 보이는 것”입니다. 질문하길 꺼리는 분위기가 생기면 그로 인해 중요한 문제를 ‘괜히 질문해서 한소리 듣지 말자, 설마 이게 맞겠지, 그냥 내보내자’ 식으로 확인없이 그냥 배포했다가 바로 장애로 이어지는 등의 일이 발생합니다.

또한 현실 비즈니스 도메인의 현재와 지속적인 변화는 한 사람이 완벽하게 파악하는게 불가능합니다. 서로간의 상호 보완이 없으면 어딘가는 구멍이 나게 마련입니다.

아무리 그래도 동일한 질문이 계속된다는 것은 뭔가 업무 프로세스상 문서화가 덜 됐거나, 의사소통의 명확성이 떨어지거나 하는 문제가 있다고 볼 수도 있습니다. 또 어쩌면 해당 비즈니스 프로세스 자체가 문서화를 하건 말건 말도 안되는 수준으로 복잡한 것일 수도 있습니다(실제 비즈니스를 해보면 이런 경우가 매우 많습니다).

질문하는 것을 막아서는 안되겠지만 질문이 왜 반복되는지, 그럴 필요가 없게 만들 수는 없는지 고민이 필요해 보입니다.

문제의 포인트를 “질문하는 사람”에서 “질문 받는 사람”으로 돌립니다. 질문하는 사람에게 “왜 자꾸 질문해요?”라고 나무라는게 아니라, “왜 자꾸 같은 질문이 나올까? 내가 질문을 덜 받으려면 어떻게 해야할까?”라고 생각해 보는 것이지요.

프로그래밍에서 반복되는 질문의 형태는 보통 두 가지인 것 같습니다.

“무엇인가요?”
“왜 그런가요?”

> 반복되는 “무엇”에 대한 질문 : 공급가인가? 세금 포함가인가?

Problem : 지속적으로 가격 변수의 값이 “공급가(세전 가격)”인지 “세금포함가격”인지 질문한다.

“무엇”에 대해서 많이 나온 질문중의 하나는 “도대체 저 price 변수는 공급가(세전 가격)이냐 세금 포함가이냐?” 라는 질문이 있었습니다. 돈을 다루는 팀이 자주 부딪히는 문제중의 하나가 바로 세금 포함여부입니다. 이는 매우 중요한 것으로 이것을 헷갈리는 순간 모든 계산이 다 틀어지게 됩니다.

Try : 모든 가격관련 변수는 xxSupplyPrice 이면 공급가로서 세금 불포함한 가격이고, xxPrice 이면 세금 등 모든 비용을 포함한 가격이다.

이제는 이게 무슨 가격인지에 대한 질문이 줄어들었습니다.

“무엇”에 대한 질문은 코드의 변수와 메소드의 Naming 을 명확히하고, 코드를 간결하게 짬으로써 어느 정도 해결이 됩니다.

> “왜?” 라는 질문을 줄이려면?

Problem : “왜 이렇게 짠거죠?” 라는 질문이 반복 됩니다. 그리고… “나도 왜 그렇게 짰는지 기억이 안나요… ㅜㅜ”
Try
- Wiki 등에 프로젝트 문서 잘 정리하기. (사실 이건 좀 위험한 try 입니다. “잘해보자”는 보통 잘 안되는 경우가 많습니다. 그래도 어쨌든 잘 정리해 봅시다.)
- 코드 리뷰 혹은 일상적인 상황에서 질문이 나온다면, 그것은 코드가 명확하지 않다는 뜻이다. 코드를 개선하여 가독성을 높이거나, 그렇게 코드를 짤 수 밖에 없는 이유를 리뷰 즉시 주석으로 남기거나 관련 테스트 코드를 작성해두자.

보통 코드에 주석 다는 것을 죄악으로 보는 경우가 있는데, 이는 코드가 “무엇을 하는지”에 관한 주석일 경우에는 그렇습니다. “무엇”은 위에서 처럼 변수나 메소드 네이밍으로 충분히 주석없이 처리가 가능한 경우가 많습니다.

하지만 “왜 하는지”는 다른 문제입니다. 도대체 고객에게 줄 돈에서 500원을 더하는데 상수의 이름을 봐도 그래서 왜 더하는지 모르겠습니다.

현실 비즈니스의 세계는 결코 논리적이지 않습니다. 온갖 황당한 이유로 코드가 꼬이기 마련이며, 거기에 명확한 이유를 적어두지 않으면 나중에 다른 개발자가 보고서 ‘이건 왜이러지? 버그아냐?’ 하고 다른 사람들에게 왜 그랬는지 물어보게 되고, 그걸 개발한 개발자조차도 왜 그랬는지는 이미 까먹었고, 버그였나보다 하고 코드를 삭제했더니 갑자기 고객 센터 전화기에 불이나기 시작합니다. 사실은 다 이유가 있었습니다.

주석으로 항상 왜를 적어둡니다. 코드와 최대한 가까운 거리에 이유를 적어두는 것이 좋습니다. 최소한 관련 사항이 명시된 문서 링크라도 달아두어야 합니다(@see javadoc tag 사용).

주석보다 더 나은 방법은 500원을 더하는 테스트 코드를 명확히 작성해두고, 테스트코드 메소드명 혹은 설명(description)에 이유를 적어두는 것입니다.

Try : 신규 입사자 등은 처음보는 외부인의 시선으로 문서를 읽으면서 따라해 봤더니 잘 안되는 점, 빠진 부분등을 찾아내기 좋은 상황이다. 신규 입사자에게 문서를 보면서 질문을 받고, 질문 받은 사항은 문서의 부족한 부분이니 채워 넣거나 수정하도록 하자.

신규 입사자 뿐만 아니라 페어가 바뀌는 상황 등도 유사한 효과가 생기게 됩니다. 그럴 때 질문이 나오면 그걸 기회로 삼아 문서를 발전시키는 계기로 삼습니다.

그 외에 질문이 많이 나오는 원인중에서 근본적으로 비즈니스 프로세스 자체가 말도 안되게 복잡한 경우도 있습니다. 몇 년에 걸쳐 누적된 땜질식 정책 변화는 도저히 한 사람의 머리로는 아무리 봐도 이해가 안되는 복잡도를 띄게 되기도 합니다(그런 예가 아마도 세금 관련 법이 아닐까 싶습니다). 이러한 복잡한 비즈니스 프로세스 자체를 간결하게 바꿀 수 있는 방법은 없을까? 라는 고민과 실천을 하기도 합니다(2019년 봄에 이런 것을 정리하는 프로젝트가 있기도 했습니다).

재택근무가 시작되었다. 누가 무엇을 하는지 잘 모르겠다. - 채팅을 통한 소통의 규칙

Problem : 전세계를 강타한 코로나19로 인해 재택 근무가 시작되었다. 바로 옆에서 의사 소통하던 상황에서 대부분 채팅과 특정인들만의 화상회의로만 의사소통이 진행되다보니 어디서 무슨일이 일어나는지 파악이 힘들다.

재택 근무가 시작되었고, Slack이나 기타 메신저로 의사 소통을 해야하는 상황이 되었습니다.

보통 바로 옆에서 팀원들이 대화를 나누거나 하다보면 옆에서 듣다가 실제로 그 문제를 가장 잘 아는 사람이 빠르게 대화에 참여해서 문제를 해결해주는 일이 생기거나, 그렇지 않더라도 최소한 무슨일이 진행되는지라도 자연스럽게 공유되는 상황이 되곤 합니다.

하지만 이제 의사소통 채널이 채팅이 되면 그런게 불가능해집니다.

Try : 업무상 대화는 항상 팀 채널방에서 공개적으로 쓰레드를 만들어서 한다.

업무상 대화를 Slack 의 팀 혹은 공개 채널에서 공개적으로 하도록 하게 되면 몇가지 효과가 있습니다.

남이 뭘하는지를 알 수 있고, 바로 옆에서 대화하는 것이 자연스럽게 들리듯, 팀 채팅방을 훑어보면서 상황 파악을 할 수 있게 됩니다. 또한 대화 참여자들은 재택 근무시에 “나 여기서 이렇게 열심히 일하고 있어요~”하고 티내는 효과도 자연스럽게 됩니다.

개인간 대화의 또다른 심각한 문제는 “열심히 대화를 나눴는데… 그 사람은 해당 사항을 전혀 모르는 사람이었고 사실은 다른 사람한테 질문해야했어”라는 상황입니다. 혹은 상대방이 휴가자인 경우도 매우 많지요. 개인 대화창을 사용할 경우에는 이제 다시 모든 대화를 처음부터 시작해야 합니다. 공개 대화를 하면 원래 담당자가 보고 있다가 대화에 먼저 끼어들 수도 있고, 아니면 간단한 멘션만으로도 기존 대화 내용을 공유해서 계속 이어나갈 수 있게 됩니다.

Slack 의 쓰레드 기능은 과도하게 남들에게 노이즈를 발생시키지 않아도 되게 해줍니다.

Problem : 쓰레드의 첫 대화에 대화 참여자들에 대한 멘션만 하고 실제 내용은 쓰레드 안에서 적었더니, 밖에서 쓰레드를 클릭하기 전까지는 대화 내용을 파악할 수 없어서 모르고 지나가게 된다. 멘션을 당한 사람은 열심히 일하다가 주의를 빼았겼는데 정작 왜 빼았겼는지 이유를 알 수 없고 다음 말이 나올 때까지 마냥 기다려야 하게 된다.
Try : 대화 쓰레드의 첫 문장에서 항상 대화의 목적을 분명하게 밝히도록 한다.

그래야 주의력을 빼앗긴 사람은 그에 대해 빠르게 보상이 되고, 밖에서 보는 사람들도 별다른 수고 없이 상황 파악을 하고 대화에 끼어들지 혹은 관전할지 아니면 그냥 하던일 계속 할지 여부를 판단할 수 있게 됩니다.

Test 코드를 작성하고 Code Coverage 높이기

Keep : Unit Test를 잘하고 있는데, 계속 더 잘하면 좋겠다.

요즘 대부분의 개발자들은 Unit Test를 짭니다. 특히 자신이 만든 코드를 자신이 스스로 끊임없이 변화시켜야 하는 우리같은 서비스 개발 회사의 개발자들은 Unit Test 가 코드가 변화할 때 기존에 잘 작동하던 코드가 깨지지 않게 하는데 꼭 필요한 요소임을 이해하고 있습니다.

그래서 항상 Test 코드를 작성하려고 노력합니다. 그런데 이걸 더 잘할 수 있는 방법이 없을까요?

Try : Jenkins 에서 빌드를 할 때 가장 최근 Code Coverage 를 기록하고, 그것보다 커버리지가 떨어지면 빌드를 실패하게 하자.

이제, 코드 커버리지가 떨어지는 것을 방지하기 위해서 Jenkins 에서 지속적으로 개발 Git Branch 를 빌드하면서 코드 커버리지가 떨어지면 빌드 실패 알람을 보내도록 하였습니다. 이런 상황이 되면 개발자들은 열심히 노력해서 코드 커버리지를 높여서 회복시켜야 합니다. 그리고, 기존 보다 더 높아지면 기준치를 다시 높여서 더 떨어지지 않게 합니다.

위 작업은 Jenkins Jacoco Plugin 과 Gradle Jacoco 조합으로 진행하고 있습니다.

추가 참조 - Gradle 프로젝트에 JaCoCo 설정하기

코드 커버리지 저하

이런 코드 커버리지 저하로 빌드가 실패했습니다. 원래 Branch Coverage 82%, Line Coverage 76% 였는데 각각 1%씩 하락했습니다. 빌드가 실패했고 새로 짠 로직이나 혹은 중요한 로직 위주로 코드 커버리지를 더 올려야 하겠습니다. (저희팀은 Branch/Line Coverage 위주로 관리합니다)

처음부터 완벽할 수는 없다. 그러나 어제보다는 낫게 만들자. 라는 원칙에 따라 코드 커버리지를 관리합니다.

테스트 코드를 작성하게 하면서 주의할 점이 있는데, 코드 커버리지에 지나치게 집착하면 assert 문 없이 대충 코드를 순서대로만 실행하는 테스트 코드를 작성하는 경우가 발생하게 됩니다.

올바르게 결과를 검증(assert)하지 않는 테스트 코드는 테스트 코드가 아닌 것으로 봅니다.

정적 분석을 하자

정적 분석은 KPT를 통해서 시작하기로 결정했다기 보다는 원래 회사가 하고 있던 일이라 자연스럽게 우리팀도 하고 있는 일입니다. SonarQube를 통해서 팀의 소스 코드를 정적 분석하여, 테스트 코드를 못짰거나, 테스트 코드가 있더라도 SonarQube 가 안좋은 습관으로 간주하는 항목들 혹은 중복 코드등을 분석하여 수정합니다.

SonarQube QualityGates CI 연동

Keep : SonarQube 코드 정적 분석 툴을 이용하여 코드 품질을 관리하는 덕분에 몇 번 버그를 미리 탐지할 수 있었다. 계속 잘 사용하면 좋겠다.
Problem : SonarQube가 프로젝트 Build 시스템(Jenkins)와 별도로 존재하다 보니 정적 분석에 위반 사항이 있어도 잘 모르고 넘어가게 된다. 그래서 명백하고 쉬운 버그가 배포되었었다.

이런 경우 우리가 쉽게 내는 결론은 “배포전에 SonarQube를 꼭 확인해보자” 같은 식이 되기 쉬운데, 우리는 그것도 지키기 쉬운 일은 아니라고 결론을 내었습니다.

이게 정말 잘 지켜지려면 결국 Build 서버와 연동이 되어야만 했습니다.

SonarQube 에는 Quality Gates(품질 관문?) 라는 기능이 있습니다. 이 기능은, 프로젝트 별로 버그 등 정적 분석 위반이 얼마간 발생할 경우 SonarQube 안에서 해당 프로젝트를 Unstable 혹은 Fail 등으로 경고를 내보낼 수 있게 해줍니다.

그리고 Quality Gates 는 SonarScanner for Jenkins Plugin를 사용하면 Jenkins Pipeline 의 waitForQualityGate() 를 이용하여 Jenkins-SonarQube 간 상호 연동을 할 수 있습니다.

이제 Jenkins 에서 프로젝트를 빌드하면 SonarQube Quality Gates 를 호출하고 결과를 받아서 Quality Gates가 프로젝트 품질를 Fail 로 표시할 경우 해당 빌드 자체를 Failure 로 처리할 수 있게 되었습니다. Jenkins 만 봐도 정적 코드 분석 결과의 성공/실패 여부를 항상 확인할 수 있게 된 것이지요. 배포할 때 좀 더 안전하게 배포할 수 있게 되었습니다.

SonarQube Quality Gates Warning SonarQube Quality Gates -> Jenkins 반영

SonarQube 에서 warning 이 발생하자 Jenkins 에서도 Warning 이 반영된 모습

(SonarQube Quality Gates 에서도 신규 코드에 대한 Code Coverage 수준을 제약조건으로 지정 가능함)

짝 프로그래밍

Keep : 짝 프로그래밍(Pair Programming)을 계속 하면 좋겠다.

저희팀은 애자일 개발 방법론에서 보편적으로 하라고 하는 짝 프로그래밍을 원래부터 하고 있습니다. 혹시 모르시는 분이 계시다면, 항상 2명 혹은 그 이상이 모여서 한대의 컴퓨터로 프로그래밍을 하는 것입니다.

페어 프로그래밍은 가장 많은 “Keep”을 받은 항목이기도 합니다. KPT 스토리 라인을 자세히 적으면 너무 길어지니 간략히 정리해보겠습니다.

가급적 스프린트마다 Pair 를 변경한다.
한 Pair 는 하나의 컴퓨터를 사용해서 개발한다. 보통은 코드를 작성하는 사람의 PC를 사용하며, 코드 작성자가 교체되면 PC도 코드 작성자 것을 사용한다. : 각 개인의 PC 설정이 워낙 달라서 남의 PC를 사용하면 효율성이 매우 저하되기 때문입니다. Git 을 사용해서 브랜칭이 쉬워진 상황에서는 컴퓨터 자체를 교체하는 것이 그리 어렵지 않습니다. pair 용 브랜치에서 계속 push 해가면서 자리를 바꾸면 됩니다.
간혹 어떤 업무가 매우 여러 스프린트에 걸쳐 있고, 시급성이 높아서 페어가 바뀌면 오히려 시간이 너무 지체될 경우가 있을 수 있다면 스프린트가 바뀌어도 페어 교체를 하지 않습니다.

페어 프로그래밍이 효율적인지 여부에 대해서는 많은 논란이 있는 것으로 알지만, 대부분의 결론은 “장기적으로는 더 유리하다”인 것으로 알고 있습니다.

페어 프로그래밍의 효용에 관한 학술적 증명에 관해서 접어 두더라도 다음 사항 때문에라도 저는 페어 프로그래밍을 해야한다고 봅니다.

이미 수조원을 다루는 회사로서, 개발자 한 두명에게 핵심 비즈니스의 존립을 의존하는 것은 개발비 조금 아끼겠다고 수억원의 손실을 볼 수도 있다는 얘기가 됩니다.
한 두명의 휴가 혹은 퇴사로 인해서 프로젝트 전체의 존립이 위협받는 일이 발생해서는 안 됩니다. 이런 것을 Bus Factor/Truck Factor/Lottery Factor 라고 부릅니다. Bus Factor 를 높이는(높은게 좋은 것입니다. 1명만 퇴사해도 문제가 생기는 팀보다 5명이 퇴사해야 문제가 생기기 시작하면 더 좋은 상태) 가장 확실한 방법이 페어 프로그래밍이라고 생각합니다.
특히 중요한 비즈니스 구현은 여러명이 함께 볼 수록 오류 확률이 줄어듭니다. - 혼자하다가 오류가 발생하는 상황은 이미 여러번 겪은 것이며 그때마다 회고를 하면 나오는 얘기는 “두 명 이상이 함께 작업하자” 였습니다. 그리고 그걸 실제로 실천을 해야겠지요.

제가 거의 확신하는게 있는데, 바로 제가 내일 당장 회사를 안나와도 우리팀은 아무 일도 없었던 듯이 돌아 갈 것이라는 사실입니다.

코드리뷰와 개발 기법 공유

Keep : 코드리뷰를 계속 잘하면 좋겠다.
Problem : Upsource 등의 온라인 툴을 이용한 코드 리뷰를 자꾸 놓치게 된다. 특히 코드의 맥락을 놓치게 되어 대충 리뷰하는 경우도 생긴다.
Problem : 페어를 하다보면 자기 짝의 좋은 개발 기법이나 좋은 툴 사용법을 배우게 된다. 이게 팀 전체로 확산되면 좋겠다.

우리는 Upsource를 코드 리뷰 툴로 사용하며 온라인 코드 리뷰를 합니다. 간단한 리뷰는 이걸로 끝내기도 합니다.

하지만 온라인으로 지속적으로 올라오는 리뷰를 자꾸 놓치고 그냥 넘어가거나, 혹은 보더라도 변경된 코드 중 무엇을 먼저봐야할지 몰라서 흐름 파악이 잘 안되거나 해서 대충보거나 하게 됩니다.

여기서 쉽게 나오는 Try는 “코드리뷰를 꼼꼼하게 잘하자”가 될 수도 있습니다. 하지만 이런 추상적이고 “잘해보자~” 식의 Try 는 결국 또 잘 안되네로 귀결되는 경우가 많습니다.

Try : 정기적으로 모여서 중요 변경점은 Offline 코드 리뷰를 하자. 그러면서 페어를 하면서 배운 좋은 프로그래밍 기법과 개발툴 사용법등을 함께 공유하자.

모든 코드를 다 오프라인 리뷰하지는 않고, 변화가 크고 비즈니스 복잡도가 높은 것들은 되도록 오프라인 리뷰를 통해 코드 품질 뿐만 아니라 비즈니스 도메인에 관한 지식이 팀원 전체에게 전파되도록 합니다. 이 과정에서 그간 새로 배운 프로그래밍 기법/도구도 함께 전파되는 시간을 갖도록 합니다.

초 고밀도 프로젝트 - 우리는 올바른 방향으로 가고 있는가? - 통합 시연(demo)를 통해 확인해보자

2019년 봄, 우리는 전사의 여러 팀이 모두다 한 방향으로 향하여 비즈니스 프로세스부터 개선하면서 시스템을 새로 구축하는 작업을 하게 됩니다. 프로젝트 기한도 당연히 정해져 있습니다.

Problem : 매우 많은 팀이 참여하는 초 고밀도 프로젝트, 우리가 올바로 가고 있는지 확인이 필요합니다.
Try : 1주일마다 목표 개발 목표 잡고 통합해서 잘 돌아가는지 개발/기획이 모두 모여 데모를 합시다.

이러한 상황에서 프로젝트가 끝나가는 시점이 되어서야 “우리 다함께 모여서 테스트 해봅시다!” 하는 것은 보통 실패로 끝나는 것 같습니다. 우리가 올바로 가고 있는지, 그 수많은 팀들이 올바로 사태를 이해하고 의사소통을 하고 있는지 통합 시연을 해보면 문제가 보입니다.

이 사항은 사실 KPT를 통해 도출 된 것은 아니고 Agile 개발 방법론에서 자주 나오는 항목인 지속적인 통합을 실천한 것 뿐입니다.

오픈 일정은 정해져 있습니다. 오픈 직전의 전사 완전 통합 테스트 전까지 개발을 끝내야만 합니다. 그 시기까지 1주일단위로 할 일을 나누고, 1주일마다 그것이 달성되었는지 통합 시연을 보여줍니다.

실제로 1주일마다 시연을 해보면 제대로 작동하는 경우가 별로 없습니다. 그리고 제대로 작동해도 문제가 발생합니다. 작동은 했지만 옆에서 데모를 보던 기획자가 “저건 제가 얘기했던게 아닌데요?” 라고 한마디 툭 던지게 되죠.

데모의 목표는 성공이 아니라 실패를 빠르게 잡아내는데 있습니다. 데모를 최선을 다해 준비하되 뭐가 문제인지 파악하는데 주안점을 둡니다. 실패를 비난하는 것은 데모의 목표가 아닙니다.

여러 팀이 만든 각종 API 는 의도대로 구현되었고, 호출 되고 있는가?
기획자의 의도가 저게 맞는가?
기획자의 의도대로 했는데 정작 해보니 오히려 불편하던데?

여러번에 걸친 데모로 저러한 사항들을 계속 잡아내며 프로젝트는 완벽하지는 않았을 지라도 큰 문제 없이 오픈을 하게 되었습니다.

개인적으로 이러한 데모는 심리적 효과도 매우 크다고 봅니다. 1년 뒤의 목표를 향해 하염없이 가는 것과 1주일에 한 발자국 갈 때마다 잘 갔는지 확인하고 성취감을 느끼는 것 중 후자가 훨씬 더 집중력의 끈을 놓지 않게 해줍니다.

Problem : 프로젝트의 거의 막바지 기능적 요구사항들이 거의 구현은 됐으나 버그들이 곳곳에서 발견되었는데 데모 준비 때문에 버그 잡을 시간이 없어요.
Try : 데모 중단. 이제 버그 잡는데 집중합니다.

절대적인 규칙은 없습니다. 바꿔야 하면 바꿉니다.

요즘에는 사실 데모를 잘 안합니다. 일단 이렇게 통합 테스트할 일이 별로 없고, 저희 팀이 UI가 거의 없다보니 기획자들에게 UI를 의미있게 보여주는 데모도 별로 없었기 때문입니다.

하지만 이게 언제 어떻게 다시 바뀔지는 모릅니다.

Keep/Problem/Try 주의할 점

KPT를 하면서 몇가지 주의할 점들이 보였습니다.

첫째는 남 탓을 해서는 안됩니다. 내 문제가 아니고 남의 문제(Problem) 혹은 남의 잘한 점(Keep)을 내가 개선(Try)할 수는 없습니다. 칭찬하던지 비난만 할 수 있겠죠. 문제의 초점을 남이 아닌 나로 옮겨서 살펴보도록 해야 내가 할 일(Try)이 도출 될 수 있습니다. 남 탓만 해서는 변화가 있을 수 없겠지요.

두 번째는 구체적이고 실천적어야 한다는 점입니다. 제 경험상 회고를 하고나면 꼭 나오는 얘기가 있습니다. “이번에 소통이 안돼서 장애가 났습니다, 공유를 잘 합시다.” 이건 하나마나한 얘기 입니다. 공유를 잘 할 수 있는 구체적 방안이 Try 로 도출 되어야만 합니다.

만약 우리가 도출한 Try가 “문서화를 잘하자”, “공유를 잘하자” 이런 식이라면 KPT를 다시 수행해야 합니다.

간단한 예를 들어보면(실제로 있었던 일입니다),

Problem : 광고 상품이 추가되면 유관 부서에 공유를 해줘야 하는데 안 해줘서 데이터 정합성이 안 맞는 일이 발생했다.
처음 나온 Try : 상품이 추가되면 x, y, z 팀에 잘 알려주도록 합시다.
구체적 Try : 상품을 추가하는 코드가 호출되면 유관 팀을 모아둔 그룹 메일을 자동 발송하는 기능을 넣도록 합시다. 유관 팀이 변경되면 그룹 메일에 해당 팀을 추가/삭제 해주면 됩니다.
더 근본적인 Try : 광고 상품의 추가와 무관하게 작동하는 보편적 시스템을 구축하자(여기까지는 아직 못갔음).

마무리

위에 든 예들은 다소 큼직한 것들만 정리한 것입니다. 사실은 남은 회식비를 어떻게 쓸지, 회고할 때 회고 그 자체에 대해서도 KPT 를 하기도 하면서 회고를 개선하기도 합니다.

또한 위의 것들이 모두다 정식으로 회고의 KPT 시간에 이뤄진 것도 아닙니다. KPT를 반복하다보면 우리도 모르는 사이에 일상의 문제에서 KPT 형태로 대화를 하고 있는 자신을 발견하기도 합니다. KPT 가 자신도 모르는 사이에 일상화가 되어 버린 것이지요. 그리고 여러번 반복 하다보면 Keep 만 반복해서 나오고 Problem/Try 는 나오지 않는 상황이 오랜시간 계속 되기도 합니다.

그럼에도 저는 KPT 가 회고 시간에 공식 시간으로 있는게 좋다고 생각하는 편입니다. “내가 이런 문제를 얘기해도 될까?” 라는 생각으로 멈춰 있을 때 공식적인 시간이 있으면, 다소 문제점 등이 자연스럽게 끄집어져 나오는 것 같습니다.

누군가가 우리팀 문화의 핵심이 무엇이냐고 묻는 다면, 팀원들이 언제나 문제점(P)이나 계속 했으면하는 점 혹은 계속 더 잘하기 위해 했으면 하는 점(K)을 꺼내놓고 논의하여 새로운 시도(T)를 할 수 있는 체계가 갖춰져 있다는 점을 꼽고 싶습니다. 그냥 눈치껏 그렇게 하는게 아니라요.

아마존의 제프 베조스가 2017년에 주주들에게 보낸 편지를 보면 “주객 전도에 대한 경계”라는 부분이 있습니다.

절차는 절차일 뿐, 대단한 무언가가 아닙니다. 항상 스스로 물어봐야 합니다. 우리가 절차를 이용하고 있는지, 우리가 그 절차에 그냥 속해있는지.

팀 문화로 예를 든 여러가지는 제가 보기엔 좋은 서비스를 만들기 위한 수단입니다. 우리가 이용할 도구이지 그 자체가 목적이 아닙니다. 그렇기에 상황에 따라 적절히 다듬어 나가야 하며 Keep/Problem/Try 가 그 팀 문화 다듬기의 좋은 수단이 되어 줄 것입니다.

우리팀의 문화는 한번에 된 것이 아니라 2년이상에 걸쳐 구축되었고 앞으로도 지속적으로 바뀔 것입니다.

고맙습니다.