코딩 에이전트를 위한 AEO 추적 시스템 구축 방법

AI 는 사람들이 정보를 찾는 방식을 바꾸었습니다. 기업들에게 이는 LLM 이 웹 콘텐츠를 검색하고 요약하는 방식을 이해하는 것이 매우 중요함을 의미합니다. 우리는 Vercel 와 우리 사이트가 모델에 의해 발견, 해석, 참조되는 방식을 추적하기 위해 AI 엔진 최적화 (AEO) 시스템을 구축 중입니다. 이는 표준 채팅 모델에만 초점을 맞춘 프로토타입으로 시작했지만, 그것이 충분하지 않음을 빠르게 깨달았습니다. 완전한 가시성 그림을 얻기 위해서는 코딩 에이전트도 추적해야 합니다. 표준 모델의 경우 추적은 비교적 간단합니다. 우리는 수십 개의 인기 있는 모델 (예: GPT, Gemini, Claude) 에 프롬프트를 보내고 응답, 검색 행동, 인용된 출처를 분석합니다. AI Gateway 코딩 에이전트는 매우 다르게 행동합니다. 많은 Vercel 사용자는 프로젝트 작업 중에 터미널이나 IDE 를 통해 AI 와 상호작용합니다. 초기 샘플링에서 우리는 코딩 에이전트가 프롬프트의 약 20% 에서 웹 검색을 수행함을 발견했습니다. 이러한 검색이 실제 개발 워크플로우와 함께 발생하므로 응답 품질과 출처 정확성을 평가하는 것이 특히 중요합니다. 코딩 에이전트의 AEO 를 측정하려면 모델 전용 테스트와 다른 접근 방식이 필요합니다. 코딩 에이전트는 단일 API 호출에 답하도록 설계되지 않았습니다. 프로젝트 내부에서 작동하고 파일 시스템, shell 액세스, 패키지 관리자를 포함한 완전한 개발 환경을 기대합니다. 이는 새로운 도전 과제를 만듭니다: 코딩 에이전트는 일반적으로 CLI 를 통해 (API 를 통해 아님) 접근됩니다. 프롬프트를 보내고 응답을 캡처한다고 해도 CLI 는 완전한 런타임 환경에서 설치되고 실행되어야 합니다. 이를 해결하기 위해 몇 초 만에 시작되는 일시적인 Linux MicroVM 을 제공합니다. 각 에이전트 실행은 자체 샌드박스를 가지며, 사용하는 CLI 가 동일하게 6 단계의 라이프사이클을 따릅니다.

Vercel Sandbox
코드에서 라이프사이클은 다음과 같습니다. 라이프사이클이 균일하므로 각 에이전트는 간단한 config 객체로 정의할 수 있습니다. 새로운 에이전트를 시스템에 추가하는 것은 새 엔트리를 추가하는 것뿐이며, 샌드박스 오케스트레이션은 나머지를 처리합니다.

image: MicroVM 의 기본 이미지를 결정합니다. 대부분의 에이전트는 Node 에서 실행되지만, 시스템은 Python 런타임도 지원합니다.

runtime 는 배열입니다. 일부 에이전트가 글로벌 설치보다 더 많은 것을 필요로 하기 때문입니다. 예를 들어 Codex 는 .toml 설정 파일이 ~/.codex/config.toml 에 작성되어야 합니다.

setupCommands 은 프롬프트를 받아 shell 명령어를 반환하는 함수입니다. 각 에이전트의 CLI 는 자체 플래그와 호출 스타일을 가집니다.

buildCommand
우리는 AI Gateway 를 비용 및 로그 관리의 중앙 집중화를 위해 사용하고자 했습니다. 이는 샌드박스 내부에서 제공자의 기본 URL 을 환경 변수로 덮어쓰는 것을 필요로 했습니다. 에이전트 자신은 이것이 일어나고 있다는 것을 알지 못하며 직접 제공자와 대화하는 것처럼 작동합니다. Claude Code 에서는 다음과 같습니다:

ANTHROPIC_BASE_URL 은 AI Gateway 를 .anthropic.com 대신 지시합니다. 에이전트의 HTTP 호출은 Gateway 로 가며 Anthropic 으로 프록시됩니다.

api.anthropic.com 의 ANTHROPIC_BASE_URL 은 의도적으로 빈 문자열로 설정되어 있습니다. Gateway 는 자체 토큰을 통해 인증하므로 에이전트는 직접 제공자 키를 필요 (또는 보유) 하지 않습니다.

ANTHROPIC_API_KEY
이 패턴은 Codex (override ) 와 base URL 환경 변수를 존중하는 다른 모든 에이전트에 적용됩니다. Provider API 자격 증명은 직접 사용할 수도 있습니다.

OPENAI_BASE_URL
에이전트가 샌드박스에서 실행을 마친 후 우리는 원본 전사록 (raw transcript) 을 가지며, 이는 수행한 모든 일의 기록입니다. 문제는 각 에이전트가 서로 다른 형식으로 전사록을 생성한다는 것입니다.

Claude Code 는 디스크에 JSONL 파일을 작성합니다. Codex 는 stdout 으로 JSON 을 스트리밍합니다. OpenCode 또한 stdout 을 사용하지만 다른 스키마를 사용합니다. 그들은 동일한 도구를 위한 다른 이름, 메시지용 다른 네스팅 구조, 그리고 다른 관습을 사용합니다. 우리는 이를 단일 브랜드 파이프라인으로 공급해야 했으므로 4 단계 정규화 레이어를 구축했습니다: 이 단계는 샌드박스 (previous section 의 lifecycle 에서의 step 5) 가 아직 실행 중일 때 발생합니다. 는 sandbox filesystem 에 JSONL 파일을 transcript 로 작성합니다. 에이전트가 끝나면 찾아서 읽어야 합니다: Claude Code 는 stdout 으로 transcripts 를 출력했으므로, 캡처는 더 간단합니다 — JSON lines 을 필터링하세요: Codex 와 OpenCode 이 단계의 출력은 모든 에이전트에게 동일합니다: 원시 JSONL 의 문자열입니다. 하지만 각 JSON 라인의 구조는 여전히 에이전트마다 완전히 다릅니다. 그리고 그것이 다음 단계를 처리합니다. 우리는 각 에이전트를 위한 전용 파서를 구축했습니다. 이는 두 가지 일을 동시에 수행합니다: 도구 이름 정규화 및 에이전트 특이적 메시지 구조를 단일 포맷 이벤트 타입으로 평탄화 (flatten) 합니다. 도구 이름 정규화 동일한 작업은 에이전트마다 다른 이름을 갖습니다: 각 파서는 ~10 개의 canonical names 에 대한 에이전트 특이적 이름을 매핑하는 lookup table 을 유지합니다. 메시지 형식 평탄화 이명칭 외에도 이벤트의 구조는 에이전트마다 다릅니다: 각 에이전트의 파서는 이러한 구조적 차이를 처리하고 모든 것을 단일 타입으로 압축합니다: TranscriptEvent 이 단계의 출력은 에이전트가 생성했는지와 관계없이 동일한 모양의 flat array of TranscriptEvent[] 입니다. 파싱 후, 모든 이벤트에 대해 공유된 포스트 프로세싱 단계가 실행됩니다. 이는 downstream code 가 Claude Code 가 파일 경로를 args.path 로 넣는 반면 Codex 는 args.file 를 사용하는 것을 알아야 할 필요가 없도록 도구 arguments 에서 구조화된 메타데이터를 추출합니다. enrich 된 array 는 같은 브랜드 추출 파이프라인에 표준 모델 응답을 위해 사용된 aggregate stats (total tool calls by type, web fetches, errors) 로 요약됩니다. 이 시점부터 시스템은 데이터가 코딩 에이전트에서 왔는지 아니면 모델 API 호출에서 왔는지를 알거나 신경 쓰지 않습니다. TranscriptEvent[] 이 전체 파이프라인은 . 으로 실행됩니다. 프롬프트가

ll 명령어를 실행합니다. 에이전트를 프롬프트와 함께 실행합니다. 에이전트가 완료된 후, 수행한 작업의 기록을 추출합니다 (사용한 도구, 웹 검색 여부, 응답에 포함된 추천 사항 등). 이는 에이전트 특이적이며 (아래에서 다루음), 트랜스크립트를 캡처합니다. 샌드박스를 중지합니다. 문제가 발생하면 블록은 샌드박스를 무조건 중지하여 리소스 누수를 방지합니다. Tear down.

catch: 각 에이전트는 트랜스크립트를 다르게 저장하므로 이 단계는 에이전트 특이적입니다.

Transcript capture (트랜스크립트 캡처): 각 에이전트는 도구 이름과 에이전트 특이적 메시지 구조를 단일 통합 이벤트 유형으로 정규화하는 자체 파서를 가집니다.

Parsing: 공유된 후처리 과정으로, 도구 인수에서 구조화된 메타데이터 (URL, 명령어) 를 추출하고 각 에이전트가 인수를 어떻게 명명하는지 다른 점을 정규화합니다.

Enrichment (풍부화): 통합 이벤트를 통계로 집계한 후, 표준 모델 응답에 사용된 동일한 브랜드 추출 파이프라인으로 입력합니다.

Summary and brand extraction: 코딩 에이전트 AEO 라이프사이클

AI Gateway 를 사용한 라우팅

트랜스크립트 형식의 문제

Vercel Workflow 를 사용한 오케스트레이션

배운 것

다음 단계

에이전트를 설정으로 사용

1 단계: 트랜스크립트 캡처
2 단계: 도구 이름 및 메시지 형태 파싱
3 단계: 풍부화
4 단계: 요약 및 브랜드 추출

Operation Claude Code Codex OpenCode

Read a file (파일 읽기): read_file
Write a file (파일 쓰기): write_file
Edit a file (파일 편집): StrReplace patch_file patch
Run a command (명령 실행): Bash shell bash
Search the web (웹 검색): WebFetch (varies)

Claude Code 는 메시지를 속성 안에 넣고 content arrays 에 블록을 섞습니다.
Claude Code message tool_use 는 Responses API 라이프사이클 이벤트 (, , ) 를 도구 이벤트와 함께 가집니다.
Codex thread.started turn.completed output_text.delta 는 tool call + result 를 same event via and . 로 묶습니다.
OpenCode part.tool part.state

랜덤 프롬프트 샘플에 대한 초기 테스트에서 코딩 에이전트는 약 20% 의 시간을 검색으로 실행하는 것으로 나타났습니다. 더 많은 데이터를 수집하여 에이전트 검색 행동을 더 포괄적으로 파악할 계획이나, 이 결과는 코딩 에이전트를 위한 콘텐츠 최적화가 중요함을 명확히 했습니다.

코딩 에이전트는 웹 검색에서 유의미한 트래픽을 기여합니다.

코딩 에이전트가 도구를 제안하면, 그 도구를 사용하여 작동하는 코드를 생성하는 경향이 있습니다 (예: if statement, config file, deployment script). 추천은 문법적 언급뿐만 아니라 출력에 내장되어 있습니다.

에이전트 추천은 모델 응답과 다른 형태를 가집니다.

import 는 에이전트 CLI 도구가 빠른 업데이트를 출시함에 따라 더 복잡해지고 있습니다.

정규화 레이어를 초기에 구축하여 지속적인 파손을 방지했습니다.

트랜스크립트 형식은 엉망입니다.

어려운 부분은 모든 상류 작업입니다: 에이전트를 실행하고, 수행한 작업을 캡처하며, 등급할 수 있는 구조로 정규화하는 것입니다.

모델과 에이전트 모두 동일한 브랜드 추출 파이프라인이 작동합니다.

우리는 시스템을 오픈소스 버전으로 출시하여 다른 팀이 표준 모델 및 코딩 에이전트를 위해 자신의 AEO 평가 (evals) 를 추적할 수 있도록 계획하고 있습니다.

도구를 오픈소스로 합니다.

우리는 프롬프트 설계, 듀얼 모드 테스트 (웹 검색 vs. 학습 데이터), query-as-first-class-entity 아키텍처, 그리고 Share of Voice metrics 를 포함한 전체 AEO 평가 방법론을 다루는 후속 포스트를 준비 중입니다.

방법론에 대한 심층 분석.

생태계가 성장하고 에이전트 유형이 늘어나며 테스트하는 프롬프트 유형도 확장 (단순히 "도구 추천"뿐만 아니라 프로젝트 스프래핑, 디버깅 등). 에이전트 커버리지 확대.