The AI Forecast 65화, "바이브 코딩 리스크: 통제되지 않은 AI는 클라우드 ROI를 어떻게 악화시키는가” 편에서는 David Linthicum이 진행자 Paul Muller와 함께 하이브리드 및 멀티 클라우드 환경에 숨겨진 비용을 짚어보고 클라우드 거버넌스와 회복 탄력성이 경영진의 핵심 관심사로 자리잡은 원인을 설명합니다.
최근 유명 클라우드 장애 사례 *를 통해 숨겨진 의존성과 단일 장애 지점이 드러나면서, IT 리더들은 하이브리드 클라우드 환경 전반의 회복 탄력성, 데이터 관리, 그리고 책임성에 대한 접근 방식을 다시 고민해야 하는 상황에 놓였습니다.
다음은 Paul과 David의 대화에서 특히 주목할 만한 내용입니다.
핵심 차이점: 안정성과 회복 탄력성
Paul: '회복 탄력성(resilience)’은 꽤 흥미로운 단어입니다. 많은 사람들이 안정성(reliability)과 같은 의미로 생각하는 경우가 많거든요. 그런데 두 개념은 사실 큰 차이가 있죠?
David: 맞습니다. 회복 탄력성은 장애나 사고가 발생했을 때에도 시스템 처리와 비즈니스 운영이 멈추지 않도록 하는 능력을 의미합니다. 쉽게 말해, A안, B안, C안이 모두 준비되어 있는 상태라고 볼 수 있죠. 얼마나 유연하게 대응할 수 있는지, 그리고 장애를 견딜 수 있는지가 핵심입니다. 반면 안정성은 개별 구성 요소의 특성에 가깝습니다. 해당 요소가 얼마나 안정적으로 동작하는지, 문제가 생겼을 때 얼마나 잘 복구되는지를 의미하죠. 회복 탄력성은 기업이 직접 책임져야 하는 영역이지만, 안정성은 그렇지 않습니다. 예를 들어 클라우드 서비스를 사용한다면 안정성은 보통 서비스 제공업체의 책임입니다. 그렇다고 해서 사용자가 영향을 받지 않는 것은 아닙니다. 장애가 발생해도 비용은 그대로 지불해야 하고, 클라우드 제공업체가 장애에 대해 요금 크레딧을 제공하는 경우도 없습니다.
Paul: 그렇다면 회복 탄력성은 개별 구성 요소의 결과라기보다 아키텍처 차원의 문제라고 봐야겠네요? 결국 시스템을 어떻게 설계하느냐의 문제니까요. 기업 아키텍처와도 연결되는 부분이고요.
David: 회복 탄력성은 전적으로 아키텍처의 문제이며, 애플리케이션 계층과 기업 계층 모두에서 고려해야 합니다. 회복 탄력성은 반드시 사전에 설계하고 계획해야 합니다. 자동으로 생기는 것이 아니며, 클라우드 안에 포함되어 있는 것도 아닙니다. 많은 사람들이 바로 이 지점에서 의외라고 느낍니다. 어떤 문제가 발생하면 클라우드가 알아서 완전히 대응해 줄 것이라고 생각했지만, 실제로는 클라우드 역시 다른 시스템과 마찬가지로 한계를 가진다는 사실을 깨닫게 되었기 때문입니다. AI 시스템이든 기업 아키텍처든, 어떤 아키텍처를 기획하든 그 핵심에는 회복 탄력성이 포함되어야 합니다. 회복 탄력성은 보안이나 거버넌스, 그리고 우리가 고려해야 하는 다른 요소들만큼 중요하며, 경우에 따라서는 그보다 더 중요할 수도 있습니다. 또한 회복 탄력성은 실제 운영에 적용되어야 하며, 최악의 상황에서도 비즈니스 처리가 중단되지 않는다는 점을 지표로 입증할 수 있어야 합니다. 이를 위해서는 결국 시간과 비용을 들여 직접 설계하고 검증해야 합니다.
회복 탄력성이 없다면, 이런 상황이 발생했을 때 제대된 복구가 불가능합니다.
하이브리드 환경에서의 책임성과 통합 가시성
Paul: 요즘 많은 사람들이 하이브리드 클라우드를 이야기하고 있는데요. 어떤 면에서 하이브리드 클라우드는 온프레미스와 클라우드의 장단점이 모두 섞여 있는 형태처럼 보이기도 합니다. 결국에는 하이브리드 환경이 표준으로 자리잡을 것으로 전망되는데, 이런 환경에서 어떻게 명확한 책임성과 통합 가시성을 확보할 수 있을까요?
David: 하이브리드나 멀티 클라우드 환경을 구축한다면, 그 구조에 내재된 복잡성을 관리하는 것이 핵심입니다. 그리고 그 전반을 관통하는 공통 제어 기반으로서 회복 탄력성이 중요한 역할을 하게 됩니다. 많은 사람들이 “하이브리드로 구성해 두면 온프레미스로 페일오버하거나, 다른 클라우드로 페일오버할 수 있겠지”라고 생각합니다. 그 자체로는 문제가 없고 실제로도 잘 동작합니다. 다만 그만큼 비용이 든다는 점은 감안해야 합니다. 결국 핵심은 이러한 비용과 필요한 리소스를 정확히 이해하고 이를 어떻게 관리할 것인가이며, 이 부분이 가장 큰 쟁점이 됩니다.
멀티 클라우드는 더 효율적인 시스템을 구축하기 위해 최적의 기술을 선택해 사용할 수 있다는 점에서 분명 장점이 있습니다. 하지만 이러한 아키텍처에서는 회복 탄력성과 안정성이 중요한 과제로 남습니다. 저는 항상 회복 탄력성과 효율성을 모두 얻기는 어렵다고 이야기합니다. 회복 탄력성을 중심으로 아키텍처를 설계할 것인지, 아니면 연간 몇 차례의 장애와 그로 인해 발생하는 막대한 비용을 감당할 것인지 선택해야 합니다.
클라우드 비용 증가 및 송환 추세
Paul: 대규모 장애, 비용 초과, 복잡한 책임 구조 같은 문제를 고려하면, 많은 기업이 워크로드를 다시 자체 통제 가능한 환경으로 되돌리는 방안을 검토하는 것도 자연스러운 흐름입니다. 현재 상황은 어떻고, 일부 워크로드를 다시 온프레미스로 옮기려 할 때 실제로 어떤 어려움이 있나요?
David: 가장 큰 문제는 비용입니다. 이는 크게 두 가지 측면과 관련이 있습니다. 첫째, 이미 애플리케이션을 구축하고 모든 것을 클라우드로 이전하는 데 상당한 비용을 투자한 상태에서 이를 다시 온프레미스로 옮기려면 비슷한 수준의 비용을 또 부담해야 합니다. 둘째, 이러한 결정을 이사회에 설명하고 향후 계획을 설득해야 합니다. 이는 쉽지 않은 일입니다. 당초에 더 높은 가치와 안정성을 기대하고 클라우드로의 전환을 추진한 것이었는데, 그 기대만큼의 성과를 내지 못했다는 점을 인정해야 하기 때문입니다. 결국 누군가는 책임을 지고, 더 높은 수준의 하드웨어 통제력을 확보하기 위해 다시 온프레미스 환경으로 전환해야 한다는 점을 설명해야 합니다.
일반적으로는 코로케이션이나 관리형 서비스 제공업체를 활용하는 것이 더 효율적인 경우가 많습니다. 하지만 많은 기업들이 이미 클라우드 비용에 큰 부담을 느끼고 있습니다. 여기에 AI 워크로드까지 도입하려다 보니 비용이 더욱 커지면서 클라우드를 감당하기 어려워 전환을 서두르는 상황입니다. 클라우드는 AI를 구현하기 위한 가장 손쉬운 선택지이자, 이러한 시스템을 구축할 때 가장 부담이 적은 경로입니다. 필요할 때 즉시 활용할 수 있는 전체 생태계가 갖춰져 있지만, 대부분의 기업에게는 그 비용이 지나치게 부담스럽습니다. 만약 경제적인 이유로 클라우드 송환을 검토한다면, 이를 효과적으로 수행하기 위한 리소스와 체계를 반드시 마련해야 합니다.
Paul: 기업 현장에서 얼마나 많은 개발자들이 바이브 코딩 앱으로 작은 사이드 프로젝트를 시작했다가, 컴퓨팅과 스토리지를 예상보다 훨씬 많이 사용해 비용 초과를 일으키고 있을까요?
David: 바이브 코딩의 경우, 개발자는 자신이 이해한 내용을 AI에게 전달해 어떤 코드를 작성할지 지시하는 방식으로 코딩하게 됩니다. 문제는 AI가 그 과정의 세부적인 맥락까지는 제대로 이해하지 못한다는 점입니다. AI는 효율성을 어떻게 고려해야 하는지도 제대로 이해하지 못하기 때문에, 결국 더 많은 비용을 쓰게 됩니다. 그래서 이런 바이브 코딩이라는 개념은 생각해 보면 흥미롭기는 하지만 결국에는 사람의 통제가 반드시 필요합니다. 저도 이런 코딩 시스템을 많이 봐왔고, 제 고객들 역시 대부분 이를 시도해 보고 있지만, 원하는 수준의 효율성을 확보하지 못해 실패하는 경우가 많습니다.
David Linthicum와의 전체 대담은Spotify, Apple Podcasts 및 YouTube에서 The AI Forecast를 통해 확인할 수 있습니다.
