Fable Week - 3 Day · cross-repo digest · 2026-07-05
하루에 저장소 6곳, 커밋 124번 — 다른 AI의 결함 찾기가 하루를 끝맺었다
Fable Week 3일차는 프로젝트 하나만의 이야기가 아니다. 여기서 '레포'는 코드 저장소(프로젝트 단위)를, '커밋'은 코드 변경을 저장한 한 번의 기록을 뜻한다. 2026-07-05 하루에저장소 6곳에서 커밋 124개가 나왔다. 저장소 이름과 그날 커밋 수는 이렇다 —memory-bank 51 · claude-code-site 40 · cc-sync 14 ·
memory-bank-cloud 8 · teamclaude 6 · hux 5— 6곳이 전부 다른 문제를 풀었다:
에러를 걸러 내는 검문소, 3D 카드로 넘겨 보는 자료실 화면, 과거 데이터 다시 채우기, 기억(메모리)에 악성 지시가 섞이는 공격 막기, 여러 계정으로 나눠 쓸 때의 재시도 로직, 에이전트가 지킬 행동 규칙 문서.
그런데6곳을 관통하는 줄기 하나가 있었다 — 6곳 모두에서 똑같이,다른 회사 AI(GPT)에게 내 코드를 일부러 트집 잡게 해 결함을 찾는 '적대 리뷰'를 결함이 더 안 나올 때까지 라운드마다 돌려 마무리했다.
memory-bank는 에러 분류가 무한 반복에 빠지던 문제를 19~25번째 검토 라운드에 걸쳐, cloud는 악성 주입을 막는 경계의 구멍을 '높음(HIGH)' 등급 2건으로, site는 눈으로는 멀쩡한데 클릭이 안 먹던 화면 버그를 잡았다.
하루 전체를 관통한 규율은"다른 AI의 검증을 통과하지 못하면 실제 배포도 없다"는 한 문장이었다.
앞선 fable-week-audit 글이 '계정 8개로 하루에 얼마나 만들었나'를 다뤘다면, 3일차는그 하루 산출물을 저장소별로 하나씩 뜯어본기록이다.
커밋 수는 코드 이력 관리 도구(git)의 기록을 직접 센 값이고(2026-07-05 0시~24시), 내용은 각 저장소의 커밋 메시지를 근거로 했다. 부풀리지 않고실제로 한 일만 적는다.
memory-bank에러를 걸러 내는 검문소를 19~25번째 라운드에 걸쳐 완성51 commits
저장된 기억을 꺼내 쓰는 통로의 검문소가에러를 잘못 분류해, 끝없이 재시도하며 멈추거나(무한 멈춤) 데이터가 조용히 사라지던(누수)문제를 적대 리뷰 19~25번째 라운드에 걸쳐 뿌리째 해결했다 — 핵심은 에러를세 갈래로 나눈 것이다: 확실히 거절된 것(재시도 안 함) / 권한·설정 문제라 보류 / 서버 일시 장애라 보류.
라운드별로 보면 — 20번째: 권한 거부 응답(401·403·404)을 조용한 누수 대신 명시적 '보류'로 처리 · 22번째: 에러 메시지 안에 우연히 들어간 숫자를 등급으로 오해하지 않게 교정 · 24번째: '건너뛰기'는 확실히 거절된 경우에만 허용 · 25번째: 라이브러리가 겹겹이 감싼 응답 상태 코드까지 꺼내 읽기(error.response.status)
결과 — 변경 기록(CHANGELOG) 1.3.2 버전에 '에러 분류 최종 완성(세 갈래 + 건너뛰기는 확실한 거절에만)'으로 남았다. 검문소가 자기 결함을 라운드마다 좁혀 스스로 막았다
claude-code-site메인 화면(index)을 3D로 넘겨 보는 자료실로 다시 설계40 commits
가만히 있던 문서 목록을손으로 넘겨 보고(스크럽) 눌러서 여는, 유리처럼 비치는 3D 카드 묶음으로바꿨다. 메인 화면 코드는 3,012줄에서 1,334줄로 줄었고,디자인 방향을 네 번 갈아엎었다(빛 알갱이 배경 → 실물처럼 쌓기 → 대각선 카드 덱 → 유리 질감)
적대 리뷰가 잡아 낸 화면 버그들 — 마우스 입력을 붙잡아 두는 기능(setPointerCapture) 탓에 클릭이 죽던 문제 · 이미 지나간 카드가 화면 앞뒤 순서(z-index) 때문에 클릭을 가로채던 문제 · 반쯤 넘긴 카드의 키보드 초점이 어긋나던 문제 · 목록 분류를 조회할 때 공용 객체가 오염되던 문제. 그리고 지금 보는 이 3일차 페이지 자체도 새로 만들어 등록했다
공개 완료 — 이 글 맨 위hugh.kim자료실 첫 화면이 그 결과물이다. 검색 기능 테스트 17개 모두 이상 없음 · 브라우저 오류 로그 0건
cc-sync트렌드 수집기(Trend Harvester) 153번째 실행 + 6월치 소급 재분석14 commits
trend-harvester 과거 데이터를 소급 처리하는 모드 신설+ 수집원 최신화 + 시스템의 빈틈에 맞춘 우선순위 정리 ·153번째 수집(6월치 소급 재분석 — 지식 메모 5건 추가) · 평가 기준과 설명 길이 규칙 개정
다른 AI(Codex, GPT 계열)의 적대 리뷰가 '중간(MEDIUM)' 등급 2건을 지적했다 —에러 메시지도 외부 입력이라 그대로 믿으면 안 된다는 것(악성 지시가 숨어들 수 있는 표면) · 텍스트 검색(grep) 검문소가무조건 통과시키지 않도록예외 규칙 정비 · 자동 동기화 4회
memory-bank-cloud여러 작업을 넘나드는 기억 꺼내 쓰기 + 주입 공격 방어8 commits
사실 검색 함수(search-facts)와, 사용자가 입력할 때 관련 기억을 끼워 넣는 장치(UserPromptSubmit hook)로 기억을 꺼내 쓰는 통로를 완성했다 · 끼워 넣는 정보의 품질을 거르는 검문소 + 분량 예산 관리(서버와 데이터 호출을 나란히 맞춤)
Codex의 '높음(HIGH)' 등급 2건— 주입되는 텍스트를믿을 수 없는 입력으로 취급하도록 고침(어느 프로젝트 것인지 URL로 고정) · 문장 중간에 심어진 가짜 표식 무력화 · 범위 설정(includeScopes)은fail-closed — 즉 설정이 잘못되면 열어 두지 않고 주입을 아예 멈추는 안전 차단 · 이 보안 규칙이 깨지지 않는지 검사하는 테스트를 영구 보관
기억이 프롬프트에 끼어드는 통로는 그 자체가 공격 통로가 된다(악성 지시 주입). 그래서 꺼내 쓰기 기능을 완성하는 것과 동시에, 믿을 수 있는 경계를 단단히 조였다
teamclaude여러 계정 묶음의 '다시 시도까지 대기 시간'을 정확하게 계산6 commits
한 계정이속도 제한(스로틀)과 사용량 한도 소진에 동시에 걸리면둘 중 더 늦게 풀리는 시각max(throttle, quota reset)까지 기다린다 · 토큰(글자 수)과 요청 횟수 한도를따로따로 추적· 멀쩡한 계정이 하나라도 있으면 묶음 전체의 대기를 짧게 끊어 준다
모든 계정이 막혔을 때의 대기 시간을, Max 요금제의 통합 한도가5h/7d reset 즉 5시간·7일 주기로 풀리는 시점에 맞춰 정확히 계산 · 버전 1.1.1
계정 8개를 한꺼번에 굴릴 때(fable-week-audit에서 다룬 그 계정들)의 대기 로직이다 — 한도가 언제 풀리는지 정확히 모르면 묶음 전체가 쓸데없이 놀며 기다린다
hux작업 감시 틀(하네스)의 기본 행동 규칙 문서 신설 (스스로 권한 못 갖게)5 commits
작업 감시 틀(하네스, AI가 제멋대로 하지 못하게 규칙을 강제하는 뼈대)의미션 헌장(지켜야 할 기본 규칙 문서)을 새로 만들었다 —authority-neutral, 즉 에이전트가 스스로에게 권한을 주지 못하게 했다(자기에게 코드 저장 권한을 부여하거나 검문을 건너뛰는 절차 제거) · 비밀번호·신뢰 경계 문제는 사람에게 올리도록 명시 · '지금은 되니까'식 시간 의존 권한 서술 제거
리뷰의 '중간(MEDIUM)' 등급 지적 반영 — '지금 시점' 기준의 진행 로그 표현을 누그러뜨림 · 코드 저장·업로드(commit·push) 권한의 우선순위를 규칙 파일(AGENTS.md)을 기준으로 기록
에이전트가 스스로 권한을 만들어 갖지 못하게 한다 — 규칙 문서가 권한을 중립으로 묶는다(진짜 통제는 AI가 손댈 수 없는 바깥 계층에 둔다는 원칙)
The Through-Line
하루를 관통한 줄기 — 저장소 6곳이 같은 규율로 끝맺다
저장소 6곳은 서로 다른 문제를 풀었지만규율 하나를 공유했다 —다른 회사 AI(GPT-5.5)에게 내 코드를 트집 잡게 하는 '적대 리뷰'를 검토 라운드마다 돌려, 치명(CRITICAL)·높음(HIGH) 결함이 0이 될 때까지 멈추지 않고 좁힌 뒤에야 실제 배포.중간에 '계속할까요?'라고 묻지 않고, 결함이 다 없어지거나(수렴) 시도할 방법을 다 써 버릴 때까지(소진) 밀어붙인다. 아래는 오늘 각 저장소에서 적대 리뷰가 실제로 잡아 낸 것들이다.
저장소 6곳이 저마다 다른 결함을 냈지만, 전부 '다른 AI의 적대 리뷰'라는 같은 검문소를 통과해야만 배포됐다 — 하루를 관통한 줄기
Two Deep Cuts
대표 사례 둘 — 검문소가 스스로를 고친 하루
커밋 124개를 다 펼칠 수는 없으니, 오늘의 성격을 가장 잘 보여 주는 두 사례만 깊게 본다.
하나는검문소가 자기 결함을 라운드마다 좁혀 고친memory-bank, 다른 하나는사람 눈으로는 놓칠 화면 버그를 잡아 낸 claude-code-site다.
저장소 · 라운드
적대 리뷰가 잡아 낸 것
근본 해결
memory-bank R19
에러 종류를 안 나눔 — 일시 장애와 확정 실패를 뭉뚱그려 무한 재시도로 멈춤
에러를 세 갈래로 나눠 일시 장애와 확정 실패를 확실히 구분
memory-bank R20
권한 거부 응답(401·403·404)이 조용히 사라짐
권한·설정 에러를명시적으로 '보류'로 처리(조용한 누수 방지)
memory-bank R23~R25
에러 메시지 속 우연한 숫자를 오해 · '건너뛰기' 남용 · 겹겹이 감싼 응답 코드 못 읽음
진짜 마우스 클릭이 안 먹음 — 입력을 붙잡는 기능(setPointerCapture)이 클릭을 엉뚱한 상위 요소로 넘김
붙잡기를 '끌기로 인정되는 순간'까지 미룸 · 진짜 사용자 입력으로 재확인
site · HIGH
지나갔거나 떠 있는 카드가 앞뒤 순서(z-index) 탓에 클릭을 가로챔
초점 카드는 항상 맨 앞 · 지나간 카드는 흐리게+클릭 잠금
cloud · HIGH×2
주입 텍스트가 아무 검증 없이 프롬프트에 흘러듦(주입 공격 표면)
믿을 수 없는 입력으로 명시 · 문장 속 가짜 표식 무력화 · 의심스러우면 차단(fail-closed)
공통점 — 어느 것도 결함을 숨기거나 빈 껍데기로 만들어 회피하지 않았다(회피 0건). 기준값 정합·세 갈래 분류·신뢰 경계로 원인 자체를 없앴다. '검문소가 통과시켰다고 안전한 건 아니다'를 저장소마다 실제로 보여 줬다
Why It Holds
왜 이걸 '작업 감시 틀(하네스)'이라 하나 — 저장소 6곳, 하나의 순환 고리
1일차 주제가 '사람의 판단을 시스템으로 굳히기', 2일차가 '1년치 일을 하루에'였다면, 3일차는그 규율이 한 저장소가 아니라 6곳에서 동시에 성립했다.
다룬 분야는 전부 달랐다(에러 분류·화면·트렌드·기억 보안·계정 묶음·규칙 헌장) — 그런데 완료 기준은 하나였다:다른 AI의 검증 통과.
01
검문소가 통과시켰다고 안전한 건 아니다
memory-bank 검문소는 자기 에러 분류를 25번째 라운드까지 고쳤다 — 검사하는 쪽도 검사받아야 한다
02
화면 캡처만으로는 검증이 아니다
site의 '보기엔 멀쩡한데 클릭이 안 먹던' 버그는 다른 AI 검증으로만 잡혔다 — 실제로 눌러 보는 테스트라야 통과로 인정한다
03
기억을 꺼내 쓰는 통로 = 공격 통로
cloud는 기억 주입 기능을 완성하면서 동시에 악성 주입을 막는 신뢰 경계를 단단히 했다 — 편의와 보안을 한 번의 저장에 함께 담았다
04
진짜 권한 통제는 AI 바깥에
hux 헌장은 에이전트가 스스로에게 권한 주는 것을 없앴다 — 진짜 검문소는 말(프롬프트)이 아니라 규칙 문서와 자동 실행 장치(hook)다
Stage & Remaining
어디까지 도달했고, 무엇이 남았나
도달한 것 — 저장소 6곳 전부적대 리뷰에서 치명·높음 결함 0으로 실제 배포했다. 아직 못 한 것은 숨기지 않고 정직하게 남겨 둔다.
저장소 6곳 배포까지 도달, 관통 줄기 입증. 실제 기기·실제 운영·장기 검증은 에뮬레이터·한 번뿐인 테스트라는 한계로 아직 미검증(not_verified) — 숨기지 않고 남긴다
"저장소 6곳이 저마다 다른 문제를 풀었지만, 완료 기준은 하나였다 — 다른 AI의 적대 검증 통과."
3일차의 진짜 결과물은 커밋 124개가 아니라,규율 하나가 여러 분야에서 동시에 통한다는 증거다.
에러 분류든, 화면 조작이든, 기억 주입 보안이든 — 검문소가 통과시킬 때까지, 그리고 검문소 자신에게 결함이 있으면 그것까지 고치면서
끝까지 좁혔다. 1일차가 '판단을 시스템으로', 2일차가 '1년을 하루에'였다면, 3일차는'그 시스템이 한 저장소가 아니라 작업 틀 전체에서 작동한다'는 하루치 증거다.