태그: ai productivity tools webdev

대부분의 개발자들은 다음과 같은 방식으로 AI 코딩 어시스턴트 (AI coding assistants)를 사용합니다: 함수를 복사해서 채팅창에 붙여넣고, 수많은 컨텍스트(context)를 추가합니다 ("자, 이 함수는 X에서 호출되고, Y 라이브러리를 사용하며, 데이터는 Z와 같은 형태입니다..."). 그러고 나서야 비로소 실제 질문을 던집니다.

이 방식도 작동은 합니다. 하지만 매우 지칩니다. 그리고 시간이 지나면, 코드를 작성하는 시간보다 코드를 설명하는 데 더 많은 시간을 쓰고 있는 것은 아닌지 의구심이 들기 시작합니다.

여기 제가 Cursor를 사용하는 방식을 바꿔놓은 워크플로 (workflow)의 변화가 있습니다.

팁: 복잡한 질문을 하기 전에 @codebase를 사용하세요

Cursor에는 @codebase를 사용하여 프롬프트 (prompt)에서 전체 코드베이스 (codebase)를 참조할 수 있는 기능이 있습니다. 대부분의 사람들은 이것이 과하다고 느껴서 건너뜁니다. 하지만 그렇지 않습니다.

Composer 또는 채팅 패널에서 @codebase를 입력하면, Cursor는 단순히 무작위 파일을 가져오는 것이 아닙니다. 답변을 하기 전에 프로젝트 전체에서 실제로 관련 있는 부분을 찾기 위해 시맨틱 검색 (semantic search)을 수행합니다. 따라서 사용자가 직접 컨텍스트를 골라내는 대신, Cursor가 무엇이 중요한지 스스로 파악합니다.

실제 사례를 들어보겠습니다. 저는 API 라우트 (API routes)가 일관되지 않은 에러 형태를 반환하는 Next.js 프로젝트를 가지고 있었습니다. 어떤 것은 { error: string }을 반환하고, 다른 것들은 { message: string, code: number }를 반환했습니다. 모든 변형을 수동으로 추적했다면 20분 이상 걸렸을 것입니다.

대신 저는 다음과 같이 입력했습니다:

@codebase 에러 응답을 반환하는 모든 API 라우트를 찾아서
그들이 사용하는 서로 다른 형태들을 보여줘. 그런 다음 모든 곳에
적용할 수 있는 통합된 에러 형식을 제안해줘.

Cursor는 패턴별로 그룹화된 불일치 사항에 대한 명확한 요약과 함께, 제안된 표준 및 각 파일에 대한 실제 리팩터링 (refactor) 코드를 가져왔습니다. 지루한 grep-and-read 세션이 되었을 작업이 4분 만에 해결되었습니다.

이것이 실제로 작동하는 이유

여기서 Cursor가 수행하는 핵심적인 일은 마법이 아닙니다. 바로 사용자의 로컬 코드베이스를 지식 소스로 사용하는 검색 증강 생성 (Retrieval-Augmented Generation, RAG)입니다. Cursor는 파일을 임베딩 (embed)하고, 쿼리 (query)와 의미적으로 유사한 청크 (chunks)를 찾아 이를 컨텍스트로 모델에 전달합니다.

실질적인 결과: 무언가에 대해 질문할 때 그것이 코드베이스의 어디에 있는지 알 필요가 없습니다. 여러분은 찾고 있는 것이 무엇인지 설명하기만 하면 되며, Cursor가 스스로 관련 조각들을 찾아냅니다.

이것은 특히 다음 상황에서 매우 중요합니다:

• 파일 간 디버깅 (Debugging across files) — 버그가 컴포넌트, 훅 (hook), 유틸리티 (utility), 또는 API 핸들러 (API handler) 중 어디에 있을지 모를 때
• 리팩터링 패턴 (Refactoring patterns) — 특정 패턴을 변경하기 전에 해당 패턴이 사용된 모든 곳을 찾고 싶을 때
• 익숙하지 않은 저장소 (repos) 온보딩 — "이 프로젝트에서 인증 (auth)은 어떻게 작동하나요?"라고 질문했을 때 실제로 유용한 답변을 얻을 때

여러 파일 변경을 위해 Composer와 함께 사용하기

Cursor가 여러분이 원하는 범위 (scope)를 이해하고 나면, Composer (⌘+I)로 전환하여 실제로 변경을 수행하세요. 이 지점이 Cursor가 다른 도구들과 진정으로 차별화되는 부분입니다.

예를 들어 다음과 같은 프롬프트 (prompt)를 사용할 수 있습니다:

@codebase 모든 API 라우트를 다음 에러 형식으로 리팩터링하세요:
{ success: false, error: { message: string, code: number } }

...

...이렇게 하면 여러 파일에 걸쳐 동시에 디프 (diff)가 생성됩니다. 여러분은 개별 변경 사항을 검토하고, 수락하거나 거부한 뒤 다음 단계로 넘어갑니다. 이는 자동 완성 (autocomplete)보다는 페어 프로그래밍 (pair programming)에 더 가깝습니다.

알아두어야 할 주의사항 (The Gotcha)

@codebase는 코드가 어느 정도 잘 정리된 프로젝트에서 가장 잘 작동합니다. 정말로 혼란스러운 레거시 코드베이스 (legacy codebase)에서는 의미론적 검색 (semantic search)이 때때로 잘못된 컨텍스트 (context)를 노출할 수 있습니다. 그런 일이 발생하면, 확신에 찬 어조로 말하지만 미묘하게 틀린 답변을 받게 됩니다. 따라서 수락하기 전에 항상 디프 (diff)를 읽어보아야 합니다.

저의 해결책: 코드베이스의 지저분한 부분에 있는 무엇인가에 대해서는, 올바른 컨텍스트가 포함되도록 @codebase와 함께 특정 파일들을 수동으로 @mention 합니다.

결론

만약 여러분이 Cursor를 단순히 화려한 자동 완성 기능이나 코드 스니펫 (snippets)을 붙여넣는 채팅창처럼 사용하고 있다면, Cursor 가치의 대부분을 놓치고 있는 것입니다. @codebase와 Composer의 조합이야말로 Cursor가 진정한 가치를 발휘하는 지점입니다. 특히 전체 코드를 머릿속에 다 담을 수 없을 정도로 큰 프로젝트에서 더욱 그렇습니다.

이것이 핵심 팁입니다. 간단하지만, 도구와 상호작용하는 방식을 완전히 바꿔 놓을 것입니다.

저는 다른 AI 코딩 도구들과 함께 Cursor를 광범위하게 테스트해 왔습니다. GitHub Copilot과의 비교 및 Cursor가 진정으로 잘하지 못하는 부분들을 포함한 저의 전체 Cursor 리뷰 (9.2/10)에서 상세한 분석 내용을 확인하실 수 있습니다.