구전 지식이 매기는 세금
어느 팀에나 그런 사람이 한 명 있다. 가장 오래 있었고, 문서화되기 전부터 시스템 절반을 손수 만들었고, 인시던트 채널이 열리면 제일 먼저 호출되는 사람. 나머지 사람들의 다음 메시지는 늘 “일단 그 사람 얘기부터 들어보자”다. 이게 바로 구전 지식 장애 대응의 실체다 — 프로세스가 아니라 그냥 한 사람이고, 팀 전체의 복구 시간은 조용히 그 사람이 깨어 있는지, 연락이 닿는지, 기분이 어떤지에 달려 있다.
누가 이렇게 설계한 게 아니다. 그냥 쌓인다. 문서화되지 않은 요령 하나하나가 켜켜이 쌓이다 보면, 어느새 조직도에는 열두 명이 적혀 있는데 인시던트 현실은 한 명짜리가 되어 있다.
온콜 특정 인력 의존은 왜 생기나
글로 남기는 일이 다음 기능 출시에 늘 밀리기 때문에 쌓인다. 지난 분기 장애를 진단했던 엔지니어는 진짜 유용한 걸 배웠다 — 이를테면 야간 배치 작업과 배포가 겹칠 때마다 결제 큐가 밀린다는 사실 — 그러고는 다시 스프린트로 돌아갔다. “방금 알아낸 걸 나머지 사람들이 찾아볼 수 있는 형태로 남겨두기”를 누구도 티켓으로 만들지 않았기에, 그런 일은 일어나지 않았다. 지식 자체는 진짜다. 다만 저장된 곳이 딱 한 군데, 사람 머릿속뿐이다.
이게 누적되는 이유는 이렇다. 지식을 쥔 사람이 가장 빠른 해결 경로가 되고, 그래서 관련된 모든 인시던트에 불려 다니고, 그래서 다른 누구도 갖지 못한 맥락을 점점 더 많이 쌓게 되고, 그래서 격차는 좁혀지기는커녕 매번 더 벌어진다. 원래는 전문성을 분산시켜야 할 시스템이 오히려 그걸 한곳에 집중시키고 있는 셈이다.
특정 엔지니어 의존이 실제로 치르는 대가
뻔한 비용은 다들 이미 불평하는 그것이다 — 그 사람의 휴가는 관리해야 할 리스크가 되고, 슬랙 상태 메시지는 운영 지표가 되고, 온콜 로테이션은 그 사람이 연락 안 되는 주간을 조용히 피해서 짜인다. 하지만 진짜 대가는 그 사람이 연락이 될 때 벌어지는 인시던트에서 드러난다 — 페이지를 받고 응답까지 하는데도, 팀은 여전히 한 시간을 먼저 잃는다.
그 한 시간은 이상한 형태의 병목으로 흘러간다. 다섯 명의 엔지니어가 같은 대시보드를 들여다보고 있고, 다섯 명 모두 문제를 스스로 추론할 능력이 있는데도, 전부 같은 질문 앞에서 멈춰 선다 — 이거 예전에도 있었나, 있었다면 그때 뭐가 먹혔나? 잘못 짐작해서 일을 더 키우고 싶지 않으니, 기본값은 기다림이 된다 — 답장을, 콜백을, “아 이거 3월에 있었던 그거네”를. 팀의 총 인원수는 더 이상 의미가 없다. 인시던트 동안의 처리량은 딱 한 사람의 주의력이 슬랙 스레드 하나씩 처리하는 속도로 상한선이 그어진다.
그리고 그 한 사람은 이제 두 배로 병목이다. 현재 인시던트를 트리아지하는 동시에, 비슷해 보이는 지난 세 건을 기억에 의존해서, 시간 압박 속에, 페이지가 울린 그 시각에 맞춰 설명해달라는 요청까지 받는다. 나머지 팀원들이 놀고 있는 게 아니다 — 조직이 쌓아온 경험에 접근할 수 있는 유일한 창구가 지친 사람 한 명이 채팅창에 타이핑하는 것뿐이라서 멈춰 있는 것이다.
이게 왜 인시던트 시간을 배로 늘리나
더해지는 게 아니라 곱해진다는 점을 과소평가하기 쉽다. 맥락이 이미 분산되어 있는 팀이라면 익숙한 장애 패턴을 20분 안에 해결할 수 있다 — 패턴을 알아보고, 확인하고, 알려진 수정을 적용하면 된다. 반면 한 사람의 기억에 의존하는 팀은 그 20분에 지연을 더하는 게 아니라, “패턴을 알아본다”는 단계 자체를 “누군가 대신 알아봐 줄 때까지 기다린다”로 바꿔버린다. 그리고 그 대기 시간은 인시던트가 아무리 급해도 줄어들지 않는다. 새벽 3시에 온 페이지도 오후 3시에 온 페이지와 똑같이 답장을 기다리는데, 새벽 3시에는 그 한 사람마저 자고 있으니 오히려 더 오래 걸린다.
이 문제는 포스트모템에서 다시 한번 드러나고, 여기서 누적 효과가 진짜로 터진다. 보고서는 작성되고, 타임라인은 정리되고, 근본 원인에는 한 문단이 할애된다 — 하지만 실제로 문제를 풀어낸 결정적인 판단(“다른 무엇보다 배치 작업 겹침부터 확인해 보라”)은 대개 여전히 그 한 사람 머릿속에만 있고, 회고에서 구두로 한 번 언급된 뒤 다른 어디에도 남지 않는다. 다음번에 똑같은 장애 패턴이 다시 나타나면, 팀은 다시 원점으로 돌아간다. 포스트모템이 무슨 일이 일어났는지는 기록했지만, 그 전문가가 실제로 어떻게 알아챘는지는 담아내지 못했기 때문이다. 이 세금은 다음 온콜 담당자가 고스란히 다시 낸다.
팀을 키운다고 해결되지 않는 이유도 여기 있고, 오히려 악화될 수도 있다. 신입 한 명이 늘어날 때마다, 인시던트 중 유용해지려면 그 시니어 엔지니어의 맥락이 필요한 사람이 한 명 더 늘어날 뿐이고, 그걸 얻을 방법은 물어보는 것 말고 없다. 병목은 팀이 커진다고 희석되지 않는다 — 오히려 더 바빠진다. 같은 한 사람을 호출하는 사람이 늘어나는 것과, 인시던트를 독립적으로 해결할 수 있는 사람이 늘어나는 것은 전혀 다른 이야기다.
이 패턴은 근본 원인 분석이 수정 자체에 걸리는 시간보다 훨씬 길게 늘어질 때 나타나는 패턴과 같다. 지연은 고치는 데서 오는 게 아니라 찾아내는 데서 온다. 그리고 그걸 찾을 수 있는 곳이 단 한 사람의 기억뿐일 때, 그 사람의 가용 여부가 — 누구도 그렇게 문서화한 적 없어도 — 인시던트의 실질적인 서비스 목표치가 되어 버린다.