이봐, 신입, 우린 당신에게 주어진 일이나 끝내라고 채용한 게 아니야
(newsletter.kentbeck.com)- 신입(N00b) 엔지니어의 가치는 완료한 작업 수가 아니라, 장차 주변 사람의 생산성까지 높이는 엔지니어로 성장할 가능성에서 결정됨
- 선임 엔지니어는 신입을 조직을 바꾸는 A / 안정적인 성과를 내는 B / 1년 안에 떠날 가능성이 있는 C로 구분하며, 신입은 자신이 원하는 범주에 해당한다는 신호를 보내야 함
- B가 되려면 코드가 동작하고 / 진행 상황을 공유하고 / 예상치의 3배 이내처럼 합리적인 시간에 끝내고 / 리뷰어와 운영 담당자에게 불필요한 일을 만들지 않아야 함
- A는 작업을 많이 끝내는 사람이 아니라, 불필요한 작업을 제거하고 / 효과가 큰 10%를 찾고 / 설계를 개선하고 / 작은 변경을 연속으로 제출하는 등 작업마다 더 많이 학습하는 사람임
- 뛰어난 성과를 보여주는 활동은 단순히 작업을 닫는 것보다 시간이 더 들지만, 무한정 곁가지에 빠지지 않고 절약한 시간을 자신과 동료에게 도움이 되는 방식으로 투자해야 함
현재 생산성이 아니라 미래의 엔지니어를 채용함
- 선임 엔지니어가 신입을 바라보는 기준은 크게 세 범주로 나뉨
- A는 주변 사람의 생산성까지 크게 끌어올리는 변화의 주체가 됨
- B는 안정적인 성과를 내며 점차 성장함
- C는 1년 뒤 조직에 남아 있지 않을 가능성이 있음
- 선임들은 자신의 업무를 수행하는 동시에 각 신입이 어느 범주에 속하는지 판단해야 함
- A에게는 가능한 한 많은 지원을 제공함
- B에게는 성숙한 엔지니어가 될 만큼 지원함
- 조직에 남지 못할 사람에게는 가능한 한 적은 노력을 쓰려 함
- 신입에게 주어진 작업은 관리자나 기술 리더가 직접 처리하면 더 빠르고 수월하게 끝낼 수 있음
- 당장의 생산성만 중요했다면 신입을 채용할 이유가 없으며, 회사는 신입이 장차 될 엔지니어를 확보하기 위한 옵션 프리미엄으로 현재의 급여를 지급함
- 육성이 성공하면 강력한 다음 세대 엔지니어가 생기지만, 실패하면 선임들이 10년 뒤에도 같은 엔지니어링 업무를 계속해야 함
작업 개수만으로는 신입을 평가할 수 없음
- 한 분기에 작업 40개를 완료한 신입과 20개를 완료한 신입 중 누가 더 나은지는 작업 수만으로 판단할 수 없음
- 모든 작업의 난도가 같더라도 A/B/C를 가르는 데 필요한 정보는 여전히 부족함
- 평가의 목적은 단기 산출량을 비교하는 것이 아니라, 신입이 어떤 종류의 엔지니어로 성장하고 있는지 확인하는 데 있음
B와 C를 가르는 기본 신호
- 작업을 가장 짧은 시간에 닫는 것보다 다음 조건이 중요함
- 작성한 코드가 실제로 동작함
- 무엇을 하고 있는지 다른 사람에게 알림
- 최초 예상 시간의 3배 이내처럼 합리적인 시간에 작업을 끝냄
- 다른 사람에게 부당할 정도로 많은 추가 업무를 만들지 않음
- 도움을 요청해 상대방의 시간이 드는 것은 허용되지만, 다음 상황은 나쁜 신호가 됨
- 리뷰어가 불필요하게 많은 시간을 쓰게 만드는 것
- 오류 때문에 온콜 담당자가 대응하게 만드는 것
- 자신이 일으킨 장애 때문에 DevOps 담당자가 출동하게 만드는 것
- 하지 않은 일을 했다고 속이는 등 평가 체계를 조작하려는 행동은 즉시 C 신호가 됨
- 누구나 실수로 C 신호를 보낼 수 있지만, 같은 C 신호를 두 번 반복해서는 안 되며 전체적으로는 B에 해당하는 신호가 더 많아야 함
A와 B를 가르는 학습 속도
- 최소한 B에 해당하는 신입 가운데 A를 구분하는 기준은 완료한 작업 수가 아니라 각 작업에서 얼마나 많이 학습하는가임
- 신입의 현재 생산성이 선임보다 낮은 것은 예상된 상태이며, 중요한 것은 생산성 자체보다 생산성이 향상되는 속도임
A에 해당하는 행동
- 다음과 같은 행동은 작업을 처리하는 수준을 넘어 학습과 조직의 생산성을 확대하는 A 신호가 됨
- 해당 작업을 아예 수행할 필요가 없다는 설득력 있는 근거를 만듦
- 데이터를 분석해 전체 효익의 90%를 만드는 작업 10%를 찾아냄
- 같은 작업을 여러 방식으로 구현해봄
- 더 나은 설계를 발견하고, 작업 구현뿐 아니라 주변 코드까지 단순화하는 일련의 diff를 제출함
- 구현 전에 어려운 변경을 쉽게 만든 뒤 쉬워진 변경을 수행하면 더 좋은 평가를 받음
- 하나의 큰 diff 대신 여러 개의 작은 diff를 연속으로 제출함
- 매일 diff를 올리면 추가적인 장점이 있음
- 비슷한 작업을 단순화하는 내부 도구를 작성함
- 다시 발생할 비슷한 작업이 없다면 오히려 감점 요인이 됨
- 공식 작업을 끝내는 데 지장을 주지 않으면서 다른 팀이나 코드 영역에도 유용한 diff를 제출함
- 배운 내용을 흥미롭고 / 유용하고 / 설득력 있게 문서화함
- 통찰력 있게 리뷰하고 피드백에 빠르게 대응함
- 견고한 단위 테스트를 포함함
- 뛰어난 성과를 보여줄 방법은 실수를 피하는 방법보다 훨씬 다양함
최소 시간보다 합리적인 시간이 중요함
- A 신호에 해당하는 활동은 작업을 닫는 데 필요한 최소한의 구현만 하는 것보다 더 많은 시간이 걸림
- 이는 흥미로운 곁가지에 무한정 시간을 써도 된다는 허가가 아님
- 공식 작업은 언제나 합리적인 시간 안에 끝내야 하지만, 반드시 절대적인 최소 시간에 끝낼 필요는 없음
절약한 시간을 자신과 동료에게 재투자함
- 추가적인 학습과 개선에 쓸 시간이 없다고 느낄 수 있지만, 시간 관리 / 작업 대기열 관리 / diff 대기열 관리 같은 기술로 진행 속도를 높일 수 있음
- 그렇게 절약한 시간은 다른 사람에게도 이익이 되는 방식으로 자신의 성장에 투자해야 함