#4 어디서 AI 모델을 가져올 것인가

나의 고독한 AI 크리에이티브 툴 개발기 #4

모델은 많았지만,
연결할 방법이 없었다.

하나를 쓰는 건 쉬웠지만,
여러 개를 동시에 쓰는 건 완전히 다른 문제였다.

멀티모달로 확장되어야 한다는 확신

3D 생성 모델의 API를 활용해 툴에서 직접 3D 모델을 생성할 수 있는 기능을 개발했다. 이미 3D 캔버스 구조인 내 툴에서 곧바로 3D 모델을 사용할 수 있게 했다

저의 AI 툴의 방향성과 활용 방식은 어느 정도 명확해진 상태였습니다. 그렇지만 개인적으로는 앞으로 다양한 API들을 활용할 수 있는데 이미지 생성과 편집에만 머무를 수는 없다 생각했습니다. 텍스트, 이미지를 넘어 업스케일링과 3D / 비디오 생성까지 이어져야 한다고 생각했습니다. 2025년에는 3D 생성 모델과 비디오 생성 모델들도 급격히 발전하기 시작했기 때문에 플랫폼에서 텍스트부터 영상까지 하나의 흐름으로 고도화하겠다는 의지가 더욱 강해졌습니다.

제각각인 AI들, API 활용의 어려움

다만 개인 단위에서 여러 미디어 영역의 개별 AI 모델들을 API로 모두 끌어와 하나의 플랫폼에 연결하기란 굉장히 번거로운 일이었습니다. 이미지, 영상, 업스케일링등을 위한 AI 모델 개발사들도 서로 다르고 API를 제공하는 방식도 모두 제각각이었기 때문입니다.

당시에는 지금처럼 똑똑한 AI 개발 에이전트도 없었습니다. ChatGPT나 Claude(클로드 코드가 아닌 그냥 클로드)등 LLM 플랫폼의 채팅 인터페이스에 코드를 붙여 넣으며 부분적으로 도움을 받을 수는 있었지만, 결국 대부분의 구조는 제가 직접 설계하고 구현하고 있었습니다.

2024년 말까지만 하더라도 FLUX API를 사용하기 위해 FLUX 모델의 개발사인 Black Forest Lab에서 직접 API를 끌어왔습니다. 서로 다른 개발사의 AI 모델들을 툴에 붙이려니 매번 새로운 백엔드 구조를 만들고 프런트앤드도 이에 맞게 모델 별로 서로 다르게 하나하나 수정해야 했습니다.

공개된 AI 모델 소스들을 모아 놓은 플랫폼들의 등장

그런데 이런 아이디어는 그동안 파편화됐던 AI 소스들을 하나로 모아 연결하고 활용할 수 있게 해주는 서비스들의 등장으로 구체화되기 시작했습니다.

이미 다양한 AI 모델을 한 곳에서 공유하는 플랫폼들은 존재했습니다. 대표적으로 Hugging Face는 2020년 이후 모델 허브를 중심으로 자연어 처리(NLP) 모델들을 공유하고 배포하는 플랫폼으로 성장했습니다. 당시 이미지 생성 AI 등 미디어 영역은 아직 실험적인 단계에 머물러 있었기 때문에 주로 언어 모델 중심으로 발전해 왔고, 자연스럽게 개발자들에게 높은 인지도를 갖게 되었습니다.

2020년대에 들어서 스테이블 디퓨전의 대중화와 함께 관련 생태계가 빠르게 확장되면서, Checkpoint 모델과 LoRA 모델을 공유하고 배포하는 Civitai와 같은 플랫폼이 등장했습니다. Hugging Face가 개발자 중심의 인터페이스로 구성되어 있었다면, Civitai는 훨씬 직관적인 UI를 통해 디자이너들도 쉽게 모델을 탐색하고 사용할 수 있게 만들었습니다. 특히 Hugging Face나 Github에 흩어져 있던 스테이블 디퓨전 관련 모델들을 한곳에서 모아볼 수 있다는 점에서 진입장벽을 크게 낮췄습니다. FLUX가 대중에게 공개되기 전, 2024년 하반기 이전까지는 저도 Civitai에서 모델을 다운로드하여 ComfyUI에서 활용하는 워크플로우를 현업 과제를 위해 주로 사용했던 것 같습니다.

문제는 모델이 아니라 인터페이스였습니다.

그 당시, 2024년 말에서 2025년 초를 떠올려봤을 때 창작자들이 아직까지 다양한 AI 활용을 주저했던 이유는 여전히 낮은 퀄리티의 문제도 있었지만 바로 그들에게 친화적인 인터페이스가 부재했기 때문이었습니다. 그래서 여러 AI 모델들을 하나의 웹사이트에서 검색하고 다운로드할 수 있게 해주는 플랫폼에서 직접 원하는 모델들을 다운로드하여 활용할 수 있음에도 대부분 그러지 못했습니다. 여전히 많은 창작자들이 개별 미디어 영역에서 이미지는 미드저니와 영상은 런웨이등으로 친숙하고 편리한 인터페이스를 제공하는 플랫폼들을 이용했습니다.

그 당시 그런 움직임들의 최전선에서 저는 제 프로토타입의 방향성에 대해 더욱 확신하고 다음 목표를 결정할 수 있었습니다. 이미지와 영상, 업스케일링까지 API로 AI 모델들을 모아서 디자이너들이나 기획자들에게 익숙한 UI로 제공하는 것.

인터페이스는 갖췄다지만

어디서 어떻게 여러 AI 모델의 API를 수급할 것인가

이미 3D를 중심으로 한 웹 기반 AI 인터페이스를 완성해 놓았으나 아직까지 이미지 생성 부분은 Black Forest Lab이 직접 제공해 주는 FLUX api 하나에 의존하고 있었고 다른 AI 모델을 연결하기 위해서 별도의 구조를 새로 짜야했습니다.

남은 건 하나였습니다. 저의 툴 구조에 가장 빠르게 붙일 수 있는 API 중개 플랫폼을 선택하는 일이었습니다. Hugging Face와 Civitai 등은 제 툴을 디벨롭시키고 있던 2025년 상반기에는 단순히 배포된 여러 AI 모델을 로컬 PC에 다운로드할 수 있게는 해주었으나 API 형식으로 직접 제공하지는 않았습니다. 이들을 직접 개발하고 있는 웹 기반 플랫폼에 탑재하기 위해서는 서버 컴퓨터에 해당 모델들을 직접 설치하고 연동하기 위한 복잡한 개발 과정이 필요했습니다.

Replicate의 발견: API를 간편하게

그때 발견한 Replicate.ai 는 여러 모델들을 단일화된 구조 안에서 REST API로 직접 제공해 주었습니다. 모델들을 직접 다운로드하여 별도로 재배포하고 API 용도로 재가공하지 않아도 Replicate.ai 에서 그들의 SDK로 빠르고 쉽게 자바스크립트 프레임워크 기반의 제 플랫폼에 다양한 AI 모델을 탑재할 수 있었습니다.

Replicate의 발견은 1인 개발 구조에서 여러 AI 모델들을 API 형식으로 활용해 통합적인 AI 플랫폼을 설계할 수 있겠다는 아이디어를 실제로 빠르게 실행할 수 있게 해 주었습니다. 기존에는 굉장히 복잡한 과정, 그리고 모델마다 서로 다른 서버 로직을 사용해야 했다면 Replicate를 통하니 통일된 구조의 REST API로 모델 URL만 변경해 요청을 보내면 곧바로 여러 모델을 자체 플랫폼 내에서 활용할 수 있게 해 주었습니다. 즉, AI 모델의 종류와 관계없이 AI 콘텐츠 생성 요청, 응답 구조를 단일화하고 모듈화 할 수 있게 된 것입니다.

2025년 봄, 곧바로 직접 개발사를 통해 제공받아 활용한 FLUX API 단일 체제였던 백엔드 구조를 Replicate 중심으로 개편했습니다. 이제 FLUX 뿐 아니라 기존 스테이블 디퓨전 모델들, 당시 새롭게 등장한 구글의 IMAGEN, 이디오그램 등의 이미지 모델들을 툴에서 제공할 수 있었고 특히 커스텀 ComfyUI 워크플로우도 Replicate를 통해 API화 하여 개별 플랫폼에 탑재할 수 있었습니다.

이제 제 툴 안에서 유저는 하나의 프롬프트로 여러 모델로 결과물을 동시에 생성하게 됐습니다. 여러 AI 모델들의 결과물 중 가장 잘 나온 것을 골라 활용할 수 있게 됐습니다.

Replicate에서 Fal로 전환: 더 빠르게!

Replicate를 활용하고 느낀 한계: 속도 저하에 따른 경험 저하

2024년 12월부터 2025년 상반기까지 저는 저의 툴에 매주 새롭게 공개되는 최신 이미지 편집, 비디오 생성, 업스케일링, 3D 생성 영역에서의 수많은 AI 모델들을 Replicate를 통해 빠르고 쉽게 탑재할 수 있었습니다. 그런데 이미지 생성 모델에서도 여러 종류의 AI 모델들을 끌어오고 3D 생성 AI, 비디오 생성 AI 모델도 툴에 통합하면서 Replicate 구조에 한계를 느끼게 됐습니다.

자주 사용되지 않아 Cold 상태인 모델은 부팅 시간이 필요한 Replicate.

Replicate를 통해 다양한 모델들을 제 툴에서 연결할 수 있었지만 속도와 응답성 측면에서 아쉬움이 있었습니다. Replicate는 AI 모델마다 컴퓨터를 하나 대여하는 개념이었습니다. 예를 들어 구글의 IMAGEN 이미지 생성 모델 하나를 API로 사용하기 위해 Replicate에 API 요청을 보내면 Replicate는 IMAGEN 모델이 설치된 서버 컴퓨터를 켜서 그 컴퓨터가 켜지면 생성을 시작합니다. 그래서 Cold time이라는 지연 시간이 존재했습니다. 만약 인기 있는 모델이라면 컴퓨터가 이미 켜져 있을 가능성이 높지만 자주 사용하는 모델이 아니라면 그 서버 컴퓨터가 꺼져있을 때가 많아서 요청과 응답 시간 지연이 꽤나 길어졌습니다.

이런 단점은 제가 추구하는 AI 에디터의 성격에 맞지 않았습니다. 여러 미디어 영역의 AI 생성 모델들을 동시 다발적으로 빠르게 하나의 화면에서 제공하고자 했지만 여러 모델을 바꿔가며 사용하면서 발생하는 지연시간은 사용 경험을 크게 해칠게 분명했습니다. 이미 생성형 AI가 이미지를 만들고 비디오를 만드는 시간도 짧지 않은데 서버 컴퓨터가 켜지기 위한 지연 시간까지 고려하고 싶지 않았습니다.

Fal의 발견: 콜드 스타트가 없어 더 빠르게, 훨씬 간편한 SDK

어떻게 하면 더 연속적인 워크플로우를 여러 API를 엮어서 빠르게 제공할 수 있을까 고민하다가 Fal.ai를 발견했습니다. Fal.ai는 제가 처음 툴을 설계할 때는 발견하지 못했었는데 Replicate와 같이 여러 AI 모델을 API 형태로 실행할 수 있도록 중개해 주는 인프라 레이어였습니다. Fal이 Replicate 보다는 늦게 2021년 공개된 신생 플랫폼이었습니다.

Fal은 Replicate의 방식과는 다르게 상시 실행되는 GPU 풀을 기반으로 콜드 스타트 없이 즉시 생성이 가능한 구조였습니다. 앞으로 저 혼자 개발하면서 다양한 모델 환경에 빠르게 대응하고 유저 요청에 빠르게 응답하는 데는 Fal.ai 가 적합했습니다. 저는 결국 툴의 AI API 구조를 Fal 기반으로 다시 설계하고 AI 생성 부분에서의 모듈 구조를 완성할 수 있었습니다.

멀티 모달 AI 에디터 구조의 완성

여러 개발사의 생성 모델을 선택해 활용할 수 있고 Gemini 등의 LLM을 연결해 프롬프트 강화도 가능해졌다. API 구조 효율화로 여러 모데를 빠르게 조합해 기능화가 가능했다.

멀티모달 API 구조화 전,

단일 AI 이미지 생성 + 3D 캔버스 기능단의 인터페이스만 존재

멀티모달 API 구조화 후,

이미지/영상 생성 /3D 생성 인터페이스 업데이트와 연속적인 생성 결과물 히스토리 관리를 위한 라이브러리 기능의 추가

여러 생성형 AI 모델들을 동시 다발적으로 사용하게 되면서 생성 결과물을 리스트업 하는 라이브러리 기능을 필수적으로 개발해 툴에 업데이트하게 됐다.

여러 생성형 AI 모델들을 동시 다발적으로 사용하게 되면서 생성 결과물을 리스트업 하는 라이브러리 기능을 필수적으로 개발해 툴에 업데이트하게 됐다.

그때부터 제 툴은 단일 모델 기반 도구에서, 여러 모델을 선택하고 조합하는 완전한 멀티모달 AI 플랫폼으로 변하기 시작했습니다. 여러 모델을 API를 통해 제 플랫폼으로 끌어오는 것을 효율화한 직 후 저는 더 이상 하나의 모델을 어떻게 끌어올지를 고민하지 않고 여러 모델을 연결하는 구조를 만들고 워크플로우를 설계해 제공하는 것에 집중할 수 있게 됐습니다.