개발자 온보딩은 보통 입사 교육이 며칠 걸렸는지로 측정되는데, 그것은 문제의 잘못된 쪽 끝을 보는 일입니다. 정작 중요한 숫자는 따로 있습니다. 새로 온 엔지니어가 무언가를 고치면서 다른 것을 망가뜨리지 않았다고 확신하기까지 얼마나 걸리는가입니다. 대부분의 팀에서 이 값은 며칠이 아니라 몇 달 단위로 측정됩니다.

지연의 원인이 사람인 경우는 드뭅니다. 원인은 시스템의 얼마나 많은 부분이 다른 사람들의 머릿속에만 존재하는지, 그리고 첫 두 주의 얼마나 많은 시간이 그것을 한 번에 하나씩 질문으로 꺼내오는 데 쓰이는지에 있습니다.

추적할 가치가 있는 단 하나의 지표는, 그 사람의 첫 변경이 운영 환경에 도달하기까지 걸리는 시간입니다. 오타 수정일 수도 있는 첫 커밋이 아니라, 의미가 있었고 실제로 배포된 변경을 말합니다. 그 시간이 일주일을 넘는다면 장애물은 거의 언제나 역량이 아닙니다. 최근에 아무도 처음부터 끝까지 돌려본 적 없는 설치 절차이거나, 안내자 없이는 진입 지점을 찾을 수 없는 코드베이스입니다.

개발자 온보딩이 경쟁하는 대상

비용은 세 가지이고, 그중 하나만이 새로 온 사람의 시간입니다.

그 사람의 시간은 눈에 보이는 비용이고 모두가 최적화하려는 대상입니다. 팀의 시간은 질문 하나하나가 다른 일을 하던 사람을 끊어놓기 때문에 발생하며, 이 항목이 첫 번째보다 큽니다. 그리고 끝내 묻지 않은 질문의 비용이 있습니다. 새 엔지니어가 오전에만 다섯 번째로 방해하느니 차라리 추측하기를 택하고, 그 추측이 두 달 뒤에야 드러나는 방식으로 틀렸을 때 생기는 비용입니다.

좋은 온보딩이 실제로 없애주는 것은 바로 이 세 번째 비용입니다. 문서를 쓸 가치가 있는 이유는 읽는 편이 묻는 것보다 빨라서가 아니라, 한 번 더 묻는 데 드는 사회적 부담을 재지 않고도 밤 열한 시에 혼자 답을 찾을 수 있게 해주기 때문입니다.

환경부터 고치십시오

첫 주의 모습을 가장 크게 좌우하는 것은, 그 프로젝트가 아무 도움 없이 깨끗한 새 기기에서 실행되는가입니다.

팀은 이 점을 한결같이 과소평가합니다. 모두가 이미 작동하는 환경을 가지고 있고, 두 해 동안 아무도 새로 만들어본 적이 없기 때문입니다. 그러는 사이 설치 문서는 이미 지나간 버전을 가리키고, 지난봄에 누군가 추가한 환경 변수를 빠뜨리며, 신입에게는 한 번도 부여된 적 없는 서비스 접근 권한을 전제로 삼습니다.

해결책은 화려하지 않습니다. 다음에 입사하는 사람에게 문서를 아무것도 바꾸지 말고 글자 그대로 따르게 하고, 실패하는 지점을 하나도 빠짐없이 기록하십시오. 그 목록이 여러분의 진짜 설치 절차입니다. 더 좋은 방법은 그것을 쓸 만한 테스트 데이터까지 갖춘 실행 상태의 시스템을 만들어내는 명령 하나로 줄이는 것입니다. 수작업 단계는 하나하나가 결국 어긋나게 될 단계이기 때문입니다.

접근 권한도 환경의 일부입니다. 코드는 받았지만 저장소 권한이나 스테이징 계정 정보, 이슈 트래커가 없는 사람은 아직 준비된 것이 아닙니다. 첫날 아침에 빈틈을 발견하는 대신 출근일 전에 계정을 미리 만들어 두십시오. 권한 요청 하나가 바쁜 승인자를 기다리며 하루를 통째로 잡아먹는 일은 흔합니다.

진짜 업무를 곧바로 맡기십시오

새로 온 사람을 두 주 동안 실제 업무에서 보호하려는 본능은 선의에서 나오지만 역효과를 냅니다. 목적 없이 코드베이스를 읽는 일은 배우는 것이 거의 없습니다. 읽은 내용을 붙들어 맬 대상이 없기 때문입니다.

반면 둘째 날이나 셋째 날에 작지만 진짜이고 배포 가능한 변경 하나를 맡기면 전달 경로 전체를 가르치게 됩니다. 코드가 어디에 있는지, 테스트는 어떻게 돌아가는지, 리뷰는 어떻게 진행되는지, 배포는 어떻게 이루어지는지, 그리고 누구에게 알려야 하는지까지 말입니다. 새 엔지니어에게 가장 필요한 것이 바로 이 경로이고, 어디에도 적혀 있을 가능성이 가장 낮은 것도 이 경로입니다.

실제 사용자가 기다리고 있는 일을 고르십시오. 지어낸 연습 과제는 안 됩니다. 사람들은 그 차이를 알아차리고, 그 차이가 피드백을 진지하게 받아들일지를 결정합니다. 첫 리뷰는 빠르게 해주십시오. 첫 변경을 이틀씩 기다리게 하는 것은 팀의 우선순위에 대해 가르치고 싶지 않은 교훈을 가르칩니다.

그리고 함께 앉아서 작업하십시오. 시스템을 아는 사람 옆에서 보내는 한 시간이 하루치 독서보다 많은 것을 전달하고, 옆에 앉아 도와준 사람 역시 대개 자기 코드베이스에 관해 무언가를 새로 알게 됩니다.

무엇을 적고 무엇을 적지 않을 것인가

문서는 낡습니다. 그러니 계속 참인 채로 남고 유지보수 비용을 되갚는 것만 쓰십시오.

쓸 가치가 있는 것: 시스템을 설치하고 실행하는 방법, 배포하는 방법, 아키텍처의 형태와 그것이 그런 형태인 이유, 적어두지 않으면 계속 다시 논쟁하게 될 결정들, 그리고 무엇을 누가 맡고 있는지입니다. 기술 문서화에 관한 저희 안내서가 유지보수 문제를 더 자세히 다룹니다.

쓸 가치가 없는 것: 코드가 이미 분명히 말하고 있는 내용, 매달 바뀌는 화면을 단계별로 따라가는 설명, 손으로 관리하는 전체 API 레퍼런스입니다. 이런 문서가 가장 빨리 낡고 가장 크게 오해를 부릅니다.

대부분의 팀에서 가치가 가장 높은 문서는 큰 구성 요소가 무엇이고 왜 분리되었는지를 설명하는 짧은 아키텍처 개요입니다. 오후 한나절이면 쓸 수 있고, 좀처럼 바뀌지 않으며, 새 엔지니어가 첫 주 내내 혼자 재구성하느라 보내는 바로 그 질문에 답해 줍니다.

온보딩은 팀에 대한 시험입니다

새로 온 사람이 힘들어하는 모든 것은, 팀이 그동안 보이지 않게 흡수해 오던 것입니다.

설치에 사흘이 걸린다면 그 비용은 늘 있었고, 기기를 다시 세팅해 본 모든 사람이 조금씩 나눠 내고 있었을 뿐입니다. 어떤 구성 요소가 왜 존재하는지 아무도 설명하지 못한다면, 그 모호함은 이미 오래전부터 의사결정에 값을 치르게 하고 있습니다. 배포 절차에 특정 인물이 반드시 필요하다면 그 의존성은 이미 위험이었고, 기술 실사에서 그리고 진지한 복구 계획에서 드러나는 것도 같은 위험입니다.

그러니 처음 몇 주를 공짜 감사로 여기십시오. 새로 온 사람에게 헷갈렸던 모든 것을 목록으로 남겨 달라고 부탁하고, 그 목록을 역량에 대한 평가가 아니라 백로그로 다루십시오. 그것은 누구도 다시는 만들어 내지 못할, 여러분 시스템에 대한 가장 정직한 기록입니다. 두 달이 지나면 그 사람도 더는 이상한 점을 알아차리지 못하게 되기 때문입니다.

Mecanik은 소프트웨어 개발 업무의 일부로 기존 코드베이스에 정기적으로 합류합니다. 다시 말해 남의 시스템에 이 시험을 치르게 하는 일을 직업으로 삼고 있습니다. 온보딩이 빠른 팀은 문서가 가장 훌륭한 팀이 아닙니다. 최근에 누군가가 자기 환경을 다시 만들어 보고, 그 과정에서 깨진 것을 고쳐 놓은 팀입니다.

자주 묻는 질문

개발자 온보딩은 얼마나 걸려야 합니까? 입사 교육의 길이가 아니라 운영 환경에 도달한 첫 의미 있는 변경까지의 시간을 측정하십시오. 그 시간이 일주일을 넘는다면 장애물이 역량인 경우는 드뭅니다. 대개는 최근에 아무도 처음부터 돌려본 적 없는 설치 절차이거나, 안내자 없이는 진입 지점을 찾을 수 없는 코드베이스입니다.

신입 개발자는 처음 며칠 동안 무엇을 해야 합니까? 실제 사용자가 기다리고 있는, 작지만 진짜이고 배포 가능한 변경 하나입니다. 목적 없이 코드베이스를 읽으면 붙들어 맬 대상이 없어 배우는 것이 적지만, 진짜 변경 하나는 코드가 어디에 있는지, 테스트와 리뷰와 배포가 어떻게 이루어지는지, 누구에게 알려야 하는지를 가르쳐 줍니다.

개발 환경 세팅은 왜 그렇게 오래 걸립니까? 모두가 이미 작동하는 환경을 가지고 있고 몇 해째 아무도 처음부터 만들지 않았기 때문에 문서가 조금씩 어긋납니다. 해결책은 다음 입사자가 아무것도 바꾸지 않고 문서를 그대로 따르며 모든 실패를 기록하게 하는 것입니다. 그 목록이 진짜 절차이고, 명령 하나로 줄이면 다시 어긋나지 않습니다.

온보딩을 위해 유지할 가치가 있는 문서는 무엇입니까? 시스템을 설치하고 실행하는 방법, 배포 방법, 아키텍처의 형태와 그 이유, 적어두지 않으면 다시 논쟁하게 될 결정들, 그리고 무엇을 누가 맡는지입니다. 코드가 이미 말하는 내용, 매달 바뀌는 화면 설명, 손으로 쓴 API 레퍼런스는 건너뛰십시오.

온보딩이 느리다는 사실은 팀에 대해 무엇을 알려줍니까? 팀이 보이지 않게 흡수해 오던 비용이 실재한다는 사실입니다. 사흘짜리 설치는 기기를 다시 세팅한 모든 사람이 늘 조금씩 나눠 내고 있었습니다. 아무도 정당화하지 못하는 구성 요소는 이미 의사결정에 값을 치르게 해 왔습니다. 한 사람만 할 수 있는 배포는 신입이 오기 전부터 위험이었습니다.