지난 한 해 대부분 동안 "AI 창작"은 사람이 캔버스 앞에 앉아 프롬프트를 입력하고 생성을 클릭하는 것을 의미했습니다. 좋은 경험이고, 우리는 Floniks를 거기에 능숙하게 만드는 데 많은 시간을 들였습니다. 하지만 그것은 세상이 향하는 곳이 아닙니다. 점점 더, 이미지를 요청하는 것은 사람이 아닙니다. 에이전트입니다. 출시를 계획하는 Claude 세션. 블로그 게시물을 소셜 에셋으로 바꾸는 스크립트. 씬을 스토리보드로 만들고 모든 샷을 렌더링하는 다단계 파이프라인. 그 호출자들은 UI를 원하지 않습니다. 도구를 원합니다.
그래서 우리는 하나를 만들었습니다. Floniks는 이제 Claude Desktop — 또는 MCP 호환 클라이언트 — 가 우리의 창작 역량을 직접 호출할 수 있게 하는 Model Context Protocol (MCP) 서버를 제공합니다. 감싼 단일 모델이 아니라 플랫폼 전체입니다. 단일 단계 생성, 다단계 워크플로, 저장된 캐릭터, 크레딧 확인, 결과 검색까지요. Floniks 소개를 읽으셨다면, 이것이 그 비전 중 창작이 클릭으로 진행하는 것이기를 멈추고 위임하는 것이 되는 부분입니다.
MCP가 실제로 제공하는 것
Model Context Protocol은 구조화된 도구를 통해 AI 에이전트를 외부 시스템에 연결하는 작고 개방된 표준입니다. 에이전트에게 웹 UI를 스크래핑하거나 HTTP 호출을 손수 만들도록 가르치는 대신, 타입이 있는 입력과 출력을 가진 명명된 도구 집합을 노출하면, 에이전트가 언제 호출할지 결정합니다. 에이전트는 메뉴를 받고, 여러분은 주방의 통제권을 유지합니다.
Floniks에게 그 메뉴는 창작 플랫폼 자체입니다. 우리의 MCP 서버에 연결된 에이전트는 어떤 모델이 존재하는지 발견하고, 스틸이나 클립을 생성하고, 저장된 파이프라인을 실행하고, 결과를 폴링하고, 남은 크레딧이 얼마인지 확인할 수 있습니다. 사람이 단계들을 꿰매지 않고서요. 워크플로 에디터에서 손으로 구축할 바로 그 노드 그래프가, 에이전트가 스스로 작성하고 실행할 수 있는 것이 됩니다.
우리가 노출하는 도구들
우리는 도구 표면을 제품이 이미 작동하는 방식과 가깝게 유지하여, UI에서 하는 것과 에이전트가 프로그래밍 방식으로 할 수 있는 것 사이에 임피던스 불일치가 없게 했습니다. 대표적인 도구들은 몇 개의 그룹으로 나뉩니다.
단일 단계 생성. single_task는 AI Image와 AI Video 페이지의 에이전트 호출 가능 버전입니다. 일회성 text_to_image, image_to_image, image_to_video, 또는 text_to_video죠. get_task는 실행 중인 작업을 폴링하고 완료되면 상태와 출력 URL을 반환합니다.
워크플로. list_workflows, get_workflow, create_workflow, update_workflow는 에이전트가 Pro 모드를 구동하는 노드 기반 DAG를 검사하고 편집하게 해 줍니다. execute_workflow는 하나를 실행합니다. 그리고 generate_workflow는 흥미로운 것입니다. 자연어 설명을 건네면 워크플로 그래프를 반환합니다. 에이전트가 사실상 한 문장에서 파이프라인을 설계하고 실행할 수 있는 것이죠.
발견과 메타데이터. list_models, list_model_aliases, get_model_params는 에이전트에게 무엇이 사용 가능한지, 각 모델이 어떤 파라미터를 받는지 알려 주어, 추측하는 대신 유효한 요청을 구성할 수 있게 합니다. list_templates는 우리의 프리셋 파이프라인을 출발점으로 드러냅니다.
에셋과 계정. list_creations는 이전 출력을 가져옵니다. list_characters는 생성 전반에 걸쳐 재사용할 저장된 캐릭터를 노출합니다. 워크플로 에디터 들여다보기에서 다룬 바로 그 일관성 기본 요소죠. 그리고 get_credit_balance는 에이전트가 작업을 시작하기 전에 감당할 수 있는지 확인하게 해 줍니다.
여기서 중요한 설계 선택은 이렇습니다. 이것들은 병렬의, 물 탄 API가 아닙니다. 제품이 실행되는 바로 그 역량을, 구조화된 출력을 가진 기계 호출 가능한 도구로 노출한 것입니다.
현실적인 에이전트 루프
서버를 이해하는 가장 깔끔한 방법은 에이전트가 실제로 무엇을 하는지 따라가는 것입니다. Claude 세션이 기능 발표를 위한 히어로 이미지를 만들라고 요청받았다고 합시다. 개념적으로 루프는 이렇게 보입니다:
- 발견.
list_model_aliases를 호출해 어떤 모델이 사용 가능한지 보고 작업에 적합한 것을 고릅니다. 예를 들어 강력한text_to_image모델이죠. 선택적으로get_model_params를 호출해 어떤 종횡비나 크기를 받는지 알아냅니다. - 생성.
single_task를task_type: text_to_image, 선택한 모델, 그리고 에이전트가 발표 카피에서 구성한 프롬프트로 호출합니다. 이는 작업 ID를 반환합니다. - 폴링. 상태가 종료 상태에 도달할 때까지 그 ID로
get_task를 호출합니다. 생성이 비동기이기 때문에, 에이전트는 요청을 열어 둔 채 막는 대신 작업을 기다립니다. - 결과 사용. 성공 시
get_task는 출력 URL을 반환합니다. 에이전트는 그 URL을 사용자에게 돌려주거나, 문서에 떨어뜨리거나, 다음 단계에 공급합니다.
빠진 것에 주목하세요. 브라우저 자동화도, 화면 스크래핑도, 부서지기 쉬운 셀렉터도 없습니다. 에이전트는 타입이 있는 도구 결과에 대해 추론합니다. 그리고 우리는 여기서 가짜 자격 증명을 발명하지 않기 때문에 — 인증은 MCP 및 개발자 문서의 문서화된 설정을 통해 여러분의 Floniks 계정이 처리합니다 — 사람이 트리거하든 에이전트가 트리거하든 같은 루프가 동일하게 실행됩니다.
이것들을 몇 개 연결하면 예시가 더 야심차집니다. 블로그 게시물을 소셜 이미지 세트로 바꾸는 에이전트는 게시물을 읽고, 플랫폼마다 크기가 맞춰진 프롬프트로 single_task를 한 번씩 호출하고, URL을 수집합니다. 혹은 대본을 스토리보드로 만드는 Claude 워크플로는 generate_workflow로 샷 파이프라인을 설계하고, execute_workflow로 렌더링하고, get_task로 모든 샷을 모읍니다. 에이전트가 오케스트레이션을 소유하고, Floniks가 생성을 소유합니다.
하나가 아니라 세 가지 진입 방법
MCP 서버는 에이전트 빌더를 위한 헤드라인이지만, 세 가지 통합 경로 중 하나이며, 이것들은 섞어 쓰도록 의도되었습니다.
- MCP 서버는 에이전트를 위한 것입니다. Claude나 어떤 MCP 클라이언트 위에 구축한다면, 이것이 에이전트에게 창작 능력을 주는 네이티브 방법입니다.
- **REST API**는 그 외 모든 것을 위한 것입니다. 스크립트, 백엔드, 크론 작업, 여러분 자신의 제품이죠. 같은 역량을 평범한 HTTP로요. 에이전트보다 서비스에서 Floniks를 호출하고 싶다면, 이것이 그 경로입니다.
- 공개 Skills는 원시 도구 호출보다 더 높은 수준의 빌딩 블록을 원하는 개발자를 위해 일반적인 흐름을 재사용 가능한 단위로 패키징합니다.
세 가지 모두 MCP 및 개발자 문서 한 곳에 문서화되어 있습니다. 하나에 헌신할 필요는 없습니다. 흔한 형태는 대화형 작업에는 MCP 서버를, 예약된 배치 작업에는 REST API를 사용하는 백엔드를 두는 에이전트입니다. 둘 다 같은 워크플로를 두드리면서요.
왜 워크플로가 중요한 단위인가
단일 generate_image 도구를 내놓고 끝내는 것이 더 쉬웠을 겁니다. 우리는 그러지 않았습니다. Floniks가 가진 가장 가치 있는 것이 어느 한 모델이 아니라 조합 가능한 파이프라인이기 때문이죠. 이에 대한 전체 논거는 왜 워크플로가 일회성 프롬프트를 이기는가에서 폈지만, 짧은 버전은 이렇습니다. 일회성 프롬프트는 결과이지만, 워크플로는 새 입력으로 영원히 다시 실행할 수 있는 역량입니다.
워크플로를 MCP로 노출한다는 것은 에이전트가 그 레버리지를 물려받는다는 뜻입니다. 에디터에서 한 번 구축한 말하는 아바타 파이프라인 — 캐릭터 이미지에서 image-to-video로, 그리고 립싱크로 — 이, 에이전트가 다른 대본으로 천 번 호출할 수 있는 단일 execute_workflow 호출이 됩니다. 시각적으로 작성한 DAG와 에이전트가 호출하는 도구는 같은 객체입니다. 그것이 별도의, 더 얄팍한 API를 만드는 대신 에이전트 표면을 제품 표면과 정렬되게 유지하는 것의 보상입니다.
에이전트가 신뢰할 수 있는 신뢰성
자율 호출자는 실패의 위험 부담을 높입니다. 도착하지 않은 결과에 대한 청구를 잡아낼 사람이 지켜보고 있지 않기 때문이죠. 우리의 답은 플랫폼의 나머지가 실행되는 바로 그 답입니다. 생성이 실패하면 크레딧이 자동으로 환불됩니다. 모든 실패 경로에 걸쳐서요. 에이전트는 시작하기 전에 get_credit_balance를 호출해 예산을 잡을 수 있고, 실패한 작업에 대한 지불을 방어적으로 계산할 필요가 없습니다. 그건 처리됩니다. get_task의 구조화된 상태는 에이전트가 산문을 파싱하는 대신 성공, 실패, 또는 아직 처리 중에 따라 깔끔하게 분기할 수 있다는 뜻입니다.
에이전트 시대를 위해 만들어졌다
여기에는 더 큰 베팅이 있습니다. AI 에이전트와 답변 엔진이 인터넷의 더 많은 부분으로 가는 정문이 되면서, 승리하는 시스템은 기계가 호출할 수 있고 구조화된 출력을 반환하는 것들입니다. 콘텐츠에 적용되는 바로 그 생성 엔진 최적화(GEO) 논리가 역량에도 적용되는 것이죠. 에이전트가 구동할 수 있는, 타입이 있는 도구와 예측 가능한 결과를 가진 창작 플랫폼은 정확히 이것이 향하는 곳에 들어맞습니다. 우리는 에이전트가 사용할 수 없는 UI보다는 에이전트가 손을 뻗는 도구이고 싶습니다.
에이전트를 구축하거나, 파이프라인을 연결하는 AI 엔지니어이거나, 생성을 클릭하기보다 스크립트로 짜고 싶은 기술적 창작자라면, MCP 서버가 준비되어 있습니다. MCP 클라이언트를 Floniks로 향하게 하고, MCP 및 개발자 문서를 열고, 에이전트가 무언가를 만들게 하세요.
자주 묻는 질문
Model Context Protocol (MCP)이란 무엇인가요?
MCP는 구조화되고 타입이 있는 도구를 통해 AI 에이전트를 외부 시스템에 연결하는 개방 표준입니다. 에이전트가 UI를 스크래핑하거나 API 호출을 손수 만드는 대신, 시스템이 에이전트가 호출하고 추론할 수 있는 명명된 도구를 노출합니다. Floniks는 MCP 서버를 제공하여 어떤 MCP 호환 클라이언트든 그 창작 역량을 직접 사용할 수 있게 합니다.
Claude가 Floniks로 이미지를 생성할 수 있나요?
네. Floniks MCP 서버를 Claude Desktop(또는 어떤 MCP 클라이언트)에 연결하면, Claude는 text_to_image나 image_to_image를 위해 single_task를 호출하고, get_task로 폴링하고, 출력 URL을 반환할 수 있습니다. 더 큰 작업의 일부로 이미지를 자율적으로 생성하는 것이죠.
에이전트는 MCP 서버를 통해 실제로 무엇을 할 수 있나요?
에이전트는 모델을 발견하고(list_models, list_model_aliases, get_model_params), 단일 단계 생성을 실행하고(single_task), 다단계 파이프라인을 구축하고 실행하고(generate_workflow, create_workflow, execute_workflow), 저장된 캐릭터를 재사용하고(list_characters), 결과를 가져오고(get_task, list_creations), 크레딧 잔액을 확인할(get_credit_balance) 수 있습니다.
MCP 외에 다른 옵션이 있나요?
네. Floniks는 세 가지 통합 경로를 제공합니다. 에이전트를 위한 MCP 서버, 스크립트와 백엔드를 위한 REST API, 그리고 더 높은 수준의 재사용 가능한 흐름을 위한 공개 Skills입니다. 세 가지 모두 같은 역량을 공유하며 MCP 및 개발자 문서에 문서화되어 있습니다.