지난 20년 동안 엔터프라이즈 Java를 작성해 왔다면, Rod Johnson이라는 이름을 알고 있을 것입니다. 그는 2003년에 Spring Framework를 만들었습니다. 이는 Java의 의존성 주입 (Dependency Injection)이 XML과 씨름하는 것이 아니라 자연스럽게 느껴지도록 만든 것입니다. Spring은 기본적으로 엔터프라이즈 Java가 작동하는 방식을 다시 썼습니다.

Johnson은 수년 전 Spring의 활발한 개발에서 물러났습니다. 하지만 2026년 초, 그는 돌아왔습니다. 그리고 그는 또 다른 IoC 컨테이너를 만들기 위해 돌아온 것이 아니었습니다.

그는 Embabel을 만들었습니다. JVM을 위한 AI 에이전트 (AI agent) 프레임워크입니다. 그리고 이것은 Spring AI나 LangChain4j와는 전혀 다르게 작동합니다.

저는 몇 달 동안 제 개인 VPS에서 AI 에이전트들을 실행해 왔습니다. Hermes Agent, Claude Code, 커스텀 MCP 서버 등 모든 것을 다 다루었습니다. 그래서 Rod Johnson이 Java AI 프레임워크와 함께 돌아왔다는 소식을 들었을 때, 저는 주목했습니다. 제가 발견한 내용은 다음과 같습니다.

Spring AI와 LangChain4j는 훌륭하지만 - 다른 문제를 해결합니다

지난 1년 동안, AI 분야에 진입하는 대부분의 Java 개발자들은 두 가지 프레임워크로 기울었습니다:

• Spring AI - Spring 생태계에 LLM 통합을 가져옵니다.
• LangChain4j - LangChain의 에이전트/도구 (agent/tool) 패턴을 Java로 포팅한 것입니다.

두 가지 모두 각자의 역할에 탁월합니다. 몇 줄의 코드만으로 챗봇, RAG 파이프라인, 도구 호출 (tool-calling) 어시스턴트, 그리고 AI 기반 API를 구축할 수 있습니다.

하지만 두 프레임워크 모두 LLM을 애플리케이션의 중심으로 취급합니다. 프롬프트 (prompt)를 보내면, 모델이 응답합니다. 어쩌면 도구를 호출할 수도 있습니다. 그러고 나서 다시 응답합니다.

질의응답이나 채팅 인터페이스의 경우에는 괜찮습니다. 하지만 만약 시스템이 다음과 같은 동작을 수행하기를 원한다면 어떨까요:

• 어떤 행동을 취하기 전에 다단계 계획 (multi-step plan)을 수립
• 10초가 아니라 10분 동안 실행
• 자신의 작업을 확인하고 실패했을 경우 재시도
• 문제의 서로 다른 부분에서 작동하는 여러 에이전트를 조정

이 지점이 바로 챗봇 패턴이 무너지는 곳입니다. 그리고 이것이 바로 Embabel이 목표로 하는 지점입니다.

Embabel이란 무엇인가?

Embabel (em-BAY-bel로 발음)은 JVM 위에서 목표 지향적 (goal-oriented) AI 에이전트를 구축하기 위한 프레임워크입니다. 이 프레임워크는 Kotlin으로 작성되었으며 Java에서 자연스럽게 작동합니다. Embabel은 Spring AI 위에서 동작하며, Johnson은 그 관계를 "Spring AI가 Embabel에 대한 관계는 Servlet API와 Spring MVC의 관계와 같다"라고 설명했습니다 [source].

즉, Spring AI는 저수준의 LLM 배관 작업 (모델 연결, 프롬프트 템플릿, 출력 파서)을 제공합니다. Embabel은 에이전트 오케스트레이션 (agent orchestration) 레이어를 제공합니다.

핵심 혁신은 비디오 게임에서 빌려온 것입니다.

GOAP: 목표 지향적 행동 계획 (Goal-Oriented Action Planning)

만약 F.E.A.R. 또는 Killzone 같은 게임을 플레이해 보았다면, GOAP를 접해본 적이 있을 것입니다. 이는 각 행동이 다음과 같은 요소를 갖는 AI 기술입니다:

• 전제 조건 (Preconditions) - 행동이 실행되기 전에 반드시 참이어야 하는 사항들
• 효과 (Effects) - 행동 실행 후 세계 상태 (world state)가 어떻게 변하는지

플래너 (planner)는 어떤 행동 시퀀스가 목표로 이어지는지를 계산합니다. 이 계획은 결정론적 (deterministic) 입니다. 즉, 또 다른 LLM 호출에 의해 구동되지 않습니다. 이것이 중요한 이유는 에이전트가 왜 그런 행동을 했는지 정확하게 설명할 수 있음을 의미하기 때문입니다.

Embabel이 이를 모델링하는 방식은 다음과 같습니다:

• 에이전트 (Agent) - @Agent 어노테이션이 붙은 Spring Bean으로, 기능과 상태를 보유합니다.
• 행동 (Action) - @Action 어노테이션이 붙은 메서드로, 전제 조건과 효과를 가집니다.
• 목표 (Goal) - 에이전트가 달성하려는 것이며, @AchievesGoal 어노테이션이 붙습니다.
• 플래너 (Planner) - 행동들을 하나의 계획으로 체이닝(chaining)합니다. 각 행동이 완료된 후 다시 계획을 세웁니다 (re-plans).
• AI - 행동이 LLM 및 임베딩 모델 (embedding models)에 접근할 수 있도록 하는 인터페이스입니다.

모든 행동이 실행된 후, 시스템은 재평가합니다. 목표가 달성되었는지 확인합니다. 달성되지 않았다면, 다시 계획을 세웁니다. 이 루프는 목표가 달성되거나 시스템이 포기할 때까지 계속됩니다.

계획 수립 자체는 LLM 호출이 아닙니다. 이는 결정론적인 알고리즘입니다. 이를 통해 기업들이 매우 중요하게 생각하는 요소인 감사 가능성 (auditability)을 확보할 수 있습니다.

구체적인 예시

Dan Vega는 2026년 4월 Embabel에 대한 첫인상을 게시했습니다. 그는 블로그 작성 에이전트 (agent)를 구축했습니다. 타입 안정성 (type-safe)이 보장된 출력을 위해 두 개의 Java 레코드 (record)로 시작합니다:

public record BlogDraft(String title, String content) {}

public record ReviewedPost(String title, String content, String feedback) {}

그 다음 에이전트 (agent) 본체입니다:

@Agent(description = "Write and review a blog post")
public class BlogWriterAgent {

...

여기서 두 가지가 눈에 띕니다.

첫째, @AchievesGoal은 플래너 (planner)에게 이 액션 (action)을 완료하는 것이 목표가 달성되었음을 의미한다고 알려줍니다. 초안을 작성하는 것은 진행 과정입니다. 그것을 검토하고 다듬는 것이 완료입니다. 플래너 (planner)는 스스로 이 순서를 파악합니다.

둘째, withLlmByRole("reviewer")를 사용하면 서로 다른 작업에 서로 다른 모델 (model)을 할당할 수 있습니다. 초안 작성에는 빠르고 저렴한 모델 (gpt-4.1-mini)을 사용하세요. 검토에는 더 유능한 모델 (gpt-4.1)을 사용하세요. 이는 코드에 하드코딩되지 않고 application.yaml에서 구성됩니다.

당신은 단계별 워크플로 (workflow)를 정의하지 않습니다. 당신은 액션 (action)과 목표 (goal)를 정의합니다. 그러면 플래너 (planner)가 경로를 찾아냅니다.

비교 분석

Spring AI / LangChain4j:

• 주요 패턴 (Primary pattern) - 채팅 (Chat) / RAG / 도구 호출 (tool-calling)
• 오케스트레이션 (Orchestration) - 당신의 코드가 호출을 체이닝 (chaining)함
• 플래닝 (Planning) - LLM이 각 단계를 결정함
• 상태 관리 (State management) - 수동
• 실행 시간 (Run duration) - 초 단위
• 검증 (Validation) - 내장되어 있지 않음
• 감사 가능성 (Auditability) - 낮음 (LLM의 결정은 불투명함)
• 시작 비용 (Startup cost) - 낮음, 단순히 API를 호출함
• 성숙도 (Maturity) - 안정적 (v1.x)

Embabel:

• 주요 패턴 (Primary pattern) - 목표 지향적 에이전트 (Goal-oriented agents)
• 오케스트레이션 (Orchestration) - 내장된 GOAP 플래너 (planner)
• 플래닝 (Planning) - 결정론적 알고리즘 (Deterministic algorithm)
• 상태 관리 (State management) - 내장된 세션 컨텍스트 (session context)
• 실행 시간 (Run duration) - 분에서 시간 단위
• 검증 (Validation) - 플래너 (planner)가 목표 달성 여부를 확인함
• 감사 가능성 (Auditability) - 높음 (결정론적 계획 추적 가능)
• 시작 비용 (Startup cost) - 중간, 액션 (action)과 목표 (goal)를 정의해야 함
• 성숙도 (Maturity) - 초기 단계 (0.4.x-SNAPSHOT)

Spring AI 대신 Embabel을 선택하는 것이 아닙니다. Spring AI와 함께 Embabel을 사용하는 것입니다. Spring AI가 LLM 배관 (plumbing) 역할을 한다면, Embabel은 그 위의 오케스트레이션 계층 (orchestration layer)입니다.

릴리스 타임라인 (The Release Timeline)

Embabel은 2025년 6월 InfoQ를 통해 처음 발표되었습니다. Johnson은 2026년 4월 Microsoft JDConf에서 이를 공개적으로 소개했습니다. 그 이후로 매주 패치가 릴리스되고 있습니다.

이 프로젝트는 Apache 2.0 라이선스를 따르며 GitHub에서 이용 가능합니다.

현재 상태: 얼리 액세스 (early access). Dan Vega가 처음 살펴봤을 당시의 버전은 0.4.0-SNAPSHOT이었습니다. 아직 Spring AI 2.0이나 Spring Boot 4를 지원하지 않으며, Spring Boot 3.5.x와 Spring AI 1.1.4가 필요합니다. 하지만 릴리스 속도는 매우 빨랐습니다. 2026년 초까지 매주 패치가 이루어졌습니다.

시작하기 (Getting Started)

공식 리소스는 부족하지만 점차 늘어나고 있습니다:

• GitHub: github.com/embabel/embabel-agent
• Examples: github.com/embabel/awesome-embabel
• Baeldung 가이드: "Creating an AI Agent in Java Using Embabel Agent Framework" (2025년 8월)

Spring Boot 3.5.x, Java 23, 그리고 사용 중인 LLM 제공업체(OpenAI, Anthropic, Gemini 등 Spring AI가 지원하는 것)의 API 키가 필요합니다. Embabel은 현재 SNAPSHOT으로 배포되고 있으므로, pom.xml에 Spring snapshot 저장소를 추가해야 합니다.

나의 견해 (My Take)

저는 운영 환경에서 Spring Boot 애플리케이션을 실행하고, 개인적인 AI 인프라로 Hermes Agent를 사용합니다. 따라서 저는 이러한 종류의 프레임워크를 위한 정확한 타겟 오디언스 (target audience)입니다.

제가 마음에 드는 점은 바로 **결정론 (determinism)**입니다. GOAP 플래너 (planner)는 감사 가능한 추적 (auditable trace)을 생성합니다. 엔터프라이즈 환경에서는 이것이 매우 중요합니다. AI 에이전트가 잘못된 동작을 했을 때, 그 이유를 알아야 하기 때문입니다. 일반적인 LLM 체인 (chains)의 경우, 답변은 대개 "모델이 그렇게 결정했다"입니다. 하지만 Embabel의 경우, 답변은 "플래너가 전제 조건 (preconditions) Y가 충족되었기 때문에 액션 (action) X를 선택했다"가 됩니다. 이것은 실질적인 차이입니다.

제가 잠시 멈춰 서서 생각하게 만드는 지점은 바로 성숙도 (maturity) 입니다. 스냅샷 저장소 의존성 (snapshot repository dependency)을 사용하는 0.4.x-SNAPSHOT 버전인 만큼, 이것은 당장 내일 프로덕션 (production) 환경에 배포할 수 있는 단계가 아닙니다. 커뮤니티 예제도 여전히 부족하며, 대부분 공식 샘플과 Dan Vega의 블로그 포스트가 전부입니다.

솔직히 말씀드리면, 저는 아직 Embabel로 무엇인가를 구축해 본 적은 없습니다. 이 내용은 문서를 읽고 Vega의 가이드 (walkthrough)를 바탕으로 작성되었습니다. 하지만 아키텍처 (architecture)를 보면 엔터프라이즈 소프트웨어 (enterprise software)에 대해 깊이 고민한 사람의 설계라는 느낌을 줍니다. 이는 놀라운 일이 아닙니다. Rod Johnson가 그렇게 해왔으니까요.

만약 그가 Spring에 쏟았던 것과 같은 에너지를 유지한다면, Embabel은 Java 팀들이 AI 에이전트 (AI agents)를 구축하는 표준적인 방식이 될 수 있습니다. 타이밍도 적절합니다. 제가 아는 모든 엔터프라이즈 Java 기업들은 기존의 투자 자산을 버리지 않으면서 어떻게 AI를 활용할 수 있을지 고민하고 있습니다. 타입 안정성 (type safety)과 감사 가능성 (auditability)을 존중하는 JVM 네이티브 (JVM-native) 에이전트 프레임워크 (agent framework)는 바로 그들이 찾고 있는 것입니다.

만약 당신이 AI 분야를 곁눈질하며 자신이 어디에 속할지 고민하고 있는 Java 개발자라면, Embabel은 그 퍼즐이 맞춰지게 만드는 프레임워크가 될 수도 있습니다. 혹은 너무 이른 단계일 수도 있습니다. 여러분의 생각이 궁금합니다.