전문가에 대한 미신 : 협력을 어떻게 할까
<updated> (아직 완전히 정리되지 않은 글입니다)

우리는 일종의 미신을 갖고 있습니다. 전문가는 언제나 탑다운(top-down)으로 "깔끔히" 생각할 것이다라는 생각입니다.

탑다운은 문제 해결 과정을 시간의 흐름에서 볼 때 추상적인 숲에서 출발해서 점점 더 구체적인 나무로 내려오는 접근법을 말합니다. 그 반대라 할 수 있는 바텀업(bottom-up)은 나무에서 출발해서 숲으로 올라오는 과정입니다.

탑다운은 더 깔끔해 보입니다. 바텀업은 "탐험적"인 성격이 많습니다. 여기저기 찔러보고 방향도 바꾸고 하지요. 이런 면에서 사람들은 전문가일수록 탑다운으로 사고하고 문제를 해결할 것이라 믿습니다. 실제 실험실 연구에서도 비슷한 결과가 나왔습니다.

예를 들어 물리학 문제를 풀게 했을 때 대학생 등 비전문가들은 문제에서 묻는 것, 즉 최종의 답에서 출발을 합니다. 예를 들어 문제에서 원하는 것이 "속도"라면 속도가 적용되는 수식을 생각해 내고 거기에서부터 다시 문제에서 애초에 주어진 정보 쪽으로 거꾸로 길을 찾아 갑니다. 잘 모르는 정보에서 출발해서 잘 아는 정보쪽으로 문제를 변형해 가며 끌어오는 겁니다. 반면 물리학자 같은 전문가들은 문제에서 주어진 정보에서 출발합니다. 거기에 적용이 되는 원칙을 생각합니다. 그러면서 수식을 하나씩 적용해 나가서는 최종적으로 문제가 원하는 답에 도착합니다. 우리가 생각하는 정답 해설의 순서와 유사합니다. 깔끔하지요. (사실 이 실험에서 말하는 것은 순방향과 역방향 사고에 대한 것이고 탑다운과 버텀업은 조금 다른 측면이긴 합니다)

인공지능 연구에선 이 세상의 문제를 두 종류로 나눕니다. 잘 정의된 문제(Well-defined), 잘 정의되지 않은(Ill-defined) 문제. 잘 정의된 문제는 출발 상태와 목표 상태가 명확히 알려져 있고 그 상태간 이동의 규칙이 주어진 문제를 일컫습니다. 오목이나, 체스 같이 승패와 말의 이동 규칙이 명확한 게임, 또 선교사와 식인종 문제 같은 것들은 여기에 속합니다. 하지만 "벽을 장식할 아름다운 그림을 그리시오" 같은 문제는 잘 정의되지 않은 문제입니다. 무엇이 목표 상태인지가 불분명합니다. 심지어는 최초의 출발 상태에 대한 정보도 온전히 주어지지 않고, 무엇이 적법한 말의 이동인지 무엇이 부적법한 것인지 규칙의 경계도 불투명합니다.

잘 정의된 문제는 연구하기가 쉽기 때문에 많은 연구가 이루어져 있습니다. 하지만 우리가 실생활에서 만나는 대다수의 문제는 잘 정의되지 않은 문제입니다. 사실상 뭔가 만들어 내야 하는 문제, 즉 디자인(설계)이 개입되는 것은 거의 다 제대로 정의될 수 없는 문제입니다.

앞서의 전문가들은 자신이 자주 접하지 않았던 문제, 어려운 문제, 혹은 잘 정의되지 않은 문제를 접하면 접근법을 바꿉니다. 탑다운과 버텀업을, 순방향과 역방향 사고를 섞어 씁니다. 전문가일수록 더욱 그러합니다. 비전문가는 어려운 문제 상황에 대한 인식력이 부족하며 자기의 문제 풀이 전략을 능동적으로 선택하지 못합니다. 오히려 억지로 탑다운, 혹은 바텀업 등 한가지에 집착하려고 합니다.

우리의 협력과 전문화 모델은 실험실 속의 전문가 모델에 기반하고 있습니다. 추상 레이어에 따라 팀을 나눕니다. 각 레이어 전문가 팀이 존재합니다. 기획 팀, 구현 팀, 디자인 팀 등. 그리고 그 직선 상에서 레이어의 경계와 만나는 지점마다 바톤 터치가 이루어 집니다. 과연 여기에서 나오는 프러덕트가 최상의 프러덕트일까요?

위 그림은 조직 내에 A, B, C라는 레이어별로 전문가, 혹은 전문팀을 따로 두고 바톤 터치 모델로 탑다운 접근을 통해 협력하는 경우를 보여주고 있습니다. A가 자기 일을 끝내면 B에게 바톤 터치를 해주고, B가 끝내면 다시 C에게로 전달됩니다.

엘레베이터 설계자들을 모아 놓고 그 사람이 설계할 때 사고 수준이 시간 흐름에 따라 어떻게 변화하는지 실험했습니다.

전문가들은 추상과 구상을 오르락내리락 했습니다. 특히 방향이 꺾이는 지점이 "아하 순간"(Aha Moment)이었습니다. 뭔가 설계에 기똥찬 개선이 이뤄지는 순간이었다는 말이죠.

위 그림은 엘레베이터 설계시 전문가들의 문제 해결(및 사고) 흐름을 보여주고 있습니다. 엘레베이터 설계에서 추상성이 높은 것은 알고리즘이나 기능 등이 될 것 같고, 추상성이 낮은 것은 모터의 가속도 제어나 회로 차원이 되겠지요. 보시다시피 전문가는 추상성의 정도를 오르락 내리락 거리고, 특히 탑다운과 바텀업의 방향이 전환되는 시점들에서 "아하 순간"이 찾아왔습니다.

레고 마인드스톰을 갖고 실험한 연구도 있습니다. 전문가와 비전문가에게 "잘 정의되지 않은 문제"를 줬습니다. 어떤 어떤 기계를 만들어 봐라, 그런 문제를 줬지요. 비전문가일수록 자신이 만든 애초에 계획에 집착을 했습니다. 오히려 전문가일수록 자신의 계획 수정 횟수가 많았습니다. 또한 전체 개발 기간 동안 자신의 개발품에 손 댄 부분을 따져보면 비전문가는 아주 소수의 부분만 바꿨습니다만 전문가는 전체적으로 손을 대고 바꿔나갔습니다.

페닝톤(Pennington)의 "프로그래밍에서의 이해 전략"Comprehension strategies in programming이라는 연구에서는 전문 프로그래머 중, 성과가 높은 사람(highly performing)과 그렇지 못한 사람(poorly performing)을 비교했습니다. (참고로 이제까지 소프트웨어 개발쪽 전문가 대 비전문가 비교 연구 중 상당수는 개발 오래한 사람 = 전문가로 보고 연구를 했는데, 비슷한 경력을 가진 전문 프로그래머 중에서 성과나 생산성을 갖고 비교하는 연구들도 있고 또 그런 쪽이 최근 조망을 받고 있습니다 -- 사실 개발자 중에는 10년 경력자 중에서도 3년 경력자보다 못한 사람이 많습니다) 프로그램을 이해할 때, 고수는 상호 참조 전략(cross-referencing strategy)을 쓰는 반면, 하수는 그렇지 않았습니다. 고수는 프로그램을 연구하면서, 그걸 도메인 어휘로 번역하고, 그러고는 도메인 어휘를 프로그램상의 어휘로 다시 바꿔서 검증합니다. 차원을 자주 오가는 것이죠. 반면 하수는 "두 세계"를 빈번히 연결하려는 노력을 하지 않으며, 종종 둘 중 한 쪽에만 집중합니다.

조직 내에 모든 레이어를 꿰뚫는 전문가가 있으면 좋겠으나(그 전문가의 작업 방식에 태클을 걸지 않는 조직이라면 다행), 많은 경우 그런 사치를 부릴 여유가 없습니다. 다루는 문제가 점점 복잡해지면서 팔방미인은 희박해지고 값은 점점 치솟습니다. 그렇다면 우리가 물어야할 질문은 다음과 같습니다. 밖에서 어떤 조직을 관찰했을 때 마치 그 속에 모든 레이어를 꿰뚫는 전문가가 있는 것 같이 만들 수는 없을까?

저는 가능하다고 생각합니다.

하지만 현재의 기능적 팀 구분에서는 이런 효과를 내기가 어렵습니다. 바톤 터치가 너무 자주 일어나게 됩니다. 그러면 빈번히 주고 받는 데에서 생기는 오버헤드가 과도하게 커집니다.

이 문제의 해결을 위해서 기본적으로 두가지 접근이 가능합니다.

  • 한 사람이 다기능을 갖추도록 (우리는 팀인가요의 GE 제트기 공장 예 참고)
  • 협력이 쉽게 되도록

재미있게도 후자를 잘 하다 보면 전자가 자동으로 좋아집니다. (반대로 전자를 잘해서 후자도 잘되게 할 수도 있으나 후자가 잘 되지 않으면서 전자가 잘 되게 하는 것은 비용이 크고 어렵습니다)

오버헤드를 낮추려면 협력 모델이 바톤 터치 모델에 기반하지 않고 삼투압 모델에 기반해야 합니다.

앨리스테어 코번(Alistair Cockburn)이라는 소프트웨어 개발 방법론 전문가가 있습니다. 과거에 IBM을 위해 일할 때, "돈을 얼마든지 써도 좋으니 전세계에서 뛰어난 팀들은 어떻게 일하는지 조사해 봐라"라는 주문을 받았다고 합니다. 그래서 사방팔방 조사를 해봤더니, 독특하게 뛰어난 팀들은 어떤 공통점을 갖고 있었습니다. 그 중 뛰어난 팀이라면 거의 한 팀도 빠지지 않고 공통적으로 갖고 있는 특징이 몇가지 있었는데, "삼투압적 의사소통"이 거기에 속합니다. 배어드는 소통방식입니다. 서양의 의사소통 모형은 대체로 화살 모형을 따릅니다. 발신, 수신인이 정해져 있고, 화살을 쏘는 겁니다. 삼투압적 모형에서는 은연 중에 서로간에 정보가 스며드는 겁니다. 그렇게 하려면 사람들이 물리적으로 가까운 거리에 있는 것이 유리하겠죠. 예를 들어, 프로그래밍하다가, "저기 이거 뭐뭐 안되는데 아는 사람 있어요?"라고 외칩니다. 테이블 건너편에 있던 디자이너가 답을 해줍니다. 기획자가 자기 볼일을 보면서 옆에 앉은 프로그래머 두 사람의 대화를 우연히 엿듣습니다. 그러다가 "아, 그런 문제가 있었나요? 저는 어쩌구.."하면서 끼어들고 새롭고 가치있는 정보를 줍니다.

그리고 한번에 처리되는 일의 양(Batch Size)을 줄여야 합니다. 배치 사이즈를 줄여서 지속적 흐름(continous flow)을 만듭니다. 짧은 시간 내에 탑, 버텀이 바뀌게 하려면 배치 사이즈를 줄여야 합니다. 예를 들어 전에는 디자이너가 100개의 일거리를 다 처리하고 걔네들을 다 모아서 한번에 전달했다면 그걸 50개로, 10개로, 1개로 낮추어야 합니다.

이 아이디어를 웹개발 쪽에 적용한다면 어떻게 될까요?

제시 제임스 개럿(Jesse James Garrett)의 역작, "The Elements of User Experience"라는 책에서는 웹개발에서 추상화의 단계를 다섯 면(plane)으로 나눕니다.
  • 전략 strategy
  • 범위 scope
  • 구조 structure
  • 뼈대 skeleton
  • 표면/비주얼 surface/visual
우리가 갖고 있는 잘못된 전문가의 이미지에서는 다음과 같이 생각하기 쉽습니다: 전략이 깔끔히 완료되고 나서야 범위(무슨 기능이 들어갈지 결정)를 정하고, 다음에 구조(기능들을 어떻게 연결할지, 흐름은 어떻게 될지, 사이트 구조 등)를 정하고, 거기에서 뼈대(화면에 어떤 요소들이 대략 들어가야 하는,지 배치는 어떤지)가 나오고, 마지막에 이르러서 비주얼 디자인에 도달할 수 있다.

더 높은 품질을 얻기 위해서는 이 사다리를 오르락 내리락 반복하는 것이 필요합니다. 한번에 어느 한 단계를 완료하는 것은 더 낮은 품질로 가는 지름길입니다. 특히나 문제와 해결책에 불확실성이 높을 경우.

이 아이디어는 매우 강력합니다. 자신이 해결하려는 것이 무엇이건 간에 이 아이디어를 대응시켜 보십시오. 프랙탈적인 적용도 가능합니다.

--김창준
by 애자일컨설팅 | 2006/06/12 03:05 | 트랙백(3) | 덧글(5)
트랙백 주소 : http://agile.egloos.com/tb/2093309
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from JH-Blog at 2006/07/05 19:41

제목 : 모든 레이어를 꿰뚫는 전문가...
관련글 다음의 한 문장은 현실을 정확히 표현하고 있다. 100인 이하의 벤처 두 군데와 대기업을 거치면서 보면 기업의 규모가 커질수록 이런 현실은 더 큰 문제를 야기한다. ...more

Tracked from 雜想, 雜像, 雜常. at 2006/07/08 23:23

제목 : 책임감 중독 - 다시 써봅니다.
전에 썼던 포스트는 책을 '소개' 하는 포스트라서 여러 모로 불완전했습니다. 책의 내용을 가급적 말하지 말아야 한다는 강박관념에 사로잡혀 있었지요. 이번 포스트에서 한번 제대로 설명을 해 보도록 하겠습니다. 일단 이 포스트를 읽어 보시기 바랍니다. 우리는 팀인가요? - 애자일 컨설팅 이 포스트에서는 팀이라는 조직이 있음에도 불구하고 내부의 조직이 팀처럼 돌아가지 않는다면 팀이라고 부를 수 없다고 설명하고 있습니다. 그렇다면......more

Tracked from Achiven Blog.. at 2010/10/02 20:01

제목 : 전문가에 대한 미신 : 협력을 어떻게 할까
우리는 일종의 미신을 갖고 있습니다. 전문가는 언제나 탑다운(top-down)으로 "깔끔히" 생각할 것이다라는 생각입니다. 탑다운은 문제 해결 과정을 시간의 흐름에서 볼 때 추상적인 숲에서 출발해서 점점 더 구체적인 나무로 내려오는 접근법을 말합니다. 그 반대라 할 수 있는 바텀업(bottom-up)은 나무에서 출발해서 숲으로 올라오는 과정입니다. 탑 다운은 더 깔끔해 보입니다. 바텀업은 "탐험적"인 성격이 많습니다. 여기저기 찔러보고 방향도 ......more

Commented by 최재훈 at 2006/06/12 10:05
오랜만에 재밌는 글이 올라올 것 같아서 기대 100% 충전 중입니다.
Commented by dana at 2006/06/12 10:44
마침 오늘 아침 제가 생각하고 있던 화두랑 비슷하네요. 뛰어난 사람들이 없는 조직, 능력보다도 동기가 부족한 사람들을 데리고 어떻게 일을 해야 하나로 고민 중입니다. 기대되는군요.
Commented by 이종화 at 2006/06/12 11:34
구성원, 환경 등에 따라 협력을 하는데 있어 힘들때가 있습니다.
항상 같은 상황이 아니다 보니 적절한 방법을 모색하고 실행하는데 있어 시행착오를 겪곤 합니다.
이에 대한 고민이 요즘 많은데 많은 도움이 될 것 같습니다. 빨리 알고 싶네요. ^^
Commented by Tolchi at 2006/06/21 23:37
요번글은 모종이 길어지네요....
Commented by 마술감자 명국진 at 2008/06/18 16:24
멍하니 심심해하다가 "어떻게 할까" 로 검색하다가 들르고 좋은 내용 보고 갑니다;;
아직 완성이 되지 않은것 같은데 마지막 업데이트가 2006년 6월이네요..
중간의 IBM관련글을 개인적인 스크랩으로 인용해 갑니다.

:         :

:

비공개 덧글

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


Site Meter