Cursor로 코드를 짜다 보면 이상하게 반복되는 순간이 있습니다. 분명 우리 프로젝트는 함수형 컴포넌트만 쓰는데 AI는 자꾸 클래스로 짜고, 들여쓰기는 스페이스로 통일했는데 탭을 섞어 넣고, 임포트는 절대경로 규칙인데 상대경로로 불러옵니다. 그때마다 채팅창에 "우린 이렇게 쓴다"고 다시 설명하고 고쳐 받죠. 문제는 다음 대화창을 열면 AI가 그 약속을 깨끗이 잊는다는 겁니다. 이 글에서는 Cursor AI 개발에서 매번 같은 지적을 반복하지 않도록, 프로젝트의 규칙을 한 번만 적어두고 계속 재사용하는 방법을 정리합니다.
참고로 아래 기능·명칭은 본 글 작성 시점(2026년 7월) 기준이며, Cursor는 업데이트가 잦은 도구라 세부 UI나 문법은 바뀔 수 있습니다.
왜 Cursor AI 개발에선 매번 같은 걸 다시 알려줘야 할까
원인은 도구의 게으름이 아니라 언어 모델의 근본 구조에 있습니다. 대규모 언어 모델은 한 번의 응답을 끝내고 나면 그 대화의 기억을 따로 저장하지 않습니다. 우리가 "다음부터는 이렇게 해줘"라고 말해도, 그 문장은 지금 열려 있는 대화의 맥락(context) 안에서만 유효합니다. 새 채팅을 열면 AI 입장에서는 다시 백지 상태인 셈입니다.
그래서 벌어지는 낭비가 두 가지입니다. 첫째, 같은 프로젝트인데도 대화를 새로 열 때마다 "우리 스택은 뭐고, 폴더 구조는 어떻고, 이런 표현은 쓰지 말라"를 처음부터 다시 타이핑합니다. 둘째, 어제 애써 교정한 스타일이 오늘 그대로 되살아나 또 고쳐야 합니다. 결국 AI에게 일을 시키는 시간보다 AI를 우리 프로젝트에 맞게 길들이는 시간이 더 들어가는 역전이 생깁니다.
해결의 실마리는 단순합니다. 매 대화마다 말로 전달하던 규칙을, 프로젝트 안에 파일로 한 번만 적어두는 것입니다. 그러면 Cursor가 그 파일을 알아서 프롬프트에 얹어 AI에게 매번 전달합니다. 이 장치가 바로 Cursor Rules입니다.
Cursor Rules — 프로젝트 규칙을 한 번 적어두는 곳
Cursor Rules는 우리가 자연어로 적어둔 지시문을, AI가 코드를 생성하기 전에 먼저 읽도록 하는 기능입니다. "이 프로젝트는 이런 규칙으로 움직인다"를 파일로 남겨두면, Cmd+K 인라인 편집이든 채팅이든 에이전트 작업이든 그 내용이 함께 전달됩니다. 규칙을 담는 방식은 현재 크게 세 가지가 있습니다.
1) .cursor/rules 디렉터리의 .mdc 파일 (현재 권장 방식)
2026년 기준 표준은 프로젝트 안에 .cursor/rules/ 폴더를 만들고 그 안에 .mdc 확장자 파일들을 두는 방식입니다. .mdc는 마크다운 본문 위에 짧은 설정(프론트매터)을 얹은 형식으로, 규칙마다 "언제 적용할지"를 지정할 수 있습니다. 주제별로 파일을 쪼갤 수 있어서, 예를 들어 프런트엔드 규칙과 테스트 작성 규칙, API 호출 규칙을 각각 다른 파일로 관리할 수 있습니다.
2) .cursorrules 파일 (레거시 단일 파일)
예전에는 프로젝트 루트에 .cursorrules라는 파일 하나에 모든 규칙을 몰아넣었습니다. 지금도 동작하지만, 규칙이 많아지면 한 파일이 비대해지고 상황과 무관한 내용까지 매번 딸려 들어간다는 단점이 있습니다. 새로 시작한다면 .mdc 방식을, 기존 .cursorrules가 있다면 주제별 .mdc로 나눠 옮기는 편이 관리가 쉽습니다.
3) AGENTS.md와 전역 설정
메타데이터 없이 그냥 마크다운 한 장으로 간단히 규칙을 두고 싶다면 프로젝트 루트의 AGENTS.md를 쓸 수도 있습니다. 다만 파일 패턴별로 규칙을 켜고 끄는 세밀한 제어는 .mdc 쪽이 유리합니다. 한편 프로젝트가 아니라 "나는 항상 이런 톤으로 답해달라" 같은 개인 취향은 Cursor 설정의 전역 규칙(Rules for AI)에 적어두면 모든 프로젝트에 공통 적용됩니다.
규칙이 켜지는 네 가지 방식
규칙을 무조건 항상 넣으면 오히려 맥락이 규칙으로만 가득 차버립니다. 그래서 .mdc 규칙은 상황에 따라 켜지도록 네 가지 적용 방식을 제공합니다.
- Always Apply(항상 적용) — 모든 요청에 무조건 포함됩니다. 프로젝트 전반의 핵심 원칙만 짧게 담는 용도입니다.
- Auto Attached(글롭 자동) —
*.tsx처럼 파일 패턴(glob)을 지정해, 해당 파일을 다룰 때만 규칙이 붙습니다. - Agent Requested(설명 기반) — 규칙에 짧은 설명을 달아두면, AI가 그 작업에 관련 있다고 판단할 때 스스로 불러옵니다.
- Manual(수동 호출) — 평소엔 꺼져 있다가
@규칙이름으로 직접 부를 때만 적용됩니다.
이 구분 덕분에 "테스트 작성 규칙"은 테스트 파일을 만질 때만, "배포 스크립트 규칙"은 내가 부를 때만 켜지도록 설계할 수 있습니다. 각 방식의 정확한 동작과 최신 문법은 Cursor 공식 문서에서 확인하는 것이 가장 안전합니다.
실전 팁 — 규칙을 제대로 쓰는 법
기능을 아는 것과 잘 쓰는 것은 다릅니다. 규칙 파일을 만들 때 효과를 보려면 다음을 지키는 게 좋습니다.
짧고 구체적으로, 그리고 주제별로 쪼갠다
항상 적용되는 규칙은 매 요청마다 맥락을 차지합니다. 커뮤니티에서 흔히 권하는 기준은 항상 적용 규칙을 200단어 안팎으로 짧게 유지하라는 것입니다. "좋은 코드를 짜라" 같은 추상적 문장 대신 "날짜는 반드시 ISO 8601로", "새 컴포넌트는 components 폴더에"처럼 검증 가능한 지시로 적으세요. 그리고 하나의 거대한 파일 대신 프런트엔드·테스트·데이터 접근처럼 주제별로 파일을 나누면, 상황에 맞는 규칙만 켜지게 만들 수 있습니다.
추상적 규칙과 구체적 규칙의 차이
같은 의도라도 어떻게 적느냐에 따라 효과가 크게 갈립니다. 예를 들어 "코드를 깔끔하게 작성해줘"는 사람마다 해석이 달라 AI에게도 별 도움이 되지 않습니다. 반면 "한 함수는 한 가지 일만 하도록 나누고, 매개변수가 4개를 넘으면 객체로 묶어라"처럼 적으면 AI가 따를 기준이 분명해집니다. "주석은 왜(why)를 설명하고, 무엇을(what) 하는지는 코드로 드러나게 하라" 같은 문장도 좋은 예입니다. 규칙을 적을 때는 '지켰는지 아닌지 눈으로 확인할 수 있는가'를 기준으로 삼으면 대부분 구체적으로 바뀝니다.
범위는 glob으로, 참조는 @로
특정 폴더나 확장자에만 필요한 규칙은 Always가 아니라 Auto Attached로 두고 glob 패턴을 지정하세요. 반대로 코드를 작성시킬 때 특정 파일이나 문서를 근거로 삼게 하려면, 채팅에서 @로 파일·폴더 등을 직접 지목해 맥락에 넣어줄 수 있습니다. 규칙(무엇을 지킬지)과 참조(무엇을 근거로 할지)를 나눠 생각하면 프롬프트가 훨씬 깔끔해집니다.
반복된 지적을 규칙으로 승격시킨다
가장 실용적인 습관입니다. 채팅에서 같은 교정을 두 번 이상 하고 있다면, 그건 규칙 파일로 옮길 신호입니다. "또 상대경로로 짰네"를 세 번째로 고치는 대신, 그 문장을 규칙에 한 줄 추가하세요. 이렇게 하면 규칙 파일이 팀의 실제 관행을 담은 살아 있는 문서로 자라고, 나중에 합류한 동료의 AI도 같은 기준을 따르게 됩니다.
규칙이 만능은 아니다
규칙은 프롬프트에 얹히는 '강한 안내'일 뿐 절대적 강제는 아닙니다. 맥락이 길어지거나 지시가 서로 충돌하면 AI가 규칙을 놓칠 수 있습니다. 그래서 규칙을 걸어두더라도 AI가 내놓은 코드는 여전히 사람이 확인해야 합니다. 규칙은 '매번 설명하는 수고'를 없애주는 장치이지, 검토를 없애주는 장치가 아닙니다.
결론
Cursor AI 개발에서 같은 지적을 반복하고 있다면, 그건 AI가 우둔해서가 아니라 우리가 프로젝트의 규칙을 아직 파일로 남겨두지 않았기 때문입니다. 대화가 끝나면 사라지는 말 대신, .cursor/rules에 규칙을 한 번 적어두면 그 약속이 모든 대화에 자동으로 따라붙습니다. 오늘 채팅에서 두 번 이상 고쳐준 지적이 있다면, 그 한 줄을 지금 규칙 파일로 옮겨 적는 것부터 시작해보세요.
본 글은 정보 제공을 목적으로 하며, 언급한 도구의 기능·명칭은 2026년 7월 작성 시점 기준입니다. 최신 사양은 각 서비스 공식 문서를 확인하시기 바랍니다.
댓글 없음:
댓글 쓰기