[책 후기] 개발자 원칙

 

• 저자: 박성철, 강대명, 공용준, 김정, 박미정, 박종천, 이동욱(네피림), 이동욱(향로), 장동수
• 출판사: 골든래빗
• 책 링크: http://www.yes24.com/Product/Goods/115852769

 

00. 책을 읽기 시작하며

 처음 나왔을 때부터 읽고 싶었는데 책 읽기 모임에서 두 번째 책으로 채택되었다. 이 책은 특정 기술이나 개념에 대한 설명이 담긴 책은 아니다. 여러 C 레벨이나 시니어 급의 개발자들이 모여 개발자로서 어떤 삶을 살아왔는지, 어떤 철학을 갖고 있는지, 자신에게 개발/개발자란 무엇인지에 대한 고찰을 담은 책이다. 책이 얇고 가벼워 지하철에서 오며가며 읽기도 좋았고 개인적으로는 너무 재미있게 읽었다. 챕터마다 담긴 이야기에 대해서는 책을 직접 읽는 것을 추천하고, 아래는 각 챕터마다 읽으면서 감명 깊었던 부분과 들었던 생각에 대해 정리해보려 한다.

 

참고로 '|' 옆에 적어둔 문구는 책에서 직접 인용해온 글이다.

 

 

01. 덕업일치를 넘어서

내재 동기를 개발하고 고양하는 데 관심이 있는 사람이라면 금전적인 보상처럼 외부에서 통제되는 체제에 집중해서는 안 된다.

내가 개인적으로 좋아하는 짤이 있다. 김연아의 '무슨 생각을 해.... 그냥 하는거지' 짤인데 어떤 보상을 바라지 않고 실천한다는 점에서 좋아한다. 요즘엔 웹툰이든 드라마든 사이다 전개, 존버는 승리한다 등 어떠한 노력을 하면 반드시 보상이 주어지는 이야기가 많다. 하지만 나는 현실은 사이다만 존재할 수 없고, 외부에 휘둘리는 보상은 더 큰 좌절감을 느낄 수 있다고 생각한다. 스스로를 발전시키는데 만족감을 느끼는 것이 더 바람직하다고 생각하기 때문에 공감이 많이 가는 문장이었다.

 

그렇다면 스스로를 발전시키며 느끼는 만족감은 어떻게 얻을 수 있을까? 저자는 동기를 위생 요인과 동기 요인으로 나눌 때, 위생은 기본적인 생리적 필요에 대한 것이라 부족하면 문제가 되나 넘쳐도 만족감이 높아지지 않는다고 말한다. 만족감은 동기 요인에서 차오른다는 말이 인상 깊었다. 최저한의 커트라인을 두고 그 선을 충족해봤자 별로 즐거운 삶이 되지는 못하는 것 같다. 앞으로 나아가려는 도전 의식 또는 무엇을 해내고자 하는 욕구를 충족시킬 때 비로소 만족감을 느낄 수 있다고 생각했다.

 

에너지 관리는 단순히 에너지를 소진하지 않으려고 걱정하며 조심하는 소극적인 방식이 아닌 회복 탄력성을 키우고 에너지 그릇을 키우는 적극적 방식이 좋습니다.

업무를 마치면 너무 피곤하니까, 내일 일을 하려면 에너지를 아껴야하니까 라는 핑계로 공부를 미루기도 한다. 나의 모습을 뻔히 들여다본 듯한 문장에 찔끔했다. 

 

 

02. 오류를 만날 때가 가장 성장하기 좋을 때다

제대로 된 정보를 확인하는 최선의 방법은 소스 코드를 확인하는 겁니다.

이 챕터에는 저자의 트러블 슈팅 과정도 포함되어 있다. 나는 평소에 동작 안하면 디버깅 정도는 찍어보니까 그래도 소스 코드를 보고 문제 파악을 하는거 아닌가? 라는 생각을 했는데 책을 읽고 생각이 바뀌었다. 나는 수박 겉만 열심히 핥은 사람인걸로...🤣 시니어들은 다 이 레벨까지 파고드는걸까? 존경스럽다. 오픈 소스에 기여하는 사람들은 어떤 사람들일까, 코드를 하나하나 뒤져보다 오류를 발견하는 사람들일까? 라는 궁금증이 자주 있었는데 이런 분들이 오픈 소스에 기여하는 사람들이구나를 깨달았다. 내가 주로 다루는 프레임워크인 스프링은 공식 문서가 정말 잘 되어있다. 그래서 소스 코드를 딥하게 살펴보지 않고 문서를 참고만 하고 그칠 때가 많았다. 약간은 반성하게 되는 시간이었다.

 

 

03. 소프트웨어 디자인 원칙

디자인과 설계에 대한 이야기를 메인으로 많은 이야기가 나와있다. 솔직히 말하자면 내게는 와닿지 않았다. 나는 경험이 부족한 신입이고 내가 직접 설계하는 일은 드물다. 또한 아직 전체적인 업무 프로세스를 익히지 못했고 어떤 설계나 디자인 패턴이 존재하는지 어떤 것이 자주 사용되는지 알지 못한다. 이론적인 개념으로만 아, 이런게 있구나~정도로 습득한 느낌인데 나중에 경력을 쌓은 뒤에 다시 읽어보고 싶다.

 

한 번 릴리즈된 소프트웨어는 시간이 지날수록 커집니다. (중략) 그래서 굉장히 당연하게도 그다음 버전이나 기능의 완성은 느려질 수 밖에 없는데도 다음 버전을 만들 땐 더 빨리 더 효과적으로 만들 수 있다고 생각합니다.

이 문장을 읽으니 전에 만들었던 토이 프로젝트가 생각났다. 약 두 달간 설계부터 개발, 운영까지 내 손을 거치지않은 곳이 거의 없었다. 하지만 한 달 뒤에 보면 분명 내가 짠 코드인데 이해하지 못했고, 예전에 했던 고민을 다시 고민하며 같은 결과를 내놓고나서야 아~ 이때 그래서 이렇게 짰었지 같은 상황도 반복되었다. 이 책의 말처럼 시간이 갈수록 개발 속도가 빨라질거라 생각했지만 실제로는 큰 차이가 안나거나 오히려 더 느려지는 현상이 발생했어서 공감되었다.

 

 

04. 나의 메이저 버전을 업그레이드하는 마이너 원칙들

프로그래머의 뇌와 함께 자라기를 읽었고 실천해온 사람이라면 공감되는 내용이 많을 것이다. 좀 더 쉽게 간소화된 언어로 표현되어있으나 본질은 비슷한 말을 전달하고자 하는 것이 느껴졌다. 두 책을 좋아하는 내게는 인용하고 싶은 문구들이 너무 많아서 선별하기 힘들었다. 🤣

 

배워야 할 지식을 저처럼 현재 업무랑 관련된 것에 50%, 앞으로 관련될 것에 30%, 관련 없지만 관심 있는 것에 20% 정도만 시간을 투자해보세요. 개발자에게 성장은 멈춰 잇는 약속 장소가 아니라, 계속해서 움직이는 사냥감에 가깝습니다. 두리번거리며 준비하다 보면 회사 업무가 나와 상관없이 변화하더라도 기회가 될 겁니다.

요즘들어 어떤 것을 공부해야할지 큰 혼란을 겪고 있다. 우테코 때는 권장하는 학습 문제가 있었고, 같은 미션을 진행하다보니 비슷한 것을 공부하는 동료들이 많았다. 신입으로서 회사에 입사하니까 새로운 기술들은 너무나도 많았고 팀원들은 너무 바쁘거나 이미 어느 정도 알고 있는 기술들이기 때문에 함께 공부하는 제안을 하기에도 곤란했다. 그와중에 공부해보고 싶은 것들도 많아 이도저도 못하며 하루를 보내곤 했다. 이 글을 읽고나서야 어느 정도 가이드 라인이 생긴 것 같아서 좋았고 조금씩이나마 공부 해보고 싶었던 것들도 공부하니 즐거웠다.

 

어떤 대상이 물어봤더라도 이해하기 쉽게 설명할 수 있어야 진정으로 아는 겁니다. 그렇지 못하다면 알고 있다고 착각했던 겁니다.

내가 포스팅을 꾸준히 작성하는 이유 중 하나이기도 하다. 옛날에는 간단한 메모용으로 사용했지만 몇 개월 지나면 내가 남긴 메모임에도 불구하고 기억이 안나고 이해하지 못했다. 그래서 미래의 나 == 타인 이라고 생각하면서 글을 작성하기 시작했고, 점점 설명이 구체화되며 미래의 나 뿐만 아니라 다른 사람들도 읽을 수 있는 글이 된 것 같다. 아직은 많이 부족하지만 더욱더 이해하기 쉬운 글을 작성하기 위해 노력하고 있다.

 

 

05. 이직, 분명한 이유가 필요해

성장하기 위해서는 항상 고정적인 환경보다는 조금씩 변화를 주는 것이 훨씬 좋다. 이 이야기는 익히 들어왔으나 새로운 기술 스택을 사용해본다던가, (TDD에 익숙하지 않은 사람이라면) 개발 시 TDD를 시도해본다던가 등의 기술적인 측면만 생각해보았지 이직 또한 환경의 변화로 취급하는 것이 신기했다. 

 

기존 환경에서 변화 모색하기가 먼저, 그리고 책임감 있는 마무리가 중요해.

그러면서도 기존 환경에서 어떤 것을 변화시킬지 생각해보는게 더 우선 순위이고, 만약 이직을 결정하게 되었다면 책임감 있는 마무리를 강조하는게 인상 깊었다. 나같이 이직에 대해 잘 모르는 사람이 본다면 환경의 변화를 만들고 싶으면 이직을 생각해보란 말인가? 라고 단순하게 이해하고 넘어갈 수도 있는데 나의 말은 그게 아니다라고 저자의 꼼꼼함을 엿본 것 같았다. 아직 입사한지 얼마 안됐고, 이직의 생각이 없기 때문에 언제 이직이라는 환경 변화를 고민하게 될지는 아직 잘 모르겠다. 먼훗날 이직을 생각하게 된다면 그 때 다시 읽어보고 싶다는 생각이 들었다.

 

 

06. 목표를 달성하는 나만의 기준, GPAM

이 챕터에서는 큰 목표를 한 번에 달성하기 보다는 작은 목표들을 세우고 하나씩 이루는 것을 추천한다. 내가 이미 몸소 느끼고 있는 부분이라 크게 공감했다. 다만 무언가를 의욕을 가지고 지속적으로 실천하려면 목표를 다룬 뒤 꼭 평가를 수행해야한다고 되어있는데 내 생각은 조금 다르다. 지속적으로 실천하려면 습관화 해야한다고 생각한다. 나는 몸이 자연스럽게 진행하도록 행동을 습관화하고 목적 실천의 결과와 평가는 생략하는 것을 좋아한다. 개인적으로는 실천에 성공했다면 평가 시 의욕이 넘쳤지만 실패했다면 의욕이 뚝뚝 감소했다. 다른 사람과 함께 회고할 수 있을때는 괜찮은데 나는 스스로에 대한 평가가 박한 편이라서 이런 현상이 나타나는 것 같다. 물론 책에서 말하던 평가란, 실천을 왜 실패했는지 분석하고 어떻게 개선해야하는가 같은 이성적인 면모를 의미하는듯 하지만 마음처럼 되는게 어렵다. 사람의 성향에 따라 다를거란 생각이 들었다.

 

항상 상황은 변하기 때문에 목표와 계획을 세워두고 실천까지 시간을 오래 끌다 보면 의미가 없는 목표가 되어 버리거나, 계획 실천이 불가능해지거나, 각오가 사그라들거나, 잊힙니다.

목표를 세우기만 하고 달성까지는 지지부진한 나에게 꽤 뼈아픈 말이었다. 그리고 격하게 공감했다. 오랜 기간 염원하던 목표를 이뤄도 뿌듯함과는 별개로 성취감이 적었던 적이 있었다. 그 원인을 파헤쳐보자면 이렇게 의미가 없거나 중요해지지 않은 목표로 변해버렸기 때문이 아니었을까 싶다.

 

 

07. 프로덕트 중심 주의

순수하게 예제를 실행시키고 얻은 지식과, 끊임없이 판단과 피드백을 반복하며 제품을 만들어본 경험은 폭과 깊이가 다를 수밖에 없습니다.

나는 개발을 막 시작하는 사람들에게 항상 만들어보라고 한다. 직접 만들며 학습하는 것이 더 인상깊게 남으며 막연한 방향성을 제시해주기 때문이라고 하는데, 만들며 학습해본 경험이 없는 사람들에게는 전혀 와닿지 않는 말이 될 뿐이다. 시키니까 해볼뿐. 하지만 이 챕터를 읽고나니 왜 그래야하는지 말로 설명할 수 있을 것 같았다. 한 프로젝트를 만들기 위해서는 주제를 선정하고, 설계하고, 개발하고, 운영하고, 유지보수하는 등 여러 작업을 순서대로 거칠 것이라고 흔히들 착각한다. 하지만 실제로 만들다보면 개발하다 설계가 뒤엎어지기도 하고 주제를 다시 선정해야할 때도 있고 유지보수하다 개발이 잘못되어 다시 만들어야하는 부분을 발견할 수 있다. 설계->개발->운영->유지보수 라는  프로세스를 한 방향으로만 진행되지 않고 때로는 역방향을 경험하고 다시 반대 방향으로 진행하기도 하면서 더 많은 것을 경험할 수 있기 때문이라고 생각한다.

 

 

08. 제어할 수 없는 것에 의존하지 않기

기준과 원칙에 따라 빠르게 결정을 내리면, 정말 중요한 설계와 선택이 필요할 때 더 깊게 사고할 수 있는 시간을 확보하고 사용하게 됩니다.

시니어들과 달리 신입과 주니어들이 허둥거리는 이유는 뭘까? 나는 요 챕터를 통해 그에 대한 답을 내릴 수 있게 되었다. 내가 지금 회사에서 가장 어려운 것이 '이것을 해도 되는가'를 판별하는 일이다. 이걸 실행했을 때 문제가 되지는 않을까? 내가 원하는 값을 찾기 위해서는 이 도구를 이용해야하는걸까 저 도구를 이용해야하는걸까? 같은 크고 작은 고민들이 많다. 이걸 기존 팀원들이나 시니어들에게 물어보면 아 이건 저렇게 하고요 저건 이렇게 하면 됩니다. 딱딱 결정이 내려지고 내 n분~ n시간 동안의 고민들은 10초 만에 사라진다. 자신만의 혹은 팀 내의 기준과 원칙을 명확히 알고 이해하기 때문에 내릴 수 있는 판단력이 아닐까 싶다.

 

제어할 수 없는 것에 집중하다 보면 그 무엇도 해결하지 못할 수 있습니다. 제어할 수 있는 것에 의존하고 집중해야만 어떤 일과 상황을 만나더라도 앞으로 전진할 수 있습니다.

개인적으로 동경하는 분이라 이 저자 분의 영상이나 글을 자주 접해왔다. 그래서 제어할 수 없는 것에 의존하지 않기와 비슷한 말들을 자주 들었었지만 막연하게 기술적인 부분에 대해서만 생각했다. 테스트를 쉽게 만들기 위해서는 제어할 수 없는 것을 최대한 분리시켜 용이하게 만든다던가, 같은 식으로만 생각해왔는데 현실의 문제도 같은 방식으로 접근하셨다는게 무척 인상 깊었다. 어떤 식으로 접근하셨는지는 책을 직접 읽어보길 추천한다 :)

 

 

09. 달리는 기차의 바퀴를 갈아 끼우기

성능은 매우 중요한 조건이지만, 대부분의 경우 우선순위가 높지 않습니다. (중요도와 우선순위를 헷갈리면 안됩니다.)

크리스마스 이벤트 페이지는 크리스마스 전에 만들어야 합니다. 크리스마스에 룰렛을 돌려서 경품을 주는 이벤트를 하기로 했다면, 크리스마스 이브 저녁이 되기 전에 룰렛이 돌아가야 합니다. 크리스마스가 지나고나서 더 작은 자바스크립트와 더 효율적인 CSS로 10%의 CPU로 10배 빨리 돌아가는 룰렛은 쓸모가 없습니다.

당연한 말들이지만, 중요도와 우선 순위를 헷갈리면 안된다는 말이 인상 깊었다. 둘을 완전히 분리해서 볼 수는 없다. 우선 순위가 높은 일이라는건 중요한 문제라는 뜻이니까. 다만 반대로 중요한 문제는 우선순위가 높은 문제다 라는 말은 성립되지 않는다.

 

레거시는 해결해야 할 기술적인 과제인 '기술 부채'도 포함하고 있지만, 많은 문제를 해결한 그리고 해결할 유용한 '기술 자산'도 포함하고 있습니다. (중략) 레거시를 물려받았다면 어떤 것이 자산이고 어떤 것이 부채인지 식별해야 합니다.

레거시는 언젠간 해결해야할 거대한 쓰레기더미 혹은 괴물 정도로 생각해왔는데 유용한 기술 자산이라고 표현하는 것이 신기했다. 어떤 문제를 직면했고 굉장히 옛날 코드를 포함하고 있다면 아 이거 그냥 다시 만들면 안되나 라는 생각이 들었었는데 과거 그렇게 짤 수 밖에 없던 상황이 있던건 아닌지, 내가 고민하고 또는 앞으로 고민할 문제들을 모두 해결한 방안이 지금의 코드인 것은 아닌지 구분할 수 있으면 좋을거란 생각이 들었다. 이를 위해 이런 히스토리를 문서화하고 주석에 문서 링크를 추가해둬도 좋을거란 생각이 들었다.