"문서AI" 태그로 연결된 4개 게시물개의 게시물이 있습니다.

miwork hangul은 HWP 문서를 서버에서 PDF로 변환하고, 그 결과를 웹에서 바로 확인할 수 있게 합니다.

한두 개의 한글 문서를 열어 PDF로 저장하는 일은 익숙합니다. 그러나 수백 개, 수천 개의 문서를 검색용 데이터로 만들거나 PDF로 일괄 변환하려고 하면 이야기가 달라집니다.

문서마다 열기와 저장을 반복해야 하고, 중간에 멈추면 사람이 확인해야 합니다. 검색용 본문을 추출하거나 문서 미리보기를 만드는 작업도 마찬가지입니다. miwork hangul은 이 과정을 서버에서 반복 실행할 수 있는 문서 처리 기능으로 만들기 위해 시작했습니다.

HWP → PDF를 가장 먼저 다루는 이유​

miwork hangul이 가장 중요하게 보는 기능은 HWP → PDF 변환입니다.

PDF가 만들어지면 별도 프로그램 없이 브라우저에서 문서를 확인할 수 있고, 검색 결과 미리보기나 문서 보관 같은 다음 작업으로 연결하기도 쉽습니다.

업로드한 PDF는 HWPX로 재구성할 수 있습니다. 이 기능은 원본 편집 구조를 완벽하게 복원한다기보다, PDF의 텍스트와 이미지를 다시 편집할 수 있는 문서로 만드는 실용적인 변환에 초점을 둡니다.

한글 문서 변환이 까다로운 이유​

HWP 문서는 단순한 텍스트 묶음이 아닙니다. 글꼴, 글자 모양, 문단, 표, 도형, 이미지, 머리말·꼬리말, 각주와 페이지 배치 정보가 함께 결과 화면을 만듭니다. 같은 본문이라도 사용 가능한 글꼴이나 레이아웃 계산 방식이 달라지면 줄바꿈과 페이지 수가 달라질 수 있습니다.

웹의 HTML처럼 브라우저가 공통으로 제공하는 DOM을 그대로 이용할 수 있는 형식도 아닙니다. 한컴은 HWP Automation 개발 가이드와 HWPX/OWPML 관련 오픈소스 자료를 제공하지만, 이를 활용한 데스크톱 자동화와 Linux 서버에서의 대량 처리는 서로 다른 실행 환경과 설계가 필요합니다.

이 차이는 특정 제품의 부족함이라기보다, 오랫동안 축적된 문서 형식을 서로 다른 환경에서 재현할 때 마주치는 기술적 과제에 가깝습니다.

변환 범위를 넓혀온 과정​

지난 6개월 동안 다양한 HWP 문서의 변환 결과를 비교하며 지원 범위를 넓혔고, 내부 테스트에서 80% 이상의 변환 성공률을 확인했습니다. 여기서 성공은 변환이 오류 없이 끝나고 주요 본문과 페이지 구성을 확인할 수 있는 결과를 뜻합니다.

이 과정에서 개선한 HWP 해석과 PDF 생성 기능은 SoliDocs Viewer의 한글 문서 보기 기능에도 반영됐습니다. 아직 복잡한 차트와 수식, 특수 개체, 특정 글꼴과 정교한 페이지 배치처럼 해결할 사례가 남아 있습니다. 데모에서 보관에 동의한 문서와 사용자가 표시한 문제 구간을 유형별로 분석해 남은 부분을 채워갈 계획입니다.

성공률은 현재 내부 테스트 문서를 기준으로 한 관찰값이며 제품 보증 수치가 아닙니다. 문서 구성과 글꼴, 개체 종류에 따라 결과가 달라질 수 있고, 테스트 표본이 늘어나면 기준도 함께 갱신할 예정입니다.

서버에서 이어지는 활용​

miwork hangul은 한글 프로그램이 설치되지 않은 Linux 컨테이너에서 동작하며 서버 API로 연결할 수 있습니다. 여러 문서의 PDF 일괄 생성, 웹 미리보기, RAG와 문서 AI 전처리 같은 작업에 활용할 수 있습니다.

실제 문서로 확인하기​

miwork hangul 데모에서는 HWP·HWPX 문서를 PDF로 변환해 브라우저에서 확인하고 내려받을 수 있습니다. 어긋난 부분이 보이면 유형과 페이지를 표시할 수 있으며, PDF를 편집 가능한 HWPX로 재구성하는 기능도 시험할 수 있습니다.

miwork hangul 데모 열기 →

핵심 요약 미니소프트의 업무 솔루션 브랜드 MiWork 공식 사이트 miwork.ai를 열었습니다. 문서를 활용 가능한 데이터로 바꾸는 MiWork OCR, 조직의 지식과 도구를 연결하는 MiWork Agents, 필요한 업무 앱을 만들고 운영하는 MiWork VibeHub를 한곳에서 살펴볼 수 있습니다.

왜 별도의 사이트를 열었나​

AI를 업무에 적용하려고 하면 질문이 세 갈래로 나뉩니다.

• 흩어진 PDF, HWP, Office 문서를 어떻게 읽고 활용할 것인가
• 조직의 지식과 업무 도구를 어떻게 AI의 답변과 실행으로 연결할 것인가
• 현업에 필요한 작은 도구를 어떻게 만들고, 검토하고, 배포하고, 운영할 것인가

MiWork는 이 질문들을 서로 다른 제품의 목록으로 남겨두기보다 하나의 업무 흐름으로 연결하려는 브랜드입니다. 사이트에서는 각 솔루션을 독립적으로 살펴볼 수 있고, 조직의 문제에 맞는 출발점을 찾을 수 있습니다.

MiWork OCR — 문서를 데이터로​

MiWork OCR은 PDF와 이미지뿐 아니라 HWP/HWPX, Word, PowerPoint, Excel, HTML 같은 문서를 페이지별로 정리된 결과로 변환합니다.

문서 길이에 따라 바로 결과를 받거나 작업을 접수한 뒤 상태와 완료 결과를 확인할 수 있습니다. 표 구조를 다루고, 문서 종류와 정확도·속도 요구에 따라 OCR 엔진을 구성할 수 있다는 점도 함께 소개하고 있습니다.

문서가 단순히 보관되는 파일에 머물지 않고 검색·복사·후속 AI 업무에 쓰이는 데이터가 되려면, 먼저 안정적으로 읽히고 구조화되어야 합니다. MiWork OCR은 그 앞단을 담당합니다.

MiWork Agents — 질문에서 실행까지​

MiWork Agents는 사내 지식과 업무 도구를 연결하는 기업용 AI 에이전트 워크스페이스입니다.

문서 기반 검색과 RAG, 팀 지식베이스, 개인 파일 워크스페이스, 공유 챗봇, 도구 연결을 하나의 환경에서 다룹니다. 답변에 참고한 문서를 함께 확인하고, 필요한 경우 파일 작업이나 업무 도구 실행으로 이어지는 흐름을 목표로 합니다.

기업에서 AI를 사용할 때는 모델의 성능만큼 운영 기준이 중요합니다. MiWork Agents는 사용자와 팀 단위 접근 제어, 실행 환경 분리, 자격증명 관리, 사용량·예산·감사 기록 같은 운영 요소도 함께 고려합니다.

MiWork VibeHub — 아이디어를 업무 앱으로​

MiWork VibeHub는 사내 앱을 만들고 검토하고 배포하고 발견하고 운영하는 전 과정을 연결하는 플랫폼입니다.

앱 사용자는 앱스토어와 개인 대시보드에서 필요한 도구를 찾고 실행할 수 있습니다. 앱 제작자는 템플릿이나 자체 Git 저장소에서 시작해 AI 코딩 도구와 공통 플랫폼 서비스를 활용할 수 있습니다. 승인자와 운영자는 공개 범위, 앱 멤버십, 배포·롤백, 실행 상태와 로그를 관리합니다.

현업의 아이디어가 원가 계산기, 입찰 분석기, 현장 점검 도구처럼 실제 업무 앱으로 빠르게 만들어질 때 중요한 것은 만드는 속도만이 아닙니다. 누가 사용할지, 어떤 데이터를 볼지, 어떻게 배포하고 되돌릴지까지 함께 관리되어야 합니다. VibeHub는 그 운영 기반을 다룹니다.

세 솔루션은 어떻게 연결되나​

세 제품은 각각 독립적으로 시작할 수 있지만, 함께 사용할 때 흐름이 선명해집니다.

문서 업로드
  ↓
MiWork OCR — 구조화된 데이터
  ↓
MiWork Agents — 지식 검색·질문·업무 실행
  ↓
MiWork VibeHub — 필요한 업무 앱의 제작·배포·운영

모든 조직이 같은 순서로 도입할 필요는 없습니다. 문서 처리부터 시작할 수도 있고, 팀 지식 검색이나 사내 앱 운영부터 시작할 수도 있습니다. 사이트는 각 솔루션의 현재 범위와 도입 문의 경로를 함께 제공합니다.

지금 miwork.ai에서 볼 수 있는 것​

• MiWork 소개
• MiWork Agents
• MiWork VibeHub
• MiWork OCR
• 도입 문의

이번 오픈은 완성 선언이라기보다, 우리가 만들고 있는 업무 솔루션을 한 문장과 한 화면으로 설명하기 위한 시작입니다. 제품의 범위와 사용 사례가 구체화될수록 사이트의 내용도 계속 업데이트하겠습니다.

마치며​

MiWork가 만들고 싶은 것은 AI 기능을 하나 더 붙인 화면이 아닙니다. 문서가 지식이 되고, 지식이 실행으로 이어지고, 필요한 도구가 조직 안에서 안전하게 운영되는 흐름입니다.

공식 사이트에서 현재의 방향과 제품 구성을 확인해 보세요. 업무에서 반복되는 한 가지 문제부터 시작해도 좋습니다.

핵심 요약 OCR은 이미지·스캔 문서 안의 글자를 검색 가능한 텍스트로 바꾸고, Graph RAG는 문서와 개체 사이의 관계를 함께 활용합니다. 복잡한 보고서, 계약, 사고 기록처럼 단순 키워드 검색만으로 맥락을 잡기 어려운 문서에서 효과적입니다.

지난 글에서 RAG를 도서관 사서로 비유했습니다. 사용자가 묻는 질문에 맞춰 사서가 자료를 찾아 LLM에게 건네주는 그림이었죠. 그런데 도서관에 들어온 책이 글자 한 줄 없이 그림과 표만 가득한 보고서라면 어떻게 될까요? 또 자료끼리 서로 연결돼 있는 복잡한 사건이라면요?

이번 글은 RAG가 마주치는 그 다음 벽 두 가지와, 그걸 푸는 OCR · Graph RAG 이야기입니다.

Graph RAG와 OCR은 어떻게 연결될까​

OCR은 문서에서 텍스트와 표 구조를 꺼내고, Graph RAG는 추출된 정보 사이의 관계를 연결합니다. 그 위에서 벡터 검색과 답변 생성이 이어집니다.

텍스트만 잘 찾는 RAG의 한계​

이전 글에서 본 RAG는 문서를 작은 조각으로 자르고, 그걸 의미가 비슷한 숫자(벡터)로 바꿔 저장했습니다. 사용자가 질문하면 비슷한 의미의 조각을 찾아 LLM에게 함께 건넵니다.

문제는 두 가지 상황에서 막힙니다.

1. 글자가 그림 안에 있을 때

스캔본 PDF, 사진으로 찍힌 계약서, 표만 들어 있는 분기 보고서. 텍스트 추출이 안 되니 자를 조각이 없습니다. 사서가 "이 책은 사진뿐이라 못 읽어요" 하는 상황이죠.

2. 자료들이 서로 연결돼 있을 때

"작년에 사고 났던 그 현장에서, 비슷한 공정 또 한다는데 어떤 안전 수칙이 적용될까?" 같은 질문. 사고 사례 · 공정 표준 · 법 규제 — 세 자료가 따로 떨어져 있으면 답이 안 나옵니다. 사서가 책 한 권씩 찾아 줄 순 있지만, 책들 사이 관계를 엮어 주진 못합니다.

OCR — 그림 속 글자도 읽는 사서​

첫 번째 벽을 푸는 게 OCR입니다. Optical Character Recognition, 광학 문자 인식. 이미지 안의 글자를 텍스트로 추출합니다.

단순히 글자만 뽑는 게 아니라, 표의 구조, 문단의 위치, 제목과 본문의 계층 까지 인식하는 게 요즘 OCR의 핵심입니다. 금융권 여신 심사 문서, 건설 시방서, 의료 영상 판독지처럼 표가 빽빽한 문서가 많은 분야에서 특히 큰 차이를 만듭니다.

OCR로 글자를 뽑아내면, 그 다음은 일반 RAG 흐름으로 들어갑니다. 의미 단위로 자르고 → 벡터로 바꿔 저장 → 질문 들어오면 검색.

Graph RAG — 자료들의 관계까지 보는 사서​

두 번째 벽은 Graph RAG입니다. 이름 그대로 그래프 데이터베이스를 RAG에 결합한 방식입니다.

일반 RAG가 "비슷한 의미의 조각" 을 찾는다면, Graph RAG는 자료와 자료 사이의 관계 까지 함께 저장합니다.

예를 들어 "2024년 ○○ 공동구 사고" 사건이 있다고 합시다. 이 사건은 다음과 연결됩니다.

• 작업 공정: "고소 작업"
• 적용 법규: "산업안전보건법 제42조"
• 안전 수칙: "추락 방지 안전대 결속 의무"
• 유사 과거 사고: "2021년 △△ 현장 사고"

이 관계가 그래프로 묶여 있으면, "오늘 공동구 고소 작업 시 점검 사항"이라는 질문 하나에 사서가 위 네 자료를 함께 가져다 줍니다. LLM은 그걸 보고 "이런 법규에 따라 이런 점검을 하셔야 하고, 비슷한 과거 사고가 ○○에서 있었습니다" 라고 한 번에 답하죠.

자료를 따로따로 찾아 사용자가 머릿속에서 엮는 게 아니라, 시스템이 미리 관계를 알고 있어서 함께 묶어주는 게 Graph RAG의 가치입니다.

어디서 쓰이나​

OCR과 Graph RAG가 함께 빛나는 분야는 정해져 있습니다. 자료가 그림·표 위주이고, 자료들이 서로 강하게 얽힌 영역입니다.

금융 — 여신 심사·시장 분석 수십 페이지짜리 사업계획서, 결산 보고서, 시장 동향 자료. OCR로 표·차트를 끌어올리고, Graph RAG로 회사 · 산업 · 규제 관계를 묶으면, 담당자가 한 줄 질문으로 핵심을 받습니다.

산업 안전 — 현장 가이드 정부 안전 지침, 사내 시방서, 과거 사고 사례집. 현장 관리자가 "오늘 진행할 공동구 고소 작업 점검 사항"을 물으면, 시스템이 법규 · 수칙 · 유사 사례를 함께 묶어 즉시 가이드합니다.

마치며​

RAG는 한 번에 완성되는 기술이 아닙니다. 텍스트만 잘 찾던 단계에서, 이미지 속 자료를 보고, 자료들 사이 관계까지 엮어 답하는 방향으로 한 걸음씩 나아갑니다.

미니소프트는 이 단계별 RAG를 금융과 산업 안전 분야에서 직접 운영하며, 사서를 더 똑똑하게 만드는 방법을 매일 실험하고 있습니다.

참고 자료​

• From Local to Global: A Graph RAG Approach to Query-Focused Summarization
• Microsoft Research: Project GraphRAG
• Azure AI Document Intelligence overview

핵심 요약 RAG는 질문과 관련된 자료를 먼저 검색한 뒤, 그 자료를 근거로 LLM이 답하게 만드는 구조입니다. 사내 챗봇처럼 최신 문서와 내부 규정을 정확히 반영해야 하는 업무에서 특히 중요합니다.

"우리 회사 휴가 정책 알려줘"라고 물었을 때, 챗봇이 정확히 우리 회사 규정을 답해주는 걸 본 적 있나요? 공개 LLM은 우리 회사 내부 문서를 모를 텐데 어떻게 가능할까요? 그 비밀이 바로 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 입니다. 도서관 사서 비유로 풀어보겠습니다.

그냥 LLM에 물어보면 안 되나요​

일반 LLM은 인터넷의 방대한 글로 학습됐습니다. 일반 상식이나 위키피디아 내용은 잘 알죠. 하지만 다음 질문에는 약합니다.

• 우리 회사 내부 규정 (학습 안 됨)
• 어제 발표된 신제품 정보 (학습 시점 이후)
• 비공개 문서나 사내 매뉴얼 (절대 학습 못 함)

이런 질문에 LLM은 두 가지 잘못된 반응을 보입니다.

1. 모른다고 답하기​

"죄송합니다, 그 정보는 알 수 없습니다"라고 솔직하게 답하면 그나마 다행입니다.

2. 그럴듯하게 지어내기​

문제는 LLM이 그럴듯하게 거짓말 한다는 점입니다. 마치 알고 있는 것처럼 답하는데, 사실은 만들어낸 정보죠. 이걸 할루시네이션(hallucination) 이라고 부릅니다.

도서관 사서 이야기​

상상해봅시다. 친구가 어떤 분야의 전문가인데, 우리 회사에 대해선 전혀 모릅니다. 그 친구에게 "우리 회사 휴가 정책 좀 알려줘"라고 묻는 게 LLM에 묻는 것과 같습니다.

이번엔 친구를 도서관에 데려갑니다. 사서가 회사 규정집을 찾아 친구에게 건넵니다. "이 책에 답이 있을 거예요." 친구는 책을 읽고 답합니다. "휴가는 입사 1년 후부터 15일이고, 사용은 이렇게 신청하면 됩니다."

이게 바로 RAG의 핵심 아이디어 입니다.

1. 사용자 질문이 들어오면 → 사서가 관련 자료를 찾아옴
2. 그 자료를 → 전문가(LLM) 에게 함께 건네줌
3. LLM은 자료를 보고 답함 → 정확한 답이 나옴

RAG는 어떻게 동작하나​

좀 더 구체적으로 단계를 보겠습니다.

1단계: 자료를 미리 정리해두기​

사서가 자료를 빨리 찾으려면, 책장이 잘 정리돼 있어야 합니다. RAG도 마찬가지입니다.

회사의 모든 문서(매뉴얼·정책·FAQ·메일)를 작은 조각으로 자르고, 각 조각을 벡터(vector) 라는 숫자 묶음으로 변환합니다. 이 숫자는 그 문장의 "의미"를 표현합니다.

비슷한 의미의 문장은 비슷한 숫자가 되도록 학습된 거죠. "휴가 신청 방법"과 "연차 사용법"은 글자는 다르지만 의미가 가까우니, 비슷한 벡터가 됩니다.

2단계: 질문이 들어오면 비슷한 자료 찾기​

사용자가 "휴가 어떻게 써?"라고 물으면, 이 질문도 벡터로 변환합니다. 그리고 미리 저장해둔 문서 벡터들 중에서 가장 비슷한 의미 의 것들을 찾습니다.

이런 데이터베이스를 벡터 DB 라고 부릅니다. 도서관의 도서 분류 카드와 비슷한 역할을 하죠. "휴가 신청 절차"가 적힌 사내 위키 문단이 검색됩니다.

3단계: LLM에게 자료와 함께 질문​

이제 LLM에게 이렇게 부탁합니다.

"다음 자료를 참고해서 사용자 질문에 답해줘.

[참고 자료] 사내 휴가 신청은 그룹웨어 → 인사 → 휴가 신청 메뉴에서...

[질문] 휴가 어떻게 써?"

LLM은 자료를 읽고 사용자 질문에 맞게 정리해서 답합니다.

"그룹웨어에 로그인한 후 인사 → 휴가 신청 메뉴로 들어가시면 됩니다. 먼저 휴가 종류를 선택하고..."

자료에 없는 내용은 만들어내지 않습니다. "참고 자료에는 그 내용이 없습니다"라고 답하도록 설정할 수 있죠.

왜 "검색"과 "생성"을 합쳤을까​

각각의 한계가 있기 때문입니다.

전통적인 검색 (예: 사내 위키 검색)

• 정확한 키워드가 있어야 함
• "휴가" 검색 → 휴가 관련 모든 문서 나열, 사용자가 직접 읽어야 함
• 자연스러운 답변은 못 함

LLM만 사용

• 자연스러운 대화는 가능
• 하지만 우리 회사 정보는 모름
• 그럴듯한 거짓말 위험

RAG = 검색 + 생성

• 우리 회사 정보를 정확히 가져옴 (검색의 강점)
• 사람이 읽기 좋게 정리해 답함 (생성의 강점)
• 자료에 근거하니 거짓말이 줄어듦

실제로 어디에 쓰이나​

사내 지식 챗봇​

신입 사원이 사내 위키를 뒤지지 않고 챗봇에 바로 물어봅니다. "출장비 정산 어떻게 해?", "VPN 접속이 안 돼", "회의실 예약 방법" 같은 일상적인 질문이 즉시 해결됩니다.

고객 지원​

고객이 제품 문의를 하면, RAG가 매뉴얼·FAQ·과거 응대 기록에서 답을 찾아 응답합니다. 24시간 동작하면서, 복잡한 문의만 사람 상담원에게 넘겨주죠.

법률·의료·금융 같은 전문 분야​

방대한 규정이나 논문에서 정확한 정보를 찾는 게 핵심인 분야입니다. 변호사가 판례를 검색하고 정리하는 시간을 크게 줄일 수 있습니다.

RAG를 잘 쓰려면​

1. 자료가 깨끗해야 한다​

쓰레기 자료를 검색해서 LLM에 넘기면, 쓰레기 답이 나옵니다. 사내 문서가 잘 정리돼 있어야 RAG가 잘 동작합니다.

2. 적절한 자료 양 찾기​

너무 적게 찾으면 답이 부족하고, 너무 많이 찾으면 LLM이 핵심을 놓칩니다. 보통 3~5개 문단 정도가 적당합니다.

3. 답변에 출처 표시​

"이 답변은 [사내 휴가 정책 v3.2]를 기반으로 했습니다"처럼 출처를 함께 보여주면, 사용자가 신뢰하고 검증할 수 있습니다.

마치며​

RAG는 마법이 아닙니다. "검색해서 그 자료를 보고 답한다" — 사람이 평소에 하는 일을 자동화한 것뿐이죠. 미니소프트는 RAG를 활용한 사내 지식 시스템과 고객 응대 챗봇을 구축하며, AI가 실제 업무에 어떻게 녹아들 수 있는지 매일 실험하고 있습니다.

참고 자료​

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Azure AI Search: Vector search overview