채팅창을 기억장치로 쓰지 않습니다. 단계가 끝나면 바로 저장합니다.
AI와 대화로 개발을 진행하면 대화가 길어질수록 앞부분이 잘리거나 맥락이 흐려집니다. 그러면 어제 무엇을 어디까지 했는지 다시 설명해야 하고, 설명이 부정확하면 이미 만든 것을 또 만듭니다. 제가 쓰는 운영 규칙은 이 문제를 저장 위치로 풉니다. 채팅창을 유일한 기억장치로 쓰지 않고, 저장소를 항상 복구 가능한 기준점으로 둡니다. 개발은 작은 단계로 나누고, 각 단계의 구현과 검증이 끝나는 즉시 저장한 뒤 다음 단계로 갑니다. 여러 단계를 몰아서 개발하고 마지막에 한꺼번에 백업하지 않습니다. 저장이 확인되지 않은 단계는 완료로 치지 않습니다.
채팅창은 기억장치가 아니다
대화가 길어지면 앞부분이 잘립니다. 잘린 뒤에도 대화는 자연스럽게 이어져서, 무엇이 사라졌는지 알아채기 어렵습니다.
그래서 규칙에는 「채팅 보고보다 실제로 저장된 파일과 기록을 우선한다」는 문장이 들어 있습니다. 보고는 참고 자료이고 기준은 저장된 파일입니다.
새 대화를 시작하거나 맥락이 끊겼을 때도 기억으로 이어가지 않습니다. 저장소의 최신 체크포인트부터 다시 읽습니다.
이 원칙 하나만 지켜도 「어디까지 했더라」에 쓰는 시간이 사라집니다. 물어볼 대상이 사람의 기억이 아니라 파일이 되기 때문입니다.
루트에 항상 두는 파일 하나
프로젝트 루트에는 현재 진행 상황을 담은 문서를 하나 둡니다. 단계가 끝날 때마다 반드시 갱신합니다.
적는 항목이 정해져 있습니다. 프로젝트명, 현재 버전과 단계, 마지막 저장 시각, 이번 단계에서 실제로 바뀐 기능, 변경된 주요 파일입니다.
여기에 검증 결과와 통과 수치, 사람이 직접 써 본 테스트 상태, 알려진 오류와 미확인 항목, 마지막으로 정상이었던 체크포인트를 덧붙입니다.
마지막 항목이 가장 중요합니다. 「다음에 할 정확한 작업 하나」입니다. 여러 개를 적으면 다음 사람이 다시 우선순위를 고민하게 됩니다.
| 구분 | 적는 항목 |
|---|---|
| 위치 | 프로젝트명, 현재 버전과 단계, 관련 폴더 |
| 시각 | 마지막 저장 시각 |
| 변경 | 바뀐 기능, 변경된 주요 파일 |
| 검증 | 검증 결과와 통과 수치, 실사용 테스트 상태 |
| 미결 | 알려진 오류, 미확인 항목 |
| 기준점 | 마지막 정상 체크포인트 |
| 다음 | 다음에 할 정확한 작업 한 개 |
단계마다 폴더 하나를 남긴다
의미 있는 단계는 독립된 폴더로 남깁니다. 폴더 이름에 순번과 단계 이름, 버전을 함께 씁니다.
폴더 안에는 그 시점의 전체 소스와, 가능하면 직전 대비 변경분을 함께 넣습니다. 전체 소스가 있어야 어느 시점으로든 되돌아갈 수 있습니다.
여기에 무엇을 왜 바꿨는지 적은 보고서, 검증 결과, 포함 파일과 버전과 의존성과 시작점을 적은 목록을 넣습니다.
중요한 체크포인트에는 무결성 값도 함께 남깁니다. 나중에 파일이 바뀌었는지 확인할 근거가 됩니다.
| 파일 | 역할 |
|---|---|
| 전체 소스 | 그 시점으로 복구 가능 |
| 변경분 | 직전 체크포인트 대비 차이 |
| 단계 보고서 | 무엇을 왜 바꿨는지 |
| 검증 기록 | 자동·수동 확인 결과 |
| 목록 문서 | 포함 파일·버전·의존성·시작점 |
| 무결성 값 | 이후 변조·손상 확인 |
언제 저장하나
기능 하나가 구현되어 확인 가능한 상태가 되면 저장합니다. 모듈 하나가 끝났을 때도 마찬가지입니다.
자동 검증의 통과 수치가 바뀌었을 때, 데이터 구조나 동작 규칙이 바뀌었을 때도 저장합니다. 나중에 문제가 생기면 대개 이 지점으로 되돌아가게 됩니다.
크게 뜯어고치기 직전과 직후에도 남깁니다. 직전만 남기면 무엇이 달라졌는지 비교할 대상이 없습니다.
그리고 대화가 길어져 맥락이 흐려질 위험이 커지기 전에 한 번 저장합니다. 끊긴 뒤에 하려고 하면 이미 늦습니다.
- 기능 하나가 확인 가능한 상태가 됐을 때
- 모듈 하나가 끝났을 때
- 자동 검증 통과 수치가 바뀌었을 때
- 데이터 구조나 동작 규칙이 바뀌었을 때
- 위험한 수정 전과 후
- 여러 모듈을 합치기 직전
- 대화가 길어져 맥락 유실 위험이 커지기 전
보고보다 저장이 먼저다
단계를 끝내는 순서도 정해져 있습니다. 구현하고, 내부 테스트를 돌리고, 결과를 확인하고, 저장할 파일을 만들고, 올립니다.
그다음 진행 상황 문서를 갱신하고, 저장소에서 실제로 저장됐는지 확인합니다. 채팅으로 결과를 보고하는 건 그 뒤입니다.
순서를 이렇게 못 박은 이유는 하나입니다. 저장 확인보다 보고가 먼저 나오면, 보고만 남고 파일은 없는 상태가 생깁니다.
새 대화에서 이어갈 때는 반대 방향으로 읽습니다. 진행 상황 문서를 먼저 열고, 거기 적힌 마지막 단계 폴더를 열고, 보고서와 검증 기록과 목록을 확인한 뒤, 실제 소스 상태와 맞는지 봅니다. 기록과 실제가 일치할 때만 다음 작업을 시작합니다.
하지 않기로 한 것
| 금지 | 생기는 문제 |
|---|---|
| 진행 상황을 채팅에만 남기기 | 끊기면 복구 지점이 없다 |
| 두 단계 이상 몰아서 저장하기 | 어느 지점이 정상인지 모른다 |
| 최신 소스 없이 보고서만 저장 | 되돌릴 수 없다 |
| 안 해 본 상태를 통과로 기록 | 다음 사람이 믿는다 |
| 이전 체크포인트 덮어쓰기 | 복구 지점이 사라진다 |
자주 묻는 질문
Q. 왜 대화 기록만으로는 부족한가요?
A. 대화가 길어지면 앞부분이 잘리는데, 잘린 뒤에도 대화는 자연스럽게 이어져서 무엇이 사라졌는지 알아채기 어렵습니다.
Q. 얼마나 자주 저장해야 하나요?
A. 기능이나 모듈 하나가 끝날 때, 검증 수치가 바뀔 때, 위험한 수정 전후, 그리고 대화가 길어져 맥락 유실 위험이 커지기 전에 저장합니다.
Q. 단계 폴더에는 무엇을 넣나요?
A. 그 시점의 전체 소스와 변경분, 무엇을 왜 바꿨는지 적은 보고서, 검증 기록, 포함 파일 목록, 그리고 중요한 지점에는 무결성 값을 넣습니다.
Q. 새 대화에서는 어디부터 읽나요?
A. 진행 상황 문서를 가장 먼저 읽고, 거기 적힌 마지막 단계 폴더를 연 다음 실제 소스 상태와 일치하는지 확인합니다.
확인 자료
- AI 개발 운영 규칙 문서 v1.3 — 15장 단계별 체크포인트, 진행 상황 문서 항목, 저장 타이밍과 복구 순서 (확인 2026-09-09)
- 개발 기록 동기화 규칙 문서 v1.1 — 단계 종료 저장 순서와 확인 항목 (확인 2026-09-09)
이 글은 직접 겪은 작업 기록을 정리한 것입니다. 확인하지 못한 항목은 본문에 쓰지 않았습니다. 대표 이미지는 이해를 돕기 위한 참고용 이미지입니다.