신규 AI 기능 회의에서 자주 보는 장면이 있다. 화면 흐름, 모델 후보, 데모 일정은 빠르게 정해진다. 그런데 출시 후 무엇을 봐야 실패를 알 수 있는지는 마지막에 밀린다. 그 결과 첫 장애는 서버 장애가 아니라 설명 불가능한 품질 저하다.
AI-Native 제품의 backlog는 기능 목록이 아니다. 운영 중 학습할 수 있는 관측점의 목록이다. agent가 어떤 호출을 했는지, 어디서 빗나갔는지, 다음 eval에 어떤 seed로 남길지를 먼저 설계해야 한다.
AI 제품의 요구사항은 로그 계약이다
전통적 SaaS 요구사항은 사용자 행동과 시스템 응답을 정의하면 충분했다. AI 제품은 부족하다. 같은 버튼을 눌러도 context, memory, tool, policy, 모델 상태에 따라 실행 경로가 달라진다.
OpenAI Agents SDK는 tracing에서 LLM generation, tool call, handoff, guardrail, custom event를 한 실행 기록으로 본다. LangSmith도 agent trace를 LLM call, tool invocation, retrieval step까지 실행 트리로 관측하는 방향을 명확히 제시한다. 운영의 기준이 페이지뷰에서 run trace로 이동했다는 뜻이다.
AI 기능 요구사항의 첫 산출물은 화면 정의서가 아니라 telemetry contract다.
telemetry contract에는 최소한 다음이 들어간다.
- agent_run_id, user_intent_id, prompt_version, model_alias
- tool_call_id, tool_name, input/output hash, permission state
- retrieval source id, memory read/write 여부, context truncation 여부
- human approval, override, correction, escalation 기록
- failure_label, eval_seed_candidate, redaction policy
이 항목은 개발팀의 부가 작업이 아니다. 경영진이 ROI를 판단할 수 있는 최소 단위다. 무엇이 반복 실패인지 모르면 투자 판단은 감에 머문다.
실패 라벨은 사후 분석이 아니라 제품 언어다
AI 실패를 모두 hallucination이라고 부르면 운영이 멈춘다. 실패의 원인이 다르면 처방도 다르다. 검색 실패, tool 권한 실패, instruction 충돌, user intent 오분류, human handoff 지연은 같은 문제가 아니다.
| 기존 backlog | AI-Native telemetry backlog |
|---|---|
| 기능명과 화면 흐름 | agent 실행 경로와 관측 지점 |
| 에러 코드 | 실패 라벨 체계 |
| QA 시나리오 | production trace에서 뽑은 eval seed |
| 배포 완료 | drift, regression, escalation 확인 |
| VOC 수집 | trace와 human correction 연결 |
실패 라벨은 제품팀, 현업, 리스크, 개발팀이 함께 쓰는 언어가 되어야 한다. 라벨이 맞아야 backlog 우선순위가 맞는다. tool 실패가 반복되는데 prompt를 고치는 조직은 비용만 쓴다. intent 라벨이 부실한데 모델 교체를 먼저 하는 조직도 같은 실수를 한다.
OpenTelemetry의 GenAI semantic conventions는 provider, operation, tool call id, evaluation metric name 같은 속성을 표준화하는 방향으로 확장되고 있다. 표준을 그대로 베끼라는 뜻이 아니다. 내부 라벨 체계를 국제적 관측 문법과 충돌하지 않게 잡아야 나중에 도구를 바꿔도 데이터가 남는다.
eval seed는 운영 중에 채집한다
많은 조직이 eval을 별도 프로젝트로 만든다. 출시 전에 만든 정적 테스트셋은 빠르게 낡는다. 실제 사용자가 던지는 요청, 내부 데이터의 결함, tool 권한의 빈틈은 운영에서 드러난다.
따라서 요구사항에 eval seed 수집 지점을 넣어야 한다. agent가 답을 냈을 때가 아니라 다음 순간을 설계해야 한다.
- 사용자가 수정한 답변을 seed 후보로 남긴다.
- human approver가 반려한 run을 실패 라벨과 묶는다.
- tool retry가 반복된 run을 별도 queue로 보낸다.
- escalation된 대화를 원인 라벨과 expected outcome으로 저장한다.
LangSmith는 production trace를 문제 trace로 식별해 evaluation dataset으로 전환하는 흐름을 제시한다. OpenAI의 2025년 AgentKit 발표도 dataset, trace grading, automated prompt optimization을 eval 기능의 축으로 설명했다. 도구 이름은 바뀐다. 그러나 방향은 같다. 제품 운영 로그가 다음 평가셋이 된다.
backlog 우선순위를 바꿔야 한다
AI-Native product telemetry backlog는 비용 항목이 아니다. 기능 출시 이후 무엇을 고칠지 알게 만드는 전략 자산이다. 이 backlog가 없으면 출시 후 회의는 반복된다. 현업은 품질이 낮다고 말하고, 개발팀은 재현이 안 된다고 말하고, 경영진은 효과가 불명확하다고 말한다.
AX Ops에서는 AI 기능 backlog를 세 갈래로 본다. 기능 backlog, telemetry backlog, eval backlog다. 세 목록은 따로 움직이지 않는다. 하나의 기능 요구사항에는 반드시 관측 지점과 평가 seed 수집 지점이 붙는다.
참고와 다음 행동
- OpenAI Agents SDK Tracing, 2026 현재 문서: https://openai.github.io/openai-agents-python/tracing/
- OpenAI, Introducing AgentKit, 2025 및 2026 업데이트: https://openai.com/index/introducing-agentkit/
- OpenTelemetry, Inside the LLM Call: GenAI Observability with OpenTelemetry, 2026: https://opentelemetry.io/blog/2026/genai-observability/
- LangChain, AI Agent Observability: Tracing, Testing, and Improving Agents, 2026: https://www.langchain.com/resources/agent-observability
- Anthropic, Enabling Claude Code to work more autonomously, 2025: https://www.anthropic.com/news/enabling-claude-code-to-work-more-autonomously
다음 AI 기능 회의에서는 화면보다 먼저 run trace, failure label, eval seed를 요구사항 템플릿에 넣어야 한다. AX LABS는 이 구조를 전략 수립부터 운영 내재화까지 한 사이클로 설계한다: AX Ops 방법론 →