일주일의 '배관 작업'을 없앤 IBM CUGA의 등장
AI 에이전트를 구축할 때 로직 설계 전 프레임워크 선정, 모델 클라이언트 연결, 도구 어댑터 작성, UI 상태 전달 방식 설정 등 이른바 '배관 작업'에 일주일 가까운 시간이 소요된다. IBM이 공개한 CUGA(Configurable User-centric Agent harness)는 계획 수립, 실행 루프, 도구 호출, 상태 관리라는 반복적 설정을 하네스 차원에서 자동으로 처리한다. 개발자는 에이전트가 사용할 도구와 수행할 작업만 정의하면 된다.
도입 과정은 매우 단순하며 패키지 설치만으로 시작할 수 있다.
pip install cugaCUGA는 FastAPI 기반의 단일 파일 구조로 구현된다. IBM은 영화 추천부터 IBM Cloud 아키텍처 어드바이저까지 24개의 예제 앱을 모은 cuga-apps를 제공하며, 라이브 갤러리를 통해 실제 작동 모습을 확인할 수 있다. 각 앱은 하나의 파일 안에 에이전트 설정, 도구, 프롬프트가 모두 포함되어 있어 FastAPI 사용 경험이 있는 개발자라면 즉시 코드를 수정해 사용할 수 있다.
하네스가 오케스트레이션을 전담하면서 모델 변경 시마다 제어 로직을 다시 짤 필요가 없어졌다. CUGA는 행동 전 계획을 세우고 도구 호출과 생성된 코드를 혼합해 실행하여 오류를 줄인다. 이러한 구조적 효율성은 벤치마크 수치로 증명된다. CUGA는 2025년 7월부터 2026년 2월까지 측정된 AppWorld 벤치마크와 2025년 2월부터 9월까지의 WebArena 벤치마크에서 모두 1위를 기록했다. 이는 하네스 수준에서 계획과 상태 관리를 체계적으로 처리하는 것이 개별 프롬프트 튜닝보다 정교한 결과물을 낸다는 것을 보여준다.
CodeAct와 리플렉션으로 구현한 '스스로 수정하는' 루프
CUGA는 모델의 추론 능력에만 의존하지 않고 하네스 수준에서 실행 방식을 제어하는 `CodeAct` 방식을 사용한다. 모델이 단순히 API를 호출하는 것에 그치지 않고, 그 결과를 처리할 코드를 직접 작성해 실행하며 다음 단계로 넘어가는 구조다. 추론과 실행이 하나의 흐름으로 이어지기에 모델은 생성한 코드의 결과물을 즉시 확인하고 다음 행동을 결정할 수 있다.
장기 태스크 수행 시 발생하는 데이터 유실 문제를 해결하기 위해 `Variable-tracking` 기능을 도입했다. 이를 통해 20단계 이상의 태스크에서도 중간 데이터를 유지하며 재도출 오류를 방지한다. 여기에 `Reflection` 단계를 추가해 실행 결과가 잘못되었음을 감지하면 계획을 다시 세운다. 모델이 모든 상태를 기억하며 추론하는 대신 하네스가 기록한 변수 목록을 참조하므로 모델이 처리해야 할 정보량이 줄어든다.
안정적인 루프를 위해 CUGA는 도구가 반환하는 데이터 규격을 엄격하게 제한한다. 모든 인라인 도구는 성공과 실패를 구분하는 엔벨로프 형태의 JSON을 반환해야 한다.
{"ok": true, "data": {...}} 또는 {"ok": false, "code": "...", "error": "..."}
가공되지 않은 스택 트레이스가 전달되면 전체 계획이 무너지지만, 규격화된 에러 메시지가 전달되면 플래너가 이를 인지해 우회 경로를 찾거나 입력을 수정할 수 있다. 도구가 정해진 규격으로 실패를 보고하는 것만으로도 에이전트의 복구 능력이 향상된다.
거대 모델 없이 gpt-oss-120b로 성능을 낸 비결
앞서 설명한 하네스의 상태 관리 능력을 바탕으로, CUGA는 고가의 프론티어 API 대신 오픈 웨이트 모델인 gpt-oss-120b를 사용하여 호스팅 앱을 구동한다. 개발자는 코드 수정 없이 설정 파일만으로 Fast, Balanced, Accurate 세 가지 추론 모드 중 하나를 선택해 비용과 지연 시간의 균형을 맞출 수 있다. 인프라 환경에 따라 모델을 교체하더라도 전체 워크플로를 다시 짤 필요가 없는 구조다.
코드 실행을 위한 샌드박스 환경은 Local, Docker/Podman, E2B cloud 중에서 선택 가능하다. 샌드박스는 외부 시스템에 영향을 주지 않고 코드를 안전하게 실행하는 격리된 가상 환경이다. 개발 단계에서는 Local을 쓰고 배포 단계에서는 Docker나 E2B cloud로 전환하는 운영이 가능하다. 특히 E2B cloud를 사용하면 별도 서버 구축 없이 즉시 코드 실행 환경을 확보할 수 있어 도구 정의와 프롬프트 최적화에 더 많은 시간을 할애할 수 있다.
이처럼 계획 수립, 리플렉션, 변수 추적을 하네스가 직접 수행함으로써 모델이 짊어져야 할 연산 부하를 분담한다. 일반적인 에이전트 하네스가 GPT-4 같은 프론티어 모델의 자체 복구 능력에 의존하는 것과 달리, CUGA는 시스템적으로 오류를 감지하고 재계획하는 과정을 처리한다. 덕분에 상대적으로 작은 오픈 모델로도 복잡한 워크플로를 완수할 수 있다.
MCP 서버와 36개 도구로 확장하는 에이전트 생태계
CUGA는 OpenAPI, MCP(Model Context Protocol), LangChain 함수를 동일한 방식으로 바인딩하여 도구 연결 과정을 단순화했다. 개발자가 각 도구의 인터페이스를 분석해 어댑터를 짤 필요 없이 표준 규격만 따르면 즉시 연결된다.
IBM Code Engine 기반의 7개 공용 MCP 서버가 총 36개의 도구를 제공한다. 웹 검색, 위키피디아, arXiv 논문 검색, 지오코딩, 날씨, 금융 시세 같은 범용 기능은 직접 서버를 호스팅할 필요 없이 호출만으로 사용 가능하다.
load_tools(["web"])위 코드 한 줄로 외부 웹 검색 기능을 즉시 탑재할 수 있다. 상태가 없는 범용 기능은 공유 MCP 서버에서 가져오고, 서비스 특화 기능만 내부 파이썬 함수로 정의해 혼합 사용하는 방식이다.
비정형 데이터 처리와 협업 구조에서도 확장성을 확보했다. Docling 기반의 RAG(Retrieval-Augmented Generation)를 지원하여 PDF, 오디오, 비디오 파일의 내용을 정확하게 읽고 활용한다. 또한 A2A(Agent-to-Agent) 방식을 도입해 하나의 에이전트가 다른 전문 에이전트에게 작업을 위임하는 멀티 에이전트 체계를 구현했다. 이는 복잡한 업무를 작은 단위의 전문 에이전트들로 쪼개어 배치함으로써 실행 정확도를 높이는 전략이다.
한국 실무자가 CUGA를 도입할 때 고려할 실무 기준
CUGA는 FastAPI 경험만 있다면 즉시 에이전트를 배포하고 검증할 수 있는 환경을 제공한다. 모델 연결 단계에서도 `create_llm`이라는 팩토리 함수가 환경 변수에 따라 적절한 모델을 자동으로 연결해 준다.
llm = create_llm()지원 프로바이더는 OpenAI, Anthropic, watsonx, LiteLLM, Ollama로 다양하다. 특히 보안상의 이유로 온프레미스 환경을 선호하거나 비용 절감을 위해 로컬 모델을 검토하는 실무자에게 Ollama나 LiteLLM 지원은 유용한 선택지다. 코드 수정 없이 환경 변수 변경만으로 상용 API에서 오픈 모델로 즉시 전환하며 성능을 비교할 수 있다.
에이전트의 도구 사용 결정 기준은 파이썬 함수의 docstring(함수 설명문)이다. 복잡한 JSON 스키마를 수동으로 작성하거나 별도의 도구 정의서를 만들 필요 없이, 함수 상단에 적은 자연어 설명만으로 에이전트가 호출 여부를 판단하고 인자를 매핑한다. 이는 새로운 도구를 추가하거나 기능을 수정할 때 코드 한 줄만 고치면 즉시 반영되는 구조다.
결국 도입의 핵심은 프론티어 모델의 성능에 전적으로 의존하지 않고도 복잡한 태스크를 수행하는 에이전트를 얼마나 빠르게 검증할 수 있느냐에 있다. 소형 오픈 모델로 충분한 업무 수행 능력이 나오는지 확인하려면 CUGA의 유연한 프로바이더 전환 기능을 활용하는 것이 효율적이다. 복잡한 오케스트레이션 프레임워크 학습보다 실제 현장에 필요한 도구 정의와 프롬프트 최적화에 집중하고 싶은 팀에게 적합한 선택지가 된다.
AI 에이전트를 구축할 때 API 연결과 환경 설정이라는 배관 작업에 매달리던 시대는 끝났다. CUGA는 계획과 실행 루프, 상태 관리를 하네스 차원에서 처리하여 개발자가 도구와 프롬프트만 정의하면 즉시 작동하는 환경을 제공한다. CodeAct 방식의 실행과 리플렉션 단계가 결합되어 소형 오픈 모델만으로도 스스로 오류를 수정하며 복잡한 태스크를 완수하는 구조다.
결국 실무자에게 남은 과제는 모델의 파라미터 수를 높이는 것이 아니라, 상태 유지와 오류 수정 메커니즘이 검증된 하네스를 통해 구축 속도를 높이는 것이다. 프론티어 모델 없이도 복잡한 에이전트를 빠르게 구현하고 싶다면 하네스의 기능적 완성도를 최우선 판단 기준으로 삼아야 한다.
