국내 대표 디지털 자산 거래소 빗썸이 금융권 규제 환경에서 Claude Code를 Amazon Bedrock 백엔드로 안전하게 도입한 실전 사례. 발표는 마상범(AWS) → 고주호(빗썸 DevOps 팀장) → 백길선(빗썸 클라우드 보안 팀장) 순.

Part 1. 마상범 (AWS) — Claude Code on Amazon Bedrock

1. 왜 백엔드 구성이 중요한가

마상범 SA는 한 줄로 시작했다.

"강력한 도구를 통제·구성·관리 없이 직원에게 그냥 맡기면, 보안·규제·비용의 리스크에 직면한다."

Claude Code는 개인 구독으로는 큰 무리가 없다. 다만 기업·특히 금융권에서는 다르다. 오늘 세션의 출발점이자 결론이 이 한 줄.

---

2. Claude Code와 Amazon Bedrock

Claude Code — 터미널 기반 AI 어시스턴트. 로컬에 설치되어 코딩뿐 아니라 다양한 작업을 Claude 모델 기반으로 수행.

Amazon Bedrock — AWS의 대표적 생성형 AI 서비스. 생성형 AI 모델 호출을 위한 API + RAG + 에이전트 구축 + 보안·거버넌스 기능까지 통합. 이 세션에서 기억해야 할 점은 단일 API로 100개 이상의 Foundation Model을 AWS 인프라 위에서 제공한다는 사실.

Bedrock은 Anthropic의 Claude 모델을 같은 가격·같은 출시일에 제공한다. 단일 리전 / 교차 리전 / 글로벌 엔드포인트로 가용성을 확보.

---

3. 백엔드 교체 — 이 한 줄이 전부

원래 Claude Code는 터미널에서 claude 명령어 실행 → Anthropic 계정 로그인 → Anthropic을 LLM 프로바이더로 사용.

그런데 Claude Code는 LLM API 제공자를 Amazon Bedrock으로 구성할 수 있는 옵션을 제공한다.

이 옵션 하나로 Anthropic이 아닌 Bedrock과 통신해서 툴을 사용하게 된다. 2026년 4월 출시된 Claude Desktop App의 Claude Code도 같은 방식이 적용 가능.

---

4. 백엔드 구성이 기업·금융권에 중요한 3가지 이유

1. 프라이빗 네트워크 — 내부망에서 외부 AI 호출이 인터넷을 경유하지 않고 전용선 / VPN으로 프라이빗 연결
2. AWS 기반 로깅·감사 — CloudTrail, CloudWatch 등 기존 AWS 서비스 그대로 활용
3. API 사용량 기반 과금 — 팀별·개인별 비용 추적과 통제

세 가지 모두 자세한 구현은 이어지는 빗썸 두 팀장의 발표에서.

---

Part 2. 고주호 (빗썸 DevOps 팀장) — 도입 배경과 아키텍처

5. 빗썸이라는 회사

• 2014년 출범, 국내 대표 디지털 자산 거래소
• 300명 이상의 IT 인력, 24시간 365일 무중단 서비스
• 금융당국 가상자산 사업자(VASP) 신고 완료 → 금융권 수준의 보안·컴플라이언스 체계 운영
• 기술: MSA 기반 AWS 클라우드 네이티브 + DevOps 문화 + 빠른 개발·배포 사이클

"빠른 속도 + 금융권 수준의 통제 — 두 가지를 동시에 충족하는 것이 AI 도입의 핵심 전제 조건이었다."

---

6. AI 도구 도입 배경

세 가지 압력이 동시에 작용했다.

1. 현업 수요 급증 — AI 도구에 대한 내부 요구가 빠르게 증가
2. 전사 관리 필요성 — 다양한 AI 도구 사용이 빠르게 확산되면서 관리 필요
3. 개발 생산성 — AI 기반 생산성 향상이 조직 차원의 중요 과제로 선정

개발자에게 좋은 도구를 제공하는 것이 경쟁력이라는 공감대 + 경영진 차원의 지원이 더해져 빠른 추진이 가능했다.

---

7. Shadow IT — 가장 큰 리스크는 "감사 추적 불가"

공식 도구 제공 전, 현장에서는 이미 개인 계정으로 ChatGPT·Claude를 쓰고 있었다.

• 소스 코드·내부 설계 문서 등 민감 정보가 외부 AI 서비스에 입력될 잠재 리스크
• 어떤 도구가 사용되고 있는지, 민감 정보 입력 가능성은 없는지 회사 차원에서 확인·추적 불가
• 보안·컴플라이언스 환경에서 감사 추적 불가가 그 자체로 가장 큰 리스크

"Shadow IT는 단순히 금지한다고 해결되는 문제가 아니다. 더 안전하고 편리한 공식 대안을 제공해야 한다."

이 결론이 빗썸의 출발점이었다. 회사 기반 공식 AI 도구 + 정책 기반 감사 로그 + 통제 가능한 경로의 아키텍처.

---

8. 도구 평가 — 왜 Claude Code 였나

내부 개발자 대상으로 AI 코딩 어시스턴트를 비교 평가했다.

코드베이스 탐색 + CLI 통합이 결정적이었다. (평가 시점에 Codex 미출시 — 출시됐다면 비등한 평가를 받았을 것)

"좋은 도구만으로는 부족하다. 금융 규제 안에서 안전하게 쓸 수 있어야 한다." — 여기서 보안 요구사항 정의가 시작된다.

---

9. 5대 보안 요구사항

1. SSO 기반 인증 — 개별 API 키 방식은 키 관리·권한 회수의 한계. 사내 계정 체계 연동 필요
2. 프라이빗 네트워크 — LLM API 호출이 인터넷을 직접 경유하지 않는 통제 가능한 경로
3. 감사 로그 체계 — 누가 어떤 모델을 사용했는지 추적, 사고 대응 가능
4. 예산 관리 — 팀별·개인별 사용량 확인, 비용 과도 증가 통제
5. 프롬프트 필터링 — 민감 정보·정책 위반 가능 입력의 실시간 탐지·차단

→ 이 다섯 가지를 가장 현실적으로 충족하는 도구가 Claude Code on Amazon Bedrock.

---

10. 옵션 비교 — Max vs Enterprise vs Bedrock

→ Bedrock 단독으로는 사용자 인증·예산 관리 같은 중앙 관리 레이어가 부족하다는 점 때문에 Bedrock 기반 LLM Gateway 자체 구축이 가장 현실적인 선택지로 정리.

---

11. 초기 POC 아키텍처

• 개발자 PC → Claude Code → AWS SSO 인증 → IAM Role 기반 Bedrock 직접 호출
• 네트워크: Direct Connect + PrivateLink 전용선

이 구조만으로도 Shadow IT 해소 + 프라이빗 네트워크 구성이라는 초기 목표는 달성. 다만 팀별 비용 추적, 상세 사용 이력 관리 같은 중앙 통제 기능은 부족. 규모가 작으면 충분하지만, 빗썸처럼 세밀한 통제가 필요한 환경엔 한계.

---

12. LLM Gateway 도입 — 단순 프록시가 아닌 거버넌스 레이어

Claude Code와 Bedrock 사이에 LLM Gateway를 두었다. 사내 인증 연동 + 비용 추적 + 사용 정책 적용 + 감사 로그 + 사용 이력 관리를 중앙화.

Tip: LLM Gateway에 부여할 IAM 정책은 Bedrock InvokeModel 권한만 있으면 된다. 처음부터 서버에 올리지 말고 개발자 로컬에서 환경 변수로 세팅·검증 후 서버 단으로 올리는 걸 추천.

---

13. 오픈소스 검증 파이프라인 — 공급망 공격 대응

LLM Gateway는 오픈소스 기반. 최근의 오픈소스 공급망 공격을 고려해 자동화된 검증 파이프라인을 구축했다.

Git Upstream → 사내 Git Mirror → GitLab SAST 취약점 분석 → AI 코드 리뷰 → 보안실 담당자에게 리포트 자동 전달 → 직접 확인·승인 → 사내 패키지 저장소 → LLM Gateway 서버 배포

승인이 완료된 버전만 프로덕션에 올라갈 수 있는 구조.

---

14. LLM Gateway의 4가지 역할

1. API 호환성 — 기존 Claude Code 사용 방식 그대로 연결, 개발자 입장에서 차이 없음
2. 인증 통합 — 사내 SSO + JWT 기반 인증 그대로 재사용
3. 모델 라우팅 — 보안 검토 완료된 허용 모델로만 요청 라우팅
4. 비용 관리 — 조직 단위 / 개인 단위 예산·사용량 관리

결과적으로 단순 프록시가 아니라 생성형 AI 사용 정책과 운영의 중앙 관리 레이어.

---

15. 운영 아키텍처

초기 POC는 Claude Code 사용에 초점이었다면, 현재 운영 환경은 JWT 기반 사내 인증 체계와 연동해 Gateway가 공통 진입점. Claude Code뿐 아니라 Codex 등 다른 AI 서비스도 동일 Gateway로 관리 가능. Aurora PostgreSQL로 사용자·예산·사용 이력 운영 데이터를 중앙 관리.

SSO 인증 흐름

1. 개발자가 Claude Code 실행 → 헬퍼 스크립트가 자동으로 브라우저를 열어 사내 인증 서버에 인증 요청
2. 평소 쓰던 사내 인증 절차 그대로 → 토큰 발급
3. 토큰 검증 후 토큰에 포함된 사용자 정보로 요청자 식별
4. 개발자는 별도 API 키 운영·관리 불필요, 기존 사내 계정으로 Claude Code / Codex 사용

요청 처리 흐름

• 인증 완료 → 예산 정책 확인 (팀/개인 잔여 예산, 초과 시 즉시 차단)
• 모델 라우팅 (허용 모델만 통과, 미승인 모델 원천 차단)
• Aurora PostgreSQL에 프롬프트·사용 현황·예산·통계·멤버·AI 커버리지 누적
• 실시간 대시보드로 관리자와 구성원 모두 가시화 (팀별 사용량, 이상징후, 개인 예산 대비 현황)

---

16. 자동화 사례와 조직 자산화

운영 환경에선 이 구조 위에 다양한 자동화가 얹혀 있다.

• GitLab MR 자동 코드 리뷰 — MR 생성 순간 Claude Code 기반 풀 컨텍스트 코드 리뷰 + 인라인 코멘트가 자동 적용. 개발자가 별도 리뷰 요청을 하지 않아도 코드 변경 맥락 전체를 기반으로 자동 리뷰

• Claude Skill 카탈로그 — 잘 정리된 프롬프트와 Claude Skill을 조직 단위로 공유. 코드 리뷰 / 테스트 / 배포 / 문서화 작업 유형별로 카탈로그화 → 특정 팀의 코드 리뷰 스킬을 다른 팀이 그대로 재사용 가능

"몇몇 개인이 잘 활용하는 AI가 아니라, 조직 전체가 함께 학습하고 재사용할 수 있는 AI 활용 플랫폼."

---

17. 도입 타임라인 — 3개월

속도의 비결: 보안팀과 AWS AM·SA가 초기 설계 단계부터 함께 고민하고 참여. 처음부터 같은 테이블에서 설계 방향을 맞춰나간 점이 결정적.

---

18. 왜 Amazon Bedrock 이었나 — 한 장 요약

• VPC + Direct Connect → 프라이빗 네트워크
• IAM → 접근 제어
• CloudTrail + CloudWatch → API 사용 이력·운영 로그

핵심은 새 보안 체계를 별도 구축이 아니라, 기존 AWS 운영 모델 안으로 AI 서비스를 자연스럽게 편입시킨 것. 그래서 3개월에 도입이 가능했다.

---

19. 도입 후 변화 5가지

1. Shadow IT 해소 — 개인이 알아서 쓰던 외부 AI 도구를 회사 공식 플랫폼으로 흡수. 데이터 유출 리스크 사라지고 모든 사용 이력 감사 추적 가능
2. 개발 생산성 향상 — 코드 리뷰 시간 단축, 디버깅·문서화 효율 상승
3. AI 기반 코드 리뷰 자동화 — GitLab MR 생성 순간 Claude Opus 4.7이 변경 파일과 연관 파일까지 풀 컨텍스트 분석 → 인라인 코멘트와 요약 노트 자동 추가 (모두 LLM Gateway 경유)
4. 비용 가시성 — 팀별·개인별 사용 비용 실시간 추적, 월 단위 예측
5. 보안·컴플라이언스 — 위 4가지를 가능하게 한 토대

결론: 통제 가능한 환경에서 최고의 AI 도구를 안전하게 활용하고, 조직 자산으로 축적한다.

---

Part 3. 백길선 (빗썸 클라우드 보안 팀장) — 보안과 거버넌스

20. 가상자산 거래소의 규제 스택

빗썸은 이미 규제 스택이 촘촘하다. ISMS-P · 개인정보보호법 · 특금법 위에 AI 리스크가 한 층 더 올라가는 구조.

대표적 우려 4가지.

• AI 사용 시 입력 정보의 외부 유출 가능성
• 입력·응답이 학습에 재사용될 가능성
• 네트워크 경로 통제 가능성
• 권한·감사가 적절히 이루어지는 환경인가

"일단 써보고 고치자" 는 매우 위험한 생각이다. 큰 힘에는 큰 책임이 따른다.

---

21. AI 보안 거버넌스 5대 기준 — 이 발표의 뼈대

발표에선 5대 기준을 두 슬라이드로 나눠 보여줬다.

1/2 — 기준 1, 2, 3

1. 데이터 프라이버시와 격리 — 프롬프트·응답의 인터넷 미경유 + 학습 재사용 차단 보장
2. 인프라 및 네트워크 보안 — Direct Connect, PrivateLink 기반 전용 경로
3. 접근 제어와 계정·단말 통제 — IAM, SCP, Permission Boundary로 기술적 강제 + SSO/OAuth2 기반 강한 인증

2/2 — 기준 4, 5

4. 감사·모니터링·포렌식 — CloudTrail + 앱 로그 추적, 프롬프트/응답 이력 보존, 이상 행동 탐지·차단
5. AI 리스크 거버넌스 — 도입 목적·사용 범위·금지 행위 정의, 서비스별 리스크 평가·승인 프로세스, 주기적 효과성 검증과 개선 루프

---

22. 기준 1. 데이터 프라이버시 — "AI 벤더가 우리 데이터로 무엇을 하는가"

가장 먼저 확인한 질문. AWS 공식 약관은 명확했다.

"Amazon Bedrock은 사용자의 프롬프트와 완성된 내용을 저장하거나 기록하지 않습니다. AWS 모델 훈련에 사용하지 않으며 제3자에게 배포하지 않습니다."

외부 SaaS형 AI 서비스 중에는 학습 동의가 기본값인 경우가 있어 기업 입장에선 그 자체가 리스크. 명시적 약관 존재 = Bedrock 선택의 핵심 이유.

---

23. 기준 2. 인프라·네트워크 — AWS Organizations + 인터넷 구간 제로

빗썸은 Control Tower 기반으로 OU를 세밀하게 나눠 운영. 이유는 SCP의 한계 때문.

• AWS Organizations SCP는 타겟 OU 개수와 정책 길이가 제한
• 2026-05-15 SCP 한도 완화 — 타겟 OU 5개 → 10개, 정책 길이 ~5,000자 → ~10,000자 (2배)
• 그럼에도 세밀한 적용을 위해 OU를 환경·용도에 맞게 세분화 + 각 OU에 특화된 SCP를 붙이는 전략
• AI 관련 계정은 별도 AIOps OU로 분리 → AI 호출 SCP를 집중 적용

네트워크 경로는 인터넷 구간이 제로.

개발자 PC → AWS Direct Connect 전용선 → LLM Gateway → Bedrock Runtime Endpoint → Bedrock 모델

금융권에선 인터넷 미경유는 선택이 아니라 필수. 외부에 노출된 지점이 구조적으로 존재하지 않는다.

---

24. 기준 3. 접근 제어 — "기술적으로 할 수 없는 구조"

권한 레이어 통제의 핵심.

• SCP로 Bedrock 모델 호출은 AIOps 계정의 LLM Gateway를 통해서만 허용
• 다른 모든 계정에서의 직접 호출은 SCP 레벨에서 원천 차단
• AIOps 계정 내에서도 허용 모델 / Gateway 인스턴스 Role / 지정 리전에 한해서만 InvokeModel 권한
• 직원이 개인 자격증명으로 Bedrock API 직접 호출 시도 → IAM + SCP 두 레이어에서 동시 차단

"정책으로 하지 마세요" 가 아니라 "기술적으로 할 수 없는 구조" 를 만든 것이 핵심.

단말 인증 — 생체 / Verify Push

서버 레벨 통제 외에 단말 인증도 강화.

1. 터미널에서 claude 입력
2. 세션 미생성 + 랜덤 활성화 코드와 함께 브라우저 팝업
3. 사전 설정한 생체 인증 또는 Verify Push로 아이덴티티 최종 확인
4. 인증 완료 후 Claude 세션 생성

→ 누가 어떤 단말에서 시작했는지 기록, 비인가 단말에선 인증 자체가 불가능.

---

25. 기준 4. 감사·모니터링 — 3중 필터링

사용자 프롬프트에 대한 1·2·3차 필터링.

세 레이어가 서로 보완하면서 어느 하나가 뚫려도 나머지가 막는 구조.

Bedrock Guardrails 상세

• 업무 범위 밖 주제 차단 — 예: "비트코인을 살까 이더리움을 살까" → "용도에 맞지 않는 프롬프트입니다" 메시지 반환
• 민감정보 필터 — 이메일·전화번호·카드번호·계좌번호 + 사내 DLP 룰까지 Guardrails에 추가
• 계정 레벨에서 강제 적용 → 직원의 잘못된 설정·실수에도 조직 정책이 자동 보호

통합 SIEM — 5개 로그 소스

AI를 쓴다는 건 새 로그가 생긴다는 뜻. 5개 로그를 자체 SIEM으로 통합 관제.

1. CloudWatch / CloudTrail Bedrock 호출 로그
2. Guardrails 감지·차단 룰 + 프롬프트 내용
3. LLM Gateway 사용자 비용 로그
4. VPC Flow Logs (네트워크 트래픽)
5. 기타 사내 로그

→ "누가 언제 어느 경로로 AI를 사용하다 어떤 프롬프트를 입력해 어떤 정책으로 탐지·차단되었는지" 통합 추적.

---

26. 기준 5. AI 리스크 거버넌스 — 프로세스

기술 통제 외에 프로세스도 만들었다.

1. 사용 신청서 제출 + 교육 이수 후 사용 가능
2. 사용 가이드 — 어떤 정보를 입력하면 안 되는지, AI 응답을 그대로 사용하면 안 되는 상황은 무엇인지. 핵심 원칙: "AI 출력은 항상 검증 대상이다"
3. 정기 점검 — 사용 목적 이탈 여부 확인, SIEM 기반 이상 패턴 탐지·소명 절차, 승인된 단말에서만 접근 허용

3축 책임 분담

→ 문제가 생겼을 때 "누가 봐야 하는 문제인가" 즉시 결정 가능.

---

27. 5대 기준 정리 — 보안은 설계다

• 데이터 프라이버시 & 격리
• 네트워크·인프라 보안
• 접근 제어·단말 통제
• 감사·모니터링·포렌식
• AI 리스크 거버넌스

"이 다섯 가지는 서로 독립적이지 않다. 하나라도 빠지면 나머지가 흔들린다." "보안은 제품이 아니라 설계다."

---

28. 향후 로드맵 3가지

빗썸에서 AI 도구 지원은 직원의 복지로 자리 잡았다. 이 복지를 더 강화하기 위한 세 가지 방향.

1. Claude Code on AWS 고도화 — Desktop App의 Claude Code 등 신규 기능을 순차 도입. Skill 기반 팀별 맞춤 시스템 프롬프트 자동 생성으로 사용자 가이드가 자연스럽게 반영되도록
2. 멀티모델 사용 전략 — Bedrock의 멀티모델 지원을 활용해 OpenAI Codex 추가 도입 검토. 기존 LLM Gateway 라우팅으로 태스크별 모델 자동 분배. 보안 체계는 그대로 → 새 모델을 빠르고 안전하게 온보딩
3. AI 기반 DevOps 자동화 심화 — MR 코드 리뷰를 시작으로 개발 / 배포 / 운영 전 사이클에 AI 내재화

"한 번 잘 만들어 놓으면 그 위에 무엇이든 올릴 수 있다. 이것이 처음부터 빗썸이 보안에 투자한 이유다."

---

정리 — 듣고 남은 인상

이번 세션이 끝나고 가장 오래 머릿속을 맴돈 한 줄은 백길선 팀장님의 "정책으로 하지 마세요가 아니라, 기술적으로 할 수 없는 구조를 만들었다"였다. 보안 정책을 문서로 박아두는 회사는 많은데, 그걸 IAM + SCP로 물리적으로 차단되도록 강제한다는 게 진짜 금융권 보안의 본질이라는 걸 한 문장으로 박아둔 느낌이었다. 사내 룰북에 적어두기만 하면 누구나 우회할 수 있지만, AWS Organizations SCP 차원에서 차단되면 그 자체가 불가능해진다.

발표의 출발점도 좋았다. 고주호 팀장님이 "Shadow IT는 금지로 해결되지 않는다" 라고 잘라 말한 부분 — 외부 ChatGPT·Claude를 막는다고 안 쓰는 게 아니라 더 안전하고 편리한 공식 대안을 만들어서 자연스럽게 흡수한다는 사상 자체가 인상 깊었다. 이건 보안팀의 흔한 접근(차단)이 아니라 DevOps팀이 주도한 사고방식 같았고, 빗썸에서 이게 가능했던 이유는 보안팀-DevOps팀-AWS SA가 처음부터 같은 테이블에 앉아 설계했기 때문이라는 게 발표 곳곳에 드러났다.

기술적으로 와닿은 포인트들을 정리하면 이렇다.

• "백엔드 교체" 한 줄의 위력: Claude Code의 LLM API 제공자를 Anthropic에서 Amazon Bedrock으로 바꾸는 것 — 그 단순한 옵션 변경 하나로 프라이빗 네트워크 + AWS 로깅 + API 과금 세 가지가 동시에 풀린다는 점이 너무 깔끔했다. "복잡한 보안 아키텍처가 아니라 이미 있는 AWS 운영 모델 안으로 AI를 편입시킨 것" 이라는 마상범 SA님의 표현이 정확했다.

• LLM Gateway = 단순 프록시가 아니라 거버넌스의 중심: Bedrock 단독으론 사용자 인증·예산 관리 같은 중앙 관리 레이어가 부족하니까, 그 사이에 LLM Gateway를 자체 구축해서 SSO·예산·라우팅·감사 로그를 모두 모아놨다는 게 인상적이었다. 단순한 reverse proxy가 아니라 생성형 AI 운영의 중앙 정책 엔진이라는 표현이 어울리는 구조.

• 오픈소스 공급망 공격을 정공법으로: LLM Gateway 자체가 오픈소스 기반이니까, 그걸 그냥 쓰지 않고 — Git Upstream → 사내 Mirror → GitLab SAST 취약점 분석 → AI 코드 리뷰 → 보안실 담당자 직접 확인·승인 → 사내 패키지 저장소 → 서버 배포. "승인 없이는 한 줄도 안 올라간다" 는 원칙이 그대로 보였다.

• 3중 필터링 — 다층 방어의 정석: LLM Gateway 커스텀 필터 (1차) + AWS Organizations SCP (2차) + Bedrock Guardrails (3차). 세 레이어가 서로 보완해서 어느 하나가 뚫려도 나머지가 막는 구조. 특히 Bedrock Guardrails를 Organizations 정책으로 조직 전체에 강제 적용한다는 점 — 개별 앱 개발자가 실수로 설정을 빼먹어도 자동 보호되는 게 진짜 거버넌스다.

• 단말 인증까지 생체/Verify Push: 서버 레벨 통제만으로 끝내지 않고, claude 명령어 입력 시 랜덤 활성화 코드 + 생체 인증 / Verify Push로 한 번 더 잠갔다. 누가 어떤 단말에서 시작했는지까지 기록이 남는다는 게 — 금융권 감사 추적 관점에서 정말 꼼꼼했다.

• 3개월 만에 도입 완료: 보통 금융권에서 새 도구 들어가는 데 1년 가까이 걸리는데, 빗썸은 11월 검토 → 12월 POC → 1월 LLM Gateway → 2~3월 안정화·운영 도입. 비결은 보안팀이 나중에 검토받는 게 아니라 처음부터 설계 단계에 들어왔던 것. 이건 조직 문화의 결과지 단순 기술 선택의 결과가 아닌 것 같았다.

• AI 사용을 조직 자산으로 축적: Claude Skill 카탈로그를 팀 단위로 공유하면서, 한 팀이 만든 코드 리뷰 스킬을 다른 팀이 그대로 가져다 쓸 수 있게 만든 부분이 좋았다. 개인 노하우 → 조직 전체의 학습·재사용 플랫폼으로 끌어올린 게 발표 후반부의 핵심 메시지였다.

마지막에 가장 와닿았던 메시지는 "보안은 제품이 아니라 설계다"였다. 한 번 잘 설계된 아키텍처 위에는 Codex든 Desktop App의 Claude Code든 새 LLM이든 무엇이든 안전하게 올릴 수 있다는 것 — 이게 발표 내내 일관되게 깔려 있던 사상이었던 것 같다. 그리고 마침 발표 일주일 전(2026-05-15)에 AWS Organizations SCP 한도가 5→10개·5K→10K자로 완화됐는데, 이 최신 변경사항까지 발표에 반영해 정확한 메시지를 전달한 디테일에서 발표자들의 준비도가 보였다.