타이밍

3분이 어디로 가는지 실제로 재 봤습니다. 제 코드가 쓰는 시간은 14%였습니다.

먼저 — 재 보기 전에는 몰랐습니다

「3분 걸린다」는 건 알고 있었습니다. 그런데 어디서 걸리는지는 몰랐습니다.

보통 이럴 때 자기 코드부터 의심합니다. 「내가 뭘 비효율적으로 짰나」 싶습니다. 그래서 재 봤습니다.

결과

어디	시간	비율
보낸 쪽 → 받는 쪽 (건너가기 + 확인 주기)	46초	24%
실제로 일한 시간	27초	14%
받는 쪽 → 보낸 쪽 (건너가기)	118초	62%
왕복 합계	191초

두 번째로 재 보니 133초였습니다. 2~3분으로 보는 게 맞습니다.

병목이 제 코드가 아니었습니다

일하는 시간은 14%뿐입니다. 나머지 86%는 전부 파일이 건너가는 시간입니다.

그리고 그중에서도 돌아오는 편도가 62%를 먹습니다.

가는 길은 46초인데 오는 길은 118초입니다. 같은 거리인데 두 배 넘게 걸립니다.

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

이게 재 본 것의 결론입니다.

제가 코드를 아무리 빨리 만들어도, 줄일 수 있는 최대치가 27초입니다. 전부 0으로 만들어도 여전히 164초입니다.

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

이게 재 보기 전에는 안 나오는 결론입니다. 안 재면 「좀 더 최적화해 보자」로 며칠을 씁니다. 그리고 며칠 써도 27초 안쪽에서만 움직입니다.

그리고 느린 대신 얻은 것

상대가 자고 있어도 도착합니다.

메신저는 빠른데 상대가 깨어 있어야 합니다. 이 버스는 느린데 감시자가 계속 보고 있어서 스스로 일어납니다.

그래서 이 둘은 경쟁 관계가 아닙니다. 쓰는 자리가 다릅니다.

필요한 것	어느 채널
지금 바로 주고받기	메신저
자고 있는 기계에 일 맡기기	이 버스

「3분이나 걸린다」가 단점처럼 보이는데, 비교 대상이 메신저가 아니라 「아침까지 아무 일도 안 일어남」이면 3분은 아주 빠릅니다.

여기부터는 자세한 기록입니다

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

구간을 갈라 재봤다

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

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

병목이 내 코드가 아니었다

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

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

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

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

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

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

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

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

대신 얻은 것

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

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

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