[서적] 이펙티브 엔지니어 | 에드먼드 라우

 

이펙티브 엔지니어 | 에드먼드 라우 - 교보문고

 

 

오랜만에 연락드린 멘토님께서 응원과 함께 <이펙티브 엔지니어>를 선물해 주셨다. 멘토링을 받을 때도 프로그래밍 지식 외에 개발자로서 어떤 마음가짐을 가져야 하는지, 한정적인 시간을 어떻게 잘 활용해야 하는지에 대한 이야기를 많이 해주셨었는데 이 책을 통해서도 '레버리지'라는 개념을 통해 어떻게 '이펙티브 엔지니어'가 될 수 있는지에 대해 배울 수 있었다.

 

효율성에서 매우 중요하지만 개발자들이 종종 간과하는 것이 메타 기술이다.
메타 기술은 시간과 에너지를 어디에 집중해야 들어간 노력 대비 더 큰 효과를 이어질지 알아내는 데 도움이 된다.
<이펙티브 엔지니어>는 이러한 메타 기술을 가르쳐줄 것이다.
약속하건대 이 책을 읽으면 레버리지라는 유용한 프레임워크를 알게 된다.
영향력을 높이는 데 필요한, 실행 가능한 도구를 갖추게 될 것이다.

*이 책에서 배우는 내용 중

 

 

올바른 마인드셋을 갖춰라

1. 레버리지란 투자한 시간당 생산한 가치, 또는 효과를 말한다. 이펙티브 엔지니어는 업무를 효율적으로 완수하고, 제한된 시간에 더 많은 가치를 생산한다. 그러니까 이 레버리지를 높이기 위해 어떤 습관을 가져야 할지, 지금 하는 활동에서 레버리지를 어떻게 높여야하는지를 항상 고민하자.

 

2. 성장 마인드셋을 가진 사람들은 자신의 지능과 기술을 노력으로 기르고 성장시킬 수 있다고 믿는다. 내 능력을 통제할 수 없는 고정된 양이라고 여기고 현실에 안주할 것인가 혹은 나를 발전시키기 위해 노력과 에너지를 쏟을 것인가? 현실에 안주하고 싶은 게 아니라면 마인드셋부터 다시 돌아보자.

성장 마인드셋을 갖췄다면, 정말로 성장해야 한다. 링크드인의 공동 창업자 리드 호프먼은 "장기적인 성공을 꿈꾼다면 자신에게 매일 투자하고 개발 주기를 반복해야 하는, 현재 진행형 스타트업이나 제품의 베타 버전이라고 생각해야 한다."고 이야기한다. 매일 딱 1%라도 성장하자.

 

3. Chapter 2의 내용은 정말 모든 주니어 개발자가 읽어봤으면 좋을 정도로 많은 도움이 됐다. 

우선, 새로운 직장이나 팀을 선택할 때 여러 가지 고려해야 할 사항들에 대한 이야기가 있었다. 핵심 사업 지표의 성장률은 어떻게 되는지, 성장이 멈춘 회사인지 혹은 회사가 팀원을 성장시키기 위해 어떤 프로그램을 갖추고 있는지 등 세세한 내용들이 참고하기에 좋았다.

그리고 근무 시간에 나를 발전시키기 위한 방법과 학습 습관을 기르는 데 도움이 되는 것들에 대한 내용은 훌륭한 온보딩 프로그램 혹은 멘토링에 참여하는 느낌이 들 정도였다. 몇 가지 내용을 적어보겠다.

 

근무 시간에 나를 발전시키기 위한 방법

• 회사에서 가장 뛰어난 개발자가 작성한 코어 추상화 코드를 연구하라.
• 코드 리뷰는 가장 혹독한 리뷰어에게 부탁하라.
• 발전하고 싶은 분야에 관한 수업을 수강하라.
• 관심 있는 프로젝트 설계 논의에 참여하라.
• 다양한 프로젝트에 참여하라.

 

학습 습관을 기르는 데 도움이 되는 것들

• 새로운 프로그래밍 언어와 프레임워크를 배워라.
• 책을 읽어라.
• 엔지니어링 정보를 공유하는 블로그를 팔로우하라.
• 블로그를 개설해 설명하고 가르쳐라.
• 사이드 프로젝트를 해라.

 

실행, 실행, 실행

1. 이 장에서는 개발 주기를 빨리 반복해야 더 빨리 배울 수 있다는 내용으로 작업을 지연시키는 평범하고 일상적인 동작이 무엇인지 찾고, 더 효율적으로 수행하는 방법을 찾아내는 것이 중요함을 배운다. 예를 들면, 수동 작업 흐름을 자동화하거나 변경사항과 관련 있는 단위 테스트를 빠르고 쉽게 실행할 수 있게 하면서 제한된 시간을 더 중요한 문제에 쏟을 수 있게 해야 하는 것이다. 

소규모로 검증을 하지 않아서 위험해진 상황이라던지, 미리 발견하지 못한 문제점으로 인해 어떤 일들이 벌어지는지에 대한 사례들을 이야기하면서 그런 상황을 겪지 않기 위해서 어떤 자세로 서비스를 개발하는 것이 좋은지에 대해 배울 수 있다.

 

• 반복적인 방식으로 문제에 접근하여 노력의 낭비를 줄여라.
• 소규모 검증으로 대규모 구현의 위험을 줄여라.
• A/B 테스트를 활용해서 제품 가설을 끊임없이 검증하라.
• 1인 프로젝트를 할 때는 정기적으로 피드백을 구할 방법을 찾아라.
• 자신의 의사 결정을 검증하는 자세를 갖춰라.

 

2. 프로젝트 계획을 어떻게 하면 성공적으로 세울 수 있을까? 프로젝트에 드는 시간과 작업량에 관한 최선의 추측을 반영하는 추정의 개념과 사업적 지향점을 나타내는 목표를 구분해야 한다. 우선 프로젝트를 계속해서 작은 작업으로 분해해서 한 작업에 이틀 이상 걸리지 않도록 설정한 이후에 추정치를 세우고 예상하지 못한 하위 작업들이 생기지 않게 한다. 그리고 사실 가장 이상적인 부분일 수 있지만 관리자가 원하는 작업 시간이 아니라, 정말 실제로 드는 시간을 추정해야 한다. (가능할까?)

 

3. 재작성 프로젝트에서 욕심내지 말자! 마틴 파울러가 이야기하기를 코드를 리팩토링 할 때는 기존 코드의 동작을 보존하면서 점진적인 변환을 활용해야 한다고 한다. "다시 만들면서 이것도 넣고 저것도 넣어볼까?"라는 태도는 지양하자. 

 

 

장기적인 가치를 구축하라

1. 품질과 실용주의 사이에서 균형을 유지하라. 소프트웨어의 품질이 뛰어나야 개발자가 가치를 생산하는 속도가 높아진다. 여기서 고품질의 코드베이스를 만드는 전략을 배울 수 있다. 우선, 반갑게도 내가 좋아하는 코드 리뷰에 대한 이야기가 나온다. 코드 리뷰는 버그를 줄여주고 개발자가 해당 코드에 대한 책임감을 더 가지게 된다는 장점이 있을 뿐더러, 팀원들끼리 좋은 코드를 서로 배울 수 있다. 하지만 모든 코드를 반드시 리뷰해야 한다거나 하지 말아야 한다는 이분법적 선택에서 벗어나야 한다.

• 우얄라에서는 핵심 기능의 까다로운 부분만 리뷰하거나, 마스터 브랜치에 푸시한 다음 커밋 이후에 코드를 리뷰했다.
• 쿼라에서는 개발 주기 속도를 늦추지 않고 고품질 코드베이스를 위해 프로덕션에 푸시한 후에 리뷰했다.

 

2. MIT 교수 대니얼 잭슨은 <Software Abstractions(소프트웨어 추상화)>에서 이렇게 이야기한다.

올바른 추상화를 선택하면 프로그래밍이 설계부터 자연스럽게 흘러간다.
모듈 인터페이스는 작고 간단할 것이고 광범위한 개편이 없어도 새로운 기능이 잘 안착할 것이다.
잘못된 추상화를 선택하면 프로그래밍하는 동안 예상 밖의 문제가 줄줄이 일어난다.
인터페이스는 예상치 못한 인터랙션을 억지로 수용하기 위해 찌그러지거나 투박해질 것이고
아주 간단한 변경조차 하기 어려워진다.

 

좋은 추상화를 배우기 위해 도움이 되는 아이디어

• 구글, 페이스북, 링크드인, 트위터 같은 IT 기업의 오픈 소스 프로젝트를 살펴보라. 프로토콜 버퍼, 쓰리프트, 하이브, 맵리듀스와 같은 추상화가 회사가 성장하는 데 필수였던 이유를 알아보라.
• 인기 있는 API 인터페이스를 연구하라. 파스 스트라이프, 드롭박스, 페이스북, 아마존 웹 서비스 등에서 개발한 것이 좋은 예다. 이러한 플랫폼을 기반으로 하면 개발이 쉬워지는 이유를 파악하라.

 

3. 레버리지가 높은 테스트를 작성하자. 테스트는 원래 코드를 작성한 사람이 기억이 생생할 때 작성하는 것이 몇 달, 몇 년 후 해당 코드를 수정하려는 사람이 코드를 작성하는 것보다 훨씬 쉽다. 

 

4. 기술 부채란 코드베이스의 상태와 품질을 개선하는 데 필요함에도 불구하고 미뤄둔, 해결하지 않은 채 방치하면 개발 속도를 지연시킬 수 있는 모든 작업을 가리킨다. 부채가 늘어나면 코드의 가독성도 떨어지고 수정하기가 어려워진다. 주기적으로 기술 부채를 상환하자!

 

5. 아키텍처를 너무 복잡하게 설계하지 말자. 유지 보수 능력에 비해 시스템 복잡성이 커지면 운영 부담만 커질 뿐이다. 이 시스템이 비슷한 프로젝트에서 성공적이었는지, 대량의 데이터를 처리할 때 실제로 분산형 클러스터가 필요할 정도로 데이터의 양이 많은지 등을 확인해야 한다. 이 장을 읽으면서 회사에서는 대부분 시스템이 이미 설계되어있어 내 고민을 적용하기가 아직은 어렵지만 이전에 멘토링을 받으면서 오버스펙에 대한 경계심을 많이 가지게되어 다행이라고 생각했다.

 

6. 저자가 우얄라에서 처음 임무를 맡으면서 기술 부채를 많이 보게되었는데 코드를 이해하기 너무 어렵고, 단위 테스트는 부족했으며 'qqq' 같은 불분명한 변수 이름들로 고생했다고 했다. 그래서 집단 지성을 구축해서 팀 내에 장기적인 가치를 창출하기 위한 투자를 하게 되었다는데 그 내용은 채용부터 시작된다. "강력한 개발자가 팀에 합류해서 산출하는 가치는 다른 많은 분야에 투자해서 얻는 가치보다 훨씬 더 크기 때문이다."

다음은 온보딩 프로그램이다. 온보딩 프로그램 절차를 체계적으로 잘 설정하면 팀의 효율성이 높아질 뿐더러 신규입사자, 나 자신까지 성장할 수 있다. 팀이 강해지고 커질수록 코드 리뷰가 쉬워지고 버그를 수정할 인원이 더 많아지며 더 야심 찬 프로젝트에 도전할 수 있는 더 큰 기회가 생긴다. 

그리고 요즘 회사에서 조금 위험해 보인다는 생각이 들었었던 부분이 마침 이 부분에 나왔다. 바로 어떤 프로젝트의 코드가 오직 한 사람의 소유가 되면 안된다는 것이다. 프로젝트를 책임지는 유일한 개발자가 되면 자신의 가치가 올라간다고 오해하기 쉽지만 오히려 작업의 유연성이 떨어지고 정보의 고립이 생기기 때문에 담당자의 부담감만 올라간다. 미래를 위해서라면 코드를 공유하고 같이 프로젝트를 이해하면서 버스 지수를 높여야 한다.

 

7. 문제가 발생했을 때는 모든 팀원들이 사후 분석에 참여해야 한다. 이 기록은 다른 조직에게도 공유되는 것이 좋다. 예전에 기업 인터뷰 시간에 장애 대응 조치에 대해 들을 수 있었는데, 그 기업에서는 대응팀이 따로 있어 모든 내용을 기록하고 해당 내용은 모두에게 공개되므로 모두가 그 대응 과정에 대해 배울 수 있었다고 했던 기억이 난다. 비슷한 장애가 다른 프로젝트에서 발생했을 때 많은 도움이 될 것 같아 우리 개발팀에서도 도입했으면 좋겠다고 생각한 프로세스 중 하나이다.

 

 

 

마무리

위에 작성한 내용 외에도 서비스에서 사용자를 사로잡기 위해 어떤 데이터 수치에 집중해야 하는지에 대한 이야기도 있는데 굉장히 흥미로웠고 이 내용을 바로 활용할 수 있는 환경이었다면 더 재미있을 거라는 생각이 들었다. 그런 환경에 속해질 수 있도록 더 노력해야겠다.

지금 하는 일이 현재 목표를 위해 가장 높은 레버리지를 내는가?
그렇지 않다면 그 일을 할 이유가 무엇인가?
개발자로 일하는 도중에 잘못된 선택을 하더라도(일을 하다 보면 일어날 수밖에 없는일이다)
성장 마인드셋을 갖춘 사람이라면 실패를 학습의 기회로 보고 다음에 더 잘할 수 있을 거라고 생각한다.

 

작년과 마찬가지로 올해도 어떤 방향으로 성장해야 하는지 고민하고 있는데 이 시기에 좋은 책을 만난 것 같아 멘토님께 감사하다. 주위에 흔들리지 말고 잘 성장하라고 선물해주신만큼 책에 나온 내용들을 기반으로 앞으로의 계획을 세워보려고 한다.