Writing

시리즈: ponswarp-origin-story에 해당하는 글입니다.

주제

프로젝트

글 유형

12개의 글

2026년 6월 29일·PonsWarp Origin Story·4 min

[PonsWarp] 대용량 전송에서는 속도보다 흐름 제어가 먼저였다

대용량 파일 전송을 처음 볼 때는 속도가 가장 중요한 숫자처럼 보였다. 하지만 큰 파일을 실제 브라우저로 보내 보니 문제는 전송률이 아니었다. 보내는 쪽이 계속 밀어 넣는 동안 받는 쪽의 메모리와 저장 속도가 따라오지 못했고, 실패는 마지막 몇 퍼센트에서야 드러났다. PonsWarp에서 ACK는 “받았다”는 표시만을 위한 메시지가 아니었다. 수신자가 다음 데이터를 받을 준비가 됐다는 신호로 써야 했다. 보내는 쪽이 자기 속도만 믿고 앞서가면 전송은 잠깐 빨라 보이지만, 브라우저가 버티지 못하는 순간 전체 작업이 무너진다.

PonsWarpMain ServicesBackpressureWASMLarge Files

2026년 6월 29일·PonsWarp Origin Story·9 min

[PonsWarp] 서버가 파일을 갖지 않는 전송을 만들고 싶었다

큰 파일을 보낼 때 사람들은 보통 클라우드를 떠올린다. 올리면 링크가 생기고, 상대가 받는다. 익숙하지만 대가는 분명하다. 서버가 파일을 잠시라도 갖게 되고, 권한·보관·삭제·비용 문제가 따라온다. PonsWarp에서 붙잡은 질문은 단순했다. **서버가 파일을 소유하지 않는 전송을 만들 수 있는가.**

PonsWarpMain ServicesWebRTCFile TransferP2P

2026년 6월 29일·PonsWarp Origin Story·2 min

[PonsWarp] 결국 내가 만든 건 파일 전송 버튼이 아니라 실패를 견디는 흐름이었다

결국 만든 것은 파일 전송 버튼이 아니라 실패를 견디는 흐름이었다. 처음에는 PonsLink 방 안에서 파일을 보내면 충분할 줄 알았다. 파일이 커지자 전송은 방의 부가기능이 아니라 별도 제품처럼 행동했다. 브라우저 메모리, 수신 속도, 저장 방식, ACK, 백프레셔가 한꺼번에 얽혔다. 보내는 일과 받는 일과 저장하는 일이 같은 속도로 진행되지 않으면 사용자는 전체 전송이 실패했다고 느꼈다.

PonsWarpProduct RetrospectiveDirectCloud DropFailure Recovery

2026년 6월 29일·PonsWarp Origin Story·5 min

[PonsWarp] 결제 성공보다 권한 증명이 먼저였다

PonsWarp에서 파일 전송을 별도 제품으로 분리한 뒤에도 결제와 입장 권한의 문제가 남았다. 결제 성공 화면을 보여 주는 것과 실제로 세션에 들어갈 권한을 증명하는 것은 같은 사건이 아니었다. 브라우저의 화면만 믿으면 권한이 확정되기 전에 입장을 열 수 있다. 결제 성공, 권한 부여, 세션 입장은 사용자에게는 한 번의 흐름처럼 보이지만 운영상 분리해야 했다. 결제 상태를 서버가 확인하고, 그 결과로 입장 권한을 발급해야 한다. 화면이 먼저 초록색으로 바뀌었다고 방을 열 수는 없다.

PonsWarpWebRTCFile TransferRetrospective

2026년 6월 29일·PonsWarp Origin Story·6 min

[PonsWarp] 브라우저마다 파일 저장 방식이 다르게 깨졌다

처음에는 PonsLink 안에 있는 파일 전송 기능이었다. 방 안에서 파일을 보내면 충분할 줄 알았는데, 파일 크기가 커질수록 회의방의 리듬까지 흔들렸다. 파일 전송은 처음엔 방 안의 작은 부가기능처럼 보였다. 그런데 파일이 커질수록 이 기능은 방 전체를 흔드는 별도 제품이 됐다. 다음 글에서는 OPFS, ZIP64, 메모리 경계 중 실제 저장 안정화 질문을 넘어간다. 특히 PonsWarp에서는 재현 조건을 같이 적어야 의미가 있었다. 브라우저마다 파일 저장 전송 프로토콜이 같아도 마지막 저장 UX는 브라우저마다 다르고, 그…

PonsWarpWebRTCFile TransferRetrospective

2026년 6월 29일·PonsWarp Origin Story·5 min

[PonsWarp] 모바일 브라우저가 잠들면 전송은 어떻게 이어져야 하나

정성적으로는 사용자가 '거의 다 됐는데 왜 깨졌지'라는 불신을 덜 느끼게 하는 게 목표였다. 이때부터 PonsWarp의 기준은 최고 속도가 아니라 끝까지 살아남는 흐름이 됐다. 다음 글에서는 OPFS, ZIP64, 메모리 경계 중 실제 저장 안정화 질문을 넘어간다. 방 안에서 파일을 보내면 충분할 줄 알았는데, 파일 크기가 커질수록 회의방의 리듬까지 흔들렸다. 처음에는 빨리 보내는 쪽이 이기는 줄 알았다. 그런데 속도를 올릴수록 받는 쪽 버퍼가 먼저 비명을 질렀다. 특히 PonsWarp에서는 재현 조건을 같이 적어야 의미가 있었다.

PonsWarpWebRTCFile TransferRetrospective

2026년 6월 29일·PonsWarp Origin Story·4 min

[PonsWarp] 끊긴 전송에서 partial file을 남기지 않기로 했다

전송이 끊기면 처음부터 다시 보내는 게 정석처럼 느껴졌다. 상태도 적고 디버깅도 쉽고 실패하면 재시도라는 문장도 깔끔했다. 작은 파일에서는 그 전략이 실제로 잘 작동했다. 문제는 파일이 커지고 네트워크가 불안정해질 때 시작됐다. 대용량 앞에서 처음부터 다시는 단순한 재시도가 아니라 기다림의 몰수다. 사용자가 길게 쌓은 진행률이 0으로 돌아가면 제품은 기능 실패가 아니라 약속 파기로 읽힌다. 그래서 끊긴 전송에서 부분 파일을 어떻게 다룰지가 복구 품질의 중심이 됐다.

PonsWarpWebRTCFile TransferRetrospective

2026년 6월 29일·PonsWarp Origin Story·5 min

[PonsWarp] Cloud Drop은 P2P의 대체재가 아니라 보완재다

다음에 남는 질문은 한 문장으로 충분하다. 처음에는 PonsLink 안에 있는 파일 전송 기능이었다. 방 안에서 파일을 보내면 충분할 줄 알았는데, 파일 크기가 커질수록 회의방의 리듬까지 흔들렸다. 처음에는 쉽게 정리할 수 있는 문제처럼 보였다. 그런데 직접 만들고 운영해보니 문장 하나로 접히지 않는 갈등이 남았다. 전송은 단순히 빨리 보내는 문제가 아니었다.

PonsWarpWebRTC대용량파일전송개발회고Cloud DropR2Operations

2026년 6월 29일·PonsWarp Origin Story·3 min

[PonsWarp] Direct와 Cloud Drop을 나눈 이유

처음에는 클라우드로 보낸다면 동작이 하나일 거라고 생각했다. 파일을 집어서 올리면 끝. 직접 전송이 어려울 때 쓰는 보조 레일 정도로 보였다. 실제로는 폴더인지 파일인지, 구조를 보존하는지, 이름 충돌을 어떻게 처리하는지, 실패 시 부분 결과를 남기는지에 따라 완전히 다른 제품이 된다. 모드를 안 가르면 사용자는 끝까지 올라갔나를 확신하지 못한다.

PonsWarpWebRTC대용량파일전송개발회고Cloud DropProduct Design

2026년 6월 29일·PonsWarp Origin Story·4 min

[PonsWarp] TB급 전송을 꿈꾸자 데이터 그리드가 필요해졌다

처음에는 PonsLink 안에 있는 파일 전송 기능이었다. 방 안에서 파일을 보내면 충분할 줄 알았는데, 파일 크기가 커질수록 회의방의 리듬까지 흔들렸다. 파일 전송은 처음엔 방 안의 작은 부가기능처럼 보였다. 그런데 파일이 커질수록 이 기능은 방 전체를 흔드는 별도 제품이 됐다. 전송은 단순히 빨리 보내는 문제가 아니었다. 브라우저 메모리, 수신 속도, 저장 방식, ACK, 백프레셔가 한꺼번에 걸렸다.

PonsWarpProduct RetrospectiveData GridLarge FileArchitecture

2026년 6월 29일·PonsWarp Origin Story·6 min

[PonsWarp] 브라우저끼리 대용량 파일을 직접 보내고 싶었다

정성적으로는 사용자가 '거의 다 됐는데 왜 깨졌지'라는 불신을 덜 느끼게 하는 게 목표였다. 다음 글에서는 OPFS, ZIP64, 메모리 경계 중 실제 저장 안정화 질문을 넘어간다. 특히 PonsWarp에서는 재현 조건을 같이 적어야 의미가 있었다. 전송 프로토콜이 같아도 마지막 저장 UX는 브라우저마다 다르고, 그 차이가 “전송 성공” 판단을 흔들었다는 문제가 있었다. 브라우저끼리 대용량 파일 특히 PonsWarp에서는 재현 조건을 같이 적어야 의미가 있었다.

PonsWarpWebRTC대용량파일전송개발회고P2PProduct

2026년 6월 29일·PonsWarp Origin Story·9 min

[PonsWarp] 파일 전송은 PonsLink 안에서 먼저 고장났다

파일 전송을 처음부터 별도 제품으로 생각한 건 아니었다. PonsLink 방에 사람이 붙어 있으니, 파일 하나 보내는 버튼 정도는 자연스러워 보였다. 붙여 보니 먼저 무너진 것은 버튼 위치가 아니라 **약속의 크기**였다. 사용자는 “파일 전송” 한 줄로 이해하지만, 제품은 연결·진행률·메모리·저장 완료·실패 후 재시도를 모두 설명해야 했다.

PonsWarpPonsLinkProduct RetrospectiveFile Transfer