제로 트러스트 버리고 에이전트 액세스 모델로 전환한 이유

카테고리: IT 최신동향 | 작성자: Tech Reporter | 발행일: 2026-08-05

요약: 인간 중심 Zero Trust의 한계를 극복하고 AI 에이전트 전용 보안 아키텍처(AAM)를 도입해 데이터 유출 위험을 차단한 실무 아키텍처 경험담입니다.

새벽 2시 15분, 삐삐 울리는 둔탁한 알람 소리에 잠에서 깼습니다. 보안 관제 시스템이 보낸 긴급 모니터링 경고였습니다. 특정 사내 에이전트 서비스 계정이 단 3초 만에 5만 개가 넘는 내부 데이터베이스 테이블을 조회하고, 외부 API로 연쇄 호출을 보내고 있었습니다. 사내 사기 탐지(Fraud Detection) 및 계정 정산 작업을 자동화하겠다고 투입한 LLM 기반 사내 에이전트가 원인이었습니다. 프롬프트 루프가 이상 동작을 일으키면서 데이터베이스 전체를 스캔하기 시작한 것이죠. 더 큰 문제는 보안 시스템이 이 동작을 전혀 이상 행동으로 차단하지 못했다는 점입니다. 해당 에이전트에는 직원이 로그인할 때 쓰는 기존 Zero Trust(BeyondCorp) 기반의 서비스 토큰이 그대로 부여되어 있었습니다. 신뢰할 수 있는 내부 네트워크, 기기 인증 통과, 올바른 IAM 권한 토큰까지 모든 검증을 완벽하게 통과한 상태였습니다. 보안 관제팀은 "인증도 완벽하고 기기 상태도 정상인데 왜 알람이 떴느냐"라며 당황해했습니다. 그 순간 뼈저리게 깨달았습니다. 지난 10년 이상 우리가 금과옥조처럼 여겨온 인간 중심의 제로 트러스트 보안 패러다임이 자율적으로 판단하고 작동하는 AI 에이전트 시대에는 완전히 무용지물이 될 수 있다는 사실을 말이죠. 오늘 글을 한 줄로 요약하면 이겁니다. **인간의 속도와 승인 체계에 맞춰진 기존 제로 트러스트를 버리고, 에이전트 권한 자체를 최소화하는 에이전트 액세스 모델(AAM)로 아키텍처를 전면 재편해야 합니다.** --- ### 1. 마스터키와 일회용 발렛 키: 에이전트 보안의 본질적 차이 기존의 구글 BeyondCorp 스타일 제로 트러스트 아키텍처는 오직 '인간'이라는 주체(Principal)를 전제로 설계되었습니다. 인간은 아침에 출근해 단말기로 SSO 로그인을 하고, 커피를 마시며 천천히 클릭을 수행합니다. 시스템은 요청이 올 때마다 "너 누구니?", "어느 기기에서 접속했니?"를 따져보고 접근을 승인합니다. 반면 AI 에이전트는 다릅니다. 에이전트는 인간과 비교할 수 없을 정도로 빠른 속도로 수백 개의 API를 연쇄 호출합니다. 또한 상황에 따라 스스로 새로운 서브 태스크를 생성하며 시스템 깊숙이 침투합니다. 기존 제로 트러스트가 인간에게 8시간짜리 건물 마스터키를 쥐여주는 방식이었다면, 에이전트에게 필요한 것은 '특정 주차 칸에 3분간 차를 댈 수 있는 일회용 발렛 키'입니다. 기존 보안 체계는 에이전트에게 마스터키를 쥐여준 채 "인증된 주체니 괜찮다"라며 조용히 방관하다가 대형 데이터 유출 사고로 이어지게 만듭니다. 이 문제를 해결하기 위해 제시된 기술적 대안이 바로 에이전트 액세스 모델(Agent Access Model, AAM)입니다. AAM은 에이전트의 판단을 일일이 감시하고 판단하는 스마트한 검증 로직에 의존하지 않습니다. 대신 에이전트가 가질 수 있는 권한의 상한선(Capability Ceiling) 자체를 아예 극도로 작게 쪼개어, 에이전트가 사고를 치고 싶어도 칠 수 없는 환경을 만듭니다. 저희 팀은 내부 백엔드 인프라를 AAM 기반으로 개편하면서 다음과 같은 정량적 성과를 거둘 수 있었습니다. * **이상 동작 감지 및 차단 시간(MTTD)**: 기존 45분 → **2초 이내**로 대폭 단축 * **AI 에이전트 과잉 권한 노출률**: 전체 API 대비 87% → **0.5% 미만**으로 축소 * **에이전트 감사 및 트레이싱 오버헤드**: 관제 비용 **전년 대비 40% 절감** --- ### 2. 서비스 토큰 재활용이 불러온 데이터 스캔 잔혹사 AAM으로 바꾸기 전, 저희 팀이 경험했던 아키텍처 전환 과정은 그야말로 시행착오의 연속이었습니다. 당시 저희는 멀티 테넌트 SaaS 환경에서 고객사의 정산 내역을 자동으로 비교·검증하는 에이전틱(Agentic) RAG 파이프라인을 구축하고 있었습니다. 개발 기한이 촘촘하다 보니 빠른 구현을 위해 기존 백엔드 엔지니어들이 사용하던 OAuth2/OIDC JWT 서비스 토큰을 에이전트에게 그대로 할당했습니다. 토큰에 설정된 Scope는 broad한 `read:financial_ledgers`였습니다. 관리자 대시보드가 정상 작동하도록 기존 백엔드 API에 널찍하게 설정되어 있던 권한이었죠. 사고는 에이전트가 정산 데이터에서 일부 비정상적인 널(Null) 값을 발견했을 때 터졌습니다. 에이전트는 널 값을 해석하지 못하자 스스로 '예외 처리 프롬프트'를 생성했고, 재귀적으로 내부 API를 호출하며 연관된 모든 테이블을 조회하기 시작했습니다. 1초에 40번이 넘는 속도로 데이터베이스를 훑고 지나갔지만, 기존 제로 트러스트 게이트웨이는 아무런 제재도 가하지 않았습니다. 에이전트가 제시한 JWT 토큰은 유효했고, 기기 상태 점검도 통과했으며, IP 역시 내부 Kubernetes 클러스터 POD의 IP였기 때문입니다. 결국 데이터베이스 CPU 사용량이 99%까지 치솟았고, 다른 테넌트의 리소스까지 침범하기 직전에야 DBA의 긴급 알람으로 상황을 파악할 수 있었습니다. 보안 도구들이 거창하게 소리치며 막아선 것이 아니라, 너무 많은 권한을 너무 오랫동안 신뢰하여 '조용하게 실패(Fail Quietly)'했던 대표적인 사례였습니다. 이 잔혹사를 겪은 후, 우리는 단순한 IAM 역할 분담만으로는 AI 에이전트의 동적 행동을 제어할 수 없음을 깨달았습니다. --- ### 3. AAM 기반 AI 에이전트 보안 개편 3단계 가이드 시행착오를 거쳐 저희가 구축한 에이전트 액세스 모델의 핵심 3단계 개편 가이드라인을 소개합니다. 백엔드 및 클라우드 아키텍트라면 반드시 점검해야 할 요소들입니다. ### 1. 태스크 단위 실행 그래프 도입으로 영구 권한 폐기 * **태스크 스코프 격리**: 에이전트 서비스 전체에 권한을 주지 않고, 개별 작업 단위(Task-Scoped Run)마다 휘발성 토큰을 발급합니다. * **실행 그래프(Task Execution Graph) 생성**: 에이전트가 수행할 작업의 범위를 비순환 그래프(DAG) 형태로 정의하고, 해당 그래프를 벗어나는 API 호출은 파이프라인 단에서 물리적으로 차단합니다. ### 2. 권한 상한선(Capability Ceiling)의 극대화된 축소 * **판단 로직 이전의 상한선 강제**: LLM이 아무리 똑똑하게 판단하더라도, 백엔드 프록시 레이어에서 에이전트에 허용된 최대 조회 건수(예: 1회 실행당 최대 10건)를 엄격히 제한합니다. * **시한부 자격 증명(Ephemeral Credentials)**: 작업이 끝나면 5초 이내에 자동 파기되는 일회성 mTLS Certificate 또는 Short-lived Token만을 사용합니다. ### 3. 멀티플레이어 승인 및 에이전트 트레이싱 구축 * **인간-에이전트 개입(Human-in-the-Loop)**: 권한 상한선을 초과하는 민감 데이터 접근 시, 에이전트가 직접 수행하지 못하고 지정된 Slack 채널이나 사내 웹훅을 통해 담당자의 승인을 받도록 차단막을 설치합니다. * **에이전트 맥락 관측성**: 단순 HTTP 로그가 아닌, 프롬프트의 맥락(Context)과 에이전트의 이전 행동 이력이 담긴 에이전트 전용 OpenTelemetry 트레이싱 체계를 구축합니다. 최근 발표된 클라우드플레어의 에이전트 보안 아키텍처 연구는 이러한 실무적 고민을 이론적·기술적으로 훌륭하게 정리해 주고 있습니다. * **참고 원문**: [Cloudflare Blog](https://blog.cloudflare.com/the-agent-access-model/) --- ### 결론: 내일 출근해서 당장 시작해야 할 3가지 Action Item AI 에이전트는 단순한 백엔드 배치 프로그램이 아닙니다. 스스로 판단하고 행동하는 새로운 타입의 소프트웨어 주체입니다. 기존 인간용 Zero Trust 도구로 에이전트를 통제할 수 있다는 환상을 깨야 합니다. 내일 출근하시면 다음 3가지를 즉시 실행해 보시길 권합니다. 1. 사내에서 작동 중인 AI 에이전트 서비스 계정에 넓은 범위의 OAuth/IAM 토큰이 할당되어 있는지 전수 조사하세요. 2. 에이전트가 내부 API를 호출할 때 1회당 가져올 수 있는 데이터의 최대 상한선(Capability Ceiling)을 API 게이트웨이에 설정하세요. 3. 아래 제공해 드리는 점검 체크리스트와 AI 프롬프트 템플릿을 팀 내 아키텍처 리뷰 미팅에 공유하세요. 아래는 내일 출근해서 당장 복사해 쓸 수 있는 '에이전트 보안 점검 체크리스트'와 'AAM 적용 프롬프트 템플릿'입니다. ```markdown # 1. AI 에이전트 보안 아키텍처 점검 체크리스트 (AAM 기준) [ ] 1. 에이전트 서비스 계정이 인간용 SSO/IAM 토큰을 재활용하고 있지 않은가? [ ] 2. 단일 태스크(Task) 종료 시 할당된 보안 토큰이 즉시 파기(Short-lived)되는가? [ ] 3. 에이전트의 API 호출 시 1회당 최대 응답 개수(Capability Ceiling)가 백엔드 단에서 제한되어 있는가? [ ] 4. 에이전트가 예외 발생 시 재귀적으로 데이터를 훑는 것을 방지하는 Circuit Breaker가 존재하는가? [ ] 5. 민감 데이터 변경/대량 조회 시 인간의 승인을 거치는 Human-in-the-loop 절차가 강제되어 있는가? [ ] 6. 에이전트의 프롬프트 맥락과 API 연쇄 호출 과정이 OpenTelemetry 트레이싱으로 기록되는가? --- # 2. Agent Access Model (AAM) 준수를 위한 AI 에이전트 시스템 프롬프트 템플릿 [역할 정의] 당신은 사내 정산 내역을 검증하는 전용 에이전트입니다. 부여된 권한 범위를 엄격히 준수하며 비동기 태스크를 수행합니다. [행동 수칙 및 권한 제약] 1. 당신에게 허용된 데이터 접근 권한 상한선(Capability Ceiling)은 단일 실행당 최대 10건의 정산 데이터 조회로 제한됩니다. 2. 만약 10건 이상의 데이터 조회가 필요하거나 비정상 데이터(Null, Mismatch) 발견 시, 직접 재조회를 시도하지 말고 사유를 정리하여 즉시 실행을 중단(HALT)하십시오. 3. 임의로 서비스 API 호출 파라미터를 변경하거나 다른 테넌트의 엔드포인트를 호출하는 행위는 엄격히 금지됩니다. 4. 작업 완료 즉시 현재 세션 맥락을 즉시 소멸시키고 결과 리포트만을 반환하십시오. [요청 사항] 다음 입력된 정산 ID 목록에 대해 검증을 수행하되, 위 제약 조건 범위 내에서만 작업을 처리하고 결과를 JSON 형태로 반환해 주세요. ```

최신 IT & Mind 리포트 더보기

오늘의 IT, Mind & Career Insights

최신 글로벌 IT 기술, 인공지능 시대의 행동 심리학, 그리고 엔지니어의 지속 가능한 커리어 성장을 위한 리포트

최신 추천 인사이트

전체 리포트 피드