Compact 전 체크포인트

왜 있는가

compact은 이번 세션의 원문 맥락을 요약본으로 대체한다. 문서·스킬에 적어두지
않은 것은 요약을 거치며 흐려지거나 사라진다. [[progress-log]]가 "새 정보가
들어오면 요청 없이 바로 갱신하라"는 원칙이라면, 이 스킬은 그 원칙이 가장
크게 걸리는 순간을 짚어준다 — compact 직전이다.

"compact 진행할게요"는 요청이 아니라 예고다. 예고를 듣고도 다음 응답에서
바로 반영하지 않으면, 사용자가 /compact를 실제로 실행한 뒤에는 이번 세션에서
있었던 논의의 결도 압축된 요약으로만 남는다. 예고를 받은 그 턴에 처리한다.

발동 시점

사용자 메시지에 compact 예고가 있으면, 다른 요청이 함께 있어도 이것부터 한다.
예고만 있고 다른 지시가 없어도 발동한다 — 확인을 기다리지 않는다.

절차

1. 이번 세션에서 반영되지 않은 것을 추린다

• 결정된 것 (사용자가 확정한 방향, 뒤집힌 계획)
• 정정된 것 (틀렸다고 밝혀진 이전 판단 — 내 것이든 남의 것이든)
• 새로 만들었거나 검증한 스킬/도구
• 아직 답을 못 받은 질문 (다음 세션이 이어받아야 할 것)
• 막혔던 것 · 기다린 것 — 무엇에 왜 얼마나 멈췄는지 한 줄씩만
• 🔴 "남기겠다·기록하겠다" 고 말한 것이 실제로 반영됐나 — 약속은 대화에만 있다가 compact 에서 사라진다

⚠️ 마지막 항목은 기록만 하고 분석하지 않는다. 압축 직전의 우선순위는 기록 보존이고,
병목은 여러 세션을 모아야 보인다. 여기 남긴 한 줄들이 나중에 [[bottleneck-review]] 의
재료가 된다. 압축 시점에 분석을 시작하지 마라 — 이 스킬이 "다른 요청이 함께 있어도
이것부터" 인 이유가 사라진다.

이번 세션이 건드린 저장소·폴더를 전부 세어 본다. 작업이 여러 곳에 걸쳐 있으면
한 프로젝트 문서만 보고는 빠진 것을 알 수 없다.

# 오늘 커밋이 있는 저장소를 훑는다
for r in <저장소들>; do git -C "$r" log --oneline --since="<오늘>"; done

⚠️ 커밋 로그가 남아 있어도 그것으로 대신하지 않는다. 커밋에는 무엇을 바꿨는지가
남지만 "왜 그렇게 갈랐는가" 는 메시지마다 흩어져 복원되지 않는다. 그 판단이
진행 문서에 있어야 다음 세션이 이어받는다.

2. 작업 문서를 갱신한다 — [[progress-log]]

프로젝트에 프로젝트_진행상황_결정사항.md 류의 진행 문서가 있으면 그 규칙대로
새 절을 추가한다. 없으면 그 프로젝트에 맞는 합당한 위치(README, 작업내역 등)에
남기되, 아무 데도 안 남기는 것보다는 스크래치 노트에라도 남기는 편이 낫다.

승인은 필요 없다([[progress-log]]의 예외 규정과 동일 — 진행상황·작업내역·스킬
갱신은 사전 허가 없이 바로 기록한다).

3. 스킬을 갱신한다

이번 세션에서 만들었거나 고친 스킬이 있으면 이력 절이 최신 사용을 반영하는지
확인한다. 세션 중 있었던 시행착오(함정, 실패했던 접근, 정정된 판단)가 스킬 본문에
아직 없으면 지금 넣는다 — 다음 세션이 같은 시행착오를 반복하지 않게.

4. 증거를 붙여 응답한다

무엇을 어디에 반영했는지, 파일 경로와 함께 간결하게 알린다. 방금 쓴 내용을
다시 요약하지 않는다 — 어디에 뭘 추가했는지만 밝히면 된다. 사용자는 그 다음
/compact를 진행하면 된다.

하지 않는 것

• 이번 세션 전체를 요약해서 보여주지 않는다 — 그건 compact 자체가 할 일이다
• 아직 결정 안 된 것을 임의로 결정해서 적지 않는다 — "확인 필요"로 남긴다
• 이미 문서화된 내용을 중복해서 다시 쓰지 않는다

연계

• 실제 문서 갱신 규칙은 [[progress-log]]
• 검증되지 않은 주장을 적지 않도록 **[[work-review]]**의 "증거로 대조" 원칙을
  이 갱신에도 적용한다 — 방금 만든 스킬이나 도구를 "완료"라고 적기 전에
  실제로 동작 확인이 됐는지 스스로 되짚는다.

이력 (필수 기록)

• 생성일: 2026-08-27
• 업데이트 횟수: 3
• 최근 업데이트: 2026-09-15 (절차 1단계에 약속 반영 점검 추가)
• 사용 이력:
  • 2026-09-15 (회의 당일, 9/11~9/15 여러 날 세션) — 말만 하고 안 남긴 것을 여기서 잡았다.
    9/14 Codex 조사가 read-only 샌드박스로 휘발됐을 때 관리자는 스킬에 남기겠다고 했지만
    남기지 않았고, 사고를 낸 문구가 codex-delegate 본문에 그대로 있었다. 진행 문서를
    키워드로 grep 해 보다가 드러났다(PoC/R&D 판단·구글독스 업로드 대기도 같은 식으로 누락).
    → 1단계에 "남기겠다고 말한 것이 반영됐나" 를 넣었다.
    → 세션이 여러 날에 걸치면 진행 문서 맨 위 블록이 며칠 전 상태를 가리킨다. 회의 당일이면
    안건별 준비 상태를 새 블록으로 올리고, 무효가 된 수치(축소 전 배치값)엔 주석을 단다.
  • 2026-09-10 (프로세스 정비 세션) — 작업 대상이 프로젝트가 아니라 작업 방식 자체였다.
    산출물이 코드가 아니라 규칙·스킬·문서여서 무엇을 정했고 무엇이 미조치인지 흐려지기 쉽다.
    진단 문서에 영역별 상태(완료/미착수)를 표로 박는 것으로 처리했다.
    🔴 압축 직전 Codex stop-review-gate 가 세션 종료를 막았다. 지적 2건 중 1건은 정당했고
    (문서만 고쳐 놓고 "작동한다"고 보고할 뻔했다) 1건은 틀렸다(설정값 오독).
    게이트가 압축 전 마지막 방어선으로 작동했고, 동시에 재검증이 필요하다는 것도 보여줬다.
    ⚠️ 이 스킬 파일을 다른 복제 세션이 같은 날 이미 갱신해 두었다. 덮어쓰지 않고 덧붙였다 —
    세션을 복제해 쓸 때는 공유 파일 갱신 전에 현재 내용을 먼저 읽어야 한다.
  • 2026-09-10 — 다섯 번째 적용. 기록할 곳이 이 세션의 작업 저장소가 아니었다.
    사용자가 별도 경로를 지정했는데 그곳은 다른 세션이 쓰는 워크스페이스였고,
    이미 자기 규약(진입 문서·메모리 색인·스킬 폴더)을 갖고 있었다.
    → 남의 규약을 먼저 읽고 그 형식(날짜별 세션 절, 결정 번호 체계)에 맞춰 append 만 했다.
    기존 절을 고쳐 쓰지 않고, 대신 파일 상단에 "최신 절이 아래 표보다 우선한다"는 포인터
    한 줄만 넣었다. 다른 세션의 기록을 덮지 않으면서, 위에서부터 읽는 사람이 낡은 표를
    먼저 믿지 않게 하는 최소 편집이다.
    🔴 이번에 가장 값이 있었던 항목은 "정정된 판단"이다 — 사용자가 어떤 대상의 성격을
    내가 잘못 안 채로 적어 둔 것을 정정해 줬고, 내가 초기안 하나를 "공수 대비 가치 낮음"으로
    깎았던 판단도 철회했다. 둘 다 압축되면 흐려질 성질이고, 남기지 않으면 다음 세션이
    같은 오독을 반복한다.
  • 2026-09-09 — 네 번째 적용. 어제 늘린 "막혔던 것·기다린 것" 항목이 제 역할을 했다.
    이번 구간은 야간 단독 작업이라 막힌 지점이 많았는데(한도 2회·resume 옵션·인코딩 3회·
    GPU 경합·데이터로딩 병목), 그것을 한 줄씩 아홉 개로 남기는 데 몇 분이면 됐다.
    🔴 그중 가장 무거운 것이 외부 요인이 아니라 관리자 자신의 오류였다 —
    계획서에 실행하지 않은 결과를 미리 적은 것. 압축 전에 이것을 남겨 두지 않았다면
    "잘 끝난 밤" 으로만 기억됐을 것이다.
    → 규칙대로 기록만 하고 분석하지 않았다. 분석은 [[bottleneck-review]] 와
    그 프로젝트의 병목 대장이 받았다.
  • 2026-09-08 — 세 번째 적용이자 절차 1단계에 항목을 하나 늘린 날이다.
    같은 세션에서 병목 분석 스킬을 만들면서 발동 시점이 겹치는 문제가 드러났다 —
    이 스킬은 "다른 요청이 함께 있어도 이것부터" 인데, 압축 예고에 병목 분석까지
    걸면 둘이 우선권을 다툰다. 게다가 이 스킬에는 지금 안 남기면 사라진다는
    긴급성이 있고 병목 분석에는 없다.
    → 압축 시점에는 "막혔던 것·기다린 것"을 한 줄씩 기록만 하고 분석은 하지 않는
    것으로 갈랐다. 그 한 줄들이 나중에 병목 분석의 재료가 된다.
    지금까지는 그 재료를 매번 진행 문서에서 grep 으로 다시 캐냈다.
  • 2026-08-27 — 두 번째 적용. 이번엔 한 세션에서 여러 저장소에 걸쳐 작업이
    진행됐고(공개 레포 신설·스킬 이관·다른 저장소 기여), 진행 문서에는 그중
    어느 것도 반영돼 있지 않았다. 각 저장소의 커밋 로그가 남아 있어도
    "왜 그렇게 갈랐는가"는 커밋 메시지에 흩어져 복원되지 않는다 — 그 판단이
    진행 문서에 있어야 다음 세션이 이어받는다.
    → 절차 1단계에 **"이번 세션이 건드린 저장소·폴더를 전부 세어 본다"**를 추가했다.
    한 프로젝트 문서만 보면 다른 저장소에서 한 일이 통째로 빠진다.
  • 2026-08-27 — 신규 생성. 사용자가 "compact 진행하겠다"는 예고와 "작업 문서·
    스킬을 업데이트하도록 스킬을 만들라"는 요청을 동시에 냈다. 예고를 받은 그 턴에
    진행상황 문서부터 갱신(그날의 결정·신규 스킬·자체 오판 정정)한 뒤 이 스킬을 만든 것이
    첫 적용 사례다 — 스킬을 만드는 일보다 기록을 먼저 한 것이 요점이다.