파일을 고치는 사람에서 일을 지휘하는 사람으로
Cursor를 처음 쓰면 가장 먼저 눈에 들어오는 것은 여전히 코드입니다. 왼쪽에는 파일 트리가 있고, 가운데에는 에디터가 있고, 아래에는 터미널이 있습니다. 그래서 우리는 자연스럽게 이렇게 말합니다.
"이 파일 좀 고쳐 줘."
"이 함수 리팩터링해 줘."
"여기 타입 에러 해결해 줘."
이 말들이 틀린 것은 아닙니다. 짧은 수정에는 여전히 훌륭한 지시입니다. 하지만 Cursor 3.0의 핵심은 파일 하나를 빨리 고치는 데 있지 않습니다. 이제 Cursor는 에이전트가 여러 환경에서 작업하고, 사용자는 그 작업을 한곳에서 보고, 멈추고, 비교하고, 적용하는 방향으로 이동했습니다. 공식 문서는 Agents Window를 "에이전트 우선 인터페이스"라고 설명하며, 로컬, 클라우드, 원격 SSH 등 여러 환경과 저장소에 걸쳐 에이전트와 함께 빌드하는 통합 워크스페이스라고 소개합니다.1
이 변화는 단순히 창 하나가 더 생겼다는 뜻이 아닙니다. 일의 중심이 바뀌었다는 뜻입니다.
예전의 중심은 파일이었습니다. 어떤 파일을 열고, 어떤 줄을 고치고, 어떤 함수 이름을 바꿀지가 중요했습니다. 그다음 단계의 중심은 채팅이었습니다. 긴 대화 하나 안에서 요구사항을 설명하고, 수정하고, 다시 물어보고, 또 수정했습니다. 그런데 Cursor 3.0에서는 그보다 한 단계 위로 올라가야 합니다. 이제 중심은 "에이전트 실행"입니다.
에이전트 실행이란, 하나의 목표를 가진 위임 단위입니다. 단순히 "AI와 나눈 대화"가 아니라, 특정한 결과를 얻기 위해 시작한 작업 흐름입니다. 어떤 목표를 달성해야 하고, 어디까지 건드릴 수 있고, 완료되었는지 어떻게 확인할지 정해진 작은 프로젝트라고 생각하면 됩니다.
솔로 메이커에게 이 관점은 특히 중요합니다. 혼자 일하는 사람은 개발자이면서 PM이고, QA이고, 운영자입니다. 모든 것을 직접 할 수는 없습니다. 그렇다고 에이전트에게 "알아서 다 해줘"라고 던져 놓을 수도 없습니다. 그래서 필요한 능력은 코드를 한 줄 더 빨리 쓰는 능력이 아니라, 일을 좋은 단위로 나누고, 각 단위를 에이전트에게 맡기고, 결과를 검토해 제품에 반영하는 능력입니다.
Cursor 3.0의 진짜 변화: agent-first workspace
Cursor 3.0을 "새 버전" 정도로만 보면 중요한 차이를 놓치게 됩니다. Cursor 팀은 3.0을 발표하면서, 소프트웨어 개발이 파일을 수동으로 고치는 방식에서 에이전트와 함께 작업하는 방식으로 이동했고, 앞으로는 여러 에이전트가 자율적으로 개선 사항을 만드는 방향으로 진화할 것이라고 설명했습니다.2 이 말은 꽤 과감합니다. IDE가 더 똑똑해졌다는 정도가 아니라, 개발자의 위치가 바뀐다는 말이기 때문입니다.
이전에는 개발자가 코드의 생산자이고 AI는 보조자였습니다. Tab 자동완성은 다음 줄을 제안했고, 인라인 편집은 선택한 코드를 고쳐 주었고, 채팅은 질문에 답했습니다. 주도권은 대부분 사람이 쥐고 있었습니다.
Cursor 3.0의 Agents Window는 다른 그림을 제안합니다. 여러 에이전트를 동시에 실행할 수 있고, 각각은 로컬 워크스페이스, 클라우드 환경, 원격 SSH, git worktree 같은 분리된 공간에서 작업할 수 있습니다. 공식 발표에서도 로컬 에이전트와 클라우드 에이전트가 사이드바에 함께 나타나며, 모바일, 웹, 데스크톱, Slack, GitHub, Linear에서 시작한 에이전트도 한곳에 모인다고 설명합니다.3
여기서 중요한 단어는 "한곳"입니다. 솔로 메이커의 하루는 이미 너무 많은 곳으로 찢어져 있습니다. GitHub 이슈를 보고, 로컬에서 재현하고, 브라우저에서 UI를 확인하고, 터미널에서 테스트를 돌리고, 문서를 업데이트합니다. Cursor 3.0은 이 흩어진 실행들을 에이전트 단위로 모아 보여주려 합니다. 그래서 개발자는 파일을 하나하나 붙잡고 있는 사람이 아니라, 여러 작업 흐름을 감독하는 사람이 됩니다.
이것을 비행 관제탑에 비유해 볼 수 있습니다. 관제사는 비행기를 직접 조종하지 않습니다. 하지만 어떤 비행기가 어디로 가는지, 어느 활주로를 써야 하는지, 충돌 위험은 없는지, 착륙해도 되는지 판단합니다. Cursor 3.0의 개발자도 비슷합니다. 에이전트가 코드를 읽고, 수정하고, 테스트를 실행할 수 있습니다. 하지만 무엇을 시킬지, 언제 멈출지, 어떤 결과를 채택할지는 사람이 결정합니다.
이때부터 일의 단위는 "파일 수정"이 아니라 "에이전트에게 맡길 수 있는 실행"이 됩니다. 이것이 이 장에서 익혀야 할 가장 중요한 사고방식입니다.
나쁜 위임과 좋은 위임의 차이
에이전트를 제대로 쓰지 못할 때 가장 흔한 패턴은 너무 큰 말을 너무 짧게 던지는 것입니다.
"로그인 버그 고쳐 줘."
이 요청은 겉보기에는 자연스럽습니다. 사람 동료에게도 이렇게 말할 때가 있습니다. 하지만 사람 동료는 곧바로 되묻습니다. 어떤 로그인 버그인지, 언제 발생하는지, 재현 방법은 있는지, 최근 변경 사항은 무엇인지, 성공 기준은 무엇인지 물어봅니다. 반면 에이전트는 때때로 묻지 않고 바로 달려갑니다. 그리고 그럴듯한 원인을 추측해 코드를 고칩니다. 문제는 그 추측이 맞을 수도 있고, 아닐 수도 있다는 점입니다.
좋은 위임은 에이전트가 해야 할 생각의 경로를 어느 정도 설계해 줍니다.
"로그인 버그 고쳐 줘"보다 훨씬 나은 지시는 다음과 같습니다.
사용자가 Google OAuth로 로그인한 뒤
/dashboard로 리다이렉트되지 않고 다시/login으로 돌아오는 문제가 있습니다. 먼저 관련 인증 흐름을 조사하고, 재현 가능한 원인 후보를 2~3개 정리해 주세요. 바로 코드를 수정하지 말고, 어떤 파일을 확인했는지와 가장 가능성 높은 원인을 보고해 주세요. 그다음 최소 수정안과 검증 방법을 제안해 주세요.
이 지시는 에이전트에게 곧바로 삽을 들고 땅을 파라고 하지 않습니다. 먼저 지도를 보라고 합니다. 어디를 봤는지 보고하게 하고, 원인 후보를 나누게 하고, 최소 수정안과 검증 방법을 요구합니다. 같은 버그 수정이라도 작업 단위가 달라집니다.
더 나아가 실제 실행 단위로 나누면 이렇게 됩니다.
재현: 현재 코드베이스에서 로그인 흐름과 리다이렉트 조건을 조사하고, 재현 절차를 정리한다.
원인 분석: 세션 저장, OAuth 콜백, 미들웨어, 라우팅 중 어디에서 상태가 끊기는지 후보를 좁힌다.
최소 수정: 가장 가능성 높은 원인 하나만 고치고, 관련 없는 리팩터링은 하지 않는다.
검증: 지정된 테스트나 수동 확인 절차를 실행하고, 결과를 요약한다.
이 네 단계는 각각 하나의 에이전트 실행이 될 수도 있고, 하나의 에이전트 실행 안에서 명시적인 체크리스트가 될 수도 있습니다. 중요한 것은 "버그 고쳐 줘"가 아니라 "재현 → 분석 → 수정 → 검증"이라는 일의 모양을 만든다는 점입니다.
에이전트에게 일을 맡긴다는 것은 결과만 요청하는 일이 아닙니다. 일을 처리하는 순서를 설계하는 일입니다.
에이전트 실행에는 목표, 범위, 완료 조건이 있어야 한다
좋은 에이전트 실행은 작은 작업 티켓과 닮아 있습니다. 티켓이 좋은 팀에서는 "이거 좀 봐 주세요"라고만 적혀 있지 않습니다. 왜 필요한지, 무엇을 바꿔야 하는지, 어디까지가 범위인지, 완료되었는지 어떻게 확인할지 적혀 있습니다. 에이전트 실행도 마찬가지입니다.
에이전트에게 일을 맡기기 전에 최소한 세 가지를 정해야 합니다. 첫째, 목표입니다. 이 실행이 끝났을 때 무엇이 달라져야 하는가입니다. 둘째, 범위입니다. 어떤 파일, 기능, 화면, API까지 건드려도 되는가입니다. 셋째, 완료 조건입니다. 테스트 통과, 타입 체크 성공, 화면 확인, 문서 업데이트처럼 "끝났다"고 말할 근거입니다.
다음은 에이전트 실행을 만들 때 쓸 수 있는 간단한 형식입니다.
목표:
- 사용자가 비밀번호 재설정 이메일을 다시 요청할 수 있게 한다.
범위:
- /forgot-password 화면과 관련 API만 수정한다.
- 인증 구조 전체 리팩터링은 하지 않는다.
- 이메일 템플릿 문구는 기존 스타일을 따른다.
완료 조건:
- 동일 이메일로 재요청할 때 60초 제한이 적용된다.
- 성공/실패 토스트가 표시된다.
- 관련 테스트를 추가하거나, 테스트가 없다면 수동 검증 절차를 보고한다.
- `npm run typecheck` 결과를 포함한다.이 정도만 적어도 에이전트의 움직임이 크게 달라집니다. 왜냐하면 에이전트는 빈칸을 채우는 데 능숙하기 때문입니다. 목표가 비어 있으면 목표를 추측합니다. 범위가 비어 있으면 필요 이상으로 넓게 수정합니다. 완료 조건이 비어 있으면 "코드를 바꿨으니 끝났다"고 판단할 수 있습니다.
사람이 해야 할 일은 빈칸을 줄이는 것입니다. 모든 세부 구현을 사람이 정할 필요는 없습니다. 하지만 "성공이 무엇인지"는 사람이 정해야 합니다. 이것은 제품 책임자의 일입니다.
작업 크기에 따라 도구가 달라진다
Cursor를 잘 쓰는 사람은 모든 일을 Agent Mode에 던지지 않습니다. 반대로 모든 일을 손으로 고치지도 않습니다. 작업의 크기에 따라 적절한 도구를 고릅니다. 망치가 좋다고 해서 나사를 망치로 박지 않는 것과 같습니다.
Tab 자동완성은 가장 작은 단위의 도움입니다. 지금 쓰고 있는 줄, 바로 아래 줄, 근처 코드의 패턴을 보고 다음 편집을 제안합니다. 변수명을 이어 쓰거나, 반복되는 JSX 구조를 완성하거나, 방금 만든 타입에 맞춰 속성을 채울 때 빠릅니다. 생각의 방향은 이미 사람이 정했고, Cursor는 손의 속도를 올려 줍니다.
Inline Edit 또는 Cmd+K는 선택한 코드의 국소 수정에 좋습니다. 함수 하나의 이름을 바꾸거나, 조건문을 단순화하거나, 에러 메시지를 더 친절하게 고치거나, 작은 컴포넌트의 스타일을 바꿀 때 적합합니다. 이때는 전체 프로젝트를 돌아다닐 필요가 없습니다. "여기만 바꿔"가 핵심입니다.
Agent Mode는 여러 파일을 넘나드는 작업에 어울립니다. API를 추가하고, 프론트엔드 호출부를 연결하고, 테스트를 만들고, 타입 오류를 고치는 식의 작업입니다. 에이전트는 파일을 검색하고, 코드를 수정하고, 터미널 명령을 실행하면서 반복할 수 있습니다. Cursor의 에이전트 모범 사례에서도 복잡한 작업에서는 Plan Mode를 통해 관련 파일을 찾고, 요구사항을 확인하고, 구현 계획을 만든 뒤 승인받는 흐름을 권합니다.4
Cloud Agent는 시간이 오래 걸리거나, 내 노트북을 붙잡아 두고 싶지 않은 작업에 적합합니다. 예를 들어 큰 리팩터링 후보를 조사하거나, 테스트 커버리지를 보강하거나, 문서 초안을 만들거나, 여러 이슈를 병렬로 처리하는 작업입니다. Cursor 3.0 발표에서는 로컬에서 시작한 세션을 클라우드로 옮겨 오프라인 상태에서도 계속 실행하게 하거나, 반대로 클라우드 세션을 로컬로 가져와 직접 테스트할 수 있는 흐름을 강조합니다.5
정리하면 기준은 단순합니다. 손가락을 돕는 일은 Tab, 선택 영역을 고치는 일은 Cmd+K, 작은 기능이나 버그를 끝까지 처리하는 일은 Agent Mode, 오래 걸리거나 분리된 환경이 필요한 일은 Cloud Agent에 맡깁니다.
이 구분을 익히면 Cursor가 훨씬 덜 산만해집니다. 초보자는 종종 작은 오타 수정도 에이전트에게 맡기고, 큰 기능 구현도 한 줄 프롬프트로 던집니다. 그러면 작업이 느려지고 결과도 불안정해집니다. 반대로 능숙한 사용자는 작업 크기를 먼저 봅니다. 그리고 가장 작은 도구로 해결할 수 있으면 작은 도구를 씁니다. 좋은 위임은 큰 도구를 많이 쓰는 것이 아니라, 알맞은 도구를 쓰는 것입니다.
Agents Window는 여러 실행을 보는 작업대다
Agents Window의 가치는 "여러 에이전트를 동시에 돌릴 수 있다"에서 끝나지 않습니다. 병렬 실행은 눈에 띄는 기능이지만, 더 중요한 것은 작업을 분리해서 볼 수 있다는 점입니다.
하나의 긴 채팅에 모든 일을 넣으면 처음에는 편합니다. 하지만 시간이 지나면 대화가 진흙탕이 됩니다. 요구사항 설명, 버그 분석, 리팩터링, 테스트 실패, 문서 작성, 잡담이 한 줄에 섞입니다. 에이전트도 점점 무엇이 중요한지 놓치기 쉽고, 사람도 어디서 어떤 결정이 내려졌는지 찾기 어려워집니다.
Agents Window에서는 일을 실행 단위로 나눠 볼 수 있습니다. 예를 들어 솔로 메이커가 결제 기능을 고친다고 해 봅시다. 하나의 에이전트는 Stripe 웹훅 실패 원인을 조사합니다. 다른 에이전트는 결제 실패 시 사용자에게 보여줄 UI 문구와 상태 처리를 개선합니다. 또 다른 에이전트는 관련 테스트를 작성합니다. 각 실행은 자기 목적과 맥락을 가집니다.
이때 분리된 환경은 큰 도움이 됩니다. git worktree는 같은 저장소를 기반으로 하되 별도의 작업 디렉터리에서 변경을 만들 수 있게 해 주는 Git 기능입니다. 쉽게 말해, 같은 프로젝트의 평행 우주를 하나 더 만드는 것입니다. 에이전트 A가 결제 UI를 고치는 동안 에이전트 B가 테스트를 추가해도 서로의 파일을 덮어쓸 위험이 줄어듭니다. Cursor의 에이전트 모범 사례도 병렬 에이전트를 위해 각 에이전트가 서로 분리된 worktree에서 실행될 수 있으며, 작업이 끝나면 변경 사항을 적용해 병합하는 흐름을 설명합니다.6
여러 모델을 비교하는 방식도 같은 관점에서 이해할 수 있습니다. 어려운 문제 하나를 한 모델에만 맡기면 그 모델의 접근에 갇힙니다. 반면 같은 문제를 여러 모델에 맡기고 결과를 나란히 보면 선택지가 생깁니다. 어떤 모델은 단순한 구현을 내놓고, 어떤 모델은 테스트를 더 잘 만들고, 어떤 모델은 엣지 케이스를 더 잘 짚습니다. 사람이 할 일은 그중 제품에 맞는 결과를 고르는 것입니다.
Agents Window는 그래서 "AI 채팅창"이라기보다 "작업대"에 가깝습니다. 각각의 에이전트 실행은 작업대 위에 놓인 반제품입니다. 어떤 것은 버리고, 어떤 것은 합치고, 어떤 것은 조금 더 다듬습니다. 모든 결과를 그대로 받아들이는 것이 아니라, 비교하고 선택하고 조립합니다.
에이전트를 주니어 개발자처럼 다룬다는 말의 진짜 의미
AI 코딩 도구를 설명할 때 "에이전트를 주니어 개발자처럼 다루라"는 말을 자주 듣습니다. 이 말은 반은 맞고 반은 위험합니다. 위험한 이유는 에이전트가 실제 사람은 아니기 때문입니다. 에이전트는 책임을 지지 않고, 제품 맥락을 스스로 소유하지 않으며, 조직의 암묵지를 완전히 이해하지 못합니다.
그럼에도 이 비유가 유용한 이유가 있습니다. 주니어 개발자에게 일을 맡길 때 우리는 보통 처음부터 완벽한 결과를 기대하지 않습니다. 대신 일을 작게 나누고, 배경을 설명하고, 중간 결과를 확인하고, 방향이 틀리면 빨리 되돌립니다. 에이전트에게도 같은 운영 방식이 필요합니다.
에이전트 실행은 한 번 던지고 잊어버리는 주문이 아닙니다. 지시하고, 실행을 관찰하고, 필요하면 중단하고, 방향을 수정하고, 결과를 검토하고, 다시 시도하는 루프입니다.
이 루프에서 가장 중요한 버튼 중 하나는 역설적으로 "Stop"입니다. 에이전트가 엉뚱한 파일을 대거 수정하기 시작하거나, 요구하지 않은 라이브러리를 설치하려 하거나, 단순한 버그 수정 중에 구조 전체를 바꾸려 한다면 멈춰야 합니다. 계속 지켜보다가 끝난 뒤에 수습하는 것보다, 초기에 멈추고 프롬프트를 다시 쓰는 편이 낫습니다. Cursor의 모범 사례도 에이전트가 원하는 방향에서 벗어났을 때 후속 프롬프트로 억지로 고치기보다 변경 사항을 되돌리고 계획을 더 구체화한 뒤 다시 실행하는 편이 더 깔끔한 결과를 만든다고 설명합니다.7
여기서 솔로 메이커가 기억해야 할 원칙이 있습니다. 에이전트의 실패는 대개 "모델이 바보라서"만 발생하지 않습니다. 목표가 흐렸거나, 범위가 컸거나, 완료 조건이 없었거나, 컨텍스트가 지저분했을 가능성이 큽니다. 물론 모델이 틀릴 때도 있습니다. 하지만 작업 설계를 바꾸면 실패율은 눈에 띄게 줄어듭니다.
에이전트를 주니어 개발자처럼 다룬다는 것은 친절하게 말하라는 뜻이 아닙니다. 일을 작게 주고, 기준을 명확히 하고, 중간에 보고받고, 최종 결과를 리뷰하라는 뜻입니다.
병렬 실행은 속도보다 선택지를 위한 것이다
여러 에이전트를 동시에 실행할 수 있다는 말을 들으면 가장 먼저 속도를 떠올립니다. 세 명이 일하면 세 배 빠르지 않을까? 어떤 경우에는 맞습니다. 문서 초안 작성, 테스트 추가, 작은 버그 여러 개 수정처럼 서로 독립적인 일은 병렬화하기 좋습니다.
하지만 병렬 실행의 진짜 가치는 속도보다 선택지에 있습니다.
혼자 일할 때 가장 위험한 순간은 대안이 보이지 않을 때입니다. 하나의 구현이 떠오르면 그것이 최선처럼 느껴집니다. 에이전트도 마찬가지입니다. 하나의 에이전트에게만 맡기면 그 에이전트가 만든 경로가 기본값이 됩니다. 그런데 같은 문제를 두세 개의 에이전트에게 다르게 맡기면 시야가 넓어집니다.
예를 들어 "온보딩 체크리스트 기능"을 만든다고 해 봅시다. 한 에이전트에게는 가장 단순한 구현을 요청합니다. 다른 에이전트에게는 확장 가능한 데이터 모델을 고려해 달라고 합니다. 또 다른 에이전트에게는 테스트와 엣지 케이스를 중심으로 설계하게 합니다. 세 결과를 비교하면 무엇을 버리고 무엇을 채택할지 판단하기 쉬워집니다.
다만 모든 일이 병렬화에 적합한 것은 아닙니다. 순서 의존성이 강한 작업은 병렬로 나누면 오히려 느려집니다. 예를 들어 데이터 모델이 아직 결정되지 않았는데 UI, API, 테스트를 동시에 만들면 세 에이전트가 서로 다른 가정을 할 수 있습니다. 결제 정책처럼 작은 해석 차이가 큰 문제로 이어지는 영역도 마찬가지입니다. 이런 일은 먼저 하나의 계획 실행으로 기준을 정한 뒤, 그 기준을 바탕으로 병렬화해야 합니다.
좋은 병렬 실행은 "각자 알아서 해 봐"가 아닙니다. 공통의 PRD와 완료 조건을 바탕으로, 서로 독립적인 하위 작업을 맡기는 것입니다. 병렬화는 혼란을 빠르게 증폭시킬 수도 있고, 좋은 선택지를 빠르게 만들어 줄 수도 있습니다. 차이는 작업을 나누는 사람에게 있습니다.
솔로 메이커의 기본 패턴: PRD → Plan → 실행 → 검토
이제 이 장의 내용을 솔로 메이커의 실제 흐름으로 묶어 보겠습니다. 이 책 전체에서 반복할 기본 패턴은 간단합니다.
먼저 PRD를 씁니다. PRD라고 해서 거창할 필요는 없습니다. "왜 만들고, 누구를 위해 만들고, 어떤 상태가 성공인가"를 적으면 됩니다. 이 문서가 없으면 에이전트는 제품 결정을 임의로 채웁니다. 특히 혼자 제품을 만들 때는 머릿속에만 있던 기준을 문서로 꺼내는 일이 중요합니다.
다음으로 Plan Mode를 사용합니다. 코드를 바로 쓰게 하지 말고, 현재 코드베이스를 조사하게 합니다. 어떤 파일이 관련되어 있는지, 어떤 위험이 있는지, 어떤 테스트가 필요한지, 구현 순서는 어떻게 되는지 계획을 받습니다. 이 계획은 에이전트가 작성했지만, 승인자는 사람입니다.
그다음 작은 기능 구현을 맡깁니다. 이때 한 번의 실행에 너무 많은 것을 넣지 않습니다. "회원 시스템 개선"이 아니라 "비밀번호 재설정 재요청 제한 추가"처럼 작게 나눕니다. 하나의 실행은 하나의 명확한 결과를 가져야 합니다.
이후 테스트와 검증을 맡깁니다. 에이전트에게 "테스트도 해줘"라고 막연히 말하지 말고, 어떤 명령을 실행해야 하는지, 실패하면 어디까지 수정해도 되는지, 수동 검증이 필요한지 알려 줍니다. 자동 테스트가 없다면 수동 확인 절차라도 남기게 해야 합니다.
마지막으로 사람이 검토하고 병합합니다. diff를 읽고, 의도하지 않은 변경이 있는지 확인하고, 보안이나 비용에 영향을 줄 만한 결정이 없는지 봅니다. 필요하면 에이전트에게 요약을 요청하되, 요약만 믿지 말고 중요한 파일은 직접 봅니다.
이 흐름을 한 문장으로 줄이면 이렇습니다.
사람은 의도와 기준을 만들고, 에이전트는 실행안을 만들며, 사람은 결과를 선택한다.
이 패턴은 단순하지만 강력합니다. 왜냐하면 AI가 잘하는 것과 사람이 잘해야 하는 것을 분리하기 때문입니다. 에이전트는 빠르게 읽고, 쓰고, 반복합니다. 사람은 방향을 정하고, 우선순위를 판단하고, 책임을 집니다.
"코드를 짜 줘"에서 "이 일을 끝내 줘"로
Cursor를 쓰는 말투도 바뀌어야 합니다. 예전에는 "코드를 짜 줘"가 자연스러웠습니다. 하지만 에이전트 시대의 더 좋은 요청은 "이 일을 끝내 줘"입니다. 단, 여기서 "일"은 반드시 목표와 완료 조건이 있는 작은 단위여야 합니다.
나쁜 요청은 이렇게 생겼습니다.
관리자 페이지 만들어 줘.조금 나은 요청은 이렇습니다.
관리자 페이지의 사용자 목록 화면을 만들어 줘.
기존 디자인 시스템을 따르고, API는 /api/admin/users를 사용해.더 좋은 에이전트 실행 요청은 다음과 같습니다.
목표: 관리자 페이지에 사용자 목록 화면을 추가합니다.
범위:
- /admin/users 라우트와 해당 화면 컴포넌트만 추가합니다.
- 기존 관리자 레이아웃과 테이블 컴포넌트를 재사용합니다.
- 새 UI 라이브러리는 추가하지 않습니다.
작업 순서:
1. 기존 관리자 페이지 구조와 테이블 사용 예시를 찾아 요약합니다.
2. 구현 계획을 먼저 제안하고, 승인 전에는 파일을 수정하지 않습니다.
3. 승인 후 화면을 구현합니다.
4. 타입 체크를 실행하고 결과를 보고합니다.
완료 조건:
- 사용자 이름, 이메일, 가입일, 상태가 표시됩니다.
- 로딩/빈 상태/에러 상태가 있습니다.
- 기존 스타일과 어긋나는 임의의 디자인 변경을 하지 않습니다.이 프롬프트는 길어 보이지만, 실제로는 시간을 아낍니다. 에이전트가 임의로 관리자 레이아웃을 새로 만들거나, 새 테이블 라이브러리를 설치하거나, 인증 구조를 건드리는 일을 줄여 주기 때문입니다. 프롬프트 몇 줄을 아끼려다 나중에 diff 수백 줄을 되돌리는 일이 더 비쌉니다.
솔로 메이커에게 중요한 것은 빠른 시작이 아니라 빠른 수습입니다. 좋은 실행 단위는 수습 비용을 낮춥니다. 잘못되어도 어디서 잘못되었는지 보이고, 되돌리기도 쉽습니다.
에이전트 실행을 작게 나누는 감각
처음에는 어느 정도가 "작은 실행"인지 감이 잘 오지 않습니다. 기준은 간단합니다. 결과를 10분 안에 리뷰할 수 없다면 대체로 큽니다. 변경된 파일이 너무 많아 한눈에 보기 어렵거나, 제품 결정과 기술 결정이 섞여 있거나, 테스트 없이 감으로만 확인해야 한다면 더 쪼개야 합니다.
예를 들어 "구독 결제 기능 만들기"는 너무 큽니다. 여기에는 요금제 정책, 결제 제공자 연동, 웹훅 처리, 권한 제어, UI, 이메일, 환불 정책, 테스트가 모두 들어 있습니다. 이것을 한 번에 맡기면 에이전트는 많은 것을 임의로 결정합니다.
대신 다음처럼 나눌 수 있습니다.
PRD 작성: 무료/유료 플랜 차이, 결제 성공과 실패 흐름, 취소 정책을 문서화한다.
코드베이스 조사: 현재 사용자 모델, 권한 체크 위치, 결제 관련 기존 파일을 찾는다.
데이터 모델 제안: 구독 상태를 저장할 최소 스키마 변경안을 만든다.
웹훅 구현: 결제 성공/실패 이벤트 하나씩 처리한다.
UI 구현: 현재 구독 상태와 업그레이드 버튼을 표시한다.
검증: 웹훅 테스트 방법, 타입 체크, 주요 수동 테스트 시나리오를 정리한다.
이렇게 나누면 각각의 에이전트 실행은 훨씬 안전해집니다. 한 실행이 실패해도 전체를 버릴 필요가 없습니다. 데이터 모델 제안만 다시 시키거나, UI 구현만 다른 접근으로 바꿀 수 있습니다.
작게 나누는 것은 느린 방법이 아닙니다. AI가 빠를수록 더 작게 나누는 편이 전체 속도를 높입니다. 왜냐하면 작은 실행은 검토가 빠르고, 실패했을 때 손실이 작고, 병렬화하기 쉽기 때문입니다.
에이전트에게 맡기지 말아야 할 것도 정해야 한다
에이전트 시대의 위임은 "무엇을 맡길까"만의 문제가 아닙니다. "무엇을 맡기지 않을까"도 똑같이 중요합니다. 솔로 메이커는 특히 이 경계를 스스로 정해야 합니다. 팀에서는 코드 리뷰, 보안 검토, 제품 승인 같은 장치가 어느 정도 분산되어 있지만, 혼자라면 그 모든 게 자신에게 돌아옵니다.
에이전트에게 맡기기 전에 사람이 직접 판단해야 할 영역이 있습니다. 사용자 데이터 삭제 정책, 결제와 환불 정책, 개인정보 처리, 보안 권한 모델, 가격 정책, 핵심 제품 포지셔닝 같은 것들입니다. 에이전트는 참고안을 줄 수는 있지만 최종 결정을 내려서는 안 됩니다.
예를 들어 "사용자 탈퇴 기능 만들어 줘"라고 맡기면 에이전트는 사용자를 데이터베이스에서 바로 삭제하는 코드를 만들 수도 있습니다. 하지만 실제 제품에서는 법적 보관 의무, 결제 내역, 감사 로그, 복구 가능 기간, 연결된 팀 데이터 소유권 같은 문제가 있을 수 있습니다. 이런 결정은 코드 문제가 아니라 제품과 운영의 문제입니다.
따라서 좋은 프롬프트에는 "하지 말아야 할 것"도 들어갑니다.
주의:
- 사용자 레코드를 물리 삭제하지 마세요.
- 결제 내역과 감사 로그는 변경하지 마세요.
- 정책 판단이 필요한 부분은 TODO로 남기고 먼저 질문하세요.에이전트는 속도를 높여 주지만, 속도가 곧 안전은 아닙니다. 위임의 경계를 명확히 할수록 Cursor는 더 강력한 도구가 됩니다.
이 장의 핵심: 에이전트 실행 카드
이제부터 Cursor에서 중요한 작업을 시작할 때는 머릿속으로라도 "에이전트 실행 카드"를 만들어 보세요. 실제 문서로 남겨도 좋고, 프롬프트에 그대로 붙여 넣어도 좋습니다.
[에이전트 실행 카드]
1. 목표
이 실행이 끝났을 때 사용자가 얻는 변화는 무엇인가?
2. 배경
왜 이 작업이 필요한가? 관련 PRD, 이슈, 버그 리포트는 무엇인가?
3. 범위
수정해도 되는 파일/기능/화면은 어디까지인가?
수정하면 안 되는 것은 무엇인가?
4. 작업 방식
먼저 조사할 것인가, 바로 구현할 것인가?
계획 승인 후 진행해야 하는가?
5. 완료 조건
어떤 테스트, 타입 체크, 수동 확인, 문서 업데이트가 있어야 끝인가?
6. 보고 형식
작업 후 어떤 내용을 요약해야 하는가?
변경 파일, 검증 결과, 남은 위험을 포함할 것인가?이 카드는 앞으로 여러 장에서 계속 변형되어 등장합니다. PRD 장에서는 목표와 배경을 더 잘 쓰는 법을 다룹니다. Plan Mode 장에서는 작업 방식을 계획으로 바꾸는 법을 다룹니다. Rules 장에서는 반복되는 범위와 제약을 프로젝트 규칙으로 고정합니다. Skills 장에서는 자주 쓰는 실행 카드를 재사용 가능한 도메인 지식으로 패키지화합니다. 컨텍스트 관리 장에서는 에이전트가 필요한 정보만 잘 보게 하는 법을 다룹니다.
즉, 이 장은 Cursor 3.0 기능 소개가 아닙니다. 앞으로의 모든 워크플로우를 받쳐 주는 기본 단위를 정하는 장입니다. 그 단위가 바로 에이전트 실행입니다.
작은 제품 조직처럼 일하기
솔로 메이커는 혼자 일하지만, 혼자처럼 일하면 금방 한계가 옵니다. 머릿속에만 요구사항을 두고, 손으로만 코드를 고치고, 테스트는 나중으로 미루고, 문서는 기억에 맡기면 제품은 점점 복잡해집니다. AI를 붙여도 마찬가지입니다. 오히려 AI가 코드를 더 빨리 만들어 주기 때문에 혼란도 더 빨리 쌓일 수 있습니다.
그래서 Cursor 3.0 시대의 솔로 메이커는 작은 제품 조직처럼 일해야 합니다. PRD로 PM의 일을 하고, Plan Mode로 테크 리드의 일을 하고, Agent Mode로 구현을 위임하고, 테스트와 리뷰로 QA의 일을 하고, Cloud Agent와 Automations로 운영 업무를 넘깁니다. 다만 그 조직의 최종 책임자는 한 사람, 바로 당신입니다.
에이전트가 일의 단위가 된다는 것은 사람이 덜 중요해진다는 뜻이 아닙니다. 사람이 더 높은 수준의 일을 해야 한다는 뜻입니다. 코드를 직접 치는 시간은 줄어들 수 있습니다. 하지만 무엇을 만들지, 어떤 기준을 지킬지, 어떤 결과를 채택할지, 언제 배포할지는 더 신중히 판단해야 합니다.
이제 Cursor에서 새 작업을 시작할 때 이렇게 묻는 습관을 들여 봅시다.
"어떤 파일을 고칠까?"가 아니라,
"이 일을 어떤 에이전트 실행으로 나눌까?"
이 질문 하나가 Cursor를 쓰는 방식을 바꿉니다. 그리고 이 질문에 익숙해지는 순간, 당신은 AI에게 코드를 부탁하는 사용자를 넘어, 에이전트와 함께 제품을 운영하는 솔로 메이커가 됩니다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.