수년 동안 VS Code는 명백한 기본값이었습니다. 빠르고, 확장 가능하며, 익숙했고, 거의 모든 종류의 개발 작업에 충분히 훌륭했습니다. 저는 많은 엔지니어들이 그러하듯 VS Code를 사용했습니다. 세련된 에디터, 몇 가지 플러그인, 하단의 터미널, 그리고 결국에는 그 위에 덧붙여진 AI 확장 프로그램(extension)과 함께 말이죠.

그 설정은 잘 작동했습니다. 하지만 그것은 항상 타협처럼 느껴졌습니다.

Cursor는 AI를 부가 기능(add-on)으로 취급하지 않는 제가 사용해 본 첫 번째 도구입니다. Cursor는 AI를 개발 환경(development environment) 그 자체의 일부로 취급합니다. 이 차이는 실제로 며칠 동안 작업해 보기 전까지는 미묘하게 들릴 수 있습니다. 하지만 일단 경험하고 나면 명확해집니다. 우리는 더 이상 단순히 코드를 편집하는 것이 아닙니다. 우리는 AI의 도움을 받아 소프트웨어를 오케스트레이션(orchestrating)하고 있으며, Cursor는 그러한 현실을 위해 구축되었습니다.

코딩에서 오케스트레이션으로의 전환

전통적인 개발 도구들은 수동 편집을 중심으로 설계되었습니다: 파일 검색, 정의로 이동(jump to definitions), 신중한 리팩터링(refactor), 테스트 실행, 그리고 반복. VS Code의 AI 확장 프로그램들은 이러한 워크플로(workflow)를 개선하지만, 아주 미미한 수준에 그칩니다. 그것들은 여전히 에디터의 핵심 모델 외부에 존재하는 도우미처럼 느껴집니다.

Cursor는 모델을 바꿉니다.

"내 에디터 안에서 AI를 어떻게 사용할까?"라고 묻는 대신, 더 나은 질문은 "내 코드베이스(codebase) 전체에서 작동하도록 AI를 어떻게 지시할까?"가 됩니다. 이것이 바로 Cursor가 제대로 짚어낸 사고방식의 전환입니다. Cursor는 에디터를 LLM(Large Language Model)이 문맥(context)을 추론하고, 여러 파일에 걸쳐 변경 사항을 만들며, 사용자가 모든 단계를 미세하게 관리(micromanage)할 필요 없이 더 높은 수준의 지침에 응답할 수 있는 작업 공간으로 변모시킵니다.

Composer는 핵심 기능(killer feature)입니다

Composer는 Cursor를 즉시 선택해야 할 이유를 만들어주는 기능입니다.

VS Code에서는 최고의 AI 확장 프로그램을 사용하더라도 여러 파일에 걸친 변경(multi-file changes)은 여전히 어색합니다. 도움을 요청할 수는 있지만, 대개 패널 사이에서 복사하여 붙여넣거나, 수동으로 패치(patch)를 적용하거나, 상태를 일치시키기 위해 채팅과 에디터를 계속 왔다 갔다 해야 합니다. 워크플로가 파편화되어 있습니다.

Composer는 그러한 파편화를 제거합니다. 사용자가 "이 인증 흐름을 서비스 레이어(service layer)로 추출해줘" 또는 "이 REST 엔드포인트들이 공유 검증(shared validation)을 사용하도록 변환해줘"와 같이 작업을 한 번만 설명하면, Cursor는 관련 파일 전체에 걸쳐 변경 사항을 조정할 수 있습니다. 이는 단순히 코드 스니펫(snippet)을 생성하는 것이 아니라, 하나의 작업을 관리하는 것입니다.

이것이 중요한 이유는 대부분의 실제 엔지니어링 작업이 고립된 함수를 작성하는 것이 아니라, 시스템을 변경하는 것이기 때문입니다.

Composer는 기능 구현(feature implementation), 리팩터링(refactoring), 정리(cleanup), 마이그레이션(migration), 그리고 코드베이스 전반의 일관성 유지와 같이 개발자들이 실제로 수행하는 종류의 작업에 AI를 유용하게 만들어 줍니다. 이는 단순한 자동 완성(autocomplete)이라기보다, 저장소(repo)를 이해하고 계획을 실행할 수 있는 유능한 주니어 엔지니어와 일하는 느낌을 줍니다.

코드베이스 인덱싱(Codebase indexing)은 영리함과 유용함의 차이를 만듭니다

AI 도구들이 실무에서 실패하는 큰 이유 중 하나는 컨텍스트(context)입니다. 만약 모델이 코드베이스를 이해하지 못한다면, 기술적으로는 그럴듯해 보이지만 운영상으로는 틀린 답변을 내놓게 됩니다.

Cursor의 코드베이스 인덱싱은 AI가 근거를 갖춘 것처럼 느껴지게 만드는 핵심 요소입니다. 단순히 현재 파일에만 응답하는 것이 아니라, 저장소 구조에 대한 이해를 구축하고 이를 바탕으로 제안을 제공합니다. 이는 더 나은 답변, 더 적은 환각(hallucination) 참조, 그리고 훨씬 더 신뢰할 수 있는 파일 간 편집을 의미합니다.

이 지점이 Cursor가 "VS Code 내의 AI 확장 프로그램(extension)" 방식보다 확실히 앞서는 부분입니다. 그러한 도구들은 종로히 사용자가 명시적으로 제공하는 정보에 크게 의존합니다. 반면 Cursor는 소프트웨어 엔지니어링에서 LLM을 사용할 때 가장 짜증 나는 부분 중 하나인 컨텍스트 관리의 부담을 줄여줍니다.

컨텍스트를 다루는 수고가 줄어든다는 것은 실제 문제를 해결하는 데 더 많은 시간을 쓸 수 있음을 의미합니다.

도구를 쌓아 올리는 것이 아닌, 매끄러운 LLM 통합

최고의 AI 도구는 워크플로 속에 자연스럽게 녹아들어 보이지 않게 됩니다. Cursor는 이 점을 매우 잘 수행합니다.

에디터와 AI 제품 사이를 전환하고 있다는 느낌이 들지 않습니다. 모델이 필요한 순간—편집(editing), 리팩터링(refactoring), 질문하기, 변경 사항 검토(reviewing changes), 그리고 새로운 코드 생성(generating new code)까지—모두 동일한 환경 내에서 즉시 사용할 수 있는 하나의 통합된 시스템에서 작업하고 있다는 느낌을 받게 됩니다.

이러한 매끄러움(seamlessness)은 과소평가되어 있습니다. VS Code에 AI 확장 프로그램(extensions)을 추가한 방식은 에디터, 플러그인, 채팅창, 차이점 보기(diff view), 터미널 등 별개의 부품들을 조립해 놓은 것처럼 느껴질 때가 많습니다. 반면 Cursor는 단일 워크플로 루프(workflow loop)를 중심으로 설계된 느낌을 줍니다.

그리고 일단 그 루프에 익숙해지면, 다시 돌아가는 것은 고통스럽습니다.

왜 이것이 VS Code + 확장 프로그램보다 나은가

분명히 말씀드리자면, VS Code는 여전히 훌륭합니다. 하지만 VS Code의 AI 스토리는 여전히 부가적인(additive) 방식입니다. Cursor의 AI는 네이티브(native)입니다.

이 차이는 일상적인 작업에서 다음과 같이 나타납니다:

• 더 빠른 다중 파일 변경 (multi-file changes)
• 저장소 컨텍스트 (repository context)에 대한 더 나은 인지
• 도구 간의 복사-붙여넣기 감소
• LLM과의 더 자연스러운 상호작용
• 몰입 상태 (flow state)의 방해 감소

다시 말해, Cursor는 단순히 코딩을 빠르게 만드는 것이 아닙니다. 조정(coordination) 비용을 낮춰줍니다. 그리고 현대의 소프트웨어 작업에서 실제 비용이 많이 발생하는 지점은 바로 이 조정 단계입니다.

결론

만약 당신이 여전히 AI를 단순한 코딩 보조 도구로 생각한다면, 확장 프로그램을 사용한 VS Code로도 충분할 것입니다.

하지만 개발이 나아가는 방향—AI 지원 계획 수립(AI-assisted planning), 코드베이스 전반의 변환(codebase-wide transformations), 그리고 더 높은 수준의 오케스트레이션(higher-level orchestration)—을 보고 있다면, Cursor가 더 나은 환경입니다. 이는 단순히 더 멋진 에디터가 아닙니다. 소프트웨어가 점점 더 구축되는 방식에 더 적합한 더 나은 인터페이스입니다.

제가 단순히 유행하는 새로운 개발 도구를 원해서 바꾼 것이 아닙니다. Cursor가 기존의 워크플로를 구식처럼 느껴지게 만들었기 때문에 바꾼 것입니다.

그리고 일단 그것을 경험하고 나면, 다시 돌아가기는 어렵습니다.