GN⁺: Cursor (AI IDE)는 어떻게 동작하는가

(blog.sshh.io)

45P by neo 5일전 | ★ favorite | 댓글 4개

AI 코딩 도구인 Cursor, Windsurf, Copilot의 내부 작동 방식을 이해하면 복잡한 코드베이스에서 생산성을 높이고 일관된 성능을 확보할 수 있음
많은 사람이 AI IDE의 한계를 이해하지 못하고 전통적인 도구처럼 다루다가 성능 문제를 경험함
이 글에서는 Cursor의 내부 작동 방식, 시스템 프롬프트, 그리고 코딩 및 Cursor 규칙 최적화 방법을 설명함

LLM에서 코딩 에이전트로

대형 언어 모델 (LLM)

LLM은 기본적으로 다음 단어를 예측하는 방식으로 작동함
프롬프트를 제공하면 LLM이 자동 완성으로 응답 생성
- 초기 디코더 기반 LLM (예: GPT-2)은 완성될 결과를 얻기 위해 특정 프롬프트 작성이 필요했음
- 프롬프트 엔지니어링은 모델을 '속여서' 원하는 답을 유도하는 기술임
명령 튜닝 (Instruction Tuning) 도입 후 사용 편의성이 향상됨
- “Foo 메서드를 리팩토링하는 PR 작성해줘” 같은 명령이 바로 실행됨
- 실제로는 자동 완성 프로세스의 확장 버전임
도구 호출 (Tool Calling) 추가됨
- 모델이 파일 읽기, 쓰기, 명령 실행 같은 작업 수행 가능
- 예: read_file('index.py') → 클라이언트가 파일 내용 제공 → 모델이 작업 진행

에이전트 기반 코딩

Cursor 같은 AI IDE는 복잡한 래퍼 구조를 사용해서 구성:

VSCode 포크 → 오픈 소스 기반에서 시작
챗 UI 추가 및 적합한 LLM 선택 (예: Sonnet 3.7)
코딩 에이전트용 도구 구현
- read_file(full_path: str)
- write_file(full_path: str, content: str)
- run_command(command: str)
프롬프트 최적화
- "너는 전문가 코더임", "추측하지 말고 도구 사용" 등 명령 추가
  → 단순히 위 단계를 구현하면 실제로는 동작하지만 문법 오류, 환각, 일관성 부족 문제 발생 가능

에이전트 기반 코딩 최적화 전략 및 팁

좋은 AI IDE를 만들기 위해서는 LLM이 잘하는 작업을 파악하고, LLM의 한계에 맞춰 프롬프트와 도구를 신중하게 설계해야 함.
- 주 작업을 단순화하고, 서브 작업에 더 작은 모델을 사용하는 방식이 효과적임
- 복잡한 작업을 분산 처리해 성능 및 일관성 개선 가능
사용자 컨텍스트 추가 (@file 사용)
- 사용자는 이미 적절한 파일이나 컨텍스트를 알고 있을 가능성이 높음
- @file 구문 추가 → 전체 파일 또는 폴더 내용을 포함시켜 컨텍스트 제공
- 팁: @folder/@file 사용 적극 권장 → 명확한 컨텍스트 제공으로 응답 속도 및 정확도 개선
코드 검색 최적화
- 코드 검색은 복잡할 수 있으며, 특히 의미 기반 검색(예: "인증 코드 위치")이 어려움
- 코드베이스를 벡터 저장소(Vectorstore) 에 인덱싱 → 검색 시 LLM이 자동으로 필터링 및 재정렬
- 팁: 코드 주석 및 문서 중요 → 임베딩 모델 성능 강화
  - 파일 상단에 해당 파일의 목적, 의미, 수정 시점 설명 추가
파일 작성 최적화
- 완벽한 코드 작성은 어렵고 비용이 많이 듦
- 전체 파일 대신 의미적 차이(Semantic Diff) 생성 → 수정된 코드 조각만 제공
- 의미적 차이를 기반으로 별도의 적용 모델이 실제 파일 작성 → 구문 오류 수정
- 팁: 적용 모델에 직접 프롬프트 명령 불가 → 전체 파일 제공으로 제어 강화
- 팁: 적용 모델은 대형 파일 편집 시 속도가 느려지고 오류 발생 가능 → 파일 크기를 500 LoC 이하로 유지
- 팁: 린터(linter) 피드백은 매우 중요한 신호 → 강력한 린터 도입 필수
  - 컴파일 및 타입 언어가 제공하는 피드백 활용 가능
- 팁: 고유한 파일 이름 사용 → page.js 대신 foo-page.js, bar-page.js 등 구체적인 이름 사용
  - 문서에서 전체 파일 경로 제공 → 수정 도구의 모호성 제거
에이전트 특화 모델 사용
- 일반적인 코드 작성 모델이 아닌, 에이전트 특화 모델 사용 권장
- Anthropic의 모델이 Cursor 같은 IDE에서 뛰어난 성능을 보이는 이유임
- 팁: 단순히 코드 작성이 아니라 에이전트 기반 IDE에 최적화된 모델 선택
  - WebDev Arena 리더보드에서 모델 성능 확인 가능
셀프 수정 도구 사용 (고급 전략)
- "apply_and_check_tool" → 비싼 린터 실행 + 헤드리스 브라우저에서 콘솔 로그 및 스크린샷 수집
- MCP(Model Context Protocol) → 에이전트 자율성과 컨텍스트 제공 강화

Cursor 시스템 프롬프트 상세 분석

Cursor의 최신 프롬프트(March 2025)는 MCP 기반 프롬프트 주입 기법을 통해 추출됨
- Cursor의 프롬프트 엔지니어들은 다른 AI IDE와 비교해도 뛰어난 프롬프트 작성 능력을 보유하고 있음.
- 프롬프트 구조를 분석하면 코드 생성 성능 및 에이전트 아키텍처 설계 능력을 개선 가능
주요 프롬프트 요소 및 의미
- "<communication>", "<tool_calling>" 등 태그 사용
  - Markdown 및 XML 태그를 혼합 사용 → 사람이 읽기 쉽고 LLM이 처리하기 용이함
- "powered by Claude 3.5 Sonnet"
  - 모델 일관성 강화 → LLM이 실행 중인 모델에 대해 잘못된 정보 제공 방지
- "the world's best IDE"
  - LLM이 오류 발생 시 다른 제품 추천 방지
- "we may automatically attach some information…follow the USER's instructions…by the <user_query> tag."
  - 사용자 프롬프트를 직접 전달하지 않고 특수 태그에 포함시켜 혼동 방지
- "Refrain from apologizing"
  - 불필요한 사과 방지 (Sonnet 모델의 특징 보완)
- "NEVER refer to tool names when speaking"
  - 도구 이름을 언급하지 말라는 명령 추가 → 하지만 실제 모델에서 무시되는 경우 발생
- "Before calling each tool, first explain"
  - 도구 호출 전 상태 설명 → 사용자 경험 개선
- "partially satiate the USER's query, but you're not confident, gather more information"
  - 과도한 자신감으로 인한 조기 응답 방지 → 추가 정보 요청 유도
- "NEVER output code to the USER"
  - 직접 코드 출력 금지 → 도구를 통해서만 코드 생성 허용
- "If you're building a web app from scratch, give it a beautiful and modern UI"
  - 단일 프롬프트로 매력적인 웹 앱 생성 유도 (데모 목적)
- "you MUST read the the contents or section of what you're editing before editing it"
  - 코드 수정 전 컨텍스트 읽기 강제 → 문맥 인식 강화
- "DO NOT loop more than 3 times on fixing linter errors"
  - 수정 루프 제한 → 무한 루프 방지
- "Address the root cause instead of the symptoms."
  - 문제의 증상이 아닌 근본 원인 수정 유도
- "DO NOT hardcode an API key"
  - 보안 강화를 위한 명령 → 하드코딩 방지
- "codebase_search", "read_file", "grep_search", "file_search", "web_search"
  - 코드 작성 전 올바른 컨텍스트 확보를 위한 다양한 검색 도구 제공
- "One sentence explanation…why this command needs to be run…" 요구
  - 도구 인수 처리 시 논리 강화 → 프롬프트 개선 기술 적용
- "reapply" 도구는 "Calls a smarter model to apply the last edit"
  - 마지막 수정 사항을 더 고급 모델에서 재적용 → 수정 품질 개선
- "edit_file" 도구는 "represent all unchanged code using the comment of the language you're editing"
  - 수정되지 않은 코드를 주석으로 표시 → 수정 모델 작동 정확성 강화
프롬프트 캐싱 활용
- 시스템 프롬프트 및 도구 설명은 정적 상태로 유지
- 코드베이스나 사용자에 따른 맞춤 설정 없음 → 프롬프트 캐싱으로 비용 및 처리 속도 개선 가능

Cursor 규칙 효과적으로 작성 및 사용하기

Cursor 규칙 작성의 정답은 상황에 따라 다를 수 있지만, 프롬프트 작성 경험 및 Cursor 내부 구조에 대한 이해를 기반으로 몇 가지 유용한 팁을 제공함
규칙은 단순한 명령이 아니라 백과사전형 지침으로 작성하는 것이 중요함.
규칙 작성의 핵심 개념
- LLM은 규칙 목록의 이름과 설명을 바탕으로 fetch_rules(…) 호출
- 규칙은 시스템 프롬프트에 추가되지 않고 필요할 때 참조됨
- 따라서 명령이 아닌 백과사전식 설명 방식이 효과적임
규칙 작성 시 피해야 할 사항
- 정체성(identity) 정의 금지
  - "너는 TypeScript 전문가임" 같은 설명 금지
  - LLM은 이미 내장된 프롬프트로 정체성을 알고 있음 → 충돌 위험
- 시스템 프롬프트 덮어쓰기 시도 금지
  - "주석을 추가하지 마라", "질문 후 코드 작성해라" 등 명령 → 내부 도구 사용 혼란 유발
- 부정적 명령 금지
  - "하지 마라"보다 "해라" 같은 긍정 명령이 LLM에 더 효과적
  - 긍정 명령 예제: "파일 수정 시 전체 컨텍스트 확인 후 수정"
규칙 작성 시 권장 사항
- 명확하고 직관적인 규칙 이름 및 설명 작성
  - 코드베이스에 대한 최소한의 정보만으로도 규칙 적용 가능해야 함
  - 중복 규칙 작성 가능 → 검색 정확도 향상
- 규칙은 백과사전식으로 작성
  - 구체적 명령보다 상황 및 목적에 대한 설명 제공
  - 필요 시 코드 파일을 연결해 문맥 강화 가능
- Cursor를 사용해 규칙 초안 작성
  - LLM은 다른 LLM을 위한 컨텍스트 작성에 강함
  - 예: "@folder/ 자주 수정되는 코드 경로와 정의에 대한 Markdown 파일 생성"
- 규칙 과다 작성은 지양
  - 너무 많은 규칙은 비효율적이며 비직관적인 코드베이스를 의미함
  - 이상적인 코드베이스는 에이전트가 최소한의 규칙으로 작업 가능해야 함
효과적인 규칙 작성 사례
- ✅ 규칙 명령:
  - "파일 수정 전 전체 컨텍스트 읽기"
  - "서버 코드 수정 시 인증 코드 로직 확인"
  - "에러 발생 시 원인 먼저 수정"
- ❌ 규칙 명령 (피해야 함):
  - "주석을 삭제하지 마라"
  - "수정 전 나에게 질문해라"
  - "불필요한 코드 수정하지 마라"
규칙 작성의 핵심 전략
- 규칙은 명령이 아니라 상황 설명으로 작성
- 직관적인 이름 및 설명 사용 → 최소한의 규칙으로 최대한의 성능 확보
- 구체적인 명령보다 상황 설명 및 코드 연결 강화

결론

VSCode의 포크에서 시작해 오픈 소스 기반 프롬프트 및 공개 모델 API를 사용한 Cursor가 100억 달러(약 13조 원) 에 가까운 가치 평가를 받은 것은 놀라운 일임
- Cursor는 현재 "래퍼 배수(wrapper multiple)" 기준으로 6배 가치 평가를 받고 있음
Cursor는 최적화된 프롬프트 및 강력한 도구 호출 시스템 덕분에 강력한 성능 제공
Cursor가 자체 에이전트 모델을 개발할 가능성은 낮음
- 대신 Anthropic이 Claude Code와 Sonnet 기반의 경쟁 제품을 출시할 가능성이 높음
핵심 인사이트
- 코드베이스, 문서화, 규칙을 올바르게 설정하는 것은 앞으로도 중요한 기술이 될 것임
- AI 코딩 도구의 최적화 전략을 이해하면 생산성 및 정확성 강화 가능
- Cursor가 제대로 작동하지 않는다면 사용 방식의 문제일 가능성이 큼