메타데이터
- 제목: Agentic Security: Permissions, Provenance, and the Agent Supply Chain
- 발표자: Steve Yegge (Snyk 대표로 발표, 저서 「Vibe Coding」 저자, Gas Town/Beads 개발자)
- 채널: aiDotEngineer
- URL: https://www.youtube.com/watch?v=yWS0udrIOc8
- 날짜: 2026-07-21
- 태그: #AI #보안 #에이전트 #공급망 #슬롭스쿼팅 #Snyk #Chainguard #VibeCoding #GasTown #Beads
핵심 주장
- AI가 코드 작성 속도를 10배 높이면서 결함률이 그대로라면, 보안 취약점이 발생할 표면(surface) 자체도 10배로 커진다. 이는 어느 은행의 최고보안책임자가 스티브 예기에게 던진 질문에서 나온 통찰이며, 발표자는 이 질문에 "무릎을 꿇을 정도로" 충격을 받았다고 말한다.
- 실제로는 결함률이 그대로 유지되지도 않는다. AI가 코드를 작성할수록 결함률 자체가 더 나빠질 가능성이 크다는 것이 발표의 암묵적 전제다.
- 개발자·조직은 지금 다가오는 위험에 대해 충분히 두려워하지 않고 있다. 발표의 공식 제목은 "Agentic Security"이지만, 예기 본인이 말하는 진짜 제목은 "Be scared(무서워하라)"다.
- LLM은 안전한 코드, 우아한 코드, 성능 좋은 코드, 회사 코딩 표준을 따르는 코드를 기본값으로 동시에 써내지 못한다. 이 각각은 별도의 검토 "패스(pass)"로 다뤄야 하며, 특히 보안은 정확성(correctness)과 동시에 요구하면 둘 다 어중간하게 처리된다.
- 보안 스캐닝·공급망 검증 도구(Snyk, Chainguard 등)를 에이전트의 작업 흐름에 필수 단계로 통합해야 한다. LLM에게 이런 도구를 쥐여주면 "슈퍼파워"를 얻은 것과 같다.
주요 논거 및 근거
1. 버그의 "긴급성 반감기"와 보안의 예외성 — 구글 TAP 팀 사례
- 예기가 구글에서 함께 일했던 TAP(Test Automation Platform) 팀은 구글 전체의 유닛테스트·통합테스트를 대규모로 운영하며 버그의 생애주기를 연구했다.
- 버그는 발견 시점과 실제 수정 시점 사이의 시간이 길어질수록 "지금 당장 고쳐야 한다"는 긴급성이 줄어드는 일종의 반감기를 갖는다. 코드를 타이핑하는 그 순간 경고가 뜨면 바로 고치지만, 코드 리뷰 단계까지 넘어가면 "이걸 굳이 고쳐야 하나" 하고 넘어가는 게 인간 본성이라는 것.
- 문제는 보안 취약점에는 이 반감기가 적용되지 않는다는 점이다. 사용자들이 당장 불편을 겪지 않는다고 해서 위험이 줄어드는 게 아니라, 오히려 시간이 지날수록 위험이 누적된다.
- 그래서 구글이 최우선순위 결함을 "개발자의 손끝(fingertips)"에서, 즉 타이핑하는 바로 그 순간 표면화했던 것처럼, 보안 취약점도 개발자(또는 코드를 쓰는 LLM) 바로 곁에서 실시간으로 드러내야 한다는 것이 핵심 결론이다.
2. 새로운 공급망 공격: 슬롭스쿼팅(Slopsquatting)
- 예시: 개발자가 그래프 데이터베이스가 필요하다고 하면 LLM이 "graphy123" 같은 실존하지 않는 패키지 이름을 환각(hallucination)해 낸다.
- 빌드도 되고 테스트도 통과하고 겉보기엔 정상으로 보이지만, 실제로는 이 패키지명이 존재하지 않는다는 사실을 노린 공격자가 미리 그 이름으로 백도어가 심긴 패키지를 업로드해 둔 것이다. LLM이 자주 환각하는 이름을 공격자가 관찰해 선점하는 방식.
- 이런 유형의 공격은 탐지 자체가 매우 어렵다는 점에서 특히 위협적이다.
3. "Rule of Five"와 패스 분리의 원칙
- 예기가 발견한 경험칙: LLM이 만든 결과물이 실제로 출시 가능한 수준이 되려면 보통 4~5회의 검토(리뷰)를 거쳐야 한다. LLM의 인지 과정은 사람과 유사해서 초안 → 수정 → 다듬기·편집의 여러 패스를 거쳐야 완성도가 나온다(벽에 페인트를 한 번에 칠하지 않고 여러 겹 칠하는 것과 비슷한 비유).
- Fable(예기가 짧은 기간 사용해 본 AI 코딩 에이전트) 같은 우수한 모델조차도 이 다중 패스 특성에서 자유롭지 않다. 정확성과 보안을 동시에 한 번의 지시로 요구하면 둘 다 대충 처리된다. 따라서 반드시 별도의 패스로 나눠서 지시해야 한다.
4. 실제 검증 사례: Fable의 보안 강화 vs Snyk 스캔 결과
- 예기는 30년간 만들어온 자신의 게임 프로젝트에서 Fable에게 보안 강화(hardening) 패스를 맡겼다. Fable은 클라우드 설정 강화, 노출된 자격증명 정리 등을 수행하고 "강화 패스가 잘 됐다"는 식의 확신을 보였다.
- 이후 Snyk을 돌려보니 Fable이 전혀 찾아내지 못한 취약점이 241개나 발견됐다. Fable이 XSS 취약점을 직접 만들어낸 사례도 있었다(구세대 취약점 유형이지만 여전히 발생).
- 결론: AI가 스스로 "보안 강화를 마쳤다"고 말해도 이는 신뢰할 근거가 되지 못하며, 전용 보안 스캐닝 도구로 별도 검증해야 한다.
5. Five Eyes의 경고: 오픈소스 모델의 최상위 모델 추격 속도
- Five Eyes(미국·영국·캐나다·호주·뉴질랜드 정보 동맹)가 오픈소스 모델이 최상위(frontier) 모델을 따라잡는 데 걸리는 시간이 "년 단위가 아니라 월 단위"로 좁혀졌다고 경고했다.
- 발표 현장에서 청중에게 예상 시점을 물었을 때 한 명이 "12월"이라고 답했고, 예기는 이를 정확하다고 인정하며 대략 6~7개월 정도로 줄어들고 있다고 언급했다. 이는 곧 강력한 해킹 능력을 갖춘 모델에 대한 접근 장벽이 매우 빠르게 낮아진다는 의미다.
세부 내용 및 사례
Software Survival 3.0 에세이 요지
- 5개월 전 예기가 쓴 에세이 "Software Survival 3.0"의 핵심: LLM은 원하는 어떤 소프트웨어든 합성(synthesize)해낼 수 있지만, 토큰 사용을 아끼려는(비용·전력·환경 부담을 줄이려는) "좋은 의미의 게으름"을 갖고 있다.
- 그래서 LLM은 토큰을 아낄 수 있다면 적극적으로 도구를 활용한다. 이 특성을 활용해 Snyk이나 Chainguard 같은 도구를 에이전트에게 쥐여주면 자연스럽게 활용하게 된다는 것.
도구 소개
- Chainguard: 사전에 취약점 검증을 마친 컨테이너 이미지를 제공하고 지속적으로 업데이트해주는 공급망 서비스. "입력값(inputs)"을 안전하게 만들어주는 역할.
- Snyk: 개발자가 직접 작성한 코드, LLM이 작성한 코드, 슬롭스쿼팅을 포함한 외부 의존성까지 폭넓게 취약점을 스캔. 예기는 "Snyk이 CVE 등록 전의 비공개 취약점까지 잡아낼 수 있다"는 이야기를 들었지만, 본인이 실제로 돌려봤을 때는 이미 공개된 CVE만 발견됐다고 솔직히 언급했다. 다만 사용성 자체는 매우 쉬웠다고 평가.
- 실전 팁: 여러 보안 도구(오픈소스 도구, Snyk, Chainguard 등)를 프롬프트에 "마지막으로 확인할 패스"로 추가하고, 도구들끼리 서로의 결과를 교차 검증하게 하면 출시 전 보안 점검을 더 견고하게 만들 수 있다.
가족을 노린 AI 사칭 사기 경고
- AI 음성·영상 클로닝을 이용해 곤경에 처한 가족을 사칭하며 돈을 요구하는 사기가 몇 달 내로 본격화될 것이라고 경고. 영상까지 동반되어 매우 설득력 있게 다가온다는 점이 특징.
- 예기는 청중에게 오프라인으로 가족을 만나 미리 "암구호(code word)"를 정해둘 것을 권했다. 미국 의회가 은행 계좌를 빼가는 방식의 비공개 시연을 받은 적이 있다는 이야기도 언급했으며, 예기 본인은 거의 2년 전부터 이 문제를 우려해왔다고 밝혔다.
Q&A — AI 코딩 세계에서 최근 놀랐던 점
- AI 기술의 발전 속도가 사회가 이를 받아들이는 속도보다 훨씬 빠르다는 점.
- 똑똑한 친구들조차 AI의 발전을 부정하거나 "사이코시스(psychosis)"라 부르며 폄하하는 모습에 놀랐다 — 사람들은 지수적(exponential) 곡선을 잘 보지 못하고, 과거 3개월과 미래 3개월 정도의 짧은 구간만 보고 "평평하다"고 착각하는 경향이 있다.
- 사람들이 AI에 대해 충분히 두려워하지도, 충분히 흥분하지도 않는다는 양쪽 모두의 반응에 놀랐다고 언급. Claude Code를 실제로 써본 사람이 청중의 대다수였다는 점도 짚었다.
Q&A — Gas Town과 Beads, 장시간 무인 에이전트 실행
- Gas Town은 지난 1월(예기 발언 시점 기준)에 재미있게 작업한 프로젝트이며, "Beads"라는 태스크 트래커를 지금도 사용 중이다. Beads를 "Agentic Foundation"에 기부하고 여러 백엔드를 붙일 계획이 있다고 언급.
- Beads는 "Boris Cherny 루프"(에이전트에게 일일이 프롬프트를 주지 않고 장시간 무인으로 돌아가게 하는 방식)를 가능하게 하는 도구. 충분한 작업을 큐에 쌓아두면 에이전트들이 스스로 작업을 가져가(claim) 처리한다.
- 실제 일화: 예기가 많은 태스크(비즈)를 등록했는데 어느 순간 목록에서 사라져서 "버그인가, 데이터가 날아갔나" 걱정했지만, 알고 보니 한 에이전트가 스스로 작업들을 찾아 전부 구현을 완료한 것이었다. 이 경험 이후 "스웜(에이전트 무리)"에 대한 신뢰가 생겼다고 밝혔다.
- 청중 중 코딩 에이전트를 동시에 10개 이상 돌려본 사람은 소수에 불과했으며, 예기는 내년(2027년)에는 이런 방식이 훨씬 빠르게 대중화될 것으로 전망했다.
Q&A — 24/7 자율 에이전트에 대한 감시/감독 체계
- 시간 부족으로 발표에서 다루지 못한 "세 번째 축"으로 언급. 예기가 자문 중인 테슬라 같은 조직들이 실제로 겪고 있는 문제라고 설명.
- 많은 조직이 24시간 내내 이벤트에 반응하고 큐를 처리하는 에이전트를 세우기 시작했으며, "누가 이 에이전트들을 감시하는가"라는 질문이 새로운 프론티어로 떠오르고 있다고 강조.
- 한 에이전트에게만 큐 관리를 맡기면 결국 언젠가는 실수를 저지르기 때문에, 적대적(adversarial)인 감독 에이전트 그룹을 두고 서로를 견제·감시하게 하는 구조를 권장했다.
- 이런 감독 시스템은 서비스 계정에 부여된 권한이 실제로 필요한지("이 작업 하나에만 필요한 권한인가?")를 점검하고 과도한 권한을 분리·축소하는 "강화(hardening)" 역할도 겸해야 한다.
- 아직 이 분야는 실험적인 수준의 도구만 존재하는 초기 단계지만, 지금 당장 사내에서 자체 설계를 시작해야 한다고 강조했다. 그렇지 않으면 엔지니어든 비엔지니어든 과도한 권한을 가진 에이전트를 마구 만들어낼 것이고, 문제가 터지는 순간("곰이 이글루를 물어뜯는 순간") 돌이킬 수 없는 피해로 이어진다는 오래된 보안 비유를 인용했다.
Q&A — 프롬프트 인젝션 대응 모범 사례
- 원래 본 발표에서 다루려 했으나 시간이 부족해 언급하지 못했던 주제.
- 학습(training) 단계와 추론(inference) 단계 양쪽 모두에서 공격이 발생하고 있으며, 공격자들이 이 둘로 파고드는 방법을 찾고 있다고 설명.
- 가장 단순한 형태는 "새로운 형태의 XSRF"에 비유: 사용자가 입력한 텍스트에 악의적인 행위자가 "이전 지시는 모두 무시하고 다음을 수행하라"는 문구를 심어 넣는 방식이며, 여기서부터 점점 더 정교해진다.
- 예기는 "지금 당장 뾰족한 해법은 없다"며, 현재로서는 조직 구성원 전체를 대상으로 한 인식 교육이 우선이라고 답했다.
- 기업 내부에 기존 보안 조직의 연장선으로 **"에이전틱 보안(Agentic Security)"**이라는 새로운 보안 직무·역할이 곧 생겨날 것이라고 전망했으며, 청중 중 일부는 이미 배포된 에이전트들의 보안을 담당하고 있다는 반응을 보였다.
시사점 및 액션포인트
- 보안 검토를 코드 생성·커밋 시점에 실시간으로 통합하라. 사후 리뷰 단계까지 미루면 인간 본성상 넘어가기 쉽고, 보안 취약점은 시간이 지나도 위험이 줄지 않고 누적된다는 점을 명심할 것.
- 정확성(correctness) 검토와 보안 검토를 절대 한 번에 같이 지시하지 말고 별도 패스로 분리하라. LLM에게 "코드도 맞고 안전하기도 하게 해줘"라고 한 번에 요구하면 둘 다 어중간해진다.
- AI 에이전트가 "보안 강화를 마쳤다"고 보고해도 그 말을 그대로 신뢰하지 말고, Snyk 같은 전용 보안 스캐너로 반드시 재검증하라. 실제 사례에서 AI 자체 판단과 전용 스캐너 결과 사이에 241개의 격차가 있었다.
- 신규 패키지·의존성을 LLM이 제안할 때마다 슬롭스쿼팅 가능성을 의심하고, 실제 존재 여부와 평판(다운로드 수, 유지보수 이력 등)을 별도로 검증하라.
- 보안 스캐너, 공급망 검증 도구(Chainguard 등)를 에이전트 워크플로우의 필수 단계로 프롬프트에 명시하고, 여러 도구를 동시에 돌려 서로의 결과를 교차 검증하게 하라.
- 24/7 자율 실행 에이전트를 운영 중이거나 계획 중이라면, 지금부터 적대적 감독 에이전트 체계와 서비스 계정 권한 최소화(최소권한 원칙) 설계를 시작하라. 아직 성숙한 솔루션이 없는 초기 단계이므로 자체 설계가 필요하다.
- 가족 구성원과 사전에 암구호(code word)를 정해, AI 음성·영상 사칭을 이용한 긴급 송금 사기에 대비하라. 몇 달 내 본격화될 위협으로 지목됨.
- 조직 내 프롬프트 인젝션에 대한 전사적 인식 교육을 지금 시작하라. 아직 완전한 기술적 해법이 없는 만큼 사람의 경계심이 1차 방어선이다.
- "에이전틱 보안" 담당 인력·역할을 조직 내에 신설하는 것을 고려하라. 기존 보안팀의 자연스러운 확장 형태로 이미 일부 조직에서 등장하고 있다.
- 보안 검토를 개발 파이프라인의 "첫 번째 패스이자 마지막 패스"로 설계하라. 시작할 때부터 끝날 때까지 놓치지 않는 것이 핵심 메시지다.
본 노트는 aiDotEngineer 컨퍼런스에서 발표된 Steve Yegge의 세션 자막을 기반으로 작성된 한국어 심층 요약입니다.