당신의 Human-in-the-loop는 매우 비싼 GPS입니다.

AI 드리프트 (AI drift)를 해결하는 것은 AI 문제가 아닙니다. 그것은 작은 확률 문제입니다 — 두 개의 변수와 한 번의 곱셈 — 그리고 어떤 모델 계층에서도 작동하는 엔지니어링 솔루션이 존재합니다.

전체 이론은 다음과 같습니다:

P(정확한 단계) = P(내가 어디에 있는지 안다) × 
                  P(위치 | 올바른 문을 선택함)

에이전트(agent)가 취하는 모든 단계는 두 가지 추정치의 곱입니다: 자신이 어디에 있는지 아는지, 그리고 그곳에서 올바른 입구를 선택하는지 여부입니다. 대부분의 에이전트 시스템에서 두 요인은 모두 1.0 미만에 머물러 있습니다. 긴 작업에 걸쳐 이들을 곱하면 모두가 목격해 온 실패가 발생합니다: 1단계부터 10단계까지는 명확하고 정확하며 빠르지만, 20단계를 넘어서는 어느 지점에서 에이전트는 여전히 바쁘고, 여전히 자신만만하며, 여전히 그럴듯한 결과물을 만들어내고 있지만 — 더 이상 당신이 준 작업을 수행하고 있지 않게 됩니다.

이 분야에는 이를 위한 분류 체계(목표 드리프트 (goal drift), 역할 드리프트 (role drift), 계획 붕괴 (plan decay), 환각 폭포 (hallucination cascades))와 이에 대응하는 현대적인 신뢰성 스택(reliability stack)이 있습니다: 감독자-작업자 계층 구조(supervisor–worker hierarchies) 내부의 ReAct 루프, 목표 재고정 (goal re-anchoring), 체크포인트 상태 (checkpointed state), 그리고 컨텍스트 엔지니어링 (context engineering)의 네 가지 레버인 쓰기(write), 선택(select), 압축(compress), 격리(isolate)가 그것입니다. 저는 그 스택을 실행합니다. 제 에이전트 중 하나는 그 과정 중에도 27시간 동안 드리프트가 발생했습니다 — 프로젝트가 그 아래에서 무너지는 동안 연속으로 9번의 국지적으로 정확한 결정을 내렸습니다. 그 스택은 튜닝의 문제가 아니라 구조적인 이유로 실패했습니다: 스택의 모든 구성 요소는 두 변수에 대한 에이전트 자신의 '설명 (account)'을 개선할 뿐입니다. 그 중 어떤 것도 변수 자체를 참(true)으로 만들지는 못합니다.

이어지는 내용: 두 변수, 루프와 메모리가 이를 해결하지 못함을 보여주는 27시간의 사례, 그리고 이를 해결하는 시스템 설계입니다.

어떤 문인가? — 입구 변수

더 쉬운 것부터 시작해 봅시다. 바로 입구 변수(entrance variable)입니다. 시스템이 여러 개의 입구를 제공할 때 — 세 가지의 등록 방식, 권한을 주장하는 두 개의 문서, "어느 쪽이든 상관없습니다"와 같은 상황 — 에이전트는 어떤 것을 선택할지 추론(reasoning)해야 합니다. 그리고 추론은 샘플링(sampling)입니다. 즉, 결정론적(deterministic)인 사건이 확률론적(probabilistic)인 사건이 되는 것입니다. 각 단계의 확률 $P = 0.95$인 이러한 선택을 20단계 연속으로 연결하면, 전체 흐름이 올바르게 완료될 확률은 36%에 불과합니다. 14번째 단계에서 모델이 더 멍청해진 것이 아닙니다. 단지 운의 예산(luck budget)이 다했을 뿐입니다. (저는 한 프런티어 모델(frontier model)이 다른 에이전트의 계약에 "인덱스 우선 탐색(index-first discovery)" 원칙을 작성한 지 불과 몇 분 만에, 그 원칙 자체를 무시하고 find 명령어로 추측하며 나아가는 것을 목격했습니다. 해당 리포지토리(repo)는 쿼리가 가능한 코드 그래프를 포함해 다섯 개의 입구를 제공하고 있었음에도, 모델은 사전 학습(training prior)된 습관을 선택했습니다. 샘플링 분포(sampling distribution)를 설정할 수는 없습니다. 선택지를 없애야 할 뿐입니다.)

이 산술적 계산은 이제 상식에 가깝습니다. Utkarsh Kanwat가 2025년에 발표하여 널리 공유된 에세이에서도 에이전트의 실패를 확신하며 동일한 수치를 계산한 바 있으며, 업계의 표준적인 대응은 체인(chain)의 길이를 줄이고 인간 체크포인트(human checkpoints)를 추가하는 것입니다. 하지만 이 두 방법 모두 단지 $N$을 낮출 뿐입니다. 문은 여전히 열려 있습니다.

하지만 선택 비용(choice tax)은 단계당 거의 일정하게 발생합니다. 이는 실패를 설명해주지만, 왜 작업의 길이가 길어질수록 실패가 가속화되는지는 설명하지 못합니다. 그것은 위치 변수(position variable)의 역할입니다.

내가 어디에 있는가? — 위치 변수

자신이 어디에 있는지 — 어떤 단계에 있는지, 어떤 의무가 이행되었는지, 실제로 어떤 일이 일어났는지 — 에 대한 에이전트의 믿음은 기본적으로 단 하나의 소스, 즉 자신의 컨텍스트(context)에서 나옵니다. 자신의 궤적(trajectory)에 대한 기억 말입니다. 항법(navigation) 용어로 말하자면, 이는 **추측 항법 (dead reckoning)**입니다. 자신의 이동 로그를 누적하여 위치를 추정하는 방식이죠. 그리고 추측 항법에는 유명한 특성이 있습니다. 오차는 오직 커지기만 한다는 것입니다. 로그의 그 어떤 것도 누적된 불확실성(uncertainty)을 제거하지 못합니다.

이것이 바로 드리프트(drift)가 장기 과제(long-task)의 질병인 이유입니다. 진입 다중성(Entrance multiplicity)은 각 단계를 동일하게 소모하며, 위치 불확실성(position uncertainty)은 단계가 거듭될수록 복리로 증가합니다. 짧은 작업은 추정치가 저하되기 전에 종료됩니다. 반면 긴 작업은 바로 자신의 위치 추정치보다 더 오래 지속되는 작업들입니다.

장비가 갖춰진 에이전트 운영을 일주일간 관찰한 결과, 세 가지 방식으로 그 메커니즘이 포착되었습니다:

• 위치 망각 (Position amnesia). 한 세션은 하루 동안 105회의 컨텍스트 압축(context compaction)을 거쳤습니다. 매 압축이 일어날 때마다 에이전트는 동일한 솔루션을 다시 도출하고 동일한 오류를 반복했습니다. 에이전트는 기술을 잃은 것이 아니라, _위치(place)_를 잃은 것이었습니다.
• 잘못된 위치 신념 (False position beliefs). 경계가 설정된 워커(worker)가 시작(startup), 구현(implement), 커밋(commit)을 완료했다고 주장하는 상태 파일을 작성했습니다. 하지만 서버는 시작이 거부되었으며 해당 커밋이 존재하지 않음을 보여주었습니다. 이는 전략적 기만이 아니었습니다. 에이전트의 자기 서사(self-narrative)가 현실과 괴리되었으며, 자기 서사가 에이전트의 유일한 위치 정보원(position source)이었기 때문입니다.
• 위치 분기 (Position forks). 두 개의 서브시스템이 하나의 작업 상태에 대해 각각 권위 있는 의견을 가졌습니다. 하나는 "병합됨, 완료됨(merged, done)"이었고, 다른 하나는 "증거 누락, 종료 불가(evidence missing, unclosable)"였습니다. 동일한 작업에 대해 두 개의 위치가 존재했으며, 해당 작업을 접하는 모든 에이전트는 그 분기(fork)를 상속받았습니다.

네 번째 변형이 존재합니다. 앞선 세 가지보다 더 미묘하며, 건강해 보이는 루프 안에서 하루 종일 숨어 있을 수 있습니다. 이는 이번 사례 연구의 핵심을 다룰 가치가 있습니다.

사례: 모든 발견은 실재하지만, 프로젝트는 결국 죽어간다

나의 거버넌스 시스템 (aming-claw)은
강제된 계약(enforced contracts) 하에 AI 코딩 에이전트(AI coding agents)를
운영합니다. 즉, 모든 변경 사항에는 수락 기준(acceptance criteria)이 포함된 작업 항목(work item)이 필요하며, 증거는 추가 전용 타임라인(append-only timeline)에 기록되고, 머지(merge)를 위해서는 별도의 에이전트 ID를 가진 독립적인 QA를 거쳐야 합니다. 7월 초, 시스템에는 제한된 새로운 기능이 필요했습니다. 계정을 혼동하지 않고 한 대의 기기에서 여러 벤더의 모델들 — Codex, Claude, 로컬 Ollama —을 구동할 수 있는 CLI 에이전트 서비스였습니다.

구현자(거버넌스 하의 워커(governed worker)로 실행되는 최첨단 코딩 모델(frontier coding model))는
단 하룻밤 만에 깔끔한 997줄의 기반 코드를 배포했습니다. 나의 적대적 QA 에이전트(adversarial QA agent) — 별도의 ID를 가지며 해당 작업물을 공격하라는 명시적 임무를 부여받음 — 는 실제 결함들을 찾아냈습니다. 점심 식사 전까지 세 번의 수정 라운드가 진행되었습니다. 설계된 대로 정확히 작동했습니다. 다음 단계인 프로필을 위한 호스트 전용 레지스트리(host-private registry) 작업은 그날 저녁에 배정되었습니다.

다음 날, 레지스트리 검토(review)가 시작되었습니다.

1라운드: 실패 (FAIL) — 실제적인 개인정보 보호 및 경로 격리(path-isolation) 결함 발견. 타당했습니다. 재작업 진행. 2라운드: 실패 (FAIL) — 충돌 정리(crash-cleanup) 로직에서의 실제 허점 발견. 이 또한 타당했습니다. 재작업 진행. 3라운드는 속도를 늦추고 발견된 내용들을 감탄하며 지켜봐야 할 지점입니다. 검토자는 스키마 검증(schema validation)이 동작적으로 호환되지 않는 데이터베이스 객체를 수용한다는 것을 증명했고, 그림자 행(shadow row)을 조용히 삽입하는 SQLite 트리거를 작성함으로써 — 정확한 변이 세트(mutation set)를 롤백하지 않고도 등록이 성공했다고 보고한다는 것을 — 입증했습니다. 진정으로 탁월했습니다.
실패 (FAIL).

그날 업무 종료 시점까지: 9건의 거절, 0건의 승인. 모든 라운드에서 818개의 테스트가 모두 통과(green)되었습니다. 단 하나의 오류 발견도 없었습니다. 시스템을 악화시킨 단 하나의 수정 사항도 없었습니다. 한편, 제품 패키지는 27시간 동안 전혀 움직이지 않았고, 리뷰 중심의 작업 항목(work items)은 제품 작업보다 19 대 3의 비율로 늘어났으며, 코드베이스는 아직 존재하지도 않는 기능을 수호하기 위해 1,000줄에서 10,000줄 규모의 요새로 변해가고 있었습니다. 이것이 수렴되는 N번째 라운드는 존재하지 않았습니다. "문제 찾기"는 결승선이 없는 목표이며, 통과 기준(pass bar)은 구현체가 살아남는 무엇이든 맞추기 위해 조용히 상승했습니다 — 해제 레버가 없는 래칫(ratchet)처럼 말입니다.

[

이 루프를 깨뜨린 개입은 단 하나의 메시지였습니다: 판정 기준선(verdict baseline)을 배포 시점에 존재했던 수락 기준(acceptance criteria)으로 고정할 것; 그 기준을 넘어서는 발견 사항은 후보를 탈락시키는 대신 새로운 작업 항목(work items)으로 전환할 것; 그리고 다시 기능 구현으로 돌아갈 것. 24시간 이내에 동일한 거버넌스(governance) 하의 동일한 에이전트들이 데몬(daemon), 슈퍼바이저(supervisor), 스케줄러(scheduler), 그리고 로컬 모델 인증(local-model certification)을 출시했습니다. 역량은 처음부터 그곳에 있었습니다.

이제 이론을 통해 이 사례를 읽어보십시오. 이것은 멍청한 에이전트, 나쁜 리뷰어, 누락된 메모리, 또는 고장 난 루프의 문제가 아닙니다. 리뷰어는 슈퍼바이저 하에서, 증거 타임라인(evidence timeline)에 외부화된 상태(externalized state)를 두고, 교과서적인 ReAct 루프 — 관찰(observe), 추론(reason), 행동(act) — 를 실행했습니다. 현대적 신뢰성 스택(reliability stack)의 모든 구성 요소가 존재했고 정상적으로 작동했습니다. 실패한 것은 네 번째 변형인 **기준 프레임 드리프트(reference-frame drift)**였습니다. 리뷰어는 자신이 어떤 후보를 리뷰하고 있는지 항상 알고 있었습니다 — 메모리 내에서의 위치는 문제가 없었습니다. 드리프트가 발생한 것은 측정 표준이었습니다. 통과 기준(pass bar)에 고정된 기준점(datum)이 없었기에, 좌표계가 매 라운드마다 조금씩 움직였고, 모든 측정값은 내부적으로는 일관성을 유지했지만 전체 프레임이 목표에서 미끄러져 나가고 있었습니다.

현대적 스택이 두 변수 모두를 다루지 못하는 이유

현재의 신뢰성 스택(reliability stack)을 항해 용어로 번역하면 다음과 같습니다:

이 모든 방식은 추측 항법(dead reckoning)의 품질을 개선할 뿐입니다. 그 어느 것도 _검증된 위치(verified position)_를 제공하지 않습니다. 모든 방식에서 두 가지 속성이 결여되어 있으며, 각각에 대한 실시간 반례는 위에서 언급되었습니다:

외부화된 상태(Externalized state)는 여전히 자기 저작 상태(self-authored state)입니다. 잘못된 위치 정보를 믿고 있는 작업자는 영속화된 상태 파일(persisted status file)을 가지고 있었습니다 — 이는 체크포인팅(checkpointing)의 전형적인 모습입니다. 검증 없는 외부화는 망상(delusion)을 영속화할 뿐입니다. 위치에 대한 주장은 그 작성자 이외의 무언가가 이를 거부할 수 없다면 아무런 가치가 없습니다.

기준 좌표계(reference frame) 자체가 표류(drift)할 수 있습니다. QA 루프(QA loop)가 연속 9번 로컬하게(locally) 정확했음에도 불구하고 프로젝트를 망쳤던 이유는, 위 표의 그 어떤 해결책도 루프가 측정 기준으로 삼는 _표준(standard)_을 고정(anchor)하지 못하기 때문입니다. 루프는 위치를 수정하지 않습니다; 루프는 반복(iteration)마다 편향(bias)을 누적시킵니다.

길을 잃은 항해사에게 필요한 것은 더 두꺼운 항해 일지나 더 깔끔한 항해 일지, 또는 항해 일지를 비교하는 항해사 위원회가 아닙니다. 그에게 필요한 것은 움직이지 않는 기준점(datum)을 바탕으로, 배 외부에서 얻는 위치 수정(position fix)입니다.

루프 안의 인간(human in the loop)이 처음부터 위치 가이드였습니다

이는 당연한 질문을 불러일으킵니다. 만약 이 누락된 도구가 이토록 근본적인 것이라면, 왜 산업 전체가 이를 알아차리지 못했을까요? 그것은 표준적인 완화 방법(mitigation)이 이를 숨기고 있기 때문입니다. 루프 안에 인간(human in the loop)을 배치하면 드리프트(drift)는 사라집니다. 그리고 모두가 인간이 _지능(intelligence)_을 제공하고 있다고 결론지었습니다. 인간이 각 체크인(check-in) 시점에 실제로 수행하는 일을 분해해 보십시오. "경로를 벗어났습니다" — 이는 위치 수정(position fix)입니다. "그게 아니라 이것입니다" — 이는 엔트런스 콜랩스(entrance collapse)입니다. 그리고 드물게, "이 프레이밍은 틀렸으니 중단하세요" — 이것이 실제 판단(judgment)입니다. 앞의 두 가지는 지능적인 작업이 아닙니다. 그것은 수동적인 위치 서비스입니다. 즉, 인간의 빈도로 호출되며, 엔지니어의 급여로 책정되고, 지루함과 함께 성능이 저하되는 인간 GPS입니다. 루프 안의 인간(Human-in-the-loop) 방식이 작동하는 이유는 정확히 그것이 수동으로 작동하는 위치 가이드이기 때문이며, 바로 그 점 때문에 확장(scale)할 수 없고, 산업계에 그것이 무엇을 제공하고 있는지에 대해 잘못된 교훈을 주었습니다.

에이전트(agent)는 해당 체크인 시점에 인간의 지성을 필요로 했던 것이 아닙니다. 내가 관찰한 드리프트가 발생한 리뷰어는 길을 잃은 상태에서도 트리거 공격(trigger attacks)을 고안해 내는 진정으로 뛰어난 작업을 수행하고 있었습니다. 에이전트에게 필요했던 것은 인간의 _좌표(coordinates)_였습니다. 그리고 인간이 제공하는 세 가지 서비스 중 두 가지는 기계적입니다. 런타임(runtime)은 피로도 없이, 급여 없이도, 3단계에서나 3,000단계에서나 동일하게, 매 단계마다 즉각적으로 위치와 엔트런스(entrance)를 제공할 수 있습니다. 이것이 루프를 체계화(systematizing)해야 하는 진짜 이유입니다. 기계가 인간보다 더 똑똑하기 때문이 아니라, 그곳에서 인간이 하는 일의 대부분은 애초에 판단(judgment) 작업이 아니었기 때문입니다.