[SwiftBeam #01] "애플과 갤럭시 사이, 끊어진 다리를 놓다" - 멀티 디바이스 유저의 파일 전송 생존기

2026. 6. 13. 18:47AI Product Building/SwiftBeam

반응형
 
SwiftBeam Series #01

"애플과 갤럭시 사이,
끊어진 다리를 놓다"

멀티 디바이스 유저의 파일 전송 생존기

📱 ↔️ 💻 ↔️ 🍎 ↔️ 🤖

안녕하세요! 오늘부터 25회에 걸쳐 제가 직접 기획하고 밑바닥부터 개발한 크로스 플랫폼 파일 전송 프로젝트, 'SwiftBeam'의 여정을 시작합니다. 이 시리즈는 단순한 코딩 기록이 아닙니다. 한 개발자가 일상의 불편함을 기술로 어떻게 해결해 나가는지에 대한 치열한 기록이 될 것입니다.

1. 나의 디지털 환경은 왜 '전쟁터'가 되었나

저는 흔히 말하는 '얼리어답터'이자, 각 플랫폼의 장점만을 취하려는 '욕심 많은 유저'입니다. 스마트폰은 아이폰의 유려한 UI와 생태계를 좋아하지만, 업무용으로는 갤럭시의 통화 녹음과 삼성페이가 필수적입니다. 태블릿은 아이패드로 드로잉을 하고 갤럭시 탭으로 영상을 봅니다. PC 환경은 더 복잡합니다. 코딩과 영상 편집은 맥북에서, 고성능 연산과 게임은 윈도우 데스크탑에서 처리하죠.

이런 환경은 겉보기엔 화려해 보이지만, 실제로는 '플랫폼의 파편화'라는 거대한 벽에 가로막혀 있습니다. 특히 기기 간에 데이터를 옮겨야 하는 순간, 저의 스마트한 디지털 라이프는 순식간에 삐걱거리기 시작했습니다.

2. 에어드랍(AirDrop)도 퀵쉐어(Quick Share)도 답이 아니었다

각 제조사가 제공하는 전송 솔루션은 훌륭합니다. 하지만 그들은 철저히 '자신의 울타리' 안에서만 친절합니다. 애플 기기끼리의 에어드랍은 마법 같지만, 그 마법은 윈도우 PC나 안드로이드 폰 앞에서는 무용지물이 됩니다. 삼성의 퀵쉐어 역시 마찬가지입니다. 갤럭시 유저들끼리는 세상 편하지만, 옆에 있는 아이패드로 사진 한 장 보내려면 갑자기 막막해집니다.

우리가 흔히 사용하는 대안들을 살펴볼까요?

  • 카카오톡 나에게 보내기: 가장 손쉽지만 치명적인 단점이 있습니다. 사진과 영상의 화질이 저하되거나, 1GB가 넘는 고용량 파일은 아예 보낼 수 없습니다. 무엇보다 전송 속도가 인터넷 회선에 의존한다는 점이 답답했죠.
  • 클라우드 서비스(Google Drive, Dropbox): 파일을 올리고, 다시 다른 기기에서 다운로드하는 과정은 너무나 번거롭습니다. 당장 내 옆에 있는 기기에 파일을 주려고 태평양 건너 데이터 센터까지 파일을 보냈다가 다시 가져와야 하는 비효율의 극치입니다.
  • 유선 연결: 2026년인 지금, 케이블을 찾아 기기에 꽂고 드라이버를 잡고 폴더를 뒤지는 방식은 더 이상 '스마트'하지 않습니다.

3. "없으면 내가 만든다" - SwiftBeam의 철학

이 지독한 불편함을 해결하기 위해 시중에 나온 수많은 파일 전송 앱을 사용해 보았습니다. 하지만 대부분은 과도한 광고로 눈살을 찌푸리게 하거나, 설정 과정이 너무 복잡했습니다. 어떤 앱은 중국이나 해외 서버를 거쳐 전송되는 탓에 보안 문제에서 자유롭지 못했죠.

그래서 저는 결심했습니다. "모든 플랫폼을 아우르면서도, 에어드랍처럼 간편하고, 보안 걱정 없는 로컬 전송 앱을 내 손으로 직접 만들자." 그것이 바로 SwiftBeam 프로젝트의 시작이었습니다. 제가 SwiftBeam을 설계하며 스스로에게 약속한 핵심 가치는 세 가지였습니다.

첫째, 설정이 없어야 한다. 로그인이나 페어링 과정 없이 앱만 켜면 즉시 주변 기기를 찾아야 합니다.

둘째, 속도의 한계가 없어야 한다. 인터넷망이 아닌 로컬 Wi-Fi와 P2P 기술을 극대하게 활용하여 기기가 낼 수 있는 최대 속도를 보장해야 합니다.

셋째, 경계가 없어야 한다. iOS, Android, macOS, Windows, 그리고 필요하다면 Linux까지 하나의 언어로 통신할 수 있어야 합니다.

4. 25편의 대장정, 무엇을 다루게 될까?

물론 과정은 결코 쉽지 않았습니다. 각 OS마다 다른 네트워크 권한 체계, 대용량 파일을 전송할 때 발생하는 메모리 부족 현상, 서로 다른 기기를 발견하기 위한 복잡한 프로토콜 설계 등 수많은 기술적 난관이 기다리고 있었습니다.

이번 연재를 통해 저는 단순히 '코드'를 공유하는 것을 넘어, 문제를 정의하고 기술적으로 접근하여 해결하는 일련의 사고 과정을 보여드리려 합니다.

  • ✅ 왜 많은 프레임워크 중 Flutter를 선택했는가?
  • ✅ 중앙 서버 없이 기기를 어떻게 찾아낼 것인가? (mDNS, UDP 스캔)
  • ✅ 대용량 스트림을 끊김 없이 전송하는 최적의 방법은?
  • ✅ 윈도우와 맥의 네이티브 기능을 어떻게 제어할 것인가?

이제 첫걸음을 뗐습니다. SwiftBeam은 단순히 파일을 옮기는 도구를 넘어, 제조사가 쳐놓은 보이지 않는 벽을 허무는 도전입니다. 여러분도 비슷한 불편함을 느끼셨다면, 저와 함께 이 긴 여정을 함께해주시기 바랍니다.

다음 편 예고: [SwiftBeam #02] 플러터(Flutter)로 결정한 이유 - 생산성과 성능 사이의 최적점 찾기

SwiftBeam 외에도 일상의 불편함을 해결하기 위해 고민하며 만든
다양한 앱 프로젝트들이 궁금하시다면 아래 사이트에서 확인해 보세요!

Team M2Y 제품 포트폴리오 구경하기 →
TAGS: Flutter, 플러터, Dart, 크로스플랫폼, 앱개발, SwiftBeam, 개발일기, 기술스택, 소프트웨어아키텍처, 1인개발
반응형