구글이 신규 코드의 75%를 AI가 생성한다고 밝힌 지금, '코드를 만드는 속도' 문제는 사실상 해결된 것이나 다름없다. 그런데 팀 리드로서 솔직히 말하면, 요즘 내가 진짜 걱정하는 건 생성 속도가 아니다. AI가 쏟아낸 결과물이 실제로 더 나아진 건지, 아니면 그냥 모양만 바뀐 건지 판단할 수 없다는 것이다.
이 감각, 많은 팀이 공유하고 있을 것이다. 시스템 프롬프트를 조금 고치고, 툴을 하나 추가하고, 지시 방식을 바꿔보면 출력이 달라진다. 그런데 '더 나아진 건지' 아니면 '그냥 다른 건지'를 구분할 방법이 없다. 프롬프트 엔지니어링이 대부분 직관에 의존하는 이유가 여기에 있다.
프롬프트 A/B 테스트: 직관을 수치로 바꾸는 도구
dev.to에 올라온 'I built a Python module to A/B test prompts inside Claude Code'는 바로 이 문제를 정면으로 겨냥한다. 저자가 만든 모듈은 단순하다. 동일한 프롬프트를 두 에이전트에게 동시에 던진다. Agent A는 기본 시스템 프롬프트만 받는다. Agent B는 동일한 기본 프롬프트에 더해 구조화된 추론 제약 세트(reasoning scaffold)를 런타임에 주입받는다. 두 응답은 생산자와 다른 모델 패밀리인 Gemini Flash가 블라인드 심판으로 채점한다. 결과는 구조화된 JSON으로 돌아온다—specificity, posture, depth, actionability, honesty 다섯 차원의 점수, 판정 이유, 그리고 A·B·tie 중 하나의 버딕트.
저자가 공개한 실제 의료 케이스가 인상적이다. 45세 남성 환자의 사전 당뇨 수치와 지질이상 데이터를 두 에이전트에게 넣었다. 기본 에이전트는 '더 건강하게 먹으라'는 일반 권고를 냈다. 스캐폴드가 주입된 에이전트는 '갑상선 패널 검사를 먼저 해보자'고 응답했다. 블라인드 심판의 점수는 B가 20점, A가 16점. 판정 이유는 명확했다: "Response B는 환자가 호소한 '무기력감'을 비타민 D 결핍과 직접 연결하고 갑상선 검사라는 구체적 다음 단계를 제안했기 때문에 우월하다."
이 도구의 진짜 가치는 결과만큼이나 투명성에 있다. 모든 응답, 점수, 판정 이유, 주입된 스캐폴드, 에이전트가 자율적으로 선택한 쿼리 모드까지 JSON 한 덩어리에 담겨 돌아온다. '모델이 개선됐다'가 아니라 '이 도구를 호출했고, 이 추론 제약을 받았고, 이 차원에서 이 점수를 얻었다'는 전체 체인이 추적 가능하다. Claude Code나 Cursor 같은 IDE 에이전트에게 "이 프롬프트로 eval 모듈 돌려줘"라고 지시하면, 에이전트가 README를 읽고 스크립트를 실행하고 결과를 리포트해준다.
병목은 생성이 아니라 검증으로 이동했다
이 맥락을 이해하려면 Ajey Gore의 통찰이 필요하다. dev.to의 'Verification is the expensive thing now'는 Martin Fowler가 수집한 AI 개발 재편 논의를 정리하면서 핵심을 찌른다: AI 에이전트가 실행을 담당하게 되면, 검증이 프리미엄 작업이 된다. 10명이 만드는 팀 대신 3명이 만들고 7명이 인수 기준을 정의하고 테스트를 설계하는 구조. 병목이 '코드를 쓸 수 있나?'에서 '코드가 맞는지 아는가?'로 이동한다.
이 글에서 제기하는 '의도 부채(intent debt)' 개념도 중요하다. AI 에이전트가 코드를 쓰기 전에는, 코드를 직접 짠 사람이 의도를 머릿속에 쥐고 있었다. 그 암묵적 지식이 암묵적 검증 역할을 했다. 에이전트가 코드를 쓰는 순간, 그 암묵적 지식의 공백이 구체적인 실패 모드로 드러난다. 의도를 명시적으로 정의하지 않으면 검증 자체가 불가능해진다.
팀에게 실질적으로 의미하는 것
프롬프트 A/B 테스트는 이 문제에 대한 실용적인 답변 중 하나다. 핵심 포인트를 정리하면 이렇다.
첫째, 프롬프트를 코드처럼 관리해야 한다. 코드는 버전 관리하고 테스트하고 리뷰한다. 프롬프트도 마찬가지다. A/B 테스트 없이 프롬프트를 수정하는 것은 테스트 없이 코드를 배포하는 것과 같다.
둘째, 블라인드 심판 구조가 중요하다. 생산자 모델과 다른 패밀리의 모델을 심판으로 쓰는 것은 bias 오염을 차단하기 위해서다. 팀이 자체적으로 판단하면 확증 편향이 끼어든다. 심판을 분리하는 구조가 객관성을 확보한다.
셋째, 타이(tie)도 신호다. 단순 쿼리나 명확한 패턴 매칭 태스크에서는 두 응답이 비슷하게 나온다. 심판이 타이를 줄 때 그건 도구의 실패가 아니라 '이 프롬프트에는 추가 구조가 필요 없다'는 정보다. 어디에 엔지니어링 비용을 집중할지 알려주는 신호다.
넷째, 팀의 월요일 스탠드업이 바뀐다. '뭘 만들었나?'가 아니라 '뭘 검증했나?'가 핵심 질문이 된다. 생성된 코드 세 개를 검증 없이 밀어넣은 사람보다, AI 출력의 미묘한 오정렬을 배포 전에 잡아낸 사람이 더 가치 있는 일을 한 것이다.
도입 전에 냉정하게 따져볼 것들
낙관적인 부분만 이야기하면 균형이 맞지 않는다. 몇 가지를 냉정하게 짚어야 한다.
이 도구는 API 키가 세 개 필요하다(OpenAI, Gemini, Ejentum). 호출당 비용이 발생한다. 매번 모든 프롬프트에 A/B 테스트를 돌리는 건 현실적으로 어렵고, 비용 효율도 나쁘다. 팀이 선택해야 할 것은 '어떤 프롬프트를 테스트할 것인가'다—프로덕션에 직접 영향을 미치는 핵심 에이전트 프롬프트, 자주 수정되는 시스템 프롬프트, 품질 불확실성이 높은 복잡한 추론 태스크가 우선순위다.
또한 블라인드 심판 자체도 완벽하지 않다. 심판 프롬프트의 품질에 따라 판정이 달라질 수 있다. 저자가 시스템 프롬프트와 평가자 프롬프트를 모두 리포지토리에 공개한 이유가 여기에 있다—누구든 검증 구조 자체를 감사할 수 있어야 한다.
지금 팀에게 필요한 것
구글의 75% 숫자가 가리키는 방향은 명확하다. 생성 능력은 더 이상 차별화 요소가 아니다. 차별화 요소는 무엇을 만들지 설계하는 능력, 만들어진 것이 맞는지 검증하는 능력, 그리고 그 루프를 반복 가능한 구조로 만드는 능력이다.
프롬프트 A/B 테스트는 그 구조의 한 조각이다. 팀이 프롬프트 품질을 직관이 아닌 수치로 이야기하기 시작하는 순간, 'AI를 잘 쓰는 팀'과 'AI에게 쓰이는 팀' 사이의 간격이 벌어지기 시작한다. 그 간격이 결국 배포 품질의 천장을 결정한다.