저장소는 바로 옮기지 않았다

Cursor Origin 발표를 읽으며 하루스페이스와 닮았다는 생각이 들었다. 에이전트가 코드를 만들고, PR에서 사람이 확인하고, Preview를 본 뒤 병합하면 운영으로 나가는 흐름 때문이다. 하루스페이스도 대화가 작업으로 이어지고, AI가 초안을 만들고, 사람이 확인한 결과만 공개하는 길을 고민해 왔다.

그렇다고 “우리도 저장소부터 만들자”는 결론은 내리지 않았다. 닮은 것은 흐름이고, 같은 것은 서비스 목적이 아니다. Origin은 코드 호스팅이고 하루스페이스는 신뢰하는 사람들의 대화·아이디어·결과를 이어 주는 협업 공간이다. 모양이 비슷한 배관이라고 커피머신과 소화전을 바로 연결하면 아침이 매우 역동적일 수 있다.

공식 발표에서 세 경로를 따로 그렸다

Cursor 공식 자료를 기준으로 보면 Origin은 세 부분으로 나뉜다.

1. Origin 자체 저장소 — Cursor가 코드, PR과 권한을 호스팅한다.
2. GitHub 동기화 저장소 — Origin에서 보고 댓글·리뷰·병합할 수 있지만 GitHub가 원본으로 남는다.
3. Vercel 앱 — Origin PR에 Preview를 만들고 병합 뒤 Production을 배포한다.

GitLab은 이번 Origin 동기화 발표에 포함되지 않았다. 다만 Vercel 자체는 GitLab과 Merge Request Preview를 지원한다. 그래서 구조는 아래처럼 그리는 편이 정확하다.

Origin 저장소 → Vercel

GitHub ↔ Origin → Vercel

GitLab → Vercel

세 줄을 한 줄로 줄이면 설명은 짧아지지만 나중에 권한 사고 보고서는 길어진다.

출처: Cursor Origin 공식 변경사항, Vercel Git 연동, Vercel GitLab 연동

하루스페이스와 닮은 부분은 승인 가능한 작업 흐름이다

내가 눈여겨본 것은 저장소 브랜드가 아니라 상태 전환이다.

대화·아이디어 → 공개 가능한 작업 → AI 초안 → 검증 → Preview → 사람 승인 → 게시

Origin도 에이전트가 branch와 PR을 만들고 사람이 검토한 뒤 배포로 보낸다. 하루스페이스에서도 AI가 결과를 만들 수 있지만, 공개 경계에서는 사람이 멈춰 확인해야 한다. Preview가 초록색이라는 사실은 내용이 공개 가능한지, 초상권이 확인됐는지, 개인 대화가 섞이지 않았는지 알려주지 않는다. 빌드 서버는 빠르지만 눈치는 아직 사람이 챙겨야 한다.

그래서 하루스페이스의 상태를 코드 배포보다 조금 더 잘게 나누고 싶다.

상태	의미
private	대화와 내부 자료, 공개 파이프라인 밖
proposed	공개 후보로 사람이 선택
generated	AI나 도구가 초안 생성
verified	사실·권리·개인정보·빌드 확인
approved	사람이 게시 승인
published	공개 화면 반영
withdrawn	이력을 보존하고 공개 중지

이 표에서 가장 중요한 칸은 approved다. 자동화는 앞뒤를 빠르게 만들 수 있지만 이 칸을 몰래 점프하게 두면 안 된다.

지금은 GitHub를 원본으로 유지한다

Origin은 early beta다. 공식 발표도 GitHub에서 시작한 저장소는 GitHub를 source of truth로 유지한다고 설명한다. 나는 이 대목이 현실적이라고 봤다. 새로운 인터페이스를 시험하면서도 원본과 복구 경로를 그대로 둘 수 있기 때문이다.

하루스페이스에도 같은 판단을 적용한다.

• 현재 GitHub 저장소와 PR 승인 흐름을 유지한다.
• Vercel Preview와 Production을 분리한다.
• 저장소 공급자를 코드 전체에 직접 박지 않는다.
• GitLab이나 Origin을 붙일 때 어댑터 하나로 추가할 수 있게 한다.
• 병합이 최종 게시 승인이라는 현재 규칙을 보존한다.

공급자 어댑터에는 최소한 아래 정보가 필요하다.

provider, repositoryId, ref, changeId, actor, commitSha, checkStatus, previewUrl

이렇게 하면 GitHub의 PR, GitLab의 Merge Request와 Origin PR을 내부에서는 ‘검토 가능한 변경’이라는 같은 개념으로 다룰 수 있다. 화면에 보이는 버튼 이름보다 상태의 의미를 맞추는 일이다.

처음 떠올린 가정 하나는 접었다

처음에는 AI IDE가 저장소와 배포를 가져가면 GitHub·GitLab의 역할이 빠르게 줄어들 수 있다고 생각했다. 공식 자료를 읽고 이 가정을 한 단계 낮췄다. Origin은 GitHub 동기화를 전면에 두고, 기존 GitHub Actions를 Depot·Buildkite에서 돌리는 길도 제공한다. 지금은 대체보다 흡수와 연결에 가깝다.

이 차이는 제품 판단에서 중요하다. 경쟁사가 새 기능을 냈다고 전체 구조를 복제하면 문제보다 메뉴가 먼저 늘어난다. 나는 하루스페이스에 저장소 화면을 새로 만드는 대신, 현재 공개 과정에서 사람이 어디서 기다리고 어떤 근거로 승인하는지가 잘 보이는지부터 확인하겠다.

작은 실험은 네 가지로 제한한다

1. 공급자 중립 이벤트

   GitHub PR 이벤트를 내부 ChangeRequest 형식으로 변환하고 공급자 이름이 UI 판단에 새지 않는지 본다.

2. Preview와 승인 분리

   Preview 성공 뒤에도 approved가 없으면 게시 경로가 열리지 않는지 자동 테스트한다.

3. 중복 이벤트 방지

   웹훅이 두 번 와도 같은 게시물이 두 번 배포되지 않도록 provider + changeId + commitSha로 멱등성을 확인한다.

4. 철회 경로

   게시 후 문제가 발견되면 이력을 지우지 않고 withdrawn으로 전환되는지 검증한다.

여기에는 실제 사용자 대화, 계정 정보나 내부 보안 설정을 쓰지 않는다. 공개 가능한 더미 콘텐츠와 독립된 테스트 저장소만 사용한다. 실험은 작게, 감사기록은 길게가 오늘의 기준이다.

결론

Cursor Origin은 하루스페이스가 바라보는 방향과 일부 닮았다. 에이전트가 결과를 만들고, 사람이 검토하며, Preview를 거쳐 공개되는 하나의 길이다. 그러나 하루스페이스가 가져와야 할 것은 새 저장소가 아니라 사람이 승인할 수 있는 상태와 공급자를 바꿀 수 있는 연결부다.

그래서 오늘은 저장소를 옮기지 않았다. 대신 어떤 문을 나중에 바꿔 달 수 있을지 표시했다. 새 집을 계약하기 전에 콘센트 위치부터 재본 셈이다. 조금 덜 화려하지만 이쪽이 이삿날 허리를 지켜준다.

오늘 전체 기술·시장 흐름은 하루이슈: 코드 옆에 금리표가 붙었다에 정리했다.