AI agent가 엉뚱한 답을 내도 서버 기록에는 아무 문제가 없어 보이는 경우가 많습니다. 장난감 쇼핑몰 예제 agent에 “$6 미만 장난감을 보여 달라”고 하자 agent는 맞는 상품이 없다고 답했지만, 요청은 모두 정상 처리된 것으로 기록됐습니다. 원인은 검색 도구에 가격 필터가 아예 없다는 데 있었습니다. 이 원인을 짚어 내고 코드를 고친 것은 사람이 아니라 실행 기록을 읽을 수 있게 된 Claude Code였습니다. AI 관측 플랫폼 기업 Arize AI가 보여 준 이 과정을 따라가며, agent를 운영하는 팀이 무엇을 기록하고 어떤 순서로 개선 루프를 돌리면 되는지 정리합니다.
코드만 봐서는 agent를 알 수 없는 이유
전통적인 소프트웨어에서는 소스 코드가 기준이었습니다. 실행 경로를 미리 분석하고 예측할 수 있기 때문입니다. AI agent는 다릅니다. 같은 입력을 주어도 실행할 때마다 다른 추론 경로를 따르고, 다른 도구를 부르고, 다른 결과를 낼 수 있습니다. 코드나 prompt를 아무리 들여다봐도 실제로 어떤 판단을 거쳤는지는 드러나지 않습니다.
그래서 agent의 동작을 이해하는 기준은 trace(실행 기록)가 됩니다. trace는 agent가 한 번 일하는 동안의 모든 단계를 계층 구조로 남긴 기록입니다. 대화의 각 차례, 도구 호출, prompt 내용, 모델의 응답, token 사용량, 지연 시간, 비용이 span(trace를 이루는 작업 단위)으로 쌓입니다. trace 없이 agent를 만드는 것은 커밋 기록만 보면서 실제 사용자와의 상호작용은 전혀 모르는 채 운영하는 것과 같다는 설명입니다.
문제는 양입니다. 초당 수천 건의 요청을 받는 서비스라면 trace가 수백만 건씩 쌓이고, 사람이 하나씩 열어 보는 방식은 초당 몇 건만 넘어도 무너집니다. 2025년에 널리 쓰인 해법은 LLM-as-a-judge, 곧 언어 모델이 정해진 기준에 따라 trace를 채점하게 하는 eval(평가)이었습니다. 평가 모델은 점수나 통과·실패 같은 판정과 함께 왜 실패했는지 자연어로 설명을 붙입니다.
그런데 2026년에는 이 평가 결과마저 사람이 다 읽을 수 없는 양이 됐다는 진단입니다. agent는 몇 분 만에 코드를 만들고 작업을 끝내는데, 사람은 대시보드에서 문제를 찾는 데 며칠이 걸립니다. 그래서 관측의 주체가 대시보드를 보는 사람에서 trace와 평가 결과를 직접 읽는 agent로 넘어가고 있다고 봅니다.
예제 agent에 관측을 붙이는 과정
예제는 장난감을 추천하는 대화형 쇼핑몰입니다. OpenAI Agents SDK로 만든 앱이고, 처음에는 trace가 하나도 남지 않습니다. “7세 아이에게 맞는 장난감”을 물으면 450조각짜리 로봇 조립 장난감 같은 상품을 잘 추천하지만, 그 과정은 아무도 볼 수 없습니다.
관측을 붙이는 작업은 VS Code의 Claude Code 확장에 맡겼습니다. 요청은 “이 앱에 Arize AX로 observability(관측 가능성)를 추가해 달라, 비밀값은 환경 설정 파일에 있다”는 한 문장이었습니다. Claude Code는 프로젝트 구조를 살피고 의존성을 설치한 뒤 Arize로 기록을 보내는 설정을 더했습니다.
이 작업이 간단했던 까닭은 OpenAI Agents SDK가 이미 OpenInference로 계측돼 있기 때문입니다. OpenInference는 AI 앱의 동작을 기록하는 특정 업체에 묶이지 않는 공개 표준입니다. 남은 일은 기록을 받을 주소와 인증 정보를 설정하는 것뿐이어서, agent의 핵심 코드는 고치지 않고도 trace가 쌓이기 시작했습니다. 다만 Claude Code가 기능과 상관없는 README까지 고치는 등 불필요한 변경을 시도하기도 했으므로, 변경 내용은 확인하는 편이 좋습니다.
▲ 정상 응답 뒤의 빈 검색 결과
200 OK 뒤에 숨은 실패
trace가 쌓인 뒤 가격 조건이 붙은 질문을 넣자 문제가 드러났습니다. “$6 미만 장난감을 모두 보여 달라”는 요청에 agent는 맞는 상품을 찾지 못했다고 답했습니다. 앱이 멈추거나 오류 코드를 내지는 않았습니다.
이어 Claude Code에게 “trace를 가져와 잘못되고 있는 것을 찾아 달라”고 요청했습니다. 이때 쓰인 것이 skill입니다. skill은 coding agent에 특정 작업 방법과 도구 사용법을 알려 주는 묶음으로, 저장소 루트의 지정된 폴더에 두면 agent가 불러 씁니다. 일반 coding agent는 관측 플랫폼에서 trace를 꺼내 오는 능력이 없지만, trace 조회 skill을 받은 Claude Code는 Arize의 명령줄 도구로 span을 가져와 상태, 입력 인자, 출력을 스스로 분석했습니다.
진단 결과는 구체적이었습니다.
| 발견한 현상 | 뜻 |
|---|---|
| 최근 검색 요청의 42%가 결과 0건 | 검색 도구가 자주 빈손으로 돌아옴 |
| 상품 검색 도구 실행 시간 1밀리초 | 맞지 않는 필터 때문에 바로 빈 목록을 반환 |
| 모든 검색 인자가 비어 있는 호출 | 인기 상품만 기본으로 내놓음 |
| 최소 나이와 최대 나이가 같은 조건 | 범위가 너무 좁아 결과가 없음 |
| 모델은 가격 조건을 넘겼지만 도구는 무시 | 검색 도구에 가격 필터가 없음 |
눈여겨볼 점은 HTTP 요청 대부분이 200 OK, 곧 정상 응답으로 기록됐다는 것입니다. 품질이 떨어지는 실패는 예외나 오류 코드가 아니라 조용한 빈 결과로 나타나는 일이 많고, 일반적인 HTTP 모니터링으로는 잡히지 않습니다. 도구가 정상 응답과 함께 빈 배열을 돌려주는 경우를 따로 살펴야 하는 이유입니다.
coding agent가 고치고 검증하기까지
“가격 필터를 추가하자”는 요청을 받은 Claude Code는 검색 도구의 입력 형식과 실행 함수에 가격 조건을 더하는 방법을 찾았습니다. 그런데 저장소 옆 폴더에 완성본 코드가 있다는 것을 발견하고, 그 구현을 그대로 가져와 적용했습니다. 결과는 맞게 동작했지만, 저장소 전체를 볼 수 있는 agent는 정답 폴더나 테스트에 있는 코드를 그대로 빌려 올 수 있다는 점을 보여 준 사례입니다. 참고용 완성본을 둔 저장소에서 agent를 돌릴 때는 이 점을 감안해야 합니다.
수정 뒤 “$9 미만 장난감”을 묻자 $7.99, $8.99 같은 상품이 나왔고, trace에는 입력부터 검색 도구 호출, 예산 조건, 최종 응답까지 모두 기록됐습니다. 이 과정을 단계로 정리하면 다음과 같습니다.
- 관측이 없는 상태에서 trace 기록을 붙입니다.
- 실패할 만한 요청을 넣어 문제를 드러냅니다.
- trace 조회 skill을 가진 coding agent가 실패 양상을 분석합니다.
- agent가 원인을 고치는 코드를 씁니다.
- 같은 유형의 요청으로 수정이 통했는지 trace로 확인합니다.
사람이 trace를 열지 않아도 되는 단계
Arize는 이 루프에서 사람이 조사를 시키는 단계까지 없애려 합니다. Arize AX 안에서 도는 agent인 Signal은 기본적으로 6시간마다 쌓인 trace를 훑어 되풀이되는 실패를 묶고, 원인을 분류하고, 고칠 방법을 제안합니다. 실행 주기는 바꿀 수 있습니다.
Signal이 찾아낸 문제의 예는 다음과 같습니다.
- prompt injection(사용자 입력으로 agent의 지시를 덮어쓰는 공격)에 넘어가 쇼핑 상담원 역할 대신 사용자의 지시를 따름
- 사용자의 모호한 표현에서 나이 조건을 지어냄
- 폭탄 제조법을 묻는 위험한 질문을 거절하지 않고 폭탄 관련 장난감을 추천하고 심리 조언까지 덧붙임
마지막 사례는 장난감 쇼핑몰 챗봇이 맡은 영역을 벗어난 것으로, 허용할 수 없는 실패로 분류됐습니다. 범위를 벗어난 위험한 질문은 도움이 되려고 애쓰기보다 아예 받지 않도록 guardrail(안전 장치)을 두는 편이 낫다는 판단입니다. 금융 상담 agent 사례에서는 해로운 금융 조언에 동조하거나 근거 없는 금융 정보를 지어내는 패턴, 바뀐 지시에서 잘못된 도구를 고르는 패턴이 묶였습니다.
문제마다 GitHub 이슈 만들기, 평가용 데이터셋에 추가하기, 평가 기준 만들기, 코드 수정 PR 열기 가운데 하나를 고를 수 있습니다. Arize의 제품 내 agent인 Alex에게 “폭탄 제조법을 절대 알려 주지 않는지 확인하는 평가를 만들어 달라”고 자연어로 요청하면 평가 규칙을 바로 만들어 줍니다.
운영 조건도 함께 알아 둘 만합니다.
- Signal의 코드 수정은 현재 Claude Code가 맡으며, 앞으로는 사용자가 원하는 coding agent와 모델을 고를 수 있게 할 계획입니다.
- 실행 비용은 지금은 Arize가 부담하지만 앞으로도 무료라고 장담하지는 않습니다.
- Signal이 평가 기준을 스스로 만들어 돌리지는 않습니다. 평가 모델을 계속 돌리는 데 시간과 비용이 많이 들어 사람이 승인해야 합니다.
- trace를 기기 안에만 두는 방식은 지원하지 않지만, 고객사 장비 안에서 모두 돌아가는 구축형 배포는 가능합니다.
- 실패를 묶는 방식은 데이터 양에 따라 달라집니다. 시험용 trace 십여 건이면 건별로, 운영 환경의 수천 건이면 큰 묶음으로 분류합니다.
▲ 관측에서 자동 수정까지의 순환
자동 수정을 믿기 전에 필요한 것
금융·의료처럼 규제가 엄격한 분야에서 agent가 스스로 코드를 고치는 루프를 어떻게 안전하게 쓸 수 있느냐는 질문에는, 검증 장치를 여러 층으로 쌓아 코드 변경을 감독하는 것이 답이라고 설명합니다. 무제한 자율에 맡기는 것이 아니라 단계별 검증이 필요하다는 뜻입니다. Arize는 이미 금융 분야 고객사가 이런 관측과 자동 수정 방식을 쓰고 있다고 밝혔습니다.
가장 강조된 조건은 회귀 평가입니다. prompt를 조금 바꾸거나 자동 PR을 병합할 때 기존 기능이 망가지지 않는지 확인하는 평가 묶음이 있어야 하고, 자동으로 만든 PR도 사람이 검토하고 회귀 평가를 통과한 뒤에 병합해야 합니다. agent가 요청하는 명령을 확인 없이 모두 승인하는 습관도 보안 측면에서 피해야 합니다.
정리: agent 개선 루프를 시작하는 순서
agent의 품질 문제는 코드가 아니라 trace에서 보입니다. 관측을 붙이고, 실패를 묶어 읽고, 고친 뒤 검증하는 루프를 갖추면 사람이 모든 기록을 읽지 않아도 agent를 꾸준히 고칠 수 있습니다.
- 쓰는 agent 프레임워크가 OpenInference 같은 표준 계측을 지원하는지 먼저 확인합니다. 지원하면 직접 기록 코드를 짜지 않아도 됩니다.
- 정상 응답과 함께 빈 결과를 돌려주는 도구 호출을 따로 찾아봅니다. 일반 모니터링이 놓치는 실패입니다.
- coding agent에 trace 조회 skill을 주고 실패 양상을 분석하게 합니다.
- 실패는 한 건씩 보지 말고 되풀이되는 패턴으로 묶어 우선순위를 정합니다.
- 평가 기준은 판정과 함께 실패 이유를 설명하도록 만들어, 그 설명을 다시 개선에 씁니다.
- 자동 수정은 회귀 평가와 사람의 검토를 거친 뒤에만 병합합니다.