AI 네이티브 조직을 스킬로 설계하고 확장하는 법

원문 제목: AI-Native Organisations Run on Skills: How to Structure and Scale Them — Imad Touil, QuantumBlack

메타데이터

• 채널: aiDotEngineer
• 발표자: Imad Touil, QuantumBlack Distinguished Engineer
• 발행일: 2026-08-29
• 원문 URL: https://www.youtube.com/watch?v=M05vON8i0aI
• 주제: AI 네이티브 조직, 에이전틱 소프트웨어 스택, 스킬 거버넌스와 확장
• 핵심 카테고리: ai-llm

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 네이티브 조직의 생산성·품질·보안·비용을 결정하는 실행 단위는 개인의 프롬프트가 아니라 재사용 가능하고 거버넌스되는 스킬이다.== 조직이 스킬을 중앙에서 발견·평가·버전 관리하고 워크플로에 조합해야 에이전트의 동작을 결정론적으로 확장할 수 있다.

• 스킬은 조직의 노하우를 에이전트가 실행할 수 있는 형태로 바꾸고, 여러 워크플로와 에이전트 하네스 사이에서 옮겨 쓸 수 있게 한다.
• 표준화되지 않은 스킬은 중복, 품질 저하, 보안 취약점, 권한 과다, 토큰 비용 증가라는 새로운 기술 부채가 된다.
• 중앙 스킬 레지스트리와 플랫폼, 명확한 도메인 소유권, 테스트·관찰성·접근 제어를 결합해야 팀 단위 실험이 조직 단위 역량으로 전환된다.

단순한 코딩 에이전트의 specify → design/plan → tasks → implement 흐름은 제품 증분(product increment)을 만드는 한 단계에 불과하다. 실제 조직의 제품 생명주기는 전략·시장조사·고객발견·데이터 준비·개발·플랫폼 운영·출시·최적화와 장애 대응을 포함한다. 이 복잡한 여정을 일관되게 움직이려면 각각의 전문 지식을 스킬로 구조화하고, 스킬을 담은 워크플로를 관리 가능한 실행 자산으로 만들어야 한다.

1. 에이전틱 소프트웨어 스택과 워크플로의 실제 범위

에이전트 시스템은 작업을 실제로 수행하는 안쪽 루프와 조직의 업무 흐름을 조율하는 바깥쪽 루프로 나뉜다.

1.1. 두 개의 루프와 이를 떠받치는 플랫폼

1. 안쪽 루프는 코드 에이전트 하네스(code agent harness)다

   1. 핵심 실행 구성요소: 컨텍스트 관리자(context manager)가 필요한 정보를 조립하고, 도구와 MCP(Model Context Protocol)를 통해 외부 기능을 호출하며, 메모리와 상태를 유지한다.
   2. 스킬 로더: 현재 작업에 필요한 스킬을 찾아 하네스에 주입한다. 어떤 지식을 언제 꺼내 쓸지가 에이전트 실행의 일관성을 좌우한다.

2. 바깥쪽 루프는 워크플로다

   1. 구성요소: 워크플로는 스킬, 서브에이전트, MCP 서버, 필요에 따라 실행 전후의 훅(hook)을 조합한다.
   2. 역할: 개별 도구 호출을 넘어서 조직의 업무 순서와 규칙을 하네스에 전달하며, 반복 업무를 같은 방식으로 재현하는 실행 청사진이 된다.

3. 하단의 활성화(enablement) 구성요소가 두 루프를 운영 가능하게 한다

   1. 환경 샌드박스: 에이전트가 코드를 실행하고 파일을 다루며 실험할 안전한 실행 환경을 제공한다.
   2. MCP 게이트웨이: 조직 전체 MCP 도구를 한곳에서 관리하고 단순화한다.
   3. 모델 게이트웨이: 로컬에서 실행하는 오픈소스 모델과 프론티어 모델을 포함한 여러 LLM을 관리·최적화한다.
   4. 그래프·지식 그래프: IT 핵심 시스템, 코드베이스, 스킬 레지스트리, 워크플로 마켓플레이스를 추상화해 각각의 자산과 관계를 연결한다.

1.2. 컨텍스트 레이어가 조립하는 정보

1. 프로젝트 지침

   1. 프로젝트별 실행 규칙은 Cloud Code의 CLAUDE.md 파일이나 에이전트 지침 파일과 같은 역할을 한다.
   2. 에이전트가 프로젝트의 제약과 목표를 이해하도록 하는 가장 기본적인 컨텍스트다.

2. 도구·MCP 스키마

   1. 어떤 도구가 존재하는지 알려준다.
   2. 각 도구를 언제 선택해야 하는지 이해하게 해 불필요한 호출을 줄인다.

3. 메모리와 사람의 개입

   1. 메모리는 최종 사용자와 나눈 대화 이력과 이전 상태를 보존한다.
   2. 사람은 에이전트 루프 바깥의 감시자가 아니라 필요할 때 판단하고 승인하는 인간 참여자(human in the loop)로 남는다.

4. 검색된 콘텐츠(retrieved contents)

   1. 파일과 코드베이스 등 작업에 필요한 자료를 검색해 컨텍스트에 넣는다.
   2. 컨텍스트 레이어의 목표는 정보를 많이 넣는 것이 아니라 작업 완료에 필요한 것을 적시에 조립하는 것이다.

1.3. 네 단계 코딩 흐름에서 전체 제품 생명주기로

1. 익숙한 네 단계는 제품 증분을 만드는 좁은 흐름이다

   1. 명세(specify): 무엇을 만들지 정의한다.
   2. 설계·계획(design/plan): 어떤 것을 만들지 계획한다.
   3. 작업(tasks): 계획을 실행 가능한 과업으로 쪼갠다.
   4. 구현(implement): 실제로 제품을 만든다.

2. 조직 수준에서는 제품 전략이 먼저다

   1. 무엇을 만들고 어떻게 만들지 정하며, 성공 지표를 정한다.
   2. 제품 로드맵을 식별하고 세부 계획으로 분해한다.
   3. 이를 위해 시장조사, 경쟁 분석, 고객 인터뷰를 통해 전략의 입력을 모은다.

3. 발견(discovery)은 문제와 해법을 검증하는 단계다

   1. 제품 전략을 문제 정의(problem statement)로 분해한다.
   2. 해법을 찾고, 검증하고, 실험한 뒤 사용자 스토리로 구체화한다.

4. 개발 전 데이터와 연결을 준비한다

   1. 제품을 뒷받침할 데이터 카탈로그를 정리한다.
   2. 핵심 시스템과 연결되는 엔드포인트와 통합을 조정한다.
   3. 데이터 제품 전달(data product delivery)에서 데이터 파이프라인을 만들고 데이터 품질을 검증한다.
   4. 개발자가 사용할 카탈로그와 데이터 자산을 준비 상태로 올려놓는다.

5. 제품 증분 이후에도 운영 루프가 이어진다

   1. 조직마다 모바일 애플리케이션, 부서별 플랫폼, 직원용 내부 플랫폼, 고객 대면 제품 등 서로 다른 SDLC가 흩어져 있다.
   2. 따라서 조직 전체를 위한 하나의 만능 워크플로는 존재하지 않는다.
   3. 플랫폼 엔지니어링·운영 단계에서는 인프라를 프로비저닝하고, 인프라 코드(IaC) 모듈을 설계·관리한다.
   4. 제품을 출시한 다음에는 성능을 최적화하고, 장애를 탐지·해결하면서 다시 다음 변경의 루프로 들어간다.

6. 규모가 커질수록 보이지 않는 복잡성이 커진다

   1. 혼자 만들고 배포할 수 있는 간단한 제품과 달리 디지털 플랫폼의 전체 풍경은 훨씬 복잡하다.
   2. 한 번에 제시되는 단순한 그림은 실제 전체의 약 10~20% 정도만 보여주는 수준이며, 구체적인 구성은 조직마다 달라진다.

2. 워크플로에서 스킬이 차지하는 역할

훅·MCP 서버·서브에이전트만으로는 조직의 노하우를 구조화하기 어렵고, 실제로 재현 가능한 행동을 만드는 핵심은 스킬에 있다.

2.1. 네 가지 워크플로 구성요소의 역할과 한계

1. 훅은 이벤트를 연결한다

   1. 훅은 워크플로 앞이나 중간에서 특정 이벤트가 발생하기 전에 어떤 작업을 트리거하는 장치다.
   2. 자체적으로 도메인 노하우를 담기보다는 실행 순서를 여는 역할을 한다.

2. MCP 서버는 필요한 도구를 제공한다

   1. 특정 MCP 도구가 필요할 때 서버를 호출할 수 있다.
   2. 많은 팀은 MCP를 직접 소유·개발하기보다 이미 사용하던 도구가 제공하는 MCP를 그대로 활용한다.
   3. 도구 연결만으로는 그 도구를 어떤 상황에서 어떤 규칙으로 써야 하는지가 구조화되지 않는다.

3. 서브에이전트는 컨텍스트 창을 절약한다

   1. 큰 작업을 특정 과업으로 위임해 주 에이전트의 컨텍스트 윈도우를 줄인다.
   2. 특정 작업을 대신 실행할 뿐 조직의 방법론과 판단 기준 자체를 체계화하는 구성요소는 아니다.

4. 스킬은 조직의 실행 가능한 노하우를 담는다

   1. 도구를 고르는 규칙, 업무 절차, 품질 기준, 규정 지식을 재사용 가능한 형태로 묶는다.
   2. 스킬이 올바르게 구조화되지 않으면 워크플로가 결정론적으로 동작하지 않고, 팀과 에이전트마다 사람이 임의로 해석하게 된다.

2.2. 워크플로는 하네스의 행동을 정하는 청사진이다

1. 개별 호출과 조직 업무를 분리한다

   1. MCP·훅·서브에이전트는 실행에 필요한 부품이다.
   2. 워크플로는 그 부품을 어떤 순서와 조건으로 조합할지 정하는 하네스 청사진(harness blueprint)이다.

2. 스킬은 청사진에 일관된 판단을 공급한다

   1. 동일한 규제 검토나 배포 절차를 여러 팀이 수행하더라도 같은 원칙을 적용할 수 있다.
   2. 에이전트가 매번 사람에게서 지시를 다시 받는 대신 레지스트리에서 검증된 노하우를 꺼내 실행한다.

3. 스킬이 새로운 조직 실행 단위가 되는 이유

스킬은 짧은 유행어가 아니라 마이크로서비스 시대에 해결했던 소프트웨어 설계 문제를 에이전트 노하우에 적용하는 새로운 단위다.

3.1. 도입 확산과 성능 차이

1. 짧은 기간에 표준이 확산됐다

   1. 약 8개월 전 Anthropic이 스킬에 관한 최초의 글을 발표했다.
   2. 약 두 달 뒤 스킬을 위한 오픈 표준이 등장했고, 여러 에이전트 하네스가 이를 채택하기 시작했다.
   3. 올해 2월 무렵에는 대부분의 에이전트가 이 표준을 채택한 것으로 관찰됐다.
   4. 에이전트가 작업 중 스킬을 불러오는 동작은 사고 과정에서 스킬을 가져오는 모습을 통해 확인할 수 있다.

2. 스킬의 수요와 생성량이 빠르게 늘고 있다

   1. 공개 GitHub 저장소와 공개 스킬 레지스트리만 표본으로 살펴봐도 많은 스킬이 존재한다.
   2. 공개된 것보다 더 많은 스킬이 각 조직 내부에서 만들어지고 있으며, 생성 속도와 수요가 함께 증가한다.

3. 모델 자체의 개선과 스킬의 효과는 구분된다

   1. 최신 SkillsBench에서 최신 모델을 스킬 없이 자동화 엔지니어링과 사이버보안 과제에 적용해도 모델 성능 향상에 따라 결과가 좋아진다.
   2. 같은 과제에 스킬을 적용하면 결과의 결정성(determinism)이 더 높아지고, 성능 결과도 명확하게 개선된다.

3.2. 마이크로서비스 설계 원칙을 스킬에 적용하기

1. 재사용 가능하고 모듈식이어야 한다

   1. 하나의 팀에서 만든 스킬을 다른 워크플로에서도 재사용할 수 있어야 한다.
   2. 하나의 거대한 문서나 만능 스킬이 아니라 교체·조합 가능한 모듈로 설계해야 한다.

2. 발견 가능하고 이동 가능해야 한다

   1. 필요한 팀이 자동으로 스킬을 발견하고 가져갈 수 있어야 한다.
   2. 같은 표준을 따르는 하네스라면 Cloud Code에서 만든 스킬을 Cursor로 옮겨도 동작해야 한다.
   3. 조직·워크플로·하네스 사이의 이동성이 스킬의 투자 가치를 높인다.

3. 전문화(specialized)되어야 한다

   1. 하나의 스킬은 하나의 과업을 명확하게 정의해야 한다.
   2. 여러 목적을 한 스킬에 몰아넣는 모놀리식 설계는 호출 조건과 결과를 불명확하게 만든다.

4. 조합 가능(composable)해야 한다

   1. 여러 스킬을 이어 붙여 더 큰 업무를 구성할 수 있어야 한다.
   2. 스킬 사이에 중복과 충돌이 생기지 않도록 경계와 책임을 설계해야 한다.

5. 일관되고 결정론적이어야 한다

   1. 같은 종류의 입력에 팀마다 전혀 다른 규칙을 적용하는 문제를 줄여야 한다.
   2. 품질 기준과 실행 절차를 스킬에 명시해 결과의 변동성을 낮춘다.

6. 비용 효율적이어야 한다

   1. 스킬은 컨텍스트 윈도우 문제를 다룬다.
   2. 점진적 공개(progressive disclosure) 패턴으로 필요한 스킬, 필요한 양, 필요한 시점을 조절한다.
   3. 모든 지식을 매번 컨텍스트에 넣지 않아 토큰 사용량을 줄이고, 조직의 노하우를 실행 가능하면서도 이동 가능하고 저렴한 새 단위로 만든다.

3.3. 데이터 보존 규정 스킬의 구체적 사례

1. 규정 지식을 실행 규칙으로 바꾼다

   1. 고객 데이터를 조작할 때 데이터 보존 규정에 맞도록 에이전트를 지시해야 한다.
   2. 데이터 retention policy를 별도의 전문 스킬로 정의하면 사람이 매번 같은 규정 문장을 프롬프트로 다시 쓰지 않아도 된다.

2. 카탈로그에서 규정 스킬을 조합한다

   1. 스킬 카탈로그 한쪽에는 retention policy 스킬이 놓이고, 다른 쪽의 하네스가 필요한 스킬을 호출한다.
   2. retention policy 외에 disclosure standards, GDPR 규칙, 작성에 사용할 채움 템플릿(fill-in templates)도 함께 필요하다.
   3. 이 요소들은 웹·모바일·기타 애플리케이션에서 만든 데이터와 기능이 조직의 규칙을 지키도록 공통 기준을 제공한다.

3. 런타임 검토와 피드백을 자동화한다

   1. 규제 공개 검토(regulatory disclosure review) 워크플로가 실행 시점에 관련 스킬을 자동으로 가져온다.
   2. 같은 규칙 세트를 적용하므로 검토 결과는 결정론적으로 기대할 수 있다.
   3. 감사 보고서를 저장하고, 개선이 필요한 항목을 특정해 다음 개선 루프로 보낸다.

4. 거버넌스가 없을 때 생기는 새로운 기술 부채

스킬을 개인과 팀이 빠르게 만들기만 하고 관리하지 않으면, 기존 기술 부채와 다른 형태의 중복·품질·보안·권한 문제가 쌓인다.

4.1. 중복과 품질 저하

1. 팀 간 중복이 구조적으로 생긴다

   1. 팀들이 서로 협업하지 않고 같은 기술 스택과 인프라를 사용한다면 동일한 스킬을 반복해서 만든다.
   2. 공유되지 않는 스킬은 조직 전체의 자산이 아니라 각 팀의 고립된 복사본으로 남는다.

2. 검증하지 않은 스킬은 시간이 지날수록 약해진다

   1. 과업에 맞는지 테스트하고 유지·관리해야 한다.
   2. 과업뿐 아니라 새로 나온 최신 모델에서도 스킬이 제대로 작동하는지 검증해야 한다.
   3. 이 검증이 없으면 모델이 바뀔 때 호출 방식과 결과 품질이 서서히 저하된다.

4.2. 발견 가능성·소유권·조합성

1. 카탈로그가 없으면 필요한 스킬을 찾을 수 없다

   1. 중앙 거버넌스가 없을 때 조직 안에 어떤 스킬이 있는지조차 알기 어렵다.
   2. 스킬은 과거 내부 개발자 포털(IDP)이 마이크로서비스 문제를 해결했던 방식과 비슷한 발견성 문제를 갖는다.

2. 소유자가 있어야 유지보수가 지속된다

   1. 서비스 카탈로그에서 마이크로서비스의 담당자를 찾듯 스킬에도 도메인 소유자를 기록해야 한다.
   2. 소유자가 없으면 아무도 업데이트·품질 개선·보안 패치를 책임지지 않는다.

3. 조합성은 저절로 생기지 않는다

   1. 무엇을 만들고 어떻게 설계할지 맞추는 거버넌스가 필요하다.
   2. 도메인 주도(domain-driven) 접근으로 스킬의 경계와 카탈로그 구조를 설계해야 중복과 충돌을 줄일 수 있다.

4.3. 보안과 권한

1. 공개 스킬도 공급망 위험을 가진다

   1. 공개 스킬에는 프롬프트 인젝션이 포함될 수 있다.
   2. 스킬은 특정 과업을 결정론적으로 수행하기 위해 스크립트를 포함할 수 있으므로, 단순한 프롬프트 문서보다 실행 보안 검토가 중요하다.
   3. 보안 검사 파이프라인이 없으면 조직이 안전하지 않은 스킬을 그대로 가져올 수 있다.

2. 모든 사람이 모든 스킬에 접근해서는 안 된다

   1. 일부 스킬은 민감한 비즈니스 로직을 담는다.
   2. 사용자·팀·환경별 접근 제어를 설정해 누가 무엇을 호출할 수 있는지 관리해야 한다.

5. 개인 실험을 조직 역량으로 확장하는 운영 모델

확장은 개인의 자유로운 제작을 막는 방식이 아니라 개인→팀→중앙 플랫폼→도메인 거버넌스의 경로를 만드는 방식으로 진행된다.

5.1. 개인과 팀에서 시작하기

1. 개인이 만들고 검증할 공간을 허용한다

   1. 개인이 스킬을 만들고, 테스트하고, 개선하고, 실제로 사용할 수 있어야 한다.
   2. 무작위로 각자 다른 방식을 택하는 것이 아니라 조직이 합의한 도구와 메커니즘 안에서 실험하게 한다.

2. 팀 공유로 빠른 학습을 만든다

   1. 스킬을 만든 즉시 팀에 공유한다.
   2. 같은 기술 스택으로 같은 제품을 만드는 동료들이 함께 개선하므로 스킬이 빠르게 진화한다.

5.2. 중앙 플랫폼의 필수 기능

1. 검색 가능한 메타데이터 카탈로그

   1. 모든 스킬의 설명, 용도, 도메인, 소유자, 상태를 메타데이터로 기록한다.
   2. 키워드나 구조화된 조건으로 검색해 필요한 스킬을 발견할 수 있어야 한다.

2. MCP와 CLI를 통한 배포 경로

   1. MCP를 카탈로그에 연결해 에이전트가 실행 중 필요한 스킬을 검색하게 한다.
   2. CLI로 스킬을 로컬 IDE 또는 개발 팩토리의 샌드박스로 가져오게 한다.

3. 의존성과 버전·수명주기 관리

   1. 한 스킬이 다른 스킬에 의존하는 관계를 이해해야 한다.
   2. 어떤 버전이 최신이고 어떤 변경이 승인됐는지 수명주기로 관리한다.
   3. 에이전트가 기능을 만들 때 레지스트리의 최신 버전을 자동으로 식별하고 가져오게 하면 오래된 규칙을 계속 쓰는 문제가 줄어든다.

4. 접근 제어·평가·관찰성

   1. 누가 무엇을 사용하고 있는지 추적해 권한 공백을 막는다.
   2. 스킬의 호출 결과와 품질을 평가하고, 운영 중 동작을 관찰할 수 있어야 한다.
   3. 플랫폼 기술만으로는 조직의 정책과 책임을 결정할 수 없으므로 기술 기능 위에 거버넌스 운영을 올려야 한다.

5.3. 도메인 소유자와 조직 거버넌스

1. 여러 리더가 영역별 책임을 나눈다

   1. 아키텍트, 엔지니어링 리드, 인프라 리드, 사이버보안 리드 등이 각자의 도메인을 맡는다.
   2. 각 도메인 소유자는 스킬이 조직 정책에 맞게 업데이트되는지 확인한다.

2. 중앙 플랫폼은 양방향 흐름을 만든다

   1. 모든 팀이 중앙의 고품질 스킬을 가져와 실행한다.
   2. 팀이 개선한 스킬은 다시 중앙 플랫폼으로 올려 조직 전체가 재사용한다.
   3. 이 흐름이 자리 잡으면 지식이 특정 개인이나 팀에 갇히지 않고 조직의 공유 실행 자산이 된다.

6. 시뮬레이션으로 본 6개월의 변화

조직 안에서 이미 일어나는 스킬 생성과 사용을 가시화하면, 거버넌스가 생산성·품질·보안·비용에 미치는 관계가 드러난다.

6.1. 거버넌스 전의 조직 상태

1. 시뮬레이션 조건

   1. 15개의 임의 팀을 만들고 팀마다 약 5~12명의 엔지니어를 배치한다.
   2. 엔지니어 1명당 스킬 기여 수, 하루 평균 스킬 사용량, 팀 간 중복 비율, 스킬 품질 비율, 보안 비율을 측정한다.
   3. 이 상태를 6개월 동안 실행해 조직이 자연스럽게 어떤 방향으로 움직이는지 본다.

2. 생산성은 스킬과 직접 연결된다

   1. 규정 스킬이 없으면 개발자는 규정을 확인하고 에이전트를 조정하느라 같은 지시를 반복하며 이른바 바이브 코딩(vibe coding)처럼 앞뒤로 시행착오를 겪는다.
   2. 사람이 올바른 방향을 찾는 동안 토큰 비용이 늘고, 작업 시간도 길어진다.

3. 품질·보안과 팀 성숙도가 갈라진다

   1. 명확하게 정의되고 유지되는 스킬이 없으면 구현 품질과 보안 판단이 사람 개인에게 맡겨진다.
   2. 팀마다 성숙도가 달라 동일한 조직 안에서도 생산성·품질·보안 편차가 커진다.
   3. 한 팀은 생산성이 중간 수준이고, 다른 팀은 생산성·품질·보안이 낮거나 중간 수준인데도 비용은 매우 높게 나타날 수 있다.

6.2. 거버넌스 후의 공통 기반

1. 모든 팀이 완벽하게 같아지는 것은 아니다

   1. 거버넌스가 적용돼도 일부 스킬은 분리되거나 팀별로 다르게 발전한다.
   2. 조직의 현실을 완벽하게 통일하기보다 공통 기반을 만드는 것이 목표다.

2. 기존 스킬의 재발견이 중복을 줄인다

   1. 한 스킬을 중앙에서 공개하면, 다음 엔지니어가 새 스킬을 만들려 할 때 코딩 에이전트 하네스가 이미 존재하는 스킬을 식별한다.
   2. 하네스는 기존 스킬을 가져와 재사용하므로 팀마다 같은 기능을 처음부터 다시 만드는 문제가 줄어든다.

3. 공통 기반이 네 가지 지표를 함께 개선한다

   1. 중앙 스킬은 팀별 실행 편차를 낮춰 생산성과 품질을 안정화한다.
   2. 규칙과 보안 검사를 공유해 보안 비율을 높인다.
   3. 중복 구현과 불필요한 토큰 사용을 줄여 비용을 낮춘다.

7. 스킬에서 워크플로 전체로 확장하기

스킬 레지스트리를 만드는 것만으로 조직의 에이전틱 운영이 끝나지 않으며, 같은 거버넌스 접근을 워크플로 전체에 적용해야 한다.

7.1. 중앙 워크플로 플랫폼

1. 워크플로도 중앙 자산으로 관리한다

   1. 플랫폼은 스킬을 포함한 조직의 워크플로를 한곳에서 제공한다.
   2. 엔지니어는 필요한 업무를 발견하고, 이미 갖춰진 스킬과 실행 순서를 활용해 워크플로를 실행할 수 있다.

2. 인프라 프로비저닝 사례

   1. 새로운 엔지니어가 인프라를 프로비저닝해야 할 때 중앙 플랫폼에서 해당 워크플로를 찾는다.
   2. 워크플로가 요구하는 스킬을 함께 가져와 실행하고 테스트한다.
   3. 개선이 필요한 부분이 발견되면 수정한 워크플로를 중앙 플랫폼에 다시 올린다.

7.2. 성숙한 실행 모델

1. 스킬은 워크플로의 한 구성요소다

   1. 스킬을 잘 관리해도 훅, MCP, 서브에이전트, 환경, 모델, 컨텍스트가 정돈되지 않으면 전체 결과는 불안정하다.
   2. 따라서 스킬에서 얻은 재사용·검색·평가·거버넌스 원칙을 워크플로의 다른 구성요소에도 적용해야 한다.

2. 워크플로 개선이 다시 중앙으로 환류된다

   1. 중앙에서 실행한 결과와 관찰 데이터를 바탕으로 워크플로를 개선한다.
   2. 검증된 개선본을 다시 공유하면 다음 실행자가 더 높은 품질의 기본값을 사용한다.

8. 앞으로 6~8개월 동안 주목할 변화

현재의 스킬 생태계는 시작 단계이며, 레지스트리·평가·자동 진화가 다음 핵심 전장이 된다.

8.1. 스킬 레지스트리

1. 조직은 레지스트리를 갖춰야 한다
   1. 아직 레지스트리가 없다면 도입을 탐색할 시점이다.
   2. 내부 개발자 포털(IDP) 문제를 해결해 온 플랫폼들이 스킬을 중앙화하는 기능을 이미 추가하기 시작했다.
   3. 현재 기능이 없더라도 몇 달 안에 기존 IDP 플랫폼과 전용 도구에서 이 역량을 볼 가능성이 높다.

8.2. 스킬 평가

1. 평가 방식은 아직 합의 중이다

   1. 무엇을 기준으로 스킬 품질을 평가할지에 관한 논의가 진행 중이다.
   2. 실용적인 출발점은 스킬을 정적으로 테스트하거나 Anthropic의 스킬 작성 모범 사례에 맞춰 평가하는 것이다.

2. 호출과 구조를 먼저 점검한다

   1. 스킬이 적절한 상황에서 호출되지 않으면 내용이 좋아도 효과가 없다.
   2. 구조가 모범 사례에 맞지 않으면 높은 품질을 기대하기 어렵다.
   3. 호출 조건과 구조 검사는 더 복잡한 업무 벤치마크에 앞서 적용할 수 있는 간단하고 가치 있는 평가다.

8.3. 자동 진화(auto-evolving)와 거버넌스의 긴장

1. 폐쇄 루프 자동 개선이 다음 유행으로 부상한다

   1. 스킬을 만들고, 사용하고, 결과를 측정하고, 스스로 개선하는 폐쇄 루프를 만들자는 아이디어가 확산되고 있다.
   2. 스킬이 자동으로 진화하면 현재보다 영향력이 훨씬 커질 수 있다.

2. 가드레일 없는 자동화는 위험을 증폭한다

   1. 거버넌스 없이 자동 진화를 켜면 낮은 품질의 규칙, 보안 취약점, 잘못된 정책이 자동으로 유지·확장될 수 있다.
   2. 자동 진화보다 먼저 조직의 정책·소유권·평가·접근 제어라는 가드레일을 마련해야 한다.

주요 발언 모음

“조직의 모든 노하우는 결국 스킬 수준에 있다.”

“스킬의 구조가 올바르지 않다면 결정론적인 워크플로를 갖고 있다고 할 수 없다.”

“스킬은 조직의 노하우를 실행 가능하고, 이동 가능하며, 저렴하게 만드는 새로운 단위다.”

“스킬을 거버넌스하지 않으면 새로운 종류의 기술 부채를 만들기 시작한다.”

“스킬은 시작일 뿐이다.”

핵심 데이터 & 수치

• 약 8개월 전: Anthropic이 스킬에 관한 최초의 글을 발표한 시점으로 언급됐다.
• 약 2개월 뒤: 스킬 오픈 표준이 등장하고 여러 에이전트 하네스가 채택하기 시작했다.
• 올해 2월 무렵: 대부분의 에이전트가 스킬 표준을 채택한 것으로 관찰됐다.
• 10~20%: 단순한 설명 그림이 조직의 실제 디지털 플랫폼 전체 복잡성에서 차지하는 대략적인 범위다.
• 15개 팀: 거버넌스 전후를 비교하기 위한 시뮬레이션의 팀 수다.
• 팀당 약 5~12명: 시뮬레이션에 배치한 팀별 엔지니어 규모다.
• 6개월: 스킬 생성·사용, 중복, 활용도, 품질, 보안 변화를 관찰한 시뮬레이션 기간이다.

결론 및 시사점

1. 개인이 잘 쓰는 프롬프트나 도구보다 조직의 지식을 반복 실행 가능한 스킬로 구조화하는 일이 AI 네이티브 전환의 기반이다.
2. 모든 스킬에 재사용성·모듈성·발견성·이동성·전문화·조합성·일관성·비용 효율성 기준을 적용해야 한다.
3. 중앙 카탈로그에는 소유자, 메타데이터, 의존성, 버전, 수명주기, 접근 권한, 평가 결과와 관찰 데이터를 함께 기록해야 한다.
4. 공개 스킬과 스크립트는 프롬프트 인젝션 및 공급망 위험을 가질 수 있으므로 보안 파이프라인과 권한 모델을 배포 전에 통과시켜야 한다.
5. 개인 실험을 허용하되 팀 공유와 중앙 플랫폼 환류를 의무화하면 빠른 학습과 조직 공통 기반을 동시에 얻을 수 있다.
6. 스킬 레지스트리를 먼저 만들고, 이후 스킬을 포함하는 워크플로 전체를 중앙에서 검색·실행·테스트·개선하는 방향으로 확장해야 한다.
7. 자동 진화 스킬은 강력한 생산성 레버리지가 될 수 있지만, 정책·소유권·평가·가드레일이 갖춰진 뒤에 도입해야 한다.

20줄 핵심 요약

AI 네이티브 조직의 실행 단위는 개인 프롬프트가 아니라 거버넌스되는 재사용 가능 스킬이다.

에이전틱 소프트웨어 스택은 코드 에이전트 하네스의 안쪽 루프와 조직 워크플로의 바깥쪽 루프로 구성된다.

컨텍스트 관리자는 프로젝트 지침, 도구 스키마, 메모리, 사람의 판단, 검색 콘텐츠를 작업에 맞게 조립한다.

명세·계획·작업·구현의 네 단계는 전체 제품 생명주기에서 제품 증분을 만드는 한 단계에 불과하다.

실제 제품 생명주기는 전략, 성공 지표, 로드맵, 시장조사, 경쟁 분석, 고객 인터뷰를 함께 요구한다.

발견 단계는 문제 정의, 해법 탐색, 검증, 실험, 사용자 스토리 작성으로 이어진다.

개발 전에는 데이터 카탈로그, 핵심 시스템 통합, 파이프라인, 데이터 품질을 준비해야 한다.

출시 뒤에도 플랫폼 운영, 성능 최적화, 장애 해결이 반복되므로 조직에는 여러 전문 워크플로가 필요하다.

훅·MCP 서버·서브에이전트는 부품이고, 스킬은 조직의 판단 기준과 노하우를 실행 가능하게 만든다.

스킬이 올바르게 구조화되지 않으면 팀과 에이전트마다 다른 해석을 하게 되어 결정론적 워크플로가 깨진다.

좋은 스킬은 재사용 가능하고 모듈식이며 발견·이동·전문화·조합이 가능해야 한다.

점진적 공개는 작업에 필요한 스킬만 적시에 컨텍스트에 넣어 토큰 사용량과 실행 비용을 줄인다.

데이터 보존 정책과 GDPR 규칙을 스킬로 조합하면 규제 검토와 감사 보고서 생성을 일관되게 수행할 수 있다.

거버넌스가 없으면 스킬 중복, 품질 저하, 발견 실패, 소유권 공백, 보안 취약점, 권한 과다가 쌓인다.

개인은 스킬을 만들고 테스트하며 팀은 공유·협업하고 중앙 플랫폼은 카탈로그·버전·의존성·권한을 관리해야 한다.

아키텍트와 엔지니어링·인프라·보안 리드는 도메인별 스킬 정책과 업데이트 책임을 맡아야 한다.

15개 팀을 6개월 관찰한 시뮬레이션은 중앙 스킬 공유가 생산성·품질·보안·비용의 편차를 줄임을 보여준다.

중앙 워크플로 플랫폼은 인프라 프로비저닝 같은 업무에 필요한 스킬을 함께 제공하고 개선본을 다시 수집한다.

스킬 레지스트리와 호출·구조 중심의 정적 평가가 다음 단계의 핵심 인프라가 된다.

자동 진화 스킬은 가드레일 없는 상태에서 기술 부채와 보안 위험까지 자동으로 확대할 수 있으므로 거버넌스 뒤에 도입해야 한다.