테크 리드

개발자가 셋을 넘어가면 기술 결정을 아무도 책임지지 않는 상태가 생깁니다. 같은 문제를 세 사람이 각자 풀면 코드 안에 같은 일을 하는 방식이 세 가지로 남습니다. 목록을 불러오는 코드가 화면마다 다르게 쓰여 있고, 새로 들어온 사람은 어느 것을 따라야 하는지 물어볼 데가 없습니다.

결정이 필요한 자리에서는 회의가 두 번 열립니다. 첫 회의에서 각자 의견을 말하고 결론 없이 끝나고, 일주일 뒤에 같은 이야기를 다시 합니다. 누가 정하는지가 정해져 있지 않으면 논의는 계속 열리고 코드는 그동안 두 방향으로 나뉘어 자랍니다.

사람 관리를 맡은 자리에 이 일을 함께 얹는 방법도 잘 통하지 않았습니다. 면담과 평가와 채용에 하루가 채워지면 설계 문서를 읽을 시간이 남지 않고, 그러면 기술 결정이 다시 아무도 없는 상태로 돌아갑니다. 게다가 관리 경로만 있는 조직에서는 잘 만드는 사람이 더 성장하려면 만드는 일을 그만둬야 했습니다.

그래서 기술 결정을 책임지되 사람 평가는 맡지 않는 자리가 생겼습니다. 코드를 계속 쓰면서 팀의 기술 방향을 정하는 쪽입니다.

코드를 쓰는 시간이 하루의 절반을 넘지 않습니다. 남은 절반은 남이 쓴 코드를 읽고, 무엇을 어떻게 만들지 정하고, 막힌 사람의 질문에 답하는 데 들어갑니다. 하루에 오가는 일은 일곱 종류입니다.

1. 코드 리뷰입니다. 대개 하루의 첫 일로 두는데, 리뷰가 밀리면 팀 전체가 기다리기 때문입니다. 통과시킬지 말지만 정하는 자리가 아니라 같은 방식으로 쓰이게 맞추는 자리입니다.
2. 설계 결정입니다. 새 기능의 구조를 정하고 한 장으로 적어 둡니다. 무엇을 정했는지와 왜 그렇게 정했는지, 그리고 버린 대안이 무엇이었는지를 함께 남깁니다. 마지막 항목이 빠지면 반년 뒤에 같은 논의가 처음부터 다시 열립니다.
3. 가장 어려운 조각의 구현입니다. 남들이 막힐 부분을 먼저 뚫어 두고 나머지를 나눕니다. 결제 대행사 연동처럼 문서에 없는 함정이 있는 자리가 대개 여기입니다.
4. 질문에 답하는 일입니다. 이 일은 예정표에 없고 온종일 끊어 들어옵니다. 그래서 집중해서 코드를 쓰는 시간을 오전 두 시간처럼 따로 떼어 두는 사람이 많습니다.
5. 쪼개기와 추정입니다. 프로덕트 매니저가 들고 온 요구를 며칠짜리 조각으로 나누고 각각에 크기를 매깁니다.
6. 부채 관리입니다. 구조를 정리하는 일은 눈에 보이는 화면을 늘리지 않아서 늘 밀리므로, 주기마다 일정 비율을 미리 떼어 둡니다.
7. 장애가 났을 때의 결정입니다. 되돌릴지 고쳐서 다시 낼지를 그 자리에서 정합니다.

맡지 않는 일도 분명합니다. 평가와 보상은 이 자리의 몫이 아니고, 채용은 기술 면접에 참여하지만 최종 결정을 혼자 하지 않습니다. 일정을 혼자 약속하지도 않습니다. 추정은 이쪽이 내고 약속은 제품 쪽과 함께 합니다.

하루에 말을 섞는 상대가 넷입니다. 페이지덱에서 태오가 상대하는 사람으로 보면 이렇게 갈립니다.

1. 프로덕트 매니저. 지현과는 무엇을 만들지와 얼마나 걸릴지를 맞춥니다. 요구를 받아 추정을 내는 것이 아니라, 범위를 줄이면 무엇이 짧아지는지를 함께 따지는 자리입니다.
2. 팀의 개발자들. 프론트엔드 개발자와 백엔드 개발자가 같은 기능을 양쪽에서 붙일 때 주고받을 형식을 먼저 정해 줍니다. 형식이 정해져 있으면 두 사람이 서로를 기다리지 않습니다.
3. 디자이너. 민서가 그린 화면이 지금 구조로 되는지, 안 되면 무엇을 바꾸면 되는지를 시안 단계에서 말합니다.
4. 배포와 운영을 맡은 쪽. 데브옵스 엔지니어와는 새 기능이 운영에서 어떻게 보일지를 맞춥니다. 알림 기준과 되돌리는 절차가 여기서 정해집니다.

결정 경계가 자주 흐려집니다. 무엇을 만들지는 프로덕트 매니저가 정하고 어떻게 만들지는 이 자리가 정합니다. 겹치는 자리는 일정입니다. 기술 부채를 먼저 갚을지 기능을 먼저 낼지는 둘이 함께 정하는데, 미루면 나중에 얼마가 드는지는 만드는 쪽이 더 잘 알기 때문입니다. 조직이 커져 사람 관리를 맡은 자리가 따로 생기면 사람에 관한 대화는 그쪽으로 가고 이 자리에는 기술 대화만 남습니다.

"이 구조는 제가 정하고 문서로 남길게요. 버린 안도 같이 적겠습니다."

결정과 근거를 한 사람이 책임지고 기록한다는 말입니다.

"리뷰가 이틀 밀렸습니다. 오전에 먼저 보겠습니다."

리뷰 지연이 팀 전체를 멈춘다는 인식입니다.

"이건 추정은 드릴 수 있는데 약속은 같이 정하셔야 합니다."

추정과 일정 약속을 구분하는 말입니다.

페이지덱이 결제 기능을 새로 붙일 때가 그랬습니다. 태오가 먼저 대행사 연동만 사흘 붙여 보고 문서에 없던 제약을 두 가지 찾았습니다. 그 뒤에 나머지를 태스크로 쪼개 나눴고, 지현에게는 첫 주에 찾은 제약 때문에 범위를 한 항목 줄이자고 말했습니다.

리뷰에서 한 번 부딪혔습니다. 다른 개발자가 목록 불러오는 코드를 새 방식으로 썼는데, 태오가 기존 방식과 섞이는 것을 막으려고 되돌려 달라고 했습니다. 새 방식이 나쁘지 않았지만 두 방식이 함께 남는 쪽이 더 나빴기 때문입니다. 대신 다음 분기에 전체를 새 방식으로 옮기는 작업을 목록에 올렸습니다.

코드를 가장 잘 쓰는 사람이 맡는 자리로 읽는 경우가 가장 많습니다. 기술 결정을 책임지니 자연스러운 추측입니다. 하지만 이 자리에서 하루의 절반은 결정을 남에게 설명하고 합의를 만드는 데 들어갑니다. 혼자 가장 좋은 답을 내도 팀이 그 답을 따라 쓰지 않으면 코드는 여전히 두 방식으로 남습니다. 실력만으로 자리를 채우면 결정이 통보로 전해지고, 통보로 전해진 결정은 리뷰에서 매번 다시 다퉈집니다.

승진이라고 보는 것도 흔합니다. 이름이 앞에 붙으니 그렇게 읽힙니다. 하지만 사람 관리를 맡는 경로와는 다른 줄이고, 다시 만드는 일로 돌아오는 경우도 많습니다. 승진으로 취급하면 이 자리를 거쳐야 다음으로 간다고 생각하게 되어서, 이끄는 일에 관심이 없는 사람도 성장하려면 이 자리를 지나야 하는 상태가 됩니다.