Embabel: 왜 JVM 생태계에서의 Agent 플랫폼이 필요한가?

bebeis·2025년 11월 25일

Embabel로 개발해보기 전에, Embabel과 같은 Agent 프레임워크가 왜 필요하고, 왜 Embabel을 사용해야 하는지 알아보자.

Embabel Founder인 로드 존슨님의 Medium 게시글을 참고하여 조금 더 이해하기 쉽게 풀어봤다.
Embabel: A New Agent Platform For the JVM

Agent 프레임워크가 필요한 이유

AI Agent는 여러 종류가 있다. 최근 가장 많이 사용되는 ReAct 에이전트를 생각해보자.

에이전트는 스스로 생각하여 행동 계획을 세우고, 도구에 입력을 제공하고 도구를 사용하고 결과를 검토한다. 이 과정을 반복하고 최종적으로 user에게 output을 전달한다.

이렇게만 보면 “그냥 LLM에게 잘 프롬프트 쓰고, MCP 도구 몇 개 묶어주면 되는 것 아닌가?” 라는 생각이 들 수 있다. 작은 데모 수준에서는 맞는 말이다. 하지만 실제 서비스나 비즈니스 애플리케이션을 만들기 시작하면 곧 한계에 부딪힌다.

가장 큰 문제는 모든 의사결정과 흐름이 LLM 안쪽의 프롬프트에 뭉쳐 있다는 것이다.

왜 특정 도구를 골랐는지,
왜 이 순서로 실행했는지,
실패했을 때 어떤 기준으로 재시도했는지
⠀를 코드나 로그에서 명확히 추적하기 어렵다. 디버깅도 “프롬프트 수정”으로 귀결되고, 팀 단위로 관리·리뷰하기도 애매해진다.

또 하나의 문제는 도구 수가 늘어날수록 조합이 폭발한다는 점이다. ReAct 루프 안에서 “이 상황에서는 어떤 도구를 선택할지”를 전부 LLM의 암묵적 판단에 맡기면,

비슷한 기능의 도구가 여러 개 있을 때 헷갈리고
새 도구를 추가할 때마다 프롬프트를 갈아엎어야 하며
특정 단계에선 반드시 지켜야 할 가드레일(권한, 안전성 검증 등)을 끼워 넣기 어렵다.

로드 존슨은 비즈니스 Application에서 Agent를 개발할 때 중요한 요소들을 다음과 같이 정의했다.

설명 가능성: 문제 해결 과정에서 왜 특정 선택들이 이루어졌는가?

발견성: MCP는 이 중요한 문제를 외면한다. 각 지점에서 올바른 도구를 어떻게 찾을 것이며, 모델들이 그것들 사이에서 선택할 때 혼동되지 않도록 어떻게 보장할 것인가?

모델 혼합 능력: 우리가 '신 모델(God Model)'에 의존하지 않고, 많은 작업에 로컬, 저렴한, 프라이빗 모델을 사용할 수 있도록 해야 한다.

흐름의 어느 지점에든 안전장치를 넣을 수 있는 능력: 안전성과 제어를 확보할 수 있다.

에이전트가 엉뚱한 행동을 하지 않도록 중간중간 검증하고 차단시킨다.

흐름 실행을 안정적으로 관리하고, 문제가 생겨도 다시 일어설 수 있는 복원력: 더욱 견고한 시스템을 구축할 수 있다.

규모에서의 흐름 조합성: 곧 우리는 단일 시스템에서 실행되는 에이전트뿐만 아니라 에이전트 여러 개를 함께 사용한다.

데이터베이스와 같은 민감한 기존 시스템과 더 안전한 통합: 최고의 LLM이라도 쓰기 권한을 주는 것이 위험한 경우가 있다.

Python 생태계가 아닌 JVM에서 Agent 플랫폼

이미 Python은 TensorFlow, PyTorch 및 많은 다른 라이브러리와 함께 광범위한 AI를 위한 생태계가 구축되어 있다. 하지만 왜 JVM 생태계의 Agent 플랫폼을 사용해야 할까?

비즈니스 Application 구축과 통합

우리가 ChatGPT의 Agent를 이용하여 업무를 한다고 생각해보자.
우리는 단순히 HTTP를 이용하여 ChatGPT에 접속한다. 하지만, 우리가 AI를 통해 하는 작업은 단순 HTTP 요청-응답 수준의 낮은 작업을 수행하지 않는다. 중요한 비즈니스 업무를 수행한다.

LLM으로 비즈니스 앱을 구축하기 위한 중요한 것은 기존 비즈니스 로직과 인프라이다.
예를 들어, 쇼핑몰에서 대신 쇼핑을 해주는 에이전트를 생각해보자. 에이전트를 잘 만드는 것도 중요하지만, 핵심은 기존 쇼핑몰의 비즈니스 로직, 인프라이다. 그 위에 정교한 에이전트를 통합시켜야 한다는 것이다.

JVM에서 Agent

JVM 진영은 엔터프라이즈 Application을 위한 훌륭한 생태계를 갖추고 있고, 정교한 Application을 개발하는 데에도 강점을 가지고 있다. 또한 많은 비즈니스 로직은 JVM 위에서 서비스되고 있다.

이런 부분에서 JVM에서 Agent를 개발하면
1. 기존 비즈니스 로직/인프라와 통합
2. 정교한 에에전트 개발
두 가지를 모두 챙길 수 있다.

예시) 쇼핑몰 에이전트 개발 - 비즈니스 로직/인프라와의 통합
우리 쇼핑몰 서비스는 자바-Spring 기반의 JVM 생태계에서 서비스되고 있고, 쇼핑몰 에이전트를 개발해야 하는 상황을 가정해보자.
JVM에서 에이전트를 개발하는 것과 Python으로 에이전트를 개발하는 것을 생각해보자.

우리 서비스의 핵심 도메인 객체와 규칙은 이미 JVM 코드 안에 잘 정리되어 있는데, Python 기반 에이전트는 문자열 기반의 입·출력 위에서 따로 놀게 된다. 도메인 모델을 진짜 타입으로 재사용하기보다는, LLM에게 자연어로 다시 설명해 주고 파싱하는 식으로 우회하게 된다.

JVM Agent를 사용하면 자연스럽게 핵심 도메인 모델과 통합되어 안정적인 에이전트 구축이 가능해진다.

정교한 에이전트 개발
Kotlin 데이터 클래스 또는 Java 레코드를 이용하여 Agent를 개발하면 다음과 같은 이점을 얻을 수 잇다.

프롬프트가 Type-safety함
- 도메인 모델이 실제 타입으로 존재하므로, 프롬프트를 “코드처럼” 다룰 수 있게 된다. LLM이 생성해야 하는 출력의 스키마가 명확하고 프롬프트 수정 없이도 리팩토링을 견딜 수 있다.
도구로 사용 가능함
- 도메인 객체 자체가 Tool이 될 수 있다. 객체의 메서드, 서비스 계층의 기능 등을 그대로 “에이전트가 사용할 수 있는 도구”로 노출할 수 있다.
```
data class Product(val id: Long, val price: Money) {
  fun isDiscountable(): Boolean = price.value > 10000
}
```
- 이런 메서드는 LLM이 직접 호출하는 도구(Action) 로 자동 노출될 수 있다.
- 에이전트는 “문자열 기반 추론”이 아니라 실제 비즈니스 규칙을 코드로 실행하며 의사결정을 내린다.

그렇다면 Embabel은?

Embabel은 JVM을 위한 에이전트 프레임워크이다. 즉, 위에서 말한 JVM에서 Agent 개발의 장점을 흡수한다.
또한, 기존 Python 에이전트 프레임워크와 구분되는 다른 특징을 갖는다.

계획 단계의 도입

Embabel의 큰 특징 중 하나는 “LLM에게 모든 판단을 맡기지 않는다”는 점이다.
계획 수립 단계에서 GOAP(Goal-Oriented Action Planning) 같은 비LLM 알고리즘을 사용하면

어떤 목표를 달성하기 위해 어떤 액션이 필요한지
지금 상태에서 실행 가능한 액션은 무엇인지
어떤 순서로 실행해야 가장 효율적인지
등을 결정론적으로, 설명 가능하게 만들 수 있다.

또한, 확장성을 챙길 수 있다.
예를 들어 서울에서 제주도를 가는 방법을 찾아주는 Agent를 개발해본다고 생각해보자.

만약 언젠가 해저 터널이 생겨서 자동차만으로도 제주도에 갈 수 있게 된다면, 기존 State Machine을 모두 다시 설계할 필요가 없다. 단지 “자동차로 갈 수 있다”는 새로운 액션 하나만 추가하면 된다. GOAP는 가능한 행동들 사이에서 자동으로 최적 경로를 다시 계산해 주기 때문에, 시스템 전체를 갈아엎지 않고도 에이전트의 능력을 자연스럽게 확장할 수 있다.