terraform

클라우드플레어 전체를 위한 CLI 구축하기 (새 탭에서 열림)

Cloudflare는 100개 이상의 제품과 3,000여 개의 API 작업을 아우르는 거대한 생태계를 단일화하기 위해 Wrangler CLI를 전면 재구축하고 있습니다. 특히 AI 에이전트가 주요 사용자로 부상함에 따라, 모든 제품을 CLI, SDK, Terraform 등 다양한 인터페이스에서 일관되게 사용할 수 있도록 하는 것을 목표로 합니다. 이를 위해 새로운 TypeScript 기반 스키마 시스템을 도입하여 코드 생성 파이프라인을 자동화하고 개발 생산성을 높이고 있습니다. ### 통합 CLI 'cf'로의 진화 * Cloudflare의 방대한 API를 모두 수용하기 위해 차세대 Wrangler의 기술 프리뷰 버전인 `cf` 커맨드를 공개했습니다. * 기존 Wrangler가 일부 제품만 지원하던 한계를 극복하고, 인간과 AI 에이전트 모두에게 인체공학적인 출력을 제공하도록 설계되었습니다. * 현재 `npx cf` 또는 `npm install -g cf`를 통해 초기 버전을 미리 체험해 볼 수 있으며, 향후 기존 Wrangler 기능들과 통합될 예정입니다. ### TypeScript 기반의 새로운 스키마 엔진 * 기존 OpenAPI 스키마만으로는 로컬 개발 환경과 API 요청이 결합된 복잡한 CLI 명령어나 Workers 바인딩을 표현하는 데 한계가 있었습니다. * 이에 Cloudflare는 API, CLI 인자, 에이전트 기술(Agent Skills) 등을 포괄적으로 정의할 수 있는 새로운 TypeScript 기반 스키마 시스템을 구축했습니다. * 이 시스템은 일종의 '코드 생성기' 역할을 하며, 단일 정의로부터 OpenAPI 스키마, SDK, Terraform 제공자 등을 자동으로 생성하여 제품 업데이트 속도에 맞춘 신속한 동기화를 지원합니다. ### 일관성 확보와 컨텍스트 엔지니어링 * 수많은 제품군 사이에서 일관성 없는 명령어(예: `info`와 `get`의 혼용)는 특히 AI 에이전트의 오작동을 유발하므로, 스키마 계층에서 명칭 규칙을 강제합니다. * 모든 명령어에 `--force`, `--json`과 같은 표준 플래그를 적용하여 예측 가능성을 높였습니다. * 로컬 리소스와 원격 리소스 간의 동작 차이를 명확히 시그널링하여, 에이전트가 개발 중 리소스를 수정할 때 혼동하지 않도록 컨텍스트를 제공합니다. ### 로컬 익스플로러(Local Explorer) 도입 * 로컬 개발 환경에서 시뮬레이션되는 KV, D1, R2, Durable Objects 등의 리소스 내부를 쉽게 들여다볼 수 있는 'Local Explorer' 기능이 베타로 출시되었습니다. * Wrangler나 Cloudflare Vite 플러그인 실행 중 단축키 `e`를 눌러 활성화할 수 있으며, 기존처럼 `.wrangler/state` 디렉토리를 직접 분석할 필요가 없습니다. * 이를 통해 개발자와 에이전트는 로컬 데이터 상태를 즉각 확인하고, 테스트 레코드를 삽입하거나 스키마를 검증하는 등 상호작용 중심의 개발 사이클을 가질 수 있습니다. Cloudflare의 새로운 변화를 미리 경험해보고 싶다면 지금 바로 터미널에서 `npx cf`를 실행해 보세요. 또한 로컬 개발 중에는 `e` 키를 활용해 데이터 상태를 실시간으로 점검하며 개발 속도를 높일 수 있습니다.

연간 600시간을 절약한 쿠버네티스 한 줄 수정 (새 탭에서 열림)

쿠버네티스 환경에서 테라폼(Terraform) 운영 도구인 아틀란티스(Atlantis)의 재시작 시간을 30분에서 수 초 내외로 단축하여, 연간 600시간의 엔지니어링 대기 시간을 줄인 사례를 소개합니다. 문제의 원인은 수백만 개의 파일을 포함한 퍼시스턴트 볼륨(PV)을 마운트할 때 쿠버네티스가 기본적으로 수행하는 파일 권한 변경 작업이었습니다. 이를 해결하기 위해 `securityContext`에 단 한 줄의 설정을 추가함으로써 불필요한 재귀적 권한 검사를 방지하고 시스템 효율성을 극대화했습니다. ### 원인 불명의 느린 재시작 문제 아틀란티스는 테라폼 프로젝트의 상태를 유지하기 위해 퍼시스턴트 볼륨(PV)을 사용하는 싱글톤 스테이트풀셋(StatefulSet)으로 운영됩니다. 자격 증명 갱신이나 프로젝트 온보딩 시 재시작이 필수적인데, 이때마다 다음과 같은 심각한 지연이 발생했습니다. * **지속적인 지연:** 매 재시작 시 30분 동안 포드가 `Init:0/1` 상태에 머물며 인프라 변경 작업이 완전히 중단됨. * **운영 부담:** 매달 약 100회의 재시작이 발생하여 월 50시간, 연간 600시간의 엔지니어링 시간이 낭비되고 온콜 엔지니어에게 불필요한 알람이 전송됨. * **한계 도달:** 파일 시스템의 아이노드(Inode) 고갈로 볼륨 크기를 키워야 하는 상황에서, 재시작 지연 문제는 더욱 두드러짐. ### Kubelet 로그를 통한 기술적 병목 파악 일반적인 `kubectl events`로는 포드가 이미지를 풀링하기 전 단계에서 왜 멈춰 있는지 알 수 없었습니다. 팀은 노드 레벨의 `kubelet` 로그를 분석하여 구체적인 원인을 찾아냈습니다. * **로그 추적:** 로그상에서 볼륨 마운트 성공 메시지 이후 `context deadline exceeded` 오류가 반복적으로 발생하며 포드 생성이 지연됨을 확인. * **fsGroup 권한 설정:** 쿠버네티스는 볼륨을 마운트할 때 포드의 `fsGroup` 설정과 일치시키기 위해 볼륨 내의 모든 파일과 디렉토리에 대해 재귀적으로 `chown` 및 `chmod`를 실행함. * **파일 개수의 영향:** 아틀란티스 볼륨에 쌓인 수백만 개의 파일에 대해 매번 이 작업을 수행하면서 30분이라는 막대한 시간이 소요됨. ### 단 한 줄의 설정 변경으로 문제 해결 쿠버네티스 1.20 버전(GA 기준)부터 도입된 `fsGroupChangePolicy` 설정을 통해 이 문제를 간단히 해결할 수 있었습니다. * **기본값(Always):** 포드가 시작될 때마다 항상 모든 파일의 권한을 재귀적으로 변경함. * **해결책(OnRootMismatch):** 볼륨 루트 디렉토리의 권한이 `fsGroup`과 일치하지 않을 때만 재귀적 변경을 수행함. 이미 권한이 올바르게 설정되어 있다면 이 과정을 건너뜀. * **적용 코드:** ```yaml securityContext: fsGroup: 1000 fsGroupChangePolicy: "OnRootMismatch" ``` ### 실용적인 권장 사항 수백만 개의 작은 파일이 포함된 대규모 볼륨을 사용하는 애플리케이션(예: Prometheus, Atlantis, Jenkins 등)을 쿠버네티스에서 운영 중이라면, `fsGroupChangePolicy: "OnRootMismatch"` 설정을 기본적으로 적용하는 것이 좋습니다. 이를 통해 볼륨 마운트 시 발생하는 불필요한 디스크 I/O를 제거하고, 포드 시작 시간을 획기적으로 개선하여 인프라 운영의 가용성을 높일 수 있습니다.

진정으로 프로그래밍 가능한 S (새 탭에서 열림)

Cloudflare는 단순한 설정 변경을 넘어 실시간 로직 주입이 가능한 진정한 의미의 프로그래밍 가능한 SASE(Secure Access Service Edge) 플랫폼을 지향합니다. Cloudflare One과 개발자 플랫폼(Workers)이 동일한 네트워크 인프라 위에서 기본적으로 통합되어 있어, 사용자는 대기 시간 없이 보안 이벤트를 가로채고 외부 컨텍스트를 결합하여 맞춤형 보안 결정을 내릴 수 있습니다. 이는 정적인 보안 정책의 한계를 극복하고 각 기업의 고유한 요구사항에 맞춘 유연한 보안 아키텍처 구축을 가능하게 합니다. **진정한 프로그래밍 가능성의 의미** - 업계에서 흔히 말하는 API 제공이나 Terraform 지원 같은 '기초적인 프로그래밍 가능성'을 넘어, 실시간으로 보안 이벤트를 가로채고 외부 데이터를 보충하여 즉각적인 조치를 취하는 능력을 의미합니다. - 예를 들어, 특정 앱 접속 시 사용자의 규정 준수 교육 이수 여부를 외부 시스템(LMS)에서 즉시 확인하여, 미이수자에게는 접속 차단 대신 교육 포털로 리다이렉트하는 동적인 정책 결정이 가능합니다. **SASE와 개발자 플랫폼의 결합** - Cloudflare One(SASE)과 Workers(개발자 플랫폼)는 동일한 전 세계 330개 이상의 도시 인프라 및 동일한 서버 자원 위에서 실행됩니다. - 별도의 외부 클라우드에서 자동화를 실행할 필요가 없어 불필요한 네트워크 왕복 지연(Latency)이 발생하지 않으며, 보안 정책 내에서 밀리초 단위로 커스텀 로직을 수행할 수 있습니다. - 웹 보호, 사용자 보안, 프라이빗 네트워크 보안 모두가 동일한 개발 도구와 기본 요소를 공유하므로 아키텍처의 일관성을 보장합니다. **확장된 보안 액션과 워크플로우** - 기존 보안 게이트웨이의 제한적인 옵션(허용, 차단, 격리 등)에서 벗어나, 사용자 정의 로직을 실행할 수 있는 '커스텀 액션' 기능을 제공합니다. - 사용자 ID 클레임에 기반한 동적 헤더 삽입, 외부 리스크 엔진의 실시간 판독 결과 반영, 근무 시간 및 위치에 따른 정교한 접근 제어 등을 구현할 수 있습니다. - '관리형 액션(템플릿)'을 통해 ITSM 통합이나 규정 준수 자동화를 쉽게 설정하거나, '커스텀 액션'을 통해 Cloudflare Worker를 직접 호출하여 정교한 코드를 실행할 수 있습니다. **실제 활용 사례: 자동화된 세션 관리** - 특정 고객은 정해진 시간 동안 활동이 없는 기기의 세션을 강제로 종료해야 하는 보안 요건을 Cloudflare Workers를 통해 해결하고 있습니다. - 'Scheduled Worker'가 주기적으로 실행되어 기기 API(Devices API)를 쿼리하고, 비활성 임계값을 초과한 기기의 등록을 자동으로 취소하여 사용자가 ID 공급자를 통해 다시 인증하도록 강제합니다. - 이는 표준 기능으로 제공되지 않는 복잡한 보안 요구사항도 프로그래밍을 통해 즉시 해결할 수 있음을 보여줍니다. 보안 요구사항이 복잡해질수록 단순한 설정 중심의 솔루션은 한계에 부딪힙니다. Cloudflare One의 프로그래밍 가능성을 활용하여 기업 고유의 비즈니스 로직을 보안 스택에 직접 통합하면, 성능 저하 없이도 가장 강력하고 유연한 제로 트러스트 환경을 구축할 수 있습니다.

백지 상태를 넘어: Cloudflare (새 탭에서 열림)

Cloudflare One은 강력한 SASE(Secure Access Service Edge) 플랫폼이지만, 모든 보안 기능을 최적으로 활용하기 위해서는 복잡한 설정 과정을 거쳐야 하는 '빈 캔버스'의 어려움이 존재합니다. 이를 해결하기 위해 Cloudflare는 전문가의 노하우를 코드화하여 자동 배포하는 '프로젝트 헬릭스(Project Helix)'를 도입했습니다. 이 프로젝트를 통해 고객은 수동 설정의 번거로움 없이 단 몇 분 만에 베스트 프랙티스가 적용된 제로 트러스트 환경을 구축할 수 있습니다. ### 초기 설정의 복잡성과 제로 트러스트 도입의 장벽 * Cloudflare One은 DNS 보호, 네트워크 보호, SWG 등 방대한 기능을 제공하지만, 초기 테넌트는 대개 운영 환경의 중단을 방지하기 위해 최소한의 설정만 되어 있는 '빈 상태'로 제공됩니다. * 고급 보안 기능인 TLS 검사, DLP(데이터 손실 방지), AV 스캔 등을 활성화하려면 수많은 스위치와 정책을 일일이 조정해야 하며, 이는 관리자에게 큰 부담이 됩니다. * 수동 설정 방식은 문서화가 어렵고 휴먼 에러의 가능성이 높으며, 특히 여러 시나리오를 동시에 적용해야 할 때 설정 간 충돌이나 누락이 발생하기 쉽습니다. ### 프로젝트 헬릭스: 전문가 노하우의 코드화와 자동화 * Cloudflare의 솔루션 엔지니어와 파트너들이 실제 구축 현장에서 겪은 베스트 프랙티스를 수집하여 이를 실행 가능한 코드(IaC) 형태로 변환했습니다. * 단순한 보안 정책 설정을 넘어, 신규 등록 도메인에 대한 원격 브라우저 격리(RBI), AI 애플리케이션 제어, 특정 SaaS 인스턴스만 허용하는 테넌트 제어(Tenant Control) 등 고도화된 설정을 포함합니다. * 사용자 경험 개선을 위해 Zoom과 같은 실시간 통신 앱의 트래픽 분리(Split Tunnel) 설정이나 공항·호텔의 캡티브 포털(Captive Portal) 접속을 위한 최적의 설정을 사전 구성으로 제공합니다. ### Terraform과 Cloudflare Workers를 활용한 기술적 구현 * **Terraform 기반 관리:** 확장 가능하고 유연한 Terraform 템플릿을 설계하여 복잡한 설정 파편과 정책을 일관되게 전달합니다. * **웹 기반 UI와 Workers:** Cloudflare Workers 및 Cloudflare Containers를 활용해 사용자가 기본 정보만 입력하면 테라폼 템플릿이 즉시 실행되는 웹 인터페이스를 구축했습니다. * **보안성 확보:** 실행 환경을 휘발성(Ephemeral)으로 구성하여 로그나 인증 토큰을 영구 저장하지 않으므로 보안 리스크를 최소화했습니다. * **효율성 극대화:** 수동으로 수 시간이 소요되던 구성 작업을 단 몇 분으로 단축하며, 클릭 한 번으로 권장 보안 정책 세트를 즉시 배포할 수 있습니다. Cloudflare One을 처음 도입하거나 환경을 재정비하려는 조직은 프로젝트 헬릭스를 통해 시행착오를 줄일 수 있습니다. 수동 설정 대신 자동화된 베스트 프랙티스 템플릿을 활용하여 보안 공백을 메우고 서비스 가동 시간을 빠르게 확보하는 것을 추천합니다.

Scaling support with Vagrant and Terraform (새 탭에서 열림)

Datadog의 솔루션 팀은 고객이 사용하는 다양한 기술 스택과 복잡한 인프라 환경에서 발생하는 문제를 정확히 재현하기 위해 Vagrant와 Terraform을 활용한 자동화된 샌드박스 시스템을 구축했습니다. 인프라 구축 과정을 코드화하여 팀 전체가 공유함으로써, 개별 엔지니어가 생소한 기술을 매번 처음부터 학습하고 설치해야 하는 비효율을 제거하고 문제 해결 속도를 획기적으로 높였습니다. 결과적으로 로컬 가상 머신과 클라우드 인스턴스를 자유롭게 오가는 유연한 디버깅 환경을 통해 팀 간 협업과 고객 지원의 품질을 극대화할 수 있었습니다. **Vagrant 프로비저닝을 통한 환경 구축 자동화** * 고객의 특정 OS, 커널 버전, 복잡한 통합 도구(Kafka, MS SQL, RabbitMQ 등)를 수동으로 설치하는 것은 시간이 많이 걸리고 오류가 발생하기 쉽습니다. * Vagrant의 '프로비저닝(Provisioning)' 기능을 활용하여, 인프라 설치 및 설정에 필요한 모든 명령어를 `setup.sh`와 같은 쉘 스크립트에 담아 자동화했습니다. * 한 번 작성된 프로비저닝 스크립트는 팀 공용 GitHub 저장소에 저장되어, 다른 팀원들이 동일한 이슈를 처리할 때 `vagrant up` 명령어 하나만으로 즉시 동일한 환경을 갖출 수 있게 합니다. **샌드박스 저장소의 구조화 및 유연성 확보** * 저장소는 운영체제와 배포판, 서비스 이름에 따라 계층적으로 디렉토리를 나누어 관리하며, 각 디렉토리에는 `Vagrantfile`, `setup.sh`, 그리고 설정 파일 등이 담긴 `/data` 폴더를 포함합니다. * 엔지니어 개인별로 달라야 하는 설정(호스트 이름, API 키, 태그 등)은 `.sandbox.conf.sh`라는 로컬 설정 파일에 분리하여 관리함으로써 스크립트의 범용성을 유지합니다. * 이를 통해 새로운 환경이 필요할 때 기존 템플릿을 복사하여 빠르게 변형할 수 있으며, 팀 내 기술적 노하우가 코드를 통해 자연스럽게 축적됩니다. **Terraform을 이용한 클라우드 확장 및 협업** * 로컬 가상 머신 사용 시 발생하는 RAM 자원 부족 문제를 해결하고 팀원 간 환경을 쉽게 공유하기 위해 Terraform을 도입하여 AWS EC2 인스턴스를 활용합니다. * Vagrant에서 사용하던 `setup.sh`와 `/data` 파일을 그대로 재사용하면서, 인스턴스 생성을 위한 `.tf` 파일만 추가하여 로컬과 클라우드 환경 간의 일관성을 유지합니다. * 클라우드 기반 샌드박스를 활용하면 여러 시간대의 팀원들이 동일한 원격 환경에 접속해 조사를 이어갈 수 있으며, 고객과의 실시간 상담 중에도 미리 준비된 환경을 즉시 배포하여 대응할 수 있습니다. **실용적인 결론** 반복적인 환경 구축이 필요한 기술 지원이나 개발 팀이라면 인프라를 코드로 관리(IaC)하는 것이 필수적입니다. Vagrant로 로컬에서 가볍게 시작하되, 동일한 프로비저닝 스크립트를 Terraform과 공유할 수 있도록 설계하면 로컬의 편의성과 클라우드의 협업 능력을 동시에 잡을 수 있습니다. 특히 `setup.sh`와 같은 범용 스크립트를 중심에 두면 도구가 바뀌어도 재사용성을 높일 수 있습니다.

ChatOps를 통한 클라우드 보안 가시성 향상 (새 탭에서 열림)

Datadog은 대규모 AWS 환경에서 발생하는 막대한 API 호출을 효율적으로 감시하기 위해 서버리스 기반의 보안 모니터링 및 알림 파이프라인을 구축했습니다. 이 시스템은 모든 API 활동을 실시간으로 분석하여 잠재적 위협과 설정 오류를 탐지하며, Slack과 Duo를 활용한 사용자 직접 확인 절차를 통해 보안팀의 운영 부담을 최소화합니다. 결과적으로 적은 인력으로도 수많은 계정의 보안 상태를 높은 가용성으로 유지할 수 있는 중앙 집중형 구조를 완성했습니다. ### 데이터 필터링과 위험도 분류 * **로그 중심의 선택적 집중:** 모든 API 호출을 실시간 감시하는 것은 불가능하므로, 보안상 의미 있는 API를 식별하여 로그(Log), 알림(Notify), 경고(Alert)의 세 단계로 분류했습니다. * **단계별 대응 체계:** 단순 변경(CreateGroup 등)은 추후 조사를 위해 로그로 남기고, 권한 변경(CreateUser 등)은 실행한 엔지니어에게 직접 확인을 요청하며, 치명적인 설정 오류(보안 그룹을 0.0.0.0/0으로 개방 등)는 즉시 보안팀에 경고를 보냅니다. * **엔지니어 직접 검증:** 알림 단계에서는 해당 API를 호출한 엔지니어에게 Slack 메시지를 보내 본인이 수행한 작업인지 확인하게 함으로써, 계정 탈취 여부를 확인하는 동시에 보안팀의 오탐(False-positive) 분석 업무를 획기적으로 줄였습니다. ### 중앙 집중형 아키텍처 및 파이프라인 * **교차 계정 데이터 통합:** 15개 이상의 AWS 계정에서 발생하는 이벤트를 하나의 중앙 보안 계정으로 수집하기 위해 CloudWatch 이벤트 규칙과 SNS, SQS를 조합했습니다. * **지연 및 비용 최적화:** CloudWatch가 SQS로 직접 데이터를 보내지 못하는 제약을 SNS를 통해 해결했으며, Lambda를 2분마다 트리거하여 SQS 큐의 데이터를 처리함으로써 실시간성과 알림 피로도 사이의 균형을 맞췄습니다. * **인프라 코드화:** Terraform을 사용하여 모든 AWS 계정에 동일한 데이터 수집 설정을 신속하고 일관되게 배포할 수 있는 구조를 갖췄습니다. ### 보안 오케스트레이션과 자동화 로직 * **워크플로우 자동화:** 보안 오케스트레이션 플랫폼인 Komand(현 Rapid7 InsightConnect)를 도입하여 복잡한 결정 트리와 브랜칭 로직을 구현했습니다. * **상세 분석 플러그인:** 커스텀 플러그인을 통해 호출자 identity, API 파라미터 내용, 요청 시간 등을 정밀하게 파싱하여 경고 여부를 결정합니다. * **다중 인증(MFA) 연동:** 엔지니어가 Slack 알림에서 본인의 작업임을 승인하면 Duo Push를 통해 2차 인증을 거치게 되며, 응답이 없거나 본인 작업이 아니라고 응답할 경우에만 보안팀에 비상 호출(PagerDuty)이 전달됩니다. * **가시성 확보:** 모든 워크플로우 실행 결과는 Elasticsearch로 전송되어 대시보드화되며, 이를 통해 보안 이벤트 추세와 시스템 효율성을 측정합니다. 대규모 클라우드 환경을 운영하는 조직이라면 모든 이벤트를 보안팀이 직접 처리하려 하기보다, 이처럼 자동화된 오케스트레이션과 사용자 참여형 검증 시스템을 구축하여 '확장 가능한 보안(Scalable Security)'을 실현하는 것이 권장됩니다.