Cursor로 갈아탄 후 3개월, VS Code로 돌아가지 않는 이유

프로토타입 하나 만드는데 개발자 3일 기다리기 vs 30분 만에 직접 만들기

지난 분기, 우리 팀은 새로운 기능 아이디어를 놓고 2주간 회의만 했다. 개발 리소스가 부족했고, PM인 내가 할 수 있는 건 피그마로 목업 만들고 PRD 쓰는 것뿐이었다. 그러다 Cursor를 만났고, 3개월이 지난 지금 나는 주 2-3개의 프로토타입을 직접 만들어낸다.

VS Code를 5년간 써온 사람으로서(주로 문서 작업과 간단한 스크립트), Cursor로의 전환은 단순한 에디터 교체가 아니었다. 이건 PM의 역할 정의를 바꾸는 도구였다.

Cursor가 VS Code + GitHub Copilot과 다른 결정적 차이

사람들은 "Cursor = VS Code + 더 나은 AI"라고 말한다. 틀렸다. 근본적으로 다른 철학으로 만들어진 도구다.

컨텍스트 이해의 깊이

GitHub Copilot은 현재 파일과 주변 몇 줄을 본다. Cursor는 프로젝트 전체를 이해한다. 실제로 측정해봤다:

• VS Code + Copilot: 20줄짜리 컴포넌트 수정 요청 시 정확도 약 60%
• Cursor: 동일 작업에서 정확도 약 85%
• Cursor의 Composer 모드: 여러 파일 동시 수정 시 90% 이상

디자이너 출신으로서 특히 중요했던 건, 내가 "이 버튼을 오른쪽으로 옮기고, 색상은 primary로, 호버 시 애니메이션 추가"라고 자연어로 말하면 관련된 CSS, 컴포넌트, 테마 파일을 알아서 찾아 수정한다는 점이다.

Cmd+K의 마법

Cursor의 Cmd+K는 단순한 코드 제안이 아니다. 이건 대화다.

실패 사례를 공유하면: 첫 주에 나는 Cmd+K를 검색창처럼 썼다. "버튼 컴포넌트 만들어줘"라고 치고 엔터. 결과는 형편없었다. 2주차에 깨달았다 - 이건 페어 프로그래밍이다.

지금 내 사용 패턴:

1. Cmd+K로 의도 설명 ("사용자가 이미지 업로드하면 미리보기 보여주는 컴포넌트 필요")
2. 생성된 코드 리뷰
3. 다시 Cmd+K로 수정 요청 ("좋은데, 파일 크기 제한 5MB 추가하고, 에러 시 토스트 메시지")
4. 반복

이 방식으로 나는 React를 '제대로' 몰라도 production-ready 컴포넌트를 만든다. 3개월간 만든 프로토타입: 12개. 그 중 8개가 실제 제품에 반영됐다.

Composer: 게임 체인저

Composer는 Cursor의 숨겨진 무기다. 여러 파일을 동시에 수정하는 AI 에이전트인데, PM에게는 이게 왜 중요할까?

사례: 우리 제품의 결제 플로우를 재설계하고 싶었다. 관련 파일이 7개였다:

• 3개의 React 컴포넌트
• 2개의 API 호출 함수
• 1개의 상태 관리 스토어
• 1개의 타입 정의 파일

VS Code 시절이었다면:

1. PRD 작성 (2시간)
2. 개발자와 미팅 (1시간)
3. 개발 대기 (3-5일)
4. QA 후 피드백 (2일)
5. 재수정 (2일)

총 약 2주.

Cursor Composer로:

1. Composer 열기
2. "결제 플로우를 3단계로 간소화. 각 단계마다 진행 바 표시, 마지막에 애니메이션 컨펌" 입력
3. 7개 파일 자동 수정
4. 로컬에서 테스트
5. 개발자에게 "이런 느낌인데 구현 가능?" 물어보기

총 2시간. 그리고 개발자는 이미 작동하는 프로토타입을 보고 "이거 코드 괜찮은데요?" 반응.

하지만 Cursor가 만능은 아니다 (3개월간의 솔직한 후기)

실패율 20%는 여전히 존재한다

통계를 냉정하게 보자. 내가 Cursor로 시도한 작업 중:

• 80%는 첫 시도에 원하는 결과
• 15%는 2-3번 수정 후 성공
• 5%는 결국 개발자 도움 필요

특히 실패하는 케이스:

• 복잡한 상태 관리 로직
• 성능 최적화가 필요한 부분
• 보안이 중요한 인증/결제 로직

PM으로서 배운 교훈: Cursor는 프로토타입과 80% 해결책에 완벽하다. 나머지 20%는 여전히 전문가가 필요하다. 그리고 그게 맞다.

비용: $20/월의 가치

Cursor Pro는 월 $20. GitHub Copilot은 $10. 2배 비싼데 값어치 할까?

내 계산:

• Cursor로 절약한 개발자 시간: 월 평균 20시간
• 우리 팀 개발자 시급 환산: 약 $80
• ROI: $1,600 / $20 = 8,000%

물론 이건 내가 실제로 쓸모있는 결과물을 만들었을 때만 유효하다. 처음 한 달은 삽질하면서 배우는 기간이었다.

VS Code로 돌아갈 이유가 없는 이유

Cursor는 VS Code 포크다. 즉, 내 모든 익스텐션, 설정, 단축키가 그대로 작동한다. 전환 비용이 거의 제로였다.

그런데 돌아갈 이유가 없다:

• AI 기능 빼면 VS Code와 동일
• AI 기능 더하면 차원이 다름
• 속도나 안정성에서 문제 없음

단 하나, VS Code로 돌아가야 할 케이스: 거대한 모노레포 작업 시 가끔 느려진다. 하지만 PM이 그런 환경에서 일할 일은 거의 없다.

PM이 Cursor를 쓰면 달라지는 것들

회의가 줄어든다

전: "이 기능 가능한가요? 어느 정도 걸릴까요?" 후: "이렇게 만들어봤는데, 이 방향 어떤가요?"

데이터: 우리 팀의 기능 논의 회의 시간이 주 8시간에서 3시간으로 감소했다. 프로토타입이 있으면 논쟁이 줄어든다.

빌드-측정-학습 사이클 가속

린 스타트업의 핵심은 빠른 검증이다. Cursor 이전엔 아이디어 → 프로토타입까지 평균 5일. 이후 → 평균 0.5일.

10배 빨라진 실험 속도는 10배 많은 학습을 의미한다. 지난 분기 우리 팀은 17개 가설을 테스트했다. 전 분기엔 5개였다.

디자이너 출신의 강점이 극대화된다

내가 코드를 '진짜' 이해하진 못한다. 하지만 UX는 이해한다. Cursor는 내가 UX 의도를 설명하면 그걸 코드로 바꿔준다.

예시: "사용자가 폼 작성 중 페이지 벗어나려 하면 경고 모달. 하지만 이미 제출 완료했으면 경고 안 띄움. 모달은 우리 디자인 시스템 따라서."

이 설명으로 Cursor는:

• beforeunload 이벤트 핸들링
• 상태 기반 조건부 로직
• 디자인 시스템 컴포넌트 import

모두 처리한다. 나는 UX만 생각하면 된다.

3개월 사용자의 실전 가이드

1주차: 기본기 익히기

• 작은 것부터: HTML/CSS 수정으로 시작
• Cmd+K 습관화: 하루 50번 이상 사용 목표
• 실패 두려워 말기: Git 있으니 망가뜨려도 OK

2-3주차: 컨텍스트 마스터하기

• @ 기호 활용법 배우기: @파일명, @폴더명으로 컨텍스트 명시
• "이 파일 기준으로"가 아니라 "이 기능 전체를" 생각하기
• 프로젝트 전체 인덱싱 이해하기

4주차~: Composer 레벨업

• 여러 파일 동시 수정 시도
• 명확한 요구사항 작성 연습
• "이건 왜 안 돼?" → "어떻게 하면 될까?" 사고방식 전환

내가 만든 Cursor 사용 원칙

1. 컨텍스트가 왕: 배경 정보를 충분히 제공할수록 결과가 좋다
2. 반복 개선: 첫 결과가 완벽하지 않아도 OK. 대화하며 다듬기
3. 이해 못 해도 OK: 생성된 코드 100% 이해 못 해도 작동하면 OK (단, 프로토타입에 한해)
4. 한계 인정: 복잡한 건 여전히 개발자에게
5. 버전 관리 필수: Git commit 자주, 실험적 변경은 별도 브랜치

결론: AI 시대의 PM은 빌더다

3개월 전 나는 '아이디어를 전달하는 사람'이었다. 지금은 '아이디어를 만드는 사람'이다.

Cursor는 도구가 아니라 역할의 재정의다. PM이 더 이상 개발자를 기다릴 필요 없다는 뜻이 아니다. 하지만 논의의 질을 바꿀 수 있다는 뜻이다.

"이거 가능해?" 대신 "이렇게 만들어봤는데, 프로덕션에선 어떻게 개선할까?"

이 질문의 차이가 제품의 속도를 바꾼다.

VS Code로 돌아갈 생각 없다. 그리고 만약 당신이 PM, 디자이너, 또는 '기술은 모르지만 만들고 싶은 게 있는' 사람이라면, 지금 당장 Cursor를 설치하라.

첫 달은 어색할 것이다. 두 번째 달엔 재미있을 것이다. 세 번째 달엔, 당신의 역할이 달라져 있을 것이다.

나처럼.