500개 이상의 내부 도구 표준화와 CI 파이프라인 병목 해결 과정
매일 아침 수십 개의 내부 대시보드와 스프레드시트를 번갈아 열어가며 데이터를 대조하고 파이프라인 상태를 점검하는 개발팀의 일상을 떠올려 보실 수 있습니다. 그랩(Grab)의 실제 업무 방식을 다룬 영상 시연에서는 인공지능 모델이 코드 작성 속도를 크게 높여주는 반면, 정작 배포를 위한 지속적 통합 파이프라인에서 작업이 밀리는 병목 현상을 보여줍니다. 회사 안에 존재하는 500개 이상의 내부 도구가 각기 다른 규격으로 작동하다 보니, 에이전트가 어떤 도구를 호출해야 할지 판단하는 과정에서 작업 맥락이 엉키는 원인이 되었습니다. 이 제약을 풀기 위해 여러 에이전트가 단계를 넘나들며 작업 상태를 잃지 않고 유지하는 다중 에이전트 오케스트레이션(Multi-agent orchestration) 환경을 구성하여 복잡한 도구 호출 방식을 하나의 틀로 맞췄습니다.
표준화를 거친 환경에서 에이전트는 사용자의 요청 내용과 각 도구에 적힌 설명을 읽고 언제 어떤 기능을 쓸지 스스로 결정합니다. 이후 모델이 규격화된 호출 명령을 내보내면, 연결된 클라이언트 애플리케이션이 이를 받아 실제 동작으로 옮기는 방식으로 업무가 이어집니다. 하지만 수백 개의 도구가 맞물린 상태에서는 모델을 새 버전으로 교체하거나 런타임을 바꿀 때마다 전혀 예상치 못한 오류가 일어날 수 있습니다. 배포 전 단계에서 동작 실패를 막기 위해 결과물이 요구하는 문체와 내용 기준에 맞는지 코드로 검사하는 평가 API(Evals API)를 더했습니다. 영상 시연에서는 평가 프로그램이 올바른 판단을 내렸는지 작업자가 애플리케이션 실행 화면을 확인하며 기대치와 실제 성능을 대조하는 작업 순서가 나타납니다.
자동 컨텍스트 압축 및 다중 에이전트 오케스트레이션 작동 흐름
사용자가 에이전트에게 여러 단계를 거치는 작업을 지시하면, 에이전트는 도구를 번갈아 쓰면서 늘어나는 대화 기록을 잃지 않고 챙겨야 합니다. 오프나이(OpenAI)의 에이전트 소프트웨어 개발 키트는 여러 에이전트가 함께 일하는 환경에서 이렇게 쌓이는 이전 문맥을 자동으로 압축해 줍니다. 전체 작업을 지휘하는 과정이 어느 곳에서 실행될지, 그리고 각 작업 사이의 상태 정보를 누가 맡아서 관리할지에 따라 알맞은 런타임을 고르는 과정이 먼저 진행됩니다. 알맞은 런타임이 정해지면 에이전트들은 서로 진행 상황을 놓치지 않고 주고받으며, 문맥이 끊기지 않은 상태에서 사용자에게 다음 행동을 자연스럽게 제안합니다.
사용자의 요청과 제공된 도구의 설명을 바탕으로 인공지능이 특정 함수를 언제 부를지 스스로 판단하지만, 직접 코드를 실행하지는 못합니다. 앤스로픽(Anthropic)의 기술 문서를 보면, 모델은 단지 정형화된 호출 신호를 만들어 돌려줄 뿐입니다. 실제 애플리케이션 실행은 이 신호를 전달받은 사용자의 클라이언트 환경이나 서버 도구 영역에서 따로 이루어집니다. 그 결과 인공지능은 화면을 통해 행동을 제안하는 역할에 머물고, 실제 명령을 수행하는 시스템과의 경계가 명확하게 그어집니다. 엠씨피(MCP) 서버를 지원하는 프로그래밍 방식의 도구 호출을 거치면, 모델이 직접 시스템을 건드리지 않고도 외부 함수를 안전하게 실행한 뒤 결과값을 받아 다음 작업을 이어갑니다.
상태 관리를 위한 런타임 선정과 클라이언트·서버 도구 호출 분기
사용자가 여러 단계의 복잡한 요청을 남겼을 때, 누가 전체 작업의 흐름을 쥐고 기억할지 결정하는 과정부터 시작합니다. OpenAI의 기술 자료를 보면 작업 단계를 조율하는 위치와 각 과제 사이의 상태를 유지할 주체에 따라 알맞은 런타임을 선정하도록 안내합니다. 자체 애플리케이션 실행 환경 안에서 직접 문맥을 자동으로 압축하거나 여러 인공지능을 동시에 통제하는 방식을 고를 수 있습니다. 영상 시연에서는 회사 내부에서 500개 넘게 표준화한 도구를 연동해 쓰는 장면이 나오는데, 다뤄야 할 대상이 많을수록 맥락이 끊기지 않도록 관리 주체를 명확히 정하는 동작 방식이 요구됩니다. 언제 어떤 기능을 꺼낼지 계획하고 결과를 다음 단계로 넘기는 모든 과정이 이 기반 위에서 이루어집니다.
모델이 외부 시스템의 데이터를 읽어오거나 특정 행동 제안을 내놓을 때, 그 명령을 실제로 누가 처리할지 실행 경로를 나누어 주어야 합니다. Anthropic의 자료를 살펴보면 사용자의 요청과 도구에 적힌 설명을 바탕으로 언제 어떤 기능을 쓸지 모델이 스스로 판단하게 됩니다. 결정이 끝나면 모델은 정형화된 호출 신호를 반환하는데, 이를 우리가 만든 프로그램이 직접 받아서 처리하는 클라이언트 도구와 인공지능 제공자 측에서 곧바로 실행하는 서버 도구로 갈라집니다. 개발자가 자체적으로 정의한 함수를 연결하거나 제공자가 미리 만들어둔 기능을 쓸 때 반드시 이 분기점을 거칩니다. 따라서 우리 쪽 환경에서 직접 코드를 돌려 결과를 낼지, 아니면 외부 서버에 처리를 완전히 맡길지 설계 단계부터 동작 경계를 뚜렷하게 긋는 작업이 필요합니다.
Evals API 기반의 출력 검증과 정량적 성능 평가 지표 설계
새로운 인공지능 모델로 교체하거나 기존 애플리케이션을 갱신할 때, 개발자는 에이전트가 엉뚱한 결과물을 내놓지 않는지부터 꼼꼼히 살피게 됩니다. 오픈AI 문서에 따르면 이때 Evals API를 활용하여 프로그래밍 방식으로 평가 과정을 구성할 수 있습니다. 에발스라고 부르는 이 절차는 모델이 내놓은 출력물이 사전에 개발자가 지정해 둔 특정 문체와 내용 기준을 정확히 충족하는지 시험하는 방식으로 작동합니다. 여러 에이전트가 단계를 넘나들며 맥락을 유지하고 외부 도구를 다루는 상황에서, 신뢰할 수 없는 데이터가 섞여 들어가는 것을 막아줍니다. 개발자는 이 API를 통해 자신의 애초 예상치 대비 실제 애플리케이션이 얼마나 안정적으로 작동하는지 양적으로 파악하여 배포 전의 위험을 줄입니다.
클로드 모델이 주어진 외부 기능을 사용할 때도 출력 검증은 꼼꼼한 절차를 거칩니다. 사용자의 요청과 기능 설명서를 바탕으로 모델이 언제 도구를 쓸지 판단하면, 결과물이 곧바로 시스템에 반영되는 대신 구조화된 호출 형태로 먼저 돌아옵니다. 돌아온 이 명령을 고객의 애플리케이션이 직접 실행할지, 아니면 서버 형태로 제공자 측이 실행할지 명확히 나누어 통제해야 합니다. 오픈AI 지침 역시 오케스트레이션 과정을 어디서 구동하고 작업 사이의 상태를 누가 관리할지에 따라 알맞은 런타임을 선택하라고 안내합니다. 결과적으로 에이전트의 도구 호출은 철저히 격리된 런타임 환경 안에서 다루어지며, 최종적인 애플리케이션 실행 전에 출력값을 한 번 더 확인하도록 만들어 예기치 못한 오류를 막아냅니다.
트랜스포머 모델 정의 프레임워크 호환성과 MCP 서버 연동 점검
고객의 환불 요청 메일을 열고 어떤 사내 시스템부터 연결할지 고민된다면, 모델이 외부 도구를 호출하는 방식을 먼저 살펴야 합니다. 앤스로픽의 문서에 따르면 모델은 사용자의 요청과 주어진 도구 설명을 바탕으로 언제 도구를 쓸지 스스로 판단한 뒤 구조화된 호출 정보를 반환합니다. 이렇게 반환된 정보를 우리 애플리케이션이 직접 실행할지, 아니면 서버 쪽에서 알아서 처리할지에 따라 런타임 환경을 다르게 선택해야 합니다. 오픈AI의 에이전트 SDK를 적용하면 MCP 서버 지원을 통해 기존 인프라와 매끄럽게 연결하고 다중 에이전트 작업의 상태를 조율할 수 있습니다. 따라서 첫 자동화 대상은 애플리케이션 실행 주체가 명확하고 상태 관리를 어디서 할지 쉽게 통제할 수 있는 단위 작업으로 좁히는 것이 유리합니다.
작업을 모델에 맡긴 후에는 출력이 의도한 틀을 벗어나지 않는지 지속적으로 감시하는 장치가 있어야 합니다. 그랩의 LLM-Kit 도입 사례를 다룬 영상 시연에서는 오백 개 이상의 내부 요소를 표준화하여 개발 파이프라인 속도를 끌어올리는 모습을 확인할 수 있습니다. 우리도 그 전에 오픈AI 평가 가이드에서 안내하는 Evals API를 활용하여 결과물의 문체나 내용이 설정한 기준을 만족하는지 프로그램 코드로 먼저 검사해야 합니다. 이렇게 자동화된 작은 평가 단위를 파이프라인에 미리 구축해 두면, 향후 새로운 트랜스포머 모델로 업그레이드하거나 동작 방식을 바꿀 때마다 안전하게 결과를 비교하며 안심하고 배포를 진행할 수 있습니다.
바로 써볼 체크리스트
시작 전에 확인할 것
도입 전후로 아래 항목만 확인해도, 자동화가 예상 밖으로 움직일 가능성을 크게 줄일 수 있습니다.
- 에이전트가 외부 도구를 호출할 때 입력하는 데이터의 형식이 사전에 정의된 스키마와 일치하는지 확인하는 입력 검증 로직이 애플리케이션 수준에 구현되어 정상 작동하는지 점검한다.
- 에이전트가 애플리케이션 내에서 실행하는 서버 도구 및 클라이언트 도구에 대해 최소 권한 원칙이 적용되어 있으며 명확한 권한 경계를 벗어나는 비정상적인 접근이 차단되는지 확인한다.
- 모델의 응답이 사전에 지정한 스타일과 내용 기준을 충족하는지 파악하기 위해 응용 프로그래밍 인터페이스를 활용한 프로그래밍 방식의 자동화된 테스트 또는 평가 파이프라인이 구축되었는지 확인한다.
- 다중 에이전트 오케스트레이션 환경에서 에이전트 간의 작업 전환과 도구 호출 내역을 포함하여 전체 실행 맥락을 빠짐없이 파악할 수 있는 상세한 로그/추적 시스템이 마련되어 있는지 검토한다.
- 에이전트의 작업 수행 중 예기치 않은 오류나 실패 사례가 발생했을 때 즉각적으로 시스템을 안전하게 보호하기 위해 실패 시 중단·되돌림 처리를 수행할 수 있는 자동화된 복구 절차를 확인한다.
- 시스템의 데이터베이스나 주요 인프라에 중대한 영향을 미칠 수 있는 도구 호출 작업에 대해서는 자동 실행 전 반드시 담당자의 검토와 사람 승인을 거치도록 필수 가드레일이 설정되어 있는지 점검한다.
참고 자료
- Grab's Agent Framework LLM-Kit Accelerates AI Agent Production Deployment (InfoQ) https://www.infoq.com/news/2026/09/grab-agent-platform/
- OpenAI Agents SDK guide (OpenAI documentation) https://developers.openai.com/api/docs/guides/agents
- Tool use with Claude (Anthropic documentation) https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
- OpenAI evaluations guide (OpenAI documentation) https://developers.openai.com/api/docs/guides/evals
- Anthropic evaluation tool (Anthropic documentation) https://platform.claude.com/docs/en/test-and-evaluate/develop-tests
- Hugging Face model documentation (Hugging Face documentation) https://huggingface.co/docs/transformers/index