커서 안에서 웹앱 생성부터 배포까지 끝나는 파이프라인이 열렸습니다

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

문장 하나에 파이프라인 전체가 들어 있습니다. 생성은 Cursor, 저장은 Origin, 배포는 Vercel이에요.

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

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

이 발표의 핵심은 문장에 들어간 세 단어가 아니라 빠진 단어들입니다.

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

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

이 발표가 제시하는 동선은 하나입니다. 에디터를 열고, 만들고, 저장하고, 배포합니다. 신규 프로젝트의 첫 한 시간을 잡아먹던 절차들이, 이 문장 안에서는 존재하지 않습니다.

발표 형식도 같은 말을 합니다. 긴 설명 없이 한 문장과 영상 하나가 전부예요. 설명이 필요 없는 동선이라는 게 이 발표의 자신감입니다.

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

커서가 코드 호스팅 플랫폼 Origin을 발표했을 때, 이 계정은 그 발표를 다뤘습니다. 발표 트윗이 조회 2,615만을 찍은 사건이었어요.

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

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

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

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

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

커서가 노리는 자리는 어디인가요?

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

대신 노리는 건 다음 프로젝트를 여는 순간의 손버릇입니다. 새 아이디어가 생겼을 때 어디를 여는가. 그 첫 동선이 에디터 안에서 완결되면, 신규 프로젝트의 기본값이 조용히 넘어갑니다.

기본값 싸움의 무서운 점은 점유율 그래프에 전혀 안 보인다는 겁니다. 지표가 움직일 때는 이미 늦었고요. 기존 리포 수를 세면 깃허브가 압도적인 채로 한참 가요. 그동안 새로 열리는 프로젝트의 첫 저장소가 어디인지는 아무 지표에도 안 잡힙니다.

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

코드가 태어나는 곳, 저장되는 곳, 배포되는 곳이 전부 한 파이프라인 안에 있으면, 에이전트는 그 안에서 처음부터 끝까지 돌 수 있습니다. 사람의 손버릇만 노리는 게 아니라, 에이전트의 작업 루프까지 자기 마당에 두는 설계예요.

배포는 왜 Vercel인가요?

발표에서 눈에 걸리는 대목이 하나 있습니다. 배포가 자체 서비스가 아니라 Vercel이라는 점이에요.

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

저는 이걸 우선순위의 문제로 읽습니다. 지금 중요한 건 배포 시장의 몫이 아니라 동선이 끊기지 않는 것입니다. 이미 검증된 배포 서비스에 연결하면 파이프라인이 오늘 완성되고, 직접 만들면 몇 분기가 밀리죠.

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

남는 생각

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

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

그런데 생성·저장·배포가 한 문장에 묶이는 순간 질문이 바뀝니다. 어느 호스팅이 나은가가 아니라, 새 프로젝트를 어디서 시작하는 게 편한가로요. 그 질문 앞에서는 축적이 해자가 아닙니다. 새로 시작하는 쪽엔 옮길 짐 자체가 없거든요.

판이 넘어간다면 기존 팀의 대이동이 아니라 신규 프로젝트부터 조용히 넘어갈 거라고 지난 글에 썼습니다. 사흘 만에 그 경로가 제품으로 나왔으니, 이제 이건 예측이 아니라 진행 중인 계획이라고 봅니다. 다음 수는 이 파이프라인 안으로 들어오는 다음 단계가 무엇인지로 읽으면 될 겁니다.

---

원문·소스

• 커서 웹앱 생성·저장·배포 발표 (@cursor_ai): https://x.com/cursor_ai/status/2093077548649570777 (조회 69만, 좋아요 3,533)
• 커서 Origin 발표 원문: https://x.com/cursor_ai/status/2089399057659596847 (조회 2,615만)