사용 사례

CPYNET이 실제로 만들어진 다섯 가지 현실적인 시나리오입니다 - 가상의 시나리오가 아닙니다. 아래의 각 명령은 실제 배포에 대한 실제 입력이며, 실제로 생성되는 출력과 함께 표시됩니다.

SSH 세션에서 로그 공유하기

원격 서버에 SSH로 접속해 있는데 뭔가 실패했고, 관련 로그 줄을 지금 당장 팀원에게 전달해야 합니다 - 또 다른 SSH 접근이나 파일 이메일 전송 없이요.

당신, 서버에서

$ journalctl -u myservice -n 200 | cpy482913curl "https://llmtag.com/482913"

두 줄이 돌아옵니다: 순수 코드와 바로 실행 가능한 curl 명령. 둘 중 하나를 채팅에 붙여넣으세요 - 읽는 사람은 정확한 텍스트를 받고, 읽는 즉시 사라집니다:

당신의 팀원

$ pst 482913Aug 08 14:02:11 myservice[1823]: connection refused: db.internal:5432Aug 08 14:02:11 myservice[1823]: retrying in 5s...Aug 08 14:02:16 myservice[1823]: connection refused: db.internal:5432

이것이 pst 셸 함수입니다 - 부수 효과로 텍스트를 클립보드에도 넣어주는, 순수한 편의 기능입니다. 상대방에게 cpy/pst가 설치되어 있지 않다면? 위에서 cpy가 출력한 단순한 curl "https://llmtag.com/482913" 줄이 별칭 없이도 완전히 동일하게 작동합니다. 어느 쪽이든, 같은 코드를 두 번째로 읽으려는 시도는 (당신을 포함해 누구든) 404를 반환합니다 - 이미 사라졌습니다.

클립보드가 비활성화된 머신에서 텍스트 옮기기

일부 환경 - 잠긴 회사 노트북, VDI 세션, 호스트와 게스트 간 공유 클립보드가 없는 원격 데스크톱 - 에서는 OS 클립보드를 통해 텍스트를 아예 복사해 나올 수 없습니다.

잠긴 머신

$ echo "wifi 비밀번호: correcthorsebatterystaple" | cpy174205curl "https://llmtag.com/174205"

몇 분 후, 당신의 머신

$ pst 174205wifi 비밀번호: correcthorsebatterystaple

CPYNET은 어차피 잠긴 머신에서 OS 클립보드를 전혀 건드리지 않습니다 - 모든 것이 curl을 통해 일반 텍스트로 나가므로, 비활성화된 클립보드는 그쪽에서 문제가 되지 않습니다. 다시 읽어들이는 머신은 정상적인 머신이므로, pst의 클립보드 편의 기능이 그쪽에서는 문제없이 작동합니다. 받는 쪽에 터미널이 없다면? 전송 후 표시되는 QR 코드를 휴대폰으로 스캔하세요 - 브라우저에서 바로 열립니다.

비기술적인 팀원에게 비밀번호로 보호된 링크 전달하기

공유해야 할 모든 사람이 명령을 실행하고 싶어하는 것은 아닙니다 - 고객, 매니저, 또는 잠긴 머신의 팀원에게는 브라우저에서 한 번 입력할 링크와 비밀번호만 있으면 됩니다.

당신

$ echo "staging: https://staging.internal  사용자: demo  비밀번호: xQ9!vB2m" | cpy -password=handoff2026591042curl "https://llmtag.com/591042"

일반 링크(코드만이 아니라 - 코드 자체도 여전히 올바른 URL이 필요합니다)와 비밀번호를 서로 다른 채널로 보내세요. 상대방은 아무 브라우저에서나 링크를 열고 페이지의 필드에 비밀번호를 입력한 뒤 한 번 읽습니다 - CLI도, 브라우저 확장 프로그램도, 계정도 필요 없습니다. 잘못된 비밀번호는 읽기 횟수를 소모하지 않고 실패하며, 비밀번호를 입력하지 않으면 다시 물어볼 뿐입니다.

컨테이너의 출력을 호스트로 가져오기

공유 볼륨이 없는 컨테이너, 격리된 빌드 단계, CI 작업의 중간 출력 - stdout에는 접근할 수 있지만 파일 시스템이 실제로 결과가 필요한 곳과 공유되지 않는 모든 곳.

컨테이너 내부

$ docker run myimage some-command | curl --data-binary @- https://llmtag.com/https://llmtag.com/718234

순수 파이프(컨테이너 내에 cpy가 설치되지 않음)는 순수 URL만 돌려받습니다 - 여전히 정확히 한 줄이며, 여전히 다음 단계로 파이프할 수 있습니다:

호스트에서

$ pst 718234{"status":"ok","records_processed":48213}

컨테이너에 cpy가 설치되어 있지 않아 순수 파이프로 대체되었습니다 - 당신의 머신에는 거의 확실히 설치되어 있으므로, 다시 읽는 것은 그냥 pst면 됩니다(없다면 단순한 curl "https://llmtag.com/718234"도 동일하게 작동합니다). kubectl exec, curl조차 없는 최소한의 scratch/distroless 이미지(netcat 대체 수단 참고), 혹은 안정적으로 접근할 수 있는 유일한 것이 파이프뿐인 다른 모든 환경에서도 동일하게 작동합니다.

CLI에서 공유를 종단 간 암호화하기

위의 비밀번호(-password=)는 서버 측에서 검증됩니다 - 서버는 검증을 위해 잠깐 평문을 봅니다. cpy -e는 다르고 더 강력한 계층입니다: 암호화는 전송되기 전에 전적으로 당신의 머신에서 이루어지며, 서버는 항상 암호문만 저장합니다.

당신, 클라이언트 측에서 암호화 중

$ echo "root ssh 암호구: Tr0ub4dor&3" | cpy -e305817curl "https://llmtag.com/305817"key (share separately, never with the link/code): n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdE

코드는 한 채널로, 키는 다른 채널로 보내세요(전화, 별도의 채팅 스레드, 대면 등) - 링크나 코드만 가진 사람은 서버를 포함해 누구든 읽을 수 없는 암호문만 받게 됩니다.

코드와 키를 모두 가진 사람

$ pst 305817 -key=n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdEroot ssh 암호구: Tr0ub4dor&3

-key=를 생략하면 pst는 대신 원시 암호문을 출력합니다 - 키가 있든 없든 서버는 어차피 그것을 복호화할 정보를 충분히 갖고 있지 않습니다.