--- title: 에이전트에게 PRD는 통하지 않는다 description: "피처 스펙으로 쓰는 기존 PRD는 에이전트 제품 앞에서 무력해집니다. 권한 경계, 실패 모드, 비용 상한, 관찰 지표를 함께 설계하는 새로운 문서가 필요합니다. 운영 단계로 들어선 에이전트 시대를 위한 PRD의 여섯 축을 제안합니다." createdAt: 2026-04-23 author: 소피아 category: tech jobCategory: pm tags: [에이전트 PRD, 프로덕트 기획, AI 에이전트, 기획 프레임워크, 프로덕트 매니지먼트] featured: false canonical: "https://blog.careernote.io/article/agent-prd-beyond-features" source: CareerNote Blog language: ko --- 최근 팀의 PRD 템플릿을 열었다가 그대로 멈춰선 일이 있었습니다. "이 에이전트는 어떻게 실패하나요?"라는 동료의 질문에 답할 수가 없었습니다. 우리가 쓰던 PRD는 입력과 출력이 결정되어 있는 피처를 위한 문서였습니다. 같은 프롬프트로도 다른 경로를 선택하고, 스스로 도구를 호출하며, 때로는 멈추지 않고 루프에 빠지는 에이전트에게는 통하지 않는 문법이었습니다. 이번 주는 이 변화가 한층 선명해진 한 주였습니다. Google Cloud Next 2026이 오늘부터 사흘간 "에이전틱 AI의 프로덕션 전환"을 메인 테마로 열리고 있고, AWS는 이달 초 DevOps Agent와 Security Agent의 GA를 선언했습니다. Salesforce의 Slackbot은 MCP 기반의 자율 업무 보조로 전환했고, Databricks는 Unity AI Gateway로 에이전트 거버넌스를 제품화했습니다. Deloitte의 2026 State of AI 보고서에 따르면 이제 66%의 기업이 AI에서 실질적 이득을 확인했다고 답합니다. 에이전트는 실험 단계를 끝내고 운영 단계로 들어섰습니다. ## 왜 기존 PRD는 에이전트 앞에서 멈추는가 피처 PRD의 전제는 결정론입니다. "사용자가 A를 누르면 화면은 B로 간다." 그러나 에이전트의 전제는 확률성입니다. 같은 요청이라도 실행 경로가 다르고, 중간에 호출하는 도구 수가 다르고, 소요되는 토큰과 시간도 다릅니다. 더 까다로운 점은 에이전트가 "명시되지 않은 것"을 스스로 추론해 실행한다는 데 있습니다. 한 엔지니어링 블로그가 날카롭게 지적한 대로, 에이전트는 생략된 것을 추론합니다. 사양에 "이번 단계에서는 인증을 구현하지 않는다"라고 쓰지 않으면, 대부분의 웹 앱에 인증이 있다는 이유만으로 에이전트가 인증을 만들기 시작합니다. 즉 에이전트의 행동을 좁히는 힘은 피처 설명이 아니라 경계의 명시적 서술에서 옵니다. 그리고 이 경계는 화면 와이어프레임이 아니라 권한, 비용, 실패, 관찰의 언어로 기술되어야 합니다. ## 제한된 합리성 앞에 선 기획자 잠시 오래된 아이디어 하나를 꺼내보겠습니다. 1978년 노벨상 수상자 허버트 사이먼은 **제한된 합리성**(bounded rationality)을 제시했습니다. 모든 행위자는 완벽한 정보도, 무한한 계산 능력도 갖지 못한 채 만족할 만한 선택을 한다는 것입니다. 사이먼은 더 나아가 조직 관리의 핵심을 이렇게 정의했습니다. "행정의 과업은, 개인이 조직의 목표에 가장 가까운 합리성에 도달할 수 있도록 환경을 설계하는 것이다"(『Administrative Behavior』, 1947). 에이전트도 본질적으로 제한된 맥락과 제한된 추론을 가진 행위자입니다. PM의 새로운 역할 중 하나는, 이 행위자가 실수를 최소화하고 성공에 가까워지도록 **환경을 설계**하는 일입니다. 그 환경이 다름 아닌 PRD입니다. 심리학 쪽에도 참고할 지혜가 있습니다. 인간-자동화 상호작용 연구의 고전인 파라수라만과 셰리던의 논문(Parasuraman, Sheridan & Wickens, 2000)은 자동화를 네 단계로 나눕니다. 정보 획득, 정보 분석, 의사결정, 행동 실행. 각 단계마다 자동화 수준은 "제안만 한다"에서 "사람의 개입 없이 실행하고 사후에만 보고한다"까지 10단계로 구성됩니다. 이 연구가 일관되게 경고하는 것은 신뢰 캘리브레이션의 문제입니다. 과신은 부주의한 위임을 낳고, 불신은 활용 저하를 낳습니다. 두 극단 모두 제품을 실패로 이끕니다. 기획자의 과업은 이 신뢰 수준을 제품 안에 구체적으로 새겨 넣는 일입니다. 에이전트 PRD는 그 작업을 위한 문서입니다. ## 에이전트 PRD의 여섯 축 지난 몇 개월간 팀과 함께 PRD 템플릿을 다시 쓰면서, 여섯 개의 축이 반복해서 필요하다는 것을 확인했습니다. **1. 목적과 결과 기준.** 아웃풋이 아니라 아웃컴으로 정의합니다. "요약을 생성한다"가 아니라 "사용자가 회의 후 10분 안에 다음 액션을 결정하게 한다"와 같이 결과의 모양을 먼저 씁니다. **2. 권한 경계**(autonomy boundary). 파라수라만 모델을 빌리면, 에이전트의 행동을 세 등급으로 정리할 수 있습니다. 첫째, 제안만 하고 실행은 사람이. 둘째, 실행하되 사람의 승인 후에. 셋째, 자율 실행하고 사후에 보고. 같은 에이전트라도 작업별로 등급이 다를 수 있고, 이 차등 설계가 제품의 안전성과 효용을 함께 결정합니다. **3. 실패 모드와 fallback.** 에이전트는 실패의 종류가 인간보다 다양합니다. 환각, 도구 호출 실패, 무한 루프, 권한 없는 시도, 예산 초과. 각 실패마다 어떤 fallback이 있는가, 즉 재시도할지, 사람에게 에스컬레이션할지, 안전한 기본값을 반환할지를 명시해야 합니다. **4. 비용 상한**(cost ceiling). 단위 작업당 토큰, 단계 수, 실행 시간, 도구 호출 횟수를 상한으로 둡니다. 이 상한을 넘으면 자동 중단하고 사람에게 넘깁니다. 비용은 기능의 설명서가 아니라, 기능 자체입니다. **5. 관찰 지표**(observability). 업계에서 자리 잡고 있는 핵심 지표는 네 가지입니다. 루프율, 개입률(사람이 중간에 개입하거나 결과를 거절한 비율), 성공 작업당 비용, p95 지연시간. 이 지표가 대시보드에 없으면 에이전트는 관측 불가능한 블랙박스로 남습니다. **6. 롤백 기준.** 개입률이 어느 수준을 넘으면 기능을 비활성화할지, 어떤 에러 유형이 반복되면 이전 버전으로 복귀할지 정의합니다. 피처 플래그와 동일하게, 에이전트에도 언제든 끌 수 있는 스위치가 필요합니다. ## 현장에서 확인한 것 몇 해 전 RAG 기반의 음성 AI 서비스를 상용화하는 프로젝트에 참여한 적이 있습니다. 사용자 경험은 훌륭했지만, 단위 세션당 토큰 소모가 들쭉날쭉해서 수익성이 무너지는 상황이 반복되었습니다. 당시의 가장 아픈 교훈이 비용 상한의 부재였습니다. 그 시점부터 저희는 PRD에 "단위 작업당 허용 비용"을 기능 명세와 동등한 비중으로 쓰기 시작했고, 그 칸이 추가된 이후의 기능들은 출시 뒤에도 구조적으로 흔들리지 않았습니다. 또 한 번은 AI 도입 전후의 생산성 지표를 재정의하는 프로젝트를 맡은 적이 있었습니다. 도입 직후의 지표는 모두 긍정적으로 보였는데, 개입률이라는 축을 넣는 순간 그림이 달라졌습니다. 겉으로는 자동화 완료로 집계되던 작업의 상당수가 실제로는 사람이 중간에 반복 수정한 결과물이었습니다. 관찰 지표가 없었다면 저희는 존재하지 않는 성공을 축하하고 있었을 겁니다. 업계에서 공통 감각으로 자리 잡고 있는 기준선도 있습니다. 여러 에이전트 플랫폼과 운영 기록들이 제시하는 초기 목표는 총 개입률 10~15% 구간입니다. 금융처럼 규제 감수성이 높은 도메인은 95% 이상의 확신 구간을 요구하고, 헬스케어는 환자 안전 때문에 더 보수적으로 접근합니다. 중요한 것은 숫자 그 자체가 아니라, 우리 팀이 어떤 개입률을 감수할 수 있는가를 PRD에 써두는 일입니다. 한 가지 더 흥미로운 움직임은, 2025년 말 Google, OpenAI, Cursor, Sourcegraph, Factory가 공동으로 `AGENTS.md`라는 오픈 표준을 발표했다는 점입니다. 2,500개 이상의 저장소를 분석한 결과, 효과적인 에이전트 사양에는 여섯 개의 공통 영역이 반드시 필요하다고 이들은 결론지었습니다. 명령어, 테스트 기대치, 프로젝트 구조, 코드 스타일, git 워크플로우, 그리고 **명시적 경계**입니다. 산업 전체가 같은 언어로 수렴하고 있다는 신호입니다. ## 내일부터 할 수 있는 것 첫째, 기존 PRD 템플릿에 여섯 섹션을 추가합니다. 완벽할 필요는 없습니다. 비어 있는 칸이 있다면, 그 칸이 지금 팀의 위험 지점을 보여줍니다. 둘째, 개입률 대시보드를 엔지니어링 팀과 합의합니다. 이 지표가 없으면 에이전트의 성공과 실패를 사실상 측정할 수 없습니다. 셋째, "이 에이전트는 X를 하지 않는다"라는 부정 제약을 명시적으로 적습니다. 앞서 말했듯 에이전트는 생략된 것을 추론합니다. 명시적 "하지 말 것"이 있어야 합니다. 넷째, 로드맵을 "자율 수준의 업그레이드 경로"로 재구성합니다. v1은 제안만, v2는 승인 후 실행, v3는 자율 실행. 같은 기능의 같은 화면 안에서도 세 단계의 진화가 가능합니다. 다섯째, 피처 플래그처럼 에이전트 스위치를 확보합니다. 장애 상황에서 기능 전체를 끄지 않고 자율 수준만 낮춰 유지할 수 있어야 합니다. ## 결론 에이전트 PRD는 "더 많은 것을 쓰는 문서"가 아닙니다. 문서의 성격 자체가 바뀐 것입니다. 피처 명세가 아니라, 팀과 에이전트 사이의 운영 계약서에 가깝습니다. 무엇을 허용할지, 무엇을 금지할지, 실패를 어떻게 알아차릴지, 얼마까지 기꺼이 소모할지를 함께 정의합니다. 사이먼의 표현을 빌리면, PM은 이제 한 명의 사용자가 아니라 두 명의 사용자를 위해 환경을 설계하고 있는지도 모릅니다. 한 명은 여전히 인간이고, 또 한 명은 확률적이고 제한된 합리성을 가진 에이전트입니다. 여러분 팀의 PRD는 두 사용자 모두의 실패를 이미 설계하고 있습니까? 작은 실험 하나를 제안합니다. 이번 주 PRD의 마지막 장에 "실패 모드"라는 소제목 하나만 추가해보세요. 그 한 줄이 여는 대화가, 팀의 에이전트 제품이 프로덕션에서 살아남는 첫 번째 보호막이 될 것입니다. --- ## 참고 자료 - Herbert A. Simon, *Administrative Behavior: A Study of Decision-Making Processes in Administrative Organization* (Macmillan, 1947) - Raja Parasuraman, Thomas B. Sheridan, Christopher D. Wickens, "A Model for Types and Levels of Human Interaction with Automation," *IEEE Transactions on Systems, Man, and Cybernetics — Part A*, Vol. 30, No. 3 (2000) - Deloitte, *2026 State of Generative AI in the Enterprise* - AWS News Blog, "AWS Weekly Roundup: DevOps Agent & Security Agent GA, Product Lifecycle updates" (2026-04-06) - BizTech Magazine, "Google Cloud Next 2026: What To Expect With Agentic AI as a Major Theme" (2026-04) - Databricks, "What is Agentic AI?" - `AGENTS.md` Open Standard (Google, OpenAI, Cursor, Sourcegraph, Factory, 2025) - Microsoft Azure Blog, "Agent Factory: Top 5 Agent Observability Best Practices for Reliable AI" - Langchain Blog, "You Don't Know What Your Agent Will Do Until It's in Production"