GitHub 다음은 Agent-Native Git이다: Cursor Origin으로 보는 AI 시대의 코드 저장소

개발자에게 Git Repository는 오랫동안 꽤 명확한 역할을 해왔다.

Developer

↓

Code

↓

git commit

↓

GitHub

↓

Pull Request

↓

CI

↓

Review

↓

Merge

GitHub가 크게 성장한 이유도 단순히 Git Repository를 인터넷에 저장했기 때문만은 아니다.

Repository 주변에:

Issue

Pull Request

Review

CI

Release

Permission

Actions

App

Webhook

이라는 Software Development Workflow가 붙었기 때문이다.

그런데 Coding Agent가 개발 과정에 들어오면서 이 구조에 새로운 참여자가 생겼다.

Developer
      │
      ├──── AI Agent
      │       │
      │       ├─ Repository 읽기
      │       ├─ Branch 생성
      │       ├─ 코드 수정
      │       ├─ Test
      │       └─ Pull Request
      │
      ▼
Repository

이제 Repository를 사용하는 주체가 사람만이 아니다.

Agent도 Repository를 읽고,

Branch를 만들고,

Commit하고,

Pull Request를 열고,

Review하고,

자동화 Event를 받아 다시 작업한다.

그렇다면 자연스럽게 질문이 하나 생긴다.

Repository는
사람이 코드를 저장하는 공간으로만
설계되어 있어야 할까?

2026년 8월 17일 Cursor가 공개한 Origin Code Hosting은 이 질문에 꽤 흥미로운 답을 던졌다.

Cursor는 Origin을 직접 “git forge built for agent scale”, 즉 Agent 규모를 염두에 둔 Git Forge라고 설명한다.

현재 Early Beta에서는:

Repository Hosting

Git Push / Pull

Code Browsing

Pull Request

GitHub Sync

Cursor Cloud Agents

Automations

부터 제공하고 있다.

그리고 Cursor는 별도로 Agent-native 기능이 앞으로 추가될 예정이라고 밝히고 있다.

중요한 것은 Git을 새로 만드는 것이 아니다.

Origin도 표준 Git을 사용한다.

바뀌는 것은 Git Repository 주변의 중심 사용자가 누구인가다.

1. GitHub가 없어지는 이야기는 아니다

제목만 보면:

Cursor Origin 등장

↓

GitHub 끝

처럼 보일 수 있다.

현재 단계에서는 전혀 그렇지 않다.

Origin은 아직 Early Beta다.

GitHub가 제공하는:

Issues

Actions 생태계

Marketplace

Security

Release

Packages

수많은 Integration

을 한꺼번에 대체하는 제품도 아니다.

오히려 현재 Origin의 방향은 이렇게 보는 편이 정확하다.

기존 Git Hosting

Developer 중심

에서

Agent-Native Git Hosting

Developer
+
Agent

를 처음부터 함께 고려하는 방향이다.

즉 GitHub의 다음 버전이라기보다 AI Agent 시대에 Repository의 역할이 어떻게 변할지를 보여주는 실험에 가깝다.

2. Cursor Origin이 실제로 제공하는 것

현재 Origin에서는 다음 작업이 가능하다.

Repository 생성

Standard Git Clone

Push

Pull

Code Browse

Code Search

Pull Request 생성

PR Review

PR Merge

GitHub Repository Mirror

Cloud Agent 연결

Automation 연결

Cursor 공식 문서에서도 Origin을 코드를 저장하고 공유하기 위한 Git Forge라고 설명한다.

그리고 중요한 기능 하나가 있다.

Cursor Agent가
Repository 자체를 만들 수 있다.

3. 기존에는 Repository를 사람이 먼저 만들었다

새 프로젝트를 시작한다고 하자.

기존에는 보통:

GitHub

↓

New Repository

↓

Local Clone

↓

프로젝트 생성

↓

Commit

↓

Push

를 한다.

Agent를 사용해도 Repository 자체는 사람이 준비하는 경우가 많았다.

4. Origin에서는 Agent에게 Repository 생성까지 맡길 수 있다

예를 들어 Cursor Agent에게:

새 Swift 프로젝트용
Origin Repository 만들어줘.

이름은 SmartCameraApp.

Private으로 만들고
현재 프로젝트를 remote에 연결한 뒤
initial commit까지 push해줘.

같은 작업을 요청할 수 있다.

공식 문서 기준 Cursor Agent는 필요하면 Origin CLI를 설치하고:

로그인

Repository 생성

Remote 설정

Push

까지 진행할 수 있다.

구조가 이렇게 바뀐다.

Developer

"새 프로젝트 만들어줘."
       │
       ▼
Cursor Agent
       │
       ├─ Repo Create
       ├─ Project Scaffold
       ├─ Commit
       └─ Push
       │
       ▼
Origin

Repository 생성 자체가 Agent Tool Call 중 하나가 되는 것이다.

5. 이것이 Agent-Native라는 말의 첫 번째 의미다

기존 Repository는 Agent 입장에서 보통 외부 시스템이었다.

Coding Agent

↓

GitHub Integration

↓

Repository

였다.

Origin에서는:

Cursor Agent

↓

Origin Repository

↓

Pull Request

가 같은 Cursor 환경 안에서 연결된다.

즉:

Agent

Code Host

Pull Request

Automation

사이의 거리가 짧아진다.

Cursor가 Origin을 소개하면서 “코드가 Agent와 Pull Request 옆에 존재한다”고 표현한 이유가 이 부분이다.

6. 그래도 Git은 그대로다

이 부분은 개발자 입장에서 중요하다.

Origin 전용 Version Control을 배울 필요는 없다.

git clone

git checkout

git commit

git push

git pull

그대로 사용한다.

Clone URL도 일반적인 Git HTTPS 형태다.

https://origin.cursor.com/acme/mobile-app.git

즉:

Git

유지

되고,

Git Hosting Layer

변화

하는 것이다.

7. Origin CLI는 Git을 대체하지 않는다

Cursor는 별도의 origin CLI를 제공한다.

하지만 이것도 Git 자체를 대체하는 CLI는 아니다.

예:

origin auth login

origin repo create mobile-app

origin repo list

origin pr create

같은 Hosting 관리 CLI다.

참고로:

origin

CLI와

agent

Cursor Agent CLI는 서로 다른 도구다.

8. 가장 단순한 새 프로젝트 Workflow

처음부터 Origin을 사용한다면 이런 형태가 된다.

Cursor
  │
  ▼
Agent
  │
  ├─ Repository 생성
  ├─ 프로젝트 생성
  ├─ 초기 코드 생성
  ├─ Test 생성
  └─ Initial Push
  │
  ▼
Origin Repository

그 이후:

Feature Task

↓

Cloud Agent

↓

Branch

↓

Commit

↓

Pull Request

↓

Checks

↓

Review

↓

Merge

로 이어진다.

9. 사람이 Repository를 직접 만들 수도 있다

물론 Web UI도 있다.

cursor.com/codebase

에서:

New

↓

Repo Name

↓

Internal / Private

↓

Create Repo

하면 된다.

그리고 기존 프로젝트라면:

git remote add origin \
https://origin.cursor.com/acme/mobile-app.git

git push -u origin main

정도로 연결할 수 있다.

10. Internal과 Private도 구분된다

Repository를 만들 때 Visibility를 선택할 수 있다.

Internal

Cursor Team에서
Codebase 접근 권한이 있는 구성원

Private

직접 Repository 권한이 부여된 사용자

정도로 구분한다.

팀 단위 Repository라면 이 권한 체계를 먼저 정리하는 것이 좋다.

11. 이미 GitHub를 사용하고 있다면 굳이 이동할 필요가 없다

Origin에서 가장 현실적인 기능 중 하나가 GitHub Mirror다.

기존 Repository:

GitHub

를 그대로 유지하면서:

GitHub
   │
   ▼
Origin Mirror

를 만들 수 있다.

이 경우 GitHub가 Source of Truth다.

12. Mirror는 단순 Import가 아니다

한 번 복사하고 끝나는 구조가 아니다.

현재 공식 문서 기준 다음 정보가 동기화된다.

Git History

Branches

Tags

Pull Requests

그리고 Repository가 변경되면 Origin Mirror도 최신 상태로 유지된다.

PR도 양방향으로 동기화된다.

13. 하지만 모든 GitHub 정보가 오는 것은 아니다

여기서 중요한 제한이 있다.

현재 GitHub Mirror에는:

GitHub Issues

GitHub Actions Workflow

GitHub Actions Secrets

가 같이 복사되지 않는다.

즉:

GitHub

Issues
Actions
Secrets
Source of Truth

을 유지하면서

Origin

Code Browse
Search
Agent Workflow
PR Interface

를 추가하는 구조가 가능하다.

14. 실제 도입은 이 방식부터 시작하는 것이 안전하다

기존 회사 Repository를 당장 Origin으로 이전하기보다:

GitHub
  │
  │ Source of Truth
  ▼
Origin Mirror
  │
  ▼
Cursor Agent

구조로 먼저 사용해볼 수 있다.

이게 상당히 현실적이다.

15. 기존 CI도 그대로 유지할 수 있다

GitHub Mirror를 사용하는 경우 기존:

GitHub Actions

을 그대로 사용할 수 있다.

즉:

Cursor Agent

↓

Origin

↓

GitHub PR

↓

GitHub Actions

↓

Checks

↓

Review

가 가능하다.

Agent 사용을 위해 CI 인프라까지 한 번에 바꿀 필요가 없다.

16. 이것이 Migration 전략으로 중요한 이유

새 개발 플랫폼을 도입할 때 가장 위험한 방식은:

이번 주부터

GitHub 제거

CI 변경

Agent 도입

Repository 이전

Permission 변경

을 동시에 하는 것이다.

Origin Mirror를 사용하면:

GitHub 유지

+

Origin 추가

부터 시작할 수 있다.

17. 충분히 검증한 뒤 Origin을 Source of Truth로 바꿀 수도 있다

GitHub Mirror Repository에는 Detach from GitHub 기능이 있다.

Detach하면:

GitHub
        X Sync
Origin

이 되고,

Origin Copy가 독립 Repository가 된다.

그 순간부터:

Origin

=

Source of Truth

가 된다.

기존 GitHub Repository 자체는 삭제되지 않는다.

18. 그래서 세 단계 Migration이 가능하다

STEP 1

GitHub Only

STEP 2

GitHub
  ↓
Origin Mirror

STEP 3

Origin

처럼 점진적으로 이동할 수 있다.

19. 하지만 대부분의 팀이 당장 STEP 3으로 갈 이유는 없다

Origin은 현재 Early Beta다.

그래서 기존 Production Repository라면:

GitHub Source of Truth

+

Origin Mirror

부터 실험하는 편이 훨씬 합리적이다.

특히:

CI

Security

Release

Compliance

GitHub Apps

의존도가 높은 회사는 더 그렇다.

20. Origin에서 가장 흥미로운 부분은 Cloud Agent다

Repository Hosting만 보면:

GitHub

GitLab

Bitbucket

과 크게 다르지 않아 보인다.

하지만 Origin의 진짜 방향은 Repository와 Cursor Agent가 같은 공간에 있다는 데 있다.

Cursor Cloud Agent는 Origin Repository에서:

Clone

Branch

Commit

Push

Pull Request

를 수행할 수 있다.

21. 예를 들어 Issue 대신 Agent Task부터 시작할 수 있다

Developer:

로그인 화면의
Session Refresh Race Condition을 조사해줘.

원인을 찾으면
Regression Test를 추가하고

기존 Public API를 변경하지 않는 범위에서
수정한 뒤 PR을 만들어줘.

Cloud Agent:

Repository Clone

↓

관련 코드 탐색

↓

Branch 생성

↓

Test 작성

↓

수정

↓

Commit

↓

Push

↓

Pull Request

이 된다.

사람은 최종 PR로 들어간다.

22. Repository가 Agent의 작업장이 된다

기존에는 Repository를 이렇게 생각했다.

Repository

=

Code Storage

Agent 시대에는 조금 달라진다.

Repository

=

Agent Workspace의
지속 가능한 경계

가 된다.

Agent Session은 사라져도:

Branch

Commit

PR

Checks

Review

가 Repository에 남는다.

23. Agent에게 장기 Memory를 무조건 줄 필요도 없다

Agent가 매번 모든 과거 Conversation을 기억하는 대신:

Repository

↓

Code

AGENTS.md

Commit History

PR

Tests

를 읽게 할 수 있다.

즉 Repository 자체가 Agent의 중요한 외부 기억 장치가 된다.

24. Source Control Event가 Agent Trigger가 된다

Origin은 Cursor Automations와 연결된다.

예를 들어:

Push to main

또는:

Pull Request opened

Pull Request pushed

같은 Event에서 Cloud Agent를 실행할 수 있다.

구조:

Git Event

↓

Cursor Automation

↓

Cloud Agent

↓

Repository 분석

↓

결과

이다.

25. 여기서 Repository가 Agent Queue 역할까지 하기 시작한다

예를 들어:

PR Opened

↓

Review Agent

↓

Architecture Violation 분석

또는:

Push to main

↓

Documentation Agent

↓

변경된 API 문서 업데이트

같은 Workflow를 만들 수 있다.

26. CI와 Agent Automation은 역할이 다르다

중요한 구분이다.

CI

결정론적 검증

Agent Automation

해석 / 분석 / 변경

이다.

예:

Compiler

Test

Lint

는 CI가 맡는다.

반면:

이 PR에서
Architecture Risk가 있는가?

는 Agent가 분석할 수 있다.

27. 추천 PR Pipeline

Agent / Human
      │
      ▼
    Branch
      │
      ▼
 Pull Request
      │
      ├─────────────┐
      ▼             ▼
     CI         Review Agent
      │             │
      └──────┬──────┘
             ▼
       Human Review
             │
             ▼
           Merge

이 정도가 자연스럽다.

28. Origin PR 자체도 꽤 일반적인 형태다

현재 Origin PR에는:

Activity

Commits

Checks

Files Changed

탭이 있다.

그리고:

Reviewer 요청

PR Comment

Line Comment

Review

Merge

도 지원한다.

즉 개발자에게 익숙한 Pull Request Workflow를 크게 바꾸지 않는다.

29. Agent-Native라고 PR을 없애는 것이 아니다

오히려 반대다.

Agent가 코드를 만드는 속도가 빨라질수록:

Pull Request

Review

Checks

Protection

같은 경계가 더 중요해진다.

Agent가 바로 Main에 Push하도록 만드는 것이 Agent-Native는 아니다.

30. Agent에게도 Branch 전략을 적용한다

예:

main

에 바로 쓰지 않는다.

Agent Task:

agent/fix-session-race

↓

Commit

↓

PR

↓

CI

↓

Review

↓

Merge

를 유지한다.

31. Repository Rule과 Protection도 존재한다

Origin Repository Settings에는:

Permissions

Rules and Protections

Apps

영역이 있다.

Branch Rule과 Merge Protection을 설정하는 구조다.

다만 현재 Early Beta이므로 이 UI와 제공 범위는 계속 바뀔 수 있다.

Production 도입이라면 이 부분을 반드시 다시 확인해야 한다.

32. Agent가 많아질수록 Permission이 더 중요해진다

개발자 5명일 때와:

Developer × 5

Agent까지 포함됐을 때는 다르다.

Developer × 5

+

Cloud Agent × N

+

Automation

+

Internal App

이 Repository를 사용한다.

그래서 앞으로 Source Control의 Permission 모델도:

Human

만 고려하면 부족하다.

33. Origin API도 이미 App을 전제로 한다

Origin에는 REST API가 있다.

App은:

App JWT

Installation Access Token

Scope

Webhook

구조를 사용한다.

즉 Repository와 상호작용하는 주체를 처음부터:

User

App

Service

까지 고려하고 있다.

34. 이것은 Agent 시대 Source Control에서 중요한 변화다

앞으로 Repository Actor는:

김개발자

뿐 아니라:

Review Agent

Release Agent

Migration Agent

Security Agent

Documentation Agent

가 될 수 있다.

Repository History에서 누가 또는 무엇이 변경을 만들었는지 구분하는 것이 더 중요해진다.

35. 이전에 다룬 Agent Provenance와도 연결된다

Agent가 PR을 만들었다면 앞으로는 다음 정보가 중요해질 수 있다.

Human Initiator

Agent Identity

Agent Session

Runtime

Policy

Validation

Human Reviewer

Origin이 이 모든 Provenance 체계를 완성했다는 의미는 아니다.

하지만 Agent가 Repository의 First-class Actor가 되는 방향에서는 이런 Metadata가 자연스럽게 필요해진다.

36. Agent-Native Repository의 중요한 조건

단순히:

Agent가 Git Push 가능

하다고 Agent-Native라고 부르기는 부족하다.

더 발전하면 다음이 필요하다.

Agent Identity

Agent Permission

Agent Trigger

Agent Context

Agent Review

Agent Provenance

Agent Budget

Human Gate

이다.

Cursor도 현재 Origin의 기본 Git Forge 기능을 먼저 제공하고 추가적인 Agent-native 기능은 이후 제공할 예정이라고 밝히고 있다.

즉 이 부분은 아직 진행형이다.

37. Origin의 현재 모습보다 방향이 더 재미있다

현재 기능만 놓으면:

Repo

PR

Code Browse

GitHub Sync

다.

굉장히 익숙하다.

하지만 이게 Cursor 안에 있다는 것이 중요하다.

Editor

Agent

Cloud Agent

Automation

Repository

Pull Request

가 한 제품 경계 안으로 들어오기 시작했다.

38. Coding Environment가 하나의 Vertical Stack으로 변한다

기존 개발 Stack:

IDE

↓

Git

↓

GitHub

↓

CI

↓

AI Tool

각각 별도 제품이었다.

Cursor가 가려는 방향을 단순화하면:

Cursor

├─ Editor
├─ Agent
├─ Cloud Agent
├─ Automation
├─ Code Hosting
└─ Pull Request

처럼 된다.

CI와 Deployment는 외부 Integration을 붙인다.

39. Origin-hosted Repository에서는 외부 CI도 붙일 수 있다

현재 공식 Integration에는:

Vercel

Depot

Buildkite

가 있다.

예를 들어:

Origin Push

↓

Buildkite

↓

Build / Test

↓

Origin PR Check

같은 구조가 가능하다.

40. Web 프로젝트라면 Vercel Preview도 연결할 수 있다

구조:

Agent

↓

UI 수정

↓

Origin PR

↓

Vercel Preview

↓

Human Review

이다.

Agent가 UI를 만든 뒤 사람이 Preview를 보고 승인하는 흐름으로 연결할 수 있다.

41. GitHub Mirror에서는 Integration 구조가 조금 다르다

중요하다.

현재 공식 문서 기준:

Depot

Buildkite

의 Origin Integration은 Origin-hosted Repository를 대상으로 한다.

GitHub Mirror Repository는 기존 GitHub CI를 유지한다.

즉:

GitHub Mirror

↓

GitHub Actions

구조다.

Migration 시 이 차이를 알아야 한다.

42. 그래서 처음부터 CI까지 Origin으로 옮길 필요가 없다

43. 개인 개발자가 가장 쉽게 시험하는 방법

기존 Side Project 하나를 선택한다.

GitHub Side Project

↓

Origin에서:

Sync from GitHub

한다.

그러면:

Git History

Branches

Tags

PR

가 Origin에서 보인다.

그 Repository에 Cloud Agent를 붙여본다.

44. 첫 번째 Agent Task는 작은 것으로 한다

예:

현재 프로젝트를 분석해서

사용하지 않는 Dependency가 있는지 확인하고

바로 제거하지 말고
후보와 근거만 정리해줘.

먼저 Read-heavy Task를 시킨다.

45. 그다음 작은 변경

Networking Layer의
중복 Error Mapping을 정리해줘.

Public API는 변경하지 말고

Unit Test를 추가한 뒤
PR을 만들어줘.

이 정도가 좋다.

46. PR을 실제 사람이 Review한다

확인할 것은:

Agent가 변경 범위를 지켰는가?

불필요한 Dependency를 추가했는가?

Test는 실제로 실행됐는가?

Architecture를 깨지 않았는가?

PR 설명이 Diff와 일치하는가?

다.

Agent 사용법보다 Review 규칙이 더 중요하다.

47. 그다음 Automation을 하나 붙인다

예:

PR Opened

↓

Agent:

이 PR에서

Architecture Boundary 위반

새 외부 Dependency

Public API 변경

Test 누락

을 확인하고
수정하지 말고 Review만 작성해.

이 정도가 첫 Automation으로 적당하다.

48. 처음부터 Agent가 Agent를 수정하게 만들지 않는다

예:

Coding Agent
      ↓
PR
      ↓
Review Agent
      ↓
자동 수정
      ↓
다시 Review Agent
      ↓
자동 수정

Loop를 만들면 복잡해진다.

처음에는:

Agent

↓

Recommendation

↓

Human

으로 둔다.

49. 안정화되면 일부만 자동 수정한다

예:

Formatting

Lint

Documentation

Generated Code

처럼 위험이 낮은 작업부터 자동화한다.

반대로:

Authentication

Payment

Database Migration

Security

같은 영역에는 Human Gate를 강하게 둔다.

50. Agent Repository에도 Risk Tier가 필요하다

예:

Tier 0

Docs
Formatting

Tier 1

UI
Simple Refactor

Tier 2

Business Logic
Network
Database

Tier 3

Auth
Payment
Security
Release

Agent가 어느 수준까지 자동 Push/PR/수정할 수 있는지를 다르게 한다.

51. Repository 자체가 Agent Policy Boundary가 된다

예:

mobile-app

Agent Write
PR Required
Human Merge

security-config

Agent Read Only

docs

Agent Write
Auto Merge 가능

처럼 Repository마다 다르게 운영할 수 있다.

52. Monorepo에서는 더 세분화해야 한다

큰 Monorepo라면 Repository 하나의 권한만으로는 부족할 수 있다.

향후 Agent-native Source Control에서 중요한 기능은:

Path Scope

Component Ownership

Agent Permission

Risk-aware Approval

같은 영역이 될 가능성이 높다.

현재 Origin이 이 모든 기능을 제공한다는 의미는 아니다.

Agent가 대규모로 Repository를 사용할 때 자연스럽게 필요한 방향이다.

53. GitHub가 만들어낸 Pull Request 문화도 다시 바뀔 수 있다

기존 PR은 사람이 만든다.

Developer

↓

PR

Agent 시대:

Agent 1 ─┐
Agent 2 ─┼→ PR
Agent 3 ─┘

가 될 수 있다.

문제는 PR 개수다.

54. 코드를 만드는 비용보다 Review 비용이 커질 수 있다

Agent는 여러 작업을 병렬로 수행할 수 있다.

사람은 그렇지 않다.

Agent

PR 20개 생성

↓

Reviewer

20개 확인

이 되면 Repository의 병목은 Commit이 아니라 Review가 된다.

55. 그래서 Agent-Native Git의 핵심은 PR을 많이 만드는 것이 아니다

더 중요한 것은:

가치 없는 PR을
사람에게 올리지 않는 것

이다.

예:

Agent Task

↓

Build

↓

Test

↓

Architecture Check

↓

Risk Check

↓

PR

처럼 사전 검증을 강화해야 한다.

56. Agent PR에는 더 강한 Evidence가 필요해질 수 있다

예:

Agent

Cursor Cloud Agent

Task

MOB-1831

Changed Files

8

Build

PASS

Tests

44 / 44

External Dependency

NONE

Architecture Check

PASS

정도가 PR 상단에 있으면 Reviewer가 판단하기 쉽다.

57. Repository가 Agent의 실행 기록을 담는 곳이 된다

Agent Conversation 전체를 Git에 저장할 필요는 없다.

하지만:

Task

Commit

PR

Checks

Review

Merge

는 남는다.

이것만으로도 Agent 작업을 상당 부분 추적할 수 있다.

58. Cursor Origin API가 중요한 이유도 여기에 있다

Origin이 UI만 있는 Repository Hosting이라면 Agent Platform 확장이 제한된다.

하지만 Origin은 API와 Webhook을 제공한다.

그래서 내부 Platform에서:

PR Created

↓

Webhook

↓

Security Agent

↓

Result

↓

PR Check

같은 구조를 만들 수 있다.

59. 내부 Agent Platform과도 연결할 수 있다

예:

Origin

↓

Webhook

↓

Company Agent Gateway

├─ Security Agent
├─ Architecture Agent
└─ License Agent

↓

Checks

↓

Origin PR

Cursor Agent만 사용해야 하는 구조로 볼 필요는 없다.

API가 있으면 조직 내부 자동화도 붙일 수 있다.

60. 여기서 Source Control이 Agent Control Plane 일부가 된다

기존 Source Control:

Code 저장

↓

사람 Collaboration

↓

CI Trigger

였다.

Agent 시대:

Code 저장

+

Human Collaboration

+

Agent Trigger

+

Agent Identity

+

Agent Workflow

+

Verification

까지 확대된다.

61. 그래서 “GitHub 다음”이라는 제목의 진짜 의미

GitHub라는 회사가 사라진다는 뜻이 아니다.

GitHub 역시 이미 Coding Agent와 AI Workflow를 빠르게 확장하고 있다.

핵심 질문은 이것이다.

Git Forge가
사람 중심 Collaboration Tool에서

Human + Agent Collaboration Platform으로
어떻게 바뀌는가?

이다.

Cursor Origin은 그 변화가 어떤 모습일지 보여주는 사례다.

62. Git Repository의 중심 Actor가 바뀌기 시작했다

과거:

Human

↓

Git

지금:

Human
+
Agent

↓

Git

앞으로:

Human

Agent

Automation

Service Account

Review Agent

Release Agent

↓

Git Forge

가 될 수 있다.

63. 이때 Repository UX도 달라질 수밖에 없다

사람에게 좋은 UX:

Browse

Diff

Comment

Review

Agent에게 좋은 UX:

API

Structured Metadata

Webhook

Permission Scope

Deterministic Checks

Machine-readable Policy

이다.

Agent-native Git Forge라면 둘 다 잘 제공해야 한다.

64. Cursor Origin이 아직 보여주지 않은 것도 많다

현재 Early Beta라는 점을 잊으면 안 된다.

앞으로 지켜볼 부분은:

Agent Identity

Agent Provenance

더 세밀한 Permission

Advanced Ruleset

Security Scanning

Package 생태계

Issue Tracking

Enterprise Governance

Agent-specific Review

등이다.

현재 기능만 보고 GitHub와 완성도 비교를 하는 것은 너무 이르다.

65. 지금 Origin을 사용해볼 만한 사람

다음 조건이라면 꽤 흥미롭다.

Cursor Agent를 자주 사용

Cloud Agent 활용

Side Project 또는 신규 프로젝트

GitHub와 병행 실험 가능

Agent Automation에 관심

하는 경우다.

66. 아직 Production 이전을 서두르지 않아도 되는 사람

GitHub Actions 복잡

GitHub Apps 많음

Enterprise Compliance 중요

Security Integration 많음

Release Pipeline 복잡

한 팀이다.

이 경우:

GitHub

+

Origin Mirror

가 더 현실적이다.

67. 가장 추천하는 도입 구조

현재 시점에는 이렇게 시작하는 것이 좋다.

             Developer
                 │
                 ▼
            Cursor Agent
                 │
                 ▼
            Origin Mirror
                 ▲
                 │
              GitHub
                 │
                 ├─ Issues
                 ├─ Actions
                 └─ Existing Apps
                 │
                 ▼
                CI
                 │
                 ▼
           Human Review

GitHub를 버리지 않는다.

Origin의 Agent Workflow만 먼저 사용한다.

68. 신규 Side Project라면 Origin-only도 실험할 만하다

새 프로젝트라면:

Cursor Agent

↓

Origin Repo

↓

Cloud Agent

↓

PR

↓

Buildkite / Depot / Vercel

↓

Review

처럼 처음부터 Agent 중심으로 구성해볼 수 있다.

Side Project에서 경험해보기 좋은 구조다.

69. Agent에게 Repository 생성까지 맡기는 것도 재미있다

예:

새 iOS 프로젝트를 만들어줘.

Swift 6 기반.

SwiftUI + Observation 사용.

Packages/AppModules에
Local Swift Package 구조를 만들고

AGENTS.md도 추가해.

Origin에 Private Repository를 생성해서
initial commit을 push해줘.

이제 Agent의 작업 범위가:

Code 작성

에서:

Project Bootstrap

+

Repository Bootstrap

까지 넓어진다.

70. 이것이 개발 Workflow에 주는 변화

과거 새 프로젝트 시작:

Repository 만들기

Project 만들기

Folder 만들기

CI 만들기

README

첫 Commit

Agent 시대:

Goal 설명

↓

Agent Bootstrap

↓

Human Review

로 줄어들 수 있다.

71. 하지만 Source of Truth는 여전히 명확해야 한다

Agent가 많아질수록 오히려 이것이 중요하다.

Mirror를 쓴다면:

GitHub

= Source of Truth

Origin-only라면:

Origin

= Source of Truth

를 명확하게 한다.

두 Repository가 독립적으로 수정되는 상태를 만들면 안 된다.

72. Migration 중에는 특히 조심한다

나쁜 구조:

GitHub에 Push

+

Origin에도 별도 Push

+

서로 다른 Branch

좋은 구조:

Mirror

또는 명확한:

Single Source of Truth

이다.

73. Agent도 어디에 Push해야 하는지 추측하면 안 된다

Repository Policy에:

Source of Truth: GitHub
Origin: Mirror

또는:

Source of Truth: Origin

을 명확하게 둔다.

Agent가 잘못된 Remote에 독립적인 Commit History를 만들지 않게 한다.

74. Agent 시대 Git 운영 규칙 예시

# Repository Policy

## Source of Truth

Origin is the source of truth.

## Branching

Agents must create task branches.

Direct push to main is prohibited.

## Pull Requests

All agent changes require a pull request.

## Validation

Before requesting review:

- build
- unit tests
- lint

must be executed.

## Dependencies

Agents must not add external dependencies
without explicit approval.

## Merge

Only humans may merge Tier 2+ changes.

이런 Machine-readable에 가까운 Repository Policy가 더 중요해진다.

75. 앞으로 Git Forge의 경쟁력이 달라질 수도 있다

지금까지 Git Hosting 경쟁력은:

Developer 수

Repository 수

CI

Marketplace

Enterprise 기능

이었다.

Agent 시대에는 여기에:

Agent Latency

Agent Context Access

Agent Permission

Automation

Agent Review

Provenance

Agent API

Machine-readable Repository

가 추가될 수 있다.

76. Repository가 AI Agent의 Operating System 비슷한 역할을 할 수도 있다

Agent는 매번 새로운 Session으로 시작한다.

하지만 Repository에는:

Code

History

Policy

Tests

PR

Artifacts

가 남는다.

Agent는 이걸 읽고 현재 상태를 이해한다.

이 관점에서는 Repository가 Agent에게 일종의 Persistent Workspace 역할을 한다.

77. 가장 중요한 변화는 Code Hosting과 Agent Runtime의 거리가 줄어드는 것이다

과거:

Agent Vendor

↓

Integration

↓

Git Provider

↓

CI Provider

여러 시스템 사이를 건너갔다.

Origin이 제시하는 방향은:

Agent

↓

Repository

↓

PR

↓

Automation

을 같은 Cursor 환경에 더 가깝게 배치하는 것이다.

78. 그래서 Cursor가 Repository Hosting까지 들어온 것은 자연스럽다

Cursor가 단순 Editor라면 Repository Hosting은 이상해 보인다.

하지만 Cursor를:

AI Software Development Platform

으로 보면 자연스럽다.

Agent가:

코드를 읽고

수정하고

Branch를 만들고

PR을 만들고

다시 Review

하려면 Repository가 Agent Workflow의 핵심 Infrastructure이기 때문이다.

79. IDE 경쟁에서 Developer Platform 경쟁으로 이동한다

초기 Cursor의 질문은:

VS Code보다
AI Coding을 잘할 수 있는가?

에 가까웠다.

Origin이 등장하면 질문이 달라진다.

Editor부터

Agent

Repository

PR

Automation까지

하나의 AI Development Workflow로
묶을 수 있는가?

가 된다.

이 변화가 Origin의 Repository 기능 자체보다 더 중요하다.

80. 마무리

GitHub는 개발자가 코드를 저장하는 서비스를 넘어 Software Collaboration Platform을 만들었다.

Repository

+

Pull Request

+

Review

+

CI

+

Issue

+

Automation

이 하나의 개발 표준이 됐다.

그런데 Coding Agent가 개발팀에 들어오면서 새로운 질문이 생긴다.

이 Platform은
사람뿐 아니라 Agent가
하루 수백 번 접근하는 환경에도
잘 맞는가?

Cursor Origin은 여기에 직접 답하려는 제품이다.

현재는 아직:

Repository

Pull Request

Code Browse

GitHub Mirror

Integration

Cloud Agent

Automation

을 제공하는 Early Beta다.

따라서 지금 당장 GitHub를 대체할 제품이라고 말하기는 어렵다.

오히려 현재 가장 현실적인 사용법은:

GitHub

Source of Truth

을 유지하면서

Origin Mirror

+

Cursor Agent

를 붙여보는 것이다.

그리고 신규 프로젝트나 Side Project에서:

Agent

↓

Repository 생성

↓

코드 생성

↓

Branch

↓

PR

↓

CI

↓

Human Review

라는 Agent-first Workflow를 실험해볼 수 있다.

중요한 것은 Repository가 어디에 저장되느냐가 아니다.

더 큰 변화는 Repository를 사용하는 주체가 바뀌고 있다는 것이다.

과거

Human
  ↓
Repository

에서

현재

Human
Agent
  ↓
Repository

그리고 앞으로는:

Human
Coding Agent
Review Agent
Security Agent
Automation
Service Account
        │
        ▼
     Git Forge

가 될 수 있다.

그 순간 Git Forge는 단순한 코드 저장소가 아니다.

사람과 Agent가 함께 Software를 만드는 Control Plane에 가까워진다.

그래서 Cursor Origin에서 봐야 할 것은 “GitHub보다 기능이 많나?”가 아니다.

더 흥미로운 질문은 이것이다.

Agent가 코드의 주요 생산자가 되는 시대에
Repository는 어떤 모습이어야 하는가?

Origin은 아직 그 답을 완성하지 않았다.

하지만 방향은 꽤 명확하다.

GitHub가 사람 중심 Software Collaboration의 표준을 만들었다면, 다음 Git Forge 경쟁은 사람과 Agent가 같은 Repository에서 어떻게 안전하고 빠르게 함께 일할 것인가를 두고 벌어질 가능성이 높다.

그리고 Cursor는 이제 그 경쟁을 Editor 밖에서 시작했다.

참고 자료

Cursor — Origin Code Hosting, 2026-08-17
Origin Early Beta 공개와 Repo·Pull Request·Code Browsing·GitHub Sync, 그리고 Agent Scale을 위한 Git Forge라는 방향을 발표한 공식 Changelog.
Cursor Docs — Origin
Origin Repository 생성, Standard Git, PR, Code Search, GitHub Mirror, Cloud Agents, Automations, Integration 등 현재 제공 기능을 정리한 공식 문서.
Cursor Docs — Mirror a GitHub repository
GitHub를 Source of Truth로 유지하면서 History·Branch·Tag·PR을 Origin에 동기화하는 구조와 Issues·Actions·Secrets가 Mirror 대상이 아니라는 현재 제한을 설명한다.
Cursor Docs — Origin Integrations
Origin Repository를 Cursor Automations와 Cloud Agents에 연결하는 방법과 Push·PR Event 기반 Agent 실행 구조를 설명한다.
Cursor Docs — Pull Requests
Activity·Commits·Checks·Files Changed, Reviewer·Line Comment·Review·Merge 등 현재 Origin PR Workflow를 설명한다.
Cursor Docs — Origin CLI
origin auth, origin repo, origin pr, origin ruleset 등 Repository와 PR을 Terminal에서 관리할 수 있는 CLI 구조를 설명한다.

핵심 참고 포인트

2026년 8월 현재 Cursor Origin은 Early Beta다. Repository 생성·표준 Git Push/Pull·Code Browsing·Pull Request·GitHub Mirror·Cursor Cloud Agent·Automation 등을 사용할 수 있지만 Cursor가 예고한 추가적인 Agent-native 기능은 아직 앞으로 확장될 영역이다.

기존 GitHub Repository를 Mirror하면 GitHub가 Source of Truth로 유지되며 Git History·Branch·Tag와 Pull Request가 Origin에 동기화된다. 반면 GitHub Issues와 Actions Workflow·Secret은 Origin으로 복사되지 않는다. 따라서 기존 회사 프로젝트에서는 GitHub를 제거하기보다 GitHub + Origin Mirror + Cursor Agent 형태로 먼저 검증하는 접근이 현실적이다.

Origin-hosted Repository에서는 Cursor Cloud Agent가 Clone·Branch·Commit·Push·PR 생성을 수행할 수 있고, Source Control Event를 Cursor Automation의 Trigger로 사용할 수 있다. 이 때문에 Origin의 핵심 가치는 단순 Code Hosting보다 Repository와 Agent Runtime·Automation 사이의 거리를 줄이는 것에서 찾는 편이 적절하다.

또 Origin은 Standard Git을 그대로 사용한다. 따라서 Agent-Native Git이라는 표현은 새로운 Version Control System을 의미하는 것이 아니라 Git Repository 주변의 Hosting·Permission·PR·Automation·Agent Workflow를 Agent가 First-class Actor인 환경에 맞게 다시 설계하는 방향을 의미한다.

이경규

iOS 앱 개발자

이전 포스트

혼자 Agent에게 시키는 시대가 끝난다: Slack Code로 만드는 Human + AI 개발팀

다음 포스트