【AI 에이전트 비교 실험】#1 Claude Code에 태스크 관리 앱을 만들게 했더니 어떻게 되었나

1. TL;DR

동일한 과제(태스크 관리 앱)를 만들게 하는 실험에서, Claude Code는 다음과 같은 결과를 보였습니다.

지표	실험 A (상세 사양)	실험 B (최소 사양)
개발 시간	4분 (6개 에이전트 중 공동 최속)	6분
대화 횟수	18회	22회
공통 테스트 합격률	24/24 (전부 합격)	11/11 (전부 합격)
정성 평가 (인간, 25점 만점)	23/25	22/25
실험 A 종합 (90점 만점·리뷰 제외)	85.0점 / 6개 에이전트 중 1위	―

속도와 품질의 양립: 공동 최속인 4분 만에, 공통 테스트는 수정 없이 단번에 전 항목 합격했습니다. 실험 A 단독 종합 스코어에서는 6개 에이전트 중 1위를 차지했습니다. -
메타 인지(Meta-cognition)가 안정적: 자기 평가와 인간 평가의 평균 차이는 실험 A에서 0.00, 실험 B에서 -0.20이었습니다. 큰 과대/과소 평가는 없었습니다 (단, 항목 단위에서는 ±1의 차이가 있습니다. 후술).
리뷰어로서도 일관됨: 상호 코드 리뷰(Code Review)에서는 평가 축이 기술적으로 구체적이었으며, 동일한 대상에 대해 실험 A와 B에서 같은 점수를 부여하는 등 기준이 안정적이었습니다.

추천도 (개인적인 결론): "빠르고, 사양에 충실하며, 나중에 읽기 좋은 코드를 단번에 내놓길 원한다"는 용도에는 솔직하게 추천할 만한 결과였습니다. 반면, 정교한 UI나 대량의 프론트엔드 구현을 기대한다면 다른 선택지도 있습니다 (이유는 후술).

2. 에이전트 개요

에이전트: Claude Code (Anthropic 공식 CLI형 코딩 에이전트) -
모델: Claude Opus 4.8 -
실행 환경: 터미널을 통한 대화. 파일 편집, 커맨드 실행, 테스트 실행까지 에이전트가 자율적으로 수행.

실험 과제는 모든 에이전트 공통으로 "FastAPI + SQLite + Vue 3로 태스크 관리 앱 만들기"입니다. 실험은 성격이 다른 여러 세션으로 나뉘어 있습니다.

실험 A: 상세 사양서 있음. 사양에 대한 충실도와 코드 품질을 확인.
실험 B: 최소 사양 + 자유 설계. plan.md (설계 방침)를 직접 작성한 후 구현.
실험 D: 다른 에이전트의 구현에 대해 직접 만든 테스트를 적용하여 검증 (타자 테스트 수정).
실험 E: 다른 에이전트의 결과물을 상호 코드 리뷰.

채점은 공통 테스트 (외부에서 실행하는 자동 테스트)의 합격 개수와, 인간 리뷰어에 의한 5개 항목 (가독성·에러 처리·UI 완성도·문서화·테스트 망라성)의 정성 평가로 이루어집니다.

3. 실험 A 결과 (상세 사양)

개발 시간·대화 횟수

항목	값
개발 시간	4분
...
6개 에이전트의 개발 시간은 최속 4분 (Claude Code·Antigravity CLI)부터 최장 20분 (Antigravity IDE)까지 5배의 차이가 있었으며, Claude Code는 그 최속 그룹에 속했습니다. 대화 횟수 18회는 중간 정도입니다 (최소는 Codex 계열의 3회, 최대는 Copilot Agent의 25회).

테스트 합격률

공통 테스트는 24/24로 전 항목 합격했습니다. 내역은 다음과 같습니다.

• 백엔드 18개: 수정 없이 단번에 합격
• 프론트엔드 6개: 셀렉터(Selector)의 경미한 조정을 거쳐 전 항목 합격

프론트엔드에서 조정이 필요했던 것은 코드 품질의 문제라기보다 "일본어 UI에 대한 자동 테스트 적용의 어려움"이 원인이었습니다. 이는 후술할 "궁금한 점"에서 구체적으로 기술하겠습니다.

코드의 특징·경향

SQLAlchemy ORM을 채택. 우선순위 정렬 순서 (low < medium < high)를 case 식으로 표현하는 등, 구조화된 백엔드 설계였습니다. -
프론트엔드는 카드형 레이아웃. 우선순위에 따라 왼쪽 보더 색상을 변경하는 (높음=빨강·중간=주황·낮음=초록) 디자인이며, 기한이 지난 태스크에는 전용 배지가 표시됩니다. -
"완료된 태스크는 기한 만료 경고 대상에서 제외한다"와 같은 사양 판단의 이유가 코드 주석으로 명시되어 있었습니다.

• 유효성 검사(Validation) 에러를 FastAPI 표준의 detail 배열 형식에 맞춰 정형화하는 formatApiError를 프론트 측에 준비하는 등, API 연동을 의식한 구조였습니다.

실험 A (상세 사양)의 구현 화면. 카드형 레이아웃으로, 우선순위에 따라 왼쪽 보더 색상이 변한다.

자발적 테스트는 23개로, 정상계(Normal case)·이상계(Abnormal case)·경계값(Boundary value)을 1테스트 1어설션(Assertion)으로 분해하는 세밀한 구성이었습니다(생성·취득·필터 정렬·갱신·삭제의 각 작업에 대해, 검증(Validation) 패턴도 개별적으로 테스트).

정성 평가 (인간, 5점 만점)

가독성	에러 처리	UI 완성도	문서화	테스트 망라성	합계
5	5	4	4	5	23/25

실험 계획서의 배점(테스트 20·시간 10·가독성 10·에러 15·UI 15·문서 10·망라성 10, 리뷰 제외 90점 만점)으로 산출하면 종합 85.0점으로 6개 에이전트 중 1위였습니다.

참고로, 톱(85.0점)과 최하위(Codex CLI 68.6점)의 차이인 16.4점 중 절반 가까이가 개발 시간 점수 차이(10.0 vs 5.6)로 설명됩니다. 공통 테스트는 6개 에이전트 중 5개가 18~20점으로 높은 수준에서 비슷하게 나타났기 때문에, 차이가 벌어진 것은 주로 개발 시간·UI 완성도·문서화였습니다. Claude Code는 '속도'에서 큰 점수를 얻은 형태입니다.

좋았던 점

• 사양서에 대한 충실도가 높아, 백엔드 공통 테스트를 한 번에 모두 통과함.
• docstring이나 판단 이유 주석이 잘 정리되어 있어, 나중에 읽어도 의도를 파악할 수 있음.
• 빠름(최속 타이)에도 불구하고 품질이 떨어지지 않음.

아쉬웠던 점

실험에서 가장 흥미로웠던 점은, 프론트엔드 공통 테스트에서 발생한 '갱신(更新)'이라는 단어의 다의성 문제입니다.

Claude Code의 저장 버튼은 편집 시 "갱신하기(更新する)"라는 레이블이 됩니다. 테스트 원본은 당초 保存|save라는 정규 표현식으로 저장 버튼을 찾고 있었기 때문에, 이를 검출하지 못하고 타임아웃되었습니다.

<button type="submit" class="btn btn-primary">
{{ editingId ? '更新する' : '追加する' }}
</button>

흥미로운 점은, 다른 에이전트(Codex CLI)에서는 반대 방향의 문제가 발생했다는 점입니다. 그쪽은 정규 표현식에 '갱신'을 포함하면, 헤더에 있는 목록 재취득 버튼('갱신')에 잘못 매칭(Mis-match)되는 충돌이 있었습니다. 같은 '갱신'이라는 단어가 에이전트에 따라 전혀 다른 역할의 버튼에 사용되었던 것입니다.

결과적으로 "범용적인 하나의 정규 표현식으로 모든 에이전트를 커버하는 것"은 불가능하며, 에이전트마다 파생된 셀렉터(Selector)가 필요하다는 교훈을 얻었습니다. 이는 Claude Code 고유의 결함이라기보다, 일본어 UI에 자동 테스트를 적용할 때의 어려움을 보여주는 사례입니다.

또 다른 점으로는, 상태 필터용 <select>와 폼용 <select>가 동일 페이지에 병존하여, .first로 폼 쪽을 잘못 잡는 문제도 있었습니다(이 부분은 부모 요소의 클래스명으로 범위를 좁혀 해결).

4. 실험 B 결과 (최소 사양 + 플래닝)

실험 A와의 차이

실험 B는 "최소 사양 + 자유 설계"입니다. plan.md를 직접 작성한 후 구현합니다.

항목	실험 A	실험 B
개발 시간	4분	6분
...

주목할 만한 차이가 몇 가지 있습니다.

1. ORM을 버리고 표준 sqlite3로 전환했다. 실험 A에서는 SQLAlchemy ORM을 사용했지만, 실험 B에서는 표준 라이브러리인 sqlite3를 채택했습니다. plan.md에 "학습·데모 용도도 겸하므로 의존성을 최소화한다"라고 명시되어 있으며, 이는 의존성 축소라는 설계 방침에 따른 판단입니다(정렬 키는 화이트리스트 검증을 통해 SQL 인젝션(SQL Injection)을 방지). 동일한 에이전트라도 과제의 성격에 따라 설계 판단을 바꾸고 있음을 알 수 있습니다.

2. 기능은 늘어났지만, UI의 장식은 절제되었다. 실험 B에서는 검색 바·통계 표시·정렬(생성일/기한/우선순위/제목)까지 추가했습니다. 반면, 실험 A에 있었던 우선순위별 왼쪽 보더 색상 구분이나 기한 만료 전용 배지와 같은 시각적 강조는 절제되어 UI가 체크리스트형으로 바뀌었습니다. plan.md에 기한 만료의 시각적 강조에 대한 언급이 없으므로, 의도적인 선택과 집중으로 읽힙니다. 인간 평가에서도 UI 완성도는 실험 A=4에서 실험 B=3으로 낮아졌습니다.

실험 B(최소 사양 + 플래닝)의 구현 화면. 체크리스트형이며 검색·통계 표시를 갖추고 있는 반면, 색상 구분 등의 시각적 강조는 절제되어 있음.

3. 자발적 테스트는 실험 A·B 모두 20개 대에서 안정적이었다. 실험 A에서는 23개, 실험 B에서는 22개로, 공통 테스트 개수(실험 A는 18개라는 '모범 사례'가 있었고, 실험 B는 사양을 스스로 설계함)와 관계없이, 정상계(Normal case)·이상계(Abnormal case)·경계값(Boundary value)을 1 테스트당 1 어서션(Assertion)으로 분해하는 세밀한 설계(Fine-grained design)를 일관되게 유지했습니다(참고로 Codex CLI는 반대로 A=6개 $\rightarrow$ B=4개로 소수 구성을 유지하고 있어, 테스트 설계에 임하는 태도는 에이전트마다 상당히 다릅니다).

실험 B 단독으로도 공통 테스트 11/11 · 자발적 테스트 22/22로 전 항목 합격하며, 품질 면의 안정감을 유지했습니다.

정성 평가 (인간, 5점 만점)

가독성	에러 처리	UI 완성도	문서화	테스트 망라성	합계
5	5	3	4	5	22/25

5. 자기 평가 격차 (과대/과소 평가 경향)

이 실험에서는 각 에이전트에게 자신의 결과물을 5개 항목으로 자기 채점하게 한 뒤, 인간 평가와의 차이(ai_self $-$ human)를 구했습니다. Claude Code의 결과는 다음과 같습니다.

실험 A 평균 차이	실험 B 평균 차이	분류
Claude Code	0.00	-0.20

6개 에이전트를 통틀어 보아도, 과대 평가 경향(Antigravity CLI +0.80)부터 과소 평가 경향(Codex CLI -1.20)까지 분포가 있는 가운데, Claude Code는 중앙 부근의 '양호' 그룹이었습니다.

단, 평균이 0에 가깝다고 해서 = 오차가 없다는 뜻은 아닙니다. 항목 단위로는 $\pm 1$의 오차가 여러 개 존재하며, 그것들이 상쇄되어 평균이 0.00이 된 것뿐입니다. 솔직하게 공개하겠습니다.

실험 A (ai_self $\rightarrow$ human)

항목	자기 평가	인간 평가	차이
가독성	5	5	0
...

실험 B (ai_self $\rightarrow$ human)

항목	자기 평가	인간 평가	차이
가독성	4	5	$-1$ (과소)
...

경향성으로 보이는 것은, UI 완성도와 문서화를 스스로 조금 높게 산정하고, 가독성·에러 처리·테스트 망라성은 반대로 낮게 산정한다는 점입니다. 특히 UI 완성도는 실험 A·B 모두에서 +1의 과대 평가였습니다. "내 UI는 어느 정도 정돈되어 있다"라는 자기 인식이 인간 평가보다 한 단계 느슨했던 것입니다. 이는 실험 B에서 실제로 UI 평가가 3까지 떨어진 것과 함께 읽어보면, UI는 Claude Code의 상대적인 약점이라고 할 수 있습니다.

반면 좋았던 점은, 만점을 준 항목에서도 구체적인 약점을 병기했다는 것입니다. 예를 들어 가독성을 5/5로 주면서도 "title.strip()이 schemas와 main에서 중복되어 장황함", 테스트 망라성을 4/5로 주면서도 "due_date가 NULL일 때의 정렬 순서 등 경계값은 미검증"이라고 적었으며, 실험 B에서는 "A·B 양 실험 공통의 최대 개선 여지는 프론트엔드 자동 테스트가 전무하다는 점"이라며 실험을 관통하는 자기 분석까지 덧붙였습니다. 점수의 엄격함에는 차이가 있으나, 메타인지(Metacognition)의 방향성 자체는 안정적이었다고 할 수 있습니다.

참고로, 6개 에이전트 중 실험 A·B 간의 자기 평가 방향이 '역전'으로 분류된 것은 Claude Code뿐이었으나(0.00 $\rightarrow$ -0.20), 차이는 매우 작아 실질적으로는 두 실험 모두 양호한 범위입니다.

6. 리뷰어로서의 실력 (실험 E로부터)

실험 E에서는 타 에이전트의 결과물을 상호 리뷰했습니다 (자기 자신은 대상에서 제외). Claude Code의 리뷰에는 다음과 같은 특징이 있었습니다.

• 평가 축이 기술적으로 구체적이고 일관됨. 타입 안정성(Type safety) · DRY · 인덱스 · UTC 대응 · 테스트 망라성 등 관찰 가능한 관점에서 차이를 두었습니다.
• 횡단적 요약(Cross-cutting summary)을 자발적으로 작성. 개별 지적과는 별도로 "모든 타겟 공통의 경향"을 정리하였는데, 이는 다른 리뷰어들에게서는 볼 수 없는 구성이었습니다.
• 강약 조절이 있는 평가. 보안(XSS/SQLi)에 대해서는 "치명적인 취약성 없음"이라고 단정 짓는 한편, 집계 버그 · 명명 규칙 · 검증의 비관습성 같은 설계 수준의 거친 부분은 세밀하게 지적했습니다.

실기 검증에서 가치가 있었던 것은, 구현 당시에는 알아채지 못했던 버그를 발견했다는 점입니다. 실험 B의 리뷰에서는 여러 에이전트가 채택한 생(raw) sqlite3

구현 방식에서 공통적으로 나타나는 "with sqlite3.connect()가 연결을 close하지 않고 (commit만 수행하는) 리소스 누수(resource leak)"를 "가장 실질적인 해를 끼치는 버그"로 지적했습니다.

평가 기준의 안정성을 보여주는 데이터도 있습니다. Codex IDE의 구현에 대해, 과제 조건이 다른 실험 A와 실험 B 모두에서 동일하게 "9점"을 부여했습니다.

한편, 리뷰가 "절대적으로 옳다"는 것은 아니라는 점도 확인되었습니다. 동일한 Antigravity IDE 구현에 대해, Antigravity CLI는 9.0점, Claude Code는 7점으로 2점 가까운 차이가 났습니다. 전체적으로 Claude Code는 일부 대상에 대해 Antigravity CLI보다 1.5~2.0점 높게 책정하는 경향이 있었습니다. 어느 쪽이 정답이라고 단정할 수는 없지만, 단일 리뷰어의 점수를 맹신하지 말고 여러 명의 평균을 취해야 한다는 실험 E의 의도대로 이를 뒷받침하는 결과가 되었습니다.

(보충) 실험 D(타인 테스트 수정)에서는 지시문 제약을 끝까지 준수하여, 6개의 에이전트 중 지시 위반이 확인되지 않은 3개 중 하나였습니다. 다만 자신이 작성한 UI 테스트의 정규 표현식에 "갱신"을 포함하는 바람에, 대상 헤더에 있는 다른 "갱신" 버튼과 잘못 매칭되어 테스트를 실패하게 만드는 결함이 1건 있었습니다. 실험 A에서 자신이 겪었던 것과 동일한 "갱신" 문제를 리뷰 측에서도 겪은 형태입니다.

7. 종합 평가

데이터를 나열하면 Claude Code의 윤곽은 다음과 같습니다.

강점

• 속도: 실험 A와 B 모두 최속 그룹(4분, 6분).
• 사양 충실도 및 테스트 통과: 공통 테스트는 실험 A에서 24/24, 실험 B에서 11/11로 전원 합격. 백엔드는 단번에 통과.
• 가독성·문서화·테스트 커버리지: 인간 평가에서 모두 높은 점수(대부분 5점).
• 메타 인지(Metacognition)의 안정성: 자기 평가 격차는 평균 0 내외이며, 만점 항목에도 약점을 병기하는 일관성.
• 리뷰어로서의 기준 안정성: 동일 대상에 동일한 점수를 부여하는 일관성과 실질적인 버그를 찾아내는 구체성.

약점·주의점

• UI 완성도가 상대적인 약점: 인간 평가는 실험 A=4, 실험 B=3. 자기 평가에서는 두 실험 모두 +1점 정도 낙관적으로 예측함. 장식보다는 로직에 치중하는 경향.
• 프론트엔드 자동 테스트 부재: 실험 A와 B 모두에서 프론트엔드 E2E 자동 테스트가 미구현됨(자기 신고에서도 가장 큰 개선 여지로 인정함).
• 항목 단위로는 자기 평가에 ±1의 편차가 있음: 평균 0은 상쇄된 결과이며, 오차가 없다는 뜻은 아님.

종합 점수(실험 A 단독·리뷰 제외 90점 만점)에서는 85.0점으로 1위를 차지했지만, 그 우위의 상당 부분은 "속도"에서 기인합니다. 공통 테스트 합격률은 최상위 그룹이 비슷했기 때문에, 속도를 가치로 간주하느냐에 따라 평가가 달라집니다. "어쨌든 빠르게, 사양대로 작성된 읽기 좋은 코드가 필요하다"면 강력한 선택지이며, "프론트엔드의 완성도나 대량의 UI 구현을 중시"한다면 프론트엔드 코드 라인이 1,000행을 넘었던 Antigravity 계열 등 다른 경향을 가진 에이전트도 검토할 가치가 있습니다(본 실험의 데이터 범위 내에서의 이야기입니다).

8. 이런 분께 추천합니다

• 사양서가 어느 정도 확정되어 있고, 이에 충실한 구현을 빠르게 얻고 싶은 분. 백엔드 공통 테스트 단번에 합격 및 최속 타이 기록은 이 용도에 적합합니다.
• 나중에 읽거나 인계받을 코드를 중시하는 분. docstring, 판단 이유 주석, README 정비 측면에서 높은 평가를 받았습니다.
• "자신이 작성한 코드의 약점도 파악해두고 싶은" 분. 만점 항목에서도 약점을 병기하는 자기 분석은 리뷰의 근거로 활용할 수 있습니다.
• 코드 리뷰의 일부를 맡기고 싶은 분. 평가 축이 구체적이며, 실질적인 해를 끼치는 버그(리소스 누수 등)를 잡아냈습니다. 다만 점수는 다른 리뷰어와 차이가 날 수 있으므로, 여러 의견 중 하나로 취급하는 것이 안전합니다.

반대로, 정교한 UI나 대량의 프론트엔드 구현을 최우선으로 하고 싶다면, UI 완성도가 상대적인 약점이라는 점과 프론트엔드 자동 테스트가 없다는 점을 고려하여 다른 선택지와 비교해 보시는 것을 권장합니다.

9. 관련 기사

본 기사는 6개의 AI 코딩 에이전트 비교 실험 시리즈 중 하나입니다 (Zenn 제1회).

시리즈 전체 기사 목록은 GitHub 리포지토리를 참조해 주세요.

Discussion