fix(agent): 에이전트 동시 실행을 2 → 4 로 — max5 는 도달할 수 없는 값이었다

[dldnsgkr]

증상

승인까지 끝난 태스크가 QUEUED 로 1분 30초 넘게 멈췄다(dev, FE 실측).

원인 — 설정값과 실제 동작이 달랐다

ThreadPoolExecutor 는 큐가 가득 차야 코어를 넘겨 스레드를 늘린다. 예전 설정 core2/max5/queue10 에서는 큐 10 이 다 차기 전에 세 번째 스레드가 생기지 않으므로 max5 는 도달할 수 없는 값이었다 — 언제나 2 개만 돌았다.

증거: dev 전체 로그에 등장한 에이전트 스레드 이름이 agent-1, agent-2 둘뿐이다.

$ grep -ao '\[ *agent-[0-9]* *\]' dvely-backend-out.log | sort -u
[        agent-1]
[        agent-2]

그래서 한 사용자의 CODE 태스크(LLM 40 라운드, 14 분)와 BACKEND_DEPLOY 가 두 자리를 다 쓰자, 다른 프로젝트의 승인된 태스크가 워커에게 집히지도 못했다 — AgentRunWorker.estimateFreeExecutorSlots() 가 0 을 보고 claim 을 건너뛴다.

수정

	이전	이후
core (= 실질 동시 실행)	2	4
max	5 (도달 불가)	8 (도달 가능)
queue	10	8

• allowCoreThreadTimeOut(true) — 코어를 늘린 만큼 한가할 때는 회수한다
• 세 값을 설정으로 뺐다(qeploy.agent.executor.*) — 환경마다 자원이 다르고, CODE 태스크 하나당 Docker 컨테이너가 하나 뜨므로 메모리가 먼저 한계에 닿는다. 배포 없이 낮출 수 있어야 한다
• 기동 시 실제 동시 실행 값을 로그로 남긴다. 설정과 실제가 어긋나던 것이 이 버그의 핵심이라, 다음엔 로그만 보고 알 수 있어야 한다

크기 근거

이 태스크들은 벽시계 시간 대부분을 LLM 응답 대기로 쓴다(라운드당 6~20 초 × 수십 회). CPU 를 실제로 쓰는 구간은 컨테이너 안 빌드뿐이라, 코어 수(dev 2 vCPU)보다 조금 넉넉히 잡는 편이 처리량에 이롭다.

dev 현재 자원: 2 vCPU / 7.6GB(가용 4.3GB) / 컨테이너 9 개 실행 중. 거부는 여전히 신호로 남긴다(log.warn / DISPATCH_REJECTED) — 큐를 무한정 키워 삼키지 않는다.

검증

전체 1326개 통과. dev 배포 후 실측 필요 — 기동 로그의 동시 실행 값과, 동시 작업 시 QUEUED 대기가 사라지는지.

🤖 Generated with Claude Code

https://claude.ai/code/session_013y8USoCXTsRTATAhy88M93