사용자 지적: "비소식, 눈소식, 태풍소식 이런 것도 넣어야겠네."
셋은 직전 커밋(58c01b7)으로 이미 걸리고 있었지만, 지적의 핵심은 맞았다 —
현상별로 흩어 놓으면 다음 현상에서 또 빠진다. 실제로 확인해보니 우박·안개·
서리 소식이 빠져 있었다. "OO 소식 있나?"는 날씨를 묻는 가장 흔한 말투라
개별 대응이 아니라 패턴으로 잡아야 한다.
WEATHER_PHENOMENON(비|눈|태풍|장마|한파|폭염|황사|미세먼지|우박|안개|서리|
더위|추위|바람|구름|강수|기온|날씨) × (소식|예보|전망|상황) 조합으로 통합.
"소식"·"전망" 단독은 넣지 않는다 — 회사 소식·업계 소식·실적 전망에 다
걸린다. 현상 목록에 "비"·"눈"처럼 다른 뜻과 겹치는 짧은 단어가 있으므로
단독 사용을 금지하는 주석을 목록 선언부에 붙였고, 오탐 4건을 테스트로 박아뒀다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
실사고(2026-08-12): "향후 비소식은 없나?"에 날씨 도구가 하나도 안 붙었다.
스코프 게이트의 hasWeatherKeyword 목록(날씨|기온|강수|미세먼지|...)에 "비"도
"기상청"도 없어서 weather_kma·weather_openmeteo가 스키마에서 빠졌고, 모델은
쓸 도구가 없으니 web_search로 갔다가 2019년 기사를 물어와 "예보를 확인할 수
없다"고 답했다.
이어서 사용자가 "기상청에 알아봐"라고 명시했는데 **그 말조차 목록에 없어서**
두 번째 턴도 web_search로 갔다. 기상청 홈페이지를 검색한 것이지 기상청 API를
부른 게 아니다. 대화 전체가 날씨 도구 없이 돌았다.
이 게이트의 비용 비대칭은 프롬프트 게이트와 반대다 — 오탐은 도구 스키마가
몇백 토큰 늘 뿐이지만 미탐은 답변 경로 자체가 틀린다. 넉넉하게 잡는 쪽이 맞다.
실사용 메시지 103건으로 교정: "기상청" 신규 2건(전부 진짜 날씨),
"비" 문맥형 신규 2건(전부 진짜 날씨), 오탐 0건.
- 기상청|예보|기상 상황
- 비 문맥형(비소식/비예보/비가 오/소나기/호우/폭우/우산) — "비" 단독은 넣지
않는다. 비용·비교·준비에 걸린다. 테스트로 박아둠
- 눈 문맥형(눈 소식/눈이 오/눈 올) — "눈" 단독은 신체 부위와 충돌
- 무더위|더위|추위|쌀쌀|습도|풍속|체감온도
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자 제보: "지서버 모델 연결됐는데 컨텍스트가 세션창에서만 8킬로", 그리고
"웹을 리로드하면 256킬로가 된다".
서버 쪽 마지막 폴백(8192)은 이미 캐시하지 않게 돼 있어서 매번 다시 조회한다
(그 사고를 겪고 고친 주석이 남아 있다). 문제는 브라우저였다 — app.js가
if (_appCtxMax > 0 && !force) return; // 한 번 받으면 끝
로 한 번 받은 값을 페이지 수명 내내 들고 있어서, 지서버가 자고 있을 때 열면
8192가 그대로 박혔다. 리로드가 고친 게 아니라 리로드로 캐시가 비워진 것.
메인 채팅 게이지는 SSE usage로 라이브 값을 받아서 멀쩡했고 세션창만 틀렸던
이유가 이것 — 두 화면이 서로 다른 경로로 같은 숫자를 구하고 있었다.
어댑터 쪽(bfbf04e)과 같은 원칙으로 고친다: **추측을 측정처럼 다루지 않는다.**
- resolveNumCtxInfo()가 value와 known(진짜 해석 결과인지)을 함께 반환
- /api/model-context가 provisional 플래그를 실어 보낸다. /api/show 실패나
마지막 폴백이면 true
- app.js: provisional이면 화면에는 보여주되 _appCtxMax에 저장하지 않아 다음
호출에서 다시 묻는다
- code.js: provisional이면 모델별 1회 래치(_codeAiCtxMaxFetchedFor)를 풀어
다시 조회하게 한다
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자 제보: "지서버 모델 처음 로딩하면 컨텍스트가 항상 8킬로인데, 웹을
리로드하면 256킬로가 된다."
getModelCtx()가 /api/show 실패 시 8192를 반환하면서 그 값을 캐시에 넣었다.
그리고 _resolveCtx가 요청값을 native로 깎는다:
if (requested && requested > 0) return Math.min(requested, native);
→ Math.min(262144, 8192) = 8192
지서버가 자고 있을 때 첫 조회가 실패하면 8192가 캐시에 박히고, 캐시는
updateEndpoint()에서 엔드포인트 문자열이 바뀔 때만 비워진다. 그래서 한 번
오염되면 계속 8K로 돌았고, wol-gate 직결/게이트 전환이 일어나 캐시가 비워질
때 비로소 정상으로 돌아왔다 — 리로드하면 고쳐지는 것처럼 보인 이유가 이것.
추측한 값을 사실처럼 캐시하고, 그걸로 사용자 설정을 덮어쓴 게 버그다.
두 가지로 나눠 고쳤다:
- getModelCtxInfo()가 native와 함께 known(진짜 조회 결과인지)을 반환한다.
**조회에 성공한 값만 캐시한다** — 지금 모델에 못 닿는다는 사실은 그 모델의
컨텍스트 창에 대해 아무것도 말해주지 않으므로, 다음 호출에서 다시 조회한다.
Modelfile num_ctx는 선언된 실제 값이라 캐시 대상으로 유지
- 명시적으로 요청된 창(models.profiles의 fixedNumCtx)은 **ceiling을 실제로 알 때만**
깎는다. 폴백 추측값으로 깎는 게 262144를 8192로 만든 경로다
검증: 응답 없는 엔드포인트로 재현 → 수정 전 8192, 수정 후 262144 유지.
실제 지서버 조회는 262144 정상, 동적 사이징의 8192 폴백은 그대로 동작.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
공개 데이터셋 조사 결과 GPU 말고는 쓸 물건이 없었다. pc-part-dataset의
motherboard.json은 4,973건인데 필드가 7개뿐이고(칩셋·PCIe·M.2·VRM 없음,
색깔은 있음) 13개월 전이 마지막 갱신, CPU 쪽은 1~4년 낡았거나 인텔 전용
이거나 AGPL, 미니PC는 데이터셋 자체가 없다.
"광고에서 찾는 게 빠르겠다"는 사용자 지적이 맞았다. 파는 물건이라 낡을
수가 없고(낡으면 목록에서 사라진다), 데이터셋이 없는 미니PC도 상품 페이지는
반드시 있다. 같은 메인보드 질의 실측 비교:
pc-part-dataset name/price/socket/form_factor/max_memory/slots/colour
다나와 AMD(소켓AM5) / AMD B650 / DDR5 / PCIe5.0 x16 /
M-ATX (24.4x24.4cm) / M.2 : 3개 / DrMOS / 전원부 방열판
라벨링은 GPU DB와 다르게 갔다. 저건 TechPowerUp 계측치라 "확정값"이지만
이건 판매처 표기이고 가격은 움직이는 값이라, 헤더에 그렇게 못박았다.
오늘 하루 주제가 근거에 정확한 라벨 붙이기였으니 출처를 부풀리지 않는다.
정중함은 선택이 아니라 제약으로 넣었다. robots.txt가 /dsearch.php는
허용하지만 Crawl-delay: 10이 걸려 있어서, 요청을 큐로 직렬화하고 10초
간격을 강제하며 30분 캐시를 둔다. 오늘 만든 비교 검색 쪼개기처럼 병렬로
３번 때리는 방식을 여기 쓰면 안 된다.
GPU에서 둘 다 걸릴 때 우선순위는 사용자 결정에 따라 다나와가 앞이고 스펙
DB는 폴백이다. 다만 버리지는 않고 출시일 한 줄은 남긴다 — 판매 목록엔 절대
없는 필드이고, 이 사태의 출발점인 "아직 출시 안 됨" 환각을 못 쓰게 만드는
게 정확히 그 필드다.
- parseDanawaHtml은 순수 함수로 분리해 저장된 페이지로 테스트한다. 스크래핑
마크업은 언젠가 깨지는데 진짜 위험은 "조용히" 깨지는 것이라, 0건 파싱은
전부 데이터 없음으로 처리하고 회귀는 테스트가 잡는다
- 가격은 price_sect 안의 <strong>만 인정한다. 블록 첫 <strong>은 평점일 수
있어 실제 페이지에서 "65"·"2"가 가격으로 잡히는 걸 확인하고 좁혔다
- isPcPartQuery는 부품 신호 + 스펙/가격 의도가 함께 있을 때만 참이다.
10초 딜레이가 있으니 조회를 아껴 쓴다. "메인보드에 CPU 끼우는 법"은 안 잡음
- 테스트가 구멍을 하나 잡았다: 카테고리 명사만 넣었더니 "RTX 5060 최저가"가
통과 못 했다. 사람은 부품을 모델명으로 부른다 — 모델명 표기를 추가
실측: "B650 메인보드 스펙" 1.7초, "미니PC 가격" 10.1초(크롤 딜레이 작동 확인)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"시어엔진에 이런 데이터 전용 API가 있나" → 253개 엔진 중 하드웨어 스펙
엔진은 0개였다(geizhals는 403 봇차단, ddg definitions는 GPU 모델명에 빈
응답). 대신 GitHub에서 RightNow-AI/RightNow-GPU-Database(Apache 2.0,
TechPowerUp 기반, 2,824개 GPU, 55필드)를 찾았고, README엔 언급이 없지만
실물엔 RTX 50 시리즈가 들어있는 것을 데이터를 받아 확인했다.
이게 지금까지의 우회로보다 나은 이유:
- nvidia.com 공식 페이지는 스펙 키워드 0개(JS 렌더링), techpowerup은
봇 차단. HTML 스크래핑으로 살아있는 출처가 nanoreview 하나뿐이었다
- 봇차단·JS·파싱실패·죽은링크가 전부 없고, 캐시 워밍 후 64ms
- 무엇보다 모든 레코드에 releaseDate가 있다. 5060은 2025-05-19다.
이 사태의 출발점이던 "5060은 미출시" 환각은 데이터와 만나는 순간
성립하지 않는다 — 가드는 쓰인 거짓말을 잡지만, 이건 쓸 이유를 없앤다
신선도가 진짜 리스크라 거기에 설계를 집중했다. 호스팅 API가 아니라 GitHub
저장소라서, 저쪽이 멈추면 우리도 멈추고 그러면 지금 고치는 실패가 데이터
계층에서 재현된다. 그래서 주간 갱신 + 결과에 캐시 나이를 항상 같이 실어
낡은 답이 조용히 틀리는 대신 눈에 띄게 낡도록 했다. 갱신은 백그라운드라
질문을 느리게 만들지 않고, 실패해도 옛 캐시로 계속 답한다.
도구가 아니라 주입으로 넣은 이유: 모델이 도구를 안 부른다. 로그 3,300줄
에서 web_fetch 호출 1번, GPU 질문엔 0번이었다(오늘 같은 결론 네 번째).
- extractGpuMentions: 맥락이 있을 때만 맨숫자를 모델명으로 본다.
"4080이 5060보다"는 잡고 "2024년 매출 3800억"은 안 잡는다 — 무관한
답변에 스펙이 끼어들면 그 자체가 오염이다
- findGpu: "RTX 4080"은 SUPER/Mobile 이름에도 부분일치하므로 변형에
가중치를 줘 기본 카드를 고른다. 데스크탑 질문에 노트북 칩 수치를
물려주면 조용히 틀린 답이 된다
- 캐시 쓰기는 write-then-rename (config.json 3회 손상과 같은 실패 방지)
실측: RTX 4080 FP32 48.74 TFLOPS / 716.8 GB/s vs RTX 5060 19.18 TFLOPS /
448 GB/s — 2.54배 차이를 근거를 갖고 말할 수 있게 됐다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
쪼개기(9f31d76)로 좋은 출처가 결과 목록엔 들어왔는데도 답변이 여전히
일반론이었다. 원인은 모델이 결과를 안 펼쳐본다는 것이다 — 프로덕션
로그 3,300줄에서 web_fetch 호출은 딱 1번, 그것도 기상청 페이지였고
GPU 스펙 질문에선 0번이다. 도구 설명에 "결과 URL을 web_fetch로 읽어라"라고
써 있는데도 그렇다. 스니펫엔 제품 이름만 있고 수치는 본문에 있으니,
스니펫만 보고 쓰면 "80 라인업이 60 라인업보다 빠르다"에서 멈춘다.
사용자 질문("스펙을 제조사에서 찾기가 어려운가?")에 답하려고 상위 세
출처를 실제로 가져와 재보니, 제조사 공식 페이지가 셋 중 가장 나빴다:
nvidia.com 6016자, 스펙 키워드 0개 — 표가 JS 렌더링이라 본문은
"This site requires Javascript" + "Game Changer" 홍보 문구
techpowerup 275자, 스펙 키워드 0개 — 봇 차단
nanoreview Cores/TMUs/Boost Clock/Bandwidth/TFLOPS 전부 있음
그래서 가져오되 거르는 구조로 했다. hasSpecContent가 통과시킨 첫 페이지
하나만 대상별로 붙인다 — 이게 없으면 "Game Changer" 6KB가 컨텍스트를
차지하고, 여러 장을 붙이면 모델이 읽고 지나가야 할 양만 늘어난다.
실측(같은 쿼리): nanoreview 4080·5060 본문 2장 자동 확보, 9.4초,
RTX 4080 Cores 9728 / 게이밍 76 vs RTX 5060 Cores 3840 / 게이밍 43 —
"얼마나 빠른지"에 실제로 답할 수 있는 수치가 처음으로 들어왔다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
어제(08-10) "A vs B로 합쳐 검색하지 말고 각각 따로 검색하라"를 web_search
설명에 넣었는데, 오늘 프로덕션 로그에서 모델이 세 턴 연속(3149/3287/3303)
정확히 금지된 형태를 그대로 날렸다:
web_search({"query":"RTX 4080 vs RTX 5060 performance comparison specs"})
매번 technical.city 링크가 죽어 있었고(link-validator 2/5 dead), 모델
손에 남은 건 제목뿐이라 답변은 수치 0건의 일반론이 됐다. 사용자 평가는
"자료가 부실하고 요점도 안 맞는다".
오늘 하루 네 번째 같은 패턴이다 — news_search country 파라미터, 카테고리
단어, 다도시 날씨 배치, 그리고 이번 건. 도구 설명으로 쿼리 구성을 강제할
수 없다는 게 반복 확인됐으므로 코드에서 쪼갠다.
- splitComparisonQuery: 비교 동사(comparison/vs/비교/차이)는 버리고
속성어(performance/specs/대역폭/성능)는 양쪽에 붙여 둘로 나눈다
- 합친 쿼리도 그대로 실행한다. 비교 페이지가 살아있을 땐 그게 최선의
출처라서, 빼면 실패 모드를 다른 실패 모드로 바꾸는 것에 불과하다.
쪼갠 검색은 추가분이고 결과 수를 3개로 더 조인다
- 오탐 쪽을 비싸게 본다: 속성어도 모델번호 꼴도 없으면 쪼개지 않는다
("Lakers vs Celtics"를 두 검색으로 만들면 질문 자체가 사라진다).
"검색결과 스펙"처럼 과/와로 끝나는 단어에 걸리는 것도 길이로 막았다
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
RTX 4080 vs 5060 비교 요청에서 모델이 답을 못 주는 이유로
"RTX 5060의 미출시 상태"를 단정했다. 실제로는 이미 출시돼 사용자
지서버에 꽂혀 있는 카드다.
기존 가드 셋이 전부 통과시킨 이유:
- AUTO-RECOVER: 검색을 하긴 했다 (도구 호출 있음)
- EMPTY-GROUNDING: 결과가 비어있지 않았다
- NUMERIC-GROUNDING: 답변에 수치가 0건이라 검증할 주장 자체가 없었다
세 가드 모두 숫자를 전제로 하는데, 이 답변의 유일한 거짓말에는
단위가 없었다.
부재 주장은 별도로 검증할 값어치가 있다. 모델은 "학습 데이터 시점
기준으로 출시 안 됨"만 알 수 있을 뿐 출시 여부 자체를 알 수 없다
(5060은 이 모델 컷오프 4개월 뒤 출시). 기억에 없는 것을 세상에 없는
것으로 바꿔 말하는 건 사실 판단이 아니라 범주 오류다. 검증 방법도
날짜 검증과 같다 — 출처가 정말 미출시라고 하면 그 표현이 출처 텍스트에
있고, 없으면 모델이 지어낸 것이다.
- checkNumericGrounding에 nonexistenceClaim/nonexistenceUnsupported 추가
- 출처 지지 판정(NONEXISTENCE_SUPPORT)은 느슨하게 잡았다. 느슨한 쪽이
재시도를 억제할 뿐 만들어내지는 않는 안전한 실패 방향이다
- 사용자가 질문에 적은 전제("그거 아직 안 나왔지?")를 되풀이한 건
숫자와 동일하게 검증 대상에서 제외
- 재프롬프트 문구를 분리했다. 기존 "출처에 있는 숫자만 써서 다시 써라"는
이 경우 헛도는 지시다 — 고칠 숫자가 없고, 문제는 정반대(지어낸 사실을
구실로 답변을 거절)이기 때문
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
실제 사고(2026-08-11): "5060 보다 얼마나 빠르지 4080?"에 도구 호출
0건, 모델이 "RTX 5060은 아직 출시되지 않은 차세대 모델"이라고
완전히 지어냈다 — 실제로는 이미 출시돼 지서버가 쓰고 있는 카드
(RTX 5060 Ti)다. "성능"/"비교" 등 기존 키워드를 하나도 안 써서
이 파일 자체 주석이 경고하던 "casual paraphrases slip through
unmatched"가 실제로 뚫렸다.
"A보다 (얼마나) 빠른/느린/좋은/나은" 형태의 캐주얼 비교 표현을
형용사 목록으로 추가. 구현 중 발견: 빠르다/느리다는 러-불규칙
활용이라 관형형이 "빠르ㄴ"이 아니라 "빠른"으로 어간 자체가
바뀐다(느리다→느린도 동일) — 어간만 넣으면 이 활용형을 놓쳐서
테스트가 그대로 잡아냈다("이게 저것보다 느린가?"가 최초 버전에서
빠짐), 두 형태 다 등록해서 고쳤다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
실사용 로그로 확인: 1분 간격 폴링 중에도 "지서버 응답 확인(깨어있음)"
과 "ping failed — 지서버 무응답"이 번갈아 찍혔다 — 60초로는 재우기
전에 못 잡는 경우가 있다는 뜻. 30초로 좁힘.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
실제 사고(2026-08-10): "RTX 3090 vs RTX 4080 Super memory bandwidth
comparison" 결합형 쿼리는 일반 개요 페이지만 반환해 두 스펙 다 못
찾았는데, 같은 두 개를 "RTX 3090 memory bandwidth GB/s" /
"RTX 4080 Super memory bandwidth GB/s"로 따로 검색하니 둘 다 바로
정답(936 vs 736 GB/s)이 나왔다.
numeric-grounding 가드가 검증 안 된 936GB 언급을 정확히 잡아냈고
(가드 자체는 M40+Qwen3.6 조합처럼 실존하지 않는 벤치마크를 지어낸
과거 사고 두 건에 근거해 만들어졌고 이번에도 의도대로 작동했다 —
가드를 손보지 않기로 결정), 대신 근본 원인인 검색 쿼리 구성을
고치기로 했다. news_search/weather_openmeteo와 달리 web_search는
결정적으로 고칠 API 단서가 없는 일반 웹검색이라, 이번엔 도구
설명에 프롬프트 지침을 추가하는 선에서 대응한다 — 오늘 다른
사례들처럼 100% 신뢰할 수 있는 방식은 아니지만 비용이 거의 없다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
08-10에 만들었던 2분 간격 버전을 효과가 불확실하다며 지웠는데(그
시점엔 지서버 쪽에 사용자가 직접 건 30초 하트비트가 병행되고 있어
어느 쪽 효과인지 분리가 안 됐음), 오늘 실제 실험으로 인과관계가
확인됐다: 지서버 쪽 30초 폴링을 끄자 몇 분 안에 Windows가 실제로
절전 상태에 들어갔다(게이트가 "깨우는 중" HTML 반환, ARP FAILED,
RDP·ping 전부 무응답 — 전부 실측 확인).
즉 주기적 폴링이 절전을 막는 효과 자체는 실재하고, 남은 건 그걸
지서버 쪽 별도 스크립트로 둘지 게이트웨이가 직접 할지의 문제였다.
사용자가 게이트웨이 쪽으로 다시 넣기로 결정 — 간격은 이전 2분보다
촘촘한 1분으로.
게이팅 로직은 이전과 동일: llm.provider === 'ollama_local'이고
WS 클라이언트가 최소 1개 연결돼 있을 때만(앱이 실제로 열려있고
지서버가 활성 모델일 때만) 직결 엔드포인트에 가벼운 요청을 보낸다.
게이트가 아니라 직결로만 보내므로 이미 잠들어 있으면 조용히
실패한다 — 깨우는 신호가 아니라 "깨어있는 동안 재우지 않는" 신호.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
실제 사고(2026-08-10): "오늘 유럽 대도시 최고 기온"에 모델이 5개
도시("London, Paris, Berlin, Madrid, Rome")를 한 번에 넘겨 실패
(도구별로 나눠 부르라는 안내 자체는 이미 08-09에 잘 만들어져 있었음),
그 뒤 로마·런던 2개만 재시도하고 파리·베를린·마드리드는 빠뜨렸다.
지어내진 않았지만("다른 도시 필요하시면 말씀해주세요") 불완전했다 —
같은 날 news_search/weather_kma에서 겪은 것과 같은 패턴: 프롬프트/
에러 메시지가 정확히 뭘 해야 하는지 알려줘도 여러 번의 후속 호출을
전부 완수하지는 못했다.
같은 해법 적용: 전체 문자열 지오코딩이 실패하면 배치인지 확인하고,
배치면 모델에게 재시도를 맡기는 대신 도구가 직접 각 도시를 병렬로
조회해서 구분선으로 나눈 하나의 결과로 합쳐 반환한다. 일부 도시가
실패해도 나머지는 정상 반환하고 실패한 도시만 목록에 남긴다 — 전체
호출이 부분 실패로 죽지 않는다.
부수적으로 OUTPUT FORMAT의 날씨 지침에 "여러 도시 비교 시 표만 던지지
말고 어디가 제일 덥/추운지, 특이한 도시가 있는지 코멘트를 붙일 것"을
추가 — 실제 로그에서 표 하나에 문장 하나짜리 부실한 답변이 관찰됨.
기존 배치 테스트(2026-08-09, success=false 검증)를 새 동작에 맞게
갱신(success=true + 도시별 결과 포함 검증) — 일부 실패 케이스 테스트도
추가.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
실제 사고(2026-08-10): "이번 주말 날씨 어때?"(5일 후 질문)에
weather_kma만 불렀고, 기상청 단기예보가 3일까지만 커버한다는 걸
확인하자 "금요일쯤 다시 물어봐 주세요"라며 끝냈다. weather_kma
자체 설명에 "3일 넘으면 weather_openmeteo로 보완할 것"이라고
이미 적혀 있었는데도 두 번째 도구를 안 불렀다.
같은 날 news_search에서 겪은 것과 정확히 같은 패턴 — 프롬프트/
스키마 설명 지침을 아무리 정확히 적어도 이 모델은 세부 지시를
안 따랐다. 그래서 같은 해법을 적용했다: 모델이 두 번째 도구를
기억해서 불러주길 바라는 대신, weather_kma가 자기 응답 안에서
Open-Meteo 4~7일차 예보(기온·강수확률)를 자동으로 붙여서
반환한다. 한 번의 호출로 끝나므로 두 번째 호출을 빼먹을 여지가
없다.
기상청이 실제로 커버한 마지막 날짜 이후만 보완하도록 날짜
경계를 계산하고(Open-Meteo가 이미 아는 날짜를 중복 표시하지
않음), 네트워크 실패 시엔 조용히 생략(기상청 데이터는 그대로
반환) — 보완 기능 하나가 핵심 예보 응답을 절대 깨뜨리지 않는다.
순수 필터링/포맷 로직(formatDailySupplement)을 네트워크 호출과
분리해 테스트 가능하게 했다 — link-validator.ts/news.ts와 같은
패턴, 회귀 테스트 4개 추가.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자 관찰("크기가 바뀔 때마다 올라마가 모델을 다시 로드하네")을
직접 재현·측정: 같은 num_ctx로 두 번 호출하면 load_duration 1.3초,
num_ctx만 바꿔 호출하면 18.8초. ollama-adapter.ts의 _resolveCtx()가
매 턴 프롬프트 크기에 맞춰 2의 거듭제곱으로 동적으로 재계산하는데,
그 값이 바뀔 때마다 Ollama가 모델을 통째로 재로드하는 것 — 대화
도중 설명 안 되는 수 초짜리 멈춤으로 나타났다.
동적 사이징 자체는 VRAM이 빠듯한 배포를 위해 존재하는데, 지서버는
그 경우가 아니다: gemma4:26b를 native 최대 컨텍스트(262144)로
로드해도 32GB 중 18.3GB만 쓰고 13.7GB가 남는다(실측, size_vram).
아낄 필요가 없는데 아끼다가 재로드 비용만 치르고 있었다.
models.profiles[<model>].fixedNumCtx로 모델별로 동적 사이징을
끄고 항상 고정값을 요청하게 하는 옵션을 추가했다(getModelProfileForceToolChoice와
같은 패턴). gemma4:26b는 262144로 설정 — 한 번 로드되면 대화가
아무리 길어져도 재로드가 없다. 다른 모델/제공자는 기존 동적
사이징 그대로 유지된다(opt-in이라 이 모델 외엔 영향 없음).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
같은 문제("태풍 돌핀" 쿼리 → 0건)를 프롬프트/스키마 설명으로 4번
연속 고치려 했으나, 실사용 재현 테스트마다 모델이 매번 예전 방식
그대로 호출했다(country 안 넣거나, 카테고리어+고유명사를 한 쿼리에
계속 붙임). prompt-gates.ts 파일 자체의 설계 철학대로 — "프롬프트
지시만으론 안 믿을 때 결정적으로 강제하는 백스톱" — 이번엔 코드가
직접 보정하도록 바꿨다.
execute()에 두 가지 결정적 로직 추가:
1. 쿼리에 한글이 있는데 country/language 둘 다 없으면 자동으로
country="kr" 적용. 모델이 계속 빠뜨리던 파라미터를 기본값으로
메운다.
2. 검색 결과가 0건이고 쿼리에 재해 카테고리어(태풍/지진/산불 등)가
섞여 있으면, 그 단어만 제거하고 자동 재시도. 라이브 API로 직접
검증: q="태풍 돌핀"은 0건, q="돌핀"은 5건 — 실제 기사 제목이
"태풍 '돌핀'"(따옴표 있음)이라 연속 문자열 매칭이 실패했던 것.
두 로직을 resolveNewsParams/stripCategoryWordForRetry로 분리해
네트워크 없이 단위 테스트 가능하게 했다(link-validator.ts의
rewriteDeadLinks와 같은 패턴) — 실제 사고 수치를 그대로 회귀
테스트에 고정, 10개 추가.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
이전 커밋에서 "country 파라미터 누락이 원인"이라 진단했는데, 사용자가
"국내 사이트로 검색하면 쏟아질 텐데?"라고 반박해서 NewsData.io API를
직접 여러 조합으로 호출해 재검증했다:
q="태풍 돌핀"+country=kr → 0건
q="태풍"+country=kr → 12건 (돌핀 기사 포함)
q="돌핀"+country=kr → 5건 (전부 관련 기사)
실제 원인은 country 누락이 아니라 **일반 카테고리어("태풍")와 고유명사
("돌핀")를 한 쿼리에 붙여 쓴 것**이었다. 실제 기사 제목은 "태풍 '돌핀'"
처럼 따옴표가 끼어 있어 "태풍 돌핀"이라는 연속 문자열과 리터럴 매칭이
안 됐다. 이전 커밋의 country 안내 자체는 여전히 유효하지만(비영어
쿼리엔 필요), 그것만으론 이 사고를 설명 못 했다.
query 파라미터 설명에 실제 API 호출로 검증한 세 가지 결과를 근거로
"특정 개체/사건이 있으면 카테고리어와 합치지 말고 그 이름 하나만
쓸 것"이라는 지침을 추가했다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
실제 사고(2026-08-10): news_search({"query": "태풍 돌핀"})가 country
없이 호출돼 "(no articles found)"를 반환했다. 같은 시점에 국내
언론사 6곳 이상이 그 사건(중국 상륙, 100만명 대피)을 보도 중이었다.
원인: NewsData.io는 country 없이 호출되면 영어 위주로 치우친 풀에서
쿼리 텍스트를 그대로 매칭한다. 한국어 쿼리 텍스트는 그 풀 안의 기사와
문자 그대로 안 맞아서 빈 결과가 나온다. 기존 설명엔 "포괄적인 요청엔
쿼리를 생략하라"는 지침만 있었고, "특정 주제의 비영어 쿼리면 country를
같이 넣어라"는 지침은 없었다.
query 파라미터 설명에 이 사례를 실측 근거로 추가해, 비영어 쿼리엔
반드시 country를 함께 넣도록 안내했다. 재해 리마인더가 아니라 도구
스키마 자체에 넣어서 재해 질문뿐 아니라 모든 news_search 호출에
적용된다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
실제 사고(2026-08-10): "태풍 돌핀 지금 어디 있지?"가 메인 채팅에서
web_search만 쓸 수 있었다. weather_map_screenshot(기상청/JMA 태풍
예상진로 지도 캡처)은 날씨 앱 탭에만 열려 있었고, news_search는
"뉴스"라는 단어가 없으면 안 열렸다 — 재해 질문은 둘 다 못 썼다.
그 결과 모델이 자체 생성한 "현재 위치 실시간 정보" 쿼리로 검색해
빈 포털 페이지만 받았고, 정직하게(수치를 지어내지 않고) "이미
소멸했을 가능성이 높다"고 결론 냈다 — 실제로는 중국에 상륙해
100만명 이상 대피, 500mm 폭우 경보 중이었다.
사용자 요청대로 "위치/경로"와 "피해상황" 두 축으로 나눠 연동했다:
- weather_map_screenshot: hasSatelliteKeyword(태풍 포함)로 게이팅
추가 — 기존 eonet_events/satellite_snapshot과 같은 패턴. 검색
스니펫보다 신뢰도 높은 기상청/JMA 공식 소스를 메인 채팅에서도
쓸 수 있게 한다.
- news_search: DISASTER_PATTERN(prompt-gates.ts, isDisasterRequest와
동일 소스 — 두 파일이 서로 다른 재해 키워드 목록을 들고 있다가
어긋나는 걸 막기 위해 재사용)으로 게이팅 추가. "뉴스"라는 단어가
없어도 재해 키워드만으로 피해/대피 상황 검색이 가능해진다.
handle-chat.ts의 사전 리마인더도 "위치/경로는 weather_map_screenshot,
피해상황은 news_search"로 역할을 나눠 안내하도록 확장했다.
이전 커밋(재해→news_search 라우팅 프롬프트 지침)만으로는 실사용
재검증에서 모델이 여전히 예전 쿼리를 그대로 썼다 — 프롬프트 지시만
믿지 않고 도구 자체를 실제로 쓸 수 있게 여는 쪽으로 보강했다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
실제 사고(2026-08-10): "태풍 돌핀 지금 어디 있지?"에 web_search가 자체
생성한 "태풍 돌핀 현재 위치 실시간 정보" 쿼리로 검색해 일반적인/내용없는
결과 3개(기상청 빈 포털, 오래된 지도 SPA, 무관한 결과 1개)만 받았다.
모델은 정직하게(좌표를 지어내지 않고) "검색결과가 없으니 이미 소멸했을
가능성이 높다"고 추론했다 — 추론 자체는 멀쩡했지만 전제(검색해도 안
나온다)가 검색 실패 때문에 거짓이었다. 실제로는 돌핀이 막 중국에
상륙해 500mm 폭우 경보, 100만명 이상 대피 중이었고, 같은 사건을 다룬
국내 언론사 기사가 6개 이상 있었다 — "태풍 돌핀 중국 상륙 피해"처럼
상황어를 넣은 쿼리로는 바로 찾아졌다.
news_search(NewsData.io, 실제 발행일 보장)가 정확히 이런 "지금 벌어지고
있는 일" 질문을 위한 도구인데, 재해 질문은 뉴스로 분류되지 않아
(isNewsRequest는 "뉴스/속보" 키워드가 있어야 걸림) 이 라우팅을 안 탔다.
isLiveDataRequest 안에 있던 재해 정규식을 isDisasterRequest로 분리해
handle-chat.ts의 사전 리마인더와 AUTO-RECOVER 재시도 리마인더 양쪽에
재사용했다 — 이 파일 헤더의 원칙대로, 검증을 강제하는 게이트끼리
어긋나면 한쪽만 고친 게 무의미해진다. 재해 질문엔 news_search를
우선 권하고, web_search를 쓰더라도 "현재 위치/실시간 정보" 같은
일반 쿼리 대신 "...상륙 피해", "...대피" 같은 상황어를 쓰도록
안내한다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
효과가 불확실했다. 로그로 보면 2분 핑이 도는 동안에도 한 번은 실제로
잠들었고("방금 또 잠들었던거 같으네"), 다른 구간에선 40분 연속 안
잤는데 그게 핑 덕분인지 그 시간 내내 실사용 채팅이 있었기 때문인지
분리할 수 없었다.
사용자가 지서버 쪽에 직접 10초 간격 하트비트를 새로 걸었다 — 원격에서
2분마다 찔러보는 것보다 훨씬 촘촘하고, 무엇보다 지서버 자체에서 도는
메커니즘이라 신뢰도를 판단하기 쉽다. 서버 쪽 것은 이제 중복이라
사용자 결정으로 제거.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
실사용 사고(2026-08-10, "16호 태풍" 답변): 모델이 URL을 그 자체로 링크
텍스트로 쓰는 흔한 패턴 `[https://x.com](https://x.com)`에서, 죽은 링크
탐지 정규식(BARE_RE)이 `]`/`[`에서 멈추지 않아 라벨의 `]`, href의 `(`를
넘어 마크다운 링크 전체를 하나의 "URL"로 삼켜버렸다. 그 결과 사용자가
실제로 본 출력은 `~~[~~url](url~~ ⚠️ (링크 끊김)))~~ ⚠️ (링크 끊김)`
같은 뒤섞인 텍스트였다.
BARE_RE의 부정 lookbehind와 문자클래스 양쪽에 `]`/`[` 제외를 추가해
마크다운 링크 경계를 넘지 못하게 했다. LINK_RE(먼저 실행됨)가 이미
"라벨이 URL 자체인" 경우를 포함해 [label](url) 쌍 전체를 처리하므로
BARE_RE는 그 경계 안으로 들어갈 필요가 없다.
rewriteDeadLinks()를 validateLinksInText()에서 분리해 순수 문자열
변환만 네트워크 모킹 없이 테스트 가능하게 했다 — 회귀 테스트 8개
추가, 실제 사고 사례를 그대로 재현해 고정.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자가 "어제 집에서는 괜찮았는데 지금 외부에서 연결하니깐 자꾸
끊어지네"라고 보고. 서버는 이미 30초마다 ping을 보내 프록시/OS 유휴
타임아웃(92초 패턴)을 피하는 방어 로직이 있고(server.ts wsPingInterval),
60초 무응답이면 서버가 직접 연결을 끊는다.
메인 채팅 페이지엔 이 ping에 응답할 JS 타이머를 살려두는 장치가 없었다.
음성통화 페이지(voice-call.js)는 정확히 같은 증상(폰 화면 꺼짐 → 탭
백그라운드 스로틀링 → 소켓이 서버 ping에 응답 못 함 → 끊김)을 07-09에
Wake Lock으로 이미 고쳤는데, 메인 채팅 쪽엔 이 조치가 빠져 있었다 —
집에서는 화면이 잘 안 꺼지니 덜 겪고, 외부에서 폰으로 쓸 때 화면이
자주 잠기니 더 자주 겪는 것과도 맞아떨어진다.
voice-call.js와 같은 패턴을 그대로 적용: WS가 열릴 때 Wake Lock을
요청하고, visibilitychange로 탭이 다시 보일 때 재요청(Wake Lock은 탭이
숨겨지면 자동 해제되므로), WS가 닫히면 명시적으로 해제.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
08-09에 이미 조사했던 "지서버가 30분 설정보다 훨씬 빨리 잔다" 문제는
사용자가 전기료 절약 관점에서 선호하는 동작으로 확정하고 조사를 접었던
건이다([[project_wol_gate]]). 그런데 오늘(08-10) 외부에서 실제로 사용
중일 때 이 빠른 절전이 매번 ~23초 기상 지연으로 이어져 불편해졌고,
사용자가 "지서버가 안자게 신호를 계속 보내자"고 명시적으로 요청했다 —
원인 재조사가 아니라 능동적 keep-alive를 원하는 것으로 확인.
원인 후보였던 "Windows 유휴 타이머가 마지막 사용자 입력 기준이라
API 트래픽으로는 리셋 안 됨"이 맞다면, 주기적으로 실제 HTTP 요청을
보내는 것 자체가 대응책이 된다.
`llm.provider === 'ollama_local'`이고(getProvider()의 단일 캐시 구조상
어차피 이 조건에서만 실제 채팅 트래픽도 지서버로 간다) WS 클라이언트가
최소 1개 연결돼 있을 때만(앱이 실제로 열려 있을 때만) 2분마다 직결
엔드포인트에 가벼운 /api/tags 요청을 보낸다. 게이트가 아니라 직결로만
보내므로, 이미 잠들어 있으면 그냥 조용히 실패한다 — 깨우는 신호가
아니라 "깨어있는 동안 재우지 않는" 신호라, 나머지 시간대의 절전
이점(사용자가 이미 선택한)을 훼손하지 않는다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자가 "지서버 젬마(gemma4:26b)가 도구를 잘 안 부르는 경향이 있다"고
직접 사용 경험을 보고했다. 이건 mistral-large-3 프로필이 이미 대응하는
것과 같은 실패 클래스(확인 가능한 질문에 도구 없이 답함)인데, 젬마
쪽은 뒷받침할 로그 증거가 없었다 — 있는 거라곤 사용자의 기억뿐이었다.
[[feedback_calibrate_on_real_data]]에 이미 세 번 적힌 교훈대로("가상
케이스로 임계값 잡으면 틀린다"), 기억만으로 프롬프트 경고를 새로
박아넣는 대신 실제 신호를 기록하고 나중에 데이터로 판단하기로 했다.
decideAutoRecover()가 이미 정확히 필요한 이벤트("도구가 필요한 질문에
관련 도구 없이 답함")를 계산하고 있었는데, 그 결과가 닿는 곳이 로테이션
되는 콘솔 로그 한 줄뿐이었고 거기엔 모델 이름도 없었다. usage-log.ts와
같은 형태(같은 디렉터리, 같은 JSONL append 패턴)로 tool-skip.jsonl을
추가해 모델별 집계가 가능하게 했다.
effectiveModel이 try 블록 안에서만 스코프였고 AUTO-RECOVER 체크는 그
catch 이후라서, try 블록 진입 시점에 resolvedModelThisRound에 미리
복사해 바깥에서도 참조 가능하게 했다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
이 문장은 245토큰으로 무조건 블록 중 단일 최대 항목인데, 내용이 통째로
"web_search를 먼저 불러라"다. 그 도구가 이번 턴 스키마에 없으면 실행할 수
없는 지시이고, 무엇보다 executeTool()이 스키마 멤버십을 확인하지 않고
이름으로만 디스패치하기 때문에 프롬프트가 도구 이름을 언급하는 것만으로도
모델이 파라미터 문서 없이 그 도구를 호출해버린다. meteorologist 스킬을 끈
사용자에게 weather_kma가 계속 돌던 그 경로다.
조건이 규칙의 실행 가능성과 정확히 일치하므로, 이건 이 파일 규칙 1이 금지하는
메시지 게이팅이 아니라 정상적인 도구 게이팅이다. ANTI-HALLUCINATION 앞부분
(도구 출력을 그대로 옮겨 적으라는 지침)은 도구와 무관하므로 무조건 유지된다.
토큰 절감은 없다. 처음엔 절감을 기대했으나, web_search가 어떤 스킬 게이트에도
속하지 않아 사실상 모든 일반 턴에 스키마에 들어간다는 걸 뒤늦게 확인했다.
실제로 줄어드는 건 부팅 턴(coder_list_files/coder_read_file만 있는 턴)뿐이고,
1687 → 1442 토큰이다. 그 턴에서 스키마에 없는 web_search를 프롬프트가 부르던
누출 벡터가 사라진 것이 이 커밋의 실질적 이득이다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
실사용 로그와 세션 104건을 가드에 직접 돌려서 찾은 오탐들이다.
1) 사용자가 질문에 직접 적은 숫자로 AUTO-RECOVER가 걸렸다.
로그 실례: "북위 27.7도, 동경 124.8도 여기가 어디쯤이지?" — 그 좌표 자체가
한 턴 전 web_search 결과였고 사용자가 그대로 옮겨 물은 것이다. 모델이
정답("동중국해")을 냈는데 답에 좌표를 되풀이했다는 이유로 COORDINATE_CLAIM이
걸려 재생성 + "latitude 27.7 longitude 124.8 location" 검색을 태웠고,
돌아온 건 "농림통계연보(2005).hwp"였다. 그러고서 같은 답을 다시 썼다.
이 가드가 잡으려는 건 "모델이 지어낸 숫자"인데, 사용자가 적어 넣은 숫자는
정의상 모델이 만든 값이 아니다. looksLikeUnverifiedSpecClaim에 userMessage를
받아 스캔 전에 지운다. 모델이 새로 덧붙인 수치는 그대로 남는다. 한 자리 수는
지우지 않는다 — 메시지의 "2" 하나로 답변의 모든 "2"가 지워지면 가드가 통째로
무력화된다(회귀 테스트 포함).
2) nhc_active_storms/eonet_events가 GROUNDING_TOOL_PATTERN에 없었다.
둘 다 권위 있는 원본(미 국립허리케인센터, NASA EONET) 직결이고 태풍 질문이
실제로 도는 도구인데, 08-09에 추가한 MEASUREMENT_UNITS/COORDINATE_CLAIM이
바로 그 도구들이 돌려주는 값(hPa·m/s·북위)에 반응한다. 그래서 NHC 데이터로만
답한 턴이 "근거 도구 미호출"로 분류돼, 방금 읽은 권위 있는 출처를 의심하라고
web_search 재시도를 걸었다. memory_stats 때와 같은 구멍이다.
3) 긴 붙여넣기 문서 본문의 우연한 키워드로 강제검색이 걸렸다.
7,583자짜리 고소장 작성 요청이 본문 한가운데(2578자 지점)의 "시세"(장물
시세) 때문에 isLiveDataRequest에 걸렸다. 문서를 써 달라는 턴에 "메모리에서
답하지 말고 검색부터 하라"는 리마인더가 붙는 건 토큰 낭비를 넘어 작업 방향을
반대로 민다.
처음엔 "길다 + isExecutionLikeRequest"로 막으려 했는데 회귀 테스트가 그게
틀렸음을 잡아냈다 — 그 메시지가 실행형으로 분류된 근거가 본문의 "화면" 한
단어였다. 막으려는 문제와 똑같은 우연 위에 얹은 수정이었다. 대신 위치를
본다: 사람은 지시를 자료의 앞이나 뒤에 쓰지 한가운데 묻지 않는다.
600자 초과 메시지는 앞 400자 + 뒤 300자만 스캔한다(instructionZone).
검증 강제 게이트끼리 예외가 어긋나면 안 되므로 isFactualInfoRequest에도
같이 적용했다.
실사용 104건 대조: isLiveDataRequest 오탐 3건 제거하고 정당한 25건은 전부
유지, 출력측 가드는 로그의 그 좌표 케이스가 정확히 하나 걸러졌다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
이 블록은 470토큰까지 커져 무조건 블록 중 두 번째로 큰 항목이었는데,
실제로 모델이 \ce{}나 ```smiles를 내보낸 건 로그 83일 중 3일(~4%)뿐이었다.
나머지 96%의 턴에 값을 치르는 쪽이 더 나쁜 거래다.
이 파일 규칙 1("도구로만 게이팅, 메시지 문구로는 절대 금지")에 대한 의도적
예외다. 출력 형식 제약이라 키로 삼을 도구가 애초에 없고, 무엇보다 대가의
크기가 다르다 — image_edit 규칙이 빠지면 위험한 도구 호출이 나가지만, 이건
놓쳐봐야 깨진 ASCII 다이어그램 하나다. 파일 헤더의 규칙 2도 "무조건 유지"에서
이 예외를 설명하는 쪽으로 고쳐 적었다.
키워드는 일부러 넓게 잡았다. 애초에 무조건 유지했던 이유가 "치과/의료 질문은
화학 키워드 없이도 구조를 그리게 될 수 있다"였고 그게 이 사용자의 실제
도메인이므로, 성분·약물·마취·불소·아말감·레진·모노머·resin·anesthe 등을
함께 넣었다.
실측: 비화학 턴 시스템 프롬프트 1708 → 1533 토큰.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"지금 비오는 곳이 있나?"에 web_search를 부르긴 했는데, 돌아온 게 URL에
tm=2024.12.13.20:00이 박힌 2024년 캐시 페이지였다. 모델은 그걸 "현재"라며
그대로 소개했고, 표를 옮겨 적으면서 열까지 잘못 읽어 동두천의 강수량을
파주 것으로, 양평의 풍속을 강수량으로 뒤바꿨다.
기존 가드는 "근거 도구를 불렀는가"만 본다(hasGroundingToolCall). 불렀다는
사실만으로는 결과가 최신인지, 옮겨 쓴 값이 맞는지 전혀 검증되지 않는다.
그래서 결과 자체를 의심하라는 지침을 프롬프트에 넣었다:
- 검색결과가 자체 타임스탬프(URL의 날짜, dateline, "as of ...")를 갖고
있는지 확인하고 현재 날짜와 대조할 것. 하루이틀 넘게 묵었으면 "지금"이
아니므로, 옛 수치를 현재처럼 내놓지 말고 실시간 데이터를 못 찾았다고
말하고 찾은 날짜를 밝힐 것.
- 표는 위치가 아니라 행 레이블로 읽을 것. 한 행의 수치가 옆 행으로
밀리면 "못 찾음"보다 나쁘다 — 틀렸는데 권위 있어 보이기 때문이다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
세션 papa@ca71bc1c(로그 12804행): "마두로 미국에 잡혀가지 않았나?"에 세 턴
연속 도구 호출 없이 "체포되지 않았다"고 확신에 차 정정했는데, 실제로는
사용자가 맞았다(이미 미국에 체포·압송된 상태). 직전 커밋에서 체포/사임 등
개별 어휘를 isLiveDataRequest에 추가해 이 사고는 막았지만, 그 방식 자체가
화이트홀이었다 — 다음번엔 태풍도 체포도 아닌 제3의 화제에서 또 뚫린다.
화제별 어휘 목록 대신 "최근/지금/현재"가 들어가면 화제를 안 가리고 걸리도록
일반화했다. 근거는 실사용 로그 403건 전수조사: 이 세 표현이 들어간 66건
(16.4%) 중 오탐 0건 — 비트코인 시세·현직 대통령·최신 모델 버전 등 전부
정당한 실시간 조회였다. 새 레이어가 추가로 잡아낸 32건 중 31건도 마찬가지로
필요한 검색이었고, "지금 몇 시야?"만 이미 시스템 프롬프트에 있는 시각을
다시 검색시키는 사소한 낭비였다(오답은 아님). "요즘"은 실사용 예가 없어
후보에서 뺐다 — "요즘 어떻게 지내?" 같은 잡담과 부딪힐 위험을 검증 없이
감수하지 않는다.
넓히는 과정에서 진짜 버그 두 개가 드러났다:
- isLiveDataRequest가 isExemptFromVerification(지서버/클로서버 등 개인
인프라 예외)을 애초에 한 번도 거치지 않고 있었다. 파일 상단 주석은 "모든
검증 가드가 이 예외를 자동으로 적용받는다"고 주장했지만 사실이 아니었다.
시점 표현을 넓게 걸자 "지서버 최근에 왜 이렇게 느려"가 웹검색 리마인더에
걸릴 뻔하면서 드러났다.
- "시어엔진"(SearXNG 별칭)이 예외 목록에 없었다. 실사용 로그의 "현재
시어엔진 상태 어때?"는 웹검색으로 검증 불가능한 로컬 인프라 질문이다.
둘 다 함께 고쳤다. 부수 효과로, 오타("잡ㅎ간") 때문에 이전 커밋의 체포 어휘
목록이 못 잡던 마두로 사건의 첫 턴도 "현재" 표현으로 이제 잡힌다.
코딩/실행형 요청(isExecutionLikeRequest)과 인사말(isGreetingLikeMessage)은
계속 제외한다 — "지금 이 코드 확인해줘"에 검색 리마인더가 끼어들면 안 된다.
검증: tests/prompt-gates.test.ts 6개 추가, 196개 전부 통과. 실제 채팅에서
"비트코인 현재 가격이 얼마야?" → web_search 호출 확인, "지서버 지금 몇 개
모델 로드돼있나" → 웹검색 없이 로컬 처리 확인.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
지서버는 provider가 바뀌어도 항상 backendOnline=true(클라우드는 하드코딩,
ollama_local은 연결 성공 시)라서, 사이드바가 늘 "ollama_local Online" /
"OpenAI Online"을 표시했다. 초록 점이 이미 온라인을 뜻하는데 그 옆에 같은
정보를 글자로 반복했고, 길어서 좁은 사이드바에서 줄바꿈까지 일으켰다.
온라인일 때는 provider 이름만 남기고, 절전 중/오프라인처럼 실제로 알려줄
정보가 있을 때만 상태 단어를 붙인다. 어떤 provider든 동일한 조건문을 타므로
클라우드에도 자동 적용된다(브라우저에서 "OpenAI"로 확인).
설정 탭의 런타임 정보 행(#r-ollama)은 라벨-값 쌍의 전용 상태 표시라 손대지
않았다 — 값이 비면 어색해진다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
세 계정(papa/cherry/jasmine)의 vault.key와 vault.enc가 저장소에 함께 추적되고
있었다. vault.key는 vault.enc를 여는 마스터 키라 둘이 같은 저장소에 있으면
암호화가 무의미하다. 복호화해보니 담긴 값이 메인 vault와 해시까지 동일한
현재 사용 중인 자격증명이었다 — 이메일 비밀번호 3개와 Unsplash/Pexels 키.
원인은 .gitignore의 `.smallclaw/vault/`가 저장소 루트에 앵커된 패턴이라
한 단계 아래의 사용자별 vault를 못 잡은 것. 아래쪽 `.smallclaw/users/*/workspace/`
규칙이 지금은 이 경로를 덮지만 gitignore는 이미 추적 중인 파일에는 적용되지
않으므로, 그 규칙이 추가되기 전에 커밋된 이 파일들은 계속 남아 있었다.
- git rm --cached (디스크 파일은 유지 — 서비스가 그대로 읽는다)
- `**/vault/vault.key|vault.enc|vault-audit.log` 추가. 누구도 예상 못 한 경로에
새 vault가 생겨도 막히도록 깊이에 무관하게 매칭한다.
메인 vault(API 키·NVR·텔레그램 등 40개)는 기존 규칙에 걸려 유출되지 않았다.
주의: 히스토리에는 그대로 남아 있다. 이 커밋은 앞으로의 추가를 막을 뿐이며,
저장소가 2026-05-05부터 96일간 공개 상태였으므로 노출된 값은 이미 유출된 것으로
간주하고 회전해야 한다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vault에 저장된 키는 이름만 opaque 문자열로 남아 있고 어디서 발급받았는지가 UI
어디에도 없어, 갱신·재발급 때마다 해당 콘솔을 찾아 헤매야 했다. data.go.kr은
특히 하나의 키라도 서비스별로 활용신청이 따로 필요한데(에어코리아 측정소정보가
같은 키로 403 난 이유), 그 사실이 기록된 곳이 없었다.
- 서비스 19곳의 발급 페이지 링크. /api/credentials/status로 실제 저장 여부를 읽어
✓(저장됨)/·(미저장)로 표시하므로 하드코딩된 목록이 아니다.
- 공공데이터포털 항목에 "서비스별로 활용신청 필요"를 명시했다.
- 전 링크 https + target=_blank + rel=noopener noreferrer, 값은 escHtml 처리.
- Vault 조회에 실패해도 링크는 그대로 보이고 경고만 덧붙인다. 저장 여부를 잘못
표시하는 것보다 모른다고 하는 편이 낫다.
브라우저에서 렌더 확인: 19개 중 17개 ✓, 미저장으로 표시된 Brave·OpenAI는
실제 Vault 내용과 일치. 콘솔 에러 없음.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
지서버는 유휴 시 절전에 들어간다. 그동안 UI가 이를 "Offline"(빨강)으로만 보여줘서
고장난 것처럼 읽혔고, 실제로는 메시지를 보내면 자동으로 깨어나 정상 응답한다.
사용자가 붉은 표시를 보고 원인을 찾아 나선 뒤 발견했다.
- /api/status가 sleeping을 함께 반환한다. 게이트를 찔러 확인하지 않고 wake_url
설정 유무로 판별하는데, 상태 표시는 10초마다 갱신되고 게이트를 찌르는 행위가
곧 매직패킷 발사라 확인하러 가면 지서버를 영영 못 자게 만든다.
- 표시를 셋으로 분리: Online(초록) / 절전 중(노랑) / Offline(빨강).
노랑엔 "메시지를 보내면 자동으로 깨어납니다" 툴팁을 붙였다.
또한 설정에서 provider를 고르면 그 자리에서 깨우도록 했다. UI는 이미 선택 즉시
/api/models/test로 모델 목록을 가져오는데, 지서버가 자면 여기서 "모델 없음 —
서버가 실행 중인가요?"로 실패했다. 모델 선택은 쓰겠다는 의사가 분명하므로 이를
기상 트리거로 삼는다. 새 엔드포인트 없이 기존 동작에 얹었고, "자면 모델 목록이
빈다"는 문제도 같이 해결된다. 잠든 지서버로 실측 시 7초 만에 모델 5개를 받았고,
깨어있을 때는 0초로 통과해 불필요한 패킷을 보내지 않는다. wake_url이 없는
provider(클로서버 등)는 기존 동작 그대로다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
모델이 미세먼지 단위를 $\mu\text{g/m}^3$처럼 LaTeX로 쓴다. 단위는 수식이 아닌데
이 표기가 세 곳에서 깨진다: index.html은 KaTeX가 렌더하지만 복사하면 MathML까지
딸려와 "μ g/m 3 μg/m 3"처럼 중복돼 보이고, 나머지 채팅 페이지 8개(weather/doctor/
lawyer/detective 등)는 KaTeX 자체가 없어 생 LaTeX가 그대로 노출되며, TTS는
백슬래시를 소리 내어 읽는다.
단위만 담긴 수식 span만 유니코드로 바꾸고, 연산자·분수·변수가 있으면 그대로 둔다:
$\mu\text{g/m}^3$ → μg/m³ $\text{m/s}$ → m/s
$E = mc^2$ / $x + y$ / $\frac{a}{b}$ → 유지
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"지금 태풍 돌핀 어디 있지?"에 도구를 하나도 부르지 않고 좌표·기압·풍속을
단언했다(로그 12065행, TOOL 호출 0건). 같은 수치가 일주일 전 답변(9119행,
8월 2일)과 글자까지 동일해서, 검색이 아니라 대화 기억에서 나온 값임이 드러났다.
실제로는 돌핀이 이미 오키나와를 통과한 뒤였다.
가드 세 개가 전부 통과시켰다:
isLiveDataRequest false
isFactualInfoRequest false
looksLikeUnverifiedSpec false
- 입력측: 라이브 데이터 패턴이 날씨/기온/환율/주가뿐이라 태풍이 없었다.
태풍·호우·폭우·폭설·한파·폭염·지진·해일·산불·홍수·가뭄·열대저압부 추가.
- 출력측: 스펙 단위 목록이 GB/TFLOPS/원/% 계열뿐이라 hPa·m/s·위경도가 어디에도
없었다. 검증할 대상 자체를 못 본 것. 관측 단위(hPa/m/s/kt/km/h/mm/cm/℃)와
좌표(북위·동경 N.N°)를 추가했다.
관측 단위를 넣으면 정상 날씨 답변까지 되던질 위험이 있는데, 재검색 조건에
!hasGroundingToolCall이 있고 weather_가 grounding으로 인정되므로 도구로 받아온
31.5°C·2mm는 영향받지 않는다. 그 반대 방향을 테스트로 못박았다 — 이쪽이 깨지면
날씨 기능이 무한 재검색에 빠진다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"오늘 구미 미세먼지"에 포항 측정소(우현동/장흥동/장량동/대도동) 수치가 구미로
제시됐다. 지적 후 재시도했더니 이번엔 영주·경산 측정소를 구미라고 답했다.
원인은 실시간 대기질 API가 시/도 단위 목록만 주고 응답에 sidoName만 있다는 것.
측정소 이름에는 소속 시/군이 없어("우현동"은 포항, "중방동"은 경산) 모델이
도 전체 목록에서 임의로 골라 특정 도시 값으로 제시할 수밖에 없었다.
- 측정소정보 서비스(MsrstnInfoInqireSvc) 연동. 주소 필드로 시/군을 매칭해
해당 도시 측정소만 반환한다(구미 4곳, 포항 13곳 확인). 목록은 하루 캐시.
이 서비스는 data.go.kr에서 별도 활용신청이 필요하며 2026-08-09 승인됐다.
- 필터가 실패하면 필터된 척하지 않고 "필터 실패, 전체 표시"로 밝히고 경고를 남긴다.
- 실시간 조회 numOfRows 20 → 200. 경북만 53개 측정소라 20행에서는 포항이 잘려
도시 필터가 조용히 빈 결과를 냈다.
- 504 SERVICETIMEOUT에 4회 재시도 추가. 측정 결과 업스트림이 무작위로 실패하며
(연속 8회 중 7성공 / 8초 간격 6회 중 4성공) 호출 간격과 무관해 쿨다운이 아니다.
단발 호출이던 기존 코드는 그때마다 도구가 통째로 실패했다. 4xx는 재시도 안 함.
또한 6개 날씨 도구가 공유하던 "위치를 찾을 수 없습니다"를 실행 가능한 에러로
교체했다. 도시 비교 요청에 모델이 "London, Berlin, Paris, Rome, Madrid"처럼
묶어 넘기면 지오코딩이 실패하는데, 기존 메시지엔 고칠 방법이 없어 같은 인자로
무한 재시도했다. 이제 도시 목록과 재호출 예시, 재시도가 무의미함을 함께 알린다.
첫 두 조각이 각각 지오코딩될 때만 목록으로 판정하므로 "Seoul, Korea"·"London,GB"·
좌표는 영향받지 않는다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
handleChat()의 빈 응답 판정이 finalText.length < 5였다. 응답이 "없는 것"과
"짧은 것"을 뭉뚱그린 규칙이라, "2"·"네"·"서울" 같은 완결된 답변이 버려지고
"죄송합니다, 응답을 생성하지 못했습니다"로 대체됐다. 모델은 제대로 답했는데
사용자에게는 실패했다고 표시되는, 가장 눈에 띄는 형태의 실패였다.
진짜 신호는 길이가 아니라 문자/숫자의 유무다. sanitizeFinalReply()가 pptx
링크나 메타 문구를 걷어내면 구두점만 남을 수 있고, 폴백 메시지는 원래 그런
잔여물을 위한 것이다.
replyLooksEmpty()를 reply-content.ts로 분리했다(handle-chat.ts는 테스트에서
import가 불가능할 만큼 크다 — tool-scope/system-prompt를 빼낸 것과 같은 방향).
유니코드 property escape를 써서 모든 문자 체계를 커버하고, 덤으로 한글 뒤에서
\b가 매칭되지 않는 함정도 회피한다.
검증: 신규 테스트 10개 포함 180개 통과. 실제 채팅에서
1+1 → "2", 3x7 → "21", 수도 → "서울", 네/아니오 → "네." 정상 반환.
빈 문자열·공백·"..."·"**"·이모지만 있는 응답은 여전히 폴백 처리.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
지서버 트래픽이 전부 wol-gate(TrueNAS) 프록시를 거치고 있었다. 게이트는 자는
타깃에 HTTP 200 + "깨우는 중" HTML을 반환하는데, ollama 클라이언트가 그 HTML을
JSON.parse해서 "Unexpected token '<'"로 죽었다.
endpoint를 지서버 직결(192.168.0.8:11434)로 두고, wake_url을 새로 받아
게이트는 직결이 안 될 때만 쓴다.
- _isAwake(host): 200이어도 본문이 HTML이면 잠든 것으로 판정
- 깨어있으면 즉시 통과(fast path). 기존 코드는 매 호출마다 /api/tags를 찍고
무조건 5초를 기다린 뒤 재확인했다.
- 게이트를 초인종이 아니라 폴백 경로로 사용. 직결과 게이트를 같은 주기로 확인해
둘 중 되는 쪽으로 이번 호출을 넘긴다. 08-09 00:52 지서버는 살아있고 게이트는
정상 프록시 중인데 직결만 타임아웃인 상황이 실제로 관찰됐고, 직결만 폴링하면
작동하는 경로를 두고 90초를 버린 뒤 실패한다.
- getModelCtx()도 _activeHost를 따라가게 수정. 폴백 중에 num_ctx 계산용
/api/show만 따로 실패하는 것을 막는다.
wake_url이 없는 provider(클로서버 등)는 기존 동작 그대로다.
검증: 직결을 죽은 주소로 바꿔 강제 재현 → 게이트 경유로 정상 응답(33초),
로그에 routing via wol-gate 기록. 원복 후 직결 fast path 9초.
실제로 잠든 지서버에 채팅 → 23초 만에 기상 후 응답.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
게이지가 8192로 표시됐으나 지서버 gemma4:26b의 실제 값은 262144, 32배 차이.
원인이 세 겹이었다.
1. resolveNumCtx()의 _cachedNumCtx가 아무 키 없이 프로세스 수명 내내 유지됐다.
6곳에서 설정되는데 무효화하는 코드가 어디에도 없어, 모델/provider를 바꿔도
이전 값을 계속 반환했다(클로서버로 바꿨는데 지서버의 262k가 계속 보이던 증상).
→ (provider, models.primary, provider별 model, llm.num_ctx) 키에 연동
2. 활성 provider가 아니라 localhost:11434를 하드코딩해 조회했다.
provider가 ollama_local(지서버)일 때 클로서버 로컬 Ollama에 물어보니
"model not found" → 최후 폴백 8192로 떨어졌다.
→ activeOllamaEndpoint() 추가, /api/model-context의 per-model 조회에도 적용
3. 프론트엔드 _fetchAppCtxMax()가 페이지 로드 시 한 번만 조회했다.
→ force 인자 추가, 설정 저장 직후 재조회
검증: 게이지 8192 → 262144(지서버 실제값 일치), 반복 호출 5회 안정.
캐시 키는 모델 전환 시 무효화되고 설정 동일 시 적중.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
updateConfig()는 fire-and-forget이고 호출 지점이 41곳(대부분 HTTP 라우트)인데
saveConfig()가 평범한 writeFile을 써서, 두 저장이 겹치면 파일이 깨졌다.
writeFile은 truncate 후 청크 단위로 쓰기 때문에 짧은 쪽이 온전히 기록된 뒤
긴 쪽의 남은 청크가 자기 fd 오프셋에 덧붙어, 유효한 JSON 뒤에 "}}" 조각이
붙은 형태가 된다. 재현 시 200회 중 196회 손상, 실제 손상 파일과 꼬리 패턴 일치.
2026-08-08 밤부터 08-09 새벽까지 세 번 발생했다.
- temp 파일에 쓰고 fsync 후 rename (같은 파일시스템 내 원자적 교체)
- writeQueue 프라미스 체인으로 동시 저장 직렬화
- 파싱 실패 시 config.json.corrupt-<timestamp>로 백업.
DEFAULT_CONFIG 폴백 상태에서 updateConfig가 한 번만 돌아도 기본값이
파일을 덮어써 29개 섹션(NVR/collabora/email/telegram 등)이 영구 소실된다.
검증: 재현 테스트 196/200 → 0/200, 임시 파일 누수 없음.
라이브 API 동시 저장 6건에도 config 정상.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TCP 연결만 확인하면, 대상이 부팅 중이라 포트는 열렸지만 실제 서비스가
아직 요청을 못 받는 순간에도 "살아있다"고 오판해서 실제 프록시를
시도하다 자체 타임아웃으로 "Bad gateway: read ETIMEDOUT"를 반환하는
문제가 있었음(HTML 깨우는 페이지 대신 이 502가 나가면 호출부가 재시도
로직을 못 탐) — 지서버 wol-gate에서 실제로 반복 관측됨(2026-08-08).
실제 HTTP GET으로 응답을 받는지 확인하도록 바꿔서, 상태코드 상관없이
진짜 HTTP 응답이 와야만 "살아있다"고 판단하게 수정. 두 인스턴스(클로서버
8099, 지서버 8100) 모두 재빌드·재배포 후 정상 동작 확인.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
지서버처럼 wol-gate 프록시 뒤에 있는 Ollama 엔드포인트가 잠들어 있으면,
프록시가 실제 API 응답 대신 "깨우는 중..." HTML 페이지를 돌려주는데
ollama 클라이언트 라이브러리가 이걸 JSON으로 파싱하려다 매번
"Unexpected token '<'" 에러로 죽는 문제 발견(실제 채팅에서 반복 확인,
2026-08-08). chat/generate/chatStream 진입 시점에 /api/tags를 먼저
가볍게 찔러보고, HTML(깨우는 중) 응답이면 최대 90초까지 5초 간격으로
재시도 대기한 뒤 실제 호출을 진행하도록 수정 — 이미 깨어있는 경우엔
응답이 JSON이라 즉시 통과, 지연 거의 없음(실측 확인).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ollama /api/tags가 반환하는 순서(풀받은 순서 등)를 그대로 써서, 저장된
현재 모델(예: gemma4:31b-cloud)이 목록 중간에 있으면 드롭다운 열 때
엉뚱한 모델(예: nemotron)이 맨 위에 보여 실수로 클릭하기 쉬웠음
(2026-08-08 보고). 현재/저장된 값을 목록 맨 앞으로 옮겨서 선택값과
시각적 첫 항목이 항상 일치하도록 수정.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
기존 "ollama" provider(클로서버 localhost, 주로 *:cloud 모델용)는 그대로
두고, LAN의 다른 로컬 GPU 머신(지서버 등)을 가리키는 두 번째 독립 Ollama
provider "ollama_local"을 신설. OllamaAdapter가 id를 생성자 인자로 받게
바꿔서(기존 'ollama' 하드코딩 → 'ollama'|'ollama_local' 선택 가능) 두
인스턴스를 provider 캐시/설정에서 구분함. 설정화면에 "Ollama
(클로서버/클라우드)" / "Ollama (지서버/로컬)"로 라벨 분리, 엔드포인트·모델
입력 필드 추가.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
메인 채팅 모델이 web_search 원본 스니펫에서 구체적 수치를 못 찾고
"검색결과에 없음"으로 답하는 사례 발견(2026-08-08, 실제 대화에서 확인) —
같은 검색결과를 ollama_web_search로 재질의하면 정확히 찾아냈음. 원인은
검색엔진 차이가 아니라(둘 다 동일한 폴백체인 사용) ollama_web_search가
"이 결과만 근거로 답하라"는 좁고 집중된 프롬프트로 별도 모델 호출을
한 번 더 거치기 때문이었음 — 메인 모델은 긴 시스템프롬프트+대화이력
속에서 검색결과를 곁다리로 처리하다 보니 놓친 것으로 추정.
web_search에도 같은 패턴(executeWebSearchWithExtraction)을 적용 —
원본 검색결과는 그대로 유지(출처 인용용)하고 앞에 "[핵심 답변]" 추출
섹션을 붙임. 추출 실패/타임아웃(15초) 시 원본 결과만 반환해 기존 동작을
깨지 않도록 함. 실제 쿼리로 테스트 완료(Gemma 4 31B VRAM 요구사양 정확히
추출됨).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
voice.js는 "~"를 기호제거 정규식이 °C보다 먼저 먹어버려 앞쪽 숫자가
단위를 잃었고("28 섭씨 35도"), voice-call.js는 "~" 제거 자체가 없어서
숫자 한글변환 단계까지 물결표가 그대로 살아남았음. 두 파일 다 범위 전용
정규식을 °C/°F 처리보다 먼저 넣어서 "섭씨 28도에서 35도"로 자연스럽게
읽도록 수정.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
weather_map_screenshot 같은 도구의 stdout에는 "위 이미지에서 실제로 보이는
것만 설명하라" 같은 비전 모델 대상 지시문이 섞여 있는 경우가 있는데, 이걸
비전 없는 모델이 받으면 응답 안 된 명령으로 읽고 색상·좌표·아이콘 같은
시각적 디테일을 그럴듯하게 지어내는 문제가 있었음. 경로 힌트 뒤에 "이 모델은
이미지를 볼 수 없다"는 명시적 안내를 덧붙여 추측 대신 솔직히 모른다고
답하도록 함.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
KMA는 한국에 영향 줄 태풍만, NHC는 대서양/동태평양만 보여줘서 대만·필리핀·
괌·일본 근해에 있지만 아직 한국 영향권 밖인 태풍은 두 소스 모두에서 안 보임.
JMA(서태평양 전역 담당 지역특별기상센터)의 typhoon=all 지도를 캡처 대상에
추가해 그 사각지대를 메움.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
kimandClaude Opus 5