[PonsWarp] 전송 중 암호화 키가 사라지자 재개가 막혔다

쉬운 말로 먼저 말하면 이렇다. 짐을 절반쯤 옮기다가 문이 닫혔는데, 다시 문을 열 열쇠가 사라진 상태였다.

두 대의 크롬으로 집 Wi-Fi 전송 시험을 하던 날이었다. 20MB는 잘 끝났다. 50MB로 올리자 속도 그래프가 한동안 올라가다 멈췄다. 정점은 초당 약 3.85MB. 그다음 로그에 이런 문장이 남았다.

Cannot resume encrypted transfer without an active crypto key

느려서가 아니었다. “이어서 받기” 버튼은 있는데, 그 버튼을 눌러도 열 수 있는 열쇠(암호화 세션)가 없었던 장애다.

왜 처음엔 정상처럼 보였나

같은 날 20MB는 깨끗했다. 약 8초 만에 끝났고, 받는 쪽 파일도 완성됐다. 경로 표시도 집 안 직접 연결(host/LAN)이었다. 그래서 50MB도 “같은 방식으로 한 번 더”라고 생각했다.

초반도 비슷했다. 그래프가 올라갔다. 피크 숫자만 보면 예전에 찍었던 직접 연결 상한(대략 초당 3.7MB 근처)과 큰 차이가 없었다. 문제는 속도가 아니라 끊긴 뒤의 행동이었다.

전송이 흔들린 뒤 시스템은 “이어서 받기”로 들어가려 했다. 그런데 암호화 키가 이미 없어진 뒤였다. 연결 통로가 먼저 죽은 게 아니라, 통로를 다시 열 열쇠가 먼저 사라진 것에 가깝다.

한 줄로 분해하면

의심 순서는 단순했다.

1. 인터넷이 느린가? → 같은 Wi-Fi에서 피크는 나와서 우선순위가 낮아졌다.
2. 저장이 막혔나? → 받는 쪽이 잠시 멈출 수는 있어도, 로그 문장은 저장이 아니라 키를 가리켰다.
3. 이어받기 조건이 잘못된가? → 여기가 본론이었다.

우리는 무의식적으로 이렇게 생각했다. “몇 바이트까지 받았는지(offset)만 있으면 이어서 받는다.”

암호화 전송에서는 그게 반쪽이다. 어디까지 받았는지와 같은 열쇠로 열고 있는지가 같이 맞아야 한다. 열쇠가 바뀌었거나 사라졌는데 숫자만 이어 붙이면, 깨진 파일을 완성본처럼 만들 수 있다.

그래서 복구 규칙을 이렇게 바꿨다

복구의 정의를 바꿨다.

• 이전: 끊긴 지점 숫자로 다시 시작한다.
• 이후: 같은 전송 세대 + 살아 있는 암호화 세션일 때만 이어받기를 허용한다.

열쇠가 없으면 “이어받기 실패”가 정답이다. 어설프게 이어 붙여 완성처럼 보여주는 쪽이 더 위험하다.

현장에서 남긴 짧은 규칙도 같다.

1. 전송 시작할 때 열쇠와 전송 번호를 같이 기록한다.
2. 끊김이 나면 통로가 먼저 죽었는지, 열쇠가 먼저 죽었는지 순서를 남긴다.
3. 이어받기 전에 통과 검사(resumeGate)를 한다. 통과 못하면 쓰지 않는다.
4. 완료는 “보내기 성공”이 아니라 “받는 쪽 파일이 닫히고 내용 검증까지 끝난 상태”다.
5. 장애 메모에는 속도 숫자와 함께 멈춘 이유 문장을 남긴다. 숫자만 있으면 성공과 실패가 비슷해 보인다.

숫자로 보면 더 분명하다

같은 주 시험표에는 50MB를 끝까지 보낸 경우도 있다. 어떤 빌드는 약 18.6초, 평균 초당 2.69MB. 어떤 빌드는 피크가 더 높은데 평균은 더 낮았다. 피크가 높다고 더 잘 끝난 것은 아니다.

실패했던 50MB 시도의 피크(약 3.85MB/s)는 성공 런의 피크와 크게 다르지 않다. 그래서 대시보드에 최고 속도만 올려 두면, 장애가 성공 근처처럼 보인다.

지원 티켓 한 줄로 남기면 이렇다.

50MB 집 Wi-Fi 전송, 피크≈3.85MB/s 후 암호화 키 소실, 이어받기 거부, 완성 파일 없음.

이 한 줄이 있어야 다음 수정과 재현 테스트 이름이 생긴다.

마치며

처음엔 “Wi-Fi가 느린가?”로 시작했다. 끝에 남은 교훈은 더 단순했다. 이어받기 버튼은 열쇠가 있을 때만 의미가 있다. 그 조건을 숨기면 사용자는 이어서 받는다고 읽고, 제품은 아무 파일도 완성하지 못한 채 멈춘다.