커서 튜토리얼(중국어 버전)

이 글은 Juan Stoppa의 블로그 게시물 '더 스마트하게, 더 어렵지 않게 코드 작성하기: 다음을 사용하여 개발하기'에 기고된 글입니다. 커서 그리고 Claude 소네트의 번역입니다. 번역이라고 부르는 이유는 이 글의 내용이 대부분 제 경험을 바탕으로 한 것이지만, 글의 틀은 그의 글의 구조를 기반으로 하고 있기 때문에 번역이라고 부릅니다.

이 튜토리얼에서는 커서의 기본 기능을 소개합니다.

초보자라면 정말 원클릭으로 AI를 통해 완전한 프로젝트 코드를 작성하고 온라인 환경을 자동으로 배포하여 사용할 수 있기를 원합니다.

추천합니다:Bolt: 완전한 프로젝트 코드를 온라인으로 생성하고 실행하는 실시간 AI 기반 풀스택 개발 플랫폼입니다.

커서에 대한 간략한 소개

Cursor는 애니스피어의 랩에 구축된 코드 편집기로, VSCode의 수정된 파생형을 기반으로 하므로 모든 VSCode 구성을 Cursor에서 가져와서 사용할 수 있으므로 일반적으로 VSCode로 개발하는 경우 쉽게 마이그레이션할 수 있습니다.

Cursor와 VSCode의 가장 큰 차이점은 코드 협업을 위한 AI가 내장되어 있다는 점이며, 이를 위해 VSCode를 여러 가지 변경하여 VSCode에서 Github 같은 것을 사용하는 것보다 더 나은 경험을 제공한다는 점입니다. 부조종사 플러그인 클래스가 훨씬 더 편합니다. 이렇게 말하는 것이 단조로울 수 있지만, 먼저 깃허브 코파일럿 비교 메모를 작성하세요.

Github Copilot은 VSCode에서 플러그인으로 가져옵니다:

깃허브 코파일럿

사용 측면에서 Copilot의 지원은 코드 완성, 코드 생성 재작성 기능을 갖춘 GPT와 동일한 대화 창 등 이러한 점에 중점을 두고 있습니다.

코드 완성 기능은 제가 좋아하는 Copilot의 핵심 기능으로, 코드를 작성할 때 자동으로 다음 내용을 추론해 주며 'Tab' 키를 누르기만 하면 제안을 받을 수 있습니다:

제가 지금 작성 중인 문서의 예로 Github Copilot의 코드 완성하기

가장 좋은 점은 몰입감 있는 경험입니다. 편집기를 벗어나지 않고 원본 코드를 복사하여 붙여넣지 않고도 샘플 코드를 쉽게 다시 작성할 수 있습니다. 물론 결과를 생성한다는 말은 아니지만 대부분의 경우 실제로 원하는 코드를 생성합니다.

또한 GPT와 동일한 대화 창이 있어 현재 편집 중인 코드의 컨텍스트를 큰 모델에 동시에 편리하게 제출할 수 있어 더 나은 생성 결과를 얻을 수 있다는 장점이 있습니다:

깃허브 코파일럿의 대화창

마지막으로 평범한 에디터 내 코드 생성 편집 다시 쓰기가 있는데, 이 기능은 VSCode의 작은 전구(정식 명칭은 코드 액션으로, 코드에 무언가를 할 때 사용됨)를 통해 트리거할 수 있습니다:

깃허브 코파일럿의 코드 생성 재작성은 코드 액션에 나타납니다.

Copilot을 사용하여 변경을 수행하도록 선택하면 `/doc`과 같은 명령을 입력하여 Copilot이 문서를 생성하거나 코드를 더 잘 수정/재작성할 수 있도록 도와주는 프롬프트 상자가 나타납니다:

깃허브 코파일럿을 위한 코드 생성 재작성

멋져 보이지만 제 개인적인 경험으로는 작동하지 않습니다. 왜냐하면 대부분의 경우 코드의 새 복사본을 다시 작성하고 원본 코드를 다시 삭제해야 하기 때문입니다. ...... 저는 주로 코드 완성 기능이 좋아서 Copilot을 사용한다고 가정해 보겠습니다.

코파일럿이 잘하는 것은 더 잘하고, 코파일럿이 잘하지 못하는 것은 완벽하게 해내는 커서의 경험은 특히 놀랍습니다.

제 개인적인 경험으로는 코드 완성 기능이 훨씬 더 정확합니다. Copilot은 종종 닫힌 코드 블록을 올바르게 생성하지 못하지만(예: 서로 `()` `{}` 쌍이 제대로 생성되지 않는 경우), Copilot에서는 이런 경우가 거의 발생하지 않습니다.

커서 대화창은 코드에 바로 적용할 수 있는 코드를 생성하기 때문에 이에 비하면 코파일럿은 정말 형편없는 수준입니다:

커서 대화창의 적용 기능은 수정한 코드를 코드에 적용하는 기능입니다.

커서가 변경 사항을 코드에 직접 적용하는 이유는 LLM이 Git과 같은 diff 형식[3]을 출력하도록 자체 모델을 미세 조정했기 때문입니다. diff 형식을 사용하면 코드의 올바른 부분을 정확히 수정할 수 있습니다.

또한 더욱 편리하게 사용할 수 있도록 Cusor는 대화 중에 여러 소스 파일을 전달하거나 전체 프로젝트의 코드 사일로를 스캔하여(`ctrl + enter`를 눌러) 빅 모델에 더 정확한 답변을 요청하기 위한 컨텍스트로 관련 콘텐츠를 추출하는 작업을 쉽게 수행할 수 있습니다:

관련 UI를 통해 관련 파일을 빠르게 추가할 수 있으며, 'Ctrl + Enter'를 누르면 코드 빈에 있는 코드를 기반으로 한 대화 상자가 나타납니다.

생성 속도와 인덱싱 속도가 매우 부드럽기 때문에 코드 웨어하우스의 인덱싱이 JetBrains와 비슷하지만 인덱싱은 벡터화(임베딩, 일반적인 번역은 벡터 인레이이지만 저는 벡터화라고 부르고 싶습니다)를 수행하기 때문에 더 나은 생성을 위해 유사성 검색을 수행하는 것이 편리 할 수 있습니다.

커서의 인덱싱 기능

이 외에도 커서에는 자체 단축키가 내장되어 있는데, 이 단축키에 대해서는 나중에 설명하겠습니다.

간단히 말해서 커서는 코파일럿을 정말 죽입니다.

이전에 VSCode 플러그인을 작성했던 경험으로 볼 때, 일반적으로 코파일럿을 사용하면서 느낀 점은 VSCode 플러그인은 제한이 많은데, 커서는 마법의 에디터라서 제한적인 기능들을 과감하고 자유롭게 할 수 있다는 점이 커서가 이렇게 잘할 수 있는 이유입니다.

커서의 기본 사용법

마운팅

커서는 공식 웹사이트(https://www.cursor.com/)에서 다운로드해야 합니다. 다운로드 후 등록을 해야 사용할 수 있으며, 구글 및 깃허브 계정 로그인을 지원합니다.

커서는 구독 기반입니다. 신규 사용자는 2주 동안 Pro 구독을 사용해 볼 수 있습니다. Pro 구독을 이용하려면 한 달에 20달러(한화 약 14만 원)를 지불해야 합니다. 작동은 하지만 약간 비싼 편입니다.

설치 후 커서를 처음 시작할 때 VSCode 구성을 가져오라는 메시지가 표시되며, 이 작업이 완료되면 기본적으로 AI가 강화된 버전의 VSCode를 사용하게 됩니다.

바로 가기 키 및 해당 기능

커서에는 해당 AI 기능을 사용하기 위한 다음 단축키가 있습니다.

1. `CTRL/CMD + L`을 눌러 대화 상자를 엽니다.

편집기 오른쪽에 있는 대화 상자를 열려면 `CTRL/CMD + L` 키를 사용합니다(이 `L`은 vim 키 입력 아래 오른쪽에 있으며, vim 키 입력 아래의 화살표 키는 키보드의 `h,j,k,l`로, `h`는 왼쪽으로 왼쪽, `l`은 오른쪽으로 오른쪽, `j`는 아래로, `k`는 위로 향합니다). (저는 이 방식이 정말 마음에 듭니다).

이미지의 출처는 원본 텍스트이며, 오른쪽에 대화 상자가 열리고 인용된 다른 출처는 이미지 앞쪽에 설명되어 있습니다.

2. `CTRL/CMD + K'로 생성 창을 엽니다.

커서 위치 위에 있는 `CTRL/CMD + K` 키(`k`는 위를 의미하므로!)를 사용하여 생성 창을 엽니다. 💕)를 눌러 생성 창을 엽니다:

위의 원본 소스 텍스트는 코드 생성을 위한 대화 상자를 엽니다.

참고로 콘텐츠를 선택할 때 `CTRL/CMD + K`를 누르면 해당 창이 열리며, 이 창은 선택한 컨텍스트에 따라 콘텐츠를 생성합니다:

선택된 콘텐츠 생성

3. `CTRL/CMD + I'를 눌러 작곡가를 엽니다.

커서의 특수 기능인 `CTRL/CMD + I`를 사용하면 하나의 대화창에서 여러 파일을 동시에 변경할 수 있는 커서의 특수 기능인 `작성기`를 열 수 있습니다.

작성기를 사용하려면 먼저 커서 설정에서 작성기를 켜야 하며, '파일 > 환경설정 > 커서 설정 > 기능 > 작성기 사용' 순서로 설정 페이지에 액세스해야 합니다.

그림 소스 원본, 작성기 설정

'Ctrl + I'로 열리는 '작곡가'는 드래그 앤 드롭 방식의 작은 인터페이스입니다:

컴포저의 작은 패널 인터페이스

여러 파일을 포함하는 복잡한 단계별 수정을 입력하면 Composer가 관련된 파일에 대한 모든 수정을 동시에 생성합니다. 그러나 일반적으로 작성기는 작은 패널 인터페이스의 오른쪽 상단 모서리에 있는 버튼을 통해 전체 기능을 사용해야 합니다:

Composer의 전체 화면 열기

누적 대화 상자에서 해당 파일을 변경하려는 위치가 왼쪽에 명확하게 나열되며, 관련 변경 사항을 바로 적용할 수 있습니다.

여러 창과 파일 사이를 전환할 필요 없이 단일 창 안에서 자연스럽게 자연어로 요구 사항을 계속 설명할 수 있다는 점에서 지금까지 경험한 **AI 지원 프로그래밍** 중 가장 좋은 방식입니다. 저는 커서가 지금까지 살펴본 상호작용 방식 중 가장 좋은 형태라고 생각합니다.

편리한 문맥 정보를 위한 `@` 표기법

대규모 언어 모델에 문맥 정보를 더 쉽게 제공하기 위해, 커서에는 다양한 `@` 주석이 내장되어 있어 대화에 다양한 유형의 문맥 정보를 쉽게 삽입할 수 있습니다.

일부 `@` 메모는 일반적인 것으로 모든 대화창에서 사용할 수 있으며, 일부 메모는 구체적인 것으로 언급하는 대로 추가하겠습니다.

참고: 실제로 깃허브 코파일럿에도 비슷한 기능이 있지만 커서만큼 완벽하지는 않습니다.

1. `@파일` 메모에 지정된 코드 파일의 컨텍스트를 전달합니다.

대화 상자에 `@파일` 메모를 입력하면 커서가 자동으로 코드 저장소의 검색 목록을 표시합니다. 컨텍스트로 가져올 파일 이름을 입력하고 확인 버튼을 누르면 해당 파일의 내용이 해당 시점의 컨텍스트에 자동으로 주입됩니다:

@파일` 노트

2. `@코드` 메모, 지정된 코드 블록의 컨텍스트 전달

코드` 노트는 보다 정확한 코드 스니펫을 제공하며, `@` 노트는 거의 동일한 방식으로 사용되며 해당 검색 상자가 나타나고 색인 목록에 키워드를 입력하면 적절한 코드 블록을 선택할 수 있습니다.

코드 블록의 식별은 개발 환경의 LSP에 의해 결정되며, 대부분의 경우 정확합니다:

코드` 노트

3. 함수 또는 라이브러리의 공식 문서에서 컨텍스트를 얻기 위한 `@Docs` 참고 사항

문서` 노트는 함수나 라이브러리의 공식 문서에서 컨텍스트를 가져올 수 있습니다. 현재는 접근 가능한 온라인 문서에서만 컨텍스트를 가져올 수 있습니다. 따라서 온라인 주소를 구할 수 없다면 JSDoc과 같은 문서는 쓸모가 없죠~ 개인적으로 이 기능은 그다지 범용적이지 않다고 생각합니다.

문서를 수동으로 가져와야 할 때 주로 사용하는 `@Docs` 노트입니다.

4. 검색 엔진 검색 콘텐츠에서 컨텍스트를 얻기 위한 `@Web` 표기법

'@웹' 방식은 질문자의 질문에 대해 먼저 검색 엔진 검색을 한 다음, 추출한 문맥의 검색 결과에서 LLM에 공급되는 방식과 유사하지만, 커서 관계자가 구체적인 구현 방법을 공개하지 않아서 실제로는 선악의 변동에 따른 사용 결과가 조정되지 않았습니다.

문제가 있는데 게을러서 오류를 검색하기 위해 페이지를 열지 않거나 큰 모델의 자체 답변으로 문제가 해결되지 않는 경우 이 메모를 사용하면 됩니다.

5. `@폴더` 참고, 파일 디렉토리 정보 전달을 위한 컨텍스트

폴더` 노트는 파일 디렉터리에 대한 정보를 제공할 수 있으므로 경로 문제가 발생하면 이 노트를 사용해 큰 모델에서 해결책을 찾아보세요.

@폴더` 노트

6. 파일 내 코드 생성 창에서만 사용할 수 있는 표기법인 `@Chat` 표기법.

파일 내 코드 생성 창(`CTRL + K`로 여는 창)에서만 사용할 수 있는 `@Chat` 메모는 오른쪽에 열린 대화창의 대화 내용을 더 큰 모델에 컨텍스트로 전달합니다.

채팅` 노트

7. 파일 내 코드 생성 창에서만 사용할 수 있는 `@정의` 메모입니다.

채팅` 노트와 마찬가지로 `@정의` 노트는 파일 안의 코드 생성 창에서만 사용할 수 있습니다. 이 노트는 커서를 가져간 코드 줄에 포함된 변수와 유형에 대한 정의를 `@Code` 노트와 비슷하게 더 큰 모델에 컨텍스트로 전달합니다.

`@정의` 참고

8. `@Git` 참고, 대화창에서만 사용할 수 있습니다.

대화 창은 `CTRL + L` 및 `CTRL + I`로 열리는 창입니다. @Git` 노트는 현재 Git 저장소의 커밋 기록을 컨텍스트로 빅 모델에 전달할 수 있습니다.

코드 공동 작업 중 전범 허가를 확인할 때 사용하기에 더 적합하다고 느껴집니다.

8. 코드베이스에서 전달할 적절한 파일을 검색하기 위해 대화 창에서만 사용할 수 있는 `@코드베이스` 메모입니다.

코드베이스` 노트는 그다지 유용하지 않습니다. 코드베이스를 훑어보기보다는 코드베이스에서 원하는 파일을 찾기 위한 컨텍스트 전달, 즉 `CodebaseFilter`에 가깝기 때문입니다.

필터 매개 변수를 설정하려면 필터 조건을 통과해야 하기 때문에 일반적인 개발에는 사용되지 않을 것 같습니다:

코드베이스` 노트에는 수량, 필터링/소팅에 사용되는 모델 등에 대한 정보를 전달해야 합니다.

이 단축키와 `CTRL + Enter` 단축키의 차이점은 아마도 쿼리에 대한 필터링 규칙을 사용자 지정할 수 있다는 점일 것입니다. 하지만 그다지 유용하지는 않다고 생각합니다.

궁극

여유가 된다면 커서를 사용해 보세요. 커서가 없더라도 정말 좋은 경험이 될 것입니다. 제가 한 말이 많지 않다고 생각하지 마시고 그냥 사용해보시면 좋은 경험을 하실 수 있을 거예요. 개발 경험은 정말 좋습니다.

이 글은 재번역이라고는 하지만 기본적으로 제가 직접 사용해본 경험을 적어놓은 것 같습니다~ 그래서 원문을 보시면 아마 여기에 맞는 내용이 없으실 겁니다.

이 글을 다시 분류할지 여부에 대해 약간 고민하고 있습니다. 원래 글을 보고 사용 방법에 대한 간단한 튜토리얼을 직접 작성하고 싶다는 생각이 들었지만 이 글의 구조가 원래 글의 영향을 많이 받았기 때문입니다. 아아, 고민이네요.