Cursor(커서) AI로 코딩할 때 프롬프트를 아무리 자세히 써도, 매번 쓰던 라이브러리 대신 엉뚱한 패키지를 새로 설치하거나 기존 코드 컨벤션을 무시하고 갈아엎어 버리는 경우가 많습니다.
매 대화마다 "타입스크립트 최신 문법 써줘", "불필요한 주석 달지 마"라고 반복하다 보면 토큰 소모도 심하고 피로감도 커집니다.
이를 방지하려면 프로젝트 루트에 규칙 파일(.cursorrules 또는 최근 버전의 .cursor/rules/*.mdc)을 제대로 세팅해 두는 것이 필수입니다. 실제로 써보며 정착한 핵심 세팅 노하우 3가지 정리해 둡니다.
1. 프로젝트 컨텍스트와 기본 기술 스택을 명시적으로 고정하기
프로젝트에서 사용하는 프레임워크 버전, 상태 관리 라이브러리, 패키지 매니저(pnpm/yarn/npm)를 파일 상단에 명확히 적어둡니다. "새로운 라이브러리를 임의로 설치하지 말고 기존 package.json에 명시된 의존성만 활용할 것"이라는 규칙을 한 줄 박아두는 것만으로도, AI가 사소한 유틸 함수 하나 구현하겠다고 생소한 패키지를 마음대로 임포트하는 대참사를 막을 수 있습니다.
2. 장황한 에세이 대신 명확한 'Do / Don't' 불릿 포인트로 작성하기
지침을 줄글로 길게 적으면 AI가 규칙의 중요도를 혼동하거나 뒷부분 지침을 건너뛰기 쉽습니다. 다음과 같이 Do와 Don't로 명확하게 끊어서 적어주는 편이 모델의 준수율이 훨씬 높습니다.
- Do: 변경이 필요한 함수와 블록만 출력하고, 수정되지 않은 기존 코드는 생략할 것
- Do: 에러 핸들링 시 프로젝트 표준 커스텀 에러 클래스를 사용할 것
- Don't: 동작 중인 기존 로직이나 타입 정의를 사용자 허가 없이 임의로 삭제하거나 리팩터링하지 말 것
- Don't: 코드 변경 이유에 대한 장황한 서론이나 인사말 출력 금지
3. 전역 규칙(User Rules)과 프로젝트별 규칙 분리하기
모든 프로젝트에 공통으로 적용될 기본 취향(예: "간결한 한국어로 설명할 것", "코드 변경점 위주로 담백하게 답할 것")은 Cursor 설정(Cursor Settings > Rules)의 User Rules에 넣어두고, 디렉토리 구조나 특정 API 설계 원칙 같은 개별 규칙은 반드시 프로젝트 내 규칙 파일로 분리해야 합니다. 전역 규칙에 특정 프로젝트 스택을 섞어두면 다른 레포지토리 작업 시 엉뚱한 코드가 튀어나오는 원인이 됩니다.
(이미지 출처: 구글 검색)
미리 규칙 파일 하나만 깔끔하게 구성해 두면 프롬프트에 구구절절 제약 조건을 붙일 필요 없이 핵심 요구사항만 던져도 코드가 규격에 맞춰 착착 나옵니다. 커서로 개발 환경 세팅하시는 분들은 참고하시면 좋을 것 같습니다.