AIREITER처음 두 달 동안 Cursor Origin은 한 줄짜리 문구와 이메일 입력창뿐이었다. 2026년 8월 17일부터는 Cursor의 코드 호스팅 기능을 체험할 수 있는 초기 베타가 됐다. 다만 출발점은 분명하다. GitHub에서 동기화한 리포지토리는 여전히 GitHub가 원본이며, 유료 사용자들의 접근 가능 여부도 벌써부터 엇갈리고 있다.
Cursor Origin, 지금 실제로 사용할 수 있나
Cursor Origin은 2026년 8월 17일 기준 초기 베타로 출시됐으며, 모든 유료 Cursor 플랜 사용자가 대상이다. 단, 엔터프라이즈 조직은 예외다. 같은 변경 로그에 따르면 관리자가 기능을 제외할 수 있다. 제품 랜딩 페이지도 "Early beta" 안내문에서 베타로 연결한다.
다만 모든 계정에서 즉시 보이는 것은 아니다. 8월 17~18일 r/cursor 출시 스레드에는 발표와 실제 계정 활성화 사이에 차이가 있다는 유료 고객들의 보고가 올라왔다.
"여전히 대기자 명단 신청 화면만 보입니다." — u/NerdyGuy117, r/cursor
"Teams 플랜인데 아직 접근할 수 없네요." — u/Darkoplax, r/cursor
즉, 조건을 충족하는 모든 계정에 한꺼번에 열리는 방식이라기보다 단계적으로 배포되는 것으로 보인다. 활성화된 계정에는 Codebase 탭 아래 Origin 리포지토리가 표시된다. 해당 플랜인데도 아무것도 보이지 않는다면 아직 그 계정까지 베타가 도달하지 않은 것이다.
| 날짜 | 주요 변화 |
|---|---|
| 2026년 6월 16일 | Cursor가 Compile 컨퍼런스에서 Origin 발표: 소개 페이지와 대기자 명단만 제공 |
| 2026년 8월 17일 | 초기 베타 출시: 리포지토리, PR, 코드 탐색, GitHub 동기화, 에이전트 제공 |
발표 당시 한 r/cursor 댓글 작성자는 제품 페이지를 두고 "정보가 전혀 없다. 이메일 입력창이 있는 소개 페이지일 뿐"이라고 평가했다. (u/One-Poet7900)
초기 베타에 포함된 Origin 기능
이번 베타는 네 가지 핵심 기능을 제공하며, 세부 내용은 아래 표에 정리했다. 변경 로그에 따르면 리포지토리는 Cursor의 새 Codebase 탭에 위치한다. 리포지토리 이름은 URL에도 포함되며 Cursor의 예시는 cursor.com/codebase/acme-corp다. 새 리포지토리를 만들려면 +New를 선택하고 이름을 정한 다음 CLI를 설치해 클론하거나, 기존 로컬 프로젝트를 푸시하면 된다.
풀 리퀘스트에서는 타임라인, 커밋, 검사 결과, 변경 파일을 볼 수 있다. 에디터를 떠나지 않고 diff를 검토하고 댓글을 남기며 병합할 수 있다. 아이콘으로 Cursor가 호스팅하는 리포지토리와 GitHub에서 동기화된 리포지토리도 구분한다.
| 기능 | 8월 17일 베타 상태 |
|---|---|
| Cursor 호스팅 리포지토리 | 출시됨(Codebase 탭) |
| 풀 리퀘스트 조회·댓글·병합 | 출시됨 |
| 코드 탐색 및 검색 | 출시됨 |
| 실시간 동기화를 포함한 GitHub 가져오기 | 출시됨 |
| 리포지토리 내에서 동작하는 에이전트 | 출시됨(1차 기능) |
| Vercel, Depot, Buildkite 앱 | 출시됨 |
| 기본 기능을 넘어선 에이전트 네이티브 기능 | "Coming", 일정 미공개 |
| 스택형 풀 리퀘스트 | 문서화되지 않음 |
| 가격, 한도, SLA | 공개되지 않음 |
GitHub 동기화는 원본을 바꾸지 않는다
Origin의 GitHub 동기화는 두 번째 원본을 만드는 기능이 아니라, 검토에 활용할 수 있는 실시간 미러를 만드는 기능이다. 변경 로그에 따르면 GitHub를 연결하고 조직과 리포지토리를 선택하면 Cursor에 실시간 동기화 사본이 생성된다. 동기화된 리포지토리에 읽기 또는 쓰기 권한이 있는 사람은 Cursor에서 이를 볼 수 있으며, 나중에 설정에서 리포지토리별 연결 해제도 가능하다.
Cursor 커뮤니티가 베타 전부터 반복해서 던진 질문은 이것이었다.
"Origin은 github나 git을 대체하는 건가요?" — u/sn2006gy, r/cursor
이번 베타의 구조가 답을 보여준다. GitHub에서 시작한 리포지토리는 푸시도 계속 GitHub로 향하며, Origin 사본은 탐색·검색·풀 용도다. Cursor의 변경 로그도 이를 명확히 적고 있다. GitHub가 원본이라는 것이다.
| 작업 | 처리 위치 |
|---|---|
| 동기화된 리포지토리에 푸시 | GitHub에서 처리, Origin은 이를 미러링 |
| Cursor에서 PR에 댓글 작성 | GitHub에 게시 |
| GitHub의 반응 또는 답글 | 변경 로그 기준 "수 초 내" Cursor에 표시 |
| GitHub에서 할당된 리뷰 | Cursor에서 완료 및 병합 가능 |
| 동기화된 리포지토리 연결 해제 | 리포지토리별 지원 |
관리 주체가 Origin으로 넘어가는 경우는 Origin 안에서 네이티브로 만든 리포지토리뿐이다.
Origin 리포지토리에서 쓰는 에이전트와 CI
변경 로그에 따르면 Origin 리포지토리에 접근할 수 있는 에이전트는 코드 관련 질문에 답하고, 변경을 적용하며, 풀 리퀘스트를 업데이트하고, 브랜치를 푸시할 수 있다. 출시 수개월 전 한 r/cursor 사용자는 여기서 해소하려는 병목을 이렇게 표현했다. "코드 리뷰가 심각한 병목이 됐습니다." (u/calloutyourstupidity)
출시와 함께 제공된 앱은 Vercel, Depot, Buildkite 세 가지다. 리포지토리의 Apps 탭에서 Vercel을 연결하면 모든 PR에 테스트와 댓글 작성을 위한 프리뷰 배포가 생성되고, 병합 시 프로덕션으로 배포된다. Depot과 Buildkite는 기존 GitHub Actions 워크플로를 실행하며, Buildkite는 자체 네이티브 파이프라인도 실행한다. 구분할 점은 분명하다. GitHub에서 동기화한 리포지토리는 기존 GitHub CI를 그대로 유지하는 반면, Origin에서 네이티브로 호스팅하는 리포지토리는 현재 이 세 앱만 연결할 수 있다.
변경 로그에는 에이전트 운영 계층에 대한 내용이 없다. 에이전트가 실행한 푸시에 대한 권한 제어와 감사 로그, 리포지토리별 한도, 비용 정보가 모두 공개되지 않았다. Cursor 밖에서 자체 코딩 에이전트를 운영한다면, 리포지토리에 푸시하는 주체를 평가할 때도 코딩 에이전트용 LLM 선택 기준이 그대로 적용된다.
베타가 아직 밝히지 않은 내용
- 리포지토리 크기, 스토리지, 동시 실행 한도가 공개되지 않았고 SLA나 가동률 목표도 없다.
- Origin 전용 가격 정책이 없다. 현재 상업적 안내는 "유료 플랜에 포함"된다는 내용이 전부이며, 추가 요금·할당량·향후 무료 티어는 언급되지 않았다.
- Origin 전용 데이터 처리 조건도 없다. Cursor의 보안 페이지에는 SOC 2 인증이 명시돼 있지만, 발표 당시 제기된 학습 데이터와 보존 기간 문제에는 호스팅 리포지토리에 특화된 공개 답변이 없다.
- Compile 무대에서 제시된 수치(한 리포지토리에서 초당 22.6개 커밋, "시간당 수십만 건의 클론")는 여전히 데모 주장에 머문다. 독립적인 Cursor 가이드는 이를 검증되지 않은 수치로 분류했고, 출시 보도는 널리 인용된 "296,000+ clones" 수치가 원래의 시간 단위를 잃었다고 지적했다.
Cursor가 Origin 전용 조건을 공개하기 전까지, 6월에 나온 이 반응은 도입의 현실적인 제약으로 남는다.
"전체 Git 히스토리를 Cursor에 넘길 가능성은 0입니다." — u/fintechbass, r/cursor
지금 Origin을 써볼 팀과 기다려야 할 팀
| 상황 | 권장 |
|---|---|
| 유료 Cursor 플랜을 쓰고, 에이전트가 코드 상당 부분을 작성하며, 중요하지 않은 리포지토리를 제공할 수 있음 | 시도해볼 만함. 베타가 이미 플랜에 포함됨 |
| 기존 CI와 함께 리포지토리를 GitHub에 유지해야 함 | 문제없음. 동기화로 Cursor에서 검토·검색하고 CI는 GitHub에서 계속 실행 |
| Vercel, Depot, Buildkite 외 CI를 연결한 네이티브 Origin 호스팅이 필요함 | 기다릴 것. 현재 제공되는 앱은 세 가지뿐 |
| 원본 리포지토리 이전을 고려 중임 | 기다릴 것. GitHub가 여전히 원본이므로 이전 대신 동기화하는 편이 나음 |
베타 이후에도 남을 핵심 트레이드오프는 리포지토리 호스트를 옮기면 관리 주체도 옮겨간다는 점이다. 같은 스택형 PR 비교는 PR 스레드처럼 Git 이외의 리뷰 산출물은 "git push로 이동하지 않는다"고 경고한다. 따라서 Origin은 현재 선택지 가운데 되돌리기 가장 어려운 편이다. 이 비교 자료는 Cursor가 2025년 12월 19일 스택형 PR 기업 Graphite 인수에 관한 최종 계약을 발표했으며, Graphite 팀이 Cursor 안에서 Origin을 개발하고 있다고 기록한다. Graphite는 현재도 graphite.com에서 독립 운영되고 있고, 연간 결제 기준 스태킹 티어 가격은 사용자당 월 $20–40으로 표시돼 있다.
Cursor Origin은 GitHub를 대체하나
아니다. GitHub에서 동기화한 리포지토리는 GitHub가 원본으로 남고 푸시도 GitHub에 반영된다. Origin은 네이티브 호스팅 옵션과 그 위에 얹는 검토 환경을 추가한다.
Cursor Origin은 Cursor 플랜에 포함되나
초기 베타는 모든 유료 Cursor 플랜에 열려 있다. Origin 별도 가격, 할당량, 무료 티어 계획은 발표되지 않았다.
Cursor Origin은 스택형 풀 리퀘스트를 지원하나
베타 문서에는 관련 내용이 없다. 독립 비교 자료에 따르면 Origin의 스택형 워크플로는 Graphite 인수에서 예상할 수 있는 방향일 뿐, 공개된 기능은 아니다.
Cursor Origin을 자체 호스팅할 수 있나
8월 17일 변경 로그와 Origin 제품 페이지 모두 자체 호스팅 옵션을 언급하지 않는다. Origin 리포지토리는 Cursor가 호스팅하며, 엔터프라이즈 관리자는 기능 전체를 제외하는 것만 가능하다.
대규모 코딩 에이전트 운영에 Origin이 필수인가
아니다. 독립적인 Cursor 가이드는 오늘도 GitHub나 GitLab에서 같은 리뷰 병목을 해결할 방법으로 에이전트별 분리 worktree, 작은 diff, 1차 리뷰 봇을 권장한다.
관련 글: Cursor Router explained