Progress Log 갱신

논의·세션에서 확정된 내용을 진행상황 문서에 반영한다.

• 대상 파일: 그 프로젝트의 진행상황·결정사항 문서. 프로젝트마다 이름이 다르므로
  (진행상황.md, DECISIONS.md, 작업로그.md 등) 먼저 있는 것을 찾는다.
  없으면 새로 만들되 이름과 위치를 사용자에게 먼저 알린다 — 임의로 만들면
  다음 세션이 다른 곳에 또 만든다.

언제 쓰는가 — 요청을 기다리지 않는다

"진행상황 정리해줘" 같은 명시적 요청뿐 아니라, 대화 중 다음이 나오면 그 자리에서 바로
문서를 갱신한다. 이어지는 다른 작업(문서 검토, 코드 리뷰 등)보다 먼저 처리한다.

• 이미 문서에 적어둔 계획·범위가 취소·변경됐을 때 (예: "그 패널은 진행 안 하기로 했다")
• 산출물의 출처·작성자가 정정됐을 때 (예: "그건 제가 만든 게 아니라 다른 사람이 만든 겁니다")
• 회의 일정·안건이 바뀌거나 확정됐을 때
• 그 외 이전에 기록한 사실과 모순되는 새 정보가 나왔을 때

이유: 문서 갱신을 뒤로 미루고 다른 작업부터 하면, 그 작업이 낡은 전제 위에서 진행되고
다음 세션이 스테일 문서를 그대로 이어받는다. 최신화가 먼저, 나머지 작업은 그다음이다.

절차

1. 현재 문서 읽기 — 기존 섹션(최신 스냅샷 절 등) 구조 파악. 이미 문서화된 내용은
   중복하지 않는다.
2. 미문서화 결정·정정만 추출 — 이번 세션/채팅에서 새로 정해졌거나, 바뀌었거나,
   뒤집힌 것만.
   • 결정은 날짜(절대일자)와 근거를 함께 기록. 상대표현("어제") 금지.
   • 뒤집힌 사실은 취소선으로 남기고 정정 내용을 잇는다 — 조용히 고쳐 쓰지 않는다.
     (예: ~~기존 서술~~ → **정정 (날짜)**: 새 사실). 이전에 그렇게 판단했던 근거가
     남아 있어야 다음에 같은 오해가 반복되지 않는다.
3. 해당 섹션에 반영 — 새 결정은 관련 섹션에 추가, 바뀐 사실은 갱신,
   완료된 대기 항목은 상태 갱신. "남은 것" 요약도 최신화.
4. 승인 없이 바로 반영 — 진행상황/작업내역/스킬 갱신은 문서 수정 사전 허가 원칙의
   예외다. 제안 없이 Edit로 바로 반영한다.

무엇을 묻고 무엇을 묻지 않는가 — 경계

기록을 묻지 않는다는 규칙은 "아무거나 해도 된다"가 아니다. 경계는 이렇다.

묻지 않고 바로 한다	반드시 먼저 묻는다
진행상황·결정사항 문서 갱신	되돌릴 수 없는 것 — 삭제, 덮어쓰기, 이력 정리
작업내역·완료 기록	밖으로 나가는 것 — 공유 문서 반영, 메일·메신저 발송, 공개 저장소 push
스킬 갱신과 그 이력	사람이 정할 것 — 범위·일정·우선순위, 아키텍처·모델·데이터셋 선택
이미 정해진 것의 기록·정정	권한 밖의 결정 — 상대가 결정권자가 아닐 때. 물을 상대부터 확인한다
조사·검증·읽기	사용자가 쓴 문서의 내용 변경 (기록 문서는 예외)
내가 만든 산출물의 자체 수정	비용이 큰 착수 — 장시간 실행, 대량 다운로드

판별 질문 하나 — "틀렸을 때 되돌리는 비용이 얼마인가."
문서에 한 줄 더 쓴 것은 지우면 그만이다. 보낸 메일과 지운 파일은 되돌릴 수 없다.

⚠️ "어느 것부터 할까요?"도 묻는 것이다. 둘 다 내가 해도 되는 일이면 순서는 내가
정하고, 하고 나서 무엇을 했는지 알린다. 선택지를 늘어놓는 것이 정중해 보이지만
결정 하나를 넘기는 것이고, 그만큼 진행이 멈춘다.

🔴 지시를 옮길 때는 원문을 함께 남긴다

요약하면서 비어 있던 자리를 내가 채우게 된다. 그 자리가 정확히 다음 세션의
작업 범위가 되므로, 채운 값이 틀리면 엉뚱한 일을 한다.

실측 사고 — 사용자가 이렇게 말했다.

"아예 스킬반영 ci 없애고 agent harness로 병합하고 거기서 선택적으로 설치하는게
 나아보여요"

병합 의 목적어가 비어 있다. 나는 진행 문서에 "CI 를 없애고 agent-harness 로
병합" 이라고 목적어를 CI 로 못 박아 적었다. 다음 세션은 그 좁힌 해석 위에서
CI 만 만들고 "없앨 CI 가 없었다" 고 보고했다. 실제 의도는 레포 병합이었다.

→ 말을 줄일 때 문법이 비워 둔 자리를 메우지 않는다. 지시가 한 가지로만
읽히지 않으면 사용자의 문장을 그대로 인용해 두고, 내 해석은 해석이라고
밝혀 따로 적는다. 한 줄 더 쓰는 값이 한 세션을 되돌리는 값보다 싸다.

⚠️ 사용자가 보내기 직전에 고친 말은 특히 그렇다. 위 문장의 로 병합하고 는
초안에 없다가 26초 뒤에 덧붙은 것이었다 — 덧붙였다는 것 자체가 그 말이
중요하다는 신호다.

원칙

• 간결하게, 불릿 위주. 이미 다른 산출물(프로젝트 지침 문서, 별도 보고서)에 있는 건 참조만.
• 코드/깃 히스토리로 알 수 있는 건 넣지 않는다 — 논의로만 정해진 맥락 위주.
• 기록은 밀리면 사라진다. 승인을 기다리는 동안 대화가 이어지고, 그러면 무엇을 왜
  정했는지가 흐려진다. 기록만 예외로 두는 이유가 이것이다.

이력 (필수 기록)

• 생성일: 2026-08-18 (추정, 최초 발견일 기준)
• 업데이트 횟수: 3
• 최근 업데이트: 2026-08-28
• 사용 이력:
  • 2026-08-28 — "무엇을 묻고 무엇을 묻지 않는가" 경계표 추가. 사용자 지시:
    로컬 작업 내역 기록은 묻지 말고 진행하라.
    §절차 4에 "승인 없이 반영"이 이미 있었는데도 관리자가 로컬 문서 갱신을 두고
    "어느 쪽부터 할까요?"라고 물었다. 규칙이 있어도 반대편(무엇은 물어야 하는가)이
    적혀 있지 않으면, 애매한 순간에 습관적으로 묻게 된다.
    → 판별 질문을 하나로 압축했다: "틀렸을 때 되돌리는 비용이 얼마인가."
    선택지를 제시하는 것도 묻는 것이라는 점을 명시했다 — 정중해 보이지만 결정을
    넘기는 것이고 진행이 멈춘다.
  • 2026-08-27 — 공용 저장소로 이관. 대상 파일명이 특정 프로젝트의 한국어 파일명으로
    본문과 description 양쪽에 박혀 있었다 — 다른 프로젝트에서는 없는 파일을 찾게 된다.
    "그 프로젝트의 진행상황 문서를 먼저 찾고, 없으면 이름·위치를 알린 뒤 만든다"로 바꿨다.
  • 2026-08-26 — 사용자가 "해당 작업 중단", "그 도식은 다른 사람이 만든 예시"라는
    정정 정보를 줬는데, 관리자가 이를 로컬 문서에 반영하기 전에 리뷰·다음 작업 정리부터
    진행하려 했다. 사용자가 "새로운 정보가 들어오면 작업 시작 전에 바로 작업 문서 업뎃 해야
    합니다"라고 지적 → 명시적 요청 없이도, 다른 작업보다 먼저 갱신하도록 규칙을 강화.
    승인 게이트(구 4단계)도 실제로는 한 번도 지켜진 적이 없어 문서에서 제거하고 예외로
    명시했다 — 매번 승인을 묻다 보면 기록이 밀리고, 밀린 기록은 결국 남지 않는다.