승진이 아니라 직업을 바꾸는 것
사실 저도 곧 이 전환을 하게 됩니다. 그래서 요즘 경험자들을 붙잡고 이야기를 듣고, 구할 수 있는 책은 다 읽어보는 중입니다. 지금까지 가장 분명하게 배운 건 이겁니다. 엔지니어에서 엔지니어링 매니저가 되는 건 한 계단 올라가는 게 아니라, 완전히 다른 직업으로 옆걸음질하는 거라는 것. 내 아웃풋은 더 이상 코드가 아니라 팀이 만들어내는 모든 것이 됩니다. 다들 이 말을 하는데, 다들 그 무게를 과소평가한다고 하네요.
실제로 달라지는 것
기술 문제를 직접 푸는 대신 사람 문제를 풀게 됩니다. 캘린더는 1:1 미팅, 기획 회의, 팀 간 조율로 채워지고, 채용과 성과 평가가 내 책상 위로 올라옵니다. 일의 중심은 팀이 일에 집중하는 데 필요한 것들, 그러니까 맥락과 명확한 우선순위, 그리고 최대한 적은 잡음을 확보해 주는 쪽으로 옮겨갑니다.
곤란한 지점은, 아키텍처 논의에서 밀리지 않고 제대로 된 기술 판단을 내릴 만큼의 기술력은 유지하면서도, 코드를 짜는 사람은 더 이상 내가 아니라는 걸 받아들여야 한다는 겁니다. 둘 다 하려던 매니저들을 몇 명 봤는데, 대개 둘 다 어중간해지더군요.
중요해 보이는 스킬들
일의 대부분은 커뮤니케이션입니다. 팀과 프로덕트와 리더십 사이의 통역이 되는 건데, 이 세 그룹이 같은 이야기를 하고 있는지 확인하는 데만 놀랄 만큼 많은 시간이 들어갑니다. 어떤 프로세스보다 중요한 건 신뢰입니다. 팀원들이 “이거 망가졌어요"라고 편하게 말하지 못하면, 문제를 가장 늦게 아는 사람이 바로 내가 됩니다. 캘린더는 정말로 사람을 집어삼키려 들기 때문에, 생각할 시간과 팀을 위한 시간을 지키는 건 끝나지 않는 싸움입니다. 그리고 회사가 뭘 이루려는지 이해하지 못하면 팀을 쓸 만한 방향으로 이끌 수도 없습니다.
직함이 오기 전에 준비하기
계속 듣는 조언이자 제가 직접 보증할 수 있는 부분은 이겁니다. 직함을 받기 전에 먼저 리드해 보라는 것. 프로젝트를 굴려 보고, 누군가를 멘토링하고, 뭔가를 조직해 보는 거죠. 저는 지난 1년 정도를 프로젝트 리드 역할로 보냈는데, 그 경험이 어떤 책보다 큰 도움이 되고 있습니다. 물론 책도 도움이 됩니다. Camille Fournier의 “The Manager’s Path"는 모두가 추천하는 책인데, 읽어 보니 이유를 알겠더군요. 기술력도 계속 갈고닦으세요. 아키텍처 논쟁은 사라지지 않으니까요. 그리고 이미 이 전환을 겪은 멘토를 찾으세요. 지나고 나서야 뻔해 보이는 실수들을 미리 피하게 해 줍니다.
트레이드오프
무엇이 어떻게 만들어질지에 대한 영향력은 커지지만, 직접 만드는 일은 거의 없어집니다. 어떤 날은 그게 뿌듯할 테고, 어떤 날은 코드가 사무치게 그리울 겁니다. 겪어본 사람들은 하나같이 그게 정상이라고 하네요. 6개월 뒤에 다시 물어봐 주세요.