처음에는 커서 AI가 진짜 편합니다. 자동완성이 빠르고, 수정도 알아서 해주고, 심지어 파일도 왔다 갔다 하니까요.
그런데 며칠 지나면 이상한 지점에서 답답해져요. 코드가 “되긴” 하는데 왜 이렇게 바뀌었는지 모르겠고, 한 번 꼬이면 어디서부터 되돌려야 할지 감이 안 잡힙니다. 이 글은 그 지점을 줄이는 커서 AI 사용법을 “기능 설명”이 아니라 실무 흐름 중심으로 정리한 내용입니다.
Table of Contents
커서 AI 사용법, 실무에서 덜 흔들리는 흐름
| 자동완성은 “한 번에 완성”이 아니라 “방향 잡기”로 쓰는 게 낫습니다
처음엔 자동완성으로 통째로 뽑아내고 싶죠. 그런데 실무 코드에서 통째 자동완성은 딱 한 번만 성공하고, 그 다음부터는 위험해집니다. 이유는 간단해요. 커서는 “지금 열려 있는 컨텍스트”를 바탕으로 추측하는데, 우리가 원하는 건 대부분 그보다 넓은 맥락이거든요.
| 제가 제일 자주 쓰는 시작 문장
자동완성을 아예 막는 게 아니라, 커서가 “어디까지 바꿔도 되는지”를 먼저 좁혀주면 안정감이 확 올라갑니다.
이 파일에서는 동작은 유지하고, 가독성만 개선해줘.
특히 함수 이름/변수 이름만 정리하고 로직은 바꾸지 마.이렇게 시작하면 결과가 덜 튀고, 나중에 리뷰할 때도 “뭘 한 건지”가 보입니다. 반대로 아무 말 없이 자동완성을 계속 받다 보면, 내가 지금 코드를 짜는 건지 결과물을 구경하는 건지 애매해져요.
| 수정 요청은 “원인-범위-검증”을 같이 주면 품질이 달라집니다
커서에서 가장 많이 하는 게 “이거 고쳐줘”인데, 여기서 결과가 갈립니다. 그냥 고치라고 하면 커서는 좋은 의도로 과감해져요. 파일을 쪼개고, 이름을 바꾸고, 유틸을 만들고… 그러다 보면 정작 내가 원했던 건 한 줄 버그 수정인데 PR이 리팩터링급이 됩니다.
그래서 저는 요청을 세 덩어리로 말합니다. 문제(원인) → 바꿀 범위 → 확인할 기준. 말투는 딱딱해질 필요 없고, 문장만 세 덩어리로 나누면 돼요.
증상: 로그인 후 간헐적으로 401이 떠.
범위: auth middleware 로직만 수정하고, API 스펙은 건드리지 마.
검증: 동일 계정으로 10번 연속 호출했을 때 401이 재현되지 않게.이 패턴으로 말해두면, 커서가 수정한 다음에 “이게 맞나?”를 내 머리로 다시 풀어헤치는 시간이 줄어듭니다. 결국 시간은 여기서 벌어요.
| 프로젝트 규칙은 많이 적기보다, 자주 흔들리는 것만 고정하세요
커서가 잘못하는 건 대개 “몰라서”가 아니라 “우리가 기준을 안 줘서”입니다. 그 기준을 한 번에 다 문서화하려고 하면, 그 문서부터 관리가 안 됩니다. 저는 아래 3가지만 고정해두는 편이에요.
1) 파일 추가/삭제는 반드시 이유를 적기
2) 테스트가 있으면 수정 후 실행 결과(또는 실패 이유)까지 남기기
3) 변경 범위가 커지면 먼저 제안만 하고, 실행은 확인 후 하기이 정도만 잡아도 “갑자기 폴더가 바뀌어 있는” 사고가 많이 줄어듭니다. 규칙은 길수록 좋은 게 아니라, 내가 자주 화나는 지점을 먼저 막는 게 이득입니다.
| 실무에서 제일 많이 꼬이는 순간: “잘 됐는데 왜 불안하지?”
커서가 만든 코드가 돌아가면, 사람 마음이 더 불안해질 때가 있어요. 특히 팀 코드베이스에서요. “이거 내가 설명할 수 있나?”가 기준이 됩니다.
저는 그때 두 가지를 바로 확인합니다. 첫째, 바뀐 파일이 한 군데인지. 둘째, 바뀐 이유를 한 문장으로 말할 수 있는지. 둘 중 하나라도 애매하면, 커서에게 다시 부탁합니다.
지금 변경 내용을 한 문단으로 요약해줘.
그리고 왜 그렇게 바꿨는지, 대안은 뭐가 있었는지 같이 적어줘.이 요청은 “요약”을 위한 게 아니라, 설명 가능성을 위한 겁니다. 설명이 되면 리뷰도 되고, 다음 작업도 이어져요.
| 커서가 갑자기 과감해질 때, 멈추는 말 한 줄이 있습니다
가끔 커서는 의욕이 넘칩니다. “이왕 하는 김에”라는 느낌으로 구조를 바꿔버리죠. 그게 항상 나쁜 건 아닌데, 일정이 촉박할 때는 대형 사고로 이어질 수 있습니다. 기능은 그대로인데 파일이 갈라지고, 이름이 바뀌고, import가 흔들리면 그날은 그냥 끝이에요.
저는 그럴 때 딱 한 줄을 먼저 던집니다. 바꾸기 전에 변경안을 먼저 보여달라는 말이요. 이 한 줄로 리팩터링 폭주를 많이 막습니다.
바로 수정하지 말고, 바뀌는 파일/함수 목록과 변경 이유를 먼저 적어줘.
그리고 내가 OK 하면 그때 실제 코드를 수정해줘.이렇게 요청하면 커서가 “계획 단계”를 거치게 됩니다. 결과물이 마음에 들면 진행시키고, 불안하면 범위를 다시 줄이면 돼요. 무엇보다 내 머리가 덜 지칩니다.
| 팀 작업에서는 결과보다 “설명”이 먼저라서, 프롬프트도 달라집니다
혼자 쓰는 프로젝트에서는 빨리 돌아가면 장땡인데, 팀에서는 이야기가 달라요. 코드 리뷰에서 제일 자주 나오는 질문은 결국 두 가지입니다. “왜 바꿨지?” “다른 방법은 없었나?” 커서가 만든 코드가든 내가 만든 코드든, 이 질문에 답을 못 하면 다음 작업이 막힙니다.
그래서 팀 코드에서는 커서에게 결과물을 받기 전에, PR 설명부터 같이 쓰게 합니다. 코드보다 글이 먼저 나오면, 변경의 방향이 스스로 정돈되거든요.
PR 설명을 먼저 써줘.
- 문제(증상)
- 원인 추정
- 변경 요약(핵심 3줄)
- 영향 범위(어떤 기능에 영향?)
- 테스트/검증 방법
그 다음에 코드를 수정해줘.이 방식은 신기하게도 코드를 더 깔끔하게 만듭니다. 설명을 먼저 쓰면, 불필요한 변경이 스스로 줄어들어요. 결국 커서 AI 사용법의 핵심은 “바로 코딩”이 아니라 “내가 원하는 결과를 더 또렷하게 말하는 것”에 가깝습니다.
| 마지막으로: 잘 쓰는 날과 못 쓰는 날의 차이는 대개 “내 컨디션”입니다
이건 좀 생활 얘기인데요. 커서를 잘 쓰는 날은 보통 내가 멀쩡한 날이고, 못 쓰는 날은 내가 이미 지친 날입니다. 피곤하면 요청 문장이 짧아지고, 짧아지면 커서는 과감해지고, 과감해지면 내가 더 피곤해지는 루프가 돌죠.
그래서 저는 피곤한 날일수록 “수정 범위 좁히기”부터 합니다. 커서에게 일을 시키기 전에, 내가 먼저 오늘 바꿔야 할 것 한 줄만 정해두는 거죠. 그 한 줄이 있으면, 커서가 얼마나 똑똑하든 그날 작업은 덜 흔들립니다.
| 같이 보면 좋은 글 (같은 도구라도 결과가 달라집니다)
커서 AI를 좀 더 깊게 쓰고 싶다면 아래 글도 같이 보면 흐름이 이어집니다.
GitHub Copilot vs Cursor 비교 (2026): 가격·요청 한도 기준으로 고르는 방법
Cursor background agent 사용법: 원격 에이전트를 언제 써야 편한가
마지막으로 한 마디만요. 커서 AI를 잘 쓰는 사람들은 기능을 많이 아는 게 아니라, “내 작업의 리듬”을 먼저 알고 있습니다. 내 리듬을 지키면서 도구를 얹으면, 진짜로 하루가 가벼워집니다.