위키가 영어로 쓰여 있었다 — 4,382개 중 482개

1부의 마지막 편이다. 앞 세 편에서 세컨드브레인을 LLM-Wiki 패턴으로 시작하고, 문서 2만 개를 만나 벡터 검색 계층을 얹고, 온갖 파일 포맷에서 텍스트를 꺼내는 이야기를 썼다.

 

이 편은, 그렇게 만든 위키를 열어봤을 때 생긴 일이다. 2주쯤 지나 브라우징 화면을 붙였고, 페이지를 넘겨보다가 이상한 걸 발견했다. 일부 페이지가 영어로 쓰여 있었다.

 

내 자료는 거의 전부 한국어인데, 합성된 페이지가 영어라니, 아무도 부탁하지 않은 번역이다. 왜 그랬는지부터 보자.

 

 

원인은 금방 찾았는데, 프롬프트를 열어보니 ingest 시 LLM 에 주는 시스템 프롬프트에 한국어로 작성 지시가 이미 있었다. 지금 규칙은 맞고, 영어 페이지는 초기 버전의 잔재다. 처음엔 프롬프트가 영어였고, 모델이 영어로 답했는데, 나중에 한국어 지시로 고쳤지만 이미 만들어진 페이지에는 아무 일도 일어나지 않았다.

 

---

두 번의 청소

먼저 영어 페이지를 찾아야 했는데, 판정 기준은 단순하게 잡았다. 본문에서 한글이 차지하는 비율이 0.10 미만이면 영어 페이지다. 한국어 문서는 영어 용어가 섞여도 0.10 은 넘고, 영어 페이지는 고유명사 말고는 한글이 없어서, 임계값 하나로 갈렸다.

 

이 기준으로 센 결과, 4,382개 중 482개가 영어였다.

 

처리 방식은 재합성이었다. 옛 페이지를 지우고, 매니페스트에서 해시를 제거해서 안 한 것으로 되돌리고, 다시 ingest 를 돌리면 지금의 한국어 프롬프트로 새로 합성된다. 문서당 70초, 482개면 8~10시간이다.

 

스크립트에 두 가지를 넣었다. 터미널을 닫아도 계속 도는 detached 실행, 중단되면 남은 것부터 이어가는 재개 로직. 둘째는 선택이 아니라 필수인데, 8시간 배치는 반드시 끊기고, 재개가 없으면 처음부터라서 영원히 안 끝난다.

 

돌렸다. 로그가 남았다. 몇 개가 처리됐는지 적어둔 곳은 없다.

 

이틀 뒤 다시 셌더니, 숫자가 안 맞았다.

 

매니페스트 기준 처리 대상    4,382개
실제 디스크의 위키 .md      6,809개
────────────────────────────────
1차가 아예 보지 않은 페이지  2,427개
여전히 영어인 페이지          233개

 

재합성 대상 목록과 실제 산출물이 일치하지 않았다. 1차 스크립트는 매니페스트를 순회했는데, 매니페스트는 처리 기록이라 처리된 것만 알고, 디스크에는 연결되지 않은 페이지가 2,400개 넘게 있었다. 확실한 건, 매니페스트를 순회하면 위키 전체를 순회하지 않는다는 것.

 

그래서 2차는 접근을 바꿔, 파일시스템을 직접 순회했다. 모든 .md 를 열어 한글 비율을 재고 0.10 미만이면 처리한다. 매니페스트는 안 본다.

 

그리고 재합성 대신 제자리 번역을 골랐다. 영어 페이지 본문을 번역해서 덮어쓰는 방식인데, 이유는 두 개다. 재합성은 문서당 70초고 번역은 그보다 싸서, 예상 2~3시간이었다. 그리고 재합성하면 내용이 또 달라지는데, 이미 링크가 걸려 있고 손으로 고친 것도 있어서 그걸 전부 날릴 수 없었다.

 

번역이라서 지켜야 할 게 늘었다. 프론트매터와 위키링크와 약어는 건드리면 안 되는데, 링크를 번역하면 그래프가 끊기고 약어를 풀면 검색이 안 걸린다. 그래서 프롬프트로 그 셋을 보존하게 묶고, 한자 가드를 얹었다. 로컬 모델이 한국어를 만들면서 한자와 CJK 문자를 섞는 경우가 있었는데, 한자가 들어오면 그 페이지는 실패로 처리하게 했다.

 

---

곁가지 — 목차도 같이 무너져 있었다

같은 시기, 위키 색인 페이지도 이상했다. index.md 에 항목이 9,532개, 죽은 링크가 422개 이상이었다. 한 페이지에 9,500개가 나열돼 있으면, 그건 목차가 아니다.

 

태그와 제목 키워드로 상위 카테고리 10개에 분류하는 색인 재생성 스크립트를 새벽마다 돌렸다. 그 분포에서 두 가지가 보였는데, 의료영상·AI연구 1,553개가 제일 큰 건 예상대로였고, 기타가 1,150개였다. 자동 분류의 정직한 성적표다. 그리고 행정 937 + 과제 581 = 1,518개, 위키 5분의 1이 공문과 과제 서류였다. 색인에 뭐가 들어 있는지가 검색 품질을 정한다는 걸, 이때는 아직 몰랐다.

 

 

---

한 달 뒤 — 오염원을 끄는 게 나았다

이 이야기의 중간 결말은, 청소가 성공했다는 게 아니다. 한 달 뒤 재설계할 때 위키를 다시 봤더니, 다국어 오염이 여전했다. 영어만이 아니었다. 러시아어 조각(отсут), 일본어 조각(挙げ), 그리고 파 mesenchymal 처럼 한 단어 안에서 언어가 섞인 것들까지 있었다.

 

오염원을 찾았더니, 매시간 도는 재합성 크론이었다. 소스가 조금이라도 바뀌면 LLM 이 페이지를 다시 쓰는데, 그때마다 오염이 새로 생길 확률이 있었다. 청소한 만큼 다시 오염되고 있었다.

 

그래서 결정을 바꿔, 위키를 청소하는 대신 동결했다. 매시간 재합성 크론과 매일 다이제스트 합성을 꺼, 위키를 읽기전용 유물로 남겼다. 근거는 앞 편에서 확인한 사실이었다 — 검색 백본은 위키가 아니라 원본 소스 임베딩이고, 위키는 소스의 파생물이다. 계속 오염되는 파이프라인에서는, 청소가 아니라 정지가 답일 수 있다. 청소 스크립트를 두 번 만들고 나서야 그 판단을 했다.

 

---

그래서 끝났나 — 세어봤다

이 글을 '그래서 다 고쳤다'로 마무리하려다 멈췄다. 확인하려고 당시 기록을 다시 열었는데, 완료 기록이 없다. 실행 방법, 예상 소요, 재개 방법은 적어뒀고, 몇 개가 처리되고 몇 개가 남았는지는 어디에도 없다. 배치를 걸고 그걸로 끝냈던 것이다.

 

그래서 지금, 동결된 위키 아카이브를 같은 판정법으로 전수 조사했다.

 

위키 페이지          7,008개
영어 판정             72개  (1.0%)
  ├ 제목까지 영어     28개
  └ 제목은 한국어     44개
전원 파일 수정시각    2026-06

 

6월에 233개였던 것이 72개다. 72개 전원의 수정시각이 6월이라는 게, 동결이 유효했다는 증거다. 위키는 정말 안 움직이고 있다.

 

그런데 이 72개를 열어보고 알았다 — 남은 것들은 고칠 대상이 아니었다.

 

제목까지 영어인 28개는, Morphology-guided attention networks for explainable... 처럼 원문이 영어인 논문 전문이었다. 제일 큰 건 62,499자, 파일명이 arXiv id 인 페이지도 12,929자였다. 내 논문 전문을 소화시키는 파이프라인이 따로 넣은 것이다. 이걸 한국어로 번역하는 건 개선이 아니라 훼손이다 — 원문을 그대로 인용할 수 없게 된다.

 

 

제목이 한국어인 44개는 더 흥미롭다. 어떤 학사 안내 문서의 한글 비율이 0.099 였는데, 임계값이 0.10 이니 0.001 차이로 영어 페이지가 됐다. 본문에 학번과 코드와 표가 빼곡해서, 숫자와 기호가 한글을 밀어낸 것이다. 멀쩡한 한국어 문서다.

 

정리하면 문제였던 페이지는 사실상 정리됐고, 남은 72개는 정상 문서 44개와 번역하면 안 되는 영어 원문 28개다. 다만 이건 완료 보고가 아니라, 두 달 뒤에 뒤늦게 센 숫자다.

 

---

교훈 세 개

하나는, 규칙을 고쳤다는 것과 데이터가 규칙을 따르게 됐다는 것이 다른 문장이라는 것. 프롬프트를 한국어로 고친 시점에 나는 해결했다고 생각했는데, 코드는 옳았고 그 뒤 페이지들은 전부 한국어였다. 시스템의 상태는 코드가 아니라 축적된 데이터라, 규칙 변경은 그 시점 이후에만 적용되고 이미 쌓인 것에는 아무 일도 하지 않는다. 규칙을 바꿀 때는 새 규칙, 쌓인 데이터를 맞추는 일회성 소급 작업, 끝났는지 확인하는 검증 쿼리가 세트로 필요하다. 검증이 없으면 1차에서 멈춘다.

 

둘은, 소급 대상 목록을 어디서 뽑는지가 소급의 정확도를 정한다는 것. 나는 매니페스트에서 뽑았는데, 처리 기록이라 처리된 것만 안다. 실제로 존재하는 것을 알려면 파일시스템을 봐야 했다. 기록과 실물이 어긋나 있을 가능성을 아예 고려하지 않은 게 실수였고, 그 어긋남을 1차가 끝난 다음에야 발견한 게 더 큰 실수였다. 검증 쿼리가 있었으면, 1차와 2차 사이에 이틀이 안 걸렸을 것이다.

 

셋은, 완료를 판정하던 지표가 그 자체로 오탐을 냈다는 것. 한글 비율 0.10 은 영어 페이지를 찾는 데는 잘 작동했고, 482개를 찾아냈는데 대부분 진짜였다. 문제는 같은 지표를 작업이 끝났는지 확인하는 데 쓸 때 생기는데, 원문이 영어인 논문 전문은 영원히 걸리고 표와 코드가 많은 한국어 문서는 0.099 로 걸린다 — 고쳐도 안 사라지는 것과, 문제가 아닌데 걸리는 것.

 

점검 지표가 오탐을 내면 그 지표로는 완료를 선언할 수 없다. 그리고 완료를 선언할 수 없으면 사람은 확인을 그만둔다.

 

 

그러니까 이 지표로는 0을 목표로 삼을 수 없다. 그런데 나는 영어 페이지가 없어지면 끝이라고 생각했는데, 목표가 도달 불가능한 형태였고 그래서 완료 판정을 아예 안 하게 됐다. 배치를 걸고 잊은 이유가 게으름만은 아니었다는 얘기다.

 

지표를 고쳤어야 했다. 논문 전문 디렉터리를 판정에서 제외하고, 한글 비율 대신 영문 문장 비율을 보고, 임계값 근처인 0.08~0.12 는 사람 검토 큐로 보내는 식이다. 그러면 0이면 끝이 성립한다.

 

이게 이 시리즈가 계속 부딪히는 문제의 1부 버전이다. 5부에서 같은 모양을 훨씬 큰 규모로 다시 만난다 — 적어둔 것과 실제가 어긋나 있는데, 그걸 확인하는 장치가 그 자체로 고장나 있다.

 

---

이걸로 1부를 마친다. 여기까지가 2026년 6월 초순, 시스템을 만든 첫 3주다. 2부에서는 자료가 끊기지 않고 흘러들게 만드는 이야기를 한다. 회의록 자동 녹음과 전사, 그룹웨어 스크래핑, 논문 리캡 — 자동화 8개를 붙였고, 그중 몇 개는 아주 이상한 방식으로 실패했다. 그 이야기는 2부에서 해 보자.