Agentic 워크플로우란 무엇일까요? 디자인 패턴 & 언제 사용해야 할까요?

기존 소프트웨어 워크플로는 예측 가능한 방식으로 작동하죠. 미리 정의된 작업 순서와 코드로 짜여진 분기 로직을 따르니까요. 이런 접근 방식은 경로를 미리 알 수 있을 때 효과적인데요. 하지만 경로를 미리 알 수 없다면 어떻게 해야 할까요?

예를 들어 사기 탐지 시스템을 생각해 봐요. 기존 소프트웨어는 미리 정의된 규칙을 적용해서, 특정 임계값을 초과하는 거래에 플래그를 지정하거나, 특정 지역의 거래를 차단하거나, 위험 점수가 특정 값을 넘으면 추가 인증을 요구하는 식으로 작동하죠. 규칙은 명확하지만, 사기는 예측대로 움직이지 않아요. 구매 내역의 미묘한 변화, 새로운 장치 지문, 몇 달 동안 잠잠하다가 갑자기 활동이 폭발하는 경우, 연결된 계정 네트워크 등 다양한 형태로 나타나죠. 사기 탐지 시스템에서는 다음 단계를 결정하기 어려울 때가 많아요. 추가 확인을 요청해야 할지, 계정을 동결해야 할지, 관련 거래를 스캔해야 할지, 아니면 담당자에게 넘겨야 할지... 결정론적인 워크플로는 이런 불확실성을 처리하기 어렵답니다.

에이전트 워크플로는 정해진 범위 내에서 목표를 달성하기 위해 도구와 피드백 루프를 사용해서, 현재 상황과 중간 결과를 바탕으로 다음 작업 단계를 결정해요. 고정된 경로를 따르는 대신, 상황에 맞춰 유연하게 적응하는 거죠.

“단순히 메시지를 한 번 표시하는 대신, 메시지 표시, 도구 호출 등 여러 단계를 거쳐 복잡한 워크플로를 연결하는 반복적인 프로세스를 만들 수 있습니다.“

Andrew Ng, DeepLearning.AI 창립자

이번 글에서는 에이전트 워크플로가 무엇인지, 기존 워크플로와 어떻게 다른지, 그리고 프로덕션 환경에 적용하기 위해 어떻게 설계해야 하는지 알아볼 거예요.

이 가이드에서 다룰 내용:

• 워크플로를 에이전트적으로 만드는 요소는 무엇일까요?
• 결정적 워크플로, 비-에이전트 워크플로, 에이전트 워크플로 비교
•  
• Orchestration
•  
• 프로덕션 환경에 적합한 에이전트 워크플로를 만들려면?
•  
• 에이전트 워크플로가 적합한 경우
•  
• 에이전트 워크플로를 피하거나 제한해야 하는 경우
•  
• 빠른 결정 가이드
•  
• 에이전트 워크플로에 대한 Knowledge Graph
•  
• 필수 GraphRAG
•  

워크플로를 에이전트적으로 만드는 것은 무엇일까요?

에이전트 워크플로에서는 목표는 여전히 정의되어 있지만, 목표에 도달하기 위한 경로는 완전히 정해져 있지 않아요. 대신, AI 에이전트가 현재 상황과 이전 작업 결과를 바탕으로 다음에 뭘 할지 결정하죠. 단순히 텍스트를 생성하는 게 아니라, 시스템이 추론하고, 도구를 사용하고, 결과를 향해 반복할 수 있는 거예요.

이런 변화는 에이전트 AI의 등장으로 가능해졌어요. 팀을 정적이고 미리 정의된 실행 경로에서 벗어나, 상황 변화에 따라 적응하는 프로세스로 이동시키는 거죠.

간단히 말하면:

• 기존 워크플로는 스크립트를 따라요.
• 에이전트 워크플로는 정의된 가이드레일 안에서 실행되는 스크립트를 결정해요.

이걸 안정적으로 수행하기 위해 에이전트 워크플로는 일반적으로 다음 네 단계를 따릅니다.

1. 계획 (Plan): 목표를 해석하고 다음에 무엇을 할지 결정해요.
2. 도구 사용 (Tool Use): 외부 환경과 상호 작용하는 도구를 사용해서 작업을 실행해요.
3. 반성 (Reflection): 결과를 되돌아봐요. 결과가 목표를 달성하지 못하면 루프백해서 다른 계획을 만들고, 목표가 완료될 때까지 다시 실행해요.
4. 오케스트레이션 (Orchestration): 효율적인 워크플로우를 위해 여러 에이전트, 도구, 상태를 조율해요.

에이전트 워크플로 루프

결정적 워크플로, 비에이전트 워크플로, 에이전트 워크플로

흔히 헷갈리는 부분은 에이전트 워크플로가 기존 자동화 방식이나 익숙한 LLM 기반 파이프라인과 어떻게 다른가 하는 점이에요. 시스템을 설계하고, 평가하고, 운영하는 방법이 달라지기 때문에 차이점을 아는 게 중요하죠.

결정론적 (Deterministic)	고정된 단계와 규칙	안정적이고 반복 가능한 프로세스
비에이전트 AI (Non-Agentic AI)	LLM 단계가 있는 고정 파이프라인	요약/분류/추출 등 제한된 작업
에이전트 AI (Agentic AI)	계획하고 도구를 사용하며 피드백을 통해 반복	조사, 진단 및 개방형 작업

기존의 결정적 (Deterministic) 워크플로는 완전히 미리 정의된 시스템이에요. 모든 단계, 분기, 결과는 규칙이나 프로세스 정의를 사용해서 미리 지정되죠. 입력에서 결과까지의 경로가 알려져 있고 안정적일 때 효과적이에요.

비에이전트 AI (Non-Agentic AI) 워크플로는 LLM을 프로세스에 도입하지만, 전체 구조는 대부분 선형으로 유지돼요. 한 단계가 언어 기반이라고 해도 단계 순서는 여전히 미리 정의되어 있죠 (예: 컨텍스트 검색 → 출력 생성 → 중지). 모델은 파이프라인 내에서 작업을 수행하지만, 결과에 따라 다음에 뭘 할지 의미 있게 결정하지는 않아요.

에이전트 워크플로는 목표를 잃지 않으면서도 상황에 맞게 유연하게 경로를 조정할 수 있게 해줘요. 다시 말해, 계획을 세우고, 도구를 사용하고, 결과를 평가하면서 성공 조건이나 안전한 중단 시점에 도달할 때까지 계속 진행하는 방식이죠.

에이전트 워크플로를 위한 디자인 패턴

에이전트 워크플로는 모델을 그저 "자유롭게 실행"하는 방식으로 만들어지지 않아요. 오히려 자율성과 제어 사이의 균형을 맞춰주는 재사용 가능한 작은 디자인 패턴들에 의존하죠. 이런 패턴들은 환각, 불안정한 출력, 조용한 오류 등 프로덕션 시스템에서 흔히 발생하는 문제들을 해결해 준답니다.

계획 패턴

계획 패턴은 Large Language Model (LLM)이 높은 수준의 목표를 실행 가능한 단계로 나누고, 런타임에 순서를 결정하는 방식이에요.

미리 경로를 정해두는 대신, 시스템은 목표, 현재 컨텍스트, 그리고 이전 작업의 결과를 바탕으로 다음에 어떤 일이 일어나야 할지 결정해요. 이걸 종종 작업 분해 및 순서 지정이라고 부르죠.

에이전트 워크플로의 계획 디자인 패턴입니다.

도움이 될 때

계획 패턴은 다음과 같은 경우에 특히 유용해요.

• 질문이나 작업에 여러 단계의 추론이 필요할 때
• 단계들이 이전 결과에 따라 달라질 때
• 입력 정보가 불완전하거나 모호할 때
• 올바른 경로를 미리 정하기 어려울 때

예를 들어, 사건 조사, 심층 연구, 계약 분석, 복잡한 지원 티켓 분류처럼 각 단계의 결과가 다음 단계에 영향을 미치는 상황에서 효과적이죠.

구현 노트

계획 패턴은 강력하지만, 신뢰성을 확보하기 위해 몇 가지 제한이 필요해요.

• 계획은 테스트 가능해야 해요. 각 단계는 워크플로를 계속 진행할지, 재시도할지, 아니면 중단할지를 결정할 수 있도록 명확한 성공 또는 실패 조건을 포함해야 해요.
• 계획은 행동으로 연결되어야 해요. 실행 없는 계획은 그저 추측일 뿐이죠. 각 단계는 구체적인 도구 호출, 쿼리 또는 작업에 해당해야 한답니다.

실제로 프로덕션 시스템에서는 무제한적인 자율성보다는 가이드레일과 결합된 가볍고 제한적인 계획을 사용하는 경우가 많아요. 이렇게 하면 예측 가능성을 유지하면서도 적응성을 확보할 수 있죠.

도구 사용 패턴

모델이 텍스트로 추측하는 대신, 도구를 사용해서 소스 시스템에서 직접 답변을 얻고 필요한 조치를 취하는 패턴이에요.

모델은 학습 데이터에서 답을 추론하는 대신, 데이터베이스 쿼리, API 호출, 작업 실행과 같은 특정 기능을 호출하고 그 결과를 워크플로에 통합할 수 있어요.

이것이 바로 LLM을 에이전트로 바꿔주는 핵심이죠!

도구는 에이전트 워크플로에서 디자인 패턴을 사용합니다.

도움이 될 때

정확성이 정적인 지식이 아니라 현재 시스템 상태에 따라 달라지는 모든 워크플로에서는 도구 사용이 필수적이에요. 몇 가지 일반적인 예시를 살펴볼까요?

• 데이터베이스 또는 Knowledge Graph 쿼리
• CRM 또는 티켓팅 시스템 확인
• 배포, 로그 또는 인프라 상태 검사
• 계산 또는 검증 실행
• 비즈니스 시스템에서 다운스트림 작업 트리거

도구를 사용하지 않으면 에이전트 워크플로는 그저 어림짐작에 불과하게 될 거예요. 도구를 사용해야 권위 있는 시스템에 기반하여 결정을 내리고 실제 상황에 적응할 수 있게 되죠.

구현 노트

프로덕션 시스템에서는 도구 사용을 명시적으로 제한해야 해요.

주요 고려 사항은 다음과 같아요.

 

• 도구 스키마 및 엄격한 검증
  입력된 입력과 잘 구조화된 출력으로 도구를 정의해요. 이렇게 하면 모호성이 줄어들고 형식이 잘못되었거나 안전하지 않은 호출을 방지할 수 있죠.
• 구조화된 컨텍스트로서의 도구
  도구는 각 도구의 기능과 사용해야 하는 경우에 대한 명확한 설명을 포함하여 컨텍스트의 일부로 모델에 제공돼요. 이를 통해 모델은 환각적인 행동 대신 올바른 도구를 안정적으로 선택할 수 있어요.

모델 컨텍스트 프로토콜로 도구 액세스 표준화

에이전트 워크플로가 확장됨에 따라 여러 시스템에 걸쳐 도구를 관리하는 것이 점점 더 복잡해지고 있어요. 그만큼 모델 컨텍스트 프로토콜(MCP)은 AI 시스템에 도구, 리소스 및 프롬프트를 노출하기 위한 표준 인터페이스를 제공하여 이 문제를 해결하죠.

MCP를 사용하면 에이전트는 맞춤형 일회성 통합이 아닌 일관되고 검색 가능한 프로토콜을 통해 데이터베이스, API 및 서비스와 상호 작용해요. 모든 모델이나 프레임워크에 대해 각 도구를 개별적으로 연결하는 대신 팀은 MCP 서버를 통해 기능을 한 번 공개하고 클라이언트와 워크플로 전체에서 사용할 수 있도록 할 수 있어요.

이러한 표준화는 신속한 프로토타이핑보다 생산 시스템에서 훨씬 더 중요한 품질인 신뢰성, 관찰 가능성 및 재사용을 향상시켜요.

반사 패턴

반사는 AI 시스템이 자체 출력을 비판하고 결과를 확정하기 전에 수정하는 패턴이에요. 첫 번째 응답이 정확하다고 가정하는 대신 워크플로는 출력이 정의된 제약 조건과 품질 기준을 충족하는지 여부를 평가하죠.

에이전트 워크플로의 반사 디자인 패턴입니다.

도움이 될 때

반사는 속도보다 정확성이나 정밀도가 더 중요한 출력 변동이 큰 작업에 특히 유용해요.

• 코드 생성 및 리팩토링
• Query 생성(SQL, Cypher, GraphQL)
• 정책 또는 규정 준수 언어
• 엄격한 제약이 있는 구조화된 요약
• 초기 실수가 복잡해지는 다단계 추론

이러한 경우 단일 패스 생성은 그럴듯해 보이지만 미묘한 요구 사항을 충족하지 못하는 경우가 많아요. 리플렉션은 이러한 문제가 사용자나 다운스트림 시스템에 도달하기 전에 포착하죠.

구현 노트

프로덕션 시스템에서 리플렉션은 명시적인 평가 단계로 구현돼요.

일반적인 패턴:

• 하나의 프롬프트(또는 모델)를 생성기로 사용
• 두 번째 프롬프트(또는 모델)를 비평가 또는 판단자로 사용
• 수정 단계에 구조화된 비평 제공

반영을 예측 가능하고 비용 효율적으로 유지하려면 다음을 수행하세요.

• 폭주 루프를 방지하기 위해 반복 횟수 제한
• 명시적인 평가 기준 정의
• 선택적으로 일반적인 실패 패턴을 유지하여 향후 실행을 개선합니다.

리플렉션만으로는 워크플로를 완전히 에이전트화할 수 없어요. 그러나 이는 출력 품질과 신뢰성을 크게 향상시키며, 팀이 생산 시스템에서 채택하는 첫 번째 패턴인 경우가 많죠.

관현악법

오케스트레이션은 단일 모놀리식 에이전트에 의존하는 대신 여러 전문 에이전트가 공유 목표 및 공유 상태를 중심으로 조정하는 데 도움이 되는 패턴이에요.

각 에이전트는 다음과 같은 집중적인 역할을 수행해요.

• – 목표를 단계로 분해합니다.
• – 관련 데이터 수집
• – 도구 호출 또는 작업을 수행합니다.
• 검증인/판사– 정확성 또는 규정 준수 여부를 확인합니다.
• – 결과를 종합하고 전달합니다.

이러한 책임 분리는 명확성, 제어 및 신뢰성을 향상시켜요.

에이전트 워크플로의 다중 에이전트 협업 디자인 패턴이에요.

도움이 될 때는 언제일까요?

오케스트레이션은 워크플로에 다음 내용이 포함될 때 가장 유용해요.

• 전문 분야가 다른 여러 에이전트
• 다양한 전문 분야(예: 법률, 금융, 보안)
• 독립적인 검증 또는 검토 요구 사항
• 실행과 검증을 분리하여 위험을 줄이는 고위험 결정

예를 들어, 한 에이전트는 계약 수정을 제안하고 다른 에이전트는 승인 전에 정책 및 규제 제약 조건에 대해 이를 검증할 수 있죠.

구현 노트

구조가 없으면 다중 에이전트 시스템은 금방 혼란스러워질 수 있어요.

• 공유 상태 및 결정 추적
  에이전트는 작업을 설명하고 감사할 수 있도록 공통 메모리 계층에서 읽고 써야 해요.
• 
  각 에이전트에는 명확하게 정의된 책임과 전달 지점이 있어야 해요. 역할이 과도하게 겹쳐 중복되거나 작업이 충돌하는 디자인은 피해야겠죠?

신중하게 설계하면 다중 에이전트 협업은 복잡한 워크플로를 불투명한 프롬프트 체인이 아닌 조정되고 검사 가능한 시스템으로 전환하여 안정성을 높여준답니다.

프로덕션 등급 에이전트 워크플로에 필요한 것

에이전트 워크플로에는 유연성과 새로운 실패 모드가 도입되었어요. 성공은 유도 기술보다는 통제, 평가, 시스템 규율에 더 많이 좌우되죠. 프로덕션에서 에이전트 워크플로에는 다음이 필요해요.

• : 명시적으로 허용 및 허용되지 않는 작업을 정의하고, 도구 및 데이터에 대한 최소 권한 액세스를 적용하고, 모든 도구 호출에 대한 입력 및 출력을 검증하여 안전하지 않은 동작, 과도한 접근 및 검증되지 않은 결정을 방지해야 해요.
• 오류 처리 및 안전 실패 모드: 시간 초과, 제한된 재시도 및 멱등성 도구 호출로 인한 불가피한 오류에 대비하여 설계해야 해요. 대체 실행, 인적 에스컬레이션 경로 및 루프 차단기를 구현하여 폭주 실행을 방지하고 안전한 성능 저하를 보장해야겠죠.
• : 프롬프트, 도구 및 데이터 품질을 반복적으로 개선하기 위해 계층화된 테스트(단위, 통합, 회귀) 및 지속적인 오류 분석을 통해 지원되는 정확성, 유용성 및 위험에 대한 결과 기반 평가에 중점을 둬야 해요.
• 지연 시간 및 비용 제어: 토큰 예산, 제어된 도구 호출 병렬화, 구조화된 검색(그래프 기반 접근 방식 포함)을 통해 생산 실행 가능성을 유지하여 불필요한 컨텍스트 확장을 최소화하고 비용을 절감하며 의사 결정 품질을 향상시켜야 해요.

에이전트 워크플로가 적합한 경우와 그렇지 않은 경우

에이전트 워크플로는 결정적 시스템에 대한 기본적인 업그레이드가 아니에요. 특정 유형의 문제에 적합하답니다.

에이전트 워크플로가 적합한 경우

에이전트 워크플로는 다음과 같은 경우에 적합해요.

• 입력이 모호하거나 불완전한 경우
• 목표는 명확하지만 실행 경로는 유연한 경우
• 작업에 조사, 진단 또는 문제 해결이 필요한 경우
• 시스템이나 정책의 발전으로 인해 워크플로가 자주 변경되는 경우

이는 사전 정의된 스크립트가 중단되고 런타임 의사 결정이 가치를 더하는 환경이에요.

에이전트 워크플로를 피하거나 제한해야 하는 경우

에이전트 워크플로는 일반적으로 다음과 같은 경우 부적절하거나 엄격하게 제한되어야 해요.

• 워크플로는 간단하고 반복 가능하며 규칙 중심인 경우
• 지연 시간 요구 사항이 매우 엄격한 경우(예: 실시간 제어 시스템)
• 승인 게이트가 없는 작업은 위험도가 높거나 규정 준수가 중요한 경우
• 도구 신뢰성이 낮고 실패로 인해 심각한 결과가 발생하는 경우

이러한 경우 결정적 아키텍처 또는 하이브리드 아키텍처가 일반적으로 더 안전하고 예측 가능하답니다.

빠른 결정 가이드

• 경로가 알려진 경우 → 결정적 작업 흐름을 사용하세요.
• 경로는 알 수 없지만 목표는 분명한 경우 → 에이전트 워크플로를 고려해 보세요.
• 둘 다 불분명한 경우 → 범위를 좁히거나 사람이 계속해서 파악하도록 하세요.

에이전트 워크플로에 대한 Knowledge Graph

대부분의 팀은 에이전트 메모리를 벡터 데이터베이스에 저장하고 벡터 검색을 통해 검색해요. 정답이 텍스트일 때 잘 작동하죠. 의미상 가장 유사 쿼리에.

한계는 유사성만으로는 구조, 즉 어떤 엔터티가 연결되어 있는지, 어떻게 연결되어 있는지, 어떤 경로가 작업에 중요한지를 파악하지 못한다는 거예요. 작업이 해당 연결에 따라 달라지는 경우 가장 가까운 청크를 검색하면 실제로 필요한 사실을 놓칠 수 있답니다.

A Knowledge Graph는 엔터티와 관계를 명시적으로 모델링해서 구조적인 맥락을 더해줘요. 실제 시스템과 도메인이 구성되는 방식에 더 가깝죠. 런타임 시 에이전트는 여러 홉(예: 서비스 → 종속성 → 소유자 → 티켓 기록)을 거쳐 유사한 표현을 사용하지 않을 수도 있지만, 연결되어 있고 관련성이 있는 정보를 가져올 수 있어요.

에이전트 시스템의 경우, Knowledge Graph는 사실을 저장하고 에이전트가 검색을 통해 검색하는 관련 엔터티에 대한 다중 홉 추론을 가능하게 하는 구조화된 메모리를 제공해요. GraphRAG 덕분이죠. 또한 에이전트의 결정을 추적하고 설명하는 결정 추적 기능도 제공해요.

에이전트 워크플로가 구조화되고 연결된 컨텍스트에 의존하면 디버깅, 감사, 제어가 더 쉬워져요. 이 모든 작업은 프로덕션 환경에 필수적이죠.

어휘 및 도메인 그래프가 포함된 그래프 데이터베이스를 보여주는 GraphRAG 아키텍처 다이어그램.

신뢰할 수 있는 에이전트 워크플로 구축

에이전트 워크플로를 사용하면 계획, 도구 사용, 반영 및 협업을 결합하여 AI가 고정된 즉각적인 응답 일정이 아닌 동적 환경에서 작동할 수 있어요.

하지만 디자인 패턴만으로는 충분하지 않아요. 프로덕션 환경에서의 성공은 가드레일, 평가 규율, 통제된 실행, 고품질 컨텍스트에 달려있죠. 이러한 기반이 없으면 유연성은 취약해져요. 에이전트 시스템이 정확하고 안전하며 대규모로 작동해야 하는 경우, 컨텍스트 품질은 모델 기능만큼 중요해요.

Knowledge Graph는 에이전트 시스템에 필요한 구조적 계층과 품질 컨텍스트를 제공해요. 엔터티와 관계를 명시적으로 모델링함으로써 모호성을 줄이고 검색 정밀도를 높이며 의사결정을 추적 가능하게 만들죠. GraphRAG를 통해 에이전트는 의미상 유사한 텍스트 대신 연결된 사실을 검색하여 보다 신뢰할 수 있는 출력을 생성해요.

Knowledge Graph를 사용하여 검색을 강화하고, 환각을 줄이고, 프로덕션급 에이전트 워크플로를 지원하는 방법을 알아보려면 Manning의 Essential GraphRAG를 읽어보세요. 실제 에이전트 시스템을 위한 도메인 모델링, 그래프 기반 검색 설계 및 컨텍스트 엔지니어링을 다루고 있어요.

필수 GraphRAG

Knowledge Graph를 통해 RAG의 잠재력을 최대한 활용하세요. 한정된 기간 동안 Manning으로부터 최종 가이드를 무료로 받아보세요.

---

에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지