스킬팩 한 장으로 코딩 에이전트의 성격이 바뀐다면: 엔터프라이즈 AI 가드레일을 다시 봅니다
개요
AI 코딩 에이전트가 어디까지 할 수 있는지는 점점 모델 자체가 아니라 그 위에 얹는 스킬과 설정이 결정합니다. 2026년 6월, 이 변화의 위험한 면을 보여주는 사건이 있었습니다. 한 보안 연구자가 라우팅 설정 파일 한 장으로 범용 코딩 에이전트를 20여 개의 전문 워크플로로 자동 분류·재배치하는 스킬팩을 공개했고, 본인 스스로 이것이 위험한 이중용도(dual-use) 프로젝트라고 명시했습니다.
이 글의 목적은 그 도구를 소개하거나 사용법을 설명하는 것이 아닙니다. 그 반대입니다. 이 사건이 드러낸 구조적 문제, 즉 “스킬팩 한 장으로 에이전트의 성격이 바뀐다”는 사실이 엔터프라이즈 환경에서 무엇을 의미하는지, 그리고 그것을 어떻게 방어하는지를 다룹니다. 따라서 공격 기법이나 해당 프로젝트의 위치는 의도적으로 싣지 않습니다. ThakiCloud는 쿠버네티스 기반 AI/ML SaaS 플랫폼에서 여러 고객의 에이전트 워크로드를 동시에 운영하기 때문에, 이런 거버넌스 문제는 추상적 우려가 아니라 플랫폼이 매일 다루는 설계 과제입니다.
무슨 일이 있었나: 스킬팩 한 장이 일으킨 논쟁
사건의 골자는 이렇습니다. 모델은 그대로 두고, 라우팅 규칙이 담긴 설정 한 장만 얹어 범용 에이전트를 특정 목적의 작업 파이프라인으로 바꿀 수 있다는 것입니다. 공개된 스킬팩은 다양한 보안 연구·역공학 계열 워크플로를 자동으로 분류하도록 구성돼 있었고, 저자는 이 조합이 악용될 수 있음을 분명히 경고했습니다.
여기서 주목할 점은 도구 하나의 선악이 아닙니다. 진짜 시사점은 추상화 수준이 낮아졌다는 데 있습니다. 과거에는 전문 도구를 다루려면 사람이 직접 그 도구를 익히고 명령을 조합해야 했습니다. 이제는 자연어로 의도를 주면 에이전트가 적절한 스킬을 골라 실행합니다. 이 편의성은 정당한 생산성 향상의 원천이지만, 동시에 악의적 의도와 실행 능력 사이의 거리도 함께 좁힙니다. 그래서 “무엇을 실행할 수 있는가”를 모델의 선의에 맡기는 것이 아니라, 시스템 차원의 경계로 강제하는 일이 필수가 됩니다.
AI 코딩 에이전트가 만든 새로운 공격면
전통적인 소프트웨어의 공격면은 비교적 정적입니다. 코드가 정해져 있고, 그 코드가 무엇을 하는지는 배포 전에 고정됩니다. 에이전트는 다릅니다. 같은 모델, 같은 바이너리라도 어떤 스킬을 로드하고 어떤 도구에 접근할 수 있느냐에 따라 행동이 런타임에 달라집니다. 즉 공격면이 동적입니다.
[ 사용자 의도(자연어) ]
|
v
[ 에이전트 + 로드된 스킬팩 ] <-- 여기서 행동이 런타임에 결정됨
|
+--> [ 파일시스템 접근 ]
+--> [ 셸·명령 실행 ]
+--> [ 네트워크 이그레스 ]
+--> [ 외부 도구·MCP 호출 ]
v
[ 실제 부작용(side effect) ]
이 동적 공격면은 세 가지 새로운 위험을 만듭니다. 첫째, 스킬 주입입니다. 신뢰할 수 없는 출처의 스킬이나 설정을 로드하면 에이전트의 행동 자체가 바뀝니다. 둘째, 권한 확대입니다. 에이전트에 넓은 도구 권한을 한 번 부여하면, 그 권한은 의도와 무관하게 모든 작업에 그대로 적용됩니다. 셋째, 데이터 유출입니다. 코드베이스 전체를 읽고 외부로 통신할 수 있는 에이전트는, 통제되지 않으면 민감 데이터의 이동 통로가 됩니다. 이 세 가지는 모두 “모델이 똑똑한가”와 무관하게 발생합니다. 똑똑한 모델일수록 오히려 더 효율적으로 위험을 실행할 수 있습니다.
가드레일 네 겹: 스킬 화이트리스트 · 도구 실행 경계 · 이그레스 통제 · 감사추적
방어는 모델의 선의가 아니라 시스템의 경계로 합니다. 실무에서 검증된 네 겹의 가드레일을 정리합니다.
첫째, 스킬 화이트리스트입니다. 에이전트가 로드할 수 있는 스킬과 설정의 출처를 명시적으로 제한합니다. 임의의 원격 스킬을 즉석에서 끌어다 실행하지 못하게 하고, 승인된 레지스트리에 등록된 스킬만 허용합니다. 새 스킬은 등록 전에 검수 게이트를 통과하도록 합니다. ThakiCloud 내부에서도 스킬은 인덱스에 올라가기 전에 보안 검수를 거치며, 의심스러운 권한 요구나 데이터 반출 패턴을 가진 스킬은 차단됩니다.
둘째, 도구 실행 경계입니다. 에이전트에 “전부 허용”을 주지 않습니다. 파일시스템 접근은 작업 디렉터리로 한정하고, 셸 명령은 허용 목록 기반으로 좁히며, 위험한 작업은 사람의 승인 게이트 뒤에 둡니다. 비가역적 변경, 예컨대 배포나 스키마 변경은 자동 실행이 아니라 계획 검토와 승인을 거치게 합니다. 권한은 기본적으로 최소로 두고 필요할 때만 좁게 확대합니다.
셋째, 이그레스 통제입니다. 에이전트가 어디로 통신할 수 있는지를 네트워크 계층에서 제한합니다. 코드베이스를 읽을 수 있다는 것과 그것을 임의의 외부 주소로 보낼 수 있다는 것은 전혀 다른 문제입니다. 허용된 엔드포인트로만 나가도록 막으면, 설령 스킬이 오염되더라도 데이터가 빠져나갈 경로가 닫힙니다.
넷째, 감사추적입니다. 에이전트가 무엇을 로드했고, 어떤 도구를 호출했으며, 어떤 부작용을 일으켰는지를 기록합니다. 무인 실행이 늘어날수록 사후에 추적 가능한 로그의 가치가 커집니다. 누가 어떤 스킬로 무엇을 실행했는지를 재구성할 수 없다면, 사고가 났을 때 대응할 방법이 없습니다.
ThakiCloud의 멀티테넌트 에이전트 거버넌스 관점
이 네 겹의 가드레일은 단일 사용자 환경에서도 중요하지만, 멀티테넌트 플랫폼에서는 생존 조건입니다. 여러 고객의 에이전트 워크로드가 같은 인프라 위에서 도는 환경에서는, 한 테넌트의 오염된 스킬이 다른 테넌트의 데이터나 연산에 닿아서는 절대 안 됩니다.
ThakiCloud의 스택은 이 격리를 인프라 계층에서 강제하도록 구성돼 있습니다. 쿠버네티스의 네임스페이스와 RBAC로 테넌트 경계를 나누고, 네트워크 정책으로 이그레스를 통제하며, Kueue로 GPU 작업을 큐잉할 때도 테넌트별 우선순위와 자원 한도를 적용합니다. 에이전트가 아무리 자유롭게 스킬을 조합하더라도, 그 실행은 결국 플랫폼이 정한 네임스페이스·권한·네트워크 경계 안에서만 일어납니다. 모델의 행동은 동적이지만, 그 행동이 미칠 수 있는 범위는 정적으로 고정돼 있는 셈입니다.
이 지점이 온프레미스·소버린 AI 수요와 직결됩니다. 데이터 반출이 제약되는 조직, 특히 보안 요구가 강한 공공·금융 환경에서는 에이전트가 외부 API로 끊임없이 데이터를 흘려보내는 구조 자체가 도입의 걸림돌입니다. 자체 인프라 안에서 에이전트를 돌리고, 스킬 출처와 네트워크 경계를 직접 통제할 수 있어야 비로소 도입이 가능합니다. ThakiCloud가 self-hosting과 멀티테넌트 격리를 강조하는 이유가 여기에 있습니다. 에이전트의 자율성이 커질수록, 그 자율성을 담는 통제 가능한 그릇의 가치가 함께 커집니다.
한계 및 반론
가장 강한 반론은 가드레일이 생산성을 떨어뜨린다는 것입니다. 실제로 권한을 좁히고 승인 게이트를 늘리면 에이전트의 자유도가 줄고, 일부 작업은 느려집니다. 그러나 이것은 트레이드오프이지 손해가 아닙니다. 통제되지 않은 자율성은 평균적으로는 빠르게 보이지만, 사고 한 번의 비용이 그동안의 이득을 모두 상쇄합니다. 핵심은 가드레일을 모든 작업에 똑같이 두껍게 두는 것이 아니라, 위험도에 비례해 차등 적용하는 것입니다. 읽기 전용 탐색은 가볍게, 비가역적 변경은 무겁게 두면 됩니다.
둘째, 가드레일도 완벽하지 않습니다. 화이트리스트는 등록된 스킬 내부의 악의는 잡지 못하고, 이그레스 통제는 허용된 엔드포인트를 경유한 우회까지 막지는 못합니다. 그래서 단일 방어선에 의존하지 않고 네 겹을 겹쳐 두는 것입니다. 한 겹이 뚫려도 다음 겹이 피해 범위를 줄이도록 설계하는 심층 방어가 현실적인 목표입니다.
셋째, 이 사건을 특정 도구의 문제로 좁혀 보는 시각에 반대합니다. 문제의 본질은 그 도구가 아니라, 스킬과 설정으로 에이전트의 행동을 런타임에 재정의할 수 있게 된 구조 전체입니다. 그 구조는 정당한 생산성의 원천이기도 합니다. 따라서 답은 능력을 막는 것이 아니라, 그 능력이 미칠 수 있는 범위를 시스템으로 경계 짓는 것입니다.
출처
- 원 트윗(이중용도 경고 포함): x.com/hjguyhan/status/2069026847523049739