AX란 무엇인가 (7)

변화 속도와 비용에 고통받는 엔터프라이즈 AI

요즘 사내 AX(AI 전환) 전담 IT 조직의 일상은 그야말로 총성 없는 전쟁터다.

당장 현재 내 상황만 해도 고객 응대를 위한 보이스봇(Voicebot)을 구축하고, 에이전틱 AI(Agentic AI)가 통일된 환경에서 동작하도록 사내 플랫폼을 정립하며, 표준화된 문서 기반 AI 정착을 위해 전사 RAG 프로젝트를 이끌고 있다. 여기에 더해, 다른 부서들이 쏟아내는 수많은 AI 프로젝트의 기술 표준과 거버넌스까지 심사해야 하는 실정이다.

겉보기에는 화려하고 체계적인 AI 생태계가 구축되는 듯하다. 하지만 막상 그 뚜껑을 열어보면, AX를 이끄는 리더들은 전혀 예상치 못한 두 가지 거대한 장벽에 직면하게 된다.

바로 '감당할 수 없는 기술의 속도'와 '비효율'이라는 문제이다.

1. 기술의 속도

IT가 마주한 첫 번째 절망은 기술의 발전 속도가 기존의 IT 프로젝트 방법론(워터폴이든 애자일이든)을 아득히 초월해 버렸다는 점이다.

한 예로 불과 반년 전, 보이스봇 프로젝트를 검토할 때만 해도 업계의 표준은 명확했다.

사용자의 음성을 텍스트로 바꾸고(STT), 이를 API 오케스트레이션을 통해 MCP 기반의 툴 콜링(Tool Calling)으로 처리한 뒤, 다시 음성으로 변환(TTS)하는 파이프라인이었다. 수많은 개발자가 이 단계별 지연 시간을 줄이기 위해 밤을 새웠다.

그런데 프로젝트가 한창 진행 중인 지금, 시장에는 S2S(Speech-to-Speech) 모델이 등장해 버렸다. 텍스트 변환 과정을 생략하고 음성을 음성으로 직접 이해하며, 툴 콜링 까지 네이티브로 처리하는 압도적인 효율성을 보여준다. 물론 아직 예외 오류 처리나 긴 문맥(Context) 관리 영역에서 숙제가 남아있지만, 이는 그저 시간문제일 뿐이다.

이러한 상황에서 "아직 S2S는 불안정하니 우리가 정교하게 짜놓은 STT-TTS 파이프라인이 더 우수하다"고 주장하는 것은,

"통신이 가끔 끊기는 최신 내비게이션보다 어제 갓 인쇄된 종이 지도가 더 정확하다"

며 고집을 피우는 것과 같다. 결국 사람들의 습관은 더 빠르고 효율적인 기술을 향해 이동하기 마련이기 때문이다.

에이전트 AI를 위한 통합 환경(MCP 등) 구축도 마찬가지다. 복잡한 프로토콜 서버를 무겁게 띄우는 대신, 이제는 가벼운 skill.md 파일 하나로 프롬프트와 API 스펙을 정의해 유연하게 연동하려는 시도들이 주를 이룬다. 무언가를 거창하게 '시작'하기도 전에 패러다임이 가볍게 우회해 버리는 시대.

이제 IT 조직은 뼈대를 세우는 동시에 언제든 모듈을 미련 없이 갈아 끼울 수 있는 '극단적인 유연성'을 아키텍처에 강제해야만 한다.

2. '제대로' 쓰는 사람이 없다

속도보다 더 심각한 두 번째 문제는, 이 훌륭한 인프라를 타면서도 AI를 "효율적이고 제대로" 사용하는 사람이 놀라울 정도로 적다는 사실이다.

사내 AI 프로젝트들의 거버넌스 심사를 들어가 보면, 아키텍처 설계도는 화려하다. 하지만 실제 프롬프트와 LLM 호출 로직을 뜯어보면 경악할 때가 많다.

단 한 번의 파이프라인 최적화로 해결할 수 있는 문제를, 오로지

"우리 프로젝트의 AI는 정확도가 높다"

고 자랑하기 위해 무조건 가장 무겁고 비싼 하이엔드 모델만 수십 번씩 호출하는 이른바 '스파게티 프롬프트'가 난무한다. 게다가 이 비용은 고스란히 고객사나 전사 IT 인프라 비용으로 청구된다. 예를 들어 보자. '수십 페이지에 달하는 방대한 텍스트의 핵심을 뽑아 클렌징하고, 이를 다른 언어로 번역하는 작업'이 있다.

효율을 모르는 개발자는 이 거대한 원문을 통째로 가장 비싸고 무거운 모델(예: Claude 4.6 Sonnet, Opus 등)에 밀어 넣는다. 원문 그대로 번역을 시키고, 다시 그 모델로 클렌징을 한 뒤, 마지막으로 요약을 시킨다. 불필요한 입력 토큰(Input Token) 비용이 폭발적으로 발생하고 응답 속도는 거북이처럼 느려진다.

반면, AI의 작동 원리를 '제대로' 이해하는 엔지니어는 먼저 빠르고 비용이 극도로 저렴한 경량화 모델(Haiku, Flash 등)을 사용해 방대한 원문에서 핵심만 요약하고 추출한다. 텍스트의 양이 10분의 1로 줄어들면, 그때 클렌징을 거쳐 고성능 모델에 번역을 맡긴다. 텍스트 양이 작다면 요약과 번역을 단일 프롬프트로 합쳐 한 번에 처리할 수도 있다. 결과물의 질은 동일하거나 더 깔끔한데, 소요되는 토큰 비용과 시간은 수십 배 절감된다.

원하는 결과물을 얻었다고 해서 모두 성공적인 프로젝트는 아니다. 가벼운 서류 봉투 하나를 배달하기 위해 엄청난 연료비가 드는 대형 화물기를 띄워 놓고 '배달 성공'이라며 박수를 치는 것.

이것이 현재 수많은 엔터프라이즈 AI 프로젝트가 마주한 부끄러운 민낯이다.

맺음말 : 인프라 감시자에서 '효율과 유연성의 통제자'로

우리는 종종 AI 거버넌스라고 하면 '보안'이나 '프로그램 언어, 버전', '인프라 표준'만을 떠올린다. 하지만 AX 리더가 버려야할 할 진짜 문제는 '낡은 아키텍처에 대한 미련'과 '비용을 무시한 무식한 프롬프팅'이다.

최고의 AI 아키텍처는 가장 단단한 시스템이 아니다. 내일 당장 S2S가 완벽해졌을 때 기존 STT 모듈을 미련 없이 버리고 스위치를 켤 수 있는 '가벼움'이다. 또한, 각 태스크의 난이도에 맞춰 무거운 모델과 가벼운 모델을 적재적소에 배치해 비용(FinOps)을 최적화하는 '치밀함'이다.

기술은 눈부시게 발전하지만, 그것을 다루는 방식은 여전히 사람의 몫으로 남아있다.

그라운드 위 화려한 기술의 궤적 속에서, 어떤 모델을 어떻게 태울 것인지, 어떤 파이프라인을 버리고 취할 것인지를 냉정하게 결정하는 것. 그것이 현시대 IT 조직 내 AX 리더들이 감당해야 할 가장 무겁고도 가치 있는 숙제일 것이다.