더 나은 프로그래머 되는 법 도서 리뷰
프로그래머로 회사에서는 물론 개인 프로젝트를 개발하다 보면 어느 순간 지금의 나는 지난번의 나보다 더 발전했는가?라는 생각이 지속적으로 떠오르게 됩니다. 그리고 더 좋은 코드를 작성하기 위해 우리는 노력합니다. 그렇다면 그 노력은 정말 더 나은 프로그래머가 되기 위한 노력이 맞을까요? 더 나은 프로그래머 되는 법 도서 리뷰를 해보도록 하겠습니다.
파트 1: you.write(code);
지옥에 보내버려야 할 코드 역시 좋은 의도로 포장되어 있다.
-p32: 코드에 신경 쓰기
"좋은 프로그래머는 무엇일까? 좋은 코드를 작성하면 좋은 프로그래머, 나쁜 코드를 작성하면 나쁜 프로그래머일까?" 저는 나쁜 코드를 작성하면 나쁜 프로그래머가 아닐까라고 생각했습니다. 하지만 도서에서 말하는 바에 따르면 의도적인 나쁜 프로그래머는 없다는 것입니다. 올라온 PR 혹은 다른 프로젝트에 involve 후 코드를 볼 때 '나쁜 코드다!'라고 생각할 수 있겠지만, 실제로는 그 당시 최선이었거나 다른 의도가 있을 수 있는 것처럼 대부분의 프로그래머는 고의적으로 나쁜 코드를 작성하지는 않을 것입니다.
이 책에서도 간단한 예시로 설명하는 것이, 모든 프로그래머는 좋은 코드를 작성하고 싶지만 할당된 작업 기간이 매우 촉박하거나 작업량이 매우 많은 경우 어쩔 수 없이 나쁜 코드를 작성되는 경우가 존재할 수 있다! 는 것입니다.
좋은 코드가 되기 위한 최소한의 방지책으로 코드 구조, 일관성, 명명, DRY 등 도 함께 설명하고 있는데 사실 이는 너무나도 당연한 내용들이기도 합니다.
공정하게 말하자면, 불쾌한 코드는 고의성을 띠지 않는다. 대부분의 개발자는 힘들고, 중복 되며, 무의미한 코드를 의도적으로 작성하지 않는다 (간혹 좋은 코드에 시간을 투자하기보다 낮은 품질의 코드를 계속 사용하는 게으른 프로그래머가 없지는 않다).
-p63: 그래서 무엇을 해야 할까
내가 개발하는 과정 혹은 프로젝트가 오랜 시간 많은 사람들에 의해 유지보수 되면서 발생할 수 있는 각각의 상황에 대해 예시를 빗대어 해결법을 안내하고 있습니다. 다양한 내용들이 소개되었지만 파트 1에서 기억나는 내용 중 하나는 죽은 코드를 제거하는 일은 해롭지 않다. 라는 내용입니다.
물론 그냥 버리는 것은 아니고, 미래에 필요할지 모르는 기능이라도 코드를 제거하는 것이 안전하며 이는 버전관리시스템을 통해 언제든 복원이 가능하다는 것입니다.
파트 2: 연습을 통해 완벽해진다
프로그래밍 세계에 널리 알려진 이상한 가설 중에는 다음과 같은 것이 있다. “일단 어떤 코드 가 작성되면, 그것은 신성한 것이 된다. 절대 수정되어서는 안 된다.” 만약 다른 사람의 코드 일 경우는 그 신성함이 두 배가 되므로 감히 건들지 말라.
-p235
기존 정상적으로 동작되는 로직이 있다면 건들기가 조금은 무서워집니다. 시간이 지나 전반적인 흐름을 파악하기 어렵거나 특히 핵심적인 로직인 경우 잘못 건드렸다가는 엄청난 후폭풍(?)이 찾아올 수 있기에 예민하게 반응될 수 있습니다. 이에 대해 저자는 다음과 같이 말하고 있습니다.
코드란 절대로 불변 이어서 는 안 되며 , 그 어떤 코드 도 신성 시 되어서 는 안 된다. 어떠 한 코드 도 완벽 할 수는 없다. 코드 주변의 세상 은 끊임없이 변화한다. 코드 가 부지런히 세상의 요구 사항에 맞춰 나간다 해도 , 요구 사항 은 언제나 끊임없이 변화한다
-p236
저자는 리팩터링을 두려워하지 말고 자신감을 가지고 변경하라 이야기합니다. 물론 생각 없이 자신만의 생각으로 자유롭게 수정하는 이른바 '카우보이 코딩'은 금기하며 "잘 돌아가는 로직을 효율적으로 리팩터링함!"으로 올린 기능에 대해 "효율적으로 리팩터링함에 따라 발생된 이슈에 따라 기존 코드로 롤백함"과 같은 상황은 방지해야 한다 합니다.
사실 이는 너무나도 당연한 이야기입니다. 리팩토링을 통해 굳어있는 코드를 효율적으로, 효과적으로 변경하는 행위는 필요하지만 이를 통해 다른 이슈가 발생한다면 그것만큼 죄악인 일은 없지 않나 싶습니다. 이는 제가 이전에 작성했던 도서 리뷰글에도 동일한 생각으로 작성하였습니다.
개인적으로 리팩토링을 하는 행위는 새로운 기능을 만드는 행위보다 더 위험하다고 생각됩니다. 개발자의 관점에서는 더 직관적이고 효율적인 로직으로 바꿈으로써 일종의 이쁜 코드(?)로 바꾸는 행위이기에 완료하고 바뀐 코드를 볼 때 희열을 느낄 수 있습니다. 저도 리팩토링이 끝난 이후 코드를 보면 너무나 아름답다는 생각에 엄청난 희열을 느낄 때 가 있습니다.
/* 중략 */
물론 어디서든 펑펑 터지는 crash 혹은 잘못된 로직으로 큰 부하나 비용이 발생한다면 리팩토링이 시급할 수 있겠지만, 기존 정상적으로 동작되던 기능을 단순히 더 깔끔한 로직을 위해 리팩터링 하다 무결했던 기능까지 망쳐버린다면 그것만큼 큰 잘못은 없다고 생각합니다.
코틀린으로 마이그레이션을 원한다면, 자바에서 코틀린으로: 코틀린으로 리팩터링하기
저자도 리팩토링은 필요하지만 그것으로 인해 무결한 기능을 망쳐서는 안 된다. 이것은 마치 양날의 검과 같다고 설명하고 있습니다. 그래서 저자는 본 도서에서 가장 중요하게 언급하는 것이 리팩터링과 단위 테스트입니다. 단순히 이 파트의 리팩토링에 대해 이야기할 때에만 테스트를 이야기하는 것이 아닌, 각 파트 전반적으로 리팩터링과 단위 테스트의 중요성에 대해 목이 터져라(?) 언급하고 있습니다.
물론 테스트 코드를 작성할 수 없는 상황(너무 짧은 개발기간 등)이 있을 수 있고 만능은 아니라고 설명합니다. 다만 좋은 코드가 되기 위해서 시간 여유가 생긴다면 한 부분 씩이라도 테스트 코드를 작성하는 것을 권장하고 있습니다.
파트 3: 개인적인 일로 받아들이기
파트 3에서는 효율적인 코드를 작성하는 방법! 에 대해 설명하기보다는 프로그래머로써 어떤 식으로 성장하면 좋을지에 대해 설명합니다. 여기서 프로그래머로서 발전하고 싶다면 배움 그 자체에 숙련되고 노련 해져야 하며, 배움을 즐기는 법도 배워야 한다.(p309) 동일하고 지루한 코드를 줄줄 뽑아내는 '코딩 공장'에 갇히면 흥미가 떨어지고 배우는 것을 멈추게 될 것이다.(p332)라는 내용이 많은 공감이 갔습니다.
전 회사에서 어느 시점부터 기존 프로젝트를 비슷한 형태로 빠르게 변형하여 짧은 기일 내 출시해야 하는 과정이 여럿 생기다 보니 프로젝트에 애정을 갖고 개발할 수 있는 시간이 짧고 무언가 찍어내는 듯한 느낌이 들어 복합적으로 공장이 된 것 같다는 생각이 든 경험이 있습니다.
물론 이 과정에서 유사 프로젝트이기에 이전에 겪었던 구조적 문제를 반복하지 않도록 한번 더 생각하여 설계한다거나 새로운 기술을 활용하더라도 마이그레이션 해야 하는 부분이 크게 없었기에 큰 무리 없이 도입할 수 있어 이런 부분에선 빠른 성장을 할 수 있었지만 조금은 아쉬웠던 시기가 아닌가 싶습니다. (그렇기에 Jetpack Compose를 빠르게 도입할 수 있었던 이유 중 하나가 되지 않았을까...)
결과적으로 이 파트에서는 코드적인 부분이 아닌, 정말 프로그래머로서 성장하는 방법에 대해 고민하고 탐구할 수 있는 시간을 제공합니다. 외적으로 건강을 위해 자세와 눈에 대해서도 이야기하고 있는데...
집중하라. 30장에서의 충고를 적절히 받아들이지 않는다면 엄청난 의료 비용을 감당하게 될 수 있다. 언젠가는 필자에게 감사하게 될 것이다.
-p367: 프로그래머의 자세
자세가 중요하다는 것은 누구나 알고 있는 사실이지만 저의 경우 알고 있음에도 나쁜 자세를 통해 지난 4월 병원에 입원하여 병원비로 200만 원이 증발되었습니다.
정확하게 이틀 전부터 허리가 조금 안 좋은 것 같은데 라는 생각은 했지만 무시하고 지내다 3일 차가 되는 날 아침에 일어날 수가 없을 정도의 허리 통증으로 결국 2일간 입원하게 되었습니다. 의사 선생님께서 경과에 따라 최소 3일 입원해야 할 수 도 있다 말씀하셨는데 3일 차 되는 날이 상권님의 컨퍼런스에서 KMP를 주제로 발표하기로 하여 무조건 2일 아니면 입원 안 하겠다고 말씀드렸고 결국 행사 전날 퇴원하여 무사히 발표도 마치고 지금은 허리도 괜찮아졌습니다. (다만 퇴원 후 3주간 지속적인 통증으로 약과 함께 살았습니다.)
개발자는 허리가 생명이다!라고 다들 말하고 저도 그렇게 말하지만 실제로는 모두 자세가 좋지 않기에... 이 글을 읽으시는 분은 지금이라도 자세를 고쳐 앉으면 좋을 것 같습니다. 만약 이 책을 지난달 입원하기 전에 읽었다면 200만 원을 아낄 수 있지 않을까...
파트 4: 일 끝내기
본 파트에서는 10장 정도의 분량으로 효율적인 일에 대해 설명합니다. 여러 가지 내용이 있지만 와닿았던 부분은 NIH 증후군을 극복하자입니다. 다른 프로그래머의 코드를 사용하는 경우 꺼림칙하거나 조금 비효율적인 것 같은데 하며 다시 작성하는 경우가 종종 있습니다. 그렇지만 이미 작동한다면 다시 작성할 필요가 없으며, 만약 자신의 시스템에 통합해야 한다면 퍼사드 패턴 사용을 추천하고 있습니다.
또한 코드 외적으로도 생략 가능하고 효율적으로 다룰 수 있는 부분은 효율적으로 다루자고 하고 있는데, 필자의 실화 이야기로 모서리가 둥근 예쁜 화살표를 만들어야 했기에 처음에는 Graphics API로 그렸으나 이쁘지 않았고, 이미지로 만들자 생각하여 포토샵으로 한 시간 동안 만들었지만 이쁘지 않게 나와 포기하고 차를 타고 오니, 다른 동료가 10초 만에 우리가 모두가 알고 있는 오피스 프로그램으로 모서리가 둥근 예쁜 화살표 도형으로 이미지를 만들어줘 해당 이미지를 사용했다는 사례를 이야기하고 있습니다.
여기에 감명받은 저는 현재 진행하고 있는 개인 사이드 프로젝트에서 완벽을 위해 아이콘을 굳이 하나하나 찾아 넣고 있었는데, 그냥 아이콘 라이브러리를 임포트 해서 사용하였고 그 결과 매우 만족하고 있습니다 (굳)
이처럼 야매처럼 보일 수 있는 방법이라도 결과가 명확하고 효율적이라면 사용하자는 이야기를 담고 있는데, 어느 정도 타협한다면 보다 효율적으로 개발할 수 있지 않나 라는 생각이 들었습니다.
그리고 개인적으로 인상 깊었던 한 멘트가 있었습니다.
전통적 조언을 기억하라. 한 번 이상 반복 해야 하는 일이 있다면 , 그것을 수행하는 스크립트를 작성하라.
-p387: '더 열심히' 보다는 '더 현명하게'
파트 5: 사람의 일
마지막 파트는 프로그래머는 혼자 일하는 것이 아닌 함께 일한다는 것. 그리고 스스로 프로그래머로서 어떠한 방향을 걸어갈 것 인지에 대해 고찰하도록 하는 내용으로 마무리되고 있습니다.
각자 자기가 옳다며 팀원과 싸운다면, 같은 작업을 불필요하게 반복하거나 코드베이스에서 Conflict 폭탄을 맛볼 수 있으며, 더 나은 프로그래머가 되길 원한다면 납득할만한 개발 선언문을 지지하되 맹목적으로는 따르지 말자!라고 이야기 합니다.
아래는 필자의 선언문인데, 이를 통해 필자가 생각하는 더 나은 프로그래머가 되기 위한 정의가 무엇인지를 알 수 있는 대목이 아닌가 싶습니다.
• 코드에 신경 써라.
• 팀의 힘을 키워라.
• 간결함을 유지하라.
• 머리를 써라.
• 그 무엇도 고정된 것은 없다.
• 꾸준히 배워라.
• (주체가 자신이든, 팀이든, 코드든 간에) 나아질 방향을 꾸준히 모색하라.
• 언제나 가치를 전달하려 애쓰라. 길게 볼 수 있도록 해보라.
Appendix: 국내 개발자 8인의 이야기
부록에서는 국내 개발자 8명의 이야기를 2-3장 정도 분량으로 담고 있습니다. 앞의 파트 1~5의 내용도 좋았지만 부록에서도 많은 배움과 고민을 할 수 있었습니다.
몇 가지 기억에 남는 문구를 작성해 보자면
- 생성형 AI 시대
- 프로그래머들이 테스트 주도 개발 (TDD)을 해야 한다.
- 더 중요하게 생각해야 할 또 하나의 영역은 소프트웨어 아키텍처이다.
- 팀플레이어
- 신형 노트북 구매를 요청할 때 본인뿐 아니라 팀을 챙기고 수치적 근거를 제시한다.
- ‘배포 속도가 2분에서 1분으로 줄기 때문에 하루에 배포를 15번 한다고 하면 한 달에 300분을 아낄 수 있다’
이외에도 많은 공감 가거나 정말 새롭게 생각하게 되는, 그동안 가진 생각에서 살짝만 틀어서 생각한다면 더 효과적으로 효율적으로 개발자로서 성장할 수 있는 주옥같은 말이 많았습니다. 정말 2-3장 정도의 짧은 분량이지만 이 부록 내용 만으로도 많은 성장을 할 수 있을 한 문장 한 문장에 정말 깨달음을 얻은 것처럼 몸이 짜릿했습니다.
마지막으로 본 리뷰를 끝내기 전에 남기고 싶은 부록의 한 문장은 좋은 직함이나 회사보다 ‘내가 잘 할 수 있는 일’을 찾기 입니다.
개발자로 일했을 때, 저는 스스로 탑 0.1%의 락스타(Rock Star) 개발자는 아니라는 것을 일찌감치 깨달았습니다. 코딩 인터뷰 성적만으로 다른 경쟁자들을 제치고 들어갈 낭중지추감 역시 아니었습니다.
- 마이크로소프트, 주한나: 좋은 직함이나 회사보다 ‘내가 잘 할 수 있는 일’을 찾기
외부 컨퍼런스에서 많이 발표하다 보니 일부 분들이 오프라인에서 만나게 되면 개발 잘하신다고 말씀해주시는 기쁜 경우가 있습니다만... 사실 저는 초등학교 때 처음 프로그래밍을 접하면서 재미를 느꼈기에 같은 나이 대의 사람들보다 그저 조금 더 개발 경험이 있을 뿐 기술적으로 상위 n%에 들 수 있는 뛰어난 사람이라고는 생각하지 않습니다. 항상 이제 조금 실력이 오른 것 같은데 생각하고 반년 뒤에 내가 짠 코드를 보면 이게 무슨...이라고 말하는 전형적인 평범한 개발자라고 생각합니다.
더욱이 중학교 때 창업한 경험을 바탕으로 언젠간 다시 창업을 꿈꾸고 있으며, 이를 위한 발판으로 사이드 프로젝트를 만들 때에는 그동안 읽은 스타트업 관련 도서에 따라 빠르게 MVP를 만들어 시장 검증 및 차근차근 업데이트하자 라는 생각을 하면서도 조금만 더 모듈을 분리하고 구조를 잡으면 이쁠 것 같은데 라는 생각이 충돌되는 아이러니한 상황을 가지고 있습니다.
지금도 출시를 위해 개발하고 있는 프로젝트의 경우에도 기본 기술 검증을 위한 테스트 데모앱은 3일 만에 끝낸 뒤 3개월이 지났지만, 더 좋은 코드가 무엇일까 고민하고 개발하다 보니 기능 추가가 아닌 코드 구조에 더 집중하고 있는 모습을 발견하였습니다. (물론 이 과정에서 MVI 디자인 패턴을 공부하여 적용할 수 있는 좋은 기회가 되었습니다.)
주한나 님의 이야기에 따르면 본인을 제한 AI팀 구성원 80%는 박사학위가 있다고 합니다. 본인보다 자격이 있는 사람은 최소 수만, 수십만 명이 있지만 본인은 지속적으로 다니면서 증명할 수 있었기에 AI팀에 합류할 수 있었다고 합니다. (사실 이미 마이크로스프트인 것부터가 실력이 뛰어나셨겠지만...)
이 과정에서 내가 가진 잘 할 수 있는 것에 대해 한번 더 고민하게 되었고, 내가 가진 아이디어를 빠르게 실행하여 결과물을 만들 수 있다는 것과 뛰어나지는 않지만 조금씩 항상 성장한다는 것. 이 2개가 내가 가진 잘 할 수 있는 일이라고 생각되었으며, 이 2개를 포기하지 않는 방법이 무엇일지 고민하여 내린 결론으로 창업을 위한 발판으로 준비하는 인디해커 프로젝트를 만들 땐 MVP 위주로, 오픈소스 프로젝트를 만들 때는 더 나은 프로그래머가 되기 위한 방향으로 만들어 두 가지 실력을 모두 키워보자 를 내리게 되었습니다.
무언가 도서 리뷰 마지막에 개인적인 이야기가 조금 길게 들어간 것 같지만, 그만큼 본 도서를 통해 개발자로서 좋은 코드를 작성하는 방법, 소통하는 방법, 성장하는 방향 등 더 나은 개발자가 되기 위해 많은 고민을 할 수 있는 길을 제시해 준 도서가 아닌가 싶습니다.