aws2026년 5월 27일

새로운 AWS 히어로를 만나보세요 – 2026년 5월 | Amazon Web Services (새 탭에서 열림)

2026년 5월 AWS Heroes로 네 명의 커뮤니티 리더가 새롭게 선정되었습니다. 이들은 AI·서버리스·클라우드 아키텍처 지식을 공유하고, 사용자 그룹과 커뮤니티 행사를 운영하며, 교육과 멘토링으로 AWS 생태계의 성장을 돕고 있습니다. 특히 AWS re:Invent 도구 개발, 라틴아메리카 최대 규모 커뮤니티 운영, AI/ML 인증 기여 등 각자의 전문성을 바탕으로 활동해 왔습니다. ## AWS Heroes 선정의 의미 - AWS Heroes는 기술 전문성뿐 아니라 커뮤니티에 대한 기여와 지식 공유를 인정받은 리더들입니다. - 선정된 인물들은 블로그, 팟캐스트, 컨퍼런스, 사용자 그룹, 교육 행사 등을 통해 다른 개발자와 클라우드 실무자를 지원해 왔습니다. - 이번에는 이탈리아, 캐나다, 아르헨티나에서 AI, 서버리스, 클라우드 아키텍처 분야의 리더들이 선정되었습니다. ## Damiano Giorgi: AI 기반 re:Invent 세션 추천 도구 - 이탈리아 파비아 출신의 **Artificial Intelligence Hero**입니다. - 온프레미스 시스템 엔지니어에서 AWS 클라우드 솔루션 아키텍트로 전환했으며, 현재 AI의 발전과 활용에 집중하고 있습니다. - AWS User Group Pavia와 AWS User Group Milan의 운영을 돕고 있습니다. - 개인 블로그 **“Bass and Bytes”**를 통해 기술 콘텐츠를 공유합니다. - Amazon Bedrock과 Amazon Nova를 활용해 관심사에 맞는 AWS re:Invent 세션을 찾도록 돕는 **“Unofficial post:Invent Session Suggester”**를 개발했습니다. - AWS Summit Milan을 비롯해 이탈리아, 아드리아 지역, 그리스, 네덜란드 등 유럽의 다양한 컨퍼런스에서 발표하고 있습니다. ## Darryl Ruggles: 서버리스와 AI/ML 아키텍처 전파 - 캐나다 오타와 출신의 **Serverless Hero**입니다. - 소프트웨어 개발자로 오랜 기간 일한 뒤 AWS 애플리케이션 및 AI/ML 아키텍처 분야로 전문성을 확장했습니다. - 서버리스, 컨테이너, AI/ML, FinOps를 주제로 블로그, LinkedIn, 공개 프로젝트에서 지식을 공유합니다. - **“Believe In Serverless”**를 포함한 여러 온라인 AWS 커뮤니티에서 활발히 활동합니다. - 온라인과 오프라인 행사를 가리지 않고 다른 개발자들과 교류하며 서버리스 기술의 실제 활용을 돕고 있습니다. ## Ricardo Daniel Ceci: 라틴아메리카 클라우드 커뮤니티 확장 - 아르헨티나 부에노스아이레스 출신의 **Artificial Intelligence Hero**입니다. - 약 2,400명의 회원을 보유한 아르헨티나 최대 AWS 커뮤니티인 **AWS User Group Buenos Aires**를 이끌고 있습니다. - **AWS Community Day Argentina**의 수석 조직자로 활동했습니다. - 2025년 **LATAM AWS Community Leader of the Year**로 선정되었습니다. - 라틴아메리카의 클라우드 전문가, AWS Heroes, 개발자 애드보킷과 대화하는 팟캐스트를 운영합니다. - 15년 이상의 클라우드 및 웹 개발 경험을 바탕으로 스페인어권 개발자들이 클라우드와 AI에 쉽게 접근하도록 지원하고 있습니다. ## Matias Kreder: AWS 인증과 머신러닝 커뮤니티 기여 - 부에노스아이레스 출신의 **Artificial Intelligence Hero**입니다. - AWS 인증 시험의 Subject Matter Expert(SME)로 참여했으며, **AWS Certified AI Practitioner**를 포함한 여러 AI/ML 인증 개발에 기여했습니다. - AWS DeepRacer에서 세 차례 결승 진출자로 선정된 경험을 계기로 커뮤니티 활동을 시작했습니다. - 이후 지역 내 DeepRacer 대회와 머신러닝 발표·행사를 조직했습니다. - AWS User Group Buenos Aires의 리더로서 2025년 AWS Community Day Argentina를 조직했습니다. - 라틴아메리카 전역의 커뮤니티 행사에서 AI, 머신러닝, AWS 관련 주제로 발표하고 있습니다. ## 실용적인 시사점 - AWS 기술을 학습할 때 공식 문서뿐 아니라 사용자 그룹, 커뮤니티 행사, 팟캐스트, 공개 프로젝트를 함께 활용하면 실무 관점을 얻을 수 있습니다. - Amazon Bedrock·Nova 같은 생성형 AI 서비스를 실제 개발 도구에 적용한 사례는 AWS 서비스 학습과 프로토타이핑에 참고할 만합니다. - 관심 지역의 AWS Heroes나 사용자 그룹에 참여하면 발표, 멘토링, 자격증 준비, 네트워킹 기회를 얻을 수 있습니다.

containersaimachine-learningaws+4

cloudflare2026년 4월 13일

샌드박스 정식 출시로 에이전트가 각자의 컴퓨터를 갖게 됩니다 (새 탭에서 열림)

Cloudflare는 AI 에이전트가 코드를 안전하게 개발하고 실행할 수 있도록 설계된 '샌드박스(Sandboxes)'와 'Cloudflare Containers'의 정식 출시(GA)를 발표했습니다. 이 서비스는 에이전트에게 격리된 가상 컴퓨터 환경을 제공하여 리포지토리 복제, 코드 빌드, 개발 서버 실행과 같은 복잡한 작업을 안전하게 수행할 수 있게 돕습니다. 이를 통해 개발자는 확장성, 상태 복구, 보안 등 인프라 구축의 난제들을 직접 해결할 필요 없이 고도화된 AI 에이전트 서비스를 배포할 수 있습니다. ### 샌드박스의 핵심 기능 및 업데이트 * **보안 인증 정보 주입(Secure Credential Injection)**: 프로그래밍 가능한 송신(Egress) 프록시를 통해 네트워크 계층에서 인증 정보를 주입합니다. 에이전트가 실제 비밀번호나 API 키에 직접 접근하지 못하게 차단하면서도 필요한 내부 서비스에는 안전하게 접근할 수 있도록 설계되었습니다. * **PTY(의사 터미널) 지원**: 단순한 텍스트 입력-출력 구조를 넘어, WebSocket과 xterm.js를 활용한 실제 터미널 환경을 제공합니다. 이를 통해 인간과 에이전트 모두 스트리밍 출력을 실시간으로 확인하고 상호작용할 수 있습니다. * **지속성 코드 인터프리터**: Python, JavaScript, TypeScript를 위한 상태 유지형 인터프리터를 기본 제공하여, 에이전트가 이전 실행 상태를 기억하며 연속적인 코드를 실행할 수 있습니다. * **스냅샷 및 상태 복구**: 스냅샷 기능을 통해 에이전트의 이전 작업 세션을 신속하게 복구할 수 있으며, 유휴 상태일 때는 자동으로 절전 모드에 진입하여 리소스를 절약합니다. ### 인프라 관리 및 운영 효율성 * **프로그래밍 방식의 제어**: `exec`, `gitClone`, `writeFile` 등의 API 메서드를 제공하여 개발자가 샌드박스의 생명주기와 파일 시스템을 코드만으로 손쉽게 조작할 수 있습니다. * **라이브 프리뷰 및 배경 프로세스**: 백그라운드에서 실행되는 개발 서버와 상호작용할 수 있는 라이브 프리뷰 URL을 지원합니다. 파일 시스템 변경 사항을 감지하는 모니터링 기능과 결합하여 에이전트의 작업 결과를 즉시 검증할 수 있습니다. * **유연한 과금 체계**: 'Active CPU Pricing' 정책을 도입하여 에이전트가 실제로 CPU를 사용하는 시간에 대해서만 비용을 지불합니다. 대규모 에이전트 함대를 운영하더라도 대기 상태의 유휴 리소스에 대한 비용 부담이 적습니다. ### 기술적 특징 및 작동 방식 * **Cloudflare Containers 기반**: 모든 샌드박스는 Cloudflare Containers에 의해 구동되며, 고유한 이름을 통해 요청 시 즉시 생성되거나 기존 환경을 재개합니다. * **전역 접근성**: 동일한 ID를 제공하면 전 세계 어디에서나 이전에 작업하던 동일한 샌드박스 환경에 다시 접속하여 작업을 이어갈 수 있습니다. * **검증된 안정성**: Figma의 'Figma Make'와 같은 실제 서비스에서 이미 활용되고 있으며, 신뢰할 수 없는 사용자 작성 코드나 에이전트 코드를 실행하는 데 최적화된 격리 환경을 보장합니다. AI 에이전트가 단순한 텍스트 응답을 넘어 실제 환경에서 도구를 사용하고 코드를 실행하는 '행동하는 에이전트'로 진화하기 위해서는 안전한 샌드박스가 필수적입니다. Cloudflare의 이번 GA 출시는 복잡한 인프라 설정 없이도 엔터프라이즈급 보안과 확장성을 갖춘 에이전트 실행 환경을 즉시 구축할 수 있는 실질적인 해답을 제공합니다.

containersauthenticationcloudflare-sandboxesagent-systems+4

cloudflare2026년 4월 12일

에이전트 위크에 오신 것을 환영합니다 (새 탭에서 열림)

AI 에이전트의 시대가 도래함에 따라 기존의 컨테이너 기반 클라우드 인프라는 확장성과 비용 측면에서 한계에 직면하고 있습니다. 클라우드플레어는 일대다(1:N) 방식의 전통적인 아키텍처 대신, 개별 에이전트마다 독립적인 실행 환경을 즉시 제공할 수 있는 격리(Isolate) 기반의 서버리스 기술이 미래 인터넷의 핵심이 될 것이라고 주장합니다. 에이전트의 대중화를 위해서는 수 밀리초 안에 실행되고 자원 소모가 적은 가벼운 컴퓨팅 환경으로의 전환이 필수적이라는 결론입니다. **기존 클라우드 모델과 에이전트의 충돌** * 스마트폰 시대를 거치며 발전한 현재의 클라우드는 소수의 마이크로서비스 인스턴스가 다수의 사용자를 처리하는 '일대다(One-to-Many)' 모델을 기본으로 합니다. * 반면 AI 에이전트는 한 명의 사용자가 하나의 특정 작업을 수행하기 위해 고유한 실행 환경을 점유하는 '일대일(One-to-One)' 모델을 요구합니다. * 기존 애플리케이션이 정해진 메뉴를 제공하는 '레스토랑'이라면, 에이전트는 작업마다 다른 도구와 재료를 사용하는 '개인 요리사'와 같아서 기존의 컨테이너 방식으로는 이를 효율적으로 수용하기 어렵습니다. **에이전트 대중화를 가로막는 확장성 산식** * 수억 명의 지식 노동자가 동시에 에이전트를 사용할 경우, 기존 컨테이너 방식으로는 수백만 대의 서버 CPU가 필요하며 이는 현재 가용 가능한 컴퓨팅 용량을 수십 배 초과합니다. * 컨테이너는 실행 시 수백 메가바이트의 메모리를 소모하고 시작 속도가 느려, 에이전트 한 대당 운영 비용이 매우 높게 형성됩니다. * 이러한 경제적 한계 때문에 현재 에이전트 도구들은 높은 비용을 정당화할 수 있는 코딩 도구 등 일부 영역에만 국한되어 있습니다. **V8 Isolate 기술을 통한 인프라 혁신** * Cloudflare Workers의 기반인 V8 Isolate 기술은 컨테이너 대비 시작 속도는 약 100배 빠르고(수 밀리초), 메모리 사용량은 100배가량 효율적입니다. * 'Dynamic Workers' 환경을 통해 요청이 들어올 때마다 실시간으로 에이전트 실행 환경을 할당하고 작업 종료 즉시 폐기함으로써 하드웨어 밀도를 극대화할 수 있습니다. * Isolate는 에이전트가 필요로 하는 최소한의 자원만 할당하므로, 전 세계 수십억 명의 사용자를 위한 에이전트 서비스 운영에 필요한 경제적 타당성을 제공합니다. **전환기의 과제와 하이브리드 전략** * 현재는 에이전트가 사람이 사용하던 웹사이트를 탐색하기 위해 헤드리스 브라우저를 사용하는 '말 없는 마차(Horseless Carriage)' 단계에 머물러 있습니다. * 향후에는 에이전트가 직접 서비스를 호출하는 MCP(Model Context Protocol) 표준과 에이전트 전용 인증 방식이 확산될 것으로 보입니다. * 클라우드플레어는 파일 시스템과 바이너리 실행이 필수적인 코딩 에이전트를 위한 '컨테이너 기반 샌드박스'를 정식 출시함과 동시에, 가벼운 작업을 위한 Isolate 기술을 병행 지원하여 구시대와 신시대의 인프라를 연결할 계획입니다. 에이전트 중심의 서비스를 구축하려는 기업은 컨테이너 중심의 무거운 기존 설계에서 벗어나, 실행 밀도가 높고 비용 효율적인 Isolate 기반의 서버리스 아키텍처를 도입하여 대규모 사용자 환경에 대비할 것을 추천합니다.

containersdatabase-designllmk8s+4

figma2024년 8월 7일

12개월 이내에 K8 (새 탭에서 열림)

Figma는 ECS에서 Kubernetes(EKS)로 이전해 플랫폼의 기능과 확장성을 높이기로 결정했고, 핵심 서비스 대부분을 12개월 이내에 안전하게 옮겼습니다. ECS의 StatefulSet·Helm 지원 부족과 운영상의 불편, CNCF 생태계 활용 한계가 주요 전환 이유였습니다. 특히 Figma는 수천 개의 마이크로서비스를 운영하는 구조가 아니었기 때문에 대규모 마이그레이션의 범위를 현실적으로 통제할 수 있었습니다. ## 기존 Figma의 컴퓨트 플랫폼 - 2023년 초 Figma의 모든 서비스는 이미 컨테이너화되어 있었고, AWS ECS에서 실행되고 있었습니다. - ECS는 컨테이너 워크로드를 빠르게 운영하기에 좋은 플랫폼이었지만, 장기적으로 필요한 기능을 확장하기에는 한계가 있었습니다. - Figma는 모든 기능을 별도 마이크로서비스로 분리하지 않았습니다. - 성능이나 격리가 필요한 경우에만 새 서비스를 만들었습니다. - 대부분의 제품 기능은 기존 핵심 서비스에 로직을 추가하는 방식으로 구현했습니다. - 따라서 Kubernetes 전환 대상 서비스 수가 수천 개에 달하지 않았고, 이전 작업의 범위를 관리할 수 있었습니다. ## ECS에서 겪은 기능적 한계 - **StatefulSet 부재** - ECS에는 Kubernetes의 StatefulSet처럼 파드에 지속적인 식별자와 네트워크 정체성을 제공하는 기능이 없었습니다. - Figma는 ECS에서 etcd 클러스터를 운영하기 위해 컨테이너 시작 시 클러스터 멤버십을 동적으로 갱신하는 커스텀 코드를 작성했습니다. - 이 방식은 취약하고 유지보수가 어려웠습니다. - Kubernetes에서는 StatefulSet을 이용해 etcd 인스턴스의 안정적인 네트워크 정체성을 제공할 수 있습니다. - **Helm 차트 활용 부족** - Temporal 같은 오픈소스 소프트웨어를 도입하려면 ECS 환경에 맞게 각 서비스를 Terraform으로 직접 포팅해야 했습니다. - Kubernetes에서는 Helm 차트를 통해 관련 서비스와 설정을 표준화된 방식으로 설치하고 관리할 수 있습니다. - **노드 장애 대응의 불편** - ECS on EC2에서 문제가 있는 EC2 인스턴스 하나를 우아하게 종료하는 작업이 복잡했습니다. - EKS에서는 노드를 cordon 처리한 뒤 API 서버가 파드를 다른 노드로 이동시키도록 할 수 있습니다. - 이 과정에서 파드의 정상 종료 절차도 준수할 수 있습니다. ## CNCF 생태계 활용 - ECS를 계속 사용하면 Kubernetes와 함께 발전한 CNCF 오픈소스 생태계를 충분히 활용하기 어려웠습니다. - Figma가 특히 관심을 가진 영역은 자동 확장이었습니다. - 당시 컨테이너 서비스에 자동 확장을 적용하지 않아, 야간이나 주말처럼 트래픽이 낮은 시간에도 최대 부하를 감당할 자원을 미리 provision해야 했습니다. - 그 결과 불필요한 인프라 비용이 발생했습니다. - Kubernetes 생태계의 KEDA는 다음과 같은 기준으로 자동 확장을 지원합니다. - CPU 사용률 - AWS SQS 큐 길이 - Datadog의 커스텀 메트릭 - ECS에도 일부 자동 확장 기능은 있지만, Figma는 Kubernetes 생태계의 성숙한 오픈소스 도구를 활용하는 편이 장기적으로 유리하다고 판단했습니다. ## 서비스 메시와 트래픽 처리 - Figma는 서비스 간 트래픽을 AWS ALB와 NLB를 통해 라우팅하고 있었습니다. - NLB에서 새 대상을 등록하거나 기존 대상을 제거하는 데 몇 분이 걸려 긴급 배포와 장애 복구가 느려지는 문제가 있었습니다. - Figma는 이미 주요 서비스 앞에 독립적인 Envoy 프록시 클러스터를 운영하고 있었습니다. - 장애 상황에서 부하를 줄이는 커스텀 필터를 적용하기 위한 목적이었습니다. - 장기적으로는 전체 서비스에 Envoy 기반 서비스 메시를 도입할 가능성이 있다고 보았습니다. - EKS에서는 Istio 같은 서비스 메시 솔루션을 활용할 수 있지만, ECS에서는 이런 생태계를 직접 구축하거나 많은 부분을 커스텀 구현해야 했습니다. ## 전환을 결정한 기준 - 단순히 새로운 기술을 도입하는 것이 아니라, 다음 세 가지를 종합해 판단했습니다. - 현재 ECS에서 발생하는 운영 및 개발 비용 - 자동 확장과 서비스 메시 등 미래 요구사항 - 마이그레이션을 합리적인 기간 안에 완료할 수 있는지 여부 - Figma는 대규모 작업이 플랫폼을 실제로 개선하고, 사용자에게 다운타임을 유발하지 않으면서 완료될 수 있어야 한다는 원칙을 강조했습니다. - 결론적으로 Kubernetes는 StatefulSet, Helm, 자동 확장, 서비스 메시 등 Figma가 필요로 하던 기능을 더 자연스럽게 제공하는 기반으로 평가되었습니다. Figma와 유사하게 컨테이너 기반 서비스를 운영하면서 ECS의 기능적 한계가 커지고 있다면 Kubernetes 전환을 검토할 수 있습니다. 다만 서비스 수와 운영 복잡도를 먼저 평가하고, 자동 확장·상태 저장 워크로드·트래픽 관리처럼 실제로 필요한 기능을 기준으로 이전의 효과를 판단하는 것이 바람직합니다.

containersk8sterraformhelm+4

figma2023년 10월 23일

서버 측 샌드박싱 (새 탭에서 열림)

서버 측 샌드박싱은 악성 입력을 처리하는 애플리케이션의 취약점이 전체 인프라로 확산되는 것을 막는 방어 계층이다. 이미지·데이터 처리 라이브러리처럼 메모리 안전성이 낮고 취약점이 반복적으로 발견되는 소프트웨어를 완전히 제거하거나 재작성하기는 현실적으로 어렵기 때문에, VM·컨테이너·seccomp 등을 이용해 실행 환경과 접근 가능한 자원을 제한해야 한다. 중요한 것은 특정 기술 하나를 선택하는 것이 아니라 보안성, 운영 복잡도, 성능, 격리 수준 사이의 트레이드오프를 workload 특성에 맞게 평가하는 것이다. ## 사용자 입력을 처리할 때 발생하는 위험 - 이미지 처리, 파싱, 압축, 썸네일 생성은 SaaS 애플리케이션에서 흔히 필요한 작업이다. - 이러한 기능은 C++ 같은 메모리 비안전 언어로 작성된 라이브러리에 의존하는 경우가 많다. - 해당 라이브러리는 원래 악의적인 입력을 처리하도록 설계되지 않았으며, 메모리 손상 취약점이 반복적으로 발견되어 왔다. - 대표적인 사례가 2016년 ImageMagick에서 발견된 **ImageTragick**이다. - 사용자가 제공한 이미지를 서버에서 처리하는 서비스가 원격 코드 실행 공격에 노출될 수 있었다. - 모든 버그와 취약점을 사전에 제거하는 것은 사실상 불가능하므로, 취약점이 발생하더라도 피해 범위를 제한하는 방어책이 필요하다. ## 서버 측 샌드박싱의 역할 - 샌드박싱은 애플리케이션이나 작업을 제한된 환경에서 실행하는 **workload isolation** 기법이다. - 공격자가 취약한 작업을 장악하더라도 다음과 같은 접근을 제한하는 것이 목표다. - 다른 작업의 사용자 데이터 - 운영 환경의 내부 서비스 - 파일 시스템과 네트워크 자원 - 추가 시스템으로의 lateral movement - Figma는 C++로 작성된 서버 측 렌더링 시스템인 RenderServer와 사용자 생성 그래픽 데이터를 처리하는 서드파티 라이브러리를 사용한다. - 이러한 작업을 인프라 내부에서 직접 실행하면 단 하나의 심각한 버그가 다른 사용자 데이터나 운영 시스템 침해로 이어질 수 있다. - 모든 unsafe 코드를 메모리 안전 언어로 다시 작성하고 정적 분석으로 정확성을 증명하는 방법도 있지만, 비용과 시간이 크며 완벽한 보안을 보장하지도 않는다. - 따라서 취약점 예방과 함께, 취약점이 악용되었을 때 영향 범위를 줄이는 격리 전략을 병행한다. ## VM, 컨테이너, seccomp - 글에서는 서버 측 샌드박싱의 대표적인 구현 방식으로 다음 세 가지를 소개한다. - **가상 머신(VM)**: 하이퍼바이저 위에서 각 게스트 운영체제를 실행한다. 인프라와 작업 사이에 하이퍼바이저 및 게스트 OS 계층이 존재한다. - **컨테이너**: 호스트 운영체제의 기능과 커널을 공유하면서 컨테이너 엔진을 통해 작업을 분리한다. VM보다 가볍게 실행할 수 있지만 격리 특성이 다르다. - **seccomp**: 프로세스가 호출할 수 있는 시스템 콜을 제한하는 Linux 보안 기능이다. - 각 방식은 격리 강도, 실행 비용, 성능, 시작 시간, 운영 편의성, 설정 복잡도 등에서 서로 다른 특성을 가진다. - 실제 환경에서는 단일 기술만 사용하기보다 workload의 신뢰 수준과 필요한 권한에 따라 여러 샌드박싱 primitive를 조합할 수 있다. ## 샌드박싱 선택 시 고려할 점 - 샌드박싱은 보안 취약점을 없애는 기술이 아니라, 취약점이 발생했을 때 공격의 범위와 피해를 제한하는 방어 계층이다. - 선택 과정에서는 다음을 함께 검토해야 한다. - 처리 대상이 사용자 입력인지, 내부에서 신뢰할 수 있는 데이터인지 - 작업이 필요한 파일·네트워크·시스템 콜의 범위 - 강한 격리에 필요한 성능 및 비용 - 샌드박스의 생성·폐기와 패치·모니터링 운영 부담 - 샌드박스 자체의 탈출 가능성과 호스트에 미치는 영향 - 샌드박싱 기술은 과거보다 안정적이고 실용적으로 발전했지만, 여전히 보안 연구와 운영 경험이 중요한 분야다. 악성 입력을 처리하는 기능은 메모리 안전 언어로의 전환만으로 보호하려 하기보다, 최소 권한과 강한 실행 격리를 함께 적용하는 것이 현실적이다. 특히 사용자 데이터를 다루는 고위험 작업은 VM이나 컨테이너 격리를 검토하고, 불필요한 시스템 콜은 seccomp로 추가 제한하는 접근이 유용하다.

containerswebassemblyc++application-security+3