누가 종속 소리를 내었는가! - 바이브 코딩 시대의 인프라에 대한 고찰

“누가 종속 소리를 내었는가!”

2026년에도 온프레미스를 선호하는 사람은 많다. 장비를 직접 다루고, 모든 층을 통제하며 운영하는 일이 즐겁다면 이해한다. 지연 시간, 기존 설비와의 연결, 규제 때문에 자체 환경이 필요한 경우도 있다. 다만 “클라우드를 쓰면 종속되니까”라는 말은 납득하기 어렵다. 클라우드간 또는 온프라미스로의 이전 비용은 바이브 코딩의 등장으로 크게 줄어 들었다. 반면 설비 및, 장비, 전문 운영 인력에 묶이는 비용은 여전히 남는다. 어느쪽이 진정한 종속인가?

TL;DR

• 바이브 코딩으로 클라우드 마이그레이션의 노동 비용은 이미 크게 줄었다. 모델과 에이전트가 발전하면 앞으로 더 줄어들 것이라고 본다.
• 온프래미스는 훨씬 더 심히다. 데이터센터를 위한 부동산, 설비, 장비에 더불어 운영인력도 필요하다.
• 클라우드 상에서 운영하는 Kubernetes는 데이턴센터는 필요 없지만 운영을 위한 전문 인력을 고용해야 한다. 이것 또한 종속이다.
• GPU 기반 고성능 컴퓨팅과 LLM 서비스가 빠르게 바뀌는 상황에서 클라우드는 장비를 사지 않고 새 기술을 시험할 수 있게 해 첨단 기술의 진입장벽을 낮춘다.
• 바이브 코딩이 개발의 뉴노멀로 자리 잡으면, 구현과 테스트가 까다로워 기피되던 서버리스 같은 클라우드 네이티브 아키텍처가 더 많이 선택될 것이다.
• 로보코는 현행 문서와 테스트를 정비하고 작은 서비스부터 이전한 뒤, 마련한 테스트·문서로 성공을 확인하고 그 절차를 규칙·스킬로 만드는 방식을 제안한다.

1. 종속성을 다시 정의할 때

클라우드 종속(vendor lock-in)을 말할 때 보통 한 공급자의 관리형 서비스와 API에 깊이 의존하는 상태를 떠올린다. 다른 환경으로 옮기려면 애플리케이션과 데이터를 바꿔야 하니, 공급자를 쉽게 교체할 수 없다는 뜻이다. NIST도 이식성을 다른 환경으로 애플리케이션과 데이터를 수용할 만한 비용으로 옮길 수 있는 능력으로 설명한다.¹

여기서 중요한 단어는 “비용”이다. 종속 여부는 특정 서비스를 썼는지가 아니라, 선택을 바꾸고 싶을 때 무엇을 얼마나 다시 해야 하는지로 판단해야 한다. 클라우드 API를 바꾸는 작업뿐 아니라 서버의 감가상각, 장비 교체, 네트워크 계약, 운영 절차와 인력도 같은 장부에 올려야 한다.

2. 마이그레이션 비용은 이미 크게 줄었고 앞으로 더 줄어든다

예전에는 클라우드에 진입하는 일부터 비쌌다. 새 서비스의 개념을 배우고, 인프라 설정을 다시 쓰고, SDK 호출을 바꾸고, 테스트와 배포 절차를 재구성해야 했다. 특정 클라우드에 최적화할수록 나중에 떠나는 비용이 커진다는 걱정은 합리적이었다.

지금은 AI 에이전트가 서비스 사용 지점을 찾고, 다른 환경의 구성으로 인프라 코드를 옮기고, 애플리케이션 호출부와 테스트를 함께 수정할 수 있다. AWS도 에이전트 기반 도구가 인프라·애플리케이션·코드의 전환을 돕는다고 문서화한다.² 예전에는 사람이 며칠씩 찾아 고쳐야 했던 작업을 에이전트와 함께 훨씬 빠르게 끝낼 수 있다. 마이그레이션의 노동 비용은 이미 크게 낮아졌다.

여기서 변화는 끝나지 않는다. 모델이 긴 코드베이스와 서비스 간 관계를 더 잘 이해하고, 에이전트가 변경·테스트·복구를 더 안정적으로 이어갈수록 이전에 필요한 사람의 시간은 앞으로도 줄어들 것이다. 필자는 바이브 코딩이 자리 잡은 조직에서 이전 작업의 비용이 과거와 비교하기 어려울 만큼 작아질 것으로 본다. 절감 폭은 시스템마다 다르지만 방향은 분명하다. 특정 클라우드의 관리형 기능이 지금의 제품을 더 단순하고 빠르게 만든다면, 막연한 미래의 이전 공포만으로 이를 포기할 이유는 약해지고 있다.

3. 그래도 남는 이전 비용

에이전트가 코드를 바꿔도 데이터는 실제로 이동해야 한다. 데이터베이스 스키마와 기능이 다른 엔진에서 그대로 동작하지 않을 수 있다. AWS의 스키마 변환 도구도 자동 변환할 수 없는 항목을 별도로 표시한다.³ 서비스 중단 시간을 정하고, 이중 운영과 되돌리기 절차를 준비하며, 보안·권한·규제 요건을 다시 확인해야 한다. Google Cloud의 이전 지침도 이런 검증과 비용 산정을 별도의 작업으로 다룬다.⁴

여기에도 바이브 코딩이 개입한다. 스키마 변환안 작성, 데이터 비교 스크립트, 검증 시나리오, 전환·복구 절차의 초안을 에이전트와 함께 만들 수 있다. 데이터 이동·검증·전환에 투입되는 사람의 노동도 과거와 비교하기 어려울 만큼 적어질 수 있고, 앞으로 더 줄어들 것이다. 남는 것은 실제 전송 시간과 요금, 서비스 중단 위험, 최종 결과를 확인할 책임이다. 작은 서비스와 거대한 거래 데이터베이스의 무중단 이전은 다른 문제이므로 총비용을 일률적으로 말할 수는 없다. 하지만 남는 작업이 있다는 사실로 이미 일어난 비용 절감을 지워서는 안 된다.

4. 서버를 소유하면 종속성이 없어질까

온프레미스를 택하면 클라우드 공급자와의 계약은 줄어들 수 있다. 대신 건물과 전력·냉각 설비, 서버와 네트워크 장비, 교체 주기와 유지보수 계약에 묶인다. 자체 Kubernetes 클러스터를 프로덕션에서 운영한다면 고가용성, 인증서, 노드, 보안, 장애 대응과 업그레이드를 계속 맡을 전문 운영 인력도 반드시 확보해야 한다. Kubernetes 공식 문서 역시 이 운영 책임을 항목별로 설명한다.⁵

직접 고용한다면 채용, 온콜, 교육, 인수인계와 퇴사에 따른 공백까지 감당해야 한다. 핵심 운영 지식이 소수에게 쌓일수록 그 사람에게도 의존하게 된다. 외부에 위탁하거나 관리형 Kubernetes를 쓰면 책임의 범위를 바꿀 수 있지만, 운영을 맡을 전문 역량 자체가 필요 없어진다는 뜻은 아니다. 이식 가능한 컨테이너가 조직을 자유롭게 만드는 것은 아니다. 운영 인력을 계속 확보해야 하는 고용의 종속성도 계산해야 한다.

장비를 소유할 때의 기회비용도 커지고 있다. GPU 기반 고성능 컴퓨팅과 LLM 제공 서비스는 빠르게 바뀐다. 서버를 구매하면 그 세대와 교체 주기에 묶이지만, 클라우드에서는 여러 GPU 인스턴스와 새 모델을 제공하는 서비스 카탈로그를 선택해 시험할 수 있다.⁶⁷⁸ 작은 팀도 큰 선행 장비 투자 없이 첨단 기술을 활용할 기회를 얻는다. 이용 가능한 지역, 할당량, 사용료는 확인해야 하지만 기술 접근의 문턱을 낮춘다는 점은 클라우드의 또 다른 장점이다.

5. 차량 공유와 자동차 소유의 차이

차량 공유 서비스를 이용하다가 다른 서비스를 고르는 일에는 불편이 따른다. 요금제와 이용 지역을 다시 확인해야 한다. 그래도 자동차를 이미 구매한 경우와는 선택의 무게가 다르다. 차를 사면 감가상각이 시작되고, 목적에 맞지 않게 되거나 더 나은 차가 나와도 즉시 바꾸기 어렵다. 사용 규모에 따라 주차장과 정비, 운전 인력까지 필요할 수 있다.

클라우드와 자체 데이터센터도 비슷한 면이 있다. 중요한 것은 “빌려 쓰는가, 소유하는가”라는 구호가 아니라 선택을 바꾸는 데 드는 전체 비용이다. 소프트웨어를 다시 구성하는 비용은 모델과 에이전트의 발전으로 계속 내려갈 수 있다. 반면 이미 소유한 장비와 운영 인력을 한꺼번에 바꾸기는 쉽지 않다.

6. 추측 대신 탈출 비용을 재보자

클라우드 종속이 걱정된다면 네이티브 기능을 모두 피하는 대신 작은 이전 실험을 해볼 수 있다. 핵심 서비스 하나를 고르고, 에이전트와 함께 다른 클라우드 또는 자체 환경에서 실행해 본다. 코드와 인프라 설정을 수정하는 데 걸린 시간, 데이터 이전과 검증 시간, 추가 비용, 남은 수작업을 따로 기록한다. 원래 환경으로 되돌리는 절차도 시험한다.

이렇게 하면 “종속될 것 같다”는 감각이 숫자와 작업 목록으로 바뀐다. 규제나 계약 때문에 클라우드를 사용할 수 없거나 어려운 곳은 그 조건을 먼저 지켜야 한다. 그러나 바이브 코딩을 도입한 팀이라면 미래에 못 떠날지도 모른다는 막연한 두려움만으로 지금 유용한 클라우드 기능을 포기할 필요는 없다.

7. 로보코가 제안하는 바이브 코딩 마이그레이션 프로세스

마이그레이션을 에이전트에게 한 번에 맡기기보다, 현재 시스템을 이해하고 결과를 검증할 기준부터 마련해야 한다. 로보코는 다음 순서를 제안한다.

1. 현행 시스템을 분석하고 문서를 최신화한다. 기존 소스코드와 문서를 함께 읽어 서비스 간 의존성, 데이터 흐름, 배포 방식, 운영 절차를 확인한다. 실제 코드와 다른 설명은 고쳐서 에이전트와 사람이 같은 현행 상태를 보게 한다.
2. 테스트를 정비하거나 추가한다. UI 테스트, 통합 테스트(IT), 종단 간 테스트(E2E)로 지금의 동작을 기록한다. 빠진 테스트를 보강해 이전 후에도 같은 사용자 흐름과 서비스 연계가 작동하는지 확인할 기준을 만든다.
3. 에이전트와 계획을 세우고 작은 서비스부터 옮긴다. 서비스별 중요도, 규모, 의존성과 되돌리기 방법을 계획에 담는다. 여러 서비스가 있다면 비교적 작고 중요도가 낮은 것부터 시작하고, 더 크고 중요한 서비스로 확대할 순서를 정한다.
4. 테스트와 문서로 성공 여부를 확인한다. 이전 전에 정비한 UI·통합·E2E 테스트를 새 환경에서 실행한다. 최신 문서에 기록한 데이터 흐름, 서비스 연계, 배포·운영 방식과 실제 동작을 대조하고 차이가 있다면 고친다. 테스트 통과와 문서에 적힌 기대 동작의 일치를 다음 서비스로 넘어가는 기준으로 삼는다.
5. 성공한 절차를 규칙·스킬로 만든다. 첫 서비스가 위 기준을 통과하고 이전 후에도 안정적으로 동작하면 계획, 코드 변경, 테스트, 배포, 검증에서 반복 가능한 단계를 기록한다. 이를 에이전트 규칙이나 스킬로 만들어 다음 서비스에 기계적으로 적용하고, 예외와 최종 승인은 담당자가 확인한다.

첫 성공을 일회성 경험으로 끝내지 않고 재사용 가능한 절차로 만드는 것이 핵심이다. 이전할 때마다 다시 배우는 비용이 줄어들면, 후속 서비스의 마이그레이션은 더 빨라진다.

결론

바이브 코딩이 낮춘 비용은 첫 구현에 그치지 않는다. 문서와 테스트를 최신화하고, 작은 서비스를 실제로 옮겨 검증한 뒤, 성공한 절차를 규칙·스킬로 반복하면 이전 가능성을 말이 아닌 경험으로 확보할 수 있다. 데이터 이동과 규제 검토는 남지만, 모델과 에이전트가 발전할수록 구현과 검증에 드는 시간은 더 줄어들 것이다.

이제 인프라 종속을 계산할 때는 클라우드 API뿐 아니라 장비 투자와 Kubernetes 운영 인력도 함께 봐야 한다. 빠르게 바뀌는 GPU와 LLM 서비스를 장비 구매 없이 시험할 수 있다는 이점도 같은 계산에 넣어야 한다. 현재 제품에 가장 잘 맞는 아키텍처를 선택하고, 필요할 때 옮길 능력을 계속 확인하는 편이 합리적이다. 필자는 바이브 코딩이 개발의 뉴노멀로 자리 잡으면서, 구현과 테스트가 까다로워 선택을 주저했던 서버리스 같은 클라우드 네이티브 아키텍처가 더 많이 선택될 것으로 본다.