[PonsWarp] Direct와 Cloud Drop을 나눈 이유

처음에는 클라우드로 보낸다면 동작이 하나일 거라고 생각했다. 파일을 집어서 올리면 끝. 직접 전송이 어려울 때 쓰는 보조 레일 정도로 보였다.

실제로는 폴더인지 파일인지, 구조를 보존하는지, 이름 충돌을 어떻게 처리하는지, 실패 시 부분 결과를 남기는지에 따라 완전히 다른 제품이 된다. 모드를 안 가르면 사용자는 끝까지 올라갔나를 확신하지 못한다.

올라갔는지 알 수 없는 구간

로컬 전송은 도착의 감각이 비교적 분명하다. 파일이 내 기기 경로에 생기면 끝이다. 클라우드 전달은 다르다. 부분 업로드, 폴더 펼침, 이름 충돌, 권한 오류가 한 화면에 섞인다.

진행률이 움직이는데 목록에 파일이 없으면 사용자는 제품이 멈춘 것으로 본다. 기술적으로는 업로드 중일 수 있어도 체감은 실패다.

도착 정의가 모호하면 완료 배지는 위험해진다. 배지가 거짓말을 하는 순간 제품의 다른 완료 배지도 의심받는다.

그래서 클라우드 경로에서는 완료 문장을 더 보수적으로 써야 한다. 보수적인 완료가 빠른 완료보다 안전하다.

한 모드로 충분할 줄 알았던 이유

초기에는 업로드 창구 하나로 충분해 보였다. 단일 파일 테스트는 잘 통과했다. 폴더 통째 전달이 들어오면서 균열이 났다.

하위 구조를 펼칠지 평평하게 올릴지, 빈 폴더를 만들지, 숨김 파일을 포함할지. 전부 기본값 싸움이었다.

용량은 줄었는데 파일이 없다는 반례가 결정타였다. 부분 실패를 성공으로 집계한 구조였다.

바이트 전송량과 사용자 완료 사건이 다르면 개선 방향도 엇갈린다. 팀은 속도만 보고 사용자는 존재 여부를 본다.

직접 전송과 클라우드 전달을 나눈 축

둘을 나눈 이유는 전송 매체가 달라서가 아니라 책임 경계가 달라서다. 직접 전송은 브라우저 간 전달이고 서버는 소개와 제어에 가깝다. 클라우드 전달은 저장 객체가 도착지다.

같은 보내기 버튼 뒤에 숨기면 실패 문장과 복구 전략이 뒤섞인다. 사용자는 한 버튼을 눌렀을 뿐인데 시스템은 다른 세계를 탄다.

내부 상태 기계에서는 반드시 분리한다. 외부 노출은 필요할 때만 한다. 다만 완료 문장은 경로별로 달라야 한다.

전환 조건도 정책으로 적는다. 직접 전송 실패 시 클라우드로 넘길지, 넘긴다면 무엇을 유지한 채 넘길지 정해야 한다.

도착의 정의를 모드마다 고정하기

다시 그은 경계는 전달 모드를 명시적으로 가른 것이다. 파일, 폴더, 병합 정책이 서로 다른 완료 정의를 가진다.

| 모드 | 동작 | 완료 정의 | 실패 시 | | --- | --- | --- | | 파일 | 단일 파일 | 객체 생성과 검증 | 부분 조각 폐기 | | 폴더 | 구조 보존 | 트리 반영 완료 | 실패 하위 경로 표시 | | 병합 | 충돌 정책 포함 | 충돌 목록 확정 | 자동 덮어쓰기 금지 |

같은 완료 배지를 붙이면 다시 혼란이 시작된다. 배지보다 문장이 중요하다.

권한 오류를 네트워크 오류와 섞지 않는다. 권한 문제를 재시도 루프에 넣으면 사용자는 무한 진행률만 본다.

마치며

직접 전송과 클라우드 전달을 나눈 이유는 기능을 늘리기 위해서가 아니다. 도착의 의미를 속이지 않기 위해서다.

지금은 모드 없는 완료 문장을 위험 신호로 본다. 다음에 클라우드 전달을 다시 만지면 모드 정의와 완료 검증을 먼저 적겠다.

그다음 버튼을 그려도 늦지 않다. 버튼이 먼저면 문장이 따라가지 못한다.

정직한 도착 정의가 있어야 보조 레일이 본선 신뢰를 갉아먹지 않는다.