설정을 걸었는데 전선에는 안 실렸습니다
자체 호스팅 모델에 코딩 에이전트를 붙여 쓰고 계신다면, 지금 설정 파일에 적어둔 값 중 일부는 서버로 서버에 닿지 않습니다. 저희는 reasoning_effort를 낮춰두고 이틀을 보낸 뒤에야 그 필드가 저희 엔드포인트로 전송되지 않는다는 걸 알았습니다.
확인은 코드 한 줄에서 끝났습니다. 하네스가 그 필드를 실을지 결정하는 함수의 마지막 관문이 이렇습니다.
if not self._is_openrouter_url():
return False
허용 목록은 특정 호스트 몇 개뿐이었고 사내 도메인은 거기 없었습니다. 설정은 파일에 남아 있었고, 명령을 실행하면 성공했고, 아무 경고도 없었습니다. 걸린 것처럼 보이는 상태가 이틀 갔습니다.
전선에 실린 설정과, 실리지 못한 설정: 한 쪽은 빛을 전달하고 다른 한 쪽은 사라집니다.
무엇이 수렴을 만드는지 갈라 봤습니다
에이전트가 다중 결함 과제를 제대로 못 끝냈습니다. 원인을 좁혀야 했습니다. 후보는 셋이었습니다. 턴 예산이 모자란가, 프로바이더를 명시하지 않아서인가, 아니면 그동안 쌓아둔 하네스 튜닝이 효과를 낸 것인가.
한 번에 한 변수만 바꿔서 네 팔을 돌렸습니다. 과제는 결함 두 개짜리 파이썬 코드입니다. 채점은 모델의 말이 아니라 테스트 러너의 종료 코드가 했습니다. 작업 디렉터리는 팔마다 격리했고 순서는 번갈아 돌렸습니다.
| 팔 | 바꾼 것 | 벽시계 중앙 | 출력 토큰 중앙 | API 호출 | 통과 |
|---|---|---|---|---|---|
| 기준 | 없음 | 7초 | 291 | 5 | 3/3 |
| A1 | 턴 예산 40 → 120 | 7초 | 273 | 5 | 3/3 |
| A3 | 프로바이더 명시 제거 | 7초 | 314 | 5 | 3/3 |
| pretune | 튜닝 전부 되돌림 | 7초 | 278 | 5 | 3/3 |
열두 번 전부 통과했고 팔이 갈리지 않았습니다. 세 가설이 한꺼번에 죽었습니다. 특히 마지막 줄이 아팠는데, 며칠에 걸쳐 넣은 튜닝을 통째로 되돌린 팔도 똑같이 7초였기 때문입니다.
NotebookLM이 소스를 종합해 생성한 인포그래픽입니다.
그럼 장황함은 무엇으로 줄이나
reasoning_effort가 안 나간다면 남는 것은 채팅 템플릿 인자입니다. 같은 엔드포인트에 짧은 코드 생성 프롬프트 세 종을 두 번씩 던져 봤습니다.
| 완성 토큰 중앙값 | |
|---|---|
| 기본 (사고 켜짐) | 132.5 |
| 사고 끔 | 64.0 |
두 배쯤 줄어듭니다. 전달 경로는 프로바이더별 요청 본문에 얹는 방식이었고, 이건 실제로 전선에 도달했습니다. 응답의 사고 토큰이 0으로 떨어지는 것으로 확인했습니다.
표본 하나짜리 재측은 이상치에 끌려갈 수 있습니다. 짧은 프롬프트 하나가 유난히 짧은 답을 내놓으면 절감률이 다섯 배까지 부풀려 보일 수 있고 여섯 번 잰 중앙값이 주는 숫자가 두 배입니다. 인용할 숫자는 후자입니다.
두 설정, 두 운명. reasoning_effort는 호스트 허용 목록 게이트에서 전송이 끊기고, chat template 인자만 실제로 전선에 도달합니다.
flowchart TB
A["설정 파일"] --> B["reasoning_effort: low"]
A --> C["chat template 인자<br/>(사고 켜짐 / 끔)"]
B --> D{"하네스 디스패치 게이트<br/>(_is_openrouter_url)"}
D -->|"사내 도메인은 허용 목록에 없음"| E["전선에 도달하지 않음<br/>이틀 동안 no-op"]
C --> F["프로바이더별 요청 본문에 포함"]
F --> G["전선에 도달<br/>사고 토큰 0 확인"]
두 설정, 두 운명: reasoning_effort는 호스트 허용 목록 게이트에서 전송되지 않고 chat template 인자만 실제로 전선에 도달합니다.
스킬이 안 보인 이유는 작업 디렉터리였습니다
같은 기간에 다른 증상도 있었습니다. 저장소의 스킬을 에이전트에 물려줬는데 조회하면 하나도 없다고 답했습니다.
파이썬으로 탐색 함수를 직접 부르면 마흔세 개가 나왔습니다. 프롬프트 크기를 재면 스킬 색인이 4.6KB로 잡혔습니다. 도구도 노출돼 있었습니다. 그런데 세션 안에서는 계속 없다고 했습니다.
모델을 의심하다가, 요약하지 말고 도구가 돌려준 원문을 그대로 붙이라고 시켰습니다.
{"success": false, "error": "Skill 'game-start' not found.", "available_skills": []}
도구가 정말로 빈손을 돌려줬습니다. 에이전트에게 현재 디렉터리를 물으니 홈 디렉터리였습니다. 저장소 안에서 실행해도 그랬습니다. 프로젝트 루트를 못 찾으니 스킬이 0개가 됩니다. 환경 변수로 작업 디렉터리를 시드하자 마흔세 개가 보이고 스킬 본문도 정상적으로 열렸습니다.
세 번의 오진이 같은 모양이었습니다
수렴이 안 될 때 모델을 의심했는데 설정 혼입이었습니다. 스킬이 없다고 할 때 환각이라고 적었는데 사실이었습니다. 다섯 배 절감이 나왔는데 표본 하나짜리 이상치였습니다.
관측이 이상할 때마다 모델을 먼저 의심했고 매번 하네스가 범인이었습니다. 자체 호스팅 모델은 상용 API보다 낯섭니다. 의심이 그쪽으로 가는 게 자연스럽습니다. 그런데 낯선 쪽은 모델이 아니라 그 모델을 감싼 배선이었습니다.
실무에서 쓸 수 있는 것
설정을 건 뒤에 그 설정이 도달했는지를 따로 확인하시길 권합니다. 방법은 셋입니다. 코드에서 그 필드를 싣는 조건을 직접 읽습니다. 산출물이나 응답에서 값을 되읽습니다. 아니면 같은 요청을 두 조건으로 보내 토큰 수를 비교합니다.
그리고 반복 없이 잰 숫자는 인용하지 않는 편이 안전합니다. 표본 하나짜리 재측은 이상치에 끌려가고, 여러 번 잰 중앙값이 인용할 숫자입니다.
마지막으로 에이전트가 도구에서 무엇을 받았는지 알고 싶을 때는 요약이 아니라 원문을 요구하시면 됩니다. 저희가 사흘 붙잡고 있던 문제를 그 한 마디가 풀었습니다.
여기 적은 수치는 단일 B200 노드에서 서빙한 Qwen3.8-27B NVFP4 실측이며 7초라는 절대값은 이 사소한 과제 전용입니다. 코딩 에이전트 일반 성능으로 읽으시면 안 됩니다.
참고 자료
- vLLM 지원 모델 문서 : 자체 호스팅 서빙 설정의 정본
- Qwen3 블로그 : 사고 모드(on/off) 토글과 chat template 인자의 개념
- OpenRouter 문서 : 하네스가 호스트 허용 목록으로 가르는 대상인 프로바이더
NotebookLM이 소스를 종합해 생성한 인포그래픽입니다.