Python 50줄로 로컬 LLM을 위한 초간단 API 게이트웨이 구축하기

저는 로컬 LLM(Large Language Models)이 설치된 세 대의 머신을 운영하고 있습니다. M4 칩이 탑재된 Mac Mini, RTX 3060이 장착된 Windows PC, 그리고 몇 개의 구형 GPU가 있는 Ubuntu 서버입니다. 각 머신에는 Ollama가 설치되어 있으며, 각각 서로 다른 모델들이 로드되어 있습니다.

몇 달 동안 저는 스크립트에 URL을 하드코딩(Hardcoded)하여 사용했습니다. 빠른 답변이 필요하면 Mac에 쿼리(Query)를 보내고, 코딩 어시스턴트가 필요하면 Windows 머신에 요청하고, 거대 모델이 필요하면 Ubuntu 서버를 기다려야 했습니다.

이 과정은 매우 번거로웠습니다. 그래서 요청을 자동으로 라우팅(Routing)하는 아주 작은 API 게이트웨이(API Gateway)를 만들었습니다. 만드는 데는 오후 한나절이 걸렸고, 단 하나의 Python 파일로 실행됩니다. 그리고 이것은 제가 로컬 AI 설정을 사용하는 방식을 완전히 바꾸어 놓았습니다.

문제점: 세 개의 URL, 로직은 제로

게이트웨이를 만들기 전, 제 스크립트들은 다음과 같은 모습이었습니다:

# quick_question.py
import requests

...

# code_review.py
import requests

...

# hard_question.py
import requests

...

세 개의 스크립트, 세 개의 URL, 그리고 유연성은 전혀 없었습니다. 만약 Windows 머신이 오프라인 상태라면 코딩 스크립트는 그냥 실패했습니다. 새로운 모델을 추가할 때마다 모든 것을 수동으로 업데이트해야 했습니다.

해결책: 아주 단순한 게이트웨이

저는 단 하나의 URL과 하나의 API를 원했습니다. 게이트웨이가 어떤 머신이 요청을 처리할 수 있는지 판단하게 만들고 싶었습니다.

제가 만든 것은 다음과 같습니다:

# gateway.py
from flask import Flask, request, jsonify
import requests
...

그게 전부입니다. 50줄입니다. 어떤 머신에서든 실행하고, 모든 스크립트의 목적지를 http://gateway:11435로 지정하기만 하면 어떤 박스에 어떤 모델이 있는지 신경 쓸 필요가 없습니다.

예상보다 더 좋았던 이유

모델을 자유롭게 옮길 수 있습니다. Windows 머신에 새 GPU를 장착했을 때, 큰 코딩 모델을 그곳으로 옮겼습니다. MACHINES 설정에서 한 줄만 수정하면 되었습니다. 모든 스크립트는 계속 정상적으로 작동했습니다.

헬스 체크(Health checks)가 매우 간단합니다. 각 머신에 핑(Ping)을 보내는 /health 엔드포인트(Endpoint)를 추가했습니다. 머신 하나가 다운되면, 메인 스크립트가 이를 인지하고 해당 머신을 제외하고 라우팅합니다.

로드 밸런싱(Load balancing)이 명확합니다. 두 대의 머신에 동일한 모델이 있는 경우, 덜 바쁜 머신을 선택할 수 있습니다. 아직 이 기능이 필요했던 적은 없지만, 구조적으로 지원이 가능합니다.

제 스크립트들이 더 멍청해졌습니다. 좋은 의미로 말이죠. 이제 스크립트들은 인프라(infrastructure)에 대해 알 필요가 없습니다. 그저 모델을 요청하고 답변을 받기만 하면 됩니다.

제가 (의도적으로) 만들지 않은 것들

데이터베이스(database) 없음. 설정 파일(config files) 없음. Docker 없음. Kubernetes 없음. "서비스 메시 (service mesh)"도 없습니다.

이것은 딕셔너리(dictionary)가 포함된 단 하나의 Python 파일입니다. 무언가를 변경해야 한다면, 파일을 수정하고 재시작하면 됩니다. 10초면 충분합니다.

YAML 설정, 핫 리로딩 (hot reloading), Prometheus 메트릭 (Prometheus metrics) 등을 갖춘 "제대로 된" 시스템을 만들까 생각도 해봤습니다. 하지만 이것은 제 홈 랩 (home lab)을 위한 것입니다. 사용자는 저뿐입니다. 복잡함은 적입니다.

진짜 승리: 정신적 과부하 (Mental Overhead) 감소

게이트웨이(gateway)를 만들기 전에는 로컬 AI를 사용하는 것이 마치 업무처럼 느껴졌습니다. 스크립트를 열고, 어떤 머신에 어떤 모델이 있는지 기억해내고, 머신이 온라인 상태인지 확인한 다음, 쿼리(query)를 날려야 했습니다.

이제는 마치... API를 사용하는 것 같습니다. 어떤 API든 말이죠. 인프라에 대해 생각하지 않습니다. 그저 프롬프트 (prompt)를 작성하고 결과를 얻을 뿐입니다.

그것이 인프라의 존재 이유입니다. 인프라는 사라져야 합니다.

수치 (그냥 궁금하니까요)

• Python 코드 라인 수: 50줄
• 구축 시간: 2시간 (테스트 포함)
• 주당 절약된 시간: 약 30분 ("이게 어느 머신에 있었더라?"라고 고민하는 시간)
• 추가 의존성 (dependencies): Flask (다른 프로젝트를 위해 이미 설치됨)
• 비용: $0

시작하기

여러 개의 Ollama 인스턴스 (instances)를 운영 중이라면, 위 스크립트를 그대로 복사해서 붙여넣고 IP와 모델만 변경하면 끝납니다.

pip install flask requests
python gateway.py

그 다음 스크립트에서는 다음과 같이 사용합니다:

import requests

# 하나의 URL. 어떤 모델이든 상관없음. 게이트웨이가 나머지를 처리함.
...

솔직한 결론

이것이 프로덕션 환경(production-ready)에 적합하냐고요? 아니요. 예외 상황(edge cases)을 처리하냐고요? 거의 못 합니다. 제 홈 랩에 충분하냐고요? 당연합니다.

때로는 올바른 아키텍처(architecture)란 실제로 유지보수할 수 있는 아키텍처를 의미합니다. 머릿속으로 디버깅할 수 있는 50줄짜리 Python 파일이, 결코 완성하지 못할 "제대로 된" 솔루션보다 훨씬 낫습니다.

만약 여러 개의 Ollama 인스턴스를 운영하며 수동으로 전환하고 있다면 — 그냥 게이트웨이를 만드세요. 오후 한나절이면 충분하며, 다시는 머신 IP에 대해 고민할 필요가 없게 만들어 줄 것입니다.

Sam Hartley는 터키에서 다중 머신 AI 홈 랩 (home lab)을 운영하는 1인 개발자입니다. 로컬 AI를 실제로 사용 가능하게 만드는 지루한 인프라(infrastructure)에 대해 글을 씁.

→ Fiverr의 커스텀 자동화 설정 (Custom automation setups on Fiverr)
→ Telegram에서 CelebiBots 팔로우하기 (Follow CelebiBots on Telegram)

ai #ollama #selfhosted #api #python #homelab #buildinpublic