기술 요약: TraceCompiler

문제 정의

도구 사용 언어 모델(LLM) 에이전트는 이미 실행했던 절차를 반복해서 재발견하며, 이로 인해 토큰 사용량과 지연 시간이 크게 증가하는 문제를 겪는다. 단일한 반복 의도(예: 결제 요청 또는 티켓 목록 조회)는 종종 재사용 가능한 구조(필요한 도구, 실제 데이터 의존성, 안정적인 설정)와 우발적 실행 이력(재시도, 스키마 탐색 조회, 스타일적 순서, 반복적인 사실 해결)이 혼합된 트레이스를 유발한다.

텍스트 가이드로 트레이스를 요약하는 기존 방식은 여전히 런타임에 LLM이 해당 절차를 다시 해석해야 한다는 한계가 있다. 전통적인 프로세스 발견(process discovery) 방식은 관찰된 이벤트의 순서가 의존성을 의미하지 않기 때문에 불충분하다. 연속적인 호출은 독립적인 작업, 실패한 시도, 또는 데이터 흐름의 결과일 수 있기 때문이다. 또한, 배포된 로그는 종종 부분적 관측 가능성(partial observability) 문제를 겪으며, 인자(arguments)는 기록하지만 도구의 출력값은 기록하지 않아, 프로듀서의 출력과 컨슈머의 입력을 매칭함으로써 의존성을 검증하는 것이 불가능하다.

핵심 과제는 노이즈가 섞인 부분적으로 관측 가능한 에이전트 트레이스를 실행 가능하고 대부분 결정론적인 워크플로우로 컴파일하는 것이다. 이를 통해 증거에 의해 뒷받침되는 결정 사항들은 모델의 런타임 책임에서 제거하고, 오직 진정으로 열려 있는 선택지만을 LLM의 몫으로 남겨두어야 한다.

방법론

TraceCompiler는 노이즈가 섞인 트레이스 클러스터를 마이닝하여 타입이 지정된 워크플로우로 컴파일하는 스킬 가이드 시스템이다. 파이프라인은 다음 단계로 구성된다:

1. 의도 발견 및 클러스터링 (Intent Discovery and Clustering)

대화는 초기 요청과 그 사이에 끼어든 추론/도구 호출을 결합한 문서 형태로 임베딩된다. 임계값 응집(threshold agglomeration, 코사인 거리, 평균 연결법)을 통해 트레이스를 의도 클러스터로 그룹화한다. 시스템은 서로 다른 의도를 오염시키는 것을 방지하기 위해 보수적인 미결합(under-merging)을 우선시한다. 멱등한 프리패스(idempotent pre-pass)를 통해 관련 없는 의도가 혼합된 대화를 감지하고 분리한다.

2. 정규화 및 행동 디노이징 (Normalization and Behavioral Denoising)

원시 트레이스는 정규화된 app.action 어휘 집합으로 변환된다. 액션은 다음과 같이 라벨링된다:

• 필수(Essential): 작업을 위해 반드시 필요함.
• 복구/탐색/중복(Recovery/Exploratory/Redundant): 분석용으로는 유지되나 제거될 수 있음.
• 데드 출력(Dead Output): 출력이 다운스트림에서 소비되지 않는 액션 (예: 스키마 조회).
• 재시도 vs 변형(Retry vs. Variation): 시스템은 노이즈(성공으로 수렴하는 인자 조정)와 진정한 팬아웃(fan-out, 예: 곡별 검색과 같이 체계적으로 구별되는 인자)을 구분한다. 페이지네이션 루프는 리터럴 카운터를 통해 감지된다.

3. 인자 수준의 의존성 검증 (Argument-Level Dependency Verification)

이것이 핵심 혁신이다. 엣지 $a \to b$는 다음 조건을 만족할 때만 **강한 의존성(hard dependency)**으로 인정된다:

1. $b$의 인자 내의 값이 $a$의 출력으로부터 추적 가능하다.
2. 배제(Exclusion): 해당 값에 대한 모든 대안적 기원(사용자 발화, 정적 컨텍스트, 도구 기본값, 그리고 이전의 모든 호출 출력)이 배제된다.

만약 타당한 대안적 기원이 존재한다면(예: 두 개의 호환 가능한 타입의 프로듀서가 있는 경우), 해당 엣지는 의심됨(suspected) 상태로 강등되며 순서 제약을 부과하지 않는다. 이는 단순히 인접성에 기반하여 잘못된 의존성을 추론하는 것을 방지한다.

4. 프로비넌스 분류 및 정적 컨텍스트 (Provenance Classification and Static Context)

바인딩은 다음과 같이 분류된다:

• 상수(Constant): 트레이스 전반에 걸쳐 안정적임 (빌드 타임에 해결됨).
• 사용자 입력(User Input): 런타임에 해결됨.
• 복사 엣지(Copy Edge): 특정 프로듀서로부터 유래했음이 증명된 값.
• 변환(Transform): 결정론적 변환.
• LLM/동적(LLM/Dynamic): 런타임 모델 해결이 필요한 진정한 의미론적 바인딩.

컴파일러는 **범위 제한적 정적 컨텍스트 주입(scope-bound static-context injection)**을 수행하도록 지정되어, 안정적인 값을 빌드 타임에 해결하고 해당 값들에 대한 발견 도구 사용을 금지한다. 그러나 이 기능은 보고된 결과에서 실행되지 않았다. 두 사례 연구 모두 주입된 값을 보고하지 않았으며, 이 설계 요소는 아직 증거를 기다리고 있는 상태이다. 만약 되돌릴 수 없는 부작 옆(side effect)이 미결정 상태라면(예: 변형의 방향이 모호한 경우), 컴파일러는 **기권(abstain)**하고 실행 가능한 그래프를 생성하지 않은 채 요청을 에스컬레이션한다.

5. 컴파일 및 런타임 (Compilation and Runtime)

분석은 타입이 지정된 노드(TOOL, TRANSFORM, DECISION, LLM, HUMAN)를 가진 실행 가능한 정의(DAG)로 컴파일된다. 런타임 라우터는 컴파일된 워크플로우와 보수적인 유사성 임계값을 일치할 경우 요청을 디스패치한다. 일치하지 않는 요청은 일반 에이전트로 폴백(fallback)된다.

컴파일러 엔진(v1)은 훈련된 모델이 아니라 버전 관리된 LLM 스킬(에이전트에 로드되는 지침 패키지)로 구현된다. 이를 통해 재학습 없이도 적대적 감사(adversarial auditing)와 신속한 개정이 가능하다.

주요 기여

1. 정식화: 반복되는 에이전트 트레이스 재사용을 워크플로 구조, 파라미터 프로비넌스, 그리고 부분 관측 가능성 하에서의 잔여 LLM 결정에 대한 컴파일 문제로 프레이밍함.
2. 파이프라인: 의도 발견, 행동 디노이징, 의존성 검증, 프로비넌스 분류 및 실행 가능한 워크플로우 생성을 위한 완전한 비지도 학습 파이프라인을 제시함.
3. 의존성 규칙: 대안적 기원의 배제를 통해서만 엣지를 허용하는 정교하고 보수적인 인자 수준 의존성 규칙을 정립함. 이는 명시적인 증거 튜플과 모호한 경우를 위한 "의심됨" 관계를 도입함.
4. 평가: 메커니즘을 공유하지 않는 두 가지 그라운드 트루스(T1 및 AppWorld)를 대상으로 순서 기반 및 재발 발생 기반 베이스라인과 비교 평가함.
5. 사례 연구: 성공적인 컴파일(Venmo 송금 요청)과 되돌릴 수 없는 부의 효과가 미결정된 경우의 컴파일 거부(Spotify/Todoist)를 입증함.

결과

의존성 정확도

• T1 코퍼스 (훈련 분할): 기계화된 규칙은 15,775개의 def–use 엣지에 대해 **0.928 정밀도(precision)**와 **0.943 재현율(recall)**을 달성했다. 이는 인접성 기반 베이스라인(F1 0.711) 및 빈도 임계값 기반 직접 후속 측정(F1 0.712)을 크게 상회한다.
  • 주의사항: 절제 연구(ablation studies)에 따르면, 이 특정 코퍼스에서는 모든 관계가 적어도 하나의 후보 프로듀서를 가지고 있기 때문에 배제 테스트가 거의 무의미하다. 따라서 보고된 정확도는 전체 배제 테스트보다는 살아남은 후보들 중 최신성(recency)(가장 최근의 생존자를 선택)에 크게 의존하고 있다. 배제 규율은 기계화된 규칙이 아닌 LLM 스킬에 의해 실행된다.
• 블라인드 스킬 실행: T1의 250개 엣지 서브셋에 대해, LLM 스킬은 단 한 번의 실행으로 0.992 정밀도/재현율을 달了했다.
• AppWorld: 마스킹된 값을 복구하는 재생 기반 참조 모델에 대해, 규칙은 563개 토큰 엣지에서 0.993 정밀도를 달성했다. 이는 독립적인 검증이라기보다 자기 일관성 체크(self-consistency check) 역할을 하며, 참조 모델이 테스트되는 규칙과 동일한 가정(동일 애플리케이션 토큰 선호)을 공유한다는 점을 유의해야 한다. 또한, 이 실험은 세션 토큰 귀속만을 다루며 비토큰 식별자 흐름의 복구는 검증하지 않는다.

워크플로우 컴파일 및 실행

• Venmo 의도: 34개의 관찰된 API 호출(재시도 및 스키마 조회 포함)을 11개의 런타임 호출로 컴파일했다. 이 워크플로우는 보류된 인스턴스들에 대해 21개의 상태 테스트 중 15개를 통과했다. 6개의 실패는 해당 인스턴스에 필요한 특정 브랜치가 훈련 세트에서 관찰되지 않아, 시스템이 실행 대신 에스컬레이션을 수행했기 때문이다.
• Spotify/Todoist 의도: 컴파일러는 변형의 방향(추가 vs 삭제)이 트레이스에 의해 미결정 상태였으므로, 되돌릴 수 없는 부의 효과를 방지하기 위해 이 의도의 컴파일을 올바르게 거부했다.
• 호출 감소: 56개의 AppWorld 시나리오 전반에서, 제거 가능한 호출의 비율(스키마 발견 및 바이트 단위로 동일한 반복 호출)의 중앙값은 **51.4%**였다.

의도 발견

T1에서 클러스터링은 커버된 대화에 대해 **0.930의 순도(purity)**를 달성했으나, 참조 라벨에 대한 조정된 랜드 지수(Adjusted Rand Index)는 0.235로 낮았다. 이는 시스템이 오분류를 하는 것이 아니라, 참조 라벨보다 더 세밀한 파티션(도메인을 템플릿 수준의 태스크로 세분화)을 발견하고 있음을 나타낸다.

의의 및 주장

본 논문은 관찰된 인접성이 의존성을 의미하지 않는다고 주장한다. 대안적 기원을 배제해야 한다는 증거 규율을 강제함으로써, TraceCompiler는 노이즈 섞인 트레이스를 결정론적 워크플로우로 컴파일하여 런타임 도구 호출과 LLM 호출을 줄일 수 있다.

• 안전성: 시스템은 완결성보다 안전성을 우선시한다. 되돌릴 수 없는 동작이 미결정된 경우 컴파일을 자제하여, 안전하지 않고 추측적인 절차가 실행되는 것을 방지한다.
• 효율성: 본 논문은 호출 감소(예: 34 $\to$ 11 호출)를 측정하지만, 오프라인 컴파일 비용을 측정하지 않았으므로 순 효율성(net efficiency)을 명시적으로 주장하지는 않는다. 경제적 전제는 유능한 모델이 반복 실행에 걸쳐 분석 비용을 상쇄할 수 있다는 것이다.
• 한계: 저자들은 현재의 평가가 합성 또는 시뮬레이터 생성 데이터에 의존하고 있음을 인정한다. "배제" 규율은 LLM 스킬에 의해 실행되지만, 코퍼스의 한계(디코이 토큰 부족)로 인해 기계화된 규칙에 의한 데코이 테스트는 완전히 실행되지 않는다. 또한 시스템은 현재 API 드리프트에 대한 워크플로우 버전 관리 및 무효화 메커니즘이 부족하다.

이 연구는 관찰된 트레이스가 필요성(necessity)에 대한 주장을 의존성(dependency)에 대한 주장만큼이나 강력하게 구속한다는 것을 확립하며, 컴파일된 워크플로우를 테스트하는 도구(실행 하네스) 자체가 검증이 필요한 추론 절차임을 밝힌다.