1. TL;DR

항목	결과
실험A 개발 시간	12분
...
Codex IDE 확장은 상세 사양을 전달한 실험A에서도, 최소 사양으로부터 설계를 수행한 실험B에서도 공통 테스트를 모두 통과했습니다. 대화 횟수도 적고 구현 속도와 안정감이 있습니다.

반면, 실험A의 결과물에는 PUT 부분 업데이트 시 title이 암묵적으로 필수화되는 중대한 버그가 남아 있었습니다. 공통 테스트는 모두 통과했음에도 불구하고 이 버그는 검출되지 않았습니다. 게다가 자기 평가에서도 이 버그에 대해서는 전혀 언급하지 않았으며, 테스트 커버리지(Test Coverage)를 4/5로 평가했습니다.

이 결과는 AI 에이전트 평가에서 흔히 발생하는 "테스트를 통과했으니 품질이 높다"라는 단편적인 판단을 매우 명확하게 부정하는 사례가 되었습니다.

2. 에이전트 개요

이번 대상은 IDE 상에서 동작하는 Codex 계열의 코딩 에이전트입니다. 이 기사에서는 편의상 "Codex IDE 확장"이라고 부릅니다.

동일한 비교 실험에는 Codex CLI도 포함되어 있습니다. 두 가지 모두 동일한 Codex 계열의 에이전트로 비교하고 있으나, 자료상 구체적인 모델명이나 계약 플랜명은 명시되어 있지 않습니다. 따라서 본 기사에서는 모델 고유의 성능 비교가 아니라, 이 실험 환경에서의 Codex IDE 확장이라는 이용 형태에 대한 관측 결과로서 다룹니다.

과제는 모든 에이전트 공통으로 FastAPI + SQLite + Vue 3를 이용한 태스크 관리 앱입니다. 실험은 주로 다음 4가지 종류입니다.

• 실험A: 상세 사양을 전달하여 구현
• 실험B: 최소 사양을 전달하여 설계부터 구현
• 실험D: 타 에이전트의 결과물에 대해 자체 제작한 테스트를 적용하여 수정
• 실험E: 타 에이전트의 결과물을 상호 코드 리뷰(Code Review)

3. 실험A 결과: 상세 사양을 전달했을 경우

실험A에서는 상세한 사양서를 전달하여 태스크 관리 앱을 구현하게 했습니다.

항목	결과
개발 시간	12분
...
숫자만 보면 상당히 좋은 결과입니다. 공통 테스트는 수정 없이 모두 통과했으며, 대화 횟수도 적은 편이었습니다. 코드도 비교적 읽기 쉬웠고 사양 추종성(Specification Compliance)도 높은 편이었습니다.

하지만 이 "전부 통과"가 구현 품질을 그대로 의미하지는 않았습니다.

PUT 부분 업데이트의 중대한 버그

실험A의 결과물에는 PUT /tasks/{id}에서 부분 업데이트가 불가능한 중대한 버그가 있었습니다.

원인은 업데이트용 스키마(Schema)가 생성용 스키마를 그대로 상속받았기 때문입니다.

class TaskUpdate(TaskBase):
    pass

이 설계에서는 TaskBase 측에서 필수였던 title이 업데이트 시에도 필수인 상태로 남게 됩니다. 그 때문에 예를 들어 상태(status)만 업데이트하고 싶은 다음과 같은 요청이 실패합니다.

{"status": "doing"}

실제로 title을 포함하지 않는 PUT 요청에 대해 422 Field required가 반환되는 것이 확인되었습니다.

문제는 공통 테스트에서 이 결함을 검출하지 못했다는 점입니다. 공통 테스트 내의 PUT 업데이트 케이스는 title을 포함한 페이로드(Payload)로 검증하고 있었습니다. 그 때문에 title이 없는 부분 업데이트라는 중요한 케이스가 누락되어 있었습니다.

즉, 실험A의 결과는 다음 두 가지를 동시에 보여줍니다.

• 공통 테스트는 24/24로 모두 통과했다
• 그러나 사양상 중요한 부분 업데이트에는 중대한 버그가 남아 있었다

이는 "테스트 통과"와 "구현 품질"이 일치하지 않는 전형적인 사례입니다. 특히 AI 에이전트에게 구현을 맡길 경우, 테스트 설계가 허술하면 에이전트가 그 빈틈을 메워 품질을 보장해 주지는 않습니다.

코드의 특징

실험A의 코드는 백엔드 152행, 프론트엔드 509행으로 비교 대상 중에서는 비교적 컴팩트했습니다. FastAPI/Pydantic을 사용한 구성으로, pytest.ini에 pythonpath = .을 설정하는 등 다른 에이전트에서 발생했던 ModuleNotFoundError 계열의 문제를 구현 단계에서 회피했습니다.

UI는 심플한 2컬럼 형태의 업무용 앱 스타일로 화려함은 절제되어 있습니다. 인간 평가에서는 가독성 5/5, 문서화 4/5로 높게 나타났습니다. 반면 UI 완성도는 3/5, 테스트 커버리지는 3/5에 머물렀습니다.

실험A(상세 사양)의 구현 화면. 2컬럼의 심플한 업무용 앱 스타일 레이아웃.

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

실험B에서는 상세 사양이 아닌 최소 사양을 전달하고, 에이전트 스스로 설계한 뒤 구현하도록 했습니다.

항목	결과
개발 시간	11분
...
실험A보다 사양의 자유도가 높음에도 불구하고, 공통 테스트는 16/16으로 전 항목 합격했습니다. 자체 테스트도 9/9로 통과했습니다.

실험B(최소 사양 + 플래닝)의 구현 화면. 실험A와 마찬가지로 심플한 구성을 유지.

실험B에서는 실험A에서 발생했던 PUT 부분 업데이트(Partial Update) 버그가 발생하지 않았습니다. TaskUpdate를 독립적인 Optional 필드 중심의 스키마(Schema)로 정의하여, 부분 업데이트를 올바르게 처리하고 있었습니다.

동 계열인 Codex CLI와 비교하면, 이번 실험에서는 Codex IDE 확장 기능이 더 안정적이었습니다. Codex CLI 측에서는 다른 조건에서 동일한 종류의 PUT 부분 업데이트 버그가 확인되었습니다. 반면, Codex IDE 확장은 실험A에서는 해당 버그를 발생시켰고, 실험B에서는 이를 회피했습니다. 즉, 같은 Codex 계열이라도 사양 조건이나 설계의 자유도에 따라 구현 결과가 달라집니다.

여기서 읽어낼 수 있는 점은 "Codex IDE 확장은 항상 이 버그를 발생시킨다"도, "항상 회피할 수 있다"도 아닙니다. 더 정확하게는, 스키마 설계나 테스트 설계 조건에 따라 결과가 상당히 요동친다는 것입니다.

5. 자기 평가 격차 (Self-evaluation Gap)

Codex IDE 확장의 자기 평가 격차는 실험A에서 평균 -0.20, 실험B에서 평균 -0.40이었습니다. 수치만 보면 인간의 평가보다 약간 낮게 평가하는 경향이 있어, 과대평가 경향이 강하지는 않습니다.

하지만 실험A의 내역을 살펴보면 중요한 문제가 있습니다.

실험A의 자기 평가에서 에이전트는 테스트 커버리지(Test Coverage)를 4/5로 평가했습니다. 그 근거로 자체 테스트가 통과했다는 점, CRUD·유효성 검사(Validation)·필터·정렬·404 등을 확인했다는 점을 들었습니다.

그런데 실제로는 PUT 부분 업데이트의 중대한 버그가 남아 있었습니다. 게다가 이 버그에 대해 자기 평가에서는 전혀 언급하지 않았습니다.

이는 단순한 채점의 오차가 아닙니다. AI 에이전트가 "자신의 테스트가 통과했다"는 것을 근거로 테스트 커버리지를 높게 추정해 버린 케이스입니다.

이번 관측을 통해 Codex IDE 확장의 자기 평가에 대해 다음과 같이 판단하는 것이 타당합니다.

• 평균값으로는 극단적인 과대평가가 아니다.
• 하지만 중대한 미검출 버그에 대해 무자각한 상태로 높은 테스트 평가를 내놓을 때가 있다.
• 자기 평가는 품질 보증(QA)이 아니라, 어디까지나 보조적인 자기 신고로 취급해야 한다.

이 점은 AI 에이전트를 팀에 도입할 때 매우 중요합니다. 자기 평가 코멘트가 차분해 보일지라도, 테스트 설계의 빈틈까지 자동으로 메워주지는 않습니다.

6. 리뷰어로서의 실력

실험E에서는 다른 에이전트의 결과물에 대해 코드 리뷰(Code Review)를 수행했습니다.

Codex IDE 확장의 리뷰는 Codex CLI와 유사한 경향을 보였습니다. 실제로 pytest를 실행하여 확인하는 자세를 보였으며, 단순한 정적 읽기뿐만 아니라 직접 구동하여 판단하려고 시도했습니다.

리뷰 결과는 다음과 같습니다.

target	대상 에이전트	Codex IDE 평가
target-1	Antigravity IDE	7
...
특히 가치가 있었던 점은 Codex CLI의 결과물에 대해 PUT 부분 업데이트 문제를 지적했다는 점입니다. 이는 에이전트 자신의 실험A 결과물에도 존재했던 문제 패턴이었습니다.

반면, 리뷰에서도 오검출(False Positive)이 있었습니다. 예를 들어, 주석이나 docstring이 글자가 깨져 있다는 지적이 있었으나, 인간이 Get-Content -Encoding UTF8로 확인했을 때 실제로는 글자가 깨지지 않은 케이스가 있었습니다. PowerShell에서 읽을 때 인코딩(Encoding) 지정이 부족했을 가능성이 높습니다.

이 결과로 볼 때, Codex IDE 확장은 리뷰 대상을 직접 구동하여 확인하는 능력은 있지만, 도구 출력의 해석 미스가 리뷰 품질에 섞일 수 있습니다. 리뷰 결과를 그대로 채택할 것이 아니라, 지적 사항의 재현 절차까지 확인할 필요가 있습니다.

7. 타자 테스트 수정에서의 실력

실험D에서는 다른 에이전트의 결과물에 자신의 테스트를 적용하고, 실패 시 수정을 요구했습니다.

결과는 다음과 같습니다.

target	대상 에이전트	test_api.py	test_ui.py	지시 위반
target-1	Claude Code	17/18	5/6	없음
...

API 측은 대체로 견실했습니다. 반면, UI 테스트에서는 셀렉터 (Selector) 설계의 약점이 드러났습니다. v-model 속성이나 id가 없는 입력란에 대해 준비한 셀렉터가 일치하지 않아 타임아웃(Timeout)이 발생하는 케이스가 여러 차례 있었습니다.

더욱 중요한 것은, target-6에서 priority 순서의 기대값을 desc에서 asc로 수정하여 합격률을 높이는 지시 위반이 확인되었다는 점입니다. DELETE의 기대 상태(Expected Status)에 대해서는 제약을 준수했으나, priority 순서의 기대값을 수정했기 때문에 부분적인 위반이 되었습니다.

이는 상당히 주의해야 할 동작입니다. 테스트 수정 태스크에서는 에이전트가 '구현을 사양에 맞추는' 것이 아니라, '테스트의 기대값을 구현에 맞추는' 방향으로 움직일 때가 있습니다. 이번 Codex IDE 확장 기능은 리뷰 시에는 실측을 중시할 수 있었던 반면, 테스트 수정 시에는 합격률을 높이는 방향으로 너무 치우치는 모습이 있었습니다.

8. 종합 평가

Codex IDE 확장은 구현 에이전트로서 충분히 실용적입니다. 실험 A에서는 12분·3회 왕복으로 24/24, 실험 B에서는 11분·1회 왕복으로 16/16을 달성했습니다. 상호작용 횟수가 적고, 사양에 따라 단번에 형태를 만들어내는 능력이 있습니다.

하지만 종합 점수는 70.0점으로, 6개의 에이전트 중 5위였습니다. 공통 테스트 합격률만 따진다면 상위권과 어깨를 나란히 하지만, UI 완성도나 테스트 망라성(Test Coverage), 인간 평가에서 충분히 올라가지 못한 점이 영향을 미쳤습니다.

특히 중요한 약점은 다음 세 가지입니다.

• 공통 테스트를 모두 합격했음에도, PUT 부분 업데이트(Partial Update)의 중대한 버그를 남겼다
• 자기 평가에서 해당 중대한 버그를 인지하지 못하고, 테스트 망라성을 4/5로 평가했다
• 테스트 수정 태스크에서, priority 순서의 기대값을 수정하는 지시 위반이 있었다

장점도 명확합니다.

• 적은 상호작용으로 구현을 완료하기 쉽다
• 사양에 따른 CRUD 구현은 비교적 안정적이다
• 리뷰 시에 실제로 테스트를 실행하여 확인하는 경향이 있다
• 실험 B에서는 실험 A와 같은 PUT 부분 업데이트 버그를 회피할 수 있었다

종합하면, Codex IDE 확장은 '구현을 빠르게 진행하는 파트너'로서는 유력합니다. 다만, '테스트를 통과했으므로 품질도 괜찮다'라고 판단하기에는 위험이 있습니다. 인간 측에서 사양의 경계 조건(Boundary Condition), 부분 업데이트, NULL, 빈 문자열, 정렬 순서, 테스트 기대값의 개변과 같은 관점을 명시적으로 감독해야 합니다.

9. 이런 분들께 추천합니다

Codex IDE 확장이 적합한 케이스는 다음과 같습니다.

• 사양이 어느 정도 확정된 CRUD 앱을 단시간에 형태를 갖추고 싶다
• IDE 상에서 코드를 보면서 에이전트에게 구현을 진행시키고 싶다
• 다소 심플한 UI라도 괜찮으니, 우선 동작하는 것을 만들고 싶다
• 리뷰나 테스트 실행을 포함하여 AI에게 1차 체크를 맡기고 싶다

반대로, 다음과 같은 방식의 사용에는 주의가 필요합니다.

• 공통 테스트 합격을 그대로 품질 보증(QA)으로 취급하고 싶다
• 부분 업데이트나 경계 조건 등 사양의 세부 사항을 AI에게 전적으로 맡기고 싶다
• 테스트 수정 시, 기대값을 수정하지 않고 구현만 바로잡기를 원한다
• UI의 완성도나 시각적인 완성도를 강력하게 요구한다

이번 실험을 보는 한, Codex IDE 확장은 '구현의 초속'을 내는 데 적합합니다. 다만 마지막 품질 판단은 테스트 설계와 인간의 리뷰로 보완한다는 전제를 두는 것이 좋을 것 같습니다.

10. 관련 기사

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

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

Discussion