목록으로
개발

Advisors를 이해하면 Spring AI 설계가 보인다

·4분 읽기
#Spring AI#Advisors#ChatClient#RAG#Java
Advisors를 이해하면 Spring AI 설계가 보인다

title: "Advisors를 이해하면 Spring AI 설계가 보인다" slug: "spring-ai-2-advisors" status: "draft" series: "Spring AI 2.0 읽는 순서" order: 6 description: "Spring AI 2.0의 Advisors API를 기준으로, 단순 모델 호출을 넘어서 메모리·RAG·관찰 가능성·평가를 어떻게 체인으로 구성하는지 설명하는 글." tags: ["Spring AI", "Advisors", "ChatClient", "RAG", "Java"] source_docs:

  • "downloads/spring-ai-reference-2.0-ko/api/advisors.html"
  • "downloads/spring-ai-reference-2.0-ko/api/advisors-recursive.html"
  • "downloads/spring-ai-reference-2.0-ko/api/chat-memory.html"

Spring AI를 처음 볼 때는 ChatClient가 중심처럼 보인다. 실제로 첫 호출은 거기서 시작하는 게 맞다.

그런데 문서를 조금 더 읽어 보면, Spring AI가 단순한 채팅 호출 래퍼로 끝나지 않는다는 사실이 분명해진다. 그 차이를 가장 잘 보여 주는 계층이 바로 Advisors다.

개인적으로는 이렇게 정리하는 편이 가장 이해가 쉽다.

ChatClient가 요청을 시작하는 곳이라면, Advisors는 그 요청이 어떤 파이프라인을 거치며 완성될지 결정하는 곳이다.

Advisors를 왜 따로 알아야 하나

LLM 앱은 금방 단순 호출을 벗어난다.

  • 대화 기록을 붙이고 싶다.
  • 검색 결과를 문맥에 섞고 싶다.
  • 실행 로그와 추적 정보를 남기고 싶다.
  • 응답 품질을 평가하고 싶다.
  • 어떤 단계에서는 재귀적으로 한 번 더 점검하고 싶다.

이걸 전부 서비스 코드에 직접 흩뿌리기 시작하면, 처음엔 빨라도 금방 읽기 어려운 코드가 된다.

Advisors는 바로 이 문제를 해결하려는 장치다. 요청 전후에 개입하는 공통 단계를 체인처럼 연결하게 해 준다.

즉 “모델 호출 전에 무엇을 준비할지, 호출 후 무엇을 보정할지”를 별도 계층으로 올려놓는 셈이다.

문서에서 보이는 핵심 개념

Spring AI Advisors API 클래스 구조
Advisor는 요청 전후에 끼어들 수 있는 확장 지점이라서 메모리, 검색, 관찰 가능성을 느슨하게 결합하기 좋다.

advisors.html 문서에서 먼저 잡아야 할 것은 구현 세부보다 역할이다.

  • Advisor는 요청/응답 흐름에 개입한다.
  • 여러 Advisor를 순서대로 조합할 수 있다.
  • 스트리밍과 비스트리밍에서 동작 방식 차이를 고려해야 한다.
  • 실행 순서가 품질과 동작에 실제 영향을 준다.

이 중에서도 특히 중요한 것은 순서다.

예를 들어,

  • 메모리를 먼저 붙일지
  • RAG 검색을 먼저 할지
  • 로깅/관찰 가능성을 어느 시점에 넣을지

에 따라 실제 프롬프트와 응답이 달라질 수 있다.

Spring AI가 단순 호출 래퍼가 아니라는 증거

Spring AI Advisors 요청 흐름
프롬프트 생성 전후와 응답 처리 단계에 Advisor를 걸 수 있다는 점이 Spring AI의 구조적 강점이다.

Advisors가 중요한 이유는 기능 개수 때문이 아니다. 이 계층이 있다는 사실 자체가 Spring AI의 방향을 보여 준다.

즉 Spring AI는 “한 번 호출하고 문자열 받는 SDK”가 아니라,

  • 메모리
  • RAG
  • Tool Calling
  • 관찰 가능성
  • 평가

같은 요소를 체인 가능한 애플리케이션 구조 안에서 다루려는 프레임워크다.

이걸 이해하면 왜 문서가 Advisors API를 따로 강조하는지도 자연스럽게 보인다.

메모리와 Advisors의 연결

chat-memory.html을 같이 읽어 보면 이 관계가 더 선명해진다. 대화 메모리는 단순 저장소 기능이 아니라, 결국 어떤 시점에 어떤 메시지를 프롬프트에 되주입할지의 문제다.

문서에는 대표적으로 이런 흐름이 나온다.

  • PromptChatMemoryAdvisor
  • VectorStoreChatMemoryAdvisor

둘의 감각은 꽤 다르다.

Prompt 기반 메모리

대화 이력을 일정 범위로 잘라서 프롬프트에 다시 넣는 방식이다.

장점은 단순하다는 점이다. 반면 길이가 늘어나면 토큰 비용과 문맥 혼잡도가 커질 수 있다.

Vector Store 기반 메모리

대화 이력을 임베딩하고, 현재 질문과 의미적으로 가까운 과거 대화만 다시 찾는 방식이다.

이건 더 유연하지만, 결국 검색 품질과 메타데이터 설계가 중요해진다.

즉 메모리조차도 단순 캐시가 아니라 Advisor로 주입되는 문맥 설계로 보는 편이 맞다.

RAG도 Advisor로 붙는다는 점이 중요하다

앞선 RAG 글에서 다뤘듯 Spring AI는 QuestionAnswerAdvisor를 통해 검색 결과를 자연스럽게 대화 호출에 삽입할 수 있다.

이게 의미하는 바는 분명하다.

  • 메모리도 Advisor
  • 검색 기반 문맥 주입도 Advisor
  • 나중에 평가나 관찰 가능성도 Advisor

즉 Spring AI는 다양한 보조 기능을 제각각의 유틸이 아니라, 하나의 체인 모델 안에서 정리한다.

이 구조는 유지보수에 큰 도움이 된다. 기능이 늘어나도 “무엇이 어디에서 개입하는지”를 계층적으로 읽을 수 있기 때문이다.

Streaming vs Non-Streaming을 따로 봐야 하는 이유

스트리밍과 논스트리밍 Advisor 처리 비교
스트리밍 여부에 따라 Advisor 개입 지점과 처리 방식이 달라지므로 별도로 이해하는 편이 안전하다.

문서에서 Streaming vs Non-Streaming이 별도 항목인 것도 실무적으로 중요하다.

채팅 UI처럼 스트리밍 응답을 쓰는 경우, 일부 Advisor는 동기 호출에서처럼 단순하게 전후처리할 수 없다. 응답이 조각 단위로 흘러오기 때문이다.

그래서 실제 구현에서는 이런 질문이 생긴다.

  • 응답 전체가 끝난 뒤만 가능한 후처리인가
  • 토큰이 흐르는 중에도 적용 가능한가
  • 로그/메트릭은 어디서 끊어 기록할 것인가

즉 Advisor는 “추가 로직을 끼운다” 수준이 아니라, 호출 모델 자체를 이해한 상태에서 설계해야 하는 확장 포인트다.

Recursive Advisors는 어디서 유용한가

Recursive Advisors 개념도
재귀적 Advisor는 도구 검색·중첩 호출처럼 단계적으로 문맥을 확장하는 패턴에서 특히 빛난다.

advisors-recursive.html은 한 단계 더 흥미롭다. 어떤 Advisor는 한 번의 요청-응답에만 개입하는 게 아니라, 필요하면 재귀적으로 다시 흐름을 만든다.

문서에서 대표적으로 언급되는 것이 다음과 같다.

  • ToolCallAdvisor
  • StructuredOutputValidationAdvisor

이런 Advisor가 중요한 이유는 “한 번 답하고 끝”이 아닌 패턴을 다루기 때문이다.

예를 들어,

  • 도구 호출 결과를 반영해 다시 답을 생성해야 하거나
  • 구조화 출력이 스키마에 맞지 않아 다시 보정해야 하거나
  • 평가 결과를 바탕으로 한 번 더 다듬어야 하는 경우

가 있다.

이 지점부터 Spring AI는 단순 LLM 호출을 넘어, 작은 에이전트 루프에 가까운 모습을 보이기 시작한다.

Advisor 설계에서 자주 놓치는 것

Advisors를 많이 붙인다고 항상 좋은 건 아니다. 오히려 과하게 쌓이면 흐름이 불투명해질 수 있다.

개인적으로는 아래 원칙을 지키는 편이 좋다.

1) 역할이 다른 Advisor를 구분한다

  • 문맥 주입용
  • 관찰 가능성용
  • 평가/검증용
  • 재귀 제어용

서로 다른 책임을 한 Advisor 안에 섞지 않는 편이 낫다.

2) 순서를 의도적으로 정한다

“동작하니까 됐다”가 아니라, 왜 이 Advisor가 앞에 있고 뒤에 있는지를 설명할 수 있어야 한다.

3) 프롬프트를 실제로 확인한다

여러 Advisor가 붙으면 최종 프롬프트가 어떻게 만들어졌는지 확인하지 않고서는 품질 문제를 잡기 어렵다.

4) 스트리밍 여부를 별도로 테스트한다

비스트리밍에서 잘 되던 흐름이 스트리밍에서 깨지는 경우가 생각보다 흔하다.

처음 붙일 때 추천하는 Advisor 조합

Spring AI를 처음 실무에 넣는다면, 아래 정도가 가장 무난하다.

1단계

  • 기본 ChatClient
  • 아주 단순한 메모리 Advisor 또는 없음

2단계

  • QuestionAnswerAdvisor로 RAG 연결
  • 요청/응답 로깅 또는 관찰 가능성 추가

3단계

  • 필요 시 도구 호출 관련 Advisor
  • 출력 검증 또는 평가 Advisor

처음부터 재귀 Advisor까지 욕심내기보다, 문맥 주입 → 관찰 → 검증 순서로 늘려 가는 편이 안정적이다.

한 문장으로 정리하면

Advisors는 Spring AI에서 부가 기능을 덕지덕지 붙이는 장치가 아니라, 메모리·검색·도구·평가를 호출 파이프라인으로 승격시키는 핵심 설계 계층이다.

그래서 Advisors를 이해하면 Spring AI가 왜 단순 모델 SDK 래퍼가 아닌지 비로소 선명해진다.

마무리

Spring AI를 얕게 보면 ChatClient가 전부처럼 느껴질 수 있다. 하지만 조금만 더 깊게 들어가면, 실제 설계의 중심은 Advisors 쪽에 가깝다.

  • 메모리는 Advisor로 주입된다.
  • RAG도 Advisor로 연결된다.
  • 평가와 검증도 Advisor 체인에 들어갈 수 있다.
  • 재귀적 흐름까지 이 계층에서 다뤄진다.

즉 Advisors는 “추가 기능”이 아니라, Spring AI가 애플리케이션 수준 프레임워크라는 점을 보여 주는 핵심 증거다.

다음 글에서는 이 흐름을 표준화 계층까지 넓혀서, 왜 MCP가 Spring 개발자에게 점점 더 중요한 주제가 되는지 이어서 보겠다.

#Spring AI#Advisors#ChatClient#RAG#Java