AI 에이전트 엔지니어링 | 5강. 오케스트레이션

⏱ 00:19오케스트레이션은 사용자 요청을 모델·도구·데이터베이스와 조율하고, 계획·실행·컨텍스트 구성을 결정하는 과정이다. 반사형은 입력과 행동을 직접 연결하며, ReAct는 추론·행동·결과 확인을 반복한다. 계획 후 실행은 플래너와 실행기를 분리해 디버깅과 비용 관리를 돕는다. 쿼리 분해는 X와 Y의 수명을 각각 검색해 비교하듯 하위 질문으로 근거를 모으고, 성찰형은 오류를 수정하거나 롤백한다. 심층 리서치는 계획·분해·ReAct를 결합하지만 비용과 시간이 늘어난다.

⏱ 06:47도구 선택은 명확한 이름과 설명을 사용하는 표준 방식, 설명의 임베딩을 검색하는 시맨틱 방식, 역할별 그룹 안에서 고르는 계층적 방식으로 나뉜다. 계산 실습은 울프럼 알파로 3.15 × 12.25 = 38.5875를 얻는다. 도구 실행 전에는 파라미터와 타입을 확인한다. 고객 문의 사례처럼 독립적인 조회는 병렬로 처리하고, 서비스 로그→유사 티켓→지원 정책처럼 이전 결과가 필요한 작업은 체인으로 연결한다.

⏱ 15:26LCEL은 선형 흐름에, LangGraph의 StateGraph와 조건부 엣지는 분기·병합에 적합하다. 인보이스·환불과 기술 지원을 분기하고 요약 노드에서 통합하는 실습이 이를 보여 준다. 컨텍스트는 관련성·명료성·토큰 최적화·동적 조립을 기준으로 구성한다. 지연과 정확도, 액션 수, 결과에 따른 계획 적응을 평가하고 계획·비계획 방식을 비교하여, 요구를 충족하는 가장 단순한 설계부터 복잡도를 늘린다.

⏱ 00:02안녕하세요. AI 에이전트 엔지니어링 5장, 오케스트레이션을 시작하겠습니다. 앞서 말씀드렸듯이 오케스트레이션은 단순히 도구의 호출 순서만 정하는 일이 아니라, 컨텍스트를 어떻게 구성하고 계획하고 실행할지를 결정하는 과정입니다. 사용자의 요청을 파운데이션 모델, 외부·로컬 도구, 데이터베이스가 각자의 역할에 맞게 조율하여 처리하는 것을 오케스트레이션이라고 부릅니다. 사용자가 요청을 보냈을 때 모델이 어떤 작업을 해야 할지 판단하고 해당 작업으로 보내는 과정을 살펴보시면 됩니다.

⏱ 00:38아주 단순한 작업이라면 도구 하나와 최소한의 컨텍스트만으로도 충분히 처리할 수 있습니다. 반면 워크플로우가 상당히 복잡하다면 계획을 세우고, 메모리도 검색하고, 컨텍스트도 그때그때 다르게 조합해야 합니다. 이런 과정에서 오케스트레이션이 필요한 에이전트에는 어떤 것들이 있는지 알아보기 위해 먼저 에이전트의 유형을 살펴보겠습니다. 에이전트는 주로 무엇을 해야 하느냐에 따라 달라집니다. 추론해야 할 수도 있고, 계획해야 할 수도 있고, 행동해야 할 수도 있으며, 어떤 방식을 취하느냐에 따라 접근 방식이 상당히 달라집니다.

⏱ 01:27에이전트에는 반사형 에이전트, 리액트(ReAct) 에이전트, 계획 후 실행 에이전트, 쿼리 분해 에이전트, 성찰형 에이전트, 심층 리서치 에이전트 등 여러 종류가 있습니다. 추론·계획·행동을 어떻게 구성하고 어떤 접근 방식을 선택하느냐에 따라 유형이 결정됩니다. 선택한 유형에 따라 시스템을 어떻게 설정할지도 결정되며, 성능과 비용, 기능 역시 달라집니다. 따라서 해결하려는 문제와 수행하려는 작업이 무엇인지 먼저 파악하면 그 조건에 맞는 에이전트를 설계할 수 있습니다.

⏱ 02:10첫 번째 유형은 반사형 에이전트입니다. 입력과 행동을 직접 매핑해 두는 방식으로, 이런 입력이 들어오면 이렇게 행동하라고 정해 두었기 때문에 추론이 필요 없습니다. 원하는 질문에 바로 답변할 수 있으므로 키워드 정리, 단순 조회, 간단한 자동화에 사용하며 큰 모델도 필요하지 않습니다. 다음은 가장 많이 사용하는 유형인 리액트 에이전트입니다. 추론과 행동을 반복하면서 다음에 무엇을 해야 할지 판단하고, 그에 맞는 도구를 호출합니다. 결과를 확인한 뒤 계획을 갱신하고 다음 행동을 정합니다. 탐색형 워크플로우, 트러블슈팅, 동적 데이터 분석에 사용하는 방식입니다.

⏱ 03:07계획 후 실행 에이전트에서는 플래너(planner)와 실행기(executor)가 계획 단계와 실행 단계를 분리합니다. 먼저 작업을 명확하게 분해합니다. 어떤 계획을 통해 어떤 실행을 했는지 확인할 수 있기 때문에 디버깅이 편합니다. 또한 큰 모델은 계획만 담당하도록 둘 수 있으므로 비용을 아주 효율적으로 관리할 수 있습니다.

⏱ 03:33쿼리 분해 에이전트는 복잡한 질문을 여러 하위 질문으로 반복해서 분해합니다. 예를 들어 “X라는 사람과 Y라는 사람 중 누가 더 오래 살았지?”라는 질문이 들어왔다고 해 보겠습니다. 에이전트는 이를 “X는 몇 년 동안 살았지?”, “Y는 몇 년 동안 살았지?”로 쪼갭니다. X가 몇 년 동안 살았는지는 검색 도구를 호출하여 파악하고, Y도 마찬가지로 처리합니다. 이렇게 쿼리를 분해하여 각각 도구를 호출하고 두 사람의 수명을 확인한 뒤 비교하면 “Y가 더 오래 살았다”는 식으로 결론을 낼 수 있습니다. 외부 지식 검색이 필요한 상황에서 효과적으로 사용할 수 있으며, 사용자의 요청에 대한 답변이 도구의 출력에 근거하도록 할 수 있습니다.

⏱ 04:38성찰형 에이전트는 성찰 및 메타추론을 수행합니다. 앞에서 살펴본 리액트의 추론 후 행동 과정에 더하여, 이전 행동이 제대로 된 결과를 냈는지 확인합니다. 실수를 찾아 수정하고 다시 개선하는 것입니다. 자신이 한 행동이 문제 해결에 얼마나 가까워졌는지, 문제가 되는 것은 없었는지 확인한 뒤 지속적으로 수정하므로 정확성이 더 높은 에이전트가 됩니다. 금융이나 의료, 사고 대응에 적합합니다. 행동마다 성찰 단계를 넣을 수 있어 도구가 출력한 값과 에이전트가 한 행동이 전혀 다르면 이를 감지하고 롤백할 수 있습니다. 이런 메타추론 단계가 있어 메타추론 에이전트라고도 부르며, 더 안정적인 결과를 낼 수 있다고 생각하시면 됩니다.

⏱ 06:00심층 리서치는 ChatGPT나 상용 에이전트를 사용하는 분들이 많이 보셨을 것입니다. 아주 복잡한 과제를 전문적으로 해내는 에이전트입니다. 어떻게 일할지 계획을 짜고, 그 계획에 맞춰 쿼리를 분해한 다음, 분해한 쿼리를 기준으로 리액트 루프를 만듭니다. 학술 문헌이나 서베이, 기술 실사, 경쟁 정보 분석 등에 적합합니다. 다만 그만큼 비용이 많이 들고 시간도 오래 걸립니다. 여기까지의 에이전트 유형은 표에 전체적으로 정리되어 있습니다. 앞서 이 에이전트들이 도구를 선택한다고 말씀드렸으니, 이제 어떤 식으로 도구를 선택하는지 살펴보겠습니다.

⏱ 06:47먼저 표준 선택입니다. 앞에서 살펴본 도구 사용과 같은 방식으로, 구현이 아주 단순하고 퓨샷(few-shot) 학습도 가능합니다. 대신 도구가 많아지면 무엇을 골라야 할지 몰라 확장성이 저하될 수 있습니다. 따라서 모델이 선택하기 편하도록 도구에 간결하고 명확한 이름과 설명을 달아 주어야 합니다. 어떤 도구를 사용할지 판단하는 데 이름과 설명이 쓰이므로, 이를 명확하게 작성해 두는 것이 필요합니다.

⏱ 07:10예시를 살펴보겠습니다. 울프럼 알파(Wolfram Alpha)의 앱 ID 환경 변수가 필요합니다. 슬랙 봇 토큰도 여기서 선언하지만, 이번에는 슬랙 봇을 실제로 사용하지 않으므로 우선 울프럼 알파만 있으면 됩니다. 울프럼 알파의 앱 ID는 products.wolframalpha.com/api에서 발급할 수 있습니다. API 접속하기를 누르고 ID를 생성한 뒤 확인합니다. 그렇게 발급한 값을 입력하고 환경 설정 파일인 .env 파일로 저장하면 됩니다.

⏱ 07:45베이직 스킬 셀렉션(Basic Skill Selection)을 보겠습니다. 앞에서 했던 것과 같습니다. 먼저 도구를 선언합니다. 울프럼 알파에 질의를 보내 계산하거나 정보를 조회하는 도구라고 설명을 달고 구현해 둡니다. 아래에는 재피어(Zapier)와 슬랙(Slack) 도구의 선언도 있습니다. 울프럼 알파를 호출하는 도구, 재피어를 실행하는 도구, 슬랙 메시지를 보내는 도구, 이렇게 세 가지를 구분해 선언한 것입니다. LLM을 초기화하면서 이 도구들을 함께 지정합니다. 지정한 슬랙 채널에 메시지를 보내거나, 울프럼 알파에 질의를 보내 식을 계산하거나, 재피어를 실행하도록 구성합니다.

⏱ 08:37질문은 “3.15 × 12.25는 얼마인가요?”입니다. LLM이 이 질문을 보고 어떤 도구를 쓸지 판단합니다. 실행해 보면 울프럼 알파 도구가 선택되고, 계산식(expression)으로 3.15와 12.25를 전달합니다. 도구는 38.5875를 출력하며, 최종적으로 “3.15 × 12.25는 38.5875입니다”라는 결과가 나옵니다. 질문에 맞는 도구를 선택하고 그 도구에 계산할 값을 전달한 다음, 반환된 결과로 답변하는 과정을 확인할 수 있습니다.

⏱ 09:08다음은 시맨틱 도구 선택입니다. 사용할 도구가 많을 때 사용하는 방식입니다. 도구들을 시맨틱하게 인덱싱하고, 시맨틱 검색으로 가장 관련성이 높은 도구를 가져옵니다. 이를 위해 도구 설명을 모두 모아 임베딩을 진행하고 벡터화합니다. 나중에 필요한 도구가 생기면 요청에 맞춰 검색하여 선택하는 방식입니다. 도구의 설명을 벡터로 표현해 두었다가 관련성을 기준으로 찾는다고 보시면 됩니다.

⏱ 09:37그림 5.2를 보시면 진행 과정을 알 수 있습니다. 각 도구나 스킬을 임베딩 모델로 벡터 표현으로 인코딩한 뒤, 효율적인 시맨틱 검색을 위해 저장해 둡니다. 시스템은 쿼리를 기준으로 가장 관련성 높은 도구를 검색하여 선택합니다. 예를 들어 사용자가 “이 방정식을 풀어 줘. 2x + 3 = 7이야”라고 요청하면, 그 요청으로 상위 도구를 조회합니다. 조회한 도구들을 바탕으로 파운데이션 모델이 적절한 도구와 파라미터를 결정하고, 해당 도구를 호출합니다. 이 방식도 예시 코드가 있습니다. 시맨틱 스킬 셀렉션(Semantic Skill Selection) 파일을 실행해 보시면 됩니다.

⏱ 10:27다음은 계층적 선택입니다. 도구를 역할에 따라 그룹으로 조직한 뒤, 먼저 그룹을 선택하고 그 안에서 도구를 고르는 방식입니다. 수식을 계산해야 한다면 울프럼 알파와 단순 계산기 같은 도구를 한 그룹에 모아 둘 수 있습니다. 수식이 들어오면 수식 처리 도구들의 그룹으로 보내고, 그중에서 적절한 도구를 선택해 해결합니다. 시맨틱하게 유사한 도구가 많을 때 정확도를 높일 수 있습니다. 계산기와 울프럼 알파가 함께 있는 상황에서 방정식이 들어오면, 단순 계산기로는 어렵기 때문에 울프럼 알파로 해결하겠다고 판단할 수 있습니다. 아주 많은 도구가 있거나 비슷한 도구가 있을 때 권장하는 방식입니다.

⏱ 11:31도구를 실행할 때는 파라미터를 설정합니다. 여기 표기에는 FM이라고 적혀 있는데, LLM이 도구 정의에 맞게 파라미터를 설정하고 필요한 타입이 맞는지 확인한 다음 도구를 실행하는 것입니다. 앞에서 보았던 함수 실행과 같다고 생각하시면 됩니다. 파라미터를 설정하면 도구가 실행되고, API 호출 등을 통해 결과를 돌려받습니다. 에이전트는 그 결과를 이용하여 문제를 해결하는 방식으로 진행합니다.

⏱ 12:03다음은 도구 토폴로지입니다. 복잡한 작업을 해야 할 때 도구를 어떻게 배치할지를 정하는 것으로, 에이전트가 사용할 수 있는 도구와 그 조합을 설정하는 방식이라고 생각하시면 됩니다. 일반적으로 가장 많이 쓰는 것은 단일 도구 실행입니다. 도구 하나에 맞는 파라미터를 설정하고 실행한 다음 응답하는 방식입니다. 지금까지 계속 보셨던 형태이므로 익숙하실 것입니다. 다음은 병렬 실행으로, 여러 도구를 한 번에 동시에 실행하는 경우입니다.

⏱ 12:52책에서는 고객의 요청 사항을 어떻게 처리할지에 관한 상황을 예로 듭니다. 그림을 보겠습니다. 빅터 하트라는 고객이 남긴 문의 1237번을 처리해야 합니다. “이 요청을 어떻게 처리해야 할까요?”라는 문제를 오케스트레이션에 넘기면, 어떤 방식으로 처리할지 판단합니다. 먼저 빅터 하트가 누구인지, 1237번 요청의 내용이 무엇인지, 과거의 비슷한 상황은 어떻게 처리했는지 등을 확인해야 합니다.

⏱ 13:31고객 정보와 주문 정보, 문의 내용은 각자 별개로 확인할 수 있습니다. 따라서 고객 상세 정보와 고객 주문 이력, 고객 서비스 로그의 티켓 정보를 가져올 수 있습니다. 비슷한 문의가 있었다면 유사한 티켓을 가져오고 관련 지원 정책도 확인할 수 있습니다. 다만 고객 서비스 로그, 유사 티켓, 관련 지원 정책이라는 세 작업은 서로 연관됩니다. 먼저 이 티켓이 무엇인지 알아야 유사한 일이 있었는지 찾을 수 있고, 이어서 관련 정책을 확인할 수 있기 때문입니다. 이 세 작업을 모두 병렬로 돌리기는 어렵습니다. 크게 보면 고객 상세 정보 조회, 고객 주문 이력 조회, 서비스 로그에서 유사 티켓과 정책을 확인하는 작업이라는 세 갈래가 병렬로 돌아간다고 볼 수 있습니다.

⏱ 14:32도구 실행 과정에서 이어서 살펴볼 것은 체인과 그래프입니다. 체인은 랭체인(LangChain)을 생각하시면 됩니다. 작업을 순차적으로 실행하므로 각 단계가 이전 결과에 의존합니다. 앞의 그림을 다시 보면 고객 서비스 로그를 가져오고, 유사 티켓을 가져오고, 관련 지원 정책을 가져오는 작업들이 연관되어 있습니다. 앞의 내용을 알아야 다음 내용을 확인할 수 있는 것입니다. 각 단계가 이전 결과에 의존하는 이 일련의 작업을 하나의 체인으로 볼 수 있습니다.

⏱ 15:09그래프는 조건부 분기와 병합이 있는 비선형 워크플로우를 모델링할 때 많이 사용합니다. 다양한 작업을 해야 하고 분기가 나뉠 때 그래프를 사용하는 것이 좋습니다. 체인은 랭체인의 LCEL이라는 언어로 구성합니다. 프롬프트를 LLM으로 넘기는 파이프 연산자를 활용하며, 일관되게 이어지는 선형 워크플로우에 적합합니다. 이런 워크플로우에서도 최대 길이를 미리 정해 두고 진행하는 것이 좋습니다.

⏱ 15:48그래프는 랭그래프(LangGraph)를 이용하여 구현합니다. 지금까지 살펴본 랭체인 과정에서의 그래프는 StateGraph로 구현합니다. 조건부 엣지(conditional edge)로 분기를 설정하며, 각 경로가 요약 노드로 수렴할 수 있도록 정리해야 합니다. 체인으로 충분하면 체인을 사용하고, 분기가 많이 나뉜다면 그래프를 사용하는 편이 좋습니다. 작업의 흐름을 보고 순차적인 연결로 충분한지, 조건에 따라 다른 경로로 보내야 하는지를 판단하시면 됩니다.

⏱ 16:18예시 코드로 체인의 아주 기본적이고 간단한 형태를 보겠습니다. LLM과 프롬프트가 있고, 프롬프트를 받으면 LLM으로 넘기는 체인을 구성합니다. 이 체인에 “프랑스의 수도는 어디인가요?”라는 프롬프트를 입력하면, 프롬프트가 LLM으로 전달되고 답변이 나오는 형태입니다. 예제를 실행하면 결과가 나오는 데 조금 시간이 걸립니다. 실행 결과로 “프랑스의 수도는 파리입니다”라는 답변이 나옵니다.

⏱ 16:57랭그래프 예시에서는 먼저 노드를 정의합니다. 지원 요청이 들어오면 비용 문제인지 기술 문제인지 판단하는 코드가 있습니다. 비용 문제이면 billing으로, 기술 문제이면 technical로 전달하며, 둘 다 아니면 technical로 넘기도록 설정합니다. 각 경우에 맞는 도구도 설정합니다. 비용 문제에서는 세부 정보를 조회하고 환불 워크플로우를 수행합니다. 기술 문제에서는 로그인 문제를 해결하고 성능 지표를 확인합니다. 그런 다음 결과를 통합하는 summarize_response를 하나 더 만들고 그래프를 구성합니다.

⏱ 17:41그래프 빌더에서 먼저 StateGraph를 설정하고 노드를 추가합니다. 이슈를 분류하는 categorize_issue 노드를 만들고, 다른 노드들도 하나씩 추가합니다. 이어서 하나씩 연결합니다. START 기점에 엣지를 추가하여 이슈를 분류하는 노드로 보내고, 분류 결과가 billing인지 technical인지에 따라 다음에 어디로 갈지 연결합니다. 라우터의 결과를 조건부 엣지로 연결하여 비용 문제는 billing으로, 기술 문제는 technical로 보냅니다. billing인 경우에는 인보이스를 확인하는 단계로, technical 이슈인 경우에는 로그인 문제를 처리하는 단계로 분기하도록 설정합니다. 이렇게 하위 분기까지 구성한 뒤 그래프를 컴파일하고 실행합니다.

⏱ 18:48사용자가 남긴 질문은 “인보이스와 환불 관련 도움을 받고 싶습니다”입니다. 이 요청을 처리하는 과정을 그림으로 나타내면 시작 지점에서 이슈를 분류하고 billing 또는 technical로 나뉩니다. 이후 인보이스나 로그인 문제를 처리하고, 환불을 비롯한 작업을 마친 뒤 summarize_response로 보냅니다. 인보이스와 환불을 도와 달라는 요청이라면 그림의 경로에 따라 인보이스를 먼저 처리하고 환불로 넘어가는 방식입니다.

⏱ 19:33터미널을 열어 CH04의 랭그래프 파일을 실행해 보겠습니다. 실행하면 요청한 청구서를 보내겠다는 안내와 받는 방식 및 수신 내용에 관한 메시지, 처리하겠다는 답변과 “감사합니다”라는 메시지가 나옵니다. 자막에는 “요청하신 뉴 1 2 3 4 청구성을 보내 드리겠습니다”, “받으실 방식과 수심 내용을 어떻게 할지”, “1일로 처리하겠습니다. 감사합니다”로 기록되어 있습니다. 청구서 번호의 정확한 표기와 수신 관련 문구, 처리 방식은 자막만으로 명확하게 확인되지 않습니다. 이처럼 요청에 따라 그래프의 작업이 처리되는 것을 볼 수 있습니다.

⏱ 19:57다음은 컨텍스트 엔지니어링입니다. 오케스트레이션에서 상당히 중요한 역할을 합니다. 각 오케스트레이션 단계에 필요한 정보와 지침을 올바르게, 동적으로 조합하는 작업을 컨텍스트 엔지니어링이라고 부릅니다. 프롬프트 엔지니어링이 어떤 것을 쓰고 어떤 결과를 받을지를 결정한다면, 컨텍스트 엔지니어링은 어떤 정보를 바탕으로 모델이 답을 내게 할지를 결정하는 것이라고 보시면 됩니다.

⏱ 20:28컨텍스트는 어떻게 설정해야 할까요? 먼저 관련성을 우선하여 정보를 정리하고, 가장 유용한 정보만 선택적으로 검색해야 합니다. 또한 명료해야 합니다. 구조화된 포맷을 사용해 예측 가능한 형태로 전달해야 합니다. 토큰 최적화도 필요합니다. 긴 히스토리는 요약하고 불필요한 표현을 제거하여 꼭 필요한 정보만 전달하면 됩니다. 마지막으로 동적인 조립이 필요합니다. 매 단계에서 현재 목표에 맞도록 컨텍스트를 다시 구성해 전달해야 합니다.

⏱ 20:58오케스트레이션을 설계할 때는 시스템의 지연 시간과 정확도 사이의 트레이드오프를 신중하게 검토해야 합니다. 시나리오에서 보통 필요한 액션 수를 파악하여 복잡도를 결정하고, 이전 결과에 따라 계획이 얼마나 잘 적응했는지도 평가해야 합니다. 대표적인 사례를 사용하여 다양한 계획 접근 방식과 비계획 접근 방식을 비교하고 평가해야 합니다. 요구 사항을 충족하는 가장 단순한 방식을 선택하고, 필요할 때 점진적으로 복잡도를 키워야 한다는 점을 알아 두시면 좋겠습니다. 지금까지 오케스트레이션을 살펴보았습니다.