프로그래머를 위한 동의보감

The Pragmatic Programmer: From Journeyman To Master

저자들이 우리에게 일깨워주고자 하는 것은 ‘균형 감각’이다. 이 책의 저자들은 자신들의 풍부한 실무 경험을 바탕으로, 실용주의 엔지니어의 가장 중요한 자격은 ‘폭넓은 사고와 굳건한 이론을 바탕으로하는 균형 잡힌 경험’이라는 사실을 가슴에 와닿게 일깨워주고자 했을 따름이다.⊕ 길게도 썼다. 오만 방자한 표현과 어설픈 감상이 뒤범벅되어 수습하기 어려울 정도로 손발이 오그라드는 글이다. 당시에 나는, 어지간히 겉멋을 부리고 싶었던 모양이다.(2026년 1월) ⊕ 모(?) 잡지에 기고했던 글을 동명정보기술원 홈피에 올렸을 때 제목 이미지

병든 엔지니어와 동의보감 #

“올해는 전혀 다르게 말씀하시는군요. 저번 특강에서는 설계가 그렇게 중요하다고 강조하시더니, 이번에는 일단 돌아가게 만드는 것이 더 중요하다고 하시네요? 그새 생각이 바뀌신 건가요?”

강의가 끝난 후에 한 학생이 다가오더니 배시시 웃으며 이리 묻는다.

‘일단 돌아가게 만들어 보는 것보다 더 확실한 문제 분석 방법이 있었던가요? 아무리 타고난 사람이라고 해도 어찌 한 번도 해보지 않은 작업을 설계부터 착착 해낼 수 있을까요? 그러니 오늘 제가 그리 얘기한 것은 설계를 하지 말라는 말이 아니겠죠. 뭘 만드는지도 모르고 설계부터 한다고 끙끙대는 순진한 학생들을 하도 많이 봐와서 설계란 것이 그렇게 뜬구름 잡는 일이 아니니, 일단 엉성한 시제품이라도 만들어 보면 우선 풀어야 할 문제가 어떤 괴물인지 절로 알게 될 거라는 말이지요. 물론, 그렇게 만들어 놓고 “개발 끝났다!“고 손 털면 어리석은 사람이지요. 진짜 설계니 구현이니 하는 것은 그런 다음에 이어지는 작업이니까요.’

이렇게 답했더라면 좋았을 터인데, 정작 입에서는 비꼬는 듯 성의 없는 대답이 튀어나왔다.

“글쎄요. 그 때는 디자인 패턴을 논하는 세미나였고, 지금은 기술의 실용성을 논하는 자리니까요.”

스스로 생각해도 뭔 소리인지 모를 대답이 나오자 수습이 되지 않았다. 속마음이야 어떠했든 이런 대답은 한 쪽에서 고의로 대화를 끊어버린 셈이다.

왜 그랬을까. 그 어설픈 대답을 심하게 오해하자면, 설계 이론을 논할 때는 설계가 가장 중요하다고 우기다가 정작 실무를 논하게 되니 설계 따위는 집어치고 돌아가게나 만들라고 소리치는 것이 아니던가. 어처구니없다. 모르긴 해도 그 학생이 듣고자 하던 답변은 아니었을 것이다. 아마도 뭐 이리 줏대 없는 사람이 있나 어리둥절했을 것이다. 십중팔구는 그랬으리라. 사실 그 학생은 속사정을 짐작도 못했을 것이다. 그러나, 조금만 더 살펴보았더라도, 그런 대답을 내뱉을 때 말하는 자의 허망한 표정을 금새 읽었을 것이고, 언제나 같은 마음으로 누군가를 끝없이 설득하다 지쳐버린 사람의 마음을 알아차렸을지 모른다.

나름의 신념을 가지고 살아가다 보면 때로 세상의 편견에 지치고 현실의 장벽에 부딪혀 진저리 쳐질 때가 있다. 매번 이 편과 저 편을 갈라서 서로가 애초에 다르다고 우겨대는 사람들, 상대편 얘기는 한마디도 듣지 않겠노라 눈 딱 감고 버티는 사람들을 자주 만나게 되면, 이들과 뒤엉켜 답 없는 싸움을 벌이는 것이 허망하다는 생각이 절로 든다. 그렇다면 이런 일에 말려들어 정력을 낭비하지 않고, 그저 제 할 일이나 온전히 다듬는 게 낫지 않을까? 신념은 때로 감옥이 되어 스스로를 가두어 버릴 때가 있고, 열정도 화가 되면 스스로를 지치게 만드는 법이다. 꿈쩍도 않는 세상에 대고 소리를 질러봤자 매번 자신만 손해보고 있다는 느낌을 지울 수 없으니 아예 마음과 입을 닫아버리게 된다.

(필자 자신을 포함해서) 이런 식으로 마음에 병이 든 엔지니어들이 의외로 많다. 막상 세상에 대고 할 말이 그리도 많았던 동료들인데, 진지한 주제로 얼굴을 마주하면 낯선 사람처럼 서먹하다. (이들이 바로 예전의 그들이었던가?)

필자는 이런 경우를 접할 때마다 ‘무엇이 이런 병에 특효약일까? 병든 엔지니어의 마음을 씻은 듯이 고쳐주는 그런 기술(?) 서적은 없을까?‘하는 생각이 들었다. 그런 바램은 헛되지 않았다. 오랜 기다림 끝에 그런 책을, 적어도 한 권 찾아냈기 때문이다. (이번에 필자는 기꺼이 약장수가 되련다.) 『The Pragmatic Programmer: from Journeyman to Master』(이하,TPP)는 고치기 어려운 병에 걸린 엔지니어들에게, 둘도 없는 명약이다. ⊕

엔지니어의 신념을 되찾아주는 특효약 #

이 책을 처음 본 것이 재작년이었지 싶다. 그러나 정작 읽기 시작한 것은 작년 초부터이니 한 동안은 그 가치를 모르고 책장 속에 고이 모셔둔 셈이다. 본래는 같이 일하는 연구원들과 함께 읽을 셈으로 구한 연구 자료였는데, 다들 반응이 시큰둥해서 이런 책이 있었는지조차 잠시 잊고 지냈다.

어쩌다가 책장 속에 버려둔 이 책을 다시 꺼내 볼 마음이 생겼는지는 기억나지 않는다. 다만 이 책을 처음 펼쳐 서문을 읽어내려 갈 때 받았던 첫 느낌만은 확실하게 기억한다. 오래 동안 까맣게 잊고 지냈던 동지를 만난 듯 반가워서, 그날 늦게까지 사무실에 죽치고 앉아 숨죽여 이 책을 훑어 내렸다. 자신이 그 동안 귀하게 간직했던 신념이 시대가 바뀌어도 빛이 바래지 않았다는 걸 알게 됐을 때 그보다 더 기쁜 일은 찾기 어렵다. (이 책은 마치 필자의 마음을 고스란히 담아놓은 일기장 같았다.)

알찬 경험을 통해 실용주의에 바탕을 두고 프로그래밍의 기본 원리를 상기시키는 책 - 이 책은 고전이다. 여기에 올라온 서평을 훑어보고, 이 책을 샀다. 나는 20년이 넘는 세월 동안 여러 가지 언어로, 다양한 운영체제에서 프로그램을 개발했다. (중략) 나에게 프로그래밍은 언제나 크래프트(craft)이 단어를 기술이라고 번역해 버리면 곤란하다. 우리말의 ‘기술’과는 전혀 다른 뜻이다. 필자 생각에는 가장 비슷한 단어가 ‘공예’인데, 이 분야 서적에서 잘 쓰지 않는 단어라서 일부러 영어 발음을 그대로 우리말로 옮겼다. 였다. 그래서 언제나 간단한 용어만으로, 깔끔하게 크래프트를 설명할 수 있는 사람을 (인정하고) 좋아했다. 왜냐하면 각자가 하는 일에 자긍심을 불러 일으켜서, 모두 제 일에 최선을 다하게 만들기 때문이다. 이 책을 읽어 동안 몇 번이나, “그래, 이게 제대로지, 당연히 이래야 옳지 - 정말 속 시원하게 설명하는구나!” 하고 생각했다. 이 책이 강조하는 바는, 프로그래밍 분야에서 경력을 쌓은 사람이라면 당연히 알고 있어야 할 만한 내용이다 (역자주: 나중에도 다시 얘기하겠지만 이 책의 내용은 전혀 새로울 게 없다). 그러나 다른 분야의 사람도 그 내용을 이해하여 응용할 수 있을 만큼 쉽고도 시원스럽게 설명한다. (중략) 이 책은 알찬 경험을 바탕으로 프로그래밍 크래프트를 개선하는 방법에 대해 실용주의적 관점에서 반드시 필요한 것이 무엇인가를 되새기게 만든다.

이 책을 펴는 순간 독자들도 틀림없이 Mitchell과 같은 말을 하게 될 것이다. (필자처럼) 번잡한 기술의 세계에 지쳐 한동안 숨어(?) 지냈다면 더욱 크게 공감할 수밖에 없다. 갈고 닦은 재주가 점점 곰팡내 나는 듯 지겨워지고, 해마다 산처럼 쌓여가는 새로운 기술이 이미 내 손아귀를 떠난 듯 하여, 하루가 멀다 하고 바뀌어 가는 응용을 따라잡다 병들 지경에 이르렀다면, 이만한 특효약이 없다.

새로운 종류의 기술 서적이라 하면, 지레 숨이 턱 막히고 설명할 수 없는 짜증부터 차오르는 독자라도 이 번만큼은 잠시 걱정을 백업해 두자. 혹시 무슨 새 기술이 또 튀어 나와서 여태 고민하던 문제를 말끔히 해결해 줄 것이라 호언장담하거나, 이제 시대가 바뀌었으니 이런 저런 개발 기법을 따라잡지 못하면 뒤쳐질 것이라고 겁주는 책이 아니기 때문이다. 그런 책은 지금도 이미 차고 넘쳐서 지나치다 싶을 정도인데, 필자가 쓰레기 더미를 더 늘리자고 부추기는 글을 쓸 이유가 어디 있을까.

여기서 이 책 서문의 한 구절을 맛보기로 하자. 이 책이 어떤 - 즉, 무엇을 목적으로 하는 책인지 쉽게 알 수 있을 것이며, 그런 의심은 말끔히 사라질 것이다.

이 글은 필자가 본지의 다른 기사에서도 한 번 인용한 적이 있다. 감상이 어떠한가? 필자의 생각으론 엔지니어로서 우리가 원하는 답은 저 짧은 글에 모두 담겨있다. 그간 앞서가는 기술을 먼저 익히기 위해 숱하게 지새웠던 날들과 결린 어깨를 들썩여가며 ‘벌레잡이’로 충혈된 눈을 비벼댔던 이유가 바로 이 때문이 아니었던가. 더 나은 프로그래머가 되려고!

그런데 언제부턴가 그런 자신이 더 이상 멋져 보이지 않게 됐다. 비슷한 일거리가 반복되면서, 점차 도구의 노예가 되어 가고, 툴을 만지는 익숙한 손놀림이 마치 기계와 같다. 눈동자는 빛을 잃고 그저 모니터를 비추는 거울이 됐다. 이제는 눈앞에 닥친 일을 재빨리 처리하는 데만 관심이 있다. 급기야 바로 옆자리의 동료가 오랜만에 그럴싸한 아이디어를 내놓아도 예전과 달리 별로 가슴이 울리지 않는다. 이제 더 나은 개발자가 되고자 애썼던 젊은 가슴은 온데 간데없다. 어느새 화석같이 굳어버린 기술자가 되어 버린 것인가?

이럴 때 TPP는 고고학자와도 같다. 묻혀 있던 화석을 찾아내어 그 잊혀진 가치를 상기시킨다. Milne 씨의 고백을 들어보자. TPP가 어떤 책인지 충분히 짐작하고도 남을 만한 서평이다.

늙은 개와 새로운 재주 #

실의에 잠겨있던 시절에 이 책을 알게 됐다. 12년이 넘도록 소프트웨어 분야에서 일하다 보니 언제부턴가 나 자신이 ‘요즘’ 코딩 기법에 대해 전혀 아는 것이 없는 화석 같은 존재처럼 느껴졌다. 그런 나에게 이 책은 자신감을 되찾아 주었다. 나는 여전히 잘 알고 있었다. 내가 무엇을 얘기해 왔으며 그 동안의 경험이 오늘날의 소프트웨어 환경과도 관련이 있다는 사실을. 저자들에게 어떻게 감사해야 좋을지 모르겠다.

이 책에서 가장 마음에 드는 부분은 실세계를 바탕으로 하고 있다는 점이다. 그저 그렇게 되어야 옳다는 이유만으로 뜬구름 잡는 공상을 써내려 간 것이 아니라 저자 스스로가 경험으로부터 그 가치를 깨닫게 된 것만을 다루고 있다. 이 책에 많은 부분 - 특히 나 자신이 취약한 분야에서 크게 공감하지 않을 수 없었다.

여러 가지로 이 책은 내 오랜 신념(예를 들어 커맨드라인도 개발자에게 여전히 쓸모 있는 것이라는 사실)에 확신을 더해 주었다. 그러나 문서화나 메타프로그래밍에 대해 더 많은 생각을 하도록 부추기는 역할도 했다. 예전에도 그런 논제를 가끔씩 생각해 보기는 했지만 Andy와 Dave는 그런 기법을 내가 하는 일에도 적용할 수 있으며, 전반적으로 주어진 업무량을 줄일 수 있다는 점을 깨우쳐 주었다. 당시에는 맡은 작업을 즉각 마무리는 것이 무엇보다 중요하게 보였기 때문에 언제나 메타프로그래밍과 같은 기법을 피했다.

이 책을 어떻게 더 칭찬해야 좋을까. 이 책은 Steve McConnell의 『Code Complete』과 다른 방식으로 소프트웨어 작업의 실용성을 논한다. 내 생각에는 수다스런 문체에 차이점이 있다고 생각한다. 『Code Complete』은 여러 면에서 탄복할 역작이지만, 『The Pragmatic Programmer』에 비하면 훨씬 무뚝뚝하다. 그래서 엔지니어라면 두 권의 책을 모두 읽어보라 권하고 싶다. 『Code Complete』은 결점을 찾기 어려울 만치 기본적인 논제(C 코드에서 괄호 위치에 대한 얘기를 제외하면)를 다루는 반면, TPP는 무엇을 하고 무엇을 하지 말아야 하는지, 좀 더 폭넓은 환경에서 업무의 실용성에 뿌리를 두고 얘기를 풀어간다.

진심으로 TPP를 누구에게나 권하고 싶다. 특히, 수년간 소프트웨어 개발에 몸담아 왔던 이 들에게 이 책을 권한다.

(Milne 씨처럼) 좋은 엔지니어가 되고자 했던 처음의 신념이 희미해질 수도 있는 법이다(그러나 걱정할 일은 아니다). 세월은 누구나 지치게 만든다. 특히 이 분야에서는 몇 달만 쉬어도 격세지감을 느낄 수 있다. 그러나 풀죽어 있을 여유가 있다면 차라리 TPP라도 읽어 보는 것이 낫다. 오히려 이런 책을 통해 자신의 약점을 정확하게 발견하게 될지도 모른다. 자신이 지치게 된 진짜 이유가 알고 보니 이 분야의 유별난 특성 때문이 아니라 그저 매일 매일 해오던 작업 방식이나 사고방식의 결함에서 비롯된 것일 수도 있지 않겠는가. 자신감이란 없던 것을 가져와 새롭게 만들어내는 것이 아니라, 있던 것을 찾아 새롭게 발견하는 것이기 때문이다.

이 책의 서문 첫 문장에도 나와 있듯이 ‘이 책으로 여러분은 더 나은 프로그래머가 될 수 있을 것이다.’ 이 책을 읽어 볼 기회를 놓쳐버린다면, 사무실 여기 저기 쌓여가는 기술 서적이 점차 쓰레기로 변해갈 수도 있다. 잠시 숨을 돌리고 널브러져 있는 그 모든 책을 내려다 보자. 뒤쳐질 것 같은 위기감에 덜컥 구입했던 그 많은 책이 기술자로서의 자신에게 얼마나 평안을 가져다주었는가. 진정 그 책들의 두터움만큼 스스로의 기술과 경험도 같이 부풀어 올랐던가. 열심히 끌어다 모아둔 자료만큼 더 나은 엔지니어가 됐는가. 그리고 스스로의 일을 충분히 잘 해내고 있다고 확신하는가. 아니라면 이제라도 돌이켜 볼 때가 되지 않았을까. 아니, 하나 더 있다. 그 무엇보다 중요한 것, 여전히 프로그래밍이 조금이라도 즐거운가!?

이 책의 첫 장에서는 프로그래머로서 우리 ‘자신이 매일 매일 작업하는 방식을 다시 꼼꼼히 훑어보라.‘는 충고를 아끼지 않는다. 어떤 부분은 너무 당연하고 어떤 부분은 받아들이기에 너무 억지스럽다. 그러나 어느 한 가지도 현실을 벗어나서 말하기 좋으라고 지어낸 얘기가 없다.

프로그래밍에는 (그런 것이 있다손 치면) 법칙이랄 만한 것이 거의 없다. 그래서 보통 ‘그랬으면 싶은 법칙’에 맞추어 이런 저런 방법론을 그려낸다. 그렇게 하면 글쓰기에 좋을지는 몰라도 실제로 잘 적용되지는 않는다. 그 많은 방법론 서적에서 계속 잘못하고 있는 부분이 바로 그것이다.(중략)

이 책의 철학은 독자의 의식 속으로 서서히 스며들어 독자가 가진 것과 하나가 된다. 훈계하거나 설교하지 않는다. 그저 무엇이 잘 돌아가는지만 말해줄 뿐이다. 그러나 그렇게 해서 더 많은 목적을 이루어낸다. 이 책은 아름답다. 철학을 내포하고 있지만, 겉멋을 부리지 않기 때문에.

고전 아닌 고전 #

TPP는 출판된 지 채 3년이 못된 책이니 나이로만 치자면 고전이라 할 수 없다. 그러나 내용만큼은 아주 케케묵은 고전이다. 사실 여러 방법론 책을 한 데 모아다 비교해 봐도 이 책만큼 새로운 용어나 이론을 소개하지 않는 책도 드물다. 이런 단점을 꼬집어 이 책의 가치를 부정하는 사람도 더러 있다(필자가 이 빳빳한 새 책을 ‘고전을 찾아서’란 기획에 버젓이 소개하는 이유가 이 때문이다. Milne 씨처럼 해묵은 기술자가 이 책 속에서 자신감을 되찾게 된 것도 비슷한 맥락이라 하겠다).

나는 서문을 읽은 후에 서문과 첫 장에 담긴 좋은 주제를 찾아볼 목적으로 이 책을 샀다. 사실 그 다음에 이어지는 모든 내용은 다른 입문 서적에서 쉽게 찾아볼 수 있는 것이었는데, 저자들은 마치 5분 전에 처음 그런 이치를 발견한 사람처럼 난리 법석을 띤다. 결국 이 책의 분위기는 지나치게 현학적이고, 다루는 내용은 새로울 게 전혀 없다.

사실이다. TPP에서 참신하고 혁신적인 내용이라고는 찾아볼 수가 없다. 그러나 이 책은 경험의 진실을 말하는 책이지, 결코 저명한 학자가 주창하는 이론을 엄밀하게 논하는 책이 아니다. 어떤 이론이 제 아무리 정교하고 신선하다고 해도 경험의 증거가 뒷받침되지 않으면 설득력이 없는 법이다. 만일 비슷한 내용을 어느 연구실의 젊은 학자가 썼다면 이토록 호응이 대단할 수 있었을까?

솔직히 말해 TPP에서 언급하는 프로그래밍 이론은 전문 연구기관의 초보 연구원 수준에도 미치지 못할 만큼 얄팍하다. 그러므로, 필자가 생각하기에, 이 책을 선택한 독자는 새로운 이론이나 기법을 배우고자 하는 것이 아니라 이미 귀에 못이 박히도록 들어온 교과서 속의 이론들이 실제로도 진정 살아 숨쉬고 있는지 확인하고 싶어서 기꺼이 시간을 투자하는 것이다.

굳이 TPP의 고루한 내용을 비판하고 들자면 맘에 들지 않는 부분이 한두 가지가 아니다. 특히, 3장은 곰팡내가 풀풀 날 정도다. 여기서는 난데없이 ‘텍스트’ 데이터와 유닉스 커맨드라인이 실제로 소프트웨어 개발 과정의 생산성을 보장하는 프로그래밍 도구라고 설명한다. 심지어 윈도우에서도 유닉스 호환 환경을 쓸 수 있도록 Cygwin과 같은 툴을 써보는 것이 어떠냐고 제안하기까지 한다. 그러나 셸을 가지고 놀아본 적도 없고 한 프로그램에서 필요한 모든 기능을 끌어다 쓸 수 있는 통합 개발 환경이 개발 경험의 전부인 독자들에게는 선뜻 받아들이기 어려운 내용일 가능성이 높다. 아니, 왜 만지기 쉬운 환경을 마다하고, 덜떨어져 보이는 인터프리터 환경을 다시 배워야 하는가? 저자들은 자신들이 유닉스 프로그래밍 환경에 익숙해져 있기 때문에 독자들도 그 유산을 이어받아야 한다고 고집을 부리는 것이 아닌가? 그렇다면 저자들이 말하는 실용주의란 그저 고루하고 편협한 경험을 되씹어 내보이는 넋두리에 불과한 것이 아닌가?

그런 오해가 아무래도 풀어지지 않는다면 잠시 책을 덮고 저자들의 본심이 무엇인지 골똘히 생각해 봐야 한다. 얼마나 다양한 환경에서 얼마나 많은 프로젝트를 수행했는지 따지자면, 아마 대부분의 독자들은 그 경험의 양과 질이 TPP 저자들에 미치지 못할 것이다. 현 시대의 프로그래밍 도구가 생산성을 향해 어떻게 진보해왔는지는 저자들이 더 잘 알고 있다(그들이 오히려 산 증인이다). 그리고 지금이 ‘셸과 텍스트’의 시대가 아니라는 것은 이 분야의 누구라도 모를 리 없는 사실인데, 프로그래밍의 실용주의를 논하는 이들이 시대를 역행하는 철학을 우겨댈 만큼 어리석을까? 저자들이 우리에게 일깨워주고자 하는 것은 ‘균형 감각’이다. 지금이 ‘GUI와 멀티미디어’의 시대이기 때문에 오해를 감수하고서라도 ‘셸과 텍스트’의 가치를 설명하고자 하는 것이다. ‘폭넓은 사고에서 비롯된 균형 잡힌 경험’이야말로 실용주의 엔지니어의 가장 중요한 자격이란 사실을 가슴에 와닿게 일깨워 주고자 했을 따름이다.

71번째 TIP #

이 책은 제목 그대로 프로그램을 만드는 모든 이에게 ‘행동하는 실용주의 철학’을 가르치려 한다. 편지를 한 통 보내는 습관에서부터, 끝없는 대화로 동료와 호흡을 맞추는 일까지, 흔히 소프트웨어 개발이라 하면 떠올리게 되는 그 모든 고통에 다양하고 적절한 치료제를 알려준다. 하지만 사전처럼 딱딱하고 메마른 이론서를 들여다보듯 이마를 찌푸리고 끙끙대며 읽을 필요는 없겠다. 이 책에는 재치 있는 유머와 통쾌한 글귀가 가득하다. 결코 쉽게 눈을 돌릴 수는 없을 것이다.

필자가 70번째 팁까지 한 번에 모조리 읽고 난 다음(사실은 여러 번 읽었다), 71번째 팁이 실수로 빠졌다는 것을 알게 됐다. 혹시 아직 스스로 찾지내지 못했다면 얼른 적어두라.

팁 71:

그 병에 걸렸다 싶으면, 얼른 약방에 가서 이 약을 사라. 날이면 날마다 볼 수 있는 그런 약이 아니다. :D ⊕ 글 말미에 붙였던 서명 이미지