아마도 우리가 배워야 할 것은 그들이 전문가에 도달하기 위해 밟았던 과정일지도 모른다. 우리의 목표는 몇몇 특정 시점에서 전문가를 흉내내는 것이 아니고 스스로 전문가가 되는 것이기 때문에. --김창준, 노스모크:LearnHowTheyBecameMasters

소프트웨어 개발에서는 형상관리라고 해서, 쉽게 말하면 소스코드가 딱 한 줄이었던 시점부터 몇 십만 라인으로 늘어날 때까지 그 이력을 저장하는 문화가 있습니다.

이런 형상관리를 위한 도구들이 많이 발전되어서, 언제 누가 어떤 부분을 어떻게 바꿨는지 간단하게 시각적으로 비교해볼 수 있습니다. 덕분에 우리는 소프트웨어의 성장 과정을 구체적으로 보고 배울 수 있습니다. 내가 추종하는 유명한 프로그래머가 있다면 그 사람의 발자취를 그대로 따라가 볼 수 있다는 것입니다.

하지만 안타깝게도, 과정으로서의 소프트웨어 개발을 가르치는 곳이 거의 전무합니다. 어떤 순서와 과정을 거치면서 소프트웨어가 성장하고 수정되어 나가야 하는지에 대해 배울 기회가 없습니다. 위대한 소프트웨어의 성장 과정에 대한 역사를 배우는 것은 말할 것도 없지요. 예컨대 그래디 부치(Grady Booch) 같은 사람은 건축학과의 경우 뛰어난 건축물을 직접 가서 보고, 그 건축의 역사를 공부하고, 설계도를 구경할 수도 있지만 소프트웨어 분야에서는 그런 일이 이뤄지지 않고 있으며, 이것이 소프트웨어 산업의 발전에 큰 장애가 된다고 주장했습니다. 랄프 존슨(Ralph Johnson)은 위대한 소프트웨어를 읽고 공부하는 수업을 진행한 바도 있고요.

"작가를 위한 git 워크숍"이란 행사가 있었나 봅니다. IT에 대한 배경지식이 없는 분들이 git이라고 하는 형상관리 소프트웨어의 사용법을 배우는 워크숍이었습니다(이것은 공동저작의 함의를 갖습니다). 그 소식을 보면서 이런 생각을 잠깐 했습니다. 내가 존경하는 작가의 최종 산출물만 보는 것이 아니라 그 사람이 짚어간 징검다리 돌 하나씩을 따라갈 수 있다면 이것은 놀라운 학습적 경험이 될 것이라고요.

경영학에서 피드백의 효과에 대한 연구가 많이 있습니다. 흥미로운 부분은 피드백의 종류에 따른 효과 차이인데요, 통상 피드백을 결과 피드백과 과정 피드백으로 나눕니다. 결과 피드백은 "어 잘했네!" 같이 그 결과가 좋다 나쁘다에 대한 피드백이고요, 과정 피드백은 진행 과정에 대해 피드백을 해주는 겁니다. 여러 연구를 통해 확인된 것은 과정 피드백을 많이 주는 팀장의 팀이 성과가 더 높다는 점이었습니다. 그만큼 학습이 많이 일어난다는 것이겠지요. 그렇다면 커리어에 있어 나에겐 어떤 상사가 좋을까 하는 질문에도 답이 나옵니다. 여러분의 상사는 일을 시키고 나서 내가 진행하는 과정에 대해 피드백을 얼마나 주나요?

노벨 물리학상을 받은 머리 겔만(Murray Gell-Mann)의 젊은 시절 일화로 이 이야기를 마칠까 합니다. 머리 겔만과 같은 수업(아마 물리학이나 수학이었을 것)을 듣던 친구가 몇 주 동안 문제 하나로 고민을 하다가 마침내는 겔만의 기숙사방을 두드렸습니다. 도무지 이 문제를 풀지 못하겠다고요. 문간에 서서 겔만에게 해당 문제를 보여주자 어린 겔만은 문제를 잠시 노려보더니 숫자 하나만을 외치고(예컨대 "-1!"처럼) 문을 닫고 들어가 버렸습니다. 겔만은 그자리에서 암산으로 답을 구해서 그걸 말했던 것입니다. 이 친구는 겔만의 이런 모습을 보고는 바로 자퇴를 결정하고 훗날 영화감독이 되었습니다. 다른 학생들도 이런 겔만의 수준일 거라고 상상한 것이죠.

--김창준