— “단순 챗봇”을 넘어 “업무 실행자”가 되는 순간, 아키텍처의 성격이 바뀐다
요즘 많은 조직이 “사내 지식 챗봇(RAG)”을 넘어, 실제 업무를 수행하는 **AI 에이전트(Agent)**를 고민합니다.
예를 들면 이런 것들입니다.
- “지난주 비용 급증 원인 분석하고, 최적화 PR까지 올려줘”
- “장애 티켓 열고, 원인 추정해서 관련 런북 실행해줘”
- “계정 권한 요청 들어온 거 검토하고 승인/반려 초안 작성해줘”
- “고객 문의 메일을 분류하고, 결제 이슈면 환불 프로세스를 진행해줘”
이런 에이전트는 민감한 데이터에 접근하고, 중요 시스템에 명령을 내릴 수 있는 손을 갖게 됩니다.
여기서 보안은 “옵션”이 아니라, 에이전트가 업무를 하게 해주는 면허 체계가 됩니다.
이 글은 그 면허 체계를 AWS에서 구현하는 “심층 아키텍처”를 한 번 끝까지 설계해보는 내용입니다. 핵심 키워드는 딱 두 가지입니다.
- Zero Trust: 내부라고 믿지 않는다. 매 요청마다 증명하고 최소 권한으로 처리한다.
- Human-in-the-Loop (HITL): 위험한 행동은 사람 승인 없이는 절대 실행되지 않는다.
전체 아키텍처 : “특수 화물 운송 차량 대열” 아키텍처
기본적인 RAG 챗봇이 “교통 법규 지키는 운전자”라면,
고도화된 에이전트는 특수 화물을 실은 차량이고, 무장 경호와 검문소, 그리고 비상 정지 장치가 같이 붙습니다.
이 아키텍처의 목표는 세 가지입니다.
- 네트워크 수준에서 데이터 유출 경로를 닫는다 (Private Isolation)
- 데이터 접근을 사용자 권한으로 강제한다 (RAG ACL)
- 치명 행동은 사람 승인 후에만 실행한다 (HITL)
1) 완전 격리된 도로: Private Subnet + VPC Endpoints로 “인터넷 없는 에이전트” 만들기
에이전트가 다루는 데이터가 민감해질수록, “어딘가로 새어 나갈 수 있는 경로” 자체를 줄여야 합니다.
여기서 가장 강력한 방법이 인터넷이 없는 Private Network 구성 입니다.
1-1. 컴퓨팅은 Private Subnet에만 둔다
- Lambda(가능하면 VPC 연결) 또는 ECS/Fargate/EKS Worker를 Private Subnet에 배치
- NAT Gateway를 빼서 아웃바운드 인터넷을 원천 차단(조직 정책에 따라 선택)
이렇게 하면 “외부로 뭔가 빼돌리기”가 구조적으로 어려워집니다.
단, “AWS 서비스 호출”은 여전히 필요하니 여기서 다음 스텝이 중요합니다.
1-2. AWS 서비스 호출은 PrivateLink(VPC Endpoint)로만
S3, Bedrock, DynamoDB, STS, CloudWatch Logs 같은 호출이 인터넷을 타면 의미가 반감됩니다. 그래서:
- Interface Endpoint: Bedrock, STS, CloudWatch Logs 등
- Gateway Endpoint: S3, DynamoDB
즉, AWS 내부망으로만 통신하게 만드는 겁니다.
참고(공식): VPC 엔드포인트/PrivateLink 개요
https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html
1-3. “허용된 서비스만” 통신하도록 엔드포인트 정책까지 조인다
많이들 Endpoint를 만들고 끝내는데, 고도화 단계에서는:
- 엔드포인트 정책으로 S3 버킷/프리픽스 단위 제한
- Bedrock 호출도 허용 모델만
- STS도 특정 AssumeRole만
까지 가면 “네트워크 + 정책”으로 이중 잠금이 됩니다.
2) 화물 검문소: PII Redaction Pipeline (입력/출력 이중 필터)
에이전트가 LLM에 데이터를 보내기 전(입력), 그리고 LLM이 결과를 사용자에게 내보내기 전(출력)에
두 번 검문하는 게 안전합니다.
2-1. Ingress Filter: 입력(문서/프롬프트)에서 PII 탐지/마스킹
- 사용자가 업로드한 문서, 혹은 프롬프트에 주민번호/카드번호/계좌번호 등이 포함될 수 있습니다.
- 이걸 그대로 모델에 넣는 순간, 통제 범위가 급격히 넓어집니다.
대표 접근:
- Amazon Macie: S3에 저장된 데이터에서 민감정보를 자동 분류/탐지
https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html - Amazon Comprehend(PII Entities): 텍스트에서 PII 엔티티 탐지
https://docs.aws.amazon.com/comprehend/latest/dg/how-pii.html
운영 설계 팁:
- 문서 업로드 → S3 저장 → 이벤트로 스캔 파이프라인 트리거(비동기)
- “검증 완료된 문서만” Knowledge Base/인덱스로 반영
- 마스킹한 원문/마스킹본을 분리 보관(접근 통제 차등 적용)
2-2. Egress Filter: 출력에서 “기밀 유출/키 노출” 방지
모델이 실수로:
- Access Key처럼 보이는 패턴
- 내부 URL / 토큰 / 민감 키워드
- 정책상 금지된 정보
를 내뱉을 수 있습니다.
실무에서 많이 쓰는 조합:
- 정규표현식 기반 필터(예: AKIA 패턴, JWT 패턴, 카드 BIN 패턴)
- 금칙어/기밀 토큰 사전
- 고위험 출력은 “부분 블라인드 + 경고 + HITL로 에스컬레이션”
추가로, Bedrock를 쓰면 Guardrails를 함께 고려할 수 있습니다.
https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html
3) 신원 기반 네비게이션: RAG 권한 제어(ACL)가 “진짜 핵심”
고도화된 에이전트에서 가장 위험한 사고 유형은 이거예요:
“에이전트는 접근 가능한데, 사용자는 보면 안 되는 문서를 근거로 답했다.”
즉, 에이전트의 서비스 권한과 사용자 권한을 분리하지 않으면, 에이전트가 “권한 증폭기”가 됩니다.
3-1. Identity Propagation: 사용자 신원을 끝까지 전파한다
- 사용자가 로그인 → JWT/OIDC 토큰 발급 (Identity Center 또는 외부 IdP)
- 요청이 API Gateway/Lambda로 들어오면 토큰에서:
- user_id
- groups/roles
- tenant
- data scope
를 추출해서 컨텍스트로 유지
중요 포인트:
- “LLM 호출”까지 이어지는 모든 단계가 이 user context를 들고 있어야 합니다.
- 그래야 Retrieval 단계에서 ACL 필터가 제대로 걸립니다.
3-2. Retrieval 단계에서 ACL을 “필터”로 강제한다
RAG에서 ACL은 “생성 후 필터링”이 아니라, 검색할 때부터 적용돼야 합니다.
예시(개념):
- 문서 메타데이터에
allowed_groups: ["finance", "exec"] - 검색 쿼리에
allowed_groups IN user.groups필터를 포함
Knowledge Bases for Amazon Bedrock를 쓰는 경우에도, “문서 메타데이터/접근 제어 전략”을 어떻게 구성할지가 품질과 보안을 좌우합니다.
https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html
3-3. “근거 링크”에도 동일한 ACL을 적용한다
많이들 답변에 출처 링크를 붙이는데, 여기서도:
- 링크를 눌렀을 때 원문 접근이 가능한지
- 프리사인 URL을 발급하는지/어떤 TTL인지
- 로그에 남는 정보는 무엇인지
를 통제해야 합니다.
정리하면: RAG는 Retrieval과 Source Serving까지가 하나의 보안 경계입니다.
4) 비상 정지 버튼: Human-in-the-Loop를 Step Functions로 “프로세스화” 하기
에이전트가 “조회”를 넘어 “행동(Action)”을 하려는 순간이 고비입니다.
- 송금
- 데이터 삭제/변경
- 대량 이메일 발송
- IAM 권한 변경
- 운영 환경 배포/롤백
이런 작업은 사람이 승인하지 않으면 실행되면 안 됩니다.
그래서 에이전트의 흐름을 워크플로우로 강제하는 게 좋고, AWS에서는 Step Functions가 이 역할에 매우 잘 맞습니다.
Step Functions 개요: https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html
4-1. 왜 Step Functions인가?
- 에이전트는 “대화형”이라 상태가 길게 이어지고, 중간에 멈추고, 재개되고, 분기합니다.
- 승인 대기(HITL)는 본질적으로 Pause/Resume 문제입니다.
- Step Functions는 상태 머신으로 이걸 명확히 모델링할 수 있어요.
4-2. 워크플로우 설계 패턴(추천)
- Input Sanitize (PII/금칙어 필터)
- Retrieve with ACL
- Generate Draft (LLM이 “행동 초안” 생성)
- Risk Classifier (행동 위험도 분류: low/medium/high)
- Decision Gate
- low: 자동 실행 가능
- medium: 추가 확인 질문
- high: 무조건 HITL
- Approval Wait
- Execute Action
- Audit Log Write (근거/승인자/실행 결과)
4-3. 승인 UX: Slack/Email/SNS 어디가 좋나?
운영에서 중요한 건 “승인 요청이 묻히지 않는 것”입니다.
- Slack: 빠르고 좋지만, 채널 노이즈가 크면 묻힘
- Email: 기록은 좋은데, 즉시성이 떨어질 수 있음
- 사내 포털(승인 페이지): 가장 정석. 이력/검색/권한이 깔끔
실무적으로는:
- SNS로 알림 + 승인 포털 링크
- 포털에서 “근거/리스크/영향 범위”를 한 화면에 보여주고 승인
이 조합이 가장 안정적입니다.
5) Guardrails와 “툴 실행 안전장치”: 에이전트가 시스템을 건드리기 전 마지막 문
에이전트가 실제 시스템을 건드릴 때는 대개 Tool 호출(함수 호출/API 호출) 형태가 됩니다.
여기서 “툴 인터페이스”를 잘 설계하면 사고 확률이 확 떨어집니다.
5-1. 툴은 “의도가 아니라 파라미터”에서 사고가 난다
예: “테이블 삭제” 툴이 있다면,
- 어느 계정?
- 어느 리전?
- 어느 테이블?
- 삭제 전 스냅샷 여부?
- 영향 범위(다운스트림 서비스)?
같은 것들이 파라미터로 명시되어야 합니다.
추천 원칙:
- 파라미터를 가능한 한 구체적으로
- 디폴트는 안전한 방향(드라이런/미리보기)
- 실행 전 **체크리스트(가드 조건)**를 코드로 강제
5-2. Dry-run / Plan-first 정책
고위험 작업은:
- 1차: 에이전트가 Plan(계획)만 작성
- 2차: 사람이 승인
- 3차: 실제 실행
이 3단 분리만 해도 “LLM 환각”이 실제 피해로 이어질 확률이 크게 줄어요.
6) 관측과 감사: “누가, 무엇을 근거로, 어떤 승인을 거쳐, 어떤 행동을 했는가?”
고도화된 에이전트는 감사 가능성이 기능 요구사항입니다.
최소한 아래를 남겨야 합니다.
- 요청 ID / 사용자 ID / 그룹
- 검색에 사용된 문서 ID/버전/해시
- 모델 ID, 프롬프트 템플릿 버전
- 위험도 분류 결과
- 승인자/승인 시각/승인 코멘트
- 실행된 API(액션)와 결과(성공/실패, 리소스 ARN)
AWS 관점에서는:
- CloudTrail(권한/리소스 접근 흔적)
- CloudWatch Logs(애플리케이션 로깅)
- X-Ray(분산 추적)
- S3/Object Lock(감사 로그 불변성)
같은 도구로 “변조 어렵고, 조회 쉬운” 형태로 엮는 게 좋아요.
7) 마무리: 신뢰 가능한 에이전트는 “기술 스택”이 아니라 “통제 가능한 프로세스”다
이 아키텍처가 복잡해 보이는 이유는, 사실 기능이 많아서가 아니라 실패했을 때의 피해가 크기 때문입니다.
기업 에이전트는 결국 “권한”과 “행동”을 다루는 시스템이고, 그 순간부터 AI는 제품이 아니라 운영 체계가 됩니다.
정리하면:
- Private Isolation로 네트워크 유출 경로를 닫고
- RAG ACL로 “사용자 권한”을 검색 단계부터 강제하고
- HITL로 치명 행동은 사람 승인 없이는 절대 실행되지 않게 만들고
- 관측/감사로 “무슨 일이 왜 일어났는지”를 나중에 재현 가능하게 만들어야 합니다.
이 네 가지가 결합될 때, 에이전트는 ‘운전면허 소지자’가 아니라 특수 훈련된 보안 요원에 가까워집니다.