Kubernetes

한 줄 요약 — Amazon S3는 20년 동안 API 하위 호환성을 유지하며 단순 저장소에서 AI와 데이터 분석을 위한 통합 플랫폼으로 진화했습니다. 이 주제를 꺼낸 이유 현대적인 클라우드 기반 애플리케이션을 개발하면서 Amazon S3(Simple Storage Service)를 거치지 않기란 불가능에 가깝습니다. 정적 웹 사이트 호스팅부터 대규모 데이터 레이크 구축, 그리고 최근의 생성형 AI를 위한 데이터셋 관리까지 S3는 언제나 그 중심에 있었습니다. 최근 S3 출시 20주년을 맞아 공개된 기술적 회고와 향후 비전은 단순한 기념사를 넘어섭니다. 20년 전 작성한 코드가 수정 없이 여전히 작동한다는 사실은 변동성이 심한 테크 업계에서 경이로운 수준의 신뢰를 보여줍니다. 특히 S3 Tables나 S3 Vectors 같은 신규 기능은 객체 스토리지가 앞으로 어떤 방향으로 확장될지 명확한 힌트를 줍니다. ...

한 줄 요약 — Amazon S3 일반 용도 버킷(General Purpose Buckets) 생성 시 계정 ID와 리전 정보가 포함된 고유 접미사를 붙여, 전역 네임스페이스 중복 문제 없이 버킷 이름을 자유롭게 선점할 수 있게 되었습니다. 이 주제를 꺼낸 이유 AWS를 사용하면서 가장 먼저 마주하는 난관 중 하나가 Amazon S3 버킷 이름을 정하는 일입니다. S3는 서비스 초기부터 전역 네임스페이스(Global Namespace)를 사용해 왔기에, 내가 원하는 이름이 이미 전 세계 누군가에 의해 사용 중이라면 해당 이름을 쓸 수 없었습니다. test-bucket이나 my-data 같은 평범한 이름은 고사하고, 회사 프로젝트 이름을 포함한 조합조차 중복 오류를 뱉어내기 일쑤였습니다. ...

왜 지금 이게 문제인가 “Pod가 Pending 상태로 멈춰 있습니다.” Kubernetes를 운영하는 팀이라면 한 번쯤 들어본 문장이다. 대부분의 경우 리소스 부족이 원인이지만, 클러스터가 1,000노드를 넘어가고 GPU 워크로드가 섞이기 시작하면 이야기가 완전히 달라진다. 스케줄러가 병목이 되는 것이다. 국내에서 AI 워크로드가 폭증하면서 이 문제는 더 이상 해외 빅테크만의 이야기가 아니다. 네이버 클라우드 HyperCLOVA 학습 클러스터, 카카오 클라우드의 GPU 인스턴스 풀, 그리고 수많은 스타트업의 A100/H100 클러스터에서 스케줄러 성능은 인프라 비용과 직결된다. GPU 한 장이 시간당 수만 원인 환경에서 스케줄링 지연 10초는 곧 돈이다. ...