전문가들 조차도 완벽한 설계를 하고 시작하는게 아니라는 거네요.
반복되는 수정 보완이 결국에는 완벽한 설계가 된다는거죠.
그리고 삼투압적 의사 소통이라는 재미있는 용어가 보이네요.
+
우리는 일종의 미신을 갖고 있습니다. 전문가는 언제나 탑다운(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)을 쓰는 반면, 하수는 그렇지 않았습니다. 고수는 프로그램을 연구하면서, 그걸 도메인 어휘로 번역하고, 그러고는 도메인 어휘를 프로그램상의 어휘로 다시 바꿔서 검증합니다. 차원을 자주 오가는 것이죠. 반면 하수는 "두 세계"를 빈번히 연결하려는 노력을 하지 않으며, 종종 둘 중 한 쪽에만 집중합니다.
조직 내에 모든 레이어를 꿰뚫는 전문가가 있으면 좋겠으나(그 전문가의 작업 방식에 태클을 걸지 않는 조직이라면 다행), 많은 경우 그런 사치를 부릴 여유가 없습니다. 다루는 문제가 점점 복잡해지면서 팔방미인은 희박해지고 값은 점점 치솟습니다. 그렇다면 우리가 물어야할 질문은 다음과 같습니다. 밖에서 어떤 조직을 관찰했을 때 마치 그 속에 모든 레이어를 꿰뚫는 전문가가 있는 것 같이 만들 수는 없을까?
저는 가능하다고 생각합니다.
하지만 현재의 기능적 팀 구분에서는 이런 효과를 내기가 어렵습니다. 바톤 터치가 너무 자주 일어나게 됩니다. 그러면 빈번히 주고 받는 데에서 생기는 오버헤드가 과도하게 커집니다.
이 문제의 해결을 위해서 기본적으로 두가지 접근이 가능합니다.
재미있게도 후자를 잘 하다 보면 전자가 자동으로 좋아집니다. (반대로 전자를 잘해서 후자도 잘되게 할 수도 있으나 후자가 잘 되지 않으면서 전자가 잘 되게 하는 것은 비용이 크고 어렵습니다)
오버헤드를 낮추려면 협력 모델이 바톤 터치 모델에 기반하지 않고 삼투압 모델에 기반해야 합니다.
앨 리스테어 코번(Alistair Cockburn)이라는 소프트웨어 개발 방법론 전문가가 있습니다. 과거에 IBM을 위해 일할 때, "돈을 얼마든지 써도 좋으니 전세계에서 뛰어난 팀들은 어떻게 일하는지 조사해 봐라"라는 주문을 받았다고 합니다. 그래서 사방팔방 조사를 해봤더니, 독특하게 뛰어난 팀들은 어떤 공통점을 갖고 있었습니다. 그 중 뛰어난 팀이라면 거의 한 팀도 빠지지 않고 공통적으로 갖고 있는 특징이 몇가지 있었는데, "삼투압적 의사소통"이 거기에 속합니다. 배어드는 소통방식입니다. 서양의 의사소통 모형은 대체로 화살 모형을 따릅니다. 발신, 수신인이 정해져 있고, 화살을 쏘는 겁니다. 삼투압적 모형에서는 은연 중에 서로간에 정보가 스며드는 겁니다. 그렇게 하려면 사람들이 물리적으로 가까운 거리에 있는 것이 유리하겠죠. 예를 들어, 프로그래밍하다가, "저기 이거 뭐뭐 안되는데 아는 사람 있어요?"라고 외칩니다. 테이블 건너편에 있던 디자이너가 답을 해줍니다. 기획자가 자기 볼일을 보면서 옆에 앉은 프로그래머 두 사람의 대화를 우연히 엿듣습니다. 그러다가 "아, 그런 문제가 있었나요? 저는 어쩌구.."하면서 끼어들고 새롭고 가치있는 정보를 줍니다.
그리고 한번에 처리되는 일의 양(Batch Size)을 줄여야 합니다. 배치 사이즈를 줄여서 지속적 흐름(continous flow)을 만듭니다. 짧은 시간 내에 탑, 버텀이 바뀌게 하려면 배치 사이즈를 줄여야 합니다. 예를 들어 전에는 디자이너가 100개의 일거리를 다 처리하고 걔네들을 다 모아서 한번에 전달했다면 그걸 50개로, 10개로, 1개로 낮추어야 합니다.
이 아이디어를 웹개발 쪽에 적용한다면 어떻게 될까요?
제시 제임스 개럿(Jesse James Garrett)의 역작, "The Elements of User Experience"라는 책에서는 웹개발에서 추상화의 단계를 다섯 면(plane)으로 나눕니다.
더 높은 품질을 얻기 위해서는 이 사다리를 오르락 내리락 반복하는 것이 필요합니다. 한번에 어느 한 단계를 완료하는 것은 더 낮은 품질로 가는 지름길입니다. 특히나 문제와 해결책에 불확실성이 높을 경우.
이 아이디어는 매우 강력합니다. 자신이 해결하려는 것이 무엇이건 간에 이 아이디어를 대응시켜 보십시오. 프랙탈적인 적용도 가능합니다.
--김창준
반복되는 수정 보완이 결국에는 완벽한 설계가 된다는거죠.
그리고 삼투압적 의사 소통이라는 재미있는 용어가 보이네요.
+
우리는 일종의 미신을 갖고 있습니다. 전문가는 언제나 탑다운(top-down)으로 "깔끔히" 생각할 것이다라는 생각입니다.
탑다운은 문제 해결 과정을 시간의 흐름에서 볼 때 추상적인 숲에서 출발해서 점점 더 구체적인 나무로 내려오는 접근법을 말합니다. 그 반대라 할 수 있는 바텀업(bottom-up)은 나무에서 출발해서 숲으로 올라오는 과정입니다.
탑 다운은 더 깔끔해 보입니다. 바텀업은 "탐험적"인 성격이 많습니다. 여기저기 찔러보고 방향도 바꾸고 하지요. 이런 면에서 사람들은 전문가일수록 탑다운으로 사고하고 문제를 해결할 것이라 믿습니다. 실제 실험실 연구에서도 비슷한 결과가 나왔습니다.
예 를 들어 물리학 문제를 풀게 했을 때 대학생 등 비전문가들은 문제에서 묻는 것, 즉 최종의 답에서 출발을 합니다. 예를 들어 문제에서 원하는 것이 "속도"라면 속도가 적용되는 수식을 생각해 내고 거기에서부터 다시 문제에서 애초에 주어진 정보 쪽으로 거꾸로 길을 찾아 갑니다. 잘 모르는 정보에서 출발해서 잘 아는 정보쪽으로 문제를 변형해 가며 끌어오는 겁니다. 반면 물리학자 같은 전문가들은 문제에서 주어진 정보에서 출발합니다. 거기에 적용이 되는 원칙을 생각합니다. 그러면서 수식을 하나씩 적용해 나가서는 최종적으로 문제가 원하는 답에 도착합니다. 우리가 생각하는 정답 해설의 순서와 유사합니다. 깔끔하지요. (사실 이 실험에서 말하는 것은 순방향과 역방향 사고에 대한 것이고 탑다운과 버텀업은 조금 다른 측면이긴 합니다)
인공지능 연구에선 이 세상의 문제를 두 종류로 나눕니다. 잘 정의된 문제(Well-defined), 잘 정의되지 않은(Ill-defined) 문제. 잘 정의된 문제는 출발 상태와 목표 상태가 명확히 알려져 있고 그 상태간 이동의 규칙이 주어진 문제를 일컫습니다. 오목이나, 체스 같이 승패와 말의 이동 규칙이 명확한 게임, 또 선교사와 식인종 문제 같은 것들은 여기에 속합니다. 하지만 "벽을 장식할 아름다운 그림을 그리시오" 같은 문제는 잘 정의되지 않은 문제입니다. 무엇이 목표 상태인지가 불분명합니다. 심지어는 최초의 출발 상태에 대한 정보도 온전히 주어지지 않고, 무엇이 적법한 말의 이동인지 무엇이 부적법한 것인지 규칙의 경계도 불투명합니다.
잘 정의된 문제는 연구하기가 쉽기 때문에 많은 연구가 이루어져 있습니다. 하지만 우리가 실생활에서 만나는 대다수의 문제는 잘 정의되지 않은 문제입니다. 사실상 뭔가 만들어 내야 하는 문제, 즉 디자인(설계)이 개입되는 것은 거의 다 제대로 정의될 수 없는 문제입니다.
앞서의 전문가들은 자신이 자주 접하지 않았던 문제, 어려운 문제, 혹은 잘 정의되지 않은 문제를 접하면 접근법을 바꿉니다. 탑다운과 버텀업을, 순방향과 역방향 사고를 섞어 씁니다. 전문가일수록 더욱 그러합니다. 비전문가는 어려운 문제 상황에 대한 인식력이 부족하며 자기의 문제 풀이 전략을 능동적으로 선택하지 못합니다. 오히려 억지로 탑다운, 혹은 바텀업 등 한가지에 집착하려고 합니다.
우리의 협력과 전문화 모델은 실험실 속의 전문가 모델에 기반하고 있습니다. 추상 레이어에 따라 팀을 나눕니다. 각 레이어 전문가 팀이 존재합니다. 기획 팀, 구현 팀, 디자인 팀 등. 그리고 그 직선 상에서 레이어의 경계와 만나는 지점마다 바톤 터치가 이루어 집니다. 과연 여기에서 나오는 프러덕트가 최상의 프러덕트일까요?
엘레베이터 설계자들을 모아 놓고 그 사람이 설계할 때 사고 수준이 시간 흐름에 따라 어떻게 변화하는지 실험했습니다.
전문가들은 추상과 구상을 오르락내리락 했습니다. 특히 방향이 꺾이는 지점이 "아하 순간"(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
더 높은 품질을 얻기 위해서는 이 사다리를 오르락 내리락 반복하는 것이 필요합니다. 한번에 어느 한 단계를 완료하는 것은 더 낮은 품질로 가는 지름길입니다. 특히나 문제와 해결책에 불확실성이 높을 경우.
이 아이디어는 매우 강력합니다. 자신이 해결하려는 것이 무엇이건 간에 이 아이디어를 대응시켜 보십시오. 프랙탈적인 적용도 가능합니다.
--김창준