데브옵스 플랫폼 전면 교체, 예산 초과와 매몰비용 “경고등”

최근 조사에 따르면, 많은 기업이 소프트웨어 개발 라이프사이클을 자동화하고 간소화하는 플랫폼을 채택했고, 지난 2년 동안 많은 조직이 데브옵스나 CI/CD 플랫폼으로의 전환을 완료했다. 이들 플랫폼은 코딩 프랙티스를 최적화하는 목적뿐 아니라 개발자가 사용하는 툴 수를 줄이고 AI 기반 코딩 코파일럿을 최대한 활용하는 방법으로 도입됐다.

가트너는 깃허브, 깃랩, 하니스 등을 포함한 데브옵스 플랫폼 사용률이 2년 전 25%에서 2027년에 80%에 이를 것으로 전망했다. 소프트웨어 딜리버리 솔루션 업체 클라우드비즈(CloudBees)가 최근 진행한 조사에서는 응답한 IT 리더의 85%가 지난 2년 안에 데브옵스 플랫폼으로 전환했다고 답했다.

클라우드비즈의 CEO 아니즈 카푸르는 애플리케이션 개발 현대화 요구, 비용 절감, 개발자가 사용하는 앱 수를 줄이려는 목적 등이 기업을 이런 움직임으로 이끌고 있다고 설명했다. 카푸르는 “툴 확산은 여러 솔루션 업체와 계약해야 하므로 조달 부담을 만든다. 서로 다른 툴을 연동해야 하므로 통합 부담도 커진다”라고 지적했다.

많은 소프트웨어 개발 책임자가 조직 내부에서 어떤 코딩 앱과 에디터가 최고인지를 놓고 벌어지는 격렬한 논쟁도 끝내고 싶어한다. 카푸르는 “조직 내부에서 누구의 툴이 더 낫다고 종교전쟁 같은 논쟁이 생긴다. 모두의 ‘종교’를 하나로 통일하면 더 좋아질 것이라는 기대가 생기고, 이런 문제를 한 번에 해결하려는 시도가 나타난다”라고 설명했다.

비용 초과

하지만 클라우드비즈 조사 결과는 데브옵스 플랫폼에서 흔히 선택하는 전면 교체 방식의 전환이 예기치 않은 비용 초과 같은 복잡성을 안고 있다고 경고한다. 조사에 응한 IT 리더 10명 중 6명 정도가 지난 1년 동안 데브옵스 전환에 100만 달러 이상을 지출했다고 답했고, 그중 전면 교체 방식을 선택한 기업은 평균 175만 달러를 쓴 것으로 나타났다.

또한 단일 이벤트로 플랫폼 전환을 진행한 기업은 평균 예산보다 18%, 즉 기업당 30만 달러 이상을 초과 지출했다고 전했다. 더 심각한 문제는 IT 리더의 1/3 이상이 전환 예산의 25%가 장기적 비즈니스 효과 없이 매몰 비용이 됐다고 답했다.

반면, 조사에 참여한 IT 리더 10명 중 9명 이상은 개발 툴을 교체하는 대신 통합하는 방식이 더 효율적이라고 평가했다. 클라우드비즈는 2024년 가트너 데브옵스 플랫폼 매직 쿼드런트에서 도전자로 분류됐지만, 카푸르는 기업이 교체가 아닌 통합 방식을 택해야 한다고 조언했다.

카푸르는 데브옵스 플랫폼이 AI 기반 코딩 보조 기능을 제공하지만, 지난 1년 동안 코파일럿 간 경쟁이 치열했음에도 생성 코드 대부분이 “너무 단순하고 사실상 차별성이 없는 수준”이라고 설명했다.

대부분 조직에서 개발자는 다양한 코딩 툴을 선호한다. 카푸르는 “개발자에게 어떤 툴을 쓰라고 지시하는 것은 10대에게 어떤 옷을 입으라고 지시하는 것과 비슷하다”라며, “효과가 절반 정도에 그친다”라고 말했다.

하나의 데브옵스 플랫폼으로 통합하면 개발자 선택권이 줄고 특정 솔루션 업체에 종속되는 문제도 생긴다. 카푸르는 “통합이 해답이라고 보지 않는다. 통합은 혁신 정신에 반한다”라며, “한 솔루션 업체가 모든 문제를 해결할 수 있다고 전제하는 셈이다”라고 강조했다.

거버넌스와 유연성의 충돌

전면 교체 방식 전환의 비용 문제는 일부 개발자에게 공감을 불러일으켰다. 헤드스톰(Headstorm)의 소프트웨어 개발팀 아키텍트 밀란쿠마르 라나는 기업이 더 빠른 딜리버리, 강화된 보안, 수월한 거버넌스를 위해 통합 데브옵스 솔루션을 찾는 흐름이 분명하게 나타나고 있다고 말했다.

라나는 통합 데브옵스 플랫폼은 거버넌스, 감사, 보안 관리가 간소화되지만, 젠킨스, 지라, 소나큐브처럼 각각 분리된 기술은 유연성은 높지만 유지 관리가 복잡해진다고 지적했다. 또, 전환을 고려하는 기업의 경우 개발자 재교육, 새로운 지속적 통합·배포 파이프라인 구축, YAML 템플릿 개선 같은 작업이 전체 예산의 15~20% 초과 지출을 불러올 수 있다고 설명했다.

헤드스톰 역시 솔루션 업체를 변경하는 과정에서 규제 준수를 위한 시스템 분해, 계정 관리, 권한 재정비, 규정 변경 검토에 소요된 시간이 가장 큰 숨은 비용이 됐다. 라나는 데브옵스 플랫폼 전환 시 단계별 접근법을 취해야 한다며, “비운영 환경 파이프라인과 개념 검증부터 시작해, 이후 핵심 워크로드로 넘어가야 한다”라고 강조했다.

플랫폼 옹호론

클라우드비즈 보고서가 전환 작업에 대한 우려를 제기했지만, 다른 데브옵스 플랫폼 관계자는 상황이 과장돼 있다고 반박했다.

하니스(Harness)의 현장 CTO 지그니시 파텔은 하니스 데브옵스 플랫폼이 지속적 딜리버리와 통합, 코드와 보안 테스트 기능을 제공하지만, 개발자는 선호하는 IDE를 계속 사용할 수 있다고 설명했다. 파텔은 “개발자는 개발 과정에서 어떤 툴을 쓸지 가장 신경 쓰지만, 테스트나 보안 테스트, 배포, 비용 최적화 툴에는 그렇게 민감하지 않다. 개발자가 신경 쓰는 것은 IDE다”라고 강조했다.

파텔은 금융 서비스 회사 모닝스타에서 클라우드·데브옵스 총괄 이사로 근무했으며, 당시 하니스를 도입하는 전면 교체 방식 전환 작업을 지휘했는데, 과정이 원활했다고 밝혔다.

전환 과정의 가장 큰 난관은 초기 동의 확보였다. 파텔은 “해결 과제는 툴 자체보다는 조직 차원의 문제에 가깝다”라며, “기술은 가장 쉬운 부분이다. 대부분 어려운 문제는 사람이며, 새로운 방식이 실제 업무에 가치를 더한다는 믿음을 심어주는 게 관건이다”라고 강조했다.

전면 교체 방식 전환이 비용 초과를 초래한다는 우려도 일축했다. 파텔은 “전환 과정에서도 기존에 갖고 있던 다른 툴을 내려놓게 된다”라며, “현재 15개 정도의 개별 툴을 쓰고 있다면, 하니스 같은 솔루션으로 전환하면 그 15개를 계속 유지하지 않는다”라고 설명했다.

깃허브의 COO 카일 데이글도 깃허브 플랫폼을 사용하는 개발자는 선호하는 IDE, CI/CD 시스템, AI 모델을 그대로 사용할 수 있다고 설명했다. 데이글은 “깃허브는 항상 개발자 선택권을 중심에 두고 설계해 왔다”라며, “특정 툴 세트나 특정 방식에 개발자를 묶어두는 방식을 옳다고 보지 않는다”라고 밝혔다.

깃허브의 데이터에 따르면, 기업 90%가 플랫폼에 존재하는 오픈소스 코드를 활용하고 있다. 데이글은 “진정한 가치는 전체 개발 라이프사이클과 커뮤니티를 코드에 결합하는 데서 나온다”라며, “깃허브에서 개발한다는 것은 플랫폼에 갇힌다는 의미가 아니라, 소프트웨어 공급망과 직접 연결된다는 뜻이다. 이 ‘가까움’이 혁신 속도를 높인다”라고 강조했다.
dl-ciokorea@foundryco.com