커서가 코드 호스팅 플랫폼 Origin으로 깃허브를 직접 겨눴습니다

커서가 코드 호스팅 플랫폼 Origin을 내놓고 깃허브와 직접 맞붙었습니다. 사람들은 발표 트윗 하나를 2,615만 번 넘게 봤어요.

발표 문구는 짧습니다. "Origin, 우리의 코드 호스팅 플랫폼이 라이브다. 빠르고, 쓰기 쉽고, 커서에 깊게 통합돼 있다. 깃허브에서 리포를 동기화하면 시작된다." 커서는 30초 남짓한 론칭 영상 하나로 발표를 끝냈어요.

이 발표를 재공유한 계정은 장면을 한 문장으로 정리했습니다. "깃허브에 에디터 안에 바로 박힌 경쟁자가 생겼다. AI 코딩 대부분이 이미 벌어지는 그 에디터에."

사람들이 AI 코딩을 이미 하고 있는 에디터 안에, 커서가 이제 호스팅까지 넣은 겁니다. 반응 크기만 봐도 사람들이 이번 싸움의 주인공을 누구로 보는지 알 수 있어요.

깃허브의 해자는 왜 서버가 아닌가요?

발표에 달린 반응 중에 가장 아픈 지적이 이겁니다. 사람들은 호스팅 말고 다른 이유로 깃허브에 머문다는 거예요.

누군가 이런 답글을 달았어요. "내 이슈, 내 리뷰, 같이 일해본 사람 전부가 거기 있기 때문이다. 그건 에디터를 따라 새 리모트로 이사하지 않는다."

이 답글을 본 사람은 거의 없었습니다. 수천만이 본 발표 아래에 사실상 묻힌 채로 달려 있어요. 그런데 저는 이 한 줄을 이번 논쟁에서 제일 정확한 문장으로 봅니다.

맞는 말입니다. 깃허브의 해자는 서버보다 십오 년치 관계와 기록에 있어요. 리포는 버튼 하나로 옮겨도, 이슈 십 년치와 리뷰 문화와 협업자 네트워크는 못 옮깁니다.

워크플로 주도권은 왜 에디터로 넘어갔나요?

그런데 반대쪽 관전평도 만만치 않습니다. 누군가는 배포가 깃허브의 해자였지만 이제 워크플로는 에디터가 쥐었다고 지적했어요.

개발자가 에디터에서 코드를 만들고, 리뷰도 머지도 에이전트가 하는 시대라면, 개발자에게 호스팅은 부속이 됩니다. 주객이 바뀌는 거죠.

같은 답글란에는 깃허브가 드디어 경쟁자를 만났다고 반기는 사람도 있었어요. 깃허브의 해자가 단단하다는 쪽과 세대교체를 기대하는 쪽이 한 발표 밑에서 정면으로 부딪힌 거예요.

Origin과 클라우드 에이전트 개편은 어떻게 맞물리나요?

이틀 차이입니다. Origin 발표가 재공유를 타고 돈 게 8월 17일, 커서가 클라우드 에이전트 개편 스레드를 올린 게 8월 19일이에요.

커서는 이 스레드에서 Origin과 정확히 맞물리는 내용을 발표했어요. 에이전트가 이벤트에서 일을 집어 들고, 목표를 달성할 때까지 붙잡고, 긴 세션 내내 경로를 유지한다는 내용이에요.

구체적으로는 이렇습니다. 커서가 PR을 모니터링하고, 슬랙 스레드를 지켜보고, 예약 작업을 돌립니다. 클라우드 에이전트는 자기가 만든 PR을 스스로 구독해서 완료까지 끌고 갑니다.

스레드를 더 내려가면 커서가 내놓은 부품이 계속 나옵니다. 서브에이전트가 각자 격리된 가상 머신에서 프로젝트 사본을 들고 돌고, 부모 에이전트의 변경을 깨끗한 환경에서 테스트하거나 독립적인 수정을 떼로 처리해요.

스킬을 채팅에 고정해두는 커스텀 모드, 실행 중인 에이전트를 끊지 않고 다음 툴 호출 타이밍에 개입을 끼워 넣는 스티어링 개선까지, 전부 에이전트를 오래 돌리기 위한 손질입니다.

마지막 트윗은 /goal이에요. 에이전트에게 완전히 끝날 때까지 붙잡을 장기 목표를 주는 명령입니다.

스레드에는 실사용자도 같은 방향의 답글을 남겼어요. "클라우드 에이전트가 오늘 말 그대로 우리를 구했다. 정말 훌륭한 제품이고, 아름답게 실행됐다."

여기에 Origin을 겹쳐 보면 커서의 계획이 보입니다. PR을 자기 플랫폼에 두면, 커서는 그 루프 전체를 자기 마당 안에서 돌릴 수 있어요.

커서에게 Origin은 에이전트 루프의 마지막 조각입니다. 에디터에서 만든 코드를 에이전트가 PR로 올리고, 자기 호스팅에서 리뷰와 머지까지 끝내는 구조예요.

Origin의 진짜 표적은 누구인가요?

기존 팀에게 이관 비용은 실재합니다. 리포 옮기기는 쉬워도 관계와 기록은 못 옮기니까, 깃허브의 해자는 기존 팀 앞에서는 여전히 단단해요.

그래서 커서는 에이전트와 함께 시작하는 새 프로젝트를 노릴 겁니다. 제로에서 시작하는 쪽은 옮길 이슈도, 지킬 리뷰 기록도 없으니 해자가 아예 안 보이거든요.

이 관점에서 보면 깃허브에서 리포를 동기화하면 시작된다는 발표 문구도 다르게 읽을 수 있어요. 커서는 대이동을 요구하지 않고, 복사본 하나로 시작할 수 있게 문턱을 최대한 낮췄어요. 기존 자산은 그대로 두고, 다음 프로젝트부터 자기 마당에서 열게 만드는 설계입니다.

커서 입장에서 손해 볼 게 없는 수이기도 합니다. 동기화는 깃허브를 떠나라는 요구가 아니니 기존 사용자를 잃을 리스크가 없고, 개발자가 새 프로젝트를 커서에서 열 때마다, 커서는 루프를 끝까지 닫는 프로젝트를 하나씩 얻습니다.

남는 생각

저는 이 싸움의 승부처가 이관 비용이라고 봅니다.

이 관점이면 당장의 점유율 그래프로는 두 회사의 싸움을 볼 수 없습니다. 기존 리포 수로 보면 깃허브가 한참 앞서요. 그동안 커서는 새로 열리는 리포를 조용히 가져갈 수 있어요.

커서가 깃허브의 해자를 한 번에 뽑을 수는 없어요. 대신 해자 바깥에 새 땅을 만들면서 해자를 조금씩 무디게 만들 수는 있습니다. 개발자들이 옮겨 간다면, 기존 팀이 한꺼번에 이사하기보다 신규 프로젝트부터 조용히 커서로 넘어갈 거예요.

---