협력을 통한 추상화 |
 |
후배가 말했다. "형은 정말 인간에 대한 끝없는 희망을 갖고 있군요." 그날 기분이 참 좋았다. 이 글 역시 인간에 대한 내 희망을 드러내는 글이라고 할 수 있다. 요지를 말하면, 협력해서 더 나은 것을 이루어 낼 수 있다는 것이다.
경력과 실력
전문성 연구라는 분야가 있다. 전문가가 비전문가와 어떻게 다른지, 어떻게 전문가가 되는지 등을 연구한다. 전문성 연구자들의 단골 연구 대상은 의사, 변호사, 운동 선수, 음악가, 과학자, 체스 선수 등이고, 프로그래머도 그 중 하나에 속한다. 그들은 프로그래밍(설계, 코딩, 테스팅 등을 모두 포함)에서 전문가를 어떻게 정의할까? 가장 손쉬운 방법은 경력이다. 얼마나 오랫 동안 프로그래밍을 해왔는가. 정량적이고 객관적이며, 반론의 여지가 없다. 그래서 예를 들면 10년이 넘는 프로그래머와 5년 경력 프로그래머 집단을 나눠놓고 서로 어떤 다른 행동을 보이는지를 연구한다.
이것이 칠팔십년대부터 시작된 프로그래밍 전문가 연구의 일반적 경향이었다. 하지만 이런 연구의 출발점에 의문을 제기하는 사람들이 있었다. 측정하기 쉬운 것(경력)을 측정하는 오류에 빠진 것은 아닌가? 전문가는 능력으로 말해야 하지 않나? 정말 경력이 많으면 실력도 좋은가?
전문성 연구에서는 1990년대부터 경력과 실력이 꼭 일치하지 않는다는 연구 결과가 늘어나기 시작했다. 심지어는 아무 상관성이 없다(통계적인 의미에서)는 결과가 나오기도 했다(현재 전문성 연구에서는 실력과 경력 간에 큰 상관성이 없다는 것이 정설로 받아들여지고 있다). 프로그래밍 분야에서도 마찬가지였다. 이와 동시에 전문가를 실력이 뛰어난 사람으로 재정의하고, 그 사람들의 특징을 연구한 논문들이 발표되기 시작한다. 통상 이런 연구에서 실력이 뛰어나다는 것은 다면적으로 평가한다. 동료들이 어떻게 평가하는지, 상관은 어떻게 평가하는지, 그 사람이 만든 코드에 버그가 얼마나 있는지, 이미 세계적 수준에 오른 전문가가 그 사람의 코드를 어떻게 평가하는지 등.
재미있는 사실은 기존의 경력이 많은 사람(experienced)과 그렇지 않은 사람(inexperienced) 구분에서 뽑아낸 전문가들의 특징과, 실력이 높은 사람(high performers)과 그렇지 않은 사람(moderate performers) 구분에서 뽑아낸 특징 간에는 불일치하는, 심지어는 정반대의 것들도 있었다는 점이다. 따라서 주변에서 경력 많은 사람을 흉내내려고 하지 말고, 실력이 뛰어난 사람을 모방해야 한다.(자신의 목표가 경력 연차가 높아지는 것이 아니라 실력 향상이라면)
커뮤니케이션과 협력
이제까지 전문 프로그래머 연구에서 가장 관심을 받지 못했던 분야는 이른바 소프트 스킬(soft skill)이었다. 커뮤니케이션이나 협력 능력 같은 것을 말한다. 커뮤니케이션과 협력에 관해, 실력이 높은 프로그래머들은 그렇지 못한 사람들에 비해 뭐가 다를까?
실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 커뮤니케이션, 협력 능력이 훨씬 더 뛰어나다. 우리가 생각하는 전형적 영웅 프로그래머와는 이미지가 정반대다. 게다가 실력이 뛰어난 프로그래머는 커뮤니케이션과 협력에 더 많은 시간을 들인다. 반면 설계나 코딩, 테스팅에 들이는 시간에는 통계적으로 큰 차이가 없었다. 또 다른 연구에서는, 경험이 적은 동료 프로그래머에게 어떤 조언을 하겠느냐는 질문을 했고, 그 대답과 그 사람들의 퍼포먼스 간의 관계를 분석했다. 예상했겠지만, 탁월한 프로그래머들일수록 다른 사람들과 협력을 하라는 조언을 자주 했다.
많은 프로그래머들이 통상 커뮤니케이션과 협력을 마지 못해 하는 것으로 생각한다. 골방에서 혼자 틀어박혀 코딩하는 것이 소원인 사람도 있을 것이다. 커뮤니케이션과 협력이 별 도움이 되지 않는다면, 도대체 탁월한 프로그래머들은 왜 그것들을 추천하는 것일까?
백지장도 맞들면 찢어진다?
협력하면 밑천도 못 건진다고 생각하는 사람이 많다. 많은 실험에서 집단의 퍼포먼스가 개인의 퍼포먼스보다 못한 경우를 찾아냈다. 예를 들어 능력이 10, 20, 30, 100인 사람들이 있을 때, 같이 일하면 전체의 능력은 100보다 작다. 최소 모델과 최대 모델의 중간인 셈이다. 부분의 합(시그마 모델)보다 큰 전체(파이 모델)라는 이야기는 꺼낼 건더기도 없다. 그래서 실력이 뛰어난 사람은 혼자 일하게 해야 한다고 주장하는 사람도 많다.
하지만 반대의 연구 결과가 점점 늘어나고 있다. 예전 연구의 실험 조건이 상대적으로 협력에 불리하게 짜여져 있는 경우가 많았으며, 그냥 협력이라고 다 좋은 것이 아니고 몇 가지 전제 조건이 필요하다는 것이다. 예컨대 두 사람이 시각화 없이 협력하는 것보다 그런 중간 매개를 두고 협력하는 것이 훨씬 낫다는 등이다.
협력해서 더 나은 연구를 하나 자세히 살펴보자. 이 실험 결과는 특히 프로그래머들에게 암시하는 바가 크다.
톱니바퀴 실험
스탠포드 대학의 심리학자인 대니얼 슈와르츠(Daniel Schwartz)는 같은 문제를 혼자 푸는 경우와 두 사람이 함께 푸는 경우의 차이에 대한 연구를 시행했다. [1] 톱니바퀴 문제인데, 다음과 같은 방식이다.
|
다섯 개의 톱니바퀴가 가로로 길게 연결되어 있다. 가장 왼쪽에 있는 톱니바퀴를 반시계 방향으로 돌리면 가장 오른쪽의 톱니바퀴는 어느 쪽으로 돌까?
|
이런 문제를 일곱 개 내준다. 문제에서 톱니바퀴 숫자는 각기 3, 4, 5, 6, 7, 8, 9로 바뀐다(숫자가 점점 커지는 것과 뒤섞인 것 두 가지로 실험). 그리고 마지막 여덟 번째 문제가 나온다. 바퀴 숫자는 131개.
처음에는 다들 허공에 손을 돌리면서 문제를 풀기 시작한다. 그 중 어떤 사람은 도중에 패리티 법칙(Parity Rule: 톱니바퀴 개수의 홀짝 여부에 따라 최우측 바퀴의 회전방향이 결정되는 법칙)을 발견하고 그 때부터는 허공에 손을 내젖지 않는다. 그들은 131개 톱니바퀴 문제도 순식간에 답할 수 있다.
일곱 번째 문제를 풀 때까지 추상화된 규칙을 찾아 내는지 그렇지 못한지를 살펴 보았더니, 혼자서 작업한 경우는 14%만이 추상화 규칙을 찾아냈다. 반면 둘이서 함께 작업한 경우 58%나 되는 경우에 추상화 규칙을 찾아냈다. 4배가 넘는다. 만약 두 사람이 한 팀으로 작업하되 서로 인터액션하지 않았고, 그들의 결과물 중 더 나은 것을 택하는 방식(명목 집단nominal group이라고 한다)이라면? 이 경우는 확률적으로 계산해 낼 수 있는데, 26%가 된다.
혼자서 작업한 경우보다 둘이서 작업한 경우에 추상화 경향이 훨씬 높았다. 왜 이런 차이가 생겼을까?
앞서의 톱니바퀴 문제 경우, 두 사람이 서로 마주 앉았는데, 둘 다 허공에 손을 들고 톱니바퀴가 도는 흉내를 낸다. 그 흉내를 내는 방식도 처음엔 제각각이다. 그러면서 맞은 편의 사람과 이야기를 하는데 예컨대 어느 쪽이 최우측이고 최좌측인지에 대해 혼동이 있게 된다. 이런 혼동을 해결하기 위해 추상적 개념을 도입하게 된다.
이 연구에서는 이 톱니바퀴 실험 외에도 두 가지 실험을 더 했는데, 그 중 한 실험에서는 구체적인 사실(연못의 특징과 거기에서 살 수 있는 물고기 종류) 관계를 주고, 이에 관련된 복잡한 문제를 풀기 위한 시각적 추상화를 하도록 했다. 물론 혼자 혹은 두 사람이 같이(짝) 문제를 풀도록 했다. 논문의 일부를 인용해 보자.
|
그림 4a에 나온 매트릭스(matrix)를 만든 짝은, 복수개의 관점이라는 조건이 어떻게 표현상(representational)의 추상화를 지원했는지 잘 보여주는 명료한 예라 할 수 있다. 이 두 사람이 자기들의 시각화를 제출할 때, 실험자는 그들이 어떻게 매트릭스를 만들게 되었는지 물어봤다. 둘 중 하나가 답했다. "이 친구는 열(column)을 만들고 싶어했고, 나는 행(row)을 만들고 싶어했죠." 문제에 대한 두 개의 관점을 협상하기 위해, 그들은 행과 열을 모두 포함한 매트릭스 형태를 찾아냈던 것이다.
|
둘이서 협력하면서 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해 줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 된다. 서로 다른 것들을 하나로 묶어야 하기 때문이다. 반면 혼자서 작업할 경우에는 이런 추상화의 필요가 덜하다.
추상화
올 초 윤주선님의 블로그에 필자가 댓글을 하나 달았다.
|
... 또, 때로는 말로 길게 풀어쓰는 것이 가독성을 떨어뜨리기도 합니다. 뭔가 장황해 보이니까요. 우리는 산문보다 운문(가령 하이쿠)에서 배울 것이 많습니다. 만약 코드가 비지니스 로직이 들어가고 그 로직이 domain-rich하다면 되도록 가독성을 추구하겠지만(가독성은 독자에 따른 상대적 개념이라는 것을 명심하면서), 저는 때로 가독성을 손해보면서까지 중복을 줄이기도 합니다. 객체지향에서 그걸 하다 보면 흥미로운 객체들을 발견합니다. 함수형에서 그렇게 하다 보면 흥미로운 함수와 함수의 함수(functional)를 발견합니다. 이 "흥미로운 무엇"은 강력합니다. 내가 전에 모르던 것을 배우게 됩니다. 그리고 종종 이것은 프로그래머의 울타리를 넘어서 영향력을 끼치기도 합니다. 고객들의 대화가 바뀔 수도 있습니다. 객체지향을 하면서 흥미로운 객체들을 발견하지 못한다면 너무 고리타분한 코딩은 아닐까 생각합니다.
|
원글의 맥락 때문에, 댓글에서 흥미로운 무엇을 발견하는 대표적 방법으로 중복 제거만을 이야기하고 있는데, 당연히 내가 생각하는 흥미로운 무엇 발견법에는 배경과 시각이 다른 사람과의 대화도 포함된다.
그런데, 여기에서 말하는 "흥미로운 무엇"이 바로 추상화다. 우리가 예상하지도 못했던 추상화. 추상화라는 것은 프로그래머들에게 매우 중요한 주제다. 추상화에 대한 소프트웨어 분야의 명언이 많이 있다. 그 중 필자가 특별히 좋아하는 것을 몇 개 추려 보았다. [2]
- 전산학의 모든 문제는 또 다른 차원의 간접성(indirection)으로 해결할 수 있다. -- 버틀러 램슨
- 전산학은 추상화의 과학이다. -- 알프레드 아호와 제프리 울먼
- ... 소프트웨어 공학의 전체 역사는 추상화 수준을 높이는 것으로 특징지울 수 있다. -- 그래디 부치
- 복잡한 현상에 대한 이해를 발전시켜 나갈 때, 인간 지성에서 가장 강력한 도구는 추상화다. 실세계의 특정한 대상체, 상황, 과정간의 유사성을 인식하는 데에서, 그리고 이러한 유사성에 집중하고 차이점은 일시적으로 무시하는 결정에서 추상화가 생겨난다. -- 토니 호아
인용문대로 소프트웨어 공학의 역사는 정말 추상화를 높이기 위한 여정이었다. 여기에 반론을 달 프로그래머는 별로 없으리라 생각한다(위 인용문의 저자 중 두 명이 튜링상 수상자들이다). 그런데 우리는 방금 막 추상화를 높힐 수 있는 방법을 하나 찾아내었다. 다른 시각을 가진 두 사람이 협력하기.
대화하는 프로그래밍
짝 프로그래밍은 두 사람이 함께 한 컴퓨터를 사용해 프로그래밍하는 것이다. 생각해볼수록 짝 프로그래밍의 구성은 절묘하다. 두 사람이라는 구성은 대화를 통해 추상화를 높힌다. 한 컴퓨터라는 구성은 구체화를 통해 검증한다. 미루고 헤아리는 것이 빈번히 교차한다. 그리고 그 사이에서 "아하"가 터져나온다.
켄트 벡과 함께 XP의 짝 프로그래밍 개념을 형상화한 워드 커닝햄이 말했다.
|
익스트림 프로그래머는 작업하면서 프로그래밍 각 단계에 대해 함께 이야기한다.
Extreme Programmers discuss each step of programming as they work.
|
그가 말하는 대로, 주의해서 생각하지 않으면 프로그래밍은 특정 프로그래밍 언어로 명령문을 타이핑해 넣는 것에 지나지 않는다고 생각할 수 있다(If you don't think carefully, you might think that programming is just typing statements in a programming language). 프로그래밍 전문성 연구에서조차도 이제까지 커뮤니케이션과 협력의 중요성을 놓치고 있었다.
워드가 개발한 FIT나 위키위키의 중요성은 그 기술에 있지 않다. 그것들이 만들어낼 사회 구조의 변화와 그것들이 이끌어낼 사람들 간의 대화에 있다. 그리고 그 대화는 우리가 혼자서는 생각하지 못했던 것들을 만들게 해 줄 것이다.
자신이 작성하는 코드의 추상성을 높이고 싶다면 혼자서 고민하지 말고 다른 사람들과 협동하고, 대화하라. 같이 그림도 그려보고 함께 소스 코드를 편집하라. 인간에게는 다른 인간과 소통하고 협력할 수 있는 놀라운 능력이 갖추어져 있다. 대화는 기적이다.
주
[1] The emergence of abstract representations in dyad problem solving. Journal of the Learning Sciences, 4, 321--354. Schwartz, D. L. & Bransford, J. D. (1998). 원문 pdf
[2] 인용문들의 원문:
- All problems in computer science can be solved by another level of indirection. -- Butler Lampson
- Computer Science is a science of abstraction -- A. Aho and J. Ullman
- ...the entire history of software engineering can be characterized as one of rising levels of abstraction. -- Grady Booch
- In the development of the understanding of complex phenomena, the most powerful tool available to the human intellect is abstraction. Abstraction arises from the recognition of similarities between certain objects, situations, or processes in the real world and the decision to concentrate on these similarities and to ignore, for the time being, their differences. -- C.A.R. Hoare
 [지난 developerWorks Column 보기]
|
김창준 
