Show GN: 로컬 네트워크간 파일 공유를 위해 만든 5mb Rust 파일 서버
(saibius.com)저는 개발을 하다 보면 임시적으로 파일을 공유할 일이 종종 생기더라구요
예를 들자면, 로컬로 파일을 빠르게 공유하거나(예를 들어 ai 체크포인트나 학습데이터 등등) 이 파일들은 대용량이라 그런지, 기존 클라우드 서비스 전송은 느리고, 파이썬 서버 같은 건 가끔 폭발(?)하는 것이 불편해서 Curl/Wget으로 일시적으로 공유 가능한 로컬 파일 서버가 있으면 해서 만들었습니다.
일단 특징이라고 하면 크게 4가지 정도입니다
첫째. 크로스플랫폼. – 사실 이것도 제가 편하자고 만든 거긴 한데, 리눅스와 윈도우를 오가는 저에게는 동일한 명령어는 포기할 수 없는 욕망…
둘째. 웹 UI – Apache 스타일의 작은 웹 서버가 기본 내장인데, 사용자가 공유한 폴더에서 파일을 다운받거나 일부 브라우저 지원 파일(html, txt등)을 바로 볼 수 있게 만들었습니다.
셋째. 별도 런타임 설치 불필요. – 초반에는 express 서버 등도 고려했는데, 저는 LXC등을 쓰는 경우가 많아서 별도로 Node 등의 런타임을 설치하는 게 불편하더라구요. 윈도우에서도 VM 켜면 매번 세팅이 귀찮은 부분도 있었고요
넷째. 5MB 이내 파일 서버 – “파일 전송” 빼고 다 들어내서 실제 파일 용량이 5MB 이내로 만들었습니다 (제일 용량이 큰 게 Linux x86 4.12MB입니다 (1.0.0) 기준 빌드)
실제로 제가 쓰고 있는 프로그램인데, 제가 만들고 제가 써본 결과 ISO 파일이나 대용량 이미지 혹은 PDF등을 일시적으로 내부망에서 공유할 때 편리합니다.
폴더 공유 예시 : ./saibius –file ./share
웹사이트 : https://saibius.com/
깃허브 : https://github.com/saibius/docs
P.s 4,900원에 판매중이지만, 선착순 10명에게 무료 키를 제공해드립니다.
https://saibius.com/redeem?key=SAIBIUS-2026-R1 링크에 들어가시면 자동완성 됩니다 :)
[업데이트] 무료 키 소진 안내
많은 관심을 주셔서 감사합니다!
2026년 01월 22일 13:10 기준으로 모든 무료 키가 소진되었습니다.
[소진된 키]
초기 무료 키(R1), 추후 배포된 U1, C1
여러분의 성원에 힘입어 앞으로도 더욱 발전해가는
세이비우스가 되겠습니다.
감사합니다.
[업데이트] 많은 관심을 주셔서 감사합니다!
초기 무료 키가 빠르게 소진되었고, 일부 분들께서 리딤 오류를 겪으셨습니다.
문제를 수정하여 추가로 20개를 제공합니다.
https://saibius.com/redeem?key=SAIBIUS-2026-U1
https://saibius.com/redeem?key=SAIBIUS-2026-C1
이전 코드로 오류 발생하셨던 분은 새 코드로 다시 시도해주세요!
셀링 포인트가 약하게 느껴져서 피드백을 드립니다. 웹 UI의 필요성이 잘 설득되지 않습니다. 터미널이 주력 인터페이스라면, 명령어로 전송받은 파일을 firefox <html_file>이나 cat <text_file>와 같이 해당 파일을 여는 어플리케이션을 바로 실행할 수 있지 않나요? 바이너리 크기를 더 줄일 수 있을 것 같습니다. 만약 GUI friendly하게 만들려면 각 플랫폼의 explorer나 finder 우클릭 메뉴에 shortcut을 추가해도 좋을 것 같습니다. 만약 웹 UI까지 들어낸다면 된다면 https://github.com/schollz/croc와 비교가 될 것 같습니다. 제가 주력으로 사용하는 도구인데요, 별도 런타임 없이 로컬 전송도 충분히 빠르고, relay p2p로 원격 전송도 e2e encryption 지원, 전송 재개(resume)도 지원하거든요.
좋은 피드백 주셔서 감사합니다!
GUI 쇼컷 부분은 추가하는 것이 좋을 것 같습니다.
우선, 말씀해주신 부분에 대한 답변을 드리겠습니다.
-
WebUI의 필요성
터미널이 주력 인터페이스이긴 하지만, 이 프로그램은 마케터, 디자이너 등 서버 환경, 터미널 환경에 익숙하지 않은 팀 분들에게도 공유할 수 있도록 설계되었으며, 이에 따라 WebUI를 차별성으로 가져가려고 합니다. -
파일 실행 관련 부분
해당 프로그램은 기본적으로는 "임시 파일 공유 서버"에 초점을 맞추고 있어서 해당 파일을 여는 어플리케이션을 직접 실행하지 않고 있습니다. 기본적으로 저희가 사용하는 확장자들은 서로 다른 프로그램이 같은 확장자를 공유하는 경우가 있어서요 -
CROC와의 차이점
말씀해주신 도구와 가장 큰 차이점이라면, Zero-Copy의 지원과 동적 버퍼 최적화(파일에 따른 버퍼 가변) 정도가 될 것 같습니다. 본 도구도 기본적으로 IDM(혹은 FDM)을 지원하기 위해 HttpRange를 적용했었거든요.
말씀해주신 숏컷 기능은 좋은 아이디어인 것 같습니다. 추후 업데이트 때 반영할 수 있도록 공부해보겠습니다
좋은 하루 보내세요! :)
좋은 피드백 주셔서 감사합니다!
--file 플래그 관련해서는 저희도 인지하고 있으며,
초기 버전에서는 플래그 없이도 파일 공유가 가능했습니다.
다만, 베타 테스트 과정에서 "파일이 즉시 공유되는 특성상, 사용자가 의도치 않게 복사 붙여넣기를 통해 클립보드의 잘못된 경로를 공유할 수 있다" 는 우려가 제기되어 한번 더 입력 절차를 두어
현재로서는 명시적인 --file 플래그를 요구하도록 변경되었습니다.
말씀하신 것처럼 편의성 측면에서는 플래그 없이도 동작하는 것이 더 나을 수 있다는 점에 공감하고 있습니다. 보안성과 편의성 사이의 균형을 어떻게 맞출지 계속 테스트 중에 있습니다.
말씀해주신 --file 플래그 생략 기능은 좋은 아이디어인 것 같습니다.
좋은 아이디어 주셔서 감사합니다 :)
좋은 하루 보내세요 :)
서버 사용자의 대상은 개발자인지 일반 사용자인지 모르겠네요. 개발자가 대상이라면 잘못된 경로 붙여넣기 방지는 거추장스럽고 일반사용자가 대상이라면 명령창을 열어서 --file 플래그를 입력해야만 하는 불편함이 있습니다. --file 플래그가 없으면 탐색기에서 폴더를 글어서 실행파일에 드랍하면 즉시 공유가능한 방법을 포기해야합니다. 그러면 편의를 위해서 시스템 메뉴에 메뉴를 추가하는걸 고려할테지만, 그 숏컷 메뉴를 한달에 몇번쓸까요?
추가 피드백 감사합니다.
말씀하신 것처럼 개발자의 사용성과 일반 유저의 편의성 모두 놓칠 수 없는 부분이라 생각합니다.
다만, 현재로서는 기존 사용자들의 안정적인 워크플로우를 유지하는 것이 우선순위라 판단하고 있습니다.
제안해주신 '플래그 생략' 이나 '인터페이스 개선' 등의 아이디어는 향후 대대적인 업데이트 시점에 맞춰 하위 호환성을 해치지 않는 선에서 신중히 검토해 보겠습니다.
관심 가져주셔서 감사합니다.