AI 코딩도구

Cursor로 만든 프로젝트 리팩토링 후기

wins007 2025. 12. 23. 23:41

아래는 티스토리 블로그에 바로 올릴 수 있는 글
👉 Cursor로 만든 프로젝트를 다시 뜯어고친 실제 리팩토링 후기를
경험담 중심 + 실무 정리형으로 응용해 쓴 버전입니다.


Cursor로 만든 프로젝트 리팩토링 후기

“딸깍으로 만든 코드, 결국 사람이 정리한다”

한 줄 요약
👉 Cursor로 빠르게 만든 프로젝트, 리팩토링 없이는 유지보수가 힘들다.


0. 왜 리팩토링을 하게 됐을까?

Cursor로 웹사이트를 하나 만들어봤다.
기획 → 프론트 → 백엔드까지 3시간 반.

솔직히 말하면,

“와… 이건 혁명이다”

라는 생각이 먼저 들었다.

하지만 하루 정도 지나서 코드를 다시 열어보니
조금 다른 감정이 들었다.

  • 파일 구조가 뒤죽박죽
  • 컴포넌트 책임이 불명확
  • 상태 관리가 여기저기 흩어짐

👉 “지금은 돌아가지만, 고치기는 힘든 코드” 상태였다.

그래서 결론은 하나.
리팩토링이 필요했다.


1. Cursor가 처음 만들어준 코드의 특징

✅ 장점부터 말하자면

  • 기능 구현 속도는 미쳤다
  • API, UI, DB 연동까지 한 번에 생성
  • 작은 프로젝트엔 충분히 쓸 만함

❌ 하지만 구조적으로는…

Cursor는 기본적으로

“일단 돌아가게 만들자”

에 최적화되어 있다.

그래서 이런 문제가 생겼다.

  • page.tsx에 로직 + UI + API 호출이 전부 있음
  • 공통 컴포넌트 분리가 거의 없음
  • 타입 정의가 느슨함
  • 상태 흐름이 명확하지 않음

👉 프로토타입용 코드에 가까웠다.


2. 리팩토링 목표 설정

무작정 고치기 시작하면 더 엉망이 된다.
그래서 먼저 기준을 잡았다.

리팩토링 목표

  1. 구조 정리
  2. 역할 분리
  3. 읽기 쉬운 코드
  4. 다시 Cursor에게 맡길 수 있는 상태 만들기

핵심은
👉 사람이 이해하기 쉬운 구조였다.


3. Cursor를 리팩토링에 쓰는 방법

아이러니하지만,
리팩토링도 Cursor에게 맡겼다.

사용한 방식

1️⃣ 파일 단위로 나눠서 요청
2️⃣ 한 번에 “전체 리팩토링”은 금지
3️⃣ 항상 “왜 이렇게 바꿨는지 설명” 요청

예시 프롬프트:

이 파일의 책임을 분리해서
- UI 컴포넌트
- 비즈니스 로직
- API 호출
로 나눠줘.
구조 변경 이유도 설명해줘.

👉 이 방식이 꽤 효과적이었다.


4. 실제로 바꾼 것들

① 폴더 구조 정리

Before

/app
  page.tsx
  admin.tsx
  firebase.ts

After

/app
  /pages
  /components
  /hooks
  /services
  /types

Cursor에게
“프론트엔드 기준으로 일반적인 구조로 바꿔줘”
라고 요청하니 무난하게 정리해줬다.


② 컴포넌트 분리

  • UI 컴포넌트
  • 로직 포함 컴포넌트
  • 상태 관리 훅

을 명확히 나눴다.

이 작업은 AI + 사람 협업이 제일 좋았다.
AI가 초안을 만들고,
사람이 “이건 여기로 가는 게 맞다” 하고 조정하는 방식.


③ 타입 & 데이터 구조 정리

Cursor가 만든 초기 타입은 대체로 느슨했다.

그래서:

  • any 제거
  • 명확한 인터페이스 정의
  • API 응답 타입 분리

같은 작업을 진행했다.

이 단계에서는
Claude 모델이 가장 안정적이었다.


5. 리팩토링 후 느낀 Cursor의 진짜 강점

리팩토링을 하면서 느낀 점은 이거였다.

Cursor는 ‘만드는 도구’보다
‘고쳐주는 도구’로 더 강하다.

특히:

  • 중복 코드 제거
  • 함수 역할 설명
  • 구조 개선 제안

은 사람이 혼자 하는 것보다 훨씬 빠르다.


6. Cursor 리팩토링의 한계

물론 한계도 있다.

❌ 한 번에 너무 많이 고치려고 함

  • 전체 리팩토링 요청 시
  • 불필요한 변경까지 같이 제안함

👉 파일 단위로 잘라서 쓰는 게 핵심


❌ “정답 구조”를 알지는 못함

  • 프로젝트 성격
  • 팀 스타일
  • 향후 확장 계획

이런 건 결국 사람이 결정해야 한다.

Cursor는 보조자이지
아키텍트는 아니다.


7. 결론: Cursor로 만든 프로젝트, 이렇게 관리하면 좋다

추천 워크플로우

1️⃣ Cursor로 빠르게 만든다
2️⃣ 사람이 구조 기준을 잡는다
3️⃣ Cursor로 리팩토링 초안을 만든다
4️⃣ 사람이 최종 결정한다

👉 이 흐름이 가장 안정적이었다.


마무리 한 줄

Cursor는 “코드를 대신 짜주는 도구”가 아니라
“개발 속도를 극단적으로 앞당겨주는 도구”였다.

잘 쓰면 정말 강력하고,
맡길 걸 맡기고 책임질 건 사람이 책임지면
꽤 좋은 파트너가 된다.