프롬프트를 잘 쓰는 것은 2024년 역량입니다. 2026년에 요구되는 것은 에이전트가 안전하게 일을 끝낼 수 있도록 시스템을 설계·통제·검증하는 능력입니다. 지금 필요한 것은 새 도구 학습이 아니라, 오래된 관행의 해체입니다. AI를 “도구”로 쓰는 것과, AI가 “팀원”으로 일하는 환경을 설계하는 것은 완전히 다른 역량입니다.
이 편이 답하는 질문
- “프롬프트를 잘 쓰는 것 = AI 역량”이라는 2024년 믿음이 2026년 “에이전트 운영 환경 설계”로 전환되었다고 할 때, 기존 PM 조직에서 이 전환을 가로막는 가장 큰 조직 장벽은?
- 버려야 할 관행 3가지(“직접 작성 집착·프롬프트 우상화·사후 QA”)와 새로 익혀야 할 역량 5가지(“AgentOps·평가 설계·FinOps·AI 거버넌스·검증 중심 품질”)를 동시 도입했을 때, 어느 항목부터 조직 저항이 가장 크고 돌파 전략은?
- Definition of Done에 “AI 생성물 검증” 항목이 없다면 이미 “한 발 늦은 것”이라는 경고의 의미는 무엇이며, 현재 완료 기준에 이 항목을 추가하는 데 필요한 최소 체크리스트는?
- “에이전트에 어떤 권한을 주고, 어떤 범위에서 작동시키고, 어떻게 감시할지”를 설계하는 AgentOps가 미래 필수 역량이라면, 현재 조직의 에이전트 도입 현황에서 이 설계 부재로 인한 리스크는 어떻게 드러나는가?
이 시리즈를 읽는 세 개의 눈
SECTION 0 ══════════════ –>
- PO: 도구는 바뀌었는데 일하는 방식은 그대로인 팀은 AI 도입 후 검증·거버넌스·비용 부담이 더 늘어나므로, 조직 문화 변화에 경영진이 직접 스폰서십을 가져야 한다.
- PM: 버려야 할 관행(사후 검증)과 새로 익혀야 할 역량(생성 단계 검증)의 충돌이 가장 격심한 저항 지점이므로, 파일럿 팀부터 명시적으로 역할 재정의를 완료해야 한다.
- PL: Definition of Done의 검증 항목(근거·정확성·재현성·안전)이 없으면 코드 리뷰·품질 관리 책임 경계가 불명확해져 나중에 디버깅 비용이 기하급수적으로 증가한다.
들어가며
더 이상 “AI를 잘 쓰는 PM”이 아닙니다
솔직히 말씀드리면, 저도 1년 전까지는 “AI 도구를 잘 활용하는 PM”이 경쟁력이라고 생각했습니다. 삼성·LG·SK·KT·현대모비스 등 15년간 PM 코칭을 하면서, 워크숍마다 “ChatGPT로 요구사항 분석하기”, “Claude로 리스크 레지스터 자동 생성하기” 같은 세션을 넣었습니다. 반응은 좋았고, 수강생들은 “신세계”라고 했습니다.
그런데 2026년 1분기를 지나면서 분명히 보였습니다. 도구를 잘 다루는 것과, 에이전트가 실제로 일하는 환경 전체를 설계하는 것은 완전히 다른 차원의 역량이라는 것을.
Jensen Huang은 GTC 2026에서 “추론의 변곡점이 도래했다”고 선언했습니다. OpenAI와 AWS는 에이전트가 메모리를 갖고, 도구를 쓰고, 장기 작업을 수행하는 “Stateful Runtime”을 발표했습니다. Microsoft는 Copilot을 “통제 가능한 에이전트 시스템”으로 재정의했습니다. GitHub Copilot은 이슈 하나를 받아 코드를 쓰고, 테스트하고, PR을 올리는 “코딩 에이전트”가 됐습니다.
이건 도구 업데이트가 아닙니다. PM·PL의 역할 정의 자체가 바뀌는 전환점입니다.
이 글이 말하는 것: 새로운 AI 도구를 어떻게 쓰는지가 아니라, 지금까지 해온 방식 중 무엇을 버려야 하는지, 그리고 무엇을 새로 훈련해야 하는지를 다룹니다. 순서가 중요합니다. 비울 곳을 만들어야 채울 수 있습니다.
Part 1
버려야 할 관행 3가지
새로운 역량을 이야기하기 전에, 먼저 버려야 할 것을 명확히 해야 합니다. 15년간 PM 현장에서 “당연히 해야 할 일”로 여겨졌지만, 에이전틱 AI 시대에는 오히려 발목을 잡는 관행들입니다.관행 1 — “모든 산출물을 직접 작성한다”
주간 보고서, 현황 대시보드, 회의록, 백로그 초안, 스프레드시트 정리 — 이것들을 PM이 직접 작성하는 데 시간을 쓰고 있다면, 그 시간은 이미 낭비입니다. GPT‑5.4는 스프레드시트와 프레젠테이션을 직접 생성합니다. Claude는 Excel·PowerPoint 컨텍스트를 공유하며 연속 작업을 수행합니다. GitHub Copilot은 이슈 코멘트 하나로 코드를 쓰고 PR을 만듭니다. 이 도구들은 1년 전에도 존재했지만, 지금은 프로덕션 수준의 품질로 올라왔습니다.
버려야 할 믿음: “내가 직접 만들어야 정확하다.”
대신 훈련할 것: AI가 만든 산출물을 3분 안에 검증하고 방향을 잡는 능력.
관행 2 — “프롬프트를 잘 쓰면 된다”
“프롬프트 엔지니어링”이라는 말이 유행한 지 2년이 됐습니다. 하지만 2026년의 AI는 프롬프트 하나로 움직이는 챗봇이 아닙니다. 에이전트는 메모리를 갖습니다. 도구를 호출합니다. 파일을 읽고 씁니다. 장시간 작업을 수행합니다. 실패하면 재시도합니다. 이 모든 것을 “프롬프트 잘 쓰기”로 통제할 수 없습니다. OpenAI·AWS의 Stateful Runtime, Microsoft Foundry Agent Service, Anthropic의 Cowork가 모두 “에이전트 운영 환경”을 제품으로 출시한 것은 우연이 아닙니다. 에이전트를 다루는 단위가 프롬프트 → 운영 시스템으로 바뀐 것입니다.
버려야 할 등식: “프롬프트 스킬 = AI 역량”
대신 필요한 것: 에이전트에게 어떤 권한을 주고, 어떤 범위에서 작동시키고, 어떻게 감시할지를 설계하는 능력.
관행 3 — “품질은 QA 단계에서 잡는다”
전통적 PM에서 품질 관리는 “만들고 나서 검수”였습니다. 하지만 AI가 코드를 쓰고, 문서를 만들고, 분석을 수행하는 환경에서 “만든 후 검수”는 이미 늦습니다. 현장에서 이미 반복되는 패턴이 있습니다. 법률 분야에서는 AI가 실제로 존재하지 않는 허위 판례를 자신감 있게 제시합니다. 헬스케어에서는 AI 환각이 오진으로 이어질 수 있습니다. 소프트웨어 개발에서는 AI가 코드를 빠르게 만들어주는 만큼, 리뷰와 검증의 부담이 함께 급증했습니다. 2025년 GitHub 공개 저장소에서 신규 하드코딩 시크릿이 2,865만 건 이상 늘어난 것도 같은 맥락입니다.
버려야 할 방식: “만들고 나서 검수”하는 순차적 품질 관리.
대신 필요한 것: 생성 단계부터 평가 기준을 내장하는 설계. Definition of Done에 “AI 생성물 검증” 항목이 없다면 이미 한 발 늦은 것입니다.
도구는 바뀌었는데 일하는 방식은 그대로인 팀은, AI 도입 후 오히려 검증·거버넌스·비용 부담이 더 늘어납니다. 비울 곳을 먼저 만들어야 새 역량이 들어올 수 있습니다.
Part 2
새로 익혀야 할 역량 5가지
버릴 것을 버렸으면, 채울 것을 채워야 합니다. 아래 5가지 역량은 “있으면 좋은 것”이 아닙니다. 에이전트 기반 제품을 다루는 PM·PL이라면 지금 당장 훈련을 시작해야 할 필수 역량입니다.역량 1 — AgentOps 설계
“기능 명세”를 넘어 “운영 명세”를 쓰는 능력입니다. 에이전트 프로젝트의 PRD에는 기존과 다른 항목이 들어가야 합니다.- 상태 관리 — 에이전트가 무엇을 기억하고, 언제 잊는가. 세션 간 컨텍스트는 어디까지 유지하는가
- 권한 경계 — 어떤 데이터와 시스템에 접근 가능한가. 접근 불가 범위는 명확히 정의됐는가
- 관측가능성 — 에이전트가 무엇을 했는지 어떻게 확인하는가. 로그와 감사 기록은 어디에 남는가
- 실패 모드 — 장기 작업 중 중단되면 어떻게 복구하는가. 재시도 조건은 무엇인가
- 승인 워크플로 — 어떤 행동은 반드시 사람이 확인해야 하는가. 자동 실행과 인간 판단의 경계선
현장 패턴: 이 항목들이 빠진 에이전트 프로젝트는 “프로토타입은 되지만 프로덕션은 안 되는” 전형적 실패 패턴에 빠집니다. Microsoft Foundry Agent Service가 “보안·컴플라이언스·평가”를 GA의 핵심으로 내세운 이유가 여기 있습니다.
역량 2 — 평가 설계 (Eval Design)
에이전트 출력을 “좋다·나쁘다”로 판단하는 것이 아니라, 정확성·근거·재현성·안전을 수용 기준으로 구체화하는 능력입니다.- 정확성 기준 — 어떤 출력이 “맞다”인가를 테스트 케이스로 정의
- 근거 추적 — 에이전트가 내린 판단의 출처를 확인할 수 있는가
- 회귀 테스트 — 기능 업데이트 후에도 이전 정답이 유지되는가
- 가드레일 — 어떤 출력이 절대 있어서는 안 되는가를 명시적으로 정의
역량 3 — AI 비용 관리 (FinOps)
Flash‑Lite, mini, nano — 모델이 계층화됐습니다. 같은 작업을 비싼 모델에 시키면 정확하지만 느리고 비쌉니다. 싼 모델에 시키면 빠르지만 품질이 떨어질 수 있습니다. 이 배분을 설계하는 것이 PM의 역할이 됐습니다.- 작업별 모델 배치 — 단순 실행·요약은 소형 모델, 복잡한 추론·판단은 대형 모델
- 비용 SLO — 기능별 토큰 예산과 지연 허용 범위를 PI 계획에 포함
- 캐싱 전략 — 반복 요청에 캐시를 적용해 실효 비용 최소화
역량 4 — AI 거버넌스
EU AI Act의 단계 적용이 2026~2027년에 걸쳐 진행됩니다. 딥페이크 규제, 저작권 소송, 민감정보 처리 문제가 동시에 터지고 있습니다. xAI 관련 미성년자 피해 소송, AI 가사 학습 저작권 소송이 실제 비즈니스 리스크로 전환된 사례들입니다. 이건 “법무팀 일”이 아닙니다. 에이전트가 어떤 데이터를 사용하는지, 생성물에 어떤 리스크가 있는지, 규제 일정에 맞춰 어떤 준비가 필요한지 — 이것들을 PM이 기능 로드맵과 병렬로 관리해야 합니다.
역할 변화: 보안·법무·감사 조직이 “사후 승인자”가 아니라 PM의 “공동 설계자”가 되는 시대입니다. 기능 기획 초반부터 이들을 참여시키지 않으면, 출시 직전에 전면 수정이 발생합니다.
역량 5 — 검증 중심 품질 관리
앞서 “버려야 할 관행”에서 말씀드린 것의 실질적 대안입니다. AI가 생산성을 높이는 것은 사실이지만, 동시에 검증 부담도 높입니다. 팀당 평균 4개 AI 도구를 쓰는 환경에서, 누가 무슨 도구로 뭘 만들었는지조차 파악하기 어렵습니다. 이 혼란을 방치하면 “AI를 썼는데 더 힘들어진” 역설이 발생합니다.- DoD에 AI 검증 항목 추가 — 정확성, 근거 출처, 재현성, 엣지케이스를 수용 기준에 명시
- 도구 기준 문서화 — 어떤 AI 도구를 어떤 작업에 쓰고, 어떤 작업에는 쓰지 않는지 팀 합의
- 자동화/인간 판단 구간 분리 — 에이전트가 처리할 구간과 사람이 반드시 확인할 구간을 명확히 선 긋기
Part 3
PM·PL의 시간은 어디로 가야 하는가
AI가 반복 업무를 처리해주면서, PM·PL에게 “빈 시간”이 생깁니다. 그 시간을 어디에 쓸 것인가가 핵심입니다. 이것을 의식적으로 설계하지 않으면, 새로 생긴 시간이 또 다른 반복 업무로 채워질 뿐입니다.
PM의 가치는 “산출물을 만드는 것”에서 “에이전트가 안전하게 성과를 내도록 시스템을 설계·통제·검증하는 것”으로 이동했습니다.
Part 4 · 실전 적용
워크숍에서 바로 쓸 수 있는 5가지 토픽
현장에서 PM·PL 교육을 설계하시는 분들을 위해, 지금 당장 커리큘럼에 넣을 수 있는 토픽을 정리했습니다. 각 토픽은 강의가 아니라 실습 중심으로 설계해야 효과가 있습니다.마무리
관행을 버리는 용기
15년 PM 코칭을 하면서, 가장 어려운 순간은 항상 “잘 해오던 방식을 바꿔야 할 때”였습니다. PMBOK을 완벽하게 따르던 팀이 Agile로 전환할 때, Waterfall로 성공해본 PM이 Scrum을 받아들일 때. 저항은 언제나 “이게 왜 필요한가”가 아니라 “지금까지는 잘 됐는데”에서 왔습니다.
지금이 바로 그 순간입니다.
“문서를 잘 쓰는 PM”에서 “에이전트 시스템을 설계하는 PM”으로. “프롬프트를 잘 쓰는 역량”에서 “운영·비용·거버넌스·평가를 통합 관리하는 역량”으로.
기존 관행을 하나씩 내려놓는 과정이 쉽지 않다는 것을 압니다. 하지만 PM·PL이라는 역할이 대체되는 것이 아닙니다. 재정의되는 것입니다.
에이전트가 아무리 똑똑해져도, 다음 질문에 답하는 사람은 여전히 PM·PL입니다.
- 이 에이전트에게 어떤 권한을 줄 것인가
- 실패하면 어떻게 복구할 것인가
- 비용이 이 범위를 넘으면 어떻게 할 것인가
- 이 산출물을 신뢰하기 위해 무엇을 확인해야 하는가
이 질문들에 답할 수 있는 역량을, 지금 당장 훈련해야 합니다.Agentic PO·PM·PL Officer · 역량 전환 시리즈 · 2026 Q1 Report
함께 읽기 · Related Posts
시리즈 네트워크에서 이 편과 연결된 글
- B-2 · PM/PL 역할 전환
AI 시대, PO·PM·PL과 사무직의 역할이 근본부터 바뀐다 - B-4 · PM/PL 역할 전환
AI 시대의 PMBOK 8판 훈련 전략 - B-5 · PM/PL 역할 전환
Agentic 시대, PM/PL과 엔지니어는 무엇을 준비해야 하는가 - P-11 · AI 인물 탐구
Agentic 시대 PO·PM·PL 5-Domain 역량 통합편 - K-4 · 사고 체계
Karpathy: AI의 사고 체계를 PM에 어떻게 적용할까? - X-1 · AX 전략
AI/AX 2030 전략: McKinsey, BCG, Accenture, Deloitte, Gartner 교차 분석
M · 진입 가이드 (Tier 0 · NEW)
D · 역할 번역 (Tier 0 · NEW)
E · 조직 전환 (Tier 0 · NEW)
AX 전략
현장 검증
PM/PL 역할 전환
사고 체계
AI 인물 탐구
- P-0 7인의 사고 체계 종합 프레임워크
- P-1 Karpathy: 제약 설계 + 닫힌 루프
- P-2 Sutskever: 압축이 곧 지능이다
- P-3 Hassabis: 제1원리 분해
- P-4 LeCun: 세계 모델 + 예측
- P-5 Hinton: 거버넌스 + 자기부정
- P-6 Ng: AI 전환 플레이북
- P-7 Fei-Fei Li: 인간중심 설계
- P-8 Builders 종합: Boris·Cat·Truell·Masad·Murati·Brockman
- P-9 Operators 종합: Altman·Amodei·Nadella·Pichai·Zuckerberg·Suleyman
- P-10 Hardware 양강: Jensen Huang · Lisa Su
- P-11 PO·PM·PL 역량 통합: 5-Domain × 3-Level
실전 도구