모델이 정말 ‘너프’됐을까? 실패한 스크린샷 한 장에서 신뢰할 수 있는 대조 실험까지

한 번의 실패는 모델이 실수했다는 사실을 증명할 수 있습니다. 하지만 그것만으로는 모델이 예전보다 더 자주 실패한다는 것까지 증명할 수 없습니다.

“이 모델, 또 너프된 걸까?” 한쪽 발이 페달 밖으로 삐져나온 펠리컨, 프레임이 꽈배기처럼 꼬인 자전거, 그리고 그 옆에 놓인, 지난주에는 꽤 잘 그려졌던 스크린샷 한 장. 이 정도면 의문이 생기기에 충분합니다.

이런 의심을 “모델에는 무작위성이 있다”는 한마디로 넘겨서는 안 됩니다. 돈을 내고 쓰는 서비스가 예전에는 해내던 작업을 이제 제대로 해내지 못한다면, 당연히 따져 볼 만한 일입니다. 다만 스크린샷 두 장만으로는 모델이 바뀌었다거나, 추론 예산이 깎였다거나, 특정 채널이 ‘물을 탔다’고 단정하기에 부족합니다.

얼마 전 저는 펠리컨 테스트를 수십 번 돌렸습니다. 이 과제가 쓸모 있는 이유는 많은 실수가 눈에 보이는 그림으로 그대로 드러난다는 데 있습니다. 코드가 실행된다고 해서 자전거 구조가 맞는 것은 아닙니다. 새와 자전거가 모두 그려져 있다고 해서 발이 실제로 페달을 밟고 있는 것도 아닙니다. 이런 공간 관계는, 유창해 보이지만 논리적 허점이 숨어 있을 수 있는 답변보다 눈으로 잡아내기가 훨씬 쉽습니다. 그런데 결과를 쌓을수록 또 다른 점이 분명해졌습니다. 우리는 작품 하나로 서비스 전체를 평가하는 경우가 많습니다.

이 글은 어떤 모델을 변호하려는 것이 아니며, 몇 가지 겉보기 특징으로 ‘가짜 모델’을 잡아내는 법을 가르치려는 것도 아닙니다. 제가 관심을 두는 질문은 더 좁습니다. 모델이 나빠졌다는 의심이 들 때, 그 느낌을 다른 사람이 다시 검증할 수 있는 증거로 어떻게 바꿀 것인가 하는 문제입니다.

참고: 아래에 나오는 서비스 A, B와 여기에 붙은 모든 테스트 수치는 설명을 위한 예시입니다. 실제 서비스를 가리키지 않으며, Folkbench의 측정 결과나 순위도 아닙니다.

1. 먼저 질문 나누기: ‘너프됐다’는 정확히 무엇을 뜻합니까?

‘너프됐다’는 편리한 말이지만, 서로 다른 여러 질문을 하나로 뭉뚱그립니다. 가장 직접적인 층위는 이번 답변이 실제로 틀렸다는 것입니다. 펠리컨에 다리가 하나 더 생겼거나, 발이 페달을 놓쳤거나, 바퀴가 프레임에서 떨어져 나갔습니다. 모두 확인할 수 있는 구체적인 실패입니다. 샘플 하나만으로도 “이런 오류가 일어났다”는 사실을 증명할 수 있고, “이런 오류는 절대 저지르지 않는다”는 약속을 뒤집기에도 충분합니다. 두 번째 층위는 같은 조건, 또는 충분히 비슷한 조건에서 이 서비스가 더 자주 실패한다는 것입니다.

이것은 더 이상 오류가 존재하느냐의 문제가 아닙니다. 오류가 얼마나 자주 나타나느냐의 문제입니다. 흔히 말하는 “사용감이 나빠졌다” 가운데 가장 측정할 가치가 있는 부분은 “대개 잘 됐다”에서 “대개 안 된다”로 바뀌는 지점입니다. 세 번째 층위는 그 변화가 모델 자체, 또는 서버 측 설정의 변화 때문에 생겼다는 것입니다. 이것은 이미 원인에 관한 주장입니다. 같은 나쁜 결과도 서로 다른 설명에서 나올 수 있습니다. 요청 파라미터가 달랐을 수도, 컨텍스트가 달랐을 수도, 출력이 잘렸을 수도, 아니면 기반 모델과 추론 설정이 실제로 바뀌었을 수도 있습니다. 결과만 보고는 대개 이 가운데 하나를 가려낼 수 없습니다.

그래서 “이번 답이 틀렸다”, “이 서비스는 덜 믿을 만하다”, “이 서비스가 몰래 모델을 바꿨다”는 같은 강도의 증거를 요구하지 않습니다. 이 차이를 인정한다고 해서 사용자 불만의 문턱을 높이는 것은 아닙니다. 오히려 그 반대입니다. 질문을 분명히 짚어 두면, 서비스 제공자가 모든 장애를 “무작위성”으로 설명하는 일도, 평가자가 모든 차이를 “모델을 바꿔치기했다”로 설명하는 일도 막을 수 있습니다.

2. 보고 있는 것은 작품 하나입니까, 출력의 분포입니까?

무작위로 샘플링하는 생성 설정에서는 같은 입력도 다른 출력을 낼 수 있습니다. 재현성을 높이기 위한 장치를 쓰더라도 “최대한 일관되게”를 “매번 똑같이”로 읽어서는 안 됩니다. OpenAI의 예전 기술 설명은 이 점을 분명히 적었습니다. 같은 seed, 같은 파라미터, 같은 백엔드 핑거프린트에서도 출력이 완전히 같다는 보장은 없다는 것입니다. 이는 재현성에 한계가 있다는 뜻일 뿐, 오늘날 모든 모델이 같은 파라미터를 지원한다는 뜻은 아닙니다.¹

펠리컨 테스트에서 우리가 보통 알고 싶은 것은 “가끔 좋은 그림 한 장을 그릴 수 있는가?”가 아닙니다. “내가 정한 조건에서 이 작업을 한 번 더 맡기면 합격 결과가 나올 가능성이 얼마나 되는가?”입니다. 단순한 예를 하나 들면 스크린샷 한 장의 문제가 드러납니다. 어떤 서비스의 실제 1회 합격률이 80%이고, 각 생성이 서로 독립적이며, 테스트 동안 상태가 변하지 않는다고 가정해 보겠습니다. 20회 연속 시도에서 적어도 한 번 실패할 확률은 다음과 같습니다. 1 − 0.8²⁰ ≈ 98.85% 대개 일을 잘 해내는 서비스라도, 20회 안에서 스크린샷으로 남길 만한 실패 사례가 나올 것은 거의 확실합니다.

반대로 생각해 보겠습니다. 다른 서비스의 실제 1회 합격률이 40%에 불과하다고 가정합니다. 같은 독립성과 안정성 전제에서 20회 중 적어도 한 번 합격 결과를 얻을 확률은 다음과 같습니다. 1 − 0.6²⁰ ≈ 99.996% 이 서비스 역시 내보일 만한 작품 하나는 거의 확실하게 만들어 냅니다. 이 두 계산은 실제 호출이 모두 독립적이라는 말도, 실제 합격률이 정확히 이 숫자라는 말도 아닙니다. 이 계산이 가리키는 것은 선택의 문제입니다. 가장 좋은 시도만 보여 주면 신뢰성을 과대평가하기 쉽고, 가장 나쁜 시도만 보여 주면 성능 저하를 과장하기 쉽습니다.

그래서 같은 서비스가 그림 한 장을 근거로 “풀성능 확정”이라고 말하는 글과, 그림 한 장을 근거로 “너프 확정”이라고 말하는 글에 동시에 등장할 수 있습니다. 두 스크린샷은 모두 진짜일 수 있습니다. 하지만 거기서 끌어낸 추론까지 맞는 것은 아닙니다. 놓치기 쉬운 구분이 하나 더 있습니다. 첫 생성에서 성공하는 것과, 열 번 생성한 뒤 성공한 것 하나를 고르는 것은 같은 능력이 아닙니다. 후자에는 추가 호출, 대기, 선별 비용이 들어 있습니다. 두 워크플로를 비교한다면 양쪽에 같은 시도 예산을 주어야 합니다. A의 첫 시도를 B의 엄선된 결과와 비교해서는 안 됩니다.

3. 20회를 돌리면 차이가 저절로 통계적으로 의미 있어집니까?

아닙니다. 20회는 합리적인 실험 예산일 수는 있어도 통계적 통행증은 아닙니다. 같은 구체적인 예를 보겠습니다. A 채널을 20회 실행해 16회 합격했고, B 채널을 20회 실행해 8회 합격했습니다. 양쪽 모두 같은 고정 과제와 같은 채점 기준을 썼고, 샘플은 하나도 버리지 않았습니다.

이 구간은 이항 비율에 대한 양측 95% Wilson 신뢰 구간입니다. 추정한 합격률의 불확실성을 나타낼 뿐, 그림 품질의 점수 범위가 아닙니다.² 샘플에서 나타난 차이는 40%p입니다. 하지만 양쪽이 각각 20회뿐이라 추정은 아직 거칩니다. 80%와 40%를 정확히 측정된, 앞으로도 변하지 않을 실제 능력으로 취급해서는 안 됩니다.

여기에 각 호출이 독립적이고, 각 채널의 합격 확률이 기간 안에서 안정적이며, 이 비교를 미리 정해 두었다고 추가로 가정하면, 합격/불합격 횟수에 대한 양측 Fisher 정확 검정은 p ≈ 0.0225를 줍니다. 미리 정한 5% 유의 수준에서 이 예시는 “이 조건에서 두 합격률이 다르다”는 판단을 뒷받침합니다.³ 그러나 이 숫자는 “B가 물을 탔을 확률이 97.75%”라는 뜻도, “A가 영원히 더 나을 확률이 97.75%”라는 뜻도 아닙니다. p값은 차이가 없다는 가설과 해당 검정의 조건 아래에서 이만큼, 또는 이보다 더 극단적인 데이터가 나올 확률입니다. 숨은 원인이 있을 확률이 아닙니다.³

두 구간이 겹치는지 훑어보는 것으로 차이 검정을 대신해서도 안 됩니다. 각 구간은 합격률 하나를 추정하지만, 검정의 대상은 두 합격률 사이의 차이입니다. 검정 방법 하나를 외우는 것보다 중요한 경계가 세 가지 있습니다. 차이의 크기와 샘플 수를 함께 봐야 합니다. 16 대 8과 16 대 15가 같은 강도의 결론을 뒷받침해서는 안 됩니다. 샘플이 얼마나 필요한지는 얼마나 작은 차이를 잡아내고 싶은지, 그리고 잘못 판단할 위험을 어디까지 감수할지에 달려 있습니다. 모든 작업에 들어맞는 “최소 몇 회는 돌려야 한다”는 기준은 없습니다.

유의한 차이를 찾지 못했다고 해서 둘이 같다는 것이 증명되지는 않습니다. 데이터가 너무 적거나 너무 불안정해서 아직 결론을 내릴 수 없을 뿐일 수도 있습니다. 차이가 무시해도 될 만큼 작다는 것을 보이려면 “얼마나 작아야 무시할 수 있는지”를 미리 정의해야 합니다. 유의하지 않은 결과는 동등성의 증명이 아닙니다. 통계적 차이가 있다고 해서 그것만으로 서비스를 바꿀 이유가 되지는 않습니다. 사용자는 여전히 실패의 대가, 호출 가격, 지연 시간, 작업을 다시 하는 비용을 따져야 합니다. 차이가 실재하더라도 선택을 바꿀 만큼 크지 않을 수 있습니다. 여기서 통계의 역할은 전문적으로 보이는 p값을 만들어 내는 것이 아닙니다. 증거가 감당할 수 있는 것보다 더 많은 것을 주장하지 않도록 막는 것입니다.

4. 베이스라인은 “프롬프트가 같았다”는 한 문장이 아니라 실험 계약입니다

많은 비교는 샘플 수가 문제가 되기도 전에 실패합니다. 샘플이 처음부터 비교 가능하지 않았던 것입니다. 양쪽 모두 “자전거 타는 펠리컨 그리기”라는 요청을 받습니다. 한쪽은 새 세션에서 보낸 API 요청이고, 다른 쪽은 이미 수십 턴이 오간 데다 도구까지 켜진 채팅 창입니다. 한쪽은 긴 출력을 쓸 수 있는데, 다른 쪽은 중간에 길이 제한에 걸립니다. 이런 결과는 백 번을 반복해도 모델 능력의 차이로 돌릴 수 없습니다.

OLMES 평가 표준에 관한 연구는 프롬프트 형식, 컨텍스트 내 예시, 과제 문구 같은 평가상의 선택이 측정되는 성능을 바꾼다고 지적합니다. 재현 가능한 비교를 하려면 이런 설정을 기록해야 합니다. 그 연구의 과제는 펠리컨 SVG가 아니지만, 실험 설정에 대한 경고는 귀담아들을 만합니다.⁴ 저는 베이스라인을 “이번 라운드가 실제로 무엇을 측정하는가”에 관한 계약으로 보자고 제안합니다.

비교 대상은 구체적이어야 합니다. 서비스, 그룹 또는 경로, 그리고 실제로 확인할 수 있는 모델 버전까지 적습니다. 시간이 지나면 바뀔 수 있는 모델 별칭밖에 없다면 그 별칭을 기록합니다. 기반 스냅샷을 모르면 ‘알 수 없음’이라고 씁니다. API가 반환한 모델명 문자열을 기반 모델의 정체가 독립적으로 검증된 것으로 취급해서는 안 됩니다. 입력은 가능한 한 완전하게 저장합니다. 마지막 프롬프트만이 아니라, 직접 제어하고 관찰할 수 있는 시스템 프롬프트, 대화 기록, 첨부 파일, 도구 설정까지 포함합니다. 눈에 보이는 조건이 같다고 해서 보이지 않는 조건까지 같다는 것이 증명되지는 않습니다.

생성 설정은 추론 강도, 출력 상한, 그리고 API가 실제로 지원하는 샘플링 파라미터를 기록합니다. API가 제공하지 않는 필드는 ‘미지원’, 적용됐는지 확인할 수 없는 필드는 ‘알 수 없음’이라고 씁니다. 이런 항목을 슬그머니 같은 것으로 취급해서는 안 됩니다. 서로 다른 두 모델에서 “high”라는 같은 이름의 설정이 같은 연산 예산을 뜻한다고 가정해서도 안 됩니다.

평가 환경에는 렌더링 방식과 채점 방식이 포함됩니다. 같은 SVG는 같은 뷰포트와 렌더러에서 확인합니다. 애니메이션 과제라면 합의한 관찰 시간을 지켜야 합니다. 한쪽은 전체 동작을 다 보고 다른 쪽은 프레임 하나만 골라 봐서는 안 됩니다. 과제가 애니메이션을 요구하지 않았다면 출력이 정지 이미지라는 이유로 감점해서도 안 됩니다. 마지막으로, 재시도 규칙은 테스트 전에 적어 둡니다. 첫 실패 후 재시도를 허용하는지, 몇 번까지 허용하는지, 피드백을 줄 수 있는지는 모두 테스트 조건입니다. 결과를 본 뒤 즉흥적으로 정할 일이 아닙니다.

이런 것들을 고정하는 목적은 현실과 동떨어진 ‘실험실 모델’을 만드는 데 있지 않습니다. 두 채팅 제품의 기본 사용 경험을 비교하는 것도 얼마든지 가능합니다. 다만 그때의 결론은 “두 제품은 기본 설정에서 내놓는 결과가 다르다”여야지, “기반 모델 가중치의 우열을 분리해 냈다”가 되어서는 안 됩니다. 통제할 수 없는 조건은 ‘알 수 없음’으로 남겨 둘 수 있습니다. 하지만 알 수 없는 조건을 통제했다고 적어서는 안 됩니다.

5. 횟수를 늘리는 것보다 테스트를 어떻게 짜느냐가 더 중요할 때가 많습니다

채널과 시간대를 한데 묶지 않기

A를 오전에 몰아서 다 돌리고 B를 밤늦게 몰아서 돌리면, “채널 간 차이”와 “시간대에 따른 차이”가 뒤섞입니다. 실제로 차이가 보이더라도 그중 얼마가 그 시간대에 달려 있는지 말하기 어렵습니다. 가벼운 수평 비교라면, 저는 미리 정한 시간 범위 안에서 A와 B에 번갈아 요청을 보내고 순서를 무작위로 정하겠습니다. 동시 요청 수도 최대한 비슷하게 맞춥니다. 한쪽은 하나씩 생성하는데 다른 쪽에는 요청이 한꺼번에 몰리게 해서는 안 됩니다.

한 걸음 더 나아가 시간 범위를 작은 배치 여러 개로 나누고, 배치마다 A와 B를 모두 넣을 수 있습니다. 그러면 전체 결과뿐 아니라 차이가 특정 배치 하나에 몰려 있는지도 확인할 수 있습니다. 무작위 순서는 시간에 의한 교란을 줄이는 데 도움이 되지만, 공유 백엔드나 짧은 장애 같은 요인에서 오는 상관관계까지 저절로 없애 주지는 않습니다.

“지난주보다 나빠졌는가?”라는 종단적 질문은 다릅니다. 시간 자체가 연구하려는 변수이므로 양쪽을 같은 시점에 고정할 수 없습니다. 핵심 과제, 설정, 채점 기준을 최대한 그대로 유지하고, 관찰 기간마다 기준 서비스를 함께 다시 돌려야 합니다. 오늘의 결과를 지난주에 가장 잘 나온 그림 한 장과 계속 비교해서는 안 됩니다. 종단적 결과를 볼 때는 절대 합격률과 상대 차이를 모두 남겨 둡니다. 테스트 대상 서비스와 기준 서비스가 함께 떨어지면 둘 사이의 차이는 그대로일 수 있습니다. 그렇다고 사용자 경험이 나빠지지 않았다는 뜻은 아닙니다. 기준 서비스 역시 언제나 옳고 언제나 안정적인 정답은 아닙니다.

결과를 보면서 언제 멈출지 정하지 않기

“다섯 번 돌려 보고 A가 이기면 글을 올린다. A가 이기지 못하면 차이가 유의해질 때까지 계속 돌린다.” 샘플을 늘리는 것처럼 보이지만, 실제로는 통계 규칙을 바꾸는 일입니다. 고정 샘플 검정의 결과를 계속 들여다보다가 보이는 결과에 따라 멈추면, 그 검정이 원래 보장하던 위양성 통제가 무너집니다. 데이터를 계속 지켜봐야 하는 테스트라면 순차 분석을 위해 설계된 방법을 써야 합니다.⁵ 대부분의 사람이 순차 통계부터 공부할 필요는 없습니다. 가장 실천하기 쉬운 방법은 라운드를 시작하기 전에 몇 회를 돌릴지, 어떤 주요 지표를 쓸지, 어떤 주요 비교를 할지 적어 두고, 결과를 하나도 빼지 않고 보관하는 것입니다.

API와 채점 절차가 제대로 동작하는지 확인하려고 먼저 몇 번 호출해 보는 것은 괜찮습니다. 그것은 시범 실행입니다. 절차 수정을 마친 뒤에는 정식 테스트를 따로 시작해야 하며, 과제를 다듬던 단계의 결과를 정식 결과와 섞어서는 안 됩니다. 같은 원칙이 다른 두 습관에도 적용됩니다. 과제를 수십 개 시험해 보고 가장 유리해 보이는 하나만 공개하는 것, 또는 총점에서 밀리는 것을 보고 세부 항목 하나로 승리를 선언하는 것은 미리 합의한 비교가 아닙니다.

한 과제를 백 번 반복한 것을 백 개 과제로 취급하지 않기

반복 생성은 이 과제에서 서비스가 얼마나 믿을 만한지 알려 줍니다. 하지만 결론의 적용 범위를 저절로 넓혀 주지는 않습니다. 펠리컨을 안정적으로 그린다고 해서 코드 디버깅, 장문 분석, 복잡한 지시 수행까지 똑같이 믿을 만하다는 뜻은 아닙니다. 한 부류의 작업에 대해 추론할 때, 과제 간 편차와 한 과제를 반복 생성할 때의 편차는 서로 다른 종류의 불확실성입니다. 평가 연구는 반복 샘플링, 과제 수준의 비교, 군집된 상관 샘플의 처리를 따로 구분합니다.⁶

그래서 저는 먼저 프로브 하나로 반복성을 살펴본 뒤, 실제 용도와 관련된 고정 과제를 소수 추가하겠습니다. 양쪽이 같은 과제 세트에 답합니다. 합산하기 전에 과제별 결과와 과제별 차이를 먼저 계산하고, 총점 하나만 던져 놓지 않습니다. 여러 과제에 대해 정식 분석을 한다면 같은 과제, 같은 배치끼리의 대응 관계를 유지해야 합니다. “과제 10개, 과제당 10회”를 “서로 독립적인 과제 100개”로 취급해 앞의 단일 과제 계산을 그대로 가져다 쓸 수는 없습니다.

작은 함정도 하나 있습니다. 고정 seed는 재현 문제를 추적할 때 유용합니다. 하지만 같은 seed에서 거의 변하지 않는 출력을 스무 번 복사한 것은 무작위 출력 분포에 대한 독립 관측 스무 번이 아닙니다. 안정성을 측정할 때는 샘플링 전략을 미리 합의해야 합니다. seed를 지원하는 API라면 미리 생성해 둔 여러 seed를 쓸 수 있고, 지원하지 않는 API라면 그 한계를 기록해 둡니다. 과제 세트를 장기적으로 어떻게 갱신할지는 별도로 다뤄야 할 문제입니다. 적어도 이번 비교 안에서는 과제를 바꾸면서 새 점수와 옛 점수를 이어 “모델이 발전하고 있다”는 곡선을 그려서는 안 됩니다.

6. 타임아웃, 출력 잘림, 잘못 그린 그림은 한데 섞을 수 없습니다

흔한 통계 왜곡 가운데 하나는 성공적으로 돌아온 작품만 채점하고 타임아웃과 오류는 지워 버리는 것입니다. 이렇게 얻은 점수는 “완전한 출력을 받은 뒤라면 얼마나 자주 합격하는가?”에 답할 뿐, 사용자가 더 신경 쓰는 질문인 “요청을 한 번 보내면 합격 결과를 받을 수 있는가?”에는 답하지 않습니다. 요청 20회를 미리 배정했고, 그중 4회가 타임아웃됐다고 가정해 보겠습니다. 나머지 16회는 완전한 작품을 돌려주었고, 그중 8회가 합격했습니다. 완전한 출력 가운데 합격률은 50%입니다. 그러나 요청 20회 전체로 계산한 첫 전달 합격률은 40%입니다. 앞의 숫자만 공개하면 사용자가 아무것도 받지 못한 네 번이 빠집니다.

저는 세 종류의 결과를 함께 남기겠습니다. 기술적으로 전달에 실패한 경우, 완전히 반환됐지만 과제에 불합격한 경우, 완전히 반환되고 과제에도 합격한 경우입니다. 타임아웃, API 오류, 스트림 끊김, 길이 제한 도달은 각각 원인을 따로 기록합니다. 따로 기록한다고 해서 서비스 장애를 면책하는 것은 아닙니다. 서비스를 고르는 사람에게는 타임아웃이든 잘못 그린 그림이든 모두 시간을 잡아먹습니다. 다만 원인을 추적할 때는 이 모두를 “모델의 지능이 떨어졌다”로 묘사해서는 안 됩니다. 로컬 네트워크나 테스트 스크립트의 장애는 따로 분류합니다. 그것을 제외할지는 미리 적어 둔 규칙에 따라야 하며, 어느 쪽이 졌는지 본 뒤에 샘플을 지울 수는 없습니다.

저는 첫 요청에서 합격 결과를 받은 비율을 주요 지표로 삼고, 완전한 출력 중 내용 합격률, 기술적 실패율, 소요 시간, 비용은 그 옆에 보조 설명으로 두는 편을 선호합니다. 완전한 출력의 내용 합격률도 편향 없는 ‘순수 능력 점수’는 아닙니다. 복잡한 요청일수록 타임아웃되기 쉽다면, 남은 작품은 애초에 쉬운 쪽이었을 수 있습니다. 이 비율은 문제를 찾아내는 데 도움이 되지만, 모든 요청을 기준으로 센 결과를 대신할 수는 없습니다.

“한 번 고쳐 주면 성공하는가?”는 양쪽에 같은 수정 기회를 주는 별도 테스트로 다룰 수 있습니다. 한쪽은 다섯 차례나 끈기 있게 바로잡아 주고, 다른 쪽은 첫 실수에 바로 탈락시켜서는 안 됩니다.

7. 일반인도 실제로 해 볼 수 있는 최소한의 대조 실험

펠리컨 하나를 테스트하려고 평가 플랫폼부터 만들 필요는 없습니다. 아래는 시작용 계획입니다. 하나의 고정 프로브에서 뚜렷한 차이를 확인하기 위한 것이지, 작은 성능 저하를 반드시 잡아내도록 샘플 수를 설계한 것은 아닙니다.

펠리컨 과제라면 소박한 합격 기준으로 시작해도 좋습니다. 파일이 합의한 환경에서 정상적으로 렌더링됩니까? 펠리컨과 자전거가 알아볼 수 있을 만큼 온전합니까? 핵심 구조가 명백히 틀리지는 않았습니까? 발과 페달처럼 과제가 요구하는 접촉 관계가 실제로 성립합니까? 미적 완성도는 따로 적어 둘 수 있지만, 공들인 색감이 구조적 오류를 상쇄할 수는 없습니다.

경계선에 있는 샘플을 두고 판단이 서지 않으면 ‘이견 있음’으로 표시하고 미리 정한 재검토 규칙에 따라 처리합니다. 채널 이름을 본 뒤에 통과 여부를 정해서는 안 됩니다. 소규모 테스트는 사람이 블라인드로 채점해도 됩니다. 규모가 커지면 자동 채점과 심사 모델 보정이 다음 과제가 되지만, 첫 라운드에서 모두 해결할 필요는 없습니다. 라운드에 속하는 설정과 호출마다 한 행씩 쌓이는 로그를 나눠 두면 기록이 훨씬 쉬워집니다. 라운드 설정에는 원본 요청 템플릿, 파라미터, 과제 버전, 채점 규칙 버전, 시간 범위, 타임아웃과 재시도 약속을 저장합니다. 각 호출에는 적어도 다음 필드를 기록해야 합니다.

run_id,block_id,service,service_group,requested_model,returned_model,started_at,request_hash,status,finish_reason,latency_ms,qualified,failure_reason,artifact_path

시간은 시간대를 포함한 형식으로 씁니다. 원본 응답, 추출한 SVG, 렌더링한 이미지는 artifact_path로 연결합니다. 토큰 사용량, 백엔드 핑거프린트 등 API가 노출하는 정보도 함께 저장할 수 있습니다. 제공되지 않았다면 비워 두거나 ‘알 수 없음’으로 기록합니다. request_hash는 요청이 같았는지 확인하는 용도이며 원본 요청 자체를 대신하지 못합니다. 로그를 저장하거나 공유할 때는 API 키를 제거하고, 개인적인 컨텍스트나 그 밖의 민감한 내용은 가려야 합니다. 공개 검증에 필요한 것은 실험 조건이지, 계정 자격 증명까지 함께 넘기는 것이 아닙니다.

집계할 때는 먼저 전체 차이와 배치별 결과를 봅니다. 앞에서 다룬 이항 구간과 Fisher 정확 검정은 독립성, 안정성 같은 가정이 대체로 성립할 때 적용됩니다. 결과가 배치의 영향을 뚜렷하게 받거나, 나중에 여러 과제의 반복 테스트로 확장한다면 대응 설계에 맞는 분석을 해야 합니다. 단일 과제 공식을 기계적으로 재사용해서는 안 됩니다. 처음 발견한 차이가 추적할 가치가 있다면, 새로 미리 정한 시간 범위에서 다시 테스트하고 실제 용도와 관련된 과제를 추가합니다. 첫 라운드는 이상 징후의 단서일 뿐입니다. 독립된 새 라운드가 있어야 그 현상이 계속되는지 판단하는 데 도움이 됩니다.

8. 차이를 발견한 뒤, 결론은 어떻게 써야 합니까?

앞의 교육용 수치를 그대로 쓰면, 절제되면서도 쓸모 있는 결론은 다음과 같이 쓸 수 있습니다.

이번 라운드의 고정 과제, 동일한 가시 설정, 미리 정한 시간 범위에서 A와 B를 각각 20회 테스트했습니다. 첫 전달 합격은 각각 16회와 8회였으며, 샘플 합격률의 차이는 40%p입니다. 독립 샘플링 등의 가정 아래에서 양측 Fisher 정확 검정의 p값은 약 0.0225로, 이번 라운드의 조건에서 차이가 있다는 판단을 뒷받침합니다. 이 결과는 다른 시간 범위와 관련 과제에서 추가로 검증해야 하며, 그것만으로 기반 모델이나 서버 설정 변화의 구체적인 원인을 식별할 수는 없습니다.

“풀성능 확정”만큼 자극적이지는 않습니다. 대신 다음 사람이 다시 검증하는 데 필요한 조건을 넘겨줍니다. 시간대를 바꾸고 관련 과제를 넓힌 후속 테스트에서도 계속 같은 방향의 결과가 나온다면, 이 서비스가 이런 용도에서 기준 서비스보다 덜 믿을 만하다고, 또는 자신의 과거 베이스라인보다 실제로 뒤처졌다고 말할 더 강한 근거가 생깁니다. 하지만 “전달 품질이 나빠졌다”에서 “몰래 더 작은 모델로 바꿨다”로 건너뛰는 것은 여전히 한 단계를 더 나아가는 일입니다. 구체적인 메커니즘을 확인하려면 검증 가능한 경로 기록이나 설정 기록처럼 여러 설명을 서로 구별할 수 있는 독립 증거가 필요합니다. 출력 스타일만으로 모델을 짐작할 수는 없습니다.

그렇다고 사용자가 원인이 밝혀질 때까지 기다려야만 서비스를 바꿀 자격이 생긴다는 뜻은 아닙니다. 서비스 선택은 그 서비스가 요구 사항을 충족하는지에 달려 있습니다. 특정 원인을 지목하려면 그 원인에 관한 증거가 필요합니다. 두 가지는 분리해서 볼 수 있습니다.

9. 정말 아껴야 할 것은 문제를 분명히 증명하는 비용입니다

수동 테스트에서 가장 지치는 부분은 대개 실행 버튼을 누르는 일이 아닙니다. 그 뒤에 이어지는 반복 작업입니다. 파일은 어디에 있습니까? 파라미터가 바뀌지는 않았습니까? 이 그림은 몇 번째 생성입니까? 재시도한 결과입니까? 스크린샷과 원본 응답을 아직 짝지을 수 있습니까? 이런 기록이 없으면, 그때는 확신했던 “정말 너프됐다”는 생각도 일주일 뒤에는 아무도 다시 검증할 수 없는 스크린샷 몇 장으로만 남을 수 있습니다.

여러 서비스가 어떻게 동작하는지 먼저 대략 알고 싶을 뿐이라면, 모두가 처음부터 다시 정리할 필요는 없습니다. Folkbench에서 공개 순위와 보고서 입구를 살펴보고, 관심 있는 모델, 서비스 그룹, 지표에 이미 결과가 있는지 확인할 수 있습니다. 공개 페이지는 같은 모델 안에서 서비스들을 비교한다는 점을 강조하며, 순위 페이지에도 어떤 행의 그룹 데이터가 그 중계 서비스의 모든 그룹을 대표하지는 않는다는 안내가 있습니다.⁷

공개된 순위는 정보를 모으고 정리하는 비용을 줄여 주어야 합니다. 조건 확인을 그만둘 이유가 되어서는 안 됩니다. Folkbench를 포함해 어떤 순위든 계속 물어볼 가치가 있습니다. 언제 측정했는지, 무엇을 측정했는지, 샘플은 얼마나 되는지, 실패를 남겨 두었는지, 결론이 어떤 범위까지 적용되는지 말입니다. 공개되지 않은 정보는 여전히 ‘알 수 없음’입니다. 처음 질문으로 돌아가 보겠습니다. ‘모델이 너프됐다’는 말 가운데 얼마가 사실이고, 얼마가 한 번의 샘플링이 만든 착각입니까?

공통된 정의, 완전한 샘플, 비교 가능한 조건이 갖춰지기 전에 전체 비율 하나를 내놓는 것은 새로운 미신을 하나 더 만들 뿐입니다. 우리가 더 잘할 수 있는 일은 구체적인 의심 하나하나를 단계적으로 검증 가능한 판단으로 바꾸는 것입니다. 실패를 보면 원본 결과를 남깁니다. 성능 저하가 의심되면 대조 실험을 시작합니다. 차이를 발견하면 그때 원인을 추적합니다. 이 모든 단계를 스크린샷 한 장 안에서 한꺼번에 끝내려 해서는 안 됩니다. 스크린샷 한 장은 좋은 질문을 던질 수 있습니다. 하지만 그 질문에 답하려면 제대로 된 실험이 필요합니다.

주석 및 참고 자료