엔지니어링 매니저

개발자가 스무 명쯤으로 늘어난 회사에서는 비슷한 일이 반복됐습니다. 코드를 가장 잘 짜는 사람이 팀장이 되고, 그 사람이 설계도 하고 면접도 보고 연봉 협상 자리에도 들어갔습니다. 직함은 하나인데 성격이 다른 일 세 덩어리가 한 사람에게 얹힌 셈입니다.

그래서 이런 장면이 흔했습니다. 장애가 터진 날 팀장이 새벽까지 서버를 붙들고 있다가, 아침에 잡혀 있던 팀원 면담을 다음 주로 미룹니다. 미뤄진 면담은 분기 평가 자리에서야 열리고, 팀원은 자기가 반년 동안 무엇으로 평가받고 있었는지를 그날 처음 듣습니다. 나중에 퇴사 이유를 물으면 기술적으로 배울 게 없어서가 아니라 내가 어디로 가고 있는지 아무도 말해 주지 않아서라는 답이 돌아왔습니다.

엔지니어링 매니저는 그 세 덩어리에서 사람과 실행을 떼어 한 사람의 본업으로 만든 자리입니다. 팀원 한 명이 무엇을 잘하고 어디서 막혀 있는지 아는 일이 틈날 때 하는 일에서 달력에 자리를 잡은 일로 바뀌었습니다.

하루의 절반 이상이 회의와 대화로 채워지고, 코드를 직접 만지는 시간은 있어도 한두 시간입니다.

반복되는 일은 다섯 갈래입니다.

1. 1on1 — 팀원과 둘이 앉아 정기적으로 갖는 개별 대화입니다. 보통 격주 30분으로 잡고, 진척 보고가 아니라 막힌 것과 앞으로 하고 싶은 것을 듣는 자리로 씁니다.
2. 우선순위 조정 — 제품 쪽이 들고 온 요청과 팀이 쌓아 둔 정리 작업 사이에서 이번 주기에 무엇을 넣을지 정합니다. 기술 부채처럼 당장 눈에 보이는 결과가 없는 작업을 끼워 넣는 것도 여기서 합니다.
3. 채용 — 자리를 열고, 서류를 보고, 면접에 들어갑니다. 팀이 커지는 시기에는 업무 시간의 30퍼센트 가까이가 여기로 갑니다.
4. 성과 평가 — 반기마다 팀원의 성과와 역량을 정리해 등급과 보상에 연결합니다. 평가 기간에만 하는 일로 보이지만 근거가 되는 기록은 1on1 때마다 쌓아 둡니다.
5. 방해 요소 치우기 — 온콜 당번이 감당하지 못하는 장애, 다른 팀을 기다리다 멈춘 작업, 결정이 나지 않아 멈춘 사안을 대신 끌고 갑니다.

시간이 어디로 가는지를 두고 착각이 잦습니다. 위 다섯 가지 가운데 결과가 그 주에 눈에 보이는 것은 하나도 없습니다. 그래서 일을 시작한 지 얼마 안 된 매니저는 금요일 저녁에 이번 주에 내가 만든 게 뭐지 싶어 남는 시간에 기능을 하나 붙잡습니다. 그러면 다음 주 1on1 두 개가 밀립니다.

하루에 말을 섞는 상대가 네 종류로 나뉩니다.

팀원인 개발자가 가장 많은 시간을 차지합니다. 1on1, 작업 배정, 승진 케이스 준비가 모두 이쪽입니다. 그다음이 제품과 디자인입니다. 다음 분기에 무엇을 만들지는 제품 쪽이 정하지만 언제까지 가능한지는 매니저가 답하므로, 둘이 합의하지 못한 일정은 팀에 내려가지 않습니다.

기술 방향을 이끄는 사람과는 역할을 나눠 씁니다. 어떤 구조로 만들지는 그쪽이 정하고, 그 결정을 누가 언제 맡을지는 매니저가 정합니다. 이 경계가 흐리면 한 사안을 두고 두 사람이 다른 답을 주는 일이 생기므로, 대개 팀을 꾸릴 때 무엇을 누가 정하는지를 먼저 적어 둡니다.

마지막이 인사와 경영진입니다. 헤드카운트 한 자리를 더 받을지, 보상 조정 폭을 어떻게 할지, 다음 분기에 팀을 쪼갤지 같은 이야기가 여기서 오갑니다. 팀원은 이 대화를 직접 보지 못하므로, 결과만 통보받지 않도록 무엇이 논의됐는지를 옮겨 주는 것도 매니저의 일입니다. 채용 자리가 한 분기 미뤄졌다면 그 사실과 이유를 다음 주 팀 회의에서 말해 두는 식입니다.

"그 얘기는 다음 1on1 때 따로 하시죠."

여러 사람 앞에서 다룰 사안이 아니라 개인의 상황에 가깝다고 판단했다는 뜻입니다.

"이번 분기에 태오 승진 케이스 올리려고 하는데, 근거 자료 같이 봐 주실래요?"

평가와 승진 제안의 권한이 매니저에게 있고, 그 판단을 문서로 남겨야 한다는 뜻입니다.

"그건 제가 위에 이야기할게요. 팀은 계획대로 가 주세요."

조직 사이의 협상을 매니저가 떠안아 팀의 작업을 건드리지 않겠다는 말입니다.

페이지덱의 개발팀은 열두 명이고 엔지니어링 매니저가 한 명 있습니다. 화요일 오후는 통째로 1on1 에 비워 둡니다. 지현이 다음 분기 계획을 들고 오면 매니저는 사람 쪽 사정을 얹어 답합니다. 태오가 온콜 주간이라 두 주는 절반만 쓸 수 있고, 새로 들어온 개발자가 자리 잡는 데 한 달이 더 필요하다는 식입니다. 규원이 개발 인원을 두 명 늘릴지 물을 때 근거를 만들어 오는 것도 이 자리입니다.

개발을 그만둔 사람이 가는 자리라는 오해가 가장 흔합니다. 매니저가 커밋을 거의 올리지 않으니 그렇게 보입니다. 실제로는 코드를 쓰는 양이 줄 뿐 읽는 양은 늘어납니다. 어떤 결정이 왜 그렇게 내려졌는지 모르면 일정도 평가도 근거 없이 말하게 되기 때문입니다. 설계 문서에 의견을 남기고 코드 리뷰를 읽는 쪽으로 관여 방식이 옮겨 갈 뿐, 기한이 걸린 기능 하나를 직접 맡는 일은 팀에 넘깁니다. 이 오해를 그대로 두면 두 방향으로 손해가 납니다. 기술을 놓기 싫은 사람이 자리를 피하다 팀에 관리자가 없는 채로 굴러가거나, 반대로 코드를 계속 붙들고 있는 매니저 밑에서 팀원들이 결정이 나오기를 기다리며 멈춰 섭니다.