시스템·유저·프로젝트 프롬프트를 어떻게 나누나?
에이전트가 “이상한 규칙”을 따르는 것처럼 보일 때는, 보통 한 파일이 아니라 여러 계층이 한꺼번에 컨텍스트에 실려 있습니다. Cursor에서는 팀·프로젝트·유저 규칙이 합쳐지고, 채팅 한 줄·슬래시 커맨드가 그 위에 얹힙니다. 가격·Skills 전체 비교·commands 파일 작성법은 다루지 않습니다.
이 글은 어디에 무엇을 둘지, 충돌 시 누가 이기는지, 너무 길면 어떻게 쪼갤지만 정리합니다. 근거는 Rules, Agent overview, Customize Cursor입니다.
어디에 무엇을?
한 줄 답: 조직 공통·컴플라이언스 → Team(시스템급), 레포·도메인 → Project, 말투·개인 취향 → User, 이번 작업만 → 채팅(또는 / 커맨드) 입니다.
실무에서 “시스템·유저·프로젝트”를 Cursor 문서에 맞춰 매핑하면 다음과 같습니다.
| 계층(실무 이름) | Cursor에 해당하는 것 | 두는 내용 | 두지 말 것 |
|---|---|---|---|
| 시스템급 | Team Rules(대시보드) + 제품이 넣는 Agent 시스템 지시 | 보안·라이선스·금지 경로, 조직 표준 | 개인 말투, 한 레포만의 API 관례 |
| 프로젝트 | .cursor/rules/*.mdc, 루트·중첩 AGENTS.md | 빌드/테스트 명령, 아키텍처, 도메인 제약, glob별 스타일 | “가끔만” 돌릴 긴 체크리스트 전부 |
| 유저 | Customize → Rules(User Rules) | 답변 길이·언어·개인 코딩 취향 | 팀 전원에게 강제할 정책 |
| 턴(이번 대화) | 채팅 메시지, (선택) .cursor/commands /이름 | 이번 목표·범위·성공 기준 | 매 채팅에 반복할 상시 규칙 |
배치 감각:
- 모든 레포·모든 사람에게 동일해야 하면 Team(또는 조직이 강제하는 규칙)입니다.
- 이 코드베이스에서만 맞으면 Project Rules /
AGENTS.md입니다. 단순하면AGENTS.md, 적용 조건(Always / Intelligent / globs /@rule)이 필요하면.mdc입니다. - 내 머신에서만 편하면 User Rules입니다. 문서상 User Rules는 Agent(Chat)에 쓰이며 Inline Edit(Cmd/Ctrl+K)에는 적용되지 않습니다.
- 오늘 한 번이면 채팅에 적거나
/커맨드로 뽑습니다. 지속 계층에 워크플로 소설을 넣지 않습니다.
Skills vs Rules·commands 글과의 경계: 이 글은 계층·우선순위입니다. Skills는 패키지된 능력, commands는 /로 명시 호출하는 재사용 프롬프트입니다. “항상 스며드는 지시” vs “그때 꽂는 절차”는 여기 표의 턴 행과 Project/User 행으로만 구분합니다.
충돌 시 우선순위는?
한 줄 답: Cursor 문서 기준 규칙 충돌 시 Team → Project → User 순으로 앞선 쪽이 이깁니다. 같은 프로젝트 안에서는 더 구체적인 지시(중첩 AGENTS.md, 매칭 glob)를 우선해 읽습니다. 이번 채팅의 명시 요청은 그 턴의 목표로 위에 얹히지만, 조직이 Enforce한 Team Rule을 채팅 한 줄로 지우지는 않습니다.
공식 Rules 문서의 병합 순서:
| 순위 | 소스 | 충돌 시 |
|---|---|---|
| 1 | Team Rules | 앞섬. Enforce면 멤버가 Customize에서 끌 수 없음 |
| 2 | Project Rules / 적용 중인 AGENTS.md | 레포·경로 맥락 |
| 3 | User Rules | 개인 전역; 팀·프로젝트와 어긋나면 양보 |
실무에서 자주 나는 충돌 패턴:
- User “짧게 답해” vs Project “변경마다 테스트 로그를 붙여라” → 프로젝트 절차가 이깁니다. 유저 규칙은 말투만 유지합니다.
- Team “시크릿·프로덕션 자격 증명 금지” vs 채팅 “
.env내용 보여줘” → Team(및 안전 정책)이 이깁니다. 채팅은 목표를 바꾸지, 강제 규칙을 덮어쓰지 않는다고 가정합니다. - 루트
AGENTS.md“npm test” vspackages/api/AGENTS.md“pnpm test:api” → 중첩 문서는 해당 디렉터리·하위 작업에서 더 구체적입니다. Cursor는 중첩AGENTS.md를 부모와 합치되, 더 구체적인 쪽이 우선한다고 안내합니다. - Always Project Rule vs Intelligent/globs Rule → Always는 매 세션에 실리고, glob/설명 기반은 관련 파일이 있을 때 붙습니다. “가끔만” 필요한 긴 절은 Always에 넣지 않습니다.
우선순위를 팀에 공유할 때 한 줄로 적어두면 디버깅이 빨라집니다. 예: “보안·금지 = Team, 레포 관례 = Project, 말투 = User, 절차 단축 = commands.”
너무 길면?
한 줄 답: 규칙은 대략 500줄 미만·쪼개서, Always에는 짧은 제약만, 긴 절차는 commands나 Intelligent/globs로 옮기고, 레포 설명은 **중첩 AGENTS.md**로 나눕니다.
길어지는 신호:
- Always 규칙 하나에 스타일 가이드·릴리스 절차·API 카탈로그가 한 파일에 있음
- User Rules에 회사 정책·레포별 빌드 명령이 섞여 전 프로젝트에 유출됨
- 같은 문장이 Team / Project /
AGENTS.md/ README에 복붙되어 어긋남 - Agent가 규칙을 “잊는” 것처럼 보이는데, 실제로는 컨텍스트 예산에 오래된 Always만 잔뜩 실림
줄이는 순서:
- Always → 짧게. 금지·필수 헤더·테스트 최소 기준만 남깁니다. (Rules 권장: 500줄 미만, 큰 규칙은 여러 개로 분할)
- 경로별은 globs.
src/components/**/*.tsx처럼 파일에 붙는 규칙으로 나눕니다. - 가끔 같은 절차는
.cursor/commands./로만 호출하면 매 채팅 비용이 없습니다. (커맨드 파일 위치·인자는 commands 글 축) - 모노레포는 중첩
AGENTS.md. 루트는 공통, 패키지는 로컬 명령만. - 코드·문서를
@로 참조. 규칙에 전문을 복붙하지 말고 예시 파일을 가리킵니다. 문서도 “복붙 대신 참조”를 권합니다. - 중복 삭제. Team에 있는 문장을 Project에 다시 쓰지 않습니다. Project에는 “Team 보안 규칙을 따른다” 한 줄이면 됩니다.
Agent overview가 말하는 구성(Instructions + Tools + Model)에서, 사용자가 가꿀 수 있는 쪽은 주로 Instructions(규칙·AGENTS·채팅) 입니다. 길이를 줄이는 일은 “더 똑똑한 모델”이 아니라 계층을 맞게 쓰는 일입니다.
FAQ
User Rules와 Project Rules가 동시에 보이면 뭐가 적용되나요?
둘 다 병합됩니다. 내용이 충돌하면 문서상 Project가 User보다 앞입니다. Team이 있으면 Team이 가장 앞입니다.
AGENTS.md만 있어도 .cursor/rules가 필요한가요?
단순한 레포 지시만이면 AGENTS.md로 충분합니다. Always/globs/@rule처럼 적용 조건을 나누려면 .mdc Project Rules가 맞습니다. 둘을 같이 쓸 때는 같은 문장을 두 곳에 복붙하지 않습니다.
채팅에서 “이 규칙은 무시해”라고 하면 되나요?
턴 목표는 바꿀 수 있지만, Enforce Team Rule·보안 금지를 채팅으로 해제한다고 가정하지 않습니다. 개인 Always를 줄이려면 Customize에서 끄거나 파일을 짧게 고칩니다.
Skills·commands와 이 글의 차이는?
계층(어디에 상시로 두나) 이 축입니다. Skills 매트릭스, /migrate-to-skills, 커맨드 인자·파일 작성 상세, 요금·한도 숫자는 다루지 않습니다.
출처 (Sources)
- Rules — Team / Project / User / AGENTS.md, 충돌 시 Team → Project → User
- Agent overview — Instructions + Tools + Model
- Customize Cursor — Rules·Commands 등 사용자 맞춤 진입점