아무것도 하지 않는 변경사항은 0점을 받아야 한다. 내 코드는 그렇지 않았다.

실제 실험에 앞서 작은 파일럿을 진행했습니다. 그 결과 10개가 넘는 버그가 발견되었습니다.

이 버그들은 모두 제 자신의 측정 코드에서 발생한 것이었습니다. 실제로 제가 답하고자 했던 질문과 관련된 것은 하나도 없었습니다.

이는 올해 초 여기에 작성했던 테스트 품질 하네스(test-quality harness)에 대한 글인 killcheck의 후속 작업입니다. 이번 연구는 Google의 Gemma 4 모델을 기반으로 구축된 AI 코딩 에이전트에 관한 Kaggle 대회에 제출할 논문이며, 에이전트가 수정한 버그 수정이 실제로 정확한지 판단하는 방법을 다룹니다. 이 글은 11월에 제출되고 대회가 끝난 후에 결과가 나오기 때문에, 여기에는 어떤 발견 사항도 포함되어 있지 않습니다. 대신 발견 사항이 나오기 전의 과정에 대한 내용이 담겨 있는데, 제가 보기엔 이 부분이 더 유용할 것 같습니다.

버그들

이들은 지루했습니다. 그것이 바로 위험한 점입니다.

실행 간 순서가 안정적이지 않아, 동일한 입력에도 불구하고 그날 아침 파일 시스템의 상태에 따라 다른 시퀀스가 생성되었습니다. 제가 시드를 설정하지 않았고 존재조차 몰랐던 무작위성(Randomness)이 있었습니다. 부하(load) 하에서 발생하여 누락된 결과가 아닌 결과로 기록되는 타임아웃(Timeout)이 있었습니다. 즉, 설명할 수 없는 이유로 두 번의 동일한 실행 간에 단순히 출력값이 달랐습니다.

이러한 버그들은 스스로를 알리지 않습니다. 아무것도 충돌하지 않습니다. 그저 숫자를 생성하며, 그 숫자는 실제 숫자처럼 보이고, 표에 넣어도 아무도 눈치채지 못할 것입니다.

저는 마지막 프로젝트 이후 이 패턴에 대해 글을 쓴 적이 있습니다. 그리고 새 프로젝트에서도 똑같이 했습니다. 실패 모드(failure mode)가 존재한다는 것을 아는 것은 거의 보호막 역할을 하지 못하는 것 같습니다.

작동했던 유일한 트릭

대부분의 버그를 찾아낸 것이 바로 이것입니다.

당신이 이미 답을 알고 있는 제어(control) 코드를 만드세요.

가장 명확한 예시는 다음과 같습니다. 아무것도 하지 않는 변경사항은 항상 0점을 받아야 합니다. 파이프라인에 무해한(inert) 것을 입력했는데, 파이프라인이 결과를 보고한다면, 그 결과는 당신의 파이프라인에서 나온 것입니다. 다른 곳에서 나올 수 있는 것은 없습니다. 당신은 단지 당신의 장치가 아무것도 아닌 것에서 숫자를 만들어내는 것을 포착했을 뿐입니다.

제 방식은 0점을 받지 못했습니다. 여러 번에 걸쳐서요.

이것이 바로 전체 기술이며 놀라울 정도로 간단합니다. 당신은 궁금해하는 대상을 테스트하고 있는 것이 아닙니다. 당신은 그것을 측정할 수 있는 기계가 이미 정답을 알고 있는 무언가를 올바르게 측정할 수 있는지 여부를 테스트하고 있는 것입니다.

만약 그 기계가 할 수 없다면, 이전에 제공했던 모든 숫자는 검증되지 않은 것입니다. 반드시 틀렸다는 의미는 아닙니다. 다만 검증되지 않았다는 것이고, 실질적으로 출판을 앞두고 있을 때는 같은 의미입니다.

이것이 단순히 코드를 테스트하는 것과 다른 이유

저에게는 테스트가 있었습니다. 그 테스트들은 통과했습니다.

테스트는 당신의 코드가 당신이 지시한 대로 작동하는지 확인합니다. 반면, 제어(control)는 그것이 생성하는 것이 현실에 부합하는지를 확인합니다. 이 둘은 다른 질문이며, 측정 코드에서는 후자(제어)가 중요합니다. 왜냐하면 실패 모드(failure mode)가 예외가 아니기 때문입니다. 실패 모드는 그럴듯한 숫자이기 때문입니다.

그럴듯하게 틀린 숫자는 증상이 없습니다. 오류를 발생시키지 않습니다. 로그에서 이상해 보이지도 않습니다. 당신이 방치하는 한 결과표에 조용히 잘못된 상태로 놓여 있다가, 오직 사전에 답을 알고 있어 기계의 답변과 의견 불일치를 발견할 수 있는 경우에만 포착됩니다.

이것은 또한 버그들이 특정 위치에 집중되었던 이유도 설명해 줍니다. 명확한 정답을 가진 모든 파이프라인 요소들은 검사하기가 쉽고 답이 모호하지 않았기 때문에 초기에 확인되었습니다. 판단(judgement call)을 내리는 결과를 생성하는 모든 것은, 그것과 비교할 대상이 없었기 때문에 훨씬 오랫동안 미검토 상태로 남아 있었습니다. 그래서 저는 그것과 비교할 무언가를 만들었습니다.

이것이 강제하는 순서

제가 다르게 할 것, 그리고 이 어려운 경험을 통해 배운 것이라 이번에 한 것은, 첫 번째 혼란스러운 결과가 나온 후에 하는 것이 아니라 실험 전에 제어(control)를 구축하는 것입니다.

이것은 지연처럼 느껴집니다. 흥미로운 부분으로 가고 싶습니다. 제어는 흥미로운 부분이 아닙니다. 통찰력을 제공하지 않으며, 아무도 당신의 도구가 0까지 셀 수 있다는 것을 확인하는 섹션을 보고서로 읽지 않습니다.

하지만 미리 시간을 들여 작업하는 매 시간은 나중에 놀라운 결과가 발견인지 결함인지를 알아내려고 노력하며 낭비할 시간이 줄어드는 것을 의미합니다. 그 두 번째 질문이 훨씬 더 비싼 이유는, 그때쯤이면 당신은 의견을 가지고 있기 때문이고, 의견은 자신에게 동의하는 증거에 대해 관대하게 만듭니다.

교훈

다른 사람의 시스템에 대한 숫자를 신뢰하기 전에, 자신의 도구가 이미 알고 있는 숫자를 생성할 수 있음을 입증하도록 만들어야 합니다.

'아무것도 하지 않음(no-op)'은 0점을 받습니다. 빈 입력은 빈 결과를 제공합니다. 동일한 재실행은 동일한 답변을 제공합니다. 이것들은 깊은 통찰력이 아닙니다. 이것들이 바닥입니다. 하지만 이 바닥 위에서 전체 테이블이 서 있는 것이고, 저는 이제 두 번이나 그것을 건너뛰었을 때 무슨 일이 벌어지는지 힘든 방식으로 알게 되었습니다.

실제 연구 질문에 대해 단 하나의 것도 배우기 전에 10개가 넘는 버그를 발견했습니다. 저는 그 비율이 정상적이라고 생각합니다. 대부분의 사람들은 단순히 세지 않을 뿐이라고 생각합니다.