MIT Sloan Management Review
유연하고 효율적인 작업을 원하는가! 프로세스 잘게 쪼개 협업 틀 마련하라
넬슨P.리페닝,돈 키퍼(Don Kieffer),제임스 리페닝(James Repenning) | 243호 (2018년 2월 Issue 2)
Article at a Glance
질문
기업은 어떻게 하면 업무에서 민첩성과 효율성이라는 두 마리 토끼를 잡을 수 있을까?
연구를 통해 얻은 해답
- 잘 정의된 일과 불분명한 일의 차이를 구별하라.
- 진척 상황을 좀 더 자주 확인할 수 있도록 전체 프로세스를 더 작은 단위로 세분하라.
- 작업에서 협업이 필요한 지점들을 확인하라.
비즈니스 관련 책들을 살펴보면 점점 가속화하는 기술 및 시장의 변화와 이에 더 잘 적응해야 하는 조직의 역량에 대한 필요성이 거의 빠짐없이 등장한다. 적응력이라는 기업의 필수 조건을 감안할 때 경영과 리더십에 대한 최근 논의에서 ‘애자일(agile)’이라는 단어가 특히 주목을 받는 것은 납득할 만한 일이다.1 제너럴일렉트릭(GE) 같은 대기업부터 아주 작은 스타트업까지 조직들은 새로운 기술 및 변화하는 시장 환경에 대처할 수 있도록 유연하고 빠른 조직이 되고자 애쓴다.2
‘애자일’이란 말은 2001년에 17명의 개발자가 소프트웨어에 대해 논의하면서 처음 사용한 것으로 보인다.3 이들은 새로운 애플리케이션을 개발하기 위해 좀 더 반복적이면서 프로세스라는 틀에 덜 얽매인 접근법을 수십 년에 걸쳐 실험했고 그 경험을 다음과 같은 애자일 선언으로 성문화했다. “우리는 애자일 방식을 실행하고 다른 사람들도 애자일 방식을 사용하도록 도움을 줘서 소프트웨어를 개발하는 더 좋은 방법을 확인해 나가고 있다.” 이제 애자일 방식은 소프트웨어 개발에서 스크럼(scrum)이나 익스트림 프로그래밍(extreme programming), 기능 주도 개발(feature-driven development)같이 매우 다양한 형태로 존재한다.4 의미 있는 결과도 나타났다. 많은 연구를 통해 애자일 소프트웨어 개발 방법이 다른 전통적인 방법들보다 개선 효과가 훨씬 더 크다는 사실이 밝혀졌기 때문이다.5
그렇다면 소프트웨어 이외의 영역에서 애자일은 무엇을 뜻할까? 애자일 방법론을 다른 유형의 일에도 성공적으로 적용할 수 있을까? 애자일 방법론을 지지하는 많은 이(소프트웨어 업계에서 커리어를 시작한 다수)는 긍정적인 반응을 보인다. 또한 애자일 전략의 실행 방법을 제시하는 책과 논문, 블로그 포스트들도 점점 늘고 있다.6 하지만 그에 대한 증거는 아직 부족하고 애자일 방법론 창시자 중 두 명은 기사를 통해 애자일 방법론을 무차별적으로 적용하는 데 경고를 표했다.7 블로그에도 애자일 방법론의 역기능을 지적하는 글로 가득하다.
필자들은 애자일이 우리 조직에 무엇을 의미하는지 이해하려 애쓰는 비즈니스 리더들에게 몇 가지 실질적인 조언을 주고자 좀 다른 접근방식을 취한다. 우리는 연구를 통해 소프트웨어 산업에서 유래한 애자일 방법론을 다른 분야에 적용하는 과정에서 관리자들이 종종 원칙과 방식을 혼동한다는 것을 발견했다. 애자일 방법론이 다른 분야에서도 효과를 발휘하는 것은 그 업무 방식들이 소프트웨어 개발과 관련된 주요 행동 원칙들을 반영하기 때문이다. 하지만 그런 방식들이 소프트웨어 개발을 성공적으로 이끌었다고 해서 다른 상황에서도 어김없이 효과를 발휘한다는 보장은 없다. 일련의 업무 방식을 한 영역에서 다른 영역으로 이전할 때는 먼저 그것이 왜 효과적이었는지 파악한 다음에 그 방식의 근본적인 원칙은 유지하면서 새로운 맥락에 맞게 수정하는 게 핵심이다.
이 아티클의 목적은 소프트웨어 개발에 적용했던 애자일 방법론뿐 아니라 제조업에서 유명한 도요타자동차 생산 시스템의 근간이 된 작업 설계의 주요 원칙들을 이해하는 데 도움을 주는 것이다. 여기서 설명하는 작업 설계의 기본 원칙들을 (필자들이 다이내믹 작업 설계(dynamic work design)라 부르는) 이해하면 당신의 조직에서도 유연하고 효율적인 작업 프로세스를 개발할 수 있다. (‘연구내용’ 참고)
안정성 vs. 불확실성
학자들과 기업 관리자들은 모두 오랫동안 조직은 유연성과 효율성의 장점을 절충해야 한다고 믿었다. 조직 설계에 대한 학문에서 중심이 되는 사상은 상황적합(contingency)이라는 이론인데, 이는 조직 및 그와 결부된 프로세스들이 조직이 전개하는 업무 성격에 맞게 설계돼야 한다는 것이다. 상황적합이론에서 가장 일반적으로 영향을 미치는 변수 중 하나는 주변 환경에 존재하는 불확실성 수준(이는 종종 개념상 혁신이 필요한 이유로 쓰인다)이다. 상황적합이론에 따르면 경쟁 환경과 조직 업무가 모두 안정적이고 이해도가 높은 경우에는 매우 체계적이고 기계적(mechanistic)인 업무 설계가 최고의 성과를 창출할 수 있다. 반대로 계속 조정이 필요한 상당히 불확실한 상황에 처한 조직은 더 유연하고 유기적인 업무 설계를 통해 성과를 높일 수 있다.8
업무 설계에 기계론적 접근법을 적용해야 한다고 주장한 초기 학자는 1911년에 『과학적 관리법(The Principle of Scientific Management)』이란 책을 발표한 프레드릭 윈슬로 테일러(Frederick Winslow Taylor)다.9 테일러가 가진 기본적인 통찰력은 단순했다. 일이라는 것은 규칙적인 반복을 통해 연구하고 개선할 수 있다는 것이다. 따라서 안정적이고 익숙한 환경에서는 반복에 따른 효율성을 활용해서 업무를 설계하는 것이 최선의 옵션이 된다. 예를 들어 현대적 공장에서는 잘 정의된 업무들이 구체적으로 명시돼 있다. 그리고 세심하게 설계하고 규정된 일련의 활동들로 이뤄진 작업이 다음 작업으로 연속적으로 이어진다. 이런 환경에서는 협업이 거의 필요 없다. 안정적이고 반복적인 작업 중심으로 돌아가는 조직은 모든 직원이 지시된 작업 방식을 확실히 이행하도록 위계질서가 강한 경우가 많다. 이런 효율성에는 융통성의 희생이 따른다. 기계적 프로세스 설계는 고도의 규칙성과 형식성 때문에 새로운 요구에 따라 변화를 꾀하기가 어렵기 때문이다. 즉 기계적 설계는 효율적이지만 민첩하지 않다.
그러나 불안정하고 불확실한 환경에서는 작업을 개별적으로 정의하기 어려우므로 조직은 명확하게 정의한 순차적 업무 프로세스에 의존할 수 없다. 예를 들어 상품개발팀은 종종 전례가 거의 없는 도전에 봉착한다. 신제품 개발처럼 예측할 수 없는 환경에서 상황적합이론은 조직이 규칙성과 꼼꼼한 작업 정의보다 교육과 협업 같은 방식에 더 의존해야 한다고 설명한다. 획기적인 제품이나 서비스는 공장 조립라인처럼 설계된 환경에서 나오기 힘들다. 마케팅 전문가들이 제품에 대한 일련의 기본 요건들을 정한 다음 그 내용을 디자이너와 엔지니어에게 전달한다. 하지만 디자이너와 엔지니어들이 그중 기술적으로 가능한 것들과 그렇지 않은 것들을 판단해 나가는 반복적인 단계들을 거치면서 필요 요건들이 진화해 나간다. 결과적으로 효과적인 개발 프로세스를 위해서는 순차적으로 구성된 일련의 단계를 무조건 고수하기보다 필요에 따라 즉각적인 협업을 모색해야 한다.
상황적합이론이 처음으로 발표된 지 50여 년이 흘렀지만 그 기본 통찰력은 아직도 경영 사상에 자주 등장한다. 전사적 품질경영(total quality management)이나 6시그마(Six Sigma), 업무재설계(business process reengineering) 등 프로세스 중심으로 사업을 개선하는 많은 이론은 반복을 통해 작업을 개선할 수 있다는, 테일러가 가진 기본 사상의 연장선에 있다. 최근 각광받고 있는 디자인싱킹(design thinking)도 모호하고 불확실한 임무를 계층적인 작업 설계보다 협업 중심으로 해결하도록 고안된 접근법으로 인식된다.10 일반적으로 상황적합이론은 관리자들에게 일을 설계하는 단순 명료한 접근법을 제시한다. 즉 경쟁 환경의 안정성과 그에 따른 결과를 평가한 다음에 당면한 도전 과제에 맞게 잘 정의된 작업 방식과 협업 방식을 가장 효과적으로 접목하라는 것이다. (‘작업 설계에 대한 전통적 접근법’ 참고.) 해당 작업이 잘 정의된 업무들(이를테면 공장 조립 라인의 과업들처럼)로 구성돼 있다면 이를 순차적 구조로 설계하거나 [그림1]에 있는 좌표의 3사분면(좌표의 왼쪽 아래)인 ‘공장’ 모드로 설계하는 것이 가장 좋다. 반대로 작업이 매우 모호하고 지속적인 상호작용이 필요한 경우(신제품을 개발할 때처럼)에는 협업 중심이나 [그림 1]의 1사분면에 해당하는 ‘스튜디오’ 모드로 설계하는 것이 최선이다.
이 접근법은 작업 설계에 있어 강력한 힘을 발휘하지만 2가지 이유로 아주 만족스럽지는 않다. 먼저 불편한 상충 요소를 만든다는 점이다. 순차적인 공장식 설계에 따라 진행되는 작업은 유연성이 떨어져서 외부 환경에 의한 변화에 대응하기 어렵고 협력적 스튜디오 모드로 진행되는 작업은 효율성이 떨어지는 경우가 많다. 둘째, 잘 정의된 작업과 모호한 작업 중 하나로 완벽히 맞아 떨어지는 유형의 일은 거의 없다. 아주 틀에 박힌 일조차도 의외의 상황이 생기기도 하고, 반대로 새로운 제품이나 서비스를 기획하는 것처럼 아주 새로운 일에도 대개 창의적인 작업 과정을 뒷받침하는 일상적인 분석이나 실험이 필요하기 때문이다. 학문적 이론에도 불구하고 실제 업무는 일상성과 불확실성이 혼재된 형태로 계속 진화해 나간다.
애자일 방법론은 얼핏 보면 일의 스펙트럼에서 협업 쪽에 치우쳐 있는 것 같다. 그러나 필자들의 연구는 이와 다른 해석을 한다. 프로세스와 조직 설계에 대한 종래의 접근법은 상당히 정적이다. 일단 어떤 업무가 설계되면 모든 게 계획했던 대로 진행되리라 암묵적으로 가정하는 것이다. 반대로 작업 설계에 대한 다이내믹한 접근법은 일이라는 것을 실제 조직에서 필연적으로 발생하는 문제와 결핍에 대응해 계속 진화해 나가는 반응으로 본다. 기사의 뒷부분에서 설명하겠지만 애자일 방법론은 전통적으로 행해졌던 순차적인 작업 방식과 협력적인 작업 방식을 유동적으로 활용하는 더 나은 메커니즘을 창출하므로 사실상 이 두 방법을 각각 초월한다. 애자일 방법론은 잘 정의된 공장 모드와 협력적인 스튜디오 모드를 교체해 나가는 메커니즘을 활용해서 효율성과 융통성 사이의 상충 작용을 상당히 줄일 수 있다.
도요타의 다이내믹 작업 디자인
애자일 방법론은 실제로 어떤 식으로 구현될까? 작업 및 조직 설계 방면에서 유명한 도요타의 안돈 코드(Andon cord) 사례를 살펴보자. 도요타의 자동차 조립 라인에서 이행되는 작업은 순차적이고 기계적인 설계의 전형적인 형태다. 과업들은 팔과 손의 움직임과 더불어 각 동작이 언제 이행돼야 하는지를 구체적이고 정확하게 명시한다. 필자들이 최근 도요타의 한 공장을 방문했을 때 그곳에서는 특정 직무에 대한 교육이 진행되고 있었다. 교육은 견습생들이 볼트 4개를(3개도 아니고 5개도 아닌) 동시에 집는 연습으로 시작됐다. 볼트 4개를 꼬박꼬박 집는 데 성공한 견습생만이 다음 동작을 배울 수 있었다. 하지만 테일러가 자긍심을 느낄 만큼 세부 사항에 주의를 기울인다 할지라도 때때로 일은 어긋날 수 있다. 도요타의 작업 설계에서는 어떤 직원이 그런 문제를 발견하면 안돈 코드라 알려진 끈을 당겨서 (혹은 버튼을 눌러서) 생산라인을 멈추고 문제를 해결하도록 돼 있다.
도요타의 관리 문서는 직원들에게 생산라인을 멈출 수 있는 권한을 부여하는 중요성을 부각해 왔고 이는 올바른 견해지만11 이보다 더 중요한 것은 코드를 당긴 후에 어떤 상황이 벌어지는가 하는 것이다. 필자들이 일본 도요타시티에 있는 도요타 공급 업체를 최근 방문했을 때 그들은 현장에서 정해진 시간 안에 작업을 끝내려 안간힘을 쓰고 있는 한 직원을 목격했다. 그녀가 노란색 버튼을 누르자 번쩍거리며 알람이 울려 퍼졌다. (그 공장은 안돈 코드를 작업 공정마다 놓인 노란색 버튼으로 대체한 상태였다.) 그러자 라인 감독자가 바로 와서 그녀가 정해진 프로세스를 이행하는 데 걸림돌이 됐던 문제를 해결하도록 도움을 줬다. 작업자는 1분도 채 안 돼 정상적인 작업 패턴으로 돌아갔고 자신의 목표도 달성했다. 감독자 또한 자리로 돌아가 다른 일들을 처리할 수 있었다.
작업 설계 관점에서 보면 이 짧은 에피소드에서 무슨 일이 벌어진 걸까? 작업자는 처음에 잘 정의된 일을 명확히 명시된 시간 안에 수행하는 ‘공장’ 모드에 따라 직무를 수행하고 있었다. ([그림2] 도요타 공급업체의 다이내믹 작업 설계’에 있는 좌표의 3사분면 참고.) 하지만 그렇게 용의주도하게 설계된 작업에서 뭔가 문제가 발생하자 작업자는 정해진 시간 안에 자신의 임무를 완수할 수 없었다. 일단 문제가 발생하면 작업자에게는 이에 대응하는 2가지 옵션이 있다. 먼저 임시방편을 구하는 옵션이다. 즉 일을 계속할 수 있는 임시 해결책이나 손쉬운 방법을 활용하는 것이다. 하지만 이런 선택은 도리어 역기능을 낳을 가능성이 크다.12 다른 방법으로는 필자들이 목격한 것처럼 버튼을 눌러서 작업을 멈추고 도움을 요청하는 옵션이 있다. 버튼을 눌러 자신을 도와줄 감독관을 부르면 작업 설계 모드를 일시적으로 변경할 수 있다. 이 시스템은 문제 해결에 중점을 둔 좀 더 유기적이고 협력적인 접근법을 위해 기계적이고 순차적인 작업 방식을 잠시 보류한다. 문제가 해결되자 작업자는 원래 임무와 순차적인 작업 설계로 돌아갈 수 있었다.
도요타 생산 시스템이 처음에는 기계적 작업 설계의 궁극적인 형태로 보일 수도 있지만 좀 더 자세히 보면 훨씬 더 역동적인 모습이라는 것을 알 수 있다. 노동자가 안돈 코드를 당기면 시스템은 작업 상태에 따라 2가지 방식을 사실상 변경한다. 일의 성격은 상당히 다르지만 2가지 작업 방식 사이의 그런 교체는 애자일 소프트웨어 개발 방식이 성공할 수 있었던 이유를 이해하는 핵심이 된다.
다이내믹한 작업 설계로서 애자일 방법론
앞서 논의한 것처럼 지난 20년 동안 소프트웨어 개발 방식에는 엄청난 변화가 있었다. 한때는 대다수의 소프트웨어가 폭포수 접근법(waterfall approach)이라 알려진 방식으로 개발됐지만 이후 애자일 방법론이 점차 대중화됐다. 다이내믹 작업 설계 관점에서 보면 폭포수 접근법과 애자일 접근법 사이에는 상당한 차이가 있다.
폭포수 접근법에서 소프트웨어 개발 사이클은 일반적으로 몇 개의 주요 단계들로 나뉜다. 한 프로젝트는 보통 요건 확인 단계, 아키텍처 개발 단계, 세부 코딩 단계, 테스트 및 설치 단계로 구성될 것이다. 폭포수 프로젝트는 보통 3가지의 기본적인 작업 방식 사이를 돌며 진행된다. 첫 번째 방식에서는 많은 시간이 개별적이거나 소그룹을 이뤄 일하는 소프트웨어 설계자와 엔지니어에 의해 소비된다. 그들은 이 단계에 요구되는 것이 무엇이든 완수한다. 두 번째 방식은 보통 주 단위로 발생하는 회의로 설계자와 엔지니어는 프로젝트 회의에 참석하기 위해 개인의 일을 잠시 중단한다. 프로젝트 멤버들은 회의에서 일의 진척도를 보고하고, 상호 호환성을 확인하며, 리더들의 지침에 변화가 있을 경우 자신의 일을 조정한다. 세 번째 방식은 보통 ‘단계별 관문 검사(phase-gate review)’라 부르는데 각 단계의 마지막에 진행되는 한층 더 중요한 검토를 말한다. 고위 리더들은 이 자리에서 프로젝트가 이번 단계를 끝마치고 다음 단계로 넘어갈 준비가 돼 있는지 판단하기 위해 관련 내용을 세부적으로 확인한다. 소프트웨어 이외의 제품을 개발하는 프로젝트 사이클도 보통은 이와 비슷하게 진행된다.13
애자일 개발 프로세스에서 작업을 편성하는 방법은 이와 다르다. 예를 들어 스크럼 접근법14 (애자일 방법론 중 하나)에서는 작업이 몇 가지 주요 단계 대신 여러 가지 짧은 ‘스프린트(sprint, 대개 1∼2주 정도 지속되는 프로그램)’로 나뉜다. 각 스프린트는 규모는 작지만 제대로 작동하는 소프트웨어 하나를 개발하는 데 필요한 모든 작업을 완수하는 데 초점을 맞춘다. 각 스프린트 마지막에는 새로운 기능이 세부 요건들을 충족하는지 평가하기 위해 실제 사용자의 테스트를 거친다.
폭포수 접근방식과 마찬가지로 애자일 방법론도 소프트웨어를 개발할 때 개별 작업, 팀 회의, 고객 리뷰라는 3가지 기본 작업 방식을 채택한다. 그러나 이 작업들이 이행되는 과정에는 큰 차이가 있다. 첫째, 애자일 방법론 지지자들은 매일 회의를 통해 그날의 진척 상황과 다음날 계획, 업무를 진척시키는 데 장애로 인식되는 이슈를 보고하라고 제안한다. 소위 스탠드 업(stand-up) 회의나 스크럼(srcum) 회의처럼 매일 같은 시간에 만나 짧게 논의하는 식으로 이 자리를 통해 개인 작업에서 팀 작업으로 혹은 그 반대로 작업 방식을 변경할 수 있다. 둘째, 애자일 방법론은 각 스프린트가 끝날 무렵에 고객 테스트로 새로 추가된 기능을 평가하라고 권고한다. 마지막은 도요타의 안돈 코드와 비슷한 방식으로, 애자일 방법론에서 파생한 일부 개념에서는 코드 방식으로도 문제가 해결되지 않으면 그 작업을 즉시 전체 팀으로 확대한다. 즉 작업 방식을 개인 작업에서 협력적인 팀 작업으로 변경하는 것이다.
다이내믹 작업 설계 관점에서 보면 애자일 방법론은 폭포수 방법론보다 잠재적으로 2가지 장점을 갖는다. 먼저 폭포수 개발 방법은 팀원들 간이나 팀과 고객 간에 협력적 방식을 활용하는 빈도가 너무 낮다. 개발자가 팀의 확인 없이 1∼2주 동안 혼자서 작업을 하다 보면 실수를 저지르거나 방향을 잘못 잡았더라도 그 결과가 너무 늦게 드러나서 상당한 시간을 소모할 가능성이 있다. 실제로는 개발자들이 그렇게 오래 기다리지 않고 관리자나 팀원들에게 비공식적인 확인을 받는다. 이런 확인 방식이 실용적으로 보일 수도 있지만 팀 전체가 프로젝트 상황에 대한 공통 정보를 공유하지 못한 채 작업을 진행할 수도 있다. 이런 경우에 작업 방식은 좌표의 3사분면인 ‘공장’ 모드에서 불확실한 작업이 순차적으로 조직화되는 4사분면으로 이동하기 시작한다. 이는 비용도 많이 들고 더딘 반복 과정을 낳으므로 필자들은 이를 ‘비효율적인 반복’이라 부른다. (DBR minibox Ⅱ ‘역기능을 낳는 다이내믹 작업 설계’ 참고.) 연구에 따르면 R&D 프로세스에서 이런 작업 방식은 큰 비효율을 낳을 수 있다.15 다음 단계로 넘어가기 위해 고위 임원들과 함께 정기적으로 모여 진척 상황을 검토하는 방법 또한 프로젝트팀 전체가 몇 달간에 걸쳐 일을 했는데 그 결과가 경영진의 기대와 다르다는 것을 너무 늦게 깨닫게 돼 일을 다시 할 위험에 처할 수 있다.
소프트웨어 개발에 애자일 방법론을 활용하면 개발자가 혼자 작업하는 시간의 질도 향상된다. 각 소프트웨어 요소들을 기능성에 초점을 맞춰 개발하면 팀과 고객 모두 1∼2주 만에 사용 가능한 소프트웨어를 접할 수 있으므로 그 소프트웨어가 고객이 원하는 요건에 부합하는지 훨씬 더 쉽게 판단할 수 있다. 반대로 폭포수 접근법의 초기 단계들은 소프트웨어의 필요 요건과 특징들을 긴 리스트로 정리하는 데 치중하며 새롭게 시도하거나 테스트하는 작업은 전혀 없다. 폭포수 방법론을 활용하면 개발 사이클이 거의 끝날 무렵에 프로젝트의 중요한 결함과 결핍을 발견하는 경우가 종종 생긴다. 그러면 결국 값비싼 비용을 치르면서 재작업을 하게 되는데 생각해보면 놀라운 일도 아니다.16
다이내믹 작업 설계 방식 적용하기
도요타 생산 시스템과 애자일 기반의 소프트웨어 개발 방식은 모두 필자들이 좋은 다이내믹 작업 설계라고 부르는 예다. 전통적으로 활용했던 고정적 접근법과 달리 다이내믹 작업 설계는 불가피한 변화를 인식하고 이에 대응하는 메커니즘을 구축한다. 관리자들이 좀 더 개별적인 작업 방식과 협력적인 방식을 유동적으로 활용해야 한다는 사실을 일단 인식하면 그들은 조직의 업무 성격에 맞는 교체 메커니즘을 개발하기 위해 다음 4가지 원칙을 활용할 수 있다.
1. 잘 정의된 일과 불분명한 일을 구별하라. 일단 잘 정의된 일과 불분명한 일을 명확히 분리하는 것부터 시작하라. 이 2가지 유형의 일을 동일한 프로세스로 처리하면 문제가 발생하기 쉽다. (DBR minibox Ⅱ ‘역기능을 낳는 다이내믹 작업 설계’ 참고.) 실무 점검으로 2가지 유형을 구분하는 경우도 있지만 그렇지 않은 경우에는 불분명한 일의 특징적 요소, 즉 반복되는 요소를 살펴보라. 잘 정의된 작업은 릴레이 주자들이 바통을 이어받듯 다음 단계로 넘어갈 수 있다. 일이 제대로 완료됐다면 전 단계로 되돌아갈 필요가 없기 때문이다. 반대로 모호한 작업은 최선의 노력을 다했을지라도 전 단계로 되돌아가는 경우가 종종 생긴다. 어떤 일이 동일한 단계들을 밟으며 몇 번씩 반복되고 있다면 이는 비효율적인 모호함에 부딪쳤다는 신호다.
2. 프로세스를 자주 점검할 수 있도록 더 작은 단위로 세분하라. 애자일 방법론에 대한 모든 거품을 빼면 어떤 작업 프로세스에 있어서나 민첩성(외부 환경의 변화로 인해 일을 조정하고 결함을 해결하는 능력을 의미하는)은 결국 결과물을 평가하는 빈도와 효과로 귀결된다. 도요타 생산 시스템이 탄생하기 이전에 존재했던 전통적 개발 방식이나 폭포수 소프트웨어 개발 방식에서는 평가가 가끔씩 이뤄지고 특별히 효과적이지도 않았다. 그 결과 두 접근법은 외부 환경 변화에 대응하는 속도가 떨어졌고 비싸고 느린 재작업 사이클을 통해서만 원하는 품질을 얻을 수 있다. 반대로 효과적인 평가를 자주 수행하면 작업 프로세스는 높은 변화 적응력을 갖게 되고 결과물의 품질도 빠르게 향상될 것이다. 프로세스를 더욱 민첩하게 만드는 근본적인 레서피는 일의 단위를 더 작게 세분하고 진척 상황도 더 자주 점검하는 것이다.
3. 작업 실무자를 보조하는 사람들을 파악하라. 헬프 체인을 발견하는 일도 중요하다. 헬프 체인이란 직무 담당자를 보조하는 일련의 사람들을 말한다. 생산에서 헬프 체인은 기계 운영자로 시작해서 작업반장, 현장 감독부터 최상위에 있는 공장 관리자까지 포함된다. 소프트웨어 개발에서 헬프 체인은 주로 엔지니어로 시작해서 팀 리더를 거쳐 고위 관리자로 이어지며 궁극적으로는 고객으로 끝난다. 필자들은 해당 작업을 수행하고 지원하는 사람들의 체인을 확인하는 일이 중요하며 그들의 역할과 소속 부서, 담당 직무는 오히려 중요도가 떨어진다고 말한다. 민첩성을 높이기 위해서는 문제가 생겼거나 피드백이 필요할 때 누구를 찾아야 하는지 아는 것이 중요하기 때문이다.
4. 작업을 협업 방식으로 바꾸는 작동 장치와 점검 장치를 도입하라. 헬프 체인을 파악했다면 이를 활성화하는 2가지 기본 메커니즘을 확보해야 한다. 작동 장치(trigger)와 확인 장치(check)다. 작동 장치는 결함이나 서로 어긋난 부분을 드러내서 작업을 공장 모드에서 협력 모드로 바꾸는 테스트를 말한다. 앞서 언급한 도요타 사례에서 한 공장 근로자는 조립 라인에서 자신의 임무를 제시간에 완수할 수 없었고 이는 그녀가 버튼을 눌러 감독자의 도움을 받는 작동 장치가 됐다. 점검 장치는 작업을 좀 더 협력적인 방식으로 바꿀 수 있도록 미리 정한 시점과 관계가 있다. 애자일 소프트웨어 개발에서 작업 방식의 변화는 팀원들이 프로젝트의 진척 상태를 점검하기 위해 매일 갖는 스탠드업 미팅에서 일어난다. 한 스프린트를 완수하면 두 번째 점검 기회가 생기는데 이때는 고객과 함께 프로젝트 상황을 확인한다.
구매 관리 개선하기
다이내믹 작업 설계 방식을 회사에 채택하면 효율성과 융통성 모두에서 성과를 크게 높일 수 있다. ‘리파인코(RefineCo)’라는 회사의 사례를 살펴보자. 이 회사는 미국에 여러 정유 공장 및 유통 터미널을 갖고 있다. 그러나 리파인코의 구매 조직은 어떤 기준을 들이대도 경쟁력이 떨어졌다. 회사는 비슷한 부품과 서비스를 경쟁사보다 더 높은 가격으로 구입하고 있었으며 구매부에서 발생하는 간접비 또한 업계 평균보다 높았다. 이보다 더 골칫거리는 정유공장이 공급업체에 비용을 제때 지급하지 못해 ‘거래 보류’ 상태에 처하고 이로 인해 중요한 부품을 공급받지 못하는 경우였다. 고위 임원부터 물품을 선적하거나 입고시키는 직원까지 구매 시스템과 관계된 모든 이들은 좌절감에 빠졌다. 리파인코의 각 공장에 있는 구매 시스템은 대략 이런 식으로 작동했다. 외부 업체로부터 상품이나 서비스를 구매하려는 직원은 전자 구매 시스템에 필요 사항을 입력한다. 그러면 전자 시스템이 구매 본부에 이를 요청서 형태로 전송한다. 구매 본부에 속한 직원은 요청서를 검토하고 구매 주문서를 발주한다. 그러면 주문서가 공급업체로 전송될 것이다. 주문한 제품이 정유 공장에 입고되거나 요청한 서비스가 완료되면 패킹 슬립(packing slip, 업체가 보통 상품과 함께 보내는 상품 정보가 수록된 확인서-역주)이나 서비스 확인서가 생성되고 그 내용이 구매 시스템에 입력된다. 이후 공급업체는 인보이스를 발송하고 이 또한 시스템에 입력될 것이다. 그러면 이제 시스템은 모든 일들이 올바로 처리됐는지 확인하기 위해 3자 간 매칭 작업을 수행한다. 즉 구매 주문서와 공급업체에서 받은 확인서, 인보이스 내용이 서로 일치하는지 확인하는 것이다. 내용이 서로 일치하지 않는 인보이스는 시스템에서 처리될 수 없으므로 불일치하는 내용이 해결될 때까지 공급업체에 비용이 지급되지 않는다.
이렇게 일치하지 않는 내용을 해결하는 일은 정유 공장의 구매부 직원들이 담당했다. 불행히도 리파인코에서 구입한 제품이나 서비스 중에는 3자 간 매칭을 통과하지 못한 경우가 허다했다. 그 결과 구매부는 과중한 업무에 시달렸을 뿐 아니라 공급업체들의 불만도 높아졌다. 정유 공장은 성공한 대기업에 속해 있었지만 인보이스 비용을 제때 지급하지 못해 공급업체들로부터 거래 중지를 당하는 경우가 종종 발생했고 구매부 직원들은 그 때문에 업무를 진행하고 공장을 안전하게 운영하는 데 고초를 겪었다. 구매부의 정규직 직원들은 하루에 10시간 이상 일하는 경우가 속출했고 잔업을 보조할 수 있는 계약직 직원도 고용했지만 업무는 점점 더 쌓여만 갔다.
구매부 직원들 대부분은 ‘과중한 업무량’과 엉망이 된 시스템에 큰 불만을 표출했다. 그 누구도 직원을 더 뽑는 방법 이외에는 상황을 개선할 여지를 발견하지 못했다. 리파인코 프로젝트에서 결정적 전환점은 오랫동안 구매부에 몸담고 있던 직원 한 명의 얘기를 들으면서 시작됐다. 그의 말에 따르면 좋은 구매 요청서는 ‘필요한 정보를 모두’ 담고 있어서 5∼10분 만에 공식적인 구매 주문서로 전환될 수 있었다. 그러나 처리하기 어려운 요청서는 핵심 정보가 몇 개씩 누락돼 있어서 구매 본부 직원은 제품을 요청한 부서 및 공급업체와 계속 e메일을 주고받아야 하고, 이로 인해 주문서를 처리하는 데 한두 시간이 걸린다는 얘기였다. 그런 노력에도 불구하고 처리하기 어려운 구매 주문서는 3자 간 매칭에 실패해서 시스템에서 반송되는 경우가 많았다. 더군다나 조사를 해보니 구매 주문 시스템은 이렇게 반송된 주문서들로 가득 차 있었고 구매부 직원들은 대부분의 업무 시간을 잔업을 해치우는 데 할애하고 있었다. 이 회사의 구매 시스템은 전형적인 ‘신속한 일 처리’와 ‘불 끄기’의 함정에 빠져 있었다. 진행 중에 있는 구매 주문서가 너무 많다 보니 어느 하나도 빨리 처리되는 법이 없었다. 처리 시간이 오래 걸리면서 고객들의 불만은 높아졌고 주문과 비용 지급에 대해 문의하는 공급업체들의 불평도 속출했다. 그 결과 구매부 직원들은 불만의 목소리가 가장 큰 고객이나 공급업체에 대응하느라 일의 우선순위를 계속해서 바꿀 수밖에 없었다.
필자들의 첫 번째 통찰력은 구매부 직원들이 순차적인 ‘공장’ 방식과 협력적인 ‘스튜디오’ 방식이 필요한 2가지 다른 유형의 업무를 담당하고 있다는 사실을 파악했다. 구매를 요청한 제품이 표준 아이템이고 필요한 모든 정보가 들어온 경우에는 협업 없이도 담당자 한 명이 쉽게 요청서를 처리할 수 있었다. 일단 구매 주문서가 입력되면 공장 조립라인 위에 놓인 아이템처럼 시스템이 처리하는 대로만 따라가면 됐다. 그러나 표준 아이템인 경우에도 요청서에 올바른 정보가 있어야만 시스템에 맡길 수 있었다. 그렇지 않은 경우에 구매 주문서를 발급하려면 보통
e메일을 통해 과정이 여러 번 반복될 수밖에 없었다. 이에 따라 구매 본부는 좋은 구매 요청서를 이루는 간략한 점검 목록을 개발했다. 표준 주문서가 항상 올바른 정보와 함께 입력될 수 있도록 정한 방책이었다. 여러 부서에서 점검 목록을 활용할 수 있도록 인센티브도 생각해냈다. 오전 7시 이전에 들어온 요청서에 필요한 정보가 전부 채워진 경우에는 당일 오후 2시까지는 구매 주문서를 발급해 주겠다는 약속이었다. 당시에는 거의 모든 요청서가 ‘미비 서류’로 처리됐기 때문에 주문서가 당일 처리된다는 것은 있을 수 없는 일이었다. 또한 구매부는 생산성을 개선할 수 있는 단순한 작동 장치도 개발했다. 점검 목록에 있는 정보가 누락된 구매 주문서는 즉시 요청 부서로 반송하기로 했다.
두 번째 통찰력은 모든 요청서를 공장 방식으로 처리할 수 없다는 점이었다. 기존 시스템에서는 상품 구매를 요청한 직원이나 구매부 직원이나 표준 요청서와 신규 요청서의 차이를 구분하지 못했다. 그래서 신제품이나 새로운 서비스에 대한 구매 요청이 들어오면 구매부 직원들은 보통 이를 처리하는 과정에서 필요한 정보를 전부 얻기 위해 며칠씩 요청 직원과 e메일을 계속해서 교환해야 했다. 구매부 직원이 필요한 정보를 얻지 못한 경우에는 대개 자신이 할 수 있는 최선의 추측으로 불완전하거나 잘못된 정보를 채운 주문서를 발급했다. 이 경우 정확히 어떤 상품을 보내야 할지 확신이 서지 않는 공급업체는 또다시 구매 본부 직원과 전화나 e메일을 교환할 수밖에 없었다. 결국 리파인코의 구매 프로세스는 필자들이 개발한 좌표의 4사분면에 자리를 잡게 됐다. 모호한 작업을 순차적인 공장 방식으로 처리하려다 보니 일이 더디고 값비싼 반복 과정이 발생했기 때문이다.
복잡한 구매 주문서를 처리하는 데 협력적인 스튜디오 방식을 도입하기 위해서는 작업 설계에 2가지 변화가 필요했다. 먼저 구매부는 명확한 작동 장치를 개발했다. 구매를 요청한 상품이 표준 물품이 아니라면 별도의 파일로 구분해서 즉시 처리하지 않았다. 그리고 매일 오후 2시에 구매부 직원들이 복잡한 요청서를 함께 처리하기 위해 한데 모였다. 협력적으로(스튜디오 모드로) 업무를 처리하자 추가 개입 없이도 복잡한 주문서 대부분을 처리할 수 있었다. 부서원 중 누군가는 비슷한 주문서를 이전에 본 적이 있었기 때문이다. 게다가 모두가 얼굴을 맞대고 회의를 하는 편이 끊임없이 e메일을 교환하는 것보다 훨씬 더 효율적이었다. 추가 정보가 필요한 경우에도 e메일을 보내기보다는 2시 이후에 전화 일정을 잡아서 끊임없이 이어지는 e메일로 발생한 비용을 줄일 수 있었다.
이 2가지 변화는 상당한 효과를 냈다. 표준 주문서에 공장 작업 방식을 도입한 결과 구매부 직원들은 ‘7시 이전에 들어온 요청서는 2시까지 내 보낸다’는 약속을 지킬 수 있었다. 그리고 구매를 요청한 직원들도 구매부에 호의를 갖게 됐다. 오후에는 스튜디오 모드로 업무를 처리한 것도 복잡한 요청서의 처리 속도를 높이는 계기가 됐다. 이 2가지 변화를 통해 구매부는 복잡한 요청서들을 처리하게 됐을 뿐 아니라 미처리된 구매 요청서로 인해 발생한 잔업을 해결하는 데 스튜디오 모드를 활용할 수 있을 만큼 충분한 여유도 갖게 됐다. 이렇게 효율성이 높아진 구매부는 정규직 직원 2명에 상응하는 인력을 줄이는 동시에 더 안정적인 서비스를 훨씬 더 빠른 속도로 제공하게 됐다. 회사는 프로세스를 개선하면서 얻은 통찰력을 미국 내 다른 공장에도 도입했다. 이 기사를 작성하는 현재 기준으로 리파인코는 인보이스의 90% 이상을 정해진 시간 내에 지급하고 있으며 그 결과 공급업체들의 만족도도 전보다 훨씬 높아졌다.
모범 사례 찾기
관리자들과 컨설턴트들은 종종 모범사례를 찾는 데 집착한다. 선도 기업들을 경쟁자들 사이에서 돋보이게 만든 활동들을 찾는 것이다. 이런 탐색 작업을 하는 이유는 일단 모범 사례를 확인하면 다른 조직에도 적용해서 비슷한 성과를 낳을 수 있다고 믿기 때문이다. 분명 어느 정도는 타당한 견해지만 이를 뒷받침하는 증거는 확실히 엇갈린다. 새로운 기법과 관행을 도입하려고 애쓰지만 모범 사례와 비슷한 성과를 경험하는 조직은 드물기 때문이다. 많은 업종에서 상위에 군림하는 기업들과 중간층을 형성하는 기업들의 실적 차이는 좁히기 어렵다. 간격을 메우기 힘든 주된 원인은 조직이라는 것이 사람과 기술, 그리고 어떤 상황에는 효과적이지만 또 다른 상황에는 효과적이지 못한 일련의 도구와 관행으로 복잡하게 구성돼 있기 때문이다. 두 경쟁사가 바로 옆 건물에 위치해 있을지라도 상황은 마찬가지다.
모범 사례는 이를 채택하려는 조직의 근본적인 행동 방식이 그것을 활용하는 조직의 행동 방식과 일치할 때 ‘최고’의 효과를 낸다. 도요타를 유명하게 만든 안돈 코드와 그 효과를 더 높이는 지역 중심의 문제 해결 방식은 효율성을 통해 효과를 발휘한다. 또한 그 효율성은 개인의 반복적인 훈련과 협력적 문제해결 방식에 따른 혁신을 통해 창출된다. 반대로 애자일 개발 방식은 잦은 팀 회의와 고객과의 상호작용을 통해 소프트웨어 엔지니어의 창의성을 발휘할 때 제대로 작동한다. 더 일반적으로 말해서 조직은 결함과 문제를 더 빨리 발견할수록 적응력을 높일 수 있다. 상황에 맞게 다이내믹한 접근법을 취하고 이를 작동 장치와 점검 장치로 뒷받침하면 조직의 업무 환경에서 민첩성을 높이는 업무 방식들을 효과적으로 모색하는 길을 열 수 있다.
번역 ｜김성아 dazzlingkim@gmail.com
편집자주
이 글은 MIT 슬론 매니지먼트 리뷰(SMR) 2017년 가을 호에 실린 ‘A New Approach to Designing Work’를 번역한 것입니다.
넬슨 P. 리페닝·돈 키퍼·제임스 리페닝
넬슨 P. 리페닝(Nelson P. Repenning)은 매사추세츠주 케임브리지에 있는 MIT 슬론 경영대에서 시스템다이내믹스 및 조직연구 분야의 경영학 석좌교수로 있으면서 리더십과 특별 프로젝트 부문의 부학장 및 MIT 리더십센터의 학부장을 겸임하고 있다. 돈 키퍼(Don Kieffer)는 MIT 슬론 경영대학원의 오퍼레이션 관리 부교수이자 케임브리지에 있는 컨설팅 회사인 시프트기어워크디자인(ShiftGear Work Design)의 설립자다. 제임스 리페닝(James Repenning)은 시프트기어워크디자인의 매니징 파트너다. 이 기사에 의견이 있는 분은 http://sloanreview.mit.edu/x/59234에 접속해 남겨 주시기 바란다.
질문
기업은 어떻게 하면 업무에서 민첩성과 효율성이라는 두 마리 토끼를 잡을 수 있을까?
연구를 통해 얻은 해답
- 잘 정의된 일과 불분명한 일의 차이를 구별하라.
- 진척 상황을 좀 더 자주 확인할 수 있도록 전체 프로세스를 더 작은 단위로 세분하라.
- 작업에서 협업이 필요한 지점들을 확인하라.
비즈니스 관련 책들을 살펴보면 점점 가속화하는 기술 및 시장의 변화와 이에 더 잘 적응해야 하는 조직의 역량에 대한 필요성이 거의 빠짐없이 등장한다. 적응력이라는 기업의 필수 조건을 감안할 때 경영과 리더십에 대한 최근 논의에서 ‘애자일(agile)’이라는 단어가 특히 주목을 받는 것은 납득할 만한 일이다.1 제너럴일렉트릭(GE) 같은 대기업부터 아주 작은 스타트업까지 조직들은 새로운 기술 및 변화하는 시장 환경에 대처할 수 있도록 유연하고 빠른 조직이 되고자 애쓴다.2
닫기‘애자일’이란 말은 2001년에 17명의 개발자가 소프트웨어에 대해 논의하면서 처음 사용한 것으로 보인다.3 이들은 새로운 애플리케이션을 개발하기 위해 좀 더 반복적이면서 프로세스라는 틀에 덜 얽매인 접근법을 수십 년에 걸쳐 실험했고 그 경험을 다음과 같은 애자일 선언으로 성문화했다. “우리는 애자일 방식을 실행하고 다른 사람들도 애자일 방식을 사용하도록 도움을 줘서 소프트웨어를 개발하는 더 좋은 방법을 확인해 나가고 있다.” 이제 애자일 방식은 소프트웨어 개발에서 스크럼(scrum)이나 익스트림 프로그래밍(extreme programming), 기능 주도 개발(feature-driven development)같이 매우 다양한 형태로 존재한다.4 의미 있는 결과도 나타났다. 많은 연구를 통해 애자일 소프트웨어 개발 방법이 다른 전통적인 방법들보다 개선 효과가 훨씬 더 크다는 사실이 밝혀졌기 때문이다.5
그렇다면 소프트웨어 이외의 영역에서 애자일은 무엇을 뜻할까? 애자일 방법론을 다른 유형의 일에도 성공적으로 적용할 수 있을까? 애자일 방법론을 지지하는 많은 이(소프트웨어 업계에서 커리어를 시작한 다수)는 긍정적인 반응을 보인다. 또한 애자일 전략의 실행 방법을 제시하는 책과 논문, 블로그 포스트들도 점점 늘고 있다.6 하지만 그에 대한 증거는 아직 부족하고 애자일 방법론 창시자 중 두 명은 기사를 통해 애자일 방법론을 무차별적으로 적용하는 데 경고를 표했다.7 블로그에도 애자일 방법론의 역기능을 지적하는 글로 가득하다.
필자들은 애자일이 우리 조직에 무엇을 의미하는지 이해하려 애쓰는 비즈니스 리더들에게 몇 가지 실질적인 조언을 주고자 좀 다른 접근방식을 취한다. 우리는 연구를 통해 소프트웨어 산업에서 유래한 애자일 방법론을 다른 분야에 적용하는 과정에서 관리자들이 종종 원칙과 방식을 혼동한다는 것을 발견했다. 애자일 방법론이 다른 분야에서도 효과를 발휘하는 것은 그 업무 방식들이 소프트웨어 개발과 관련된 주요 행동 원칙들을 반영하기 때문이다. 하지만 그런 방식들이 소프트웨어 개발을 성공적으로 이끌었다고 해서 다른 상황에서도 어김없이 효과를 발휘한다는 보장은 없다. 일련의 업무 방식을 한 영역에서 다른 영역으로 이전할 때는 먼저 그것이 왜 효과적이었는지 파악한 다음에 그 방식의 근본적인 원칙은 유지하면서 새로운 맥락에 맞게 수정하는 게 핵심이다.
이 아티클의 목적은 소프트웨어 개발에 적용했던 애자일 방법론뿐 아니라 제조업에서 유명한 도요타자동차 생산 시스템의 근간이 된 작업 설계의 주요 원칙들을 이해하는 데 도움을 주는 것이다. 여기서 설명하는 작업 설계의 기본 원칙들을 (필자들이 다이내믹 작업 설계(dynamic work design)라 부르는) 이해하면 당신의 조직에서도 유연하고 효율적인 작업 프로세스를 개발할 수 있다. (‘연구내용’ 참고)
| DBR mini box I 연구내용 필자들이 다이내믹 작업 설계에 대한 방법론을 연구한 것은 그들이 할리데이비슨(Harley Davidson)에서 생산과 제품개발 역량에 대한 개선 방법을 모색했던 20여 년 전 시작됐다. 당시 필자 중 한 명인 돈 키퍼는 할리데이비슨이 추진하고 있던 막대한 규모의 엔진 개발 프로젝트를 이끌고 있었고 또 다른 저자인 넬슨 리페닝은 신제품 개발이 실패하는 원인에 대한 연구를 수행하고 있었다. 필자들은 그 후 수십 년간 행동 연구 원칙들을 바탕으로 작업 설계를 개선하려는 조직들을 보조해 왔다. 이런 기업 프로젝트와 더불어 기초 사회과학을 토대로 조직의 개입이 제대로 작동하거나 작동하지 않는 이유를 이론적으로 구축하는 작업도 주기적으로 진행해 나갔다. 필자들은 수년간 석유, 가스, 소프트웨어, 유전자 서열 등을 포함한 여러 분야에서 수십 건의 프로젝트를 수행했다. 또한 그들이 가르치는 MIT 강의를 수강하는 임원들이 추진한 1000여 개의 작업 설계 프로젝트도 감독했다. |
안정성 vs. 불확실성
학자들과 기업 관리자들은 모두 오랫동안 조직은 유연성과 효율성의 장점을 절충해야 한다고 믿었다. 조직 설계에 대한 학문에서 중심이 되는 사상은 상황적합(contingency)이라는 이론인데, 이는 조직 및 그와 결부된 프로세스들이 조직이 전개하는 업무 성격에 맞게 설계돼야 한다는 것이다. 상황적합이론에서 가장 일반적으로 영향을 미치는 변수 중 하나는 주변 환경에 존재하는 불확실성 수준(이는 종종 개념상 혁신이 필요한 이유로 쓰인다)이다. 상황적합이론에 따르면 경쟁 환경과 조직 업무가 모두 안정적이고 이해도가 높은 경우에는 매우 체계적이고 기계적(mechanistic)인 업무 설계가 최고의 성과를 창출할 수 있다. 반대로 계속 조정이 필요한 상당히 불확실한 상황에 처한 조직은 더 유연하고 유기적인 업무 설계를 통해 성과를 높일 수 있다.8
업무 설계에 기계론적 접근법을 적용해야 한다고 주장한 초기 학자는 1911년에 『과학적 관리법(The Principle of Scientific Management)』이란 책을 발표한 프레드릭 윈슬로 테일러(Frederick Winslow Taylor)다.9 테일러가 가진 기본적인 통찰력은 단순했다. 일이라는 것은 규칙적인 반복을 통해 연구하고 개선할 수 있다는 것이다. 따라서 안정적이고 익숙한 환경에서는 반복에 따른 효율성을 활용해서 업무를 설계하는 것이 최선의 옵션이 된다. 예를 들어 현대적 공장에서는 잘 정의된 업무들이 구체적으로 명시돼 있다. 그리고 세심하게 설계하고 규정된 일련의 활동들로 이뤄진 작업이 다음 작업으로 연속적으로 이어진다. 이런 환경에서는 협업이 거의 필요 없다. 안정적이고 반복적인 작업 중심으로 돌아가는 조직은 모든 직원이 지시된 작업 방식을 확실히 이행하도록 위계질서가 강한 경우가 많다. 이런 효율성에는 융통성의 희생이 따른다. 기계적 프로세스 설계는 고도의 규칙성과 형식성 때문에 새로운 요구에 따라 변화를 꾀하기가 어렵기 때문이다. 즉 기계적 설계는 효율적이지만 민첩하지 않다.
그러나 불안정하고 불확실한 환경에서는 작업을 개별적으로 정의하기 어려우므로 조직은 명확하게 정의한 순차적 업무 프로세스에 의존할 수 없다. 예를 들어 상품개발팀은 종종 전례가 거의 없는 도전에 봉착한다. 신제품 개발처럼 예측할 수 없는 환경에서 상황적합이론은 조직이 규칙성과 꼼꼼한 작업 정의보다 교육과 협업 같은 방식에 더 의존해야 한다고 설명한다. 획기적인 제품이나 서비스는 공장 조립라인처럼 설계된 환경에서 나오기 힘들다. 마케팅 전문가들이 제품에 대한 일련의 기본 요건들을 정한 다음 그 내용을 디자이너와 엔지니어에게 전달한다. 하지만 디자이너와 엔지니어들이 그중 기술적으로 가능한 것들과 그렇지 않은 것들을 판단해 나가는 반복적인 단계들을 거치면서 필요 요건들이 진화해 나간다. 결과적으로 효과적인 개발 프로세스를 위해서는 순차적으로 구성된 일련의 단계를 무조건 고수하기보다 필요에 따라 즉각적인 협업을 모색해야 한다.
상황적합이론이 처음으로 발표된 지 50여 년이 흘렀지만 그 기본 통찰력은 아직도 경영 사상에 자주 등장한다. 전사적 품질경영(total quality management)이나 6시그마(Six Sigma), 업무재설계(business process reengineering) 등 프로세스 중심으로 사업을 개선하는 많은 이론은 반복을 통해 작업을 개선할 수 있다는, 테일러가 가진 기본 사상의 연장선에 있다. 최근 각광받고 있는 디자인싱킹(design thinking)도 모호하고 불확실한 임무를 계층적인 작업 설계보다 협업 중심으로 해결하도록 고안된 접근법으로 인식된다.10 일반적으로 상황적합이론은 관리자들에게 일을 설계하는 단순 명료한 접근법을 제시한다. 즉 경쟁 환경의 안정성과 그에 따른 결과를 평가한 다음에 당면한 도전 과제에 맞게 잘 정의된 작업 방식과 협업 방식을 가장 효과적으로 접목하라는 것이다. (‘작업 설계에 대한 전통적 접근법’ 참고.) 해당 작업이 잘 정의된 업무들(이를테면 공장 조립 라인의 과업들처럼)로 구성돼 있다면 이를 순차적 구조로 설계하거나 [그림1]에 있는 좌표의 3사분면(좌표의 왼쪽 아래)인 ‘공장’ 모드로 설계하는 것이 가장 좋다. 반대로 작업이 매우 모호하고 지속적인 상호작용이 필요한 경우(신제품을 개발할 때처럼)에는 협업 중심이나 [그림 1]의 1사분면에 해당하는 ‘스튜디오’ 모드로 설계하는 것이 최선이다.
이 접근법은 작업 설계에 있어 강력한 힘을 발휘하지만 2가지 이유로 아주 만족스럽지는 않다. 먼저 불편한 상충 요소를 만든다는 점이다. 순차적인 공장식 설계에 따라 진행되는 작업은 유연성이 떨어져서 외부 환경에 의한 변화에 대응하기 어렵고 협력적 스튜디오 모드로 진행되는 작업은 효율성이 떨어지는 경우가 많다. 둘째, 잘 정의된 작업과 모호한 작업 중 하나로 완벽히 맞아 떨어지는 유형의 일은 거의 없다. 아주 틀에 박힌 일조차도 의외의 상황이 생기기도 하고, 반대로 새로운 제품이나 서비스를 기획하는 것처럼 아주 새로운 일에도 대개 창의적인 작업 과정을 뒷받침하는 일상적인 분석이나 실험이 필요하기 때문이다. 학문적 이론에도 불구하고 실제 업무는 일상성과 불확실성이 혼재된 형태로 계속 진화해 나간다.
애자일 방법론은 얼핏 보면 일의 스펙트럼에서 협업 쪽에 치우쳐 있는 것 같다. 그러나 필자들의 연구는 이와 다른 해석을 한다. 프로세스와 조직 설계에 대한 종래의 접근법은 상당히 정적이다. 일단 어떤 업무가 설계되면 모든 게 계획했던 대로 진행되리라 암묵적으로 가정하는 것이다. 반대로 작업 설계에 대한 다이내믹한 접근법은 일이라는 것을 실제 조직에서 필연적으로 발생하는 문제와 결핍에 대응해 계속 진화해 나가는 반응으로 본다. 기사의 뒷부분에서 설명하겠지만 애자일 방법론은 전통적으로 행해졌던 순차적인 작업 방식과 협력적인 작업 방식을 유동적으로 활용하는 더 나은 메커니즘을 창출하므로 사실상 이 두 방법을 각각 초월한다. 애자일 방법론은 잘 정의된 공장 모드와 협력적인 스튜디오 모드를 교체해 나가는 메커니즘을 활용해서 효율성과 융통성 사이의 상충 작용을 상당히 줄일 수 있다.
도요타의 다이내믹 작업 디자인
애자일 방법론은 실제로 어떤 식으로 구현될까? 작업 및 조직 설계 방면에서 유명한 도요타의 안돈 코드(Andon cord) 사례를 살펴보자. 도요타의 자동차 조립 라인에서 이행되는 작업은 순차적이고 기계적인 설계의 전형적인 형태다. 과업들은 팔과 손의 움직임과 더불어 각 동작이 언제 이행돼야 하는지를 구체적이고 정확하게 명시한다. 필자들이 최근 도요타의 한 공장을 방문했을 때 그곳에서는 특정 직무에 대한 교육이 진행되고 있었다. 교육은 견습생들이 볼트 4개를(3개도 아니고 5개도 아닌) 동시에 집는 연습으로 시작됐다. 볼트 4개를 꼬박꼬박 집는 데 성공한 견습생만이 다음 동작을 배울 수 있었다. 하지만 테일러가 자긍심을 느낄 만큼 세부 사항에 주의를 기울인다 할지라도 때때로 일은 어긋날 수 있다. 도요타의 작업 설계에서는 어떤 직원이 그런 문제를 발견하면 안돈 코드라 알려진 끈을 당겨서 (혹은 버튼을 눌러서) 생산라인을 멈추고 문제를 해결하도록 돼 있다.
도요타의 관리 문서는 직원들에게 생산라인을 멈출 수 있는 권한을 부여하는 중요성을 부각해 왔고 이는 올바른 견해지만11 이보다 더 중요한 것은 코드를 당긴 후에 어떤 상황이 벌어지는가 하는 것이다. 필자들이 일본 도요타시티에 있는 도요타 공급 업체를 최근 방문했을 때 그들은 현장에서 정해진 시간 안에 작업을 끝내려 안간힘을 쓰고 있는 한 직원을 목격했다. 그녀가 노란색 버튼을 누르자 번쩍거리며 알람이 울려 퍼졌다. (그 공장은 안돈 코드를 작업 공정마다 놓인 노란색 버튼으로 대체한 상태였다.) 그러자 라인 감독자가 바로 와서 그녀가 정해진 프로세스를 이행하는 데 걸림돌이 됐던 문제를 해결하도록 도움을 줬다. 작업자는 1분도 채 안 돼 정상적인 작업 패턴으로 돌아갔고 자신의 목표도 달성했다. 감독자 또한 자리로 돌아가 다른 일들을 처리할 수 있었다.
작업 설계 관점에서 보면 이 짧은 에피소드에서 무슨 일이 벌어진 걸까? 작업자는 처음에 잘 정의된 일을 명확히 명시된 시간 안에 수행하는 ‘공장’ 모드에 따라 직무를 수행하고 있었다. ([그림2] 도요타 공급업체의 다이내믹 작업 설계’에 있는 좌표의 3사분면 참고.) 하지만 그렇게 용의주도하게 설계된 작업에서 뭔가 문제가 발생하자 작업자는 정해진 시간 안에 자신의 임무를 완수할 수 없었다. 일단 문제가 발생하면 작업자에게는 이에 대응하는 2가지 옵션이 있다. 먼저 임시방편을 구하는 옵션이다. 즉 일을 계속할 수 있는 임시 해결책이나 손쉬운 방법을 활용하는 것이다. 하지만 이런 선택은 도리어 역기능을 낳을 가능성이 크다.12 다른 방법으로는 필자들이 목격한 것처럼 버튼을 눌러서 작업을 멈추고 도움을 요청하는 옵션이 있다. 버튼을 눌러 자신을 도와줄 감독관을 부르면 작업 설계 모드를 일시적으로 변경할 수 있다. 이 시스템은 문제 해결에 중점을 둔 좀 더 유기적이고 협력적인 접근법을 위해 기계적이고 순차적인 작업 방식을 잠시 보류한다. 문제가 해결되자 작업자는 원래 임무와 순차적인 작업 설계로 돌아갈 수 있었다.
도요타 생산 시스템이 처음에는 기계적 작업 설계의 궁극적인 형태로 보일 수도 있지만 좀 더 자세히 보면 훨씬 더 역동적인 모습이라는 것을 알 수 있다. 노동자가 안돈 코드를 당기면 시스템은 작업 상태에 따라 2가지 방식을 사실상 변경한다. 일의 성격은 상당히 다르지만 2가지 작업 방식 사이의 그런 교체는 애자일 소프트웨어 개발 방식이 성공할 수 있었던 이유를 이해하는 핵심이 된다.
다이내믹한 작업 설계로서 애자일 방법론
앞서 논의한 것처럼 지난 20년 동안 소프트웨어 개발 방식에는 엄청난 변화가 있었다. 한때는 대다수의 소프트웨어가 폭포수 접근법(waterfall approach)이라 알려진 방식으로 개발됐지만 이후 애자일 방법론이 점차 대중화됐다. 다이내믹 작업 설계 관점에서 보면 폭포수 접근법과 애자일 접근법 사이에는 상당한 차이가 있다.
폭포수 접근법에서 소프트웨어 개발 사이클은 일반적으로 몇 개의 주요 단계들로 나뉜다. 한 프로젝트는 보통 요건 확인 단계, 아키텍처 개발 단계, 세부 코딩 단계, 테스트 및 설치 단계로 구성될 것이다. 폭포수 프로젝트는 보통 3가지의 기본적인 작업 방식 사이를 돌며 진행된다. 첫 번째 방식에서는 많은 시간이 개별적이거나 소그룹을 이뤄 일하는 소프트웨어 설계자와 엔지니어에 의해 소비된다. 그들은 이 단계에 요구되는 것이 무엇이든 완수한다. 두 번째 방식은 보통 주 단위로 발생하는 회의로 설계자와 엔지니어는 프로젝트 회의에 참석하기 위해 개인의 일을 잠시 중단한다. 프로젝트 멤버들은 회의에서 일의 진척도를 보고하고, 상호 호환성을 확인하며, 리더들의 지침에 변화가 있을 경우 자신의 일을 조정한다. 세 번째 방식은 보통 ‘단계별 관문 검사(phase-gate review)’라 부르는데 각 단계의 마지막에 진행되는 한층 더 중요한 검토를 말한다. 고위 리더들은 이 자리에서 프로젝트가 이번 단계를 끝마치고 다음 단계로 넘어갈 준비가 돼 있는지 판단하기 위해 관련 내용을 세부적으로 확인한다. 소프트웨어 이외의 제품을 개발하는 프로젝트 사이클도 보통은 이와 비슷하게 진행된다.13
애자일 개발 프로세스에서 작업을 편성하는 방법은 이와 다르다. 예를 들어 스크럼 접근법14 (애자일 방법론 중 하나)에서는 작업이 몇 가지 주요 단계 대신 여러 가지 짧은 ‘스프린트(sprint, 대개 1∼2주 정도 지속되는 프로그램)’로 나뉜다. 각 스프린트는 규모는 작지만 제대로 작동하는 소프트웨어 하나를 개발하는 데 필요한 모든 작업을 완수하는 데 초점을 맞춘다. 각 스프린트 마지막에는 새로운 기능이 세부 요건들을 충족하는지 평가하기 위해 실제 사용자의 테스트를 거친다.
폭포수 접근방식과 마찬가지로 애자일 방법론도 소프트웨어를 개발할 때 개별 작업, 팀 회의, 고객 리뷰라는 3가지 기본 작업 방식을 채택한다. 그러나 이 작업들이 이행되는 과정에는 큰 차이가 있다. 첫째, 애자일 방법론 지지자들은 매일 회의를 통해 그날의 진척 상황과 다음날 계획, 업무를 진척시키는 데 장애로 인식되는 이슈를 보고하라고 제안한다. 소위 스탠드 업(stand-up) 회의나 스크럼(srcum) 회의처럼 매일 같은 시간에 만나 짧게 논의하는 식으로 이 자리를 통해 개인 작업에서 팀 작업으로 혹은 그 반대로 작업 방식을 변경할 수 있다. 둘째, 애자일 방법론은 각 스프린트가 끝날 무렵에 고객 테스트로 새로 추가된 기능을 평가하라고 권고한다. 마지막은 도요타의 안돈 코드와 비슷한 방식으로, 애자일 방법론에서 파생한 일부 개념에서는 코드 방식으로도 문제가 해결되지 않으면 그 작업을 즉시 전체 팀으로 확대한다. 즉 작업 방식을 개인 작업에서 협력적인 팀 작업으로 변경하는 것이다.
다이내믹 작업 설계 관점에서 보면 애자일 방법론은 폭포수 방법론보다 잠재적으로 2가지 장점을 갖는다. 먼저 폭포수 개발 방법은 팀원들 간이나 팀과 고객 간에 협력적 방식을 활용하는 빈도가 너무 낮다. 개발자가 팀의 확인 없이 1∼2주 동안 혼자서 작업을 하다 보면 실수를 저지르거나 방향을 잘못 잡았더라도 그 결과가 너무 늦게 드러나서 상당한 시간을 소모할 가능성이 있다. 실제로는 개발자들이 그렇게 오래 기다리지 않고 관리자나 팀원들에게 비공식적인 확인을 받는다. 이런 확인 방식이 실용적으로 보일 수도 있지만 팀 전체가 프로젝트 상황에 대한 공통 정보를 공유하지 못한 채 작업을 진행할 수도 있다. 이런 경우에 작업 방식은 좌표의 3사분면인 ‘공장’ 모드에서 불확실한 작업이 순차적으로 조직화되는 4사분면으로 이동하기 시작한다. 이는 비용도 많이 들고 더딘 반복 과정을 낳으므로 필자들은 이를 ‘비효율적인 반복’이라 부른다. (DBR minibox Ⅱ ‘역기능을 낳는 다이내믹 작업 설계’ 참고.) 연구에 따르면 R&D 프로세스에서 이런 작업 방식은 큰 비효율을 낳을 수 있다.15 다음 단계로 넘어가기 위해 고위 임원들과 함께 정기적으로 모여 진척 상황을 검토하는 방법 또한 프로젝트팀 전체가 몇 달간에 걸쳐 일을 했는데 그 결과가 경영진의 기대와 다르다는 것을 너무 늦게 깨닫게 돼 일을 다시 할 위험에 처할 수 있다.
| DBR mini box II 역기능을 낳는 다이내믹 작업 설계 업무에 공장 모드와 스튜디오 모드를 적절히 접목하지 못하는 조직에는 어떤 일이 생길까? 이와 관련해 필자들은 비효율적인 반복(ineffective iteration)과 헛된 주목(wasted attention)이라는 2가지 실패한 업무 방식을 발견할 수 있었다. 이 2가지가 결합하면 매우 비생산적인 업무 설계를 낳는데 필자들은 이를 좌절의 축(axis of frustration)이라고 이름 붙였다. (그림 3) 비효율적인 반복 어떤 작업이 매우 모호한 요소들로 구성돼 있음에도 불구하고 순차적인 작업 방식을 따른다면 ([그림 3]의 4사분면에 해당) 어떻게 될지 먼저 생각해 보자. 이런 접근법은 좀 더 협력적으로 작업을 설계할 때보다 더디고 비용도 많이 드는 반복된 작업을 낳기 쉽다. 속도가 떨어지는 것은 모호한 일이 명확해질 때까지 작업자들 손을 거쳐 나가고 이 과정이 여러 번 되풀이되면서 시간을 잡아먹기 때문이다. 더욱이 지식 노동이 순차적으로 설계된 경우에는 모호함을 해결하기 위한 상호작용이 대부분 e메일이나 문자 메시지를 통해 전개된다. 연구에 따르면 이런 커뮤니케이션 방식은 직접 만나서 문제를 해결할 때보다 모호함을 효과적으로 줄이지 못할 뿐 아니라 메시지를 주고받는 사람들도 그런 한계를 인식 못한다. i 모호함을 e메일이나 문자 메시지로 해결하려는 노력은 더 큰 오해를 낳아 같은 과정을 여러 번 반복하게 만드는 경우가 많다. 헛된 주목 한편 잘 정의된 작업을 협력적인 방식으로 설계한 경우에도 비효율을 낳는다. 명확하게 정의된 일은 협력적 방식으로 혜택을 보기 힘들고 비용만 몇 배 더 들어갈 뿐이다. 게다가 과도한 협력은 같은 업무를 반복하는 사람들이 얻는 학습 곡선에서 생기는 효율성을 차단할 수 있다. ii 좌절의 축 필자들의 연구는 기능적 업무 프로세스가 공장 모드와 스튜디오 모드 사이를 움직인다 할지라도 이를 신중하고 주의 깊게 설계하지 않으면 그 프로세스가 위에서 설명한 실패한 방식들 사이를 오갈 수 있음을 보여준다. 즉 필자들이 좌절의 축이라 불렀던 헛된 주목과 비효율적 반복이 교대로 발생하는 것이다. 좌절의 축은 보통 시간적 압박을 받으면서 시작된다. 프로젝트가 계획된 일정보다 뒤처져 있거나 프로세스를 계속 반복해도 목표를 달성하지 못하는 경우를 말한다. 일단 스스로 뒤처져 있다고 느끼면 사람들은 문제를 해결하기 위해 시간을 들여 협력적인 스튜디오 모드를 취하려 하지 않는다. 대신 좌표의 3사분면에 해당하는 공장 방식을 고수한 채 ‘그저 일을 해치운다’는 태도를 취한다. 이런 결단은 문제를 미해결 상태로 남기거나 더 많은 문제를 야기한다. 그 문제가 제대로 작동하지 않는 제품의 디자인적 요소든 생산된 제품의 결함이든 마찬가지다. 이런 문제들은 보통 문제의 발단과는 한창 괴리된 활동에 의해 발견된다. 그리고 문제를 협력적 스튜디오 방식으로 해결하지 않고(시간 압박때문에) 재작업이라는 절차를 밟으면 작업 시스템은 다시 좌표의 3사분면에서 4사분면으로 이동하면서 ‘비효율적 반복’ 모드가 시작된다. 비효율적 반복의 결과로 작업 프로세스는 한층 더 효율이 떨어지고 목표를 달성할 수 없게 된다. 이렇게 되면 이제는 임원들도 상황을 좌시하지 않고 중재에 나설 것이다. 불행히도 이런 중재는 대개 문제의 작업 프로세스를 좀 더 면밀히 검토하는 회의를 더 자주 하는 형태로 나타난다. (필자들이 인터뷰했던 한 관리자는 이렇게 말했다. “프로젝트 진척상황을 매시간 보고하라는 지시가 떨어졌을 때 뭔가 일이 잘못됐다는 걸 감지했습니다.”) 하지만 그런 검토를 어떤 식으로 하느냐에 따라 결과는 완전히 달라진다. 검토 작업이 비효율적 반복을 일으킨 핵심 문제를 해결하는 데 집중하도록 짜인 경우에는 작업 시스템을 좀 더 생산적인 사이클, 즉 공장 모드와 스튜디오 모드가 필요에 따라 교체되는 프로세스로 되돌릴 수 있다. 하지만 그런 식의 중재 작업이 이뤄지는 경우는 흔치 않다. 
지금까지 대부분의 작업 프로세스는 단계적 확대라는 메커니즘을 염두에 두고 설계되지 않았다. 그래서 고위 관리자들이 프로젝트를 중재하고 면밀히 검토하려 할 때면 어디를 살펴봐야 할지도 모른 채 프로세스 전체를 검토하려 했다. 그런 검토의 대부분은 프로세스 중 아무 문제 없는 요소에 주의를 기울이는 긴 회의들을 이끌고 그 결과 문제의 프로세스는 좌표의 2사분면에 해당하는 ‘헛된 주목’이라는 덫에 걸리고 만다. 게다가 끊임없이 이어지는 회의와 회의를 위한 준비로 실제 업무에 할당해야 할 시간과 자원이 소모되면서 애초에 2가지 작업 모드 사이의 적절한 교체를 방해했던 시간 압박이 더욱 가중된다. 개별적 공장 모드와 협력적 모드 사이를 움직이는 작업 메커니즘을 신중하고 주의 깊게 살펴보지 않으면 프로세스는 비효율적 반복과 헛된 주목 사이를 점점 더 많이 오가게 되는 것이다. 기본적으로 다음 검토 회의가 있기 전까지 가장 최근에 발생한 문제를 해결하려고 (아니면 숨기려고) 미친 듯이 애쓰고, 또 회의가 시작되면 실제로 변화를 이끌 만한 문제 해결에 전혀 도움이 되지 않는 검토를 끝도 없이 이어 나가는 악순환이 반복된다. |
소프트웨어 개발에 애자일 방법론을 활용하면 개발자가 혼자 작업하는 시간의 질도 향상된다. 각 소프트웨어 요소들을 기능성에 초점을 맞춰 개발하면 팀과 고객 모두 1∼2주 만에 사용 가능한 소프트웨어를 접할 수 있으므로 그 소프트웨어가 고객이 원하는 요건에 부합하는지 훨씬 더 쉽게 판단할 수 있다. 반대로 폭포수 접근법의 초기 단계들은 소프트웨어의 필요 요건과 특징들을 긴 리스트로 정리하는 데 치중하며 새롭게 시도하거나 테스트하는 작업은 전혀 없다. 폭포수 방법론을 활용하면 개발 사이클이 거의 끝날 무렵에 프로젝트의 중요한 결함과 결핍을 발견하는 경우가 종종 생긴다. 그러면 결국 값비싼 비용을 치르면서 재작업을 하게 되는데 생각해보면 놀라운 일도 아니다.16
다이내믹 작업 설계 방식 적용하기
도요타 생산 시스템과 애자일 기반의 소프트웨어 개발 방식은 모두 필자들이 좋은 다이내믹 작업 설계라고 부르는 예다. 전통적으로 활용했던 고정적 접근법과 달리 다이내믹 작업 설계는 불가피한 변화를 인식하고 이에 대응하는 메커니즘을 구축한다. 관리자들이 좀 더 개별적인 작업 방식과 협력적인 방식을 유동적으로 활용해야 한다는 사실을 일단 인식하면 그들은 조직의 업무 성격에 맞는 교체 메커니즘을 개발하기 위해 다음 4가지 원칙을 활용할 수 있다.
1. 잘 정의된 일과 불분명한 일을 구별하라. 일단 잘 정의된 일과 불분명한 일을 명확히 분리하는 것부터 시작하라. 이 2가지 유형의 일을 동일한 프로세스로 처리하면 문제가 발생하기 쉽다. (DBR minibox Ⅱ ‘역기능을 낳는 다이내믹 작업 설계’ 참고.) 실무 점검으로 2가지 유형을 구분하는 경우도 있지만 그렇지 않은 경우에는 불분명한 일의 특징적 요소, 즉 반복되는 요소를 살펴보라. 잘 정의된 작업은 릴레이 주자들이 바통을 이어받듯 다음 단계로 넘어갈 수 있다. 일이 제대로 완료됐다면 전 단계로 되돌아갈 필요가 없기 때문이다. 반대로 모호한 작업은 최선의 노력을 다했을지라도 전 단계로 되돌아가는 경우가 종종 생긴다. 어떤 일이 동일한 단계들을 밟으며 몇 번씩 반복되고 있다면 이는 비효율적인 모호함에 부딪쳤다는 신호다.
2. 프로세스를 자주 점검할 수 있도록 더 작은 단위로 세분하라. 애자일 방법론에 대한 모든 거품을 빼면 어떤 작업 프로세스에 있어서나 민첩성(외부 환경의 변화로 인해 일을 조정하고 결함을 해결하는 능력을 의미하는)은 결국 결과물을 평가하는 빈도와 효과로 귀결된다. 도요타 생산 시스템이 탄생하기 이전에 존재했던 전통적 개발 방식이나 폭포수 소프트웨어 개발 방식에서는 평가가 가끔씩 이뤄지고 특별히 효과적이지도 않았다. 그 결과 두 접근법은 외부 환경 변화에 대응하는 속도가 떨어졌고 비싸고 느린 재작업 사이클을 통해서만 원하는 품질을 얻을 수 있다. 반대로 효과적인 평가를 자주 수행하면 작업 프로세스는 높은 변화 적응력을 갖게 되고 결과물의 품질도 빠르게 향상될 것이다. 프로세스를 더욱 민첩하게 만드는 근본적인 레서피는 일의 단위를 더 작게 세분하고 진척 상황도 더 자주 점검하는 것이다.
3. 작업 실무자를 보조하는 사람들을 파악하라. 헬프 체인을 발견하는 일도 중요하다. 헬프 체인이란 직무 담당자를 보조하는 일련의 사람들을 말한다. 생산에서 헬프 체인은 기계 운영자로 시작해서 작업반장, 현장 감독부터 최상위에 있는 공장 관리자까지 포함된다. 소프트웨어 개발에서 헬프 체인은 주로 엔지니어로 시작해서 팀 리더를 거쳐 고위 관리자로 이어지며 궁극적으로는 고객으로 끝난다. 필자들은 해당 작업을 수행하고 지원하는 사람들의 체인을 확인하는 일이 중요하며 그들의 역할과 소속 부서, 담당 직무는 오히려 중요도가 떨어진다고 말한다. 민첩성을 높이기 위해서는 문제가 생겼거나 피드백이 필요할 때 누구를 찾아야 하는지 아는 것이 중요하기 때문이다.
4. 작업을 협업 방식으로 바꾸는 작동 장치와 점검 장치를 도입하라. 헬프 체인을 파악했다면 이를 활성화하는 2가지 기본 메커니즘을 확보해야 한다. 작동 장치(trigger)와 확인 장치(check)다. 작동 장치는 결함이나 서로 어긋난 부분을 드러내서 작업을 공장 모드에서 협력 모드로 바꾸는 테스트를 말한다. 앞서 언급한 도요타 사례에서 한 공장 근로자는 조립 라인에서 자신의 임무를 제시간에 완수할 수 없었고 이는 그녀가 버튼을 눌러 감독자의 도움을 받는 작동 장치가 됐다. 점검 장치는 작업을 좀 더 협력적인 방식으로 바꿀 수 있도록 미리 정한 시점과 관계가 있다. 애자일 소프트웨어 개발에서 작업 방식의 변화는 팀원들이 프로젝트의 진척 상태를 점검하기 위해 매일 갖는 스탠드업 미팅에서 일어난다. 한 스프린트를 완수하면 두 번째 점검 기회가 생기는데 이때는 고객과 함께 프로젝트 상황을 확인한다.
구매 관리 개선하기
다이내믹 작업 설계 방식을 회사에 채택하면 효율성과 융통성 모두에서 성과를 크게 높일 수 있다. ‘리파인코(RefineCo)’라는 회사의 사례를 살펴보자. 이 회사는 미국에 여러 정유 공장 및 유통 터미널을 갖고 있다. 그러나 리파인코의 구매 조직은 어떤 기준을 들이대도 경쟁력이 떨어졌다. 회사는 비슷한 부품과 서비스를 경쟁사보다 더 높은 가격으로 구입하고 있었으며 구매부에서 발생하는 간접비 또한 업계 평균보다 높았다. 이보다 더 골칫거리는 정유공장이 공급업체에 비용을 제때 지급하지 못해 ‘거래 보류’ 상태에 처하고 이로 인해 중요한 부품을 공급받지 못하는 경우였다. 고위 임원부터 물품을 선적하거나 입고시키는 직원까지 구매 시스템과 관계된 모든 이들은 좌절감에 빠졌다. 리파인코의 각 공장에 있는 구매 시스템은 대략 이런 식으로 작동했다. 외부 업체로부터 상품이나 서비스를 구매하려는 직원은 전자 구매 시스템에 필요 사항을 입력한다. 그러면 전자 시스템이 구매 본부에 이를 요청서 형태로 전송한다. 구매 본부에 속한 직원은 요청서를 검토하고 구매 주문서를 발주한다. 그러면 주문서가 공급업체로 전송될 것이다. 주문한 제품이 정유 공장에 입고되거나 요청한 서비스가 완료되면 패킹 슬립(packing slip, 업체가 보통 상품과 함께 보내는 상품 정보가 수록된 확인서-역주)이나 서비스 확인서가 생성되고 그 내용이 구매 시스템에 입력된다. 이후 공급업체는 인보이스를 발송하고 이 또한 시스템에 입력될 것이다. 그러면 이제 시스템은 모든 일들이 올바로 처리됐는지 확인하기 위해 3자 간 매칭 작업을 수행한다. 즉 구매 주문서와 공급업체에서 받은 확인서, 인보이스 내용이 서로 일치하는지 확인하는 것이다. 내용이 서로 일치하지 않는 인보이스는 시스템에서 처리될 수 없으므로 불일치하는 내용이 해결될 때까지 공급업체에 비용이 지급되지 않는다.
이렇게 일치하지 않는 내용을 해결하는 일은 정유 공장의 구매부 직원들이 담당했다. 불행히도 리파인코에서 구입한 제품이나 서비스 중에는 3자 간 매칭을 통과하지 못한 경우가 허다했다. 그 결과 구매부는 과중한 업무에 시달렸을 뿐 아니라 공급업체들의 불만도 높아졌다. 정유 공장은 성공한 대기업에 속해 있었지만 인보이스 비용을 제때 지급하지 못해 공급업체들로부터 거래 중지를 당하는 경우가 종종 발생했고 구매부 직원들은 그 때문에 업무를 진행하고 공장을 안전하게 운영하는 데 고초를 겪었다. 구매부의 정규직 직원들은 하루에 10시간 이상 일하는 경우가 속출했고 잔업을 보조할 수 있는 계약직 직원도 고용했지만 업무는 점점 더 쌓여만 갔다.
구매부 직원들 대부분은 ‘과중한 업무량’과 엉망이 된 시스템에 큰 불만을 표출했다. 그 누구도 직원을 더 뽑는 방법 이외에는 상황을 개선할 여지를 발견하지 못했다. 리파인코 프로젝트에서 결정적 전환점은 오랫동안 구매부에 몸담고 있던 직원 한 명의 얘기를 들으면서 시작됐다. 그의 말에 따르면 좋은 구매 요청서는 ‘필요한 정보를 모두’ 담고 있어서 5∼10분 만에 공식적인 구매 주문서로 전환될 수 있었다. 그러나 처리하기 어려운 요청서는 핵심 정보가 몇 개씩 누락돼 있어서 구매 본부 직원은 제품을 요청한 부서 및 공급업체와 계속 e메일을 주고받아야 하고, 이로 인해 주문서를 처리하는 데 한두 시간이 걸린다는 얘기였다. 그런 노력에도 불구하고 처리하기 어려운 구매 주문서는 3자 간 매칭에 실패해서 시스템에서 반송되는 경우가 많았다. 더군다나 조사를 해보니 구매 주문 시스템은 이렇게 반송된 주문서들로 가득 차 있었고 구매부 직원들은 대부분의 업무 시간을 잔업을 해치우는 데 할애하고 있었다. 이 회사의 구매 시스템은 전형적인 ‘신속한 일 처리’와 ‘불 끄기’의 함정에 빠져 있었다. 진행 중에 있는 구매 주문서가 너무 많다 보니 어느 하나도 빨리 처리되는 법이 없었다. 처리 시간이 오래 걸리면서 고객들의 불만은 높아졌고 주문과 비용 지급에 대해 문의하는 공급업체들의 불평도 속출했다. 그 결과 구매부 직원들은 불만의 목소리가 가장 큰 고객이나 공급업체에 대응하느라 일의 우선순위를 계속해서 바꿀 수밖에 없었다.
필자들의 첫 번째 통찰력은 구매부 직원들이 순차적인 ‘공장’ 방식과 협력적인 ‘스튜디오’ 방식이 필요한 2가지 다른 유형의 업무를 담당하고 있다는 사실을 파악했다. 구매를 요청한 제품이 표준 아이템이고 필요한 모든 정보가 들어온 경우에는 협업 없이도 담당자 한 명이 쉽게 요청서를 처리할 수 있었다. 일단 구매 주문서가 입력되면 공장 조립라인 위에 놓인 아이템처럼 시스템이 처리하는 대로만 따라가면 됐다. 그러나 표준 아이템인 경우에도 요청서에 올바른 정보가 있어야만 시스템에 맡길 수 있었다. 그렇지 않은 경우에 구매 주문서를 발급하려면 보통
e메일을 통해 과정이 여러 번 반복될 수밖에 없었다. 이에 따라 구매 본부는 좋은 구매 요청서를 이루는 간략한 점검 목록을 개발했다. 표준 주문서가 항상 올바른 정보와 함께 입력될 수 있도록 정한 방책이었다. 여러 부서에서 점검 목록을 활용할 수 있도록 인센티브도 생각해냈다. 오전 7시 이전에 들어온 요청서에 필요한 정보가 전부 채워진 경우에는 당일 오후 2시까지는 구매 주문서를 발급해 주겠다는 약속이었다. 당시에는 거의 모든 요청서가 ‘미비 서류’로 처리됐기 때문에 주문서가 당일 처리된다는 것은 있을 수 없는 일이었다. 또한 구매부는 생산성을 개선할 수 있는 단순한 작동 장치도 개발했다. 점검 목록에 있는 정보가 누락된 구매 주문서는 즉시 요청 부서로 반송하기로 했다.
두 번째 통찰력은 모든 요청서를 공장 방식으로 처리할 수 없다는 점이었다. 기존 시스템에서는 상품 구매를 요청한 직원이나 구매부 직원이나 표준 요청서와 신규 요청서의 차이를 구분하지 못했다. 그래서 신제품이나 새로운 서비스에 대한 구매 요청이 들어오면 구매부 직원들은 보통 이를 처리하는 과정에서 필요한 정보를 전부 얻기 위해 며칠씩 요청 직원과 e메일을 계속해서 교환해야 했다. 구매부 직원이 필요한 정보를 얻지 못한 경우에는 대개 자신이 할 수 있는 최선의 추측으로 불완전하거나 잘못된 정보를 채운 주문서를 발급했다. 이 경우 정확히 어떤 상품을 보내야 할지 확신이 서지 않는 공급업체는 또다시 구매 본부 직원과 전화나 e메일을 교환할 수밖에 없었다. 결국 리파인코의 구매 프로세스는 필자들이 개발한 좌표의 4사분면에 자리를 잡게 됐다. 모호한 작업을 순차적인 공장 방식으로 처리하려다 보니 일이 더디고 값비싼 반복 과정이 발생했기 때문이다.
복잡한 구매 주문서를 처리하는 데 협력적인 스튜디오 방식을 도입하기 위해서는 작업 설계에 2가지 변화가 필요했다. 먼저 구매부는 명확한 작동 장치를 개발했다. 구매를 요청한 상품이 표준 물품이 아니라면 별도의 파일로 구분해서 즉시 처리하지 않았다. 그리고 매일 오후 2시에 구매부 직원들이 복잡한 요청서를 함께 처리하기 위해 한데 모였다. 협력적으로(스튜디오 모드로) 업무를 처리하자 추가 개입 없이도 복잡한 주문서 대부분을 처리할 수 있었다. 부서원 중 누군가는 비슷한 주문서를 이전에 본 적이 있었기 때문이다. 게다가 모두가 얼굴을 맞대고 회의를 하는 편이 끊임없이 e메일을 교환하는 것보다 훨씬 더 효율적이었다. 추가 정보가 필요한 경우에도 e메일을 보내기보다는 2시 이후에 전화 일정을 잡아서 끊임없이 이어지는 e메일로 발생한 비용을 줄일 수 있었다.
이 2가지 변화는 상당한 효과를 냈다. 표준 주문서에 공장 작업 방식을 도입한 결과 구매부 직원들은 ‘7시 이전에 들어온 요청서는 2시까지 내 보낸다’는 약속을 지킬 수 있었다. 그리고 구매를 요청한 직원들도 구매부에 호의를 갖게 됐다. 오후에는 스튜디오 모드로 업무를 처리한 것도 복잡한 요청서의 처리 속도를 높이는 계기가 됐다. 이 2가지 변화를 통해 구매부는 복잡한 요청서들을 처리하게 됐을 뿐 아니라 미처리된 구매 요청서로 인해 발생한 잔업을 해결하는 데 스튜디오 모드를 활용할 수 있을 만큼 충분한 여유도 갖게 됐다. 이렇게 효율성이 높아진 구매부는 정규직 직원 2명에 상응하는 인력을 줄이는 동시에 더 안정적인 서비스를 훨씬 더 빠른 속도로 제공하게 됐다. 회사는 프로세스를 개선하면서 얻은 통찰력을 미국 내 다른 공장에도 도입했다. 이 기사를 작성하는 현재 기준으로 리파인코는 인보이스의 90% 이상을 정해진 시간 내에 지급하고 있으며 그 결과 공급업체들의 만족도도 전보다 훨씬 높아졌다.
모범 사례 찾기
관리자들과 컨설턴트들은 종종 모범사례를 찾는 데 집착한다. 선도 기업들을 경쟁자들 사이에서 돋보이게 만든 활동들을 찾는 것이다. 이런 탐색 작업을 하는 이유는 일단 모범 사례를 확인하면 다른 조직에도 적용해서 비슷한 성과를 낳을 수 있다고 믿기 때문이다. 분명 어느 정도는 타당한 견해지만 이를 뒷받침하는 증거는 확실히 엇갈린다. 새로운 기법과 관행을 도입하려고 애쓰지만 모범 사례와 비슷한 성과를 경험하는 조직은 드물기 때문이다. 많은 업종에서 상위에 군림하는 기업들과 중간층을 형성하는 기업들의 실적 차이는 좁히기 어렵다. 간격을 메우기 힘든 주된 원인은 조직이라는 것이 사람과 기술, 그리고 어떤 상황에는 효과적이지만 또 다른 상황에는 효과적이지 못한 일련의 도구와 관행으로 복잡하게 구성돼 있기 때문이다. 두 경쟁사가 바로 옆 건물에 위치해 있을지라도 상황은 마찬가지다.
모범 사례는 이를 채택하려는 조직의 근본적인 행동 방식이 그것을 활용하는 조직의 행동 방식과 일치할 때 ‘최고’의 효과를 낸다. 도요타를 유명하게 만든 안돈 코드와 그 효과를 더 높이는 지역 중심의 문제 해결 방식은 효율성을 통해 효과를 발휘한다. 또한 그 효율성은 개인의 반복적인 훈련과 협력적 문제해결 방식에 따른 혁신을 통해 창출된다. 반대로 애자일 개발 방식은 잦은 팀 회의와 고객과의 상호작용을 통해 소프트웨어 엔지니어의 창의성을 발휘할 때 제대로 작동한다. 더 일반적으로 말해서 조직은 결함과 문제를 더 빨리 발견할수록 적응력을 높일 수 있다. 상황에 맞게 다이내믹한 접근법을 취하고 이를 작동 장치와 점검 장치로 뒷받침하면 조직의 업무 환경에서 민첩성을 높이는 업무 방식들을 효과적으로 모색하는 길을 열 수 있다.
번역 ｜김성아 dazzlingkim@gmail.com
편집자주
이 글은 MIT 슬론 매니지먼트 리뷰(SMR) 2017년 가을 호에 실린 ‘A New Approach to Designing Work’를 번역한 것입니다.
넬슨 P. 리페닝·돈 키퍼·제임스 리페닝
넬슨 P. 리페닝(Nelson P. Repenning)은 매사추세츠주 케임브리지에 있는 MIT 슬론 경영대에서 시스템다이내믹스 및 조직연구 분야의 경영학 석좌교수로 있으면서 리더십과 특별 프로젝트 부문의 부학장 및 MIT 리더십센터의 학부장을 겸임하고 있다. 돈 키퍼(Don Kieffer)는 MIT 슬론 경영대학원의 오퍼레이션 관리 부교수이자 케임브리지에 있는 컨설팅 회사인 시프트기어워크디자인(ShiftGear Work Design)의 설립자다. 제임스 리페닝(James Repenning)은 시프트기어워크디자인의 매니징 파트너다. 이 기사에 의견이 있는 분은 http://sloanreview.mit.edu/x/59234에 접속해 남겨 주시기 바란다.
인기기사
