핵심 인물 의존 위험

Key Person Risk

개념

특정 구성원이 빠지면 업무가 멈추거나 조직이 흔들리는 상태로, 그 사람만 아는 지식과 권한이 한곳에 몰렸을 때 생깁니다.

등장 배경

빨리 만들어야 하는 조직에서는 아는 사람이 그냥 합니다. 결제 연동을 붙인 사람이 그다음 장애도 보고, 한 번 보다 보니 그 영역은 계속 그 사람 몫이 됩니다. 매번 누가 할지 정하고 설명하는 시간을 아낀 결과라 초반에는 이게 가장 빠릅니다.

문제는 그 사람이 자리에 없는 날 한 번에 드러납니다. 페이지덱에서도 결제 배포는 태오 혼자 해 왔습니다. 태오가 휴가 간 주에 결제가 한 시간 멈췄고, 남은 사람들은 복구 절차를 몰라 태오에게 전화를 걸었습니다. 공항에서 노트북을 연 태오가 명령어 두 줄을 알려 주고서야 끝났습니다.

그날 규원이 꺼낸 질문은 "왜 태오만 알고 있었는가" 가 아니었습니다. "이런 자리가 여기 말고 또 어디에 있는가" 였습니다. 한 사람에게 일이 몰린 건 사고가 아니라 조직이 자라는 과정에서 매번 생기는 모양이라, 하나를 푼다고 다시 안 생기지 않습니다. 이 위험에 이름을 붙여 두는 이유가 여기 있습니다. 이름이 있어야 점검 목록의 한 줄이 되고, 분기마다 같은 질문을 다시 던지게 됩니다.

작동 방식

위험은 한 사람이 유능해서가 아니라 남들이 접근할 수 없는 것을 그 사람이 쥐고 있을 때 생깁니다. 쥐고 있는 것은 대개 셋 중 하나입니다.

  1. 지식. 문서에 없고 그 사람 경험에만 있는 절차입니다. 결제사 쪽 담당자가 누구인지, 장애 때 어떤 순서로 되돌리는지 같은 것들입니다.
  2. 권한. 계정과 접근 키가 한 사람에게만 있는 경우입니다. 도메인 관리자 계정을 퇴사한 사람이 들고 나가 며칠 동안 아무것도 못 고친 회사가 드물지 않습니다.
  3. 관계. 주요 고객이나 투자자가 특정 개인을 보고 남아 있는 경우입니다. 회사 이름이 아니라 그 사람 이름으로 맺어진 계약은 그 사람과 함께 움직입니다.

위험의 크기는 그 사람이 얼마나 뛰어난지가 아니라 빠졌을 때 얼마나 오래 멈추는지로 잽니다. 태오가 없으면 결제 배포가 반나절 밀리는 팀과 두 주 동안 아무도 손대지 못하는 팀은 같은 상황이 아닙니다. 그래서 점검할 때 묻는 문장은 "누가 중요한가" 가 아니라 "이 사람이 내일부터 두 주간 못 나온다면 무엇이 멈추는가" 입니다.

푸는 방법은 그 사람을 붙잡아 두는 쪽이 아니라 쥐고 있는 것을 나누는 쪽입니다. 지식은 다음번에 그 일이 생길 때 다른 사람이 손을 대고 원래 담당자가 옆에서 보게 해서 옮깁니다. 문서만 써 두면 옮겨졌다고 믿기 쉬운데, 읽고 따라 해 본 사람이 하나도 없는 문서는 정작 급할 때 빈 곳이 드러납니다. 권한은 계정을 둘 이상에게 두거나, 필요한 만큼만 권한을 주는 최소 권한 원칙을 지키면서 비상시 접근 경로를 따로 만들어 둡니다. 관계는 다음 미팅부터 한 명을 더 붙여 회사 대 회사의 관계로 바꿔 갑니다.

쓰이는 곳

이 말이 실제로 오가는 자리는 셋입니다.

투자 실사와 이사회가 첫 번째입니다. 투자자는 창업자나 특정 개발자 한 사람에게 회사가 걸려 있는지를 봅니다. 그래서 사업 계획서의 위험 항목에 이 이름이 들어가고, 회사가 주요 임원 앞으로 보험을 드는 일도 여기서 나옵니다. 그 사람이 빠졌을 때 회사가 버틸 현금을 보험금으로 마련해 두는 장치입니다.

두 번째는 리스크 관리 점검표입니다. 회사를 흔들 수 있는 위험을 한 표에 늘어놓고 가능성과 크기로 순위를 매기는 작업인데, 핵심 인물 의존은 고객 편중 위험이나 규제 위험과 나란히 한 행을 차지합니다. 위쪽에 올라온 행에는 사업 연속성 체계나 비상 계획처럼 구체적인 대비를 붙입니다.

세 번째는 엔지니어링 팀의 일상입니다. 이쪽에서는 리스크라는 말보다 특정 영역을 아는 사람이 몇 명인지로 이야기합니다. 누구나 어느 코드든 고칠 수 있게 하자는 코드 공동 소유, 두 사람이 한 화면을 보며 함께 코드를 쓰는 페어 프로그래밍, 합치기 전에 동료가 코드를 살펴보는 코드 리뷰가 모두 아는 사람 수를 늘리는 장치로도 작동합니다. 장애 연락을 받는 온콜 당번을 돌리는 것도 같은 효과를 냅니다. 당번이 되려면 그 영역을 알아야 하기 때문입니다.

실무 용례

"결제 쪽은 태오 말고 아무도 못 고쳐요. 이번 분기 위험 목록에 올립시다."

한 사람에게 몰린 영역을 공식 안건으로 만들자는 제안입니다.

"대표가 주요 고객을 다 들고 있는 건 실사에서 지적받습니다."

투자자가 회사가 아니라 개인에 붙은 매출로 볼 거라는 경고입니다.

"다음 장애는 태오 말고 다른 사람이 대응하고, 태오는 옆에서 보기만 합시다."

지식을 옮기는 가장 확실한 방법을 실행에 옮기자는 말입니다.

페이지덱은 그 휴가 사건 뒤로 분기마다 한 시간을 잡아 같은 표를 다시 읽습니다. 영역을 왼쪽에 적고 그 영역을 혼자 할 수 있는 사람 수를 오른쪽에 적는데, 1이 적힌 줄만 그 분기의 과제가 됩니다. 결제 배포에 1이 적혀 있던 줄은 두 분기 만에 2가 됐습니다. 특별한 방법을 쓴 건 아니고 그동안 있었던 배포를 민서와 함께 한 번씩 돌렸을 뿐입니다.

흔한 오해

당사자를 문제로 읽는 경우가 가장 많습니다. 한 사람 이름이 표에 오르니 그 사람이 정보를 쥐고 안 놓은 것처럼 보이기 쉽습니다. 하지만 이 상태는 급할 때 아는 사람이 하도록 둔 조직의 선택이 쌓인 결과이고, 대개 그 사람은 가장 많이 일한 쪽입니다. 당사자를 탓하는 회의가 되면 그다음부터는 아무도 "이건 저만 알아요" 라고 말하지 않게 되고, 위험은 보이지 않는 채로 남습니다.

문서를 쓰면 해결됐다고 보는 것도 흔합니다. 인수인계 문서 한 편이 폴더에 올라오면 표의 숫자를 1에서 2로 고치고 싶어집니다. 그런데 문서는 쓴 사람의 머릿속을 기준으로 쓰여서, 쓴 사람에게 당연한 단계가 빠져 있는 경우가 많습니다. 다른 사람이 그 문서만 보고 한 번 해 보기 전까지는 숫자를 그대로 둡니다.

같이 보면 좋은 페이지

  • 리스크 관리

    이 위험이 어느 목록의 한 줄인지, 목록 전체를 어떻게 다루는지 봅니다

  • 고객 편중 위험

    사람이 아니라 매출이 한곳에 몰렸을 때 생기는 같은 모양의 위험입니다

  • 코드 공동 소유

    엔지니어링 팀이 이 위험을 일상에서 줄이는 방법입니다

마지막 업데이트 2026-09-16