확장을 비활성화하는 올바른 방법과 캐시 적중 0%의 진짜 원인

26년 07월 18일

165개 세션에서 0번 발동한 가드

이날은 “쓸모없어진 코드를 어떻게 검증하고 폐기하는가”를 정리한 날이다.

그리고 캐시 적중률이 0%인 원인을 찾다가 세 가지 가설이 전부 틀린 것도 경험했다.

진짜 원인은 라우팅이었다.

루프 감지 가드 확장이 있었다.

에이전트가 같은 도구를 반복 호출하는 루프를 막는 거다.

임계값을 3회에서 10회로 올렸다.

그리고 165개 세션을 전부 스캔했다.

발동 횟수: 0회. 67.5메가바이트의 세션 기록에서 한 번도 발동하지 않았다.

이건 “가드가 필요 없다”는 증거다.

근데 그냥 지우면 안 된다.

“발동 안 했다”가 “필요 없다”는 아니다.

모델이 업그레이드되면서 루프 자체가 안 생기는 걸 수도 있다.

폐기 4단계 방법

그래서 폐기 방법을 4단계로 정리했다.

첫째, 정찰 에이전트한테 메커니즘이랑 문제 상황을 조사시킨다.

둘째, 전체 세션 기록에서 실제 발동을 스캔한다.

이때 소스 코드의 리터럴이 아니라, 런타임에서만 나오는 마커로 찾아야 한다.

소스 코드에 적힌 문자열은 에이전트가 자기 소스를 읽으면서 발생한 위양성이기 때문이다.

셋째, 위양성을 실제 발동에서 분리한다.

에이전트가 자기 소스를 읽으면서 도구 결과에 마커가 나오는 건 실제 발동이 아니다.

넷째, 0회 발동에 도구식 이유가 있으면 폐기한다.

근데 삭제가 아니라 보관한다.

“더 이상 필요 없다”는 판단이 틀릴 수 있으니까, 1~2개월 후 재평가 창을 둔다.

Pi 확장 비활성화의 올바른 방법

Pi는 파일시스템 자동 발견으로 확장을 찾는다.

레지스트리가 없다.

확장 디렉토리를 밖으로 옮기면, 컴파일/패키지/런타임 세 단계가 한 번에 끊긴다.

disable 플래그가 필요 없다.

복구는 한 번의 mv면 된다.

캐시 적중 0%의 진짜 원인

법원경매 서비스에서 DeepSeek 모델의 캐시 적중률이 0%였다.

비용을 5배 더 쓰고 있었다.

세 가지 가설을 세웠다.

첫째, 프롬프트 접두사가 너무 짧아서. 둘째, 캐시 만료 시간 때문에.

셋째, 라우팅 키가 달라서. 전부 틀렸다.

진짜 원인: 라우팅

실제 요청이 공식 DeepSeek이 아니라 StreamLake(47.5%)랑 GMICloud(30.1%)로 분산되고 있었다.

하나의 프로바이더에 요청이 집중하지 않으니까, 캐시가 따뜻해지지 않았다.

분산 + 폴백 때문에 어떤 샤드도 캐시를 쌓지 못한 거다.

프롬프트 접두사가 짧은 게 아니었다.

만료 시간 문제도 아니었다.

라우팅 키도 맞았다.

그냥 라우팅이 요청을 분산시키고 있었다.

올바른 해결

프로바이더 우선순위 설정을 리스트로 쓴다.

“이 프로바이더만 써라”가 아니라 “이 순서로 시도하되, 첫 번째가 안 되면 다음으로”다.

정상 상황에서는 전부 첫 번째 프로바이더로 수렴한다.

캐시가 따뜻해진다.

장애 때만 다음으로 넘어간다.

“하나만 고정하면 캐시가 따뜻해지지만 단일 실패 지점이 된다.” “여러 개 쓰면 가용성은 좋지만 캐시가 안 따뜻해진다.” 이 딜레마를 우선순위 리스트로 해결한다.

정상일 때는 집중, 장애일 때만 분산.

야후 파이낸스 종가 필드를 잘못 읽었다

야후 파이낸스의 범위 시작점 종가 필드를 “전 거래일 종가”로 읽었다.

근데 이건 “조회 범위 시작점의 종가”였다.

이걸 잘못 읽어서 “금요일 하루 -9.98% 폭락”이라고 보고했다.

근데 실제는 일주일 누적 -7.1%였다.

금요일 단일일 하락은 -1.6%였다.

사용자가 정정했다.

“토요일인데 미국 장이 열리지도 않았는데?” 이 한마디로 잘못을 발견했다.

정확한 계산은 마지막 종가 vs 이전 종가로 단일일을 구하고 야후 파이낸스의 범위 시작점 종가 필드는 누적 범위 계산에만 쓴다.

API 문서를 안 읽고 필드 이름으로 추론한 결과였다.

마무리

이날의 핵심은 “가설이 틀릴 수 있다”였다.

확장 폐기에서 “발동 안 했다”를 “필요 없다”로 단정하면 위험하다.

실제로 165개 세션을 스캔하고 위양성을 분리하고 도구식 이유를 확인해야 한다.

캐시 적중 0%에서 세 가지 가설을 세웠다.

전부 틀렸다.

진짜 원인은 라우팅이었다.

가설을 세우되, 데이터로 검증하지 않으면 틀린 가설로 수정하는 데 시간을 낭비한다.

그리고 야후 파이낸스의 범위 시작점 종가 필드를 필드 이름으로 추론했다.

“이전 종가”라니까 “전 거래일 종가”라고 생각했다.

근데 다른 뜻이었다.

API 문서를 읽지 않고 추론한 결과, 잘못된 보고가 나왔다.

가설은 출발점이다.

가설을 세우고 데이터로 검증하고 틀리면 버린다.

가설에 집착하지 마라. 데이터가 가설을 거부하면, 가설을 버려라.