흐름의 시작: 멈춤과 분할의 원칙
365 Proejct (312/365)
내 글에 이어서 생각하기 026: 일을 공유하고 관리하기 에 이어서
내 글에 이어서 생각하기 027: 일을 공유하고 관리하기 에 이어서 흐름으로 일하기에 이어서
어떻게 일할 것인가 001-0-1: 흐름의 시작: 멈춤과 분할의 원칙
신입사원으로 입사한 첫 주, 당신은 아마도 이런 풍경을 목격했을 것입니다. 모니터 세 개를 펼쳐놓고 이 창 저 창을 넘나드는 선배, 슬랙 알림이 끊임없이 울리는 가운데 회의에 들어갔다 나왔다를 반복하는 동료, "바쁘다 바빠"를 입에 달고 사는 팀원들.
그런데 이상하게도 정작 "이번 주에 뭘 완료했어?"라고 물으면 선뜻 대답하기 어려운 분위기. 모두가 바쁜데 왜 일은 끝나지 않는 걸까요? 이 질문에 대한 답이 바로 '흐름(Flow)'을 이해하는 시작점입니다.
제품 개발의 흐름은 가만히 둔다고 저절로 생겨나는 자연 현상이 아닙니다. 그것은 치밀한 설계의 결과물입니다. 역설적이게도, 유연하고 빠른 흐름을 만드는 가장 중요한 열쇠는 무작정 속도를 내려는 '가속'이 아니라, 시스템의 건강 상태를 조절하는 '통제'에 있습니다.
이는 두 가지 핵심 원칙으로 구현됩니다. 첫째, 시스템이 감당할 수 있는 만큼만 일을 진행시키는 'WIP(Work In Progress) 제한'입니다. 둘째, 각 업무를 명확하고 작게 만들어 예측 가능성을 높이는 '업무 분할'입니다. 이 두 원칙을 이해하면, 당신은 "일 잘하는 사람"의 비밀을 알게 될 것입니다.
왜 바쁜데 일이 안 끝날까: WIP 제한의 발견
당신이 개발자라고 상상해봅시다. 오전에는 A 기능 개발을 하다가, 기획자가 급하게 요청한 B 기능 스펙 검토를 하고, 오후에는 어제 시작한 C 버그 수정을 이어서 하다가, 갑자기 터진 D 장애 대응에 투입됩니다. 저녁이 되어 돌아보니 A, B, C, D 모두 '진행 중'이지만 하나도 '완료'되지 않았습니다. 내일 아침 스탠드업 미팅에서 "어제 뭐 했어요?"라는 질문에 당신은 "음... 여러 가지를 조금씩..."이라고 답하게 됩니다. 왜 이런 일이 벌어질까요?
우리는 흔히 여러 작업을 동시에 진행하는 것을 생산성의 상징으로 착각합니다. 멀티태스킹을 잘하는 사람이 유능해 보입니다. 하지만 인지과학의 연구는 정반대를 말합니다. 동시 작업이 늘어날수록 우리의 생산성은 기하급수적으로 떨어지는데, 그 주범은 바로 '문맥 전환 비용(Context Switching Cost)'입니다. A 작업을 하다가 B 작업 요청에 응답하고 다시 A로 돌아올 때, 우리의 뇌는 "아, 내가 A에서 어디까지 했더라? 이 변수가 뭐였지? 다음 단계가 뭐였지?"를 다시 불러오는 데 상당한 에너지를 소모합니다. 연구에 따르면 고작 3개의 작업을 번갈아 진행하는 것만으로도 우리는 업무 시간의 20%에서 40%를 이렇게 낭비합니다.
이는 마치 공 5개로 저글링을 하는 것과 같습니다. 공이 2개일 때는 여유롭게 던지고 받으면서 각각의 공에 집중할 수 있습니다. 하지만 공이 5개가 되는 순간, 당신은 공을 계속 '돌리는' 데만 온 신경을 쏟을 뿐, 어느 공 하나도 제대로 손에 '쥐지' 못합니다. 공이 떨어지지 않게 하는 것만으로도 벅찹니다. 이것이 바로 당신이 "바쁜데 일이 안 끝나는" 이유입니다.
WIP 제한은 이 문제를 정면으로 해결합니다. 만약 당신의 팀이 "동시에 진행 중인 일은 최대 2개까지"라는 규칙을 정했다고 해봅시다. 그러면 세 번째 일이 요청되는 순간, 당신은 자동으로 이렇게 생각하게 됩니다. "이 새로운 일을 시작하려면, 지금 진행 중인 일 중 하나를 먼저 완료해야 해." 이 간단한 규칙이 만드는 변화는 놀랍습니다.
첫 번째 효과는 숨겨진 병목을 수면 위로 드러내는 것입니다. 실제 팀 상황을 예로 들어보겠습니다. 당신의 팀에는 칸반 보드가 있고, 'To Do', 'In Progress', 'In Review', 'Done' 네 가지 상태가 있습니다. 'In Review' 상태에 WIP 제한이 없다면 어떤 일이 벌어질까요? 개발자들은 코드를 계속 작성해서 리뷰 요청을 올립니다. 'In Review'에 일이 5개, 10개, 15개 쌓여도 개발자들은 "내 일은 끝났으니 다음 일 시작해야지"라고 생각하며 새로운 일을 시작합니다. 그 사이 리뷰어는 혼자서 15개의 코드를 검토하느라 허덕이고, 리뷰가 느려지면 개발자들은 "리뷰가 왜 이렇게 느려?"라고 불평합니다. 문제는 명확한데 누구도 해결하지 않습니다.
이제 'In Review' 상태에 "최대 2개"라는 WIP 제한을 걸어봅시다. 개발자가 세 번째 리뷰 요청을 올리려는 순간, 시스템이 막힙니다. 칸반 보드에 빨간 불이 켜집니다. 이때 팀의 반응이 달라집니다. "왜 리뷰가 막혔지? 리뷰어가 부족한가? 리뷰 프로세스에 문제가 있나? 내가 리뷰를 도울 수 있을까?" 팀은 새로운 일을 시작하는 대신, 지금 흐름을 막고 있는 진짜 문제를 해결하는 데 집중하게 됩니다. WIP 제한은 문제가 생긴 곳을 비추는 조명과 같습니다.
두 번째 효과는 '완료' 중심의 문화를 만드는 것입니다. WIP 제한 이전의 스탠드업 미팅을 떠올려보세요. "어제 뭐 했어요?" "A 기능 50% 정도 했고요, B 버그도 보고 있고, C 스펙도 검토했습니다." 모든 게 '진행 중'입니다. 하지만 WIP 제한 이후의 대화는 달라집니다. "어제 뭐 했어요?" "A 기능을 완료해서 배포했습니다. 이제 B를 시작합니다." 팀의 성공 지표가 '얼마나 많은 일을 시작했는가'에서 '얼마나 많은 가치를 고객에게 전달했는가'로 바뀝니다.
더 흥미로운 것은 협업 방식의 변화입니다. 'In Progress' 칸이 꽉 차서 새로운 일을 시작할 수 없는 상황을 상상해보세요. 이전이라면 "할 일이 없네, 쉬어야지"라고 생각했을지 모릅니다. 하지만 WIP 제한이 있는 팀에서는 질문이 바뀝니다. "어떻게 하면 지금 막혀있는 동료를 도와서 우리 팀의 일을 빨리 완료할 수 있을까?" 백엔드 개발자가 프론트엔드 코드 리뷰를 도와주고, 시니어가 주니어의 막힌 부분을 페어 프로그래밍으로 함께 풀어줍니다. 개인의 효율성을 넘어 팀 전체의 효율성을 최적화하는 협업 문화가 자연스럽게 형성됩니다.
그렇다면 어떻게 시작해야 할까요? 먼저 팀의 칸반 보드를 준비합니다. 화이트보드든 노션이든 지라든 상관없습니다. 중요한 것은 모든 일의 상태를 시각화하는 것입니다. 'To Do', 'In Progress', 'In Review', 'Done'처럼 여러분 팀의 실제 작업 단계를 만듭니다. 그리고 처음에는 'In Progress' 상태에 '팀원 수 - 1' 정도로 WIP를 제한해봅니다. 5명 팀이면 4개, 이런 식입니다. 너무 강하게 시작하면 저항이 클 수 있으니까요.
여기서 중요한 것은 WIP 제한을 엄격한 '법률'처럼 대하지 않는다는 점입니다. 오히려 '대화의 도구'로 활용해야 합니다. 만약 긴급 장애로 WIP 제한을 초과해야 하는 상황이 생겼다면, 그것 자체가 문제는 아닙니다. 그보다는 "왜 이런 긴급 상황이 발생했을까? 어떻게 하면 다음에는 이런 예외를 줄일 수 있을까?"를 팀이 함께 논의하는 것이 핵심입니다. 이것이 바로 개선의 과정입니다. WIP 제한은 단순히 일의 양을 제한하는 도구가 아니라, 팀이 함께 성장하는 학습의 도구입니다.
어디서부터 시작해야 할까: 업무 분할의 기술
WIP 제한이 '동시에 얼마나 많은 일을 할까'의 문제였다면, 업무 분할은 '각각의 일을 어떻게 정의할까'의 문제입니다. 당신이 신입 기획자로서 첫 프로젝트를 맡았다고 상상해봅시다. 팀장이 말합니다. "우리 서비스의 고객 이탈률이 너무 높아. 이번 분기에 50% 개선해줘." 당신은 의욕이 넘칩니다. 하지만 책상 앞에 앉자마자 막막합니다. "50% 개선... 그래서 내가 지금 당장 뭘 해야 하지?"
이것이 바로 많은 신입사원이 겪는 첫 번째 벽입니다. "고객 이탈률 50% 개선"은 분명 중요한 목표입니다. 하지만 그것은 우리가 나아갈 방향을 알려주는 '북극성'일 뿐, 당장 무엇을 해야 할지 알려주는 '지도'가 아닙니다. 이 거대하고 추상적인 목표를 지금 당장 실행 가능한 작은 행동으로 바꾸는 기술, 그것이 업무 분할입니다.
왜 이것이 중요할까요? 학습의 속도가 곧 성공의 속도이기 때문입니다. 구체적인 예를 들어보겠습니다. 당신이 "고객 이탈률 개선"이라는 거대한 프로젝트를 6개월짜리 계획으로 시작했다고 해봅시다. UI를 전면 개편하고, 신규 기능 10개를 추가하고, 온보딩 프로세스를 완전히 바꾸는 큰 그림입니다. 6개월 후 출시하고 측정해보니... 이탈률이 오히려 증가했습니다. 당신은 6개월이라는 시간과 팀의 모든 자원을 잃었습니다. 더 나쁜 것은 "왜 실패했는지" 알 수가 없다는 점입니다. UI 때문인가? 신규 기능 때문인가? 온보딩 때문인가? 전부 섞여 있어서 무엇이 문제였는지 알 수 없습니다.
이제 다른 접근을 상상해봅시다. 같은 목표지만 이번에는 작게 쪼갭니다. "회원가입 후 첫 3일 이내에 이탈하는 신규 고객이 많다는 데이터가 있어. 어쩌면 온보딩이 복잡해서 그런 게 아닐까? 가설: 온보딩 스텝을 5단계에서 3단계로 줄이면, 첫 3일 이탈률이 10% 감소할 것이다." 이 가설을 검증하는 데 3일이 걸립니다. 출시하고 일주일 후 측정해보니 이탈률이 예상대로 10% 줄었습니다. 당신은 10일 만에 확실한 교훈을 얻었습니다. "온보딩을 단순화하면 신규 고객이 더 오래 남는구나." 이제 다음 가설로 넘어갑니다. "첫 구매까지의 시간을 줄이면 어떨까?" 또 3일 실험합니다. 이렇게 한 달에 여러 번 배우고 개선하는 팀과, 6개월 동안 한 번만 배우는 팀 중 누가 더 빠르게 목표에 도달할까요?
이것이 업무 분할의 핵심 가치입니다. 작게 쪼개면 빠르게 배우고, 빠르게 배우면 빠르게 성공합니다. 그렇다면 구체적으로 어떻게 쪼개야 할까요? 보통 세 단계의 위계로 나눕니다.
맨 위에는 Epic(가설)이 있습니다. 이것은 "만약 우리가 A라는 가치를 제공한다면, B 고객 그룹이 C라는 행동을 하여, D라는 비즈니스 성과를 만들 것이다"라는 형태의 큰 가설입니다. 예를 들어봅시다. "만약 우리가 간편 결제를 도입한다면(A), 구매를 망설이던 신규 고객들이(B) 복잡한 카드 정보 입력 없이 쉽게 첫 구매를 완료하여(C), 신규 고객의 구매 전환율이 5% 향상될 것이다(D)." 이것이 Epic입니다. 왜 이 일을 하는지, 누구를 위한 것인지, 무엇을 기대하는지가 명확합니다.
하지만 Epic은 여전히 너무 큽니다. 이것을 어떻게 실행할까요? 여기서 Story(가치 단위)로 쪼갭니다. Story는 사용자가 직접 경험할 수 있는 최소한의 가치 단위입니다. "신규 사용자는 복잡한 카드 정보 입력 화면 대신, 익숙한 소셜 로그인 버튼(카카오, 네이버)을 클릭 한 번으로 결제를 완료할 수 있다." 이것이 하나의 Story입니다. 사용자 입장에서 "아, 이게 편해졌네!"라고 직접 느낄 수 있는 변화입니다.
좋은 Story는 INVEST 원칙을 따릅니다. Independent(독립적), Negotiable(협상 가능), Valuable(가치 있음), Estimable(추정 가능), Small(작음), Testable(테스트 가능). 실제로 이 원칙을 적용해봅시다. "카카오 로그인으로 결제하기" Story는 "네이버 로그인" Story와 독립적으로 개발하고 출시할 수 있습니다(Independent).
구현 방법은 개발자와 협의하여 조정할 수 있습니다(Negotiable). 사용자에게 명확한 가치가 있습니다(Valuable). 개발 시간을 대략 추정할 수 있습니다(Estimable). 2~3일 안에 완료할 수 있을 만큼 작습니다(Small). 실제로 로그인이 작동하는지 테스트할 수 있습니다(Testable).
마지막으로, 이 Story를 실제로 만들기 위한 구체적인 Task(실행 단위)로 분해합니다. "카카오페이 결제 모듈 API 연동", "결제 완료 페이지 UI 디자인", "결제 실패 시 에러 처리 로직 구현" 같은 것들입니다. Task는 개발자나 디자이너가 받자마자 "아, 이걸 하면 되겠구나"라고 바로 실행에 옮길 수 있을 정도로 구체적이어야 합니다.
실제 팀 상황에서 이것이 어떻게 작동하는지 예를 들어보겠습니다. 월요일 아침 스프린트 계획 미팅입니다. 팀장이 Epic을 공유합니다. "이번 분기 목표는 간편 결제 도입으로 신규 고객 전환율 5% 향상입니다." 팀원들이 함께 Story를 만듭니다.
"첫 번째 Story: 카카오 로그인 결제",
"두 번째 Story: 네이버 로그인 결제",
"세 번째 Story: 게스트 결제 간소화".
각 Story를 보며 개발자는 묻습니다. "카카오 로그인 결제에 2~3일 정도 걸릴 것 같은데, 이번 주에 할 수 있을까요?" 팀장은 답합니다. "좋아요, 그럼 이번 주는 카카오 로그인 하나에만 집중합시다. 완료되면 금요일에 실제 사용자 몇 명에게 테스트해보고, 다음 주에 네이버로 넘어갑시다."
이 과정에서 개발자는 Task를 직접 쪼갭니다. "카카오 API 연동 - 1일", "UI 컴포넌트 개발 - 0.5일", "에러 처리 - 0.5일", "테스트 코드 작성 - 0.5일", "문서 작성 - 0.5일". 이렇게 쪼개고 나니 전체 그림이 보입니다. 월요일에 API 연동 시작, 화요일 오전에 완료, 화요일 오후 UI 개발, 수요일 에러 처리와 테스트, 목요일 QA 및 문서 작성. 금요일에 출시.
여기서 핵심은 '3일 법칙'입니다. 만약 하나의 Task가 3일 이상 걸릴 것으로 예상된다면, 그것은 아직 우리가 그 일을 충분히 이해하지 못했다는 강력한 신호입니다. "API 연동"이라는 Task를 받았는데 막막하다면, 다시 쪼개야 합니다. "API 문서 읽고 이해하기 - 2시간", "개발 환경에 테스트 키 설정 - 1시간", "샘플 코드로 연동 테스트 - 2시간", "실제 결제 플로우 구현 - 4시간". 이렇게 쪼개고 나면 "아, 첫 번째로 API 문서부터 읽어야겠구나"라는 명확한 첫걸음이 보입니다.
이렇게 업무를 잘게 나누는 행위는 단순히 일정 관리를 편하게 만드는 것을 넘어, 세 가지 심리적 효과를 만듭니다.
첫째, 불확실성을 줄입니다. "고객 이탈률 50% 개선"은 막연하지만, "카카오 로그인 버튼 만들기"는 구체적입니다. 무엇을 해야 할지 명확합니다. 둘째, 심리적 안정감을 줍니다. 6개월짜리 거대 프로젝트는 압도적이지만, 2~3일짜리 작은 Task는 "이 정도는 할 수 있어"라는 자신감을 줍니다. 셋째, 지속적인 동력을 만듭니다. 한 달에 한 번 성취하는 것과 일주일에 세 번 성취하는 것, 어느 쪽이 더 동기부여가 될까요? 작은 성공을 자주 경험하는 팀은 에너지가 넘칩니다.
신입사원인 당신이 내일 당장 실천할 수 있는 것은 이것입니다. 팀장이 큰 일을 던져주면, "네, 알겠습니다" 하고 받기만 하지 마세요. 대신 이렇게 물어보세요. "이 일을 더 작게 쪼개서, 이번 주에 하나라도 고객에게 전달할 수 있는 게 있을까요?" 이 질문 하나가 당신을 "시키는 일만 하는 신입"에서 "흐름을 만드는 팀원"으로 바꿔줄 것입니다.
두 원칙이 만나는 지점: 예측 가능한 성공
WIP 제한과 업무 분할은 따로 작동하는 독립적인 기법이 아닙니다. 이 둘은 서로를 강력하게 지지하며 시너지를 만듭니다. WIP 제한은 잘게 쪼개진 업무가 막힘없이 흐를 수 있는 환경을 만들어주고, 잘게 쪼개진 업무는 WIP 제한을 실천 가능하게 만듭니다.
구체적으로 상상해봅시다. 당신의 팀이 WIP 제한은 도입했지만 업무는 여전히 크게 정의되어 있다면 어떨까요? "간편 결제 기능 개발"이라는 2주짜리 큰 Task를 'In Progress'에 올려놓았습니다. 이 Task 하나가 WIP 슬롯 하나를 2주 동안 꽉 채웁니다.
다른 팀원들은 이 일이 어떻게 진행되는지 알 수 없습니다. "어, 아직도 진행 중이네?" 2주 후에야 "완료"로 넘어가거나, 더 나쁘게는 "더 필요한 작업이 있어서 1주 더 걸릴 것 같아요"라는 말이 나옵니다. WIP 제한은 있지만 흐름은 막혀있습니다.
이제 반대로, 업무는 잘게 쪼갰지만 WIP 제한이 없다면 어떨까요? "카카오 API 연동", "네이버 API 연동", "UI 개발", "에러 처리", "문서 작성" 다섯 개의 작은 Task가 있습니다. 하지만 WIP 제한이 없으니 개발자는 다섯 개를 동시에 시작합니다. 월요일에 카카오 API를 조금 하다가, 화요일에는 UI가 궁금해서 조금 만져보고, 수요일에는 네이버 API를 시도합니다. 금요일이 되어도 다섯 개 모두 '진행 중'이고 하나도 완료되지 않습니다. 업무는 작지만 흐름은 없습니다.
하지만 두 원칙을 함께 사용하면 마법이 일어납니다. 업무는 작게 쪼개져 있고(각 Task는 2~3일), WIP 제한이 있습니다(동시에 2개까지). 월요일에 "카카오 API 연동"과 "UI 개발" 두 개를 시작합니다. 화요일 오후, 카카오 API가 완료됩니다. Done으로 이동합니다.
이제 WIP에 빈자리가 생겼으니 "에러 처리"를 시작할 수 있습니다. 수요일, UI 개발도 완료됩니다. "네이버 API 연동"을 시작합니다. 이런 식으로 일이 물 흐르듯 진행됩니다. 매일 무언가가 완료되고, 팀 전체가 진행 상황을 명확히 볼 수 있으며, 예상치 못한 문제가 생기면 즉시 드러나 해결됩니다.
실제 팀에서 이런 변화를 경험한 사례를 들려드리겠습니다. 한 스타트업의 개발팀이 있었습니다. 항상 바빴지만 출시는 늦었고, 팀원들은 지쳐 있었습니다. 그들은 WIP 제한과 업무 분할을 도입하기로 했습니다. 처음 한 달은 혼란스러웠습니다. "일을 이렇게 작게 쪼개야 해?", "WIP가 꽉 차서 새로운 일을 못 시작하는데 그냥 기다려야 해?"
하지만 두 달째부터 변화가 보이기 시작했습니다. 스탠드업 미팅에서 "진행 중"이라는 말이 줄고 "완료했습니다"라는 말이 늘었습니다. 석 달째, 팀의 배포 빈도가 월 1회에서 주 2회로 증가했습니다. 여섯 달 후, 팀장은 이렇게 말했습니다. "예전에는 다음 주에 뭐가 나올지 몰랐어요. 지금은 오늘 오후에 뭐가 나올지 알아요."
이것이 바로 예측 가능한 성공입니다. WIP 제한은 문맥 전환의 낭비를 없애고 숨겨진 문제를 즉시 드러내며, 업무 분할은 학습 속도를 높여 불확실성을 제거합니다. 두 원칙이 만나는 지점에서, 우리는 더 이상 "언제쯤 끝날까?"를 걱정하는 대신, "오늘은 무엇을 완료할까?"에 집중할 수 있게 됩니다.
신입사원인 당신에게 이 글이 전하고 싶은 메시지는 명확합니다. 일을 잘한다는 것은 더 많은 일을 시작하는 것이 아니라, 시작한 일을 확실하게 완료하는 것입니다. 일을 잘한다는 것은 큰 일에 압도되는 것이 아니라, 큰 일을 작은 승리의 연속으로 바꾸는 것입니다.
내일 출근하면 당신의 보드를 보세요. 'In Progress'에 몇 개의 일이 있나요? 그 일들은 언제 완료될까요? 만약 대답하기 어렵다면, 지금이 바로 WIP 제한과 업무 분할을 시작할 때입니다. 이 두 원칙을 중심으로 당신은 예측 가능하고 지속 가능한 성공의 흐름을 설계할 수 있습니다.
