규칙 자동 주입
한 번 정한 규칙이 매번 지켜지게 만드는 법.
문제
대화가 길어지면 규칙이 희석된다.
앞에서 "any 타입 쓰지 마"라고 말해도, 서른 번쯤 주고받은 뒤에는 슬그머니 나온다. 새 대화를 열면 아예 처음부터 다시 설명해야 한다. 에이전트를 여러 개 띄우면 더 심하다. 각자 다른 컨텍스트에서 도니까, 한쪽에 말한 규칙이 다른 쪽에는 없다.
규칙을 대화에 넣으면 대화가 끝날 때 같이 사라진다. 그래서 대화 밖에 둬야 한다.
하는 일
규칙을 파일로 빼서 모든 대화와 에이전트에 자동으로 얹는다. 지금 두 개를 쓰고 있다.
| 파일 | 담는 것 |
|---|---|
code.rules.md | 타입·에러 처리·네이밍·구조 같은 코딩 컨벤션 |
project.rules.md | HMR 보호·백로그·배포 절차 같은 운영 규칙 |
합쳐서 230줄쯤 된다. 이게 어느 에이전트가 코드를 짜든 똑같이 적용된다. 구현 에이전트에게만 말하고 리뷰 에이전트는 모르는 상황이 안 생긴다.
무엇을 넣나
넣을 것과 안 넣을 것의 구분이 이 구조의 전부다.
넣는 것은 "매번 같아야 하는 것"이다. any 금지, 빈 catch 금지, 키 하드코딩 금지, 이모지 금지. 판단이 필요 없고 예외도 거의 없는 것들이다.
안 넣는 것은 "그때그때 다른 것"이다. 이 기능을 어떻게 설계할지, 이 화면을 어떤 톤으로 만들지는 규칙이 아니라 대화다. 이런 걸 규칙 파일에 넣으면 파일이 비대해지고, 비대해지면 그 안의 진짜 금지사항이 묻힌다.
특히 금지 목록은 짧아야 힘이 있다. 서른 개를 적으면 아무것도 안 지켜진다.
같은 규칙을 여러 곳에 쓰면 언젠가 서로 어긋난다. 한쪽만 고치고 다른 쪽을 못 고치기 때문이다.
그래서 규칙은 Skills 한 곳, 워크플로우는 각 에이전트 정의 한 곳, 라우터는 한 페이지로 못 박았다. 라우터에는 에이전트 목록과 흐름만 있고 상세는 없다. 상세를 라우터에 적기 시작하면 그게 곧 두 번째 사본이 된다.
규칙과 기억은 다르다
이 구조 옆에 파일 메모리가 따로 있다. 헷갈리기 쉬운데 성격이 다르다.
- 규칙은 내가 정해서 박아두는 것이다. "any 쓰지 마"
- 기억은 겪으면서 쌓이는 것이다. "이 사람은 이런 실수를 반복 지적했다"
규칙은 안 바뀌고 기억은 계속 는다. 그래서 저장 위치도 갱신 방식도 다르다. 기억을 규칙 파일에 밀어 넣으면 파일이 계속 부풀고, 규칙을 기억에 맡기면 매번 지켜지지 않는다.
정직한 한계
자동 주입은 규칙이 읽히는 것을 보장하지, 지켜지는 것을 보장하지 않는다. 길고 복잡한 작업에서는 여전히 놓친다.
그래서 진짜 중요한 것은 규칙에만 맡기지 않는다. 타입 체크로 잡히면 타입으로, 빌드로 잡히면 빌드로 막는다. 규칙 파일은 기계가 못 잡는 것을 위한 자리다. 이모지 금지나 문서 톤 같은 것들.