<이펙티브 엔지니어> 책을 읽고서

들어가며

개발자에게 시간은 유한하다. 갑자기 무슨 당연한 이야기를 하느냐고 물을 수 있겠지만 개발자 중에 일정 압박을 겪어보지 않은 사람은 없을 것이다. 혹은 어떤 업무나 프로젝트가 주어지고 그에 대한 공수 산정을 했을 때 도출한 값이 마치 자신의 능력치인 것처럼 느껴져 괜히 움츠러든 적은 없는가? 적어도 나는 주니어 때 그런 감정을 느꼈고 업무의 속도와 코드의 품질을 함께 가져가는 개발자 선배들에게 막연한 동경을 느껴왔었다. 나와 비슷한 생각을 한 적이 있다면, 이 책을 꼭 한 번은 읽어보길 권한다. 신입 ~ 저년차 시절엔 기술에 대한 욕심이 강해 원론적인 기술 서적만을 고집했었고, 개발자의 태도나 일하는 방식이 서술된 책은 굳이 찾아 읽어보지 않았었다. 그런 것은 팀의 동료, 선배 개발자들을 보며 자연스레 체득하고 배우는 것이라고 생각했다. (오해하지 말아달라, 실제로도 그렇게 배우기도 한다.) 하지만 내가 조금 더 일찍 이 책을 읽었더라면 일관된 방향성을 가지고 일해왔을 것이고, 내가 한 때 동경했던 선배들처럼 효율적으로 일하는 개발자의 모습에 가까워졌을 것이다.

핵심은 레버리지다

이 책에서 말하는 가장 핵심적인 내용은 다음과 같다.

"시간은 가장 제한적인 자산이므로 가장 중요한 곳에 써라."

그렇다면 무엇이 가장 중요한 것인지 어떻게 판단할 수 있는가? 책의 저자인 에드먼드 라우는 레버리지를 그 척도로 삼고 이를 높일 수 있는 방법을 늘 고민하라고 조언한다. 레버리지라는 개념이 와닿지 않는 독자들을 위해 간단히 설명을 붙인다면, 레버리지란 단위 시간당 생산한 가치를 의미한다. 분수 형태로 간단히 표현하면 가치량 / 들인 시간으로 표현되는 값이다. 즉, 분모인 시간이 줄어들수록, 분자인 가치량이 증가할수록 레버리지는 증가한다.

현업에서 일하다보면 흔히 우스갯소리로 '노가다 작업이다'라고 일컫는 업무들이 종종 있다. 이 업무를 함으로써 얻게 되는 가치는 한없이 낮은데 시간은 한없이 들어가는 경우를 말한다. 하지만 이 업무를 정말 반드시 해야 하는 상황이라면? 그렇다면 레버리지를 높여야 한다. 가장 쉬운 방법은 작업 시간을 줄이는 것이다. 야근을 하라거나 각성 상태에 들어가라는 의미가 아니다. 자신이 다루고 있는 도구의 기능을 이용하거나 정형화된 프로세스를 자동화하여 여기에 들이는 시간을 줄일 수 있다. 변수 _a를 a 로 바꾸고 싶은데, VS Code에서 제공하는 replace 기능을 쓰지 않고 일일이 검색해 바꾸는 상황을 생각해보라. 얼마나 비효율적이겠는가.

그렇다면 나는

이 책을 읽으며 레버리지와 성장 마인드셋에 대해 다시 한번 스스로를 세팅하고 되돌아보는 시간을 가질 수 있었고, 아래는 내가 실제로 적용해 볼법한 액션 아이템들을 도출한 것이다.

• 레버리지가 높은 활동에 집중해라
  • 수동적인 작업이 계속 반복된다면 이를 자동화
  • 의미있는 단위의 코드 공통화를 통해 중복 개발 막기
  • 개발 속도와 코드 품질 중 더 임팩트있는 업무가 무엇인지 늘 생각
  • 체계적인 온보딩 시스템 구축. 개발자의 1년 평균 근무시간이 1900시간임을 감안할때, 신입 온보딩에 19시간을 들여도 겨우 1%에 불과할 뿐이다. 1%의 투자가 99%(근속년수가 늘어난다면 n배로)의 시간에 영향 미침.
  • 팀 회의가 늘어지지 않게끔 일목요연하게 진행하고, 회의 전에 아젠다를 미리 공유함으로써 시간 단축
• 성장 마인드셋을 갖추고 학습 곡선을 최적화. 근무시간에 편한 업무만 하는 것은 엄청난 기회비용을 날리는 것.
  • 업무시간을 8:2로 쪼개어 2의 시간을 학습에 투자한다. 이 학습은 주 업무와 연관된 기술을 더 깊게 이해하는 딥다이브가 될 수도 있고, 불편한 도구를 개선하는 토이 프로젝트일 수도.
  • 모르는 분야에 용감히 뛰어들기. 어차피 SSR이든 BFF든 우리 프로덕트에서 고려해봐야할 사항이다. 서버 제대로 해본 적 없다고 겁먹지 말고 뛰어들어보자.
• 우선순위를 점검. 급한 일과 급하지 않은 일, 중요한 일과 중요하지 않은 일을 구분하기.
  • 몰입의 경험을 위해 길고 연속적인 시간 블록을 확보. 보통 오후에 회의가 많이 잡히는 편이므로 아침 일찍 출근해 가장 몰입이 필요한 일부터 시작.
  • 매주 월요일엔 주간 To do, 매일 아침엔 일간 To do 업무들 나열하기.
• 반복적으로 일어나는 작업에 대한 속도를 높이기.
  • 내가 쓰는 VS Code의 단축키를 숙지하여 마우스보다는 키보드 쓰는 시간을 늘리기.
  • 디버깅에 드는 시간을 단축. 크롬 데브툴 마스터하기.
  • 개발 후 검증에 드는 과정을 자동화하여 시간 단축하기. PR이 올라가면 자동으로 테스트가 돌게 한다.
  • 프로젝트는 소통이 지나칠 때가 아니라 부족할 때 실패. 계속 협업자들과 소통하면서 엔지니어링 외적인 병목을 피하기.
  • 너무 이른 최적화는 만악의 근원. 현재 가장 큰 병목이 어딘지 늘 파악할 것.
• 개선사항을 지표로 측정하기.
  • 평균 응답 시간 대신 가장 느린 응답을 기준으로 개발. 우리나라처럼 좋은 네트워크 환경을 당연히 여기지 말기.
  • 데이터를 시각적인 지표로 확인할 수 있는 대시보드 구축에 대한 중요성 일깨우기.
• 아이디어는 일찍 그리고 자주 검증하기
  • PR 리뷰같은 피드백은 개방적으로 수용할 것. 방어적인 마인드셋은 사람들이 피드백을 꺼리게 한다. 피드백은 발전의 기회.
  • 코드를 일찍, 자주 커밋해 빠르게 설계 결함이 발견될 수 있도록 하기.
  • 1인 팀으로 일하게 되더라도 최대한 정기적으로 피드백을 구할 방법을 찾기
  • 작업 시작 전 대략적인 설계 문서를 작성하고 시작하기
• 프로젝트 추정 기술 향상시키기
  • 가장 어렵고 까다로운 코드 작업부터 시작
  • 작업을 최대한 작은 단위로 쪼개라. 한 단위당 3일은 넘기지 말 것.
  • 상위 결정권자의 "목표"와 개발자로서의 "추정"을 혼동하지 말것. 목표에 추정을 끼워 맞추지도 말 것.
  • 실제 업무 담당자가 추정하도록 하고, 맨먼스 미신을 조심할 것(aka "3분 카레를 10명이서 끓인다고 18초만에 요리되겠냐구요")
  • 범위가 커질 수 있는 작업은 타임박스로 제한할 것. 예를 들어 새로운 도구를 검토하는데 3일이 걸린다고 하지 말고, 3일동안 찾은 결과물을 기반으로 최선의 결정 내리기.
  • 미지의 변수 고려. 회고에 기반해 추정치와 실제 작업 사이의 간극이 얼마였는지 데이터 쌓기.
  • 목표 확실히 하기. 빠른 개발이 목표인가, 장기적인 관점에서의 효율적인 유지보수가 목표인가.
  • 거대한 프로젝트는 측정 가능한 마일스톤 단위로 진행
• 품질과 실용주의 사이에서 균형 찾기
  • 가장 자주 마주하는 기술부채부터 해결하기
  • 좋은 추상화(배우기 쉽고, 문서가 없어도 사용하기 쉬움)에 집중해 어려운 문제를 단순하게 쪼개 코드 품질을 유지하면서 복잡한 문제에 들이는 시간 단축하기
• 운영 부담 최소화
  • 사용자에겐 우아하게 실패하면서(ex. 컴포넌트 비노출) 개발자가 빨리 오류를 알아챌 수 있도록 설계. 예를 들면 Sentry를 통한 에러 추적.
  • 새로운 프레임워크나 도구를 도입해서 얻는 이득과 기존 추상화/도구 용도를 변경해서 쓰는 것 중 어느것이 더 효율적인지 항상 고민하기
  • 도발적인 신기술 대신 확고히 검증된 기술을 택하되, 기술 스택을 최대한 일원화해가면서 팀 전체 업무의 복잡성 낮추기
  • 절차적인 부분은 최대한 자동화
• 팀 성장에 투자
  • 다른 팀원의 어려움을 적극적으로 돕기
  • 채용 기준을 낮추지 말고 채용 이후를 늘 생각하면서 레버리지가 높은 면접자를 채용하기
  • 니 업무 내 업무 나누지말고 최대한 코드 공유하기 (버스팩터를 2 이상으로)
  • 한가지 업무만 하지말고 서로 업무 돌려가면서 하기
  • "팀이 전체적으로 나아진다면 책임 개발자, 회사가 전체적으로 나아진다면 수석 개발자, 업계가 더 발전한다면 최고 개발자"
    • 결제시스템 스트라이프의 엔지니어링 부사장이 한 말. 나는 어떤 시니어가 되고 싶은가?
    • 내 업무만 잘하는게 능사가 아니다.

잊지 말자. 가장 제한적인 자산은 시간이며, 레버리지는 시간을 가장 중요한 곳에 쏟게 해준다.

총평

결국, 이 책은 개발자라면 누구나 고민할 법한 "어떻게 더 효율적으로 일할 수 있을까?"라는 질문에 대한 명확한 가이드라인을 제시한다. 우리의 시간은 유한하고, 그 안에서 최대한의 가치를 창출하는 것이 무엇보다 중요하다. 이를 위해 필요한 것은 단순히 더 많은 시간을 일하는 것이 아니라, 레버리지를 높여서 더 적은 시간에 더 큰 성과를 내는 방법을 찾는 것이다. 지금의 나를 점검하고, 더 나은 방향으로 나아가기 위해 고민하고 실천하는 노력이 쌓일 때, 우리는 비로소 Effective Engineer가 될 것이다.