AI가 코드를 대신 짜도, Platform Engineering은 사라지지 않는다

코드 작성 비용이 낮아질수록, 잘 만들어진 공통 기반의 가치는 오히려 커질 수 있습니다.

AI 코딩 에이전트가 빠르게 발전하면서 소프트웨어 개발에서는 흥미로운 질문이 나오기 시작했습니다.

“이제 AI가 필요한 코드를 그때그때 만들어준다면, 굳이 공통 플랫폼을 만들고 재사용할 필요가 있을까?”

Evan Meagher는 Platform Engineering still matters라는 글에서 이 질문을 다룹니다.

과거 Platform Engineering의 중요한 가치 중 하나는 Reuse, 즉 재사용이었습니다.

여러 팀에서 반복적으로 필요한 인증, 배포, 인프라, 관측성 같은 기능을 각 팀이 다시 만들지 않고 공통 플랫폼으로 제공하는 방식입니다.

그런데 Agentic Coding 시대에는 상황이 달라 보입니다.

필요한 것이 있다면 Claude나 Codex 같은 에이전트에게 그냥 새로 만들어달라고 하면 되기 때문입니다.

하지만 Evan Meagher의 주장은 반대입니다.

AI가 코드 작성 비용을 낮췄다고 해서 재사용의 경제성이 사라진 것은 아닙니다.

코드는 공짜가 아닙니다

최근 자주 등장하는 표현이 있습니다.

“The cost of writing code is going to zero.”

하지만 실제로는 0이 아닙니다.

AI가 코드를 작성하려면 토큰을 사용해야 하고, 기존 코드를 읽어야 하고, 컨텍스트를 이해해야 하고, 테스트와 검증도 필요합니다.

즉 코드 작성 비용의 형태가 바뀌었을 뿐입니다.

Evan Meagher는 그래서 “코드 작성 비용이 0으로 간다”는 표현을 이제는 버려야 한다고 주장합니다. 비용이 크게 낮아진 것은 맞지만 토큰 역시 실제 비용을 가진 유한한 자원이기 때문입니다.

여기서 Platform Engineering의 가치가 다시 등장합니다.

매번 전체 스택을 만들 필요는 없습니다

예를 들어 새로운 서비스를 하나 만든다고 생각해봅시다.

AI 에이전트에게 이렇게 요청할 수도 있습니다.

물론 가능합니다.

하지만 회사 안에 이미 잘 만들어진 Internal Platform이 있다면 이야기가 달라집니다.

에이전트에게 필요한 것은 훨씬 줄어듭니다.

“우리 플랫폼 위에 이 서비스를 배포해줘.”

이미 아래 계층이 존재하기 때문입니다.

Application ────────────── Internal Platform ────────────── CI/CD Infrastructure Observability Security Networking Cloud

AI가 전체 스택을 매번 새로 생성하는 것보다 기존 플랫폼을 활용하면서 상위 계층만 구현하도록 하는 편이 더 적은 작업으로 이어질 수 있습니다.

Meagher는 이것을 소프트웨어 엔지니어링이 오랫동안 활용해 온 Leverage의 원리로 설명합니다. 프로그래밍의 추상화 수준이 한 단계 올라갔을 뿐, 기존 구성요소 위에서 더 높은 가치를 만드는 원리는 사라지지 않았다는 것입니다.

Agent에게도 좋은 추상화가 필요합니다

이 관점에서 보면 Platform Engineering의 사용자가 개발자에서 끝나지 않을 수도 있습니다.

앞으로 Internal Developer Platform의 중요한 사용자는

Developer + AI Agent

가 될 가능성이 있습니다.

사람에게 좋은 플랫폼이

“복잡한 인프라를 몰라도 안전하게 서비스를 배포할 수 있는 환경”

이었다면,

Agent에게 좋은 플랫폼은

“전체 시스템을 다시 이해하거나 구현하지 않아도 제한된 컨텍스트만으로 안전하게 작업할 수 있는 환경”

이라고 볼 수 있습니다.

즉 Platform Engineering은 AI 때문에 필요 없어지는 것이 아니라 AI가 효율적으로 작업할 수 있는 경계를 제공하는 역할까지 확장될 수 있습니다.

코드 구조도 AI 비용에 영향을 줍니다

이 주장은 비슷한 시기에 공개된 Thoughtworks의 실험에서도 흥미롭게 나타납니다.

Agent가 만든 애플리케이션에서 하나의 Rust 데이터 접근 파일이 17,155줄까지 커졌고, 이를 단계적으로 리팩터링한 뒤 동일한 변경 작업을 반복했습니다.

결과가 흥미롭습니다.

같은 작업을 수행하는 데 필요한 입력 토큰이

159,564 → 27,360

으로 감소했습니다.

약 83% 감소입니다.

코드의 전체 양이 크게 사라진 것이 아니라, 구조가 개선되면서 Agent가 작업을 위해 읽어야 하는 코드의 범위를 더 작게 선택할 수 있게 된 것이 주요 원인으로 분석됐습니다.

이것은 중요한 변화입니다.

과거 좋은 아키텍처와 리팩터링은 주로

사람의 인지 부하를 낮추기 위한 작업

이었다면,

앞으로는

AI의 Context와 Token 비용을 낮추는 작업

이 될 수도 있습니다.

Platform Engineering의 ROI도 달라질 수 있습니다

그래서 AI 시대의 Platform Engineering ROI를 단순히

“개발자 몇 명의 시간을 얼마나 절약했는가”

만으로 볼 필요가 없을지도 모릅니다.

앞으로는 이런 지표도 중요해질 수 있습니다.

Agent가 읽어야 하는 Context

반복 생성되는 코드의 양

서비스 하나를 만드는 데 필요한 Token

Agent가 직접 다뤄야 하는 인프라 영역

표준에서 벗어난 구성의 비율

검증해야 하는 변경 범위

좋은 플랫폼이 존재하면 AI에게 맡겨야 하는 문제의 범위 자체를 줄일 수 있습니다.

결국 중요한 것은 AI가 얼마나 많은 코드를 만들어낼 수 있는지가 아닙니다.

얼마나 적은 코드와 Context만으로 원하는 결과를 만들 수 있도록 시스템을 설계했느냐가 더 중요해질 수 있습니다.

AI는 Platform Engineering을 없애기보다 이유를 하나 더 만들고 있습니다

AI가 코드를 빠르게 만들어준다고 해서 모든 서비스를 처음부터 다시 만드는 것이 효율적인 것은 아닙니다.

잘 만들어진 인증 시스템이 있다면 재사용하고,

검증된 배포 플랫폼이 있다면 재사용하고,

표준 Observability가 있다면 재사용하고,

검증된 Infrastructure Module이 있다면 재사용하는 편이 합리적입니다.

그 위에서 AI가 비즈니스에 필요한 부분에 집중하게 만드는 것입니다.

Platform Engineering의 본질은 결국

개발자가 모든 것을 직접 만들지 않아도 되도록 좋은 추상화를 제공하는 것이었습니다.

Agentic Coding 시대에는 여기에 하나가 추가됩니다.

AI Agent도 모든 것을 다시 만들지 않아도 되도록 만드는 것.

코드를 작성하는 비용은 계속 낮아질 수 있습니다.

하지만 좋은 시스템을 반복해서 활용할 수 있도록 만드는 가치까지 0이 되는 것은 아닙니다.

오히려 코드 생성량이 폭발적으로 늘어날수록 좋은 플랫폼과 아키텍처가 제공하는 레버리지는 더 중요해질 수도 있습니다.

SourceEvan Meagher, Platform engineering still matters — Reuse is a good thing, even with agentic coding, July 31, 2026.Giles Edwards-Alexander, The Economic Benefit of Refactoring, Thoughtworks/Martin Fowler, July 30, 2026.