Relayium

Relayium vs magic-wormhole: CLI 파일 전송

마지막 업데이트: 2026-07-12

magic-wormhole은 조용히 충성도 높은 사용자층을 모아왔습니다. 실행하면 7-crossover-clockwork처럼 짧고 읽기 쉬운 코드가 나오고, 그것을 상대에게 말해주면 파일이 도착합니다 — 전 과정이 암호화되어 있고, 계정도 신경 쓸 서버도 없습니다. Relayium CLI도 비슷한 발상으로 만들어졌습니다. 짧은 코드로 두 컴퓨터를 직접 페어링하고 그 사이의 모든 것을 암호화합니다.

둘은 겹치는 부분이 많고, 겹치지 않는 부분은 정확히 짚을 가치가 있습니다 — magic-wormhole이 오늘 실제로 Relayium CLI보다 더 견고한 지점 하나를 포함해서요.

두 도구의 공통점

두 도구 모두 같은 핵심 문제를 같은 정직한 방식으로 해결합니다. 통제할 수 없는 서버에 파일이 머물지 않으며, 양쪽이 별도 채널로 주고받는 것은 짧은 코드 하나뿐입니다. magic-wormhole은 계정이 전혀 필요 없고, Relayium은 서버가 그 코드를 발급할 수 있도록 보내는 쪽에만 로그인을 요구하며 받는 쪽은 여전히 필요 없습니다.

magic-wormhole이 더 견고한 한 지점: 릴레이가 있다

이것은 솔직한 트레이드오프이며, 얼버무리지 않고 분명히 말할 가치가 있습니다. magic-wormhole은 Transit Relay를 함께 제공하며, 양쪽이 서로 직접 연결을 열 수 없을 때 — 예를 들어 양쪽 모두 엄격하거나 대칭적인 NAT 뒤에 있어 뚫을 방법이 없을 때 — 이 릴레이로 대체됩니다. 릴레이는 항상 암호문만 볼 뿐이지만, 그것이 있기 때문에 전송이 완료됩니다.

Relayium의 send/receive는 직접 연결 전용입니다. 핸드셰이크 직후 몇 초 동안 직접 연결을 시도하고, 찾지 못하면 릴레이로 대체되지 않고 그대로 실패합니다 — 설계상 Relayium의 서버는 네트워크 간 CLI 전송의 파일 바이트를 전혀 건드리지 않습니다. 실제로는 이런 경우가 드뭅니다(대부분의 가정용·사무용 네트워크는 직접 경로를 허용합니다). 하지만 둘 다 유난히 엄격한 NAT 뒤에 있는 두 기기 사이에서 파일을 옮긴다면 magic-wormhole이 그냥 작동할 가능성이 더 높습니다. 직접 경로를 찾을 수 없고 릴레이를 피하는 것보다 신뢰성이 더 중요하다면, 그것이 바로 magic-wormhole을 써야 할 경우입니다 — 아니면 직접 P2P 홉에 의존하지 않는 Relayium의 push/pull이나, 실제로 도달 가능한 서버에 대한 데몬 다이렉트를 사용해도 됩니다.

시작하기 전에

아래는 모두 relayium CLI이므로, 설치하지 않았다면 먼저 설치하세요. macOS나 Linux에서는 명령어 하나로 사전 빌드된 바이너리가 PATH에 등록됩니다:

curl -fsSL https://relayium.com/install.sh | sh

SSH와 데몬 다이렉트: 이미 운영 중인 서버와 대화하기

Relayium CLI가 정말로 더 갖춘 부분은 일회성 페어링 코드 사례 바깥에 있습니다 — 이미 가진 인프라를 활용하는 두 가지 방식이 더 있으며, 이는 magic-wormhole이 다루려 하지 않는 영역입니다.

relayium push / pull은 기존 SSH 접근 권한을 재사용하므로 새로 신뢰할 것도, 공유할 페어링 코드도 없습니다. push는 relayium이 전혀 설치되지 않은 서버에도 작동해, SSH 연결 위의 일반 tar 스트림으로 대체됩니다 — 이 대체 방식은 push에만 있습니다. pull은 항상 원격지에 relayium이 필요합니다. 그곳에서 pull이 송신자 역할을 하기 때문입니다.

relayium serve는 소유한 어떤 기기든 데몬 다이렉트 대상으로 바꿔주며, 인증서 고정 TLS 1.3을 통해 SSH도 페어링 코드도 없이 접근할 수 있게 합니다 — 신뢰는 첫 연결에서 성립하고(대화식으로 승인하거나, 무인 운영을 위해 미리 승인해 둘 수 있음) 이후로는 고정됩니다. SSH의 host key와 같은 발상입니다.

relayium push ./photos user@your-server:backups/
relayium serve --dir ~/incoming
relayium push ./build relayium://your-server

폴더 동기화, 그리고 자체 호스팅 가능한 서버

magic-wormhole은 파일 묶음(또는 압축된 폴더)을 보내고 종료합니다 — 상대 쪽을 갱신하려면 다시 보내야 하고, 무엇을 삭제해야 하는지에 대한 개념도 없습니다. Relayium CLI는 relayium sync를 더해, 위의 두 전송 방식 위에서 증분 단방향 미러링을 합니다. 변경된 것만 옮기고, --delete는 소스에서 사라진 파일을 대상에서도 삭제합니다(데몬은 --allow-delete로 시작된 경우에만 이를 따르므로, 수신 측이 직접 선택해야 합니다). --watch는 파일이 바뀔 때마다 실시간으로 계속 재동기화하며, cron 작업이 필요 없습니다.

relayium.com에 의존하지 않고 직접 모든 것을 운영하고 싶다면, Relayium의 서버는 단일 Docker 컨테이너로 자체 호스팅할 수도 있습니다. --server로 CLI가 그곳을 가리키게 하세요.

relayium sync ./photos user@your-server:backups/photos --delete --watch

기능 한눈에 비교

가장 중요한 차이를 나란히 정리하면:

자주 묻는 질문

Relayium의 CLI는 무료인가요?

네, 완전히 무료입니다. 유료 등급이 없고 계량할 것도 없습니다 — 모든 모드가 양쪽을 직접 연결하며, CLI는 오픈소스입니다.

계정이 필요한가요?

send가 그렇고, 클라우드 up도 그렇습니다. push/pull은 자신의 SSH 접근을 사용하고 데몬 다이렉트는 기기 간 TLS 인증서 고정 신뢰를 사용하므로 둘 다 Relayium 계정을 건드리지 않습니다. send/receive가 예외입니다. 페어링 코드는 서버만, 그것도 로그인된 계정에만 발급할 수 있으므로 보내는 쪽이 relayium login을 한 번 실행합니다. 건네받은 코드를 지정한 send는 발급을 하지 않으므로 로그인이 필요 없습니다. 받는 데는 계정이 전혀 필요 없습니다.

엄격한 NAT 뒤에 있어 직접 경로가 없다면 어떻게 되나요?

이 경우 Relayium의 send/receive는 직접 연결 전용이라 실패합니다 — 릴레이로 대체되지 않습니다. magic-wormhole의 Transit Relay는 암호화된 스트림을 실어 날라 전송을 완료할 수 있습니다. 네트워크 상황과 무관하게 반드시 성공해야 한다면, magic-wormhole이 오늘 그 상황을 처리합니다. 도달 가능한 서버에 대한 Relayium의 push/pull이나 데몬 다이렉트도 직접 P2P 홉에 의존하지 않으므로 마찬가지로 작동합니다.

CLI의 페어링 코드를 Relayium 브라우저 앱과 함께 쓸 수 있나요?

아직 실시간 페어링 전송은 안 됩니다 — CLI의 send/receive는 자체 직접 핸드셰이크를 사용하며, 브라우저의 WebRTC 기반 페어링 흐름과는 별개라 현재는 상호 운용되지 않습니다. 브라우저만으로 상대에게 파일을 전달하려면 Relayium의 저장형 다운로드 링크나 브라우저 앱 자체의 페어링 코드 모드를 사용하세요.

자체 호스팅할 수 있나요?

네. Relayium의 서버는 Docker 이미지로 배포되며(docker compose up -d --build), CLI의 send/receive도 --server https://your-domain으로 자신의 인스턴스를 가리키게 할 수 있습니다.

무료 Relayium CLI를 설치하고 push, sync, send를 써보세요 — 완전 무료로, magic-wormhole만큼 빠르게 시작할 수 있는 코드 기반 전송입니다.

CLI 받기

계속 읽기