![A [[Kanban board](https://upload.wikimedia.org/wikipedia/commons/b/b4/Abstract_Kanban_Board.svg) ]]

칸반 | MOAI 제조 AI 백과사전(2026)

칸반 (일본어: , 간판 또는 게시판을 의미)은 인간 시스템 전반의 작업을 관리하고 개선하기 위한 린 방법론이다. 이 접근법은 수요와 가용 역량의 균형을 맞추고 시스템 수준의 병목 현상 처리를 개선함으로써 작업을 관리하는 것을 목표로 한다.

작업 항목은 시각화되어 참여자들이 처음부터 끝까지의 진행 상황과 프로세스를 볼 수 있도록 하며, 일반적으로 칸반 보드를 통해 이루어진다. 작업은 요청 시 프로세스에 밀어 넣는 방식이 아니라, 역량이 허용하는 만큼 당겨오는 방식으로 진행된다.

지식 노동과 소프트웨어 개발에서 칸반의 목표는 무엇을, 언제, 얼마나 생산할지에 대한 의사결정을 지원하는 시각적 프로세스 관리 시스템을 제공하는 것이다. 기반이 되는 칸반 방법론은 린 제조업에서 유래했으며,[^7] 이는 도요타 생산 시스템에서 영감을 받았다.[^8] 그 기원은 1940년대 후반으로, 당시 도요타 자동차 회사가 고객 수요에 맞춰 생산하고 생산 라인 내 잠재적인 자재 부족을 파악하는 것을 목표로 하는 적시생산(JIT) 시스템을 도입했다. 그러나 도요타가 고안한 이 방법론이 모든 유형의 조직 프로세스에 적용 가능한 프로세스가 될 수 있다는 것을 인식한 것은 코비스의 한 팀이었다. 칸반은 소프트웨어 개발에서 스크럼과 같은 방법론 및 프레임워크와 결합하여 일반적으로 사용된다.[^1]

칸반 보드

여기의 다이어그램은 칸반 보드에서의 소프트웨어 개발 워크플로를 보여준다.[^9]

upright=2.2

칸반 보드는 사용되는 맥락에 맞게 설계되어 상당히 다양하며, 작업 항목 유형(여기서는 "기능"과 "사용자 스토리"), 워크플로 활동을 구분하는 열, 명시적 정책, 그리고 스윔레인(여러 열을 가로지르는 행으로, 여기서는 기능별 사용자 스토리 그룹화에 사용)을 표시할 수 있다. 목표는 참여자와 이해관계자에게 전반적인 워크플로와 개별 항목의 진행 상황을 명확히 보여주는 것이다.

칸반 보드는 시스템의 워크플로 정의[^10]를 나타내며 다음과 같은 최소 요소를 필요로 한다:

워크플로를 통해 이동하는 개별 가치 단위의 정의. 이러한 가치 단위를 작업 항목 (또는 항목)이라고 한다.
워크플로 내에서 작업 항목이 시작되고 완료되는 시점에 대한 정의. 워크플로는 작업 항목에 따라 둘 이상의 시작 또는 완료 지점을 가질 수 있다.
작업 항목이 시작에서 완료까지 거치는 하나 이상의 정의된 상태. 시작 지점과 완료 지점 사이에 있는 모든 작업 항목은 진행 중 작업(WIP)으로 간주된다.
시작에서 완료까지 WIP가 어떻게 제어될 것인지에 대한 정의.
작업 항목이 시작에서 완료까지 각 상태를 어떻게 통과할 수 있는지에 대한 명시적 정책.
서비스 수준 기대치(SLE), 즉 작업 항목이 시작에서 완료까지 흐르는 데 걸리는 예상 시간.

칸반 실천법

칸반 가이드[^2]에 설명된 칸반의 실천법은 다음과 같다.

워크플로를 정의하고 시각화하기
워크플로 내 항목을 능동적으로 관리하기
워크플로를 개선하기

칸반은 효율적이고 효과적이며 예측 가능한 시스템을 만들기 위해 이러한 실천법을 순서대로 따르는 것을 목표로 하는 전략이다.

칸반 방법론(Kanban Method)은 칸반을 전문적이고 상세하게 확장한 것이다. 소프트웨어 개발을 위한 칸반 방법론에 관한 서적[^3][^1]에 설명된 바와 같이, 칸반 방법론의 두 가지 주요 실천법은 작업을 시각화하는 것과 진행 중인 작업(WIP)을 제한하는 것이다. *에센셜 칸반 콘덴스드(Essential Kanban Condensed)*에 나열된 칸반 방법론의 네 가지 추가 일반 실천법은 정책을 명시적으로 만들기, 흐름 관리하기, 피드백 루프 구현하기, 협력적으로 개선하기이다.[^6]

위 다이어그램의 칸반 보드는 칸반 방법론의 처음 세 가지 일반 실천법을 보여준다.

개발 팀의 작업(기능 및 사용자 스토리)을 시각화한다.
개발 단계별 WIP 제한을 표시한다: 열 제목 아래의 원으로 표시된 값으로, 해당 단계에서 처리할 수 있는 작업 항목 수를 제한한다.
일부 개발 단계 아래의 파란색 사각형 안에 완료 규칙[^5]이라고도 하는 정책을 문서화한다.
또한 "사용자 스토리 준비", "사용자 스토리 개발", "기능 인수" 단계에 대한 칸반 흐름 관리를 보여주는데, 이 단계들은 "진행 중"과 "준비 완료" 하위 열을 가지고 있다. 각 단계의 WIP 제한은 두 하위 열 모두에 적용되어, 해당 단계로 유입되거나 유출되는 흐름에 작업 항목이 과부하되는 것을 방지한다.

워크플로 관리

칸반은 칸반 보드에서 직접 워크플로를 관리한다. 개발 단계별 WIP 제한은 개발 팀에게 일반적인 워크플로 문제에 대한 즉각적인 피드백을 제공한다.[^3][^5]

예를 들어, 위에 표시된 칸반 보드에서 "배포" 단계의 WIP 제한은 5이며 현재 해당 단계에 5개의 에픽이 표시되어 있다. 하나 이상의 에픽이 해당 단계를 완료("전달됨"으로 이동)하기 전까지는 더 이상의 작업 항목이 배포로 이동할 수 없다. 이는 "배포" 단계에 과부하가 걸리는 것을 방지한다. "기능 인수"(이전 단계)를 작업하는 팀원들은 새로운 에픽을 배포할 수 없어 작업이 막힐 수 있다. 그들은 보드에서 그 이유를 즉시 확인하고 현재 에픽 배포를 도울 수 있다.

"배포" 단계의 5개 에픽이 전달되면, "기능 인수"(이전 단계)의 "준비 완료" 하위 열에 있는 2개의 에픽을 "배포" 열로 이동할 수 있다. 이 2개의 에픽이 전달되면, 다른 에픽은 배포할 수 없다(새로 준비된 에픽이 없다고 가정). 이제 배포를 담당하는 팀원들이 작업이 막히게 된다. 그들은 그 이유를 즉시 확인하고 기능 인수를 도울 수 있다.

칸반 보드 설정에서 스윔레인은 작업을 프로세스의 여러 단계로 시각적으로 구성하여 명확성과 집중력을 확보하는 데 사용된다. 효율적인 워크플로 관리를 위해 요구사항, 개발, 테스트, 완료/종료 작업 등 핵심 단계별로 별도의 스윔레인을 유지하는 것이 중요하다. 특히 테스트 스토리는 항상 지정된 "테스트" 스윔레인에 배치해야 한다. 이러한 분리를 통해 테스트 활동을 쉽게 추적할 수 있으며, 개발이나 다른 단계의 스토리와 뒤섞이지 않도록 한다. 테스트 작업을 자체 스윔레인 내에 유지함으로써, 팀은 병목 현상을 빠르게 식별하고, 이슈의 우선순위를 정하며, 개발이나 요구사항 단계의 오염 없이 테스트 프로세스의 무결성을 유지할 수 있다. 이러한 구조는 더 명확한 워크플로를 이끌어내고 팀 협업을 강화한다.

이러한 워크플로 제어는 모든 단계에서 유사하게 작동한다. 문제가 시각적으로 즉시 드러나며, 재계획을 지속적으로 수행할 수 있다. 이러한 작업 관리는 팀원들이 항상 확인하고 추적할 수 있는 방식으로 진행 중인 작업을 제한함으로써 가능해진다.

방법의 발전과 문서화

데이비드 앤더슨의 2010년 저서 Kanban[^3]은 2004년 마이크로소프트에서의 프로젝트[^11]에서 제약 이론 접근법을 사용하고 드럼-버퍼-로프(칸반 풀 시스템에 비견되는)를 도입한 것으로부터, 2006~2007년 코비스(빌 게이츠가 설립한 별도의 회사)에서의 프로젝트에서 칸반 방법이 확립되기까지의 발전 과정을 서술하고 있다. 2009년, 돈 라이너슨은 2세대 린 제품 개발에 관한 책[^12]을 출간하였으며, 이 책에서는 칸반 시스템의 도입과 경영 의사결정을 위한 데이터 수집 및 경제 모델의 활용을 설명하고 있다. 또 다른 초기 기여는 코리 라다스로부터 비롯되었는데, 그의 2008년 저서 Scrumban[^1]은 칸반이 소프트웨어 개발을 위한 스크럼을 개선할 수 있다고 제안하였다. 라다스는 스크럼반을 스크럼에서 칸반으로의 전환으로 보았다. 짐 벤슨과 토니앤 데마리아 배리는 2011년에 칸반을 개인과 소규모 팀에 적용한 Personal Kanban[^4]을 출간하였다. Kanban from the Inside (2014)[^13]에서 마이크 버로우스는 칸반의 원칙, 실천법 및 기저 가치를 설명하고 이를 이전의 이론 및 모델과 연관지었다. Agile Project Management with Kanban (2015)[^5]에서 에릭 브레크너는 마이크로소프트와 Xbox에서의 칸반 실무 활용에 대한 개요를 제공하였다. 클라우스 레오폴드와 지크프리트 칼테네커의 Kanban Change Leadership (2015)[^14]는 변화 관리의 관점에서 이 방법을 설명하고 변화 추진에 대한 지침을 제공하였다. 2016년 린 칸반 유니버시티 프레스는 초기 칸반 프로젝트의 개선 사항과 확장을 반영한 축약 안내서를 출간하였다.[^6]

2020년 존 콜먼과 다니엘 바칸티는 칸반 시스템을 운영하기 위해 필요한 최소 조건을 설명하는 The Kanban Guide[^2]를 출간하였다. 콜린 존슨, 다니엘 바칸티, 프라틱 싱은 2022년에 실무자들이 칸반 실천법을 탐색하는 데 도움을 주는 The Kanban Pocket Guide[^15]를 출간하였다. 윌 셀레와 다니엘 바칸티 역시 2022년에 칸반에서 일반적으로 사용되는 지표의 이점을 스크럼 팀에 가져오기 위해 Flow Metrics for Scrum Teams[^16]를 출간하였다.