Cursor가 API 수정 시 프론트를 빼먹나요? CodeGraph 실측 솔루션（Vue + Spring Boot）

Cursor나 Claude Code로 API를 바꿨는데 백엔드만 머지되고 프론트는 그대로인 경험, 흔합니다. 이 글은 왜 빠지는지, 실제 사례를 어떻게 잡는지, CodeGraph로 어떻게 해결하는지 세 가지만 다룹니다. 스택은 Vue 3 + Spring Boot 분리 저장소, 도구는 CodeGraph(MCP)입니다.

Cursor가 프론트를 빼먹는 이유

누락은 “모델이 코드를 못 쓴다”기보다 AI Coding이 디렉터리·언어를 넘는 참조를 못 보는 경우가 많습니다. Vue + Spring Boot에서는 보통 세 가지입니다.

1. 컨텍스트 창: 열린 파일만 보임

Cursor @ 파일, Claude Code Read에는 한도가 있습니다. Agent는 OrderController.java만 보고 300줄 밖의 frontend/src/api/order.ts가 같은 DTO 필드를 쓰는지 모릅니다. 대화·브랜치를 바꾸면 “어디까지 고쳤는지”가 더 잘 사라집니다(Cursor 망각과 겹치면 더합니다).

2. grep: 문자열은 찾지만 호출 관계는 모름

탐색은 grep에 의존하기 쉽습니다. amount 검색은 로그·테스트·미사용 상수까지 나오고, OrderService.createOrder 호출자나 @PostMapping handler는 구분되지 않습니다. 토큰은 “입구 찾기”에 쓰이고 “전체 영향면 수정”에는 못 씁니다.

3. impact 분석 없음: 한 곳 고치고 열 곳 방치

사람은 “이 필드를 바꾸면 누가 깨지나?”를 먼저 묻습니다. 구조화된 impact가 없으면 Agent는 “Java 끝”으로 TypeScript·Pinia·테스트를 다음 라운드로 미룹니다—한 번의 대화로 끝난 줄 알았지만 실제로는 두 번의 부채입니다.

필요한 것은 항상 더 큰 모델이 아니라 호출 그래프·의존 엣지·라우트 진입점을 조회할 통로입니다. 아래 주문 API 예시입니다.

실제 사례: OrderDTO.amount

요구: POST /api/orders 요청 본문에서 amount를 number에서 string으로(대액·포맷 문자열 등). 저장소는 backend/(Controller → Service → OrderDTO), frontend/(api/order.ts → Pinia → 주문 화면) 분리 구조입니다.

CodeGraph 없을 때 Cursor / Claude Code가 자주 빼먹는 것

업무 설명만 주고 @ 파일은 지정하지 않았습니다. 흔한 결과:

• ✅ OrderDTO.java, OrderService 수정
• ❌ frontend/src/api/order.ts의 createOrder payload 타입
• ❌ useOrderStore의 amount 매핑
• ❌ 주문 페이지 v-model이 숫자 검증 그대로

mvn compile은 통과할 수 있고 pnpm build도 통과할 때가 있습니다—머지 후 연동이나 프로덕션에서 터집니다. “API는 고쳤는데 프론트를 잊었다”가 이것입니다.

대조: impact 영향 목록(발췌)

codegraph_impact
  symbol: "OrderDTO.amount"

→ OrderService.createOrder
→ OrderController.create
→ frontend/src/api/order.ts :: createOrder
→ stores/order.ts :: useOrderStore

마지막 줄이 grep에서 가장 잘 빠지던 Pinia입니다. 목록대로 Cursor / Claude Code에서 수정하면 누락이 줄어듭니다.

CodeGraph로 문제 찾기

CodeGraph는 Tree-sitter로 Java / TS / Vue script를 인덱스하고 호출 엣지를 .codegraph/에 저장한 뒤 MCP로 codegraph_*를 제공합니다. 데이터는 기본적으로 로컬에 둡니다.

이 주문 API에서는 순서를 고정합니다:

1. codegraph_context — Controller, DTO, 프론트 API 진입을 태스크 단위로(경로 @ 불필요)
2. codegraph_trace — Spring: OrderController.create → OrderMapper.insert
3. codegraph_impact — OrderDTO.amount에서 Java + Vue + store로 확장
4. codegraph_explore — 관련 메서드만(800줄 Service 통째로 넣지 않음)

HTTP 경로와 axios 문자열에 symbol 엣지가 없어도 DTO impact로 프론트에 닿을 수 있습니다—이번 사례의 “기대 이상” 지점입니다. 도구·RAG 비교는 코드 지식 그래프; 설치는 아래.

AGENTS.md에 DTO 변경 전 codegraph_impact 필수, frontend/src/api와 Pinia 나열을 적어 두면 “프론트 잊지 마” 한 줄보다 낫습니다.

설치(약 5분)

frontend/ + backend/가 있는 저장소 루트(macOS):

curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh
# 또는: npx @colbymchenry/codegraph

codegraph install --target=cursor --yes
cd /path/to/your-repo
codegraph init -i
codegraph status

첫 전체 인덱스는 규모에 따라 10~20분. node_modules, target, dist 제외. 저장 후 약 2초 디바운스 증분 동기화; MCP가 ⚠️ Pending sync이면 Agent가 소스 Read.

결과 비교

공식 Java 벤치(OkHttp ~645 파일) 중앙값 10→3(2026-05-29). Vue + Spring에서도 탐색은 절반 이하로 느껴졌습니다. 그래프는 테스트 대체가 아닙니다—머지 전 mvn test + pnpm test:unit.

대형 저장소 인덱스 위치

첫 codegraph index는 CPU·SQLite 쓰기·팬이 칩니다—IDEA로 Spring, pnpm build로 Vue를 동시에 돌리면 Cursor MCP도 버벅입니다.

클론+전체 인덱스+정기 재구축을 Mac mini, CI, Cloud Mac에 두고 노트북은 코딩·MCP만—저는 일 단위 Macstripe M4에서 인덱스하고 로컬 빌드와 엇갈립니다. worktree는 기업 Mac CI FAQ.

「Cloud Mac + CodeGraph 배포」는 별도 글 주제—여기서는 인덱스와 인터랙션을 분리하면 안정적이라는 점만.

요약

Cursor가 API 수정 시 프론트를 빼먹는 이유는 보통 제한된 컨텍스트 + 호출을 모르는 grep + impact 없음입니다. Vue + Spring Boot에서 CodeGraph MCP context → trace → impact로 DTO 변경의 전후단 목록을 한 번에 맞추고, 탐색은 수십 번 grep에서 구조화 쿼리 몇 번으로 줄일 수 있습니다.

고정 절차: init → impact(DTO 전) → 목록대로 수정 → 테스트. 개념 글·대형 저장소 Claude Code·Cloud Mac 배포는 시리즈로—아래 관련 글.

관련 글

• 코드 지식 그래프: 대형 저장소에 어떤 지도가 맞나?
• Cursor가 잊는 이유—긴 컨텍스트로 주간 협업은 안 살아남
• OpenClaw 원격 Mac: 장시간 Agent와 인덱스 동일 머신