이 글의 순서 세 번째 반복은 신호다
같은 금지 조건을 세 번째 붙여넣었다. 프롬프트보다 흩어진 작업 기준부터 손볼 때였다.
반복 문장을 이번 요청, 저장소 규칙 문서, 실제 차단 장치로 나눠 보기로 했다.
독자는 자기 프로젝트에서 어떤 문장을 어디로 옮길지 판단하는 짧은 체크리스트를 가져가면 된다.
처음에는 내가 프롬프트를 잘 못 쓰는 줄 알았다. 그래서 매번 더 길게 썼다.
삭제 명령은 바로 실행하지 말고 먼저 물어봐. 테스트가 실패하면 원인부터 알려줘. 고객 이름이나 이메일은 공개 문서에 그대로 넣지 마. 배포는 내가 확인한 뒤에만 해.
한 번 붙일 때는 별생각이 없었다. 두 번째까지도 그럴 수 있다고 봤다.
그런데 세 번째로 같은 문장을 붙여넣는 순간, 문제는 프롬프트가 아니라 운영 방식이라는 생각이 들었다.
반복되는 요청은 왼쪽의 임시 지시로 남겨두지 않고, 가운데의 규칙 파일과 오른쪽의 검증 지점으로 옮겨야 한다.
세 번째 반복은 신호다
프롬프트에 넣을 말과 규칙 파일에 둘 말은 다르다.
프롬프트에는 이번 작업의 부탁을 쓴다.
이번 글은 공개하지 말고 초안까지만 만들어줘.
이 함수만 보고 버그 가능성을 확인해줘.
오늘은 코드 수정 없이 리뷰만 해줘.이런 말은 그날의 요청이다. 다음 작업에서는 달라질 수 있다.
반대로 매번 다시 쓰는 문장이 있다.
삭제 명령은 실행 전에 한 번 더 확인한다.
배포는 테스트가 통과한 뒤에만 한다.
고객 정보나 내부 링크는 공개 문서에 그대로 넣지 않는다.
완료라고 말하기 전에 가능한 검증을 먼저 한다.이건 취향이 아니라 repo의 기본값이다. 이런 문장이 채팅창에 계속 남아 있으면 운영 기준이 흩어져 있다는 신호다.
프롬프트가 나쁜 게 아니다
프롬프트는 여전히 필요하다.
문제는 프롬프트가 너무 많은 일을 떠안는 순간이다. 작업 목표, 출력 형식, 독자, 예외 조건까지는 프롬프트가 맡아도 된다. 그런데 수정 범위, 공개 여부, 검증 기준, 위험 작업 기준까지 매번 프롬프트에 넣기 시작하면 대화창이 작은 운영 매뉴얼이 된다.
처음에는 그게 편하다. 붙여넣으면 되니까.
그런데 세션이 바뀌면 다시 붙여야 한다. 한 줄이 빠지면 에이전트는 그 기준을 모르는 사람처럼 움직인다. 대화가 길어지면 중요한 기준과 그날의 취향이 섞인다. 나중에는 내가 무슨 일을 요청했는지보다, 무엇을 하지 말라고 했는지가 더 길어진다.
그 상태에서는 프롬프트를 더 잘 쓰는 것보다, 반복되는 말을 어디로 빼둘지 정하는 편이 낫다.
규칙 파일은 프롬프트 저장소가 아니다
저장소 규칙 문서는 에이전트가 프로젝트 안에서 매번 확인해야 할 작업 기준을 모아두는 곳이다. Codex 환경에서는 AGENTS.md, Claude Code 환경에서는 CLAUDE.md가 그 예가 될 수 있다.
처음 보면 긴 프롬프트를 파일로 옮겨둔 것처럼 보인다. 나도 처음에는 그렇게 봤다.
그런데 실제 역할은 조금 다르다. 이 파일들은 에이전트에게 성격을 부여하지 않는다. 저장소에서 어디까지 보고, 어디서 멈추고, 무엇을 확인할지 작업 기준으로 남긴다.
예를 들어 이런 문장은 규칙 파일에 더 잘 맞았다.
- 삭제 명령은 확인 전에는 실행하지 않는다.
- 배포는 테스트가 통과한 뒤에만 진행한다.
- 고객 이름, 이메일, 내부 링크는 공개 문서에 그대로 남기지 않는다.
- 생성된 산출물은 직접 수정하지 않는다.
- 완료 전 가능한 검증 명령을 실행한다.재미있는 문장은 아니다. 그래도 사고를 줄이는 문장은 대개 재미가 없다.
이런 기준이 프로젝트 안에 있으면 다음 요청은 짧아진다. “이번 작업은 오류 원인만 찾아줘”라고만 말해도 된다. 삭제 전 확인, 배포 조건, 공개 문서의 개인정보 처리, 검증 기준은 규칙 파일이 이미 알려준다.
그래도 막아주는 건 아니다
여기서 착각하면 안 되는 지점이 있다.
규칙 파일은 안전장치가 아니다. 에이전트가 참고할 context다. “push 전에 물어봐”라고 써두면 물어볼 가능성은 올라간다. 하지만 그것만으로 잘못된 push가 물리적으로 막히지는 않는다.
정말 막아야 하는 일은 별도 장치가 필요하다. Git hook(커밋이나 push 앞에서 실행되는 검사 스크립트), 권한, CI, branch protection, review 절차 같은 것들이다. 규칙 파일은 “여기서 멈춰야 한다”를 알려주는 쪽이고, hook이나 권한은 “멈추지 않으면 실패하게 만드는” 쪽이다.
나는 이 둘을 섞어 쓰면 문서도 작업도 위험해진다고 본다. AGENTS.md가 있다고 해서 안전해졌다고 쓰면 과장이다. 더 정확한 말은 이 정도다.
반복 기준을 저장소 안에 남겨서, 에이전트가 멈춰야 할 지점을 더 자주 보게 만든다.딱 거기까지다. 그 이상은 다른 장치의 몫이다.
처음 버전은 짧아야 한다
규칙 파일을 처음 만들 때 욕심을 내기 쉽다. 좋은 코드, 좋은 UX, 깔끔한 설계, 책임 있는 커뮤니케이션 같은 말을 다 넣고 싶어진다.
그런데 그런 문장은 읽기에는 좋지만 행동을 크게 바꾸지 못한다. 에이전트가 실제로 틀리는 지점은 보통 더 구체적이다.
파일을 너무 넓게 고친다. 검증 없이 완료했다고 말한다. 검토 중인 문서를 공개 상태로 바꾼다. 생성된 결과물을 직접 수정한다. 삭제나 push 앞에서 멈추지 않는다.
첫 규칙 파일은 이런 실패 모드만 잡아도 충분하다. 공개 여부가 중요한 문서는 먼저 비공개 초안 상태로 두고, 생성 산출물과 승인 경계도 같이 적어둔다.
# Project Rules
- 요청받지 않은 파일은 수정하지 않는다.
- 새 문서는 기본적으로 비공개 초안 상태로 시작한다.
- 생성된 산출물은 직접 수정하지 않고 원본이나 생성 절차를 고친다.
- 삭제, 원격 반영, 배포는 확인 전에는 하지 않는다.
- 완료 전 가능한 검증 명령을 실행한다.이 정도면 화려하지는 않다. 대신 다음 작업에서 바로 쓴다.
내가 지금 쓰는 기준
지금은 프롬프트를 쓰기 전에 이 질문을 먼저 한다.
이 문장은 이번 요청에만 필요한가, 아니면 다음 작업에도 반복될 기준인가?이번 요청에만 필요하면 프롬프트에 둔다. 다음 작업에도 반복될 기준이면 규칙 파일 후보로 본다. 틀렸을 때 되돌리기 어렵다면 규칙 파일만 믿지 않고 hook이나 권한 같은 차단 장치도 같이 본다.
바로 적용하려면 이렇게 보면 된다.
- 세 번째 반복된 문장인가.
- 이번 요청의 취향이 아니라 저장소의 기본값인가.
- 에이전트가 실제로 확인하거나 멈추는 문장인가.
- 삭제, 원격 반영(push), 배포(deploy)처럼 되돌리기 어려운 일이라면 문서 말고 차단 장치도 필요한가.
비슷한 주제를 설명형으로 더 정돈하는 방법도 있다. 여기서는 내가 반복 프롬프트를 규칙 파일 후보로 보기 시작한 계기에 집중했다.
다음에 프롬프트를 길게 쓰고 있다면 바로 고치지 않아도 된다. 대신 세 번째 붙여넣는 문장만 따로 봐도 된다.
그 문장은 아마 프롬프트가 아니라 규칙 파일에 있을 자리다.
시리즈 연결
반응
댓글은 제출 즉시 공개되며, 작성 때 정한 비밀번호로 삭제할 수 있습니다.
댓글을 불러오는 중입니다.