AI 에이전트는 한 번 성공했다고 믿으면 안 된다: 로그, 평가, 피드백 루프로 운영하는 법

1. 개요: 한 번 성공은 운영 신뢰가 아니다

AI 에이전트 데모는 최종 결과물이 깔끔하기 때문에 설득력 있어 보입니다. 에이전트가 검색하고, 초안을 만들고, 도구를 호출하고, 자신감 있는 답으로 끝납니다. 하지만 운영 품질은 첫인상과 다릅니다.

Anthropic은 에이전트가 여러 턴에 걸쳐 도구를 호출하고, 환경 상태를 바꾸고, 중간 결과에 맞춰 적응하기 때문에 평가가 더 어렵다고 설명합니다. 최종 답변은 맞아 보이지만, 실제로는 잘못된 출처를 쓰거나, 불필요한 도구 호출을 반복하거나, 정책 확인을 건너뛰거나, 그럴싸하게 다른 문제를 풀었을 수 있습니다.

OpenAI의 tracing 문서도 같은 운영 포인트를 인프라 관점에서 말합니다. 에이전트 실행에는 모델 생성, 도구 호출, 핸드오프, 가드레일, 사용자 정의 이벤트까지 기록되는 전체 기록이 필요합니다. 실무 언어로 말하면 회사에는 영수증이 필요합니다.

2. 쉬운 용어 정리: 로그, 트레이스, eval, gold set

로그는 영수증입니다. 무엇이 일어났는지 남깁니다. 입력, 출력, 도구 호출, 승인, 오류, 변경 기록이 로그입니다. 로그가 없으면 팀은 기억에 의존해서 논쟁하게 됩니다.

트레이스는 동선 지도입니다. 로그 하나가 영수증이라면, 트레이스는 한 작업이 처음부터 끝까지 어떤 길을 지나갔는지 보여줍니다. 먼저 티켓을 읽고, 정책을 검색하고, 답변을 초안화하고, 승인 요청을 보냈다는 식의 전체 흐름입니다. OpenTelemetry는 trace를 여러 서비스 사이를 지나가는 요청의 경로로 설명하는데, AI 에이전트에서는 모델 호출, 도구, 사람 체크포인트를 지나는 경로로 이해하면 됩니다.

Eval은 AI 시스템을 위한 시험입니다. "느낌상 좋아졌다"가 아니라, 고정된 과제를 주고 성공했는지 채점합니다. Anthropic은 eval을 이렇게 설명하면서, 에이전트 평가는 최종 문장만이 아니라 과제, 환경, 결과, transcript까지 봐야 한다고 말합니다.

Gold set은 기준 문제집입니다. 팀이 중요하게 보는 실제 예시 묶음입니다. 까다로운 환불 요청, 애매한 고객 질문, CRM 예외 업데이트, 위험한 도구 호출, 과거 실패 사례를 모아둡니다. 에이전트가 gold set에서 나빠졌다면 변경을 배포하면 안 됩니다.

• Observability: 로그, 트레이스, 지표, 대시보드로 시스템 안에서 무슨 일이 일어나는지 볼 수 있는 능력.
• Metric: 성공률, 사람 수정률, 도구 호출 횟수, 지연시간, 비용, 롤백률, 정책 위반률처럼 추적하는 숫자.
• LLM-as-a-judge: 다른 AI 모델로 AI 결과물을 채점하는 방식. 유용하지만 보정이 필요하고 유일한 판단 기준이 되면 위험합니다.
• Rollback: 이전 프롬프트, SOP, 도구 권한, 모델, 기록 상태로 되돌릴 수 있는 능력.

3. 로그와 트레이스: 답만 보지 말고 과정을 보여줘야 한다

위험한 에이전트 오류는 최종 답변만 보면 잘 보이지 않습니다. 에이전트가 예의 바른 답을 하면서도 오래된 SOP를 읽었을 수 있고, 같은 도구를 다섯 번 호출했을 수 있고, 읽으면 안 되는 개인 메모를 봤을 수 있고, 반드시 거쳐야 하는 승인 단계를 건너뛰었을 수 있습니다.

그래서 좋은 트레이스에는 입력, 검색한 출처, 도구 호출, 변경된 기록, 승인, 오류, 재시도, 비용, 지연시간, 최종 결과가 보여야 합니다. 이것은 엔지니어만 보는 자료가 아닙니다. 비전문가 운영자도 간단한 타임라인처럼 읽을 수 있어야 합니다. AI가 무엇을 봤고, 무엇을 했고, 어디서 사람이 개입했는지를 보는 것입니다.

다만 OpenAI 문서가 말하듯 trace에는 민감한 데이터가 포함될 수 있습니다. 그래서 기록은 "모든 것을 영원히 저장하자"가 아닙니다. 로그 자체에도 마스킹, 보존 기간, 접근 권한이 필요합니다.

• 최소 로그: 사용자 요청, 워크플로우 이름, 에이전트 버전, 사용한 출처, 도구 호출, 변경 필드, 사람 승인, 최종 출력, 오류 상태, 시각.
• 최소 트레이스: 각 단계의 순서, 그 단계를 한 이유, 도구 입력과 출력 요약, 자동 처리인지 사람 승인인지 여부.
• 최소 개인정보 규칙: 비밀키, 원본 인증정보, 개인 메모, 불필요한 개인정보를 trace 안에 저장하지 않습니다.

4. 평가: 불만을 반복 가능한 시험으로 바꾼다

사용자가 "에이전트가 이상해졌다"고 말했을 때 가장 나쁜 대응은 추측입니다. 더 좋은 대응은 그 실패를 시험 문제로 바꾸는 것입니다. 어떤 입력에서 문제가 생겼는가. 원래 무엇을 했어야 하는가. 어떤 출처를 써야 했는가. 어떤 행동은 피했어야 하는가.

Anthropic은 eval이 없는 팀이 반응형 루프에 빠진다고 설명합니다. 하나의 실패를 고치다가 다른 실패를 만들고, 진짜 회귀인지 노이즈인지 구분하지 못합니다. 작은 팀에도 적용되는 조언이 있습니다. 거대한 벤치마크부터 만들지 말고, 실제 실패에서 뽑은 간단한 과제 20개에서 50개로 시작하라는 것입니다.

Guildex식 운영에서는 평가가 최종 답변과 과정 모두를 봐야 합니다. 과제가 해결됐는가. 올바른 정책을 썼는가. 위험한 도구 호출을 피했는가. 승인 요청을 했는가. 사람이 결과를 다시 써야 했는가.

• 결과 평가: 워크플로우가 올바른 비즈니스 결과를 냈는가.
• 과정 평가: 에이전트가 올바른 출처, 도구, 순서, 승인 게이트를 사용했는가.
• 비용 평가: 토큰, 도구 호출, 검토자 시간을 너무 많이 쓰지 않았는가.
• 안전 평가: 민감정보, 금지 행동, 과도한 실행 권한을 피했는가.

5. Gold set과 점수표: 품질을 눈에 보이게 만든다

Gold set은 처음부터 클 필요가 없습니다. 대표성이 중요합니다. 쉬운 사례 10개와 어려운 사례 10개가 막연한 예시 100개보다 낫습니다. 중요한 것은 사례를 고정해서 변경 전후를 비교할 수 있게 하는 것입니다.

점수표는 사업 담당자가 읽을 수 있을 만큼 단순해야 합니다. 좋은 에이전트 점수표는 과제 성공률, 출처 정확도, 정책 준수, 사람 수정률, 승인 정확도, 롤백률, 완료 과제당 비용, 고객 노출 위험을 추적합니다.

이렇게 하면 AI 개선이 운영 대화가 됩니다. "새 프롬프트가 더 좋아 보인다"가 아니라, 성공률은 올랐지만 도구 호출이 두 배가 됐고 사람 수정률은 줄지 않았다고 말할 수 있습니다. 그러면 아직 검토 부채가 남아 있다는 뜻입니다.

• Gold set 입력: 실제 과거 업무, 익명화된 고객 요청, 알려진 예외 상황, 실패한 실행, 승인 민감도가 높은 사례.
• 점수표 출력: 통과/실패, 실패 이유, 사람 수정 메모, 사용 출처, 도구 호출, 비용, 지연시간, 롤백 결정.
• 검토 주기: 매주 샘플을 읽고, 큰 변경 전 gold set을 다시 돌리고, 매달 새 실패를 추가합니다.

6. LLM-as-a-judge: 유용하지만 판단을 대체하지는 못한다

LLM-as-a-judge는 열린 형식의 결과물을 대량으로 채점할 수 있어서 유용합니다. 답변이 지시를 따랐는지, 요약에서 핵심을 빠뜨렸는지, 톤이 규칙을 어겼는지 확인하는 데 도움을 줍니다.

하지만 한계가 있습니다. MT-Bench와 Chatbot Arena 논문은 LLM judge에 위치 편향, 장황함 선호, 자기 모델 선호, 제한된 추론 능력 문제가 있을 수 있다고 설명합니다. 그래서 모델 judge가 모두가 따르는 보이지 않는 관리자가 되면 안 됩니다.

더 안전한 방식은 혼합 평가입니다. 가능한 것은 규칙 기반으로 확인하고, 애매한 기준은 LLM judge를 쓰고, 주기적으로 사람 기준과 맞춰봅니다. 쉽게 말하면 AI가 채점을 도와도 되지만, 기준표와 최종 확대 판단은 사람이 소유해야 합니다.

• 좋은 사용: 두 초안 비교, 누락된 정책 항목 감지, 톤 확인, 실패 유형 분류, 사람 수정 내역 요약.
• 나쁜 사용: 결제 승인, 법적 준수 인증, 사람 검토 우회, 보정 없는 고위험 행동 채점.
• 보정 규칙: 주기적으로 모델 judge와 사람 리뷰어의 판단을 비교하고, 불일치가 나오면 기준표를 고칩니다.

7. 피드백 루프: 수정은 시스템 변경으로 돌아가야 한다

피드백 루프는 에이전트가 운이나 기억에 기대지 않고 개선되는 방식입니다. 운영자가 실행을 검토하고, 실패에 라벨을 붙이고, SOP나 프롬프트를 수정하고, gold set을 다시 돌린 뒤 변경을 배포합니다.

x-inbox-router 신호도 같은 방향을 가리킵니다. SkillOpt는 에이전트 skill을 훈련 가능한 외부 절차로 봅니다. Vibe training은 운영 에이전트가 도메인 특화 실패를 잡는 평가자를 필요로 한다고 말합니다. OpenHarness는 권한, hook, memory, task, observability를 모델 주변 인프라로 제시합니다. 이것들은 공식 증거가 아니라 소셜 신호지만, 패턴은 일관됩니다. 가치는 모델 자체보다 모델 주변의 운영 루프에서 나옵니다.

핵심은 제한된 개선입니다. 에이전트가 자기 규칙을 마음대로 다시 쓰게 하면 안 됩니다. 사람 수정은 작은 이름 있는 변경으로 SOP, 프롬프트, skill, 도구 권한에 반영되어야 하고, 그 변경은 다시 평가되어야 합니다.

• 실행 발생: 에이전트가 과제를 완료하거나 실패합니다.
• 트레이스 검토: 팀이 출처, 도구 호출, 승인, 오류, 출력을 봅니다.
• 실패 라벨링: 출처 오류, 정책 누락, 도구 오용, 톤 드리프트, 비용 급증, 승인 누락으로 나눕니다.
• 시스템 수정: SOP, 프롬프트, skill, 권한, 기준표, gold set을 고칩니다.
• 평가 재실행: 수정이 실제로 좋아졌는지, 기존 사례를 망가뜨리지 않았는지 확인합니다.

8. 피해야 할 실패 패턴

첫 번째 실패는 최종 출력만 평가하는 것입니다. 최종 답변만 보면 낭비된 도구 호출, 위험한 검색, 숨어 있는 정책 드리프트, 검토 부채를 놓칩니다.

두 번째 실패는 대시보드 흉내입니다. 차트가 많은 대시보드는 누군가 샘플을 읽고, 실패를 분류하고, 시스템을 고치지 않으면 의미가 없습니다.

세 번째 실패는 경계 없는 자기개선입니다. 자동 개선은 매력적으로 들리지만, 에이전트가 gold set과 롤백 경로 없이 자기 지시문을 바꾸면 회사는 언제 품질이 흔들렸는지 알 수 없습니다.

• 성공한 데모 하나를 안정적 품질의 증거로 보지 않습니다.
• 문제가 터졌을 때만 eval을 돌리지 않습니다.
• 고위험 업무에서 같은 모델이 작업자, 채점자, 승인자, 규칙 작성자를 모두 맡게 하지 않습니다.
• 아무도 읽지 않는 로그를 모으지 않습니다.
• 보존 기간과 접근 규칙 없이 민감한 trace 데이터를 저장하지 않습니다.

9. Guildex 체크리스트: 에이전트를 진짜 워크플로우처럼 운영한다

AI 에이전트가 회사 운영에 들어가기 전, Guildex는 일곱 가지 산출물을 요구합니다. 워크플로우 책임자, 권한표, 로그 형식, 트레이스 화면, gold set, 점수표, 롤백 규칙입니다.

책임자는 누가 결과를 소유하는지 말합니다. 권한표는 에이전트가 무엇을 읽고, 쓰고, 실행할 수 있는지 말합니다. 로그와 트레이스는 무슨 일이 있었는지 말합니다. Gold set과 점수표는 품질이 좋아졌는지 말합니다. 롤백 규칙은 에이전트가 나빠졌을 때 회사가 어떻게 물러날지 말합니다.

이것이 "AI가 한 번 도와줬다"와 "AI가 믿을 수 있는 운영 자산이 됐다"의 차이입니다. 회사는 첫날부터 완벽한 자동화를 만들 필요가 없습니다. 실수를 보이게 만들고, 수정이 더 나은 업무로 돌아가게 하는 루프가 필요합니다.