명령줄에서 파일 받기

마지막 업데이트: 2026-08-06

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

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

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

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

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

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

1단계 전에 필요한 것

이 기기에 CLI. relayium version은 버전 문자열을 출력합니다. command not found가 나오면 여기에는 아직 설치되지 않은 것입니다.
지금 로그인되어 있고 지금 터미널 앞에 있는 발신자. 계정이 필요한 쪽은 발신자뿐이고, 받는 쪽은 로그인하지 않습니다.
여섯 자리 숫자를 대역 외 경로로 전달받을 것. 상대 CLI가 발급한 순간부터 5분간만 유효하므로 시점을 먼저 맞추세요.
나중에 여섯 자리를 다시 읽어 줄 수 있는 경로. SAS는 화면이 아니라 말로 대조합니다.
상대편도 CLI여야 합니다. 브라우저는 CLI 페어링 코드에 참여할 수 없습니다. 브라우저밖에 없다면 relayium up 링크를 요청하세요.

이것은 relayium send의 받는 쪽입니다. 상대는 자기 쪽에서 relayium send <path>를 실행합니다(미리 relayium login을 해 둔 상태로). 그러면 상대의 CLI가 5분간 유효한 6자리 숫자 코드를 발급해 출력하고, 상대는 통화나 채팅 등 서로 신뢰하는 채널로 그것을 알려줍니다. 받는 쪽에서는 그 코드로 receive를 실행합니다:

relayium receive 483920

# 특정 디렉터리로 받으려면
relayium receive 483920 ./downloads

발신자가 send를 언제 실행할지 먼저 맞추세요. 코드는 발급된 순간부터 만료가 시작되며, 전달받은 순간부터가 아닙니다.
서로 신뢰하는 경로로 여섯 자리를 받으세요 — 통화, 채팅창, 아니면 같이 있는 그 방에서.
파일이 떨어질 디렉터리에서 receive를 실행하거나, 위치를 명시하세요.
```
relayium receive 483920
```
```
relayium receive 483920 ./downloads
```
두 터미널에 확인 코드가 뜨면 자기 쪽 값을 소리 내어 읽고 상대와 일치하는지 확인하세요. 이것은 페어링 코드가 아니며, 상대 종단이 바꿔치기되지 않았음을 배제해 주는 유일한 근거입니다.
터미널이 프롬프트로 돌아올 때까지 건드리지 마세요. 이것은 하나의 실시간 세션이라 어느 쪽이든 닫으면 전송이 멈춥니다.

성공적인 수신의 모습

연결이 direct로 표시되고, 두 터미널이 서로 같은 확인 코드를 출력합니다. 코드가 다른 경우만은 받아들이면 안 됩니다 — 거기서 멈추고 상대가 어느 기기에 있는지 확인하세요.

$ relayium receive 483920
verification code (SAS): 271044 — not the pairing code; compare it on both ends to rule out a substituted endpoint
path: direct

연결은 직접적인 피어투피어이며 종단간 암호화됩니다. 연결되면 양쪽 터미널에 동일한 SAS(짧은 인증 문자열)가 출력됩니다. 발신자와 대역 외로 비교하면 고정된 TLS 인증서 지문이 바뀌지 않았고 랑데부 서비스가 어느 끝점도 사칭하지 않았음을 확인할 수 있습니다. SAS는 끝점을 인증하는 것이지 네트워크 경로의 모든 홉을 증명하는 것은 아닙니다.
목적지를 지정하지 않으면 파일은 현재 디렉터리에 저장됩니다.
send와 동일하게 직접 연결만 지원합니다. 두 네트워크 사이에 직접 경로를 찾을 수 없으면 릴레이를 거치는 대신 전송이 실패합니다.
이것은 CLI 자체의 페어링 코드 프로토콜입니다——CLI 코드는 CLI끼리만 페어링됩니다. 현재 relayium.com 브라우저 쪽의 페어링 코드나 QR 흐름과는 상호 운용되지 않습니다. 향후 추가될 수는 있지만 지금은 기대할 수 없습니다. 브라우저밖에 없다면 보내는 쪽에 relayium up 다운로드 링크를 대신 요청하세요.
받는 쪽은 어느 네트워크에 있든 계정이 전혀 필요하지 않습니다. 로그인하는 쪽은 보내는 사람뿐이며, 그 CLI가 코드를 발급할 수 있도록 하기 위해서입니다.

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

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

relayium serve

# 디렉터리와 포트를 지정하고 삭제 요청을 허용하려면
relayium serve --dir ~/incoming --port 9031 --allow-delete

전송이 떨어질 디렉터리를 지정해 리스너를 시작합니다.
```
relayium serve --dir ~/incoming
```
새 기기가 처음 밀어 넣으면 serve가 그 주소와 지문을 보여 주며 묻습니다. 한 번 승인하면 같은 지문에서 오는 전송은 이후 조용히 통과합니다.
이 리스너를 터미널 없이 돌릴 예정이라면 그 프롬프트에 기대지 마세요. 답할 사람이 없으므로 낯선 발신자는 그대로 거부됩니다. 다음 절의 사전 승인을 쓰세요.

새 기기가 처음 푸시해 오면, 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

원격에 CLI가 정말 있는지 확인하세요. pull은 원격에서 relayium을 실행하며, push와 달리 tar 대체 경로가 없어 바이너리가 없으면 명령 전체가 실패합니다.
```
ssh user@host command -v relayium
```

없다면 원격에 먼저 설치하세요.

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

이미 가진 SSH 접근으로 파일을 가져옵니다. -i와 -p는 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처럼 동작하며, 특정 신원 파일이나 포트를 지정하는 데 사용합니다.

잘 안 될 때

실패하는 수신은 거의 모두 다섯 가지 중 하나입니다. 어떤 명령을 실행했는지가 해당 항목을 정하며, 각각 읽어서 판단할 한 줄이나 실행해서 결론 낼 명령이 있습니다.

증상, 확인, 해결

코드를 입력했는데 랑데부가 거부합니다.

relayium receive 483920
# the rendezvous refuses the code

거의 항상 5분이 지난 경우입니다. 코드는 발신자의 CLI가 발급한 순간부터 만료되며, 전달받은 시점부터가 아닙니다. 다시 send를 실행하게 하고 새 숫자를 바로 읽어 달라고 하세요. 한 자리 오타는 이쪽에서 보면 똑같아 보이므로, 만료라고 단정하기 전에 코드를 되읽어 대조하세요.

전송은 끝났는데 파일을 찾을 수 없습니다.

relayium receive 483920 ./downloads

목적지를 주지 않으면 receive는 실행한 디렉터리에 씁니다. 그곳이 찾고 있던 위치인 경우는 드뭅니다. 위치를 명시하거나 먼저 pwd로 확인하세요.

"no direct connection to the peer (both ends behind strict NAT?)"로 실패합니다.

relayium receive 483920
# no direct connection to the peer (both ends behind strict NAT?): …

CLI 페어링 경로는 설계상 직결 전용이라, 직접 경로가 없으면 파일을 릴레이로 우회시키는 대신 실패합니다. 이쪽에서 고칠 수 있는 것은 없습니다. 발신자에게 relayium up 다운로드 링크를 요청하거나, 둘 다 관리하는 기기끼리라면 데몬 직결이나 SSH를 통한 push를 쓰세요.

pull이 곧바로 실패하며 relayium을 찾을 수 없다고 합니다.

ssh user@host command -v relayium
# (no output)

pull은 원격에서 relayium을 실행합니다 — 그 교환에서는 원격이 보내는 쪽입니다 — 그리고 push에 있는 tar 대체 경로가 없습니다. 원격에 CLI를 먼저 설치한 다음 pull을 다시 실행하세요.

어떤 기기가 serve 리스너로 밀어 넣었다가 거부되었는데, 한 번도 묻는 창이 뜨지 않았습니다.

relayium serve --dir ~/incoming

그 프롬프트는 serve에 터미널이 있을 때만 존재합니다. systemd 아래, 스크립트 안, 파이프 뒤에서는 물어볼 상대가 없으므로 모르는 지문은 그대로 거부됩니다. 보내는 쪽에서 relayium id를 실행하게 하고, 여기서 relayium authorize <지문>을 리스너와 같은 --config-dir로 실행하세요.

자주 묻는 질문

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

아니요. receive, serve, pull 세 가지 모두 완전히 무료이며 받는 쪽에는 Relayium 계정이 필요 없습니다. 전체 과정에서 유일하게 로그인하는 쪽은 receive 모드의 보내는 사람이며, 그 CLI가 페어링 코드를 발급할 수 있도록 하기 위해서입니다.

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

아니요. CLI의 페어링 코드 프로토콜은 relayium.com 브라우저 쪽의 참여 링크 및 QR 흐름과 별개입니다——핸드셰이크 방식이 다르며 현재는 서로 통신하지 않으므로, CLI 코드는 다른 CLI와만 페어링됩니다. 이는 로드맵에 있는 사항이며 지금은 기대할 수 없습니다. 그때까지 브라우저로 받는 사람에게는 코드가 아니라 relayium up 링크를 주세요.

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

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

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

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

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

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

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

CLI 받기