Agent pattern과 workflow pattern

이 장에서 배울 것

앞의 에이전트란 무엇인가에서는 에이전트를 '목표를 받고, 상황을 판단하고, 도구를 사용하며, 결과를 다시 확인하는 시스템'으로 보았다. 이번 장에서는 한 걸음 더 들어간다. 모든 LLM 시스템이 에이전트일 필요는 없다. 어떤 문제는 정해진 순서대로 처리하는 워크플로가 더 안전하고 빠르다. 반대로 어떤 문제는 실행 중 판단이 필요하므로 에이전트형 구조가 더 적합하다.

이 장의 목표는 두 가지다.

• 결정적 워크플로와 에이전트형 패턴을 구분한다.

• 요구사항에 맞는 오케스트레이션 구조를 선택한다.

오케스트레이션은 여러 단계, 모델, 도구, 조건 분기를 어떤 순서로 실행할지 설계하는 일이다. 쉽게 말해 'AI 시스템의 업무 흐름을 짜는 것'이다.

왜 이 주제가 중요한가

LLM 앱을 처음 만들 때 흔히 하는 실수는 모든 문제를 자율 에이전트로 풀려고 하는 것이다. 사용자가 요청하면 에이전트가 알아서 계획하고, 도구를 고르고, 실행하고, 결과를 정리하게 만든다. 데모에서는 멋져 보인다. 하지만 실제 운영에서는 문제가 생긴다.

도구 호출이 불필요하게 많아지고, 비용이 늘고, 응답 시간이 길어진다. 실패했을 때 어느 단계에서 문제가 생겼는지 찾기 어렵다. 같은 입력에 다른 결과가 나와 테스트도 어려워진다. 특히 승인, 결제, 문서 발송, 고객 알림처럼 실수가 큰 비용으로 이어지는 작업에서는 과도한 자율성이 위험하다.

운영 가능한 시스템은 보통 완전한 자율 에이전트가 아니다. 예측 가능한 워크플로를 기본으로 두고, 판단이 필요한 일부 구간에만 제한된 에이전트성을 넣는다. 즉, 좋은 설계자는 '어디를 고정하고, 어디를 열어둘지'를 결정한다.

핵심 개념 설명

Workflow pattern: 순서가 정해진 처리 흐름

워크플로 패턴은 입력, 처리 단계, 출력이 비교적 명확한 구조다. 예를 들어 문서 처리 파이프라인을 생각해보자.

1. 사용자가 문서를 업로드한다.

2. 텍스트를 추출한다.

3. 문서 종류를 분류한다.

4. 필요한 항목을 뽑는다.

5. 형식에 맞게 요약한다.

6. 사람이 검토한다.

7. 최종 저장한다.

이런 업무는 순서가 거의 고정되어 있다. 중간에 LLM이 쓰이더라도 전체 구조는 예측 가능하다. 실패 지점도 비교적 분명하다. 텍스트 추출이 실패했는지, 분류가 틀렸는지, 요약 품질이 낮은지 단계별로 확인할 수 있다.

워크플로는 다음 상황에 적합하다.

• 처리 순서가 정해져 있다.

• 입력과 출력 형식이 명확하다.

• 감사 로그와 재현성이 중요하다.

• 비용과 지연 시간을 예측해야 한다.

• 실패 시 어느 단계가 문제인지 추적해야 한다.

Agent pattern: 실행 중 판단하는 구조

에이전트 패턴은 정해진 순서보다 실행 중 판단이 중요할 때 사용한다. 예를 들어 고객지원 에이전트를 보자. 사용자의 질문은 매번 다르다. 어떤 사용자는 환불을 묻고, 어떤 사용자는 장애 상황을 설명하고, 어떤 사용자는 계정 변경을 요청한다. 에이전트는 먼저 의도를 파악하고, 필요한 정보를 확인하고, 적절한 도구를 선택해야 한다.

이 구조에서는 다음 질문이 중요하다.

• 지금 사용자의 목표는 무엇인가?

• 답변만 하면 되는가, 도구를 호출해야 하는가?

• 추가 질문이 필요한가?

• 정책상 사람이 승인해야 하는가?

• 결과가 충분한가, 다시 확인해야 하는가?

에이전트 패턴은 다음 상황에 적합하다.

• 요청의 형태가 다양하다.

• 실행 중 다음 행동을 선택해야 한다.

• 여러 도구 중 무엇을 쓸지 판단해야 한다.

• 사용자와 여러 번 상호작용해야 한다.

• 예외 상황이 많고 고정 절차로 모두 커버하기 어렵다.

단, 에이전트형 구조가 항상 더 똑똑한 구조는 아니다. 자유도가 높아질수록 디버깅, 비용 관리, 안전장치 설계가 어려워진다.

대표 패턴 비교

LLM 시스템을 설계할 때 자주 쓰는 패턴을 입력, 출력, 실패 지점 중심으로 비교해보자.

Prompt chaining

Prompt chaining은 가장 기본적인 워크플로 패턴이다. 하나의 큰 일을 여러 작은 단계로 나눈다. 예를 들어 FAQ 답변 생성 시스템을 만든다면 다음처럼 나눌 수 있다.

1. 질문에서 핵심 의도를 추출한다.

2. 관련 FAQ 항목을 찾는다.

3. 답변 초안을 만든다.

4. 금지 표현과 정책 위반을 검사한다.

5. 최종 답변을 출력한다.

장점은 단순하다는 것이다. 각 단계의 입출력이 보이므로 디버깅이 쉽다. 단점은 앞 단계가 틀리면 뒤 단계가 함께 흔들린다는 점이다. 따라서 중요한 단계마다 검증을 넣어야 한다.

Routing

Routing은 입력을 보고 어느 경로로 보낼지 결정하는 방식이다. 고객 문의를 '결제', '계정', '기술 장애', '환불'로 나누는 경우가 대표적이다.

라우터는 작고 단단해야 한다. 라우터가 복잡해지면 전체 시스템이 불안정해진다. 처음에는 분류 항목을 적게 시작하는 편이 좋다. 또한 '모르겠음', '사람에게 전달' 같은 안전한 경로를 반드시 둬야 한다.

Parallelization

Parallelization은 여러 작업을 동시에 실행하는 방식이다. 예를 들어 하나의 계약서를 분석할 때 조항 요약, 위험 문구 탐지, 개인정보 포함 여부 확인을 동시에 수행할 수 있다. 서로 독립적인 검토라면 병렬 처리로 시간을 줄일 수 있다.

하지만 병렬 처리에는 병합 문제가 있다. 각 결과가 서로 충돌할 때 무엇을 우선할지 정해야 한다. 따라서 병렬화는 '나눌 수 있는 일'과 '다시 합칠 기준'이 있을 때 사용해야 한다.

Evaluator-optimizer

Evaluator-optimizer는 생성자와 평가자를 나누는 패턴이다. 생성자가 답변을 만들고, 평가자가 기준에 따라 점검한다. 부족하면 다시 개선한다.

이 방식은 품질 향상에 도움이 된다. 다만 평가 기준이 흐릿하면 반복만 늘어난다. '더 좋게 만들어라'는 기준은 약하다. '정책 문구를 포함했는가', '답변이 세 문단 이내인가', '사용자에게 필요한 다음 행동을 안내했는가'처럼 확인 가능한 기준이 필요하다.

Orchestrator-subagents

Orchestrator-subagents는 중앙 조정자가 여러 하위 에이전트에게 일을 나누는 구조다. 예를 들어 문서 작성 에이전트가 조사 담당, 초안 담당, 검토 담당, 형식 정리 담당을 부를 수 있다.

이 구조는 강력하지만 비용이 크다. 하위 에이전트가 많아지면 컨텍스트가 오염될 수 있다. 컨텍스트 오염은 한 작업에 필요 없는 정보가 섞여 모델의 판단을 흐리는 현상이다. 또 각 에이전트가 비슷한 일을 반복할 수도 있다. 따라서 멀티 에이전트 구조는 처음부터 쓰기보다, 단일 구조로 한계를 확인한 뒤 도입하는 편이 안전하다.

쉬운 비유 또는 사례

워크플로는 공장의 조립 라인과 비슷하다. 부품이 들어오면 정해진 순서대로 가공하고 검사한다. 어느 단계에서 불량이 생겼는지 찾기 쉽다. 속도와 품질을 예측하기도 쉽다.

에이전트는 현장 매니저에 가깝다. 상황을 보고 사람을 부르거나 도구를 쓰거나 고객에게 다시 질문한다. 예외 상황에 강하지만, 매니저의 판단이 흔들리면 결과도 흔들린다.

문서 처리 파이프라인은 워크플로에 가깝다. 문서 업로드, 텍스트 추출, 항목 추출, 요약, 승인이라는 순서가 있다. 중간 판단은 필요하지만 큰 흐름은 고정할 수 있다.

고객지원 에이전트는 에이전트 패턴에 가깝다. 사용자가 무엇을 원하는지 모른 채 대화가 시작된다. 질문이 모호하면 추가 질문을 해야 하고, 계정 조회가 필요하면 도구를 호출해야 한다. 환불처럼 민감한 작업은 사람 승인으로 넘겨야 한다.

실제 서비스에서는 둘을 섞는다. 고객지원 시스템도 모든 것을 에이전트에게 맡기지 않는다. 문의 유형 분류는 라우터로 처리하고, 정책 검색은 고정 도구로 처리하고, 환불 실행은 승인 워크플로로 묶는다. 에이전트는 그 사이에서 '무엇을 해야 하는지'를 제한된 범위 안에서 판단한다.

단일 에이전트와 멀티 에이전트 선택 기준

처음에는 단일 에이전트로 시작하는 것이 좋다. 단일 에이전트는 구조가 단순하고 로그를 읽기 쉽다. 실패 원인도 비교적 빨리 찾을 수 있다. 하지만 다음 조건이 나타나면 분리를 검토한다.

1. 컨텍스트 오염이 심해질 때

한 에이전트가 결제 정책, 기술 문서, 법무 기준, 마케팅 문구를 모두 들고 있으면 판단이 흐려질 수 있다. 이때는 역할별로 컨텍스트를 나누는 것이 좋다.

2. 병렬 처리가 가능할 때

서로 독립적인 작업이라면 나누어 동시에 처리할 수 있다. 예를 들어 긴 문서를 여러 섹션으로 나누어 요약하거나, 보안 검토와 문장 교정을 동시에 실행할 수 있다.

3. 도구 수가 너무 많아질 때

한 에이전트가 사용할 수 있는 도구가 20개, 30개로 늘어나면 도구 선택 오류가 증가한다. 이때는 결제 담당, 검색 담당, 문서 담당처럼 도구 묶음을 나누는 편이 낫다.

4. 전문성이 분명히 다를 때

법률 검토와 고객 응대와 데이터 분석은 판단 기준이 다르다. 같은 프롬프트 안에 모두 넣으면 기준이 섞인다. 이 경우 전문 하위 에이전트로 분리하고, 최종 결정은 오케스트레이터가 맡게 할 수 있다.

단, 멀티 에이전트가 항상 더 나은 것은 아니다. 에이전트를 나누면 통신 비용, 지연 시간, 로그 복잡도, 책임 경계 문제가 생긴다. 분리의 이익이 복잡도보다 클 때만 도입한다.

직접 해보는 실습

이번 실습에서는 같은 FAQ 문제를 세 가지 방식으로 설계한다. 코드를 먼저 작성하지 않아도 된다. 먼저 구조를 표로 설계하고, 예상 지연 시간, 비용, 디버깅 난이도를 기록한다.

실습 상황

온라인 강의 서비스의 FAQ 응답 시스템을 만든다고 가정하자. 사용자는 다음과 같은 질문을 한다.

• 수강 기간은 어디서 확인하나요?

• 결제 영수증을 받을 수 있나요?

• 강의 영상이 재생되지 않습니다.

• 환불은 어떻게 신청하나요?

• 기업 단체 수강도 가능한가요?

FAQ 데이터는 이미 있다고 가정한다. 목표는 사용자의 질문에 적절한 FAQ 답변을 제공하는 것이다.

방식 A: 순차 체인

다음 단계로 설계한다.

1. 질문 정리: 사용자 질문에서 핵심 의도를 한 문장으로 정리한다.

2. FAQ 검색: 관련 FAQ 후보를 3개 찾는다.

3. 답변 생성: 가장 관련 있는 항목을 바탕으로 답변한다.

4. 검증: FAQ에 없는 내용을 지어내지 않았는지 확인한다.

5. 최종 출력: 짧고 친절한 답변을 제공한다.

기록할 항목은 다음과 같다.

방식 B: 라우터

먼저 문의 유형을 분류한다.

• 수강 정보

• 결제/영수증

• 기술 장애

• 환불

• 기업 문의

• 기타/사람 연결

각 유형마다 다른 프롬프트와 FAQ 범위를 사용한다. 예를 들어 환불 문의는 환불 정책 FAQ만 검색하고, 기술 장애는 재생 문제 해결 절차를 우선 안내한다.

이 방식의 장점은 답변 범위를 좁힐 수 있다는 점이다. 단점은 처음 분류가 틀리면 잘못된 경로로 간다는 점이다.

방식 C: 단일 에이전트

단일 에이전트에게 다음 권한을 준다.

• 사용자 의도 파악

• FAQ 검색 도구 사용

• 추가 질문 여부 판단

• 답변 생성

• 필요 시 사람 상담으로 전환

이 방식은 유연하다. 사용자가 '결제했는데 영상이 안 나와요'처럼 복합 질문을 해도 처리하기 쉽다. 하지만 도구 호출이 늘 수 있고, 같은 질문에도 매번 다른 경로를 선택할 수 있다.

실습 결과 비교표

세 방식에 대해 다음 표를 채워보자.

마지막으로 세 방식 중 하나를 선택하고 이유를 짧게 적어보자. 중요한 것은 가장 멋진 구조를 고르는 것이 아니다. 현재 요구사항에서 가장 단순하게 운영 가능한 구조를 고르는 것이다.

흔한 실수와 오류 분석

실수 1: 처음부터 멀티 에이전트로 시작한다

하위 에이전트를 많이 만들면 전문적인 시스템처럼 보인다. 하지만 초기에 로그가 복잡해지고 실패 원인을 찾기 어려워진다. 먼저 단일 체인이나 단일 에이전트로 시작하자. 반복되는 실패가 확인되면 그때 분리한다.

실수 2: 라우터에 너무 많은 분류를 넣는다

분류 항목이 많을수록 라우터의 부담이 커진다. 처음에는 큰 범주로 나누고, 데이터가 쌓이면 세분화한다. '기타'와 '사람 연결' 경로를 두는 것도 중요하다.

실수 3: 평가 기준 없이 evaluator를 붙인다

평가자가 있다고 품질이 자동으로 좋아지지 않는다. 평가 기준이 구체적이어야 한다. 예를 들어 '친절한가?'보다 '사용자의 다음 행동을 한 가지 이상 안내했는가?'가 더 좋은 기준이다.

실수 4: 에이전트에게 너무 많은 도구를 준다

도구가 많아지면 선택 오류가 늘어난다. 에이전트에게 모든 도구를 주기보다 상황별로 사용할 수 있는 도구 목록을 제한하자. 결제 문의를 처리할 때 문서 편집 도구가 필요하지 않다면 숨기는 편이 낫다.

실수 5: 실패 경로를 설계하지 않는다

좋은 시스템은 성공 경로만 설계하지 않는다. 검색 결과가 없을 때, 사용자 질문이 모호할 때, 정책상 답변할 수 없을 때, 도구 호출이 실패했을 때의 경로가 있어야 한다. 실패 경로가 없으면 에이전트는 그럴듯한 답을 만들어낼 가능성이 커진다.

요약

워크플로 패턴은 순서가 정해진 작업에 강하다. 입력과 출력이 명확하고, 실패 지점을 추적하기 쉽다. 문서 처리, 승인 절차, 정형 데이터 추출처럼 예측 가능한 업무에 적합하다.

에이전트 패턴은 실행 중 판단이 필요한 작업에 강하다. 사용자의 요청이 다양하고, 도구 선택과 추가 질문이 필요한 상황에 적합하다. 고객지원, 리서치 보조, 복합 업무 자동화에 잘 맞는다.

하지만 모든 문제를 에이전트로 풀 필요는 없다. 운영 가능한 시스템은 보통 워크플로와 에이전트성을 섞는다. 고정할 수 있는 것은 고정하고, 판단이 필요한 부분만 열어둔다. 단순한 구조를 먼저 배포하고, 로그를 관찰한 뒤 복잡도를 올리는 것이 안전한 설계 원칙이다.

퀴즈

1. 워크플로 패턴이 에이전트 패턴보다 적합한 상황은 무엇인가?

2. 라우터 패턴에서 가장 중요한 실패 지점은 무엇인가?

3. Prompt chaining에서 앞 단계 오류가 위험한 이유는 무엇인가?

4. Evaluator-optimizer 패턴을 사용할 때 평가 기준은 어떤 형태여야 하는가?

5. 단일 에이전트를 멀티 에이전트로 분리할지 판단할 때 고려할 기준 네 가지는 무엇인가?

6. 고객지원 시스템에서 모든 작업을 에이전트에게 맡기지 않고 워크플로와 섞어야 하는 이유는 무엇인가?

체크리스트

• 작업 순서가 고정되어 있는지 확인했다.

• 실행 중 판단이 필요한 지점을 구분했다.

• 입력, 출력, 실패 지점을 단계별로 적었다.

• 라우터가 필요하다면 fallback 경로를 설계했다.

• 병렬 처리할 작업과 병합 기준을 분리해 적었다.

• evaluator의 평가 기준을 구체적으로 정의했다.

• 단일 에이전트로 시작할 수 있는지 먼저 검토했다.

• 멀티 에이전트 분리 이유가 컨텍스트, 병렬성, 도구 수, 전문성 중 어디에 해당하는지 확인했다.

• 지연 시간, 비용, 디버깅 난이도를 비교했다.

• 실패했을 때 사람에게 넘기는 경로를 설계했다.

다음 장 연결

이번 장에서는 에이전트형 패턴과 워크플로 패턴을 구분했다. 다음 장에서는 에이전트가 실제로 외부 기능을 실행하는 방법을 다룬다. 핵심은 tool use와 function calling이다. 모델이 단순히 답변을 생성하는 것을 넘어 검색, 계산, 조회, 저장 같은 작업을 어떻게 호출하는지 살펴본다. 이때도 원칙은 같다. 도구를 많이 붙이는 것이 목표가 아니라, 필요한 도구를 안전하게 선택하고 검증 가능한 방식으로 실행하게 만드는 것이 목표다.