모노레포에서 Cursor와 Claude Code를 역할로 나눠 쓰는 1년치 결론
정유나
@yuna_ai
Cursor Tab 자동완성을 1년 넘게 메인으로 쓰다가 최근 Claude Code 비중이 크게 늘었다. 완전히 갈아탄 건 아니고, 둘을 작업 성격으로 나눠 쓰는 구조로 정착했다. 무엇을 기준으로 나눴는지, 그 기준이 왜 생겼는지 정리한다.
갈라지기 시작한 지점
패키지를 여러 개 쪼갠 모노레포로 옮기면서 Cursor가 컨텍스트를 놓치는 일이 잦아졌다. 가장 자주 겪은 패턴은 두 가지다.
- 다른 패키지에 정의된 타입을 물어보면 동명의 로컬 타입을 끌어와서 엉뚱한 import를 박는다.
packages/shared의User를 봐야 하는데 현재 패키지 안의User를 잡는 식. - 자동완성이 열려 있는 파일과 최근 연 탭 중심으로만 추론해서, 인덱싱이 안 닿은 워크스페이스의 함수 시그니처를 추측으로 채운다.
한 줄짜리 수정에서는 이게 오히려 빠른데, 파일 여러 개에 걸친 변경에서는 추측이 누적돼서 결국 내가 다 따라가며 고쳐야 했다.
Claude Code로 큰 덩어리를 넘긴 이유
같은 모노레포에서 12개 파일에 걸친 리팩터를 Claude Code에 시켰을 때는 동작이 달랐다. 바로 추측하지 않고 grep/파일 탐색으로 실제 정의를 먼저 찾고 들어간다. 변경 후 타입체크(tsc --noEmit)까지 알아서 돌려서 깨진 곳을 스스로 다시 잡았다. 추측 기반이 아니라 "읽고 확인한 뒤 고치는" 흐름이라 파일이 늘어날수록 격차가 벌어졌다.
반대로 한두 줄 잔손질에서는 이게 과하다. 매번 탐색부터 들어가니 느리고, 무엇보다 Tab 자동완성의 즉각성이 없다. 타이핑 흐름에 끼어드는 작은 보정은 여전히 Cursor Tab이 압도적으로 빠르다.
현재 나눈 기준
| 작업 | 도구 | 이유 |
|---|---|---|
| 여러 파일 리팩터, 새 모듈 추가 | Claude Code | 정의를 grep으로 확인 후 변경, 타입체크 루프까지 |
| 함수 한두 줄 수정, 보일러플레이트 | Cursor Tab | 타이핑 흐름 안에서 즉시 완성 |
| 패키지 경계 넘는 타입 추적 | Claude Code | 워크스페이스 전체를 읽고 들어감 |
| 주석/이름 바꾸기 같은 잔손질 | Cursor | 컨텍스트 거의 불필요 |
비용
명확한 트레이드오프는 토큰 비용이다. Claude Code에 큰 작업을 자주 넘기면 탐색 단계에서 파일을 많이 읽으므로 입력 토큰이 누적된다. 그래서 "덩어리 작업만" 넘기는 기준 자체가 비용 통제 장치 역할도 한다. 잔손질까지 Claude Code로 다 시키면 효과 대비 비용이 안 맞는다.
결론적으로 한쪽으로 정리하기보다 작업 크기를 경계로 둔 게 가장 안정적이었다. 모노레포처럼 컨텍스트 범위가 넓은 코드베이스일수록 "전체를 읽고 들어가는 도구"와 "흐름 안에서 즉시 채우는 도구"의 강점이 뚜렷하게 갈린다.