특히 커서의 Tab 자동완성 기능을 인상 깊게 사용했는데요. 제가 작성하려던 코드의 흐름을 자연스럽게 이어주기도 하고, 때로는 미처 생각하지 못한 로직이나 수정이 필요한 지점을 먼저 짚어주기도 했습니다. 커서가 해당 라인으로 이동해 Tab 입력을 기다리고 있을 때면, 매번 감탄하며 즐겁게 코딩하곤 했습니다. 그런 점에서 저에게 커서는 단순한 개발 도구가 아니었습니다. 개발 멘토이자 동반자였고, 저보다 한발 먼저 코드를 읽고 길을 알려주는 선지자(Fast Mover)같은 존재였습니다.

이처럼 기대와 믿음을 주던 커서가 이번에 커서 3를 출시했습니다. 개인적으로는 커서가 다른 도구와 무엇으로 경쟁할지, 어떤 차별점을 내세울지 궁금했습니다. 그래서 2주가량 클로드 코드를 잠시 내려놓고, 커서 3만 사용해 사이드 프로젝트를 구현해 보았습니다.

테스트 조건은 다음과 같습니다.

클로드 코드와 달리 별도의 세부 설정은 하지 않았고, 커서 자체가 기본으로 제공하는 기능만 사용했습니다.
최근 AI 구독 비용이 빠르게 오르고 있어, 커서는 여전히 애정하지만 현재는 20달러 요금제를 사용하고 있습니다.

커서 3의 새로운 기능

이번 메인은 바로 Agent Window입니다. 기존 IDE에서 벗어나, Agent만을 위한 새로운 인터페이스를 만들었다는 의미로 보입니다.

1) 전반적으로 깔끔한 UI

개발자는 개인 성향에 따라 CLI(Command-Line Interface) 혹은 GUI(Graphical User Interface)를 선호합니다. 특히 젊은 연차이거나 프론트엔드에 가까울수록, 따로 명령어를 배워야 하는 CLI보다 단순하고 직관적인 GUI를 좋아한다고 생각합니다.

그런 기준에서 클로드 코드의 터미널 사용 경험은 저에게 상당히 거칠게 느껴졌습니다.

물론 클로드 코드 앱이나 다른 플러그인을 붙인다면 얘기가 달라질 수 있지만, 우선 가장 근본이 되는 기본 설정을 기준으로 비교하고자 합니다.

위 이미지를 보면 UI가 깔끔하다는 말이 절로 나옵니다. 전반적으로 무난하면서도 부드럽고 정돈된 UI입니다. 다만 제가 확인한 바로는 아직 3개의 테마만 지원하고 있습니다. VS Code의 테마를 그대로 가져와 다양한 테마를 사용할 수 있을 거라 기대했는데, 이 부분은 조금 아쉬웠습니다.

그리고 마지막으로, IDE 모드에서 생성한 대화는 Agent Window 모드에서도 확인이 가능합니다. 하지만 반대로 Agent Window에서 시작한 대화는 IDE 모드에서는 노출되지 않습니다.

2) 페어프로그래밍 인터페이스의 초안

지난 글 ‘코드는 줄고 판단은 남았다: AI 시대 개발자의 일일일’에서 40년차 빅테크 개발자 분은 AI와 함께 페어 프로그래밍을 하고 있다고 말하며, 페어 프로그래밍의 중요성을 강조했습니다. 저 역시 그 의견에 매우 공감했는데요. 한 달 뒤 커서 3에서 비슷한 느낌의 인터페이스가 등장했습니다.

아직은 페어 프로그래밍이라고 하기엔 간단한 Diff만 보여주는 UI에 가깝지만, 저는 개인적으로 근시일 내에 해당 인터페이스에서 Agent Review가 적절한 단위로 수행될 것이라고 생각합니다. AI가 엄청나게 많은 코드를 쏟아내는 만큼, 특정 라인의 코드 변경 사항에 대해 AI가 짧게나마 리뷰해 준다면, 전체 변경 사항을 이해하지 않더라도 해당 라인만 작은 PR Review를 하는 느낌을 줄 수 있기 때문입니다.

게다가 커서가 내세우는 장점 중 하나인 “우리 모델은 빠르고 코딩에 특화되어 있다”라는 점은, 곧 코드 리뷰도 꽤 잘해줄 것이라는 의미와도 통한다고 봅니다. 그래서 저는 개인적으로 커서의 자동완성 Tab에 이은 새로운 매력적인 기능이 바로 여기에 있지 않을까 하고, 혼자만의 상상을 해보았습니다.

3) 커서의 타일형 레이아웃

커서에서 ‘타일형 레이아웃’이라고 부르는 이 기능은, IDE에서 기본적으로 제공하는 창 분할 기능입니다.

전통적인 IDE의 창 분할 기능을 기본으로 제공해, 에이전트를 위한 인터페이스이면서도 아직 IDE의 모습을 유지하고 있다는 점이 좋았습니다. 게다가 저는 클로드 코드나 Agent Window를 사용할 때 모니터 하나를 전부 할당해 쓰고 있습니다.

그리고 기존에 클로드 코드와 cmux 조합을 사용하던 저에게는 익숙하면서도, 당연히 있어야 하는 기능처럼 느껴졌습니다.

커서 3 실제 사용기

그럼 이제 직접 사용해 보면서 디테일한 부분을 체크해 보겠습니다. 이번 글을 위해 “SEO에 대해 무작정 개선 포인트를 찾아서 수정하라”는 명령을 던져보았습니다.

이전 IDE 모드와 비교하면 대화와 결과가 확연히 달라졌습니다. 전보다 플랜 모드에서 각자의 역할이 더 선명해 보였고, 플랜 모드의 결과물은 “Plans > 결과물”로 표시되어 어떤 프로젝트에서 작성된 문서인지 바로 확인할 수 있었습니다. 이전에는 플랜 모드를 여러 개 돌려놓으면 직관적으로 보기 어려웠는데, 이런 부분이 개선되어 좋았습니다.

그다음으로 눈에 띈 점은 현재 진행 중인 채팅들의 결과입니다. 많은 개발자가 불편함을 느끼는 부분은 바로 채팅 결과가 어떻게 진행되고 있는지 추적할 방법이 없다는 점입니다. 커서팀에서도 이 부분을 염두에 두었는지, 완료된 대화, 처리 중인 대화, 혹은 워크트리로 분기된 대화, push까지 된 대화까지 한눈에 보고 알 수 있도록 개선되었습니다.

그다음으로는 커밋과 푸시하기가 매우 편해졌다는 점입니다. 일반적으로 큰 작업이 아닌 이상, 현재 작업을 위해 하위 브랜치를 만들거나 워크트리를 생성하기에는 애매합니다.

그래서 특정 기능을 위한 채팅을 병렬로 돌리게 되면, 커밋 단위로 구분이 필요한 경우가 종종 생깁니다. 저는 이 번거로움 때문에 “/grouped-commits”라는 skills를 만들어 관리했었습니다.

그렇지만 이제는 코드 수정이 마무리되면, 해당 대화에서 수정된 파일들만 따로 커밋하고 푸시할 수 있도록 별도의 UI가 제공됩니다.

커서 3 vs 클로드 코드

커서 3에 특별한 것은 없었다

2주가량 커서 3를 사용해 본 감상은 “특별한 것은 없다”라고 말할 수 있습니다. 위에서 말한 내용을 보면 기존에 불편함이 있었고, 이를 다른 방식으로 해결해 왔는데, 커서에서도 이를 이렇게 해결했다는 식으로 논리가 전개되고 있습니다.

그렇습니다. 이번 커서 3에는 딱히 특별한 것이 없습니다. 기존의 날것들이 다양한 방식으로 진화를 거듭하는 와중에, 저 멀리서 “내가 정통이오!” 하며 정리한 느낌이 강했습니다. 즉, 개성은 사라지고 기능 그 자체만 남게 된 셈입니다.

다만 그게 전부라면 질문의 답은 하나로 수렴합니다.

“커서 3 계속 사용할래?”

“커서 3를 위해 플랜 업그레이드할래?”

저는 이 두 가지 질문에 No라고 답하겠습니다. 또 이미 현업에서는 모든 에이전트가 클로드 코드 기준으로 돌아가고 있습니다. 공유되는 문서와 사용법, 심지어 팁까지 클로드 코드를 중심이라, 굳이 커서로 옮겨야 하나 싶은 생각이 듭니다.

제 기준에 맞춰 간단히 커서와 클로드 코드의 여러 가지 특성을 비교해 보았습니다. 무승부 1, 승리 3, 패배 3으로 최종 결과는 무승부처럼 보이지만, 실제로 커서가 승리한 3가지는 개인적인 선호도 차이에서 비롯된 것입니다. 반면, 실질적인 코딩 능력을 결정하는 확장성, 대중성, 협업 용이성 등에서는 클로드 코드가 압도적으로 우위에 있습니다.

그렇다면 코딩을 처음 하는 입장에서도 커서가 좋을까요? 이미 시중에는 바이브 코딩 툴(Lovable, Base44) 등이 강력하게 자리 잡고 있습니다. 따라서 현재 커서는 상당히 애매한 위치에 있습니다. IDE와 조화롭게 동작한다는 점을 제외하면 더더욱 그렇습니다. 이런 압도적인 차이와 함께, 현재 커서의 위치는 VS Code, Windsurf처럼 IDE에 가깝습니다. 물론 커서 입장에서는 위기감을 느끼고, 클로드 코드와 같은 레벨로 도약을 꿈꾸는 방향성도 이해합니다.

하지만 클로드 코드, 코덱스 앱 등이 범람하고 있는 에이전트판에서 커서의 영향력이 얼마나 될지는 모르겠습니다. 오히려 다른 서비스들이 IDE에서 벗어나는 스탠스를 취하고 있는 이 시기에, IDE 본연의 기능에 더 집중했으면 어땠을까라는 생각도 들었습니다.

해커뉴스나, 제 주위만 봐도 커서 20달러 플랜과 클로드 코드 200달러 플랜 조합을 쓰는 경우가 많습니다. 저 또한 그렇습니다. 특히 해커뉴스의 반응은 사뭇 공격적입니다. 커서를 쓰는 이유는 IDE스러움에 있는데, 이번 업데이트는 원하지 않는 방향으로 나아간다는 겁니다. 개발자들이 커서를 쓰는 이유는 IDE스러움과 바이브 코딩이 아니라, 실제로 코딩하고 싶은 욕구에 있다고 말합니다.

마치며

우리가 커서를 쓰는 이유는 에이전트 때문이 아닙니다. 그냥 커서가 개발하기 편하기 때문입니다. 이미 에이전트는 클로드 코드와 다른 툴을 병행해서 쓰고 있습니다. 우리가 느끼는 불편함이 에이전트 그 자체에 있지 않다는 말입니다.

ChatGPT와 코딩하기 위해 전체 코드를 복사하고 붙여넣으며 불편함을 느꼈고, 커서는 그 불편함을 VS Code 포크라는 방식으로 멋지게 풀어냈습니다. 다시 “바이브 코딩”으로 불편함이 커지는 지금, 커서의 다음 해결책은 무엇인지 궁금해지는데요. 적어도 지금처럼 Fast Follower 같은 기능은 아니면 좋겠습니다.

그리고 이 글을 쓰고 난 뒤, 우주 탐사 기업 스페이스X가 커서와 전략적 파트너십을 맺었다는 소식을 접했는데요. 계약에는 연말까지 커서를 인수할 수 있는 옵션까지 포함됐다고 합니다. 아직은 이르지만, 커서가 스페이스X를 만나 또 어떤 방향으로 진화할지는 지켜봐야 할 것 같습니다.