Vercel Agent Runs: AI 에이전트 작업은 이제 “관측 가능한 실행 기록”이어야 한다

테크

AI 에이전트가 코드를 고치고 PR을 열고 배포 로그를 읽는 시대에는 “무엇을 했는지”보다 “나중에 무엇을 재현할 수 있는지”가 더 중요해진다. 사람이 작성한 코드도 commit, CI log, review comment, deploy event가 남는다. 에이전트가 한 작업도 같은 수준의 증거가 없으면 팀은 생산성을 얻는 대신 운영 공백을 만든다.

AI 에이전트 작업이 Agent Runs trace로 기록되고 Vercel MCP와 CLI를 통해 리뷰, 비용, 로그, 장애 대응으로 이어지는 워크플로 다이어그램
Agent Runs는 에이전트 작업을 “좋은 답변”이 아니라 재현 가능한 운영 기록으로 다루게 만든다.

무슨 일이 있었나

Vercel은 2026년 7월 3일 Agent Runs를 Vercel MCP와 CLI에서 지원한다고 발표했다. 변경 기록에 따르면 개발자는 MCP의 list_agent_runs, get_agent_run_details, search_agent_run_traces, get_agent_run_summary 도구와 CLI의 vercel agent list, vercel agent inspect, vercel agent search, vercel agent summary 명령으로 에이전트 실행 기록을 조회할 수 있다.

Agent Runs 자체는 Vercel의 agent observability 화면이다. 공식 문서는 eve 기반 agent의 실행이 자동으로 관측성 traces에 들어오며, 별도 instrumentation이 필요하지 않다고 설명한다. 화면에서는 run status, start time, duration, model, token usage, trace timeline, logs, reasoning steps, errors 같은 실행 맥락을 볼 수 있다.

이번 업데이트의 실무 포인트는 UI보다 접근 표면이다. 대시보드에서만 보던 기록을 MCP와 CLI로 꺼낼 수 있으면, 에이전트가 스스로 이전 실행을 조회하거나, CI/incident 스크립트가 실패한 run의 요약을 뽑거나, 운영자가 터미널에서 특정 trace를 검색하는 흐름이 가능해진다.

왜 개발팀에 중요한가

에이전트 도입의 첫 번째 난점은 “잘 작동하는가”가 아니다. 실제 팀에서는 누가 어떤 권한으로 어떤 파일을 바꿨고, 어떤 도구를 호출했고, 어떤 모델에 어떤 맥락이 들어갔으며, 실패했을 때 사람이 어디서 이어받을 수 있는지가 더 중요하다. Agent Runs는 이 질문에 답하기 위한 운영 표면에 가깝다.

Vercel 문서는 Agent Runs가 traces, status, duration, token usage, logs, reasoning steps, errors를 보여준다고 안내한다. 이 항목들은 AI 품질 평가용 장식이 아니다. 장애 분석, 비용 배분, 리뷰 우선순위, 민감 데이터 접근 감사에 필요한 최소 단서다. 예를 들어 “PR이 이상하게 바뀌었다”는 문제를 보면 diff만 볼 것이 아니라 어떤 prompt와 tool call, 어떤 model, 어떤 error recovery가 있었는지도 봐야 한다.

또 하나 중요한 점은 MCP와 CLI가 같은 기록을 보는 경로가 된다는 것이다. MCP는 다른 agent나 IDE가 구조화된 도구 호출로 접근하기 좋고, CLI는 사람이 터미널에서 검색하거나 스크립트에 붙이기 좋다. Agent observability가 사람 전용 대시보드에 갇히지 않으면, 팀의 내부 개발 플랫폼에 붙일 수 있는 재료가 된다.

커뮤니티 신호

커뮤니티에서는 “에이전트가 실제로 코드를 만질수록 사람의 review와 재현성이 더 중요하다”는 불안이 반복된다. Hacker News의 agentic coding 논의에서는 자동화가 편해질수록 reviewer가 무엇을 믿고 확인해야 하는지, 도구가 만든 변경을 어떻게 책임질지에 대한 댓글이 이어졌다.

또 다른 논의 축은 CLI와 MCP의 역할 분리다. 어떤 개발자는 CLI가 사람과 agent 모두에게 익숙한 Unix 표면이라는 점을 선호하고, 어떤 개발자는 MCP처럼 구조화된 protocol이 agent-to-tool 통합에 더 적합하다고 본다. 이 논쟁은 어느 쪽이 이겼다는 뜻이 아니라, 운영 도구가 둘 다 필요해지고 있다는 신호다.

따라서 이번 업데이트는 “Vercel이 또 하나의 agent 기능을 냈다”가 아니라 “agent run을 사람이 보는 dashboard, agent가 쓰는 MCP, 운영자가 쓰는 CLI 사이에서 같은 증거로 다룰 수 있게 됐다”는 변화로 읽는 편이 맞다.

개발·운영 영향

첫 번째 영향은 리뷰 방식이다. AI가 만든 PR은 diff만 보면 부족하다. 작업 지시, agent가 본 context, 사용한 tool, 실패 후 재시도, 토큰 사용량, 관련 deployment log를 함께 봐야 한다. Agent Runs가 CLI/MCP로 노출되면 PR 템플릿이나 리뷰 봇이 “관련 run summary”를 자동 첨부하는 흐름을 만들 수 있다.

두 번째 영향은 장애 대응이다. 에이전트가 배포 실패를 분석하거나 rollback 절차를 보조했다면, 그 세션은 운영 기록이다. 나중에 같은 장애가 재발했을 때 어떤 log를 봤고 어떤 가설을 세웠으며 어떤 명령을 제안했는지 찾을 수 있어야 한다. MCP의 trace search와 CLI의 --json 출력은 이런 기록을 incident timeline에 붙이는 데 유용하다.

세 번째 영향은 비용과 용량 관리다. Token usage가 run 단위로 보이면 “에이전트를 많이 썼다”가 아니라 어떤 작업 유형이 비싼지 볼 수 있다. 테스트 실패 분석, 문서 생성, 대규모 refactor, 로그 검색은 비용 구조가 다르다. 팀은 모델별 요금표만 볼 것이 아니라 run별 비용 신호를 운영 지표에 넣어야 한다.

네 번째 영향은 privacy disclosure다. Vercel 문서는 Agent Runs가 prompts, reasoning traces, token usage, tool calls, logs, outputs, errors, generated code, diffs, repository context, deployment identifiers, metadata를 캡처할 수 있다고 명시한다. 이는 편리함과 동시에 governance 요구다. 어떤 repository와 deployment에서 어떤 정보가 trace에 남는지 팀에 공개해야 한다.

지금 적용할 체크리스트

1. “agent run”을 리뷰 가능한 산출물로 정의한다. 중요한 PR, 배포, 장애 대응에는 관련 run URL 또는 summary를 남긴다.

2. MCP와 CLI 접근 권한을 나눈다. 사람의 터미널 조회, agent의 자동 조회, CI의 요약 생성은 필요한 권한과 audit 수준이 다르다.

3. --json 출력이 있는 CLI 명령은 내부 리포트나 incident bot에 붙인다. 사람이 보는 화면과 자동화가 읽는 데이터를 분리하지 않는다.

4. 토큰 사용량을 비용만이 아니라 작업 복잡도 신호로 본다. 비싼 run이 항상 나쁜 것은 아니지만, 이유 없이 반복되는 비싼 run은 운영 냄새다.

5. trace에 남을 수 있는 정보 목록을 팀에 공유한다. repository context, logs, generated diff, deployment identifier가 기록될 수 있음을 onboarding 문서에 넣는다.

6. agent가 만든 변경에는 “실행 기록 -> diff -> 테스트 -> 리뷰 결정” 순서의 링크를 남긴다. 나중에 재현할 수 없는 자동화는 운영 자동화가 아니다.

7. 작은 업무부터 시작한다. 실패한 deployment 요약, 오래 걸린 run 탐색, 특정 repo의 최근 agent run listing처럼 관측성 자체를 먼저 운영해 본다.

리스크와 반론

첫 번째 리스크는 관측성 과신이다. trace가 있다고 해서 agent가 옳았다는 뜻은 아니다. trace는 판단을 돕는 증거이지 승인 자체가 아니다. 리뷰어는 summary를 읽되 원본 diff, 테스트 결과, 배포 상태를 함께 봐야 한다.

두 번째 리스크는 데이터 노출이다. 관측성은 많은 것을 저장할수록 유용하지만, 그만큼 민감한 repository context와 log가 남을 가능성도 커진다. 특히 production log, customer identifier, secret-like string이 trace에 들어가지 않도록 log hygiene과 redaction 정책을 확인해야 한다.

세 번째 반론은 “작은 팀에는 과한 운영 아닌가”다. 작은 팀일수록 오히려 기억에 의존하기 쉽다. agent가 한 작업이 하루 뒤에도 설명 가능해야 한다면 최소한 run summary, 관련 PR, 테스트 결과 정도는 남겨야 한다. 모든 것을 platform화할 필요는 없지만 증거 링크는 가볍게 시작할 수 있다.

Agent Runs 운영 체크리스트

• 1. “agent run”을 리뷰 가능한 산출물로 정의한다. 중요한 PR, 배포, 장애 대응에는 관련 run URL 또는 summary를 남긴다.

정리

Agent Runs의 MCP/CLI 지원은 에이전트 기능 하나가 추가된 사건이 아니다. AI 개발 작업을 dashboard 안의 이벤트가 아니라 검색 가능하고, 요약 가능하고, 자동화에 붙일 수 있는 운영 기록으로 만드는 변화다. 앞으로 팀이 물어야 할 질문은 “에이전트가 코드를 잘 쓰는가”만이 아니다. “그 작업을 나중에 사람이 검토하고, 비용을 설명하고, 장애 상황에서 재현할 수 있는가”가 함께 와야 한다.

출처

다른 글