🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Cursor 공동창업자 Michael Truell의 Compile 26 오프닝 키노트는 Cursor가 단순 AI 코딩 보조 도구를 넘어 에이전트 중심 개발 환경, 클라우드 실행, Origin Git 플랫폼, 자체 코딩 모델로 확장하고 있음을 보여준다.

📌 핵심 요점

1. Cursor는 이미 경쟁이 치열했던 AI 코딩 시장에서 출발했지만, 창업팀이 실제로 매일 쓰고 싶은 개발 환경이 없다는 문제의식에서 제품을 만들기 시작했다.
2. 초기 사용자 반응은 강하지 않았지만, 소수의 개발자가 매일 사용하면서 피드백 루프가 생겼고, Cursor는 개발자가 개발자를 위해 만드는 제품 중심 회사라는 정체성을 강화했다.
3. Cursor 3는 Tab 같은 보조 기능보다 에이전트 사용이 훨씬 커진 흐름을 반영해, 화면 구조와 사용 경험을 agent-first 개발 환경으로 재편하고 있다.
4. Cursor는 로컬에서 짧은 작업을 돕는 에이전트에서 벗어나, 자체 컴퓨터와 개발환경을 가진 클라우드 에이전트가 며칠 단위의 기능 구현·버그 수정·검증을 맡는 방향을 제시했다.
5. 발표의 큰 축은 모바일 앱, Origin이라는 에이전트 네이티브 Git 플랫폼, 그리고 Composer 이후 더 큰 규모의 자체 모델 개발 계획으로 정리된다.

🧩 배경과 문제 정의

• Cursor는 AI 코딩 시장이 이미 스타트업, 빅테크, AI 연구소로 붐비던 시기에 출발했지만, 창업팀이 실제로 매일 쓰고 싶은 개발 도구는 시장에 충분하지 않다고 보았다.
• 초기 문제의식은 개발자가 생산성을 크게 잃지 않으면서도 일상적으로 사용할 수 있는 AI 기반 개발 환경을 만드는 데 있었다.
• 첫 사용자 반응은 강하지 않았지만, 소수의 일상 사용자가 남아 제품 개선 루프를 만들었고, Cursor는 이를 바탕으로 계속 형태를 바꿔왔다.
• 최근 전환의 핵심은 단순한 보조 기능 중심 IDE에서 agent-first 개발 환경, 클라우드 실행, SDK·플러그인·CLI, 자체 코딩 모델까지 포함하는 개발 플랫폼으로 확장되는 흐름이다.
• Cursor가 제시하는 장기 방향은 에이전트가 짧은 작업을 보조하는 수준을 넘어, 동료 엔지니어처럼 프로젝트, 버그 수정, 기능 구현을 맡고 완료·검증된 결과를 돌려주는 구조다.
• 발표에 등장하는 사용자 비율, 성능 향상, 신뢰성 수치 등은 발표 내 설명 기준이며, 외부 검증이 필요한 지표로는 별도 확인이 필요하다.

🕒 시간순 섹션별 상세정리

1. Cursor의 출발과 AI 코딩 시장에 대한 초기 부담

• Cursor 팀은 2022년 1월부터 AI 관련 작업을 시작했고, 첫 Cursor 버전은 2023년 초에 나왔으며, AI 업계 기준으로는 짧은 시간 안에도 기술 환경이 빠르게 바뀌었다고 보여준다 [00:20]
• 창업팀은 네 명의 젊은 프로그래머로 구성됐고, 개발자 도구와 AI 코딩에 관심이 있었지만 이미 많은 스타트업, 빅테크, AI 연구소가 경쟁 중이라 진입 여지가 작다고 느꼈다 [00:53]

2. 직접 쓰기 위한 프로토타입과 첫 사용자 반응

• 시장에 있던 도구들은 창업팀이 정말 쓰고 싶은 개발 환경의 기준을 충족하지 못했고, 팀은 약 2주 동안 집중적으로 프로토타입을 만들며 자체 개발 환경을 목표로 삼았다 [01:41]
• 초기 목표는 기존 도구보다 생산성을 크게 떨어뜨리지 않는 개발 환경이었고, 오픈소스 코드 에디터 구성요소, 언어 서버 통합, 원격 SSH, Copilot 통합까지 직접 엮어 최소 사용 가능한 상태에 도달했다 [02:08]

3. 개발자를 위한 제품 중심 문화와 최근 3개월의 전환

• Cursor의 핵심 정체성은 개발자가 개발자를 위해 만드는 제품 중심 회사이며, 제품 개선의 기준은 창업팀과 커뮤니티 개발자 모두에게 실제로 유용한지에 놓여 있다 [03:47]
• 첫 프로토타입의 코드와 화면 요소는 현재 코드베이스와 제품에 남아 있지 않고, 기술 변화 속도에 맞춰 Cursor의 코드, UI, 제품 방향이 여러 차례 교체됐다 [04:18]

4. Cursor 3의 agent-first 개발 환경

• 발표에 따르면 현재 Cursor 사용자의 95% 이상은 Cursor를 주로 에이전트로 사용하고, 요청 기준으로도 에이전트 사용량이 Tab 같은 보조 기능보다 약 5배 많으며, 코드 라인 기준 격차는 훨씬 더 크다 [05:10]
• Cursor 3의 화면 구조는 왼쪽과 중앙에 에이전트를 배치한 agent-first 형태로 바뀌었고, 동시에 파일 편집, 원격 SSH, 언어 서버, 린팅 같은 전문 개발 환경 기능은 유지된다 [05:45]

5. 로컬 보조 작업에서 클라우드 기반 장기 위임으로 이동

• 많은 개발자는 아직 에이전트에게 30분에서 1시간 단위의 작은 작업을 맡기고, 로컬 컴퓨터에서 3~5개의 에이전트를 동시에 돌리며 같은 코드베이스에서 도구 호출을 처리한다 [07:06]
• 로컬에서 여러 에이전트가 같은 코드베이스 위에서 충돌하는 방식은 장기적 구조가 아니며, 에이전트는 동료 엔지니어처럼 전체 기능, 버그 수정, 프로젝트를 맡아 며칠간 작업한 뒤 완료·테스트된 결과를 돌려줘야 한다고 드러난다 [07:22]

6. SDK·플러그인·CLI와 자체 모델 개발의 확대

• Cursor는 사람이 직접 쓰는 닫힌 제품에서 팀과 비즈니스의 핵심 인프라가 되는 플랫폼으로 이동하고 있으며, 사용자는 업무 중심 도구를 수정, 제어, 확장할 필요가 있다 [08:05]
• SDK는 Cursor를 제품 UI뿐 아니라 프로그래밍 언어와 다른 에이전트가 접근할 수 있는 대상으로 만들고, 플러그인은 DataDog, 데이터베이스, 디자인 도구처럼 엔지니어가 쓰는 도구를 에이전트도 사용할 수 있게 한다 [08:37]

7. Composer의 비용·속도 전략과 모델 접근성 문제

• Composer 2.5에 대한 관심은 속도와 비용에 대한 집중에서 나왔고, 고성능 모델이 자본이 큰 회사만 쓸 수 있는 자원이 되면 개인 개발자와 솔로 해커의 창작 가능성이 제한될 수 있다는 문제의식이 드러난다 [12:00]
• 최신 Composer 모델 릴리스는 비용과 속도에 초점을 맞췄고, 일상적으로 쓰는 가격 대비 성능 모델과 필요할 때 쓰는 고가 모델을 함께 운용하는 방식이 자연스러운 선택지로 떠오른다 [12:40]

8. 클라우드 에이전트가 필요한 이유와 독립 개발환경

• 에이전트는 앞으로 몇 시간뿐 아니라 며칠, 몇 주 동안 실행될 수 있고, 핵심 인프라처럼 항상 켜져 있어야 하므로 노트북에서 프로덕션 서버를 돌리지 않는 것과 같은 환경 전환이 필요하다 [13:21]
• 고객 방문 중이거나 달리는 중이거나 잠들기 직전에 떠오른 아이디어도 즉시 기능 요청으로 바뀔 수 있고, 클라우드 에이전트는 이를 실제 구현과 프로덕션 수준 결과물로 이어가는 팀원 역할을 목표로 한다 [13:47]

9. 항상 켜져 있는 에이전트와 자동화 규모

• 에이전트 활용은 단발성 프롬프트에서 루프와 에이전트 시스템으로 이동하며, 에이전트가 프로그램적으로 시작되고 때로는 사용자가 에이전트를 부르는 것보다 에이전트가 사용자를 더 자주 호출하는 구조가 된다 [15:53]
• 상시 실행 에이전트에는 빠르고 신뢰성 높은 인프라가 필요하고, 발표자는 지난 몇 달 동안 클라우드 에이전트가 세 배 빨라졌으며 99.9% 수준의 신뢰성에 도달했다고 보여준다 [16:13]

10. 여러 작업 표면과 Cursor Mobile 베타

• 에이전트는 Slack, Microsoft Teams, Jira, Linear, 클라우드 API, 웹훅에서 시작될 수 있고, 에디터, IDE, CLI, 터미널까지 이어지는 여러 표면에서 같은 작업 흐름을 유지한다 [17:29]
• Cursor Mobile 베타는 이동 중에도 에이전트를 확인하고 막힌 작업을 풀며 새 아이디어를 실행할 수 있는 작업 표면으로 추가된다 [18:02]

11. Origin이 겨냥하는 팀 개발 워크플로의 병목

• Graphite는 테스트, 리뷰, 머지, 배포처럼 코드 작성 이후의 팀 개발 워크플로를 가속하는 도구를 만들어 왔고, Shopify, Snowflake, Notion, Figma 같은 엔지니어링 팀이 이 흐름에 의존해 왔다고 묶인다 [19:35]
• AI 도구 도입 이후 기존 개발 도구는 신뢰성이 떨어지기 시작했고, 개발자 생산성이 10배에서 100배까지 커질 수 있는 변화는 완전히 다른 협업 도구를 요구한다는 문제의식이 드러난다 [20:12]

12. Origin의 확장성·자동 처리와 자체 대형 모델 전환

• Origin의 첫 번째 핵심은 규모이며, AI 도구 확산으로 코드 라인, 커밋, PR이 늘어난 만큼 클라우드 제공자의 프리미티브를 활용한 새로운 Git 아키텍처가 더 높은 확장성, 신뢰성, 성능을 제공한다고 드러난다 [21:08]
• 초기 부하 테스트에서는 수천 개 에이전트를 시뮬레이션했고, 단일 저장소에 동시에 push와 pull을 처리할 수 있어 현재 수요와 예상되는 미래 수요를 감당할 수 있다는 근거가 생겼다 [21:36]

13. 모델 스케일업과 코딩을 넘는 지능 확장

• Composer 1부터 Composer 2.5까지의 기존 모델은 frontier lab 대비 작은 GPU 세트로 학습됐고, 모델 개선은 더 많은 GPU와 더 긴 학습 시간을 확보할 수 있는지에 근본적으로 막혀 있었다고 드러난다 [24:03]
• 10~20배 규모 확장은 frontier 수준에 접근하고 곧 넘어설 수 있는 기반이며, 사용자에게 더 강력한 기능을 제공할 가능성을 키운다는 방향성이 드러난다 [24:21]

14. 개발자 중심 조직의 모델 전략과 세 가지 발표 정리

• 제품과 모델을 동시에 공동 설계할 수 있는 AI 주체는 매우 적고, 기존 경쟁자들은 대형 기술기업이거나 연구소에서 출발해 개발자·빌더 영역으로 확장한 성격이 강하다고 압축된다 [25:40]
• Cursor는 개발자에게 유용한 도구를 만들고 싶은 사람들로 구성된 개발자 중심 회사이며, 다음 단계에서는 그 제품 철학이 화면의 픽셀뿐 아니라 모델의 근본 능력까지 바꾸는 힘으로 확장된다는 결론으로 마무리된다 [26:02]

🧾 결론

• Cursor의 핵심 메시지는 “AI가 코드를 조금 더 빨리 쓰게 해주는 기능”이 아니라, 개발 작업의 시작·실행·검증·리뷰·배포 전 단계까지 에이전트가 관여하는 개발 운영체제로 확장하겠다는 것이다.
• 클라우드 에이전트, SDK, 플러그인, CLI, 모바일 앱은 모두 같은 방향을 향한다. 에이전트가 IDE 안에만 머무르지 않고 Slack, Jira, Linear, 터미널, 모바일 등 여러 작업 표면에서 계속 이어지는 구조다.
• Origin은 AI로 인해 코드 라인, 커밋, PR이 급증할 수 있다는 전제 아래, 기존 Git 협업 흐름이 병목이 될 수 있다고 보고 이를 에이전트 네이티브 방식으로 다시 설계하려는 시도다.
• 모델 전략에서도 Cursor는 API 기반 활용을 넘어 자체 코딩 모델을 강화하려 하고 있으며, 속도·비용·성능·실제 코딩 워크로드 적합성을 함께 개선하려는 방향을 강조했다.
• 다만 새 모델의 실제 성능, Origin의 공개 후 안정성, 클라우드 에이전트의 장기 작업 품질은 발표 내용만으로 확정할 수 없으며, 실제 사용자 환경에서의 검증이 필요하다.

📈 투자·시사 포인트

• AI 개발 도구 시장의 경쟁 축은 코드 자동완성에서 에이전트 실행 인프라, 협업 워크플로, 자체 모델, 멀티 플랫폼 접근성으로 넓어지고 있다.
• Cursor가 제시한 방향이 현실화된다면, 개발 도구의 가치는 IDE 기능 자체보다 에이전트가 얼마나 오래, 안정적으로, 검증 가능한 결과물을 내는지에 의해 평가될 가능성이 커진다.
• Origin 발표는 AI 코딩 확산이 Git 호스팅, 코드 리뷰, CI 수정, 머지 관리 같은 개발 협업 인프라 시장에도 직접적인 압력을 줄 수 있음을 시사한다.
• Composer 계열 모델과 더 큰 규모의 새 모델 계획은 Cursor가 외부 모델 호출 비용과 성능 한계에만 의존하지 않고, 제품 경험과 모델 능력을 함께 설계하려는 전략으로 해석할 수 있다.
• 검증 필요: 클라우드 에이전트가 실제로 며칠·몇 주 단위 작업에서 사람 엔지니어 수준의 신뢰성과 비용 효율성을 낼 수 있는지는 발표만으로 판단하기 어렵다.
• 검증 필요: Origin이 GitHub에 맞서는 수준의 플랫폼이 될 수 있는지는 공개 범위 확대 이후 대규모 팀의 실제 이전 사례, 성능, API 생태계, 기존 도구와의 호환성을 확인해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 발표에서는 Cursor 사용자의 95% 이상이 Cursor를 주로 에이전트로 사용하고, 에이전트 요청량이 Tab 같은 보조 기능보다 약 5배 많다고 설명하지만, 산정 기준과 표본 범위는 별도 확인이 필요하다.
• 클라우드 에이전트가 최근 몇 달 동안 3배 빨라졌고 99.9% 수준의 신뢰성에 도달했다는 수치는 발표 내 주장으로 보이며, 측정 방식·기간·장애 기준은 공개 자료로 검증해야 한다.
• 자동화 제품 출시 후 몇 달 동안 600만 건 이상의 자동화 실행이 있었다는 언급은 의미 있는 성장 지표지만, 실행 1건의 정의와 실제 성공률은 추가 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Cursor 3의 agent-first UI, 디자인 모드, recursive sub-agent 기능이 실제 제품에서 어떤 형태로 제공되는지 공식 릴리스 노트로 확인한다.
• 클라우드 에이전트가 장기 작업을 맡을 때 필요한 저장소 권한, 의존성 설치, 테스트 실행, 스크린샷 검증 흐름을 팀 개발 환경 기준으로 점검한다.
• SDK·플러그인·CLI가 기존 개발 워크플로와 어떻게 연결되는지 확인하고, Slack·Jira·Linear·터미널·IDE 중 우선 도입할 표면을 정한다.
• Origin이 GitHub·Graphite 기반 워크플로를 대체하거나 보완할 수 있는지, PR 리뷰·CI 실패 수정·merge conflict 처리 사례를 중심으로 비교한다.

❓ 열린 질문

• Cursor가 말하는 “동료 엔지니어처럼 며칠간 작업하는 에이전트”는 실제로 어느 수준의 작업 분해, 테스트, 코드 리뷰, 책임 추적까지 수행할 수 있을까요?
• 여러 에이전트가 동시에 같은 저장소에서 작업할 때 충돌·중복 구현·품질 저하를 막는 기본 메커니즘은 무엇일까요?
• Origin의 에이전트 네이티브 Git 플랫폼은 기존 GitHub 생태계, CI/CD, 보안 정책, 감사 로그와 어느 정도까지 호환될까요?