함께 자라기
머리말
내가 정말 잘할 수 있을까? 아니, 우리가 정말 자랄 수 있을까?"
- 무엇이건 실제 바깥세상(야생)에 임팩트를 남기려면 혼자 힘으로만 되는 게 없는 것 같습니다. 함께 해야 합니다.
- 세상은 함께 해야 뭔가 이룰 수 있는데 왜 우리는 혼자 하는 것만 배울까요.
- 세가지 질문
- 내가 정말 자랄 수 있을까?
- 우리가 정말 함께 자랄 수 있을까?
- 우리가 정말 매일매일 함께 자랄 수 있을까?
- 저는 학습의 본의는 야생 학습에 더 가깝다고 생각을 하고, 현실 세계에서는 야생 학습이 더 많이 필요하다고 봅니다. 그래서 이 책에서 학습을 이야기할 때에는 대부분의 경우 야생 학습을 언급하는 것이라고 보면 되겠습니다.
- 수파리 이야기로 마무리하면 좋겠습니다. ... 수파리는 특히 제 1단계(일단 규칙을 무조건적으로 받아들이고 따르는 단계)를 강조하기 위해 쓰이는데, 그 미명하에서 얼마나 많은 교육적 폭력이 자행되어 왔나 하는 생각이 듭니다.
자라기
당신은 몇년차?
경력, 그 견딜 수 없는 무거움
그런데 소프트웨어 기술자의 등급이라는 것이, 겉으로는 기술자격이나 학력에 경험을 함께 고려해 결정되는 것 같아 보이지만 사실상 '경험'이라는 요소가 가장 결정적 역할을 합니다. ... 이런 제도 때문에 사람들은 더더욱 경력의 틀(심리학적 프레임) 안에서 생각하게 됩니다. ... 저는 이 글을 통해,
- 경력 연차라는 것으로부터 이 사람이 초급인지 아닌지 정도의 정보만 기대할 수 있으며
- 초급이 아닌 사람들에 대해서는 경력 연차가 오히려 혼동을 불러일으키는 잘못된 정보로 작용할 수 있고
- 고로 경력 연차로 채용 여부나 임금 수준을 결정하는 것은 판단 편의적이고 관료주의적이며 결과적으로 조직에 손해를 줄 수 있는 방식
이라고 이야기하려고 합니다.
직원을 뽑을 때 무엇이 그 사람의 실력을 가장 잘 예측할까?
...는 채용 시 가장 효과적인 예측변수가 무엇이냐에 대해 연구했습니다. 0에 가까우면 상관성이 없다고 말하고, 1이나 -1에 가까우면 상관성이 높다고 합니다. 통상 0.5를 넘으면 강한 효과가 있다고 하고 0.2에서 0.5 사이는 중간정도라고 하며, 0.2 이하는 약한 효과라고 합니다.
경력 연차의 상관성은 0.18, 학력의 상관성은 0.10입니다. 관심사조차도 직무 성과와 상관성이 0.10이 되는 수준입니다.
그렇다면 어떤 것들이 상관성이 높았을까요? 작업 샘플 테스트(실제로 채용 후 해야 할 작업의 일부를 해보는 테스트)가 0.54, 아이큐가 0.51이었습니다. 성실성이나 꼼꼼한 같은 성격 테스트도 0.41이나 0.31 정도의 상관성이 있었습니다. 레퍼런스 체크도 0.26으로 연차들의 상관성보다 높았습니다.
그렇다고 연차가 완전히 의미가 없는 것은 아니었습니다. 경력이 얼마 되지 않았을 떄 몇 년간은 연차의 상관성이 꽤 높은 편입니다.
중요하다고 생각하는 것이 중요하지 않다
예를 들면 경력을 지나치게 중요하게 여기는 회사가 많습니다. 동시에 협력 능력을 지나치게 등한시하는 회사가 많았습니다.
최소한도의 경력 수준만 넘겼으면 오히려 몇 년 일했는지는 모르는 것이 더 낫다고 생각하고요. 실제 작업을 해보도록 하는 작업 샘플 테스트, 실제 업무를 주고 시험적으로 짧은 기간 동안 일을 해보게 하는 것 등을 권합니다.
잘 뽑는 것 이상으로 중요한 것 🚧
개발자들이 할 수 있는 것 🚧
자기계발은 복리로 돌아온다 🚧
복리의 비밀
"조직에는 세 가지 차원의 작업이 있다"고 컴퓨터 선구자이자 마우스 발명가인 더글라스 엥겔바트가 말했다.
A 작업은 겉으로 가장 잘 드러나는 수준으로, 한 회사의 사람과 자원의 대부분은 이 수준에 초점이 맞춰져 있다. 그 회사의 사람고 자원의 대부분은 이 수준에 초점이 맞춰져 있다.
하지만 다음 수준인 B 작업 없이는 효과적인 A 작업은 불가능할 것이다. B 작업은 회사가 자신의 제품과 서비스를 개발, 생산, 판매하는 걸 가능케 해주는 시스템과 프로세스를 설계하는 것과 관련이 있다.
하지만 가장 미묘하고 또 잠재적으로 가장 영향력이 큰 것은 C 작업으로, 이는 우리의 사고방식과 상호 작용 방식을 개선한다. 궁극적으로는 C 작업의 품질이 우리가 설계하는 시스템과 프로세스의 품질을 결정짓고, 나아가 우리가 제공하는 제품과 서비스의 품질을 결정짓는다.
보통 경영학에서는 더하는 조직을 작업 그룹이라고 하고 곱하는 조직을 팀이라고 구분합니다. 작업 그룹은 주어진 일을 사람 숫자에 맞게 나눠주고 각자 정해진 일을 하는 형태를 말합니다. 서로 교류할 필요가 없습니다. 반면에 팀은 일을 상호 협력적으로 진행합니다.
- 그리고 조직의 효과성을 가장 잘 예측하는 변수는 동료 코칭이라고 합니다. 서로 업무적으로 도움을 주고받는 걸 말하죠. 이 동료 코칭과 퍼포먼스 간의 상관계수는 0.82입니다.
잠자는 시간을 줄이는 것이 더하기적 사고라면, 집단의 지능을 높이는 것은 곱하기적 사고입니다.
그냥 일하는 시간을 늘리는 것은 작업량을 늘리는 것에 지나지 않습니다.
A 작업을 개선하려면 두 가지 질문을 해 봐야 합니다. 첫 번째는 어떻게 하면 더하기보다 곱하기를 할 수 있을 것인가입니다. 두 번째는 어떻게 해야 곱하는 비율(이자율)을 높일 수 있는가 혹은 이자 적용 주기(1년에 한 번 대신에 1달에 한번)를 짧게 할 수 있는가입니다.
- 자신이 이미 갖고 있는 것들을 잘 활용하라
- 외부 물질을 체화하라
- 자신을 개선하는 프로세스에 대해 생각해 보라
- 예컨대 나의 A 작업을 되돌아보는 회고/반성 활동을 주기적으로 하는 프로세스를 만들어라(C 작업).
- 나를 개선하는 과정(B 작업)을 어떻게 하면 개선할 수 있을지 고민하라.
- 피드백을 자주 받아라
- 일찍, 그리고 자주 실패하라. 실패에서 학습하라.
- 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라
학습 프레임과 실행 프레임
한 그룹의 아이들에게는 실행 프레임을 갖게 합니다. "여러분이 얼마나 그림을 잘 그리는지 보고자 하는 겁니다. 여러분의 창의성을 측정해 보려고 합니다. 점수를 매길 거에요. ..." 다른 그룹 아이들에게는 학습 프레임을 갖게 합니다. "내가 안 그려 보았던 방식들을 실험해 보는 시간이에요. 여러 가지 방식으로 실험해 보세요." ... 실행 프레임에서는 '잘하기'에 초점을 맞추게 하고, 학습 프레임에서는 '자라기'에 초점을 맞추게 합니다.
여기에서 말하는 실행 프레임은 사람들이 현재 주어진 과업이 뭔가 좋은 성과를 내는 걸로 생각하는 틀을 말합니다. 학습 프레임은 현재 주어진 과업이 내가 얼마나 배우느냐로 여기게 되는 틀을 말합니다.
현재 상황 자체가 어렵지 않냐. 업무하면서 학습이 중요하다는 생각을 갖기가 어렵지 않냐.
지금 자신의 상황 '때문에' 학습 프레임을 갖는 것이 힘들다는 생각이 든다면, 이 우주 어딘가의 누구는 비슷한 상황 '덕분에' 학습 프레임을 가질 수 있었다고 생각하고 있다고 상상해 보면 어떨까요?
가장 학습하기 힘든 직업이 살아남는다
학습에 유리한 조건, 불리한 조건
컴퓨터로 대체되기 힘든 일
무엇에 집중할 것인가
달인이 되는 비결
동기가 부족하다
피드백을 제때 받지 못한다
수십 년 동안 전문가가 안 되는 비결
전문성 형성에서 타당성과 피드백의 중요성
타당성과 피드백을 높이기
당신이 제자리걸음인 이유
의도적 수련의 필수조건, 적절한 난이도
실력이 늘지 않는 이유
제자리걸음에서 벗어나기
지루함을 느끼는 경우: a1 실력 낮추기
지루함을 느끼는 경우: a2 난이도 높이기
불안함을 느끼는 경우: b2 실력 높이기
불안함을 느끼는 경우: b1 난이도 낮추기
테트리스의 핵심은 살아있으면서도 간단한, 아기 버전의 테트리스를 만드는 것입니다.
동적인 균형
팀장이 할 수 있는 일
이소룡의 자기 혁신
의도적 수련의 일상적 예시
실력 조정하기(a1, b2)
난이도 조절하기(a2, b1)
일반적으로 제가 새로운 기술을 코칭에 적용할 경우 이 난이도 조절을 적극적으로, 점진적으로 하는 것 같습니다.
처음에는 현재 제 자신에게 적용해 홉니다. ... 그 다음에는 과거의 힘들거나 어려웠던 상황을 떠올려서 그 때의 자신을 코칭해 봅니다. ... 이게 되면 실제로 그 사람과 코칭을 해봅니다. 이 때에는 미리 언급을 합니다.
프로그래밍 언어 배우기의 달인
'인간' 역엔지니어링 방법을 사용하고, 또 가르치고 있습니다.
S 님의 어떤 전문성을 끌어낼까 하다가 '프로그래밍 언어를 배우는 전문성'을 하기로 했습니다.
튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다
적극적 읽기
첫 번째 목표로 주로 삼는 프로그램은 단어 개수 세기 프로그램이라고 합니다.
공부할 때 표준 라이브러리 소스코드를 읽는다
자연 언어 교육과는 다르게 프로그래밍 언어 교육에서는 읽기보다 쓰기를 더 강조하는 경향이 있습니다. 프로그래밍 언어를 가르칠 때 읽기를 교육하는 경우는 극히 드물죠. 하지만 프로그래머가 실제로 업무를 할 때에는 코드를 읽는 시간이 쓰는 시간을 압도합니다. 좋은 코드를 읽어봐야 좋은 코드를 쓸 수 있기도 하고요.
S 님은 튜토리얼을 읽어 나가면서 틈틈이 해당 언어의 표준 라이브러리를 찾아 읽었습니다.
Java로 작성된 프로그램이냐 C로 작성된 프로그램이냐를 가르는 진짜 기준은 어떤 언어의 키워드를 썼느냐가 아니라 어떤 스타일을 따르고 어떤 숙어를 사용했는가입니다.
공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다
전문성을 효과적으로 뽑아내는 전문가가 되기
한 가지 비결은 전문가가 구체적인 사건에 대해 말하도록 유도하는 겁니다.
S 님의 경우에는, 가장 최근에 익힌 언어가 Go라고 하더군요. 그 언어를 익힌 과정을 시간대별로 짚어가며 어떤 행동을 했는지, 그리고 암묵적인 의사결정과 상황판단이 무엇이었는지를 추출했습니다.
실수는 예방하는 것이 아니라 관리하는 것이다
미연에 실수를 막아야 한다?
미국 산림청의 산불 정책이 수십년 전에 바뀐 것을 아십니까? 예전에는 산불 예방을 강조했습니다.
이제는 불 예방에서 불 관리 쪽으로 초점이 바뀌었습니다.
흥미로운 부분은 가장 사망률이 높은 병원과 가장 낮은 병원 집단 사이에 수술 후 합병증 발생 확률이 통계적으로 차이가 있었다는 점입니다. 그럼 무엇이 사망률의 차이를 만들었을까요? 합병증을 발견하고 적절한 조치를 취하는 부분에서 차이가 났습니다. ... 사망률이 낮은 병원은 심각한 합병증이 벌어지는 것을 잘 알아챘고, 또 합병증이 생긴 후 적절한 조치를 했던 것이죠.
두 가지의 실수 문화
실수 예방 문화에서는 실수를 한 사람을 비난하고, 처벌하고, 따라서 실수를 감추고 그에 대해 논의하기 꺼리며 문제가 생겼을 때 협력도 덜 하게 됩니다. 반대로 실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생깁니다.
실수 연구의 역사를 보면, 초기에는 기술적인 부분만 보다가 그 다음에는 인간적인 부분을 보다가, 이제는 문화적인 부분을 이야기합니다.
실수가 없으면 학습하지 못합니다. 이는 학습이론의 기본입니다.
다양한 실수를 경험하는 걸 격려하고, 실수 사례를 배우고, 실수 시에 어떻게 대처하는가를 가르치는 교육이 더 효과적이라는 연구 결과가 많습니다.
뛰어난 선생에 대한 미신
흥미롭게도 많은 조직에서 교육은 투입으로 성과를 측정하는 대표적 분야입니다.
기업에서의 교육, 훈련 효과에 대한 메타분석 연구에 따르면 대부분의 훈련은 6개월 정도만 지나도 효과가 거의 사라집니다.
존 해티의 연구에 따르면 교사가 가진 주제에 대한 지식수준은 효과 크기가 0.09에 지나지 않으며 ... 교사가 지식이 얼마나 많은지는 큰 영향을 미치는 요소가 아니라는 말이지요.
왜 그럴까요? ... 여기에서는 특히 '아는 것을 온전히 가르칠 수 있는가'하는 면에 초접을 맞춰보죠.
전문가가 가르쳐주는 것은 전부가 아니다
의료계의 연구를 보면, 전문가가 특정 수술법을 학생에게 가르칠 때, ... 70%는 가르치지 않는다는 분석이 거듭해 나왔습니다. 가르치는 능력을 인정받고 한 번 이상의 '탁월한 교사상'을 받은 사람임에도 그랬고, .. 그 기술을 성공적으로 해내기 위해 필요한 것의 30%만 가르쳐 놓고 자신은 다 가르쳤다고 생각하는 겁니다.
이런 현상이 벌어지는 이유에는 ... 대표적인 것이 자동화입니다. 전문가가 되면 자신이 하는 일이 반복적으로 몸에 익고 자동화가 되어서 결국 암묵적이 되어 버립니다.
인지적 작업 분석으로 극복하기
이걸 극복하는 방법이 있을까요? 네. 있습니다. ... 한 가지 힌트를 드리자면, 앞에서 <프로그래밍 언어 배우기의 달인>의 인지적 작업 분석 같은 방법을 선생과 학생이 쓰는 겁니다. ... 메타분석에 따르면 선생이 인지적 작업 분석에 능숙한가 하는 것이 학생들의 학업성취도에 미치는 여향의 효과 크기가 자그만치 1.29나 됩니다. 이런 분석 능력이 뛰어난 선생이 잘 가르치는 사람이라는 이야기입니다.
또 선생의 메타인지를 돕기 위해 자기가 어떻게 생각하면서 이 문제를 풀었는지 그 인지적 과정을 선생에게 알려주는 것도 매우 효과적입니다.
나홀로 전문가에 대한 미신
보통은 어떤 사람이 전문가라고 하면 그 사람의 뇌 안에서 무슨 일이 벌어질까에만 주목하는 면이 있습니다. '고독한 천재'같은 ... 이미지로 떠올리기도 하죠. 그런데 과연 현실에서의 전문가가 정말 그런 사람일까요?
뭘 하든지 나 혼자가 아니라 항상 누군가가 등장하고, 일의 성패에 다른 사람이 관련되어 있기 때문입니다. 정리하면 다음과 같습니다.
1) 아무리 기술적인 실천법이라고 해도 2) 그 기술은 사회적 맥락 속에서 실천되어야 하며 3) 그 기술의 성공을 위해서는 사회적 자본과 사회적 기술이 함께 필요하다.
사회적 자본과 기술
신뢰가 깨어져 있는 상태에서는 어떤 행동을 해도 악의적으로 보인다는 것입니다.
이 신뢰를 사회적 자본의 일종이라고 합니다.
고독한 전문가라는 미신
전문가가 해당 도메인 지식만 뛰어난 사람이라는 것은 대표적인 미신입니다. 전문가는 사회적 자본과 사회적 기술 또한 뛰어납니다.
이제는 프로그래밍을 잘한다는 정의 안에 의사소통 능력을 그 일부로 보게 된 겁니다.
희망적인 소식은 이런 사회적 기술을 훈련으로 개선할 수 있다는 겁니다.
간단한 방법은 주변 사람들과 주고받는 마이크로 인터랙션에 신경을 쓰는 겁니다. 그걸 기록하고, 복기하고, 다르게 인터랙션한다고 하면 어떻게 했으면 좋았을까를 생각해보는 것만으로도 훈련이 될 수 있습니다.
저는 ... TDD를 사람들에게 교육하고 컨설팅해주었습니다. 제 경험에 한해서는 TDD 도입에 실패하는 경우, ... 필요한 사회적 자본과 사회적 기술이 없어서가 훨씬 더 많았습니다.
어떤 기술적 지식을 전달한다고 해도 그것을 사회적 맥락 속에서 가르치고 경험하게 하려고 노력하고 있습니다.
제가 중요하게 다루는 사회적 기술은 도움받기, 피드백 주고받기, 영향력 미치기, 가르치고 배우기, 위임하기 등이 있습니다.
함께
사람들은 협력이 중요하다고 합니다. 그래서 프로젝트를 할 때 협력적으로 하자고 합니다. 그러나 실제 모습을 들여다보면 초반에 일을 세밀하게 나누고 선을 긋습니다. 그리고 안녕이죠.
우리는 협력을 제대로 배워본 적이 거의 업시 때문입니다.
그래서 지금부터라도 협력 방법을 배우고 수련해야 합니다.
소프트웨어 관리자의 개선 우선순위
조엘 테스트라는 것이 있습니다.
그러나 여기에 가장 큰 위험이 존재합니다. 선의의 관리자나 경영진이 각 질문의 맥락을 이해하지 못한 채 단순히 12가지 질문에 예라고 답하는 것을 목표로 노력하는 경우를 말하는 겁니다.
모든 항목에 "예"라고 답하는 것이 무조건 더 낫다고 동의하기 어렵다
제가 아는 뛰어난 팀들은 툴을 고를 때 단순히 비싼 게 뭐냐를 기준으로 고르지 않습니다. 이 항목을 보고 '비싼 툴을 쓰면 잘하겠지'하고 생각하는 건 기술을 이해하지 못하는 경영자 마인드에 가깝습니다.
12가지 질문이 개발팀 평가에서 정말 중요한 요소인가?
품질 전문가 제럴드 와인버그가 한 말을 살펴봅시다. 이분은 소프트웨어 개발을 잘 관리하려면 세 가지 근본적 능력이 필요하다고 했습니다.
- 복잡한 상황을 이해하는 능력으로, 프로젝트를 계획한 다음 관찰하고 행동하여 계획에 맞게 프로젝트가 진행되게 하거나 계획을 바꿀 수 있어야 한다.
- 관찰하는 능력으로, 무엇이 벌어지고 있는지를 관찰하고, 효과적인 적응 행동을 하기 위해 자신이 관찰한 것이 어떤 의미인지 이해할 수 있어야 한다.
- 행동하는 능력으로, 어려운 대인 상황에서 우리가 심지어 혼란스럽거나 화가 나 거나 아니면 무서워서 도망쳐 숨어버리고 싶을 때에도 적절하게 행동할 수 있어야 한다.
이 세 가지 능력을 활용해 실제 조직과 개인(관리자 자신을 포함-와인버그는 자신을 바꾸지 못하는 사람은 다른 사람을 바꾸는 일도 할 수 없다고 합니다)
QSM 4권에 소프트웨어 개발 비용에 대한 내용이 있습니다. 다음 네 가지 요소의 분류에서 가장 중요한 것부터 나열해 보세요.
- 도구 : 소프트웨어 개발에 사용하는 모든 종류의 도구. 컴퓨터, 모니터, 디버거, IDE
- 사람 : 사람들의 능력과 경험
- 시스템 : 제품 자체의 복잡도, 요구되는 신뢰성, DB 크기, 타깃(VM 등)의 변화 가능성, 스케줄 제약 등
- 관리 : 사람을 배정하고 작업 분배를 조정하고 위임하는 것, 작업 모니터링, 동기를 고취하는 것, 작업 조건/환경을 개선하는 것, 자원의 준비, 리스크를 일찍 확인하고 적절한 조치를 취하는 것, 요구사항과 설계 스펙이 비준(validate)되게 돕는 것 등
비슷한 크기의 소프트웨어를 개발한다고 할 때, 각 분류별로 비용 면에서 가장 적게 드는 회사부터 그렇지 않은 회사까지 100등까지 순위를 매깁니다. 85등이던 회사가 10등하는 회사로 '개선'을 했다면 개발 비용이 얼마나 줄어들까요? 개선효과가 높은 것은 무엇일까요?
...
관리, 시스템, 사람, 도구 순서였습니다. ... 하지만 각 분류별로 실제로 개선 시도가 얼마나 있었는지 확인해 보니 가장 많은 개선 노력이 있었던 분류를 바로 '도구'였습니다
다시 조엘 테스트로 돌아갑시다. 조엘 테스트는 가장 만만하고 쉬운 것부터 시작하는 관리자의 성향과 충돌하지 않습니다.
저는 관리자가 눈에 잘 보이고 갈아치우기 쉬운 '도구'들에 신경을 쓰는 것이 위험하다고 생각합니다.
협력을 통한 추상화
커뮤니케이션과 협력
일반적으로, 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 커뮤니케이션, 협력 능력이 더 뛰어납니다.
백지장도 맞들면 찢어진다?
톱니바퀴 실험
둘이서 함께 작업한 경우 58%나 추상화 규칙을 찾아냈습니다. 4배가 넘습니다. 만약 두 사람이 한 팀으로 작업하되 서로 이너랙션하지 않았고, 그들의 결과물 중 더 나은 것을 택하는 방식(명목 집단(nominal group)이라고 함)이라면? 이 경우는 확률적으로 계산할 수 있는데, 26%가 됩니다.
그러면서 맞은편의 사람과 이야기를 하는데, ... 이런 혼동을 해결하기 위해 추상적 개념을 도입합니다. 예컨대 바퀴에 식별 번호를 붙인다든지 하는 것이지요.
둘이서 협력하면서 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해 줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 됩니다. 서로 다른 것들을 하나로 묶어야 하기 때문입니다.
추상화의 중요성
만약 코드가 비지니스 로직이 들어가고 그 로직이 domain-rich 하다면 되도록 가독성을 추구하겠지만, 저는 때로 가독성을 손해보면서까지 중복을 줄이기도 합니다. ... 흥미로운 객체들을 발견합니다. ... 내가 전에 모르던 것을 배우게 됩니다.
'흥미로운 무엇'이 바로 추상화입니다.
인용문 대로 소프트웨어 공학의 역사는 정말 추상화를 높이기 위한 여정이었습니다. ... 그런데 우리는 조금 전 추상화를 높일 수 있는 방법을 하나 찾아냈습니다.
대화하는 프로그래밍
익스트림 프로그래머는 작업하면서 프로그래밍 각 단계에 대해 함께 이야기한다.
자신이 작성하는 코드의 추상성을 높이고 싶다면 혼자서 고민하지 말고 다른 사람들과 협동하고, 대화하세요. 같이 그림도 그려보고 함께 소스코드를 편집하세요. 인간에게는 다른 인간과 소통하고 협력할 수 있는 놀라운 능력이 있습니다. 대화는 기적입니다.
신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가
공유 조건별 신뢰도 변화 실험
조금 충격적인 이야기를 해드리겠습니다. 두 경우 모두 공유 후에 신뢰감이 더 떨어졌습니다. 특히 첫 번째, 즉 디자인 하나만 작업하고 그걸 공유한 경우가 더 많이 떨어졌습니다만, 두 조건 모두 신뢰감이 통계적으로 유의미하게 떨어졌습니다. 공유를 해서 신뢰가 더 떨어지는 상황이 벌어진 것이죠.
각자 여러 개의 디자인을 만들고 그걸 모두 공유한 경우였습니다. 이때는 신뢰가 유의미하게 증가했습니다.
하나 공유나 최고 공유의 경우 우리는 공유 자리에 기대감보다 불안감을 갖고 갈 겁니다.
복수 공유의 장점
복수 공유는 그런 불안감이 상대적으로 덜합니다. 여러 개를 준비했으니 그중 하나를 두고 뭐라고 해도 나에 대한 공격은 아닌 겁니다.
마지막으로 가장 놀라운 부분 ... 클릭률이 더 높았습니다. 복수 공유는 (같은 시간을 투자했을 때) 신뢰도 높아지고 성과도 더 좋았다는 말입니다.
여러분의 공유는 어떻습니까? 신뢰를 깎아먹는 공유를 하고 계신가요, 신뢰를 쌓아가는 공유를 하고 계신가요?
객관성의 주관성
새로운 개념을 주변에 설득하기 위해 노력하는 분들을 많이 봅니다.
그런 분들을 만나면 저는 다음과 같은 질문을 던집니다. "상대방에 대해 얼마나 이해를 하고 계신가요? 얼마나 대화를 해보셨나요?"
강사는 자신이 좋은 예를 들었다고 생각합니다. 하지만 질문자는 그렇게 생각하지 않습니다. '예'의 정이가 주관적이라 벌어진 일이죠.
품질은 상대적이다
품질 전문가 제럴드 와인버그는 품질을 다음과 같이 정의합니다.
품질이란 누군가에게 가치가 되는 것이다.
우리가 일반적으로 듣는 품질의 정이와 다르죠? ... 그런 정의들은 매우 플라톤적입니다. 뭔가 고상하고 완벽한 품질이라는 것이 하늘 어딘가에 있는 것처럼 들립니다. 하지만 와인버그의 정의는 상대주의적이며 동시에 무척 실용적입니다.
우리가 품질을 이야기할 때에는 '누구'를 놓고 하는 말이냐는 걸 생각해 봐야 한다 이겁니다.
결국 결정하는 것은 사람입니다.
감정을 배제할 수 없다
그리고 논리랑 감정적 판단을 분리할 수가 없습니다.
의사결정을 하는 과정에 감정적이고 직관적인 부분이 큰 역할을 하고 있으며, 그런 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없다는 것을 알 수 있습니다.
남을 설득하려면 논리성과 객관성에 대한 환상을 버려야 합니다. 그래야 현실적으로 설득이 가능합니다. 내가 설득하고 싶은 상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야 합니다.
성향과 기질에 따른 애자일 설명법
결론은, 객관성이라고 하는 것은 상대적이며, 내가 생각하는 객관이 상대의 객관이 아닐 수 있고, 그렇기 때문에 설득에 성공하려면 우선 그 사람을 이해하는 것에서 출발해야 한다는 말입니다.
이것도 모르세요?
공감하고 이해하려는 대화
이런 과정을 거치면 홍춘이의 머릿속에는 어떤 그림이 떠오를까요? ... 술퍼맨의 머릿속 지도와 사고 흐름을 엿보게 되는 것이죠.
그 사람이 이 상황에서 왜 이런 접근을 할 수밖에 없었는지 알기 때문에 좀 더 정확하고 효과적인 제안을 해줄 수 있습니다. ... 또, 소위 암묵지라고 부르는 것들을 전달해줄 수도 있습니다.
행동을 유도하는 대화
술퍼맨 : 네, 그러고 싶어요. 그런데 언젠가 한번 마음먹고 제대로 공부해야지, 해야지 하고 생각하면서 몇 달째 미루고 있는 것 같아요.
홍춘이 : 정규식을 배워서 해보고 싶은 것들이 있나봐요. ...
참고로 코칭의 흥미로운 점은 코치 자신(홍춘이)이 해당 영역(정규식)에 대한 전문지식이 없어도 코칭을 할 수 있다는 점입니다.
하향식 접근의 함정
대부분의 기업에서 직원 숫자가 늘어나기 시작하면 추상 층위에 따라 팀을 나눕니다. 각 층위의 전문가 팀이 존재합니다. 기획팀, 구현팀, QA팀 등, 그리고 일이 진행됨에 따라 팀 간의 바통 터치가 이루어집니다. 위에서 아래 방향으로요.
그럼 모든 문제를 탑다운 식으로 푸는 것이 우리의 지향점일까요? 인공지능 연구에선 이 세상의 문제를 두 종류로 나눕니다. 잘 정의된 문제와 잘 정의되지 않은 문제 ... 오목이나 체스 ... 여기에 속합니다.
하지만 우리가 실생활에서 만나는 대다순의 문제는 잘 정의되지 않은 문제입니다.
앞서의 전문가들은 ... 잘 정의되지 않은 문제를 접하면 접근법을 바꿉니다. 탑다운과 바텀업을 섞어 씁니다. 뛰어난 전문가일수록 더욱 그러합니다.
특히 탑다운과 바텀업의 방향이 전환되는 시점들에서 '아하 순간'이 찾아왔습니다.
"이번 일은 복잡하고 불확실하니까 철저하게 계획하고 단계적으로 접근하자!" 이 말은 곧, 이번 일은 불확실하니까 초보처럼 일하자는 말과 똑같습니다.
오히려 전문가일수록 자신의 계획을 수정한 횟수가 많았습니다.
연구에 따르면, 프로그램을 이해할 때 고수는 상호 참조 전략을 쓰는 반면 하수는 그렇지 않았습니다.
고수는 ... 프로그램에서 이해한 것을 도메인 어휘로 번역합니다. 그러고는 도메인 어휘를 프로그램상의 어휘로 다시 바꿔서 검증합니다. 이를 상호 참조 전략이라고 합니다.
빠르고 빈번한 바통 터치가 가능한 전문가 조직
삼투압적 의사소통
사람들이 물리적으로 가까운 거리에 있어야 유리하겠죠.
그리고 한번에 처리되는 일의 양(batch size)을 줄여야 합니다. 배치 사이즈를 줄여서 지속적 흐름을 만들고 짧은 시간 내에 탑, 바텀을 오가게 합니다. 예를 들어 전에는 디자이너가 100개의 일자리를 다 처리한 후에 한꺼번에 모아 결과를 전달했다면 점차 50개로, 10개로, 1개로 낮추어야 합니다.
어느 한 단계를 한번에 완료하는 것은 더 낮은 품질로 가는 지름길입니다.
흔히들 말하는 개발의 5단계도 비슷합니다. ... 어떻게 해야 첫 달부터, 아니 첫 주부터 분석, 설계, 구현, 테스트, 전개를 모두 왔다갔다할 수 있을까를 고민해야 할 것입니다.
전문가 팀이 실패하는 이유
회사에서의 올스타는 어떨까요? ... 스타들이 한 명씩 팀에 추가될 떄마다 팀의 추가적 성과 향상은 한계효용을 보이며 어느 수준을 지나면 음의 방향으로 작용한다고 합니다.
전문가가 추가되는게 도움이 안 되거나 오히려 성과를 깎아먹는 경향은 특히나 전문가들의 전문성이 서로 유사할 떄 도드라졌습니다.
자기들이 알아서 하게 놔둔 전문가팀은 비전문가로만 구성된 팀보다도 훨씬 못한 결과가 나왔습니다.
팀 내에 개인 내 다양성이 높은 멤버가 없다면 전문가로 구성된 팀은 정보 공유가 잘 안 되어서 성과가 떨어질 수 있다는 분석을 했습니다.
구글이 밝힌 탁월한 팀의 비밀
제가 봤을 떄 중요한 부분은 세 군데입니다.
팀에 누가 있는지(전문가, 내향/외향, 지능 등)보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.
5가지 성공적 팀의 특징을 찾았는데, 그중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감이었다.
팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있었다.
여기에서 말하는 심리적 안전감이란, 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음을 말합니다.
에드몬드슨은 이런 도구를 사용해 병원의 중환자실의 심리적 안전감을 측정해 보았습니다. ... 예상과 비슷하게, 직위에 따라 느끼는 심리적 안전감에 통계적으로 유의미한 차이가 있었습니다.
심리적 안전감이 높은 병실에서는 ... 18%나 낮은 사망률을 보였습니다.
팀원이 불편한 문제를 제기하거나, 어리석어 보이는 질문을 하거나, 부족한 의견을 얘기하거나, 어처구니없는 실수를 저지를 때 여러분은 어떤 마이크로 인터랙션을 보여주고 계신가요?
쾌속 학습팀
최소 침습 심장 수술
논문 제목은 <팀 학습의 속도 높이기>입니다. 최소 침습 심장 수술법을 어떤 팀이 빨리 익히는가 하는 것이 주제입니다.
하지만 놀라운 점은 수술 시간 감소율이 팀마다 천차만별이었다는 겁입니다.
학습 속도와 상관없는 것
리더가 팀 학습 속도에 미치는 영향
단순히 기술적 탁월함만을 갖춘 사람보다는 학습 환경을 만들 수 있는 리더가 필요하다는 것입니다.
학습 환경의 차이
선발 자체가 매우 협동적
속도가 빠른 팀은 새로운 수술 도입을 기술적 도전이라기보다 조직적 도전으로 받아들였습니다. 개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각했습니다.
마지막으로, 속도가 빠른 팀은 심리적으로 보호가 되고 있었습니다.
기술 전환에 성공한 개발팀
속도가 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했습니다.
속도가 느리거나 낙오된 팀은 학습을 개인의 과제로 치부했습니다. 학습보다는 단기 퍼포먼스를 중요시했습니다.
현실에서 실천하기
다시 현실에서 돌아와서, 나는 팀장도 아니고, 정치적인 힘도 없습니다. 그렇다면 이 상황에서 내가 무엇을 할 수 있을까요? 팀원과 팀장에게 이 책을 권할 수 있는 분위기도 아니라면?
우선 자신의 학습 환경을 만드세요. 거기서부터가 출발입니다. 개별 기술 이상으로 일하는 방식에 대해 실험을 해 보세요.
프로젝트 확률론
이번 프로젝트는 제떄에 끝낼 수 있을 것 같았는데
소프트웨어 공학 쪽의 연구에 따르면 사람들이 통상적으로 추정하는 소요시간에 적어도 2~3배를 해야 80% 정도의 확률로 마칠 수 있는 시간이 나온다고 합니다.
게다가 일반적으로 일의 소요 시간을 추정할 때 사람들이 낙관적으로 추정한다는 편향에 대한 연구 결과가 많다는 점까지 고려하면 상황은 더 심각해집니다.
또 다른 연구에 따르면, 사람들에게 가장 그럴싸한 추정(best guess)을 부탁했을 때와 자신이 기대하는 최선의 상황(best case scenario)을 상상해서 추정해보라고 부탁했을 때 그 추정치는 큰 차이가 없었습니다.
애자일 확률론
제가 선호하는 접근법은 관리자가 12명 모두에게 단지 3가지 일만 주고 서로 협동해서 그 일을 하도록 요청하는 것입니다.
이 방식이 잘 돌아가는 이유는 사람들이 '관심사의 섞임'을 통해 서로에 대해 엄청나게 많은 것을 매우 빨리 배울 수 있기 때문입니다.
애자일은 앞서의 고전적 방법과 달리 일을 공유합니다. 각자 일을 얼마나 진행했는지 매일 공유할 뿐 아니라 내 일, 네 일의 구분선이 뚜렷하지 않습니다. 애자일에서는 되도록 사람들이 섞이도록 합니다.
애자일은 마치 프랙털 구조처럼 부분 속에 전체가 들어가게 합니다. 그렇게 하면 과거에서 미래를 접쳐 보기가 훨씬 쉽습니다. 일이 진행될수록 점점 추정 정확도가 높아집니다.
한 사람만이라도 중요한 통찰이 있었다면 이걸 공유해서 '또는' 확률로 만들고, 버그 같이 나쁜 일에 대해서는 여러 사람이 중복 검토를 해서 모두가 실수해야지만 구멍이 나게 '그리고' 확률로 바꾸는 것입니다.
애자일
당시 주도적인 소프트웨어 개발 방식은 계획주도의 방식이었습니다. 계획주도 방식에서는 초반에 계획을 정교하고 꼼꼼하게 만들려고 엄청난 노력을 합니다. 그러면 실행단계는 간단해지고 예측 가능해진다고 생각하기 때문입니다. 하지만 애자일은, 불확실성이 높은 일에 대해서는 애초에 이것이 불가능하다고 봅니다. 불확실성 크기 때문에 미리 분석하고 설계하는 데 한계가 있다는 것이지요.
이번에는 과의의 애자일을 얘기해 보겠습니다. 애자일을 단순히 소프트웨어 개발 방법론이라는 울타리에 가두어 보지 않고, 일하는 한 가지 스타일, 혹은 더 넘어서서 삶을 사는 방식으로까지 확장해 보는 것이지요.
학습과 협력은 불확실성이 큰 상황에서 좋은 대응전략이 됩니다. 우리의 삶도 불확실하기 때문에 학습과 협력은 현명한 전략이 될 것이고요.
애자일의 씨앗
씨앗이 될만한 것을 줘야합니다.
고객에게 매일 가치를 전하라.
애자일 도입 성공 요인 분석
두려워도 중요하다면 시도해봐야 하지 않겠는가
당신의 조직에 새 방법론이 먹히지 않는 이유
결과들을 보면 상담에서 어떤 기법을 쓰느냐보다 치료자가 누구인가가 상담 효과에 더 큰 영향을 준다는 게 거듭 밝혀졌습니다.
매뉴얼이 말하고 있는 것보다 훨씬 더 많은 것을 상담사들이 할 수 있다는 말이 될 것입니다.
사실 더 나아가서 모든 지식이 근본적으로는 암묵지라고 역설했습니다.
맥락을 가로지르는 보편적 규칙들이 별로 없다고 생각이 든다면, 결과를 에측하기 어렵고 불확실성이 높다면, 해당 분야는 '복잡한 도메인'이 됩니다. 상담이 그렇죠. 이런 복잡한 분야일수록 어떤 특정 기법의 효과보다도 치료자 효과가 더 큰 영향을 미칠 것입니다.
내가 어떤 팀장인지가 전혀 바뀌지 않으면서 새 방법론만 도입한다고 무슨 효과가 있을까요.
애자일을 애자일스럽게 도입하기
칸반 같은 개별 실천법은 상시 변화하고 발전하는 도요타의 특정 시점의 스냅샷 같은 것이 아닐까 생각합니다. 우리가 배워야 할 것은 칸반 이면의, 칸반이 나올 수 있었던 구조의 문화입니다.
"... 애자일을 도입할 때 확실성 위에서 진행하려고 한다면 문제가 된다"
이것은 거의 모든 종류의 방법론 도입에 적용됩니다. 왜냐하면 방법론 도입은 태생적으로 불확실성이 높기 때문입니다. ... 수순을 따르는 것이 아니라 곁에 있는 사람들과 함께 주변을 탐색하고 조금 나아가고 확인하고를 반복하면서 우리의 현 맥락에 맞는 좋은 전략들을 스스로 만들어 나가는 것이 아닐까 합니다