기술 리더의 공백을 막는 승계 구조 설계

리더가 비면 왜 일정이 아니라 시스템이 멈출까?

핵심 서비스나 플랫폼을 오래 이끈 기술 리더가 이동·휴가·역할 전환을 앞두면, 많은 조직은 후임자 이름과 인수인계 일정을 먼저 정합니다. 그러나 실제 위험은 빈 자리가 아닙니다. "이 변경은 어느 고객 경로를 손상시키는가", "지금의 오류율은 롤백 기준인가", "이 의존성을 제거할 수 있는 조건은 무엇인가"에 답할 근거가 한 사람의 기억에만 있다는 사실입니다. 이 상태에서 후임자를 지정해도 질문의 종착지가 바뀌지 않으면, 조직은 리더를 교체했을 뿐 판단 대기열은 유지합니다.

Google SRE가 말하는 toil은 반복적이고 예측 가능한 운영 작업이 서비스 성장에 따라 늘어나는 위험을 설명합니다. 기술 리더에게만 같은 판단 질문이 되풀이된다면 그것 역시 사람의 성실성 문제가 아니라 제거해야 할 운영 대기열입니다. 특히 긴급 변경, 외부 팀의 예외 요청, SLO 해석, 비가역 데이터 변경이 한 통로에 모이면 리더의 부재는 곧 고객 영향의 불확실성으로 번집니다.

그렇다면 개인의 경험을 어떻게 복사할 수 있을까요? 핵심은 지식을 전부 옮기는 것이 아니라, 결정이 발생하는 위치를 작고 검증 가능하게 분해하는 데 있습니다.

왜 런북만 넘기면 예상 밖의 상황에서 멈출까?

런북은 이미 알려진 실패에서 매우 유용합니다. 경보를 확인하고, 트래픽을 우회하고, 되돌릴 수 있는 배포를 중단하는 절차는 빠르게 실행되어야 합니다. 다만 명령 목록만 남긴 런북은 새로운 조합의 장애에서 답을 주지 못합니다. 승계 문서에는 실행 절차 외에 세 종류의 판단 정보가 필요합니다.

첫째는 고객 약속입니다. 서비스가 지켜야 하는 사용자 경험, 허용 가능한 지연과 데이터 손실, 위반 시 우선하는 조치가 명확해야 합니다. 둘째는 불변 조건과 위험 경계입니다. 데이터 정합성, 보안 권한, 외부 계약처럼 되돌리기 어려운 변경을 구분합니다. 셋째는 재검토 신호입니다. 어떤 지표·비용·트래픽 변화가 나오면 과거 결정을 다시 열어야 하는지 기록합니다. 이 세 층이 있으면 후임자는 결론을 암기하지 않고 새로운 상황을 해석할 수 있습니다.

이는 ADR을 많이 쓰자는 주장과는 다릅니다. ADR이 결정을 팀 자산으로 남기는 장치라면, 승계 구조는 그 기록을 실제 권한과 연습 경로에 연결하는 일입니다. Google의 코드 리뷰 연구가 지적하듯 리뷰는 결함 탐지뿐 아니라 지식과 관행을 공유하는 통로가 될 수 있습니다. 다만 모든 리뷰에 서술을 늘리면 흐름이 무너집니다. 고객 약속·비가역 변경·장애 대응처럼 다음 리더가 반드시 알아야 할 경계에만 판단 이유를 남겨야 합니다.

[고객 약속] ──> [불변 조건] ──> [가역적 변경]
      │                 │                 │
      ▼                 ▼                 ▼
[SLO·영향 지표]   [검토 책임자]     [후임 독립 실행]
      │                 │                 │
      └──────────> [재검토 신호와 기록] <─┘

여기서 중요한 질문이 남습니다. 기록을 읽었다는 사실이 아니라, 실제로 판단과 실행을 분리해 수행할 수 있는지는 어떻게 확인할까요?

후임자는 어떤 변경부터 독립 실행해야 할까?

가장 안전한 승계 단위는 가역적이고 영향 범위가 제한된 변경입니다. 예를 들어 관측 대시보드의 임계값 조정, 기능 플래그의 제한된 롤아웃, 재시도 한도의 작은 조정처럼 사전 조건·성공 지표·롤백 경로를 명확히 둘 수 있는 일입니다. 후임자는 변경 전에 고객 영향과 실패 가설을 적고, 실행 중에는 정한 지표를 관찰하며, 종료 후에는 판단이 맞았는지 기록합니다. 기존 리더는 승인자가 아니라 관찰자·코치로 참여합니다.

▲ 역할표가 아닌 판단 카드와 검증 기록으로 구성하는 실무 승계 구조

이 표를 성과 평가표로 쓰면 안 됩니다. 목적은 후임을 시험하는 것이 아니라 문서·권한·관측 중 어디가 불완전한지 찾는 것입니다. 독립 실행에서 막힌 지점이 있다면 개인의 준비 부족이라고 결론 내리기 전에, 권한이 과도하게 넓은지, 고객 영향 지표가 보이지 않는지, 롤백이 실제로 가능한지 확인해야 합니다.

준비도를 직감이 아닌 관측 가능한 신호로 판단하는 법

승계를 앞둔 조직은 흔히 “이제 혼자 할 수 있겠는가”를 묻습니다. 이 질문은 필요하지만 너무 넓어서 답이 사람의 인상으로 흐르기 쉽습니다. 더 좋은 방법은 준비도를 네 가지 신호로 나누어 관찰하는 것입니다. 첫째, 후임자가 요청을 받았을 때 담당자를 찾기 전에 고객 영향과 관련 지표를 먼저 확인하는가입니다. 둘째, 변경 계획 안에 정상 경로뿐 아니라 실패 가설과 중단 조건이 들어 있는가입니다. 셋째, 예상 밖의 질문 앞에서 즉시 정답을 요구하기보다 문서·대시보드·과거 결정을 연결해 근거를 제시하는가입니다. 넷째, 실행 뒤에 자신이 고른 기준이 맞았는지 기록하고 다음 기준을 수정하는가입니다.

이 신호는 경력이 많은 사람에게만 적용되는 기준이 아닙니다. 주니어에게는 범위가 좁은 기능 플래그나 대시보드 경보부터, 시니어에게는 여러 팀의 의존성이 있는 전환 계획부터 적용하면 됩니다. 중요한 것은 난도를 빠르게 올리는 것이 아니라, 책임의 범위와 피드백 주기를 함께 키우는 일입니다. 후임자가 모르는 것을 드러내는 순간은 실패가 아니라 승계 지도에 빈칸을 추가할 가장 좋은 때이기도 합니다.

반대로 경계해야 할 신호도 분명합니다. 리더가 휴가 중에도 사소한 질문을 모두 답하고 있다면, 팀의 예의가 아니라 승계 구조의 결손일 수 있습니다. 후임이 "승인받았습니다"라고만 말하고 고객 영향이나 롤백 조건을 설명하지 못한다면, 권한은 넘겼지만 판단은 넘기지 못한 것입니다. 이런 상태에서 직함만 바꾸면 위험은 사라지지 않고, 중요한 변경이 오기 전까지 숨겨질 뿐입니다.

역할을 분산하다가 책임까지 흐리면 안 되는 이유

단일 리더 의존을 줄이려는 조직이 빠지기 쉬운 반대편의 함정은 "모두가 함께 책임진다"는 문장입니다. 이는 장애가 발생했을 때 아무도 지휘하지 않는 상태로 바뀔 수 있습니다. 승계가 잘된 팀은 한 사람의 권위를 여러 사람에게 복제하는 대신, 책임의 종류를 더 구체적으로 나눕니다. 장기 설계의 결정 책임자, 배포의 실행 책임자, 장애 시 지휘 책임자, 고객 커뮤니케이션 책임자를 같은 사람일 필요가 없는 역할로 분리합니다.

승계 문서에 반드시 남겨야 할 것은 ‘답’보다 ‘미결정’이다

리더가 떠날 때 남기는 문서는 완결된 설명서처럼 보이기 쉽습니다. 하지만 운영 중인 시스템에는 아직 답이 없는 문제가 남아 있습니다. 다음 분기 트래픽이 특정 임계값을 넘으면 어떤 저장소를 선택할지, 한 파트너의 계약이 바뀌면 어느 기능을 포기할지, 비용 절감과 지연 시간 중 무엇을 우선할지처럼 말입니다. 이 미결정을 숨기면 후임자는 과거 결론을 영구 규칙으로 오해하거나, 같은 논의를 처음부터 다시 시작합니다.

따라서 승계 패킷에는 ‘열린 결정 목록’을 별도로 둬야 합니다. 각 항목에는 현재 가설, 확인해야 할 데이터, 결정을 다시 여는 날짜 또는 조건, 최종 결정 권한자를 적습니다. 이는 책임을 미루는 목록이 아닙니다. 불확실성이 개인의 기억이나 메신저에 머물지 않게 만드는 장치입니다. 특히 장기적인 플랫폼 투자나 다팀 간 우선순위 조정에서는, 확정된 ADR만큼이나 아직 확정되지 않은 선택지가 중요한 운영 맥락이 됩니다.

이 기록은 새 리더에게 자유를 줍니다. 과거 리더가 무엇을 알고 있었는지 추측하는 대신, 무엇이 아직 검증되지 않았는지와 어떤 증거가 필요한지를 확인할 수 있기 때문입니다. 조직은 그때 비로소 한 사람을 대체하는 것이 아니라, 다음 사람이 더 나은 결정을 내릴 수 있도록 판단 시스템을 갱신하게 됩니다.

30일 안에 승계 구조를 작동시키는 세 단계

좋은 승계는 "누가 그 자리를 대신하는가"보다 "다음 사람이 같은 상황에서 무엇을 보고, 어디까지 결정하고, 언제 도움을 요청하는가"에 답합니다. 리더가 자리를 비워도 서비스가 멈추지 않는 조직은 영웅을 덜 가진 조직이 아닙니다. 판단의 근거와 실행의 안전장치를 팀 전체가 사용할 수 있게 만든 조직입니다.

참고: Google SRE Book — Eliminating Toil, Google Engineering Practices — What to Look for in a Code Review, Google SRE Workbook — Postmortem Culture

참고 자료 (References)

• LeadDev - Engineering Leadership & Knowledge Continuity
• Camille Fournier - The Manager's Path: Succession and Systems Architecture