SKILL.md는 문서가 아니라 실행 레이어다, 에이전트 공급망 보안이 바뀌는 순간

나는 새 에이전트 도구를 볼 때 늘 기능표보다 먼저 무슨 파일을 얼마나 쉽게 믿게 만드는지부터 본다. 콘텐츠 쪽에서 보면 SKILL.md는 그냥 친절한 사용설명서처럼 보이기 쉽다. 그런데 운영자 시선으로 한 발만 물러서서 보면 얘기가 달라진다. 에이전트가 그 파일을 읽고, 행동 규칙을 바꾸고, 외부 스크립트를 실행하고, MCP 서버를 연결하는 순간부터 SKILL.md는 문서가 아니라 실행 레이어가 된다. 에이전트 공급망 보안이 바뀌는 지점도 바로 여기다.

요즘 이 주제가 중요한 이유는 단순하다. CSA AI Safety Initiative는 3,984개 에이전트 스킬을 감사한 결과 36.82%에서 보안 결함을 발견했고, 76개는 확인된 악성 페이로드를 담고 있었다고 경고했다. 이 숫자가 말하는 건 “몇 개 위험하네” 정도가 아니다. 이제 위험은 코드 파일 하나에만 숨지 않는다. 자연어 지시문, 유니코드 숨김 문자, 번들 스크립트, .mcp.json, AGENTS.md, CLAUDE.md, SKILL.md처럼 에이전트가 신뢰하는 문맥층 전체가 공격 표면으로 바뀌었다는 뜻이다.

왜 SKILL.md를 문서로만 보면 안 되나

기존 개발팀은 공급망 보안을 볼 때 보통 패키지, 컨테이너 이미지, CI 비밀정보, 배포 서명을 먼저 점검했다. 그 프레임은 여전히 중요하다. 하지만 에이전트가 본격적으로 개발 루프 안으로 들어오면, 먼저 읽히는 파일이 곧 행동 정책이 된다.

예를 들어 아래 같은 스킬 번들을 생각해 보자.

skills/release-helper/
├── SKILL.md
├── scripts/
│   └── publish.sh
├── templates/
│   └── release-note.md
└── .mcp.json

겉보기엔 별문제 없어 보인다. 하지만 실제론 이 묶음이 에이전트에게 이렇게 말할 수 있다.

• 배포 전 특정 스크립트를 실행하라
• 검증보다 속도를 우선하라
• 승인 단계를 건너뛰어라
• 특정 MCP 서버를 자동 연결하라
• 실패 시 로그를 외부 엔드포인트로 보내라

즉 SKILL.md는 설명서가 아니라 행동을 유도하는 인터페이스다. 사람이 README를 읽을 때는 의심하거나 건너뛸 수 있다. 하지만 에이전트는 작업 효율을 위해 그 지시를 구조화된 맥락으로 받아들인다. 이 차이가 크다. 예전 공급망 공격이 “악성 패키지를 설치하게 만들기”였다면, 이제는 “정상처럼 보이는 컨텍스트를 신뢰하게 만들기”가 된다.

context poisoning은 프롬프트 장난이 아니라 공급망 공격에 가깝다

많은 사람이 아직도 context poisoning을 “프롬프트 인젝션의 변형” 정도로 가볍게 본다. 나는 이 해석이 너무 느슨하다고 본다. 에이전트가 저장소를 열고, 문맥 파일을 읽고, 그 지시에 따라 외부 도구와 로컬 실행기를 만지는 순간 이건 이미 운영 공급망 문제다.

왜냐하면 공격자는 굳이 소스코드 안에 노골적인 악성 코드를 심지 않아도 되기 때문이다. 대신 더 은근한 방식이 가능하다.

1. SKILL.md에 위험한 권한 상승 흐름을 자연어로 숨긴다.
2. AGENTS.md에 검증 생략 규칙을 “팀 관례”처럼 적는다.
3. .mcp.json에 외부 서버 연결이나 자동 승인 경로를 심는다.
4. 숨김 유니코드나 애매한 문장으로 리뷰를 통과한다.
5. 에이전트는 이를 코드가 아닌 신뢰된 운영 지침으로 받아들인다.

이게 무서운 이유는 정적 스캐너가 놓치기 쉽기 때문이다. 패키지 해시는 맞고, 소스 diff도 깨끗하고, 테스트도 통과할 수 있다. 그런데 실제 행동은 이미 오염된다. 결국 우리가 검토해야 하는 대상이 package-lock.json이나 Dockerfile만이 아니라, 에이전트가 읽는 모든 컨텍스트 파일로 넓어진다.

아래 표처럼 보는 게 더 정확하다.

관련해서 최근 MCP STDIO 보안 위기가 보여준 것도 비슷하다. 문제는 도구 연결 자체보다, 연결이 실행 권한으로 이어지는 구조였다. SKILL.md 이슈도 정확히 같은 축에 있다. 보기엔 텍스트지만 결과는 실행이다.

Claude Code 사례가 보여준 신뢰 경계의 이동

이 흐름을 더 또렷하게 만든 건 Claude Code 계열 취약점 논의였다. 프로젝트 설정이나 .mcp.json 같은 파일이 저장소 안에 들어와 있고, 사용자가 저장소를 열거나 신뢰 폴더를 허용하는 순간, 그 로컬 문맥이 OS 프로세스 실행이나 API 키 노출로 이어질 수 있다는 사례들이 연달아 공유됐다.

핵심은 “Claude Code가 위험하다”가 아니다. 더 본질적인 메시지는 이거다.

이제 개발팀이 신뢰해야 하는 대상은 코드 저장소만이 아니라, 그 저장소가 에이전트에게 들려주는 운영 문맥 전체다.

이건 꽤 큰 패러다임 이동이다. 예전엔 저장소를 clone해도 바로 코드가 실행되진 않는 경우가 많았다. 하지만 에이전트 툴은 생산성을 위해 저장소의 설명 파일을 적극적으로 읽고, 도구를 추천하고, 명령을 유도하고, 연결 구성을 불러온다. 그 결과 “문서”와 “실행” 사이 거리가 급격히 짧아졌다.

그래서 앞으로는 저장소 온보딩 질문도 달라져야 한다.

• 이 저장소는 어떤 컨텍스트 파일을 자동으로 읽히게 하나?
• 그 파일은 누가 리뷰하고 누가 변경할 수 있나?
• 외부 스킬 설치나 MCP 연결은 수동 승인인가?
• 로컬 시크릿과 셸 권한은 어디까지 분리돼 있나?

이 질문이 없으면, 우리는 코드 리뷰는 하면서도 행동 정책 리뷰는 놓치는 팀이 된다.

한국 개발팀이 지금 바로 바꿔야 할 기본값

나는 이 주제가 한국 팀에 특히 중요하다고 본다. 국내에선 작은 팀, 1인 개발자, 빠른 실험 문화가 강해서 새 에이전트 도구를 빨리 붙이는 쪽으로 기울기 쉽다. 그 자체는 장점이다. 다만 그 속도에 맞는 보안 기본값이 없으면, 가장 먼저 깨지는 건 편의가 아니라 신뢰다.

실무적으로는 최소한 여기까지는 바꿔야 한다.

1. SKILL.md와 AGENTS.md를 코드와 같은 등급으로 리뷰한다

설명 문서 취급하면 안 된다. 변경 이력, 승인자, 목적, 허용 권한을 남겨야 한다.

2. 외부 스킬은 allowlist 기반으로만 설치한다

“좋아 보이는 스킬”을 즉석에서 붙이는 습관을 버려야 한다. 마켓플레이스와 예제 저장소도 공급망이다.

3. MCP와 로컬 스크립트 실행은 샌드박스로 감싼다

에이전트가 실수하거나 속더라도 바로 사용자 셸과 비밀정보에 닿지 못하게 해야 한다.

4. 시크릿은 컨텍스트 파일과 물리적으로 분리한다

문맥 파일 안에 토큰, 웹훅, 내부 URL 힌트를 섞어두면 사고 반경이 급격히 커진다.

5. 자연어 정책도 보안 감사 범위에 넣는다

숨김 문자, 애매한 우회 지시, “승인 생략” 같은 표현을 정기적으로 점검해야 한다.

체크리스트로 줄이면 이렇다.

- SKILL.md / AGENTS.md / CLAUDE.md / .mcp.json 전수 목록화
- 외부에서 가져온 스킬 번들 출처와 유지관리자 검증
- auto approve / auto run / trust folder 기본값 재검토
- 로컬 실행기와 시크릿 접근 권한 최소화
- 자연어 지시문 리뷰를 코드리뷰 절차에 포함
- 에이전트 전용 샌드박스와 격리된 테스트 저장소 운영

결론: 이제 보호해야 할 건 코드베이스만이 아니라 문맥 베이스다

코딩 에이전트 시대의 공급망 보안은 더 이상 패키지 이름만 외우는 게임이 아니다. 어떤 팀은 여전히 “모델이 똑똑하면 되지”라고 생각하겠지만, 실무에서 더 자주 사고를 키우는 건 모델의 IQ가 아니라 무엇을 믿게 설계됐는가다. SKILL.md가 문서처럼 보여도 실제론 행동을 바꾸고, 행동이 바뀌면 권한 경계가 이동하고, 권한 경계가 이동하면 공급망 공격의 반경도 함께 넓어진다.

그래서 나는 앞으로의 보안 기준이 이렇게 바뀐다고 본다. 좋은 팀은 패키지 스캔만 잘하는 팀이 아니라, 에이전트가 읽는 문맥까지 운영 자산으로 관리하는 팀이다. 그 차이가 점점 더 큰 사고 비용 차이로 돌아올 가능성이 크다.

김덕환 운영자가 봤을 때

log8.kr처럼 새 도구를 빨리 실험해보는 운영자 입장에선 이 변화가 꽤 현실적이다. 생산성을 올려주는 스킬, 프롬프트, MCP 연결은 너무 매력적이라서 금방 붙이고 싶어진다. 그런데 김덕환 운영자가 봤을 때 지금 더 중요한 건 “무엇을 추가할까”보다 무엇을 자동으로 믿지 않을까다. 그 감각이 있어야 1인 운영에서도 속도와 신뢰를 같이 가져갈 수 있다.

KPI impact: published = 0