타이밍

느리다는 건 알고 만들었다. 그런데 어디가 느린지는 재기 전엔 몰랐다.

구간을 갈라 재봤다

구간	시간	비중
보낸 쪽 → 받는 쪽 (전파 + 폴링 대기)	46초	24%
실제로 일하는 시간	27초	14%
받는 쪽 → 보낸 쪽 (전파)	118초	62%
왕복	191초

두 번째 왕복은 133초였다. 2~3분으로 보는 게 맞다.

병목이 내 코드가 아니었다

일하는 시간은 14%뿐이다. 나머지는 전부 파일이 건너가는 시간이고, 그중에서도 돌아오는 편도가 62%를 먹는다.

여기서 나오는 결론이 이 문서의 전부다. 폴링 주기를 줄여도 이건 초 단위가 안 된다.

폴링을 1분에서 10초로 줄이면 어떻게 되나 계산해 보면 답이 나온다. 첫 구간 46초에서 폴링 대기가 빠지니 20~30초쯤 줄고, 전체는 191초에서 160초대가 된다. 코드를 여섯 배 부지런하게 만들어서 15% 얻는 것이다.

62%를 먹는 복귀 전파는 내가 손댈 수 있는 부분이 아니다. 동기화 도구가 파일 변경을 감지하고 상대에게 밀어 넣는 시간이고, 그건 도구 설정과 네트워크가 정한다.

그래서 튜닝이 아니라 선택의 문제다

초가 필요하면 이 채널을 쓰면 안 된다. 그건 튜닝으로 풀 문제가 아니라 채널을 잘못 고른 문제다.

이 결론이 중요한 이유는, 재보기 전에는 정확히 반대로 생각하고 있었기 때문이다. “폴링이 1분이니까 그게 느린 원인이겠지”가 자연스러운 추측이고, 그 추측대로 폴링을 줄이는 작업을 했으면 효과 없는 최적화에 시간을 쓰고 나서 여전히 3분인 걸 보고 당황했을 것이다.

구간 분해가 값을 하는 자리가 이런 데다. 전체 숫자만 보면 “느리다”까지밖에 안 나오고, 갈라 보면 “느린 이유가 내 밖에 있다”까지 나온다.

대신 얻은 것

느린 대신 이 채널이 가진 게 하나 있다. 상대가 자고 있어도 도착한다.

동기화 폴더에 파일이 놓이면 상대 기계가 깨어날 때 그게 건너가고, 감시자가 그걸 집는다. 채팅앱은 상대가 안 켜져 있으면 그냥 쌓이기만 하는데, 이쪽은 깨어나는 순간 자동으로 진행된다.

3분을 내주고 그걸 산 셈이다. 그리고 그게 이 도구를 만든 이유 전부다.