[책] 이펙티브 엔지니어 후기

 

소감

---

 

회사에 있는 책 중에 "이펙티브 엔지니어"라는 책을 발견하게 되었다.

요즘 사내에 개발자들이 많아져서 그런지 IT 관련 서적을 많이 구매하는 것 같았다.

살짝 훑어봤을 때 내용이 크게 어려워 보이지 않았고, 책에서 사용하는 용어들도 대부분 개발자라면 바로 알 만한 단어들로 이뤄져 있었다. 두껍지도 않아 (대략 250페이지 정도) 시간 내서 읽어보려고 이번 주에 완독을 했는데, 사실 테마가 "개발자들을 위한", "IT업무 효율"이지만, 이 책에서 나오는 개발 용어들을 일반 업무용어로 바꿔서 읽으면 비개발 직군에게도 충분히 유용할 수 있는 자기 개발서라고 생각한다. 특히 업무의 우선순위도 선별과정, 지표를 활용한 내 업무에서의 활용, 차라리 빠른 실패를 경험하기 등 내가 읽으면서도 "응? 이건 개발자들에게 국한되지는 않겠는걸?"이라는 생각이 들기도 했다. 하여튼 평상시 본능적으로 이끌렸던 "효율적으로 일하기"라는 방식을 이 책에서는 조리 있게 정리되어 있었고, 엔지니어가 아닌 다른 직군의 사람들에게도 추천을 해주고 싶은 좋은 책이었다.

 

 

요약

---

 

Part 1. 올바른 마인드셋을 갖춰라

 

1. 레버리지가 높은 활동에 집중해라.

 

 레버리지는 생산한 효과/투자한 시간으로 내가 투자한 시간 대비 얼마나 큰 이펙트를 발휘하는지에 대한 척도다. "업무를 줄이기 위한 업무", "우선순위를 정하는 업무", "지금은 중요하진 않지만 장기적으로 큰 도움이 되는 업무" 등이 레버리지가 높은 활동에 해당한다. 책은 전반적으로 이런 레버리지를 높이기 위한 방법들을 알려주고 있다.

 

 

2. 학습을 위해 최적화하라

 

 자기 자신을 성장시키기 위해서는 수단과 방법을 가리지 말아야 한다. 학습은 늘어날수록 이자처럼 복리가 발생한다. 더 많이 배우려 하고, 더 빨리 시작할수록 좋다. 회사를 다닌다고 학습할 기회가 없는 게 아니다. 회사라는 상황에 맞는 방식으로 학습을 최적화를 하면 된다. "회사에서 가장 뛰어난 개발자의 추상화 코드 연구하기", "혹독한 리뷰어에게 코드리뷰를 받기", "여러 프로젝트를 경험하며 자신의 문제점 파악하기", "회사에서 지원해 주는 웬만한 교육들을 들어보기" 등 다양하게 방식으로 얼마든지 최적화할 수 있고, 회사 밖에서도 내 상황에 맞게 학습을 최적화할 수 있다. "생산적인 토론 그룹에 참가하기", "더 나은 개발자가 되기 위해 사이드 프로젝트를 하기", "책을 많이 읽고, 블로그에 글을 쓰기" 등 나에게 맞는 상황에서 최적화된 학습 방법을 찾아서 학습하라.

 

 

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

 

 적절하고 올바른 목표를 선택하면 제품의 성장 속도를 크게 높일 수 있다. 핵심 영역에서 0.5퍼센트만 성장해도 사용자가 복리 이자처럼 수백만 명이 추가될 수 있다. 우선순위를 높이는 것 또한 레버리지를 높이는 활동이다. "자신이 할 일을 적고 검토해 보기", "중요하지만 급하지 않은 일을 하기", "만약~한다면 계획방법으로 미루는 습관을 무찌르기" 등의 방법을 통해 우선순위 정하기를 습관들이고, 업무효율을 늘이기 위해 노력하라.

 

 

Part 2. 실행, 실행, 실행

 

4. 반복 속도에 투자하라

 

업무를 할 때 우리는 종종 반복적인 일을 접하게 된다. 반복 속도가 느려지는 것은 다른 기회를 놓칠 수 있고 더 많은 것을 배우기가 힘들어진다. 반복 속도를 높이는 일 또한 레버리지가 높은 활동이다. 만약 배포 프로세스가 너무 오래 걸린다면 자동화 배포 툴을 활용할 수 있고, 컴파일 시간, 개발 소요시간이 오래 걸린다면, 그에 맞는 다양한 IDE를 사용할 수 있다. 개발을 하면서 주기적인 반복 과정을 전체론적인 시각(Holistic view)으로 보고, 자신의 권한 범위 내에 있는 회사 또는 팀과 관련된 병목을 간과하지 말자.

 

 

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

 

구글, 아마존, 메타 등 다양한 기업들은 시스템이나 사용자로부터 측정할 수 있는 모든 지표들을 최대한 수집하고 있다. 항공기 조종사도 특정 목적지를 향해서 가면서 계기 세트를 통해 고도와 기압차를 측정하고, 비행기의 상태를 이해하고, 모든 것을 모니터링한다. 아무런 정보 없이 소프트웨어를 만들게 되면 분명 그에 대한 혹독한 대가를 치르게 될 것이다. 최대한 다양한 데이터들을 수집하려 하고, 올바른 데이터인지 꼼꼼하게 확인하면 소프트웨어 개선에 큰 도움이 될 것이다.

 

 

6. 아이디어는 일찍 그리고 자주 검증하라

 

조슈아 레비는 밤을 새워가며 구글의 대항마로 준비한 쿨을 공개했다. 하지만 기대와는 다르게 쿨은 정말 느리고 버그가 많았으며, 심지어 타임지(Time manazine)에서는 "제구실을 못 한다"라고 까지 했다. 이런 참패를 겪은 쿨의 개발자들과 레비는 이 경험에서 "제품 조기 검증의 중요성"을 깨달았다. 언론에 세부사항이 나가는 것이 두려워 제품을 시험해 볼 알파 테스터를 한 명도 고용하지 않았던 것이다. 시장에서 적은 노력으로 검증할 방법을 찾는 것도 중요하며, 미리 프로토타입 모델 출시하기, A/B테스트 등을 통해 사용자들의 반응을 조사해 보기 등을 통해 사전에 소프트웨어를 빠르고 효과적으로 검증해야 한다. 혼자서 모든 것을 담당하는 1인 개발의 경우도 최대한 팀원들에게 프로젝트의 맥락을 공유하고, 피드백을 적극적으로 수용할 수 있어야 한다. 사전 조사는 앞으로 할 일에 비해 정말 적은 노력으로 큰 효과를 누릴 수 있다.

 

 

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

 

프로젝트의 기한을 추정하는 것은 개발자에게 매우 어려운 일에 속한다. 하지만 대규모 프로젝트에서는 모든 기한을 잘 추정해야 하며, 프로젝트를 추정하는 것은 피할 수 없는 일이다. 아래에는 유연성을 보장하는 정확한 추정치를 도출하는 전략들이다.

• 예상치 못한 하위 작업을 미리 찾아내기 위해 프로젝트를 더 작은 작업으로 분해하기
• 자신 또는 다른 누군가가 원하는 작업 시간이 아닌, 작업에 실제로 드는 시간을 기준으로 추정하기
• "4주 이내에 완성할 가능성이 50%, 8주 이내에는 90% "라고 말하는 것처럼 추정을 확률 분포로 생각하기
• 내가 하면 1분 만에 끝내지만 다른 사람이 하면 3시간이 걸릴 수 있기 때문에 실제 업무 담당자가 추정하게 하기
• 미리 수치를 정하면 나중에 변경하기 어려우므로 작업의 윤곽을 짜기 전에는 수치를 이야기하지 않기
• 기존의 데이터로 추정치를 검증하라

추가로 마라톤 중간에 전력질주를 해도 실제 효율이 늘어나지 못할 확률이 높다. 추가 근무로 인해 팀원들은 번아웃이 발생할 수 있고, 이로 인해 팀 내 관계가 악화될 수 있다. 최종적으로 이는 기술 부채가 되어 훗 날 갚아야 될 기술 부채가 산더미처럼 쌓일 수 있으니, 날짜를 더 현실적으로 미루는 게 더 나은 방법이다. 

 

Part 3. 장기적인 가치를 구축하라

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

 

코드리뷰는 코드 품질을 검증하고 최적화하는데 큰 도움을 준다. 때문에 구글에서는 개발자들이 작성한 모든 코드들에 대해 포괄적으로 코드리뷰를 진행하는 문화가 있다. 하지만 소규모 팀에서 이러한 문화는 팀 전체의 생산성을 저해하는 요소가 될 수 있다. 따라서 코드 품질과 개발 속도가 균형을 이룰 수 있게 적절한 균형을 찾아낼 수 있어야 한다.

 

9. 운영 부담을 최소화하라

 

인스타그램은 페이스북에 10억 달러로 인수될 당시 사용자 수는 4천만 명에 달했다. 그에 반해 직원은 단 13명이 전부였다. 이들이 얻은 가장 가치 있는 교훈은 "운영 부담을 최소화하기였다", 검증된 기술을 고집하고, 간단한 일부터 처리하기, 그리고 기계적인 일에 대한 자동화가 운영 부담을 줄여 주여 주는데 큰 도움이 되었다고 한다. 

애플의 스티브잡스는 에어팟을 설계하며 이러한 교훈을 얻었다고 한다. "문제를 해결하려 시도할 때 처음 떠올리는 해결책은 매주 복잡한데 대부분의 사람들은 거기서 멈춥니다. 하지만 포기하지 말고 문제를 붙들고 양파처럼 껍질을 더 벗겨내다 보면 종종 매우 간단한 해결책에 도달합니다.". 결국 운영을 단순화하고 부담을 최대한 줄이는 것 또한 레버리지가 높은 홀동이 될 수밖에 없다.