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

by Victor Grazi on May 8, 2013

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<sup>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. 불확실한 미래 상황을 분기점이 있는 도형으로 표현해서 의사결정 문제를 분석하는 데 사용하는 방법. 디시전 트리 또는 의사결정 나무라고 부르기도 한다.↩</sup>