앜스토리 | 호기심 많은 개발자의 보물창고

PonsWarp의 첫 커밋은 조용하지 않았습니다.2025-11-20 ad322f3 feat : first commit이라는 짧은 메시지 안에 이미 제품의 거의 모든 욕심이 들어 있었습니다. 브라우저끼리 직접 파일을 보내고, 서버에는 데이터를 맡기지 않고, 10GB를 넘어 100GB와 1TB까지 상상하며, 그 모든 것을 사용자가 복잡하게 느끼지 않게 만들겠다는 약속이었습니다.지금 돌아보면 그 약속은 절반은 제품 방향이었고, 절반은 부채였습니다. PonsWarp는 “파일을 올리고 링크를 기다리는 서비스”가 아니라 “상대가 들어오면 바로 흐르는 전송 경험”을 만들고 싶었습니다. WebRTC, 브라우저 저장소, worker, signaling, 무결성 확인, 나중의 Cloud Drop까지 모두 그 한 문장을 지..

PonsWarp를 처음 떠올렸을 때 가장 크게 붙잡은 문장은 단순했습니다. 브라우저끼리 바로 큰 파일을 보내면 된다는 문장이었습니다.서버에 올렸다가 다시 내려받는 과정을 건너뛰고, 방을 만들고, 상대가 들어오면 WebRTC 데이터 채널로 파일을 흘려보내면 된다. 제품 설명으로는 꽤 깨끗했습니다. 지금 돌아보면 그 문장 안에는 몇 가지 착각이 숨어 있었습니다.WebRTC를 쓰면 서비스가 가벼워질 것이라는 착각, 대용량 파일은 청크로 자르면 된다는 착각, 전송 완료 이벤트가 곧 사용자 완료라는 착각, 서버는 signaling만 하면 된다는 착각입니다. 각각은 완전히 틀린 말은 아니었습니다. 그래서 더 위험했습니다. 절반만 맞는 전제는 제품을 가장 늦게 망가뜨립니다.초기 착각은 하나가 아니라 제품 표면, 전송..

PonsWarp를 허공에서 갑자기 튀어나온 프로젝트처럼 쓰고 싶지는 않았습니다.실제 기록을 보면 그 바로 앞에 아주 짧고 거친 다리가 하나 있습니다. 2025년 4월 30일에 만들어진 wormhole-file-gate입니다.이 저장소는 오래 버틴 제품은 아니었습니다. 그런데도 무시하기 어렵습니다. PonsWarp에서 본격적으로 붙잡게 되는 질문들을 한 번에 모아 놓은 프로토타입처럼 보이기 때문입니다.wormhole-file-gate는 완성품이라기보다, 이전 파일 전송 집착과 PonsWarp 본편 사이에 놓인 짧은 다리에 가까웠습니다.💡 하루짜리 저장소가 남긴 흔적💡 wormhole-file-gate는 완성품이라기보다 질문 정리용 프로토타입에 가까웠습니다. 중요한 것은 얼마나 오래 유지됐는지가 아니라,..

PonsWarp를 회고할 때 가장 조심해야 할 부분은 시작점을 너무 늦게 잡는 일입니다.2025년 11월의 첫 커밋만 보면 PonsWarp는 WebRTC, React, Rust/WASM, signaling 서버가 엮인 현대적인 브라우저 파일 전송 제품처럼 보입니다. 그런데 그 전에 이미 같은 문제가 두 번 나타났습니다. 2021년 11월 30일의 KronDelivery, 2022년 5월 31일의 filetransfer입니다.두 저장소의 내부 코드를 지금 같은 깊이로 열람할 수 있는 것은 아닙니다. 그래서 이 글은 “그때 이미 지금의 PonsWarp 구조가 있었다”라고 쓰지 않겠습니다. 확인 가능한 것은 저장소 이름, 생성 시점, 몇 개의 커밋 문구, 그리고 그 문구가 가리키는 제품 언어입니다.KronDe..

파일 전송은 흔한 기능입니다.그래서 더 오래 붙잡게 됐습니다. 화면에는 버튼 하나와 진행률 하나만 보이지만, 실제로는 연결, 권한, 메모리, 저장, 무결성, 운영이 한꺼번에 엮입니다. PonsWarp는 갑자기 나온 아이디어가 아니라, 몇 년 동안 같은 불편을 다른 이름으로 다시 만진 결과에 가깝습니다.첫 글에서 영웅담을 만들 생각은 없습니다. KronDelivery, filetransfer, wormhole-file-gate, 그리고 PonsWarp로 이어지는 흐름을 보면, “나는 왜 또 파일 전송인가”라는 질문은 낭만보다 집요한 미해결 문제에 가깝습니다.KronDelivery, filetransfer, wormhole-file-gate, PonsWarp로 이어지는 반복된 파일 전송 문제의 계보입니다.?..

PonsWarp는 겉으로 보면 브라우저 앱입니다.사용자는 링크를 열고, 파일을 고르고, 상대가 들어오면 전송을 시작합니다. 화면은 React가 그리고, 연결은 WebRTC DataChannel이 담당하고, 저장은 브라우저의 File System Access API와 worker 흐름을 탑니다. 그러면 자연스럽게 질문이 생깁니다. “브라우저 앱인데 왜 코어가 Rust인가?”짧은 답은 성능입니다. 하지만 그것만으로는 부족합니다. PonsWarp가 Rust/WASM 코어로 옮긴 것은 단순히 빠른 반복문이 아니라, 파일 전송 제품에서 거짓말하면 안 되는 바이트 단위의 계약이었습니다.브라우저 UI/JS는 사용자 흐름과 연결 제어를 맡고, Rust/WASM 코어는 파일 바이트 계약을 맡습니다.💡 이 글은 “JS는..

Season 3에서 PonsWarp는 JS에서 Rust/WASM 코어로 책임을 내려보냈습니다.ZIP64, Merkle tree, file signature, reordering buffer, zero-copy는 모두 같은 방향의 이야기였습니다. 그런데 암호화는 더 까다로운 위치에 있었습니다. 신뢰를 높이는 기능이면서 동시에 처리량과 메모리 예산을 바로 건드렸기 때문입니다.암호화는 packet path에 세션, header, 인증 태그, decrypt/verify 비용을 추가합니다.🔐 암호화는 packet path에 새 대기열을 만든다💡 핵심은 암호화를 우회해서 빠르게 만드는 쪽이 아니었습니다. PonsWarp는 CryptoSession, encrypted packet header, key confir..

PonsWarp의 reordering buffer 이야기는 이미 post-20에서 한 번 다뤘습니다.비순차로 도착한 청크를 offset 기준으로 잡아 두고, nextExpectedOffset이 맞는 것만 writer로 내보내는 장치입니다. 그때의 결론은 “받은 즉시 쓰기”가 아니라 “순서가 증명된 것만 쓰기”였습니다.post-28에서 질문은 한 단계 더 내려갑니다. 왜 이 책임을 JS 유틸로 계속 두지 않고 WASM 경계로 옮기려 했을까요. 답은 “JS가 느려서”가 아닙니다. 순서 보장, packet offset, zero-copy, writer 완료, recovery 기준이 한 덩어리의 신뢰 계약이 되었고, 그 계약을 브라우저 glue 코드에 오래 두기 어려웠기 때문입니다.JS reordering은 자..

PonsWarp가 packet checksum과 save-complete handshake까지 붙였을 때, 얼핏 보면 파일 무결성 문제는 거의 닫힌 것처럼 보입니다.하지만 packet 하나가 맞다는 사실은 전체 파일의 구조가 맞다는 뜻이 아니고, 저장이 끝났다는 사실은 저장된 파일이 기대한 산출물이라는 뜻이 아닙니다. 그래서 Season 3의 pons-core-wasm 쪽에는 Merkle tree와 file signature가 같이 등장합니다.PonsWarp의 완료 문장은 packet, 저장, Merkle proof, file signature가 각각 다른 실패 지점을 막을 때만 안전해집니다.🧱 packet-level check는 어디까지 책임졌나💡 CRC32, save-complete, Merkle..

PonsWarp의 성능 회고에서 zero-copy라는 말은 꽤 매력적으로 보입니다.대용량 파일을 브라우저에서 직접 보내고, worker와 WASM을 붙이고, WebRTC DataChannel로 밀어 넣는 제품이라면 복사를 없애는 것이 정답처럼 들립니다. 하지만 실제 기록을 따라가면 결론은 더 조심스럽습니다. PonsWarp에서 zero-copy는 “복사가 전혀 없다”가 아니라 “복사가 가장 위험하고 자주 일어나는 경계를 줄이고 통제한다”에 가까웠습니다.브라우저 파일 전송에서는 파일 조각을 읽는 순간, worker로 넘기는 순간, WASM memory에서 packet view를 얻는 순간, WebRTC가 ArrayBuffer를 소유하는 순간, receiver가 payload를 검증하고 저장하는 순간마다 경..