내맘대로 책읽기— 프로그래머의 길 멘토에게 묻다 / 데이브 후
사회생활 맛을 잠깐 봤던 사람으로서 계속 마음속에 품고 있던 난제가 하나 있었는데, 소프트웨어 회사의 인적관리는 어떻게 해야하는가에 대한 점이었다.
회사가 주는 것들을 뜯어보면 돈도 있지만 보통 직급이란 형태로 보상하는 자부심도 있고, 자신이 하고 싶은 일을 하게 해주는 터전이란 점도 있으며 여유있는 회사의 경우 MBA 등을 빙자하여 해외에서 마음껏 골프를 치게 해주는(!) 등 다양한 형태의 보상을 통해 직원들을 원하는 방향으로 유도한다.
그런데 소프트웨어 회사, 혹은 적어도 소프트웨어 기술이 회사의 주요한 자산인 회사라면 위에서 언급한 보상체계가 충분히 유효하지 않을 것 같다는 생각을 계속 가지고 있었다. 왜냐하면 업무의 특성상 인력의 질적 차이가 크고 업무에 쓰이는 도구나 기술이 자주 변하며, 가끔은 회사의 중요한 업무 자체까지 피벗이 일어나는 등 일반적인 회사와는 차이가 나는 부분이 많기 때문이다.
좀 더 나아가 생각하면 우리나라 소프트웨어 기업들이 쉽게 성공하지 못하는 이유가 제조업에 특화된 인재 관리 방법을 컴퓨터 공학 엔지니어들에게 무리하게 적용하기 때문이 아닌가 싶기도 하다는 생각도 든다.
어쨌든 그런 생각을 가지고 있던 나에게 이 책은 상당히 많은 생각거리를 안겨주었다. 이 책 자체는 소프트웨어 산업에 일자리를 얻은 초보자, 또는 견습생이 마스터의 위치에 올라서기 위해 어떤 패턴을 적용해야 할지를 다분히 공학적인(?) 접근으로 풀어가는 책이지만, 나는 이를 입장을 다소 바꿔서 회사 입장에서 어떻게 하면 초보자 또는 견습생 수준의 개발자들이 마스터의 수준으로 올라설 수 있는 시스템을 만들어 줄 수 있을 것인지에 대한 관점에서 읽었기 때문이다.
가장 인상깊었던 부분들을 중심으로 이야기하자면, 우선 멘토와 같은 개발자 커뮤니티의 유용함에 대한 부분을 들 수 있다. 언어는 단순히 문법만으로 이루어지는 것이 아니며, 책에서 말하는 것처럼 수많은 미묘한 부분들이 있는데 이런 것들은 대부분 선배들의 경험으로 부터 전달되는 것이다. The Craftsman라는 책에는 다음과 같은 글이 실려 있다. “안토니오 스트라디바리나 과르네리 델 제수와 같은 거장(바이올린 제조의 달인)들의 비밀은 사실 그들과 함께 죽은 것이다. 이 공방들의 특성 중 무엇인가가 그 지식이 전달되지 못하도록 막았음에 틀림없다.” “공방이 개인의 특출한 재능을 중심으로 돌아갔고, 스트라디바디가 자신의 천재성을 견습생들에게 전하지 못했기 때문에, 공방은 그와 함께 죽음을 맞이했다”
스트라디바디의 견습생 중에는 두 아들도 있었는데, 우리가 아는 한 그는 아들들에게 자신이 아는 모든 것을 가르쳤다. 하지만 그가 신경조차 쓰지 않았던 그 모든 암묵적인 지식의 조각들이 실제로 그가 가진 기술의 일부를 이루고 있었기에, 결과적으로 그는 전수에 실패하고 말았다.
소프트웨어 기술도 이와 비슷한 부분이 많다. 나 역시 독학으로 공부를 해왔지만, 들인 시간에 비해 얻는 것은 매우 적다는 것을 실감하고 있다. 소프트웨어 기술의 발전은 기존의 비효율을 제거하거나 전혀 새로운 접근방법이 나타나는 식으로 발전해왔는데, 이러한 역사를 이해하고 어떠한 접근법이나 방법론이 어떠한 이유에서 나온 것인지 이해하는 것이 매우 중요하다. 이유를 모르면 결국 같은 실수를 반복할 수 밖에 없다.
우리는 라이브러리나 튜토리얼을 한웅큼 고른 다음에 거기에 내재된 이슈를 이해하지도 않은채 프로젝트에 그냥 써버린다. 새로운 기술 분야에 뛰어들어서 아주 빨리 해결책을 찾아내는 데는 아주 유용한 능력이지만, 결국 자기 자신의 코드를 유지보수하면서도 계속 난관에 봉착할 것이며, 복잡한 이슈를 단순화한 결과 미묘한 버그가 계속 발생하거나 깊은 지식이 필요한 일을 할 때 어쩔 줄 몰라 허둥대는 일을 겪을 것이다.
그런데 과연 이러한 커뮤니티 문화를 회사 내에 만들 수 있을까? 혹은 만들 수 있다 할지라도, 과연 그것이 바람직한 문화로 정착될 수 있을까? 나는 개인적으로 생각하기에 이것의 열쇠가 되는 것은 마스터의 암묵적인 지식을 명시적인 형태로 독촉해내는 견습생의 문화를 만드는 것에 있다고 생각한다. 위에서가 아니라 아래에서 자꾸만 더 자세히 알려달라고 보채는 것이 이상하지도, 나빠보이지도 않는 문화를 사내에 만들 수 있어야 해결될 수 있을 것이다. (말로 하는 것보다 실제로 만들기는 어려운 문제긴 하다)
또한 피드백 루프를 만들어 지속적인 발전의 토대를 구축하고, 실패하는 법을 배워 그 토대를 튼튼하게 만드는 것의 중요성에 대해서도 책은 언급하고 있다. 유용한 피드백이란 그것을 기반으로 삼아 실천할 수 있는 데이터이며, 특정한 행위를 더 하거나 덜 하도록 선택의 여지를 주는 데이터이다. 단순히 선배가 하는 충고라는 형태로 나타나는 소위 '스톱에너지' 같은 것은 유용한 피드백이 아니다.
성공적인 시스템이라면 피드백 데이터가 신속하고 자주 얻을 수 있는 구조가 되어야 한다. 따라서 코드를 리뷰하고 피드백을 줄 사람을 갖추어주는 것이 회사 시스템의 중요한 부분이 될 것이다. 이는 마스터면 좋겠지만, 꼭 그렇지 않더라도 피어 리뷰와 같은 형태로 서로 코드를 읽고 리뷰하며 질문할 수 있는 문화가 갖추어진다면 가능할 것이라고 생각이 든다.
일전에 누가 코드리뷰를 빨가벗겨서 대중 앞에 나 자신을 내놓는 것과 비슷한 느낌이라고 표현한 적이 있다. 아마 누구나 비슷하게 느낄 것이라 생각이 든다. 그런데 반대편에서 이 문제를 짚어볼 필요도 있는 것이, 코드를 읽히는 사람 외에 코드를 읽는 사람에게도 이는 유익한 행동이라는 것이다.
학교에서는 프로그래머들이 실무에서 코드 작성보다 코드 읽는데 훨씬 더 많은 시간을 소비한다는 사실을 간과하는 경향이 있다. 코드를 잘 짜는 것만을 좋은 점수로 평가하여 보상하는 것은 학교라는 시스템에서는 일리있는 방식 일 수도 있지만, 실제 사회에서 개발자의 일과 시간 대부분을 차지하게 될 이런 코드 읽기를 더 잘할 수 있도록 훈련시키는 것은 장기적으로 더 큰 보상을 가져오는 효과적인 일일 것이다.
마지막으로 독서목록 공개에 대한 것이다. 내가 언제 어떤 책을 읽었고, 앞으로 읽어야 할 책들을 우선순위에 따라 정렬한다. 결국 어떤 책들은 순위에서 너무 많이 밀려서 아마도 결코 읽지 않게 되겠지만, 이것은 좋은 일이다. 이 패턴은 잠재적인 지식의 홍수 속에서 우선 순위를 매기며 걸러내는 방법을 제시하는 것이 목적이기 때문이다.
그런데 이 패턴의 모순점은 어떤 책들을 어떤 순서로 읽을지 정하려면 해당 주제를 깊이 이해하고 있어야 한다는 것이다. 나는 이 문제를 이렇게 풀면 어떨까 싶다. 회사 전체적인 입장에서 보면, 각 구성원들이 읽은 책은 결국 그 회사의 문제를 해결하기 위해 노력한 흔적이다. 이 책들의 목록은 그 회사가 기술적인 문제를 해결하기 위해 걸어온 길의 역사이자, 각 문제를 어떻게 이해하고 풀어갔는지 또는 회피했는지 "이유"를 알려주는 역할을 한다.
이러한 중요한 자료를 목록으로 만들어 공유하고, 마찬가지로 현재 각 구성원들이 관심을 가지는 책의 목록을 만들어 공유하는 것은 회사 입장에서 매우 가치있는 자료가 될 것이다. 왜냐하면 앞서도 얘기했듯이 이는 회사가 걸어온 길과 앞으로 나아갈 방향을 알려주는 이정표가 될 것이고 뒤따라오는 사람들이 길을 잃지 않고 나아갈 수 있는 횃불이 될 것이기 때문이다.
정리하면서 덧붙이고 싶은 일화는 (마찬가지로 책에서 나온 내용이다) 외과 의사 이그나스 제멜바이스는 병원에서 출산한 산모들의 주요한 사망 원인이 ‘손을 깨끗이 씻지 않는 의사들의 탓’이라는 것을 발견했다. 손을 씻는 것만으로도 치사율을 20%에서 1%로 낮출수 있음에도 그는 이를 설득하지 못했고 오히려 동업자 전부를 적으로 돌리고 동료들은 단지 그를 무시하기 위해 일부러 손을 씻지 않을 뿐더러 그 자신은 일자리를 잃었고, 나중에 조세프 리스터가 같은 아이디어를 발견할 때까지 20년 동안 많은 사람들이 목숨을 잃었다.
마찬가지로 조직에서 이와 같은 일들이 무수히 일어남을 우리는 목격하고 있다. 조직의 목표와 리더의 목표와 조직원의 목표 혹은 이해관계가 늘 일치하지 않기 때문이다. 아니 일치하지 않는게 당연하고 아주 드물게 일치하는 와중에 이 모든 것을 해내야 하는 것이다.
스타트업 역시 초기에는 그렇지 않겠지만, 결국은 이러한 이해와 목표의 불일치를 겪을 수 밖에 없다. 그래서 이는 시스템을 마련하고 유지하는 것이 중요해지는 이유다.