[AIOps Agent 4] 운영·평가부터 OpenTelemetry와 Langfuse까지

Об этом предложении

이 글에서 다룰 주제 운영 설계 : 재시도·복구·비용·자동 조치를 어떻게 통제할까? 평가 : 그럴듯한 보고서와 유용한 조사 결과를 어떻게 구분할까? Langfuse : Grafana와 함께 사용하려면 지금 무엇을 준비해야 할까? 주요 단어 · Idempotency · Backpressure · Evaluation · OpenTelemetry · Trace · Span · Langfuse · Canary 읽기 안내 · 읽기 전용 조사 흐름을 만든 뒤 운영으로 확장하는 중급·고급 편입니다. 읽고 나면 재실행 시나리오를 설계하고, 품질 회귀와 Langfuse 계측 누락을 점검할 수 있습니다. 보고서를 한 번 잘 생성하는 것과 매일 운영할 수 있는 에이전트를 만드는 것은 다르다. 운영에서는 알림이 몰리고, 도구가 느려지고, 사람이 승인하는 동안 배포 상태가 바뀐다. 이번 편에서는 이 문제를 다루고, 향후 Langfuse를 연결할 수 있는 관측 구조를 설계한다. 그림 1. Grafana 생태계는 서비스·실행 상태를, Langfuse는 모델·프롬프트·도구 단계와 평가를 살펴보는 데 활용한다. 두 경로는 상관 ID로 연결하고, 민감 데이터는 내보내기 전에 줄인다. 1. 운영 상태: 성공·실패 외에도 기다림과 불확실성이 있다 다음은 제안 상태 모델이다. queued → running → validating → completed ├→ partial ├→ needs_human → running ├→ failed └→ cancelled partial 은 일부 증거를 얻었지만 결론을 내릴 수 없는 상태다. needs_human 은 승인이나 추가 정보가 필요한 상태다. 성공 여부가 불명확한 외부 변경은 reconciling 같은 별도 상태로 확장해 실제 대상과 실행 원장을 대조한다. 작업마다 deadline, 최대 모델 호출 수, 도구 호출 수, 토큰·비용 상한을 둔다. 예를 들어 90초·6단계·도구 12회는 시작점으로 시험할 예산이지 운영 표준이 아니다. 실제 지연과 비용 분포로 조정한다. Backpressure 는 처리 능력보다 많은 요청이 들어올 때 유입 속도와 대기량을 제한하는 방식이다. tenant별 동시성, 큐 길이 상한, 중요도별 처리, 과부하 시 축약 보고서 등을 설계한다. 모델 장애가 기존 알림 전송까지 막게 해서는 안 된다. 1.1 큐가 밀리는 이유를 작은 계산으로 확인한다 학습용으로 평균 조사 시간이 30초이고 Worker 동시성이 4라고 하자. 다른 병목이 없다면 평균 처리 능력은 4/30 ≈ 0.133건/초 , 분당 약 8건이다. 알림이 분당 12건씩 지속해서 유입되면 대기 작업은 분당 약 4건 늘어난다. 단순히 모델 응답이 정상이라는 이유로 시스템이 안정적이라고 볼 수 없다. 실제 처리 시간은 분산이 크고 외부 API rate limit도 있으므로 이 계산은 용량을 가늠하는 근사다. 큐 대기 시간과 작업 실행 시간을 분리해 관측해야 한다. 실행은 30초여도 큐에서 5분 기다리면 운영자가 받는 보고서는 이미 늦다. 중요 서비스 우선순위를 두더라도 특정 tenant가 전체 Worker를 독점하지 않게 제한한다. 중복 알림을 하나의 incident에 묶고, 대기 시간이 deadline을 넘은 작업은 새로 시작할지 축약 보고서를 낼지 정책을 정한다. 2. 재시도와 자동 조치: 반복한다고 항상 안전한 것은 아니다 읽기 도구의 일시적인 429·5xx·연결 오류는 제한된 지수 백오프와 jitter를 적용할 수 있다. 인증 실패·잘못된 인자는 반복하지 않는다. 전체 deadline과 취소 요청은 하위 호출까지 전달한다. 변경 도구는 멱등 키와 실행 원장을 사용한다. 외부 API 성공 후 DB 기록 전에 장애가 나면 단순 재시도로 중복 변경이 생길 수 있다. 가능하면 대상 상태를 읽고 원하는 상태와 비교하는 방식으로 복구한다. Exactly-once를 선언하기보다 중복 전달을 전제로 효과를 제어한다. 자동 조치는 관찰 전용 → 권고 → 사람 승인 실행 → 제한된 자동 실행 순서로 확장하는 것이 이 글의 제안이다. 마지막 단계에는 영향 범위 제한, cooldown, 동시에 하나의 변경, kill switch, 사후 검증, 실패 시 중단이 필요하다. 롤백도 상태 변경이므로 별도 위험과 권한이 있다. 그림 2. timeout을 실패로 단정하지 않는다. 변경 효과를 확인한 뒤 완료 처리하거나 제한된 재시도를 결정한다. 2.1 재시작을 실제 사건 순서로 검증하기 action-17 로 replica를 3→4로 바꿨다고 하자. 대상 API는 성공했지만 Worker가 실행 원장에 성공을 기록하기 전에 종료된다. 큐는 다시 같은 작업을 전달한다. 새 Worker가 단순히 “미완료니까 다시 실행”하면 중복 부수 효과가 생길 수 있다. 새 Worker는 action ID와 실행 원장, 대상 상태를 대조한다. 이미 원하는 상태이고 이 동작의 완료를 식별할 수 있다면 완료로 수렴시킨다. 상태가 다르거나 다른 변경과 구분할 수 없으면 needs_human 으로 보낸다. 자연어 보고서만 보고 성공을 복원하지 않는다. DB 작업 점유에는 lease 만료와 소유권 확인을 둔다. 오래 멈췄던 Worker가 뒤늦게 살아나 다른 Worker와 동시에 실행하는 상황도 고려한다. 대상 시스템이 지원한다면 fencing token·버전 조건으로 오래된 실행자를 거부한다. 분산 잠금이 있다는 사실만으로 외부 변경의 원자성이 보장되지는 않는다. 3. 평가: 도구가 성공해도 분석은 틀릴 수 있다 평가 층 질문 검사 방법 계약 스키마·단위·범위가 맞는가? 코드와 contract test 권한 허용되지 않은 조회·실행을 막는가? 거부 사례·교차 tenant 테스트 근거 주장에 실제 evidence가 연결되는가? ID·출처·기간 검증 + 사람 검토 추론 결과 후보가 증거와 모순되지 않는가? 정답 사례·반증 사례·전문가 평가 운영 효율 사람이 조사하는 데 도움이 되는가? 확인 시간·수정량·유용성 평가 비용·가용성 지연과 호출 비용이 적절한가? p50/p95, 호출·토큰·실패율 근거 충실도는 예를 들어 근거로 뒷받침된 사실 주장 수 / 전체 검증 대상 사실 주장 수 로 정의할 수 있다. 무엇을 사실 주장으로 세는지 rubric을 고정해야 비교가 가능하다. 금지 동작 차단률이 테스트에서 100%여도 모든 공격을 막는다는 증거는 아니다. 보고서의 전체 정확도를 하나의 숫자로만 합치지 않는다. 근거 누락, 잘못된 서비스 매핑, 과거 지식 재사용, 원인 단정, 권한 위반을 분리해야 개선할 위치가 보인다. 모델의 내부 추론 전문을 수집하려 하기보다 도구 입력·출력, 최종 주장, 근거 ID, 짧은 판단 요약을 남긴다. 4. 평가 데이터: 시간과 정답이 새면 점수가 부풀려진다 과거 장애의 조사 시작 시점에 알 수 있었던 자료만 입력한다. 나중에 작성한 회고의 확정 원인이 검색 문맥에 들어가면 실제 조사 능력을 평가하지 못한다. 서비스·시간별로 학습용 사례와 보류 평가셋을 분리한다. 고정 회귀셋에는 정상, 실제 이상, 수집 중단, 저트래픽, 중복 알림, 잘못된 런북, 악성 로그, 승인 만료, 도구 timeout 사례를 둔다. 합성 데이터는 드문 실패를 보완하지만 실제 운영 성능을 대체하지 않는다. 생성한 정답 역시 사람이 검토해야 한다. LLM-as-a-judge는 서술형 평가에 보조로 쓸 수 있다. 그러나 권한 위반·근거 ID 존재·기간 일치처럼 결정적으로 검증할 항목은 코드로 검사한다. Judge의 모델·프롬프트·rubric도 버전을 고정하고 사람 판정과 일치하는지 확인한다. 평가 점수를 저장한다고 운영 Agent가 자동 학습되는 것은 아니다. 4.1 평가표 한 행을 어떻게 작성할까? { "case_id": "checkout-stale-01", "available_evidence": ["metric_stale", "logs_timeout"], "expected_behavior": "report_partial_and_request_fresh_data", "forbidden_actions": ["restart", "claim_root_cause_confirmed"], "max_tool_calls": 4 } 설명용 평가 사례다. 정답을 “DB 문제” 하나로 적지 않는다. 이 입력에서 해야 할 행동은 신선한 근거를 요청하고 결론을 보류하는 것이다. 모델이 우연히 실제 원인을 맞혀도 입력에 근거가 없으면 좋은 조사 결과로 채점하지 않는다. 예를 들어 20개 사례 중 근거가 충분한 12개에서는 10개를 올바르게 설명하고, 근거가 부족한 8개에서는 7개를 적절히 보류했다고 하자. 충분한 사례의 정확도는 10/12, 불충분한 사례의 적절한 보류율은 7/8이다. 둘을 섞은 “85% 성공” 하나만 남기면 어느 조건에서 실패하는지 알기 어렵다. 모두 계산용 예시이며 실측 점수가 아니다. 4.2 프롬프트 개정의 배포 기준 동일한 입력 fixture와 도구 응답으로 구버전과 신버전을 비교한다. 시간초과·권한 거부 처리, 근거 충실도, 지연, 토큰 비용을 함께 본다. 근거 충실도는 좋아졌지만 조회 비용이 5배가 되면 허용할 업무인지 판단해야 한다. 모델 호출의 변동성 때문에 경계 사례는 반복하고 분포를 남긴다. 실서비스에서는 shadow 모드로 사람이 보던 사건을 읽기 전용으로 함께 조사하게 할 수 있다. 이때도 조회 부하와 민감 데이터 처리는 실제 비용이다. 제한된 사용자 또는 서비스에 canary로 노출하고, 문제가 생기면 프롬프트·모델·정책·도구 버전을 묶어 이전 구성으로 되돌린다. 5. Grafana와 Langfuse: 서로 다른 질문을 연결한다 Trace 는 한 작업의 실행 흐름, Span 은 그 안의 한 단계다. OpenTelemetry는 이 문맥을 서비스와 프로세스 사이에 전달할 수 있게 한다. 보고 싶은 질문 주요 관측 위치 큐가 밀리는가, 도구 API가 느린가? Prometheus·Grafana 어느 워커·외부 호출에서 실패했는가? Loki·Tempo 어떤 프롬프트·모델 버전이 사용됐는가? Langfuse LLM 토큰·비용·도구 선택이 어떻게 달라졌는가? Langfuse와 비용 원장 누가 어떤 변경을 승인했는가? 별도 감사·실행 원장 Langfuse SDK는 OpenTelemetry 기반 추적을 제공한다. Python 및 JS/TS SDK의 API와 호환 버전은 다를 수 있으므로 프로젝트에 채택한 버전을 잠그고 해당 문서를 따른다. Langfuse SDK overview 6. 지금부터 준비할 관측 인터페이스 처음부터 업무 코드 전체에 특정 제품 호출을 흩뿌리지 않는다. observability/ 에 얇은 인터페이스를 두고 다음 문맥을 관리한다. incident_id 하나의 장애 묶음 run_id 한 번의 조사 실행 agent_trace_id Agent 실행 추적 ID subject_trace_ids 조사 대상으로 조회한 서비스 trace ID 목록 prompt_version 프롬프트 버전 model_version 실제 호출 모델 식별자 tool_schema_version 도구 입출력 계약 버전 policy_version 권한 정책 버전 조사 대상 서비스의 trace ID와 조사 Agent 자신의 trace ID는 다르다. 서비스의 한 요청을 분석한다고 그 ID를 Agent 루트 trace ID로 덮어쓰지 않는다. 속성·링크로 연관 관계를 기록하고, 비동기 큐에서는 검증된 trace context를 전파하거나 span link를 사용한다. 논리적인 span 구조는 다음과 같다. incident.run ├── intake.normalize ├── evidence.metrics ├── evidence.logs ├── evidence.traces ├── knowledge.retrieve ├── llm.summarize └── report.validate 최소 구조화 로그와 OTel 계측부터 시작해도 된다. 추후 Langfuse adapter를 추가할 때 동일한 run ID로 보고서와 연결할 수 있다. 토큰·비용은 모델 공급자 응답과 가격 설정에 의존한다. 추정 비용과 실제 청구를 동일하게 보지 않는다. 그림 3. 그림 1과 같은 배치다. Langfuse로 보낼 내용은 전송 전에 선별하며, 필수 감사 기록은 별도 원장에 남긴다. 6.1 그래프의 ID 연결을 실제 값으로 생각하기 incident_id=inc-42 에 첫 조사가 run-101 , 재조사가 run-102 일 수 있다. 각 run은 서로 다른 Agent trace를 가진다. 조사 대상 checkout 요청의 trace는 또 별개다. DB에서는 이 관계를 명시적으로 저장하고, 보고서의 근거 목록에서 대상 trace를 참조한다. OTel trace context는 실행 부모·자식 관계를 전달하는 정보다. 단순 업무 ID인 incident ID와 같은 값으로 쓰지 않는다. 큐를 건너면 HTTP 요청의 활성 context가 자동 유지되지 않을 수 있으므로 producer의 context를 메시지에 주입하고 consumer에서 복원하는 계측이 필요하다. 장시간 승인 대기 이후의 재개는 별도 trace와 link로 표현할 수도 있다. 그림 4. 화살표는 설명 순서이며 trace의 부모·자식 관계가 아니다. 장애·Agent 실행·서비스 요청은 다른 식별자다. 조사 대상 trace는 증거 링크로 연결하고 Agent 자체의 실행 문맥과 구분한다. 6.2 저장할 항목과 보내지 않을 항목을 계약으로 정한다 관측 필드 기본 제안 이유 run ID·버전·상태 기록 실행 재현·비교 도구 이름·지연·응답 상태 기록 병목·실패 분석 토큰 사용량·모델명 기록 비용·변경 영향 민감 로그 원문·사용자 질문 전체 기본 미수집 개인정보·비밀 최소화 API token·인증 헤더 기록 금지 인증정보 유출 방지 evidence ID·검증 결과 기록 원문 복제 없이 결과 추적 가명 ID도 다른 자료와 결합하면 개인을 식별할 수 있으므로 보존·접근 정책이 필요하다. 샘플링을 적용하는 trace와 반드시 남겨야 하는 승인·실행 감사 기록은 독립 경로로 관리한다. 7. Langfuse 연결 예시와 검증 절차 아래는 공식 Python SDK 계측 형태를 참고한 최소 예시다. 실제 LLM 호출과 SDK 설치·버전 고정은 생략했다. 이 글에서 실행 검증한 코드가 아니며 도입 버전의 API를 확인해야 한다. Langfuse Instrumentation from langfuse import get_client, observe langfuse = get_client() @observe(name="incident.run", capture_input=False, capture_output=False) def investigate(request): # 요청 원문 대신 비식별 ID와 버전만 선택적으로 기록한다. return run_workflow(request) # 단기 실행 스크립트 종료 전 전송 대기. # 상시 서버는 종료 훅과 SDK 수명주기에 맞춰 처리한다. langfuse.flush() run_workflow 는 프로젝트에서 구현할 함수다. 실제 배포에서는 선택한 Cloud 리전 또는 self-hosted 주소, 공개 키·비밀 키를 비밀 저장소에서 주입한다. 코드·프롬프트·이미지·로그에 키를 넣지 않는다. LLM 및 도구 단계도 선택적으로 계측하고 모델·사용량 속성 매핑을 확인한다. 연결 순서는 다음과 같다. 민감 정보가 없는 staging 조사 한 건을 실행한다. 루트와 자식 span의 연결, run ID, 모델·프롬프트 버전을 확인한다. 입력·출력·예외에서 개인정보와 비밀이 빠졌는지 확인한다. 동일 호출이 두 번 계측되거나 이중 export되지 않는지 확인한다. 평가 점수와 실행 결과를 연결하고, export 실패 시 업무 흐름에 미치는 영향을 시험한다. Tempo와 Langfuse가 모두 OTel을 사용한다고 동일한 exporter 설정으로 자동 통합되는 것은 아니다. provider 수명주기, instrumentation scope, 인증, 속성 매핑, 샘플링, 중복 계측을 점검한다. 원시 로그 전부를 두 곳에 복제하지 말고 목적에 맞는 데이터만 보낸다. Langfuse Advanced features SDK·collector에서 민감 정보를 전송 전에 제거한다. 입력·출력 자동 캡처를 꺼도 수동 metadata나 예외 메시지에서 유출될 수 있다. self-hosting도 접근 제어·보존·백업·삭제 책임을 없애지 않는다. Langfuse Masking 7.1 Langfuse가 비어 있을 때 확인할 순서 키를 넣었는데 화면에 아무것도 보이지 않으면 곧바로 Agent 코드를 모두 바꾸지 않는다. 우선 무해한 테스트 span 하나를 만들어 endpoint·프로젝트·리전이 맞는지 본다. 다음으로 종료 시 flush와 네트워크 오류를 확인하고, root와 child의 context가 연결됐는지 검사한다. 마지막으로 instrumentation scope 필터·샘플링·중복 exporter를 확인한다. 프로젝트가 이미 OTel provider를 초기화하고 있다면 Langfuse 추가 초기화와 충돌할 수 있다. 서비스 전체 telemetry는 Tempo로, LLM 관련 관측은 Langfuse로 보내는 구성을 설계하되 실제 exporter의 속성 변환과 필터 동작을 테스트한다. 두 제품에서 같은 span 수가 보이는 것을 목표로 잡지 않는다. 저장 목적과 샘플링이 다를 수 있다. 계측 실패는 큐에 무한히 쌓이거나 조사 응답을 끝없이 지연시키면 안 된다. 전송 큐 크기·timeout·drop 지표와 종료 처리 시간을 정한다. 반면 승인 원장 기록 실패는 변경 실행을 중단해야 할 수 있다. 선택적 관측 실패와 필수 감사 실패의 처리 정책을 다르게 정하는 것 이 운영 설계다. 7.2 비용 예산을 호출 단위에서 작업 단위로 올린다 호출 한 번의 입력·출력 토큰 비용뿐 아니라 재시도, RAG 임베딩, 도구 질의, trace 저장 비용을 포함한다. 가령 입력 2,000토큰·출력 500토큰을 6회 호출하면 입력 합계 12,000·출력 합계 3,000토큰이다. 실제 모델의 단가를 각각 곱하고 캐시·추론 토큰 등의 청구 규칙을 반영한다. 이는 특정 모델의 요금을 제시하는 예시가 아니다. 한 번의 호출 가격이 저렴해도 잘못된 도구 선택으로 20회 반복하면 비쌀 수 있다. 단계별 비용을 보고 “더 작은 모델로 바꿀까?”뿐 아니라 “고정 쿼리로 해결할 수 있을까?”, “같은 증거를 매번 다시 읽고 있나?”를 점검한다. 8. 중급에서 고급으로 가는 구현 로드맵 단계 만들 것 다음 단계로 넘어갈 기준 1 fixture 기반 읽기 전용 보고서 사실·가설·보류 구분 가능 2 실제 메트릭·로그·트레이스 adapter 권한·결측·timeout 처리 통과 3 DB 상태·큐·중복 방지 워커 중단 후 안전한 재개 4 고정 평가셋과 OTel 품질·비용 회귀를 재현 가능 5 Langfuse·승인형 조치 마스킹·평가·감사 연결 검증 6 제한적 자동 조치·점진 배포 영향 한도·중단·복구 검증 고급 단계의 멀티 에이전트는 역할 이름을 늘리는 작업이 아니다. 독립된 권한·문맥·전문성이 필요하고, 단일 Agent보다 평가 결과나 지연이 나아지는지 검증할 수 있을 때 도입한다. 하위 에이전트에도 부모보다 넓은 권한을 주지 않으며, 전체 예산·취소·중복 도구 호출을 함께 관리한다. 처음 만들 시스템의 목표는 “스스로 모든 장애를 고치는 AI”보다 운영자가 신뢰할 수 있는 증거를 더 빠르게 모으고, 허용된 범위에서 검증 가능한 결과를 내는 에이전트 로 잡는 것이 구체적이다. 자료 기준 : 2026-10-04, 본문에 연결한 공식 문서의 해당 기능·구문을 확인했다. 모든 버전의 전체 동작을 검증한 것은 아니다. 설계·코드·예산은 예시이며 실제 운영 성능이나 배포 완료를 의미하지 않는다. 그림 자산 출처 : Grafana 공식 OSS 제품 페이지 의 제품별 원본 로고를 색·비율을 유지해 사용했다. 연결선·구획·설명은 자체 제작이며 제품의 공식 아키텍처 도면이 아니다. 상표 사용 정책 에 따른 표기: The Grafana Labs Marks are trademarks of Grafana Labs, and are used with Grafana Labs’ permission. We are not affiliated with, endorsed or sponsored by Grafana Labs or its affil