AWS에서 보낸 20년, 한 번도 "내 일이 아니"라고 한 적 없다
(daemonology.net)- FreeBSD 보안 담당자이자 Tarsnap 창업자인 Colin Percival이 2006년 AWS 첫 계정 생성부터 현재까지 20년간, 공식 직원이 아닌 외부 기여자 입장에서 FreeBSD EC2 지원 구축, 보안 취약점 선제 발견·보고, 서비스 설계 피드백까지 AWS 발전에 폭넓게 관여해온 과정을 연대순으로 회고한 글
- 초기 AWS는 서비스별로 별도 활성화가 필요했으며, 최초 기본 활성화된 서비스는 Amazon SQS와 대부분 알려지지 않은 Amazon E-Commerce Service였음
- FreeBSD를 EC2에서 구동하기 위해 Xen 버전 호환성, PAE 지원, HVM 전환 등 수년에 걸친 기술적 난관을 해결해야 했으며, 2010년 t1.micro에서 최초 가동에 성공
- AWS 요청 서명 체계의 정규화 충돌 취약점, IMDS를 통한 자격증명 노출 위험(2019년 Capital One 침해 사고로 현실화), Seekable OCI 보안 문제 등 다수의 보안 이슈를 선제적으로 발견·보고
- 2024년부터 Amazon의 GitHub Sponsors 후원을 받아 FreeBSD/EC2 유지보수를 지속하고 있으며, 외부 기여자로서 내부 시스템 접근 없이도 Amazon 엔지니어들의 협력을 통해 성과를 이룬 사례
AWS 계정 생성과 초기 서비스
- 2006년 4월 10일 Amazon S3 발표를 보고 첫 AWS 계정을 생성, 온라인 스토리지 서비스에 대한 관심이 계기였으며, 이전부터 1998년부터 HTTP 기반 웹 서비스를 구축해온 경험 보유
- 초기 AWS에서는 각 서비스를 별도로 계정에 활성화 요청해야 했으며, 기본 제공 서비스는 Amazon SQS와 Amazon E-Commerce Service(Amazon 제휴사용 제품 카탈로그 API)뿐이었음
- Amazon E-Commerce Service가 사실상 최초의 AWS 서비스였으나 대부분 알려지지 않았고, AWS 역사에서도 조용히 삭제됨
보안에 대한 초기 관심과 피드백
- FreeBSD Security Officer 경험을 바탕으로 AWS의 보안 구조에 즉시 관심을 가졌으며, AWS 요청은 API 키로 서명되어 인증과 무결성을 보장하지만 응답에는 서명이 없다는 점을 지적
- 당시 HTTP를 통한 AWS 요청이 일반적이었기 때문에 응답 변조 가능성이 실질적 위험이었으며, TLS 전환 이후에도 엔드투엔드 서명이 전송 계층 보안보다 우수하다는 입장 유지
FreeBSD on EC2 — 초기 도전
- Amazon EC2 출시 직후 FreeBSD 구동을 목표로 Jeff Barr를 통해 Amazon 내부 담당자와 연결, 2007년 초 첫 Amazon NDA 체결
- 당시 Amazon은 팩스를 사용하고 있었으나, 팩스 미보유로 인해 우편으로 서명 원본을 발송하면서 첫 브리핑이 지연됨
- EC2는 초기에 커스텀 커널 지원 없이 출시되었으며(현재 AWS Lambda와 유사한 방식), 2007년 11월 Red Hat 지원과 함께 이 기능이 활성화되면서 FreeBSD 계정에도 내부 "Amazon Kernel Images 게시" API 접근 허용
Xen 보안 감사와 사이드 채널 공격 경고
- 2007년 3월 Amazon 담당자에게 Xen의 보안 감사 필요성을 제기, 적합한 감사자를 모를 때 Tavis Ormandy를 추천
- 같은 해 Tavis가 Xen 취약점 2건(CVE-2007-1320, CVE-2007-1321)을 보고했으나, 해당 추천과의 연관성은 불분명
- Jeff Barr의 Second Life 내 AWS 사용자 모임에서 읽기 전용 루트 디스크와 재부팅 시 메모리 초기화 보장 기능을 요청, 신뢰할 수 없는 코드 실행(FreeBSD 패키지 빌드) 시나리오를 위한 것이었으며, EC2 Instance Attestation이 18년 후 출시
- 2012년 re:Invent에서 HyperThreading을 이용한 RSA 키 탈취 연구를 EC2 Principal Engineer에게 설명하며, 같은 코어의 두 스레드에서 EC2 인스턴스를 병렬 실행하지 말 것을 강력 권고
- 이 권고가 많은 EC2 인스턴스 패밀리가 "medium" 크기를 건너뛰고 바로 2개 vCPU("large")로 시작한 이유로 전해짐
Eventual Consistency와 이론적 제안
- 2007년 말 Amazon 내부에서 널리 읽힌 블로그 포스트에서 Eventual Consistency 문제를 지적하고, Eventually Known Consistency라는 약간 더 강한 모델을 주장
- CAP 정리에서 "A"(가용성) 경로를 유지하면서도 내부 상태를 노출해 정상 경로에서 "C"(일관성)도 확보 가능한 모델
- Amazon S3는 이후 가용성 최적화에서 일관성 최적화로 전환했고, DynamoDB는 Eventual/Strongly Consistent 읽기 선택권 제공
Xen 호환성 문제와 FreeBSD 부팅 실패
- 2008년 초 Kip Macy가 Xen PAE 지원 FreeBSD 커널을 작성, 내부 AMI 도구를 FreeBSD로 포팅하는 데 수 주 소요
- Ruby 스크립트가 bash 스크립트를 생성·실행하는 구조에 대해 언어 선택 재고 필요성 언급
- FreeBSD AMI가 EC2에서 부팅되지 않았으며, EC2가 사용하던 Xen 3.0이 FreeBSD VM 코드의 재귀 페이지 테이블을 지원하지 않는 버그가 원인
- Xen 3.1에서 수정되었으나 안정 ABI 미제공으로 기존 AMI 호환성 유지를 위해 Amazon은 Xen 3.0 유지를 선택
AWS 서명 취약점 발견과 수정
- 2008년 4월 Tarsnap 베타를 위해 Amazon SimpleDB를 사용하면서 서명 체계의 정규화 충돌을 발견
- 당시 Amazon에 보안 이슈 보고 채널이 없어 Jeff Barr를 통해 전달
- Amazon은 Signature Version 2 설계 검토를 요청했고, 문서 모호성 수정, 설계 결정 교정, 계정 허용목록 추가 등을 거쳐 12월에 수정 완료
SimpleDB NextToken 보안 위생 문제
- 2008년 6월 SimpleDB의 NextToken 값이 단순 base64 인코딩된 Java 직렬화 객체임을 발견
- 내부 정보 유출 방지를 위한 암호화와 변조 방지를 위한 서명이 필요하다고 보고했으나 응답 없음
- 6개월 후 다른 엔지니어를 통해 재보고하여 내부 티켓으로 작성되었으나, 이후에도 공식 응답은 없었음
EBS 알파 테스트와 설계 피드백 타이밍
- 2008년 3월 EC2팀의 Matt Garman이 Elastic Block Storage(현 Elastic Block Store) 비공개 알파 초대
- 새 서비스에 대해 가장 유용한 피드백을 줄 수 있는 시점은 구축 이전 설계 단계이며, 수학·이론 배경에서 알파 테스트보다 설계 문서 검토가 더 효과적이라는 입장
Amazon 입사 면접 에피소드
- 2008년 Jeff Barr의 권유로 Amazon 입사를 고려, Al Vermeulen과 전화 면접에서 45분 중 30분을 예외 처리(exceptions)의 장단점에 대해 토론하는 데 소비
- 예외 처리가 캐주얼한 코드 검토에서 발견되기 어려운 버그를 만들기 쉬운 본질적으로 부적절한 에러 처리 방식이라는 입장 유지
IAM과 제한된 접근 키 — SigV4까지의 여정
- 2008년 11월 Seattle AWS Start-up Tour에서 Amazon 엔지니어와 직접 만나 제한된 AWS 접근 키 필요성을 논의
- 마스터 시크릿에서 서비스별로 키를 해시 파생하는 암호학적 파생 키 방식을 주장, Amazon 측은 규칙 기반 설계를 선호
- 2010년 1월 IAM 비공개 베타 초대, 2012년 SigV4 출시 시 파생 키 방식 채택
EC2 방화벽 문제와 Path MTU Discovery
- 2009년 EC2 기본 방화벽 규칙이 ICMP Destination Unreachable(Fragmentation Required) 메시지를 차단하여 Path MTU Discovery가 작동하지 않는 문제 발견·보고
- 2009년 12월 EC2 매니저가 해결안에 동의했으나, 실제 수정은 2012년 공개적으로 문제를 제기한 후 이루어짐
NetBSD를 통한 우회와 HVM 전환
- 2010년 초 EC2가 여전히 구 버전 Xen을 유지하자 NetBSD로 전환 시도, 1주일 만에 부팅·파일시스템 마운트·네트워크 설정·sshd 실행까지 성공
- 2010년 7월 Cluster Compute 인스턴스가 HVM을 지원하면서 FreeBSD에도 희망이 생겼으며, PV(준가상화)가 기술적 막다른 길임이 분명해짐
FreeBSD/EC2 최초 가동 — t1.micro
- 2010년 9월 출시된 t1.micro 인스턴스 패밀리가 내부적으로 Xen 3.4.2를 실행, FreeBSD 부팅을 가로막던 버그가 해소
- 2010년 11월 중순 FreeBSD/EC2 t1.micro 인스턴스에 SSH 접속 성공, 12월 13일 FreeBSD EC2 t1.micro 지원 공식 발표
인스턴스 유형 확대와 "Defenestration" 핵
- Amazon Solutions Architect가 더 큰 인스턴스를 원하는 FreeBSD 사용자를 연결해주어 Cluster Compute 인스턴스 지원 구현
- EC2가 실제로 어떤 OS가 실행되는지 모른다는 점을 이용해 defenestration(Windows 인스턴스 위장)을 통해 모든 64비트 인스턴스 유형에서 FreeBSD 사용 가능
- "Windows 세금"을 지불해야 했고 Amazon도 불만이었으나 고객 수요 충족에 필수적이었으며, 2014년 7월 T2 인스턴스가 HVM "Linux" 지원을 완비하면서 해당 핵 불필요
S3 라우터 하드웨어 장애 진단
- 2012년 4월 특정 S3 엔드포인트에서 SignatureDoesNotMatch 오류 등 다수의 요청 실패 발생
- 오류 응답의 StringToSign 값이 송신 값과 불일치하는 패턴에서 stuck bit(고착 비트)를 식별, traceroute와 수백만 건의 ping으로 경로상 특정 라우터의 하드웨어 장애를 특정
- AWS Developer Forums에 보고 후 Amazon이 며칠 내에 장애를 확인하고 하드웨어 교체
re:Invent 2012와 사이드 채널 공격 경고
- 첫 re:Invent는 기술 콘텐츠가 부족하고 정장 비율이 높았으나, 다수의 Amazon 엔지니어와 대면 교류 기회 제공
- Intel의 "가상 머신 보안" 발표자 VP가 사이드 채널 공격에 대해 모른다고 답한 후 EC2 부스에서 Principal Engineer에게 관련 연구를 직접 설명
FreeBSD/EC2의 공식화와 릴리스 엔지니어링
- 2015년 4월 FreeBSD/EC2 AMI 빌드 프로세스를 FreeBSD src 트리에 통합, 이미지 빌드를 FreeBSD 릴리스 엔지니어링 팀에 이관하여 개인 프로젝트에서 공식 FreeBSD 프로젝트로 전환
- 2020년 9월 FreeBSD Release Engineering Lead Glen Barber의 요청으로 Deputy Release Engineer 역할 수락
- 2022년 말 Glen이 폐렴으로 입원, 장기 후유증으로 복귀가 어려워지면서 2023년 11월 17일 FreeBSD Release Engineering Lead 직접 인수
- 주간 스냅샷 빌드, 일정 강화, 예측 가능한 빠른 릴리스 주기 확립, 연 4회 릴리스 관리
IMDS 보안 경고와 Capital One 침해 사고
- 2016년 10월 IAM Roles for Amazon EC2를 분석하고, 인증되지 않은 HTTP로 작동하며 "민감 데이터 저장 금지"를 문서에 경고하는 IMDS를 통한 자격증명 노출이 위험하다고 블로그에 게시
- 2019년 7월 Capital One이 정확히 이 위험을 악용당해 1억 600만 고객 정보 유출, 같은 해 11월 Amazon과 통화 후 2주 뒤 IMDSv2 출시
- IMDSv2는 특정 공격 경로의 완화이지 자격증명이 부적합한 인터페이스를 통해 노출되는 근본적 문제의 해결은 아니라는 입장
AWS Heroes 프로그램
- 2019년 5월 비Amazon인으로서 AWS에 중요한 기여를 한 사람을 인정하는 AWS Heroes 프로그램에 초대
- 프로그램이 주로 개발자 교육(블로그, YouTube, 워크숍) 기여자 중심인 가운데 이례적 선정이었으며, Distinguished Engineer와 Senior Principal Engineer의 추천으로 승인
UEFI 부팅과 BootMode=uefi-preferred
- 2021년 3월 EC2가 x86 인스턴스 UEFI 부팅 지원 추가, FreeBSD에서 UEFI 전환 시 16비트 모드 I/O 불필요로 부팅 시간 7초 단축
- 모든 인스턴스 유형이 UEFI를 지원하지는 않아 레거시 BIOS와 UEFI 모두 부팅 가능한 이미지를 위해 BootMode=polyglot 설정 요청
- 2023년 3월 BootMode=uefi-preferred라는 이름으로 구현
Seekable OCI 보안 이슈 발견과 수정 지연
- 2023년 8월 Heroes Summit에서 Seekable OCI 설계를 보고 특정 사용 사례에서 보안 주장이 성립하지 않는 문제 발견, AWS Security 팀에 보고
- 내부 수정 약속을 받았으나 실제 진행이 없었고, 2024년 re:Invent에서 재확인 요청, 2025년 1월 재보고 후 2023년 커밋이 우발적 데이터 손상만 방지하고 의도적 공격은 차단하지 못함을 확인
- 지적 후 빠르게 대응이 이루어져 2025년 2월 말까지 해당 기능이 대부분 고객에 대해 비활성화 처리, "major revision" 대기 중
Amazon 후원과 협력 모델
- 2024년 4월 FreeBSD/EC2 유지보수에 충분한 시간을 투입하지 못하고 있음을 Amazon 측에 알리고 자금 지원 요청, 수 주 내에 GitHub Sponsors를 통한 주 10시간·1년 후원 확정
- 다수의 미해결 이슈를 처리한 후 6개월 휴지기(대부분 무급으로 FreeBSD 15.0 릴리스 엔지니어링에 전념)를 거쳐 두 번째 12개월 후원 시작
- 20년간의 기여가 혼자만의 성과가 아님을 강조하며, 내부 AWS 시스템 접근 권한 없이도 Amazon 엔지니어들이 티켓 작성, 내부 연락처 탐색, API 로그 조사, 기술 문서 확보 등 "원격 손" 역할을 수행
댓글과 토론
Hacker News 의견들
-
저자는 ‘Heroes는 사실상 무급 Amazon 직원’이라는 농담을 했지만, 그건 농담이 아니라 현실임
나는 내 개인 연구를 공개하지 않음. 이미 충분히 효율적인 가치 추출 머신에 무료 R&D를 제공하고 싶지 않기 때문임
Amazon은 오픈소스의 경제적 전제를 무너뜨렸고, 그 결과 많은 프로젝트가 Business Source License로 전환하고 있음
이런 개발자들은 Amazon이 얼마나 탐욕스러운지 알고 있음. 결국 커뮤니티 기여가 초거대 기업의 무급 노동으로 귀결되고, Amazon은 관리형 서비스로 사용자를 흡수해 원 프로젝트의 지원과 커뮤니티를 약화시킴- Amazon이 내 코드를 쓰는 게 싫다면, 라이선스에서 Amazon을 명시적으로 제외하면 됨
“Amazon을 제외한 누구나 자유롭게 사용할 수 있다”라고 쓰면 Amazon은 법적 리스크 때문에 사용하지 않음
다만 필요하다고 판단되면 Amazon은 자체 버전을 새로 만들 가능성이 있음 - 대형 SaaS 기업들은 Business Source License가 있어도 API 인터페이스를 그대로 구현할 수 있음
Redis 사례처럼, API 표면에 대한 법적 보호가 명확하지 않음
예전에 Google v. Oracle 판례가 그런 보호를 세우려다 미뤄진 걸로 기억함 - AGPL이나 GPL3 같은 라이선스도 사용할 수 있음. 이런 라이선스는 hyperscaler들이 거의 금지함
사실 BSL을 택하는 회사들은 진정한 오픈소스 정신보다는 이미지 관리나 개발자 호감도 확보를 위해서만 공개했을 가능성이 큼 - 나는 “운 좋게도” 이런 문제를 깊게 고민할 만큼 똑똑하거나 중요한 사람이 아님
그래도 전적으로 동의함. 이제 내가 공개할 코드는 완전한 오픈소스이거나 완전한 비공개 둘 중 하나임
누군가가 그걸로 돈을 벌 가능성이 있으면 공개하지 않음
- Amazon이 내 코드를 쓰는 게 싫다면, 라이선스에서 Amazon을 명시적으로 제외하면 됨
-
대기업에 시간을 주기 싫다는 시각을 이해하지만, 나는 다른 관점을 제시하고 싶음
2006년에 내가 만든 프로젝트 이름을 2012년에 다른 개발자가 쓰고 싶다고 해서 흔쾌히 넘겨줬음
그 프로젝트가 바로 scrypt, 개발자는 Colin이었음
이런 커뮤니티 친절은 상업적 기대 없이도 쌓이는 좋은 업보가 됨 -
“Jeff Barr의 AWS 유저 밋업이 Second Life에서 열렸다”는 말이 참 흥미로움
Second Life는 AWS의 초기 사용자였고, Jeff Bezos가 2005년 투자 라운드에 직접 참여했음
그 덕분에 Jeff Barr가 Second Life 내에서 AWS 밋업을 열었고, 당시엔 Reuters나 Jonathan Coulton 같은 그룹들도 가상 공간에 진출하던 시기였음- 2002~2003년쯤 컨퍼런스에서 Second Life를 처음 봤을 때의 기억이 남음
우리는 Evolution Robotics 부스로 나가서 ER1 로봇을 시연했는데, Second Life가 정말 인상적이었음
좋은 추억으로 남아 있음 - re:Invent 2020이 가상 공간으로 열렸을 때, Second Life 시절의 데자뷔를 강하게 느낌
물론 노트북 화면 속 Second Life와 VR 헤드셋은 완전히 다른 경험이었음
- 2002~2003년쯤 컨퍼런스에서 Second Life를 처음 봤을 때의 기억이 남음
-
“Amazon을 위한 무료 노동”이라는 프레임은 핵심을 놓치고 있음
Colin은 자선활동을 한 게 아니라, Tarsnap이 FreeBSD/EC2에 의존하기 때문에 그걸 개선한 것임
이런 모델이 오픈소스의 가장 건강한 형태임 — 자기 제품의 기반을 고치고, 그 결과가 모두에게 이익이 되는 구조임
Amazon이 직접 관심을 가질 때까지 기다리는 건 영원히 기다리는 것과 같음 -
Amazon이 GitHub Sponsors를 통해 주 10시간, 1년간 후원했다는 글을 보고 놀랐음
시간당 $300이라니, Google L6 엔지니어 급여 수준임
지금은 더 받기를 바람- 미국 IT 업계의 시간당 요율은 정말 비정상적으로 높음
독일어권 유럽에서는 120유로면 훌륭한 엔지니어를 구할 수 있음. 동유럽은 더 저렴함
- 미국 IT 업계의 시간당 요율은 정말 비정상적으로 높음
-
IAM Roles for EC2에 대한 저자의 비판에 동의하지 않음
IAM은 자격 증명을 정책 기반으로 관리하게 해주는 핵심 기능임
Outlook, Slack, Teams보다 훨씬 안전하며, 수학적으로 팀원이 서명 키를 볼 수 없다는 걸 증명할 수도 있음
Azure도 비슷한 개념을 적용해 MSSQL 접근을 깔끔하게 처리함- 나는 IAM Roles 자체를 반대하지 않음. 다만 역할 자격 증명을 전달하는 인터페이스로 최악의 선택을 했다고 봄
예전엔 XenStore를 통해 커널에 자격 증명을 전달하자고 제안했음. Nitro 기반이라면 지금은 더 쉽게 구현 가능함
커널이 자격 증명을 받아 소유권과 권한을 설정할 수 있는 가상 파일시스템으로 노출하면 됨 - Scaleway는 포트 1024 미만에서만 토큰을 가져올 수 있게 함
CAP_NET_BIND_SERVICE 권한이 있는 프로세스만 접근 가능하다는 점이 귀여움
vsock(7) 소켓을 쓰면 속이기 어려운 연결 방식이 되어 더 안전함
더 나아가 DMI 데이터에 부트스트랩 자격 증명을 넣으면 root만 읽을 수 있는 sysfs 디렉터리에 위치하게 됨
- 나는 IAM Roles 자체를 반대하지 않음. 다만 역할 자격 증명을 전달하는 인터페이스로 최악의 선택을 했다고 봄
-
2007년 이메일을 확인해보니, 초기에 AWS 서비스 접근을 개별 요청해야 했던 게 사실이었음
처음엔 “Amazon E-Commerce Service”만 승인받았고, 이후 S3, EC2 베타 순으로 접근 권한을 얻었음
당시 “Alexa Web Information Service”는 음성 비서가 아니라 웹 검색 API였음. 그 시절이 참 흥미로움 -
정말 흥미로운 기술사적 기록임
Tavis Ormandy 같은 유명 엔지니어도 인터뷰에서 실수할 수 있다는 점이 인상적임
이런 경험담 블로그 글이 참 좋음 -
20년 회고에 Hetzner나 OVH 언급이 없다는 게 의미심장함
나는 AWS, Hetzner, 소형 클라우드를 함께 쓰는데, 가격 차이가 엄청남
AWS는 월 $350, Hetzner는 20~25유로에 비슷한 스펙과 20TB 트래픽 포함임
AWS가 파는 건 이제 컴퓨트가 아니라 IAM 모델, 글로벌 인프라, 조직 내 합의임
“AWS를 선택하면 아무도 해고되지 않는다”는 인식이 진짜 제품임
최근 AWS에서 워크로드를 옮긴 사람들에게 묻고 싶음 — 예상보다 더 고통스러웠던 부분은 무엇이었는지