커서가 깃허브와 로컬 셋업을 동선에서 통째로 지워버렸습니다

"이제 Cursor로 새 웹앱을 만들고, 코드를 Origin에 저장하고, Vercel로 배포할 수 있다." 커서 공식 계정이 이 한 문장짜리 영상 발표를 올렸습니다.

커서는 문장 하나에 파이프라인 전체를 담았습니다. 생성은 Cursor, 저장은 Origin, 배포는 Vercel이에요.

아이디어에서 라이브 URL까지, 에디터 밖을 한 번도 안 나갑니다. 사흘 전 Origin 발표를 다룬 지난 글에서 예고한 바로 그 장면이에요.

발표 문구에서 빠진 건 무엇인가요?

저는 이 발표에서 문장에 들어간 세 단어보다 빠진 단어들을 먼저 봤습니다.

깃허브가 없습니다. 새 프로젝트를 열 때 리포부터 만들던 그 관문을 커서가 동선에서 지웠어요. 로컬 셋업도 없습니다. 환경을 깔고, 클론하고, 설정 파일을 맞추던 통과의례를 통째로 건너뜁니다.

지금까지 새 웹앱의 표준 동선을 떠올려 보세요. 깃허브에서 리포를 만들고, 로컬에 클론하고, 에디터를 열고, 코드를 쓰고, 푸시하고, 배포 서비스에 리포를 연결합니다. 도구 세 개와 탭 대여섯 개를 오가는 여정이에요.

이 발표가 제시하는 동선은 하나입니다. 에디터를 열고, 만들고, 저장하고, 배포합니다. 신규 프로젝트의 첫 한 시간을 쓰던 절차를 이제 건너뜁니다.

커서는 발표도 한 문장과 영상 하나로 끝냈어요. 긴 설명은 없습니다. 설명이 필요 없는 동선이라는 자신감이죠.

Origin 발표와는 어떻게 이어지나요?

커서가 코드 호스팅 플랫폼 Origin을 발표했을 때, 저는 지난 글에서 그 발표를 다뤘습니다. 사람들은 그 발표 트윗을 2,615만 번 봤어요.

그때 논쟁의 중심은 해자였습니다. 깃허브에는 십오 년치 이슈와 리뷰 기록, 협업자 네트워크가 있어서 사람들이 에디터를 따라 이사하지 않을 거라는 반론이 발표 밑에 달렸죠.

맞는 반론이었습니다. 기존 팀에게 이관 비용은 실재하니까요. 리포는 버튼 하나로 옮겨도, 이슈 십 년치와 리뷰 문화와 협업자 네트워크는 못 옮깁니다.

그래서 저는 그 글에서, Origin이 진짜 겨냥하는 건 에이전트와 함께 시작하는 새 프로젝트일 거라고 결론 냈습니다. 제로에서 시작하는 쪽은 옮길 이슈도, 지킬 리뷰 기록도 없으니 해자가 아예 안 보이거든요.

그 결론을 낸 지 사흘 만에, 커서가 정확히 그 수를 실행했습니다. 커서는 기존 리포를 옮기라고 하지 않고, 새 웹앱을 여기서 시작하라고 말합니다.

호스팅을 열고, 사흘 뒤에 그 호스팅을 관통하는 신규 프로젝트 동선을 내놓는 순서. 커서는 Origin을 단독 제품보다 파이프라인의 부품으로 설계했어요.

커서는 무엇을 노리나요?

이 파이프라인은 기존 팀에게 아무것도 요구하지 않습니다. 십 년 묵은 리포를 옮기라고도, 리뷰 문화를 버리라고도 안 해요. 그 싸움은 커서가 이길 수 없는 싸움이고, 커서도 그걸 압니다.

대신 커서는 다음 프로젝트를 여는 순간의 손버릇을 노립니다. 새 아이디어가 생겼을 때 어디를 여는가. 그 첫 동선을 에디터 안에서 끝내면, 개발자는 새 프로젝트를 자연스럽게 커서에서 열게 됩니다.

저는 기본값 싸움을 무섭게 봅니다. 점유율 그래프로는 전혀 안 보이거든요. 지표에서 변화를 볼 때쯤이면 이미 늦었고요. 기존 리포 수로 보면 깃허브가 한참 앞서요. 그동안 새로 여는 프로젝트의 첫 저장소가 어디인지는 아무 지표로도 못 잡습니다.

그리고 커서는 이 동선을 에이전트와도 잘 맞물려 놨습니다. 같은 주에 커서는 클라우드 에이전트 개편도 발표했었죠. 에이전트가 PR을 만들고, 스스로 구독해서, 완료까지 끌고 가는 구조요.

코드를 만들고, 저장하고, 배포하는 곳이 전부 한 파이프라인 안에 있으면, 에이전트는 그 안에서 처음부터 끝까지 돌 수 있습니다. 커서는 사람의 손버릇에 더해 에이전트의 작업 루프까지 자기 마당에 둡니다.

배포는 왜 Vercel인가요?

발표에서 눈에 걸리는 대목이 하나 있습니다. 커서는 배포를 자체 서비스 대신 Vercel에 맡겼어요.

호스팅은 Origin으로 직접 만들었으면서, 배포는 남의 서비스에 연결했습니다. 전부 쥐려는 회사라면 배포까지 자기 이름을 걸었을 텐데, 커서는 그러지 않았어요.

저는 이걸 우선순위의 문제로 읽습니다. 커서는 배포 시장의 몫보다 동선을 끊기지 않게 하는 걸 먼저 챙겼어요. 이미 검증된 배포 서비스에 연결하면 파이프라인을 오늘 완성하고, 직접 만들면 몇 분기를 미루게 되죠.

전부 쥐려다 동선을 끊는 것보다, 끊기지 않는 한 줄을 먼저 잇겠다는 판단입니다. 생성과 저장을 자기 마당에 두는 한, 배포는 나중에 바꿔 끼울 수 있는 부품이기도 하고요. 커서는 파이프라인에서 각 단계를 소유하는 것보다 단계 사이를 잇는 쪽을 더 중요하게 보는 겁니다.

남는 생각

저는 이 발표를 Origin의 후속편보다 본편으로 봅니다.

Origin 단독으로는 "깃허브 대신 쓸 이유가 뭐냐"는 질문에 커서는 답이 궁했습니다. 호스팅만 놓고 비교하면 깃허브의 축적을 이길 수 없으니까요.

그런데 커서가 생성·저장·배포를 한 문장에 묶자 개발자는 다른 질문을 던집니다. 어느 호스팅이 나은지보다, 새 프로젝트를 어디서 시작하는 게 편한지를요. 그 질문 앞에서는 깃허브도 축적을 해자로 쓸 수 없습니다. 새로 시작하는 쪽엔 옮길 짐 자체가 없거든요.

지난 글에 저는, 개발자들이 옮겨 간다면 기존 팀이 한꺼번에 이사하기보다 신규 프로젝트부터 조용히 커서로 넘어갈 거라고 썼습니다. 사흘 만에 커서가 그 경로를 제품으로 내놨으니, 커서는 이미 그 계획을 실행하고 있다고 봅니다. 다음에는 커서가 이 파이프라인 안으로 어떤 단계를 더 넣는지 보면 될 겁니다.

---