AX LABS
← 블로그 AX 전략

AI-Native PRD는 운영 문서다

기능 정의만으로는 agent 리스크를 못 잡는다

AX LABS 6분 읽기

신규 기능 리뷰 회의에서 아직도 화면, 사용자 여정, 백로그, 일정만 본다. 그런데 실제 제품 안에서는 agent가 API를 호출하고, 파일을 읽고, 외부 시스템에 접근하고, 중간 결과를 바탕으로 다음 행동을 고른다. 기능 PRD만으로는 이 실행을 설명하지 못한다.

OpenAI는 2026년 Responses API와 컴퓨터 환경을 설명하며 agent가 shell, 파일 시스템, 데이터베이스, 네트워크 접근 같은 실행 환경을 다룬다고 밝혔다. Google Cloud도 2026년 장시간 agent workflow의 재개, HITL 확인, 분산 실행을 운영 문제로 다뤘다. 제품 리뷰의 질문이 바뀌어야 한다.

기능 PRD는 agent 실행을 숨긴다

기존 PRD는 사용자가 버튼을 누른 뒤 어떤 화면이 나오는지 잘 설명한다. 하지만 agent형 기능은 화면보다 호출이 중요하다. agent가 무엇을 읽고, 어떤 tool을 부르고, 어느 시점에 멈추고, 실패를 어떻게 복구하는지가 제품 품질을 결정한다.

그래서 AI-Native product review에는 세 섹션이 필수다.

PRD 필수 섹션 리뷰 질문 빠지면 생기는 문제
agent-call scenario agent가 어떤 순서로 context, tool, memory를 호출하는가 데모는 되지만 운영 로그가 해석되지 않는다
eval SLA 어떤 eval을 통과해야 출시·확대·중단을 결정하는가 장애가 아니라 취향 논쟁으로 회귀한다
permission envelope agent가 넘지 못하는 데이터·행동·금액·시스템 경계는 무엇인가 권한 설계가 보안팀 사후 승인으로 밀린다

AI-Native PRD는 기능 명세서가 아니다. agent 실행 계약서다.

agent-call scenario는 사용자 여정이 아니다

agent-call scenario는 “사용자가 요청한다 → 답변한다”가 아니다. 그 사이의 실행 단계를 적어야 한다. 최소한 네 가지가 들어간다.

  1. 입력 context: 사용자 발화, 업무 데이터, 세션 상태, 과거 memory
  2. tool 호출: 검색, DB 조회, SaaS API, 코드 실행, 문서 생성
  3. 중단 조건: 권한 부족, 불확실성, 비용 초과, 정책 위반
  4. human handoff: 누구에게, 어떤 증거와 함께 넘기는가

Anthropic은 2026년 agent eval 글에서 agent가 여러 턴에 걸쳐 tool을 호출하고 state를 바꾸며 환경 안에서 실행된다고 설명했다. 이 구조에서는 최종 답변만 평가하면 늦다. 중간 호출의 품질이 제품 품질이다.

agent-call scenario는 UX 문서와도 다르다. UX는 사람이 보는 흐름을 그린다. agent-call scenario는 시스템이 실제로 수행하는 흐름을 고정한다. 이 문서가 있어야 엔지니어, 보안, 법무, 운영, 현업이 같은 대상을 보고 리뷰한다.

eval SLA는 출시 기준보다 운영 기준이다

eval은 “모델이 똑똑한가”를 묻는 시험지가 아니다. 제품이 운영 중 지켜야 할 서비스 약속이다. 그래서 SLA 형식으로 적어야 한다.

PRD에는 다음 문장이 들어가야 한다.

  • 출시 전 반드시 통과할 golden task set
  • 배포 후 매일 또는 매주 돌릴 regression eval
  • 실패 시 롤백, 권한 축소, human-only 전환 기준
  • 현업 이의제기를 eval case로 편입하는 절차

OpenAI는 2025년 eval을 business objective를 consistent result로 바꾸는 프레임으로 설명했다. Anthropic도 agent eval은 단순 출력 평가보다 환경, tool, task, agent loop를 함께 봐야 한다고 정리했다. 두 자료의 공통점은 분명하다. eval은 연구팀의 부속물이 아니라 제품 운영 체계다.

여기서 SLA라는 단어가 중요하다. “좋아 보인다”는 출시 근거가 아니다. “이 조건을 만족하지 못하면 확대하지 않는다”가 출시 근거다.

permission envelope가 투자 판단을 만든다

agent 제품의 ROI는 권한에서 갈린다. 권한이 너무 좁으면 자동화가 아니라 검색창이 된다. 권한이 너무 넓으면 작은 오류가 큰 사고가 된다. 그래서 PRD 단계에서 permission envelope를 먼저 그어야 한다.

Anthropic은 2026년 Claude containment 글에서 agent의 blast radius를 제한하는 것이 핵심 공학 문제라고 썼고, tool permission을 세분화해 피해 범위를 줄이는 접근을 설명했다. Claude Code 제품 설명도 파일 수정과 명령 실행 전에 명시적 허가를 요구하는 기본값을 강조한다.

permission envelope는 보안 체크리스트가 아니다. 투자 범위의 설계다. 이 기능이 읽을 수 있는 데이터, 쓸 수 있는 시스템, 실행할 수 있는 명령, 사람이 승인해야 하는 구간을 정해야 한다. 그래야 경영진은 “얼마나 자동화할 것인가”와 “어디까지 책임질 것인가”를 같은 회의에서 결정한다.

이 템플릿을 PRD에 넣으면 product review의 언어가 바뀐다. 화면 리뷰에서 운영 리뷰로 넘어간다. 기능 승인에서 실행 계약 승인으로 넘어간다. AX LABS는 이 전환을 AX Ops 안에서 전략, 설계, 운영 내재화까지 한 사이클로 다룬다. 다음 제품 리뷰부터 PRD 첫 장에 세 항목을 넣어라: agent-call scenario, eval SLA, permission envelope. 더 깊은 템플릿 설계는 AX Ops 방법론 →

참고