나는 2020년 10월을 시작으로 지금까지 여러 명의 개발자들을 코칭하고 있다. 초보 코치로써 약 1년 5개월 동안 배운 것을 정리했다.

1. 코치는 그저 거들 뿐이다

함께 개발을 하면서 코칭을 하다보니 해결하기 어려운 문제를 만나면 내가 주도적으로 해결했다. 결과적으로 내게 의존성이 높아졌으며 어려운 문제가 생기면 나를 찾았다. 보다 본질적인 문제는 코치가 아닌 개발자 본인이 성장하지 못한다는 것이었다. 성장은 자신이 주도적으로 문제를 해결해 가며 겪는 수 많은 실수와 실패의 집합이다. 다른 사람이 문제를 해결해 버리면 단기적으로 좋을지 모르겠지만 장기적으로는 성장의 기회가 사라진다.

그래서 나는 스스로 제약을 걸었다.

함께 문제 해결을 위한 짝 프로그래밍을 제외하고는 나는 코딩하지 않겠다.

문제를 주도적으로 해결하는 것은 내가 아니다. 본인이 해야 한다. 다만 짝 프로그래밍을 예외를 두었는데 그 이유는 무엇이었을까?

문제를 해결하다가 보면 혼자 넘을 수 없는 벽에 부딪치기 마련이며 함께 해결해야 한다. 문제를 푸는 첫 단계는 문제 인식이며 가장 중요한 것이 맥락을 함께 공유하는 것이다. 이를 위해 내가 자주(거의 항상) 쓰는 원칙은 ‘On the Same Page’ 이다. 한 마디로 같은 것을 보고 말하는 것이다. 매우 당연하다고 생각이 되는데 현실적으로 이 원칙을 지키는 사람이 많지가 않아 맥락이 공유되지 않아 상대방이 말을 이해하지 못하거나 오해를 해서 시간을 낭비한다. 또한 전문가 중 상당 수는 자신이 어떻게 문제를 풀었는지 인식하지 못하는 경우가 많다고 한다. 문제를 풀었는데 어떻게 풀었는지 잘 설명할 수 없다는 것이다. 흔히 암묵지(暗默知)라고 부르는데 상대방에 전달하기 쉽지가 않다.

짝 프로그래밍은 문제의 맥락과 코치의 암묵지를 효과적으로 전달할 수 있는 방법이다.

코치는 그저 거들 뿐이다.

2. 상대방이 도움을 진짜 원하는지 물어보라

내가 3개월 정도 코칭하던 개발자가 있었다. 어느 순간 그 개발자가 잘 따라오지 못한다고 느꼈는데 그래서 생각했다.

• 일의 양이나 난이도의 문제일까?
• 아니면 일 외에 다른 문제가 있는 것일까?

대화를 시도했을 때에도 위의 문제는 아니라고 했다. 그렇다면 무엇이 문제일까?

제럴드 와인버그의 책 <테크니컬 리더>에서는 ‘다른 사람들을 돕는 문제'에 대해 아래와 같이 말하고 있다.

만약 사람들이 당신의 도움을 원하지 않는다면, 당신이 아무리 똑똑하고 훌륭한 사람이라고 해도 절대 성공적으로 도움을 줄 수 없다.
(중략)
효과적으로 도움을 주려면 문제를 명확히 정의하고, 그 정의를 상호 합의할 필요가 있다.
(중략)
이 것은 뛰어난 문제 해결사들 사이에서 일어나는 동기부여의 가장 흔한 실수다. 다른 사람들을 관리할 때 무심코 상대방이 언짢아할 수도 있는 도움을 제의하는 것이다.
(중략)
상대방이 도움을 바라고 있는지 아닌지 항상 확인하자. - <테크니컬 리더>, 205~206쪽

나는 깨달았다. 코칭을 하기 전에 한번도 코칭을 원하는지 물어보지 않았음을 또한 상호 합의가 아닌 내가 정한 일방적인 코칭 방식을 시도했음을...

그 개발자와 다시 대화를 했다. 진정 내 도움을 원하는지 진심을 물었다. 그리고 그 개발자는 생각할 시간을 달라고 했고 결국 퇴사했다. 이 일 이후로 나는 코칭을 하기 전에 상대방이 진정 코칭을 바라고 있는지 확인한다. 상대방이 도움을 원하지 않는다면 절대 성공적으로 도움을 줄 수 없는 것이다.

3. 조금씩 천천히 점진적으로 그리고 작게 시도하라

일에 자신감을 가지게 하는 것은 중요하다. 동기부여하고도 연결되기 때문이다. 그럴려면 충분한 피드백과 함께 성취감을 느껴야 한다. 단순하고 쉬운 일부터 주도적으로 충분히 할 수 있는 기회를 제공해야 하며 본인이 스스로 느끼거나 깨달을 수 있게 해야 한다.

충분한 피드백과 성취감을 느끼게 하려면 사용 중인(혹은 운영 중인) 시스템에 시도해야 한다. 문제는 위험성이다. 처음하다 보면 서툴러 실수를 할수 있기 때문이다. 위험 부담을 줄이기 위해서는 최대한 일을 작게 나누어야 한다. 작을 수록 위험 부담이 준다. 잘못된 것이 적기 때문이다. 그리고 작기 때문에 문제를 찾아내 해결하기가 쉽다. 일을 작게 나누어 한다는 것은 구체적으로 어떻게 한다는 것일까? 나는 ‘일주일별 주기’를 사용한다. 한 번에 일주일 분량의 일을 계획하고 실행하는 것이다. 일주일 안에 운영에 배포 가능한 동작 가능한 코드를 만드는 것이다.

일에 익숙해질 때 쯤 자신감에 차 본인이 시도하고 싶은게 있다고 말할 때가 있다. 그런데 코칭하는 입장에서 보면 눈이 보이는 실패의 길이다. 어떻게 해야 할까?

본인이 하고 싶다면 내가 보기에 잘 못 되었다고 판단되더라고 가로 막지 말라.

나는 두 아이를 양육하며 배운 것이 있다. 삶의 경험 많은 부모 입장에서 아이의 시도를 가로 막는 것이 아이 성장에 결코 도움이 되지 않는다는 것이다. 우리는 직접 해보면서 깨닫고 배운다. 먼저 해보았다고 상대방에게 하지 말라고 하면 반발심만 커진다. 그리고 항상 내가 옳은 것도 아니다. 본인이 스스로 깨달을 수 있도록 충분히 시간을 주어야 한다. 다만 나는 위험 부담을 줄이기 위해 제약을 둔다. 앞서 언급한 것 처럼 작게 시도하게 만드는 것이다.

켄트 벡은 <익스트림 프로그래밍>에서 ‘아기 발걸음'을 말했다. 아기가 걸음마 때듯 조금씩 천천히 점진적으로 작게 시도하자.

아기 발검음은, 단계를 잘게 쪼갤 때 생기는 부하가 큰 변화를 시도했다가 실패해서 다시 원상태로 돌아갈 때 드는 낭비보다 훨씬 작다는 사실을 인정하는 것이다. - 익스트림 프로그래밍, 66 쪽

4. 실패를 학습의 기회로 그리고 배움으로 전환 시켜라

내가 전자 상거래 회사에서 재직할 때 있었던 일이다. 주문 업무를 담당 했었는데 함께 일하는 시니어 개발자가 내게 이런 말을 했다.

주문 업무는 돈이 관련되어 있어서 다른 사람들이 하려 하지 않아 담당자를 구하기 힘들어.

앞서 풍부한 피드백을 얻기 위해서는 사용 중인(혹은 운영중인) 시스템에 시도해야 한다고 언급했다. 하지만 경력과 무관하게 시도하는게 두려울 수 있다. 잘 못해서 실수하기라도 하면 그로 인한 여파를 무서워하는 것이다.

두려움에 용기를 내지 못하는 이들에게 ‘안전한 공동체’가 되어 줄 수 있다. 실수/실패하더라도 괜찮다는 믿음을 줄 수 있는 동료가 있다는 건 용기를 낼 수 있는 큰 힘이다. 부모는 아이가 태어나 성장할 때까지 안전한 공동체가 되어준다. 안전한 공동체 안에서 아이는 부모를 믿고 끊임 없이 실수하고 실패하며 그 속에서 배우고 성장한다.

운영 배포 후 장애가 발생했다고 생각해 보자. 안전한 공동체가 아닌 곳에서는 개인에게 책임을 묻는다. 문제를 개인으로 몰아서 책임을 전가하는 것이다. 글쎄 개인의 문제/책임일까? 문제는 정도가 다를 뿐 모두가 기여 하는 것이다. 안전한 공동체에서는 문제를 ‘우리의 문제’로 받아들인다. 이 과정에서 믿음이 생긴다고 나는 믿는다.

우리는 성공에서 보다 실패에서 많은 것을 배운다. 실패에서 배워야 한다. 그리고 똑같은 실패를 하지 않아야 한다.실용적인 접근 방식은 오노 다이이치가 고안한 Five Ways 이다. 왜 문제가 발생했는지 다섯 번 묻는 것이다.

‘왜 다섯 번'을 하고 나면 결함의 중심부에는 사람 문제가 놓여 있다는 것을 알게 된다(거의 언제나 사람 문제다). 이 문제를 해결하고, 그 과정에서 다른 문제들도 해결한다면, 이것과 똑같은 문제를 두고 앞으로 다시 씨름할 필요가 없으리라는 것에 대해 어느 정도 안심할 수 있다. - 익스트림 프로그래밍, 111 쪽

5. 여러가지 선택지를 제안하라

하나 보다는 여러가지 선택지를 제안할 때 상대의 자율성을 덜 침해한다고 한다. 하나만 제안할 경우 상대방이 선택의 여지가 없기 때문에 강요로 받아들일 수 있으며 강요는 복종 아니면 반항이라는 반작용을 부른다. 상대의 자율성을 덜 침해할 때 상대가 더 주도적이게 된다. 본인이 스스로 선택했기 때문이다.

반면 “하고 싶지 않다”고 말하는 사람이 드물다는 사실을 깨달았다. 내가 추정하는 이유는 크게 두 가지 이다. 첫 번째는 자신이 하고 싶은 일이 명확하지 않기 때문이고 두 번째는 거절하는 것 즉, 상대에게 부정적인 피드백을 주는 것이 익숙하지 않기 때문이다(누가 가르쳐 주지도 않는다). 또 다른 여러가지 이유가 있을 수 있는데 그래서 나는 코치 입장에서 한 가지 선택지를 더 제공한다.

꼭 할 필요는 없다. 하고 싶지 않는 것도 선택이다.

코칭 상대에게 여러 선택지 중에서 ‘하지 않는 것’도 있다는 것을 인지 시켜 주는 것이다.

선택을 할 때 중요한 것은 ‘결정에 충분한 정보'이다. 정보가 충분하지 않은 상태에서 고민만 하다가는 시간만 낭비한다. 실용적인 접근 방법은 여러 선택지를 모두 조금씩 해보고 결정하는 것이다. 언뜻 보면 낭비일 것 같은 말이다. 모두 해보라니...

나는 전에 어떤 프로그래밍 언어를 쓸 것인가를 고민한 적이 있었다. 두 가지 선택지가 있었다.

• Node.js
• Python

문제는 내가 둘 다 실제로 해본적이 없다는 것이었다. 해본적도 없으면서 고민한다니 웃기는 일이었다. 결국 나는 간단한 기능을 일주일씩 두 가지 언어를 모두 구현해 보았다. 해보니 알게 되었다(결정에 충분한 정보). 지금 내 맥락에는 Python이 맞다는 것을...

세 가지 해결책 가운데 어떤 것이 가장 단순한 방법일까? 셋다 시도해 보고 판단하라. - 익스트림 프로그래밍, 48 쪽

6. 사실에 근거해 피드백 하라

의사소통의 핵심은 피드백이다. 스포츠 영화를 보면 코치가 스톱워치를 들고 측정한 결과를 선수에게 공유하는 것을 흔히 볼 수 있다. 코치의 주관적인 의견이 아니라 객관적인 정보를 보여 주는 것이다. 조언보다 사실에 근거한 정보 제공이 상대가 피드백을 수용할 가능성이 높다.

구체적인 사례를 살펴보자. 아래는 기부 내역을 보여 주는 화면이다. 상단에는 ‘기부 번호'로 조회하는 기능이 있다.

나는 직관적으로 사용자가 기부 번호로 조회하는 기능을 제대로 쓰지 못할 것 같았다. 그러나 이건 내 느낌일 뿐이다. 내 직관에 근거한 피드백을 주면 상대가 받아들일까? 코치가 상대에 비해 나이가 많고, 경험이 많으며 직급이 높다면 거부하기 어려울 것이다. 하지만 앞서 언급한 것 처럼 강요는 큰 반작용을 부른다. 사실에 근거에 피드백을 하려면 데이터가 필요하다. 4일간 사용자가 기부 번호를 잘 못 입력하는 경우를 측정해 보았더니 400건이나 발견했다. 자 이제는 데이터로 피드백할 시간이다.

측정할 수 없으면 관리할 수 없고, 관리할 수 없으면 개선시킬 수도 없다. - 피터 드러커

7. 가르치려만 들지 마라

코칭을 하다보면 가르쳐야 한다는 생각에 일방적인 ‘충조평판(충고, 조언, 평가, 판단)’ 하기 쉽다. 하지만 상대는 원하지 않을 수 있다. 코칭 상대의 상황에 따라 원하는 피드백이 다를 수 있다는 말이다. 그래서 일단 들어야 한다. 들으면서 깨달아야 한다. 상대가 어떤 피드백을 원하는지. 인정을 원하고 있을 수 있고, 평가나 조언을 원하고 있을 수 있다. 또한 내 경험으로는 듣는 과정에서 상대가 스스로 답을 깨달을 때가 많이 있었다. 코치가 모든 것을 다 해결해 줄 수 도 없으며 해줄 필요도 없다. 가장 좋은 것은 코칭 상대가 스스로 해결하는 것이다.

나는 가끔 코칭 상대에게 하고 있는 일이 재미 있는지 묻는다. 억지로 시키면 할 수는 있겠지만 지속하기 어렵고 자기 주도적이 될 수 없기 때문이다. 재미는 코칭 상대가 일방적으로 느끼는 것이 아니다. 코치가 만들어 줄 수 있는 부분이다. 나는 코드네임을 활용한다. 개발자가 만든 코드에 함께 애정이 담긴 이름을 붙혀 주는 것이다.

마지막으로 나도 잘 못하지만 잘 하려고 노력하는 것이 있다. 바로 유머이다. 연구에 따르면 유머는 즐거움, 흥겨움 같은 긍정 정서를 증가시키고, 걱정, 우울, 화 같은 부정 정서를 감소시킨다고 한다.

내가 참여 했던 어느 프로젝트에서 일이다. 프로젝트 리더는 하루 종일 심각한 표정으로 한숨을 쉬면서 일했다. 그 프로젝트 리더와 함께 일하는 사람들의 감정은 어땠을까? 사람은 서로 영향을 주고 받는다. 영향력을 많이 행사하는 사람일수록 이점을 놓치지 말아야 한다. 우리가 처한 현실을 바꾸기는 어렵지만 현실을 살아가는 것은 우리다. 어떻게 받아들이냐에 따라 처한 상황이 다르게 느껴지기도 하는 것이다. 그래서 나는 유머 감각은 떨어지지만 늘 웃으려 노력한다.