왜 지금 에이전트 오케스트레이션이 문제인가
멀티 에이전트 루프를 프로덕션에 배포하는 순간, 데모 환경에서는 드러나지 않던 구조적 문제들이 수면 위로 올라온다. 에이전트가 수렴에 실패하고 무한 루프에 빠지거나, 고위험 작업을 승인 없이 실행하거나, 비정상적인 상태 전이가 발생하는 것들이 대표적이다. 이런 문제를 해결하기 위해 Java 개발자는 기존에 두 가지 선택지 중 하나를 골라야 했다. Temporal이나 Camunda 같은 외부 워크플로우 클러스터를 도입해 운영 오버헤드를 감수하거나, 서비스 내부에 취약한 while 루프와 커스텀 상태 머신을 직접 구현하는 것이다. 어느 쪽도 장기적으로 유지보수하기 쉬운 선택은 아니었다.
Quarkus Flow가 제시하는 대안
Quarkus Flow는 이 딜레마를 해소하기 위해 설계된 오케스트레이션 프레임워크다. 외부 워크플로우 클러스터 없이 서비스 내부에서 멀티 에이전트 루프를 프로덕션 수준으로 운영할 수 있도록 지원한다. Quarkus 생태계 위에서 동작하기 때문에 Java 백엔드 개발자가 익숙한 CDI, REST, Reactive 패턴과 자연스럽게 통합된다.
핵심은 에이전트 간 상태 전이와 실행 흐름을 선언적으로 정의할 수 있다는 점이다. 아래처럼 에이전트 스텝을 플로우로 엮으면, 런타임이 상태 관리와 오류 복구를 처리해준다.
@ApplicationScoped
public class ReviewFlow {
@Inject
AnalysisAgent analysisAgent;
@Inject
ApprovalGate approvalGate;
public FlowResult run(String input) {
return Flow.start(input)
.step(analysisAgent::analyze)
.gate(approvalGate::requireHumanApproval)
.step(analysisAgent::finalize)
.build();
}
}
직접 while 루프로 상태를 관리하던 코드와 비교하면, 실행 흐름이 명시적으로 드러나고 게이트(gate) 지점에서 인간 개입을 강제할 수 있다는 점이 실무에서 큰 차이를 만든다.
AGENTS.md로 거버넌스 기반 확보하기
AGENTS.md는 에이전틱 워크플로우에 운영 정책을 명문화하는 구성 요소다. 단순한 문서가 아니라, 워크플로우 런타임이 실제로 참조하는 정책 명세 파일로 기능한다. 여기에 정의할 수 있는 내용은 크게 세 가지다.
- 고위험 작업 승인 정책: 특정 툴 호출이나 상태 전이에 인간 승인을 필수로 지정
- 루프 제한 규칙: 에이전트가 동일 스텝을 반복할 수 있는 최대 횟수를 명시해 무한 루프 방지
- 표준 툴 호출 통합: 외부 API, 데이터베이스 조작 등 사이드 이펙트가 있는 작업을 거버넌스 범위 안에서 통제
이 파일이 없으면 에이전트의 행동 범위는 코드와 프롬프트에만 의존하게 되고, 정책 변경 시마다 코드를 수정해야 한다. AGENTS.md를 통해 정책과 구현을 분리하면, 운영 중 정책을 조정할 때 코드 배포 없이 대응할 수 있는 유연성이 생긴다.
정리
- Quarkus Flow는 Temporal·Camunda 같은 외부 클러스터 없이 서비스 내에서 멀티 에이전트 루프를 프로덕션 수준으로 운영할 수 있게 해준다
- AGENTS.md는 고위험 작업 승인, 무한 루프 방지, 툴 호출 통제 등 운영 정책을 선언적으로 정의해 에이전트 거버넌스의 기반이 된다
- 두 가지를 조합하면 정책과 구현을 분리하면서도 Java 백엔드 서비스 안에서 거버넌스가 적용된 워크플로우를 구현할 수 있다