The modular AI tech stack: How to build for a world where models change every year

모듈러 AI 기술 스택은 LLM, 임베딩 모델, 벡터 DB, 오케스트레이션 레이어, 평가/관측 도구를 각각 독립적으로 교체 가능한 컴포넌트로 분리하는 아키텍처 패턴이다. 핵심 작동 원리는 추상화 레이어(LiteLLM, LangChain, Vercel AI SDK 등)를 통해 모델 호출 인터페이스를 표준화하고, 프롬프트·체인·툴 정의를 모델 종속성에서 분리하는 데 있다. 이를 통해 OpenAI GPT-5에서 Claude 4, Gemini 2.5로 모델을 교체하더라도 비즈니스 로직은 그대로 유지되며, 라우터 패턴으로 작업 유형별(요약은 Haiku, 추론은 Opus)로 다른 모델을 동적 라우팅할 수 있다. 매년 SOTA 모델이 바뀌는 현실에서 모놀리식 통합은 6~12개월마다 대규모 리팩토링을 강요하지만, 모듈러 구조는 모델 교체를 설정 변경 수준으로 축소시킨다.

개발자 관점에서 이는 "어떤 모델을 쓰느냐"보다 "어떻게 평가·교체할 수 있게 만드느냐"가 더 중요한 설계 결정이 됨을 의미한다. 단일 벤더 SDK에 직접 의존하는 코드는 단기적으로 빠르지만, 신규 모델 출시 시 회귀 테스트·프롬프트 튜닝·비용 재계산이 모두 코드베이스 전반에 흩어지게 된다. 반면 모듈러 스택은 초기 추상화 비용을 지불하는 대신, 평가 파이프라인(eval harness)에 새 모델만 꽂으면 정량적 비교가 가능하다. 또한 모델별 토큰 단가·레이턴시·컨텍스트 윈도우 차이가 매우 크기 때문에, 비용 최적화 측면에서도 워크로드별 모델 선택 자유도가 직접적인 ROI로 이어진다. 특히 사내 데이터로 RAG를 구축하는 경우, 임베딩 모델을 교체할 때 인덱스 전체를 재생성해야 하므로 벡터 DB와 임베딩 레이어를 분리해두는 설계가 필수적이다.

실무에서 취해야 할 행동은 명확하다. 첫째, 모델 호출은 반드시 얇은 어댑터 레이어 뒤에 두고, 프롬프트는 코드에 하드코딩하지 말고 버전 관리되는 별도 자산(파일 또는 프롬프트 레지스트리)으로 관리한다. 둘째, 골든 데이터셋 기반 자동 평가 파이프라인을 CI에 통합해 모델 교체 시 회귀를 정량적으로 감지할 수 있어야 한다. 셋째, LangSmith·Langfuse·Helicone 같은 관측 도구로 프롬프트·응답·비용·레이턴시를 로깅해 두면, 새 모델 도입 시 A/B 비교의 근거가 된다. 넷째, 한국 환경에서는 한국어 성능, 데이터 주권(국내 리전), Solar·HyperCLOVA X 같은 국산 모델 옵션까지 고려한 멀티 프로바이더 전략이 필요하며, 이는 처음부터 모듈러로 설계하지 않으면 사실상 불가능하다. 결론적으로 "모델은 일회용, 인프라는 영속적"이라는 관점으로 스택을 설계하는 것이 향후 2~3년 AI 엔지니어링의 핵심 역량이다.