Fronmpt← 모든 글
블로그4분 읽기

커서가 코드 호스팅 플랫폼 Origin으로 깃허브의 자리를 직접 노렸습니다

30초 론칭 영상으로 발표된 커서의 코드 호스팅 Origin과, 이틀 뒤 올라온 클라우드 에이전트 개편을 겹쳐 읽었습니다. 에디터에서 태어난 코드가 자기 호스팅에서 머지까지 끝나는 루프입니다.

커서가 깃허브의 자리를 직접 노렸습니다. 코드 호스팅 플랫폼 Origin의 발표 트윗 하나가 조회 2,615만을 넘겼어요.

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

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

AI 코딩이 이미 벌어지는 에디터 안에, 이제 호스팅까지 들어온 겁니다. 이번 판의 주인공이 누구인지는 반응의 크기가 먼저 말한 셈이에요.

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

발표에 달린 반응 중에 가장 아픈 지적이 이겁니다. 사람들이 깃허브에 있는 건 호스팅 때문이 아니라는 거예요.

내 이슈, 내 리뷰, 같이 일해본 사람 전부가 거기 있기 때문이고, 그건 에디터를 따라 새 리모트로 이사하지 않는다는 답글이 붙었습니다.

재미있는 건 이 답글이 거의 읽히지 않았다는 점입니다. 수천만이 본 발표 아래에 사실상 묻힌 채로 달려 있어요. 그런데 이 한 줄이 이번 논쟁에서 제일 정확한 문장입니다.

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

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

그런데 반대쪽 관전평도 만만치 않습니다. 배포가 깃허브의 해자였는데, 이제 워크플로를 쥔 건 에디터라는 지적이 나왔어요.

코드가 태어나는 곳이 에디터고, 리뷰도 머지도 에이전트가 하는 시대라면, 호스팅은 그 옆에 붙는 부속이 됩니다. 주객이 바뀌는 거죠.

깃허브가 드디어 경쟁자를 만났다는 반응도 같은 자리에 붙었습니다. 해자 논쟁과 세대교체 기대가 한 발표 밑에서 정면으로 부딪힌 거예요.

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

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

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

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

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

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

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

스레드에 달린 실사용 답글도 방향이 같습니다. 클라우드 에이전트가 오늘 말 그대로 우리를 구했다. 정말 훌륭한 제품이고, 아름답게 실행됐다.

여기에 Origin을 겹쳐 보면 그림이 완성됩니다. PR이 사는 곳이 자기 플랫폼이면, 그 루프 전체가 자기 마당 안에서 돌아요.

Origin은 호스팅 사업이 아니라 에이전트 루프의 마지막 조각입니다. 에디터에서 태어난 코드가, 에이전트가 만든 PR을 타고, 자기 호스팅에서 리뷰와 머지까지 끝나는 구조예요.

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

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

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

깃허브에서 리포를 동기화하면 시작된다는 발표 문구도 이 관점에서 다시 읽힙니다. 대이동을 요구하는 게 아니라, 복사본 하나 놓고 시작하는 문턱을 최대한 낮춰 놓은 거예요. 기존 자산은 그대로 두고, 다음 프로젝트부터 자기 마당에서 열게 만드는 설계입니다.

커서 입장에서 손해 볼 게 없는 수이기도 합니다. 동기화는 깃허브를 떠나라는 요구가 아니니 기존 사용자를 잃을 리스크가 없고, 새 프로젝트가 자기 마당에서 열릴 때마다 루프 완결이라는 본전이 쌓입니다.

남는 생각

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

이 관점이면 두 회사의 싸움은 당장의 점유율 그래프에 안 나타납니다. 기존 리포 수를 세면 깃허브가 압도적인 채로 한참 가고, 그동안 새로 열리는 리포의 몫이 조용히 갈리는 거예요.

해자는 뽑히는 게 아니라, 그 바깥에 새 땅이 생기는 방식으로 닳습니다. 판이 넘어간다면 기존 팀의 대이동이 아니라 신규 프로젝트부터 조용히 넘어가는 거예요.

원문·소스

FAQ

자주 묻는 질문

깃허브의 해자는 왜 서버가 아닌가요?
사람들이 깃허브에 있는 건 호스팅 때문이 아니라 내 이슈, 내 리뷰, 같이 일해본 사람 전부가 거기 있기 때문이라는 답글이 발표에 달렸습니다. 리포는 버튼 하나로 옮겨도 십오 년치 관계와 기록은 안 옮겨집니다.
워크플로 주도권은 왜 에디터로 넘어갔나요?
코드가 태어나는 곳이 에디터고 리뷰도 머지도 에이전트가 하는 시대라면, 호스팅은 그 옆에 붙는 부속이 된다는 관전평이 나왔습니다. 깃허브가 드디어 경쟁자를 만났다는 반응도 같은 자리에 붙었습니다.
Origin과 클라우드 에이전트 개편은 어떻게 맞물리나요?
Origin 발표가 재공유를 타고 돈 게 8월 17일, 클라우드 에이전트 개편 스레드가 올라온 게 8월 19일로 이틀 차이입니다. PR이 사는 곳이 자기 플랫폼이면, 에이전트가 만든 PR의 리뷰와 머지까지 루프 전체가 자기 마당 안에서 돕니다.
Origin의 진짜 표적은 누구인가요?
기존 팀에게는 이관 비용이 실재하니, 진짜 표적은 에이전트와 함께 시작하는 새 프로젝트입니다. 제로에서 시작하는 쪽은 옮길 이슈도 지킬 리뷰 기록도 없어 해자가 아예 보이지 않습니다.