GPT-5.5와 Claude-Opus-4.8도 ‘흐릿한 요구사항’에서 프로젝트를 완성하지 못한다. 480개 과제, 12개 언어, 세 가지 모호도 수준에서 실험한 ICAE-Bench는, 바이브 코딩(vibe coding) 시대의 코딩 에이전트가 여전히 ‘보이는 동작’은 재현하지만 ‘숨겨진 제약’과 ‘긴 호라이즌 통합’에서 붕괴한다는 것을 보여준다.
그림 1: ICAE-Bench의 핵심 설정. 모호한 요구사항(fuzzy PRD)에서 출발해, 코딩 에이전트가 User Agent에게 질문하며 숨겨진 제약을 복원하고, 최종적으로 실행 가능한 저장소를 만든다.
Q. “바이브 코딩”이 뭔가요? 기존 코딩 에이전트 벤치마크와 뭐가 다르죠?
바이브 코딩은 사용자가 불완전한 의도만 던지고, 코딩 에이전트가 그것을 캐묻고, 계획하고, 도구를 쓰고, 디버깅해서 실행되는 소프트웨어로 바꾸는 작업 방식을 말한다. “파일 파서 하나 만들어 줘”라고만 하면, 에이전트가 “어떤 포맷이요? 에러 처리는? 엣지 케이스는?”을 스스로 물어봐야 한다.
기존 벤치마크는 달랐다. SWE-bench는 이슈를 해결하는 패치를, HumanEval은 함수를, ProgramBench는 실행 파일에서 프로그램을 복원하는 것을 요구했다. 공통점은 요구사항이 이미 완전하게 주어진다는 가정이다. ICAE-Bench의 저자들은 이것이 현실과 다르다고 본다. 실제 사용자는 요구사항을 다 말하지 않는다.
Q. ICAE-Bench는 구체적으로 어떤 과제를 내나요?
각 과제는 실제 오픈소스 저장소에서 출발한다. 원본 코드와 테스트가 Docker에서 실행되는 것을 확인한 뒤, 다음 단계를 거친다:
- GroundPRD 합성: 저장소의 동작에서 상세한 제품 요구사항 문서(PRD)와 블랙박스 테스트 케이스를 추출한다.
- PRD 흐릿화(fuzzification): GroundPRD에서 선택한 제약(엣지 케이스, API 형식, 아키텍처 등)을 숨긴다. 숨겨진 정보는 User Agent Data에 보관한다.
- 얼티밋 이미지 패키징: 정답 코드와 테스트를 제거하지만 런타임 환경은 보존한 Docker 이미지를 만든다.
- 검증: 생성된 산물물의 의미적·실행 일관성을 확인한다.
그림 2: ICAE-Bench 파이프라인. 저장소 필터링 → GroundPRD 합성 및 테스트 리팩토링 → PRD 흐릿화 → 얼티밋 이미지 패키징 → 산물 검증의 5단계.
이렇게 만들어진 과제는 480개, 12개 프로그래밍 언어를 span한다. Python뿐 아니라 C++, Go, Rust, TypeScript, Kotlin, PHP, Ruby, Dart, C#, JavaScript까지 포함된다.
그림 4: 480개 과제의 카테고리 분포. CLI 도구, 파서, 웹 앱, 데이터 처리 등 다양한 도메인을 포함한다.
그림 5: 원본 저장소의 코드 라인 수 분포. 대부분 50–500 라인 사이지만, 일부는 1000라인을 넘는다.
Q. “모호도 수준”은 어떻게 정하나요?
ICAE-Bench는 같은 과제에 대해 세 단계의 흐릿함을 정의한다:
- L1: 가장 적은 정보. 핵심 동작만 설명하고, 엣지 케이스·포맷·아키텍처는 모두 숨김.
- L2: 일부 모호점을 복원. 중요한 제약 일부를 드러냄.
- L3: 대부분의 GroundPRD를 유지하되, 제한된 세부사항만 제거.
- GroundPRD: 완전히 명시된 참조 요구사항 (상한선).
그림 3: L1 → L2 → L3 → GroundPRD로 갈수록 에이전트가 초기에 보는 정보가 풍부해진다.
이 설계의 핵심은 **“흐릿함이 현실적이어야 하되, 평가는 정확해야 한다”**는 것이다. 모호한 요구사항에서 시작하되, User Agent를 통해 숨겨진 제약을 복구할 수 있고, 최종 결과물은 정확한 블랙박스 테스트로 평가한다.
Q. User Agent는 어떤 역할을 하며, 왜 통제해야 하나요?
코딩 에이전트가 모호한 요구사항을 만나면 User Agent에게 질문할 수 있다. User Agent는 자유롭게 대답하는 LLM이 아니다. 벤치마크가 작성한 요구사항 기록(User Agent Data)에서만 답변한다.
이 제약이 중요한 이유는:
- 새 요구사항 발명 방지: User Agent가 자의로 새 기능을 추가하면 평가가 무의미해진다.
- 구현 유출 방지: 정답 코드를 그대로 알려주면 코딩 에이전트의 능력을 측정할 수 없다.
- 재현성 보장: 동일한 질문에 동일한 답변이 보장되어야 실험이 재현 가능하다.
User Agent는 Public 케이스(예시 입출력)와 숨겨진 제약(엣지 케이스, 포맷 요구사항)을 상황에 맞게 공개한다. 코딩 에이전트는 이 정보를 요구사항으로 보존하고 구현에 반영해야 한다.
Q. 결과는 어땠나요? 최고 모델도 못 했나요?
못 했다. Claude-Opus-4.8이 전체 벤치마크에서 Overall 38.2%, GPT-5.5가 37.2%에 그쳤다. Public 케이스(가시적) 통과율은 각각 48.5%, 50.3%이지만, Hidden 케이스(숨겨진 엣지 케이스)에서는 35.5%, 32.8%로 추락한다.
그림 6: 모호도 수준별 합격률. L1→L3→GroundPRD로 갈수록 정보가 풍부해지지만, 합격률 상승은 선형적이지 않다.
그림 6 상세: RecoveredPRD(대화로 복구한 요구사항)와 GroundPRD(완전 명시) 사이에는 여전히 큰 갭이 있다.
가장 중요한 발견은 **“더 많은 정보에 접근해도 합격률이 일관되게 오르지 않는다”**는 것이다. GroundPRD(완전 명시)는 여전히 강한 상한선이며, 대화를 통해 요구사항을 복구(RecoveredPRD)해도 그 상한선에 미치지 못한다.
Q. 질문을 많이 하면 더 잘하나요?
아니다. 질문 양과 합격률은 비례하지 않는다. 저자들은 “높은 제약 커버리지(질문으로 더 많은 제약을 알아냄)가 자동으로 더 높은 합격률로 이어지지 않는다”고 명시한다.
그림 7: 요구사항 토큰 사용량 비교. 더 많은 요구사항을 알아냈다고 해서 더 정확한 코드가 나오지는 않는다.
문제는 정보 획득이 아니라 정보 활용에 있다. 코딩 에이전트가 User Agent에게서 들은 제약을 컨텍스트에 보존하고, 그것을 실제 구현 결정에 반영하고, 검증까지 이어가는 능력이 부족하다. 이것은 단순한 메모리 용량 문제가 아니라, 요구사항-구현-검증의 일관성 루프(coherent loop)를 유지하는 능력의 문제다.
Q. 어떤 모델을 비교했고, 언어별로 차이가 있나요?
6개 모델을 Claude Code와 OpenHands 두 에이전트 프레임워크에서 평가했다:
| 모델 | Overall | Public | Hidden | Semantic | API | Design |
|---|---|---|---|---|---|---|
| Claude-Opus-4.8 | 38.2 | 48.5 | 41.4 | 35.5 | 22.6 | 12.1 |
| GPT-5.5 | 37.2 | 50.3 | 42.0 | 32.8 | 21.5 | 9.3 |
| Gemini-3.1-Pro | 27.0 | 37.0 | 30.7 | 23.5 | 18.9 | 8.9 |
| GLM-5.1 | 26.6 | 36.8 | 30.0 | 23.7 | 21.1 | 10.0 |
| Claude-Sonnet-4.6 | 21.8 | 29.0 | 24.1 | 19.4 | 22.9 | 10.1 |
| MiniMax-M2.5 | 0.8 | 1.5 | 1.2 | 0.6 | 11.8 | 5.5 |
언어별로는 C#(39.9%), TypeScript(43.7%), Rust(40.3%)에서 Claude-Opus-4.8이 강세를 보이고, GPT-5.5는 PHP(42.2%), Ruby(41.4%)에서 앞선다. 흥미롭게도 Design 점수는 모든 모델에서 매우 낮다 (5.5–12.1%) — 에이전트가 만든 코드는 동작할 수 있지만, 설계 품질은 기대 이하라는 의미다.
Q. 에이전트 프레임워크(Claude Code vs OpenHands)는 결과에 영향을 주나요?
준다. Claude Code가 OpenHands보다 전반적으로 안정적이며, 특히 파일 관리와 도구 오케스트레이션에서 유리하다. 하지만 OpenHands의 멀티 에이전트 구조가 일부 과제에서 더 나은 결과를 내기도 한다.
프레임워크의 핵심 역할은 실행 가능한 Public 케이스(예시 입출력)를 제공하는 것이다. Public 케이스가 실행 가능할 때, 에이전트는 이를 테스트로 활용해 검증 루프를 만들 수 있다. 저자들은 “실행 가능한 Public 케이스가 materially한 정확도 향상을 가져온다”고 결론짓는다.
Q. 사고(thinking) 모드와 실행 환경은 어떤 영향을 주나요?
Gemini-3.1-Pro에서 사고 모드를 켜면 Overall이 26.7% → 36.6%로 10포인트 상승한다. GLM-5.1에서도 적응적 사고 할당이 think-8k 고정보다 37.4% → 40.0%로 향상된다. 숙고(deliberation)는 실질적으로 도움이 된다.
하지만 실행 환경이 풍부할수록 역효과가 난다. 더 많은 의존성을 제공하는 얼티밋 이미지에서 GLM-5.1의 Overall이 37.4% → 28.4%로 하락했다. 이유는: 더 많은 의존성이 주어지면 에이전트가 더 복잡한 설계를 시도하고, 파일 수는 191%, LOC는 674%로 폭발하지만, 각 추가 모듈과 인터페이스는 새로운 실패 지점이 되기 때문이다. 더 많은 도구가 더 나은 결과로 이어지는 것은 아니다.
Q. 다른 언어로 구현하면 어때요? (언어 간 일반화)
ICAE-Bench의 블랙박스 테스트는 언어 비의존적이다. 그래서 Python이 아닌 과제를 Python으로 재구현해 볼 수 있다. 결과: 비-Python → Python으로 바꾸면 Overall이 26.6% → 29.9%로 소폭 상승하지만, 언어별 효과는 섞여 있다.
이것은 언어 간 구현이 가능하지만, Python이 항상 유리한 것은 아님을 시사한다. 과제의 원래 언어가 더 자연스러운 구현 경로를 제공하는 경우가 많다.
Q. 핵심 인사이트는 뭔가요? 코딩 에이전트가 발전하려면 무엇이 필요한가요?
ICAE-Bench가 드러내는 가장 중요한 패턴은 **“정보 접근성 ≠ 정보 활용성”**이다:
- 요구사항 복구 ≠ 구현 성공: User Agent를 통해 더 많은 제약을 알아내도, 그것을 코드에 정확히 반영하지 못한다.
- 보이는 동작 ≠ 숨겨진 제약: Public 케이스는 통과하지만 Hidden 케이스에서 무너진다. 에이전트는 보이는 예시에 최적화하고, 숨겨진 엣지 케이스를 놓친다.
- 더 풍부한 환경 ≠ 더 나은 코드: 의존성이 많아지면 오히려 액션 공간이 분산되어 실패가 늘어난다.
- 사고 모드는 유효하지만 충분하지 않다: 숙고는 도움이 되지만, 요구사항-구현-검증 루프를 유지하는 것은 별개의 능력이다.
저자들이 제시하는 나아갈 방향은, 정보를 행동 가능하게(actionable) 만드는 에이전트 설계다. 명확화된 제약을 컨텍스트에 보존하고, 구현 결정에 연결하고, 끝까지 검증하는 능력. 이것은 단순한 컨텍스트 윈도우 크기 문제가 아니라, 에이전트 하네스(harness, 에이전트를 둘러싼 실행 프레임워크)의 아키텍처 문제다.
📄 논문: Zhongyuan Peng et al., “ICAE-Bench: Evaluating Coding Agents as Interactive Project Builders,” arXiv:2607.21217, 2026. 논문 보기 · 코드 & 데이터
더 실습해보고 싶은 분들께
코딩 에이전트에게 요구사항을 캐묻고, 보존하고, 구현에 반영하게 만드는 것 — 이 전체 루프를 직접 실험해보고 싶다면 다음 두 가지를 추천합니다:
- 『이게 되네? 오픈클로 미친 활용법 50제』 — 에이전트 하네스와 도구 사용 루프를 실제로 구성하고 활용하는 50가지 패턴
- 「모두를 위한 루프 엔지니어링」 — 요구사항-구현-검증 루프를 설계하고 최적화하는 실무 강의
ICAE-Bench가 보여주는 교훈은 분명하다. 코딩 에이전트의 다음 경쟁은 “코드를 잘 짜는 것”이 아니라 “요구사항을 끝까지 살려내는 것”이다.