#acl +All:read

[[책/함께 자라기]]의 1부. 

 * 1부는 [[../자라기]]
 * 2부는 [[../함께]]
 * 3부는 [[../애자일]]

= 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)
 * 실제 작업을 해보도록 하는 작업 샘플 테스트
 * 가능하다면 실제 업무를 주고 시험적으로 짧은 기간 동안 [[http://agile.egloos.com/5824695|일을 해보게]] 하는 것


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

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

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

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


=== 개발자들이 할 수 있는 것 ===

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


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

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

=== 복리의 비밀 ===

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

 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. 구체적인 피드백을 적절한 시기에 받아야 한다.


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


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

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

GaryKlein과 DanielKahneman이 같이 쓴 논문이 있다. 각각 자연주의 의사결정론(NDM: Naturalistic Decision Making)과 발견법과 편향(HB: Heuristics and Bias) 학파의 수장이다. HB 학파는 전문가라고 하는 사람들(넓게 보면 인간)이 사실은 얼마나 형편없는가를 밝혀내는 데에 큰 즐거움을 느끼고 있다. NDM 학파는 전문가라는 사람들이 얼마나 엄청난 일들을 해낼 수 있는지를 알리는 데에 행복을 느끼고 있다.

이 두 학파의 초점은 전문가들의 직관적 판단에 모아진다. HB는 그건 믿을 것이 못 된다는 말을 하고, NDM은 믿을 수 있다는 말을 한다. 직관에 대해 NDM의 입장을 어느 정도 대변하는 대중서로는 말콤 글래드웰의 [[책/블링크]]가 있다. 또, 이 책에 정면으로 반박하는 [[책/싱크!]]라는 책도 있다.

그러나 이 둘이 같이 쓴 [[ConditionsForIntuitiveExpertise]] 라는 논문이 있는데, 이 둘이 공통적으로 동의하는 부분이 있다.

믿을 수 있는 직관이 형성되려면 특정 조건이 필요하다. 타당성(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%가 사람 실수라던지)을 보다가, 이제는 문화적인 부분(컬럼비아호 사고 등)을 이야기한다. 심리적 안전감이라고 하는 것이 이 문화의 일부이다.

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

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

[[http://agile.egloos.com/5774862|참고]]

== 뛰어난 선생에 대한 미신 ==

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

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


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

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

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

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

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

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


== 나홀로 전문가에 대한 미신 ==

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

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

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


=== 사회적 자본과 기술 ===

=== 고독한 전문가라는 미신 ===

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

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

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