커서/코드래빗 개발팀이 말하는 AI 코딩 도구 잘 쓰는 법

AI가 프로그래밍의 모든 영역에 스며들고 있습니다. 소프트웨어 개발에 필요한 모든 과정이 AI 중심으로 바뀌고 있죠. 이런 변화를 이끄는 건 바로 “AI 코딩 도구”입니다.

대표적인 예시는 ‘커서(Cursor)’입니다. 짧은 기간 안에 3억 달러가 넘는 매출을 올리며, 미친듯이 성장하고 있습니다. 현재 수백만 명 이상의 개발자가 커서를 사용 중이고요. 처음에는 탭(Tab) 키를 눌러 코드를 자동으로 완성하거나, 이어질 내용을 예측해주는 단순한 기능으로 출발했지만, 이제는 프로그래밍 과정 전체를 아우르는 강력한 도구로 발전했습니다.

또 다른 도구로는 ‘코드래빗(CodeRabbit)’이 있습니다. 코드 배포 과정에서 발생하는 다양한 문제를 효과적으로 해결하는 AI 기반 도구입니다. 단순히 코드를 작성하는 수준을 넘어, 코드 리뷰 과정에서 필요한 속도와 정확성, 그리고 판단력을 가졌죠. 그 결과, 단 1년 만에 5,000개 이상의 고객사와 7만 개 이상의 오픈소스 프로젝트에 쓰이며 그 가치를 증명하고 있습니다.

이 코딩 도구들은 어떻게 고객의 문제에 접근했고, 어떤 기술로 어려움을 극복했을까요? 우리가 AI 코딩 도구를 쓸 때는 무엇을 고려해야 할까요? 커서와 코드래빗의 이야기를 재구성했습니다.

커서 개발자 대담 How Cursor is building the future of AI coding with Claude

코드래빗 개발기 CodeRabbit improves code review accuracy with OpenAI o3, o4-mini, and GPT-4.1

“개발 병목을 해결해 주세요”

처음에 AI 코딩 도구가 풀어야 할 문제는 단순했습니다. 개발할 때 생기는 비효율과 병목을 없애는 거였죠. 어제와 오늘이 또 다른 LLM의 발전이 이들의 발전을 뒷받침했습니다.

커서가 이토록 빠르게 성장한 방법

커서는 언어 모델을 프로그래밍에 접목한 첫 회사입니다. 특히 탭(Tab) 키를 이용한 자동 완성 기능이나 단일 파일 내에서의 간단한 코드 편집 기능으로 빠르게 인기를 얻었죠.

특히 전환점은 클로드 3.5 소넷 같은 고성능 모델을 도입하며, 다중 줄 편집(Multi-line Edit) 기능을 선보인 순간이었습니다. 그 덕분에 ‘단계 함수’와 같은 작업에 뚜렷한 개선 효과를 보였죠. 이후 꾸준히 더 좋은 모델을 적용하고 내부적으로 최적화하며 더 효율적인 AI 도구로 발전했습니다.

무엇보다 커서 개발자들은 커서를 활용해 커서를 개발하기에 무척 빠르게 성장할 수 있었습니다. 빠르게 기능을 추가해 보고 직접 써보며 효과가 없는 기능은 과감히 제거하는 방식이죠. 이를 “자기 개선적 피드백 루프”라고 부른다고 합니다.

“우리가 새로운 기능을 빨리 만들고, 잘 안 되는 기능은 빨리 없앨 수 있는 이유가 바로 여기에 있습니다. 우리 스스로 그 기능이 진짜로 유용한지 솔직하게 판단할 수 있기 때문이죠. 굳이 사용자에게 배포한 다음 사람들이 어떻게 사용하는지 지켜본 뒤에야 기능 개선 여부를 결정하는 방식이 필요 없어요. 덕분에 기능 개발의 반복 주기도 훨씬 빨라졌다고 생각합니다.” 커서 CTO 아만 상거(Aman Sanger)

코드래빗은 기회를 어떻게 찾아냈을까?

코드래빗의 창업자들 역시 개발하며 스스로 느낀 문제에서 출발했습니다. 느리고 수동적인 코드 리뷰 과정에서 오는 고통을 직접 느낀 거죠. 무엇보다 AI가 코드 작성은 더 쉽게 만들었다 해도, 여전히 코드를 배포하는 것이 발목을 잡았습니다.

“백만 줄의 코드를 생성해도, 검토 프로세스가 1,000줄만 지원한다면 그만큼만 내보낼 수 있습니다.” 코드래빗 선임 제품 매니저 사힐 M. 반살(Sahil M. Bansal)

그래서 그들은 코드 검토에 필요한 AI 도구를 만들기에 지금이 가장 적합한 시기라 생각했다고 합니다. AI 코드를 그대로 쓰기에 위험도는 가장 높고 컨텍스트가 가장 복잡할 때니까요. 따라서 코드래빗 팀은 코드 생성이 아닌 코드 리뷰에 AI를 적용하여 속도와 정확성, 그리고 지능을 확보하는 데 집중했습니다.

AI 코딩 도구 잘 쓰는 법

그렇게 두 회사 모두 최신 AI 모델을 활용하고 내부적인 피드백 과정을 거치며 도구의 역량을 키웠습니다. 이제 AI 도구는 다양한 기능과 선택지를 가지고 있죠. 그리고 그 기능을 최대한도로 뽑아내는 것이 ‘개발자의 역량’으로도 바뀌고 있습니다.

커서 개발자가 말하는 커서 잘 쓰는 법

커서는 개발 과정에서 특히 이런 일들을 잘 지원하는 도구로 성장했습니다.

• 문제 해결/편집: 특정 버그를 수정하거나 세부적인 편집이 필요할 때는 ‘사고 모델’이나 ‘탭’ 기능을 활용합니다.
• 코드베이스 탐색: 낯선 코드베이스에서 작업할 때는 ‘QA 기능’과 ‘검색’을 주로 씁니다. 클로드 3.5 같은 고급 모델은 코드베이스 조사와 분석 능력이 뛰어납니다.
• 초기 코드 설정: ‘에이전트 기능’은 초기 코드베이스를 설정하거나 새로운 기능 개발을 시작할 때 매우 유용합니다.

특히 아래 커맨드, 기능은 필요한 때에 맞춰 쓸 때 가장 효율적이라고 합니다.

• 탭(Tab): 개발자가 직접 주도권을 가지고 자신이 무엇을 해야 하는지 명확히 알 때 가장 유용합니다.
• Command+K: 특정 코드 영역이나 전체 파일의 편집을 빠르게 수행할 때 활용합니다.
• 에이전트(Agent): 여러 파일을 동시에 다룰 때 좋습니다.
• 백그라운드 에이전트(Background Agent): 전체 PR을 처리할 때 유용한 기능입니다. 개발자가 동시에 여러 작업을 진행하면서, 필요에 따라 전경과 배경 모드를 오갈 수 있게 해줍니다.

코드래빗이 리뷰에 AI 도구를 적용하는 방법

코드래빗은 LLM을 기반으로 하는 다단계 리뷰 시스템을 구축했습니다. AI가 코드 리뷰를 진행하는 과정은 아래 3가지 단계로 이뤄집니다.

• 샌드박스 환경: 개발자가 PR을 제출하면, 코드래빗은 저장소를 샌드박스 환경으로 복제합니다.
• 맥락 강화: 곧 코드 이력, 린터, 코드 그래프 분석, 이슈 티켓, 개발자 대화 등으로부터 추가 맥락을 추출하여 차이점을 강화합니다.
• 다중 모델 분석: 이제 맥락을 바탕으로 여러 모델을 조합해 분석을 실행합니다. 이를테면 추론 모델(o3, o4-mini 등)은 다중 줄 버그, 코드 리팩터링, 파일 간 아키텍처 문제와 같은 작업을 수행하고, 범용 모델(GPT-4.1 등)로는 컨텍스트 창이 커야 하는 리뷰 요약, 독스트링 생성, 일상적인 QA 검사를 수행합니다.

즉, 코드래빗은 마치 ‘워크플로우에 내장된 시니어 엔지니어’처럼 움직입니다. 단순히 코드를 검토하는 AI가 아닌 거죠. 코드 베이스, 팀의 습관, 그리고 표준을 이해하는 시스템과 실제 문제를 포착할 수 있는 추론 깊이를 가진 모델이 함께 움직여야 합니다. 또한 VS 코드 같은 코드 에디터에서 개발자가 실시간으로 리뷰를 받도록 만드는 것도 중요합니다. 코딩 중이든, 커밋이 합쳐질 때든, 어느 환경에서나 리뷰가 이뤄지는 유연성이 필요하니까요.

AI 코딩 도구가 가지는 문제들

AI 코딩 도구는 엄청나게 발전했지만, 여전히 풀리지 않는 문제도 있습니다. 커서와 코드래빗이 가지고 있는 문제를 역으로 살펴보면, 지금 우리가 조심해야 하는 부분 역시 보일 겁니다.

코드 검증의 복잡성

AI가 코드를 생성하는 능력이 향상되면서, 이제 병목은 코드 작성에서 코드 검토로 이동하고 있습니다. 개발자들이 코드 작성에 70%, 검토에 30%를 보낸다고 가정할 때, 코드 작성을 완전히 해결해도 소프트웨어 엔지니어링 속도는 최대 3배밖에 빨라지지 않습니다.

따라서 AI 코딩 도구의 과제는 사람들이 코드를 더 쉽게 검토하고, 에이전트 변경 사항이 정확하다고 확신할 수 있도록 만드는 것입니다. 그래서 코딩 도구 개발팀은 크게 아래 내용을 신경 쓴다고 합니다.

• “정확성”의 모호함: 에이전트가 만든 변경이 단지 명세에 따라 “정확”한 것을 넘어, 개발자가 생각했던 것과 일치하는지 확인하는 과정이 중요합니다.
• 다른 코드 표현: 코드베이스의 변경 사항을 의사코드와 같은 간결한 방식으로 표현하여 검증 시간을 크게 단축하려는 아이디어도 있습니다.
• “감각 코딩”과 현실: 단순한 “감각 코딩”은 소프트웨어를 직접 실행해보며 쉽게 검증할 수 있지만, 실제 프로덕션 코드베이스에서는 훨씬 어렵습니다.

대규모 코드베이스의 난제

LLM은 AI가 ‘맥락’을 이해하는 과정에서 등장했습니다. 엄청 좋아졌지만, 여전히 아주 긴 맥락은 어려워 합니다. 그렇기에 대규모 코드베이스에서 AI 모델을 효과적으로 활용하는 것 또한 여전히 문제입니다.

• 테스트 실행 환경 설정: 모델이 테스트를 실행할 수 있도록 종속성을 올바르게 설정하는 것이 복잡합니다. 그래서 커서의 백그라운드 에이전트는 이를 간소화하고 반복하도록 만드는 방법을 모색하고 있습니다.
• 내부 도메인 특화 언어와 분산된 코드: 대규모 코드베이스는 자체 언어처럼 보이는 DSL이나 수백만 개의 파일에 걸쳐 분산된 코드를 포함하기도 합니다. 이런 경우에는 모델이 전체를 이해하기 어렵다고 하죠.
• 맥락 검색의 한계: 검색 모델을 훈련하고 다른 맥락을 통합했지만, 모델이 코드베이스를 진정으로 이해하기에는 여전히 충분하지 않습니다.
• “기억”의 한계: 모델이 사용자 경험으로 학습하는 "기억" 중심 접근 방식은 성능 향상에 작은 도움을 주지만, 대규모 코드베이스에서 탁월한 결과를 내기에는 여전히 부족합니다.
• “올바른 방식”으로 코딩하기: 단순히 테스트를 통과하는 것을 넘어, 기존 코드와 일치시키고 올바른 구조와 가이드라인을 따르는 것이 중요합니다. 예를 들어, 코드를 디바운스할 때 자체 함수를 새로 만드는 대신 코드베이스에 이미 존재하는 적절한 디바운스 함수를 사용하는 방법을 아는 것이 필요하다는 겁니다.
• 조직 지식의 중요성: 슬랙 메시지와 같이 코드베이스 외부에 존재하는 조직의 지식 또한 의사결정에 큰 영향을 미칠 수 있습니다. 현재는 큰 병목이 아니지만, 모델이 코드베이스 지식에 완벽해지면 조직 안의 사람들만 이해하는 지식이 다음 병목이 될 것입니다.

AI 코딩 도구는 개발을 어떻게 바꿔버릴까?

물론 이런 어려움에도 AI 코딩 도구는 계속 진화할 겁니다. 문제를 알고 있다는 것은, 곧 그 문제를 풀어낼 방법을 찾고 있다는 말이니까요. 그렇게 코드 작성 방식과 개발자의 역할, 그리고 소프트웨어 개발의 전반적인 환경도 달라질 겁니다. 이러한 상황을 가장 많이 상상하는 사람들은 미래를 어떻게 보고 있을까요?

AI가 더 잘 알아듣는 코드로 작성하기

“깨끗한 코드를 작성하려고 할 때, 반복을 피하고, 불필요하게 복잡하게 만들지 않으려 합니다. 그리고 그것은 사람만큼이나 모델에게도 중요합니다” 커서 리서처 루카스 뮐러(Lukas Möller)

이제 코드를 만들 때는 ‘AI 모델이 더 잘 읽고 이해할 수 있도록’ 신경써야 할지도 모릅니다.

우선 커서의 API 디자인은 LLM이 더 쉽게 쓰도록 조정되고 있습니다. 이를테면, 모델이 새로운 버전의 소프트웨어를 쉽게 인식하도록 버전 번호를 표시하는 방식이죠. 또한, LLM이 코드베이스를 더 잘 다룰 수 있도록 상호작용 수준을 줄이는 방식으로 코드를 구조화할 수 있습니다.

AI가 더 많은 코드를 쉽게 작성할 수 있게 되면서, “코드의 취향”과 깔끔한 솔루션을 구조화하는 능력이 더욱 중요해질 것입니다. 하지만 물론 사람과 모델 모두에게 읽히는 ‘깨끗한 코드’가 핵심이라는 원칙은 크게 다르지 않습니다.

새로 ‘개발자’의 영역에 접근하는 사람들

“저는 훨씬 더 많은 사람이 자신만의 소프트웨어를 만들게 될 것이라고 생각합니다. 물론, 소프트웨어로 하고 싶은 독특한 것이 있는지 여부가 병목으로 동작하겠지만요.” 커서 CTO 아만 상거(Aman Sanger)

과거에는 소프트웨어를 구축하지 않았던 사람들이 스스로 대시보드 같은 도구를 구축할 수 있습니다. 코드베이스나 제품에 직접 관여하지 않는 커뮤니케이션 팀 직원이 버그 수정을 제출할 수도 있고요. 그러다 보면 사용자의 상호작용에 따라 소프트웨어가 스스로 바뀌며, 개인의 필요에 맞게 조정되는 미래도 상상할 수 있습니다.

특히 AI는 교육에 매우 유용한 도구가 될 수 있죠. 특정 개념에 대한 질문이나 설명이 필요할 때 AI를 활용하면, 아주 빠르고도 정확하게 학습할 수 있습니다.

개발자의 역할은 어떻게 달라질까?

“품질은 빠르게 반복하고, 실수를 저지르고, 특정 요소가 왜 실패하는지 파악하는 것에서 크게 나온다고 생각합니다. 그리고 저는 모델이 이러한 반복 과정을 엄청나게 가속화하여, 이를 통해 무엇이 효과가 있고 무엇이 효과가 없는지를 더 빨리 배우게 할 수 있다고 생각합니다” 커서 CTO 아만 상거(Aman Sanger)

그러나 여전히 제품의 모든 것을 이해하며 깊이 파고들 수 있는 엔지니어는 필요할 것입니다. 다만 세부 사항을 거의 모른 상태로, 고객 수준에서만 작업하는 엔지니어가 생겨날 수 있습니다. 즉, UX 취향과 같이 인터랙션을 구상하고 설명하는 일에 엔지니어들이 가까워지는 거죠.

커서를 구성하는 코드의 90% 이상은 이미 AI가 만든 코드라고 합니다. 수동으로 입력한다 해도 탭 완성 같은 기능이 대부분의 변경을 처리하고요. 그럴수록 개발자의 역할은 코드의 필요성을 이해하고, “취향”을 가지고 소프트웨어 개발을 안내하는 방식으로 진화할 겁니다.

마치며

AI 코딩 도구는 소프트웨어 개발의 패러다임을 근본적으로 바꾸고 있습니다. 커서와 코드래빗의 이야기에서 볼 수 있듯, 개발자의 생산성을 놀라울 정도로 올려주면서 동시에 코드 품질 향상, 빠른 반복 주기, 그리고 소프트웨어 개발의 접근성 확대를 제공합니다.

AI가 거의 모든 코드 작성에 관여하는 미래에, 인간 개발자의 역할은 코드의 본질적인 “취향”과 비즈니스 목표를 이해하고 안내하는 방향에서 더욱 중요해질 것입니다. AI 코딩 도구 활용 능력도 결국은 올바른 ‘방향성’을 제시할 수 있느냐에 달려 있습니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.