Cursor의 Composer 모드를 실전 프로젝트에 적용한 3주간의 기록

배경

사내 백오피스 시스템의 레거시 코드 정리 작업을 맡았다. 컴포넌트 구조 개선, API 레이어 분리, 타입 정의 통일 등 여러 파일을 동시에 수정해야 하는 작업이었다. Cursor의 Composer 모드를 본격적으로 써볼 기회라고 판단했다.

효과를 본 케이스

1. 컴포넌트 분리 작업

하나의 거대한 UserManagement.tsx (800줄)를 여러 컴포넌트로 분리하는 작업에서 Composer가 빛을 발했다.

"UserManagement 컴포넌트를 UserList, UserDetail, UserForm으로 분리하고,
공통 타입은 types.ts로 추출해줘. 각 파일은 200줄 이하로 유지"

5개 파일을 동시에 생성하고 수정하면서도 import 경로, 타입 참조가 정확했다. 수동으로 했다면 1시간은 걸렸을 작업을 15분만에 완료했다.

2. API 레이어 통일

fetch, axios가 혼재된 API 호출을 통일된 클라이언트로 교체하는 작업도 수월했다. 20개 파일의 API 호출 패턴을 일괄 변경하면서 에러 처리 로직도 개선했다.

한계와 문제점

컨텍스트 누락

Composer가 프로젝트 구조를 완벽히 이해하지 못하는 경우가 있었다. 특히 모노레포 구조에서 packages/shared의 유틸을 참조해야 하는데, 자꾸 새로 만들려고 했다. .cursorrules에 명시해도 가끔 놓쳤다.

과도한 수정 범위

"로그인 플로우를 개선해줘"처럼 추상적인 요청을 하면, 필요 이상으로 많은 파일을 수정하려 했다. 10개 파일 변경을 제안받았는데, 실제로는 3개만 수정하면 되는 케이스였다. 요청을 구체적으로 쪼개는 게 중요했다.

diff 확인의 중요성

Composer가 제안한 변경사항을 무심코 수락했다가, 의도하지 않은 로직 변경이 포함된 적이 있었다. 이후로는 반드시 diff를 꼼꼼히 확인하는 습관을 들였다.

결론

3주간 사용하며 내린 결론은 "구체적인 멀티파일 작업에 최적화"되어 있다는 것이다. 범위가 명확한 리팩토링, 보일러플레이트 작업에서는 생산성이 확실히 올랐다. 하지만 복잡한 비즈니스 로직이나 아키텍처 변경은 여전히 사람이 설계하고, Composer는 실행 도구로 쓰는 게 맞다고 느꼈다.

앞으로는 "30분 이상 걸릴 것 같은 반복 작업"에 우선적으로 Composer를 활용할 계획이다.