Beyond the Prompt: An Empirical Study of Cursor Rules

이 논문은 오픈소스 저장소 401 개를 분석하여 개발자가 AI 코딩 도구에 제공하는 '커서 규칙'의 특성을 규명하고, 이를 관례, 가이드라인, 프로젝트 정보, LLM 지시사항, 예시 등 5 가지 주요 주제로 분류하는 체계적인 분류론을 제시합니다.

핵심

🍳 제목: "요리사 (AI) 가 최고의 요리를 하려면, 어떤 레시피 (규칙) 가 필요할까?"

이 논문의 핵심은 아주 단순합니다.
"인공지능 (AI) 이 코드를 짜게 할 때, 단순히 '이거 만들어줘'라고만 말하면 안 됩니다. 어떤 스타일의 요리 (프로젝트) 를 하는지, 어떤 재료를 쓰는지, 어떤 맛을 내야 하는지를 미리 알려줘야 해요."

연구자들은 GitHub 에 있는 401 개의 오픈소스 프로젝트에서 개발자들이 작성한 **'커서 규칙 (Cursor Rules)'**이라는 파일들을 분석했습니다. 이를 마치 **"요리사에게 건네는 비밀 레시피 노트"**라고 생각하시면 됩니다.

🔍 연구가 발견한 5 가지 '비밀 레시피' 유형

개발자들이 AI 에게 남긴 지시사항을 분석한 결과, 크게 5 가지 종류로 나뉘었습니다.

1. 🏗️ 프로젝트 정보 (Project): "우리가 무슨 일을 하는 가게야?"

• 비유: 식당의 메뉴판과 주방 환경 설명서입니다.
• 내용: "우리는 한국 식당이야 (프론트엔드)", "불은 가스불이야 (기술 스택)", "오늘은 김치찌개만 만든다 (기능)".
• 이유: AI 가 엉뚱한 요리를 하지 않도록, 우리가 어떤 프로젝트를 하고 있는지 기본 배경을 알려줍니다.

2. 📏 관습 (Convention): "우리는 이렇게 접시를 닦아!"

• 비유: 식당의 매너와 규칙입니다.
• 내용: "접시는 항상 오른쪽에 쌓아라 (코드 스타일)", "소스는 테두리에만 발라라 (파일 구조)", "이름은 한글로 적어라 (네이밍 규칙)".
• 이유: 팀원들이 모두 같은 방식으로 일해야 나중에 요리가 섞여도 깔끔하게 유지됩니다.

3. 💡 가이드라인 (Guideline): "최고의 요리사라면 이렇게 해!"

• 비유: 요리 철학이나 팁입니다.
• 내용: "너무 짜지 않게 해라 (보안)", "손님이 기다리게 하지 마라 (성능)", "재료는 낭비하지 마라 (코드 효율)".
• 이유: 구체적인 규칙보다는 '좋은 코드'를 위한 일반적인 원칙을 알려줍니다.

4. 🤖 AI 전용 지시 (LLM Directive): "너는 이렇게 생각해야 해!"

• 비유: 요리사 (AI) 에게만 주는 특수 훈련입니다.
• 내용: "모르겠으면 무조건 물어봐 (질문하기)", "실수하면 스스로 확인해 (검증)", "너는 한국 요리 전문가야 (역할 부여)".
• 이유: AI 가 사람처럼 행동하도록, 혹은 AI 의 특성에 맞춰서 사고방식을 조절하는 지시입니다. (이 부분이 가장 흥미롭고, 아직 개발자들이 잘 쓰지 않는 영역입니다.)

5. 📝 예시 (Example): "보라, 이렇게 해!"

• 비유: 실제 요리 사진이나 시식용 샘플입니다.
• 내용: "이런 코드는 OK, 저런 코드는 NG" 같은 실제 코드 조각들입니다.
• 이유: 말로 설명하는 것보다 보여 주는 게 빠르니까요.

---

🧐 흥미로운 발견들 (연구 결과)

1. 언어마다 성격이 달라요 (프로그래밍 언어별 차이)

• 자바스크립트/파이썬 (유동적 언어): 규칙이 덜 정해져 있어서, AI 가 헷갈리지 않게 자세한 설명과 예시를 많이 줍니다. (마치 "이건 이렇게 해, 저건 저렇게 해"라고 자세히 알려줘야 하는 상황)
• 자바/고 (강한 타입 언어): 규칙이 이미 정해져 있어서, AI 가 스스로 추론할 수 있어 간단한 설명만 줍니다. (마치 "이건 이미 정해진 대로 해"라고만 말해도 됨)

2. 분야마다 초점이 달라요 (앱 분야별 차이)

• 웹 개발: 예시와 스타일 규칙을 많이 줍니다. (디자인이 중요하니까)
• 데이터 분석/AI 에이전트: "실수하지 마", "검증해 봐" 같은 **주의 사항 (가이드라인)**을 많이 줍니다. (결과가 중요하니까)

3. "복사 - 붙여넣기"가 많아요 (재사용성)

• 개발자들이 처음부터 다 쓰는 게 아니라, 다른 프로젝트의 레시피를 베껴서 쓰는 경우가 28% 나 됩니다.
• 특히 "AI 가 어떻게 행동해야 해"라는 지시사항은 거의 다 비슷하게 복사해 옵니다. (아직 AI 에게 어떻게 지시해야 할지 정해진 '표준 레시피'가 없어서, 다들 비슷하게 쓰는 것 같습니다.)

4. 시간이 지날수록 변해요 (시간에 따른 변화)

• 새로 생긴 프로젝트: "우리는 이런 프로젝트야"라고 기본 정보를 많이 줍니다.
• 오래된 프로젝트: 기본 정보는 줄이고, **"AI 가 실수하지 않게 조심해"**라는 지시사항을 더 많이 줍니다. (프로젝트가 커질수록 AI 가 망치지 않게 통제하는 게 중요해지기 때문입니다.)

---

💡 이 연구가 우리에게 주는 교훈

1. AI 는 '배경지식'이 필요해요: AI 가 코드를 잘 짜려면, 프로젝트의 분위기, 규칙, 철학을 미리 알려주는 '레시피 노트'가 필수적입니다.
2. 복사 - 붙여넣기는 비효율적일 수 있어요: 이미 AI 가 알고 있는 정보를 반복해서 적으면, AI 가 중요한 정보를 놓칠 수 있습니다. (예: "우리는 한국 식당이야"라고 이미 문서에 써 있는데, 레시피 노트에도 똑같이 적는 것)
3. 앞으로 더 똑똑한 도구가 필요해요: 개발자가 직접 모든 규칙을 짜는 대신, **"이 프로젝트에는 이런 규칙이 필요해"**라고 AI 가 스스로 제안해 주는 도구가 나오면 좋겠습니다.

🎯 결론

이 논문은 **"AI 와 함께 일할 때, 개발자가 어떻게 '비밀 지시서'를 작성하는지"**를 처음부터 끝까지 분석한 보고서입니다.

앞으로 AI 코딩 도구를 쓸 때, 단순히 "이거 만들어줘"라고만 하지 말고, 프로젝트의 성격, 규칙, 그리고 AI 에게 필요한 특수 지시를 잘 정리해서 알려주면 훨씬 더 멋진 코드를 얻을 수 있다는 것을 알려줍니다. 마치 요리사에게 "오늘은 손님들이 피곤하니까 가볍고 맛있는 요리를 만들어줘"라고 구체적으로 말해주는 것과 같습니다.

기술 요약

1. 연구 배경 및 문제 정의 (Problem)

• 배경: 대규모 언어 모델 (LLM) 의 성능은 단순한 프롬프트뿐만 아니라 제공되는 맥락 (Context) 에 크게 의존합니다. 특히 소프트웨어 공학 분야에서는 프로젝트의 목표, 아키텍처, 협업 관행 등이 응답 품질에 결정적인 역할을 합니다.
• 문제: 많은 AI 코딩 어시스턴트 (예: Cursor IDE) 가 개발자가 프로젝트의 고유한 제약 조건을 인코딩할 수 있는 지속적이고 기계가 읽을 수 있는 지시문 (Cursor Rules) 을 작성할 수 있게 했습니다. 그러나 이러한 규칙 파일의 내용과 구조가 어떻게 구성되는지에 대한 체계적인 연구는 전무했습니다.
• 필요성: 과도하거나 최적화되지 않은 맥락은 응답의 정확도를 떨어뜨리고 비용 및 지연 시간을 증가시킬 수 있습니다. 개발자가 AI 와 협업할 때 무엇을 중요하게 생각하는지, 그리고 어떤 패턴이 존재하는지 이해하는 것은 차세대 AI 도구의 설계에 필수적입니다.

2. 연구 방법론 (Methodology)

• 연구 대상: GitHub 의 공개 저장소 중 .mdc 확장자를 가진 커서 규칙 파일을 포함하는 401 개의 오픈소스 저장소를 대상으로 한 질적 연구 (Qualitative Study).
• 데이터 수집 및 전처리:
  • Sourcegraph 를 사용하여 GitHub 의 모든 공개 저장소 검색.
  • 포크/아카이브된 저장소 제외, 영어가 아닌 파일, 템플릿/예시 파일, 중복 데이터 등을 정제하여 최종 401 개 저장소 선정.
  • 총 1,876 개의 .mdc 파일 분석.
• 분석 기법:
  • 주제 분석 (Thematic Analysis): 401 개 저장소 중 30 개를 층화 표본 추출 (Stratified Sampling) 하여 초기 코딩 (Open Coding) 수행.
  • LLM 보조 코딩: 초기에 도출된 코딩 체계 (Coding Scheme) 를 바탕으로 LLM(Gemini-2.5-flash) 을 활용하여 전체 401 개 저장소의 규칙을 라인 단위로 코딩. 인간 연구자와 LLM 간의 일관성 (Cohen's Kappa ≈ 0.64~0.71) 을 검증.
  • 정량적 분석: 코딩된 데이터를 바탕으로 프로그래밍 언어, 애플리케이션 도메인, 규칙 작성 시기 등에 따른 맥락 유형 분포 분석.

3. 주요 기여 및 분류 체계 (Key Contributions & Taxonomy)

개발자가 커서 규칙에 제공하는 맥락의 유형을 5 가지 상위 주제와 20 가지 세부 코드로 분류한 종합적인 분류 체계 (Taxonomy) 를 제시했습니다.

상위 카테고리	정의 및 하위 요소	주요 특징
1. 프로젝트 (Project)	소프트웨어 프로젝트의 기술 스택, 아키텍처, 변경 사항 등을 설명.	환경 설정, 기능 설명, 최신 업데이트 내용 포함.
2. 관습 (Convention)	프로젝트 내 코드 작성 및 조직화를 위한 표준.	코드 스타일, 언어/프레임워크 특화 관습, 프로젝트 구조 규칙.
3. 가이드라인 (Guideline)	개발자가 따라야 할 고수준 원칙 및 모범 사례.	QA(테스트), 일반 프로그래밍 원칙, 커뮤니케이션, 성능, 보안, 의존성 관리 등.
4. LLM 지시문 (LLM Directive)	LLM 의 행동과 응답 방식을 직접 지시하는 규칙.	행동 (질문하기, 검증), 워크플로우 (단계별 수행), 페르소나, 출력 형식, 상세도 조절.
5. 예시 (Example)	올바른/부적절한 사례 또는 템플릿 제공.	실제 코드 스니펫이나 링크를 통한 구체적 설명.

4. 주요 연구 결과 (Results)

RQ1: 프로그래밍 언어별 차이

• 정적 타입 언어 (Go, C#, Java): 타입 시스템이 컴파일 시점에 오류를 잡아주므로 상대적으로 맥락 제공량이 적음.
• 동적 타입 언어 (JavaScript, PHP): 타입 체크 및 오류 처리에 대한 추가 맥락이 필요하여 가이드라인 및 프로젝트 관련 맥락이 더 많음.
• 특이점: C# 등 엔터프라이즈/게임 개발 언어는 LLM 지시문 (Behavior) 이 상대적으로 많음. JavaScript/TypeScript 는 빠른 프레임워크 변화로 인해 예시 (Example) 가 많이 포함됨.

RQ2: 애플리케이션 도메인별 차이

• 복잡한 워크플로우 (데이터 분석, 웹 개발): 구체적인 예시 제공 빈도가 높음.
• API 정보가 부족한 도메인 (MCP Tools 등): 프로젝트 이해를 돕기 위해 프로젝트 정보를 더 많이 제공.
• 불확실성이 높은 도메인 (LLM 에이전트, 데이터 분석): 실행 전 신중한 고려가 필요하므로 가이드라인 관련 맥락이 많음.

RQ3: 규칙 재사용 (Duplication)

• 전체 코드 라인의 약 28.7% 가 다른 저장소나 템플릿에서 복사된 중복 코드임.
• LLM 지시문 카테고리의 중복률이 가장 높음 (일반화하기 쉬움).
• 개발자는 커뮤니티 템플릿 (예: awesome-cursor-rules) 이나 종속성 문서에서 규칙을 복사하여 사용.

RQ4: 맥락의 공존 (Co-occurrence)

• 개발자는 단일 유형이 아닌 다양한 맥락 유형을 종합적으로 제공하는 경향이 있음.
• 약 37% 의 저장소가 프로젝트, 관습, 가이드라인, LLM 지시문 등 4 가지 핵심 카테고리를 모두 포함.
• 대부분의 저장소는 3~15 개의 고유한 코드를 포함하여 맥락의 양을 적절히 조절 (과부하 방지).

RQ5: 시간적 변화 (Repository Age)

• 새로운 저장소: LLM 의 한계와 능력을 더 잘 인식하여 LLM 지시문을 더 많이 포함.
• 오래된 저장소: 프로젝트 유지보수 중심이며, 프로젝트 정보나 관습 관련 맥락이 상대적으로 줄어듦.
• 전반적 경향: 프로젝트가 성숙해질수록 불필요한 세부 사항을 줄이고 핵심 가이드라인과 LLM 지시문에 집중하는 경향.

5. 의의 및 시사점 (Significance & Implications)

1. 맥락 투명성 (Context Transparency) 강화: 개발자가 AI 가 이미 접근 가능한 정보 (문서 등) 를 중복으로 제공하거나, AI 가 이해하지 못하는 외부 링크만 남기는 비효율적인 관행이 발견됨. AI 도구가 현재 어떤 맥락을 참조하고 있는지 실시간으로 피드백하는 기능이 필요함.
2. 맥락 인식 규칙 생성 (Context-Aware Rule Generation): 현재 개발자들은 템플릿을 복사하거나 LLM 에게 규칙을 생성하게 하지만, 이는 프로젝트 특성 (언어, 도메인) 에 최적화되지 않음. 프로젝트 특성에 맞춰 자동으로 최적화된 규칙을 생성하는 도구의 필요성이 대두됨.
3. 교육 및 모범 사례: 개발자들이 무엇을 제공해야 하는지 불확실해하는 경향이 있음. 본 연구에서 도출된 분류 체계는 개발자 교육 자료 및 AI 어시스턴트의 온보딩 가이드로 활용 가능.
4. 향후 연구 방향: 규칙의 실제 효과성 (Task Performance) 을 정량적으로 평가하고, 시간이 지남에 따라 규칙이 어떻게 진화하는지에 대한 종단적 연구 (Longitudinal Study) 가 필요함.

결론

본 논문은 개발자가 AI 코딩 어시스턴트에게 제공하는 맥락의 첫 번째 대규모 실증 연구로, 5 가지 주요 맥락 유형을 체계화했습니다. 이 연구는 AI 가 프로젝트의 고유한 맥락을 더 잘 이해하고, 개발자가 더 효과적으로 AI 와 협업할 수 있도록 하는 차세대 도구 설계의 기초를 제공합니다.