Techlist.io - 한국 테크 블로그 큐레이터

figma3분 읽기큐레이션 요약

Issue no.17: 즐겁게 만들기 | Figma 블로그

Figma의 뉴스레터 「Build with joy」는 도구와 작업 방식이 계속 바뀌어도, 아이디어를 현실로 만드는 즐거움과 창작의 본질은 변하지 않는다고 말한다. Config 2026에서 공개한 새로운 도구를 바탕으로 디자인의 방향성, 취향, 모션, 색상 등 창작 역량을 탐구하며, 독자가 자신의 관심사에 따라 콘텐츠를 선택하도록 구성했다. ## 자신만의 경로를 선택하는 창작 - Config 2026 매거진은 정해진 순서 없이 원하는 주제부터 시작할 수 있는 ‘선택형 모험’ 구조로 제작됐다. - 팀이 기존 워크플로를 어떻게 발전시키고, 새로운 가능성을 향해 나아가는지 디지털 매거진을 통해 소개한다. - 핵심 메시지는 새로운 도구를 사용하는 방식보다, 그 도구로 무엇을 만들고 어디로 향할지 결정하는 사람이 중요하다는 점이다. ## 취향은 지속적으로 가꾸는 능력 - Figma 최고디자인책임자 로레다나 크리산은 취향을 단순히 좋은 것과 나쁜 것을 구분하는 능력으로 보지 않는다. - 좋은 결과에 도달하기 위해 계속 에너지를 유지하고, 자신의 관점을 발전시키는 태도까지 취향에 포함한다. - 음악을 연주하며 얻은 경험을 통해 취향을 형성하는 과정을 설명한다. - 채용 시에도 결과물만이 아니라 지원자의 관점과 성장 가능성을 중요하게 본다. - 도구가 작업을 도와줄 수는 있지만, 장인정신을 갖추려면 자신만의 기준과 시각을 끊임없이 다듬어야 한다. ## 모션은 디자인과 시간의 결합 - Figma Brand Studio 팀은 모션 디자인을 ‘디자인과 시간의 결합’으로 설명한다. - 움직임의 속도, 방향, 타이밍에 따라 같은 동작도 전혀 다른 인상을 줄 수 있다. - “whoosh”와 “whoop”처럼 유사해 보이는 움직임도 세부적인 리듬과 강도에 따라 구분된다. - 모션은 장식적인 효과가 아니라 브랜드의 성격과 사용자 경험을 전달하는 핵심 디자인 요소다. ## 색상이 문화를 해석하는 방식 - Pantone의 ‘색채 인류학자’들은 색상이 단순한 시각 요소를 넘어 문화적 의미를 만든다고 설명한다. - Coca-Cola의 빨강, Barbie의 분홍, Brat의 초록처럼 특정 색은 브랜드와 시대적 현상을 상징할 수 있다. - 브랜드는 색을 활용해 정체성과 의미를 형성하고, 사회적 트렌드에 영향을 줄 수 있다. - 색상을 선택할 때는 미적 조화뿐 아니라 색이 특정 문화와 집단에서 어떤 감정과 연상을 불러일으키는지 고려해야 한다. ## Config와 창작 커뮤니티의 확장 - Figma CEO이자 공동창업자인 딜런 필드는 Config 2026에서 발표된 내용을 정리하고, 캔버스에 새로운 차원을 더하는 방향을 소개한다. - 커뮤니티 구성원들은 감정에 따라 적응하는 시스템이나 미래를 예측하는 도구 등 소프트웨어의 미래를 상상한다. - Figma 굿즈 시즌 5에서는 8명의 일러스트레이터가 첫 스케치부터 Figma Store에 제품이 나오기까지의 과정을 공유한다. - 제품, 커뮤니티, 일러스트레이션을 연결하며 창작이 개인 작업을 넘어 다양한 사람과 매체를 통해 확장된다는 점을 보여준다. ## 글 전체를 관통하는 창작 철학 - 기술과 제작 방식은 변화하지만, 비전을 실제 결과물로 구현할 때 느끼는 기쁨은 변하지 않는다. - 창작자는 새로운 도구를 익히는 데 그치지 않고, 무엇이 좋은지 판단하는 기준과 자신만의 관점을 길러야 한다. - 세부적인 움직임과 색상 선택도 브랜드와 사용자 경험의 의미를 형성하므로, 결과물의 작은 요소까지 의도적으로 설계해야 한다. 실무에서는 새로운 기능을 무작정 도입하기보다, 먼저 전달하려는 의도와 관점을 정한 뒤 도구·모션·색상을 선택하는 것이 좋다. 꾸준히 다양한 작업을 관찰하고 직접 실험하면서 자신만의 취향과 디자인 기준을 발전시키는 것도 중요하다.

원문 읽기(새 탭에서 열림)
aws3분 읽기큐레이션 요약

Kubernetes 버전 롤백으로 Amazon EKS 클러스터를 안심하고 업그레이드하기 | Amazon Web Services

Amazon EKS가 Kubernetes 클러스터 업그레이드 후 7일 이내에 이전 마이너 버전으로 되돌릴 수 있는 버전 롤백 기능을 출시했습니다. 이는 업그레이드 실패 시 클러스터를 재구축하지 않고, 실제 운영에서 검증된 이전 버전으로 복구할 수 있게 해줍니다. 이를 통해 업그레이드에 대한 부담을 줄이고 보안 패치와 최신 버전 도입을 더욱 적극적으로 추진할 수 있습니다. ### 기존 Kubernetes 업그레이드의 한계 - 오픈소스 Kubernetes는 전통적으로 컨트롤 플레인 버전 롤백을 지원하지 않았습니다. - 업그레이드 후 문제가 발생하면 클러스터를 재구축하거나 장기간의 복구 작업을 진행해야 했습니다. - 조직들은 다음과 같은 보완책을 마련해야 했습니다. - 긴 사전 검증 및 bake 기간 - 단계적 업그레이드 그룹(stagger groups) - 자동 승인 절차 - 수개월에 걸친 업그레이드 일정 - 그 결과 보안 패치가 포함된 최신 Kubernetes 버전으로의 업그레이드를 미루고, 지원 종료나 연장 지원 기간에 임박하는 문제가 발생했습니다. ### Amazon EKS 버전 롤백 기능 - 업그레이드 후 **7일 이내**에 이전 Kubernetes 마이너 버전으로 되돌릴 수 있습니다. - 예를 들어 Kubernetes 1.34에서 1.35로 업그레이드한 뒤 문제가 발견되면 1.34로 복구할 수 있습니다. - 에뮬레이션된 버전이나 임시 상태가 아니라, 실제 운영에서 사용했던 검증된 이전 버전으로 복원합니다. - 한 번에 한 마이너 버전만 롤백할 수 있으며, 이는 EKS의 점진적 업그레이드 정책과 동일합니다. - 자체 관리 노드를 사용하는 클러스터와 AWS 관리형 노드를 사용하는 클러스터 모두 컨트롤 플레인 롤백을 지원합니다. ### 롤백 준비 상태 점검 - EKS는 클러스터 인사이트를 통해 롤백 가능 여부를 자동으로 평가합니다. - 다음과 같은 문제를 사전에 확인할 수 있습니다. - 노드와 컨트롤 플레인 간 버전 호환성 - 애드온 의존성 - 롤백을 방해할 수 있는 클러스터 구성 - 점검 결과를 확인한 뒤 롤백을 시작할 수 있습니다. - 긴급하게 진행해야 하는 경우 `--force` 옵션으로 준비 상태 검사를 우회할 수 있습니다. ### EKS Auto Mode의 노드 롤백 - EKS Auto Mode에서는 컨트롤 플레인과 관리형 노드를 함께 롤백해야 합니다. - 노드 롤백은 Pod Disruption Budget(PDB)을 준수하므로, 설정에 따라 완료까지 시간이 걸릴 수 있습니다. - 롤백이 지나치게 오래 걸리거나 전략을 바꾸고 싶을 때 사용할 수 있도록 취소 API가 제공됩니다. - 기본적으로 EKS는 롤백 중 PDB를 무시하지 않습니다. - 롤백을 빠르게 진행하려면 사용자가 직접 PDB를 수정하거나 제거해야 합니다. - 노드 롤백 기능은 EKS Auto Mode 클러스터에 제공됩니다. ### 롤백 과정과 운영 영향 - EKS 콘솔의 클러스터 설정 화면에서 롤백 가능 여부와 남은 롤백 기간을 확인할 수 있습니다. - 롤백 시작 전에 클러스터 인사이트를 검토해 노드 상태와 잠재적인 문제를 확인합니다. - 사례에서는 컨트롤 플레인 롤백에 약 20분이 걸렸으며, 이는 일반적인 업그레이드와 비슷한 수준입니다. - 롤백 중에도 클러스터는 계속 동작했습니다. - Auto Mode 노드는 PDB 설정에 따라 워크로드 중단을 최소화하면서 순차적으로 롤백됩니다. ### 제공 범위와 비용 - 상용 Amazon EKS가 제공되는 모든 AWS 리전에서 사용할 수 있습니다. - 추가 비용은 없으며, 기존 EKS 및 컴퓨팅 리소스 요금만 부과됩니다. - 표준 지원 또는 연장 지원 대상 Kubernetes 버전을 실행하는 클러스터가 지원됩니다. - 컨트롤 플레인 롤백은 모든 EKS 클러스터에서 사용할 수 있고, 노드 롤백은 EKS Auto Mode에서 지원됩니다. 운영 환경에서는 업그레이드 전에 롤백 가능 기간과 클러스터 인사이트를 확인하고, PDB와 애드온 호환성을 점검하는 것이 좋습니다. 특히 Auto Mode 사용자는 롤백 시간에 영향을 주는 PDB 설정과 취소 API 사용 방법을 미리 검토하면 안전한 복구 계획을 세울 수 있습니다.

원문 읽기(새 탭에서 열림)
meta5분 읽기큐레이션 요약

메타의 대규모 AI 스토리지 청사진

AI 혁신의 속도와 규모가 커질수록 스토리지는 GPU 활용률과 연구 생산성을 좌우하는 핵심 인프라가 된다. Meta는 기존 BLOB 스토리지의 긴 메타데이터 경로와 글로벌 복제 중심 설계가 AI의 낮고 예측 가능한 지연시간 요구를 충족하지 못한다고 판단했다. 이에 통합 메타데이터, 데이터 프록시 제거, GPU 인접 리전 배포를 중심으로 아키텍처를 재구축해 GPU 유휴 시간을 줄이고 데이터 처리 속도를 높이려 했다. ## AI 워크로드에서 스토리지가 중요한 이유 - AI 모델과 학습 데이터셋의 규모가 빠르게 증가하고, 프런티어 모델 출시 주기도 수개월에서 수주로 단축되고 있다. - GPU 성능은 약 2년마다 세 배 수준으로 향상된 반면, 스토리지와 네트워크 성능 향상은 상대적으로 느렸다. - 스토리지 병목은 다음과 같은 문제를 일으킨다. - GPU가 데이터를 기다리며 유휴 상태가 됨 - 학습 시간과 인프라 비용이 증가함 - 여러 리전에 분산된 GPU로 데이터를 이동·적재하는 데 시간이 걸림 - 연구자가 실험을 반복하는 속도가 느려짐 - Meta는 이러한 문제를 해결하기 위해 BLOB 스토리지를 두 가지 목표에 맞춰 발전시켰다. - GPU 활용률 최대화 - AI 연구 반복 속도, 즉 연구 생산성 최대화 ## Meta의 기존 스토리지 계층 - Meta의 스토리지 서비스는 Facebook, Instagram, Reality Labs, Meta AI, 광고, 데이터 웨어하우스 등 다양한 서비스에 사용된다. - 기반 계층인 **Tectonic**은 수평 확장 가능한 블록 스토리지 패브릭이다. - 소거 코드(erasure coding)를 이용해 높은 내구성과 가용성을 제공한다. - HDD와 플래시 등 여러 미디어 계층을 지원한다. - 핫·웜·콜드 데이터를 적절히 배치해 테넌트 간 I/O 효율을 관리한다. - 그 위의 BLOB 스토리지는 전역적으로 확장 가능한 저장소 인터페이스를 제공하며, 내구성과 가용성 사이의 정책적 선택을 지원한다. - 과거에는 Tectonic 위에 NFS와 유사한 파일 시스템 인터페이스를 제공해 Llama 학습을 수행했지만, 최근 학습 스택은 대규모 데이터 레이크에 대한 통합 접근성과 고성능을 위해 BLOB 인터페이스로 점진적으로 이동하고 있다. ## GPU 학습에서 지연시간이 중요한 이유 - 수십만 개의 GPU가 대규모 데이터셋을 여러 에폭에 걸쳐 반복 처리한다. - 각 GPU 호스트의 데이터로더는 GPU가 현재 배치를 처리하는 동안 다음 배치를 미리 읽어 계산과 I/O를 겹친다. - 대부분의 요청이 빠르더라도 일부 요청의 지연시간이 크게 튀면 GPU가 데이터를 기다리며 멈출 수 있다. - 일정한 학습 스텝마다 GPU들이 상태를 동기화하므로, 단 하나의 느린 GPU도 전체 학습 스텝과 클러스터의 진행을 지연시킨다. - 따라서 평균 지연시간보다 **pMax와 같은 최악 구간의 지연시간을 낮고 예측 가능하게 유지하는 것**이 중요하다. ## 기존 BLOB 아키텍처의 한계 - 기존 BLOB 스토리지는 여러 서비스 계층을 덧붙이는 방식으로 발전했으며, 각 계층이 별도의 상태와 메타데이터 저장소를 보유했다. - `getObject("/bucket/path")` 요청은 다음과 같은 여러 계층을 거쳐야 했다. - API 서버가 요청 수신 - namelayer, volumeslayer, containerlayer 등에서 메타데이터 조회 - 경로를 `(blockId, offset, size)` 목록으로 변환 - Tectonic에서 데이터를 가져온 뒤 API 서버가 클라이언트로 프록시 - 메타데이터 조회가 여러 리전을 넘나들 수 있고, 어느 한 단계라도 느리면 전체 지연시간이 증가했다. - 전통적인 HDD 기반 워크로드에서는 수백 밀리초의 메타데이터 지연이 큰 문제가 아니었지만, 플래시 기반 AI 스토리지에서는 데이터 접근 자체가 밀리초 단위이므로 메타데이터 조회가 주요 병목이 되었다. ## AI 시대에 달라진 설계 요구사항 - **성능과 지연시간** - 기존 서비스는 평균적인 성능이면 충분했지만, AI는 높은 처리량과 pMax까지 예측 가능한 지연시간을 요구한다. - **가용성과 내구성** - 기존에는 리전 장애에도 대응하기 위해 데이터와 메타데이터를 기본적으로 전역 복제했다. - AI는 높은 가용성을 원하지만, 모든 데이터를 전역 복제하는 설계가 항상 필요한 것은 아니다. - **비용 효율** - 기존 스택은 HDD의 바이트당 비용을 최소화하는 데 최적화됐다. - AI는 높은 IOPS 때문에 플래시가 필요하며, 스토리지 계산 비용보다 GPU 계산 비용이 훨씬 커졌다. - **전력 효율** - AI 데이터센터는 공간보다 전력 제약이 커지고 있다. - 스토리지에 사용하는 전력은 GPU에 사용할 수 없는 전력이므로, 프록시와 불필요한 계층을 줄여야 한다. ## 통합 메타데이터와 직접 데이터 스트리밍 Meta는 AI 워크로드에 맞춰 스토리지 기반을 다시 설계했다. - **통합 메타데이터 스키마** - 여러 계층에 분산돼 있던 메타데이터를 하나의 평탄한 스키마로 통합했다. - ZippyDB를 기반으로 경로와 실제 저장 위치의 매핑을 관리한다. - 청크 단위로 경로를 저장 주소로 변환하는 조회를 O(1)에 가깝게 수행할 수 있게 됐다. - **데이터 플레인 프록시 제거** - API 서버가 데이터를 중계하지 않고, 클라이언트 SDK가 스토리지 서버에서 직접 바이트를 스트리밍하도록 변경했다. - 불필요한 데이터 복사와 네트워크 홉을 줄였다. - 전력 사용량을 줄이면서 처리량을 높이고 지연시간을 낮출 수 있다. - **팻 클라이언트 SDK** - SDK에 Tectonic `BlockClient`를 내장했다. - 클라이언트는 먼저 `getReadPlan("/bucket/path")`을 호출해 읽기 계획을 얻는다. - API 서버는 메타데이터를 조회해 `(blockId, offset, size)` 정보를 반환한다. - 이후 SDK가 Tectonic 블록에서 데이터를 직접 읽는다. - **리전 단위 배포** - BLOB 스택을 전역 서비스로만 운영하지 않고, GPU가 위치한 각 AI 리전에 함께 배치한다. - 데이터와 GPU의 물리적 거리를 줄여 리전 간 데이터 이동과 지연시간을 줄인다. - 이 구조는 Tectonic 위에 추가되는 오버헤드를 사실상 제거하고, 데이터 프록시를 없애 전력 예산도 준수하도록 설계됐다. ## 실용적인 결론 AI 학습용 스토리지는 단순히 저장 용량이나 평균 처리량을 늘리는 것만으로 충분하지 않다. 메타데이터 경로를 단순화하고, 데이터 프록시를 제거하며, GPU와 가까운 곳에 스토리지를 배치하고, 최악 지연시간을 관리해야 한다. 특히 플래시 기반 AI 환경에서는 전통적인 글로벌 복제·다계층·중앙 프록시 구조보다 워크로드에 맞춘 지역성, 직접 스트리밍, 예측 가능한 지연시간이 더 중요한 설계 기준이 된다.

원문 읽기(새 탭에서 열림)
github1분 읽기큐레이션 요약

이번 주에 모든 GitHub 유지 관리자가 활성화해야 할 6가지 보안 설정

Joseph은 사이버보안과 AI 분야에서 개발자들이 안전한 소프트웨어를 만들도록 돕는 전문가다. 오픈소스 게임, 영상, 강연을 통해 보안 지식을 실용적으로 전달하며, 전 세계 개발자와 청중에게 큰 영향력을 미치고 있다. ### 사이버보안 및 AI 분야의 전문성 - 개발자가 보안을 고려해 소프트웨어를 구축할 수 있도록 콘텐츠와 소프트웨어를 개발한다. - 사이버보안과 AI를 결합한 실용적인 지식을 전달하는 인물로 소개된다. ### 오픈소스 보안 교육 - 오픈소스 게임 `gh.io/scg`를 제작했다. - 이 게임은 10,000명 이상의 개발자가 미래에도 활용 가능한 보안 역량을 익히는 데 기여했다. ### 대중적인 보안 콘텐츠 - Joseph의 영상 콘텐츠는 누적 280만 회 이상의 조회수를 기록했다. - 복잡한 보안 주제를 쉽게 설명하고, 개발자가 바로 적용할 수 있는 실용적인 조언을 제공한다. - 콘텐츠는 전 세계 audience를 대상으로 한다. ### 국제적인 강연 활동 - 최근 4년간 25개국에서 총 79회의 강연을 진행했다. - 전문적인 통찰력과 활기찬 무대 진행으로 청중의 관심을 끌었다. 개발자라면 Joseph의 오픈소스 게임이나 영상을 활용해 보안 개념을 실습 중심으로 익히고, 강연을 통해 최신 보안 동향과 적용 방법을 접할 수 있다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

AI 검색을 더 스마트하게 만들기

AI 검색의 확산으로 사용자는 원문 링크를 방문하지 않고 요약된 답변만 소비하게 되었으며, 기존의 “콘텐츠 제공과 방문자·수익의 교환” 구조가 흔들리고 있다. Cloudflare는 단순한 AI 크롤러 차단을 넘어, 더 효율적인 검색 크롤링과 콘텐츠 사용량에 따른 창작자 보상 체계를 구축해야 한다고 주장한다. 이를 위해 콘텐츠 최신성 신호를 활용한 검색 개선과 ‘크롤링당 지불’에서 ‘사용당 지불’로의 전환을 추진한다. ### AI 검색이 만든 기존 수익 모델의 위기 - 전통적으로 검색엔진은 웹사이트를 크롤링하고 방문자를 보내는 방식으로 콘텐츠 제공자와 상호 이익을 만들었다. - AI 검색·답변 엔진은 웹페이지를 읽고 직접 요약하므로 사용자가 원문 사이트를 방문할 필요가 줄어든다. - 2025년 Pew Research Center 조사에 따르면: - Google에 AI 요약이 표시되면 일반 검색 결과 링크 클릭률은 8%에 그쳤다. - AI 요약 안의 링크 클릭률은 1%에 불과했다. - 콘텐츠 제공자는 AI 검색을 차단하면 발견 가능성이 낮아지고, 허용하면 콘텐츠는 활용되지만 방문자와 수익은 줄어드는 선택을 강요받고 있다. ### 차단을 넘어선 새로운 인터넷 거래 구조 - Cloudflare는 투명성, 통제권, 책임 있는 봇 운영을 기본 원칙으로 제시한다. - 새로운 봇 관리 옵션을 통해 사이트 운영자는 어떤 봇이 접근하고 무엇을 할 수 있는지 제어할 수 있다. - 그러나 차단만으로는 콘텐츠 제작자를 지속적으로 지원할 수 없으므로 다음 두 가지가 필요하다고 본다. - AI 검색이 더 신선하고 품질 높은 콘텐츠를 찾도록 개선 - 콘텐츠가 실제 답변 생성에 사용된 가치에 따라 창작자에게 보상 ### 콘텐츠 최신성 신호로 AI 검색 개선 - Cloudflare는 전 세계 네트워크에서 얻는 신호를 활용하는 연구 프로그램을 시작한다. - 활용하려는 정보에는 다음이 포함된다. - 페이지가 실제로 변경되었는지 여부 - 콘텐츠의 최신성 - 사용자와 봇이 어떤 콘텐츠에 많이 접근하는지 - 사이트 운영자가 공유에 동의한 콘텐츠 신호 - 답변 엔진은 이 정보를 이용해 더 관련성 높고 최신인 콘텐츠를 우선 노출할 수 있다. - 사이트 운영자는 자신의 콘텐츠가 어떤 질문과 AI 결과에 연결되는지 파악할 수 있다. ### 불필요한 크롤링 감소 - Cloudflare 데이터에 따르면 정상적인 봇 크롤링 트래픽의 20% 이상이 변경되지 않은 페이지를 다시 가져오는 데 사용된다. - “이 페이지는 변경되지 않았다”는 신호를 제공하면 크롤러가 불필요한 재방문을 생략할 수 있다. - 이에 따라: - AI 기업의 컴퓨팅 비용이 감소한다. - 사이트 운영자의 서버 부하와 요청 처리 비용이 줄어든다. - 크롤링 규모가 커질수록 누적되는 낭비를 줄일 수 있다. - 이 프로그램은 특정 검색엔진에 종속되지 않으며, 공정하게 참여하는 모든 답변 엔진을 대상으로 한다. - 검색 목적에만 한정되고 콘텐츠 자체를 공유하거나 기초 모델 학습에 사용하는 방식은 아니다. - Cloudflare는 연구 결과와 사이트 운영자에게 발생한 효과를 공개하고, 이후 네트워크 전반에 기능을 확대할 계획이다. ### ‘크롤링당 지불’에서 ‘사용당 지불’로 - Cloudflare의 기존 Pay Per Crawl은 AI 기업이 콘텐츠를 크롤링할 때 게시자에게 비용을 지불하도록 하는 모델이었다. - 하지만 크롤링 횟수만으로는 콘텐츠의 실제 가치를 정확히 측정하기 어렵다. - 한 번 크롤링된 페이지가 수천 개 답변에 인용될 수 있다. - 여러 번 크롤링되어도 실제 검색 결과에는 한 번도 사용되지 않을 수 있다. - 이에 따라 Cloudflare는 콘텐츠가 실제 답변이나 검색 결과에 사용된 횟수에 기반해 보상하는 Pay Per Use 모델을 실험한다. - Ceramic.ai와 You.com 등 AI 기업과 협력하고 있으며, 각 기업의 결제 모델을 Cloudflare 네트워크의 콘텐츠 제공자에게 확장할 수 있도록 지원한다. - Ceramic.ai의 ‘쿼리당 지불’ 모델에서는 게시자가 동의할 경우 자신의 콘텐츠가 검색 결과에 표시될 때마다 보상받는다. - 이 방식은 단순한 봇 접근량이 아니라 콘텐츠가 이용자에게 제공한 실제 가치에 보상이 연결된다는 점에 의미가 있다. ### 실용적인 시사점 콘텐츠 운영자는 AI 봇을 일괄 차단하기보다 봇별 접근 권한과 보상 조건을 구분하는 전략을 검토할 필요가 있다. Cloudflare가 추진하는 최신성 신호와 사용량 기반 보상 모델이 확산되면, 콘텐츠의 발견 가능성을 유지하면서도 AI 검색으로 발생하는 가치 일부를 수익으로 회수할 수 있을 것으로 보인다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

수익화 게이트웨이 출시: x402를 통해 Cloudflare 뒤의 모든 리소스에 요금 부과

Cloudflare는 웹 페이지·데이터셋·API·MCP 도구 등 Cloudflare 뒤의 모든 리소스에 사용량 기반 요금을 부과할 수 있는 Monetization Gateway를 발표했다. 이 게이트웨이는 결제 규칙, 결제 검증, 접근 제어를 엣지에서 처리하며, 출시 시 x402와 스테이블코인을 사용한다. 이를 통해 에이전트가 계정이나 구독 없이 요청 단위로 소액 결제하고, 서비스 제공자는 별도의 결제·정산 시스템 없이 리소스를 수익화할 수 있다. ## 에이전트 중심으로 바뀌는 웹의 수익 모델 - 기존 웹은 콘텐츠를 인간의 관심과 교환하고, 광고·구독·전자상거래로 수익을 창출했다. - AI 에이전트는 광고를 보거나 장기 구독을 유지하기보다, 필요한 페이지·데이터·도구를 한 번 사용하고 이동한다. - AI 크롤러는 방문자를 보내는 횟수보다 훨씬 많은 요청을 발생시킬 수 있어, 기존 광고 모델과 맞지 않는다. - 에이전트 경제에서는 다음과 같은 사용량 기반 과금이 적합하다. - 검색 1회당 수 센트 - 업로드 기본 요금 0.001달러와 MB당 0.01달러 - 성공적으로 해결된 지원 요청 1건당 0.99달러 - 소프트웨어의 자연스러운 과금 단위는 사용자 좌석이나 월 구독이 아니라 요청, 토큰, 작업 결과가 된다. ## 기존 사용량 과금의 한계 - 클라우드와 API는 호출량·사용 시간 기준으로 판매되어 왔지만, 일반적으로 사전에 등록한 고객과 API 키가 필요했다. - 콘텐츠 서비스는 주로 광고에 의존했기 때문에, 신원 확인이 되지 않은 구매자의 초소액 결제를 처리하기 어려웠다. - 결제 수수료와 정산 지연 때문에 결제 금액이 너무 작으면 결제 자체가 더 비싸지는 문제가 있었다. - 사업자는 사용량을 정확하고 감사 가능하게 기록하기 위해 자체 회계·청구 시스템을 구축해야 했다. - 이러한 복잡성 때문에 많은 기업이 구현하기 쉬운 좌석 기반 가격제를 선택했다. ## 스테이블코인과 에이전트 결제 - 에이전트는 한 사람이 처리할 수 없는 수준으로 지속적으로 작업하며, 수천 건의 소액 결제를 자동으로 수행할 수 있다. - 사람이 각 결제를 승인해야 하는 기존 방식은 에이전트 사용 패턴과 맞지 않는다. - Open USD, USDC 같은 스테이블코인은 매우 작은 금액을 낮은 수수료로 전송하고, 1초 이내에 정산할 수 있다. - 따라서 에이전트 환경에서는 소액·고빈도 결제와 사용량 기반 가격제가 적합하다. ## x402의 HTTP 기반 결제 흐름 - x402는 HTTP 상태 코드 `402 Payment Required`를 활용하는 개방형 결제 프로토콜이다. - 기본 흐름은 다음과 같다. - 클라이언트가 결제 보호 리소스를 요청한다. - 서버가 `402` 응답과 함께 가격, 허용 자산, 결제 주소를 전달한다. - 클라이언트가 결제한 뒤 결제 증명을 포함해 요청을 재전송한다. - 퍼실리테이터가 결제를 검증하면 서버가 리소스를 반환한다. - 결제는 별도의 결제 페이지나 API 호출 없이 일반적인 HTTP 요청·응답 안에서 처리된다. - 구매자의 결제 금액은 판매자의 지갑으로 직접 정산되는 P2P 구조다. - 판매자 계정이 없어도 결제 자체가 접근 자격 증명이 되므로, 구매자 온보딩이 필요 없다. - 프로토콜 오버헤드가 작아 1센트 미만의 결제도 가능하며, 스테이블코인과 결합하면 낮은 수수료와 빠른 정산을 기대할 수 있다. ## Monetization Gateway의 역할 - Cloudflare는 결제 정책과 접근 제어를 하나의 컨트롤 플레인에서 관리하도록 지원한다. - 서비스 제공자는 어떤 요청에 결제를 요구할지 Cloudflare 규칙 표현식으로 정의할 수 있다. - 토큰, API, MCP 호출, 데이터 등 기존 Cloudflare 경로를 통과하는 트래픽에 대해 선택적으로 과금할 수 있다. - 결제 검증과 집행은 원본 서버가 아니라 Cloudflare 엣지에서 처리된다. - Cloudflare의 330개 이상 도시에 분산된 네트워크에서 x402 핸드셰이크가 수행되므로 구매자와 가까운 위치에서 처리할 수 있고, 원본 서버의 부하와 지연도 줄일 수 있다. - 계획된 기능에는 다음이 포함된다. - 특정 REST 경로와 HTTP 메서드별 과금 - 예를 들어 `/api/premium/*`의 GET·POST 요청마다 0.01달러 부과 - 작업의 특성에 따른 변동 가격 설정 ## 서비스 제공자에게 주는 이점 - 제공자가 직접 구매자를 등록하거나 API 키·청구 시스템을 운영할 필요가 없다. - 사용량 측정, 결제 교환, 정산이 원본 서버에서 분리된다. - 제공자는 가격, 결제 조건, 접근 규칙, 수익에 집중할 수 있다. - Cloudflare는 기존에 자체 청구 및 고객 분석을 위해 구축한 사용량 회계 역량을 웹 리소스에 적용하려 한다. 실용적으로는 API·데이터·MCP 도구처럼 요청 단위 가치가 분명한 리소스부터 x402 기반 과금을 적용하는 방식이 적합하다. 다만 실제 도입 시에는 스테이블코인 지원 범위, 환불·분쟁 처리, 가격 변동성, 규제 및 회계 처리를 별도로 검토해야 한다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

콘텐츠 독립기념일, 1년 후—에이전틱 인터넷의 비즈니스 모델 구축

AI 확산으로 인터넷의 기존 경제 모델인 “콘텐츠 제공 → 검색 노출 → 추천 트래픽”의 구조가 빠르게 붕괴하고 있다. 사람들은 검색 결과를 직접 방문하기보다 AI가 통합한 답변을 소비하고 있으며, 크롤러의 절반 이상이 AI 학습용으로 사용된다. 이에 Cloudflare는 콘텐츠 접근 통제·투명성·희소성을 통해 콘텐츠 라이선싱 시장을 만들고, 퍼블리셔가 AI 기업과 더 공정하게 거래할 수 있도록 하겠다고 주장한다. ## AI adoption과 오픈 웹의 급격한 변화 - 생성형 AI는 스마트폰보다 2배 이상 빠른 속도로 확산되고 있다. - 약 3.5년 만에 전 세계 25억 명, 즉 인류의 30% 이상이 정기적으로 생성형 AI를 사용하게 됐다. - 인터넷 사용 방식도 바뀌었다. - 온라인에서 정보를 검색하는 1시간 중 실제 오픈 웹에서 보내는 시간은 약 15분에 불과하다. - 여러 웹사이트를 방문해 정보를 비교하는 대신, 사용자는 AI에 질문하고 통합된 답변을 바로 받는다. - 이 변화는 검색 기반 유입에 의존하던 콘텐츠 사업자에게 직접적인 위협이 된다. ## 에이전틱 인터넷과 비인간 트래픽 - 2026년에는 인터넷 트래픽의 50% 이상이 처음으로 비인간 트래픽이 됐다. - AI 에이전트와 크롤러가 정보 검색, 상품 비교, 조사, 업무 수행을 직접 처리하면서 인간 방문자와 자동화된 접근의 경계가 흐려지고 있다. - 콘텐츠 소유자는 자신의 콘텐츠가 누구에게, 어떤 목적으로 사용되는지 파악하기 어려워지고 있다. ## 크롤러의 목적 변화 - 2026년 6월 기준 크롤러 요청의 52%가 AI 학습 목적이었다. - 2025년 봄의 22%에서 크게 증가한 수치다. - 검색·에이전트·학습을 혼합한 크롤러가 전체 활동의 36% 이상을 차지한다. - 순수 검색용 크롤링은 전체에서 작아지고 있지만, 퍼블리셔의 검색 노출에는 여전히 중요하다. - 혼합형 크롤러는 콘텐츠 소유자에게 딜레마를 만든다. - AI 시대에도 발견되려면 크롤링을 허용해야 한다. - 그러나 그 과정에서 핵심 콘텐츠가 보상 없이 AI 학습에 사용될 수 있다. - 따라서 검색을 위한 접근과 AI 학습을 위한 접근을 기술적으로 구분하는 것이 중요해졌다. ## 검색 유입 중심 모델의 붕괴 - 과거에는 콘텐츠를 검색엔진에 제공하면 검색 결과를 통해 방문자가 유입됐고, 그 트래픽이 광고·구독·판매 등의 경제적 가치를 만들었다. - 현재는 콘텐츠가 계속 크롤링되고 사용되지만, 원 출처로 돌아오는 트래픽은 줄어들고 있다. - AI가 원문을 방문하지 않고도 질문에 답하고 제품을 비교하며 업무를 수행하기 때문이다. - 이에 따라 콘텐츠 제작자는 “사람들이 원문을 방문하지 않아도 어떻게 지속 가능한 수익을 만들 것인가”라는 문제에 직면했다. - 일부 퍼블리셔는 검색 유입이 거의 사라지는 상황을 “Google Zero”라고 부르며 대비하고 있다. ## 산업 전반으로 확산되는 영향 - 초기에는 뉴스·미디어 기업이 가장 큰 영향을 받았지만, 현재는 다음 산업으로 확산되고 있다. - 소매 - 소프트웨어 - IT - 금융 - 일부 고크롤링 분야에서는 1년 이내 인간 트래픽이 최대 40% 감소했다. - 인터넷에 독점적이거나 전문적인 정보를 게시하는 모든 조직이 에이전틱 인터넷에 대응해야 한다. - 이 문제는 퍼블리셔만의 문제가 아니라, 인터넷을 기반으로 운영되는 전체 경제와 정보 생태계의 지속 가능성에 영향을 준다. ## 콘텐츠 시장을 만들기 위한 세 가지 요소 Cloudflare는 Content Independence Day 이후 다음 세 가지 방향을 추진했다고 설명한다. - **투명성과 통제** - 사이트 운영자가 자신의 콘텐츠가 어떻게 접근되고 수익화되는지 결정하도록 지원한다. - **희소성 창출** - 무제한 접근을 기본값으로 두지 않고, 콘텐츠 접근을 제한해 소유자의 협상력을 높인다. - **콘텐츠 마켓플레이스** - 콘텐츠 제작자와 AI 기업이 콘텐츠를 발견하고, 라이선스를 협의하며, 콘텐츠 가치를 정할 수 있는 시장을 구축한다. ## 통제와 투명성이 협상력을 만든 방식 - 기존에는 퍼블리셔가 AI 기업의 콘텐츠 접근·사용 방식을 충분히 알기 어려웠다. - Cloudflare의 귀속 분석, 비즈니스 인텔리전스, 집행 도구는 네트워크 수준에서 AI 콘텐츠 소비를 파악하고 통제하도록 했다. - 이는 자발적 규범인 `robots.txt`보다 강력한 집행 수단으로 제시된다. - 운영자는 다음과 같은 데이터를 확보할 수 있다. - LLM이 콘텐츠에 접근하려 한 빈도 - 어떤 경쟁 AI 모델이 크롤링했는지 - 가장 많이 요청된 URL - 크롤링 횟수와 실제 추천 트래픽의 비율 - 이런 데이터는 콘텐츠 접근을 제한해 희소성을 만들고, 라이선스 협상에서 정보 비대칭을 줄인다. - 결과적으로 퍼블리셔는 AI 기업이 콘텐츠를 얼마나 필요로 하는지 근거를 바탕으로 판단하고, 더 유리한 조건을 협상할 수 있게 된다. ## 실용적인 결론 콘텐츠 사업자는 검색 유입만을 성과 지표로 삼기보다 AI 크롤러의 접근 목적과 규모를 측정해야 한다. `robots.txt` 같은 선언적 방식에 더해 접근 제어, 사용량 분석, AI 학습과 검색 접근의 구분, 콘텐츠 라이선싱 정책을 마련하는 것이 필요하다. 앞으로는 콘텐츠를 공개할지 차단할지의 이분법보다, 어떤 용도로 누구에게 어떤 조건으로 제공할지를 관리하는 능력이 핵심 경쟁력이 될 것이다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

내 사이트, 내 규칙: 모든 고객을 위한 새로운 AI 트래픽 옵션

AI 트래픽은 더 이상 “차단할 것인가, 허용할 것인가”의 단순한 문제가 아니며, 웹사이트 운영자는 봇의 목적에 따라 접근을 세분화해 관리해야 한다는 글입니다. Cloudflare는 AI 트래픽을 **검색(Search), 에이전트(Agent), 학습(Training)**으로 분류하고, 각 유형을 개별적으로 허용하거나 차단할 수 있는 기능을 모든 고객에게 제공합니다. 특히 광고가 표시되는 페이지에서는 2026년 9월 15일부터 학습·에이전트 봇은 기본 차단하고, 검색 봇은 기본 허용할 예정입니다. ## AI 봇을 일괄 차단하기 어려운 이유 - 기존에는 AI 기업이 콘텐츠를 학습에 사용하면서도 웹사이트에 방문자나 보상을 돌려주지 않는 문제가 컸습니다. - 이에 Cloudflare는 2025년부터 다음과 같은 대응책을 제공했습니다. - 한 번의 설정으로 AI 봇을 차단하는 **“Block AI Bots”** - 크롤링 건별로 콘텐츠 사용료를 받는 **Pay-Per-Crawl** 마켓플레이스 - 그러나 모든 자동화 트래픽을 차단하면 소규모 사이트는 검색 결과에서 발견될 기회까지 잃을 수 있습니다. - 검색 노출을 얻기 위해 AI 학습까지 허용해야 하는 상황은 대형 검색 사업자에게 유리한 구조를 만들고, 신규 사업자가 봇의 정체를 숨기도록 유도할 수 있습니다. ## AI 대신 봇의 행동을 기준으로 분류 - AI 기술의 범위는 빠르게 변하므로, 봇을 단순히 “AI 봇”인지 아닌지로 구분하는 방식은 오래 유지되기 어렵습니다. - 대신 다음 질문을 기준으로 봇을 평가합니다. - 사이트에서 무엇을 하는가? - 콘텐츠를 어디에 저장하는가? - 나중에 콘텐츠를 어떻게 재공유하는가? - 하나의 봇이 여러 목적을 수행한다면 대표 목적 하나만 기록하지 않고, **모든 목적을 함께 추적**하는 방향을 채택합니다. ## 검색·에이전트·학습의 3가지 분류 ### 검색(Search) - 사이트 콘텐츠를 수집하거나 색인해 나중에 질문에 답하는 데 사용하는 자동화입니다. - 검색 엔진이나 AI 답변 엔진이 사이트 데이터를 미리 데이터베이스화하는 행위가 해당됩니다. - 사이트 운영자는 검색 유입이나 그에 상응하는 보상을 기대할 수 있습니다. - Google 검색처럼 결과 페이지에서 직접 답변을 제공하는 서비스도 이 범주와 관련됩니다. ### 에이전트(Agent) - 사용자를 대신해 실시간으로 작업을 수행하는 자동화입니다. - 예시: - ChatGPT-User 같은 채팅 기반 가져오기 봇 - Gemini 또는 Claude가 브라우저를 조작하는 브라우저 에이전트 - 일반적으로 사람이 요청한 작업을 완료하기 위해 웹 애플리케이션을 방문합니다. - 콘텐츠를 장기적으로 학습하기보다는 특정 시점에 필요한 정보를 조회하거나 거래를 수행하는 것이 핵심입니다. ### 학습(Training) - 콘텐츠를 모델 학습이나 파인튜닝에 사용하기 위해 수집하는 크롤러입니다. - 사이트 데이터가 AI 모델의 내부 구조에 영구적으로 흡수되어 모델의 능력을 개선하는 것이 특징입니다. - 검색처럼 방문자를 되돌려 보내는 목적이 명확하지 않기 때문에, 사이트 운영자가 별도로 차단하거나 보상을 요구할 수 있어야 합니다. ## 목적별로 분리된 크롤러의 필요성 - 하나의 기업이 검색 색인 구축, 사용자 대신 작업 수행, 모델 학습을 모두 한다면 각 목적에 맞는 크롤러를 분리하는 것이 권장됩니다. - 크롤러를 분리하면 사이트 운영자가 다음을 더 명확히 파악할 수 있습니다. - 어떤 이유로 방문했는지 - 어떤 콘텐츠 접근 권한이 필요한지 - 검색은 허용하면서 학습은 차단할 수 있는지 - 일부 크롤러는 여러 목적을 동시에 수행할 수 있으며, Googlebot·Applebot·BingBot처럼 검색과 학습 목적이 결합된 봇이 그 예입니다. ## Cloudflare의 새로운 AI 트래픽 관리 옵션 - Cloudflare는 기존의 일괄적인 **“Block AI Bots”** 설정을 세분화합니다. - 모든 요금제, 무료 요금제를 포함한 고객이 다음 유형을 각각 관리할 수 있습니다. - Search 크롤러 - Agent 크롤러 - Training 크롤러 - 이를 통해 사이트 운영자는 다음과 같은 정책을 설정할 수 있습니다. - 검색 봇은 허용하고 학습 봇은 차단 - 에이전트 접근은 허용하되 특정 콘텐츠에서는 제한 - 모든 유형을 허용하거나 차단 - Cloudflare는 광고 검증, 피드 수집, 에이전트 기반 거래 등 다른 자동화 유형도 분류하고 있지만, 이번 변경의 중심은 세 가지 AI 사용 사례입니다. ## 2026년 9월 15일부터 적용되는 기본값 - 새로 Cloudflare에 등록되는 도메인의 광고 표시 페이지에는 다음 기본 정책이 적용됩니다. - **Training:** 기본 차단 - **Agent:** 기본 차단 - **Search:** 기본 허용 - 광고는 사람이 페이지를 방문해 콘텐츠를 보고 관심을 갖는 것을 전제로 하는 수익 신호입니다. - 따라서 광고 페이지에서는 사람의 관심을 방해하거나 콘텐츠를 재사용할 수 있는 학습·에이전트 봇을 차단하고, 방문자를 유도할 가능성이 높은 검색 봇은 허용한다는 논리입니다. - 여러 목적을 가진 크롤러는 모든 목적에 대한 규칙을 적용받으며, 가장 제한적인 규칙이 우선합니다. - 따라서 Training을 차단한 고객은 검색과 학습을 함께 수행하는 Googlebot, Applebot, BingBot도 차단될 수 있습니다. - 운영자는 9월 15일 이전에 Cloudflare 보안 설정에서 새 기본값을 적용하지 않도록 선택할 수 있습니다. 사이트 운영자는 모든 AI 자동화를 일괄 차단하기보다 검색·에이전트·학습 목적을 구분해 정책을 설정하는 것이 좋습니다. 특히 검색 유입이 중요한 사이트는 Search를 허용하되 Training과 Agent를 별도로 차단하고, Googlebot처럼 다목적 봇이 어떤 규칙을 적용받는지 사전에 점검해야 합니다.

원문 읽기(새 탭에서 열림)
cloudflare3분 읽기큐레이션 요약

Attribution Business Insights로 크롤링의 실체 밝히기

웹사이트의 기존 검색엔진 생태계는 크롤링의 대가로 방문자를 보내는 구조였지만, AI 크롤러의 확산으로 이 균형이 무너지고 있다. AI 봇은 콘텐츠를 대량 수집하면서도 원 사이트로 유입되는 방문자는 거의 제공하지 않아, 게시자는 트래픽·수익·인프라 비용 측면에서 손해를 입을 수 있다. Cloudflare는 이를 판단할 수 있도록 봇별 활동과 크롤링 대비 추천 비율을 보여주는 **Attribution Business Insights** 대시보드를 공개했다. ## 검색엔진 시대에서 ‘제로 클릭’ 시대로 - 전통적인 검색엔진은 콘텐츠를 크롤링한 뒤 사용자에게 원문 페이지를 추천했다. - 게시자는 검색 유입을 통해 광고, 제휴, 구독 수익과 독자 관계를 확보할 수 있었다. - 검색엔진의 크롤링 횟수와 추천 방문자 수 사이에는 비교적 균형 잡힌 관계가 있었다. - 그러나 AI 챗봇은 원문을 수집해 답변을 직접 생성하면서 사용자를 원 사이트로 보내지 않는 ‘제로 클릭’ 환경을 만들고 있다. - 이에 따라 인터넷의 최적화 전략도 SEO에서 AEO(Answer Engine Optimization), GEO(Generative Engine Optimization) 중심으로 변화하고 있다. ## AI 크롤러의 불균형한 트래픽 - Cloudflare가 관찰한 주요 AI 크롤러의 크롤링 대비 추천 방문 비율은 약 **118:1에서 거의 50,000:1**까지 나타났다. - 일부 AI 크롤러는 방문자 한 명을 보내기 위해 콘텐츠를 수십만 번에 가깝게 요청할 수 있다. - 게시자는 두 가지 손실을 동시에 부담한다. - 광고 노출, 직접 방문, 독자 관계 등 수익으로 이어지는 트래픽 감소 - 상업적 가치가 불분명한 봇 요청을 처리하는 서버·대역폭 비용 증가 - 따라서 모든 크롤러를 허용해 노출을 기대하는 기존 전략은 더 이상 합리적이지 않을 수 있다. ## Attribution Business Insights 대시보드 - Cloudflare Bot Management 고객에게 제공되는 대시보드다. - 복잡한 로그 분석이나 수동 필터링 없이 사이트의 봇 트래픽을 사업 관점에서 파악하도록 설계됐다. - 주요 제공 정보는 다음과 같다. - 콘텐츠 페이지에 접근한 인간 사용자와 봇의 전체 트래픽 비교 - 사이트 전체 및 봇 운영자별 크롤링 대비 추천 방문 비율 - 24시간, 7일, 30일 단위의 비율 변화 - 트래픽 규모가 큰 봇 목록 - 봇의 국가, 사용 대역폭, 현재 허용·차단 상태 - 이를 통해 어떤 봇이 콘텐츠를 많이 사용하고 실제 방문자를 유도하는지 확인할 수 있다. ## 행동 기반 AI 크롤러 분류 Cloudflare는 AI 봇을 단순히 ‘AI 크롤러’로 묶지 않고 목적에 따라 분류한다. - **Training** - 차세대 대규모 언어 모델을 학습하기 위해 콘텐츠를 수집하는 크롤러 - **Search** - RAG(검색 증강 생성)에 사용할 데이터베이스를 갱신하는 크롤러 - **Agent** - 최종 사용자의 요청에 답하기 위해 에이전트형 상호작용에서 콘텐츠를 조회하는 크롤러 - 이러한 분류를 통해 게시자는 단순한 요청량뿐 아니라 콘텐츠가 어떤 용도로 사용되는지도 판단할 수 있다. ## 데이터에서 콘텐츠 비즈니스 전략으로 - 사이트 운영자는 보안 전문가가 아니더라도 대시보드의 요약 지표만으로 현재 콘텐츠 보안 정책의 효과를 점검할 수 있다. - 더 자세한 분석이 필요한 경우 봇 운영자별로 다음 정보를 비교할 수 있다. - 봇 유형 - 크롤링 대비 추천 비율 - 전체 요청량 - 현재 허용 또는 차단 정책 - 이 데이터는 AI 기업과의 협상이나 콘텐츠 라이선스 재검토에도 활용할 수 있다. - 예를 들어 특정 회사의 크롤링량이 다른 회사보다 20배 많거나, 이미 콘텐츠 사용료를 지급하는 회사가 있다면 이를 근거로 접근 정책과 계약 조건을 조정할 수 있다. - 핵심은 AI 트래픽을 일괄적으로 허용하거나 차단하는 것이 아니라, 실제 사업 가치와 비용을 기준으로 운영하는 것이다. ## 실용적인 적용 방향 게시자는 봇별 크롤링량, 추천 방문자, 대역폭 비용을 함께 비교해 허용·제한·차단 정책을 세워야 한다. 특히 Training, Search, Agent 목적을 구분하고, 유입 가치가 낮은 대량 크롤러에는 속도 제한이나 차단을 적용하며, 수익 또는 라이선스와 연결되는 봇에는 차별화된 접근 정책을 검토하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)
gitlab2분 읽기큐레이션 요약

GitLab 패치 릴리스: 18.8.11 | GitLab 문서

2026년 7월 1일 공개된 GitLab 18.8.11은 Rails 7.2 업그레이드로 발생한 데이터베이스 연결 누수 문제를 해결하는 패치 릴리스입니다. 데이터베이스 로드 밸런싱을 사용하는 환경의 안정성을 높이기 위한 긴급 패치이며, 보안 수정이나 신규 마이그레이션은 포함하지 않습니다. 다중 노드 배포에서는 일반적으로 다운타임 없이 업그레이드할 수 있습니다. ### 데이터베이스 연결 누수 수정 - 데이터베이스 로드 밸런서를 사용할 때 연결이 커넥션 풀로 정상 반환되지 않는 회귀 버그를 수정했습니다. - 해당 문제는 Rails 7.2 업그레이드 이후 발생했습니다. - 연결 누수가 지속되면 사용 가능한 데이터베이스 연결이 고갈되어 GitLab 성능 저하나 장애로 이어질 수 있습니다. - GitLab 18.8 필수 업그레이드 구간의 안정성을 확보하기 위해 정식 일정 외 패치로 제공되었습니다. ### 업그레이드 영향 - 신규 데이터베이스 마이그레이션은 포함되지 않습니다. - 다중 노드 배포 환경에서는 일반적으로 서비스 중단이 필요하지 않습니다. - Omnibus 패키지는 업그레이드 규모와 관계없이 기본적으로 다음 작업을 수행합니다. - GitLab 중지 - 마이그레이션 실행 - GitLab 재시작 - 업그레이드 시 자동 재구성을 건너뛰려면 다음 파일을 생성할 수 있습니다. ```text /etc/gitlab/skip-auto-reconfigure ``` - 이 설정은 업그레이드 작업에만 적용됩니다. ### 버전 및 구독 안내 - 대상 버전: - GitLab Community Edition 18.8.11 - GitLab Enterprise Edition 18.8.11 - 이번 릴리스에는 보안 수정 사항이 없습니다. - 업데이트 절차는 GitLab 공식 업데이트 페이지를 따라야 합니다. - Premium 및 Ultimate 기능은 유료 구독이 필요하며, 별도로 GitLab.com을 이용할 수도 있습니다. 데이터베이스 로드 밸런싱을 사용하는 GitLab 18.8 환경이라면 연결 고갈 위험을 줄이기 위해 18.8.11로 업데이트하는 것이 권장됩니다. અપ그레이드 전에는 자동 재구성 및 재시작 정책을 확인하고, 운영 환경에서는 공식 업데이트 절차에 따라 진행하는 것이 안전합니다.

원문 읽기(새 탭에서 열림)
figma4분 읽기큐레이션 요약

Canvas 기반 제품에 접근성 구축하기 | Figma 블로그

Figma는 캔버스 렌더링으로 무한 줌과 실시간 협업 같은 성능을 얻었지만, 브라우저의 기본 접근성 기능을 사용할 수 없게 되었다. 이를 해결하기 위해 디자인의 scenegraph를 기반으로 접근성 정보를 담은 내부 트리와 이를 반영하는 Mirror DOM을 구축했다. 그 결과 스크린 리더 사용자는 Figma 파일을 탐색·편집하고, 캔버스 선택 상태와 키보드 탐색을 연동하며, 비시각적 변경 사항도 안내받을 수 있다. ## 캔버스 기반 제품의 접근성 문제 - Figma 캔버스는 일반 HTML/DOM 대신 자체 렌더링 시스템을 사용한다. - 이 방식은 전통적인 웹 앱보다 높은 성능을 제공한다. - 무한 줌 - 실시간 멀티플레이어 협업 - 게임과 유사한 고성능 그래픽 처리 - 반면 브라우저가 자동으로 생성하는 접근성 트리를 활용할 수 없다. - 실제 캔버스에는 여러 디자인 레이어가 있어도 포커스를 유지하는 `<input>` 요소 하나만 존재하므로, 스크린 리더가 인식할 구조가 거의 없었다. ## 접근성 트리 합성 - 브라우저의 접근성 트리는 DOM, 시맨틱 HTML, ARIA 속성, 계산된 상태를 바탕으로 생성된다. - Figma는 이 기능을 되살리기 위해 실제 캔버스와 별도로 접근성용 DOM 요소를 합성했다. - 이 구조를 통해 스크린 리더가 Figma 파일의 레이어를 탐색하고 편집할 수 있게 했다. - 시각적 렌더링과 접근성 정보를 분리해, 캔버스의 성능을 유지하면서 브라우저의 보조 기술과 연동한다. ## 네 가지 핵심 시스템 Figma의 접근성 구현은 다음 시스템들이 협력하는 구조다. - **내부 접근성 트리** - 각 디자인 레이어의 접근성 정보를 캐시한다. - 변경이 발생할 때 전체를 다시 만들지 않고 필요한 부분만 갱신한다. - **Mirror DOM React 컴포넌트** - 내부 접근성 트리를 참조해 실제 DOM 요소를 생성한다. - 각 레이어에 대응하는 접근성 요소를 재귀적으로 렌더링한다. - **양방향 선택 동기화** - 캔버스에서 노드를 선택하면 대응하는 DOM 요소에 포커스를 이동한다. - 스크린 리더나 키보드로 DOM 요소를 탐색하면 캔버스 선택 상태도 갱신한다. - **공지 시스템** - 탐색 외의 변경 사항을 사용자에게 알린다. - 예를 들어 객체 이동, 도구 전환 등 시각 사용자에게는 명확하지만 스크린 리더 사용자는 놓칠 수 있는 변화를 안내한다. ## 문맥에 따른 접근성 요약 - 각 디자인 레이어마다 스크린 리더가 읽을 수 있는 **접근성 요약(accessible summary)** 을 생성한다. - 같은 디자인이라도 사용 중인 애플리케이션 문맥에 따라 요약 방식이 달라진다. - 프로토타입을 보는 상황에서는: - 편집 관련 기능을 대부분 제외한다. - 텍스트 필드의 내용이나 클릭 동작이 있는 요소의 버튼 역할처럼 최종 사용자에게 필요한 정보만 제공한다. - 문서를 편집하는 상황에서는: - 오토레이아웃 프레임처럼 편집에 필요한 구조도 접근성 트리에 포함한다. - 레이어별 요약을 만든 뒤 트리를 위에서 아래로 순회하며, 접근성에서 제외된 노드는 제거하고 하위 노드를 상위 구조에 병합한다. - 문서 최초 로딩 시에는 전체 접근성 트리를 구성하지만, 이후에는 편집된 부분만 수술적으로 갱신해 비용을 줄인다. ## Mirror DOM의 재귀적 렌더링 - React 기반 `Mirror DOM` 컴포넌트가 접근성 트리의 각 레이어를 DOM으로 변환한다. - 각 컴포넌트는 특정 레이어의 접근성 요약을 구독한다. - 요약에서 다음 정보를 가져와 DOM 요소를 생성한다. - `label`: 스크린 리더가 읽을 이름 - `role`: 버튼, 입력 필드 등 요소의 의미 - `children`: 하위 레이어 - 하위 레이어는 같은 컴포넌트를 재귀적으로 호출해 DOM 트리를 구성한다. - 내부 접근성 트리를 최소 단위로 갱신하면 React가 실제 DOM 변경도 최소화할 수 있다. ## 시각적 콘텐츠와 접근성 콘텐츠의 분리 - Mirror DOM은 화면에 보이지 않지만 보조 기술이 해석할 수 있는 구조를 제공한다. - 일반적인 visually hidden 스타일을 사용하지 않는 점이 특징이다. - 캔버스 기반 제품에서는 접근성용 DOM이 페이지 레이아웃이나 캔버스 렌더링에 영향을 주지 않도록 별도의 방식으로 관리해야 한다. - 핵심은 시각적 UI를 억지로 HTML로 대체하는 것이 아니라, 보조 기술이 필요로 하는 의미 구조를 별도로 합성하는 것이다. 캔버스 기반 제품에 접근성을 추가할 때는 브라우저가 자동으로 제공하던 기능을 직접 재구축해야 한다. 특히 내부 접근성 트리, 점진적 갱신, 시각 UI와 DOM의 양방향 상태 동기화를 함께 설계하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
datadog4분 읽기큐레이션 요약

대규모 환경에서 데이터 완전성을 측정하는 방법

고객의 대시보드·알림·AI 에이전트가 올바르게 작동하려면 Datadog에 유입된 모든 텔레메트리 데이터가 완전하게 전달되어야 한다. Datadog은 수백 개의 분산 파이프라인과 고객별 경로를 실시간으로 추적하기 위해 파이프라인을 세그먼트로 나누고, 각 payload의 생성과 확인(acknowledgment)을 비교한다. 이 방식은 중복·순서 뒤바뀜·지연 데이터가 존재하는 환경에서도 세그먼트별 문제 위치와 전체 파이프라인의 완전성을 계산하도록 설계되었다. ## Datadog에서 데이터 완전성의 의미 - 완전한 데이터란 Datadog에 들어온 모든 payload가 고객에게 제공되는 상태다. - 대상 payload에는 다음과 같은 텔레메트리 데이터가 포함된다. - 메트릭 데이터 포인트 - 로그 - 트레이스 - 기타 수집 데이터 - 완전성은 전역 단위가 아니라 **고객별로** 판단해야 한다. - 고객마다 파티셔닝, 격리 전략, 트래픽 패턴이 다르다. - 따라서 동일한 리전에서도 데이터가 통과하는 경로가 매우 다양하다. - 시스템은 데이터가 누락되었는지뿐 아니라 다음도 즉시 설명해야 한다. - 어느 구간에서 문제가 발생했는가 - 어떤 서비스가 비정상인가 - 문제가 고객에게 영향을 주었는가 - 진단 결과는 운영자가 수 초 안에 대응하거나 자동화된 시스템이 조치하는 데 사용된다. ## 워터마크 방식의 한계 - 초기에는 Flink 같은 스트리밍 시스템의 워터마크 방식을 고려했다. - 데이터가 일정 시간 안에 도착한다고 가정하고 워터마크를 전진시킨다. - 특정 임계점을 넘으면 해당 시점까지 데이터가 완전하다고 판단한다. - 그러나 Datadog 환경에서는 고객이 임의로 지연된 데이터를 보낼 수 있다. - 또한 다음과 같은 특수 상황이 워터마크를 신뢰하기 어렵게 만든다. - 파이프라인 내부의 루프 - 트래픽 재생 - 예측하기 어려운 데이터 지연 - 따라서 데이터 도착 시점만으로 전체 파이프라인의 완전성을 판단하는 방식은 필요한 보장을 제공하지 못했다. ## 파이프라인을 세그먼트로 분할 - Datadog은 전체 파이프라인을 여러 개의 작은 세그먼트로 나누어 추적한다. - 예를 들어 다음과 같은 흐름이 있을 수 있다. - intake → Kafka → processing → Kafka → router - 각 서비스 내부와 서비스 간 연결을 별도의 세그먼트로 정의한다. - `intake-in → intake-out` - `intake-out → processing-in` - 각 세그먼트에서 다음을 독립적으로 측정한다. - 세그먼트에 들어온 payload 수 - 세그먼트에서 나간 payload 수 - 이 구조의 장점은 다음과 같다. - 누락이 발생한 위치를 구체적으로 찾을 수 있다. - 개별 세그먼트 결과를 합쳐 end-to-end 완전성을 계산할 수 있다. - 파이프라인에 분기 경로가 추가되거나 제거되어도 전체 시스템을 재정의할 필요가 적다. ## 생성 이벤트와 확인 이벤트로 payload 추적 - payload가 세그먼트에 들어오면 `create` 이벤트를 기록한다. - payload가 세그먼트를 빠져나오면 동일한 식별자에 대한 `acknowledgment` 이벤트를 기록한다. - 두 이벤트의 수를 비교해 세그먼트에서 데이터가 유실되었는지 판단한다. - 재시도와 중복 처리를 위해 모든 payload에 고유 식별자를 부여한다. ### 시간 버킷을 이용한 멱등성 - 분산 시스템에서는 이벤트가 중복되거나 순서가 뒤바뀐 채 도착할 수 있다. - 이를 처리하기 위해 완전성을 payload가 Datadog에 처음 들어온 시점의 **시간 버킷** 단위로 계산한다. - 고객 시스템의 시계가 아니라 Datadog이 관리하는 타임스탬프를 사용한다. - 각 버킷에서 payload의 세그먼트별 상태를 관리한다. - 생성됨 - 확인됨 - 생성 이벤트보다 확인 이벤트가 먼저 도착함 - 같은 버킷에서 동일한 식별자의 `create` 또는 `acknowledgment`가 반복되면 기존 상태를 확인하고 중복 이벤트를 무시한다. - 이 방식은 별도의 분산 조정 없이도 카운트를 멱등적으로 유지한다. ## 세그먼트 비율로 전체 완전성 계산 - 각 세그먼트의 완전성은 다음 비율로 정의된다. `세그먼트 완전성 = 세그먼트를 빠져나간 payload 수 ÷ 세그먼트에 들어온 payload 수` - 순차적으로 연결된 파이프라인에서는 각 세그먼트의 완전성 비율을 곱한다. - 예를 들어 두 세그먼트의 완전성이 각각 98%, 96%라면 전체 완전성은 다음과 같다. `98% × 96% = 94%` ### 병렬 분기 처리 - 병렬 분기를 단순히 하나의 파이프라인으로 취급하면 문제가 생긴다. - 예를 들어 APM 트레이스가 다음 두 서비스로 동시에 전달될 수 있다. - 오류율·요청 수를 계산하는 서비스 - 지연 시간 분포를 계산하는 서비스 - 한 분기가 늦게 처리되면 다른 분기에서 이미 사용 가능한 데이터까지 전체적으로 불완전한 것처럼 보일 수 있다. - Datadog은 병렬 분기를 **데이터 처리량에 비례한 가중 평균**으로 결합한다. - 각 분기의 기여도를 해당 분기가 처리하는 payload 양에 따라 산정한다. - 데이터가 많은 분기는 전체 결과에 더 큰 영향을 준다. - 예시에서는 한 분기가 98%와 96%의 두 세그먼트를 거쳐 94% 완전성을 보이고, 다른 분기는 100%를 처리한다. - 이후 각 분기의 처리량을 기준으로 가중치를 적용해 전체 파이프라인 완전성을 계산한다. ## 실용적인 결론 대규모 분산 수집 시스템에서는 전체 파이프라인을 한 번에 관찰하기보다, payload의 이동을 세그먼트별로 계측하는 편이 문제 위치와 고객 영향을 더 정확히 파악할 수 있다. 특히 고유 식별자, 시간 버킷, 멱등적인 상태 추적을 함께 사용하면 재시도와 지연 데이터가 많은 환경에서도 실시간 완전성 검증이 가능하다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

스킬이 있으신가요? Figma Agent를 더 나은 협업자로 만들기 | Figma 블로그

Figma의 “스킬”은 팀의 업무 방식과 전문 지식을 자연어 지침으로 저장해 두고, `/` 명령으로 Figma 에이전트에서 반복 사용할 수 있게 하는 기능이다. 디자인 시스템이 컴포넌트와 UI 패턴을 제공한다면, 스킬은 브랜드 문체·접근성·리뷰 절차·개인별 피드백 방식 같은 조직의 맥락을 더한다. Figma는 이를 통해 에이전트를 단순한 생성 도구가 아니라 팀의 작업 방식을 이해하고 협업하는 파트너로 활용할 수 있다고 설명한다. ## 스킬과 디자인 시스템의 역할 구분 - 디자인 시스템은 에이전트가 사용할 컴포넌트, 패턴, UI 요소를 제공한다. - 스킬은 그 위에 팀의 전문 지식과 업무 규칙을 적용한다. - 적용할 수 있는 예시는 다음과 같다. - 브랜드 보이스와 UX 라이팅 규칙 - 컴플라이언스 및 접근성 기준 - 디자인 리뷰 절차 - 제품 원칙과 의사결정 기준 - 디자인 시스템을 특정 업무 흐름 안에서 호출하는 방법 - 한 번 만든 스킬은 팀이나 조직에 게시해 여러 사람이 반복 사용할 수 있다. ## 필요할 때 받는 두 번째 의견 스킬은 특정 관점으로 디자인이나 문구를 검토해 아이디어의 약점을 찾고 더 나은 질문을 하도록 돕는다. - **이해관계자의 피드백 방식 모사** - 공개 코멘트, 과거 크리틱, 파일에 남은 메모 등을 예시로 제공한다. - 에이전트가 특정 인물의 피드백 스타일을 적용하도록 만들 수 있다. - Figma는 CEO Dylan의 코멘트 방식을 반영해, 공식 리뷰 전에 작업을 점검하는 스킬을 만들었다. - **UX 라이팅 기준 적용** - 스타일 가이드에 따라 대문자 사용, 구두점 등 문구의 일관성을 1차 검토한다. - 작성자는 단순한 형식 오류보다 더 중요한 내용과 메시지에 집중할 수 있다. - **처음 사용하는 사람의 관점 제공** - 제품을 잘 아는 디자이너가 놓치기 쉬운 마찰 지점과 부족한 설명을 찾는다. - 신규 사용자가 경험을 이해할 수 있는지 점검하는 데 유용하다. ## 한 번 만들고 반복해서 사용하는 업무 팀이 매번 비슷한 방식으로 수행하는 의식이나 절차는 스킬로 만들 가치가 있다. - **`/catch-me-up`** - 파일이나 프로젝트의 최근 활동을 요약한다. - 한동안 자리를 비운 사람이 댓글과 변경 내역을 직접 추적하지 않고 빠르게 상황을 파악할 수 있다. - **크리틱 준비 체크리스트** - 에이전트가 페르소나, 작업 범위, 크리틱 참석자 등 프로젝트 맥락을 질문한다. - 수집한 정보를 바탕으로 크리틱 페이지와 토론용 질문을 만든다. - Figma의 스킬은 Nielsen Norman Group의 모범 사례를 참고해 더 깊은 논의를 유도하는 질문을 구성한다. - **크리틱 회고** - 회의에서 나온 피드백을 주제별로 정리한다. - 결정 사항, 후속 작업, 보류된 항목을 구분해 실행 계획으로 만든다. - 결과를 캔버스의 recap 카드나 Slack 스레드에 공유할 수 있어 회의 후 정보가 유실되는 것을 줄인다. ## 팀의 암묵지를 재사용 가능한 지침으로 전환 - 팀만 알고 있던 업무 방식이나 반복 프롬프트를 자연어 지침으로 문서화한다. - 매번 같은 설명을 다시 입력하지 않고 `/스킬이름`으로 호출한다. - 개인의 머릿속에 머물던 리뷰 기준과 작업 절차를 조직 전체가 사용할 수 있는 자산으로 바꾼다. - 스킬을 만들 때는 실제 피드백, 스타일 가이드, 기존 산출물처럼 구체적인 사례를 함께 제공할수록 팀의 방식에 가까운 결과를 얻을 수 있다. 팀에서 반복되는 작업이나 동일한 검토 기준이 있다면, 이를 먼저 작은 스킬로 만들어 테스트하는 것이 좋다. 특히 온보딩, 크리틱 준비·회고, 문구 검수처럼 입력과 결과가 비교적 명확한 업무부터 시작하면 효과를 확인하기 쉽다.

원문 읽기(새 탭에서 열림)
figma4분 읽기큐레이션 요약

검증할 수 있는 신뢰: Figma, 이제 ISO 42001 인증 획득 | Figma 블로그

Figma는 AI 거버넌스 관리 체계(AIMS)에 대해 국제 표준 ISO/IEC 42001:2023 인증을 획득했다고 발표했습니다. 이번 인증은 자체 설명이 아니라 ANAB 공인 인증기관인 Schellman의 독립적인 심사를 통해 정책, 위험 관리, 데이터 관행, 기술적 보호조치가 실제로 운영되고 있음을 검증받았다는 의미입니다. Figma는 이를 통해 규제 산업 고객이 AI 관련 공급업체 위험 평가와 규제 보고에 활용할 수 있는 객관적 근거를 제공한다고 강조합니다. ## ISO/IEC 42001과 AI 관리 시스템 - ISO/IEC 42001은 2023년 12월 제정된 AI 관리 시스템 국제 표준입니다. - 정보보호 관리체계 표준인 ISO 27001과 유사하게, 조직이 AI를 책임 있게 개발·배포·운영하기 위해 필요한 정책과 절차, 통제 항목을 정의합니다. - AI 관리 시스템(AIMS)은 다음 활동을 관리하는 운영 기반입니다. - AI 기능의 설계와 개발 - 제품 내 AI 배포 - 데이터 및 위험 관리 - 성능과 영향 모니터링 - 인간의 감독과 책임 체계 유지 ## 자체 문서보다 독립적 검증이 중요한 이유 - AI 공급업체는 백서, 보안 설문, 정책 문서 등을 통해 거버넌스 수준을 설명할 수 있지만, 문서만으로는 실제 통제가 작동하는지 판단하기 어렵습니다. - ISO 42001 인증은 공인된 제3자가 국제 표준에 따라 관리 체계를 직접 심사했다는 점에서 자체 평가와 구별됩니다. - Figma는 Schellman이 다음 항목을 검토했다고 설명합니다. - AI 거버넌스 정책 - 데이터 처리 관행 - AI 위험 관리 절차 - 기술적 보호조치 - 실제 운영 효과 - 따라서 고객은 Figma의 설문 답변만 검토하는 대신, 벤더 위험 평가·이사회 보고·규제 제출에 활용할 수 있는 외부 검증 결과를 참고할 수 있습니다. ## 인증 적용 범위 - 인증 대상은 Figma 플랫폼 전반의 AI 기능을 관리하는 AIMS입니다. - 적용 제품은 다음과 같습니다. - Figma Design - Figma Make - FigJam - Dev Mode - Figma Sites - Figma Slides - Figma Draw - Figma Buzz - Figma Weave ## 실제 심사 방식과 9개 통제 목표 - 심사는 두 단계로 진행되었습니다. - **1단계:** AIMS의 설계, 문서, 정책, 위험 평가 방법론 검토 - **2단계:** 직원 인터뷰, 업무 프로세스 관찰, 실제 운영 효과 평가 - 총 38개 통제를 다음 9개 Annex A 통제 목표에 따라 평가했습니다. - AI 영향 평가 - 거버넌스와 책임 - AI 특화 위험 관리 - AI 시스템 생명주기 관리 - 데이터 거버넌스 - 제3자 AI 위험 관리 - 모니터링과 성능 평가 - 인간의 감독 - AI 시스템의 책임 있는 사용 - Figma는 이번 인증이 관련 개념을 문서화했다는 사실보다, 실제 프로세스에 적용하고 운영하고 있음을 검증한 데 의미가 있다고 설명합니다. - 인증기관 자체도 ANAB의 공인을 받았기 때문에, 비공인 기관의 인증보다 신뢰성과 객관성이 높다고 강조합니다. ## 규제 산업 고객에게 의미하는 점 - Figma의 AI 기능은 금융, 의료, 보험, 공공 부문 등 보안·개인정보·규제 요구가 높은 환경에서 사용될 수 있습니다. - 이런 조직은 AI 공급업체를 평가할 때 다음을 입증해야 할 수 있습니다. - AI 위험을 식별하고 관리하는지 - 데이터가 적절히 통제되는지 - AI 시스템에 인간의 감독이 존재하는지 - 공급업체의 통제가 실제로 운영되는지 - EU AI 법(EU AI Act)과 새로운 AI 조달 기준은 단순한 선언보다 증빙을 요구하는 방향으로 발전하고 있습니다. - ISO 42001 인증은 기업의 벤더 위험 관리, 감사 대응, 이사회 보고, 규제 제출에 활용 가능한 공식 근거가 될 수 있습니다. ## 향후 지속적인 검증 - Figma는 AI 기능이 확대될수록 거버넌스 체계도 계속 제3자 검증에 맡기겠다고 밝혔습니다. - ISO 42001 인증서는 기존 ISO 27001 및 SOC 2 Type II 인증과 함께 제공됩니다. - 인증서와 보안·컴플라이언스 문서는 `compliance.figma.com`에서 확인할 수 있으며, Schellman 인증서 디렉터리를 통해 인증을 검증할 수 있습니다. - Figma는 AI 거버넌스가 변경되어 고객의 위험 평가에 영향을 줄 경우 이를 투명하게 알리고, 관련 정보를 지속적으로 최신 상태로 유지하겠다고 약속합니다. 실무적으로는 AI 서비스를 도입하거나 갱신할 때 공급업체의 자체 설명만 확인하기보다, ISO 42001처럼 공인기관이 검증한 인증 범위·유효기간·적용 제품을 함께 확인하는 것이 바람직합니다.

원문 읽기(새 탭에서 열림)
aws3분 읽기큐레이션 요약

AWS CloudFormation Express 모드로 인프라 배포를 최대 4배 가속화하세요 | Amazon Web Services

AWS CloudFormation Express mode는 리소스가 완전히 안정화될 때까지 기다리지 않고 설정 적용이 확인되는 즉시 배포를 완료해, 반복적인 인프라 개발 속도를 최대 4배 높이는 기능이다. 리소스 안정화는 백그라운드에서 계속 진행되며, 일시적인 프로비저닝 실패는 CloudFormation이 자동 재시도한다. 다만 트래픽 전환이나 테스트 전에 리소스의 완전한 운영 가능 상태가 필요하다면 기존 Standard 모드를 사용해야 한다. ## Express mode의 동작 방식 - Standard 모드는 리소스 설정 적용 후 안정화 검사를 수행한 뒤 배포를 완료한다. - Express mode는 설정이 적용되었다고 CloudFormation이 확인하면 안정화 검사를 기다리지 않고 배포를 완료한다. - 배포 완료 이후에도 리소스는 백그라운드에서 계속 운영 상태로 전환된다. - 의존 리소스에서 일시적인 오류가 발생하면 동일 스택 내에서 CloudFormation이 자동으로 재시도한다. - 리소스 프로비저닝 방식 자체를 바꾸는 것이 아니라, CloudFormation이 배포 완료를 보고하는 시점만 앞당긴다. ## 적합한 사용 사례 - 인프라 설정을 반복적으로 수정하는 개발 및 실험 workflow - 애플리케이션의 개별 구성 요소를 빠르게 테스트하는 경우 - AI 도구를 활용한 인프라 개발처럼 1분 이내의 피드백이 필요한 경우 - 리소스가 완전히 안정화되기 전에 다음 개발 작업을 진행해도 되는 프로덕션 환경 ## 배포 시간 단축 사례 - SQS 큐와 DLQ 생성: - Standard mode: 약 64초 - Express mode: 최대 약 10초 - 네트워크 인터페이스가 연결된 Lambda 함수 삭제: - Standard mode: 약 20~30분 - Express mode: 벤치마크 기준 최대 약 10초 실제 시간은 리소스 종류와 환경에 따라 달라질 수 있지만, 안정화 대기 시간이 긴 작업일수록 효과가 크다. ## 활성화 방법과 롤백 설정 - 콘솔에서 스택 생성 시 **Stack deployment options → Express mode → Enable**을 선택한다. - AWS CLI, SDK, CDK, Kiro 같은 AI 도구에서도 사용할 수 있다. - CLI에서는 `--deployment-config`에 `EXPRESS` 모드를 지정한다. ```bash aws cloudformation create-stack \ --stack-name my-app \ --template-body file://template.yaml \ --deployment-config '{"mode": "EXPRESS", "disableRollback": true}' ``` - Express mode는 빠른 반복 작업을 위해 기본적으로 롤백이 비활성화된다. - 프로덕션 환경에서 롤백을 사용하려면 `disableRollback: false`로 설정한다. - 롤백을 비활성화할 경우 실패한 배포에 대한 모니터링과 정리 절차를 별도로 마련해야 한다. ## 점진적 인프라 개발 Express mode는 리소스를 하나씩 추가하는 방식의 개발에 적합하다. - 1단계: IAM 역할 배포 - 2단계: Lambda 함수 추가 - 3단계: SQS 큐와 이벤트 소스 매핑 추가 - 각 단계에서 `create-stack` 또는 `update-stack`과 함께 Express mode를 사용할 수 있다. - IAM 역할 템플릿은 최소 권한 원칙을 따라야 한다. ## CDK 및 CloudFormation 호환성 - AWS CDK에서는 다음 명령으로 활성화한다. ```bash cdk deploy --express ``` - 기존 CloudFormation 템플릿을 수정하지 않아도 된다. - 변경 세트, 중첩 스택 등 기존 CloudFormation 기능을 지원한다. - 부모 스택에서 Express mode를 활성화하면 중첩 스택에도 적용된다. - 리소스가 완전히 운영 가능해진 뒤 트래픽을 전환하거나 테스트해야 한다면 Standard 모드를 유지해야 한다. ## 제공 범위 - 모든 AWS 상용 리전에서 추가 비용 없이 제공된다. - 리전별 지원 현황과 향후 계획은 AWS 리전별 기능 문서에서 확인할 수 있다. 개발 중 빠른 피드백이 중요하다면 Express mode를 우선 사용하되, 롤백 비활성화에 따른 정리 및 모니터링 체계를 준비하는 것이 좋다. 운영 트래픽이나 테스트가 리소스의 완전한 안정화에 의존한다면 기존 Standard 모드가 더 안전하다.

원문 읽기(새 탭에서 열림)