메뉴
HN
Hacker News • 33일 전

AI 시대의 인프라 엔지니어링

IMP
6/10
핵심 요약

쿠버네티스와 서버리스가 그랬듯이 AI는 인프라 엔지니어를 대체하는 것이 아니라 수동 작업 계층을 하나씩 자동화하고 엔지니어의 역할을 한 단계 위로 끌어올린다고 설명하는 글입니다. 저자는 Claude로 Helm 차트와 Terraform 모듈 작성의 '조사 작업'을 없앴지만, 좋은 설계를 판단하고 최종 형태를 결정하는 일은 여전히 엔지니어의 몫이라고 강조합니다.

번역된 본문

들어가며 지금은 회사 전체가 AI를 전면적으로 도입하라는 압박이 있습니다. 모든 컨텍스트를 AI에 쏟아붓고, 모든 저장소에 AGENTS.md나 INSTRUCTIONS.md를 작성해서 사람뿐 아니라 에이전트도 프로젝트를 찾고 기여할 수 있게 하라는 것이죠. 생각해 보면 좀 웃픕니다. 저는 인간 팀원에게 README를 제대로 읽게 한 적이 단 한 번도 없었는데, 이제는 로봇을 대상으로 예전보다 훨씬 나은 문서를 쓰고 있으니까요. 그와 함께 따라오는 당연한 질문은 이것입니다: 이것이 엔지니어링을 불필요하게 만드는가? 스택과 인프라에 대한 모든 컨텍스트가 에이전트가 읽을 수 있는 곳에 기록되면, 다음은 우리인가? 저는 그게 정확히 올바른 질문이라고 생각하지 않습니다. 왜냐하면 우리는 이미 그런 버전의 변화를 겪어봤기 때문입니다.

우리는 이미 이 길을 걸어왔다 쿠버네티스(Kubernetes)는 Ansible을 죽였는가? 어떤 면에서는 그렇습니다. 저는 몇 년째 Ansible 플레이북을 작성한 적이 없습니다. 지금 하나를 건네받으면 처음 보는 것처럼 모듈 문법을 가늠하게 되겠죠. 설정 관리가 중요하지 않아져서가 아니라, 쿠버네티스가 서버 관리를 충분히 쉽게 만들어서 우리가 더 이상 노드 이미지를 직접 만들지 않게 됐기 때문입니다. 클라우드 제공자가 주는 대로, 즉 AWS가 만들어준 AMI를 아무 질문 없이 그냥 씁니다. 그리고 마지막으로 무언가를 디버깅하려고 노드에 SSH로 접속한 게 언제였죠? 사실상 거의 없습니다. 노드가 말썽이면 그냥 죽여버리고 대체 노드가 같은 문제를 겪지 않기를 바랄 뿐이죠.

그 위의 계층도 같은 길을 걸었습니다. ECS Fargate, Lambda, Cloudflare Containers에서 컨테이너를 실행하면 그게 어떤 노드에 떨어졌는지 저는 정말 모르고, 알고 싶지도 않습니다. 하지만 그렇다고 아무도 오케스트레이션을 하지 않는다는 뜻은 아닙니다. 그 워크로드가 컨테이너여야 한다는 결정, 어떤 이미지를 실행할지, 무엇과 통신하도록 허용할지, 어떻게 스케일링할지, 장애가 나면 어떻게 될지는 여전히 제가 결정합니다. 쿠버네티스와 서버리스 컨테이너는 이러한 결정 계층을 제거한 게 아니라, 작업 단위를 '기계'에서 '워크로드'로 한 단계 끌어올렸고, 그 아래 계층은 조용히 자동화되어 사라졌습니다. 아무도 쿠버네티스, Fargate, Cloudflare의 컨테이너 플랫폼이 인프라 엔지니어를 대체했다고 말하지 않을 겁니다. 각각은 특정 계층의 수동 작업 — 이미지 직접 빌드, 서버 직접 패치, 워크로드가 어느 노드에 있는지 아는 일 — 을 대체했고, 엔지니어는 매번 그 위의 계층으로 올라갔습니다. 저는 AI가 한 계층 위에서 같은 일을 다시 하고 있다고 생각합니다.

일상에서 달라진 점 저는 매일 Claude를 사용해 Helm 차트를 생성하고 Terraform 모듈을 작성합니다. Claude가 제 하루에서 실제로 없애준 부분은 '생각'이 아니라 '조사 작업'입니다. 저는 더 이상 AWS 프로바이더의 changelog를 뒤져 v5와 v6 사이에 뭐가 바뀌었는지 확인하지 않습니다. 원하는 결과물의 형태대로 설명하면 Claude가 그 버전을 만들어줍니다. 실제로 출시할 수 있는 형태로 만들려면 반복 작업이 필요하지만, 일단 완성되면 다음 번의 예제가 됩니다. 특히 저장소의 AGENTS.md가 그걸 가리키고 있다면요. 한 계층 아래에서도 같은 일이 이미 일어났습니다. 저는 Ansible 모듈을 직접 작성하지 않듯이 원시 Kubernetes YAML도 더 이상 직접 작성하지 않습니다. 그게 Helm 차트의 존재 이유니까요. 그리고 점점 더 Helm 차트조차 직접 작성하지 않습니다. 무엇을 해야 하는지 방향을 정하면, Claude가 작성합니다.

달라지지 않은 점 저는 여전히 좋은 Terraform 모듈이나 잘 구조화된 Helm 차트가 어떤 모습인지 알아야 합니다. 정말 심각한 문제가 발생해서 파드를 죽이는 것으로는 해결이 안 될 때 노드에 SSH로 접속할 수 있어야 합니다. 위의 계층이 아래 계층을 없애는 게 아니라, 손대야 하는 빈도를 줄여줄 뿐입니다. 그리고 실제 형태를 결정하는 사람은 여전히 저입니다. 모듈의 최종 버전이 어떤 모습일지, 1년 뒤에도 유지보수 가능한 게 무엇인지, 차트를 어떻게 배포하고 버전 관리할지요. AI는 시간이 오래 걸리는 부분을 처리합니다. 방향을 제시하는 건 여전히 저의 몫입니다.

원문 보기
원문 보기 (영어)
Introduction There’s a push right now for whole companies to adopt AI wholesale - dump every bit of context into it, write an AGENTS.md or INSTRUCTIONS.md in every repo so any project is discoverable and contributable by an agent, not just a human. Slightly funny, if you think about it: I’ve never once gotten a human teammate to actually read the README, and now we’re all writing better docs than we ever did, just aimed at a robot instead. The question that comes with it is the obvious one: does this make engineering redundant? Once all the context about a stack and its infrastructure is written down somewhere an agent can read it, are we next? I don’t think that’s quite the right question, because we’ve already lived through a version of it. We’ve Been Here Before Did Kubernetes kill Ansible? Kind of. I haven’t written an Ansible playbook in years - if you handed me one right now I’d be squinting at the module syntax like I’d never seen it before - not because configuration management stopped mattering, but because Kubernetes made server management easy enough that we stopped building our own node images at all - we just use whatever the cloud provider hands us, an AWS AMI built for us, no questions asked. And when did I last SSH into a node to debug something? Mostly never. If a node’s acting up, I kill it and hope the replacement doesn’t have the same problem. The next layer up went the same way: run a container on ECS Fargate, in a Lambda, or on Cloudflare Containers, and I genuinely don’t know or care what node it landed on - but that doesn’t mean nobody’s orchestrating it, it means I still decided that workload should be a container in the first place, what image it runs, what it’s allowed to talk to, how it scales, what happens when it fails. Kubernetes and serverless containers didn’t remove that layer of decisions, they moved the unit of work up from “the machine” to “the workload,” and everything below that layer got quietly automated away. Nobody would say Kubernetes, or Fargate, or Cloudflare’s container platform, replaced infrastructure engineers. Each one replaced a specific layer of manual work - hand-building images, hand-patching boxes, knowing which node a workload landed on - and the engineers moved up to the layer above it every time. I think AI is doing the same thing again, one layer higher. What Changed Day to Day I use Claude daily to generate Helm charts and write Terraform modules. The part it actually removed from my day isn’t the thinking - it’s the lookup work. I don’t read through the AWS provider’s changelog to figure out what changed between v5 and v6 anymore; I describe what I want, in whatever shape I want the module or chart to end up, and Claude produces a version of it. It takes iteration to get it into the shape I’d actually ship, but once it’s there, it becomes the example for next time - especially with an AGENTS.md in the repo pointing at it. The same thing happened one level down a while ago: I don’t hand-write raw Kubernetes YAML any more than I hand-write Ansible modules - that’s what Helm charts are for. Increasingly, I don’t hand-write the Helm chart either. I direct what it should do, and Claude writes it. What Hasn’t Changed I still need to know what a good Terraform module or a well-structured Helm chart looks like. I still need to be able to SSH into a node when something genuinely goes wrong and killing the pod isn’t an option - the layer above doesn’t remove the layer below, it just moves how often you have to touch it. And I’m still the one deciding the actual shape of things: what the final version of a module looks like, what’s maintainable a year from now, how a chart should be deployed and versioned. AI does the time-consuming part. I still give the direction. The Skill You Trade Away The honest tradeoff: I’m faster at building and debugging things than I was two years ago, and I’m also visibly rustier at the fundamentals underneath that speed. My HCL syntax recall isn’t what it used to be. Four years ago I hand-wrote a nested for loop - four levels deep, tagging subnets across regions and availability zones in another AWS account - and it took me about an hour to get the syntax right: hcl Copy locals { subnet_tags = merge ([ for account , regions in var . accounts : merge ([ for region , azs in regions : merge ([ for az , subnets in azs : { for subnet_id , tags in subnets : "${account}/${region}/${az}/${subnet_id}" = > tags } ]...) ]...) ]...) } Four merge([...]...) calls stacked on top of each other just to flatten a map of a map of a map of subnets. Claude writes the equivalent in seconds now, and if you asked me to produce that from scratch today, I’d genuinely have to sit and think about it. My reflexes for debugging a broken node over SSH are a little slower than when that was the only way I knew how to do it. That’s not a hypothetical cost - it’s one I can feel happening in real time, the same way plenty of engineers who came up after Kubernetes never really learned to hand-roll a server image, and were fine, because they never needed to. Where This Goes Next The part I’m less sure about is how long “I still give the direction” holds. Right now I’m the one who decides the long-term shape of a stack, because I have the context and the agent doesn’t - not really, not beyond what’s written down in a repo’s AGENTS.md . But that’s exactly the gap those company-wide AI pushes are trying to close: give the agent the whole context, not just one repo’s. If that actually works, an agent with a genuine long-term view of the entire infrastructure - not just this Terraform module, but every decision made across every repo for years - might end up planning better than I do, the same way I can’t out-debug a tool that’s read every changelog for every provider I use. Kubernetes didn’t replace infrastructure engineers, it replaced a layer of their work and moved them up one. I don’t think AI replaces engineering either. I think it’s still busy eating the layer just below “give direction” - and I’m not fully convinced that’s the last layer it eats. AI Kubernetes Terraform Helm Opinion