체크리스트는 모두 통과했다. 핵심만 빠져 있었다 — 요약 서브 에이전트를 Haiku로 만든 경험

결론

요약 담당의 서브 에이전트를 Claude Haiku 5.5로 낮추고, Opus 5.5와 동일한 원문 14건을 요약하게 했습니다. Haiku는 숫자나 인용도 틀리지 않았습니다. 수치와 영어 인용을 원문과 기계적으로 대조했을 때, 어떤 조건에서도 조작(捏造)은 0건이었습니다.

대신 Haiku는 핵심을 놓쳤습니다. 13건 중 4건에서, 기사가 가장 말하고 싶은 내용이 요약에서 빠져 있었습니다. 두 번 시도했고 두 번 모두 같았습니다.

대조(照合)로는 이 누락을 잡아낼 수 없습니다. 대조할 수 있는 것은 '쓰여진 것'이 맞는지 여부이며, 쓰여지지 않은 것은 대조 입력에 아예 들어가지 않기 때문입니다.

누락을 방지한 것은 프롬프트에 추가한 하나의 절차였습니다. '글을 쓰기 전에, 저자의 핵심을 1문장으로 정하라'고 판단을 먼저 외부로 표출하게 하자, Haiku는 두 번 모두 13건의 모든 핵심을 포착했습니다.

이 글은 그 비교 기록입니다. 다만 한 가지 단서가 있습니다. '저렴한 모델은 틀리지 않는다'라고 말할 수 없었습니다. 대조를 빠져나간 오류가 1건 있었습니다. 그것까지 포함하여 작성합니다.

제1부: 무엇을 시도했는가

동기: Explore는 아직 Opus로 작동하고 있다

Haiku 5.5가 출시된 주에 r/ClaudeCode에 'Haiku 5.5는 Opus 5.5의 40분의 1이다. 당신의 Explore 서브 에이전트는 아직 Opus로 작동하고 있을지도 모른다'라는 스레드가 올라왔습니다. Haiku 5.5는 100k 토큰 이하 프롬프트에서 입력 $0.10・출력 $0.50(/MTok)이며, Opus 5.5는 $4・$20이므로 단가는 정확히 40분의 1이 됩니다(요금 페이지).

저는 기사 요약을 서브 에이전트에게 맡기고 있습니다. 읽을 양이 많고 출력 형태도 정해져 있습니다. Haiku로 낮추어 테스트하기에 가장 직관적인 후보입니다.

설계: 추출을 포함하지 않고, 요약만 비교하다

비교하고 싶은 것은 모델의 차이점뿐이므로, 추출 과정의 변동성을 제거했습니다. 10/9에 웹 기사 14건의 본문을 가져와 저장했고, 같은 파일을 각 조건에 읽게 했습니다. CAPTCHA나 타임아웃으로 인해 조건별로 읽을 수 있는 원문이 달라지면, 차이가 모델에서 나온 것인지 추출 과정에서 나온 것인지 알 수 없게 됩니다.

14건 중 1건(WSJ)은 CAPTCHA 때문에 본문을 가져오지 못했습니다. 이것은 '가져오지 못했다'고 적는지 확인하기 위해 남겨두었습니다.

조건은 2×2로 설정했습니다.

'유형(型)'은 프롬프트에 추가한 다음 절차입니다. 각 기사에 대해, 쓰기 시작하기 전에 세 가지를 정하게 했습니다.

(1) 저자의 중심 주장을 1문장으로. 무엇이 일어났는지가 아니라, 왜인지・독자는 무엇을 바꿔야 하는지. 원문에 핵심을 나타낸 영문이 있다면 그대로 인용한다.

(2) 그것을 뒷받침하는 근거를 2~3개 (원문의 수치・구조).

(3) 가져오지 못한 부분

유형 없음 프롬프트는 이전에 사용하던 요약 지시 그대로입니다.

판정: 조건을 숨기고, 다른 판정자에게 2회 채점하게 하다

누락은 대조로는 셀 수 없기 때문에, 사람이나 상위 모델이 판정할 수밖에 없습니다. 여기서는 Opus의 서브 에이전트를 판정자로 사용했습니다. 판정에도 상위 모델을 사용했다는 점은 미리 말씀드립니다.

• 판정자는 먼저 원문을 읽고, 각 기사의 핵심을 스스로 정합니다. 그 후, 조건을 숨기고 순서를 섞은 요약을 채점합니다.
• 항목은 2개이며, 각각 0/1입니다.
  핵심(의역으로도 괜찮으니 포함되었는지)과, 추출의 한계(이미지로 가져오지 못한 표, 중간에 잘린 본문, CAPTCHA 등을, 원문에 그것이 있는 기사에서 작성했는지) - 첫 번째를 보고 판정하지 않은 판정자에게 순서를 바꿔 다시 채점하게 했습니다. 일치도는 핵심 76/78, 추출의 한계 54/54였습니다.

유형 있음 출력에는 '핵심'이라는 제목이 붙습니다. 판정 패킷에서는 제목을 제거했지만, 서두의 첫 문장이 주장이 되는 구성으로 조건이 드러날 가능성은 남아 있습니다.

제2부: 오류와 누락은 별개다

결과

핵심의 분모는 13(본문이 없는 WSJ 제외), 추출의 한계의 분모는 10(원문에 그것이 있는 기사). 두 번째 판정 수치로 제시합니다.

| 조건 | 핵심 | 추출의 한계 | 조작 (대조) | |
|---|---|---|---|
| Haiku 유형 없음 (2회) | 9/13, 9/13 | 2/10, 2/10 | 0건, 0건 |
| ... |10/10, 9/10 |
0건, 0건 |
| Opus 유형 있음 (1회) | 12/13 | 10/10 | 0건 |

읽을 수 있는 것은 세 가지가 있습니다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

• 형태 없는(型なし) Haiku는 두 번 모두 13건 중 4건에서 핵심을 놓쳤다. Opus는 형태가 없어도 12~13/13이다.
• 취득의 한계(取得の限界)를 적지 않는 것은 Haiku만의 문제는 아니다. 형태가 없으면 Opus도 3~4/10밖에 쓰지 못했다.
• 형태를 넣자, Haiku의 핵심은 13/13이 되었고, 취득의 한계는 두 모델 모두 9~10/10이 되었다.

실제 사례: GPT-6 발표 기사

가장 차이가 많이 보인 곳은 OpenAI의 'GPT-6 and Intelligent UI for everyone'이다. ChatGPT 답변에 그림, 버튼, 폼 등을 결합하는 'Intelligent UI' 발표에서, 기사는 이렇게 마무리된다.

Instead of people adapting to software, software will adapt to people.

(사람이 소프트웨어에 맞추는 것이 아니라, 소프트웨어가 사람에게 맞추게 될 것이다.)

형태 없는 Haiku (1차)의 요약은 다음과 같았다.

OpenAI 발표. ChatGPT의 GPT-6에 'Intelligent UI'를 도입하여 답변에 텍스트뿐만 아니라 그림, 버튼, 폼, 그래프, 간편 도구 등의 인터랙티브 요소가 포함되도록 했다. 모델은 Plus・Pro・Business・Enterprise가 GPT-6 Sol이고, Free・Go가 GPT-6 Luna이다。(중략) 웹 검색이 필요한 질문에서는 GPT-6 Instant가 GPT-5.6 Instant보다 '44% sooner' 답변을 시작한다고 한다(사내 평가).

쓰여진 내용은 전부 맞다. '44% sooner'도 원문 그대로다. 다만, 무엇이 나왔는지는 알 수 있어도, 왜 OpenAI가 이것을 발표했는지 알 수 없다.

형태 있는 Haiku는 핵심에 이 마무리 문장을 배치하고, 게다가 마지막에 이렇게 썼다.

취득 부족: 인터랙티브 UI의 실제 사례 영상・이미지는 본문에 없다. 본문 중 요리 예시는 GPT-5.6 Instant의 출력으로 표시되어 GPT-6의 출력이 아니다.

원문을 보면, 확실히 본문에서 가져온 예시는 'GPT‑5.6 Instant' 제목 아래에 있다. Intelligent UI가 어떻게 보이는지에 대한 실제 사례는 취득한 텍스트에는 들어있지 않았다. 형태 없는 요약은 Haiku와 Opus 모두 이것을 쓰지 않았고, 독자는 전부 읽은 요약이라고 생각하며 읽는다.

실제 사례: SemiAnalysis의 구독 분석

SemiAnalysis의 'Anthropic의 구독 서비스는 OpenAI보다 5배 이상의 가치가 있다' 역시 형태 없는 Haiku가 두 번 모두 핵심을 놓친 기사다.

저자의 주장은, 플랜의 가치는 플랜 단독으로는 결정되지 않는다는 것이다.

it doesn't make sense to say a plan is worth $X in isolation—you need to consider the full (plan, model, workload) tuple

(플랜이 단독으로 $X의 가치가 있다고 말하는 것은 의미가 없다. (플랜, 모델, 작업 내용) 전체 튜플을 고려해야 한다.)

형태 없는 Haiku는 '구독 서비스는 수익의 약 10%지만 추론 계산의 40% 이상을 차지한다', '중간급 모델로 약 5배'와 같은 숫자는 정확하게 가져왔다. 반면, 이 '튜플로 생각해야 한다'는 입장은 쓰지 않았다. Opus(형태 없음)가 쓴 '이용률 100%라면 Opus 5.5의 총이익은 -369%'나, 상한선이 예고 없이 바뀐 사례도 Haiku의 요약에는 없다.

취득 면에서도 차이가 났다. 이 기사는 그래프와 표가 이미지이고, 취득한 텍스트에서는 수치 일부만 읽을 수 있다. 끝부분도 Cursor와의 비교 도입부에서 끊겨있다. 형태 없는 Haiku는 1차 때는 둘 다 쓰지 않았고, 2차 때는 끝부분의 단절만 쓰고, 이미지 누락은 쓰지 않았다.

형태 있는 Haiku는 핵심에 이 tuple 문장을 배치했다. 게다가 원문이 전반부에서 '약 5배'라고 쓰고, 후반부 반론 부분에서 '~4x'라고 쓰는 모순을 스스로 지적했다. Opus의 요약은 이 모순에 언급하지 않았다.

대조(照合)가 유지되는 것은 한 칸뿐

지금까지의 결과를 대조 스크립트에서 보면 다음과 같다.

要約の内容を「書いた/書かなかった」と「書くべきだった/書かなくてよかった」の2軸で分けた図。照合の網がかかるのは「書いた」の行だけで、欠落は網の外にある。網にも「1.2億」が通過した穴がある

그림: 대조의 그물(점선)이 걸리는 것은 위 줄만이다. 왼쪽 아래의 결락은, 그물 밖에서 아무것도 내보내지 않고 지나간다.

대조가 작동하는 것은 위 줄뿐이다. 아래 줄은 쓰여있지 않으므로, 대조 입력에 들어가지 않는다. 형태 없는 Haiku의 요약은, 위 줄에서는 '전체 일치'였다.

이 상황은 낯익었다. 이번에 다룬 14개의 글 중 Every의 기사 「다음 지시를 추가하기 전에, 하나 줄여보자」에서 저자가 Codex에게 원인을 조사시킨 답변과 같았다.

Agent workflow에서는 구체적인 규칙(concrete rules)이 검증하기 쉬기 때문에, 모든 체크리스트가 통과하더라도 그보다 미묘한 것들을 압도할 수 있다.

수치와 인용 같은 구체적인 것은 검증하기 쉽다. 핵심이라는 미묘한 것은 검증할 수 없다. 검증 가능한 것만 보고 있으면, 전부 통과한 것처럼 보이면서 핵심이 사라진다.

요약은 예외와 한계를 누락시키기 쉬우며, 이 자체는 이전부터 느끼고 있던 것이었다. 이번에 밝혀진 것은 그것이 두 종류가 있다는 것이다. 핵심의 결락(欠落)은 주로 저사양 모델에서 발생했고 (Opus에서도 13건 중 1건은 놓쳤다), 취득의 한계의 결락은 Opus에서도 발생한다. 후자가 더 심각하다. 요약문을 읽는 사람에게는 빠진 것이 보이지 않는다.

이전 기사에서는 저사양 모델에 위임하는 것이 실패가 감지되기 쉬울 때 유용하다고 쓰면서, 잘못된 요약문이 상위 판단을 오염시키는 '조용한 전파적 실패(静かに伝播する失敗)'는 비용식 외부에 두었다. 이번에 그 내용물을 측정할 수 있었다. 요약의 실패에는 대조(照合)로 잡히는 '오류'와, 대조로는 원리적으로 잡을 수 없는 '결락'이 있다.

다른 기사에서는 평가를 생성기가 제어할 수 없는 신호, 예를 들어 원문과의 교차 대조에 두라고도 썼다. 대조는 위조(捏造)에는 효과적이었다. 결락에는 도달하지 못했다.

대조 스크립트도 틀린다

대조가 지켜야 할 상위 부분에도 구멍이 있었다.

사용하는 것은 직접 만든 check-digest-facts.py로, 요약문 중 2자리 이상의 숫자와 큰따옴표로 묶인 5단어 이상의 영어 문구가 원문에 실제로 존재하는지 확인한다. 원문에 없는 것을 '재확인 필요'로 표시하고, 마지막은 내가 원문을 보고 판단한다.

대조를 빠져나간 오류. 타입이 없는 Haiku의 두 번째 판에서 GPT-6 기사를 '주 1.2억 명 이상의 사용자에게 전개'라고 작성했다. 원문은

또 한 가지, 솔직하게 적어둘 것이 있다.

10월 9일에 첫 비교를 했을 때, 메인 Opus는 Every의 기사를 보고 'Haiku가 핵심을 놓쳤다'고 판단하여 이 기사의 하이라이트로 삼으려 했다. 숫자는 모두 맞았지만, 기록과 규칙을 구분하지 못했다는 핵심적인 부분이 빠져 있다고 본 것이다.

그런데 조건이 숨겨진 두 명의 판정자는 Every를 6개 모두 '핵심 있음'으로 판단했다. 틀에 박히지 않은 Haiku도 앞서 Codex의 인용을 작성했고, 그 덕분에 '왜(why)'는 쓸 수 있다고 판단되었다. 하이라이트는 GPT-6과 SemiAnalysis로 바뀌었다.

상위 모델의 판정 역시 한 번으로는 흔들린다. 조건을 숨기고 판정자를 바꿔서 다시 해보면, 판정이 갈리는 기사와 그렇지 않은 기사가 구분된다. 누락된 부분을 세려면 이 과정은 생략할 수 없다.

제3부: 누락을 막는 방법은 '판단을 밖으로 꺼내는 것'

틀(型)이 하는 일

제1부의 틀은 요약 전에 '저자의 핵심은 무엇인가'라는 판단을 한 문장으로 작성하게 한다. 틀에 박히지 않은 Haiku도 사실 자체는 올바르게 나열했다. 부족했던 것은, 나열된 사실들 중 어떤 것이 기사의 중심인지에 대한 판단이었다. 그 판단을, 쓰기 전의 절차로 밖으로 꺼냈다.

(3) '획득하지 못한 부분'도 마찬가지다. 틀이 없으면 모델은 손안의 텍스트를 전부라고 요약한다. (3)을 먼저 작성하게 하니, 이미지로 가져오지 못한 표나 중간에 끊긴 본문을 스스로 언급하기 시작했다. Opus에서도 틀이 없었을 때는 10개 중 3~4개였다. 이곳을 채운 것은 모델의 지능이라기보다 절차 덕분이었다.

지금까지 나는 '판단은 상위 모델에 남기고, 정형적인 작업은 하위 모델에 맡긴다'고 써왔다. 이번 결과는 그것을 조금 바꾼다. 판단의 내용을 지시로 밖으로 꺼낼 수 있다면, 하위 모델도 판단을 가질 수 있다. 적어도 '이 기사의 핵심은 무엇인가' 정도의 판단은 틀 하나만으로 13개 중 9개에서 13/13으로 늘어났다.

시간과 토큰은 줄지 않았다

속도는 기대하지 않는 것이 좋다. 틀이 있는 Haiku는 첫 번째에 232초, 두 번째에 136초로, 틀이 없는 Opus(110124초)보다 느렸다. 소비된 토큰도 어떤 조건에서든 137k161k로 거의 비슷했다. 대부분은 원문을 읽는 입력이라 모델을 바꿔도 읽는 양은 변하지 않는다.

줄어든 것은 단가뿐이다. 그것도 프롬프트가 100k 토큰을 넘으면 Haiku는 $0.50에서 $2.50로 오르기 때문이다. Opus 5.5에는 길이에 따른 계단 현상이 없으므로, 차이는 8분의 1로 줄어든다. 긴 원문을 모아서 읽게 하는 방식에서는 40분의 1을 전제로 하지 않는 것이 좋다.

틀을 추가하는 것은 Every의 경고에 위배되지 않는가?

여기는 독자들에게 지적받을 것 같아 미리 적는다. Every 기사의 결론은 '지시를 더하기 전에, 하나 줄여보라'였다. 나는 Haiku를 위해 틀을 추가했고, 게다가 '작업 정보를 본문에 쓰지 말라'는 것을 한 문장 더 추가했다.

틀에 대해 말하자면, 추가한 것은 규칙이 아니라 순서라고 생각한다. Every에서 깨진 것은 두 번 말했다는 수정 사항이 그 이후의 모든 원고의 규칙으로 쌓였기 때문이다. 틀은 1회 요약 안에서의 절차이며, 쌓이지 않는다.

반면에 '작업 정보를 쓰지 말라'는 것은 실패를 보고 추가한 규칙 그 자체다. Every가 말하는 누적 추가의 입구에 가깝다. 이것은 추가한 채로, 반년 후에 정리할 대상으로서 기록해 두었다.

마무리

비용 이야기부터 시작했지만, 마지막으로 남은 것은 '무엇을 검증할 수 있고, 무엇을 검증할 수 없는가'라는 이야기였다.

이전 기사에서는 단가가 낮아져도 토큰이 늘어나 총액은 줄지 않는다고 썼다. 이번에는 반대의 경우다. 토큰은 거의 같았기 때문에, 단가의 차이가 그대로 효과를 발휘했다. 싸진 부분을 무엇으로 메웠냐면, 누락이었다.

에이전트의 정밀도는 검증할 수 있는 범위에서 결정되는 것이 아닐까라고 전에 썼다. 거기에서는 설계 판단이나 제약을 미리 문서로 고정하는 것도 검증 수단에 포함했다. 이번 틀도 같은 움직임이다. 대조라는 사후 검증이 미치지 못하는 누락을, 쓰기 전에 판단을 고정시킴으로써 메웠다.

지금 매일 아침 요약은 틀이 있는 Haiku로 돌리고 있다. 2일간의 실전에서는 조작(hallucination)이 0건이었고, 가져올 수 없었던 기사는 가져오지 못했다고 썼다. 핵심을 놓치지는 않았는지는 대조로는 알 수 없다. 그래서 가끔 조건이 숨겨진 상태로 다시 세어본다.

Discussion