로컬 네트워크용 오픈소스 에어드롭 대안, 로컬센드

• 로컬센드는 한마디로 “오픈소스 에어드롭 대안”임. 인터넷 없이 같은 로컬 네트워크 안에서 파일과 메시지를 바로 주고받게 해주는 앱이다.

  • 외부 서버를 거치지 않아서 클라우드 업로드, 계정 로그인, 메신저 전달 같은 우회로가 필요 없음.
  • 윈도우·맥·리눅스·안드로이드·아이오에스처럼 여러 플랫폼을 섞어 쓰는 환경에서 특히 쓸모가 큼.

• 구조는 생각보다 개발자 친화적임. 기기끼리 REST API로 통신하고, 데이터는 HTTPS로 암호화해서 보낸다.

  • TLS/SSL 인증서는 각 기기에서 즉석으로 생성하는 방식이라, 중앙 서버에 의존하지 않는 설계를 유지함.
  • “로컬 네트워크라 괜찮겠지” 하고 평문 전송하는 도구들과 달리, 기본 보안 모델을 챙긴 게 포인트다.

• 다만 연결이 안 될 때는 앱보다 네트워크 설정을 먼저 의심해야 함.

  • 방화벽이 로컬센드의 로컬 네트워크 통신을 막고 있으면 송수신이 실패할 수 있음.
  • 라우터에서 AP isolation이 켜져 있으면 같은 와이파이에 있어도 기기끼리 서로 못 봄. 특히 게스트 네트워크에서 자주 걸리는 함정임.

• 설치는 앱스토어나 패키지 매니저 경로가 권장됨. 이유는 단순한데, 앱 자체에 자동 업데이트가 없기 때문임.

  • 최신 커밋 기반의 비공식 MSIX 프리뷰 빌드도 있지만 안정성은 보장되지 않는다고 명시돼 있음.
  • 운영용으로 쓸 거면 검증된 배포 채널을 타는 게 낫다.

• 개발 관점에서는 Flutter와 Rust가 필요하고, Flutter 버전 관리에 fvm을 쓰는 구조임.

  • 저장소를 클론한 뒤 app 디렉터리에서 의존성을 받고 실행하는 흐름이다.
  • 현재는 특정 구버전 Flutter가 필요해서, 시스템에 깔린 Flutter와 버전이 안 맞으면 빌드 이슈가 날 수 있음.

---

기술 맥락

• 로컬센드의 선택은 “파일 전송 서버를 하나 두자”가 아니라 “각 기기가 직접 통신하게 하자”에 가까워요. 그래서 REST API를 쓰면서도 외부 백엔드가 아니라 로컬 네트워크 안의 피어끼리 요청을 주고받는 구조가 됩니다.

• HTTPS를 붙인 이유도 꽤 현실적이에요. 같은 와이파이라고 해도 회사망, 카페망, 게스트망에서는 누가 같은 네트워크에 붙어 있는지 알기 어렵거든요. 로컬 전송 도구라도 암호화를 기본값으로 두는 게 맞다는 판단이에요.

• 문제 해결 포인트가 방화벽과 AP isolation에 몰리는 것도 이 구조 때문이에요. 중앙 서버를 경유하지 않으니 네트워크가 기기 간 직접 통신을 막으면 앱이 아무리 잘 만들어져도 전송이 안 됩니다.

• Flutter를 쓰는 건 여러 운영체제용 앱을 한 코드베이스에서 가져가려는 선택으로 볼 수 있어요. 대신 특정 Flutter 버전에 묶이는 순간 빌드 재현성이 중요해져서, fvm으로 프로젝트 버전을 고정하는 방식이 같이 따라온 거예요.