명령줄에서 파일 받기

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

보내는 것은 이야기의 절반일 뿐입니다——언젠가는 당신이 받는 쪽이 됩니다. 동료가 인터넷 너머로 파일을 건네주고 싶을 때, 당신의 기기 하나가 다른 기기에게 넘겨주고 싶을 때, 또는 당신이 관리하는 서버에서 무언가를 직접 가져오고 싶을 때. Relayium CLI는 이 세 가지 각각에 서로 다른 명령으로 대응하며, 어느 쪽도 계정이 필요 없습니다.

상대가 페어링 코드로 당신에게 푸시할 때는 receive를, 신뢰하는 기기들이 언제든 푸시할 수 있는 상시 수신함이 필요할 때는 serve를, 그리고 당신이 이미 SSH로 접속 가능한 서버로 직접 다가갈 때는 pull을 선택하세요.

받는 세 가지 방법과 각각이 적용되는 상황

어떤 명령을 실행할지는 누가 전송을 시작하는지, 그리고 두 기기가 서로 어떻게 아는 사이인지에 따라 달라집니다:

relayium receive <code> [destdir] — 상대가 대역 외로 합의한 페어링 코드를 사용해 네트워크를 넘어 당신에게 보냅니다. 직접적인 피어투피어이며 SAS 코드로 검증됩니다.
relayium serve [--dir D] [--port N] [--once] [--allow-delete] — 이 기기가 데몬 다이렉트 relayium:// 푸시를 대기합니다. 기본 포트는 9031입니다.
relayium pull [user@]host:src <dest> — 당신이 이미 로그인할 수 있는 서버로 SSH를 통해 직접 다가가 파일을 가져옵니다.

receive: 상대가 네트워크를 넘어 파일을 보낼 때

이것은 relayium send의 받는 쪽입니다. 상대는 짧은 코드를 정하고 통화나 채팅 등 서로 신뢰하는 채널로 알려준 뒤, 자기 쪽에서 relayium send <path> <code>를 실행합니다. 당신은 같은 코드로 receive를 실행합니다:

relayium receive 428571

# or into a specific directory
relayium receive 428571 ./downloads

연결은 직접적인 피어투피어이며 종단간 암호화됩니다. 연결되면 양쪽 터미널에 동일한 SAS(짧은 인증 문자열)가 출력됩니다——발신자와 비교해 중간에 아무도 없는지 확인하세요.
목적지를 지정하지 않으면 파일은 현재 디렉터리에 저장됩니다.
send와 동일하게 직접 연결만 지원합니다. 두 네트워크 사이에 직접 경로를 찾을 수 없으면 릴레이를 거치는 대신 전송이 실패합니다.
이것은 CLI 자체의 페어링 코드 프로토콜입니다——현재 relayium.com 브라우저 쪽의 페어링 코드나 QR 흐름과는 상호 운용되지 않습니다. 향후 추가될 수는 있지만 지금은 기대할 수 없습니다.
받는 쪽은 어느 네트워크에 있든 계정이 전혀 필요하지 않습니다.

serve: 이 기기를 대기형 수신함으로 만들기

serve는 반대 방향으로 동작합니다. 당신이 다가가는 대신, 다른 기기가 relayium://를 통해 곧바로 당신에게 푸시합니다——이미 신뢰하는 기기, 예를 들어 자신의 노트북이 NAS로 푸시하거나 빌드 서버가 산출물을 당신의 기기에 떨어뜨리는 경우를 위한 것입니다. 고정된 TLS 1.3 연결로, SSH도 랑데부도 필요 없습니다.

relayium serve

# a specific directory, port, and allowing delete requests
relayium serve --dir ~/incoming --port 9031 --allow-delete

새 기기가 처음 당신에게 푸시하면, serve는(터미널에서 실행 중일 때) 그 주소와 핑거프린트를 보여주고 한 번 승인해 달라고 요청합니다. 이후 같은 핑거프린트의 푸시는 조용히 통과합니다.
터미널이 없을 때——systemd 서비스, TTY 없는 스크립트——물어볼 사람이 없으므로 알 수 없는 푸시하는 쪽은 그대로 거부됩니다. 대신 푸시하는 쪽이 relayium id로 출력하는 핑거프린트를 이용해 미리 승인하세요:

무인 실행되는 serve를 위해 미리 승인하기

무인으로 실행되는 serve(systemd, 백그라운드 스크립트)의 경우, 푸시하는 쪽이 relayium id를 실행해 핑거프린트를 출력하게 한 다음, 받는 쪽에서 미리 승인해 두세요:

relayium authorize <fingerprint>

--dir는 파일이 저장될 위치를 설정합니다(기본값은 현재 디렉터리). --once는 한 번의 전송만 받고 종료합니다. --allow-delete는 들어오는 --delete(미러) 요청이 실제로 이곳의 파일을 삭제할 수 있게 하며, 기본값은 꺼짐입니다.
--config-dir(기본값 ~/.config/relayium)는 이 호스트의 신원과 승인된 핑거프린트 목록이 저장되는 위치입니다——serve를 전용 서비스로 실행한다면 재정의하세요.

pull: 이미 SSH로 접속 가능한 서버에서 직접 가져오기

pull은 push의 거울상입니다. 누군가 무언가를 보내오기를 기다리는 대신, 이미 가진 SSH 접근 권한으로 직접 다가가 파일을 가져옵니다.

relayium pull user@host:/path/to/files ./local-dest

push와 달리, pull은 항상 원격 쪽에 relayium이 이미 설치되어 있어야 합니다——맨 서버에서 pull할 때 사용할 tar 대체 방식은 없습니다. 원격에 아직 없다면 먼저 curl -fsSL https://relayium.com/install.sh | sh로 설치하세요.
파일은 파일별 SHA-256 검사로 검증되며, 중단되면 자동으로 재개됩니다(--no-resume으로 비활성화 가능).
-i와 -p는 ssh 자체의 -i/-p처럼 동작하며, 특정 신원 파일이나 포트를 지정하는 데 사용합니다.

자주 묻는 질문

파일을 받는 데 계정이 필요한가요?

아니요. receive, serve, pull 세 가지 모두 완전히 무료이며 양쪽 다 Relayium 계정이 필요 없습니다.

relayium receive는 브라우저의 페어링 코드와 상호 운용되나요?

아니요. CLI의 페어링 코드 프로토콜은 relayium.com 브라우저 쪽의 참여 링크 및 QR 흐름과 별개입니다——핸드셰이크 방식이 다르며 현재는 서로 통신하지 않습니다. 이는 로드맵에 있는 사항이며 지금은 기대할 수 없습니다.

알 수 없는 기기가 내 serve 리스너로 푸시하면 어떻게 되나요?

터미널에서는 첫 푸시 시 주소와 핑거프린트로 승인 여부를 묻고, 그 승인은 기억됩니다. 터미널이 없을 때——systemd 서비스나 cron 작업——물어볼 사람이 없으므로 알 수 없는 푸시하는 쪽은 거부됩니다. 먼저 relayium authorize <fingerprint>로 미리 승인하세요.

relayium이 설치되지 않은 서버에서 pull할 수 있나요?

아니요. pull은 항상 원격 쪽에 relayium이 필요합니다——push처럼 tar 대체 방식이 없습니다. 먼저 원격에 relayium을 설치하세요.

relayium은 내 신원과 신뢰하는 상대를 어디에 저장하나요?

기본적으로 ~/.config/relayium에 저장됩니다——신원이나 신뢰와 관련된 모든 명령에서 --config-dir로 이 위치를 재정의할 수 있습니다.

첫 전송을 받을 준비가 되셨나요? CLI를 설치하고 receive, serve, pull 중 하나를 선택하세요.

CLI 받기