100 만 Gradio 사용자를 향한 여정!

5 년 전, 우리는 스탠포드의 연구자들이 웹 인터페이스로 컴퓨터 비전 모델을 쉽게 데모할 수 있도록 간단한 Python 라이브러리인 Gradio 를 출시했습니다.

오늘날, Gradio 는 매달 >100 만 명의 개발자가 AI 웹 애플리케이션을 구축하고 공유하는 데 사용되고 있습니다. 이는 Automatic1111, Oobabooga 의 Text Generation WebUI, Dall-E Mini, LLaMA-Factory 와 같은 모든 시대의 가장 인기 있는 오픈소스 프로젝트 중 일부를 포함합니다.

우리는 어떻게 여기까지 왔나요? Gradio 는 왜 매우 혼잡한 오픈소스 Python 라이브러리 분야에서 계속 성장했을까요? 저는 이 질문을 많은 사람들이 자신의 오픈소스 라이브러리를 구축하는 과정에서 자주 듣습니다. 이 글은 지난 몇 년 동안 배운 교훈 중 일부를 요약합니다:

• 좋은 기본 구조 (primitives) 에 투자하고, 높은 수준의 추상화 (high-level abstractions) 에는 투자하지 마세요.
• 라이브러리에 직접적인 바이러스성 (virality) 을 포함하세요.
• 성장하는 틈새 시장 (niche) 에 집중하세요.
• 유일한 로드맵은 빠른 반복 (rapid iteration) 이여야 합니다.
• 사용자가 라이브러리의 출력을 소비할 수 있는 방법을 최대한 극대화하세요.

1. 좋은 기본 구조 (primitives) 에 투자하고, 높은 수준의 추상화 (high-level abstractions) 에는 투자하지 마세요.

우리가 Gradio 를 처음 출시했을 때, 우리는 하나의 높은 수준의 클래스 (gr.Interface) 만을 제공하여 단일 Python 함수에서 완전한 웹 애플리케이션을 생성했습니다. 우리는 개발자들이 다른 종류의 애플리케이션을 만들고 싶어한다는 것을 빠르게 깨달았습니다 (예: 다단계 워크플로우, 챗봇, 스트리밍 애플리케이션). 그러나 우리가 사용자가 구축하고 싶은 애플리케이션 목록을 작성하기 시작했을 때, 우리가 해야 할 일을 깨달았습니다: 더 낮은 수준으로 내려가세요.

다양한 사용 사례를 지원하기 위해 많은 높은 수준의 클래스를 구축하는 대신, 우리는 모듈형 컴포넌트, 이벤트, 레이아웃에서 애플리케이션을 조립할 수 있도록 사용자를 위한 Gradio Blocks 라는 낮은 수준의 API 를 구축했습니다. 일반적으로 더 많은 작업이 필요하지만, gr.Blocks 는 오늘날 Gradio 의 80% 의 사용량을 대표합니다—위에서 언급한 인기 있는 애플리케이션들을 포함합니다.

작은 팀으로, 낮은 수준 추상화에 집중하는 것은 우리가 많은 유혹적인 높은 수준의 추상화를 쫓을 수 없음을 의미했습니다. 그러나 이 집중은 두 가지 일반적인 함정에서 우리를 구해냈습니다:

커스터마이징 유지보수 함정 (Customization-maintenance trap): 높은 수준의 추상화는 사용하기 쉽지만, 사용자들이 커스터마이징을 위해 추가 파라미터를 요청하면, 모든 추상화와 파라미터가 구현되고 유지보수되고 테스트되어야 오류를 방지하기 때문에 유지보수 부담이 증가합니다.

생산성 환상 (The productivity illusion): 높은 수준의 추상화를 사용하는 것은 더 적은 작업처럼 보이지만, 사용자가 지원되지 않는 기능을 필요로 할 때 (이는 프로젝트 초기에는 예측하기 어려울 수 있음), 개발자는 비용이 많이 드는 리스크를 겪게 됩니다.

첫 번째 문제는 Gradio 의 유지보수자로서 우리의 시간을 낭비하고, 두 번째 문제는 사용자의 시간을 낭비합니다. 오늘날까지, Gradio 는 두 개의 높은 수준의 추상화 (gr.Interface 와 gr.ChatInterface) 만을 포함하며, 이 자체는 Blocks 로 구축됩니다.

좋은 기본 구조를 가진다는 장점은 AI 보조 코딩 시대에 더욱 극적으로 나타납니다. 우리는 LLM 이 일반적으로 문서와 복잡한 애플리케이션을 조합하여 구축하는 데 능숙하다는 것을 발견합니다 (예: three.js 를 사용하여 만든 모든 게임). AI 가 코드를 작성해 주면, 낮은 수준의 코드를 작성하는 데 추가 시간이 많이 걸리지 않습니다.

2. 성장하는 틈새 시장 (niche) 에 집중하세요.

당신의 라이브러리를 가장 잘 대변하는 것은 당신 그 자체가 아니라, 열정적인 사용자입니다. 따라서 사용자들이 워크플로우의 일부로 라이브러리 또는 그 제품을 공유할 수 있는 방법을 찾아야 합니다. Gradio 의 초기 성장은 단 한 줄의 코드로 사용자의 Gradio 앱에 대한 임시 공개 링크를 생성하는 "공유 링크" 기능을 통해 추진되었습니다. 웹 서버에 올바른 컴퓨팅 리소스를 갖춘 코드 패키징이나 호스팅을 걱정하지 않아도, Gradio 사용자들은 동료들과 즉시 앱을 공유할 수 있었습니다.

Hugging Face 에 합류한 후에도 우리는 Hugging Face Spaces 의 표준 UI 로서 널리 사용됨으로써 큰 혜택을 보았습니다. 가장 많은 조회수를 기록한 Spaces 는 수백만 명의 방문자를 끌어들이며 개발자들에게 Gradio 를 노출시켰습니다. 이들은 다시 동일한 Spaces (코드가 공개적으로 이용 가능함) 을 자원으로 활용하여 Gradio 를 사용하는 방법을 배우고, 그 결과 자체 Gradio 앱을 공유하고 구축했습니다.

3. 성장하는 니치(use case) 용도를 위한 개발

초기 단계에서 우리는 결정해야 할 중요한 문제를 직면했습니다: Gradio 는 일반적인 목적의 Python 웹 프레임워크가 되거나, 아니면 기계 학습 웹 앱 구축에 특화되어 집중해야 하는 것입니까? 우리는 후자를 선택했으며, 이것이 모든 차이를 만들었습니다.

Python 웹 라이브러리의 경쟁적인 생태계에서 우리는 자주 "Gradio 와 X 는 어떻게 다른가요?"라는 질문을 받습니다. 우리의 간결한 답변—Gradio 는 기계 학습 웹 앱에 최적화되어 있음—은 기억하기 쉽고 근본적으로 정확합니다. 각 Gradio 앱은 ML 워크플로우에 특히 적합한 기능을 내장하고 있습니다: 수천 명의 동시 사용자를 포함하더라도 긴 실행 시간을 가진 ML 작업을 효율적으로 관리할 수 있는 내장 큐 (queue) 등. 우리가 설계한 컴포넌트는 ML 용도에 특화되어 있습니다. 반면, 오랫동안 Gradio 는 링크 버튼과 같은 기능을 포함하지 않았습니다. 이는 우리 핵심 사용자가 결코 필요로 하지 않았기 때문입니다. 우리의 초점을 좁히면서 Gradio 는 기계 학습 개발자들 사이에서 선택의 대상이 되었습니다—"AI 의 표준 UI".

물론, 성장하는 니치 (niche) 를 선택함으로써 우리는 엄청난 혜택을 보았습니다. 최근 AI 관련 모든 분야를 추진한 역풍은 우리에게 큰 혜택을 주었습니다. 만약 우리가 데이터 과학이나 대시보드 (dashboard) 등을 집중했다면 아마도 동일한 성장을 경험하지 못했을 것입니다.

4. 유일한 로드맵은 빠른 반복 (iteration) 여야 함

다른 일부 라이브러리와 달리 Gradio 는 로드맵을 발행하지 않습니다. 대신 우리는 기계 학습의 새로운 트렌드를 추적하고 그에 따라 제품을 출시합니다. 오픈소스 소프트웨어 전반에 걸쳐, 그리고 AI 에게 있어서는 커뮤니티의 필요성에 기반한 기능 출시 (그리고 더 이상 필요하지 않은 기능의 폐기) 는 지속적 성장의 핵심입니다. 구체적인 예를 들면, Gradio 의 초기 버전에서는 개발자들이 자신의 기계 학습 모델의 "해석"을 표시할 수 있도록 특정 기능을 구축했습니다. 이는 2020 년~21 년 사이에 매우 인기 있는 사용 사례였습니다. 해석에 대한 관심이 줄어든 후 우리는 이를 폐기하고 대신 오디오/비디오 스트리밍 및 채팅 관련 기능에 노력을 기울였습니다.

내부 프로세스 또한 분산형입니다. Gradio 팀의 11 명의 엔지니어와 개발 오토캐드 (developer advocate) 는 각자가 영향력 있는 아이디어를 식별하고, 빠르게 프로토타입을 구축하며, GitHub, Hugging Face, 소셜 미디어를 통해 오픈소스 커뮤니티와 직접 소통할 것을 권장합니다. 팀의 각 구성원은 이러한 아이디어들을 팀에 되돌려서 가장 영향력 있는 방향을 계속 성장시키면서 어떤 아이디어가 실제로 영향력을 가질 가능성이 있는지 주위에 대해 지속적으로 합의 (consensus) 를 구축하고 재구축합니다.

5. 사용자의 라이브러리를 소비하는 방식을 최대한 다양하게 만드세요

Gradio 앱과 "launch()" 를 실행할 때, 브라우저에서 웹 애플리케이션이 실행됩니다. 하지만 그뿐만 아니라, 각 Python 함수에 대한 API 엔드포인트와 해당 엔드포인트를 위한 자동으로 생성된 문서를도 제공합니다. 이 엔드포인트는 우리 팀이 구축한 Python 또는 JavaScript 클라이언트를 통해 소비할 수 있으며, cURL 을 직접 사용하여도 됩니다.

우리가 이를 하는 이유는 개발자가 Gradio 에 시간을 할애하는 분당마다 최대한 유용하게 사용되도록 하기 위함입니다. 하나의 Gradio 앱은 로컬에서 실행되거나, Hugging Face Spaces 나 서버에 코드 변경 없이 배포할 수 있으며, 프로그램적으로 더 큰 애플리케이션과 통합할 수 있거나, MCP 를 통해 AI 에이전트에 의해 활용될 수도 있습니다 (그것에 대해 곧!). 최대 사용성을 강조함으로써, 개발자들이 Gradio 라이브러리를 계속 더 많은 것을 얻을 수 있을 것이라고 희망합니다.

1000 만 대!