SERIESPonsWarp 운영 노트

[PonsWarp] 전송 성공률을 시작 횟수로 세면 안 되는 이유

Jul 28, 2026·3 min read·110 views

PonsWarp성공률지표운영전송

택배 기사에게 “출발한 횟수”를 물어보고 그걸 배송 성공률이라고 부르면 이상하다. 그런데 전송 제품 대시보드에서는 그런 실수를 하기 쉽다.

초기에 나도 성공률을 아주 단순하게 잡고 싶었다. 보내기 누른 횟수 대비 완료 횟수. 카드 하나에 들어가는 예쁜 숫자. 문제는 완료가 사람마다 다른 순간이라는 점이었다.

이 네 가지는 같은 사건이 아니다.

우리는 사건을 단계로 나눈다

연결 제품에서는 이미 이렇게 센다. 방에 들어옴, 연결됨, 연결 실패. 시작과 성공을 한 줄로 뭉개지 않는다. 파일 전송도 같아야 했다.

현장에서 쓰는 단계는 대략 이렇다.

성공률 하나를 꼭 써야 한다면 기본은 이것이다.

검증 완료 ÷ 시도

연결만 되고 파일이 비는 경우를 성공으로 세면, 제품은 바빠 보이고 사용자는 파일을 못 받는다.

실제 시험표를 보면 더 분명하다. 같은 50MB여도 어떤 빌드는 끝까지 갔고, 어떤 시도는 높은 피크 뒤에 암호화 키 오류로 멈췄다. 피크만 보면 실패 런도 “거의 성공”처럼 보인다.

또 다른 함정은 재시도다. 같은 파일을 세 번 보내 한 번 성공하면, 시작 기준으로는 분주해 보이지만 사용자 과업 기준으로는 성공률이 낮다. 사람의 할 일 1개를 기준으로 읽어야 한다.

경로를 섞는 것도 위험하다. 집 안 직접 연결과 우회 연결(relay)은 성공 확률과 비용이 다르다. 둘을 한 평균으로 섞으면, 무엇을 고쳐야 할지 안 보인다.

“지금 전송 중” 숫자를 성공률 옆에 두고 싶을 때가 있다. 많아 보이면 제품이 살아있는 느낌이다. 하지만 전송 중은 성공이 아니다. 길게 남는 전송 중은 저장 대기, 우회 경로 정체, 사용자가 창을 닫은 상태일 수 있다.

그래서 이렇게 나눈다.

속도 시험 숫자도 성공률을 대체하지 않는다. 같은 컴퓨터 안 시험과 집 Wi-Fi 실기 시험은 레이스가 다르다. 둘 다 참고 샘플이지, “우리 사용자 전체 성공률”이 아니다.

“성공률 99%” 같은 문장은 분모를 밝히기 전에는 쓰지 않는다. 대신 내부에서는 이런 문장이 유용하다.

없는 숫자(라이브 전체 사용자 성공률 등)는 비워 둔다. 비워 두는 것도 운영 품질이다.

성공률은 자랑 문구가 아니라, 실패를 종류별로 보이게 만드는 렌즈여야 한다. 출발을 도착으로 세면 제품은 분주하고 사용자는 허탕 친다. 파일이 닫히고 내용까지 맞는 순간을 분자에 두는 순간, 복구·열쇠·저장 문제가 같은 점수판 위에 올라온다.