소프트웨어 장인 (Feat 삶의 방정식)

Published in

Hibike! Quantum’s blog

6 min readJun 5, 2022

배경

이 책을 산건 2019년 6월이었다. 뜨거운 여름, 양산도서관에서 프로그래머가 되기 위해 프로그래머스에서 알고리즘 문제도 풀고 코드스테이츠의 Pre 코스를 밟던 시절이다. 알고리즘 말고도 좋은 프로그래머가 되기 위한 조건은 많을 것 같아 샀던 것 같다.

하지만 이 책을 사놓고도 24시간 알고리즘이나 문법에 대한 생각과 불안뿐이었기에 책을 읽을 수가 없었다. 그래도 실제로 일을 시작한 다음이라도 읽었어야 했는데 그러지 못했다. 한 페이지 한 페이지에 통렬한 반성을 요구하는 이 책이 읽기가 두려웠던 걸까.

결국 책을 읽은 건 2022년 5월, 모든 내 불안이 해소되고 세상 밖으로 나아가도 되겠다고 마음을 편하게 먹은 뒤다. 심지어 이때 같이 산책들도 모두 최근에 다 읽었다 (미안해 제레미 다이아몬드) 읽고보니 옛날에 그 시절에 읽었으면 참 좋았을 텐데라는 생각이 들었다. 이렇게 보면 소프트웨어 장인이 되기 이전에 심리적으로 스스로를 잘 케어해줄 수 있는 사람이 되는 게 먼저인 건가? 😔

내용 요약

책의 내용은 광범위하다. 소프트웨어 장인정신의 정의, 애자일, 익스트림 프로그래밍, 페어 프로그래밍, TDD, 휴식 방법(!?), 성공적인 소프트웨어의 조건, 프로페셔널의 조건, 조직 내에서 만나는 다양한 개발자 및 아키텍처 인간군상과 그들에게 장인정신을 불어넣기 위한 시도들, 글쓴이가 프로그래머가 된 과정과 성숙하게 된 에피소드, 채용문화와 면접, 조직문화와 소프트웨어 프로젝트 성패, 마지막으로 장인으로서의 커리어 관리방법

책을 읽을까 말까 고민하는 사람들을 위해 그 내용들의 엑기스를 내 언어로 정리하면 다음의 내용으로 요약할 수 있다.

장인들은 더 많은 공장식 프로그래머들보다 보다 질 좋은 소프트웨어를 만들고 성공적인 프로젝트를 견인한다. 그걸 모르는 회사들도 많지만 앞서 나가는 회사들은 안다. 회사와 정직한 관계를 맺어라.
장인은 지식으로 완성되는 게 아니라 한 가지 개념에 대해 몇 년 또는 평생의 실천을 통해 완성되는 과정이다.
장인은 로직을 잘 구현하는 사람이 아니라 고객의 문제를 해결하는 사람이다. 고객의 목적을 위해 솔직하게 조직 내 수많은 사람들과 커뮤니케이션을 할 줄 알아야 한다. ⭐️⭐️⭐️
장인은 싸운다. 드라마 속 직장인처럼 굴지 말고 준비가 되었다면 아니오라고 말해라. 그 대상이 아키텍터, PM, 프로정신이 없는 동료일 수도 있다. 이들을 포섭하고 장인정신에 믿음을 주는 것도 장인이 할 일이다. 안된다고 포기하지 마라.
장인에게 필요한 건 열정이다. 그 열정으로 팀에 활기를 불어넣고 소프트웨어를 똑바로 만들게 된다. 팀의 퍼포먼스는 약한 고리에서 결정된다. 그러니 아무나 뽑지 말고 아무 데나 지원하지도 마라. 장인정신을 지향하는 조직인지 꼼꼼하게 따져라. ⭐️⭐️

이 내용을 더 요약하면 “열정적으로 임하고 그리고 프로답게 굴어라” 라고 할 수 있겠다. 이외의 패러다임, 실행 관례 등 세부적인 사항은 책을 직접 보면서 글쓴이가 겪었던 사례를 통해 더 실감 나게 통감할 수 있을 것 같다.

내 삶의 방정식의 해

이 책 마지막에 이런 문구가 나온다.

소프트웨어 장인은 매일 출근할 때마다 ‘급여를 받는 그 이상을 생각하고 … 사회 진화의 사명감을 느낀다’

그 말에 감명을 받았다. 이건 끙끙 헤매고 있던 내 삶의 방정식의 해였다.

비슷한 정답은 여태껏 많이 있지 않았던가. 열정을 가지고 일하라는 멘토들. 그런 게 현실에서 동작하는 건가? 에 대해선 의문이 언제나 문제였다. 현실의 조직은 열정보단 상사의 기분에 따라 목적도 성과도 일하는 방법도 움직이는 것 같았으니 말이다.
(이건 냉소적으로 일에 임하는 주변 사람의 일부 사례로 세상을 평가한 내 잘못도 크다. 세상엔 냉소적으로 직업에 응하는 사람들도 있겠지만 아닌 장인도 있는 건데.. 나는 냉소적인 사람들이 있을 땐 절망했고 뜨거운 사람들이 있을 당시엔 소화를 못했다.)

그러나 이 책에서 소개된 장인정신을 가지고 행동한 사례들과 일어난 충돌과 열정을 가지고 회사에서 솔직하게 일을 하는 게 잘못된 게 아니라고 말해준다. 만약 개발자의 장인정신을 인정하지 않는 조직이 있다면 서로 헤어지는 게 나를 위해서도, 채용하는 회사에게도 좋다는 글쓴이의 주장도 있는데 그걸 보니 나니 속이 시원해졌다.

더 성능이 좋은 알고리즘, 더 최신의 더 많은 솔루션에 대한 이해, 나아가 성공하려면 누군가랑 알랑 방귀 뀌는 게 중요한 건가라고 괴로워하던 내게 장인정신은 말해준다. “정확한 방법으로 더 솔직하게 일하는 게 더 중요하다.” 큰 위안이다. 😭

난 부끄럽다.

이 책에는 저자가 무언가를 시도하려는데 반대하는 사람들의 이야기가 참 많다. 그런 걸 보다 보면 아 반대하는 저게 내 모습은 아니었을까.라고 급히 반성 모드로 괴로운 마음으로 책을 읽게 되었다. 그런데 그럼 어떠랴.

장인 정신은 완벽한 지식이 아니라 실천 지향적 이데올로기다. 실행 관례로 한다고 다 잘되는 것도 아니다. 그 당시엔 합리적인 반대였을 수도 있다. 하지만 저자의 확고한 믿음을 미리 접했다면 난 더 많은 리스크를 감수할 수 있었을 테고 반대하지 않았을 텐데. 지금 와서 보니 과거에 같이 일했던 동료들에게 미안하다.

그래도 드는 의구심 1g

이 책에는 크로스펑셔널, 애자일 등을 실행하다가 체하는 사례(행오버) 이야기가 반복해서 나온다. 그리고 근거를 단다 ‘잘하는 사람들이 제대로 해야 효과가 있는 거다.’

필자는 이쯤 오면 장인정신과 애자일을 통해 소프트웨어의 품질이 좋아진 게 아니라 없어도 품질은 좋았을 건 아닐지 의문이 든다 🤨 인과관계를 잘못 파악한 건 아닐까? 물론 이데올로기가 소프트웨어를 만드는 게 아니라 장인정신을 믿는 사람이 소프트웨어를 만드는 거니까, 틀린 말은 아니란 건 알면서도 의문이 드는 것이다. 장인정신을 믿고 누가 봐도 제대로 실천하고 있다고 보이는 (열정이 있는) 사람이 잘못할 확률은 거의 없으니까.

그런데 이게 만능 지팡이는 아니야 그래도..

이 저자는 장인정신이 소개하는 방법들이 만능 지팡이처럼 여겨질까 봐 밑밥을 깔아 놓았다. 특히나 TDD에 대해 저자는 많은 지면을 설득하는데 할당했다. 그러면서도 여러 단서는 달았다. 정확한 문구는 아니지만 내가 느낀 바대로 요약하면 다음과 같다.

“TDD를 처음 해보는 개발자는 방법에 익숙 해지는데 수년의 시간이 필요하다. 잘 안될 수도 있다. 그런데 그건 제대로 안 해서 그렇다. 테스트 커버리지의 숫자 자체가 목적이라 완성된 프로젝트에 테스트만 외주를 주는 프로젝트도 있었다. 그런 건 노카운트다. 내가 해봤는데 매번 좋았다. 그런데 당장에 변경에 집착해서 해 이걸 안 하다고? 명백히 좋은 건데 품질에 관심 없이 하던 대로 하려는 당신이 잘못된 거다. 올바른 방법으로 일하도록 PM을 설득 못한 당신 잘못이다. 다 품질을 높이자고 하는 거다. 결국은 이게 더 빠르다! 그러니 Try it!”

난 특히나 커버리지의 숫자를 높히려고 하는것에 염려를 많이 하는 편이였지만, 필자의 간곡한 설득 끝에 나는 믿기로 했다. 고로 앞으로 하는 펫 프로젝트도 테스트 코드를 먼저 적기로 했다. 실행 강령 1호다. 혹여나 저를 만난다면 정말로 그렇게 하고 있는지 꼭 물어봐주길 바랍니다. 😉