시작 명령을 셋으로 나눕니다. 규칙 확인, 이어가기, 새로 만들기입니다.
AI에게 개발을 맡길 때 가장 자주 생기는 사고는 엉뚱한 프로젝트를 건드리는 것입니다. 규칙만 불러오려고 한마디 건넸는데 최근 파일과 이전 대화를 근거로 프로젝트를 추정하고, 폴더를 만들고, 파일을 고치기 시작합니다. 제가 쓰는 개발 운영 규칙 문서는 이 문제를 명령을 쪼개는 방식으로 풀었습니다. 「개발루틴 확인」은 공통 규칙만 불러오고, 「기존 프로젝트 확인」은 이어갈 프로젝트를 지정받고, 「프로젝트 세팅」은 새로 만드는 명령입니다. 문서에는 이 셋이 서로 다른 명령이며 AI가 자동으로 합치거나 다른 명령으로 바꾸지 않는다고 못 박혀 있습니다. 나누고 나서 달라진 것은 하나입니다. 대상이 불분명할 때 AI가 추측 대신 질문을 하게 됐습니다.
명령을 나눈 이유
규칙 문서에는 「개발루틴 확인」을 받았을 때 AI가 하지 말아야 할 일이 다섯 가지로 적혀 있습니다. 금지 목록이 다섯 줄이나 붙어 있다는 건 그 다섯 가지가 실제로 벌어졌다는 뜻입니다.
다섯 가지는 최근 파일이나 이전 대화로 프로젝트를 추정하는 것, 기존 프로젝트 상태를 보고하는 것, 새 프로젝트 폴더를 만드는 것, 코드와 문서와 저장소를 고치는 것, 설치나 배포를 시작하는 것입니다.
그래서 명령을 셋으로 쪼갰습니다. 각 명령이 담당하는 범위를 좁혀서 해석의 여지를 없애는 방식입니다.
쪼갠 뒤에는 명령마다 「이 명령에서는 하지 않는 것」을 따로 적었습니다. 할 일보다 안 할 일을 적는 편이 훨씬 잘 지켜집니다.
| 규칙만 불러올 때 하지 않는 것 | 왜 |
|---|---|
| 최근 파일·이전 대화로 프로젝트 추정 | 요청하지 않은 대상을 만든다 |
| 기존 프로젝트 상태 보고 | 확인 비용만 늘어난다 |
| 새 프로젝트 폴더 생성 | 되돌리기가 번거롭다 |
| 코드·문서·저장소 수정 | 승인 없는 변경이 된다 |
| 설치·배포 시작 | 환경이 조용히 바뀐다 |
첫 번째 명령 — 규칙만 불러온다
「개발루틴 확인」은 공통 개발·디자인·백업·권한·테스트 규칙만 읽는 명령입니다. 특정 프로젝트를 고르지 않습니다.
규칙 문서에는 이 명령의 응답 예시까지 적혀 있습니다. 확인이 끝났다는 문장, 특정 프로젝트를 자동 선택하지 않았다는 문장, 그리고 다음에 무엇을 입력할지 두 가지 선택지를 제시하는 문장입니다.
응답 예시를 문서에 박아 둔 이유가 있습니다. 사람이 매번 「프로젝트는 아직 고르지 마」라고 덧붙이지 않아도 되게 하려는 것입니다.
선택지를 두 개만 준 것도 의도입니다. 셋 이상이면 사용자가 다시 고민하고, 고민하는 동안 대화가 길어집니다.
- 불러오는 것 — 공통 개발·디자인·백업·권한·테스트 규칙
- 고르지 않는 것 — 프로젝트, 폴더, 파일
- 끝나는 방식 — 두 가지 선택지를 제시하는 질문
- 이어지는 명령 — 기존 프로젝트 확인 또는 프로젝트 세팅
두 번째 명령 — 이어갈 대상을 지정받는다
「기존 프로젝트 확인」은 진행 중인 프로젝트를 이어가는 명령입니다. 프로젝트명이나 공식 경로가 없으면 AI가 한 번만 묻습니다.
「한 번만」이라는 조건이 중요합니다. 매번 묻게 하면 사람이 붙잡혀 있게 되고, 아예 안 묻게 하면 추측으로 돌아갑니다.
안내 문서, 에이전트 규칙, 작업 흐름, 디자인 기준을 먼저 읽고, 그다음 프로젝트 상태와 승인 범위, 결정 기록, 최근 개발 기록, 쓰기 권한 점검 결과, 테스트 기록을 읽습니다.
필수 문서가 없거나 문서와 실제 상태가 어긋나면 추측하지 않고 먼저 보고합니다. 확인이 끝나기 전에는 수정도 설치도 시작하지 않습니다.
| 단계 | 읽는 것 | 확인하는 것 |
|---|---|---|
| 1 | 안내·에이전트·작업 흐름·디자인 | 이 프로젝트의 약속 |
| 2 | 상태·승인 범위·결정 기록 | 지금 어디까지 왔나 |
| 3 | 개발 기록·테스트 기록 | 무엇이 실패했나 |
| 4 | 실제 폴더·버전 관리 상태 | 문서와 일치하나 |
| 5 | 저장소 쓰기 권한 | 고칠 수 있나 |
세 번째 명령 — 만들기 전에 계획부터
「프로젝트 세팅」은 새 프로젝트를 만드는 명령입니다. 설명이 없으면 AI가 먼저 묻습니다. 해결하려는 문제와 원하는 결과를 한두 문장으로 알려 달라는 질문입니다.
답을 받으면 곧바로 폴더를 만드는 게 아니라 정리부터 합니다. 목표, 사용자, 제품 형태, 최소 기능, 제외할 기능, 기술 후보, 개인정보, 배포, 테스트, 폴더와 문서 구조, 저장소 권한, 위험과 복구 방법입니다.
이 정리가 끝나고 승인 문장이 나오기 전까지는 폴더도 파일도 만들지 않습니다. 규칙 문서에 명시된 조건입니다.
- 사람이 하는 일 — 목적 설명, 계획 승인, 권한 허용
- 사람만 결정하는 일 — 돈·계약·개인정보·외부 발송·공개·삭제
- AI가 하는 일 — 폴더 생성, 문서 생성, 답변 반영, 권한 시험, 상태 기록
- 승인 전에 하지 않는 일 — 폴더 생성, 파일 생성
두 명령을 붙여 쓸 때
규칙 문서는 명령을 붙여 쓰는 문장도 함께 정해 뒀습니다. 「개발루틴 확인 후 기존 프로젝트 확인」, 「개발루틴 확인 후 프로젝트 세팅」 두 가지입니다.
굳이 붙여 쓰는 형태를 따로 적어 둔 이유는, 정하지 않으면 사람마다 다르게 말하기 때문입니다. 표현이 흔들리면 AI가 다시 해석하고, 해석이 들어가면 추측이 돌아옵니다.
붙여 쓸 때도 순서는 그대로입니다. 규칙을 먼저 읽고, 그다음 대상을 정합니다. 순서를 바꾸면 규칙 없이 프로젝트를 열게 됩니다.
셋으로 나누고 달라진 것
| 나누기 전 | 나눈 뒤 |
|---|---|
| 한마디에 프로젝트를 추정 | 대상이 없으면 한 번 질문 |
| 규칙 확인이 상태 보고로 번짐 | 규칙만 읽고 질문으로 끝남 |
| 승인 전에 폴더가 생김 | 승인 문장 뒤에만 생성 |
| 문서와 실제가 어긋난 채 진행 | 어긋나면 먼저 보고 |
| 매번 조건을 다시 설명 | 응답 예시가 문서에 고정 |
자주 묻는 질문
Q. 명령을 왜 굳이 셋으로 나눠야 하나요?
A. 명령이 하나면 AI가 그 하나로 모든 상황을 해석해야 하고, 해석의 폭이 넓을수록 추측이 늘어납니다. 셋으로 나누면 각 명령의 범위가 좁아져 추측할 자리가 사라집니다.
Q. 규칙만 확인하는 명령에서는 무엇을 하지 않나요?
A. 프로젝트 추정, 기존 프로젝트 상태 보고, 새 폴더 생성, 코드·문서 수정, 설치·배포 시작 다섯 가지를 하지 않습니다. 규칙 문서에 금지 항목으로 적혀 있습니다.
Q. 프로젝트를 지정하지 않으면 어떻게 되나요?
A. AI가 한 번만 묻습니다. 매번 묻지도, 아예 묻지 않고 추측하지도 않도록 횟수를 정해 둔 것입니다.
Q. 새 프로젝트는 언제부터 폴더가 생기나요?
A. 목표·최소 기능·제외 기능·위험과 복구 방법까지 정리해 보고한 뒤 승인이 떨어진 다음입니다.
확인 자료
- AI 개발 운영 규칙 문서 v1.3 — 0장 시작 명령 라우팅, 1장 새 프로젝트 세팅, 2장 프로젝트 지정 후 필수 확인 순서 (확인 2026-09-09)
- 개발 운영 규칙 변경 기록 — v1.0 최초 배포 이후의 항목별 변경 이력 (확인 2026-09-09)
이 글은 직접 겪은 작업 기록을 정리한 것입니다. 확인하지 못한 항목은 본문에 쓰지 않았습니다. 대표 이미지는 이해를 돕기 위한 참고용 이미지입니다.