11 단계 밖에서 배워 넣기 — 계약 감사 · Hermes · 기록 재생
이 페이지 목차
목적만든 순서1 · 파이스 계약 목록과 실동작 감사 (9/3)2 · 토큰 예산 — 5시간 한도가 빨리 닳는 원인 셋 (9/3, 9/11)3 · Hermes Agent 적용 (9/10~9/11)4 · 가져오지 않은 것과 이유5 · 전 기능 점검 — 고장 9건 (9/11)6 · 관문이 글을 고쳐 쓰고 있었다 (9/11)7 · 기록 재생으로 정책을 시험했다 (9/16)8 · 이미지 생성 — 진짜 원인은 첨부가 디스크에 안 남은 것 (9/17)9 · 회의록이 안 되던 진짜 원인 — 소리를 안 남겼다 (9/17, 9/23)💡 설명함정과 배운 것출처뒷이야기 · 11 / 17단계 · 2026-09-03 ~ 09-17 (+ 09-23) · 갈래 밖에서 배운 것
이전 단계: 10 파이스의 두 번 이사 — PC → 맥북 → 맥미니 · 다음 단계: 12 SJ 메신저와 AI 비서 — 직원 모두의 창구
핵심 요약
| 항목 | 내용 |
|---|---|
| 이 단계에서 한 일 | 파이스가 "원했던 것과 실제로 돈 것"을 감사하고(9/3), 남이 만든 에이전트 Hermes Agent 를 11행 비교표로 견줘 좋은 것만 이식했다(9/10~9/11). 이식 뒤에는 전 기능을 실제로 불러 점검해 고장 9건을 고쳤고, 쌓인 작업 기록으로 정책을 시험해(9/16) 그럴듯한 아이디어 둘을 실행 없이 폐기했다. 이미지 생성과 회의록은 "진짜 원인이 엉뚱한 곳에 있었다"는 사례다. |
| 기간 | 2026-09-03 ~ 09-17 (+ 09-23 플랫폼 회의록 후일담) |
| 규모 | 9/3~9/17 커밋 131개(작성자 cwkim83 122 · PAIS 9). 그중 9/10~9/11 이틀이 62개(Hermes 관련 제목 26개). 들인 스킬 13개 · docs/Hermes-적용-로드맵.md 406줄(커밋 14개) · scripts/replay_worklog.py 88줄 |
| 다룬 도구 | Hermes Agent(NousResearch) · Dream-RSI · Gemini 이미지 · whisper.cpp · ffmpeg · Fable 5.1 |
| 결과 | 셀프체크 항목 79(9/3) → 106(9/11) → 165(10/8, PC 에서 직접 돌려 센 값 · 실패 3~4건은 이 PC 에 볼트가 없는 환경 때문으로 보임) · 실동작 점검 0 → 150항목 · 자동 플레이북 0개(9/11 고장) → 표식 든 파일 35개(10/8, 들인 13개 포함) · 관문 압축을 껐더니 토큰 13.1% 대가 · 기록 671건 재생으로 아이디어 2개 폐기 |
| 공개 범위 | 사내(로그인 뒤) — 🔒 항목(키 · 토큰 · 개인 사진 · 고객 자료)은 넣지 않음 |
한 줄 요약 — 남의 것을 가져올 때는 베끼지 않고 실측으로 견줬고, 그럴듯한 아이디어는 배포 전에 계산으로 죽였다. 쓰는 사람이 "구현했다"를 믿지 않고 "돈다"를 확인했다.
11단계 · 밖에서 배워 넣기 — 계약 감사 · Hermes · 기록 재생
목적
8월에 파이스는 빠르게 자랐다. 기능은 쌓였는데 "원했던 대로 도는가"를 아무도 세어 보지 않았다. 시연회(9/9)를 앞둔 9/3 에 신기능을 멈추고 감사부터 했다. 그 뒤로는 안에서 새로 만드는 대신 밖에서 먼저 만든 사례를 가져오고(Hermes), 가져오지 않을 것을 정하고, 아이디어는 쓰기 전에 기록으로 시험하는 방식을 익혔다.
만든 순서
1 · 파이스 계약 목록과 실동작 감사 (9/3)
crazy4eu(cwkim83)가 파이스에 원한 것을 육성으로 여섯 조로 정리했다. 클로드 코드처럼 작동할 것, 대화가 옵시디언에 색인·기록될 것, 결과물을 바로 내려받을 것, 에이전트형 대화 화면, 기억을 옵시디언에 저장해 같은 문맥을 유지할 것, 대화 압축(40개가 넘으면 요약 없이 잘라 버리던 것). 신기능은 시연회 전까지 동결하고 수리와 실동작 검증만 했다.
감사 결과 구조 진단이 나왔다. 설계나 두뇌의 잘못이 아니라 계약이 코드 밖(대화 속)에만 있어서 기능을 쌓을 때 회귀를 못 잡았다. 셀프체크 79항목 다수가 "코드 조각이 있는가"를 글자 찾기(grep)로 보는 검사라 기능이 실제로 도는지는 보지 않았다. 9/3 13:13~13:22 에 9분 사이 커밋 넷으로 메웠다. 계약 2번(일지를 볼트에도 기록)은 고쳤고(b91cb7d), 5번(기억 미러)과 6번(대화 압축)은 새로 만들었고(d1f6cdc · 054c78f), 서버를 띄워 둔 채 실제 기능을 왕복하는 --live 층을 셀프체크에 붙였다(f6284ca). 파일 내려받기 · 볼트 검색 · 대화 왕복을 실제로 부른다. 두뇌 오류 문구가 와도 실패로 센다. 문구가 왔다고 통과시키면 죽은 두뇌를 살아 있다고 보고하기 때문이다(PC 실측에서 실제로 그랬다).
그런데 "구현됨"으로 표시한 계약 6번이 일주일 죽어 있었다(9/3~9/10). 두 버그였다. 재요약 판단이 "밀려난 개수"끼리의 비교라 기록 상한 200개에서 160 으로 포화해 160-160>=10 이 영원히 거짓이었고, 9/3 이후 재요약이 0회였다. 또 로컬 모델(gemma)이 요약 대신 대화를 이어받아 답했고 그 답변문이 일주일간 매 턴 두뇌에 "이전 대화 요약"으로 주입됐다. 형식 지시가 대화보다 앞에 있어서였다. 12B 모델은 마지막에 본 32,000자에 반응한다. 지시를 대화 뒤로 옮긴 것만으로 풀렸다(65c64f9 · 677f855). 계약 4번(화면)은 같은 날 오후 사용자가 클로드 코드 화면과 나란히 놓고 보며 다시 짰다(669d78c).
2 · 토큰 예산 — 5시간 한도가 빨리 닳는 원인 셋 (9/3, 9/11)
같은 9/3 에 사용자가 두 번 지적했다. 한 건을 처리하는 데 5시간 한도의 13%를 썼다고. 이 저장소는 파일이 크고(app.js 1,700줄, tools.js 149KB) 화면 확인이 필요해서 생각 없이 일하면 한 건에 10%대가 사라진다. 원인과 규칙은 셋이다.
- 브라우저 스크린샷이 제일 비싸다. 장당 이미지 토큰이 든다. 화면 확인은 브라우저 도구(
javascript_tool)로 화면의 구조(DOM)와 실제 적용된 모양(computed style)을 글자로 뽑고, 스크린샷은 1~2장으로 마감한다. 단, 화면을 바꿨으면 실물 확인 없이 끝내지 않는다. 9/3 의 UI 버그 3연속이 그 대가였다. - 셀프체크 전체를 습관적으로 돌리지 않는다. 출력이 통째로 문맥에 들어온다. 바뀐 모듈의 셀프체크만 돌리고 전체는 커밋 직전 1회.
- 큰 파일은 통째로 읽지 않는다. 글자 찾기로 줄 번호를 찾고 그 부분만 읽는다.
이 규칙은 9/16 CLAUDE.md 의 "토큰" 절로 올라갔다(905f3d9). 9/11 에는 omniroute 사용 기록으로 더 큰 원인도 찾았다. 한 모델(opus-5)의 높음·매우 높음 노력 단계 호출이 전체 claude 호출의 65%, 입력 1.2억 토큰이었다. 계정 우선순위를 최후순위로 낮춘 본계정이 4계정 중 2위로 쓰이고 있었다. 부하가 몰리면 우선순위는 소용없다. 한도를 지키려면 우선순위를 낮출 게 아니라 그 계정을 꺼야 한다. 기본 모델과 폴백(안전 모델)이 둘 다 같은 모델이라 둘을 같이 내려야 했다. 헛다리도 적었다. 7일 98,213회로 보이던 연결 점검 호출은 로컬 핑이라 토큰이 0 이었다.
3 · Hermes Agent 적용 (9/10~9/11)
남이 먼저 만든 에이전트 Hermes Agent(NousResearch, MIT)를 조사해 docs/Hermes-적용-로드맵.md 에 정리했다. 쓴 것은 Claude(Fable 5.1)이고 문서 머리에는 crazy4eu(cwkim83)의 검토 대기로 적혀 있다. 11개 항목(두뇌 · 기억 · 배경 리뷰 · 스킬 · 세션 검색 · 스케줄 · 게이트웨이 · 터미널 · 보안 · 자기개선 · 배포)을 나란히 놓고 판정했다. 결론은 한 줄이다. Hermes 는 범용 몸통이 두껍고 파이스는 회사 전용 신경이 두껍다. 그래서 교체가 아니라 이식이다. 가져올 가치가 확실한 것은 넷이었다. 기억 관리 규율, 스킬 생명주기, 스킬 허브 접속, 세션 전문 검색(선택).
9/10 21:16 에 0단계를 반영했고(9727dc1), 9/11 16:53 에 "0~7단계 전부 완료"로 문서를 갱신했다(624be9b). 20시간이 안 걸렸다. 파이스 규칙 그대로 했다. 기존 함수를 재사용하고, 고치는 줄은 최소로(최소 diff), 셀프체크 하나를 꼭 달고, 위험한 것은 권한 등급 뒤에 둔다.
- 0단계: 도구 10회 누적이면 배경 리뷰(시간 간격만 보면 도구를 30번 쓴 무거운 세션을 놓친다) · 기억 병합(
consolidate, 같은 사실이 4~5개로 흩어지던 것) · 주입 차단(기억에 "이전 지시 무시" 류가 한 번 들어가면 매 턴 되살아난다, 패턴 8개) · 플레이북 자동 갱신(<!-- pais-auto -->표식이 없는 파일은 절대 안 고친다). - 2단계(9/11 09:17): 플레이북 원장과 되돌리기. 로드맵 명세를 고쳤다. 지문(sha)만으로는 복구가 안 되므로 이전 전문까지 남긴다(e24b708).
- 3단계와 7단계(09:26): 스킬 허브에서 SKILL.md 를 읽어 한국어 플레이북으로 번역해 들이는 도구
import_skill, 그리고 사설 주소로 나가지 못하게 하는 목적지 검문(SSRF 방어). 한쪽에만 걸면 절반이라fetch_url과import_skill양쪽에 걸었다(df1e7fd). - 6단계(09:49): 예약 결과를 폰 알림(ntfy) · 메일 · 캘린더로 보내는 분기(c8801e3).
- 4단계(13:31): 같은 질문의 두 번째는 색인을 안 뒤지는 회사 위키 층(9411e46). 5단계(16:50): 3주 전 작업을 낱말 하나로 찾는 세션 전문 검색(e82d191).
스킬 13개가 플레이북으로 들어왔다(문서 작성, 회의록 정리, 근거 인용 등). 10/8 현재 플레이북 폴더 46개 중 13개가 허브에서 온 것이고, 원장은 94줄이다.
4 · 가져오지 않은 것과 이유
가져오지 않는 판단도 같이 적었다. Hermes 본체 설치와 교체는 하지 않았다. 파이스의 차별점(회사 신경)을 다 다시 붙여야 한다. 메신저 게이트웨이도 안 가져왔다. 회사 자료가 외부 메신저로 새는 길이 된다. 두뇌를 여러 회사에 흩뿌리는 모델 라우팅과 외부 기억 서비스는 자료 통제가 안 돼서 뺐다. 기억이 곧 회사 정보라서다. 탈옥 스킬은 금지했다. 허브의 선택 스킬 3개(감시기 · 검색 · 코드 위키)는 쓸 자리가 정해지지 않아 넣지 않았다. 그리고 로드맵에서 "참고할 것"으로 적어 두고 하지 않은 보안 항목 넷(하드 차단 목록 · 보호 경로 · 자식 프로세스 환경 청소 · 도구 결과 주입 스캔)은 전 기능 점검에서 발견해 같은 날 넣었다(36e9a5a). 차단은 일부러 좁게 했다. 정상 작업 14종이 통과하는지 함께 시험하고, 옵션 순서가 달라도(-rf 와 -fr) 막는다.
5 · 전 기능 점검 — 고장 9건 (9/11)
이식을 끝낸 뒤 "모든 기능을 전부 다시 확인"했다. 셀프체크는 106항목이고, --live 는 서버를 띄운 채 150항목을 실제로 부른다(두뇌 3갈래 · 도구 16종 · 화면 API 9개 · 안전장치 · 명령 관문 6개 · 배달 · 플랫폼). 읽기만 하고, 안전장치는 막혀야 통과로 센다(e75e9f5). 고장 9건이 나왔고 전부 고쳤다.
- 자동 플레이북이 0개였다(커밋 제목은 "한 달째"). 0단계를 "관찰 중"으로 열어 둔 채였는데 관찰이 아니라 고장이었다. 도구 빚(누적 횟수)이 시간 발동에 지워져 문턱 10 에 영영 닿지 못했다(3b7dbd2).
- Ollama 기본 문맥 길이가 긴 입력을 조용히 잘랐다. 스킬 번역이 얇게 나와서 출력 상한을 올렸는데 안 늘었고, 입력 토큰 수를 보니 12,000자 문서에서 2,051 토큰만 읽고 있었다. 종료 사유는 정상(stop)이라 잘렸다는 표시가 안 난다. 문맥 길이를 프롬프트에 맞춰 올렸다(7961129).
- 그 수리가 만든 회귀 둘. 수리 직후 10,721자 호출이 60초 제한에서 끊겼고(813cc8f), 맥 16GB 에서 스왑(모자란 메모리를 디스크로 대신 쓰는 것)이 5GB 에 달해 문맥 상한을 32,768 → 16,384 로 내렸다(babf740).
- 하드 차단 목록 · 보호 경로 · 환경 청소 없음, 도구 결과 주입 스캔 없음(위 4번).
- 자동 플레이북 프롬프트가 천장을 넘을 위험(스킬 13개면 40KB, 시스템 문맥 천장 17,000자), 파이스가 "obsidian_list 도구가 없다"고 없는 사실을 보고한 것(통 안의 도구는 두뇌 눈에 안 보인다), 스킬 번역이 문장 중간에서 끝난 것을 아무도 몰랐던 것(71544cd).
6 · 관문이 글을 고쳐 쓰고 있었다 (9/11)
두뇌 관문(omniroute)의 압축이 긴 사용자 메시지를 자리표시자 한 줄로 바꿔치기했다. 모델은 [CCR retrieve hash=… chars=N] 만 받고, 되찾을 도구가 없으면 영구히 안 보인다. 증상은 "문서에 본문이 없다"는 엉뚱한 답이라 파이스 쪽 코드를 의심하게 만든다. 8/14 에도 같은 압축이 셀프체크 결과를 지웠다는 주석이 코드에 남아 있다. 9/11 에 이 엔진(CCR)을 껐고 사용자 메시지 천장이 약 900자에서 약 9,000자로 올랐다. 천장이 사라진 게 아니라 올라간 것이어서 긴 자료는 여전히 시스템 메시지에 넣고, 20,000자급 문서는 로컬 두뇌로 보낸다는 규칙을 남겼다.
그날 더 나쁜 것을 찾았다. 압축 엔진이 CCR 말고도 11개였고 그중 글을 고쳐 쓰는 것이 더 있었다. 라벨 이름 속 낱말이 사라져 두뇌에 도착했고, 두뇌는 "보이지 않는 특수문자가 섞인 듯하다"고 원인을 지어냈다. 두뇌의 잘못이 아니었다. 두뇌가 받은 이름(압축 뒤)과 실제 라벨 이름이 달랐다. 한국어 사용자 메시지는 영어 전신문으로 다시 쓰여 도착하기도 했다. 7개를 껐다. 대가는 토큰 13.1%(8,710건 1억7,417만 → 1억5,134만)다. 교훈은 하나다. 파이스가 설명할 수 없는 실패를 보고하면 모델을 의심하기 전에 관문이 글을 고쳐 쓰는지 먼저 본다. 시험은 도구 결과에 긴 고유명사를 심어 그대로 되읽히는지 보면 충분하고, 껐는지는 압축 계측의 비율이 1 인지로 확인한다.
7 · 기록 재생으로 정책을 시험했다 (9/16)
Dream-RSI 라는 논문에서 가져온 생각이다. 누적된 기록이 그 자체로 정확한 시뮬레이터라는 것. 결과가 이미 디스크에 있으니 "정책이 달랐다면?"이 예측이 아니라 계산이 된다. scripts/replay_worklog.py(88줄)가 작업 기록(work_log.jsonl)의 단계별 도구 호출과 성패를 다시 돌려 본다. 실행은 0회다. 한계도 분명하다. 안 가본 가지는 못 본다. 자를 수 있는 건 정지 지점과 순서뿐이다.
671건(토큰 16,846,794, 성공 668 · 중단 3)을 돌리자 이런 것이 보였다.
- 82%의 작업(550건)이 도구를 한 번도 안 부른다. 대화형 답이 주류다.
- 도구를 20번 이상 부른 작업 12건(1.8%)이 토큰의 43%를 쓴다.
- 도구 호출 919회 중 실패가 88회(9.6%), 실패에 쓴 토큰이 9.7%다. 실패율이 높은 도구는 라벨 붙이기(91.7%, 그날 하루의 사고로 이미 수리) · 파일 읽기(80%) · 문서 읽기(50%) · 파일 목록 보기(38.5%) · 볼트 노트 읽기(17.8%)였다.
그럴듯한 생각 둘이 계산으로 죽었다. ① "반복 상한(40)을 낮추면 토큰을 아낀다"는 손해다. 길게 끈 작업은 거의 다 성공작이어서(20~29회 100%, 30회 이상 100%) 상한을 20 으로 두면 167만 토큰을 아끼는 대신 성공 9건을 잃는다. 40 은 671건 중 1건에서만 걸린다. 낭비가 아니라 안전밸브다. ② "볼트 노트 읽기가 빗나가면 비슷한 이름 후보를 준다"는 값이 안 맞는다. 실제 볼트 6만 장으로 재생해 보니 빗나간 이유가 오타가 아니라 그 노트가 없어서였다. 8건 중 1건만 걸렸고 그마저 미심쩍은데 값은 실패할 때마다 볼트 전체를 도는 것이었다. 만들다 걷어냈다. 첫 판은 한 글자 파일 이름이 모든 질의에 걸려 후보가 쓰레기였고, 합성 볼트 셀프체크는 통과했다. 실제 볼트에서만 드러났다. 남은 것은 실측이 지지하는 한 가지, 실패했을 때 복구가 제각각이라 오류에 안내를 붙여 한 길(검색)로 모은 것이다(ad9ab12).
8 · 이미지 생성 — 진짜 원인은 첨부가 디스크에 안 남은 것 (9/17)
9/16 에 사진 한 장을 다른 그림체로 바꿔 달라고 했더니 파이스가 5번 시도하며 680만 토큰을 쓰고 실패했다. 작업 기록을 되짚어 원인 넷을 찾았다.
- 비상 두뇌가 가로챘다. 본두뇌가 끊긴 사이 로컬 모델이 답했고, 도구가 없으니 "기능이 없어서요", 시력이 약하니 사진 속 사람을 다른 것으로 봤다. 단계 0(도구 0회)인 작업 셋이 기록에 그대로 있다.
- 이미지 경로가 전부 막혀 있었다. 관문 모델표에 이미지 모델이 117개 뜨는데 하나씩 쏴 보니 그림이 나오는 건 0개였다. 목록에 있다고 되는 게 아니다.
- 첨부가 디스크에 안 남았다. 사진을 글자로 바꾼 꼴(base64)로 비전에만 넘기고 파일로는 쓰지 않아 두뇌가 홈 폴더를 뒤져 원본을 찾다 실패했다. 경로가 없으면 이미지 도구를 붙여도 먹일 게 없다. 가장 깊은 원인이었다.
- 환각(없는 것을 지어내 말하는 것). 마지막 답이 "이미 있는 키로 가겠다"였는데 그런 키는 없었다. 없는 걸 있다 하고 턴이 끝나 아무도 이어받지 않았다.
고친 것(15f2896). 첨부 이미지를 작업 폴더에 파일로도 저장하고 경로를 두뇌에 알려 준다. 구글 직결 이미지 생성 모듈 src/image.js(179줄)와 generate_image 도구를 새로 넣었다. 실패는 지어내지 않고 그대로 보고한다. 그날은 코드는 되는데 무료 할당량이 0 이었다(키 4개 × 모델 6종 = 24조합이 전부 429 한도 초과, 하루치이고 프로젝트 단위라 키를 더 넣어도 한 통을 나눠 쓴다).
9 · 회의록이 안 되던 진짜 원인 — 소리를 안 남겼다 (9/17, 9/23)
"회의록 녹음이 잘 안 된다"는 신고에 meeting.html 을 읽으니 결함이 셋이었고 뿌리는 같았다. 소리를 한 조각도 안 남겼다. 크롬 실시간 받아쓰기 하나에만 기대고 있었다.
- 되살리기가 조용히 죽었다.
onend직후 곧바로start()하면 오류가 나는데 그걸 삼키는catch {}때문에 화면은 "받아쓰는 중"인데 실제로는 죽어 있었다. 회의가 끝나서야 앞부분만 남은 걸 안다. - 화면이 꺼지면 멈췄다.
- 소리가 없으니 위 둘이 터지면 회의가 통째로 날아갔다.
이제 5초마다 소리를 조각내 담고, 끝나면 서버로 올려 로컬 위스퍼(whisper.cpp)가 처음부터 다시 받아쓴다. 실시간 받아쓰기는 보면서 확인하는 용도로 강등했다. 죽어도 회의는 산다(84ce5df). 위스퍼는 이미 깔려 있었다. 모델 1.6GB 가 8/26 부터 코드에서 불리지 않은 채 3주째 놀고 있었다. 맥미니 M4 실측 12.1배속(72.8초 → 6초), 1시간 회의가 약 5분이다. 폰이나 노트북에서 녹음한 파일을 올려도 받아쓴다. 작업하던 Claude 가 낸 버그 하나도 적어 둔다. 윈도우에서는 경로 구분자가 역슬래시라 "슬래시가 없으면 실행 파일 이름"이라는 판별이 절대 경로를 이름으로 오인해 없는 모델을 "있음"으로 보고했다. 9/16 이미지 건의 환각(없는 키를 있다고 함)과 같은 종류다.
9/23 에는 플랫폼의 회의록 AI 가 이미 7/20 모듈 첫 판부터 있었는데 한 번도 안 돌았다는 것을 찾았다. 두 겹으로 죽어 있었다. 회사 계정 확인 헤더를 안 붙였고, 호출 순서표의 모델 아홉 개가 하나도 돌지 않았다(폐기된 이름 · 결제 필요 · 거부). 눌러서 확인하니 회의 전사본 580자에서 주제 · 안건 4개 · 항목 12개 · 담당과 기한까지 나왔다(df69a88 · c0592fc). 요약을 새로 만들자고 시작했다가 코드를 보고 알았다. 짓기 전에 있는지부터 본다.
💡 설명
- 계약 목록: 사용자가 파이스에 원한 것을 조항으로 적어 둔 목록. 기능을 쌓을 때 이 목록이 깨지지 않았는지 본다.
- 셀프체크 ·
--live: 파이스가 스스로 돌리는 시험. 평소 시험은 코드 조각을 보고,--live는 서버를 띄운 채 실제로 불러 본다. - 회귀: 고쳤더니 다른 곳이 다시 고장 나는 것.
- Hermes Agent: 남이 만든 오픈소스 개인 비서. 이 단계에서 좋은 점만 가져온 대상.
- 플레이북: 파이스가 읽는 "이럴 땐 이렇게 하라"는 절차 노트. 사람 소유 파일은 자동으로 고치지 않는다.
- 스킬 허브: 남이 만든 절차(SKILL.md)를 모아 둔 곳. 읽어서 플레이북으로 번역해 들인다.
- 프롬프트 주입: 웹이나 메일 글에 "이전 지시를 무시해" 같은 문장을 숨겨 AI 를 조종하는 공격.
- SSRF: 서버가 내부 주소로 요청을 보내게 속이는 공격. 사설 주소를 막아서 방어한다.
- 압축 엔진(관문): 두뇌 앞의 관문이 글을 줄여 보내는 장치. 줄이다가 글을 바꾸면 실패의 원인이 된다.
- 기록 재생: 쌓인 작업 기록을 다시 돌려 "정책이 달랐다면?"을 실행 없이 계산하는 방법.
- 문맥 길이(num_ctx): 모델이 한 번에 읽을 수 있는 양. 기본값이 작으면 긴 글을 조용히 잘라 읽는다.
- 위스퍼(whisper.cpp): 소리를 글로 바꾸는 오픈소스 모델. 이 컴퓨터에서 돌려 회의 내용이 밖으로 안 나간다.
함정과 배운 것
- "구현됨"과 "돈다"는 다르다. 계약 6번은 구현됐다고 적은 채 7일 죽어 있었다. 실제 기능을 왕복하는 시험(
--live)이 있어야 잡힌다. - 두뇌가 설명할 수 없는 실패를 보고하면 모델을 의심하기 전에 관문이 글을 고쳐 쓰는지 본다. 긴 고유명사를 심어 되읽히는지로 시험한다.
- "관찰 중"이라고 열어 둔 것이 고장일 수 있다. 자동 플레이북이 0개였다(커밋 제목은 "한 달째").
- 모델이 조용히 잘라 읽는다. 종료 사유가 정상이라 표가 안 난다. 읽은 입력 토큰 수를 직접 본다.
- 수리가 회귀를 만든다. 문맥을 올린 수리가 60초 제한과 5GB 스왑을 불렀다. 고친 뒤 한 번 더 돌려 본다.
- 합성 데이터 시험은 통과하고 실제 자료에서만 드러난다. 볼트를 건드리는 매칭은 실물로 시험한다.
- 그럴듯한 아이디어는 코드를 쓰기 전에 기록으로 시험한다. 이번에는 둘 다 죽었고, 하나는 만들다 걷어냈다.
- 없는 것을 있다고 말하는 환각이 두 번 나왔다(없는 키, 없는 모델 경로). 목록에 있다고 되는 게 아니다. 직접 쏴 본다.
- 첨부가 디스크에 안 남으면 도구를 붙여도 먹일 게 없다. 가장 깊은 원인은 도구가 아니라 입력이었다.
- 짓기 전에 있는지부터 본다. 회의록 AI 는 만들 게 아니라 고칠 것이었다.
출처
커밋 b91cb7d · d1f6cdc · 054c78f · f6284ca · 65c64f9 · 677f855 · 669d78c · 905f3d9 · 9727dc1 · 5479d61 · e24b708 · df1e7fd · c8801e3 · 9411e46 · e82d191 · 624be9b · e75e9f5 · 3b7dbd2 · 7961129 · 813cc8f · babf740 · 71544cd · 36e9a5a · ad9ab12 · 15f2896 · 84ce5df(pais_project) · df69a88 · c0592fc(플랫폼 저장소). 문서: docs/Hermes-적용-로드맵.md · scripts/replay_worklog.py · CLAUDE.md 토큰 절. 기억 노트: pais-contract · pais-token-budget · pais-replay-policy · pais-image-gen · pais-meeting-notes.
← 10 파이스의 두 번 이사 — PC → 맥북 → 맥미니 · 12 SJ 메신저와 AI 비서 — 직원 모두의 창구 →