조직의 노하우는 이제 스킬에 산다 — 거버넌스 없는 스킬은 새로운 기술부채다

1. 이 글은 무엇에 관한 글인가?

QuantumBlack(McKinsey)의 Imad Touil이 AI Engineer World's Fair에서 한 발표 AI-Native Organisations Run on Skills: How to Structure and Scale Them을 보고 정리한 글입니다.

발표는 청중에게 손을 들라는 질문 세 개로 시작합니다. 그리고 그 손이 접히는 순서 가 발표 전체입니다.

"스킬을 만들어 쓰고 계신 분?"              → 방의 대부분
"팀과 공유하고 계신 분?"                   → 더 적게
"조직 차원에서 관리·유지보수하고 계신 분?"   → 몇 명

지난 글이 "내 저장소 안의 스킬을 어떻게 쓸 것인가" 였다면, 이번 글은 그 한 층 위입니다 — "조직 전체의 스킬을 누가 소유하고, 어떻게 배포하고, 무엇으로 검증할 것인가." 개인의 습관이었던 것이 자산이 되는 순간 완전히 다른 문제가 됩니다.

발표의 주장을 한 줄로 줄이면 이렇습니다.

스킬은 조직의 노하우가 실제로 사는 곳이 됐다. 그리고 지금 관리하지 않으면, 그건 새로운 종류의 기술부채 가 된다.

2. 워크플로우의 네 조각 중 왜 스킬만 남는가

발표는 에이전틱 스택을 두 개의 루프로 나눕니다.

그리고 아우터 루프의 네 조각을 하나씩 지웁니다. 이 소거법이 이 발표에서 제일 날카로운 부분입니다.

결국 당신의 노하우는 전부 스킬 레벨에 있습니다. 그리고 스킬의 구조가 잡혀 있지 않다면, 그 워크플로우는 애초에 결정론적이었던 적이 없습니다.

이 마지막 문장이 핵심입니다. "우리 워크플로우는 결정론적이다" 라는 말은 스킬이 구조화돼 있을 때만 참입니다. 스킬이 사람마다 다르게 써진 텍스트 뭉치라면, 워크플로우는 이름만 워크플로우입니다.

참고로 발표는 워크플로우를 하네스 블루프린트 로 정의합니다 — 런타임에 하네스의 행동을 규정하는 설계도. 이 정의가 뒤에서 "워크플로우도 카탈로그에 올려라"로 이어집니다.

3. 우리가 워크플로우라 부르는 건 전체의 한 칸이다

이 절이 개인적으로 이 발표에서 제일 값어치 있었습니다.

우리가 아는 개발 워크플로우는 보통 네 단계입니다.

specify → design/plan → tasks → implement

대부분의 코딩 에이전트가 이 모양으로 만들어져 있습니다. 그런데 발표의 지적은 이겁니다 — 조직 규모에서 보면 이 네 단계 전체가 여정의 한 칸 입니다. 제품 증분(product increment) 하나를 만드는 칸.

비즈니스가 가치를 만들어 고객에게 배송하기까지의 실제 전체 수명주기는 이렇습니다.

그리고 더 중요한 지적이 하나 더 붙습니다. 조직은 이 수명주기를 하나만 돌리지 않습니다. 18년 커리어에서 본 모든 조직에 SDLC가 여러 벌 흩어져 있었다는 것 — 모바일 앱용, 부서별, 플랫폼별, 사내 임직원용, 고객 대면용. 무엇이든 만들어낼 수 있는 하나의 워크플로우 같은 건 없습니다.

여기서 제 결론은 이렇습니다. 코딩 에이전트 업계는 지금까지 가장 안쪽 10%를 최적화해왔습니다. specify→implement 구간은 도구가 넘쳐나지만, 그 바깥 여섯 단계는 대부분 사람의 머릿속과 컨플루언스 문서에 있습니다. 그리고 그 바깥이야말로 조직마다 다른, 즉 노하우가 몰려 있는 구간입니다.

4. 스킬을 마이크로서비스처럼 설계하라

발표는 스킬 설계를 새 문제로 다루지 않습니다. 마이크로서비스 시절에 이미 풀어본 문제 라는 겁니다.

이식성 항목은 실무적으로 큰 얘기입니다. 표준이 공유되니 Claude Code에서 쓰던 스킬을 Cursor로 옮겨도 그대로 돌아간다 는 것. 스킬이 특정 벤더에 묶이지 않는다는 뜻이고, 그래서 조직 자산이 될 자격이 생깁니다.

발표의 정리 문장은 이렇습니다.

스킬은 조직의 노하우를 실행 가능하고(executable), 이식 가능하고(portable), 저렴하게(cheap) 만드는 새로운 단위다.

조합 예시 — 규제 대응

발표가 든 예가 구체적이라 옮깁니다. 왼쪽에 스킬 카탈로그, 오른쪽에 하네스가 있습니다.

[스킬 카탈로그]                        [런타임]                    [산출물]
데이터 보존 정책(retention policy)  ┐
공시 표준(disclosure standards)     ├→ 규제 공시 리뷰 워크플로우 →  감사 리포트(보관 가능)
GDPR 규칙                           │   (런타임에 자동으로 pull)     개선 지점 식별
채워 넣을 템플릿                    ┘                              → 코드베이스로 피드백 루프

웹이든 모바일이든 어느 애플리케이션에서 만들어진 기능이든 같은 규칙을 지키게 만드는 방법 이 이겁니다. 그리고 산출물이 감사 리포트라는 게 중요합니다 — 지난 글에서 정리한 "검증 가능한 산출물이 남는가" 기준을 조직 단위로 올린 형태입니다.

5. 거버넌스가 없으면 생기는 것 — 새로운 기술부채

발표가 꼽는 목록입니다. 하나하나가 마이크로서비스 시절에 겪어본 것들입니다.

이 발표에서 가장 중요한 한 문장

보안 항목의 논리가 특히 날카롭습니다.

스킬은 스크립트를 갖고 있습니다. 그게 결정론적인 부분이기 때문입니다.

이 두 문장이 붙어 있는 게 핵심입니다. 스킬이 결정론적인 이유가 특정 작업에 특정 스크립트를 실제로 실행하기 때문 이고, 그건 동시에 스킬이 공급망(supply chain) 이라는 뜻입니다. 둘은 같은 성질의 양면이라 하나만 취할 수 없습니다.

그래서 발표의 결론은 이겁니다 — 검사 파이프라인 없이 공개 스킬을 pull 하는 건 공급망 결정 입니다. npm install에 대해 우리가 배운 것과 정확히 같은 얘기이고, 다만 이번엔 컴파일 단계도 타입 시그니처도 없는 마크다운 파일 이라 더 조용히 들어옵니다.

품질 저하 — 스킬은 코드와 다르게 썩는다

"작업이 아니라 최신 모델에 대고 검증하라" 는 지적은 한 번 더 씹어볼 만합니다.

스킬은 대개 모델의 실패 양상을 상대로 씁니다. "이 모델은 테스트를 건너뛰니까 명시적으로 시켜라", "이 모델은 스코프를 넘으니까 못박아라." 그런데 모델은 몇 주마다 새 버전이 나옵니다. 그러면 스킬의 일부는 이미 필요 없어진 지시 가 되고(순수 토큰 낭비), 일부는 새 모델의 더 나은 기본 동작을 억누르는 안티패턴 이 됩니다.

일반 코드:  런타임이 그대로면 어제 맞던 게 오늘도 맞다
스킬:      실행 환경(모델)이 몇 주마다 새 버전으로 갈린다

스킬은 자기가 가정하는 환경이 계속 바뀌는 코드 입니다. 그래서 "한 번 잘 써두면 끝"이 성립하지 않는 종류의 자산입니다.

6. 성숙도 사다리 — 개인 → 팀 → 중앙 플랫폼

발표가 제시하는 도입 경로는 세 칸입니다.

중앙 플랫폼에 필요한 것들이 구체적입니다.

• 메타데이터가 붙은 카탈로그 — 검색 가능해야 한다
• 카탈로그에 붙은 MCP + CLI — 스킬을 검색해서 IDE나 샌드박스로 pull 해오는 경로
• 의존성 — 스킬 간 의존 관계를 알아야 한다
• 버저닝과 수명주기 — 에이전트가 최신 버전이 있다는 걸 알아채고 끌어온다
• 접근제어 — 누가 무엇에 접근하는지
• 평가와 관측성

그리고 발표에서 제일 정직한 문장이 여기서 나옵니다.

이 모든 게 거버넌스 위에서 돌아갑니다. 그리고 여기가 기술이 문제를 푸는 걸 멈추는 지점 입니다.

카탈로그를 다 만들어놔도 "그래서 누가 관리하는가" 는 남습니다. 발표는 아키텍트·엔지니어링 리드·인프라 리드·보안 리드가 각자 도메인을 소유하고 정책에 맞게 스킬을 갱신해야 한다고 말합니다. 조직도 문제 라는 걸 숨기지 않는 게 좋습니다.

15개 팀 6개월 시뮬레이션

발표는 팀 15개(팀당 5~12명)에 엔지니어당 스킬 기여도 · 하루 평균 스킬 사용량 · 팀 간 중복 비율 · 품질·보안 비율을 넣고 6개월을 돌려봅니다.

거버넌스가 없을 때의 관찰이 현실적입니다.

규제 스킬이 없으면, 누군가는 에이전트를 제대로 조종하려고 앞뒤로 바이브 코딩 을 합니다. 비용 측면에서 토큰을 더 태우고, 생산성 측면에서 한 번에 나올 답을 시간을 들여 받습니다.

그리고 품질·보안도 같습니다. 스킬이 정의·유지되지 않으면 판단이 전부 사람에게 떨어지고, 팀별 성숙도 차이가 그대로 결과물 편차가 됩니다.

거버넌스를 넣으면? 발표는 과장하지 않습니다 — 완벽해지지 않고, 갈라지는 팀도 여전히 있습니다. 다만 공통 지반이 생깁니다. 스킬 하나가 퍼블리시되면 다음 엔지니어가 새 스킬을 만들려 할 때 하네스가 이미 있는 스킬을 알아보고 끌어옵니다.

7. 다음에 오는 것 — 그리고 순서를 틀리면 안 되는 이유

발표가 마지막에 꼽는 세 가지입니다.

그리고 경고가 붙습니다.

가드레일이 되는 거버넌스 없이 자가 진화를 켜면, 그 영향은 지금보다 훨씬 커집니다.

저는 이 순서 얘기가 이 발표의 진짜 결론이라고 봤습니다. 자동화는 증폭기 입니다. 중복·품질저하·주인 없음이 있는 상태에서 자동 진화를 켜면 그 셋이 자동으로 증식합니다. 자가치유 하네스 글에서 정리했던 것과 같은 이야기 — 규칙을 자동으로 더하는 장치를 만들기 전에, 더해진 규칙이 나빠졌는지 확인하는 장치가 먼저 있어야 합니다.

8. 이 저장소에 대입해보면 — 나는 2단에 있고, 3단은 필요 없다

읽기만 하면 남는 게 없으니 이 블로그 저장소에 대봤습니다.

이 저장소에는 하네스 스킬이 여러 개 붙어 있습니다 — frontend-harness, product-spec-harness, test-layering-harness, git-harness. 발표의 사다리로 재보면 이렇습니다.

여기서 정직하게 갈라야 할 게 있습니다. 3단 전체가 나에게 필요한 건 아닙니다. 발표의 청중은 팀 15개짜리 조직이고, 이 저장소는 블로그 한 개입니다. 카탈로그·MCP 검색·접근제어는 명백한 오버엔지니어링입니다.

그런데 팀 규모와 무관하게 필요한 두 개 가 있습니다.

규모를 타는 것:  카탈로그 · 검색 MCP · 접근제어 · 소유자 지정 · 중복 탐지
규모를 안 타는 것: 버저닝(스킬이 언제 왜 바뀌었나) · eval(바뀐 스킬이 나빠졌나)

그리고 이 저장소에는 그 두 개가 다 없습니다. 지난 글에서도, 그 전 글에서도 같은 구멍을 지적했는데 이번 발표가 이유를 하나 더 줍니다 — 모델이 바뀔 때마다 스킬이 조용히 썩는다. 5절에서 정리한 그 이야기입니다. 스킬을 안 건드려도 환경이 갈리면 품질이 떨어지는데, 그걸 알아챌 장치가 0개입니다.

그래서 이 저장소에서 실제로 할 일은 이 두 줄로 좁혀집니다.

1. 스킬 변경을 커밋 단위로 추적 가능하게 — 어떤 스킬이 언제 왜 바뀌었는지가 남아야 롤백이 된다
2. 스킬에 대한 회귀 테스트 몇 개 — 대표 작업 몇 개를 스킬 유무·모델 버전별로 돌려 비교

카탈로그를 만드는 것보다 이쪽이 훨씬 값이 큽니다. 그리고 이건 조직에서도 순서가 같습니다 — 평가 없는 카탈로그는 썩은 스킬을 더 효율적으로 배포하는 장치 이기 때문입니다.

9. 오해하기 쉬운 지점

오해 1 — "카탈로그를 만들면 거버넌스다"

발표가 직접 못박습니다. 카탈로그·버저닝·접근제어를 다 만들어도 "여기서 기술이 문제 푸는 걸 멈춥니다." 카탈로그는 발견 을 풀고, 거버넌스는 소유와 정책 을 푸는 문제입니다. 소유자 이름이 붙지 않은 카탈로그는 잘 정리된 창고일 뿐입니다.

오해 2 — "마이크로서비스에서 해봤으니 안전하다"

발표의 처방은 마이크로서비스 거버넌스를 통째로 빌려옵니다. 좋은 처방인데, 저는 여기에 단서를 답니다. 마이크로서비스 거버넌스는 대체로 잘 안 됐습니다. 그리고 스킬은 더 빨리 어긋납니다.

빠르게 복제되고, 계약이 없고, 틀려도 그럴듯한 것 — 이건 거버넌스가 더 급하다 는 뜻이지 해본 문제라 안심해도 된다는 뜻이 아닙니다.

오해 3 — "스킬은 텍스트니까 안전하다"

5절 그대로입니다. 스킬은 스크립트를 포함하고, 그게 결정론의 원천입니다. 공개 스킬을 검사 없이 가져오는 건 의존성을 추가하는 것과 같은 무게의 결정입니다.

오해 4 — "최신 버전을 자동으로 끌어오면 좋다"

발표는 에이전트가 최신 스킬 버전을 알아채고 pull 하는 걸 장점으로 듭니다. 편의로는 맞습니다. 다만 자동 최신 pull + 서명·검사 없음 조합은 우리가 이미 아는 사고 패턴입니다. 편의와 공급망 안전은 반대 방향으로 당기고, 그 사이를 메우는 게 6절의 검사 파이프라인 입니다. 둘 중 하나만 도입하면 안 됩니다.

10. 정리

이 블로그에서 이어온 이야기의 다음 칸이기도 합니다.

• 자가치유 하네스 — 규칙을 더할 때 검증하라
• 덜어내는 컨텍스트 엔지니어링 — 규칙을 덜어낼 때 검증하라
• AI 네이티브 SDLC — 프로세스를 바꿀 때 검증하라
• 코드 품질은 제약에 있다 — 에이전트를 둘러싸는 것 으로 검증하라
• 에이전트가 건너뛰는 건 시니어의 일 — 에이전트에게 집어넣는 것 이 스킬이다
• 이번 글 — 그 스킬이 여러 사람 손을 타기 시작하면 무엇이 필요한가

발표의 손 접히는 세 질문으로 돌아가면, 첫 질문에 손을 드는 건 이제 쉽습니다. 어려운 건 세 번째입니다. 그리고 그 어려움은 기술 문제가 아니라 누가 소유할 것인가 의 문제라는 게, 이 발표가 정직하게 인정하는 지점입니다.

참고 문서

• Imad Touil (QuantumBlack, AI by McKinsey), AI-Native Organisations Run on Skills: How to Structure and Scale Them — AI Engineer World's Fair
• 이전 글 — 에이전트가 건너뛰는 건 언제나 시니어의 일이다 · 코드 품질은 제약에 있다 · AI 네이티브 SDLC 플레이북