직무 지식 기반과 Skill/MCP 재사용 전략

두 사람이 같은 일을 했는데, 결과가 다르다

한 B2B SaaS 운영팀에 PRD를 잘 쓰는 PO가 있었다. 그의 요구사항은 수락 기준이 명확해 개발팀이 되묻는 일이 적었다. 그가 휴가나 다른 과제로 빠지면 같은 자리에서 나온 PRD 품질이 눈에 띄게 흔들렸다. 용어가 어긋나고 수락 기준이 빠졌다. 되묻기가 늘고 리드타임이 길어졌다.

이 조직이 AX를 시작하며 가장 먼저 한 일은 그 PO에게 “AI를 쓰라”고 권한 것이었다. 그는 이미 잘했기에 AI로 더 빨라졌다. 그 효과는 그 한 사람의 화면 안에서만 일어났다. 옆자리 주니어 PO는 같은 도구를 켜고도 여전히 흔들리는 PRD를 만들었다. 도구에 들어갈 ‘검증된 업무 기준’이 한 사람의 머릿속에만 있었기 때문이다.

여러 직무에 자동화를 직접 넣어보며 반복해서 본 패턴이다. AX 성과는 ‘잘하는 사람 한 명’에게 집중되고, 그가 빠지면 무너진다. 사용량은 우상향하는데 검증된 산출 품질은 사람마다 들쭉날쭉하다. 채택은 확산됐지만 품질은 따라오지 않았다.

여기서 이 장의 단일 명제가 나온다. 검증된 업무 기준을 개인 노하우로 두면 자산이 아니라 위험이다. 그것을 Skill과 MCP(Model Context Protocol, 시스템 연결 도구)로 바꿔 ‘누가 작업해도 같은 품질’이 나오게 만드는 것이 AX 확산의 실체다. 5장이 “무엇을 재설계할지”, 6장이 “그것을 만들지 말지”를 물었다면, 이 장은 **“한 번 검증된 것을 어떻게 재사용 자산으로 굳히는가”**를 묻는다. 13장의 기능별 전환 성공을 다음 팀이 그대로 다시 쓰게 만드는 장치가 여기 있다.

못 박아 둔다. 이것은 ‘플랫폼을 깔자’는 이야기가 아니다. 직무 지식 기반은 새 시스템이 아니라 이미 검증된 업무 기준을 실행 가능한 형태로 묶는 운영 자산이다. 풀스택 앱을 짓자는 제안이 나오면 이 장을 거꾸로 읽은 것이다.

핵심 관점: 개인 노하우는 자산이 아니라 부채다

“잘하는 사람이 AI로 더 잘하게 됐다”는 좋은 소식처럼 들린다. 하지만 그것은 AX의 더 위험한 절반이다. 검증된 업무 기준이 한 사람 머릿속에만 있으면 세 가지 비용이 따라온다.

재현 불가. 그 사람이 빠지면 품질이 무너진다. 휴가·이직·과제 이동이 곧 품질 사고가 된다.
중복 재발명. 옆 팀은 같은 기준을 모른 채 같은 문제를 처음부터 다시 푼다. 현장에서 가장 잦은 고비용 패턴이다.
검증 단절. 머릿속으로 하던 품질 점검이 전수되지 않아 산출 품질이 사람마다 다르다.

그래서 관점을 뒤집는다. 목표는 ‘잘하는 사람을 더 잘하게’가 아니라 ‘그의 검증된 기준을 모두가 쓰게’다. 전자는 개인 생산성, 후자가 조직 AX다. AI leverage(검증된 산출 배수, 9장 참조)가 조직 단위로 올라가려면 검증된 기준이 재사용 자산이 되어 있어야 한다.

핵심 진단 질문은 하나다. “이 검증된 업무 기준은, 그 사람이 빠져도 같은 품질로 재현되는가?” “아니오”라면 아직 자산이 아니라 부채다. 그 부채를 자산으로 바꾸는 절차가 이 장의 본론이다.

무엇을 모으는가: 직무 지식의 6개 단위

직무 지식 기반은 문서 저장소가 아니다. AI가 일할 때 필요한 기준을 실행 가능한 형태로 묶는 것이다. 아무거나 모으면 또 하나의 방치된 위키가 된다. 검증된 업무 기준은 6개 단위로 나뉘고, 6개가 다 모여야 ‘누가 해도 같은 품질’이 가능해진다.

지식 단위	무엇인가	없으면 생기는 일	Skill/MCP 전환 형태
용어·판단 기준	직무 용어, 지표 정의, 예외 조건	같은 단어를 다르게 써서 결과가 어긋난다	용어집, KPI 정의, 승인 조건 (→ Skill)
산출물 형식	좋은 결과물의 구조·품질 기준	사람마다 다른 형식의 산출이 나온다	템플릿, 리뷰 체크리스트, 보고서 형식 (→ Skill)
시스템 연결	AI가 읽거나 호출할 기존 자원	매번 데이터를 손으로 복사한다	협업 도구·사내 API·읽기 전용 DB view (→ MCP)
권한·금지선	누가 어디까지 접근·실행하는가	자율 실행이 사고로 번진다	RBAC, 개인정보 차단, 운영 쓰기 금지 (→ MCP 제약)
검증 기준	결과가 맞는지 판단하는 샘플·평가 방식	“좋아 보인다”로 통과시킨다	골든셋, 테스트셋, 리뷰 기준 (→ Skill+게이트)
운영 기준	변경·폐기·비용·담당 관리 방식	자산이 방치되고 비용만 샌다	사용량 로그, 담당 조직, 버전, 폐기 기준 (→ 카탈로그 등재)

가장 자주 빠뜨리는 두 칸이 검증 기준과 운영 기준이다. 자산화를 직접 굴려보며 가장 많이 실패한 지점이다. 템플릿과 용어집까지는 누구나 모은다. “이 결과가 맞는지”(검증)와 “누가 관리하고 언제 버리는가”(운영)를 같이 묶지 않으면, 자산은 만든 그 주에만 살아 있고 한 분기 뒤엔 아무도 신뢰하지 않는 좀비 자산이 된다.

Skill과 MCP는 다른 일을 한다 — 섞지 마라

둘을 혼동하면 자산화가 어긋난다. 경계는 단순하다.

Skill = 판단·작성 기준. “좋은 PRD는 이렇게 생겼다”, “이건 빠지면 안 된다” 같은 무엇을 어떻게 만들지의 기준. 시스템에 손대지 않는다.
MCP(또는 Tool) = 시스템 접근·실행. “이 DB를 읽는다”, “이 API를 호출한다” 같은 외부 자원 연결. 권한과 금지선이 여기 붙는다.

이 분리는 위험 등급·자율성(16장 참조)과 직접 이어진다. Skill은 피해 반경이 작고(틀린 초안은 버리면 끝), MCP는 무엇을 읽고 쓰느냐에 따라 급격히 커진다. 둘을 묶으면 가벼운 Skill까지 무거운 심의에 걸리거나, 무거운 MCP가 Skill 외피로 통과한다. 자산화의 첫 단추는 분리 등록이다.

자산화 절차: 노하우를 재사용 자산으로 바꾸는 5단계

검증된 업무 기준 하나를 재사용 자산으로 굳히는 절차다. 순서에 의미가 있다. 1단계를 건너뛰고 곧장 Skill 제작으로 가는 것이 가장 흔한 실패다.

[자산화 후보: 한 사람이 잘하는, 검증된 업무 기준]
   │
   ▼
1단계. 검증되었는가?
   (이미 사람 검토·승인·완료를 통과해 품질이 확인된 기준인가)
   ├─ 아니오 → 자산화 보류. 아직 검증 안 된 노하우는 굳히면 안 된다
   └─ 예
        │
        ▼
2단계. 6개 단위로 추출한다
   (용어·형식·연결·권한·검증·운영 — 머릿속에서 글로)
        │
        ▼
3단계. Skill / MCP로 분리한다
   (판단·작성 기준 → Skill / 시스템 접근 → MCP, 권한·금지선 부착)
        │
        ▼
4단계. 검증 기준을 함께 등록한다
   (골든셋·나쁜 예 샘플·통과 게이트를 자산에 묶는다)
        │
        ▼
5단계. 운영 자산으로 등록한다
   (담당 조직·버전·사용량 로그·폐기 기준 부여 → 카탈로그 등재)

1단계 — 검증 먼저. 검증 안 된 개인 습관을 Skill로 굳히면 틀린 기준이 조직 전체로 복제된다. 자산화는 품질의 증폭기라 나쁜 기준도 똑같이 증폭한다. 검증 안 된 후보는 작은 파일럿(8장 참조)으로 검증부터 받는다.

2단계 — 머릿속을 글로. 잘하는 사람의 기준은 대부분 암묵지다. “왜 이 PRD가 좋은가”를 마주 앉아 6개 단위로 받아 적는 작업이 자산화의 절반이다. 건너뛰면 Skill은 빈 템플릿이 된다.

3단계 — 분리. 위 Skill/MCP 경계를 적용한다.

4단계 — 검증 기준 동봉. 템플릿만 주면 형식만 채우고 품질은 빠진다. 좋은·나쁜 샘플(골든셋)을 같이 줘야 Anti-Slop 게이트(6장 참조)가 작동한다.

5단계 — 운영 등재. 담당 조직 없는 자산은 방치되고 폐기 기준 없는 자산은 쌓인다. 카탈로그에 올려 사용량·비용·재사용률을 보이게 한다. 확대·폐기 게이트(12장 참조), 확산(14장 참조)과 연결된다.

한 줄 원칙: 자산화는 “Skill을 만드는 일”이 아니라 “검증된 기준 + 검증 방법 + 운영 책임을 한 묶음으로 등록하는 일”이다. 셋 중 하나라도 빠지면 좀비 자산이다.

만들기 전에 멈추는 질문 — 자산화가 풀스택 핑계가 되지 않게

자산화를 한다면서 새 화면·대시보드·입력 폼을 짓기 시작하면 6장이 막으려던 풀스택 과잉의 다른 얼굴이다. 직무 지식 기반은 기존 자원 위에 얇게 얹는 것이 원칙이다. 착수 전 다음 질문을 통과해야 한다. Anti-Slop 게이트(6장 참조)의 직무 지식판이다.

#	질문	통과하지 못하면
1	기존 협업 도구·사내 시스템·DB view로 해결되지 않는가?	별도 앱 금지. 기존 자원에 얹는다
2	화면이 필요한 문제인가, Skill/MCP+운영 규칙으로 충분한가?	화면부터 만들지 않는다
3	이 직무 지식이 다른 팀에서도 재사용되는가?	재사용 안 되면 자산화 우선순위 낮춤
4	필요한 것은 입력 화면인가, 기존 데이터를 안전하게 읽는 연결인가?	후자면 MCP 연결로 끝, 화면 불필요
5	권한·감사·비용·담당·폐기 기준을 댈 수 있는가?	운영 기준 없으면 등록 보류
6	사람 협업 절차를 그대로 AI에 시키는 대신, AI에 맞는 단위로 다시 나눴는가?	절차 복제. 5장으로 되돌림

별도 화면을 만드는 것이 곧 자산화가 아니다. Skill·MCP로 될 일을 풀스택 앱으로 키우면 재사용 자산이 또 하나의 운영 고정비로 바뀐다.

직무별 1차 자산화 후보

어디부터 손댈지 막막할 때 쓰는 출발표다. 각 직무에서 ‘검증된 기준이 한 사람에게 몰려 있는’ 지점을 1차 후보로 잡았다. 보는 법은 “이 기준이 한 사람 머릿속에만 있는가”다.

직무·영역	먼저 모을 검증된 기준	재사용 자산(Skill/MCP)	기대 효과
Product/PO	PRD 구조, 문제 정의, 수락 기준, 우선순위 근거	PRD 작성 Skill, User Story Skill, PRD 리뷰 Skill	요구사항 품질이 사람 바뀌어도 흔들리지 않는다
Design/Frontend	디자인 시스템, 컴포넌트 규칙, 화면 검수 기준	디자인 시스템 Skill, UI 리뷰 Skill, 컴포넌트 MCP	UI 품질·접근성 기준을 누구나 따른다
Data/BI	지표 정의, 컬럼 의미, 권한, 읽기 전용 질의 기준	메트릭 사전 Skill, DB Query MCP(읽기 전용)	같은 질문에 같은 지표·안전한 질의가 나온다
Operations	승인 조건, 예외 처리, 문서 양식, 반복 업무 흐름	업무 흐름 Skill, 협업도구 MCP, 승인형 자동화 템플릿	새 대시보드 없이 기존 도구 위에서 자동화한다
Business/CS	고객 세그먼트, 제안서 구조, 응대 기준, 금지 표현	제안서 Skill, 응대 Skill, CRM MCP(읽기 위주)	영업·CS 산출의 톤·기준이 일관된다
Engineering	저장소 정책, 테스트 기준, 리뷰 기준, 배포 금지선	코드 리뷰 Skill, CI/Test MCP	팀별 관행이 아니라 공통 검증 기준을 따른다

세 가지 읽기 주의가 있다.

첫째, ‘검증된 기준’이 전제다. 표의 모든 후보는 “이미 잘 작동하는 기준이 있다”를 가정한다. 기준 자체가 흔들린다면 자산화가 아니라 기능별 전환(13장 참조)과 파일럿(8장 참조)으로 기준을 먼저 세운다. 흔들리는 기준을 자산화하면 흔들림을 복제한다.

둘째, MCP에는 권한이 먼저 붙는다. DB Query를 읽기 전용, CRM을 읽기 위주로 명시한 데 의도가 있다. 시스템에 쓰는 MCP는 위험 등급·자율성 심의(16장 참조)를 거친다. 읽기형부터 시작하면 피해 반경이 작다.

셋째, 한 직무 안에서도 Skill과 MCP를 나눈다. Operations의 “승인 조건·예외 처리”는 Skill, “협업 도구 연결”은 MCP다. 한 자산으로 묶지 않는다.

흔한 실패모드

자산화가 무너지는 패턴을 회의에서 알아챌 신호로 정리한다. 자산을 직접 만들고 폐기해보며 밟은 지뢰들이다. 레드플래그는 “이 말이 나오면 의심하라”는 판별구다.

1 — 검증 안 된 노하우 굳히기. 틀린 기준이 조직 전체 품질을 빠르게 끌어내린다. 레드플래그: “이 사람이 잘하니 그대로 Skill로”(검증 없이). 차단: 자산화 1단계.

2 — 템플릿만, 검증 기준 없이. 형식만 채우고 품질은 빠진 산출이 양산된다. 레드플래그: “템플릿 배포 완료”가 자산화 완료로 보고. 차단: 자산화 4단계 + Anti-Slop(6장).

3 — Skill과 MCP 혼동. 가벼운 Skill이 무거운 심의에 걸리거나 위험한 연결이 ‘Skill’ 외피로 통과. 레드플래그: 하나의 자산이 “PRD도 쓰고 DB에도 쓴다”. 차단: 분리 등록 + 위험 등급(16장).

4 — 운영 주인 공석. 한 분기 뒤 누가 고치는지·최신인지 모른다. 레드플래그: “누가 이 Skill 관리해요?”에 답이 없다. 차단: 자산화 5단계.

5 — 자산화를 풀스택 핑계로. 비용 절감 자산이 운영 고정비로 뒤집힌다. 레드플래그: Skill 하나에 서버·DB·인증·화면이 붙는다. 차단: 만들기 전 6개 질문 + Anti-Slop(6장).

6 — 카탈로그 없는 중복 양산. 옆 팀 Skill을 모른 채 또 만든다. 레드플래그: 같은 직무에 비슷한 Skill이 둘 이상 등록. 차단: 최소 카탈로그 + 중복 점검(14장).

7 — 절차 복제 자산. 한 번에 끝낼 일을 쪼개 비용만 키운 자산이 박제된다. 레드플래그: 설명에 “취합 → 전달 → 재확인”이 그대로. 차단: 6개 질문의 6번 + 5장.

Before/After: 한 사람의 노하우 vs 조직의 자산

앞의 B2B SaaS 운영팀을 다시 보자. PRD를 잘 쓰는 PO 한 명에게 품질이 몰려 있다. 그가 빠지면 품질이 흔들리고 되묻기가 늘어 리드타임이 길어진다.

Before — 개인에게 AI를 붙인다

리더는 잘하는 PO에게 최신 AI 도구를 쥐여주고 “더 빨리, 더 많이 쓰라”고 한다. 그는 이미 기준이 머릿속에 있으니 AI로 더 빨라진다. 한 분기 뒤:

그 PO의 처리량은 늘고 개인 leverage는 올랐다. 그러나 다른 PO들의 품질은 그대로다.
그 PO가 빠지자 팀 전체 품질이 다시 무너졌다. 되묻기와 리드타임이 원위치됐다.
경영진 보고: “AI를 도입했고 사용량이 늘었습니다.” → 조직 차원에서 무엇이 좋아졌는지 말할 수 없다(증거 L1에서 멈춘다, 10장 참조).

After — 그의 검증된 기준을 자산으로 굳힌다

리더는 자산화 5단계를 적용한다. 그 PO의 PRD가 이미 검증된 기준임을 확인하고(1단계), 마주 앉아 “왜 이 PRD가 좋은가”를 6개 단위로 추출한다(2단계). 작성 기준은 PRD 작성 Skill로, 요구사항 시스템 연결은 MCP로 분리한다(3단계). 좋은·나쁜 PRD 샘플(골든셋)을 리뷰 Skill에 동봉하고(4단계), 담당 조직·버전·폐기 기준을 붙여 카탈로그에 등록한다(5단계). 한 분기 뒤:

주니어 PO가 Skill로 쓴 요구사항의 검증 기준 통과 비율이 크게 올랐다. 품질이 사람이 아니라 자산에 실렸다.
잘하던 PO가 빠져도 품질이 유지된다. 그는 다른 직무의 기준을 자산화하는 일로 시간을 재배치했다.
경영진 보고: “사람 간 편차를 기준선 대비 줄였고 재사용 자산으로 등록했습니다.” → 비교와 재사용 가능성으로 말할 수 있다(L2~L3로 올라간다).

두 갈래 한 줄 비교

구분	Before (개인에 AI)	After (기준을 자산화)
무엇을 강화했나	잘하는 한 사람	검증된 기준 자체
품질의 위치	사람 머릿속	Skill/MCP 자산
그 사람이 빠지면	품질 붕괴	품질 유지
다른 팀	재발명	재사용
증거 등급	L1(사용·산출)	L2~L3(편차 감소·재사용)
경영 보고	“AI 도입했다”	“편차 줄이고 자산화했다”

두 갈래는 같은 사람, 같은 AI 역량에서 출발했다. 갈린 지점은 하나 — 그의 노하우를 화면에 두었는가, 조직의 자산으로 꺼냈는가다.

리더가 승인·요구할 신호

승인자에게는 “무엇을 보면 통과·반려할지”, 제안을 올리는 실무자에게는 “무엇을 미리 갖춰야 통과되는지”의 체크리스트다. 거버넌스 세부는 16~18장에 있고, 여기서는 회의에서 한 문장으로 쓸 신호만 남긴다.

요구할 것 (없으면 검토 테이블에 올리지 않는다)

검증된 업무는 Skill/MCP 자산으로 등록할 것. “누가 빠져도 같은 품질로 재현되는가”에 답이 없으면 자산이 아니라 부채다.

자산에 검증 기준(골든셋·나쁜 예·통과 게이트)이 동봉되어 있는가. 템플릿만 있고 “무엇이 통과인지”가 없으면 반려.

담당 조직·버전·폐기 기준이 붙어 있는가. 운영 주인 없는 자산은 등록 보류.

Skill(판단)과 MCP(시스템 접근)가 분리 등록되어 있는가. 묶이면 위험 등급 심의(16장 참조)가 어긋난다.

반려할 것

검증되지 않은 개인 습관을 그대로 전사 Skill로 굳히려는 제안.

템플릿만 배포하고 검증 기준 없이 “자산화 완료”로 보고하는 제안.

자산화를 명분으로 새 풀스택 앱·대시보드를 짓는 제안.

사람 협업 절차(“취합 → 전달 → 재확인”)를 그대로 박제한 Skill.

승인할 것 (가치 배분의 기준)

재사용 비중을 가치 배분 근거로. “누가 많이 썼나”가 아니라 “누구의 자산이 여러 팀에서 재사용됐나”를 본다.

잘하는 사람을 ‘더 많이 찍어내는 자리’가 아니라 ‘기준을 자산화하는 자리’로 재배치.

읽기형 MCP부터 시작해 피해 반경이 작은 자산을 먼저 검증하는 순서.

이 장의 요약

검증된 업무 기준이 한 사람 머릿속에만 있으면 자산이 아니라 부채다. AX 확산의 실체는 ‘잘하는 사람을 더 잘하게’가 아니라 **‘그의 검증된 기준을 모두가 쓰게(누가 작업해도 같은 품질)‘**다.
모을 것은 6개 단위 — 용어·판단 / 산출물 형식 / 시스템 연결 / 권한·금지선 / 검증 / 운영. 자주 빠뜨리는 검증·운영 기준이 좀비 자산을 가른다.
Skill(판단·작성)과 MCP(시스템 접근)는 분리 등록. 자산화 5단계: 검증 확인 → 6단위 추출 → Skill/MCP 분리 → 검증 기준 동봉 → 운영 등재.
자산화는 기존 자원 위에 얇게 얹는다. 직무별 후보에서 읽기형 MCP부터 피해 반경이 작은 자산을 먼저 검증한다.
리더가 쥘 신호는 둘 — 요구: 검증된 업무는 Skill/MCP 자산으로 등록. 승인: 사용량이 아니라 재사용 비중으로 가치를 배분한다.

6개 지식 단위·자산화 5단계·만들기 전 6개 질문·실패모드·신호 박스는 도구·모델이 바뀌어도 유지되는 방법론 골격이다. ‘Skill’·‘MCP’ 같은 형식 명칭과 직무별 후보의 구체 자산명은 실행 형식이 바뀌면 명칭만 바꾸고 골격은 그대로 쓰면 된다. 자산화는 13장(기능별 전환의 성공)을 입력으로 받아 14장(확산)으로 넘기는 중간 고리다.