어느 날 아침, 제가 좋아하게 된 보고서 하나가 제 시스템에서 올라왔습니다. 바로 '할 일이 없음'이라는 보고서였습니다. 플래그(Flag)된 항목 0개. 필요한 조치 0개. 깨끗하고, 조용하며, 안심이 되는 숫자 0이었습니다.

하지만 그 0은 거짓말이었습니다. 보고서에 데이터를 공급하던 룩업(Lookup)이 죽어버린 것이었습니다. 아무것도 체크되지 않았기 때문에 아무것도 플래그되지 않은 것이었고, 이 실패는 실패가 취할 수 있는 가장 위험한 형태인 '성공과 똑같이 보이는 침묵'으로 변질되어 있었습니다.

만약 당신이 AI 워크플로우 (Workflow)를 기반으로 비즈니스를 운영하고 있다면, 당신의 운영 체계에도 이미 이러한 형태의 '0'이 존재하고 있을지 모릅니다. 그것은 연락해야 할 고객이 없다고 말합니다. 연체된 인보이스 (Invoice)가 없다고 말합니다. 유입된 리드 (Lead)가 없다고 말합니다. 에스컬레이션 (Escalation)이 필요한 티켓이 없다고 말합니다. 대부분의 날에 그 0은 진실입니다. 하지만 당신의 AI 이니셔티브 (Initiative)가 현실과 맞닥뜨렸을 때 살아남을 수 있을지를 결정하는 질문은 불편합니다. '그 0이 거짓이 되는 날, 누가 이를 알아차리며, 얼마나 빨리 알아차리는가?'입니다.

이것은 모델링 (Modeling)의 문제가 아닙니다. 이것은 소유권 (Ownership)의 문제입니다. 즉, 워크플로우 (Workflow)가 시작되는 순간부터 그 결과가 증명되는 순간까지 각 워크플로우를 책임지는 지정된 사람이 있어야 한다는 뜻입니다. 많은 이니셔티브 (Initiative)들이 결과 소유자 (Outcome owner)를 지정하지 않은 채 구성 요소 소유자 (Component owner)만을 지정하곤 합니다.

파일럿은 실패하지 않았습니다

제가 제 시스템과 제가 조사했던 여러 정체된 AI 이니셔티브 (Initiative)들에서 계속 목격하는 패턴이 있습니다. 모델은 성능을 발휘합니다. 데모 (Demo)는 성공적입니다. 파일럿 (Pilot)은 '작동'합니다. 그러다 이니셔티브 (Initiative)는 조용히 복리 효과를 멈추고, 사후 분석 (Postmortem)에서는 AI를 탓합니다.

종종 실패의 첫 번째 원인은 모델이 아닙니다. 문제는 모두가 조각을 소유했을 뿐, 경로 (Path)를 소유한 사람은 아무도 없었다는 점입니다. 누군가는 모델을 소유했습니다. 누군가는 데이터를 소유했습니다. 누군가는 대시보드 (Dashboard)를 소유했습니다. 하지만 트리거 (Trigger)부터 실행 (Action), 검증 (Verification), 그리고 복구 (Recovery)에 이르는 전체 여정을 소유한 사람은 아무도 없었습니다. 그래서 그 사슬의 연결 고리 하나가 끊어졌을 때, 그 실패에는 붙여진 이름이 없었습니다. 책임은 모델의 출력값 (Output)에서 멈췄고, 그 주변의 워크플로우 (Workflow)는 누구의 소유도 아니었습니다.

당신의 AI 파일럿 (Pilot)은 실패하지 않았습니다. 아무도 워크플로우 (Workflow)를 소유하지 않았을 뿐입니다.

실제로 무엇이 고장 나는가

메커니즘이 중요하며 모호한 전쟁 이야기는 누구에게도 도움이 되지 않기에, 제 시스템에서 발생한 세 가지 실패 사례를 통해 구체적으로 말씀드리겠습니다.

첫째: 잘못된 종료 코드(exit code)를 신뢰한 게이트(gate)입니다. 저는 AI 에이전트가 생성하는 모든 커밋(commit) 앞에 자동화된 품질 게이트(quality gates)를 실행합니다. 한 게이트는 테스트 출력(test output)을 포맷팅 명령(formatting command)으로 파이프(pipe) 처리했는데, 파이프라인(pipeline)이 테스트가 아닌 파이프의 마지막 명령인 포맷터(formatter)의 종료 코드를 보고했습니다. 포맷터는 항상 성공했습니다. 그래서 테스트 스위트(test suite)가 실패(red) 상태일 때도 게이트는 성공(green)으로 인식했고, 검증되지 않은 작업이 모두가 구속력이 있다고 믿었던 통제 장치를 그대로 통과했습니다. 테스트는 실행되었습니다. 테스트는 실패했습니다. 하지만 워크플로우(workflow)는 성공을 보고했습니다.

둘째: 침묵을 듣고 이를 정상 상태(health)라고 부른 모니터(monitor)입니다. 저는 파이프라인(pipelines)에 데드맨 스위치(dead-man switch)를 실행합니다. 무언가 크게 고장 나면 경고를 보냅니다. 하지만 이 모니터에는 더 미묘한 사각지대가 있었습니다. 경고(alarm)는 감시했지만, 활동량에 대한 분모(denominator), 즉 얼마나 많은 작업이 흘러가야 하는지에 대한 기대치가 없었습니다. 중단된 프로듀서(producer)와 평온하고 조용한 날은 동일한 신호, 즉 '아무것도 없음'을 생성했습니다. 침묵에는 두 가지 의미가 있었지만, 모니터는 그중 하나만 읽을 수 있었습니다.

셋째: '아니오'가 '예'로 들린 가드(guard)입니다. 저의 프리릴리스(pre-release) 가드 중 하나가 설계된 대로 정확히 변경 사항을 거부했습니다. 하지만 그 거부 신호가 상위 레이어(layer)에서 인식할 수 없는 형식으로 전달되었고, 그 결과 거부 신호는 올라가는 과정에서 삼켜졌으며 릴리스 경로(release path)는 그 침묵을 승인으로 읽었습니다. 가드가 막으려 했던 작업이 모두가 구속력이 있다고 믿었던 통제 장치를 그대로 통과해 버린 것입니다. 해결책은 두 단계로 이루어졌습니다. 거부 신호를 이를 집행하는 레이어(layer)가 명확하게 인식할 수 있도록 만들고, 그다음 전체 체인이 차단되는지 확인하기 위해 의도적으로 실패를 강제하는 것이었습니다. 한 번도 작동하는 것을 본 적 없는 통제 장치는, 당신이 믿음(faith)에 의존해 신뢰하고 있는 통제 장치일 뿐입니다.

Infographic titled The Three Meanings of a Quiet System, three numbered panels on a midnight navy background. Panel one, Verified Empty Result: a status card reading check complete with example counts (items examined 1,284, findings 0), a copper zero beside a checkmarked report, tagged TRUSTWORTHY in green. Panel two, Actionable Result: check complete with findings 17, a copper seventeen beside a findings list under a magnifier, tagged TRUSTWORTHY in green. Panel three, Dead Dependency: a red-bordered card reading check did not complete, items examined unknown, receipt missing, a faded zero beside a severed cable and a missing report marked with a red X, tagged BLOCK AND RECOVER in red. Banner along the bottom: A zero without proof of work is not a zero.

이것들의 공통점을 주목하십시오. 어떤 모델도 틀리지 않았습니다. 어떤 프롬프트도 튜닝(Tuning)이 필요하지 않았습니다. 각각의 실패는 구성 요소 사이의 틈새(Seam)에서 발생했으며, 그 틈새는 누구의 소유도 아니었습니다. '0(Zero)'이라는 결과는 그 이면의 작업이 실제로 수행되었다는 증거 없이 나타났고, 그 증거를 요구할 사람이나 메커니즘도 없었습니다.

누락된 경계 (The missing boundary)

해결책은 지능(Intelligence)이 아닙니다. 그것은 누군가 소유하고 기계에 의해 강제되는, 규칙이 있는 경계(Boundary)입니다.

제 시스템에서 그 경계는 이제 일관된 형태를 갖추고 있습니다. 모든 "할 일이 없음"이라는 보고에는 체크(Check)가 실행되었다는 증거가 반드시 포함되어야 합니다. 즉, 영수증(Receipt), 검토된 항목의 수(Count), 또는 활동 분모(Activity denominator)가 포함된 하트비트(Heartbeat)가 있어야 합니다. 모든 게이트(Gate)는 '실패 시 폐쇄(Fail closed)' 방식으로 작동합니다. 증거가 누락되면 답변은 '아니오'가 되고, 동작은 실행되지 않으며, 사람은 구체적이고 명시된 이유를 전달받습니다. 체크를 읽는 모든 시스템은 두 가지 상태가 아닌 세 가지 상태를 구분합니다: 결과(Result), 검증된 빈 결과(Verified empty result), 그리고 응답 없음(No answer). 세 번째 상태를 두 번째 상태로 뭉뚱그리는 것이 '거짓 0(False zero)'의 근본 원인이므로, 제 게이트는 이를 허용하지 않습니다.

그리고 모든 워크플로우(Workflow)에는 소유자가 있습니다. 모델의 소유자가 아닙니다. 경로(Path)의 소유자입니다. 즉, 워크플로우를 시작하는 트리거(Trigger), AI가 내릴 수 있도록 허용된 결정, AI가 건드리지 못하도록 규정된 결정론적 단계(Deterministic steps), 결과를 증명하는 검증(Verification), 그리고 검증이 실패했을 때의 복구(Recovery)를 소유하는 사람입니다.

운영자 테스트 (The operator test)

당신에게 이 문제가 있는지 확인하기 위해 코드를 읽을 필요는 없습니다. 다음 운영 회의에서 세 가지 질문을 던져보십시오.

1. 만약 우리 AI 워크플로우 뒤에 있는 데이터 피드(Data feed)가 지금 당장 중단된다면, 내일의 보고서에는 무엇이 나타날 것인가? 만약 정직한 답변이 "평소와 다름없는 조용한 하루"라면, 당신에게는 '거짓 0(False zero)'이 기다리고 있는 것입니다.

2. 하루 안에 이를 알아챌 수 있는 지정된 담당자는 누구이며, 그들은 정확히 무엇을 보게 되는가? "아마 팀에서 알아채겠죠"라는 말은 아무도 소유하고 있지 않다는 뜻입니다.

3. 시스템이 '할 일이 없음'이라고 말할 때, 체크가 실제로 실행되었다는 어떤 증거를 첨부하는가? 만약 답변이 '없음'이라면, 당신의 보고서는 증거가 아니라 주장(Claims)일 뿐입니다.

저는 제 자신의 운영 과정에서 이러한 질문들이 던져지지 않았을 때 어떤 일이 발생하는지 목격해 왔습니다. 제가 운영하던 메시징 게이트웨이(Messaging gateway) 중 하나는, 모든 인바운드 메시지가 내부의 재시도 루프(Retry loop) 속에서 조용히 소멸하고 있는 동안에도 마치 살아있는 것처럼 보였고, 결국 누군가 우연히 이를 발견할 때까지 문제가 지속되었습니다. 또 다른 사례에서는, 근본 원인(Root cause)이 해결되었다는 이유로 장애(Incident)가 종결되었지만, 해당 장애로 인해 쓰러졌던 시스템들은 12일 동안이나 다운 상태로 남아 있었으며, 그중 5일은 장애 종결 이후의 기간이었습니다. 이를 포착했을 알람(Alarm)은 모니터링 대상이 사라졌다는 이유로 폐기된 상태였습니다. 종결(Closure)은 메커니즘을 추적했습니다. 아무도 결과(Outcome)를 책임지지 않았습니다.

Diagram titled Own the Path, Not the Model: five numbered stage cards on a midnight navy background, Trigger (start event, start receipt), AI Decision (allowed choice, policy boundary), Deterministic Action (bound execution, exact artifact), Verification (external receipt, reality check), and Recovery (named alert, restore and confirm), joined by copper arrows with red SEAM markers cracking between the stages. A copper ribbon connects every stage to a plaque reading ONE NAMED OWNER. Banner along the bottom: Failures live in the seams. Ownership spans the outcome.

소유권(Ownership)의 실제 의미

제가 소유권(Ownership)을 말할 때, 그것은 사람과 메커니즘이 함께 다음의 다섯 가지 구체적인 사항에 대해 책임을 지는 것을 의미합니다.

워크플로우(Workflow)를 무엇이 시작하는가, 그리고 시작이 실제로 일어났음을 무엇이 증명하는가. AI가 단독으로 결정할 수 있는 것은 무엇이며, 나머지 모든 것이 기본적으로 결정론적(Deterministic)인 상태에서 무엇이 문서화되는가. 어떤 행동이 결과(Action results)를 낳으며, 이를 증명하기 위해 외부 세계가 반환하는 영수증(Receipt)은 무엇인가. 시스템 자체의 믿음이 아닌 현실과 대조하여 결과를 검증하는 체크(Check)는 무엇인가. 그리고 증거가 누락된 날에는 어떤 일이 발생하는가: 누구에게 페이지(Paged)가 발송되는가, 무엇이 페일 클로즈(Fail closed)되는가, 무엇이 복구되는가, 그리고 복구가 실제로 이루어졌음을 누가 확인하는가(단순히 수정 사항이 피해자에게 도달했다고 가정하는 것이 아니라).

이 다섯 가지 질문에 답할 수 있는 팀은 AI를 안정적으로 운영할 수 있는 훨씬 강력한 기반을 갖추고 있습니다. 답할 수 없는 팀은 계속해서 중단될 인상적인 파일럿(Pilots) 프로젝트를 운영할 것이며, 모델(Model)만이 이름이 있는 유일한 구성 요소이기 때문에 계속해서 모델을 탓하게 될 것입니다.

이 모든 것의 밑바닥에 깔린 불편한 진실은 동시에 해방을 주는 진실이기도 합니다. 워크플로우 (Workflow) 소유권은 연구 문제가 아닙니다. 더 똑똑한 모델 (Model), 더 큰 예산, 또는 플랫폼 마이그레이션 (Platform migration)을 필요로 하지 않습니다. 그것은 침묵이 증거가 아니라는 것, 0(zero)이 스스로를 증명해야 한다는 것, 그리고 트리거 (Trigger)부터 검증된 결과 (Verified outcome)에 이르는 각 경로를 지정된 한 명의 담당자가 소유해야 한다는 것을 결정하는 일입니다. 제가 살펴본 세 가지 실패 사례 모두 담당자가 정해지자마자 빠르게 해결되었으며, 그 해결책 중 어떤 것도 모델 (Model)을 건드리는 작업은 포함되지 않았습니다.

당신의 AI는 아마 괜찮을 것입니다. 누가 0(zero)을 담당하고 있는지 찾아보세요.

원문은 danmercede.com에 게시되었습니다.