YC 스타트업 레스팬, 러스트 기반 AI 게이트웨이 오픈소스 공개

러스트로 만든 AI 게이트웨이, 무엇이 다른가

Y 콤비네이터 W24 배치 기업 **레스팬(Respan)**이 AI 게이트웨이를 오픈소스로 공개했다. 해커뉴스 런치 HN 게시글에 따르면 점수 26점, 댓글 14개로 개발자 커뮤니티의 초기 반응을 얻고 있다. 핵심은 플러그인 구조다. 기존 게이트웨이가 설정 파일로 동작을 바꾸는 것과 달리, 레스팬은 플러그인을 정적 컴파일로 바이너리에 포함시킨다.

성능을 위한 선택, 정적 컴파일 플러그인

개발팀은 댓글에서 G스트리머(GStreamer) 방식을 참고했다고 밝혔다. 플러그인이 핫 패스(hot path, 요청 처리 핵심 경로)에 위치해 데이터베이스나 큐 접근이 빈번한데, 이를 WASM(웹어셈블리) 샌드박스로 감싸면 오버헤드가 크다는 판단이다. 정적 컴파일로 네이티브 성능을 유지하되, 설정 변경만으로는 커스텀 로직을 넣을 수 없다. 템플릿 플러그인으로 벤더·포맷 추가는 가능하지만, 그 이상은 러스트 코드 작성 후 재빌드가 필수다.

바로 쓰기 어렵다 — 커뮤니티가 짚은 진입 장벽

해커뉴스 댓글에서 가장 많이 나온 불만은 두 가지다.

첫째, 공식 도커 이미지가 없다. 출시 직전 API 변경 가능성을 이유로 기존 이미지를 내렸다. 바이너리는 깃허브 릴리스에 있지만, 컨테이너 환경에서 바로 띄우려면 직접 이미지를 빌드해야 한다. 한 댓글 작성자는 "변경되는 API는 핑계가 안 된다, 모든 프로젝트는 API를 바꾼다"고 지적했다.

둘째, 러스트를 모르는 조직은 커스터마이징이 불가능하다. "우리 조직엔 러스트 아는 사람이 없다"는 댓글에 개발팀은 "템플릿 플러그인으로 흔한 케이스는 커버된다"고 답했으나, 커스텀 훅이 필요하면 결국 러스트를 배워야 한다. 오픈코드(OpenCode) 대 파이(Pi) 채택 차이를 예로 들며 배터리 포함(batteries included) 접근을 요구하는 목소리도 있었다.

MCP 지원은 직접 구현 — 클로드 도움 받았지만 검수 완료

모델 컨텍스트 프로토콜(MCP) 지원도 눈여겨볼 지점이다. 기존 러스트 MCP 라이브러리 rmcp를 검토했으나, 게이트웨이 특성상 각 처리 단계에 훅이 필요해 결국 직접 구현했다. 개발팀은 "클로드로 코드를 생성했지만 모든 라인을 직접 검수했다"고 밝혔다. AI 코딩 도구를 썼으나 블랙박스로 쓰지 않았다는 점은 검증 관점에서 긍정적이다.

쉽게 풀어보면

레스팬은 AI 모델 호출을 중개하는 관문이다. 여러 AI 공급자(오픈AI, 앤스로픽, 로컬 모델 등)를 하나의 인터페이스로 묶고, 요청·응답을 변형하거나 로깅·인증·레이트리밋 같은 공통 기능을 끼워 넣는다. 기존 제품(라이트LLM, 포트키 등)과 역할은 같다.

차이는 만드는 방식이다. 대부분 파이썬으로 짜고 설정 파일로 동작을 바꾼다. 레스팬은 러스트로 짜고, 플러그인을 실행파일 속에 박아 넣는다. 뷔페에 비유하면 이렇다. 일반 게이트웨이는 손님이 접시에 음식을 담듯 설정으로 기능을 고른다. 레스팬은 주방장이 손님 취향에 맞춰 요리를 완성해 내놓는 구조다. 음식이 식을 틈 없이 빠르지만, 메뉴를 바꾸려면 주방장이 다시 요리해야 한다(재컴파일).

한국 개발자 입장에서 보면, 지금 바로 프로덕션에 쓰기는 이르다. 도커 이미지가 없으니 쿠버네티스나 도커 컴포즈 환경에서 띄우려면 직접 빌드 파이프라인을 짜야 한다. 러스트 빌드 환경도 갖춰야 한다. 다만 바이너리 배포는 제공되니, 단일 서버나 시스템디(service) 환경이라면 바이너리 다운로드 → 설정 파일 작성 → 실행으로 테스트는 가능하다. 깃허브 릴리스 페이지에서 respan-x86_64-unknown-linux-gnu.tar.gz 같은 파일을 찾으면 된다.

한국어 문서나 커뮤니티는 아직 없다. 영문 README와 예제 설정만으로 시작해야 한다. 국내에서 러스트 도입이 늘고 있지만 여전히 소수라, 사내에 러스트 가능 인력이 있는지부터 확인해야 한다.

나에게 미치는 영향

일반 직장인이나 학생이 오늘 바로 만질 일은 아니다. 이 도구는 백엔드 인프라 팀이 검토한다. 하지만 내 회사가 여러 AI 모델을 섞어 쓰거나, 요청마다 다른 공급자로 라우팅해야 한다면 레스팬 같은 게이트웨이 필요성이 생긴다.

지금 할 수 있는 확인 사항은 세 가지다.

**깃허브 저장소(star/history)**를 열어 릴리스 빈도와 이슈 대응 속도를 본다. 출시 초기라 히스토리가 짧다.
바이너리를 내려받아 로컬에서 실행해 본다. ./respan --config config.yaml 한 줄이면 뜨는지 확인 가능하다.
사내 러스트 역량을 묻는다. 커스텀 플러그인이 필요 없다면 템플릿만으로도 충분할 수 있다.

기존에 라이트LLM이나 포트키를 쓰고 있다면, 마이그레이션 비용 대비 성능 이득을 따져봐야 한다. 레스팬은 아직 1.0이 아니다. API가 바뀔 수 있다. 프로덕션 도입은 안정화 버전 이후로 미루는 편이 안전하다.

남은 쟁점 — 도커 이미지와 1.0 로드맵

개발팀은 "공식 빌드를 깃허브 릴리스에 올렸고, 퍼스트파티 플러그인은 포함돼 있다"고 답했다. 하지만 도커 허브·GHCR 이미지 공개 일정은 아직 밝히지 않았다. 컨테이너 네이티브 조직이라면 이 지점이 블로커다.

또 플러그인 생태계가 열릴지도 미지수다. 정적 컴파일 특성상 서드파티 플러그인은 포크 후 재빌드 구조가 된다. npm이나 파이썬 패키지처럼 pip install plugin 식 배포는 어렵다. 개발팀이 WASM 지원을 "필요하면 고려하겠다"며 여지를 둔 이유다.

본지가 앞서 다룬 AI로 하드웨어 드라이버 직접 만든다… 리눅스 사용자 새 길 열려 기사에서도 러스트와 AI 조합이 개발자 도구 영역으로 확장되는 흐름을 짚었다. 레스팬 역시 그 연장선에 있다. 차이는 인프라 계층이라는 점이다. 드라이버는 하드웨어에 붙지만, 게이트웨이는 비즈니스 트래픽 한가운데 선다. 버그 하나가 전사 장애가 된다. 도입 신중함이 더 요구되는 이유다.

공식 문서와 로드맵 업데이트는 레스팬 깃허브 저장소와 해커뉴스 런치 스레드를 통해 확인할 수 있다.