이 화면은 현재 OCR 플랫폼을 UI 중심이 아니라 원문 처리 관점에서 설명합니다. 각 단계마다 무엇을 하려는지, 어떤 기술을 쓰는지, 대안은 무엇이었는지, 왜 그 방향을 선별했는지, 그리고 Mac Studio POC 이후 어떤 서버 구조로 넘어가야 하는지를 객관적으로 정리한 개요입니다.
오케스트레이터 기본 경로는 Stage 1 DetectionStage, Stage 2 RecognitionStage까지만 활성입니다.
현재 기본 Ollama 모델과 VLM 모델 설정은 둘 다 `qwen3.5:122b` 입니다.
이 장비는 Mac Studio, Apple M3 Ultra, 메모리 256GB 입니다.
방법론 문서에는 Stage 1~5 전체 설계와 탐지 수, 저신뢰 라우팅 수치가 정리돼 있습니다. 다만 이 수치가 현재 자동 경로의 실시간 운영값과 동일하다고 단정할 수는 없습니다.
고문서에서 글자 영역을 과감하게 많이 잡고, 후속 단계에서 정제하는 탐지 우선 전략입니다.
탐지된 글자 crop에 대해 빠른 1차 판독을 수행하고, 낮은 신뢰도는 후속 보강 대상으로 넘기는 단계입니다.
기본 OCR이 자신 없어 하는 글자에만 VLM을 추가 투입해 후보를 늘리고, 합의 또는 교체 판단을 하는 보강 단계입니다.
문자 하나씩 고치는 것이 아니라 세로쓰기 줄 단위 문맥을 보고 오인식을 교정하는 단계입니다.
최종 텍스트를 단순 OCR 결과로 끝내지 않고, 문서 구조에 맞는 필드와 그룹으로 묶는 단계입니다.
현재 업로드 샘플 해상도는 약 4162×3063 수준입니다.
Stage 3 VLM, Stage 4 LLM은 구현은 있으나 오케스트레이터 기본 경로에선 비활성입니다.
특히 Stage 3은 저신뢰 문자 수에 거의 비례해 비용이 증가합니다.
사람이 개입해야 할 지점이 명확히 보이도록 설계돼 있습니다.
Mac Studio급 Apple Silicon은 로컬 실험과 모델 조합 검증에는 적합합니다. 특히 통합 메모리가 커서 대형 모델을 억지로라도 올려보는 POC엔 유리합니다.
현재 자동 경로의 페이지당 처리시간은 이 화면에서 확정 수치로 적지 않았습니다. 코드 구조상 Stage 1 다중 패스 탐지가 가장 무거운 구간인 것은 확인되지만, 안정된 동일 샘플 실측표가 repo 안에 정리돼 있지 않아 시간은 별도 벤치마크 후 적는 것이 맞습니다.
방법론 문서에는 저신뢰 2,087개가 Stage 3 후보로 남는 예시가 있습니다. 다만 현재 자동 경로에는 Stage 3이 연결돼 있지 않으므로, 이 화면에서는 페이지당 총 처리시간을 단정하지 않고 'VLM은 문자 수에 비례해 비용이 커지는 보강 단계'까지만 사실로 적었습니다.
POC 장비가 Mac Studio M3 Ultra 256GB인 것은 실환경으로 확인했습니다. 또한 현재 Ollama에 `qwen3.5:122b`, `qwen2.5vl:32b`, `qwen2.5vl:7b` 등이 실제 적재돼 있습니다. 다만 서버 이전 시 필요한 정확한 GPU 스펙은 이 repo 내부 실측만으로 확정할 수 없어, 이 화면에서는 '122B 기본 설정은 POC 친화적이지 않다' 수준으로만 적었습니다.
Mac Studio는 POC와 모델 조합 검증 장비로는 적합하지만, 운영 서빙의 종착지는 아닙니다.
실서비스 자동 경로는 Stage 1~2를 기본으로 두고, Stage 3 VLM은 저신뢰 재처리 큐나 검수 보조로 분리하는 편이 현실적입니다.
운영 서버 스펙은 별도 실측 벤치마크 후 확정해야 하며, 현재 개요에는 검증된 코드/설정 사실만 반영했습니다.
즉 결론은 '맥스튜디오에서 방법론과 기준을 검증하고, 서버에서는 실측 기반으로 자동 경로와 보강 경로를 다시 분리 설계한다' 입니다.