마지막 업데이트: 2026-07-09
magic-wormhole은 조용히 충성도 높은 사용자층을 모아왔습니다. 실행하면 7-crossover-clockwork처럼 짧고 읽기 쉬운 코드가 나오고, 그것을 상대에게 말해주면 파일이 도착합니다 — 전 과정이 암호화되어 있고, 계정도 신경 쓸 서버도 없습니다. Relayium CLI도 비슷한 발상으로 만들어졌습니다. 짧은 코드로 두 컴퓨터를 직접 페어링하고 그 사이의 모든 것을 암호화합니다.
둘은 겹치는 부분이 많고, 겹치지 않는 부분은 정확히 짚을 가치가 있습니다 — magic-wormhole이 오늘 실제로 Relayium CLI보다 더 견고한 지점 하나를 포함해서요.
두 도구 모두 같은 핵심 문제를 같은 정직한 방식으로 해결합니다. 계정이 필요 없고, 파일이 여러분이 통제할 수 없는 서버에 머물지 않으며, 양쪽이 별도 채널로 합의해야 하는 것은 짧은 코드 하나뿐입니다.
이것은 솔직한 트레이드오프이며, 얼버무리지 않고 분명히 말할 가치가 있습니다. magic-wormhole은 Transit Relay를 함께 제공하며, 양쪽이 서로 직접 연결을 열 수 없을 때 — 예를 들어 양쪽 모두 엄격하거나 대칭적인 NAT 뒤에 있어 뚫을 방법이 없을 때 — 이 릴레이로 대체됩니다. 릴레이는 항상 암호문만 볼 뿐이지만, 그것이 있기 때문에 전송이 완료됩니다.
Relayium의 send/receive는 직접 연결 전용입니다. 핸드셰이크 직후 몇 초 동안 직접 연결을 시도하고, 찾지 못하면 릴레이로 대체되지 않고 그대로 실패합니다 — 설계상 Relayium의 서버는 네트워크 간 CLI 전송의 파일 바이트를 전혀 건드리지 않습니다. 실제로는 이런 경우가 드뭅니다(대부분의 가정용·사무용 네트워크는 직접 경로를 허용합니다). 하지만 둘 다 유난히 엄격한 NAT 뒤에 있는 두 기기 사이에서 파일을 옮긴다면 magic-wormhole이 그냥 작동할 가능성이 더 높습니다. 직접 경로를 찾을 수 없고 릴레이를 피하는 것보다 신뢰성이 더 중요하다면, 그것이 바로 magic-wormhole을 써야 할 경우입니다 — 아니면 직접 P2P 홉에 의존하지 않는 Relayium의 push/pull이나, 실제로 도달 가능한 서버에 대한 daemon-direct를 사용해도 됩니다.
Relayium CLI가 정말로 더 갖춘 부분은 일회성 페어링 코드 사례 바깥에 있습니다 — 이미 가진 인프라를 활용하는 두 가지 방식이 더 있으며, 이는 magic-wormhole이 다루려 하지 않는 영역입니다.
relayium push / pull은 기존 SSH 접근 권한을 재사용하므로 새로 신뢰할 것도, 공유할 코드도 없습니다. push는 relayium이 전혀 설치되지 않은 서버에도 작동해, SSH 연결 위의 일반 tar 스트림으로 대체됩니다 — 이 대체 방식은 push에만 있습니다. pull은 항상 원격지에 relayium이 필요합니다. 그곳에서 pull이 송신자 역할을 하기 때문입니다.
relayium serve는 소유한 어떤 기기든 daemon-direct 대상으로 바꿔주며, 고정된 TLS 1.3을 통해 SSH도 코드도 없이 접근할 수 있게 합니다 — 신뢰는 첫 연결에서 성립하고(대화식으로 승인하거나, 무인 운영을 위해 미리 승인해 둘 수 있음) 이후로는 고정됩니다. SSH의 host key와 같은 발상입니다.
relayium push ./photos user@your-server:backups/relayium serve --dir ~/incomingrelayium push ./build relayium://your-servermagic-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가장 중요한 차이를 나란히 정리하면:
네, 완전히 무료입니다. 유료 등급이 없고 계량할 것도 없습니다 — 모든 모드가 양쪽을 직접 연결하며, CLI는 오픈소스입니다.
아니요. push/pull은 자신의 SSH 접근을 사용하고, daemon-direct는 기기 간 고정된 TLS 인증서 신뢰를 사용하며, send/receive는 별도 채널로 미리 합의한 짧은 코드를 사용합니다. 어느 것도 Relayium 계정을 필요로 하지 않습니다.
이 경우 Relayium의 send/receive는 직접 연결 전용이라 실패합니다 — 릴레이로 대체되지 않습니다. magic-wormhole의 Transit Relay는 암호화된 스트림을 실어 날라 전송을 완료할 수 있습니다. 네트워크 상황과 무관하게 반드시 성공해야 한다면, magic-wormhole이 오늘 그 상황을 처리합니다. 도달 가능한 서버에 대한 Relayium의 push/pull이나 daemon-direct도 직접 P2P 홉에 의존하지 않으므로 마찬가지로 작동합니다.
아직 실시간 페어링 전송은 안 됩니다 — 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 받기