Cursor가 LLM의 한계를 극복하는 방법
바이브 코더의 프로젝트 진행 과정을 크게 3단계로 쪼갤 수 있습니다.
- 시작 단계: 기획만 하고 아직 구현을 시작하지 않았거나, 막 시작했음
- 마무리 단계: 출시 전 마지막 5-10%를 채워나가고 있음
- 유지보수 단계: 출시 후 기능을 추가하거나 개선하고, 버그를 수정하고 있음
1단계는 웬만한 코딩 에이전트들이 대부분 놀라울 정도로 잘 만들어줍니다. 만들려는 프로그램이 대략 이런 조건에 해당한다면 더욱 그렇죠.
- 모든 방문자에게 동일한 서비스를 제공함(사용자 로그인이 필요하지 않음)
- 사용자 인터랙션이 간단하며 명시적임(내 클릭 없이 화면이 변하지 않음)
- 외부 프로그램과 연동하여 데이터를 가져오거나 내보내지 않음(캘린더의 일정 정보를 불러오거나, SNS에 글을 게시해주거나 하지 않음)
이런 프로그램은 마무리 단계까지도 AI가 쉽게 해줄 수 있습니다. 프롬프트만 잘 짰다면 첫 턴에 완성될지도 몰라요. 이 때는 v0나 Lovable 같은 프로토타이핑 서비스를 쓰는 게 좀 더 유리합니다. 바로 화면이 보이고, 배포되어 누구나 쓸 수 있게 나오니까요. (굳이 별도 서비스로 갈 필요 없이 Gemini Canvas 수준으로도 충분할 수 있습니다)
그러나 만들려는 프로그램이 더 복잡하거나, 위와 같이 만든 프로그램에 기능을 추가할 때는 AI의 결과물에 만족하지 못할 가능성이 높습니다. 이는 LLM이 가지는 3가지 근본적 문제 때문입니다.
1) 환각 현상
바이브 코딩에서는 프로그램 내에서 사용하는 라이브러리들의 버전 때문에 골치아픈 일이 많습니다. 라이브러리들의 버전이 올라가서 사용법이 바뀌었는데, LLM이 가지고 있는 데이터는 이전 버전에 대한 것이어서 의도한 대로 동작하지 않는 거죠. 코드의 일부는 최신 버전, 일부는 예전 버전을 참조한 상태가 되는 일도 적지 않습니다.
LLM이 발전하고, 환각을 줄이기 위한 다양한 기법이 동원되고 있지만 완벽히 사라지게 할 순 없어요. 이상하게 작업해놓고 한껏 당당한 AI의 모습은 계속해서 보게 될 겁니다.
2) 부족한 컨텍스트 윈도우
코딩에 자주 쓰이는 Claude의 모델들은 200k 토큰을 입력받을 수 있고, 이는 대략 영어책 500페이지 분량 정도로 결코 적지 않습니다. 역시 코딩 잘 하는 걸로 소문난 Gemini 2.5 Pro는 1048k 토큰으로 여기의 다섯 배나 되죠. 하지만 본격적으로 프로그램을 만들기 시작하면 이러한 토큰 양으로도 충분하지 않을 수 있습니다.
게다가 Cursor에 채팅을 할때마다 내 코드를 전부 붙여넣을 수도 없고, 그렇게 집어넣는다 한들 항상 정확하게 코드를 참조해서 응답하리라는 보장도 없습니다. 컨텍스트에 들어간 내용은 모두 벡터화되어, 정확한 단어보다는 의미 위주로 남도록 LLM이 처리하기 때문입니다.
3) 비일관적인 결과물
1과 2 때문에, AI가 작성한 코드는 일관성을 지키지 않는 일이 많습니다. 좀 비일관적이면 어때? 라고 생각하실 수도 있겠지만, 이게 심해지면 이런 문제를 겪게 돼요.
- 새 기능을 추가했더니 기존에 잘 동작하던 기능이 망가짐
- 새 페이지의 생김새가 기존 페이지와 너무 다름
- 이 버그를 고치면서 저 버그가 추가됨
그래서 프로그램의 마지막 5-10%를 채우지 못하고, 프로덕션 레벨로 완성하지 못해 공개하지 못하는 사람도 많습니다. 출시한 앱을 더이상 업데이트하지 못하기도 하고요.
이런 분들의 도움 요청을 받아 코드를 보면 그렇게 엉망일 수 없어요. 처음부터 다시 짜는 게 낫겠다는 생각이 들 정도입니다.
Cursor가 한계를 극복하는 법
모든 문제에는 해결책이 따라옵니다. Cursor는 공식 문서에서 컨텍스트를 적절하게 제공하는 다양한 방법을 소개하고 있어요. 위 한계들을 뛰어넘게 돕는, Cursor가 일을 더 똑똑하게 할 수 있도록 돕는 도구들이죠. 이런 도구들을 크게 3가지로 분류할 수 있습니다.
- 상황별, 단계별로 쓰는 지침들
- 더 편하고 정확한 개발을 돕는 MCP
- 그 외 제품 개발을 돕는 도구들
이러한 도구들을 잘 활용하면 비개발자 바이브 코더가 가장 곤란해하는 마무리 단계를 뛰어넘을 가능성이 높아집니다. 특히 이 마무리 단계는, 대체재가 있는 시작 단계(프로토타이핑 도구들)나 유지보수 단계(OpenAI Codex, Google Jules)와 달리 Cursor 같은 IDE 외에는 특별한 대체재가 아직 없다고도 생각해요.
그렇다고 커서가 1단계와 3단계를 못하는 것도 전혀 아니기 때문에, 비개발자분들도 커서를 잘 배워두면 본인 제품을 출시하고 유지보수하는 데 아주 유용하게 써먹을 수 있습니다.
그래서 뭘 쓰면 되는데?
그래서 어떤 지침과 MCP, 도구들을 쓰면 되는가? 는... 바이브 코딩 강의를 수강하신 분들께 공개하고 있습니다 ㅎㅎ
조금 더 적어보자면, 저는 거대하고 복잡한 프로젝트에서 커서를 효과적으로 쓰려면 크게 여섯 종류의 지침이 필요하다고 생각합니다.
- 글로벌 지침 (User Rules)
- 프로젝트 단위 지침 (Project Rules)
- 폴더 단위 지침 (폴더 내의 마크다운 파일)
- 파일 단위 지침 (파일 최상단의 주석)
- 상황에 맞는 워크플로우 지침 (필요할 때만 쓰는 Project Rules 또는 Custom Mode)
- 채팅에서의 프롬프트
제가 추천하는 지침 조합, 고급 사용자를 위한 팁 모음 (툴에 대한 이해, 다양한 모드 활용, MCP와 익스텐션 등) 등에 대해 정리한 글을 강의 수강자 분들께 정성들여 연재하고 있어요. 관심 있으신 분들은 수강신청 해보세요!
패스트캠퍼스
글로벌 지침 예제
글로벌 지침은 내가 어떤 프로젝트를 하든 적용할 만한 룰을 넣어두는 곳이며, 프로젝트 룰과 달리 언제나 컨텍스트에 포함되게 됩니다. 따라서 너무 길게 쓰는 건 좋지 않습니다.
아래는 Awesome CursorRules의 Clean Code 규칙, 그리고 Anthropic이 Claude 4를 출시하면서 공개한 프롬프트 엔지니어링 모범 사례에서 가져와서 조합한 제 글로벌 지침입니다. 프리미엄 구독자 분들께 공개합니다.