지난 1월, GitHub Copilot 청구서를 보고 잠깐 멍했다. 팀이 커지면서 시트 수가 늘었는데, 어느새 월 구독료가 무시하기 어려운 금액이 되어 있었다. 그때 팀 리드가 슬랙에 메시지를 보냈다: “이번 분기 툴링 비용 한번 검토해봐요.” 그게 2주짜리 대안 탐색의 시작이었다.
Cursor, Codeium, Tabnine, Amazon Q — 이 네 가지를 실제 프로젝트 작업 중에 돌려가면서 써봤다. 완벽한 통제 실험은 아니었지만, 동일한 태스크 유형으로 각각을 평가했고, 느낀 점을 있는 그대로 정리한다.
테스트 환경: 내 세팅부터 밝혀두는 게 맞다
이런 비교는 컨텍스트가 굉장히 중요하다. 같은 도구도 쓰는 사람의 스택과 워크플로우에 따라 평가가 완전히 달라진다.
나는 주로 TypeScript/Node.js로 백엔드를 짜고, React로 프론트를 만든다. 팀은 나 포함 5명이고 모노레포 구조로 여러 서비스를 관리한다. 평소 VS Code를 쓰는데, Cursor가 VS Code 기반이라 전환 비용이 낮았다. AWS 환경에서 배포하기” rel=”nofollow sponsored” target=”_blank”>배포하고 있어서 Amazon Q에 대한 기대도 있었던 게 사실이다.
테스트한 태스크는 이런 것들이었다:
- 기존 REST API에 새 엔드포인트 추가
- 레거시 JavaScript 코드를 TypeScript로 마이그레이션
- Jest로 유닛 테스트 작성
- 코드 리뷰 피드백 반영
- 낯선 라이브러리(Zod, tRPC) 빠르게 파악하기
각 도구를 3~4일씩 주 작업 도구로 돌려봤고, 일부 태스크는 다른 도구로 다시 시도해서 비교했다.
Cursor: 기대가 컸던 만큼 처음에 실망했고, 결국 가장 많이 썼다
솔직히 Cursor에 대한 기대가 네 가지 중 가장 컸다. X(구 트위터)에서 “Cursor 쓰고 개발 속도가 몇 배 됐다”는 포스팅을 너무 많이 봤거든. 근데 처음 이틀은 그냥… 그랬다.
문제는 내가 Cursor를 VS Code처럼만 쓰려고 했다는 거다. Cursor의 핵심은 Cmd+K와 Cmd+L인데, 나는 계속 인라인 자동완성에만 의존하고 있었다. Cmd+K로 선택한 코드 블록을 직접 수정하고, Cmd+L로 코드베이스 전체를 컨텍스트로 삼아 대화하는 방식에 익숙해지는 데 이틀이 걸렸다. 도구가 아니라 내 습관이 문제였던 것.
그 이후로는 달랐다. 특히 레거시 마이그레이션 작업에서 빛났다. JS 파일을 열고 Cmd+L로 “이 파일을 TypeScript로 마이그레이션해줘. Zod 스키마로 타입 검증도 추가하고, 기존 테스트가 깨지지 않게 해줘”라고 하면 — 완벽하진 않지만 — 70~80% 정도는 쓸 만한 결과가 나왔다.
// Cursor가 제안한 마이그레이션 결과 (실제 작업에서 발췌)
// 원본 JS: req.body를 타입 없이 그냥 쓰던 코드
import { z } from 'zod';
import { Request, Response } from 'express';
const CreateUserSchema = z.object({
email: z.string().email(),
name: z.string().min(1).max(100),
role: z.enum(['admin', 'user', 'viewer']),
});
type CreateUserInput = z.infer<typeof CreateUserSchema>;
export async function createUser(req: Request, res: Response) {
// 파싱과 에러 핸들링까지 자동으로 추가해줬다 — 예상보다 훨씬 나은 결과
const result = CreateUserSchema.safeParse(req.body);
if (!result.success) {
return res.status(400).json({ errors: result.error.flatten() });
}
// 이후 로직...
}
한 가지 함정이 있다 — .cursorrules 파일로 프로젝트 컨텍스트를 설정하는 기능인데, 이걸 제대로 구성하지 않으면 제안 품질이 들쭉날쭉하다. 팀 코딩 컨벤션, 사용하는 라이브러리 목록, 피해야 할 패턴 같은 걸 명시해두면 제안이 확연히 달라진다. 처음에 이걸 모르고 “왜 이렇게 엉뚱한 걸 추천하지?” 하고 불만가졌다가, 나중에서야 .cursorrules 탓인 걸 깨달았다. 이걸 설정하기 전과 후가 사실상 다른 도구다.
가격은 개인 플랜이 월 $20, 팀 플랜이 시트당 $40이다. Copilot과 비교하면 비싸거나 비슷한 수준인데, 사용성 차이를 경험하고 나면 이 가격에 대한 감각이 좀 달라진다.
Codeium(이제 Windsurf): 무료인데 이 정도면 충분한 팀이 분명 있다
Codeium은 작년에 Windsurf IDE를 내놓으면서 브랜딩이 좀 복잡해졌다. VS Code 플러그인 형태의 Codeium은 여전히 무료 플랜이 있고, Windsurf는 별도 IDE다. 나는 VS Code 플러그인 버전을 테스트했다.
인라인 자동완성 품질만 놓고 보면, Cursor나 Copilot에 크게 뒤지지 않는다. 반복적인 패턴을 파악하는 속도가 특히 빠르다.
// Codeium이 패턴을 파악하고 나머지를 채운 예시
// 위에 비슷한 함수 두 개가 있으면, 세 번째는 거의 자동으로 완성된다
async function getUserById(id: string): Promise<User | null> {
return db.users.findUnique({ where: { id } });
}
async function getUserByEmail(email: string): Promise<User | null> {
return db.users.findUnique({ where: { email } });
}
// 함수 시그니처만 작성했더니 구현부가 바로 완성됐다
async function getUserByUsername(username: string): Promise<User | null> {
// ↑ 여기까지만 쓰면 Codeium이 나머지를 제안
근데 여기서 Cursor와의 차이가 명확하게 드러난다. Codeium은 “코드를 완성해주는 도구”에 가깝고, Cursor는 “코드를 같이 짜는 도구”에 가깝다는 느낌이랄까. 여러 파일에 걸친 리팩터링이나, 코드베이스 구조를 이해한 상태에서 의사결정이 필요한 작업에서 Codeium은 한계가 생긴다. Cursor의 Cmd+K 같은 인터랙티브 편집 경험이 없기 때문이다.
비용이 실질적인 제약이라면, Codeium 무료 플랜은 진지하게 고려할 만하다. Windsurf Pro가 월 $15인데, 이건 직접 충분히 써보지 않아서 의견을 내기가 어렵다 — 이 부분은 직접 확인해봐라.
Amazon Q Developer: AWS 팀 아니면 매력이 반감된다
Amazon Q에 기대가 있었던 이유는 단순하다. 우리 팀이 CloudFormation, Lambda, ECS 등 AWS를 많이 쓰기 때문이다. Q가 이 컨텍스트를 잘 안다면 다른 도구들과 다른 가치가 있을 것 같았다.
AWS 관련 작업에서는 확실히 강점이 있다. IAM 정책 작성할 때 “이 Lambda 함수가 특정 S3 버킷에서 읽고 DynamoDB 테이블에 쓸 수 있는 최소 권한 정책”이라고 하면 꽤 정확한 결과가 나왔다. CloudFormation 템플릿이나 AWS SDK 호출 패턴도 마찬가지다. Copilot이나 Cursor가 범용 학습 데이터에서 AWS를 아는 것과, Q가 AWS를 아는 건 깊이가 다르다는 게 실제로 느껴졌다.
일반적인 TypeScript/React 작업에서는 Cursor나 Codeium보다 확연히 아쉬웠다. 컨텍스트 이해가 얕고, 제안이 뻔한 경우가 많았다. 특히 프로젝트 특화 패턴을 반영하는 속도가 느렸다. 그리고 솔직히 말하면, IDE 플러그인보다 AWS 콘솔 내에서 쓸 때 훨씬 자연스럽다는 인상이었다 — 아직 IDE 통합이 콘솔 통합만큼 완성도 있지 않은 것 같다.
Q Developer Free 티어는 개인 사용자에게 꽤 관대하지만, 팀 단위로 쓰려면 시트당 $19/월의 Pro 플랜이 필요하다.
Tabnine: 코드가 외부로 나가면 안 되는 팀을 위한 선택지
Tabnine은 이번 비교에서 좀 독특한 포지션에 있다. 차별점이 코딩 어시스턴트 성능이 아니라, 코드 보안과 온프레미스 배포에 있기 때문이다.
금융권, 의료, 공공 부문처럼 코드가 외부 클라우드 서버” rel=”nofollow sponsored” target=”_blank”>서버로 나가면 안 되는 환경이라면, Tabnine Enterprise의 Self-hosted 옵션이 현실적으로 얼마 안 되는 선택지 중 하나다. 이 맥락에서 다른 도구들과 성능을 비교하는 건 의미가 없다 — 컴플라이언스 요구사항이 있다면 Tabnine은 타협이 아니라 유일한 경로일 수 있다.
순수하게 코딩 어시스턴트 성능만 보면, 네 가지 중 가장 보수적이다. 대신 팀 코드베이스를 학습해서 조직 특화 제안을 해주는 기능이 있는데, 몇 주 쓰다 보면 팀 컨벤션을 꽤 잘 반영한다. 다만 초기 학습 기간이 필요하고, 그 전까지는 다른 도구들에 비해 제안이 밋밋하게 느껴질 수 있다. 일반 스타트업이나 소규모 팀에게 먼저 추천하기는 어렵다.
결국 우리가 선택한 것
2주 테스트가 끝나고 팀과 논의한 결과, Cursor Teams로 갔다.
이유를 구구절절 나열하기보다 핵심만 말하자면 — @codebase 기능으로 전체 모노레포를 참조하면서 대화할 수 있는 게 실제 작업 흐름을 바꿨다. “이 엔드포인트가 어떤 미들웨어를 통과하는지 추적해줘”나 “이 타입이 어디서 정의되고 어디에 쓰이는지 보여줘” — 이런 걸 물어볼 수 있다는 게 Cursor와 나머지 도구들의 진짜 차이다. 인라인 자동완성은 모두 비슷한 수준에 왔는데, 이 대화형 컨텍스트 이해 능력이 아직 Cursor가 앞선다.
VS Code 사용자라면 UI가 거의 동일하고 새로운 단축키 몇 개만 익히면 된다. 팀에서 가장 보수적인 팀원도 일주일 만에 적응했다. 그리고 예상치 못했던 부수 효과가 있었는데, .cursorrules에 팀 컨벤션을 명시해두니 새 팀원 온보딩에서 시니어가 리뷰 때마다 같은 말을 반복하는 횟수가 줄었다.
상황이 다르다면 선택도 달랐을 것 같다. 비용이 진짜 제약이라면 Codeium 무료 플랜 — 인라인 완성 품질만 보면 충분히 쓸 만하다. AWS 작업이 전체의 70% 이상이라면 Amazon Q를 더 깊이 테스트할 가치가 있다. 코드가 외부로 나가면 안 되는 규제 환경이라면 Tabnine Enterprise가 유일한 답이다.
마지막으로 하나만 — 이 도구들은 빠르게 업데이트된다. 내가 테스트를 마칠 즈음 Cursor가 새 버전을 냈고, Codeium도 업데이트가 있었다. 내가 지적한 단점이 이미 개선됐을 수도 있다. 이 글은 참고만 하고, 본인 워크플로우에서 직접 2~3일은 써봐야 한다. 모두 무료 플랜이나 트라이얼을 제공하니까.