본문으로 건너뛰기

분석 동시 실행에 상한을 두지 않는다

결정일상태원본
2026-07-31activeheymoa-ai/docs/decisions/2026-07-31-no-analysis-concurrency-cap.md

APP-298에서 큐를 걷어내고 BackgroundTasks로 옮기면서 ANALYSIS_WORKERS가 사라졌다. 다시 넣지 않는다.

상한이 막던 것을 지금은 다른 것이 막는다. 옛 워커 수는 두 가지를 겸했다 — 같은 잡이 두 번 도는 것과, 동시 LLM 요청이 provider rate limit을 넘는 것. 앞의 것은 이제 PgSingleFlight가 advisory lock으로 막는다. 인스턴스가 여럿이어도 동작해서 워커 수보다 낫다.

뒤의 것은 지금 잴 수가 없다. 접수량도 provider 한도도 아직 관측된 값이 없다. 숫자를 모른 채 상한을 넣으면 그 숫자가 근거 없이 굳고, 대개 너무 낮게 잡아서 분석이 한 줄로 선다.

넘쳤을 때 조용하지 않다. rate limit은 429로 오고, 섹션 재시도가 그것을 먹고 (analysis/timeouts.pyRETRYABLE에 429가 명시돼 있다), 실행 지표 로그의 outcome=error와 재시도 경고에 남는다. 무엇이 문제인지 모르는 채로 느려지는 상황이 아니다.

되돌리는 조건

셋 중 하나면 상한을 다시 넣는다.

신호어디서 보나
429가 섹션 재시도를 다 태우고 실패로 끝난다outcome=error + "재시도한 섹션" 경고
접수가 몰릴 때 total_ms가 평소의 몇 배가 된다실행 지표 로그의 분포
DB 커넥션 풀이 마른다PgSingleFlight가 잠금마다 커넥션 하나를 쥔다

되돌릴 때는 워커 수가 아니라 동시 실행 세마포어로 넣는다. 워커 수는 큐가 있을 때 말이 되는 단위이고, 지금은 큐가 없다.

같이 봐야 하는 것

server-ai.md의 미결 3이 rate limit 관계를 "재 본 적 없음"으로 두고 있다. 그것이 재지면 여기 숫자가 정해진다.