MCP만으로는 닫히지 않는 간극: Skill은 에이전트의 운영체제다

한 줄 결론

에이전트의 실패는 지능 부족보다 운영 맥락의 위치 지정 실패에서 더 자주 발생한다. MCP는 에이전트에게 손과 눈을 준다. Skill은 “이 환경에서는 이렇게 판단해야 한다”는 작업 규범을 준다. 둘 중 하나만 있으면 실제 프로덕션 경계에서는 구멍이 난다.

영상의 핵심 사례: RLS를 우회하는 Postgres View

Pedro Rodrigues는 Supabase에서 같은 에이전트에게 동일한 작업을 두 조건으로 시켰다고 설명한다. 하나는 MCP만 제공한 조건, 다른 하나는 MCP와 Supabase Skill을 함께 제공한 조건이다. 작업은 RLS가 켜진 테이블 위에 SQL view를 만드는 일이었다.

Postgres에서 view를 만들 때 security_invoker = true 같은 조건을 명시하지 않으면, 의도치 않게 RLS가 우회되어 사용자가 보지 말아야 할 데이터가 노출될 수 있다. MCP만 가진 에이전트는 도구를 사용할 수 있었지만 이 보안 함정을 놓쳤고, Skill까지 가진 에이전트는 안전한 구현을 선택했다.

이 차이는 “모델이 똑똑한가?”가 아니라 “모델이 절대 놓치면 안 되는 로컬 규칙을 언제, 어디서 읽게 되는가?”의 차이다.

MCP와 Skill의 역할 분리

따라서 논쟁은 “MCP냐 Skill이냐”가 아니다. MCP는 능력의 표면적을 넓히고, Skill은 능력의 사용 방식을 좁힌다. 실제 에이전트 운영에서는 둘의 결합이 신뢰성을 만든다.

Supabase가 Skill을 쓰며 얻은 세 가지 원칙

1. 문서를 복제하지 말고 살아 있는 문서로 보내라.

   Skill은 전체 제품 문서의 사본이 되면 금방 낡는다. 대신 에이전트가 최신 문서를 찾는 경로와 습관을 명시해야 한다. Supabase는 문서를 파일시스템처럼 탐색하게 하는 실험도 언급했다. 에이전트는 웹페이지보다 파일과 grep류 탐색에 익숙하기 때문이다.

2. 절대 놓치면 안 되는 규칙은 skill.md 본문에 둬라.

   Rodrigues는 에이전트가 reference file을 생각보다 게으르게 읽는다고 말한다. 한 파일은 읽을 수 있어도 두세 개의 참조 파일을 연쇄적으로 열어야 하는 문제에서는 쉽게 빠뜨린다. 보안 체크리스트처럼 실패 비용이 큰 규칙은 외부 참조가 아니라 최초 로딩되는 Skill 본문에 있어야 한다.

3. 제품 팀의 의견을 숨기지 말고 워크플로로 박아라.

   예를 들어 Supabase는 스키마 변경 시 매번 migration 파일을 만들기보다 개발/스테이징 DB에서 직접 DDL로 반복하고, advisor로 보안·성능 이슈를 확인한 뒤, 마지막에 migration을 만들라는 식의 권장 경로를 Skill에 담았다. 이건 단순 정보가 아니라 제품 팀이 축적한 작업 방식이다.

AutoGrowth 관점의 해석

이 영상은 AutoGrowth/Hermes류 시스템에 바로 연결된다. 우리가 원하는 것은 사람이 매번 “이 클라이언트에서는 이렇게 해야 해”라고 설명하는 구조가 아니다. 클라이언트별 암묵지를 에이전트가 자동으로 로드하는 운영 규칙으로 바꾸는 것이다.

여기서 중요한 설계 원칙은 레이어를 늘리는 게 아니다. 오히려 반대다. 도구 호출 표면은 MCP나 스크립트로 단순화하고, 위험한 판단 규칙은 Skill의 최상단에 둔다. 나머지 변하기 쉬운 지식은 문서·SSOT·레포 안의 살아 있는 파일로 연결한다.

에이전트 신뢰성은 “더 큰 컨텍스트”가 아니라 이 루프가 짧고 명확할 때 올라간다.

실무 체크리스트

• 에이전트가 한 번 놓치면 사고가 나는 규칙인가? → Skill 본문으로 올린다.
• 자주 바뀌는 API/문서인가? → 복사하지 말고 공식 문서나 SSOT를 링크한다.
• 도구는 있는데 사용 순서가 중요한가? → “권장 워크플로”로 명시한다.
• reference 파일 여러 개를 읽어야만 성공하는가? → 실패할 가능성이 높다고 보고 본문/스크립트/검증으로 재설계한다.
• Skill이 실제 성능을 올리는지 알고 싶은가? → 모델별·조건별 eval로 문서 자체를 테스트한다.

남는 질문

영상 말미 Q&A에서 Skill 배포 문제가 나온다. 아직 범용 registry나 패키징 방식은 정리되지 않았다. Supabase는 레포 안에 Skill/플러그인을 함께 두는 방식을 언급한다. 이 지점이 중요하다. 에이전트의 지식은 중앙 위키보다 작업이 일어나는 레포와 런타임 경계에 붙어 있을 때 더 잘 작동한다.

NerdMakr식으로 말하면, 좋은 Skill은 “문서”가 아니라 작업 현장에 붙은 운영체제 패치다.