AI 네이티브 조직은 스킬로 움직인다: 구조화와 확장 전략

URL: https://www.youtube.com/watch?v=0qySk1fcf6k 날짜: 2026-08-30 채널: Tech Bridge

---

📌 핵심 질문 / 핵심 논점과 근거

==AI 네이티브 조직은 에이전트의 스킬(Skill)을 개인의 임시 프롬프트가 아니라 재사용·조합·검증·통제가 가능한 실행 단위로 다뤄야 생산성 향상을 조직 전체로 확장할 수 있다.==

• 스킬은 코딩 에이전트 하네스(harness)의 내부 루프와 조직 워크플로의 외부 루프를 연결하는 노하우의 핵심 단위다.
• 마이크로서비스(Microservice)의 재사용성·모듈성·발견 가능성·조합성·일관성 원칙은 스킬 설계에도 그대로 적용된다.
• 거버넌스가 없으면 동일한 스킬의 중복 개발, 품질 저하, 소유권 부재, 프롬프트 인젝션(prompt injection), 민감한 비즈니스 로직 노출이라는 새로운 기술 부채가 쌓인다.
• 중앙 스킬 레지스트리(registry), 메타데이터 카탈로그, MCP와 CLI, 버전·수명주기 관리, 접근 제어, 평가·관찰 가능성(observability)이 조직 확장의 기반이 된다.
• 15개 팀을 6개월 동안 관찰하는 시뮬레이션은 거버넌스가 없을 때 가시성이 낮고 비용이 높아지며, 중앙화 이후 공통 기반과 재사용성이 생기는 모습을 보여준다.

Imad Touil은 QuantumBlack의 distinguished engineer로서 스킬을 조직의 실행 가능한 노하우로 정의한다. 개인이 스킬을 만들고 팀이 공유하는 단계에서 출발해 중앙 플랫폼과 도메인별 거버넌스로 확장해야 한다. 스킬 레지스트리와 정적 평가(static evaluation)를 먼저 준비하고, 자동 진화(auto-evolving) 기능은 조직의 안전장치가 마련된 뒤 도입해야 한다.

1. 도입: 스킬 사용 현황이 보여주는 거버넌스의 공백

조직 전체에서 스킬을 만들고 쓰는 사람은 늘고 있지만, 조직 차원에서 소유·공유·검증하는 체계는 아직 드물다.

1.1. 세 번의 손들기 질문 (00:00~01:20)

1. 개인이 스킬을 만들고 사용하는가

   1. Imad Touil은 참석자에게 이미 스킬을 만들어 사용하고 있으면 손을 들어 달라고 요청한다.
   2. 손을 든 참석자들에게 “Amazing”이라고 반응하며 첫 번째 사용 집단이 존재함을 확인한다.

2. 팀 안에서 스킬을 공유하는가

   1. 스킬을 팀 안에서 사용하고 공유하는 사람에게 손을 계속 들고 있어 달라고 요청한다.
   2. 일부 참석자가 계속 손을 든 상황을 긍정적으로 받아들이면서도, 개인 사용과 팀 공유 사이에 차이가 있음을 드러낸다.

3. 조직 전체에서 스킬을 관리하고 유지하는가

   1. 조직 전체에 걸쳐 스킬을 거버넌스(governance)하고 유지해 온 사람에게 다시 손을 들어 달라고 요청한다.
   2. 손이 몇 개만 남는 반응을 통해 스킬을 조직 단위로 관리하는 단계가 아직 초기임을 보여준다.
   3. 이 반응은 개인의 실험이 조직 역량으로 전환되려면 구조·소유권·관리 체계가 필요하다는 출발점이 된다.

1.2. 발표의 범위와 관객 반응

1. 조직 확장의 세 가지 질문

   1. 스킬을 왜 중요한 구성 요소로 봐야 하는지 질문한다.
   2. 스킬이 어느 지점에서 중요한지와 실제로 조직 전체에 어떻게 적용할 수 있는지를 함께 묻는다.

2. 현장 상호작용

   1. 초반에는 참석자에게 여러 차례 손들기를 요청하는 짧은 참여형 실습을 진행한다.
   2. 스킬을 만들어 쓰는 사람보다 조직 전체의 스킬을 관리해 본 사람이 적다는 반응이 강연의 문제의식을 구체화한다.
   3. 별도의 질의응답은 이어지지 않으며, 마무리 때 Leadership Lounge에서 질문을 받겠다고 안내한다.

2. 에이전틱 소프트웨어 스택의 두 루프

에이전틱 소프트웨어 스택(Agentic software stack)은 에이전트가 한 작업을 수행하는 내부 루프와 조직의 엔드투엔드 실행을 조정하는 외부 루프로 구성된다.

2.1. 내부 루프: 코딩 에이전트 하네스

1. 코딩 에이전트와 하네스

   1. 내부 루프는 코딩 에이전트(coding agent) 또는 코딩 에이전트 하네스가 작업을 추론하고 실행하는 부분이다.
   2. 하네스는 에이전트가 무엇을 읽고, 어떤 도구를 호출하며, 어떤 상태를 유지할지 결정하는 실행 기반이다.

2. 핵심 구성 요소

   1. 컨텍스트 관리자(context manager)는 작업에 필요한 정보의 범위를 관리한다.
   2. 도구(tools)와 MCP(Model Context Protocol)는 에이전트가 외부 기능과 시스템에 접근하게 한다.
   3. 메모리(memory)와 상태(state)는 이전 대화와 현재 작업 상태를 이어 준다.
   4. 스킬 로더(skills loader)는 작업 시점에 필요한 스킬을 불러온다.

2.2. 외부 루프: 워크플로 하네스 블루프린트

1. 워크플로의 역할

   1. 외부 루프는 여러 단계와 담당자를 연결하는 워크플로(workflow)다.
   2. 워크플로는 스킬, 서브 에이전트(sub-agent), MCP 서버, 필요할 때 작동하는 훅(hook)을 포함한다.

2. 워크플로의 성격

   1. 워크플로는 코딩 도구의 행동을 형성하는 하네스 블루프린트(harness blueprint)로 작동한다.
   2. 내부 루프가 하나의 작업을 처리한다면 외부 루프는 작업의 순서·조건·조직 내 협업을 조정한다.

2.3. 실행을 가능하게 하는 하단 구성 요소

1. 환경 및 도구 관문

   1. 환경 샌드박스(environment sandbox)는 에이전트와 작업을 격리된 실행 환경에 둔다.
   2. MCP 게이트웨이(MCP gateway)는 조직 전체 MCP 도구를 관리하고 단순화한다.

2. 모델·지식·유통 관문

   1. 모델 게이트웨이(model gateway)는 로컬에서 실행되는 오픈소스 모델과 프런티어 모델(frontier model)을 함께 관리하고 최적화한다.
   2. 그래프 지식 그래프(graph knowledge graph)는 IT 핵심 시스템, 코드베이스, 스킬 레지스트리를 추상화한다.
   3. 워크플로 마켓플레이스(workflow marketplace)는 재사용 가능한 실행 흐름을 유통하는 장소가 된다.

2.4. 컨텍스트 레이어

1. 작업 수행에 필요한 정보의 집합
   1. 프로젝트 지침(project instructions)은 CLAUDE.md 또는 AGENTS.md 파일처럼 프로젝트의 규칙을 제공한다.
   2. 선택한 MCP 스키마(schema)는 어떤 도구를 언제 써야 하는지 이해하게 한다.
   3. 메모리는 최종 사용자와의 대화 이력을 보존한다.
   4. 사람의 개입(human in the loop)은 자동화 과정에 판단과 승인을 넣는다.
   5. 검색된 콘텐츠(retrieved contents)는 파일과 코드베이스 등에서 작업에 필요한 자료를 가져온다.

3. 네 단계 코딩 작업과 엔터프라이즈 제품 수명주기

명세·계획·작업 분해·구현이라는 네 단계는 제품 증분(product increment)의 한 부분일 뿐이며, 조직 전체의 제품 소프트웨어 전달 수명주기를 대표하지 않는다.

3.1. 익숙한 네 단계의 한계 (약 02:20~03:40)

1. Specify: 무엇을 만들지 정의하기

   1. 만들고 싶은 대상을 구체적으로 명세한다.
   2. 무엇을 구축할지 정의하는 단계는 제품 전체 가치 흐름의 출발점에 해당한다.

2. Design/Plan: 설계와 계획 세우기

   1. 어떤 것을 어떤 방식으로 만들지 계획한다.
   2. 계획은 구현 전에 문제를 정리하고 실행 순서를 정하는 역할을 한다.

3. Tasks: 작은 작업으로 분해하기

   1. 계획한 결과물을 수행 가능한 작업들로 나눈다.
   2. 작업 분해는 에이전트가 처리할 단위를 줄이지만 조직의 제품 전략·데이터·운영 문제를 해결하지는 않는다.

4. Implement: 구현하기

   1. 분해된 작업을 코드와 실행 결과로 옮긴다.
   2. 오늘날 많은 코딩 에이전트가 이 네 단계와 비슷한 형태를 갖고 있다.
   3. 조직의 복잡성과 규모를 고려하면 이 네 단계는 전체 흐름이 아니라 여정의 한 단계다.

3.2. 제품 전략과 발견 단계

1. 제품 전략 수립

   1. 비즈니스가 무엇을 만들고 어떻게 만들지 결정한다.
   2. 성공 지표(success metrics)를 정의한다.
   3. 제품 계획과 로드맵(roadmap)을 확인하고 작은 단위로 세분화한다.

2. 통찰 확보

   1. 시장 조사(market research)를 통해 시장의 요구와 맥락을 파악한다.
   2. 경쟁사 분석(competitive analysis)을 수행한다.
   3. 시장 조사와 경쟁사 분석을 고객 인터뷰(customer interviews)의 입력으로 사용한다.

3. 문제와 해결책 발견

   1. 조사 결과를 여러 문제 진술(problem statements)로 쪼갠다.
   2. 문제에 대한 해결책을 찾고 해결책을 검증한다.
   3. 실험(experiment)을 거쳐 가설을 확인하고 사용자 스토리(user stories)를 작성한다.

3.3. 데이터 제품 전달

1. 구축 전 데이터 준비

   1. 제품을 만들기 전에 제품을 뒷받침할 데이터 카탈로그(data catalog)를 정리한다.
   2. 핵심 시스템과 연결되는 엔드포인트(endpoint)와 통합(integration)을 조정한다.

2. 데이터 파이프라인

   1. 데이터 파이프라인(data pipeline)을 구축한다.
   2. 파이프라인을 검증하고 데이터 품질(data quality)을 검증한다.
   3. 데이터 자산을 카탈로그에 정리해 개발에 사용할 준비를 마친다.
   4. 발표 중 카탈로그라는 단어 뒤에 기침과 목을 가다듬는 소리가 삽입되어 현장감을 더한다.

3. 제품 증분으로 복귀

   1. 데이터 제품 전달이 끝나면 제품 증분 단계로 돌아가 구현을 시작한다.
   2. 제품 증분은 전략·발견·데이터 준비를 거친 뒤에야 의미를 갖는다.

3.4. 여러 SDLC와 플랫폼 엔지니어링 운영

1. 조직에 흩어진 SDLC

   1. Imad Touil은 지난 18년간 여러 조직에서 제품을 만들며 서로 다른 SDLC(Software Development Life Cycle)가 한 조직 안에 흩어져 있음을 관찰했다.
   2. 모바일 애플리케이션용 SDLC와 다른 부서 또는 다른 플랫폼용 SDLC가 각각 존재한다.
   3. 직원용 내부 플랫폼과 고객 대면(customer-facing) 플랫폼도 서로 다른 흐름을 가질 수 있다.
   4. 조직의 모든 것을 하나의 워크플로로 구축할 수 있다는 가정은 현실과 맞지 않는다.

2. 플랫폼 엔지니어링 운영

   1. 무엇을 어떻게 만들지 정한 다음에는 실행 단계로 넘어간다.
   2. 프로비저닝된 인프라(provisioned infrastructure)를 운영한다.
   3. 인프라스트럭처 애즈 코드(Infrastructure as Code) 모듈을 설계하고 관리한다.

3. 출시 이후의 반복 루프

   1. 제품을 출시한 뒤 제품 성능을 최적화한다.
   2. 발생 가능한 인시던트(incident)를 찾아 해결한다.
   3. 최적화와 문제 해결이 끝나면 다시 다음 실행 루프로 들어간다.

4. 규모가 만드는 복잡성

   1. 혼자 간단한 제품을 만들고 배포하는 상황과 대규모 디지털 플랫폼을 구축하는 상황은 다르다.
   2. 조직 규모에서 보이는 실제 지형은 예상보다 훨씬 복잡하다.
   3. 슬라이드에 보이는 그림조차 실제 복잡성의 약 10~20%에 불과하며, 구체적인 모습은 조직마다 달라진다.

4. 워크플로에서 스킬이 핵심이 되는 이유

훅·MCP 서비스·서브 에이전트는 실행을 돕지만, 조직의 노하우와 구조적 가치를 가장 직접적으로 담는 단위는 스킬이다.

4.1. 네 가지 구성 요소와 역할 구분 (약 06:50~08:20)

1. 훅(hook)

   1. 훅은 특정 이벤트가 발생했을 때 워크플로의 작업을 미리 트리거하는 장치다.
   2. 훅은 이벤트 기반 동작을 제공하지만 조직의 업무 노하우 자체를 담는 핵심 단위는 아니다.

2. MCP 서비스

   1. MCP 도구는 작업에 필요한 외부 기능을 제공한다.
   2. 실제로 많은 사람이 MCP를 직접 만들기보다 자신이 사용하는 도구가 제공하는 MCP 도구를 이용한다.
   3. 따라서 MCP 도구는 중요하지만 조직이 직접 소유하는 노하우의 저장소와는 구분된다.

3. 서브 에이전트(sub-agent)

   1. 서브 에이전트는 컨텍스트 윈도우(context window)를 최소화하는 데 쓰인다.
   2. 특정 작업이 필요할 때만 서브 에이전트에게 실행 권한을 위임한다.
   3. 서브 에이전트의 위임 구조만으로는 조직의 반복 가능한 방법론을 표준화할 수 없다.

4. 스킬(skill)

   1. 조직의 노하우는 결국 스킬 수준에 집중된다.
   2. 스킬의 구조가 올바르지 않으면 워크플로가 예측 가능하고 결정론적(deterministic)으로 작동하지 않는다.
   3. 스킬은 워크플로의 행동을 구체화하는 실행 가능한 지식 단위다.

4.2. 스킬 채택의 빠른 확산

1. 표준의 등장

   1. 약 8개월 전 Anthropic이 스킬에 관한 첫 번째 글을 발표했다.
   2. 약 2개월 뒤 스킬을 위한 개방형 표준(open standard)이 등장하고 여러 에이전트 하네스가 새 표준을 채택하기 시작했다.
   3. 발표 시점 기준 올해 2월 무렵부터는 대부분의 에이전트가 이 방식을 채택한 것으로 관찰된다.

2. 에이전트의 작업 과정

   1. 사용자가 표면에서 스킬을 직접 보지 못하더라도 에이전트의 사고 과정을 살피면 작업 중 여러 스킬을 불러오는 모습을 확인할 수 있다.
   2. 스킬은 별도 버튼을 누르는 기능이 아니라 작업 실행 중 필요한 지식을 공급하는 방식으로 녹아든다.

3. 생성 수와 수요의 증가

   1. 공개 GitHub 저장소와 공개 스킬 레지스트리를 간단히 훑은 스냅샷만으로도 생성된 스킬 수가 증가하는 흐름이 보인다.
   2. 실제 공개 영역과 조직 내부에는 슬라이드에 나타난 것보다 훨씬 많은 스킬이 존재한다.
   3. 스킬의 생성과 수요가 동시에 증가하므로 구조·검색·품질 관리가 필요해진다.

4. 벤치마크가 던지는 질문

   1. 최신 Skills Bench는 최신 모델과 기존 모델이 소프트웨어 엔지니어링·사이버 보안 작업을 수행하는 방식을 비교한다.
   2. 스킬 없이도 최신 모델의 성능은 기대에 부합하고 매일 개선된다.
   3. Skills Bench 비교는 “the outcome was”라는 미완성 문구 뒤 구체적인 수치나 완결된 비교 결과 없이 다음 주제로 이어진다.
   4. 핵심 주장은 모델 자체의 일반 능력보다 더 결정론적인 스킬이 예측 가능성을 높인다는 데 있다.

5. 마이크로서비스 설계 원칙으로 스킬 구조화하기

스킬 설계는 완전히 새로운 문제가 아니라 마이크로서비스 운동에서 다뤄 온 소프트웨어 설계 문제와 유사하며, 재사용·모듈화·검색·조합·일관성이 핵심이다.

5.1. 재사용·모듈화·발견 가능성

1. 재사용 가능한 단위

   1. 스킬은 여러 워크플로에서 반복해서 사용할 수 있어야 한다.
   2. 동일한 조직 노하우를 매번 프롬프트로 다시 작성하지 않도록 실행 단위로 분리해야 한다.

2. 모듈식 구조

   1. 스킬은 하나의 큰 덩어리가 아니라 독립적으로 관리할 수 있는 모듈이어야 한다.
   2. 모듈식 구조는 다른 스킬이나 워크플로에 끼워 넣을 수 있는 경계를 제공한다.

3. 발견·확보 가능성(discoverability)

   1. 한 팀에 속한 사람이 특정 스킬을 필요로 하면 자동으로 해당 스킬을 발견하고 가져올 수 있어야 한다.
   2. 필요한 지식이 누군가의 개인 컴퓨터나 기억에만 남지 않도록 검색 가능한 목록과 전달 경로를 마련해야 한다.

5.2. 이동성·전문화·조합성

1. 워크플로와 하네스 사이의 이동성

   1. 스킬은 여러 워크플로에서 사용할 수 있다.
   2. 같은 표준을 채택한 여러 에이전트 하네스에서도 사용할 수 있다.
   3. Cloud Code에서 만든 스킬을 Cursor로 옮기는 예처럼, 표준을 따르면 하네스가 바뀌어도 그대로 작동해야 한다.

2. 전문화(specialization)

   1. 하나의 스킬에 모든 기능을 넣은 모놀리스(monolith)를 만들면 안 된다.
   2. 스킬은 특정 작업 하나를 구체적으로 정의하도록 전문화해야 한다.
   3. 전문화는 스킬의 가치가 일반적인 설명이 아니라 반복 실행할 수 있는 작업 정의에 있음을 뜻한다.

3. 조합성(composability)

   1. 스킬은 다른 스킬과 실제로 조합될 수 있도록 설계해야 한다.
   2. 조합 시 같은 로직이 여러 스킬에 중복되거나 서로 충돌하지 않도록 경계를 정해야 한다.
   3. 조합 가능한 카탈로그는 복잡한 워크플로를 작은 실행 단위의 연결로 구성하게 한다.

5.3. 일관성·결정론·비용 효율

1. 일관성과 결정론

   1. 스킬의 핵심 가치는 같은 입력과 규칙에서 예측 가능한 결과를 내는 일관성(consistency)에 있다.
   2. 결정론은 팀별 사람의 숙련도 차이에 따라 결과가 크게 흔들리는 현상을 줄인다.

2. 점진적 공개(progressive disclosure)

   1. 스킬은 필요한 시점에 필요한 양만 에이전트의 컨텍스트에 공개해야 한다.
   2. 적절한 스킬을 적절한 시기에 적절한 양만 제공하면 컨텍스트 윈도우 문제를 완화할 수 있다.

3. 토큰 비용 절감

   1. 모든 지식을 매번 컨텍스트에 넣는 대신 점진적으로 공개하면 토큰 사용량이 줄어든다.
   2. 비용 효율성은 모델 호출 비용뿐 아니라 사람이 정답을 얻기까지 반복하는 시간도 줄이는 방식으로 나타난다.

4. 새로운 실행 단위

   1. 스킬은 조직의 노하우를 실행 가능(executable)하게 만든다.
   2. 스킬은 노하우를 이식 가능(portable)하게 만든다.
   3. 스킬은 노하우를 저렴하게(cheap) 활용하게 만든다.

6. 규제 준수 스킬을 조합한 결정론적 검토

데이터 보존 정책과 규제 공개 검토를 스킬로 분리·조합하면 에이전트의 데이터 처리 규칙을 실행 시점에 자동으로 적용하고 감사 결과를 남길 수 있다.

6.1. 데이터 보존 정책 스킬

1. 고객 데이터 처리 지침

   1. 에이전트가 고객 데이터를 조작하는 이유를 이해하도록 지침을 제공한다.
   2. 데이터가 관련 규정에 맞게 처리되는지 확인하게 한다.

2. 노하우의 정책화

   1. 담당자가 규정을 기억해 수동으로 판단하는 대신 데이터 보존 정책(data retention policy)을 재사용 가능한 스킬로 만든다.
   2. 정책 스킬은 실제 데이터 처리 작업에 결합될 수 있는 규칙 단위가 된다.

6.2. 규제 수준의 조합

1. 스킬 카탈로그와 하네스

   1. 왼쪽의 스킬 카탈로그는 필요한 규칙과 절차를 보유한다.
   2. 오른쪽의 하네스는 카탈로그에서 스킬을 가져와 실행하고 결과를 출력한다.

2. 함께 필요한 규칙

   1. 데이터 보존 정책 스킬만으로는 충분하지 않다.
   2. 공개 기준(disclosure standards)을 지켜야 한다.
   3. GDPR 규칙을 준수해야 한다.
   4. 작성 양식과 필링 템플릿(filling templates)을 사용해야 한다.

3. 조직 전체 적용

   1. 웹·모바일·조직 내부의 여러 애플리케이션에서 만들어지는 데이터와 기능이 같은 규칙을 따르도록 정의한다.
   2. 규칙을 공통 스킬로 조합하면 애플리케이션 종류가 달라도 준수 기준을 반복 적용할 수 있다.

6.3. 실행 시점의 검토와 감사

1. 자동 스킬 호출

   1. 규제 공개 검토(regulatory disclosure review) 워크플로가 실행될 때 관련 규칙을 자동으로 가져온다.
   2. 데이터 보존 정책·공개 기준·GDPR·양식이 작업 맥락에 맞게 조합된다.

2. 결정론적 결과

   1. 검토 결과는 예측 가능한 결정론적 결과가 되어야 한다.
   2. 감사 보고서(audit report)를 저장할 수 있어야 한다.
   3. 개선이 필요한 지점을 구체적으로 식별하고 코드베이스로 피드백한다.

3. 코드 개선 루프

   1. 검토 결과가 코드베이스의 수정 지점을 가리킨다.
   2. 수정된 코드와 스킬을 다시 검토해 규제 준수 수준을 높인다.

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

스킬을 만들기만 하고 조직적으로 거버넌스하지 않으면 기존 기술 부채와 다른 형태의 중복·품질·소유권·조합성·보안 부채가 발생한다.

7.1. 중복과 품질 저하

1. 조직 내 중복

   1. 팀 간 협업이 없으면 같은 기술 스택과 같은 인프라를 사용하는 팀들이 동일한 스킬을 반복해서 만든다.
   2. 각 팀이 만든 스킬을 공유하지 않으면 이미 존재하는 노하우를 다시 학습하고 다시 구현하게 된다.

2. 품질 검증

   1. 스킬을 테스트하고 유지하며 검증하지 않으면 시간이 지나면서 품질이 떨어진다.
   2. 자체 테스트 결과뿐 아니라 새로 출시되는 최신 모델에서도 스킬이 제대로 작동하는지 평가해야 한다.

7.2. 검색 가능성과 소유권

1. 거버넌스와 발견 가능성

   1. 거버넌스가 없으면 조직에 어떤 스킬이 존재하는지 발견하기 어렵다.
   2. 스킬을 검색할 수 없으면 팀은 다시 같은 기능을 만들게 된다.

2. Backstage·IDP와 서비스 카탈로그의 비유

   1. 내부 개발자 포털(IDP, Internal Developer Portal)과 Backstage는 마이크로서비스의 소유자를 찾는 문제를 해결해 왔다.
   2. 개발자는 사람에게 일일이 묻지 않고 서비스 카탈로그에 들어가 누가 해당 서비스를 소유하는지 확인한다.
   3. 스킬도 같은 방식으로 소유자와 책임 범위를 식별해야 한다.

3. 소유자 부재의 결과

   1. 소유자가 없으면 누구도 스킬을 유지 관리하기 어렵다.
   2. 스킬을 확장하거나 발전시키는 책임도 사라진다.

7.3. 조합성과 도메인 정렬

1. 조합성은 자동으로 생기지 않는다

   1. 무엇을 만들지와 어떻게 설계할지를 맞추는 거버넌스 방식이 필요하다.
   2. 서로 다른 팀이 만든 스킬이 충돌하지 않도록 설계 기준과 도메인 경계를 합의해야 한다.

2. 도메인 중심 접근

   1. 오랫동안 사용해 온 도메인 중심(domain-driven) 접근 방식은 스킬 카탈로그를 구성하는 방식과 유사하다.
   2. 도메인별로 스킬의 책임·소유·의존성을 나누면 조직 규모에서도 조합성을 유지하기 쉽다.

7.4. 보안과 권한

1. 공개 스킬의 위험

   1. 공개 스킬을 실험하는 과정에서 프롬프트 인젝션(prompt injection)이 포함된 스킬을 가져올 수 있다.
   2. 스킬에는 특정 작업을 결정론적으로 실행하는 스크립트(script)가 들어갈 수 있으므로 설명문만 읽고 안전하다고 판단하면 안 된다.

2. 보안 검증 파이프라인

   1. 스킬을 조직에 가져오기 전에 보안을 확인하는 파이프라인이 필요하다.
   2. 검증이 없으면 안전하지 않은 코드·지침·스크립트를 조직의 워크플로로 끌어올 수 있다.

3. 접근 제어

   1. 조직의 모든 구성원이 모든 스킬에 접근할 필요는 없다.
   2. 일부 스킬에는 민감한 비즈니스 로직이 포함될 수 있다.
   3. 누가 어떤 스킬을 사용할 수 있는지 정하는 접근 제어(access control)가 필수다.

8. 개인에서 팀, 중앙 플랫폼으로 확장하는 운영 모델

스킬 운영은 개인의 제작·테스트에서 팀의 협업과 공유로, 다시 중앙 카탈로그·레지스트리와 거버넌스로 확장된다.

8.1. 개인 수준: 만들고 검증하고 사용하기

1. 개인의 실행 권한

   1. 개인이 스킬을 만들 수 있어야 한다.
   2. 개인이 만든 스킬을 테스트하고 개선하며 실제 작업에 사용할 수 있어야 한다.

2. 구조화된 도구 선택

   1. 개인의 실험이 무작위로 흩어지지 않도록 조직이 합의한 도구와 메커니즘을 선택한다.
   2. 다양한 도구 중 하나를 정하고 개인 수준에서 일관되게 사용한다.

8.2. 팀 수준: 공유와 협업

1. 공유의 시작

   1. 개인이 스킬을 만드는 순간 팀원과 공유한다.
   2. 팀은 공유된 스킬을 함께 개선한다.

2. 공통 기반의 빠른 진화

   1. 같은 기술 스택을 사용하고 같은 제품을 만드는 팀은 스킬을 빠르게 발전시킬 수 있다.
   2. 개인의 노하우가 팀의 재사용 자산으로 바뀌면서 중복 제작이 줄어든다.

8.3. 중앙 플랫폼: 검색·가져오기·생명주기 관리

1. 메타데이터 카탈로그

   1. 중앙 집중식 플랫폼은 스킬을 검색하고 발견할 수 있는 메타데이터 카탈로그를 갖춰야 한다.
   2. 메타데이터는 스킬의 목적·소유자·버전·의존성·접근 범위를 식별하게 한다.

2. MCP와 CLI를 통한 배포

   1. MCP가 카탈로그에 연결되어 필요한 스킬을 검색할 수 있어야 한다.
   2. CLI는 검색한 스킬을 로컬 IDE로 가져오거나 공장(factory)의 샌드박스로 가져온다.
   3. 검색과 가져오기 경로가 표준화되면 팀마다 별도 복사본을 관리할 필요가 줄어든다.

3. 의존성 관리

   1. 스킬 사이의 상호 의존성을 이해해야 한다.
   2. 어떤 스킬이 다른 스킬을 요구하는지 추적해야 조합 시 충돌을 줄일 수 있다.

4. 버전과 수명주기

   1. 스킬의 최신 버전이 무엇인지 알 수 있어야 한다.
   2. 에이전트는 기능을 구축하는 중 최신 스킬 버전을 감지하고 자동으로 가져올 수 있다.
   3. 버전 관리(versioning)와 수명주기(lifecycle) 관리는 레지스트리의 최신 변경 사항을 올바르게 반영하게 한다.

5. 접근 제어·평가·관찰 가능성

   1. 누가 무엇에 접근하는지 모르는 상태는 거대한 보안·운영 공백이다.
   2. 스킬 사용을 평가(evaluation)하고 관찰 가능성(observability)을 확보해야 한다.
   3. 사용량·품질·실패·개선 이력을 추적해야 중앙 플랫폼이 실제 운영 자산이 된다.

9. 거버넌스의 책임 구조와 중앙화된 결과

기술만으로는 스킬 운영 문제를 해결할 수 없으며, 조직 구조에 맞는 책임자들이 정책과 변경을 소유해야 한다.

9.1. 기술의 한계와 거버넌스의 필요

1. 기술이 해결하는 범위

   1. 카탈로그·MCP·CLI·버전·평가 기능은 스킬을 찾고 실행하고 관리하는 기반을 제공한다.
   2. 무엇을 허용하고 누가 책임질지 결정하는 문제까지 도구가 자동으로 해결하지는 않는다.

2. 누가 통치하는가

   1. 중앙 플랫폼을 만든 뒤에는 누가 스킬 정책과 변경을 통치할지 정해야 한다.
   2. 답은 현재 조직 구조와 도메인별 책임 체계에 따라 달라진다.

9.2. 도메인별 오너십

1. 핵심 리더들의 참여

   1. 아키텍트(architect)가 설계 영역을 책임진다.
   2. 엔지니어링 리드(engineering lead)가 구현과 개발 방식의 기준을 책임진다.
   3. 인프라 리드(infrastructure lead)가 실행 환경과 인프라 영역을 책임진다.
   4. 사이버 보안 리드(cybersecurity lead)가 보안 정책과 검증을 책임진다.

2. 정책에 맞는 변경 관리

   1. 각 리드는 자기 도메인의 스킬을 소유하고 운영한다.
   2. 스킬이 업데이트될 때 조직이 지키려는 정책을 충족하는지 확인한다.
   3. 도메인 책임자는 변경을 승인·추진하고 품질·보안 기준을 지속해서 유지한다.

9.3. 중앙화된 운영 결과

1. 고품질 스킬의 공통 사용

   1. 모든 팀이 하나의 중앙 장소에서 고품질 스킬을 가져온다.
   2. 각 팀은 스킬을 실행하고 업무에 적용한다.

2. 개선 사항의 환류

   1. 팀이 더 나은 스킬을 만들면 개선된 결과를 중앙 플랫폼으로 되돌린다.
   2. 중앙 플랫폼은 검증된 개선을 다시 모든 팀이 사용할 수 있는 자산으로 만든다.

10. 15개 팀 시뮬레이션으로 본 거버넌스 효과

15개 무작위 팀이 각자 스킬을 개발·사용하는 상황을 6개월 동안 돌려 보면 가시성 없는 중복과 비용 문제가 드러나고, 중앙 거버넌스가 공통 기반을 만든다.

10.1. 시뮬레이션 변수와 초기 상태 (약 16:20~17:45)

1. 조직 모형

   1. Imad Touil은 조직을 시각적으로 보여주기 위해 시뮬레이션을 만들었다.
   2. 시뮬레이션에는 무작위로 구성된 15개 팀이 있다.
   3. 슬라이드에는 팀당 5~12 수준의 팀 규모 또는 스킬 보유 단위가 제시되며, 두 단위가 명확히 구분되지는 않는다.

2. 스킬 운영 변수

   1. 엔지니어의 기여도에 따른 스킬 보유량을 둔다.
   2. 하루 동안 스킬이 호출되는 평균 시간인 평균 스킬 활용도를 둔다.
   3. 팀 내부 중복이 발생하는 비율을 둔다.
   4. 스킬 품질 비율과 보안 비율을 별도 변수로 둔다.

3. 6개월 관찰

   1. 시뮬레이션을 6개월 동안 실행해 스킬 생성과 사용이 어떻게 쌓이는지 본다.
   2. 팀들은 실제 조직에서처럼 스킬을 만들고 사용하지만, 중앙 가시성이 없으면 무슨 일이 벌어지는지 알기 어렵다.

10.2. 거버넌스 없는 운영의 생산성·품질·비용

1. 가시성의 부재

   1. 팀마다 스킬을 만들고 사용해도 조직은 전체 현황을 파악하지 못한다.
   2. 어떤 스킬이 존재하고 어디에서 중복되는지 알 수 없으면 개선 우선순위를 정할 수 없다.

2. 생산성 향상과 스킬의 결합

   1. 스킬은 생산성 향상(productivity uplift)과 밀접하게 연결된다.
   2. 규정 스킬이 없으면 엔지니어가 규정을 제대로 구현하도록 코드를 여러 번 수정하며 방향을 찾는다.
   3. 반복적인 바이브 코딩(vibe coding)은 한쪽에서 더 많은 토큰을 소모하고, 다른 쪽에서 한 번에 정답을 얻는 것보다 많은 시간을 소모한다.

3. 품질과 보안의 편차

   1. 명확하게 정의·관리되는 스킬이 없으면 구현 품질이 낮아진다.
   2. 규칙을 사람이 매번 판단해야 하므로 팀별 성숙도 차이가 결과에 드러난다.
   3. 스킬 정의와 유지 수준이 낮으면 보안 구현도 사람의 판단에 크게 의존한다.

4. 시뮬레이션의 관찰 결과

   1. 무작위 팀을 살펴보면 생산성은 중간 수준으로 나타난다.
   2. 품질과 보안도 중간 수준이지만, 비용은 매우 높게 나타난다.
   3. 중간 수준의 결과를 얻기 위해 반복 작업과 토큰 비용을 계속 지불하는 상태다.

10.3. 거버넌스 이후의 공통 기반

1. 분할과 공통성

   1. 모든 스킬을 관리한다고 해서 모든 스킬이 하나로 합쳐지는 것은 아니며 일부는 서로 다른 스킬로 분리된다.
   2. 분리 자체는 현실적인 결과지만, 적어도 세 팀 사이에 공통으로 사용할 기반이 생긴다.

2. 게시와 자동 재사용

   1. 관리자가 하나의 스킬을 게시하면 다음 엔지니어가 새 스킬을 만들 때 조정 에이전트 하네스(coordinating agent harness)가 이미 사용 가능한 스킬을 식별한다.
   2. 하네스는 기존 스킬을 가져와 새 작업에 재사용하므로 같은 기능의 중복 제작이 줄어든다.

3. 효과의 의미

   1. 거버넌스는 팀별 실험을 중앙에서 검색 가능한 공통 자산으로 바꾼다.
   2. 중앙화는 생산성·품질·보안·비용 지표를 비교하고 개선할 수 있는 가시성을 제공한다.

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

스킬을 정리하는 것만으로 충분하지 않으며, 동일한 중앙화·거버넌스 접근을 제품·인프라·운영 전체 워크플로에 적용해야 한다.

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

1. 부분 최적화의 한계

   1. 스킬을 제대로 구축했다고 해서 조직의 전체 실행이 자동으로 좋아지는 것은 아니다.
   2. 훅·MCP·서브 에이전트·컨텍스트·승인·운영 단계까지 같은 접근 방식으로 설계해야 한다.

2. 워크플로 중앙화

   1. 중앙 플랫폼은 스킬뿐 아니라 모든 워크플로를 보유한다.
   2. 워크플로 카탈로그에서 필요한 흐름을 검색하고 재사용한다.

11.2. 인프라 프로비저닝 예시

1. 필요한 워크플로 조립

   1. 다음 엔지니어가 인프라를 프로비저닝하려 하면 중앙 플랫폼에서 관련 워크플로를 찾는다.
   2. 해당 워크플로가 요구하는 스킬을 가져온다.

2. 실행·테스트·개선

   1. 필요한 스킬로 워크플로를 구성한다.
   2. 워크플로를 실행하고 테스트한다.
   3. 개선 사항이 생기면 중앙 플랫폼으로 다시 전달한다.

12. 결론: 레지스트리·평가·자동 진화의 순서

조직은 6~8개월 안에 스킬 운영 기반을 만들기 시작할 수 있으며, 레지스트리와 평가를 먼저 갖춘 뒤 거버넌스가 있는 자동 진화로 나아가야 한다.

12.1. 스킬 레지스트리

1. 지금 준비할 기반

   1. 아직 스킬 레지스트리가 없다면 하나를 마련해야 한다.
   2. 레지스트리는 스킬의 발견·소유·버전·수명주기·재사용을 뒷받침한다.

2. IDP 생태계의 움직임

   1. 내부 개발자 포털 문제를 해결해 온 업체들이 스킬 관리 기능을 중앙화하기 시작했다.
   2. 지금 해당 기능이 없더라도 몇 달 뒤 IDP 제품에 관련 기능이 나타날 가능성이 있다.
   3. 이미 특정 문제를 해결하는 도구도 여러 가지 존재하므로 조직에 맞는 도구를 탐색해야 한다.

3. 시간 전망

   1. 현재의 변화는 시작 단계에 있다.
   2. 지금부터 약 6~8개월 사이에 관련 기능과 운영 방식이 더 뚜렷해질 것으로 전망한다.

12.2. 스킬 평가와 정적 테스트

1. 평가 방법에 대한 논의

   1. 스킬 역량을 어떤 방식으로 평가할지는 아직 논의가 진행 중이다.
   2. 모든 조직에 통용되는 하나의 평가 방법이 확정된 상태는 아니다.

2. 실용적인 출발점

   1. 현재 유용하다고 느낀 쉬운 방법은 스킬을 실제로 테스트하는 것이다.
   2. Anthropic의 모범 사례에 맞춰 스킬을 정적으로 테스트하거나 평가한다.

3. 호출과 구조 검증

   1. 스킬이 적절한 상황에서 제대로 호출되지 않으면 품질을 기대하기 어렵다.
   2. 스킬의 구조가 올바르지 않아도 높은 품질의 결과를 내기 어렵다.
   3. 호출 여부와 구조 적합성을 정적 평가의 기본 검사 항목으로 삼는다.

12.3. 자동 진화와 안전장치

1. 폐쇄 루프(closed loop)

   1. 스킬을 자동으로 개선하는 폐쇄 루프를 만들 수 있다.
   2. 자동 시스템이 실행되면 현재보다 훨씬 큰 영향이 발생할 수 있다.

2. 거버넌스 없는 자동화의 위험

   1. 거버넌스 없이 자동 진화를 시작하면 조직의 정책과 책임 범위를 벗어난 스킬이 계속 유지될 수 있다.
   2. 자동 진화는 품질 개선뿐 아니라 잘못된 규칙과 취약한 스크립트의 확대도 자동화할 수 있다.

3. 가드레일 우선

   1. 조직에 안전장치(guardrails)를 제공하는 거버넌스를 먼저 마련해야 한다.
   2. 정책·소유권·보안·권한·평가 체계가 갖춰진 뒤 자동 진화 기능을 작동시켜야 한다.

주요 발언 모음

“At the end of the day, all of your know-how is actually at the skills level.”

“결국 여러분이 가진 모든 노하우는 실제로 스킬 수준에 있다.”

“If you don't govern skills, we will start creating a new class of technical debt.”

“스킬을 거버넌스하지 않으면 새로운 유형의 기술 부채를 만들기 시작할 것이다.”

“This makes your know-how in your organization executable, portable, and cheap.”

“스킬은 조직의 노하우를 실행 가능하고, 이식 가능하며, 저렴하게 만든다.”

“Skills is just one component of your workflows.”

“스킬은 워크플로의 한 구성 요소일 뿐이다.”

“What, so what, right?”

“그래서 어쩌란 말인가?”

핵심 데이터 & 수치

• 영상 길이: 1,201초, 약 20분 1초다.
• 경력: Imad Touil은 지난 18년간 여러 조직에서 제품을 개발한 경험을 바탕으로 SDLC의 분산을 설명한다.
• 스킬 표준 확산 시점: 첫 스킬 글 발표 후 약 2개월 뒤 개방형 표준이 등장했고, 발표 시점 기준 올해 2월 무렵 대부분의 에이전트가 채택했다.
• 조직 복잡성 시각화: 슬라이드에 보이는 디지털 플랫폼 지형은 실제 복잡성의 약 10~20%에 불과하다.
• 시뮬레이션 조직: 무작위로 구성한 15개 팀을 사용한다.
• 팀 규모 또는 단위: 슬라이드에 팀당 5~12 수준이 제시되지만, 사람 수인지 스킬 단위인지 명확히 구분되지 않는다.
• 관찰 기간: 거버넌스 전후의 스킬 생성·사용·중복을 6개월 동안 비교한다.
• 거버넌스 이후 전망: 스킬 레지스트리와 관련 기능이 6~8개월 안에 더 확산될 것으로 전망한다.
• 비용 관찰: 거버넌스 없는 무작위 팀의 생산성·품질·보안은 대체로 중간 수준이고 비용은 매우 높게 나타난다.

결론 및 시사점

1. 개인이 만든 스킬을 팀에 공유하고 테스트하는 규칙을 먼저 정해 조직의 암묵지를 재사용 자산으로 전환해야 한다.
2. 스킬을 재사용·모듈화·검색·전문화·조합 가능한 단위로 설계하고 동일한 표준을 여러 하네스에 적용해야 한다.
3. 점진적 공개로 작업에 필요한 스킬만 컨텍스트에 넣어 토큰 비용과 반복 시간을 줄여야 한다.
4. 데이터 보존·GDPR·공개 기준·작성 양식을 조합한 규제 검토 스킬로 결정론적 결과와 감사 보고서를 확보해야 한다.
5. 중앙 스킬 레지스트리에 메타데이터·소유자·의존성·버전·수명주기·권한 정보를 등록해야 한다.
6. 공개 스킬을 가져오기 전에 프롬프트 인젝션과 스크립트를 점검하는 보안 파이프라인을 통과시켜야 한다.
7. 아키텍트·엔지니어링 리드·인프라 리드·사이버 보안 리드가 도메인별 정책과 변경을 공동으로 소유해야 한다.
8. 스킬 플랫폼을 마련하는 데서 멈추지 말고 제품 전략부터 데이터 전달·인프라 운영·배포·최적화까지 워크플로 전체를 중앙화해야 한다.
9. 자동 진화 스킬은 정적 평가와 관찰 가능성, 접근 제어, 가드레일을 마련한 뒤에 도입해야 한다.
10. AI 네이티브 조직의 확장 속도는 모델 성능만이 아니라 조직 노하우를 얼마나 안정적인 실행 단위로 공유하고 관리하는지에 달려 있다.

핵심 요약 (20줄)

AI 네이티브 조직은 에이전트 스킬을 개인의 임시 프롬프트가 아닌 재사용 가능한 실행 단위로 다뤄야 한다. 코딩 에이전트 하네스의 내부 루프는 컨텍스트·도구·메모리·상태·스킬 로더로 구성된다. 워크플로의 외부 루프는 스킬·서브 에이전트·MCP 서버·훅을 연결해 조직의 업무를 조정한다. 명세·계획·작업 분해·구현은 엔터프라이즈 제품 전달 수명주기의 한 단계에 불과하다. 제품 전략은 성공 지표와 로드맵을 정하고 시장 조사·경쟁사 분석·고객 인터뷰로 통찰을 확보한다. 탐색 단계는 문제 진술·해결책·검증·실험·사용자 스토리로 구축할 대상을 구체화한다. 제품 구축 전에는 데이터 카탈로그와 핵심 시스템 연결을 정리하고 파이프라인과 데이터 품질을 검증해야 한다. 대규모 조직에는 모바일·내부 플랫폼·고객용 플랫폼마다 서로 다른 SDLC와 운영 흐름이 존재한다. 훅과 MCP와 서브 에이전트가 실행을 보조해도 조직의 핵심 노하우는 스킬 수준에 축적된다. 스킬은 재사용·모듈화·발견·이동·전문화·조합·일관성·결정론을 갖춰야 한다. Cloud Code에서 Cursor로 스킬을 옮겨도 작동하려면 여러 하네스가 같은 개방형 표준을 따라야 한다. 점진적 공개는 필요한 순간에 필요한 스킬만 제공해 컨텍스트 윈도우와 토큰 비용을 줄인다. 데이터 보존 정책·GDPR·공개 기준·작성 양식을 조합하면 규제 검토를 결정론적으로 실행할 수 있다. 거버넌스가 없으면 스킬 중복·품질 저하·소유권 부재·조합 실패·보안 취약점이 기술 부채가 된다. 공개 스킬에 포함된 프롬프트 인젝션과 스크립트는 보안 검증 파이프라인과 접근 제어를 요구한다. 개인이 만든 스킬은 팀 공유와 협업을 거쳐 중앙 카탈로그의 조직 자산으로 승격되어야 한다. 중앙 플랫폼은 메타데이터 검색·MCP·CLI·의존성·버전·수명주기·평가·관찰 가능성을 제공해야 한다. 15개 팀의 6개월 시뮬레이션은 거버넌스가 없을 때 중간 성과와 높은 비용과 낮은 가시성을 보여준다. 거버넌스 이후 조정 에이전트 하네스는 게시된 스킬을 찾아 재사용하므로 팀 간 공통 기반이 생긴다. 스킬 레지스트리와 정적 평가를 먼저 도입하고 조직 가드레일을 갖춘 뒤 자동 진화로 확장해야 한다.

🎬 Tech Bridge — 2026-08-30 https://www.youtube.com/watch?v=0qySk1fcf6k

AI 네이티브 조직은 에이전트 스킬을 개인의 임시 프롬프트가 아닌 재사용 가능한 실행 단위로 다뤄야 한다. 코딩 에이전트 하네스의 내부 루프는 컨텍스트·도구·메모리·상태·스킬 로더로 구성된다. 워크플로의 외부 루프는 스킬·서브 에이전트·MCP 서버·훅을 연결해 조직의 업무를 조정한다. 명세·계획·작업 분해·구현은 엔터프라이즈 제품 전달 수명주기의 한 단계에 불과하다. 제품 전략은 성공 지표와 로드맵을 정하고 시장 조사·경쟁사 분석·고객 인터뷰로 통찰을 확보한다. 탐색 단계는 문제 진술·해결책·검증·실험·사용자 스토리로 구축할 대상을 구체화한다. 제품 구축 전에는 데이터 카탈로그와 핵심 시스템 연결을 정리하고 파이프라인과 데이터 품질을 검증해야 한다. 대규모 조직에는 모바일·내부 플랫폼·고객용 플랫폼마다 서로 다른 SDLC와 운영 흐름이 존재한다. 훅과 MCP와 서브 에이전트가 실행을 보조해도 조직의 핵심 노하우는 스킬 수준에 축적된다. 스킬은 재사용·모듈화·발견·이동·전문화·조합·일관성·결정론을 갖춰야 한다. Cloud Code에서 Cursor로 스킬을 옮겨도 작동하려면 여러 하네스가 같은 개방형 표준을 따라야 한다. 점진적 공개는 필요한 순간에 필요한 스킬만 제공해 컨텍스트 윈도우와 토큰 비용을 줄인다. 데이터 보존 정책·GDPR·공개 기준·작성 양식을 조합하면 규제 검토를 결정론적으로 실행할 수 있다. 거버넌스가 없으면 스킬 중복·품질 저하·소유권 부재·조합 실패·보안 취약점이 기술 부채가 된다. 공개 스킬에 포함된 프롬프트 인젝션과 스크립트는 보안 검증 파이프라인과 접근 제어를 요구한다. 개인이 만든 스킬은 팀 공유와 협업을 거쳐 중앙 카탈로그의 조직 자산으로 승격되어야 한다. 중앙 플랫폼은 메타데이터 검색·MCP·CLI·의존성·버전·수명주기·평가·관찰 가능성을 제공해야 한다. 15개 팀의 6개월 시뮬레이션은 거버넌스가 없을 때 중간 성과와 높은 비용과 낮은 가시성을 보여준다. 거버넌스 이후 조정 에이전트 하네스는 게시된 스킬을 찾아 재사용하므로 팀 간 공통 기반이 생긴다. 스킬 레지스트리와 정적 평가를 먼저 도입하고 조직 가드레일을 갖춘 뒤 자동 진화로 확장해야 한다.

📁 Study/YouTube다이제스트/2026-08-30-Tech Bridge-AI 네이티브 조직 스킬.md