대규모 코드베이스로 작업하면 소규모 프로젝트와는 다른 종류의 과제가 생겨. Cursor의 코드베이스를 직접 스케일해 온 경험과 거대한 코드베이스를 운영하는 고객들의 인사이트를 바탕으로, 늘어나는 복잡도를 다루는 데 유용한 몇 가지 패턴을 찾아냈어. 이 가이드에서는 대규모 코드베이스에 특히 효과적이었던 몇 가지 기법을 함께 살펴볼게.

​
Chat으로 낯선 코드를 빠르게 파악하기

특히 처음 접하는 대규모 코드베이스를 살피는 건 쉽지 않아. 보통은 원하는 부분을 찾으려고 grep하고, 검색하고, 이곳저곳 클릭하게 되지. Chat을 쓰면 궁금한 걸 바로 물어보면서 찾고, 동작 방식에 대한 자세한 설명도 받아볼 수 있어. 여기서는 Cursor에서 코드베이스 인덱싱의 구현 세부를 찾는 걸 도와달라고 하고, 이해를 돕기 위해 예시까지 요청하고 있어.

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

새로운 협업자가 코드베이스에 합류했다면, 어떤 배경 정보를 알려줘야 바로 의미 있는 기여를 시작할 수 있을까? 이 질문에 대한 답은 Cursor가 이해하는 데도 꽤 가치 있는 정보야. 어떤 조직이나 프로젝트든 문서에 다 담기지 않은 암묵지가 있기 마련이거든. 규칙을 잘 활용하는 게 Cursor가 전체 맥락을 정확히 파악하도록 보장하는 가장 좋은 방법이야. 예를 들어, 새 기능이나 서비스를 구현하는 방법을 문서화하고 있다면, 나중을 위해 짧은 규칙으로 남겨두는 걸 고려해봐.
보일러플레이트
---
description: 새로운 VSCode 프런트엔드 서비스 추가
---

1. **인터페이스 정의:**
   - `createDecorator`로 새 서비스 인터페이스를 정의하고, 오류를 피하기 위해 `_serviceBrand`가 포함되어 있는지 확인해.

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

3. **서비스 등록(컨트리뷰션):**
   - 서비스를 가져와 로드하는 컨트리뷰션 파일을 만들고, 메인 엔트리포인트에 등록해.

4. **컨텍스트 통합:**
   - 애플리케이션 전반에서 접근할 수 있도록 컨텍스트를 업데이트해 새 서비스를 포함해.
공통 서식 패턴을 Cursor가 꼭 따르길 원한다면, glob 패턴에 따라 규칙을 자동으로 첨부하도록 설정하는 걸 고려해봐.
서식
---
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보다 named export를 써. 예: (`export const variable ...`, `export function `)

​
계획 수립 과정에 밀착하기

큰 변경을 다룰 땐, 정확하고 범위가 명확한 계획을 세우기 위해 평소보다 더 깊이 고민하면 Cursor의 결과물이 훨씬 좋아져. 같은 프롬프트를 몇 번 바꿔도 원하는 결과가 안 나오면, 한 발 물러나서 동료에게 줄 PRD를 쓰듯 처음부터 더 구체적인 계획을 잡아봐. 많은 경우 어려운 건 무엇을 바꿔야 하는지 정하는 일이고, 이건 사람이 잘하는 일이야. 올바른 지침만 있으면 구현의 일부는 Cursor에 맡길 수 있어. 계획 수립을 AI로 보강하는 한 가지 방법은 Ask 모드를 쓰는 거야. 계획을 만들려면 Cursor에서 Ask 모드를 켜고, 프로젝트 관리 시스템, 내부 문서, 흩어진 생각 등 가지고 있는 모든 컨텍스트를 그대로 넣어. 코드베이스에서 포함하고 싶다고 이미 알고 있는 파일과 의존성을 떠올려봐. 통합하려는 코드 조각이 들어 있는 특정 파일일 수도 있고, 아예 폴더 전체일 수도 있어. 다음은 예시 프롬프트야:
계획 수립 프롬프트
- 새로운 기능을 어떻게 만들지 계획을 세워줘 (@existingfeature.ts처럼)
- 애매한 부분이 있으면 질문해줘 (최대 3개)
- 코드베이스를 꼭 찾아보고 진행해줘

@Past Chats (이전에 했던 탐색용 프롬프트)

[project management tool]에서 가져온 추가 컨텍스트가 있어:
[붙여넣은 티켓 설명]
모델이 계획을 세우고 컨텍스트를 수집하도록, 사람에게 질문하고 이전 탐색용 프롬프트와 티켓 설명을 참조하게 해. claude-3.7-sonnet, gemini-2.5-pro, o3 같은 사고 모델을 권장해. 이런 모델은 변경 의도를 파악하고 더 나은 계획을 종합해낼 수 있어. 이걸 바탕으로 구현을 시작하기 전에 Cursor 도움을 받아 계획을 반복적으로 다듬으면 돼.

​
일에 맞는 도구를 고르기

Cursor를 제대로 쓰려면 가장 중요한 스킬 중 하나가 상황에 딱 맞는 도구를 고르는 거야. 무엇을 하려는지 먼저 생각하고, 플로우를 끊지 않는 접근을 선택해.
ToolUse caseStrengthLimitation
Tab빠른 수동 변경완전한 제어, 매우 빠름단일 파일
Inline Edit한 파일 내 범위 제한 변경특정 영역에 집중한 편집단일 파일
Chat대규모, 다중 파일 변경컨텍스트 자동 수집, 깊은 편집더 느림, 컨텍스트 부담
각 도구가 활약하는 구간이 있어:
  • Tab은 네가 직접 운전대 잡고 빠르게 수정할 때 기본 선택이야
  • Inline Edit는 특정 코드 구간에 집중해서 바꿔야 할 때 빛나
  • Chat은 더 큰 변경처럼 Cursor가 넓은 컨텍스트를 이해해야 할 때 딱 좋아
Chat 모드(조금 느리게 느껴질 수 있지만 정말 강력해)를 쓸 때는, 좋은 컨텍스트를 줘서 잘 도와줄 수 있게 해줘. 따라 하고 싶은 유사 코드를 가리키려면 @files, 프로젝트 구조를 더 잘 이해시키려면 @folder를 활용해. 그리고 큰 변경은 과감히 더 작은 단위로 쪼개도 좋아 — 새 챗으로 시작하면 포커스를 유지하고 효율적이야.

​
핵심 포인트

  • 변경 범위를 좁히고 한 번에 너무 많은 걸 하려고 하지 마
  • 가능하면 관련 컨텍스트를 함께 제공해
  • Chat, Inline Edit, Tab은 각자 잘하는 데 써
  • 새 챗을 자주 만들어
  • Ask 모드로 계획하고 Agent 모드로 구현해