06 단계 두뇌 관문 — omniroute · 9router · 사용량 절감

뒷이야기 · 6 / 17단계 · 2026-08-09 ~ 08-20 (+ 09-08 · 09-10 · 09-11) · 갈래 파이스
이전 단계: 05 파이스 탄생 — 닷새 만에 뼈대와 안전망 · 다음 단계: 07 계산 도구 — pvcalc 와 DWSIM

핵심 요약

한 줄 요약 — 한도가 빨리 닳은 원인은 입력 크기가 아니라 모델 선택과 캐시가 안 걸리는 호출 방식이었다. 그리고 "고쳤다"고 적은 날에도 직접 재기 전까지 캐시는 0% 였다.

6단계 · 두뇌 관문

목적

파이스는 스스로 생각하지 않고 모델(두뇌)을 불러 쓴다. 모델 하나에 직접 붙으면 그 모델이 막히는 순간 파이스도 멈춘다. 그래서 모델 앞에 '관문'을 두었다. 관문은 여러 모델·계정을 하나의 주소로 묶어, 한 계정의 한도가 차면 다음 계정이나 모델로 넘긴다. 이 단계는 그 관문을 쓰고, 관문이 죽는 날을 겪고, 모델을 부르는 값을 줄인 기록이다.

만든 순서

1 · 관문이 무엇인가 (8/2 ~ 8/14)

8/2 11:16 첫 커밋부터 파이스는 모델을 직접 부르지 않았다. 'OpenAI 호환 /v1 주소' 하나로 부르는 구조였고, 그 주소는 9router(여러 공급자를 묶는 라우터)의 것이었다. 설정의 기본 주소에는 공개 터널(안의 컴퓨터를 바깥 주소로 내보내는 통로) 주소가 들어 있었다.

8/13 16:14 코드에 omniroute 의 콤보 이름(brain · code · review · research · vision · quick)이 처음 나온다. 콤보는 관문 안의 이름표다. 그 이름으로 부르면 관문이 미리 짜 둔 순서대로 모델·계정을 시도한다. 같은 날 부서가 동시에 일하는 delegate 도구를 넣으면서 콤보 6종을 다시 짰다. 감독·기획은 한도가 빡빡한 fable-5, 일반 작업은 opus-5, 간단한 일은 가벼운 모델이다. 1순위를 전부 다른 계정 묶음으로 갈라, 6개 부서가 동시에 불러도 첫 요청부터 경쟁이 없게 했다. 재편 전에는 세 콤보가 같은 계정 묶음을 동시에 물고 있었다.

8/14 소스 압축본 옆에 놓인 두뇌 설정 방법 문서가 둘을 이렇게 견준다. omniroute 는 여러 공급자를 하나의 OpenAI 호환 주소로 묶고 자동 폴백을 지원하는 로컬 라우터로 '권장'이다. 한 계정이 한도에 걸려도 다음 계정이나 공급자로 넘어간다. 9router 는 같은 개념의 다중 공급자 라우터다.

바깥에서 쓸 때는 회사 도메인의 서브도메인 하나를 거친다. 터널이 /v1 만 열고 나머지(관리 화면)는 일부러 404 로 둔다.

2 · 관문이 죽은 아침, 첫 비상 길 (8/13)

8/13 아침 관문 쪽이 530 오류(터널 너머 서버가 답하지 않을 때 Cloudflare 가 내는 오류)로 죽자 예약 작업이 통째로, 아무 알림 없이 실패했다. 08:48 에 첫 비상 길이 들어갔다. 관문이 죽으면 Gemini(키 4개를 돌려 가며)로 자동 전환한다. Gemini 는 관문을 거치지 않고 구글로 직행한다. 무료 한도는 키마다 따로여서 한도 오류(429)면 다음 키로 넘긴다. 44분 뒤인 09:32 에는 비상용 기본 모델을 gemini-3.6-flash 로 바꿨다(도구 호출 200 확인).

같은 날 14:36 에 이 비상 길의 첫 사고를 재구성해 고쳤다. Claude 한도가 소진돼 관문이 실패하면 사슬이 Gemini 로 넘어간다. 그런데 Gemini 3 는 이력의 도구 호출 조각마다 자기가 서명한 값(thought_signature)을 요구하고, Claude 가 만든 도구 이력에는 그게 없어 400 이 났다. 사슬은 400 을 "넘기면 안 되는 오류"로 분류해 그 자리에서 죽었고, 원문 오류가 대화창에 그대로 떴다. 수리는 두 겹이다. Gemini 로 보낼 때만 지난 도구 호출·결과를 글로 풀어 보낸다. 이 400 은 요청 문제가 아니라 공급자 궁합 문제로 다시 분류해 다음으로 넘긴다. 같은 작업에서 두뇌 주소를 공개 터널에서 같은 컴퓨터의 로컬 포트로 바꿔 530 의 뿌리도 없앴다고 커밋 메시지에 적혀 있다(설정 파일은 저장소 밖이라 코드 변경에는 없고 메시지에만 남았다).

배운 것은 비상 길이 한 번도 안 써 본 길이라는 점이다. "다른 모델이 만든 도구 이력을 이어받는 일"은 비상 길에서만 일어나서 평소에는 안 보인다.

3 · 한도가 빨리 닳던 원인을 갈랐다 (8/16)

사람이 "예약 하나가 5시간 한도의 7%를 먹었다"고 짚었다(8/16 실측). 비용은 턴 수 × 한 요청(약 12,000토큰)이다. 40턴이면 한 작업이 48만 토큰이다.

01:28 에 실측으로 원인을 갈랐다. 입력은 범인이 아니었다. 도구 53개(5,006토큰)와 시스템문이 매 턴 다시 가지만, 캐시(앞에서 한 번 읽은 입력을 싸게 다시 쓰는 장치)가 걸리면 새로 내는 건 1%뿐이다(5턴 49,407 중 378). 진짜 원인은 콤보였다. brain 콤보가 부를 때마다 다른 모델을 골랐는데, 그중에 한도가 빡빡한 fable-5 와 생각 토큰을 잔뜩 뱉는 모델이 섞여 있었다. 같은 물음을 재면 이랬다.

체감 소모는 출력 × 5 + 새로 낸 입력이다(scripts/usage.mjs 가 쓰는 식).

다만 이 PC 의 사용 기록(8/16 09:25 부터)에는 채택한 sonnet-5-low 호출이 한 줄도 없다. 본 작업은 opus-5-medium, 8/17 저녁부터는 opus-5-high 였다. 왜 바뀌었는지는 확인 못 함. 그래서 아래 6번의 결과는 모델 선택이 아니라 캐시 쪽 효과다.

같은 날 이어진 수리가 넷이다.

• 캐시 표시 사고 (01:37). Claude 는 캐시 표시(cache_control)를 4개까지만 받는데, 매 턴 다른 메시지에 붙여 표시가 쌓였다. 5턴째에 400 "Found 5"로 두뇌 호출이 통째로 실패했다. 표시를 도구 목록 끝과 시스템문 두 곳으로 고정했다.
• 연장통 (08:11). 도구 53개가 매 턴 5,006토큰으로 한 요청의 42% 였다. 처음엔 낱말로 골라 주려 했는데 사람이 짚었다. 그러면 두뇌가 판단할 여지가 없다. 그래서 연장통 이름만 보여 주고 두뇌가 load_tools 로 직접 열게 했다. 처음 목록은 늘 쓰는 14개와 load_tools 15개로 5,006 → 1,579토큰(68% 감소)이다.
• 턴 한도 (08:13). 한 작업 최대 턴을 40 → 20 으로 줄였다.
• 사용량 기록 (08:19). 화면에는 "이 창 누적"만 나와 하루 총량을 알 길이 없었다. 부를 때마다 한 줄(시각·모델·입력·캐시로 읽음·출력·새로 낸 입력)을 파일에 남기고 집계 스크립트를 붙였다.

4 · 스트리밍에서는 캐시가 안 걸린다, 그리고 재지 않은 하루 (8/16 08:39 ~ 8/17 01:54)

08:39 에 같은 요청을 두 방식으로 재니 갈렸다. 비스트리밍(답을 다 받은 뒤 한 번에)은 1차 캐시 0, 2차 12,419 였다. 스트리밍(글자가 오는 대로)은 두 번 다 0 이었다. 파이스는 실시간 타이핑 때문에 늘 스트리밍이었다. 그래서 예약 작업은 비스트리밍으로 바꿨다. 09:26 에는 대화도 비스트리밍으로 바꾸면서 최대 턴을 20 → 30 으로 올렸다. 비스트리밍이면 턴당 새 입력이 200 남짓이라 30턴이 옛 20턴보다 싸다는 계산이었다. 잃는 건 타이핑 애니메이션뿐이다.

그런데 이튿날 01:54, 사람이 "사용량이 여전히 많다"고 해서 기록을 열어 보니 캐시가 전부 0 이었다. 두 곳에서 막혀 있었다. 작업 실행 함수의 기본값(stream = true)이 대화 쪽 기본값(false)을 덮어썼다. 예약 시작 함수는 넘겨받은 인자를 버려서 { stream: false } 가 사라졌다. 커밋 메시지는 어제 고쳐 놓고 실측을 안 했다고 적었다.

이 PC 의 사용 기록으로 확인했다. 8/17 01:21~01:33 의 63호출은 모두 캐시 0 이었다. 첫 캐시 호출은 01:53:42(입력 13,622 중 12,235)이고, 3초·7초 뒤의 두 호출까지 세 호출의 입력·캐시 값이 커밋 메시지의 실측 세 줄과 같았다. 커밋 시각은 그 40초 뒤다.

5 · 사용량 절감 5단계 (8/17)

8/17 08:31 과 08:39 의 커밋 둘에 5단계가 담겼다.

1. 연장통 잠금. 도구 목록은 요청 맨 앞에 실려서, 앞이 바뀌면 캐시가 통째로 깨진다. 같은 대화를 도구 15개로 두 번 보내면 2차에 캐시 읽음이 8,428 이고, 22개로 늘리면 0 이었다. load_tools 를 부를 때마다 도구 스키마 340토큰을 아끼려고 쌓인 대화 23,400토큰을 다시 내고 있었다. 대화가 40,000자 아래일 때만 통을 열 수 있게 하고, 두뇌에게 "첫 수에 필요한 통을 한 번에 다 열라"고 안내했다.
2. 부서에 읽기 도구. 부서는 글로만 답해서 "찾아봐"를 맡길 수 없었고, 감독이 혼자 31번을 돌았다(질문 하나에 484,100토큰). 부서 안에 작은 도구 루프(최대 8번)를 넣어, 부서가 자기 콤보·작은 통으로 돌고 결론만 돌려주게 했다. 그 토큰은 Claude 한도 밖으로 나간다. 부서 1순위에는 무료·경량 모델이 앉으므로 읽기 전용 도구만 준다.
3. 조직도 도구 칸. 부서가 쓸 도구를 볼트의 부서조직도 표에서 한글 별명(볼트검색·문서읽기·웹검색…)으로 정한다.
4. 끊긴 작업 발자국. 서버가 죽으면 작업이 사라지고 남는 건 "다시 말씀해 주세요" 한 줄뿐이었다. 도구 발자국을 파일에 남겨 다음 부팅에 "여기까지 했어요: …"로 알린다. 자동 재실행은 하지 않는다. 끊긴 지점의 도구를 또 부르면 이미 쓴 파일을 또 쓰기 때문이다.
5. 자기수정 검증 확대. 파이스가 자기 코드를 고칠 때 시험(selftest)을 .js 일 때만 돌렸다. 시험 안에 index.html 인코딩 붕괴 검사가 있는데 정작 html 을 고칠 때는 안 돌았다. 이제 파일 종류를 안 가린다.

같은 날 곁가지로 둘을 잡았다. 하나는 .gitignore 다. 줄 끝에 주석을 달면 패턴이 주석까지 통째로 되어 아무것도 막지 못한다. 그 때문에 키가 든 .env 백업 하나가 비공개 저장소에 올라가 있었다. 주석을 제 줄로 옮기고 추적을 풀었다. 다른 하나는 시험이 운영 기록을 오염시킨 것이다. 시험이 일부러 없는 부서를 불러 "실패"가 쌓였고, 부서 성적표 기록 28줄 중 26줄이 시험 자국이었다.

6 · 직접 센 결과 (8/16 ~ 8/20)

이 PC 의 사용 기록(1,532줄)을 시각별로 다시 세었다. 8/21 이후 기록은 이 PC 에 남아 있던 두 번째 파이스의 것이라 뺐다.

두 작업의 모델은 같다(opus-5-medium). 호출당 체감 소모는 16,402 → 1,442 로 11.4배 줄었고, 41호출 작업 전체의 체감은 59,138 이다.

다만 큰 몫은 5단계가 아니라 4번의 캐시 수리(8/17 01:54)였다. 캐시가 켜진 01:53:42 부터 5단계 커밋(08:31) 전까지 88호출이 이미 95.5%(호출당 새 입력 439)였다. 5단계만의 몫은 이 기록으로 가를 수 없다.

날마다 보면 캐시 비율이 8/16 14.5% → 8/17 66.6% → 8/18 90.2% → 8/19 73.7% → 8/20 93.0% 로 올랐다. 작업마다는 달랐다. 8/17 저녁의 92호출 작업(opus-5-high 47 · research 41 등이 섞임)은 76.2%, 호출당 새 입력 1,786 이었다. 하루 평균이 90% 대여도 작업 하나는 낮을 수 있다.

기억 노트에 적힌 기준선(캐시 42% · 호출당 새 입력 5,958 · 출력 277)은 같은 값으로 재현되지 않았다. 가장 가까운 것은 기록 첫 줄(8/16 09:25)부터 5단계 커밋 직전(8/17 08:29)까지의 누적 194호출이다(42.4% · 5,980 · 276). 이 누적에는 캐시 0% 구간과 캐시가 켜진 뒤 95.5% 구간이 섞여 있다. 그래서 기준선은 '고치기 전 작업 하나'의 값이 아니라 그때까지의 누적 평균으로 보인다(추정 — 노트에 센 범위가 적혀 있지 않다). 수리 전 상태로는 위 표의 0% 쪽이 맞다.

7 · 포트가 막혀 둘이 같이 죽은 날 (8/18)

8/18 관문(omniroute)과 9router 가 동시에 죽었다. 로그의 오류는 listen EACCES: permission denied(포트를 열 권한이 없다)였다. 그런데 그 포트는 아무도 쓰지 않고 있었다.

원인 사슬은 기억 노트에 이렇게 남아 있다. 예전에 포트 고갈을 고치려고 윈도우의 동적 포트 범위를 10000번부터 넓혔다. WSL·도커가 뜨면 그 범위 안에서 100포트 단위로 블록을 예약해 간다. 그날은 20124~20223 이 잡혀 두 서비스가 갇혔다. 예약을 풀려면 관리자 권한이 필요하다. 해결은 포트를 10000 아래로 옮기는 것이었다(관문 9130, 도커의 9router 9128).

같은 날 화면의 거짓말도 드러났다. 상태판은 "9router 두뇌 LIVE"를 키가 있는지만 보고 있었다. 그래서 관문이 죽었는데도 LIVE 로 보여 원인을 늦게 찾았다. 14:28 에 상태판이 관문·9router·Ollama 를 실제로 찔러 보게 고쳤다(응답만 있으면 401·404 도 '살아있다'로 센다). 실측은 관문 401/37ms · 9router 200/47ms · Ollama 200/12ms 였다.

같은 날 사람이 관문을 도커 화면에서 보고 싶어 했다. 직접 시험해 보고 접었다. 관문은 설계상 같은 컴퓨터에서만 듣고 --host 옵션이 없어 컨테이너로 옮기면 포트 중계기가 필요하고, 저장 파일(storage.sqlite)을 호스트와 나눠 쓸 수 없고, OAuth 재로그인이 브라우저 기반이라 컨테이너 안에서 못 한다. 얻는 건 초록 점 하나뿐이라 값이 안 맞았다. 대신 파이스 화면에서 보이게 했다.

8 · 로컬 모델을 두뇌 갈래로, 비상 사슬 (8/18 ~ 8/20)

8/18 14:37 모델 이름이 ollama/ 로 시작하면 이 컴퓨터(Ollama)에서 도는 갈래를 붙였다. Ollama 의 OpenAI 호환 창구로 부르면 사고형 모델이 토큰을 전부 속생각에 써서 본문이 빈 문자열로 나왔다(num_predict 80 이 전부 생각으로 소진). 그래서 네이티브 창구로 think:false 를 줘서 부른다. 로컬은 폴백 사슬을 타지 않는다. 조용히 클라우드로 새면 "로컬인 줄 알았는데 한도가 닳는" 일이 되기 때문이다. 첫 적용은 '다음에 할 말 제안'이다. 제안이 나오는데 사용 기록에 Claude 호출이 늘지 않았다.

8/19 로컬 처리를 다른 기기(맥북)로 넘길 수 있게 했다. 이 PC 의 그래픽카드(그래픽 메모리 VRAM 8GB)는 절벽처럼 끊겼다. 30B 모델을 올리니 대부분 CPU 로 밀려 초당 3.8토큰, 이미지 한 장에 141초였다. M4 는 통합 메모리(CPU 와 GPU 가 같이 쓰는 메모리)라 그 절벽이 없다. 임베딩(글을 숫자 벡터로 바꾸는 의미 색인)은 건당 PC 131ms → 맥 114ms 였다. 8/20 15:45 에는 로컬 주소를 여러 개 적고 먼저 답하는 쪽을 쓰게 했다. 맥북 주소가 하루 세 번 바뀌었기 때문이다.

8/20 21:40~21:45 에 비상 사슬을 주력 → 로컬 → Gemini 로 정하고 자가치유를 붙였다. 인터넷이 끊기거나 클라우드가 전멸하거나 재시작 틈새에서 유일하게 사는 길이 로컬이다. 로컬 비상 두뇌는 도구를 못 쓰지만 말은 한다. 비상 두뇌의 덕목은 똑똑함이 아니라 살아있음이다. 소방 훈련으로 관문을 멈추니 로컬 비상 두뇌 배지와 함께 응답이 왔고, 관문을 되살리자 복구됐다. 자가치유는 주력이 무응답이면 로컬이 대타로 답하면서 동시에 관문을 걷어차 살린다. 걷어차는 건 연결 거부·5xx(서버 쪽 오류)·시간 초과에만, 5분에 한 번이다. 401·429(키·한도)는 재시작이 약이 아니라서 안 걷어찬다.

9 · 관문도 이사했다 (8/20)

PC 에서 돌던 관문과 9router 를 8/20 에 맥북으로 옮겼다(이사 전체는 10단계). 관문과 관련된 것만 적는다.

• PC 의 백업(85MB)을 맥에 복원하자 "복호화 오류 205개 · 전 공급자 Invalid API key"가 났다. 화면에는 연결이 보이는데 호출은 전부 실패하는, 원인 찾기 가장 어려운 꼴이다. 설정 파일의 첫 줄에 윈도우가 붙인 BOM(눈에 안 보이는 3바이트)이 있어 암호 해제 키 이름이 '없는 것'이 된 것이었다. 3바이트를 떼서 진짜 환경변수로 넘기게 했다. 키가 같은지는 값을 찍지 않고 지문(sha256 앞 16자)으로 PC 와 맥을 대조했다.
• 결과: 공급자 36개 중 35개 모델 동기화 성공 · 복호화 오류 0. 9router 를 맥에서 상시로 띄워 붙이니 동기화가 36/37 이 됐다.
• PC 의 관문은 내렸고 자동 시작도 껐다. 다시 켜면 안 된다. OAuth 토큰이 돌려 쓰는 방식이라 두 대가 같은 계정을 갱신하면 서로 죽인다. 맥의 Claude 계정 4개가 전부 오류였던 원인이 그것이었다.
• 파이스의 두뇌 주소를 맥으로 돌렸다(터널 → 파이스 → 맥 → 두뇌 3.6초). 바깥 주소의 DNS(이름을 실제 주소로 바꿔 주는 장부)도 맥 터널로 옮겼다. 맥 터널만 끄면 530, 되살리면 200 이었다.
• 9router 키가 맥의 설정 파일 안에 평문으로 있던 것을 찾아, 키를 폐기하고 PC·맥 양쪽 9router 저장소에서 키를 비웠다. 죽은 문자열만 남았다. 같은 날 상태판의 9router 포트도 맥 기준(20128)으로 고쳤다.

10 · 뒷일 — 새 모델, 막힌 계정, 이름 (9/8 ~ 9/11)

• Fable 5.1 (9/8). 새 모델은 클라이언트 버전이 2.1.251 이상이어야 했는데, 관문이 모델 서버에 알리는 버전 숫자(2.1.219)가 낡아 400 으로 거절당했다. 관문에 덮어쓸 설정이 없어 실행 파일 속 상수를 올렸다(백업을 두고). 관문을 업그레이드하면 패치가 사라지니 그때 다시 해야 한다. 같은 날 파이스 화면에 Fable 5.1 · 최대(max) 노력 선택이 붙었다.
• 막힌 계정 (9/10 사고). 화면에서 Fable 5.1 을 골라 둔 채 밤이 지나자, 관문의 Claude 계정 4개 중 2개는 토큰이 만료됐고 나머지 2개는 Fable 5.1 권한이 없었다. 429 "Usage credits are required" 가 나서 예약 작업이 전부 로컬 비상 두뇌 답으로 나갔다. 고른 모델이 막히면 로컬로 떨어지기 전에 '안전모델'로 한 번 더 시도하게 고쳤다.
• 기본 모델 내리기 (9/11). 관문 사용 기록에서 opus-5 high·xhigh 가 Claude 호출의 65%, 입력 1.2억 토큰이었다(기억 노트 값). 파이스 일감 대부분은 메일 분류·색인·요약이라 그 등급이 필요 없다. 기본 모델만 내리면 안전모델에서 다시 opus 로 올라가므로 둘을 함께 sonnet-5 로 내렸다.
• 이름 바로잡기 (9/11). 맥 이사 뒤 관문은 omniroute 인데 코드·화면·오류 문구가 계속 9router 라고 말하고 있었다. 그날 "9router 오류 400"이라 뜬 것도 실은 omniroute 가 낸 400 이었다(응답 헤더로 확인). 라벨·문구를 모두 바꾸고, 진짜 9router(20128)를 가리키는 곳만 남겼다. 기본 주소도 죽은 옛 터널 주소에서 같은 컴퓨터의 3000번으로 고쳤다.
• 관문이 글을 고쳐 쓴다 (9/11). 관문의 압축 엔진이 라벨 이름의 " 제작 및" 을 지운 채 보내서, 파이스가 "보이지 않는 특수문자가 섞인 듯"이라고 원인을 지어냈다. 모델 잘못이 아니었다. 글을 다시 쓰거나 낱말을 버리는 엔진 7개를 껐다. 대가는 토큰 13.1%(8,710건 1억7,417만 → 1억5,134만)다. 껐는지는 압축 기록의 비율(ratio)이 1 이면 확인된다.

💡 설명

• 두뇌 관문(라우터): 파이스와 여러 AI 모델 사이에 서서, 한 주소로 받아 알맞은 모델·계정으로 보내는 중계 프로그램.
• omniroute · 9router: 둘 다 여러 AI 공급자를 한 주소로 묶는 관문 프로그램. 이 기록에서 파이스가 부르는 쪽이 omniroute, 그 밑의 공급자 하나로 붙는 쪽이 9router 다.
• 콤보: 관문 안의 이름표 하나. 이 이름으로 부르면 미리 짜 둔 모델·계정 순서대로 시도한다.
• 공급자: 모델을 실제로 돌려 주는 쪽(Claude·Gemini 등)이나 계정 묶음.
• 폴백(fallback): 원래 길이 안 될 때 대신 가는 길. 비상 사슬은 그 길을 줄 세운 것이다.
• 프롬프트 캐시: 앞에서 한 번 보낸 같은 입력을 다시 보낼 때 싸게 읽어 오는 장치. 요청의 앞부분이 그대로여야 걸린다.
• 스트리밍: 답이 만들어지는 대로 글자를 흘려보내는 방식. 이 기록의 관문에서는 스트리밍 요청에 캐시가 걸리지 않았다.
• 연장통(도구 목록): 모델에게 보여 주는 도구 목록. 요청 맨 앞에 실려서 바뀌면 캐시가 깨진다.
• 체감 소모: 한도에서 닳는 정도를 어림하는 식. 출력 × 5 + 새로 낸 입력.
• OAuth: 비밀번호 대신 로그인 허가를 받아 쓰는 방식. 토큰이 돌려 쓰는 방식이면 같은 계정을 두 곳에서 갱신하지 못한다.
• Ollama(로컬 모델): 인터넷 없이 이 컴퓨터에서 AI 모델을 돌리는 프로그램.
• EACCES: 프로그램이 포트(통신 문)를 열 권한이 없다는 오류. 포트가 비어 있어도 윈도우가 예약해 두면 난다.

함정과 배운 것

• 고쳤다고 쓰기 전에 잰다. "비스트리밍으로 캐시를 얻는다"고 고쳐 놓고 실측을 안 해 하루 동안 캐시가 0% 였다.
• 기본값을 바꾸면 호출하는 쪽이 덮어쓰지 않는지까지 본다. 기본값 하나와 버려진 인자 하나가 캐시를 막고 있었다.
• 한도는 입력 크기가 아니라 모델 선택과 호출 방식에서 닳는다. 도구 5,006토큰이 매 턴 가도 캐시가 걸리면 1%였다. 콤보가 한도 빡빡한 모델을 고르던 것이 진짜 원인이었다.
• 도구 목록은 요청 맨 앞이라, 바꾸면 쌓인 대화까지 다시 낸다. 연장통을 열 때마다 캐시가 깨졌다.
• 상태판이 '키가 있는지'만 보면 거짓 LIVE 다. 실제로 찔러 봐야 한다.
• 포트가 비었는데 EACCES 면 윈도우 예약을 의심한다. 포트를 동적 범위(10000번 이상) 밖으로 옮겨 피했다.
• 비상 길은 실제로 한 번 태워 본다. 다른 모델의 도구 이력에서 400 이 나는 것은 비상 길에서만 보인다.
• 백업을 복원했는데 전부 실패하면 설정 파일 첫 줄의 BOM 을 의심한다. 화면에는 연결이 보이고 호출만 전부 실패한다.
• 돌려 쓰는 OAuth 계정은 한 대만 갱신한다. 옛 PC 의 관문을 다시 켜면 서로 죽인다.
• 관문을 업그레이드하면 실행 파일에 가한 패치가 사라진다.
• 설명할 수 없는 실패가 나오면 모델을 의심하기 전에 관문이 글을 고쳐 쓰는지 본다. 긴 고유명사를 도구 결과에 심어 그대로 되읽히는지 보면 된다.
• 코드가 옛 이름으로 말하면 디버깅이 엉뚱한 곳으로 간다. "9router 오류"가 omniroute 의 오류였다.
• 계정 우선순위는 '최후순위' 보장이 아니다. 본 계정이 우선순위 4인데도 4계정 중 2위로 쓰였다(9/11 실측, 기억 노트 값). 막으려면 우선순위가 아니라 비활성화다.
• 포트 9128 을 잡은 프로세스는 9router 가 아니라 WSL 중계(wslrelay)였다고 기억 노트에 적혀 있다. 왜 그렇게 보였는지는 확인 못 함.

출처

파이스 저장소: 84a6aa0 · 2c1e279 · 7d9ece7 · 6fcf821 · e2845e0 · ed48a3e · a95520c · 69125cd · fe07805 · 81dcc7c · ab07a2c · db3d926 · 61077ed · 2b48efc · ac6b408 · 94259f2 · 67b3af3 · 54bdaa8 · e8fb815 · 7d60965 · 5bb7d1f · 53b52b0 · 4fdd58a · 23bb13b · 732a360 · 2fc6c81 · 726ee96 · 2e71e65 · 6639601 · 18a5add · ab4fce2, docs/Hermes-적용-로드맵.md ⑪, 소스 압축본 옆 두뇌 설정 방법 문서.
기억 노트: pais-ports · mac-server-setup · pais-5step-plan · pais-token-budget · pais-contract.

← 05 파이스 탄생 — 닷새 만에 뼈대와 안전망 · 07 계산 도구 — pvcalc 와 DWSIM →