프롬프트보다 규칙이 필요했습니다

처음 AI를 잘 쓰는 방법을 찾을 때는 프롬프트를 많이 고쳤습니다. 말을 더 구체적으로 하면 결과가 좋아졌고, 역할을 지정하면 문체도 달라졌습니다.

그런데 일을 오래 맡기기 시작하자 프롬프트만으로 해결되지 않는 문제가 늘었습니다.

파일을 지우기 전에 확인해야 한다든가, 결과를 어느 폴더에 저장해야 한다든가, 다른 에이전트가 만든 결과를 누가 검수해야 한다든가 하는 문제였습니다. 이런 것은 이번 답변을 잘 받기 위한 문장이 아니라 다음 대화에서도 반복해서 지켜야 하는 조건이었습니다.

그래서 저는 프롬프트와 규칙의 역할을 나누기 시작했습니다.

층위	제가 맡기는 역할
프롬프트	지금 해야 할 일과 이번 작업의 조건
AGENTS.md	이 폴더에서 지켜야 할 규칙, 먼저 읽을 것, 결과를 둘 곳
Standards	여러 작업에서 공통으로 지켜야 할 품질 기준
Skill·MCP 같은 도구 계층	반복 절차나 외부 시스템 연결
결정·상태·작업 기록	왜 이렇게 정했는지, 지금 어디까지 왔는지

모든 것을 AGENTS.md 하나에 넣는 것도 답은 아니었습니다. 규칙이 많아질수록 어떤 문서가 기준인지 모호해지고, 같은 내용이 여러 파일에 복제되면 서로 다른 버전이 생겼습니다.

그래서 규칙을 만들 때는 “무엇을 써둘까”보다 **“이 지시는 얼마나 오래 살아야 하고, 어디에서 효력이 있어야 하는가”**를 먼저 봅니다.

이번 작업에서만 필요한 요구라면 프롬프트에 둡니다. 특정 폴더에 들어온 AI가 매번 지켜야 한다면 그 폴더의 진입 규칙에 둡니다. 여러 글이나 프로젝트에 공통으로 적용할 기준이라면 Standards처럼 더 위의 공통 규칙으로 올립니다. 왜 그런 결정을 했는지는 실행 규칙과 섞지 않고 결정 기록에 남깁니다.

2026년 봄부터 대화에서 ’하네스’라는 표현을 쓰기 시작한 것도 같은 맥락이었습니다. 당시 제가 생각한 하네스는 프롬프트 묶음보다 넓었습니다. 에이전트에게 주는 제약, 작업 절차, 필요한 도구와 연결, 사람이 확인해야 할 지점을 함께 보는 방식이었습니다.

이렇게 나누고 나니 프롬프트의 역할도 오히려 단순해졌습니다. 매번 “절대 지우지 마라”, “여기에 저장해라”, “먼저 이 문서를 읽어라”를 길게 반복할 필요가 줄었습니다. 반복되는 조건은 작업 환경이 들고 있고, 프롬프트는 지금 해결할 문제에 더 집중할 수 있었습니다.

규칙은 AI를 더 똑똑하게 만드는 장치가 아닙니다. 같은 실수를 매번 사람의 말로 다시 막지 않기 위한 운영 장치에 가깝습니다.

프롬프트를 잘 쓰는 것보다 규칙이 중요해졌다는 말은 프롬프트가 필요 없다는 뜻도 아닙니다. 둘의 수명이 다릅니다. 프롬프트는 지금의 일을 설명하고, 규칙은 다음 작업자까지 이어져야 할 조건을 남깁니다.