AI 에이전트가 본격적으로 도구를 호출하기 시작한 뒤부터, 보안의 기준도 바뀌었습니다. 예전식 guardrail은 주로 입력과 출력의 문장을 검사합니다. 하지만 에이전트는 메모리를 쓰고, MCP 서버를 읽고, RAG 문서를 참조하고, 다른 에이전트와 협업합니다. 공격면이 넓어졌는데도 텍스트 필터 하나로 막으려 하면 언제든 빈틈이 생깁니다.
gaebalai/aigis-kr는 그 빈틈을 정면으로 겨냥합니다. 이 프로젝트의 핵심은 “문장을 분류하는 도구”가 아니라, AI 에이전트의 실행 경계를 통제하는 보안층에 가깝다는 점입니다. 2026년 5월 18일에 공개된 v1.1.4 릴리스는 한국 환경 통합, HTTP 사이드카, MCP 3단계 스캐닝, 메모리 모방 공격 탐지, 구조화 쿼리 경계 강제 같은 방향을 한꺼번에 드러냅니다.
왜 챗봇식 가드레일로는 부족한가
AI 보안을 챗봇 시대의 문제로만 보면 반쪽만 보게 됩니다. 챗봇은 대화 한 턴의 안전성만 보면 됐지만, 에이전트는 다릅니다.
- 도구 호출이 있다
- 세션 메모리가 누적된다
- 외부 문서를 RAG로 다시 읽는다
- 다른 에이전트의 출력을 다시 입력으로 받아쓴다
- 권한이 다른 작업을 연속으로 수행한다
이 구조에서는 “사용자 입력이 안전한가”만으로는 충분하지 않습니다. 안전해 보이는 출력도 다음 단계의 입력이 되면 공격 벡터가 됩니다. Aigis가 흥미로운 이유는 바로 여기입니다. 이 프로젝트는 텍스트 내용을 보기 전에, 에이전트가 무엇을 할 수 있는지부터 제한하려고 합니다.
README가 강조하듯 Aigis는 AI agents, MCP, memory poisoning, indirect injection 같은 문제를 하나의 보안층으로 묶습니다. 즉, 모델의 말이 아니라 모델이 실제로 실행하는 행동을 기준으로 설계합니다.
Aigis가 겨누는 공격면
아키텍처 문서와 README를 함께 보면 Aigis의 방어 모델은 대략 네 개의 층으로 읽힙니다.
1. 입력과 출력 텍스트
가장 익숙한 영역입니다. prompt injection, jailbreak, 인코딩된 페이로드, RAG로 섞여 들어오는 indirect injection을 막습니다. Aigis는 정규식 패턴, 유사도 검사, 디코딩 후 재검사로 이 층을 처리합니다.
여기서 중요한 점은 “한 번만 검사”하지 않는다는 것입니다. 문자열이 Base64, hex, URL encoding, ROT13, 유니코드 변형으로 우회되면 원문 기반 필터는 놓치기 쉽습니다. Aigis는 먼저 정규화하고, 필요하면 다시 디코딩한 뒤 재검사합니다. 텍스트 전처리 자체를 방어 논리의 일부로 끌어올린 셈입니다.
2. 도구 호출과 MCP
에이전트 보안에서 더 중요한 지점은 툴 호출입니다. 사용자가 허용 버튼을 눌렀더라도, 런타임 시점에 MCP 서버 정의가 바뀌거나, invocation 단계에서 이름이 섞이거나, response에 악성 지시가 끼어들 수 있습니다.
Aigis의 MCP 스캐너는 정의만 보는 것이 아니라 invocation과 response까지 이어서 봅니다. 이건 사소한 차이가 아닙니다. 실전 공격은 대부분 “등록 시점”이 아니라 “실행 시점”에 일어납니다. 즉, 보안은 문서 검토가 아니라 런타임 감시에 가까워집니다.
3. 세션 메모리
에이전트는 대화가 끝나도 기억을 남깁니다. 이 기억이 편리함이 되는 순간, 동시에 오염 경로가 됩니다. README와 changelog는 memory poisoning, sleeper injection, false-preference injection 같은 계열을 반복해서 다룹니다.
여기서 Aigis의 접근은 단순합니다. 메모리를 “좋은 요약”이 아니라 “잠재적으로 독립적인 공격 매체”로 본다는 점입니다. 그래서 세션 간 지속성 자체가 위험 요소가 됩니다.
4. 런타임 행동
이 단계가 가장 덜 자주 이야기되지만 가장 중요합니다. 에이전트는 때때로 목표에서 벗어나거나, 허용되지 않은 상태 전이를 하거나, 감사 흔적을 조작하려고 합니다. Aigis는 이 영역까지 규칙화하려고 합니다.
이 프로젝트의 문서에 등장하는 capability-based access control, atomic execution pipeline, safety specification verifier는 모두 같은 방향을 가리킵니다. “무엇을 말했는가”가 아니라 “어떤 상태 전이를 허용할 것인가”를 정의하는 방식입니다.
v1.1.4가 보여주는 방향
v1.1.4 릴리스 노트는 이 프로젝트가 어디를 향하는지 꽤 선명하게 보여줍니다.
첫째, 한국 환경 통합이 들어갔습니다. PIPA, 금융위 AI, ISMS-P 같은 키워드는 단순 번역이 아니라 국내 도입 맥락을 신경 썼다는 뜻입니다. AI 보안은 기술만으로 끝나지 않고, 규제 언어로 다시 설명될 수 있어야 현장에서 채택됩니다.
둘째, HTTP sidecar와 Dockerfile, GHCR 배포 흐름이 추가됐습니다. 이건 Aigis가 라이브러리만이 아니라 배포 가능한 보안 구성요소로 취급된다는 신호입니다. 에이전트 앞단에 프록시처럼 두거나, 서비스 옆에 붙이는 방식이 가능해집니다.
셋째, MCP invocation + response stage scanner가 붙으면서 3단계 커버리지가 완성됐습니다. Aigis가 가장 중요하게 보는 공격면이 어디인지 분명합니다. 이제는 “등록된 도구가 안전한가”보다 “실행 중에 무슨 일이 벌어지는가”가 핵심입니다.
넷째, semantic-imitation detector, goal-conditioned FSM, StruQ-style structured query boundary enforcement, RAG context filter 같은 기능이 보입니다. 이 조합은 한 가지 메시지를 줍니다. 에이전트 보안은 단일 룰로 끝나는 문제가 아니라, 경계 설정과 상태 제약의 문제라는 것입니다.
이 관점이 좋습니다. 프롬프트 필터는 메시지 수준에서만 유효하지만, 상태 기계와 경계 강제는 시스템 전체의 행동을 제한합니다. Aigis는 점점 “문장 감시기”에서 “정책 집행기”로 이동하고 있습니다.
도입 관점에서의 장점
Aigis가 실무에서 매력적인 이유는 기술적 야심보다 운영적 성질에 있습니다.
Deterministic
판단이 결정적입니다. LLM 심사위원을 다시 부르지 않으니 결과가 흔들리지 않습니다. 감사와 재현성이 중요한 환경에서는 이게 큰 장점입니다.
Zero dependency
코어는 표준 라이브러리만으로 동작합니다. 보안 도구가 외부 의존성에 많이 기대면 공급망 리스크가 같이 따라옵니다. 이 프로젝트는 그 부담을 의도적으로 줄였습니다.
Multiple integration surfaces
Getting Started 문서에는 Guard 클래스, FastAPI middleware, OpenAI / Anthropic proxy, LangChain callback, Claude Code hooks가 같이 나옵니다. 이건 중요한 설계 신호입니다. 하나의 알고리즘을 여러 제품군에 얇게 입히는 구조가 아니라, 동일한 정책 엔진을 여러 실행 지점에 끼워 넣는 구조입니다.
Policy as data
44개의 compliance template를 YAML로 읽고 수정할 수 있다는 점도 실용적입니다. 보안팀이나 컴플라이언스 팀은 코드보다 정책 문서를 먼저 건드립니다. 정책을 데이터로 두면 운영 속도가 빨라집니다.
다만, 이 도구를 어떻게 읽어야 하는가
Aigis를 읽을 때는 장점만 보면 안 됩니다. 이 프로젝트는 분명 강력하지만, 동시에 성격이 뚜렷합니다.
- 규칙 기반이다
- 정규화와 패턴에 강하다
- 결정적이고 감사하기 쉽다
- 대신 완전히 새로운 공격 패턴에는 업데이트가 필요하다
즉, Aigis는 “모든 AI 안전 문제를 해결하는 만능 모델”이라기보다, 실행 경계에 두는 1차 방어선으로 보는 편이 맞습니다. 이런 도구는 단독 방어막보다, 정책, 리뷰, 샌드박스, 권한 관리와 함께 놓일 때 가장 강합니다.
개인적으로 이 프로젝트의 가치 포인트는 거창한 모델 성능이 아닙니다. 오히려 “에이전트 보안은 프롬프트의 미학이 아니라 실행의 통제”라는 사실을 구현으로 보여준 데 있습니다. 그래서 Aigis는 데모성 guardrail보다 훨씬 실용적으로 읽힙니다.
마치며
Aigis-kr는 AI 에이전트 보안을 한 단계 넓혀 봅니다. 입력을 막는 것에서 끝내지 않고, 도구 호출, 메모리, RAG, 상태 전이를 함께 다룹니다. 그래서 이 프로젝트는 단순한 필터가 아니라, 에이전트 앞단에 놓는 실행 경계에 가깝습니다.
2026년 5월 18일 공개된 v1.1.4는 그 방향을 더 분명하게 했습니다. 한국 규제 맥락, HTTP 사이드카, MCP 3단계 스캐닝, 메모리 오염 방어, 구조화 쿼리 경계 강제까지 들어가면서, 이 프로젝트가 “보여주기용 보안”이 아니라 실제 운영용 보안으로 이동하고 있다는 인상을 줍니다.
에이전트가 계속 더 많은 일을 하게 될수록, 이런 종류의 실행 경계는 점점 중요해질 것입니다. 모델이 똑똑해지는 것만으로는 부족하고, 똑똑한 모델이 어디까지 할 수 있는지 정하는 일이 더 어려워집니다. Aigis는 그 어려운 부분을 다루려는 프로젝트입니다.