폰과 PC 사이에 파일이 어떻게 건너가나

건네가 하는 일

PC방이나 사무실, 학교에서 내 폰에 있는 사진을 지금 앉은 PC 로 옮겨야 할 때, 또는 PC 에서 받은 PDF 를 내 폰에 넣어야 할 때 쓰는 도구입니다. 흔히 메신저의 나에게 보내기나 이메일을 쓰는데, 그러면 파일이 남의 서버에 올라가고 남의 PC 에 내 계정으로 로그인해야 합니다. 건네는 그 둘을 하지 않습니다.

두 기기의 브라우저가 서로를 직접 찾아 잇고, 파일은 그 사이로만 갑니다. 이 연결을 만드는 기술이 WebRTC 이고, 화상 통화가 쓰는 것과 같은 것입니다. 우리 서버는 두 기기가 서로를 찾도록 코드 하나를 잠깐 맡아 둘 뿐이고, 그것마저 안 거치는 길(서버 없이 직접)도 있습니다.

한 기기에서 보내기와 받기가 다 됩니다. 보내는 쪽이 파일을 담고 연결 준비를 누르면 여섯 자 코드와 QR 이 뜨고, 받는 쪽이 그 코드를 넣거나 QR 을 찍으면 연결이 되어 파일이 갑니다. 받은 파일은 받는 쪽 브라우저의 다운로드 자리에 저장됩니다.

브라우저가 정한 규칙

브라우저끼리 직접 잇는 방식은 IETF 가 표준으로 정해 두었습니다(RFC 8825 와 RFC 8829). 두 기기는 연결 전에 서로의 주소와 열쇠를 한 번 교환해야 하는데, 이 교환을 시그널링이라 부르고 표준은 그 경로를 정하지 않습니다. 그래서 서비스마다 다릅니다. 건네는 그 경로로 여섯 자 코드 우편함과 QR 두 장, 둘을 둡니다.

자기 주소를 알아내는 데 STUN 이라는 공개 서버를 씁니다(RFC 8489). 공유기 뒤에 있는 기기는 바깥에서 보이는 자기 주소를 모르기 때문에 그것을 물어보는 것이고, 파일은 그쪽으로 가지 않습니다. 건네는 구글이 공개한 STUN 주소를 쓰는데, 구글이 그 서버의 이용 조건을 문서로 밝힌 곳은 찾지 못했습니다. 널리 쓰이지만 약속된 것은 아니라는 뜻이고, 그래서 STUN 이 답을 안 해도 같은 Wi-Fi 안에서는 연결이 되게 해 두었습니다.

직결이 안 될 때 중계해 주는 TURN 서버라는 것도 표준에 있지만 건네는 쓰지 않습니다. 중계는 파일이 서버를 지난다는 뜻이고 그 비용은 누군가 내야 합니다. 같은 자리에 있는 두 기기라는 전제에서 중계는 필요 없어야 하고, 안 되면 안 된다고 말하는 쪽을 골랐습니다.

연결이 되면 파일은 DataChannel(RFC 8831)로 갑니다. 이 채널은 DTLS 로 암호화되어 있어 같은 Wi-Fi 의 다른 기기가 엿볼 수 없습니다. 열쇠(지문)는 시그널링 때 교환한 것과 대조되므로, 코드를 아는 사람이 아니면 끼어들 수 없습니다.

이 앱의 세부 규칙

여기는 코드가 실제로 하는 일을 순서대로 적은 것입니다. 보내는 쪽이 연결 준비를 누르면 브라우저가 연결 신호(SDP)를 만들고 주소 후보를 모읍니다. 모으기는 3초 안에 끝내고, 그 뒤엔 모인 것만으로 갑니다. 그 신호에서 상대에게 정말 필요한 값 넷(ICE 아이디와 비밀번호, DTLS 지문, 주소 후보)만 뽑아 한 줄로 줄입니다. 원문은 보통 1,000자를 넘는데 줄이면 수백 자가 됩니다. 이 줄이기는 값을 바꾸지 않고 자리만 옮기는 것이라, 받는 쪽에서 표준 꼴로 다시 폅니다.

코드 우편함은 우리 서버 메모리에 있는 상자입니다. 보내는 쪽의 한 줄을 넣으면 여섯 자 코드를 돌려주고, 받는 쪽이 그 코드로 한 줄을 꺼내 자기 답 한 줄을 넣습니다. 상자에 들어갈 수 있는 것은 8KB 이하의 글뿐이라 파일은 구조적으로 들어갈 수 없고, 10분이 지나면 지웁니다. 디스크에 쓰지 않고 로그에도 남기지 않습니다. 서버가 다시 켜지면 전부 사라지는데, 그래도 되는 자료입니다.

파일은 16KB 조각으로 나눠 보냅니다. 브라우저마다 한 번에 보낼 수 있는 크기가 달라서 그 아래로 잡았습니다. 보내는 쪽은 버퍼가 차면 잠깐 쉬고, 받는 쪽은 조각을 모아 저장할 파일로 다시 붙입니다. 받는 쪽이 조각을 다 받으면 보내는 쪽에 그렇다고 알리고, 보내는 화면에 다 닿았다는 줄이 뜹니다.

파일 하나의 상한은 1GB 입니다. 받는 쪽이 조각을 브라우저 메모리에 모았다가 저장하기 때문에 실제 한계는 그 기기의 메모리입니다. 만든 날 PC 의 크로미움에서 재 본 크기까지는 되었고, 폰은 그 환경에서 재지 못했습니다. 그래서 폰으로 받을 때는 큰 파일을 몇 개로 나누라고 안내합니다. 이 숫자를 넉넉하게 적어 두고 안 되는 것을 되는 것처럼 말하고 싶지 않아서 그렇게 적었습니다.

글이나 링크는 파일과 달리 메시지 하나로 갑니다. 10,000자까지이고, 받는 쪽에서 복사하거나 링크면 바로 열 수 있습니다.

계측은 어느 단계까지 왔는지(화면을 열었는지, 연결 준비를 눌렀는지, 연결됐는지, 다 건넸는지, 형제 도구 링크를 눌렀는지)만 셉니다. 파일 이름도 크기도 코드도 싣지 않습니다.

쓰는 요령

두 기기를 같은 Wi-Fi 나 같은 핫스팟에 둡니다. PC방이나 사무실 PC 가 유선이고 폰이 Wi-Fi 라면 대개 같은 공유기 뒤라 됩니다. 폰의 데이터(LTE)와 PC 의 유선처럼 서로 다른 망이면 연결이 안 될 수 있습니다. 그때는 폰의 핫스팟을 켜고 PC 를 거기에 붙이는 것이 가장 확실합니다.

PC 에서 폰으로 보낼 때는 PC 를 보내는 쪽으로 두고 파일을 담은 다음 연결 준비를 누릅니다. 뜨는 QR 을 폰 카메라로 찍으면 받는 화면이 바로 열리고 연결이 됩니다. 폰에서 PC 로 보낼 때는 반대로 폰이 보내는 쪽이고, PC 화면에서 받는 쪽을 고른 뒤 폰에 뜬 여섯 자 코드를 칩니다.

받은 파일은 저장을 눌러야 다운로드 자리에 들어갑니다. 화면을 닫으면 받은 것은 사라집니다. 여러 개를 받았으면 하나씩 저장합니다.

PC방처럼 남의 PC 라면 다 쓴 뒤 브라우저의 다운로드 자리에서 파일을 지우는 것을 잊지 마세요. 건네는 서버에 아무것도 남기지 않지만, 그 PC 의 다운로드 폴더에는 남습니다.

서버 없이 QR 로만 잇기

코드 우편함을 안 거치는 길입니다. 보내는 쪽에 연결 신호가 QR 로 뜨고, 받는 쪽이 그것을 찍으면 답이 QR 로 뜹니다. 그 답을 보내는 쪽이 다시 찍으면 연결이 됩니다. 이 길에서는 우리 서버가 아무것도 받지 않습니다.

QR 한 장에 담는 글은 700자까지로 잡았고, 줄인 연결 신호는 보통 그 안에 들어갑니다. 넘치면 여러 장으로 나뉘고 스캐너가 차례로 모읍니다. 화면에 원문이 몇 바이트였고 몇 자로 줄었는지, QR 이 몇 칸짜리인지 그대로 보여 줍니다.

둘째 걸음(답을 보내는 쪽으로 되돌리기)에 보내는 쪽 기기의 카메라가 필요합니다. 노트북은 대개 되고 데스크톱은 웹캠이 없는 경우가 많습니다. 그때는 답 글을 붙여 넣는 칸이 있는데, 수백 자를 손으로 옮기기는 어려우므로 그런 PC 에서는 코드 우편함 쪽이 맞습니다. 이 길을 남겨 둔 이유는 서버가 없어도 되는 길이 하나는 있어야 한다고 봤기 때문입니다.

안 될 때 볼 자리

연결하는 중에서 멈추고 안 됐다는 줄이 뜨면 대개 망이 기기끼리의 통신을 막고 있는 경우입니다. 카페나 학교 Wi-Fi 에는 손님 기기끼리 서로 못 보게 하는 설정(AP 격리)이 흔하고, 회사 망은 UDP 를 막기도 합니다. 폰 핫스팟에 둘을 붙이면 대개 풀립니다.

코드를 넣었는데 없다고 하면 보내는 쪽 화면이 아직 코드를 띄우고 있는지 봐 주세요. 코드는 10분 뒤 사라지고, 보내는 쪽이 화면을 닫아도 연결이 안 됩니다. 코드 우편함 자체에 닿지 못한다는 줄이 뜨면 우리 서버가 잠깐 죽은 것이니 서버 없이 직접 연결로 가면 됩니다.

큰 파일이 받는 중에 멈추면 받는 기기의 메모리가 모자란 경우가 많습니다. 특히 폰이 그렇습니다. 파일을 나눠 보내거나, 받는 쪽을 PC 로 바꾸세요.

사파리(아이폰)에서 파일 저장을 누르면 다운로드 대신 새 창이 열릴 때가 있습니다. 그 창에서 공유 단추로 파일에 저장을 고르면 됩니다. 브라우저가 WebRTC 를 꺼 두었으면(일부 사생활 보호 설정) 연결 준비에서 멈추는데, 그 경우 화면이 그렇게 말합니다.

이 도구는 두 기기가 같은 자리에 있을 때를 위한 것입니다. 멀리 있는 사람에게 보내려면 파일을 올려 두는 서비스가 맞고, 그런 서비스는 파일을 서버에 두는 대신 그 값을 받습니다. 건네는 그 반대 자리입니다.