관리형 런타임에서 라이브 에이전트를 운영하며 발견한 세 가지 놀라운 사실
Three things surprised us while running a live agent through a governed runtime
핵심 요약
에이전트 운영 시 추론보다 프롬프트 구조가 실행 안정성에 더 큰 영향을 미치며, 추론과 추출 단계를 분리하는 것이 효과적임을 발견했습니다.
- 프롬프트 구조 — 추론 품질보다 출력 형식이 실행 안정성을 결정함
- 의사결정 왜곡 — 엄격한 스키마가 모델의 추론 과정 자체를 압축할 수 있음
- 단계 분리 — 추론과 추출을 별도 에이전트로 나누는 것이 효율적임
- 거버넌스 위치 — 실행 경계에서 구조화된 페이로드를 제어하는 것이 가장 적합함
배경
실제 시장 데이터를 가지고 라이브 분석 에이전트를 돌려봤다. 실행 과정은 전부 거버넌스 런타임을 거치게 설계했음. 예산 제한, 의미론적 분류, 그리고 외부 시스템에 닿기 전 게이트웨이에서의 실행 제어까지 싹 다 포함해서 말이지. 분석이 실제 실행과 맞닥뜨렸을 때 도대체 뭐가 박살 나는지 확인하려고 추론 단계에서 통제된 실험을 진행했다. 단순히 프롬프트 퀄리티가 좋냐 나쁘냐를 따지는 게 아니라, 모델이 뱉어낸 결과물을 하위 시스템이 제대로 처리할 수 있는지를 본 거다.
놀랐던 점 세 가지
1. 실행 안정성을 결정짓는 건 추론 능력이 아니라 프롬프트 구조였다.
똑같은 데이터를 가지고 엄격한 JSON 출력 방식이랑 자유 형식의 자연어 분석 방식을 비교해 봤다. 각각 10번씩 돌려봄.
- Strict JSON: 10/10 파싱 성공
- Freeform: 0/10 파싱 성공
자유 형식으로 나온 답변들은 꽤나 그럴싸했다. 다중 시나리오 분석에 조건부 관점, 미묘한 불확실성까지 다 담겨 있었으니까. 근데 우리 파이프라인이 이걸 못 받아먹더라. 결국 안정성은 모델이 문제를 이해했느냐가 아니라, 출력값이 실행 시스템이 원하는 형태랑 맞느냐에서 갈리는 거였다.
2. 프롬프트 구조가 단순히 출력 형태만 바꾸는 게 아니라 의사결정 분포까지 건드리는 것 같았다.
세 번째 변수를 추가해 봤다. 자유 형식으로 추론하게 한 뒤 마지막에 구조화된 JSON 블록을 붙이는 방식. 데이터랑 모델은 그대로 유지했다.
실험할 때마다 분포는 조금씩 달랐지만, 입력값이 똑같아도 포맷에 따라 결과값이 계속 다르게 나왔다. 엄격한 스키마를 씌우니까 다중 시나리오 추론이 강제로 한 방향으로 압축되는 느낌이더라. 단순히 직렬화 방식만 바꾼 게 아니라, 에이전트가 내리는 결정 자체를 바꿔버린 걸지도 모른다.
3. 추론과 추출은 분리할 수 있다.
두 개의 명시적인 호출로 쪼개봤다. 에이전트 A는 자유 형식으로 추론하고, 에이전트 B는 A의 결과물을 읽어서 딱 JSON만 뱉게 만든 거다.
에이전트 B는 10/10 파싱 성공률을 유지했고, A는 여전히 풍부하고 때로는 모순적인 분석 내용을 담아냈다. A의 글에 단일 라벨로 정의할 수 없는 여러 조건부 시나리오가 섞여 있어도, 추출된 결과값은 기계가 읽기 딱 좋게 나왔다. 각 계층마다 할 일이 따로 있는 거다.
결론
이제 우리는 세 가지 계층으로 생각한다.
- 추론(Reasoning) — 자유로운 분석, 불확실성, 다중 시나리오
- 추출(Extraction) — 파이프라인이 파싱 가능한 구조화된 출력
- 실행(Execution) — 예산, 의미론, 권한 부여가 실제로 적용되는 통제 경계
현재 우리가 세운 가설은 거버넌스는 실행과 가장 가까운 곳, 즉 결정이 행동으로 옮겨지는 지점에 있어야 한다는 거다. 자유 형식의 추론을 통제하려고 드는 건 계층을 잘못 잡은 느낌이다. 실행 경계에서 구조화된 페이로드를 통제하는 게 정답인 것 같다.
다들 어떻게 하는지 궁금함
지금 프로덕션 에이전트 돌릴 때 실행 제어, 도구 권한 부여, 거버넌스는 어떻게 처리하고 있음? 프롬프트 단에서 함? 아니면 미들웨어 계층? 그것도 아니면 도구 경계에서? 뭐가 잘 먹히고 뭐가 아직 임시방편 수준인지 궁금하다.
