칸반에는 칸반이 없다?!

얼마 전에 트위터에서 우연히 이런 트윗을 보았다.

애자일에서 말하는 칸반 보드는 역전 앞 같은 말이 아닌가… (…

워낙 자주 듣던 이야기이다. 사람들은 소프트웨어 개발 진행 상황을 시각화한 보드를 가리켜 흔히 ‘칸반’이라고 말한다. 나도 급할 때는 무의식 중에 보드를 가리켜 ‘칸반’이라고 이야기하기도 하는데, 그렇게 해도 의사 소통에 별로 문제가 없기 때문이다. “칸반 == 보드”라는 오해는 그 만큼 널리 퍼져있고 뿌리 깊게 자리잡고 있어 벗어나기 쉽지 않다.

곰곰이 생각해보았는데, 그 원인은 크게 두 가지로 볼 수 있을 것 같다.

  • 데이비드 J. 앤더슨이 도요타 생산 시스템TPS, Toyota Production System제약 이론TOC, Theory Of Constraints당김 방식pulling system에서 영감을 얻어 새로운 소프트웨어 개발 방법을 만들면서 거기에 ‘칸반’이라는 이름을 붙였는데, 이는 일종의 메타포로써 사람들에게 쉽게 다가가기 위한 전략이었다고 할 수 있다. 마케팅 측면에서는 성공적이었지만, 그 이름이 지금에 와서는 오히려 사람들에게 혼란을 주고 있다.
  • 칸반에서는 보드가 매우 중요한 역할을 수행한다. 그러나 워낙 시각적인 측면이 강렬하기 때문에 보드 이외의 다른 중요한 요소들을 보기가 쉽지 않다. 낮에는 태양의 밝기 때문에 달과 별이 보이지 않는 것과 마찬가지라고나 할까.

kanban-chinese

많은 사람들이 알고 있는 것처럼 칸반Kanban‘은 看板간판을 일본식으로 발음한 것이다. 간판의 사전적 의미는 ‘기관, 상점, 영업소 따위에서 이름이나 판매 상품, 업종 따위를 써서 사람들의 눈에 잘 뜨이게 걸거나 붙이는 표지’이지만 여기에서는 그런 의미가 아니다. 칸반이라는 단어에는 (연관성은 있으나) 서로 다른 세 가지 정의가 있다.

 

1. 도요타 생산 시스템에서의 칸반

kanbancardfromliker

위는 도요타에서 실제로 사용하던 칸반의 모습인데, 생산 도중 추가로 부품이 필요할 때 이 카드를 작성하여 프로세스의 전 단계로 보내면, 카드를 받은 곳에서는 카드를 보내온 곳에서 필요한 부품을 생산한다. 즉, 도요타 생산 시스템(린 제조 프로세스)에서 프로세스 전 단계로 보내는 물리적 주문서가 칸반의 첫 번째 정의다.

 

2. 당김 방식의 신호로써의 칸반

도요타에서 이런 방식으로 생산 프로세스를 운영했던 가장 큰 목적은 적시 생산JIT, Just-In-Time을 위해서다. 프로세스의 전 단계에서 미리 예측한 양만큼 생산한 부품을 다음 단계로 밀어내는push 것보다, 프로세스 이전 단계에서 필요한 부품을 당겨와pull 생산하면 필요한 때에 필요한 만큼만 제품을 생산해낼 수 있고 그 재고량은 최소화할 수 있다. 여기에서 칸반은 작업 시작을 알려주는 역할을 한다. 즉, 당김 방식에서 사용하는 새로운 작업을 시작할 수 있다는 신호가 칸반의 두 번째 정의다.

그렇다면 소프트웨어 개발의 칸반에서는 무엇이 ‘새로운 작업을 시작할 수 있다는 신호’의 역할을 할까? 바로 진행 중 업무(WIP)의 양을 제한한 값에서 현재 진행 중인 업무 항목 수를 뺀 값이 0보다 크다면 그것이 바로 새로운 작업 시작의 신호가 된다. 이것을 논리적으로 표현하면 다음과 같다.

if ( 0 < ('WIP Limit' - 'WIP') ) {
    pull();
}

도요타 생산 시스템에서의 칸반과 비교해보았을 때 가장 두드러지는 차이점은 바로 물리적 실체가 없다는 점이다. 그래서 소프트웨어 개발에서 이야기하는 칸반을 가상 칸반 시스템virtual kanban system이라고 말한다.

 

3. 소프트웨어 개발 방법으로써의 칸반

칸반의 마지막 정의는 데이비드 J. 앤더슨이 만든 소프트웨어 개발 방법으로써의 칸반이다. 이런 혼란을 막기 위해서인지는 모르겠으나, 요즘 해외 커뮤니티에서는 소프트웨어 개발 방법인 칸반을 Kanban Method라고 부른다. 모두 여섯 가지 핵심 요소가 모두 포함되어 있어야 칸반 메소드라고 할 수 있다. 시각화만이 전부가 아니다.

  • 시각화한다.
  • 진행 중 업무(WIP)를 제한한다.
  • 흐름을 관리한다.
  • 정책을 명시화한다.
  • 피드백 루프를 실행한다.
  • 함께 개선하고 실험을 통해 발전시킨다.

요약하자면, 원래 칸반은 ‘도요타 생산 시스템에서 프로세스 이전 단계에서 새로운 업무를 당겨오는 신호 역할을 하는 카드’라고 할 수 있다. 우리는 이 단어를 소프트웨어 분야의 개발 방법 중 하나인 칸반의 이름으로 사용하고 있는 것이다. 따라서, 따라서 칸반 메소드에서는 보드를 칸반이라고 볼 수 없으며, 포스트잇을 칸반이라고 할 수도 없다. 칸반(소프트웨어 개발에서의 칸반 메소드)에는 칸반(즉, 당김 신호 역할을 하는 카드)이 없다.

물론 보드를 가리켜 칸반이라고 불러도 의사 소통이 안되는 것은 아니며, 무슨 큰 일이 나는 것은 더더욱 아니다. 하지만 칸반을 단순히 업무 시각화 방식으로 인식하는 오해가 여기에서 비롯된 것이라 생각하면 가볍게 생각할만한 것은 아니라고 생각한다.

다시 한 번 더 강조하지만, 칸반에는 칸반이 없다.

 

데이비드 J. 앤더슨과의 인터뷰 2탄

원문: InfoQ Interviews David J. Anderson at Lean Kanban 2013 Conference

by Victor Grazi on May 8, 2013

실리콘 밸리 근처에 있는 산을 러시모어 산1처럼 조각한다면, 거기에는 데이크스트라(Edsger W. Dijkstra)2, 커니핸(Brian Kernighan)3, 쓰리 아미고(the Three Amigos)4, 갱 오브 포(GoF, The Gang of Four)5와 함께, 소프트웨어 개발 분야 칸반의 아버지인 데이비드 J. 앤더슨의 자리를 만들어두어야 할 것이다. 지난주 시카고 중심가에서 열렸던 린 칸반 노스 아메리카 콘퍼런스에서 InfoQ는 David J. Anderson and Associates의 행사를 진행하던 앤더슨과 만나 인터뷰를 진행했다.
 

InfoQ: 최근 우연히 스크럼을 사용해서 소프트웨어 개발 프로젝트를 이끌던 동료를 만난 일이 있었습니다. 그 친구가 요즘에는 칸반을 사용하고 있다고 말하기에 저는 깜짝 놀랐습니다. 프로세스를 어떻게 바꾸었냐고 물어보았더니, 사실은 스크럼과 칸반의 차이점을 잘 모르겠다고 이야기하더군요. 칸반을 전혀 이해하지 못하고 있는 것이 분명했습니다. 이 에피소드를 보면 모두가 애자일을 하고 있다고 주장하던 애자일의 초창기 시절이 떠오릅니다. 저는 이 이야기가 어떤 징후를 보여주고 있다고 생각하는데요, 칸반에 대해 참고할만한 자료가 부족한 듯 합니다. 당신이 쓴 책은 상당히 중요하고 의미가 있지만, 그 양이 300 페이지가 넘습니다. 스크럼을 간단히 설명하고 싶은 경우, 스크럼에는 시간을 정해놓은 반복 주기가 있고, 시작할 때에는 “스프린트”를 계획하는 회의를 진행하며, 끝날 때에는 회고를 진행하고, 속도를 측정하며, 일일 스크럼으로 프로젝트의 상태와 장애물을 점검한다고 이야기할 수 있습니다. 이와 비슷하게 칸반을 한 마디로 쉽게 설명해주실 수 있는지 궁금합니다.

데이비드: 우리도 그 지점에서 무언가 빠진 부분이 있다는 것을 알고 있습니다. 예전에 8 페이지 짜리 안내서를 만들었던 적이 있었는데, 당시에는 쓸만한 내용을 담고 있었지만 다시 만들어야 하는 상황입니다.
몇몇 얇은 책자도 이미 오래 전인 2008년에 만든 것이어서, 우리는 그것을 다시 사용하는 것이 별로 좋은 생각이 아니고, 칸반을 제대로 설명하지도 못하고 있다고 판단했습니다. 사람들이 한 시간 이내에 읽을 수 있는 자료가 꼭 필요합니다.
린 칸반 유니버시티(Lean Kanban University)를 통해 “칸반 공식 가이드”를 발행할 예정입니다.

 

InfoQ: “공식 가이드”를 언제쯤 볼 수 있을까요?

데이비드: 음, 이미 나왔어요 했죠. 올해 내 발표를 목표로 하고 있습니다. 저는 이미 『칸반』 2판을 쓰기 시작했는데, 올 가을 초쯤 출간할 수 있으리라 기대하고 있습니다. 초판을 출간한 이후 몇 년 동안 많은 것들을 새롭게 배웠습니다. 칸반을 가르치면서 배운 것도 많고요. 『칸반』 2판을 다 쓰고 나면, 그 내용을 토대로 “공식 가이드”를 정리할 생각입니다.6

 

InfoQ: 지금 바로 칸반을 사용해서 프로젝트를 시작하고 싶다면 어떻게 해야 할까요? 어떻게 시작해야 하고, 지금 하고 있는 일은 어떻게 분석해야 할까요? 그리고 관리자를 어떻게 설득할 수 있을까요?

데이비드: 작년 보스턴 린 콘퍼런스에서 제가 발표했던 것처럼, 거기에 사용할 수 있는 지침이 있습니다. 사람들에게 칸반을 가르칠 때 다음과 같은 질문으로 시작합니다. “고객과 외부 이해 관계자가 무엇을 불만스러워하는가? 다시 말해서, 내부 팀은 무엇을 불만스러워하며, 해결하고자 하는 문제는 무엇이고, 사람들은 왜 행복해하지 못할까?” 우리는 이 질문을 통해 그 원인이 무엇인지 생각해봅니다.
그런 다음 업무가 어디에서부터 오는지 찾아보라고 이야기합니다. 애자일에서는 “업무는 제품 책임자(product owner)에게서 온다.”와 같은 이야기를 많이 듣게됩니다. 업무는 제품 책임자에게서 오는 것이 아닙니다! 제품 책임자는 중개인이죠. 그래서 요구가 어디에서 발생하는지 찾아보는 것은 매우 중요한 일입니다. 요구는 영업 부서나 마케팅 부서에서 올 수도 있고, 정부 계획 당국이나 규제 기관 아니면 특정 고객이나 특정 시장으로부터 올 수도 있습니다. 그렇기 때문에 우리는 요구가 어디에서부터 오는지 이해할 수 있도록 도움을 주고 있습니다.
목표 대상을 찾아보라고 이야기하기도 합니다. 어떤 모바일 앱 회사의 제품이 아이폰 버전, 안드로이드 버전, 심비안 버전을 지원한다고 예를 들어 봅시다. 심비안 버전은 조건이 바뀌어서 무언가를 바꿔야하는 경우가 거의 없겠지만, 이 회사의 앱을 더 이상 사용할 수 없는 심비안 폰으로 은행 업무를 처리하고자 하는 고객들이 생겨날겁니다. 반대로 아이폰 버전은 모든 최신 기능을 갖추고 있겠죠. 그렇기 때문에 우리는 위험 요소를 찾아내고 서비스 만족도를 대표하는 것이 무엇인지 이해할 수 있도록 돕고 있습니다. 그것이 요구 분석 활동입니다. 다시 말해서, 우리는 처음에 고객과 직원의 목소리를 이해한 후 그 다음에 요구 분석으로 옮겨갑니다.
그 다음에는 현재 역량 수준을 알아내기 위해, 기존의 추적 시스템을 살펴보고 리드 타임과 출시율의 이력 데이터를 기반으로 수용량을 분석합니다. 이력 데이터가 전혀 없는 사람들도 있긴 하지만 그 비율이 점점 줄어들고 있습니다. 사람들은 보통 지라(JIRA) 같은 추적 시스템을 사용합니다. 추적 시스템을 사용하면 현재 수용량을 알 수 있고, 그렇다면 (요구 분석을 통해 얻은) 고객의 요구량을 현재 수용량에 맞춰볼 수 있습니다. 이러한 입력 데이터를 전부 살펴본 다음에야 칸반 시스템 설계를 시작할 수 있죠.

 

InfoQ: 이 과정에 프로젝트 관리자를 배치하는 것이 좋을까요?

데이비드: 그렇게 할 수도 있지만 대개는 사람들이 직접 이 과정을 실행에 옮길 수 있도록 적절한 교육을 받길 추천합니다. 곧바로 보드를 벽에 걸고 접착식 메모지를 붙이는 사람들은 업무와 업무 흐름을 시각화할 수는 있겠지만, 그런 사람들이 고객 서비스를 개선하는 칸반 시스템을 설계할 수는 없습니다. 칸반은 서비스 지향 방식이고 서비스 출시 개선 메커니즘입니다. 그렇기 때문에 당신이 제공하고 있는 서비스가 무엇인지, 그 서비스가 받는 요구는 무엇인지, 그리고 요구량과 비교해봤을 때 공급 가능한 현재 수용량이 어떠한지 알아야 합니다.

 

InfoQ: 칸반의 진입 장벽은 어떻습니까? 사람들은 큰 투자를 하기 전에 먼저 이해하기를 원합니다.

데이비드: 은탄환이 존재하지 않는다는 것은 분명한 사실입니다. 사람들은 한 부서가 생산성을 700%에서 800% 개선했던 BBC 처럼, 조직 내에서 한 번도 본 적이 없는 결과를 실현하고 싶어합니다. BBC 월드와이드 웹사이트 개발 부서는 빠른 출시를 통해 광고 노출에서 연간 100만 달러의 수익을 추가로 만들어냈습니다. 이들은 출시율을 700% 개선했고, 덕분에 출시 속도가 빨라져 출시 시간이 줄어들었습니다. 그래서 연간 100만 달러의 추가 광고 수익을 창출해냈죠. 이런 점이 칸반을 적절히 적용했을 때 얻을 수 있는 이익입니다.

 

InfoQ: 하지만 프로젝트 관리자의 관점에서 보면, 마치 과장된 마케팅처럼 들립니다. 제가 처해있는 환경에서 비슷한 결과를 기대할 수 있을지 알아보려면 어떻게 해야 할까요?

데이비드: 저는 이 이야기를 과장이라고 생각하지 않습니다. 사람들이 생산성을 400% 개선했다는 사례 연구를 발표하면, 저는 그걸 보고 “음, 보통 수준이군.”이라고 이야기합니다. 당신은 콘퍼런스를 돌아다니면서 그런 이야기를 들려주는 사람을 100명 정도는 만날 수 있을겁니다.

 

InfoQ: 재미있군요. 하지만 거기에는 우리가 실패한 프로젝트 이야기는 듣지 못하고 있고, 그런 이야기는 그냥 조용히 묻혀버리고 있다는 문제가 있습니다.

데이비드: 책을 읽고서 아무런 도움도 받지 않은 채 놀라운 결과를 이룩한 회사들을 많이 봤습니다. 상업적 관점에서 무시무시할 수도 있는 이야기를 하나 해드리죠. 책만 읽고서 그런 결과를 얻을 수 있다면, 사람들은 교육을 받으려하지 않을겁니다. 하지만 여기 북미에는 칸반을 얄팍하게 사용하는 사람들이 엄청나게 많고, 얄팍한 칸반을 “깊이 있는” 칸반 시스템으로 업그레이드한다면 커다란 이익을 얻을 수 있습니다.
칸반이 시장에서 많은 탄력을 받고 있고, 당신도 그런 이야기를 많이 들었겠죠. 하지만, 벽에 보드를 설치해서 보드를 통해 흐름을 살펴보고 있다는 등의 이야기를 하는 사람들은 얄팍한 칸반을 하고 있는 것이고, 대부분 인터넷에서 건져올린 내용들일겁니다. 애자일 커뮤니티, 특히 북미에 있는 커뮤니티들은 칸반에 대한 이해가 매우 빈약합니다. 그들은 칸반의 깊이, 시스템 사고 방식, 서비스 지향 방식을 제대로 알아보지 않고 있습니다. 진행 중 업무를 제한하는 당김 방식이 반드시 필요하다는 것을 분명히 인식하고 있지도 않습니다. 또한 칸반 시스템 설계의 핵심 역동을 깊이 살펴보지도 않고 있지요.

 

InfoQ: 하지만 일단 발을 들여 놓고 성장해 나가려면 진입 장벽을 극복하는 것이 중요한 일 아닐까요? 예를 들어 어떤 거대 금융 회사가 있는데, 그곳에는 관리 계층이 층층이 쌓여있고, 개발팀은 칸반을 해보고 싶다는 생각을 갖고 있습니다. 개발팀은 관리자를 설득해야 할테고, 그 관리자는 “작년에는 스크럼을 하자고 하더니, 올해에는 칸반을 하자고 하는군. 우리가 스크럼을 해서 무슨 이익을 얻었지?”라고 이야기하는 임원을 설득해야 합니다.

데이비드: 제 생각에 매우 중요하기도 하고 널리 오해하는 점이 있는데, 다시 강조하지만 그것은 북미 애자일 커뮤니티가 안고 있는 문제입니다.
애자일 쪽에서 이름이 널리 알려져 있는 많은 이들이 칸반을 팀 차원의 프로세스로 설명해왔습니다. 칸반은 결코 팀 차원의 프로세스만이 아닙니다. 첫 번째로 구현했던 칸반 시스템은 여러 부서 사이의 업무 흐름을 다루는 프로세스였습니다. 두 번째 칸반이나 2006년과 2007년 사이에 있었던 그 이후의 칸반도 여러 부서 사이의 업무 흐름을 다루었습니다. 팀 차원의 프로세스였던 적은 한 번도 없습니다. 칸반은 조직 차원의 업무 흐름 프로세스입니다. 칸반은 중간 계층이 변화를 이끌어갈 수 있도록 설계되어 있습니다. 그리고 이 점이 시장에서 차별점이 되었습니다. 많은 린 컨설턴트들은 최고 경영진을 설득할 수만 있다면 반드시 성공할 수 있다고 이야기합니다. 그런 변화는 하향식 변화입니다. 대부분의 애자일 변화는 밑으로부터 시작하는 경향이 있습니다. 왜냐하면 애자일은 팀을 지향하며 개발자를 지향하기 때문입니다. 칸반은 중간 계층에서 변화를 시작할 수 있도록 만들어졌습니다. 그리고 업무 흐름, 서비스 지향, 제품 생애 주기의 다양한 부서와 여러 단계를 고려하여 만들어졌습니다. 여러 팀의 협업이 필요합니다. 그리고 이 모든 것을 해내려면 중간 관리자가 되어야 합니다. 여러 다른 조각들을 하나로 묶어낼 수 있는 정치적 권한 때문입니다. 당신이 개발자라면 그것이 수준을 올리는 길입니다.
칸반을 사용하면 인생을 불행하게 만들고 방해하는 것들을 전부 처리할 수 있으며, 관리자는 차단 이슈에 집중해서 차단된 이슈를 더욱 빠르게 해결하고 업무를 원활하게 진행할 수 있습니다. 그러나 다른 무엇보다 칸반을 사용하면 사람들이 내게 요구하는 20가지 일을 한 번에 하는 것이 아니라 소수 몇몇에 집중할 수 있습니다.
직원들이 지속적으로 큰 불만을 갖는 또 한 가지는 우선 순위가 늘 바뀌어서 계속 다른 방향으로 휘둘리는 상황입니다. 칸반을 사용하면 사람들은 커뮤니티 내에서 이야기하는 이른바 “스파이즈 걸스 질문”에 정말로 집중할 수 있습니다. 칸반 시스템 대기열에 새로운 항목을 보충을 하면서, 다음으로 원하는 두 가지가 무엇인지 이야기한 적이 있을겁니다. 관리 컨설턴트인 스티븐 번게이(Stephen Bungay)는 이렇게 이야기합니다. “정말로 원하는 것을 말해주세요. 정말 정말 원하는 것을.”7 그리고 일단 한 번 정하고나면 마음을 바꿔서는 안된다고 이야기합니다. 따라서 원치않는 무언가가 칸반 보드를 따라 흘러가고 있더라도, 그걸 취소할 필요는 없습니다. 개발자와 분석가들은 이 점이 유용하다는 것을 알고 있습니다. 이들은 단지 사람들이 원하는 것들을 진행할 뿐이며 그 양을 제어할 수 있기 때문에, 집중하고, 출시하고, 다음 업무를 시작할 수 있습니다. 상향식으로도 어느 정도 개선을 볼 수 있지만, 그 다음 가치 흐름의 위 아래 방향으로 개선을 확대하지 못하면 그 기세가 한 풀 꺾일겁니다. 정치적 영향력이 충분한 사람이 없다면, 개선을 이루기 어렵습니다. 지금 확산에 대해 이야기하는 중인데, 가끔은 누군가 이끌지 않아도 자발적으로 칸반 시스템이 확대되는 모습을 보기도 합니다.
하지만 솔직히 말해서 칸반을 제대로 적용하려면, 임원급 또는 작은 회사인 경우 선임 관리자 같은 중간 관리자의 참여가 필요합니다. 그러나 상향식은 직원들에게 심리적, 사회학적 장점을 줍니다. 사람들이 제대로 일할 수 있도록 해준다면 스트레스는 상당히 줄어들겠지만, 그렇다고 해서 경제라는 기관에 동력을 공급해주지는 못합니다. 저는 책에서 “잉여 시간(slack)”의 장점에 대해 이야기 했습니다. 잉여 시간이 갖는 장점에 대해 이야기한다고 해서, 제품이나 서비스로서 칸반을 설득시킬 수는 없습니다. 그렇게 한다면 고위 경영진에게 그가 칸반에 비용을 지불해야하는 이유를 전달하지 못합니다.

 

InfoQ: 칸반을 사용했을 때 당신이 설명하는 효율을 얻을 수 있을지 판단하는 데 사용할 수 있는 의사결정 트리(decision tree)8가 있습니까?

데이비드: 예, 고급 과정에서 이 부분을 가르치고 있습니다. 사실은 칸반을 사용하지 않고 있는 상황에서 더 설명하기 쉽습니다.
선임 관리자들이 서둘러 극적인 결과를 보고 싶어하는 참을성 없는 혁명가들로 이루어져 있다면, 칸반을 사용하기 어렵습니다. 하지만 문화적으로 보수적인 나라에서 관료주의적 조직에 몸담고 있다면, 칸반을 적용하기가 더 쉬울겁니다. 칸반은 극단적 혼돈 상태 또는 연구의 초기 단계에도 적용하기 어렵습니다. 칸반은 개발 분야와는 궁합이 잘 맞지만 연구 분야와는 썩 어울리지 않습니다. 가치 흐름을 설명할 수 있고, 고객이 바라는 서비스가 무엇인지 찾아낼 수 있어야 합기 때문입니다. 이런 것들을 설명할 수 없다면 칸반 시스템을 구축할 수 없습니다.
또한 기술 회사 관점에서 보면, 회사에는 구성 관리 역량도 필요하고, 버전 제어도 필요하며, 무언가를 개발 중이면서도 다른 부분을 릴리스할 수 있는 능력도 필요합니다. 평범한 애자일에서 요구하는 것보다 더 수준 높은 구성 관리 역량이 필요하죠. 하나의 반복 주기를 시작해서, 몇 주 동안 업무를 진행한 다음, 배포를 한다면, 반드시 브랜치를 종료하거나 코드에 레이블을 붙이게 됩니다. 하지만 칸반 시스템에서는 여러 브랜치를 동시에 다룰 수 있습니다. 모든 조직이 이 정도 기술 역량을 갖추고 있진 못합니다.

 

InfoQ: 저는 조금 더 좋은 칸반 적용법을 알고 싶습니다. 현재 개발 프로세스를 관리하는 중이라고 가정해볼까요? 일반적으로 프로젝트 모델을 먼저 만들고, 다음에 테스트를 작성하고, 구현을 하고나서, 테스트를 거친 다음, 코드 리뷰를 합니다. 이 각각을 칸반 보드 위에 있는 하나의 열로 볼 수 있을까요?

데이비드: 아마 그럴겁니다. 하지만 상류 및 하류 프로세스도 포함시키고 싶을겁니다. 현재 정치적으로 제어할 수 있는 범위를 살펴본 다음, 정치적 역량을 더 갖춘 다음에 상류와 하류를 포함시킬 수 있습니다.

 

InfoQ: 그게 바로 제가 원하던 방식입니다. 팀 리더는 의사 결정을 하고, 실행하고, 그 제품이 잘 작동한다면 마무리를 하겠지요. 조촐하게 시작해서 차이를 만들게 되면, 그 방법이 확산될겁니다.

데이비드: 어떤 프로세스를 사용하더라도 사회적 자본이 필요하고, 신뢰를 쌓기 위해 사회학적 방법을 필요합니다. 정보를 더욱 투명하게 제공하는 것이 한 가지 예죠. 작동 방식을 이해할 수 있고, “내가 2주 전에 주었던 업무가 지금은 어디에 있지?”라고 이야기할 수 있을 때, 사람들은 신뢰를 보여줍니다. 또한 신뢰는 조금씩 늘어나는 것이고, 신경 심리학적 이유로 인해 비정기적으로 출시하는 큰 약속을 하는 것보다 정기적으로 출시하는 작은 약속을 하는 편이 빠른 신뢰 구축에 더 큰 도움이 됩니다. 목표와 일치하는 출시가 신뢰를 쌓습니다. 그것이 바로 상향식에서 탄력을 만들어내는 비결입니다.
이틀 짜리 고급 교육 과정을 마친 후에, 가끔 이렇게 이야기하는 사람이 있습니다. “변화와 심리학과 사회학을 배웠는데요, 칸반은 언제 배우나요?” 사실상 칸반 대부분이 바로 변화이자 심리학이자 사회학입니다. 칸반 시스템의 핵심은 신호 메커니즘을 통해 진행 중 업무를 제한하는 당김 방식일 뿐입니다. 거기에다 요구에 대한 이해와 적절한 제한을 선택하는 방법 등 몇 가지를 덧붙인 것입니다. 칸반이 조직 내 지식 노동자의 성과를 혁신할 수 있도록 하는 방법은 무엇일까요? 그것은 바로 심리학과 사회학입니다.

 

InfoQ: 데이비드, 자세한 이야기를 들려주셔서 감사합니다! 칸반은 분명 세상을 휩쓸게 될겁니다. 당신의 여정에 행운이 깃들길 바랍니다.

 

1. 미국 사우스 다코타 주에 있는 바위산. 4명의 미국 대통령의 얼굴을 조각해놓은 것으로 유명하다.
2. 네덜란드의 컴퓨터 과학자. 프로그래밍 언어 분야에 대한 지대한 공헌으로 1972년에 튜링상을 수상했다.
3. 미국의 소프트웨어 과학자. C언어를 만든 데니스 리치와 함께 쓴 『The C Programming Language』로 널리 알려져 있다.
4. UML을 만든 그래디 부치(Grady Booch), 제임스 럼버(James Rumbaugh), 이바 야콥슨(Ivar Jacobson)을 가리키는 말
5. 건축가 크리스토퍼 알렉산더(Christopher Alexander)의 디자인 패턴이라는 개념을 소프트웨어 개발에 도입한 에릭 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시디스(John Vlissides)를 가리키는 말
6. 2014년 9월 현재도, 앤더슨은 여전히 『칸반』 2판과 공식 가이드 작업을 진행 중이다.
7. 스파이스 걸스의 히트곡인 Wannabe의 가사. 원문은 “tell me what you want, what you really really want”
8. 불확실한 미래 상황을 분기점이 있는 도형으로 표현해서 의사결정 문제를 분석하는 데 사용하는 방법. 디시전 트리 또는 의사결정 나무라고 부르기도 한다.

칸반의 개척자 데이비드 J. 앤더슨과의 인터뷰

포르투갈어 원문: Kanban com o pioneiro: Entrevista com David J. Anderson
영어 원문: Kanban Pioneer: Interview with David J. Anderson

by Anselmo Martelini, Eric Fer, Leonardo Campos, Rafael Buzon on Aug 20, 2012

소프트웨어 개발에 최초로 칸반을 적용한 데이비드 J. 앤더슨이 최근 브라질을 방문했다. InfoQ 브라질의 편집자들이 데이비드를 만나서 린, 애자일, 칸반을 주제로 인터뷰를 진행했다. 다음은 인터뷰 내용을 요약한 것이다.
 

InfoQ: 린 철학과 애자일 철학은 서로 어떤 연관이 있나요?

데이비드: 비슷한 부분이 무척 많습니다. 그래도 차이점을 하나 꼽아보자면, 린은 완벽을 추구하는 반면에 애자일은 불완전한 정보로 진행해가면서 나중에 더 많은 것들을 알게 되면 진로를 변경한다는 아이디어가 바탕에 있지요. 린 방식으로 사고하는 사람들은 그 부분에서 어려움을 겪는 경우가 많습니다. 불완전한 정보를 갖고 앞으로 나아가야 한다는 개념을 어려워합니다. 이들은 재작업을 낭비로 생각합니다. 애자일은 완벽을 추구하지 않습니다. 이 부분이 중요한 차이점입니다.
린과 애자일의 또 한 가지 차이점은 사람을 바라보는 관점입니다. 린에서는 시스템 사고를 통해 모든 것을 바라봅니다. 사람도 시스템의 일부이기 때문에 사람이 이루는 성과는 시스템으로부터 큰 영향을 받는다고 여기고, 그래서 사람들이 효율적으로 일할 수 있는 시스템을 설계하는 것이 사람을 존중하는 방법이라고 생각합니다. 애자일의 접근 방식은 좀 더 인본주의적이며 사람들은 각 개인으로서 존중합니다. 애자일 철학은 사람들이 제대로 일할 수 있도록 내버려두어야 스스로 조직화하여 최선의 결과를 얻을 수 있다는 무정부주의 또는 자유주의에 가깝습니다. 린과 애자일은 사람을 존중하는 방법에서 큰 차이가 있습니다.
애자일 커뮤니티, 특히 미국 애자일 커뮤니티에서는 정치적 성향이 커다란 영향력을 미칩니다. 커뮤니티 내에는 인본주의자도 있고, 자유주의자도 있으며, 꽤나 무정부주의적인 철학을 지니고 있는 사람들도 있습니다. 애자일 커뮤니티에서는 사람은 태생적으로 선하기 때문에 (그래서 믿을 수 있기 때문에) 모두가 자신이 원하는 것이 무엇인지 알고 있을 것이라는 사상이 널리 퍼져 있습니다. 개인적으로는 그런 생각을 희망 사항이라고 봅니다.
예전부터 지금까지, 애자일 커뮤니티는 순수 공산주의 이론으로부터 영향을 받은 측면이 있습니다. 다음과 같은 생각을 통해 그런 부분이 드러납니다. “관리자는 모두 사악하다.”, “사람들을 통제하려는 시도는 모두 나쁜 것이다.”, “권한을 주장하는 시도는 모두 나쁜 것이다.” 이런 말들이 정말로 맞는지 알 수 없지만, 린 방식으로 사고하는 사람들은 조금 다른 관점을 갖고 있다고 생각합니다. 그들은 시스템 구축이 중요하다고 생각하고, 시스템을 구축하는 사람들과 시스템을 운영하는 사람들의 존재가 중요하다고 생각합니다. 카이젠 문화는 자기 조직화가 아닙니다. 그러므로 애자일과 린은 사람에 대해서도 그렇고 조직에 대해서도 상당히 다른 방식으로 접근합니다.
출근해서 일을 하고 급여를 받고 퇴근해서 가족을 생각하면서 인생을 즐기고자 하는 사람이 있다 해도, 저는 괜찮다고 생각합니다. 그 사람들의 열정이 직장 내에 있지 않더라도 상관 없습니다. 애자일을 따르는 많은 사람들은 모든 팀원이 직업에 대단한 열정을 가져야한다고 믿습니다. 저는 애자일을 큰 회사에 대규모로 적용할 때에는 그런 생각이 현실적이지도 않고 실용적이지도 않다고 생각합니다. 열정적 직업 정신에 의존하는 이런 생각이 6명 규모의 스타트업에서는 통할 수도 있겠지만, 대기업에 속해 있는 300명 규모의 사업부라면 그렇지 않습니다.

 

InfoQ: 팀에게 권한을 위임하는 것에 대해서는 어떻게 생각하시나요? 그 생각에 반대하시나요?

데이비드: 사람들이 원하는 것은 뭐든지 할 수 있도록 해주거나, 어떻게든 제대로 된 결과를 만들어내려고 스스로 조직화하리라고 가정하는 것이 위임은 아닙니다. 위임이란 경계를 정의하는 일입니다. 아이들은 키우는 것과 마찬가지죠. 우리는 아이들에게, 몇 시에 잠자리에 들어야 하는지, 어디서 놀아야 하는지, 집 앞 마당을 벗어나도 되는지, 얕은 연못가에서 헤엄을 쳐도 될지, 다이빙 보드에서 뛰어내려도 좋은지 등과 같은 것들을 알려줍니다. 위임이란 사람들에게 분명한 경계를 제시하는 것이고, 그 경계 내에서 자주성을 발휘할 수 있도록 해주는 일입니다.

 

InfoQ: 당신은 최근 칸반에 “조직적 피드백의 실행(implement organizational feedback)”이라는 새로운 핵심 특성을 추가했습니다. 그 이유는 무엇인가요?

데이비드: 사실은 새로운 특성을 추가한 것이 아닙니다. 명시적으로 드러냈을 뿐이죠. 제 책 『칸반: 기술 비즈니스의 점진적 변화』를 보면, 이미 모든 장마다 이 주제를 계속 다루고 있습니다. 다만 핵심 특성 중 하나로 나열하지 않았던 것입니다. 저는 이 부분이 커다란 실수라는 것을 깨달았는데, 사람들이 조직 차원의 피드백 루프를 충분히 적용하고 있지 않다고 보았기 때문입니다. 어떤 일이 일어나지 않고 있다면, 더욱 분명하게 만들 필요가 있습니다. 그것이 바로 핵심 특성 목록에 조직적 피드백의 실행을 추가한 목적입니다. 그러니까 새로 만든 것이 아니라 강조한 것입니다.

 

InfoQ: 당신은 칸반이 수용량과 요구량을 맞추는 한 가지 방법이라고 이야기합니다. 거기서 얻을 수 있는 장점을 말씀해주시겠어요? 그리고 비즈니스 쪽 사람들에게 이 부분이 중요하다고 어떻게 설득할 수 있을까요?

데이비드: 우리는 요구량이 수용량 또는 역량과 균형을 이루기를 원하며, 수용량이 과도한 부담을 받는 상황을 피하는 것은 매우 중요합니다. 부담이 지나치면 실제로 생산이 감소하고, 품질이 낮아지며, 생산 시간이 더 오래 걸립니다. 균형을 이루게 되면 수용량을 개선할 수 있고 모든 일이 더 빨라집니다. 마무리되는 일이 더 많아지죠. 품질 역시 더 좋아질겁니다.
비즈니스 쪽 사람들은 수용량을 요구량에 맞게 제한하는 것이 어떤 의미인지 이해할 수 있어야 합니다. 그것은 지원 가능한 수용량에 맞게 요구량을 제공한다는 뜻입니다. 항상 지원할 수 있는 것보다 발생하는 요구가 더 많기 때문입니다. 하지만 인간의 창의성에는 제한이 없습니다. 정말로 중요한 것은, 사람들이 접하게 될 새로운 소프트웨어가 갖는 위험, 보상, 이익 등을 정확히 평가하는 것입니다.
그러므로, 비즈니스 쪽에서 위험을 분석하고 자신들의 아이디어가 지닌 이익을 이해할 수 있도록, 그리고 요구량을 수용량에 맞추어 균형잡힌 포트폴리오를 통해 최고의 정보를 제공하는 데 집중할 수 있도록 도움을 주는 것은 매우 가치있는 일입니다. 제공할 수 있는 수용량을 개선하려고 우리가 노력하는 동안, 그들 또한 가능한 아이디어들 중에서 최고를 선택하는 방법을 배워야 합니다.
우리가 이 두 가지(수용량 증가 그리고 요구량에 대한 위험 관리 또는 개선)를 모두 이루어낼 수 있다면 더욱 조화로운 삶을 살 수 있습니다. 점점 더 요구가 많아지는 이유 중 하나는, 미래가 불확실하고 그래서 비즈니스 쪽 사람들이 “그냥 다 만들어주세요.”라고 이야기하며 양쪽 모두에 베팅하기 때문입니다. 분명히 이런 상황은 너무나 비합리적이기 때문에, 그들이 위험을 제대로 평가하고 직면한 불확실성을 더 잘 이해할 수 있도록 도와주어야 합니다. 그렇게 하면 비즈니스 쪽 사람들은 자신의 선택을 더욱 자신할 수 있습니다.

 

InfoQ: 칸반에는 어떤 미신이나 오해가 있나요? 만약 그런 것이 있다면, 그 중 어떤 것이 가장 널리 퍼져있고 커다란 오해일까요?

데이비드: 앨런 섈로웨이가 칸반에 대한 오해를 주제로 글을 쓴 일이 있습니다. 그 글이 좋은 참고가 되겠네요.1 칸반에 대해 많은 오해가 있다고 생각합니다. 그 중 한 가지는 보드에 대한 오해입니다. 실제로 애자일 얼라이언스는 웹 사이트에서 칸반 보드가 애자일 실천법 중 한 가지라고 설명하고 있습니다. 칸반 방법을 “칸반”이라고 부르는 이유는 보드가 있기 때문이 아니라, 진행 중 업무를 제한하고 린에서 “책임이 따르는 마지막 순간(last responsible moment)”이라고 부르는 시점까지 약속을 늦추는 당김 방식인 가상 칸반 시스템을 구현한 것이기 때문입니다. 보드는 단지 진행 중인 것을 시각화하는 방법 중 하나에 불과합니다.
보드는 나중에 추가한 것이고, 칸반 시스템이 먼저 등장했습니다. 당시에는 보드를 가르켜 그냥 “카드벽”이라 불렀고, 카드벽은 애자일 커뮤니티 내에서 아주 흔한 것이었습니다. 보드는 새롭지도 않았고, 혁신을 대표하지도 않았습니다. 가상 칸반 시스템을 사용한 것이 바로 혁신이었습니다.
계속 나타나는 많은 오해도 있습니다. 그 중 하나는 칸반이 유지 보수나 IT 운영 업무에만 적합하고 대규모 프로젝트에 사용해서는 안된다는 생각입니다. 그것은 분명히 잘못된 정보입니다. 예를 들자면 우리는 2007년에 1,100만 달러 규모의 프로젝트에서 50명이 넘는 사람들과 함께 칸반을 사용하기도 했습니다.
우리는 상당히 초창기부터 대규모 프로젝트에 칸반을 사용해왔고, 예측성을 개선하고 위험을 관리하는 데 칸반을 사용할 수 있습니다. 이것은 (출시 일정의 확실성 측면에서) 프로젝트 관리와 거버넌스에 매우 중요한 부분입니다.
유감스럽게도, 칸반은 단지 유지 보수나 IT 운영 업무에만 사용할 수 있고 대규모 프로젝트에 사용해서는 안된다는 오해가 애자일 커뮤니티에서 흔하며 되풀이해서 나타나고 있습니다.

 

InfoQ: 칸반을 사용하면 폭포수 모델로 돌아가게 된다는 오해에 대해서는 어떻게 생각하시나요? 아직도 그런 오해가 있나요?

데이비드: 칸반이 폭포수라는 오해는 2007년부터 2009년 사이에는 아주 흔한 것이었지만, 이제는 그런 이야기가 많이 줄었습니다. 그런 오해가 생긴 이유는 칸반 초기 사례를 주로 애자일이라고 볼 수는 없는 전통적 소프트웨어 개발 생애주기 또는 PSP/TSP 방법을 사용하는 팀에서 얻었기 때문이었습니다. 그렇기 때문에 초기 칸반 사례들은 전부 애자일이 아닌 사례들이었습니다.
그 이유는 당연하게도, 제가 애자일을 거부하는 팀을 개선하는 방법으로 칸반을 도입했기 때문입니다. 모든 초기 사례가 애자일이 아닌 것이 당연하죠. 하지만 요즘에는 애자일 사례가 아주 많습니다. 아마 50%가 넘는 사례들이 스크럼 위에 칸반을 더한 것이기 때문에, 이제는 그런 오해가 대부분 사라졌다고 생각합니다.

 

InfoQ: 당신은 요새 “아이디어에 대한 권한 부여와 프로세스 혁신 장려(giving permission for ideas and encouraging process innovation)”라는 특성 추가를 고려하고 있습니다. 왜 예전에는 이 특성을 추가하지 않았었는지 말씀해주시겠어요? 그리고 “칸반 마스터”의 필요성에 대해서는 어떻게 생각하시나요?

데이비드: 사실 저는 칸반 원칙에 리더십을 장려하고 리더십과 관리는 다른 것이라는 점을 사람들이 인식하도록 해야 한다는 아이디어를 더했습니다. 관리자에게는 시스템을 운영하고, 그 시스템을 설계하고, 모든 정책 그리고 정책의 변경이나 중단에 대한 결정을 해야 할 책임이 있습니다. 다 좋지만, 우리가 진정으로 원하는 것은, 평범한 개인이든 관리자든 업무를 진행하는 모든이가 리더십 행동을 보여주는 것입니다.
리더십 행동이란 현재 상태가 충분치 않다고 이야기하면서 더 좋은 아이디어를 제안하거나 보여주는 것입니다. 그렇게 하지 않는다면 지속적 개선의 촉매를 얻을 수 없습니다. 전부 어깨만 으쓱하면서 이렇게 이야기할겁니다. “어, 음, 뭐 그런거지. 일하러 돌아가자고!” 아무 것도 더 나아지지 않을겁니다. 그래서 리더십이란 일종의 마법 재료이고 촉매입니다.
최근 비슷한 사례가 한 가지 더 있습니다. 스웨덴의 칸반 컨설턴트인 호칸 포르스는 마이크 로더(Mike Rother)의 책인 『Toyota Kata』를 읽고나서 칸반에는 세 가지 카타(かた)2가 있다는 아이디어를 제안했습니다.
첫 번째는 좁은 지역의 카이젠 활동을 유발하는 일일 스탠드업 회의입니다. 두 번째는 업무 흐름 사이, 칸반 시스템 사이의 개선을 유발하는 운영 리뷰입니다. 그리고 세 번째는 상급자와 하급자, 일선 관리자와 이선 관리자 사이에서 선임이 후임에게 “우리 시스템은 얼마나 잘 운영되고 있나요?”, “우리 정책을 올바른가요?”, “우리가 올바른 지표를 수집하고 있나요?”, “우리는 올바른 것을 시각화하고 있나요?” 등의 질문을 하면서 코칭하는 관계입니다. 그렇게 함으로써, 우리는 우리가 살고 있는 세상을 이해할 수 있고 개선을 위한 변화를 만들 수 있습니다.

 

InfoQ: 커뮤니티에서 “칸반 마스터”라는 용어를 익숙하게 생각하나요?

데이비드: 아니오! 우리는 (스크럼 마스터의 역할에 대응하는) 칸반 마스터라는 아이디어에 반대합니다. 저는 코치를 활용하는 편이 더 가치있다고 생각합니다. 애자일 코칭에서 흔히 볼 수 있는 코칭과는 다른 역할입니다. 애자일 코치들을 보면, 대부분 팀에 소속되어 있고 매일 팀과 함께 일합니다.
우리는 칸반 코치가 보통 한 달에 2~3일 정도 함께 일하면서, 정책이나 시각화, 지표 등에 대해 주로 이야기를 나누고, 수용량을 이해하고 개선을 고민할 수 있도록 도움을 주는 역할이라고 생각합니다. 그렇게 하는 데 매일 함께 있을 필요는 없습니다.

 

InfoQ: 최근 InfoQ는 칸반이 스크럼의 다음 단계라는 기사를 발표한 적이 있습니다. 여기에 대해서는 어떻게 생각하시나요?

데이비드: 그 기사가 시장 변화에 대한 이야기라면, 우리는 칸반이 소프트웨어 프로세스 시장에서 새롭고 중요한 기회가 되어가고 있는 중이라고 생각하고 있으며, 저도 그 말이 맞다고 생각합니다. 칸반 교육이나 코칭 또는 컨설팅, 칸반 소프트웨어, 시뮬레이션, 게임 등 모든 부분이 정말로 탄력을 받고 있다는 많은 증거가 있고, 그래서 저는 시장 관점에서 보았을 때 칸반이 새로운 기회로 발전하고 있다고 봅니다. CMMI가 있었고, RUP가 있었고, XP가 있었고, 스크럼이 있었다고 생각한다면, 칸반이 그 뒤를 잇고 있습니다.
하지만 사람들이 칸반을 사용하기 전에 먼저 스크럼을 해야 한다는 의미의 기사였다면… 완전히 옳지 않은 말이라고 생각합니다. 스크럼은 큰 조직에 적용하기가 어렵습니다. 문화적으로 잘 맞지 않는 회사도 많고 사람들은 스크럼을 적용할 때 저항합니다.
반면에 칸반은 쉽게 적용할 수 있도록 설계되어 있습니다. 지금 바로 시작할 수 있는 방법으로 만들어졌습니다. 칸반은 스크럼의 대안입니다. 사람들이 (스크럼에 대한) 저항을 극복하길 그저 기다리는 중이라면, 칸반을 더 일찍 적용해서 더욱 빠른 개선을 이룰 수도 있는 큰 기회를 놓치고 있는 것입니다. 이미 스크럼을 적용 중이고 더욱 개선할 필요를 느끼고 있다면, 칸반을 나중에 추가하는 것도 좋은 생각입니다. 하지만 현재 스크럼을 하는 중이 아니라면, 바로 시작할 수 있는 방법으로서 칸반을 고려해보는 것이 좋습니다.

 

InfoQ: 위르헌 아펄로(Jurgen Appelo)의 책 『Management 3.0』을 보면 “밈플렉스(memeplex)”3에 대해 이야기하고 있습니다. 아펄로는 스크럼이 성공적으로 선택된 이유가 현재의 밈플렉스를 새로운 밈플렉스로 대체하기 때문이라고 주장하고 있습니다. 여기에 대해서는 어떻게 생각하시나요?

데이비드: 그 주장에 반박하지 않겠습니다. 하지만 문제는 밈플렉스의 완전한 제거와 대체가 가능할까요? 스크럼이 성공적이었다고 이야기할 수도 있겠지만, 저항 또한 만만치 않았습니다. 스크럼을 적용하긴 했지만 많은 문제가 있거나 실패한 경우도 있습니다. 비교적 최근 믿을만한 시장 조사를 통해 스크럼이 시장에서 15%를 차지하고 있다는 결과를 보았습니다. 전성기 RUP의 점유율보다 더 높습니다. RUP의 점유율은 약 11%였습니다. 15%면 훌륭하긴 하지만, 그 중에서 문제가 있는 적용이 얼마 정도인지 질문을 던져볼 필요가 있습니다.
낙관적으로 생각해서 15% 전부가 스크럼을 멋지게 적용했다고 가정하더라도, 시장에는 아직 85%가 남아있습니다. 그 부분이 제가 해결하고자 하는 문제입니다. 사람들이 스크럼을 더욱 훌륭하게 적용할 수 있도록 시장의 15%에 집중하는 것과 시장의 나머지 85%에 도움을 주는 것 중에서 어떤 것이 더 좋을까요? 저는 위르헌이 스크럼이 옳다고 주장했던 많은 부분에 대해서는 의심하지 않습니다. 하지만 이 우주에는 그리고 관리나 소프트웨어 프로세스의 세상에는 해결해야 할 더욱 흥미로운 문제가 많고, 나는 그 공간에서 나머지에 더 관심이 있습니다. 스크럼 커뮤니티에 있는 많은 분들도 스크럼을 개선하는 데 관심이 있으리라 확신합니다.

 

1. Common Myths of Kanban
2. 정해진 동작을 순서에 따라 반복하는 무술 훈련법. 태권도에서는 품새라고 부른다.
3. 밈(meme)은 리처드 도킨스(Richard Dawkins)가『이기적 유전자』에서 주장한 개념으로, 사상, 종료, 관습, 이념 등 인간의 삶을 규정하는 다양한 문화적 요소들이 유전자와 비슷한 방식으로 퍼지고 번식한다고 설명할 때 등장한 단어. 밈플렉스는 밈과 복합체(complex)의 합성어로 밈의 집단을 이야기한다. 언어, 종교, 과학 이론 등이 밈플렉스에 해당한다.