article · 2026-08-11
AI 모델은 처리 모듈이다
이미지 인식에서 문서 처리로, 다시 Task 계약과 Agent Tool Platform으로.
이미지 인식에 대해 찾아보면서 문서 처리라는 분야에 대해 좀더 잘 이해하게 되었다.
처음에는 이미지에서 원하는 대상을 얼마나 잘 찾을 수 있는지가 궁금했다. 그런데 문서 처리 사례를 따라가 보니 질문이 달라졌다. 글자·표·그림을 찾는 것만으로는 문서가 되지 않았다. 각 요소의 의미와 관계, 읽기 순서와 계층을 복원하고, 그 결과를 다음 업무가 사용할 수 있는 데이터 구조로 만들어야 했다.
이 탐색은 문서 파서의 구조를 넘어 AI-Native System의 설계 원칙으로 이어졌다. 모델이 먼저가 아니라 Task가 먼저다. Task가 요구하는 관찰값을 정의해야 적절한 모델과 Tool을 고를 수 있다. 그리고 조직 규모에서는 이 Task 계약과 Tool, 지식과 거버넌스를 공통 기반으로 제공하는 Agent Tool Platform이 필요해진다.
이미지 인식
→ 무엇이 어디에 있는가
문서 처리
→ 무엇과 연결되고 어떤 순서로 읽히는가
Task 설계
→ 다음 업무에 필요한 관찰값과 실패 조건은 무엇인가
Agent Tool Platform
→ Task 계약·Smart Tool·지식·거버넌스를 어떻게 공통 기반으로 제공할 것인가
요약하면, 이미지 인식은 모델의 성능을 보는 출발점이었다. 문서 처리는 여러 모델과 규칙이 Task별로 협업해야 하는 이유를 보여줬다. Agent Tool Platform은 그 Task와 Tool을 조직의 지식·권한·평가 체계 안에서 반복 사용할 수 있게 만드는 운영 기반이다.
이미지 인식에서 문서 처리로
Docling의 최신 레이아웃 모델 heron-101은 공개 평가에서 78% mAP를 기록했다. 이전 Docling 기준 모델보다 20.6~23.9%p 개선된 결과다. 다만 이 수치를 곧바로 문서 이해의 정확도로 읽을 수는 없다. mAP는 정해진 종류의 영역을 얼마나 정확히 검출했는지 측정하는 지표이고, 실제 문서 변환의 품질은 영역 사이의 관계와 읽기 순서까지 좌우하기 때문이다. Advanced Layout Analysis Models for Docling
사람도 같은 문서를 언제나 동일하게 라벨링하지는 않는다. DocLayNet은 모델이 사람 annotator 간 합의 수준보다 약 10% 뒤처진다고 보고했다. 또한 학술 논문 중심 데이터셋으로 학습한 모델은 다양한 실제 문서 레이아웃에서 정확도가 크게 낮아질 수 있음을 보여준다. 즉, 문서 레이아웃 인식의 어려운 부분은 단순히 상자를 놓치는 데 있지 않다. DocLayNet: A Large Human-Annotated Dataset for Document-Layout Analysis
클래스별 차이도 크다. 큰 텍스트와 표 영역은 비교적 잘 검출되지만, 페이지 머리말·꼬리말, 수식, 그림 설명, 섹션 제목처럼 작거나 문맥에 의존하는 요소는 더 어렵다. 예를 들어 Deep Learning Architecture라는 한 줄은 시각적 모양만으로 제목인지, 섹션 제목인지, 그림 설명인지, 일반 본문인지 단정하기 어렵다. 글자 크기와 위치뿐 아니라 앞뒤 문단, 인접한 그림, 문서 전체의 계층을 함께 봐야 한다. Docling의 공개 모델 카드에서도 텍스트와 표의 검출 성능은 높지만, 머리말·꼬리말·수식의 성능은 상대적으로 낮게 나타난다. Docling Models
PDF 한 페이지를 Markdown으로 바꾸는 일을 생각해보자. 얼핏 보면 “문서 이해 AI” 하나를 고르는 문제처럼 보인다. 실제 파이프라인은 전혀 다르게 생겼다.
먼저 페이지에서 제목, 본문, 표, 그림, 캡션이 어디에 있는지 찾는다. 표라면 행과 열, 셀의 관계를 복원한다. 글자 영역은 텍스트를 읽고, 각 영역의 순서를 정한다. 그 결과를 문서 객체로 묶어야 Markdown이나 JSON이 된다.
PDF 페이지
→ 레이아웃 탐지
→ 영역별 인식
→ 요소 관계·읽기 순서·계층 복원
→ 문서 데이터 모델
→ Markdown / JSON / 검색 / 업무 처리
그림과 캡션의 bounding box를 모두 찾아도, 어느 캡션이 어느 그림에 속하는지와 두 개의 본문 열을 어떤 순서로 읽는지를 틀리면 문서는 잘못 파싱된다. 그래서 문서 레이아웃 분석은 객체 탐지와 구조 이해 사이에 놓인 문제다.
Docling도 이런 분해를 전제로 한다. 레이아웃, 표 구조, OCR, 읽기 순서와 결과 문서 모델을 서로 다른 처리 단계로 다룬다. Docling model catalog
문서 처리는 하나의 모델이 페이지를 통째로 이해하는 문제가 아니었다. 서로 다른 Task가 관찰값을 만들고, 다음 단계가 그 값을 이어받아 구조를 완성하는 문제였다. 여기서 첫 번째 설계 원칙이 나온다. 모델은 이해의 주체라기보다, 비정형 입력을 다음 단계가 사용할 관찰값으로 바꾸는 처리 모듈이다.
모델은 정보를 정형화하는 처리 모듈이다
모델을 처리 모듈로 보면 비교 기준이 달라진다. 레이아웃 모델은 TABLE, PICTURE, SECTION_HEADER와 bounding box를 낸다. OCR은 문자열과 단어 좌표를 낸다. 표 인식기는 셀과 행·열 관계를 낸다. 마지막 문서 모델은 이 결과들의 소속과 순서를 보존한다. 중요한 것은 모델 이름이 아니라 각 단계가 보장하는 출력이다.
비정형 입력
→ Task별 처리 모듈
→ 정형 관찰값
→ 데이터 모델
→ 업무 판단과 실행
언어도 같다. 문장은 형태소, 품사, entity, intent, 관계, 임베딩으로 바뀔 수 있다. 음성은 transcript와 timestamp가 된다. 이미지는 box, mask, landmark, text, 변화 영역이 된다.
이 결과를 “모델의 답변”이라고 부르면 설계가 거기서 끝나기 쉽다. 정형 관찰값이라고 부르면 바로 다음 질문이 생긴다.
-
이 값은 어떤 entity에 속하는가?
-
이전 관찰과 같은 대상인가?
-
어떤 업무 상태를 바꾸는가?
-
누가 이 값을 검증하거나 수정할 권한을 갖는가?
이 질문부터는 모델 선택이 아니라 데이터 모델의 영역이다. DoclingDocument가 text, table, picture뿐 아니라 계층, bounding box, provenance를 함께 담으려는 이유도 여기에 있다. 인식 결과는 파일로 흩어져 있으면 아직 업무 정보가 아니다. DoclingDocument
Detection, Recognition, Structure, Semantics는 같은 일이 아니다
Task를 먼저 보려면 먼저 서로 다른 종류의 일을 구분해야 한다. 문서 파이프라인에서는 적어도 네 단계가 나뉜다.
Detection : 표가 어디에 있는가
Recognition : 그 표 안의 글자와 셀은 무엇인가
Structure : 이 캡션은 어느 그림에 붙고, 무엇을 먼저 읽는가
Semantics : 이 표와 본문은 무엇을 주장하는가
YOLO나 RT-DETR 같은 detector는 앞의 두 질문 가운데 첫 번째에 특히 잘 맞는다. person 대신 table, figure, title을 찾는 객체 탐지다. 하지만 탐지 결과만으로는 표를 데이터로 만들 수도, 그림과 캡션의 관계를 보장할 수도 없다.
따라서 하나의 거대한 모델이 모든 일을 해야 한다는 결론으로 갈 필요가 없다. 고정된 구조의 청구서에서 금액만 뽑는다면 OCR과 필드 규칙이 더 분명한 계약을 만든다. 문서의 표를 데이터베이스로 적재해야 한다면 table structure recognition이 빠질 수 없다. 그림끼리 유사도를 찾고 싶을 때는 visual representation이 필요해진다. 해야 할 일이 달라지면 필요한 출력과 도구도 달라진다.
문서에서 보인 분해는 이미지와 언어에도 그대로 적용된다.
| 알고 싶은 것 | Task | 필요한 출력 | 먼저 쓸 후보 |
|---|---|---|---|
| LED가 켜졌는가 | 상태 판정 | boolean, 색 비율, mask 품질 | threshold, morphology, rule |
| 다이얼이 정상 범위인가 | 기하 측정 | 중심, 각도, 오차 | contour, line/circle detection |
| 화면의 금액은 얼마인가 | 필드 추출 | text, word box, field value | OCR + field rule |
| 문서의 표는 무엇인가 | 문서 구조 복원 | table, heading, reading order | document parser |
| 처음 보는 물체는 무엇인가 | 열린 세계 의미 인식 | class, embedding, 설명 | detector, representation model, VLM |
모델을 먼저 고르면 이 다섯 일을 모두 “이미지 이해”라고 부르게 된다. Task를 먼저 고르면 필요한 출력, 허용 오차, 실패했을 때의 다음 경로가 드러난다. Task-first는 모델을 덜 중요하게 보는 태도가 아니라, 모델이 맡아야 할 책임을 더 정확하게 정하는 방식이다.
Tool은 Task 계약의 구현체다
Task가 정의되면 Tool은 그 계약을 실행 가능한 형태로 만든다. NLP에서 Kiwi가 문장을 형태소와 품사라는 일정한 단위로 바꾸듯, 이미지에도 처리 도구가 있다. 다만 이미지에서는 범용 형태소 분석기 하나로 끝나지 않는 경우가 많다. threshold, contour, registration, OCR, pose landmark, layout parser처럼 Task에 따라 parser를 조합한다.
고정된 조작 패널이라면 panel_led_parser 같은 작은 parser를 만들 수 있다. 입력은 패널 ROI, 출력은 led_on, component_area, hue_ratio, unknown_reason이다. 이것은 object detection의 축소판이 아니다. 업무가 정의한 상태 판정 Task의 구현체다.
문자와 좌표가 필요하면 Tesseract가 plain text 외에 hOCR, TSV, ALTO, PAGE 같은 구조화 출력을 제공한다. Tesseract OCR
사람의 자세가 문제라면 MediaPipe Pose Landmarker가 이미지와 video에서 신체 landmark를 이미지 및 world 좌표로 출력한다. MediaPipe Pose Landmarker
모두 AI를 썼는가가 기준이 아니다. 어떤 입력을 받아 어떤 필드를 보장하고, 실패할 때 어떤 상태를 반환하는지가 기준이다. 이 계약이 명확한 Tool일수록 다른 Workflow에서도 다시 사용할 수 있다.
Agent는 파서가 아니라 위임의 주체다
Tool이 Task 계약을 구현한다면 Agent의 역할도 선명해진다. Agent에게 페이지 하나를 던지고 “이 문서를 이해해서 처리해”라고 시키는 것은 편하다. 하지만 이 요청 안에는 최소한 레이아웃 탐지, 텍스트 추출, 표 복원, 정책 판단, 후속 실행이 섞여 있다.
이것을 Agent 하나에 몰아주면 실패 원인이 사라진다. 표를 못 찾은 것인지, 표는 찾았지만 셀을 잘못 읽은 것인지, 정상적으로 읽었지만 업무 규칙을 잘못 적용한 것인지 구분하기 어렵다. 호출 비용과 처리 시간도 함께 흔들린다.
Agent가 할 일은 각 처리 모듈을 없애는 일이 아니다.
업무 요청을 Task로 해석한다
→ 적절한 parser와 tool을 고른다
→ 결과가 unknown이거나 충돌하면 다음 검증을 위임한다
→ 권한이 필요한 실행은 정책과 사람의 승인을 확인한다
→ 결과와 근거를 남긴다
규칙으로 확정할 수 있는 값은 규칙으로 끝낸다. 전문 모델의 출력이 충분하면 그 결과를 저장한다. 모호한 입력, 예외, 여러 Task 사이의 충돌만 Agent에게 넘긴다. Agent는 parser의 자리를 차지하는 것이 아니라 그 사이의 판단과 위임을 맡는다.
DINOv3도 retrieval, correspondence, video segmentation tracking처럼 feature를 직접 쓸 수 있는 Task를 제시한다. 모델의 성능표를 보기 전에 그 feature가 어떤 처리 계약에 들어갈지 정하는 편이 설계에는 더 도움이 된다. DINOv3 model card
AI Native 조직은 모델 목록이 아니라 Task 계약을 소유한다
이제 관점을 개별 Workflow에서 조직으로 넓혀보자. 시스템이 작을 때는 Agent 하나가 입력을 읽고 판단하고 실행해도 된다. 시스템이 커지면 모델 카탈로그나 Agent 수보다, 어떤 팀이 어떤 Task 계약을 소유하는지가 중요해진다.
상담 조직이 소유해야 할 것은 챗봇 하나가 아니다. 의도, 고객 상태, 위험 신호, 처리 이력, 승인 필요 여부라는 데이터 모델이다. 각 필드를 어떤 입력에서 만들고, 누가 수정하며, 어느 오류에서 사람에게 넘길지를 Task 계약으로 정해야 한다.
업무 목적
→ 알고 싶은 정보
→ 데이터 모델
→ Task 분해
→ Tool과 model 배치
→ Agent 위임
→ 사람의 승인·예외 처리
→ 관측·평가·개선
이 구조에서 싼 도구를 먼저 쓴다는 말은 “LLM을 아끼자”는 구호가 아니다. 검증 가능한 관찰값을 가능한 작은 모듈에서 만들고, 모호함과 예외에만 큰 모델과 Agent를 쓰자는 설계 원칙이다.
다음 AI 시스템을 설계할 때 모델 비교표보다 먼저 적을 문장은 이쪽에 가깝다.
이 입력을 어떤 관찰값으로 바꿔야, 다음 업무가 움직이는가?
문서 파서가 이미 보여주고 있다. 하나의 “이해”라는 말 안에는 여러 Task가 들어 있다. 그 Task를 꺼내고, 출력 계약을 만들고, 알맞은 도구를 배치한 뒤에야 Agent가 위임할 일이 선명해진다.
AI-Native System의 기반, Agent Tool Platform
Task 계약의 조직적 소유까지 생각하면 최종 목적지가 보인다. AI-Native System에서 먼저 만들 것은 Agent 하나나 모든 조직이 따라야 할 정답 Workflow 하나가 아니다. 지식과 거버넌스를 내장한 Smart Tool이 업무 능력을 증폭하고, Agent는 그 도구들을 선택·위임·조율하는 얇은 층으로 남는 구조다. 다시 말해 Thin Agents, Thick Smart Tools를 가능하게 하는 Agent Tool Platform이 필요하다.
여기서 Smart Tool은 API를 한번 감싼 함수가 아니다. 어떤 입력을 받고 어떤 관찰값을 내는지, 어떤 지식과 데이터 범위를 참조하는지, 누가 실행할 수 있는지, 실패하면 무엇을 반환하는지, 어떤 테스트로 품질을 확인하는지를 함께 가진 Task 계약이다. Tool이 이 정도로 두꺼워질수록 Agent는 모든 업무 지식과 예외 처리를 프롬프트 안에 품을 필요가 없다.
실무자는 고객 문의 분류, 계약서 검토, 보고서 작성처럼 자신이 가장 잘 아는 업무의 Task를 쪼개고, 그 Task에 맞는 Tool과 Agentic Workflow를 구성한다. 중앙 플랫폼이 모든 세부 흐름을 대신 설계할 필요는 없다. 대신 각 흐름이 공통의 지식·권한·테스트·감사 기반을 쓰게 해야 한다.
실무자가 구성하는 Agentic Workflow
→ Task와 Tool 조합
→ 얇은 Agent의 선택·위임·조율
→ 업무 결과
조직이 제공하는 Agent Tool Platform
→ 두꺼운 Smart Tool: Task 계약·도메인 지식·실행 규칙
→ 지식 그래프: 업무 맥락·데이터·근거의 연결
→ Tool 계약·권한·정책 거버넌스
→ 조직 그래프: 사람·팀·업무·데이터·책임의 연결
→ 테스트 도구: 품질·비용·지연·안전성 평가
→ 실행 이력·근거·예외 관측
지식 그래프와 조직 그래프는 각각 ‘무엇을 알아야 하는가’와 ‘누가 무엇을 책임지는가’를 Tool이 읽을 수 있게 만든다. 조직 그래프는 단순한 조직도가 아니다. 어떤 팀이 어떤 업무 상태를 소유하는지, 어떤 데이터와 Tool에 접근할 권한이 있는지, 어느 판단에서 사람의 승인이 필요한지를 연결하는 운영 지도다. 이 연결이 있어야 Agent가 잘못된 팀의 데이터를 읽거나, 승인되지 않은 실행을 하거나, 결과의 책임 소재가 사라지는 일을 줄일 수 있다.
테스트 도구도 모델 벤치마크 하나로 충분하지 않다. 실제 업무 입력으로 Tool 호출 결과, 출력 형식 준수, 사람 검토 비용, 실패율, 지연 시간, 정책 위반 여부를 함께 평가해야 한다. 그래야 실무자는 새 워크플로를 빠르게 실험할 수 있고, 조직은 무엇이 효과적이고 무엇이 위험한지 같은 기준으로 비교할 수 있다.
이 조합이 갖춰지면 자율성과 통제가 충돌하지 않는다. 실무자는 업무 가까이에서 Agentic Workflow를 계속 개선하고, 조직은 지식·거버넌스·테스트 도구를 갖춘 Smart Tool을 계속 강화한다. 모델이 바뀌어도, 개별 워크플로가 달라져도, Task 계약과 지식·거버넌스·조직 그래프·테스트 도구가 남는다. 그 기반 위에서 Thin Agent는 더 적은 맥락으로도 더 정확하게 위임할 수 있다. 이것이 AI-Native System이 단발성 데모를 넘어 운영 역량으로 축적되는 방식이다.