코칭(Coaching)

[!tldr] 한줄 요약 코칭은 개인이 이미 가진 잠재력을 질문, 성찰, 피드백을 통해 이끌어내는 조력 활동이며, 소프트웨어 개발에서 기술적 역량만큼 중요한 사회적 기술(피드백 교환, 협력적 문제해결, 신뢰 구축)의 기반이 된다.

핵심 내용

코칭은 "사물을 다른 시각으로 바라보고, 그걸 자신의 말로 설명해주며, 문제에 어떻게 접근할지를 논의"하는 활동이다. 에릭 슈미트와 스티브 잡스 모두 빌 캠벨이라는 동일한 코치를 두었으며, 슈미트는 "도무지 과장해 말할 수 없을 정도의 공헌"이라고 평가했다.

핵심 오해 타파: 코치가 해당 분야의 최고 전문가일 필요가 없다. 코치의 역할은 "선수"의 역할과 완전히 다르다. 모든 사람에게 코칭이 필요하다.

1. 질문으로 가르치기 (Timothy Gallwey)

"입을 다물고 가르치기" — 20분 이상 강의 금지, 대신 질문으로 학습 유도. 학생은 경험을 통해 스스로 통찰을 얻고, 교육자는 경험 환경을 만들어 성찰을 유도한다.

2. 피드백의 힘 — "어라가 전문가를 만든다"

자신의 예상과 다른 피드백을 받을 때 진짜 성장이 일어난다. 상담자가 내담자 피드백에 놀란 횟수가 상담 효과를 62% 예측했다. 놀라움을 적극 추구하는 태도가 핵심이다.

3. 리더의 코칭 자세

"아는 것을 모르는 척하고 기다려줄 수 있는 능력"이 핵심이다. 성공과 실패가 약 반반인 상황에서 최대 학습이 발생하며, 안전한 실패 환경을 조성해야 한다.

소프트웨어 개발에서 뛰어난 개발자와 평범한 개발자의 차이는 코딩 능력이 아니라 다른 사람과의 상호작용 방식에 있다.

효과적인 피드백의 3요소 (회고(Retrospective) 연구에서 발견):

균형잡힌 감정 표현 — 긍정과 부정을 모두 표현. 잘한 점만 나열하면 성장이 없고, 비판만 하면 신뢰가 무너진다
진화하는 서사 — 같은 주제에 대해 점점 더 깊이 성찰. "테스트가 부족했다" → "왜 테스트를 안 썼을까" → "시간 압박에서 어떤 판단 기준이 필요할까"
관점 전환 — "내가 힘들었다"(1인칭)에서 "팀이 어떻게 느꼈을까"(타인 관점)로 확장

코치의 역할은 이 세 요소가 자연스럽게 일어나는 대화 구조를 설계하는 것이다.

전문가 팀의 역설: 협력 계획이 없는 전문가 팀은 비전문가 팀보다 성과가 낮다. 차이를 만드는 것은 추상화를 통한 공유 이해다:

시각화 — 화이트보드나 문서로 문제를 함께 볼 때, 텍스트/음성만으로는 불가능한 협력이 가능해진다
명시적 소통 구조 — "10분간 각자 분석 → 5분간 발견 공유 → 함께 결정"처럼 구체적인 협력 프로세스 필요
공유 모델 구축 — 개인의 멘탈 모델을 팀의 공유 모델로 발전. 짝 프로그래밍(Pair Programming), 몹 프로그래밍이 이를 자연스럽게 만든다

코칭이 작동하려면 심리적 안전감(Psychological Safety)이 전제되어야 한다:

TDD 도입 실패의 대부분은 기술 이해 부족이 아니라 사회적 요인이었다. 기술 변화의 성공은 사회적 기술에 달려있다.

AI 시대에 대체하기 가장 어려운 능력이 바로 이 사회적 기술이다: 협상과 설득, 공감, 의사소통, 갈등 해결.

[!tip] 핵심 인사이트

성장의 복리 효과 — 자기계발은 복리처럼 돌아온다. 각 학습이 다음 단계의 기반

변화는 자신부터 — 조직 변화를 원하면 먼저 자신이 변해야 한다

코칭의 본질 — 권력 관계가 아닌 성장을 위한 동반자 관계