잘못된 프롬프팅이 당신의 Cursor 세션을 지루한 반복처럼 느끼게 하는 진짜 이유인가요?

최근 중국 AI 개발자 커뮤니티에서 이 논의가 나왔는데, 그 주장이 워낙 강력해서 영어권 독자들에게도 전달하고 싶습니다. 많은 Cursor 사용자들은 자신들의 프롬프트 탓을 하고 있지만, 실제 문제는 도구 주변에 어떠한 스캐폴딩(scaffolding) 구조도 구축하지 않았다는 점입니다.

이 주장은 도발적입니다. 하지만 반론 역시 현실적입니다. 어느 쪽도 명백히 틀렸다고 말하기 어려우며, 저는 이 두 입장의 긴장 관계 자체가 양측이 인정하는 것보다 더 중요하다고 생각합니다.

아무도 소리 내어 이야기하지 않는 문제점

여기서 논의가 시작된 시나리오를 소개합니다. 당신은 Cursor를 몇 달 동안 사용해 왔습니다. 괜찮은 프롬프트를 작성하고, 의도를 명확하게 설명합니다. 그런데도 매 세션마다 마치 AI에게 자신의 코드베이스를 처음 소개하는 것 같은 느낌을 받습니다. 코드는 구문적으로는 문제가 없지만 프로젝트의 네이밍 컨벤션을 위반합니다. 이미 제거한 종속성을 제안합니다. 건드리지 말라고 지시했던 함수를 다시 작성해 버립니다.

본능적인 반응은 프롬프트를 탓하는 것입니다. 더 많은 세부 사항을 작성하고, 더 많은 제약 조건을 추가하며, 모든 예외 케이스(edge case)를 명시적으로 적어 넣습니다.

중국 개발자 커뮤니티의 주장은 이러한 본능이 틀렸거나, 적어도 불완전하다는 것입니다. 프롬프트가 병목 지점(bottleneck)이 아닙니다. 부족한 부분은 일종의 인프라 레이어(infrastructure layer)라고 할 수 있는 것들입니다: 프로젝트 수준의 규칙, 지속적인 컨텍스트(persistent context), 노이즈 필터링, 확인 게이트(confirmation gates), 그리고 재사용 가능한 워크플로우가 그것입니다. 이것들이 없다면, 원문 게시글에서 말했듯이, 당신은 "맨몸으로 뛰는 것"과 같습니다. 즉, 누가 당신인지 또는 프로젝트가 무엇을 요구하는지에 대한 기억이 없는 도구에 프롬프트를 던지는 것입니다.

여기서 '인프라(Infrastructure)'가 실제로 의미하는 바

추상적으로만 이야기하면 이 주장은 모호함 속에 무너져 내리기 때문에, 구체적으로 설명하겠습니다.

Cursor를 위한 인프라 레이어는 대략 네 가지 범주로 나뉩니다.

세션 전반에 걸쳐 유지되는 규칙 및 컨텍스트. 기술 스택, 명명 규칙, 제외해야 할 파일 목록, 그리고 AI가 따라야 할 패턴을 지정하는 .cursorrules 파일입니다. 이것이 없으면 매 세션이 0부터 시작합니다. AI가 바보 같아서가 아니라, 실제로 지난주에 내린 결정에 대한 기록 자체가 전무하기 때문입니다.

신호 대 노이즈 제어(Signal-to-noise controls). node_modules, 빌드 아티팩트, 그리고 사용 중단된 디렉터리들을 컨텍스트 창에서 제외하는 .cursorignore 파일입니다. 데이터베이스 스키마나 API 정의와 같은 핵심 파일들은 "항상 포함(Always Included)"으로 고정하여, AI가 추론에 의존하기보다 실제 데이터 모델을 기반으로 추론하도록 합니다. 여기서의 논리는 간단합니다. 프롬프트가 아무리 잘 작성되었더라도, 컨텍스트를 깨끗하게 유지하는 것이 더 일관된 출력을 만들어냅니다.

확인 및 복구 메커니즘(Confirmation and recovery mechanics). 의존성을 설치하거나 파일을 삭제하거나 스크립트를 실행하는 명령어에 대한 자동 실행 기능을 끄는 것입니다. 에이전트 모드(Agent mode)가 무언가를 망가뜨렸을 때, 무엇이 바뀌었는지 수동으로 찾는 대신 체크포인트 복원(checkpoint restore)을 사용하는 것입니다. 또한, '질문하기 모드(Ask mode)'와 '에이전트 모드'를 개념적으로 분리하여—하나는 분석하고 다른 하나는 행동하는—같은 세션에서 혼용하지 않도록 하는 것이 중요합니다.

재사용 가능한 워크플로우 정의(Reusable workflow definitions). 자주 발생하는 작업 패턴을 Markdown 워크플로우로 .cursor/commands/에 저장함으로써, "이 모듈 리팩토링" 같은 작업을 할 때마다 동일한 지침들을 처음부터 재구성할 필요가 없게 합니다.

이 모든 것은 특별한 것이 아닙니다. 이는 개발 환경의 상태를 유지하는(stateful) 어떤 도구에도 적용할 수 있는 기본적인 위생 관리 수준에 가깝습니다.

반박 논리는 결코 단순하지 않다

여기서는 다른 측면의 의견도 공정하게 다루고 싶습니다. 왜냐하면 "그냥 프롬프트를 개선하라"는 주장은 순수한 변명(pure cope)이 아니기 때문입니다.

프롬프트 품질은 실제로 중요합니다. 아무리 좋은 인프라가 갖춰져 있어도, 모호한 프롬프트는 여전히 모호한 출력을 만들어냅니다. 원하는 바를 명확하게 표현할 수 없다면, .cursorrules을 아무리 많이 사용해도 소용이 없습니다. 인프라 계층은 당신의 의도를 증폭시킬 뿐이며, 그 자체로 대체재가 되지는 못합니다.

인프라 자체에도 유지보수 비용이 발생합니다. .cursorrules 파일은 구식이 되기 쉽습니다(go stale). 고정된 컨텍스트 파일들은 실제 코드베이스와 동기화되지 않고 벗어나게 됩니다(drift out of sync). 워크플로우 마크다운 문서들은 주석 처리된 코드처럼 쌓여갑니다. 아무도 그것들을 삭제하지 않고, 업데이트하지 않으며, 결국 AI를 안내하기보다는 적극적으로 오도하게 만듭니다. 순간적으로 완벽하게 조정된 프롬프트는 시간이 지남에 따라 제대로 유지보수되지 않은 규칙 파일보다 더 나은 성능을 보일 수 있습니다.

또한 소규모 프로젝트에서 작업하는 1인 개발자에게는 이러한 스캐폴딩(scaffolding) 구축의 오버헤드가 실제 이점보다 클 수도 있습니다. 만약 프로젝트가 세 개의 파일을 가지고 있고 당신이 유일한 기여자라면, AI는 아마도 당신의 명명 규칙에 대한 공식적인 사양을 필요로 하지 않을 것입니다.

논쟁이 실제로 존재하는 영역

따라서 진짜 질문은 '프롬프트인가 인프라인가'가 아닙니다. 바로 **어떤 규모와 팀 크기에서 인프라 투자가 누적되는 프롬프트 개선보다 더 빨리 회수되는가?**입니다.

이에 대한 정해진 답은 없습니다. 저는 Cursor 설정에 막대한 투자를 한 팀과 동등한 시간을 프롬프트 엔지니어링(prompt engineering)에 투자한 팀을 비교하는 통제된 연구를 본 적이 없습니다. 중국 개발자 커뮤니티의 일화적 증거는 몇 주 이상 다중 파일 프로젝트에서 작업하는 사람이라면 누구나 인프라 접근 방식이 상당히 빠르게 승리한다는 것을 시사합니다. 하지만 그것은 데이터가 아닌 일화입니다.

제 의견은 이렇습니다: 인프라 논리는 이미 '도구 평가' 단계를 지나 자신의 워크플로우 일부로 이를 확신한 대다수의 개발자에게는 옳습니다. 제가 그렇게 생각하는 이유는 다음과 같습니다.

프롬프트 개선은 세션별(session-local)입니다. 오늘 더 나은 프롬프트를 작성해도, 다음 주 화요일에 재구성하는 것을 기억하지 않는 한 도움이 되지 않습니다. 인프라 개선은 세션 지속적(session-persistent)입니다. 좋은 .cursorrules 파일을 한 번 작성하면 모든 미래 세션에 걸쳐 복리처럼 쌓입니다. 투자된 시간에 대한 비대칭적인 수익률은 이 도구를 정기적으로 사용하는 누구에게나 인프라 쪽으로 기울어집니다.

“유지보수 비용”에 대한 반론은 현실적이지만 과장된 측면이 있습니다. 규칙 파일(rules file)을 최신 상태로 유지하는 것은 주요 아키텍처 결정 이후 10분 정도면 충분합니다. 이는 규칙 파일이 강제했을 컨벤션을 위반한 AI 출력을 수정하는 데 소비할 시간보다 적은 양입니다.

프롬프트 품질에 대한 주장 역시 인프라 구축 주장이 갖지 못한 한계점이 있습니다. 프롬프트를 아무리 정교하게 작성하더라도 결국 명세서(spec document)를 작성하는 수준에 도달하기 때문에, 그 시점에서는 어차피 규칙 파일로 형식화하는 것이 나을 수밖에 없습니다.

실질적인 시사점

만약 Cursor 사용 6개월 차인데도 매번 세션이 처음부터 시작되는 느낌이라면, 진정한 진단 질문은 “내가 프롬프트를 충분히 잘 작성하고 있는가”가 아니라 “이 도구가 내 프로젝트에 대해 세션 간 지속적으로 알고 있는 것이 무엇인가?”여야 합니다.

대부분의 개발자에게 답은 거의 '아무것도 아님'입니다. AI는 5분 전에 당신이 말한 내용과 현재 컨텍스트(context)에 포함된 파일들로부터 추론할 수 있는 정보만을 알 뿐입니다. 이는 실제 코드베이스에서 일관된 출력을 내기에는 매우 취약한 기반입니다.

인프라 계층을 구축하는 것은 단순히 파워 유저의 움직임이 아닙니다. 이는 .gitignore나 린팅 설정(linting config)을 구성하는 것과 유사하며, 아마도 더 일찍 했어야 할 기본적인 프로젝트 위생 관리입니다.

원래 커뮤니티 게시물은 이를 “당신은 Cursor의 10%만 사용하고 있다”고 프레임화합니다. 이 틀은 마케팅에 가깝다고 생각하며 저는 이를 배제할 것입니다. 더 유용한 관점은 다음과 같습니다: 당신은 Cursor를 상태가 없는(stateless) 채팅 도구로 사용하고 있지만, 이 도구는 상태가 있는(stateful) 컨텍스트와 함께 작동하도록 설계되었습니다. 이 두 가지 사용 패턴 사이의 간극이야말로 대부분의 좌절감이 존재하는 곳입니다.

제가 정말 알고 싶은 질문 하나

제가 진정으로 알지 못하는 것은 다음과 같습니다: 프롬프트 엔지니어링과 Cursor 인프라 설정을 모두 심도 있게 투자한 개발자들에게, 6개월 동안 출력 품질에 더 지속 가능한 개선을 가져온 것은 어느 쪽이며 — 그 답이 혼자 작업할 때와 팀 단위로 작업할 때 달라지는가?

이와 관련하여 실제로 '전(前)'과 '후(後)'의 경험이 있으시다면, 저는 또 다른 의견보다는 그런 실제 사례를 듣고 싶습니다.