스크립트
00:00:00한 달에 약 40억 개의 LLM 토큰을 무료로 얻고 단일한
00:00:05OpenAI 호환 엔드포인트를 통해 사용할 수 있습니다. 제공자를 끊임없이 전환할 필요 없이
00:00:10이 모든 걸 할 수 있죠. 정말 멋진 일입니다. 이것이 바로 Free LLM API입니다. 이름이 좀 뻔하긴 한데,
00:00:1728개 제공자의 무료 티어를 모은 다음, 자동으로 라우팅하고 장애 복구(failover)를 처리해 줍니다. GitHub에서
00:00:23이미 스타 18,000개를 넘었으며, 1분 안에 실행할 수 있습니다. 그런 다음 40억 개의
00:00:28무료 토큰이 실제로 유용한지, 아니면 그냥 말장난에 불과한지 알아보겠습니다.
00:00:36자, 우리가 처한 상황은 좀 묘합니다. 실제로 사용할 수 있는 무료 LLM 용량이 꽤 많거든요.
00:00:43Grok에도 무료 티어가 있습니다. Cerebras에도 있고, Google에도 있죠. Mistral과 NVIDIA, OpenRouter의 오픈 모델도
00:00:50무료입니다. 이미 시중에 나와 있는 게 많죠. 그래서 이미 문제가 해결되었다고 생각할 수 있습니다. 하지만
00:00:54우리 중 많은 이들이 알듯이 그렇지 않습니다. 왜냐하면 이제 API 키도 다르고, 대시보드도 다르며,
00:01:01요청 제한(rate limit), 모델 이름, 그리고 API도 조금씩 다르기 때문입니다. 그리고 코딩
00:01:06에이전트를 사용하신다면 다음에 무슨 일이 일어나는지 잘 아실 겁니다. 작업 시작한 지 10분 만에 제공자 제한에 걸리고,
00:01:11이제 키를 교체하거나, 모델을 바꾸거나, 설정 파일을 수정하느라 하던 일을 멈추게 되죠.
00:01:16추론 자체는 무료지만, 무료 추론을 관리하는 게 짜증 나는 부분입니다. 바로 그것을 해결해 주는 것이
00:01:22Free LLM API입니다. 여기에 제공자 키를 입력하면 됩니다. 할당량, 상태, 요청 제한을 추적하고, 제공자 간에 요청을
00:01:28라우팅해 줍니다. 그리고 하나가 제한에 걸리면, 알아서 다른 쪽으로 넘어갈 수 있죠. 하지만
00:01:35여러분의 도구는 단 하나의 엔드포인트만 보게 됩니다. 따라서 Cursor, Claude Code, Codex CLI, 심지어 여러분의 스크립트조차도
00:01:42그 뒤에서 무슨 일이 일어나고 있는지 알 필요가 없습니다. 한번 설정해 봅시다. 워크숍을 가속하는 코딩 도구를 좋아하신다면
00:01:46구독해 주세요. 유용한 영상들이 계속 업로드됩니다. 좋습니다. 솔직히 제가 찾은 가장 좋은 방법은
00:01:52Docker로 실행하는 것입니다. 간단히 git clone을 하고 해당 디렉토리로 이동합니다. 필요한 32바이트
00:01:57암호화 키를 생성한 다음, Docker Compose를 실행하면 됩니다. 실행되고 나면 로컬
00:02:03대시보드가 나타납니다. 잠시 후에 살펴보겠지만, 먼저 API 키부터 설정해야 합니다. 보시다시피 여기에 이 모든 옵션의
00:02:10API 키를 추가했습니다. Google, Grok, Cerebras, Mistral, OpenRouter가 있습니다. 이 목록에서 원하는 만큼
00:02:17얼마든지 추가할 수 있습니다. 이 자격 증명은 로컬에 암호화되어 저장됩니다. 그리고 추가된 후,
00:02:24Free LLM API는 구성한 제공자들로부터 모델 카탈로그를 빌드합니다. 그런 다음 모델 탭에서 내 월간 토큰이
00:02:31얼마나 남았는지 확인할 수 있습니다. 꽤 많죠. 그리고 이 토큰들을 모두 얻기 위해 실행될 모든 모델도 볼 수 있습니다.
00:02:37아래로 조금 더 내려가면 라우팅 전략을 선택할 수도 있는데, 저는 balance로 설정했으며 현재
00:02:44지능순으로 순위가 매겨져 있습니다. Playground에서 간단한 테스트를 실행해 볼 수 있습니다. 이 프롬프트를 실행해 보면,
00:02:51결과가 반환됩니다. 이제 준비는 끝났습니다. 하지만 진짜 중요한 부분은 따로 있습니다. 유용한 점은 더 이상
00:02:57제가 직접 설정할 필요가 없다는 것입니다. 모든 코딩 도구를 Grok, Google, 그리고
00:03:03Cerebras에 직접 연결하는 대신, 이 도구를 여기에 연결합니다. API 키는 단 하나이며, Free LLM API를 사용하는 거죠. 자, 이것이
00:03:10통합 과정의 전부입니다. 일반 OpenAI 클라이언트를 사용하는 경우에도 아이디어는 같습니다.
00:03:16어떻게 작동하는지 확인하기 위해 좀 더 긴 코딩 작업을 시켜보겠습니다. 그래서 이 파이썬
00:03:23스크립트를 작성하여 제 API 키를 사용하도록 했습니다. 클라이언트 인스턴스에 앞서 얻은 Free LLM API 키를
00:03:31전달하는 것을 볼 수 있습니다. 모든 요구사항을 갖춘 파이썬 CLI 작업 관리자를 빌드해 달라고 요청하겠습니다.
00:03:38좋습니다. 간단한 프로젝트이지만 한번 실행해 보겠습니다. 그 추론 과정을 보고 싶네요. 또한
00:03:43여러 개의 파일을 작성하고 리드미(README) 파일도 함께 반환해야 합니다. 실행하고 잠시
00:03:49기다려 보겠습니다. 아직까지는 특별히 놀라운 점은 없습니다. 내 애플리케이션이 더 이상 제공자를 선택하지 않고,
00:03:54라우터가 선택하기 때문입니다. 따라서 이 제공자의 요청 제한이 걸리거나 상태가 안 좋아지면,
00:03:59Free LLM API는 에이전트가 작업 도중 중단되는 대신 요청을 다른 곳으로 옮겨줄 수 있습니다.
00:04:05이제 제 스크립트와 코딩 에이전트들은 하나의 작은 무료 할당량 뒤에 갇혀 있지 않습니다. 풀(pool)을
00:04:10사용하고 있죠. 코드가 반환한 최종 출력은 단순한 터미널 출력입니다.
00:04:16그래서 제가 직접 파일들을 만들었습니다. 이제 실행해서 테스트해 보겠습니다. 모든 게 아주 잘 작동합니다. 하지만
00:04:22이 프로젝트는 토큰을 2,000개 미만으로 적게 사용하여 매우 간단했다는 것을 알 수 있습니다.
00:04:29이 모든 게 좋아 보이지만, 한 가지 명확한 의문이 듭니다. 시스템이 실제로 어디로
00:04:34요청을 보낼지 어떻게 결정할까요? 사실 이 모든 과정은 꽤 간단합니다. 제공자 키는 로컬에 암호화되어 유지됩니다.
00:04:40여러분의 요청이 Free LLM API로 들어오면, 라우터가 사용 가능한 제공자를 확인합니다.
00:04:47어떤 제공자가 정상이고 어떤 제공자가 요청 제한이나 할당량 문제에 부딪혔는지 파악한 다음, 요청을
00:04:53보냅니다. 여러분의 도구는 여전히 OpenAI 호환 엔드포인트를 포함해 익숙한 API 인터페이스로 통신합니다.
00:04:59따라서 애플리케이션 관점에서는 복잡한 일이 전혀 일어나지 않습니다. 이렇게 생각하시면 됩니다.
00:05:05좋습니다. 우리의 코딩 에이전트는 단 하나의 문을 보게 됩니다. 그 문 뒤에서 Free LLM API가 어떤
00:05:12제공자가 실제로 응답해야 하는지 결정합니다. 이것이 바로 이 프로젝트가 정말 흥미로운 이유입니다. 이제 이 모든 것을
00:05:17알아서 처리해 주죠. 예전에는 무료 티어를 사용하려면 모델을 직접 여러 번 테스트해야 했습니다. 하지만 이제는
00:05:24충분한 무료 추론이 여러 제공자에 분산되어 있어서 합쳐진 용량이 꽤 쓸만합니다. 그래서
00:05:30문제가 바뀌었습니다. 예전의 문제는 '무료 추론을 어디서 구할 수 있을까?'였다면, 이제는 '이 모든 것을
00:05:37일일이 관리하지 않고 어떻게 다 쓸 수 있을까?'입니다. 그것이 바로 Free LLM API가 해결하고자 하는 문제입니다. 개발자인 우리에게는
00:05:43이게 중요한 명백한 상황들이 많이 있습니다. 몇 초의 지연 시간이 추가되어도 큰 문제가 되지 않는
00:05:50에이전트 루프라든가, 단순 테스트나 유료 모델로 넘어가기 전 프로토타이핑,
00:05:56유료 크레딧을 계속 소모하지 않고 여러 코딩 에이전트를 실행하는 경우 등 다양합니다.
00:06:01이 도구가 매우 유용해질 수 있는 이유는 엄청납니다. 단순히 배우거나 사이드 프로젝트를
00:06:06가지고 놀 때도 마찬가지입니다. 기본적으로 완벽하게 일정한 지연 시간보다 비용이 더 중요한 워크로드에 적합하죠.
00:06:11이 모든 것 사이에서 그 점은 중요한 요소입니다. 일단 그것을 이해하고 나면, 왜 이것이
00:06:15단순히 로고만 바뀐 OpenRouter나 LiteLLM이 아닌지도 이해할 수 있게 됩니다. 그렇다면 왜 그냥 OpenRouter나
00:06:21LiteLLM을 쓰지 않을까요? 겹치는 부분은 여전히 존재하지만 목표가 다르기 때문입니다. OpenRouter로 시작해보면,
00:06:27다양한 모델에 액세스할 수 있는 관리형 API를 원한다면 OpenRouter는 엄청나게
00:06:32편리합니다. 무료 모델도 제공하지만 호스팅 방식입니다. 요청이 OpenRouter를 거치며 해당 플랫폼에서
00:06:38사용 가능한 용량을 쓰는 것입니다. 반면 Free LLM API는 다르게 작동합니다. 여러분이 직접 제공받은 계정과
00:06:44무료 티어 할당량을 결합하는 방식입니다. 그것들을 풀(pool)로 묶는 것이죠. 그리고 LiteLLM이 있습니다.
00:06:51애플리케이션을 위해 본격적인 다중 제공자 게이트웨이를 구축하는 중이라면 그것은 완전히 다른 이야기입니다.
00:06:57범위가 더 넓고, 설정 가능하며, 훨씬 프로덕션 지향적입니다. 하지만 유연성이 높다는 것은
00:07:03라우팅 전략을 직접 설정하고 환경을 유지 관리해야 한다는 뜻이기도 합니다. Free LLM API는 훨씬 더 좁은
00:07:09역할을 가집니다. 이미 가지고 있는 무료 용량을 가져와서 더 쉽게 사용할 수 있게 만드는 것,
00:07:14그게 전부입니다. 따라서 이걸 모든 LLM 게이트웨이의 대체품으로 볼 필요는 없습니다.
00:07:20무료 티어 극대화 도구로 보는 것이 좋습니다. 하지만 이것을 유용하게 만드는 바로 그 특성이 가장 큰 약점도 만들어냅니다.
00:07:27먼저 잘하는 것부터 살펴보죠. 첫째, 풀링된 용량입니다. 하나의 작은 무료 티어는 그다지 유용하지 않지만, 여러 개를
00:07:32모으면 실제로 일을 처리할 수 있게 됩니다. 둘째, 하나의 키와 하나의 엔드포인트입니다. 이것이 아마도
00:07:39가장 큰 삶의 질 향상일 것입니다. 코딩 에이전트를 한 번만 설정해 두면 각 요청에 어떤
00:07:46제공자가 응답하는지 신경 쓰지 않아도 됩니다. 엄청난 장점이죠. 다음은 로컬 퍼스트입니다. 제공자 자격 증명이 다른 호스팅 라우팅 서비스로 넘어가지 않고 내 기기에 머뭅니다.
00:07:54마지막으로 장애 복구(failover)입니다. 무료 티어는 불안정하기 때문에, 이것은 우리가 얻는 토큰 수보다
00:07:59제게 더 중요합니다. 요청 제한이 있고, 일일 한도가 있으며, 수시로 바뀝니다. 따라서 가치 있는 부분은 단순히 여러 제공자를
00:08:05가지는 데에만 있지 않습니다. 무언가 작동을 멈췄을 때 다른 곳으로 전환할 수 있다는 점에 있습니다.
00:08:11하지만 함정이 있습니다. 불안정한 무료 서비스들을 모아둔다고 해서 모든 게 해결되고 안정적으로 변하는 것은 아닙니다.
00:08:16하루의 시작에는 선호하는 무료 모델을 사용할 수 있겠지만, 시간이 지나면 해당 할당량을 다 소모하게 됩니다.
00:08:21그럼 어떻게 될까요? 이제 요청이 애초에 선택하지 않았을지도 모르는 곳으로 라우팅될 수 있습니다.
00:08:27따라서 모델 품질이 달라질 수 있고, 지연 시간도 달라질 수 있으며, 최고급(frontier) 모델에 대한 무제한 액세스를
00:08:32갑자기 얻게 되는 것은 아닙니다. 여러분의 워크플로우가 매 순간 최고의 모델에 절대적으로 의존한다면,
00:08:37이 도구는 그것을 해결해주지 못합니다. 이 위에 프로덕션 인프라를 구축해 놓고 무료
00:08:42티어를 유료 인프라처럼 쓸 수는 없습니다. 절대 안 됩니다. 제공자는 할당량을 바꿀 수 있고, 모델이 사라질 수도 있으며,
00:08:46많은 것들이 아주 빠르게 바뀔 수 있습니다. 저장소 링크는 아래에 남겨두겠습니다.
00:08:52마땅히 쓸 곳 없이 굴러다니는 무료 티어 키가 있다면, 그것들로부터 얼마나 유용한 용량을
00:08:57끌어낼 수 있는지 확인해 볼 겸 시도해 볼 가치가 충분히 있습니다.
00:09:01이와 같은 코딩 팁과 요령이 마음에 드신다면 BetterStack 채널을 구독해 주세요.
00:09:05다음 영상에서 뵙겠습니다.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기