본문으로 건너뛰기

버그 제보

이상한 점을 알려 주시면 고칠게요. 지금 보고 있는 페이지와 브라우저 정보가 함께 담겨요.

페이지:

Career

칸반과 린: 흐름과 낭비

작성 2026. 10. 15.추가
목차10개 항목
출처와 참고

Asana의 「애자일 프로젝트 관리 리소스」 아티클들을 바탕으로 재구성한 노트다.

린과 칸반의 관계

린(Lean)은 "고객에게 가치 있는 것만 남기고 나머지는 낭비로 보고 없앤다"는 사고방식이다. 도요타 생산 방식(TPS, 1948~1975년 무렵 정립)에서 나왔고, 1988년 존 크래프칙(John Krafcik)이 "린 생산"이라는 이름을 붙였고, 『세상을 바꾼 기계(The Machine That Changed the World)』(1990)로 퍼졌다.

칸반(Kanban)은 원래 TPS에서 오노 다이이치가 쓴 "필요할 때 필요한 만큼 당겨 오라"는 신호 카드다. 소프트웨어에서는 이 원리를 지식 노동에 옮긴 칸반 방법(Kanban Method)을 뜻하고, 칸반 보드는 그 도구다. 보드에 할 일·진행 중·완료 열이 있다고 칸반인 것은 아니다. WIP 제한으로 당기는 흐름을 만들어야 칸반이다.

린애자일
뿌리도요타 제조소프트웨어 개발
초점낭비 제거, 흐름 효율변화 대응, 짧은 반복
재는 것리드 타임, 흐름 효율동작하는 증분, 피드백 주기

둘은 대립하지 않는다. 대부분의 팀이 애자일로 방향을 맞추고 린으로 낭비를 줄인다.

칸반의 핵심 실천

실천하는 일
시각화일의 단계를 열로, 항목을 카드로 보인다. 막힌 카드와 오래된 카드가 한눈에 보이게 한다
WIP 제한열마다 동시에 둘 수 있는 카드 수를 정한다. 자리가 나야 앞 단계에서 당겨 온다(풀 방식)
흐름 관리사람이 바쁜지가 아니라 일이 멈춰 있는지를 본다
정책 명시"리뷰 열로 옮기는 조건" 같은 규칙을 보드에 적어 둔다
피드백 주기정기적으로 보드와 지표를 보고 개선한다

"시작은 멈추고, 끝내기를 시작하라(Stop starting, start finishing)." WIP를 제한하지 않으면 모두 바쁜데 아무것도 끝나지 않는다. 일을 동시에 많이 쥘수록 작업 전환 비용이 늘고, 끝나는 시점은 모두 뒤로 밀린다.

흐름 지표

지표뜻
리드 타임(lead time)요청이 들어온 때부터 전달될 때까지
사이클 타임(cycle time)실제로 작업을 시작한 때부터 끝날 때까지
처리량(throughput)단위 시간당 끝낸 항목 수
WIP지금 진행 중인 항목 수
누적 흐름도(CFD)단계별 항목 수를 시간에 따라 쌓은 그래프. 한 띠가 계속 두꺼워지면 그 단계가 병목이다

세 지표는 리틀의 법칙(Little's Law)으로 묶인다.

평균 사이클 타임 = 평균 WIP ÷ 평균 처리량

처리량이 그대로라면 WIP를 절반으로 줄이는 것만으로 평균 사이클 타임이 절반이 된다. 사람을 더 넣는 것보다 동시에 하는 일을 줄이는 쪽이 대개 싸고 빠르다.

칸반 · 스크럼 · 스크럼반

스크럼칸반스크럼반(Scrumban)
리듬고정 길이 스프린트연속 흐름흐름 + 정기 계획·회고
역할PO·스크럼 마스터·개발자강제하지 않음팀이 정함
일 담는 단위스프린트 목표와 스프린트 백로그WIP 제한WIP 제한, 백로그가 일정 수 아래로 줄면 계획
변경스프린트 중엔 목표를 지킴언제든 순서 변경다음 당김 때 반영
대표 지표속도, 번다운사이클 타임, 처리량, CFD사이클 타임
잘 맞는 일새 제품·기능 개발, 정기 데모가 의미 있는 일운영·유지보수, 지원 요청, 끝없이 이어지는 일장기 유지보수, 스크럼이 경직된 팀
  • 칸반 보드에서 스프린트를 돌리면 그것은 칸반이 아니라 보드를 쓰는 스크럼이다.
  • 스크럼반은 원래 스크럼 팀이 칸반으로 옮겨 가는 과정을 돕는 방식으로 제안됐고(코리 라더스, 2008), 지금은 그 자체로도 쓴다. 정해진 표준이 적어 팀마다 모양이 크게 다르고, 역할이 흐릿하면 우선순위를 정할 사람이 없어지는 것이 약점이다.
  • 스크럼 자체의 구성은 스크럼: 책임·이벤트·산출물에 있다.

낭비

린은 낭비를 세 가지로 나눈다.

낭비뜻일에서의 모습
무다(Muda)가치를 더하지 않는 활동아래 표의 여덟 가지
무라(Mura)불균형, 들쭉날쭉함마감 직전에만 몰리는 리뷰, 스프린트 마지막 날 몰아치기
무리(Muri)능력을 넘는 과부하야근 상시화, 한 사람에게 몰린 이슈. 결국 번아웃과 결함으로 돌아온다

무다 가운데에도 고객 가치는 없지만 꼭 필요한 일(보안 점검, 법적 기록)은 줄이고, 필요 없는 일은 없앤다.

제조의 낭비소프트웨어에서
재고반쯤 한 일, 머지 안 된 브랜치, 쌓이기만 하는 백로그
과잉 생산아무도 요청하지 않은 기능, 읽히지 않는 문서
과잉 처리필요 이상의 설계, 쓸 일 없는 일반화
운반사람과 팀 사이의 인계(handoff), 정보 옮겨 적기
동작작업 전환, 도구 사이를 오가기, 겹치는 회의
대기리뷰·승인·다른 팀 응답 기다리기
결함버그, 재작업, 기술 부채
활용되지 않는 재능아이디어를 낼 권한이 없는 팀원

린의 다섯 원칙

  1. 가치 정의: 고객 입장에서 무엇이 가치인지 정한다.
  2. 가치 흐름 매핑: 요청부터 전달까지 모든 단계를 그린다.
  3. 흐름 만들기: 낭비를 걷어 내 일이 멈추지 않게 한다.
  4. 당기기(pull): 뒤 단계가 준비됐을 때만 앞 단계에서 가져온다.
  5. 완벽 추구: 이 과정을 계속 반복한다.

가치 흐름 매핑

가치 흐름 매핑(Value Stream Mapping, VSM)은 요청이 들어와서 고객에게 가치가 전달되기까지의 단계를 그려 어디서 기다리는지를 찾는 방법이다.

flowchart LR
  n1["현재 상태 그리기"] --> n2["단계마다 작업 시간과<br/>대기 시간 적기"]
  n2 --> n3["낭비 찾기"]
  n3 --> n4["미래 상태 그리기"]
  n4 --> n5["적용"]
  n5 -->|"다시"| n1

핵심 숫자는 흐름 효율 = 실제 작업 시간 ÷ 전체 리드 타임이다. 지식 노동에서는 이 값이 낮은 경우가 흔하다. 일이 대부분의 시간을 누군가의 손이 아니라 대기열에서 보낸다는 뜻이다. 그래서 사람을 더 빠르게 일하게 하는 것보다 대기를 줄이는 쪽이 효과가 크다. 문제가 일·정보·시간의 흐름과 관련 없다면 VSM은 맞는 도구가 아니다.

병목과 제약 이론

병목(bottleneck)은 처리 능력이 가장 낮아 전체 흐름을 늦추는 지점이다. 제약 이론(Theory of Constraints, 엘리야후 골드랫 『더 골』)에 따르면 시스템의 처리량은 병목의 처리량을 넘지 못한다. 병목이 아닌 곳을 빠르게 해 봐야 병목 앞에 재고만 쌓인다.

단계하는 일예: 리뷰어 한 명이 병목일 때
1. 찾기일이 쌓이는 곳을 찾는다 (CFD, 대기 시간)리뷰 대기 열이 계속 길어진다
2. 최대한 활용병목이 놀지 않게 한다리뷰어의 다른 일을 덜어 준다
3. 나머지를 맞추기병목 속도에 맞춰 들여보내고, 들어가는 일의 질을 높인다PR을 작게, 셀프 리뷰·테스트를 마친 상태로 올린다
4. 능력 늘리기그래도 부족하면 용량을 늘린다리뷰어를 늘리고 페어 리뷰를 도입한다
5. 반복병목은 옮겨 간다. 1로 돌아간다이제 QA가 병목이 된다

병목은 사람(인력·역량·명확성 부족)일 수도 있고 시스템(느린 빌드, 낡은 도구, 수동 절차)일 수도 있다. 사람 병목은 대개 개인의 잘못이 아니라 자원이나 정보가 부족해서 생긴다. 근본 원인을 찾을 때는 피시본(이시카와) 다이어그램이나 5 Whys를 쓴다. 품질을 깎아 병목을 통과시키지 않는다. 재작업이 되어 같은 병목으로 돌아온다.

지속적 개선: 카이젠과 PDCA

카이젠(改善)은 작은 개선을 꾸준히 쌓는다는 원칙이다. 한 번의 큰 개혁보다 위험이 적고, 현장의 개인이 바로 시작할 수 있다. 완벽을 목표로 삼으면 필요 없는 변경까지 하게 된다.

PDCA하는 일
Plan문제와 성공 기준을 정하고 가설을 세운다
Do작은 범위에서 시험한다
Check기준에 비춰 결과를 확인한다
Act효과가 있으면 표준으로 삼고, 없으면 바꿔서 다시 돈다

PDCA는 월터 슈하트(Walter Shewhart)가 제안하고 에드워즈 데밍(W. Edwards Deming)이 널리 알려 데밍 사이클이라고도 한다. 스크럼의 회고, 칸반의 정기 지표 점검이 모두 이 사이클의 한 바퀴다.

정리

  • 린은 고객 가치를 기준으로 낭비(무다·무라·무리)를 없애고, 칸반은 시각화와 WIP 제한으로 당기는 흐름을 만든다.
  • 바쁜 사람이 아니라 멈춘 일을 본다. 리틀의 법칙상 WIP를 줄이면 사이클 타임이 줄어든다.
  • 스크럼은 리듬, 칸반은 흐름이 중심이다. 일의 성격에 맞게 고르거나 섞는다.
  • 흐름을 늦추는 것은 대개 작업이 아니라 대기다. VSM으로 대기를 찾고, 병목은 제약 이론의 다섯 단계로 다룬다.
  • 개선은 작은 PDCA를 계속 돌리는 일이다.

관련 노트: 애자일과 스프린트, 스크럼: 책임·이벤트·산출물, 백로그와 추정, 기술 부채, Jira: 이슈 구성, JQL, 워크플로, GitHub 이슈·프로젝트로 진행 상황 관리하기

원본 기록7

댓글

GitHub 계정으로 댓글을 남길 수 있어요.