# 타이밍
> 3분이 어디로 가는지 구간을 갈라 재봤습니다. 일하는 시간은 14%였습니다.
- 수치: 14%
- 사람이 보는 화면: https://aitryed.com/ko/built/claude-bus/timing/
- 반대 언어: https://aitryed.com/en/built/claude-bus/timing/index.md
- 이 사이트 안내(AI용): https://aitryed.com/ko/llms.txt
---
**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분을 내주고 그걸 산 셈이다. 그리고 그게 [이 도구를 만든 이유](/ko/built/claude-bus/index.md) 전부다.