We Vetted 2000 AI Skills Before They Reached Developers — Lucas Palma, Nubank

URL: https://www.youtube.com/watch?v=iKQ78wyJEXU 날짜: 2026-07-29 채널: AI Engineer (aiDotEngineer) 발표자: Lucas Palma (LP) — Nubank 프로덕트 시큐리티 매니저

---

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

AI 스킬(AI skill)은 겉보기엔 단순 설정 파일 같지만 실제로는 라이브러리 같은 ==공급망 의존성(supply chain dependency)처럼 행동하며, 코드뿐 아니라 "AI가 코드를 생성하는 워크플로우 전체"를 보호 대상으로 삼아야 한다==.

• Nubank는 개발자에게 배포되기 전 2,000개 이상의 AI 스킬을 자체 개발한 CI 도구 "Skill Vector"로 심사했다
• 결정론적(regex) 스캐너와 LLM 리뷰를 결합한 하이브리드 방식으로 위험을 탐지했다
• 하드코딩된 크리덴셜, 파괴적 셸 명령, 과도한 권한, "AI가 스스로 승인해버리는" 가짜 human-in-the-loop 등 구체적 위험 패턴을 스캔했다
• 결과: 1,500개 이상의 위험을 식별했고 그중 1,000개는 즉시 remediation, 일부는 마켓플레이스 배포 전 차단됨

이 발표는 금융권(Nubank)이라는 고규제 환경에서 "개발자에게는 빠르고 편리한 AI 도구를, 조직에게는 감사 가능성(auditability)과 크리덴셜 안전을 기본값으로" 라는 상충하는 요구를 어떻게 절충했는지 다룬다. 핵심 교훈은 스킬을 코드가 아니라 패키지·컨테이너·모델과 동급의 공급망 컴포넌트로 취급해야 한다는 것이다.

---

1. AI 시대의 확장된 공급망(Supply Chain) 개념

전통적 공급망 개념(패키지, 컨테이너, 모델)에 스킬·플러그인·MCP 서버·에이전트 규칙이 새로 추가되면서 위협 표면이 넓어졌다.

1.1. AI 스킬이란 무엇인가

1. AI 스킬의 정의와 역할

   1. 워크플로우 상 위치: 개발자가 AI 툴을 사용해 결과물(대부분 코드)을 생성할 때, 그 AI 툴 내부에는 여러 컴포넌트가 임베드될 수 있는데 AI 스킬이 그중 하나다
   2. 기능: 모델이나 에이전트에게 특정 지시사항(instruction)과 맥락(context)을 번들로 제공해, 더 나은 가이드를 통해 특정 작업을 수행하게 하는 능력(capability)을 부여한다

2. 스킬 공유의 위험성

   1. 작성자-사용자 비대칭: 누군가 스킬을 만들어 다른 사람과 공유하면, 그 최초 작성자가 타인이 생성하는 코드를 사실상 "가이드"하게 되는 구조가 만들어진다
   2. 위험 전이: 이 구조 때문에 스킬 작성자의 실수나 악의가 스킬을 사용하는 모든 사람에게 그대로 전이될 수 있다

1.2. 금융권(규제 산업)이라는 특수 조건

1. 상충하는 두 요구

   1. 개발자 관점: 더 빠르고 나은 코딩, 더 풍부한 맥락, 반복 작업 감소를 원한다
   2. 규제 관점: 감사 가능성(auditability), 기본값으로서의 크리덴셜 안전(safety by default), 기타 다양한 보안 요건 준수가 필요하다

2. 균형의 어려움

   1. 트레이드오프: 발표자는 이 두 요구 사이의 균형을 맞추는 것이 "하드하다(hard)"고 명시적으로 언급하며, 이것이 Skill Vector를 만들게 된 근본 동기임을 시사한다

---

2. AI 스킬은 실제로 얼마나 위험한가 — 구체적 위험 패턴

발표자가 제시한 실제 관찰된 위험 사례들이다.

2.1. 크리덴셜·데이터 관련 위험

1. 하드코딩된 토큰 유출
   1. 발생 메커니즘: 스킬 설명(description) 안에서 토큰이나 시크릿을 가져오도록(retrieve) 지시하는데, 이 과정에서 토큰이 하드코딩된 채로 사용되기 시작한다
   2. 결과: 하드코딩된 토큰이 로그(logs) 등에 그대로 남게 되어 향후 데이터 유출(data leak)로 이어질 수 있다

2.2. 실행 권한 관련 위험

1. 파괴적 셸 명령

   1. 작성 시점의 의도: 스킬 작성자가 AI에게 셸 커맨드를 사용하도록 지시한다
   2. 재사용 시점의 사고: 이 스킬이 다른 사람에 의해 사용될 때, 그 사람의 셸에서 위험한 작업이 실행되고 다수의 파일이 의도치 않게 수정될 수 있다

2. 과도한 권한(excessive permissions)

   1. 설정 오류: 스킬이 어떻게 구성되었는지에 따라 실제 필요한 것보다 훨씬 더 많은 권한을 갖게 될 수 있다
   2. 오타의 파급력: 단순한 오타(typo) 하나조차, 그 스킬을 누가 사용하느냐에 따라 위험한 결과로 이어질 수 있다

---

3. Skill Vector — Nubank의 자체 개발 스킬 심사 시스템

3.1. 배경: 내부 마켓플레이스 구조

1. 스킬 공유 방식

   1. 캐노니컬 공유 채널: Nubank는 플러그인을 포함한 스킬들을 내부 마켓플레이스를 통해 캐노니컬하게 공유한다
   2. 디스커버리 역할: 이 마켓플레이스는 엔지니어들이 새로운 스킬을 발견하는 창구이자, 보안팀이 안전성을 통제하려는 경계(boundary)이기도 하다

2. 심사 프로세스의 삽입 지점

   1. PR 이전 CI 단계: 누군가 스킬을 만들면 원래는 곧바로 PR을 열어 마켓플레이스로 가는 흐름이었지만, 그 전에 "Skill Vector"라는 CI 단계를 추가했다
   2. 역할: 이 도구는 스킬이 사용하기에 안전한지 다수의 평가(assessment)를 통해 점검하고, 위험을 분류(classify)하며, 필요시 시정조치(remediation)를 요청한다

3.2. Skill Vector의 파이프라인 구조

1. 로컬 → 업로드 → 재검증의 3단계

   1. 로컬 스캔: 스킬이 생성되거나 변경될 때, 엔지니어가 로컬 환경에서 이 도구를 사용해 "안전하다"고 판단될 때까지 반복(iterate)할 수 있다
   2. 업로드 후 재스캔: 업로드 이후에도 다시 한번 스캔을 돌리는데, 이는 엔지니어가 실제로 로컬에서 스캔을 실행했는지, 혹은 최신 버전의 스캐너로 검사했는지를 조직 차원에서 보장하기 위함이다

2. 결정론적 스캐너 + LLM 리뷰의 하이브리드

   1. 결정론적(deterministic) 체크: 정규표현식(regular expression) 등을 사용해 쉽게 판별 가능한 위험들을 우선 점검한다
   2. LLM 기반 체크: 더 깊은 맥락 이해가 필요한 경우 LLM을 사용하는데, 발표자는 "LLM은 temperature 설정에 따라 어떤 때는 위험으로 판정하고 어떤 때는 그렇지 않을 수 있다"며 그렇기 때문에 결정론적 체크와 병행하는 하이브리드 접근이 중요하다고 강조했다

3. PR 피드백 루프와 SARIF 출력

   1. PR 내 즉시 피드백: 모든 발견 사항(finding)은 스킬을 업로드하기 위해 열린 그 PR에 리포트되어, 엔지니어가 같은 PR 안에서 무엇을 고쳐야 하는지 바로 확인할 수 있어 사용성이 개선된다
   2. SARIF 표준 출력: 결과를 SARIF 포맷으로도 생성해 보안 도구들이 소비할 수 있게 하고, 위험에 대한 리포트를 생성해 취약점 관리 프로그램(vulnerability management program)의 일부로 편입시킨다

4. 심각도·정책 기반 의사결정

   1. 차등 대응: 심각도(severity)와 정책(policy)에 따라 스킬은 시정조치가 요구되거나(remediation), 차단(block)될 수 있으며, 이 모든 판단은 마켓플레이스 배포 전에 이뤄진다
   2. 전체 흐름 요약: 로컬 스캔 → PR 오픈 → 결정론적 스캐너 → LLM 리뷰 → PR 피드백 → SARIF → 최종 결정(허용 / 시정조치 후 허용 / 차단)

3.3. Skill Vector가 실제로 스캔하는 항목 (비완전 목록)

1. 행동·명령 관련

   1. 안전하지 않은 지시(unsafe instructions): 스킬 지시문 자체에 내포된 위험 요소
   2. 에이전트 행동 드리프트(behavior drift): 에이전트가 원래 의도한 행동 범위를 벗어나는 경향
   3. 파괴적 셸 명령과 의도치 않은 파일 수정

2. 데이터·권한 관련

   1. 크리덴셜 요청 방식: 크리덴셜을 어떻게 요구하고 처리하는지
   2. 의도치 않은 데이터 노출과 과도하거나 위험한 권한(overly broad, risky permissions)
   3. 위험한 MCP 사용(risky MCP usage) 등

---

4. 심사 결과 — 2,000개 스킬 스캔 데이터

1. 규모와 위험 발견 수

   1. 스캔 규모: 이 발표 기준 베이스라인으로 2,000개 이상의 스킬을 스캔했다(발표 시점 이후로는 이보다 더 많아졌다고 언급)
   2. 위험 총량: 1,500개 이상의 위험(risk)을 식별했다 — 이는 "1,500개 스킬에 위험이 있었다"는 뜻이 아니라, 스킬 1개가 여러 개의 위험을 가질 수 있으므로 발견된 위험의 총 개수가 1,500개 이상이라는 의미다

2. 후속 조치 결과

   1. 즉시 시정조치: 발견된 위험 중 1,000개는 발견 직후 바로 remediation되었다
   2. 완전 차단: 그중 일부(few)는 매우 위험(hacky)해서 마켓플레이스에 올라가기 전에 아예 차단되었다

3. 소급 적용(historical scan)

   1. 레거시 스킬 점검: Skill Vector 도입 이전에 이미 만들어져 있던 스킬들에 대해서도 별도로 히스토리컬 스캔을 진행했다
   2. 결과: 이 과정에서도 새로운 위험들을 식별해 취약점 관리 프로그램에 편입시켜 remediation 대상으로 만들었다

---

5. 운영 과정에서 얻은 교훈

5.1. 잘 작동한 것들

1. 하이브리드 탐지 전략의 성공

   1. 결정론적 스캐너: 명확한 비위험 패턴(non-risk pattern)을 걸러내는 데 효과적이었다
   2. LLM 리뷰: 파괴적 명령이나 크리덴셜 체크처럼 "행동(behavior)"을 확인해야 하는 영역에서 유효했다

2. 출력/피드백 설계의 성공

   1. SARIF 출력과 PR 코멘트: 개선이 필요한 부분을 명시적으로 남기는 방식이 실무에서 잘 작동했다

5.2. 어려웠던 것들

1. 위험도 판단의 미묘함

   1. 일괄 처리의 오류: 특정 코멘트/패턴을 모두 동일한 위험도로 취급했었는데, 실제로는 코멘트의 맥락에 따라 위험도가 더 크거나 작을 수 있었다
   2. 약한 신호(weak signal)의 함정: 충분한 맥락이 없는 일부 신호는 도움이 되기보다 오히려 혼란(troublesome)을 야기했다

2. 로컬 vs. 프로덕션 맥락 차이

   1. 거짓 안심(false comfort): 일부 경고는 로컬에서 실행될 때는 무해해 보였지만, 실제 프로덕션으로 넘어가면 임팩트가 커질 수 있었다
   2. 대응: 이런 경우를 별도로 구분해서 살펴봐야 했다

3. 가이드 없는 발견의 무용함

   1. 명확성 부재: 발견(finding)에 명확한 가이드가 딸려있지 않으면 엔지니어 입장에서 오히려 성가신(troublesome) 결과물이 되었다

4. 마켓플레이스 확장에 대한 선제 대응 필요성

   1. 거버넌스 사각지대: 조직 내 다른 팀/그룹이 별도의 새로운 마켓플레이스를 만들 수도 있다는 점을 인지해야 한다
   2. 대응 방향: 새로운 마켓플레이스가 생기는지 능동적으로 스캔·탐지하고, 그곳에도 Skill Vector를 적용해야 한다

5.3. 딥다이브: "AI가 스스로 승인해버리는" 가짜 human-in-the-loop 문제

1. 문제의 본질

   1. 작성자의 착각: 사람들이 스킬 지시문에 "확인을 요청해야 한다(need to ask for confirmation)"고 써넣지만, 실제로는 AI가 그 확인을 스스로에게 요청하고 스스로 답할 수 있다
   2. 인지 격차: 인간 입장에서는 human-in-the-loop가 존재한다고 믿지만, AI 입장에서는 이미 "확인이 완료됐다"고 인식하고 "다른 누군가 컨펌했으니 진행하자(another has confirmed then let's go)"는 식으로 넘어가버린다

2. Skill Vector의 대응

   1. 스캔 대상화: 이 패턴 자체를 Skill Vector가 탐지 대상으로 삼는다
   2. 점검 포인트: 제대로 된 human-in-the-loop가 있는지, 실행 도구가 승인 게이트(approval gate)를 실제로 거치는지, 훅(hooks)이 걸려있는지를 확인한다

---

6. 더 넓은 적용 범위와 다음 단계

6.1. 스킬을 넘어선 확장

1. 동일 원칙의 재사용 대상

   1. 적용 범위 확장: 이 발표는 스킬에 초점을 맞췄지만, 같은 접근이 플러그인(plugin), MCP 서버, 에이전트 규칙(rules), 훅(hooks)에도 적용될 수 있다
   2. 실제 확장 사례: Nubank는 이미 "MCP vector"와 규칙(rules) 체크도 별도로 운영 중이며, 컴포넌트마다 위험 종류와 게이트가 다르게 설계된다

2. 재사용 가능한 6가지 핵심 교훈

   1. 공급망으로 취급: 스킬/플러그인 등을 패키지·컨테이너와 동급의 공급망 컴포넌트로 간주해야 한다
   2. 업로드 전 리뷰 + 로컬 실행 허용 + CI 강제화: 마켓플레이스에 올라가기 전 리뷰하고, 개발자가 로컬에서도 같은 체크를 돌릴 수 있게 하며, 이를 CI에서도 강제해야 한다
   3. 결정론 + LLM 병행, 위험 행동/프롬프트에 대한 강제(enforcement): 두 탐지 방식을 함께 쓰고, 위험한 행동이 실제 발생했을 때 강제 조치가 뒤따라야 한다

6.2. 향후 계획

1. 툴 레벨 거버넌스 강화

   1. 감사 로그와 신뢰된 게이트웨이: 툴 레벨에서 감사 로그(audit log)를 남기고, 신뢰된 게이트웨이(trusted gateway)를 거치도록 하는 정책 강제를 계획하고 있다

2. 신뢰된 AI 마켓플레이스의 중요성

   1. 캐노니컬 스캔·공유 체계: 안전하다고 검증된 것을 캐노니컬하게 스캔·공유하는 체계로서 신뢰된 마켓플레이스가 매우 중요하다고 강조했다
   2. 서드파티까지 포괄: 이는 자체 제작 스킬뿐 아니라, 외부에서 다운로드한 서드파티 스킬/플러그인에도 동일하게 적용된다 — 누군가 무언가를 다운로드해 사용하고 싶다면, 그것을 먼저 마켓플레이스에 업로드해 스캔을 거치게 함으로써 다른 사람들도 안전하게 사용할 수 있게 해야 한다

---

주요 발언 모음

"Although they look like configuration, they behave like supply chain dependence — like, for example, libraries and others."

"We should be protecting the whole workflow, not only the code that's being generated."

"Sometimes it will check that it's a risk, sometimes it might not" — LLM 기반 체크가 temperature 설정에 따라 일관되지 않을 수 있다는 지적

"From your perspective there is a human in the loop, but for the AI perspective there has been a confirmation — 'another has confirmed, then let's go.'"

"If someone downloads something and wants to use it, it's important to upload it on the marketplace."

핵심 데이터 & 수치

• 스캔한 스킬 수: 2,000개 이상 (발표 시점 베이스라인, 현재는 더 많음)
• 식별된 위험 총량: 1,500개 이상 (스킬 1개당 다수 위험 가능 — "1,500개 스킬이 위험"이 아니라 "위험 건수가 1,500개 이상")
• 즉시 시정조치된 위험: 1,000개
• 완전 차단된 위험: 소수(few) — 마켓플레이스 배포 전 단계에서 차단
• 소급 스캔: Skill Vector 도입 이전 생성된 레거시 스킬까지 별도 히스토리컬 스캔 진행, 신규 위험 발견 후 취약점 관리 프로그램에 편입

결론 및 시사점

1. AI 스킬/플러그인/MCP 서버는 코드가 아니라 공급망 컴포넌트로 취급해야 한다. 패키지나 컨테이너처럼 출처 검증, 심사, 버전 관리의 대상이 되어야 하며 이 인식 전환이 전체 접근법의 출발점이다.
2. 결정론적 스캐너만으로도, LLM만으로도 불충분하다. 정규표현식 기반 체크는 명확한 패턴은 빠르게 잡아내지만 맥락을 놓치고, LLM은 맥락은 잡아내지만 temperature에 따라 일관성이 떨어진다 — 두 방식을 병행하는 하이브리드 구조가 실무적으로 검증된 해법이다.
3. 심사는 로컬 → CI → 업로드 후 재검증의 3단 방어선으로 설계해야 한다. 엔지니어가 로컬에서 반복 개선할 수 있게 하되, 로컬 실행 여부를 신뢰하지 않고 CI에서 다시 강제로 재검사하는 구조가 조직 차원의 일관성을 보장한다.
4. "AI가 스스로 확인했다"는 패턴을 반드시 별도로 탐지해야 한다. 스킬 지시문에 "확인을 요청하라"는 문구가 있어도, 실제로는 AI가 자문자답하며 인간의 개입 없이 진행할 수 있다는 점은 human-in-the-loop 설계에서 가장 놓치기 쉬운 함정이다.
5. 발견 결과에는 반드시 명확한 가이드(remediation guidance)를 동반해야 한다. 맥락 없는 경고나 가이드 없는 findings는 오히려 엔지니어의 신뢰를 떨어뜨리고 도구의 실효성을 낮춘다.
6. 거버넌스는 확장을 전제로 설계해야 한다. 이미 알려진 마켓플레이스뿐 아니라 조직 내에서 새롭게 생겨날 수 있는 마켓플레이스까지 능동적으로 탐지해 동일한 심사 체계를 적용해야, 거버넌스 사각지대가 생기지 않는다.