실용주의 프로그래머라는 책의 영문 제목은 “The Pragmatic Programmer” 입니다. Pr 로 시작하고 가운데 m이 있어서 처음에는 어원이 같은 줄 알고 프로그램적인 프로그래머? 라고 해석해버렸는데 아예 단어가 달랐네요!

실용주의. 실용주의! 실용주의라고 하니까 너무 딱딱해보이지 않나요? 영단어도 딱딱해보이긴 마찬가집니다. 프래그메틱. 개발자. 프로그래머. 용어가 왜이렇게 딱딱할까요. 조금 더 유했으면 좋겠습니다. 예를 들면 해바라기처럼. 제 직업은 해바라기입니다. 이렇게 하면 뭔가 귀여워보이잖아요. 해는 문제를 “해”결한다(solve)는 깊은 뜻이 있던 겁니다!

비슷한 어감을 줄 수 있도록 영어를 곰곰히 떠올려보건만 네이티브 스삐커는 아니라서 생각의 한계가 뚜렷하네요.

책을 집어든 이유

책을 집어든 이유는 굉장히 중요합니다. 책을 읽는 태도에 따라 무엇을 얻어가냐가 다르기 때문이죠. 별 생각 없이 책을 읽는다면 별 생각 없이 끝날 거예요. 물론 재미를 위해서… 그러니까 그냥 그 느낌이 좋아서 소설을 읽는 것처럼 어려운 기술 서적을 음미하는 분들도 있겠지만!

(말이 길어지고 있습니다…) 책을 집어든 이유가 중요한 두 번째 이유는 저와 비슷한 상황에 처해있는 특별한 독자분들과 함께하고 싶어서죠. 저와 모든 게 비슷하지만 이 책을 읽었는지의 여부만 다른 어떤 독자분에게는 제 이야기가 다가오지 않을까 싶어서 입니다.

하여튼하여튼, 제가 실용주의 프로그래머라는 책을 집어든 이유는 크게 두 가지가 있었습니다.

• 전설같은 제 팀장님이 옛날에 굉장히 감명 깊게 읽은 책이었다.
• 지금 뭔가 몰려있다. 뭔가 방향을 잡아줄 만한 지혜가 필요하다.

명성

제 팀장님은 제 기준에서는 개쩌는데, 그분이 감명깊게 본 책이라니 저도 관심이 가지 않을 수 없지요. 왜 옛날이냐 하면, 이 책은 사실 1999년에 초판이 나왔습니다. 2019년에 두번째 판이 나왔는데요. NEW 책이라 할 수 있을 정도로 시대의 흐름에 맞게 내용을 잘 정리했다고 하더라구요. 한국어 번역판은 2022년에 나왔습니다.

책이 굉장히 흥미롭지만, 그와 동시에 반감이 드는 책이기도 합니다.

대한민국의 모든 고3이 수능을 열심히 보고 거기서 1~2등급을 맞은 인재들이 좋은 학교에 간다는 흐름. 너무나도 저항하고 싶지 않습니까? 마치 숭어에 빙의된 것마냥 공교육을 때려친 지도 벌써 10년이 넘었네요.

그때 그런 것처럼, 모두가 이 책을 좋다좋다 하니까 오히려 그 “모두”에 포함되지 않으리라는 저항정신이 꿈틀꿈틀꿈틀 거렸습니다.

흠…

이 책의 이름을 한참 옛날부터 듣긴 했습니다.

10년 전 처음 비트코인에 대한 소개를 봤을 땐 그저 호기심과 신기함만 아주 조금 있었습니다. 지금은 감히 넘볼 수 없는 성채가 되어버린 비트코인. 하지만 이 책에 담긴 지혜는 제겐 있어서 성채가 아닙니다. 책이란 건 시간만 조금 있다면 언제든지 넘겨볼 수가 있죠. 그 효용이 시대에 따라 좀 달라질 수는 있겠지만요. 2040년 쯤 한참 미래 입장에서 탁월한 투자였다! 라고 회고할 순 있겠지만 지금 바로 현재는 별볼일 없는 투자라는 느낌입니다.

아, 투자라고 했나요? 사실 투자가 아닌 거 같아요.

몰려있다.

투자란 여유가 있는 상태에서 이것저것 꼼꼼히 따지면서 한껏 전략을 부려보는 느낌인데요, 전 그것보단 좀 더 구석 모퉁이에 몰린 생쥐와 같은 마음입니다. 어떻게든 손에 뭐라고 집히는 걸 집고 거대한 고양이에게 힘껏 던지면서 저항해야 하는 입장인 거죠.

회사 이야기를 좀 할게요.

최근에 회사에서 진행했던 프로젝트는 여러가지로 인상깊었습니다. 과정에서 배움도, 얻은 통찰도 많았습니다. 예를 들어 중기 프로젝트를 진행하기 위해 가져야할 태도나 전략을 다시 한번 점검할 수 있게 되는 등.

그러나 부족했던 점도 많았습니다. 일정에 대한 책임이 제게 있었는데, 업무의 범위를 잘못 선정했습니다. 일을 바로 잡아가는 과정도 그다지 순탄치 않았습니다.

진짜로. 일정 짜기가 어렵디 어렵네요. 답이 없어요!! ㅎㅎ. 다음 일도 계속계속 있는데, 뭔가 일정을 산정할 자신감이 떨어졌습니다. 나름 일을 좀 해왔다고 생각했는데, 어째 점점 더 어려워지네요. 뭐가 어디서부터 잘못된 건지 알아야 했습니다.

스스로 생각할 수 있는 범위에서는 뾰족한 대답이 나오지 않았습니다. 제 그릇을 좀 더 키워야 할 필요성을 느꼈습니다. 무엇을 할까요? 그릇을 넓힌다고 했을 때, 뭘 해야 할까요? 어떻게 넓힐 수 있을까요? 기술적인 역량? 더더욱 코딩 고수 되기? 브라우저를 손수 구현할 수 있을 만큼 프론트에 있어서 굉장한 역량 가지기?

그보다 더 중요한 게 있는 것 같았습니다. 기술적인 역량이 아무리 뛰어나다 하더라도 그게 곧 일정을 잘 짠다는 의미는 아니겠지요. 뭔가 다른 지혜가 필요했습니다.

어떤 전략이 있을까? 전략에 있어서 흠집이 없다면 내 태도가 문제일까? (예를 들면 너무 욕심이 크다든지…) 개발자로서 성장에 관해 확신이 잘 서지 않고, 지금 뭔가 잘 하고 있는 건 아닌 것 같은데, 그렇다고 지금 당장 뭘 해야 할지 모르겠는 상태. 상당히 불편합니다. 일도 손에 잘 잡히지 않습니다. 이 책이 고양이에게 저항할 수 있는 구원의 연장이 되길 기대하면서 첫장을 넘기기 시작했습니다.

결론부터 이야기하면 그 기대는… 딱 기대만큼 만족합니다.

좋아요~ 실용주의~ 프로그래머~

실용주의 프로그래머를 다 읽고 나서 가장 먼저 들었던 생각. 딱 2년차 개발자가 보기에 좋다고 생각했습니다. 뭔가 일을 직접 경험해봤고, 잘 하는 상사나 동료로부터 자극도 피드백도 많이 받고, 해야할 것들이 산더미 같을 때. 스트레스가 최고조일 때! 급할 수록 돌아가라고 하잖아요. 자신에게 부족한 지점이 굉장히 많다고 막연히 느껴질 때, 이 책을 읽으면 좋을 것 같습니다. 무엇이 어떻게 잘못되었는지, 그리고 어떻게 하면 되는지를 담담하게 알려줍니다.

세세한 코딩과 한 발짝 떨어져 있는 이야기들이 많습니다. 직교성을 지켜야 한다든지, 프로토타이핑을 언제 해야 하고 무엇을 기대할 수 있는지 등등. 세세한 코딩에 관한 이야기도 있습니다. 상속하지 말라든지 단정문(assert)을 쓰라든지…

DRY(Don’t Repeat Yourself) 원칙같은 경우는 세세한 코딩과 커다란 설계 둘 다 해당됩니다.

전략적인 내용 중에서 가장 기억에 남는 건 항목 12, “예광탄(Tracer Bullets)” 입니다. 예광탄이란 실제 조건 하에서 즉각적인 피드백을 받기 위한 전략으로, 요구 사항으로부터 최종 시스템의 일부분까지 빨리, 눈에 보이게 도달해 줄 무언가 입니다. 여기서 이야기하는 피드백이란, 익숙하지 않은 기술, 언어, 개발 방법론, 라이브러리, 전략이 실제로 사용할 만한가에 대한 피드백이죠.

구체적으로는 다음과 같은 장점을 가지고 있다고 소개하고 있습니다.

• 사용자(의뢰인)가 먼가 작동하는 것을 일찍부터 보게 된다.
• 개발자가 들어가서 일할 수 있는 구조를 만든다. (뭔가 이미 구체화되어 있기 때문에)
• 통합(배포) 작업을 수행할 기반이 생긴다. → 디버깅과 테스트 용이
• 진행 상황에 대해 더 정확하게 감을 잡을 수 있다.

네. 제가 왜 이게 제일 기억에 남았는지 아시겠죠? 그렇게 파악하기 힘들었던 진행 상황을 그나마 더 쉽게 파악할 수 있게끔 해주는 방법이란 말입니다!

이 책에서는 매니징이나 리딩과 관련된 이야기가 많진 않습니다. 개발자로서, 문제해결사(해바라기)로서 어떻게 잘 문제를 해결할 것인가가 핵심입니다. 해결사로서, 커뮤니케이션이 중요하다는 이야기도 자주 나옵니다.

이 항목 말고도 다른 항목들도 모두 생산성을 높일 수 있는 전략이다보니 눈에 잘 들어왔습니다. 개발 일정을 당기려면 생산성이 우수해야 하니까요. DRY 원칙에서 코드 뿐만 아니라 문서나 데이터나 등등 A를 바꿔야 한다면 B도 바꿔야 하는 모든 상황을 줄이라는 것도 좀 인상 깊었습니다. 같은 일을 두번 할 필요 없죠.

예전에 했던 일의 근거를 이 책에서 찾기

하나. GraphQL codegen

예전에 이걸 도입하고 지금도 잘 쓰고 있는데, 그 근거인 DRY 원칙을 발견하여 기분이 좀 좋았습니다. GraphQL codegen 은 타입스크립트에서 유용합니다. 쿼리나 스키마 만들고 타입을 또 만드는 과정이 너무 반복적이니까요.

음…!

그런데 한편으로 이 codegen 하는 게 또 하나의 뤼핏이 될 수도 있겠다는 생각이 조금 들면서… 또 고민에 빠집니다.

하나. 매일매일 문서.

저희 팀에서, 직전 KPT 회고에서 나왔던 문제가 “예전 결정 사항의 기억이 잘 안난다”였습니다. 그래서 나온 해결책이 “매일매일”이라는 prefix 가 달린 문서를 만들고 그때그때 했던 이야기나 사소한 결정사항 등등을 기록으로 남기자고 했었는데요! 뭐, 완전 똑같지는 않지만, Topic 22. “엔지니어링 일지”가 거의 그런 내용이었습니다! 기록으로 많이많이 남기기.

그래서 신기했다구요.

좋아요 2 - DBC

또 하나 실천해봐야 할 전략이 있습니다. 그건 바로 Topic 23. 계약에 의한 설계 입니다. 줄여서 DBC(Design By Contract) 라고도 하죠. 세 가지 규칙이 있습니다.

• 선행 조건 제시 - 인자 값이 유효 범위를 벗어나면 예외 발생
• 후행 조건 제시 - 결과 값이 유효 범위를 벗어나면 예외 발생
• 상태 유효 보증 - 작업 이후 내부 상태가 좀 이상하면 예외 발생

무엇을 예로 들어볼까요… 예를 들어 팝업을 띄운다…!

PopupSystem.mount(”ABC”)

• 뭔가 mount 가능한 id 중에 하나여야 합니다. 아니면 예외!
• mount 이후 팝업 Iframe 으로부터 신호가 와야 합니다. 일정 시간 지나면 예외!
• mount 된 팝업 리스트에 ABC 가 있어야겠죠. 없다면 예외!

흠… 이렇게 써놓고 보니 실제로 유효할 지는 잘 모르겠긴 하네요.

다른 개발 방법론과 대치되는 면을 살펴보면 DBC 를 더 이해하기 좋다고 생각합니다.

• 테스트 코드는 테스트할 때만 사용되지만 DBC 는 설계, 개발, 배포, 유지 보수 전체에 걸쳐 사용된다.
• 방어적 프로그래밍은 입출력이 자유분방하여 모든 사람이 데이터를 검증하는 반면, DBC 는 그보다 더 효율적이고 DRY 하다.

결론

결론은 항상 빈약합니다. 하여튼 이 책으로부터 좋은 인사이트를 많이 얻었다고 생각합니다.

모든 항목에 고개를 끄덕끄덕하긴 하지만, 와닿지 않은 부분들도 좀 있었습니다. 그래서 여러 번 읽어야 좀 더 빛이 나는 책일 거 같다는 생각도 들었어요. 여러번 읽어봅시다.