칸반에는 칸반이 없다?!

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

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

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

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

  • 데이비드 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)를 제한한다.
  • 흐름을 관리한다.
  • 정책을 명시화한다.
  • 피드백 루프를 실행한다.
  • 함께 개선하고 실험을 통해 발전시킨다.

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

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

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

 

초보자를 위한 애자일/린 소프트웨어 개발 입문 안내

애자일/린 소프트웨어 개발에 대해 사람들이 갖는 인식이 어떠하든, 분명히 과거에 비해 더 많은 사람들이 애자일/린을 알고 있고, 더 자연스럽게 받아들이고 있다. 불과 몇 년 전만 해도, “애자일”을 검색하면 그 결과에 “OOO는 장애자일 수…” 또는 “XXX는 동성애자일 것이…” 따위가 부지기수였고, 실제로 개발에 적용하고 있다는 곳도 거의 찾아볼 수 없었는데, (“칸반”은 아직도 검색하면, “유럽의 화약고 발칸반도에서는…”, “기름 한칸반으로 어디까지…” 같은 결과가 주루룩 나온다 ㅜㅜ) 이제는 스타트업부터 대기업까지, 스크럼이나 CI, 일일 스탠드업, 칸반 보드와 같은 것들이 (물론 제대로 하고 있는지와는 별개로) 비교적 자연스러운 상황이 되었다.

하지만, 애자일/린 소프트웨어 개발에 새롭게 관심을 갖고 학습해보고 싶은 사람들 입장에서는, 오히려 요즘 환경이 더 악회된게 아닐까하는 생각이 든다. 예전보다, 커뮤니티의 오프라인 모임도 활발하지 않은 것 같고… 몇 년 전부터 소식이 없는 대안언어축제나 애자일 코리아 같은 세미나, 컨퍼런스, 워크숍 등도 많이 사라졌다. “애자일/린 소프트웨어 개발을 공부해보고 싶은데요, 어떻게 하는게 좋을까요?“라는 질문을 받아도, 현재는 안타깝게도 책 몇 권 추천해주는 것 이외에 뚜렷한 대안이 없다. 영어권 애자일 트레이너들이 자주 방문하는 싱가포르, 중국, 필리핀 등이 오히려 더 부러운 지경이다.

그래서, 애자일/린 소프트웨어 개발을 처음으로 학습하기 시작할 때 꼭 필요한 것들이 무엇인지 주변 분들께 알려드리려는 목적으로 한 번 정리해보았다. 아래 내용은 물론 100% 주관적인 선택이다.

1

첫 번째. 애자일 소프트웨어 개발 선언 읽어보기

  • 제일 먼저 봐야할 것은 애자일 소프트웨어 개발 선언Manifesto for Agile Software Development이다. 애자일 소프트웨어 개발이 추구하는 네 가지 가치를 간결하게 표현하고 있으며, 마치 헌법처럼 모든 것을 아우르는 최상위 개념이라고 할 수 있다.
  • 선언 아래쪽에 있는 애자일 소프트웨어의 12가지 원칙Principles behind the Agile Manifesto도 매우 중요하다. 애자일 소프트웨어 개발이 추구하는 가치를 이루기 위한 원칙들이다.
  • 가치와 원칙을 항상 중요하게 생각하고 이를 지키기 위해 노력이 없다면, 애자일 소프트웨어 개발이라고 볼 수 없다.
  • 애자일 소프트웨어 개발 선언을 만든 17명의 이름도 눈여겨 보는 것이 좋다. 거의 대부분 매우 활발한 개발/저술/강연/컨설팅 등의 활동을 하고 있으며, 그 활동을 통해 지금도 애자일/린에 커다란 영향을 미치고 있다.

2

두 번째. 위키 백과의 애자일 소프트웨어 개발 항목 찾아보기

  • 두 번째로는 위키 백과에서 애자일 소프트웨어 개발 항목을 찾아 읽어본다.
  • 학습을 본격적으로 시작하기 전에, 애자일/린 소프트웨어 개발의 사전적 의미를 간단히 파악해볼 수 있다.

3

세 번째. 메일링 리스트 가입하기

  • 묻지도 따지지도 말고 다음 메일링 리스트 세 군데에 가입한다.
  • Xper는 국내에서 거의 유일한 애자일 커뮤니티이다. 개발자 뿐만 아니라 매우 다양한 분야의 사람들이 함께 모여 애자일에 대한 경험과 지식을 나누고 있다. 요즘에는 예전만큼 활발하지는 않지만 과거 메일링 리스트를 읽어보는 것만으로도 큰 도움을 얻을 수 있고, 지금도 이따금 올라오는 글에서 유용한 정보들을 얻을 수 있다.
  • Scrum Alliance의 메일링 리스트는 세계적으로 가장 활발한 애자일 관련 메일링 리스트라고 할 수 있다. 물론 영어로 메일이 오고가지만, 책에서 볼 수 있는 몇 년 묵은 이야기가 아니라, 살아있는 최신 정보들을 접할 수 있다. 그리고, 메일링 리스트에서 지금도 활발히 활동하는 전설의 레전드들을 만나볼 수도 있다.
  • Using the Kanban Method는 칸반이 탄생했던 야후 메일 그룹이다. 초창기 칸반을 소프트웨어 개발에 적용하고자 노력했던 사람들이 (창시자인 데이비드 J. 앤더슨을 포함해서) 아직도 고스란히 여기에 출몰한다. 전세계에서 가장 빠르게 칸반에 대한 정보를 얻을 수 있는 곳이다.

4

네 번째. 애자일 SW 개발 101 읽어보기

  • 정보통신 산업 진흥원NIPA 산하의 소프트웨어 공학 센터에서 배포하고 있는 애자일 초심자를 위한 가이드이다.
  • 분량과 내용 모두 애자일/린을 처음 접하시는 분들에게 알맞게 되어 있다.
  • 애자일의 개요, 각종 실천 방법, 사례 연구 등의 내용으로 구성되어 있다.
  • 회원 가입 후 로그인하면 다운로드 받아볼 수 있다.
  • 6명의 공동 저자 모두 다년간 애자일 소프트웨어 개발에 풍부한 현장 경험을 갖고 있는 분들이며, 덕분에 실제로 직접 고민하고 해결했던 문제들이 현장감 있게 담겨 있다.

5

다섯 번째. State of Agile Survey 살펴보기

  • 같은 이름의 프로젝트 관리 도구인 VersionOne이 매년 발간하는 애자일 보고서이다.
  • 2007년부터 올해까지 9년 째 보고서를 발표하고 있다.
  • 1년 동안 전세계 소프트웨어 개발 업계에 있는 다양한 사람들의 의견을 종합하여, 그 다음 해에 그 내용을 공개하고 있다.
  • 다른 곳에서는 애자일을 어떻게 바라보는지, 무엇을 기대하는지, 어떤 문제를 겪고 있는지 등을 멋진 인포그래픽을 통해 볼 수 있다.

6

여섯 번째. 스크럼 가이드 읽어보기

  • 전세계적으로 가장 널리 사용하고 있고 가장 인기 있는 애자일 개발 방법인 스크럼Scrum에 대한 기본 안내서이다.
  • 스크럼 가이드는 창시자인 켄 슈와버Ken Schwaber와 제프 서덜랜드Jeff Sutherland가 직접 썼으며, 한글 버전도 있다.
  • 스크럼의 핵심 개념과 규칙, 활용 방안에 대해 학습할 수 있다.

7

일곱 번째. 즐겨찾기에 “애자일 이야기” 블로그를 등록하고 모든 글 읽어보기

  • 애자일 컨설팅의 김창준님 블로그
  • 모든 글들을 꼼꼼하게 읽어보시길 추천한다.
  • 애자일/린에 기술만큼 중요한 것들이 얼마나 많은지 알 수 있다.

8-1 테크니컬리더 8-3

마지막. 세 권의 추천도서

위 여덟 가지만 충실하게 학습해도, 기초를 튼튼히 쌓았다고 볼 수 있지 않을까? 이 정도만 해도, 기초에서 그치는 것이 아니라 아마도 그 이상의 역량을 갖출 수 있을 것이다.

P.S. 나중에 입문 단계를 벗어나고 싶은 분들이 참고할만한 자료도 한 번 정리해봐야겠다.

P.P.S. 위에서 언급한 사이트, 블로그, 책, 기타 자료들 모두 훌륭하지만, 이것보다 더 중요한 것이 한 가지 더 있다.

개인적으로는, 몇 년 동안 혼자 책을 보고 시도했던 결과보다, 과거에 미리 같은 경험을 해보았던 사람들의 도움으로 얻은 결과가 훨씬 더 좋았다. 나는 그 동안 만났던 좋은 분들 덕분에, 절대 풀리지 않을 것만 같았던 어려운 문제들이, 순식간에 눈 녹듯 사라지는 놀라운 경험을 여러 차례 경험해볼 수 있었다.

애자일/린 소프트웨어 개발을 학습하는데, 실력있고 열정있는 애자일 코치와 함께 일해보고 네트워크를 지속적으로 유지하는 것만큼 좋은 방법은 없다. 거인의 어깨에 올라서서 바라보는 세상이 더 넓은 법이니까.

P.P.P.S. 인터넷에 돌아다니는 창준님 사진을 사용했는데… 괜찮겠죠? 창준님?