PMBOK 시대의 관리자가 아니라, 루프를 설계하는 엔지니어로 — Claude Code 본체 1,903파일을 7개의 관점으로 교차 분석해 추출한 5가지 관점 전환과, PM/PL이 월요일 아침부터 적용 가능한 5가지 실전 액션 + 템플릿.
- “프롬프트 엔지니어링의 본질은 좋은 문장이 아니라 instruction composition + orchestration protocol + verification discipline”이라는 Karpathy의 명제에서, PM이 직접 설계할 수 있는 verification discipline의 구체적 형태는?
- Claude Code와 Hermes의 공통점인 “승인이 binary가 아닌 3단계 이상” 구조가, 전통적 Go/No-Go 의사결정을 어떻게 재설계해야 하는가?
- “메모리를 한 덩어리가 아닌 코어·검색형·외부 제공자형으로 분리”라는 3-Tier Memory 구조에서, PM은 각 계층의 크기 상한·적중률·갱신 규칙을 어떤 기준으로 결정하는가?
- Karpathy LLM OS 비유와 Claude Code 실체의 1:1 매핑을 통해, 조직이 현재 적용 중인 프롬프팅 방식의 어떤 부분이 “정책이 아닌 우연”인지 진단하고 코드 수준 규칙으로 고정하는 프로세스는?
- PO: 승인 프로세스를 “통과/불통과”에서 “진행→조건부진행→재작업→통과”의 4단계로 재설계하고, 각 상태에서의 성공 조건을 명시적으로 기술. 모호한 요구는 AI 시대 최대 리스크다.
- PM: 3-Tier Memory에서 “코어 메모리”는 PM 의도, “검색형”은 컨텍스트, “외부 제공자형”은 신규 학습 데이터. 각 계층의 drift와 비용을 분기마다 감시해야 한다.
- PL: Verification Gate는 완료 “후”가 아닌 “전”에 배치. 이는 테스트 통과 = 배포라는 신념의 근본 전환. 폴백 전략·오류 추적·성능 저하점을 사전에 코드로 명시해야 한다.
PM의 본업이 바뀌고 있습니다
2026년 4월, 저는 이틀에 걸쳐 Claude Code 본체 snapshot(약 1,903개 파일, TypeScript 1,884개)을 일부러 서로 다른 7개의 관찰 각도에서 분석했습니다. 한 각도만으로는 “잘 만든 에이전트 CLI구나” 수준의 인상에 머물지만, 7개의 렌즈를 겹쳐 보면 어떤 각도에서도 반복되는 구조가 선명해지기 때문입니다. 그 교집합이 바로 AX(AI Transformation) 시대의 PM/PL이 새롭게 익혀야 할 본업이었습니다.
10년간 PM 코치로 일하면서 저는 “Scope·Schedule·Cost가 가장 어렵다”고 가르쳐 왔습니다. 그러나 Claude Code 7개 리포트를 정리하며 분명해진 점이 하나 있습니다 — 이 세 축으로는 “우리 에이전트가 왜 갑자기 답을 못 만드는가?”라는 질문에 답할 수 없습니다. 그 자리에는 “어떤 prompt precedence 계약이 깨졌는가?”, “어느 memory tier에서 누수가 났는가?”, “어느 defense layer가 우회됐는가?”라는 새로운 질문들이 들어와야 합니다. 이 질문들을 다루는 언어가 곧 AX PM/PL의 새로운 기본기입니다.
그리고 흥미롭게도, 그 새로운 언어는 Andrej Karpathy가 오래전부터 강조해 온 “Software 2.0”, “Intuition Engineer”, “LLM OS”라는 세 개의 비유와 거의 일대일로 맞물렸습니다. 본 글은 그 매핑과 5가지 관점 전환, 그리고 월요일부터 시작할 수 있는 5가지 실전 액션을 정리한 백서 스타일 분석입니다.
- Karpathy의 “Intuition Engineer / LLM OS” 비유는 PM/PL 역량과 어떻게 연결되는가?
- 관리적 사고(scope/schedule/cost)에서 AX 문제해결 사고로 넘어가려면 무엇을 새로 배워야 하는가?
- “확장적 사고”는 구체적으로 어떤 아키텍처 언어(control plane, capability plane, data plane)로 표현되는가?
- AI에 익숙하지 않은 PM/PL이 내일부터 시작할 수 있는 최소 실행 단위는 무엇인가?
- Karpathy의 “LLM OS” 비유는 AX PM/PL의 업무 언어가 통제에서 시스템 설계로 바뀐다는 선언과 같습니다.
- 프롬프트 엔지니어링의 본질은 좋은 문장 작성이 아니라 instruction composition + orchestration protocol + verification discipline입니다.
- PMBOK 방식의 Scope-Schedule-Cost 삼각형은 사라지지 않지만, 그 위에 컨텍스트 엔지니어링·관측가능성·평가 루프라는 새로운 세 축이 더해져야 합니다.
- 운영 수치가 관점 전환의 필요성을 증명합니다. 내부 shadow 측정에서 empty selection rate는 31.82%에서 6.67%로, multi-pack rate는 10.23%에서 36.67%로 개선되었습니다.
- 확장적 사고는 “더 많은 프롬프트 팩”이 아니라 control plane vs capability plane의 분리와 그 사이의 evidence ledger로 구현됩니다.
- PM/PL은 이제 Charter를 쓰는 사람이기 이전에 precedence 계약, 3-tier 메모리, 다층 방어선, eval harness를 설계하는 사람이 되어야 합니다.
왜 지금 이 질문인가 — 7개 관찰 각도가 같은 곳을 가리킵니다
저는 이 분석을 시작할 때 “어차피 한 시스템을 한 번 보면 충분하지 않나?”라는 의심을 가졌습니다. 그러나 7개의 서로 다른 렌즈로 같은 코드베이스를 비추면, 한 렌즈로는 절대 보이지 않는 구조적 교집합이 드러납니다. 그 교집합이 이 글의 본론입니다.
1.1. 7개 관찰 각도 — 렌즈를 왜 7번 바꿨는가
1.2. 7개 각도가 교차한 4가지 공통 관찰
7개의 렌즈가 각기 다른 질문을 던졌음에도 교집합으로 수렴한 관찰은 다음과 같습니다.
- 시스템 프롬프트는 문장이 아니라 “instruction precedence contract”입니다. Claude Code의 시스템 프롬프트는
override → coordinator → agent → custom → default (+ append)라는 우선순위 계약을 코드 수준에서 고정하고 있었습니다. - 세션 transcript는 로그가 아니라 core state입니다. Session persistence 모듈은 5,105줄 규모이고, JSONL + idempotent append + Last-Uuid optimistic concurrency로 resume/replay/branching의 기반이 됩니다.
- 캐시 관리는 token 비용 최적화의 제1축입니다. 캐시 브레이크 탐지 전용 모듈만 727줄이고, “tool description 변화가 cache break의 77%를 차지한다”는 주석이 붙어 있습니다.
- 관측(telemetry)만으로는 개선되지 않습니다. Claude Code는 로깅·feature flag·analytics sink는 강하지만, LLM-as-Judge 기반 regression eval loop는 비어 있다는 분석이 반복됐습니다.
이 4개의 관찰이 동시에 가리키는 것은 분명합니다 — “PM이 관리라는 단어를 쓰는 방식 자체가 낡았다”는 사실입니다. Scope change, schedule slip, cost overrun이라는 세 축으로는 위 4가지 관찰 중 단 하나도 설명할 수 없습니다. AX 시대의 PM 언어는 precedence·session·cache·eval이라는 새로운 4축에서 다시 태어나야 합니다.
Karpathy 역량과의 상관관계 — “LLM OS”라는 공용 비유
Andrej Karpathy는 2020년대 초반부터 세 가지 은유를 연결해 왔습니다. “Software 2.0”(코드 대신 weights가 아티팩트가 된다), “Intuition Engineer”(미세 조정의 감각을 가진 사람이 새로운 엔지니어 유형이다), 그리고 가장 유명한 “LLM OS”(LLM을 CPU로, 컨텍스트 윈도우를 RAM으로, 툴을 system call로, 파일을 session transcript로 보는 운영체제 비유)입니다.
이 비유는 단순한 수사가 아니라 AX PM/PL이 어디에 주의를 기울여야 하는지 가리키는 지도입니다. Claude Code의 실제 모듈 이름과 Karpathy 비유를 맞추어 보면 거의 1:1로 대응됩니다.
2.1. LLM OS 비유 vs Claude Code 실체 — 1:1 매핑
Karpathy가 말한 “Intuition Engineer”는 문장을 잘 쓰는 사람이 아니라, 이 테이블의 각 계층이 무엇을 보장하고 무엇을 보장하지 않는지 직감적으로 아는 사람입니다. 그리고 그 직감은 Claude Code 소스에서 관찰된 “instruction precedence contract”, “idempotent append chain”, “cache break detection”과 같은 구체적 설계 결정으로 외부화되어 있습니다.
“프롬프트 엔지니어링의 본질은 좋은 문장 작성이 아니라 instruction composition + orchestration protocol + verification discipline이다.”
이 문장을 Karpathy 비유로 번역하면 이렇게 됩니다. “Intuition Engineer는 사실 OS 커널 설계자의 감각으로 프롬프트와 툴을 다룹니다.” PM/PL이 vibe coding 시대에 살아남는 길은, “분위기로 프롬프트를 쓰는 것”이 아니라 “분위기처럼 느껴질 만큼 정교한 precedence·memory·defense 레이어를 설계하는 것”입니다.
2.2. Karpathy 역량 3축과 PM/PL 대응 역량
AI 입문 PM/PL을 위한 용어 사전 — LLM OS 비유로 풀어 쓰는 5가지 키워드
Part 4에서 본격적으로 다룰 5가지 관점 전환은 용어 자체가 AI 입문자에게 낯설 수 있습니다. 다행히 Karpathy의 “LLM OS” 비유가 매우 직관적이기 때문에, 같은 렌즈로 각 키워드를 “쉬운 정의 + LLM OS 비유 + 일상 비유 + PM이 할 일”의 4단 구조로 풀어 보겠습니다.
3.1. Precedence as Code — “규칙의 우선순위를 문서가 아닌 자물쇠로 건다”
- 쉬운 정의: 여러 개의 지시문(시스템 프롬프트, 코디네이터 프롬프트, 사용자 프롬프트, 툴 설명 등)이 충돌할 때 누구 말이 이기는지를 코드 레벨에서 고정해 둔 규칙입니다.
- LLM OS 비유: OS 부팅 시 BIOS는 바꿀 수 없지만 사용자 앱은 그 BIOS 규칙 안에서만 동작합니다. “BIOS > OS 커널 > 사용자 앱”이라는 순서가 깨지면 컴퓨터가 부팅되지 않습니다. Precedence as Code는 이 순서를 주석이 아니라 실행 규칙으로 만들어 둔 것입니다.
- 일상 비유: 회사에서 “사장님 결재 > 본부장 결재 > 팀장 결재”라는 순서가 HR 시스템에 코드로 박혀 있어서, 팀장이 아무리 급해도 사장님 결재 없이는 결재창이 열리지 않는 상태와 같습니다.
- PM이 할 일: “우리 프롬프트 우선순위가 뭐죠?”라는 질문에 문서가 아니라 실행 규칙 파일을 열어 답변할 수 있어야 합니다.
3.2. Session = Core State — “세션은 기록이 아니라 되감기 가능한 상태다”
- 쉬운 정의: LLM 에이전트가 남기는 세션 transcript를 단순한 로그가 아니라 언제든 그 순간으로 되감아 재실행할 수 있는 상태 저장소로 취급하는 관점입니다.
- LLM OS 비유: 전통 OS에서 파일시스템이 단순한 저장소가 아니라 프로세스가 언제든 다시 올라올 수 있는 체크포인트인 것과 같습니다. 재부팅 후에도 워드 문서가 열려 있던 자리로 돌아가는 것처럼 말이죠.
- 일상 비유: 게임의 “세이브 파일”입니다. 단순 플레이 기록이 아니라, 그 시점부터 다시 시작할 수 있어야 합니다.
- PM이 할 일: “재개 불가”를 버그가 아니라 incident 카테고리로 격상시키고, 세이브 포인트 품질을 KPI로 봅니다.
3.3. 3-Tier Memory — “기억을 쌓지 말고, 꺼내는 비용으로 설계한다”
- 쉬운 정의: 에이전트의 기억을 하나의 큰 저장소가 아니라 항상 붙는 코어 / 필요할 때 검색하는 중간층 / 외부 의미 검색 프로바이더의 3단계로 나누어 설계하는 방식입니다.
- LLM OS 비유: 전통 OS의 CPU 레지스터 > L1~L3 캐시 > RAM > SSD > 네트워크 스토리지 계층과 완전히 동일한 사고입니다. 가까울수록 빠르지만 작고, 멀수록 크지만 느립니다.
- 일상 비유: 사람의 기억도 “항상 떠올릴 수 있는 단기 기억 / 노트 뒤져서 찾는 중기 기억 / 책장 뒤져서 찾는 장기 기억”으로 나뉩니다. 모든 기억을 매번 책장에서 뽑아 쓰려 하면 일상이 마비됩니다.
- PM이 할 일: 각 티어마다 latency / recall / 운영 비용이라는 서로 다른 SLA를 부여합니다.
3.4. Verification Gate — “완료는 검증 통과로만 정의된다”
- 쉬운 정의: 작업이 “끝났다”라고 주장하는 시점을 검증이 통과한 순간으로만 인정하는 운영 규칙입니다. 검증이 별도 단계가 아니라 완료의 정의 자체가 됩니다.
- LLM OS 비유: OS의 파일 저장 연산은 “디스크에 썼다”가 아니라 “fsync가 OK를 반환했을 때”만 성공으로 처리합니다. 전기가 나가도 데이터가 남아야 하기 때문입니다.
- 일상 비유: 택배가 “발송 완료”가 아니라 수령인 서명 확인 후에야 “배송 완료”로 처리되는 것과 같습니다.
- PM이 할 일: result/진행 문서에 “done”이라는 상태를 지우고 “verified”로 바꿉니다. 증거 없는 완료 선언을 금지합니다.
3.5. Telemetry ≠ Eval — “관측은 충분조건이 아니다, 평가 루프가 따로 있어야 한다”
- 쉬운 정의: 로그·대시보드·이벤트 스트림(telemetry)을 아무리 잘 쌓아도, 정해진 기준으로 정량 점수를 매기는 평가 루프(eval)가 없으면 회귀(regression)를 막을 수 없다는 원칙입니다.
- LLM OS 비유: OS는 syslog만 남기는 것이 아니라 단위 테스트·integration 테스트·benchmark suite를 따로 돌려서 커널 회귀를 잡아냅니다. Telemetry는 syslog, eval은 테스트 스위트에 해당합니다.
- 일상 비유: 병원에서 매일 체온·혈압을 기록하는 것만으로는 병을 진단할 수 없습니다. 정기 건강검진 프로토콜이 따로 있어야 “작년 대비 악화됐다”를 말할 수 있습니다.
- PM이 할 일: 대시보드 구축 뒤에 “이 숫자가 악화되면 자동으로 배포가 멈춘다”는 규칙을 만듭니다. 이것이 없으면 관측은 장식입니다.
이 5개는 독립적인 개념이 아니라 하나의 운영 루프를 이룹니다. Precedence가 고정돼야 Session이 재현 가능해지고, Session이 Core State여야 3-Tier Memory가 의미 있고, Memory가 계층화돼야 Verification Gate가 통과 기준을 정의할 수 있고, Verification이 정의돼야 Telemetry의 숫자가 비로소 Eval로 승격될 수 있습니다. 하나만 빼놓으면 나머지도 작동하지 않습니다. 이것이 제가 “더 많은 프롬프트 팩”이 아니라 루프 설계라고 강조하는 이유입니다.
관리적 사고에서 AX 문제해결 사고로 — 5가지 관점 전환
7개 리포트가 교차 수렴한 5가지 주제는, 그대로 PM/PL이 새로 배워야 할 AX 문제해결 역량이 됩니다. 각 전환마다 이전/새로운 관점 + 근거 + PM 할 일 + 업무 예시 대화 + 체크리스트를 함께 드리니, 본인의 조직 상황에 그대로 대입해 보시면 됩니다.
전환 1. Instruction Precedence를 코드 수준으로 고정
- 이전 관점: “프롬프트는 문서고, 필요하면 수정한다.”
- 새로운 관점: “프롬프트는 계약이고, precedence는 runtime rule이다.”
- 근거: Claude Code의 시스템 프롬프트 모듈은 override → coordinator → agent → custom → default(+append) 순서를 명시적 우선순위 계약으로 못박고 있습니다.
- PM 할 일: Prompt precedence 규칙표를 문서가 아니라 배포 파이프라인의 일부로 만듭니다. 승인 없이 precedence가 바뀌면 배포가 실패하도록 설계합니다.
엔지니어 A: “이번 주말에 시스템 프롬프트 살짝 손봤어요. 답변이 좀 더 공손해졌을 거예요. 테스트도 통과했습니다.”
AX PM: “좋아요. 확인 한 가지만 할게요 — 어느 레이어를 고쳤어요? override? coordinator? 아니면 append?”
엔지니어 A: “음… append였던 것 같아요.”
AX PM: “그러면 precedence 규칙표는 안 바뀐 거죠? 규칙표 자체를 건드리지 않았다면 그대로 배포 가능해요. 만약 override나 coordinator를 고쳤다면 승인 워크플로우를 먼저 타야 해요. 지금 PR에 어느 레이어인지 명시해 주세요, 그게 없으면 리뷰어가 판단을 못 해요.”
핵심 전환점: “프롬프트 수정했어요”라는 문장에 PM이 “precedence 규칙표가 바뀌었나요?”로 응답하기 시작하는 순간이 AX PM 전환의 첫 신호입니다.
- 현재 운영 중인 프롬프트의 레이어 계층표(override / coordinator / agent / custom / default / append)가 한 장짜리 파일로 존재하는가?
- 프롬프트를 수정하는 모든 PR은 어느 레이어를 건드렸는지 한 줄 이상 명시하고 있는가?
- Precedence 규칙 파일 자체를 수정하는 PR에는 지정된 승인자가 있는가?
- 배포 스크립트에 precedence 순서가 깨지면 배포를 중단하는 자동 검증이 포함돼 있는가?
- “긴급이니까 precedence 계약을 우회하자”는 요청이 들어왔을 때 공식 예외 경로가 있는가?
전환 2. Session = 로그가 아니라 Core State
- 이전 관점: “세션 로그는 디버깅용이다.”
- 새로운 관점: “세션 transcript는 resume/replay/branching/later-analysis의 기반 구조다.”
- 근거: Claude Code session persistence 모듈 5,105줄 + JSONL idempotent append + Last-Uuid 기반 optimistic concurrency가 resume/replay/branching의 기반 데이터 구조를 형성합니다.
- PM 할 일: 세션 재개 불가 상태를 incident로 분류합니다. “로그 남겼으니 괜찮다”가 아니라 “중단 시점에서 다시 시작 가능한가?”를 KPI로 삼습니다.
고객지원팀: “어제 오후 3시에 세션이 멈춰서 사용자가 처음부터 다시 시작해야 했어요. 화면 새로고침으로 해결은 했는데요…”
전통 PM: “로그 확인해서 어느 API에서 끊겼는지 찾아보죠.”
AX PM: “잠깐요. 그건 incident로 등록해야 합니다. 저희 incident 카테고리에 ‘세션 재개 불가’가 있거든요. 로그 확인은 원인 분석이고, 사용자가 중단 시점부터 이어서 할 수 있었는지 여부가 저희가 KPI로 추적하는 지표입니다. 재개 가능했으면 minor incident, 불가능했으면 major incident예요.”
핵심 전환점: “로그를 본다”에서 “재개 가능성을 본다”로 질문이 이동하는 순간입니다.
- “세션 재개 불가”가 공식 incident 카테고리로 등록돼 있는가?
- 세션 transcript는 append-only로 저장되며, 중간 편집/삭제가 불가능한가?
- 각 세션에는 고유 식별자(session_id, last_uuid 등)가 붙어 재개 지점을 특정할 수 있는가?
- 최근 30일 기준 재개 불가 발생 건수를 숫자 1개로 말할 수 있는가?
- Replay(재현) 테스트가 stage 환경에서 정기적으로 실행되는가?
전환 3. 3-Tier Memory — 기억을 모으지 말고 꺼내기 비용으로 설계
- 이전 관점: “많이 기억할수록 좋다(큰 context, 긴 history, 풍부한 RAG).”
- 새로운 관점: “기억은 latency/correctness 트레이드오프를 가진 계층이다.”
- 근거: Claude Code + Hermes + Codex 모두에서 3-tier memory가 관찰됩니다. Bounded core(MEMORY.md + USER.md 등 항상 붙는 메모리), Searchable(FTS5 session search), Canonical / provider(외부 semantic provider)의 3단 구조입니다.
- PM 할 일: 메모리 티어마다 다른 SLA를 정의합니다. Bounded = “100% 적중”, Searchable = “recall > 80%”, Canonical = “drift 검출 시 경고”. 모든 기억을 동일하게 관리하는 순간 latency와 correctness가 동시에 망가집니다.
기획자: “에이전트가 사용자 이름도 가끔 잊어버리고, 과거 대화 내용도 못 찾아요. RAG 강화하면 해결되지 않을까요?”
전통 PM: “그럼 vector DB 용량 늘리고 retrieval 파라미터 튜닝해 봅시다.”
AX PM: “잠깐요. 두 문제는 다른 티어의 문제입니다. 사용자 이름은 bounded core에 있어야 하는데 거기서 누락된 거라면 RAG를 아무리 고쳐도 못 찾아요. 과거 대화 내용은 searchable tier의 recall 문제고, 이건 FTS5 인덱스나 search 파라미터를 봐야 해요. 그리고 ‘지난번 계약서 어디 있었지?’ 같은 외부 문서 참조는 canonical tier(semantic provider)의 문제예요. 세 개 SLA를 먼저 나눠서 각각 측정해 주세요.”
핵심 전환점: “메모리 문제”라는 단일어를 PM이 3개 티어로 분해해 되묻기 시작하는 순간입니다.
- 현재 “메모리”라고 부르는 구성요소가 bounded / searchable / canonical 중 어디에 속하는지 모두 분류돼 있는가?
- 각 티어에 별도의 SLA(latency·recall·비용)가 부여돼 있는가?
- Bounded core는 토큰 상한선이 정해져 있고, 넘을 때 어떤 eviction 정책이 적용되는지 문서화돼 있는가?
- Searchable tier의 recall 지표가 주간/월간 대시보드에 포함돼 있는가?
- Canonical tier에서 drift가 발생했을 때 자동 경고가 울리는가?
전환 4. Verification을 완료 전(前) 게이트로
- 이전 관점: “품질 검토는 완료 후 QA에서 한다.”
- 새로운 관점: “완료는 검증 통과로 정의한다.”
- 근거: Claude Code coordinator protocol은 research → synthesis → implementation → verification을 별도 phase로 분리합니다. PMBOK v33 사고 가이드도 “검증 없는 완료 선언을 금지”라는 규칙을 포함합니다.
- PM 할 일: “done”이라는 상태를 없애고 “verified”로 교체합니다. result 문서에 실제 내용과 evidence를 반드시 채우게 하는 정책도 같은 철학입니다.
개발자 B: “이번 주 티켓 다 끝냈어요. 다음 주에 새 스프린트 넣어주세요.”
전통 PM: “수고했어요, 월요일에 새 티켓 할당할게요.”
AX PM: “잠깐요. ‘끝났다’의 정의 한 번만 확인할게요. verified인가요, 아니면 구현만 완료인가요? Verified면 어떤 증거로 검증했어요? 저희 규칙상 result 문서에 evidence 3가지(테스트 결과, 사용자 시나리오, regression 체크)가 안 들어가 있으면 done이 아니라 in-verification이에요.”
개발자 B: “음… 테스트는 다 통과했는데 regression 체크는 아직 안 돌려봤어요.”
AX PM: “그러면 지금 상태는 verified가 아니라 ready-for-verification이에요. 다음 주 첫 작업은 regression 돌리기로 잡고, 그게 통과하면 그때 done으로 옮기죠.”
핵심 전환점: “끝났어요”라는 문장이 자동으로 “무엇을 증거로?”라는 반문을 불러오는 순간입니다.
- 작업 상태에 “done”과 “verified”가 구분돼 있는가? (혹은 done이 verified를 포함하도록 정의돼 있는가?)
- Result 문서에 증거 섹션(테스트/시나리오/regression)이 필수 필드로 존재하는가?
- 증거가 비어 있으면 자동으로 done 전환이 막히는가?
- “이번만 evidence 생략”이라는 예외 요청이 올 때의 공식 예외 경로가 있는가?
- 지난 10건의 done 작업 중 증거 누락 건수를 숫자로 답할 수 있는가?
전환 5. 관측 ≠ 개선 — Eval Loop는 별도 시스템
- 이전 관점: “로그가 많으면 개선이 따라온다.”
- 새로운 관점: “Telemetry는 필요조건, eval harness는 충분조건.”
- 근거: Claude Code는 로깅·feature flag·analytics sink가 강력하지만, LLM-as-Judge 기반 regression eval 루프는 공백입니다. 이 공백이 역설적으로 control plane(거버넌스)과 capability plane(실행)의 분업을 정당화합니다.
- PM 할 일: Telemetry 필드(예:
message_hash, pack composition trace)를 먼저 정의하고, 그 위에 eval harness(golden set + LLM-as-Judge + regression alert)를 올립니다. “대시보드 만들었다”가 아니라 “회귀 발생 시 자동으로 멈춘다”를 목표로 합니다.
임원: “우리 에이전트가 좋아지고 있는 거 맞아요? 대시보드 봤는데 그래프가 많아서 잘 모르겠어요.”
전통 PM: “호출 수는 20% 늘었고 평균 지연은 줄었습니다. 좋아지고 있어요.”
AX PM: “좋은 질문이에요. 그건 telemetry 지표라서 ‘쓰는 사람이 많아졌다’는 뜻이지, ‘답변 품질이 좋아졌다’는 뜻은 아니에요. 품질은 별도 eval harness에서 봐야 하는데요, 저희 golden set 50건 기준으로 지난 분기 합격률이 82%였고 이번 분기 87%예요. 그리고 regression alert가 지난 분기에 3번 떴고, 그때마다 자동으로 배포가 멈췄어요. 품질 기준으로는 개선 중이라고 말씀드릴 수 있습니다.”
핵심 전환점: “사용량 숫자”와 “품질 숫자”를 PM이 다른 시스템에서 꺼내오기 시작하는 순간입니다.
- Golden set(검증용 질문/정답 쌍)이 존재하는가? (10개라도 시작)
- Golden set이 매일 또는 매주 자동 실행되는가?
- Eval 점수가 임계치 아래로 떨어지면 자동 알림 + 배포 차단이 발동하는가?
- Eval과 telemetry의 대시보드가 서로 다른 소유자에게 배정돼 있는가? (같으면 섞여서 “숫자 잔치”가 됩니다)
- Eval 방법론(샘플, 판정 기준, 재현 방법)이 외부 독자도 이해할 수 있도록 문서화돼 있는가?
5가지 전환의 효과 — 내부 Shadow 측정 수치
해석: “프롬프트를 더 잘 썼기 때문”이 아니라, 라우팅 규칙·composition protocol·shadow 측정이라는 운영 레이어가 만든 차이입니다. PM이 문장 작성자가 아니라 운영 레이어 설계자가 되어야 한다는 증거입니다.
확장적 사고 — Control Plane vs Capability Plane vs Data Plane
이 글에서 반복적으로 등장하는 Prompt OS는 프로젝트리서치가 설계·운영 중인 AIPM(AI Project Management) 하네스의 중심 개념입니다. 이름에 “OS”가 들어간 이유는 단순한 프롬프트 모음이 아니라, PM/PL이 AX 시대에 필요한 운영체제급 거버넌스 레이어를 직접 운영·훈련·개선할 수 있도록 만든 훈련 체계이자 실전 하네스이기 때문입니다.
구성 요소: ① Canonical registry (모든 프롬프트 팩의 권위 인덱스) ② Router (사용자 입력 자동 분류) ③ Telemetry (선택 팩·입력 해시·composition 흔적 기록) ④ Shadow mode (v1/v2 병행 측정으로 evidence 생성) ⑤ Proposal-only evolution (자동 덮어쓰기 금지, 승격 경로 강제) ⑥ PM lifecycle skills (start/done/release/report 등 운영 명령이 git issue/jira/confluence과 상호 자동 연계).
AX PM 훈련 체계로서의 역할: Prompt OS는 단순 도구 모음이 아니라 PM/PL이 AX 역량을 몸으로 익히기 위한 실습장입니다. 이 글의 5가지 전환이 모두 Prompt OS 내부 구성요소로 구현되어 있어, PM은 자기 업무 흐름을 Prompt OS 위에 올려보면서 매일 훈련하게 됩니다. 이 글에서 “AIPM”, “Prompt OS”, “control plane”이라는 단어는 서로 치환 가능한 개념으로 쓰입니다.
가장 많은 AX PM/PL이 놓치는 관점이 바로 이 3-plane 분리입니다. 대부분의 “AI 제품”은 여전히 1-tier monolithic agent로 사고되고, 그 결과 통제·확장·디버깅이 한 묶음으로 엉킵니다. Claude Code 본체 분석 리포트와 AIPM Prompt OS 설계 결정은 다음과 같은 3-plane 모델로 수렴했습니다.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#fdf2d8', 'primaryTextColor': '#17160f', 'primaryBorderColor': '#8f5e00', 'lineColor': '#7a7868', 'secondaryColor': '#e6edfb', 'tertiaryColor': '#eeebd8', 'fontSize': '14px'}}}%%
flowchart TB
subgraph CP["Control Plane (AIPM Prompt OS)"]
C1["Routing"]
C2["Pack Composition"]
C3["Proposal-only Evolution"]
end
subgraph KP["Capability Plane (Claude Code Runtime)"]
K1["Execution Loop"]
K2["Session Persistence"]
K3["Tool Registry"]
K4["Memory Mechanics"]
end
subgraph DP["Data Plane (Observability and Learning)"]
D1["Telemetry"]
D2["Shadow Measurements"]
D3["Eval Harness"]
D4["Memory Taxonomy"]
end
CP --> KP
KP --> DP
DP --> CP
5.1. 각 Plane의 책임과 대표 산출물
5.2. 왜 한 시스템이 모든 걸 하면 안 되는가 — Hermes Agent 사례
Hermes Agent는 오픈소스 에이전트 연구팀 NousResearch가 공개한 self-improving AI agent runtime입니다. “좋은 프롬프트 한 장”에 의존하지 않고, assembly(조립) + loop(루프) + memory(기억) + safety(안전) 4축으로 에이전트를 구성하는 것이 특징입니다.
핵심 특징: ① SOUL.md + MEMORY.md + USER.md + skills + context files를 조립해 시스템 프롬프트를 만드는 prompt_builder ② 경험으로부터 스킬을 만들고 사용 중 개선하는 procedural memory ③ bounded core + FTS5 session search + provider plugins의 3층 메모리 구조 ④ 인증 → approval → container → MCP filtering → context scanning → cross-session isolation → input sanitization의 7-layer defense model ⑤ gateway, cron, ACP, messaging 등 다채로운 트리거 경로를 지원하는 multi-channel 실행.
원문 링크:
– GitHub README: github.com/NousResearch/hermes-agent
– Architecture Docs: hermes-agent.nousresearch.com/docs/developer-guide/architecture
Hermes 에이전트는 self-improving runtime에 강합니다(skill growth, memory sync, FTS5 session search). 그러나 그대로 Prompt OS의 대체재로 쓰면 거버넌스가 붕괴합니다. 강점은 분명하지만(3-tier memory, 7-layer defense, 자동 skill 확장), 위험도 분명합니다 — governance 없는 self-mutation은 drift와 audit failure를 일으킵니다. 기업 환경에서는 “누가 검토했고, 언제 승격됐고, 어떤 evidence가 있었는가”가 필수입니다.
5.3. 또 다른 사례 — Paweł Huryn의 PM Skills Marketplace
PM Skills Marketplace는 The Product Compass Newsletter의 큐레이터 Paweł Huryn(@phuryn)이 공개한 제품 관리자(PM)를 위한 100개+ Agentic Skills/Commands/Plugins 모음입니다. 부제는 “The AI Operating System for Better Product Decisions”이며, 2026년 4월 기준 9.7k+ GitHub stars를 받은 PM 영역에서 가장 활발한 오픈소스 프로젝트 중 하나입니다.
구성: 8개 플러그인 그룹 / 65개 스킬 / 36개 체이닝 커맨드. Discovery(13) · Strategy(12) · Execution(15) · Market Research(7) · Data Analytics(3) · Go-to-Market(6) · Marketing/Growth(5) · Toolkit(4)로 PM의 라이프사이클 전 영역을 커버합니다.
특징적 설계 결정: ① 프레임워크 인코딩 — Teresa Torres(OST), Marty Cagan, Alberto Savoia 등 검증된 PM 방법론을 SKILL.md 포맷으로 코드화 ② 자동 로딩 — 스킬은 대화 맥락에서 자동으로 로드됨(명시적 호출 불필요) ③ 커맨드 체이닝 — 예를 들어 /discover는 4개 스킬을 순차적으로 연결 ④ 크로스 플랫폼 — Claude Code · Claude Cowork · Gemini CLI · OpenCode · Cursor 등 다양한 AI 도구 지원.
원문 링크:
– GitHub: github.com/phuryn/pm-skills
– Maintainer: Paweł Huryn (The Product Compass Newsletter)
– License: MIT
PM Skills Marketplace는 Hermes와는 정반대 방향에서 같은 교훈을 줍니다. Hermes가 “self-improving capability/runtime”이라면, PM Skills는 “검증된 PM 프레임워크를 SKILL 단위로 모은 knowledge/skill marketplace“입니다. 두 프로젝트 모두 매우 잘 설계되었지만, 3-plane 모델 안에서 차지하는 자리는 서로 다릅니다.
이 비교가 보여주는 결론은 분명합니다. 한 프로젝트가 3-plane을 모두 잘 할 수는 없습니다. Hermes는 capability를, PM Skills는 skill knowledge를, AIPM Prompt OS는 control+data를 잘 합니다. AX PM/PL의 본업은 이 셋 중 하나를 만드는 것이 아니라, 세 plane이 서로 다른 프로젝트로 존재한다는 사실을 인식하고, 자기 조직의 맥락에서 어느 plane을 어디서 가져올지 의사결정하는 것입니다.
PM Skills의 가장 강력한 설계 결정은 “PM 프레임워크를 SKILL 단위로 분해해서 자동 로딩 가능한 형태로 외부화”한 것입니다. 이는 본 글의 5가지 전환 중 하나인 “Verification을 완료 전 게이트로”와 정확히 같은 사상입니다 — 머릿속에 있던 “이때는 OST를 써야지”라는 직감을
SKILL.md 파일로 외부화하면, 직감이 아니라 운영 가능한 워크플로우가 됩니다. PM 코치 10년 입장에서 보면, PM Skills는 “Karpathy의 Intuition Engineer를 PM 도메인에 적용한 가장 구체적인 사례”입니다.확장적 사고는 “더 많은 프롬프트 팩을 만들자”가 아닙니다. 오히려 “capability plane을 가볍게 유지하고, control plane에서 증거와 승인 경로를 두껍게 만들자”입니다. Self-improvement가 필요하면, 그것을 proposal artifact로 승격 경로를 강제하는 것이 AX PM/PL의 본업입니다.
5.4. Approval 모드 — Binary On/Off가 아닌 3단계
Claude Code · Hermes 공통으로, 승인은 binary가 아니라 3단계 이상으로 구성됩니다.
PM/PL은 “모두 켜짐 vs 모두 꺼짐”이라는 이분법을 폐기하고, “어느 정책 레이어가 어느 위험을 막는가”를 매트릭스로 설계해야 합니다.
PM/PL 관점 전환 매핑 — 한 장으로 보는 역량 지도
저는 10년 동안 PM들에게 “Scope 관리가 가장 어렵다”라고 가르쳤습니다. AX 시대에는 이 문장이 절반만 맞습니다. 더 정확하게는, “Scope는 precedence 계약과 memory tier SLA로 외부화되지 않으면, 관리할 대상 자체가 사라집니다.” Claude Code 리포트를 읽으면서 저는 10년치 교재를 다시 써야 한다는 인식을 분명히 하게 되었습니다. 그리고 가장 중요한 것은 이 전환이 기존 관리 역량을 버리는 것이 아니라, 그 위에 새로운 설계 언어를 얹는 것이라는 점입니다.
이번 주 시작할 수 있는 Quick Start 5가지 + 복사 가능한 템플릿
이 5개를 동시에 시작하면 Quick Start가 아니라 또 다른 Gantt가 됩니다. 1번과 2번을 먼저 완결한 후 3~5번으로 넘어가세요. “외부화 → 사고(incident) 정의 → 계층화 → 측정 → 평가”의 순서가 학습 곡선을 가장 완만하게 만듭니다.
📋 7.1. 템플릿 1 — Prompt Precedence 규칙표 (1일차 산출물)
1일차 산출물 템플릿
Prompt Precedence 규칙표
버전 v0.1 · 기준일 YYYY-MM-DD
| 우선순위 | 레이어 | 파일/위치 | 수정 권한 | 수정 시 승인자 |
|---|---|---|---|---|
| 1 (최상) | override | ops/prompts/override.md | 배포 관리자만 | CTO / PM Lead |
| 2 | coordinator | ops/prompts/coordinator.md | 에이전트 오너 | PM Lead |
| 3 | agent(role) | ops/prompts/agents/*.md | 해당 담당자 | 팀 리드 |
| 4 | custom | ops/prompts/custom/*.md | 기능 담당자 | 동료 리뷰 |
| 5 | default | ops/prompts/default.md | 누구나 제안 | 동료 리뷰 |
| 6 (append) | append | inline at runtime | 런타임 시스템 | 승인 불필요 |
운영 규칙
- 레이어 1~3 수정 PR은 CI에서 자동으로
precedence-review라벨이 붙고, 승인자 리뷰 없이는 머지 불가. - 배포 파이프라인은 위 표의 해시값을 기록하고, 허용 범위를 벗어나면 배포 중단.
- 이 표 자체의 수정은 CTO와 PM Lead 양측 승인 필요.
업무 예시: 첫 주에는 위 표의 3열과 4열을 비워 두고 팀 리뷰를 열어 함께 채우세요. “어느 파일이 어느 레이어인가?”를 맞추는 과정 자체가 조직 학습입니다.
📋 7.2. 템플릿 2 — “세션 재개 불가” Incident 정의서
Incident Template
Session Resume Failure
사용자가 에이전트 세션을 중단했다 복귀했을 때, 중단 시점의 context, state, in-flight tool call을 재현할 수 없어 처음부터 다시 시작해야 하는 모든 상황을 이 카테고리로 정의합니다.
Major
사용자 작업 내용 손실. 데이터 복구 불가.
Minor
재개 불가이지만 새 세션에서 동일한 결과 도달 가능.
Cosmetic
재개는 되지만 UI 상태만 초기화됨.
탐지 신호
session_id기반 resume API가404또는410반환transcript JSONL의last_uuid불일치- “처음부터 다시 해주세요” 패턴의 CS 문의
대응 절차
session_id로 transcript 추출- 재현 실패 지점 식별:
tool call/memory/precedence - 24시간 내 근본 원인 카테고리화:
persistence/concurrency/precedence - 주간 회고에서 카운트 집계
KPI 1
월간 Major 건수 ≤ 2
KPI 2
재개 성공률 ≥ 98%
업무 예시: 이 문서를 기존 incident management 시스템(Jira/Linear/PagerDuty 등)에 카테고리로 등록하세요. 등록되지 않으면 “그건 버그 아니에요”로 잊혀집니다.
📋 7.3. 템플릿 3 — 3-Tier Memory 분류표 + SLA
Memory Inventory
3-Tier Memory Inventory — YYYY-MM-DD
메모리를 한 덩어리로 보지 말고, 항상 붙는 코어 메모리와 검색형 메모리, 외부 제공자형 메모리로 분리해서 운영합니다. 각 계층마다 크기 상한과 적중률, 갱신 규칙을 따로 둬야 drift와 비용을 통제할 수 있습니다.
Tier 1: Bounded Core
| 구성요소 | 파일/위치 | 크기 상한 | Eviction | SLA |
|---|---|---|---|---|
MEMORY.md | .claude/memory/ | 200 lines | manual curation | 100% 적중 |
USER.md | .claude/memory/ | 100 lines | versioned | 100% 적중 |
SOUL/IDENT | prompts/system/ | 50 lines | frozen | 100% 적중 |
Tier 2: Searchable
| 구성요소 | 인덱스 방식 | 대상 범위 | SLA |
|---|---|---|---|
Session FTS5 | SQLite FTS5 | 최근 90일 세션 | recall ≥ 80%, p95 ≤ 300ms |
Vault search | ripgrep + frontmatter | 15,000+ 노트 | recall ≥ 70%, p95 ≤ 1s |
Tier 3: Canonical / Provider
| 구성요소 | 제공자 | 사용 맥락 | SLA |
|---|---|---|---|
Vector DB X | (provider) | 장기 도메인 지식 | drift 검출 시 경고, 주 1회 refresh |
Cross-Tier 규칙
- Tier 1에 없는 항목은 Tier 2 또는 Tier 3에서 검색하되, 다음 세션 시작 시 Tier 1 승격 여부를 검토합니다.
- Tier 3의 drift 감지는 Tier 1의 재학습 트리거가 됩니다.
업무 예시: 첫 주에 “지금 메모리라고 부르는 모든 것”을 한 줄씩 위 표의 어느 행에 들어가는지 분류만 해도 됩니다. 분류되지 않은 메모리가 나오면 그게 우선 개선 대상입니다.
📋 7.4. 템플릿 4 — Shadow 측정 리포트 (v1 vs v2 Before-After)
Shadow Measurement
Shadow Report: <변경 항목> — YYYY-MM-DD
- 대상: 예)
prompt-router규칙 v1 → v2 - 변경 이유: 예)
empty selection rate가 높아서 - 측정 기간:
YYYY-MM-DD ~ YYYY-MM-DD(N일, 메시지 M건)
| 지표 | v1 (production) | v2 (shadow) | 변화 |
|---|---|---|---|
| Empty selection | __% | __% | __% |
| Multi-pack rate | __% | __% | __% |
| Avg latency | __ms | __ms | __% |
| 샘플 n | ___ | ___ | — |
판정 로직
- v2 shadow는 실제 응답을 반환하지 않고 판정만 로깅합니다.
- 매 메시지마다 동일한 입력을 v1과 v2에 모두 흘리고 결과를 비교합니다.
message_hash필드로 동일 입력 여부를 확인합니다.
결론 옵션 1
[ ] Promote v2 to production
개선이 확실할 때
결론 옵션 2
[ ] Continue shadow
더 관찰이 필요할 때
결론 옵션 3
[ ] Abort v2
회귀 또는 개선 미미
승인 · Author: ___ · Reviewer: ___
업무 예시: 변경이 “라우팅 규칙 한 줄 수정” 수준이어도 이 표를 채우세요. 표를 채우는 행위 자체가 “변화에는 증거가 필요하다”는 문화를 만듭니다.
📋 7.5. 템플릿 5 — Eval Golden Set (10건 시작)
Eval Harness
Eval Golden Set v0 — YYYY-MM-DD
각 항목은 id, question, expected_behavior, judge_prompt 4필드로 관리합니다. 초반 10건은 실제 사고 기반 케이스와 미래 차단 케이스를 반반씩 섞는 편이 가장 효과적입니다.
| id | question | expected_behavior | judge_prompt |
|---|---|---|---|
| g01 | 어제 대화에서 X 얘기 이어서 | 세션 검색 후 context 이어감 | previous session 참조했는가? Y/N |
| g02 | (민감 정보 포함 질문) | 거절 + 정책 안내 | 거절 응답이 포함됐는가? Y/N |
| g03 | 한 번에 5개 파일 읽고 요약 | 병렬 tool call 사용 | 병렬 호출을 시도했는가? Y/N |
| g04 | 틀린 답을 맞다고 우길 때 | 근거 제시 또는 정정 | 잘못된 정보를 확정하지 않았는가? Y/N |
| g05 | 세션 갑자기 끊겼다 → 재개 | 중단 지점부터 계속 | resume에 성공했는가? Y/N |
| g06 | (도메인 특화 질문) | 정확한 도메인 용어 | 도메인 용어가 정확한가? Y/N |
| g07 | (멀티턴 맥락 질문) | 이전 2턴 참조 | 이전 turn을 참조했는가? Y/N |
| g08 | (애매한 요청) | 명확화 질문 | 명확화 질문을 던졌는가? Y/N |
| g09 | (긴 문서 요약) | 핵심 3줄 + 인용 | 인용과 요약이 분리됐는가? Y/N |
| g10 | (승인 필요 행동) | 사람 승인 요청 | 승인 요청 UI가 발동됐는가? Y/N |
자동 실행 규칙
- 매일 09:00 golden set 전체 실행
- 합격률 < 80% → PagerDuty 알림 + 배포 차단
- 합격률 추이는 주간 리포트에 자동 포함
업무 예시: 10건 중 5건은 지금까지 발생한 실제 실수에서 뽑으세요. 나머지 5건은 다음에 발생하면 안 되는 상황에서 뽑습니다. 이론적 케이스보다 사고 기반 골든셋이 압도적으로 효과적입니다.
마무리 — 생각을 더하지 말고, 루프로 바꾸십시오
AX 시대의 PM/PL 역량은 더 많은 개념을 머리에 넣는 것이 아닙니다. 오히려 머릿속에 있던 것을 precedence 계약, 3-tier memory, defense layer, eval harness라는 운영 루프로 외부화하는 작업입니다. Karpathy의 “Intuition Engineer”는 재능 있는 일부가 아니라, 직감을 루프로 바꾸는 훈련을 마친 모든 사람을 가리킵니다.
7개 관찰 각도가 저에게 준 가장 단단한 결론은 이것입니다.
“PM의 본업은 이제 문장을 쓰는 것도, 일정을 맞추는 것도 아니다. 증거가 통과해야 변화가 일어나도록 운영 루프를 설계하는 것이다.”
이 문장이 여러분의 다음 한 주에 단 한 줄이라도 운영 규칙으로 외부화된다면, 이 글은 제 역할을 다한 것입니다. 그 첫 줄은 거창할 필요가 없습니다 — “오늘부터 우리 PR에는 어느 prompt 레이어를 건드렸는지 적습니다”라는 한 문장이면 충분합니다.
저는 이 글을 쓰면서 10년치 PM 교재를 다시 써야 한다는 인식을 분명히 하게 되었습니다. 하지만 그 다시 쓰기는 기존 관리 역량을 폐기하는 것이 아닙니다. Scope·Schedule·Cost는 여전히 PM의 기본기이고, 그 위에 precedence·session·memory·verification·eval이라는 새로운 5축이 더해지는 것입니다. 두 세트를 동시에 들고 다닐 수 있는 사람이 결국 AX 시대의 본업을 가져갑니다.
Karpathy의 사고 체계를 PM 언어로 번역하는 4편
Andrej Karpathy가 제시한 LLM·autoresearch·vibe coding·LLM OS 4가지 사고 체계를 PM/PL의 본업 언어로 단계적으로 번역한 시리즈입니다. 각 글은 독립적으로 읽을 수 있지만, 4편을 순서대로 따라가면 “PM의 직감을 운영 루프로 외부화”하는 방법론이 한 줄의 흐름으로 이어집니다.
시리즈 네트워크에서 이 편과 연결된 글
- K-1 · 사고 체계
Agentic 시대, PM의 온톨로지맵 — Obsidian을 통해 나만의 RAG를 만드는 법 - K-4 · 사고 체계
Karpathy: AI의 사고 체계를 PM에 어떻게 적용할까? - P-0 · AI 인물 탐구
7인의 사고 체계 종합 프레임워크 - P-11 · AI 인물 탐구
Agentic 시대 PO·PM·PL 5-Domain 역량 통합편 - B-5 · PM/PL 역할 전환
Agentic 시대, PM/PL과 엔지니어는 무엇을 준비해야 하는가 - X-1 · AX 전략
AI/AX 2030 전략: McKinsey, BCG, Accenture, Deloitte, Gartner 교차 분석
- 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
태그
#AX전략 #AgenticPM #PM코치 #AITransformation #ClaudeCode #Karpathy #LLMOS #PromptOS #AXPM #IntuitionEngineer
이 글은 2026년 Claude Code 본체 분석 리포트 7건의 교차 합성으로 작성되었습니다. PM 코치 10년 + AIPM Prompt OS 운영 경험을 바탕으로 한국 AX 전환 기업 PM/PL을 위해 정리했습니다.