15 단계 회사 자료 AI — 고치기 전에 자부터

뒷이야기 · 15 / 17단계 · 2026-09-20 ~ 10-07 · 갈래 회사 자료 AI
이전 단계: 14 사무직 AI 작업실 — 직원마다 개인 비서 · 다음 단계: 16 가르치기 — 발표와 강좌

핵심 요약

한 줄 요약 — 고치기 전에 자부터 만든다. 그런데 자도 틀린다. 점수가 움직이면 먼저 자를 의심하고, 예전 정답 조각의 본문을 열어 본다.

15단계 · 회사 자료 AI — 고치기 전에 자부터

목적

사내 문서 검색(규격 코드북 · NAS(사내 공용 파일 서버) 파일 · 표)은 9월부터 파이스 안에 있었다. 직원에게 열기 전에 "찾은 것이 맞는가" 를 숫자로 알아야 했다. 숫자가 없으면 좋아졌는지 나빠졌는지 모른 채 며칠을 쓴다.

9/29 01:10 에 작업실에서 사고가 났다. 같은 대화에서 문서 셋을 만들게 한 뒤(한 턴에 입력 80만 토큰 — 토큰은 AI 가 글을 읽는 단위다), 01:41 부터 답이 전부 빈칸이었다. 원인은 Claude Code(터미널용 AI 도구)가 옛 판이라 400: version 2.1.280 or newer is required 가 났는데 화면이 빈 말풍선으로 보여 줬기 때문이다(두 대화 합쳐 10번). 02:05 에 "한 프로젝트의 P&ID(배관계장도) 최신본을 확인해서 Equipment List(장비 목록)를 만들어 줘" 를 시키자 도구 호출 19번에 find_files 0 · drawing_info 0 · 파일 생성 0 으로 끝났다. 폴더가 색인에 없었다. 02:17 에 AI 가 "색인에 없다" 며 끝냈고, 체감으로 30분이었다.

만든 순서

1 · 먼저 자를 만들고 검색을 합쳤다 — 하이브리드 검색 (9/20)

뜻 검색(문장을 숫자 벡터로 바꿔 비슷한 것을 찾는 방식)만으로는 SA-516·QW-406 같은 규격 번호에 약했다. 어휘 검색(BM25, 글자가 맞는 정도로 점수를 매기는 방식)을 얹어 하이브리드로 바꾸기로 했다. 바꾸기 전에 자부터 만들었다. scripts/rag-eval.mjs 에 답을 아는 질문 17개를 넣었다(코드를 지정한 6 · 규격 번호로 묻는 7 · 코드 이름 없이 묻는 4).

자를 짜다가 두 번 틀렸다. 처음엔 "동력보일러 안전밸브" 의 정답을 ASME Sec.I 하나로 적었다. 검색은 에너지이용합리화법을 1등으로 줬고, 그게 맞는 답이었다. 세종은 세 코드를 다 쓰고 어느 것을 쓸지는 발주처가 정한다. 코드 이름 없이 물으면 답이 여럿인 게 정상이다. 둘째, 정답 판정이 문서 이름만 보고 머리(어느 책 어느 조항인지 적힌 칸)를 안 봤다. 맞는 답을 틀렸다고 세서 하이브리드가 더 나쁜 것처럼 보였다(MRR 0.824. MRR 은 정답이 몇 등에 나왔는지를 1/등수로 평균 낸 점수라, 1에 가까울수록 좋다). 고치니 0.941 이었다.

BM25(k1 1.2 · b 0.75)와 뜻 순위를 RRF(순위만 보고 합치는 방식, k 60)로 합쳤다. 결과는 1등 14/17 → 17/17, MRR 0.853 → 1.000 이었다. 고치는 동안 안 본 딴 문항 12개는 두 방식 다 12/12 였다. 비용은 어휘 색인 0.7초(한 번) · 질의당 0ms · 힙 218MB 다.

바로 뒤(9/21 00:31)에 한 번 더 고쳤다. 합친 순위를 순위값(0, -1, -2…)으로 내보냈더니, 메신저 AI 가 score >= 0.4 로 거르는 곳에서 한글 질문의 사내 문서가 통째로 버려졌다. "용접사 자격은 몇 개월" 의 점수가 [0, -1, -2] 라 0.4 를 넘는 것이 0개였다. 점수는 시스템 경계를 넘는 값이다. 바꾸기 전에 쓰는 곳을 전부 봤어야 했다. 점수를 0~1 눈금으로 되돌리고 셀프체크에 박았다.

2 · 읽을 양을 줄였다 — 1비트 해밍 미리거르기 (9/21)

"우리 회사 모든 자료를 ASME 처럼 색인할 수 있나" 라는 물음이 나왔다. 글 482,958개와 도면 228,094개를 합치면 약 1,200만 조각이다. 지금 방식(벡터 전부를 정확히 곱해 보기)은 훑기만 8.8초라 "가능하지만 못 쓴다" 는 답이 될 뻔했다. 그게 틀린 답이었다.

41,807조각 색인에서 네 방법을 재 보고 1,200만 조각으로 환산했다. 그대로 30.6ms(8.8초), 루프 펴기 21.6ms(6.2초), 8비트 정수 30.2ms(8.7초 — JS 에 SIMD(여러 숫자를 한 번에 계산하는 CPU 기능)가 없어 이득이 없었다), 1비트 해밍 1.4ms(0.4초, 22배). 벡터의 부호만 1비트로 남긴 사본을 곁에 둔다(1,024차원이 128바이트, 32배 작다). XOR 과 비트 세기로 해밍 거리(서로 다른 비트의 수)를 재서 후보를 추리고, 그 후보만 원래 숫자로 정확히 다시 잰다. 그래서 최종 점수와 순서는 전수 검색과 같은 눈금이다.

정확도는 추측하지 않고 쟀다. 1등의 해밍 등수는 중앙값 3위, 최악 459위(41,807개 중 1.1%)였다. 후보를 넉넉히 잡아 자 17문항이 전수와 똑같이 17/17(MRR 1.000)이었다. 후보 수를 2,000으로 조여도 같았다. 20만 조각 아래에서는 전수가 30ms 라 이득이 없고 결과가 달라질 수 있어서 문턱을 뒀다. 그 아래에서는 옛 결과가 한 글자도 안 바뀐다.

같은 날 오전(08:34)에 옵시디언 볼트(노트 217만 개)에도 적용했다. 검색 한 번이 4~6초에서 0.31~0.34초(15배)가 됐다. 병목은 CPU 가 아니라 디스크였다. 8.9GB 를 질문마다 5초에 읽으니 초당 약 1.8GB, 이 맥의 NVMe(빠른 SSD) 속도 그대로였다. 계산을 빠르게 해도 안 줄었을 것이다. 읽을 양을 줄여야 했다(사본 266MB, 짓는 데 6초).

작업 PC(윈도우)에서 합성 벡터(4만 1,807개 × 1,024차원)로 방법만 다시 재 봤다(두 번, 잴 때마다 값이 달랐다). 전수는 56~107ms, 후보를 1,000~2,000개로 잡은 1비트 방식은 5~8ms 였고 상위 5개는 같았다. 기본 후보 수(5만)가 조각 수보다 크면 걸러지는 것이 없어 오히려 103~153ms 로 전수보다 느렸다. 맥의 숫자(30.6 → 1.4ms)는 커밋 메시지의 값이고 다시 재지 못했다.

배운 것: 빠르게 만들기 전에 어디가 느린지 잰다. 원본 8.9GB 는 절대 메모리에 안 올린다(8/15 에 파이스가 "헬스 무응답" 이 된 바로 그 짓이다).

3 · 30분 사고와 청사진 — "고치기" 로 정했다 (9/29 ~ 10/1)

사고를 로그로 다시 짰다(작업실 대화 파일과 도구 호출 기록). 원인은 12개로 정리됐다. 셋이 핵심이다. ① 구버전 → 400 → 빈 말풍선 ② 찾으려던 폴더가 색인에 없었다 ③ 한 세션에 모든 일을 몰아 넣어(Opus 5.5 + 노력 high) 턴마다 입력 46만~80만 토큰, 64~153초가 걸렸다.

세 선택지를 비교했다. 파인튜닝(AI 를 추가로 학습시키는 일)은 세 원인을 하나도 못 푼다. 색인에 없는 폴더는 학습된 모델도 모른다. 처음부터 새 에이전트를 만들면 이미 잘 된 울타리·표·계산기를 다시 만든다. 고치기를 택했다. 10/1 01:39 에 making-ai 저장소의 첫 커밋을 남겼다. 청사진 문서(진단 · 목표 구조 · 5단계 · 12주 로드맵 · 코드 조각 · "하지 말 것")와 아치파이 그림이 들었다.

원칙은 셋이다. 찾기는 표·경로로 하고 뜻 검색은 보조로 쓴다. 긴 계산은 서버 작업으로 돌리고 두뇌는 결과만 받는다. 작업 하나는 세션 하나다. 하지 말 것도 적었다. 지금 파인튜닝, 전체 재구축, 도면 전량 OCR, 한 대화에 여러 일.

4 · 응급조치와 찾기 도구 — 50만 한도가 폴더를 막고 있었다 (10/1)

0단계(응급조치)는 10/1 02:01 에 코드가 끝났다. 옛 판 오류가 나면 저절로 새로 받기, 끊긴 답도 까닭을 보여 주기, 첫 응답이 오면 곧바로 세션 저장, 도면 폴링이 오류를 삼키지 않기, 노력 기본값을 medium 으로, 입력 30만 토큰이 넘으면 새 대화로 안내하기, 안내문 두 줄이다. 자체 시험은 30개에서 33개가 됐다. 같은 날 11시에 실물로 확인했다. 찾기 도구를 부르고, 도면 결과가 말풍선에 나오고, 색인에 없는 판은 "색인에 없다" 고 정직하게 답했다. 긴 대화가 새 대화보다 느렸다(524초 대 20초).

"찾으려던 폴더가 왜 색인에 없었나" 는 맥에서 직접 쟀다. 그 폴더는 파일이 53,558개인데 카드(파일 하나를 설명한 작은 메모)가 0장이었다. 업체 폴더 63개 중 카드가 있는 것은 7개뿐이었다. 처음엔 기록에 있던 ENAMETOOLONG 오류를 범인으로 봤다. 그건 9/14 에 고친 옛 회차였다. 진짜 까닭은 9/30 밤 회차의 숫자였다. 기술부·설계팀·품질관리부 셋이 "훑음 500000" 에서 정확히 끊겼다. 50만이라는 한도가 "새로 만들 카드" 가 아니라 "훑은 파일" 에 걸려 있어서, 이미 카드가 있는 파일까지 세다가 가나다순 뒤쪽(업체별)에 영영 닿지 못했다. 오류가 아니라 한도였다. 한도를 새 카드에만 걸자 다시 훑은 결과 73만 7천 개를 훑고 새 카드 18만 6천 장이 생겼다.

1단계(찾기 도구)는 Sonnet 5.5 가 짓고 Opus 5.5 가 검토·맥 실측을 했다. find_files 에 날짜·확장자 걸러내기, index_status(폴더의 카드 수·마지막 훑기), list_folder(폴더를 한 단계씩), 낮 훑기(06·10·14·18·22시, 바뀐 폴더만), 로그인 토큰 파일이다. 12:51 에 1단계가 끝났다. 같은 함정을 도구가 스스로 알려 주게도 했다. index_status 는 옛 기록의 정확히 500000 을 한도에 걸린 것으로 읽는다. 그 뒤(10/3)에는 메신저에 파일 찾기가, 작업실에 압력용기 계산 도구(pv_calc)가 붙었다. 산초에 이 창구를 붙이는 것은 안 하기로 정했다.

5 · 장비 표를 LLM 말고 규칙으로 (10/1 ~ 10/3)

목표 시나리오는 "찾기 → 도면에서 장비 표 → 엑셀" 세 번 호출에 수 분이었다. 먼저 맥 로컬 LLM 에게 도면 여러 장을 한 작업으로 읽혔다(39131ad). 도면 2장에 999초가 걸려 375줄이 나왔고 "확인 필요" 가 166칸이었다.

도면 구조를 세어 보니 태그·이름·용량이 블록 속성(CAD 부품에 붙는 이름표 칸)이 아니라 그냥 글자였다(태그 꼴 97%). 레이어는 번호뿐이고 글자 높이로는 장비와 계기가 안 갈렸다. 대신 장비마다 정보 상자가 있었다. 칸 이름이 있는 꼴(ITEM NO.·ITEM NAME·CAPACITY…)과 칸 이름 없이 태그가 위에 있는 꼴(펌프 등)이다. 규칙으로 읽는 시제품이 태그 꼴 99.8%, 이름·용량 100% 였다. 15:48 에 drawing_boxes.js 를 넣었다. 16:05 에 칸이 둘뿐인 상자까지 고친 뒤, 한 프로젝트의 P&ID 는 장당 장비 42개를 8초에 읽는다(LLM 0번). LLM 이 낸 장당 187줄은 대부분 장비가 아니었다.

점수를 재는 채점기는 사람이 만든 장비 목록을 정답지로만 쓴다. 만드는 쪽에는 안 넘긴다. 첫 점수 F1(재현율과 정밀도를 하나로 합친 점수) 0.41 은 P&ID 를 1/27·2/37·5/57 장만 읽은 때라 무의미했다. 낮은 점수는 정확도가 아니라 안 읽은 도면이었다. 덜 읽은 프로젝트는 합계에서 뺐다.

같은 날 맥에서 조용한 고장 둘을 더 찾았다. 밤 작업이 NAS 가 멀쩡한데 0.9분 만에 "원본 없음 100번 연달아" 로 멈췄다. 지워진 폴더의 카드가 순서상 한데 몰려 있었을 뿐이다. 순서가 매일 같아서 매일 밤 같은 자리에서 멈추고 P&ID 1.7만 장이 영영 안 읽힐 뻔했다. 이제는 마운트를 직접 본다. 또 "원본 없음" 56,179장(도면 카드의 22%)은 표본을 보니 98% 가 한글 NFC/NFD 문제였다(한글을 글자 하나로 저장하느냐, 자음·모음 낱개로 저장하느냐의 차이). PC 시절 카드의 경로는 조합형인데 맥 smbfs(NAS 공유 폴더를 맥에 붙이는 방식)는 분해형으로만 연다. 고친 뒤 원본 없음은 1,109장으로 줄었다.

10/2 밤에는 상자 없는 P&ID 를 봤다. 읽은 1,612장 중 상자 871 · 없음 650(40%) · 실패 91 이었다. 실패 91 중 78장이 옛 AutoCAD 2000 형식이었고, 글자가 적은 20장 중 7장은 블록 속 글자를 안 읽고 있었다. 읽는 방법을 고쳐도 상자가 생긴 것은 30장 중 3장이었다. 나머지는 원래 상자가 없는 도면이다. 그 도면만 밤에 로컬 LLM 이 읽는다(장당 449~546초, 하룻밤 16~20장). 10/3 첫 점검에서 다 읽은 4개 프로젝트의 F1 은 0.04 였다. 그런데 큰 몫이 정답지 쪽 사정이었다(정답이 1개로 읽혔거나, 그 종류를 안 다뤘거나, 태그가 도면 글자에 아예 없거나). 범위를 맞춘 점수는 0.56~0.79 였다.

6 · 시험지 52항목과 헛점수 — 자가 틀렸다 (10/3 00:59 ~ 13:58)

3단계 검색 정확도를 고치기 전에 시험지부터 만들었다(tools/search-exam.json). 규격 22(회사 표준 2 포함) · 파일 15 · 표 15, 모두 52항목이다. 정답은 10/2 밤 맥에서 직접 센 값이다. 규격은 그 조항이 머리에 든 조각이 실제로 있는지 세고, 파일은 카드 폴더를 직접 세고, 표는 정답 SQL 을 돌렸다. 한국어→영어 낱말 사전(203항목)을 만든 쪽은 시험지를 안 봤다. 시험지에 맞춘 사전은 점수만 오르기 때문이다. 시험지는 새벽 4:40 밤 채점에도 붙였다(어제보다 나빠질 때만 실패).

첫 기준선에서 자가 또 틀렸다. "수주통보서" 의 정답을 폴더 하나만 적었는데 1등은 다른 폴더의 진짜 수주통보서였다. 폴더를 넓혀 고쳤다. 점수는 이렇게 나왔다(같은 시험지, 맥). 규격 두 줄은 바로 아래에 나오는 느슨한 채점으로 잰 값이다.

이어서 규격 책 13권을 고친 조각내기로 다시 조각냈더니 점수가 떨어졌다(MRR 0.738 → 0.683). 따라가 보니 떨어진 두 문항의 "예전 정답" 이 둘 다 가짜였다. 채점이 정답 조항을 조각의 머리뿐 아니라 글 앞 150자에서도 찾았다. ASME 본문은 앞부분에 다른 조항 참조가 흔하다. 시험지 규19 의 "1등 UCS-56" 은 UF-37 조각이었다(글 앞에 "…if UCS-56 requires…" 가 있었다). 진짜 UCS-56 조각은 예전에도 11위였다. 규06 의 "5위 UW-12" 는 경판 조각에 잘못 붙은 머리였고, 진짜 UW-12 는 18위였다.

조항을 조각 자기 머리에서만 보도록 고쳐 다시 쟀다. 같은 옛 조각, 같은 22문항에서 헛점수 0.738(1등 14 · 상위5 20) → 진짜 0.586(1등 10 · 상위5 18) 이었다. 다시 조각낸 뒤는 0.633(1등 11 · 상위5 19)이다. 첫 다시 조각내기는 0.528 로 나빠서, 부록·다른 장 참조·번호뿐인 장 제목 처리를 고친 조각내기로 올렸다. 이어서 일반 질문에 전문 장(주철·브레이징 등) 조항이 앞서면 뒤로 미는 "장 맞추기" 로 0.670, 부록 조각을 본문 뒤로 미는 것으로 0.679(상위5 20)가 됐다. 한 가지는 알아야 한다. 처음 기준선 0.345 도 같은 느슨한 채점으로 잰 값이라, 엄격 채점으로 다시 재지는 못했다.

기록으로 세면 자가 틀린 일은 다섯 번이다. ① 9/20 정답을 한 코드로만 적음 ② 9/20 판정이 머리를 안 봄 ③ 10/3 정답을 폴더 하나로만 적음 ④ 10/3 글 앞 150자의 참조를 정답으로 셈 ⑤ 10/7 사본이 많은 곳에서 "그 파일" 점수를 자로 믿음(8번 기록). 밤 채점의 자도 9/23 첫날 두 문항이 둘 다 자 쪽 잘못이었다. 배운 것은 이렇다. 점수가 떨어지면 먼저 "예전 정답 조각" 의 본문을 열어 진짜 정답인지 본다. 순위 숫자만 보면 고친 것이 나빠 보인다.

7 · 받아서 쟀더니 나빠진 것들 (10/3)

좋다고 알려진 방법도 우리 자료에서 재 봤다. 작성자(crazy4eu)의 허락을 받아 재순위 모델(후보를 모델이 다시 매기는 방법, bge-reranker-v2-m3)을 맥에 받았다(모델 캐시 4GB). 같은 색인·같은 후보 30개로 비교했다. 원래 순서는 MRR 0.738 · 1등 14, 모델 순서는 0.666 · 1등 12 였고 질문당 2초가 더 걸렸다. 국내 규정 질문은 좋아졌지만 ASME 조항 질문이 다른 규격 조항에 밀렸다. 14가지로 섞어 본 최고 0.758 은 같은 22문항에 맞춘 값이라 잡음과 가를 수 없었다. 서버는 남기고 기본 꺼짐, 상주도 안 시키기로 했다(손으로 띄워 다시 잴 수 있다). 로컬 qwen 모델로 다시 매기는 것도 MRR 0.712 → 0.702 로 나빠졌고 절반이 점수 개수를 틀려 꺼 뒀다.

다만 이 비교 값들은 위 헛점수가 섞인 채점으로 쟀다. "안 쓴다" 는 결론의 방향은 같은 채점 안의 비교라 유효하지만, 엄격 채점으로 다시 재지는 않았다.

시험지가 퇴보도 잡았다. 한국어→영어 넓히기는 새 시험지에서는 좋아 보였는데, 옛 17문항과 밤 채점에서 둘이 나빠졌다. "SA-516 허용응력" 이 넓혀져 엉뚱한 조항이 1등이 됐고(17 → 16/17), 코드 이름 없는 "압력용기 수압시험 몇 배" 에서 ASME 의 1.3배가 국내 기준 1.5배를 밀어냈다. 그래서 식별자가 든 질문은 안 넓히고, 영어 규격을 가리킬 때만 넓힌다. Sonnet 이 짠 셀프체크는 다 통과했고, 맥 실측으로만 퇴보가 보였다. 옛 17문항과 밤 채점을 늘 같이 돌려야 한다.

환경변수 이름 충돌도 하나 찾았다. 재순위를 끄는 DOC_RERANK 를 미리거르기의 후보 수도 읽고 있었다. 재순위를 0 으로 끄면 20만 조각부터 후보가 조용히 쪼그라들 뻔했다. 이름을 갈랐다.

8 · 문서 본문 색인 (10/3 ~ 10/7)

파일 카드는 이름·경로·600자 요약뿐이라 "그거 어디 썼더라" 가 본문으로는 안 걸렸다. 청사진의 원칙대로 전체를 한 번에 다시 하지 않고 폴더 하나로 먼저 재 봤다. 품질관리부 최근 2년 문서 3,654개가 대상이었고, 3,458개를 읽어 1,299개 문서 · 18,653조각을 색인했다(27분). 막힌 것은 스캔본 1,456(42%) · 글 깨짐 355 · 큼 148 · 주민번호 꼴 66 · 도면 글 20 이다. 울타리는 원본 읽기와 같은 함수이고, 문서 전체에서 도면 글이나 주민번호 꼴이 한 군데라도 보이면 문서째 뺀다.

맥의 gemma4 가 문서마다 지은 내용 질문 30개로 쟀다. 카드 뜻 검색은 상위5가 2/30(MRR 0.069)이었고, 본문 색인은 17/30(0.390)이었다. 관문이 본문을 규격 몫의 꼬리에서 자르던 것을 고쳐 본문 몫을 따로 줬다. 질문이 규격 이름을 대면 본문 몫은 없다.

10/4 에 전 부서로 넓혔다. 순서는 작성자가 정했다(규격 → 기술부 → 구매·영업·생산·안전·재무·총무 → 나머지). 문서가 9만 건 가까이라, 파일 저장소로는 서버가 벡터 1.2~2GB 를 메모리에 올리고 50건마다 통째로 다시 써야 했다. 맥은 16GB 중 여유가 13%였다. 저장소를 SQLite(파일 하나로 된 작은 데이터베이스) 한 파일로 바꿨다. 읽을 때는 조각당 134바이트(번호 4 + 1비트 서명 128 + 범위 2)만 메모리에 둔다. 50만 조각이 약 67MB 다. 계획 한 바퀴(7.8시간)에 문서 1만 8,266개 · 조각 14만 2,911개가 들어갔다.

그런데 시범에서 17이던 상위5가, 전 부서로 넓힌 뒤 모든 부서 범위로 물으면 12로 떨어졌다(10/7, 품질관리부 범위는 15). 품질관리부 문서만 놓고 물으면 17 · MRR 0.393 으로 시범과 똑같았다. 장치 탓이 아니었다. 뜻 후보를 4천에서 4만으로 늘려도 그대로라 후보 수 탓도 아니었다. 놓친 18개 중 8개는 정답과 거의 같은 글(다른 폴더의 사본·개정판)이 위에 있었다. 같은 글이 자리를 여럿 먹은 것이다. 거의 같은 글을 한 줄로 묶고, 자리는 문서 먼저 주었다. 그러자 품질관리부 범위(전사 공용 폴더 포함)는 상위5가 15에서 19로(MRR 0.333 → 0.478), 모든 부서 범위는 12에서 16으로(MRR 0.289 → 0.386) 올랐다.

기술부는 달랐다. 같은 양식의 문서가 프로젝트마다 수십 벌이라 "그 파일" 을 맞히는 엄격 점수는 4/30 이었다. 미리 만든 같은 글 묶음 표(3,338묶음)를 순위에 쓰는 세 방식(숨김 · 상한 · 없음)을, 정답을 "그 파일 또는 같은 묶음의 구성원" 으로 넓혀 같은 자로 재 보니 순위에 쓰면 오히려 덜 맞았다. 그래서 묶음 표는 순위에 안 쓰고 결과의 사본 목록에만 붙인다. 엄격 점수만 봤다면 사본 목록 덕을 순위 덕으로 착각해 숨김을 켤 뻔했다. 프로젝트 번호를 대면 그 프로젝트 문서 안에서 먼저 찾는 보정은, 1등 자리에 그 프로젝트의 문서가 오는 질문을 18에서 30/30 으로 올렸다(번호가 대개 경로에만 있어 어휘가 못 잡았다). 정답(그 파일 또는 같은 묶음)이 상위5에 든 것은 29/30(1등 20)이었다.

9 · 밤 배치와 밤 채점 — 조용히 멎는 것들 (9/23 ~ 10/3)

맥에서 밤마다 도는 일이 늘었다(launchd 예약, 시각은 plist 에서 읽은 값). 도면 태그 읽기 22:30·03:40, 카드 요약 01:00, 밤 로컬 LLM 장비 읽기 01:05, NAS 훑기 02:00, 스캔 PDF 글자 인식 03:35, 밤 채점 04:40, 문서 본문 색인 06:10, 낮 훑기 06·10·14·18·22시.

파일 카드 207만 장은 대부분 이름·경로뿐이었다. 카드 요약 배치(9/26 가동)가 여기에 요약을 채운다. 도면·범위 밖·개인 자료를 빼고 남은 후보는 약 27만 7천 장(옛 형식 · 새 형식 · PDF)이었다. 가동 전에 적대 검토(일부러 구멍을 찾는 검토)를 돌려 네 가지를 잡았다. 도면을 거르는 규칙이 실제 도면 이름 대부분을 놓쳤고, 이는 원본 읽기도 같은 구멍이었다. 폴더 범위만 봐서 전사 폴더에 섞인 개인 서류 15장이 요약됐다가 즉시 되돌렸다(의미 색인에는 안 들어갔다). 밤중에 NAS 가 끊기면 수만 장에 "원본 없음" 이 영구 표시될 뻔했다. 한글 특수 글자 하나에 해석기가 통째로 죽었다.

9/27 첫 밤은 27,367장을 채웠다(105.3분). 둘째 밤(9/28)에는 남은 230,948장이 전부 "NAS 안 붙음" 이었다(그때는 밤중에 NAS 가 떨어졌다고 보았다). 9/29 부터는 매일 같은 모양으로 떨어졌고, 진짜 원인은 10/3 에야 찾았다. 닷새 밤(9/29~10/3) 동안 26만 장을 건너뛴 셈이다. 10/3 새벽에 한 NFD 수리(849fe3f)는 짐작이 틀려 안 나았다. 단서는 "남음 = NAS 안 붙음" 이 정확히 같다는 것이었다. 공유마다 첫 실패에서 죽은 꼴이다. 진단용 사본으로 첫 실패의 오류 코드·상위 폴더·붙었는지를 찍어 보니, 폴더째 옮겨진 카드 하나를 만나면 "상위 폴더도 없음 → NAS 끊김" 으로 쳐서 그 공유를 통째로 건너뛰고 있었다(매일 같은 3,915장째). 고친 뒤 6,000장 연습에서 채움 5,716 · NAS 안 붙음 0 이었다.

밤 채점(9/23 가동)은 하루(9/23)에 10문항에서 21문항으로 늘렸다. 알림은 새로 틀린 것에만 폰으로 한 번 보낸다. 매일 울리면 아무도 안 본다. 여기에 함정이 있었다. 카드 요약이 9/29 부터 매일 떨어져 있었는데, "새로 틀린 것만" 알려서 폰은 한 번 울렸거나 아예 안 울렸다. 며칠째 같은 ✗ 는 보고서를 거슬러 직접 봐야 보인다. 또 Firestore 429(그날 읽기 한도 참)는 실패가 아니라 "건너뜀" 으로 센다. 자는 자기가 못 쟀을 때와 물건이 고장 났을 때를 갈라야 한다.

스캔 PDF 배치(10/3 만듦, 매일 03:35 에 60분·1,500장)는 앞 2쪽만 맥 OCR(사진·스캔의 글자를 읽는 기술)로 읽고, OCR 글에 도면 표제란 낱말이 보이면 요약하지 않는다. 경로 거름은 이름만 봐서 이름이 평범한 도면이 요약으로 샐 뻔했다. 밤 채점은 이제 본문 색인(06:10)과 스캔 배치도 "돌았나" 본다. 조용히 멎으면 아무도 모르기 때문이다.

10 · 메일 라벨·수주 등록과 품질 주간보고 초안 (10/7)

브리핑이 "라벨 없는 새 공사번호 — Gmail 에서 직접 만들어 주세요" 를 9/28~10/7 사이 최소 8일 매일 올렸다. 업무 기록 조사에서 가장 먼저 자동화할 반복 일로 꼽혔다.

10/7 20:27 에 메일 스윕이 새 공사번호 라벨을 스스로 만들게 했다. 라벨 이름은 메일 제목에서 지어내지 않는다. 플랫폼 프로젝트 목록 → Drive 공사 폴더(하나일 때만) 순으로 찾아 기존 꼴 코드_업체_공사명 으로 만든다. 만들기 직전에 라벨 목록을 새로 받아 정말 없는지 다시 본다(셀프체크에 박았다). 라벨을 붙이면 받은편지함에서 뺀다. 처음엔 메일 한 통만 빼서 대화가 받은편지함에 그대로 남았다. 대화째 빼게 고쳤고, 지난 라벨 메일 대화 568개도 한 번에 뺐다.

20:41 에는 사내 수주통보서가 오면 플랫폼에 프로젝트까지 등록하게 했다. 등록 표식(woRegistry)을 먼저 만들고, 이미 있으면(409) 아무것도 쓰지 않는다. 공정 일정표(WBS)는 안 쓴다(7/17 WBS 덮어쓰기 사고 때문). 기존 문서는 고치지 않는다. 공사번호·업체·공사명 중 하나라도 확정 못 하면 지어내지 않고 보고로 내린다. 수주통보서는 실제 메일함에서 두 꼴이었다. 제목에 번호가 있는 꼴(HTML 만 있는 메일이라 앞 200자만 읽다 납기를 놓쳐 HTML 풀기를 더했다)과, 번호가 첨부 파일 이름에만 있는 꼴이다.

품질 주간보고 초안은 월요회의 통합 Weekly Project Report 의 품질 칸을 금요일 16:40 예약이 메일 초안으로 쓴다. 이 칸은 회의에서 사장단이 보는 칸이라 지어낸 줄이 나가면 안 된다. 그래서 초안은 메일로만 보내고, 근거 없는 줄은 "(확인 필요)" 로 둔다. 겪은 함정은 셋이다. 맥의 한글 파일 이름이 NFD 라 날짜 패턴이 안 맞았다. 도구 결과가 두뇌로 갈 때 12,000자에서 가운데가 잘린다. 첫 시범은 14,800자였고 두뇌가 같은 도구를 4번 부르느라 13분이 걸렸다. 10,500자 안으로 줄여 실측 7,200자가 됐다. 통합본에는 번호가 잘못 적힌 공사가 있어 업체명으로도 찾는다. 첫 정기 실행(10/9 금요일)은 아직 오지 않아 결과는 확인하지 못했다.

💡 설명

• 색인: 책 뒤의 찾아보기처럼, 자료를 빨리 찾게 미리 만들어 둔 목록.
• 카드: NAS 파일 하나를 설명한 작은 메모 파일(이름·경로·수정일·일부 요약).
• 뜻 검색 / 어휘 검색(BM25): 문장의 뜻이 비슷한 것을 찾는 방식 / 글자가 맞는 정도로 점수를 매기는 방식. 둘을 같이 쓰면 하이브리드다.
• RRF: 두 줄 순위를 점수가 아닌 등수로만 합치는 방법. 점수 눈금이 달라도 합칠 수 있다.
• MRR / 상위5: 정답이 몇 등에 나왔나를 평균 낸 점수(1등이면 1, 2등이면 0.5) / 정답이 5등 안에 든 비율.
• 1비트 해밍 미리거르기: 숫자 벡터를 0/1 부호만 남겨 빠르게 후보를 추린 뒤, 후보만 정확히 다시 재는 방법.
• 시험지(자): 답을 아는 질문 묶음. 검색을 고치기 전과 후에 같은 자로 재서 좋아졌는지 본다.
• 헛점수: 채점 규칙이 틀려서 실제보다 높게(또는 낮게) 나온 점수.
• 재순위 모델: 찾은 후보를 다른 모델이 다시 줄 세우는 방법. 여기서는 재 보니 나빠져 껐다.
• 로컬 LLM: 인터넷 밖으로 안 나가고 맥에서 도는 AI(gemma4). 도면은 이것만 읽는다.
• launchd: 맥이 정해진 시각에 프로그램을 돌려 주는 장치(윈도우의 작업 스케줄러와 비슷하다).
• 적대 검토: 일부러 구멍을 찾는 검토. 예약을 켜기 전에 돌려 위험을 미리 잡는다.

함정과 배운 것

• 점수가 움직이면 자부터 의심한다. 떨어졌을 때는 "예전 정답 조각" 의 본문을 열어 진짜 정답인지 본다. 올랐을 때도 본다.
• 자는 자기가 틀리기 쉽다. 정답을 우리 상식으로 한 곳에 박으면 틀린다(코드 이름 없이 물으면 답이 여럿이다). 판정 규칙의 빈틈은 헛점수를 낸다. 사본이 많은 곳에서는 "그 파일" 점수가 자가 아니다.
• 새 시험지만 보지 말고 옛 자를 같이 돌린다. 새 시험지에서 좋아 보이는 방법이 옛 문항에서 퇴보를 만들었다.
• 좋다는 방법도 우리 자료에서 재 본다. 재순위 모델, 로컬 모델 다시 매기기는 나빠졌다. 나빠지면 서버는 남기고 끈다.
• 점수는 시스템 경계를 넘는 값이다. 순위값으로 바꿨더니 쓰는 곳의 문턱이 결과를 통째로 버렸다. 바꾸기 전에 쓰는 곳을 전부 본다.
• 빠르게 만들기 전에 어디가 느린지 잰다. 병목은 CPU 가 아니라 디스크였다.
• LLM 에 읽히기 전에 데이터의 구조를 센다. 정보 상자 규칙은 장당 8초, LLM 은 2장에 999초(장당 약 500초)로 60배 넘게 차이 났다.
• 한도는 오류가 아니라 조용히 멈춘다. 50만 한도가 폴더를 막았고, 도면 밤 작업은 지워진 폴더의 카드 때문에 같은 자리에서 멈췄다. 한도에 걸리면 기록에 남기고, 멈춘 수가 "정확히 같은" 숫자면 한도를 의심한다.
• "새로 틀린 것만 알림" 은 며칠째 고장을 숨긴다. 며칠째 같은 ✗ 는 보고서로 직접 본다. 429 는 실패가 아니라 건너뜀이다.
• 맥의 한글 파일 이름은 NFD 다. 비교 전에 NFC 로 맞추고, 자르기·존재 확인·정규식을 모두 점검한다. 이 단계에서만 적어도 네 곳(카드 이름 자르기 · 원본 열기 · 밤 채점의 영수증 표본 열기 · 주간보고의 폴더 이름 정규식)에서 터졌다.
• 작업실 토큰 파일을 PowerShell ConvertFrom-Json 으로 읽지 않는다. 파싱 오류 메시지가 원문을 찍었다(10/2). 만료만 볼 때는 node 로 exp 만 꺼낸다.
• PC 작업 사본에서 git add -A 를 쓰지 않는다. 10/7 에 다른 세션의 작업 중 파일이 섞였다. 고친 파일만 올린다.
• 게이트웨이 배포는 wrangler deploy --config wrangler.toml 로 한다. --config 를 빼면 사이트가 대신 올라간다(10/1 에 또 겪었다).
• 오래 걸리는 일의 "끝나면 알림" 을 세션 예약에 맡기지 않는다. 연휴 내내 안 돌아 완료 메일이 사흘 늦었다. 일이 도는 쪽이 끝에 직접 알리게 한다.

출처

• making-ai 커밋(26개): 9012090 · 19b4082 · 03e912f · fa53978 · faa4441 · 93ea797 · b9d1828 · d424bcc · a93fa81 · 4ac1ca7 · 644f843 외 — 청사진 문서 청사진-회사AI-진단과-로드맵.md · README.md
• pais_project 커밋: 183019e · ce9ffe9 · d685bdc · 8824cad · 34b3ce5 · 11e6618 · 39131ad · dd4881b · 5580aa2 · 8f311bc · c5c15ad · fb04565 · a1395f5 · 5e852e2 · 1424ec0 · 4309d1d · 7ebef37 · 02bea7e · d62df09 · dba02ee · 0838c3f · 18d547a · 3f9f300 · 33fdb80 · 3701122 · 849fe3f · 1b18116 · c54c01f · d69e98a · bfc06e6 · bce40f8 · 782ba52 · 9c11c83 · 246c9ab · 1dd5659
• sejong-platform-v2 커밋: 8651851 · b6117b9 · 3764d3a · 48f07c8 · a180b82
• 기억 노트: making-ai-roadmap · rag-eval-lesson · one-bit-prefilter · card-summary-batch · nightly-eval · gmail-label-wo-register · quality-weekly-report

← 14 사무직 AI 작업실 — 직원마다 개인 비서 · 16 가르치기 — 발표와 강좌 →