흐름의 통제, 가속, 그리고 진화
365 Proejct (314/365)
내 글에 이어서 생각하기 029:
일을 공유하고 관리하기 에 이어서 흐름으로 일하기에 이어서 흐름의 시작: 멈춤과 분할의 원칙 에 이어서 흐름의 명료함 에 이어서
흐름을 만들고 명확하게 정의했다면, 이제는 이 흐름을 현명하게 통제하고, 막힌 곳을 뚫어 가속하며, 꾸준히 더 나은 방향으로 진화시켜야 합니다. 이 세 단계는 한 번에 끝나는 것이 아니라, 서로 맞물려 돌아가는 개선의 엔진과 같습니다.
흐름의 통제: 무자비한 단순함으로 길을 열다
화요일 아침 스프린트 계획 미팅입니다. 화이트보드에는 '해야 할 일' 목록이 가득합니다. 기획자가 말합니다. "신규 기능 A도 중요하고, 버그 B도 고쳐야 하고, 고객이 요청한 C도 해야 하고, 그리고..." 목록은 계속 늘어납니다. 팀원들은 고개를 끄덕이지만 눈빛은 불안합니다.
"이걸 이번 주에 다 한다고?" 금요일 저녁, 예상대로 A는 70% 완성, B는 시작도 못 했고, C는 절반쯤 진행되었습니다. 아무것도 '완료'되지 않았습니다. 다음 주 월요일, 우리는 같은 일들을 다시 이어서 합니다. 그 사이 새로운 긴급 요청 D, E가 추가됩니다. 악순환이 시작됩니다.
이것이 바로 '선택하지 않는 팀'의 전형적인 모습입니다. 모든 아이디어와 요청은 저마다의 이유로 중요해 보입니다. 하지만 모든 것을 '지금' 하려는 시도는 결국 아무것도 제때 끝내지 못하는 결과로 이어집니다. 흐름을 통제하는 첫걸음은 '무자비한 단순함(Ruthless Simplicity)'을 받아들이는 것입니다. 이것은 냉정하게 들릴 수 있지만, 실제로는 팀을 보호하는 가장 따뜻한 결정입니다.
NOW, NEXT, LATER: 우선순위의 명료함
당신이 신입 기획자로서 백로그(Backlog)를 처음 봤을 때를 떠올려보세요. 스크롤을 내려도 내려도 끝이 없는 티켓들. 어떤 것은 6개월 전에 만들어졌고, 어떤 것은 어제 추가되었습니다. 어떤 것은 "긴급"이라고 표시되어 있지만 3개월째 아무도 손대지 않았습니다. 우선순위 열을 보니 High가 30개, Medium이 50개입니다. "도대체 진짜 우선순위가 뭐지?" 당신은 혼란스럽습니다.
이것이 바로 백로그가 '쓰레기장'으로 변하는 과정입니다. 모든 것을 보관하려다가 정작 중요한 것을 찾을 수 없게 되는 것이죠. 이런 혼란을 없애는 가장 강력한 프레임워크가 바로 NOW, NEXT, LATER입니다. 이 세 단어는 단순해 보이지만, 팀의 집중력을 극적으로 바꿔놓습니다.
NOW는 이번 주, 혹은 이번 스프린트에 세상이 무너져도 반드시 끝내야 할 극소수의 일입니다. '극소수'라는 표현에 주목하세요. 5명 팀이라면 NOW에는 3~5개 정도의 스토리만 있어야 합니다. "그것밖에 안 돼?"라고 놀랄 수 있습니다.
하지만 기억하세요. 우리의 목표는 많은 일을 '시작'하는 것이 아니라 적은 일을 '완료'하는 것입니다. NOW에 있는 일은 팀의 모든 집중력이 쏟아지는 곳입니다. 다른 어떤 일이 들어와도, NOW가 끝나기 전에는 새로운 일을 시작하지 않습니다.
실제 상황을 상상해봅시다. 수요일 오후, 영업팀에서 급하게 메시지를 보냅니다. "고객사 A가 요청한 기능 없으면 계약 취소한대요. 이번 주까지 꼭 만들어야 해요!" 이전의 당신 팀이라면 어떻게 했을까요? 아마도 하던 일을 멈추고 즉시 이 긴급 요청에 달려들었을 것입니다. 그 결과 기존에 하던 A, B, C는 모두 미완성으로 남고, 긴급 요청도 제대로 끝내지 못한 채 주말을 맞이합니다.
하지만 NOW, NEXT, LATER를 사용하는 팀은 다르게 반응합니다. 팀장이 묻습니다. "이 요청이 정말 NOW에 들어갈 만큼 중요한가요? 그렇다면 현재 NOW에 있는 어떤 일을 NEXT로 미뤄야 할까요?" 영업팀과 논의합니다. "사실 계약 취소까지는 아니고, 다음 주 화요일 미팅 전까지만 있으면 됩니다." 팀장이 답합니다. "좋습니다. 그럼 현재 NOW를 금요일까지 완료하고, 다음 주 월요일부터 이 일을 NOW로 올려서 화요일까지 완료하겠습니다." 명확한 약속이 생기고, 기존 작업도 보호받으며, 긴급 요청도 적절히 대응됩니다.
NEXT는 NOW가 끝나는 즉시 시작할 수 있도록 모든 준비가 완료된 일입니다. 여기서 '모든 준비'가 핵심입니다. 기획이 완료되었나요? 디자인은? 기술적 리스크는 검토했나요? 필요한 외부 리소스는 확보했나요? 수용 조건은 명확한가요? 이 모든 질문에 "예"라고 답할 수 있을 때만 NEXT에 들어갈 자격이 있습니다.
실제로 많은 팀이 실수하는 부분이 바로 이것입니다. NEXT에 "신규 결제 시스템 구축"이라는 큰 스토리가 있습니다. NOW가 끝나자 팀은 이 일을 시작합니다. 하지만 첫날부터 문제가 터집니다. "결제 대행사 API 문서가 어디 있죠?" "보안팀 검토를 받아야 하는데 신청 안 했네요." "디자인이 아직 초안 단계인데요?" 결국 개발자들은 일을 시작했지만 진행할 수 없어서 또 대기합니다. NEXT라고 표시되었지만 실제로는 준비되지 않은 일이었던 것입니다.
제대로 된 NEXT는 이렇습니다. "카카오페이 결제 연동으로 구매 전환율 5% 향상" 스토리가 NEXT에 있습니다. 이 스토리에는 이미 다음이 준비되어 있습니다. 카카오페이 API 문서와 테스트 계정, 완성된 UI 디자인 파일, 보안팀의 사전 승인, 명확한 수용 조건, 예상 개발 시간 2~3일. NOW가 끝나는 금요일 오후, 개발자는 월요일 아침에 즉시 코딩을 시작할 수 있다는 확신을 가지고 퇴근합니다. 이것이 진짜 NEXT입니다.
LATER는 좋은 아이디어지만 지금 당장 신경 쓰지 않아도 될 모든 것입니다. 그리고 여기에 대부분의 백로그가 있어야 합니다. "고객 리뷰 시스템", "다크 모드 지원", "AI 추천 기능" 같은 멋진 아이디어들이 LATER에 있습니다. 이것들은 언젠가 할 수도 있고, 영영 하지 않을 수도 있습니다. 그리고 그것은 괜찮습니다. LATER에 100개의 아이디어가 있어도 팀은 전혀 신경 쓰지 않습니다. 팀의 모든 에너지는 NOW의 3~5개에만 집중되어 있으니까요.
여기서 중요한 원칙 하나를 기억해야 합니다. 백로그는 가보를 모아두는 보물창고가 아니라, 신선한 재료를 보관하는 냉장고여야 합니다. 냉장고에 6개월 된 음식을 계속 보관하지 않듯이, 백로그도 신선하게 유지해야 합니다. 상위 10~20개의 아이템만 구체적으로 관리하고, 나머지는 가벼운 아이디어 목록으로 옮기세요. 3개월 동안 아무도 관심 없었던 티켓은 과감히 닫으세요. "나중에 필요하면 어떡하지?"라는 걱정은 버리세요. 정말 중요하면 다시 제안될 것이고, 그렇지 않다면 애초에 중요하지 않았던 것입니다.
역산 스케줄링: 마감일로부터 거꾸로 계획하기
NOW를 정했다면, 이제 '어떻게 제때 끝낼 것인가'를 계획해야 합니다. 대부분의 팀은 이렇게 계획합니다. "이 일은 월요일에 시작해서... 개발에 3일 정도 걸리고... 리뷰에 하루, QA에 하루... 그럼 금요일쯤 끝나겠네?" 하지만 금요일이 되면 여전히 개발 중입니다. "생각보다 시간이 더 걸려서요." 배포는 다음 주로 미뤄집니다. 매번 반복되는 이 패턴, 왜 생길까요?
문제는 앞에서부터 계산하는 방식에 있습니다. 우리는 항상 일을 낙관적으로 추정하고, 예상치 못한 문제를 고려하지 않습니다. 해결책은 역산 스케줄링(Backwards Scheduling), 즉 마감일로부터 거꾸로 계획하는 것입니다.
구체적인 예를 들어보겠습니다. 금요일 오후 5시에 신규 기능을 배포하는 것이 목표입니다. 이제 거꾸로 계획합니다. 금요일 오후 5시 배포라면, 최소 2시간 전인 오후 3시에는 배포 준비가 완료되어야 합니다. 만약 문제가 생기면 롤백할 시간이 필요하니까요. 오후 3시에 배포 준비가 되려면, QA가 완료되어야 합니다. QA는 최소 반나절이 걸리니, 금요일 아침 9시에는 QA팀에 전달되어야 합니다.
QA팀에 전달하려면 코드 리뷰가 완료되어야 합니다. 코드 리뷰는 보통 하루 걸리니, 목요일 아침에는 리뷰 요청이 올라가야 합니다. 리뷰 요청을 올리려면 개발이 완료되어야 합니다. 개발에 이틀 걸린다면, 늦어도 화요일 아침에는 개발을 시작해야 합니다.
정리하면 이렇습니다.
화요일: 개발 시작
목요일 아침: 개발 완료, 리뷰 요청
금요일 아침: 리뷰 완료, QA 시작
금요일 오후 3시: QA 완료, 배포 준비
금요일 오후 5시: 배포
이제 팀은 명확히 압니다. 만약 화요일에 개발을 시작하지 못하면, 금요일 배포는 불가능합니다. 만약 목요일 아침에 아직 개발 중이라면, 금요일 배포를 포기하고 다음 주로 계획을 조정해야 합니다. 역산 스케줄링은 '희망적 추측'을 '현실적 계획'으로 바꿔줍니다.
실제 팀에서 이것이 어떻게 작동하는지 봅시다. 월요일 스프린트 계획 미팅입니다. 기획자가 말합니다. "이번 주 금요일까지 A, B, C 세 가지 기능을 배포하면 좋겠어요." 팀장이 화이트보드에 역산 타임라인을 그립니다. "금요일 배포라면 목요일에 QA, 수요일에 리뷰가 끝나야 해요.
개발은 화요일까지 완료되어야 하고요. A는 개발에 이틀, B는 하루, C는 이틀 걸리네요. 우리 개발자가 3명이니까..." 계산해보니 C는 금요일까지 불가능합니다. 팀장이 말합니다. "A와 B는 금요일에 배포 가능하지만, C는 다음 주 화요일이 현실적입니다. 금요일에 억지로 하면 QA를 건너뛰거나 야근해야 해요." 기획자가 고민하다 답합니다. "알겠어요. C는 다음 주로 하죠. 대신 A와 B는 확실하게 금요일에 나가는 게 낫겠네요."
역산 스케줄링은 불가능한 약속을 막아줍니다. 그리고 팀을 보호합니다. "왜 못 끝냈어?"라는 비난 대신, "계획대로 진행되고 있어"라는 확신을 줍니다. 신입사원인 당신이 내일 당장 실천할 수 있는 것은 이것입니다. 어떤 일을 맡았을 때, "언제 시작할까?"가 아니라 "언제 끝내야 하지?"부터 생각하세요. 그리고 거꾸로 계산하세요. 그러면 "오늘 무엇을 해야 하는지"가 명확해집니다.
흐름의 가속: 협업으로 병목을 제거하다
흐름을 통제했다면, 이제는 그 흐름을 막는 장애물을 제거할 차례입니다. 당신이 개발자로서 수요일 오전에 코드를 완성하고 리뷰를 요청했다고 상상해보세요. 당신은 뿌듯합니다. "예상보다 빨리 끝났네!" 이제 다음 일을 시작하려는데 WIP 제한 때문에 시작할 수 없습니다.
"그럼 리뷰가 완료될 때까지 기다려야겠네." 수요일 오후, 목요일, 금요일... 아무 피드백이 없습니다. 월요일에 리뷰어에게 슬랙 메시지를 보냅니다. "리뷰 언제 가능하세요?" 답장이 옵니다. "아, 미안해요. 바빠서 못 봤어요. 이따 볼게요." 화요일이 되어서야 리뷰가 달립니다. 당신의 코드는 5일 동안 대기 상태에 있었습니다.
이것이 바로 흐름에서 가장 큰 적인 '대기 시간'입니다. 열심히 노를 저어도 강 중간에 보이지 않는 그물이 있다면 배는 나아갈 수 없습니다. 우리 시스템의 속도를 갉아먹는 두 가지 대표적인 그물은 '리뷰 대기'와 '좀비 이슈'입니다.
24시간 리뷰 약속: 흐름을 막지 않는 문화
많은 팀에서 코드 리뷰나 문서 리뷰는 "시간 나면 하는 일"로 여겨집니다. 자신의 개발이 더 중요하고, 리뷰는 부차적인 일로 생각되죠. 하지만 이것은 근본적으로 잘못된 생각입니다. 당신의 코드가 리뷰를 기다리는 동안, 팀 전체의 WIP는 꽉 차 있고, 다른 팀원도 새로운 일을 시작할 수 없으며, 고객은 가치를 받지 못합니다. 리뷰 지연은 한 사람의 문제가 아니라 팀 전체의 처리량(Throughput)을 떨어뜨리는 시스템 문제입니다.
해결책은 명확합니다. '24시간 리뷰 약속'을 팀의 원칙으로 세우는 것입니다. 리뷰 요청이 들어오면 24시간 이내에 피드백을 주는 것을 팀의 최우선 원칙으로 만드세요. 완벽한 리뷰가 아니어도 괜찮습니다. 빠른 피드백이 완벽한 리뷰보다 100배 더 가치 있습니다.
실제 상황을 봅시다. 목요일 오전, 당신의 칸반 보드를 보니 'In Review' 상태에 3개의 코드가 있습니다. WIP 제한이 3이므로 더 이상 새로운 개발을 시작할 수 없습니다. 이전의 당신이라면 "리뷰는 시니어가 하는 거니까 나는 기다려야지"라고 생각했을 것입니다. 하지만 지금은 다릅니다. 당신은 손을 들어 말합니다. "제가 리뷰를 도와드릴까요? 시니어분만큼은 못 보겠지만, 기본적인 코드 스타일이나 명백한 버그 정도는 찾을 수 있을 것 같아요." 시니어가 고맙다고 답합니다. "좋아요. 이 PR은 비교적 간단하니 먼저 봐주시겠어요?"
당신은 30분 동안 코드를 읽고 첫 리뷰를 남깁니다. "변수명 tmp 보다는 userEmail 이 더 명확할 것 같아요. 그리고 이 부분 에러 핸들링이 빠진 것 같은데 확인 부탁드려요." 완벽한 리뷰는 아니지만, 코드 작성자는 즉시 피드백을 받고 수정할 수 있습니다. 시니어는 나중에 더 깊은 리뷰를 추가하지만, 이미 기본적인 이슈들은 해결된 상태입니다. 'In Review'에서 하나가 'Done'으로 이동하고, 이제 팀은 새로운 일을 시작할 수 있습니다.
만약 리뷰 대기열이 WIP 한도를 초과한다면, 이것은 명확한 신호입니다. "새로운 개발을 시작하지 말고, 리뷰 병목을 해결하라." 월요일 스탠드업에서 팀장이 말합니다. "지금 'In Review'에 5개가 쌓여 있네요. WIP 제한이 3인데 초과했어요. 오늘은 새로운 개발을 시작하지 말고, 모두 리뷰에 집중합시다." 시니어 개발자들은 오전을 리뷰에 쓰고, 주니어들은 간단한 리뷰와 테스트를 돕습니다. 오후가 되자 'In Review'는 2개로 줄어들었고, 흐름이 다시 원활해집니다.
24시간 리뷰 원칙을 도입한 한 팀의 이야기를 들려드리겠습니다. 처음에는 저항이 있었습니다. "제 일도 바쁜데 남의 리뷰까지 24시간 안에?" 하지만 한 달 후 변화가 보였습니다. 평균 리뷰 대기 시간이 3일에서 하루로 줄었고, 사이클 타임이 30% 단축되었습니다. 더 중요한 것은 팀 분위기였습니다. 이전에는 "리뷰 언제 해주실 건가요?"라는 재촉 메시지로 긴장이 있었지만, 이제는 리뷰가 빠르게 돌아가면서 서로 감사 메시지를 주고받게 되었습니다. "빠른 리뷰 감사합니다!" "도움이 되는 피드백 감사해요!" 협업의 질이 달라졌습니다.
좀비 이슈 정리: 시스템을 건강하게 유지하기
리뷰 대기가 단기적 병목이라면, '좀비 이슈'는 장기적으로 시스템을 좀먹는 독입니다. 좀비 이슈란 무엇일까요? 생성된 지 오래되었지만 아무런 진척 없이 방치된 티켓들입니다. "언젠가 해야지"라고 생각하며 만들어졌지만, 실제로는 아무도 신경 쓰지 않는 일들이죠.
당신이 신입으로 백로그를 정리하는 업무를 맡았다고 상상해보세요. 티켓을 하나 엽니다. "고객 푸시 알림 개선". 생성일: 8개월 전. 마지막 업데이트: 6개월 전. 댓글을 보니 "나중에 해요"라는 말만 세 번 반복되어 있습니다. 담당자도 이미 퇴사했습니다. 이 티켓은 무엇을 의미할까요? 정말 중요한 일일까요, 아니면 잊혀진 일일까요? 알 수 없습니다. 하지만 확실한 것은 이 티켓이 백로그를 복잡하게 만들고, 우선순위를 흐리며, 팀의 집중력을 분산시킨다는 것입니다.
좀비 이슈를 정리하는 규칙은 간단합니다. 7일 이상 아무런 업데이트가 없는 티켓에는 자동으로 알림을 보냅니다. "이 티켓은 7일 동안 업데이트가 없습니다. 여전히 진행 중인가요?" 14일이 지나면 더 강한 알림을 보냅니다. "이 티켓은 2주 동안 정체되어 있습니다. 계속 진행할 계획이 있나요? 없다면 닫아주세요." 30일이 지나면 자동으로 'Stale(오래됨)' 라벨이 붙고, 60일이 지나면 자동으로 닫힙니다.
"하지만 나중에 필요할 수도 있잖아요?"라는 우려가 생길 수 있습니다. 여기서 중요한 마인드셋 전환이 필요합니다. 닫힌 티켓은 삭제된 것이 아닙니다. 언제든 다시 열 수 있습니다. 정말 중요한 일이라면 누군가 다시 제안할 것이고, 그렇지 않다면 애초에 중요하지 않았던 것입니다. 백로그는 '혹시 모를 보험'이 아니라 '다음 행동'을 위한 명확한 리스트여야 합니다.
실제 팀에서 이것을 실천해봅시다. 금요일 오후, 팀은 '좀비 이슈 정리의 날'을 갖습니다. 30일 이상 방치된 티켓 20개를 화면에 띄웁니다. 하나씩 빠르게 결정합니다. "이건 여전히 필요한가요?" "아니요, 상황이 바뀌어서 필요 없어졌어요. 닫을게요."
"이건요?" "아, 이건 중요한데 시간이 없어서 못 했어요." "그럼 지금 NOW, NEXT, LATER 중 어디에 넣어야 할까요?" "음... LATER요." "좋아요. 그럼 LATER로 옮기고 이번 분기 내에 다시 검토하기로 해요." 한 시간 만에 20개 중 15개를 닫고, 3개를 LATER로, 2개를 NEXT로 명확히 분류했습니다.
이렇게 정리하고 나면 백로그가 숨 쉬기 시작합니다. 신입사원인 당신이 백로그를 볼 때 "도대체 뭐가 중요한 건지 모르겠어"가 아니라 "아, 지금 중요한 건 이 5개구나"라고 명확히 알 수 있습니다. 좀비 이슈 정리는 단순히 티켓을 줄이는 게 아니라, 팀의 정신적 명료함을 되찾는 과정입니다.
흐름의 진화: 감이 아닌 데이터로 개선하다
당신의 팀장이 금요일 회고에서 묻습니다. "이번 주는 어땠나요?" 팀원들이 답합니다. "바빴어요." "뭔가 많이 한 것 같은데 잘 모르겠어요." "저는 괜찮았던 것 같은데요?" 모두의 느낌이 다릅니다. 팀장이 다시 묻습니다. "그래서 우리가 개선해야 할 부분이 뭘까요?" 침묵이 흐릅니다. "음... 소통을 더 잘해야 할 것 같아요?" 애매한 대답만 나옵니다. 다음 주도 같은 대화가 반복됩니다. 아무것도 바뀌지 않습니다.
왜 이런 일이 생길까요? 우리는 '감'으로만 일하고 있기 때문입니다. 눈을 감고 운전할 수 없듯이, 감으로만 일하는 조직은 성장할 수 없습니다. 데이터는 우리가 어디에 막혀 있는지, 어디로 나아가야 하는지를 객관적으로 보여주는 거울이자 지도입니다.
측정해야 할 핵심 지표들
가장 먼저 측정해야 할 것은 사이클 타임(Cycle Time)입니다. 이것은 한 개의 일이 'In Progress' 상태로 들어와서 'Done'이 될 때까지 걸린 시간입니다. 예를 들어, "카카오 로그인" 스토리를 화요일 오전에 시작해서 목요일 오후에 완료했다면, 사이클 타임은 2.5일입니다. 이 숫자는 무엇을 말해줄까요? 우리 팀의 집중력과 내부 효율성을 보여줍니다. 사이클 타임이 길다면, 일을 하는 동안 방해받거나 대기하는 시간이 많다는 뜻입니다.
실제로 데이터를 봅시다. 지난 달 완료된 스토리 20개의 사이클 타임을 측정했습니다. 평균은 5일인데, 어떤 스토리는 2일, 어떤 스토리는 12일이 걸렸습니다. 왜 이렇게 차이가 날까요? 12일 걸린 스토리를 들여다봅니다. "결제 UI 개선" 스토리였습니다.
타임라인을 보니, 개발 2일, 디자인 피드백 대기 3일, 개발 재작업 1일, 리뷰 대기 4일, QA 2일. 실제 작업 시간은 5일이지만, 대기 시간이 7일이었습니다. 이제 우리는 압니다. 문제는 개발 속도가 아니라 '대기'라는 것을요.
다음은 리드 타임(Lead Time)입니다. 이것은 아이디어가 처음 백로그에 추가된 순간부터 고객에게 전달되기까지 걸린 전체 시간입니다. 리드 타임은 고객 관점의 속도를 보여줍니다. 고객은 우리가 얼마나 바쁘게 일했는지 관심 없습니다. 그들이 원하는 것은 "내가 요청한 게 언제 나와?"입니다.
예를 들어, 고객이 3월 1일에 "배송지 변경 기능이 필요해요"라고 요청했습니다. 우리는 3월 5일에 백로그에 추가했고, 3월 20일에 개발을 시작했으며, 3월 27일에 배포했습니다. 리드 타임은 26일입니다. 하지만 실제 개발에 걸린 시간(사이클 타임)은 7일뿐입니다.
나머지 19일은 무엇을 했을까요? '기다렸습니다.' 우선순위 결정을 기다리고, 디자인을 기다리고, 개발자 리소스를 기다렸습니다. 리드 타임이 길다는 것은 시스템 전체에 비효율이 많다는 신호입니다.
세 번째는 누적 흐름 다이어그램(Cumulative Flow Diagram, CFD)입니다. 이것은 매일 각 상태(To Do, In Progress, In Review, Done)에 몇 개의 일이 있는지를 시간에 따라 쌓아 올린 그래프입니다. CFD를 보면 병목이 어디서 발생하는지 한눈에 알 수 있습니다.
실제 CFD를 상상해봅시다. 가로축은 시간(주 단위), 세로축은 누적 스토리 개수입니다. 그래프는 여러 색깔 층으로 나뉘어 있습니다. 맨 아래는 Done(파란색), 그 위는 In Review(노란색), 그 위는 In Progress(초록색), 맨 위는 To Do(회색). 만약 그래프가 건강하다면, 모든 층이 비슷한 기울기로 증가합니다. 일이 골고루 흘러간다는 뜻이죠. 하지만 특정 층이 두꺼워진다면? 그곳이 병목입니다.
예를 들어, 3월 셋째 주에 In Review 층이 갑자기 두꺼워졌습니다. 무슨 일이 있었을까요? 팀은 데이터를 보고 회고합니다. "아, 그 주에 시니어 개발자 두 명이 휴가였네요. 그래서 리뷰가 밀렸구나." 이제 해결책을 논의합니다. "다음에 여러 리뷰어가 동시에 휴가 갈 때는 미리 알려서, 그 주에는 새로운 개발을 줄이고 이미 진행 중인 일만 마무리하자." CFD는 과거를 반성하고 미래를 계획하는 도구입니다.
마지막으로 중요한 지표는 재작업 비율(Rework Rate)입니다. 완료된 일 중 몇 퍼센트가 버그나 불완전함으로 인해 다시 작업되었는지를 측정합니다. 속도만큼 중요한 것이 품질입니다. 만약 우리가 10개를 빠르게 만들었는데 그중 5개를 다시 고쳐야 한다면, 실제로는 느린 것입니다.
지난달 데이터를 봅니다. 완료된 스토리 30개 중 9개가 재작업되었습니다. 재작업 비율 30%. 놀랍게도 높습니다. 왜 그럴까요? 재작업된 스토리들을 분석합니다. 대부분 수용 조건이 불명확했거나, 리뷰가 부실했거나, QA를 건너뛴 경우였습니다. 팀은 결정합니다.
"다음 달부터 모든 스토리에 명확한 수용 조건을 필수로 작성하고, 리뷰 체크리스트를 도입하자." 한 달 후 재작업 비율이 15%로 떨어집니다. 속도는 오히려 빨라졌습니다. 재작업에 쓰던 시간을 새로운 가치를 만드는 데 쓸 수 있게 된 것입니다.
데이터를 문화로 만들기: 회고의 힘
데이터가 '무엇이' 문제인지 알려준다면, 회고는 '왜' 그런 문제가 발생했고 '어떻게' 해결할지 논의하는 자리입니다. 하지만 많은 팀의 회고는 형식적입니다. "이번 주 좋았던 점? 음... 다들 열심히 했어요. 개선할 점? 소통을 더 잘해야 할 것 같아요. 액션 아이템? 다음부터 소통 더 잘하기." 다음 주 회고도 똑같습니다. 아무것도 바뀌지 않습니다.
효과적인 회고는 구체적인 데이터에서 시작합니다. 금요일 오후 회고 시간입니다. 스크린에 이번 주 CFD를 띄웁니다. 팀장이 묻습니다. "이번 주 In Review 대기 시간이 평균 3일이었는데, 지난주는 1일이었어요. 무슨 일이 있었을까요?" 팀원들이 생각합니다.
개발자가 말합니다. "이번 주 PR이 5개나 동시에 올라왔어요. 보통은 2~3개인데." 시니어가 덧붙입니다. "그리고 제가 화요일에 긴급 미팅이 많아서 리뷰를 못 봤어요." 이제 문제가 구체화됩니다. 팀이 함께 해결책을 찾습니다. "PR을 동시에 여러 개 올리지 말고, 하나씩 완료하고 다음 것을 올리면 어떨까요?" "그리고 리뷰어가 하루 이상 바쁠 예정이면 미리 공유해서, 다른 사람이 리뷰를 준비하면 좋겠어요."
이것이 진짜 회고입니다. "소통을 잘하자" 같은 추상적 다짐이 아니라, "다음 주부터 모든 PR 설명에 예상 결과 스크린샷을 첨부한다", "리뷰어가 바쁠 때는 아침 스탠드업에서 미리 공유한다" 같은 구체적이고 측정 가능한 실행 계획을 만드는 것입니다.
한 달 후 팀은 다시 데이터를 봅니다. 평균 리뷰 대기 시간이 3일에서 1.5일로 줄었습니다. 팀원들이 웃으며 말합니다. "PR 스크린샷 첨부하는 게 처음엔 귀찮았는데, 확실히 리뷰어가 빨리 이해하더라고요." "미리 공유하니까 리뷰가 밀리는 일이 없었어요." 작은 개선이 쌓여 큰 변화를 만듭니다. 이것이 데이터 기반 문화입니다.
개선은 문화이지 이벤트가 아닙니다. 일주일에 한 번 회고하고, 한 달에 한 번 데이터를 검토하며, 매 분기 큰 그림을 다시 그립니다. 작은 개선이 습관이 되고, 습관이 문화가 됩니다. 신입사원인 당신이 내일 당장 실천할 수 있는 것은 이것입니다.
회고에서 "느낌"만 이야기하지 마세요. "이번 주 제가 맡은 일은 사이클 타임이 6일이었는데, 그중 4일이 리뷰 대기였어요"처럼 구체적인 데이터를 이야기하세요. 데이터는 비난이 아니라 개선의 출발점입니다.
도구가 아닌 문화: 우리 손에 맞는 연장 쥐기
여기까지 읽은 당신은 아마 이런 생각이 들 수 있습니다. "좋은 이야기인데, 우리 팀에 JIRA가 없는데요?" "Notion으로도 이런 걸 할 수 있나요?" "Linear는 어떤가요?" 도구에 대한 질문이 자연스럽게 떠오릅니다. 하지만 지금까지 이야기한 모든 원칙은 특정 도구에 종속되지 않습니다. JIRA든, Notion이든, Asana든, Linear든, 심지어 엑셀이나 화이트보드든 상관없습니다. 도구는 우리의 연장일 뿐, 본질이 될 수 없습니다.
실제로 한 스타트업 팀은 처음 6개월 동안 구글 스프레드시트로 칸반 보드를 운영했습니다. 각 열이 상태(To Do, In Progress, In Review, Done)였고, 각 행이 스토리였습니다. WIP 제한은 엑셀 셀에 빨간색으로 숫자를 적어두었습니다.
"In Progress 최대 3개". 누군가 네 번째 일을 시작하려고 하면, 다른 팀원이 "어, WIP 초과예요"라고 알려줬습니다. 완벽한 시스템은 아니었지만, 흐름의 원칙은 지켜졌고, 팀은 잘 작동했습니다. 나중에 규모가 커지면서 JIRA로 옮겼지만, 핵심 원칙은 그대로였습니다.
중요한 것은 일을 대하는 우리의 태도와 우리가 함께 만들어가는 문화입니다. 투명하게 공유하고, 명확하게 정의하며, 작게 쪼개 빠르게 배우고, 끊임없이 회고하며 개선하는 것. 이 원칙들은 어떤 도구에서든 실현 가능합니다.
다만 도구를 선택할 때 몇 가지 조언을 드리자면, 팀의 성숙도와 필요에 맞는 도구를 선택하세요. 5명 팀이 복잡한 JIRA 워크플로우를 설정하느라 일주일을 쓰는 것은 낭비입니다. 반대로 50명 조직이 화이트보드만으로 일하려면 혼란스러울 것입니다. 처음에는 간단한 도구로 시작해서, 필요가 생길 때 진화시키세요. Trello나 Notion 같은 가벼운 도구로 시작했다가, 팀이 커지면 JIRA나 Linear 같은 강력한 도구로 옮겨가는 것도 좋은 전략입니다.
그리고 무엇보다 중요한 것은, 도구가 우리를 섬기게 하는 것입니다. 우리가 도구의 노예가 되어서는 안 됩니다. JIRA가 복잡한 17단계 워크플로우를 강제한다면, 그것이 정말 우리 팀에 필요한지 질문하세요. 만약 팀에 맞지 않는다면 과감히 단순화하세요. 프로세스가 우리를 돕는다면 지키고, 방해한다면 바꾸세요. 완벽한 프로세스는 세상에 존재하지 않습니다. 우리 팀에 맞는 최적의 균형점을 찾아가는 여정만이 있을 뿐입니다.
신입사원인 당신에게
여기까지 긴 이야기를 읽어준 당신에게 감사드립니다. 어쩌면 지금 머릿속이 복잡할 수도 있습니다. WIP 제한, 업무 분할, 사용자 스토리, NOW/NEXT/LATER, 사이클 타임, CFD... 너무 많은 개념들. "이걸 다 어떻게 실천하지?" 압도될 수 있습니다.
하지만 기억하세요. 이 모든 것을 내일 당장 완벽하게 할 필요는 없습니다. 작은 것부터 시작하세요. 내일은 티켓 제목을 더 명확하게 쓰는 것부터 시작해보세요. 다음 주에는 팀에게 WIP 제한을 제안해보세요. 그다음 주에는 사용자 스토리 형식으로 티켓을 작성해보세요. 한 달 후에는 간단한 데이터를 모아 회고에서 공유해보세요. 작은 개선이 쌓여 큰 변화를 만듭니다.
그리고 가장 중요한 것은, 당신이 완벽할 필요가 없다는 것입니다. 실수하세요. 배우세요. 다시 시도하세요. 좋은 팀은 실수를 비난하지 않고, 실수에서 배우는 팀입니다. 당신이 "이 프로세스가 이상한 것 같아요"라고 말할 때, 그것은 불평이 아니라 개선의 시작입니다. 신입이기 때문에 보이는 것들이 있습니다. 그 신선한 시각을 잃지 마세요.
마지막으로, 일은 완벽한 프로세스로 하는 것이 아니라, 사람과 함께 하는 것입니다. 칸반 보드, 데이터, 도구... 이 모든 것은 결국 우리가 함께 더 나은 가치를 더 즐겁게 만들어가기 위한 수단입니다. 동료와 웃으며 일하고, 작은 성공을 함께 축하하고, 막혔을 때 서로 도우며, 실패했을 때 함께 배우세요. 그것이 진짜 흐름입니다.
당신의 팀이 내일 조금 더 나아지길, 당신이 일하며 조금 더 행복하길, 그리고 우리 모두가 만드는 제품이 세상에 조금 더 나은 가치를 전하길 바랍니다. 응원합니다.
