# AWS에서 보낸 20년, 한 번도 "내 일이 아니"라고 한 적 없다 > Clean Markdown view of GeekNews topic #28433. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28433](https://news.hada.io/topic?id=28433) - GeekNews Markdown: [https://news.hada.io/topic/28433.md](https://news.hada.io/topic/28433.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-04-12T12:31:56+09:00 - Updated: 2026-04-12T12:31:56+09:00 - Original source: [daemonology.net](https://www.daemonology.net/blog/2026-04-11-20-years-on-AWS-and-never-not-my-job.html) - Points: 9 - Comments: 1 ## Topic Body - 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 로그 조사, 기술 문서 확보 등 **"원격 손"** 역할을 수행 ## Comments ### Comment 55135 - Author: neo - Created: 2026-04-12T12:31:57+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47727711) - 저자는 ‘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을 택하는 회사들은 진정한 오픈소스 정신보다는 **이미지 관리**나 개발자 호감도 확보를 위해서만 공개했을 가능성이 큼 - 나는 “운 좋게도” 이런 문제를 깊게 고민할 만큼 똑똑하거나 중요한 사람이 아님 그래도 전적으로 동의함. 이제 내가 공개할 코드는 완전한 오픈소스이거나 완전한 비공개 둘 중 하나임 누군가가 그걸로 **돈을 벌 가능성**이 있으면 공개하지 않음 - 대기업에 시간을 주기 싫다는 시각을 이해하지만, 나는 다른 관점을 제시하고 싶음 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 헤드셋은 완전히 다른 경험이었음 - “Amazon을 위한 무료 노동”이라는 프레임은 핵심을 놓치고 있음 Colin은 자선활동을 한 게 아니라, **Tarsnap이 FreeBSD/EC2에 의존**하기 때문에 그걸 개선한 것임 이런 모델이 오픈소스의 가장 건강한 형태임 — 자기 제품의 기반을 고치고, 그 결과가 모두에게 이익이 되는 구조임 Amazon이 직접 관심을 가질 때까지 기다리는 건 **영원히 기다리는 것**과 같음 - Amazon이 GitHub Sponsors를 통해 **주 10시간, 1년간 후원**했다는 글을 보고 놀랐음 시간당 $300이라니, Google L6 엔지니어 급여 수준임 지금은 더 받기를 바람 - 미국 IT 업계의 **시간당 요율**은 정말 비정상적으로 높음 독일어권 유럽에서는 120유로면 훌륭한 엔지니어를 구할 수 있음. 동유럽은 더 저렴함 - 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 디렉터리에 위치하게 됨 - 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에서 워크로드를 옮긴 사람들에게 묻고 싶음 — 예상보다 **더 고통스러웠던 부분**은 무엇이었는지