Cursor 핵심 정리 – Wayhope's DevLog

Cursor는 AI를 코드 에디터에 붙인 수준을 넘어, Agent를 중심으로 개발 작업 자체를 위임하는 환경으로 발전하고 있다.

특히 Cursor 3부터는 기존 IDE 화면에서 AI에게 코드를 생성시키는 방식보다 Agents Window에서 여러 Agent를 실행하고, Worktree나 Cloud 환경을 활용하고, Skills와 Subagents를 조합하는 방식이 중요해졌다. Cursor 3에서는 여러 Agent를 병렬로 실행할 수 있는 새로운 Agents Window가 추가됐다.

최근 Cursor의 구조를 보면 다음과 같이 이해하는 편이 좋다.

Cursor -> Agents Window / Skills / Rules / MCP / Hooks / Automations / Plugins

이제 Cursor를 이해하려면 단순히 “AI가 코드를 작성해준다”가 아니라 Agent를 어떻게 구성하고 일을 어떻게 분배하는가를 봐야 한다.

Agents Window

Cursor 3에서 가장 큰 변화 중 하나가 Agents Window다.

기존에는 IDE 안에서 하나의 Agent와 대화하면서 작업하는 방식이 중심이었다.

Cursor 3에서는 별도의 Agents Window에서 여러 Agent를 동시에 실행할 수 있다. 각 Agent를 로컬 환경, Worktree, Cloud, Remote SSH 등의 환경에서 실행할 수 있다.

구조를 단순하게 보면 이렇다.

Agents Window -> Agent A / Agent B / Agent C / Agent D

각 Agent는 서로 다른 작업을 담당할 수 있다.

Agent A -> Feature 구현
Agent B -> Bug 분석
Agent C -> Test 작성
Agent D -> Code Review

개발자가 하나의 Agent가 작업을 끝낼 때까지 기다리는 방식에서 벗어날 수 있다.

예를 들어

Agent A -> 로그인 기능 구현
Agent B -> 로그인 테스트 작성
Agent C -> 기존 인증 코드 분석
Agent D -> 관련 보안 문제 검토

처럼 여러 작업을 동시에 진행할 수 있다.

이런 구조가 Cursor 3의 핵심적인 변화다.

Agent

Agent는 Cursor에서 실제 개발 작업을 수행하는 주체다.

단순히 답변을 생성하는 것이 아니라 프로젝트를 탐색하고 파일을 읽고 수정하고 터미널 명령을 실행할 수 있다.

일반적인 흐름은 다음과 같다.

요구사항 -> Agent -> 코드베이스 탐색 -> 필요한 파일 확인 -> 계획 -> 코드 수정 -> 명령 실행 -> 테스트 -> 결과 보고

따라서 Agent에게 일을 시킬 때는 코드 한 줄을 어떻게 작성할지를 설명하기보다 무엇을 완성해야 하는지를 설명하는 편이 좋다.

예를 들어

Player 저장 시스템 추가 -> 기존 Player 구조 유지 -> JSON 저장 -> 기존 SaveManager API 유지 -> 테스트 추가

처럼 작업의 목적과 제약을 정의한다.

Agent의 Queue와 Steering

Agent가 작업 중일 때도 추가적인 지시를 전달할 수 있다.

기본적으로 다음 요청을 입력하면 현재 작업이 끝난 뒤 순서대로 처리되는 Queue에 들어간다.

현재 작업 완료 -> Queue에 등록된 다음 작업 실행

반대로 작업 중간에 방향을 바꾸거나 추가 지시를 즉시 전달하고 싶다면 Steering을 사용할 수 있다.

개발자 -> 첫 작업 -> Queue -> 다음 작업
개발자 -> Steering -> 현재 작업 방향 수정

이것도 Agent를 단순한 Chat과 구분하는 부분이다.

긴 작업을 시킬수록 이런 방식이 유용하다.

Multitask

Cursor 3.2에서 추가된 /multitask는 여러 작업을 병렬로 처리하기 위한 기능이다.

일반적인 순차 작업은 다음과 같다.

작업 A -> 완료 -> 작업 B -> 완료 -> 작업 C

Multitask를 사용하면 Async Subagent를 활용해 작업을 병렬화할 수 있다.

Main Agent -> Subagent A / Subagent B / Subagent C

예를 들어 대규모 기능을 작업하면서

인증 시스템 분석 / API 테스트 작성 / 관련 문서 확인

같은 요청을 Multitask로 처리하면 각각의 작업을 병렬적인 Subagent 작업으로 나눌 수 있다.

여기서 중요한 것은 Multitask가 단순히 Agent 창을 여러 개 띄우는 기능은 아니라는 것이다.

작업을 Subagent 단위로 분배하고 동시에 처리하는 개념이다.

Subagent

Subagent는 Agent가 특정 작업을 다른 Agent에게 위임하는 구조다.

각 Subagent는 별도의 Context Window에서 작업하고 결과를 부모 Agent에게 반환한다.

예를 들어 메인 Agent가 다음 작업을 받았다고 하자.

새로운 결제 시스템 구현 및 검증

메인 Agent가 내부적으로 작업을 분리할 수 있다.

Main Agent -> Subagent A / Subagent B / Subagent C / Subagent D
Subagent A -> 기존 결제 구조 조사
Subagent B -> API 구조 조사
Subagent C -> 테스트 작성
Subagent D -> 보안 검토

각각의 Context가 분리되기 때문에 메인 대화의 Context를 불필요한 조사 내용으로 채우지 않을 수 있다.

Subagent는 특히 조사, 검증, 병렬 작업에 잘 맞는다.

Skill

Skill은 특정 작업을 수행하는 방법을 Agent에게 제공하는 확장 기능이다.

Cursor의 Agent Skills는 특정 도메인의 지식과 Workflow, Script, Reference 등을 하나의 패키지로 구성할 수 있다. SKILL.md를 중심으로 구성되며 프로젝트나 사용자 단위로 설치할 수 있다.

Skill의 구조를 단순화하면 다음과 같다.

Skill -> SKILL.md / Scripts / References

SKILL.md에는 해당 작업을 Agent가 어떻게 수행해야 하는지가 들어간다.

예를 들어 Code Review Skill이라면

Code Review -> 변경 파일 확인 -> 관련 테스트 확인 -> 논리 오류 확인 -> 성능 문제 확인 -> 보안 문제 확인 -> 수정 항목 정리

같은 작업 절차를 Skill로 정의할 수 있다.

Cursor의 Built-in Skills

Cursor에는 기본적으로 제공되는 Skill도 있다.

대표적으로 다음과 같은 Built-in Skill을 사용할 수 있다.

/automate /babysit /canvas /create-hook /create-rule /create-skill /create-subagent /cursor-blame /loop /migrate-to-skills /review /review-bugbot /review-security /sdk /shell /split-to-prs /statusline /update-cli-config /update-cursor-settings

각각 목적이 다르다.

예를 들어

/review -> 코드 리뷰
/review-security -> 보안 취약점 검토
/create-skill -> 새로운 Skill 생성
/create-subagent -> 특정 역할의 Subagent 생성

처럼 사용할 수 있다.

Skill은 Agent Chat에서 /를 입력해서 검색하고 사용할 수 있다.

Skill의 자동 호출

Skill은 단순한 Slash Command와 조금 다르다.

Cursor는 Skill의 이름과 설명을 보고 현재 작업에 해당 Skill이 필요한지 판단할 수 있다.

예를 들어 Skill의 설명이

React 컴포넌트 생성 -> 프로젝트 React 규칙 적용 -> 기존 컴포넌트 패턴 적용

이라면 Agent가 React 컴포넌트를 만드는 상황에서 해당 Skill을 사용할 수 있다.

반대로 명시적인 호출만 허용하고 싶다면 disable-model-invocation: true를 사용할 수 있다.

자동 호출 허용 -> Agent가 필요성을 판단 -> Skill 실행
자동 호출 비활성화 -> /skill-name -> Skill 실행

Skill을 Custom Mode로 사용하는 방법

Skill을 단발성 작업이 아니라 현재 세션 전체에서 계속 적용되는 작업 방식으로 사용할 수도 있다.

Cursor에서는 Skill을 Custom Mode로 사용할 수 있다.

예를 들어 TDD Skill을 만들었다면

/TDD -> Custom Mode -> 세션 전체에 TDD Workflow 적용

같은 방식으로 사용할 수 있다.

이런 방식은

코드 리뷰 / TDD / 보안 검토 / 아키텍처 검토

처럼 작업 방식 자체를 유지해야 할 때 유용하다.

Skill과 Subagent의 차이

둘을 헷갈리기 쉽다.

핵심 차이는 간단하다.

Skill -> 작업 방법을 제공한다.
Subagent -> 작업 자체를 별도의 Agent에게 위임한다.

예를 들어

Skill -> "코드 리뷰할 때 이 체크리스트를 사용해라."
Subagent -> "코드 리뷰를 전담해서 독립적으로 수행해라."

Skill은 Knowledge / Workflow에 가깝고, Subagent는 독립적인 작업 실행 단위에 가깝다.

Worktree

Agent가 코드를 수정할 때 현재 작업 공간과 충돌할 수 있다.

이 문제를 해결하기 위한 방법 중 하나가 Worktree다.

Git Worktree를 이용하면 서로 다른 작업을 독립된 작업 공간에서 실행할 수 있다.

main -> Worktree A / Worktree B / Worktree C

각 Worktree에서 서로 다른 작업을 수행할 수 있다.

Worktree A -> 로그인 작업
Worktree B -> 인벤토리 작업
Worktree C -> 버그 수정

Agent를 여러 개 동시에 돌릴수록 Worktree가 중요해진다.

Multi-root Workspace

여러 저장소를 하나의 작업 환경에서 다뤄야 할 때는 Multi-root Workspace를 사용할 수 있다.

예를 들어

Workspace -> Frontend / Backend / Shared

처럼 여러 Repository를 하나의 Workspace에 구성할 수 있다.

게임 개발에서도

Workspace -> GameClient / GameServer / SharedProtocol / Tools

처럼 프로젝트가 분리되어 있다면 활용할 수 있는 구조다.

Automation

Automation은 Agent에게 일을 시키는 것에서 한 단계 더 나아간다.

개발자가 직접 Agent를 실행하는 것이 아니라 특정 이벤트가 발생하면 Agent가 자동으로 실행되도록 만드는 기능이다.

구조는 다음과 같다.

Trigger -> Automation -> Cloud Agent -> Context / Tools / MCP / Model -> 결과

예를 들어

GitHub PR 생성 -> Automation 실행 -> Agent 코드 리뷰 -> 문제 발견 -> 결과 작성

같은 Workflow를 만들 수 있다.

Automation과 Agent의 차이

일반 Agent는 개발자가 실행한다.

개발자 -> Agent 실행 -> 작업

Automation은 이벤트가 Agent를 실행한다.

이벤트 -> Automation -> Agent 실행 -> 작업

이 차이가 크다.

Automation을 잘 구성하면 반복적인 관리 업무를 사람이 직접 실행하지 않아도 된다.

`/automate`

Cursor에는 /automate Skill도 제공된다.

Agent Chat에서 /automate를 사용하고 자동화하고 싶은 작업을 자연어로 설명하면 Cursor가 Trigger, Instructions, Tools 등을 구성하는 방식으로 Automation을 만들 수 있다.

예를 들어

매일 오전 -> GitHub 열린 Issue 확인 -> 우선순위 높은 버그 분석 -> 결과 정리

같은 요구사항을 Automation으로 만들 수 있다.

Automation은 AI에게 일을 시킨다보다 AI가 알아서 일을 시작하게 만든다는 관점으로 보면 이해하기 쉽다.

Hooks

Hooks는 Agent의 실행 과정에 특정 Script를 연결하는 기능이다.

Agent Lifecycle의 특정 시점에서 Script를 실행하거나 Agent Loop를 관찰하고 제어하는 데 사용할 수 있다.

예를 들어

Agent 수정 -> Hook -> Formatter -> Static Analysis -> Test

처럼 Agent가 코드를 수정한 뒤 자동으로 검증하도록 만들 수 있다.

또는 Agent가 특정 작업을 수행하기 전에 검증 로직을 넣을 수도 있다.

Skill이 작업 방법을 정의한다면 Hook은 Agent 실행 과정에 자동으로 개입하는 장치에 가깝다.

Rules

Rules는 프로젝트에서 Agent가 따라야 할 지속적인 지침이다.

예를 들어

Rules -> C++17 사용 / 스마트 포인터 규칙 / 계층 간 직접 참조 금지 / 네이밍 규칙 / 테스트 규칙

같은 것을 정의할 수 있다.

정리하면

Rule -> 항상 지켜야 할 기준
Skill -> 특정 작업을 수행하는 방법
Subagent -> 별도의 Agent에게 작업 위임
Hook -> Agent 실행 과정에 자동 개입

이다.

MCP

MCP는 Cursor Agent가 외부 도구나 데이터에 접근할 수 있게 하는 연결 계층이다.

예를 들어

Cursor Agent -> GitHub / Database / Slack / 외부 API / 기타 개발 도구

같은 환경을 연결할 수 있다.

MCP가 중요한 이유는 Agent가 IDE 안의 코드만 보는 것에서 벗어나 개발 환경 전체와 연결될 수 있기 때문이다.

Commands

Commands는 /로 호출하는 재사용 가능한 명령이다.

예를 들어

/review -> 코드 리뷰
/shell -> Shell 작업

처럼 사용할 수 있다.

현재 Cursor에서는 기존 Commands와 Dynamic Rules를 Skills로 마이그레이션할 수 있도록 /migrate-to-skills도 제공한다.

새로운 구조에서는 단순 반복 Prompt보다는 Skill로 Workflow를 구성하는 방향이 더 강해지고 있다고 보면 된다.

Plugins

Plugin은 여러 확장 요소를 하나의 패키지로 묶어 배포하는 방식이다.

하나의 Plugin에

Plugin -> Rules / Skills / Agents / Commands / MCP Servers / Hooks

등을 포함할 수 있다.

따라서 팀에서 사용하는 개발 Workflow를 Plugin 형태로 만들어 배포하는 것도 가능하다.

예를 들어

Plugin -> 회사 Coding Rules / Code Review Skill / Security Skill / GitHub MCP / Custom Subagent

처럼 구성할 수 있다.

실제로 어떻게 조합해서 사용하는가

이 기능들은 각각 따로 사용하는 것보다 조합했을 때 의미가 있다.

예를 들어 새로운 게임 기능을 추가한다고 해보자.

개발자 -> Agent -> Context / Rules / Skills / Subagent / MCP / Hooks -> 실제 작업

각 요소의 역할을 세분화하면 다음과 같다.

Agent -> 작업 실행
Rules -> 프로젝트 아키텍처 규칙
Skills -> 기능 추가 Workflow
Subagent -> 코드 조사 / 테스트 작성 / 리뷰
MCP -> 외부 데이터 / 개발 도구 연결
Hooks -> 자동 검증

그리고 여러 기능을 동시에 처리해야 한다면

Agents Window -> Agent A / Agent B / Agent C
Agent A -> 전투 시스템
Agent B -> UI
Agent C -> 테스트

처럼 분리할 수 있다.

각 작업이 서로 충돌할 가능성이 있다면 Worktree로 격리한다.

Agent A -> Worktree A
Agent B -> Worktree B
Agent C -> Worktree C

Cursor에서 자주 쓰게 될 기능을 정리하면

기능	역할
Agent	실제 개발 작업 수행
Agents Window	여러 Agent 관리 및 병렬 작업
Multitask	여러 작업을 Async Subagent로 병렬 처리
Subagent	특정 작업을 별도 Context에서 위임
Worktree	Agent 작업을 Git 작업 공간별로 격리
Multi-root	여러 Repository를 하나의 Workspace에서 작업
Skill	특정 작업의 지식과 Workflow 제공
Rules	프로젝트의 지속적인 개발 규칙
Automation	Trigger에 따라 Agent 자동 실행
Hook	Agent Lifecycle에 Script 연결
MCP	외부 도구와 데이터 연결
Command	`/`로 실행하는 재사용 명령
Plugin	Rules, Skills, MCP 등을 패키지화
Tab	코드 작성 중 AI 자동완성

결국 Cursor의 핵심 구조

Cursor 3 이후의 구조를 한 번에 정리하면 다음과 같다.

Cursor -> Agents Window -> Agent A / Agent B / Agent C -> Context / Rules / Skills / Subagent / Tools / MCP / Hooks -> 실제 작업 -> Worktree / Branch -> 검증 / Review

여기에 Automation을 붙이면 구조가 달라진다.

Event / Schedule -> Automation -> Cloud Agent -> Skills / Rules / MCP / Tools -> 결과

결국 Cursor는 AI 코드 생성기에서 Agent 기반 개발 환경으로 넘어가고 있다.

개발자가 직접 모든 코드를 작성하고 AI에게 일부 코드를 추천받는 구조에서는 Tab이 중요했다.

지금은 그보다 큰 단위로 올라왔다.

코드 한 줄 -> 함수 -> 파일 -> 기능 -> 작업 단위 -> 여러 작업 -> 자동화된 Workflow

Cursor의 기능도 이 방향으로 확장되고 있다.

그래서 Cursor를 제대로 사용하려면 Agent 하나만 이해해서는 부족하다. Agent, Subagent, Multitask, Skills, Rules, Worktree, Automation, Hooks, MCP가 각각 어떤 문제를 해결하는지 구분하고, 필요한 것들을 조합할 수 있어야 한다.

특히 Skill과 Subagent의 차이는 명확하게 잡아두는 것이 좋다.

Skill -> "이 작업은 이런 방식으로 해라."
Subagent -> "이 작업을 네가 맡아서 해라."
Multitask -> "이 작업들을 여러 Agent가 동시에 처리해라."
Automation -> "이 이벤트가 발생하면 Agent가 알아서 해라."
Rules -> "어떤 작업을 하더라도 이 규칙은 지켜라."
Hooks -> "Agent가 이 단계에 도달하면 이 동작을 실행해라."
MCP -> "Agent가 이 외부 도구를 사용할 수 있게 해라."

이 정도로 역할을 나눠두면 Cursor의 기능들이 단순히 많은 기능 목록으로 보이지 않는다.

Agent를 중심으로 작업을 정의하고, 필요한 지식은 Skill과 Rules로 주입하고, 복잡한 작업은 Subagent와 Multitask로 분리하고, 외부 시스템은 MCP로 연결하고, 반복 작업은 Automation으로 넘기는 구조다.