저는 잘못된 모델을 위해 아키텍처를 최적화했습니다.

저는 예전에 블랙박스 (Black-box) 인프라가 AI 주도 개발 (AI-driven development)을 위한 올바른 추상화 (Abstraction)라고 생각했습니다.

Vercel, Supabase, Cloudflare Workers — 전면에는 명확한 계약이 있고, 후면에는 관리형 백엔드 (Managed backend)가 있는 구조 — 가 당연히 적합하다고 느꼈습니다. 에이전트 (Agent)가 추론해야 할 것이 적을수록, 길을 잃을 가능성도 줄어들기 때문입니다. 깔끔한 인터페이스를 제공하고, 지저난 백엔드를 숨기며, 빠르게 움직이는 방식 말입니다.

작년에 우리가 사용하던 에이전트들에게는 여전히 그 방식이 옳았다고 생각합니다. 하지만 지금 우리가 사용하기 시작한 에이전트들에게는 옳지 않다고 생각합니다.

변화의 핵심은 AWS가 더 단순해진 것이 아닙니다. 그렇지 않았습니다. 설정 (Setup)은 여전히 더 오래 걸리고, CI/CD를 연결하는 데는 더 많은 작업이 필요하며, 비용 제어에는 실질적인 한계가 있습니다. 변화는 에이전트가 복잡성을 읽는 능력이 향상되었다는 것입니다. 에이전트가 실제로 대규모의 구조화된 컨텍스트 (Structured context)를 사용할 수 있게 되면서, 제가 오버헤드 (Overhead)로 취급했던 것들(리소스 (Resources), 프로바이더 스키마 (Provider schemas), IAM 정책 (IAM policies), 명시적 큐 (Explicit queues), 명시적 알람 (Explicit alarms), 명시적 네트워크 (Explicit networks))이 제가 에이전트에게 전달할 수 있는 가장 신호가 높은 (Highest-signal) 컨텍스트가 되었습니다.

구체적인 비교를 위해 도구는 동일하게 유지하겠습니다. 이것은 AWS 상의 HCL/Terraform 대 Cloudflare 상의 HCL/Terraform의 비교입니다. 동일한 언어, 동일한 워크플로우, 두 개의 프로바이더 (Providers)입니다.

역전 (The inversion)

에이전트는...
컨텍스트가 부족함 (작년의 루프들)
컨텍스트가 풍부함 (현재)

한 줄 요약:

에이전트의 읽기 능력이 향상될수록, 명시적 인프라 (Explicit infrastructure)의 가치는 더욱 높아집니다.

제가 AWS를 더 선호하게 된 것은 AWS가 쉬워졌기 때문이 아닙니다. 에이전트가 AWS를 더 잘 읽게 되었기 때문입니다.

동일한 Terraform, 두 개의 프로바이더

흥미로운 비교 대상은 AWS의 우아함 대 Cloudflare의 우아함이 아닙니다. 핵심은 에이전트가 HCL과 프로바이더 스키마만으로 인프라 토폴로지 (Infrastructure topology)와 운영 계약 (Operational contract)을 얼마나 많이 재구성할 수 있는가입니다.

	Terraform × AWS	Terraform × Cloudflare
Provider 성숙도 (Provider maturity)	AWS provider는 IaC(Infrastructure as Code)가 도달할 수 있는 가장 검증된 수준입니다. 모듈과 예제의 방대한 공개 코퍼스(public corpus)를 보유하고 있습니다.	v5는 처음부터 다시 작성된, OpenAPI 기반의 재작성(ground-up, OpenAPI-generated rewrite)입니다. 빠르게 개선되고 있지만, 변경 사항이 기존 설정을 깨뜨리기도 하며 짧은 주기로 안정화 단계에 있습니다.
...

Cloudflare 행에 대한 언급은 비난이 아니라 핵심(crux)을 짚는 것입니다. Terraform 파일은 에이전트에게 특정 바인딩(binding)이 _존재한다_는 사실은 알려줄 수 있습니다. 하지만 그 바인딩이 어떻게 사용되는지, Worker 코드와 스토리지 사이의 책임 소재가 어디에 있는지, 마이그레이션(migrations)이 런타임 동작(runtime behavior)과 어떻게 연관되는지, 혹은 어떤 프레임워크 컨벤션(framework conventions)이 보이지 않는 작업을 수행하고 있는지에 대해서는 스스로 설명할 수 없습니다. Terraform을 통한 AWS의 경우, 큐(queues), 권한(permissions), 스케줄(schedules), 알람(alarms), 네트워크(networks), 역할(roles), 정책(policies), 데이터 평면 배선(data-plane wiring) 등 훨씬 더 많은 인프라 토폴로지(infrastructure topology)와 운영 계약(operational contract)이 동일한 아티팩트(artifact)를 통해 가시화됩니다. 애플리케이션 역시 여전히 중요합니다. Lambda 코드, 마이그레이션, API 명세는 HCL(HashiCorp Configuration Language)에 포함되지 않기 때문입니다. 하지만 _인프라 형태(infra shape)_가 에이전트로부터 덜 숨겨져 있습니다. 이는 AWS가 더 단순해서가 아니라, AWS가 더 많은 운영 계약을 동일한 조사 가능한 아티팩트(inspectable artifact) 안에 담아두기 때문입니다.

Cloudflare는 틀린 선택이 아니라, 다른 베팅입니다

Workers, D1, R2, KV, Durable Objects, Queues, 그리고 프레임워크 네이티브 배포(framework-native deploy)는 진정으로 일관된 플랫폼을 형성합니다. 비용, 속도, 그리고 운영의 경량화 측면에서 이는 사용 가능한 최고의 균형 중 하나이며, 저 또한 기꺼이 이를 선택합니다.

단지 동일한 종류의 명시성 (explicitness)을 중심으로 최적화되어 있지 않을 뿐입니다. Cloudflare는 Terraform을 개선하고 있습니다. v5는 커버리지와 API 정렬 측면에서 OpenAPI로 생성된 진정한 도약입니다. 하지만 더 흥미로운 전략적 움직임은 다른 곳에 있습니다. 바로 프레임워크로부터 의도 (intent)를 읽어 인프라를 프로비저닝하는 의도 기반, 프레임워크 네이티브 (intent-based, framework-native) 프로비저닝 (VoidZero/Vite, Astro)입니다. VoidZero 인수 프레임워크에서 Cloudflare는 단 한 번의 Vite 배포 명령이 앱의 데이터베이스 또는 오브젝트 스토어 필요성을 감지하고, 수동 대시보드 단계 없이 D1 또는 R2와 같은 리소스를 프로비저닝하는 미래를 설명합니다. 그것은 일관된 미래입니다. 이는 단순히 "모든 것을 코드로 명시하는 것"과는 다른 베팅이며, 이것이 오늘날 Cloudflare 환경에서 HCL이 시스템을 충분히 결정하지 못하는 (underdetermines) 이유입니다. Cloudflare를 단순히 에지 (edge)를 타겟팅하는 Terraform으로 보지 말고, 프레임워크 네이티브 인프라로 평가하십시오.

안전 경계 (이것은 "떠나라는 것"이 아닙니다)

검사 가능한 기질 (Inspectable substrate)은 이야기의 절반에 불과합니다. 나머지 절반은 모델의 확신 (confidence)이 아니라, **계획 (plan), 정책 (policy), 그리고 테스트 (tests)**를 통해 정확성을 완성하는 루프입니다. 두 가지 Terraform 관련 연구는 동일한 점을 지적합니다: 표면적인 성공이 곧 정확함을 의미하는 것은 아닙니다.

성공처럼 보이는 것	실제로 일어난 일	연구
구조화된 스키마 지식 (Structured schema knowledge)이 모델을 훨씬 더 나은 _코더 (coder)_로 만들었다	베이스라인(Baseline) 전체 성공률은 **27.1%**였으나, 주입 (injection)을 통해 기술적 검증 (technical validation)은 75.3%, 전체 성공률은 **62.6%**에 도달했습니다. 하지만 의도 정렬 (intent alignment)은 정체되었으며, 이는 **"정확성-일치성 격차 (Correctness–Congruence Gap)"**로 나타났습니다. 유효한 HCL이 당신이 요청한 인프라와 반드시 일치하는 것은 아닙니다.	Nekrasov et al., 2025
원샷 (One-shot) 보안 "수정"이 플래그가 지정된 문제를 **83%**의 확률로 사라지게 만들었다	실제로는 **10%**만이 깨끗하게 해결되었으며, **57–71%**는 **기만적인 수정 (deceptive fixes)**이었습니다. 스캐너는 녹색(통과)으로 변했지만, 보안 취약점은 그대로 남아 있었습니다.	TerraProbe — Alsaid et al., 2026

특히 TerraProbe는 당신이 해서는 안 되는 방식으로 실행되었습니다. 즉, 고맥락(high-context)의 폐쇄 루프(closed-loop) 워크플로우가 아니라, 최소한의 프롬프트만 사용한 1차 수정 방식이었습니다. 이것이 핵심입니다. 이는 에이전트에 반대하는 증거가 아니라, 루프(loop)의 필요성을 입증하는 증거입니다. Nekrasov et al.은 상호 보완적인 논거를 제시합니다: 구조화된 지식이 유효성(validity)을 향상시키더라도, 유효한 HCL이 여전히 당신이 의도한 인프라와 동일하지는 않다는 것입니다. 녹색 체크 표시가 증거는 아닙니다. 따라서 기질(substrate)은 폐쇄 루프를 지원합니다:

#	단계	실패 시
1	자연어(NL) 요청	—
...

루프가 핵심입니다: 계획 차이(plan diff)나 정책 검사(policy check) 실패는 적용(apply) 단계로 바로 넘어가는 것이 아니라, 반드시 재생성(regeneration) 단계로 되돌아갑니다.

Pulumi는 여기서 흥미로운 예외입니다. Pulumi는 대부분의 AWS 스키마 기질을 유지하면서(그의 프로바이더는 동일한 Terraform 프로바이더로부터 브릿지됨), HCL 대신 실제 프로그래밍 언어를 사용합니다. 따라서 에이전트는 컴파일러(compiler)와 타입 시스템(type system)을 추가적인 오라클(oracle)로 활용할 수 있습니다. 여기서 발생하는 위험은 그 강력함의 거울 이미지와 같습니다: 실제 언어는 에이전트가 잔꾀를 부릴 수 있게 만들기 때문에, 정신적인 선언적(declarative) 상태를 유지하기 위해 preview, 정책 기반 코드(policy-as-code), 그리고 테스트에 더 크게 의존해야 합니다.

이것이 AWS의 승전보가 아닌 이유

제가 AWS로 돌아가는 이유는 그것이 더 가벼워졌기 때문이 아닙니다. 그렇지 않습니다. 환경 설정(Environment setup)은 더 오래 걸리고, CI/CD는 더 많은 작업이 필요하며, 비용 제어는 범위가 좁은 플랫폼보다 더 어렵고, 더 넓은 표면적(surface area) — 즉, 더 많은 IAM, 더 많은 정책(policy), 더 많은 배선(wiring), 그리고 더 많은 실수 가능성이 존재합니다.

하지만 그 표면적은 또한 **더 명시적(more explicit)**입니다. 인간만을 위한 개발에서 이러한 명시성은 종종 저항(drag)처럼 느껴졌습니다. 하지만 AI 주도 개발(AI-driven development)에서는 그것이 점점 더 레버리지(leverage)로 느껴집니다. 제가 모델로부터 숨기려 했던 인프라가 이제는 모델이 읽어야 할 인프라가 되고 있습니다.

그것이 진정한 변화입니다.

Cloudflare가 여전히 의도 기반(intent-native) 경로에서 승리할 수도 있습니다. 계약(contract) 규모가 작고 백엔드가 보이지 않는 곳에 머물러야 할 때는 Vercel과 Supabase가 여전히 정답일 수 있습니다. 하지만 엔터프라이즈 요구 사항, 복잡한 시스템, 그리고 인프라와 애플리케이션 코드 모두에 걸쳐 근거 있는(grounded) 변경을 수행해야 하는 에이전트(agents)에게는, AWS 기반의 HCL(HCL-on-AWS)을 이기기 어렵습니다. 그것이 우아해서가 아니라, 시스템의 더 많은 부분을 코드로 검사(inspectable)할 수 있게 남겨두기 때문입니다.

에이전트가 컨텍스트에 제한적(context-bound)이었을 때는 불투명한(Opaque) 플랫폼이 유용했습니다. 에이전트가 풍부한 컨텍스트(context-rich)를 갖게 되면 명시적인 인프라가 유용해집니다. 우리는 지금 그 경계를 넘어서고 있습니다.

만약 여러분이 반대의 선택 — 에이전트 중심 개발을 위해 의도 기반(intent-native) 및 프레임워크 우선(framework-first) 인프라에 베팅했다면 — 그것이 어떻게 유지되고 있는지 듣고 싶습니다. 그 부분이 제가 가장 확신하지 못하는 갈림길(fork)입니다.