SITE SEARCH

검색

사이트 전체 글을 빠르게 찾을 수 있습니다.

RSS FEED

RSS 구독

RSS 리더에서 Project Research의 새 글을 바로 받아볼 수 있습니다.

EMAIL SUBSCRIBE

이메일 구독

새 글을 이메일로 받아봅니다. RSS는 별도 RSS 아이콘을 눌러 동일한 크기의 패널에서 열 수 있습니다.

이메일로 블로그 구독하기

이 블로그를 구독하고 이메일로 새글의 알림을 받으려면 이메일 주소를 입력하세요







주니어 PM 위한 AI 하네스 구축 가이드

시리즈

PMBOK 8th, SAFe 6.0, BABOK v3, SEBOK v2.13 + AI 코딩 도구 실운영 설정 교차 참조

이 편이 답하는 질문
  • 주니어 PM을 위한 AI 하네스 구축이 기존 PM 온보딩·교육 프로그램을 어떻게 대체하거나 보강하는가?
  • AI 하네스의 “스킬·에이전트·피드백 루프” 3층 구조가 junior→senior PM 성장 경로에서 각각 무엇을 담당하는가?
  • 주니어 PM의 “common mistake”(scope 설정 오류·stakeholder alignment 누락·metric 정의 부족)를 AI가 사전에 탐지·교정하는 메커니즘은?
  • AI 하네스 기반 PM 교육이 “표준화”와 “개인화 학습”의 긴장을 어떻게 해결하는가?
이 시리즈를 읽는 세 개의 눈
  • PO: junior PM 온보딩에 AI 하네스를 필수 도구로 지정하고, “프롬프트·context 작성 능력”을 신입 기준의 L1로 정의하라.
  • PM: 자신의 PM 워크플로우를 markdown(CLAUDE.md 또는 동등)으로 명시화하는 것을 junior PM 교육 제1과제로 삼되, 그 과정이 자신의 암묵적 노하우를 명시적 프롬프트로 전환하는 훈련 기회가 되게 하라.
  • PL: AI 하네스 기반 교육으로 주니어 PM의 “성장 곡선”을 정량 측정할 수 있게 되면, “PM 채용 기준”과 “역량 개발 로드맵”을 조직 단위로 표준화할 수 있다는 기회를 인식하라.
대상 독자
Part I — 이제 막 커리어를 시작하는 주니어 PM (Project Manager)
Part II — AI를 팀에 도입·운영하려는 시니어 PM / PL / 팀장

원본 분석 대상: 시니어 PM 컨설턴트의 Claude Code 실제 운영 설정 3개 파일 + 12개 프롬프트팩 + 8개 슬래시 커맨드 + 자동화 스크립트 체계
Part I

주니어 PM — AI 업무 하네스 구축

들어가며

하네스 없는 AI 협업이 왜 문제인가

“ChatGPT 잘 쓰는데 뭐가 문제야?”

주니어 PM 대부분은 AI를 이렇게 씁니다. 회의가 끝나면 ChatGPT를 열고 “오늘 회의 내용 정리해줘”라고 입력합니다. 리스크 분석이 필요하면 “이 프로젝트의 리스크를 분석해줘”라고 물어봅니다. 주간 보고를 쓸 때면 “이번 주 성과를 보고서로 정리해줘”라고 요청합니다. 처음엔 놀랍습니다. “이렇게 빨리 나온다고?” 하지만 2–3주가 지나면 다음과 같은 상황에 반복적으로 부딪힙니다. 매번 같은 말을 반복합니다. “한국어로 써줘”, “PMBOK 기준으로 답해줘”, “마크다운 표로 정리해줘” — 이 말을 매 대화마다 합니다. 새 대화를 열 때마다 AI는 여러분이 누구인지, 어떤 프로젝트를 하는지, 어떤 형식을 원하는지 전혀 모릅니다. 지난번 대화에서 30분 동안 맥락을 설명한 것이 다음 대화에서는 백지가 됩니다. 산출물 형식이 매번 달라집니다. 월요일에 만든 주간 보고서와 다음 월요일에 만든 보고서의 구조가 다릅니다. AI는 특별히 지시하지 않으면 자기가 “좋다고 판단한” 형식으로 매번 다르게 답합니다. 결국 AI가 만든 초안을 받아서 형식을 맞추는 데 다시 시간을 쓰게 됩니다. 좋은 답변을 받고도 잊어버립니다. 지난달에 AI와 함께 만든 리스크 대응 전략이 꽤 좋았는데, 이번 달 비슷한 상황에서 그걸 다시 찾을 수 없습니다. AI와의 대화에서 나온 인사이트가 휘발성 지식으로 증발합니다. AI가 자신 있게 틀린 말을 합니다. “이 프로젝트의 예산은 충분합니다”라고 AI가 말했는데, 실제로는 프로젝트 데이터를 본 적도 없으면서 그럴듯하게 답한 것이었습니다. 근거를 물어보면 “일반적으로…”라는 답이 돌아옵니다.

하네스가 있으면 무엇이 달라지는가

하네스(Harness)란 AI에게 “누구로서, 어떤 맥락에서, 어떤 형식으로, 어떤 기준으로 일하라”고 한 번 정의해두는 구조입니다. 설정 파일 하나가 모든 대화에 자동으로 적용됩니다. 반복 설명이 사라집니다. 페르소나, 출력 형식, 행동 규칙이 설정 파일에 있으므로, 매번 “한국어로, PMBOK 기반으로, 표로 정리해줘”를 타이핑하지 않아도 됩니다. 산출물이 일관됩니다. 주간 보고서의 구조가 매주 동일합니다. 한 번 정의된 템플릿이 자동으로 적용되기 때문에, “형식 맞추기”에 쓰던 시간이 사라지고 내용에만 집중할 수 있습니다. 지식이 쌓입니다. AI와 만든 산출물이 프로젝트 저장소에 자동 저장되고, 재사용 가능한 교훈은 지식 베이스로 분류됩니다. AI의 과신을 제어합니다. “불확실하면 가정하지 말고 질문하라”, “근거 없이 단정하지 말라”는 행동 규칙이 설정되어 있으므로, AI가 모르는 것을 아는 척하는 빈도가 눈에 띄게 줄어듭니다.

무시했을 때 실제로 겪는 문제들

4가지 함정
1. “프롬프트 장인” 함정 — 완벽한 프롬프트 작성에 20분, 산출물 검토에 5분
2. “기억력 의존” 함정 — 좋은 프롬프트를 메모장/카카오톡에 흩뿌려 놓고 3개월 후 찾지 못함
3. “맥락 단절” 함정 — 프로젝트 A의 분석을 프로젝트 B에서 활용 불가
4. “AI 맹신” 함정 — 검증 없이 AI 출력을 그대로 써서 이해관계자 앞에서 근거 없는 보고
이 가이드의 8대 원칙과 5단계 로드맵은 위 4가지 함정을 구조적으로 방지하기 위해 설계되었습니다. 프롬프트 기술(skill)이 아니라, 프롬프트가 담기는 시스템(system)을 만드는 것이 핵심입니다.
Executive Summary

10줄 설정

템플릿 3-5종

키워드 트리거

피드백 반영

Stage 1: Foundation
1주차 — 페르소나 + 출력 규칙

Stage 2: Structure
2-3주차 — 산출물 형식 표준화

Stage 3: Automation
1-2개월차 — 트리거 기반 자동화

Stage 4: Knowledge Loop
3개월차~ — 지식 축적 시스템

핵심 요약

1. AI를 “질문-답변 도구”가 아닌 “업무 라이프사이클 하네스”로 설계하라
2. 8대 원칙으로 AI 출력 품질을 제어: 페르소나, 출력 형식, 증거 우선, 행동 가이드라인, 3단계 품질 게이트, 지식 축적, 위험기반 자율 실행, AI용 DoR/DoD
3. 5단계 로드맵(Foundation → Structure → Automation → Knowledge Loop → Enterprise Scaling)
4. 맥락 자동 감지 프롬프트팩(12종), 지식 사후 분류(disposition)와 수명주기 관리
5. Claude Code 기반이나, 원칙은 도구 불문 — Cursor, GitHub Copilot, ChatGPT 등에도 적용 가능

8대 핵심 원칙 상관관계도

① 페르소나
② 출력 형식
③ 증거 우선
↓ ↓ ↓
AI 업무 하네스 시스템으로서의 AI 협업
↓ ↓ ↓
④ 행동 규칙
⑤ 품질 게이트
⑥ 지식 축적
↓ ↓
⑦ 위험기반 자율성
⑧ AI DoR/DoD

①②③ 입력 품질 제어 → ④⑤⑥ 프로세스 품질 제어 → ⑦⑧ 실행·완료 품질 제어

원칙 1

7대 핵심 원칙

1 페르소나 선언

역할과 전문성 명시

일관된 답변 품질

2 출력 형식 고정

언어 + 용어 병기

마크다운 표준화

3 컨텍스트 탐색 우선

로컬 파일 먼저

기존 산출물 확인

4 행동 가이드라인

과잉 행동 제어

스코프 크리프 방지

5 품질 게이트

빈 산출물 차단

검수 기준 사전 정의

6 지식 축적

3층 SSoT 모델

교훈 전달 경로

7 자동 실행 정책

Type 2 즉시 실행

Type 1만 확인 요청

페르소나를 명시적으로 선언하라

LLM은 “누구로서” 답변해야 하는지 알 때 출력 품질이 달라집니다. “PM 관점에서 답해줘”라고 매번 타이핑하는 것과, 설정 파일에 한 번 선언해두는 것은 전혀 다릅니다. SAFe 6.0의 관점으로 비유하자면, 이것은 팀 토폴로지(Team Topology)를 정하는 것과 같습니다. AI에게 역할과 책임(R&R)을 명확히 부여하는 거죠.
실무 적용 사례: 삼성전자 PM 역량 강화 워크숍에서 SEBOK+PMBOK 교차 매핑을 활용할 때, AI 페르소나를 “시스템 엔지니어링과 프로젝트 관리 양쪽 프레임워크에 정통한 코치”로 선언하자 도메인 특화 답변 정확도가 뚜렷이 향상되었습니다. FullyActiveLearning 워크숍에서도 참가자별 페르소나 커스터마이징이 산출물 만족도에 가장 큰 영향을 미치는 요인으로 확인되었습니다.
원칙 2

출력 형식을 사전에 고정하라

PM의 산출물은 결국 다른 사람이 읽는 문서입니다. PMBOK 8th Edition에서 말하는 조직 프로세스 자산(OPA) 관점에서, 출력 형식의 표준화는 조직의 일하는 방식을 정의하는 것과 같습니다. 특히 “영어 원문 병기” 규칙은 실무에서 매우 강력합니다. 글로벌 프레임워크를 한국어로만 쓰면 원문 맥락이 유실되고, 영어로만 쓰면 팀원들이 이해하기 어렵습니다.
원칙 3

“증거 우선(Evidence-First)” 원칙을 세워라

이것은 이 설정 체계에서 가장 중요한 원칙 중 하나입니다. AI가 기존에 이미 있는 자료를 먼저 찾아보도록 강제합니다. BABOK v3현행 상태 분석(Current State Analysis) 원칙과 같습니다.

증거 우선 계층(Evidence Hierarchy)

Evidence Hierarchy — 피라미드

1. 공식 기록 시스템 (SoR)
2. 공식 최신 소스
3. 승인된 로컬 지식
4. 모델 일반 지식

↑ 신뢰도 높음  |  ↓ 신뢰도 낮음 — 상위 계층이 우선 적용

우선순위 증거 출처 예시
1 공식 기록 시스템(System of Record) Jira 이슈, 계약서, 승인된 일정표
2 공식 최신 소스 벤더 공식 문서, 법규 원문, API 레퍼런스
3 승인된 로컬 지식 Obsidian Vault, 프로젝트 docs, 검증된 템플릿
4 모델 일반 지식 AI의 학습 데이터 기반 답변
실무 적용 사례: LS Electric 요구사항 관리 워크숍에서 AI가 기존 사양서(System of Record)를 먼저 검색한 뒤 답변하도록 설정했을 때, 요구사항 누락률이 현저히 줄었습니다. 반대로 로컬 탐색 없이 AI 모델 지식만으로 답변하게 했을 때는 해당 제품 도메인에 맞지 않는 일반론이 반복 생성되는 문제가 발생했습니다.
원칙 4

“행동 가이드라인”으로 AI의 습관을 교정하라

규칙 핵심 메시지 PM 관점 해석
Think Before Coding 가정하지 말고, 트레이드오프를 드러내라 이해관계자 요구사항을 추측하지 말 것
Simplicity First 요청 범위 이상의 기능을 추가하지 말라 스코프 크리프(Scope Creep) 방지
Surgical Changes 건드려야 할 것만 건드려라 변경 영향 분석 최소화
Goal-Driven Execution 성공 기준을 정의하고 검증까지 반복 DoD 기반 실행
SAFe의 WSJF(Weighted Shortest Job First) 관점으로 보면, AI가 가치가 높지 않은 작업에 시간을 쓰지 않도록 우선순위 가드레일을 설정하는 것입니다.
실무 적용 사례: 현대모비스 PBL(Problem-Based Learning) 시뮬레이션 워크숍에서 ASPICE 기반 프로세스를 AI에 적용할 때, “Simplicity First” 규칙 없이 진행한 팀은 AI가 불필요한 프로세스 단계를 과잉 생성하여 오히려 작업량이 증가했습니다. 반면 4대 행동 규칙을 설정한 팀은 ASPICE 필수 산출물에만 집중하여 효율적으로 결과를 도출했습니다.
원칙 5

산출물에 “3단계 품질 게이트(Quality Gate)”를 걸어라

PMBOK 8th의 품질 성과 영역(Quality Performance Domain) 관점에서, 형식 검수만으로는 부족합니다.

3단계 검증 게이트 흐름도

Gate 1 형식 검증
AI 자가 체크
Gate 2 내용 검증
PM 본인 검토
Gate 3 영향 검증
피어 리뷰
✓ 승인 산출물 확정
게이트 검증 주체 검증 내용 예시
Gate 1: 형식 AI 자가 체크 placeholder 없음, 변수 치환 완료 원본의 품질 게이트 규칙
Gate 2: 내용 PM 본인 1차 검토 사실 관계, 근거 출처, 가정 표면화 “이 리스크 분석의 근거는?”
Gate 3: 영향 피어 리뷰 이해관계자 영향 산출물의 정확성 고객 공지, 의사결정 메모
실무 적용 사례: 삼성전자 Global Expert PMBOK 7th→8th 전환 워크숍에서, AI가 생성한 성과 영역 매핑 산출물에 Gate 2(내용 검증)를 적용했을 때, 7th와 8th 간 용어 변경·개념 재편이 정확히 반영되지 않은 오류 3건을 사전에 포착했습니다.
원칙 6

지식을 “축적”하는 구조를 만들어라

대부분의 사람들은 AI와 대화하고, 좋은 인사이트를 얻고, 그리고… 잊어버립니다. 이 설정은 AI가 만든 산출물 중 재사용 가능한 지식을 자동으로 분류하고 축적하는 구조를 갖추고 있습니다. 이것은 PMBOK 8th의 교훈 관리(Lessons Learned) + SEBOK v2.13의 시스템 사고(Systems Thinking)가 결합된 형태입니다.
실무 적용 사례: LG전자 PM 인증 프로그램(PMBOK+SAFe 병행)에서 5회 세션에 걸친 교훈을 Obsidian Vault에 disposition 기반으로 축적한 결과, 후속 세션에서 이전 세션의 Q&A와 실습 결과를 AI가 자동 참조하여 중복 설명이 대폭 줄었습니다. 특히 cross-repo-reusable로 분류된 SAFe PI Planning 실습 템플릿은 이후 SK화학 워크숍에서도 재활용되었습니다.
원칙 7

위험기반 자율 실행 정책을 명시하라

SAFe의 분권화된 의사결정(Decentralized Decision-Making) 원칙에서 구분하듯, 되돌릴 수 있는 결정(Type 2)은 빠르게 실행하되, 되돌릴 수 없는 결정(Type 1)에는 반드시 사람의 확인을 거쳐야 합니다.

위험기반 자율성 의사결정 트리

AI 작업 요청
가역적(Reversible)인가?
✓ Yes
외부 영향이 있는가?
No
즉시 실행 (Type 2)
Yes
승인 후 실행
✗ No
반드시 승인 (Type 1)
즉시 실행 가능 (Type 2) 승인 후 실행 (Type 1)
회의록 구조화 외부 이메일/메시지 발송
내부 초안 작성 일정/범위 확정·변경
태그/라벨/분류 정리 비용 발생 작업
요약/번역/포맷 변환 데이터 삭제/이관
내부 위키 초안 생성 릴리스/배포/고객 공지
코드 리뷰/분석 계약/법무 관련 문서
원칙 8

AI에게 맡길 준비 상태(DoR)와 완료 기준(DoD)을 정의하라

Scrum Guide 2020의 Definition of Done과 커뮤니티 실천법인 Definition of Ready에 기반합니다.
AI용 DoR — “맡기기 전 체크리스트”
• 목표(Goal)가 한 문장으로 명확한가?
• 입력 자료(Input)가 최신이고 충분한가?
• 민감 정보 포함 여부가 확인되었는가?
• 성공 기준이 측정 가능하게 정의되었는가?
• 검토자(Reviewer)가 지정되었는가?
AI용 DoD — “받은 후 체크리스트”
• 산출물이 완전한가? (빈 섹션, placeholder 없음)
• 근거 출처가 명시되었는가? (Source Traceability)
• 미치환 변수가 없는가?
• 민감정보가 노출되지 않았는가?
• 다음 액션/담당자/기한이 포함되었는가?
Key Nuances

이 설정만의 차별화된 특이사항

특이사항 1: [pm] 트리거 기반 모드 자동 전환

키워드 한 개로 전체 워크플로우가 자동 기동됩니다. 이것은 PMBOK 8th의 프로세스 그룹 — 착수 → 계획 → 실행 → 감시 및 통제 → 종료를 AI 명령어 하나에 매핑한 것입니다.

특이사항 2: 맥락 자동 감지 기반 프롬프트팩 적용

12개의 전문 프롬프트팩이 업무 맥락에 따라 자동으로 선택·적용됩니다. SAFe의 역량 기반 라우팅(Competency-Based Routing) 개념과 유사합니다.

특이사항 3: Knowledge Disposition — 지식의 사후 분류와 수명주기

프로젝트가 끝날 때마다 산출물을 3단계로 분류합니다. 재사용 가능하다고 분류된 지식도 시간이 지나면 오염원이 됩니다. 이를 방지하기 위해 disposition에 owner, confidence, review_date, applicable_domains 메타데이터를 함께 기록합니다.

특이사항 4: Obsidian 위키링크를 AI 지식 그래프 빌딩에 활용

AI가 문서를 작성할 때 위키링크를 삽입하게 하면, Obsidian의 그래프 뷰에서 개념 간의 연결이 자동으로 시각화됩니다.
Operational Impact

PM 업무별 구체적 기대 효과

PM 업무 기존 방식 하네스 적용 후
백로그 관리 수동 입력, 라벨 불일치 [pm] 한 줄로 이슈·브랜치·계획 자동 생성
일일/주간 보고 형식이 매번 달라 재작업 프롬프트팩이 구조·품질 기준 자동 적용
리서치 검색→요약→문서화 수동 반복 [research] 주제로 검색·요약·파일 저장 자동화
프로젝트 종료 교훈이 기록만 되고 전달 안 됨 결과 문서 + 품질 게이트 + disposition
지식 관리 폴더에 파일만 쌓여감 프론트매터 + 위키링크로 검색·연결·재사용
릴리스 관리 수동 작성, 마일스톤 누락 [pm] release로 버전 태그·노트 자동화

효과 측정을 위한 프록시 지표

지표 측정 방법 의미
산출물 재작업률 AI 도입 전후 수정 횟수 비교 품질 게이트 효과
승인 1회 통과율 첫 리뷰에서 수정 없이 승인된 비율 출력 형식 표준화 효과
지식 재사용률 Obsidian cross-reference 빈도 지식 축적 효과
트리거 성공률 [pm] 실행 대비 롤백 비율 자동화 안정성
도구 비교

Claude Code 이외의 선택지

비교 축 Claude Code Cursor Copilot ChatGPT
개인 지시 지속성 CLAUDE.md .cursorrules copilot-instructions.md Custom Instructions
프로젝트 공유 프로젝트별 CLAUDE.md 프로젝트 Rules repo-wide instructions Projects
조직 강제력 Managed settings 엔터프라이즈 규칙 Organization inst. Enterprise 정책
권한 통제 5단계 권한 모드 제한적 제한적 미지원
Hooks/자동화 hooks + 스크립트 + 트리거 커맨드 팔레트 VS Code 연동 수동
감사 추적 Git 커밋 + 이슈 로그 Git 커밋 Git 커밋 대화 이력만
PM 적합도 ★★★★★ ★★★★☆ ★★★☆☆ ★★★☆☆
Roadmap

5단계 구축 가이드

5단계 구축 로드맵

1
Foundation
1주차
2
Structure
2–3주차
3
Automation
1–2개월차
4
Knowledge Loop
3개월차~
5
Enterprise
6개월차~
Stage 1: Foundation (1주차) — 글로벌 설정 파일(페르소나 + 출력 규칙 + 행동 규칙) 세팅
Stage 2: Structure (2-3주차) — 자주 만드는 산출물 3-5개의 출력 형식 템플릿 표준화
Stage 3: Automation (1-2개월차) — 키워드 트리거(회의록, 리스크 등) 도입
Stage 4: Knowledge Loop (3개월차~) — Obsidian 기반 지식 베이스 축적 구조 구축
Stage 5: Enterprise Scaling (6개월차~) — 개인 하네스를 팀 운영 표준으로 확장 → Part II로
“완벽한 설정을 만들고 시작하려 하지 마세요. Stage 1의 10줄짜리 설정부터 시작하고, 불편할 때마다 한 줄씩 추가하세요.” PM의 핵심 역량이 점진적 정교화(Progressive Elaboration)인 것처럼, AI 협업 환경도 점진적으로 정교화하는 것이 올바른 접근입니다.
Part II

시니어 PM/PL/팀장 — 팀 운영 표준으로의 확장

들어가며

개인 하네스만으로는 왜 부족한가

“우리 팀에 AI 잘 쓰는 사람이 한 명 있어요”

시니어 PM이나 팀장이 가장 자주 접하는 상황입니다. 팀원 중 한 명이 AI를 잘 활용합니다. “나도 저렇게 쓰고 싶다”는 말이 팀 내에서 돌기 시작합니다. 그런데 3개월이 지나도 한 명만 계속 잘 쓰고, 나머지 팀원들은 여전히 “이거 정리해줘”를 반복합니다. 이것이 “고립된 챔피언(Isolated Champion)” 문제입니다.
팀 차원의 5가지 실패 패턴
1. “누가 이걸 승인했지?” — AI가 작성한 고객 공지가 검토 없이 외부로 발송
2. “다들 다른 형식으로 줘요” — 산출물 취합 시 형식 통일에 시간 낭비
3. “회사 데이터를 어디에 넣은 거야?” — Shadow AI 리스크 현실화
4. “효과가 있긴 한 거야?” — 정량 측정 없는 도입은 “비용만 확실한 투자”
5. 챔피언 퇴사 = 조직 AI 역량 퇴보 — 개인 자산이 아닌 조직 자산이어야
Agentic Operating Model

사람과 AI의 역할 분담

AI 자율 수준(Level of Autonomy)

AI 자율 수준 (Level of Autonomy) 계층도

L0 Assist
L1 Recommend
L2 Draft + Review
L3 Constrained Execute
L4 Autonomous Execute
사람 주도 → AI 자율성 증가 → AI 주도
수준 명칭 AI의 역할 사람의 역할
L0 Assist 정보 제공, 검색 지원 판단·작성 모두 사람
L1 Recommend 대안 제시, 비교 분석 최종 선택은 사람
L2 Draft + Review 초안 작성 사람이 검토·수정·승인
L3 Constrained Execute 정해진 범위 내 자동 실행 사후 검토 + 예외 에스컬레이션
L4 Autonomous Execute 규칙 기반 완전 자동 주기적 감사만

Human-AI Decision Rights Matrix

업무 AI 주니어 PM 시니어 PM/PL 팀장
회의록 초안 작성 검토
리스크 분석 초안 검토 승인
고객 공지 메일 초안 검토 승인 필요시 승인
배포/릴리즈 보조 검토 승인 최종 승인
예산 변경 분석 제안 승인
Operational Guardrails

보안·규정 준수·데이터 분류

NIST AI RMF 1.0Generative AI Profile(AI 600-1)은 AI 시스템의 리스크를 Govern → Map → Measure → Manage 4단계로 관리할 것을 권고합니다.
등급 정의 AI 입력 예시
Public 외부 공개 가능 ✓ 제한 없음 공개 블로그, 제품 소개서
Internal 사내 공유 가능 ✓ 사내 승인 AI만 내부 회의록, 프로젝트 현황
Confidential 접근 제한 ⚠ 마스킹 후 제한적 고객사 계약 조건, 인사 정보
Restricted 극비 ✗ 금지 개인정보 원본, 인증 키, 재무 데이터
실무 적용 사례: SK화학 WBS/리스크 관리 워크숍에서 팀 단위로 AI 사용 가이드라인을 배포한 후, 참가자들이 “어떤 데이터를 AI에 넣어도 되는지”에 대한 명확한 기준을 갖게 되었다는 피드백이 가장 많았습니다.
Quality & Evaluation

측정·감사 체계

4대 KPI 영역
생산성 — 문서 초안 작성 시간 절감률, 회의록 정리 리드타임, 재작업률
품질 — 승인 1회 통과율, 사실 오류 수정 건수, 빈 섹션 발생률
리스크 — 민감정보 노출 건수, 잘못된 자동 실행 건수, 트리거 오작동 건수
지식 자산화 — 재사용된 템플릿 수, 위키링크 연결 증가율, AI 참조 성공률
Team Deployment

팀 표준 패키지 — 팀 Config 계층과 성숙도 모델

4계층 Config 구조 (우선순위: Global > Team > Project > Personal)
rules-global.md ← 전사/본부 공통 정책 (보안, 용어, 형식)
rules-team.md ← 팀 표준 (템플릿, 태그 체계)
rules-project-X.md ← 프로젝트별 컨텍스트 오버라이드
rules-personal.md ← 개인 선호 설정

팀 AI 성숙도 모델

레벨 특징 팀장의 역할 다음 단계 조건
L1: 개인 실험 각자 알아서 사용 Shadow AI 모니터링 2명 이상 Stage 2+ 도달
L2: 표준화 팀 공통 설정 도입 Base Config 배포 팀 전원 공통 설정 적용
L3: 통합 워크플로우 연결 트리거/자동화 설계 KPI 추적 시작
L4: 최적화 효과 측정 및 개선 메트릭 기반 피드백 조직 단위 확산 준비
실무 적용 사례: SKAX PM 역량 강화 프로그램에서 팀 AI 성숙도 L1→L2 전환 시, 팀 공통 CLAUDE.md를 배포하고 주간보고 형식을 표준화한 것만으로도 팀 내 산출물 취합 시간이 크게 단축되었습니다. L3 전환 시에는 [pm] 트리거와 자동화 스크립트를 도입하여 이슈 관리 프로세스를 연결했습니다.
Knowledge Lifecycle

지식 수명주기 관리

지식 수명주기 순환도

생성 Create
검토 Review
표준화 Standardize
재사용 Reuse
폐기/보관 Retire

↺ 재사용 가능 지식은 다시 순환

프로젝트 종료 시 지식 분류(Disposition) 기준

프로젝트가 끝나면 AI와 함께 만든 산출물을 “이 지식을 어디까지 재사용할 것인가?” 관점에서 5단계로 분류합니다. 분류하지 않으면 쌓이기만 하고 찾을 수 없는 “디지털 쓰레기”가 됩니다.
분류 의미 예시
None 해당 프로젝트에만 남김 (이관 불필요) 프로젝트 고유 회의록, 1회성 분석
Local-Reusable 같은 저장소 내 핸드북/템플릿으로 흡수 팀 내 반복 사용 체크리스트
Cross-Repo-Reusable 조직 지식 베이스(Vault)로 이관 범용 리스크 대응 패턴, 프레임워크 매핑
Obsolete 아카이브 — AI 참조 대상에서 제외 버전 변경으로 무효화된 가이드
Restricted 접근 제한 보관 (보안/규정 상 필요) 고객사 계약 관련 분석, 인사 데이터
Adoption & ROI

도입 타당성과 정착 전략

30-60-90일 정착 계획

기간 목표 핵심 액션 성공 기준
30일 개인 습관 형성 Quick Start 3가지 완료 팀원 80%가 설정 파일 보유
60일 팀 표준화 Team Config 배포 주간보고 표준 형식 통일
90일 측정 시작 KPI 트래킹, 효과 보고 재작업률 20% 감소 확인

실패 패턴 (Anti-patterns)

패턴 증상 대응
설정 과신 “써뒀으니 알아서 잘 하겠지” 설정은 유도이지 강제가 아님을 교육
과잉 자동화 검증 없이 AI 산출물 공유 Gate 2(내용 검토) 의무화
고립된 챔피언 한 명만 잘 쓰고 나머지 방관 페어 워크로 확산
측정 부재 “체감상 좋아진 것 같다” 90일차에 정량 지표 1개+ 보고
References

참고 문헌 및 출처

PM 프레임워크 표준: PMBOK 8th Edition (PMI, 2025) · SAFe 6.0 · BABOK v3 (IIBA) · SEBOK v2.13 (BKCASE/INCOSE, 2025) · Scrum Guide 2020 AI 도구 공식 문서: Claude Code · Cursor · GitHub Copilot · Windsurf AI 거버넌스: NIST AI RMF 1.0 · NIST AI 600-1 (GenAI Profile) · Gartner Shadow AI Report SAFe 참조 개념: WSJF · Decentralized Decision-Making 실무 적용 사례 (FullyActiveLearning): 삼성전자 SEBOK+PMBOK 교차 매핑 · LS Electric 요구사항 관리 · 현대모비스 ASPICE PBL · KPMA PMBOK 전환 교육 · LG전자 PM 인증 · SK화학 WBS/리스크 · 롯데이노베이트 PM 역량 강화
#AI-Harness #PMBOK-8th #SAFe-6.0 #Claude-Code #Agentic-PM #Team-Governance #Knowledge-Management

이 글은 10년간의 PM 코칭·컨설팅 경험과 Claude Code 실운영 설정 분석, 4개 AI(ChatGPT·Gemini·Claude·Copilot) 교차 피드백, 그리고 삼성전자·현대모비스·LG전자·SK화학 등 FullyActiveLearning 워크숍 사례를 바탕으로 작성되었습니다.

함께 읽기 · Related Posts

시리즈 네트워크에서 이 편과 연결된 글

Project Research에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기