CTO 대행이 첫 2주에 실제로 하는 일

첫 2주의 결과물은 수정 커밋이 아니라 순서표입니다

CTO 대행으로 들어가는 첫 2주에 코드를 고치기 시작하면 거의 실패합니다. 결론부터 말하면, 이 기간의 목적은 무엇이 잘못됐는지 찾는 것이 아니라 이미 모두가 알고 있는 문제들을 어떤 순서로 손댈지 정하는 것입니다. 대부분의 조직은 자기 문제를 이미 알고 있습니다. 배포가 무섭다는 것도, 테스트가 없다는 것도, 특정 개발자 한 명이 없으면 아무것도 못 한다는 것도 압니다. 모르는 것은 "그래서 월요일부터 뭘 먼저 하냐"입니다.

그래서 2주 뒤에 내놓아야 하는 문서는 진단서가 아니라 순서표입니다. 진단서는 읽고 나면 무력해지고, 순서표는 읽고 나면 다음 주 스프린트가 바뀝니다. 이 글은 그 순서표를 만들기 위해 첫 2주에 실제로 무엇을 보고 무엇을 묻는지에 대한 정리입니다. 마지막에는 이 역할을 아예 부르지 말아야 하는 상황도 함께 적었습니다.

0일 차 — 권한과 범위부터 문서로 확정합니다

첫 주가 시작되기 전에 두 가지가 정해져 있어야 합니다. 이게 없으면 1주 차의 절반이 계정 신청 대기로 사라집니다.

접근 권한 목록

시작 전에 서면으로 요청합니다. 못 주는 것이 있다면 무엇을 왜 못 주는지가 그 자체로 첫 번째 발견입니다.

• 소스 저장소 읽기 권한(조직 전체 단위. 일부만 열어 주면 의존 관계를 못 봅니다)
• CI/CD 빌드·배포 기록, 로그·모니터링 대시보드 조회 권한
• 이슈 트래커와 위키, 그리고 보관 처리된 문서
• 클라우드 콘솔 읽기 권한과 최근 청구 내역
• 외부 서비스 계약 목록과 갱신일(결제 수단이 개인 카드에 걸려 있는 경우가 드물지 않습니다)
• 운영 데이터는 접근하지 않는 것을 원칙으로 하되, 필요하면 마스킹 범위를 미리 합의

권한의 범위와 보고 대상

"CTO 대행"이라는 같은 단어가 조직마다 전혀 다른 뜻으로 쓰입니다. 최소한 이 세 가지는 시작 전에 문장으로 적어 둡니다. 첫째, 기술 결정을 승인하는 자리인지 권고하는 자리인지. 둘째, 인사 평가와 채용 결정에 관여하는지. 셋째, 보고 대상이 대표인지 이사회인지 투자자인지. 특히 셋째가 애매하면 2주 뒤 산출물이 엉뚱한 곳에서 인용됩니다.

왜 코드부터 보면 어긋나는가

코드는 결과물이지 원인이 아닙니다. 나쁜 코드를 발견했을 때 알 수 있는 것은 "이 코드가 나쁘다"뿐이고, 정작 필요한 정보인 "왜 이렇게 됐는가"와 "지금 고치면 또 이렇게 되는가"는 코드 안에 없습니다.

구체적으로 세 가지가 어긋납니다.

1. 심각도를 잘못 매깁니다

눈에 띄게 지저분한 코드는 대개 오래됐고, 오래됐는데도 살아 있다는 것은 자주 바뀌지 않는다는 뜻인 경우가 많습니다. 읽기 괴로운 것과 위험한 것은 다릅니다. 진짜 위험한 지점은 변경이 잦은 곳과 복잡한 곳이 겹치는 자리이고, 그건 최근에 여러 사람이 급하게 손댄, 겉보기엔 멀쩡한 코드인 경우가 많습니다. 코드만 읽으면 이 구분이 되지 않습니다. 변경 이력을 함께 봐야 보입니다.

2. 조직의 제약을 못 봅니다

구조가 이상하게 갈라져 있는 이유가 기술적 판단이 아니라 조직 경계나 계약 구조인 경우가 흔합니다. 코드만 보고 "합치면 된다"고 말하면, 사실은 두 조직의 릴리스 주기를 합치라는 말이 됩니다. 그건 아키텍처 제안이 아니라 조직 개편 제안이고, 2주 차 외부인이 꺼낼 카드가 아닙니다.

3. 신뢰를 잃습니다

외부에서 온 사람이 첫 주에 코드 리뷰부터 시작하면, 팀은 그것을 평가로 받아들입니다. 그 순간부터 인터뷰에서 진짜 대답이 나오지 않습니다. 첫 2주에 얻어야 할 가장 값비싼 자원은 "이 사람한테는 솔직히 말해도 되겠다"는 판단이고, 이건 한 번 놓치면 남은 계약 기간 내내 회복되지 않습니다.

오해를 막기 위해 덧붙이면, 코드를 아예 안 본다는 뜻이 아닙니다. 이력과 인터뷰에서 위험 지점이 좁혀진 뒤에 그 지점만 읽습니다. 순서가 반대일 뿐입니다.

코드보다 먼저 읽는 세 가지 기록

1주 차는 사실상 기록 읽기와 인터뷰로 채웁니다. 읽는 순서는 배포 이력, 장애 이력, 의사결정 기록입니다.

배포 이력 — 이 조직이 얼마나 자주 두려워하는가

배포 기록은 조직의 심박수입니다. 저장소와 CI 기록만 있으면 반나절이면 뽑을 수 있습니다.

# 릴리스 태그와 그 간격
git for-each-ref --sort=-creatordate \
    --format="%(creatordate:short) %(refname:short)" refs/tags | head -40

# 파일별 변경 빈도 상위 — 자주 바뀌는 곳이 곧 위험 후보
git log --since="12 months ago" --no-merges --name-only --pretty=format: \
  | grep -v "^$" | sort | uniq -c | sort -rn | head -30

# 되돌린 흔적 (git log의 --grep 은 -E 로 확장 정규식을 켤 수 있습니다)
git log --oneline --since="12 months ago" -i -E \
  --grep="revert|hotfix|rollback|긴급|롤백" | head -40

# 요일(1=월) / 시각 분포 — 배포와 수정이 언제 몰리는가
git log --since="12 months ago" --date=format:"%u %H" --pretty="%ad" \
  | sort | uniq -c | sort -k2

주의할 점이 하나 있습니다. 커밋 이력은 배포 이력의 대용품일 뿐입니다. 태그를 안 쓰거나 배포가 별도 파이프라인에서 일어나는 조직도 많으므로, 가능하면 CI/CD 도구의 배포 기록을 원본으로 삼고 git은 교차 검증에 씁니다.

여기서 보는 것은 숫자 자체가 아니라 패턴입니다.

• 배포 간격이 들쭉날쭉한가. 규칙적이면 프로세스가 있는 것이고, 몰아치기와 침묵이 반복되면 배포가 이벤트로 취급되고 있다는 뜻입니다.
• 배포 직후 핫픽스가 따라붙는 비율. 배포 횟수보다 이 비율이 조직의 실제 자신감을 보여줍니다.
• 배포가 특정 요일과 시간대에 몰려 있는가. 심야·주말 배포가 상시화됐다면 대개 롤백을 신뢰하지 못한다는 뜻입니다. 다만 규제 산업의 정해진 작업 창구, 트래픽 피크 회피, 계약상 유지보수 시간대처럼 외부에서 강제된 제약일 수도 있습니다. 그건 역량 문제가 아니라 조건입니다. 팀에 "낮에 배포해도 되느냐"고 물어보면 둘 중 어느 쪽인지 바로 갈립니다.
• 변경이 소수 파일에 극단적으로 쏠려 있는가. 그렇다면 그 파일이 문서상의 아키텍처보다 더 정확한 아키텍처입니다. 다만 자동 생성 파일, 잠금 파일, 번역 리소스처럼 자주 바뀌는 게 당연한 것들은 먼저 걸러 냅니다.

장애 이력 — 같은 사고가 반복되는가

포스트모템 문서가 정리돼 있는 조직은 드뭅니다. 없으면 이슈 트래커, 고객 문의 채널, 사내 메신저의 장애 채널을 봅니다. 문서가 없다는 사실 자체가 첫 번째 발견입니다.

장애 이력에서 확인하는 것은 원인 기술이 아니라 이런 것들입니다.

• 누가 먼저 알았는가. 모니터링이 알렸는지, 고객이 알렸는지. 고객이 먼저 아는 비율이 높으면 무엇을 고치든 그 성과를 증명할 수 없습니다. 관측이 먼저입니다.
• 같은 유형이 반복되는가. 반복은 재발 방지 조치가 실행되지 않았다는 뜻이고, 그건 기술 문제가 아니라 후속 조치를 추적하는 사람이 없다는 뜻입니다. 포스트모템의 액션 아이템이 실제 티켓으로 전환됐는지, 그 티켓이 닫혔는지를 표본으로 몇 개만 따라가 보면 답이 나옵니다.
• 복구에 특정 인물이 반드시 필요했는가. 복구 절차가 사람 머릿속에 있으면, 그 사람의 휴가가 곧 리스크입니다.
• 원인 규명이 사람 이름으로 끝났는가. "누가 실수했다"로 끝나는 기록이 이어진다면, 이후 인터뷰에서 아무도 사실을 말하지 않을 것을 각오해야 합니다.
• 장애 등급 기준이 있는가. 모든 사고가 같은 무게로 기록되는 조직에서는 심각한 사고가 사소한 문의에 파묻혀 보이지 않습니다.

의사결정 기록 — 되돌릴 수 없는 결정이 어디에 있는가

ADR(아키텍처 결정 기록) 같은 형식을 갖춘 곳은 흔치 않습니다. 그래도 흔적은 남아 있습니다. 오래된 기술 검토 문서, 제안서, 스프린트 회고, 외주 계약서, 클라우드 청구서가 모두 결정의 기록입니다. 특히 청구서는 정직합니다. 아무도 설명하지 못하는 비용 항목은 대개 잊힌 결정의 잔해입니다.

여기서 찾는 것은 되돌리기 비싼 결정입니다. 데이터 저장소 선택, 멀티테넌시 모델, 인증·권한 체계, 과금 구조, 외부 서비스에 대한 락인, 그리고 스키마의 근본 형태. 이런 것들은 나중에 바꾸려면 데이터 마이그레이션과 정지 시간이 따라옵니다. 반대로 프레임워크 버전, 코드 스타일, CI 도구, 로깅 라이브러리는 상대적으로 싸게 바꿀 수 있습니다. 이 두 종류를 같은 회의에서 같은 무게로 다루는 조직이 의외로 많고, 그 결과 되돌릴 수 있는 결정에 몇 주를 쓰고 되돌릴 수 없는 결정은 한 사람이 즉흥적으로 정합니다.

결정의 배경을 아무도 설명하지 못하는 영역이 있다면 그 자체가 위험 신호입니다. 이유를 모르는 제약은 건드릴 수도 없고 지킬 수도 없습니다.

인터뷰에서 묻는 질문, 묻지 않는 질문

1주 차에 개발자와 이해관계자를 1:1로 만납니다. 30~45분이면 충분하고, 그룹으로 묶으면 아무 말도 듣지 못합니다. 전원을 만날 수 없다면 무작위 표본이 아니라 경계에 있는 사람부터 만납니다. 가장 오래된 재직자, 가장 최근 입사자, 온콜을 가장 많이 서는 사람, 그리고 개발 조직 바깥(영업·운영·CS·대표)에서 개발팀과 가장 자주 부딪히는 사람. 최근 입사자가 특히 값집니다. 아직 적응하지 않아서 무엇이 이상한지를 기억하고 있습니다.

실제로 던지는 질문

• "지난 6개월에 가장 오래 걸린 작업은 무엇이었고, 시간의 대부분은 어디서 새어 나갔습니까?"
• "오늘 한 줄짜리 수정을 프로덕션에 반영한다면, 몇 단계를 거쳐야 하고 누구의 승인이 필요합니까?"
• "손대기 무서운 코드가 있습니까? 왜 무섭습니까?"
• "내일 장애가 난다면 어디서 날 것 같습니까?" — 팀은 대체로 이미 알고 있습니다. 여러 사람의 답이 한 곳으로 모이면 그 지점은 증거를 더 찾을 것도 없습니다.
• "당신이 2주 휴가를 가면 멈추는 일이 있습니까?"
• "이 시스템에서 지금 아무도 이해하지 못하는 부분이 있습니까?"
• "최근에 제안했다가 반려된 개선이 있습니까? 왜 반려됐습니까?" — 조직의 의사결정 방식이 가장 잘 드러나는 질문입니다.
• "신입이 들어와 로컬 환경을 띄우고 첫 커밋을 반영하기까지 며칠 걸립니까?" — 문서화 수준과 환경 복잡도를 한 번에 재는 질문입니다.
• (개발 조직 바깥에) "개발팀에 요청했을 때 가장 답답했던 순간은 언제였습니까?"

묻지 않는 질문

• "이 코드는 누가 짰습니까?" — 책임 추궁으로 들립니다. 필요하면 이력에서 확인하면 되고, 대개 확인할 필요도 없습니다.
• "누구 때문에 이렇게 됐습니까?" — 이 질문을 한 번 하면 그 이후 인터뷰는 전부 방어적으로 바뀝니다.
• "이 팀에서 누가 제일 일을 못합니까?" — 인사 평가는 이 역할의 첫 2주 업무가 아닙니다. 성과 문제는 관찰이 쌓인 뒤에 다루는 것이지, 전언으로 판단할 문제가 아닙니다.
• "전임자는 왜 나갔습니까?" — 궁금해도 묻지 않습니다. 답은 어차피 시간이 지나면 저절로 들어오고, 먼저 물으면 편 가르기에 초대받습니다.

인터뷰에서 나온 말은 개인과 분리해서 기록합니다. 2주 뒤 보고서에 "누가 이렇게 말했다"가 들어가면, 그 조직에서 다음 인터뷰는 영원히 성립하지 않습니다. 반대로 여러 사람이 독립적으로 같은 말을 한 항목은 출처를 지운 채 그대로 올립니다. 그건 이미 개인의 의견이 아니라 조직의 관측입니다.

위험도로 정렬하는 법

1주 차가 끝나면 문제 목록이 수십 개 나옵니다. 이걸 그대로 보고하면 아무 일도 일어나지 않습니다. 정렬해야 합니다. 실무에서 쓸 만한 축은 다섯 개입니다.

이 다섯 축을 점수로 곱해서 정교한 숫자를 만들려는 유혹이 있는데, 권하지 않습니다. 근거 없는 가중치를 곱하면 결론이 숫자의 권위를 빌려 반박 불가능해집니다. 첫 2주에 모은 것은 대부분 표본이 적은 관찰과 진술이고, 그런 입력으로 소수점 있는 점수를 만들면 정밀도가 근거를 앞지릅니다. 대신 세 묶음으로 나눕니다.

1. 출혈 — 지금도 손실이 나고 있고, 시간이 갈수록 나빠지는 것. 예: 감지되지 않는 장애, 롤백 불가능한 배포, 만료가 임박한 인증서나 계약, 이미 알려진 취약 버전이 노출된 상태.
2. 지뢰 — 지금은 조용하지만 터지면 회복이 어려운 것. 예: 백업 복원 절차를 한 번도 검증하지 않은 상태, 한 사람만 아는 운영 절차, 되돌릴 수 없는 데이터 구조 결정, 퇴사자 개인 계정에 걸린 결제나 도메인.
3. 마찰 — 매일 조금씩 속도를 갉아먹는 것. 예: 느린 빌드, 수동 QA, 로컬 환경 구축에 며칠 걸리는 상태, 리뷰 대기가 길어 브랜치가 쌓이는 상태.

순서는 대개 출혈 → 지뢰 → 마찰입니다. 마찰이 가장 눈에 띄고 개발자들이 가장 크게 호소하지만, 출혈을 막지 않은 상태에서 개발 속도를 올리면 손실이 나는 속도만 빨라집니다. 다만 마찰 항목 중에서 하루 이내에 해결되고 모두가 체감하는 것 한두 개는 첫 2주 안에 처리합니다. 빌드 캐시 하나, 죽어 있던 알림 채널 하나여도 됩니다. 신뢰를 사는 비용으로 그만한 것이 없습니다.

예외도 분명히 해 둡니다. 지뢰 중에서 법·계약·보안 기한이 걸린 항목은 출혈보다 먼저 갑니다. 개인정보 처리 요건이나 만료되는 계약처럼 날짜가 정해진 것은 우선순위 논쟁의 대상이 아니라 일정의 문제입니다.

2주 뒤에 내놓는 산출물의 형태

분량이 많은 보고서는 실패한 보고서입니다. 실제로 쓰이는 형태는 다음 다섯 가지입니다.

1. 한 장짜리 시스템 지도

서비스, 데이터 저장소, 외부 연동, 배포 경로를 한 장에 그린 그림입니다. 정확도보다 합의가 목적입니다. 팀 전원이 같은 그림을 보고 "여기가 맞다/틀리다"를 말할 수 있게 되면 그 다음 논의의 속도가 달라집니다. 이 그림이 없는 조직이 생각보다 많습니다. 그리면서 아무도 설명하지 못하는 화살표가 하나쯤 나오는데, 대개 거기가 가장 위험합니다.

2. 순서가 매겨진 위험 목록

출혈·지뢰·마찰로 묶고, 각 항목에 증거(어떤 기록에서 나왔는지), 영향, 지금 손대지 않으면 어떻게 되는지를 한 줄씩 붙입니다. 추정이면 추정이라고 씁니다. 근거가 인터뷰 진술뿐이면 그렇게 적습니다. 이 정직함이 문서의 수명을 결정합니다.

3. 되돌릴 수 없는 결정 목록

앞으로 6개월 안에 내려야 하는데 한 번 정하면 되돌리기 비싼 결정들. 각각에 대해 언제까지 정해야 하는지와 지금 결정을 미루는 비용을 씁니다. 경영진이 실제로 읽는 장은 대개 여기입니다.

4. 30 / 60 / 90일 실행안

각 구간에 목표를 두세 개만 둡니다. 다섯 개가 넘으면 아무것도 안 됩니다. 그리고 각 항목에 담당자 이름과 완료를 판정하는 문장이 있어야 합니다. "모니터링 개선"은 판정할 수 없고, "결제 실패가 5분 안에 담당 채널로 알림되고, 알림 수신을 실제 테스트로 확인했다"는 판정할 수 있습니다. 담당자가 CTO 대행 본인으로만 채워진 계획은 계약 종료와 함께 사라집니다.

5. 지금 당장 멈춰야 할 것 목록

가장 짧지만 가장 강한 장입니다. 진행 중인데 중단하는 편이 나은 프로젝트, 쓰지 않는데 비용이 나가는 인프라, 아무도 보지 않는 리포트, 아무도 대응하지 않는 알림. 새로 시작할 일보다 멈출 일을 먼저 제시하는 편이 조직의 여력을 만듭니다. 특히 아무도 대응하지 않는 알림은 반드시 끕니다. 무시하는 습관이 붙은 알림 채널은 나중에 진짜 장애가 나도 작동하지 않습니다.

진단을 개선안으로 바꾸는 순서

목록이 나왔다고 개선이 시작되는 것은 아닙니다. 순서를 잘못 잡으면 좋은 진단도 무산됩니다. 실무적으로 안전한 순서는 이렇습니다.

1단계 — 보이게 만든다

최소한의 관측부터 세웁니다. 에러 수집, 핵심 지표 몇 개, 장애 알림 경로. 여기서 말하는 핵심 지표는 대시보드를 가득 채우는 수십 개가 아니라, 서비스가 돈을 버는 경로 하나에 대한 성공률과 응답 시간 분포, 그리고 배포와 관련된 몇 가지입니다. 배포 빈도, 변경 리드 타임, 변경 실패율, 복구 시간처럼 널리 쓰이는 지표를 그대로 쓰면 정의를 새로 만들 필요가 없다는 장점이 있습니다.

이걸 먼저 하는 이유는 두 가지입니다. 하나는 이후 개선의 효과를 증명하기 위해서고, 다른 하나는 측정되지 않는 개선은 예산 재승인을 못 받기 때문입니다. 6개월 뒤에 "좋아졌습니까?"라는 질문을 받았을 때 비교할 기준선이 없으면 계약은 거기서 끝납니다.

2단계 — 되돌릴 수 있게 만든다

배포와 롤백입니다. 되돌릴 수 있게 되는 순간 팀의 위험 감수 성향이 바뀌고, 그때부터 나머지 개선이 훨씬 싸집니다. 반대로 롤백이 안 되는 상태에서 구조를 바꾸기 시작하면, 한 번의 실패로 개선 자체가 금지됩니다.

여기서 자주 놓치는 것이 데이터입니다. 애플리케이션은 이전 버전으로 되돌려도 스키마 변경은 되돌아가지 않습니다. 그래서 이 단계의 실제 과제는 배포 도구 도입이 아니라 스키마 변경을 애플리케이션 배포와 분리해 앞뒤로 호환되게 만드는 습관입니다. 컬럼을 추가하고, 양쪽을 함께 쓰다가, 나중에 제거하는 단계적 변경이 자리 잡아야 롤백이 의미를 가집니다. 백업도 같습니다. 백업이 존재한다는 사실과 복원이 된다는 사실은 다른 이야기이고, 후자는 한 번 복원해 보기 전까지 아무도 모릅니다.

3단계 — 출혈을 막는다

위에서 정렬한 출혈 항목을 처리합니다. 이 단계는 구조를 바꾸지 않고 증상을 멈추는 것이 목표입니다. 근본 해결을 미루는 것이 맞습니다. 지혈이 먼저입니다. 다만 임시 조치에는 반드시 만료일과 담당자를 붙여 남깁니다. 그러지 않으면 이 단계의 우회 조치가 몇 년 뒤 다음 사람이 이력을 뒤지며 "왜 이렇게 돼 있지"라고 묻는 코드가 됩니다.

4단계 — 구조를 바꾼다

여기서야 아키텍처 이야기를 꺼냅니다. 1~3단계 없이 4단계부터 시작하는 제안서는 대부분 실행되지 않고, 실행되면 더 나쁜 결과를 냅니다. 관측이 없으면 바꾼 것이 나아졌는지 알 수 없고, 롤백이 없으면 중간에 멈출 수 없기 때문입니다. 그리고 구조 변경은 한 번에 한 축만 건드립니다. 저장소를 바꾸면서 동시에 배포 방식과 언어를 바꾸면, 문제가 생겼을 때 어느 변경 때문인지 아무도 말하지 못합니다.

그리고 하나 더 — 인수인계 가능한 형태로

CTO 대행의 성공 기준은 재계약이 아니라 자기가 없어도 되는 상태입니다. 그래서 모든 개선 항목에는 내부 담당자가 붙어야 하고, 판단의 근거를 문서로 남겨야 합니다. 본인만 운영할 수 있는 파이프라인을 만들어 놓는 것은 의존도를 하나 더 만드는 일이고, 애초에 진단서에서 지적했던 그 문제와 같은 종류입니다. 실무적으로는 마지막 4분의 1 기간부터 회의 진행과 결정 설명을 내부 담당자가 하게 하고, 대행은 배석만 합니다. 그 자리에서 설명이 막히면 인수인계가 안 된 것이고, 그 사실은 계약이 끝나기 전에 아는 편이 낫습니다.

언제는 CTO 대행을 부르지 말아야 하는가

이 역할이 잘 맞지 않는 상황이 분명히 있습니다. 아래에 해당한다면 비용 대비 효과가 나오지 않습니다.

답이 이미 정해져 있고 외부의 도장만 필요한 경우

"이 시스템을 새로 만들어야 한다는 결론이 나오면 좋겠다"는 요청이 사전에 들어오면, 그건 진단이 아니라 근거 조달입니다. 이 경우 2주 뒤 보고서는 조직 내부의 정치에 소비되고 시스템은 그대로입니다.

기술 결정권을 실제로 넘길 생각이 없는 경우

창업자가 여전히 모든 기술 결정을 직접 하고 싶어 하는 조직이 있습니다. 그 자체는 나쁜 것이 아닙니다. 다만 그 상태에서 CTO 대행을 두면 조언자가 두 명 생기고 팀은 누구 말을 들을지 몰라 더 느려집니다. 이 경우엔 대행이 아니라 기간 한정 기술 자문으로 범위를 좁히는 편이 정직합니다.

인력 조정의 명분이 필요한 경우

외부인의 진단을 감원 근거로 쓰려는 의도가 보이면 맡지 않는 편이 낫습니다. 그런 의도는 팀이 먼저 눈치채고, 눈치챈 순간 인터뷰에서 나오는 모든 정보가 오염됩니다. 그 상태의 진단서는 회사에도 쓸모가 없습니다.

엔지니어가 두세 명이고 문제가 명확한 경우

사람이 적고 병목이 하나로 뚜렷하면, 진단에 2주를 쓰는 것보다 경험 있는 시니어 한 명을 채용하거나 해당 영역만 짧게 자문받는 것이 훨씬 싸고 빠릅니다. CTO 대행이 값을 하는 지점은 문제가 여러 개이고 서로 얽혀 우선순위를 정할 수 없을 때입니다.

기술이 병목이 아닌 경우

매출이 나지 않는 이유가 제품 방향이나 시장에 있는데 개발 조직을 손보는 경우가 있습니다. 첫 주 인터뷰에서 이 정황이 보이면 그 사실 자체를 먼저 보고해야 합니다. 계약을 유지하려고 기술 개선안을 만들어 주는 것이 가장 나쁜 선택입니다.

실사나 인수 일정이 코앞인 경우

2주 뒤에 기술 실사가 잡혀 있다면 필요한 것은 개선이 아니라 실사 대응입니다. 목적이 다르고, 산출물의 형태도 다르며, 이 기간에 시스템을 건드리는 것은 위험만 늘립니다. 그건 별개의 일로 규정하고 시작해야 합니다.

지금 대형 장애 한복판인 경우

불이 나 있는 동안에는 진단이 아니라 손이 필요합니다. 이때 부르는 것은 CTO 대행이 아니라 해당 영역을 아는 엔지니어입니다. 진단은 불이 꺼지고, 사람들이 다시 잠을 자기 시작한 뒤에 시작해야 합니다. 장애 대응 중에 받은 인터뷰 답변은 그때의 감정이 섞여 있어 우선순위를 왜곡합니다.

정리

첫 2주에 하는 일은 결국 세 가지로 줄어듭니다. 기록을 읽어 사실을 모으고, 사람을 만나 맥락을 채우고, 그 둘을 합쳐 순서를 정하는 것입니다. 코드 내용은 위험 지점이 좁혀진 뒤에 봐도 늦지 않습니다.

그리고 이 기간에 가장 자주 필요한 판단은 무엇을 시작할지가 아니라 무엇을 하지 않을지입니다. 모든 문제를 다루겠다는 계획은 아무 문제도 해결하지 못하고, 외부인이 내놓은 그런 계획은 조직에 냉소만 남깁니다. 두세 개만 고르고, 그것이 왜 먼저인지를 설명할 수 있고, 그 두세 개에 내부 담당자 이름이 붙어 있으면 첫 2주는 성공한 것입니다.

같은 주제의 다른 글

• 기술 부채를 숫자로 말하는 법
• 외주 개발 계약에서 반드시 정해 두어야 할 것들

맘소프트는 19년 넘게 금융 · 엔터프라이즈 · 모바일 시스템을 만들어 왔습니다. 여기 적는 글은 그 과정에서 실제로 부딪히고 해결한 것들입니다.

• 기술 블로그 전체 목록
• 이전 글 — 오프라인 우선 앱을 설계한다는 것
• 다음 글 — 기술 부채를 숫자로 말하는 법