01 Responsibility
직원 작업 화면부터 학습 입력까지 맡았습니다.
MAYEYE 인턴십에서 직원들이 사용할 웹 도구와 관리 체계, 보정 데이터를 추가 학습에 활용하는 코드를 맡았습니다. 문서를 고치는 작업과 모델 학습 사이의 연결을 만드는 것이 제 담당 범위였습니다.
- OCR 라벨링 웹 페이지: 인식이 잘되지 않는 페이지를 불러와 원본 이미지와 인식 결과를 확인하고, 텍스트 영역과 내용을 수정할 수 있는 작업 화면을 구현했습니다.
- 직원·관리자 체계: 직원의 작업 화면과 관리자의 문서·계정 관리 화면을 구성하고, 문서를 할당해 작업하는 흐름을 만들었습니다.
- 추가 학습 코드: 라벨링으로 축적한 데이터를 PaddleOCR 추가 학습에 활용하는 자동화 로직과 GPU 환경에서 학습을 실행할 수 있는 코드를 작성했습니다.
웹 · React 18, TypeScript, Tailwind CSS, Zustand, PDF.js
서버 · Python, FastAPI, JWT, asyncio, SSE
OCR·저장 · PaddleOCR, PP-StructureV3, PostgreSQL, Supabase Storage
02 Problem
읽을 수 있는 PDF와, 활용할 수 있는 텍스트 사이.
텍스트를 추출하기 어려운 공공문서 PDF는 화면 읽기 도구와 TTS로 활용하는 데 제약이 있었습니다. 당시 문자 단위의 보정·검수가 반복되고, 영역·문단·표의 구조를 다시 확인해야 했습니다.
저는 직원이 원본과 OCR 결과를 비교해 수정하는 웹과 관리 기능을 맡고, 보정한 라벨을 추가 학습에 활용하는 코드로 연결했습니다. 문서를 수정하는 작업과 학습 데이터를 만드는 작업이 이어지도록 하는 데 집중했습니다.
03 Training pipeline
오인식 사례를, 추가 학습의 입력으로.
기본 OCR 모델만으로 처리하기 어려운 한글 문서에는 다양한 글꼴, 복잡한 표, 저해상도 스캔과 기울어진 페이지가 섞여 있었습니다. 이런 페이지를 작업 화면에서 보정하고, 그 과정에서 만들어진 라벨을 모아 추가 학습에 사용하는 흐름을 구성했습니다.
- 어려운 페이지를 작업 대상으로 가져오기. OCR 결과가 잘 나오지 않는 페이지를 불러와 원본과 인식 영역·텍스트를 확인합니다.
- 사람이 라벨을 수정하고 저장하기. 잘못 잡힌 텍스트 영역과 인식 내용을 보정해 학습에 사용할 데이터를 축적합니다.
- 학습 입력으로 연결하기. 수집한 데이터를 PaddleOCR 추가 학습에 활용할 수 있도록 준비하는 자동화 로직을 작성했습니다.
- GPU에서 학습 실행하기. 축적한 데이터를 GPU 환경에 올려 추가 학습을 실행할 수 있는 코드까지 구현했습니다.
이 흐름의 핵심은 모델의 예측 결과를 그대로 학습에 넣는 대신, 사람이 보정한 데이터를 학습의 기반으로 활용하는 것입니다. 예측 오류를 수정하는 웹 도구와 학습 코드를 연결해, 문서 처리 중 발견한 어려운 사례를 다시 사용할 수 있도록 했습니다.
OCR의 confidence는 모델이 인식 결과에 부여한 점수입니다. 실제 정답과 비교한 정확도와는 다르므로, 점수만으로 문서가 정확히 처리되었다고 판단할 수는 없습니다. 이 플랫폼의 라벨링·검수 단계는 원본과 결과를 사람이 비교하는 역할을 맡습니다.
04 Scope
보정 웹과 관리 기능, 학습 실행 코드를 만들었습니다.
문서 업로드·OCR 결과 확인·영역별 보정, 직원·관리자 화면과 문서 할당, 수집 데이터의 추가 학습 실행 코드를 구현했습니다. 문서 접근성과 TTS 활용은 프로젝트의 출발점이며, 이 사례에서 소개하는 담당 범위는 텍스트·라벨 데이터 구축과 OCR 추가 학습 기반입니다.
2025년 9월 발표자료의 설계·시연 화면과 담당 업무를 바탕으로 정리했습니다. 공개 소개에는 회사 내부 문서·계정 정보와 발표자료 원본을 포함하지 않았습니다. 추가 학습 전후의 정확도 수치나 운영 도입 성과는 별도로 제시하지 않습니다.
MAYEYE 회사 소개 ↗ (새 탭)05 Design decisions
단순한 텍스트 추출을 넘어, 검수할 수 있는 도구로.
01 / PAGE & REGION
원본 페이지와 영역별 결과를 함께 확인.
- 문제
- 추출된 텍스트만 보면 누락된 영역이나 잘못 나뉜 문단, 표의 위치를 확인하기 어렵습니다. 인식 오류가 많은 일부 페이지 때문에 문서 전체를 다시 살피는 부담도 생깁니다.
- 구성
- 페이지 이미지 위의 텍스트 영역과 인식 결과 목록을 함께 보는 편집 화면을 구성했습니다. 작업자는 문제가 있는 페이지에서 영역과 글자를 수정하고 결과를 저장할 수 있습니다.
- 이유
- 인식한 내용과 원본의 위치를 나란히 비교할 수 있어야 누락·오인식을 검수하고, 해당 이미지에 대응하는 라벨을 만들 수 있기 때문입니다.
02 / WORKFLOW
직원의 보정 작업과 관리자의 문서 운영을 구분.
- 문제
- 여러 사람이 라벨링하려면 누가 어떤 문서를 담당하는지, 어떤 작업이 진행 중인지 관리할 수 있어야 합니다.
- 구성
- 직원용 작업 화면과 관리자용 문서·계정 관리 화면을 만들고, 문서 할당 정보를 관리하는 구조를 구성했습니다.
- 이유
- 라벨링 편집 기능에 문서 할당과 계정 관리가 함께 있어야, 개인이 파일을 수정하는 도구를 넘어 회사 구성원이 함께 데이터를 구축하는 작업 환경으로 사용할 수 있기 때문입니다.
03 / PROCESSING STATUS
처리 결과와 진행 상황을 나눠 전달.
여러 페이지의 OCR은 업로드 직후 끝나는 작업이 아닙니다. 서버의 비동기 처리 흐름과 SSE 진행 알림을 사용해 웹에서 처리 상황을 확인하도록 구성했습니다. 페이지별 결과·캐시와 작업 로그를 남기는 구조는 어떤 페이지에서 문제가 생겼는지 확인하는 데도 필요했습니다.
06 Architecture
문서 처리와 사람이 보정하는 흐름을 한곳에.
웹에서는 PDF를 업로드하고 페이지와 OCR 결과를 확인합니다. FastAPI는 문서 처리 요청을 받아 OCR 엔진과 저장소를 연결하고, 진행 상황을 SSE로 전달합니다. 파일은 Storage에, 문서·작업 관련 메타데이터는 PostgreSQL에 저장하는 구성입니다.
텍스트·레이아웃·표 인식
문서·할당 메타데이터
OCR JSON · 내보내기
업로드 → 페이지 전처리 → 영역 검출·문자 인식 → 구조화된 결과 저장
오인식 페이지 확인 → 영역·텍스트 라벨 수정 → 저장·데이터 축적
축적한 라벨링 데이터 → 학습 입력 준비 → GPU에서 PaddleOCR 추가 학습 실행
OCR 처리는 전처리 → 검출 → 인식 → 후처리로 나눴습니다. 텍스트 영역과 문서 레이아웃을 찾고, 한글·영문·숫자를 인식한 뒤 구조화된 결과로 저장하는 흐름입니다. PDF.js는 브라우저에서 문서 페이지를 보여주는 역할을 맡고, 서버의 OCR 처리와 구분됩니다.