요약: 지침은 많아서 문제가 되는 게 아니다. 설계 없이 추가되고, 아무 때나 수정되고, 정리되지 않을 때 무너진다. 이 글에서는 내가 실제로 겪은 실패 과정과 그 끝에 만든 구조를 정리했다.
AI를 활용해서 개발을 반복하다 보니 확실히 느낀 게 있다.
지침 하나로 결과 품질이 크게 달라진다는 점이다.
그래서 프로젝트 시작부터 범용 지침을 만들어 적용하기 시작했다.
초반엔 잘 돌아갔다.
근데 딱 거기까지였다.
1. 지침을 "잘 만든다"는 착각
처음엔 단순한 지침이었다. 그래서 오히려 안정적으로 동작했다.
문제는 품질 욕심이었다. 지침을 계속 추가하고, 더 구체화했다.
예를 들어 이런 식이다.
- 간결하게 작성하라
- 필요한 경우 상세히 설명하라
- 사용자 스타일에 맞춰라
- 일관된 톤을 유지하라겉보기엔 문제 없어 보인다.
하지만 이미 충돌이 시작된 상태다.
결과는 이랬다. 어떤 응답은 지나치게 짧고, 어떤 응답은 쓸데없이 길어지고, 톤도 일정하지 않았다.
문제를 해결하려고 지침을 더 구체화했다.
- 설명은 3~5문장으로 작성하라
- 예시는 반드시 포함하라
- 문장은 120자 이하로 유지하라이건 더 좋아 보인다. 근데 실제로는 더 망했다. 조건 충돌이 늘고, 토큰 사용량이 증가했고, 결과 품질은 오히려 흔들렸다.
구체화는 정확도를 올리지만, 충돌 확률도 같이 올린다.
2. 실제로 겪은 지침 충돌
이건 특히 치명적이었다.
- 모듈화하라
- 새로운 파일 생성은 가능한 지양하라사람은 상황에 따라 판단한다. AI는 다르다. 결과는 파일은 안 나누고 코드만 복잡해진 구조였다.
이때 확실히 알았다. 지침 간 충돌은 반드시 설계로 해결해야 한다. 지침을 더 추가하는 방식으로는 해결이 안 된다.
3. 내가 만든 구조: 두 계층 + 단계별 워크플로우
실패를 반복하면서 결국 템플릿 레포를 만들었다.
핵심은 두 가지다. 지침의 계층 분리와 지침 수정 시점 통제.
계층 분리: 범용 규칙 vs 프로젝트 전용 지침
레포 구조는 이렇다.
.ai_rules/ ← 범용 규칙 (모든 프로젝트에 적용)
AI_DEV_GLOBAL_RULES.md
AI_ARCHITECTURE_GUARD.md
AI_EXTENSIBILITY_BALANCE.md
.ai/ ← 프로젝트 진행 워크플로우 (01~07단계)
01_spec_draft.md
02_critical_questions.md
03_final_spec.md
04_architecture.md
05_project_rules.md ← 프로젝트 전용 지침 생성
06_review.md
07_guideline_update.md
docs/ ← 프로젝트 산출물
SPEC.md
ARCHITECTURE.md
DECISIONS.md
KNOWN_ISSUES.md
PROJECT_CONTEXT.md.ai_rules/는 건드리지 않는다. 이 규칙들은 프로젝트를 넘어서 항상 유효한 원칙이다. 예를 들어 "미래 기능을 미리 구현하지 않는다", "추상화는 반복이 3회 이상 발생한 후에만 한다", "레이어 간 의존 방향을 지킨다" 같은 것들이다.
프로젝트 전용 지침은 05_project_rules.md 단계에서 범용 규칙을 상속하고, 이 프로젝트의 도메인 용어, 명명 규칙, 코드 패턴을 구체화해서 생성한다. 충돌이 없는 이유는 범용 규칙이 원칙을 정의하고, 전용 지침이 적용 방법을 정의하는 역할 분리가 되어 있기 때문이다.
지침 수정 시점 통제 (게이트)
이게 핵심이다.
baseline(MVP) 완료 전에는 지침을 수정하지 않는다.
구현 중에 발생하는 내용은 지침에 반영하지 않고, 유형에 따라 아래로 분리한다.
| 발생 상황 | 기록 위치 |
|---|---|
| 아키텍처 결정 | docs/DECISIONS.md (추가 전용) |
| 임시 우회나 제약 | docs/KNOWN_ISSUES.md |
| 지침 자체가 틀리거나 충돌하는 경우 | 즉시 수정 (예외) |
이 규칙이 없으면 이렇게 된다. 구현 중 "이 케이스는 다르게 처리해야 해"라는 이유로 지침을 계속 수정하게 되고, 기준이 흔들리고, 결국 지침이 뭘 말하는지 알 수 없게 된다. 초반에 내가 겪은 구조 붕괴가 정확히 이거였다.
baseline 이후에는 06_review → 07_guideline_update 루프로 지침을 개선한다. 이 단계에서 반복 위반된 규칙은 구체화하고, 한 번도 위반 안 된 규칙은 제거를 검토한다.
임시 지침 잔류 방지
이건 의외로 중요한 포인트였다.
KNOWN_ISSUES.md에 임시 제약을 기록할 때 반드시 "이 제약이 해소되는 조건"을 같이 적는다.
## [임시] 리팩토링 단계 파일 분리 제한
현재 리팩토링 진행 중이므로 신규 파일 생성을 지양한다.
→ 리팩토링 완료 후 삭제이 항목이 06_review 단계에서 점검된다. 해결된 항목이 남아 있으면 삭제한다. 과거 임시 지침이 계속 영향을 주는 건 거의 기술 부채랑 같다.
4. 뭐가 달라졌는가
구조 적용 전에는 이런 일이 반복됐다.
- 지침을 추가할수록 결과가 흔들렸다
- "어떤 지침이 우선인지" 애매한 상황이 계속 발생했다
- 임시로 넣은 지침이 뒤에 의도하지 않은 영향을 줬다
구조 적용 후의 변화는 이렇다.
- 범용 규칙이 충돌 없이 동작한다. 원칙과 적용 방법이 분리되어 있기 때문이다.
- 지침이 언제 수정됐는지, 왜 수정됐는지 추적이 된다. DECISIONS.md에 기록이 쌓인다.
- 임시 제약이 KNOWN_ISSUES.md에서 수명을 갖게 됐다. 방치되지 않는다.
5. 마무리: 지침은 코드와 같다
지침은 많아서 문제가 아니다.
설계 없이 추가되고, 아무 때나 수정되고, 정리되지 않을 때 무너진다.
코드에 계층과 책임 분리가 필요하듯, 지침도 마찬가지다.
범용 규칙은 원칙을 가지고, 전용 지침은 구체적인 적용 방법을 가진다.
수정 시점은 통제되어야 하고, 임시 지침은 수명을 가져야 한다.
지금 지침 계속 추가하고 있다면, 한 번 멈추고 구조부터 봐라.
'statement' 카테고리의 다른 글
| 회피형 인간(aka 나)을 위한 가동률 최적화 전략 (0) | 2026.02.19 |
|---|