일반적인 웹 서비스에서 주문 API가 실패하면 상태 코드, 예외 메시지, 데이터베이스 로그를 따라가며 원인을 찾을 수 있습니다. 하지만 AI 에이전트가 “고객 요청을 확인하고 재고를 조회한 뒤 적절한 답변을 보내라”는 업무에서 실패하면 이야기가 달라집니다. 모델이 요청을 잘못 해석했을 수도 있고, 검색이 오래된 문서를 가져왔을 수도 있으며, 도구 인자가 틀렸거나 다른 에이전트로의 위임이 잘못됐을 수도 있습니다. 겉으로는 정상 응답을 반환했지만 실제 업무 시스템에는 아무 변화가 없을 수도 있습니다.
그래서 AI 에이전트 운영에서 관측성은 단순히 CPU와 응답시간을 보는 대시보드가 아닙니다. 한 요청이 어떤 판단과 도구 실행을 거쳐 실제 업무 결과에 도달했는지 재구성하고, 그 결과가 올바른지 평가하며, 실패 사례를 다음 배포의 회귀 테스트로 되돌리는 능력입니다. 이 글에서는 로그·메트릭·트레이스의 기본을 넘어 에이전트에 필요한 추적 단위, 버전 정보, 평가 방식, 개인정보 통제와 운영 폐쇄루프를 실무 관점에서 정리합니다.
에이전트 장애가 기존 장애보다 어려운 이유
전통적인 프로그램은 같은 코드와 입력, 같은 외부 상태라면 대체로 같은 경로를 실행합니다. 에이전트는 자연어 입력을 해석하고 매 순간 다음 행동을 선택합니다. 모델이나 프롬프트가 같아도 샘플링, 대화 맥락, 검색 결과, 도구 응답, 실행 시점의 데이터에 따라 경로가 달라질 수 있습니다. 실패를 재현하려면 입력 문자열만으로는 부족합니다.
더 큰 차이는 성공의 정의입니다. HTTP 200은 에이전트의 업무 성공을 뜻하지 않습니다. 답변은 자연스러워도 근거가 틀릴 수 있고, 도구 호출은 성공했지만 잘못된 고객의 데이터를 수정했을 수 있습니다. 반대로 중간 도구가 한 번 실패했어도 에이전트가 다른 경로로 복구해 최종 목표를 달성할 수 있습니다. 따라서 기술적 상태와 업무적 결과를 분리해 기록해야 합니다.
또한 에이전트는 하나의 서비스 안에 머물지 않습니다. 사용자 채널, 오케스트레이터, 모델 제공자, 벡터 검색, 사내 API, 승인 시스템, 다른 에이전트를 차례로 통과합니다. 각 시스템의 로그가 따로 존재하면 장애 시각을 맞추는 데만 시간이 걸립니다. 처음부터 하나의 추적 문맥을 전 구간에 전파해야 전체 실행을 한 화면에서 볼 수 있습니다.
로그는 사건을, 트레이스는 이야기를 보여준다
로그에는 “검색 완료”, “도구 호출 성공” 같은 개별 사건이 남습니다. 메트릭은 분당 요청 수, 오류율, 토큰, 지연시간의 추세를 보여줍니다. 트레이스는 이 사건들을 한 요청의 부모·자식 관계와 시간 순서로 연결합니다. 셋은 경쟁 관계가 아니라 서로 다른 질문에 답합니다.
- 메트릭: 지금 전체 시스템이 평소와 다른가?
- 트레이스: 이 요청은 어느 경로에서 느려지거나 잘못됐는가?
- 로그: 해당 단계에서 구체적으로 어떤 사건이 발생했는가?
- 평가 결과: 기술적으로 완료된 실행이 실제로 좋은 결과였는가?
OpenAI Agents SDK는 한 에이전트 실행 안의 모델 생성, 도구 호출, 핸드오프, 가드레일과 사용자 정의 이벤트를 트레이스로 수집합니다. Microsoft Foundry 역시 OpenTelemetry 기반으로 모델 호출, 도구 실행, 사용자 코드의 구간을 연결하고 OTLP 호환 백엔드로 보낼 수 있도록 설명합니다. 중요한 흐름은 특정 제품 하나가 아니라 에이전트 실행을 분산 추적의 구조로 다룬다는 점입니다.
한 번의 실행에서 무엇을 스팬으로 남길까
트레이스는 사용자 요청부터 최종 결과 검증까지의 한 실행을 나타냅니다. 그 안의 스팬(span)은 시작과 종료가 있는 작업 단위입니다. 모든 함수를 잘게 기록하면 데이터만 많아지고 의미가 사라지므로, 운영자가 원인을 구분할 수 있는 경계를 선택해야 합니다.
- 에이전트 실행: 업무 이름, 실행 ID, 사용자·테넌트의 비식별 키, 시작 채널, 위험 등급을 기록합니다.
- 모델 호출: 모델과 배포 버전, 프롬프트 버전, 입력·출력 토큰, 지연시간, 종료 이유를 남깁니다.
- 검색: 검색 질의의 안전한 표현, 인덱스와 임베딩 버전, 필터, 반환 문서 ID, 점수, 소요시간을 연결합니다.
- 도구 실행: 도구 이름과 스키마 버전, 허용된 인자의 요약, 결과 상태, 재시도 횟수, 멱등성 키를 기록합니다.
- 핸드오프: 어느 에이전트가 누구에게 어떤 목표와 제한을 넘겼는지 표시합니다.
- 정책과 승인: 적용된 정책 버전, 차단 또는 승인 결과, 승인 대기시간을 별도 스팬으로 둡니다.
- 업무 결과 검증: 주문 번호, 처리 상태, 생성된 산출물처럼 독립적으로 확인한 성공 증거를 기록합니다.
여기서 중요한 원칙은 모델의 최종 문장이 아니라 관찰 가능한 업무 결과가 루트 트레이스의 상태를 결정해야 한다는 것입니다. 에이전트가 “등록했습니다”라고 답해도 조회 API에서 대상 레코드가 확인되지 않으면 실행은 실패 또는 검증 불가로 분류해야 합니다.
추적 ID는 서비스 경계를 넘어야 한다
프런트엔드가 만든 요청 ID와 에이전트 프레임워크의 트레이스 ID, 사내 API의 상관관계 ID가 서로 다르면 전체 흐름이 끊깁니다. 진입점에서 생성한 추적 문맥을 HTTP 헤더, 메시지 큐 속성, 비동기 작업 메타데이터를 통해 전달해야 합니다. 다른 에이전트나 외부 작업자로 위임할 때도 부모 관계를 유지합니다.
한 대화가 여러 실행으로 이어지는 경우에는 실행 트레이스와 대화 스레드를 구분합니다. 트레이스는 한 번의 요청을, 스레드 ID는 여러 턴의 관계를 나타냅니다. 장기 업무는 별도의 업무 실행 ID로 묶어야 재시작과 사람 승인 이후에도 같은 비즈니스 건을 추적할 수 있습니다. 모든 것을 대화 ID 하나에 담으면 트레이스가 지나치게 커지고 장애 범위를 판단하기 어렵습니다.
OpenTelemetry의 생성형 AI 의미 규약은 에이전트, 대화, 모델 요청, 검색 문서 등의 공통 속성을 정리하는 방향으로 발전하고 있습니다. 다만 규약의 안정성 수준과 필드가 변할 수 있으므로, 운영 스키마에 그대로 결합하기보다 내부 표준 필드와 변환 계층을 두고 사용하는 의미 규약 버전을 함께 관리하는 편이 안전합니다.
재현에는 코드보다 더 많은 버전이 필요하다
배포 커밋만 기록해서는 지난주의 실패를 재현할 수 없습니다. 에이전트 행동은 코드 외에도 모델, 프롬프트, 도구 정의, 지식베이스와 정책에 의존합니다. 최소한 다음 버전을 한 실행에 묶어야 합니다.
- 애플리케이션과 오케스트레이션 코드의 배포 버전
- 모델 공급자, 모델 식별자, 추론 및 생성 설정
- 시스템 프롬프트와 템플릿, 예시의 버전
- 도구 이름, 입력 스키마, API와 커넥터 버전
- 검색 인덱스 스냅샷, 임베딩 모델, 청킹·필터 정책
- 가드레일, 권한, 승인과 라우팅 정책의 버전
- 기능 플래그와 실험군, 테넌트별 설정
모델 제공자가 같은 이름 아래 동작을 갱신하거나 외부 데이터가 바뀌는 경우까지 완벽히 고정하기는 어렵습니다. 그래서 재현은 비트 단위의 동일한 문장을 얻는 것보다, 당시 입력과 근거·도구 결과를 재생해 동일한 품질 및 안전 기준을 통과하는지 확인하는 방식이 현실적입니다.
대시보드는 네 가지 축으로 나눈다
에이전트 운영 지표를 평균 응답시간과 토큰 비용만으로 보면 빠르게 실패하는 시스템이 좋아 보일 수 있습니다. 최소 네 가지 축을 함께 봐야 합니다.
품질
업무 완료율, 근거 정확성, 답변 관련성, 필수 단계 준수율, 사람 평가 점수를 봅니다. 평균뿐 아니라 업무 종류, 고객군, 언어, 입력 길이별로 나눠야 취약 구간이 드러납니다.
신뢰성과 안전
도구 오류율, 재시도율, 반복 루프, 승인 우회 시도, 금지 도구 호출, 거짓 성공률, 사람 이관율을 측정합니다. 치명적 결과는 평균에 섞지 말고 별도의 0건 목표로 관리합니다.
성능
전체 지연시간과 함께 모델, 검색, 도구, 승인 대기시간을 분해합니다. 첫 응답 시간과 최종 업무 완료 시간도 구분해야 합니다. 비동기 에이전트에서는 사용자가 기다린 시간과 백그라운드 처리 시간이 다릅니다.
비용
입력·출력 토큰, 검색과 도구 호출 비용, 실행 인프라, 실패 재처리와 사람 검토 시간을 업무 성공 건수로 나눕니다. 요청당 비용보다 검증된 성공 건당 비용이 의사결정에 더 유용합니다.
평가는 최종 답변과 실행 경로를 모두 본다
최종 답변 평가만으로는 우연히 맞은 결과와 안전하게 도달한 결과를 구분하기 어렵습니다. 반대로 정해진 도구 순서를 강제하면 더 나은 경로를 찾는 에이전트의 장점을 잃습니다. 따라서 결과 평가와 경로 평가를 나눕니다.
결과 평가는 사용자의 목표가 달성됐는지, 사실과 근거가 맞는지, 실제 시스템 상태가 원하는 값인지 확인합니다. 경로 평가는 승인 없이 위험 행동을 하지 않았는지, 허용된 도구만 사용했는지, 불필요한 반복이 없었는지, 근거 문서를 왜곡하지 않았는지 봅니다. 경로는 하나의 정답 시퀀스가 아니라 반드시 지켜야 할 불변 조건으로 평가하는 것이 좋습니다.
평가 방식도 하나로 통일하지 않습니다. 구조화된 결과와 업무 상태는 코드 기반 검사로, 표현 품질은 모델 기반 평가로, 중요한 위험과 애매한 사례는 사람이 확인합니다. 자동 평가 모델도 틀릴 수 있으므로 정기적으로 사람 판정과 일치율을 확인하고 평가 프롬프트와 기준 자체를 버전 관리해야 합니다.
실패 원인을 분류해야 개선 담당자가 보인다
모든 실패를 “환각”으로 부르면 아무것도 고칠 수 없습니다. 트레이스의 실패를 적어도 다음처럼 분류해야 합니다.
- 요청 이해: 의도·대상·제약을 잘못 해석함
- 검색: 적절한 문서를 찾지 못했거나 오래된 버전을 사용함
- 모델 판단: 충분한 근거가 있는데도 잘못 추론함
- 도구 선택: 잘못된 도구 또는 불필요한 도구를 호출함
- 도구 실행: 인자·권한·외부 API·재시도 문제로 실패함
- 정책: 허용해야 할 행동을 차단하거나 위험 행동을 허용함
- 오케스트레이션: 핸드오프, 상태 전달, 종료 판단이 잘못됨
- 검증: 실제 결과를 확인하지 않고 성공으로 판정함
분류가 있어야 검색팀은 인덱스를, 플랫폼팀은 도구와 재시도를, AI팀은 프롬프트와 모델을, 업무팀은 성공 기준을 각각 개선할 수 있습니다. 한 실행에 여러 원인이 있을 수 있으므로 최초 원인과 증폭 요인을 구분해 태깅하는 것도 유용합니다.
운영 트레이스를 평가 데이터셋으로 되돌리는 폐쇄루프
좋은 관측성은 장애 보고서에서 끝나지 않습니다. 운영 트레이스 중 오류와 낮은 평가 점수, 과도한 비용, 사람 이관 사례를 선별합니다. 개인정보를 제거하고 원인을 분류한 뒤, 기대 결과와 금지 행동을 붙여 버전 관리되는 평가 데이터셋에 추가합니다. 수정된 모델·프롬프트·검색·도구 후보는 기존 핵심 사례와 새 실패 사례 전체에서 회귀 테스트를 거칩니다.
LangSmith 문서는 트레이스가 모델 상호작용, 도구 호출과 의사결정 단계를 기록하고, 운영 데이터를 평가와 개선에 연결하는 구조를 설명합니다. 제품을 무엇으로 선택하든 이 폐쇄루프가 핵심입니다. “문제를 고쳤다”는 개발자의 판단 대신 같은 사례에서 품질·안전·비용 지표가 실제로 개선됐는지 비교해야 합니다.
모든 운영 요청을 평가셋으로 저장하면 개인정보와 비용 문제가 생깁니다. 오류와 고위험 업무는 높은 비율로, 일반 성공 요청은 대표 표본으로 샘플링합니다. 드문 언어, 신규 고객군, 새 도구, 긴 대화처럼 위험이 큰 구간은 별도 층화 표본을 둡니다. 평가셋에는 원문 전체보다 재현에 필요한 최소 데이터와 참조 키를 저장합니다.
트레이스 자체가 새로운 민감정보 저장소가 된다
에이전트 트레이스에는 사용자 입력과 모델 출력뿐 아니라 검색 문서, 도구 인자, API 응답, 승인 내용이 들어갈 수 있습니다. 일반 애플리케이션 로그보다 훨씬 풍부하고 위험한 데이터입니다. Microsoft의 에이전트 추적 가이드도 프롬프트·도구 인자·스팬 속성에서 비밀정보와 개인정보를 제거하고, 트레이스를 운영 데이터와 같은 수준의 접근 제어와 보존 정책으로 다룰 것을 강조합니다.
기본값은 원문 미수집 또는 선택적 수집이어야 합니다. 토큰과 지연시간, 상태, 버전, 문서 ID처럼 분석에 필요한 메타데이터는 남기되, 메시지 본문은 민감도와 환경에 따라 마스킹하거나 별도 저장합니다. 비밀번호, API 키, 인증 토큰은 수집 전에 차단해야 하며 사후 삭제에 의존해서는 안 됩니다.
개발·검증·운영 환경의 수집 정책을 분리하고, 고객 또는 테넌트별 데이터 경계를 유지합니다. 원문 열람 권한은 운영 대시보드 권한과 별도로 관리하며, 열람 자체도 감사 로그로 남깁니다. 보존 기간과 샘플링 비율을 정하면 비용뿐 아니라 노출 범위도 줄어듭니다.
샘플링 때문에 중요한 실패를 놓치지 않으려면
트레이스는 모델 입출력과 검색 결과까지 담으면 빠르게 커집니다. 모든 실행을 장기간 같은 상세도로 보관하는 것은 비싸고 위험합니다. 그렇다고 시작 시점에 무작위로 일부만 남기면 드문 실패를 놓칩니다.
실무에서는 기본 메타데이터는 넓게 수집하고, 상세 내용은 조건에 따라 보존합니다. 오류, 정책 차단, 사람 이관, 높은 비용, 긴 지연, 낮은 평가 점수, 신규 버전과 고위험 업무는 우선 보존합니다. 성공 요청은 소량의 대표 표본을 유지해 정상 기준선을 만듭니다. 실행이 끝난 뒤 상태를 보고 상세 보존 여부를 정하는 꼬리 기반 샘플링도 유용합니다.
다만 처음부터 수집하지 않은 민감 원문을 나중에 복원할 수는 없습니다. 어떤 필드를 생성 시점에 마스킹하고 어떤 필드를 임시 버퍼에 두었다가 보존할지는 법적 요구와 장애 분석 필요성을 함께 고려해야 합니다.
알람은 기술 오류보다 사용자 영향에 연결한다
도구 호출 오류 하나마다 알람을 보내면 복구 가능한 일시 오류 때문에 운영자가 지칩니다. 반대로 최종 응답이 반환됐다는 이유로 알람을 끄면 거짓 성공을 놓칩니다. 알람은 실패율뿐 아니라 검증된 업무 완료율, 승인 대기 누적, 사람 이관 급증, 단위 성공당 비용, 특정 버전의 품질 하락에 연결해야 합니다.
배포 후에는 전체 평균보다 이전 버전과 후보 버전을 같은 업무군에서 비교합니다. 신규 버전의 치명적 오류가 한 건이라도 발생하거나 품질 하한을 넘지 못하면 자동 중단합니다. 평균 품질이 좋아도 특정 고객군이나 언어에서 악화될 수 있으므로 세그먼트별 보호 기준을 둡니다.
30일 구축 로드맵
- 1주차 — 성공 정의와 ID 체계: 대표 업무 2~3개의 검증 가능한 성공 조건을 정하고 요청·트레이스·대화·업무 실행 ID의 관계를 설계합니다.
- 2주차 — 핵심 스팬과 버전: 모델, 검색, 도구, 승인, 결과 검증을 계측하고 코드·프롬프트·인덱스·정책 버전을 연결합니다. 기존 관측 플랫폼으로 OTLP 전송 경로를 만듭니다.
- 3주차 — 평가와 개인정보: 코드·모델·사람 평가를 조합하고 실패 분류 체계를 적용합니다. 원문 수집, 마스킹, 접근 권한, 보존과 샘플링 정책을 검증합니다.
- 4주차 — 폐쇄루프와 배포 게이트: 운영 실패를 평가셋에 추가하고 후보 버전의 회귀 테스트, 카나리아 배포, 자동 중단 기준을 연결합니다.
처음부터 모든 필드를 수집하기보다 “이 트레이스로 실제 장애 하나를 설명할 수 있는가?”를 기준으로 확장하는 편이 좋습니다. 관측 데이터가 있어도 원인을 판단할 수 없다면 스팬 경계나 버전 정보가 부족한 것이고, 판단에 쓰이지 않는 원문이 많다면 수집 범위를 줄여야 합니다.
Nature Fractal이 보는 에이전트 운영의 핵심
AI 에이전트 프로젝트는 데모 단계에서 모델의 답변 품질에 집중하기 쉽습니다. 실제 서비스에서는 모델 밖의 검색, API, 데이터베이스, 승인, 재시도와 업무 검증이 전체 신뢰성을 결정합니다. 따라서 관측성도 AI 전용 대시보드를 하나 더 만드는 일이 아니라 기존 서비스 추적과 에이전트 실행을 이어 붙이는 시스템 통합 과제입니다.
Nature Fractal은 에이전트가 회사 시스템을 사용할 때 요청부터 실제 결과까지 하나의 흐름으로 설계하고, 권한과 개인정보 경계를 유지하며, 운영 실패가 자동으로 품질 개선 자료가 되도록 만드는 접근을 중요하게 봅니다. 모델을 교체해도 남는 것은 좋은 프롬프트 한 줄이 아니라 재현 가능한 추적, 측정 가능한 성공 기준, 축적되는 평가 데이터셋입니다.
도입 전 체크리스트
- 에이전트의 성공을 실제 업무 상태로 확인할 수 있는가?
- 요청·대화·트레이스·업무 실행 ID가 명확히 구분되는가?
- 모델·검색·도구·승인·핸드오프·검증 단계가 연결되는가?
- 코드뿐 아니라 프롬프트·인덱스·도구·정책 버전이 남는가?
- 품질·안전·성능·비용을 함께 측정하는가?
- 최종 결과와 금지 행동을 각각 평가하는가?
- 실패를 검색·모델·도구·정책·오케스트레이션 문제로 분류하는가?
- 운영 실패가 평가 데이터셋과 회귀 테스트에 추가되는가?
- 비밀정보와 개인정보가 트레이스에 들어가기 전에 제거되는가?
- 고위험·실패 실행을 놓치지 않는 샘플링 정책이 있는가?
- 신규 버전을 제한 배포하고 자동 중단할 기준이 있는가?
AI 에이전트의 실패를 완전히 없앨 수는 없습니다. 대신 어떤 조건에서 실패했는지 설명하고, 실제 영향을 확인하며, 같은 유형이 다시 나타나지 않도록 평가에 반영할 수는 있습니다. 관측성은 장애를 바라보는 창을 넘어 에이전트가 운영 데이터로 계속 좋아지게 만드는 기반입니다.
