대규모 코드베이스로 작업하면 소규모 프로젝트와는 다른 새로운 도전 과제가 생겨. Cursor 자체 코드베이스를 확장해 온 우리의 경험과 거대한 코드베이스를 운영하는 고객들의 인사이트를 바탕으로, 높아진 복잡도를 다루는 데 유용한 몇 가지 패턴을 정리했어. 이 가이드에선 우리가 대규모 코드베이스에서 효과적이라고 확인한 몇 가지 기법을 살펴볼 거야.

​
Chat을 사용해 낯선 코드 빠르게 파악하기

특히 처음 접하는 대규모 코드베이스를 탐색하는 건 꽤 어렵지. 보통은 grep하고, 검색하고, 여기저기 클릭해가며 필요한 부분을 찾게 돼. Chat을 쓰면 궁금한 걸 물어보면서 찾고자 하는 내용을 빠르게 찾아내고, 동작 방식에 대한 상세한 설명도 받아볼 수 있어. 여기서는 Cursor에서 코드베이스 인덱싱의 구현 세부를 찾는 데 도움을 받고, 이해를 쉽게 하려고 예시까지 요청하고 있어.

​
도메인별 지식을 위한 규칙 작성하기

새로운 협업자를 코드베이스에 온보딩한다면, 의미 있는 기여를 바로 시작할 수 있게 어떤 컨텍스트를 줄 거야? 이 질문에 대한 네 답변은 Cursor가 이해하는 데에도 꽤 가치 있는 정보일 가능성이 높아. 조직이나 프로젝트마다 문서에 다 담기지 않는 암묵지가 있어. 규칙을 효과적으로 쓰는 게 Cursor가 전체 그림을 제대로 파악하게 하는 가장 좋은 방법이야. 예를 들어, 새로운 기능이나 서비스를 구현하는 방법을 문서화한다면, 후속 참고를 위해 짧은 규칙으로 남겨두는 걸 고려해봐.
Boilerplate
---
description: Add a new VSCode frontend service
---

1. **Interface Definition:**
   - `createDecorator`를 사용해 새 서비스 인터페이스를 정의하고, 오류를 피하려면 `_serviceBrand`가 포함되어 있는지 확인해.

2. **Service Implementation:**
   - 새 TypeScript 파일에서 `Disposable`을 상속해 서비스를 구현하고, `registerSingleton`으로 싱글톤으로 등록해.

3. **Service Contribution:**
   - 서비스를 임포트·로딩하는 컨트리뷰션 파일을 만들고, 메인 엔트리포인트에 등록해.

4. **Context Integration:**
   - 애플리케이션 전반에서 접근할 수 있도록 컨텍스트에 새 서비스를 추가해.
Cursor가 반드시 지켜줬으면 하는 공통 포맷팅 패턴이 있다면, glob 패턴에 따라 규칙을 자동으로 첨부하도록 설정해봐.
Formatting
---
globs: *.ts
---
- 패키지 매니저로 bun을 사용해. 스크립트는 [package.json](mdc:backend/reddit-eval-tool/package.json)을 참고
- 파일 이름은 kebab-case를 사용
- 함수와 변수 이름은 camelCase를 사용
- 하드코딩된 상수는 UPPERCASE_SNAKE_CASE를 사용
- `const foo = () =>` 대신 `function foo()`를 선호
- `T[]` 대신 `Array<T>`를 사용
- 기본 내보내기 대신 이름 있는 내보내기를 사용, 예: (`export const variable ...`, `export function `)

​
계획 수립 프로세스에 밀착해서 진행하기

큰 변경사항일수록, 정확하고 범위가 명확한 계획을 세우기 위해 평소보다 더 신중하게 고민하면 Cursor의 출력 품질이 크게 좋아져. 같은 프롬프트로 몇 번 변형해도 원하는 결과가 나오지 않으면, 시야를 넓혀서 아예 처음부터 더 자세한 계획을 만들어봐. 마치 동료를 위한 PRD를 작성하듯이. 종종 어려운 부분은 무엇을 바꿔야 하는지 정하는 거고, 이건 사람이 잘하는 일이야. 올바른 지시만 있으면 구현의 일부는 Cursor에게 맡길 수 있어. 계획 수립 프로세스를 AI로 보강하는 한 가지 방법은 Ask 모드를 쓰는 거야. 계획을 만들려면 Cursor에서 Ask 모드를 켜고 프로젝트 관리 시스템, 내부 문서, 혹은 흩어진 메모에서 가지고 있는 컨텍스트를 전부 던져줘. 코드베이스에서 포함하려고 이미 정해둔 파일과 의존성에 대해 생각해봐. 통합하려는 코드 조각이 들어 있는 파일일 수도 있고, 아예 전체 폴더일 수도 있어. 예시 프롬프트는 다음과 같아:
Planning prompt
- create a plan for how we shoud create a new feature (just like @existingfeature.ts)
- ask me questions (max 3) if anything is unclear
- make sure to search the codebase

@Past Chats (my earlier exploration prompts)

here's some more context from [project management tool]:
[pasted ticket description]
우리는 모델에게 계획을 만들고, 사람이 답할 수 있는 질문을 통해 컨텍스트를 수집하며, 이전 탐색 프롬프트와 티켓 설명을 참고하도록 요청하고 있어. 변경 의도를 이해하고 계획을 더 잘 종합할 수 있는 claude-3.7-sonnet, gemini-2.5-pro, o3 같은 thinking 모델을 쓰는 걸 추천해. 이렇게 하면 구현을 시작하기 전에 Cursor의 도움을 받아 계획을 점진적으로 다듬을 수 있어.

​
일에 맞는 도구를 제대로 고르기

Cursor를 제대로 쓰려면 작업에 맞는 도구를 고르는 게 정말 중요해. 뭘 하려는지 생각하고, 흐름을 끊지 않는 접근을 선택해.
ToolUse caseStrengthLimitation
Tab빠른 수동 수정완전한 제어, 빠름단일 파일
Inline Edit한 파일 내 범위 지정 변경집중된 편집단일 파일
Chat대규모·다중 파일 변경컨텍스트 자동 수집, 심층 편집더 느림, 컨텍스트 많음
각 도구마다 알맞은 쓰임새가 있어:
  • Tab은 네가 직접 운전하면서 빠르게 고치고 싶을 때 기본 선택이야
  • Inline Edit은 특정 코드 구간에 집중해서 바꿔야 할 때 빛나
  • Chat은 더 큰 변경에서 Cursor가 넓은 컨텍스트를 이해해야 할 때 제격이야
Chat 모드를 쓸 때(조금 느릴 수 있지만 엄청 강력해), 좋은 컨텍스트로 보조해줘. 에뮬레이트하고 싶은 유사한 코드를 @files로 가리키거나, 프로젝트 구조 이해를 돕게 @folder를 써줘. 그리고 큰 변경은 과감히 더 작은 덩어리로 나눠 — 새 채팅으로 시작하면 집중도와 효율이 올라가.

​
핵심 포인트

  • 변경 범위를 좁히고 한 번에 너무 많은 걸 하려고 하지 마
  • 가능할 때는 필요한 맥락을 같이 제공해
  • Chat, Inline Edit, Tab은 각자 잘하는 데에 맞춰서 써
  • 새 채팅을 자주 만들어
  • Ask 모드로 설계하고 Agent 모드로 구현해