클라우드 보안 팀의 하루는 이렇게 흘러갑니다.

CNAPP·스캐너가 수천 건의 경고를 쏟아냄
→ 조사: 이 리소스 주인이 누구지? 뭐가 의존하지?
→ 확인: 이걸 고치면 프로덕션이 안 깨질까?
→ 우선순위: 다급한 것부터... 그런데 기준이 없음
→ 결국 중요한 노출이 몇 달째 그대로 쌓임

탐지는 이미 충분합니다. Wiz, CrowdStrike, Palo Alto Cortex, Upwind, SentinelOne, Orca, Cyera 같은 CNAPP도, AWS Security Hub와 GuardDuty도 열심히 일하고 있습니다. 문제는 탐지와 수정 사이의 간격입니다.

10월 14일 AWS가 공개한 글은 이 간격을 에이전트로 좁히는 Tamnoon의 사례를 다룹니다. Tami라는 클라우드 수정(remediation) 오케스트레이터가 Amazon Bedrock 위에서 어떻게 프로덕션을 안전하게 고치는지, 그 구조가 흥미롭습니다.

4개 에이전트의 역할 분담

Tami는 수정 파이프라인을 네 단계로 나누고, 각 단계를 전담 에이전트에 맡깁니다.

① Investigation (조사)
   자산·노출 맥락을 수집하고, '읽기 전용' 조사 단계와 조사 계획을 만듦
   → LLM-as-a-judge 검증 레이어를 통과해야 다음으로 감

② Safety scoring (안전 점수)
   자산별 증거 체인을 만들고 SAFE / RISKY / AWAITING DATA로 분류
   → 의심스러우면 낮은 등급으로 내리는 보수적 편향

③ Remediation (수정 계획)
   SAFE 판정을 받은 건만 진행. 순서·의존성·조건을 따져
   모든 단계를 '백업 → 수정 → 검증' 구조로 만들고 롤백 안내를 포함

④ Code generation (실행 생성)
   계획을 실행 가능한 코드로 변환. 단, 입력 가드레일이 먼저
   관련성과 프롬프트 인젝션을 검사한 뒤, 별도 reviewer 에이전트의
   승인을 통과한 산출물만 나감

핵심 아이디어는 수정 전에 "이걸 해도 되는가"를 별도로 심사한다는 것입니다. 조사와 수정 사이에 안전 점수라는 게이트가 있고, 이 게이트는 애매하면 통과가 아니라 보류(AWAITING DATA)를 줍니다. 사람 검토가 필요한 건들이 자동으로 걸러지는 구조입니다.

안전은 기능이 아니라 구조입니다

이 사례에서 배울 게 가장 많은 부분입니다. "제로 프로덕션 이슈"를 주장하는 근거를 뜯어보면, 화려한 모델이 아니라 차곡차곡 쌓은 경계가 보입니다.

이중 방어 설계 (defense in depth)
  ① 독립 안전 평가 — 수정안을 쓰기 전에 별도 평가가 먼저 "안전한가"를 판정
  ② 읽기/쓰기 경계 — 조사 단계는 엄격히 읽기 전용으로 검증.
                     문제를 "이해하는" 작업이 문제를 "바꾸지" 못 함
  ③ 백업·검증·롤백 — 모든 변경에 자기 복구 절차가 따라붙음
  ④ 자기 비판 루프 — 생성 단계마다 reflection이 결과를 검토하고 재생성에 피드백
  ⑤ 자격증명 분리 — AI는 클라우드 자격증명을 직접 들지 않음.
                     실행은 단기·테넌트 한정 자격증명으로 브로커링되고,
                     계획 에이전트와 격리된 환경에서 수행
  ⑥ 사람 거버넌스 — 승인 워크플로 + 전체 감사 추적(audit trail)

세부도 단단합니다.

- Amazon Bedrock Guardrails가 모든 요청·응답에 적용:
  PII·비밀값 마스킹, 프롬프트 인젝션 방어, 금지 주제·콘텐츠 필터
  → 신뢰할 수 없는 경고 데이터를 다루는 구조에서 특히 중요
- 최소 권한: 서비스별 실행 역할. Bedrock 권한은 bedrock:InvokeModel 하나,
  특정 추론 프로파일·모델 ARN으로 한정 (모델 관리·학습·추출 불가)
- 모델 버전 고정: 예: claude-sonnet-4-5-20250929 같은 날짜형 ID로 명시.
  모델 교체 = 리뷰 거친 코드 변경
- 결정성: temperature 0으로 점수·계획의 일관성 유지
- 실패 격리: 입력 큐 redrive, 에러 핸들러, DLQ, 타임아웃·DLQ 알람 온콜 연결

클라우드 보안 회사의 인프라답게 "AI를 쓰는 방식"이 곧 보안 제품의 일부입니다.

결과: 90일, 노출 90% 감소 — 단, 읽는 법이 있습니다

AWS가 인용한 Tamnoon의 결과 표는 이렇습니다.

중요 클라우드 노출   : 90일 내 최대 90% 감소 (Tamnoon 발표 기준)
수정 효율           : 근본 원인 클러스터링으로 최대 100배
프로덕션 이슈        : 수백만 워크로드에서 0건
엔지니어 시간        : 고객 전체 주당 13,000시간 이상 절감
분석된 경고         : 누적 1,400만 건 (2026 State of Cloud Remediation)

숫자와 함께 단서도 정확히 붙여야 합니다. 이 수치는 Tamnoon이 자사 고객 환경에서 측정해 발표한 값으로, 독립적인 벤치마크가 아닙니다. "보편적으로 90% 줄어든다"가 아니라 "이 접근이 잘 운영되면 이 정도가 가능하다"는 사례로 읽는 게 맞습니다.

그래도 방향은 분명합니다. 경고를 하나씩 처리하는 대신 공통 근본 원인으로 묶고(당연히 수정 하나가 여러 경고를 닫음), 판단이 확실한 것만 자동 실행하는 구조. 이 두 가지가 100배 효율과 0건의 프로덕션 이슈를 동시에 가능하게 한 설계입니다.

에이전트를 프로덕션에 들이는 진짜 병목

이 글이 남기는 질문은 하나입니다.

"우리 에이전트가 이 작업을 할 수 있는가?"       ← 능력의 문제
"우리 에이전트가 이 작업을 해도 되는가?"        ← 경계의 문제

대부분의 팀이 첫 번째 질문에 집중하지만, 실제로 배포를 막는 건 두 번째입니다. Tami의 아키텍처가 보여주는 답은 명확합니다.

- 행동 전에 "안전한가"를 묻는 별도 단계를 둔다 (자기 평가가 아니라 독립 평가)
- 읽기와 쓰기를 분리한다 (읽는 에이전트는 절대 바꾸지 못한다)
- 자격증명은 에이전트가 아니라 실행 브로커가 쥔다 (단기·범위 한정)
- 모든 변경에 롤백이 있고, 모든 판단에 감사 기록이 남는다

에이전트 부작용 평가 글에서 다룬 "도와주려다 유출했다" 유형의 사고도, 테스트 샌드박스 글의 "가짜 환경에서 먼저 시키기"도 같은 문제의 다른 얼굴입니다. Tami는 그 원칙을 실제 제품 규모에서 구현한 사례입니다.

CodeBridge Mini Lab: 우리 팀 에이전트 경계 점검

프로덕션 시스템을 건드리는 에이전트를 운영한다면, 다음을 확인해 보세요.

[ ] 읽기 권한과 쓰기 권한이 분리되어 있는가
[ ] 위험한 작업에 승인 게이트(사람 또는 별도 평가)가 있는가
[ ] 실행에 백업·검증·롤백이 함께 다니는가
[ ] 자격증명이 단기·범위 한정으로 발급되는가 (에이전트가 영구 키를 들지 않는가)
[ ] 모든 실행에 감사 추적이 남는가
[ ] 판단이 애매할 때 '자동 실행'이 아니라 '보류'로 기우는가

마지막 항목이 특히 중요합니다. 자동화의 안전은 "맞게 판단할 확률"이 아니라 틀렸을 때 무슨 일이 일어나는가로 결정됩니다. 애매하면 멈추는 시스템은 틀려도 크게 틀리지 않습니다.

결론: 마지막 한 걸음은 능력이 아니라 신뢰다

한 문장으로 정리하면 이렇습니다.

에이전트를 프로덕션에 들이는 병목은
"할 수 있나"가 아니라 "해도 되나"를 증명하는 일이다.

Tami의 교훈은 모델 선택이나 프롬프트 기법이 아닙니다. 독립 평가, 읽기/쓰기 분리, 롤백, 단기 자격증명, 사람 승인 — 지루한 경계들의 합이 "0건의 프로덕션 이슈"를 만듭니다. 에이전트 한 단계를 자동화할 계획이라면, 기능 목록보다 먼저 이 경계 목록을 체크리스트로 만들어 보세요. 그게 배포를 가능하게 하는 순서입니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

"자동 실행할 것인가, 사람에게 넘길 것인가"를 위험도에 따라 나누는 감각은 이 글의 SAFE/RISKY/AWAITING DATA 게이트와 정확히 같은 문제의식입니다. 판단 모델과 Human-in-the-Loop 구조를 직접 설계하며 익혀보세요.