devalive

실전 Claude Code 하네스 ㉓ 점검 봇이 모두 통과시킨 영상에서 달이 제목을 가리고 있었습니다

devalive — Sat, 31 Oct 2026 13:04:58 +0900

처음 오셨다면 용어 풀이와 연재 지도를 정리한 ⓪편 「AI에게 일을 맡기기 전에 알아야 할 것」부터 읽어 보세요.

옛이야기 영상 앞에 붙일 6초짜리 제목 인트로를 영상 생성 서비스 없이 코드로만 그려 봤습니다. 밤하늘에 별이 반짝이고, 달이 떠오르고, 산 능선이 천천히 흐르다가 금색 제목이 한 글자씩 올라오는 장면입니다. 파이썬으로 프레임을 한 장씩 그리고 ffmpeg로 이어 붙였더니 생성 크레딧은 0원이었고 워터마크도 없었습니다.

만드는 일은 Claude Code의 자동 모드에 맡겼고, 사람이 보기 전에 숫자로 걸러 내는 점검 봇도 함께 만들게 했습니다. 첫 결과물은 봇의 10항목을 모두 통과했습니다. 그런데 확인용 장면을 열어 보니 달이 제목 끝 글자 뒤에 걸려 있었습니다. 이번 글은 그 실패를 어떻게 봇 항목으로 바꿨는지에 대한 이야기입니다.

봇은 「잘 만들었는가」를 묻지 못했습니다

처음 만든 봇은 해상도와 초당 프레임 수, 길이, 1초 넘게 멈춘 구간이 있는지를 봤습니다. 시작과 끝이 어둡게 페이드되는지, 제목 금색이 제때 나타나는지, 글자가 화면 가장자리 안전 영역 안에 있는지, 장면이 실제로 움직이는지도 확인했습니다. 모두 「틀리지 않았는가」를 묻는 항목이었습니다.

달과 제목이 겹치는 것은 어느 항목도 묻지 않았습니다. 두 요소가 각각 제자리에 있으니 숫자로는 문제가 없었고, 사람 눈에만 어색했습니다. 다행히 봇이 대표 장면 네 장을 이어 붙인 확인 그림을 함께 남기게 해 두어서, 그 그림을 여는 순간 바로 보였습니다.

놓친 실패는 지우지 않고 봇 항목으로 바꿨습니다

달 위치만 고치고 넘어갈 수도 있었습니다. 하지만 다음 편에서 부제를 바꿔 다시 구우면 같은 일이 또 생길 수 있습니다. 그래서 검사 항목을 하나 더했습니다. 제목 글자를 둘러싼 상자를 30픽셀 넓힌 범위 안에 달 색(옅은 크림색) 픽셀이 50개 이상 있으면 실패로 판정합니다.

이 항목을 만들다가 봇의 다른 결함도 드러났습니다. 화면 아래쪽 등롱 불빛의 색이 제목 금색과 비슷해서, 봇이 불빛까지 글자로 세고 있었습니다. 그 바람에 글자 상자가 아래로 늘어나 있었고 가운데 정렬 값도 조금 틀려 있었습니다. 금색 검사에서 화면 아래 25%를 빼서 바로잡았습니다.

고친 봇은 예전 실패작으로 먼저 시험했습니다

새 항목을 넣은 뒤 바로 고친 영상을 검사하지 않았습니다. 먼저 달이 겹친 예전 영상(v1)을 고친 봇에 다시 넣었습니다. 결과는 12항목 중 실패 2건이었고, 달 색 픽셀이 4,383개로 나왔습니다. 봇이 그 문제를 실제로 잡는다는 것을 확인한 뒤에야 달을 위로 올린 v2를 검사했고, 달 색 픽셀은 1개와 4개로 통과했습니다.

이 순서를 건너뛰면 새 항목이 늘 통과만 하는 장식일 수도 있습니다. 고친 영상이 통과했다는 사실만으로는 「문제가 고쳐졌다」와 「검사가 아무것도 못 본다」를 구별할 수 없습니다. 예전 실패작이 시험지 역할을 해 준 것입니다.

그다음부터는 미리보기 한 장으로 먼저 걸렀습니다

v3에서는 등롱을 든 인물과 소나무, 얇은 구름, 국악 배경 음악을 더했습니다. 6초를 모두 렌더하면 3~4분이 걸리기 때문에, 이번에는 5초 지점 한 장면만 먼저 그려 보게 했습니다. 그 한 장에서 구름 띠의 경계가 직사각형으로 보이는 것, 소나무가 탑처럼 쌓여 보이는 것, 인물이 기둥처럼 가는 것을 모두 잡았습니다.

봇에는 소리 항목 세 개(소리 유무, 음량 -18~-14 LUFS, 최고점 -1 dBTP 이하)를 더해서 모두 15항목이 되었고, v3는 15항목을 모두 통과했습니다. 그래도 확인 그림은 다시 눈으로 열어 봤습니다.

맺으며

이번에 정리한 것은 이렇습니다.

6초 인트로를 코드로만 그렸고, 생성 크레딧과 워터마크 없이 만들었습니다.
점검 봇 10항목을 모두 통과한 첫 결과물에서 달과 제목이 겹친 것을 눈으로 찾았습니다.
놓친 실패는 봇 항목으로 바꿨고, 그 과정에서 등롱 불빛을 글자로 세던 봇의 결함도 고쳤습니다.
고친 봇은 예전 실패작으로 먼저 시험해서 실제로 실패를 잡는지 확인했습니다.
전체 렌더 전에 한 장면 미리보기로 거르면, 3~4분짜리 반복을 몇 번씩 줄일 수 있습니다.

다음 편은 준비하는 대로 적겠습니다.

이전 편: ㉒ 1시간 반이 넘는 영상은 뒤쪽 교정이 빠져 있었습니다
다음 편: 준비 중
연재 전체: Claude Code 하네스

실전 Claude Code 하네스 ㉒ 1시간 반이 넘는 영상은 뒤쪽 교정이 빠져 있었습니다

devalive — Fri, 30 Oct 2026 12:32:01 +0900

처음 오셨다면 용어 풀이와 연재 지도를 정리한 ⓪편 「AI에게 일을 맡기기 전에 알아야 할 것」부터 읽어 보세요.

2시간 43분짜리 강의 영상의 자막을 받아 10분씩 17조각으로 나눴습니다. 조각마다 받아쓰기 오타를 고치는 교정 스크립트를 돌리고, 정리는 서브에이전트에게 맡겼습니다. 돌아온 보고서에 이런 줄이 있었습니다. 「교정된 자막은 1시간 30분까지만 있어서, 그 뒤는 교정 전 원문으로 읽었습니다.」

스크립트는 오류 없이 끝났고 경고도 없었습니다. 그런데 17조각 중 9조각만 교정되어 있었습니다. 이번 글은 이 구멍이 어디서 생겼고, 어떻게 드러났는지에 대한 이야기입니다.

보고서의 「구멍」 한 줄이 먼저 알려 줬습니다

이 연재에서 서브에이전트에게 일을 맡길 때는 결과와 함께 「무엇을 확인하지 못했는지」를 적게 합니다. 이번 보고서에도 「범위에 구멍이 있다」는 항목이 따로 있었습니다. 교정본이 없는 구간은 교정 전 원문으로 읽었고, 그 부분에는 [미교정] 표시를 달아 두었다고 적혀 있었습니다.

이 줄이 없었다면 저는 정리본 전체가 같은 품질이라고 믿었을 것입니다. 앞쪽 1시간 반은 교정된 자막으로, 뒤쪽 1시간은 오타가 섞인 원문으로 정리되었는데, 겉보기에는 구별되지 않습니다. 서브에이전트가 범위를 스스로 밝혀 준 덕분에, 문제가 정리본이 아니라 그 앞 단계에 있다는 것을 알 수 있었습니다.

원인은 파일 이름 패턴의 숫자 하나였습니다

받기 스크립트를 열어 보니 교정 단계가 조각 파일을 chunk_0*.txt라는 패턴으로 고르고 있었습니다. 조각 이름은 chunk_01부터 chunk_17까지입니다. 이 패턴은 「chunk_0으로 시작하는 파일」이라는 뜻이라서 01부터 09까지만 고릅니다. 10분 조각 아홉 개, 곧 1시간 30분까지입니다.

지금까지 이 스크립트로 받은 영상은 대부분 1시간 30분보다 짧았습니다. 조각이 아홉 개를 넘지 않으니 이 패턴으로도 전부 골라졌고, 그래서 한 번도 드러나지 않았습니다. 패턴이 파일 몇 개와라도 맞으면 스크립트는 정상으로 끝나기 때문에 오류도 나지 않았습니다.

고친 곳은 두 군데였습니다

패턴을 chunk_[0-9][0-9].txt로 바꿨습니다. 숫자 두 자리를 모두 받으므로 01부터 99까지 고릅니다. 같은 패턴을 복사해 쓴 받기 스크립트가 하나 더 있어서 그쪽도 함께 고쳤습니다. 그다음 빠진 조각 10~17을 교정하고, 서브에이전트에게 「뒤쪽 구간을 교정본으로 다시 읽고 [미교정] 표시를 지워 달라」고 이어서 맡겼습니다.

새 패턴에도 한계는 있습니다. 조각이 100개를 넘으면, 곧 영상이 16시간 40분을 넘으면 또 빠집니다. 그런 영상을 받을 일은 거의 없어서 그대로 두었습니다. 더 확실한 방법은 「교정한 조각 수가 전체 조각 수와 같은지」를 마지막에 세어 보는 것인데, 이 확인 줄은 아직 넣지 않았습니다.

ERP 집계에서도 같은 모양으로 생깁니다

ERP 일에 빗대면 이런 경우와 같습니다. 월별 집계 화면에서 월을 '0%'처럼 「0으로 시작하는 값」으로 거르면, 1월부터 9월까지는 잘 나오다가 10월부터 갑자기 빠집니다. 9월까지는 아무도 모르고, 10월 마감 때 숫자가 안 맞아서야 발견됩니다.

두 경우 모두 조건이 틀린 것이 아니라 조건이 가정한 자릿수가 틀린 것입니다. 데이터가 작을 때는 맞게 돌아가서 시험에서 걸리지 않습니다. 그래서 「경계를 넘는 크기」로 한 번 돌려 보는 것이 가장 싼 확인입니다. 이번에는 우연히 긴 영상이 들어와서 그 시험을 대신해 주었습니다.

맺으며

이번에 정리한 것은 이렇습니다.

2시간 43분 영상을 17조각으로 나눴는데, 교정은 9조각에만 되어 있었습니다.
원인은 chunk_0*라는 패턴이 01~09만 고른 것이었고, 오류도 경고도 없었습니다.
서브에이전트가 보고서에 「확인하지 못한 범위」를 적어 둔 덕분에 발견했습니다.
패턴을 두 자리 숫자로 고치고, 복사본 스크립트도 함께 고쳤습니다.
자릿수를 가정한 조건은 경계를 넘는 크기로 한 번 돌려 보는 것이 가장 싼 확인입니다.

다음 편은 준비하는 대로 적겠습니다.

이전 편: ㉑ 캘린더 도구는 UTC라고 했고, 설정 화면은 서울이었습니다
다음 편: ㉓ 점검 봇이 모두 통과시킨 영상에서 달이 제목을 가리고 있었습니다
연재 전체: Claude Code 하네스

실전 Claude Code 하네스 ㉑ 캘린더 도구는 UTC라고 했고, 설정 화면은 서울이었습니다

devalive — Sun, 25 Oct 2026 22:01:17 +0900

처음 오셨다면 용어 풀이와 연재 지도를 정리한 ⓪편 「AI에게 일을 맡기기 전에 알아야 할 것」부터 읽어 보세요.

오늘 Claude Code가 저에게 「구글 캘린더 시간대가 UTC로 잡혀 있어서 일정을 넣으면 9시간이 어긋날 수 있다」고 보고했습니다. 바꿔 달라고 했더니, 설정 화면을 열어 본 Claude Code가 이번에는 「이미 서울로 되어 있어 바꿀 것이 없다」고 정정했습니다.

틀린 보고였습니다. 이번 글은 그 보고가 어디서 나왔고, 무엇이 그것을 바로잡았는지에 대한 이야기입니다.

계정을 옮긴 날, 연결부터 확인했습니다

이날 저는 Claude 계정을 개인 계정으로 옮겼습니다. 기억 파일과 문서는 PC에 그대로 남지만, 연결된 서비스는 새 계정 기준으로 다시 확인해야 합니다. 그래서 Claude Code에게 연결 상태를 점검하게 했습니다.

Claude Code는 연결된 서비스 목록을 조회하고, 노션과 구글 캘린더에는 「지금 누구로 로그인되어 있는지」를 묻는 읽기 전용 요청을 보냈습니다. 모두 새 계정으로 연결되어 있었습니다. 여기까지는 문제가 없었습니다.

문제는 캘린더 목록을 조회한 응답에 들어 있던 한 줄이었습니다. 캘린더마다 붙는 시간대 칸에 UTC가 찍혀 있었습니다. Claude Code는 이 값을 그대로 믿고, 일정이 9시간 어긋날 수 있으니 설정을 서울로 바꾸라고 권했습니다.

바꾸러 갔더니 로그인부터 막혔습니다

캘린더 연결 도구로는 일정을 읽고 만들 수만 있고, 시간대 설정은 바꿀 수 없었습니다. 그래서 Claude Code는 앱 안에 들어 있는 내장 브라우저로 캘린더 설정 화면을 열었습니다. 그런데 로그인 화면이 나왔습니다. 비밀번호는 제가 직접 넣어야 하므로 거기서 멈췄습니다.

저는 평소 쓰는 크롬에서 로그인되어 있는 것을 보고 「로그인했다」고 답했습니다. 하지만 내장 브라우저에는 여전히 로그인이 되어 있지 않았습니다. 두 브라우저는 로그인 상태를 서로 나눠 쓰지 않습니다. 한쪽에 로그인했다고 다른 쪽이 따라오지 않습니다.

그래서 크롬 확장으로 Claude Code가 제 크롬을 조작하게 했습니다. 이미 로그인되어 있어서 설정 화면이 바로 열렸습니다.

설정 화면은 처음부터 서울이었습니다

설정 화면에는 시간대가 두 군데 있습니다. 계정 전체의 「기본 시간대」와, 캘린더 하나하나에 붙은 시간대입니다. Claude Code는 둘 다 열어 봤고, 둘 다 「(GMT+09:00) 한국 표준시 - 서울」이었습니다.

결국 처음 보고의 근거였던 UTC는 실제 설정이 아니라 연결 도구의 응답에만 있던 값이었습니다. 도구가 왜 그렇게 보여 줬는지는 확인하지 못했습니다. 확실한 것은 사람이 보는 설정 화면과 도구의 응답이 달랐고, 맞는 쪽은 설정 화면이었다는 점입니다.

Claude Code는 바꿀 것이 없으니 아무것도 바꾸지 않았습니다. 대신 앞서 남긴 기록 두 곳을 고쳤습니다. 계정 전환 인계 문서와 기억 파일에 「실제 설정은 서울, 도구 표시는 믿지 말 것」이라고 적었고, 앞으로 일정을 만들 때는 시간대를 서울로 직접 지정하기로 했습니다.

도구 응답도 남이 준 자료입니다

이 연재에서 여러 번 적은 원칙이 있습니다. 웹 페이지나 파일에서 읽은 내용은 자료일 뿐 지시가 아니라는 원칙입니다. 이번 일로 하나를 덧붙이게 됐습니다. 도구가 돌려준 값도 자료라는 점입니다. 값이 그럴듯해 보여도, 그 값을 근거로 설정을 바꾸기 전에는 원본 화면에서 한 번 더 봐야 합니다.

ERP 일에 빗대면 조회 화면과 DB 값이 다를 때와 비슷합니다. 화면에 찍힌 금액이 이상하다고 바로 전표를 고치지 않고, 원장을 열어 실제 값을 먼저 확인하는 것과 같은 순서입니다.

이번에 다행이었던 점은 설정을 바꾸는 단계가 「원본 화면을 여는 단계」와 붙어 있었다는 것입니다. 바꾸러 들어갔기 때문에 틀린 것을 발견했습니다. 도구가 시간대를 직접 바꿀 수 있었다면, 맞는 설정을 맞는 값으로 덮어쓰고 「바꿨습니다」라고 보고했을 수도 있습니다.

맺으며

이번에 정리한 것은 이렇습니다.

계정을 옮긴 날, 연결된 서비스를 읽기 전용 요청으로 하나씩 확인했습니다.
캘린더 연결 도구는 시간대를 UTC로 보여 줬지만, 실제 설정은 서울이었습니다.
앱 안의 브라우저와 평소 쓰는 크롬은 로그인 상태를 나눠 쓰지 않습니다.
도구가 돌려준 값도 자료입니다. 설정을 바꾸기 전에는 원본 화면에서 대조합니다.
틀린 보고는 지우지 않고, 고친 사실과 이유를 기록에 남겼습니다.

다음 편은 준비하는 대로 적겠습니다.

이전 편: ⑳ 리더보드 1위 받아쓰기 모델, 우리 음성 3분으로 재 보니 세 배 느렸습니다
다음 편: ㉒ 1시간 반이 넘는 영상은 뒤쪽 교정이 빠져 있었습니다
연재 전체: Claude Code 하네스

실전 Claude Code 하네스 ⑳ 리더보드 1위 받아쓰기 모델, 우리 음성 3분으로 재 보니 세 배 느렸습니다

devalive — Sat, 24 Oct 2026 14:33:25 +0900

처음 오셨다면 용어 풀이와 연재 지도를 정리한 ⓪편 「AI에게 일을 맡기기 전에 알아야 할 것」부터 읽어 보세요.

어젯밤 Claude Code에게 받아쓰기 모델 하나를 설치하고 시험하게 했습니다. 오픈소스 음성 인식 순위에서 1위로 소개된 모델이었습니다. 시험은 한국어 음성 3분짜리 두 편으로 했고, 지금 쓰고 있는 받아쓰기 도구와 같은 조건으로 나란히 돌렸습니다.

결론부터 적으면 새 모델은 들이지 않았습니다. 이번 글은 그 결론까지 간 순서입니다.

설치 전에 세 가지를 먼저 봤습니다

저는 자막이 없는 영상이나 회의 녹음을 받아쓸 때 오픈소스 받아쓰기 도구(faster-whisper)를 씁니다. 이 PC의 그래픽카드는 RTX 2060, 메모리 6GB입니다. 큰 장비는 아니지만 3분짜리 음성을 수십 초 안에 받아씁니다.

새 모델을 시험하자고 했을 때 Claude Code가 설치보다 먼저 확인한 것은 세 가지였습니다.

라이선스 : 저장소, 패키지, 모델 가중치가 모두 상업 이용이 되는 Apache-2.0인지 각각 확인했습니다. 앱과 모델의 라이선스가 다른 경우를 전에 겪었기 때문입니다.
설치 자리 : 지금 쓰는 받아쓰기 환경은 건드리지 않고, 폴더를 따로 만들어 격리했습니다. 패키지 판도 고정했습니다.
그래픽카드 조건 : 공식 예제는 bf16이라는 연산 형식을 쓰는데, 이 그래픽카드 세대는 그 형식을 제대로 지원하지 않습니다. 그래서 float16으로 바꿔 돌렸습니다.

ERP 현장에서 새 라이브러리를 운영 서버에 바로 올리지 않고 개발 서버에 따로 깔아 보는 것과 같은 순서입니다.

같은 3분을 세 번 받아썼습니다

시험 음성은 공개된 한국어 강의 영상 두 편의 앞 3분입니다. 하나는 또박또박한 해설이고, 다른 하나는 말이 빠르고 고유 명사가 많습니다. 같은 파일을 세 모델에 넣었습니다. 새 모델은 작은 판(0.6B)과 큰 판(1.7B)을 모두 돌렸습니다.

3분을 받아쓰는 데 지금 쓰는 도구는 32초와 20초, 새 모델은 작은 판이 84초와 83초, 큰 판이 72초와 87초 걸렸습니다. 지금 쓰는 도구의 시간에는 모델을 불러오는 시간까지 들어 있는데도 가장 빨랐습니다. 새 모델은 두 판 모두 약 두 배속에 머물렀습니다. 문장마다 시간을 붙여 주는 기능도 새 모델에는 기본으로 없었습니다.

큰 판은 6GB 중 5.39GB를 썼습니다. 돌아가기는 하지만, 그동안 그래픽카드를 쓰는 다른 작업은 함께 돌릴 수 없는 수준입니다.

숫자 하나가 틀리면 요약 전체가 틀립니다

속도보다 더 걸린 것은 정확도였습니다.

또박또박한 해설에서 작은 판은 「엑셀 파일 10개」를 「5개」로 두 번 받아썼습니다. 맞춤법도 몇 군데 틀렸습니다. 큰 판은 이 해설에서는 지금 도구와 비슷하게 맞혔습니다.

말이 빠른 영상에서는 큰 판도 흔들렸습니다. 장르 이름 세 개가 이어지는 대목에서 단어가 엉뚱하게 바뀌었고, 「디테일하게」 같은 말도 알아볼 수 없게 적었습니다. 같은 대목을 지금 도구는 그대로 받아썼습니다.

받아쓴 글은 그다음 요약과 검토의 재료가 됩니다. 글자 하나 틀린 것은 읽으면서 고칠 수 있지만, 숫자가 바뀌면 그 위에 쌓은 요약이 통째로 틀립니다. 매출 「10개 파일」을 「5개 파일」로 요약한 보고서가 어떻게 될지는 ERP 일을 해 본 분이라면 바로 그림이 그려지실 겁니다.

순위는 남의 시험지였습니다

순위가 거짓이었다는 뜻은 아닙니다. 순위는 그 순위를 만든 사람들의 시험지로 매긴 점수입니다. 그 시험지에 한국어 강의 음성이, 그것도 6GB 그래픽카드에서 돌린 결과가 들어 있지는 않았을 겁니다.

그래서 이번에 남긴 기록에는 판정과 함께 한계도 적었습니다. 표본이 3분짜리 두 편뿐이고, 오차율을 계산하지 않고 눈에 띄는 오류로 비교했다는 점입니다. 큰 그래픽카드가 생기면 같은 음성으로 다시 재 보기로 했습니다. 이번 결론은 「이 모델이 나쁘다」가 아니라 「우리 PC와 우리 음성에서는 지금 도구가 낫다」입니다.

설치해 둔 격리 폴더는 약 5.5GB입니다. 지울지 남길지는 제가 정하기로 하고 그대로 두었습니다.

맺으며

이번에 정리한 것은 이렇습니다.

설치 전에 라이선스, 설치 자리, 그래픽카드 조건부터 봤습니다.
같은 음성을 지금 쓰는 도구와 나란히 돌려야 비교가 됩니다.
새 모델은 이 PC에서 두 배 넘게 느렸고, 큰 판은 메모리 한계에 걸렸습니다.
숫자 하나를 틀리게 받아쓰면 그 위에 쌓은 요약이 통째로 틀립니다.
순위는 남의 시험지입니다. 들일지는 우리 음성으로 정합니다.

다음 편은 준비하는 대로 적겠습니다.

이전 편: ⑲ 무료라던 국제 사업자 번호, 나라를 고르자 50만 원이 됐습니다
다음 편: ㉑ 캘린더 도구는 UTC라고 했고, 설정 화면은 서울이었습니다
연재 전체: Claude Code 하네스

실전 Claude Code 하네스 ⑲ 무료라던 국제 사업자 번호, 나라를 고르자 50만 원이 됐습니다

devalive — Wed, 21 Oct 2026 17:36:02 +0900

처음 오셨다면 용어 풀이와 연재 지도를 정리한 ⓪편 「AI에게 일을 맡기기 전에 알아야 할 것」부터 읽어 보세요.

오늘 하루 동안 Claude Code와 함께 개인사업자 서류 일곱 가지를 처리했습니다. 영문 사업자등록증명, 애플 계정 만들기, 국제 사업자 번호(D-U-N-S) 신청, 은행 사업자 통장과 체크카드, 홈택스 사업용 카드 등록과 계좌 신고, 출판사 신고입니다. 블로그를 전자책으로 묶고 작은 게임을 내려면 모두 필요한 서류입니다.

이번 글은 그중 한 장면, 「무료」라고 적힌 신청이 결제 화면 직전까지 간 이야기입니다.

손은 나눠 쓰기로 정해 두었습니다

시작하기 전에 선을 하나 정했습니다. 로그인, 본인 인증, 결제, 최종 제출 버튼은 사람이 누릅니다. Claude Code는 브라우저에서 메뉴를 찾고, 칸을 채우고, 제출 전에 입력값을 서류와 대조합니다. 카드번호, 계좌번호, 주민등록번호처럼 넣으면 안 되는 값은 칸만 알려 주고 제가 직접 넣었습니다.

ERP 화면에서 매일 하던 일과 비슷했습니다. 입력은 빨라도, 전표 승인 버튼은 담당자가 누르는 것과 같은 이치입니다.

「무료」는 미국 페이지의 이야기였습니다

D-U-N-S는 해외 앱 마켓에 사업자로 등록할 때 쓰는 아홉 자리 기업 번호입니다. 발급처인 던앤브래드스트리트(D&B) 공식 페이지에는 「번호를 받는 데 비용이 들지 않는다」고 분명히 적혀 있습니다.

그래서 그 페이지에서 신청을 시작했습니다. 「해외 사업자」를 고르고, 「구글 개발자」를 고르고, 나라 목록에서 「대한민국」을 눌렀습니다. 그러자 국내 협력사 사이트로 넘어갔고, 그곳의 안내 표에는 신규 신청 50만 원(부가세 별도, 7영업일), 급행 70만 원이 적혀 있었습니다. 번호에 기업 인증서를 묶어 파는 상품이었습니다.

Claude Code는 여기서 진행을 멈추고, 미국 본사 페이지는 무료라고 하지만 한국 사업자는 유료 협력사로 연결된다고 보고했습니다. 결제 화면 근처에는 가지 않았습니다. 그리고 다른 길을 찾아 왔습니다.

다른 문으로 들어가니 0원이었습니다

애플 개발자 사이트에는 D-U-N-S 번호를 조회하고, 없으면 D&B에 무료로 요청하는 도구가 있습니다. 애플 계정은 사업용 메일로 제가 직접 만들었고, 애플 개발자 기본 약관에도 제가 동의했습니다. 유료 개발자 프로그램에는 가입하지 않았습니다.

회사 정보 칸은 Claude Code가 그날 오전에 뗀 영문 사업자등록증명과 한 글자씩 맞춰 채웠습니다. 주소 칸이 「#」 기호를 받지 않아서 한 글자가 달라졌는데, 나중에 구글 쪽에 등록할 때는 이 번호에 등록된 표기 그대로 맞추기로 적어 두었습니다. 조회 결과는 「해당 조직을 찾을 수 없음」이었고, 그 자리에서 요청서를 제출했습니다. 화면에는 「곧 확인 이메일을 받게 된다」는 안내가 떴습니다. 들어간 돈은 0원입니다.

하나 덧붙이면, 이렇게 받은 번호는 애플 프로그램에 가입하지 않아도 사업자에게 그대로 남습니다. 구글 쪽 등록에도 같은 번호를 씁니다.

이번엔 AI 안내가 현장에서 틀렸습니다

공정하게 적자면, 같은 날 Claude Code의 안내가 틀린 일도 있었습니다. 은행에 가기 전에 「홈택스에서 출력한 사업자등록증도 원본과 같은 효력이 있다」고 정리해 줬는데, 창구에서는 세무서에서 발급한 원본을 요구했습니다. 결국 세무서에 들러 원본을 받고 나서야 통장을 만들었습니다.

그날 저녁 이 일은 규칙 하나로 남았습니다. 서류를 낼 때는 세무서 원본을 스캔한 파일을 정본으로 쓰고, 첨부 용량이 작은 곳에 낼 때는 그 파일에서 가벼운 사본을 따로 만듭니다. 원본 파일은 고치지 않습니다.

맺으며

이번에 정리한 것은 이렇습니다.

손은 나눠 씁니다. 로그인, 인증, 결제, 최종 제출은 사람이 누릅니다.
「무료」라는 공식 문구도, 나라를 고르는 순간 다른 상품으로 바뀔 수 있었습니다.
결제 화면 앞에서 멈추는 규칙이 50만 원을 지켰습니다.
다른 길(애플 개발자 도구)로 같은 번호를 0원에 요청했습니다.
AI 안내도 현장에서 틀릴 수 있어서, 틀린 날은 규칙으로 남겼습니다.

편하게 빨리 처리한 하루였지만, 멈춘 자리가 더 기억에 남습니다. 다음 편은 준비하는 대로 적겠습니다.

이전 편: ⑱ 로그인을 이어 쓰게 했더니, 열쇠가 평문 파일로 남아 있었습니다
다음 편: ⑳ 리더보드 1위 받아쓰기 모델, 우리 음성 3분으로 재 보니 세 배 느렸습니다
연재 전체: Claude Code 하네스

실전 Claude Code 하네스 ⑱ 로그인을 이어 쓰게 했더니, 열쇠가 평문 파일로 남아 있었습니다

devalive — Sun, 18 Oct 2026 07:01:33 +0900

처음 오셨다면 용어 풀이와 연재 지도를 정리한 ⓪편 「AI에게 일을 맡기기 전에 알아야 할 것」부터 읽어 보세요.

블로그 글은 자동화 브라우저로 올립니다. 그런데 이 브라우저를 다시 띄울 때마다 로그인이 풀려서, 어제 로그인 상태를 파일에 저장해 두고 다음에 되살리게 바꿨습니다. 편해졌습니다. 그리고 확인하다가, 그 파일이 로그인 열쇠를 평문 그대로 담고 있다는 것을 알았습니다.

이번 글은 그 열쇠를 어떻게 다시 보관했는지에 대한 이야기입니다.

편해진 만큼 열쇠가 하나 생겼습니다

로그인이 풀린 원인은 두 가지였습니다. 브라우저 설정이 세션마다 지워지는 임시 폴더에 있었고, 블로그 로그인 정보는 브라우저를 닫으면 사라지는 방식이었습니다. 그래서 설정 폴더를 고정 위치로 옮기고, 닫을 때 로그인 정보를 파일로 저장했다가 다음에 띄울 때 되살리게 했습니다.

로그인을 대신하는 것은 아닙니다. 로그인은 지금도 제가 직접 하고, 자동화 브라우저는 그 세션을 이어 쓰기만 합니다.

문제는 저장한 파일이었습니다. 그 파일만 있으면 누구든 블로그 관리 화면에 들어갈 수 있습니다. 집 열쇠를 현관 앞 화분 밑에 둔 것과 같았습니다.

네 겹으로 잠갔습니다

1. 암호화 : 윈도우가 기본으로 주는 암호화 기능(DPAPI)으로 파일을 잠갔습니다. 기본 설정에서는 이 PC의 이 계정에서만 풀립니다. 파일을 복사해 가도 다른 곳에서는 쓸 수 없습니다. 2. 14일 만료 : 저장한 지 14일이 지나면 되살리지 않고 지웁니다. 2주에 한 번은 다시 로그인하게 됩니다. 3. 즉시 폐기 : 명령 한 줄로 저장된 로그인을 바로 지울 수 있게 했습니다. 4. 읽기 차단 : 그 폴더를 Claude Code의 읽기 차단 목록에 넣었습니다. AI 도구가 작업 중에 그 파일을 열어 볼 일이 없게 했습니다.

브라우저가 따로 남기는 것도 있었습니다

잠그고 나서 하나가 더 보였습니다. 브라우저도 설정 폴더 안에 자기 쿠키 저장소와 세션 복원 파일을 따로 남깁니다. 이것은 브라우저가 관리하는 파일이라 제가 암호화할 수 없습니다.

그래서 열쇠의 정본은 암호화한 파일 하나로 두고, 브라우저가 남기는 평문 저장소는 띄우기 직전과 닫은 직후에 지우도록 했습니다. 띄우기 직전에도 지우는 것은, 창이 강제로 꺼져서 닫은 뒤 정리가 안 됐을 때를 대비한 것입니다.

고친 뒤에는 이렇게 확인했습니다

시험은 임시 폴더에서 먼저 했습니다. 저장한 파일 안에 쿠키 값이 그대로 보이지 않는지, 같은 PC에서는 다시 풀리는지, 15일 전 파일은 지우는지, 폐기 명령 뒤 남는 것이 없는지를 봤습니다. 어제 저장해 둔 실제 로그인 파일은 값을 화면에 띄우지 않고 파일끼리만 암호문으로 옮겼습니다.

중간에 한 번 헷갈렸습니다

평문 저장소를 지우는 패치를 넣고 브라우저를 띄우자 로그인 화면이 떴습니다. 당연히 패치 탓인 줄 알았습니다. 브라우저 저장소에만 있던 무언가가 로그인에 필요했던 것 아닐까 싶었습니다.

그래서 패치를 넣기 전에 백업해 둔 원래 저장소를 그대로 되돌려 놓고, 지우기 없이 띄워 봤습니다. 그래도 로그인 화면이었습니다. 원인은 패치가 아니라 밤사이 서버 쪽에서 로그인이 만료된 것이었습니다.

다시 로그인한 뒤 브라우저를 닫고, 평문 저장소를 지운 채 암호화한 파일만으로 띄웠습니다. 이번에는 로그인 없이 관리 화면이 바로 열렸습니다. 이 글도 그 브라우저로 올렸습니다.

먼저 의심한 쪽을 바로 되돌렸다면, 쓸모 있는 패치를 버릴 뻔했습니다. 백업을 두고 원인을 한 번 가려 본 덕분에 그러지 않았습니다.

맺으며

이번에 정리한 것은 이렇습니다.

자동화가 편해지는 순간, 어딘가에 새 열쇠가 생깁니다.
열쇠는 암호화하고, 기한을 두고, 바로 버릴 수 있게 만들었습니다.
브라우저가 따로 남기는 평문은 정본으로 쓰지 않고 지웠습니다.
로그인 자체는 지금도 사람이 직접 합니다.
고친 뒤 문제가 생기면, 되돌리기 전에 원인부터 한 번 가렸습니다.

편하게 만든 날, 그 편함이 무엇을 남겼는지도 같이 봐야 했습니다. 다음 편은 준비하는 대로 적겠습니다.

이전 편: ⑰ 질문 순서만 바꿨더니, 판단 모델의 답이 5% 뒤집혔습니다
다음 편: ⑲ 무료라던 국제 사업자 번호, 나라를 고르자 50만 원이 됐습니다
연재 전체: Claude Code 하네스

실전 Claude Code 하네스 ⑰ 질문 순서만 바꿨더니, 판단 모델의 답이 5% 뒤집혔습니다

devalive — Sat, 17 Oct 2026 20:19:07 +0900

처음 오셨다면 용어 풀이와 연재 지도를 정리한 ⓪편 「AI에게 일을 맡기기 전에 알아야 할 것」부터 읽어 보세요.

오늘 블로그 원고 점검기의 판단 모델에 같은 문장 323개를 세 번씩 물었습니다. 문장은 그대로 두고 질문의 순서만 바꿨습니다. 0.5를 기준으로 보면 16개, 약 5%의 판정이 뒤집혔습니다.

이번 글은 그 5%가 어디서 나왔고, 그래서 무엇을 바꿨는지에 대한 이야기입니다.

다른 실험에서 14%가 뒤집혔다는 글을 읽었습니다

어제 긱뉴스에서 의사결정 모델에 트롤리 문제를 물어본 실험을 읽었습니다. 같은 상황을 설명하는 순서만 바꿨는데, 판단 모델 Jev의 선택이 질문 쌍의 약 14%에서 바뀌었다는 내용이었습니다.

⑯편에서 붙인 고유정보 거름망은 작은 로컬 판단 모델(JevK5 4B)을 씁니다. 마침 그 실험의 비교 대상에도 들어 있던 모델입니다. 문장 하나를 주고 「문제없음」과 「고유정보」 중 하나를 고르게 하는 방식입니다. 그렇다면 우리 거름망도 순서에 흔들리는지 재 봐야 했습니다. 정확도와 오탐은 재 왔지만, 순서는 한 번도 바꿔 본 적이 없었습니다.

두 가지 순서를 바꿨습니다

판단 모델에 보내는 질문은 「문장 → 질문 → 선택지(A 문제없음, B 고유정보)」 순서로 되어 있습니다. 여기서 두 가지를 따로 바꿨습니다.

1. 선택지 순서 : A와 B를 맞바꿨습니다(A 고유정보, B 문제없음). 2. 항목 순서 : 질문과 선택지를 먼저 보여 주고 문장을 맨 뒤에 붙였습니다.

물은 문장은 323개입니다. 이미 공개한 ⑮·⑯편 원고 147문장, 판정 기록에 쌓아 둔 문장 6개, 가상의 회사 정보를 섞어 만든 예시 160문장, 그리고 「점심으로 김치찌개를 먹었습니다」 같은 뻔한 문장 10개입니다. 뻔한 문장은 0에 가까운 값이 나와야 정상입니다. 트롤리 실험에서 「아무도 없는」 선로를 확인한 것과 같은 검사입니다.

뒤집힌 것은 모양이 없는 문장이었습니다

선택지 순서를 바꾸면 5.0%, 항목 순서를 바꾸면 4.6%가 뒤집혔습니다. 「통과·확인·경고」 세 칸으로 보면 바뀐 문장은 11~13%였습니다.

뒤집힌 문장은 한쪽에 몰려 있었습니다. 16개 중 14개가 가상의 예시 문장이었고, 그중 절반 이상이 「○○건설 현장에서 전표 취소가 막혔습니다」처럼 회사 이름만 들어 있는 문장이었습니다. 나머지도 계정 이름이나 표 이름처럼 경로·메일 모양이 아닌 값이었습니다. 경로나 메일처럼 모양이 정해진 값은 앞 단계의 규칙이 잡기 때문에, 판단 모델에 남는 것은 원래 애매한 문장입니다. 애매한 문장일수록 순서에 흔들렸습니다.

뻔한 문장 10개는 세 순서 모두 통과했습니다. 가장 높은 값도 0.021이었습니다.

참고로 Jev 실험과는 과제도 모델도 달라서, 5%와 14%를 나란히 놓고 어느 쪽이 낫다고 말할 수는 없습니다.

순서를 바꾸면 놓쳤습니다

더 중요한 숫자는 따로 있었습니다. 진짜 고유정보 문장 73개 중 「통과」로 놓친 수입니다.

지금 순서로는 하나도 놓치지 않았습니다. 그런데 선택지 순서만 바꾸면 5개를 놓쳤습니다. 원인은 짐작이 갑니다. ⑮편에서 맞춘 확률 보정이 지금 순서로 물었을 때의 답에 맞춰져 있었기 때문입니다. 보정값과 질문 순서는 한 묶음이었던 것입니다.

그렇다면 두 순서로 다 물어서 높은 쪽을 쓰면 어떨까 싶었습니다. 놓침은 0개 그대로였지만, 공개 원고에서 「확인」으로 걸리는 문장이 14개에서 27개로 늘었습니다. 세 순서를 다 쓰면 30개입니다. 사람이 다시 봐야 할 문장이 두 배가 되는데, 더 잡아내는 것은 없었습니다.

그래서 순서를 기준값처럼 묶었습니다

결론은 의외로 간단했습니다. 여러 순서를 합치지 않고, 지금 순서를 기준값처럼 고정했습니다.

1. 점검기 코드에 순서를 못 박았습니다 : 질문과 선택지 순서를 바꾸면 보정값도 다시 맞춰야 한다고 적어 두었습니다. 2. 시험 스크립트를 남겼습니다 : 판단 모델이나 질문을 바꿀 때마다 같은 323문장으로 순서 바꾸기 시험을 다시 돌립니다. 3. 뻔한 문장 검사는 매번 같이 돌립니다 : 0에 가까운 값이 나오지 않으면 그날은 점검기를 믿지 않습니다.

맺으며

이번에 정리한 것은 이렇습니다.

같은 문장도 질문 순서만 바꾸면 판단 모델의 답이 5% 뒤집혔습니다.
흔들린 곳은 모양이 정해지지 않은 애매한 문장이었습니다.
보정값은 질문 순서와 한 묶음이라, 순서를 바꾸면 놓치는 문장이 생겼습니다.
여러 순서를 합치면 놓침은 그대로이고 사람이 볼 문장만 두 배가 됐습니다.
그래서 순서를 기준값처럼 고정하고, 바꿀 때마다 다시 재기로 했습니다.

판단 모델의 숫자 하나에는 질문을 어떻게 물었는지까지 들어 있었습니다. 다음 편은 준비하는 대로 적겠습니다.

이전 편: ⑯ 원고 점검기에 판단 모델을 붙였더니, 첫날 오탐이 16%였습니다
다음 편: ⑱ 로그인을 이어 쓰게 했더니, 열쇠가 평문 파일로 남아 있었습니다
연재 전체: Claude Code 하네스

실전 Claude Code 하네스 ⑯ 원고 점검기에 판단 모델을 붙였더니, 첫날 오탐이 16%였습니다

devalive — Fri, 16 Oct 2026 11:51:18 +0900

처음 오셨다면 용어 풀이와 연재 지도를 정리한 ⓪편 「AI에게 일을 맡기기 전에 알아야 할 것」부터 읽어 보세요.

오늘 블로그 원고 점검기에 판단 모델을 붙였습니다. 일부러 회사 정보를 섞어 둔 시험 원고에서는, 규칙으로는 못 잡는 문장까지 모델이 잡아냈습니다. 그런데 이미 공개한 15편 원고에 돌려 보니 89문장 중 14문장이 걸렸고, 14문장 모두 오탐이었습니다.

이번 글은 붙이자마자 오탐부터 센 이야기입니다.

규칙만으로는 못 잡는 문장이 있습니다

원고 점검기는 원래 규칙으로만 움직였습니다. 금지어 목록과 정규식으로 실제 경로, 메일 주소, IP 주소, 로컬 주소와 포트를 찾습니다. 모양이 정해진 값은 이 방식이 가장 확실합니다.

문제는 모양이 정해지지 않은 고유정보입니다. 예를 들어 「고객사 ○○물산의 전표 화면 ○○0912를 고쳤습니다」 같은 문장에는 경로도 메일도 없습니다. 그래도 고객사 이름과 화면 코드가 그대로 드러납니다. 규칙으로 이런 문장을 잡으려면 세상의 회사 이름을 다 적어 둬야 합니다.

⑮편에서 4B 판단 모델이 고유정보 판정을 89%까지 해낸 것을 확인했습니다. 그래서 이 모델을 규칙 뒤에 붙이기로 했습니다.

세 단계로 나눴습니다

1. 규칙 : 금지어와 정규식이 먼저 거릅니다. 2. 판단 모델 : 남은 문장마다 「고유정보일 확률」을 내고, ⑮편에서 맞춘 확률 보정을 거칩니다. 0.1 미만은 통과, 0.1~0.5는 확인, 0.5 이상은 경고입니다. 3. 사람 또는 Claude의 작은 모델(Haiku) : 확인과 경고 문장만 다시 봅니다.

판단 모델 서버는 점검할 때만 켜지고 끝나면 꺼집니다. 원고 하나를 점검하는 데 30초 안쪽이 걸렸습니다.

시험 원고에서는 기대한 대로 잡았습니다

시험 원고에는 가상의 경로, 사설 IP, 로컬 주소, 고객사 이름과 화면 코드, 그리고 블로그 공개 연락처를 섞었습니다.

경로, IP, 로컬 주소 세 문장은 규칙이 잡았습니다.
고객사 이름과 화면 코드가 든 문장은 규칙을 통과했지만, 판단 모델이 0.99로 잡았습니다. 판단 모델을 붙인 이유가 바로 이 한 줄입니다.
평범한 설명 문장은 모두 통과했습니다.

하나가 이상했습니다. 블로그에 공개해 둔 연락처 메일이 든 문장을 판단 모델이 0.98로 걸었습니다. 모델 입장에서는 메일 주소가 든 문장이니 고유정보처럼 보였을 겁니다. 하지만 이 주소는 일부러 공개한 값입니다. 그래서 허용 목록을 만들어, 공개 연락처와 블로그 주소가 든 문장은 판단 모델에 보내지 않고 통과시키도록 했습니다.

공개된 원고에 돌리자 오탐이 나왔습니다

시험 원고는 결국 제가 만든 문장입니다. 실제 실력은 실제 원고에서 봐야 합니다. 그래서 이미 공개해서 고유정보가 없다고 확인된 15편 원고를 넣었습니다.

89문장 중 75문장은 통과했고, 10문장이 확인, 4문장이 경고로 걸렸습니다. 걸린 14문장을 하나씩 읽어 보니 공통점이 있었습니다.

「고유정보가 들어 있는 문장 73개를 하나도 빠짐없이 잡았습니다.」
「회사 경로 하나가 공개 글에 나가면 되돌릴 수 없기 때문입니다.」

고유정보를 다룬 글이라서, 「고유정보」나 「회사 경로」라는 말 자체에 모델이 반응한 것입니다. 실제 값은 하나도 없는데, 주제를 말하는 단어만 보고 걸었습니다. 문장 안의 단어로 판단하는 모델의 한계가 그대로 드러난 셈입니다.

오탐을 세는 칸을 따로 만들었습니다

오탐이 나왔다고 바로 기준값을 올리지는 않았습니다. ⑮편의 교훈처럼, 적은 사례로 맞춘 기준값은 다음 원고에서 다시 흔들립니다. 대신 세 가지를 붙였습니다.

1. 오탐 추적 기록 : 원고를 점검할 때마다 문장 수와 경고·확인 수가 한 줄씩 쌓입니다. 걸린 문장을 본 뒤에는 오탐 수와 진짜 고유정보 수를 채웁니다. 2. 오탐 문장을 실제 사례로 저장 : 이번 14문장은 「실제 원고, 문제없음」으로 판정 기록에 넣었습니다. 지금까지 기준값은 대부분 만든 예시 문장으로 맞췄는데, 이제 실제 원고 사례가 쌓이기 시작합니다. 3. 편마다 오탐률을 비교 : 첫 기준선은 16%입니다. 몇 편이 쌓이면 실제 사례를 넣어 보정을 다시 맞추고, 오탐률이 내려가는지 봅니다.

같은 날 한 번 고쳤습니다

이 글도 발행 전에 같은 점검기를 거쳤습니다. 결과는 68문장 중 15문장이 걸렸고, 이번에도 모두 오탐이었습니다. 원인도 같았습니다. 이 글 역시 고유정보를 다루니 그 말이 계속 나옵니다.

그래서 기준값 대신 판단 모델에 보내는 문장을 바꿔 봤습니다. 「고유정보」, 「회사 경로」, 「화면 코드」 같은 주제어를 「그 항목」이라는 중립적인 말로 바꾼 뒤 판단하게 한 것입니다. 실제 값은 그대로 두고, 그것을 가리키는 일반 단어만 가립니다.

효과는 기존 표본으로 먼저 쟀습니다. 진짜 고유정보 문장 73개는 가린 뒤에도 하나도 놓치지 않았습니다. 15편과 이 글에서 모은 실제 오탐 29문장 중 걸린 것은 29개에서 13개로 줄었고, 경고 수준으로 걸린 것은 13개에서 2개로 줄었습니다. 이 글에 다시 돌리자 오탐은 15개에서 8개로, 경고는 9개에서 1개로 줄었습니다.

다만 가릴 단어 목록을 바로 그 오탐 문장들을 보고 정했기 때문에, 이 숫자는 조금 좋게 나왔을 수 있습니다. 진짜 효과는 다음 편 원고에서 확인됩니다. 오탐 추적 기록에는 가림 전과 후를 두 줄로 나눠 적어 두었습니다.

맺으며

이번에 정리한 것은 이렇습니다.

모양이 정해진 고유정보는 규칙이, 모양이 없는 고유정보는 판단 모델이 잡습니다.
공개하려고 둔 값은 허용 목록으로 판단 모델 앞에서 빼 둡니다.
시험 원고가 아니라 이미 공개한 원고로 재야 오탐이 보입니다.
이번 오탐은 실제 값이 아니라 주제를 말하는 단어에 반응한 것이었습니다.
기준값을 고치기 전에, 모델에 보내는 문장에서 주제어를 가려 오탐을 절반으로 줄였습니다.

점검기를 붙인 날 할 일은 「잘 잡는다」를 확인하는 것만이 아니었습니다. 무엇을 잘못 잡는지 세기 시작하는 것이었습니다. 다음 편은 준비하는 대로 적겠습니다.

이전 편: ⑮ 접었던 판단 모델을 4B로 다시 재 보니, 한 곳에서는 통했습니다
다음 편: ⑰ 질문 순서만 바꿨더니, 판단 모델의 답이 5% 뒤집혔습니다
연재 전체: Claude Code 하네스

실전 Claude Code 하네스 ⑮ 접었던 판단 모델을 4B로 다시 재 보니, 한 곳에서는 통했습니다

devalive — Fri, 16 Oct 2026 06:47:09 +0900

처음 오셨다면 용어 풀이와 연재 지도를 정리한 ⓪편 「AI에게 일을 맡기기 전에 알아야 할 것」부터 읽어 보세요.

지난주에 「작은 판단 모델은 한국어에 쓰기 어렵다」고 결론을 내리고 접어 둔 일이 있습니다. 이번 주에 같은 문제 461개를 더 큰 모델에게 다시 풀게 했습니다. 공개 글에 실제 경로나 계정 같은 「고유정보」가 섞였는지 가리는 문제에서는 정답률이 44%에서 89%로 올랐습니다. 반면 「근거 없는 문장」을 가리는 문제에서는 여전히 한쪽만 찍는 것보다 못했습니다.

이번 글은 같은 모델이 한 과제에서는 통하고 다른 과제에서는 통하지 않은 이야기입니다.

판단 모델은 글을 쓰지 않고 확률만 돌려줍니다

판단 모델은 정해 준 선택지마다 확률만 돌려주는 AI입니다. 「이 문장을 공개해도 되는가? 1. 문제없음 2. 고유정보」라고 물으면 문장을 쓰지 않고 「1번 0.2, 2번 0.8」처럼 숫자만 줍니다. 그래서 빠르고, 내 PC 안에서 돌릴 수 있습니다.

⑤편에서는 무료 판단 모델 Laya를 한국어 영상 분류에 써 봤고, 정답률이 60%에 그쳐서 보류했습니다. 그 뒤에 1.5B(15억 개 매개변수) 크기의 작은 언어 모델에도 같은 방식을 시험했지만, 문제를 454개로 늘리자 결과가 뒤집혀서 이것도 접었습니다. 이 과정에서 만든 판정 기록이 ⑨편의 블로그 교정자입니다.

다시 꺼낸 이유는 크기였습니다

이번 주에 다른 분이 한국어 업무 문서 200건으로 판단 모델 여러 개를 잰 영상을 봤습니다(Dante's Datalab 채널). 그 실측에서도 Laya는 공개 문서 대부분을 기밀로 잘못 걸렀습니다. 그런데 4B(40억 개) 크기의 모델 두 개는 기밀 문서를 95% 잡으면서 공개 문서를 잘못 거른 비율이 약 6%였습니다.

우리가 실패한 것은 1.5B였습니다. 그래서 크기만 바꿔서 다시 재 보기로 했습니다. 고른 모델은 판단용으로 따로 학습한 오픈 모델 JevK5 4B입니다. 라이선스는 Apache-2.0이라 상업적으로도 쓸 수 있고, 5비트로 줄인 파일이 약 3GB라 집에 있는 6GB 그래픽카드에 올라갑니다.

규칙은 하나만 정했습니다. 문제와 정답은 지난번과 똑같이 둔다. 모델만 바꿔야 차이가 모델 때문인지 알 수 있기 때문입니다.

같은 461문제, 결과는 과제마다 갈렸습니다

과제	4B 모델	한쪽만 찍었을 때	지난번 1.5B
고유정보 판정(166문제)	89%	56%	44%
사실 판정, 실제 원고 문장(35문제)	40%	77%	한쪽 찍기보다 못함
사실 판정, 만든 예시 문장(240문제)	66%	67%	한쪽 찍기보다 못함

「한쪽만 찍었을 때」는 모든 문제에 더 많은 쪽 답 하나만 냈을 때의 정답률입니다. 판단 모델이 이 숫자를 넘지 못하면 아무 생각 없이 찍는 것보다 못하다는 뜻입니다.

고유정보 판정은 확실히 좋아졌습니다. 고유정보가 들어 있는 문장 73개를 하나도 빠짐없이 잡았습니다. 대신 문제없는 문장 93개 중 19개도 고유정보로 걸렀습니다.

사실 판정은 여전히 안 됐습니다. 실제 원고에서 고친 문장 35개에서 40%였고, 확신이 0.9를 넘은 답 3개는 모두 틀렸습니다. 「근거 없는 단정」이나 「지나친 일반화」를 가려내는 일은 문장 안의 단어가 아니라 글 전체의 맥락과 상식을 봐야 합니다. 4B 판단 모델에게는 아직 무거운 일로 보입니다.

확신 숫자를 다시 맞추니 자동으로 넘길 몫이 늘었습니다

모델이 「0.9 확신한다」고 말할 때 실제로 열에 아홉이 맞는지는 따로 확인해야 합니다. 그래서 이틀 뒤에 확률 보정을 해 봤습니다. 모델의 원래 확률에 기울기와 치우침 두 숫자만 맞춰서, 「0.9」가 실제로 0.9의 확률로 맞도록 고치는 방법입니다. 문제를 다섯 묶음으로 나누고, 보정할 때 쓰지 않은 묶음에서만 결과를 쟀습니다.

고유정보 판정에서는 효과가 컸습니다.

정답률이 89%에서 94%로 올랐습니다.
확신 0.9 이상만 자동으로 처리한다고 하면, 그 몫이 전체의 54%에서 80%로 늘었고 그중 98%가 맞았습니다.
사람이 다시 봐야 할 문장이 77개에서 33개로 줄었습니다.

그런데 함정이 하나 있었습니다. 보정한 뒤 흔히 쓰는 기준값 0.5를 그대로 쓰면 고유정보 문장 4개를 놓쳤습니다. 고유정보는 놓치는 쪽이 훨씬 비쌉니다. 회사 경로 하나가 공개 글에 나가면 되돌릴 수 없기 때문입니다. 그래서 「고유정보일 확률이 0.1만 넘어도 경고한다」로 기준을 낮췄더니 놓친 문장이 다시 0개가 됐습니다.

정리하면, 보정의 이득은 「고유정보 의심」을 더 잘 잡는 데서 나오지 않았습니다. 「문제없음」 판정을 믿고 넘길 수 있는 몫이 늘어난 데서 나왔습니다.

사실 판정은 보정해도 소용이 없었습니다. 보정 숫자를 맞춰 보니 기울기가 음수로 나왔는데, 이는 모델이 확신할수록 오히려 틀린다는 뜻입니다.

그래서 이렇게 붙였습니다

1. 정규식과 금지어 목록이 먼저 거릅니다. 실제 경로나 회사 코드처럼 모양이 정해진 것은 규칙이 가장 확실합니다. 이 원칙은 지난번부터 그대로입니다. 2. 판단 모델이 남은 문장을 셋으로 나눕니다. 고유정보일 확률이 0.1을 넘으면 경고하고, 「문제없음」 확신이 0.9를 넘으면 통과시키고, 나머지는 다음 단계로 넘깁니다. 3. 애매한 문장은 Claude의 작은 모델(Haiku)이나 사람이 봅니다.

사실 판정은 지금처럼 Haiku가 맡습니다. 판단 모델 자리는 비워 둡니다.

한계도 적어 둡니다. 고유정보 문제 166개 중 대부분은 실제 원고가 아니라 만든 예시 문장입니다. 그래서 0.1과 0.9라는 기준값은 아직 확정하지 않았습니다. 실제 원고에서 걸러 낸 문장이 쌓이면 같은 방법으로 다시 맞출 생각입니다. ⑤편에서 얻은 교훈인 「적은 문제로 낸 결과를 믿지 않는다」를 이번에도 지키는 셈입니다.

맺으며

이번에 정리한 것은 이렇습니다.

접어 둔 모델도, 같은 문제와 같은 정답으로 다시 재면 비교가 됩니다.
모델을 키웠더니 고유정보 판정은 44%에서 89%로 올랐고, 사실 판정은 그대로였습니다.
그래서 「이 모델을 쓸까」가 아니라 「이 과제에 쓸까」를 묻게 됐습니다.
확률을 보정하니 믿고 넘길 몫이 54%에서 80%로 늘었지만, 기준값 0.5는 놓침을 만들었습니다.
판단 모델은 정규식 뒤, 사람 앞에 둡니다.

한 번 「안 된다」고 적은 결론도 조건이 바뀌면 다시 잴 수 있습니다. 다만 그때도 문제와 정답은 그대로 두어야 합니다. 다음 편은 준비하는 대로 적겠습니다.

이전 편: ⑭ AI가 기억으로 쓴 API 이름, 118개 중 22개가 없었습니다
다음 편: ⑯ 원고 점검기에 판단 모델을 붙였더니, 첫날 오탐이 16%였습니다
연재 전체: Claude Code 하네스

실전 Claude Code 하네스 ⑭ AI가 기억으로 쓴 API 이름, 118개 중 22개가 없었습니다

devalive — Wed, 14 Oct 2026 08:59:13 +0900

처음 오셨다면 용어 풀이와 연재 지도를 정리한 ⓪편 「AI에게 일을 맡기기 전에 알아야 할 것」부터 읽어 보세요.

어제 Claude와 함께 국내 SI 현장에서 많이 쓰는 UI 플랫폼 두 가지(WebSquare, Nexacro)의 점검 도구를 만들었습니다. 화면 코드에 존재하지 않는 API가 쓰였는지 잡아내는 도구입니다. 그 도구의 「허용 목록」을 공식 문서와 맞춰 보다가, Claude가 기억으로 적어 넣은 이름 118개 중 22개가 공식 문서에 없다는 것을 발견했습니다.

이번 글은 그 22개에 관한 이야기입니다.

공개 코드가 적은 플랫폼에서 AI는 이름을 지어냅니다

이 두 플랫폼은 공공·금융·기업 화면에 많이 쓰이지만, 인터넷에 공개된 코드가 많지 않습니다. 그러면 AI는 비슷한 다른 도구에서 본 이름을 섞어 그럴듯한 API를 만들어 냅니다.

작업을 시작할 때 참고로 받은 한 검색 AI의 답변에도 그런 흔적이 있었습니다. 「회계 화면용 금액 표시 함수」라며 짧은 코드를 보여 줬는데, 직접 돌려 보니 1000000을 넣어도 쉼표 없이 1000000이 그대로 나왔습니다. 정규식에서 \d{3}이 \d3으로 적혀 있었습니다. 같은 답변에 나온 단축키 API 이름은 공식 문서에서 찾을 수 없었습니다.

여기까지는 예상한 일이었습니다. 예상하지 못한 것은 그다음입니다.

점검 도구를 만드는 Claude도 지어냈습니다

점검 도구는 이렇게 동작합니다. 화면 코드에서 데이터목록.메서드() 꼴의 호출을 찾고, 그 메서드가 허용 목록에 있는지 봅니다. 목록에 없으면 「지어낸 API일 수 있다」고 알립니다.

처음 허용 목록은 Claude가 썼습니다. 공식 문서를 조사한 보고서를 바탕으로 하되, 「자주 쓰는 것」이라며 몇 개를 더 붙였습니다. 그 목록을 공식 API 문서와 자동으로 대조하자 결과가 이렇게 나왔습니다.

플랫폼	Claude가 쓴 이름	공식 문서에 없던 이름	목록을 만든 방법
WebSquare	118개	22개	조사 보고서 + 기억으로 덧붙임
Nexacro	83개	1개	조사 보고서에서만 가져옴

없던 이름들은 하나같이 그럴듯했습니다. getData, setDataList, show, focus처럼 다른 도구에서는 실제로 쓰는 이름들입니다. 차이를 가른 것은 이름이 어디서 왔느냐였습니다. 조사 보고서에서 가져온 이름은 거의 맞았고, 기억으로 덧붙인 이름이 틀렸습니다. Nexacro에서 틀린 1개(Grid.redraw)도 보고서가 아니라 기억에서 나온 이름이었습니다.

목록은 사람도 AI도 아닌 공식 문서가 만들게 했습니다

고친 방법은 단순합니다. 허용 목록을 손으로 쓰지 않습니다. 공식 API 문서에서 메서드 이름을 자동으로 뽑는 작은 스크립트를 만들었습니다.

WebSquare는 공식 API 문서 페이지에서 뽑았습니다. 데이터 목록 140개, 단건 데이터 37개, 그리드 232개입니다.
Nexacro는 공식 레퍼런스 목차에서 뽑았습니다. 데이터셋 125개, 그리드 150개입니다.
목록 파일 첫 줄에 「자동 추출: 손으로 고치지 말 것」을 적었습니다.

프로젝트가 다른 버전을 쓰면 그 버전의 문서 주소로 스크립트를 다시 돌리면 됩니다. 사람의 기억도, AI의 기억도 거치지 않습니다.

점검 도구는 일부러 틀린 화면으로 시험했습니다

13편에서 적은 원칙대로, 점검 도구도 걸려야 할 실수를 일부러 넣은 화면으로 시험했습니다. 실수 없는 화면에서는 아무것도 나오지 않아야 하고, 실수를 넣은 화면에서는 넣은 실수가 모두 나와야 합니다.

가장 의미 있게 잡힌 것은 「그리드에서 셀 값을 읽는」 호출이었습니다. 이 플랫폼의 그리드에는 그런 메서드가 없고, 값은 그리드에 연결된 데이터 목록에서 읽어야 합니다. 옛 버전에는 그리드에 같은 이름의 메서드가 있었기 때문에, 사람도 AI도 습관처럼 쓰기 쉬운 실수입니다.

근거가 있는 것과 없는 것을 나눠 적습니다

이번 일로 하네스에 한 줄을 더했습니다. API 이름처럼 틀리면 바로 깨지는 정보는 기억으로 채우지 않는다. 근거 문서가 없으면 「미확인」으로 남기고, 목록은 문서에서 뽑습니다.

한계도 있습니다. Nexacro의 옛 버전 두 가지는 온라인 레퍼런스가 없어서, 지금 목록은 최신 버전 기준입니다. 옛 버전에서만 없는 이름은 아직 이 도구로 다 잡지 못합니다. 이 부분은 실제 현장 화면을 받아 확인할 생각입니다.

맺으며

이번에 정리한 것은 이렇습니다.

공개 코드가 적은 분야일수록 AI는 그럴듯한 이름을 지어냅니다.
그 실수를 잡는 도구를 만드는 AI도 같은 실수를 합니다.
차이를 만든 것은 이름의 출처였습니다. 문서에서 온 이름은 맞았고, 기억에서 온 이름이 틀렸습니다.
그래서 허용 목록은 공식 문서에서 자동으로 뽑습니다.
점검 도구는 일부러 틀린 화면으로 시험한 뒤에 씁니다.

AI에게 「정확히 해 줘」라고 말하는 대신, 정확한 출처에서 가져오는 길을 하나 더 만들었습니다. 다음 편은 준비하는 대로 적겠습니다.

이전 편: ⑬ 「확인해 줘」라고 말하는 대신 확인할 수단을 남겼습니다
다음 편: ⑮ 접었던 판단 모델을 4B로 다시 재 보니, 한 곳에서는 통했습니다
연재 전체: Claude Code 하네스