나의 인프라 분석가 에이전트(infrastructure analyst agent)는 아직 이름 붙이지 못한 루프에 빠져 있었습니다.

에이전트는 환각(hallucinated)된 컬럼 이름으로 SQL 쿼리를 작성합니다. 그러면 쿼리는 Postgres 에러와 함께 실패합니다. 나의 에러 핸들러(error handler)는 pg_attribute로부터 실제 컬럼 리스트를 다시 전달합니다. 에이전트는 이를 읽고, 추론 과정(reasoning trace)에서 수정을 인지한 뒤, 다음 시도에서 정확히 똑같은 잘못된 컬럼 이름을 다시 작성합니다.

다른 잘못된 컬럼이 아닙니다. 바로 그 동일한 컬럼입니다.

나는 이를 '작화 연쇄 (confabulation cascade)'라고 부르기 시작했습니다. 실제로 어떤 일이 일어나고 있었는지, 왜 이것이 모델의 문제라기보다 도구 설계(tool design)의 문제인지, 그리고 내가 이에 대해 무엇을 했는지 설명하겠습니다.

설정 (The Setup)

Nexus는 나의 개인 지능 플랫폼입니다. 이 플랫폼은 191개의 테이블로 구성된 Postgres 스키마를 대상으로 8개 이상의 자율 에이전트(autonomous agents)를 실행하며, 주간 삶의 단계 분석, 관계 건강 추적, 24년 치 개인 데이터로부터의 전기적 추론(biographical inference)과 같은 작업들을 수행합니다. 인프라 분석가 에이전트는 패턴과 이상 징후를 드러내기 위해 해당 테이블들을 쿼리하는 책임을 집니다.

에이전트가 Nexus에서 SQL을 작성할 때, 이들은 tool-executor.ts의 handleQueryDb를 거칩니다. 핸들러는 SELECT 전용 액세스를 강제하고, 에이전트 범위의 역할(agent-scoped roles)을 적용하며, 실패 시 query-db-schema-hint.ts의 buildQueryDbSchemaHint()를 호출하여 에러 메시지를 보강합니다.

문제가 발생한 지점은 바로 그 마지막 부분이었습니다.

반응형 스키마 힌트 (The Reactive Schema Hint)

buildQueryDbSchemaHint()는 두 가지 일을 수행합니다:

• “column does not exist” 에러 발생 시: pg_attribute를 조사(introspect)하여 해당 테이블의 실제 컬럼 리스트를 반환합니다.

• “table does not exist” 에러 발생 시: pg_class에서 유사한 테이블 이름을 검색하여 제안합니다.

이것은 유용합니다. 이 기능이 트리거되면 에이전트는 정확한 스키마 정보를 얻게 됩니다. 문제는 바로 “언제”인가 하는 점입니다. 이 힌트는 순수하게 반응적(reactive)입니다. 쿼리가 실패한 후에만 실행됩니다.

describe_table 도구도 없고, get_schema 호출도 없습니다. 에이전트가 SQL을 작성하기 전에 “aurora_life_chapters에는 어떤 컬럼들이 있는가?”라고 물을 방법이 없습니다. 진실(ground truth)에 도달하는 유일한 경로는 시행착오뿐입니다.

따라서 에이전트의 루프는 다음과 같았습니다:

1. 쿼리(query)를 생성합니다. 컬럼 이름은 학습된 가중치(training weights)와 컨텍스트(context)에서 가져오는데, 이를 '확신에 찬 사전 확률(confident prior)'이라고 부릅시다.

2. 쿼리가 실패합니다. 실제 컬럼 목록이 포함된 에러 메시지(error message)가 도착합니다.

3. 에이전트는 다음 생성 시 이 수정 사항을 컨텍스트(context)로 처리합니다.

4. 학습된 사전 확률(training prior)이 다시 주장됩니다. 새로운 쿼리에서도 동일한 잘못된 컬럼이 나타납니다.

5. 1번으로 돌아갑니다.

에이전트는 수정 사항을 무시한 것이 아니었습니다. 에이전트는 두 가지 상충하는 신호를 받고 있었습니다. 하나는 현실에 기반한 에러 메시지 수정이고, 다른 하나는 모델의 가중치(weights)에 내재된 더 강력한 스키마 사전 확률(schema prior)이었습니다. 수정 사항은 한 번 도착했지만, 사전 확률은 매 토큰(token)마다 도착했습니다. 어느 쪽이 승리했을지 짐작해 보십시오.

이것이 도구 설계 문제인 이유

이를

async function handleDescribeTable(
  tableName: string
): Promise<{ columns: Array<{ name: string; type: string; nullable: boolean }> }> {
...

에이전트의 도구 권한(tool grants)에 이를 등록하십시오. 도구 실행기 디스패치(tool executor dispatch)에 추가하십시오. 완료되었습니다.

그 결과 나타나는 에이전트의 동작:

1. 익숙하지 않은 테이블에 대해 SQL을 작성하기 전에, describe_table을 호출합니다.

2. 권위 있는(authoritative) 컬럼 이름과 타입을 돌려받습니다.

3. 검증된 스키마(schema)를 바탕으로 쿼리를 작성합니다.

연쇄(cascade)가 멈췄습니다. 모델이 더 똑똑해졌기 때문이 아니라, 더 이상 추측할 필요가 없기 때문입니다.

더 넓은 패턴

만약 여러분의 에이전트가 실제 데이터 저장소(데이터베이스, API, 파일 시스템 등)를 대상으로 도구 호출(tool calls)을 작성하고 있다면, 스스로에게 물어보십시오. 에이전트가 행동하기 전에 구조를 검증할 수 있는가, 아니면 오직 실패함으로써만 배울 수 있는가?

이 질문에 대한 답은 여러분이 마주하게 될 버그의 종류를 바꿉니다.

사후 반응적인 에러 힌트(Reactive error hints)는 가치가 있습니다. 하지만 그것만으로는 충분하지 않습니다. 오직 실패를 통해서만 현실을 발견할 수 있는 에이전트는 '관리된 환각(managed hallucination)' 상태에서 작동하고 있는 것입니다. 즉, 수정될 때까지 틀리고, 수정되면 이전의 상태가 다시 주장될 때까지 수정되었다가, 다시 틀린 상태로 돌아가는 상태입니다.

선제적인 자기 성찰 도구(Proactive introspection tools)는 설계 단계에서 이 루프를 끊어냅니다. 에이전트가 먼저 물어볼 수 있게 하는 것입니다. 이것은 프롬프트 엔지니어링(prompt engineering)의 해결책이 아닙니다. 그것은 도구 인터페이스(tool surface)에 대한 결정입니다.

이는 방어적 에러 처리(defensive error handling)와 입력 유효성 검사(input validation)의 차이와 같은 원리입니다. 예외(exception)를 잡는 것이 충돌(crash)하는 것보다 낫습니다. 하지만 유효하지 않은 입력을 아예 생성하지 않는 것이 예외를 잡는 것보다 더 낫습니다. 검사 단계를 더 앞당기십시오.

SQL을 작성하는 에이전트의 경우, 실패 후의 schema_hint보다 쿼리 전의 describe_table이 훨씬 낫습니다. 제가 이해하는 데 디버깅 세션 하나를 통째로 써야 했던 그 루프는, 도구 인터페이스가 애초에 추측을 요구하지 않는다면 마주칠 일조차 없습니다.

Nexus는 개인 하드웨어에서 실행되는 저의 개인 지능 플랫폼입니다. 에이전트 런타임(agent runtime), 작업 시스템(job system), 그리고 Postgres 스키마는 모두 자체 제작되었습니다. 아키텍처에 관한 게시물은 niclydon.io에서 확인하실 수 있습니다.