우리는 팀인가요?
테일러주의는 우리에게 가능한한 모든 작업을 원자 단위로 쪼개고, 작업 간의 의존성을 최소화하고 각 작업을 최적화할 것을 가르쳤습니다. 아니, 그런 일을 해줄 사람이 관리자로 존재하고, 노동자들은 기계의 일부분인냥 정해진 일을 하면 된다고 가르쳤습니다.

여기에서 우리가 물어야할 질문은 과연 그 방식이 오늘날 적절한가 하는 것과, 그 방식이 다른 분야에도 적절한가 하는 것입니다.

우선 제가 Are We a Team이라는 위키 페이지에 썼던 글과 워드 커닝햄이 썼던 글을 인용하겠습니다. 워드는 관심사의 분리(Separation of Concerns)가 아니라 관심사의 섞임(Mingling of Concerns)을 말합니다. 그리고 이 방식이 더 나은 코드로 가는 더 빠른 길이라고 말합니다.

많은 팀들은 사실 "팀"이 아니다. 그냥 일하는 사람들의 집단일 뿐이다. 상호 협력과 인터액션이 부족하다. 우리가 팀인지, 단순한 워크그룹인지 쉽게 아는 방법:

    일단 1주일 이하 단위의 공유 미팅이 없으면 일단 제껴야 한다. 그 다음, 주간 회의 시간에 업무 공유를 할 때 사람들을 유심히 보라. 한명씩 돌아가면서 자기가 한 일을 발표하는 데에 각자 3분 이상 걸리는가? 단지 사실의 나열을 읽는 것일 뿐이고 다른 사람과 교감이 없는가(질문이 있다든지)? 다른 사람들이 그 동안 딴 짓을 하는가? 조는 사람이 있는가? 그렇다면 우리는 팀이 아닐 확률이 높다.

이런 사람들에게 애자일 방법론을 권하면 반응은 한결같다. "우리는 서로 업무가 너무 달라서 그런 방식이 맞지 않아요." 우리는 팀이 아니에요 하는 말과 꼭 같다. 워드가 MinglingOfConcerns에서 말하듯이 대다수의 매니저는 12가지 일이 있고 사람이 12명이면 한 사람에게 하나의 일을 맡기는 것을 최선으로 생각한다. 그러나 그것이 진정 최고의 코드를 만드는 방법인가? --김창준



알렉산더 에지드(Alexander Egyed)의 작업을 연구하는 학생에게 보낸 편지 중에서...

저는 에지드의 논문을 잘 모릅니다. 학생이 보낸 이메일을 읽고난 후 온라인을 검색해서 그가 보엠과 함께 모델링에 대해 많은 글을 썼다는 사실을 알게 되었습니다. 그 글 전부가 우리가 "초기 대형 설계"(BigDesignUpFront^) 철학이라고 부르는 것과 같아 보이는데, 저는 그 철학을 거부합니다. 학생의 연구 목표로 생각되는 "관심사의 분리"(SeparationOfConcerns^)에 대해서도 언제나 팬의 입장은 아닙니다. 제 생각을 설명해줄 사고 문제가 여기에 있습니다:

어떤 소프트웨어 관리자(manager)에게 12가지 할 일이 있고 그 일을 할 사람도 12명이 있습니다. 그는 어떻게 해야 할까요?

대다수의 관리자들은 각자에게 한가지씩 일을 할당할 것인데, 이 경우에 병렬 진행이 최대화될 수 있다고 보기 때문입니다. 하지만 이것이 최고의 코드로 가는 가장 빠른 지름길일까요? 저는 그렇지 않다고 봅니다. 제 생각에는 관리자가 사람들에게 함께 작업하지 말라고 지시했을 겁니다. 그들이 따로 떨어져서는 할 수 없는 것을, 다 같이 모여서 도대체 무슨 일을 할 수 있을런지 그 관리자는 아마 상상조차 못할 것입니다. 그럴 수 밖에 없는 것이, 사람들이 하나의 문제를 해결하기 위해 각자의 경험을 동원할 수 있도록 허락했을 때 그들이 무슨 일을 할지 한 사람으로서는 상상하기가 무척이나 어렵기 때문입니다.

제가 선호하는 접근법은 관리자가 12명 모두에게 단지 3가지 일만 주고 서로 협동해서 그 일을 하도록 요청하는 것입니다. 그 일들이 완료되면 관리자는 할 일을 3개 더 만들어 냅니다. 사람들은 작업을 완료하기 위해 자기조직화(self-organize)할 수 있는 권한이 있고, 또 매번 다르게 조직화할 수도 있을 겁니다. 이 방식이 잘 돌아가는 이유는 사람들이 "관심사의 섞임"(mingling of concerns)을 통해 서로에 대해 엄청나게 많은 것을 매우 빨리 배울 수 있기 때문입니다. 이런 식으로 학습한 지식은 관리자나 혹은 누구든 딱 한 사람이 모델링한 것의 위험을 피할 수 있는데, 그런 한 사람에 의한 모델링 때문에 모델 주도 접근법(model driven approaches)은 불리해 집니다.

제 접근법은 또한, 첫 3가지 작업에 대한 해결책을 조정해서 두번째 3가지 작업에 대한 니즈를 수용하고, 계속해서 결국 모든 작업이 완료될 때까지 이를 계속하는 팀의 능력에 의존하고 있기도 합니다. 우리는 이것을 리팩토링이라고 부릅니다. 초기 대형 설계 쪽의 사람들은 이것은 어려운 문제이고 따라서 회피해야 하는 것이라고 믿습니다. 그렇지 않습니다. 문제는 이미 간단하며, IntelliJ IDEA 같은 강력한 리팩토링 툴 덕택에 더욱 간단해졌습니다.

"소프트웨어 공학" 공동체가 그런대로 간단한 것(프로그래밍)을 갖고는 매우 복잡하게 만들어 버리지나 않았는지 저는 걱정이 듭니다. 독창적 연구의 기회가 많아지기 때문에 이것은 학생에게는 득이 될 수도 있겠습니다. 저는 학생이 계획했던 대로 연구를 완성하기를 권합니다. 명심해야 할 것은, 학생은 어떤 인공적 구조물을 연구하고 있는 것이며 그것은 앞서의 가상의 관리자가 내렸던 열등한 선택들 때문에 존재하게 되었다는 점입니다. 자신의 연구가 훗날에도 경쟁력이 있게 하려면, 제가 장려하는 기법들이 널리 퍼지는 경우 그 연구가 어떻게 적용될지 혹은 적용되지 못할지를 논하는 작은 섹션을 하나 추가하면 되겠지요.

행운을 빕니다. 그럼 이만.

-- 워드 커닝햄, MinglingOfConcerns에서 (번역: 김창준)


도요타는 자동차 회사입니다. 도요타에서는 테일러리즘과는 정반대의 길을 장려하고 있습니다. 한 사람이 여러 직능을 갖는 것을 권하며, 노동자들이 머리를 짜내어 공정을 지속적으로 개선하는 것(카이젠이라고 합니다)을 강조합니다. 팀으로 일하며 서로 협력할 것을 권합니다. 결과는? 도요타는 전세계 자동차 회사 중 최고의 이익을 내고 있다고 합니다.

제트기 엔진 같이 복잡하고 전문성이 많이 필요한 분야는 어떨까요?

GE의 제트기 공장 중 최고 성과를 내는 곳이 노스 캐롤라이나 더럼(Durham)의 공장입니다. Fast Company라는 잡지에 이 공장에 대한 기사가 났습니다. 제목이 Engines of DemocracyHow Teamwork Took Flight입니다.

직원 수는 170여명인데 상관은 딱 한명입니다. 그 170명이 모두 동일한 한 사람의 상관만 두고 있습니다. 공장장이지요. 실질적으로는 모두가 상관 없이 일하는 것입니다. 여기에는 전통적 조립 라인이 없습니다. 각각의 팀이 엔진 처음(부속 단계)부터 끝까지(트럭에 실을 때까지) 모든 것을 책임집니다. 각 팀은 매일 14시 30분에 만납니다. 단순한 일간 보고가 아닙니다. 그야 말로 팀에 대해 모든 것을 이야기하는 자리입니다. 뭔가 팀으로 작업하고 있는 것이지요. 또한 관심사의 섞임을 권합니다. 모든 사람이 자신의 기술을 넓히도록 합니다.

"Multiskilling is how the place is kept together," says Derrick McCoy, 32, a tech-3 and a buddy of Duane Williams's on Team Raven. "You don't hoard your skills. That way, when I'm on vacation, the low-pressure turbine can still be built without me."


예상하시겠지만, 이곳에서 사람을 뽑을 때엔 단순히 기술능력만 보지는 않습니다. 총 11개의 영역이 있고, 그 중 기술은 한가지일 뿐이고 다른 나머지 10개에서 기준치를 넘지 못하면 뽑지 않습니다. 그 영역은 도와주는 능력, 의사소통 능력, 다양성, 유연성, 코칭 능력 등 다양합니다.

The most interesting measure may be one that the people at GE/Durham talk about themselves. They don't really think that their main job it so make jet engines. They think that their main job is to make jet engines better.

"I think what they've discovered in Durham is the value of the human being," says McEwan.

저는 테일러리즘은 오늘날 점점 더 그 의미를 잃어가고 있으며, 적절한 분야도 점점 줄어들고 있다고 생각합니다. 하지만 불행히도 우리의 무의식 속에는 테일러리즘이 깊히 뿌리박혀 있습니다. 각자 자신의 최선만 다하면 된다고 생각하며, 관리자는 그런 환경 -- 자기 일만 최선을 다하면 전체 성과가 좋은 -- 을 만들어 내려고 많은 노력을 합니다. 하지만 대다수의 경우 이런 태도는 반대효과를 불러 일으킵니다. 최적의 성과가 나지 않습니다. 지역 최적(local optima)에 도달하지 전역 최적(global optima)에 도달하지 못합니다. 나는 잘 했는데 우리 회사는 망하는 꼴이 납니다.

관심사가 섞이는 곳에 혁신이 있고 개선이 있다고 생각합니다.

--김창준
by 애자일컨설팅 | 2006/05/09 00:53 | 트랙백(4) | 덧글(7)
트랙백 주소 : http://agile.egloos.com/tb/1932595
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from Xeraph: 블로쿠 at 2006/05/09 01:44

제목 : 우리는 팀인가요?
우리는 팀인가요? 모듈 단위로 한 사람에게 전담시켜버리는 일이 흔합니다. 계층별로 전체 솔루션을 쪼개서, 각 계층을 팀원들에게 분배하는거죠. 이렇게 되면 정말로 바쁠 때에는, 누구 하나 휴가도 못 가는 상황이 만들어집니다. 모듈 하나를 책임지던 사람이 하나라도 빠져버리면 그냥 전체가 못 굴러가는 상황이 되는거죠. 팀원 각각은 다른 모듈이......more

Tracked from SoWhat? at 2006/05/09 10:06

제목 : 우리는 팀인가요?
테일러리즘 - 테일러리즘이란 인간과 도구 혹은 기계를 어떻게 하면 과학적으로 결합시켜 노동으로부터 최대의 효율을 얻어내는가를 연구하는 과학적 관리기법을 의미한다. 또 하나 배웠다..;; 크 우리는 팀인가요? ...more

Tracked from 일상에서 행복찾기 at 2006/05/27 23:01

제목 : 팀 빌딩, 워크그룹 컴파일.. 그리고 팀 그로우잉(..
종종 팀 빌딩이라는 용어를 사용한다.난 이 말을 싫어한다. 빌딩이라 함은 부품을 하나하나 끼워 맞춰 만들어 가는 것이다.일종의 무기체의 결합이다.부품들은 주어진 역활에서 다른 역활을 해서는 안된다.맏은 역활에서 그 이상도 그 이하도 수행하면 안된다.단순히 자신의 능력중 일부만을 기계적으로 정확히 반복하기를 요구 받는다.자신의 ......more

Tracked from wisehouse's .. at 2009/09/03 11:44

제목 : 처루의 생각
관심사가 섞이는 곳에 혁신이 있고 개선이 있다. -애자일 이야기...more

Commented by 김형준 at 2006/05/09 08:11
회의 부분에서는 동감이 많이 갑니다. 매주 주간업무회의를 하지만 각 파트 리더들이 자신의 업무를 이야기 할때 다른 사람은 무슨 이야기를 하는지 모를 경우가 많거든요. 이런 회의가 필요한가에 대해 이전부터 고민을 많이 했습니다. 물론 그 회의를 소집하는 팀장의 입장에서는 최소한 팀내에서 무슨일이 발생하고 있는지에 대해서는 공유가 되어야 하지 않겠느냐고 말하지만... 그 공유라는 것의 의미가 단순한 단어의 나열인 경우에는 매번 회의때 마다 이해하는 정도가 같으면 월간회의 정도로도 충분하리라 생각합니다.
Commented by 고현운 at 2006/05/09 10:09
너무 좋은글이라 퍼가도 될런지 모르겠습니다. 평소 생각하던바와 공감이 가는 부분이 있어서 아는 사람들에게 보여주고 싶습니다.
Commented by 냥이 at 2006/05/09 16:13
훌륭한 글입니다. 링크하겠습니다.
Commented by 서상민 at 2006/05/11 20:16
너무나도 마음에 느끼는 글인것 같습니다.
링크해갑니다.
Commented by 마근엄 at 2006/05/16 06:30
캐논의 조립라인도 전통적인 테일러리즘과는 정 반대로 가는 케이스라 하지요. 복사기 1대를 조립하는데 8명이 필요했다면, 이를 6명으로 줄여서 하는 방법을 고안하고, 다시 4명, 2명... 종국에는 1사람이 복사기를 처음부터 끝까지 조립하게 된다고 하더군요.
Commented by 정규현 at 2006/07/13 14:56
단순히 소프트웨어개발보다는 프로젝트나 팀활동 자체에 대한 심도깊은
성찰이네요. 에이자일 방법론 말고, 조직커뮤니케이션 전문가로 활동하셔도
될것 같습니다.
Commented at 2007/03/13 17:58
비공개 덧글입니다.

:         :

:

비공개 덧글

< 이전페이지 다음페이지 >