홍창우

보안 공지를 확인하는 것과 대응을 마치는 것은 다르다.

MiWork Guard는 어디가 문제인지 찾고, 무엇부터 고칠지 정리하고, 조치 결과를 다시 검증한다. AI는 근거와 위험을 정리하고, 관리자는 필요한 대응을 판단한다. 그 과정은 신뢰할 수 있는 기록으로 남는다.¹²

제품의 목적을 표현한 삽화. 실제 화면은 아니다. 본문의 이미지를 클릭하면 원본을 볼 수 있다.

왜 지금 필요한가​

AI는 공격자가 보안의 약점을 찾아 악용하는 속도와 규모도 키울 수 있다. 새로운 위협에 대비하는 한편, 이미 알려진 위험을 줄이는 기본 관리가 중요해지는 이유다.³

최근 사례도 같은 과제를 남긴다.

• GitLab은 2026년 10월 12일 중요한 보안 문제의 수정본을 공개하고 빠른 업데이트를 권고했다.⁴
• LiteLLM의 10월 21일 배포물 침해 사건 조사에서는 과거 노출된 관리자 키가 폐기되지 않았던 사실이 드러났다.⁵

수정 방법이 나온 취약점은 보안 업데이트를 제때 적용하는 것만으로도 해당 공격 경로를 막을 수 있다. 다만 업데이트 외의 대응이 필요한 문제도 있다. NIST가 설명하는 ‘예방 정비’ 역시 필요한 수정본의 적용과 결과 확인을 포함한다.⁶

현실의 어려움은 그다음이다. 구매한 제품부터 오픈소스와 라이브러리까지, 공지와 적용 시점이 제각각이다. 우리 회사가 영향을 받는지, 누가 무엇을 처리했고 어떤 일이 남았는지 빠짐없이 따라가기는 쉽지 않다.

무엇을 먼저 고칠지 정리한다​

MiWork Guard는 서버에서 확인한 프로그램과 구성요소를 보안 정보와 대조해 할 일을 정리한다. 관리자가 보고서에서 찾는 답은 세 가지다.¹⁷

• 어디에 있는 프로그램이 문제인가 — 위치와 현재 버전
• 무엇부터 바꿔야 하나 — 목표 버전과 작업별 우선순위
• 바로 고칠 수 있나 — 수정판 유무와 실제 사용 여부를 확인할 항목

AI는 수집 자료를 검토하고 추가로 살펴볼 위험을 정리한다. 서버를 임의로 변경하는 것이 아니라, 관리자의 판단을 돕는 역할이다.¹

긴 경고 목록을 실제로 처리할 작업으로 바꾸는 것. 조치 계획과 작업 목록은 보고서나 엑셀에서 열 수 있는 파일로 저장해 담당자와 공유할 수 있다.⁷

실제 조치 계획 화면. 내부 식별 정보는 제외했다.

조치 결과를 다시 검증하고 기록한다​

점검의 ‘완료’가 업데이트의 완료를 뜻하지는 않는다. 담당자가 실제 조치를 수행한 뒤, MiWork Guard로 다시 점검해 변경이 반영됐는지와 앞서 발견한 문제가 남았는지 확인한다.¹⁷²

최초 점검 결과, 처리 내역, 재검증 결과를 연결하면 무엇을 발견했고 어떻게 대응했으며 이후 무엇이 달라졌는지 확인할 수 있다. 신뢰의 근거는 기록의 존재가 아니라, 조치 결과를 다시 검증했다는 데 있다.²

위변조 방지는 이렇게 확인한 기록을 보호한다. 남은 문제와 확인하지 못한 범위도 함께 남겨 다음 점검과 인수인계의 근거로 삼는다. 확인된 범위 밖의 안전까지 보장하는 것은 아니다.¹²

실제 작업 이력의 일부. 내부 식별 정보는 제외했다.

현재 점검 대상은 Linux 서버와 실행 중인 Docker 컨테이너다. 실제 업데이트는 담당자가 수행하며, 점검하지 못한 영역은 ‘부분 확인’이나 ‘미검사’로 구분한다.¹⁷

보안의 기본을 몰라서가 아니라, 챙겨야 할 것이 너무 많아 놓치는 일이 있다. 그 빈틈을 줄이고, 조치와 재검증까지 이어가는 것. MiWork Guard가 필요한 이유다.

참고 자료​

핵심 요약 On-Sitehub의 AI 위험성평가 검토는 협력사별 평가 항목을 읽고 적정·보완필요·부적정으로 분류합니다. 재해유형, 위험요인, 개선대책, 위험등급이 작업 맥락에 맞는지 검토하고 판단 의견과 수정 제안을 함께 보여줍니다. 안전관리자는 현재 값과 AI 제안을 비교해 필요한 항목만 선택하여 반영하며, 최종 판단과 완료 처리는 담당자가 수행합니다.

협력사 위험성평가서가 한꺼번에 들어오는 날이면 안전관리자는 비슷한 문장을 반복해서 읽습니다.

재해유형과 위험요인이 서로 맞는지, 개선대책이 그 위험을 실제로 낮출 수 있는지, 위험등급이 적절한지 확인해야 합니다. 중공종, 세부공종, 작업 위치와 인원까지 함께 살피려면 문서마다 형식과 표현이 다른 점도 부담이 됩니다.

항목이 많아질수록 누락 가능성이 커지고, 담당자의 경험이나 검토 순서에 따라 먼저 보는 항목도 달라질 수 있습니다.

이때 AI가 먼저 맡는 일은 승인이나 결재가 아닙니다. 검토가 필요한 항목을 분류하고, 안전관리자가 비교할 근거와 제안을 정리하는 일입니다.

위험성평가 검토 흐름​

On-Sitehub에서는 현장 설정에 따라 협력사별 위험성평가 자료를 엑셀로 등록하거나 화면에서 직접 입력할 수 있습니다. 일부 양식은 여러 협력사 자료를 한 번에 올린 뒤 협력사별 문서로 나누어 처리할 수도 있습니다.

실제 제품의 문서 목록 구조를 참고한 예시 화면입니다. 현장명·협력사·문서명·회차·항목 수는 모두 가상 데이터이며, 검토 전 문서 목록을 보여줍니다.

모바일에서는 흐름도를 좌우로 밀어 확인할 수 있습니다.

1. 등록과 AI 검토

2. 비교와 담당자 완료

AI는 각 항목의 다음 내용을 함께 살펴봅니다.

• 재해유형이 위험요인의 내용과 맞는가
• 위험요인이 중공종·세부공종·작업 위치·작업인원 맥락에서 구체적인가
• 개선대책이 위험을 실질적으로 줄이고 현장에서 실행 가능한가
• 위험등급이 발생 가능성과 중대성에 비추어 적절한가

검토가 끝나면 항목은 세 단계로 표시됩니다.

• 적정: 입력된 문서 기준으로 그대로 사용할 수 있다고 판단한 항목
• 보완필요: 방향은 맞지만 구체성, 누락 대책 또는 위험등급 등의 부분 보완이 필요한 항목
• 부적정: 재해유형과 위험요인이 맞지 않거나 개선대책의 실효성이 부족해 재작성이 필요한 항목

이 분류는 법 위반 여부를 확정하거나 현장 조치의 적정성을 보증하는 결과가 아닙니다. 업로드된 내용 안에서 문서의 구체성, 일관성, 실행 가능성을 검토한 보조 의견입니다.

판정과 수정 제안​

AI 검토 결과에는 항목별 판정과 검토 의견뿐 아니라 필요에 따라 다음 제안이 함께 표시됩니다.

• 재해유형 변경 제안
• 위험등급 조정 제안
• 개선대책 보완 제안

안전관리자는 화면에서 현재 값과 AI 제안 값을 나란히 비교할 수 있습니다. 제안 전체를 그대로 받아들이는 방식이 아니라, 재해유형·위험등급·개선대책 가운데 필요한 필드만 선택해 입력란에 반영합니다. 반영 전에는 변경 전후 값을 다시 확인할 수 있고, 저장하지 않았다면 되돌릴 수도 있습니다.

여러 항목을 처리할 때는 보완필요·부적정 항목을 모아 보고, 적용할 항목과 필드를 선택해 일괄 반영할 수 있습니다. 사람이 선택하고 저장하기 전까지 원문은 자동으로 바뀌지 않습니다.

실제 제품의 비교 화면을 참고한 가상 사례입니다. 표시된 작업 내용과 AI 제안은 설명용 예시이며, 실제 현장 데이터나 판정 결과가 아닙니다.

주요 검토 사례​

아래 사례는 기능의 검토 방식을 설명하기 위한 예시입니다. 실제 판정과 제안은 입력된 문서와 현장별 검토 기준에 따라 달라질 수 있습니다.

이동식 크레인​

이동식 크레인 작업의 개선대책에 ‘작업반경 내 출입 통제’라고만 적혀 있다고 가정해 보겠습니다.

AI는 누가, 어디에서, 어떤 방식으로 출입을 통제할지 확인하기 어려운 점을 보완 대상으로 표시할 수 있습니다. 안전관리자는 장비 제원, 작업 위치와 당일 동선을 확인한 뒤 실제 적용할 조치를 정합니다.

고소작업​

고소작업 항목에 ‘안전대 착용’만 적혀 있다면 추락 위험에 대한 대책이 충분히 구체적이지 않을 수 있습니다.

AI는 재해유형과 위험요인의 일치 여부, 작업 위치 정보의 구체성, 개선대책의 실행 가능성, 위험등급을 함께 검토하고 필요한 보완 의견을 제시할 수 있습니다.

화기작업​

화기작업 평가서에 ‘소화기 비치’만 적혀 있다면 조치의 범위가 좁을 수 있습니다.

AI는 위험요인에 비해 개선대책이 충분한지 검토하고 추가 확인이 필요한 내용을 제안할 수 있습니다. 실제 조치는 작업 장소, 주변 설비와 사용 물질을 확인한 뒤 안전관리자가 결정합니다.

변경 항목 재검토​

AI 검토가 끝난 뒤 담당자가 항목을 직접 수정하면 해당 문서는 재검토필요 상태가 됩니다. 이때 전체 문서를 처음부터 다시 분석하지 않고 변경된 항목만 골라 재검토할 수 있습니다. AI 제안을 선택 적용한 경우에는 적용 내용과 출처가 이력으로 남습니다.

검토 화면에서는 적정·보완필요·부적정 건수를 바로 확인하고 판정별로 항목을 걸러 볼 수 있습니다. 문서 전체에 대해서는 종합 검토 의견과 핵심 지적사항도 확인할 수 있습니다. 결과는 인쇄용 AI 검토 보고서와 엑셀 파일로 출력할 수 있어 검토 기록을 공유하거나 보관할 때 활용할 수 있습니다.

완료본 관리​

해당 기능을 사용하는 현장 설정에서는 AI 검토가 끝난 사전검토 문서를 담당자가 완료 처리할 수 있습니다. 완료 처리된 내용은 별도의 완료본으로 생성되며, 협력사의 최신 완료본은 TBM 일지의 ‘위험성 평가 DB’에서 조회할 수 있습니다.

완료 처리는 AI의 자동 승인과 다릅니다. AI는 항목을 분류하고 수정 후보를 제안하지만, 어떤 제안을 반영할지와 사전검토를 완료할지는 담당자가 결정합니다.

최종 판단은 사람이 합니다​

위험성평가서에 적힌 내용만으로는 알 수 없는 정보가 있습니다. 당일 날씨, 작업자 숙련도, 장비 상태, 동시에 진행되는 다른 작업과 현장 동선은 문서 밖에 있을 수 있습니다.

AI가 문장을 잘 정리해도 실제 설치 상태나 작업 조건까지 자동으로 확인한 것은 아닙니다. 입력 내용이 부족하거나 잘못되어 있으면 분석 결과도 제한됩니다. 따라서 AI의 1차 검토는 다음 사항을 확인하는 출발점으로 사용해야 합니다.

• 검토 의견이 제출 문서의 어떤 내용에 근거하는가
• 제안한 대책을 실제 작업 위치와 장비에 적용할 수 있는가
• 위험등급 조정이 현장 기준에 맞는가
• 문서 밖의 현장 조건을 추가로 확인해야 하는가

적정으로 표시된 항목도 현장 확인 대상에서 제외되는 것은 아닙니다. 공종, 장비, 작업 위치나 작업 조건이 달라졌다면 다시 확인해야 합니다. AI 분류는 검토 순서를 돕는 기준이지 검토 범위를 줄이는 기준이 아닙니다.

AI를 1차 검토에 사용하면 반복적인 항목 확인과 보완 후보 정리를 먼저 맡길 수 있습니다. 안전관리자는 현장을 아는 사람만이 할 수 있는 확인과 최종 판단에 더 집중할 수 있습니다.

이 기능은 현장 위험성평가 절차와 참여자의 책임을 대체하지 않습니다. 사업장에 적용되는 법령과 역할 분담에 따라 담당자가 평가를 실시하고 확인·기록해야 하며, AI 검토 결과는 그 과정을 돕는 참고 자료입니다. 협력사 문서의 처리 범위와 보관 기준도 도입 전에 확인해야 합니다.

현장별 적용 범위​

엑셀 양식과 업로드 방식, 사전검토 완료 처리, 완료본 활용 범위는 현장 설정에 따라 달라질 수 있습니다. AI의 검토 관점과 3단계 판정 기준도 운영 정책에 맞게 설정될 수 있으므로, 실제 제공 범위와 적용 시점은 도입 협의에서 확인해야 합니다.

On-Sitehub 살펴보기

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 Agents는 AI에게 질문하는 채팅 화면에서 출발해, 이제 사람과 AI가 같은 공간에서 대화하고 지식을 정리하며 업무 도구를 실행하는 AI 협업 워크스페이스로 고도화되었습니다. 이번 글에서는 새로워진 채널·1:1 대화·위키·공유 챗봇·지식베이스·MCP와 기업용 운영 기능을 소개합니다.

AI에게 묻지만 말고, AI와 함께 일하자​

기업에서 AI를 처음 사용할 때는 보통 개인 채팅으로 시작합니다. 사용자가 질문을 입력하고 AI가 답합니다. 빠르고 편리하지만, 답변이 개인 대화 안에만 남으면 팀의 지식이나 업무 흐름으로 이어지기 어렵습니다.

실제 업무에는 AI와의 대화만 있는 것이 아닙니다. 동료와 논의하고, 파일을 공유하고, 결정한 내용을 문서로 남기고, 필요한 시스템을 실행해야 합니다. 그래서 MiWork Agents의 범위를 단순한 AI 채팅에서 사람·AI·지식·도구가 함께 있는 협업 공간으로 넓혔습니다.

Case Study: 업무는 이렇게 달라집니다​

이번 고도화의 의미는 AI 기능을 하나 더 추가한 데 있지 않습니다. 채널, 위키, 지식베이스, 공유 챗봇과 MCP를 연결해 사람들이 일하는 공간에 AI가 실제로 참여할 수 있도록 협업 기능을 확장한 데 있습니다. 다음 두 케이스는 새 기능들이 실제 업무에서 어떻게 연결되는지 보여줍니다.

AI와 사람이 함께 일한다는 것은 AI가 업무를 대신 처리한다는 뜻이 아닙니다. 사람들이 가진 현장 경험과 판단에 AI의 지식 검색과 맥락 정리 능력을 더해 혼자서는 놓치기 쉬운 내용을 함께 확인하는 방식입니다.

Case Study 1. “이 기능을 왜 이렇게 결정했지?”​

새로 프로젝트에 참여한 개발자가 채널에서 묻습니다.

“모바일에서는 왜 이 기능을 제외했나요?”

몇 달 전 논의에 참여했던 담당자들도 당시 결정의 정확한 이유를 바로 기억하지 못합니다. 새로운 팀원은 이전 채널 대화와 여러 문서를 모두 읽어야 하고, 기억에 의존한 설명은 중요한 조건을 빠뜨릴 수 있습니다.

팀은 AI를 현재 대화에 참여시킵니다. AI는 현재 채널에서 확인할 수 있는 이전 대화와 접근이 허용된 위키·지식베이스·기술 문서를 바탕으로 당시의 요구사항, 제약 조건과 선택 이유를 정리합니다. 기존 담당자는 AI가 찾은 내용이 실제 상황과 맞는지 확인하고, 새로운 팀원은 현재 조건이 달라진 부분을 질문합니다.

사람들은 기존 결정을 유지할지 다시 설계할지 함께 판단합니다. 결정이 바뀌면 AI는 새로 합의한 내용뿐 아니라 왜 변경했는지까지 위키에 남기도록 돕습니다.

Case Study 2. 현장과 본사가 함께 설비 문제를 해결할 때​

현장 작업자가 모바일에서 설비 사진과 증상을 채널에 올립니다.

“평소보다 진동이 심하고 온도가 빠르게 올라갑니다.”

본사의 기술 담당자는 작업자에게 소음이 시작된 시점, 최근 교체 부품과 현재 계기값을 추가로 확인해 달라고 요청합니다. 동시에 AI는 접근이 허용된 설비 매뉴얼과 과거 정비 기록에서 비슷한 증상, 점검 항목과 주의사항을 찾습니다.

현장 작업자는 AI가 제시한 정보를 실제 설비 상태와 비교해 결과를 공유합니다. 본사 기술 담당자는 현장의 관찰과 조직의 정비 지식을 함께 검토해 안전한 조치 범위를 결정합니다. AI가 위험한 작업을 스스로 결정하거나 실행하지는 않습니다.

조치가 끝나면 AI는 확인한 증상, 판단 근거, 수행한 조치와 결과를 정리합니다. 사람이 검토한 기록은 위키나 정비 이력으로 남기고, 필요한 부품과 후속 점검은 권한이 적용된 업무 도구에 등록할 수 있습니다.

1. 채널과 1:1 대화​

MiWork Agents 안에서 팀은 주제별 채널을 만들고 대화를 이어갈 수 있습니다. 동료와의 1:1 대화와 그룹 대화도 같은 환경에서 사용할 수 있습니다.

채널과 대화에는 다음 협업 기능이 포함됩니다.

• 주제별 공개·비공개 채널
• 동료 검색과 1:1·그룹 대화
• 메시지 반응과 스레드
• 멤버와 고정 메시지 관리
• 대화 중 AI 호출과 AI 초대

AI를 사용하기 위해 협업 화면을 떠날 필요가 없습니다. 사람이 논의하던 문맥 안으로 AI를 불러와 내용을 요약하거나 다음 작업을 요청하는 흐름을 만들 수 있습니다.

2. AI 대화와 작업 파일​

개인 AI 대화도 계속 MiWork Agents의 중요한 기능입니다. 사용자는 새 대화를 시작하고 문서와 이미지를 첨부해 질문할 수 있습니다.

현재 대화 화면은 다음 기능을 제공합니다.

• 지식베이스와 첨부 파일을 활용한 답변
• PDF, DOCX, HWP/HWPX와 이미지 첨부
• 대화별 작업 문서와 파일
• 음성 대화 진입
• 대화 즐겨찾기와 공유 링크
• 텍스트 서식과 대화 기록 관리

대화에 첨부한 파일과 개인 작업공간의 파일을 정리할 수 있으며, 조직이 함께 검색해야 하는 문서는 별도의 지식베이스로 연결합니다.

3. 대화를 공동 위키로​

좋은 대화도 채팅 기록 속에만 있으면 시간이 지나면서 찾기 어려워집니다. MiWork Agents의 위키는 채널에서 논의한 내용을 문서로 정리하고 공동으로 편집하는 공간입니다.

회의 내용, 결정 사항, 후속 작업과 참고 자료를 하나의 문서로 남길 수 있습니다. 문서를 가져오거나 내보내는 기능과 블록 기반 편집도 제공합니다.

채널에서 논의
  ↓
AI로 내용 정리
  ↓
위키 문서로 등록
  ↓
팀이 공동 편집하고 다시 활용

AI가 답변을 만드는 데서 끝나지 않고, 팀이 다시 사용할 수 있는 지식으로 남기는 것이 핵심입니다.

4. 팀별 지식베이스​

지식베이스에서는 문서를 업로드하고 팀별 읽기·수정 권한을 관리합니다. 사용자는 자신에게 허용된 지식베이스만 검색할 수 있습니다.

• 문서 업로드와 처리 상태 확인
• 지식베이스별 공개 범위
• 팀 단위 읽기·수정 권한
• 연결 문서 조회와 관리
• AI 답변의 근거 문서 활용

조직의 모든 문서를 AI에게 무조건 공개하는 방식이 아니라, 기존 업무 권한과 책임 범위 안에서 검색하도록 설계합니다.

5. 공유 챗봇​

팀이나 외부 사용자가 반복적으로 묻는 질문에는 목적별 공유 챗봇을 만들 수 있습니다. 챗봇마다 사용할 지식베이스와 공개 범위, 웹 검색 허용 여부를 따로 지정합니다.

공유 챗봇은 개인 AI 환경과 분리해 운영합니다. 개인 메모리나 개인 MCP 연결을 그대로 노출하지 않고, 챗봇에 명시적으로 연결된 지식과 기능만 사용합니다.

이를 통해 사내 업무 안내, 규정 검색, 제품 소개, 고객용 FAQ처럼 목적이 분명한 AI 접점을 구성할 수 있습니다.

6. MCP로 업무 도구 연결​

MiWork Agents는 답변만 생성하는 AI를 넘어 조직의 실제 업무 도구와 연결되도록 MCP를 지원합니다.

관리자는 조직 공통 MCP를 등록하고, 사용자는 필요한 경우 자신의 계정으로 인증합니다. AI는 허용된 도구 안에서 정보를 조회하거나 업무를 실행할 수 있습니다.

중요한 점은 도구를 많이 연결하는 것이 아니라 누가 어떤 도구를 어떤 권한으로 사용하는지 관리하는 것입니다. 조직 공통 연결과 개인 인증을 분리해 운영하는 이유도 여기에 있습니다.

7. 기업 운영을 위한 관리 기능​

AI 협업 플랫폼은 채팅 화면만으로 운영할 수 없습니다. MiWork Agents에는 조직이 AI 사용을 관리하기 위한 콘솔이 함께 제공됩니다.

• 사용자 계정과 플랫폼 역할
• 팀 구성과 팀별 멤버 역할
• 개인·팀·조직 예산과 사용량
• 채팅·임베딩 모델과 fallback 순서
• 공유 챗봇 생성·승인·운영
• 조직 정책과 접근 범위
• MCP 연결 상태
• 로그인·권한·콘텐츠 변경 감사 로그

관리자는 비용과 사용량을 확인하고, 조직에 사용할 모델과 예산 정책을 설정할 수 있습니다. 주요 변경과 인증 이벤트는 감사 기록으로 남습니다.

8. 데스크톱과 모바일에서 같은 협업 흐름​

MiWork Agents의 주요 협업 화면은 모바일에서도 사용할 수 있도록 구성했습니다. 채널, 대화, AI와 위키를 하단 내비게이션으로 이동하고, 작은 화면에서도 대화 목록과 작성 영역이 가로 스크롤 없이 표시됩니다.

현장에서 문서를 확인하거나 이동 중 대화를 이어갈 때도 데스크톱과 같은 업무 문맥을 유지하는 것이 목표입니다.

하나의 제품에서 이어지는 업무 흐름​

확장된 기능을 하나의 흐름으로 정리하면 다음과 같습니다.

사람들이 채널에서 논의한다
  ↓
AI를 대화에 초대해 내용을 정리한다
  ↓
근거가 필요한 질문은 지식베이스에서 찾는다
  ↓
결정과 후속 작업을 위키에 남긴다
  ↓
필요한 업무는 MCP로 연결된 도구에서 실행한다
  ↓
관리자는 권한·예산·모델·감사 기록을 관리한다

마치며​

이번 업데이트를 통해 MiWork Agents는 사람과 AI가 함께 일하는 AI 협업 워크스페이스로 한 단계 더 확장되었습니다.

AI가 사람의 대화를 대신하는 제품이 아니라, 사람이 동료와 협업하는 공간에 AI가 함께 들어와 지식을 찾고 문서를 만들며 필요한 도구를 실행하는 제품을 만들고 있습니다.

MiWork Agents 살펴보기

핵심 요약 미니소프트의 업무 솔루션 브랜드 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 기능을 하나 더 붙인 화면이 아닙니다. 문서가 지식이 되고, 지식이 실행으로 이어지고, 필요한 도구가 조직 안에서 안전하게 운영되는 흐름입니다.

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

핵심 요약 LUMINUS는 MiWork Agents로, MiniApp Hub는 MiWork VibeHub로 명칭이 바뀝니다. MiWork는 미니소프트가 AI로 만드는 업무 제품군의 통합 브랜드입니다.

무엇이 바뀌나​

왜 바꿨나​

하나로 부를 이름이 없었습니다. 제품을 소개할 때마다 목록을 읽어야 했습니다. "AI Agent 플랫폼이 있고, 미니앱 플랫폼이 있고…" 목록은 각 제품이 무엇인지는 전달하지만, 이 회사가 AI로 무엇을 하는 회사인지는 전달하지 못합니다.

이름이 제품을 설명하지 못했습니다. LUMINUS는 빛을 뜻하는 라틴어에서 온 이름입니다. 부르기 좋았지만 이름만 듣고 무엇을 해주는 제품인지 알 수 있는 사람은 없었고, 소개하는 자리마다 설명을 한 줄 먼저 붙여야 했습니다. MiWork는 Work가 이름 안에 이미 들어 있습니다.

'미니앱'이라는 말이 좁아졌습니다. 이제는 현업 담당자가 AI에게 필요한 것을 설명하면 원가 계산기나 입찰 분석기가 짧은 시간에 나옵니다. 흔히 바이브코딩이라 부르는 흐름입니다. 이렇게 만들어진 앱은 작아서 미니앱인 것이 아니라, 만들어지는 속도와 방식이 달라진 것입니다. VibeHub는 그 변화를 이름에 담았습니다.

지금은 둘입니다​

MiWork라는 이름을 함께 쓰는 제품은 Agents와 VibeHub 둘입니다. 앞으로 AI를 쓰는 업무 제품이 늘어나면 같은 체계 안에 들어올 수 있지만, 어떤 제품이 언제 합류할지는 아직 정하지 않았습니다.

지난 글과 링크는 이렇게 정리했습니다​

• 이미 발행된 글은 본문 표기를 새 명칭으로 바꾸고, 각 글 상단에 이전 명칭을 함께 적어 두었습니다.
• 글 주소(URL)는 바꾸지 않았습니다. 저장해 두신 링크와 외부 기사에서 들어오는 경로가 그대로 열립니다.
• 화면 캡처와 가이드 영상에는 아직 이전 명칭이 남아 있습니다. 순차적으로 교체하겠습니다.
• 언론에 소개된 기사는 발행 시점의 명칭을 그대로 둡니다.

마치며​

이름을 바꾼다고 제품이 좋아지지는 않습니다. 검색했을 때 우리를 찾을 수 있게 하고, 여러 제품이 한 식구라는 것을 설명 없이 알려주는 것 — 이름이 하는 일은 그 정도입니다.

핵심 요약 AI 시대의 업무 플랫폼은 ERP나 그룹웨어만이 아니라, 엑셀·매크로·Python·AI Agent·바이브코딩 앱처럼 흩어진 업무 자산을 함께 관리해야 합니다. MiWork VibeHub는 만들어진 도구를 검색, 공유, 설치, 운영할 수 있는 회사의 업무 자산 플랫폼을 지향합니다.

엑셀 파일부터 바이브코딩 앱까지, 흩어진 업무 자산을 연결하는 방법​

기업은 오랫동안 업무를 디지털화하기 위해 ERP, 그룹웨어, MES, CRM과 같은 시스템을 도입해 왔습니다. 각각의 시스템은 중요한 역할을 해 왔고, 지금도 많은 조직의 핵심 업무를 지탱하고 있습니다.

하지만 생성형 AI와 코딩 에이전트가 등장하면서 회사 안의 업무 도구는 더 빠르게, 더 작게, 더 많이 만들어지고 있습니다. 이제 문제는 "업무 앱을 만들 수 있는가"가 아니라 "만들어진 수많은 업무 앱을 어떻게 회사의 자산으로 남길 것인가"에 가까워지고 있습니다.

업무는 점점 더 작아지고 있다​

과거에는 업무 시스템 하나를 만들기 위해 긴 프로젝트가 필요했습니다. 요구사항을 정리하고, 예산을 확보하고, 개발과 테스트를 반복해야 했습니다.

지금은 다릅니다. 생성형 AI와 코딩 에이전트를 활용하면 현업 담당자도 자신이 필요한 업무 도구를 직접 만들 수 있습니다.

회의록 정리 앱, 구매 요청 앱, 견적 생성기, 입찰 분석기, 원가 계산기, 계약 검토 도구처럼 작지만 실질적인 업무 앱이 빠르게 만들어질 수 있습니다.

회사 안에는 이미 수많은 업무 자산이 있다​

대부분의 기업에는 공식 시스템 밖에서도 중요한 업무가 돌아가고 있습니다.

• 원가 계산 엑셀
• 견적 생성 매크로
• 재고 관리 파일
• 품질 분석 스크립트
• 입찰 분석 도구
• 계약 검토 에이전트
• 바이브코딩으로 만든 내부 웹앱

이 도구들은 실제 업무를 움직입니다. 하지만 개인 PC, 공유 폴더, 메신저 대화방, 이메일 첨부파일 속에 흩어져 있는 경우가 많습니다.

앞으로의 문제는 앱이 부족한 것이 아니다​

AI는 앱을 만드는 비용을 크게 낮추고 있습니다. 앞으로는 한 명의 직원이 여러 개의 업무 앱을 만들 수 있고, 부서마다 새로운 도구가 계속 생겨날 수 있습니다.

과거의 문제는 시스템이 부족한 것이었습니다. 앞으로의 문제는 시스템과 앱이 너무 많아지는 것일 수 있습니다.

그때 기업이 물어야 할 질문은 달라집니다.

• 누가 만들었는가?
• 어디에 있는가?
• 누가 사용하고 있는가?
• 최신 버전은 무엇인가?
• 퇴사나 조직 변경 이후에도 유지될 수 있는가?

개인의 도구는 회사의 자산이 될 수 있을까?​

좋은 아이디어는 개인에게서 시작되는 경우가 많습니다. 하지만 개인의 노트북에만 남아 있으면 조직의 자산이 되기 어렵습니다.

한 사람이 만든 도구가 팀으로 공유되고, 팀에서 검증된 도구가 전사로 확산되려면 등록, 검색, 설치, 운영, 피드백 구조가 필요합니다.

MiWork VibeHub를 예로 들면​

MiWork VibeHub 같은 기업용 미니앱 플랫폼은 이런 흐름을 지원하기 위한 하나의 방식입니다.

엑셀 기반 업무 도구, 스크립트, AI Agent, 바이브코딩으로 만든 웹앱까지 회사가 활용할 수 있는 업무 자산으로 등록할 수 있습니다.

사용자는 필요한 도구를 검색하고 설치합니다. 회사는 누가 어떤 앱을 사용하고 있는지, 어떤 버전이 운영 중인지, 어떤 앱이 많이 쓰이는지 관리할 수 있습니다.

미래의 경쟁력은 업무 자산의 축적이다​

AI는 앞으로 더 많은 업무 도구를 만들 것입니다. 중요한 것은 얼마나 많은 앱을 만들 수 있는가가 아닙니다.

만들어진 앱을 얼마나 잘 공유하고, 얼마나 잘 운영하고, 얼마나 오래 조직의 자산으로 남길 수 있는가가 더 중요합니다.

기업의 경쟁력은 시스템의 수가 아니라 업무 자산의 축적에서 만들어질 수 있습니다.

마치며​

AI는 소프트웨어 개발을 민주화하고 있습니다. 누구나 업무 앱을 만들 수 있는 시대가 오고 있습니다.

이제 기업의 과제는 앱을 만드는 것이 아닙니다. 만들어진 수많은 업무 자산을 어떻게 연결하고 관리할 것인가입니다.

핵심 요약 MiWork VibeHub는 개인이나 부서 안에 머무르던 업무 앱을 회사가 공유하고 관리할 수 있는 자산으로 바꾸는 플랫폼입니다. 앱스토어, 설치 현황, 사용 현황, 권한과 버전 관리를 통해 작은 업무 아이디어가 조직 전체로 확산되도록 돕습니다.

누구나 만들고, 모두가 사용하고, 회사가 관리하는 기업용 미니앱 플랫폼.

Enterprise Proposal · 2026

문제 정의​

기업 안에는 이미 많은 업무 도구가 있습니다. 부서별로 만든 점검 앱, 보고서 자동화 도구, 데이터 조회 화면, 챗봇, 신청서가 여기저기 흩어져 있습니다. 문제는 좋은 앱이 있어도 찾기 어렵고, 한 번 만든 앱이 전사로 확산되기 어렵다는 점입니다.

기존 업무앱 환경은 부서별로 따로 만들어지고 관리되는 경우가 많습니다. 링크, 파일, 도구가 흩어져 있고 이미 만들어진 유용한 앱도 발견되지 못합니다. 그 결과 비슷한 앱을 다시 만들고, 유지 비용은 늘어나며, 보안과 권한 관리 기준도 불분명해집니다.

MiWork VibeHub 소개​

MiWork VibeHub는 사내 미니앱을 앱스토어처럼 찾고, 설치하고, 개인 대시보드에서 바로 실행할 수 있게 만드는 기업용 미니앱 운영 플랫폼입니다.

MiWork VibeHub는 이 문제를 사내 앱스토어 구조로 풀어갑니다. 임직원은 필요한 앱을 검색하고 설치하며, 설치한 앱은 개인 대시보드에 자동으로 추가됩니다. 별점, 댓글, 인기순위는 좋은 앱이 자연스럽게 확산되는 기준이 됩니다.

솔루션 개요​

MiWork VibeHub가 만드는 효과​

사내에는 생각보다 많은 업무 도구가 존재합니다. 문제를 잘 아는 현업 담당자가 직접 정리한 엑셀, 반복 업무를 줄이기 위해 만든 작은 자동화 도구, 특정 부서에서만 쓰는 조회 화면처럼 이미 업무에 도움이 되는 자산이 곳곳에 있습니다.

MiWork VibeHub는 이런 도구가 개인 PC나 특정 부서 안에만 머무르지 않도록 공식 채널을 제공합니다. 핵심은 만들어진 업무 앱이 조직 안에서 발견되고 관리되고 계속 쓰이도록 만드는 것입니다.

• 좋은 업무 앱을 조직 전체로 공유할 수 있습니다.
• 개인이 만든 앱을 회사 자산으로 관리할 수 있습니다.
• 설치 현황과 사용 현황을 확인할 수 있습니다.
• 버전과 권한을 체계적으로 관리할 수 있습니다.
• 현장의 아이디어가 개인의 편의 도구로 끝나지 않고 조직의 디지털 자산으로 축적됩니다.

실제 화면​

App Store​

사내 앱스토어는 검증된 미니앱을 모아 놓는 공식 업무앱 카탈로그입니다. 사용자는 안전관리, 품질, 구매, 인사·총무, 보고 자동화 같은 카테고리로 앱을 찾고, 별점과 설치 수를 기준으로 비교할 수 있습니다.

Dashboard​

설치된 앱은 개인 대시보드에 자동으로 추가됩니다. 자주 쓰는 앱은 상단에 고정하고, 승인 요청·미완료 업무·보고서 현황 같은 알림도 한 화면에서 확인할 수 있습니다.

업무 앱 활용 예시​

현장 안전관리, 보고서 자동 생성, KPI 데이터 조회처럼 부서별 업무 앱을 카드 단위로 정리하면 어떤 앱이 실제 업무에 쓰이는지 빠르게 비교할 수 있습니다.

동영상으로 보기​

아래 영상은 MiWork VibeHub의 기본 화면 흐름을 빠르게 확인할 수 있는 가이드입니다.

보안과 거버넌스​

기업용 플랫폼에서 중요한 것은 편리함만이 아닙니다. MiWork VibeHub는 회사 계정 기반 SSO, 역할 기반 접근 제어, 설치·실행·접근 로그 관리, 앱 등록 승인 프로세스를 함께 다룹니다.

앱 제작자, 앱 오너, 승인자, 운영자, 리뷰관리자의 역할을 나누면 현업의 자율성과 회사의 통제 기준을 함께 가져갈 수 있습니다. 누구나 만들 수 있지만, 아무 앱이나 무분별하게 퍼지는 구조는 막는 것입니다.

기대 효과​

MiWork VibeHub를 도입하면 개인 PC나 특정 부서에 머무르던 업무 앱을 공식 채널로 모을 수 있습니다. 승인된 앱만 공개하고 사용량을 기반으로 운영하면 Shadow IT를 줄이고, 앱 공유를 활성화하며, 현장의 아이디어를 회사의 디지털 자산으로 관리할 수 있습니다.

임직원은 자주 쓰는 앱을 한 화면에서 실행하고 반복업무를 줄일 수 있습니다. 현업 부서는 아이디어를 빠르게 앱으로 만들고 우수 사례를 전사로 확산할 수 있습니다. IT·DX 조직은 사용량 기반으로 앱 포트폴리오를 관리할 수 있고, 경영진은 어떤 혁신 사례가 실제로 쓰이고 있는지 데이터로 확인할 수 있습니다.

마치며​

MiWork VibeHub의 목표는 앱을 많이 만드는 것이 아닙니다. 이미 만들어지고 있는 사내 미니앱을 찾기 쉽게 만들고, 안전하게 설치하게 하고, 실제 사용 데이터를 기반으로 좋은 앱이 확산되도록 만드는 것입니다.

현장의 작은 아이디어가 회사의 자산이 되려면, 만드는 도구만큼이나 모으고 운영하는 플랫폼이 필요합니다.

핵심 요약 InfraManager와 미나는 인프라 알람이 발생했을 때 서버, DNS, 인증서, 컨테이너, 담당 정보를 따로 보지 않고 하나의 영향 관계로 묶어 보여주는 것을 목표로 합니다. 운영자에게 필요한 것은 메뉴 목록이 아니라 지금 무엇이 영향을 받는지에 대한 빠른 답입니다.

한밤중 휴대폰이 울립니다. "api.example.com 응답 없음." 잠에서 덜 깬 운영자가 머릿속에 떠올리는 질문은 늘 비슷합니다. 이게 어디 영향을 주는가, 누가 담당이었는가, 같은 일이 예전에 있었는가, 지금 손대도 되는가.

응급실에 환자가 들어왔을 때 의료팀이 가장 먼저 하는 트리아지(triage)와 비슷한 일입니다. 증상 하나로 영향 범위·우선순위·담당을 빠르게 묶어내는 일이죠. 이번 글은 클라우드 인프라가 흔들렸을 때 운영자가 무엇을 보는지 이야기합니다.

메뉴 다섯 군데를 도는 운영의 무게​

기존 운영 화면은 보통 메뉴별로 나뉩니다. 서버 목록, DNS 목록, 컨테이너 목록, 인증서 목록을 따로 봅니다. 각 화면은 잘 정리돼 있지만, 정작 운영자가 알고 싶은 건 그 사이의 관계입니다.

한 도메인이 멈추면 뒤이어 어떤 서비스가 영향받는지, 누가 담당인지, 과거에는 이걸 어떻게 풀었는지. 메뉴 하나하나에는 답이 흩어져 있고, 그걸 머릿속에서 엮는 게 운영자의 역할이었죠.

응급실에 비유하면, 환자 차트는 다 있지만 누가 트리아지를 해주진 않는 상태입니다. 의사는 차트를 한 장씩 펼쳐 가며 머릿속에서 그림을 그려야 하죠.

InfraManager가 묶어내는 운영 체인​

저희가 만들고 있는 InfraManager 는 이 흩어진 정보를 하나의 운영 체인으로 묶어 보여주는 운영 대시보드입니다.

도메인 → DNS → 프록시 → 컨테이너 → 서버 → 백업 → 담당팀 → 런북.

api.example.com 한 줄을 누르면, 시스템이 이 체인을 따라가며 연결된 모든 것을 한 화면에 펼쳐냅니다. 운영자는 이제 "어디 있더라"를 묻는 대신 "어떻게 할까"부터 시작합니다.

비용도 같은 방식으로 봅니다. 이번 달 청구서가 늘었다면, 어느 구독에서 얼마가 늘었고, 그 구독에 어떤 리소스가 매여 있고, 누가 그 리소스를 만들었는지를 함께 보여줍니다. 숫자 하나를 따라가다가 그 뒤에 누가 서 있는지까지 보이는 거죠.

미나 — 운영자의 질문을 받는 트리아지​

InfraManager 위에는 AI 인프라 직원 **미나(MiNa)**가 함께 동작합니다. 운영자가 자연어로 묻기만 하면, 미나는 필요한 도구를 골라 결과를 묶어 답합니다.

운영자가 실제로 던지는 질문은 대략 이렇습니다.

• "이 도메인이 죽으면 뭐가 영향받지?" — 미나는 DNS·프록시·서비스·서버·담당팀을 한 묶음으로 가져옵니다.
• "이번 달 비용은 왜 늘었지?" — 구독·리소스·변경 이력·정리 후보를 함께 보여줍니다.
• "백업 안 되는 서버가 있나?" — 백업 정책·실패 이력·복구 대상을 묶어 답합니다.
• "같은 장애가 예전에 있었나?" — 과거 이벤트·조치 내역·재발 여부를 가져옵니다.

응급실 트리아지가 환자의 증상 하나로 진료 흐름 전체를 결정하듯, 미나는 질문 하나로 운영자가 다음에 봐야 할 화면·자료·사람을 함께 묶어줍니다. 운영자는 메뉴를 다섯 군데 도는 대신 미나에게 먼저 묻고, 시스템이 실제 데이터를 확인하는 흐름이 만들어집니다.

왜 이 방향인가​

인프라 운영에서 가장 어려운 일은 "서버가 살아 있는지" 만 확인하는 게 아닙니다. 장애가 났을 때 영향 범위·담당·과거 사례·지금 손대도 되는지를 빠르게 묶어 다음 행동을 결정하는 일이죠.

이 일은 그동안 사람이 머릿속에 인프라를 외우고 있어야만 가능했습니다. 인프라가 커질수록, 담당자가 바뀔수록 이 방식은 흔들리기 쉽습니다. 시스템이 관계를 기억하고, AI가 그 관계를 운영자에게 답으로 묶어주는 쪽으로 무게를 옮기면, 운영의 부담이 사람의 기억력에서 벗어납니다.

마치며​

저희는 InfraManager와 미나를 사내 인프라 운영에 직접 쓰면서, 한밤중 알람을 받았을 때 운영자가 머릿속 대신 시스템에게 먼저 묻는 흐름을 만들어가고 있습니다.

다음 글에서는 미나가 실제로 어떤 도구를 골라 어떤 답을 묶어내는지, 그 안쪽 흐름을 풀어보겠습니다.

핵심 요약 미나가 가장 먼저 구분해야 하는 것은 사용자가 조회만 원하는지, 실제 인프라 변경을 원하는지입니다. 읽기 작업과 변경 작업을 분리해야 AI 운영 도구가 빠르면서도 안전하게 동작할 수 있습니다.

지난 글에서 미나(MiNa)가 운영자의 질문을 받아 영향 범위·담당·과거 사례를 한 묶음으로 답한다는 이야기를 했습니다. "이 도메인이 죽으면 뭐가 영향받지?"에 미나가 DNS·프록시·서비스·서버·담당팀을 가져다 주는 식이었죠.

그런데 운영자가 던지는 질문이 늘 조회만은 아닙니다. "이 컨테이너 좀 지워줘", "GPU 작업 중지해줘", "이 사용자 계정 묶어줘" 같은 손대는 질문도 섞여 있죠. 같은 미나에게 묻는데 답이 같은 식으로 나오면 위험합니다.

이번 글은 미나가 묻는 한 가지 질문 — "조회만 할 거예요, 손대실 거예요?" 이야기입니다.

같은 응급실, 두 가지 모드​

응급실에서 의료팀이 하는 일은 두 갈래입니다. 환자 차트를 펼쳐 보는 일과, 약을 처방하거나 시술을 결정하는 일. 둘은 같은 의사가 하지만 절차가 완전히 다릅니다. 차트는 일단 빠르게 펼쳐도 환자에게 변화가 없죠. 처방은 잘못되면 환자에게 즉시 영향이 갑니다.

미나가 운영자의 질문을 받았을 때 가장 먼저 하는 일도 이 갈림입니다. "이건 보기만 하는 질문인가, 손대는 질문인가." 같은 미나가 묻고 답하지만, 둘은 다른 길을 탑니다.

빠른 길 — 조회만 묻는 질문​

조회는 빠르게 가도 됩니다.

• "서버 목록 보여줘"
• "GPU 누가 쓰고 있어?"
• "DNS 레코드 어디로 연결돼?"
• "이 도메인 담당팀이 누구야?"

이런 질문에 미나는 깊게 추론하지 않고 곧장 필요한 도구를 호출해 결과를 가져옵니다. 응급실로 치면 차트를 즉시 펼쳐 보여주는 동작이죠. 답이 빨라야 운영자가 다음 판단을 빨리 할 수 있습니다.

신중한 길 — 손대는 질문​

변경 질문은 같은 속도로 가면 안 됩니다. 미나는 다음 세 단계를 거칩니다.

1. 영향 범위 먼저 답하기 (dry-run)

"이걸 지우면 이게 같이 영향받습니다" 를 먼저 보여줍니다. 컨테이너 하나 지우는 요청에도, 그 컨테이너가 떠받치는 사이트·연결된 프록시·로그 보관 정책까지 함께 보여줍니다. 실제로는 아무것도 건드리지 않은 상태죠.

2. 담당팀 확인

"이 영역은 인프라팀입니다", "이건 데이터팀 권한이에요" 처럼 책임 소재를 함께 답합니다. 운영자가 자기 권한 밖 작업을 무심코 진행하지 않도록 보호하는 단계입니다.

3. 명시 승인 대기

운영자가 "OK, 진행해" 를 명시적으로 누르기 전까지 미나는 실행하지 않습니다. 응급실에서 위험한 시술 전에 동의서를 받는 단계와 같습니다.

왜 두 길을 굳이 나누나​

빠른 길만 있으면 위험합니다. 손대는 질문이 들어왔는데 미나가 빠르게 처리해 버리면, 운영자가 영향 범위를 모르는 채 인프라가 바뀌어 버립니다.

신중한 길만 있으면 답답합니다. 단순 조회까지 매번 "정말로 보시겠습니까?" 를 묻기 시작하면, 운영자가 미나에게 묻지 않고 메뉴를 직접 도는 옛 방식으로 돌아갑니다.

빠른 트리아지 + 신중한 처치 — 응급실이 잘 굴러가는 이유와 같은 모양으로, 인프라 운영도 두 트랙이 함께 있어야 합니다.

마치며​

미나는 답을 묶어내는 능력만큼 언제 멈춰서 운영자에게 다시 물을지 아는 능력도 중요합니다. 빠른 답이 필요한 곳에선 빠르게, 신중해야 할 곳에선 한 번 멈춰서 묻는 미나가 저희가 사내 인프라에 매일 함께 쓰고 있는 동료입니다.

다음 글에서는 미나가 따라가는 운영 체인 — 도메인 한 줄에서 시작해 어떻게 백업과 담당팀까지 따라가는지 — 그 안쪽 흐름을 풀어보겠습니다.

핵심 요약 Smart On-sitehub는 작업일보를 단순 기록이 아니라 공정관리, 위험성평가, 안전관리, 전자문서 관리의 공통 데이터로 바꾸는 플랫폼입니다. 현장 정보가 흩어지지 않도록 작업, 위치, 인원, 위험요인을 하나의 흐름으로 연결합니다.

건설현장에서는 매일 수많은 정보가 발생합니다.

오늘 어떤 작업자가 투입되었는지, 어떤 작업이 진행되는지, 어떤 위험요인이 있는지, 그리고 관련 문서가 어디에 있는지까지 관리자는 계속 확인해야 합니다. 하지만 실제 현장에서는 이러한 정보가 여러 문서와 엑셀, 메신저, 종이 서류에 흩어져 있는 경우가 많습니다.

미니소프트의 Smart On-sitehub는 이러한 문제를 해결하기 위해 만들어진 스마트 건설 현장 플랫폼입니다. 안전관리, 공정관리, 위험성평가, 전자문서 관리를 하나의 시스템으로 통합하여 현장을 한눈에 파악할 수 있도록 지원합니다.

핵심은 작업일보 중심의 디지털화입니다.

작업자가 작업일보를 작성하면 누가(OBS), 어디서(PBS), 어떤 작업을(WBS), 어떤 위험요인(SBS)과 함께 수행했는지가 데이터로 연결됩니다. 단순 기록이 아니라 공정관리와 위험성평가, 작업현황 모니터링의 기반 데이터가 되는 것입니다.

작업일보가 데이터가 되는 순간​

Smart On-sitehub에서는 작업일보가 Activity Data로 변환되고, 위험성평가, 안전관리, 공정관리, 전자문서 관리의 공통 데이터로 활용됩니다.

각 업무 영역에서 생성된 데이터는 통합 대시보드로 모여 관리자가 현장 전체를 실시간으로 파악할 수 있게 합니다.

특히 위험성평가 자동 연계가 중요합니다.

기존에는 월 단위 또는 별도 문서로 관리되던 위험성평가가 실제 작업과 분리되는 경우가 많았습니다. Smart On-sitehub는 작업일보 작성 시 작업내용, 작업위치, 작업인원 정보를 함께 반영하여 실제 작업 기반의 안전관리를 가능하게 합니다.

종이 문서에서 디지털 문서로​

문서관리도 디지털로 전환됩니다.

안전교육 확인서, 동의서, 점검일지, 작업계획서 등을 전자문서 형태로 관리할 수 있으며 전자서명과 QR 기반 업무 처리도 지원합니다. 외국인 근로자를 위한 다국어 교육 콘텐츠 활용도 가능합니다.

현장에서 발생하는 각종 문서는 단순 보관 대상이 아니라 업무 데이터가 됩니다. 필요한 자료를 빠르게 검색하고 공유할 수 있으며, 승인과 이력 관리도 함께 수행할 수 있습니다.

건설현장을 데이터로 연결하다​

결국 Smart On-sitehub의 목표는 단순한 문서 전산화가 아닙니다.

현장에서 발생하는 작업, 안전, 공정, 문서를 하나의 데이터로 연결하여 관리자가 현장을 더 빠르고 정확하게 파악할 수 있도록 만드는 것입니다.

작업일보 한 건이 현장 전체를 설명하는 데이터가 되는 것.

그것이 Smart On-sitehub가 추구하는 스마트 건설 현장의 모습입니다.

핵심 요약 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

핵심 요약 멀티모달 LLM은 현장 사진에서 위험요소 후보를 빠르게 요약하는 보조 도구로 유용합니다. 다만 최종 안전 판단은 검증 가능한 기준과 사람의 확인 절차 안에서 운영되어야 합니다.

현장 사진과 안전 규정 프롬프트를 활용한 산업안전 점검 가능성 검증​

산업안전 점검은 여전히 많은 부분이 사람의 경험과 수작업에 의존합니다. 현장 사진을 확인하고, 보호구 착용 여부와 위험요소를 판단하고, 그 결과를 다시 보고서로 정리해야 합니다.

최근 멀티모달 LLM은 이미지와 텍스트를 함께 이해할 수 있게 되었습니다. 이 글에서는 현장 사진과 안전 규정 프롬프트를 함께 입력했을 때, 안전수칙 점검과 리포트 작성 보조가 가능한지 검토한 PoC 내용을 정리합니다.

PoC 목표​

이번 PoC의 목표는 특정 현장이나 특정 장비를 판정하는 것이 아니라, 멀티모달 LLM을 산업안전 점검 보조 도구로 활용할 수 있는지 확인하는 것이었습니다.

• 현장 사진 기반 안전수칙 점검 가능 여부 검증
• 별도 모델 학습 없이 규정 프롬프트만으로 점검 가능한지 확인
• 위험요소 요약과 점검 리포트 자동 생성 가능성 검토
• 향후 영상 기반 점검으로 확장할 수 있는지 검토

접근 방식​

입력은 단순하게 구성했습니다. 현장 사진을 넣고, 점검해야 할 안전 규정과 출력 형식을 프롬프트로 제공했습니다. 모델은 사진에서 보이는 작업자, 보호구, 주변 위험요소를 확인한 뒤 구조화된 점검 결과를 반환하도록 했습니다.

이 방식의 장점은 별도 학습 데이터셋이나 전용 비전 모델을 먼저 준비하지 않아도 된다는 점입니다. 규정을 프롬프트로 바꾸면 점검 기준을 비교적 빠르게 바꿔 볼 수 있고, 결과 형식도 리포트나 체크리스트 형태로 조정할 수 있습니다.

확인한 점​

PoC에서 확인한 가능성은 다음과 같습니다.

• 안전모 착용 여부를 식별할 수 있었습니다.
• 안전조끼 착용 여부를 식별할 수 있었습니다.
• 사진 안의 작업자 수를 대략 파악할 수 있었습니다.
• 눈에 보이는 위험요소를 요약할 수 있었습니다.
• 점검 결과를 리포트 형태로 정리할 수 있었습니다.

다만 한계도 분명했습니다. 저해상도 이미지에서는 정확도가 떨어졌고, 원거리 작업자는 누락될 수 있었습니다. 안전대 체결 여부처럼 작은 디테일이나 가려진 상태를 판단해야 하는 항목은 신뢰도가 낮았습니다.

인사이트​

이번 검증에서 멀티모달 LLM은 최종 판정자보다는 점검 보조 도구에 더 적합했습니다. 사람이 놓칠 수 있는 위험요소를 1차로 요약하고, 점검자가 확인해야 할 항목을 빠르게 정리하는 역할에서 가능성이 컸습니다.

특히 보고서 초안 생성은 실무 부담을 줄일 수 있는 영역입니다. 사람이 사진을 보고 판단한 뒤 문장을 다시 쓰는 시간을 줄이고, 점검자는 최종 확인과 보완에 집중할 수 있습니다.

향후 확장 방향​

다음 단계에서는 정지 이미지뿐 아니라 CCTV, 드론, 모바일 촬영 영상에서 스냅샷을 추출해 주기적인 안전 점검 흐름으로 확장하는 방안을 검토할 수 있습니다.

중요한 것은 AI가 모든 판단을 대신한다는 접근이 아닙니다. 현장 안전은 책임과 맥락이 필요한 영역입니다. AI는 반복 점검을 보조하고, 위험 후보를 빠르게 정리하며, 사람이 더 중요한 판단에 집중할 수 있도록 돕는 역할부터 시작하는 것이 현실적입니다.

마치며​

멀티모달 LLM은 현장 사진을 이해하고 안전 규정과 연결해 해석할 수 있는 가능성을 보여주었습니다. 아직 모든 상황을 정확하게 판단하기에는 한계가 있지만, 안전 점검 보조와 리포트 자동화 영역에서는 충분히 실험해 볼 가치가 있습니다.

산업안전 영역에서 AI의 역할은 사람을 대체하는 것이 아니라, 더 빠르게 보고 더 일관되게 기록하도록 돕는 방향에서 시작될 수 있습니다.

참고 자료​

• NIST AI Risk Management Framework
• OWASP Top 10 for Large Language Model Applications

핵심 요약 AI Agent 시대에는 하나의 챗봇보다 여러 Agent가 문서, 이미지, 데이터, 업무 흐름을 나누어 처리하는 구조가 중요해집니다. MiWork Agents는 이런 Agent들을 만들고 연결하고 관리하는 플랫폼 방향을 지향합니다.

AI는 더 이상 하나의 챗봇에 머무르지 않습니다.

문서를 이해하는 AI, 이미지를 분석하는 AI, 데이터를 분석하는 AI, 그리고 여러 AI Agent가 협업하는 시대로 빠르게 변화하고 있습니다.

이 변화는 기업에게 새로운 질문을 던집니다.

AI Agent를 어떻게 만들고, 어떻게 업무 데이터와 연결하며, 어떻게 안전하게 관리할 것인가.

MiWork Agents는 이러한 변화에 대응하기 위해 AI Agent를 만들고, 연결하고, 관리할 수 있는 플랫폼으로 진화하고 있습니다.

AI Agent 시대의 핵심은 더 많은 도구를 쓰는 것이 아니라, 기업의 업무 자산과 AI를 안정적으로 연결하는 운영 체계를 만드는 것입니다.

핵심 요약 기업용 AI Agent 플랫폼은 AI에게 질문하는 화면만으로 완성되지 않습니다. 문서, 데이터, 업무 시스템을 연결하면서도 권한·보안·운영 정책 안에서 관리할 수 있어야 실제 기업 업무에 적용할 수 있습니다.

최근 언론을 통해 MiWork Agents가 기업 맞춤형 AI Agent 플랫폼으로 소개되었습니다.

우리는 AI를 사용하는 것보다, AI Agent를 어떻게 연결하고 어떻게 안전하게 운영할 것인가를 더 중요하게 생각합니다.

기업 환경에서 AI Agent는 단순한 대화 도구를 넘어 문서, 데이터, 업무 시스템과 연결되어야 합니다. 동시에 권한, 보안, 운영 정책 안에서 지속적으로 관리되어야 합니다.

MiWork Agents는 이러한 고민에서 시작되었습니다.

앞으로도 기업 환경에 최적화된 AI 플랫폼으로 지속적으로 발전해 나갈 예정입니다.

핵심 요약 패션 이미지 검색은 사용자가 정확한 상품명을 몰라도 사진 한 장으로 유사 상품을 찾게 해주는 검색 방식입니다. 제품 이미지를 임베딩 벡터로 바꾸고, 업로드 이미지와 가까운 상품을 비교하는 구조가 핵심입니다.

패션 상품을 찾을 때 사용자는 꼭 정확한 상품명을 알고 있지 않습니다. 길에서 본 신발, 착용샷 속 아우터, 비슷한 디자인의 가방처럼 이미지는 있는데 키워드는 애매한 상황이 더 많습니다.

이번 PoC는 이런 상황을 전제로 만들었습니다. 사진 한 장을 업로드하면 이미지에서 특징을 추출하고, 상품 카탈로그에 저장된 이미지 벡터와 비교해 비슷한 상품을 추천하는 구조입니다.

왜 이미지 검색인가​

텍스트 검색은 상품명, 브랜드명, 카테고리, 색상 같은 메타데이터가 잘 정리되어 있을 때 강합니다. 하지만 패션 상품은 같은 상품도 사용자가 다르게 표현합니다. 누군가는 "흰색 운동화"라고 검색하고, 누군가는 "두꺼운 밑창 스니커즈"라고 검색합니다.

이미지 검색은 이 간극을 줄입니다. 사용자가 가진 사진을 기준으로 형태, 색감, 실루엣, 패턴 같은 시각 특징을 비교하면 텍스트가 부족해도 유사 상품을 찾을 수 있습니다.

검색 흐름​

핵심은 상품 이미지를 단순 파일로 두지 않고, 검색 가능한 벡터로 바꾸는 것입니다.

1. 상품 이미지를 수집하고 카테고리와 함께 정리합니다.
2. 이미지 임베딩 모델로 각 상품의 특징 벡터를 생성합니다.
3. 벡터 DB에 상품 ID, 카테고리, 이미지 경로, 임베딩을 저장합니다.
4. 사용자가 업로드한 검색 이미지도 같은 방식으로 벡터화합니다.
5. 벡터 유사도 기준으로 가까운 상품을 정렬해 보여줍니다.

이 구조에서는 검색어가 정확하지 않아도 됩니다. 검색의 기준이 텍스트가 아니라 이미지 자체이기 때문입니다.

상품 검색 화면​

사용자는 이미지를 올리거나 상품명을 입력해 검색할 수 있습니다. 카테고리 필터를 함께 두면 전체 상품 중에서 원하는 범위를 좁힐 수 있습니다.

검색 결과는 유사도와 함께 노출됩니다. 운영자는 추천 결과가 실제로 기대한 상품군에 가까운지 확인하면서 카테고리, 이미지 품질, 임베딩 생성 상태를 점검할 수 있습니다.

착용샷으로 검색하기​

실제 사용자는 정면 상품 이미지보다 착용샷이나 현장 사진을 가지고 있을 가능성이 높습니다. 그래서 테스트 화면은 업로드 이미지에서 관심 객체를 기준으로 비슷한 상품을 찾는 흐름을 확인하도록 구성했습니다.

검색 결과가 좋아지려면 단순히 모델만 바꾸는 것으로는 부족합니다. 상품 이미지의 배경, 각도, 해상도, 카테고리 품질이 함께 맞아야 합니다. PoC 단계에서는 이 품질 기준을 빠르게 확인하는 것이 중요합니다.

상품 관리와 임베딩 재생성​

이미지 검색 서비스에서 관리 화면은 검색 화면만큼 중요합니다. 상품 이미지가 바뀌었는데 임베딩이 갱신되지 않으면 검색 결과는 오래된 정보를 기준으로 움직입니다.

그래서 상품 관리 화면에는 이미지 수, 임베딩 상태, 검수 상태를 함께 보여주는 구성이 필요합니다. 신규 상품을 등록하거나 이미지를 수정한 뒤에는 임베딩을 재생성해 검색 결과에 반영합니다.

PoC에서 확인한 것​

이번 PoC의 목적은 완성형 쇼핑몰을 만드는 것이 아니라, 이미지 검색이 상품 탐색 업무에 실제로 쓸 수 있는지 확인하는 것이었습니다.

확인할 지점은 명확했습니다. 사용자가 이미지를 업로드했을 때 유사 상품이 충분히 빠르게 나오는가, 카테고리 필터가 결과 품질을 높이는가, 상품 관리자가 이미지와 임베딩 상태를 이해할 수 있는가, 신규 상품을 넣었을 때 검색 결과에 반영되는가입니다.

마치며​

이미지 검색은 "상품명을 입력하는 검색"을 대체한다기보다, 사용자가 말로 설명하기 어려운 순간을 보완하는 검색 방식입니다.

패션처럼 시각 정보가 중요한 영역에서는 상품 이미지, 카탈로그 데이터, 벡터 검색, 관리 화면이 함께 맞물려야 합니다. 검색 결과 화면만 만드는 것이 아니라, 이미지를 계속 관리하고 갱신할 수 있는 운영 흐름까지 같이 설계해야 실제 서비스로 이어질 수 있습니다.

핵심 요약 MiWork Agents는 언론을 통해 기업용 AI Agent Platform으로 소개되었습니다. 이 글은 기사에서 다룬 MiWork Agents의 방향과, 기업이 AI Agent를 업무 시스템과 안전하게 연결해야 하는 이유를 짧게 정리합니다.

AI Agent 시대를 위한 Enterprise AI Platform​

최근 전자신문을 통해 MiWork Agents가 소개되었습니다.

MiWork Agents는 AI Agent를 만들고, 기업의 데이터와 연결하며, 안전하게 운영할 수 있도록 설계된 Enterprise AI Agent Platform입니다.

지난 2년 동안 우리는 AI를 어떻게 업무에 적용할 것인지, 그리고 기업은 AI Agent를 어떻게 관리해야 하는지에 대해 고민해 왔습니다.

이번 기사에서는 MiWork Agents의 주요 기능과 기업 환경에서의 활용 방향, AI Agent Platform으로서의 비전을 소개하고 있습니다.

MiWork Agents는 앞으로도 변화하는 기술 트렌드에 맞추어 계속 진화해 나갈 예정입니다.

기사 전문 보기

핵심 요약 LLM 도입은 모델을 하나 고르는 일이 아니라, 업무 데이터와 연결하고 위험을 관리하는 운영 체계를 만드는 일입니다. 실제 업무에 쓰려면 RAG, 권한, 검증 절차, 보안 기준을 함께 설계해야 합니다.

"AI가 일자리를 빼앗는다"는 말, 한 번쯤 들어보셨을 거예요. 그런데 막상 회사 안에서 AI를 어떻게 쓰는지는 잘 안 보입니다. 미니소프트가 지난 1년 동안 LLM(대규모 언어 모델)을 사내에 들이며 겪은 진짜 이야기를 풀어보겠습니다.

업무 요청이 결과물로 바뀌는 흐름​

업무 요청은 LLM만으로 끝나지 않습니다. 사내 데이터 검색, 사람의 검토, 최종 산출물 확인까지 이어져야 실제 업무에 사용할 수 있습니다.

LLM, 도대체 뭐가 다른가요​

기존 챗봇은 "정해진 질문에 정해진 답"을 했습니다. 사용자가 조금만 다르게 물어도 "죄송합니다, 이해하지 못했습니다"가 돌아왔죠.

LLM은 다릅니다. 사람이 쓴 문장을 그대로 이해하고, 문맥을 파악해 답을 만들어냅니다. 마치 신입 직원에게 매뉴얼을 통째로 외우게 한 뒤 자유롭게 답하게 하는 것과 비슷합니다.

우리가 처음 시도한 것 — 그리고 실패​

처음에는 단순했습니다. 공개 LLM API를 붙여 사내 문의 응대 봇을 만들었죠. 결과는 처참했습니다.

문제 1: 회사 정보를 모른다​

"우리 회사 휴가 정책이 어떻게 돼?"라고 물으면 일반론만 답했습니다. 미니소프트의 실제 규정은 공개 LLM이 알 리 없으니까요.

문제 2: 그럴듯하게 거짓말한다​

가끔은 존재하지 않는 사내 제도를 만들어내 답하기도 했습니다. 이른바 할루시네이션(hallucination) 이죠. 직원이 잘못된 답을 그대로 믿으면 큰일입니다.

RAG로 다시 시작하다​

해법은 RAG(검색 증강 생성) 였습니다. 사내 문서를 미리 검색하고, 그 내용을 LLM에게 "이 자료를 참고해서 답해주세요"라고 함께 전달하는 방식입니다.

도서관 사서를 떠올리면 됩니다. "이 주제 좀 알려주세요"라고 하면, 사서가 책장에서 관련 책을 먼저 꺼내고, 그 책을 보면서 답해주는 거죠. 책에 없는 내용은 "이 자료에는 없습니다"라고 솔직하게 답합니다.

진짜 바뀐 것들​

신입 교육 시간이 줄었다​

신입 직원이 사내 위키를 뒤지는 대신 챗봇에 바로 물어봅니다. "출장비 정산은 어떻게 하나요?", "VPN 접속이 안 돼요"처럼요. 인사·총무팀의 반복 문의가 약 40% 줄었습니다.

회의록 정리가 자동화됐다​

2시간짜리 회의 녹음 파일을 올리면 5분 안에 요약·액션 아이템·담당자가 정리됩니다. 회의 후 30분씩 쓰던 정리 시간이 사라졌습니다.

코드 리뷰의 1차 점검을 AI가​

개발팀에서는 PR이 올라오면 LLM이 먼저 검토합니다. 명백한 실수, 보안 취약점, 컨벤션 위반을 잡아주죠. 사람 리뷰어는 더 중요한 설계 논의에 집중할 수 있게 됐습니다.

우리가 배운 것​

1. AI는 도구일 뿐, 만능은 아니다 무엇을 맡길지, 무엇은 사람이 해야 할지 구분이 핵심입니다.

2. 데이터 정리가 절반이다 LLM이 잘 답하려면 사내 문서가 잘 정리돼 있어야 합니다. AI 도입 전에 문서 정비부터 했어요.

3. 작게 시작해서 키운다 한 번에 모든 업무를 자동화하려 하지 않았습니다. 한 팀에서 한 가지 문제부터 풀었고, 효과가 입증되면 확장했습니다.

마치며​

LLM은 마법이 아닙니다. 하지만 잘 쓰면 반복적이고 지루한 일을 줄여, 사람이 더 중요한 일에 집중하게 해줍니다. 다음 글에서는 RAG 구축 과정을 좀 더 기술적으로 풀어보겠습니다.

참고 자료​

• NIST AI Risk Management Framework
• OWASP Top 10 for Large Language Model Applications

핵심 요약 IoT 현장 적용의 핵심은 센서를 붙이는 것이 아니라, 센서 데이터가 운영자가 판단할 수 있는 Dashboard와 알림으로 이어지게 만드는 것입니다. 스마트팩토리와 스마트물류는 작은 현장 데이터가 누적될 때 실제 운영 개선으로 연결됩니다.

스마트팩토리, 스마트물류 — 뉴스에서는 자주 듣지만 실제로 공장 안에서 무슨 일이 벌어지는지는 잘 안 보입니다. 미니소프트가 구축한 현장의 이야기를 통해, IoT가 실제로 어떻게 일을 바꾸는지 풀어보겠습니다.

센서 데이터가 Dashboard가 되기까지​

현장의 센서 데이터는 Gateway와 Cloud Platform을 거쳐 분석되고, 운영자가 볼 수 있는 Dashboard로 정리됩니다.

"스마트"하다는 게 정확히 뭐죠​

기계가 스스로 생각한다는 의미는 아닙니다. 핵심은 두 가지입니다.

1. 데이터를 모은다 — 기계의 상태, 온도, 진동, 위치를 실시간으로 측정
2. 데이터로 판단한다 — 평소와 다르면 알리고, 패턴을 분석해 미래를 예측

이걸 가능하게 하는 게 IoT(사물인터넷) 입니다. 작은 센서들이 모여 큰 그림을 만들어내는 거죠.

한 공장의 하루를 따라가 봅시다​

미니소프트가 구축한 부품 가공 공장의 사례입니다.

아침 7시 — 라인 가동 전 점검​

옛날엔 작업자가 일일이 기계를 돌며 "오늘 컨디션 어때?"를 확인했습니다. 지금은 출근하면서 핸드폰으로 대시보드를 봅니다. 어젯밤 동안 모든 기계의 진동·온도·전류 데이터가 자동으로 수집돼 있죠.

비정상 신호가 잡힌 3번 라인 만 확인하면 됩니다. 점검 시간이 1시간에서 10분으로 줄었습니다.

오전 10시 — 갑작스런 소리​

3번 라인 모터에서 평소와 다른 진동이 감지됩니다. 시스템이 자동으로 알림을 보냅니다.

"라인 3 모터 베어링 이상 징후. 향후 72시간 내 점검 권장."

예지보전(Predictive Maintenance) 입니다. 고장 난 다음 고치는 게 아니라, 고장 나기 전에 미리 잡는 것. 라인이 멈춰서 생기는 손해는 시간당 수백만 원이라, 한 번의 사전 정비가 막대한 비용을 아낍니다.

오후 2시 — 재고 자동 보충​

부품 박스마다 무게 센서가 달려 있습니다. 박스가 일정 무게 이하로 줄면 창고 시스템에 자동 발주가 들어갑니다. 작업자가 "어, 부품 떨어졌네?" 하고 발견하는 일이 사라집니다.

물류창고는 또 다른 세계​

위치 추적 — 물건은 어디에 있나​

대형 창고에서 작업자가 물건을 못 찾는 시간이 의외로 깁니다. RFID와 비콘을 쓰면 모든 박스의 현재 위치가 지도에 표시됩니다. PDA로 "찾기" 누르면 길 안내가 나오죠.

환경 모니터링 — 식품·의약품의 생명선​

콜드체인이 필요한 의약품 창고에서는 온도가 1도만 벗어나도 제품이 폐기 대상이 됩니다. 온도 센서가 1분마다 측정하고, 임계치 초과 시 즉시 담당자에게 알림이 갑니다. 사고 위험을 사실상 0으로 만듭니다.

작업자 안전​

지게차에 충돌 감지 센서를 달면, 사람과 가까워질 때 자동으로 속도를 줄이거나 멈춥니다. 사고가 줄어드는 건 물론이고, 작업자의 심리적 부담도 줄죠.

데이터가 쌓이면 진짜 시작된다​

IoT의 진짜 힘은 데이터가 누적된 후에 나옵니다.

• 이 모터는 평균 8개월 만에 베어링이 마모된다 → 정비 주기 최적화
• 금요일 오후 라인 효율이 떨어진다 → 작업 스케줄 재조정
• A 부품 입고 후 3일 내에 가공 완료해야 품질이 좋다 → 재고 회전 정책 변경

데이터가 쌓일수록 더 똑똑해지는 시스템 — 이게 스마트팩토리의 본질입니다.

시작은 작게, 효과는 크게​

IoT 도입은 거창할 필요가 없습니다. 미니소프트가 함께한 한 중소 제조사는 처음에 딱 한 라인의 진동 센서 5개 로 시작했습니다. 6개월 만에 라인 가동률이 12% 올랐고, 그 후 단계적으로 전 라인에 확장했습니다.

핵심은 "어디서 비용이 새고 있는가" 를 먼저 보는 것. 센서를 많이 다는 게 아니라, 꼭 필요한 곳에 다는 거죠.

마치며​

IoT는 SF 같은 미래 기술이 아닙니다. 작은 센서 하나가, 그 데이터를 모으는 시스템이, 그리고 그것을 해석하는 사람의 판단이 더해질 때 현장은 분명히 달라집니다. 미니소프트는 앞으로도 현장의 문제부터 듣고, 데이터로 답을 만들어가겠습니다.