Cursor Composer에서 훨씬 더 나은 결과를 얻기 시작한 방법

Composer가 진짜 개쩌는 도구인 건 맞는데, 코드를 건드리기 전에 제대로 계획하고 생각하게끔 강제로 시켜야만 그 성능이 제대로 나옴.

나한테 가장 큰 변화를 준 건 GPT-5.5로 나만의 커스텀 프롬프트 스킬을 만든 거임. 내가 프롬프트를 어떤 식으로 짜길 원하는지 정확히 알고 있는 스킬을 만들었거든. 좋은 프롬프트에 뭐가 들어가야 하는지, 얼마나 상세해야 하는지, Composer가 뭘 쓰기 전에 뭘 고민해야 하는지, 그리고 어떤 후속 질문을 던져야 하는지까지 다 포함시켰음.

이 스킬은 대충 던진 아이디어를 훨씬 그럴싸한 프롬프트로 바꿔줌. 단순히 내 말을 다시 쓰는 게 아님. 목표가 뭔지, 프로젝트 맥락은 어떤지, 발생할 수 있는 예외 상황은 뭔지, 빠진 디테일은 없는지, 구현할 때 위험 요소는 뭔지, 그리고 내 아이디어가 기존 프로젝트랑 진짜 잘 맞는지까지 다 고민하게 만듦.
그리고 .cursor 폴더 안에 Cursor rules도 추가했음. 이 규칙들 덕분에 Composer가 프로젝트 설명, 아키텍처, 코딩 스타일, 컨벤션, 그리고 내가 뭘 계획하거나 구현할 때 Composer가 어떻게 행동해야 하는지 같은 프로젝트 맥락을 더 잘 파악하게 됨.

지금 내 작업 방식은 이럼:

• /prombt를 입력함
• 뭘 만들거나, 바꾸거나, 고치고 싶은지 대충 적음
• 내 커스텀 프롬프트 스킬이 그걸 상세하고 구조화된 프롬프트로 바꿔줌
• 그 프롬프트를 복사해서 Composer 플래닝 모드에 붙여넣음
• Composer가 제대로 된 계획을 짜줌
• 내가 계획을 검토함
• 그제야 Composer한테 구현하라고 시킴

따로 리뷰용 스킬도 하나 만들었음. 이건 절대 코드를 수정 안 함. 구현이 끝난 다음에 결과물을 비판적으로 뜯어보기만 함. 원래 목표가 뭐였는지, 실제로 뭐가 바뀌었는지, 결과물이 내가 원하던 거랑 맞는지, 아직 손볼 데는 없는지, 문제점이나 허점은 없는지 확인하는 용도임.

이 리뷰 단계 덕분에 결과물을 한 번 더 생각할 수 있게 됨. 리뷰 스킬도 Cursor rules랑 프로젝트 맥락, 그리고 처음에 짠 상세 프롬프트를 다 알고 있어서 피드백이 뻔한 소리가 아님. 진짜 우리 프로젝트랑 내가 뭘 하려던 건지에 딱 맞춰서 피드백이 나옴.

이게 진짜 엄청난 차이를 만들었음. /prombt로 뽑은 프롬프트만으로도 이미 계획서로 쓰기 충분할 때가 많지만, 그걸 Composer 플래닝 모드랑 같이 쓰니까 결과물이 훨씬 믿을만해짐. 이런 워크플로우 쓰기 전에는 Composer가 맨날 성급하게 코딩부터 하다가 중요한 디테일 놓치거나, 기술적으로는 돌아가는데 프로젝트랑은 전혀 안 맞는 코드를 짜놓곤 했거든.

사람들이 제일 많이 하는 실수가 Composer한테 문제부터 고민하게 안 시키고 바로 코드로 돌진하게 놔두는 거임. "이거 어떻게 구현하지?"만 물어볼 게 아니라, "이게 진짜 말이 되는 소린가?", "더 나은 해결책은 없나?", "프로젝트 아키텍처에 맞는 건가?", "숨겨진 예외 상황은 없나?", "사용자 아이디어 자체가 잘못된 전제를 깔고 있는 건 아닌가?" 같은 질문을 던지게 해야 함.

마지막 팁 하나 주자면, Composer는 사용 비용이 워낙 싸니까 이런 추가 단계들을 거치는 게 무조건 이득임. 맥락 더 넣고, 계획 더 짜고, 비판적인 리뷰 한 번 더 돌리는 게 결과물 퀄리티를 훨씬 높여줌. 특히 API 기반으로 돈 나가는 거 생각하면 이런 단계들이 금방 비싸질 수 있는데, 여기선 그런 걱정 없으니까 맘껏 써먹으셈.