기업이 AI 도입 속도를 높여야 하는 것은 분명하다. 그러나 그것을 ‘무질서한 자유 경쟁’으로 만들지 않고 추진하는 방법은 명확하지 않다. 최고의 인재는 기업이 표준을 마련할 동안 기다리지 않는다. 이미 AI를 적극 활용하고 있다. 그렇다, 개발자는 기업이 어떤 정책을 세우든 상관없이 이미 챗GPT에 코드를 입력하고 있다. 최근 조사에 따르면, 개발자는 리더가 표준화를 추진하기도 전에 AI를 훨씬 빠르게 도입하고 있으며, 진짜 위험한 것은 이런 속도 차이가 아니라 리더십의 대응이 지연되는 것이다.

이 현상이 이른바 “AI 속도 격차(AI velocity gap)”다. 즉, AI를 활용해 앞서가려는 팀과 위험성을 이유로 시작조차 주저하는 경영진 사이의 간극이다. 익숙하게 들리는가? 과거 ‘섀도우 IT’와 똑같은 상황이다. 다만 이번에는 기업의 데이터가 그 연료로 사용된다.

필자는 기술 확산의 숨은 비용에 대해 여러 번 이야기해왔다. 관리되지 않은 자유로운 개발 환경이 통제 불가능한 인프라를 낳거나, 멀티클라우드의 유혹이 상호운용성 악몽과 비용 초과로 이어지는 사례가 대표적이다. 각 개발자와 팀이 각자 다른 클라우드, 데이터베이스, SaaS 도구를 선택하면, 혁신이 아니라 혼란이 생긴다.

지금의 현실은 그럴지 모르겠지만, 성공의 공식은 아니다. 그렇다면, 대안은 무엇일까?

‘공식 플랫폼’의 함정

플랫폼팀은 이런 혼란을 보면 본능적으로 ‘차단’을 시도한다. 공식적인 엔터프라이즈 AI 플랫폼이 완성될 때까지 아무도 앞으로 나아가지 말라는 것이다. 그리고 18개월 동안 솔루션 업체를 평가하고, 하나의 LLM에 표준을 맞추며, 일관되고 거대한 워크플로우를 설계한다.

하지만, 안타깝게도 ‘모두를 위한 단 하나의 진정한 플랫폼’이 출범한 즈음엔 이미 구식이 되어 있을 것이다. 지금의 AI 발전 속도를 보면, 도입되기도 전에 구시대의 산물이 될 위험이 있다. 기업이 표준으로 삼은 모델은 이미 다섯 번은 더 새롭고 더 저렴하며, 더 강력한 대안으로 대체될 것이다. 한편 기다리다 지친 개발자는 오래전부터 플랫폼을 우회할 것이며, 개인 신용카드로 최신 API를 결제해 쓰면서 기업의 심장부에 거대한 보안과 모니터링의 사각지대를 만들어버릴 것이다.

AI를 위한 하나의 커다란 ‘문’을 세우려는 시도는 실패할 수밖에 없다. 변화 속도가 너무 빠르고, 요구사항은 너무 다양하다. 법률 문서를 요약하는 데 뛰어난 모델은 파이썬 코드를 작성하는 데 끔찍하다. 마케팅 문구를 잘 작성하는 모델은 재무 예측에는 부적합하다. 심지어 엔지니어링 내에서도, 자바 코드를 리팩터링하는 데 탁월한 모델이 쿠버네티스 매니페스트를 작성하는 데는 전혀 쓸모없을 수 있다.

결국 문제는 ‘플랫폼을 갖고자 하는 욕망’이 아니라, ‘플랫폼을 어떻게 정의하느냐’에 있다.

규정된 플랫폼에서 조립형 제품으로

플랫폼 전문가 브라이언 로스는 최근 “황금 경로(golden paths)”에 대한 글에서 이 딜레마를 명확히 짚었다. 로스는 우리가 ‘게이트(gate)’가 아닌 ‘가드레일(guardrail)’로 사고를 전환해야 한다고 주장한다. 문제는 플랫폼팀이 종종 개발자가 진정으로 필요로 하는 것을 정확히 이해하지 못한다는 점이다.

로스는 분석은 다음과 같다.

“플랫폼팀은 대부분 ‘하나의 플랫폼’을 생각한다. 팀이 그것을 쓰거나 쓰지 않거나의 문제로 본다. 하지만 개발자는 당장 자신이 해결하려는 문제를 위해 필요한 ‘기능(capability)’ 단위로 생각한다.”

그렇다면 이 상충되는 관점을 어떻게 조율할까? 로스의 제안은 명확하다.

“플랫폼을 ‘제품’이라고 생각하라. 조립 가능한 구성요소를 제공하라. 플랫폼을 고정된 워크플로우가 아니라 API를 가진 제품처럼 다루는 것이 모듈형 도입의 핵심이다.”

문제의 원인과 해법

위원회를 소집해 어떤 모델을 쓸지 결정하도록 맡기기보다, 플랫폼팀은 개발자의 속도를 방향성 있게 이끌 수 있는 서비스나 조립 가능한 API 세트를 구축해야 한다. 실제로 이는 실질적인 인터페이스 표준을 마련하는 것에서 시작된다.

대표적인 예가 바로 오픈AI 스타일의 API이다. 단일 솔루션 업체를 공식 업체로 승인하라는 뜻이 아니다. 모든 팀이 공통된 계약을 기반으로, API 게이트웨이를 통해 서로 다른 엔진을 손쉽게 교체할 수 있도록 하는 것이다.

API 게이트웨이는 구조화된 출력 형식을 강제하는 최적의 지점이기도 하다. “그냥 텍스트를 반환해줘”는 데모용으로는 괜찮지만, 실제 프로덕션 환경에서는 통하지 않는다. 지속 가능한 통합을 원한다면, 스키마로 강제되는 JSON 기반 출력을 표준으로 삼아야 한다. 현대적인 기술 스택은 대부분 이를 지원하며, 이것이 바로 ‘귀여운 데모’와 ‘실제 운영 가능한 시스템’을 가르는 핵심 차이다.

API 게이트웨이는 동시에 관찰성과 비용 관리의 제어판 역할을 한다. 새로운 “AI 로그”를 발명할 필요는 없다. 대신 새롭게 부상하는 오픈텔레메트리(OpenTelemetry)의 생성형 AI 시맨틱 컨벤션 같은 기술을 사용하자. 이를 통해 프롬프트, 모델 ID, 토큰 사용량, 지연 시간, 비용 등을 이미 SRE 엔지니어가 사용하는 도구로 추적할 수 있다. 이 가시성이야말로 효과적인 비용 가드레일이 될 것이다.

이 모든 것의 근본은 데이터 접근 거버넌스다. 단호함이 필요한 영역으로, ID와 기밀을 이미 안전하게 관리하고 있는 기존 체계에 그대로 둬야 한다. 내장 키를 사용하지 않고 런타임 기밀 조회를 요구하고 인증은 기업 IAM으로 통일해야 한다. 목표는 새로운 공격면을 최소화하면서 AI를 이미 단단히 구축된 보안 패턴 안으로 흡수하는 것이다.

마지막으로, “황금 경로(golden path)”를 벗어날 수도 있도록 허용하되, 그에 따른 의무를 부과해야 한다. 예를 들어, 추가 로그 기록, 보안 검토, 더 엄격한 예산 제한 등이다. 로스의 제안처럼, 플랫폼 내에 기존 원칙을 지키지 않아도 되는 “정당성 있는 진행” 플래그 같은 것을 만드는 것이다. 이런 예외를 모두 기록하고 주간 단위로 검토하며, 이 데이터를 가드레일을 진화시키는 데 활용한다.

‘감시자’가 아닌 ‘제품’으로서의 플랫폼

그렇다면 왜 ‘게이트(gate)’ 대신 ‘가드레일’ 방식이 AI에 그렇게 잘 맞을까? 그 이유는 명확하다. AI는 끊임없이 움직이는 목표물이기 때문이다. 중앙화된 예측과 통제는 실패할 수밖에 없다. 위원회는 아직 이해하지 못한 것을 승인할 수 없고, 솔루션 업체는 표준 문서를 완성하기도 전에 방향을 바꿔버릴 것이다. 반면, 가드레일은 ‘하면서 배우는 학습’을 가능하게 한다. 이는 이미 클라우드 도입 과정에서 많은 기업이 배운 교훈이다. “생산적인 제약이 환상의 통제보다 낫다.”

필자가 주장했듯이, 선택지를 신중히 제한하는 것은 개발자가 각기 다른 방향으로 달린 뒤 그 격차를 메우는 접착 코드에 시간을 낭비하지 않고, 오히려 혁신에 집중하도록 돕는다. AI에서는 그 효과가 두 배로 크다. 모델 선택, 프롬프트 관리, 검색·조회 패턴, 비용 제어 등에서 발생하는 인지 부하가 크기 때문이다. 플랫폼팀의 역할은 바로 이 부담을 낮추는 데 있다.

‘황금 경로’는 가장 뛰어난 개발자의 속도에 맞춰 움직이면서, 기업을 예기치 못한 위험으로부터 보호하는 방법이다. 무엇보다 이 접근법은 기업의 현재 수준에 맞춘다. 이미 AI를 실험 중인 개발자에게는 안전하고 빠른 진입로를 제공하되, 검문소처럼 느껴지지 않는다. 플랫폼팀은 필요한 컴플라이언스, 가시성, 비용 통제를 확보하면서도 프로세스에 갇히지 않는다. 그리고 리더십은 지금 모든 기업이 절실히 원하는 것, 바로 “수천 개의 흩어진 실험을 하나의 일관되고 측정 가능하며, 통제 가능한 프로그램으로 전환할 수 있는 방법”을 얻을 수 있다.
dl-itworldkorea@foundryco.com