AI 코딩 일반

같은 리팩토링, 커서·클로드코드·코덱스에 다 시켰다: 광범위 수정 실전 비교 (2026)

DevPilot 2026. 9. 10. 20:27

핵심 요약: 버그 수정·새 기능 편에 이어, 리뷰 3부작의 마지막 — "리팩토링 시키기"입니다. 제 서비스(AI 비용 계산기)에서 여러 컴포넌트에 흩어진 통화 환산(USD→KRW) 로직을 공용 유틸 하나로 통합하는 과제를 커서·클로드코드·코덱스에 동일 투입했어요. 리팩토링의 생명은 "흩어진 호출부를 하나도 빠뜨리지 않고 다 바꾸느냐"인데 — 클로드코드가 긴 컨텍스트로 전 호출부를 추적해 가장 안전했고, 커서는 파일을 @멘션 앵커로 짚어주면 정확했지만 파일 수가 많아지자 후반에 몇 개를 놓쳤으며, 코덱스는 제일 빨랐지만 흩어진 호출부 두 곳을 빠뜨려 그대로 머지했으면 환산이 어긋날 뻔했습니다. 한 줄 결론: 광범위 리팩토링은 클로드코드, 범위가 좁으면 커서(앵커), 빠른 시도는 코덱스+철저한 검수.

이 글에서 다루는 내용: 어떤 리팩토링이었나, 공정 비교 규칙, 세 도구의 실제 결과, 항목별 비교표, 상황별 추천, 배운 것.

먼저, 어떤 리팩토링이었나

제 계산기에는 통화 환산 로직이 컴포넌트마다 복붙돼 있었습니다 — 결과 카드, 비교 표, 요약 배너 등 여러 곳에서 각자 USD에 환율을 곱하고 있었죠(전형적인 레거시 냄새). 과제는 이걸 공용 유틸 함수 하나로 뽑아내고 모든 호출부를 그 함수로 교체하는 것이었습니다. 어려운 지점은 로직 자체가 아니라 범위였어요 — 흩어진 호출부가 십수 군데라, "하나라도 빠뜨리면 그 화면만 옛날 환율로 남는" 리팩토링이었습니다.

▲ 같은 리팩토링, 세 갈래. 리팩토링의 승부는 지능보다 "흩어진 호출부를 다 잡느냐"에서 났습니다.

공정하게 비교하려고 정한 규칙

세 가지를 고정했습니다. ① 같은 시작점 — 셋 다 같은 커밋에서 출발. ② 같은 프롬프트 — "여러 곳에 복붙된 USD→KRW 환산 로직을 공용 유틸 하나로 뽑고, 모든 호출부를 교체해줘"만 주고 힌트는 안 줌. ③ 같은 잣대 — 흩어진 호출부를 몇 개나 빠뜨리는가, 빌드·테스트가 통과하는가, 사람이 손볼 게 얼마나 남는가, "이대로 머지해도 되나". 검증은 리팩토링 전후로 모든 화면의 환산 결과가 동일한지 스냅샷 테스트로 확인했습니다.

① 코덱스(Codex): 제일 빨랐지만 두 곳을 놓쳤다

코덱스는 공용 유틸을 만들고 대부분의 호출부를 빠르게 갈아치웠습니다. 자율 실행으로 쭉 밀어붙이는 힘은 여전히 좋았어요. 문제는 덜 뚜렷한 호출부 두 곳(조건부 렌더 안쪽, 그리고 유틸이 아니라 인라인으로 계산하던 배너)을 못 찾고 남겨뒀다는 겁니다. 스냅샷 테스트를 돌리니 그 두 화면만 값이 어긋났어요 — 테스트가 없었다면 배포 후에야 발견했을 종류의 누락입니다.

// 코덱스가 놓친 호출부 (인라인 계산이 그대로 남음)
const krw = usd * rate; // ← convertUSD(usd)로 안 바뀜

맨바닥 작업이나 호출부가 몇 개 안 되는 리팩토링이면 이 속도가 그대로 강점입니다. 하지만 광범위하게 흩어진 리팩토링에서는 "빠르게 대부분"이 오히려 위험해요 — 남은 소수를 사람이 다 찾아야 하는데, 그게 리팩토링에서 제일 품이 드는 일이니까요.

② 커서(Cursor): 앵커는 정확, 대형 스팬에선 후반에 놓침

커서는 관련 파일들을 @멘션으로 앵커로 넘기면 정확하게 교체했습니다. 인라인 diff로 파일별 확인이 편했고요. 그런데 파일이 20개를 넘어가자 세션 후반에 앞쪽 맥락을 놓치는 현상이 나왔어요 — 초반 파일은 공용 유틸로 잘 바꿨는데, 뒤쪽 몇 개는 새 유틸을 안 쓰고 비슷한 걸 또 만들려 했습니다. 컨텍스트 창의 한계로 알려진 그 지점이더군요.

그래서 커서로 대형 리팩토링을 할 땐 "한 번에 다"가 아니라 폴더/도메인 단위로 쪼개서 앵커를 주는 게 답이었습니다. 범위를 좁게 끊으면 정확도가 확 올라가요. 관례를 Rules에 박아두면 "새 유틸 대신 기존 걸 쓰라"는 지시를 매번 반복하지 않아도 됩니다.

③ 클로드코드(Claude Code): 전 호출부를 추적해 가장 안전했다

클로드코드에는 앵커 없이 과제만 던졌는데, 먼저 코드베이스에서 환산 패턴을 전수 검색해 호출부 목록을 뽑고("총 14곳을 찾았다"), 계획을 보여준 뒤 공용 유틸을 만들어 하나씩 교체하며 각 지점을 보고했습니다. 코덱스가 놓친 인라인 배너와 조건부 렌더 안쪽까지 다 잡았고, 마지막에 테스트를 돌려 전 화면 값이 동일함을 확인했어요. 광범위 리팩토링에서 필요한 "빠짐없이"가 셋 중 가장 강했습니다 — 지난 디버깅 편의 "긴 맥락을 끝까지"가 여기서도 이어집니다.

▲ 리팩토링은 '범위'가 도구를 정합니다. 넓게 흩어질수록 전수 추적이 강한 쪽으로.

대가는 역시 토큰입니다 — 전수 검색과 추적에 파일을 많이 읽어 소모가 컸어요(긴 세션은 비용이 붙습니다). 하지만 "하나라도 빠지면 그 화면만 틀리는" 리팩토링에서는 그 비용이 버그를 미리 막는 값으로 정당화됐습니다.

항목별 비교

항목 코덱스(Codex) 커서(Cursor) 클로드코드(Claude Code)
속도 가장 빠름 빠름 전수 검색이라 느림
호출부 누락 2곳 누락 대형 스팬서 후반 누락 누락 없음
범위 대응 좁은 범위에 적합 쪼개서 앵커 주면 정확 광범위에 강함
사람 개입 누락분 직접 탐색 범위 분할·앵커 지정 거의 없이 진행
비용·체감 빠름·자율성↑ IDE diff 리뷰 토큰 많이 씀·터미널
이대로 머지? ❌ (누락 있음) ⭕ (범위 쪼개면) ⭕ (검수 후)

상황별 추천

호출부가 넓게 흩어진 광범위 리팩토링: 클로드코드의 전수 추적이 값을 합니다 — "빠짐없이"가 생명인 작업에 가장 안전합니다. 범위가 좁거나 특정 폴더로 한정되는 리팩토링: 커서에 그 파일들을 앵커로 주면 가장 쾌적합니다(넓으면 도메인 단위로 쪼개세요). 빠르게 초안 리팩토링을 뽑고 싶을 때: 코덱스가 빠르되, 흩어진 호출부 누락을 잡을 테스트가 반드시 함께 있어야 합니다. 저는 광범위 정리는 클로드코드에 맡기고, 좁은 범위는 커서 앵커로 처리하는 식으로 나눠 씁니다. 단일 도구 관점의 Cursor 레거시 경험은 이 글에 따로 정리해뒀습니다.

정작 제일 크게 배운 것

리팩토링에서 도구를 가른 건 "코드를 얼마나 잘 바꾸느냐"가 아니라 "바꿔야 할 곳을 다 찾느냐"였습니다. 그리고 그걸 보증해준 건 도구가 아니라 내가 미리 짜둔 스냅샷 테스트였어요 — 테스트가 없었다면 코덱스의 누락 두 곳은 조용히 배포됐을 겁니다. 결국 AI가 광범위 수정을 빠르게 해줄수록, "바뀐 결과가 예전과 같은지 자동으로 확인하는 안전망"이 리팩토링의 진짜 핵심이라는 걸 이 작업이 다시 확인시켜 줬습니다. 이걸로 리뷰 3부작(고치기·만들기·리팩토링)에서 매번 같은 결론에 도달했네요 — 빨라질수록 검수가 실력이다.

자주 묻는 질문 (FAQ)

Q. 광범위 리팩토링엔 어떤 도구가 제일 낫나요?

A. 호출부가 넓게 흩어졌다면 클로드코드의 전수 추적이 가장 안전합니다. 범위가 좁거나 특정 폴더로 한정되면 커서에 앵커를 주는 게 더 쾌적하고, 코덱스는 빠르되 누락을 잡을 테스트가 전제입니다.

Q. AI가 한 리팩토링을 그냥 믿고 머지해도 되나요?

A. 특히 안 됩니다. 이번에도 한 도구가 흩어진 호출부 두 곳을 놓쳐, 그대로 합쳤다면 그 화면만 옛 로직으로 남을 뻔했습니다. 리팩토링 전후 결과가 동일한지 확인하는 테스트를 반드시 돌리고 머지하세요.

Q. 커서가 대형 리팩토링에서 뒤로 갈수록 놓치는데요?

A. 컨텍스트 창 한계 때문입니다. 한 번에 전체를 시키지 말고 폴더·도메인 단위로 쪼개 앵커를 주면 정확도가 크게 올라갑니다.

Q. 세 개를 다 결제해야 하나요?

A. 아니요. 하나로 시작해 부족할 때 하나를 더합니다. 무료·체험으로 자기 코드에 같은 리팩토링을 시켜보고 정하는 게 가장 정확합니다.

한눈에 보는 요약

같은 광범위 리팩토링을 세 도구에 시켰더니 — 코덱스는 빨랐지만 흩어진 호출부 두 곳을 놓쳤고, 커서는 앵커를 주면 정확했지만 파일이 많아지자 후반에 놓쳤고, 클로드코드는 전수 추적으로 다 잡았습니다. 넓게 흩어지면 클로드코드, 좁으면 커서(앵커), 빠른 시도는 코덱스+테스트. 그리고 무엇을 쓰든 "결과가 예전과 같은지" 검증하는 안전망이 리팩토링의 핵심입니다.

함께 보면 좋은 글

같은 버그, 세 도구에 다 시켜봤다 (디버깅 편)
같은 기능, 세 도구에 다 만들게 시켰다 (스캐폴딩 편)
Cursor로 레거시 코드 리팩토링한 경험 (단일 도구)

참고 자료

Claude Code 공식 문서
OpenAI Codex 소개
Cursor 공식 사이트