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

결국 만든 것은 파일 전송 버튼이 아니라 실패를 견디는 흐름이었다. 처음에는 PonsLink 방 안에서 파일을 보내면 충분할 줄 알았다. 파일이 커지자 전송은 방의 부가기능이 아니라 별도 제품처럼 행동했다.

브라우저 메모리, 수신 속도, 저장 방식, ACK, 백프레셔가 한꺼번에 얽혔다. 보내는 일과 받는 일과 저장하는 일이 같은 속도로 진행되지 않으면 사용자는 전체 전송이 실패했다고 느꼈다.

마지막 몇 퍼센트가 만든 차이

작은 파일은 정상 경로만 봐도 된다. 큰 파일은 끝에 가까워질수록 실패 비용이 커진다. 저장 공간이 부족하거나 수신자가 잠시 멈추면 이미 보낸 데이터와 아직 저장하지 못한 데이터의 경계를 설명해야 한다.

전송률만 보여 주면 사용자는 멈춘 이유를 알 수 없다. 어느 조각까지 확인됐고, 다시 시도할 수 있는지, 포기해야 하는지를 상태로 남겨야 했다.

서버 없는 흐름의 조건

PonsWarp는 서버가 파일을 들고 있지 않는다는 원칙을 유지했다. 대신 브라우저끼리 주고받는 조각의 확인과 저장을 더 엄격하게 관리해야 했다.

이 선택은 서버 비용을 없애는 대신 클라이언트의 책임을 늘린다. 메모리 압박과 중단, 재연결과 재시도를 제품 안에서 설명해야 한다. 서버에 다시 올리면 쉬운 문제도, 이 구조에서는 흐름 제어의 문제로 돌아온다.

실패를 정상 경로로 놓기

전송 실패를 예외 화면 하나로 밀어내지 않았다. 확인된 조각과 대기 중인 조각을 나누고, 수신 속도가 떨어지면 보내는 쪽도 멈추게 했다. 사용자가 다시 시도할 때 처음부터 모든 파일을 보내지 않는 것도 이 흐름의 일부다.

이 구조에서는 빠른 성공보다 설명 가능한 중단이 중요하다. 무엇이 보존됐는지 알 수 있어야 다음 작업자가 복구할 수 있고, 사용자가 파일을 다시 선택할지 기다릴지 결정할 수 있다.

마치며

PonsWarp의 핵심은 전송 버튼의 성공률을 꾸미는 일이 아니다. 큰 파일과 느린 수신자와 끊긴 연결을 정상적인 조건으로 놓고도 흐름을 이어 가는 일이다. 실패를 숨기지 않고 상태로 만들었을 때 전송이 제품이 됐다.