AI 시대, 인프라 엔지니어의 일은 어디까지 바뀔까

AI가 인프라 엔지니어를 대체할까요?

이 질문보다 더 현실적인 질문은 따로 있습니다.

인프라 엔지니어가 직접 해야 하는 일은 어디까지 줄어들게 될까요?

최근 AI and Infrastructure Engineering이라는 글에서는 이 변화를 Kubernetes와 Fargate가 등장했을 때와 비슷하게 설명합니다.

과거 인프라 엔지니어는 서버에 직접 접속하고, OS 이미지를 만들고, Ansible을 작성하며 시스템을 운영했습니다.

하지만 Kubernetes와 Managed Service가 등장하면서 엔지니어가 직접 관리해야 하는 영역은 크게 줄었습니다.

서버가 사라진 것은 아니지만, 서버를 직접 다루는 일이 줄어든 것입니다.

AI도 비슷한 변화를 만들고 있습니다.

AI가 먼저 없애고 있는 일

저자는 현재 Claude를 활용해 Terraform Module과 Helm Chart를 작성합니다.

예전에는 새로운 AWS Provider 버전의 변경사항을 확인하고, Terraform 문법을 검색하고, 여러 예제를 참고하며 코드를 작성해야 했습니다.

지금은 원하는 구조를 설명하면 AI가 초안을 만들어줍니다.

엔지니어는 그 결과를 검토하고 수정합니다.

즉, AI가 가장 먼저 줄여주고 있는 것은 생각하는 시간보다 찾아보고 타이핑하는 시간입니다.

Terraform 문법을 얼마나 빨리 작성할 수 있는지보다,

를 판단하는 능력이 더 중요해지고 있습니다.

구현보다 방향을 결정하는 일이 남는다

AI가 Terraform을 만들어준다고 해서 인프라 엔지니어링 자체가 없어지는 것은 아닙니다.

여전히 사람이 결정해야 하는 문제가 많습니다.

어떤 Workload를 Kubernetes에 올릴지, Lambda를 사용할지, ECS나 Fargate를 선택할지 결정해야 합니다.

Network 구조, Scaling 기준, 장애 대응 방식, Observability, Security, Cost 역시 코드 생성만으로 해결할 수 없습니다.

AI가 구현 속도를 높여줄 수는 있지만,

무엇을 만들어야 하는지와 그것이 좋은 설계인지 판단하는 일은 여전히 엔지니어에게 남아 있습니다.

지금까지 AI 활용은 대체로 이런 구조입니다.

엔지니어의 의도 → AI → Terraform / Helm / Pipeline

사람이 방향을 결정하고 AI가 구현을 돕습니다.

대신 기본기는 조금씩 사라질 수 있다

흥미로운 부분은 생산성이 올라가는 만큼 일부 능력이 약해질 수 있다는 점입니다.

저자는 AI를 사용하면서 예전보다 훨씬 빠르게 개발하고 디버깅할 수 있게 됐지만, HCL 문법이나 SSH 기반의 저수준 장애 분석 능력은 예전보다 떨어졌다고 이야기합니다.

복잡한 Terraform 표현식을 직접 한 시간 동안 작성하던 경험이 이제는 몇 초짜리 AI 요청으로 바뀌었기 때문입니다.

하지만 이것이 반드시 나쁜 변화인지는 생각해볼 필요가 있습니다.

오늘날 많은 엔지니어가 직접 서버 OS 이미지를 만들지 않아도 인프라를 운영합니다.

필요한 추상화 계층이 올라가면서 이전 세대가 중요하게 생각했던 기술 일부가 자연스럽게 덜 중요해진 것입니다.

AI 역시 비슷한 변화를 만들 가능성이 있습니다.

다음 단계는 Context다

이 글에서 특히 흥미로운 지점은 AGENTS.md와 같은 Context 관리입니다.

현재 AI는 보통 하나의 Repository나 특정 작업의 Context만 알고 있습니다.

하지만 AI가 다음 정보까지 모두 이해하게 된다면 이야기가 달라집니다.

여기에 몇 년 동안 축적된 기술적 의사결정까지 연결된다면 AI는 단순한 코드 생성 도구가 아니라 Infrastructure Engineering System의 일부가 됩니다.

그리고 그 시점에는 새로운 질문이 생깁니다.

Architecture의 방향까지 사람이 계속 결정해야 할까요?

현재 AI는 아직 사람이 방향을 정해줘야 합니다.

하지만 저자는 AI가 이미 '방향을 결정하는 영역 바로 아래'까지 올라왔다고 봅니다.

그 위의 영역까지 올라오지 않을 것이라고 확신할 수는 없습니다.

Infrastructure as Code 다음에는

지금까지 인프라 엔지니어링의 중심에는 Infrastructure as Code가 있었습니다.

인프라를 코드로 만들고, Git으로 관리하고, 자동화하는 것이 핵심이었습니다.

AI가 들어오면서 구조는 조금 달라지고 있습니다.

Infrastructure Knowledge→ Context→ Agent→ Code→ Infrastructure

여기서 중요한 것은 코드보다 그 앞에 있는 Knowledge와 Context입니다.

좋은 문서, ADR, Repository 구조, Naming Convention, 운영 정책, 장애 기록이 앞으로는 단순한 문서화가 아닐 수 있습니다.

이 정보들이 AI Agent가 조직의 인프라를 이해하고 판단하기 위한 데이터가 되기 때문입니다.

그래서 AI 시대의 인프라 엔지니어에게 중요한 역량은 Terraform을 얼마나 빨리 작성하는지가 아닐 가능성이 높습니다.

대신,

좋은 Architecture를 판단하고, 시스템의 Context를 구조화하고, AI가 만든 결과를 검증할 수 있는 능력

이 더 중요해질 수 있습니다.

인프라 엔지니어의 일이 사라진다기보다, 우리가 직접 다뤄야 하는 계층이 계속 위로 올라가고 있는 것입니다.

원문: AI and Infrastructure Engineering — Omegion