아마존 보안 문화 사례: BlackFoot·MadPot, COE, 5 Whys로 본 민첩성과 보안

핵심 메시지

• “보안을 중시하면 속도가 느려진다”는 통념과 달리, 발표자는 아마존이 혁신·민첩성과 보안을 함께 달성해 왔다고 말한다.
• 아마존의 보안은 회사 문화, 즉 리더십 원칙을 행동 강령으로 삼아 만든 “메커니즘”에서 나온다. 선한 의도에 기대지 말고 작동하는 장치를 만들라는 철학이다.
• 고객 집착의 사례로 BlackFoot(네트워크 매핑)와 MadPot(허니팟)을 통해 취약점 스캔 시도를 75% 이상 줄이고, 6개월간 2조 4천억 건의 악성 스캐닝을 차단해 모든 고객에게 무료로 제공한다.
• 주인 의식은 단일 책임자(STO)와 투피자 팀, 그리고 각 팀에 보안 전문성을 심는 “AWS Guardians”와 자유로운 문제 제기(에스컬레이션) 문화로 구현된다.
• 깊게 파고들기는 오류 수정 문서 COE와 토요타식 “5 Whys”로 근본 원인을 추적하며, 사람을 탓하기보다 시스템을 개선하는 데 초점을 둔다.

쉽게 이해하기

발표는 아마존의 사업 전반을 관통하는 “아마존 플라이휠”, 즉 고객 경험 개선이 매출을 키우고 규모의 경제로 더 싼 가격을 만든다는 선순환에서 출발한다. 클라우드 서비스인 AWS 역시 20년 가까이 성장해 왔는데, 이는 끊임없는 혁신·민첩성과 보안·규제를 함께 다뤘기 때문이라고 본다. 보통 보안을 강조하면 속도가 느려진다고들 하지만, AWS는 설계 단계부터 보안을 내장하고 200여 개 서비스에 보안을 기본 통합하며, 오랜 경험과 AI·자동화로 이를 뒷받침한다는 것이다.

첫 번째 원칙은 고객 집착이다. 초창기 “로우 플라잉 호크”라는 익명 사용자가 꾸준히 기능을 제안하자, 지출이 크지 않았는데도 그 의견을 소중히 여겨 그의 가명을 시애틀의 건물 이름으로 삼았다는 일화를 든다. 보안에서도 고객 입장에서 거꾸로 생각한다. 서버 포트 스캔 같은 공격은 WAF·Shield로 막을 수 있지만 고객은 막는 만큼 비용을 낸다. 그래서 공격을 원천 차단하고자, 인터넷과 클라우드 경계의 내부 네트워크 매핑 장치 “BlackFoot”(외부 IP를 내부 IP로 변환, 시간당 13조 건 이상 처리)과, 취약한 서비스인 척 공격자를 유인해 정보를 식별하는 허니팟 “MadPot”을 운영한다.

이 장치들로 식별한 공격자 IP를 차단해, 취약점 탐지 시도를 75% 이상 줄였고 지난 6개월간 2조 4천억 건의 악성 스캐닝 요청을 막았다. 더 중요한 점은 이 보호가 인터넷에 연결된 모든 리전에서 모든 AWS 고객에게 무료로 제공된다는 것이다. 고객이 일일이 비용과 수고를 들이기 전에 플랫폼이 먼저 위협을 걷어내는, 고객 관점의 역발상 사례다.

두 번째 원칙은 주인 의식이다. 렌터카보다 자기 차를 더 아끼듯, 보안도 주인의식에서 시작된다. 아마존에는 특정 주제의 지표·의사결정·변화를 한 사람이 책임지는 “단일 책임자(STO)” 개념과, 피자 두 판으로 끼니를 해결할 만큼 작고 자율적인 “투피자 팀”이 있다. 이 팀 구조는 거대한 단일 웹서비스를 작은 서비스로 쪼갠 마이크로서비스 아키텍처로 이어졌다. 보안에서는 각 서비스 팀에 보안 전문성을 심는 “AWS Guardians”가 스프린트 계획부터 보안 검토까지 전 단계에 참여하고, 문제가 생기면 즉시 알리는 자유로운 에스컬레이션 문화로 보안 팀이 신속히 소유권을 넘겨받아 해결 시간을 단축한다.

세 번째 원칙은 높은 기준이다. 작은 팀이 제품에만 집중하도록 빌드 시스템 “Brazil”, 배포 시스템 “Apollo”, 커밋부터 프로덕션까지 자동화하는 “Pipelines” 같은 셀프서비스 도구를 제공하는데, 이는 훗날 CodeBuild·CodePipeline 같은 AWS 서비스의 모태가 됐다. 최근엔 생성형 AI 코딩 도구 “Amazon Q Developer”로 생산성을 높인다. 사내 자바 업그레이드 프로젝트에서는 5명이 이틀 만에 1천 개의 프로덕션 앱을 자바 17로 올렸고(앱당 평균 10분), 전사적으로는 3만 개 프로젝트에서 약 4,500년치 개발 시간과 2억 6천만 달러를 절감했다고 한다. 보안 검토를 자동 트리거해 패치를 클릭 한 번으로 병합하는 등, 평균 해결 시간을 40% 이상 줄인 사례도 소개한다. 네 번째 원칙은 깊게 파고들기(딥다이브)다. “선한 의도에 기대지 말고 일이 되게 하는 메커니즘을 만들라”는 말처럼, 반복되는 장애·보안 문제는 오류 수정 문서 “COE(Correction of Errors)”로 다룬다. 토요타식 “5 Whys”로 표면적 원인 너머 근본 원인까지 검증 가능한 사실로 추적하고(2018년 서울 리전 장애의 수동 작업 실수 사례 포함), COE를 임원 운영 회의에서 추첨 방식으로 검토하며, 사람을 탓하기보다 시스템을 고치도록 설계해 잘 쓴 COE 작성자가 승진하기도 한다.

주요 인사이트

• 보안과 속도는 양자택일이 아니다. 설계 단계의 보안 내장과 자동화가 있으면 둘을 함께 추구할 수 있다는 것이 발표의 전제다.
• 문화는 구호가 아니라 메커니즘일 때 작동한다. 리더십 원칙을 채용·평가·회의·문서에까지 녹여 “살아 있는 규범”으로 만든 점이 핵심이다.
• 플랫폼이 먼저 막으면 고객 비용이 준다. BlackFoot·MadPot로 위협을 원천 차단하고 이를 전 고객에게 무료 제공하는 것은 고객 관점 역발상의 구체적 결과다.
• 실패를 벌하지 않고 학습으로 전환하는 COE·5 Whys는, 문제를 숨기지 않고 드러내 시스템을 개선하게 만드는 안전한 회고 장치다.

자주 묻는 질문

관련 AI 소식