AI 코딩 도구 실무 비교: Copilot, Cursor, Claude Code를 반년간 쓰며 느낀 것들

작년 말쯤, 팀 내에서 "AI 코딩 도구를 안 쓰는 사람이 이제 없지 않냐"는 이야기가 나왔습니다. 실제로 2026년 기준 개발자의 90% 이상이 어떤 형태로든 AI 코딩 도구를 사용하고 있다는 조사 결과도 있고, 체감상으로도 맞는 말이었습니다.

문제는 도구가 너무 많다는 것이었습니다. GitHub Copilot을 1년 넘게 써오고 있었는데, 주변에서 Cursor가 좋다는 소리가 들리고, Claude Code라는 터미널 기반 도구까지 등장하니 "지금 쓰고 있는 게 최선인가?"라는 의문이 슬슬 올라왔습니다.

그래서 약 반년간 세 가지 도구를 실무 프로젝트에서 번갈아 써보면서 비교해봤습니다. 이 글은 그 과정에서 느낀 점들을 정리한 기록입니다.

비교 대상과 사용 환경

비교한 도구는 다음 세 가지입니다.

• GitHub Copilot: VS Code / IntelliJ 플러그인 기반의 자동 완성 도구
• Cursor: VS Code를 포크(Fork)한 AI 네이티브 에디터
• Claude Code: 터미널에서 동작하는 에이전트(Agent) 기반 코딩 도구

사용 환경은 Spring Boot 기반 백엔드 프로젝트였습니다. JPA 엔티티, REST API, 테스트 코드 작성이 주 업무였고, 간간이 Gradle 설정이나 Docker 관련 작업도 있었습니다.

자동 완성의 왕자, GitHub Copilot

Copilot은 가장 오래 써온 도구입니다. 처음 Tab 키 한 번으로 반복 코드가 완성되는 경험을 했을 때의 감동은 아직도 기억합니다.

실무에서 체감되는 Copilot의 강점은 "흐름을 끊지 않는다"는 점이었습니다. 코드를 쓰다가 자연스럽게 다음 줄이 제안되고, 맞으면 Tab, 아니면 무시하면 됩니다. 사고의 흐름이 크게 방해받지 않습니다.

예를 들어 DTO를 만들 때, 필드 하나를 쓰면 나머지 필드와 생성자, 팩토리 메서드까지 줄줄이 제안해주는 식입니다.

public record OrderResponse(
    Long orderId,
    String productName,
    int quantity,
    BigDecimal totalPrice,
    LocalDateTime orderedAt
) {
    // 여기까지 쓰면 아래 팩토리 메서드를 자동 제안
    public static OrderResponse from(Order order) {
        return new OrderResponse(
            order.getId(),
            order.getProduct().getName(),
            order.getQuantity(),
            order.getTotalPrice(),
            order.getCreatedAt()
        );
    }
}

다만, 한계도 분명했습니다. Copilot은 현재 열려 있는 파일과 그 주변 맥락만 봅니다. 프로젝트 전체 구조를 이해하고 제안하는 것은 아니기 때문에, 도메인 간 연관관계가 복잡한 로직에서는 엉뚱한 코드를 제안하는 경우가 잦았습니다.

특히 예외 처리 전략처럼 프로젝트 내 공통 규칙이 있는 부분에서, Copilot은 그 규칙을 모른 채 일반적인 패턴을 제안하곤 했습니다.

프로젝트를 읽는 에디터, Cursor

Cursor를 처음 써봤을 때 가장 인상적이었던 건 @codebase 기능이었습니다. 프로젝트 전체를 인덱싱해서 "우리 프로젝트에서 에러 응답은 어떻게 내려가?"라고 물으면, 실제 코드베이스를 참조해서 답해줬습니다.

이전에 공통 응답 구조를 설계해둔 적이 있었는데, Cursor는 그 구조를 인식하고 새 API를 만들 때도 같은 패턴으로 코드를 생성해줬습니다. Copilot에서는 매번 수동으로 맞춰줘야 했던 부분이었기 때문에, 이건 꽤 큰 차이였습니다.

Cursor의 Composer(작곡가) 모드는 여러 파일을 동시에 수정할 수 있어서, 새 도메인을 추가할 때 특히 편했습니다.

[Cursor Composer에게 요청한 프롬프트]
"Coupon 도메인을 추가해줘.
- JPA Entity, Repository, Service, Controller 구조로
- 기존 Order 도메인의 패턴을 따라서
- 예외 처리는 BusinessException 기반으로"

이렇게 요청하면 45개 파일을 한 번에 생성하고, 기존 코드 컨벤션도 대부분 맞춰줬습니다. 수작업으로 30분은 걸릴 보일러플레이트(Boilerplate) 작업이 23분으로 줄었습니다.

하지만 Cursor도 만능은 아니었습니다. 생성된 코드의 품질이 "80점짜리"인 경우가 많았습니다. 돌아는 가지만, 네이밍이 어색하거나 불필요한 의존성이 들어가 있어서 리뷰 과정에서 수정할 부분이 꽤 있었습니다.

터미널의 아키텍트, Claude Code

Claude Code는 앞의 두 도구와 성격이 많이 달랐습니다. 에디터 플러그인이 아니라 터미널에서 실행되는 에이전트(Agent)입니다. 직접 파일을 읽고, 수정하고, 명령어를 실행합니다.

처음에는 "에디터 없이 코딩 도구를?"이라는 의문이 있었습니다. 그런데 실제로 써보니, 이 도구가 빛나는 순간은 "코드를 한 줄씩 쓰는 작업"이 아니라 "프로젝트 전체를 파악하고 큰 단위로 리팩토링하는 작업"이었습니다.

예를 들어, 이전에 멀티 모듈 아키텍처 분리를 진행할 때 비슷한 규모의 작업이 있었는데, 그때 Claude Code가 있었다면 훨씬 수월했을 것 같습니다. 실제로 모듈 간 의존성을 분석하고 분리 방안을 제안하는 작업에서 Claude Code의 강점이 두드러졌습니다.

$ claude
> OrderService에서 외부 API 호출 로직을 분리하고 싶어.
> module-infra 쪽으로 옮기고, 인터페이스 기반으로 주입받게 바꿔줘.
> 기존 테스트도 깨지지 않게 수정해줘.

이 요청 하나로 Claude Code는 관련 파일 7~8개를 읽고, 인터페이스 추출, 구현체 이동, Import 정리, 테스트 수정까지 한 번에 처리했습니다. 물론 결과를 그대로 수락하기보다는 diff를 꼼꼼히 확인하는 과정이 필요했지만, 작업의 시작점으로서는 압도적이었습니다.

반면, 한 줄 한 줄 코드를 작성하는 일상적인 개발에서는 오히려 불편했습니다. Copilot이나 Cursor처럼 타이핑하면서 바로 제안을 받는 방식이 아니기 때문에, 간단한 CRUD 작업에는 과하다는 느낌이 들었습니다.

세 도구를 나란히 놓고 보면

반년간 써보고 나니, 각 도구의 포지션이 꽤 뚜렷하게 구분됐습니다.

실제 업무에서 어떻게 섞어 쓰게 됐나

결국 "하나만 골라 쓴다"보다는, 작업 종류에 따라 도구를 바꾸는 방식으로 정착했습니다.

일상적인 코딩 — Copilot

서비스 로직을 한 줄씩 작성하거나, 테스트 코드를 쭉 이어서 쓸 때는 Copilot이 가장 자연스러웠습니다. 특히 Testcontainers 기반 통합 테스트를 작성할 때처럼 비슷한 패턴의 테스트를 여러 개 만들어야 하는 상황에서 Copilot의 자동 완성은 큰 도움이 됐습니다.

새 도메인 추가 — Cursor

Entity부터 Controller까지 한 벌을 만들어야 할 때는 Cursor의 Composer가 효율적이었습니다. "기존 패턴을 따라서"라는 지시 한 줄이면, 프로젝트의 컨벤션을 읽고 반영해주기 때문입니다.

구조 변경이나 복잡한 디버깅 — Claude Code

"이 API가 간헐적으로 느린 이유를 찾아줘"처럼 프로젝트 전체를 뒤져야 하는 작업에서는 Claude Code가 빛났습니다. 파일을 하나하나 열어볼 필요 없이 알아서 탐색하고, 문제 지점을 짚어주는 경험은 실제로 꽤 신선했습니다.

주의할 점도 있었다

도구에 익숙해질수록 조심해야 할 부분도 생겼습니다.

첫 번째, 생성된 코드를 그대로 수락하는 습관입니다. 특히 Cursor의 Composer로 대량 생성한 코드는 겉보기에 깔끔해 보여도, 세부적으로 문제가 있는 경우가 많았습니다. 불필요한 @Transactional이 붙어 있거나, N+1 쿼리가 숨어 있거나, 예외 처리가 빠져 있는 식이었습니다.

이전에 JPA N+1 문제를 정리한 적이 있었는데, AI가 생성한 코드에서도 동일한 패턴이 종종 발견됐습니다. AI 도구를 쓴다고 해서 이런 기본기를 생략할 수 있는 건 아니었습니다.

두 번째, 프롬프트에 쏟는 시간입니다. Claude Code에서 원하는 결과를 얻으려면 요구사항을 정확히 서술해야 합니다. 모호하게 물으면 모호한 답이 돌아옵니다. 어떤 날은 프롬프트를 다듬는 데 코드를 직접 쓰는 것보다 더 오래 걸린 적도 있었습니다.

세 번째, 비용입니다. 세 도구를 모두 구독하면 월 $50 이상입니다. 팀 규모가 있다면 꽤 큰 비용이 될 수 있어서, 팀 내에서 어떤 도구를 표준으로 쓸지 합의하는 과정이 필요했습니다.

마무리

반년 전에는 "어떤 도구가 가장 좋은가?"를 찾으려 했습니다. 지금은 "어떤 작업에 어떤 도구를 꺼내야 하는가?"로 질문이 바뀌었습니다.

AI 코딩 도구가 코드를 대신 써주는 시대가 됐다고 해서, 개발자의 판단이 덜 중요해진 것은 아니었습니다. 오히려 생성된 코드를 읽고, 맥락에 맞는지 판단하고, 필요하면 거절하는 능력이 더 중요해졌다고 느꼈습니다.

결국 AI 도구는 "더 잘 아는 개발자에게 더 많이 돌려주는" 도구였습니다. 기본기가 탄탄할수록 도구의 제안을 더 정확하게 평가할 수 있고, 더 좋은 프롬프트를 쓸 수 있고, 결과적으로 더 많은 시간을 아낄 수 있었습니다.

이 도구들이 1년 뒤에 어떻게 변해 있을지는 모르겠지만, "도구가 만들어준 코드를 온전히 책임지는 건 결국 나"라는 점은 변하지 않을 것 같습니다.