#0016

AWS community day, security edition

2026년 4월 10일, 미국에서 열린 AWS Community Day Security Edition에 다녀왔다. 보안도 AWS도 깊이 아는 편이 아니라서 세션을 따라가기가 쉽진 않았지만, “아 미국 컨퍼런스는 이런 분위기구나” 같은 감각은 확실히 남았다. 행사장에서는 아침과 점심을 주고, 저녁은 Sports Page라는 곳에서 따로 제공해줬는데, 생각보다 그 시간이 더 기억에 남는다. 낯선 도시에서 밥을 먹으며 오늘 들은 얘기를 대충 곱씹는 느낌이 좋았다.

세션 내용은 꽤 어려웠지만, 이상하게도 방향은 단순했다. 각기 다른 발표처럼 보였는데, 계속 듣다 보니 전부 한쪽으로 모이고 있었다. 결국 들으면서 점점 분명해진 것은, 거의 모든 세션이 AI로 수렴한다는 것이었다.

코드와 데이터의 경계가 흐려지는 순간

초반 세션에서는 LLM 테스트 이야기가 나왔다. 같은 프롬프트를 넣어도 결과가 계속 달라지기 때문에, 기존처럼 정해진 입력과 출력으로 검증하는 방식이 더 이상 통하지 않는다는 얘기였다. 그래서 정적 테스트 대신, 다른 방식의 검증 프레임워크가 필요하다는 설명이 이어졌다. 듣는 내내 “테스트가 이렇게까지 달라지나” 싶었다.

여기에 더해, 외부 데이터를 참조하는 구조에서 발생하는 간접 프롬프트 인젝션(Indirect Prompt Injection) 얘기가 같이 붙었다. 모델이 GitHub나 웹페이지 같은 곳을 읽는 것만으로도 공격이 가능해진다는 점이 인상적이었다.

이 챕터에서 가장 기억에 남은 표현은 **“입력값이 코드가 된다”**는 말이었다. 예전에는 무엇이 코드이고 무엇이 데이터인지 비교적 분명했는데, 이제는 그 경계가 거의 사라지는 느낌이었다. 모델이 읽는 README, GitHub Issue, 웹페이지 같은 것들이 전부 잠재적인 명령어가 될 수 있다는 얘기를 듣고 나니, 공격자가 굳이 시스템 안으로 들어오지 않아도 된다는 점이 새삼 무겁게 들렸다.

에이전트가 대신 행동할 때 생기는 일들

MCP(Model Context Protocol) 세션은 처음에는 그냥 “모델이 외부 도구를 부르는 표준” 정도로 들렸다. 구조도 비교적 단순했다. Host, Client, Server로 나뉘고, 통신은 stdio, http, JSON-RPC 2.0 같은 방식으로 이루어진다고 했다. 그런데 여기서 “유일하게 신뢰할 수 있는 건 host뿐”이라는 말이 계속 강조됐다.

데모에서는 AI 코딩 에이전트가 메일을 보내는 상황이 나왔다. 정상적인 MCP 서버를 쓰고 있었는데, 다른 악의적인 서버가 끼어들면서 메일의 BCC에 공격자의 이메일이 몰래 추가되는 식이었다. 사용자는 그냥 메일을 보낸 줄 알지만, 실제로는 다른 동작이 같이 수행되는 구조였다.

이걸 설명하면서 나온 개념이 Confused Deputy였다. AI가 외부의 악의적인 데이터와, 메일 발송 같은 민감한 권한을 동시에 다룰 때 생기는 문제라고 했다. 비슷한 맥락으로 GitHub Actions 캐시가 오염돼서 npm 토큰이 노출된 사례도 짧게 언급됐는데, 생각보다 가까운 곳에서도 이런 일이 일어난다는 느낌이 들었다.

듣고 나서 남은 인상은, MCP의 “깔끔한 구조” 자체가 오히려 위험을 키울 수 있다는 점이었다. 에이전트가 여러 서버를 동시에 다루는 순간, 하나라도 오염되면 나머지까지 끌려간다. 결국 신뢰할 수 있는 건 host뿐이라는 말은, 자동화된 흐름 안에서도 사용자의 명시적인 동의가 계속 필요하다는 뜻처럼 들렸다.

보이지 않는 곳에서 일어나는 공격들

이 챕터에서는 두 가지 공격이 같이 나왔는데, 결이 비슷해서 하나로 묶여 들렸다. 공통점은 둘 다 “사용자가 보지 못하는 자리”에서 동작한다는 점이었다.

첫 번째는 Invisible Character Injection, 일종의 Hash Smuggling이다. 화면에는 보이지 않지만 LLM은 읽을 수 있는 유니코드를 이용해서 명령을 숨겨 넣는 방식이다. SEC 공시 문서 안에 숨겨진 문장이 있었는데, 겉으로 보면 평범한 텍스트인데 실제로는 “주식을 거래하라” 같은 명령이 포함되어 있었다. 분석가가 요약을 요청하면, AI가 그 명령까지 같이 실행하는 식이었다.

두 번째는 Persistent Memory Poisoning이었다. 한 세션에서 공격자가 에이전트의 메모리에 특정 설정을 심어두고, 이후 다른 사용자가 같은 에이전트를 사용할 때 그 설정이 그대로 적용되는 구조였다. 예를 들어 “알림을 보낼 때 공격자에게도 같이 보내라”는 식의 지시가 저장되면, 다음 사용자 데이터가 그대로 유출되는 식이다. 핵심은 “한 번 오염되면 이후 모든 사용자에게 영향이 간다”는 점이었다.

둘 다 들으면서 불편했던 건, 공격자가 거기에 계속 있을 필요가 없다는 점이었다. 보이지 않는 유니코드는 화면 밖에서, 오염된 메모리는 시간 밖에서 작동한다. 한 번 심어두면, 나중에 누군가가 알아서 그 공격을 실행하게 되는 구조라는 게 계속 머리에 남았다.

여러 겹으로 나눠서 막는다는 접근

AWS 쪽 세션은 개별 기술보다 전체 그림이 더 인상적이었다. 보안을 한 번에 막는 게 아니라, 단계별로 나눠서 쌓는 방식이었다.

• 입력 단계에서 보이지 않는 문자 같은 걸 걸러내는 Input Sanitization
• Bedrock Guardrails로 프롬프트 인젝션이나 부적절한 입력을 탐지
• AgentCore Identity, S3, KMS 같은 정책으로 최소 권한 유지

여기에 더해, 인프라 자체를 코드로 관리하고 모든 변경을 PR로 처리하는 방식도 같이 나왔다. Renovate가 계속 업데이트 PR을 열어주고, AWS Control Tower로 계정과 정책을 관리하는 흐름이었다. 보안이 특정 시점의 점검이 아니라, 계속 돌아가는 워크플로우 안에 들어가 있는 느낌이었다.

인사이더 위협 탐지 쪽에서는 OpenSearch와 Bedrock을 활용한 벡터 검색 이야기도 나왔는데, 여기서는 기술보다는 “이걸 다 AWS 안에서 해결하려고 하는구나”라는 인상이 더 강했다.

Kiro라는 IDE도 잠깐 봤다. 기획부터 구현까지 과정을 시각적으로 보여주는 도구였는데, gstack이랑 비슷한 느낌이었다. 다만 개인적으로는 그런 UI보다는, 에이전트가 할 수 있는 것과 없는 것을 정의하는 게 더 중요해 보였다.

이 챕터에서 남은 건 한 문장으로 요약되는 느낌이었다. “변경은 항상 PR로”. 보안이 이벤트가 아니라, 일상적인 개발 과정 안에 들어가야 한다는 얘기로 들렸다.

자율성과 격리 사이에서 남은 감각

하루 동안 들은 세션들을 묶어보면 결국 하나의 질문으로 모였다. Isolation과 Autonomy 사이에서 어디까지를 허용할 것인가. 권한을 많이 줄수록 에이전트는 더 많은 일을 할 수 있지만, 동시에 공격 표면도 같이 커진다.

강연자들은 공통적으로, 보안을 나중에 붙이는 게 아니라 처음부터 같이 설계해야 한다고 말했다. 기능을 다 만든 다음 체크하는 게 아니라, 권한과 신뢰 구조를 먼저 정의해야 한다는 얘기였다.

미국에서 처음 가본 컨퍼런스였고, 밥도 잘 줬고, 어디를 가나 AI 얘기뿐이었다. 하루 종일 들은 내용을 한 줄로 정리하진 못한 채 행사장을 나왔다. 다만 다음에 무언가를 만들 때, 어떤 권한을 줄지와 무엇을 믿을지를 먼저 그려봐야겠다는 생각만 남았다.