어느 날, 코드 편집기가 작업장이 되었다
처음 Cursor를 열었을 때 많은 사람은 이렇게 생각했습니다. "VS Code에 ChatGPT가 붙었네." 익숙한 파일 트리, 익숙한 터미널, 익숙한 단축키. 여기에 채팅창이 하나 더 생겼고, 선택한 코드를 고쳐 달라고 말하면 AI가 코드를 제안했습니다. 그때의 Cursor는 분명 "AI 코드 편집기"에 가까웠습니다.
그런데 지금의 Cursor는 그 표현만으로는 설명이 부족합니다.
이제 Cursor는 한 줄 자동완성을 해주는 도구를 넘어, 제품을 만들고 운영하는 흐름 전체에 들어와 있습니다. 요구사항을 정리하고, 구현 계획을 세우고, 여러 파일을 고치고, 테스트를 실행하고, Pull Request를 만들고, 리뷰하고, 때로는 클라우드에서 계속 작업합니다. 개발자가 잠시 브라우저를 보거나 커피를 가지러 간 사이에도 에이전트는 자기 작업 공간에서 코드를 읽고, 고치고, 실패한 테스트를 다시 확인합니다.
Cursor 3 발표에서 Cursor 팀은 이 변화를 명확히 말합니다. 지난 1년 동안 개발 방식이 "파일을 수동으로 수정하는 방식"에서 "코드의 대부분을 작성하는 에이전트와 함께 작업하는 방식"으로 이동했다는 것입니다. 그래서 Cursor 3는 기존 IDE에 AI 기능을 덧붙이는 수준이 아니라, 에이전트와 함께 소프트웨어를 만들기 위한 통합 워크스페이스를 목표로 다시 설계되었습니다.1
이 변화가 중요합니다. 왜냐하면 우리는 더 이상 "AI가 코드를 얼마나 잘 완성하는가"만 묻지 않기 때문입니다. 이제 질문은 바뀌었습니다.
"내가 혼자 제품을 만들 때, 어떤 일을 사람에게 남기고 어떤 일을 에이전트에게 맡길 것인가?"
이 책은 바로 그 질문에서 시작합니다.
다시 Cursor 책이 필요한 이유
이미 Cursor를 다룬 글과 영상은 많습니다. 설치 방법, Tab 자동완성, Cmd+K, 채팅창 사용법, "이렇게 프롬프트를 쓰면 앱이 만들어진다"는 데모도 넘쳐납니다. 그런데 막상 실제 제품을 만들려고 하면 이야기가 달라집니다.
간단한 투두 앱을 10분 만에 만드는 것과, 실제 사용자가 쓰는 제품을 몇 달 동안 고치고 운영하는 것은 전혀 다른 일입니다. 데모에서는 AI가 멋지게 코드를 생성합니다. 하지만 현실에서는 이런 문제가 곧바로 따라옵니다.
코드는 만들어졌는데 요구사항과 조금 다릅니다. UI는 얼추 비슷하지만 모바일에서 깨집니다. 테스트는 없거나, 있더라도 중요한 엣지 케이스를 놓칩니다. 인증 로직을 건드리다가 보안 문제가 생길 수도 있습니다. AI가 새 라이브러리를 추가했는데 비용이나 번들 크기를 고려하지 않았을 수도 있습니다. 무엇보다, 며칠 뒤 내가 다시 봤을 때 "이 변경이 왜 들어갔지?"라는 질문에 답하지 못하면 제품은 빠르게 무너집니다.
그래서 다시 Cursor 책이 필요합니다. 기능을 나열하는 책이 아니라, 혼자서 제품을 만들고 운영하는 사람이 Cursor를 어떻게 작업 시스템으로 사용할지 다루는 책이 필요합니다.
Cursor의 초창기 이야기를 보면, Cursor가 단순한 VS Code 확장 프로그램이 아니라 IDE 자체를 포크한 이유도 여기에 닿아 있습니다. 기존 편집기의 한계 안에서 AI 기능을 얹는 것만으로는 새로운 사용자 경험을 만들기 어렵기 때문에, Cursor는 AI에 맞는 IDE 경험을 직접 만들려 했습니다.2 그 선택은 시간이 지나며 더 큰 방향으로 이어졌습니다. 이제 Cursor는 "AI가 붙은 편집기"가 아니라 "에이전트를 조직하고 지휘하는 작업대"에 가까워지고 있습니다.
이 책은 Cursor를 처음 쓰는 사람도 따라올 수 있도록 기본부터 설명합니다. 하지만 목표는 단순 입문서가 아닙니다. 이 책의 목표는 분명합니다. 솔로 메이커가 제품을 기획하고, 구현하고, 검증하고, 운영하는 반복 가능한 워크플로우를 만드는 것입니다.
솔로 메이커에게 가장 비싼 것은 시간이 아니라 전환 비용이다
혼자 제품을 만드는 사람에게 하루는 늘 짧습니다. 오전에는 고객 문의를 보고, 낮에는 결제 오류를 고치고, 오후에는 새 기능을 만들고, 밤에는 랜딩 페이지 문구를 다듬습니다. 개발자이면서 기획자이고, 디자이너이면서 QA 담당자이며, 운영자이면서 고객 지원 담당자입니다.
문제는 일이 많다는 것만이 아닙니다. 더 큰 문제는 계속 역할을 바꿔야 한다는 것입니다.
방금 전까지 데이터베이스 스키마를 보고 있었는데, 갑자기 버튼 색상이 이상하다는 피드백을 받습니다. UI를 고치다 보니 API 응답 형식이 맞지 않습니다. API를 고치려니 테스트가 없습니다. 테스트를 만들다 보니 애초에 요구사항 문서가 없었다는 사실을 깨닫습니다. 결국 브라우저, 터미널, GitHub, 이슈 트래커, 디자인 도구, 로그 도구, 문서 파일을 오가며 머릿속 컨텍스트가 계속 찢어집니다.
여기서 Cursor의 가치는 단순히 "코드를 빨리 써준다"가 아닙니다. Cursor는 이 전환 비용을 줄여 줍니다. 한 공간 안에서 코드베이스를 이해하고, 자연어로 질문하고, 여러 파일을 수정하고, 터미널 명령을 실행하고, 변경 사항을 diff로 검토할 수 있습니다. 공식 홈페이지도 Cursor의 에이전트가 자체 컴퓨터를 사용해 기능을 처음부터 끝까지 만들고, 테스트하고, 데모를 진행해 리뷰 가능한 상태로 만든다고 설명합니다.3
물론 이 말이 "사람이 할 일이 사라진다"는 뜻은 아닙니다. 오히려 반대입니다. 사람이 해야 할 일은 더 선명해집니다.
솔로 메이커는 더 이상 모든 코드를 손으로 입력하는 사람일 필요는 없습니다. 대신 무엇을 만들지 정의하고, 어떤 제약을 지켜야 하는지 알려주고, 결과가 제품의 방향과 맞는지 판단하는 사람이 되어야 합니다. 개발자라기보다 작은 제품 조직의 책임자에 가까워집니다. Cursor는 그 조직의 개발자, 리뷰어, QA 보조, 운영 보조 역할을 동시에 맡을 수 있는 도구입니다. 하지만 제품 책임자는 여전히 당신입니다.
에이전트는 직원이 아니라 작업 단위다
에이전트라는 단어는 종종 과장되어 들립니다. 마치 AI 직원 여러 명을 고용한 것처럼 말하기도 합니다. 하지만 실제로 Cursor를 잘 쓰려면 에이전트를 사람처럼 상상하기보다 "작업 단위"로 보는 편이 더 정확합니다.
예를 들어 "회원 탈퇴 기능을 만들어줘"라고 말하면 너무 큽니다. 이 요청 안에는 정책 결정, 데이터 삭제 범위, 결제 구독 취소, 이메일 발송, 관리자 로그, 테스트, UI 문구, 법적 안내까지 여러 일이 섞여 있습니다. 이걸 한 번에 맡기면 에이전트는 그럴듯한 코드를 만들 수는 있어도, 제품적으로 중요한 결정을 임의로 해버릴 가능성이 큽니다.
반면 작업을 이렇게 나누면 달라집니다.
PRD에서 회원 탈퇴 기능의 목적과 정책을 먼저 정리합니다.
Plan Mode에서 현재 코드베이스 기준 구현 경로를 조사하게 합니다.
승인한 계획에 따라 작은 단위로 구현합니다.
테스트와 타입 체크를 실행하게 합니다.
변경 사항을 리뷰하고, 필요한 부분만 다시 맡깁니다.
이 흐름에서 에이전트는 "알아서 다 해주는 마법사"가 아닙니다. 명확한 입력과 검증 기준을 가진 실행 단위입니다. 사람이 일을 정의하고, 에이전트가 수행하며, 다시 사람이 판단합니다.
Cursor의 에이전트 모범 사례에서도 같은 방향을 강조합니다. 코드를 작성하기 전에 계획을 세우면 무엇을 만들고 있는지 명확해지고, 에이전트에게 구체적인 목표를 줄 수 있습니다. Plan Mode는 관련 파일을 찾고, 요구사항을 명확히 하기 위한 질문을 하고, 구현 계획을 만든 뒤 승인받는 흐름을 제공합니다.4
이 책에서 Plan Mode를 중요하게 다루는 이유가 여기에 있습니다. AI 시대의 개발에서 가장 위험한 순간은 AI가 코드를 못 쓸 때가 아닙니다. AI가 너무 빨리 그럴듯한 코드를 쓸 때입니다. 계획 없는 속도는 기술 부채를 빠르게 쌓습니다. 반대로 계획이 있는 속도는 혼자 일하는 사람에게 강력한 무기가 됩니다.
Cursor는 왜 솔로 메이커에게 특히 강력한가
팀이 있는 회사에서는 역할이 나뉩니다. 기획자는 요구사항을 정리하고, 디자이너는 화면을 만들고, 프론트엔드 개발자는 UI를 구현하고, 백엔드 개발자는 API를 만들고, QA는 테스트 케이스를 돌리고, DevOps 담당자는 배포와 모니터링을 봅니다. 물론 현실의 팀도 늘 바쁘고 완벽하지는 않지만, 적어도 책임이 분산됩니다.
솔로 메이커에게는 그런 분산이 없습니다. 좋은 아이디어가 있어도 구현 속도가 느리면 시장 반응을 보기 어렵습니다. 버그가 생겨도 대신 봐줄 동료가 없습니다. 코드 리뷰도 혼자 해야 하고, 오래된 결정의 이유도 혼자 기억해야 합니다.
이때 Cursor는 네 가지 보조 역할을 합니다.
개발자 역할: 반복적인 코드 작성, 보일러플레이트 생성, 여러 파일에 걸친 수정, 테스트 작성 초안을 맡길 수 있습니다.
리뷰어 역할: 변경된 diff를 설명하게 하고, 잠재적인 문제를 찾게 하고, 더 단순한 구현이 있는지 물어볼 수 있습니다.
QA 역할: 재현 절차를 바탕으로 버그 원인을 추적하게 하고, 회귀 테스트를 만들게 하고, 브라우저나 터미널을 통해 검증 루프를 돌릴 수 있습니다.
운영 보조 역할: 로그, 이슈, PR, 배포 스크립트, 외부 도구와 연결해 반복 업무를 줄일 수 있습니다.
중요한 점은 이 역할들이 각각 떨어져 있지 않다는 것입니다. Cursor 안에서는 PRD, 코드, 터미널, 테스트, Git 변경 사항, 외부 도구가 하나의 흐름으로 이어집니다. 그래서 Cursor는 솔로 메이커에게 "코딩 도구"라기보다 "작은 제품 조직을 흉내 내는 시스템"이 됩니다.
혼자 일할수록 시스템이 필요합니다. 의지가 아니라 시스템입니다. 컨디션이 좋은 날에는 누구나 빠르게 만들 수 있습니다. 문제는 피곤한 날, 고객 문의가 밀린 날, 버그가 겹친 날에도 같은 품질의 결정을 내릴 수 있느냐입니다. Cursor를 제대로 세팅한다는 것은 그날그날의 즉흥성을 줄이고, 반복 가능한 개발 운영 루틴을 만든다는 뜻입니다.
그래도 최종 책임은 사람에게 남는다
AI가 코드를 대신 쓰면 책임도 AI에게 넘길 수 있을까요? 현실은 그렇지 않습니다.
서비스가 장애를 내면 사용자는 "에이전트가 그렇게 만들었다"는 말을 듣고 싶어 하지 않습니다. 결제 오류가 나면 고객은 환불을 요구합니다. 개인정보가 잘못 처리되면 법적 책임은 제품을 운영하는 사람에게 돌아옵니다. 보안 취약점이 생기면 "AI가 추천한 라이브러리였다"는 변명은 통하지 않습니다.
그래서 Cursor를 잘 쓰는 사람은 AI를 많이 믿는 사람이 아니라, AI가 만든 결과를 검증하는 구조를 잘 만드는 사람입니다.
Cursor의 공식 모범 사례도 AI가 작성한 코드는 반드시 리뷰가 필요하다고 말합니다. 생성 중에는 diff를 보며 방향을 확인하고, 작업 후에는 리뷰 기능이나 Bugbot 같은 도구로 문제를 찾고, 로컬 변경 사항을 메인 브랜치와 비교해 검토하는 절차가 필요합니다.5
이 책에서 계속 반복할 전제가 있습니다.
AI는 초안을 만듭니다. 사람은 기준을 정합니다.
AI는 빠르게 수정합니다. 사람은 무엇이 맞는지 판단합니다.
AI는 테스트를 실행합니다. 사람은 무엇을 테스트해야 하는지 결정합니다.
AI는 PR을 열 수 있습니다. 사람은 배포 버튼을 누를지 결정합니다.
이 전제를 받아들이면 Cursor 사용법이 훨씬 현실적으로 바뀝니다. 더 이상 "한 번에 완성해줘"라고 기도하지 않습니다. 대신 "이 기준을 만족할 때까지 반복해줘"라고 요청합니다. 더 이상 "알아서 좋은 코드로 만들어줘"라고 말하지 않습니다. 대신 "우리 프로젝트에서는 이 규칙을 지켜"라고 알려줍니다. 더 이상 긴 채팅 하나에 모든 맥락을 우겨 넣지 않습니다. 대신 Rules, Skills, 문서, 계획 파일, 테스트로 컨텍스트를 나눠 관리합니다.
AI 시대의 개발 능력은 손가락으로 코드를 입력하는 속도가 아니라, 좋은 기준을 만들고 그 기준을 시스템에 심는 능력에 가까워지고 있습니다.
이 책의 지도: PRD에서 Automations까지
이 책은 Cursor의 기능을 하나씩 소개하는 순서로만 진행하지 않습니다. 대신 솔로 메이커의 실제 작업 흐름을 기준으로 Cursor의 기능을 연결합니다. 여기서 중요한 축은 PRD, Plan Mode, Rules, Skills, MCP, Automations입니다.
먼저 PRD입니다. PRD는 Product Requirements Document의 약자로, 제품 요구사항 문서입니다. 거창한 회사 문서처럼 생각할 필요는 없습니다. 솔로 메이커에게 PRD는 "무엇을, 왜, 어디까지 만들 것인가"를 적는 짧은 설계도입니다. AI에게 코드를 맡기기 전에 사람이 의도를 정리하는 문서입니다. PRD가 없으면 에이전트는 빈칸을 자기 방식으로 채웁니다. PRD가 있으면 에이전트는 방향을 따라갑니다.
다음은 Plan Mode입니다. PRD가 제품의 목적을 적는 문서라면, Plan Mode는 현재 코드베이스에서 그 목적을 어떻게 구현할지 찾는 과정입니다. 어떤 파일을 봐야 하는지, 어떤 API를 고쳐야 하는지, 어떤 테스트가 필요한지, 어떤 위험이 있는지를 코드 작성 전에 점검합니다. 여기서 1분을 더 쓰면, 나중에 1시간짜리 되돌리기를 줄일 수 있습니다.
그다음은 Rules입니다. .cursor/rules/는 에이전트에게 프로젝트의 기본 규칙을 알려주는 공간입니다. 예를 들어 "패키지 매니저는 pnpm을 사용한다", "API 응답은 이 형식을 따른다", "컴포넌트는 이 디렉터리 구조를 지킨다", "수정 후에는 타입 체크를 실행한다" 같은 지침을 적어둘 수 있습니다. 매번 채팅에서 반복할 말을 규칙으로 옮기는 것입니다.
Skills는 Rules보다 더 동적인 지식 패키지입니다. Rules가 늘 적용되는 프로젝트의 기본 생활 규칙이라면, Skills는 특정 작업을 할 때 꺼내 쓰는 전문 도구함에 가깝습니다. 예를 들어 "신규 랜딩 페이지 제작 스킬", "Stripe 결제 디버깅 스킬", "Sentry 오류 분석 스킬", "릴리즈 노트 작성 스킬"처럼 만들 수 있습니다. Cursor의 에이전트 모범 사례는 Rules를 정적 컨텍스트로, Skills를 필요할 때 로드되는 동적 역량과 워크플로우로 설명합니다.6
MCP는 Model Context Protocol의 약자로, Cursor를 외부 세계와 연결하는 통로입니다. 코드 편집기 안에만 갇혀 있던 에이전트가 Slack, GitHub, Linear, Sentry, Datadog, 데이터베이스 같은 도구와 대화할 수 있게 됩니다. 솔로 메이커에게 이것은 특히 중요합니다. 운영 정보는 코드 안에만 있지 않기 때문입니다. 버그의 단서는 고객 문의에 있고, 장애의 단서는 로그에 있으며, 다음 작업의 우선순위는 이슈 트래커에 있습니다.
마지막으로 Automations입니다. 반복되는 일을 자동화하는 단계입니다. 의존성 업데이트를 확인하고, 실패한 테스트의 원인을 조사하고, PR 설명을 작성하고, 오래된 TODO를 정리하고, 특정 조건에서 에이전트를 실행하는 식입니다. Cursor SDK는 Cursor의 런타임, 하네스, 모델을 사용해 프로그래밍 방식의 에이전트를 만들 수 있게 하며, 팀들이 CI/CD 파이프라인이나 자동화 워크플로우에 에이전트를 직접 호출하는 사례를 소개합니다.7 이 흐름은 솔로 메이커에게도 중요한 힌트를 줍니다. 혼자 일한다고 해서 모든 일을 직접 눌러서 시작할 필요는 없습니다.
이 여섯 가지는 따로 떨어진 기능이 아닙니다. 하나의 사슬입니다.
PRD로 의도를 정리합니다. Plan Mode로 구현 경로를 확인합니다. Rules로 반복되는 기준을 고정합니다. Skills로 도메인 지식을 패키지화합니다. MCP로 외부 도구와 연결합니다. Automations로 반복 업무를 에이전트에게 넘깁니다.
이 사슬이 만들어지면 Cursor는 단순히 "코드를 생성하는 창"이 아니라 "제품을 계속 앞으로 밀어주는 작업 시스템"이 됩니다.
이 책을 읽는 방법
이 책은 세 종류의 독자를 생각하며 썼습니다.
첫째, Cursor를 처음 설치했지만 어디서부터 써야 할지 막막한 사람입니다. 이 책은 설치와 첫 30분, 주요 인터페이스, 기본 단축키부터 차근차근 설명합니다. 처음부터 복잡한 자동화를 만들 필요는 없습니다. Tab 자동완성, Cmd+K, Agent를 제대로 쓰는 것만으로도 작업 방식이 달라집니다.
둘째, Cursor를 이미 쓰고 있지만 결과가 들쭉날쭉한 사람입니다. 어떤 날은 놀랍도록 잘되고, 어떤 날은 엉뚱한 파일을 고치거나 같은 실수를 반복합니다. 이런 경우 대부분 문제는 모델의 지능만이 아니라 컨텍스트와 작업 구조에 있습니다. PRD, Plan Mode, Rules, Skills, 컨텍스트 관리 장에서 그 문제를 다룹니다.
셋째, 혼자 제품을 만들고 운영하는 사람입니다. 이 책의 중심 독자입니다. 여러분에게 필요한 것은 "AI로 앱 하나 만들기"가 아니라 "AI와 함께 제품을 계속 개선하는 방법"입니다. 그래서 이 책은 새 기능 개발뿐 아니라 디버깅, 리팩터링, UI 작업, MCP, 코드 리뷰, 클라우드 에이전트, 비용 관리까지 다룹니다.
각 장은 가능한 한 실제 작업 흐름에 맞춰 읽을 수 있게 구성했습니다. 처음부터 끝까지 읽어도 좋고, 지금 막힌 지점부터 펼쳐도 됩니다. 다만 PRD부터 시작하라, Plan Mode, Rules, Skills, 컨텍스트 관리의 기술, 새 기능 만들기로 이어지는 구간은 하나의 핵심 루프를 이룹니다. 제품 요구사항을 쓰고, 계획하고, 규칙을 만들고, 필요한 맥락을 관리한 뒤, 실제 기능 하나를 끝까지 구현하는 흐름입니다. Cursor를 단순한 채팅 도구에서 작업 시스템으로 바꾸는 구간이므로 가능하면 순서대로 읽기를 권합니다.
AI에게 맡길수록 더 사람다워져야 한다
이상하게 들릴 수 있지만, Cursor를 깊이 쓸수록 사람의 역할은 더 중요해집니다. 단순 반복은 점점 에이전트에게 넘어갑니다. 파일을 찾고, 타입 오류를 고치고, 테스트 초안을 만들고, 문서를 요약하는 일은 앞으로 더 자동화될 것입니다. 그렇다면 사람에게 남는 것은 무엇일까요?
문제를 정의하는 일입니다.
좋은 취향을 갖는 일입니다.
사용자를 이해하는 일입니다.
무엇을 하지 않을지 결정하는 일입니다.
AI가 만든 결과를 책임지는 일입니다.
솔로 메이커에게 Cursor는 강력한 지렛대입니다. 하지만 지렛대가 있다고 해서 어디를 들어 올릴지 자동으로 정해지지는 않습니다. 방향은 사람이 정해야 합니다. Cursor는 당신의 속도를 높여 줍니다. 그렇기 때문에 더더욱 방향이 중요합니다.
이 책의 부제는 "에이전트 시대, 혼자서 제품을 만들고 운영하는 솔로 메이커의 워크플로우"입니다. 여기서 핵심은 에이전트가 아니라 워크플로우입니다. 도구는 계속 바뀝니다. 모델 이름도, 요금제도, 인터페이스도 바뀝니다. 그러나 좋은 워크플로우의 원리는 오래갑니다. 먼저 의도를 쓰고, 실행 전에 계획하고, 반복 기준을 시스템에 넣고, 작은 단위로 검증하고, 결과에 책임지는 것입니다.
이제 Cursor를 다시 볼 시간입니다.
VS Code에 AI가 붙은 도구가 아니라, 혼자 일하는 사람이 작은 제품 조직처럼 움직이게 해주는 작업대로.
그리고 이 책은 그 작업대를 당신의 방식으로 조립하기 위한 안내서입니다.
참고
2Cursor.so: The AI-first Code Editor — with Aman Sanger of Anysphere
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.