전체 repo 스캔, AWS Security Agent가 겨냥한 SAST의 빈칸

AWS가 2026년 5월 12일 AWS Security Blog에서 AWS Security Agent의 full repository code review 프리뷰를 공개했습니다. 이름만 보면 기존 코드 스캐너에 "전체 저장소" 옵션이 붙은 것처럼 보입니다. 하지만 발표문이 겨냥한 지점은 더 구체적입니다. AWS는 이 기능이 단일 파일이나 알려진 취약점 패턴을 훑는 방식이 아니라, 전체 애플리케이션의 구조, 신뢰 경계, 데이터 흐름, 권한 불변식을 먼저 파악한 뒤 취약점 후보를 찾고 검증한다고 설명합니다.

이 뉴스가 흥미로운 이유는 "AI가 코드를 더 많이 읽는다"는 양적 변화 때문만은 아닙니다. 보안 리뷰의 병목이 어디에 있는지 드러내기 때문입니다. 지금까지 SAST는 빠르고 일관적이지만, 이미 알려진 패턴에 강했습니다. 하드코딩된 비밀, 명백한 SQL injection sink, escape 누락, 취약한 암호 함수 같은 문제는 기계가 잘 잡습니다. 반대로 실제 침해로 이어지는 결함 중 상당수는 더 애매합니다. 다섯 개 경로 중 하나만 검증 함수가 빠져 있거나, 같은 값이 한 화면에서는 인코딩되고 다른 화면에서는 빠지거나, endpoint 하나만 authorization annotation을 잃어버린 경우입니다. 이런 결함은 한 줄의 냄새가 아니라 시스템의 불일치입니다.

AWS가 이번 발표에서 "traditional static analysis tools"와 거리를 둔 것도 이 때문입니다. 발표문은 full repository code review가 application architecture, trust boundaries, data flows를 추론한다고 말합니다. 과감한 표현도 들어갑니다. AWS Security Agent가 전체 code base에서 취약점을 찾고 working exploit을 만들 수 있다고 설명합니다. 이 문장은 매력적이지만 동시에 조심해서 읽어야 합니다. 보안팀에게 중요한 것은 agent가 멋진 finding을 내는 것이 아니라, 어떤 증거를 남기고 어떤 부분을 검증하지 못했는지 명확히 말하는 것입니다.

SAST가 빠른 대신 놓치는 것

SAST는 여전히 필요합니다. 빠르고 싸고, CI에 붙이기 쉽고, 반복 가능한 정책 집행에 좋습니다. 모든 PR에서 금지된 API, secret, dependency issue, 기본적인 injection pattern을 걸러내는 일은 에이전트가 아니라 규칙 기반 도구가 더 적합할 때도 많습니다. 문제는 SAST가 잘하는 영역과 사람이 수동 리뷰에서 찾는 영역 사이에 빈칸이 있다는 점입니다.

AWS가 든 예시는 이 빈칸을 잘 보여줍니다. 한 stored procedure에 SQL injection 취약점이 있을 때, 일반 SAST는 특정 EXECUTE IMMEDIATE 호출을 잡을 수 있습니다. 하지만 AWS 설명에 따르면 scanner는 중앙 validation function이 다섯 개 regex profile 모두에서 single quote를 막지 않는다는 점, 특정 database engine에서 single quote가 왜 중요한지, 다른 stored procedure가 validation function을 아예 건너뛴다는 점까지 연결했습니다. 이 경우 수정은 한 호출부의 escape 추가가 아니라 validation 체계 전체의 보강입니다.

XSS 사례도 비슷합니다. 어떤 값이 한 context에서는 Encode.forHtml()로 처리되지만, 같은 파일의 다른 경로에서는 HTML encoding 없이 field에 들어갑니다. pattern matcher는 파일 안에 encoding function이 있다는 사실을 보고 안심할 수 있습니다. 반대로 사람 리뷰어는 "왜 같은 값이 어떤 경로에서는 보호되고 어떤 경로에서는 보호되지 않는가"를 묻습니다. AWS Security Agent의 full repository review는 바로 이 질문을 자동화하려 합니다.

네 단계가 말하는 에이전트 보안 리뷰의 모양

AWS는 full repository code review가 네 단계로 작동한다고 설명합니다. 첫째는 profile입니다. scanner가 전체 저장소를 읽어 entry point, trust boundary, data flow, authorization invariant, 이미 존재하는 방어 장치를 모델링합니다. 이 단계가 중요한 이유는 coverage 결정이 암묵적이지 않게 되기 때문입니다. "파일을 얼마나 읽었는가"가 아니라 "어떤 공격 표면으로 이해했는가"가 리뷰의 기준이 됩니다.

둘째는 search입니다. orchestrator가 보안 profile을 읽고 위험도가 높은 component에 specialized agent를 보냅니다. 각 agent는 특정 module, threat context, adversarial question을 받습니다. 흥미로운 부분은 agent가 시작 scope 밖의 import나 caller를 따라갈 수 있다는 점입니다. 취약점은 대개 한 파일에 갇혀 있지 않습니다. validation은 middleware에 있고, permission check는 decorator에 있고, 실제 sink는 service layer에 있을 수 있습니다. 에이전트 리뷰가 의미 있으려면 이 경로를 따라가야 합니다.

셋째는 triage와 dedup입니다. 같은 sink, 같은 root cause에서 나온 후보를 합치고 낮은 confidence noise를 버립니다. 이 단계는 AI 보안 도구에서 특히 중요합니다. 모델은 좋은 가설을 많이 내지만, 좋은 가설이 곧 좋은 보안 결과물은 아닙니다. 보안팀 입장에서 finding 열 개보다 검증된 finding 두 개가 더 가치 있을 수 있습니다. 노이즈가 많은 도구는 시간이 지나면 개발자에게 무시됩니다.

넷째는 independent validation입니다. 별도 validator가 source code를 다시 읽고 전체 attack chain을 추적합니다. validator는 finding이 취약점이 아닐 수 있는 이유와 취약점일 수 있는 이유를 모두 검토합니다. AWS는 finding이 Verified와 Could not verify 섹션을 갖는다고 설명합니다. 이 구분이 이번 발표에서 가장 실용적인 부분입니다. 보안 에이전트가 deployment environment, network segmentation, runtime behavior까지 전부 확정할 수 없다면, 어디까지 code evidence이고 어디서부터 환경 의존인지 분리해야 합니다.

이 구조는 Microsoft MDASH와도 닮았습니다. MDASH는 Windows 네트워킹 및 인증 스택에서 발견, 검증, 증명 단계를 강조했습니다. AWS Security Agent의 이번 발표는 더 일반 개발팀에 가까운 경로를 보여줍니다. Microsoft 쪽이 거대 proprietary OS codebase와 Patch Tuesday 루프 안의 보안 하네스라면, AWS 쪽은 고객 repository와 GitHub workflow, S3 source, remediation PR에 가까운 제품 경계입니다. 둘 다 같은 방향을 가리킵니다. 보안 AI의 경쟁은 모델 이름보다 finding을 검증 가능한 업무 단위로 바꾸는 workflow에서 갈립니다.

개발자가 실제로 만나는 흐름

공식 quickstart를 보면 제품의 표면은 비교적 익숙합니다. 먼저 AWS Console에서 Agent Space를 만듭니다. Agent Space는 테스트할 application 단위로 잡는 공간이고, 여러 사용자가 함께 쓸 수 있습니다. 접근은 IAM-only로 시작할 수 있고, AWS Management Console 없이 Security Agent web application에 접근하게 하려면 IAM Identity Center 통합을 켤 수 있습니다.

그다음 GitHub integration을 연결합니다. repository는 전체를 선택할 수도 있고 일부만 선택할 수도 있습니다. repository별로 code review comments와 automatic remediation을 켜고 끌 수 있습니다. S3 bucket에 소스가 있다면 S3 source도 연결할 수 있습니다. code review 설정은 기본적으로 조직별 security requirement 준수와 일반 vulnerability finding을 함께 분석합니다.

실행은 Security Agent web application에서 합니다. Code reviews 메뉴에서 review를 만들고, GitHub repository나 S3 source를 고르고, service role을 선택합니다. 선택적으로 automatic code remediation을 켜면 finding에 대해 자동 수정 PR을 요청할 수 있습니다. AWS 문서는 code review가 codebase 크기에 따라 보통 30-60분 걸린다고 설명합니다. 완료 후 Findings 탭에서 Description, Code locations, Risk reasoning을 보고, Remediate code로 fix PR을 만들 수 있습니다.

이 UX는 보안 리뷰의 위치를 바꿉니다. 기존에는 보안팀이 특정 시점에 penetration test나 architecture review를 예약하고, 개발팀은 그 전까지 대기하거나 자체 점검을 합니다. AWS가 제안하는 흐름은 보안팀의 깊은 리뷰 전에 전체 repo 에이전트 리뷰를 돌려 "명백하거나 반쯤 명백한 문제"를 먼저 걷어내는 것입니다. 발표문도 이것을 기존 security tooling의 대체가 아니라 보완이라고 표현합니다.

finding의 형식이 제품의 신뢰를 좌우합니다

AI 보안 도구에서 가장 위험한 실패는 틀린 finding 자체보다, 틀린 finding이 확신에 찬 문장으로 전달되는 것입니다. 개발자는 이미 alert fatigue에 지쳐 있습니다. finding이 실제 취약점인지, 배포 환경에서 exploitable한지, 어떤 조건이 필요한지, 무엇을 고치면 충분한지 분리되어 있지 않으면 도구는 곧 "AI가 만든 noisy report"가 됩니다.

AWS가 finding 구조를 강조한 것은 이 문제를 의식한 것으로 보입니다. Problem은 코드가 무엇을 잘못하는지와 파일, 라인을 제시합니다. Impact는 공격자가 얻는 것을 deployment context와 함께 설명합니다. Verified와 Could not verify는 코드에서 직접 확인한 것과 환경에 의존하는 것을 나눕니다. Remediation은 generic guidance가 아니라 구체적 code change를 제안합니다. Severity와 confidence도 분리됩니다. severity는 exploitable할 때의 피해이고, confidence는 attack chain 중 코드에서 확인한 범위입니다.

이 구분은 작아 보이지만 중요합니다. 예를 들어 내부 admin endpoint에서 authorization check 누락이 의심된다고 합시다. 코드만 보면 위험합니다. 하지만 실제 배포에서는 private network 뒤에 있고, mTLS와 identity-aware proxy를 거칠 수도 있습니다. 이 경우 severity는 높을 수 있지만 confidence는 환경 정보에 따라 달라집니다. 반대로 인터넷 노출 endpoint에서 같은 누락이 코드와 route config로 확인된다면 confidence도 올라갑니다. 보안 에이전트가 이런 차이를 표현하지 못하면 사람 리뷰어의 시간을 줄이기 어렵습니다.

왜 전체 저장소인가

전체 저장소 리뷰는 비용이 큽니다. 더 많은 파일을 읽고, 더 많은 call graph와 data flow를 추적하고, 더 많은 후보를 dedup해야 합니다. 하지만 보안 취약점은 repository 안의 경계를 따라 움직이지 않습니다. 사용자 입력은 controller에서 들어오고, DTO 변환을 거치고, service layer에서 permission을 확인하고, repository layer에서 query로 바뀝니다. 인코딩과 검증과 authorization이 각각 다른 파일에 있으면, 한 파일만 보는 scanner는 구조적 결함을 놓치기 쉽습니다.

더 큰 문제는 조직 지식입니다. 보안팀은 "우리 회사에서는 이 library가 승인된 authorization layer다", "이 logging field는 개인정보라 masking해야 한다", "이 S3 bucket path는 tenant boundary다" 같은 정보를 알고 있습니다. AWS Security Agent 문서는 조직별 security requirement를 Console에서 한 번 정의하고 design review와 code review에 적용할 수 있다고 설명합니다. 이는 일반 취약점 목록보다 더 실무적입니다. 팀마다 같은 "SQL injection"보다 "우리 조직의 인증/로깅/데이터 접근 기준을 어겼는가"가 더 중요한 순간이 많기 때문입니다.

인수한 코드나 오픈소스 component를 도입할 때도 전체 저장소 리뷰의 의미가 커집니다. 내부 지식이 없는 codebase를 받아들일 때, 사람은 먼저 구조를 파악해야 합니다. 어떤 endpoint가 있고, 어떤 데이터가 민감하고, 어떤 검증이 중앙화돼 있고, 어떤 경로가 예외인지 봐야 합니다. AWS는 scanner가 institutional knowledge 없이 security model을 처음부터 만든다는 점을 장점으로 제시합니다. 이 주장은 아직 고객 사례와 벤치마크로 더 검증되어야 하지만, 문제 설정 자체는 현실적입니다.

커뮤니티가 아직 넓게 반응하지 않은 이유

이번 업데이트는 강한 주장에 비해 커뮤니티 반응이 아주 넓게 형성된 상태는 아닙니다. Hacker News의 직접 토론은 확인하지 못했습니다. Reddit의 Cloudvisor 게시물은 full repository review가 single-file이나 snippet-level check보다 의미 있는 개선이라고 짧게 평가했습니다. 과거 r/aws의 AWS Security Agent preview 피드백에서는 target URL과 authentication URL 설정이 맞지 않아 agent가 ERR_ACCESS_DENIED를 만난 사례가 공유됐습니다. 이 사례는 기능 자체보다 운영 경계의 중요성을 보여줍니다.

보안 에이전트는 "더 자유롭게 공격해 보라"와 "고객 환경을 절대 벗어나지 말라"는 두 요구를 동시에 만족해야 합니다. authentication URL, redirect domain, staging host, callback path, API gateway, private network가 조금만 어긋나도 에이전트는 실제 attack chain을 재현하지 못하거나, 반대로 허용되지 않은 표면을 건드릴 수 있습니다. AWS Security Agent가 code review를 repo 단위로 확장할수록 이런 설정 품질은 더 중요해집니다.

또 하나의 질문은 데이터 경계입니다. 전체 저장소 리뷰는 코드와 문서를 많이 읽습니다. GitHub repository, S3 source, service role, CloudWatch log group 설정이 얽힙니다. 개발팀은 "어떤 코드가 어디로 이동하는가", "어떤 모델이나 agent runtime이 접근하는가", "finding과 remediation PR에 어떤 민감 정보가 남는가"를 확인해야 합니다. 보안 도구에 소스 전체를 맡기는 결정은 단순한 생산성 도입이 아니라 공급망·권한·감사 결정입니다.

SAST의 종말이 아니라 보안 리뷰의 계층화

이번 발표를 "SAST의 종말"로 읽으면 과합니다. 오히려 더 현실적인 결론은 보안 리뷰가 계층화된다는 것입니다. 첫 계층은 빠른 규칙 검사입니다. secret, dependency, known sink, license, IaC misconfiguration처럼 명확한 것은 계속 빠르게 잡아야 합니다. 둘째 계층은 PR 중심의 developer feedback입니다. 변경한 코드가 조직 기준을 위반하거나 새로운 위험을 만들 때 즉시 알려주는 흐름입니다. 셋째 계층은 repo 단위 에이전트 리뷰입니다. 특정 release, 인수 코드, 고위험 서비스, architecture review 전에 전체 구조를 읽고 finding 후보를 정리합니다. 마지막 계층은 사람 보안 리뷰입니다. threat model, 사업 맥락, 위험 수용, 제품 정책은 여전히 사람이 결정합니다.

AWS Security Agent의 full repository code review는 이 세 번째 계층을 제품화하려는 시도입니다. 발표문은 보안팀이 penetration test나 security review를 예약하기 전에 이 리뷰를 돌려 obvious and semi-obvious issue를 먼저 표면화하라고 제안합니다. 좋은 방향입니다. 보안 전문가의 시간을 "정규식이 놓친 escape"보다 "이 권한 모델이 제품 요구와 맞는가"에 쓰게 만든다면 가치가 있습니다.

다만 preview라는 단어를 잊으면 안 됩니다. 공개 정보만으로는 language/framework coverage, false positive rate, false negative profile, model choice, source retention, large monorepo에서의 비용과 시간, automatic remediation PR의 품질을 판단하기 어렵습니다. AWS 문서가 말하는 30-60분도 codebase size에 따라 달라집니다. 보안팀은 이 도구를 도입할 때 먼저 낮은 위험의 repository에서 baseline을 만들고, 기존 SAST와 pentest 결과와 교차 비교해야 합니다.

개발팀이 바로 물어야 할 질문

첫째, 이 도구를 어디에 넣을 것인가입니다. 모든 PR에 전체 repo review를 돌리는 것은 비용과 시간 면에서 맞지 않을 수 있습니다. 반대로 release candidate, 주요 인증/결제/권한 서비스 변경, 인수 코드 반입, 외부 공개 API 추가 시점에는 충분히 의미가 있습니다. 에이전트 리뷰를 CI의 synchronous gate로 둘지, security review 전에 asynchronous report로 둘지 정해야 합니다.

둘째, finding의 책임 소재입니다. 자동 remediation PR이 생성되면 누가 리뷰합니까. 개발팀이 바로 merge해도 되는가, 보안팀 승인 없이는 안 되는가, low confidence finding은 backlog로 가는가, high severity but low confidence finding은 어떻게 다루는가. AI 보안 도구는 finding을 많이 만드는 순간부터 운영 정책이 필요합니다.

셋째, 조직별 security requirement를 얼마나 명확히 쓸 수 있는가입니다. AWS Security Agent의 강점은 generic checklist보다 조직 기준을 적용할 수 있다는 데 있습니다. 하지만 그 기준이 낡았거나 모호하면 에이전트도 모호한 결과를 냅니다. "적절한 authorization을 사용하라"보다 "외부 사용자 데이터 접근은 approved middleware와 tenant scope check를 모두 통과해야 한다"처럼 검토 가능한 기준이 필요합니다.

넷째, 기존 도구와 어떻게 비교할 것인가입니다. Semgrep, Snyk, CodeQL, GitHub code scanning, Endor AURI, 내부 linters가 이미 있을 수 있습니다. AWS Security Agent를 새로 붙인다면 finding 중복, severity mapping, suppression, ticket routing을 맞춰야 합니다. 좋은 보안 도구도 기존 workflow와 충돌하면 도입이 실패합니다.

에이전트 보안 경쟁의 다음 기준

지난 몇 달 동안 AI 보안 경쟁은 빠르게 이동했습니다. Anthropic은 Claude Code Security와 Mythos 계열 흐름을 통해 취약점 발견 역량을 강조했고, Microsoft는 MDASH로 multi-agent scanning harness와 Patch Tuesday 연결을 보여줬습니다. Endor Labs는 AI 코딩 에이전트가 가져오는 package와 dependency 위험을 AURI로 감시하려 합니다. AWS는 이번 업데이트로 고객 저장소 전체를 읽고, finding을 구조화하고, remediation PR까지 이어지는 개발 workflow 쪽에 더 가까이 붙었습니다.

공통점은 분명합니다. 보안 AI의 질문은 "모델이 취약점을 찾을 수 있는가"에서 "그 finding을 어떤 증거, 어떤 권한, 어떤 workflow, 어떤 수정으로 바꾸는가"로 넘어갑니다. 전체 repo review는 이 전환의 중요한 조각입니다. 애플리케이션 보안은 더 이상 한 파일의 패턴 문제가 아니라 데이터와 권한과 배포 경계가 얽힌 시스템 문제이기 때문입니다.

AWS Security Agent의 새 기능은 아직 preview입니다. 독립 검증과 실사용 데이터가 더 필요합니다. 하지만 방향은 실무적입니다. SAST가 빠르게 잡는 것과 사람이 깊게 보는 것 사이에는 오래된 빈칸이 있었습니다. AWS는 그 빈칸에 에이전트를 넣으려 합니다. 성공 여부는 모델 성능보다 finding의 품질, 권한 경계, 개발자 workflow 통합, 그리고 "검증하지 못한 것"을 정직하게 말하는 능력에서 갈릴 것입니다.