린 개발방법론이 보통 어떤 맥락에서 쓰이는가?
우선, 린 개발방법론은 개발 원칙에 대한 이야기이고, 애자일보다도 더 ‘메타적’이다. 좋게 말하면 거시적이고 나쁘게 말하면 말하고자 하는 바를 수동적으로 던져 두기만 한다는 뜻이다. 그리고 앞선 포스트에서 애자일이 지나치게 ‘메타적’인 문제에서 지적한 구멍은 놀랍게도 린 개발방법론이 건드리는 부분과 적당히 나사가 맞아 들어간다.
그래서 다시 생각해도 나는 번복하지 않는 입장으로 애자일은 나사가 빠진 스포츠카라고 생각을 한다.
우선, 애자일에서 가장 문제가 됐던 것이 무엇인가?
무엇이 낭비이고, 언제가 결정 시기이며, 납품 여부의 판단 기준과 권한 설정이 어떠한가?
이것에 대해서 놀랍게도 린 개발 방법론이 적절한 통찰을 제공한다.
골자만 남기고 보자면 세 가지 축으로 나뉜다.
결함 제거, 신속성, 품질 기법
이 세 가지의 축에 대해서 린 방법론은 7 가지의 개발 원칙을 제시한다. 그리고 그 원칙의 실무적이고 일반적인 언급도 제시한다.
낭비를 제거하라
낭비를 어떻게, 왜 제거하는지에 대한 이야기는 거의 이 부분의 핵심 내용이 될 수밖에 없다.
그것을 이해하기 위해 먼저 봐야 할 것이 파레토의 법칙이다.
파레토의 법칙(Pareto Principle)
파레토의 법칙은 원래는 수학적이고 통계적인 이론이다. 파레토의 법칙은 “확률 변수의 최소값이 주어질 경우” 전체의 20%가 나머지 80%의 결과를 초래한다는 것이다. 이를 테면, 적절한 제약 조건이 주어진 정원에서 잘 여문 20%의 콩깍지가 전체 산출의 대부분을 차지하고, 나머지 콩깍지는 산출물에 크게 영향을 주지 않았다는 것이다.
물론 수학적으로만 아름다울 수 있지 않느냐? 하고 반문할 수 있지만, 린 개발방법론은 대체로 이 파레토의 법칙을 따라서 코드의 20% 부분에서 80%의 버그가 발생한다고 가정하고 진행된다.
그리고, 이 파레토의 법칙이라도 있는 것이 “적당히 잘 짜면 된다”는 무식하고 인간적인 압박보다는 훨씬 납득 가능한 형태이다.
배움 증폭
이것은 프로세스의 진행 과정에서도 배움을 계속해서 요구하는 과정이다. 보통 이러한 단계를 충실히 따르는 기업은 수행 중인 과제와 연관이 있는 분야의 써밋이나 세미나 등에 임직원을 참석시키거나, 관련한 교육 등을 무료로 진행하는 등의 지원도 포함된다. 많은 경우 이런 지원이 실제 기업에서 이뤄지느냐는 상황, 기업에 따라 다르지만 원칙적으론 수행되는 것이 정석이다.
늦은 결정
앞에서의 배움 증폭은 늦은 결정에 대한 밑밥이기도 하다. 배움 증폭 단계에서 학습하면서 판단한 개선안 등이 결정이 늦게 이루어지는 만큼이나 충분하게 반영이 되고, 이후에 피드백을 기반으로 더 나은 결정을 내릴 수 있게끔 시간을 끌어준다. 그러나, 뒤의 것은 이것과 모순되는 일이다.
빠른 납품
결정과 실제 개발은 늦게 이루어지지만, 납품은 “고객에게 가능한 한 빨리 가치를 전달”하라고 강요한다. 조기에 자주 납품을 하면서 피드백을 수집, 그리고 고객 요구 사항에 따라 개선한다고 서술하는데, 결정이 늦었으면 스프린트 기간의 일부만이 개발에 투입되며, 결과적으로 과로에 시달릴 수 있다. 그래서, 결정 시기를 최후로 미루는 것도 이론적인 측면이 어느 정도 있다고 생각한다.
팀에 권한 위임
솔직히 이 부분은 뭐라고 말해야 할지 모르겠다. 어떻게 보면 말 뿐인 팀의 복지와 분위기에 대한 이야기이기 때문이다.
명목 상으로는 팀 구성원을 존중하고 그들에게 결정을 내라고 문제를 해결할 ‘자율성’을 부여한다고 한다. 실상은 어떠한 학습 내지는 사고 기회를 주지 않고 눈치 싸움을 하라는 소리지만… 그리고 ‘권한을 부여하여서’ 자신의 작업에 대한 주인 의식을 갖고 팀의 성공에 기여한다고 한다. 내가 자본가가 아닌데, 문서 몇 페이지 권한을 받는다고 주인 의식을 강요하는 것은 이해하기 어렵다. 만약 자신이 부사장이나 사장의 자리에 있다면 안 갖는 것이 문제이지만, 왜 공장의 직공이나 백화점의 캐셔에게 ‘스스로가 공장장, 점장이라고 생각하라’고 하는지 구조적으로 납득하기 힘든 것은 사실이다. 그러나, 그것이 눈 앞에 놓여진 사회이니까 그렇다고 해 줘야 한다.
통합성 구축
아, 드디어 꽃이다, 좋든 나쁘든 늘 요구되는 통합성 구축이다.
개발 초기부터 통합하고 또 통합하라고 한다. 의문은 “무엇을 통합하라는 건데?”
개발에서 통합성은 늘 품질 향상이라고 등식처럼 소비된다. 그렇기 때문에 소규모 개발 단계 하나하나에 대해 통합적이지 못한 것들을 오류 혹은 부채로 생각하고 해결하는 것이 모범적으로 간주된다.
좋은 측면으로는 애플의 통합 생태계가 있을 것이고, 나쁜 측면으로는 마이크로소프트 Azure의 모든 크로스 플랫폼 환경이 내부적으로 파워쉘을 사용한다는 끔찍한 사실이 있을 것이다.
한편으로는 통합성에 대한 집착이 정말 좋은 것인가 생각한다.
전체 최적화
개발 프로세스가 개별 구성 요소에 집중하기보다 전체적으로 최적화되어야 한다(혹은 그렇게 주장한다). 전체 프로세스를 최적화함으로써 팀은 낭비를 식별 및 제거하고, 리드 타임을 단축하고, 고객에게 보다 신속하게 가치를 제공할 수 있다.
그러니까 달리 말해서 개발은 중요하지 않다는 주장을 당당하게 써 두고 있다.
개발 프로세스와 전사적 관리가 중요한 것은 알겠지만, “전체 최적화”라는 미명 하에 “얘들아, 우린 이렇게 한다. 문제 없지? 명세대로 반박하지 말고 진행해”라고 하는 것을 에둘러 말하는 것이다. 결국에 수평적인 프로세스를 지향한다는 린 방법론과 애자일 방법론에서도 권위주의, 그리고 관리자의 냄새가 뚝뚝 묻어난다.
그럼 어떻게 하는 것이 좋을까요?
프로세스 최적화라는 명목은 좋으나, 명목을 위해서 “관리자에게 무소불위의 권력을 쥐어주고” 소위 말하는 인적 자원의 최적화를 하는 것이 좋은 명목인지 모르겠다. 신입의 우스운 방법론이 이해가 되지 않는다면 기술적이고 이론적으로 납득 가능하게 하라고 하면 그럼에도 증명을 성공해 내는 신입은 드물 것이다. 만약 있다고 하면, 그 신입은 MIT 출신의 천재거나 보기 드문 귀재이기 때문에 어차피 발언권을 키워 줘야 한다.
하지만, 그럼에도 불구하고 가끔 괜찮은 의견이 나올 가능성을 노이즈로 취급하고 관리자의 지시 아래 뭉개 버리는 것은 일본 기업에서의 잔재라고 생각한다. 히타치의 3S 같은 것이 신뢰 가능한 측면도 분명히 있지만, 어느 정도는 “히타치니까” 따라 가는 것도 있다고 본다.
결국 우리에게 필요한 것은 “이 나이 먹은 사람이면 잘 하겠지”가 아니고 합리성과 이성적인 판단이다. 그리고, 그것을 위해서는 밀실에 격리한 채 쥐구멍만 뚫어 주는 식의 제약은 이제 지양해야 한다고 생각한다.