# 문서 100건을 넣으면 무슨 일이 일어나나

> 이 한 장의 숫자는 `python -m noda.eval` 이 낸 점수판(`eval_results/latest.json`)에서
> 그대로 옮긴 것이다. `tests/test_brief_numbers.py` 가 줄마다 맞대므로
> **점수판과 다르면 시험이 떨어진다.** 잰 날: 2026-10-10 · 문서 1,488건

## 한 줄

**100건 중 68건은 원문을 안 열어도 됩니다.**
31건은 한 번 보셔야 하는데, **어느 31건인지 · 왜인지를 엔진이 먼저 말합니다.**
1건은 못 읽었고, **왜 못 읽었는지도 말합니다.**

세 번째 문장이 이 엔진의 값입니다. 68%는 누구나 말할 수 있지만
**「어느 31건인지 미리 짚어 준다」는 실패를 빠짐없이 신고해야만 할 수 있는 말**입니다.

## 문서 종류에 따라 크게 다릅니다

전체 평균 하나만 보시면 안 됩니다. **21%에서 95%까지 갈립니다.**

| 문서 종류 | 문서 수 | 원문 안 열어도 됨 |
|---|---:|---:|
| 기안·시행문 | 41 | **95.1%** |
| 보도자료 | 453 | 88.1% |
| 기타 | 334 | 72.8% |
| 규정·지침·법령안 | 67 | 59.7% |
| 업무 매뉴얼·안내서 | 37 | 40.5% |
| 계약서·서식 | 64 | 65.6% |
| 공고문 | 363 | 48.5% |
| 계획·보고서 | 82 | 53.7% |
| 포스터·홍보물 | 47 | 25.5% |

**이 「문서 종류」는 파일 이름으로 가늠한 값입니다.** 라벨이 아니라 이름에 든 낱말로
가릅니다(`공고`·`보도자료`·`포스터` 등). 사람이 붙인 이름이라 틀릴 수 있고, 실제로
**이름은 업무 문서인데 판면은 포스터인 경우**를 저희가 실측했습니다 — 스캔 문서 셋을
뽑아 보니 **셋 다** 그랬습니다. **종류별 숫자는 대략의 갈림으로 보셔야 합니다.**
특히 「기타」에는 여러 종류가 섞여 있습니다. **실제로 「기타」의 68%가 보도자료였습니다** — 이름에 「보도」가 한 글자도 없는 보도자료(`(부서명) 머리기사(9. 15. 11시부터).hwp` 꼴)를 저희가 못 가리고 있었고, 문서 안의 「보도시점」 머리표로 참값을 세워 바로잡았습니다.

**업무자동화에 쓰시는 기안·시행문이 가장 높습니다** — 다만 **표본 41건**입니다.
「이 종류가 잘 된다」가 아니라 「그 41건에서 잘 됐다」로 읽으셔야 합니다.

**포스터·홍보물이 가장 낮은 것은 그림이기 때문입니다.** 글자층이 없어
그림에서 글자를 읽어내야 하고, 그럴 때 엔진이 스스로 자신 없다고 말합니다.

## 파일 형식에 따라서도 크게 다릅니다

**위의 「문서 종류」는 파일 이름으로 가늠한 값이지만, 파일 형식은 가늠이 아닙니다** —
확장자가 아니라 **파일 안의 매직바이트로 확인한 사실**입니다. 그래서 이 표가 더
확실하고, **고객께서 실제로 던지시는 물음**이기도 합니다 — 「저희는 PDF 가 많은데요」.

| 파일 형식 | 문서 수 | 원문 안 열어도 됨 |
|---|---:|---:|
| pdf | 677 | 49.6% |
| hwpx | 572 | 84.6% |
| hwp | 178 | 80.9% |
| pptx | 16 | 87.5% |
| tif | 14 | 85.7% |
| docx | 10 | 90.0% |
| xlsx | 9 | 66.7% |
| jpg | 5 | 20.0% |
| png | 4 | 75.0% |

**가장 크게 갈리는 것은 PDF 와 한글입니다.** PDF 가 47.2%, 한글(hwpx)이 84.6% 입니다 —
**전체 평균 68%는 이 둘의 가운데**이지 어느 쪽의 값도 아닙니다. 까닭은 **PDF 에
스캔이 몰려 있기 때문**입니다. 글자층이 있는 PDF 는 잘 읽히고, 그림을 찍어 PDF 로
만든 문서는 엔진이 스스로 손을 듭니다.

**그러니 저희에게 주실 문서의 형식 비율을 먼저 알려 주시면, 68%가 아니라 그 비율에
맞는 숫자를 말씀드릴 수 있습니다.**

**워드·파워포인트·엑셀·스캔그림은 문서 수가 4~16건입니다** — 숫자가 높게 보이지만
**「그 열몇 건에서 그랬다」로 읽으셔야 합니다.**

## 「한 번 보셔야 한다」는 무슨 뜻인가

엔진이 **스스로 손을 든 문서**입니다. 까닭은 넷이 대부분입니다.

| 까닭 | 문서 수 | 무슨 뜻인가 |
|---|---:|---|
| 가로로 나란한 배치가 있다 | 233 | 다단·표·상자가 나란해 **표 격자**와 **문단 나눔**이 어긋날 수 있습니다. **읽는 차례와 글자는 맞습니다** — 같은 문서를 두 포맷으로 읽어 맞대면 차례는 한 짝도 안 어긋났습니다 (짝 24) |
| 서식이 화려한 문서다 | 229 | 글꼴에만 있는 글머리표를 쓴 문서입니다. **표 격자**가 틀렸을 수 있습니다 |
| 읽개 둘이 어긋났던 자리가 있다 | 19 | 한쪽으로 바로잡았지만 그 자리는 위험합니다 |
| 그림에서 읽은 글자가 흐리다 | 35 | 인식 확신이 낮습니다 |

**까닭마다 근거가 다릅니다** (W58). 같은 문서를 두 포맷으로 읽어 맞대면 그 까닭이
실제로 나쁜 자리를 가리키는지 확인할 수 있습니다 — 확인해 보니:

**아래 표의 문서 수는 그 확인을 한 날의 코퍼스입니다** (W58·W119 · 1,375건).
위 표와 몇 건 차이가 나는 것은 그 뒤 코퍼스가 늘었기 때문이고, **확인의 방향과
크기는 그때 잰 그대로 적습니다** — 다시 재지 않고 숫자만 고치면 거짓이 됩니다.

| 까닭 | 문서 수 | 짝으로 확인됐나 |
|---|---:|---|
| 가로로 나란한 배치가 있다 | 225 | **확인됨** — 표 격자 −0.71 · 문단 나눔 −0.38 (짝 25) |
| 서식이 화려한 문서다 | 221 | **확인됨** — 표 격자 −0.11 · 문단 나눔 −0.15 (짝 16) |
| 읽개 둘이 어긋났던 자리가 있다 | 19 | **반대 방향** — 오히려 더 잘 맞습니다 (짝 6 · 너무 작아 아직 못 믿습니다) |
| 그림에서 읽은 글자가 흐리다 | 26 | **확인됨** — 이 문서들의 글자 오차가 **2.6배**입니다 (0.44 대 0.17 · 라벨 45건). 맞댈 다른 포맷이 없어 정답 라벨로 쟀습니다 |

**문서 수로는 486/505(96%)가 확인된 까닭입니다.** 나머지 열아홉은 「읽개 둘이 어긋났던 자리」인데
짝이 여섯뿐이라 아직 못 믿습니다 — **「못 믿는다」는 「괜찮다」가 아니라 아직 재지 못했다는 뜻입니다.**
그리고 **읽는 차례는 네 까닭 모두에서 안 어긋났습니다.**

**「가로로 나란한 배치」는 스캔 문서에서도 같은 결론입니다** (W119). 위의 짝 25 는 글자층이
있는 문서만 잰 값이라, 그림을 읽은 문서(226건 중 **61건**)에는 닿지 않았습니다. 그쪽은
맞댈 다른 포맷이 없어 **정답 라벨로** 쟀습니다 (라벨 66건 · 붙은 38 · 안 붙은 28):
**표 격자는 −0.060 으로 무너지고, 읽는 차례는 −0.004 로 거의 같고, 글자는 오히려
0.013 더 정확합니다.** 곧 이 까닭은 **표를 보라는 말**이고, 스캔에서도 그렇습니다.
다만 표 격자 라벨이 **12 대 18** 이라 얇습니다 — 양쪽 20건을 넘기면 다시 재겠습니다.

이 표에 없는 까닭 다섯(표 모양을 확신하지 못했다 · 붙임을 못 찾았다 · 읽는 차례가 분명하지 않다 ·
수식으로 잘못 볼 수 있다 · 그림 읽기가 돌지 못했다)은 **코퍼스 1,366건에서 한 번도 안 나왔습니다** —
말은 준비해 두었지만 쓸 일이 없었다는 뜻입니다.


문서마다 **어느 까닭인지 · 어디인지**가 응답에 함께 나옵니다.
「어딘가 잘못됐을 수 있다」가 아니라 **「이 표가 의심스럽다」**로 나옵니다.
**다만 표 안을 인용할 때의 쪽 번호는 아래 「지금 못 하는 것」을 함께 보셔야 합니다.**

## 공문은 누가 누구에게 언제 보냈는지 읽습니다

공문 서식에 적힌 것 — **두문의 발신 기관과 수신 · 결문의 문서번호와 시행일 · 수신자 목록** — 을 문서가 적은
그대로 냅니다. 접수분류의 첫 열쇠입니다. **서식에 없으면 비워 둡니다** — 공고·보도자료에서 수신을 지어내지
않고, 기안문(내부결재)의 빈 시행일에 결재일을 옮겨 적지 않습니다. 경유·결재선은 내지 않습니다.

| 무엇을 쟀나 | 값 | 표본 |
|---|---:|---:|
| 발신 기관·문서번호·시행일을 맞췄나 | **0.934** | 67건 |
| 수신과 수신자 목록을 맞췄나 | **0.989** | 55건 |

표본의 절반 넘게가 **한 기관이 실제로 받은 시행문**(39건 · 스캔 셋 포함)입니다. 빈 몫은 거의 다 스캔입니다 —
글자 사이가 벌어져 읽힌 결문은 못 읽고, 수신자 목록은 열넷 중 열셋까지 읽습니다. 글자층 문서에서 틀린 것은
하이픈이 글자가 아닌 기호로 박힌 한 건뿐입니다.

## 이 68%를 믿어도 되나

**「엔진이 조용하다」가 실제로 「정확하다」와 같은 방향인지 확인했습니다.**
사람이 정답을 붙인 문서를 조용한 무리와 손든 무리로 갈라 비교했습니다.

| 무엇을 쟀나 | 손든 문서 | 조용한 문서 |
|---|---:|---:|
| 공문 구조(제목·조항·붙임)를 맞췄나 | 0.824 (70건) | **0.959** (117건) |
| 표를 원본과 같게 복원했나 | 0.853 (27건) | **0.939** (43건) |
| 읽는 차례가 맞았나 | 0.936 (11건) | **0.999** (35건) |
| 질문에 맞는 답을 냈나 | 0.832 (91건) | **0.911** (102건) |

**괄호 안이 그 값을 받친 문서 수입니다 — 값보다 그것을 먼저 보십시오.**
셋째 줄의 손든 쪽은 **열한 건**입니다 (W435 에서 셋 · W451 에서 둘을 더했다 — 법령안·공고문·한글 공고·세무조사 보도자료). 정답을 붙인 문서가 조용한 쪽에 쏠려 있어서이고,
**그 칸은 문서 하나가 들어올 때마다 크게 흔들립니다** (실제로 한 건을 더하자
0.873 → 0.905 → 0.924 → 0.936 으로 세 번 움직였습니다). 다른 세 줄은 27~102건이라 그만큼 단단합니다.

**반대로 간 지표가 하나도 없습니다.**

첫 줄의 차이가 벌어진 것은 **포스터 정답 셋을 새로 붙였기 때문**입니다 — 셋 다 엔진이 **손을 들었고**, 셋 다 틀렸습니다. 손든 쪽이 실제로 어려운 문서라는 뜻입니다. 조용한 쪽 첫 줄이 0.961 인 것은 **제목이 없는 문서에서 엔진이 손을 들지 않고 제목을 지어내기** 때문입니다 — 그 꼴을 이제 잽니다.

**다만 「조용하다」가 「맞았다」는 아닙니다.** 조용한 문서도 질문 정답률은
**0.908**입니다. 이 숫자는 **「사람이 확인할 문서를 골라 준다」**는 뜻이지
**「나머지는 완벽하다」**는 뜻이 아닙니다.

## 지금 못 하는 것 — 숨기지 않습니다

- **스캔 문서의 글자 오차가 목표에 못 미칩니다.** 목표 0.05 인데 실측 **0.186**입니다
  (표본 54). 오차의 가장 큰 몫은 글자를 못 알아본 것이 아니라 **읽는 차례**입니다
- **표 안을 인용할 때 쪽 번호가 자주 틀립니다.** 표 안의 글자는 그 표가 **시작한
  쪽**을 댑니다 — 열 쪽짜리 표의 아래쪽 행도 첫 쪽을 가리킵니다.
  같은 문서의 PDF 판과 맞대 보니 **표 글자 1,417개 중 쪽이 맞은 것은 539개(38%)**
  입니다(본문 글자는 **93%**). **한 쪽보다 긴 표가 있는 문서에서는 17.5%**입니다.
  그런 문서는 엔진이 신고하지만, 위 「한 번 보셔야 한다」에는 **안 넣었습니다** —
  **글자와 표는 멀쩡하고 쪽 번호만 틀리기 때문**입니다. 인용을 눌러 원문 위치로
  가는 기능을 쓰실 계획이면 **이 점을 먼저 확인하셔야 합니다**
- **워드(.docx)는 표본이 얇습니다.** 공공 문서 붙임 1,792개 중 `.docx` 가 **2개**뿐이라, 한 기관이
  빌려준 업무 문서 여덟으로 처음 쟀고 그중 넷에 정답을 붙였습니다 — 넷 다 글자째 맞았지만 **둘을 재다가
  계약 위반을 하나씩 찾아 고쳤습니다**. **「읽는다」와 「재 봤다」는 다른 말**이고 여덟은 아직 「그 여덟에서 그랬다」입니다
- **못 읽는 형식이 있습니다** — 오즈리포트(.ozd).
  **읽는 척하지 않고 「이 형식은 못 읽는다」고 신고합니다**

## 문서가 이 기계 밖으로 나가나 — **엔진은 안 나갑니다**

엔진은 네트워크를 쓰지 않습니다. 읽기·조각내기·검색·발췌 답변이 **전부 이 기계**
안에서 끝나고, DB 도 외부 서비스도 없습니다. 폐쇄망에 그대로 둘 수 있습니다.

**이것은 설계 설명이 아니라 실측입니다** (2026-10-09 · `docs/install.md`):

| 무엇을 했나 | 결과 |
|---|---|
| 깨끗한 기계에 설치 | `parse,ocr` 로 **41 패키지 · 361MB** · 저장소 밖 폴더에서 바로 돌았습니다 |
| **인덱스 없이** 설치 (폐쇄망) | 휠 **39개 · 117MB** 를 들고 가 `--no-index` 로 깔고 문서를 읽었습니다 |
| 스캔 읽기에 필요한 모델 | **18.9MB** 세 파일을 꺼내 담아 가리킵니다 (뜻 검색 모델 118MB 는 선택) |
| **바깥을 막고 돌림** | 인터넷 경로를 죽은 주소로 막고 스캔 PDF 를 읽혔습니다 — **밖으로 나간 흔적 0 줄** |

**반대쪽도 재서 적습니다** — 모델 경로를 **셋 다 주지 않으면** 엔진이 쓰는 인식 모델을
**받으러 나갑니다.** 그래서 폐쇄망 설치 안내가 「셋 다 주십시오」로 못 박혀 있습니다.
저희가 그 사실을 숨기지 않는 까닭은, 그것을 모르고 설치하면 **반입 심의를 지난 망에서
조용히 실패**하기 때문입니다.

**딱 하나 예외가 있고 그것은 끄고 켭니다.** 답을 한 문장으로 다듬는 `LLM` 기능을
켜면 **인용할 대목이 LLM 제공자에게 그대로 갑니다.** 기본은 꺼짐입니다.

- 어디로 가는지 **화면과 `GET /health` 가 켜기 전에 말합니다** —
  「켜면 문서 글이 밖으로 나갑니다 — api.openai.com」
- **사내 모델로 돌리면 아무것도 안 나갑니다.** 주소 하나만 바꾸면 되고
  (vLLM·Ollama·LM Studio), 그때 화면은 「밖으로 안 나갑니다」라고 적습니다
- 키는 **환경변수에서만** 읽고 어디에도 내보내지 않습니다


## 이 숫자는 어디서 나왔나

문서 **1,488건**입니다. 둘로 나뉩니다 —

- **공개된 정부 문서 1,374건** — 정책브리핑 · 기업마당 · 정보공개포털 ·
  국민참여입법센터 · 공정거래위원회 · 나라장터.
- **기관이 빌려주신 업무 문서 103건** — 한 기관이 2026-10-06 에 64건, 2026-10-10 에 시행문 39건을 주신 것입니다.
  업무 문서는 공개 자료에 거의 안 나오는 꼴을 가져왔습니다 — 스캔 공문(TIF) ·
  발표자료(PPTX) · 워드. **아직 한 기관의 것뿐입니다.**
  처음 들인 81건에서 **개인 자료가 든 열여섯**(이력서 · 개인정보 동의서 ·
  심사 평가표 · 얼굴이 알아볼 수 있는 사진)을 **다음 날 도로 걷어냈습니다.**
  저희가 그것을 놓쳤던 까닭과 다시 안 놓치려고 무엇을 만들었는지는
  `docs/pilot.md` 에 적어 두었습니다.
- 그 밖에 **저희가 만든 시험용 파일 9건** — 「못 여는 파일을 못 열었다고 말하는가」를
  재려고 일부러 깨뜨린 것들입니다.

**고객님 문서의 숫자는 다를 것입니다.** 위 표에서 보시듯 종류에 따라
21%에서 95%까지 갈리고, 저희 코퍼스는 보도자료가 33%입니다.

**실제 폴더에서 한 번 쟀습니다** (2026-10-11 · 한 기관의 업무 폴더 그대로 · 묶음 20개를 풀어 문서 1,642건 · 277분):
원문을 안 열어도 되는 것 **49.2%** · 한 번 보셔야 하는 것 42.6% · 못 읽은 것 8.2%(바로가기·썸네일처럼 문서가 아닌 것)였습니다.
위의 68%보다 낮은 까닭은 **스캔이 623건**이라 「그림에서 읽은 글자가 흐리다」와 「가로로 나란한 배치」가 손을 많이 들었기
때문입니다. 같은 폴더의 공문 61건에서는 발신 기관 78.7% · 문서번호 67.2% · 시행일 65.6% · 수신자 목록 100%를 읽었고,
그 기관의 제 기안 서식 759건은 처음에 두문을 못 보다가 서식을 배워 읽게 되었습니다. **이 숫자는 그 폴더의 것**이고
저희 점수판에는 들어 있지 않습니다 — 받은 문서는 기한에 지우므로 한 번의 증언입니다.
**고객님 문서 100건이면 그 100건으로 같은 숫자를 다시 냅니다** — 라벨 없이
반나절이면 나옵니다.

**계산 자체는 오래 걸리지 않습니다.** 실측(2026-09-30 · 노트북 한 대 · 캐시 없이):

```
문서 100건 · 27 MB · 스캔 10%   →  1.1분
  스캔   10건이 시간의 59%       (한 건 평균 4.1초)
  글자층 90건이 41%             (한 건 평균 0.31초)
```

**시간을 먹는 것은 스캔입니다** — 글자층 문서보다 13배 걸립니다. 문서가 전부 스캔이어도
100건에 십여 분입니다. 「반나절」의 대부분은 **받아서 정리해 드리는 시간**입니다.
(아주 큰 문서 하나가 오래 걸릴 수 있습니다 — 가로 72인치 브로슈어 한 건이 3분 걸린 적이 있습니다.)

**이 숫자도 고객님 문서로 다시 냅니다.** 위 표의 비율과 같은 자리에서 나옵니다 —
`tools/customer_report.py` 가 **읽는 데 걸린 시간**을 스캔·글자층으로 갈라 함께 찍습니다.
위 값은 저희 코퍼스의 것이고, **고객님 문서의 참값은 그때 나옵니다.**

> 앞서 적었던 1.7분은 **다른 표본(54 MB)**의 값이고, 같은 표본으로 견주면
> **100초 → 68초**입니다 — 칠한 면을 잔선 수백 개로 그린 PDF 에서 표 격자를 찾느라
> 5쪽짜리 한 건이 22초를 먹고 있었습니다 (지금 4.5초). **읽어 내는 글자는 그대로입니다.**