당신의 에이전트가 또 실패했고, 당신은 트랜스크립트(transcript)를 다 읽기도 전에 모델 드롭다운 메뉴로 손을 뻗었습니다. 모델은 당신의 에이전트 중 공개되어 있고, 순위가 매겨지며, 논쟁의 대상이 되는 유일한 부분입니다. 그 외의 모든 것은 비공개적이고, 화려하지 않으며, 당신만의 영역입니다. 그래서 당신은 눈에 보이는 레이어(layer)를 업그레이드하고, 실제로 실패하고 있는 레이어는 그대로 방치합니다.

당신은 당신의 신뢰를 조용히 갉아먹고 있는 레이어가 아니라, 이야기하기 가장 쉬운 레이어를 디버깅(debugging)해 왔습니다.

이러한 반사 작용은 정교한 형태로도 나타납니다. 단순히 드롭다운을 클릭하지 않는 빌더(builders)들은 대신 더 두꺼운 하네스(harness), 더 큰 컨텍스트 윈도우(context window), 혹은 모두가 게시하고 있는 프레임워크(framework)를 찾습니다. 이는 동일한 움직임입니다. 보이지 않는 부분을 진단하지 않아도 되도록, 눈에 보이는 부분에 비용을 쓰는 것입니다.

7가지 레이어 (The Seven Layers)

나는 이제 피해가 가장 멀리까지 미치는 레이어부터 시작하여, 고정된 순서에 따라 7개의 레이어를 통해 디버깅합니다. 각 레이어마다 하나의 질문과, 해당 레이어가 결핍(starved)되었을 때 나타나는 실패 징후(failure signature)가 있습니다.

외부에서 내부로 디버깅하고, 내부에서 외부로 설계하라

당신은 탑다운(top down) 방식으로 구축합니다. 작업을 정의하고(Purpose), 하네스(harness)를 결합하며, 기술을 패키징(package)합니다. 하지만 디버깅은 바텀업(bottom up) 방식으로 수행해야 합니다. 다른 모든 것이 추론의 근거로 삼는 사실인 데이터(Data)부터 시작하십시오. 결핍된 레이어가 아래에 위치할수록, 그 결함은 이미 더 멀리 퍼져 있기 때문입니다.

설계는 외부에서 내부로(outside-in) 하십시오. 디버깅은 내부에서 외부로(inside-out) 하십시오. 드롭다운 반사 작용이 실패하는 이유는 스택(stack)의 설계 끝단인 최상단에서 디버깅을 시도하기 때문입니다.

데이터 함정 (The data trap)

가격, 버전, 정책을 인용하는 리서치 에이전트(research agent)는 대개 데이터에서 문제가 발생합니다. 검색(retrieval)된 정보가 오래되었고, 그 위의 체크 과정은 건전하지만, 실패의 양상은 이미 변해버린 세상으로부터 끌어온 자신만만한 답변으로 나타납니다. 더 큰 모델을 사용하면, 모델은 더 침착하게(more poise) 업데이트되지 않은 수치를 내놓을 뿐입니다. 결핍된 바닥은 누구도 예상했던 것보다 더 낮은 곳에 있습니다.

에이전트의 사실(facts)이 유입되는 지점을 찾으세요: 검색 호출(retrieval call), 시스템 프롬프트(system prompt)에 작성된 가정들, 문서 세트(document set) 등입니다. 그다음 하나의 주장(claim)을 그 출처와 대조해 보세요. 에이전트가 가격, 버전, 정책 등을 인용할 때 — 그 사실이 마지막으로 언제 갱신되었는지 명시할 수 있습니까? 그것이 여전히 현실 세계와 일치합니까?

검증의 함정 (The verification trap)

깔끔하고 잘 구성된 산문이나 코드를 생성하는 에이전트는 대개 한 단계 위인 검증(verification) 단계에서 무너집니다. 통과하는 테스트 스위트(test suite)를 가리키며 가장 쉽게 초록색(pass)으로 표시할 수 있는 행(row)입니다. 하지만 그 테스트들이 무엇을 확인하는지 살펴보십시오. 대부분은 출력이 올바른 형태(shape)인지를 확인하며, 그것이 _옳은지(right)_를 테스트하는 경우는 거의 없습니다. 그것은 검증 배지를 달고 있는 형식 확인(format check)일 뿐입니다.

함정은 자신의 행동을 스스로 재작성하는 에이전트의 경우 더욱 심각합니다. 이러한 에이전트는 해당 테스트들이 보호하고자 했던 행동으로부터 벗어나면서도 모든 검사를 통과할 수 있습니다. 초록색 테스트 스위트가 결핍된 검증 계층(verification layer) 위에 놓여 있을 수 있으며, 이는 때때로 눈먼 상태를 유지하는 가장 비용이 많이 드는 방법이 됩니다.

감사(audit)를 실행하는 방법

디버그 순서에 따라 아래에서 위로, 일곱 가지 질문을 가져오십시오. 각 질문에 대해, 답변이 되는 증거를 당신의 리포지토리(repo)에서 작성하십시오: 파일 경로, 주장된 비교(asserted comparison), 메모리 저장소(memory store)의 마지막 쓰기(last write) 등입니다. 이 모든 것이 반드시 파일일 필요는 없습니다. 로우 SDK 루프(raw SDK loop)에서는 호출 사이에 유지(persist)하는 모든 것이 메모리입니다. 형식은 중요하지 않습니다.

해당 계층이 어디에 존재하는지 가리키는 대신, 그 계층을 어느 정도 처리하고 있다는 문장을 쓰고 있는 자신을 발견한다면, 당신은 결핍된 행(starved row)을 찾은 것입니다.

일곱 가지 중 대부분은 몇 분 안에 명확해집니다 — 이미 당신이 신뢰하고 있는 행들입니다. 이 모든 것을 실행하는 것이 바로 추측하는 대신, 문제가 되는 한두 가지로 바로 넘어갈 수 있는 권리를 얻는 방법입니다. 결핍된 행은 당신이 이름을 붙이지 않은 채 수동으로 보완해 오던 바로 그 지점입니다.

어떤 계층이 유행하는지는 계속 변합니다 — 작년에는 메모리(memory)였고, 지금은 컨텍스트 엔지니어링(context engineering)입니다 — 하지만 감사는 그중 무엇이 당신의 것인지 알려주는 도구입니다. 모델을 업그레이드하기 전에, 하네스(harness)를 다시 구축하기 전에, 이 7단계 과정을 실행하십시오. 빨간색으로 표시되어 돌아오는 행은 이미 당신의 신뢰를 갉아먹고 있는 지점이며, 이를 명명하는 순간 낭비되는 움직임이 멈출 것입니다. 즉, 모델과 논쟁하는 것을 그만두고, 애초에 문제가 아니었던 프롬프트(prompt)를 다시 쓰는 일을 멈추며, 사실 관계가 처음부터 오래된 계층에 메모리를 추가하는 일을 중단하게 됩니다.

이 글은 전체 프레임워크, 실제 작동 예시, 그리고 무료 1페이지 감사 출력물을 포함하고 있는 The Durability Curve의 전체 기사를 요약한 버전입니다.