지난 두 달 동안 실제 업무에 Cursor AI와 GitHub Copilot을 번갈아 써봤다. 임베디드 C 코드, Python 자동화 스크립트, Flutter 앱, 그리고 이 블로그의 Hugo 템플릿까지 — 꽤 다양한 코드베이스에서 두 도구를 굴려봤다.
결론부터: 둘 다 쓸 만하고, 어느 게 낫냐는 질문에는 “상황에 따라"라는 답이 정직하다. 하지만 그 “상황"이 무엇인지 구체적으로 말해주는 리뷰가 없어서 직접 정리했다.
나의 개발 환경과 사용 맥락 #
리뷰를 읽기 전에 내 환경을 알아야 맥락이 맞다:
- 주 OS: Windows 11 + WSL2 (Ubuntu)
- 주 IDE: VS Code (Cursor는 VS Code 포크이므로 환경 이전 거의 없음)
- 주요 언어: Python, C/C++, Dart(Flutter), TypeScript
- 팀 규모: 5~8명, GitHub 사용
두 달 플랜:
- 1개월: GitHub Copilot Pro ($10/월)
- 1개월: Cursor Pro ($20/월)
GitHub Copilot — 한 달 사용 후기 #
잘하는 것 #
인라인 완성은 진짜 빠르다. Tab 키 하나로 코드가 완성되는 경험은 익숙해지면 없어서는 안 될 것처럼 된다. 특히 반복적인 패턴 — 비슷한 구조의 함수를 여러 개 작성할 때, 테스트 케이스를 쭉 늘어놓을 때, 설정 파일 작성할 때 — 은 Copilot이 흐름을 끊지 않고 따라온다.
GitHub PR 통합이 생각보다 유용했다. gh copilot suggest로 셸 명령어 힌트를 받거나, PR에 자동으로 Summary를 달아주는 기능은 리뷰어 입장에서 편리하다. GitHub에 모든 게 묶여 있는 팀이라면 이 부분의 시너지가 크다.
JetBrains 지원: 팀원 중 CLion을 쓰는 사람이 있는데, Copilot은 JetBrains 전 제품군을 지원한다. Cursor는 VS Code 계열 전용이라 이 부분은 Copilot의 명확한 강점이다.
아쉬운 것 #
멀티파일 컨텍스트가 약하다. “이 함수를 리팩토링하는데 저 파일의 인터페이스도 함께 바꿔줘"라는 요청을 처리하는 능력이 Cursor에 비해 현저히 떨어진다. 열려 있는 파일과 그 주변만 본다는 느낌.
임베디드 C에서 환각이 많다. MCU 레지스터 이름, 특정 칩의 HAL 함수 시그니처 등에서 그럴싸하지만 존재하지 않는 API를 만들어내는 경우가 잦았다. 데이터시트 참조 없이 자신 있게 틀린다.
Cursor AI — 한 달 사용 후기 #
잘하는 것 #
Composer(Cmd+I) 기능이 압도적이다. “현재 프로젝트의 모든 라우터 파일에서 deprecated된 res.json() 패턴을 찾아서 res.status(200).json()으로 바꿔줘” — 이런 요청을 처리하는 능력이 Copilot과 비교가 안 된다. 영향받는 파일 목록과 각각의 diff를 보여주고, 파일별로 Accept/Reject를 선택할 수 있다.
실제로 이런 작업을 했다: Flutter 프로젝트에서 Navigator 1.0 방식을 GoRouter로 마이그레이션하는 작업. 파일이 20개 이상 영향받는 상황이었는데, Cursor Composer가 전체 변경 사항 초안을 5분 만에 잡아줬다. 직접 했다면 반나절 이상 걸렸을 작업이다.
@codebase 검색이 유용하다. “이 프로젝트에서 MQTT 연결을 초기화하는 부분이 어디야?“라고 물으면 실제 코드를 찾아서 보여준다. 모른다고 하거나 관련 없는 코드를 갖다주는 경우가 적다.
모델 선택 유연성. Claude Sonnet을 기본으로 쓰다가 복잡한 아키텍처 질문은 Claude Opus로 전환하는 방식이 효율적이다. 작업 유형에 따라 모델을 바꿀 수 있다는 건 단순한 기능처럼 보이지만 실제로 꽤 차이가 난다.
아쉬운 것 #
월 $20, 가격이 부담스럽다. Copilot 대비 2배다. 팀 전체로 라이선스를 사면 비용이 상당하다. 개인 사용이라면 감당할 만하지만 10명 팀에 도입하면 월 $200 추가 비용이다.
가끔 자신감 넘치는 오류. Cursor도 환각에서 자유롭지 않다. 특히 프로젝트에 없는 라이브러리 함수를 당당하게 쓰는 코드를 생성하는 경우가 있다. AI 제안은 항상 검증해야 한다는 전제를 잊으면 안 된다.
딥슬립 모드 후 응답 느림. 오래 안 쓰다가 Composer를 다시 켜면 첫 응답이 느린 경우가 있다. 사소한 UX 문제지만 집중의 흐름을 끊는다.
직접 비교 — 같은 작업을 두 도구로 #
테스트: “SQLAlchemy ORM 모델 5개를 Pydantic v2 스키마로 변환하라”
Copilot:
- 하나씩 설명하면서 진행 필요
- 파일 간 관계(foreign key → 중첩 스키마)를 명시적으로 설명해줘야 처리
- 소요 시간: 약 20분
Cursor Composer:
- “이 프로젝트의 models.py를 분석해서 Pydantic v2 스키마로 전환해줘”
- 자동으로 관계 파악, 전체 schemas.py 초안 생성
- 소요 시간: 약 5분 (검토 포함)
이 차이는 작업 규모가 클수록 더 벌어진다.
가격 대비 가치 분석 #
Copilot이 더 합리적인 경우 #
- 이미 VS Code + GitHub 생태계에 깊이 박혀 있는 팀
- JetBrains IDE 사용자 포함 팀
- 주로 단일 파일 수준의 코드 완성이 필요한 작업
- 비용에 민감한 개인 또는 소규모 팀
- 인라인 완성 속도가 최우선
Cursor가 더 합리적인 경우 #
- 대형 코드베이스 리팩토링이 잦은 팀
- 레거시 코드 파악에 시간을 많이 쓰는 팀
- 신규 기능 개발 시 여러 파일에 걸친 변경이 많은 경우
- 모델 유연성이 중요한 경우 (다양한 AI 모델 시험)
- 개인 생산성 극대화에 투자할 의사가 있는 경우
13년 차 시각에서의 결론 #
솔직히 둘 다 있으면 있을수록 좋다. 하지만 하나만 골라야 한다면:
혼자 일하거나 프리랜서라면 Cursor를 쓴다. $20이 아깝지 않을 만큼 생산성 차이가 난다. Composer 기능 하나만으로도 월 구독료를 뽑는다.
팀 도입이라면 Copilot이 현실적이다. 팀원 모두의 IDE가 다를 수 있고, 비용 부담을 설득하기도 쉽다. 그리고 솔직히 말하면, AI 도구 사용 능력 자체가 팀마다 차이가 커서 $10짜리도 제대로 못 쓰는 팀이 많다. 도구 보다 활용 문화가 먼저다.
한 가지 분명히 말할 수 있는 건, 이제 AI 코딩 도구를 안 쓰는 선택지는 없다. 속도 차이가 너무 크다. 어느 걸 쓸지는 선택이지만, 쓸지 말지는 이미 답이 나왔다.