PairDrop vs Send: 로컬 또는 링크 기반 공유?

발행: (2026년 3월 9일 AM 10:31 GMT+9)
8 분 소요
원문: Dev.to

I’m happy to translate the article for you, but I need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line and all formatting exactly as you requested.

빠른 판단

PairDropSend는 서로 다른 문제를 해결합니다.

  • PairDrop: 근처 기기 간 즉시 로컬 파일 전송 (AirDrop을 떠올려 보세요).
  • Send: 암호화된 만료 링크를 통해 누구와도 파일 공유 (WeTransfer를 떠올려 보세요).

사용 사례에 따라 선택하세요, 어느 것이 “더 좋다”는 것이 아니라.

기능 비교

기능PairDropSend
전송 방법피어‑투‑피어 (WebRTC)업로드 → 링크 → 다운로드
검색LAN에서 자동 검색수동 링크 공유
암호화WebRTC (DTLS)종단 간 (브라우저 측 AES‑GCM)
파일 크기 제한없음 (피어‑투‑피어)설정 가능 (기본 ≈ 2.5 GB)
만료되는 링크해당 없음예 (시간 + 다운로드 횟수)
비밀번호 보호해당 없음
서버 저장소 필요없음예 (암호화된 파일 저장)
계정 필요아니오아니오
텍스트/메시지 공유아니오
다중 수신자모든 LAN 장치링크가 있는 모든 사람
오프라인 전송아니오 (시그널링 서버 필요)아니오 (스토리지 서버 필요)
모바일 지원브라우저 기반 (모든 플랫폼)브라우저 기반 (모든 플랫폼)
외부 공유TURN 서버만 사용예 (URL이 있는 누구든)
라이선스GPL‑3.0MPL‑2.0

자체 호스팅

PairDrop (단일 컨테이너)

# docker-compose.yml
services:
  pairdrop:
    image: ghcr.io/schlagmichdoch/pairdrop:v1.11.2
    ports:
      - "3000:3000"
    restart: unless-stopped
  • 하나의 컨테이너, 데이터베이스 없음, 영구 저장소 없음.
  • 서버는 WebRTC 시그널링만 처리하며, 파일은 서버를 거치지 않습니다.

Send (앱 + Redis + 스토리지)

# docker-compose.yml
services:
  send:
    image: registry.gitlab.com/timvisee/send:v3.4.27
    ports:
      - "1443:1443"
    volumes:
      - ./uploads:/uploads
    environment:
      - REDIS_HOST=redis
    depends_on:
      - redis
  redis:
    image: redis:7-alpine
  • 두 개의 컨테이너(앱 + Redis)와 업로드된 파일을 위한 영구 볼륨이 필요합니다.
  • 구성에는 BASE_URL, 업로드 제한 및 만료 기본값이 포함됩니다.

Resource Usage

MetricPairDropSend
RAM (idle)~30 MB~80‑110 MB (앱 + Redis)
Disk usage없음업로드에 비례
Network load on server신호 전송만 (~KB)전체 파일 업로드 + 다운로드
Containers12 (앱 + Redis)
Bandwidth impact피어 간 직접서버가 중개자 역할

커뮤니티 및 유지보수

  • PairDrop: 약 4.5 k GitHub 스타, 활발한 개발 중, 방, 지속적인 페어링 및 텍스트 공유 기능을 갖춘 Snapdrop 포크. 문서에는 Docker 배포와 선택적 TURN 서버 설정이 포함됩니다.
  • Send: 약 4.8 k GitHub 스타, 중단된 Firefox Send의 유지 관리된 포크. 유지 관리자(timvisee)가 정기적인 업데이트를 제공하고 배포 예제가 포함된 별도 Docker‑Compose 저장소를 제공합니다.

결과: 두 프로젝트 모두 커뮤니티 규모와 활발한 유지보수가 비슷합니다.

Source:

올바른 도구 선택

  • PairDrop를 사용할 경우:

    • 모든 플랫폼에서 AirDrop과 같은 기능이 필요할 때.
    • 프라이버시가 최우선일 때(파일이 서버에 절대 저장되지 않음).
    • 같은 네트워크(사무실, 가정) 내 기기 간 전송일 때.
    • 유지보수가 전혀 필요 없는 배포를 원할 때.
  • Send를 사용할 경우:

    • 네트워크 외부 사람들과 파일을 공유해야 할 때.
    • 만료되거나 비밀번호로 보호된 다운로드 링크가 필요할 때.
    • 저장된 파일의 종단 간 암호화가 중요할 때.
    • WeTransfer 등 유사 서비스를 대체하고 싶을 때.
    • 다운로드 횟수를 제어해야 할 때.
  • 두 가지를 함께 사용할 경우: 서로 보완적인 역할을 합니다. PairDrop는 로컬에서 빠르고 프라이빗한 전송을 담당하고, Send는 원격에서 링크 기반 공유를 담당합니다.

  • 하나만 선택해야 한다면:

    • PairDrop – 개인/가정용(대부분의 파일 공유가 자신의 기기 간에 이루어지는 경우).
    • Send – 팀/비즈니스용(고객, 파트너 또는 네트워크 외부와 파일을 공유할 때).

자주 묻는 질문

Q: TURN 서버 없이 PairDrop을 사용할 수 있나요?
A: 예, 하지만 동일한 LAN 또는 VPN에 있는 장치 간에만 가능합니다. NAT를 통과하거나 인터넷을 통해 연결을 중계하려면 TURN 서버(예: coturn)가 필요합니다.

Q: Send의 암호화가 진정한 종단 간 암호화인가요?
A: 예. 암호화는 업로드 전에 브라우저에서 이루어집니다. 서버는 암호화된 블롭만 저장하며, 복호화 키는 URL 조각(#…)에 포함되고 서버로 전송되지 않습니다.

Q: Send에서 파일이 만료된 후 어떻게 되나요?
A: 암호화된 파일은 서버에서 자동으로 삭제됩니다. 파일도 메타데이터도 복구할 수 없습니다.

Q: 각 서비스는 얼마나 많은 RAM을 사용하나요?
A: PairDrop은 약 30 MB RAM(시그널링만) 사용합니다. Send는 약 80‑110 MB RAM(앱 + Redis)과 저장된 업로드를 위한 디스크 공간을 사용합니다.

  • PairDrop 자체 호스팅
  • Send 자체 호스팅
  • Send vs WeTransfer
  • AirDrop에 대한 자체 호스팅 대안
  • WeTransfer에 대한 자체 호스팅 대안
  • 최고의 자체 호스팅 파일 공유 도구
  • Docker Compose 기본
0 조회
Back to Blog

관련 글

더 보기 »