1. 어떤 AI 프레임워크를 선택할 것인가?
Spring AI vs LangChain4j
결론
에이전트를 서비스에 본격적으로 올릴 거라면, 초기 세팅이 조금 번거롭더라도 단일 API 직결보다는 AI 프레임워크를 활용하는 것이 장기적으로 이득이다.
기존 서비스가 Java/Spring 기반이고, 잦은 패키지 버전업에 따른 사이드 이펙트(전수 검증)를 감당할 여력이 없다면, Spring AI보다는 LangChain4j를 처음부터 검토하는 것을 권장한다.
어떤 AI 프레임워크를 선택할 것인가?
본격적으로 에이전트 제품을 만들어보기로 마음먹었다면, 가장 먼저 마주하는 고민이 있다. 바로 '이 에이전트를 우리 제품에 어떻게 연결할 것인가'다.
물론 이 부분은 백엔드 개발자가 시스템 아키텍처를 짜면서 주도적으로 고민하는 영역이다. 하지만 에이전트를 기획하는 프로덕트 매니저라고 해서 "그건 개발팀이 알아서 하겠지" 하고 넘길 수 있는 문제가 아니다.
기획자 역시 이 연결 구조를 바싹 밀착해서 파악하고 있어야 한다. 그래야 나중에 에이전트 구조를 통째로 뒤엎어야 할 때나, 응답 속도 같은 품질 지표를 끌어올려야 할 때 정확한 개선 포인트를 짚어내고 개발자와 소통할 수 있기 때문이다. 그리고 팀 규모가 크다면 동시 다발적으로 진행하는 프로젝트 속 리소스를 판단하는데 도움이 된다.
기술 구조를 모르면 기획의 한계도 모르게 된다.
그래서 이번 시리즈의 첫 번째 이야기로, 개발팀과 머리를 맞대고 어떤 프레임워크를 고를지 치열하게 고민했던 경험부터 먼저 풀어보려 한다.
단일 API의 한계와 프레임워크의 필요성
초기에는 구글 AI 스튜디오나 주요 모델의 API를 직접 호출하는 방식을 썼다. 단순히 이력서를 요약하거나 공고 문구를 다듬는 단발성 기능에는 이 방식이 최고다. 직관적이고, 해당 API 문서만 챙겨보면 되니까 유지보수도 단순하다.
단발성 기능을 기획하며 우리가 주로 검토하고 사용했던 대표적인 API들의 특징은 대략 이렇다.
LLM 대표 3인방 ©작가편집하지만 우리의 목표는 '에이전트'다. 에이전트가 상황에 맞춰 여러 도구를 선택하고 연속적인 작업을 수행하려면 복잡한 오케스트레이션이 필요하다. 이걸 단일 API 연결로 풀려다 보니, 모델 버전이 올라가거나 파라미터가 하나만 바뀌어도 일일이 대응하거나, 여러 프로바이더를 복합적으로 사용하기 힘들어졌다.
그래서 코드는 그대로 둔 채 껍데기만 갈아 끼울 수 있는 AI 프레임워크를 도입했다.
AI 프레임워크 도입, 이상과 현실의 충돌
만약 우리가 내부 백오피스 툴을 처음부터 새로 만드는 상황이었다면 고민 없이 파이썬 기반의 LangChain을 선택했을 것이다. AI 생태계는 파이썬이 지배하고 있고, 프레임워크의 안정성이나 레퍼런스도 압도적이기 때문이다.
하지만 현실은 다르다. 우리가 에이전트를 올려야 하는 기반은 이미 수많은 고객이 사용 중인 B2B SaaS 제품이었고, 우리 백엔드는 자바 코틀릿 Spring Boot 기반이었다. 자바 생태계 위에서 AI 에이전트를 띄우기 위해 우리는 세 가지 선택지를 두고 고민했다.
AI 프레임워크 대표 3인방 ©작가편집표를 보면 답이 명확해 보이지만, 실무에 적용해 보며 겪은 사정이 조금씩 다르다.
1. Spring AI
현재 우리 제품의 뼈대로 삼고 있는 프레임워크다. 자바/스프링에 익숙한 우리 개발팀 입장에서는 당장 코드를 짜고 붙이는 데 좋았다.
하지만 치명적인 문제가 두 가지 있었다. 첫째는 '구분자(Delimiter)' 이슈다. 프롬프트를 정교하게 짜다 보면 XML 태그 방식으로 꺾쇠(<>)를 자주 쓰게 되는데, 현재 버전 기준으로 Spring AI가 이 꺾쇠를 자신들의 내부 구분자로 삼아버리는 경우가 있다. 이걸 막으려면 프롬프트 내의 꺾쇠를 전부 이스케이프(\) 처리해야 하는데, 이 과정에서 토큰이 낭비되고 맥락이 오염되는 짜증 나는 상황이 발생한다.
둘째는 정말 '의존성' 문제가 짜증난다. 프레임워크 안정성을 위해 마이너 버전을 올리면, 여기에 물려있는 다른 Spring 패키지들의 버전까지 강제로 올려야 한다. 에이전트 하나 업데이트하자고 멀쩡히 돌아가던 기타 모듈이나 권한 설정 기능까지 회귀 테스트를 돌려야 하는, 전수검증 상황이 벌어지는 것이다. 게다가 Claude 같은 최신 모델 지원도 한 박자씩 늦다.
2. LangChain4j
파이썬 랭체인의 빠른 업데이트 속도와 다양한 툴 생태계를 자바 언어로 그대로 누릴 수 있다. 최신 모델이 나오면 거의 즉각적으로 반영해 준다. 다만 스프링 생태계의 작동 방식과는 다소 결이 다르다 보니, 기존 백엔드 개발자들이 새로운 구조를 익혀야 하는 러닝 커브가 존재한다.
3. Lanchain (Python 서버 분리)
에이전트만 전담하는 파이썬 서버를 따로 띄우고, 기존 스프링 서버와 API로 통신하는 투트랙 방식이다. 데이터 분석에 특화된 파이썬 라이브러리를 마음껏 쓸 수 있다는 건 축복이지만, 작은 스타트업이나 리소스가 빡빡한 팀에서는 코드 베이스를 두 벌이나 관리해야 한다는 게 부담이다.
그래서 지금 우리는?
앞서 말했듯 당장의 개발 속도를 위해 Spring AI로 고군분투 중이다. Spring AI는 LLM과의 기본적인 상호작용을 담당하는 인터페이스로 ChatModel이라는 핵심 컴포넌트 사용한다. 아래는 사이오닉 AI에서 정리한 플로우차트.
당장은 기존 제품의 안정화가 우선이라 Spring AI를 쓰고 있지만, 추후 에이전트 개발 경험이 팀 내에 충분히 쌓이면 아키텍처 전체를 LangChain4j 기반으로 마이그레이션 하는 방안도 진지하게 고려하고 있다. (그 전에 Spring AI가 안정화되면 좋겠다.)
ⓒ 2026. 327roy All rights reserved.