장애 목록에 없는 정지: 공급 관계가 멈출 때

초록 장애 대응 체계는 대개 기술 결함을 전제로 설계됩니다. 서버가 죽거나, 코드가 틀리거나, 트래픽이 넘치는 경우입니다. 그런데 실제 운영에서 서비스를 멈추는 축에는 다른 계열이 있습니다. 공급자가 지불 상태를 거부로 판정하는 순간, 계약이나 약관이 바뀌는 순간, 쓰던 모델이 폐기되어 이주를 강제당하는 순간 — 코드 한 줄 바뀌지 않았는데 호출이 거절되기 시작합니다. 이 글은 그 '관계의 정지'를 장애의 정식 축으로 올려야 한다고 주장합니다. 공급망 위험관리 문서가 위험을 부품이 아니라 관계의 속성으로 다루는 이유, 모델 이주가 공짜가 아닌 이유, 그리고 멈춘 순간 무엇을 내보낼지를 미리 정해 둔 조직만이 가진 선택지를 차례로 살핍니다.

오늘 새벽 우리 파이프라인에서 실제로 있었던 일로 시작하겠습니다. 매일 콘텐츠를 굽는 배치가 정시에 떴고, 코드는 어제와 같았고, 모델도 질의도 그대로였습니다. 그런데 생성 호출이 전부 거절로 돌아왔습니다. 거절 사유는 과부하도 오류도 아니라 공급자의 지불 판정이었습니다. 결제 상태를 심사하는 시스템이 우리 프로젝트를 거부로 분류했고, 그 판정 하나로 생성에 기대는 작업 전체가 그 자리에 멈췄습니다. 흥미로운 것은 그날 우리 장애 문서 어디에도 이 시나리오가 없었다는 점입니다. 다운을 감시하는 장치는 살아 있었고, 오류율 경보도 조용했습니다. 서비스가 기술적으로는 멀쩡했기 때문입니다. 멈춘 것은 기계가 아니라 관계였습니다. 그리고 관계의 정지는 장애 목록에 올라 있지 않았기 때문에, 그것을 발견한 것은 경보가 아니라 결과물을 세어 본 사람이었습니다.

핵심 개념 정의

공급 관계의 정지

기술 결함 없이 공급자와의 상거래·계약 관계에서 발생하는 서비스 중단. 지불 판정 거부, 약관·정책 변경, 제품 단종과 모델 폐기가 여기 속한다. 호출하는 쪽의 코드와 데이터가 그대로인 채 호출이 거절되는 것이 특징이다.

공급망 위험관리(C-SCRM)

NIST SP 800-161 이 정의하는 관리 체계로, 공급망 위험을 개별 부품의 결함이 아니라 조직의 여러 층위에 걸친 관리 대상으로 다룬다. 전략 수립, 정책, 실행 계획과 위험 평가를 한 몸으로 묶는 것이 핵심이다.

비상계획(contingency planning)

NIST SP 800-34 가 다루는, 시스템이 정상 경로로 서비스를 제공하지 못할 때를 위한 사전 계획. 복구 우선순위와 대체 경로, 그리고 무엇보다 '무엇을 멈추고 무엇을 내보낼지'의 결정을 사고 전에 문서로 만들어 두는 일이다.

전략적 관점

멈춤의 원인 축은 셋이고, 문서는 대개 하나만 다룬다

서비스가 멈추는 원인을 늘어놓으면 세 계열로 갈라집니다. 첫째는 기술입니다. 코드 결함, 인프라 다운, 용량 초과 — 장애 대응 문서의 표준 목차이고, 감시와 경보가 모두 이 계열을 향해 설계됩니다. 둘째는 수요입니다. 트래픽 급증이나 남용처럼 쓰는 쪽에서 오는 압력이고, 한도와 차단기가 이 계열을 막습니다. 셋째가 오늘 이야기하는 관계입니다. 공급자가 지불 상태를 다시 판정하거나, 약관을 바꾸거나, 제품을 접거나, 모델을 폐기하는 경우 — 이 계열의 특징은 우리 쪽 어떤 계기판에도 전조가 나타나지 않는다는 것입니다. 오류율은 정상이고 지연도 정상인데 어느 순간부터 응답이 거절로 바뀝니다. 오늘 우리가 겪은 지불 판정 거부가 정확히 그랬습니다. 기술 축의 감시는 촘촘했지만 관계 축은 감시 대상 목록에 아예 없었고, 그래서 발견도 경보가 아니라 사람의 손으로 이루어 졌습니다. 관리하지 않는 축은 없는 축이 아니라 보이지 않는 축일 뿐입니다.

공급망 위험은 부품의 결함이 아니라 관계의 속성이다

공급망 위험관리를 다룬 NIST SP 800-161 이 흥미로운 이유는, 위험을 '나쁜 부품이 섞여 들어오는 문제'로 좁히지 않고 조직의 여러 층위에 걸친 관리 대상으로 정의한다는 데 있습니다. 전략과 정책, 실행 계획과 위험 평가를 한 묶음으로 요구하는 것은, 공급자가 주는 위험이 납품물의 품질만이 아니라 그 공급자와 맺은 관계의 구조 자체에서 나오기 때문입니다. 인공지능 API 를 쓰는 조직에 이 관점을 그대로 옮기면, 위험 목록은 '모델이 틀린 답을 낸다'에서 끝나지 않습니다. 공급자가 과금 체계를 바꾸면, 지역 정책을 바꾸면, 우리 계정을 다시 심사하면, 모델을 폐기하면 — 각각이 별도의 위험 항목이고, 각각에 대해 우리가 통제할 수 있는 것과 없는 것이 다릅니다. 부품 관점은 대체품 시험으로 끝나지만 관계 관점은 계약 조건, 통지 기간, 데이터 반출 경로, 지불 체계의 이중화까지를 관리 항목으로 만듭니다. 우리가 오늘 배운 것도 그것입니다. 막은 것은 코드가 아니라 관계였고, 대비도 관계 단위로 해야 했습니다.

모델 폐기는 통보가 아니라 이주 명령이다

관계의 정지 중에서 가장 예고가 길지만 가장 과소평가되는 것이 모델 폐기입니다. 상용 LLM API 에서 구모델이 폐기되면 이용자는 후속 모델로 옮겨야 하고, 이주 여부를 결정할 근거로는 대개 벤치마크 집계 점수가 쓰입니다. 그런데 올해 여름 공개된 한 실측 연구(arXiv:2608.17719)는 그 집계가 무엇을 감추는지를 문항 단위로 세어 보여 줍니다. 상용 모델 계열의 연속 업그레이드에서 공개 벤치마크 문항을 반복 질의해 문항별로 '확실히 좋아짐'과 '확실히 나빠짐'을 가려낸 결과, 집계 점수가 오른 이주에도 확실히 나빠진 문항이 섞여 있었고 집계가 내려간 이주에도 좋아진 문항이 있었습니다. 총점의 방향과 개별 문항의 방향이 일치하지 않는다는 뜻입니다. 이것을 운영 언어로 번역하면 이렇습니다 — 이주는 공짜가 아니고, 새 모델이 전반적으로 낫다는 말은 우리 서비스의 특정 경로가 조용히 나빠지지 않았다는 보장이 아닙니다. 폐기 통보를 받은 날 시작하는 이주는 그 회귀를 찾을 시간이 없습니다. 이주 시험 문항을 평소에 갖춘 조직만이 통보를 일정으로 받아들일 수 있습니다.

멈춘 순간 무엇을 내보낼지는 미리 정한 쪽만 고를 수 있다

오늘 사고에서 우리가 유일하게 다행으로 여긴 것은, 생성이 거절된 순간 파이프라인이 무엇을 했는가입니다. 생성기는 실패를 삼키고 아무거나 내보내는 대신 발행을 건너뛰었습니다. 검증할 수 없는 콘텐츠를 내보내지 않는다는 fail-closed 원칙이 코드에 박혀 있었기 때문에, 결과는 '틀린 하루치'가 아니라 '빈 하루치'였습니다. 빈 것은 나중에 채울 수 있지만 틀린 것은 회수해야 합니다. 이 선택은 사고 당일에는 할 수 없는 종류의 선택입니다. 멈춘 순간에는 이미 코드가 정한 대로 흘러가기 때문입니다. NIST SP 800-34 가 비상계획을 시스템 개발 수명주기에 붙여 두라고 요구하는 이유도 같습니다. 복구 우선순위와 대체 절차는 장애가 난 뒤에 정하는 것이 아니라 설계할 때 정해 두는 것이고, 정하지 않은 조직은 사고 순간 코드의 기본값 — 대개는 fail-open — 을 선택지로 받아들이게 됩니다. 공급 관계의 정지에도 같은 질문이 성립합니다. 지불이 거절되면, 모델이 사라지면, 우리 서비스는 무엇을 보여 주기로 되어 있습니까. 그 답이 코드에 있습니까, 아니면 그날의 임기응변에 있습니까.

관계의 정지는 감시가 아니라 대조로 발견된다

기술 장애는 감시가 잡습니다. 오류율이 뛰고 지연이 늘고 헬스체크가 빨개 집니다. 그런데 관계의 정지는 우리 계기판이 아니라 공급자의 판정 시스템에서 시작되므로, 우리 쪽 신호는 '평소와 같은 초록' 이기 쉽습니다. 오늘 우리 배치도 잡 상태로는 성공이었습니다. 멈춤을 드러낸 것은 산출물의 개수를 등록 대장과 대조한 확인 절차였습니다 — 여섯 스트림이 등록되어야 할 자리에 둘만 있었습니다. 여기서 얻는 교훈은 감시를 더 쌓으라는 것이 아닙니다. 결과를 기대값과 대조하는 절차, 즉 '오늘 나왔어야 할 것이 실제로 나왔는가'를 세는 장치는 원인 축이 무엇이든 — 기술이든 수요든 관계든 — 멈춤을 같은 방식으로 드러낸다는 것입니다. 원인별 감시는 아는 원인만 잡지만, 결과 대조는 모르는 원인까지 잡습니다. 공급 관계처럼 전조가 우리 눈 밖에 있는 축일수록, 서비스 수준의 결과 대조가 최후의 그물이 됩니다. 그물이 있었기에 우리는 오늘 하루치 공백을 그날 안에 세고 그날 안에 채울 수 있었습니다.

반론과 재반박

예상 반론 결국 대기업 조달·재무 부서의 이야기 아닌가. 작은 서비스는 공급자 하나에 깊이 올라타는 것이 비용으로 보나 속도로 보나 합리적이고, 공급자 이중화나 상시 이주 체계는 사치다. 지불 사고 같은 것은 카드 한도를 넉넉히 두면 될 일이다.

재반박 이중화를 사라는 주장이 아닙니다. 공급자 하나에 올라타는 선택 자체는 작은 조직에서 합리적일 수 있습니다. 이 글이 권하는 것은 그 선택을 하되 '이 관계가 멈추면 우리 화면에 무엇이 보이는가'를 코드로 정해 두라는 것입니다. fail-closed 표면, 재개 절차, 그리고 결과를 기대값과 대조하는 확인 장치는 공급자가 하나든 셋이든 필요하고, 비용도 이중화와 비교할 수 없이 작습니다. 그리고 지불 사고는 한도의 문제가 아니라 판정의 문제입니다. 오늘 우리가 받은 거절은 잔액이 아니라 공급자 쪽 심사 시스템의 판정에서 나왔고, 그런 판정은 카드 한도를 늘려도 예방되지 않습니다. 통제할 수 없는 판정이 존재한다는 사실 자체가, 멈춤의 시나리오를 미리 적어 둘 이유입니다.

법마디 OS가 그리는 미래

인공지능 위에 지은 서비스가 늘어날수록, 운영 위험의 무게중심은 자기 코드에서 공급 관계로 옮겨 갑니다. 모델·검색·과금·인증이 전부 외부 공급자의 API 인 구조에서, 조직이 직접 고칠 수 있는 결함의 비중은 줄고 조직이 통제할 수 없는 판정의 비중은 늘기 때문입니다. 그 세계에서 운영 역량의 정의도 바뀝니다. 지금까지는 장애를 빨리 고치는 조직이 강했다면, 다음에는 멈춤을 빨리 알아차리고 — 그 원인이 자기 것이 아니어도 — 정해 둔 표면으로 내보낼 수 있는 조직이 강합니다. 공급자와의 관계는 계약서 서랍이 아니라 운영 문서 안에 살아 있어야 하고, 관계가 멈추는 날의 화면은 그날의 임기응변이 아니라 오래전에 커밋된 코드여야 합니다. 우리는 오늘 그 차이를 하루치 공백으로 지불하고 배웠습니다. 공백은 채우면 되지만, 준비 없는 조직이 같은 자리에서 지불하는 것은 공백이 아니라 신뢰입니다.

전략적 함의

장애 대응 문서에 '공급 관계의 정지' 절을 따로 만든다. 지불 판정 거부, 약관·정책 변경, 모델 폐기를 각각 항목으로 적고, 항목마다 우리가 받게 될 신호와 첫 대응을 적는다. 목록에 없는 시나리오는 사고 당일에 처음 설계된다.
서비스 수준의 결과 대조를 감시와 별도로 둔다. '오늘 나왔어야 할 것'의 목록과 실제 산출물을 매일 대조하면, 원인이 기술이든 관계든 멈춤이 같은 자리에서 드러난다.
이주 시험 문항을 평소에 유지한다. 모델 폐기 통보를 받은 날 만드는 시험은 회귀를 찾기에 늦다. 우리 서비스의 핵심 경로를 대표하는 질의 묶음이 있어야 집계 점수가 아니라 우리 기준으로 이주를 판정할 수 있다.

"장애 목록은 우리가 고칠 수 있는 것들의 목록이 아니라, 우리를 멈출 수 있는 것들의 목록이어야 합니다."

참고 자료

칼럼니스트

서연

최고전략책임자 (CSO · Chief Strategy Officer)

미국 연방대법원 로클럭 출신급 / 글로벌 Top3 전략 컨설팅 파트너급

법마디 OS 무료로 경험하기

본 칼럼은 법마디 OS 전략팀의 관점이며, 투자 권유나 법률 자문이 아닙니다.