코린이의 개발 일지

Cursor AI 활용: 장단점 본문

웹 (web)/프론트엔드

Cursor AI 활용: 장단점

폴라민 2025. 7. 13. 22:09
반응형

회사 사내 교육 프로그램에서 2주간 데이터 처리 주제의 프로젝트를 진행했다.
4명이 한 팀으로 구성됐으며, 나는 프론트엔드 전반을 담당했다.
발표 준비, 시연 영상, 기획 회의를 제외하면 실제 개발에 투입된 시간은 약 7일 정도였다.

이번 프로젝트에서는 회사에서 Cursor AI를 제공해주어 이를 잘 활용해보기로 했다.
개발 환경 세팅부터 기능 구현, 디버깅, 리팩토링까지 프론트엔드 전체를 Cursor에 의존해 진행해본 결과를 정리했다.


프로젝트 개요

✅ 목표

여러 상권 데이터를 수집·분석해 음식점 창업을 준비하는 사용자에게 유용한 정보를 제공하는 웹 서비스를 개발

✅ 사용 기술 스택

  • TypeScript
  • React.js
  • Chart.js (데이터 시각화)
  • Material UI, Emotion (UI 컴포넌트 & CSS-in-JS)
  • Recoil (상태 관리)
  • Google Maps API (지도)

데이터 수집 및 API 서버 구축은 다른 팀원이 맡았고,
나는 프론트엔드 전반을 혼자 진행했다.


Cursor AI를 사용하며 느낀 주요 장점

1. UI 개발 속도 극대화

왼쪽에 상권 메뉴를 드롭다운 형태로 구현하려고 할 때,
Cursor에 프롬프트를 다음과 같이 입력하면

'시간대별 유동인구' 를 subMenu에 추가해주고, 클릭하면 드롭다운 형태로 밑에 하위 메뉴가 나오도록 해줘. 하위 메뉴는 0~23 까지 time_period 이며, 0이 자정부터 새벽 세시, 1이 새벽 세시부터 아침 6시 이렇게 3시간 간격이야

 

바로 이렇게 UI를 구현해준다.

 
 

직접 CSS 조정이나 컴포넌트 구조 고민 없이,
바로 이 상태에서 필요한 데이터만 바인딩하면 됐다.
기존 같으면 구조 설계 → MUI 문서 확인 → CSS 조정에 몇 시간은 들었을 작업이다.

2. 맥락 기반 코드 수정 & 구현

Cursor에 명령을 입력하면 관련된 모든 파일을 탐색해 필요한 코드를 찾아 사용하고 수정한다.

덕분에 프롬프트를 대충 이렇게만 줘도

이제 유동인구 탭에서 지도에서 특정 지역을 클릭했을 때 나오는 툴팁에, 남 여 바그래프 말고, 해당 지역의 시간대별 유동인구 데이터를 바그래프로 그려줘

 

기존 API 요청 함수들 중 특정 행정동의 시간대별 유동인구 데이터를 가져오는 API를 활용해 데이터를 받아오고, Chart.js로 바그래프를 바로 그려준다.

당연히 기능구현 뿐만 아니라 디버깅도 관련 파일을 탐색해서 문제 원인을 찾아준다.

3. 코드 리팩토링

프로젝트 후반에 Map.tsx가 너무 커져 500줄이 넘어가자,
아래처럼 지시했다.

Map.tsx 기능은 그대로 유지하면서 코드 리팩터링 해줘.
 

그러자 알아서 커스텀 훅, 유틸 함수, 상수로 사용될 것들을 분리해서 새로 파일을 생성하고 리팩터링해줬다.

물론 문제가 아예 없던건 아니지만 이건 단점에서 자세히 다뤄보겠다.

 

4. 처음 사용하는 라이브러리의 경우 Best Practice 제공

이번에 Chart.js를 처음 사용했는데, Chart.js를 사용해서 어떤 데이터로 파이차트 그려줘. 하면 알아서 template 코드를 제공해 주니까, 여러 레퍼런스를 검색해봐야 하는 시간을 단축시켜준다.

이 점도 굉장히 좋았다.


Cursor AI의 단점과 실제 겪은 문제

1. 코드 재사용의 한계

Cursor는 이미 존재하는 함수를 잘 찾아서 사용한다. 그러나, 함수로 로직이 분리되어 있지 않으면, 동일한 로직을 그대로 똑같이 매번 다시 구현한다.
예를 들어, 지도에서 특정 행정동 클릭 시 줌인하는 로직을 유동인구 탭과 매출 탭 양쪽에서 똑같이 새로 만들었다.

결국 나중에 줌인 로직을 수정할 일이 생겼는데,
유동인구 탭만 수정하고 매출 탭은 빠뜨려 한쪽만 수정되는 문제가 발생했다.

 

 

행정동 클릭해서 선택된 행정동의 상태가 변경되면 → 현재 선택된 메뉴가 유동인구 혹은 매출 탭인지 확인하고 지도 줌인 로직을 실행하도록 코드가 구현되어 있었으면 더 코드 관리가 편했을 텐데. 이건 나중에 내가 직접 리팩토링 해줬다.


2. Dead Code

기능을 여러 번 수정하다 보면 Cursor가 기존 코드를 제거하지 않고 남겨둬 사용되지 않는 코드가 계속 쌓였다.

예를 들어 아래와 같이 Tooltip 표시되는 내용을 수정했을 때, 

왼쪽이 기존 UI,오른쪽이 수정된 UI


기존의 남여 바그래프는 이제 사용하지 않는데도, 그대로 코드가 남아있어서 내가 직접 삭제했다.

 

또한 Dead Code보다는 불필요한 로직이 남아있는 경우의 사례가 하나 더 있었는데,

원래 지역 상태로 관리하던 것을 전역 상태로 관리하도록 로직을 변경했는데, Sidebar 컴포넌트에서 Cursor가 지역상태와 전역상태를 혼용해서 계속 사용하고 있어서, 이것도 나중에 직접 대대적인 리팩토링을 진행했었다.


3. 리팩토링 후 기능 깨짐

Cursor가 리팩토링 과정에서 함수 내에서 상태 참조를 매개변수 방식으로 바꾸다 보니, 기존에 정상 동작하던 기능이 깨진 사례도 있었다.

 

위에 장점에서 언급했던 Map.tsx 파일 리팩토링을 진행한 후, 실행시켜 기능을 확인해보니, 유동인구 탭에서 남여 선택을 다르게 해도 지도 Polygon 색이 바뀌지 않았다.

코드를 확인해보니, getPopulationByGender 함수가 기존에는 Map.tsx 파일 내에 있어서, genderSelection 이라는 상태를 매개변수로 직접 받지 않고 상태를 바로 참조하고 있었는데, 따로 파일을 분리하게 되면서 getPopulationByGender 상태를 가져올 수 없게 되었다.

 

이 과정에서 Cursor가 그냥 함수 매개변수에 맞춰서 함수 내부 로직을 변경해버렸다.

 

내가 직접 함수를 수정한 커밋

결국 이부분도 내가 직접 다시 수정을 해줬는데,
분명 함수 내에서 getPopulationByGender 를 사용하고 있는데 왜 매개변수에 getPopulationByGender를 추가하지 않고 함수 내부를 수정하는 방식으로 리팩토링이 진행되었는지는 미지수다.

 

아무튼 이때 테스트가 정말 중요하구나가 느껴졌다. 이번에는 개발기간이 짧아서 테스트 코드는 안짰는데, 매번 기능 추가하거나 리팩터링할 때마다 기존 기능도 전부 일일이 확인하다 보니 내가 놓치는 부분도 많았고, 뒤늦게 발견해서 수정한 부분도 있었다.

 


결론: 어떻게 활용할 것인가

Cursor AI를 7일 동안 프론트엔드 전체에 전적으로 사용해본 결과
개발환경 세팅, UI 구축과 API 연동, 그리고 코드 리팩터링 측면에서 개발 생산성은 압도적으로 향상됐다.
반면 코드 재사용의 한계, Dead Code, 리팩토링 혹은 추가 기능 개발 이후 기존 기능 깨짐 같은 문제도 분명히 있었다.

하지만 이는 사람이 개발할 때도 동일하게 발생하는 문제라고 생각한다.

실제 개발할때도 남이 짠 코드는 전부 파악이 어려우니, 반복되는 로직도 무수히 생기고, Dead Code는 말할 것도 없고, 기존 함수 건드렸다가 잘되던 기존 기능이 고장나는 경우도 현업에서 허다하지 않나.

 

결론은 AI를 사용하더라도, 

  • 당연히 전체 코드를 완전히 파악하고 있어야 하며, 
  • 주기적인 리팩터링을 통해 Dead Code 제거와 반복되는 로직을 함수로 분리하고
  • 테스트 코드를 통해 코드가 변경될 때 마다, 기존 기능이 깨지지 않는지 검토가 필요하다.

가장 Cursor AI가 유용하게 사용되는 상황은 아무래도 개인 프로젝트 진행하면서 처음 사용해보는 라이브러리를 학습할 때, 정말 유용하게 사용될 거 같고,

그리고 빠르게 개발 해야 하는 PoC에서 정말 정말 유용할 거 같다.

 

이번 프로젝트 하면서 ai 없이 혼자 풀 개발 했으면 이거 기능 절반 정도밖에 구현하지 않았을까..? 싶다.

 

아 참. 그리고 좀 비싸다는 게 흠이라면 흠이다..

반응형
Comments