도구 리뷰 ·
Cursor의 답이 엇나갈 때 관련 파일부터 좁혀 보여주는 법
먼저 답부터
Cursor의 답이 엇나갈 때는 프롬프트를 무작정 길게 쓰기보다 목표와 현재 상태를 나누고 관련 파일이나 코드만 정확히 보여주는 것이 먼저입니다. 반복하는 기준은 프로젝트 규칙에 짧게 남기고, 한 대화에는 한 작업만 두며 변경 파일과 테스트 결과를 직접 확인해야 합니다.
Cursor에 “로그인 화면을 고쳐줘”라고 썼는데 전혀 다른 파일까지 바뀌는 경우가 있습니다. 도구가 내 프로젝트를 하나도 모르는 것은 아니지만, 내가 말하지 않은 목적과 화면 상태까지 정확히 짐작할 수는 없습니다. 이때 요청을 더 화려하게 쓰기보다 어떤 정보를 보여줬는지부터 확인하는 편이 낫습니다.
Cursor 문서에서는 모델에 제공되는 정보를 컨텍스트라고 설명합니다. 쉽게 말해 요리사에게 메뉴 이름뿐 아니라 지금 냉장고에 있는 재료와 완성 사진을 함께 보여주는 것입니다. 목표는 “무엇을 원한다”는 정보이고, 현재 파일과 오류 메시지는 “지금 무엇이 있다”는 정보입니다.
목표와 현재 상태를 두 덩어리로 나눈다
“버튼이 안 돼요”만으로는 어떤 버튼인지, 눌렀을 때 무엇이 일어나야 하는지 알기 어렵습니다. 먼저 사용자가 있는 화면과 행동, 기대 결과를 적습니다. 그 다음 실제로 보이는 오류와 관련 파일을 붙입니다.
목표: 로그인 버튼을 누르면 이메일 입력 오류가 화면 아래에 보인다.
현재: 빈 값으로 눌러도 아무 문구가 보이지 않는다.
관련 화면: src/pages/Login.tsx
바꾸지 말 것: 회원 데이터와 배포 설정
완료 확인: 빈 값은 전송되지 않고 정상 이메일은 기존처럼 전송된다.
이 정도면 모델이 수정할 범위와 유지할 동작을 함께 볼 수 있습니다. 기술 이름을 모르면 추측해서 프레임워크를 지정하지 말고, 먼저 프로젝트가 어떤 기술을 쓰는지 읽고 설명해 달라고 요청합니다.
관련 파일만 정확히 보여준다
Cursor는 열려 있는 파일과 코드베이스에서 관련 정보를 찾을 수 있고, 사용자는 파일이나 폴더, 코드 등을 직접 컨텍스트로 지정할 수 있습니다. 화면 한 곳을 고치는데 프로젝트 전체를 한꺼번에 보여주면 오래된 파일이나 비슷한 이름의 화면이 섞일 수 있습니다.
먼저 브라우저 주소와 화면 제목으로 해당 페이지 파일을 찾습니다. 버튼이 별도 컴포넌트에 있다면 그 파일을 추가하고, 오류가 서버에서 온다면 요청을 보내는 파일과 실제 오류 문장을 더합니다. 비밀번호와 API 키, 고객 자료는 컨텍스트에 넣지 않습니다.
- 화면 모양 수정은 해당 페이지와 사용 중인 컴포넌트를 보여줍니다.
- 오류 수정은 오류 전문과 재현 순서, 관련 파일을 보여줍니다.
- 데이터 저장 수정은 입력 화면과 요청 함수, 데이터 형식을 보여줍니다.
- 스타일 수정은 현재 화면 캡처와 목표 화면의 차이를 말합니다.
- 문서를 참고해야 하면 현재 공식 문서 링크를 함께 줍니다.
반복하는 기준만 프로젝트 규칙에 둔다
매번 “한국어로 설명해줘”, “기존 디자인을 유지해줘”, “테스트를 실행해줘”라고 쓰게 된다면 규칙 파일을 검토할 수 있습니다. Cursor의 현재 문서에서는 프로젝트 규칙을 '.cursor/rules' 폴더 안에 두고 코드베이스와 함께 관리할 수 있다고 안내합니다. 예전에 쓰이던 '.cursorrules'는 지원되지만 오래된 방식으로 표시되어 있습니다.
규칙에는 모든 상황을 설명하는 긴 글보다 반복해서 지켜야 할 기준을 짧게 씁니다. 특정 폴더에만 필요한 규칙은 그 범위에 맞춰 나눕니다. “좋은 코드를 작성한다” 같은 말보다 “버튼 문구는 한국어로 쓰고, 폼 변경에는 빈 값 테스트를 추가한다”처럼 확인 가능한 행동이 낫습니다.
규칙이 있다고 결과가 자동으로 맞아지는 것은 아닙니다. 규칙이 적용되는 범위와 유형을 확인하고, 실제 대화에서 참조됐는지 봅니다. 서로 충돌하는 규칙을 여러 곳에 복사하면 모델도 우선순위를 판단하기 어렵습니다.
한 대화에는 한 작업만 남긴다
같은 채팅에서 로그인 오류를 고치다가 가격표를 만들고 다시 로그인으로 돌아오면 이전 요청이 현재 작업과 섞일 수 있습니다. Cursor 문서도 대화 기록이 컨텍스트에 포함되므로 목적이 바뀌면 새 대화를 시작해 관련 기록만 유지하는 방법을 제안합니다.
새 대화를 열기 전에 현재 변경이 저장됐는지 확인합니다. 바뀐 파일 목록, 아직 실패하는 테스트, 다음에 할 일을 짧게 기록한 뒤 넘어갑니다. 새 대화라고 해서 프로젝트 파일까지 사라지는 것은 아니지만, 앞 대화에서만 말한 결정은 다시 알려줘야 할 수 있습니다.
작은 변경 뒤에 차이를 먼저 읽는다
Agent가 여러 파일을 수정할 수 있어도 한 번에 승인할 필요는 없습니다. 변경된 파일과 추가·삭제된 줄을 보고 요청 범위 안인지 확인합니다. 패키지 설치, 설정 파일, 데이터베이스 변경이 생겼다면 왜 필요한지 묻고 이해되지 않으면 적용을 멈춥니다.
다음 질문을 결과 확인에 그대로 쓸 수 있습니다.
- 어떤 파일을 왜 바꿨는지 한 줄씩 설명해줘.
- 요청하지 않은 동작이 달라질 가능성을 알려줘.
- 실행한 테스트 명령과 실제 결과를 보여줘.
- 테스트하지 못한 부분을 따로 말해줘.
- 원래 상태로 되돌릴 파일을 알려줘.
AI의 자기 설명만 읽고 끝내지 말고 직접 변경 화면과 테스트 결과를 봅니다. 오류가 생겼다면 현재 오류 문장을 그대로 다시 제공하고, 성공했다고 가정하지 않도록 합니다.
자동 실행은 권한에 맞춰 좁게 쓴다
Cursor Agent는 터미널 명령을 실행하고 파일을 바꿀 수 있습니다. 처음에는 명령과 변경을 확인한 뒤 실행하는 설정을 사용합니다. 삭제, 강제 덮어쓰기, 배포, 결제나 외부 메시지처럼 되돌리기 어려운 작업은 대상과 결과를 직접 확인한 뒤 별도로 승인합니다.
프로젝트에 '.env' 같은 비밀 설정 파일이 있다면 대화에 내용을 복사하지 않습니다. Cursor의 개인정보 설정과 코드 인덱싱 설명도 현재 정책이 바뀔 수 있으므로 회사 자료나 고객 코드를 연결하기 전에 공식 문서와 조직 규정을 확인합니다. “개인정보 보호 모드”라는 이름만 보고 모든 저장과 전송 방식을 추정하지 않습니다.
오류 하나로 작은 연습을 한다
버튼 문구 오타처럼 위험이 낮은 문제 하나를 고릅니다. 새 대화에서 관련 페이지 파일 하나를 지정하고 현재 문구, 원하는 문구, 바꾸지 말 것을 세 줄로 적습니다. Cursor가 제안한 변경을 적용하기 전에 파일 목록을 확인합니다.
수정 뒤 개발 화면에서 데스크톱과 휴대전화 크기를 모두 봅니다. 테스트가 있다면 실행하고, 없다면 어떤 행동을 직접 확인했는지 기록합니다. 마지막으로 변경 차이에 오타 수정 외의 내용이 없는지 봅니다. 이 작은 과정을 익히면 더 긴 프롬프트를 외우지 않아도 컨텍스트를 좁히고 결과를 검증하는 습관을 만들 수 있습니다.
확인한 자료
- Working with Context — Cursor Docs
- Rules — Cursor Docs
- Privacy and Security — Cursor Docs