Building Effective Agents with Spring AI (Part 1) 한국어 정리
Building Effective Agents with Spring AI (Part 1) 한국어 정리
Anthropic가 공개한 Building effective agents는 한동안 에이전트 설계 논의의 기준점처럼 쓰였다.
흥미로운 건 이 글이 “더 복잡한 프레임워크를 만들자”가 아니라, 오히려 단순함과 조합 가능성을 강조한다는 점이다.
Spring 팀의 글 *Building Effective Agents with Spring AI (Part 1)*는 이 관점을 Spring AI에 가져와서, 실제 애플리케이션 설계에 어떻게 녹일 수 있는지를 설명한다. 이 글은 그 내용을 한국어로 다시 정리한 것이다.
핵심 메시지는 아주 단순하다.
완전 자율 에이전트를 무조건 지향하기보다, 문제의 성격에 따라 워크플로우와 에이전트 패턴을 구분해서 쓰는 편이 더 낫다.
Agentic Systems를 두 종류로 나눠서 봐야 한다
원문은 에이전트 시스템을 크게 두 부류로 나눈다.
- Workflows
LLM과 도구가 정해진 코드 경로를 따라 움직이는 시스템 - Agents
LLM이 자기 프로세스와 도구 사용을 더 동적으로 결정하는 시스템
이 구분이 중요한 이유는, 많은 팀이 “에이전트”라는 단어 때문에 모든 문제를 자율 에이전트처럼 풀려고 하기 때문이다. 하지만 실제 서비스에서는 예측 가능성과 유지보수성이 더 중요할 때가 많다.
Spring AI 관점에서도 이건 아주 현실적인 판단 기준이 된다.
- 작업이 잘 정의돼 있으면 → 워크플로우 기반 설계가 낫고
- 작업 분해나 방향 결정이 더 유동적이면 → 에이전트성 패턴이 필요해진다
즉 무조건 더 자율적인 쪽이 정답은 아니다.
1. Chain Workflow
Chain Workflow는 가장 이해하기 쉬운 패턴이다.
복잡한 일을 한 번에 모델에게 던지지 않고, 순차적인 작은 단계들로 나누는 방식이다.
언제 좋은가?
- 단계가 명확할 때
- 응답 속도보다 정확도가 더 중요할 때
- 앞 단계 결과가 뒷단계 입력이 되는 작업일 때
예를 들면,
- 초안 작성 → 요약 → 문체 다듬기
- 요구사항 분석 → 설계 정리 → 코드 스캐폴드 생성
- 원문 읽기 → 핵심 포인트 추출 → 한국어 설명 재구성
Spring AI 글에서 보여주는 감각은 단순하다. 각 단계마다 다른 시스템 프롬프트를 주고, 이전 결과를 다음 입력으로 넘긴다. 이 방식은 구현이 어렵지 않으면서도 품질을 꽤 안정적으로 끌어올린다.
장점은 분명하다.
- 각 단계 책임이 분리된다
- 문제 생긴 지점을 찾기 쉽다
- 단계 추가/삭제가 쉽다
즉 “단순한데 강한” 패턴이다.
2. Parallelization Workflow
Parallelization은 여러 LLM 작업을 동시에 돌리고 결과를 합치는 방식이다.
원문은 이 패턴을 두 갈래로 설명한다.
- Sectioning: 서로 독립적인 하위 작업을 병렬 처리
- Voting: 같은 작업을 여러 번 돌려 합의/평균을 보는 방식
언제 좋은가?
- 비슷하지만 독립적인 항목이 많을 때
- 여러 관점이 동시에 필요할 때
- 처리 시간이 중요할 때
예를 들어,
- 여러 이해관계자별 영향 분석
- 문서 여러 장 동시 요약
- 여러 초안을 동시에 만들고 가장 나은 결과 선택
Spring AI에서 이 패턴이 유용한 이유는, LLM 호출을 애플리케이션 레벨에서 조합하기 쉬워서다. 모델 한 번 호출에 집착하지 않고, 여러 호출을 구조적으로 배치할 수 있다.
3. Routing Workflow
Routing은 입력을 분석해서 가장 맞는 처리 경로로 보내는 패턴이다.
예를 들면,
- 결제 문의 → billing prompt
- 기술 문제 → technical prompt
- 일반 문의 → general prompt
언제 좋은가?
- 입력 종류가 뚜렷하게 나뉠 때
- 도메인별 전문 프롬프트가 필요할 때
- 분류 정확도가 충분히 확보될 때
Spring AI 글에서 보여주는 핵심은 “하나의 만능 프롬프트”보다, 입력 분류 + 전문 처리 경로가 더 안정적일 수 있다는 점이다.
실무에서 이 패턴은 꽤 자주 쓴다.
- 고객지원 챗봇
- 티켓 라우팅
- 문서 분류 후 처리
- 여러 도메인 QA 시스템
즉 Routing은 에이전트성이라기보다, LLM 기반 스마트 라우터에 가깝다.
4. Orchestrator-Workers
이 패턴부터는 조금 더 “에이전트 같다”는 느낌이 난다.
구조는 이렇다.
- Orchestrator가 작업을 보고 어떤 하위 작업들이 필요한지 정한다
- Workers가 각 하위 작업을 처리한다
- 마지막에 결과를 다시 모아 최종 응답을 만든다
언제 좋은가?
- 하위 작업을 미리 고정하기 어려울 때
- 여러 관점/여러 산출물이 동시에 필요할 때
- 문제 해결 방식이 유동적일 때
예를 들어,
- 기술 문서 + 사용자 문서를 동시에 생성
- 분석 + 요약 + 리스크 포인트를 따로 뽑기
- 하나의 문제를 여러 작업자에게 나눠 맡기기
이 패턴의 장점은 유연성이다. 하지만 그만큼 복잡해질 수 있다. 그래서 Spring 글도 “제어를 유지한 채 복잡한 에이전트 행동을 구현한다”는 식으로 설명한다.
즉 완전 자율보다는, 관리 가능한 유연성이 포인트다.
5. Evaluator-Optimizer
이 패턴은 생성기와 평가기를 분리하는 구조다.
- Generator LLM: 초안 생성
- Evaluator LLM: 결과를 평가하고 개선 피드백 제공
- 필요하면 반복
언제 좋은가?
- 평가 기준이 비교적 명확할 때
- 한 번 더 다듬는 과정이 의미 있을 때
- 품질을 반복적으로 끌어올리고 싶을 때
예를 들면,
- 코드 생성 후 품질 점검
- 문서 초안 후 표현 개선
- 정책 문안 초안 후 규칙 충족 여부 확인
이 패턴은 특히 “사람처럼 한 번 쓰고, 다시 검토하고, 다시 다듬는 흐름”과 잘 맞는다.
다만 반복이 길어지면 비용/지연이 커질 수 있으니, 평가 기준을 명확하게 잡는 게 중요하다.
Spring AI에서 이 패턴들이 좋은 이유
원문 글은 Spring AI 구현의 강점을 몇 가지로 요약한다.
1) Model Portability
공급자를 바꾸더라도 애플리케이션 구조를 크게 바꾸지 않게 해준다.
2) Structured Output
평가 결과나 라우팅 결과를 문자열이 아니라 타입 안전한 구조체로 받게 만들 수 있다.
3) Consistent API
ChatClient 중심으로 호출 감각이 일정해서, 패턴 구현을 여러 공급자에 걸쳐 반복 적용하기 쉽다.
이건 결국 “에이전트 패턴을 코드로 옮기는 난이도”를 낮춰 준다.
즉 논문에서 본 패턴이 데모로 끝나지 않고, 실제 서비스 구조로 이어질 수 있게 만든다.
이 글에서 진짜 중요한 교훈
이 글이 말하고 싶은 건 사실 아주 현실적이다.
- 처음부터 완전 자율 에이전트를 만들려 하지 말 것
- 가장 단순한 패턴부터 시작할 것
- 문제에 맞는 패턴만 쓸 것
- 복잡성은 꼭 필요할 때만 추가할 것
이건 엔터프라이즈 개발 환경에 특히 잘 맞는다.
안정성, 예측 가능성, 유지보수성이 중요한 환경에서는 “멋진 자율성”보다 통제 가능한 설계가 더 중요하기 때문이다.
실무적으로 어떻게 적용하면 좋나
개인적으로는 이런 식으로 생각하면 좋다.
- Chain: 가장 먼저 도입할 패턴
- Parallelization: 처리량/관점 다양성이 필요할 때
- Routing: 입력 유형이 명확히 나뉠 때
- Orchestrator-Workers: 복합 작업 분해가 필요할 때
- Evaluator-Optimizer: 품질 반복 개선이 중요할 때
즉 패턴은 장식이 아니라, 문제의 성격에 따라 고르는 도구 세트다.
Series Links
- Building Effective Agents with Spring AI (원문)
- Spring AI Agentic Patterns (Part 1): Agent Skills 한국어 정리
- Spring AI 2.0, 왜 지금 다시 볼 만한가
- ChatClient가 사실상 Spring AI의 진입점인 이유
- RAG를 Spring AI에서 구현하면 뭐가 쉬워지나