같은 기능, 커서·클로드코드·코덱스에 다 만들게 시켰다: 스캐폴딩 실전 비교 (2026)

핵심 요약: 지난번 버그 수정 편에 이어, 이번엔 "새 기능 만들기"를 세 도구에 똑같이 시켜봤습니다. 제 서비스(AI 비용 계산기)에 새 계산기 페이지 하나를 통째로 스캐폴딩하는 과제를 커서(Cursor)·클로드코드(Claude Code)·코덱스(Codex)에 동일 투입했어요. 결과: 코덱스는 빈 캔버스에서 파일·의존성·기본 테스트까지 제일 빨리 뽑았지만 우리 프로젝트의 기존 컨벤션을 겉돌았고, 커서는 기존 계산기 파일을 @멘션으로 앵커 주자 스타일이 딱 맞게 나왔으며, 클로드코드는 힌트 없이도 계획을 먼저 보여주고 기존 구조를 스스로 파악해 맞췄습니다. 한 줄 결론: 맨바닥 신규는 코덱스, 기존 프로젝트에 얹기는 커서(앵커)나 클로드코드. 그리고 셋 다 컨벤션 검수는 사람 몫이었습니다.

이 글에서 다루는 내용: 어떤 스캐폴딩 과제였나, 공정 비교 규칙, 세 도구의 실제 결과물, 항목별 비교표, 상황별 추천, 배운 것.

먼저, 어떤 과제였나

제 계산기 사이트에는 이미 "AI 비용 계산기"가 있고, 여기에 변형 페이지 하나(이미지 생성 비용 계산기)를 새로 추가하는 게 과제였습니다. 손이 가는 파일이 여럿이라 스캐폴딩 비교에 딱 맞아요 — 새 라우트, 입력 폼 컴포넌트, 모델별 단가 데이터 모듈, 결과 카드, 내비게이션 링크까지. 기존 계산기가 이미 그 다섯 조각을 갖고 있으니, "얼마나 우리 패턴에 맞게 새 걸 얹느냐"가 진짜 관전 포인트였습니다.

▲ 같은 "새 기능 만들기", 세 갈래 접근. 빠르게 찍어내느냐, 기존 걸 참조해 맞추느냐, 스스로 구조를 읽어 맞추느냐.

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

세 가지를 고정했습니다. ① 같은 시작점 — 셋 다 같은 커밋에서 출발. ② 같은 프롬프트 — "기존 AI 비용 계산기와 같은 구조로, 이미지 생성 비용 계산기 페이지를 새로 추가해줘. 라우트·폼·단가 데이터·결과 카드·내비 링크까지"만 주고, 추가 힌트는 안 줌. ③ 같은 잣대 — 얼마나 빨리 도는가, 기존 컨벤션(파일 위치·네이밍·스타일)을 얼마나 따르는가, 사람이 손볼 게 얼마나 남는가, "이대로 머지해도 되나". 벤치마크 점수는 참고만 하고 판단은 제 실제 코드베이스에서 어떻게 굴렀는지로 했습니다.

① 코덱스(Codex): 빈 캔버스에서 제일 빠르다

코덱스의 강점이 스캐폴딩에서 그대로 나왔습니다 — 다섯 조각을 한 번에 만들고, 필요한 의존성을 설치하고, 기본 렌더 테스트까지 붙여 돌아왔어요. 사람이 중간에 끼어들 일이 거의 없이 끝까지 밀어붙이는 자율성은 확실히 편했습니다. 문제는 "우리 프로젝트답지 않다"였어요 — 단가 데이터를 기존 모듈에 합치는 대신 새 형식으로 따로 만들었고, 결과 카드도 기존 컴포넌트를 재사용하지 않고 비슷한 걸 새로 그렸습니다.

// 코덱스: 기존 pricing.ts를 두고 새 파일을 만듦
// image-pricing.ts  (기존 pricing.ts와 형식이 미묘하게 다름)
export const IMAGE_PRICES = { "model-a": 0.04, ... };

맨바닥에서 새 프로젝트를 찍는 상황이라면 이 속도가 그대로 강점입니다. 하지만 이미 패턴이 있는 코드베이스에 얹을 때는, 빨리 나온 결과물을 우리 컨벤션에 맞추는 뒷작업이 생겨 시간 이득이 절반쯤 상쇄됐습니다.

② 커서(Cursor): 앵커를 주면 결이 딱 맞는다

커서는 IDE 안에서 기존 계산기 파일들을 @멘션으로 앵커로 넘길 수 있는 게 결정적이었습니다. "@ai-cost/ 이 폴더 구조와 같은 방식으로 image 버전을 만들어줘"라고 하니, 기존 pricing 모듈에 항목을 추가하고 결과 카드도 같은 컴포넌트를 재사용해서, 스타일이 처음부터 맞게 나왔어요. 멀티파일 수정은 Composer/Agent(그 정리)로 묶여 인라인 diff로 리뷰가 편했고요.

// 커서: 앵커(@pricing.ts) 덕에 기존 모듈에 얹음
// pricing.ts 에 항목 추가 (형식 그대로)
export const PRICES = { ...text, image: { "model-a": 0.04 } };

정리하면 커서는 "참고할 기존 코드를 내가 짚어줄 수 있을 때" 가장 강했습니다. 반대로 앵커 없이 던지면 코덱스처럼 새 파일을 만드는 경향이 있어, 앵커를 주는 한 줄이 결과 품질을 갈랐습니다. 관례를 아예 규칙으로 박아두면(Rules) 앵커 없이도 편차가 줄어듭니다.

③ 클로드코드(Claude Code): 힌트 없이 구조를 읽어 맞춘다

클로드코드에는 앵커 없이 과제 문장만 던졌는데, 먼저 계획을 보여주고("기존 pricing 모듈을 확장하고, CalculatorCard를 재사용하겠다") 나서 여러 파일을 훑어 우리 구조를 스스로 파악한 뒤 그에 맞춰 만들었습니다. 새 파일을 남발하지 않고 기존 걸 확장하는 판단이 셋 중 가장 정확했어요. 터미널에서 테스트까지 돌려 마무리했고요 — 지난 디버깅 편에서 본 "맥락을 끝까지 붙잡는" 강점이 스캐폴딩에서도 나왔습니다.

▲ 신규냐 기존이냐 — 이 한 갈래가 스캐폴딩 도구 선택의 대부분을 결정합니다.

대가는 역시 토큰이었습니다. 구조를 파악하느라 파일을 많이 읽어 소모가 컸고(긴 세션은 비용이 붙습니다), 터미널 전용이라 시각적 diff가 익숙한 분은 초반이 낯설 수 있어요. 그래도 "기존 프로젝트에 자연스럽게 얹기"에서는 앵커를 안 줘도 되는 유일한 도구였습니다.

항목별 비교

항목	코덱스(Codex)	커서(Cursor)	클로드코드(Claude Code)
속도(맨바닥)	가장 빠름	빠름	계획 먼저라 약간 느림
기존 컨벤션 준수	약함(새 파일 남발)	앵커 주면 정확	자력 파악, 정확
기존 코드 재사용	덜 함	앵커로 재사용	스스로 재사용 판단
사람 개입	컨벤션 정리 필요	앵커 한 번 지정	거의 없이 진행
비용·체감	빠름·자율성↑	IDE 손맛·diff 리뷰	토큰 많이 씀·터미널
이대로 머지?	△ (컨벤션 손질 후)	⭕ (검수 후)	⭕ (검수 후)

상황별 추천

맨바닥에서 새 프로젝트·프로토타입을 찍을 때: 코덱스가 빠릅니다 — 참고할 기존 패턴이 없으니 "새 파일 남발"이 단점이 아니라 그냥 속도가 됩니다. 이미 패턴이 있는 코드베이스에 기능을 얹을 때: 커서(앵커 지정)나 클로드코드(자력 파악)가 뒷작업을 줄여줍니다. IDE에서 diff를 눈으로 확인하며 가고 싶으면 커서, 앵커 지정도 귀찮고 알아서 맞춰주길 원하면 클로드코드. 저는 요즘 기존 서비스 작업은 커서에 앵커를 주고 가다가, 구조가 복잡해 앵커를 특정하기 애매하면 클로드코드에 통째로 넘기는 식으로 씁니다.

정작 제일 크게 배운 것

스캐폴딩은 셋 다 "만들기" 자체는 잘합니다 — 갈리는 건 "우리 프로젝트답게" 만드느냐였어요. 그리고 그건 도구의 지능보다 내가 맥락(앵커·규칙·기존 구조)을 얼마나 쥐여주느냐에 달려 있었습니다. 코덱스가 겉돈 것도 도구가 나빠서가 아니라 맥락을 안 줬기 때문이고, 규칙 파일 하나만 있었어도 결과가 달랐을 겁니다. 결국 빨리 만들어주는 시대일수록 "무엇을 우리 관례로 정해 두느냐"가 결과를 가른다는 걸, 이 작은 페이지 하나가 다시 확인시켜 줬습니다.

자주 묻는 질문 (FAQ)

Q. 새 기능 스캐폴딩엔 어떤 도구가 제일 낫나요?

A. 맨바닥 신규는 코덱스의 속도, 기존 프로젝트에 얹기는 커서(앵커 지정)나 클로드코드(자력 파악)가 낫습니다. "우리 코드에 자연스럽게 붙느냐"가 기준이면 클로드코드를 기본으로 두되, 참고 파일을 짚어줄 수 있으면 커서가 가장 쾌적합니다.

Q. AI가 만든 새 기능을 그냥 믿고 머지해도 되나요?

A. 권하지 않습니다. 이번에도 한 도구는 기존 모듈을 두고 새 파일을 만들어, 그대로 합쳤다면 단가 데이터가 두 곳으로 갈라질 뻔했습니다. 최소한 "기존 걸 재사용했는지, 컨벤션에 맞는지"를 확인하고 머지하세요.

Q. 결과를 우리 스타일에 맞추는 제일 쉬운 방법은요?

A. 참고할 기존 파일을 앵커로 주거나(커서 @멘션), 관례를 규칙 파일(Cursor Rules·CLAUDE.md)에 박아두는 것입니다. 맥락을 미리 쥐여줄수록 뒷작업이 줄어듭니다.

Q. 셋을 다 결제해야 하나요?

A. 아니요. 하나로 시작해 부족할 때 하나를 더합니다. 무료·체험으로 자기 프로젝트에 같은 스캐폴딩을 시켜보고 정하는 게 가장 정확합니다.

한눈에 보는 요약

같은 새 기능을 세 도구에 만들게 했더니 — 코덱스는 빈 캔버스에서 제일 빨랐지만 컨벤션을 겉돌았고, 커서는 앵커를 주면 결이 맞았고, 클로드코드는 힌트 없이 구조를 읽어 맞췄습니다. 맨바닥은 코덱스, 기존에 얹기는 커서·클로드코드. 그리고 무엇을 쓰든 "우리 관례로 만들었는지" 검수는 사람 몫입니다.

함께 보면 좋은 글

같은 버그, 세 도구에 다 시켜봤다 (디버깅 편)
Cursor Composer 완전 정리 (멀티파일 수정)
Cursor Rules 완전 정리 (관례를 규칙으로)

참고 자료

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