<PonsLink/>
작업
글
주제
시리즈
카테고리
연락
⌘K 검색
About
코드와 제품으로

코드와 제품으로

연결되는 세계

연결되는 세계

PonsLink는 만남 뒤 요청을 세션으로 잇고, PonsWarp는 서버 보관 없이 파일을 직접 전송합니다. 이 블로그는 기능 소개보다 설계 판단과 운영 증거를 남깁니다.

연락처

[email protected]github.com/DeclanJeon

운영

콘텐츠는 WordPress headless CMS, 공개 UI는 Next.js입니다.

초안 미리보기
© 2026 PonsLink Blog|Next.js · WordPress REST · Framer Motion
Local-first · Backup-before-deploy

Writing

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

주제
프로젝트
글 유형
6개의 글
[PonsWarp] Signaling 서버는 파일 운반자가 아니라 소개자였다
2026년 6월 29일·PonsWarp Transfer Engine·5 min

[PonsWarp] Signaling 서버는 파일 운반자가 아니라 소개자였다

처음에는 PonsLink 안에 있는 파일 전송 기능이었다. 방 안에서 파일을 보내면 충분할 줄 알았는데, 파일 크기가 커질수록 회의방의 리듬까지 흔들렸다. 브라우저끼리 직접 붙이면 서버 부담이 줄고 구조도 단순해질 줄 알았다. 그런데 WebRTC는 연결의 문만 열어줬고, 질서는 제품이 직접 만들어야 했다.

PonsWarpMain ServicesSignalingWebRTCRust
[PonsWarp] Zero-Copy Pool은 빠른 전송보다 GC를 피하기 위한 선택이었다
2026년 6월 29일·PonsWarp Transfer Engine·2 min

[PonsWarp] Zero-Copy Pool은 빠른 전송보다 GC를 피하기 위한 선택이었다

Zero-Copy Pool을 고른 이유는 전송 속도를 더 내고 싶어서가 아니었다. 브라우저에서 큰 파일을 다룰 때 복사와 가비지 컬렉션이 전송의 마지막 구간을 망가뜨리는 일이 무서워졌기 때문이다. 처음에는 PonsLink 방 안에서 파일을 보내면 충분할 줄 알았다. 파일 크기가 커지면서 회의방의 리듬까지 흔들렸다. 파일을 보내는 일과 대화하는 일이 같은 메모리 압박을 공유하고 있었다.

PonsWarpWebRTCFile TransferRetrospective
[PonsWarp] 속도를 올리기 전에 파이프라인의 한계를 먼저 정했다
2026년 6월 29일·PonsWarp Transfer Engine·4 min

[PonsWarp] 속도를 올리기 전에 파이프라인의 한계를 먼저 정했다

아래에서는 PonsWarp을 중심으로, 깨진 가정과 다시 그은 경계를 순서대로 남긴다. 처음 기대와 실제 제약을 한 번 충돌시킨 뒤 선택 이유가 드러났다. 이 흐름은 브라우저끼리 파일을 직접 보내면서 부딪힌 전송 엔진의 벽을 따라간다. 속도를 올리기 전에 파이 처음에는 PonsLink 안에 있는 파일 전송 기능이었다. 방 안에서 파일을 보내면 충분할 줄 알았는데, 파일 크기가 커질수록 회의방의 리듬까지 흔들렸다. 처음에는 쉽게 정리할 수 있는 문제처럼 보였다. 그런데 직접 만들고 운영해보니 문장 하나로 접히지 않는 갈등이 남았다.…

PonsWarpWebRTCFile TransferRetrospective
[PonsWarp] ACK 하나 때문에 전송이 멈추고 살아났다
2026년 6월 29일·PonsWarp Transfer Engine·6 min

[PonsWarp] ACK 하나 때문에 전송이 멈추고 살아났다

전송이 빠른데도 수신 쪽이 밀리면서 멈추는 장면이 있었다. 처음에는 더 빠르게 보내면 해결될 것 같았다. 실제로는 속도를 올릴수록 브라우저 버퍼가 먼저 한계에 닿았다. 큰 파일에서 마지막 몇 퍼센트가 깨지는 이유도 그곳에 있었다. ACK는 받았다는 표시만이 아니었다. 수신자가 다음 조각을 받을 준비가 됐다는 신호로 사용해야 했다. 보내는 쪽이 자기 속도만 믿고 계속 밀어 넣으면 전송은 빨라 보이지만 실제로는 더 빨리 깨진다.

PonsWarpProduct RetrospectiveACKBackpressureWebRTC
[PonsWarp] 백프레셔는 기다림이 아니라 보호 장치였다
2026년 6월 29일·PonsWarp Transfer Engine·10 min

[PonsWarp] 백프레셔는 기다림이 아니라 보호 장치였다

빠르게 보내는 것보다 채널이 받아줄 수 있는 만큼만 보내는 일이 안정적인 전송을 만들었다. 백프레셔를 제품 기준으로 삼은 이유를 적었다.

PonsWarpWebRTC대용량파일전송개발회고BackpressureFlow Control
[PonsWarp] WebRTC는 파일을 보내주지 않는다, 길만 열어준다
2026년 6월 29일·PonsWarp Transfer Engine·12 min

[PonsWarp] WebRTC는 파일을 보내주지 않는다, 길만 열어준다

WebRTC를 처음 붙잡을 때는 약간의 낙관브라우저끼리 직접 연결되고, data channel이 열리고, 그 위로 바이트를 보내면 파일 전송의 큰 문제가 해결될 것 같았다. 서버에 파일을 올리지 않아도 되고, 두 사람이 바 는 점이 매력적이었다. 그런데 PonsWarp를 정리하면서 더 분명해진 건 WebRTC가 파일을 보내주는 기술이 아니라 길을 열어주는 기술이라는 점이었다. 아래에서는 PonsWarp을 중심으로, 깨진 가정과 다시 그은 경계를 순서대로 남긴다.

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