생성형 AI 서비스가 단순한 질의응답을 넘어 검색, 데이터베이스 조회, 코드 실행, 외부 API 호출을 연속으로 수행하는 에이전트 형태로 발전하면서 운영 방식도 달라지고 있습니다. 전통적인 웹 서비스는 요청 하나가 어느 서버를 거쳤는지 추적하면 원인을 찾을 수 있었지만, AI 에이전트는 같은 질문에도 서로 다른 도구와 경로를 선택할 수 있습니다. 응답이 실패하지 않았더라도 근거가 부정확하거나 불필요한 호출을 반복해 비용이 커질 수 있습니다. 따라서 운영팀은 속도와 오류율뿐 아니라 판단 과정, 근거 품질, 도구 사용량을 함께 관찰해야 합니다.
한 번의 요청을 전체 흐름으로 연결하기
사용자의 요청이 들어오면 고유한 추적 ID를 부여하고, 모델 호출과 검색, 도구 실행, 재시도에 같은 문맥을 전달해야 합니다. 각 단계에는 시작 시각과 종료 시각, 사용한 모델 버전, 입력과 출력의 크기, 성공 여부를 기록합니다. 다만 프롬프트와 결과 전체를 무조건 저장하면 개인정보나 회사 기밀이 로그에 남을 수 있으므로 기본은 메타데이터 중심으로 설계합니다. 문제 분석에 필요한 샘플만 권한과 보존 기간을 제한해 저장하고 민감한 값은 수집 전에 가립니다.
에이전트 운영에 필요한 핵심 지표
- 요청당 모델 호출 횟수와 입력·출력 토큰 수
- 검색 결과가 실제 답변 근거로 사용된 비율
- 도구별 성공률, 지연 시간, 재시도 횟수
- 사람에게 넘겨진 요청과 사용자가 다시 질문한 비율
- 요청당 비용과 업무 완료 한 건당 총비용
평균값만 보면 일부 사용자가 겪는 긴 지연이나 폭발적인 비용을 놓칠 수 있습니다. 지연 시간과 비용은 중앙값뿐 아니라 상위 95%, 99% 구간을 함께 보고, 업무 유형과 모델, 도구별로 나누어 확인합니다. 배포 전후의 분포를 비교하면 새로운 프롬프트가 품질은 높였지만 호출 횟수를 크게 늘렸는지도 발견할 수 있습니다.
정답 여부와 업무 완료를 따로 평가하기
문장이 자연스럽다는 이유만으로 좋은 결과라고 판단할 수 없습니다. 지식 질의는 답변의 사실성과 인용 근거를 평가하고, 예약이나 환불 같은 실행 업무는 최종 상태가 정확히 변경됐는지 확인해야 합니다. 도구 호출 형식이 올바르더라도 사용자의 의도와 다른 작업을 수행했다면 실패입니다. 대표적인 실제 요청으로 평가 세트를 만들고 정확성, 근거성, 정책 준수, 완료율을 각각 측정하는 것이 좋습니다.
운영 원칙: 에이전트의 성공은 답변을 생성했다는 사실이 아니라 사용자의 목표를 허용된 범위 안에서 정확히 완료했다는 결과로 정의해야 합니다.
토큰 비용보다 전체 실행 비용을 보기
AI 비용을 모델 토큰 가격으로만 계산하면 검색 인프라, 벡터 데이터베이스, 서버리스 함수, 외부 API, 로그 저장 비용을 놓칩니다. 요청 하나가 여러 번 계획을 수정하면 작은 모델 호출도 누적되어 큰 비용이 됩니다. 업무 완료 한 건을 기준으로 모든 자원 비용을 합산하고, 실패하거나 사용자가 취소한 작업에 들어간 비용을 별도로 추적해야 개선 우선순위가 보입니다. 팀과 기능별 비용 태그를 일관되게 붙이면 어떤 제품 기능이 예산을 소비하는지도 파악할 수 있습니다.
비용을 줄이는 단계별 라우팅
모든 요청에 가장 큰 모델과 많은 검색 결과를 사용하는 방식은 간단하지만 비효율적입니다. 규칙으로 처리할 수 있는 상태 조회는 모델 없이 해결하고, 분류와 요약은 작은 모델부터 시도하며, 복잡한 추론에만 고성능 모델을 사용합니다. 검색 결과 개수와 대화 기록 길이에도 상한을 두고, 오래된 대화는 필요한 사실만 구조화해 전달합니다. 반복되는 공개 정보는 유효 기간을 정해 캐시하되 사용자 권한이나 최신 상태가 중요한 결과는 캐시 키와 만료 정책을 엄격하게 관리합니다.
무한 반복과 재시도를 차단하기
도구가 계속 실패할 때 에이전트가 같은 인수를 바꾸지 않고 재호출하면 비용과 지연이 빠르게 늘어납니다. 한 요청의 최대 단계 수, 도구별 재시도 횟수, 총 실행 시간, 최대 비용을 미리 정해야 합니다. 재시도는 일시적 네트워크 오류처럼 회복 가능성이 있는 경우에만 지수적으로 간격을 늘려 수행합니다. 권한 부족이나 잘못된 입력은 즉시 사용자에게 필요한 정보를 요청하거나 사람에게 넘깁니다. 예산 한도에 가까워지면 부분 결과와 실패 원인을 명확히 반환하는 편이 침묵 속에서 계속 실행하는 것보다 낫습니다.
권한과 감사 기록을 관측성에 연결하기
에이전트가 외부 시스템을 수정할 수 있다면 도구별 최소 권한과 사용자별 접근 범위를 적용합니다. 읽기 작업과 쓰기 작업을 구분하고, 결제나 삭제처럼 되돌리기 어려운 행동은 별도 승인 단계를 둡니다. 감사 로그에는 누가 요청했는지, 어떤 정책과 권한으로 어떤 도구가 실행됐는지, 결과가 무엇인지 남깁니다. 로그를 볼 수 있는 권한도 제한해야 하며 개인정보의 보존 기간과 삭제 절차를 마련해야 합니다.
배포 전후의 실전 운영 순서
- 대표 업무별 성공 조건과 허용 비용을 정의합니다.
- 단계별 추적 ID와 모델·도구 메타데이터를 수집합니다.
- 오프라인 평가 세트로 품질과 정책 준수를 검사합니다.
- 소수 사용자에게 배포해 지연과 비용 분포를 확인합니다.
- 최대 단계, 시간, 재시도, 예산 한도를 설정합니다.
- 이상 징후가 발생하면 이전 버전으로 전환할 수 있게 합니다.
경보도 지표 하나가 임계값을 넘을 때마다 울리게 하기보다 사용자 영향과 연결해야 합니다. 예를 들어 도구 오류율 상승과 업무 완료율 하락이 동시에 나타나거나, 요청당 비용이 급증하면서 재시도가 늘어날 때 우선순위를 높입니다. 배포 버전과 프롬프트 버전을 지표에 표시하면 변화의 원인을 더 빠르게 좁힐 수 있습니다.
관측 데이터를 개선 학습으로 돌리기
운영 로그에서 자주 실패하는 질문을 익명화해 평가 세트에 추가하고, 검색 실패와 도구 선택 실패, 정책 거부, 사용자 입력 부족으로 유형을 나눕니다. 프롬프트만 수정하기 전에 지식 문서의 최신성, API 설명, 권한 설정, 사용자 화면의 안내가 원인인지 살펴야 합니다. 수정한 뒤에는 성공률만 아니라 비용과 지연, 안전 지표가 함께 좋아졌는지 확인합니다.
AI 에이전트의 관측성은 모든 생각을 저장하는 일이 아닙니다. 사용자의 목표가 어떤 단계와 자원을 거쳐 처리됐는지 재구성하고, 품질 저하와 비용 낭비를 안전하게 발견할 수 있는 최소한의 증거를 만드는 일입니다. 추적, 평가, 예산 한도, 최소 권한을 처음부터 하나의 운영 설계로 연결하면 기능이 복잡해져도 예측 가능한 서비스로 관리할 수 있습니다.