Cursor Origin 튜토리얼: CLI 설정, GitHub 미러링, 풀 리퀘스트

Cursor Origin이란?

Cursor Origin은 Git 포지입니다. 저장소를 호스팅하고, GitHub 프로젝트를 미러링하며, 풀 리퀘스트와 코드 탐색을 지원합니다. Origin 저장소는 Cursor의 클라우드 에이전트와 자동화 기능과도 연동됩니다.

Cursor Origin과 GitHub의 차이점은?

Origin은 GitHub의 모든 기능을 제공하지는 않습니다. 공개 저장소는 문서화되어 있지 않으며, 미러링에는 GitHub Issues, GitHub Actions 워크플로우, 그리고 Actions 시크릿이 포함되지 않습니다. 공개 저장소, Issues, Actions, 서드파티 앱 측면에서 GitHub가 여전히 더 폭넓은 플랫폼이므로, 오늘날 Origin은 더 좁은 서비스입니다.

주요 차이는 익숙한 Git 워크플로 아래에 있습니다. Cursor는 에이전트가 만들어내는 브랜치와 커밋 규모를 처리하기 위한 별도의 스토리지 레이어를 구축했습니다. Cursor는 이를 "에이전트 규모(agent scale)"라고 부르며, 다수의 에이전트가 동일한 저장소에서 브랜치를 만들고 커밋하며 풀 리퀘스트를 여는 워크로드를 가리킵니다.

Cursor가 독자적인 Git 호스트를 만든 이유는?

스토리지 설계가 기존 호스트에 다른 인터페이스를 추가하는 대신 새로운 Git 호스트를 만든 이유를 설명합니다.

Cursor의 Continuity에 관한 엔지니어링 포스트는 기존 Git 호스트가 저장소를 여러 서버에 두고 과반수가 동의하면 푸시를 확정하는 방식이라고 설명합니다. Cursor는 이 모델이 수명이 짧은 저장소가 수천 개이거나 하나의 저장소에 빈번한 푸시가 있을 때 비용이 더 든다고 말합니다.

Cursor Origin의 Continuity 스토리지는 어떻게 동작하나요?

Continuity(약칭 "Cnt")는 Origin 뒤에서 동작하는 스토리지 시스템입니다. S3 호환 오브젝트 스토리지에 선기록 로그(write-ahead log)를 저장하며 이를 소스 오브 트루스로 사용합니다. 로컬 디스크의 Git 저장소는 로그에서 재구성 가능한 웜 캐시 역할을 합니다.

Continuity는 Git 기록을 오브젝트로 저장합니다. 이미지: 작성자 제공.

오브젝트 로그가 실제 기록이기 때문에, Cursor는 트래픽이 많은 저장소에 읽기 레플리카를 추가하고 수요가 줄면 제거할 수 있습니다. Cursor의 테스트에서는 레플리카를 최대 100개까지 추가할수록 읽기 처리량이 증가했습니다. 표준 S3에서 초당 최대 120개의 푸시를 처리했지만, 이 수치는 외부 벤치마크로 검증되지는 않았습니다.

사용자 입장에서는 더 단순합니다. 바쁜 저장소는 읽기 용량을 늘릴 수 있고, 수명이 짧은 저장소는 모든 서버에 상시 로컬 복사본이 필요하지 않습니다.

누가 Cursor Origin에 액세스할 수 있나요?

Origin은 Pro, Teams, Enterprise 요금제에서 제공되며, 무료 요금제에서는 제공되지 않습니다. 접근 권한은 단계적으로 배포되므로, 자격이 있어도 Codebase 탭이 바로 나타나지 않을 수 있습니다. Pro에서는 개인 네임스페이스를 보유하고 코드베이스 이름을 직접 등록합니다.

Enterprise 관리자는 조직 단위로 비활성화할 수 있습니다. Cursor 개요에는 팀 구성원 누구나 첫 코드베이스 이름을 등록할 수 있다고 되어 있으나, Codebase Settings 페이지에는 팀 관리자가 등록해야 한다고 되어 있습니다. 설정 전 팀 내 권한을 확인하세요.

Cursor Origin CLI란?

Origin은 인증, 저장소, 풀 리퀘스트, 계정 구성을 위한 독자적인 커맨드라인 도구를 제공합니다.

Cursor Origin CLI vs. Cursor Agent CLI

Origin의 CLI는 Cursor의 Agent CLI와 분리된 실행 파일로, origin 명령을 사용하며, Agent CLI는 agent 로 실행됩니다. 

명칭이 헷갈릴 수 있습니다. origin은 일반적으로 Git 원격 이름이기도 하기 때문입니다. 이 글에서 "push to origin"은 Git 원격을 의미하고, "run origin"은 CLI 실행을 의미합니다.

Origin CLI가 지원되는 플랫폼

Cursor 문서에는 macOS, Linux, WSL을 통한 Windows가 명시되어 있습니다. 테스트 시점에는 Windows용 네이티브 설치 관리자가 없어 WSL을 의미했습니다.

Windows에서 진행 중이라면, CLI 설치 전에 Ubuntu 터미널을 여세요. PowerShell에서 셸 설치 프로그램을 실행하는 것은 동일한 설정이 아닙니다.

Cursor Origin CLI 명령

현재 Cursor Origin CLI에는 아홉 가지 명령 그룹이 있습니다.

대부분의 저장소 명령은 origin이라는 이름의 Git 원격에서 대상을 읽습니다. -R owner/repo 옵션은 대상을 직접 지정하며, 여러 저장소를 대상으로 실행될 수 있는 스크립트에서 유용합니다. ruleset 명령은 기존 푸시 및 머지 규칙만 표시하며, 변경하지는 않습니다.

Cursor Origin CLI 설치 및 로그인 방법

Cursor는 패키지 관리자가 아닌 셸 스크립트로 CLI를 제공합니다. 명령은 Cursor의 설치 페이지에서 가져옵니다.

Cursor Origin CLI 설치 방법

설치는 한 줄로 끝납니다:

curl -fsSL https://downloads.cursor.com/origin/install.sh | sh

설치 프로그램은 origin을 ~/.local/bin/origin 위치에 배치했습니다. 팀에서 설치 스크립트를 실행 전 검토한다면, sh로 바로 파이프하지 말고 먼저 스크립트를 내려받아 확인하세요.

Origin CLI "command not found" 오류 해결

설치 후 셸에서 origin을 찾지 못한다면, 해당 디렉터리를 PATH에 추가하세요:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

~/.zshrc 대신 bash에서는 ~/.bashrc를 사용하세요. 머신당 한 번만 설정하면 됩니다.

설치 및 로그인 확인

설치를 확인하려면 origin --version 및 origin --help를 실행한 후, origin auth login으로 Cursor의 브라우저 로그인 흐름을 시작하세요.

WSL에서 확인 출력은 다음과 같았습니다:

Origin CLI 버전 및 도움말 출력. 이미지: 작성자 제공.

헤드리스 환경에서는 CLI가 URL을 출력합니다. 로그인은 Git의 크리덴셜 헬퍼도 구성하므로, Origin 원격은 별도의 Git 토큰 없이 동작합니다. 이후 origin auth status로 세션을 확인하세요.

브라우저 없이 Cursor API 키 사용하기

CI나 스크립트에서는 origin auth login --api-key <key>를 실행하거나 CURSOR_API_KEY를 설정한 뒤 origin auth login을 실행하세요. 키는 커밋된 파일에 포함하지 마세요. CURSOR_AUTH_TOKEN 은 다른 값으로, 베어러 토큰을 기대합니다.

Cursor Origin 저장소 생성, 클론, 푸시 방법

로그인 후에는 웹 페이지나 CLI에서 저장소를 생성할 수 있습니다. 푸시는 표준 Git 명령을 사용합니다.

origin repo create로 저장소 만들기

cursor.com/codebase에서 New를 선택하고 이름을 입력한 뒤 Internal 또는 Private 가시성을 선택합니다. 

CLI에서는 origin repo create my-project가 계정의 네임스페이스를 사용합니다. 팀 네임스페이스에는 origin repo create acme/my-project처럼 소유자를 포함하세요. 선택 사항인 --default-branch 플래그로 서버의 기본 브랜치 main을 변경할 수 있습니다.

origin repo clone acme/my-project 명령은 CLI에 저장된 로그인 정보를 이용해 HTTPS로 저장소를 클론합니다.

Origin으로 첫 커밋 푸시하기

첫 푸시 후 저장소가 Codebase에 표시됩니다:

저장소가 푸시되어 Codebase에 표시됨. 영상: 작성자 제공.

완전히 비어 있는 신규 저장소라면, 클론 후 파일을 추가하고 푸시하세요:

git clone https://origin.cursor.com/{owner}/{repo}.git
cd {repo}
echo "# {repo}" > README.md
git add .
git commit -m "Initial commit"
git push -u origin main

Git이 WSL의 /mnt 아래에서 .git/config.lock 권한 오류를 보고한다면, 대신 ~ 아래에서 클론하세요. 제 테스트에서는 그렇게 해서 오류가 해결되었습니다.

푸시 후 Codebase를 열어 커밋이 보이는지 확인하세요. Code 탭에는 파일 트리와 커밋 기록이 표시됩니다. T 를 눌러 Go to file로 이동하거나, 검색 필드로 코드를 검색하세요.

기존 Git 저장소를 Origin으로 푸시하기

이미 Git 히스토리가 있는 프로젝트라면 먼저 git remote -v를 실행하세요. 아래 명령은 저장소에 origin이라는 이름의 원격이 아직 없을 때만 적용됩니다:

git remote add origin https://origin.cursor.com/{owner}/{repo}.git
git push -u origin main

origin이 이미 GitHub를 가리킨다면, 기존 URL을 대체하지 말고 cursor처럼 다른 원격 이름을 사용하세요. Origin CLI 명령은 그 이름에서 저장소를 추론하지 않으므로, 실행 시 -R owner/repo를 전달해야 합니다.

Cursor Origin에서 GitHub 저장소 미러링하는 방법

미러링은 기존 GitHub 프로젝트를 Origin으로 복사하고 두 서비스를 연결 상태로 유지합니다.

Cursor Origin GitHub 미러링 요건

Origin 액세스, 해당 저장소를 소유한 조직 또는 계정에 연결된 Cursor GitHub 앱, 그리고 그 저장소에 대한 GitHub 관리자 권한이 필요합니다. 쓰기 권한만으로는 충분하지 않습니다.

Cursor Origin GitHub 미러 시작하기

cursor.com/codebase에서 Sync from GitHub를 선택하고 조직과 저장소를 고른 뒤 확인합니다. CLI 대안은 origin repo create-mirrored owner/repo이며, Cursor의 미러링 문서에서 다룹니다.

Cursor Origin이 GitHub에서 미러링하는 항목

Origin은 Git 데이터를 미러링하지만, 모든 GitHub 기능을 포함하진 않습니다:

GitHub Actions는 계속 GitHub에서 실행됩니다. Depot과 Buildkite 통합은 미러가 아닌 Origin 호스팅 저장소에 적용됩니다.

GitHub가 소스 오브 트루스로 남는 경우

저장소가 미러링되는 동안 Origin을 통한 푸시는 GitHub로 전달됩니다. 저장소 설정의 Detach from GitHub는 GitHub 저장소를 변경하지 않고 Origin 사본을 독립형으로 만듭니다.

Cursor Origin에서 풀 리퀘스트 열고 리뷰하는 방법

Origin의 풀 리퀘스트는 다른 Git 호스트와 동일한 브랜치 생성, 푸시, 리뷰 시퀀스를 따릅니다. 우리의 풀 리퀘스트 작동 방식 가이드가 그 시퀀스를 설명합니다.

브랜치를 만들고 변경 사항 푸시하기

작업 브랜치를 만들고 푸시하세요:

git checkout -b my-change
echo "Example change" >> README.md
git add README.md
git commit -m "Add example change"
git push -u origin my-change

Git에서 할 일은 끝났습니다. 다음 명령은 Origin의 차례입니다.

Origin CLI로 풀 리퀘스트 열기

저장소 관련 명령은 origin이라는 Git 원격에서 대상을 추론합니다. origin pr create를 실행하거나 -R owner/repo로 저장소를 직접 지정하세요. 기본적으로 드래프트가 생성되며, 리뷰 준비가 된 상태로 열려면 --status open을 전달하세요.

Cursor Origin 풀 리퀘스트 리뷰

CLI에는 origin pr list, origin pr view, origin pr diff, origin pr checks가 포함됩니다. CI 앱이 구성되지 않은 상태에서 origin pr checks 는 No checks reported.를 출력하고 종료 코드 1로 끝났습니다(테스트 기준).

이 종료 코드는 set -e를 사용하는 셸 스크립트에서 중요합니다. Checks 탭이 비어 있어도 풀 리퀘스트 자체에는 문제가 없더라도 스크립트가 중단될 수 있기 때문입니다.

네 가지 탭을 갖춘 풀 리퀘스트 리뷰 화면. 이미지: 작성자 제공.

웹 보기에서 모든 풀 리퀘스트는 Activity, Commits, Checks, Files Changed의 네 탭을 갖추고 있으며, 리뷰어 요청, 인라인 댓글, 머지 버튼이 제공됩니다. 웹 페이지에서 머지 충돌이 표시되며, origin pr status --conflict-status 는 터미널에서 충돌 상태를 보고합니다.

터미널에서 origin pr merge도 지원합니다. Origin에 호스팅된 저장소에서 생성한 풀 리퀘스트는 Origin에 남고, 미러링된 저장소의 활동은 GitHub로 전송됩니다.

Cursor Origin 팀 액세스와 저장소 권한

Origin 권한은 코드베이스와 저장소 두 수준에서 존재합니다.

Codebase 설정 vs. 저장소 설정

Codebase 설정은 팀 전반에 적용됩니다. Origin 활성화 권한, 저장소 생성, 앱 설치 권한을 관리합니다. 저장소 설정은 단일 저장소 범위에서 General, Permissions, Rules and Protections, Apps를 다루며, Cursor 문서에는 Permissions와 Rules 화면이 개편 중이라고 안내되어 있습니다.

팀원이 Origin을 사용할 수 있는데 특정 저장소를 열지 못한다면, 팀 전역 설정이 아니라 해당 저장소의 권한을 확인하세요.

Internal vs. Private 저장소

접근이 제한된 저장소 유형은 두 가지입니다:

• Internal 저장소는 코드베이스 액세스 권한이 있는 팀 구성원에게 표시됩니다. 
• Private 저장소는 개별 부여 또는 코드베이스 권한을 통해 액세스 권한을 받은 구성원에게만 표시됩니다. 저장소를 private로 전환하면 변경을 수행한 사람은 관리자 권한을 유지합니다.

Cursor Origin 저장소 액세스 확인 방법

origin repo list 명령은 현재 계정에서 볼 수 있는 모든 저장소를 표시합니다. 특정 저장소에 누가 접근할 수 있는지 확인하려면 Settings의 Permissions를 열어보세요.

Cursor Origin 모범 사례

Origin을 사용할 때 반드시 염두에 둘 세 가지가 있습니다:

• 저장소를 삭제하거나 재구성하기 전에 전체 owner/repo 값을 확인하고 원격을 점검하세요. 

• 대상이 확실해질 때까지 -y 사용을 피하세요. 

• Cursor의 권한 페이지는 상충되는 부분이 있으므로, 액세스 변경을 자동화하기 전에 최신 문서를 확인하세요.

Cursor Origin vs. GitHub: 기능 비교

Origin은 Cursor의 에이전트 워크플로와 밀접하게 연계되고, GitHub는 더 넓은 저장소 생태계를 포괄합니다.

Git 호스팅, 풀 리퀘스트, CI/CD

각 섹션을 반복하기보다, 기능 분할의 간단한 버전을 정리하면 다음과 같습니다:

여기서 에이전트 행은 추가 맥락이 필요합니다.

에이전트 워크플로에서 Cursor Origin vs. GitHub

두 플랫폼 모두 에이전트가 저장소를 대상으로 작업할 수 있습니다. Origin은 그 루프를 Cursor 내부에 유지하고, GitHub는 Agents 패널과 Copilot 도구(예: GA된 CLI)를 통해 제공합니다.

Cursor Origin, GitHub, 혹은 둘 다를 사용할 때

• Origin 사용: 저장소가 internal 또는 private이고, 대부분의 에이전트 작업이 이미 Cursor 내부에서 이루어지며, 배포나 CI 구성이 Vercel, Depot, Buildkite로 실행될 수 있을 때.
• GitHub 유지: 프로젝트가 공개되어 있거나, Issues와 Actions가 일상 워크플로의 일부이거나, 팀이 GitHub 앱 마켓플레이스에 의존할 때 기본 호스트로 유지하세요.
• 둘 다 사용: 소스 저장소를 옮기지 않고 Origin의 코드 탐색과 에이전트 워크플로를 활용하고 싶을 때. 미러링은 푸시와 풀 리퀘스트 활동을 GitHub에 연결한 채 동일한 코드를 Origin에서도 사용할 수 있게 합니다.

맺음말

WSL의 새 설치 환경에서 GitHub와 동일한 브랜치, 커밋, 푸시 흐름으로 Origin 풀 리퀘스트를 여는 데까지 진행했습니다. CLI는 Git의 동작 방식을 바꾸지 않았고, Origin의 차이점은 호스팅, 권한, 미러링에서 나타났습니다.

사용해 본 결과, Origin은 GitHub의 완전한 대체보다는 보완재로 보는 것이 적절하겠습니다. 기존 저장소에는 GitHub가 권위(source of truth)로 남을 수 있는 미러링이 가장 현실적인 진입점입니다. 공개 프로젝트와 Actions 중심 워크플로는 아직 옮길 이유가 거의 없습니다.

관련해서, Cursor Automations 가이드는 기존 저장소를 대상으로 실행되는 에이전트 작업을 다룹니다. GitHub가 무엇이며 어떻게 사용하는지에 대한 가이드는 GitHub 워크플로를 더 자세히 설명합니다.