[PonsWarp] - LAN 최적화는 왜 따로 필요했나

PonsWarp가 이미 Push 방식, AIMD, backpressure, RTT 기반 적응형 제어까지 붙였다면 한 가지 질문이 남습니다.

그런데 왜 LAN 최적화가 따로 필요했을까요. 네트워크가 빠르면 기존 튜닝이 알아서 더 크게 열리고, 느리면 줄이면 되는 것처럼 보이기 때문입니다. 하지만 현재 코드에 남은 흔적은 다른 이야기를 합니다.

LAN에서는 긴 경로 혼잡보다 애플리케이션 대기, 브라우저 큐, 저장 압력이 더 빨리 제품 문제로 드러납니다.

💡 이 글의 핵심은 “LAN에서는 더 공격적으로 보내자”가 아닙니다. 빠른 로컬망에서는 네트워크 병목보다 애플리케이션 대기, 브라우저 큐, 저장 압력이 더 빨리 드러나므로 별도 경로의 튜닝 언어가 필요했다는 점입니다.

⚡ 일반 전송 튜닝만으로는 설명되지 않는 구간

post-10에서 본 Push와 AIMD는 필요한 전환이었습니다. sender가 요청을 기다리기만 하면 빠른 링크가 굶고, 반대로 무작정 밀면 DataChannel buffer와 receiver 저장 큐가 부풉니다. post-17의 RTT 기반 적응형 제어도 같은 문제를 더 정교하게 봅니다.

이 접근은 인터넷 경로에서는 자연스럽습니다. RTT가 커지고, TURN 경유 가능성이 있고, 중간 경로가 붐비면 지연 기반 혼잡 제어가 의미를 갖습니다. 실제 networkAdaptiveController.ts도 currentRoundTripTime, availableOutgoingBitrate, bufferedAmount를 보고 cwnd를 조절합니다.

문제는 LAN입니다. 같은 공유기, localhost, 매우 짧은 RTT에서는 “네트워크가 막혀서 느리다”보다 “애플리케이션이 다음 청크를 제때 안 넣어서 빈다”가 더 잘 보입니다. RTT 기반 제어가 틀렸다는 뜻은 아닙니다. 다만 LAN에서는 그 제어만으로 제품 기대를 충족시키기 어렵습니다.

📐 로컬망에서는 가정이 바뀌었습니다

현재 constants.ts의 LAN 관련 주석은 짧지만 결정적입니다. SEND_WINDOW_POLL_INTERVAL_MS는 5ms, PARTITION_ACK_POLL_INTERVAL_MS는 10ms입니다. 주석은 25~50ms가 localhost와 빠른 LAN에서 DataChannel을 자주 굶기므로 짧은 fallback tick과 drain/ACK wake-up을 병행한다고 설명합니다.

이 말은 PonsWarp가 빠른 로컬망을 특별한 케이스로 봤다는 뜻입니다. 인터넷 경로에서는 25ms 대기가 큰 문제가 아닐 수 있습니다. 하지만 LAN에서는 그 시간이 여러 번 겹치면 링크가 놀고, 사용자는 속도 표시가 제대로 올라가지 않는다고 느낍니다.

LAN 최적화의 방향은 “대기 시간을 줄이되 queue 상한은 보수적으로 유지한다”에 가까웠습니다.

현재 상수는 큰 pipeline보다 bounded queue, 단일-flight batch, 짧은 poll tick, drain/ACK wake-up을 선택합니다.

🧩 chunk와 batch는 더 커지지 않았습니다

LAN이라고 하면 먼저 chunk 크기를 키우고 batch를 늘리고 싶어집니다. 하지만 현재 근거는 반대입니다. CHUNK_SIZE_INITIAL과 CHUNK_SIZE_MAX는 모두 192KB로 고정되어 있고, 주석은 일반적인 256KB SCTP message limit 아래에 두려는 의도를 드러냅니다. BATCH_SIZE_MAX도 1입니다. PREFETCH_BUFFER_SIZE는 0입니다.

이건 성능을 포기했다는 뜻이 아닙니다. PonsWarp가 한 번 배운 것은 sender 쪽 큐가 비었다고 receiver 저장이 끝난 것은 아니라는 사실입니다. 큰 batch와 prefetch는 빠른 LAN에서 순간 속도 숫자를 올릴 수 있지만, receiver writer가 밀리면 결국 진행률 정지, GC 압박, 저장 지연으로 돌아옵니다.

file-sender.worker.ts도 이 보수성을 그대로 받습니다. worker는 update-adaptive-config로 받은 chunkSize와 prefetchBatch를 상수 범위 안에서만 반영합니다. LAN의 병목을 줄이려는 시도는 chunk와 batch를 무한히 키우는 방식이 아니라, 작은 단위가 끊기지 않게 돌도록 만드는 방식이었습니다.

🔄 channel과 buffering의 기대도 달라졌습니다

시리즈 계획에는 Season 2의 성능 전쟁 안에 multi-channel strategy, pipeline parallelism, backpressure, RTT adaptive control이 함께 놓여 있습니다. 현재 코드에서도 reorderingBuffer.ts 주석은 multi-channel 전송이나 jitter 상황에서 out-of-order packet이 파일 손상을 만들 수 있다고 말합니다.

LAN은 이 고민을 더 날카롭게 만듭니다. 빠른 링크에서는 channel을 더 열고 buffer를 더 채우면 좋아 보입니다. 하지만 PonsWarp의 현재 상수는 그 길을 조심합니다. DataChannel의 bufferedAmount는 sender 로컬 큐일 뿐 receiver 저장 완료를 의미하지 않는다고 못 박고, queue를 4MB에 묶고, partition 단위로 보낸 뒤 receiver writer queue가 idle될 때까지 기다리는 전략을 둡니다.

빠른 로컬망일수록 사용자는 네트워크보다 제품 구현을 의심하므로, 속도와 정직한 완료 조건을 함께 지켜야 합니다.

🧠 제품 기대는 네트워크 종류에 따라 달라집니다

인터넷 전송에서 사용자는 어느 정도 변동을 받아들입니다. 모바일 네트워크, NAT, TURN, 해외 경로 같은 변수가 눈에 보이지 않아도 “네트워크가 불안정한가 보다”라고 해석할 여지가 있습니다. 반대로 LAN에서는 그 여지가 줄어듭니다. 같은 방, 같은 공유기, 같은 사무실에서 느리면 사용자는 제품 구현을 봅니다.

그래서 LAN 최적화는 숫자 싸움이면서 동시에 신뢰 싸움입니다. 속도 표시가 빠르게 올라가는 것만으로는 부족합니다. 멈춘 것처럼 보이지 않아야 하고, receiver 저장 압력이 올라오면 정직하게 늦춰야 하며, 완료는 여전히 save-complete 조건을 지켜야 합니다.

PonsWarp가 보수적인 queue, 단일-flight batch, 16MB partition, 짧은 poll tick을 함께 둔 것은 이 제품 감각과 맞닿아 있습니다. LAN에서는 전송 엔진의 작은 빈틈이 더 선명하게 보입니다.

📚 읽은 코드
PonsWarp/src/utils/constants.ts:15-47 — 192KB chunk 고정, 4MB bounded DataChannel queue, 16MB partition, LAN/localhost poll 지연 주석, batch/prefetch 보수화
PonsWarp/src/services/networkAdaptiveController.ts:38-152 — RTT, bufferedAmount, cwnd 기반 적응형 제어와 batch 계산
PonsWarp/src/services/swarmManager.ts:733-817 — drain 이벤트, WebRTC stats 샘플링, worker adaptive config 갱신
PonsWarp/src/workers/file-sender.worker.ts:138-146,251-267,563-625 — worker의 adaptive config, prefetch batch, chunk 생성 경로
PonsWarp/src/services/reorderingBuffer.ts:6-10 — multi-channel 또는 jitter 상황에서 out-of-order packet을 파일 손상 위험으로 보는 주석
content/ponswarp-retrospective/series-plan.md:196-207,261-270 — Season 2의 성능/무결성 흐름과 post-18 위치