What Happens When AI Outgrows the Tests We Use to Measure It?
AI가 측정 도구를 넘어서면 어떻게 되는가 — 벤치마크 포화와 개발자 평가의 문제
GPT-6 Astra 출시와 Jensen Huang의 'AGI 도착' 발언을 계기로, AI의 능력을 우리가 실제로 어떻게 측정하는지를 파고든 글입니다. 벤치마크 포화, proxy와 ground truth의 한계, 평가 방식 자체의 변화를 짚으며, 코드 생산이 쉬워져도 요구사항·설계·검증 같은 개발자의 역할은 오히려 중요해진다고 주장합니다.
- 주제
본문
OpenAI가 GPT-6 Astra를 공개하면서 익숙한 논쟁이 다시 시작되었습니다. NVIDIA CEO Jensen Huang이 X에 "AGI가 도착했다"고 쓰면서 SNS에는 흥분과 공포가 교차했고, 저자는 여기서 "AI가 빠르게 발전하고 있다"는 사실이 곧바로 "개발자는 필요 없다"는 결론으로 건너뛰는 것이 지나치게 크다고 지적합니다. 대신 던져야 할 질문은 "우리는 AI가 실제로 좋아지고 있는지 어떻게 아는가"입니다.
벤치마크는 능력이 아니라 측정 도구입니다
Model A 82%, Model B 88% 같은 숫자는 비교를 편하게 만들지만, 벤치마크는 능력 자체가 아니라 능력에 대한 증거를 주는 도구입니다. 온도계가 온도를 알려주되 온도 그 자체는 아니듯, 벤치마크 점수는 실세계에서 모델이 할 수 있는 모든 것을 담지 못합니다.
포화(saturation)되는 벤치마크
Astra의 시스템 카드는 평가가 시간에 따라 바뀐다는 점을 공개적으로 다룹니다. 초기 평가 일부는 이미 포화 상태이거나 은퇴가 검토되고 있고, 더 현실적이거나 실험 데이터를 쓰는 새 평가가 도입되고 있습니다. 강한 모델들이 97%, 98%, 98%를 기록하면 1%p 차이가 주는 정보는 거의 없습니다. 이는 벤치마크의 실패가 아니라 기술이 천장까지 도달했다는 신호이며, 모델이 움직였으니 시험도 움직여야 합니다.
92%는 무엇을 기준으로 92%인가
수학 문제는 정답이 있지만 과학적 추론이나 긴 작업에는 명확한 정답이 없는 경우가 많습니다. 그래서 ground truth(평가의 기준 정답)와 proxy(직접 측정하기 어려운 능력을 대신 측정하는 지표)가 등장합니다. 시스템 카드의 예로 AAV capsid packaging 예측이 있는데, adeno-associated virus의 단백질 껍질 성능 예측을 더 넓은 생물학 설계 능력의 proxy로 씁니다. 다만 "이 예측이 좋아졌다"와 "실제 능력이 좋아졌다"는 다릅니다. BPNet처럼 다른 모델의 예측을 정답으로 쓰면, 패턴 재현력은 좋아져도 실제 과제 능력은 그대로일 수 있습니다. 그래서 미공개 실험 데이터와 wet-lab 검증(실제 실험실 실험으로 확인)을 쓰는 새 평가가 중요합니다.
시험 자체도 계속 바뀐다
점수 뒤에는 데이터셋, 지시문, grader, scoring 방식, 도구와 모델 설정이 있습니다. 이 중 무엇이든 바뀌면 숫자의 의미도 바뀌므로 90%와 95%를 비교하기 전에 같은 평가 설정인지 확인해야 합니다. 작은 함정도 있습니다. 개방형 평가에서 긴 답변은 grader가 찾는 요소를 충족할 기회가 더 많아, 덜 유용한 긴 답이 높은 점수를 받을 수 있습니다. Astra는 일부 평가에 길이 보정 점수를 별도 보고합니다.
단일 질의응답에서 전체 작업 수행으로
이제 AI는 여러 단계의 작업을 수행하고, 도구를 쓰고, 모호한 지시를 다룹니다. Astra는 답이 결과를 바꿀 수 있으면 핵심 질문을 하고, 응답을 기다리는 동안 다른 작업을 진행하며, 중대한 결정은 추측 대신 사용자 입력을 기다립니다. 시스템 카드에는 컴퓨터·브라우저 작업과 모호한 지시, 복잡한 권한을 다루는 workplace-style 평가가 포함되어 있습니다. "정답을 맞혔나"만으로는 부족하고 "작업 전체를 얼마나 잘 처리했나"를 물어야 합니다.
개발자를 위한 질문과 자체 평가
벤치마크 점수를 볼 때 물을 것들입니다. 측정하는 게 목표 능력인가 proxy인가, 상위권에 몰려 포화되지 않았나, 정답의 기준은 무엇인가(고정 정답, 전문가, 다른 모델, 시뮬레이션, 실험 증거), 데이터셋·grader·설정이 바뀌지 않았나. 그리고 일반 코딩 벤치마크 점수가 높아도 내 코드베이스에 최적은 아닐 수 있으므로, 실제 업무에서 20~30개 태스크를 뽑아 직접 평가하라고 권합니다. 코드 동작, 요구사항 이해, 변경 대응, 수정량, 실패 시 복구, 시간과 비용을 보는 것입니다.
"개발자는 사라지는가"라는 질문 바꾸기
코드 생산이 쉬워져도 무엇을 만들지, 요구사항과 제약, 아키텍처가 성장을 견디는지, 보안과 신뢰성, 산출물 검증, 6개월 뒤의 요구사항 변경은 남습니다. 구현 후보가 늘어날수록 선택하는 판단은 더 중요해집니다. CSE는 처음부터 코드 작성 이상이었으므로 "CSE는 끝났다"는 과도합니다. "AI가 나를 대체할까"보다 "어떤 역량이 더 가치 있어지는가"를 묻자는 것입니다. 저자는 안전·오용·고용 같은 위험은 진지하게 다루되, 모든 능력 향상이 직업 종말 예언이 될 필요는 없다고 말합니다. 남는 질문은 단순합니다. "무엇이 바뀌었고, 어떻게 알며, 우리가 하는 일에 무슨 의미인가."
원문: dev.to / 번역·요약: Trawling