VisionLinq는 이미지·PDF·오피스 문서를 읽어 구조화된 데이터로 돌려주는 문서 AI API입니다. 설계 노트 연재의 1편입니다 — 출시를 준비하며 내린 설계 결정들을, 결정의 이유와 함께 기록합니다. 1편은 다른 모든 결정보다 먼저 정한 것, 경계 이야기입니다.
1. 원본은 고객의 클라우드에 남는다
문서 처리 서비스의 흔한 구조는 "파일을 우리에게 업로드하면, 우리가 보관하며 처리해 드립니다"입니다. 우리는 반대로 정했습니다 — 고객이 원본 문서와 업무 데이터베이스를 자기 클라우드 계정에 그대로 두고, VisionLinq는 승인된 소스를 읽어 요청된 파이프라인을 돌리고 결과만 돌려줍니다.
문서에는 단가표, 계약 조건, 주민번호가 들어 있습니다. 그런 데이터의 보관 주체가 바뀌는 순간 고객의 컴플라이언스 부담도 함께 넘어옵니다. 미들웨어는 읽고, 처리하고, 돌려주고, 잊는 쪽이 맞습니다.
2. 추출 값에는 근거와 신뢰도가 붙는다
"AI가 문서를 읽었습니다"만으로는 업무에 못 씁니다. 세금계산서의 공급가액을 추출했다면, 그 값이 문서의 어디에서 왔는지(원문 위치·좌표)와 얼마나 확신하는지(보정된 신뢰도)가 함께 와야 합니다.
- 근거가 있으면 사람이 검증할 수 있습니다 — 값을 클릭하면 원본의 그 자리가 하이라이트되는 UI를 고객이 만들 수 있습니다.
- 신뢰도가 있으면 자동화의 경계를 고객이 정할 수 있습니다 — "0.95 이상은 자동 입력, 그 밑은 사람 확인" 같은 규칙이 가능해집니다.
우리는 이것을 evidence-bearing 결과라고 부릅니다. 값만 돌려주는 API와 근거를 돌려주는 API는 겉보기에 비슷하지만, 그 위에 지을 수 있는 업무의 종류가 다릅니다.
3. 한국 문서가 1급이다
범용 OCR은 많습니다. 그러나 한국의 영수증, 세금계산서, 계약서에는 그 문서만의 구조와 어휘가 있고, 범용 모델은 그 구조를 모릅니다. VisionLinq는 한국 문서 스키마를 내장하고, 문서 분류와 스키마 기반 구조화 추출을 OCR과 한 파이프라인으로 묶습니다. 품질 게이트도 한국어 문자 인식 정확도를 기준으로 잡습니다.
4. 배포 형태가 달라도 계약은 하나다
클라우드 API로 쓰든, 고객 인프라에 직접 설치(BYOC)하든 같은 작업·결과 계약을 씁니다. 처음에 작게 시작해서 규제나 규모 때문에 설치형으로 옮겨도, 연동 코드는 그대로입니다. "배포 형태의 선택이 API의 재작성을 부르면 안 된다"가 규칙입니다.
VisionLinq는 현재 출시를 준비하고 있습니다. 다음 편에서는 이 원칙들이 실제 구조가 되는 첫 장면 — 문서 변환을 인터넷이 끊긴 컨테이너에 격리한 이유와, 그 제약이 오히려 구조를 단순하게 만든 과정을 다룹니다. 진행 소식은 이 블로그와 devslab.kr에서 전하겠습니다.