커서로 2주 만에 AI SaaS 런칭하기: .cursorrules와 플래닝 전략

커서 코리아와 함께하는 커서 밋업 서울 행사에 참여했다. 이 포스트는 첫 번째 강연 "커서로 2주 만에 경쟁자보다 10배 더 좋은 AI SaaS 런칭기"의 내용을 요약 정리한 것이다.

강연자가 설명하는 내용을 시간 순으로 정리했으며, 주장하는 바를 납득할 수 있도록 그 배경과 히스토리도 함께 기재했다.

이 글을 읽는 독자의 업무 효율성 향상에 도움이 되길 바란다.

들어가며

AI 개발 도구의 발전으로 개발 속도가 혁신적으로 향상되고 있다. 특히 Cursor 같은 AI 코딩 어시스턴트는 단순히 코드 작성을 도와주는 것을 넘어서, 프로젝트 전체의 개발 프로세스를 변화시키고 있다.

캐럿(Caret) 팀은 이러한 변화를 몸소 실천하며, 2주 만에 AI 미팅 노트 테이커 서비스를 성공적으로 런칭했다. 현재 5천 명의 사용자를 보유하고 있으며, 매월 25%씩 성장하고 있는 이 서비스가 어떻게 단기간에 개발될 수 있었는지, 그 핵심 전략을 살펴보자.

기존 개발 프로세스의 한계와 새로운 접근

전통적인 개발 프로세스의 문제점

일반적인 제품 개발 프로세스는 다음과 같다:

1. 기능 기획
2. 프로토타입 및 디자인
3. 백엔드 API 설계 및 개발
4. 프론트엔드 UI 개발
5. 연동 및 QA
6. 배포

이러한 순차적 프로세스는 안정적이지만, 빠른 속도가 요구되는 상황에서는 한계가 명확하다. 특히 스타트업 환경에서는 "2주 안에 경쟁사의 모든 기능을 포함하면서도 차별화된 제품을 출시해야 한다"는 압박이 있을 때, 기존 방식으로는 최소 두 달이 소요될 것으로 예상되었다.

병렬 개발을 위한 새로운 전략

캐럿 팀은 이 문제를 해결하기 위해 혁신적인 접근 방식을 채택했다:

4명의 엔지니어가 각자 하나의 기능을 전담하여 기획-디자인-개발을 동시에 진행

• 멀티플랫폼 개발자: Windows/macOS 앱의 오디오 캡처 및 믹싱 기능
• 실시간 처리 개발자: 음성 인식 및 트랜스크립션 품질 향상
• 미팅 기능 개발자: 캘린더 연동, 번역, UI 구현
• 워크스페이스 개발자: B2B를 위한 권한 관리 시스템

이 전략이 성공할 수 있었던 핵심은 일관성 있는 코드 작성을 보장하는 시스템이었다. 그 중심에 .cursorrules 파일이 있었다.

.cursorrules: 팀 차원의 AI 컨텍스트 관리

.cursorrules가 필요한 이유

Cursor를 팀 단위로 사용할 때 가장 큰 문제는 일관성이다. 각 개발자가 "이거 만들어줘", "버그 수정해줘" 식으로 개별적으로 요청하면, AI는 프로젝트 전체의 맥락을 이해하지 못한 채 코드를 생성한다.

2024년 1월 당시에는 Cursor의 프로젝트 스캔 기능이 현재만큼 발달하지 않았기 때문에, 매번 컨텍스트를 수동으로 제공해야 했다. 이는 비효율적일 뿐만 아니라 팀원 간 코드 스타일의 불일치를 야기했다.

캐럿 팀의 .cursorrules 구조

캐럿 팀의 .cursorrules 파일은 다음과 같이 구체적이고 실용적으로 구성되었다:

1. 프로젝트 개요 - AI의 기본 이해 설정

# 프로젝트 소개
우리는 AI 미팅 노트 테이커인 캐럿을 개발한다.
실시간 트랜스크립션과 AI 기반 노트 정리 기능을 제공한다.
미팅이 진행되는 동안 실시간으로 음성을 텍스트로 변환하고,
미팅 종료 후 AI가 정리된 노트를 생성한다.

이유: AI가 단순히 코드를 생성하는 것이 아니라, 프로젝트의 목적과 맥락을 이해한 상태에서 관련성 높은 코드를 작성할 수 있도록 한다. 예를 들어, "미팅 노트"라는 맥락을 알고 있으면 변수명이나 함수명을 더 적절하게 제안할 수 있다.

2. 코드 구조 명시 - 거대한 모노레포 네비게이션

캐럿의 코드베이스는 모노레포로 구성되어 있어 상당히 크다. 2024년 1월 당시 Cursor의 프로젝트 스캔 기능이 지금만큼 발달하지 않았기 때문에, AI가 필요한 파일을 찾기 위해 상당한 시간을 소비했다. 이를 해결하기 위해 상세한 프로젝트 구조를 명시했다:

## Project Structure
- TypeScript + pnpm (패키지 매니저) + Supabase (데이터베이스)
- apps/api: Cloudflare Workers 환경에서 실행되는 백엔드 (Hono 프레임워크, tRPC)
- apps/web: Next.js로 구현된 메인 웹 애플리케이션 (Vercel 배포, TailwindCSS, shadcn-UI)
- apps/landing: 마케팅용 랜딩 페이지 (Next.js)
- apps/docs: Mintlify로 작성된 개발자 문서 (.mdx 파일)
- packages/common: 공통 타입 정의, Zod 스키마, Supabase 테이블 스키마 자동 생성
- packages/ui: 재사용 가능한 shadcn-UI 컴포넌트들

## 임포트 가이드라인
- Supabase 테이블: `import { tables } from '@caret/common/data'`
- 타입 정의: `import { Type } from '@caret/common/types/feature'`
- UI 컴포넌트: `import { Button } from '@caret/ui'`

세부 설명:

• apps/ 폴더: 실제 배포되는 애플리케이션들
• packages/ 폴더: 여러 앱에서 공통으로 사용하는 코드들
• 임포트 경로 명시: AI가 "버튼이 필요해"라고 하면 새로 만들지 않고 @caret/ui에서 가져오도록 유도

이유: 모노레포 구조에서는 동일한 기능을 하는 파일이 여러 위치에 존재할 수 있다. 명확한 구조 가이드 없이는 AI가 잘못된 파일을 수정하거나, 이미 존재하는 컴포넌트를 다시 만드는 등의 비효율이 발생한다. 특히 캐럿처럼 빠른 개발이 필요한 상황에서는 이런 시간 낭비가 치명적이다.

3. 코딩 규칙 - 팀 컨벤션의 자동화

## Caret Coding Rules
- 최소한의 외부 의존성으로 개발 (번들 사이즈 최적화)
- 기존 코딩 패턴을 분석한 후 동일한 스타일로 작성
- 데이터베이스 타입은 Supabase의 `Tables<'table_name'>` 형식 사용 (별도 DTO 생성 금지)
- 패키지 설치 시 반드시 `pnpm add --filter @caret/<package-name> <dependency-name>` 명령어 사용
- 주석 최소화 (코드 자체가 설명이 되도록)

이유: 4명이 동시에 개발하면서 코드 스타일이 달라지는 것을 방지한다. 특히 Supabase 타입 규칙은 중요한데, 개발자마다 다른 방식으로 데이터베이스 타입을 정의하면 나중에 타입 불일치 오류가 발생할 수 있다. 패키지 설치 명령어까지 명시한 이유는 모노레포에서 잘못된 위치에 의존성을 설치하면 빌드 오류가 발생하기 때문이다.

4. 모듈별 세부 규칙 - AI의 상상력 제한하기

각 모듈은 웹 개발에서 기능별로 나뉜 코드 단위를 의미한다. 예를 들어:

• API 모듈: 서버 로직, 데이터베이스 연동
• Web 모듈: 사용자 인터페이스, 프론트엔드 로직
• UI 모듈: 재사용 가능한 컴포넌트들

문제는 AI가 프로젝트 구조만 보고는 "이런 기능도 있을 것이다", "저런 기능도 만들어야겠다"고 추측하여 존재하지 않는 기능을 구현하려 한다는 점이었다. 이를 방지하기 위해 각 모듈의 실제 기능만을 명시했다:

## API 모듈 (`apps/api`) 세부 규칙
- 루트 레벨 라우터는 `apps/api/src/router.ts`에 정의됨
- 서브 라우터들을 이곳에서 임포트하여 구성
- 새로운 API 엔드포인트 추가 시 반드시 루트 라우터에 등록
- tRPC를 사용하므로 타입 안전성을 위해 Zod 스키마 필수
- 현재 구현된 기능: 음성 처리, 사용자 인증, 미팅 관리
- 구현되지 않은 기능을 임의로 추가하지 말 것

## Web 모듈 (`apps/web`) 세부 규칙
- Next.js App Router 사용
- 페이지 컴포넌트는 `app/` 디렉토리 구조를 따름
- 공통 컴포넌트는 `components/` 폴더에 위치
- 현재 구현된 페이지: 대시보드, 미팅 뷰, 설정
- 새로운 페이지 추가 시 반드시 네비게이션 업데이트 필요

구체적인 예시:
AI가 "미팅 관리 기능을 개선해줘"라는 요청을 받았을 때, 모듈 규칙이 없다면 채팅 기능, 화면 공유 기능 등을 추가로 구현하려 할 수 있다. 하지만 위와 같은 규칙이 있으면 현재 구현된 기능(음성 처리, 사용자 인증, 미팅 관리) 범위 내에서만 개선안을 제시한다.

이유: AI의 창의성은 장점이지만, 빠른 개발이 필요한 상황에서는 오히려 방해가 될 수 있다. 존재하지 않는 기능을 구현하려다가 에러가 발생하거나, 불필요한 코드가 추가되어 복잡성이 증가할 수 있다. 명확한 경계를 설정함으로써 AI가 현실적이고 실용적인 코드를 생성하도록 유도한다.

5. 다국어 지원 규칙

## i18n 필수 사항
- 모든 UI 텍스트는 i18n 폴더에 등록
- 하드코딩 금지, JSON 파일에서 불러오기
- 한국어, 영어, 일본어 지원

이유: 글로벌 서비스를 위한 다국어 지원을 처음부터 고려하여, 나중에 리팩토링하는 비용을 줄인다.

6. 디자인 시스템

기존 컴포넌트와 UI 패턴에 대한 설명을 포함하여, AI가 새로운 컴포넌트를 만들기보다는 기존 것을 재사용하도록 유도했다.

이유: 디자인 일관성을 유지하고, 불필요한 중복 컴포넌트 생성을 방지한다.

플래닝 에이전트로서의 Cursor 활용

기술적 의사결정 지원

캐럿 팀은 Cursor를 단순한 코딩 도구가 아닌 플래닝 에이전트로도 활용했다. 특히 멀티플랫폼 개발에서 이 접근법이 빛을 발했다.

상황: macOS는 익숙하지만 Windows 개발 경험이 부족한 상태에서 시스템 오디오 캡처 기능을 구현해야 함

질문 방식:

"Windows에서 시스템 오디오를 캡처하고 싶은데, 어떤 API들이나 라이브러리가 있어?"

Cursor의 답변:

• WWDC 2024에서 소개된 macOS API 정보
• Windows에는 해당 라이브러리가 없어 직접 구현 필요
• 사용 가능한 Windows API 목록과 기능 설명

아키텍처 설계 지원

단순히 API 정보를 제공하는 것을 넘어서, Cursor는 전체 아키텍처 설계에도 도움을 주었다:

질문:

"우리 파이프라인이 이렇게 구성되어 있고, 각 플랫폼별로 구현해야 하는데, 
인터페이스는 동일하게 맞추고 내부 구현체만 다르게 하고 싶어."

결과:

• 공통 인터페이스 설계 제안
• 각 OS별 구현 방법 가이드
• 플랫폼별 최적화 방안 제시

플래닝 에이전트 활용의 장점

1. 학습 곡선 단축: 새로운 기술 스택이나 플랫폼에 대한 진입 장벽을 낮춤
2. 의사결정 속도 향상: 기술적 선택지를 빠르게 파악하고 비교 가능
3. 아키텍처 검증: 설계 아이디어를 AI와 토론하며 개선점 발견

실제 개발 속도의 변화

정량적 성과

• 개발 기간: 기존 2개월 → 2주로 단축
• 팀 구성: 4명의 엔지니어로 4개 핵심 기능 동시 개발
• 배포 주기: 현재 일주일에 하나의 새 기능 배포 유지

정성적 변화

개발자 경험 개선:

• 반복적인 boilerplate 코드 작성 시간 단축
• 새로운 기술 학습을 위한 시행착오 시간 감소
• 코드 리뷰에서 스타일 관련 피드백 최소화

팀 협업 효율성:

• 일관된 코드 스타일로 코드 가독성 향상
• 모듈 간 인터페이스 설계 표준화
• 문서화 부담 감소 (코드 자체가 표준을 따름)

현실적인 한계와 해결책

AI의 한계 인식

Cursor를 활용했다고 해서 모든 것이 완벽하지는 않았다:

1. 빌드 실패: AI가 제안한 코드가 실제로는 빌드되지 않는 경우
2. UX 라이팅: 여전히 인간의 세심한 검토가 필요한 영역
3. 복잡한 비즈니스 로직: 도메인 전문성이 필요한 부분

해결 접근법

점진적 개선:

• AI 제안을 기반으로 시작하되, 인간이 최종 검증 및 수정
• 최소한의 로우레벨 작업은 AI에게 맡기고, 핵심 로직에 집중
• 지속적인 .cursorrules 업데이트로 AI의 정확성 향상

다른 플랫폼으로의 확장

Android 개발

Android Studio에서는 Cursor를 직접 사용할 수 없지만, Firebender라는 플러그인을 통해 유사한 경험을 구현했다:

• Cursor와 동일한 UI 제공
• GPT-4 기반 코드 생성
• JetBrains의 내장 AI보다 우수한 성능

iOS/macOS 개발

Apple이 VS Code 플러그인을 지원하면서, Xcode 없이도 iOS/macOS 앱 개발이 가능해졌다. 이를 통해 Cursor를 활용한 Apple 플랫폼 개발도 실현할 수 있었다.

미래 전망과 권장사항

지속적인 진화

AI 도구의 발전 속도를 고려할 때, 다음과 같은 방향으로 발전할 것으로 예상된다:

1. 더 정교한 컨텍스트 이해: 프로젝트 전체 구조를 더 잘 파악
2. 실시간 협업: 팀원 간 AI 어시스턴트 공유 및 학습
3. 도메인 특화: 특정 분야에 특화된 AI 모델 등장

팀에서 도입 시 권장사항

1. 작은 프로젝트부터 시작: 전체 워크플로우를 한 번에 바꾸지 말고 점진적 적용
2. 팀 규칙 정의: .cursorrules 같은 공통 가이드라인 사전 정의
3. 지속적 업데이트: AI 도구의 발전에 맞춰 사용법도 함께 진화
4. 한계 인식: AI가 만능이 아님을 인정하고 인간의 판단력 유지

끝맺으며

캐럿 팀의 성공 사례는 AI 도구를 단순히 코드 생성기로 사용하는 것을 넘어서, 전체 개발 프로세스의 혁신 도구로 활용했다는 점에서 의미가 크다.

특히 .cursorrules를 통한 팀 차원의 컨텍스트 관리와, 플래닝 에이전트로서의 AI 활용은 다른 팀들이 참고할 만한 실용적인 전략이다.

AI 시대에 맞는 새로운 개발 방법론을 찾고 있는 팀이라면, 캐럿 팀의 접근법을 참고하여 자신들만의 AI 협업 시스템을 구축해보는 것을 권장한다.

중요한 것은 AI를 도구로 활용하되, 인간의 창의성과 판단력을 중심에 두는 균형잡힌 접근이다. 그럴 때 비로소 "2주 만에 경쟁자보다 10배 더 좋은 서비스"를 만드는 것이 현실이 될 수 있을 것이다.