코딩 에이전트를 사용하면 내부 도구를 훨씬 빠르게 만들 수 있게 되었지만, Future of Platform Engineering 2026 보고서의 데이터는 구축의 용이성이 반드시 명확한 비전을 의미하지는 않는다는 점을 보여준다. 플랫폼 엔지니어링 전문가 379명 가운데 기능 대부분을 처음부터 구축하는 팀은 명확한 전략의 부재를 장애물로 여길 가능성이 약 3.5배 더 높았다.
이 결과가 처음부터 구축하는 것이 잘못된 결정이라는 점을 입증하는 것은 아니다. 다만 플랫폼 역량을 제공하는 방식과 팀이 따르는 방향의 명확성 사이에 연관성이 있음을 드러낸다.
기성 도구가 가장 일반적인 선택이다
응답자의 51.3%는 기성 기본 도구를 사용하는 것이 플랫폼 기능을 지원하는 주요 접근 방식이라고 답했으며, 31.2%는 기존 템플릿에 의존했고 17.5%는 처음부터 구축했다. 고성과로 분류된 팀에서는 도구 의존도가 58.8%로 더 높았고, 템플릿은 47.8%, 처음부터 구축하는 방식은 33.3%였다.
예외는 특정 기술 경로와 직접 연결된 환경에서 나타났다. 예를 들어 로컬 개발 환경, 원클릭으로 생성되는 프로젝트, 임시 환경 등이 이에 해당한다. 이러한 경우 템플릿은 일반 도구가 쉽게 제공하지 못하는 승인된 경로와의 호환성을 제공할 수 있다.
임시 환경은 플랫폼 성숙도의 지표다
임시 환경을 제공하는 팀은 소프트웨어 제공 속도와 안정성, 코드 커버리지 및 비용 관리에서 AI가 긍정적인 영향을 미쳤다고 보고할 가능성이 더 높았다. 그 영향을 매우 긍정적이라고 평가한 팀 가운데 4분의 3 이상이 임시 환경을 사용하고 있었다.
그러나 이러한 관계가 임시 환경 자체가 개선을 일으켰다는 뜻은 반드시 아니다. 임시 환경을 제공하는 팀은 여러 자동화 역량을 포함한 더 폭넓은 플랫폼 안에서 운영되는 경우가 많다. 따라서 안정성을 희생하지 않고 AI가 만들어내는 변화의 규모를 수용하는 데에는 플랫폼의 범위와 성숙도가 더 중요한 요인일 수 있다.
이 소식이 중요한 이유는 무엇인가?
실무적으로 가장 중요한 변화는 AI가 코드 작성 비용은 낮추지만 코드를 보유하는 데 드는 비용까지 없애지는 않는다는 점이다. 빠르게 구축한 도구에는 유지보수, 업그레이드, 거버넌스가 필요하며, 개발 경로에서 발생하는 변화의 규모가 커지면 운영 부담이 증가할 수 있다.
데이터도 이러한 구분을 뒷받침한다. 처음부터 구축하는 방식이 우세한 팀의 57.9%는 명확한 전략의 부재를 장애물로 꼽았으며, 템플릿을 사용하는 팀에서는 15.6%, 기본 도구를 사용하는 팀에서는 16.7%였다. 또한 처음부터 구축하는 팀은 레거시 시스템 업데이트와 언어 마이그레이션에 AI를 더 많이 사용했다. 이는 이러한 사용의 일부가 팀 스스로 만든 복잡성을 유지하는 데 투입되고 있음을 시사한다.
질문은 단순히 구축이냐 구매냐가 아니다
구축 또는 구매 결정에서 가장 흔한 이유는 29.6%를 차지한 비용·편익 분석이었다. 그 뒤를 오픈 소스 선호도 28.6%, 적합성 및 요구사항 평가 22.4%, 상용 도구 선호도 22.4%, 본질적인 차별화를 위한 구축 16.3%가 이었다.
이 자료는 데이터만으로 어느 쪽인지 결론 내릴 수 없는 두 가지 가능한 해석을 제시한다. 전략이 구축 또는 구매 결정보다 앞설 수도 있고, 구축 자체가 아직 구체화되지 않은 전략을 일시적으로 대체하는 수단이 될 수도 있다. 그러나 편집상 가장 명확한 결론은 문제가 처음부터 구축하는 것에 있는 것이 아니라, 특정한 이유 없이 이를 기본값으로 채택하는 데 있다는 점이다. 고유한 역량은 조직의 맥락을 중심으로 구축해야 하며, 표준적인 문제를 효율적으로 해결하는 도구는 유지보수 비용과 장기적인 의존성을 고려해 구매하거나 도입해야 한다.
뉴스 출처
The New Stack - Software Development
원문 보기 ↗