LLM 에이전트 시대의 오케스트레이션: 여러 작업과 도구를 하나의 흐름으로 연결하기

이전 글에서는 하네스 엔지니어링(Harness Engineering)에 대해 정리했다.

하네스는 LLM 에이전트가 안전하게 실행될 수 있도록 도구, 권한, 상태, 검증, 로그, 실패 복구를 관리하는 실행 틀이다.

쉽게 말하면 하네스는 에이전트 하나가 안전하게 일할 수 있도록 감싸는 구조라고 볼 수 있다.

이번 글에서는 그다음 단계인 오케스트레이션(Orchestration)에 대해 정리해보려고 한다.

하네스가 “한 명의 작업자가 안전하게 일할 수 있도록 만든 장비와 규칙”이라면, 오케스트레이션은 “여러 작업자와 도구를 어떤 순서로 움직일지 정하는 운영 방식”에 가깝다.

1. 오케스트레이션이란?

오케스트레이션은 원래 여러 악기 연주를 하나의 음악으로 조율한다는 의미에서 나온 말이다.

LLM 에이전트 문맥에서도 비슷하게 볼 수 있다.

단순한 LLM 호출과 다르게 실제 업무 자동화나 에이전트 시스템은 훨씬 복잡하다.

이처럼 여러 단계를 어떤 순서로 실행할지, 각 단계의 결과를 다음 단계로 어떻게 넘길지, 실패했을 때 어떻게 처리할지를 설계하는 것이 오케스트레이션이다.

한 문장으로 정리하면 다음과 같다.

오케스트레이션은 LLM 에이전트가 여러 작업, 도구, 에이전트를 하나의 흐름으로 연결해 목표를 달성하도록 만드는 설계 방식이다.

 

2. 왜 오케스트레이션이 필요할까?

처음 LLM을 사용할 때는 단순히 질문하고 답변을 받는 것만으로도 충분했다.

예를 들어 다음과 같은 요청은 단일 LLM 답변으로 처리할 수 있다.

이 문장을 영어로 번역해줘.

또는

이 개념을 쉽게 설명해줘.

하지만 실제 업무에서는 하나의 답변으로 끝나지 않는 경우가 많다.

예를 들어 사용자가 이렇게 요청했다고 해보자.

이번 주 회의록을 기반으로 주요 이슈를 정리하고, 관련 문서를 찾아서 보고서 초안을 만들어줘.

이 요청은 여러 작업으로 나뉜다.

회의록 찾기
회의록 내용 읽기
주요 이슈 추출
관련 문서 검색
문서 내용 요약
보고서 구조 생성
초안 작성
최종 검토

여기서 LLM은 한 번의 답변만으로 모든 것을 안정적으로 처리하기 어렵다.

각 작업은 서로 다른 도구와 판단이 필요하다.

검색 도구
문서 읽기 도구
요약 기능
분류 기능
보고서 작성 기능
검증 기능

이 도구들을 어떤 순서로 실행할지 정하지 않으면 에이전트는 중간에 길을 잃기 쉽다.

예를 들어 다음과 같은 문제가 생길 수 있다.

필요한 문서를 검색하지 않고 답변한다.
중요한 단계를 건너뛴다.
같은 검색을 반복한다.
앞 단계 결과를 다음 단계에서 제대로 활용하지 못한다.
실패했는데도 다음 단계로 넘어간다.
최종 결과가 요구사항과 맞지 않는다.

그래서 복잡한 작업을 처리하려면 전체 흐름을 조율하는 구조가 필요하다.
이것이 오케스트레이션이 필요한 이유다.

3. 하네스와 오케스트레이션의 차이

하네스와 오케스트레이션은 함께 쓰이는 개념이라 헷갈릴 수 있다.

둘의 차이를 간단히 정리하면 다음과 같다.

 

하네스는 에이전트가 도구를 안전하게 사용하게 만든다.

이 파일을 수정해도 되는가?
이 도구를 실행할 권한이 있는가?
결과가 조건을 만족하는가?
실패하면 재시도할 것인가?

반면 오케스트레이션은 전체 작업 흐름을 설계한다.

먼저 무엇을 해야 하는가?
다음 단계는 무엇인가?
어떤 에이전트가 이 작업을 맡을 것인가?
앞 단계 결과를 어디로 넘길 것인가?
언제 최종 응답을 생성할 것인가?

즉, 하네스가 “안전하게 실행하기 위한 틀”이라면, 오케스트레이션은 “목표를 달성하기 위한 작업 흐름”이다.

 

4. 오케스트레이션의 기본 구조

오케스트레이션은 보통 다음과 같은 흐름으로 구성된다.

사용자 요청
  ↓
작업 분석
  ↓
계획 수립
  ↓
작업 분해
  ↓
도구 또는 에이전트 실행
  ↓
중간 결과 수집
  ↓
검증
  ↓
최종 결과 생성

예를 들어 보고서 작성 에이전트를 만든다고 해보자.

사용자 요청은 다음과 같다.

최근 AI Agent 관련 자료를 조사해서 블로그 글 초안을 작성해줘.

오케스트레이션 구조는 이렇게 나눌 수 있다.

1. 주제 분석
2. 자료 검색
3. 핵심 내용 정리
4. 글 구조 설계
5. 초안 작성
6. 문체 수정
7. 최종 검토

각 단계는 하나의 에이전트가 모두 처리할 수도 있고, 여러 에이전트가 나누어 처리할 수도 있다.

Planner Agent: 전체 계획 수립
Research Agent: 자료 검색
Writer Agent: 글 작성
Reviewer Agent: 검토 및 수정

이렇게 역할을 나누면 복잡한 작업을 더 체계적으로 처리할 수 있다.

5. 오케스트레이션의 대표 패턴

오케스트레이션에는 여러 방식이 있다.
여기서는 이해하기 쉬운 대표 패턴 몇 가지를 정리해본다.

5.1 순차 실행 패턴

가장 기본적인 방식은 순차 실행이다.

Step 1 → Step 2 → Step 3 → Step 4

예를 들어 문서 요약 작업은 다음처럼 진행될 수 있다.

문서 읽기
  ↓
핵심 문장 추출
  ↓
요약 작성
  ↓
검토

이 방식은 단순하고 이해하기 쉽다.
작업 순서가 명확한 경우에 적합하다.

다만 앞 단계가 실패하면 뒤 단계도 영향을 받는다.
그래서 각 단계마다 검증과 실패 처리가 필요하다.

5.2 라우팅 패턴

라우팅은 사용자의 요청에 따라 적절한 작업 흐름을 선택하는 방식이다.

예를 들어 사용자의 요청이 들어오면 먼저 유형을 분류한다.

사용자 요청
  ↓
요청 유형 분류
  ├─ 문서 질문 → RAG Agent
  ├─ 코드 수정 → Coding Agent
  ├─ 일정 정리 → Calendar Agent
  └─ 보고서 작성 → Writing Agent

이 패턴은 여러 기능을 가진 AI 서비스에서 자주 사용된다.

예를 들어 사용자가 “이 코드 오류 고쳐줘”라고 하면 Coding Agent로 보내고, “이 회의록 요약해줘”라고 하면 Summary Agent로 보내는 식이다.

라우팅이 잘못되면 엉뚱한 에이전트가 작업을 맡게 되므로, 요청 분류가 중요하다.

5.3 병렬 실행 패턴

병렬 실행은 여러 작업을 동시에 진행하는 방식이다.

예를 들어 시장 조사 보고서를 작성한다고 해보자.

사용자 요청
  ↓
동시에 실행
  ├─ 경쟁사 조사
  ├─ 시장 규모 조사
  ├─ 기술 트렌드 조사
  └─ 고객 사례 조사
  ↓
결과 통합

이 방식은 여러 정보를 동시에 수집해야 할 때 유용하다.

장점은 시간이 줄어든다는 점이다.
단점은 결과를 통합하는 과정이 필요하다는 점이다.

각 에이전트가 서로 다른 관점에서 자료를 가져오기 때문에, 마지막에는 중복을 제거하고 하나의 구조로 정리하는 단계가 필요하다.

5.4 검토자 패턴

검토자 패턴은 한 에이전트가 결과를 만들고, 다른 에이전트가 검토하는 방식이다.

Writer Agent
  ↓
Reviewer Agent
  ↓
Final Answer

예를 들어 블로그 글 작성에서는 다음처럼 사용할 수 있다.

Writer Agent: 초안 작성
Reviewer Agent: 논리 흐름 검토
Editor Agent: 문체 수정

코딩 에이전트에서도 비슷하다.

Coding Agent: 코드 수정
Test Agent: 테스트 실행
Review Agent: 변경사항 검토

이 방식은 결과 품질을 높이는 데 도움이 된다.
특히 코드, 보고서, 기획서처럼 검토가 중요한 작업에 적합하다.

5.5 반복 개선 패턴

반복 개선 패턴은 결과가 기준을 만족할 때까지 여러 번 수정하는 방식이다.

초안 생성
  ↓
검토
  ↓
수정
  ↓
다시 검토
  ↓
통과하면 완료

예를 들어 글쓰기 에이전트에서는 다음과 같이 사용할 수 있다.

1차 초안 작성
문장 흐름 검토
부족한 설명 추가
중복 표현 제거
최종본 생성

이 패턴은 품질을 높일 수 있지만, 반복 횟수를 제한하지 않으면 비용과 시간이 늘어날 수 있다.

그래서 보통은 다음과 같은 조건을 둔다.

최대 3회까지 수정
정확도 기준 통과 시 종료
사용자 확인 필요 시 중단

이 조건을 관리하는 것도 오케스트레이션의 일부다.

6. 실제 예시 1: 고객 문의 처리 Agent

오케스트레이션을 이해하기 쉬운 예시 중 하나는 고객 문의 처리 Agent다.

사용자가 고객지원 챗봇에 다음과 같이 문의했다고 해보자.

지난주에 주문한 상품이 아직 도착하지 않았어요.

이 요청에 제대로 답변하려면 단순히 “죄송합니다”라고 답하는 것만으로는 부족하다.
고객의 주문 정보, 배송 상태, 지연 사유, 환불 또는 재배송 가능 여부를 순서대로 확인해야 한다.

오케스트레이션 흐름은 다음과 같이 구성할 수 있다.

각 Agent의 역할은 명확하다.

Intent Classifier	문의가 배송, 환불, 교환, 결제 중 어떤 유형인지 분류
Order Lookup Agent	고객의 주문 내역 확인
Delivery Status Agent	현재 배송 위치와 지연 여부 확인
Policy Check Agent	환불, 재배송, 보상 가능 여부 확인
Response Agent	고객에게 전달할 최종 답변 작성

이 예시에서 오케스트레이션이 중요한 이유는 작업 순서가 틀리면 답변 품질이 떨어지기 때문이다.

예를 들어 주문 내역을 확인하지 않고 배송 지연 안내를 하거나, 정책 확인 없이 환불 가능하다고 답변하면 문제가 생길 수 있다.

잘못된 흐름:
고객 문의 → 일반 답변 생성 → 종료

좋은 흐름:
고객 문의 → 주문 확인 → 배송 확인 → 정책 확인 → 맞춤 답변 생성

즉, 고객 문의 처리 Agent에서 오케스트레이션은 여러 확인 단계를 올바른 순서로 연결해, 고객에게 더 정확하고 신뢰할 수 있는 답변을 제공하도록 돕는다.

7. 실제 예시 2: 시장 조사 보고서 Agent

두 번째 예시는 병렬 작업이 필요한 시장 조사 보고서 Agent다.

사용자가 다음과 같이 요청했다고 해보자.

AI Agent 시장 동향을 조사해서 블로그 글 초안을 작성해줘.

이 작업은 하나의 흐름으로만 처리하기보다, 여러 조사를 동시에 진행한 뒤 결과를 합치는 방식이 더 적합하다.

예를 들어 다음과 같은 항목들을 각각 따로 조사할 수 있다.

시장 규모 조사
경쟁 서비스 조사
기술 트렌드 조사
사용 사례 조사
리스크 및 한계 조사

오케스트레이션 흐름은 다음과 같이 구성할 수 있다.

이 구조에서는 여러 Agent가 동시에 각자의 역할을 수행한다.

Market Research Agent	시장 규모와 성장 흐름 조사
Competitor Research Agent	주요 서비스와 경쟁사 분석
Tech Trend Agent	최신 기술 흐름과 키워드 정리
Use Case Agent	실제 활용 사례 수집
Risk Analysis Agent	한계, 리스크, 도입 시 고려사항 정리
Synthesizer Agent	여러 결과를 하나의 구조로 통합
Writer Agent	보고서 또는 블로그 초안 작성

이 예시에서 핵심은 병렬 실행과 결과 통합이다.

순차적으로 처리하면 다음과 같이 오래 걸릴 수 있다.

시장 조사 → 경쟁사 조사 → 기술 조사 → 사례 조사 → 리스크 조사 → 글 작성

하지만 병렬 구조를 사용하면 여러 조사를 동시에 진행할 수 있다.

시장 조사
경쟁사 조사
기술 조사
사례 조사
리스크 조사

이후 오케스트레이션은 각 Agent가 가져온 결과를 모아 중복을 제거하고, 하나의 글 구조로 정리한다.

예를 들어 각 Agent가 다음과 같은 결과를 가져왔다고 해보자.

시장 규모 조사 결과
경쟁 서비스 목록
주요 기술 키워드
실제 활용 사례
도입 시 주의점

Synthesizer Agent는 이 결과를 하나로 묶어 다음과 같은 구조를 만들 수 있다.

1. AI Agent 시장이 주목받는 배경
2. 주요 기술 트렌드
3. 대표 서비스와 경쟁 구도
4. 실제 활용 사례
5. 도입 시 고려해야 할 점
6. 정리 및 전망

이처럼 병렬 작업이 필요한 경우 오케스트레이션은 단순히 순서를 정하는 것을 넘어, 여러 작업을 동시에 실행하고 결과를 하나로 통합하는 역할을 한다.

즉, 오케스트레이션은 복잡한 업무를 작은 작업으로 나누고, 필요한 경우 병렬로 실행한 뒤, 최종적으로 하나의 완성된 결과물로 합치는 구조라고 볼 수 있다.

8. 오케스트레이션에서 중요한 설계 질문

오케스트레이션을 설계할 때는 다음 질문들을 생각해야 한다.

1) 작업을 어떤 단계로 나눌 것인가?

복잡한 요청을 하나의 큰 작업으로 처리하면 실패하기 쉽다.
따라서 작업을 작은 단위로 나누는 것이 중요하다.

검색
분석
작성
검토
수정
보고

 

2) 어떤 순서로 실행할 것인가?

모든 작업에는 순서가 있다.

문서를 읽기 전에 요약할 수는 없다.
테스트를 실행하기 전에 코드를 수정해야 한다.
고객에게 답변하기 전에 주문 정보를 확인해야 한다.

3) 어떤 에이전트가 어떤 역할을 맡을 것인가?

하나의 LLM Agent가 모든 일을 처리할 수도 있다.
하지만 복잡한 작업에서는 역할을 나누는 것이 더 효과적일 수 있다.

Planner
Researcher
Writer
Reviewer
Executor

역할을 나누면 각 단계의 책임이 명확해진다.

4) 중간 결과를 어떻게 전달할 것인가?

오케스트레이션에서 중요한 것은 데이터 흐름이다.

검색 결과 → 요약 Agent
요약 결과 → Writer Agent
초안 결과 → Reviewer Agent
검토 결과 → Editor Agent

중간 결과가 제대로 전달되지 않으면 뒤 단계의 품질도 떨어진다.

5) 실패하면 어떻게 처리할 것인가?

작업은 항상 성공하지 않는다.

검색 결과가 부족할 수 있다.
도구 호출이 실패할 수 있다.
테스트가 실패할 수 있다.
정책 확인이 불가능할 수 있다.

따라서 실패 시 처리 방식이 필요하다.

재시도
다른 도구 사용
사용자에게 확인 요청
부분 결과만 보고
작업 중단

 

6) 언제 완료로 볼 것인가?

에이전트가 계속 작업만 반복하면 안 된다.
완료 조건이 있어야 한다.

예를 들어 다음과 같은 기준을 둘 수 있다.

필수 항목이 모두 포함되었는가?
테스트가 통과했는가?
검토 단계가 완료되었는가?
사용자 요청 형식에 맞는가?

완료 조건이 명확해야 오케스트레이션 흐름도 안정적으로 끝난다.

9. 오케스트레이션이 약하면 생기는 문제

오케스트레이션이 잘 설계되지 않으면 에이전트는 다음과 같은 문제를 보일 수 있다.

작업 순서가 뒤섞인다.
중요한 단계를 건너뛴다.
같은 작업을 반복한다.
에이전트 간 결과 전달이 불명확하다.
실패했는데도 다음 단계로 넘어간다.
최종 결과가 사용자 요청과 맞지 않는다.

특히 멀티 에이전트 구조에서는 이런 문제가 더 커질 수 있다.

여러 에이전트가 동시에 움직이면 좋아 보이지만, 조율이 없으면 오히려 혼란스러워질 수 있다.

예를 들어 Research Agent가 찾은 자료를 Writer Agent가 제대로 받지 못하거나, Reviewer Agent가 기준 없이 검토하면 최종 결과는 불안정해진다.

그래서 멀티 에이전트 시스템에서는 에이전트 수를 늘리는 것보다, 역할과 흐름을 명확하게 설계하는 것이 더 중요하다.

10. 하네스와 오케스트레이션은 함께 필요하다

하네스와 오케스트레이션은 따로 떨어진 개념이 아니다.

실제로는 함께 작동한다.

오케스트레이션:
- 어떤 순서로 작업할지 결정한다.
- 어떤 에이전트에게 작업을 맡길지 결정한다.
- 중간 결과를 다음 단계로 넘긴다.

하네스:
- 각 에이전트가 안전하게 도구를 사용하게 한다.
- 권한을 확인한다.
- 실행 결과를 검증한다.
- 실패 시 재시도하거나 중단한다.

예를 들어 코딩 자동화 Agent를 생각해보자.

오케스트레이션:
요구사항 분석 → 코드 수정 → 테스트 실행 → 리뷰 → 최종 보고

하네스:
파일 접근 권한 확인, 테스트 실행 관리, 수정 가능 범위 제한, 실패 로그 기록

즉, 오케스트레이션은 전체 흐름을 만들고, 하네스는 각 단계가 안전하게 실행되도록 관리한다.

둘 중 하나만 있어서는 부족하다.

오케스트레이션만 있고 하네스가 없으면, 흐름은 있지만 안전하지 않을 수 있다.
하네스만 있고 오케스트레이션이 없으면, 안전하게 실행은 되지만 복잡한 업무 흐름을 만들기 어렵다.

11. 다음 글에서는 무엇을 볼 수 있을까?

이번 글에서는 오케스트레이션을 개념 중심으로 정리했다.

핵심은 다음과 같다.

작업을 나누고
순서를 정하고
필요한 경우 병렬로 실행하고
중간 결과를 통합하고
실패했을 때 복구하고
최종 결과를 검증하는 것

그렇다면 다음 단계에서는 이런 질문을 던져볼 수 있다.

이런 오케스트레이션을 실제 도구들은 어떻게 구현하고 있을까?

예를 들어 개발자들이 사용하는 AI 코딩 에이전트 도구를 보면 오케스트레이션 개념을 더 구체적으로 이해할 수 있다.

Claude Code
OpenCode
Codex
Cursor

이런 도구들은 단순히 LLM에게 코드를 물어보는 수준을 넘어, 파일을 읽고, 코드를 수정하고, 터미널 명령을 실행하고, 테스트 결과를 확인하며, 때로는 여러 작업을 나누어 처리한다.

즉, 실제 도구 안에는 이미 다음과 같은 오케스트레이션 요소가 들어 있다.

작업 분해
도구 호출
권한 확인
상태 관리
테스트 실행
실패 로그 분석
결과 검토
병렬 작업

다음 글에서는 Claude Code, OpenCode, Codex 같은 도구를 예시로, LLM Agent 오케스트레이션이 실제 개발 환경에서 어떻게 구현되고 있는지 살펴볼 수 있다.

이때 중요한 비교 기준은 “어떤 모델을 쓰는가”만이 아니다.

작업을 어떻게 나누는가?
도구를 어떻게 연결하는가?
권한을 어떻게 관리하는가?
여러 작업을 병렬로 실행할 수 있는가?
작업 이력과 상태를 어떻게 유지하는가?
실패했을 때 어떻게 복구하는가?

이런 관점으로 도구를 비교하면, 단순한 AI 코딩 도구 리뷰를 넘어서 “LLM Agent 시스템이 실제로 어떻게 구성되는가”를 더 잘 이해할 수 있다.

12. 정리

LLM 에이전트가 실제 업무에 사용되기 위해서는 단순히 모델이 좋아야 하는 것만으로는 부족하다.

하나의 에이전트가 안전하게 도구를 사용하려면 하네스가 필요하다.
그리고 여러 작업과 에이전트를 하나의 목표로 연결하려면 오케스트레이션이 필요하다.

정리하면 다음과 같다.

Harness Engineering
= 에이전트 하나를 안전하게 실행시키는 구조

Orchestration
= 여러 작업, 도구, 에이전트를 하나의 흐름으로 연결하는 구조

오케스트레이션의 핵심은 복잡한 작업을 작은 단계로 나누고, 각 단계를 올바른 순서로 연결하며, 중간 결과를 다음 단계로 전달하고, 실패했을 때 적절히 처리하는 것이다.

앞으로 LLM 서비스는 단순한 챗봇을 넘어 점점 더 많은 업무를 자동화하는 방향으로 발전할 가능성이 크다.

이때 중요한 것은 “LLM이 얼마나 똑똑한가”뿐만이 아니다.

어떤 작업 흐름을 설계했는가?
어떤 에이전트에게 어떤 역할을 맡겼는가?
각 단계의 결과를 어떻게 검증했는가?
실패했을 때 어떻게 복구하는가?

이런 질문에 답할 수 있어야 실제로 사용할 수 있는 에이전트 시스템을 만들 수 있다.

하네스가 LLM 에이전트를 안전하게 실행시키는 틀이라면, 오케스트레이션은 그 에이전트들이 함께 일하도록 만드는 흐름이다.

다음 글에서는 이 개념을 실제 AI 코딩 에이전트 도구와 연결해서, Claude Code, OpenCode, Codex 같은 도구들이 작업 흐름을 어떻게 다루는지 살펴보려고 한다.