AI 에이전트가 빠르게 발전하는 것은 '정답 확인(테스트 오라클)'이 가능한 작업에 한정되는가?

AI 에이전트에게 작업을 맡기면, 같은 도구임에도 불구하고 '놀라울 정도로 빠른 날'과 '하루 종일 만지작거리다 아무것도 진전되지 않는 날'이 있습니다.

전자는 대부분 '기계가 맞는지 틀리는지 판정할 수 있는' 작업입니다. 테스트가 빨간색에서 초록색으로 바뀌거나, 출력이 기존 시스템과 일치하거나, 파일이 제대로 열릴 수 있습니다. 후자는 '뭔가 좋은 느낌으로 만들어줘', '좀 더 사용하기 쉽게'와 같이 정답이 인간의 머릿속에만 존재하는 작업입니다.

이 글의 주장은 간단합니다.

AI 에이전트가 빨라지는 것은, 정답 확인(테스트 오라클)을 준비할 수 있는 업무일 때만 아닐까.

다만, 이것은 결론이라기보다는 논의를 위한 출발점입니다. 오라클을 만드는 방법에는 여러 학파가 있으며, 각각 장단점이 있습니다. 마지막으로 '정답이 없는 작업은 어떻게 할 것인가'라는 미해결된 부분도 남겨두었습니다. 다른 의견이 있다면 댓글로 지적해주시면 감사하겠습니다.

10월 10일, Destructoid는 'GTA 5, Modern Warfare 2, Halo 등이 AI를 통한 리버스 엔지니어링으로 브라우저에 이식되고 있다'라는 기사를 발표했고, Reddit의 r/singularity에서도 600 포인트 이상, 댓글 90개 이상의 스레드가 되었습니다. (권리적으로는 상당히 논란이 많으며, Rockstar는 이미 GTA 5의 이식 버전을 삭제하도록 했습니다. 여기서 다루고 싶은 것은 '옳고 그름'이 아니라 기술적으로 '왜 게임이 먼저 실패했는지'입니다.)

스레드에서 나온 가설 중 하나가 이것입니다.

게임에는 완벽한 채점기가 처음부터 달려 있다. 원래의 실행 파일이다. 두 가지를 나란히 돌려 출력을 비교하고, 일치할 때까지 모델에 루프를 돌리면 된다.

원래 바이너리가 있는 한, '올바른 이식'의 정의는 모호해지지 않는다. 화면, 동작, 계산 결과를 비교하면 어긋나 있는지 알 수 있다. 에이전트에게는 몇천 번이고 물어볼 수 있는 정답 확인 담당자가 있는 상태와 같다.

또 다른 사례는 ArtCraft의 Brandon Thomas 씨가 Claude를 사용해 Rust로 만들고 있는 Adobe나 Microsoft Office 호환 앱입니다. Thurrott.com(10월 9일)에 따르면, Word 상당의 WordCraft는 리본 커맨드로 87%, 기능 패리티 전체로는 약 62%(둘 다 ArtCraft 본인의 신고)에서 DOCX 읽기/쓰기를 지원한다고 합니다. 반면, Adobe 계열 앱의 경우 '몇 달 만에 99%'라는 본인 발언에도 불구하고, 사용자들로부터 기본적인 편집이나 단축키, 성능 문제가 보고되면서 패리티 수치 자체를 두고 논쟁이 되고 있습니다.

여기서 흥미로운 점은, 두 세계에서 '정확성'을 측정하는 방식이 완전히 다르다는 것입니다.

• DOCX는 사양이 있는 파일 형식입니다. Word로 만든 파일을 열고 저장한 다음, 다시 Word로 열면 손상되었는지 기계적으로 알 수 있습니다.
• '포토샵처럼 사용 가능하게 만드는 것'은 사양이 아닙니다. 단축키의 느낌, 브러시의 부드러움, 대기 시간의 감각 등은 테스트하기 어렵습니다.

어느 쪽의 숫자가 오르기 쉬운가에 대한 이야기입니다.

필자는 SQL 엔진을 Rust로 처음부터 작성하게 하는 에이전트 실험을 진행하고 있습니다. 채점에 사용하는 것은 SQLite 본래의 테스트 스위트인 sqllogictest입니다. 수치는 다음과 같습니다.

• 코퍼스는 sqllogictest의 공개 미러에서 가공 없이 복사한 17개 파일, 11,185 레코드입니다. 모든 파일의 해시를 남겨 변조되지 않았는지 검증할 수 있도록 했습니다. - 채점기 자체가 올바른지 확인하기 위해, 같은 채점기로 실제 SQLite 3.46을 채점했을 때 11,183 / 11,185가 통과합니다. 틀린 2건은 새로운 SQLite가 sum()에서 integer overflow를 발생시키게 된 버전 차이입니다. 즉, 'SQLite와 같은 답을 내면 만점'이라는 거의 완벽한 오라클이 존재하는 것입니다. - 스텁(모두 오류를 반환하는 20줄)의 초기 점수는 30 / 11,185였습니다. 통과한 것은 '오류가 되어야 하는 문장'뿐입니다.
• 에이전트가 수정할 수 있는 곳은 src/만 가능합니다. 테스트와 채점기에는 손댈 수 없습니다. - 변경을 남기는 조건은 오직 하나입니다. 통과하는 테스트가 늘어나고, 이전에 통과하던 테스트가 단 하나도 망가지지 않는 것.

이런 형태로 만들자 에이전트의 작업은 'SQL 사양을 이해하고 아름답게 설계하는 것'에서 '실패한 테스트를 하나씩 통과시키는 것'으로 바뀝니다. 인간이라면 사흘 만에 지겨워할 종류의 작업입니다. NULL 비교, 타입 변환, ORDER BY

細かいルール。採点器がある限り、エージェントは文句も言わずにそこを削り続けます。

逆に、採点器を外した状態の指示（「いい感じのSQLエンジンを書いて」）では、何をもって前進とするかをエージェント自身が決めることになります。もっともらしいコードは増えても、それが前進なのか横滑りなのかを誰も判定できません。

もう一つ、人間側の感覚もあまり当てになりません。METR의 2025년 무작위 대조 시험(randomized controlled trial)에서는 경험 많은 OSS 개발자 16명이 실제 issue 246건을 다루었고, AI로 인해 24% 빨라질 것으로 예상했지만, 실제로는 AI를 사용한 쪽이 19% 느렸고, 끝난 후에도 20% 빨라졌다고 믿었습니다. (METR 자체가 이 결과는 이미 오래되었다고 명시하고 있으므로, 현재 도구 평가로서는 사용할 수 없습니다. 다만 '빨라진 느낌'과 '빨라졌다'가 어긋날 수 있다는 점은 기억할 가치가 있습니다.) 오라클(oracle)은 에이전트뿐만 아니라 인간의 착각에도 영향을 미칩니다.

"답안지 확인을 준비하자"라고 해도, 만드는 방법은 여러 가지입니다. 어느 것 하나 만만한 것이 없습니다.

주장: 사람이 먼저 사양(specification)을 테스트로 작성하고, 에이전트에게는 그것을 통과하는 코드만 쓰게 한다. 인간의 일이 '코드를 읽는' 것에서 '사양을 쓰는' 것으로 바뀌므로 확장 가능하다.

반론: 테스트는 인간이 생각해낸 것만 검사합니다. 게다가 에이전트는 테스트도 작성할 수 있습니다. 버그가 있는 동작을 그대로 기대값(expected value)으로 삼은 테스트는, 겉보기에는 좋은 테스트와 구별되지 않습니다. '누가 테스트를 리뷰하는가' 문제는 남아있습니다.

주장: 포팅(porting), 리라이트(rewrite), 언어 전환이라면, 기존 시스템 자체가 답이 됩니다. 같은 입력을 양쪽에 흘려보내고 출력을 비교합니다. 위의 게임 포팅이나 SQLite의 예가 이에 해당합니다. 테스트를 한 줄도 쓰지 않고 방대한 검사 항목을 얻을 수 있습니다.

반론: 기존 시스템의 버그까지 '정답'이 됩니다(SQLite의 sum()처럼, 오라클 측 버전에서도 답이 달라집니다). 또한, 기존 시스템이 존재하지 않는 신기능에는 사용할 수 없습니다.

주장: 현재 출력을 파일에 저장해 두고, 변경 후 출력과 비교한다. Rust라면 insta, JS라면 Jest의 스냅샷(snapshot) 등이 있습니다. 리팩토링을 에이전트에게 맡길 때 안전망으로 매우 저렴합니다.

반론: '현재 출력'이 옳다는 보장이 없습니다. 그리고 차이가 발생했을 때 --update 한 번에 스냅샷을 덮어쓸 수 있는 환경이라면, 에이전트든 인간이든 가볍게 정답을 덮어쓰게 됩니다.

주장: 최종적인 판단은 인간이 합니다. 설계의 왜곡, 요청하지 않은 의존성 추가, 로그로의 토큰 유출 등 테스트로는 걸러지지 않는 문제를 잡아낼 수 있는 것은 현재까지는 인간뿐입니다.

반론: 속도가 나오지 않습니다. 에이전트가 4분 만에 600줄의 PR을 내고, 읽는 데 40분이 걸린다면, 병목 현상은 인간입니다. 결국 'lgtm'으로 흘려보게 됩니다.

주장: 개별적인 기대값(expected value)이 아니라, 항상 성립하는 속성(property)을 작성하고, 입력은 무작위로 대량 생성한다. (예: 인코딩 후 디코딩하면 원래대로 돌아옴, 정렬 결과는 오름차순으로 요소 수가 변하지 않음 등). 기대값을 누군가 결정할 필요가 없으므로, 사양이 모호한 영역에서도 오라클을 만들 수 있습니다.

반론: 좋은 속성을 찾는 것이 어렵습니다. 게다가 속성은 '필요조건'일 뿐인 경우가 많아, 전부 만족시켜도 사양과 같지는 않습니다.

필자의 베팅은 "2(차분 테스트)가 사용 가능하다면 최우선, 사용할 수 없다면 1과 5를 조합하고, 4는 마지막 관문에만 집중시키는 것"입니다. 다만, 이것이 정답이라는 자신감은 없습니다.

어느 학파에서든 쓸 수 있고 복사 붙여넣기 하기 쉬운 것을 정리합니다.

통과하는 테스트가 늘어나고, 기존의 합격 테스트가 하나도 떨어지지 않은 변경만 받아들이는 스크립트입니다. Rust의 cargo test 출력(test 이름 ... ok)을 전제로 하고 있지만, 다른 언어에서도 합격 테스트명 목록만 가져올 수 있다면 같은 형태로 작성할 수 있습니다.

#!/usr/bin/env bash
# gate.sh: 사용법 → 변경 전에 ./gate.sh baseline, 변경 후에 ./gate.sh check
set -uo pipefail
...

기존 바이너리와 신 바이너리에 같은 입력을 흘려보내고 출력이 다른 것만 비교하는 최소 구성입니다. 입력 케이스는 실제 로그나 기존 샘플에서 모으면, 순식간에 수가 채워집니다.

#!/usr/bin/env bash
# diff_oracle.sh: cases/*.in을 기존・신 양쪽에 흘려보내고 출력이 다른 것을 나열한다
fail=0
...

use proptest::prelude::*;
proptest! {
// 어떤 문자열이든 인코딩했다가 디코드하면 원래대로 돌아온다
...}

완료 조건

• ./gate.sh check가 exit 0이면 완료. 그 외의 경우는 완료로 보고하지 말 것.

금지 사항

...

채점기 자체를 먼저 검증한다. 실제 시스템(구 시스템, 본가 구현)으로 채점하여 만점에 가까운 점수가 나오는 것을 확인한 후에 에이전트에게 넘긴다. 채점기의 버그는 에이전트가 전력을 다해 공격할 것이다. -
테스트와 채점기는 쓰기 금지로 한다. 지시뿐만 아니라, 가능하다면 권한이나 CI(Continuous Integration)를 통해 물리적으로 막는다. -
테스트의 차분은 코드의 차분보다 먼저 리뷰한다. 테스트가 정직하다면, 코드는 대체로 제약받게 된다. -
머지는 하나씩, 머지할 때마다 모든 테스트를 재실행한다. 단독으로 통과하는 두 개의 변경 사항이 합쳐지면 깨질 수 있다. -
오라클(Oracle)을 만들 수 없는 태스크는 처음부터 '사람이 리뷰하는 업무'로 분리한다. 에이전트에게 맡기는 양을, 오라클이 있는 부분과 없는 부분으로 나눈다.

여기까지의 이야기는 역설적으로 '오라클이 없는 일에서는 에이전트가 그다지 빨라지지 않는다'는 주장으로 이어집니다. 그리고 현실의 많은 업무에는 오라클이 없습니다.

UI의 사용감, 애니메이션의 느낌

'이 화면은 뭔가 이해하기 어렵다'라는 말 속의 '뭔가'

제품으로서 무엇을 만들지 않을지에 대한 감각

글의 톤, 에러 메시지의 친절함

몇 가지 아이디어는 있습니다. 스크린샷 이미지 비교로 '외형이 망가지지 않았는지'만 기계적으로 본다. Lighthouse나 접근성 검사처럼 수치화할 수 있는 부분만 잘라낸다. 다른 모델에게 평가하게 한다(단, 평가하는 쪽도 같은 편견을 가지고 있을 수 있다). 사용자 테스트나 A/B 테스트를 '느린 오라클'로 사용한다.

하지만 이 모든 것이 '포토샵처럼 사용할 수 있는지'에 답할 만큼 강하지는 않습니다. 오라클이 있는 일은 계속 에이전트에게 넘어가고, 오라클이 없는 일만 인간에게 남게 됩니다. 그렇게 되었을 때, 인간의 업무는 '오라클을 만드는 것'과 '오라클을 만들 수 없는 것을 판단하는 것' 두 가지가 될지도 모릅니다. 그것이 좋은 일인지는 솔직히 아직 알 수 없습니다.

실제 현장의 이야기를 꼭 듣고 싶습니다. 특히, 잘되지 않았던 이야기를요.

에이전트에게 맡겨 성공했던 태스크에는, 돌아봤을 때 오라클(테스트, 구 시스템, 사양이 있는 파일 형식 등)이 있었나요?

차분 테스트에서 구 시스템을 오라클로 사용한 적이 있습니까? 구 시스템의 버그는 어떻게 처리했나요?

에이전트가 테스트나 스냅샷을 수정해서 '녹색'으로 만들었던 경험이 있습니까? 어떻게 방지하고 있나요?

UI의 사용감이나 제품 판단 같은 '정답이 없는 업무'를, 에이전트에게 어느 정도까지 맡기고 있습니까? 기계로 측정할 수 있는 대체 지표를 찾은 사람이 있습니까?

위 내용 중 사실과 다르거나 현장의 감각과 동떨어진 부분이 있다면, 주저하지 말고 지적해 주세요. 논리보다 실제 실패담이 훨씬 참고가 됩니다.