답변별 복기 부하 안전밸브를 환경변수로 노출

[i3months]

배경 — LLM 호출량 감사

비용·부하 축을 보면서 면접 1회의 LLM 호출을 세어봤다. 세션 종료 시 generate.feedback 하나가 동시에 부르는 것:

항목	호출 수
평가위원 패널	직군 수 N + 논리 + 전달력
자기소개 첫인상	1
직무 적합도	1 (JOB_TAILORED)
인성	1 (PERSONALITY·INTEGRATED)
답변별 복기(코칭)	답변 수만큼

복기가 최대 비용 지점이다. 나머지는 세션 길이와 무관하게 상수인데 이것만 선형으로 늘어난다. 답변마다 RAG 검색(임베딩 1 + 검색 1)까지 동반한다.

문제

그걸 막는 안전밸브 두 개가 조절 불가능했다.

coaching_max_answers: int = 30,   # 생성자 기본값
coaching_concurrency: int = 5,

runner.py 가 이 둘을 전달하지 않고, settings.py 에도 없다. 즉 게이트웨이가 429 를 내기 시작해도 코드를 고쳐 재배포하지 않으면 조일 수 없다.

코드의 주석은 목적을 정확히 알고 있다 — "게이트웨이 429/과부하 방지 — 답변별 코칭 호출 동시성을 제한한다." 그런데 정작 운영 중에 쓸 수가 없는 상태였다.

그리고 이건 이 저장소의 규약에서 벗어난 것이기도 하다. ai/CLAUDE.md §6.2 는 "설정은 settings.py + 환경변수로 주입 (코드에 하드코딩 금지)" 이고, 같은 성격의 다른 값은 전부 settings 경유다:

embedding_batch_size · embedding_max_retries · llm_pro_timeout_sec · llm_flash_timeout_sec · questions_rag_timeout_sec · followup_rag_timeout_sec · feedback_rag_top_k

이 둘만 빠져 있었다.

수정

feedback_coaching_max_answers / feedback_coaching_concurrency 를 settings 에 추가하고 runner 가 전달한다. 기본값은 그대로(30/5)라 동작 변화는 없다.

테스트

• test_runner_wires_coaching_limits_from_settings — runner 가 실제로 settings 값을 넘기는지. 런타임 조립에 의존성이 많아 인스턴스 생성 대신 배선을 고정했고, 공백 정규화로 포맷 변경에 깨지지 않게 했다
• test_coaching_limits_are_settings_backed — Settings 모델에 필드가 있는지

395 tests 통과.

동기화

.env.example · docs/environment.md (프로젝트 체크리스트 항목).

이번 감사에서 확인했고 문제없던 것

비용·성능 축은 전반적으로 잘 관리돼 있었다.

• 코칭 상한·동시성 자체는 이미 있었다 (이번 건은 "조절 못 한다"는 것이지 "없다"가 아니다). 상한 초과 시 feedback.coaching.capped 로그도 남긴다
• 임베딩: 배치(EMBEDDING_BATCH_SIZE) + 429 지수 백오프 + 재시도 상한
• RAG: 질문 풀은 문서 1개면 검색 생략(PLAN), followup·questions 모두 1.5s 하드 타임아웃 후 (none) 폴백
• LLM: Pro 30s / Flash 10s 요청 타임아웃 명시
• AMQP prefetch 10 — 동시 처리 세션 수의 상한
• Core 메시지 목록: 음성 분석을 배치 1회로 가져와 매핑(N+1 없음), parentMessage 지연 로딩도 목록 매핑에서 건드리지 않음