AI agent skill이 스캔을 통과했는데도, 설치 전에 왜 실행 경계를 다시 봐야 할까?

In this lesson

1. 스캔을 통과해도 바로 설치하면 안 되는 이유
2. AI agent skill 설치 전 go/no-go 표
3. 격리 dry-run으로 runtime 관찰을 보완하는 방법
4. 팀이 내일부터 추가할 수 있는 최소 승인 단계
5. AI에게 정리를 맡길 수 있는 handoff prompt

스캐너는 단서를 찾고, 승인 절차는 위험을 감당할 수 있는지 결정한다

스캐너는 중요하다. prompt injection, 데이터 유출, 권한 상승, 도구 오용, MCP 위험 같은 흔한 문제를 찾는 데 도움을 준다. MCP는 먼저 “AI 도구가 같은 방식으로 데이터와 도구에 연결되도록 하는 프로토콜”로 이해하면 된다.

하지만 스캐너는 보통 이런 질문에 더 잘 답한다.

• repo 안에 수상한 문자열이 있는가?
• 파일 구조 안에 흔한 악성 패턴이 있는가?
• prompt가 원래 지시를 덮어쓰려 하는가?
• 민감 파일을 읽거나 데이터를 외부로 보내라고 명시적으로 요구하는가?

반면 다음 질문은 스캐너 혼자 답하기 어렵다.

• 이 skill은 우리 프로젝트 맥락에서 실제로 어떤 데이터를 받게 되는가?
• agent가 이 skill을 세 단계 연속 호출하면 새로운 위험이 조합되지 않는가?
• 쓰기 권한이 꼭 필요한가, 아니면 읽기만으로 충분한가?
• 네트워크 연결 목적지를 제한할 수 있는가?
• 문제가 생겼을 때 누가 멈추고, token을 회수하고, 임시 데이터를 지우는가?

그래서 “스캐너 통과”는 진입 조건으로는 적절하지만 최종 승인으로 쓰기에는 적절하지 않다. 비슷하게, 보안 스캐너가 문제를 지적했다고 해서 도구가 production 설정을 자동으로 마구 고치게 해서는 안 된다. 이 글도 함께 볼 수 있다. AI 보안 스캐너가 수정하라고 말해도, 먼저 사람이 고쳐도 되는지 결정해야 한다. 같은 논리를 skill 설치 전에 적용하면 이렇게 된다. 스캐너는 힌트를 줄 수 있지만, 결정은 사람이 책임져야 한다.

30분 동안 격리 dry-run을 한 번 해보기

dry-run은 “먼저 시험 실행하되 실제 데이터 변경이나 배포는 하지 않는 것”이다. 서드파티 skill에서 dry-run은 그것이 작업을 완료할 수 있는지만 보는 과정이 아니다. 그것이 작업을 어떻게 완료하는지도 관찰하는 과정이다.

다시 말해 이 절은 추가 테스트가 아니다. 스캐너만으로는 보이지 않는 runtime 경계를 보완하는 절이다. skill이 실제로 실행될 때 무엇을 읽고, 어디에 연결하고, 어떤 도구를 쓰며, 데이터가 최종적으로 어떤 출력으로 나가는지를 보는 것이다.

아래 순서로 작은 점검을 한 번 실행할 수 있다.

1. 가짜지만 진짜 같은 작업을 준비한다

첫 테스트 대상으로 production 프로젝트를 쓰지 말자. 더 나은 방법은 작은 fixture를 준비하는 것이다.

• 실제 repo 구조를 흉내 낸 파일 10~20개.
• 의도적으로 넣어 둔 경계 사례 2~3개. 예: 가짜 .env, 가짜 고객 데이터, 가짜 API key.
• 명확한 작업 1개. 예: “changelog를 정리해 줘” 또는 “설정 파일의 불일치를 찾아줘”.
• 명확한 금지 사항 1개. 예: “secrets/ 디렉터리는 읽지 말 것”.

이렇게 하면 skill이 작업을 끝냈는지만 보는 것이 아니라, 만지면 안 되는 곳을 건드렸는지도 볼 수 있다.

2. 권한을 세 단계로 나누고 처음부터 모두 열지 않는다

첫 dry-run에서는 다음 순서로 권한을 여는 것을 권한다.

1. 1단계: 읽기 전용 파일 권한, 네트워크 없음.
2. 2단계: 읽기 전용 파일 권한, 제한된 도메인 연결.
3. 3단계: 필요할 때만 쓰기 권한 추가. 단, output/ 또는 임시 디렉터리에만 쓰도록 허용.

skill이 1단계에서 핵심 작업을 끝낼 수 있다면 3단계까지 올리지 않는다. 권한 상승에는 이유가 있어야 한다. 설치 가이드에 “full access 권장”이라고 적혀 있다는 이유만으로 그대로 따라 하지 말자.

3. 네 가지 runtime 신호를 기록한다

runtime은 먼저 “프로그램이 실제로 실행되는 시간”으로 이해하면 된다. 격리 dry-run에서는 최소한 다음 네 가지 신호를 기록해야 한다.

• 파일: 어떤 경로를 읽었는가? 어떤 경로에 썼는가? forbidden directory를 건드렸는가?
• 네트워크: 어떤 도메인에 연결했는가? request 크기가 비정상적인가? 실행 내용을 동적으로 다운로드했는가?
• 도구: 어떤 shell, 브라우저, API, MCP tool을 호출했는가? 순서는 합리적인가?
• 출력: 최종 답이 알아서는 안 되는 데이터를 인용했는가? 내부 내용을 외부 서비스에 붙여 넣었는가?

처음부터 무거운 보안 플랫폼을 만들 필요는 없다. 작은 팀은 container log, proxy log, 파일 시스템 audit, agent tool-call log를 엮어 첫 번째 관찰 버전을 만들 수 있다. 핵심은 dry-run이 나중에 되돌아볼 수 있는 흔적을 남기게 하는 것이다.

4. 결과를 “쓸 만해 보임”이 아니라 go/no-go로 쓴다

dry-run이 끝난 뒤 Slack에 “괜찮아 보임” 한 줄만 남기지 말자. 결과를 세 가지 상태로 수렴시킨다.

• go: 제한된 워크플로에 설치 가능. 같은 권한 제한과 모니터링을 유지한다.
• conditional go: 특정 owner, 특정 repo, 특정 작업에만 사용 가능하며 2주 안에 재검토한다.
• no-go: 설치하지 않는다. 이유를 남겨 다음에 다른 동료가 같은 길을 다시 밟지 않게 한다.

conditional go가 너무 많다면 이 skill은 아직 팀 공용 도구가 되기에 적합하지 않다는 뜻이다. 개인 실험 환경에는 남겨 둘 수 있을지 몰라도 공식 워크플로에는 넣지 않는 편이 좋다.

내일부터 먼저 추가할 수 있는 최소 단계 하나

아직 완전한 절차가 없다면 보안 플랫폼이 완성될 때까지 기다릴 필요는 없다. 내일부터 이 단계 하나를 먼저 추가하자.

누군가 서드파티 AI agent skill을 설치하려 할 때마다 6줄짜리 설치 신청 카드를 붙이게 한다.

1. 출처 버전: skill 출처 URL, 버전 또는 commit hash.
2. 단일 작업: 이 skill이 해결할 단일 작업.
3. 데이터 권한: 이 skill이 읽어야 하는 디렉터리와 도구.
4. 네트워크 필요: 네트워크가 필요한지 여부. 필요하다면 예상 도메인 목록.
5. 시험 데이터: 첫 dry-run에 사용할 가짜 데이터셋.
6. 이상 시 정리: 이상이 있을 때 owner가 누구인지, token을 어떻게 철회하거나 비활성화할지.

owner는 “마지막 판단과 마무리를 책임지는 사람”이다. 이 카드는 예쁠 필요는 없지만, 다음 사람이 이해할 수 있어야 한다. 왜 설치하려는지, 무엇을 허용하려는지, 그것이 선을 넘으면 누가 처리할지 말이다.

이 카드가 있으면 스캐너는 승인 절차를 대체하는 것이 아니라 승인 절차의 한 부분이 된다.

AI 정리 카드

이 글의 판단을 내 체크리스트로 바꾸기 이것은 요약 프롬프트가 아니다. 글의 방법을 내 워크플로, 제약, 데이터, 의사결정 목표에 맞춰 되돌리는 지시문이다.

이 BMC 미니 레슨을 내 상황에 적용하고 싶다: AI agent skill이 스캔을 통과했는데도, 설치 전에 왜 실행 경계를 다시 봐야 할까?

이 글이 다루는 구체적인 문제: 서드파티 AI agent skill이 스캔을 통과했다고 해서 실행 중에도 반드시 안전하다는 뜻은 아니다. 이 미니 레슨은 하나의 go/no-go 표로 출처, 권한, 샌드박스, 네트워크, 민감 데이터 경계를 점검한다.
글 URL: https://boosterminiclass.com/ko/posts/ai-agent-skill-install-runtime-risk-checklist/

글을 요약만 하지 말아 달라. 먼저 다음 3가지를 확인하는 질문을 해 달라.
1. 내가 지금 다루는 실제 워크플로 또는 의사결정은 무엇인가.
2. 이 흐름에 어떤 데이터, 권한, 계정, 비용, 외부 실행이 관련되는가.
3. 오늘 필요한 결과가 중단/진행 판단, 시험 도입 체크리스트, 인수인계 템플릿, 위험 등급 중 무엇인가.

그다음 이 글의 프레임워크로 내 상황을 점검해 달라: 

다음 형식으로 출력해 달라:
- 지금 바로 진행, 제한적으로 시험, 일단 중단 중 무엇인지 한 문장 판단;
- 프레임워크를 내 상황에 적용한 표: 준비됨 / 근거 부족 / 사람 확인 필요;
- 오늘 할 수 있는 가장 작은 한 단계;
- 담당자, 로그, 되돌리기, 사람 검토가 필요한 지점.

AI가 제약이나 출처를 확인하지 않으면, 결과를 쓰기 전에 추가로 질문한다.