AI Agent, 진짜 현장에서 쓰려면 오케스트레이션이 필요하다.
"AI Agent 도입하면 뭐가 달라지나요?"
요즘 기업 현장에서 가장 많이 듣는 질문입니다. ChatGPT 이후 생성형 AI에 대한 관심이 폭발적으로 늘었고, 자연스럽게 "우리 업무에도 AI를 붙여보자"라는 요구가 쏟아지고 있죠. 특히나 구글의 NotebookLM과 Gemini 가 다양한 입력 값을 바탕으로 특정한 '내' 업무에서도 충분히 활용될 수 있을 만한 성능을 보여 준 이후 이러한 요구가 더욱 커지고 있는 상황입니다.
그런데 막상 도입을 검토하다 보면 벽에 부딪힙니다. 일반적인 챗봇은 범용적인 대화는 잘하지만, 우리 회사 고유의 업무 로직을 이해하지 못합니다. 예를 들어 상사의 업무 중 하나인 운임산출의 경우 (매우 복잡한 로직과 다양한 정보가 연결되어야 산출이 가능하기 때문에) GPT 나 Gemini 에게 "이 구간 해상 운임이 얼마야?"라는 질문을 던지면 그럴듯한 답을 내놓을 수는 있어도, 실시간 환율, 유가 변동, 선박 크기, 선적물 종류까지 반영한 실무에서 바로 쓸 수 있는 답을 주기는 어렵습니다.
이건 AI의 능력이 부족해서가 아닙니다. 문제의 본질은 설계 방식에 있습니다. 범용 AI 모델에 단순히 프롬프트를 던지는 것과, 업무에 맞게 설계된 AI 시스템을 구축하는 것은 완전히 다른 이야기입니다.
여기서 등장하는 개념이 바로 AI Agent입니다. 단순히 질문에 답하는 수준을 넘어, 스스로 데이터를 조회하고, 계산하고, 판단까지 수행하는 자율적인 AI 시스템이죠. Agent는 사전에 정의된 도구(tool)와 데이터 소스에 접근하면서, 주어진 목표를 달성하기 위해 스스로 다음 행동을 결정합니다. 이 때 해당 소스와 정의된 도구는 "내" 업무에 맞춘, 즉 특정 업무를 해결하기 위한 도구와 소스(데이터)가 되어야 합니다.
AI Agent 구축, 어디서부터 시작해야 할까?
AI Agent를 현장에 도입하려면 크게 세 가지를 고려해야 합니다.
첫째, 업무 지식의 구조화입니다. Agent가 제대로 작동하려면 해당 업무의 도메인 지식이 체계적으로 정리되어 있어야 합니다. 어떤 데이터가 필요하고, 어떤 순서로 처리해야 하며, 어떤 조건에서 어떤 판단을 내려야 하는지 — 이 모든 것이 Agent가 참조할 수 있는 형태로 설계되어야 합니다.
많은 기업들이 이 단계를 가볍게 넘기려 하지만, 사실 여기가 프로젝트의 성패를 가르는 가장 중요한 지점입니다. 현장 담당자의 머릿속에만 존재하는 암묵적 지식을 끌어내고, 이를 Agent가 이해할 수 있는 규칙과 데이터 구조로 변환하는 작업이 선행되어야 합니다.
둘째, 멀티 에이전트 오케스트레이션입니다. 현실의 업무는 하나의 Agent가 처리하기엔 너무 복잡합니다. 데이터를 수집하는 Agent, 계산을 수행하는 Agent, 결과를 비교·분석하는 Agent가 각각의 역할을 맡고 서로 협력해야 비로소 실무 수준의 결과물이 나옵니다.
이 협력 구조를 설계하는 것이 오케스트레이션의 핵심입니다. 마치 오케스트라에서 지휘자가 각 악기 파트의 타이밍과 역할을 조율하듯, 여러 Agent가 언제 어떤 순서로 작업을 수행하고 어떻게 결과를 넘겨받을지를 체계적으로 설계해야 합니다. 단일 Agent에 모든 기능을 욱여넣으면 복잡도가 기하급수적으로 올라가고, 어느 한 부분에서 오류가 발생했을 때 전체 시스템이 무너지는 리스크도 커집니다.
셋째, 기업 환경과의 통합입니다. 아무리 뛰어난 Agent라도 직원들이 쉽게 접근할 수 없다면 의미가 없습니다. 기존 업무 환경 — 예를 들어 사내 메신저나 협업 도구 — 에 자연스럽게 녹아들어야 실제 활용도가 올라갑니다. 별도의 웹사이트에 접속해야 하거나, 새로운 앱을 설치해야 한다면 아무리 좋은 Agent도 조직 내 확산이 어렵습니다.
실전 사례: 해상 운임 자동 산정 AI Agent
데이터스랩은 최근 국내 대기업과의 협업을 통해 해상 운임 자동 산정 AI Agent를 구축했습니다. 이 프로젝트는 위에서 설명한 세 가지 원칙을 그대로 적용한 사례입니다.
어떤 문제를 풀었는가
해상 운임 산정은 생각보다 훨씬 복잡한 업무입니다. 단순히 "A항구에서 B항구까지 얼마"로 끝나지 않습니다. 실시간으로 변하는 환율과 유가를 반영해야 하고, 선박의 크기와 종류, 선적물의 특성, 해상 경로의 차이까지 모두 고려해야 합니다. 같은 출발지와 도착지라 하더라도 수에즈 운하를 경유하느냐, 희망봉을 돌아가느냐에 따라 운임이 크게 달라지기도 합니다.
기존에는 숙련된 담당자가 여러 시스템을 오가며 수작업으로 계산하던 영역이었습니다. 환율 사이트를 열고, 유가 정보를 확인하고, 엑셀에서 복잡한 공식을 돌리고, 여러 경로를 하나씩 비교하는 과정을 거쳐야 했죠. 한 건의 운임을 산정하는 데 상당한 시간이 소요됐고, 담당자의 경험과 숙련도에 따라 결과의 정확도가 달라지는 문제도 있었습니다.
3개 Agent의 오케스트레이션
이 복잡한 업무를 해결하기 위해, 우리는 단일 Agent가 아닌 3개의 전문 Agent가 협력하는 오케스트레이션 구조를 설계했습니다.
Agent 1 — 데이터 수집 및 정제 Agent: 실시간 환율, 유가, 해상 경로 데이터 등 운임 산정에 필요한 기초 데이터를 자동으로 수집하고 정제합니다. 흩어져 있는 데이터 소스를 하나의 흐름으로 통합하는 역할을 맡습니다. 데이터의 신뢰성을 확보하기 위해 수집 시점의 타임스탬프를 기록하고, 이상치를 자동으로 감지하는 로직도 포함되어 있습니다.
Agent 2 — 운임 계산 Agent: 수집된 데이터를 바탕으로 선박 크기, 선적물 종류, 특정 구간 등의 조건을 반영해 운임을 계산합니다. 단순 공식 적용이 아니라, 다양한 변수를 조합한 복합 계산을 수행합니다. 예를 들어 동일한 경로라 하더라도 벌크선과 컨테이너선의 운임 체계가 다르고, 계절에 따른 수요 변동까지 반영해야 하는 경우가 있습니다.
Agent 3 — 비교 분석 및 최적화 Agent: 여러 조건에 대한 운임을 비교 분석하여 최적의 운임 값을 제시합니다. 담당자가 의사결정을 내리는 데 필요한 비교 데이터를 정리하고 변경해 보기 원하는 조건 값을 반영하여 비교 분석 자료를 작성해 줍니다.
이 세 Agent는 순차적으로, 때로는 병렬로 작업을 수행하며, 최종적으로 사용자에게 최적의 운임 산정 결과를 전달합니다. 중요한 것은 이 전체 프로세스가 사용자 입장에서는 하나의 자연어 질문으로 시작된다는 점입니다. "A항구에서 B항구까지, 5만톤급 벌크선 운임 비교해줘"라고 말하면, 뒤에서 3개의 Agent가 알아서 움직입니다.
Azure 기반 아키텍처
전체 시스템은 Microsoft Azure 인프라 위에 구축했습니다. Azure SQL로 데이터를 관리하고, Blob Storage에 관련 문서와 참조 데이터를 저장합니다. Azure Function App으로 각 Agent의 핵심 로직을 실행하고, Power Automate로 워크플로우를 자동화했습니다. Web App을 통해 사용자 인터페이스를 제공하되, 최종적으로는 Microsoft Teams에 임베딩하여 배포했습니다.
Azure를 선택한 이유는 단순합니다. 대부분의 대기업이 이미 Microsoft 365 환경을 사용하고 있기 때문입니다. 기존 인프라와의 호환성, 보안 정책 연동, 그리고 Teams를 통한 자연스러운 배포까지 — Azure 생태계 안에서 구축하면 엔터프라이즈 환경에서 요구하는 많은 조건들을 별도의 추가 작업 없이 충족할 수 있습니다. (참고로 GPT API를 통해서도 구축은 가능합니다. 다만, Azure 의 다양한 리소스를 활용한 유연한 방식이 아닌 OpenAI의 제공된 프레임워크를 사용해야 하기 때문에 설계 유연성이 다소 떨어집니다..)
Teams 임베딩은 의도적인 선택이었습니다. 직원들이 매일 사용하는 협업 도구 안에서 별도의 로그인이나 앱 설치 없이 바로 Agent에 접근할 수 있기 때문입니다. 도입 초기의 가장 큰 허들인 "사용자 접근성" 문제를 원천적으로 해결한 셈입니다.
Agent를 잘 만드는 것과 잘 쓰이게 만드는 것
AI Agent 프로젝트에서 가장 흔한 실패 패턴은 "기술적으로는 완성했는데 아무도 안 쓴다"입니다. 기술 데모에서는 박수를 받았지만, 정작 현장 담당자들은 기존 방식을 고수하는 경우가 생각보다 많습니다. 데이터스랩이 프로젝트를 수행하면서 가장 중요하게 생각한 원칙은 세 가지였습니다.
업무 전문가와의 긴밀한 협업. Agent가 현장에서 통하려면, 개발팀만으로는 부족합니다. 실제로 해상 운임을 산정하는 실무자들과 지속적으로 소통하며 업무 로직을 Agent에 녹여냈습니다. 개발 초기 단계부터 실무자를 참여시키고, 프로토타입을 함께 테스트하며 피드백을 반영하는 과정을 반복했습니다. 이 과정에서 "엑셀에서는 이렇게 했는데 Agent는 왜 다르게 계산하지?"라는 질문이 나올 때마다 로직을 정교하게 다듬었습니다.
적절한 역할 분리. 하나의 만능 Agent를 만들려는 유혹을 버려야 합니다. 각 Agent가 명확한 책임을 가지고, 그 범위 안에서 최고의 성능을 발휘하도록 설계하는 것이 안정적인 운영의 핵심입니다. 역할이 명확하면 문제가 발생했을 때 어느 Agent에서 이슈가 생겼는지 빠르게 파악할 수 있고, 특정 Agent만 개선하거나 교체하는 것도 가능해집니다.
기존 업무 환경에 자연스러운 통합. 새로운 도구를 도입하는 것이 아니라, 이미 익숙한 환경 안에 AI를 심는 방식으로 접근해야 합니다. Teams 임베딩은 그 철학의 결과물입니다. 사용자가 "새로운 AI 시스템을 배워야 한다"고 느끼는 순간, 활용도는 급격히 떨어집니다. 반대로 평소 쓰던 채팅창에서 자연어로 질문하면 답이 나오는 경험은, 도입 장벽을 거의 제로에 가깝게 만들어 줍니다.
마치며
AI Agent는 더 이상 미래의 기술이 아닙니다. 이미 기업 현장에서 복잡한 실무를 대체하고 있고, 그 가치는 실제 업무 문제를 얼마나 정확하게 풀어내느냐에 달려 있습니다.
다만 그 과정이 생각만큼 단순하지는 않습니다. 업무 지식의 구조화, 멀티 에이전트 오케스트레이션, 그리고 사용자 환경과의 통합 — 이 세 축이 균형 있게 갖춰져야 진짜 쓸모 있는 Agent가 탄생합니다. 기술만 앞세우거나, 반대로 현장의 목소리만 듣고 기술적 최적화를 간과해도 결과는 좋지 않습니다. 두 세계를 연결하는 것이 핵심입니다.
현장의 문제를 가장 잘 아는 사람과, AI를 가장 잘 만드는 팀이 만나면 — 진짜 변화가 시작됩니다.
