서론

모든 기업이 AI 개발 지식(Knowledge)을 축적하여 수평 전개(Horizontal Expansion)하려고 노력하고 있다.

하지만 잘 되고 있는 조직의 이야기는 그리 많이 들리지 않는다.

McKinsey의 2025년 Global Survey에 따르면, 88%의 조직이 최소한 한 가지 업무 영역에서 AI를 정기적으로 활용하고 있다[1].

그러나 기업 전체에서 AI 프로그램을 스케일(Scale)하기 시작한 곳은 약 3분의 1에 불과하다.

또 다른 McKinsey 조사에서는, 생성형 AI(Generative AI)의 롤아웃(Rollout)이 「성숙」 단계에 있다고 답한 C-level 리더는 1%에 불과했다[2].

실행의 문제처럼 보일 수도 있다. 하지만 그 실행을 어렵게 만드는 구조가 존재한다.

한 프로젝트에서 성공하더라도 수평 전개를 할 수 없는 것은, 재현 가능한 실행을 방해하는 구조적인 이유가 있기 때문이라고 생각한다.

그 이유를 Java 시대의 패턴과 대조하여 생각해 보고자 한다.

Java 태동기의 독자 프레임워크를 되돌아보며

2000년대, 많은 SIer가 J2EE를 기반으로 독자 프레임워크를 구축했다.

EJB는 「표준적인 방법으로 코드를 작성하면 횡단 관심사(Cross-cutting Concerns)가 자동으로 처리된다」는 약속으로 보급되었지만[3], 결국은 무거운 설정과 유지보수 비용에 무너졌다.

실패의 본질은 세 가지라고 생각한다.

불확실성이 높은 시기에, 「안정적인 추상화(Abstraction)」를 먼저 결정해 버렸다.

기술이 빠르게 움직이는 시기에 사내 독자적인 추상화 레이어(Abstraction Layer)를 고정하면, 외부의 OSS(Open Source Software)나 클라우드 서비스의 진화에 뒤처지게 된다.

현장에 강요된 포장된 도로가 되었다.

현장마다 제약 사항은 다른데 「이것을 사용하라」고 강요받으면, 현장 고유의 과제를 해결하기보다 프레임워크에 맞추는 작업이 늘어난다.

유지보수 비용을 자사에서만 부담하게 되었다.

OSS라면 시장 전체에서 유지보수되지만, 사내 프레임워크는 유지보수 비용을 자사만이 짊어진다.

개발한 사람은 다음 프로젝트로 떠나고, 사용자만 남게 된다.

AI에서도 동일한 패턴이 시작되고 있다.

독자적인 LLM 래퍼(Wrapper) 프레임워크, 전 프로젝트 공통 프롬프트 집합, 범용 RAG 템플릿이 「AI 공통 기반」으로서 정비되고 있다.

다만, AI는 Java보다 어려운 점이 있다.

Java 시절에는 「Spring에 걸면 된다」로 끝날 수 있었다. OSS가 안정적이었기 때문이다.

지금은 LangChain 하나만 보더라도 파괴적인 변경(Breaking Changes)이 빈번하게 일어난다.

「독자적인 것을 피하라」는 교훈은, OSS인지 독자적인 것인지를 불문하고 빠르게 움직이는 계층과의 결합을 최소화하라로 업데이트되어야 한다고 생각한다.

수평 전개가 어려운 3가지 구조적 이유

정교화하려고 하면, 서비스가 등장한다

평가 기반을 사내에서 직접 만들려고 하면, LangSmith, Langfuse, Braintrust 등이 그 기능을 서비스로서 제공한다.

RAG 파이프라인을 범용 템플릿으로 묶으려고 하면, 클라우드 벤더의 AI 서비스가 그것을 통째로 제공하기 시작한다.

「정교화하려고 했던 것이 서비스로 등장한다」는 현상은, 유용한 나침반이기도 하다.

벤더가 만들 법한 것을 만들려고 하고 있을 때, 그 계층은 이미 차별화 요소가 되지 않는다.

현장의 제약이 너무 제각각이다

Copilot만 사용할 수 있는 현장, 사내 LLM만 사용 가능한 현장, 에이전트(Agent) 사용이 금지된 현장, 외부 API가 완전히 금지된 현장이 동시에 존재한다.

이런 상황에서 「전 프로젝트 공통 AI 모듈」을 만들면 파탄 날 수 있다.

제약이 다르면 필요한 아키텍처 컴포넌트(Architecture Component)가 근본적으로 바뀌기 때문에, 공통화할 수 있는 부분이 거의 남지 않는다.

패키지화하기 쉬운 것일수록, 차별화가 되지 않는다

코드, 프레임워크, 프롬프트 집합처럼 리포지토리(Repository)에 둘 수 있고, 경영진에게 보여줄 수 있으며, 사람이 퇴사해도 남는 「시각화할 수 있는 자산」일수록, 벤더나 OSS가 가장 빠르게 흡수하는 계층에 위치한다.

Wardley Mapping으로 말하자면, 이것들은 코모디티화(Commoditization)가 빠른 범용 영역에 위치한다[4].

예를 들어, 프로젝트마다 AI 에이전트의 Skills나 하네스(Harness)를 처음부터 구축하고 있는 현장은 적지 않다.

이를 사내에서 수평 전개할 수 있다면 구축 부담이 줄어들고 경쟁력이 될 것이라는 발상은 자연스럽다.

하지만 이러한 베스트 프랙티스(Best Practice)는 시간이 흐름에 따라 GitHub의 리포지토리, 블로그 기사, 공식 문서로 흘러 들어간다.

굳이 사내에서 만들지 않아도 외부에서 가져오면 된다.

차별화가 되지 않는다.

반대로, 정말로 차별화에 유효한 자산, 즉 도메인 지식(Domain Knowledge), 평가의 안목, 고객 고유의 맥락에 대한 이해, 프로젝트를 어떻게 분해할 것인가에 대한 판단은 암묵적이고 맥락 의존적이어서 모듈화(Modularization)에 적합하지 않다.

패키지화하기 쉬운 것일수록 차별화가 되지 않고, 차별화로 이어지는 것일수록 패키지화에 저항한다.

기업들이 자꾸만 「가시화할 수 있는 것」에 손을 뻗고, 그 결과 그것들이 진부화되는 과정을 반복하는 이유가 바로 여기에 있다.

SIer는 도메인 데이터를 수평 전개할 수 없다

「평가와 도메인 데이터가 내구 자산(Durable Asset)」이라는 답은 옳다고 생각한다.

다만 SIer라는 맥락에서는 절반은 무너진다.

업무 데이터나 라벨의 대부분은 고객에게 귀속된다.

비밀 유지 의무와 계약의 제약으로 인해, 프로젝트를 넘나들며 자사 자산으로 가져올 수 없다.

그렇다면 SIer에게 정말로 수평 전개할 수 있는 자산은, 축적된 데이터 그 자체가 아니라, 고객 고유의 정답을 빠르게 이끌어내고, 평가를 구성하며, 딜리버리(Delivery)를 구축하는 프로세스라고 생각한다.

강점은 「무엇을 축적했는가」가 아니라 「얼마나 빠르게 구축할 수 있는가」에 두어야 하지 않을까.

무엇을 수평 전개해야 하는가

먼저, 만들지 말아야 할 것을 정리한다.

만들지 말아야 할 것

독자적인 LLM 래퍼 프레임워크 (LLM Wrapper Framework)

각 LLM이나 에이전트 기반의 변화가 빠르며, 얇은 래퍼(Wrapper)는 금방 두꺼워진다.

감사 로그·비용 관리·인증·이용 정책 적용을 위한 얇은 LLM 게이트웨이(Gateway)는 필요하겠지만, 업무 로직이나 에이전트 설계까지 떠안는 두꺼운 독자 프레임워크를 만드는 것이 문제다.

전 프로젝트 공통 프롬프트 모음

모델 차이·업무 차이·입력 데이터 차이로 인해 품질이 안정되지 않는다.

수평 전개해야 할 것은 프롬프트 본문이 아니라, 프롬프트를 평가하고 개선하는 관점이다.

범용 RAG 템플릿

RAG의 본질은 검색 대상·평가 데이터·권한 제어·업무 맥락에 있으며, 코드만 배포해서는 현장에 뿌리내릴 수 없다.

전 프로젝트용 범용 에이전트 기반

OSS(Open Source Software)나 클라우드 서비스의 진화를 따라가지 못해 금방 부채가 된다.

반면, 「이 에이전트의 어느 단계에서 무엇을 검증할 것인가」, 「이 업무에서 피드백 루프(Feedback Loop)를 어떻게 설계할 것인가」와 같은 맥락 고유의 판단은 별개다. 그것은 후술할 평가 스타터 키트나 제약별 아키텍처의 내용이며, 내구 자산이 될 수 있다.

「AI 개발 표준」이라는 거대한 문서

읽히지 않고, 업데이트되지 않으며, 현장에서 사용할 수 없다.

그렇다면 무엇을 만들어야 하는가.

만들어야 할 것

Team Topologies의 Thinnest Viable Platform (TVP)는 「필요 이상으로 두껍게 만들지 마라, 경우에 따라서는 Wiki 페이지 한 장이라도 플랫폼이 될 수 있다」는 사고방식이다 [5].

Martin Fowler의 「paved road」와도 맥락이 비슷하며, 플랫폼은 강제하는 것이 아니라 쓰고 싶게 만들어야 한다는 원칙이 있다 [6].

전반부에서 살펴본 문제(변화의 속도, 제약의 다양성, 패키지화하기 쉬운 것은 차별화가 되지 않음)를 고려하면, 수평 전개에 적합한 것의 윤곽이 보인다.

제약별 레퍼런스 아키텍처 (Reference Architecture)

「Copilot만 사용 가능」, 「사내 LLM만 사용 가능」, 「에이전트 금지」, 「외부 API 금지」 등의 제약 프로파일을 타입(Type)으로서 설계한다.

제약을 예외로 취급하지 않고 처음부터 설계 대상으로 삼음으로써, 현장마다 발생하는 「우리 프로젝트는 특수해서...」라는 상황을 줄일 수 있다.

평가 스타터 키트 (Evaluation Starter Kit)

수평 전개해야 할 것은 평가 데이터의 내용이 아니라, 「정답의 정의 방법과 평가 루브릭(Rubric)의 타입」이다.

평가 데이터의 내용은 고객에게 귀속되지만, 평가를 구성하는 방법은 자사 자산으로 만들 수 있다.

「이 업무에서 무엇이 정답이며, 어떤 오류가 치명적인가」를 고객으로부터 이끌어내는 인터뷰 타입, 루브릭 설계(정확도·완결성·포맷 적합성을 어떤 축과 몇 단계로 측정할 것인가), 모델을 변경했을 때 무엇을 비교할 것인가에 대한 관점 등이다.

데이터는 프로젝트마다 바뀌더라도, 이 타입은 수평 전개할 수 있다.

이것이 없으면 AI 프로젝트는 「어찌어찌 돌아가긴 한다」 수준에서 멈춘다.

AI 리스크 체크리스트

데이터 반출 판정, 할루시네이션(Hallucination) 대응, 인간 승인 필요 여부, 로그 저장 의무 등 법무·보안·개인정보 관련 판단을 매번 제로 베이스에서 논의하지 않도록 하는 타입을 갖춘다.

사내 Technology Radar

Thoughtworks가 AI·기술 선정의 지침으로 공개하고 있는 리포트로, 기술을 「사용해도 좋음 / 시도해 봐도 좋음 / 관망 / 사용 금지」의 4단계로 분류하여 반년마다 업데이트하고 있다 [7].

이를 사내 버전으로 만드는 것이다.

포인트는 「폐지 리스트」이다. AI 영역에서는 반년 전의 권장 구성이 지금은 비권장 사항이 되는 일이 흔하다.

「이 RAG 구성은 이제 사용하지 않는다」, 「이 OSS 에이전트 FW는 프로젝트 적용 금지」를 조직으로서 명시하는 메커니즘이 없으면, 각 프로젝트는 오래된 지식에 머문 채 계속 진행된다.

지식(Knowledge)은 늘리는 것보다, 진부화된 것을 지우는 메커니즘이 더 가치가 높다고 생각한다.

InnerSource 접근 방식

InnerSource란 OSS(Open Source Software)의 개발 스타일(누구나 PR(Pull Request)을 제출할 수 있고, 리뷰하여 반영하는 방식)을 사내에 적용하는 사고방식이다[8].

중앙의 CoE(Center of Excellence)가 일방통행식으로 가이드라인만 배포한다면 현장은 이를 사용하지 않을 것이며, 현장의 지식(Knowledge)이 환류되지도 않을 것이다.

현장 팀이 "이 패턴을 수평 전개하고 싶다"는 의사를 PR로 제출할 수 있는 양방향 메커니즘을 구축하고, 중앙은 이를 프로덕트(Product)로서 관리해야 한다.

코드를 배포하는 것이 아니라, OSS처럼 육성하는 것이다.

KPI를 바꾸기

DORA의 2025년 리포트는 AI를 "증폭 장치"로 정의하고 있다[9].

플랫폼의 품질이 낮으면 AI의 효과는 거의 제로에 가깝지만, 품질이 높을 때에만 강력한 양(+)의 방향으로 작용한다.

즉, AI 프로젝트의 성패는 도구의 풍부함이 아니라 프로젝트를 뒷받침하는 메커니즘의 질에 의해 결정된다.

그렇다면 KPI(핵심 성과 지표)도 바뀌어야 한다.

"몇 개의 프로젝트에서 사용되었는가"를 기준으로 삼으면, Java 독자 프레임워크의 재림이 될 것이다.

사용하게 만드는 것 자체가 목적이 되어버리기 때문이다.

나쁜 KPI	좋은 KPI
공통 모듈 이용 프로젝트 수	신규 프로젝트 런칭 기간 단축
...
측정해야 할 것은, 모델이나 도구가 바뀌었을 때 얼마나 빠르고 안전하게 전환할 수 있는가이다.

그것이 기업의 AI 역량이 될 수 있다.

부품이 아닌, 메커니즘을 수평 전개하기

AI 개발의 경쟁력을 스톡(Stock)형으로 생각하면 실패한다.

코드나 프레임워크가 쌓여 있으면 강하다는 발상은, Java 독자 프레임워크와 동일한 함정을 초래한다.

Java 독자 프레임워크의 실패를 반복하지 않으려면, 만들지 말아야 할 것을 만들지 않겠다는 판단이 필요하다고 생각한다.

"AI의 부품을 공통화하는 것"이 아니라, "실행을 재현 가능하게 만드는 구조를 공통화하는 것"이다.

수평 전개해야 할 것은 코드가 아니라 타입(Type)이며, 도구가 아니라 판단의 프레임워크(Framework)다.

쌓아 올리는 것이 아니라, 빠르게 교체할 수 있는 구조에 투자하는 것이 변화가 빠른 AI 영역에서는 지속적으로 유효하지 않을까 생각한다.

---

• EJB 1.0 사양은 Sun Microsystems가 1998년에 발표(IBM 등 여러 벤더가 사양 책정에 참여). 프레임워크와 컴포넌트의 밀결합(Tight Coupling)과 방대한 설정이 문제가 되었으며, Rod Johnson이 EJB를 사용하지 않는 J2EE 개발에 관한 저서(2002년)를 발표하였고, 이것이 Spring(2003년)의 초석이 되었다. ↩︎

• Wardley Mapping은 Simon Wardley가 제창하는 비즈니스 전략 시각화 기법. 활동이나 기술을 "태동기 ~ 코모디티(Commodity)"의 진화 축으로 정리하여, 차별화해야 할 영역과 범용화해야 할 영역을 명확히 한다. ↩︎

• What is a Thinnest Viable Platform (TVP)? — Team Topologies ↩︎

• What I Talk About When I Talk About Platforms | Martin Fowler ↩︎

Discussion