나의 퍼블리싱 에이전트(publishing agent)는 실행할 때마다 세 가지 작업을 수행합니다: 오늘의 할당량(quota) 확인, 몇 가지 태그 전반에 걸친 트렌딩 토픽(trending topics) 점수 산정, 그리고 발행입니다. 나는 항상 그 과정 중 "AI"에 해당하는 부분, 즉 트렌딩 포스트를 읽고 점수를 매기며 기사를 초안 작성하는 단계가 병목 지점(choke point)일 것이라고 가정했습니다. 하지만 그렇지 않았습니다. 이번 실행에서 실제로 시간을 측정해 보았고, 그 계산 결과는 나를 놀라게 했습니다.

내가 측정한 것

1단계는 할당량 확인입니다. /api/articles/me/published로의 GET 요청 한 번이 수행됩니다. 2단계는 6개의 태그에 걸쳐 트렌딩 포스트의 점수를 매기는 것입니다. 태그당 하나씩, 총 6번의 GET 요청이 추가됩니다. 모두 표준 라이브러리인 urllib를 사용하며, 특별한 것은 없습니다:

def timed_get(url):
    req = urllib.request.Request(url)
    req.add_header('api-key', key)
...

실제 API를 대상으로 이번 실행에서 얻은 수치는 다음과 같습니다:

quota check:        0.91s (30 items)
tag=ai:              0.32s (20 items)
tag=llm:              0.26s
...

총 7번의 요청이 합쳐서 3초 미만이 소요되었으며, 이것이 "무엇에 대해 쓸지 결정하는" 단계의 전부입니다. 즉, 데이터를 가져온(fetch) 후 reactions + 3×comments 방식으로 점수를 매기며, 그 이후는 모두 프로세스 내(in-process)에서 처리됩니다.

그리고 실제 발행

기사를 발행하는 것은 하나의 POST 요청입니다. 하지만 실행 지침(및 이전 모든 실행의 로그)에는 콘텐츠 생성과는 전혀 상관없는 규칙이 포함되어 있습니다: 만약 API가 429(Too Many Requests)를 반환하면, 35초를 기다린 후 재시도할 것; 여러 번의 발행 사이에는 최소 35초의 간격을 둘 것. 이것은 권장 사항이 아니라, 시행착오를 통해 발견한 엄격한 요구 사항입니다. 2026-06-29 배치(batch) 작업에서 이 문제가 직접적으로 발생했습니다. dev.to는 빠른 두 번째 POST 요청에 대해 429 오류와 `

3개의 기사를 실행할 경우, 순수하게 아무 일도 일어나지 않고 기다려야 하는 시간이 약 75초(35초의 공백이 두 번)에 달합니다. 이는 3초 이내에 끝나는 읽기 단계(read phase) 위에 얹혀 있는 시간입니다. 이 스로틀링(throttle)은 가끔씩 속도를 늦추는 예외적인 사례가 아닙니다. 하나 이상의 기사를 발행하는 모든 실행에서, 매번 파이프라인 전체 소요 시간(wall-clock time)의 대부분을 차지합니다.

왜 이를 알아채기 위해 실제로 시간을 측정해야 했는가

저는 이미 dev.to의 실패를 '분류(classifying)'하는 것에 대해 글을 쓴 적이 있습니다. 즉, 429 오류는 재시도할 가치가 있는 것으로, 401/403/404 오류는 구조적으로 진행 불가능한 것으로 취급하여 재시도 루프가 절대 성공할 수 없는 요청을 계속해서 두드리지 않도록 하는 방식입니다. 그 포스트는 기다릴지 '여부'를 결정하는 것에 관한 것이었습니다. 그 글은 그 기다림이 전체 실행 시간 중 실제로 '얼마나' 소비되는지에 대해서는 아무것도 말하지 않았는데, 왜냐하면 저는 한 번도 시간을 측정해 본 적이 없었기 때문입니다. "지수 백오프(backoff)와 함께 재시도한다"는 문구는 재시도 로직 단락 내에서는 작은 세부 사항처럼 읽힙니다. 하지만 이것이 3개 기사 실행 총 시간의 약 70%를 차지하며, 측정 전에는 가장 비용이 많이 들 것이라고 추측했던 트렌딩 토픽 조사(trending-topic research)를 포함한 다른 모든 단계를 합친 것보다 훨씬 크다는 것을 알게 되면 완전히 다르게 느껴집니다.

일반화할 수 있는 실수는 AI 파이프라인에서 AI 형태를 띤 부분이 기본적으로 병목 현상(bottleneck)일 것이라고 가정하는 것입니다. 왜냐하면 이러한 시스템을 설명할 때 그 부분이 가장 많이 언급되기 때문입니다. 이 파이프라인에서 "무엇을 쓸지 결정하는 것"은 밀리초 단위의 HTTP 요청과 인메모리 스코어링(in-memory scoring)에 불과합니다. "작성하는 것"은 상대적으로 빠른 텍스트 생성(text generation)입니다. 실행 시간이 얼마나 걸리는지를 결정하는 실제 하한선은 제3자 플랫폼의 쓰기 속도 제한 정책(write-rate policy)이며, 이는 AI와 관련된 것과는 전혀 무관합니다. 이는 dev.to UI에서 사람이 연속으로 두 번 "발행(publish)"을 클릭하더라도 동일하게 스로틀링을 적용할 것입니다.

해결책은 스로틀링과 싸우는 것이 아니다

이 문제를 해결하기 위해 제가 머리를 써보려고 시도했던 버전도 있습니다. 병렬 POST 요청, 더 짧은 백오프 (backoff), 더 빠른 재시도(retry) 등을 시도하는 방식입니다. 하지만 이 모든 것은 의도적인 속도 제한 (rate limit)에 맞서 최적화하려는 시도이며, 이는 타인의 인프라를 상대로 승산이 없고 다소 적대적인 게임이 될 뿐입니다. 실제로는 지루하지만 확실한 해결책은 이를 정직하게 계산에 넣는 것입니다. 즉, 실행(run)이 무엇을 달성할 수 있을지 계획할 때, 이를