[프로그래머의 길, 멘토에게 묻다] - 13

앞으로의 포스팅은 책에서 소개하는 패턴 언어 중 마음에 드는 구절을 소개하는 방식이 될 것이다.

 

배운 것을 공유하라

 

 

상황

당신은 얼마 동안 견습생이었다. 당신은 몇 가지 업무적인 지식을 알고 있으며 사람들은 당신을 지식의 소스로 여기기 시작한다.

문제

지금까지 당신은 장인으로서 자신의 발전에만 집중해왔다. 하지만 숙련공이 되려면 효과적으로 의사소통하며 다른 사람들이 속도를 내도록 이끄는 능력을 갖출 필요가 있다.

해결책

배운 것을 정기적으로 공유하는 습관을 견습과정 초기에 들여놓으라. 이것은 블로그를 운영하는 형태가 될 수도 있고, 마음 맞는 사람들끼리 점심 도시락 모임을 갖는 것이 될 수도 있다. 또 컨퍼런스에서 발표를 하거나 학습 중인 여러 가지 기술 분야와 기법에 대한 튜토리얼을 쓸 수도 있겠다. 당신은 마스터도, 숙련공도 아니기에 이런 일이 어려운 것이다. 더 경험 많은 누군가가 나서기를 기다리는 것이 옳을까? 얼마 안 되는 지식이라도 당신의 동료 견습생에게 설명해준다면 그들은 고마워할 것이다. 당신이 조금밖에 알고 있지 못하기에, 당신은 단순하며 사전 지식이 필요 없는 요점을 설명하게 된다. 그래서 더 좋은 설명이라 부를 수 있다. 튜토리얼을 직접 써봐도 좋을 것이다. 
혼자 힘으로 배우는 것, 이런 지식을 겸손하게 공유하는 것. 둘 다 가치있게 여기는 개인들이 모인 커뮤니티의 일원이 된다는 것은, 견습 과정이 가진 가장 강력한 측면이다. 커뮤니티의 일원이 된다는 것은, 견습 과정이 가진 가장 강력한 측면이다. 견습생 입장에서는 자신을 가이드해줄 누군가가 생기는 것이다. 그리고 누군가를 가르치는 과정은 가르치는 사람도 배울 수 있는 기회가 된다. 이 패턴은 배운 것을 기록하라 패턴과 연관된다. 배운 것을 기록해두었다면, 다른 이들과 그것을 나누기는 더 쉬울 것이다. 반면에 이 패턴에는 당신이 공유한 지식을 사람들이 항상 고맙게 여기지 않을 수 있다는 위험이 있다. 
또한 윤리를 고려해야한다. 기밀사항이거나 해를 끼치는 내용을 공유해서는 안된다. 또한 팀이나 고용주와의 관계를 훼손시킬 수 있는 공유는 좋지 않다. 가장 뒤떨어진 이가 돼라 패턴은 당신을 더 나은 학습의 기회로 이끌지만, 장인으로서 지닌 의무에 소홀해질 수 있는 위험성도 내포한다. 이럴 때는 공유했을 때 혜택을 입을 수 있는 사람을 고려하지 않고, 자기 학습만 가속화하는 경우이다.

우테코 과정 중에서 얻은 지식을 어떻게 공유하셨나요?

면접 때에 받은 질문이다. 당시의 답변은 지금 글을 쓰고 있는 블로그와 칵테일픽 프로젝트 팀의 기술 블로그 그리고 진행했던 세미나. 이들을 준비하기 위해 내가 획득한 지식을 정제하고 가다듬는 과정이 필요하다. 그 과정에서 남에게 설명하기 위해 고민하고 정리한다. 추가적인 학습으로 볼 수 있다. 내가 혼자 알고 있는 지식은 거기서 끝이다. 하지만 이렇게 공유를 위한 준비를 하고 공유를 하다 보면 지식은 깊어지고 넓어진다. 

 

피드백 루프를 만들어라

 

 

상황

당신이 스스로 "인식하지 못하는 무능력"으로 고통스러워하는 상태인지 말하기는 어려운데 이는 숙련되지 않은 사람일수록 대개 자신이 무능력한지 어떤지에 대해 신경조차 쓰지 않기 때문이다. 게다가 당신이 덜 숙련되었을수록 자신과 다른 사람의 역량을 평가하기에 서툴기 마련이다. 이런 경우 성공이나 실패는 대개 깜짝 놀랄 일이며, 당신이 어떤 피드백을 얻게 되듣지 간에 그 피드백은 스스로의 향상에 도움을 준다는 원래 목적과 달리 자기 평가에 대한 갑작스러운 충격으로 다가온다. 

문제

자기 평가는 오로지 자신이 지닌 능력에 비례하며, 늘 객관성이 부족할 것이다. 당신이 자기 능력에 대해 느끼는 감은, 같이 일하는 팀이란 존재에 의해 쉽사리 왜곡될 수 있다. 평균을 웃도는 팀에 속했을 경우, 예비 멤버 이상의 역할을 맡을 때는 마치 슈퍼스타가 된 듯이 느껴질 수도 있고, 다른 모든이가 당신보다 훨씬 유능해 보일 때는 당신의 자신감이 여지없이 무너질 수도 있다. 반대로 평균 이하의 팀에 속하면 당신은 자만하며 우쭐댈 수도 있다. 일하면서 성찰하라 패턴을 사용한다고 해도, 과거를 분석하는 데 도움을 받을 수 있을 뿐 현재에 대해서 알려주지는 않는다. 

해결책

당신의 수행 능력을 평가하는 데 어느 정도 객관성 있는 외부 데이터를 정기적으로 수집할 방안을 마련하라. 일찍, 자주, 효과적으로 피드백을 얻으려 애쓰면, 당신은 적어도 자신의 무능함을 자각할 가능성을 높일 수 있을 것이다. 피드백의 방식은 여러가지가 있다. 당신이 프로그램을 짜서 당신의 다른 프로그램을 이용하여 테스트하고 피드백할 수 있다. 또한 짝 프로그래밍을 하며 코드를 리뷰받아서 피드백을 얻을 수도 있을 것이다. 당신의 역량 자체보다 시험 치는 테크닉만 테스트하는 경우가 많기는 하지만 이 또한 능력이니까! 또한 다른 사람들에게 당신이 어떻게 해 나가고 있는지 직접 물어보는 것이다. 입사나 승진 건으로 직접 인터뷰했던 사람들에게 연락해서 그들이 당신을 어떻게 생각했는지 들어보라. 비록 좋은 결과를 얻지 못한 인터뷰더라도 무엇 때문에 당신이 거절되었는지 자세히 들으며 많은 것을 얻을 수 있다. 이런 피드백은 때로는 당신이 깨닫지 못하고 있던 인성의 측면을 드러낼 것이다. 
위에 기술한 방법들은 모두 당신이 raw한 자료를 처리하는 능력을 갖추지 않았다면 소용없는 일이다. 예를 들어 고용주가 연 단위 리뷰를 제공하는 경우, 당신이 거기에서 유용한 피드백을 얻으려면 필요한 것을 구별하는 능력이 있어야 한다. 비판 그 자체는 피드백으로 쓸모가 없다. 왜냐하면 당신에게 무엇을 기대하는지 아무것도 얘기해주지 않기 때문이다. 혹은 당신이 아닌 다른 사람의 이야기를 하는 경우 이는 위장된 충고일 가능성이 높다. 
유용한 피드백은 어떤 모습일까? 피드백을 기반삼아 실천할 수 있는 데이터이며, 특정한 행위를 더하거나 덜 하도록 선택의 여지를 주는 데이터다. 어떤 피드백을 받고서 무언가 구체적으로 할 수 있는 것이 없다면, 그것은 유용하지 않은 피드백이다. 주변 상황이 바뀌면 갑자기 아주 의미 있는 피드백이 될 수도 있지만 우선은 유용하지 않다. 또한 정적 강화와 부적 강화의 차이점을 잘 구분해야 한다. 그리고 이를 잘 결합해서 피드백을 주고받아야 한다. 성공적인 견습생들이라면, 어떤 행동을 더 할지 덜 할지 결정하기 위한 데이터를 신속하고도 자주 얻는 상황을 조성하는 법을 배운다.

나의 피드백 루프  

개발은 피드백이 확실한 분야라고 생각한다. 가장 작은 단위는 TDD의 테스트 통과에서 오는 피드백. 조금 더 크기를 키워보자면 하나의 이슈 티켓을 해결해서 머지가 될 경우에 오는 피드백. 조금 더 키워볼까? 하나의 스프린트? 여러 스프린트가 모인 프로젝트? 이 모든 과정에서 오는 피드백들이 내가 즐겁게 개발을 할 수 있는 원동력이다. 성취감에서 오는 내적 동기.
다른 피드백은 없을까? 코드 리뷰를 하며 동료들과 주고 받는 대화에서 받는 칭찬과 성장. 그리고 회고를 통한 감정적인 공유와 서로에 대한 신뢰감. 이 또한 가까운 곳에서 받는 피드백이다. 우테코를 진행하며 이 과정이 정말 잘 진행되었기에 무너지지 않고 10개월간의 과정을 잘 생활해올 수 있지 않았을까? 
마지막으로는 서비스를 사용하는 사람들로부터 오는 피드백이 있다. 칵테일픽 서비스가 칵린이들에게는 너무 필요한 사이트라는 한마디에 열심히 개발을 할 수 있게 되었고 앞으로도 유지해야 할 이유가 생겼다. 
이 외에도 더 많은 부분에서, 사람으로부터 피드백을 받았고 앞으로도 받을 것이다. 피드백 없이 삽질만 하다보면 전혀 다른 방향으로 구덩이를 파는 나를 확인할 수 있으리.