최고 기술 책임자

개발자가 세 명인 회사에는 이 자리가 필요하지 않습니다. 결정할 일이 생기면 옆자리에 대고 물어보면 되고, 누가 무엇을 하고 있는지가 눈에 다 보입니다. 기술 결정의 주인이 따로 없어도 결정이 밀리지 않습니다.

문제는 인원이 스물을 넘기면서 시작됩니다. 팀이 둘로 나뉘고 각자 자기 앞의 일정을 처리하다 보면, 같은 알림 기능을 두 팀이 서로 다른 방식으로 만들어 둔 사실을 반년 뒤에 발견하는 일이 생깁니다. 어느 쪽을 버릴지 정할 사람이 없어서 둘 다 남고, 다음에 알림을 고칠 때는 두 곳을 고쳐야 합니다. 채용도 비슷하게 흘러갑니다. 각 팀이 급한 자리를 각자 채우다 보면 비슷한 사람만 늘고, 정작 배포와 장애를 맡을 사람은 계속 비어 있습니다.

장애 때도 같은 문제가 드러납니다. 새벽에 서비스가 멈추면 누가 먼저 일어나 무엇부터 되살릴지 정해져 있어야 하는데, 팀마다 자기 몫만 알면 순서를 정할 사람이 없습니다. 30분이면 끝날 복구가 세 시간이 되는 것은 기술이 모자라서가 아닙니다.

최고 기술 책임자는 이런 결정의 주인을 한 사람으로 정해 두려고 만든 자리입니다. 여기서 맡는 결정은 기능 하나를 어떻게 구현할지가 아니라, 되돌리는 데 분기 단위의 시간이 드는 쪽입니다. 시스템을 어떤 덩어리로 자를지, 어떤 사람을 몇 명 뽑을지, 어디에 얼마를 쓸지 같은 것들입니다. 경영·전략 축에 이 자리가 함께 걸려 있는 이유도 여기 있습니다.

코드를 쓰는 시간보다 결정을 내리고 사람과 일정을 맞추는 시간이 깁니다. 하루의 대부분은 아래 다섯 가지로 채워집니다.

1. 되돌리기 비싼 기술 결정을 고릅니다. 소프트웨어 아키텍처, 곧 시스템을 어떤 덩어리로 나누고 덩어리끼리 어떻게 말을 걸게 할지에 대한 큰 설계가 여기 속합니다. 기능 하나를 고치는 데는 하루가 들지만 덩어리를 다시 자르는 데는 분기가 듭니다.
2. 채용을 설계합니다. 채용 공고의 요건을 직접 손보고, 최종 면접에 들어가고, 다음 분기에 어느 자리를 먼저 채울지 정합니다. 서버 담당을 먼저 뽑을지 QA 를 먼저 뽑을지가 반년 뒤 장애 횟수를 가릅니다.
3. 예산을 지킵니다. 서버와 도구에 나가는 돈이 월 2천만 원을 넘어서면 어느 항목을 줄일지, 사람을 한 명 더 뽑는 것과 서버를 늘리는 것 중 무엇이 나은지를 판단합니다.
4. 미뤄 둔 정리를 언제 할지 정합니다. 기술 부채는 빨리 가려고 미뤄 둔 작업이 쌓여 생기는 비용입니다. 갚는 일은 새 기능처럼 눈에 보이지 않아서, 일정에 자리를 잡아 주는 사람이 없으면 영원히 밀립니다.
5. 바깥과 이야기합니다. 투자 실사 과정에서 기술 구조를 설명하고, 도입을 검토하는 기업 고객의 기술 질문에 답하는 것도 이 자리의 몫입니다.

같은 직함이라도 회사 규모에 따라 하루가 전혀 다릅니다. 열 명일 때는 시간의 절반을 직접 코드에 쓰고, 마흔다섯 명이면 코드를 거의 쓰지 않고, 이백 명이 넘으면 관리자를 관리하는 일이 대부분입니다.

안으로는 기술 조직의 중간 자리들과, 밖으로는 제품과 경영과 고객 쪽 사람들과 붙습니다.

1. 테크 리드 — 한 팀의 기술 방향과 구현 품질을 책임지는 자리입니다. 팀 안에서 끝나는 결정은 여기서 끝나고, 팀 경계를 넘는 결정만 위로 올라옵니다.
2. 엔지니어링 매니저 — 개발 조직의 사람과 실행을 함께 맡는 자리입니다. 구성원의 성장과 일정 진행을 챙기고, 평가와 1on1 이 여기서 이뤄집니다.
3. 최고 제품 책임자와 프로덕트 매니저 — 무엇을 만들지 정하는 쪽입니다. 다음 분기에 담을 기능의 목록을 두고 만드는 데 얼마가 드는지를 맞춰 보는 대화가 반복됩니다.
4. 최고 경영자 — 예산과 일정의 최종 결정권자입니다. 기술 결정을 돈과 시간의 언어로 옮겨 설명해야 하는 상대입니다.
5. 세일즈 — 기업 고객이 도입 전에 보내는 보안 점검표에 답할 때 함께 움직입니다. 한 건이 계약의 조건이 되기도 합니다.

페이지덱에는 아직 최고 기술 책임자가 따로 없고, 그 몫을 규원과 태오가 나눠 지고 있습니다. 채용 계획과 서버 예산은 규원이 분기마다 들고 오고, 어떤 구조로 만들지에 대한 판단은 태오가 합니다. 이 방식은 마흔다섯 명까지는 버티지만, 팀이 셋으로 갈라지는 시점부터는 두 사람 사이에서 결정이 한 주씩 멈추기 시작합니다.

"그건 CTO 판단이 필요한 건이에요. 다음 주 회의로 올리죠."

한 팀 안에서 끝낼 수 없는 결정이라 위로 올린다는 뜻입니다.

"이번 분기에는 새 기능 말고 구조 정리에 두 주를 쓰겠습니다."

미뤄 둔 정리에 일정을 확보하겠다는 선언으로, 이 자리가 아니면 내기 어려운 결정입니다.

"고객사 보안 검토 질문지는 CTO가 직접 답해야 할 것 같아요."

기술 구조 전체를 설명해야 하는 문서라 담당 개발자 선에서 답할 수 없다는 판단입니다.

페이지덱에서는 이 말이 주로 분기 계획 회의에서 나옵니다. 지현이 다음 분기에 담을 기능 목록을 가져오면 태오가 그중 둘은 지금 구조로는 두 배가 든다고 답하고, 규원이 일정과 채용 중 무엇을 움직일지 정합니다. 세 사람이 같은 자리에 앉아야 끝나는 대화라, 한 사람이라도 빠지면 결론이 다음 회의로 넘어갑니다.

가장 뛰어난 개발자가 맡는 자리로 읽는 경우가 많습니다. 기술을 책임진다는 말이 곧 기술을 제일 잘한다는 뜻처럼 들려서 그렇습니다. 실제로 이 자리에서 판단하는 것은 코드의 품질보다 사람과 돈과 시간의 배분입니다. 구현 실력만 보고 자리를 맡기면 대개 두 가지 일이 함께 일어납니다. 회사는 가장 잘 만들던 사람을 회의실에 앉혀 잃고, 정작 채용과 예산은 아무도 보지 않은 채 남습니다.

직함이 곧 같은 일을 뜻한다고 보는 것도 흔합니다. 구성원 열 명인 회사의 최고 기술 책임자와 이백 명인 회사의 최고 기술 책임자는 하는 일이 겹치지 않습니다. 앞쪽은 직접 만드는 사람에 가깝고 뒤쪽은 조직을 설계하는 사람에 가깝습니다. 이 차이를 모르고 옮기면 회사는 조직을 맡아 줄 사람을 뽑았다고 여기는데 본인은 계속 코드를 짜고 있는 상황이 생깁니다.