안녕하세요!
이번 글에서는 AWS Summit 2026에서 발표된 「규제 환경에서의 통제 가능한 AI 에이전트 아키턱처」세션 내용을 정리해보겠습니다.
생성형 AI는 이제 단순히 질문에 답변하는 수준을 넘어, 스스로 계획을 세우고 도구를 호출하며 업무를 수행하는 AI 에이전트 형태로 발전하고 있습니다.
하지만 공공, 금융, 의료, 헬스케어와 같이 규제와 보안 요구 사항이 높은 환경에서는 AI 도입 시 반드시 고민해야할 부분이 있습니다.
“AI가 어떤 데이터에 접근할 수 있는지, 어떤 행동을 수행할 수 있는지, 문제가 발생했을 때 그 책임을 어떻게 설명할 수 있는지”입니다.
이번 세션의 핵심 메시지는 다음과 같습니다.
규제는 AI 도입을 막는 정책이 아니라, 안전한 AI 에이전트를 만들기 위한 설계 요구사항입니다.
1. AI 에이전트는 왜 거버넌스가 필요한가?
에이전트 거버넌스의 출발은 AI 어시스턴트와 AI 에이전트의 본질적인 차이를 이해하는 것에서 시작합니다.
- AI 어시스턴트: 사람이 짜놓은 흐름 안에서 질문에 답변하거나 지시에 따라 단일 작업을 수행.
- AI 에이전트: 목표가 주어지면 스스로 계획을 세우고, 필요한 도구를 선택하여 여러 단계의 작업을 자율적으로 수행.
즉, AI가 단순히 ‘답변하는 존재’에서 ‘스스로 행동하는 존재’로 패러다임이 바뀌는 것입니다. 이 자율성은 생산성을 극대화하는 원천이지만 동시에 심각한 거버넌스 리스크를 동반합니다.
예를 들어 대학병원에서 진료보조 AI 에이전트를 도입했는데, 이 에이전트가 환자의 알레르기 이력을 누락한 채 특정 약물을 추천하여 부작용이 발생했다면 어떨까요?
이 판단은 누구의 결정이고, 책임은 누구에게 있을까요?
그래서 AI 에이전트를 설계할 때는 처음부터 다음과 같은 기준이 필요합니다.
- 어떤 데이터에 접근할 수 있는가
- 어떤 도구와 API를 사용할 수 있는가
- 어떤 행동은 허용하고 차단할 것인가
- 언제 사람이 개입해야 하는가
- 실행 과정과 결과를 어떻게 추적할 것인가
2. 규제는 아키텍처 설계에 반영되어야 한다.
세션에서는 대부분의 AI 규제가 결국 네 가지 질문으로 정리된다고 설명했습니다.
- 누가 책임질 것인가
- 개인정보를 어떻게 보호할 것인가
- 기술적으로 어떻게 통제할 것인가
- 리스크를 어떻게 지속적으로 관리할 것인가
이 네 가지는 단순한 체크리스트가 아닙니다. AI 에이전트 아키텍처에 반영되어야 하는 설계 요구사항입니다.
특히 규제는 계속 변화합니다. 모델, 지식 베이스, 프레임워크도 함께 바뀌기 때문에 처음 구축할 때 뿐만 아니라 운영 중에도 계속 검증할 수 있는 구조가 필요합니다.
세션에서는 복잡한 규제를 하나씩 대응하기보다, 레이어드 컴플라이언스 관점으로 접근하는 방법을 제시했습니다.
애플리케이션 위에 개인정보보호법, AI 기본법, 산업별 규제와 같은 규제 계층을 두고, 그 위에 Responsible AI, ISO 42001, NIST AI RMF, OWASP Top 10 for LLM Applications, AWS Well-Architected Framework와 같은 기준을 계층적으로 반영하는 방식입니다.
이렇게 설계하면 규제가 변경되더라도 전체 시스템을 다시 만드는 것이 아니라, 변경된 계층을 중심으로 대응할 수 있습니다.
3. 통제 가능한 AI 에이전트 아키텍처
세션에서는 규제 환경의 AI 에이전트 아키텍처를 크게 세 가지 관점으로 설명했습니다.
첫 번째는 어떻게 만들 것인가입니다.
AI 에이전트를 어떤 플랫폼과 프레임워크로 구축하고 실행할지에 대한 영역입니다.
두 번째는 어떻게 통제할 것인가입니다.
모델의 입출력과 에이전트의 행동을 어떻게 제어할지에 대한 영역입니다.
세 번째는 어떻게 유지할 것인가입니다.
배포 이후에도 품질, 보안, 컴플라이언스 기준을 지속적으로 검증하는 영역입니다.
어떻게 만들 것인가 (에이전트 구축과 배포)
AWS 환경에서 AI 에이전트를 안전하게 구동하는 방법은 크게 두 가지가 있습니다. 조직의 규제 수준과 운영 여력에 맞춰 선택할 수 있습니다.
| 구분 | ① Amazon Bedrock AgentCore (완전 관리형) | ② Amazon EKS 기반 (셀프 매니지드) |
| 한줄 요약 | AWS가 인프라와 보안을 알아서 관리해 주는 방식 | 인프라와 컨테이너를 직접 통제하는 방식 |
| 핵심 장점 | • 세션 격리(Runtime): microVM으로 데이터 유출 차단 • 내장 인증(Identity): 시스템 접근 추적성 확보 • 코드 최소화: Strands Agents 연동으로 빠른 개발 | • 세밀한 커스텀: OS 및 커널 레벨까지 직접 통제 • 인프라 제어: 조직 내 고유한 폐쇄망 요건 충족 |
| 추천 대상 | 인프라 운영 부담을 줄이고 보안 표준을 빠르게 충족하고 싶은 조직 | 인프라 환경 자체를 완벽하게 직접 통제해야 하는 초고도 규제 환경 |
어떻게 통제할 것인가 (모델과 에이전트의 2중 구조 제어)
안전한 통제를 위해서는 성격이 다른 리스크에 맞춰 통제 영역을 분리해야 합니다. 모델의 ‘말(입출력)’과 에이전트의 ‘행동’을 나누어 제어하는 구조입니다.
① 모델 층 제어: Amazon Bedrock Guardrails
- 역할: 모델이 “무엇을 말하는가(입출력)”을 필터링합니다.
- 통제 항목: 환각 현상, 욕설/비속어, 민감정보(주민번호 등) 마스킹, 근거 없는 답변 차단
Cross Account Safeguard 를 통해 보안팀이 마스터 계정에서 규칙을 딱 한번만 정의하면, 사내 수백 개의 서비스 계정에 일괄 적용됩니다.
② 에이전트 층 제어: AgentCore Policy
- 역할: 에이전트가 “어떤 행동을 하는가(도구/API호출)”을 제어합니다.
- 통제 항목: 에이전트가 권한이 없는 시스템을 호출하거나 비즈니스 규칙을 어기지 못하도록 차단합니다.
중요한 점은 LLM의 판단에만 의존하지 않고 에이전트가 특정 행동을 수행하려고 하더라도 정책 조건을 만족하지 않으면 실행을 차단할 수 있어야 하기 때문에 필요합니다.
어떻게 유지할 것인가
AI 에이전트는 배포 후에도 계속 검증되어야 합니다.
모델이 업데이트되고 지식 베이스가 변하며, 규제 기준도 변화하기 때문입니다. 따라서 처음에는 기준을 충족했던 에이전트가 운영 중에도 계속 안전한가?를 확인할 수 있어야합니다.
① 거버넌스 작동 검증: AgentCore Evaluations
- 최종 답변만 보는 것이 아니라, 답을 도출하기까지의 ‘도구 실행 순서(시퀀스)’가 절차적 규제에 맞는지 실시간으로 채점합니다.
② 공격 방어 검증: AWS Security Agent
- 2026년 3월에 출시된 프론티어 AI 에이전트로, 철저히 ‘공격자의 시선’에서 시스템을 모의 해킹합니다.
- 프롬프트 인젝션 우회, 권한 이탈 시도 등을 자동으로 테스트하여 기존에 수 주일씩 걸리던 보안 재 검증을 수 시간 내로 단축시켜 줍니다.
4. 리뷰를 마치며
이번 세션 전체를 관통하는 핵심 메시지는 다음과 같습니다.
이제는 단순히 ‘더 똑똑하고 강력한 기능’을 가진 AI 에이전트를 만드는 경쟁을 넘어, ‘설명할 수 있고 책임질 수 있는(Responsible) AI 에이전트‘를 구현하는 조직만이 시장의 신뢰를 얻고 생성형 AI의 진정한 생산성 혁신을 누릴 수 있습니다.
NDS는 고객사의 비즈니스 로직과 산업별 규제 요건에 딱 맞춘 안전한 AI 아키텍처 설계를 지원합니다.
규제 환경 속 통제 가능한 AI 도입을 고민중이시라면 언제든 NDS Sales팀으로 연락주시길 바랍니다.
Reference: AWS Summit Seoul 2026, AWS Session by 최인영
SA 강채윤