'100% 성공률'이라는 숫자를 보면 가장 먼저 드는 생각
'샘플 사이즈는 충분했나요? 테스트 환경은 프로덕션과 같았나요?'
최근 두 가지 사례가 ML 시스템의 성능 측정이 얼마나 복잡한 문제인지를 적나라하게 보여줬습니다. 하나는 백엔드 코드를 자동 생성하는 오픈소스 AI 에이전트 AutoBe의 성능 붕괴와 복구 이야기, 다른 하나는 구글 딥마인드의 AlphaEvolve가 인간 연구자를 넘어서는 알고리즘을 자동으로 설계했다는 발표입니다. 두 사례는 서로 다른 도메인에 있지만, '성능 수치가 무엇을 측정하고 있는가'라는 질문에서 정확히 만납니다.
AutoBe: 100%를 의도적으로 깨뜨린 팀
Wrtn Technologies가 개발한 AutoBe는 자연어로 설명하면 TypeScript + NestJS + Prisma 기반의 완전한 백엔드 애플리케이션을 생성하는 AI 에이전트입니다. 초기 버전은 컴파일 성공률 100%, E2E 테스트 통과율 near-100%를 달성했습니다. 숫자만 보면 완벽한 시스템입니다.
그런데 팀은 이 아키텍처를 전부 폐기했습니다.
이유는 단순합니다. 테스트 환경이 실제 운영 환경과 달랐기 때문입니다. 초기 아키텍처는 한국 SI 방법론을 차용해 모든 API 함수를 완전히 독립적으로 생성했습니다—코드 재사용 없음, 공유 유틸리티 없음. 컴파일러 입장에서는 각 함수를 독립적으로 검증하면 되니 오류가 없습니다. 하지만 실제 상용 프로젝트에서 요구사항이 바뀌는 순간, 50개 엔드포인트를 전부 재생성해야 했습니다. 이건 correlation이지 causation이 아닙니다—'컴파일 성공'이 '유지보수 가능한 코드'를 의미하지는 않습니다.
성능이 40%로 추락한 진짜 이유: 테스트 분포의 변화
모듈화 아키텍처로 전환하자 컴파일 성공률이 40% 아래로 떨어졌습니다. 흥미로운 점은 모델이 나빠진 게 아니라는 것입니다. 입력 분포(input distribution)가 바뀌었습니다. 코드 간 의존성이 생기면서 AI 에이전트가 이제 순환 의존성 감지, 임포트 순서 검증, 모듈 간 타입 호환성까지 처리해야 했습니다. 기존 모델이 학습되지 않은 복잡도의 영역으로 들어온 것입니다.
이것은 전형적인 데이터 드리프트(data drift) 시나리오입니다. 훈련(혹은 최적화) 단계의 데이터 분포와 운영 단계의 분포가 달라졌고, 성능이 급락했습니다.
복구 전략 분석: 스트레스 테스트와 피드백 루프
AutoBe 팀이 100%를 되찾기 위해 사용한 세 가지 전략은 ML 엔지니어링 관점에서 매우 교과서적입니다.
첫째, RAG 최적화로 컨텍스트 관리. 모듈 간 의존성 정보를 어떻게 LLM에 전달하느냐의 문제입니다. 관련 없는 컨텍스트를 줄이고 필요한 스키마 정보만 정밀하게 주입하는 방식입니다.
둘째, 약한 로컬 LLM(30B, 80B)으로 스트레스 테스트. 이 부분이 특히 인상적입니다. GPT-4급 모델로만 테스트하면 edge case를 발견하기 어렵습니다. 더 작은 모델로 테스트해 실패 모드를 먼저 발굴하고, 그 실패를 방어하는 시스템을 설계한 것입니다. 이는 adversarial testing의 일종으로, 실제 프로덕션 환경의 다양한 조건을 시뮬레이션하는 방법입니다.
셋째, 시스템 프롬프트 제거 후 함수 호출 스키마와 검증 피드백으로 대체. 가장 흥미로운 부분입니다. 자연어 지시를 제거하고 엄격한 함수 호출 스키마로 대체했더니, 원래 6.75%였던 함수 호출 성공률이 검증 피드백 루프만으로 100%에 도달했습니다. 이건 ablation study 결과로 볼 수 있습니다—'무엇이 실제로 성능에 기여하는가'를 분리해서 확인한 것입니다.
AlphaEvolve: 베이스라인 대비 성능 개선의 자동화
구글 딥마인드의 AlphaEvolve는 다른 각도에서 같은 질문을 던집니다. AI가 스스로 더 나은 학습 알고리즘을 설계할 수 있다면, 그 성능은 어떻게 측정해야 하는가?
AlphaEvolve는 Gemini를 활용해 알고리즘 코드를 '변이'시키고, 자동화된 평가 시스템이 실제 게임 환경에서 성능을 점수화합니다. 성능이 뛰어난 알고리즘만 살아남아 다음 세대로 이어집니다—진화 알고리즘과 LLM의 결합입니다.
결과로 나온 두 알고리즘이 주목할 만합니다. VAD-CFR은 학습 과정의 변동성에 따라 과거 데이터 가중치를 동적으로 조절하며, 11개 게임 중 10개에서 기존 SOTA를 넘겼습니다. SHOR-PSRO는 탐색(exploration)과 활용(exploitation)의 균형을 자동으로 맞춥니다.
'베이스라인 대비 얼마나 개선되었나요?' 관점에서 보면: 10/11 게임에서 SOTA 갱신은 상당한 수치입니다. 하지만 '11개 게임이 충분히 다양한 분포를 커버하는가?'라는 질문은 여전히 남습니다. 특히 불완전 정보 게임이라는 특정 도메인에 한정된 결과라는 점—일반화 성능(generalization)은 아직 미지수입니다.
두 사례가 공통으로 가리키는 것
두 사례를 나란히 놓으면 ML 시스템 검증에서 반복되는 패턴이 보입니다.
측정 환경의 함정. AutoBe의 초기 100%는 독립적 함수 생성이라는 '쉬운 테스트 환경'에서 나온 숫자였습니다. AlphaEvolve의 11개 게임 벤치마크도 마찬가지—선택된 게임 세트가 곧 측정의 범위를 정의합니다. 'SOTA 달성'이라는 발표를 볼 때 재현 가능성(reproducibility)과 벤치마크 선택의 타당성을 함께 물어야 합니다.
스트레스 테스트의 가치. AutoBe 팀이 약한 로컬 LLM으로 의도적으로 성능을 낮춘 것은, 시스템의 취약점을 통제된 환경에서 먼저 발견하는 전략입니다. 프로덕션에서 발견하는 것보다 훨씬 저렴합니다.
피드백 루프가 성능을 만든다. 6.75% 함수 호출 성공률을 100%로 올린 것은 모델 교체가 아니라 검증 피드백 루프의 설계였습니다. AlphaEvolve도 마찬가지—개별 알고리즘의 품질보다 평가-선택-진화의 루프 설계가 핵심입니다.
시사점: '100%'를 보면 먼저 테스트 환경을 확인하라
ML 시스템을 평가할 때 성능 수치보다 먼저 봐야 할 것들이 있습니다.
- 테스트 데이터의 분포: 프로덕션 데이터와 얼마나 유사한가?
- 평가 메트릭의 선택: 무엇을 측정하고 무엇을 측정하지 않는가? AutoBe는 컴파일 성공률을 측정했지만 유지보수성은 측정하지 않았습니다.
- 스트레스 조건 포함 여부: 정상 입력만으로 테스트한 결과인가, edge case를 포함했는가?
- E2E 성능과 컴포넌트 성능의 분리: AutoBe의 컴파일 성공률이 100%여도 E2E 테스트(런타임 성공)는 아직 회복되지 않았습니다. 컴포넌트 지표와 시스템 지표는 다릅니다.
전망: 자동화가 깊어질수록 검증 설계가 핵심 경쟁력이 된다
AlphaEvolve가 보여준 '알고리즘 자동 설계'와 AutoBe가 보여준 '코드 자동 생성'은 모두 같은 방향을 가리킵니다—AI가 생성하는 결과물의 범위와 복잡도가 커질수록, 무엇을 어떻게 측정할 것인가의 설계가 시스템 전체의 품질을 결정합니다.
AutoBe 팀이 다음 목표로 E2E 런타임 성공률 회복을 꼽은 것은 정직한 자기 평가입니다. 컴파일 성공률 100%는 필요조건이지 충분조건이 아닙니다. AlphaEvolve가 게임 이론이라는 특정 도메인 밖에서도 같은 성과를 낼 수 있는지는 아직 보여주지 않았습니다.
'근거는 있나요?'라는 질문의 가치는 회의주의가 아니라 더 나은 측정 설계를 향한 출발점입니다. 100%라는 숫자는 이야기의 끝이 아니라 '무엇이 100%인가'를 묻는 시작점입니다.