되돌리기 어려운 작업 앞에는 열 줄짜리 보고를 먼저 받습니다.
AI에게 개발을 맡기면 속도가 빨라지는 대신 되돌리기 어려운 작업까지 빨라집니다. 파일을 지우고, 구조를 바꾸고, 설정을 갈아 끼우는 일이 설명 한 줄 없이 지나갑니다. 문제는 실행 자체가 아니라, 무엇이 바뀔지 모르는 상태에서 실행됐다는 데 있습니다. 제가 쓰는 개발 운영 규칙은 이 지점에 관문을 하나 두었습니다. 큰 변경이나 되돌리기 어려운 작업 전에는 열 가지 항목을 먼저 보고하고, 승인 전에는 실행하지 않는다는 규칙입니다. 열 가지는 목표, 현재 상태, 바꿀 파일과 기능, 반드시 유지할 것, 이번에 제외할 것, 실행 순서, 예상 결과, 위험 요소, 테스트 방법, 복구 방법입니다. 항목을 세어 두는 이유는 하나입니다. 빠진 항목이 곧 위험한 항목이기 때문입니다.
왜 실행 전에 보고를 받나
AI는 요청을 받으면 곧바로 실행 가능한 형태로 옮깁니다. 그 자체는 장점이지만, 요청을 어떻게 이해했는지는 실행이 끝난 뒤에야 결과로 드러납니다.
결과로 드러나는 순간에는 이미 파일이 바뀐 뒤입니다. 되돌릴 수 있는 작업이면 시간만 쓰면 되지만, 되돌리기 어려운 작업이면 복구 자체가 새 작업이 됩니다.
그래서 규칙은 실행 앞에 한 단계를 끼워 넣습니다. 이해한 내용을 글로 먼저 내놓게 하는 것입니다. 이해가 어긋났다면 이 단계에서 드러납니다.
보고를 받는 목적은 감시가 아니라 범위 확인입니다. 어디까지 바뀌는지 알고 시작하면 결과를 볼 때도 어디를 봐야 하는지 알 수 있습니다.
- 화면 문구 한 줄 수정 — 되돌리면 끝, 보고 없이 진행
- 여러 파일에 걸친 구조 변경 — 되돌리는 데 시간이 들어 보고 대상
- 파일과 폴더의 이동과 삭제 — 원본이 없으면 복구 불가, 반드시 보고
- 설정과 배포 환경 변경 — 겉으로 안 드러나고 나중에 터짐, 반드시 보고
열 가지 항목은 무엇인가
항목은 세 묶음으로 읽으면 외우기 쉽습니다. 지금 어디에 서 있는지, 무엇을 어떻게 바꿀지, 잘못됐을 때 어떻게 돌아올지입니다.
특히 중요한 것은 반드시 유지할 요소와 이번에 제외할 내용입니다. 이 두 줄이 없으면 AI가 주변까지 정리하려 들면서 승인하지 않은 변경이 섞입니다.
| 묶음 | 항목 | 이 줄이 막는 것 |
|---|---|---|
| 지금 어디 | 이해한 목표 · 현재 상태 | 요청을 잘못 이해한 채 시작 |
| 무엇을 어떻게 | 바꿀 파일과 기능 · 실행 순서 · 예상 결과 | 범위가 흐린 채 진행 |
| 건드리지 않을 것 | 반드시 유지할 요소 · 이번에 제외할 내용 | 승인하지 않은 변경이 섞임 |
| 잘못됐을 때 | 위험 요소 · 테스트 방법 · 복구 방법 | 되돌릴 방법 없이 시작 |
복구 방법을 왜 미리 적나
복구 방법은 문제가 생긴 뒤에 찾으면 늦습니다. 그 시점에는 이미 상태가 바뀌어 있어서, 무엇을 되돌려야 하는지부터 다시 알아내야 합니다.
미리 적어 두면 판단이 아니라 실행이 됩니다. 어디에 백업을 뒀는지, 어떤 순서로 되돌리는지, 되돌린 뒤 무엇을 봐서 정상인지 알 수 있는지가 이미 정해져 있기 때문입니다.
규칙 문서에는 원본을 덮어쓰기 전에 백업 또는 새 버전을 만들라는 항목도 따로 있습니다. 복구 방법을 적으라는 규칙과 짝을 이루는 조항입니다.
- 적을 것 — 되돌릴 대상과 백업 위치
- 적을 것 — 되돌리는 순서
- 적을 것 — 되돌린 뒤 정상인지 볼 자리
- 적지 않아도 되는 것 — 되돌릴 필요 없는 작은 수정
무엇을 보존한다고 적어야 하나
규칙 문서에는 기존 자산 보존이 따로 한 절로 들어 있습니다. 기능과 자료와 구조와 디자인과 문구를 우선 보존하고, 승인되지 않은 제목이나 기능이나 구조를 바꾸지 않는다는 내용입니다.
가장 자주 어긋나는 항목은 단순화를 이유로 기존 기능을 지우는 경우입니다. 코드가 깔끔해지는 것은 맞지만, 그 기능이 왜 있었는지는 코드에 적혀 있지 않습니다.
그래서 보고 단계에서 유지 항목을 이름으로 적습니다. 뭉뚱그린 표현으로는 지켜지지 않습니다.
승인은 어떤 말로 하나
승인 문장은 짧고 일정해야 합니다. 표현이 매번 달라지면 AI가 승인인지 의견인지 다시 해석하고, 해석이 들어가면 추측이 돌아옵니다.
반대로 보류할 때도 문장을 정해 둡니다. 어느 항목이 비어서 보류인지 함께 말하면 다음 보고가 곧바로 채워집니다.
승인하지 않은 채로 넘어가는 경우도 정해 둡니다. 답을 하지 않은 것은 승인이 아니라는 것을 한 번 못 박아 두면, 기다림이 묵인으로 바뀌지 않습니다.
돈이 들거나 개인정보를 다루거나 밖으로 나가는 작업은 이 관문을 건너뛸 수 없게 해 둡니다. 규칙 문서에도 그 항목들은 사람이 최종 승인한다고 따로 적혀 있습니다.
| 상황 | 돌려줄 말 | 다음에 오는 것 |
|---|---|---|
| 열 항목이 다 찼고 이견 없음 | 진행 | 실행과 결과 보고 |
| 항목이 비어 있음 | 빈 항목을 지목하고 보류 | 채워진 보고 다시 |
| 범위가 넓음 | 이번에 제외할 것을 지정 | 좁힌 보고 다시 |
| 복구 방법이 없음 | 백업부터 요청 | 백업 확인 뒤 보고 |
관문을 두고 달라진 것
| 두기 전 | 둔 뒤 |
|---|---|
| 실행 뒤에 범위를 알게 됨 | 실행 전에 범위를 읽음 |
| 유지할 것이 말로만 남음 | 이름으로 적혀 남음 |
| 복구 방법을 사고 뒤에 찾음 | 미리 적어 두고 실행만 함 |
| 승인 표현이 매번 다름 | 진행과 보류 두 마디로 고정 |
자주 묻는 질문
Q. 작은 수정에도 매번 보고를 받아야 하나요?
A. 아닙니다. 규칙은 큰 변경이나 되돌리기 어려운 작업으로 범위를 정해 두었습니다. 되돌리면 끝나는 수정까지 보고를 받으면 절차만 늘고 지켜지지 않습니다.
Q. 열 가지를 다 적으면 보고가 너무 길어지지 않나요?
A. 항목마다 한 줄이면 충분합니다. 길이를 늘리는 게 목적이 아니라 빈칸을 드러내는 게 목적이라, 짧게 적을수록 빠진 항목이 잘 보입니다.
Q. 반드시 유지할 요소는 어느 수준으로 적나요?
A. 이름으로 적습니다. 어떤 기능, 어떤 문구, 어떤 화면인지 지목해야 지켜집니다. 기존 기능 유지 같은 표현은 지시로 쓰이지 않습니다.
Q. 보고를 받았는데 판단이 어려우면 어떻게 하나요?
A. 이번에 제외할 내용을 먼저 지정하고 범위를 좁혀 다시 받습니다. 판단이 어렵다는 것은 대개 한 번에 바꾸려는 범위가 넓다는 뜻입니다.
확인 자료
- AI 개발 운영 규칙 문서 v1.3 — 4장 실행 전 보고 10항목, 5장 기존 자산 보존, 10장 버전과 백업 (확인 2026-09-09)
- AI 개발 운영 규칙 현장 부록 v1.3 — 4장 완료 보고에 추가할 항목 (확인 2026-09-09)
이 글은 직접 겪은 작업 기록을 정리한 것입니다. 확인하지 못한 항목은 본문에 쓰지 않았습니다. 대표 이미지는 이해를 돕기 위한 참고용 이미지입니다.