[reinvent 2025] AWS Security Agent: 설계부터 배포까지 사전 예방적 AppSec
Summary
AWS Security Agent는 AI 기반 자동화를 통해 애플리케이션 보안을 사후 대응에서 사전 예방으로 전환하는 솔루션입니다. 설계 단계부터 배포까지 개발 라이프사이클 전반에 걸쳐 보안 요구사항을 자동으로 검토하고 검증하여, 개발 속도를 유지하면서도 보안 커버리지를 확장할 수 있습니다.
리인벤트 2025 테크 블로그의 더 많은 글이 보고 싶다면?
Overview
들어가며
이번 re:Invent 2025에서 가장 인상 깊었던 세션 중 하나는 AWS Security Agent에 관한 것이었습니다. Neha Goswami와 Neha Rungta 두 분의 발표로 진행된 이 세션에서는 애플리케이션 보안 팀이 직면한 근본적인 문제를 다루었습니다. 증가하는 애플리케이션 포트폴리오 전반에 보안 전문성을 확장하면서도 개발 속도를 유지해야 하는 과제입니다. 전통적인 접근 방식은 조직이 속도와 보안 중 하나를 선택하도록 강요해왔습니다.
현재 버지니아 북부 리전에서만 제공되는 이 신규 서비스는 AI 기반 자동화를 통해 애플리케이션 보안을 사후 대응에서 사전 예방으로 전환합니다. 조직의 요구사항에 맞춤화된 자동 보안 검토를 수행하고, 온디맨드 침투 테스트를 제공하여 개발 생명주기 초기에 취약점을 예방하는 방법을 소개했습니다.
Proactive Security
세션은 매우 인상적인 비유로 시작되었습니다. 발표자는 전기가 발명되기 전 밤의 조명이 사치품이었던 시대를 예로 들었습니다. 빛은 비싸고 귀했기 때문에 신중하게 배분되어야 했고, 부유한 사람들만이 제한적으로 사용할 수 있었습니다. 그러나 전기가 발명되면서 모든 것이 바뀌었습니다. 오늘날 빛은 어디에나 존재하는 상품이 되었습니다.
발표자에 따르면 최근까지도 Proactive Security는 여전히 “촛불 시대”에 머물러 있었습니다. 배분되고, 제한적으로 사용되며, 아껴 써야 했습니다. 하지만 대규모 언어 모델의 발명이 이를 근본적으로 변화시켰다고 강조했습니다. 이제 Proactive Security는 “전기 시대”입니다.
세션에서 제시한 대량 생산되는 Proactive Security의 세계는 매우 흥미로웠습니다. 보안 설계 검토가 저렴하고 ㄴ빠를 때 언제 어디서나 수행할 수 있고, 모든 풀 리퀘스트에서 보안 코드 검토가 자동으로 이루어지며, 침투 테스트가 정해진 스케줄이 아닌 온디맨드 방식으로 제공됩니다. 이것이 바로 AWS Security Agent가 지향하는 비전입니다.
Security Requirements
세션에서는 보안 요구사항이 Proactive Security의 기초라고 설명하며, 크게 두 가지 유형으로 나누었습니다.
1. 산업별 모범 사례(Industry Best Practices)
첫 번째는 업계 모범 사례입니다. 이는 모든 사람이 따라야 하는 것들로, 소프트웨어 개발자의 집단적 지식에서 나온 것입니다. 시간이 지남에 따라 천천히 진화합니다.
대표적인 예로 “Secure by Default”가 있습니다. 시스템의 기본 구성이 안전하도록 보장하는 것입니다. 안전한 기본값을 벗어나려면 추가 작업과 추가 단계가 필요하도록 만듭니다. 전통적으로 이는 지향해야 할 설계 목표였지만, 시스템 적으로 강제하기는 어려웠습니다. 설계 단계에서부터 시스템이 기본적으로 안전한지 일일이 검증하기가 현실적으로 쉽기 않았기 때문입니다. 결국 개발자의 지식과 최선의 의도에 의존해야 했습니다.
Security Agent에서는 이러한 모범 사례를 AWS 관리형 보안 요구사항으로 코드화합니다. 약 10개의 관리형 보안 요구사항이 포함되어 있으며, 콘솔에서 직접 확인할 수 있습니다. 각 요구사항에는 이름과 설명 외에도 적용 가능성과 준수 기준이 포함됩니다.
2. 회사별 특정 요구사항(Company Requirements)
두 번째 유형은 회사별 요구사항입니다. 업계 도메인, 운영 국가, 회사 정책에 따라 달라집니다. 조직마다 애플리케이션 액세스 권한 부여 방식, 민감한 리소스에 대한 다자 승인, 특정 암호화 요구사항, 감사 로깅 규칙 등 다른 요구사항이 있을 수 있습니다.
세션에서는 포스트 양자 암호화를 사용해야 한다는 요구사항을 생성하는 예를 들었습니다. 사용자 정의 요구사항을 만들 때 네 가지 주요 부분이 필요합니다: 이름과 설명, 적용 가능성, 준수 기준, 그리고 내부 문서 링크나 승인된 라이브러리에 대한 권장사항입니다.
발표자는 생성된 사용자 정의 보안 요구사항이 AWS가 제공하는 관리형 요구사항과 함께 배치되며, 앞으로 모든 설계 및 코드 검토에 적용된다고 설명했습니다.
AWS Security Agent
세션에서는 “AWS Sweets Manager”라는 가상의 서비스를 예로 들어 실제 작동 방식을 시연했습니다. 일반적으로 몇 시간, 며칠, 심지어 몇 주가 걸릴 수 있는 작업이 이제 몇 분 만에 완료된다는 점이 매우 인상적이었습니다.
설계 검토를 생성하고, 설계 문서를 업로드하고, 시작을 클릭하면 1분 만에 결과를 얻을 수 있습니다.
결과 화면에서는 어떤 보안 요구사항이 준수되는지, 어떤 것이 적용되지 않는지 확인할 수 있습니다. 발표자는 컨텍스트가 중요하기 때문에 모든 보안 요구사항이 모든 애플리케이션에 적용되는 것은 아니라고 설명했습니다.
데모에서 Secure by Default 요구사항이 준수되지 않은 것으로 나타났습니다. 사용자가 생성한 리소스인 박스가 기본적으로 공개적으로 공유되도록 설정되어 있었기 때문입니다. Agent는 왜 준수하지 않는지 설명하고, 보안 요구사항을 충족하도록 설계 문서를 업데이트하는 방법에 대한 수정 지침도 제공했습니다. 발표자가 강조한 가장 큰 장점은 단 한 줄의 코드도 작성되기 전에 설계 단계에서 이를 조기에 발견했다는 것입니다.
또 다른 기능으로 코드 검토를 소개했습니다. GitHub 리포지토리를 연결하면, Security Agent가 동일한 보안 요구사항 세트에 대해 모든 풀 리퀘스트를 검토합니다. 일부 요구사항은 설계 부분에 적용될 수 있고, 다른 요구사항은 코드에 적용될 수 있으며, 둘 다에 적용되는 경우 둘 다에서 평가가 이루어집니다.
발표자는 개발자가 설계 검토 없이 바로 코딩을 시작하는 경우를 예로 들었습니다. 코딩 어시스턴트를 사용하면 시작하기가 더욱 쉬워졌지만, Security Agent가 풀 리퀘스트를 읽고 기본적으로 안전하지 않은 구성을 자동으로 플래그한다고 합니다.
또한 AWS가 지난 몇 개월 동안 내부적으로 이 Security Agent를 사용했던 사례에 대해 발표해주었습니다. 발표자는 AWS도 자체 내부 보안 요구사항이 많이 있으며, Security Agent를 사용하여 이러한 요구사항을 포착하고 개발자의 속도를 높여왔다고 밝혔습니다.
특히 주목할 만한 예는 IAM 통합 라이브러리입니다. AWS의 모든 서비스는 IAM과 통합되어야 하는데, 자동화된 추론 기반의 검증된 라이브러리를 출시했다고 합니다. 발표자는 이것이 팀이 정확하고 빠르게 작업할 수 있도록 내부적으로 개발한 핵심 보안 기본 요소라고 설명했습니다. AWS Security Agent가 모든 서비스 팀이 이 라이브러리를 사용하도록 보장하는 메커니즘 역할을 한다는 점이 흥미로웠습니다.
세션에서 공유한 한 팀의 피드백은 Proactive Security의 힘을 잘 보여줍니다. “문제를 조기에 발견하고 조기에 수정할 수 있어서 프로덕션에 도달하기 전에 해결할 수 있었습니다.” 나중에 문제를 발견하고 수정할수록 더 어렵고 비용이 많이 든다는 것은 보안 업계에서 잘 알려진 사실입니다.
혁신적인 활용 사례
기존 보안 검토를 Security Agent로 일대일로 교체하는 것은 좋은 시작이지만, 여전히 Proactive Security를 배분해야 할 사치품으로 생각하는 것입니다. 이전에 고려하지 않았던 방식으로 Proactive Security를 수행하는 방법을 살펴보겠습니다.
Sweets Manager의 기능 요청이 있습니다. 리소스 정책을 사용하여 리소스를 공유하는 기능입니다.
엔지니어가 1~2주 동안 설계 문서를 작성하도록 하고 나중에 보안 검토를 받게 할 수도 있지만, 이 기능 요청 자체로 보안 설계 검토를 수행할 수 있습니다.
Security Agent에 업로드해보니, 대부분의 보안 요구사항은 적용되지 않거나 데이터가 충분하지 않았지만, 보안 요구사항 중 하나가 이미 준수되지 않았습니다. Block Public Access입니다. AWS는 모든 새로운 리소스 기반 정책이 Block Public Access를 요구합니다. S3를 사용하는 경우 한 번의 클릭으로 켤 수 있어 리소스가 공개되지 않도록 보장할 수 있습니다. 모든 새 리소스 정책이 이를 지원하는 것이 요구사항입니다.
이것은 놀라운 일입니다. 중요한 요구사항이 있다는 것을 알아내기 위해 몇 주 동안 기능을 설계하는 대신, 시작하기도 전에 이제 알게 됩니다.
매우 짧은 형식의 콘텐츠와 반대로, 매우 긴 형식의 콘텐츠를 대상으로 검토해보았습니다.
Sweets Manager는 실제로 2020년에 구축되었으며, 자체 서비스를 사용하는 것이 얼마나 쉬운지 확인하는 방법으로 구축한 일반 애플리케이션이었습니다. 이것의 일부로 엔지니어 중 한 명이 1시간 반 동안 미팅을 했습니다. 어떻게 생성되었는지, 어떤 서비스가 사용되었는지, 어떤 서비스가 잘 작동했는지, 어려운 점은 무엇이었는지를 설명했습니다.
Security Agent가 이 미팅에 대해 어떻게 생각하는지 보기 위해 트랜스크립트를 업로드하고 설계 검토를 만들었습니다. 결과를 보니 대부분은 적용되지 않았지만, 미팅이 비밀 보호에 대한 모범 사례를 준수하지 않은 것으로 나타났습니다. 적절한 보호 없이 민감한 자격 증명을 직접 사용하는 것처럼 보였습니다. 발표자는 데모 미팅으로서는 예상치 못한 일이 아니지만 타당한 지적이라고 평가했습니다.
Penetration Testing
세션의 후반부에서는 Neha Goswami가 침투 테스트에 대해 설명했습니다.
발표자에 따르면 Amazon에서도 침투 테스트는 개발 과정에서 매우 늦게 이루어진다고 합니다. 개발자들이 이미 무엇을 구축할지 결정하고, 코드를 작성하고, 체크인하고, 기능이 라이브로 갈 준비가 된 후에야 보안 팀이 침투 테스트를 수행하기 위해 참여합니다. 작업이 끝날 때까지 몇 주를 기다려야 한다고 합니다.
발표자는 현재의 침투 테스트를 “촛불 시대”라고 표현했습니다. 침투 테스트 전문 지식이 제한적이므로 많은 회사가 전문 회사에 아웃소싱하고, 정말 느린 프로세스이며, 꽤 일찍 스케줄을 잡아야 하고, 많은 시간이 소요된다고 설명했습니다. 게다가 침투 테스트 회사 자체도 이미 쉽게 조기에 발견할 수 있었던 매우 기본적인 취약점을 제공하는 경우가 많아 가치가 제한적이라고 지적했습니다.
이것은 고객으로부터도 자주 듣는 이야기라고 합니다. 미리 스케줄을 잡아야 하고, 가치가 매우 제한적이며, 감지된 취약점과 애플리케이션의 로직 간의 연결이 항상 좋은 것은 아닙니다.
작동 방식을 살펴보면, 침투 테스트 Agent는 API 엔드포인트, 로그인에 필요한 연결, 관련 문서, 코드 리포지토리를 입력으로 받습니다. Preflight 단계에서 엔드포인트를 확인하고 사이트맵을 생성하여 애플리케이션 컨텍스트를 파악합니다. Planning Agent가 여러 침투 테스트를 병렬로 실행하고, Validation Gate에서 발견된 문제의 유효성을 검증하여 실제 취약점과 오탐을 명확히 구분합니다. Agent Loop를 통해 결과를 정제하고, Remediation Gate에서 모든 정보를 종합하여 코드 리포지토리에 Pull Request를 생성한다고 합니다.
시작하기는 매우 간단합니다. 발표자에 따르면 대부분의 정보는 선택 사항이며, 타겟 URL만으로도 Agent를 실행할 수 있다고 합니다.
침투 테스트 Agent는 몇 시간이 걸릴 수 있는 장기 실행 Agent입니다. 실시간으로 진행 상황을 추적할 수 있으며, 완료되면 결과를 고위험, 중위험, 저위험으로 분류하여 제공합니다.
발표자에 따르면 이러한 분류는 보안 팀과 엔지니어 모두에게 매우 유용하다고 합니다. 프로덕션 배포 전에 반드시 수정해야 하는 것과 추후에 수정할 수 있는 것을 구분할 수 있기 때문입니다.
가장 인상적이었던 부분은 Agent가 테스트를 어떻게 수행했는지 단계별로 보여주는 상세 요약입니다. 발표자는 이 페이지가 자체 내부 보안 팀과 고객으로부터 가장 긍정적인 피드백을 받았다고 밝혔습니다. Agent가 어떻게 취약점에 도달했는지 단계별 분석을 보여주며, “이 단계를 수행한 다음 다음 단계를 수행한 다음 이 단계에서 다음 작업을 수행합니다”라는 식으로 매우 상세하게 설명한다고 합니다.
팀이 정말 좋아한 또 다른 것은 재현 단계라고 합니다. Agent가 수행한 작업을 팀이 다시 실행하여 신뢰를 구축할 수 있습니다. 발표자는 이것이 보안 팀이 프로덕션에서 이 도구를 사용하기 시작하는 것에 자신감을 가질 수 있도록 하는 데 필수적이었다고 강조했습니다.
발표자가 가장 좋아하는 부분이라고 밝힌 것은 자동 수정 기능입니다. Agent가 식별한 문제를 해결하는 방법을 설명하기 위해 Pull Request가 자동으로 생성됩니다.
발표자는 “코딩 Agent 덕분에 실제 코딩 부분이 속도 면에서 도약했습니다. 팀은 매우 높은 속도로 코드를 생성하고 있습니다. 보안이 병목이 되는 것을 원하지 않습니다”라고 말했습니다. 이 Agent가 실제로 수정을 수행할 수 있고, 온디맨드로 실행할 수 있으며, Pull Request를 생성한다는 사실은 엔지니어링 팀의 개발 속도를 따라갈 수 있다는 의미입니다.
고객 피드백도 매우 긍정적이었다고 합니다. Sputman의 경우 침투 테스트 Agent를 실행했을 때 Agent가 코드 구조에서 비즈니스 로직 취약점을 발견했고, 이는 이전에 발견되지 않았던 것이어서 매우 만족했다고 합니다.
결론
세션을 통해 Proactive Security의 세 가지 측면인 설계 검토, 코드 검토, 침투 테스트를 모두 살펴볼 수 있었습니다. 발표자는 세 가지 도구 모두 매우 애플리케이션 지향적이고 비즈니스 인식적인 결과를 제공하며, 온디맨드로 실행할 수 있고, Agent의 작업을 상세히 볼 수 있으며, 결과가 포괄적이라고 강조했습니다.
개발 라이프사이클 초기에 취약점을 예방하면서도 현대 개발의 속도를 유지할 수 있는 것, 단 한 줄의 코드도 작성되기 전에 보안 문제를 발견할 수 있는 것, 그리고 자동으로 수정 방법까지 제시 받을 수 있는 것 등, 개발 속도와 보안 사이의 균형을 찾고자 하는 조직에게 AWS Security Agent는 강력한 솔루션이 될 것으로 보입니다.
