리셋 데이는 대청소의 날이 아니라 선택의 날

1. 한 장 요약

받은 제안문은 프로젝트 감사, 놓친 아이디어, 성능, 애니메이션, PRD, AI 슬롭, 생활 일정, 컴퓨터 파일, 제품 아이디어 100개, 게임 월드, 대형 학습 과정까지 한 번에 펼칩니다. 영감 목록으로는 좋습니다. 문제는 그 목록을 실행 목표처럼 쓰는 순간입니다. 에이전트는 “이 중 무엇을 오늘 하지 않을지” 판단할 근거가 없습니다.

리셋 데이의 결과는 깨끗해진 하드디스크가 아닙니다. 다음에 무엇을 하고 무엇을 하지 않을지 정해진 상태입니다. 청소는 부산물이고 선택이 본편입니다.

2. 구호와 실행 목표를 섞지 않는다

“오늘은 전부 정리하는 날”은 사람의 기분을 움직이는 구호입니다. 실행 목표는 다르게 생겼습니다. 동사, 범위, 산출물, 금지 사항, 끝의 정의가 있어야 합니다. 둘을 구분하지 않으면 사람에게 힘을 주려고 쓴 문장이 에이전트에게 전권을 주는 명령이 됩니다.

3. 위험 신호 아홉 가지

위험한 문장은 대부분 생산적으로 들립니다. 그래서 단어를 보면 바로 멈출 수 있도록 이름을 붙였습니다.

“문서화해줘”도 조심해야 합니다. 리셋 데이의 문서 작업은 새 문서를 양산하기보다 서로 충돌하는 문서를 합치고, 현재와 어긋난 문서를 표시하는 데서 시작하는 편이 낫습니다. 문서가 늘었다는 사실은 정리가 끝났다는 증거가 아닙니다.

4. 안전한 Reset Day 6단계

앞 단계의 산출물이 없으면 다음 단계로 가지 않습니다. 순서가 안전장치입니다.

1. 경계부터 적기

   경로, 저장소 수, 읽지 않을 민감 영역, 사용할 수 있는 시간, 금지 행동을 먼저 적습니다.

2. 읽기 전용 감사

   마지막 수정일, 현재 상태, 테스트·배포 여부, 남은 TODO를 조사합니다. 쓰기, 삭제, 이동, 설치, 외부 발신은 하지 않습니다.

3. 네 분류로 나누기

   Keep은 유지, Finish는 끝낼 후보, Archive는 보관, Delete 후보는 검토 대상입니다. 후보는 삭제가 아닙니다.

4. 두 승인 게이트 통과

   되돌릴 수 없는 행동과 외부로 나가는 행동을 항목별로 승인합니다. 범위가 넓어지면 실행하지 않고 계획을 다시 씁니다.

5. Finish 하나 실행

   끝냈을 때 다른 일을 가장 많이 풀어주는 항목 하나를 고릅니다. 대형 작업 하나 또는 소형 작업 세 개를 상한으로 둡니다.

6. 검증하고 다섯 줄로 닫기

   종료 조건을 확인하고, 본 것·분류·승인·실행 결과·다음 시작점을 기록합니다. 조건을 못 맞췄다면 실패 로그와 재개 지점을 남기고 멈춥니다.

Keep / Finish / Archive / Delete 후보를 쓰는 이유는 일을 네 종류로 완벽히 설명하기 위해서가 아닙니다. “지금 실행할 것”과 “지금 건드리지 않을 것”을 강제로 갈라놓기 위해서입니다.

5. 승인 게이트는 두 개면 된다

모든 행동에 승인을 요구하면 사람은 결국 전부 “예”를 누릅니다. 게이트가 많은 시스템은 안전한 시스템이 아니라 승인 피로를 만드는 시스템입니다. 정말 위험이 달라지는 두 지점만 막습니다.

6. 사람 시간 90분 운영표

90분은 저장소가 정리된다는 보장이 아닙니다. 사람이 보고서를 읽고 선택하는 데 쓰는 집중시간의 상한입니다. 에이전트 작업 대기시간은 따로 흐를 수 있습니다. 이 안에서 대형 작업 하나 또는 소형 작업 세 개까지만 다룹니다.

실행이 25분 안에 끝나지 않아도 괜찮습니다. 리셋 데이의 목적은 모든 일을 끝내는 게 아니라 어떤 일을 이어갈지 결정하고 다음 시작점을 잃지 않는 것입니다. 감사와 분류만 끝내고 실행하지 않은 날도 선택이 일어났다면 성공입니다.

7. 붙여넣기 /goal 템플릿

고정해서 재사용하는 것은 안전 규칙뿐입니다. 대괄호로 표시한 목표, 범위, 산출물, 종료 조건은 프로젝트마다 반드시 다시 씁니다. 지난번 목표를 그대로 복사하는 것이 이 템플릿의 가장 위험한 사용법입니다.

/goal [대상]의 Reset Day를 진행한다.

이번 목표: [이번에 줄이거나 끝낼 열린 일]
범위: [경로·프로젝트 수·파일 수]
제외: [.env, 개인 로그, 비밀값, 범위 밖 경로]
산출물: [상태표, 승인 목록, 실행 결과]
종료 조건: [테스트, 측정값, 파일 수, 시도 횟수처럼 판정 가능한 값]

1. 먼저 범위 안을 읽기 전용으로 감사한다.
   파일 수정, 삭제, 이동, 설치, 커밋, 배포, 외부 발신을 하지 않는다.

2. 각 항목을 Keep / Finish / Archive / Delete 후보로 분류하고
   한 줄 근거를 붙인다. Delete 후보를 실제로 삭제하지 않는다.

3. 다음 두 종류는 항목별 승인을 요청한다.
   A. 되돌리기 어려운 행동
   B. 컴퓨터 밖으로 나가는 행동
   범위 확대가 필요하면 실행하지 말고 새 계획을 제안한다.

4. 내가 고른 Finish 항목 하나만 실행한다.
   [N회 실패 / N분 경과 / N파일 변경]에 도달하면 멈추고 보고한다.

5. 검증 후 다섯 줄로 마감한다.
   본 것 / 분류 / 승인 / 실행 결과 / 다음 시작점

템플릿의 길이는 실수로 빠지기 쉬운 경계를 모두 적은 결과입니다. “알아서 안전하게”라는 한 줄은 이 전체를 대신하지 못합니다.

8. 좋은 아이디어를 실행 목표로 다시 쓰기

원래 제안의 좋은 에너지는 남길 수 있습니다. 수량과 전권을 빼고 검증 가능한 한 단계로 줄이면 됩니다.

수량을 줄였다고 야심이 줄어든 게 아닙니다. 결과를 보고 다음 단계를 바꿀 수 있게 만든 겁니다. 250개를 한 번에 만들면 17번째에서 틀린 난이도가 250번째까지 복제됩니다. 10개를 만들고 실제 사용을 보는 편이 더 빨리 큰 결과에 도달합니다.

9. 마감 체크리스트

리셋 데이가 끝났는지는 아래 아홉 줄로 판단합니다.

• “모든” 대신 경로와 항목 수를 적었다.
• 민감정보와 범위 밖 경로를 제외했다.
• 첫 산출물은 수정이 아니라 읽기 전용 상태표였다.
• 각 항목이 Keep / Finish / Archive / Delete 후보 중 하나로 분류됐다.
• 되돌리기 어려운 행동을 항목별로 승인했다.
• 외부로 나가는 행동을 별도로 승인했다.
• 실행은 Finish 하나 또는 소형 작업 세 개를 넘지 않았다.
• 종료 조건을 에이전트가 스스로 판정할 수 있었다.
• 실행 결과와 다음 시작점이 다섯 줄로 남았다.