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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MiniApp Hub를 예로 들면​

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

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

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

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

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

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

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

마치며​

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

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

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

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

Enterprise Proposal · 2026

문제 정의​

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

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

MiniApp Hub 소개​

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

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

솔루션 개요​

MiniApp Hub가 만드는 효과​

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

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

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

실제 화면​

App Store​

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

Dashboard​

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

업무 앱 활용 예시​

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

동영상으로 보기​

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

보안과 거버넌스​

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

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

기대 효과​

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

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

마치며​

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

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

핵심 요약 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가 문서, 이미지, 데이터, 업무 흐름을 나누어 처리하는 구조가 중요해집니다. LUMINUS는 이런 Agent들을 만들고 연결하고 관리하는 플랫폼 방향을 지향합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

왜 이미지 검색인가​

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

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

검색 흐름​

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

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

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

상품 검색 화면​

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

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

착용샷으로 검색하기​

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

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

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

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

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

PoC에서 확인한 것​

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

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

마치며​

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

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

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

AI Agent 시대를 위한 Enterprise AI Platform​

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

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

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

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

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

기사 전문 보기

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

핵심 요약 LUMINUS는 기업이 여러 AI Agent를 만들고, 업무 데이터와 연결하며, 권한과 정책 안에서 운영하도록 돕는 Enterprise AI Agent Platform입니다. 핵심은 더 많은 AI 도구를 쓰는 것이 아니라, AI Agent를 안전하게 관리 가능한 업무 플랫폼으로 만드는 것입니다.

LUMINUS로 구현한 Enterprise AI Agent Platform​

지난 2년 동안 우리는 AI 기술이 어떻게 기업의 업무를 바꾸는지 지켜보았습니다.

LLM이 등장했고, RAG가 확산되었으며, 멀티모달 AI는 문서와 이미지를 이해하기 시작했습니다. 그리고 이제는 여러 AI Agent가 협업하는 시대가 빠르게 다가오고 있습니다.

하지만 기술이 발전할수록 오히려 더 큰 고민이 생겼습니다.

• 기업은 AI를 어떻게 연결해야 할까?
• AI를 어떻게 안전하게 운영해야 할까?
• 여러 AI Agent를 어떻게 관리해야 할까?

우리는 이 질문에 대한 답으로 LUMINUS를 만들었습니다.

LUMINUS는 단순한 챗봇이 아닙니다​

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

AI Agent가 실제 업무에 쓰이려면 대화만 잘해서는 부족합니다. 문서, 이미지, 데이터, 업무 시스템과 연결되어야 하고, 동시에 권한과 정책 안에서 안전하게 동작해야 합니다.

누구나 업무용 AI Agent를 만들 수 있도록​

LUMINUS에서는 업무 목적에 맞는 AI Agent를 만들 수 있습니다.

• 문서를 검색하는 Agent
• 이미지를 이해하는 Vision Agent
• 데이터를 분석하는 Agent
• 업무를 자동화하는 Workflow Agent

각 Agent는 독립적으로 동작하면서도 하나의 플랫폼 위에서 통합 관리됩니다. 개별 기능을 흩어 놓는 것이 아니라, 기업이 운영할 수 있는 Agent 자산으로 관리하는 것이 핵심입니다.

기업의 데이터와 안전하게 연결​

AI Agent는 단순히 질문에 답하는 것을 넘어 기업의 실제 업무와 연결되어 동작해야 합니다.

파일 시스템, 데이터베이스, 사내 시스템, 클라우드 서비스까지 다양한 데이터와 도구를 연결할 수 있어야 합니다. 동시에 누가 어떤 Agent를 만들었고, 어떤 데이터에 접근하며, 어떤 정책을 적용받는지 관리할 수 있어야 합니다.

AI 시대의 경쟁력은 AI 자체가 아니다​

우리는 AI 시대의 경쟁력이 더 뛰어난 AI 모델을 선택하는 것에만 있다고 생각하지 않습니다.

AI를 얼마나 빠르게 연결하고, 얼마나 안전하게 운영하며, 얼마나 많은 업무 자산을 AI와 연결할 수 있는가가 더 중요합니다.

LUMINUS는 AI를 사용하는 플랫폼이 아니라, AI Agent를 만들고, 연결하고, 관리하기 위한 플랫폼입니다.

마치며​

AI Agent가 많아질수록 기업에는 새로운 운영 체계가 필요합니다. Agent를 쉽게 만들고, 필요한 데이터와 연결하고, 정책과 보안 기준 안에서 운영하는 구조가 있어야 합니다.

LUMINUS는 기업이 AI Agent를 개별 실험이 아니라 지속적으로 운영 가능한 플랫폼으로 다룰 수 있도록 돕는 것을 목표로 합니다.

핵심 요약 신입 개발자의 첫 달은 코드를 빨리 많이 치는 시간보다, 제품·사람·업무 방식을 이해하는 시간입니다. 미니소프트 온보딩은 첫 배포까지의 작은 성공 경험을 통해 개발자가 팀 안에서 일하는 방식을 익히도록 설계됩니다.

"개발자로 회사에 들어가면 뭘 하지?" 학생일 때 가장 궁금했던 질문입니다. 미니소프트에 입사한 신입 개발자가 첫 한 달 동안 어떤 여정을 거치는지 — 좋은 점, 어려운 점, 배운 점 모두 — 솔직하게 풀어봅니다.

출근 첫 날 — 사람부터 만난다​

첫 날 아침은 코드를 보지 않습니다. 대신 사람을 만나죠.

환영 미팅​

팀장님과 멘토 선배가 함께 점심을 사주십니다. 회사 분위기, 팀이 뭘 하는지, 앞으로 어떤 프로젝트가 있는지 편하게 이야기합니다. 코드 한 줄 못 짜도 괜찮은 시간입니다.

장비 세팅​

오후엔 노트북을 받습니다. 미니소프트는 신입에게 맥북 또는 고사양 윈도우 노트북 중 선택권을 줍니다. 모니터, 키보드, 마우스 같은 주변 기기도 본인이 원하는 걸 신청할 수 있죠.

계정 받기​

이메일, 메신저, 그룹웨어, GitHub, AWS, 사내 위키 — 받을 계정만 10개 가까이 됩니다. 한꺼번에 헷갈리니 정보 관리부터 시작이죠. 비밀번호 매니저(1Password) 사용법도 이때 배웁니다.

1주차 — 환경부터 익숙해지기​

개발 환경 세팅​

미니소프트는 개발 환경 세팅 자동화 스크립트를 운영합니다. make setup 한 번이면 필요한 모든 도구가 깔립니다. 그래도 문제는 꼭 생기죠. 그럴 땐 멘토 선배에게 물어봅니다. "이거 안 되는데요?"

코드 둘러보기​

첫 주는 코드를 "쓰는" 게 아니라 "읽는" 시간입니다. 문서, README, 아키텍처 다이어그램부터 시작해 핵심 모듈을 차근차근 읽어 나갑니다. 이해 안 되는 건 노션에 적어두고, 매일 1-on-1 시간에 멘토와 같이 봅니다.

사내 문화 익히기​

• 수평 호칭: 직급 대신 "OO님"으로 부릅니다. 신입이 임원에게도 "님"으로 의견을 말할 수 있는 분위기입니다.
• 점심 시간 자유: 정해진 시간 없이 12-2시 사이에 알아서 먹으면 됩니다. 같이 먹고 싶은 사람과 자유롭게.
• 수요일 오후 = 학습 시간: 매주 수요일 오후 2-6시는 업무 대신 학습 시간입니다. 책, 강의, 토이 프로젝트 자유롭게.

2주차 — 작은 PR부터 시작​

첫 커밋, 첫 PR​

멘토가 작은 작업을 줍니다. "이 함수 이름이 헷갈리니까 더 명확한 이름으로 바꿔줘", "이 부분 테스트 코드가 빠졌어, 한 번 써볼래?" 같은 거죠.

코드 한 줄 바꿔도 PR(Pull Request)을 올립니다. 그러면 팀원 2-3명이 리뷰해줍니다. 처음엔 코멘트가 10개씩 달려서 위축되기도 하지만, 그게 성장 포인트입니다.

코드 리뷰 문화​

미니소프트의 리뷰 문화는 단호하지만 친절합니다.

• ❌ "이거 왜 이렇게 짰어?"
• ✅ "이 부분은 이렇게 하면 더 읽기 좋을 것 같아요. 제가 알려드릴까요?"

지적은 코드에 대한 것이지 사람에 대한 것이 아니라는 원칙이 있죠. 신입도 시니어 코드에 의견을 낼 수 있습니다.

쌍 프로그래밍​

어려운 작업은 멘토와 함께 한 화면을 보면서 진행합니다. 한 사람이 코드를 치고, 다른 사람이 옆에서 같이 생각하는 방식이죠. 혼자 끙끙대는 시간이 줄어들고, 사고 방식 자체를 배웁니다.

3주차 — 첫 진짜 작업​

작은 기능 하나 맡기​

이쯤이면 작은 기능 하나를 처음부터 끝까지 맡습니다. 기획서를 읽고, 설계하고, 구현하고, 테스트하고, 배포까지요. 분량은 작지만 전 과정을 경험하는 게 핵심입니다.

막히면 어디서 도움 받나​

• Slack #ask-engineering — 기술 관련 질문 채널, 누구나 답해줌
• 사내 위키 — 과거 사례, 가이드, 트러블슈팅 정리됨
• AI 챗봇 — RAG 기반 사내 챗봇 (이건 이전 글에서)
• 멘토 1-on-1 — 매일 30분, 어떤 질문이든 OK

"질문하는 게 부끄럽지 않은 분위기"가 신입에겐 가장 큰 자산입니다.

4주차 — 첫 배포​

운영 환경에 내 코드가​

3주차에 만든 작은 기능이 드디어 운영 환경에 배포됩니다. 처음엔 떨립니다. "이거 잘못 배포해서 서비스 멈추면 어쩌지?"

미니소프트는 그래서 단계적 배포 를 합니다.

1. 개발 환경에 먼저 배포 (혼자 테스트)
2. 스테이징에 배포 (전 팀이 함께 검증)
3. 운영의 1%에만 먼저 노출 (Canary Release)
4. 문제 없으면 단계적으로 100%까지 확장

문제가 생기면 즉시 이전 버전으로 자동 롤백됩니다. 신입도 부담 없이 배포할 수 있는 안전망이죠.

회고​

배포가 끝나면 회고를 합니다. "잘된 것, 아쉬운 것, 다음에 시도해볼 것"을 솔직하게 적습니다. 실패도 자산이라는 분위기가 있어, 솔직하게 적을 수 있죠.

한 달이 지나고​

한 달이 지나면 이런 변화가 있습니다.

• 사내 도구 10개의 사용법이 익숙해짐
• 팀의 코드베이스 구조를 머릿속에 그릴 수 있음
• 작은 기능 하나를 혼자 처음부터 끝까지 만들 수 있음
• 누구한테 무엇을 물어볼지 감이 잡힘
• 회사 동료 20명 정도와 친해짐

여전히 모르는 게 산처럼 많습니다. 하지만 "어떻게 배워나갈지"의 길이 보이기 시작합니다.

미니소프트가 신입에게 약속하는 것​

• 혼자 헤매지 않게 — 멘토, 1-on-1, 학습 시간
• 실수가 두렵지 않게 — 단계적 배포, 자동 롤백
• 목소리를 낼 수 있게 — 수평 호칭, 누구나 의견 가능
• 계속 성장하게 — 학습 시간, 컨퍼런스 지원, 도서 구입비

기술은 빠르게 변합니다. 그래서 미니소프트는 "지금 잘하는 사람"보다 "함께 성장할 사람"을 찾습니다.

마치며​

신입 개발자의 첫 달은 어렵습니다. 모르는 게 너무 많고, 따라가기 벅찰 때도 있죠. 그래서 미니소프트는 환경, 동료, 문화를 통해 그 시간을 함께 견뎌냅니다. 우리와 함께 성장할 분들을 늘 환영합니다.

핵심 요약 mini Labs는 미니소프트가 AI와 업무 시스템을 어떻게 준비하고 실험해 왔는지 기록하는 공간입니다. 기술 변화 자체보다, 그 변화를 실제 업무와 제품으로 연결하는 과정을 중심으로 공유합니다.

2년간의 AI 준비 기간, 그리고 지금도 계속되는 변화의 기록​

지난 2년 동안 우리는 LLM 기반 AI 기술을 준비해왔습니다.

처음에는 단순한 챗봇을 만드는 것에서 시작했습니다. 하지만 시간이 지날수록 질문은 달라졌습니다.

• AI는 문서를 이해할 수 있을까?
• 이미지를 이해할 수 있을까?
• 기업 데이터를 안전하게 연결할 수 있을까?
• 여러 AI Agent가 함께 일할 수 있을까?

우리는 이런 질문에 답하기 위해 수많은 기술을 테스트하고, 여러 PoC와 파일럿 프로젝트를 수행했습니다.

어떤 실험은 기대 이상이었고, 어떤 실험은 생각보다 어려웠습니다. 하지만 그 모든 과정이 우리를 성장시켰습니다.

6개월이 멀다 하고 변해가는 기술 트렌드​

기술 변화의 속도는 정말 빠릅니다. 불과 6개월 전만 해도 최신 기술이라고 생각했던 것이, 지금은 새로운 기술에 자리를 내어주기도 합니다.

RAG가 주목받던 시기를 지나 멀티모달 LLM이 등장했고, MCP는 AI Agent의 새로운 표준으로 자리 잡아가고 있습니다.

이러한 변화의 속도만큼이나, 우리 회사 내부의 기술 변화도 빠르게 진행되고 있습니다.

회사와 솔루션, 함께 진화하고 있습니다​

우리는 기술 트렌드에 맞추어 자사 솔루션을 지속적으로 업그레이드하고 있습니다.

단순한 챗봇에서 시작해 RAG 기반 지식검색, Vision AI, 멀티모달 문서 이해, MCP 기반 AI Agent, Enterprise Security, Mini App Platform까지 기술의 변화에 맞추어 계속 확장하고 있습니다.

우리가 만드는 솔루션은 완성된 제품이라기보다, 계속 진화하는 플랫폼에 가깝습니다.

우리가 기록하고 싶은 것​

MiniSoft Labs는 완성된 답을 보여주기 위한 공간이 아닙니다.

우리가 어떤 기술을 선택했고, 무엇을 실험했으며, 무엇이 잘 되었고, 무엇이 어려웠는지를 기록하는 공간입니다.

기술은 계속 변합니다. 그리고 우리도 계속 변해갑니다.

MiniSoft Labs는 그 변화의 여정을 함께 기록하겠습니다.