만약 당신이 Cursor나 Replit AI를 사용하여 앱을 빌드하는 데 몇 시간 이상을 소비했다면, 아마 이런 상황을 겪어보았을 것입니다.

당신은 AI에게 기능을 만들어 달라고 요청합니다.

하지만 대신 AI는 다음과 같은 행동을 합니다:

• 파일들을 무작위 위치에 생성합니다.
• 이미 잘 작동하던 코드를 다시 작성합니다.
• 임포트 (imports)를 환각 (hallucinates) 합니다.
• 하나의 에러를 고치면 세 개의 새로운 에러를 만들어내는 과정을 반복합니다.
• "고쳤습니다" → "새로운 에러 발생"이라는 끝없는 루프에 갇힙니다.

익숙한 상황인가요?

당신만 그런 것이 아닙니다.

대부분의 개발자가 저지르는 가장 큰 실수는 Cursor를 사용하는 것이 아닙니다. 적절한 아키텍처 (architecture)를 제공하기 전에 Cursor에게 코딩을 시키는 것입니다.

진짜 문제는 Cursor가 아니다

Cursor는 코드를 작성하는 데 믿을 수 없을 정도로 뛰어납니다.
하지만 당신의 프로젝트 구조를 추측하는 데는 형편없습니다.

AI가 다음과 같은 사항을 알지 못할 때:

• 기술 스택 (tech stack),
• 폴더 구성 (folder organization),
• 데이터베이스 설계 (database design),
• 코딩 표준 (coding standards),
• 또는 구현 순서 (implementation order),

AI는 가정을 하기 시작합니다.

그 가정들은 다음과 같은 결과로 이어집니다:

• 중복된 컴포넌트 (duplicate components),
• 일관성 없는 API (inconsistent APIs),
• 깨진 임포트 (broken imports),
• 충돌하는 상태 관리 (conflicting state management),
• 끝없는 리팩토링 (refactors),
• 그리고 결국 자신의 실수를 계속 뒤쫓는 에이전트 (agent).

이것이 사람들이 Cursor가 "환각 (hallucinating)"을 일으킨다고 생각하는 이유입니다.

대부분의 경우, AI는 단순히 컨텍스트 (context)가 부족한 것뿐입니다.

핵심적인 깨달음

Cursor를 주니어 소프트웨어 엔지니어 (junior software engineer)라고 생각하십시오.

당신은 주니어 개발자에게 다음과 같이 말하겠습니까?

"내 SaaS 앱 전체를 가서 만들어와."

당연히 아니겠죠.

당신은 먼저 다음과 같은 것들을 제공할 것입니다:

• 아키텍처 (Architecture)
• 요구사항 (Requirements)
• 폴더 구조 (Folder structure)
• 데이터베이스 설계 (Database design)
• 개발 계획 (Development plan)

그다음에야 그들은 코딩을 시작할 것입니다.

AI 코드 빌더 (AI code builders)도 정확히 똑같은 방식으로 작동합니다.

단 하나의 파일을 생성하기 전에 완전한 시스템 아키텍처 (system architecture)를 제공받을 때, 이들은 극적으로 더 나은 성능을 발휘합니다.

그 한 가지 변화가 AI가 생성한 놀라울 정도로 많은 버그를 제거해 줍니다.

모든 것을 바꾼 3단계 워크플로우 (Workflow)

Cursor에게 "앱을 만들어줘"라고 요청하는 대신, 프로세스를 세 단계로 나누십시오.

1단계 — 기술 스택 및 데이터베이스 스키마 정의

코드를 작성하기 전에 기반을 문서화하십시오.

다음과 같은 사항들을 포함해야 합니다:

• 프론트엔드 프레임워크 (Frontend framework)
• 백엔드 프레임워크 (Backend framework)
• 데이터베이스 (Database)
• 인증 (Authentication)
• 상태 관리 (State management)
• API 스타일 (API style)
• 배포 대상 (Deployment target)

예시:

Frontend:
- Next.js
- TypeScript
...

그 다음 데이터베이스 스키마 (database schema)를 정의하십시오.

예시:

Users
- id
- email
...

이제 Cursor는 테이블을 임의로 만들어내기 전에 어떤 데이터가 존재하는지 이해하게 됩니다.

2단계 — 디렉토리 구조 설계

이 단계는 놀라울 정도로 자주 생략되곤 합니다.

그것이 바로 AI가 루트 디렉토리 (root directory)에 파일을 마구 쏟아붓기 시작하는 정확한 이유입니다.

대신, 프로젝트 레이아웃 (project layout)을 먼저 정의하십시오.

예시:

src/
├──components/
├──pages/
...

또한 다음과 같은 규칙을 정의하십시오:

공통 컴포넌트 (Shared components)는 components/에 위치한다
API 로직은 services/ 내부에 유지한다
데이터베이스 코드는 database/에만 존재한다
유틸리티 함수 (Utility functions)는 utils/ 내부에 유지한다

이렇게 하면 엄청난 양의 모호함이 제거됩니다.

AI는 더 이상 새로운 파일이 어디에 속해야 하는지 추측할 필요가 없습니다.

3단계 — 단계별 프롬프트 시퀀스를 사용하여 구축

이것이 여러분이 할 수 있는 가장 큰 개선 사항입니다.

Cursor에게 모든 것을 한꺼번에 구축해 달라고 절대 요청하지 마십시오.

대신, 개발을 별도의 프롬프트 (prompts)로 나누십시오.

1단계 — UI 구축

다음 사항에 대해서만 프롬프트를 작성하십시오:

• 페이지 (pages)
• 레이아웃 (layouts)
• 재사용 가능한 컴포넌트 (reusable components)
• 네비게이션 (navigation)
• 스타일링 (styling)

인증 (authentication)에 대해서는 언급하지 마십시오.

API에 대해서도 언급하지 마십시오.

데이터베이스에 대해서도 언급하지 마십시오.

오직 인터페이스 (interface)만 다루십시오.

2단계 — 인증 및 데이터베이스 추가

UI가 완성되면 다음 단계로 넘어갑니다:

• 인증 (authentication)
• 데이터베이스 스키마 (database schema)
• 마이그레이션 (migrations)
• API 라우트 (API routes)
• CRUD 작업 (CRUD operations)

UI가 이미 존재하기 때문에, Cursor는 모든 것을 연결할 안정적인 대상(target)을 갖게 됩니다.

3단계 — 비즈니스 로직 추가

앱 구조가 안정된 후에만 다음 사항들을 구현해야 합니다:

• 유효성 검사 (validation)
• 워크플로우 (workflows)
• 자동화 (automation)
• 권한 (permissions)
• 알림 (notifications)
• 백그라운드 작업 (background jobs)
• AI 통합 (AI integrations)
• 제3자 API (third-party APIs)

각 단계는 이전 단계를 기반으로 구축됩니다.

불필요하게 코드가 다시 작성되는 일이 발생하지 않습니다.

이것이 작동하는 이유

대규모 언어 모델 (Large Language Models)은 작업 기억 용량 (working memory)이 제한적입니다.

동시에 해결하도록 요청하는 관련 없는 작업이 많아질수록, 모델은 다음과 같은 문제를 일으킬 가능성이 높아집니다:

• 문맥 (context) 상실,
• 기존 파일 덮어쓰기,
• 일관성 없는 코드 생성,
• 또는 이전 실수를 수정하려다 루프 (loop)에 빠짐.

개발 과정을 명확한 단계로 나누면 복잡성이 줄어듭니다.

한 번에 20개의 문제를 해결하는 대신, AI는 한 번에 하나의 잘 정의된 문제만을 해결합니다.

그 결과 더 깨끗한 코드, 더 적은 회귀 (regression), 그리고 훨씬 더 매끄러운 개발 경험을 얻을 수 있습니다.

흔한 프롬프팅 실수 (Common Prompting Mistakes)

다음과 같은 프롬프트는 피하세요:

"인증, 결제, 대시보드, 관리자 패널, AI 채팅, Stripe, 이메일 인증, 분석 및 배포 기능이 포함된 완전한 프로덕션 준비 완료된 SaaS를 구축해줘."

이는 한 번의 요청에 너무 많은 책임이 부여된 것입니다.

더 나은 프롬프트는 다음과 같습니다:

"제공된 아키텍처를 사용하여 대시보드 UI만 구축해줘. 인증, API 또는 데이터베이스 코드는 생성하지 마. 디렉토리 구조를 정확히 따라줘."

두 번째 프롬프트는 훨씬 더 제약 조건이 명확하며, 이는 출력 결과의 신뢰성을 높여줍니다.

기억해야 할 간단한 규칙

AI에게 설계 (design)와 구축 (build)을 동시에 요구하지 마세요.

먼저, 청사진 (blueprint)을 제공하세요.

그 다음에 코드를 작성하게 하세요.

이 작은 변화가 수 시간의 디버깅 (debugging) 시간을 절약해주고, Cursor가 반복적인 수정 루프에 빠질 확률을 줄여줄 수 있습니다.

리소스 (Resources)

• 오픈 소스 GitHub 워크플로우 (GitHub Workflow): View on GitHub
• 복사-붙여넣기 마스터 프롬프트 시퀀스 (Master Prompt Sequence): Get Full Prompt on PromptBase

PromptBase 컬렉션에는 Cursor, Replit Agent, Bolt.new 및 유사한 AI 코딩 도구들이 아키텍처 실수를 줄이면서 더 깨끗하고 유지보수가 용이한 프로젝트를 생성할 수 있도록 설계된 구조화된 프롬프트들이 포함되어 있습니다.

마치며 (Final Thoughts)

AI 보조 개발 (AI-assisted development)은 빠르게 진화하고 있지만, 소프트웨어 엔지니어링 (software engineering)의 기본 원칙은 변하지 않았습니다.

좋은 아키텍처는 여전히 좋은 코드보다 앞서야 합니다.

사양(specifications), 폴더 구조(folder structure), 그리고 구현 계획(implementation plan)이 더 나을수록, AI가 생성하는 결과물도 더 좋아질 것입니다.

Cursor가 실패하는 것은 그것이 능력이 없기 때문이 아닙니다.

대부분의 경우, 구현(implementation)을 작성하는 동시에 전체 소프트웨어 아키텍처(software architecture)를 즉흥적으로 만들어내라는 요구를 받기 때문에 실패하는 것입니다.

먼저 계획을 제시하세요.

그런 다음 구축하게 하세요.

여러분의 의견은 어떠신가요

여러분은 Cursor나 Replit 워크플로우(workflow)를 어떻게 구성하시나요?

아키텍처 문서(architecture documents), 단계별 프롬프트(phased prompts), 또는 AI가 경로를 벗어나지 않도록 유지하는 다른 시스템을 사용하시나요?

여러분의 워크플로우를 댓글로 공유해 주세요. 여러분에게 효과적이었던 방법들을 꼭 알고 싶습니다.