컴퓨터 125대로 3만4천권의 책을 OCR한 이야기 : 비개발자의 스토리

처음부터 거창한 분산 시스템을 만들 생각은 없었습니다.

제가 가지고 있는 디지털 문서들을 AI가 제대로 읽을 수 있게 만들고 싶었습니다.

PDF는 이미 많이 가지고 있었습니다. 그런데 막상 LLM에 넣어보니 문제가 있었습니다.

겉으로 보기에는 멀쩡한 PDF이고 OCR도 되어 있는 것 같은데, AI에게는 별로 쓸모가 없는 문서가 많았습니다.

텍스트가 이상하게 깨져 있거나, 문단 순서가 뒤섞여 있거나, 검색이 제대로 안 되거나, 사람이 보는 내용과 AI가 읽어낸 내용이 다른 경우도 있었습니다.

그래서 생각했습니다.

"그냥 전부 다시 OCR하면 되지 않을까?"

문제는 그다음부터였습니다.

컴퓨터 한 대로는 안 되는 일이었다

처음에는 당연히 제 컴퓨터에서 돌리려고 했습니다. 요즘 로컬 AI 이야기가 많으니까요.

그런데 수십 페이지가 아니라 수백만 페이지를 처리하려고 하니 완전히 다른 문제가 됐습니다. 현재까지 처리한 양만 누적 406만 페이지입니다.

좋은 GPU에서는 잘 돌아가지만 저사양 컴퓨터에서는 속도가 급격하게 느려집니다. 직접 테스트해보니 GTX 950 2GB에서는 한 페이지에 약 36초가 걸렸고, GTX 750 1GB에서는 한 권도 제대로 끝내지 못했습니다.

여기서 몇 번 좌절했습니다.

"역시 로컬 AI는 좋은 GPU가 있어야 하는 건가?" "이 정도 데이터를 처리하려면 결국 클라우드 비용을 내야 하나?" "내 컴퓨터 성능으로는 안 되는 프로젝트인가?"

처음에는 계속 컴퓨터 한 대의 성능을 고민했습니다. 더 좋은 GPU를 사야 하나. 맥을 더 좋은 것으로 바꿔야 하나. 클라우드 GPU를 빌려야 하나.

질문을 바꾸자 방향이 달라졌다

그런데 어느 순간 질문을 바꿨습니다. 여기서 프로젝트 방향이 완전히 달라졌습니다.

한 컴퓨터가 4만 권을 처리할 필요가 없었습니다.

컴퓨터 A는 1번 문서. 컴퓨터 B는 2번 문서. 컴퓨터 C는 3번 문서. 각자 다른 문서를 처리하면 됩니다.

그렇다면 컴퓨터 한 대의 절대적인 성능보다 동시에 몇 대가 일할 수 있는가가 더 중요해집니다.

그래서 프로젝트에 함께할 사람들을 모집하기 시작했습니다. 좋은 GPU를 가진 사람만 모집한 것도 아닙니다. 맥도 있고 윈도우도 있습니다. RTX 4090도 있고, 8GB 맥북에어도 있습니다.

각자 컴퓨터를 사용하지 않는 시간에 작업 하나를 받아 OCR을 돌리고 결과를 보내는 방식입니다. 그렇게 하나둘 연결하다 보니 지금은 125대가 됐습니다.

핵심 기술은 OCR 모델이 아니라 네트워킹이었다

이 프로젝트에서 의외였던 부분입니다.

처음에는 어떤 OCR 모델을 쓸지가 가장 중요하다고 생각했습니다. 그런데 실제 규모가 커지고 나니 핵심 기술은 모델만이 아니었습니다. Tailscale과 네트워킹이었습니다.

컴퓨터 125대가 한 장소에 있는 게 아닙니다. 서로 다른 장소에 있고, 인터넷 환경도 다르고, 맥과 윈도우가 섞여 있습니다. 이 컴퓨터들을 Tailscale로 하나의 네트워크처럼 묶었습니다.

그리고 구조를 단순하게 만들었습니다.

마스터 서버 → 작업 배정 → 참여자 컴퓨터 → 로컬 OCR → 결과 반환

마스터가 할 일을 나눠줍니다. 참여자의 컴퓨터는 하나를 받아 자기 컴퓨터에서 처리합니다. 끝나면 결과를 서버로 돌려줍니다. 그리고 다음 작업을 받습니다.

결국 제가 해결한 문제는 "어떻게 더 강력한 AI 컴퓨터를 살 것인가?"가 아니었습니다. **"이미 존재하는 컴퓨터들을 어떻게 하나의 시스템처럼 일하게 만들 것인가?"**였습니다.

로컬 AI의 성능 한계를 하드웨어 구매가 아니라 분산으로 풀어본 것입니다.

지금의 시스템

처음에는 제 컴퓨터 한 대에서 OCR을 돌렸습니다. 지금은 맥과 윈도우 125대가 인터넷으로 작업을 나눠 처리합니다.

개발자가 아닌 사람이 125대를 운영하는 법

여기서 또 문제가 생겼습니다. 저는 개발자가 아닙니다.

컴퓨터가 125대가 되면 당연히 사고가 납니다. 한 대가 연결이 안 되고, 어떤 컴퓨터는 업로드가 안 되고, 대시보드가 멈추고, Windows 트레이 표시가 실제 상태와 다르고, NAS가 이상해지고, DB가 느려지고, 멀쩡히 일하는 컴퓨터가 갑자기 오프라인으로 표시됩니다.

저 혼자 이걸 디버깅할 수 없습니다. 그래서 서버 운영과 디버깅 자체를 Claude Code와 같이 하기 시작했습니다.

제가 하는 일은 의외로 단순합니다. 증상을 말합니다. 실제로 입력한 프롬프트도 이 정도였습니다.

워커들 마스터로 업로드 잘 되고 있나? 아직 안되는것 같은데 즉시 고쳐라 마스터 연결상태 확인 및 작업현황판 작동안됨 확인 실시간에서는 일하는 중인데 트레이가 가끔 제대로 표기 못하는 경우 발생

저는 원인을 모릅니다. 대신 Claude Code가 서버에 들어가 로그를 보고, 코드를 찾고, 원인을 검증하고, 수정하고, 테스트하고, 배포합니다.

지난 한 주 동안 그렇게 16개 커밋, 장애 7건을 해결했습니다. 그중 몇 가지가 꽤 재미있었습니다.

장애 1. 업로드는 되고 있었다, 엉뚱한 곳으로

제가 보기에는 업로드가 안 되는 것 같았습니다. 그런데 로그를 조사한 Claude의 결론은 달랐습니다. 업로드가 안 된 게 아니라 엉뚱한 곳으로 업로드되고 있었습니다.

NAS 연결이 끊겼는데 원래 NAS가 있어야 할 경로에 평범한 로컬 폴더가 생겨 있었습니다.

프로그램 입장에서는 폴더가 존재합니다. 파일도 쓸 수 있습니다. 그러니 "업로드 성공"이라고 판단했습니다. 하지만 실제 NAS에는 아무것도 없었습니다.

그렇게 약 3.1GB가 로컬 디스크로 들어갔고, 당시 함대 84대 중 73대가 새 작업을 받지 못하고 있었습니다.

여기서 배운 게 하나 있습니다. 폴더가 있다고 해서 내가 생각하는 저장장치가 있다는 뜻은 아니다.

그래서 이제는 파일을 받기 전에 실제 NAS인지 확인합니다. NAS가 없으면 임시 저장소를 확인합니다. 그것도 없으면 아예 파일을 받지 않습니다.

완성된 결과를 워커가 가지고 기다리는 것이, 저장하지도 않았는데 "성공했습니다"라고 말하는 것보다 낫기 때문입니다.

장애 2. 대시보드를 19초 동안 멈춰 세운 쿼리 하나

어느 날 작업현황판이 열리지 않았습니다. 8초 타임아웃. CPU는 574%.

처음 발견한 것은 DB 연결 누수였습니다. 열린 DB 연결이 580개까지 늘어나 있었습니다. 코드 33군데에 같은 패턴이 있었습니다. 하나씩 고치는 대신 DB 연결 클래스를 하나 수정해서 전부 해결했습니다.

• DB 연결: 580개 → 26개
• DB WAL 파일: 59MB → 254KB

그런데 이상했습니다. 그래도 대시보드는 느렸습니다.

그래서 Claude가 대시보드에서 실행되는 DB 쿼리를 하나씩 측정했습니다. 대부분 몇 ms. 그런데 하나가 18,774ms, 약 19초였습니다.

완료된 작업과 작업기록을 비교하는 쿼리에 인덱스가 없어서 사실상 수억 개의 행을 계속 비교하고 있었습니다. 인덱스 두 개를 추가했습니다.

• 해당 쿼리: 18,774ms → 0ms
• 대시보드는 다시 약 1초 만에 열렸습니다.

이 사건에서 배운 것도 단순합니다. "느리다"를 보지 말고 무엇이 몇 ms 걸리는지 측정해야 합니다.

장애 3. 워커가 죽은 게 아니라 마스터가 바빴다

처음에는 Windows 문제라고 생각했습니다. Windows에서 트레이 표시가 이상했고, 업로드할 때 오프라인으로 보이는 현상을 발견했기 때문입니다.

그런데 Claude가 로그를 통계로 돌렸습니다.

• 20초가 넘는 하트비트 공백: 15,086회
• 5대 이상이 같은 분에 동시에 끊긴 경우: 233분
• 그중 서버가 결과물을 받는 시간과 겹친 경우: 225분(96%)

결론은 완전히 달랐습니다. 워커들이 죽은 게 아니라 마스터가 바빠서 응답하지 못하고 있었습니다.

더 재미있는 것은 제가 Windows 문제라고 생각했던 것도 틀렸다는 겁니다. 끊김률은 Windows 0.18%, Mac 0.20%로 거의 같았습니다. 제가 Windows에서 먼저 발견했을 뿐입니다.

이후부터 문제가 생기면 반드시 이것부터 봅니다.

"한 대에서 일어났나, 여러 대에서 동시에 일어났나?"

한 대만 이상하면 그 컴퓨터를 의심합니다. 그런데 서로 다른 장소에 있는 여러 컴퓨터가 같은 순간에 이상해진다면 이야기가 달라집니다. 공통으로 연결된 서버나 네트워크부터 봐야 합니다.

실제로 이 질문 하나로 "워커 문제"라고 생각했던 장애를 세 번이나 "마스터 문제"로 뒤집었습니다. 바이브 코딩으로 분산 시스템을 만든다면 이건 꽤 유용한 디버깅 기준이라고 생각합니다.

AI와 함께 서버를 운영하며 정한 규칙

추측을 빼고 증상만 준다. "NAS 때문에 업로드가 안 되는 것 같다"보다 "업로드가 안 되는 것 같다. 확인해줘."라고 했습니다. 증상을 주고 AI가 로그와 실제 상태를 확인하게 했습니다. 제 추측이 틀린 경우가 꽤 많았기 때문입니다.

숫자에는 이유를 같이 적는다. 단순히 OFFLINE_AFTER = 90이라고 적지 않습니다. 왜 90초인지 같이 적습니다. 실측 날짜, 하트비트 주기, 실제 장애 횟수, 동시에 몇 대가 끊겼는지, 그때 서버가 무엇을 하고 있었는지. 이걸 주석에 남깁니다.

그래야 한 달 뒤 다른 AI 세션이 와도 "왜 90이지? 20으로 줄이면 더 빠르겠네" 하고 과거의 장애를 다시 만드는 일을 줄일 수 있습니다.

사고를 기억 파일에 남긴다. 프로젝트별 기억 파일을 만들었습니다. 사고가 나면 증상, 실제 원인, 판별 방법, 복구 순서, 하면 안 되는 것, 그리고 Claude가 잘못 판단했던 내용까지 기록합니다.

AI가 실수했던 것도 지우지 않습니다. 다음 세션의 AI가 같은 실수를 하지 않게 하기 위해서입니다.

보고보다 실제 상태를 믿는다. Claude가 저를 정정할 때도 있고, 제가 Claude를 정정할 때도 있었습니다. 한 번은 Claude가 "배포가 안 됐다"고 했는데 실제 서버와 비교해보니 이미 배포되어 있었습니다. 다시 확인시키자 "앞서 말한 것은 틀렸다"고 정정했습니다.

그래서 중요한 작업에서는 보고를 믿는 것보다 실제 파일, 프로세스, 로그, DB를 다시 확인하게 합니다.

배포 전 검사를 신뢰한다. AI가 코드를 잘 작성하는 것과, 현재 파일이 안전하게 배포 가능한 상태인 것은 다른 문제였습니다. 실제로 배포 직전 문법 검사에서 코드가 깨져 있는 것을 발견한 적이 있습니다. 다른 세션이 같은 파일을 편집하고 있었기 때문입니다. 그대로 배포했다면 마스터가 죽었을 겁니다.

지금은 AI의 자신감보다 배포 전 검사를 신뢰합니다.

결국 질문 자체가 틀렸던 것이다

이 프로젝트에서 꼭 나누고 싶은 대목입니다.

저도 처음에는 계속 **"내 컴퓨터 성능이 부족하다"**고 생각했습니다. 로컬 AI 모델을 돌려보고 느리면 좌절했습니다. VRAM이 부족하면 포기해야 하나 생각했습니다. 클라우드 비용을 계산하다가 규모를 줄여야 하나 고민했습니다.

그런데 지금 돌아보면 질문 자체가 잘못되어 있었습니다.

"내 컴퓨터가 이 일을 할 수 있는가?"가 아니라 "이 일을 여러 컴퓨터가 나눠서 할 수 있는가?"를 물었어야 했습니다.

한 대의 성능이 부족하다는 것이 프로젝트 전체가 불가능하다는 뜻은 아니었습니다.

작업을 충분히 작게 나누고, 네트워크로 연결하고, 마스터가 배분하고, 각자의 컴퓨터가 하나씩 처리하고, 완료된 결과를 다시 모으면 됩니다.

저에게 불가능을 가능하게 만든 아이디어는 더 좋은 AI 모델이 아니라 Tailscale과 네트워킹을 이용한 업무 분산이었습니다.

AI 시대라고 해서 모든 문제의 답이 더 큰 AI 모델이나 더 비싼 GPU일 필요는 없었습니다. 때로는 문제를 나누는 구조가 하드웨어 성능보다 중요했습니다.

OCR은 첫 단계일 뿐입니다

이 프로젝트의 목적은 OCR 자체에 있지 않습니다.

현재 만들어지고 있는 Markdown, EPUB, 검색 가능한 PDF는 단순히 보관하기 위한 결과물이 아닙니다. 이 결과물을 앞으로 제가 사용하는 LLM Wiki의 소스 데이터로 활용할 계획입니다.

지금까지 가지고 있던 문서들은 사람에게는 읽을 수 있는 자료였지만 AI에게는 제대로 읽을 수 없는 자료가 많았습니다. 이 프로젝트는 그 자료를 이렇게 바꾸는 과정입니다.

PDF → OCR → 구조화된 텍스트 → 검색 가능한 지식 → LLM이 활용할 수 있는 Wiki

나중에는 Claude Code든 Codex든 다른 AI든, 새로운 세션을 시작할 때 필요한 지식을 처음부터 다시 설명하는 것이 아니라 이 지식 저장소를 읽고 시작하게 만들고 싶습니다.

문서를 OCR하는 것에서 끝나는 게 아니라, 내가 가진 디지털 자료들을 AI가 장기적으로 활용할 수 있는 지식 기반으로 바꾸는 것. 그게 이 프로젝트의 다음 단계입니다.

지금 고치고 있는 것

가장 먼저 고치고 있는 것은 **"서버가 죽어도 작업 결과는 죽지 않는 구조"**입니다.

지금은 몇 시간 동안 OCR한 결과가 업로드 단계에서 문제가 생기면 다시 처음부터 처리해야 하는 경우가 있습니다. 앞으로는 서버가 아프면 워커가 완성본을 자기 컴퓨터에 가지고 있도록 만들 생각입니다.

업로드 실패 → 로컬 보관 → 다음 작업 진행 → 서버 정상화 → 자동 재업로드

이 구조가 완성되면 중앙 서버가 잠깐 멈춰도 100대의 컴퓨터가 같이 멈출 필요가 없습니다.

대시보드에도 경고 시스템을 붙이고 있습니다. 이번 장애가 반나절 방치됐던 가장 큰 이유는 장애가 없어서가 아니라 장애가 화면에 보이지 않았기 때문입니다.

아직 답을 못 찾은 질문

가장 궁금한 것은 저사양 컴퓨터의 참여 기준입니다.

현재 직접 측정한 바로는 GTX 950 2GB에서는 약 36초/페이지로 겨우 돌아가고, GTX 750 1GB에서는 한 권도 끝내지 못했습니다.

그렇다면 질문이 생깁니다. 느린 컴퓨터라도 한 대 더 추가되면 함대에는 이득일까? 아니면 전기와 참여자의 컴퓨터 자원을 생각하면 일정 성능 아래에서는 참여시키지 않는 것이 나을까?

surya-2(0.65B)의 실제 VRAM 사용량 자료도 충분하지 않아 직접 측정하고 있습니다. 이 부분은 앞으로 GPU별 처리속도와 VRAM 사용량을 모아 따로 정리해 공유할 계획입니다.