“AI가 코드를 써 준다”는 말은 맞지만, 너무 작다.
내가 Cursor를 쓰며 얻은 더 큰 감각은 이쪽이다.
티켓, 코드, 채팅, 브라우저, 터미널, 문서를 한 흐름으로 이어 주는 작업 운영체제.

이 글은 Cursor 사용법을 한 번에 정리해 보려는 시도다.

완벽한 가이드는 아니다.
그래서 제목에 물음표를 붙였다.

그래도 꽤 길게 쓴다.

내가 최근 몇 달 동안 Cursor와 함께 한 일은 단순한 자동완성 수준을 넘었다.

• 오래된 프론트엔드 모노레포에서 파일을 찾고
• 여러 코드 경로를 비교하고
• GitHub, Jira/Confluence, Slack, 로컬 git 기록을 함께 보고
• 내부 문서를 읽어 성과 보고서 형태로 다시 구성하고
• 브라우저나 CLI까지 곁들여 검증하고
• 실패하면 권한, SSO, MCP 세션, 로컬 클론 같은 현실 문제를 우회했다.

이 글은 그 경험을 바탕으로 쓴다.

회사 코드와 내부 자료는 그대로 적지 않는다.
예시는 익명화한다.
다만 어떤 식으로 일을 나누고, 무엇을 맡기고, 어디서 사람이 판단해야 하는지는 최대한 구체적으로 적어 보겠다.

이 글을 읽는 법

이 글은 한 번에 외우는 매뉴얼이 아니다.
차라리 책상 옆에 두는 얇은 책 몇 권을 한 권으로 묶은 것에 가깝다.

켄트 벡의 책들을 좋아하는 이유가 있다.
분량이 압도적이지 않은데, 읽고 나면 손이 바뀐다.
TDD를 설명할 때도 거창한 선언보다 “빨강, 초록, 리팩터”처럼 손에 잡히는 리듬을 남긴다.

이 글도 그렇게 읽히면 좋겠다.

• 신입 개발자는 “Cursor로 React 코드를 어떻게 처음부터 만들어 볼까”를 따라가면 된다.
• 실무자는 “내가 하려는 일이 Cursor에 맞는 일인가”를 찾으면 된다.
• 리드는 “팀 규칙, 자동화, 보안선, 리뷰 기준을 어디까지 도구에 넣을까”를 보면 된다.
• 이미 Claude나 다른 Agent를 쓰는 사람은 “Cursor가 더 편한 표면은 무엇인가”를 비교하면 된다.

그래서 순서는 이렇다.

1. 먼저 Cursor의 감각을 잡는다.
2. 작은 React 코드를 만들어 본다.
3. 실무 코드에서 탐색, 수정, 검증, 문서화를 연결한다.
4. MCP, 브라우저, CLI, 자동화로 반경을 넓힌다.
5. Claude와 비교해 자기 작업 방식에 맞게 섞는다.
6. 마지막에는 하지 말아야 할 일을 기억한다.

Cursor는 도구다.
하지만 도구가 커지면 작업 방식도 같이 바뀐다.
이 글은 기능 목록보다 작업 방식의 이동을 설명하려고 한다.

Cursor를 처음 켤 때 기대해야 하는 것

Cursor를 “AI 코드 생성기”라고 생각하면 반만 맞다.

물론 코드를 만든다.
하지만 실무에서 더 자주 도움이 되는 일은 이렇다.

• 코드베이스에서 관련 파일 후보를 찾는다.
• 비슷한 코드 경로 두 개를 비교한다.
• 변경 전후 의도를 PR 문장으로 바꾼다.
• 문서, 티켓, 커밋, 채팅에 흩어진 맥락을 하나의 설명으로 묶는다.
• 테스트나 타입체크를 실행하고 실패 지점을 요약한다.
• 브라우저를 열어 실제 UI 상태를 확인한다.
• 외부 도구(MCP)를 통해 GitHub, Jira, Confluence, Figma 같은 곳에서 자료를 가져온다.

그래서 나는 Cursor를 이렇게 부르는 편이 더 맞다고 느낀다.

맥락을 읽고, 이동 비용을 줄여 주는 개발 작업 인터페이스.

여기서 핵심은 “대신 판단한다”가 아니다.
오히려 반대다.

Cursor를 잘 쓰면, 사람이 판단해야 할 지점이 더 빨리 드러난다.

이 파일을 고칠지, 저 파일을 고칠지.
기존 패턴을 따를지, 이번에 새 구조를 만들지.
이 요구사항이 진짜인지, 방금 채팅에서 바뀐 것인지.
테스트 실패가 내 변경 때문인지 원래 깨져 있던 것인지.

Cursor는 이 질문들을 없애지 않는다.
대신 더 빨리 앞에 꺼내 놓는다.

Cursor다운 부분은 어디에 있나

여기까지 읽으면 이런 생각이 들 수 있다.

“이건 Cursor만의 이야기가 아니라, Claude나 ChatGPT에도 할 수 있는 말 아닌가?”

맞다.
좋은 질문의 순서, 먼저 읽고 나중에 고치기, 테스트를 먼저 생각하기 같은 원칙은 특정 도구에 종속되지 않는다.

그럼에도 Cursor에서 유독 편해지는 지점이 있다.
나는 그 차이가 모델보다 IDE와 코드베이스에 붙어 있는 방식에서 온다고 본다.

1. Codebase Indexing: “찾기”의 기본값이 달라진다

Cursor는 프로젝트를 열면 코드베이스를 인덱싱한다.
그래서 단순 문자열 검색만 하는 것이 아니라, “이 기능이 어디쯤 있을지”를 의미 단위로 찾아갈 수 있다.

예를 들어:

주문서에서 혜택 금액을 계산하는 흐름을 찾아줘.
쿠폰, 포인트, 결제수단이 만나는 지점을 우선적으로 봐줘.

이런 요청은 단순 grep으로는 애매하다.
검색어가 benefit인지, discount인지, coupon인지, promotion인지 모르기 때문이다.

Cursor의 인덱싱은 여기서 첫 후보를 잡는 데 도움을 준다.

다만 한계도 있다.

• 최근 생성한 파일이 아직 인덱스에 잘 안 잡힐 수 있다.
• 큰 모노레포에서는 의미 검색 결과가 넓게 퍼질 수 있다.
• 비슷한 이름의 레거시 코드가 많으면 엉뚱한 경로를 먼저 볼 수 있다.
• generated file, build output, archive 폴더가 많으면 노이즈가 커질 수 있다.

그래서 나는 인덱싱 결과를 그대로 믿지 않는다.

의미 검색으로 후보를 찾은 뒤,
실제 import/call graph 기준으로 다시 검증해줘.
가능하면 rg 검색과 파일 읽기를 함께 사용해줘.

이렇게 시킨다.

의미 검색은 지도 후보이고,
실제 호출 관계는 도로 확인이다.

2. 열려 있는 파일과 diff를 같이 물고 간다

Cursor의 큰 장점은 내가 지금 보고 있는 파일, 최근 열어 본 파일, diff, linter 상태가 대화와 가깝다는 점이다.

일반 챗봇에서는 내가 파일을 복사해서 붙여야 한다.
터미널형 Agent에서는 파일 경로를 정확히 알려줘야 할 때가 많다.

Cursor에서는 이런 식이 자연스럽다.

지금 열어 둔 파일과 최근에 본 주문서 폼을 비교해서,
배송지 상태 업데이트 방식이 왜 다른지 설명해줘.

또는:

방금 수정한 diff를 리뷰어 관점으로 봐줘.
기능 리스크, 테스트 누락, 기존 패턴 위반만 찾아줘.

이건 단순한 편의가 아니다.
작업 중인 개발자의 시선과 Agent의 시선이 같은 표면에 놓인다.

3. Composer에서 Agent로: 한 화면 안의 수정 루프

Cursor를 오래 쓴 사람은 Composer라는 이름에 익숙할 수 있다.
최근에는 Agent/Chat 중심으로 흐름이 정리되었지만, 핵심 감각은 비슷하다.

여러 파일을 한 번에 읽고, 수정 계획을 만들고, diff를 제안하고, 내가 승인하거나 되돌리는 루프다.

중요한 건 “한 번에 많이 고친다”가 아니다.

좋은 루프는 이렇다.

1. 관련 파일 후보를 찾는다.
2. 수정 계획을 설명한다.
3. 작은 diff를 만든다.
4. 내가 diff를 읽는다.
5. 테스트/타입체크/브라우저 확인을 붙인다.
6. 필요한 만큼 반복한다.

이 루프가 IDE 안에서 끊기지 않는 것이 Cursor의 장점이다.

4. Inline Edit와 Agent를 구분한다

작은 문장, 작은 함수, 작은 JSX 정리는 Inline Edit가 낫다.
반대로 여러 파일을 읽고 판단해야 하면 Agent가 낫다.

나는 이렇게 나눈다.

모든 일을 Agent에게 맡기면 오히려 느려진다.
반대로 모든 일을 Inline Edit로 하면 맥락을 놓친다.

Cursor의 생산성은 기능 하나가 아니라, 이 표면들을 오가며 생긴다.

설치와 첫 세팅

설치 자체는 어렵지 않다.

1. Cursor 데스크톱 앱을 설치한다.
2. 로그인한다.
3. 평소 작업하던 프로젝트 폴더를 연다.
4. VS Code에서 쓰던 확장, 설정, 키맵을 필요한 만큼 가져온다.
5. Agent 패널을 열고, 바로 큰 일을 시키지 말고 먼저 코드베이스를 읽게 한다.

처음 시킬 만한 질문은 이런 것이다.

이 저장소의 전체 구조를 먼저 설명해줘.
어떤 앱과 패키지가 있고, 주요 개발 명령어는 어디에 정의돼 있는지 찾아줘.
아직 파일은 수정하지 말고 읽기만 해줘.

혹은:

이 프로젝트에서 새 기능을 넣을 때 따라야 할 규칙이 어디에 있는지 찾아줘.
AGENTS.md, README, docs, package.json, lint 설정을 우선 확인해줘.

첫날에는 “코드 만들어 줘”보다 “이 프로젝트의 지도를 그려 줘”가 낫다.

Cursor는 작업 폴더 안의 규칙 파일을 꽤 잘 따른다.

• AGENTS.md
• .cursor/rules
• CLAUDE.md
• README.md
• 패키지별 문서
• lint/typecheck/test 설정

이런 파일들이 있으면 먼저 읽게 하는 것이 좋다.

팀 프로젝트라면 특히 그렇다.
AI는 프로젝트의 오래된 습관을 모르면, 그럴듯한 새 습관을 만들어낸다.

그럴 때 나오는 코드는 보통 “동작할 수도 있지만 우리 코드가 아닌” 코드다.

신입 개발자를 위한 첫 React 실습

Cursor를 처음 쓰는 신입이라면 거대한 기능부터 만들 필요가 없다.

처음 목표는 이것이면 충분하다.

작은 컴포넌트를 하나 만들고, 상태를 바꾸고, 테스트하고, 리뷰 문장까지 써 본다.

예를 들어 “쿠폰 선택 카드” 같은 익명화된 UI를 만든다고 해 보자.

요구사항:

- 쿠폰 이름을 보여준다.
- 할인 금액을 보여준다.
- 선택 가능하면 버튼을 활성화한다.
- 이미 선택된 쿠폰이면 "선택됨" 상태를 보여준다.
- 비활성 사유가 있으면 안내 문구를 보여준다.

처음부터 이렇게 시키면 안 된다.

쿠폰 컴포넌트 만들어줘.

대신 이렇게 시작한다.

이 프로젝트에서 카드 형태 UI 컴포넌트를 어떻게 작성하는지 찾아줘.
비슷한 컴포넌트 3개를 찾고, props 설계와 스타일링 패턴을 요약해줘.
아직 파일은 만들지 마.

그러면 Cursor가 먼저 프로젝트의 언어를 배운다.

그 다음:

방금 찾은 패턴을 기준으로 CouponSelectCard 컴포넌트 초안을 제안해줘.
아직 구현하지 말고 props 타입과 렌더링 상태만 설명해줘.

이 단계에서 사람은 props 이름을 고른다.

예:

type CouponSelectCardProps = {
  title: string;
  discountText: string;
  selected: boolean;
  disabledReason?: string;
  onSelect: () => void;
};

이제 구현을 시킨다.

이 props 설계로 컴포넌트를 만들어줘.
기존 카드 컴포넌트의 스타일 패턴을 따르고,
disabledReason이 있으면 버튼은 비활성화하고 안내 문구를 보여줘.

중요한 건 다음이다.

구현이 끝났다고 끝이 아니다.

이 컴포넌트의 상태별 렌더링 케이스를 테스트 코드로 작성해줘.
테스트 파일 위치는 기존 컴포넌트 테스트 패턴을 먼저 확인하고 맞춰줘.

좋은 테스트 케이스(TC)는 보통 구현보다 먼저 사람의 머리를 정리한다.

테스트 케이스는 이런 식으로 나뉜다.

• 기본 쿠폰 이름과 할인 금액이 보인다.
• 선택되지 않은 쿠폰은 선택 버튼이 보인다.
• 선택된 쿠폰은 “선택됨” 상태가 보인다.
• 비활성 사유가 있으면 버튼이 비활성화되고 안내 문구가 보인다.
• 버튼 클릭 시 onSelect가 호출된다.

Cursor가 테스트를 만들면 마지막으로 이렇게 묻는다.

이 테스트가 구현 상세에 너무 의존하는 부분이 있는지 리뷰해줘.
사용자에게 보이는 동작 중심으로 바꿀 부분이 있으면 제안해줘.

이 한 줄이 중요하다.

AI는 테스트도 너무 쉽게 만든다.
너무 쉽게 만든 테스트는 내부 className, DOM 구조, 구현 상세에 들러붙기 쉽다.

신입에게 Cursor가 좋은 이유는 코드를 대신 써 줘서가 아니다.
“좋은 질문의 순서”를 손에 익히게 해 줄 수 있어서 좋다.

1. 기존 패턴을 찾는다.
2. props와 상태를 먼저 설계한다.
3. 구현한다.
4. 사용자 동작 기준으로 테스트한다.
5. 리뷰 문장을 만든다.

이 리듬을 익히면, Cursor가 없어도 개발을 더 잘하게 된다.

React 코드에서 Cursor에게 맡기기 좋은 단위

React 실무에서 Cursor에게 맡기기 좋은 단위는 대략 이렇다.

컴포넌트 상태 나누기

이 컴포넌트가 지금 너무 많은 조건부 렌더링을 갖고 있어.
사용자 상태 기준으로 상태를 4~5개로 분류해줘.
분류만 하고 수정은 하지 마.

AI는 if 문을 잘 읽는다.
사람은 if 문을 읽다가 정책을 놓친다.

먼저 상태표를 만들게 하면 좋다.

예:

이 표가 나오면 구현이 쉬워진다.

Hook 분리 검토

나쁜 요청:

이거 hook으로 빼줘.

좋은 요청:

이 컴포넌트에서 hook으로 분리할 만한 상태/부수효과/파생값을 구분해줘.
분리했을 때 좋아지는 점과 오히려 복잡해지는 점을 비교해줘.

모든 분리는 좋은 것이 아니다.

AI는 분리를 좋아한다.
사람은 분리 후에 남는 책임 경계를 봐야 한다.

서버 상태와 UI 상태 구분

이 컴포넌트의 상태를 서버에서 온 데이터, 사용자 입력 상태, UI 표시 상태로 나눠줘.
각 상태가 어디서 만들어지고 어디서 바뀌는지 추적해줘.

React 버그의 상당수는 이 셋이 섞일 때 생긴다.

Cursor는 추적을 잘한다.
사람은 그 결과를 보고 경계를 정해야 한다.

접근성 확인

이 폼 컴포넌트에서 label, button name, disabled 상태, error message 연결이 접근성 관점에서 괜찮은지 확인해줘.
문제가 있으면 사용자 동작 기준으로 수정안을 제안해줘.

AI에게 “예쁘게”보다 “접근 가능하게”를 시키는 편이 낫다.

코드 리뷰 사전 점검

이 diff를 리뷰어 관점에서 봐줘.
버그 가능성, 빠진 테스트, 과한 추상화, 기존 패턴 위반만 찾아줘.
칭찬이나 요약은 짧게 해줘.

이건 꽤 잘 맞는다.

다만 마지막 판단은 사람 몫이다.
AI 리뷰는 “놓친 것 후보”이지 “승인”이 아니다.

모드 감각: Ask, Plan, Agent

Cursor를 쓸 때 중요한 감각은 “무슨 모델을 고를까”보다 “어떤 모드로 일을 시작할까”에 가깝다.

나는 대략 이렇게 나눈다.

Ask: 읽기 전용 탐색

코드를 바꾸지 말고 알고 싶을 때 쓴다.

이 훅이 어떤 화면에서 쓰이는지 찾아줘.
수정하지 말고 호출 경로만 설명해줘.

이 API 응답 모델이 주문서와 주문 완료 화면에서 어떻게 다르게 쓰이는지 비교해줘.

Ask는 “내 머릿속 index를 만드는 시간”을 줄여 준다.

Plan: 큰 일의 설계

여러 파일을 건드릴 것 같거나 요구사항이 애매하면 바로 수정시키지 않는다.

이 요구사항을 반영하려면 어떤 파일을 봐야 하는지 조사하고,
가능한 구현안 2개와 리스크를 정리해줘.
아직 수정하지 마.

Plan의 장점은, 틀린 길로 빠르게 달리는 것을 막아 준다는 점이다.

나는 Cursor를 쓰며 이 말을 자주 떠올렸다.

AI의 속도는 틀린 방향에서도 빠르다.

큰 일은 먼저 방향을 맞춘다.

Agent: 실행

방향이 맞으면 그때 파일을 고치게 한다.

방금 계획의 1안으로 구현해줘.
기존 패턴을 유지하고, 변경 범위는 주문서 폼과 공유 훅에만 제한해줘.
수정 후 관련 타입체크나 lint를 확인해줘.

Agent는 일꾼처럼 부려야 한다.
다만 “알아서 잘”은 금물이다.

좋은 지시는 대개 이런 성질을 갖는다.

• 범위가 있다.
• 변경하지 말아야 할 것이 있다.
• 검증 방법이 있다.
• 기존 패턴을 먼저 읽으라는 말이 있다.
• 실패했을 때 멈추라는 조건이 있다.

좋은 프롬프트와 나쁜 프롬프트

나쁜 프롬프트:

장바구니 쪽 잘 봐줘.

이건 너무 크다.

Cursor는 친절하게 뭔가를 찾고, 뭔가를 고치고, 뭔가를 설명할 것이다.
하지만 그게 내가 원한 일인지는 모른다.

조금 나은 프롬프트:

장바구니 상품행의 바로구매 버튼과 주문서의 결제 버튼이
쿠폰 발급 로직을 다르게 타는지 비교해줘.
관련 파일 후보를 찾고, 차이만 요약해줘.
아직 수정하지 마.

더 좋은 프롬프트:

문제:
- 주문서 진입 시에는 미발급 쿠폰이 자동 발급된다.
- 장바구니 상품행의 바로구매 진입에서는 같은 쿠폰이 발급되지 않는다.

요청:
1. 두 진입 경로의 코드 흐름을 비교해줘.
2. 이미 존재하는 주문서 쪽 패턴을 재사용할 수 있는지 판단해줘.
3. 수정 범위와 리스크를 먼저 설명해줘.
4. 내가 승인하기 전에는 파일을 수정하지 마.

핵심은 “행동 단위”다.

• 비교해줘
• 후보를 찾아줘
• 차이를 요약해줘
• 수정 범위를 제안해줘
• 승인 전에는 고치지 마

AI에게 “잘해줘”라고 하면 안 된다.
AI에게는 “무슨 행동을 어떤 순서로 할지”를 줘야 한다.

Cursor가 특히 잘하는 일

1. 비슷한 코드 경로 비교

회사 코드에는 같은 기능이 조금 다른 경로로 구현된 경우가 많다.

예를 들면 익명화하면 이런 식이다.

• 일반 주문서 진입
• 장바구니에서 바로구매 진입
• 주문 완료 화면
• 마이페이지에서 재진입

사람이 직접 따라가려면 피곤하다.

Cursor에는 이렇게 시킬 수 있다.

일반 주문서 진입과 장바구니 바로구매 진입에서
혜택 계산 요청이 어느 시점에 호출되는지 비교해줘.
파일명, 함수명, 호출 순서만 표로 정리해줘.

이때 Cursor는 코드를 “작성”하기 전에 “지도”를 만든다.

이 지도는 리뷰에도 쓸 수 있다.

PR 첫 문단에:

이번 변경은 일반 주문서 진입과 바로구매 진입의 혜택 처리 시점을 맞추는 작업입니다.
기존 주문서 흐름의 쿠폰 발급 패턴을 바로구매 진입에도 적용했습니다.

이런 문장이 생긴다.

2. 오래된 규칙 찾기

모노레포에는 규칙이 흩어져 있다.

• 어떤 라우터를 써야 하는지
• 어떤 feature flag 패키지를 써야 하는지
• localStorage에 직접 접근해도 되는지
• Tailwind token이 표준 Tailwind와 다른지
• 앱별로 금지된 패턴이 있는지

사람은 기억으로 일하다가 틀린다.
Cursor는 기억 대신 파일을 읽게 만들 수 있다.

새 feature flag를 추가해야 해.
이 코드베이스에서 권장되는 feature flag 사용 규칙을 먼저 찾아줘.
legacy 패턴이 있으면 새 코드에서 피해야 할 것도 같이 정리해줘.

중요한 건 “먼저 찾아줘”다.

AI가 알고 있는 일반 지식보다, 현재 저장소의 규칙이 더 중요하다.

3. 성과 정리와 문서화

최근에 특히 유용했던 건 코드 작성이 아니라 성과 정리였다.

커밋은 저장소에 있다.
PR은 GitHub에 있다.
성과 가이드는 PDF에 있다.
전략 문서는 Confluence에 있다.
내가 PM, PD, BE와 조율한 내용은 채팅과 머릿속에 있다.

이걸 사람이 처음부터 엮으면 오래 걸린다.

Cursor에는 이렇게 시킬 수 있다.

최근 6개월 동안 기본 브랜치에 들어간 내 작업을 월별 역순으로 정리해줘.
그 다음 회사의 목표 작성 가이드에 맞춰 Objective/KR/SBI 형태로 재구성해줘.
단, 외부 공개가 아니라 내부 제출용 문서로 작성해줘.

물론 처음부터 완벽하진 않다.

실제로는 여러 번 고쳤다.

• “전략과제를 그대로 복붙하지 말고 내 일의 성질로 목표를 다시 만들자”
• “특정 결제·혜택 프로그램이라고 너무 좁히면 연말 목표로 쓰기 어렵다”
• “정량 KPI가 빈약하니 정성 중심으로 쓰자”
• “코드 만든 느낌 말고 제품 만든 느낌으로 쓰자”
• “PM/PD/BE와 협업해 효과를 키운 점도 넣자”
• “파트너 운영 콘솔은 부수 화면 개선보다 계정 통합과 접근 정책이 핵심이다”

이 과정에서 Cursor는 초안을 계속 바꿔 줬다.
사람은 방향을 잡았다.

이 조합이 좋았다.

Cursor가 자주 틀리는 일

1. 권한이 되는 줄 안다

MCP가 연결됐다고 해서 모든 데이터에 접근 가능한 것은 아니다.

예를 들어 GitHub MCP에서 내 계정 정보는 잘 가져오는데, 조직 private repository의 commit API는 404나 422를 줄 수 있다.

이건 “레포가 없다”가 아니라 “권한이 없다”일 수 있다.

비슷하게:

• GitHub CLI 토큰이 만료될 수 있다.
• 조직 SSO 승인이 안 되어 있을 수 있다.
• 브라우저로 열면 로그인 페이지나 JavaScript load error가 나올 수 있다.
• MCP 세션은 살아 있어도 특정 리소스 권한은 없을 수 있다.

그래서 나는 권한 관련 작업을 할 때 이렇게 시킨다.

먼저 인증 상태를 확인해줘.
실패하면 실패 원인이 토큰인지, SSO인지, private repo 권한인지 구분해줘.
가능하면 로컬 git 기록으로 대체 가능한지도 확인해줘.

그리고 결과 문서에는 한계를 적는다.

일부 저장소는 원격 fetch가 SSO 이슈로 제한되어 로컬 동기화 시점 기준으로 집계했다.

이 한 줄이 중요하다.

AI가 만든 숫자보다, 숫자의 출처와 한계를 적는 태도가 더 중요하다.

2. 공개하면 안 되는 것을 공개 가능한 문장으로 착각한다

내부 문서, 티켓, Slack, Confluence, PR, 고객 이슈를 그대로 블로그에 쓰면 안 된다.

Cursor가 정리해 준 문장은 매끈할 수 있다.
하지만 매끈한 문장이 안전한 문장은 아니다.

공개 글에서는 이렇게 바꾼다.

특히 조심할 것은 “성과 수치”다.

블로그에서는 이렇게 쓰는 편이 낫다.

런칭 후 특정 결제 수단의 초기 지표가 좋게 나왔고,
그 성과가 실제 전환으로 이어지도록 주문서와 결제단의 마찰을 줄이는 작업을 했다.

반면 내부 보고서에서는 기준일과 수치를 적을 수 있다.

둘을 섞으면 안 된다.

3. “자동화”를 “방치”로 착각한다

Cursor와 CLI, MCP, browser automation을 묶으면 꽤 많은 일을 자동화할 수 있다.

하지만 자동화는 방치가 아니다.

나쁜 자동화:

매일 아침 repo 전체를 보고 문제 있으면 알아서 고쳐서 PR 올려줘.

좋은 자동화:

매일 아침 main 기준으로 최근 실패한 CI를 확인해줘.
실패 원인이 테스트 환경이나 flaky test로 보이면 요약 댓글만 작성해.
명확한 오타/타입 오류처럼 안전한 수정만 별도 브랜치로 제안해.
비즈니스 로직 변경이 필요하면 PR을 만들지 말고 나에게 보고해.

자동화에는 세 가지가 있어야 한다.

1. 언제 실행할지
2. 어디까지 해도 되는지
3. 언제 멈춰야 하는지

이 셋이 없으면 자동화는 사고가 된다.

4. 인덱스와 맥락이 틀렸을 때

Cursor가 틀릴 때는 보통 “멍청해서”가 아니라,
보고 있는 맥락이 틀렸거나 너무 넓거나 오래됐을 때다.

큰 모노레포에서는 이런 일이 흔하다.

• 비슷한 이름의 앱이 여러 개 있다.
• 레거시 코드와 신규 코드가 공존한다.
• 동일한 도메인이 사용자 앱과 운영자 앱에 모두 있다.
• archive나 generated file이 검색 결과에 섞인다.
• 최근 브랜치에서 만든 파일이 인덱스에 늦게 잡힌다.

이럴 때 “아니야, 다시 해”라고 하면 별로 좋아지지 않는다.
맥락을 좁혀야 한다.

내가 쓰는 복구 프롬프트는 이렇다.

방금 답변에서 본 파일 후보가 틀린 것 같아.
다시 찾되 아래 조건을 지켜줘.

- archive/generated/test fixture는 제외
- 실제 런타임 import 경로가 있는 파일만 우선
- 현재 앱의 라우트에서 도달 가능한 코드만 후보로
- 후보마다 왜 관련 있다고 판단했는지 근거를 적어줘

또는:

의미 검색 결과를 믿지 말고, rg 검색과 import 추적을 같이 써서 다시 확인해줘.
최종 후보는 3개 이하로 줄여줘.

인덱스가 엉켰다고 느껴질 때는 사람도 같이 도와야 한다.

• 관련 파일을 직접 열어 둔다.
• @파일명 또는 경로를 명시한다.
• “이 앱이 아니라 저 앱”이라고 말해 준다.
• “이건 레거시 참고용이고 수정 대상은 아니다”라고 못 박는다.

Cursor는 넓은 지도에서 출발할 수 있지만,
마지막 목적지는 사람이 좁혀 줘야 한다.

5. 거대한 변경이 산으로 갈 때

Agent가 너무 많은 파일을 만지기 시작하면 멈추는 것이 좋다.

증상은 대략 이렇다.

• 원래 요청보다 훨씬 많은 파일이 바뀐다.
• 이름만 비슷한 다른 도메인까지 수정한다.
• 테스트를 맞추려고 구현을 더 크게 바꾼다.
• 새 helper, 새 abstraction, 새 type을 계속 만든다.
• 설명은 그럴듯한데 diff가 불안하다.

그럴 때는 이어서 고치게 하지 말고 이렇게 말한다.

여기서 멈춰줘.
지금까지 변경한 파일을 목적별로 분류하고,
원래 요청에 꼭 필요한 변경과 불필요하게 커진 변경을 나눠줘.
아직 추가 수정하지 마.

그리고 필요하면 되돌린다.

원래 요청에 필요한 최소 변경만 남기는 계획을 다시 세워줘.
새 추상화는 만들지 말고 기존 패턴을 재사용하는 방향으로 줄여줘.

Cursor의 Checkpoint나 Git 커밋은 이럴 때 중요하다.

나는 큰 작업을 할 때 이렇게 끊는 편이다.

1. 조사 완료
2. 계획 승인
3. 1차 최소 diff
4. 테스트/브라우저 확인
5. 문서/PR 문장

각 단계 사이에 사람이 diff를 읽는다.
이게 느려 보이지만, 산으로 간 800줄 diff를 되돌리는 것보다 훨씬 빠르다.

6. MCP와 브라우저가 서로 다른 말을 할 때

사내 도구를 연결하면 이런 일이 생긴다.

• 브라우저에서는 페이지가 보이는데 MCP API는 권한 오류가 난다.
• MCP에서는 데이터가 보이는데 브라우저 자동화는 로그인에서 막힌다.
• CLI는 토큰이 만료됐고, 로컬 git에는 예전 기록만 있다.

이건 Cursor 문제가 아니라 기업 도구의 현실이다.

이럴 때는 “어느 것이 진실인가”보다 “각 경로가 무엇을 증명하는가”를 나눠야 한다.

지금 접근 경로를 브라우저, MCP, CLI, 로컬 파일로 나눠서 정리해줘.
각 경로에서 확인 가능한 것과 확인 불가능한 것을 표로 만들어줘.

결과 문서에는 이렇게 남긴다.

원격 API 접근은 조직 권한 문제로 제한되어, 로컬 동기화 시점 기준으로 집계했다.

또는:

브라우저에서는 로그인 정책 때문에 확인하지 못했고, 공식 API 응답 기준으로 정리했다.

실패를 숨기지 않으면 문서의 신뢰도가 올라간다.

회사 코드 익명화 예시

아래는 실제 코드를 그대로 옮긴 것이 아니다.
회사 도메인에서 자주 만나는 문제를 익명화한 예시다.

예시 1: 결제 혜택 로직 맞추기

상황:

일반 주문서로 들어오면 혜택 계산이 정상 동작한다.
장바구니 상품행의 바로구매로 들어오면 일부 혜택이 누락된다.

Cursor에게 시킬 일:

일반 주문서 진입 경로와 바로구매 진입 경로를 비교해줘.
혜택 계산/쿠폰 발급/주문서 초기화가 어디서 갈라지는지 찾아줘.
기존 로직을 재사용하는 수정안을 우선 제안해줘.

좋은 결과:

• 두 흐름의 차이를 먼저 찾는다.
• 새 로직을 만들기보다 기존 주문서 패턴을 재사용한다.
• 결제 직전 고객 마찰을 줄인다.
• PR 설명은 “두 진입 경로의 혜택 처리 일관화”가 된다.

나쁜 결과:

• 바로구매 쪽에만 임시 if를 추가한다.
• 기존 주문서 로직과 다른 정책을 하나 더 만든다.
• 다음 캠페인에서 다시 깨진다.

예시 2: 파트너 어드민 계정 정책 정리

상황:

새 파트너 운영 플랫폼으로 계정을 통합하는 중이다.
하지만 구 운영 콘솔도 남아 있고, 사내 운영 계정의 접근 정책도 함께 정리해야 한다.

Cursor에게 시킬 일:

새 파트너 운영 콘솔과 구 운영 콘솔에서 계정/인증/세션 정책이 어떻게 다른지 비교해줘.
사내 운영 계정의 접근 정책과 충돌할 수 있는 지점을 찾아줘.
기술 변경 목록보다 운영 정책 관점의 차이를 먼저 정리해줘.

좋은 결과:

• 기술 변경이 아니라 운영 정책의 차이가 보인다.
• PM/PD/BE/운영 담당자와 논의할 질문 목록이 생긴다.
• “누가 어떤 계정으로 어디까지 접근 가능한가”가 명확해진다.

나쁜 결과:

• 토큰 갱신 코드만 고친다.
• 계정 정책의 주체와 예외 케이스가 남는다.
• 나중에 운영자가 다시 물어본다.

예시 3: 반기 성과 정리

상황:

내가 한 일은 커밋과 PR에 흩어져 있다.
회사의 목표 작성 가이드는 Objective/KR/SBI 형식을 요구한다.
전략과제 문서는 별도로 있다.

Cursor에게 시킬 일:

최근 6개월 동안 기본 브랜치에 들어간 내 작업을 월별로 정리해줘.
그 다음 전략과제 문서의 축에 맞춰 내 일을 2~3개 목표로 재분류해줘.
단, 코드 작업 나열이 아니라 제품/운영 가치 중심으로 써줘.

중간에 사람이 해야 할 말:

이 목표는 너무 특정 결제·혜택 프로그램에 좁다. 연말까지 이어질 수 있게 고객 전환 경험 전반으로 넓혀줘.

정량 KPI는 근거가 약하니 정성 중심으로 쓰자.
내가 통제 가능한 반영 범위와 협업 과정만 남겨줘.

파트너 플랫폼 쪽은 부수적인 화면 개선보다 플랫폼 통합과 계정 정책 정리가 핵심이다.
그 우선순위를 반영해줘.

좋은 결과:

• 커밋 목록이 목표 문장으로 바뀐다.
• 기술 작업이 제품/운영 가치로 번역된다.
• 본인이 강조하고 싶은 핵심이 살아난다.

검증과 TC 작성: AI가 제일 빛나는 곳 중 하나

Cursor를 쓰며 점점 더 크게 느낀 영역은 테스트다.

AI에게 “테스트 만들어줘”라고 하면 대충 만든다.
하지만 “어떤 위험을 검증할지”를 먼저 묻고 나면 꽤 강력해진다.

내가 좋아하는 순서는 이렇다.

1. 변경 의도를 설명하게 한다.
2. 깨질 수 있는 사용자 시나리오를 뽑게 한다.
3. 기존 테스트 패턴을 읽게 한다.
4. TC 목록을 먼저 만들게 한다.
5. 테스트 코드를 작성하게 한다.
6. 테스트가 구현 상세에 묶였는지 다시 리뷰하게 한다.

예를 들어 주문서의 혜택 적용 로직을 바꿨다면 바로 테스트 파일을 만들게 하지 않는다.

먼저:

이번 변경으로 깨질 수 있는 사용자 시나리오를 정리해줘.
정상 케이스, 예외 케이스, 회귀 케이스로 나눠줘.
아직 테스트 코드는 작성하지 마.

출력은 이런 식이면 좋다.

그 다음:

이 프로젝트의 테스트 도구와 기존 테스트 스타일을 확인해줘.
비슷한 주문서/혜택 테스트가 있으면 위치와 패턴을 요약해줘.

그리고:

위 TC 중 회귀 위험이 가장 큰 3개만 테스트 코드로 작성해줘.
mock은 기존 테스트 패턴을 따르고, 내부 구현 함수 호출보다 사용자에게 보이는 결과 중심으로 검증해줘.

이 접근의 좋은 점은 테스트가 “코드의 복사본”이 되지 않는다는 것이다.

테스트는 구현을 확인하는 문서가 아니다.
사용자에게 약속한 동작을 고정하는 핀에 가깝다.

Cursor는 핀을 많이 꽂게 도와준다.
사람은 어디에 꽂을지 정해야 한다.

TC를 잘 뽑는 프롬프트

이 변경의 위험을 사용자 시나리오 기준으로 나눠줘.
단순 line coverage가 아니라, 실제 장애/문의로 이어질 수 있는 케이스를 우선해줘.

이 기능의 기존 동작 중 절대 깨지면 안 되는 회귀 케이스를 찾아줘.
관련 코드와 테스트 후보를 함께 알려줘.

테스트 코드 작성 전에 TC 목록만 먼저 만들어줘.
각 TC마다 왜 필요한지 한 줄로 설명해줘.

작성한 테스트가 구현 상세에 의존하는지 리뷰해줘.
가능하면 role/text/user-event 중심으로 바꿔줘.

테스트가 없는 코드베이스에서 시작하는 법

현실에는 테스트가 거의 없는 코드도 많다.

그럴 때 Cursor에게 “테스트 다 만들어줘”라고 하면 망한다.
대신 가장 얇은 골든 패스를 잡는다.

이 기능에서 가장 중요한 사용자 골든 패스 하나만 골라줘.
테스트 환경을 크게 바꾸지 않고 추가 가능한 최소 테스트를 제안해줘.

또는:

테스트 추가가 어렵다면, 수동 QA 체크리스트를 먼저 작성해줘.
브라우저에서 확인할 단계, 기대 결과, 실패 시 볼 로그를 포함해줘.

이것도 검증이다.

모든 검증이 자동 테스트일 필요는 없다.
중요한 건 검증을 말로 남기는 것이다.

브라우저 검증과 TC의 연결

Cursor의 browser 기능이 있으면 TC와 실제 화면을 연결할 수 있다.

방금 작성한 QA 체크리스트를 기준으로 로컬 페이지에서 확인해줘.
실제 결제/데이터 생성은 하지 말고, 화면 상태와 콘솔 에러만 확인해줘.

브라우저 검증 결과를 다시 테스트로 바꿀 수도 있다.

브라우저에서 확인한 동작 중 자동화 가능한 항목을 테스트 코드 후보로 바꿔줘.
지금은 코드 작성하지 말고 TC만 정리해줘.

이 루프가 좋다.

TC → 브라우저 확인 → 테스트 후보 → 자동 테스트.

AI가 잘하는 건 이 사이의 번역이다.

티켓, 저장소, 채팅을 한 줄로 잇기

이건 내가 요즘 가장 많이 쓰는 루프다.

1. 티켓은 약속이다.
2. 브랜치는 증거다.
3. 채팅은 맥락이다.

문제는 셋이 서로 자동으로 연결되지 않는다는 것이다.

티켓에는 처음 약속한 범위가 있다.
PR에는 실제 바뀐 코드가 있다.
채팅에는 중간에 바뀐 합의가 있다.

Cursor는 이 셋을 한 줄로 번역하는 데 좋다.

이 티켓 설명, 관련 PR diff, 최근 채팅에서 바뀐 범위를 합쳐서
PR 본문 첫 문단을 써줘.
단, 내부 채팅 문장은 그대로 인용하지 말고 일반화해줘.

혹은:

이 PR이 원래 티켓 범위에서 달라진 점을 정리해줘.
리뷰어가 알아야 할 의사결정만 남기고, 잡담은 빼줘.

이 루프를 만들면 나중에 성과 정리도 쉬워진다.

성과 정리는 갑자기 하는 일이 아니다.
잘 남긴 PR 설명과 티켓 메모를 다시 읽는 일에 가깝다.

MCP: 외부 도구를 연결하는 방식

MCP는 Model Context Protocol의 약자다.

간단히 말하면 Cursor가 외부 도구를 읽고 쓸 수 있게 해 주는 연결 규격이다.

실무에서 연결하고 싶은 것들은 많다.

• GitHub
• Jira
• Confluence
• Slack
• Figma
• 브라우저
• 내부 API
• 로그/모니터링 도구

MCP가 있으면 Cursor가 이런 일을 할 수 있다.

이 Confluence 페이지를 읽고 요구사항만 요약해줘.

이 Jira 티켓의 AC와 관련 PR 목록을 보고 누락된 검증 항목을 찾아줘.

Figma 디자인에서 실제로 필요한 컴포넌트 계층을 뽑고,
우리 코드베이스의 기존 컴포넌트와 매핑해줘.

하지만 MCP에는 항상 권한 문제가 붙는다.

MCP가 켜져 있어도:

• OAuth가 만료될 수 있다.
• 조직 SSO가 막을 수 있다.
• API scope가 부족할 수 있다.
• 브라우저에서는 보이는데 API로는 안 보일 수 있다.
• API로는 되는데 브라우저 자동화는 로그인에서 막힐 수 있다.

그래서 MCP 작업을 시작할 때는 먼저 도구 스키마와 인증 상태를 확인하는 습관이 좋다.

먼저 사용할 MCP 도구의 스키마를 확인해줘.
그 다음 내 계정이 접근 가능한 리소스를 확인하고,
권한이 부족하면 어떤 권한이 필요한지 구분해줘.

MCP는 마법이 아니다.
잘 연결된 사내 출입증에 가깝다.
출입증이 있어도 들어갈 수 없는 회의실은 있다.

Web과 Browser를 같이 쓰기

Cursor의 웹/브라우저 활용은 두 종류로 나뉜다.

1. 웹 검색/문서 조회
2. 실제 브라우저 조작

문서 조회는 이런 데 좋다.

• 공개 문서 확인
• 라이브러리 버전별 API 확인
• GitHub 공개 페이지 확인

브라우저 조작은 이런 데 좋다.

• 로컬 개발 서버 UI 확인
• 클릭/입력/스크롤로 실제 동작 재현
• 콘솔 에러 확인
• 네트워크 요청 확인
• 스크린샷 기반 시각 검증

다만 브라우저 자동화도 조심해야 한다.

좋은 요청:

로컬 QA 페이지를 열고 주문서 화면까지 이동해줘.
버튼 클릭 후 콘솔 에러와 네트워크 실패만 확인해줘.
결제나 실제 주문 완료 액션은 하지 마.

나쁜 요청:

사이트 들어가서 주문 잘 되는지 확인해줘.

브라우저는 실제 서비스를 건드릴 수 있다.
그래서 금지 조건이 필요하다.

• 실제 결제 금지
• 실제 데이터 생성 금지
• 운영 계정 사용 금지
• 삭제/발송/승인 버튼 클릭 금지
• 캡차/2FA/권한 요청에서 멈추기

브라우저 자동화는 테스트 계정과 안전한 환경에서만 쓰는 것이 좋다.

CLI와 자동화

Cursor를 IDE에서만 쓰면 절반이다.

CLI를 쓰면 반복 작업을 스크립트처럼 만들 수 있다.

예를 들면:

agent -p "최근 실패한 테스트 로그를 읽고 원인을 요약해줘. 파일 수정은 하지 마."

혹은:

agent -p --force "문서의 할 일 목록을 최신 코드 기준으로 갱신하고 diff를 요약해줘."

실제 자동화로 갈수록 프롬프트는 더 엄격해야 한다.

예:

매주 월요일 오전에 실행한다.
최근 7일간 기본 브랜치에 들어간 PR 제목을 수집한다.
도메인별로 묶어 changelog 초안을 만든다.
파일은 docs/changelog-drafts 아래에만 생성한다.
코드 파일은 절대 수정하지 않는다.
내부 URL과 실명은 공개 문서용으로 익명화한다.

이 정도로 적어야 한다.

자동화에서 특히 중요한 것은 “수정 가능한 경계”다.

허용:
- docs/changelog-drafts/*.md 생성
- markdown 문장 수정

금지:
- src/** 수정
- package.json 수정
- lockfile 수정
- git commit/push
- 외부 API에 write 요청

AI 자동화는 권한이 커질수록 프롬프트도 구체적이어야 한다.

예전 자동화와 Cursor식 자동화의 차이

나는 예전에도 자동화를 좋아했다.

예를 들어 이런 식의 자동화다.

• YAML에 API 명세를 적는다.
• 스크립트가 그 명세를 읽는다.
• 타입, API client, mock handler, 문서 일부를 생성한다.
• 정해진 디렉터리에 파일을 떨군다.

이 방식은 좋다.

특히 반복되는 구조가 안정적일 때 강하다.

endpoint: /orders/{orderId}/benefits
method: GET
response:
  type: OrderBenefitResponse
generate:
  - api-client
  - msw-handler
  - docs

이런 자동화는 예측 가능하다.
리뷰하기도 쉽다.
팀 규칙으로 만들기도 좋다.

하지만 한계도 있다.

현실의 요구사항은 종종 YAML로 잘 떨어지지 않는다.

• 기존 API가 조금 이상하다.
• 화면마다 비슷하지만 다른 예외가 있다.
• 어떤 필드는 곧 사라질 예정이다.
• 레거시 경로는 타입이 느슨하다.
• 백엔드 문서와 실제 응답이 살짝 다르다.
• PM이 말한 정책이 아직 명세에 반영되지 않았다.

예전 자동화는 “정해진 입력 → 정해진 출력”에 강하다.
Cursor식 자동화는 그 사이의 애매함을 다루는 데 강하다.

나는 이 차이를 이렇게 본다.

중요한 건 둘 중 하나를 버리는 게 아니다.

좋은 전략은 섞는 것이다.

예:

OpenAPI 명세로 생성된 API client가 있어.
이번 요구사항은 기존 생성 코드만으로는 부족하고,
주문서의 레거시 어댑터에서 응답을 한 번 변환해야 해.

1. 생성 코드와 수동 어댑터의 경계를 찾아줘.
2. 생성 파일은 수정하지 말고, 어댑터에서 처리할 수 있는지 검토해줘.
3. 다음 명세 갱신 때 사라져야 할 임시 로직이면 남겨 둘 표시와 문서 위치를 제안해줘.

이런 일은 전통적인 generator만으로는 어렵다.
하지만 Cursor에게 전부 맡겨도 위험하다.

가장 좋은 형태는 이렇다.

• 반복 구조는 generator가 만든다.
• 예외 해석은 Cursor와 사람이 같이 한다.
• 팀 규칙은 문서/Rules에 남긴다.
• 다음 반복에서 다시 generator로 흡수할 수 있는지 본다.

즉 Cursor는 자동화의 적이 아니다.

오히려 딱딱한 자동화와 현실의 애매함 사이를 메우는 층이다.

개인화의 영역

Cursor가 재미있는 이유 중 하나는 개인화다.

여기서 말하는 개인화는 “말투를 내 취향으로” 정도가 아니다.

내가 자주 하는 일의 순서를 도구가 배우게 하는 것이다.

나는 예를 들면 이런 습관이 있다.

• 먼저 파일을 읽는다.
• 기존 패턴을 찾는다.
• 코드를 고치기 전에 PR 첫 문장을 생각한다.
• 내부 자료를 공개 글로 바꿀 때는 익명화한다.
• 숫자를 쓰면 출처와 한계를 적는다.
• 큰 변경은 테스트/수동 QA/브라우저 확인 중 하나를 붙인다.

이런 습관은 User Rules나 프로젝트 Rules, AGENTS.md, 프롬프트 템플릿으로 남길 수 있다.

예:

내가 블로그 초안을 요청하면:
1. 내부 회사명, 레포명, 티켓 키, 실명, 내부 URL을 공개 가능한 표현으로 일반화한다.
2. 기술 작업 나열보다 작업 방식과 판단 기준을 중심으로 쓴다.
3. 마지막에 공개 전 점검 체크리스트를 붙인다.

또는:

내가 성과 정리를 요청하면:
1. 커밋 목록을 먼저 월별로 정리한다.
2. 그 다음 Objective/KR/SBI 구조로 바꾼다.
3. 과한 정량 KPI는 피하고, 통제 가능한 실행 근거와 협업 과정을 강조한다.

이게 쌓이면 Cursor는 단순한 도구가 아니라 내 작업 리듬을 담은 인터페이스가 된다.

물론 조심해야 한다.

개인화가 강해질수록 편향도 강해진다.

• 내가 좋아하는 추상화를 계속 만들 수 있다.
• 내가 자주 쓰는 표현이 과하게 반복될 수 있다.
• 팀 규칙보다 내 습관이 앞설 수 있다.
• 보안/공개 경계가 느슨해질 수 있다.

그래서 개인화에는 두 종류가 있어야 한다.

1. 나를 빠르게 하는 규칙
2. 나를 멈추게 하는 규칙

예를 들어:

내가 "블로그로 정리해줘"라고 해도 내부 URL, 실명, 고객 정보, 티켓 원문은 절대 포함하지 말고 먼저 경고해줘.

내가 "바로 고쳐줘"라고 해도 결제/권한/인증/삭제 흐름은 먼저 계획을 제안하고 승인 후 수정해줘.

이런 규칙이 진짜 개인화다.

내 취향대로 더 빨리 가는 것뿐 아니라,
내가 자주 실수할 수 있는 지점에서 멈춰 주는 것.

Rules와 AGENTS.md

Cursor를 팀에서 오래 쓰려면 개인 프롬프트만으로 부족하다.

반복되는 규칙은 저장소에 남겨야 한다.

예:

# AGENTS.md

- 새 코드에서는 legacy router helper를 쓰지 않는다.
- 브라우저 storage는 직접 접근하지 않고 표준 storage package를 사용한다.
- Tailwind spacing은 1px:1unit 스케일이다.
- PR 설명 첫 문단에는 사용자 영향과 검증 방법을 적는다.

혹은 .cursor/rules에 더 세밀한 규칙을 둘 수 있다.

좋은 rule:

When editing order checkout code, first inspect the shared order form hooks and reuse existing validation helpers before adding a new branch-specific implementation.

나쁜 rule:

Always write clean code.

“깨끗한 코드”는 너무 넓다.

좋은 규칙은:

• 특정 상황이 있고
• 피해야 할 실수가 있고
• 따라야 할 파일이나 패턴이 있다.

규칙은 많을수록 좋은 것이 아니다.
AI도 긴 규칙을 다 잘 기억하지 못한다.

짧고, 자주 틀리는 것만 적는다.

Hooks: 안전장치와 습관 만들기

Hooks는 Agent의 특정 이벤트 전후에 스크립트를 실행하는 장치다.

예를 들면:

• 파일 수정 후 formatter 실행
• shell command 실행 전 위험 명령 차단
• MCP 호출 전 민감 도구 확인
• .env나 credential 파일 읽기 방지
• 세션 시작 시 프로젝트 규칙 안내

Hooks는 자동화의 안전벨트다.

예:

{
  "hooks": {
    "beforeShellExecution": [
      {
        "pattern": "rm -rf|git reset --hard|git push --force",
        "action": "block",
        "message": "위험 명령입니다. 사용자 승인이 필요합니다."
      }
    ]
  }
}

실제 설정 문법은 사용하는 Cursor 버전의 문서를 확인해야 한다.
하지만 방향은 이렇다.

AI가 빨라질수록, 금지선을 코드로 적어 두는 것이 중요하다.

팀에서 Cursor를 도입할 때 정해야 할 것

개인이 Cursor를 잘 쓰는 것과 팀이 Cursor를 안전하게 쓰는 것은 다른 문제다.

개인은 속도를 본다.
팀은 속도와 함께 다음을 봐야 한다.

• 어떤 코드와 문서를 AI 컨텍스트로 줄 수 있는가
• 어떤 명령을 자동으로 실행해도 되는가
• 어떤 외부 도구(MCP)를 연결할 수 있는가
• 생성된 코드를 누가 어떻게 검증하는가
• 보안/개인정보/고객정보가 섞인 파일을 어떻게 막는가
• AI가 만든 PR을 리뷰할 때 기준은 무엇인가

이걸 정하지 않으면 팀은 두 갈래로 갈라진다.

한쪽은 무서워서 거의 못 쓰고,
다른 한쪽은 너무 많이 맡긴다.

둘 다 좋지 않다.

1. 컨텍스트로 줄 수 있는 것과 없는 것

팀 차원의 첫 규칙은 “무엇을 읽혀도 되는가”다.

예:

이 표는 법무 문서가 아니다.
팀의 작업 기준이다.

중요한 건 “대충 조심”이 아니라, 실제로 막는 것이다.

• .cursorignore나 ignore 설정으로 민감 파일 제외
• Hooks로 .env, key, credential 접근 차단
• MCP token scope 최소화
• 운영 계정과 테스트 계정 분리
• 외부 공개 글 생성 시 고유명사 검사

AI 도구를 안전하게 쓰려면 윤리 선언보다 파일 경계가 먼저다.

2. 자동 실행해도 되는 명령

Agent가 터미널을 실행할 수 있다면 팀은 명령 정책을 정해야 한다.

허용하기 쉬운 명령:

pnpm lint
pnpm type-check
pnpm test -- --runInBand
git diff
git status

주의가 필요한 명령:

pnpm install
database migration
codegen that rewrites many files
docker compose down

기본 차단해야 할 명령:

rm -rf
git reset --hard
git push --force
production deploy
real payment/test purchase with real account

이걸 문서로만 쓰지 말고 Hook이나 권한 설정에 넣는 편이 좋다.

프롬프트에도 남긴다.

명령 실행 전 위험도를 판단해줘.
파일 삭제, force push, 운영 배포, 실제 결제/발송/승인과 연결되는 명령은 실행하지 말고 멈춰서 물어봐.

3. AI PR 리뷰 기준

AI가 만든 PR은 사람이 만든 PR과 같은 기준으로 리뷰해야 한다.
다만 몇 가지를 더 본다.

• 기존 패턴을 따랐는가
• 새 추상화를 과하게 만들지 않았는가
• 테스트가 사용자 동작을 검증하는가
• 실패한 검증을 숨기지 않았는가
• 사용하지 않는 파일이나 generated diff가 섞이지 않았는가
• 내부 정보가 문서/로그/코멘트에 남지 않았는가
• “AI가 그렇게 했다”가 설명이 되지 않는가

리뷰어는 이렇게 물을 수 있다.

이 변경에서 AI가 새로 만든 추상화와 기존 패턴을 재사용한 부분을 구분해줘.
새 추상화가 꼭 필요한 이유를 한 문단으로 설명해줘.

또는:

이 PR의 검증 결과를 성공/실패/미실행으로 나눠줘.
미실행 항목은 왜 못 했는지 적어줘.

AI 시대의 리뷰는 “코드를 읽는 일”에서 “근거를 확인하는 일”로 조금 이동한다.

4. 팀 Rules의 최소 세트

처음부터 거대한 규칙 파일을 만들 필요는 없다.

나는 팀 도입 초기에는 이 정도면 충분하다고 본다.

# AI 작업 규칙

1. 큰 변경은 먼저 계획을 작성하고 사람 승인 후 수정한다.
2. 기존 패턴을 먼저 찾고, 새 추상화는 필요할 때만 만든다.
3. 결제/권한/삭제/발송/승인 흐름은 자동 실행하지 않는다.
4. 민감 파일(.env, credential, customer data)은 읽거나 수정하지 않는다.
5. PR 설명에는 사용자 영향, 주요 변경, 검증 결과, 남은 리스크를 적는다.
6. 테스트를 실행하지 못했으면 못 한 이유를 적는다.

이 정도만 있어도 팀의 사고 확률이 많이 줄어든다.

5. 팀에 맞는 개인화를 허용하기

팀 규칙은 공통 안전선이다.
하지만 개인마다 잘 쓰는 방식은 다르다.

어떤 사람은 브라우저 검증을 자주 쓰고,
어떤 사람은 CLI batch를 좋아하고,
어떤 사람은 문서 초안을 많이 쓴다.

팀은 모든 사용법을 하나로 통일하려고 하기보다,
공통 금지선만 강하게 잡고 나머지는 개인화할 수 있게 두는 편이 좋다.

좋은 팀 규칙:

• 고객정보 금지
• 위험 명령 차단
• 큰 변경은 계획 먼저
• 검증 결과 명시

개인이 정할 규칙:

• 글쓰기 말투
• PR 초안 형식
• 선호하는 테스트 작성 순서
• 자주 쓰는 프롬프트 템플릿
• 선호하는 브라우저 검증 루프

AI 도구의 생산성은 개인화에서 나오고,
AI 도구의 안전성은 팀 규칙에서 나온다.

둘 중 하나만 있으면 오래 못 간다.

Claude와 Cursor의 차이

나는 Claude도 좋아한다.

Claude Code는 터미널 중심의 작업에 강하다.
긴 사고 과정, 텍스트 중심의 리팩터링 계획, 파일 시스템 기반 작업, CLI 파이프라인과 잘 맞는다.

Cursor는 IDE 중심의 작업에 강하다.

• 현재 열어 둔 파일
• diff
• linter
• 브라우저
• MCP
• inline edit
• Agent/Plan/Ask
• workspace rules

이런 것들이 한 화면 안에 들어온다.

내 기준으로 나누면 이렇다.

중요한 건 어느 하나가 전부를 대체한다는 생각을 버리는 것이다.

나는 이렇게 쓴다.

• Cursor: 코드베이스 안에서 움직이는 작업
• Claude: 큰 생각 정리, 긴 문장, 터미널 중심 루프
• Web/Browser: 외부 사실 확인과 UI 검증
• CLI: 반복 가능한 자동화

도구 이름보다 더 중요한 것은 작업 단위다.

차이는 모델보다 표면에서 온다

많은 사람이 “Claude가 좋냐, Cursor가 좋냐”를 모델 성능으로만 비교한다.

하지만 실무에서 체감 차이는 모델보다 작업 표면에서 더 크게 온다.

Claude Code를 터미널에서 쓰면 자연스럽게 이런 흐름이 된다.

명령을 실행한다.
결과를 읽는다.
다음 명령을 구성한다.
파일을 수정한다.
다시 명령을 실행한다.

유닉스 파이프라인의 감각에 가깝다.

반면 Cursor는 이런 흐름이 자연스럽다.

열려 있는 파일을 본다.
관련 파일을 찾는다.
diff를 확인한다.
linter와 테스트를 본다.
브라우저에서 UI를 확인한다.
PR 문장을 다듬는다.

IDE의 감각에 가깝다.

둘은 경쟁한다기보다 몸의 자세가 다르다.

Claude Code는 의자에서 조금 뒤로 물러나 터미널과 대화하는 느낌이고,
Cursor는 코드 바로 옆에서 짝 프로그래밍하는 느낌에 가깝다.

Claude가 더 편했던 순간

Claude 쪽이 더 편한 순간도 많다.

• 긴 글의 논리 구조를 잡을 때
• 코드와 직접 관련 없는 사고 실험을 할 때
• 터미널 중심으로 여러 repo를 훑을 때
• 이미 CLI 습관이 강한 작업을 이어갈 때
• “일단 긴 설명을 듣고 싶다”는 상태일 때

예를 들어 아키텍처 의사결정 문서를 쓰거나,
어떤 조직의 개발 문화 변화에 대해 긴 글을 구상할 때는 Claude식 대화가 더 편할 때가 있다.

Claude는 문장을 오래 붙잡고 가는 데 강하다.
그리고 터미널 기반 작업에서는 IDE 표면이 오히려 거추장스러울 때도 있다.

Cursor가 더 편했던 순간

Cursor는 코드와 화면이 붙어 있을수록 강하다.

• 열어 둔 파일의 맥락을 바로 이어갈 때
• diff를 보며 고칠 때
• linter 경고를 보며 수정할 때
• 브라우저에서 화면을 확인할 때
• Figma/Confluence/GitHub/Jira 같은 MCP 도구를 한 작업 안에서 오갈 때
• PR 리뷰 직전 문장을 다듬을 때

특히 프론트엔드 작업은 Cursor 쪽이 좋았다.

프론트엔드는 코드만으로 끝나지 않는다.

• 화면이 어떻게 보이는지
• 버튼이 눌리는지
• 콘솔 에러가 있는지
• 네트워크 요청이 맞는지
• 접근성 이름이 잡히는지
• 디자인과 간격이 맞는지

이런 것들이 IDE와 브라우저 사이를 오간다.

Cursor는 이 왕복 비용을 줄인다.

병행 전략

나는 둘을 이렇게 나눠 쓰는 쪽이 좋다고 본다.

중요한 건 같은 일을 두 도구에 동시에 맡기지 않는 것이다.

도구가 둘이면 책임 경계가 흐려질 수 있다.

나는 보통 이렇게 한다.

Claude에게 큰 구조를 묻는다.
Cursor에게 실제 파일을 고치게 한다.
Cursor가 만든 diff를 다시 Claude식 시야로 검토한다.
마지막 판단은 내가 한다.

혹은 반대로:

Cursor로 코드베이스 근거를 모은다.
Claude에게 글의 구조와 문장 리듬을 다듬게 한다.
다시 Cursor에서 파일로 저장하고 링크/코드블록을 확인한다.

둘 다 맞다.

다만 모든 단계에서 물어야 한다.

지금 내가 원하는 것은 코드 근처의 행동인가, 생각의 구조화인가?

그 답이 도구를 고른다.

Claude와 Cursor 모두에게 공통으로 필요한 것

둘 다 잘 쓰려면 결국 같은 기본기가 필요하다.

• 요구사항을 작게 나누기
• 모르는 것을 모른다고 표시하기
• 근거 파일을 먼저 읽기
• 변경하지 말아야 할 범위 정하기
• 테스트와 검증을 요구하기
• 내부 자료 공개 경계 지키기
• 생성된 결과를 리뷰하기

도구가 바뀌어도 이 기본기는 바뀌지 않는다.

오히려 AI 도구를 잘 쓸수록 기본기가 더 드러난다.

프롬프트는 개발자의 사고방식을 숨기지 못한다.

상황별 레시피: “이런 것도 되나?”

실무자는 보통 기능 목록을 읽고 싶어 하지 않는다.
지금 막힌 일이 Cursor로 풀리는지가 궁금하다.

그래서 상황별로 적어 본다.

관련 파일을 못 찾겠다

이 기능이 어디에 구현되어 있는지 찾아줘.
검색 키워드를 추측해서 넓게 찾고, 가능성 높은 파일 5개와 이유를 정리해줘.
아직 수정하지 마.

좋은 후속 질문:

가장 가능성 높은 2개 파일만 더 자세히 읽고, 호출 흐름을 설명해줘.

비슷한 기능이 이미 있는지 모르겠다

이 요구사항과 비슷한 기존 구현을 찾아줘.
재사용 가능한 함수/컴포넌트/훅이 있는지 보고,
새로 만드는 경우와 재사용하는 경우의 장단점을 비교해줘.

레거시 코드가 무섭다

이 파일을 수정하기 전에 책임을 나눠서 설명해줘.
외부에서 호출되는 public surface, 내부 helper, side effect, 위험한 전역 상태를 구분해줘.

레거시에서는 고치기보다 먼저 지도를 그린다.

요구사항이 애매하다

이 요구사항에서 구현 전에 확인해야 할 질문을 PM/PD/BE/QA 관점으로 나눠줘.
이미 코드에서 답을 찾을 수 있는 질문과 사람에게 물어야 하는 질문을 구분해줘.

이 프롬프트는 회의 전에 좋다.

질문을 잘 만들면 개발 시간이 줄어든다.

PR이 너무 커졌다

이 diff를 기능 단위로 나눠줘.
리뷰어가 보기 좋은 순서와, 분리 가능한 PR 후보를 제안해줘.
단, 실제 git 작업은 하지 마.

후속:

현재 PR 본문을 5문장 이하로 다시 써줘.
사용자 영향, 주요 변경, 검증, 리스크만 남겨줘.

리뷰 코멘트를 받았다

이 리뷰 코멘트들을 유형별로 분류해줘.
버그 지적, 스타일, 설계 이견, 질문, 후속 과제로 나눠줘.
각 항목에 답변 초안을 작성해줘.

리뷰 코멘트는 감정적으로 읽히기 쉽다.
Cursor에게 먼저 분류시키면 덜 피곤하다.

QA에서 버그가 왔다

이 버그 리포트를 재현 단계, 기대 결과, 실제 결과, 의심 코드 경로로 정리해줘.
관련 파일 후보를 찾아주고, 재현 전에 확인할 로그/네트워크 요청도 제안해줘.

브라우저까지 쓴다면:

로컬 QA 환경에서 재현을 시도해줘.
데이터 생성/결제/삭제 액션은 하지 말고,
화면 상태, console error, network failure만 확인해줘.

성과 보고를 써야 한다

최근 N개월 내 내 커밋/PR을 월별로 정리해줘.
그 다음 제품 가치 기준으로 2~3개 목표로 묶어줘.
기술 작업 나열이 아니라 고객/운영/협업 임팩트 중심으로 써줘.

후속:

이 문장을 평가 시스템의 Objective/KR/SBI 형식으로 바꿔줘.
과한 정량 KPI는 피하고, 통제 가능한 실행 근거와 협업 과정을 강조해줘.

내부 문서를 공개 글로 바꾸고 싶다

이 문서를 공개 블로그 초안으로 바꿔줘.
회사명, 서비스명, 실명, 내부 URL, 티켓 키, 정확한 수치는 제거하거나 일반화해줘.
과정과 배운 점 중심으로 재구성해줘.

그리고 꼭 다시 묻는다.

공개하면 위험한 표현이 남아 있는지 점검해줘.
내부 정보, 수치, 고유명사, 고객 정보, 조직 구조 힌트를 기준으로 봐줘.

자동화로 돌리고 싶다

이 작업을 매주 자동화한다고 가정하고,
허용할 작업, 금지할 작업, 실패 시 멈출 조건, 사람이 승인해야 할 조건을 표로 정리해줘.

자동화는 실행보다 경계가 먼저다.

새 기술을 도입하고 싶다

이 라이브러리를 도입하기 전에 현재 코드베이스의 기존 대안과 비교해줘.
번들 크기, 유지보수성, 팀 패턴, 마이그레이션 비용, 테스트 가능성을 기준으로 정리해줘.

Cursor에게 “설치해줘”라고 하기 전에 “왜 필요한지”를 먼저 묻는다.

디자인을 코드로 옮겨야 한다

이 디자인을 구현하기 전에 기존 디자인 시스템/컴포넌트와 매칭해줘.
새 컴포넌트를 만들지 않고 조합 가능한 영역과, 새로 필요한 영역을 구분해줘.

Figma MCP가 있다면 더 좋다.

그래도 원칙은 같다.

픽셀을 복사하기 전에 제품의 구성 요소를 찾는다.

배포 전 불안하다

이번 변경의 배포 전 체크리스트를 작성해줘.
자동 테스트, 수동 QA, 브라우저 확인, 롤백/모니터링 포인트로 나눠줘.

후속:

체크리스트 중 지금 이 로컬 환경에서 확인 가능한 것만 실행해줘.
확인 불가능한 것은 이유와 필요한 환경을 적어줘.

이렇게 하면 “다 확인했다”는 착각을 줄일 수 있다.

내가 정한 실무 규칙

1. 큰 일은 바로 구현하지 않는다

먼저 읽힌다.

수정하지 말고 관련 파일과 기존 패턴만 찾아줘.

그 다음 계획을 받는다.

구현안 2개와 리스크를 비교해줘.

그 다음 고친다.

2. PR 첫 문단을 먼저 쓴다

PR 첫 문단을 못 쓰면, 아직 내가 뭘 하는지 모르는 것이다.

Cursor에게 이렇게 시킨다.

이 변경의 PR 첫 문단을 써줘.
사용자/운영자 관점에서 무엇이 같아졌거나 좋아졌는지 중심으로.

코드보다 설명이 먼저일 때가 많다.

3. 내부 자료는 바로 블로그로 가져오지 않는다

내부 성과 정리 문서와 공개 블로그 글은 다르다.

내부 문서:

• 구체 수치
• 기준일
• 레포명
• 티켓 키
• 담당 부서

공개 글:

• 패턴
• 익명화된 도메인
• 도구 사용법
• 실패와 우회
• 내 작업 습관

4. 막히면 실패 원인을 분류한다

Cursor가 실패하면 “다시 해봐”보다 분류가 먼저다.

• 권한 문제인가?
• 네트워크 문제인가?
• 파일 접근 문제인가?
• 테스트가 원래 깨져 있었나?
• 내 변경 때문에 깨졌나?
• 요구사항이 애매했나?

이 분류를 시키면 다음 행동이 나온다.

5. AI가 낸 결론은 출처를 붙인다

특히 숫자는 그렇다.

이 숫자는 로컬 git log 기준인지, GitHub API 기준인지, 내부 Wiki 기준인지 표시해줘.
접근 실패한 저장소가 있으면 한계도 적어줘.

이 습관이 없으면 AI가 만든 문서는 그럴듯하지만 불안하다.

하면 좋은 것

• Cursor에게 먼저 프로젝트 규칙을 읽게 하기
• 큰 작업은 Ask/Plan으로 시작하기
• “수정하지 마”를 자주 쓰기
• 기존 패턴을 먼저 찾게 하기
• 행동 단위로 지시하기
• 실패하면 원인 분류부터 시키기
• 터미널 출력과 브라우저 결과를 함께 보게 하기
• 문서 작성 시 내부/공개 경계를 먼저 선언하기
• 성과 정리는 커밋 목록이 아니라 목표 언어로 다시 쓰기
• PR 첫 문단을 Cursor와 같이 만들기
• 자동화에는 허용/금지/중단 조건을 명시하기

하면 안 되는 것

• “알아서 잘 고쳐줘”라고 하기
• 권한이 필요한 일을 인증 확인 없이 시키기
• 운영 데이터/실계정으로 브라우저 자동화하기
• 내부 URL, 티켓, Slack 캡처를 공개 글에 그대로 넣기
• 테스트 없이 큰 diff를 믿기
• Cursor가 만든 새 추상화를 바로 받아들이기
• 프로젝트 규칙보다 일반 지식을 우선하기
• MCP 연결만 보고 모든 데이터 접근이 가능하다고 믿기
• 자동화가 실패했는데 조용히 넘어가게 만들기
• Git 커밋이나 Cursor checkpoint 없이 큰 변경을 오래 이어가기

내가 생각하는 Cursor의 제일 좋은 사용법

Cursor를 잘 쓴다는 건, 코드를 더 많이 찍어내는 것이 아니다.

내가 느낀 좋은 사용법은 이렇다.

내가 이미 하던 좋은 습관의 비용을 낮추는 것.

• 먼저 읽기
• 기존 패턴 따르기
• 변경 이유 쓰기
• 리뷰어가 볼 문장 만들기
• 테스트 결과 확인하기
• 내부 맥락을 공개 가능한 말로 바꾸기
• 실패 원인을 숨기지 않기

Cursor는 이 습관들을 대신하지 않는다.
대신 유지하기 쉽게 만든다.

그래서 나는 Cursor를 쓰며 “대체”보다 “증폭”이라는 말을 더 자주 떠올린다.

좋은 개발자의 습관은 더 빨리 퍼진다.
나쁜 개발자의 습관도 더 빨리 퍼진다.

도구의 성능보다 먼저, 내 작업 방식이 중요해지는 이유다.

긴 글의 짧은 결론

Cursor는 코드 생성기가 아니다.

혹은, 코드 생성기이기만 해서는 너무 아깝다.

내가 겪은 Cursor는:

• 저장소를 읽는 눈
• 터미널을 대신 두드리는 손
• 브라우저를 확인하는 발
• 티켓과 PR과 채팅을 번역하는 입
• 그리고 사람이 판단할 지점을 빨리 드러내는 거울

에 가까웠다.

완벽한 가이드는 없다.

다만 이 정도는 말할 수 있다.

Cursor를 잘 쓰려면 일을 작게 쪼개야 한다.
작게 쪼갠 일을 다시 제품 가치로 묶어야 한다.
그 사이의 반복 이동을 Cursor에게 맡기면, 사람은 더 자주 판단할 수 있다.

나는 당분간 이 방식으로 일할 것 같다.

한 줄 결: Cursor는 나 대신 일하는 사람이 아니라, 내가 티켓·코드·채팅·문서·브라우저 사이를 덜 헤매게 해 주는 작업 운영체제에 가깝다.