프롬프트가 실제로 작동하는지 재는 AIDRA eval 하네스

문제 정의

고쳤다고 적었지만, 고쳐졌는지는 아무도 확인하지 않았다

AIDRA는 AI 숏폼 드라마와 애니를 기획하는 에이전트다. 계정 로스터는 13명이지만 실제로 콘텐츠를 만드는 사람은 두 명뿐이고, 팀 확산은 명시적인 비목표로 확정했고 성공 기준도 그 두 사람의 리텐션과 전 기능 사용량으로 좁혔다. 이런 제품에서는 한 명의 품질 불만이 곧 제품 리스크가 된다. 7월 말, 그 두 사람 중 한 명이 남긴 실사용 흔적을 전수 분석해 결함 여덟 건을 수정했다. 그중 네 건은 프롬프트에 지시 문장을 추가하는 방식이었고, 각각 테스트를 붙였으며, 전부 통과했고, 프로덕션에 배포했다.

며칠 뒤 그 테스트들이 무엇을 증명하고 있었는지 다시 들여다봤다. 검증 방식을 주기적으로 재점검하는 습관에서 나온 확인이었다. 네 건의 테스트는 전부 조립된 프롬프트 안에 내가 넣은 지시 블록이 들어 있는지를 확인하는 형태였다. 이건 지시가 모델에게 전달된다는 것만 증명하고, 모델이 그 지시를 따르는지는 증명하지 못한다. 네 건 중 세 건이 그렇게 효능 검증 밖에 있었다.

남은 결함의 크기는 실무에서 이미 드러나 있었다. 보완을 지시하면 지목하지 않은 클립까지 절반 넘게 다시 쓰였고, 사용자는 산출물을 신뢰하지 못해 보완 기능을 점점 덜 쓰게 됐다. 유저가 둘인 제품에서 한 명이 특정 기능을 우회하기 시작한 상태였다. 프롬프트에 문장을 넣고, 테스트를 붙이고, 배포하고, 문서에 고쳤다고 적는 네 단계가 전부 성립했는데도 결함은 그대로였다.

가설 수립

판사를 세우는 대신, 세어볼 수 있는 것만 세기로 했다

세 지시가 효과가 있을지 없을지는 몰랐고, 모른다는 사실 자체가 문제라고 봤다. 프롬프트를 고치는 일은 앞으로도 계속할 텐데 판정할 수단이 없다면 매번 같은 자리에 서게 된다. 물론 더 값싼 대안들이 있었지만 전부 같은 함정을 갖고 있었다. 방향을 정한 것은 세 지시를 다시 읽으면서였다. 셋 다 의미 판단 없이 파서로 셀 수 있는 형태였다.

착수하기 전에 스스로 경계한 것이 하나 있다. 급조하면 검증하는 척만 하는 하네스가 되고, 그건 없는 것보다 나쁘다. 통과 표시가 거짓 안심을 주기 때문이다. 그래서 설계 의도와 채점 방식, 기각한 대안까지 문서로 남긴 뒤 그 문서를 들고 새 세션으로 넘어갔다. 내 추론에 오염되지 않은 맥락에서 적대적으로 검증하기 위해서였고, 이 제품에서는 산출물을 반드시 별도 세션이 검증하게 하는 것을 원칙으로 두고 있다.

솔루션 도출

채점기가 틀리자, 결론이 뒤집혔다

하네스는 프로덕션 코드를 한 줄도 건드리지 않는 방식으로 설계했다. 실험군과 대조군을 만들기 위해 코드에 분기를 넣는 대신, 조립이 끝난 프롬프트에서 문제의 지시 블록만 문자열로 떼어내 대조군을 만들었다. 이 방식의 최악의 실패는 앵커가 어긋나 절제가 조용히 아무 일도 하지 않는 것이다. 그러면 차이가 없다는 결과가 나오는데 그건 정확히 틀린 결론이다. 그래서 제거 전에 마커가 있는지, 제거 후에 사라졌는지, 길이가 실제로 줄었는지를 전부 단언하고 하나라도 어긋나면 즉시 중단하게 했다.

1차 측정 결과는 세 지시 모두 효과 미검출이었다. 지시를 넣은 산출물과 뺀 산출물은 바이트 단위로 서로 달랐다. 문장은 달라지는데 측정 대상 행동은 달라지지 않았다는 뜻이다. 그리고 이 표에서 읽어야 할 것은 개선폭이 아니라 대조군의 절대값이었다. 나흘 전 내가 고쳤다고 기록한 것이 사실이 아니었고, 그 사실을 문서에 그대로 적었다.

세 지시가 겨냥한 대상을 다시 설계하고 수정판을 재측정하는 도중에 하네스 자신의 결함이 드러났다. 대사를 판별하는 채점기가 인용부호를 필수로 요구하고 있었는데, 실제 산출물은 인용부호 없이 대사를 쓰는 경우가 흔했다. 그 결과 대사가 열 클립 전부에 있는 회차를 무대사 여섯 개로 오채점했고, 수정판이 회귀한 것처럼 보였다. 판별 근거를 인용부호에서 문장 구조로 바꾸고 다시 채점하자 숫자가 뒤집혔다.

이 하네스는 다른 검증이 검증하는 척했다는 것을 폭로하러 만들어졌는데, 그 자신도 한 지점에서 같은 일을 하고 있었다. 합성 예시로만 확인한 채점기는 테스트 24개를 통과하면서도 실제 산출물에서 틀렸다. 그래도 결론을 되돌릴 수 있었던 것은 저장해둔 산출물로 모델을 다시 호출하지 않고 재채점하는 도구를 미리 만들어뒀기 때문이다. 채점기를 고칠 때마다 생성을 다시 하면 비용이 배로 든다는 것을 착수 전에 계산해 넣어둔 장치였다.

세 결함의 최종 처방이 서로 달라진 것도 측정 덕분이었다. 측정 없이 하나의 처방으로 묶었다면 셋 다 실패했을 것이다. 대사 밀도는 지시문을 다시 쓰는 것으로 충분했고, 장치 재사용은 서버가 계산해 주입해야 움직였다. 수정 범위는 성격이 아예 달랐다. 유형이 갈렸기 때문에 처방도 갈릴 수 있었다.

결과 & 배운 점

검증 없는 수정은 수정이 아니었다

세 트랙을 세 차례 측정하는 데 108회씩 총 324회를 호출했고 비용은 약 16달러였다. 승인받은 상한 28달러 안이었다. 대사 밀도는 겨냥 지표가 27.6퍼센트에서 11.5퍼센트로 내려가며 p값 0.021로 유의하게 개선됐고, 회귀 감시 지표는 움직이지 않았다. 장치 재사용은 여섯 케이스 중 다섯이 한 방향으로 개선되며 반복률이 5배 넘게 줄었다.

가장 큰 변화는 수정 범위 쪽이었다. 보존을 서버 코드로 옮긴 뒤 지목하지 않은 클립의 변경률이 30.2퍼센트에서 0퍼센트로 떨어졌고 여섯 케이스 전부에서 같은 결과가 나왔다. 프로덕션에서 실제 회차로 보완을 요청해 확인해보니 지목한 클립 하나만 바뀌고 나머지 일곱 개는 바이트 단위로 동일했다. 핸드오프 문서를 쓴 시각부터 마지막 배포까지 4시간 44분이 걸렸다.

이 과제에서 내가 한 일은 채점기의 버그를 발견하거나 세 결함의 처방을 구분한 것이 아니다. 그건 내가 설계한 워크플로우가 나보다 먼저 잡아냈다. 내 몫은 그 판단들이 나오게 만드는 구조를 짠 것과, 이미 배포까지 끝난 내 작업을 다시 의심하고 재보기로 결정한 것이었다. 인터뷰로 요구를 정제해 문서로 고정하고, 적대적 검증을 붙이고, 구현을 위임하고, 측정으로 다듬고, 인수 조건을 직접 채점하고, 마지막에 제품을 직접 쓰면서 보완하는 순서를 반복했다.

이 일을 통해 남은 것은 검증 없는 수정은 수정이 아니라는 사실이다. 위험한 것은 지시의 존재가 아니라 고쳤다고 믿는 것이었다. 그래서 세 지시를 걷어내지 않고 남겨둔 채, 무엇이 실제로 작동하고 무엇이 작동하지 않는지를 수치로 문서에 적었다. 앞으로 프롬프트를 고칠 때 무엇을 어떻게 잴지부터 정하게 될 것 같다. 다만 이 습관이 다른 작업에 어떤 영향을 줄지는 아직 겪어봐야 알 것이다.