이펙티브 엔지니어

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

챕터

• 올바른 마인드셋을 갖춰라
  • 레버리지가 높은 활동에 집중하라
  • 학습을 위해 최적화하라
  • 우선순위를 정기적으로 점검하라
• 실행, 실행, 실행
  • 반복 속도에 투자하라
  • 개선하려는 사항을 측정하라
  • 아이디어는 일찍 그리고 자주 검증하라
  • 프로젝트 추정 기술을 향상시켜라
• 장기적인 가치를 구축하라
  • 품질과 실용주의 사이에서 균형을 유지하라
  • 운영 부담을 최소화하라
  • 팀의 성장에 투자하라

 

요약

이펙티브 엔지니어를 효과적(효율적)으로 일하는 개발자라고 표현하는데 여기서 효과적(효율적)으로 일한 다는 건 어떻게 측정할까?
- 시간? 노력? 결과물? -
이 책은 효과적으로 일하는 개발자가 되는 방법을 알려준다.

이펙티브 엔지니어는 일한 시간 단위당 생산하는 가치의 비율로 정의되며, 이것이 바로 레버리지이다.

 

우리가 쓸 수 있는 시간은 한정되어 있고, 그 시간에 할 수 있는 활동은 많다.
‘레버리지가 높은 활동에 집중하라’

 

성장 마인드셋을 갖춰라.
성장 마인드셋을 가진 이들은 자신의 지능과 기술을 노력으로 기르고 성장시킬 수 있다고 믿는다.
… 
도전과 실패를 학습의 기회로 본다.
그래서 성공으로 가는 도중에 포기할 가능성이 훨씬 적다.

 

새로운 직장이나 팀을 선택할 때 고려할 점

• 성장
• 교육 = 온보딩 프로그램, 멘토링, 학습 & 성장 지원
• 개방성 = 문화, 지식 공유
• 속도
• 사람 = 좋은 동료, 멘토
• 자율성

 

직장에서 이용할 수 있는 자원을 활용하는 방법

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

 

직장 밖에서 학습 습관을 기르는 데 영감과 도움을 줄 만한 방법

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

 

코드 리뷰가 개발자에게 제공하는 명확한 혜택

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

 

좋은 추상화의 속성

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

 

온보딩 절차를 통해 달성할 네 가지 목표

• 최대한 빠르게 신입 개발자 적응시키기
• 팀의 문화와 가치 전달하기
• 신입 개발자가 성공에 필요한 폭넓은 기초 지식 접하게 하기
• 신입 개발자를 사회적으로 통합시키기

 

기억에 남는 문장

서문

이펙티브 엔지니어: 효과적으로 일하는 개발자

이펙티브 엔지니어는 가치와 효과를 내는 데 집중하며 어떤 성과를 낼지 선택할 줄도 안다.

메타 기술: 다른 기능적인 기술을 빠르고 효율적으로 습득할 수 있는 기술
메타 기술은 시간과 에너지를 어디에 집중해야 들어간 노력 대비 더 큰 효과로 이어질지 알아내는데 더 큰 도움이 된다.

 

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

멘토가 해야 할 일에는 코드 리뷰해 주기, 배워야 할 기술 개괄적으로 알려주기, 페어 프로그래밍 세션 진행하기, 기술의 트레이드오프 알려주기, 업무 우선순위를 잘 설정하는 방법 설명해 주기, 다른 팀원들과 원만하게 협업하는 방법 지도하기 등 온갖 항목이 포함됐다.
…
신입 개발자들이 공통적인 기초 위에서 시작할 수 있게 온보딩 프로그램도 개설하여 기술 강연 10회를 반복해서 열고, 코드랩 10회도 포함시켰다.
코드랩은 구글에서 빌려온 아이디어로, 코어 추상화를 설계하는 이유, 활용 방법, 관련 코드를 설명하고 이해한 바를 검증 볼 수 있는 훈련까지 제공하는 문서를 말한다.

-p27

레버리지란 투자한 시간당 생산한 가치, 또는 효과다.
레버리지 (Return On Investment, ROI) = 생산한 효과 / 투자한 시간
레버리지가 매우 중요한 이유는 시간이 가장 제한적인 자원이기 때문이다.

-p29

이펙티브 엔지니어는 시간을 어디에 어떻게 쓸지 정하는 기준으로 레버리지 (파레토 법칙)를 삼는다.
일반적인 개발자의 근무 시간은 1,880 ~ 2,820 시간 정도다.
입사 후 첫 한 달간 매일 1시간을 신입 개발자 멘토링과 교육에 쓴다는 것이 큰 투자로 느껴질 수 있다.
하지만 그 시간은 신입 개발자가 첫해에 일하는 전체 시간의 1%밖에 되지 않는다.
…
신입 개발자에게 유용한 UNIX 명령어를 알려주면 기본 업무에 드는 시간을 몇 분에서 몇 시간까지 절약할 수 있다. 디버깅 도구를 알려주면 새로운 기능 제작에 드는 개발 시간을 크게 줄일 수 있다.
코드를 초기에 철저히 리뷰해서 일반적인 오류를 찾아주면 나중에 비슷한 문제를 다시 해결할 필요가 없어지고 나쁜 습관이 형성되는 것도 막을 수 있다.
완료해야 할 프로젝트나 배워야 할 기술의 우선순위를 정하는 방법을 알려주면 신입 개발자의 생산성이 수월하게 향상된다.
신입 개발자가 코어 추상화, 기본 개면을 배우기 좋은 첫 프로젝트를 계획하면 소프트웨어 설계가 개선되고 향후 유지 보수에 드는 수고가 줄어든다.
스타트업이 성공하려면 개발자 한 명이 얼마나 성취하느냐보다는 팀 전체가 성공하느냐가 더 중요하다.
따라서 신입 개발자를 최대한 빠르고 매끄럽게 양성하는 프로그램에 투자하는 건 우리가 할 수 있는 일 중에서 레버리지가 매우 높은 일이었다.

-p30~p31

인텔의 전 CEO 앤드루 그로브는 [하이 아웃풋 매니지먼트]에서 전체 레비리지, 즉 단위 시간당 생산하는 가치의 양을 증가시키려면 다음 세 가지 방법밖에 없다고 설명했다.
특정 활동을 완료하는 데 드는 시간 줄이기 특정 활동의 생산량 늘리기 레버리지가 높은 활동으로 전환하기 세 가지 방법은 자연스럽게 다음 질문으로 이어진다.

ㆍ이 활동을 더 짧은 시간에 완료하려면 어떻게 해야 할까?
ㆍ이 활동으로 생산되는 가치를 증가시키려면 어떻게 해야 할까?
ㆍ이 시간을 투자해 더 큰 가치를 생산할 수 있는 다른 활동이 있을까?

예를 들어 각 질문은 각기 다른 잠재적인 개선 방안으로 이어진다.
ㆍ똑같은 목표를 더 짧은 시간 내에 달성할 수 있게 회의 시간을 1시간에서 30분으로 줄이기
ㆍ회의가 명확한 목표를 향해 더 생산적으로 진행되도록 사전에 회의의제를 준비하고 목표를 설정하여 참석자에게 배포하기
ㆍ꼭 직접 만나 의논할 필요가 없다면 회의를 이메일 논의로 대체하고, 회의 시간을 중요한 기능을 제작하는 데 사용하기

-p31 ~p34

학습을 위해 최적화하라

자신의 능력을 통제할 수 없는 고정된 양으로 볼 것인가?
아니면 자신을 발전시키는 데 자신의 노력과 에너지를 쓸 것인가?

-p43

근무 시간에 도전적이지 않은 업무를 하는 것은 단순히 지루한 시간을 보내거나 학습 기회를 놓치는 것뿐만 아니라, 성장과 학습 측면에서 막대한 기회비용을 지불하는 것이다.
…
회사가 근무 시간에 도전적이지 않은 업무를 9시부터 5시까지 시키고 지급한 급여는 훨씬 낮은 지적 성장률을 수용한 대가로 주는 돈입니다.
지식이 복리 계산된다고 보면 장기적으로 놓치는 복리 비용은 어마어마합니다.
회사는 여러분에게 인생 최고의 기회를 주지 않습니다.
그렇게 시간을 끌며 현실에 안주하면 무시무시한 상황이 벌어집니다.

-p47

오늘 자신을 1% 성장시키기 위해 무엇을 배우겠는가?
그 1%는 기술과 지식을 발전시켜 미래의 기회를 잡을 수 있게 해주는, 레버리지 높은 투자다.
…
자신의 시간을 학습률이 가장 높은 활동에 투자하라.

-p48

자신의 성장에 투자하려면 스스로 20%의 시간을 개척해야 한다.
매주 하루를 통째로 내는 것보다 매일 1~2시간 정도를 내는 것이 더 효과적이다.
…
20%의 시간으로는 이미 작업 중인 분야나 사용 중인 도구에 대해 더 깊이 이해하면 좋다.
아니면 인접 분야에 대한 경험을 쌓아도 좋다.
인접 분야란 자신의 핵심 역할과 연관 있는 분야를 가리킨다.

-p54

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

개발자에게도 체크리스트가 도움이 된다.
효과적으로 우선순위를 정하는 첫 번째 단계는 해야 할 모든 업무를 목록으로 정리하는 것이다.

-p58

모든 것을 하려고 하지 마라.
중요한 것에 집중하라.
가치를 생산하는 것이 중요하다.

-p72

개발자의 몰입 상태를 고려해서 회의 일정을 잡는 회사는 거의 없다.
폴 그레이엄은 [생산자의 일정, 관리자의 일정]이라는 에세이에서 관리자와 생산자의 일정이 어떻게 다른지 설명한다.
관리자는 전통적으로 자신의 스케줄을 1시간 단위로 정리하지만, 생산자(프로그래머)는 일반적으로 적어도 반나절을 시간 단위로 쓰는 것을 선호한다.
…
마이크로소프트 리서치의 한 연구는 직원들이 자신을 방해하는 이메일, 채팅을 처리한 후에 다시 원래 하던 활동에 집중하기까지 평균 10 ~ 15분이 걸리는 것을 알아냈다.
…
가능하면 일정에 집중하는 시간 블록의 길이를 최대한 길게 유지하라.
…
중요하지 않은 활동을 거절하는 법을 배워라.
자신의 일정, 그리고 자신과 함께하는 생산자의 일정을 보호하라

-p75~76

끊임없는 맥락의 전환은 어느 하나의 활동에도 제대로 집중하지 못하게 방해하고 전체적인 성공 가능성을 감소시킨다.

-p77

반복 속도에 투자하라

측정할 지표를 정하는 것은 중요하지만 측정하지 않을 지표를 정하는 것도 중요하다.

-p125

지표는 1) 가장 큰 효과를 내고 2) 실행하기 좋으며 3) 즉각 반응하되 견고한 것으로 정해야 한다.
그 지표에 맞춰 최적화했을 때 팀에 가장 큰 효과를 내는 지표를 찾아라

-p127

 

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

"지체하지 말고 (…) 피드백을 받으세요.
어떤 부분이 효과가 있는지 알아내세요.
그렇게 하는 것이 무턱대고 만들고 전부 제대로 했을 거라 착각하는 것보다 훨씬 나아요.
왜냐하면 전부 제대로 만드는 것은 불가능하니까요."

-p148

“이 프로젝트에서 가장 두려운 부분이 무엇인가요?
그 부분이 가장 모르는 것이 많은, 가장 위험한 부분입니다.
그 부분부터 하세요.”
가장 위험한 부분을 먼저 이해하면 사전에 계획을 업데이트해서 모든 노력이 허사가 될 위험을 피할 수 있다.

-p150

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

우리는 항상 불안정한 정보에 기대어 움직인다.
그러므로 프로젝트 추정의 정확성을 높이고 변화하는 요구 조건에 적응하는 능력을 키워야 프로젝트 계획을 성공적으로 세울 수 있다.

-p174

일정을 설정할 때 예기치 못한 방해 요소를 고려해서 여유 시간을 추가하라.
장기 프로젝트에서는 방해 요소가 복합적으로 발생할 확률이 꽤 높다.

-p184

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

코드를 리뷰하지 않는 개발자는 코드 리뷰가 코드 품질 개선에 도움이 된다는 것을 인정하면서도, 종종 리뷰가 개발 주기 반복 속도에 미치는 영향에 대해 우려를 표명한다.

-p211

쿼라에서는 비즈니스 로직의 모델과 컨트롤러 코드에 대한 리뷰만 요청했다.
사용자에게 웹 인터페이스를 렌더링 하는 뷰 코드는 리뷰할 필요가 없었다.
대부분의 코드를 프로덕션에 푸시한 후에 리뷰했다.
개발 주기 반복 속도는 늦추지 않되 미래를 생각해서 고품질 코드베이스를 위해 투자하고자 했다.
…
입사한 지 얼마 안 된 신입의 코드일수록 코드 품질과 스타일을 팀의 표준에 맞게 높이기 위해 리뷰가 더 중요하다.

-p212

기술 부채란 코드베이스의 상태와 품질을 개선하는 데 필요함에도 불구하고 미뤄둔, 해결하지 않은 채 방치하면 개발 속도를 지연시킬 수 있는 모든 작업을 가리킨다.
…
”첫 번째 코드를 배포하는 것은 부채를 지는 것과 같다.
약간의 부채는 재작성을 통해 즉시 상환하는 한 개발 속도를 높인다.
…
부채를 상환하지 않은 채 두면 위험해진다.
올바르지 않은 코드에 들이는 시간은 부채에 대한 이자로 간주된다.”

-p225

더 효과적인 개발자가 되려면 기한에 맞춰 업무를 완료해야 할 때는 어쩔 수 없이 기술 부채를 만들지만, 대신 주기적으로 그 부채를 상환해야 한다.

-p226

운영 부담을 최소화하라

고장이 없으면 시스템이 견고하고 안정적이라고 생각하는 개발자가 많다.
…
시스템이 느리게 실패하면 코드 오류의 원인이 불분명해져서 어떤 문제가 일어난 것인지 알아내기 어려워진다.
...
피드백 과정을 단축하는 유용한 기법은 소프트웨어가 빨리 실패하게 하는 것이다.
…
빨리 실패하면 더 빠르고 효과적으로 문제를 드러내고 해결할 수 있다.

-p237 _ p238

팀의 성장에 투자하라

함께 일하는 사람이나 팀은 여러분의 효과성에 큰 영향을 미치며 관리자나 선임 개발자가 아닌 사람도 팀의 방향에 영향을 미칠 수 있기 때문이다.
…
개발자로서 더 높은 자리에 오를수록 개인적인 기여보다 주변 사람에게 미친 영향이 효과성을 측정하는 기준이 된다.
…
”그 사람의 존재로 인해 팀이 전체적으로 나아진다면 책임 개발자다.
그 사람의 존재로 인해 회사가 전체적으로 나아진다면 수석 개발자다.
그 사람의 존재로 인해 업계가 더 발전한다면 최고 개발자다.”

-p258

성공한 회사의 일원이 되면 기여한 바에 비해 더 많은 공을 인정받고 성공하지 못한 회사의 일원이 되면 기여한 바에 비해 더 적은 공을 인정받습니다.
…
직업적 성공은 회사와 팀의 성공에 크게 좌우되며 개인적인 기여만으로는 회사나 팀이 성공할 수 없다.

-p259

신입 개발자를 입사 후 1개월간 하루에 1~2시간 교육하면 같은 시간을 제품 제작에 쏟는 것보다 조직에 훨씬 더 큰 영향을 미친다.
더욱이 온보딩 자료 제작을 위한 초기 시간 투자는 팀원이 한 명씩 추가될 때마다 꾸준히 배당 수익을 낸다.
온보딩이 팀과 회사에 도움을 주는 것은 분명하다.
하지만 이미 회사에 잘 적응해서 생산적으로 일하고 있는 사람이라면 신입 개발자의 적응을 돕는 것이 자신에게 어떤 도움이 될지 궁금할 수 있다.
자신의 업무에 쏟아야 할 시간을 왜 굳이 신입에게 써야 할까?
명심하라.
팀의 성공을 향한 투자가 자신의 성공 가능성도 높여준다.

-p267

어떤 프로젝트를 책임지는 유일한 개발자가 되면 자신의 가치가 올라간다는 잘못된 통념이 존재한다.
내가 가진 지식을 똑같이 아는 사람이 별로 없으면 관련 지식이 희소해지면서 더 높은 수요와 가치로 이어질 거라고 생각하는 것이다.
…
작동하는 시스템에 대해 정통한 사람이 여러분밖에 없는데 그 시스템이 작동을 멈춘다면 최전선에서 홀로 방어해야 한다.
그저 그 시스템에 관해 가장 잘 아는 사람이라는 이유로 관련 문제에 대응하고 유지 보수하고 기능을 수정하고 버그를 수정하는데 꽤 많은 시간을 쏟느라 새로운 것을 배우거나 만들 자유시간을 가지기 어려워진다.

-p274

사후 분석은 책임 소재를 따지는 비생산적인 논의가 아니라 함께 더 나은 해결책을 찾는 것을 목표로 한다.

-p277

집단적으로 학습하는 문화를 조직 전체에 주입하는 것은 어려운 일이다.
하지만 꾸준히 노력하면 큰 효과를 거둘 것이다.
자신이 속한 팀에서 작업 중인 소규모 프로젝트부터 시작해 점진적으로 더 큰 프로젝트에서도 사후 분석을 진행하는 관례를 확립하라.
각각의 경험에서 더 많이 배울수록 다음 프로젝트에 가져갈 지식이 더 늘어날 확률, 성공할 확률도 커진다.
집단 학습을 위해 최적화하라.

-p280