Cursor Composer의 멀티파일 편집, 실전에서 체감하는 한계점

배경

레거시 API 클라이언트를 전면 개편하는 작업이 필요했다. 약 15개의 파일에 걸쳐 있는 REST 기반 클라이언트를 타입 안전성이 보장되는 구조로 바꿔야 했다. Cursor Composer가 멀티파일 편집에 강하다는 얘기를 듣고 시도해봤다.

시도한 방식

Composer 모드에서 다음과 같이 요청했다:

/api 디렉토리의 모든 클라이언트 함수에 zod 스키마 기반 검증 추가.
각 엔드포인트마다 Request/Response 타입 생성하고,
runtime validation 레이어 추가해줘.

처음엔 잘 동작하는 것처럼 보였다. 5~6개 파일까지는 일관성 있게 수정됐고, 타입 정의도 제대로 생성됐다.

문제 발생

하지만 7번째 파일부터 이상한 일이 벌어졌다:

1. 이전 파일 컨텍스트 망각: 앞서 만든 공통 유틸 함수를 재사용하지 않고 비슷한 코드를 다시 생성
2. 불완전한 수정: import 문은 추가했는데 실제 함수 본문은 수정 안 함
3. 타입 불일치: 초반에 정의한 Base 타입과 다른 구조의 타입을 후반부에 생성

특히 치명적이었던 건, 중간에 "Apply" 버튼을 눌러 일부만 적용한 뒤 계속 진행하면 이미 적용한 변경 사항을 또 다시 제안한다는 점이었다.

해결 방법

결국 작업을 3단계로 쪼갰다:

1. 공통 타입과 유틸만 먼저 Composer로 생성
2. 각 클라이언트 파일은 개별적으로 Chat 모드에서 수정
3. 마지막에 통합 테스트 작성만 Composer 활용

이렇게 하니 훨씬 안정적이었다. Composer는 5개 이하 파일을 다룰 때 가장 효과적이란 걸 체감했다.

교훈

Composer의 멀티파일 편집은 분명 강력하지만, 컨텍스트 윈도우 안에서도 일관성 유지에는 한계가 있다. 큰 작업은 여전히 사람이 구조를 설계하고, AI는 반복 작업을 맡기는 게 현실적이다.

작업 단위를 작게 쪼개고, 각 단계마다 결과를 검증하는 습관이 더 중요해졌다.