비용, 한계, 그리고 솔로 메이커를 위한 운영 가이드

비용은 카드값이 아니라 운영 문제입니다

Cursor를 처음 켜는 순간에는 비용보다 속도가 먼저 느껴집니다. "이걸 왜 이제 썼지?"라는 생각이 들고, 하루 만에 기능 하나를 끝내면 월 20달러는 거의 공짜처럼 보입니다. 문제는 그다음부터입니다. 에이전트에게 디버깅을 맡기고, 리팩터링을 맡기고, UI 수정과 테스트 작성까지 맡기기 시작하면 Cursor는 더 이상 '에디터 구독료'가 아니라 작은 클라우드 비용처럼 움직입니다.

솔로 메이커에게 Cursor 비용은 단순히 카드값의 문제가 아닙니다. 그것은 제품을 얼마나 안정적으로 운영할 수 있는지, 어느 작업을 AI에게 맡기고 어느 작업은 내가 승인해야 하는지, 코드 품질을 어떤 기준으로 지킬 것인지에 대한 운영 문제입니다.

이 장에서는 Cursor를 오래 쓰기 위한 현실적인 기준을 세웁니다. 더 많이 쓰는 법이 아니라, 계속 쓸 수 있게 쓰는 법입니다.

Cursor 비용은 "좌석값"이 아니라 "작업 방식값"입니다

2026년 5월 현재 Cursor의 주요 개인·팀 요금제는 Hobby, Pro, Pro+, Ultra, Teams로 나뉩니다. 공식 요금 페이지 기준으로 Hobby는 무료, Pro는 월 20달러, Pro+는 월 60달러, Ultra는 월 200달러입니다. Teams는 협업과 조직 관리가 필요한 사용자를 위한 플랜입니다. Pro 이상에서는 Agent 한도 확장, 프런티어 모델 접근, MCP, Skills, Hooks, Cloud Agents 같은 기능을 사용할 수 있고, Pro+와 Ultra는 OpenAI, Claude, Gemini 모델 사용량을 각각 3배, 20배로 늘려 줍니다.¹

다만 요금제와 포함 기능은 언제든 바뀔 수 있습니다. 이 장의 숫자는 판단 기준을 세우기 위한 현재 기준으로 읽고, 실제 결제 전에는 반드시 Cursor 공식 요금 페이지를 다시 확인하세요.

겉으로 보면 선택은 간단해 보입니다. 무료로 써 보고 부족하면 Pro, 더 많이 쓰면 Pro+, 하루 종일 에이전트를 돌리면 Ultra. 하지만 솔로 메이커에게 중요한 질문은 "얼마짜리 플랜이 좋은가?"가 아닙니다.

질문은 이렇게 바뀌어야 합니다.

나는 Cursor에게 어떤 종류의 일을 얼마나 자주 맡길 것인가?

가벼운 자동완성과 짧은 질문 위주라면 Pro도 넉넉할 수 있습니다. 반대로 매일 Agent를 켜서 여러 파일을 고치고, Cloud Agents로 병렬 작업을 돌리고, 큰 컨텍스트 모델에 자주 의존한다면 Pro의 한도는 생각보다 빨리 줄어듭니다. Cursor는 2025년 중반 이후 단순 요청 수 중심에서 모델 사용량 기반의 크레딧 구조로 이동했습니다. 그래서 같은 "한 번의 요청"이라도 어떤 모델을 골랐는지, 얼마나 긴 컨텍스트를 보냈는지, 에이전트가 몇 번이나 반복 작업을 했는지에 따라 비용 감각이 달라집니다.²

솔로 메이커에게 추천하는 출발점은 명확합니다. 일단 Pro로 시작하세요. Hobby는 평가용에 가깝습니다. 하루에 몇 시간씩 제품을 만들기 시작하면 무료 한도는 도구를 익히기도 전에 막힐 수 있습니다. Pro는 Cursor가 실제 작업 도구가 되는 최소선입니다. 여기서 한 달을 보내며 자신의 사용 패턴을 관찰한 뒤, 다음 결정을 내리면 됩니다.

여기서 중요한 것은 자존심을 버리는 것입니다. "나는 솔로니까 Pro면 충분해야 해"라고 생각할 필요가 없습니다. 반대로 "AI 시대니까 Ultra를 써야 앞서간다"라고 생각할 필요도 없습니다. 비용은 실력의 표시가 아니라 작업량의 결과입니다.

플랜 선택보다 먼저 해야 할 일: 월간 Cursor 예산 정하기

Cursor를 운영 도구로 받아들이려면 먼저 상한선을 정해야 합니다. AWS 비용을 무한정 열어 두지 않듯, Cursor도 "이번 달에는 여기까지"라는 선이 있어야 합니다.

예를 들어 아직 매출이 없는 사이드 프로젝트라면 Cursor 예산을 월 20달러로 제한하는 것이 합리적일 수 있습니다. 제품을 실제로 판매하고 있고 매달 개발 시간이 부족하다면 월 60달러도 충분히 투자할 만합니다. Cursor 덕분에 유료 기능 하나를 이틀 빨리 출시할 수 있다면 Pro+ 비용은 금방 회수됩니다. 하지만 Ultra는 다릅니다. 월 200달러는 "써 보면 좋겠지"로 결제할 금액이 아닙니다. AI 에이전트를 상시 개발 인력처럼 운용하고, 그 속도가 매출이나 고객 대응 속도로 이어질 때 선택하는 플랜입니다.

한 달 예산을 정할 때는 세 가지 숫자를 함께 봐야 합니다.

• Cursor 구독료

• 추가 사용량 또는 주문형 사용으로 발생할 수 있는 비용

• Cursor가 절약한 내 시간의 금전적 가치

솔로 메이커가 자주 저지르는 실수는 구독료만 보고 비싸다거나 싸다고 판단하는 것입니다. 사실 더 중요한 것은 "AI가 내 병목을 줄였는가?"입니다. 만약 Cursor가 매주 3시간을 아껴 준다면 월 20달러는 거의 고민할 필요가 없습니다. 하지만 Cursor를 켜 놓고도 대부분의 시간을 잘못된 결과를 고치느라 쓰고 있다면 월 20달러도 낭비입니다.

따라서 첫 달에는 감으로 판단하지 말고 간단한 기록을 남겨 보세요.

이 기록을 2주만 해도 어떤 작업에서 Cursor가 돈값을 하는지 보입니다. 비용 최적화는 모델 가격표를 외우는 일이 아닙니다. 내 작업 중 AI에게 맡길수록 이득인 일을 찾는 일입니다.

모델은 비싼 순서가 아니라 "작업 난이도"로 고릅니다

Cursor를 처음 쓰면 가장 강한 모델을 고르고 싶어집니다. 좋은 모델을 쓰면 좋은 코드가 나올 것 같기 때문입니다. 절반은 맞고 절반은 틀립니다. 어려운 문제에서는 강한 모델이 확실히 유리합니다. 하지만 모든 요청에 가장 비싼 모델을 쓰는 것은 편의점에 가면서 스포츠카를 매번 빌리는 것과 비슷합니다.

모델 선택의 기본 원칙은 단순합니다.

빠른 작업은 빠른 모델에게, 넓은 작업은 큰 컨텍스트 모델에게, 깊은 판단은 reasoning 모델에게 맡깁니다.

여기서 말하는 reasoning 모델은 문제를 여러 단계로 나누어 추론하는 데 강한 모델을 뜻합니다. 느리고 비쌀 수 있지만, 아키텍처 결정이나 복잡한 버그 분석에는 값어치를 합니다.

빠른 모델: 손이 느려지는 순간에 씁니다

빠른 모델은 일상적인 코딩 마찰을 줄이는 데 좋습니다. 타입 정의 추가, 간단한 유틸 함수 작성, 반복적인 JSX 수정, 테스트 이름 정리, 오류 메시지 개선 같은 작업입니다. 이런 작업에는 깊은 사고보다 반응 속도가 중요합니다.

빠른 모델을 써야 하는 작업은 대체로 실패해도 피해가 작습니다. 결과가 마음에 들지 않으면 바로 되돌리거나 직접 고치면 됩니다. 이때 고급 reasoning 모델을 쓰는 것은 비용 대비 효과가 낮습니다.

예를 들어 이런 요청은 Auto 또는 빠른 모델로 충분합니다.

이 컴포넌트의 props 타입을 더 명확하게 정리해 주세요.
기능은 바꾸지 말고 이름과 타입만 개선해 주세요.

이 에러 메시지를 사용자가 이해하기 쉬운 한국어 문장으로 바꿔 주세요.

큰 컨텍스트 모델: 여러 파일을 동시에 이해해야 할 때 씁니다

큰 컨텍스트 모델은 많은 정보를 한 번에 보고 판단해야 할 때 유리합니다. 인증 흐름, 결제 흐름, 대시보드 상태 관리, 오래된 서비스 레이어처럼 파일 하나만 봐서는 답이 나오지 않는 작업이 여기에 속합니다.

하지만 큰 컨텍스트는 공짜가 아닙니다. 많은 파일을 @로 넣고, 긴 대화를 이어 가고, Max Context를 켜면 모델이 처리해야 할 토큰이 늘어납니다. 토큰은 모델이 읽고 쓰는 텍스트의 조각 단위라고 생각하면 됩니다. 많은 문서를 읽힐수록 더 많은 계산이 필요하고, 그만큼 비용과 지연 시간이 커집니다.

큰 컨텍스트 모델을 쓸 때는 "많이 넣기"보다 "잘라 넣기"가 중요합니다. 결제 버그를 고치는데 랜딩 페이지 파일까지 읽힐 필요는 없습니다. 오히려 불필요한 파일은 모델의 주의를 흐립니다.

좋은 요청은 이렇게 생겼습니다.

@src/server/billing @src/server/webhooks @src/db/schema.ts
Stripe 결제 성공 후 credits가 두 번 증가할 수 있는 경로가 있는지 확인해 주세요.
수정하지 말고 먼저 가능한 원인과 확인할 테스트를 제안해 주세요.

나쁜 요청은 이렇게 생겼습니다.

@src 전체를 보고 결제 쪽 문제를 다 고쳐 주세요.

두 번째 요청은 넓어 보이지만 실제로는 흐릿합니다. Cursor가 많은 파일을 읽는다고 해서 더 똑똑해지는 것은 아닙니다. 필요한 파일을 정확히 읽을 때 더 똑똑해집니다.

reasoning 모델: 되돌리기 어려운 결정 전에 씁니다

reasoning 모델은 비싸게 써도 되는 순간이 있습니다. 데이터 모델 변경, 인증 구조 변경, 멀티테넌시 도입, 결제 정책 수정, 대규모 리팩터링처럼 한 번 잘못 가면 며칠을 잃는 작업입니다.

이런 작업에서는 코드를 바로 쓰게 하지 말고 먼저 생각하게 해야 합니다. 앞 장에서 다룬 Plan Mode가 여기서 비용 절감 도구가 됩니다. 무작정 Agent를 돌려 실패한 diff를 버리는 것보다, 1분 동안 좋은 계획을 받아 검토한 뒤 실행하는 편이 싸게 먹힙니다.

이 작업은 바로 구현하지 마세요.
먼저 현재 구조에서 위험한 지점, 마이그레이션 순서, 롤백 방법, 테스트 전략을 제안해 주세요.
그다음 내가 승인하면 구현해 주세요.

이 한 문장은 돈을 아껴 줍니다. AI가 잘못된 방향으로 20분 동안 달리는 것을 막아 주기 때문입니다.

비용을 줄이는 가장 쉬운 습관: Auto를 기본값으로 둡니다

Cursor의 유료 플랜에서는 Auto 모드가 중요한 비용 완충 장치가 됩니다. Auto는 Cursor가 작업에 맞는 모델을 자동으로 고르게 하는 방식입니다. 많은 사용자에게 Auto는 "생각보다 충분히 좋은 기본값"입니다. 모델을 수동으로 고르는 것은 특정 작업에서 품질을 끌어올릴 때만 해도 됩니다.

운영 원칙은 이렇게 잡으면 됩니다.

• 일상 작업은 Auto로 시작합니다.

• 결과가 불안정하거나 문제의 난도가 높을 때만 고급 모델을 수동 선택합니다.

• 같은 요청을 여러 모델에 반복해서 던지기 전에, 프롬프트와 컨텍스트를 먼저 줄입니다.

• 긴 대화가 이어졌다면 새 채팅으로 요약을 넘겨 다시 시작합니다.

• 한 번에 전체 리팩터링을 시키지 말고 작은 단위로 나눠 검증합니다.

이 원칙의 핵심은 "싼 모델을 써라"가 아닙니다. 싼 방식으로 시작하고, 필요할 때만 비싼 판단을 산다는 것입니다.

모델을 수동으로 고를 때는 마음속에 작은 신호등을 두면 편합니다.

AI 품질은 모델보다 컨텍스트에서 먼저 무너집니다

Cursor가 엉뚱한 코드를 쓰기 시작하면 사람들은 보통 모델을 탓합니다. "이 모델 별로네." 물론 모델 차이는 있습니다. 하지만 실제 작업에서 품질을 망치는 원인은 모델 자체보다 주변 환경인 경우가 많습니다.

AI는 주어진 컨텍스트 안에서 최선을 다합니다. 문제는 그 컨텍스트가 종종 쓰레기통처럼 변한다는 것입니다.

대형 monorepo는 AI에게 안개 낀 도시입니다

monorepo는 여러 앱, 패키지, 도구, 설정이 한 저장소에 들어 있는 구조입니다. 사람에게도 복잡한데 AI에게는 더 어렵습니다. 비슷한 이름의 패키지가 많고, 오래된 코드와 새 코드가 섞여 있으며, 테스트용 구현과 실제 구현이 공존합니다.

이런 저장소에서 "전체 코드베이스를 보고 고쳐 주세요"라고 하면 Cursor는 길을 잃기 쉽습니다. 관련 없는 패키지를 참고하거나, deprecated된 유틸을 새 코드에 끌어오거나, 예전 아키텍처를 현재 규칙으로 착각할 수 있습니다.

대형 저장소에서는 .cursorignore와 인덱싱 제외 규칙을 적극적으로 써야 합니다. 빌드 산출물, 오래된 실험 폴더, 생성 파일, vendor 코드, 마이그레이션 백업, 더 이상 사용하지 않는 앱은 AI의 시야에서 치워야 합니다. 사람도 책상 위가 어지러우면 일을 못 합니다. AI도 마찬가지입니다.

낡은 문서는 그럴듯한 거짓말을 만듭니다

문서가 오래되면 AI는 자신 있게 틀린 답을 합니다. README에는 "Firebase Auth를 사용한다"고 쓰여 있는데 실제 코드는 Clerk로 바뀌어 있다면, Cursor는 두 세계를 섞어 버릴 수 있습니다. 더 위험한 것은 이 결과가 꽤 그럴듯해 보인다는 점입니다.

낡은 문서는 없는 문서보다 위험할 때가 많습니다. 없는 문서는 AI가 코드를 보려고 하지만, 낡은 문서는 AI에게 잘못된 확신을 줍니다.

솔로 메이커는 문서를 완벽히 관리하기 어렵습니다. 대신 최소한의 생존 규칙을 두세요.

• README.md에는 현재 실행 방법만 남깁니다.

• docs/architecture.md에는 현재 쓰는 핵심 스택과 버린 스택을 함께 적습니다.

• 큰 구조 변경을 하면 .cursor/rules/와 PRD를 같이 업데이트합니다.

• 오래된 문서는 archive/로 옮기고 AI 인덱싱에서 제외합니다.

"문서를 잘 쓰자"는 말은 너무 큽니다. 솔로 메이커에게 필요한 것은 "AI가 잘못 믿을 문서를 줄이자"에 가깝습니다.

부정확한 Rules는 AI에게 잘못된 습관을 가르칩니다

.cursor/rules/는 강력합니다. 하지만 강력한 만큼 위험합니다. 예전에 작성한 규칙이 현재 코드와 맞지 않으면 Cursor는 낡은 규칙을 열심히 따릅니다. "API는 pages router에 작성한다"는 규칙이 남아 있는데 프로젝트가 App Router로 이동했다면, AI는 새 기능을 엉뚱한 위치에 만들 수 있습니다.

Rules는 많이 쓰는 것보다 정확하게 쓰는 것이 중요합니다. 특히 다음 규칙은 정기적으로 점검해야 합니다.

• 현재 프레임워크 버전과 맞는가?

• 실제 폴더 구조와 일치하는가?

• 더 이상 쓰지 않는 라이브러리를 권장하지 않는가?

• 보안상 위험한 우회 방법을 허용하지 않는가?

• "항상", "절대" 같은 표현이 과하게 들어가 있지 않은가?

규칙은 AI에게 주는 법전이 아니라 작업 지침서입니다. 법전처럼 길고 딱딱해지면 오히려 현장을 망칩니다.

긴 대화는 똑똑한 AI도 피곤하게 만듭니다

Cursor와 한 문제를 오래 붙잡다 보면 대화가 길어집니다. 처음에는 버그 하나를 묻다가, 중간에 설계를 바꾸고, 테스트를 추가하고, 배포 오류를 고치고, 다시 UI를 수정합니다. 이렇게 한 채팅 안에서 주제가 계속 바뀌면 모델은 앞선 맥락에 끌려다닙니다.

긴 대화의 문제는 단순히 비용만이 아닙니다. 품질도 떨어집니다. 이전에 폐기한 접근을 다시 꺼내거나, 이미 바꾼 파일 상태를 헷갈리거나, 사용자가 승인하지 않은 가정을 이어받을 수 있습니다.

이럴 때는 새 채팅을 여는 것이 가장 싸고 빠른 해결책입니다. 단, 그냥 새로 시작하지 말고 이전 대화에서 살아남은 사실만 요약해 넘깁니다.

이전 대화는 잊고 아래 사실만 기준으로 작업해 주세요.

- 목표: 결제 성공 후 credits를 정확히 1회만 증가시킨다.
- 현재 확인된 원인: webhook 재시도와 success page polling이 동시에 증가 로직을 호출할 수 있다.
- 유지할 결정: credits 증가는 서버의 idempotent 함수에서만 처리한다.
- 금지: 클라이언트에서 credits를 직접 증가시키지 않는다.

먼저 수정 계획만 제안해 주세요.

좋은 컨텍스트 관리는 비용 절감이자 품질 관리입니다.

환각은 버그가 아니라 운영 조건입니다

AI 환각은 모델이 모르는 것을 아는 것처럼 말하거나, 존재하지 않는 함수와 파일, 패키지, 정책을 만들어 내는 현상입니다. Cursor를 쓰다 보면 환각은 반드시 만납니다. 중요한 것은 환각을 완전히 없애려는 태도가 아니라, 환각이 제품에 들어가지 못하게 막는 운영선입니다.

환각은 보통 네 곳에서 제품으로 침투합니다.

첫째, 존재하지 않는 API를 호출합니다. 모델은 라이브러리의 실제 버전과 다른 사용법을 제안할 수 있습니다. 둘째, 보안에 취약한 예제 코드를 만듭니다. 인증 체크를 임시로 우회하거나, 테스트를 통과시키기 위해 검증 로직을 느슨하게 만들 수 있습니다. 셋째, 그럴듯한 의존성을 추천합니다. 이름이 비슷한 패키지를 설치하자고 제안할 수도 있습니다. 넷째, 테스트를 "코드에 맞춰" 고칩니다. 기능이 틀렸는데 테스트 기대값을 바꿔서 초록불을 만드는 식입니다.

그래서 Cursor 결과물은 항상 네 단계로 통과시켜야 합니다.

Cursor는 코드를 빨리 만들 수 있습니다. 하지만 "이 코드가 나가도 되는가?"라는 질문은 여전히 운영자의 몫입니다.

보안은 Privacy Mode 하나로 끝나지 않습니다

Cursor 공식 요금 페이지는 Privacy Mode를 설정 또는 팀 관리자가 활성화할 수 있으며, 활성화되면 코드 데이터가 모델 제공업체에 저장되거나 학습에 사용되지 않도록 보장한다고 설명합니다.¹ 이것은 중요한 기능입니다. 특히 고객 코드, 사내 코드, 비공개 제품을 다루는 사람이라면 반드시 확인해야 합니다.

하지만 Privacy Mode는 보안의 시작이지 끝이 아닙니다. AI 코딩 도구의 위험은 "내 코드가 학습에 쓰일까?"만이 아닙니다. 더 흔한 위험은 내가 민감한 정보를 AI 컨텍스트에 넣거나, 에이전트가 위험한 명령을 실행하거나, AI가 제안한 의존성이 안전하지 않은 경우입니다.

보안 관점에서 Cursor는 아주 빠르고 성실한 주니어 개발자처럼 봐야 합니다. 문제는 이 주니어가 파일을 수정하고, 터미널 명령을 실행하고, 패키지를 설치하고, 때로는 배포 설정까지 건드릴 수 있다는 점입니다.

따라서 다음 파일과 정보는 AI의 기본 시야에서 빼는 것이 좋습니다.

• .env, .env.local, .env.production

• API 키, 개인키, 인증서, 토큰이 들어 있는 파일

• 고객 개인정보가 포함된 로그와 CSV

• 실제 production 데이터 덤프

• 결제 제공업체의 시크릿 키와 webhook secret

• 배포 권한이 있는 CI/CD 토큰

• 인프라 변경 권한이 있는 Terraform state 또는 kubeconfig

.cursorignore는 단순 정리 도구가 아니라 보안 장치입니다. 단, 한 가지를 기억해야 합니다. 어떤 파일이 무시 목록에 있더라도 IDE에서 열려 있거나 사용자가 직접 붙여 넣으면 AI 컨텍스트에 들어갈 수 있습니다. 민감한 정보를 열어 둔 채로 "이 오류 고쳐 줘"라고 하는 습관은 위험합니다.

로그를 붙여 넣을 때도 마찬가지입니다. 로그 안에는 이메일, 세션 ID, 결제 ID, 내부 URL, 토큰 일부가 섞여 있을 수 있습니다. Cursor에게 보여 주기 전에 지워야 합니다. 귀찮아도 이 습관 하나가 사고를 막습니다.

인간 승인선: AI가 멈춰야 하는 지점

솔로 메이커는 혼자라서 더 위험합니다. 팀에서는 누군가 "이거 진짜 배포해도 되나요?"라고 묻지만, 혼자 일하면 그 질문을 스스로 해야 합니다. 그래서 인간 승인선을 명시해야 합니다.

인간 승인선은 "AI가 여기까지는 해도 되지만, 여기부터는 내가 직접 확인하고 승인한다"는 경계입니다. 이 선이 없으면 Cursor는 너무 열심히 일합니다. 열심히 일하는 도구는 때로 위험합니다.

인증과 권한

로그인, 세션, 권한 체크, 관리자 기능은 반드시 인간 승인선을 둡니다. AI가 "일단 테스트를 통과시키기 위해" middleware를 우회하거나, 임시로 role 검사를 느슨하게 만들면 제품 전체가 위험해집니다.

인증 관련 작업에서는 Cursor에게 먼저 질문해야 합니다.

수정 전에 현재 인증 흐름을 설명해 주세요.
어떤 요청에서 사용자를 식별하고, 어디서 권한을 검사하는지 파일별로 정리해 주세요.
그다음 변경이 필요한 최소 지점만 제안해 주세요.

설명을 이해한 뒤에만 구현을 승인합니다. 인증 코드는 "돌아간다"보다 "막아야 할 것을 막는다"가 중요합니다.

결제와 크레딧

결제 코드는 솔로 메이커의 심장입니다. 결제가 두 번 처리되거나, 무료 사용자가 유료 기능을 쓰거나, 환불 후에도 권한이 남아 있으면 바로 돈과 신뢰의 문제가 됩니다.

결제 관련 작업에서는 AI에게 구현을 맡길 수는 있지만, 다음 결정은 사람이 해야 합니다.

특히 결제 webhook은 반드시 idempotent하게 만들어야 합니다. idempotent란 같은 요청이 여러 번 들어와도 결과가 한 번 처리된 것과 같도록 만드는 성질입니다. 결제 제공업체는 네트워크 문제로 webhook을 재시도할 수 있습니다. AI가 이 사실을 놓치면 "가끔 credits가 두 배로 늘어나는" 무서운 버그가 생깁니다.

개인정보와 production 데이터

개인정보는 개발 편의를 위해 AI에게 보여 줄 대상이 아닙니다. 이메일 하나, 전화번호 하나, 결제 내역 한 줄도 조심해야 합니다. 실제 고객 데이터를 붙여 넣어 버그를 설명하는 습관은 빠르지만 위험합니다.

production 데이터가 필요한 버그라면 먼저 익명화된 샘플을 만드세요. 예를 들어 실제 이메일 대신 user_123@example.com, 실제 결제 ID 대신 pay_sample_001을 사용합니다. 중요한 것은 데이터의 모양이지 실제 값이 아닙니다.

AI에게 줄 수 있는 데이터는 "문제를 재현하는 데 필요한 구조"까지만입니다. 실제 고객을 식별할 수 있는 정보는 넘기지 않습니다.

배포 자동화와 인프라

배포 스크립트, GitHub Actions, Vercel 설정, Dockerfile, Terraform, Kubernetes 설정은 AI가 수정할 수 있지만 자동 적용해서는 안 됩니다. 특히 Agent가 터미널 명령을 실행할 수 있는 환경에서는 더 조심해야 합니다.

배포와 인프라 작업에서는 다음 원칙을 둡니다.

• AI는 변경안을 만들 수 있습니다.

• AI는 로컬 검증 명령을 제안할 수 있습니다.

• AI는 production 배포 명령을 직접 실행하지 않습니다.

• AI는 secret을 생성하거나 저장하지 않습니다.

• AI가 만든 배포 변경은 diff를 사람이 읽은 뒤 병합합니다.

Cursor 팀도 자체 보안 자동화를 운영하면서 PR 리뷰, 취약점 탐지, 의존성 패치, 컴플라이언스 드리프트 감시 같은 에이전트를 활용하지만, 발견 사항을 Slack과 PR로 보고하고 차단 게이트를 두는 식으로 운영한다고 설명합니다.³ 즉, 자동화는 넓은 커버리지를 제공하지만 중요한 판단 지점에는 여전히 검증과 승인 흐름이 놓입니다.

의존성 설치는 "AI 추천"이 아니라 "공급망 변경"입니다

AI가 새 패키지를 추천할 때가 있습니다. 날짜 포맷, CSV 파싱, 인증, 암호화, 결제, 차트, 에디터, 파일 업로드 등 거의 모든 기능에서 패키지 제안이 나옵니다. 문제는 AI가 패키지의 현재 안전성을 보장하지 않는다는 점입니다.

패키지 하나를 추가하는 것은 코드 몇 줄을 추가하는 것보다 큰 결정일 수 있습니다. 패키지는 설치 스크립트를 실행할 수 있고, transitive dependency, 즉 그 패키지가 다시 의존하는 다른 패키지들을 끌고 옵니다. 작은 기능을 위해 수십 개의 의존성이 들어올 수 있습니다.

AI가 패키지를 추천하면 바로 npm install을 치지 말고 다음을 확인합니다.

• 패키지 이름이 유명 패키지와 미묘하게 다르지 않은가?

• 최근에도 유지보수되고 있는가?

• GitHub 저장소, 문서, 이슈, 릴리스 기록이 자연스러운가?

• 다운로드 수만 많고 관리자가 불분명하지 않은가?

• 같은 기능을 이미 프로젝트 안의 의존성으로 해결할 수 없는가?

• 보안 스캐너나 npm audit에서 치명적 문제가 나오지 않는가?

특히 인증, 암호화, 결제, 파일 업로드와 관련된 패키지는 더 엄격하게 봅니다. 솔로 메이커는 시간이 없어서 패키지를 쓰지만, 시간이 없을수록 검증되지 않은 패키지 하나가 제품을 오래 괴롭힙니다.

Bugbot과 보안 에이전트는 리뷰어이지 판사가 아닙니다

앞 장에서 Bugbot과 Automations를 다뤘습니다. 이들은 솔로 메이커에게 매우 유용합니다. 혼자서도 PR 리뷰를 받고, 잠자는 동안 취약점 후보를 찾고, 반복적인 점검을 자동화할 수 있습니다. Cursor가 공개한 보안 에이전트 사례처럼, 에이전트는 많은 PR과 기존 코드베이스를 지속적으로 훑으며 사람이 놓칠 수 있는 문제를 찾아낼 수 있습니다.³

하지만 AI 리뷰어는 확률적입니다. 좋은 지적을 할 때도 있고, 틀린 경고를 낼 때도 있으며, 진짜 문제를 놓칠 때도 있습니다. Snyk의 분석도 LLM 기반 보안 리뷰에서는 오탐과 미탐을 모두 고려해야 하며, 에이전트가 스스로의 숙제를 채점하게 해서는 안 된다는 점을 강조합니다.⁴

따라서 Bugbot이나 보안 에이전트의 결과는 이렇게 다룹니다.

AI 리뷰어는 혼자 일하는 사람에게 두 번째 눈을 줍니다. 그러나 최종 서명은 여전히 내 이름으로 나갑니다.

솔로 메이커를 위한 월간 운영 루틴

Cursor를 오래 쓰려면 매일 모든 것을 통제할 필요는 없습니다. 대신 월 1회 운영 점검을 하면 됩니다. 제품 운영도, 비용 관리도, 보안 관리도 결국 루틴이 이깁니다.

월말이나 결제일 전날 30분만 잡아 다음을 확인하세요.

1. 사용량과 비용 확인

이번 달에 Cursor를 어디에 많이 썼는지 봅니다. 단순 자동완성 위주였는지, Agent 요청이 많았는지, Cloud Agents를 자주 돌렸는지, 특정 고급 모델에 과하게 의존했는지 확인합니다. 예상보다 비용 압박이 컸다면 플랜을 올리기 전에 먼저 작업 방식을 조정합니다.

2. 실패한 AI 작업 회고

Cursor가 만든 결과 중 버린 것이 무엇인지 봅니다. 실패 원인이 모델이 약해서였는지, 프롬프트가 모호해서였는지, 컨텍스트가 너무 넓어서였는지, Rules가 낡아서였는지 구분합니다.

대부분의 실패는 더 비싼 모델이 아니라 더 좁은 요청으로 해결됩니다.

3. Rules와 문서 정리

.cursor/rules/에서 오래된 규칙을 제거합니다. README와 architecture 문서가 현재 코드와 맞는지 봅니다. 지난달에 바꾼 중요한 구조가 문서와 규칙에 반영되지 않았다면 짧게라도 업데이트합니다.

4. 보안 제외 목록 점검

.cursorignore, .gitignore, secret scanning 설정을 확인합니다. 새로 생긴 .env.*, 로그 파일, export 파일, 고객 데이터 샘플이 AI 인덱싱이나 Git 추적 대상에 들어가지 않았는지 봅니다.

5. 승인선 재확인

이번 달에 인증, 결제, 개인정보, 배포 자동화 중 무엇을 건드렸는지 봅니다. AI가 만든 변경이 있다면 테스트와 리뷰 기록이 남아 있는지 확인합니다.

이 루틴은 거창하지 않습니다. 하지만 혼자 제품을 만드는 사람에게는 작은 CTO 회의와 같습니다. 참석자는 나 한 명뿐이지만, 비용 담당자, 보안 담당자, 품질 담당자, 개발자가 모두 그 안에 있습니다.

플랜 업그레이드보다 워크플로우 업그레이드가 먼저입니다

Cursor 비용이 부담될 때 가장 쉬운 선택은 플랜을 올리는 것입니다. Pro가 부족하면 Pro+, Pro+가 답답하면 Ultra. 물론 필요한 순간이 있습니다. 하지만 플랜을 올리기 전에 먼저 워크플로우를 점검해야 합니다.

다음 상황이라면 플랜 업그레이드보다 작업 방식 개선이 먼저입니다.

• Agent에게 너무 큰 작업을 한 번에 맡깁니다.

• 같은 실패 요청을 모델만 바꿔 반복합니다.

• 긴 대화 하나에서 여러 주제를 계속 처리합니다.

• Rules와 문서가 실제 코드와 맞지 않습니다.

• 테스트 없이 AI 결과를 눈으로만 확인합니다.

• 인증, 결제, 배포 작업에도 승인선이 없습니다.

반대로 다음 상황이라면 업그레이드를 고려할 만합니다.

• Pro 한도를 아끼느라 중요한 작업에서 AI 사용을 망설입니다.

• 매일 Agent를 쓰고 결과물의 채택률이 높습니다.

• Cursor가 실제로 기능 출시 속도를 높이고 있습니다.

• 고급 모델을 써야 하는 복잡한 작업이 꾸준히 있습니다.

• 월 60달러 또는 200달러가 절약되는 시간과 매출에 비해 작습니다.

좋은 운영자는 무조건 아끼지 않습니다. 필요한 곳에는 씁니다. 다만 어디에 쓰는지 알고 씁니다.

Cursor 운영 원칙 10가지

마지막으로 이 장의 내용을 실제 작업 책상 앞에 붙여 둘 수 있는 원칙으로 정리해 보겠습니다.

1. Pro로 시작하고 한 달 동안 사용 패턴을 기록합니다. 감이 아니라 데이터로 업그레이드를 결정합니다.

2. Auto를 기본값으로 둡니다. 고급 모델은 복잡한 설계, 디버깅, 보안 작업에 예약합니다.

3. 큰 컨텍스트는 필요한 파일만 넣습니다. 많이 보여 주는 것이 아니라 정확히 보여 주는 것이 중요합니다.

4. 긴 대화는 끊고 요약으로 새로 시작합니다. 대화가 길어질수록 비용과 오류가 함께 늘어납니다.

5. Rules는 짧고 현재 코드와 맞게 유지합니다. 낡은 규칙은 AI 품질을 망칩니다.

6. 낡은 문서는 archive로 보내고 인덱싱에서 제외합니다. AI가 잘못 믿을 자료를 줄입니다.

7. 인증, 결제, 개인정보, 배포는 인간 승인선을 둡니다. AI가 초안을 만들 수는 있지만 최종 판단은 사람이 합니다.

8. 새 의존성은 반드시 검증합니다. AI 추천은 공급망 변경 제안일 뿐입니다.

9. 테스트와 diff 검토 없이 병합하지 않습니다. AI가 만든 코드도 내 제품의 코드입니다.

10. 월 1회 비용, 품질, 보안 루틴을 돌립니다. 솔로 메이커에게 운영 회의는 선택이 아니라 생존 장치입니다.

Cursor는 혼자 일하는 사람에게 놀라운 힘을 줍니다. 하지만 그 힘은 공짜도 아니고, 무오류도 아니며, 무제한도 아닙니다. 에이전트 시대의 솔로 메이커는 더 빨리 만드는 사람일 뿐 아니라, 더 명확한 경계를 세우는 사람이어야 합니다.

AI에게 일을 맡기는 능력만으로는 부족합니다. 이제는 AI가 만든 속도를 비용, 품질, 보안 안에서 운영하는 능력이 필요합니다. 그 순간 Cursor는 단순한 코딩 도구를 넘어, 혼자서 제품을 만들고 운영하는 작은 개발 조직의 운영체제가 됩니다.

참고

¹Cursor 요금제

²What Happened to Cursor Pricing? 2026 Guide & 5 Cost Cutting Tips

³자율형 에이전트로 코드베이스 보호하기 · Cursor

⁴I Read Cursor's Security Agent Prompts, So You Don't Have To