본문 바로가기
풀스택 개발이야기

Windsurf와 Cursor, 두 달 써 보고 남은 것 — 이름이 바뀌어도 옮겨 가는 습관 넷

by junetapa 2026. 9. 14.
반응형

책상 위에 나란히 켜 둔 노트북 두 대, AI 코딩 도구를 번갈아 쓰는 자리

AI 코딩 도구 두 개를 두 달 동안 번갈아 썼다. 여러 파일에 걸친 리팩토링은 Windsurf의 에이전트에 맡기고, 스크립트 하나를 빨리 짜야 할 때는 Cursor를 열었다. 둘을 항목별로 견준 표와 요금은 원문에 따로 정리했고, 이 글에는 그 표에 들어가지 않는 이야기를 적는다.

그 두 달 사이에 한쪽 도구의 이름이 바뀌었다. Windsurf가 2026년 6월 업데이트로 Devin Desktop이 된 것이다. 앱을 열면 보이는 첫 화면이 달라졌고 기본 에이전트도 새것으로 교체됐다. 기능표를 처음부터 다시 읽어야 하나 싶었는데, 돌아보니 손에 남아 있던 것은 표가 아니었다.

도구의 이름과 기본 에이전트, 요금 체계가 한꺼번에 움직이는 동안에도 그대로 가져갈 수 있는 것들이 있었다. 대부분 도구의 기능이 아니라 일하는 방식 쪽에 있었다. 개발 도구를 바꿀 때마다 처음부터 다시 익히지 않으려면 무엇을 챙겨야 하는지, 네 가지로 추렸다.

핵심만 먼저
① 이름이 바뀌어도 설정은 따라왔다 — 다만 다음에도 그러리라는 약속은 없다
② 프로젝트 규칙은 도구의 기억 기능보다 저장소 안 파일에 먼저 적는다
③ 맥락을 알아서 찾는 도구를 쓰더라도 관련 파일 두세 개는 내가 먼저 짚는다
④ 명령을 자동으로 돌려도 되는 곳과 막을 곳을 브랜치로 나눈다

이름이 바뀌어도 옮겨 가는 습관 네 가지를 정리한 결론 카드


이름이 바뀐 날, 따라온 것과 바뀐 것

업데이트 뒤 그대로 따라온 설정과 바뀐 첫 화면, 기본 에이전트를 나눈 도해

이 제품의 이름은 이번이 세 번째다. Codeium으로 시작해 Windsurf가 됐고, 2025년 7월 자율 코딩 에이전트 Devin의 개발사인 Cognition이 인수를 발표했다. 그리고 2026년 6월에 제품 이름을 Devin Desktop으로 바꿨다. 기존 사용자에게는 따로 설치할 것 없이 업데이트로 들어왔다.

업데이트 뒤에 확인해 보니 쌓아 둔 것은 그대로였다. 쓰던 요금제, 설정과 확장, 키보드 단축키, 외부 도구를 붙이는 MCP 연결까지 전부 넘어와 있었다. 다시 세팅할 것은 없었다.

항목 업데이트 뒤
요금제 그대로
설정과 확장 그대로
키보드 단축키 그대로
MCP 연결 그대로
첫 화면 편집기 대신 에이전트들을 한데 모아 보는 화면(Agent Command Center)
기본 에이전트 Cascade 자리를 새로 작성된 Devin Local이 넘겨받음

바뀐 것은 두 가지였다. 앱을 열면 로컬과 클라우드에서 도는 에이전트를 모아 보는 화면이 먼저 뜬다. 그리고 오래 써 온 Cascade의 자리를 Devin Local이 넘겨받았다. 새 첫 화면은 여러 에이전트 작업을 칸반처럼 늘어놓고 진행 상황을 보는 판에 가깝다. 손에 익은 자리가 옮겨졌을 뿐, 쌓아 둔 것이 사라지지는 않았다.

노트북 화면에 업데이트 진행 막대가 떠 있는 장면

다행이었지만 이것을 규칙으로 믿기는 어렵다. 인수 한 번에 브랜드와 기본 에이전트, 요금 체계가 함께 움직였다. 다음 변화에서도 설정이 따라온다는 보장은 어디에도 없다. 그래서 이 절에서 남는 것은 «옮길 수 있는 형태로 둔다» 하나다. 두 도구의 요금과 기능을 항목별로 견준 내용은 원문 비교표에 정리해 두었다.

설정이 무사히 넘어온 것은 도구가 약속한 일이 아니라, 이번에는 그렇게 됐다는 기록일 뿐이다

규칙은 도구의 기억보다 파일에 먼저 적는다

같은 규칙 문장을 저장소 원본에서 Memories와 규칙 파일로 옮기는 도해

두 도구 모두 프로젝트 규칙을 기억시키는 자리가 있다. Windsurf 쪽은 Memories 기능이고, Cursor 쪽은 프로젝트 맨 위 폴더에 두는 규칙 파일(.cursorrules)이다. 코딩 규칙이나 구조 설명을 한 번 적어 두면 AI가 코드를 만들 때마다 그것을 참고한다.

문제는 두 도구를 번갈아 쓸 때 생긴다. 규칙을 한쪽에는 대화로 말하고 다른 쪽에는 파일로 적으면, 두 도구가 아는 내용이 시간이 갈수록 조금씩 어긋나기 쉽다. 같은 저장소 안에서 어느 도구가 만들었느냐에 따라 코드의 결이 달라지는 것이다.

이렇게 해 보자
규칙의 원본을 저장소 안 문서 한 장에 적는다(예: docs/ai-rules.md). 그 문장을 Cursor 규칙 파일과 Windsurf Memories에 그대로 붙여 넣는다. 규칙을 고칠 일이 생기면 원본부터 고치고 양쪽에 다시 붙인다. 원본이 저장소에 있으니 커밋 기록으로 언제 무엇이 바뀌었는지도 남는다.

노트에 적어 둔 프로젝트 규칙 목록과 펜

규칙이 길 필요는 없다. 예를 들어 주문 조회 API를 만드는 파이썬 프로젝트라면 이 정도 네 줄로 시작해도 된다. «함수와 변수 이름은 snake_case로 쓴다», «결제사 호출은 payments 폴더 한 곳에만 둔다», «새 기능에는 pytest 테스트를 함께 만든다», «사용자에게 보이는 오류 문장과 로그용 문장을 나눈다».

이렇게 두면 도구가 바뀌어도 규칙은 저장소에 남는다. 이번 업데이트에서 Memories가 그대로 넘어온 것은 반가운 일이었지만, 넘어오지 않았더라도 붙여 넣기 한 번으로 되돌릴 수 있는 상태가 더 안전하다.


맥락은 알아서 찾게 두더라도 내가 먼저 짚는다

파일이 많은 서비스와 스크립트 하나에서 맥락을 넘기는 방식을 견준 도해

두 도구가 가장 크게 갈린 자리는 맥락을 넘기는 방식이었다. Windsurf는 프로젝트를 열면 코드베이스 전체를 색인해 관련 파일을 스스로 참조한다. Cursor는 @ 뒤에 파일 이름을 적어 직접 짚어 줘야 답이 정확해지는 경우가 많았다.

알아서 찾는 쪽 — Windsurf
파일이 수십 개로 나뉜 서비스를 고칠 때 편하다. 대신 작은 작업에서도 «분석 중» 단계를 거쳐 몇 초씩 기다리게 된다.
내가 짚는 쪽 — Cursor
관련 파일 두세 개를 @로 넣어 주면 답이 눈에 띄게 나아진다. 스크립트 하나를 빨리 짤 때는 바로 답해서 앞선다.

그래서 도구와 상관없이 통하는 순서는 하나로 모인다. 요청하기 전에 이 작업에 걸린 파일을 두세 개 먼저 적어 보는 것이다. Cursor에서는 그 목록을 그대로 @로 넣으면 되고, 알아서 찾아 주는 쪽에서는 결과를 검토할 때 그 목록과 대조하면 된다. 앞 절의 주문 조회 API에서 «환불 상태를 응답에 추가해 달라»고 요청한다면, 떠올릴 파일은 라우터와 응답 형식을 정의한 파일, 그리고 그 응답을 확인하는 테스트 세 개 정도다.

서류 폴더 더미에서 관련 파일 두 개를 골라 꺼내는 손

목록이 있으면 검토가 쉬워진다. AI가 손댄 파일이 내가 떠올린 목록 밖에 있다면 그것이 맞는 판단이었는지 한 번 더 볼 이유가 생긴다. 반대로 관련 파일이 하나도 떠오르지 않는 작업이라면, 아직 AI에게 넘길 만큼 일이 정리되지 않았다는 신호로 읽을 수 있다.

자동으로 찾아 주는 기능은 편하지만, 무엇을 찾았어야 했는지 모르는 사람은 그 결과를 검토할 수 없다

자동 실행은 브랜치로 경계를 친다

브랜치마다 명령 자동 실행과 변경 검토 범위를 나눈 표

Windsurf에는 AI가 터미널 명령을 스스로 실행하게 두는 Turbo Mode가 있다. 설치와 테스트, 빌드를 알아서 돌려 주니 편하다. 다만 긴 에이전트 세션에서는 가끔 앱이 멈췄고, Turbo Mode로 명령을 맡겨 둔 동안에는 흔들리는 순간이 더 잦았다. 이 부분은 Cursor 쪽이 비교적 나았다.

불안정함보다 먼저 볼 것은 어디서 실행되느냐다. 같은 명령이라도 실험용 브랜치에서 돌면 되돌리면 그만이지만, 배포로 이어지는 브랜치에서 돌면 이야기가 달라진다. 모든 변경을 하나씩 확인해야 하는 곳이라면, 변경마다 승인하게 되는 Cursor의 검토 방식이 오히려 장점이 된다.

브랜치 명령 자동 실행 변경 검토
개인 실험용 켜 둔다 끝난 뒤 한 번에 본다
기능 개발용 테스트 명령까지만 허용 커밋 전에 바뀐 부분을 확인
메인과 배포용 끈다 변경마다 승인

자동 실행을 막아 두는 안전 덮개 달린 스위치

이 경계를 도구 설정에만 맡기지 않는 것이 요점이다. 도구가 바뀌면 설정 이름과 위치도 바뀐다. 이번에 기본 에이전트가 교체된 것처럼. 대신 «메인 브랜치에서는 명령을 자동으로 돌리지 않는다»를 앞 절의 규칙 문서에 한 줄로 적어 두면, 어느 도구를 쓰든 같은 선이 유지된다. 저장소 쪽에서 메인 브랜치에 직접 올리지 못하게 막아 두면 한 겹 더 단단해진다.

이건 확인하고
자동 실행을 켠 채 긴 작업을 맡겼다면, 끝난 뒤에는 결과 코드보다 실행된 명령 기록을 먼저 본다. 코드만 보고 넘어가면 그 사이에 설치된 패키지나 지워진 파일을 놓치기 쉽다.

자주 묻는 질문

Windsurf를 쓰던 사람은 다시 설정해야 하나?

그럴 필요가 없다. 업데이트로 Devin Desktop이 되면서 요금제와 설정, 확장, 키보드 단축키, MCP 연결이 그대로 옮겨 왔다. 달라지는 것은 첫 화면과 기본 에이전트다. 이름이 낯설 뿐 쓰던 환경은 그대로다.

상자에 담아 옮겨 가는 키보드와 마우스

하나만 고른다면 무엇을 보나?

가격은 기준이 되기 어렵다. 두 도구의 기본 유료 요금이 같은 수준으로 맞춰졌기 때문이다. 남는 기준은 얼마나 맡기고 싶은가다. 여러 파일에 걸친 일을 통째로 맡기고 싶다면 에이전트 쪽, 변경을 하나씩 보고 승인하고 싶다면 Cursor 쪽이 맞는다. 쓰던 편집기를 바꿀 수 있는지부터 따지는 방법은 Copilot과 Cursor를 비교한 글에 적어 두었다.

규칙 문서를 두 도구에 같이 두면 충돌하지 않나?

내용이 같다면 문제 될 것이 없다. 충돌은 두 곳의 내용이 서로 달라질 때 생긴다. 그래서 원본은 저장소에 한 장만 두고, 도구 쪽에 들어간 것은 복사본으로 취급하는 편이 낫다.

둘 다 무료로 견줘 볼 수 있나?

두 도구 모두 무료 플랜이 있다. 조건은 자주 바뀌니 공식 페이지에서 확인하는 편이 확실하다. 견줄 때는 같은 작업 하나를 정해 한 주씩 번갈아 써 보는 쪽이 기능표를 읽는 것보다 빠르다.

정리하면

도구가 바뀌어도 들고 갈 습관 네 가지 체크리스트

두 달 동안 두 도구를 번갈아 쓰는 사이 한쪽은 이름과 기본 에이전트가 바뀌었다. 표에 적힌 기능은 그동안에도 계속 움직였고 앞으로도 움직일 것이다.

손에 남은 것은 도구 쪽이 아니라 저장소와 습관 쪽이었다. 규칙은 파일에 적고, 맥락은 먼저 짚고, 자동 실행은 브랜치로 막고, 설정은 옮기기 쉬운 형태로 둔다. 이 네 가지는 다음에 어떤 이름의 AI 코딩 도구가 나와도 그대로 들고 갈 수 있다.

다음에 개발 도구를 바꿀 일이 생기면 기능표를 펴기 전에 네 가지만 먼저 확인하면 된다. 규칙 문서가 저장소에 있는지, 브랜치 경계가 그 문서에 적혀 있는지, 새 도구에서 파일을 직접 짚는 방법이 무엇인지, 설정과 단축키를 내보내 둘 수 있는지. 이 넷을 확인하고 나면 어느 쪽으로 옮겨 가도 첫날부터 같은 방식으로 일할 수 있다.

요금제와 모델 선택지, 누구에게 어느 쪽을 권하는지까지 담은 비교는 junetapa.com 원문 — Windsurf(현 Devin Desktop)와 Cursor 비교 후기에 있다.

반응형