핵심 요약

  • Cursor 창업팀은 AI 모델의 발전이 코드 작성뿐 아니라 편집기 자체를 바꿀 것이라고 보고 VS Code를 기반으로 독립 편집기를 만들었다.
  • Cursor Tab은 커서 뒤의 문장만 완성하는 데서 나아가 다음 코드 변경과 이동할 위치를 예측하려 한다.
  • AI가 더 큰 변경을 제안할수록 사람이 변경 내용을 이해하고 오류를 찾아내도록 돕는 화면이 중요해진다.
  • 팀은 자율 에이전트가 명확히 정의된 작업에 유용할 수 있다고 보지만, 요구사항을 만들면서 고쳐 나가는 작업에는 빠른 피드백이 필요하다고 본다.

확장 기능 대신 편집기를 만든 이유

Cursor는 VS Code를 기반으로 한 AI 코딩 편집기다. 창업팀의 마이클 트루엘은 초기 GitHub Copilot을 사용하면서 AI가 프로그래밍에 실질적인 도움을 줄 수 있다고 느꼈다고 설명했다. 이후 GPT-4 초기 버전을 접하며 AI가 특정 작업만 돕는 수준을 넘어 소프트웨어를 만드는 방식 전반에 영향을 줄 것이라고 판단했다.

그는 기존 편집기의 확장 기능으로는 편집 경험을 바꿀 수 있는 범위에 한계가 있다고 봤다. 팀은 모델이 제안하는 내용과 개발자가 이를 받아들이는 방식을 함께 설계하기 위해 독립 편집기를 택했다. 아르비드 룬네마르크는 사용자 화면, 모델에 제공하는 지시와 맥락, 모델 자체를 같은 팀에서 다루는 점을 Cursor의 개발 방식으로 설명했다.

자동 완성에서 다음 행동 예측으로

Cursor Tab의 목표는 현재 위치에 이어질 코드 몇 줄을 채우는 데 그치지 않는다. 팀은 개발자가 다음에 수정할 부분과 이동할 위치까지 예측하려 한다. 수알레 아시프는 한 변경을 수락한 뒤 같은 파일의 다른 위치로 이동해 다음 변경을 제안하는 경험을 예로 들었다. 다른 파일로의 이동이나 터미널 명령 제안은 대담에서 앞으로 확장하고 싶은 방향으로 언급됐다.

이 기능은 이미 표현된 의도에 따라 예측할 수 있는 작업을 줄인다는 생각에 기반한다. 다만 개발자가 탭을 누르기만 하는 것은 아니다. 제안을 거절하거나 문자를 더 입력하는 행동도 원하는 결과를 전달한다.

응답 속도도 중요하다. 아만 생거는 Tab처럼 긴 코드 맥락을 읽고 짧은 결과를 내는 작업에 맞춰 작은 모델을 훈련한다고 설명했다. 같은 내용을 매번 다시 계산하지 않도록 이전 요청의 계산 결과를 재사용하고, 사용자가 제안을 수락했을 때의 다음 결과를 미리 준비하는 방법도 소개했다.

코드 생성이 늘수록 검토가 어려워진다

Cursor는 AI가 제안한 수정 전후를 보여주는 차이 화면을 사용한다. 아시프에 따르면 짧은 자동 완성에 적합한 표시 방식과 큰 코드 변경을 검토하는 방식은 달라야 한다. 팀은 삭제할 코드에 취소선을 긋거나, 제안이 있는 위치만 표시하는 방식 등을 시험했지만 산만하거나 직관적이지 않은 문제가 있었다고 설명했다.

룬네마르크는 여러 파일에 걸친 큰 변경에서는 차이 화면을 읽는 일 자체가 부담이 된다고 지적했다. 중요한 변경을 강조하거나 오류 가능성이 있는 부분을 표시하고, 이해하기 쉬운 순서로 파일을 안내하는 방안을 제시했다. 이는 대담에서 제시한 개선 아이디어이며, 모든 변경을 자동으로 검증하는 기능이 완성됐다는 뜻은 아니다.

에이전트가 맡을 일과 빠른 반복이 필요한 일

팀은 자율적으로 파일을 찾고 코드를 수정하는 AI 에이전트에 가능성이 있다고 본다. 룬네마르크는 채팅 입력창에서 복사와 붙여넣기가 간헐적으로 작동하지 않는 것처럼 문제가 명확한 경우를 예로 들었다. 에이전트가 오류를 재현하고 수정한 뒤 결과를 검증해 사람이 나중에 살펴보는 방식이다. 그는 당시 많은 작업에서 에이전트가 아직 충분히 유용하지 않으며, 이런 작업 방식도 바라는 모습으로 설명했다.

반면 개발 과정에서는 첫 결과를 본 뒤에야 원하는 바가 분명해지는 일이 많다고 했다. 이런 작업은 요청을 한 번 전달하고 오래 기다리는 방식보다 초기 결과를 빠르게 받아 계속 수정하는 방식에 맞는다. 룬네마르크는 말로 설명하는 것보다 코드 예시를 직접 작성하거나 화면의 요소를 옮겨 보여주는 편이 의도를 더 잘 전달할 때도 있다고 덧붙였다.

코드 맥락과 오류 검출의 한계

AI에 코드베이스 전체를 무조건 넣는 것도 해법은 아니다. 트루엘은 맥락이 많아질수록 요청이 느리고 비싸지며, 일부 모델은 관련 없는 정보에 혼란을 겪는다고 설명했다. 따라서 현재 작업에 필요한 코드를 찾아 제공하는 정확도가 중요하다. 팀은 관련 파일을 제안하는 기능을 실험 중이라고 했지만, 당시 버전은 초기 단계라고 밝혔다.

오류 검출 역시 남은 과제다. 생거는 모델에 막연히 버그를 찾으라고 하면 결과가 부정확하다고 평가했다. 트루엘은 AI가 더 많은 코드를 작성하려면 생성한 코드를 확인하는 능력도 함께 좋아져야 한다고 말했다. 팀이 언급한 방법에는 기존 코드에 인위적으로 오류를 넣어 탐지 모델을 훈련하거나, 실제 실행 결과와 디버거 정보를 모델에 제공하는 방안이 있다.

규모가 커지며 드러난 운영 문제

코드베이스에서 관련 부분을 찾는 기능은 서비스 규모가 커지면서 운영 과제가 됐다. 아시프는 코드를 나눠 임베딩이라는 검색용 수치 표현을 만들고, 서버에는 코드 원문 대신 그 표현을 저장한다고 설명했다. 로컬 파일과 서버의 색인 상태를 맞출 때는 파일과 폴더의 해시를 계층적으로 비교해, 차이가 있는 부분만 더 살펴보는 방식을 쓴다. 생거는 같은 회사의 개발자들이 공유하는 코드에 대해 임베딩을 반복 계산하지 않도록 결과를 재사용한다고 덧붙였다.

팀이 설명한 미래상에서도 사람의 역할은 남는다. 트루엘은 소프트웨어 개발에 명세를 구현하는 일만 있는 것이 아니라 속도와 비용 등을 둘러싼 작은 설계 결정이 계속 따른다고 봤다. AI가 반복적인 편집을 줄이더라도, 무엇을 만들고 어떤 변경을 받아들일지는 개발자가 판단하는 방식이 팀의 지향점이다.