마우스 오른쪽 버튼, 「압축」, 기다리기, 첨부, 보내기. 그러면 수신자는 내려받고, 마우스 오른쪽 버튼, 「압축 풀기」, 또 기다립니다. 대부분 별생각 없이 이렇게 합니다. 수십 년 동안 폴더를 보내는 방식이었으니까요. 저는 공유하려고 폴더를 압축하는 일을 이제 그만둘 때라고 생각합니다. ZIP 형식은 1989년에 나왔고, 당시의 문제는 문서를 플로피 디스크와 느린 모뎀에 밀어 넣는 것이었습니다. 오늘날 우리의 폴더는 영상 프로젝트, 사진 촬영본, 코드 저장소이고, 오래된 습관은 아끼는 것보다 더 많은 비용을 치르게 합니다.
애초에 왜 폴더를 압축할까요?
대부분의 공유 채널이 단일 파일만 실어 나르기 때문입니다. 이메일 첨부도 파일 하나입니다. 채팅 업로드도 파일 하나입니다. 전통적인 다운로드 링크도 파일 하나를 가리킵니다. 폴더는 파일의 트리이므로, 그 통로를 지나려면 먼저 하나의 파일로 묶어야 합니다.
압축은 두 번째 이유였고, 1989년에는 중요했습니다. 텍스트와 스프레드시트는 많이 줄어드니까요. 하지만 오늘날 사람들이 보내는 대부분의 폴더에서 그 이유는 조용히 사라졌습니다.
압축하면 실제로 무엇을 잃나요?
실제 예를 들어 보겠습니다. 결혼식 촬영본 40 GB 폴더입니다. RAW 사진, MP4 클립 몇 개, 보정한 JPEG 몇 장이 들어 있습니다.
- 디스크 공간, 두 배. 원본 옆에 압축 파일을 둘 약 40 GB의 여유 공간이 필요합니다. 수신자는 ZIP에 40 GB, 압축을 풀 공간으로 또 40 GB가 필요합니다. 40 GB 폴더에 80 GB입니다. 적어도 압축 파일을 지울 때까지는요.
- 시간, 세 배. 묶는 동안 기다리고, 전송하는 동안 기다리고, 수신자는 압축을 푸는 동안 기다립니다. 노트북에서 수십 기가바이트를 묶고 푸는 데는 전송 자체만큼 걸리기도 합니다.
- 압축이 거의 안 됩니다. JPEG, MP4, MOV와 대부분의 RAW 형식은 이미 압축되어 있습니다. 압축해도 크기가 거의 변하지 않습니다. 시간과 디스크 공간을 쓰고 돌려받는 것은 거의 없습니다.
- 끝날 때까지 아무것도 쓸 수 없습니다. 큰 압축 파일 하나라면, 마지막 바이트가 도착하고 전체 압축이 풀릴 때까지 수신자는 첫 번째 사진조차 열 수 없습니다.
ZIP 안에서는 무엇이 깨지나요?
비용만의 문제가 아닙니다. 일이 잘못되기도 하고, 대개 가장 나쁜 순간에 그렇습니다.
긴 경로. Windows는 기본적으로 파일 경로 전체 길이를 260자로 제한합니다. Mac에서 깊은 하위 폴더와 설명적인 이름으로 만든 프로젝트 폴더는 Windows에서 압축을 풀 때 오류가 나거나 파일이 빠질 수 있습니다.
거대한 압축 파일. 원래 ZIP 형식은 파일당 4 GB, 항목 65,535개에서 멈춥니다. ZIP64 확장이 이 한계를 없앴지만, 모든 컴퓨터의 모든 도구가 똑같이 처리하지는 않습니다. 일부 클라우드 드라이브는 큰 폴더 다운로드를 여러 ZIP 파일로 나누고, 수신자는 그것을 다시 맞춰야 합니다.
파일 이름. 한 도구로 만들고 다른 도구로 연 압축 파일은 키릴 문자, 그리스 문자, 중국어, 악센트가 있는 글자 같은 비라틴 파일 이름을 깨뜨릴 수 있습니다. 구조는 도착하는데 이름은 도착하지 않습니다.
쓰레기 파일. macOS Finder로 만든 압축 파일에는 __MACOSX 폴더와 .DS_Store 파일이 들어 있어 Windows
사용자를 혼란스럽게 하고 수신자의 프로젝트에 섞여 들어갑니다.
오류 하나에 처음부터. 40 GB 다운로드가 95 %에서 실패하면 압축 파일은 쓸모가 없습니다. 바이트 하나가 손상되면 압축 풀기가 중간에 멈출 수 있습니다.
어느 것도 특이한 일이 아닙니다. 몇 기가바이트가 넘는 폴더를 보내 본 적이 있다면 이 중 적어도 하나는 겪어 보셨을 겁니다.
StrongFolder는 어떻게 폴더를 폴더 그대로 보내나요?
저희는 간단한 아이디어로 StrongFolder를 만들었습니다. 파일이 내 브라우저에서 수신자의 브라우저로 직접 간다면, 먼저 하나의 파일로 묶을 이유가 없습니다.
폴더를 고르면 브라우저가 그 트리, 즉 모든 하위 폴더와 파일 이름을 읽습니다. 아무것도 업로드되지 않습니다. 링크를 보내면 수신자가 열고 저장 위치를 고릅니다. 그다음 파일이 각자의 상대 경로와 함께 암호화된 WebRTC 연결을 통해 두 브라우저 사이를 직접 이동하고, 같은 폴더 트리가 수신자의 디스크에 나타납니다.
실제로 달라지는 점은 다음과 같습니다.
- 묶기도 풀기도 없습니다. 수신자가 링크를 여는 순간 전송이 시작됩니다.
- 추가 디스크 공간이 필요 없습니다. 수신자는 폴더와 압축 파일이 아니라 폴더만큼의 공간만 있으면 됩니다.
- 파일이 하나씩 도착합니다. 나머지가 아직 오는 중에도 첫 사진들은 이미 수신자의 디스크에 있습니다.
- 경로를 정직하게 처리합니다. Windows에서 경로가 너무 길면 이름을 줄이고, 이름이 바뀐 모든 파일을 적은 텍스트 파일을 추가합니다. 아무것도 조용히 사라지지 않습니다.
- 저희가 정한 용량 제한이 없습니다. StrongFolder가 정한 용량 제한은 없습니다. 실제 한계는 받는 기기의 여유 디스크 공간, 연결 속도, 두 기기가 온라인을 유지하는 시간입니다.
제가 항상 말씀드리는 조건이 두 가지 있습니다. 폴더 전체를 구조 그대로 저장하려면 수신자는 컴퓨터의 Chrome, Edge, Opera 또는 다른 Chromium 계열 브라우저가 필요합니다. 다른 브라우저는 파일을 하나씩 또는 ZIP으로 내려받습니다. 그리고 수신자가 다 받을 때까지 탭이 열려 있어야 합니다. 파일이 서버가 아니라 내 기기에서 나오기 때문입니다. 이것이 아무것도 업로드하지 않는 대가입니다. 보내는 사람이 온라인 상태로 있어야 하는 이유에서 자세히 설명합니다.
무료 · 브라우저에서 바로 · 가입 불필요
ZIP이 여전히 알맞은 도구인 경우는 언제인가요?
저는 ZIP에 반대하지 않습니다. 훌륭한 형식입니다. 다만 매번 보내기 전의 기본 단계로는 아닙니다. 저는 지금도 다음과 같을 때 압축합니다.
- 보관할 때. 파일 하나가 저장하고, 체크섬을 확인하고, 몇 년 동안 보관하기 쉽습니다.
- 비밀번호가 필요할 때. StrongFolder 링크에는 비밀번호가 없습니다. 민감한 파일이라면 암호화된 압축 파일(예: AES-256을 쓰는 7-Zip)과 다른 채널로 보낸 비밀번호가 어떤 전송 방법에서든 통하는 보호 계층을 더합니다.
- 폴더가 아주 작은 파일 수만 개로 되어 있을 때.
node_modules폴더나 작은 이미지 캐시는 파일마다 오버헤드가 있어서 하나의 파일로 묶는 편이 더 빨리 전송됩니다. - 수신자가 휴대폰을 쓸 때. 휴대폰은 브라우저에서 폴더 트리를 저장할 수 없으므로 어차피 파일이 하나씩 또는 ZIP으로 옵니다.
그 밖의 모든 것, 즉 촬영본, 편집본, CAD 프로젝트, 게임 모드, 스캔한 자료는 폴더를 있는 그대로 보내세요.
폴더 압축을 완전히 그만두려면 어떻게 하나요?
이메일, 클라우드 드라이브, 전송 서비스를 나란히 비교한 단계별 안내를 원하신다면 압축하지 않고 폴더를 보내는 방법을 읽어 보세요. 아주 큰 폴더라면 대용량 파일을 보내는 방법에서 속도와 설정을 다루고, 제한 사항과 요구 사항에 브라우저 관련 세부 사항이 모두 나와 있습니다.
그리고 폴더가 이름이 틀리거나 하위 폴더가 빠지는 등 망가진 채 도착한다면 info@strongfolder.com로 제게 메일을 보내 주세요. 폴더는 StrongFolder가 존재하는 이유이고, 저는 그 사실을 알고 싶습니다.