0.05점 받은 요약이 사실 가장 정확했다 — AI 검사기가 말투를 재고 있었다

📝 한줄 요약

AI가 만든 요약을 검사하는 장치를 붙여놨는데, 알고 보니 그게 요약의 품질이 아니라 영상 진행자의 말투를 재고 있었습니다. 검사 기준을 바꾸자 그동안 탈락하던 자료가 되살아나 위키가 두 배 가까이 늘었습니다.

바쁘시면 이것만 읽어도 돼요:

• 유튜브 전사를 정리해 개인 위키로 쌓는 도구에 검색 기능을 붙이고, 검증 장치 두 개를 고쳤습니다

• 자료 8편 중 5편이 탈락했는데, 원인은 요약이 부실해서가 아니라 검사 기준이 잘못 설계돼서였습니다

• 점잖은 발표체 영상은 0.75점, 편하게 말하는 강의는 0.05점을 받았습니다. 요약 품질은 후자가 더 좋았는데도요

• 검사 기준을 세 가지 대안으로 직접 재보고 가장 나은 것을 골랐습니다. 두 개는 실측해보니 효과가 없어서 버렸습니다

• 구현을 맡긴 AI가 "이 조건은 논리적으로 통과할 수 없다"며 작업을 거절했고, 확인해보니 제 지시가 틀렸습니다

• 되돌릴 지점 없이 일하고 있었다는 걸 뒤늦게 발견하고 기준점부터 만들었습니다

🎯 이런 분들께 도움돼요

• AI에게 일을 시켜봤지만 "결과물을 어떻게 믿을지"에서 막히는 분

• AI가 만든 것을 검사하는 장치를 붙였는데 잘 작동하는지 확신이 없는 분

• 자료가 쌓이기만 하고 정리가 안 되는 분

😫 문제 상황 (Before)

지난 편에서 유튜브 전사를 자동으로 정리해 개인 위키로 쌓는 도구를 만들었습니다. 전사 파일을 넣으면 주제를 분류하고, 정리 노트를 쓰고, 원문을 제대로 인용했는지 검사한 뒤 위키 페이지로 올려주는 흐름이었죠.

그때 계획에 이렇게 적어뒀습니다. "다음으로 검색 기능을 붙이거나, 쌓인 위키 위에서 질문에 답하는 에이전트로 확장할 예정."

이번엔 그 검색을 붙이려고 앉았습니다. 그런데 시작하자마자 벽에 부딪혔어요. 검색할 게 없었습니다. 위키에 노트 한 건, 페이지 세 건이 전부였거든요. 이 상태로 검색을 만들면 "잘 되네요"라고 말할 수는 있어도 그게 정말 잘 되는 건지 알 방법이 없습니다.

🛠️ 사용한 도구

• 도구: Claude Code (설계·검증), Codex CLI (구현)

• 모델: Claude Opus 5 / GPT-5.6

• 특이사항: 설계와 검증은 Claude가, 실제 코드 작성은 Codex가 맡는 분업. 만든 쪽과 검사하는 쪽을 다른 프로그램으로 분리해 자기 채점을 막는 구조입니다

🔧 작업 과정

검색을 만들려는데 검색할 게 없었다

먼저 재료부터 채워야 했습니다. 다행히 집에 있는 맥미니가 유튜브 전사를 계속 모으고 있어서, 거기서 8편을 가져왔습니다.

고를 때 한 가지를 신경 썼습니다. 한 채널에서만 뽑으면 안 된다는 점이요. 정리된 위키 페이지는 서로 링크로 연결되는데, 주제가 한 곳에 몰리면 링크가 얽히지 않습니다. 그러면 나중에 "끊어진 링크 찾기" 같은 기능을 만들어도 검사할 대상 자체가 없어져요.

그래서 뇌과학 강의 3편, 투자 2편, 학습법 2편, 사주명리 1편으로 흩뿌리되, 각 묶음 안에서는 주제가 이어지게 골랐습니다. 뇌과학 3편은 기억·세포·단백질로 서로 닿아 있는 식으로요.

8편을 파이프라인에 통과시키는 데 34분이 걸렸습니다. 결과를 보니 3편만 통과하고 5편이 탈락했습니다.

8편 중 5편이 탈락했다

탈락 사유는 전부 같았습니다. "커버리지 부족". 정리 노트가 원문을 충분히 다루지 못했다는 뜻입니다.

이상했던 건 점수 분포였어요.

통과: 0.40  0.50  0.75
탈락: 0.05  0.15  0.15  0.25  0.30

가장 낮은 0.05점을 받은 건 15,147자짜리 강의였습니다. 이 프로젝트에서 가장 길고 내용이 조밀한 자료요. 반대로 0.75점을 받은 건 4,185자짜리 짧은 영상이었고요.

긴 자료일수록 점수가 낮았습니다. 뭔가 이상하다는 생각이 들어서 검사기를 열어봤습니다.

'하기'가 217번 나왔다

검사 방식은 이랬습니다. 원문에서 가장 자주 나오는 단어 20개를 뽑고, 그게 요약에 얼마나 등장하는지 세는 겁니다. 전제는 단순합니다. 자주 나오는 말이 곧 핵심일 테니까요.

0.05점을 받은 강의에서 그 20개를 실제로 뽑아봤습니다.

하기(217) 이게(43) 돼요(36) 다음에(35) 거예요(35) 있어요(29)
그러면(27) 하면(26) 이렇게(22) 어떻게(21) 이거(21) 그럼(20)
요거(20) 바로(20) 요게(16) 뭐냐면(16) 아미노산(15) 이제(14)
이빨(13) 다시(12)

20개 중 내용어는 '아미노산'과 '이빨' 둘뿐입니다. 나머지 열여덟은 강의하시는 분의 말버릇이에요.

1위인 '하기'는 더 황당했습니다. 원문을 찾아보니 이렇게 되어 있었습니다.

좋은 던짐하다 하기 하기 하기 하기 하기 하기 하기 하기...

음성을 글로 옮기는 프로그램이 무음이나 잡음을 잘못 알아들은 겁니다. 그게 217번 반복돼서 1위를 차지했고요.

그런데 정작 이 강의의 요약은 이렇게 쓰여 있었습니다.

"진핵세포 단백질 합성 과정 중 rRNA 가공과 리보솜 소단위체·대단위체 조립, tRNA의 구조·성숙 과정을 설명한 뒤, 유전암호(코돈)표를 쉽게 암기하는 방법을 다루고…"

요약은 훌륭합니다. 전문 용어를 정확히 잡았어요. 그런데 '요거'와 '뭐냐면'을 안 썼다는 이유로 0.05점을 받았습니다.

그제서야 0.75점의 정체도 알았습니다. 그 영상은 "~습니다" 체로 또박또박 발표하는 형식이라 자주 나오는 말이 '포토리딩', '공인', '지도자' 같은 내용어였던 겁니다.

검사기가 재고 있던 건 요약의 품질이 아니라 영상의 말투였습니다.

세 가지 대안을 실제로 재봤다

여기서 바로 고치지 않고, 대안 세 가지를 프로토타입으로 만들어 같은 자료에 돌려봤습니다. 머릿속으로 "이게 나을 것 같은데"라고 판단하면 틀릴 때가 많으니까요.

두 번째 방식은 그럴듯해 보였는데 실측하니 별로였습니다. 자료가 8편뿐이라 통계가 부족했고, 영어가 섞인 자료에서는 오히려 'the'나 'and'가 상위로 올라오는 부작용까지 생겼어요.

채택한 건 세 번째, 자료를 열 구간으로 나눠 각 구간의 특징적인 말이 요약에 반영됐는지 보는 방식입니다. 이게 좋았던 이유가 두 가지예요.

말버릇은 처음부터 끝까지 고르게 나옵니다. 그래서 "이 구간에서 유독 두드러진 말"을 찾으면 자동으로 걸러집니다. 금지어 목록을 사람이 계속 채워 넣지 않아도 되는 거죠.

그리고 구간 개수가 고정이라 자료가 길든 짧든 같은 잣대로 잽니다. 실제로 가장 긴 영상과 가장 짧은 영상이 똑같이 0.70점이 나왔습니다. 길이 때문에 불리해지는 문제가 사라진 겁니다.

효과 없다고 판명된 두 방식은 그냥 버리지 않고 "왜 버렸는지"를 지시문에 적어뒀습니다. 안 그러면 구현을 맡은 AI가 "더 정교하게 해보자"며 같은 길을 다시 갈 수 있거든요.

AI가 "이 조건은 통과할 수 없다"고 말했다

설계를 정리해 Codex에게 넘겼습니다. 잠시 후 돌아온 답이 예상 밖이었어요.

현재 명세를 엄격히 지키면 검증 전체 통과가 불가능합니다.

>

1. 지시하신 "글자가 적으면 0점 처리" 규칙이 기존 테스트와 충돌합니다 2. 검증 조건의 숫자 비교가 소수점 오차 때문에 실패합니다

구현을 끝내놓고 작업을 거절한 셈입니다. 직접 확인해봤더니 둘 다 맞았습니다.

여기서 중요한 건, Codex가 마음만 먹으면 통과시킬 수 있었다는 점입니다. 기존 테스트의 기대값을 낮추거나 숫자를 살짝 손보면 검사는 전부 초록불이 켜졌을 거예요. 저는 "완료됐습니다"라고 보고받았겠죠.

그런데 실제로는 짧은 영상이 영원히 위키에 못 올라가는 결함이 남았을 겁니다. 제가 "글자 수가 적으면 0점"이라고 지시한 게 문제를 해결한 게 아니라 덮은 것이었거든요. 1분짜리 짧은 영상은 앞으로도 계속 탈락했을 테니까요.

이게 가능했던 건 지시문에 한 줄을 넣어뒀기 때문입니다.

검증 조건이 틀렸다고 판단되면 고치지 말고 사실대로 보고하라.

이 한 줄이 없었다면 조용히 넘어갔을 겁니다.

20개와 20종은 같은 말인데

지표를 고치자 통과가 3편에서 7편으로 늘었습니다. 그런데 여전히 막혀 있는 자료가 있었어요. 아까 그 0.05점짜리 강의입니다. 이제 0.60점으로 통과했는데도 위키에 못 올라가고 있었습니다.

사유를 보니 딱 한 줄이었습니다.

원문에 없는 수치가 있습니다: 20

원문을 뒤져보니 "20개밖에 안 돼요"라고 말했고, 요약은 "아미노산 20종"이라고 적었습니다. 아미노산이 20종이라는 같은 사실이고, 오히려 요약이 더 정확한 단위를 썼어요.

문제는 검사기가 숫자를 단위까지 붙여서 비교하고 있었다는 겁니다. 원문의 '20개'와 요약의 '20종'을 다른 값으로 본 거죠. 단위 목록에 '종'이 없어서 생긴 일인데, 목록을 늘리는 방식으로는 끝이 없습니다. 가지, 회, 번, 층… 계속 나올 테니까요.

그래서 숫자 부분만 떼어내 비교하도록 바꿨습니다.

다만 이 수정은 방향이 위험했습니다. 지금까지는 검사를 정교하게 만드는 일이었는데, 이건 검사를 느슨하게 만드는 일이거든요. 잘못하면 AI가 지어낸 가짜 숫자까지 통과시키게 됩니다.

그래서 검증 순서를 뒤집었습니다. 보통은 "기능이 되는가"를 먼저 보는데, 이번엔 "안전장치가 여전히 작동하는가"를 최우선으로 두고 지시문에 이렇게 적었습니다. "이 항목이 실패하면 나머지가 다 통과해도 실패다."

원문에 없는 숫자를 요약에 심어놓고 잡히는지, 원문에 있는 숫자를 잘못 신고하지 않는지 실제 문장으로 확인했습니다. 전부 통과했고, 그제서야 그 강의가 위키에 올라갔습니다.

곁들여서: 되돌릴 지점 없이 일하고 있었다

중간에 예전 세미나 정리 노트와 지금까지의 진행을 대조해봤습니다. 대부분 맞아떨어졌는데 하나가 크게 어긋나 있었어요.

작업 이력을 남기는 장치(git)를 안 쓰고 있었습니다.

세미나에서 "AI에게 일을 맡기기 전에 되돌릴 수 있는 지점부터 만들라"고 강조했던 바로 그 부분이 비어 있던 겁니다. 그리고 이게 추상적인 문제가 아니었어요. 그때까지 저는 AI가 기존 코드를 건드렸는지 확인하려고 파일 크기를 숫자로 비교하는 이상한 방법을 쓰고 있었습니다. 이력 관리가 있었으면 명령어 한 줄이면 될 일을요.

바로 만들고 첫 기록을 남겼습니다. 그 직후에 바로 써먹었어요. 기존 코드 8개가 한 글자도 안 바뀌었다는 걸 내용 단위로 확인할 수 있었고, 파일 크기 비교라는 편법은 버렸습니다.

되돌리는 절차도 문서로 정리했는데, 여기서 한 가지를 깨달았습니다. 모든 파일의 복구 비용이 같지 않다는 점이요.

코드는 잘못돼도 명령어 한 줄이면 1초 만에 돌아옵니다. 그런데 위키에 쌓인 정리 노트는 AI를 34분 돌려서 만든 것이고, 다시 돌려도 똑같이 나오지 않습니다. AI는 같은 입력에도 매번 조금씩 다르게 답하니까요.

그래서 흔히 쓰는 "전부 되돌리기" 명령을 문서에 금지로 못박았습니다. 코드를 되돌리려다 되살릴 수 없는 걸 날리면 안 되니까요.

✅ 결과 (After)

Before vs After

되살아난 자료

특히 15,147자짜리 강의가 아깝지 않게 됐습니다. 단백질 합성과 유전암호표를 다룬, 이 프로젝트에서 내용이 가장 조밀한 자료인데 그동안 "20개 vs 20종" 하나에 막혀 있었거든요. 이 한 편이 위키에 페이지 다섯 개를 보탰습니다.

지금 위키에 못 올라간 자료는 두 편인데, 둘 다 정당한 이유입니다. 하나는 원문이 영어인데 요약이 한국어라 단어 대조가 불가능한 경우고, 다른 하나는 AI가 원문과 다르게 인용한 진짜 실수예요. 검사 기준이 잘못돼서 억울하게 탈락한 자료는 이제 없습니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. "조건이 틀렸으면 고치지 말고 보고하라"를 지시문에 넣기

2. 이 한 줄이 이번 작업에서 가장 큰 값을 했습니다. AI는 기본적으로 시킨 일을 해내려 하기 때문에, 지시 자체가 모순되면 억지로 맞추는 쪽을 택하기 쉽습니다. 거절할 권한을 명시적으로 줘야 합니다.

1. 판단하기 전에 실제로 재보기

2. 대안 세 가지 중 두 개는 머릿속으로는 그럴듯했는데 돌려보니 효과가 없었습니다. 실측 없이 골랐으면 복잡도만 늘어난 코드를 안고 갔을 겁니다.

1. 버린 선택지의 이유도 남기기

2. "이건 해봤는데 안 됐다"를 근거와 함께 적어두니, AI가 같은 길을 다시 가지 않았습니다.

1. 검사를 느슨하게 만들 땐 안전장치 검증을 최우선에 두기

2. "이 항목이 실패하면 다른 게 다 통과해도 실패"라고 순서를 못박았습니다. 안 그러면 편의를 위해 안전장치를 무력화하고도 모를 수 있습니다.

1. 만드는 쪽과 검사하는 쪽을 다른 프로그램으로 분리하기

2. Codex가 구현하고 Claude가 검증하는 구조라, 검사가 형식적으로 흐르지 않습니다.

이렇게 하면 안 돼요

1. 검사 결과의 숫자를 그대로 믿기

2. 0.05점을 보고 "요약이 부실하구나"라고 넘어갈 뻔했습니다. 실제로는 요약이 훌륭했고 검사기가 틀렸어요. 점수가 이상하면 점수 자체를 의심해봐야 합니다.

1. 문제를 덮는 조건을 넣기

2. "글자 수가 적으면 0점 처리"라고 쓴 게 해결이 아니라 회피였습니다. 짧은 자료는 앞으로도 계속 탈락할 참이었죠. 예외 처리를 넣을 때는 그게 진짜 해결인지 한 번 더 봐야 합니다.

1. 기준점 없이 AI에게 넓은 권한 주기

2. 이력 관리 없이 작업하다가 결국 파일 크기를 비교하는 편법을 쓰게 됐습니다. 되돌릴 지점부터 만들고 시작하세요.

1. 막힌 벽을 계속 두드리기

2. 중간에 유튜브에서 자막을 받으려다 접속이 막혔는데, 15분 간격으로 6시간을 시도했습니다. 결과는 전부 실패였고, 오히려 차단 시간만 늘렸을 가능성이 있습니다. 안 되는 건 시간을 두고 다른 경로를 찾는 게 낫습니다.

🌍 다른 업무에 적용한다면?

평가 기준을 만들 때마다 "이게 진짜 재려는 걸 재고 있나" 확인하기. 이번 일은 프로그램 이야기지만 구조는 어디서나 같습니다. 예를 들어 보고서 품질을 "분량"으로 재면 장황한 글이 높은 점수를 받고, 상담 품질을 "통화 시간"으로 재면 말이 느린 사람이 유리해집니다. 기준을 정한 뒤에는 일부러 반대 사례를 만들어 넣어보면 기준이 제대로 작동하는지 금방 드러납니다.

AI에게 일을 맡길 때 "거절할 권한"을 주기. 지시가 모순되면 알려달라고 명시하는 것만으로 결과가 달라집니다. 사람 팀에게도 마찬가지고요.

되돌릴 수 없는 것과 있는 것을 구분해두기. 코드는 되돌리기 쉽지만 AI가 만든 결과물은 다시 만들어도 같지 않습니다. 작업 전에 "이건 날리면 복구가 안 된다"를 표시해두면 사고를 막을 수 있습니다.

🚀 앞으로의 계획

다음은 쌓인 위키 위에서 질문에 답하는 에이전트를 만들 차례입니다. 지난 편에서 예고했던 두 갈래 중 남은 하나예요. 위키가 30페이지로 늘어 답할 근거가 어느 정도 갖춰졌습니다.

원래 담으려던 주제도 아직 남아 있습니다. AI 워크스페이스 관련 강연 두 편을 위키에 넣으려 했는데 자막 접속이 막혀서 미뤄뒀어요. 차단이 풀리면 바로 채울 예정입니다.

📋 재사용 가능한 프롬프트

프롬프트 1: AI에게 거절할 권한 주기

아래 작업을 구현해주세요. [작업 내용]

>

단, 검증 조건이 서로 모순되거나 논리적으로 통과할 수 없다고 판단되면 억지로 맞추지 말고 이유를 사실대로 보고하세요. 조건을 통과시키기 위해 기존 테스트를 수정하거나 기대값을 낮추는 것은 실패로 간주합니다.

프롬프트 2: 평가 기준이 제대로 작동하는지 확인하기

지금 [평가 기준 이름]이 이상한 결과를 내고 있습니다. [구체적 증상: 예 — 내용이 알찬 자료가 낮은 점수를 받습니다]

>

기준을 고치기 전에 먼저 진단해주세요. 1. 이 기준이 실제로 무엇을 측정하고 있는지 계산 과정을 열어서 확인 2. 점수가 가장 높은 사례와 가장 낮은 사례를 뽑아 무엇이 달랐는지 비교 3. 원인을 찾은 뒤에 대안을 제시하되, 실제 데이터로 돌려본 결과를 함께 보여주세요

프롬프트 3: 검사를 느슨하게 만들 때 안전장치 지키기

[검사 항목]에서 오탐이 발생합니다. [구체적 사례]

>

이 오탐을 없애되, 검사 자체가 무력해지면 안 됩니다. 다음을 최우선 검증으로 두고, 이게 실패하면 다른 항목이 모두 통과해도 실패로 판정하세요. - [원래 잡아야 하는 것]이 여전히 잡히는가 - [정상인 것]을 잘못 신고하지 않는가

>

위 두 가지를 실제 사례로 확인한 결과를 보고해주세요.