이펙티브 엔지니어

 

알라딘 중고서점에서 우연히 찾은 책인데, 우연히라고 하기에는 유명했고 좋은 내용이 가득있어서 왜 이제서야 발견했나 싶은 책이다.

훌륭한 엔지니어로써 어떻게 해야 하는지, 어떻게 성장해야 하는지 시중에 나와있는 책들을 어느정도 봐서 그런지 특별할껀 없지만, 그렇기에 대부분의 책에서 공통적으로 얘기하는 부분들만 잘 내것으로 만든다면 나도 꽤 좋은 엔지니어가 될 수 있지 않을까 한다. 물론 글로 접하는 말은 쉬워 보이기도 하고 읽는 것만으로 내 것 인것 같지만, 실제로 수행하고 그것을 계속 일관되게 유지하는것은 쉬운 일은 아니니까...그리고 한편으로 꽤 많은 연차를 보냈음에도 부족하다고 생각되는 면에 대해서도 부끄럽기도 하다.

 

정말 좋은 말이고 공감되는 내용들만 정리했는데도 분량이 많은데, 이 책에 아직 남아있는 내용이 많으니 꼭 읽어보길 추천한다.

 

레버리지가 높은 활동에 집중하라

# 멘토가 해야 할 일
코드 리뷰해주기, 배워야 할 기술 개괄적으로 알려주기, 페어 프로그래밍 세션 진행하기, 기술의 트레이드오프 알려주기, 업무 우선순위를 잘 설정하는 방법 설명해주기, 필요한 팀원 소개하기, 다른 팀원들과 원만하게 협업하는 방법 지도하기 등 온갖 항목이 포함된다.
신입 개발자가 회사 시스템에 익숙해지도록 초반에 해야 할 업무와 프로젝트의 순서를 계획해주는 것도 멘토의 몫이다.

# 레버리지를 효과성의 측정 기준으로 삼아라
레버리지는 투입한 노력에 대한 투자 자본 수익률(ROI)이다. 이펙티브 엔지니어는 더 오랜 시간을 일해서 더 많은 일을 하려는 사람이 아니다. 업무를 효율적으로 완수하고, 제한된 시간에 더 많은 가치를 생산한다. 공식의 분모를 낮게 유지하면서 분자를 높이려고 노력하는 것이다. 즉, 레버리지는 여러분의 활동이 얼마나 효과적인지를 측정하는 기준이다. 
레버리지가 매우 중요한 이유는 시간이 가장 제한적인 자원이기 때문이다. 시간은 다른 자원과 달리 저장, 확장, 대체가 불가능하다.

# 레버리지를 늘리는 세 가지 방법
1. 특정 활동을 완료하는데 드는 시간 줄이기 
    - 이 활동을 더 짧은 시간에 완료하려면 어떻게 해야 할까?
2. 특정 활동의 생산량 늘리기
    - 이 활동으로 생산되는 가치를 증가시키려면 어떻게 해야 할까?
3. 레버리지가 높은 활동으로 전환하기
    - 이 시간을 투자해 더 큰 가치를 생산할 수 있는 다른 활동이 있을까?

 

근무 환경의 핵심요소

# 성장 마인드셋을 갖춰라
성장 마인드셋을 가진 이들은 자신의 지능과 기술을 노력으로 기르고 성장시킬 수 있다고 믿는다.

# 자신의 학습률에 투자하라
매일 딱 1% 발전하고 이를 다음 성장의 기반으로 삼는다고 생각해보라. 이는 극적인 효과를 보이며 1년 후 우리를 365%(3.65배)가 아닌 37배 성장시킬 것이다.

# 학습에 도움이 되는 근무 환경을 찾아라
1. 빠른 성장
   - 로켓에 탈 기회가 생긴다면 어떤 자리인지 묻지 말고 일단 타라

* 핵심 사업 지표(활성 사용자, 연간 고정 매출, 제품 판매량 등)의 주간 또는 월간 성장률은 얼마인가?
* 회사는 여러분이 맡은 프로젝트를 성장시키기 위해 충분히 지원해 주는가? 
  맡은 프로젝트가 회사로부터 지원받는 우선순위가 높은 프로젝트인가?
* 지난해 회사나 팀이 얼마나 적극적으로 인력을 충원했는가?
* 뛰어난 팀원이 얼마나 빨리 리더의 자리에 오르는가?

2. 교육
   - 훌륭한 온보딩 프로그램이 있다는 건 조직이 신입 개발자 교육을 중요하게 생각한다는 증거다.

* 신입 개발자가 스스로 문제를 해결해야 하는가? 아니면 공식적인 신입 개발자 온보딩 절차가 준비되어 있는가?
* 공식적인 또는 비공식적인 멘토링이 존재하는가?
* 회사는 팀원이 계속 학습하고 성장하는 것을 보장하기 위해 어떤 조치를 하는가?
* 팀원들이 최근 새롭게 배운 것은 무엇인가?​

3. 개방성
   - 질문을 장려하는 호기심의 문화, 피드백과 정보를 사전에 공유하는 개방적인 문화를 추구하라. 실패한 프로젝트 반성하기, 서비스를 중단한 원인 알아내기, 제품별 투자 자본 수익률 검토하기는 모두 올바른 교훈을 체득하는 데 도움이 된다.

* 직원들은 다른 팀이 집중하고 있는 우선 과제가 무엇인지 알고 있는가?
* 팀끼리 만나서 과거에 수행한 제품을 수정하거나 기능을 출시하는 일이 수고할 만한 가치가 있었는지 재검토하는가? 
  서비스 중단 이후에는 사후 분석을 실시하는가?
* 회사 내에서 지식이 어떻게 기록되고 공유되는가?
* 팀이 배운 교훈의 예는 무엇인가?​

4. 속도
   - 최선을 다하되 장기적으로 지속 가능한 속도를 찾아야 한다.

* 빠른 속도가 회사의 가치나 엔지니어링 가치로 인정받는가?
* 개발 주기 속도를 높이기 위해 팀에서는 어떤 도구를 쓰는가?
* 아이디어 구상부터 출시 승인까지 시간이 얼마나 걸리는가?
* 새로운 제품과 기능을 개발하는 시간과 유지 보수하는 시간의 비율은 어느 정도인가?​

5. 사람
   - 경력 성장과 업무 만족도 면에서 볼 때 어떤 사람과 일하느냐가 무슨 일을 하느냐보다 더 중요할 수 있다.

* 면접관이 여러분보다 똑똑해 보이는가?
* 그들에게 배울 만한 기술이 있는가?
* 면접이 엄격하고 포괄적이었는가? 면접관과 잘 지낼 만한 사람들과 함께 일하고 싶은가?
* 1인 프로젝트가 많은가? 아니면 팀워크와 협력을 중요시하는가?​

6. 자율성
   - 우리의 학습 능력은 어떤 일을 어떻게 할지 선택할 수 있는 자유가 주어지고, 자유를 효과적으로 활용하는 데 필요한 지원이 뒷받침될 때 발휘된다. 업계에 입문한 초기에는 온보딩과 멘토링이 더 중요하고, 나중에는 자율성이 더 중요해진다.

* 직원들은 어떤 일을 어떻게 할지 자율적으로 선택할 수 있는가?
* 직원들이 팀이나 프로젝트를 얼마나 자주 바꾸는가?
* 한 직원이 1년간 작업할 수 있는 코드베이스의 규모는 어느 정도인가?
* 개발자들이 제품 설계 관련 논의에 참여하고 제품 방향에 영향을 미치는가?​

 

# 근무 시간을 활용해서 새로운 기술을 발전시켜라
자신의 성장에 투자하려면 스스로 20%의 시간을 개척해야 한다. 20%의 시간이 생겼다면 무엇을 해야 할까? 이미 작업 중인 분야나 사용중인 도구에 대해 더 깊이 이해하면 좋다

* 회사에서 가장 뛰어난 개발자가 작성한 코어 추상화 코드를 연구하라
* 더 많은 코드를 작성하라
* 내부에서 제공되는 기술 교육 자료를 꼼꼼히 살펴보라
* 자신이 사용하는 프로그래밍 언어를 마스터하라
* 코드 리뷰는 가장 혹독한 리뷰어에게 부탁하라
* 발전하고 싶은 분야에 관한 수업을 수강하라
* 관심 있는 프로젝트 설계 논의에 참여하라
* 다양한 프로젝트에 참여하라
* 보고 배울 만한 것이 있는 시니어 개발자가 최소한 몇 명 이상 되는 팀에 머물러라
* 모르는 코드에 용감하게 뛰어들어라​

# 항상 배워라

* 새로운 프로그래밍 언어와 프레임워크를 배워라
* 수요가 많은 기술에 투자하라
* 책을 읽어라
* 토론 그룹에 참여하라
* 강연, 컨퍼런스, 모임에 참여하라
* 강력한 인맥 네트워크를 구축하고 유지하라
* 엔지니어링 정보를 공유하는 블로그를 팔로우하라
* 블로그를 개설해 설명하고 가르쳐라
* 사이드 프로젝트를 하라
* 좋아하는 것을 추구하라​

 

우선순위를 정기적으로 점검하라

# 할 일 목록의 우선순위
할 일 목록이 갖춰야 할 주요 속성은 두가지다. 자신의 업무를 정식으로 대표하는 목록이어야 하고, 쉽게 접근할 수 있어야 한다. 해야 할 일을 일관되게 목록에 적으면 기억해야 할 일은 단 한가지, 마스터 목록 확인하기 뿐이다.
레버리지를 정확히 계산할 수 있다면 레버리지에 따라 정렬하면 끝이다. 그러나 안타깝게도 각 업무에 필요한 시간과 업무가 생산할 가치는 예측하기 매우 어렵다. 결국 우선순위를 매긴 목록을 만들기 위해 추정에 쏟아부은 그 많은 시간이 낭비된 셈이다. 100번째 업무의 레버리지가 101번째 업무보다 높다는 것을 알아내는건 실제로 그다지 유용하지 않다. 
현재 수행중인 일과 할 일 목록에 있는 다른 일을 쌍으로 비교하는 것이 훨씬 더 쉽고 효율적이다. 
자신에게 레버리지가 더 높은 다른 할 일이 있을지 반복해서 물어라. 답이 '없다'라면 가던 경로를 계속 가면 된다. '있다'라면 지금 하고 있는 일을 다시 생각해야 하는 순간이다.
목표는 모든 우선 과제를 완벽한 순서로 정렬하는 것이 아니다. 그 대신 가지고 있는 정보를 바탕으로 최우선 과제를 레버리지가 가장 높은 업무로 끊임없이 전환하라.

# 직접적으로 가치를 생산하는 일에 집중하라
레버리지가 높은 활동을 우선 과제로 삼기 위한 첫 번째 휴리스틱은, 직접적으로 가치를 생산하는 일에 집중하는 것이다. 무엇이든 결과로 이어지는 일을 하라.
거절하는 법을 배워라. 요청 받은 모든 일을 의무라고 생각하지 마라. 우선순위를 높일 이유가 없다면 거기에 시간을 쓸 이유 또한 없다.
모든 것을 하려고 하지 마라. 중요한 것에 집중하라. 가치를 생산하는 것이 중요하다.

# 중요하지만 급하지 않은 일에 집중하라
직업적 목표 계획하기, 강력한 인맥 구축하기, 전문성 향상을 위해 책과 기사 읽기, 생산성과 효율성을 높이는 새로운 습과 기르기, 작업 흐름을 개선할 도구 만들기, 유용한 추상화에 투자하기, 인프라 꾸준히 확장하기, 새로운 프로그래밍 언어 배우기, 컨퍼런스에서 발표하기, 팀원들의 생산성 증진을 위해 멘토링하기 등이다.

# 생산자의 일정을 보호하라
개발자는 다른 직종에 비해 더 길고 연속적인 시간 블록(몰입)이 확보되어야 생산성이 높아진다. 가능하면 일정에 집중하는 시간 블록의 길이를 최대한 길게 유지하라. 참석하지 않아도 되는 회의, 우선순위가 낮은 약속처럼 자신의 일정을 짧게 쪼개 놓을 수 있는, 중요하지 않은 활동을 거절하는 법을 배워라. 자신의 일정, 그리고 자신과 함께하는 생산자의 일정을 보호하라.

# 동시에 진행할 작업의 양을 제한하라
끊임업는 맥락의 전환은 어느 하나의 활동에도 제대로 집중하지 못하게 방해하고 전체적인 성공 가능성을 감소시킨다. 소규모 그룹 사람들의 노력이 너무 많은 업무에 걸쳐 흩어지면 설계 논의나 코드 리뷰에 있어서 동일한 맥락이 공유되지 않는다.

# 우선순위를 정하는 자신만의 루틴을 만들어라
회고를 통해 우선순위를 재정비하는 습관을 길러라. 우선순위를 정하는 '최고'의 작업 흐름은 없다.
자신에게 잘 맞는 방법을 찾을 때까지 시행착오를 반복하여 자신만의 시스템을 만들어야 한다. 고유한 시스템을 갖추지 못했다면 생산성 관련 도서를 참고하거나 다른 개발자의 시스템을 활용하는 것이 출발점이 될 수 있다. 어떤 메커니즘을 써서 우선순위를 검토하는지보다 우선순위를 검토하는 습관을 들이는 것이 더 중요하다.

 

반복 속도에 투자하라

# 지속적 배포
지속적 배포라는 도구가 이토록 강력한 이유는 무엇일까? 근본적인 변화가 일어나기 때문이다. 지속적 배포 시스템을 갖추면 일괄적인 대규모 변경을 꾀하는 일반적인 회사와 달리 점진적으로 소규모로 변경을 수행하고 배치할 수 있다. 접근법이 달라지면 전통적인 배포 프로세스에 드는 상당한 간접 비용이 사라질 뿐 아니라 변경사항에 대한 추론이 더 쉬워지고 개발주기 반복 속도도 훨씬 빨라진다.
변경사항이 더 작은 작업 단위로 이루어지면 문제를 발견하고 디버깅하는 것도 쉬워진다.

# 빨리 배우려면 빨리 움직여라
개발 주기를 빠르게 반복할수록 무엇이 더 효과적인지 더 많이 배울 수 있다. 개발 주기의 반복 속도에 대한 투자가 왜 그토록 레버지리가 높은 결정인지 보여준다. 빠르게 움직이면 더 많은 것을 만들고 더 빨리 배울 수 있습니다. 하지만 대부분의 회사는 성장과 함께 너무 느려집니다. 너무 느리게 움직이느라 기회를 잃는 것보다 실수를 저지르는 것을 더 두려워하기 때문입니다. 실수가 하나도 없다는 건 움직이는 속도가 느리다는 뜻일 수 있습니다.

# 시간 절약 도구에 투자하라
만약 수동으로 두 번 이상으로 해야 하는 일이 생기면 세 번째에는 도구를 작성하라.
작게 시작하라. 도구로 시간을 절약할 수 있는 영역을 찾아서 도구를 만들고 그 가치를 증명하라. 조금 더 도전적인 길을 탐색해볼 자율권이 생길 것이고, 그 도구로 인해 앞으로 조금 더 효율적으로 일하게 될 것이다.

# 디버깅과 검증 과정을 단축하라
버그를 수정하거나 기능을 개발하는 중인데 문득 똑같은 동작을 반복하고 있다는 것을 깨달았다면 잠시 멈춰라. 그리고 테스트 과정을 더 짧게 만들 수 없을지 잠시 생각할 시간을 가져라. 이렇게 하면 장기적으로 시간이 절약될 것이다.

# 프로그래밍 환경을 마스터하라
좋아하는 텍스트 에디터와 IDE를 능숙하게 다뤄라.
생산적이고 수준 높은 프로그래밍 언어를 적어도 하나는 배워라.
유닉스나 윈도우의 쉘 명령에 익숙해져라.
마우스보다 키보드를 우선 사용하라.
수동 작업 흐름을 자동화하라.
변경사항과 관련 있는 단위 테스트를 빠르게 쉽게 실행할 수 있게 하라.

# 엔지니어링 외적인 병목을 무시하지 마라
이펙티브 엔지니어는 가장 큰 병목이 코드 작성과 관련이 없거나 안전지대를 벗어난 영역에 있더라도 이를 찾아내서 해결한다. 병목이 흔히 발생하는 지점은 타인에게 의존하는 부분이다. 소통은 사람과 관련 있는 병목을 개선할 때 대단히 중요하다. 프로젝트는 소통이 지나칠 때가 아니라 부족할 때 실패한다. 
또 다른 병목 유형은 리뷰 프로세스로, QA 팀의 검증, 성능 팀의 확장성이나 안전성 리뷰, 보안 팀의 감사 등 어떤 프로젝트에나 수반되는 것들이다. 출시 체크리스트 요구사항을 충실히 지키고 리뷰 일정을 마지막까지 미루지 마라. 다시 말하지만 리뷰 프로세스가 병목이 되지 않게 막는 열쇠는 소통이다.
자신의 개발 주기에서 가장 중대한 병목이 어디인지 알아내라. 엔지니어링 도구인가, 다른 팀에 대한 의존성인가, 의사 결정권자의 승인인가? 알아내서 그 부분을 최적화하라.

 

개선하려는 사항을 측정하라

# 지표를 활용해서 발전을 주도하라
좋은 지표는 여러 면에서 도움이 된다.
첫째, 올바른 대상에 집중하게 해준다. 변경사항과 이를 위해 쏟아부은 모든 노력이 목표 달성에 실제로 도움이 되는지 확인해준다. 목표와 관련한 지표를 정의하고, 변경사항이 미친 영향을 측정하는 것이다.
둘째, 좋은 지표를 시간 경과에 따라 시각화하면 향후 발생할 회귀 버그를 방지하는 데 도움이 된다.
셋째, 좋은 지표는 발전을 주도한다.
넷째, 좋은 지표는 시간이 흐르는 동안 효율성을 측정하고, 현재 하는 활동과 그 대신 할 수 있었던 활동을 비교할 수 있게 해준다.

# 원하는 행동을 장려하려면 올바른 지표를 골라라
측정할 대상을 선택하는 건 측정 자체만큼이나 중요하다. 어떤 지표를 선택하느냐가 어떤 작업을 할지에 큰 영향을 미친다는 것을 명심하자. 올바른 지표는 팀의 노력을 공통의 목표에 맞추는 북극성 역할을 한다.

* 주당 근무 시간 vs 주당 생산성
주당 근무 시간을 늘려서 생산량을 늘리려는 시도는 지속가능하지 않다. 
관심 영역에서의 생산성을 제품 품질, 사이트 속도, 사용자 성장 같은 요소로 측정하고, 
주당 생산성에 맞춰서 지표를 정하는 것이 훨씬 더 합리적이다.

* 평균 응답 시간 vs 95 또는 99 백분위수 응답 시간
평균을 낮추려면 모든 요청의 응답 시간을 1/1000초 단축하도록 일반적인 인프라 개선에 더 집중해야 한다. 
전체 연산 시간을 줄여서 서버 비용을 낮추는 것이 목표라면 평균이 적절한 지표다. 
그러나 95 또는 99 백분위수 응답을 줄이려면 가장 나쁜 동작을 시스템에서 찾아내야 한다. 
즉, 이 경우에는 가장 느린 응답에 집중해야 한다. 
가장 느린 응답은 파워 유저의 경험을 반영하는 경향이 있기 때문이다.

* 등록한 사용자 수 vs 등록한 사용자의 수의 주간 성장률
주간 성장률(예를 들면 등록한 전체 사용자 대비 일주일 간 새로 등록한 사용자 비율)로 성장을 측정하면 
성장 속도가 둔화되고 있는지 여부를 확인할 수 있다.

* 주간 활성 사용자 vs 가입 기간별 주간 활성 사용자
가입 후 n주차에도 여전히 활성화된 사용자를 주 단위로 측정하는 것이다. 
이 지표는 제품의 변화가 기존 사용자 집단에 비해 
새로운 사용자 집단의 참여에 어떤 영향을 미쳤는지, 보다 실행 가능한 통찰을 제공한다.​

제품과 목표가 복잡할수록 무엇을 측정하고 무엇을 측정하지 말아야 할지 선택지가 늘어나고, 어디에 노력을 기울일지 어떤 결과를 생산할지 고민할 범위가 넓어진다. 지표는 1) 가장 큰 효과를 내고, 2) 실행하기 좋으며, 3) 즉각 반응하되 견고한 것으로 정해야 한다.
허무 지표가 증가하면 제품이 발전했다는 뜻일 수는 있으나 그렇다고 해서 팀이 꼭 일을 잘했다는 뜻은 아니다.

# 현재 상황을 파악하려면 모든 것을 계측하라
목표를 세울 때는 어떤 핵심 지표를 측정하고(또는 측정하지 않고) 최적화할지 신중하게 고르는 것이 중요하다. 그러나 일상적인 업무에 관해서라면 대상을 가리지 않고 최대한 많이 측정하고 계측하는 것이 좋다. 이 두가지 원칙이 서로 모순되는 것처럼 보일지 모르나 실제로는 서로를 보완하는 역할을 한다. 첫 번째 원칙은 높은 수준에서 전체 활동을 설명하는 데 필요하고, 두 번째 원칙은 자신이 만든 시스템의 현재 상황을 통찰하는 데 필요하다.
핵심 지표를 효과적으로 최적화하려면 이를 뒷받침하는 다른 많은 지표를 체계적으로 측정해야 한다.

# 데이터 무결성을 의심하라
사람들은 데이터를 해석하고 싶은대로 해석한다.
지표에 관한 한 자신의 직감이 수치와 일치하는지 비교하라. 다른 방향에서도 똑같은 데이터에 이를 수 있는지 시도해보고 그때도 그 지표가 여전히 타당한지 확인하라. 지표에서 다른 속성이 엿보인다면 해당 속성을 측정해서 결론에 일관성이 있는지 확인하라.
데이터를 신뢰할 수 있게 만들라. 데이터가 없는 것보다 데이터가 올바르다는 착각이 더 나쁘다.

 

아이디어는 일찌 그리고 자주 검증하라

자신의 작업을 적는 노력으로 검증할 방법을 찾아라
발전을 방해하는 위험한 문제를 더 일찍 제대로 파악할수록 더 빨리 문제를 해결해서 성공 가능성을 높이거나 조금 더 유망한 경로로 방향을 전환할 수 있다.  최소 기능 제품(MVP, Minimum Viable Product)을 만들 때는 최소의 노력으로 제품의 성공 가능성을 최대로 높일 수 있게 사용자에 관한 가정을 가능한 한 많이 검증할 수 있는, 레버리지가 높은 활동에 집중해야 한다. 적은 노력을 투자해서 프로젝트 가정과 목표를 검증할 데이터를 모아라.

A/B 테스트로 제품 변경사항을 꾸준히 검증하라
A/B 테스트라는 실험은 이러한 효과를 구분하고 효과를 낸 요인이 무엇인지 검증하는 강력한 도구다. A/B 테스트는 출시할 변경사항을 정할 때만 도움이 되는 것이 아니다. 특정 변경사항이 지표를 개선할 거라고 절대적으로 확신하는 상황에서도 유용하다. 그 변형이 실제 얼마나 더 나은지 알려주기 때문이다. 얼마나 개선될지 정량화하면 같은 분야에 계속 투자하는 것이 합리적인지 확인할 수 있다.
A/B 테스트는 이론을 검증하고 개발 주기를 반복하면서 효과를 내는 변경사항을 찾아가는 반복적인 제품 개발 방식을 장려한다.
A/B 테스트 대상을 정할 때는 시간이 가장 제한적인 자원이라는 점을 기억하라. 레버리지가 높고 실질적으로 큰 의미를 지니며, 자기 회사에 실제로 중요한 차이를 내는지 파악하라. A/B 테스트는 제대로 수행하면 제품 아이디어를 검증하고, 있는 그대로는 이해할 수 없는 사용자 행동 데이터라는 블랙박스를 이해하고 실행할 수 있는 지식으로 변환하는 데 도움이 된다. 제품 변경사항을 반복해서 검증하게 해줄 뿐 아니라 시간과 노력을 효과적으로 소비하며 목표 달성을 향해 올바른 경로로 가고 있는지도 확인시켜 준다.

1인 팀을 주의하라

* 피드백을 개방적으로 수용하라.
피드백과 비판을 개인적인 공격이 아닌 발전의 기회로 보라.

* 코드를 일찍, 자주 커밋하라.

* 코드 리뷰를 철저한 비평가에게 부탁하라.
무언가 제대로 작동하지 않는다는 혹독한 비평은 사용자보다 동료에게 미리 받는 것이 낫다.

* 팀원들에게 아이디어에 대한 반응을 요청하라

* 새로운 시스템의 인터페이스나 API부터 설계하라.

* 코드에 에너지를 쏟기 전에 설계 문서를 공유하라.

* 최대한 팀원들과 맥락을 공유할 수 있게 프로젝트를 구조화하라.

* 논란의 여지가 있는 기능이라면 너무 많은 시간을 투자하기 전에 승인을 요청하라.
해당 도메인을 이해하고 있는 사람들에게 승인을 얻지 못한다면 잘못된 경로로 가고 있다는 뜻일지 모른다.​

의사 결정을 위한 피드백 과정을 구축하라
개발자의 직급이 올라갈수록(특히 관리직을 맡을수록) 의사 결정이 점점 더 어려워지고 모호해진다. 팀의 업무를 어떻게 조직해야 할까? 팀의 기술 부채를 줄이기 위해 기능 개발을 잠시 멈출(또는 멈추지 않음) 여력이 있을까? 업무 평가와 피드백은 어떻게 이루어져야 할까? 익명으로, 직접적으로, 아니면 공개적으로? 직원 채용이나 유지를 개선하려면 보상구조를 어떻게 조절해야 할까?
업무의 모든 측면에 피드백 과정을 만들어야 한다. 피드백 과정이 없으면 그냥... 추측하는 것이다.

 

프로젝트 추정 기술을 향상시켜라

프로젝트 추정 기술
프로젝트 추정은 이펙티브 엔지니어가 익혀야 할 어려운 기술 중 하나다. 그러나 숙달하는 것이 중요하다. 기업이 제품에 대해 장기적인 계획을 세우려면 정확한 추정이 필요하다. 언제 자원을 확보하여 다음 기능 작업에 돌입할 수 있는지 또는 요청받은 기능의 완료 계획을 고객에게 언제 알려줄 수 있는지 알아야 한다. 기한에 맞춰 배포해야 한다는 압박이 없을 때도 프로젝트에 얼마의 시간이 들어가느냐는 어떤 작업을 할지 결정하는 데 영향을 미친다.

정확한 추정치를 활용하여 프로젝트 계획을 추진하라
목표에 맞춰 추정을 수정하다가 프로젝트 일정이 지연되기도 한다.
추정을 반복해서 수정하면 프로젝트 결과물이 나아질 수 있다.

* 프로젝트를 더 작은 작업으로 분해하라.

* 자신 또는 누군가가 원하는 작업 시간 말고, 작업에 실제로 드는 시간을 기준으로 추정하라.

* 추정을 최상의 시나리오가 아닌 확률 분포로 생각하라.
제품 관리자를 비롯한 다른 이해관계자에게 어떤 기능을 6주 이내에 완성하겠다고 말하기보다 
"이 기능을 지금부터 4주 이내에 완성할 가능성이 50%이고, 8주 이내에 완성할 가능성은 90%입니다" 라고 말하는 것이 좋다.

* 실제 업무 담당자가 추정하게 하라.

* 기준점 편향에 주의하라
낮은 추정치가 초기에 기준점으로 자리 잡으면 나중에 더 정확한 추정치를 설정하기 어려우므로 
관련 작업의 윤곽을 짜기 전에는 수치를 이야기하지 마라.

* 하나의 업무를 여러 방법을 사용해 추정하라.

* 이상적인 인월을 조심하라
사람과 시간을 호환할 수 있다는 근거 없는 믿음이 생긴다. 
한 여성이 아홉 달 안에 아이를 낳을 수 있다고 해서 9명의 여성이 한 달 안에 아이를 낳을 수 있는 것은 아니다. 
새로운 팀원이 프로젝트에 적응해서 생산성을 내기까지는 시간이 걸리므로 인원을 추가한다고 해서
프로젝트 타임라인이 단축된다고 생각하지 마라.

* 기존 데이터로 추정치를 검증하라

* 범위가 커질 수 있는 작업을 타임 박스(time box)로 제한하라
조사에 3일 정도 걸린다고 추정하지 말고, 3일 이내에 찾은 데이터를 기반으로 최선의 결정을 내리려고 노력하라.

* 다른 이들이 추정에 이의를 제기하도록 허용하라

미지의 변수를 고려하라
추정한 작업 시간을 달력상의 시간과 분리하는 것이다. 
'작업을 완료하기까지 1개월이 걸릴 것이다'라는 말을 '한 달 이내에 완료될 것이다'라는 뜻으로 해석하면 안된다. 
이상적인 1일 치 엔지니어링 업무를 일상적인 방해 요소를 감안해서 근무일 2일로 계산한다.

구체적인 프로젝트 목표와 측정 가능한 마일스톤을 정의하라
명확한 문제를 바탕으로 명확한 목표를 표현하는 것.
첫번째 혜택, 잘 정의해둔 목표는 작업 목록에서 꼭 해야 할 일과 하면 좋은 일을 구분하는 중요한 필터.
두번째 혜택, 핵심 이해 관계자들 사이에 명확성과 공통의 이해가 형성된다는 것.
구체적인 목표를 정의하는 것보다 더 효과적인 것은 목표 달성을 위해 측정할 수 있는 마일스톤을 세우는 것이다.

위험은 초반에 감소시켜라
프로젝트를 효과적으로 실행한다는 것은 기한을 늦출 만한 위험을 최소화하고 예상치 못한 문제를 최대한 초반에 알아낸다는 뜻이다.
문제가 예상보다 어렵다는 것이 뒤늦게 밝혀지는 것보다는 차라리 일찌감치 문제를 찾아내서 목표 기한을 조정하는 것이 낫다.
통합 위험을 줄이는 방법) 초기에 종단 간 테스트를 위한 틀을 만들고 시스템을 테스트. 불완전한 기능과 모듈을 제거하고 최대한 빨리 종단 간 시스템을 구성해서 테스트하라.

재작성 프로젝트는 매우 조심스럽게 접근하라
무언가를 바닥부터 재작성하려는 욕구는 소프트웨어 개발자의 아주 일반적인 특징이다. "두 번째 시스템은 인간이 설계한 가장 위험한 시스템이다."
시스템을 점진적으로 재작성하는 것은 레버리지가 높은 활동이다. 점진적인 방법을 활용하면 전체 작업량이 늘어날 수 있으나, 위험이 많이 감소하는 것을 고려하면 이런 단점을 감수할 만한 가치가 있다.

마라톤 중간에 전력 질주하지 마라
초과 근무한다고 해서 출시일이 지켜질지 보장할 수 없는 이유
    * 근무 시간이 늘어나면 시간당 생산성이 떨어진다.
    * 생각보다 일정이 더 지연됐을 수 있다.
    * 추가 근무 시간으로 인해 팀원들이 번아웃을 경험할 수 있다.
    * 추가 근무는 팀 내 역학 관계를 망가뜨릴 수 있다.
    * 마감 기한이 다가올수록 의사소통 간접 비용이 늘어난다.
    * 기한을 향한 전력 질주 때문에 기술 부채가 유발된다.
추가 근무해서 실제로 출시일을 지킬 현식적인 계획이 없는 한, 장기적으로 볼 때 최고의 전략은 목표 기한 내에 얼마나 완성할 수 있는지를 가늠해서 출시할 내용을 재정의하거나 더 현실적인 날짜로 기한을 미루는 것이다.
    * 지금까지 타임라인이 지연된 주요 원인을 모두가 이해하고 공유하라
    * 프로젝트 계획과 타임라인을 현실적으로 수정하라.
    * 프로젝트가 수정한 타임라인보다 더 지연된다면 전력 질주를 포기하라

 

품질과 실용주의 사이에서 균형을 유지하라

소프트웨어 품질
소프트웨어 품질은 결국 균형의 문제로 귀결되며, 어떻게 해야 한다고 규정된 하나의 보편적인 원칙은 존재하지 않는다. "옳고 그름의 관점에서 생각하는 것은 세상을 바라보기에 매우 정확하거나 유용한 프레임워크가 아니다. 나는 옳고 그름 대신에 효과가 있느냐 없느냐의 관점에서 대상을 보는 것을 선호한다. 그렇게 할 때 더욱 명확하고 효과적으로 의사 결정할 수 있다."

지속 가능한 코드 리뷰 프로세스를 만들어라
* 설계 결함이나 버그를 초기에 포착한다.
* 코드 변경사항에 대한 책임감이 강해진다.
* 좋은 코드 작성법을 배우는 모델로써 도움이 된다.
* 코드베이스에 관한 실용적 지식을 공유한다.
* 장기적인 작업 속도가 향상된다.

추상화를 통해 복잡성을 관리하라
올바른 추상화를 선택하면 프로그래밍이 설계부터 자연스럽게 흘러간다. 모듈 인터페이스는 작고 간단할 것이고 광범위한 개편이 없어도 새로운 기능이 잘 안착할 것이다. 잘못된 추상화를 선택하면 프로그래밍하는 동안 예상 밖의 문제가 줄줄이 일어난다. 인터페이스는 예상치 못한 인터랙션을 억지로 수용하기 위해 찌그러지거나 투박해질것이고 아주 간단한 변경조차 하기 어려워진다.
* 원래 문제의 복잡성을 이해하기 쉬운 원시 형태로 분해해준다.
* 애플리케이션 유지 보수에 드는 수고가 줄고 개선사항을 적용하기 쉬워진다.
* 어려운 문제를 한 번 해결하면 그 해결책을 여러 번 사용할 수 있다.
강력한 엔지니어링 팀은 추상화에 투자를 많이 한다. 특정 문제에 대한 추상화를 만들면 트레이드오프가 따른다. 일반적인 해결책을 만들려면 특정 문제에만 맞는 해결책을 만드는 것보다 더 많은 시간이 든다. 손해를 보지 않으려면 추상화를 제작하는 데 든 시간보다 추상화로 인해 절약되는 시간이 더 많아야 한다. 팀원들이 크게 의존하는 소프트웨어(로그 라이브러리나 사용자 인증 라이브러리 등)를 만들 때 그렇게 될 확률이 높으므로 코어 추상화를 훌륭하게 만드는 데 에너지를 집중하라.

좋은 추상화의 속성
* 배우기 쉽다.
* 문서가 없어도 사용하기 쉽다.
* 잘못 사용하기 어렵다.
* 요구 조건을 충족시킬 정도로 충분히 강력하다.
* 확장하기 쉽다.
* 대상 사용자에게 적합하다.

테스트를 자동화하라
엄격한 자동 테스트가 없다면 수동 테스트를 철저히 수행하는 데 드는 시간이 엄두도 못 낼 정도로 길어질 수 있다. 통합 테스트는 작성하고 유지 보수하기 어렵지만, 몇 개만 작성한다면 레버리지가 높은 투자다.
보통 첫 번째 테스트를 작성하는 게 가장 어렵다. 테스트를 작성하는 습관을 들일 효과적인 방법은 레버리지가 높은 테스트, 즉 작성하는 데 든 시간에 비해 많은 시간을 절약해주는 테스트에 집중하는 것이다. 가장 가치 있는 테스트부터 시작하여 한 걸음씩 전진하라.

기술 부채를 상환하라
분기를 마칠 때마다 관련 부채를 상환하는 'Polish Week' 일정과 내부 도구 관련 부채를 상환하는 'Grease Week' 일정을 잡아둔다.
안타깝게도 기술부채는 정량화하기 어려울 때가 종종 있다. 재작성에 드는 시간이 얼마이고 이를 통해 절약되는 시간이 얼마인지에 대한 확신이 부족하다면 작게 시작해서 점진적으로 풀어나가는 것이 좋다. 그러면 작업이 너무 복잡해질 위험이 줄어들고, 기술 부채는 상환할 가치가 있다는 것을 자신과 다른 사람에게 증명할 기회가 된다.

 

운영 부담을 최소화하라

운영 부담
매력적이거나 도발적인 신기술 대신 가능한 확고히 검증된 기술을 선택하라. 새롭게 추가하는 기술은 시간이 지나면서 조금씩 문제를 발생시키는 게 당연하다. 어느 순간 정신을 차리고 보면 팀 전체가 운영에 매달리고 있을 것이다.

단순하게 운영하라
엔지니어링 팀이 간단한 일부터 하는 데 집중하지 않으면 유지 보수 비용이 많이 드는 활동에 에너지를 쏟느라 시간이 지남에 따라 효율이 점점 떨어지거나, 운영 부담이 너무 커져서 아키텍처를 단순화할 수밖에 없는 상황에 처한다.
* 다양한 시스템에 관한 엔지니어링 전문 지식을 습득해야 한다.
* 복잡성이 증가하면 잠재적 단일 장애점(single point of failure)이 늘어난다.
* 신입 개발자가 새 시스템을 익히고 이해하기 어려워진다.
* 추상화, 라이브러리, 도구를 개선하는 데 드는 노력이 여러 시스템으로 분산되어 희석된다.

빨리 실패하는 시스템을 만들어라
시스템이 느리게 실패하면 코드 오류의 원인이 불분명해져서 어떤 문제가 일어난 것인지 알아내기 어려워진다. 버그와 소프트웨어 구성 오류는 불가피하게 발생하므로 문제를 재현하고 오류의 원인을 정확히 알아내는 데 시간을 투자해야 한다. 문제나 오류가 원인에 가까울수록 문제를 더 빨리 재현하고 해결할 수 있다. 빨리 실패하면 더 빠르고 효과적으로 문제를 드러내고 해결할 수 있다.
빠른 실패라고 해서 반드시 사용자가 사용 중인 프로그램을 종료시켜야 하는 건 아니다. 빨리 실패하기 기법을 활용하여 최대한 빨리 문제를 드러내고 오류의 실제 원인에 가깝게 접근하고, 사용자 측에서는 우아하게 실패하는 동안 개발자에게 오류를 보고하는 방안으로 보완이 가능하다.

기계적인 작업을 꾸준히 자동화하라
자동화해야 할지 결정할 때는 이렇게 자문하라.
이 작업을 수동으로 하는 것, 이 작업을 자동화하기 위한 비용을 선불로 내는 것, 둘 중 어느 쪽을 택했을 때 전체적으로 시간이 더 절약될까?
자동화가 필요한 만큼 이루어지지 않는 몇 가지 이유
* 지금 당장 시간이 없다.
* 공유지의 비극이 일어난다. (자동화를 위해 나설 동기나 의지가 감소)
* 자동화 도구에 익숙하지 않다.
* 향후 작업 빈도를 과소평가한다.
* 장기적으로 볼 때 시간이 얼마나 절약되는지 체감하지 못한다.

일괄 처리를 멱등성 있게 만들어라
일괄 처리를 '유지 보수하기 쉽고 실패 회복력이 더 뛰어나게' 만드는 한가지 기법은 이를 멱등성(idempotent) 있게 만드는 것이다.

 

팀의 성장에 투자하라

팀워크
강력한 팀과 긍정적인 문화를 구축하는 것이 상당히 레버리지가 높은 활동임을 인식하는 것이 중요하다.
업계에 입문한 초기부터 동료의 성공을 돕는 방법을 고민한다면 후일 스스로 성공을 거머쥘 올바른 습관을 기르는 셈이다.
직업적 성공은 회사와 팀의 성공에 크게 좌우되며 개인적인 기여만으로는 회사나 팀이 성공할 수 없다. 주변에 있는 이들이 우호적인 태도로 여러분과 뜻을 함께할 때 훨씬 더 많은 것을 성취할 수 있는데 그런 환경을 조성하는 열쇠는 그들의 성공에 투자하는 것이다.

여러 직위가 지니는 의미
그 사람의 존재로 인해 팀이 전체적으로 나아진다면 책임 개발자다.
그 사람의 존재로 인해 회사가 전체적으로 나아진다면 수석 개발자다.
그 사람의 존재로 인해 업계가 더 발전한다면 최고 개발자다

채용을 모두의 책임으로 만들어라
좋은 면접 절차는 두 가지 목표를 달성한다. 
1. 회사에 잘 적응할 것 같은 유형의 지원자를 선별한다.
2. 지워낮가 회사, 회사에서 맡을 임무, 회사의 문화에 매력을 느끼게 한다.
면접관의 목표는 신호 대 잡음 비율이 높아지도록 질문을 최적화하는 것이다. 소비한 시간에 비해 관련 없거나 쓸모 없는 데이터(잡음)가 거의 없이 지원자에 관한 유용한 정보(신호)를 많이 밝혀내는 질문을 던진다는 뜻이다. 가장 많은 신호를 생성하는 질문의 유형은 해당 팀의 성공과 가장 관련있는 자질이 무엇이냐에 따라 달라진다.
모든 기술이 그렇듯이 면접과 채용을 더 효과적으로 진행할 수 있는 방법도 반복과 연습뿐이다.

온보딩 절차를 훌륭하게 설계하라
팀의 성공을 향한 투자가 자신의 성공 가능성도 높여준다. 신입 개발자의 성장을 효과적으로 도우면 궁극적으로 레버리지가 더 높은 활동을 선택할 수 있는 유연성이 생긴다.
온보딩 절차를 통해 달성할 네가지 목표
1. 최대한 빠르게 신입 개발자 적응시키기
2. 팀의 문화와 가치 전달하기
3. 신입 개발자가 성공에 필요한 폭넓은 기초 지식 접하게 하기
4. 신입 개발자를 사회적으로 통합시키기

코드 소유권을 공유하라
소유권을 더 많이 공유하려면 자신이 작성한 코드나 도구를 다른 팀원들이 탐색하고 이해하고 수정할 때 발생하는 마찰을 줄여야 한다.
* 1인 팀을 피하라
* 서로의 코드와 소프트웨어 설계를 리뷰하라.
* 팀 내에서 여러 유형의 업무와 책임을 돌아가며 맡아보라.
* 코드의 가독성과 품질을 높게 유지하라.
* 소프트웨어 의사 결정과 아키텍처에 관한 기술 강연을 열어라.
* 자신이 만든 소프트웨어를 문서화하라. 높은 수준의 설계 문서도 좋고, 코드 수준의 주석도 좋다.
* 업무를 완수하는 데 필요한 복잡한 작업 흐름, 명확하지 않은 우회로를 문서화하라.
* 다른 팀원의 교육과 멘터링에 시간을 투자하라.

사후 분석으로 집단 지성을 구축하라
팀이 얻은 교훈을 기록하려면 솔직한 대화가 바탕이 되어야 하는데, 프로젝트에 관해 솔직하게 대화하는 것이 불편할 수 있다. 몇 개월간의 노력이 실패로 돌아갔을지 모른다는 것을 인정하고 실패를 성장의 기회로 보아야 한다. 책임 소재를 따지는 데 집중하지 말고 제품과 팀으르 발전시키겠다는 공동의 목표에 대한 공감대가 형성되어야 한다. 무엇이 잘못됐고 무엇을 더 잘할 수 있었는지 집단 지성을 구축하겠다는 목표를 가지고 열린 자세로 피드백을 수용해야 한다. 한 시간 동안 나눈 힘겨운 대화가 다음 한 달간 진행할 팀 프로젝트의 성공 가능성을 높인다면 시간과 감정을 투자할 가치가 있는 레버리지가 높은 활동이라고 볼 수 있다.

훌륭한 엔지니어링 문화를 구축하라
최고의 개발자는 탄탄한 엔지니어링 문화를 갖춘 조직을 찾으므로 뛰어난 인재를 채용하는 데 도움이 되는 유용한 도구이기도 하다. 뛰어난 개발자가 입사하면 문화가 더욱 강화되는 선순환 구조가 만들어진다.
최고의 개발자가 장래의 회사에 기대하는 점
* 개발 주기 반복 속도를 최적화한다.
* 끊임없이 자동화를 추구한다.
* 올바른 소프트웨어 추상화를 구축한다.
* 코드 리뷰를 활용해서 높은 코드 품질을 유지하는 데 집중한다.
* 서로 존중하는 근무 환경을 유지한다.
* 코드 소유권을 공유한다.
* 자동 테스트에 투자한다.
* 20%의 시간이나 해커톤을 통해 실험할 시간을 준다.
* 학습하고 꾸준히 발전하는 문화를 조성한다.
* 최고의 개발자를 고용한다.