HTTP 200인데 AI는 실패한다: AI 에이전트 트레이싱과 관측 가능성

 

AI 에이전트가 “요청을 처리했습니다”라고 답했다. 서버는 HTTP 200을 반환했고 예외 로그도 없다. 그런데 실제 주문 상태는 바뀌지 않았거나, 다른 상품의 규정을 적용했거나, 완료되지 않은 일을 끝났다고 보고했다면 어떨까. 통신은 정상이어도 사용자가 맡긴 업무는 실패할 수 있다. AI 에이전트 운영에서 관측 가능성과 트레이싱이 필요한 이유가 여기에 있다.

 

프롬프트를 고치거나 더 큰 모델로 바꾸기 전에 알아야 할 것은 실패가 발생한 위치다. 필요한 자료를 못 찾았는지, 올바른 자료를 읽고도 조건을 잘못 해석했는지, 도구 호출은 성공했지만 업무 결과를 확인하지 않았는지에 따라 해결책은 달라진다. 최종 답변 하나와 전체 응답 시간만 저장하면 이 차이를 구분하기 어렵다.

 

이 글은 AI 에이전트 트레이싱, 관측 가능성, OpenTelemetry, 스팬, 토큰 비용, 민감 정보 처리의 관계를 한국 기술 블로그 형식으로 정리한다. OpenTelemetry와 OpenAI Agents SDK 공식 문서, AWS 한국어 기술 블로그, 국내 개발자의 관측 도구 적용 글을 비교했다. 자료 확인 기준일은 2026년 10월 24일이며, 아래의 환불 에이전트와 시간 계산은 이해를 돕기 위한 가상 사례다.

 

중요한 전제도 있다. 트레이스는 실제로 수집한 실행 이벤트를 연결하는 기록이다. 모델 내부의 모든 생각이나 판단 원인을 완벽하게 읽는 장치가 아니다. 기록의 범위와 누락 가능성을 이해해야 유용한 증거로 사용할 수 있다. 관측 도구를 설치했다는 사실만으로 시스템이 설명 가능해지거나 답변의 정확성이 보장되지는 않는다.

정상 응답과 업무 성공을 먼저 분리하자

HTTP 상태 코드는 해당 통신이나 API 처리의 상태를 알려 준다. 에이전트가 반환한 JSON의 문법이 맞는지, 사용자의 목적을 달성했는지까지 자동으로 판정하지는 않는다. 잘못된 주문 번호로 조회해도 조회 API는 정상적으로 응답할 수 있다. 모델이 그 응답을 바탕으로 잘못된 설명을 생성해도 웹 서버는 200을 반환할 수 있다.

 

따라서 운영에서는 기술적 오류와 업무 결과를 별도로 정의하는 편이 좋다. 기술적 오류에는 연결 실패, 시간 초과, 도구 예외 같은 사건이 들어간다. 업무 결과에는 실제 처리 완료, 조건 불충족, 추가 정보 필요, 사용자가 취소함, 확인되지 않음 같은 상태가 들어갈 수 있다. 구체적인 상태 이름은 서비스에 맞게 정하되 서로 다른 의미를 한 칸에 합치지 않는 것이 중요하다.

 

예를 들어 환불 불가 조건을 정확히 확인하고 이유를 설명한 실행은 사용자의 원하는 결과를 주지 못했어도 시스템의 올바른 동작일 수 있다. 반대로 환불 가능하다고 자신 있게 답했지만 실제 처리를 하지 않았다면 문장이 친절해도 업무 성공이 아니다. 성공 지표는 긍정적인 답변의 비율이 아니라 요청의 범위와 처리 결과를 기준으로 설계해야 한다.

 

도구 실행 상태와 외부 시스템의 상태도 나누어 보자. 요청을 보냈다는 사실, 서버가 요청을 받았다는 사실, 비동기 작업이 완료되었다는 사실은 서로 다르다. 조회로 확인할 수 있는 업무라면 최종 상태를 확인하는 단계가 필요할 수 있다. 완료 확인을 수행하지 않았다면 관측 기록에도 미확인 상태가 남아야 한다.

이 구분은 대시보드에도 영향을 준다. 서버 오류율이 낮다고 업무 품질이 높다고 결론 내리면 잘못된 성공 보고를 놓친다. 기술 오류율과 별도로 검증된 완료율, 확인 질문 비율, 정책상 거절, 사람에게 이관된 비율 등을 업무 목적에 맞게 살펴보자. 단, 거절이나 이관이 늘었다는 이유만으로 나쁜 변화라고 단정할 수는 없다.

로그와 지표 그리고 트레이스는 서로 다른 질문에 답한다

로그는 특정 시점에 무슨 일이 있었는지 설명하는 데 유용하다. 지표는 시간에 따른 요청 수, 지연 분포, 오류율처럼 집계된 상태를 보여 준다. 트레이스는 하나의 요청이 여러 작업을 거쳐 어떤 경로로 처리되었는지 연결한다. 세 가지를 경쟁 관계로 볼 필요는 없다. 같은 장애를 서로 다른 해상도로 보는 수단이다.

 

OpenTelemetry 공식 문서는 트레이스를 애플리케이션에서 요청이 지나가는 경로로 설명한다. 트레이스를 구성하는 기본 단위는 스팬이다. 스팬에는 작업 이름, 시작과 종료 시각, 식별자, 속성, 이벤트, 상태와 관계 정보 등을 담을 수 있다. 루트 스팬과 하위 스팬을 연결하면 전체 요청과 세부 작업의 관계가 드러난다.

 

환불 에이전트라면 하나의 요청 아래에 의도 확인, 주문 조회, 정책 검색, 판단을 위한 모델 호출, 처리 도구 호출, 결과 검증을 둘 수 있다. 모든 서비스가 같은 프로세스에 있을 필요는 없다. 관련 식별 정보가 전달되어야 다른 서버나 작업자가 만든 기록을 하나의 실행과 연결할 수 있다. 이것이 분산 추적에서 문맥 전파가 중요한 이유다.

 

여기서 문맥은 언어모델이 읽는 프롬프트 문맥과 구별해야 한다. 추적 문맥은 어떤 실행에 속하는지 연결하기 위한 식별 정보와 관계를 포함한다. 이를 전달한다고 주문 내용이나 대화 원문을 모든 서비스에 복사해야 하는 것은 아니다. 추적 연결과 업무 데이터 전달을 분리하면 불필요한 데이터 확산도 줄일 수 있다.

 

또한 대화 전체와 요청 하나가 반드시 같은 트레이스일 필요는 없다. 긴 대화를 하나의 거대한 기록으로 묶기보다 요청별 실행을 나누고 안전한 그룹 식별자로 연결하는 설계도 가능하다. 실제 구분은 시스템에 맞게 정해야 한다. 대화 식별자와 업무 식별자, 재시도 식별자를 같은 값으로 재사용하면 관계가 모호해질 수 있다.

실행 기록은 모델의 머릿속을 그대로 보여 주지 않는다

트레이싱 도구가 모델 호출과 도구 선택을 보여 준다고 해서 내부 추론을 그대로 읽는 것은 아니다. 일반적으로 확인하는 것은 관측된 입력과 출력, 호출 순서, 도구 인자, 실행 결과, 제공된 메타데이터다. 모델이 출력한 설명이나 요약이 있더라도 그것이 내부 판단 과정을 빠짐없이 반영한다고 가정해서는 안 된다.

 

가령 에이전트가 “최신 정책을 확인했다”고 말했지만 트레이스에는 오래된 문서 조회만 있다면 두 기록이 불일치한다는 사실을 알 수 있다. 그러나 이 자료만으로 모델의 내부에서 어떤 연산 때문에 잘못된 문장이 나왔는지 모두 설명할 수는 없다. 실행 기록은 행동과 결과를 검토할 증거이며 완전한 심리 해설이 아니다.

 

트레이스가 보여 주지 않는 것에도 주목해야 한다. 외부 도구 내부에서 일어난 세부 작업을 계측하지 않았다면 호출 하나로만 보일 수 있다. 데이터베이스 조회와 외부 API 호출이 같은 스팬에 묶이면 어디서 지연이 생겼는지 구분되지 않는다. 기록이 없다는 사실은 그 행동이 없었다는 확정 증거가 되지 않을 수 있다.

반대로 기록이 있다는 사실도 해당 내용이 사실이라는 보장은 아니다. 모델이 출력한 잘못된 주장은 기록에 그대로 남을 수 있다. 도구가 반환한 오래된 정보도 성공 응답으로 보일 수 있다. 계측은 어떤 데이터를 주고받았는지 드러내지만 데이터의 진실성과 업무 적합성은 별도의 확인이 필요하다.

 

감사 기록과 운영 트레이스의 목적도 구별하자. 트레이스는 성능과 오류 진단을 위해 샘플링하거나 짧게 보존할 수 있다. 책임 추적에 필요한 기록은 완전성, 접근 통제, 무결성, 보존 정책 같은 별도 요구가 있을 수 있다. 관측 대시보드가 있다는 이유만으로 모든 감사 요구를 충족했다고 판단하면 안 된다.

스팬 경계는 모델 호출보다 업무의 경계에서 시작한다

에이전트 프레임워크가 자동으로 남기는 모델 호출 스팬은 출발점으로 유용하다. OpenAI Agents SDK 문서는 모델 생성, 함수 도구 호출, 가드레일, 핸드오프와 사용자 정의 이벤트 등을 추적 대상으로 설명한다. 다만 실제 포함 항목과 기본값은 사용하는 SDK와 버전에 맞춰 확인해야 한다. 설치만 하면 모든 업무 단계가 자동으로 보인다고 기대해서는 안 된다.

 

업무 담당자가 궁금한 것은 “모델을 몇 번 불렀나”보다 “어떤 주문에 어떤 정책을 적용했고 결과를 검증했나”일 수 있다. 이를 알려면 주문 조회와 정책 검색, 실행과 검증 같은 단계를 의미 있는 경계로 묶어야 한다. 모든 문장 생성이나 모든 내부 함수를 별도 스팬으로 만들면 오히려 중요한 흐름을 찾기 어려울 수 있다.

 

스팬의 이름은 작업 종류를 드러내는 안정적인 표현이 좋다. 요청마다 사용자의 전체 질문을 스팬 이름으로 넣으면 검색과 집계가 어려워지고 민감 정보가 퍼질 수 있다. 작업 종류는 이름으로, 필요한 버전과 결과 분류는 제한된 속성으로, 상세 근거는 접근 통제된 참조로 나누는 방식이 가능하다. 구체적인 필드는 팀에서 관리해야 한다.

 

승인 대기가 있는 업무에서는 대기 시간과 실제 실행 시간을 구별하자. 사람의 승인을 기다린 10분을 모델 계산이 느렸던 시간으로 해석하면 최적화 대상이 잘못된다. 대기 시작과 재개 같은 사건을 시간 정보와 함께 남기거나 별도 작업으로 구분할 수 있다. 사용자가 체감한 전체 시간도 유지하되 어디서 기다렸는지 설명할 수 있어야 한다.

 

비동기 작업은 단순한 부모와 자식 트리만으로 표현하기 어려운 경우도 있다. OpenTelemetry는 스팬 링크로 관련된 작업을 연결하는 개념을 설명한다. 요청이 큐에 작업을 넣고 나중에 별도 실행이 이어질 때 관계를 보존할 수 있다. 같은 트레이스 아래에 억지로 모두 끼워 넣는 것보다 실제 실행 관계에 맞는 연결 방식을 선택해야 한다.

지연을 찾을 때 스팬 시간을 전부 더하면 틀린다

트레이스의 각 스팬에는 소요 시간이 있지만 이를 모두 더한 값이 사용자 지연은 아니다. 부모 스팬의 시간 안에 자식 스팬이 포함되어 있고, 여러 자식 작업이 동시에 실행될 수도 있기 때문이다. 계층 구조와 병렬 구간을 무시하면 같은 시간을 중복 계산하거나 실제 병목을 잘못 찾게 된다.

 

가상의 실행을 보자. 사전 처리에 2초가 걸리고 주문 조회 4초와 정책 검색 6초를 동시에 수행한 뒤 마지막 검증에 2초가 걸렸다고 하자. 대기와 추가 오버헤드가 없다는 가정에서 전체 시간은 약 10초다. 두 병렬 작업의 시간을 단순히 더하면 14초가 된다. 전체 루트 시간까지 더하면 중복은 더 커진다.

이때 주문 조회를 4초에서 2초로 줄여도 정책 검색 6초가 그대로라면 전체 시간은 거의 줄지 않을 수 있다. 사용자가 기다리는 경로를 결정하는 작업이 어디인지 살펴봐야 한다. 반대로 지연이 짧은 작업이라도 자원 사용량이나 비용 측면에서는 개선 가치가 있을 수 있다. 지연 최적화와 자원 효율 최적화는 다른 질문이다.

 

스트리밍 응답에서는 첫 반응과 최종 완료도 구분해야 한다. 사용자가 첫 토큰을 본 시간은 짧아도 실제 외부 작업이 끝나기까지 오래 걸릴 수 있다. “처리 중입니다”라는 문장을 빨리 보여 주는 것과 업무를 빨리 끝내는 것은 다르다. 서비스에 맞게 첫 응답, 최종 답변, 실제 처리 완료의 기준을 정해야 한다.

 

평균 지연만 보는 것도 부족하다. 대부분은 빠르지만 일부 요청에서 도구 재시도나 속도 제한 때문에 오래 걸릴 수 있다. 지연 분포와 느린 실행의 경로를 함께 보자. 다만 서로 다른 기간이나 집단에서 계산한 백분위 값을 단순히 평균 내는 방식은 조심해야 한다. 집계 기준과 표본을 맞춰 비교해야 의미가 있다.

토큰 합계와 실제 청구 비용도 같은 숫자가 아니다

에이전트 요청 하나는 여러 모델 호출을 포함할 수 있다. 입력과 출력 토큰, 캐시된 입력, 도구 사용과 검색, 외부 서비스, 자체 호스팅 자원 등 비용 요소가 나뉜다. 토큰 수를 기록하는 일은 중요하지만 토큰 합계에 하나의 단가를 곱하는 것만으로 모든 청구 비용을 정확히 재현할 수는 없다.

 

모델별 요금과 호출 시점, 입력과 출력 구분, 캐시 가격, 배치나 계약 조건에 따라 계산이 달라질 수 있다. 사용량이 제공되지 않는 호출은 0이 아니라 미확인으로 구분하는 편이 좋다. 단가표의 버전과 통화를 함께 기록하면 나중에 비용 추정이 달라진 이유를 설명하기 쉽다. 대시보드의 추정치와 실제 청구 내역은 별도로 맞춰 봐야 한다.

 

AWS의 Phoenix 적용 글은 모델별 토큰 단가를 설정해 비용을 계산하는 흐름을 설명한다. 또한 시연의 가시성을 위해 특정 모델 단가를 높게 설정했다고 명시한다. 이런 데모 화면의 숫자를 실제 서비스 요금이나 운영 비용으로 그대로 인용하면 안 된다. 도구가 계산한 값이 어떤 설정에 기반했는지를 확인해야 한다는 좋은 사례다.

 

토큰 중복 집계도 주의하자. 하위 모델 호출의 사용량을 합산한 값이 상위 에이전트 스팬에 이미 들어 있다면, 부모와 자식의 수치를 다시 모두 더하면 같은 사용량을 두 번 셀 수 있다. 어떤 계층의 값이 원본이고 어떤 값이 파생 집계인지 정해야 한다. 계측 라이브러리가 둘 이상이면 같은 호출을 중복으로 기록할 가능성도 살펴봐야 한다.

 

운영 의사결정에는 요청당 비용 외에 검증된 성공당 비용도 도움이 된다. 싸게 여러 번 실패하는 시스템이 한 번에 성공하는 시스템보다 경제적이라고 단정할 수는 없다. 사람의 수정과 이관, 재시도까지 포함할 범위를 정하고 비교하자. 다만 사람의 시간이 포함된 추정과 모델 API 비용을 같은 종류의 확정 청구액처럼 표시하지 않는 것이 좋다.

검색과 도구 실행은 중간 결과까지 연결해서 봐야 한다

RAG를 사용하는 에이전트가 틀렸을 때 모델 호출만 보면 원인을 놓친다. 검색 질문, 필터, 후보의 식별자와 순서, 실제 전달된 근거의 버전을 연결해 두면 어떤 자료가 사용되었는지 확인하기 쉽다. 모든 원문을 무조건 저장할 필요는 없다. 추후 확인할 수 있는 안전한 참조와 버전 정보로 충분한 경우도 있다.

원하는 문서가 검색 후보에 없었다면 검색과 데이터 준비 단계의 문제일 수 있다. 후보에는 있었는데 최종 문맥에서 빠졌다면 선택과 문맥 구성의 문제를 살펴볼 수 있다. 근거를 받았는데 예외를 잘못 설명했다면 생성과 검증 단계로 범위를 좁힌다. 이런 구분은 트레이스에 필요한 중간 정보가 있을 때 가능하다.

 

도구 호출에서는 도구 이름만으로 충분하지 않을 수 있다. 어떤 유형의 요청인지, 호출이 읽기인지 변경인지, 인자가 검증되었는지, 응답이 무엇을 의미하는지 연결해야 한다. 다만 고객 이름과 결제 정보 같은 인자를 그대로 관측 서버에 보내는 방식은 피해야 한다. 업무 진단에 필요한 구조와 민감한 실제 값의 보존 여부는 따로 설계할 수 있다.

 

재시도도 각 호출을 독립된 무작위 사건처럼 남기지 말고 같은 시도의 관계로 연결하자. 호출이 시간 초과되었다는 사실은 외부 작업이 실행되지 않았다는 확정 증거가 아니다. 최종 상태 조회와 실제 변경 이력의 참조를 남기면 중복 실행 여부를 조사하는 데 도움이 된다. 트레이싱이 중복 방지 자체를 구현하는 것은 아니라는 점도 구분해야 한다.

 

완료 응답과 실제 검증 결과가 다르면 이를 별도 결과로 다루는 편이 좋다. 모델이 성공이라고 쓴 문장만 집계하면 잘못된 완료 보고가 통계상 성공으로 남는다. 검증 가능한 작업에서는 확인 도구의 결과나 시스템의 최종 상태를 근거로 삼고, 확인하지 못한 경우는 미확인으로 남겨야 한다. 보이지 않는 결과를 관측 도구가 대신 알아내지는 못한다.

버전 정보가 없으면 같은 실패를 다시 설명하기 어렵다

오늘 잘 동작하던 요청이 다음 주에 실패했을 때 질문만 같다고 같은 조건은 아니다. 시스템 지침과 프롬프트 템플릿, 모델 설정, 도구 정의, 검색 인덱스와 정책 문서가 바뀌었을 수 있다. 실행 당시 어떤 조합을 사용했는지 알 수 있어야 변경과 실패의 관계를 조사할 수 있다.

 

프롬프트는 원문 전체 대신 관리 가능한 버전 식별자와 안전한 참조를 둘 수 있다. 모델은 요청한 이름과 제공되는 경우 실제 응답 모델 식별 정보를 구분해 기록하는 방법을 검토할 수 있다. 단, 모델 이름만으로 제공자 내부의 모든 변경을 통제하거나 완벽하게 재현할 수 있다는 뜻은 아니다. 기록 가능한 것과 통제 가능한 것을 나누어야 한다.

 

도구 설명과 입력 스키마도 동작에 영향을 준다. API 구현은 그대로여도 설명문이 바뀌면 모델이 선택하는 도구가 달라질 수 있다. 에이전트 스킬이나 참고 지침을 사용한다면 활성화된 버전도 진단 단서가 된다. 기록해야 할 것은 모든 파일의 복사본이 아니라 실행 결과에 영향을 준 구성의 식별 가능한 관계다.

 

검색 문서가 갱신되는 서비스에서는 문서 식별자만 남겨도 내용이 달라질 수 있다. 버전이나 추출 시점, 인덱스 갱신 상태를 함께 관리해야 당시 근거를 확인하기 쉽다. 해시가 내용 변화 확인에 도움을 줄 수 있어도 원문 복구를 보장하지는 않는다. 추적 정보와 실제 자료의 보존 정책을 연결해야 한다.

 

재현에는 외부 상태의 한계도 있다. 재고와 가격, 주문 상태가 이미 바뀌었다면 같은 호출을 다시 실행하는 것만으로 과거 상황을 재현할 수 없다. 변경 작업을 그대로 재실행하면 부작용도 생길 수 있다. 읽기 전용 조사, 고정된 테스트 입력, 모의 도구 응답 등 목적에 맞는 재현 방식을 선택해야 한다.

관측 데이터를 모으는 순간 새로운 데이터 관리가 시작된다

프롬프트와 도구 입력 및 출력에는 사용자 질문, 내부 문서, 개인정보, 인증 정보가 섞일 수 있다. 관측 도구는 이를 잘 모으기 때문에 유용하면서도 별도의 보호가 필요하다. 애플리케이션의 데이터 접근 통제가 잘되어 있어도 관측 서버와 대시보드의 권한이 넓으면 새로운 노출 경로가 될 수 있다.

 

OpenAI Agents SDK 공식 문서는 생성 스팬과 함수 스팬이 입력과 출력을 저장할 수 있고 민감 데이터 포함 설정을 조정할 수 있다고 설명한다. 확인한 문서는 해당 설정의 기본값을 True로 안내한다. 다른 SDK까지 같은 기본값이라고 일반화하지 말고 실제 사용하는 버전의 설정과 기본 전송 대상을 확인해야 한다. 계측을 활성화하기 전에 확인할 항목이다.

 

보통은 필요한 항목을 허용 목록으로 정하는 접근을 고려할 수 있다. 작업 종류, 결과 분류, 시간, 사용량, 구성 버전처럼 진단에 필요한 값부터 수집하고, 원문은 필요성과 권한이 확인된 범위에서 다룬다. 오류 메시지와 URL, 사용자 정의 메타데이터에도 민감 정보가 들어갈 수 있으므로 입력 필드만 마스킹했다고 끝나는 것은 아니다.

 

특히 처리기를 하나 더 붙이면 기존 전송 경로가 자동으로 사라질 것이라고 가정하면 안 된다. OpenAI Agents SDK 문서는 추가 처리기를 등록해도 기본 전송기가 남을 수 있고, 마스킹 처리기에서 예외가 나도 다른 처리기가 계속 호출될 수 있다고 설명한다. 마스킹 실패 시 전송을 막아야 한다면 마스킹과 전달의 경계를 함께 설계해야 한다.

 

이 원칙을 적용할 때는 원본을 복사해 필요한 값만 남기고, 변환에 실패하면 원문을 예외 로그에 다시 출력하지 않도록 해야 한다. 실제 구현은 SDK와 전송 대상에 맞춰 검증해야 한다. 이 글은 특정 코드 몇 줄로 모든 데이터가 보호된다고 주장하지 않는다. 저장 이전뿐 아니라 외부 전송 이전에 어떤 값이 나가는지 확인하는 것이 중요하다.

 

접근 통제, 보존 기간과 삭제도 함께 정하자. 운영자가 성능 문제를 조사하는 데 고객의 전체 대화 원문이 항상 필요한 것은 아니다. 반대로 제한된 권한으로 원문을 확인해야 하는 조사도 있을 수 있다. 진단용 메타데이터와 민감한 상세 자료를 분리하고, 외부 서비스에 저장한다면 실제 계약과 저장 범위를 확인해야 한다. 자체 호스팅도 권한과 백업 관리의 책임을 없애 주지는 않는다.

샘플링과 비동기 전송은 누락까지 측정해야 완성된다

모든 실행의 상세 내용을 영구 저장하면 데이터량과 비용이 커질 수 있다. 그래서 일부 실행만 남기는 샘플링을 검토하게 된다. 이때 드문 실패를 놓칠 수 있다는 점을 고려해야 한다. 정상 실행 일부와 느린 실행, 특정 오류나 중요한 업무를 어떻게 관측할지 목적을 먼저 정하는 편이 좋다.

 

시작 시점에 선택하는 방식과 실행 결과를 본 뒤 선택하는 방식은 필요한 정보와 운영 부담이 다르다. 결과를 본 뒤 남기면 실패와 느린 요청을 고를 수 있지만 중간 데이터를 보관하고 연결하는 부담이 생길 수 있다. 어떤 기능이 가능한지는 수집기와 SDK, 백엔드에 따라 확인해야 한다. 이름만으로 같은 동작을 기대하지 말자.

 

선택된 트레이스만으로 전체 실패율을 계산하는 것도 조심해야 한다. 오류가 있는 실행을 더 자주 보존했다면 그 표본의 오류 비율은 전체 서비스의 비율과 다르다. 대시보드에 보이는 실행의 모집단과 샘플링 조건을 표시해야 한다. 전체 지표와 상세 진단 표본을 함께 사용하되 서로의 의미를 혼동하지 않는 것이 좋다.

비동기 전송도 공짜는 아니다. 메인 요청이 전송 완료를 직접 기다리지 않더라도 직렬화와 큐, 메모리와 네트워크를 사용한다. 큐가 가득 찼을 때 버릴지 대기할지, 전송 실패를 어떻게 처리할지에 따라 서비스 영향이 달라진다. 계측 도입 전후의 지연과 자원 사용량을 확인해야 한다.

 

OpenAI Agents SDK는 기본 배치 처리기가 백그라운드로 내보내며 종료 시 처리도 수행한다고 설명한다. 다만 작업이 끝난 즉시 대시보드에 나타나지는 않을 수 있다. 문서에 소개된 강제 내보내기는 버퍼 전송을 기다리는 동작이므로 호출 위치와 지연 영향을 고려해야 한다. 갑작스러운 프로세스 종료나 수집 장애에서 기록이 어떻게 되는지도 별도로 확인해야 한다.

 

따라서 관측 시스템 자체의 상태도 운영 대상이다. 애플리케이션에서 만든 스팬 수와 실제 수집된 양의 차이, 전송 오류, 큐 포화, 지연된 수집을 살펴볼 수 있다. 기록이 없어서 문제가 없다고 결론 내리는 상황을 피해야 한다. 관측 신호를 수집하는 경로가 정상인지 확인하지 않으면 대시보드의 빈칸을 잘못 해석하기 쉽다.

대시보드에서 끝내지 말고 평가와 개선으로 연결하자

트레이스는 실패를 찾는 데 도움을 주고 평가는 결과가 요구를 만족하는지 판단한다. 둘은 연결되지만 같은 기능은 아니다. 실행 경로가 완전히 기록되어도 답변의 사실성이나 정책 적용의 적합성을 판단하려면 기준이 필요하다. 반대로 평가에서 실패로 판정되어도 실행 단서가 없으면 원인을 좁히기 어렵다.

 

국내 개발 블로그의 LangSmith와 Langfuse 적용 글은 잘못된 코드 답변을 검색 단계와 모델 입력 단계로 나누어 보는 흐름을 설명한다. AWS의 Phoenix 글도 검색 결과, 모델 호출, 도구와 지연 및 토큰을 연결하는 사례를 보여 준다. 도구별 화면이 달라도 공통 목적은 실패한 결과를 고칠 수 있는 단계로 되돌리는 데 있다.

 

운영에서 찾은 사례를 그대로 대량 복사하기보다 민감 정보를 제거하고 대표적인 평가 문제로 재구성하자. 기대하는 근거와 결과, 확인 질문 또는 이관해야 하는 조건을 정하면 다음 변경의 퇴행을 검사할 수 있다. 운영 데이터와 평가 데이터는 목적과 접근 권한이 다를 수 있으므로 옮기는 과정도 관리해야 한다.

 

모델을 이용한 자동 평가는 검토량을 줄이는 데 유용할 수 있지만 절대 판정으로 취급하지 않는 편이 좋다. 평가 모델이 같은 잘못된 전제를 받아들이거나 근거 없는 설명을 높게 볼 수 있다. 금액이나 상태처럼 기계적으로 확인할 수 있는 항목은 실제 기준과 대조하고, 중요한 판단은 사람 검토와 함께 보정해야 한다.

 

개선은 실패 유형과 연결하자. 검색 누락이면 인덱스와 질의를, 잘못된 도구 선택이면 설명과 선택 조건을, 처리 후 확인 누락이면 검증 단계를 살펴본다. 프롬프트만 계속 늘리는 방식은 원인과 수정의 관계를 흐릴 수 있다. 같은 평가 조건에서 품질과 지연, 비용이 어떻게 바뀌었는지 함께 확인해야 한다.

운영 도입은 질문 하나를 끝까지 추적하는 데서 시작한다

처음부터 모든 프레임워크와 서비스를 한꺼번에 계측하기보다 대표 업무 하나를 끝까지 연결하는 편이 좋다. 사용자 요청에서 모델과 검색, 도구, 최종 확인까지 이어지는지 살펴보자. 중간 작업이 별도 트레이스로 끊기거나 어떤 스팬이 중복되는지 이 단계에서 찾을 수 있다.

그다음 팀이 실제로 답해야 할 질문을 정한다. 왜 이 요청이 느렸는지, 왜 잘못된 근거를 썼는지, 실제 변경이 완료되었는지, 비용이 어느 호출에서 늘었는지처럼 구체적이어야 한다. 수집 항목을 이 질문과 연결하면 필요 없는 원문 저장과 지나치게 상세한 계측을 줄일 수 있다.

 

공통 결과 분류와 버전 기준을 정하고, 일부러 실패와 지연 및 거절 사례를 만들어 수집이 제대로 되는지 확인한다. 민감 정보가 들어간 가짜 시험 문자열을 사용해 마스킹과 접근 권한도 점검할 수 있다. 실제 비밀을 시험 데이터로 쓰지 않는 것이 중요하다. 외부 전송 경로와 기존 전송기 설정도 함께 확인하자.

 

마지막으로 수정한 뒤 같은 조건에서 다시 본다. 관측 도구를 설치했다는 작업 완료보다, 이전에 설명하지 못했던 실패를 이제 설명하고 줄일 수 있는지가 도입 효과에 가깝다. 도구의 기능 목록과 우리 서비스에서 실제 확인한 범위를 구분하면 운영팀의 기대도 현실적으로 맞출 수 있다.

자주 묻는 질문

Q. HTTP 200과 오류 없는 트레이스면 에이전트가 성공한 것 아닌가요?

아니다. 통신과 기록된 작업이 오류 없이 끝났어도 잘못된 근거나 조건을 사용했을 수 있다. 사용자의 요청 범위에 맞는 업무 완료 기준과 실제 결과 확인이 필요하다. 기술적 상태와 업무 결과를 별도로 기록하는 편이 좋다.

Q. 트레이싱을 켜면 모델의 모든 생각을 볼 수 있나요?

그렇지 않다. 확인하는 것은 계측한 호출과 입출력, 관계와 시간 같은 실행 데이터다. 모델이 출력한 설명이 있더라도 내부 추론을 완전하게 반영한다고 보장할 수 없다. 관측된 행동의 증거와 내부 원인의 설명을 구분해야 한다.

Q. 스팬의 소요 시간을 더하면 전체 지연을 알 수 있나요?

부모와 자식의 시간이 겹치거나 병렬 실행이 있으면 중복 계산된다. 전체 요청 시간과 작업 간 관계, 실제 대기 경로를 함께 봐야 한다. 승인 대기와 모델 계산 시간도 따로 구분해야 올바른 개선 대상을 찾을 수 있다.

Q. 프롬프트와 응답 원문은 전부 저장해야 하나요?

반드시 그렇지는 않다. 업무 진단에 필요한 메타데이터와 버전, 안전한 참조부터 정하고 원문은 목적과 권한에 따라 제한할 수 있다. 실제 SDK의 민감 정보 포함 기본값과 전송 대상, 마스킹 실패 시 동작을 확인해야 한다.

Q. 비동기 수집이면 서비스 성능에 영향이 없나요?

비동기 방식도 직렬화와 큐, 메모리와 네트워크 자원을 사용한다. 전송이 느리거나 큐가 가득 찰 때의 정책에 따라 영향이 달라질 수 있다. 계측 도입 전후의 지연과 자원 사용량 및 기록 누락을 함께 확인해야 한다.

Q. 관측 도구만 도입하면 자동으로 품질이 좋아지나요?

도구는 실행을 이해할 자료를 제공한다. 실제 개선에는 실패 분류와 평가 기준, 수정과 재검증이 필요하다. 어떤 단계의 문제가 줄었는지 확인해야 하며, 대시보드의 데이터량이 늘었다는 사실만으로 품질 향상을 판단할 수는 없다.

좋은 관측 가능성은 더 많이 저장하는 능력이 아니다

AI 에이전트의 관측 가능성은 사용자 요청과 모델, 검색, 도구, 실제 결과를 연결해 설명할 수 있는 능력에 가깝다. 정상 응답과 업무 성공을 구분하고, 지연과 비용의 집계 의미를 맞추며, 기록되지 않은 부분의 한계를 이해해야 한다. 트레이스는 그 연결을 위한 실행 증거를 제공한다.

그 증거를 모으는 과정에도 데이터 보호와 운영 비용이 따른다. 필요한 정보는 남기고 불필요한 원문은 줄이며, 수집 경로의 누락을 확인하고, 실패 사례를 평가와 수정으로 연결해야 한다. HTTP 200 뒤에 숨은 실패를 찾는 힘은 기록의 양보다 기록의 의미와 검증 가능한 관계에서 나온다.

출처와 추가로 읽을 자료

OpenTelemetry 공식 문서, Traces. 요청 경로, 스팬과 문맥 전파, 속성과 이벤트, 비동기 작업을 연결하는 스팬 링크의 개념을 확인했다. 문서의 예제 필드를 그대로 제품의 최신 표준 스키마라고 재현하지 않았다. 원문: https://opentelemetry.io/docs/concepts/signals/traces/

Traces

 

OpenAI Agents SDK 공식 문서, Tracing. 기본 추적 범위, 민감 정보 포함 설정, 배치 전송, 처리기 추가와 교체, 전송 이전 마스킹의 주의점을 확인했다. 설정과 동작은 실제 사용하는 SDK 버전에서 다시 확인해야 한다. 원문: https://openai.github.io/openai-agents-python/tracing/

Tracing - OpenAI Agents SDK

 

AWS 기술 블로그, 오픈소스 Arize Phoenix를 활용한 멀티 에이전트 AI시스템 쉽고 빠르게 모니터링하기. 2025년 9월 18일 게시. Bedrock 에이전트, MCP, 검색과 토큰 및 비용 추적을 연결하는 한국어 구현 사례다. 시연용 비용 설정을 실제 요금으로 인용하지 않았다. 원문: https://aws.amazon.com/ko/blogs/tech/monitoring-using-arize-phoenix-multi-agent-ai-system/

오픈소스 Arize Phoenix 를 활용한 멀티 에이전트 AI

 

Cloud & AI Engineering, 코드를 이해하는 AI 에이전트, 그 다음 단계: LLM Observability. 2026년 1월 14일 게시. 국내 개발 블로그의 문제 제기, 도구 비교, 실패 분석과 평가로 이어지는 전개를 참고했다. 제품별 가격과 호스팅 조건은 이 글에서 현재 조건으로 단정하지 않았다. 원문: https://server-engineer.tistory.com/1062

코드를 이해하는 AI 에이전트, 그 다음 단계: LLM Observability (LangSmith vs LangFuse)

 

OpenTelemetry GenAI Semantic Conventions 저장소. 생성형 AI의 스팬, 지표, 이벤트와 MCP 관련 규약을 다루는 공식 저장소다. 기존 문서에서 별도 저장소로 이동한 상태를 확인했으며, 구현 시에는 사용 중인 계측 라이브러리가 지원하는 규약과 버전을 맞춰야 한다. 원문: https://github.com/open-telemetry/semantic-conventions-genai