[PonsWarp] 데스크탑 앱까지 갔지만, 테스트할 기기가 없었다

같은 입력인데 어떤 환경에서만 PonsWarp가 도드라졌다.

데스크탑까지 갔지만 테스트가 막힌 지점

처음 기대와 실제 제약을 한 번 충돌시킨 뒤 선택 이유가 드러났다. 데스크탑 앱까지 갔지만, 그래서 요청 흐름은 PonsLink가 회의 도구보다 연결 설계에 가까워진 이유를 보여준다. 정성적으로는 사용자가 '거의 다 됐는데 왜 깨졌지'라는 불신을 덜 느끼게 하는 게 목표였다.

처음에는 앱만 만들면 될 줄 알았다

전송은 단순히 빨리 보내는 문제가 아니었다. 브라우저 메모리, 수신 속도, 저장 방식, ACK, 백프레셔가 한꺼번에 걸렸다. 특히 큰 파일에서는 마지막 몇 퍼센트에서 실패하는 순간이 제일 잔인했다. 요청을 먼저 받는 일은 사람을 거르는 장치가 아니었다. 서로의 시간을 덜 낭비하게 만드는 완충지대였다.

그래서 PonsWarp는 별도 제품처럼 분리됐다. 서버가 파일을 들고 있지 않는다는 원칙을 유지하면서도 브라우저가 버틸 수 있는 흐름 제어와 저장 전략을 먼저 세워야 했다. 다음에 남는 질문은 한 문장으로 충분하다.

방 안에서 파일을 보내면 충분할 줄 알았는데, 파일 크기가 커질수록 회의방의 리듬까지 흔들렸다. 회의는 방에 들어온 뒤 시작되는 줄 알았다. 하지만 실제로는 그보다 훨씬 앞에서 시작됐다. 누가, 왜, 언제 만나고 싶은지 모르면 좋은 방도 금방 비어 보였다.

기기 부족이 선명해진 순간

이 흐름은 PonsLink 안에서 고장난 파일 전송이 어떻게 PonsWarp로 분리됐는지 따라간다. 처음 기대와 실제 제약을 한 번 충돌시킨 뒤 선택 이유가 드러났다. 특히 PonsWarp에서는 재현 조건을 같이 적어야 의미가 있었다.

정성적으로는 사용자가 '거의 다 됐는데 왜 깨졌지'라는 불신을 덜 느끼게 하는 게 목표였다. 전송은 단순히 빨리 보내는 문제가 아니었다. 브라우저 메모리, 수신 속도, 저장 방식, ACK, 백프레셔가 한꺼번에 걸렸다. 특히 큰 파일에서는 마지막 몇 퍼센트에서 실패하는 순간이 제일 잔인했다. 요청을 먼저 받는 일은 사람을 거르는 장치가 아니었다.

서로의 시간을 덜 낭비하게 만드는 완충지대였다. PonsWarp를 설명할 때 서버/클라이언트/사용자 중 누구 문장으로 말하는지 먼저 고르면 논쟁이 줄었다.

테스트 경계 나누기

브라우저 메모리, 수신 속도, 저장 방식, ACK, 백프레셔가 한꺼번에 걸렸다. 특히 큰 파일에서는 마지막 몇 퍼센트에서 실패하는 순간이 제일 잔인했다. 요청을 먼저 받는 일은 사람을 거르는 장치가 아니었다. 서로의 시간을 덜 낭비하게 만드는 완충지대였다.

그래서 PonsWarp는 별도 제품처럼 분리됐다. 서버가 파일을 들고 있지 않는다는 원칙을 유지하면서도 브라우저가 버틸 수 있는 흐름 제어와 저장 전략을 먼저 세워야 했다. 다음에 남는 질문은 한 문장으로 충분하다. 처음에는 PonsLink 안에 있는 파일 전송 기능이었다. 방 안에서 파일을 보내면 충분할 줄 알았는데, 파일 크기가 커질수록 회의방의 리듬까지 흔들렸다.

회의는 방에 들어온 뒤 시작되는 줄 알았다. 하지만 실제로는 그보다 훨씬 앞에서 시작됐다. 누가, 왜, 언제 만나고 싶은지 모르면 좋은 방도 금방 비어 보였다. 특히 PonsWarp에서는 재현 조건을 같이 적어야 의미가 있었다. 이 흐름은 PonsLink 안에서 고장난 파일 전송이 어떻게 PonsWarp로 분리됐는지 따라간다.

회고에서 고정한 원칙

처음 기대와 실제 제약을 한 번 충돌시킨 뒤 선택 이유가 드러났다. 그래서 요청 흐름은 PonsLink가 회의 도구보다 연결 설계에 가까워진 이유를 보여준다. 데스크탑 앱까지 갔지만, 정성적으로는 사용자가 '거의 다 됐는데 왜 깨졌지'라는 불신을 덜 느끼게 하는 게 목표였다.

마치며

이 글에서 확인한 경계는 다음 변경의 기준으로 남겼다.