Launch HN: Respan (YC W24) – 플러그인 기반의 오픈소스 Rust AI 게이트웨이

HN 여러분, Respan의 Andy입니다( https://www.respan.ai ). 저희는 오픈소스 Rust AI 게이트웨이를 만들고 있습니다. 이 게이트웨이는 분리형(decoupled) 구조라서 서로 다른 provider, 프로토콜(MCP, voice), 모달리티(이미지, 비디오), 그리고 게이트웨이 기능(fallback, PII 마스킹, 스마트 라우팅)까지 모든 것이 플러그인입니다. 수많은 provider와 기능을 하나의 게이트웨이에 몰아넣는 대신, Respan은 작은 코어와 공개 인터페이스를 제공하여 팀이 애플리케이션에 필요한 AI 인프라를 조립할 수 있게 합니다. 이렇게 하면 사용자는 게이트웨이 코어를 변경하지 않고도 자체 기능을 추가 플러그인으로 만들 수 있습니다. 영상 데모는 다음과 같습니다: https://www.youtube.com/watch?v=pVv2ibXiTXM LLM 게이트웨이는 셀 수 없이 많으며, 대부분은 하나의 엔드포인트에서 서로 다른 provider를 호출한다는 공통된 문제를 해결합니다. 하지만 새로운 기능을 추가하는 일은 지나치게 어려워질 수 있습니다. 그래서 개발자들은 결국 특정 문제를 해결하기 위해 또 다른 게이트웨이를 만들게 됩니다. 저희는 2024년부터 LiteLLM을 기반으로 게이트웨이를 만들어 왔고, 현재는 수천 개의 조직에 서비스를 제공하고 있습니다. 각 조직은 서로 다른 API 키 설정, 라우트, 제한을 필요로 합니다. 이를 지원하기 위해 저희는 계속 LiteLLM을 감싸고 기능을 추가했으며, 어느 단계에서는 래퍼 코드가 100,000줄을 넘어섰습니다. 올해 1월, 일상적인 LiteLLM 업그레이드가 간헐적인 연결 오류를 일으켜 롤백해야 했습니다. 아직 원인을 파악하지 못했지만, 그 이후로는 LiteLLM을 직접 업그레이드하지 않고 업스트림 수정 사항을 수동으로 백포트하고 있습니다. 이러한 경험을 통해 LiteLLM을 계속 패치하는 것은 지속 가능한 장기 해결책이 아니라는 것을 깨달았고, 게이트웨이를 직접 재설계해야 했습니다. 게이트웨이를 재설계하면서 저희는 기존 기능을 깨뜨리지 않고 기능을 더 쉽게 추가하고 싶었습니다. Nginx에서 영감을 받아, AI 게이트웨이는 이벤트 디스패치만 담당하는 정말 작은 코어를 가져야 한다고 생각합니다. 저희는 게이트웨이의 모든 것이 플러그인이어야 한다고 믿습니다. 여기에는 provider(OpenAI, Anthropic, Gemini), 프로토콜(chat, realtime voice, MCP), 모달리티(이미지, 비디오), 그리고 신뢰성과 보안을 위한 게이트웨이 기능(스마트 라우팅, fallback, 예제 플러그인을 통한 PII 마스킹)이 포함됩니다. 그뿐만 아니라, 개발자가 코어를 건드리지 않고 자체 플러그인을 추가하여 게이트웨이의 기능을 쉽게 확장할 수 있기를 바랍니다. provider 추가는, 심지어 직접 만든 provider라도, 매우 간단합니다. 왜냐하면 특이 동작(quirk)도 플러그인이기 때문에 특별할 것이 없기 때문입니다. provider는 짧은 파일 하나이며, Mistral의 경우 22줄이고, Groq가 토큰 사용량을 자체 필드에 넣는 것 같은 각 특이 동작에는 자체 테스트가 있습니다. Respan Gateway는 OpenAI SDK에서 Claude나 Gemini 모델을 호출할 수 있게 하는 것 이상을 합니다. 도구, 이미지, 추론 프로토콜을 자동으로 처리합니다. OpenAI Realtime API 기반 애플리케이션은 게이트웨이를 통해 Gemini Live도 사용할 수 있습니다. 물론 모든 기능이 그대로 변환되지는 않습니다. 간단한 채팅 앱은 MCP를 직접 구현하지 않고도 게이트웨이에 구성된 MCP 도구를 사용할 수 있습니다. 저희는 또한 요청을 공유 구조로 파싱합니다. 클라이언트와 provider가 동일한 API를 사용할 때, 공유 구조에 해당 필드가 없더라도 provider별 필드를 원래 형식으로 보존합니다. 이렇게 하면 게이트웨이가 해당 필드를 버리지 않고 다시 쓸 수 있습니다. 작동 방식은 다음과 같습니다: 어댑터가 각 HTTP 또는 WebSocket 연결을 이를 인식하는 첫 번째 클라이언트 포맷에 넘깁니다. 해당 포맷은 요청을 타입이 지정된 입력 및 출력 이벤트의 양방향 스트림으로 노출합니다. 코어는 등록 순서대로 플러그인을 실행하여, 플러그인이 provider를 선택하거나, 어느 한 스트림을 필터링 또는 래핑하거나, 추가 호출을 하거나, 응답을 반환하거나, 요청을 거부할 수 있게 합니다. 그런 다음 provider 포맷이 업스트림 연결을 엽니다. 클라이언트와 provider가 동일한 포맷을 사용하고 어떤 플러그인도 페이로드를 변경하지 않으면, 원본 바이트와 pr