1. 자라기

• 야생 학습은 대부분 협력적이다 (학교 학습은 대부분 개별적이다)
• 야생 학습은 대부분 비순차적이다 (학교 학습은 대부분 공부 순서가 정해져 있다)
• 야생 학습은 대부분 자료에 한정이 없다 (학교 학습은 대부분 교과서, 교재, 시험 범위 등이 정해져 있다)
• 야생 학습은 대부분 명확한 평가가 없다 (학교 학습은 대부분 시험이라는 명확한 평가기준이 있다)
• 야생 학습은 대부분 정답이 없다 (학교 학습은 무엇이 정답이라고 하는 것이 명확하다)
• 야생 학습은 대부분 목표가 불분명하고 바뀌기도 한다 (학교 학습은 대부분 합격, 자격증 같은 목표가 분명하다)

학습 방법을 학습해야 한다. 도인 메타포를 대체할만한 새로운 메타포를 찾아보자.

당신은 몇 년 차?

경력, 그 견딜 수 없는 무거움

직원을 뽑을 때 무엇이 그 사람의 실력을 가장 잘 예측할까?

존 헌터(John Hunter)의 연구 - 채용시 가장 효과적인 예측변수가 무엇인가. (론다 헌터와 프랭크 슈미트와 함께 연구함.)

상관성이 높았던 것들

• 작업 샘플 테스트 0.54 (work sample test)
• 아이큐 같은 지능 테스트 0.51
• 구조화된 인터뷰 0.51
• 성격 테스트(성실성, 꼼꼼함 등) 0.41~0.31
• 레퍼런스 체크 0.26
• 경력 연차 0.18
• 학력 0.10
• 필체 0.02
• 나이 -0.01

경력과 실력은 일치하지 않는다.

소프트웨어 개발에서 경력과 실력

톰 드마르코와 티모시 리스터가 한 유명한 연구에서는, 1984년부터 1986년까지 92개 회사에서 600명 이상의 개발자를 대상으로 프로그래밍 생산성 비교를 했다. 가장 놀라운 점은 개발자 개개인의 능력 차이이다. 최고는 최악보다 열 배 정도 업무 능력이 뛰어난다.

그들은 이 연구에서 경력과 업무 수행 능력에 깊은 상관성이 없다고 밝혔다.

이렇게 전문가에 대한 새로운 정의, 즉 퍼포먼스의 수준으로 접근한 연구들을 통해 앞서 말한 바와 같이, 최소한도의 경험치만 넘어가면 경력 연수와 실제 직무 성과의 상관성이 생각보다 낮다는 것은 소프트웨어 개발 뿐만 아니라 다른 여러 영역들에서도 동일하게 밝혀졌다.

반면, 한 가지 흥미로운 연구에서는 경력이 직무 성과와 관련이 있음을 발견했따. 단, 여기에서 경력이란 경력 연차를 말하는게 아니라, 개발자의 경험이 얼마나 폭넓고 다양했는지가 실제 직무성과와 관련이 있었다. 경력의 양적인 면이 아니라 질적인 면의 중요성을 발견한 것이다.

중요하다고 생각하는 것이 중요하지 않다

경력을 지나치게 중요하게 여기는 회사가 많다. 동시에 협력 능력을 지나치게 등한시하는 회사가 많다.

최소한의 경력 수준만 넘겼으면 오히려 몇 년 일했는지는 모르는 것이 더 낫다고 본다. 경력은 오히려 경계해야 할 대상 중 하나다. 그 대신에,

• 구조화된 인터뷰. 특히 구조화된 행동중심적 인터뷰 (structured behavioral interview)
• 실제 작업을 해보도록 하는 작업 샘플 테스트

• 가능하다면 실제 업무를 주고 시험적으로 짧은 기간 동안 일을 해보게 하는 것

잘 뽑는 것 이상으로 중요한 것

이미 뽑은 사람을 어떻게 할 것인가도 중요하다. 뽑은 후에 어떻게 교육, 훈련시키고 성장시킬 것인지 고민해야 한다.

또한, 훌륭한 사람을 뽑아도 조직의 시스템과 문화에 문제가 있으면 그런 사람은 묻혀버리기 쉽고, 반대로 실력이 평범한 사람도 좋은 시스템 속에서 뛰어난 성과를 낼 수도 있다.

에드워드 데밍은, 직원들이 문제가 아니라, 그 사람들이 속한 시스템, 그리고 그걸 만들고 책임지는 경영진이 문제라고 말했다.

개발자들이 할 수 있는 것

자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련, 의도적 수련이 실력의 향상과 상관 있다. 업무를 하면서도 의도적 수련을 할 수 있는 방법(1, 2)이 있다. 애자일은 학습을 소프트웨어 개발의 가장 큰 병목 중 하나로 본다. 피드백 사이클이 길다. 하지만 애자일 프로젝트에서는 지금 내가 한 행동의 피드백을 10분 후, 한 시간 후, 하루 후 등 여러 주기를 통해 지속적으로 얻을 수 있다. 그리고 그 과정에서 교정할 수 있다. 피드백을 짧은 주기로 얻는 것, 실수를 교정할 기회가 있는 것, 이 두 가지가 학습에 큰 차이를 가져온다.

자기계발은 복리로 돌아온다

저는 뭔가 일이 끝나면 항상 회고를 한다. 그 때 항상 되짚어 보는 것 중 하나가 나 자신에게 얼마나 투자를 했나 하는 것이다. 소위 자기계발이라고 하는 것이다.

복리의 비밀

더글라스 엥겔바트는 작업을 세 가지 수준으로 구분한다.

1. A 작업은 원래 그 조직이 하기로 되어 있는 일을 하는 것이다. 자동차 공장이면 자동차를 만드는 것이 A 작업이다.
2. B 작업은 A 작업을 개선하는걸 말한다. 제품을 만드는 사이클에서 시간과 품질을 개선하는 것이다. 제품을 만드는 시스템을 잘 설계하는 것도 포함된다.
3. C 작업은 B 작업을 개선하는 것이다. 개선 사이클 자체의 시간과 품질을 개선하는 것이다. 예컨대 개선하는 인프라를 설계하는 것디 포함된다. 한마디로 개선하는 능력을 개선하는걸 말한다.

더글러스는 '우리가 더 잘하는 것을 더 잘하게 될수록 우리는 더 잘하는 걸 더 잘 그리고 더 빨리 하게 될 것이다'라고 표현했다.

피터 센게는 더글러스의 말을 인용했던 것을 재인용했다.

"조직에는 세 가지 차원의 작업이 있다"고 컴퓨터 선구자이자 마우스 발명가인 더글라스 엥겔바트가 말했다.

A 작업은 겉으로 가장 잘 드러나는 수준으로, 한 회사의 제품과 서비스의 개발, 생산, 판매와 관련이 있다. 그 회사의 사람과 자원의 대부분은 이 수준에 초점이 맞춰져 있다.

하지만 다음 수준인 B 작업 없이는 효과적인 A 작업은 불가능할 것이다. B 작업은 회사가 자신의 제품과 서비스를 개발, 생산, 판매하는 걸 가능케 해주는 시스템과 프로세스를 설계하는 것과 관련이 있다.

하지만 가장 미묘하고 또 잠재적으로 가장 영향력이 큰 것은 C 작업으로, 이는 우리의 사고방식과 상호 작용 방식을 개선한다. 궁극적으로는 C 작업의 품질이 우리가 설계하는 시스템과 프로세스의 품질을 결정짓고, 나아가 우리가 제공하는 제품과 서비스의 품질을 결정짓는다.

앵겔바트가 처음 했던 작업은 사람들이 모여서 협업하기 좋은 환경과 도구를 만드는 것이었다. 당시에 없던 그래픽 사용자 인터페이스라든가 화상 통신 등의 온라인 협업 도구를 만들었다. 더글러스의 그룹은 이 도구를 사용해 점점 더 작업의 효율을 높일 수 있었고, 더 똑똑해질 수 있었다.

이런 기술을 부트스트래핑(bootstrapping)이라고 한다. 자기가 신은 신발에 달린 끈(뒤축의 가죽 끈)을 들어 올려 자신의 몸을 공중에 띄운다는 뜻에서 생긴 단어이다. 외력의 도움 없이 스스로 상황을 개선하는걸 뜻한다.

더하는 조직을 작업 그룹이라고 하고 곱하는 조직을 팀이라고 구분한다. 작업 그룹은 주어진 일을 사람 숫자에 맞게 나눠주고 각자 정해진 일을 하는 형태를 말한다. 서로 교류할 필요가 없다. 반면에 팀은 일을 상호 협력적으로 진행한다. 거기서 소위 시너지 효과가 나온다. (RichardHackman은 일반적으로 작업그룹보다 팀이 더 효과성이 높다고 한다. 그리고 조직의 효과성을 가장 잘 예측하는 변수는 동료 코칭 peer coaching이라고 한다. 서로 업무적으로 도움을 주고받는 것이다. 이 동료 코칭과 퍼포먼스간의 상관계수는 0.82이다. 퍼포먼스 차이의 약 67%를 설명할 수 있다는 뜻이다. 팀이 일반적으로 더 효과적인 이유는 이 동료 코칭에서 온다고 볼 수 있다.)

어떻게 해야 우리가 더하기보다 곱하기를 더 많이 할 수 있을까. 가용시간을 늘리고, 낭비되는 시간을 줄이고 잠자는 시간을 줄이는 것이 더하기적 사고라면, 집단의 지능을 높이는 것은 곱하기적 사고이다. 집단의 지능을 높이면 모든 지적 활동의 효율이 좋아지기 때문에 전반적인 개선(B 작업)이 일어나고, 특히 개선 작업을 더 잘하게(C 작업) 된다. 지금보다 속도가 더 날 수 있다. 그냥 일하는 시간을 늘리는 것은 작업량을 늘리는 것에 지나지 않는다.

평소 투자하는 비용을 살펴보라. A 작업, B 작업, C 작업의 비율이 얼마인지. B나 C가 없다면 후퇴하는 셈이 된다.

어떻게 더하기보다 곱하기를 할 수 있을 것인가. 그리고 어떻게 해야 곱하는 비율(이자율)을 높일 수 있는가 혹은 이자 적용 주기를 짧게 할 수 있는가.

자신이 이미 갖고 있는 것들을 잘 활용하라.

• 새로운 것을 유입시키는 데에만 집중하다 보면 새로 들어온 것들이 이미 있는 것들을 덮어버릴 수 있다. 자신이 올해 몇 구너을 읽었다고 자랑하지 말고, 내가 그 지식을 얼마나 어떻게 활용하는지 반성하라
• 이미 갖고 있는 것들을 하이퍼링크로 서로 촘촘히 연결하라. 노드 간 이동 속도가 빨라질 수 있도록 고속도로를 놔라. 즉, 이미 습득한 지식, 기술, 경험 등을 서로 연결 지어서 시너지 효과가 나게 하고 하나의 영역에서 다른 영역으로 왔다갔다 하는 것을 자주 해서 다른 영역 간을 넘나들기가 수월해지도록 하라.
• 새로운 것이 들어오면 이미 갖고 있는 것들과 충돌을 시도하라
• 현재 내가 하는 일이 차후에 밑거름이 될 수 있도록 하라

외부 물질을 체화하라

• 계속 내부 순환만 하다가는 일정 수준에 수렴할 위험이 있다. 주기적인 외부 자극을 받으면 좋다. 단, 외부 자극을 받으면 그걸 재빨리 자기화해야 한다. 마치 인체가 음식을 먹어 자기 몸의 일부로 만들듯이, 외부 물질을 받아들이면 소화해서 자신의 일부로 체화해야 한다.
• 외부 물질 유입 이후 생긴 내부의 갈등을 해결하려는 데에 노력을 기율여야 한다. 무시하고 덮어두지 마라. 내가 가진 것들의 상생적 관계를 끌어내도록 하라.

자신을 개선하는 프로세스에 대해 생각해 보라

• 예컨대 나의 A 작업을 되돌아보는 회고/반성 활동을 주기적으로 하는 프로세스를 만들어라 (C 작업)
• 나를 개선하는 과정(B 작업)을 어떻게 하면 개선할 수 있을지 고민하라

피드백을 자주 받아라

• 사이클 타임을 줄여라. 새로운 정보를 얻었다면 1년 후에 크고 완벽한 실험을 하려고 준비하기보다는 1달, 혹은 1주 후에 작게라도 실험해 보는 것이 좋다. 순환율을 높여라.
• 일찍, 그리고 자주 실패하라. 실패에서 학습하라.

자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라

• 일례로, 전설적 프로그래머 워드 커닝햄은 자기의 수족을 마음대로 놀릴 수 없는 불편한 언어에서 프로그래밍을 하는 경우 점차적으로 자신을 도와주는 환경을 만들어 나간다. 나의 속도를 늦추는 것들을 중력에 비유한다면, 워드는 중력을 점점 줄여나간다고 할 수 있다. 중력을 요만큼 줄였기 때문에 그 덕으로 몸이 더 가벼워지고, 또 그 때문에 중력을 줄이는 작업을 좀 더 쉽게 할 수 있다. 이런 식으로 되먹임을 해서 결국은 거의 무중력의 공간을 만들어낸다. 결국 그는 어셈블리 언어에서도 우아한 춤을 출 수 있다.
• 완벽한 도구와 환경을 갖추는 데에 집착해선 안된다. 그런 식으로는 무엇도 영원히 얻을 수 없다. "방이 조용해지고 배도 안 고프고 온도도 적절해지기만 하면 공부 시작해야지"라고 생각하는 사람들 중에 1등은 없다. 또한 실제로 그런 환경이 되어도 몸에 배어든 습관 때문에 결국은 공부하지 못할 것이다.

학습 프레임과 실행 프레임

초등학생들을 무작위로 두 그룹으로 나눈다. 그리고 두 그룹에 다른 셋팅(MindSet)을 한다.

실행 프레임: "여러분이 얼마나 그림을 잘 그리는지 보고자 하는 겁니다. 여러분의 창의성을 측정해 보려고 합니다. 점수를 매길 거예요. 각자 그림을 하나씩 그려서 내야 합니다" 등의 주문을 한다.

학습 프레임: "내가 안 그려 보았던 방식들을 실험해 보는 시간이예요. 여러 가지 방식으로 실험해 보세요"로 주문한다.

실행 프레임에서는 '잘하기'에 초점을 맞추게 하고, 학습 프레임에서는 '자라기'에 초점을 맞추게 한다.

그림 그리기 과제가 끝나고 쉬는 시간에 아이들의 행동을 관찰해보면, 실행 프레임의 아이들은 논다고 정신이 없다. 학습 프레임의 아이들은 계속 그림을 그리는 애들이 많다.

그러나, 현재 상황 자체가 어렵고, 업무하면서 학습이 중요하다는 생각을 갖기가 어렵다고 많이들 말한다. 하지만 동일한 자극/조건이 주어졌을 때 어떤 사람은 더 많은 학습과 성장의 기회를 찾고 오히려 그 조건을 자신에게 유리한 조건으로 생각하기도 한다.

두 사람의 일화. 둘 다 입사한지 1년도 안된 사람이었는데, 두 사람의 답 모두 '아직 입사한 지 1년도 되지 않아서...'로 시작했으나, 그 뒤 그로 인한 자신의 선택과 행동, 반응은 서로 180도 달랐다.

가장 학습하기 힘든 직업이 살아남는다

학습에 유리한 조건, 불리한 조건

알파고 같은 인공지능 시스템에 유리한 조건은 다음과 같다.

1. 목표(goal)가 분명하고 객관적으로 정해져 있으며 정적이다.
2. 매 순간 선택할 수 있는 행동/선택의 종류(move)가 유한하게 정해져 있다.
3. 매 순간 자신이 목표에 얼마나 근접했는지를 알 수 있다 (내가 한 선택의 피드백이 빨리 주어진다)
4. 주로 닫힌 시스템 (즉, 예상 못 한 외부 요소가 갑자기 들어오지 않는) 속에서 일한다.
5. 과거의 선택과 결과에 대한 구조화된 기록이 많다.

그런데 이 다섯 가지 조건은 사실 인간이 학습하기 좋은 환경의 조건이기도 한다. 이 조건이 많이 갖춰질수록 효과적으로 빨리 학습할 수 있다.

이는 샨토(Shanteau)가 발표한, 전문성이 드러나는 직업 특징에 대한 연구에서도 비슷하게 나타난다. 피드백이 주어지고 작업이 반복되며 객관적 분석이 가능한 경우에 해당 작업에서 전문성이 잘 드러난다. 학습이 잘 일어나는 조건이다.

그러나, 인공지능에 대체되지 않으려면, 학습하기 힘든 환경에서 학습하기 힘든 주제들을 골라서 전문성을 쌓아야 한다.

위 조건을 반대로 뒤집어보자.

1. 목표(goal)가 모호하고 주관적일 수 있으며 동적이다.
2. 매 순간 선택할 수 있는 행동/선택의 종류(move)가 불확실하다.
3. 매 순간 내가 목표에 얼마나 근접했는지를 알기 어렵다 (내가 한 선택의 피드백을 빨리 얻기 어렵다)
4. 주로 열린 시스템 (즉, 예상 못한 외부 요소가 갑자기 들어오는 경우가 흔한) 속에서 일한다.
5. 과거의 선택과 결과에 대한 구조화된 기록이 별로 없다.

이런 환경은 소위 '암묵지', '직관' 같은 것들이 작동하는 회색 영역이다. 자신이 왜 이런 선택을 했는지 쉽게 설명할 수 없는 것들이다.

컴퓨터로 대체되기 힘든 일

이런 영역에서는 어떤 역량이 중요할까?

옥스퍼드 대학에서 미국 노동부의 O*NET 데이터를 가지고 연구한 '고용의 미래'라는 논문에서, 컴퓨터화에 병목이 되는 카테고리 3개를 선정했다. 지각과 조작, 창의적 지능, 사회적 지능. 그 카테고리에 속하는 변수들 중 다섯 가지는 아래와 같다:

• 독창성 (originality): 주어진 주제나 상황에 대해 특이하거나 독창적인 생각을 해내기, 혹은 문제를 해결하는 창의적인 방법들을 만들어내기
• 사회적 민감성 (social perceptiveness): 타인의 반응을 알아차리고 그 사람들이 왜 그렇게 반응하는지 이해하기
• 협상 (negotiation): 사람들을 화해시키고 서로 간의 차이를 조정하려고 노력하기
• 설득 (persuation): 다른 사람들이 마음이나 행동을 바꾸게 설득하기
• 타인을 돕고 돌보기 (assisting and caring for others): 개인적 도움, 치료, 감정적 지지, 혹은 동료, 고객, 환자 같은 타인들에 대한 기타의 개인적 도움을 제공하는 것

O*NET의 분류 기준에서, 컴퓨터 프로그래머는 다른 사람이 준 스펙대로 개발하는 것을 주 업무로 하며 그 과정에서 협상, 설득이 크게 필요하지 않다. 반면, 소프트웨어 개발자는 소프트웨어로 뭘 만들지를 고민하고 설계하는 부분이 포함되며, 그 과정에서 타인과 상호작용하는 업무가 많다.

무엇에 집중할 것인가

자신이 주로 하는 일이 남이 시킨 대로 혼자 프로그램을 만드는 것이라면 그런 스킬과 경력만 계속 쌓일 것이다. 반면, 컴퓨터화하기 어려운 부분은 크게 성장하지 못할 것이다.

미래에는 암묵지와 직관을 잘 학습하는 사람들이 높은 경쟁력을 가질 것이다. 그런데, 앞에서도 말했듯 이런 것들은 배우기가 어렵고, 자신이 얼마나 잘하는지 판단하기도 어렵다. (그래서 DunningKrugerEffect도 더 크게 나타난다.) 경쟁하기가 쉽지 않다. 그럼에도 불구하고 이 분야에서 두각을 나타내고 싶다면 어떻게 해야 할까?

암묵지와 직관을 배우고 수련하는 방법을 배워야 한다.

달인이 되는 비결

왜 평생 양치질을 하는데도 전문성이 높아지지 않을까?

1. 동기
2. 피드백

꾸준한 반복으로 달인이 되려면,

1. 실력을 개선하려는 동기가 있어야 하고
2. 구체적인 피드백을 적절한 시기에 받아야 한다.

에릭손은 다음과 같은 말을 했다. "특정 영역에서 개인이 성취할 수 있는 최고 수준의 퍼포먼스는 경험을 오래 한다고 해서 자동으로 얻을 수 있는 것은 아니다"

수십 년 동안 전문가가 안 되는 비결

전문성 형성에서 타당성과 피드백의 중요성

믿을 수 있는 직관이 형성되려면 특정 조건이 필요하다. 타당성(validity)과 피드백이다.

타당성 조건이 필요하다는 의미는, 직관이 적용되는 영역에 어느 정도 인과관계와 규칙성이 존재해야 한다는 것이다. 예측가능성이라고 말할 수도 있다.

피드백 조건이 필요하다는 의미는 자신이 내린 직관적 판단에 의해 빨리 피드백을 받고 이를 통해 학습할 기회가 주어지는 환경이 갖춰줘야 한다는 것이다.

수십 년 동안 한 가지 일을 하면서 전문가가 안 되는 비결이 있다면 이 타당성과 피드백이 부족한 환경에서 일하는 것이다. 예컨대 복잡한 상황에서 뒤죽박죽으로 일하거나 오늘 실수한 것을 몇 달 뒤에 알거나 혹은 영영 모르거나 하는 환경이다.

타당성과 피드백을 높이기

내가 속한 업계과 원래 이런 환경이라면? 일하는 방식, 개발하는 방식을 바꾸면 이 타당성과 피드백을 어느 정도 높일 수 있다. 그리고 전문성을 현재보다 좀 더 빨리 발전시킬 수 있다.

예컨대, 타당성을 높이려면 변수를 제한하고 실험을 하면서 규칙성과 인과관계를 찾으려는 노력을 하면 된다. 피드백을 높이려면 동료나 상사, 고객에게서, 혹은 내가 개발하는 프로그램에서 직접 피드백을 적극적으로 구하면 된다.

당신이 제자리걸음인 이유

실력을 높이기 위해서는 '의도적 수련 (DeliberatePractice)'이 중요하다.

의도적 수련의 필수 조건, 적절한 난이도

의도적 수련이 되려면, 나의 실력과 작업의 난이도가 비슷해야 한다. 칙센트미하이의 몰입이론(Flow)과도 일치한다.

실력이 작업 난이도를 초과하는 작업은, 당장은 쉽지만 조금 지나면 지루함을 느끼게 된다. 실력보다 높은 난이도의 일을 하면 불안함이나 두려움을 느낀다.

난이도와 실력이 엇비슷하게 맞는 작업을 하면, 인간이 몰입을 경험하고, 최고 수준의 집중력을 보이고, 퍼포먼스나 학습 능력이 최대치가 된다. 또한 최고 수준의 행복감을 경험한다.

언어학자인 크라센은, 입력가설(InputHypothesis)을 통해 말한다. i+1 이론이라고 하는데, 현재 언어학습자의 언어 수준을 i라고 할 때, 딱 한 단계 높은 i+1 수준의 입력이 주어질 때만 언어 능력이 유의미하게 진전한다는 것이다.

교육학에서도 비슷한 이야기를 한다. 인지 부하 이론(CognitiveLoadTheory)에서는 학습 시 불필요하게 인지적인 부담을 주면 어떤 것도 제대로 학습하기 어렵다는 말을 한다. 반면에, 영단어를 여러 개 외울 때 모음을 감추고 외우면 '더 어려워서' 오히려 기억이 오래갈 수 있다는 연구도 있다. 핵심은 적절한 난이도이다.

실력이 늘지 않는 이유

자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 늘지 않는 환경에 있는 것이다.

피겨 스케이팅 선수들 중에서도 자신이 어떤 연습을 얼마나 하는지에 대해 정확하게 인식하지 못하는 경우들이 있다. A 영역이 제공해주는 안전지대 안에 머무르고, 지루함 속에서 자기 실력에 대해 안심하고, 그 상태에 익숙해진 것이다.

제자리걸음에서 벗어나기

그러면 일상 업무에서 어떻게 시도할 수 있을까?

지루함을 느끼는 경우: 실력 낮추기

같은 난이도의 체력 훈련을 하는데 팔과 다리에 모래주머니를 달고 운동한다던지. 프로그래머로서는, 평상시 즐겨 쓰던 보조 도구를 일부러 안쓴다던지. 마우스를 즐겨 쓴다면 키보드로만 개발하려고 노력하거나, 디버거를 자주 사용했다면 디버거를 안쓰는 것이다. 컴파일을 30초마다 한 번씩 한다면 5분에 한 번씩으로 주기를 늘려본다. 난이도와 실력이 잘 맞아 들어가면 의도적 수련이 될 수 있다. 지루하던 작업이 몰입하는 작업이 되고 실력도 늘 수 있다.

지루함을 느끼는 경우: 난이도 높이기

실력은 그대로 두고 난이도를 높이는 전략이다. 자신만의 제약을 추가한다던지. 이소룡이 '3분 이내에 이겨야 한다'고 생각했던 것처럼. 하루만에 개발하라고 주어진 업무인데 지루한 느낌이 드니 한 시간만에 할 수 있는 방법을 고안해보기. 익숙한 작업을 새로운 언어로 진행해보기, 안 해도 되는 업무를 추가로 하기. 리팩토링을 하거나 자동화 테스트를 달거나, 자신만의 도구를 개발하거나. 이 방식에서는 자신만의 도구, 방법을 만드는게 매우 중요하다. 인지심리학에서 상대의 전문성을 빠른 시간 내에 간파하는 기법 중에, '남들보다 일을 좀 더 효율적/효과적으로 하기 위해 내가 직접 만들어 쓰는 나만의 도구, 방법'을 묻는 방법이 있다.

불안함을 느끼는 경우: 실력 높이기

실력을 높여서 몰입 영역으로 들어가는 방법이다. 책을 보거나 스터디에 참가하거나 교육을 듣거나. 하지만 당장 그렇게 향상되기는 쉽지 않다. 사회적 접근, 도구적 접근, 내관적 접근을 해볼 수 있다. 사회적 접근은, 나보다 뛰어난 전문가의 도움을 얻는 것이다. 도구적 접근은 다른 도구의 도움을 받는 것이다. 디버거, IDE, 코드 분석 툴, 오픈소스 등. 내관적 접근은 비슷한 일을 했던 경험으로부터 비유적으로 적용해본다. 이런 과정을 거치면 자기효능감이 증대하면서 스스로 인식하는 자기 실력이 향상되기 쉽고, 결과적으로 몰입 영역으로 들어가기 좋다.

불안함을 느끼는 경우: 난이도 낮추기

간단하면서 핵심적인 결과물, 즉 아기 버전을 첫 번째 목표로 삼는 방법이 있다.

동적인 균형

이러한 전략은 계속 조정해야 한다. 실력이나 난이도는 계속 변화하기 때문. 때문에 자기가 어떤 상태인지를 살피는 알아차림이 필요하다. 메타인지 전략이라고도 한다.

팀장이 할 수 있는 일

팀장은 어떻게 이를 활용할 수 있을까?

팀원들이 현재 어떤 상태를 주로 경험하고 있는지 파악하고 적절한 전략을 구사하게 도와줄 수 있다. 개인들이 자기 스스로 몰입 상태를 조정하는 능력을 키우게 도와주는 것이 바람직하다.

의도적 수련의 일상적 예시

프로그래밍이 아닌 경우에는 의도적 수련을 어떻게 적용할까?

프로그래밍 이외의 분야에 이 전략들을 적용할 수 있다. 한 가지 영역에서의 교휸을 다른 영역에 적용하는 것을 심리학에서는 학습 전이(transfer of learning)라고 한다.

코칭의 경우,

실력 조정하기

코칭을 하다가 매너리즘에 빠져서 지루하게 느껴질 때가 있었다. 그래서 일시적으로 실력을 떨어뜨리는 시도를 했다. 익숙하지 않은 새로운 기법(CleanLanguage)을 사용해봤다. 아무래도 초보자가 된 느낌이 들고, 기본적인 진행도 쉽지 않다. 이렇게 하다보니 내가 잘 하고 있는건가 하는 불안함이 들었다. 실력을 높여야겠다는 욕구가 들어서 CleanLanguage 전문가에게 코칭을 받았다.

난이도 조절하기

시간 제약을 통해 난이도를 높였다. 초기에는 코칭 한 세션이 1시간 30분이었다. 점점 코칭 결과가 좋게 나오고 자신감이 붙으면서 안심하게 되자, 더 도전적으로 하기 위해, 가급적 90분을 맞추려 노력했고, 그 후에는 공식적인 세션을 1시간으로 줄였다. 현재는 45분이 공식 코칭 시간이다.

프로그래밍 언어 배우기의 달인

'인간' 역엔지니어링 방법, 전문 용어로는 인지적 작업 분석 (CognitiveTaskAnalysis)이라고 한다. 전문가가 되려는 모든 사람에게 유용한 방법이다. 미 해군의 연구 결과 선생과 학생들이 이 방법을 배워서 협력적으로 (CollaborativeDevelopmentOfExpertise) 사용하는 것이 교육 효과를 높인다는 것을 발견했다. 그래서 교육시 선생과 학생들에게 이 방식을 사용하도록 하고 있다. 선생에게만 의존하는 것은 위험하다고 본 것이다. 선생에 따라서는 전문 지식은 많지만 가르치는걸 못하는 사람도 있을 수 있는데, 이럴 때는 학생이 선생에 대해 역엔지니어링을 해야 한다.

실수는 예방하는 것이 아니라 관리하는 것이다

미연에 실수를 막아야 한다?

두 가지의 실수 문화

마이클 페레제(Michael Frese)는 회사에서의 실수 문화에 대해 연구를 했다. 그에 따르면 실수 문화에는 크게 두 가지가 있다. 실수 예방과 실수 관리. 실수 예방은 행동에서 실수로 가는 경로를 차단하려고 한다. 즉, 실수를 저지르지 말라고 요구한다.

반면, 실제 세상에서는 많은 실수가 일어나지만, 전문가들이 실수를 조기에 발견하고 빠른 조치를 취할 수 있다. 이렇게, '실수는 어떻게든 할 수밖에 없다. 대신 그 실수(예컨대 코딩하다가 == 대신 =를 쳤다던가)가 나쁜 결과(서버가 도미노로 죽는다던가)로 되기 전에 일찍 발견하고 빨리 고치면 된다'라는 태도도 있다. 이 태도를 실수 관리라고 한다. 또한, 이미 결과가 난 실수에 대해서는 학습을 통해 '다음 행동할 때 이렇게 하자'는 계획을 세우기도 한다.

실수 예방 문화에서는 실수를 한 사람을 비난하고 처벌하고, 따라서 실수를 감추고 그에 대해 논의하기 꺼리며 문제가 생겼을 때 협력도 덜 하게 된다. 실수에서 배우지 못한다. 반대로 실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 베우는 분위기가 생긴다.

실수 연구의 역사를 보면, 초기에는 기술적인 부분만 보다가 그 다음에는 인간적인 부분(결국 80%가 사람 실수라던지)을 보다가, 이제는 문화적인 부분(컬럼비아호 사고 등)을 이야기한다. 심리적 안전감이라고 하는 것이 이 문화의 일부이다.

이런 실수 관리 문화가 회사에 정말 도움이 될까? 여기에 대해 연구가 있다. 회사 문화가 실수 예방보다 관리에 가까울수록 그 기업의 혁신 정도가 더 높다. 그리고 회사의 수익성이 더 높다. 왜? 실수가 없으면 학습하지 못한다. 즉, 실수 관리를 하는 문화일수록 학습을 더 잘한다.

보통 교육에서는 교육 중에 학생들이 실수를 최소화할 수 있도록 설계한다. 하지만 연구 결과는 반대이다. 교육 중에 실수를 더 유도해야 오히려 학습 전이가 더 잘 일어난다. 다양한 실수를 경험하는걸 격려하고, 실수 사례를 배우고, 실수 시에 어떻게 대처하는가를 가르치는 교육이 더 효과적이라는 연구 결과가 많다. 그래서 전문가에게 실수 대처법을 배우는 것이 중요하다.

참고

뛰어난 선생에 대한 미신

대부분의 교육, 훈련은 6개월 정도만 지나도 효과가 거의 사라진다. 그러나 교육이 끝난 직후에는 그렇게 생각이 안 들고, 만족도도 높고 굉장히 도움이 된다는 느낌이 들었을 것이다. 그런데 왜 효과가 별로 없었을까?

선생이 가진 지식은 학생의 성과를 높여주는 면에 있어서 큰 영향을 주지 못했다. 지식이 많은 사람이라고 해서 꼭 좋은 선생이라고 할 수 없다, 지식이 많은 사람에게 배웠다고 해서 내가 실력이 꼭 느는 것은 아니다.

전문가가 가르쳐주는 것은 전부가 아니다

전문가가 무언가를 가르칠 때, 자신이 실제로 사용하는 것 중 대부분(70%)은 가르치지 않는다. 전문가가 되면 자신이 하는 일이 반복적으로 몸에 익고 자동화되어서 결국 암묵적이 되어버린다. 그래서 인식이 없어진다.

인지적 작업 분석으로 극복하기

따라서, 학교와 선생, 학교 모두 이러한 현상을 극복하는데 기여해야 한다. 인지적 작업 분석을 선생과 학생이 쓰는 것이다.

선생은, 자신에 대한 메타 인지를 높인다. '내가 이 문제를 해결할 때 어떤 과정을 거치는가'를 생각하며 자신의 머릿속을 관찰하고, 질문을 던지고 분석한다. 이런 메타 분석 능력이 뛰어난 선생이 잘 가르친다.

학생 입장에서는, 자신과 학생에 대한 분석을 잘 하는 선생을 고르는 것이 유리한 전략이다. 지식의 양만 보기보다는. 또, 선생의 메타인지를 돕기 위해, 자기가 어떻게 생각하면서 이 문제를 풀었는지, 그 인지적 과정을 선생에게 알려주는 것도 효과적이다. 혹은 선생이 그 문제를 푼 인지적 과정 자체를 알려달라고 한다.

나홀로 전문가에 대한 미신

교육을 듣고 나서, 실무에 돌아갔을 때 흔히 접하는 문제들은,

• 회사로 돌아가서 실무에 적용하려고 하는데 상사나 동료의 지원 없이 추가적으로 일을 하려니, 시간이 모자라 계속 미루게 되어 결국 적용하지 못한다.
• 팀원, 팀장들에게 전파 교육을 하려 하지만 팀원, 팀장들 가운데 몇몇은 추가 업무를 왜 하는지 필요성도 못 느끼는 상태에서 강제로 해야 한다는 스트레스를 받아서 부작용이 생긴다 (그래서 결과적으로 해당 기법은 실무에 써먹을 수 없다는 평가가 나온다)
• 배운 것을 팀 내에서는 열심히 적용했으나 지원해주는 임원이 없어 확대하는 데 실패하고, 조직 내에서는 한 팀의 별난 문화로 치부되어 실행 범위가 축소된다.
• 배운대로 팀에서 실천했더니 '다른 부서는 그런거 없이도 잘 하는데 너희는 왜 그런거 하면서 제때 아웃풋이 안나오냐'며 이해할 수 없다고 말하는 상사나 협력 팀의 리더와 갈등을 겪는다
• 기술적으로 어떻게 해야 할지 모르겠는데, 주변에 물어볼 사람이 없어 인터넷 검색하느라 몇 시간씩 보낸다. 하지만 결국 원하는 정보를 찾지 못해서 적용을 포기한다.
• 회사에서는 여력이 없어 배운 것을 시도해 보려 했더니, 가족들의 여러 요구로 인해 집중할 수 없어 화를 내거나, 가족의 요구대로 하느라 내가 할 일은 시작도 못 하거나, 그냥 포기하고 잠을 자게 된다.

아무리 기술적인 실천법이라도 그 기술은 사회적 맥락 속에서 실천되어야 하며, 그 기술의 성공을 위해서는 사회적 자본과 사회적 기술이 함께 필요하다. 하지만 현실에서는 팀원들이 마음에 안들고, 그들도 나를 마음에 들어하지 않는 상황, 즉 사회적 맥락이 나쁜 상황에서 타개책으로 실천법의 기술적인 측면에만 매몰되는 경우가 있다. 사실 그런 상황에서는 무엇을 골라도 실패한다.

사회적 자본과 기술

고독한 전문가라는 미신

전문가는 사회적 자본과 사회적 기술 또한 뛰어나다. 뛰어난 연구자는 같은 부탁을 해도 훨씬 더 짧은 시간 안에 타인의 도움을 얻었다. 최근 소프트웨어 공학 연구도, 뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓰며, 초보 개발자에게 조언을 할 때 기술적인 조언 뿐 아니라 사회적인 조언도 포함한다.

그러나 아직 대중에게는 이런 전문가 연구의 변화가 충분히 전파되지 않았다. 그래서 사회적 자본과 기술이 없이 해당 도메인 지식만 배우게 된다. 게다가 그런 사회적 자본과 기술이 없는 상황에서 도메인 지식만 높으면 해당 지식의 확산과 성공에 오히려 장애가 되기도 한다.

사회적 기술을 어떻게 훈련할까? 간단한 방법은 주변 사람들과 매일 주고받는 마이크로 인터랙션에 신경쓰는 것이다. 그걸 기록하고, 복기하고, 다르게 인터랙션한다고 하면 어떻게 했으면 좋았을까 생각하는 것만으로도 훈련이 될 수 있다.

2. 함께

초기에는 대상에 대한 지식이 거의 없으니 일을 제대로 나눌 수가 없다. 사실 일을 가장 잘 나눌 수 있는 때는 프로젝트가 완료되는 시점이다. 사람들은 협력이 중요하다고 말한다. 그래서 프로젝트를 할 때 협력적으로 하자고 한다. 그러나 실제 모습을 들여다보면 초반에 일을 세밀하게 나누고 선을 긋는다. 그리고 안녕. 각자 진행하고 나중에 만나서 서로 합쳐본다. 그 속을 들여다보면 협력은 거의 없다.

우리는 협력을 제대로 배워본 적이 거의 없다. 그래서 지금부터라도 협력 방법을 배우고 수련해야 한다.

소프트웨어 관리자의 개선 우선순위

조엘 테스트라는 12가지 질문이 있다.

12가지 질문이 개발팀 평가에서 정말 중요한 요소인가?

GeraldWeinberg 는 소프트웨어 개발을 잘 관리하려면 세 가지 근본적 능력이 필요하다고 했다.

1. 복잡한 상황을 이해하는 능력으로, 프로젝트를 계획한 다음 관찰하고 행동하여 계획에 맞게 프로젝트가 진행되게 하거나 계획을 바꿀 수 있어야 한다.
2. 관찰하는 능력으로, 무엇이 벌어지고 있는지를 관찰하고, 효과적인 적응 행동을 하기 위해 자신이 관찰한 것이 어떤 의미인지 이해할 수 있어야 한다.
3. 행동하는 능력으로, 어려운 대인 상황에서 우리가 심지어 혼란스럽거나 화가 나거나 아니면 무서워서 도망쳐 숨어버리고 싶을 때에도 적절하게 행동할 수 있어야 한다.

그가 쓴 QSM의 제목은 아래와 같다.

1. 시스템적 사고 (Systems Thinking)
2. 일차적 측정 (First-Order Measurement)
3. 일치적 행동 (Congruent Action)
4. 변화를 기대하기 (Anticipating Change)

1,2,3권은 앞서 말한 필수 능력 세 가지와 순서대로 들어맞는다. 마지막 권은, 이 세 가지 능력을 활용해 실제 조직과 개인(관리자 자신을 포함한다. 와인버그는 자신을 바꾸지 못하는 사람은 다른 사람을 바꾸는 일도 할 수 없다고 말한다)을 어떻게 바꿔나갈 것인가를 다룬다.

소프트웨어 개발 비용을 결정하는 요소는 무엇일까?

• 도구
• 사람
• 시스템
• 관리

GeraldWeinberg는 베리 보엠의 연구에서 아래와 같이 각 요소의 영향을 도출해냈다.

• 도구: 2.97배
• 사람: 10.55배
• 시스템: 25.76배
• 관리: 64.00배

관리자들이 선호하는 개선 노력은 어떤 순서일까? 정확히 역순이다. 일단 도구 개선부터 시작한다. 자기 자신(관리)을 바꾸는 것은 맨 나중이다. 하지만 실제 효과로 보면 우선순위는 관리가 맨 처음에 온다.

협력을 통한 추상화

커뮤니케이션과 협력

백지장도 맞들면 찢어진다?

톱니바퀴 실험

둘이서 협력하여 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해 줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 된다. 서로 다른 것들을 하나로 묶어야 하기 때문이다. 반면 혼자서 작업할 경우에는 이런 추상화의 필요가 덜하다.

추상화의 중요성

소프트웨어 공학의 역사는 추상화를 높이기 위한 여정이었다. 그런데, 그 추상화를 높일 수 있는 방법 중 하나가 바로 '다른 시각을 가진 두 사람이 협력하기'이다.

대화하는 프로그래밍

짝 프로그래밍은, 대화를 통해 추상화를 높이게 하고, 하나의 컴퓨터를 사용한다는 점은 그것을 구체화를 통해 검증하게 한다. 구체와 추상이 빈번히 교차한다. 그리고 그 사이에서 '아하'가 터져 나온다.

자신이 작성하는 코드의 추상성을 높이고 싶다면 혼자서 고민하지 말고 다른 사람들과 협동하고 대화하라. 같이 그림도 그려보고 함께 소스코드를 편집하라.

신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가

신뢰 자산이 높은 조직은 커뮤니케이션 효율이나 생산성이 높다는 연구가 많이 있다. 신뢰 자산이 높다는 것은 조직원들 간에 높은 수준의 신뢰가 기반되어 있는걸 말하며, 그 신뢰가 줄거나 늘 수 있음을 암시한다.

어떻게 신뢰를 쌓을까?

널리 사용되는 한 가지 방법은 투명성과 공유, 인터랙션이다. 그런데 그렇게 공유하고 소통하면 신뢰가 쌓일까?

공유 조건별 신뢰도 변화 실험

공유의 세 가지 셋팅을 생각해보자.

하나 공유(share one)

하나의 결과물을 만들고 하나를 공유하게 함

최고 공유(share best)

같은 시간 동안 여러개의 결과물을 만들고, 그 중 자신이 가장 잘 했다고 생각하는 것을 골라서 공유하게 함

복수 공유(share multiple)

각자 여러 개의 결과물을 만들고 그걸 모두 공유

하나 공유나 최고 공유가 아마 우리가 흔히 하는 공유 방식일 것이다. 그런데 이 방식은 하고 나면 신뢰가 더 떨어진다. 왜? 이 방식의 경우, 우리는 공유 자리에 기대감보다는 불안감을 갖고 가곤 한다. "상대가 이걸 보고 흉을 보면 어쩌지?" 그리고 그럴 경우 어떻게 방어적으로 대응해야 할지도 대략 생각해두게 된다. 또한, 상대의 시안에 대해서도 솔직한 의견을 내리는 것을 꺼리게 된다. "내가 한 말을 듣고 나를 싫어하면 어쩌지?" 나의 작품이 하나밖에 없으니 '작업물=나'가 되는 것이다. 나름 방어를 해낸다고 해도 자기효능감이 떨어지기 쉽다.

복수 공유의 장점

반대로 복수 공유는 그런 불안감이 상대적으로 덜하다. 또 부정적 피드백을 수용하려는 마음도 더 많다. 여러 개를 준비했으니 그 중 하나를 두고 뭐라고 해도 나에 대한 공격은 아니다. 또 여러 개이니 상대적으로 이야기를 할 수 있어 말하는 사람도 편하고, 듣는 사람도 좋다는 이야기와 안 좋다는 이야기를 같이 들으니 (A안은 이게 좋은데, B안은 이게 안좋고) 마음이 좀 더 편하다.

그리고 복수 공유는 성과도 더 높았다.

경영자나 관리자들은, 그냥 공유만 하게 한다고 신뢰가 저절로 쌓이는게 아니라는 것을 이해하고, 또 그렇다면 어떻게 공유하게 할 것인가 하는 고민을 해볼 수 있겠다.

객관성의 주관성

팀장 자리에 있으면 새로운 아이디어 전파가 쉬울 것이라고 생각하는 것은 환상이다. 그렇다면 주위 사람들을 어떻게 설득해야 하는가? 어떻게 해야 설득할 확률을 높일 수 있는가?

품질은 상대적이다

감정을 배제할 수 없다

다마지오(Damasio. A)와 그의 동료들은 감정과 의사결정을 연결하는 특정 뇌 영역에 손상을 입은 환자들을 연구했는데, 결정과 관련된 인지적 작업에서 문제가 있었다. 식당을 고르는 것 같은 사소한 결정도 엄청나게 고민했고 시간도 오래 걸렸다.

우리는 의사결정을 하는 과정에 감정적이고 직관적인 부분이 큰 열할을 하고 있고, 그런 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없다.

성향과 기질에 따른 애자일 설명법

결국, 내가 설득하려는 대상도, 결정을 내기는 과정에서 감정이나 직관 등, 객관적이지 않은 과정을 거친다. 그렇기 때문에, 상대방을 이해하고 상대에 맞게 설득해야 한다. KAI 성향이나 MBTI 등을 활용할 수도 있겠다.

이것도 모르세요?

공감하고 이해하려는 대화

행동을 유도하는 대화

한 팀은 서로 잘 물어보지 않고, 물어봐도 '이것도 모르세요?'의 수준으로 대답해 준다. 반대로 다른 팀은 서로 코칭을 해주면서 함께 동기와 의지를 북돋워주고 같이 고민해준다. 어느 팀의 사람들이 성장할까?

하향식 접근의 함정

우리는 일종의 미신을 가지고 있다. "전문가는 언제나 탑다운으로 깔끔하게 생각할 것이다"라는 믿음이다.

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

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

그러나 전문가들은 자신이 자주 접하지 않았던 문제, 어려운 문제, 혹은 잘 정의되지 않은 문제를 접하면 접근법을 바꾼다. 탑다운과 바텀업을 섞어서 쓴다. 뛰어난 전문가일수록 그렇다. 비전문가는 현재 문제가 나에게 얼마나 어려운가에 대한 인식이 부족하며 자기의 문제 풀이 전략을 상황에 맞게 능동적으로 선택하거나 변경하지 못한다. 오히려 탑다운이나 바텀업 중 한 가지에만 억지로 집착하려고 한다. '이번 문제는 복잡하니까 더 철저하게 계획하고 설계해야겠다'와 같이.

하지만 우리는 전문가는 탑다운으로 문제를 푸는 사람이라는 고정된 이미지를 갖고 있다. 게다가 이런 믿음을 협력 방식에까지 확장한다.

기업에서 일하는 방식도 통상 이 탑다운 모형을 따른다. 전문가가 탑다운으로 일하니, 조직도 탑다운으로 일해야 한다는 단순한 생각의 흐름이다. 대부분의 기업에서 직원 숫자가 늘어나기 시작하면 추상 층위에 따라 팀을 나눈다. 각 층위의 전문가 팀이 존재한다. 기획팀, 구현팀, QA팀 등. 그리고 일이 진행됨에 따라 팀 간의 바통 터치가 이루어진다. 위에서 아래 방향으로.

한 연구에서는, 엘리베이터 시스템 설계자들을 모아놓고 그 사람이 설계할 때 사고 수준이 시간 흐름에 따라 어떻게 변화하는지 실험했다.

전문가들은 추상과 구상을 오르락내리락 했다. 특히 '아하 순간'은 방향이 꺾이는 지점에서 왔다. 뭔가 설계에 기똥찬 개선이 이루어지는 순간이었던 것이다.

엘리베이터 설계에서 추상성이 높은 것은 알고리즘이나 기능 등이 될 테고, 추상성이 낮은 것은 모터의 가속도 제어나 회로 차원일 것이다. 전문가는 추상성의 정도를 오르락내리락거리고, 특히 탑다운과 바텀업의 방향이 전환되는 시점들에서 '아하 순간'이 찾아왔다.

하지만 우리는 종종 이렇게 말한다. '이번 일은 복잡하고 불확실하니까 철저하게 계획하고 단계적으로 접근하자!'. 이 말은 곧, 이번 일은 불확실하니까 초보처럼 일하자는 말과 똑같다.

조직 내에 모든 레이어를 꿰뚫는 전문가가 있으면 좋겠으나 많은 경우 그런 사치를 부릴 여유가 없다. 다루는 문제가 점점 복잡해지면서 팔방미인은 희박해지고 몸값은 치솟는다. 그러면 그 (한 사람이 그 역할을 하는) 대신에, 밖에서 그 조직을 관찰했을 때 마치 그 속에 모든 층위를 꿰뚫는 전문가가 있는 것처럼 만들 수는 없을까?

하지만 현재 통상적인 기능적 팀 구분에서는 이런 효과를 내기가 어렵다. 바통 터치가 너무 자주 일어난다. 그러면 주고 받는데서 생기는 오버헤드가 과도하게 커진다.

• 한 사람이 다기능을 갖추도록 (참고)

• 협력이 쉽게 되도록

전자는 바통 터치가 덜 필요하게 만드는 것이고, 후자는 한번 바통 터치하는데 드는 비용을 줄이는 것이다. 재미있게도 후자를 잘 하다 보면 전자가 자동으로 좋아진다. 반대로 전자를 잘해서 후자도 잘 되게 할 수도 있으나, 후자가 잘 되지 않으면서 전자가 잘 되게 하기는 어렵고 비용이 크다.

빠르고 빈번한 바통 터치가 가능한 전문가 조직

오버헤드를 낮추려면 협력 모델이 바통 터치 모형에 기반하지 않고 삼투압 모형에 기반해야 한다. 사실 바통 터치 비용을 극도로 줄이다 보면 삼투압 모형으로 가게 된다. (AlistairCockburn이 뛰어난 팀에 대해 관찰한 바와도 같다.)

삼투압적 의사소통은 '배어드는' 소통방식이다. 서양의 의사소통 모형은 대체로 화살 모형을 따른다. 발신, 수신인이 정해져 있고, 화살을 쏘는 것이다. 삼투압적 모형에서는 은연중에 서로 간에 정보가 스며드는 것이다.

그렇게 하려면 사람들이 물리적으로 가까운 거리에 있어야 유리하다. 예를 들어, 프로그래밍하다가 '저기 이거 뭐뭐 안되는데 아는 사람 있어요?'라고 외친다. 테이블 건너편에 있던 디자이너가 답을 해준다. 옆에 앉아 자기 일을 하던 기획자는 프로그래머 둘이 하는 대화를 우연히 듣는다. 그러다가 '아, 그런 문제가 있었나요? 저는 어쩌구...'하면서 끼어들어 새롭고 가치 있는 정보를 준다.

그리고 한번에 처리되는 일의 양(batch size)를 줄여야 한다. 배치 사이즈를 줄여서 지속적 흐름(continuous flow)를 만들고 짧은 시간 내에 탑, 바텀을 오가게 한다. 예를 들어 전에는 디자이너가 100개의 일거리를 다 처리한 후에 한꺼번에 모아 결과를 전달했다면 점차 50개로, 10개로, 1개로 낮추어야 한다.

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

제시 제임스 개럿(JesseJamesGarrett)의 저서 '사용자 경험의 요소'에서는 웹개발에서 추상화의 단계를 다섯 면(plane)으로 나눈다.

• 전략 (strategy)
• 범위 (scope)
• 구조 (structure)
• 뼈대 (skelecton)
• 표면/비주얼 (surface/visual)

우리가 전문가의 이미지를 잘못 가지고 있다면 전문가가 다음과 같이 일을 처리하리라 생각하기 쉽다.

'전략이 깔끔히 완료되고 나서야 범위(무슨 기능이 들어갈지 결정)를 정하고, 다음에 구조(기능들을 어떻게 연결할지, 흐름은 어떻게 될지, 사이트 구조 등)를 정하고, 거기에서 뼈대(화면에 어떤 요소들이 대략 들어가야 하는지, 배치는 어떤지)가 나오고, 마지막에 이르러서 비주얼 디자인에 도달할 수 있다'

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

흔히 말하는 개발의 5단계도 비슷하다. 분석, 설계, 구현, 테스트, 전개를 1년이라는 프로젝트 기간에 얼마씩 배치할까로 고머니하지 말고, 어떻게 해야 첫 달부터, 아니 첫 주부터 분석, 설계, 구현, 테스트, 전개를 모두 왔다갔다 할 수 있을까를 고민해야 할 것이다.

그리고 이렇게 일하기 위해 우리 조직은 어떤 종류의 협력을 해야 할지를 생각해 봐야 할 것이다.

전문가팀이 실패하는 이유

사업을 하는 사람들이 흔히 버스에 사람 태우기라는 메타포를 이야기하곤 한다 (JimCollins가 GoodToGreat에서 한 말인데, 위대한 기업에서는 버스에 적절한 사람 태우는 것이 우선이고 어디로 갈지 정하는 건 그 다음이라고 말한다). 그리고 이 메타포를 사용하는 사람의 상당수는 '뛰어난 사람'을 뽑는 것이 얼마나 중요한가를 말하기 위해 이 비유를 든다. 그들에게 있어 뛰어난 사람은 해당 전문 분야의 뛰어난 사람을 의미한다.

그러나 뛰어난 사람을 뽑아두면 어떻게든 잘 할거라는 사고가 지나치게 낙관적인 기대일 수 있다.

스포츠맨들은 '올스타팀'이라는걸 잘 알고 있을 것이다. 그런데 올스타팀의 성적이 그다지 인상적이지 못하다는 점은 대개 동의할 것이다.

그로이스버그 등의 연구에 따르면, '이런 스타들이 한 명씩 팀에 추가될 때마다 팀의 추가적 성과 향상은 한계효용을 보이며 어느 수준을 지나면 음의 방향으로 작용한다'고 한다. 게다가, 올스타틈을 만드는데 드는 비용까지 고려하면 더 심각한 결과가 나올 것이다. 이렇게 전문가가 추가되는게 도움이 안되거나 오히려 성과를 깎아먹는 경향은 특히 전문가들의 전문성이 서로 유사할 때 도드라졌다. 그 원인 중 하나로 전문가들의 에고(ego)를 꼽는다.

그러면 해결책은?

울리(Woolley) 등의 연구를 보면, 아래와 같은 상황에서 실험을 했다.

1. 전문가, 협력 개입
2. 전문가, 협력 비개입
3. 비전문가, 협력 개입
4. 비전문가, 협력 비개입

협력을 고취하기 위해 10분간 개입하지 않고 자기들이 알아서 하게 놔둔 전문가팀은 비전문가로만 구성된 팀보다도 훨씬 못한 결과가 나왔다. 단순히 전문가들을 모아둔다고 해서 높은 성과가 나오지 않았따. 이런 경향은 필요한 협력의 정도가 높은 일일수록 도드라진다.

왜 이런 차이가 났을까를 분석했더니 그 원인은 정보 공유의 차이에 있었다. 협력 개입이 된 경우, 팀원들은 정보를 공유해서 더 통합된 해결책을 제시했다. 반면에 협력 개입이 없으면 결과물은 서로 모순되는 등 통합되지 못했따 (소프트웨어 개발로 치자면 각 모듈이 제대로 통합되지 않고 충돌하는 것이다). 분야 전문가들이라고 해서 무조건 협력을 잘하는게 아니다.

논문에서 저자들은 이렇게 말한다.

• 이 결과는 팀에 작업 관련 전문가가 포함되는 것과 동시에 각 멤버의 작업을 조율하고 통합하는 전략을 팀이 드러내놓고 탐색하는 경우에 팀의 분석 작업이 가장 높은 수준의 효과성을 보인다는 것을 시사한다. 협력 계획하기라는 개입을 받지 못하고 전문가들이 포함된 팀은 다른 팀보다 더 못한 성과를 보였다. 이것은 멤버들이 전문가의 특별한 재능을 사용하도록 도움을 받지 않는다면 전문가 멤버들의 존재가 사실은 팀의 효과성을 떨어뜨릴 수 있다는, 기대를 거스르는 가능성을 제시한다.

이에 더해, 분더슨 등의 연구에서는 팀 내에 개인 내 다양성(intrapersonal diversity)이 높은 멤버가 없다면 전문가로 구성된 팀은 정보 공유가 잘 안되어서 성과가 떨어질 수 있다는 분석을 했다. 여기에서 개인 내 다양성이 높다는 것은 다양한 분야를 경험한 제너럴리스트 같은 사람을 뜻한다. 이 연구도 앞의 울리 연구와 같은 맥락으로 볼 수 있다.

정리하자면,

1. 전문가들 모아서 팀 만든다고 (일을) 잘하는 것 아니고
2. 오히려 성과가 떨어질 수 있고
3. 정보 공유하고 협력을 잘하기 위한 명시적인 도움이 필요하며
4. 소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 된다.

구글이 밝힌 탁월한 팀의 비밀

구글은 데이터 기반으로 뛰어난 관리자의 특징을 찾는 옥시전 프로젝트 이후에도 뛰어난 팀의 특징을 찾기 위해 2년간 노력했다. 이름하여 아리스토텔레스 프로젝트(AristotleProject)이다.

중요한 부분은 세 군데이다.

1. 팀에 누가 있는지(전문가, 내향/외향, 지능 등)보다, 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.

2. 5가지 성공적 팀의 특징을 찾았는데, 그중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감(PsychologicalSafety)이었다.

3. 팀 토론 등 특별히 고안된 활동(gTeamsExercise)을 통해 심리적 안전감을 개선할 수 있었다.

쾌속 학습팀

프로젝트 확률론

3. 애자일

애자일의 씨앗

애자일 도입 성공 요인 분석

당신의 조직에 새 방법론이 먹히지 않는 이유

애자일을 애자일스럽게 도입하기