<개발자 원칙> (테크 리더 9인 공저) / 골든래빗
개발자 9인(박성철, 강대명, 공용준, 김정, 박미정, 박종천, 이동욱, 이동욱, 장동수)의 원칙에 대해 다루고 있는 글이지만, 각각의 원칙이 당장 내게 깊게 다가오지 않는 것도 있고, 원칙 그 자체보다 원칙에 다다르기까지의 여정이 더 인상깊은 부분도 있고 해서 발췌와 각 발췌에 대한 내 코멘트로 기록해두려 한다.
사실, 책을 공개된 매체에 과하게 발췌하는 걸 좋아하지 않는다. 저작권 문제도 있지만, 발췌도 일종의 편집이라 책을 읽기 전에 내 시각에 영향을 받고 읽게되는 사람이 있을까봐서 그렇다. 그래서 최대한 짧게 요약해서 발췌하려고 했는데.. 생각보다 발췌한 부분이 많아서 길어졌다.
혹시라도 누군가 이 글을 본다면, 이 포스트로 책을 파악했다고 여기지 말고, 관심가는 키워드가 있다면 그 부분을 찾아 책을 읽어보기를. 이 누군가는 미래의 나를 포함한다. 한참 뒤에 다시 읽으면 또 새로운 부분이 보일 책이다.
발췌 + 덧붙임
어떤 일을 시작할 때면 그 일을 해야 할 개인적인 의미를 찾아 가능한 강한 내적 동기를 가지고 일하려고 의식적으로 노력했습니다. 정 동기가 찾아지지 않으면 일부러 제가 하고 싶은 일을 그 과제에 섞어넣기도 했습니다. p37
→ 나도 많이 썼던, 쓰고 있는 방법이라 공감이 가서 발췌. 특히 학창시절 과제할 때 어떻게든 재미있게 하고 싶어서 애썼던 기억.
동기를 관리하는 사람은 자신의 에너지도 관리하고 지나치게 에너지를 소진하지 않으려고 노력합니다. 동기는 단순히 있고 없고 하는 것이 아닌 크기가 있는 양입니다. p38
"지식 근로자는 스스로 성과의 방향을 성정해야 하기 때문에, 자신에게 어떤 성과각 기대되고 있는지 그리고 자신에게 그러한 성과가 기대되고 있는 이유가 무엇인지를 이해하지 않으면 안된다." 피터 드러커.
이때부터 저는 동기를 스칼라가 아닌 벡터로 생각하기 시작했습니다. 내가 뭔가를 만들어냈다면 그 성과는 그 자체로 의미 있지 않고 원래 나에게 기대된 성과의 방향에 비추어 평가된다고 봤고 이는 결국 두 벡터의 정사영에 해당했습니다. p40
흔히 좋은 팀워크는 좋은 분위기를 의미합니다. (중략) 하지만 팀워크는 그 이상입니다. 1+1이 2 이상이 되도록 만드는 것이 팀워크입니다. p44
→ #협력 #소통 언제나 중요한 키워드들. 대학 때의 팀 프로젝트는 항상 좋은 분위기를 유지하는데 힘 썼던 것 같다. 분위기와 소통 방식이 정말 달랐던 두 팀 프로젝트를 동시에 하면서 좋은 팀워크에 대한 생각을 어렴풋이 재정의하게 되었고, 이후 프로젝트에서는 좋은 분위기가 아니라 공동의 목표를 공유하고 더 효과적으로 협력할 수 있도록 하는 것에 집중했다.
"백엔드 엔지니어의 실력은 얼마나 많은 오류와 장애를 만나고 이를 해결했는지 여부에 따라 갈린다" p53
(오류가 발생하면 소스코드 레벨에서 이해 -> 알아낸 지식은 글로 공개)
'설계란 제품이 요구사항을 만족시키는 것을 증명하는 조건을 정의하는 행위'로 불 수 있습니다. 그래서 설계 전에 요구사항을 잘 정의해야 합니다. (중략) 요구사항이 정해지면, 설계 단계에서는 만들 제품이 주어진 요구사항을 잘 충족하는지 증명할 수 있는 조건을 정의해야 합니다. (중략) 단어적인 설계나 개념이 측정할 수 있는 숫자적 개념으로 바뀌게 됩니다. p85
→ 이전에 요구사항 명세서를 작성할 때 이 부분이 미흡했던 것 같다. 요구사항은 상세하게 잘 만들었고, 구현할 때도 그걸 참고하긴 했는데, 충족 조건을 분명하게 정의해두지 않아서 이정도면 되었는가? 하는 질문을 매번 던져야했다. 그또한 나쁘지는 않았지만 시간이 불필요하게 소모되는 부분이 있었다.
배워야 할 지식을 저처럼 현재 업무랑 관련된 것에 50%, 앞으로 관련될 것에 30%, 관련 없지만 관심 있는 것에 20% 정도만 시간을 투자해보세요. p122
'낯선 방식으로 해결하기' 학습은 익숙한 것을 의식하지 않고 반복하는 게 아니라, 낯선 것을 의도를 갖고 배우는 겁니다. p123
→ 와 이거 정말... 머리로만 알고 몸으로는 못하는 그것이다 ㅋㅋㅋㅋ...
성장을 위한 더 효과적인 방법은 의도적으로 낯선 환경을 만들고, 제약사항을 추가해서, 도전적이면서 살짝 어렵지만 재밌는 요소를 찾아서 학습하는 겁니다. p128
ex1) 내가 익숙하게 풀었던 문제나 코드를 새로 익히는 언어로 풀어보기
ex2) 함수를 작성할 때 10줄 이내로만 작성하려고 시도하기
ex3) 익숙한 통합 개발 환경 대신 터미널에서 CLI 명령만으로 빌드를 직접 해보기
ex4) 마우스 없이 키보드만으로 단축키 쓰기
→ 예시 3번이 특히 혹한다. 한번쯤 해보고 싶었던 도전이긴 한데...
(개구리 해부X, 직접 만들기O) 직접 만들어보라는 의미는 분석, 설계, 개발, 검증 단계를 위에서 아래로, 아래에서 위로 반복해야 한다는 의미입니다. p132
개발자에게 문제는 무엇일까요? 기술 부채 문제, 제품 개발 우선순위 문제, 동기부여 문제, 조직 안의 소통 문제 등 사실상 모든 곳, 모든 것이 문제일 수 있죠. p169
GPAM: Goal을 정하고 Plan을 만들고, Action을 하고, Measure를 진행해 결과를 확인. p170
(PAM이 가능한 목표를 세울 것, 계획은 실천할 수 있어야 하고, 평가할 수 있는 결과를 도출해야 하며, 평가 데이터를 보고 다시 목표와 계획을 수정할 수 있어야 함. p172)
→ 정말 중요한 인사이트. 목표는 평가할 수 있는 결과로 도출되어 한다. 그리고 그렇게 평가된 데이터를 명확한 수정 방안으로 나를 이끌어야 한다. 이걸 설계하는 작업이 정말 까다롭다. 항상 평가 기준이 모호해지거나, 평가를 해놓고도 어떻게 목표와 계획을 수정해야할 지 가늠이 되지 않아서 문제가 되곤 한다.
디테일과 빠른 실행, 그리고 근본적인 목표에 대한 고민은 선택의 문제가 아닙니다. 핵심적인 목표 설정은 이터레이션의 주제를 정리하게 도와주고, 박자를 만들어 디테일을 신경 써야 할 때와 그렇지 않을 때를 리듬감 있게 오가게 하는 도구입니다. p197
프로덕트를 목표로 삼았다면 무언가를 계속 시도하면 됩니다. 모든 시도가 멋지고 대단하고 어렵지 않아도 됩니다. 반드시 모든 시도가 성공적 출시가 아니어도 좋습니다. (중략) 더 나은 프로덕트를 목표로 삼고 무언가를 계속 반복적으로 시도하면 점점 프로덕트를 잘 이해하게 됩니다. 프로젝트 실패 경험은 오히려 큰 성장을 이루게 하며, 앞으로 더 잘할 수 있는 역량을 보장하기 때문입니다. p200
→ 실패... 하다가 만 프로젝트도 여기서 말하는 실패한 프로젝트일까. 소프트웨어적인 부분은 아니지만 분명 개선점이 있긴 하겠지. 목표 설정과 일정 관리 면에서라도.
빠듯한 일정으로 일이 주어져도 항상 80~90점의 소프트웨어를 출시하는 분들이 있습니다. (중략) 기준과 원칙에 따라 빠르게 결정을 내리면, 정말 중요한 설계와 선택이 필요할 때 더 깊게 사고할 수 있는 시간을 확보하고 사용하게 됩니다. p208
→ 팀 협업에서도 프로덕트의 방향과 우선순위를 분명하게 해두면 시간 vs 퀄리티, 더 쉬운 방식 vs 더 객체지향적인 방식 같은 갈등 상황에서 빠르게 판단할 수 있었다.
"제어할 수 없는 것에 의존하지 않기." (실용주의 프로그래머) p210
ex1) 구현에 있어, 제어할 수 없는 현실 세계 속성을 사용하지 않기
ex2) 주요 비즈니스 로직은 모두 제어할 수 있는 값만 의존하게 해 테스트 코드 작성이 쉬운 형태로 구성하기
제어할 수 있는 것과 제어할 수 없는 것을 구분한 뒤, 제어할 수 없는 것을 멀리하고, 제어할 수 있는 것에 집중하면 됩니다. p225
→ 주여, 우리에게 우리가 바꿀 수 없는 것을 평온하게 받아들이는 은혜와 바꿔야 할 것을 바꿀 수 있는 용기, 그리고 이 둘을 분별하는 지혜를 허락하소서. (평온을 비는 기도 Serenity Prayer - 위키백과 참고) 이건 정말... 유구하게 어렵지만 삶을 충실히 사는 비법인 것 같다. 둘을 구분하는 것도, 제어할 수 없다는 것을 인정하는 것도 참 쉽지가 않다.
"일단 동작하게 만들라" (중략) 개발자는 컴퓨터 소프트웨어를 이용해 문제를 해결하는 사람입니다. (중략) 제약조건을 극복하고 제대로 동작하는 코드를 제때 만들어야 합니다. p231
→ 동작 = 제약조건 극복 + 계획대로 동작 + 제시간 안에
어떤 코드가 더 좋은 코드일까요? (중략) 가독성, 성능, 유연성입니다. p232
가독성(좋은 관행, 재귀와 대칭, 단순 명료) >> 성능 >> 유연성
→ 다른 사람도 보기 좋은 코드가 미래의 내가 보기 좋은 코드다...
(기술 부채) 이때도 먼저 구현 코드와 무관한 E2E 테스트를 작성하고, 이를 기반으로 단위 테스트가 가능한 코드로 천천히 조금씩 리팩터링해나가야 합니다. (중략) 시스템 전반에 걸쳐 테스트를 확보하는 것이 중요합니다. (=관리 가능한 부채로 만들어라) p241
→ 간단한 프로젝트를 진행해도, 일단 동작하게 만들다보니 단위 테스트를 놓치는 경우가 많다. 문제는, 그렇게 만들어놓고 나면 테스트하기 좋지 않은 부분이 너무 많아서 (의존성 문제 / 데이터의 형태 문제 등) 늘 테스트 코드 작성을 미루게 된다. api 테스트는 늘 진행하지만, 그걸 단위 테스트 가능한 코드로 리팩터링하는 건 너무 어려운 것 같다... 아우우우...
바퀴를 계속 만들다 보면 애초에 바퀴가 필요 없었다는 사실을 깨닫게 될 수도 있고, (중략) 대부분은 기존에 쓰던 바퀴와 큰 차이가 없거나 더 나빠졌을 겁니다. 그럼에도 불구하고 바퀴에 대해서 더 잘 알게 됐다는 것은 분명합니다. p245
이것 외에도 발췌해둔 부분이 좀 더 있는데, 코드 예시와 도표 부분이거나 CS 이론, 도서 추천이라 노션에 개인적으로 따로 적어두었다. 우연히 발견해서 읽은 책이었는데 꽤 수확이 있었다. 간만에 속도감 있게 책 읽었네.