텍스트만 뱉는 에이전트는 그림을 못 그린다 — OpenClaw가 미디어 생성을 프로바이더 추상화로 푼 방법

오픈소스 개인 AI 어시스턴트 OpenClaw를 들여다보다가, "에이전트가 어떻게 그림·영상·음악을 만들어 내는가"를 다루는 부분이 흥미로웠다. 텍스트 대화만 하는 에이전트는 "포스터 하나 그려줘"라는 부탁에 글로 묘사만 할 뿐 실제 이미지를 내놓지 못한다. OpenClaw는 이 한계를 이미지·영상·음악 생성 도구 세 개(image_generate, video_generate, music_generate)로 풀되, 각각을 여러 외부 생성 서비스(프로바이더)를 갈아 끼울 수 있는 표준 인터페이스로 묶었다. 이 글은 왜 그 추상화가 필요했고, 어떻게 동작하는지를 따라간다.

배경 — 텍스트 전용 에이전트의 출력 한계

메신저로 말을 거는 AI 에이전트는 기본적으로 텍스트 in, 텍스트 out이다. 사용자가 "친근한 로봇 마스코트 이미지를 만들어줘"라고 해도, 언어 모델 혼자서는 픽셀을 직접 칠하지 못한다. 시각·청각 산출물은 별도의 생성 모델(이미지 디퓨전 모델, 영상 생성 모델, 음악 생성 모델)이 맡아야 하는데, 그런 모델은 OpenAI·Google·fal 같은 외부 서비스가 API로 제공한다. 그래서 에이전트가 그림을 그리려면 "외부 생성 API를 호출하는 도구"를 손에 쥐어 줘야 한다.

여기서 핵심 용어 하나 — 도구(tool)는 언어 모델이 대화 중에 직접 호출할 수 있는 함수를 말한다. 모델이 "지금은 이미지를 만들 차례"라고 판단하면 image_generate라는 도구를 인자(프롬프트·크기 등)와 함께 호출하고, OpenClaw가 그 호출을 받아 실제 외부 서비스로 중계한다. OpenClaw에서는 이런 미디어 생성 도구가 프로바이더가 최소 하나 설정돼 있을 때만 에이전트의 도구 목록에 나타난다 — API 키가 하나도 없으면 도구 자체가 보이지 않는다.

다이어그램 설명. 이 그림은 같은 부탁을 받았을 때 도구가 있느냐 없느냐로 결과가 갈리는 지점을 보여준다. 위에서 사용자의 요청이 언어 모델로 들어가고, 모델은 "이미지를 만들 도구가 있는가?"를 판단한다. 도구가 없는 텍스트 전용 에이전트는 아래 왼쪽 분기로 가서 그림을 말로만 묘사하고 끝난다. 도구가 붙어 있으면 오른쪽 분기로 가서 외부 생성 서비스를 호출해 실제 이미지 파일을 받아 온다. 이 패턴이 중요한 이유는, 언어 모델 자체를 바꾸지 않고 도구를 쥐어 주는 것만으로 에이전트의 출력 종류(텍스트 → 이미지·영상·음악)를 늘릴 수 있다는 데 있다. 놓치기 쉬운 점은 "AI가 그림도 그린다"는 표현인데, 정확히는 언어 모델이 그리는 게 아니라 언어 모델이 그림 그리는 외부 모델을 호출하는 구조다. 그래서 사용자에겐 "에이전트가 그림을 그려 줬다"로 보이지만, 가치의 핵심은 "텍스트 비서가 멀티미디어 비서로 확장됐다"는 점이다.

핵심 문제 — 프로바이더마다 다 다르다

도구 하나만 붙이면 끝일 것 같지만, 실제 외부 생성 서비스들의 사정은 제각각이다. OpenClaw가 묶은 이미지 프로바이더만 해도 ComfyUI·DeepInfra·fal·Google·LiteLLM·Microsoft Foundry·MiniMax·OpenAI·OpenRouter·Vydra·xAI로 열 곳이 넘고, 영상은 14개, 음악은 5개다. 이들이 서로 다른 점을 나열하면 이렇다.

• 인증 방식: 어떤 곳은 OPENAI_API_KEY 같은 API 키, 어떤 곳은 OAuth(사용자가 로그인해 권한을 위임하는 방식), Microsoft Foundry는 Entra ID(마이크로소프트 계정 인증)까지 쓴다.
• 입력 능력: 같은 "이미지 편집"이라도 OpenAI는 참조 이미지 5장까지, fal의 한 모델은 14장까지, ComfyUI는 1장만 받는다. 영상은 텍스트만으로 만드는 것(text-to-video), 이미지를 첫 프레임으로 주는 것(image-to-video), 기존 영상을 변형하는 것(video-to-video)을 프로바이더마다 다르게 지원한다.
• 옵션 이름: 가로세로 비율을 OpenAI는 받지 않고 크기(size)만 받는데, Google은 비율(aspectRatio)·해상도(resolution)를 따로 받는다. 같은 의도(세로 9:16)를 프로바이더마다 다른 파라미터로 표현해야 한다.
• 처리 시간과 응답 형태: 이미지는 보통 빠르지만 영상은 30초에서 수 분까지 걸리고, fal의 큐 기반(queue, 작업을 대기열에 넣고 순서대로 처리) 모델은 기본 20분까지 기다린다.

다이어그램 설명. 이 그림은 "에이전트가 프로바이더를 직접 상대하면 무엇이 번거로운가"를 보여준다. 동일한 요청(세로 비율 이미지 한 장)이 세 갈래로 갈라지는데, 각 프로바이더마다 비율을 표현하는 방법도, 인증 방식도, 응답을 받는 방식(즉시 vs 대기열)도 전부 다르다. 만약 에이전트(정확히는 에이전트를 모는 언어 모델)가 이 차이를 전부 알고 있어야 한다면, 프로바이더가 추가될 때마다 모델에게 새 사용법을 가르쳐야 하고, 한 곳이 장애를 일으키면 대안으로 갈아탈 방법이 막막해진다. 함정은 "프로바이더가 다 비슷하겠지"라는 가정이다 — 위 세 갈래가 보여주듯 같은 "9:16 한 장"조차 표현이 갈리므로, 차이를 흡수하는 중간 계층이 없으면 도구를 쓰는 쪽이 그 복잡도를 고스란히 떠안는다. 그래서 무슨 가치냐면, 이 문제를 풀어야 비로소 "프로바이더는 늘려도 에이전트 쓰는 법은 그대로"가 가능해진다.

해결 방법 — 하나의 표준 도구 + 갈아 끼우는 프로바이더 백엔드

OpenClaw의 답은 프로바이더 추상화다. 에이전트에게는 종류별로 도구 딱 하나(image_generate / video_generate / music_generate)만 노출하고, 그 도구 아래에 여러 프로바이더를 교체 가능한 백엔드로 둔다. 비유하자면 벽의 콘센트와 같다 — 콘센트 모양(도구 인터페이스)은 표준이라 어떤 기기를 꽂든 똑같이 쓰지만, 그 뒤에서 전기를 만드는 발전소(프로바이더)는 화력이든 태양광이든 바꿔 끼울 수 있다.

다이어그램 설명. 이 그림은 추상화의 전체 구조를 한 장으로 보여준다. 에이전트가 표준 도구 하나를 호출하면, 그 호출이 OpenClaw 미디어 생성 계층으로 들어가고, 거기서 선택된 프로바이더의 형식으로 번역돼 여러 백엔드 중 하나로 나간다. 핵심은 에이전트가 보는 인터페이스는 항상 동일하고, 프로바이더별 차이(인증·파라미터 이름·입력 한계)는 전부 가운데 계층이 흡수한다는 점이다. 단일 프로바이더 호출과의 결정적 차이는, 앞 섹션의 세 갈래가 모두 이 한 계층 뒤로 숨어 에이전트 눈에는 콘센트 하나로 보인다는 데 있다. 놓치기 쉬운 점은 가운데 계층이 단순 중계가 아니라 "번역기"라는 사실이다 — 뒤에서 보겠지만, 지원하지 않는 옵션을 가장 가까운 값으로 바꾸거나 아예 무시하는 일까지 여기서 한다. 그래서 가치는 명확하다 — 프로바이더를 11개로 늘려도 에이전트가 익혀야 할 도구는 여전히 하나다.

능력 선언 — 프로바이더가 자기가 뭘 할 수 있는지 미리 알려 둔다

추상화가 성립하려면 가운데 계층이 "각 프로바이더가 무엇을 할 수 있는지"를 알아야 한다. OpenClaw는 이걸 능력 선언(capability declaration)으로 푼다 — 각 프로바이더가 자기가 지원하는 모드와 한계를 코드로 명시해 둔다. 예를 들어 영상 프로바이더는 텍스트로 만들기·이미지로 만들기·영상으로 변형하기 세 모드를 각각 켜고 끄며, 각 모드에서 받을 수 있는 최대 입력 개수와 최대 길이를 적는다.

다이어그램 설명. 이 그림은 들어온 요청이 어떤 작업 모드로 분류되고, 프로바이더가 그 모드를 지원하는지 검사하는 흐름을 보여준다. 영상이 있으면 기존 영상을 변형하는 모드로, 이미지가 있으면 이미지를 첫 프레임 삼는 모드로, 아무 참조도 없으면 순수 텍스트 생성 모드로 결정한다. 그다음 프로바이더가 그 모드를 지원하는지 능력 선언과 대조해, 지원하면 제출하고 아니면 그 후보를 건너뛴다. 모드 지원 여부를 요청을 실제로 보내기 전에 판정하므로 — 못 하는 프로바이더는 처음부터 후보에서 빠진다. 가치는, 수십 개의 프로바이더 중 "이 요청을 실제로 처리할 수 있는 곳"만 자동으로 추려진다는 데 있다.

폴백 체인 — 한 곳이 실패해도 다음 후보로 자동 전환

프로바이더가 여럿이라는 사실은 장애 대비라는 부가 가치를 만든다. OpenClaw는 모델을 고를 때 정해진 순서를 따른다 — (1) 도구 호출에 모델이 직접 지정한 값, (2) 설정의 primary(주 모델), (3) 설정의 fallbacks(대체 모델 목록) 순서, (4) 그래도 없으면 인증된 프로바이더를 자동 탐색. 이걸 폴백 체인(fallback chain)이라 부른다 — 앞 후보가 실패하면 자동으로 다음 후보로 넘어가는 사슬이다.

다이어그램 설명. 이 그림은 한 요청이 여러 후보 프로바이더를 순서대로 시도하는 사슬을 보여준다. 각 단계가 실패하면 다음 순위로 떨어지고, 어느 단계든 성공하면 곧바로 이미지를 반환한다. 한 서비스의 일시 장애가 기능 전체의 실패로 번지지 않고 다음 후보로 흡수된다 — 프로바이더를 여러 개 묶은 추상화가 자연스럽게 가용성까지 끌어올린다. 가치는, 사용자가 아무것도 신경 쓰지 않아도 "되는 곳을 알아서 찾아 주는" 견고함이다.

비동기 처리 — 영상·음악은 오래 걸리니 작업 ID로 추적한다

이미지는 보통 금방 나오지만 영상·음악은 수십 초에서 수 분이 걸린다. 그동안 에이전트가 멈춰 기다리면 다른 대화를 못 하므로, OpenClaw는 이걸 비동기(asynchronous)로 처리한다 — 요청을 받으면 즉시 작업 ID(task id)를 돌려주고, 결과가 준비되면 같은 대화 세션을 다시 깨워서 그때 결과물을 전달한다.

다이어그램 설명. 이 그림은 오래 걸리는 생성 작업이 대화를 막지 않도록 처리되는 흐름을 보여준다. 에이전트가 영상 생성을 호출하면 OpenClaw가 프로바이더에 일을 맡기고 기다리지 않고 작업 ID부터 돌려준다. 프로바이더가 백그라운드에서 처리하는 동안 대화는 자유롭고, 영상이 다 만들어지면 OpenClaw가 같은 세션을 완료 이벤트로 깨워 에이전트가 결과물을 사용자에게 전달한다. 수 분짜리 렌더링이 에이전트를 인질로 잡지 않으면서도 결과가 준비되는 순간 자동으로 전달된다는 점이 핵심이다.

결과 — 무엇이 좋아졌나

이 추상화 덕분에 세 종류의 미디어 생성이 같은 골격을 공유하면서도, 셋을 합쳐 30개에 가까운 프로바이더 선택지를 갖게 됐다. 정리하면 이렇다.

관점	프로바이더 직접 상대했다면	OpenClaw 추상화
에이전트가 익힐 도구	프로바이더 수만큼	종류당 하나 (image/video/music)
프로바이더 추가	모델에게 새 사용법 교육 필요	백엔드만 등록, 도구는 그대로
한 서비스 장애	기능 전체 실패	폴백 체인으로 다음 후보 자동 전환
옵션 불일치	요청 거부 또는 오류	가장 가까운 값으로 정규화 + 무시 보고
오래 걸리는 작업	대화가 멈춤	작업 ID로 비동기 추적, 완료 시 자동 전달

정리하면, OpenClaw의 미디어 생성은 "에이전트에겐 도구 하나, 뒤에선 수십 개의 갈아 끼우는 백엔드"라는 구조다. 사용자 입장에선 "포스터 그려줘", "5초짜리 영상 만들어줘", "신스팝 트랙 하나"라고 말하면 되고, 어느 프로바이더가 잘 되는지·어떤 옵션 이름을 쓰는지·얼마나 걸리는지는 신경 쓸 필요가 없다. 텍스트만 뱉던 에이전트가 시각·청각 산출물까지 내놓는 멀티미디어 비서로 확장되는 동시에, 그 확장이 특정 외부 서비스에 묶이지 않는다는 게 이 설계의 진짜 값이다 — 더 나은 생성 모델이 나오면 백엔드만 갈아 끼우면 되고, 에이전트가 쓰는 법은 어제와 똑같다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.