[PonsLink] 파일 전송은 결국 방 밖으로 독립해야 했다

파일 전송은 결국 방 밖으로 독립해야 했다. 처음에는 방 안에 두는 게 자연스러워 보였다. 사람이 붙어 있는데 파일 하나쯤 같이 보내면 될 줄 알았다.

그 기준을 들이밀자 방 안 파일 전송은 금방 한계에 부딪혔다.

불편이 실패로 커진 지점

방 UI 안의 파일 전송은 금방 이런 질문에 부딪혔다. 지금 업로드 중인가 peer 전송 중인가, 브라우저를 닫으면 이어받을 수 있는가, 상대가 새로고침하면 진행률은 어디로 가나.

작은 첨부면 모르지만, 자료 묶음·영상 샘플·로그 압축본이 들어오면 "가벼운 공유" 가정은 깨진다. 방 제품이 미완성 전송 클라이언트처럼 보이기 시작했다. 사용자는 회의 중 파일이 멈추면 회의 제품 전체를 불안해했다.

처음에는 부가 기능으로 두면 되겠다 생각했다

그럴듯해 보였던 첫 설계는 "방 패널에 파일 탭 하나"였다. 채팅과 같은 줄에 두면 사용자도 편할 거라 봤다.

그런데 전송은 채팅과 다른 실패 모드를 가진다. 중간 조각 유실이면 전체 실패고, 저장 단계 실패는 보내는 쪽과 받는 쪽이 다른 시점에 멈춘다. 로그가 말해 준 반례는 "연결은 살아 있는데 전송만 죽은" 경우였다. 같은 data channel에 태우면 구현은 짧아지지만, 한쪽 백프레셔가 다른 쪽 체감을 망친다.

독립 필요가 선명해진 순간

다시 그은 경계는 이랐다.

구성요소	책임	갖지 말아야 할 것
회의 방	실시간 협업	대용량 전송 상세
PonsWarp	전송 경로·완료 설명	회의 presence
공통 signaling	매칭·재연결	파일 바이트 보관

메커니즘이 버틴 이유는 간단하다. 전송 상태를 화면 중앙에 둘 권리, 브라우저별 저장 차이를 숨기지 않을 권리, 완료를 수신 확인으로 고정할 권리가 생겼기 때문이다. 방 제품은 회의 얼굴만 지키면 된다.

파일 전송 경계 나누기

• 대용량 전송은 회의 부가 기능으로 두지 않는다
• 완료는 송신 종료가 아니라 수신 저장 확인 후
• 브라우저 제약을 숨기지 않는다
• 실패 문장은 연결/전송/저장을 구분해 쓴다

결론보다 그 과정을 먼저 보여주는 쪽이 신뢰에 가깝다.

마치며

파일 전송을 방 밖으로 빼낸 건 기능 정리 이상이다. 회의 제품의 얼굴이 전송 장애로 오염되는 걸 막는 최소 조치였다.

지금은 이렇게 본다. 같은 화면에 두고 싶은 유혹이 올 때마다, 그 기능이 실패했을 때 회의 제품의 얼굴을 얼마나 더럽히는지 먼저 계산한다. 그 계산이 분리 여부보다 먼저다. 다음에 비슷한 유혹이 오면, 부가 기능의 실패가 주 제품의 신뢰를 깎는 속도를 먼저 측정하겠다.