백서 다운로드-업무전문가가 만드는 AI Agent, 오픈소스 AAS 소개

목차 (Agenda)

백서 다운로드 — 챗봇 다음 단계부터 도입 결재 점검표까지

이 백서는 12개 장으로 구성됩니다. 1–4장은 챗봇과 AI Agent의 차이, AI 산업이 AI Agent 쪽으로 옮겨 가는 이유, 조직 AI의 다섯 단계, 내부 sLLM과 폐쇄망이 필요한 이유를 다룹니다. 5–7장은 업무 담당자가 에이전트를 만드는 방식을 견적 작성 사례와 OPENMARU AAS의 제품 정의로 설명합니다. 8–12장은 도구 비교, 주요 기능, 도입 전후 업무 차이, Apache-2.0 오픈소스의 의미, 도입 순서를 정리합니다.

시장 수치는 원출처를 확인한 것만 실었고, 제품의 부족한 점도 같은 비중으로 적었습니다. 아래 버튼을 누르면 OPENMARU AAS 백서 109쪽 전문을 PDF 한 파일로 받을 수 있습니다.

👉 백서 다운로드 : 업무전문가가 만드는 AI Agent, 오픈소스 AAS 소개 (109쪽 PDF)

MSAP.ai 백서 구독하기🔔

새로운 백서 소식을 가장 먼저 만나보세요!

MSAP.ai 가 전하는 AI 기반 운영 인사이트와 최신 백서 소식을 가장 빠르게 받아보실 수 있습니다.

구독해 주시면 더 좋은 콘텐츠로 보답하겠습니다.🙏

영상으로 먼저 보기

클라우드네이티브TV의 「AI Agent 오픈소스 관리 도구 – AI Agent Studio」 영상은 OPENMARU AAS 화면을 직접 보여 줍니다.

백서는 화면 뒤에 있는 설계 이유와 도입 판단 기준을 글로 풀어 씁니다. 영상으로 화면 흐름을 먼저 익힌 뒤 백서로 넘어가면 장마다 설명하는 기능을 떠올리기 쉽습니다.

이 백서가 답하는 7가지 질문

도입을 검토하는 조직이 실제로 묻는 질문 일곱 가지에 차례로 답합니다.

사내 챗봇이 이미 있는데 AI Agent는 무엇이 다른가
AI 산업이 AI Agent 쪽으로 옮겨 간다는 근거는 무엇인가
우리 조직의 AI는 지금 몇 단계이고 다음 단계는 무엇인가
왜 외부 LLM이 아니라 조직 안의 sLLM에서 에이전트를 돌려야 하는가
코딩을 모르는 업무 담당자가 정말 에이전트를 만들 수 있는가
OPENMARU AAS가 있을 때와 없을 때 업무는 어떻게 달라지는가
오픈소스 제품을 도입하면 지원과 책임은 누가 지는가

챗봇이 답에서 멈추고 AI Agent가 결과물까지 가는 차이

챗봇과 AI Agent를 가르는 기준은 처리가 어디에서 끝나느냐입니다. 사내 RAG(검색한 사내 자료를 근거로 답하는 방식) 챗봇은 질문 한 번에 답변 한 번으로 끝나고, 그 답을 업무 시스템에 옮겨 적는 일은 여전히 사람이 맡습니다. AI Agent는 목표를 받은 뒤 계획, 도구 호출, 결과 확인을 업무가 끝날 때까지 반복해 견적서나 처리 기록 같은 결과물을 남깁니다. Anthropic은 2024년 12월 「Building effective agents」에서 에이전트를 언어 모델이 스스로 처리 과정과 도구 사용을 정하는 시스템으로 정의했습니다. 백서는 이 차이를 다섯 기준으로 나눕니다.

▲ 질문→사내 자료 검색→답변 출력으로 끝나는 RAG 챗봇의 단일 턴과, 계획→도구 호출→결과 확인→수정을 반복해 업무 시스템에 결과물을 남기는 AI Agent의 실행 반복 (백서 5쪽)

그림의 왼쪽은 답변 뒤에 사람이 이어받는 일이고, 오른쪽은 에이전트가 업무 시스템에 남기는 결과물입니다.

기준	챗봇(RAG 챗봇 포함)	AI Agent
자율성	질문할 때마다 한 번 응답	다음 행동을 스스로 정함
도구	없거나 문서 검색 하나	조회·작성·등록 도구를 골라 호출
기억	현재 대화창의 맥락만 유지	규칙·작업 이력·중간 결과를 저장
권한	문서를 읽는 권한	업무 시스템에 쓰는 권한, 필요한 곳은 사람 승인
실행 반복	질문 한 번에 응답 한 번	계획→실행→확인→수정을 끝날 때까지 반복

에이전트가 단계마다 사람에게 묻지 않는다는 점은 처리를 빠르게 하는 이유이면서 사람의 확인이 필요한 이유이기도 합니다. 첫 단계에서 잘못 고른 조건이 다음 단계의 입력으로 그대로 이어지고, 도구 실행을 되풀이하는 만큼 모델이 읽고 쓰는 토큰도 늘어납니다. 그래서 에이전트에게 일을 맡길 때는 쓸 수 있는 도구의 범위와 결과를 확인할 사람을 처음부터 함께 정해 둡니다.

AI 사용 88%와 회사 전체 확산 7% 사이가 AI Agent로 가는 이유

AI를 쓰는 조직은 크게 늘었지만 업무 구조로 정착한 조직은 아직 소수입니다. McKinsey 「The State of AI in 2025」(2025년 11월)에 따르면 응답 조직의 88%가 최소 한 개 업무 기능에서 AI를 정기적으로 쓰며, 이는 전년 78%보다 늘어난 수치입니다. 생성형 AI 정기 사용은 2023년 33%에서 2025년 79%로 올랐습니다. 반면 조직 전체로 완전히 확산했다는 답은 7%에 그쳤고, 확산을 시작한 조직도 약 3분의 1입니다. 가트너는 2026년 말까지 기업용 애플리케이션의 40%가 업무 특화 AI 에이전트를 통합할 것으로 전망했습니다(2025년 5% 미만). 옴디아(Omdia)는 기업용 에이전틱 AI 소프트웨어 시장이 2025년 약 15억 달러에서 2030년 418억 달러로 커질 것으로 봤습니다.

▲ AI 정기 사용 88%와 회사 전체 완전 확산 7% 사이의 간격 (McKinsey, The state of AI in 2025, 2025년 11월) (백서 13쪽)

가트너는 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 비용 상승, 불분명한 가치, 위험 통제 부족으로 취소될 것이라는 경고도 함께 냈습니다.

백서는 88%와 7% 사이의 간격을 업무 하나 단위로 판정합니다. 결과물이 업무 시스템에 남아 다른 사람이 이어받는지, 같은 업무가 정해진 주기나 요청마다 반복되는지, 규칙이 바뀌었을 때 업무 담당자가 직접 고쳐 계속 쓰는지를 묻고, 세 질문을 모두 통과한 업무가 아직 적다는 것이 이 간격의 정체라고 봅니다. 기업용 애플리케이션에 따라 들어오는 에이전트와 달리 조직 고유의 규칙을 담은 에이전트는 업무 담당자가 규칙을 정의해야 만들어지므로, 업무 담당자가 에이전트 제작에 참여하는 방법이 함께 필요해집니다.

사람이 손을 떼는 범위로 조직의 AI 단계를 재는 기준

조직의 AI 활용 수준은 Prompt, Context, Loop, AI Agent, Agentic AI 다섯 단계로 나누고, 단계를 가르는 기준은 사람이 일의 어디까지 직접 맡느냐입니다. 사내 챗봇을 도입한 조직도 대부분 질문을 잘 쓰거나 사내 자료를 붙여 답을 받는 앞의 두 단계에 머뭅니다. Loop(계획·실행·확인·재시도를 AI가 스스로 반복하는 단계)부터 사람의 역할이 결과를 옮겨 적는 일에서 결과를 확인하는 일로 바뀝니다. 백서는 업무가 요구하는 가장 낮은 단계에서 시작하라고 권합니다. 단계가 오를수록 비용과 응답 시간이 늘고 오류 원인을 찾기도 어려워지기 때문입니다.

▲ Prompt에서 Agentic AI까지 다섯 계단과 계단마다 사람이 하는 일 — 매번 묻기·결과 입력·결과 확인·승인·목적 관리 (백서 22쪽)

계단 위의 표시는 단계마다 사람이 하는 일이고, Context와 Loop 사이가 전환점입니다.

단계	새로 붙는 기술	사람이 하는 일	견적 업무로 본 예
Prompt	질문을 잘 쓰는 방법	매번 묻고 결과를 옮겨 적음	견적 안내 문구를 물어봄
Context	사내 자료 검색	근거가 붙은 결과를 옮겨 적음	사내 견적 규정을 찾아 답함
Loop	계획·실행·확인·재시도 반복	목표를 주고 결과를 확인	금액을 계산하고 규칙을 스스로 점검
AI Agent	도구·기억·권한	승인할 곳에서만 승인	CRM에 견적을 만들고 PDF 저장
Agentic AI	여러 에이전트의 분담과 조율	목적과 결과를 관리	영업기회 등록·견적·기술 문서가 이어짐

다음 단계로 올라가는 데 필요한 것은 더 큰 모델보다 업무 시스템 연결과 판정 기준입니다. OPENMARU AAS에서는 업무 시스템을 MCP 서버와 스킬로 붙이고, 비밀값과 권한을 작업공간마다 따로 관리하며, 업무 담당자가 말로 정한 판정 기준을 코딩 에이전트가 점검 코드와 시험으로 옮깁니다. 이 준비가 끝난 업무 하나가 시범 도입의 첫 후보가 됩니다.

생성형 AI가 LLM, RAG, Agent, Agentic으로 넘어가는 흐름을 장표로 먼저 보고 싶다면 생성형 AI 진화 4단계 — LLM에서 Agentic까지 자료를 함께 읽어 볼 만합니다.

AI Agent가 외부 LLM 대신 내부 sLLM에서 일해야 하는 이유

AI Agent는 챗봇보다 훨씬 넓은 업무 자료를 모델에 보내므로 조직 안의 sLLM(조직 장비에서 직접 서빙하는 수십억–수백억 파라미터 규모의 언어 모델)에서 일해야 합니다. 에이전트가 조회한 고객 정보, 견적 금액, 계약 문서는 도구 호출 결과로 다시 모델 입력에 실립니다. 외부 LLM을 쓰면 그 자료가 호출마다 조직 밖으로 나갑니다. 작은 모델이 긴 다단계 판단에서 약한 점은 설계로 메웁니다. 판단은 미리 만든 코드가 맡고, 모델은 요청의 뜻을 읽어 해당 코드를 실행하는 한 줄만 맡습니다. OPENMARU AAS는 모든 모델 호출이 사내 모델 게이트웨이(LiteLLM)를 거치게 하고, 실행 중에 외부망을 쓰지 않습니다.

▲ 외부 LLM을 쓰면 도구 호출 결과가 매 호출 조직 밖으로 나가고, 내부 sLLM을 쓰면 같은 자료가 조직 안에 머문다 (백서 31쪽)

모델을 고를 때는 도구 사용에 필요한 64,000 토큰 이상의 문맥을 지원하는지 먼저 점검해야 합니다.

업무 담당자가 말로 정하고 코딩 에이전트가 코드를 쓰는 분담 구조

AI Agent는 업무 규칙을 아는 업무 담당자가 말로 정의할 때 가장 정확하게 만들어집니다. 개발자를 새로 뽑거나 외부에 구축을 맡기면 규칙을 아는 사람과 코드를 짜는 사람이 달라서 규칙이 전달 과정에서 빠지고 바뀝니다. 업무 담당자는 목적, 판정 기준, 검수를 맡고 규칙을 말로 정합니다. 코딩 에이전트(코드를 대신 작성하는 AI)는 그 말을 규칙 파일, 점검 코드, 시험으로 옮깁니다. IT 담당자는 모델, 권한, 시스템 연동, 운영 환경을 맡습니다.

▲ 업무 담당자는 규칙과 판정 기준을 말로 정하고, 코딩 에이전트는 규칙 파일·점검 코드·시험을 만들고, IT 담당자는 모델·권한·시스템 연동을 맡는다 (백서 42쪽)

결과 검수는 다시 업무 담당자에게 돌아옵니다.

AI 기초부터 보기인공지능(AI)이란 무엇인가요?뜻·종류·작동 원리부터 2026년 현황까지 한 번에 정리했어요가이드 읽기 →

견적 사례에서 만드는 단계와 일하는 단계를 나누는 기준

견적 작성 에이전트는 만드는 단계와 일하는 단계로 나눠야 보안 검토에 정확히 답할 수 있습니다. 만드는 단계에서는 영업 업무 담당자가 규칙을 평범한 문장으로 말하고, 코딩 에이전트가 규칙과 예시 자료만 다루며 견적 스킬을 만듭니다. 일하는 단계에서는 사내 sLLM 에이전트가 채팅 첫 줄이 「견적」인 요청을 받아 아홉 단계로 처리합니다. 고객사와 사업명 확인부터 CRM 견적 생성, PDF 저장, 영업기회 일지 기록까지입니다. 사람이 확인하는 지점은 네 번이고, CRM에 견적을 실제로 만드는 일은 마지막 확인을 받은 뒤에만 실행됩니다.

▲ 만드는 단계(업무 담당자의 말 + 코딩 에이전트, 규칙·예시 자료)와 일하는 단계(사내 sLLM 에이전트, 고객·금액 자료가 조직 안에 머무는 경로) — 두 흐름은 견적 스킬 하나로만 만난다 (백서 47쪽)

두 흐름은 견적 스킬 하나로만 만나고, 고객과 금액 자료는 일하는 단계 안에서만 움직입니다.

말 한 줄이 규칙 파일과 점검 코드, 시험으로 바뀌는 흐름

업무 담당자는 규칙을 말로만 고치고, 나머지 산출물은 코딩 에이전트가 만듭니다. 예를 들어 「공공기관 견적서는 VAT 포함으로 작성」이라는 말은 제목 말머리, 전용 서식, 세액 이중 부과 금지 규칙이 됩니다. 코딩 에이전트는 CRM에 쌓인 지난 견적에서 문서에 없던 작성 관행도 찾아 규칙으로 옮겼습니다. 견적 스킬의 규칙 15개는 규칙 파일 하나에 모여 있고, 이를 실행하는 스크립트 약 4,600줄과 시험 코드 약 1,500줄도 코딩 에이전트가 작성했습니다. 규칙을 바꾸면 새 규칙을 지난 견적 전체에 다시 대어 통과, 경고, 차단 건수를 보여 줍니다.

▲ 업무 담당자의 말 → 규칙 파일 → 점검 코드 → 시험 → 규칙 페이지·업무 투입으로 이어지는 흐름과 말로 고치는 개선 순환 (백서 50쪽)

잘못 처리된 요청을 말로 알리면 그 사례가 시험에 추가되어 같은 오류가 다시 나오지 않게 됩니다.

만들기·시키기·지켜보기·나누기를 한 화면에 모은 OPENMARU AAS 구조

OPENMARU AAS는 업무 담당자가 자기 에이전트를 만들고, 일을 시키고, 지켜보고, 조직 안에서 나누는 웹 Studio입니다. 오픈소스 에이전트 플랫폼 Hermes Agent에 연결하며, 코드는 공개 저장소 openmaru-io/ai-agent-studio에 Apache-2.0으로 공개되어 있습니다. 에이전트 플랫폼의 기본 창구가 메신저 채팅뿐이면 스킬을 만드는 일, 맡긴 일이 끝났는지 확인하는 일, 잘 만든 스킬을 나누는 일이 채팅 화면에서 처리되지 않습니다. 사용자마다 작업공간이 하나씩 생기고, 플랫폼 데이터 폴더에 직접 쓰지 않고 공식 API로만 변경합니다.

▲ 만든다·시킨다·지켜본다·나눈다 네 동작과 OPENMARU AAS의 대응 화면 — 한 작업공간 안에서 이어지는 순환 (백서 59쪽)

지켜보기에서 찾은 문제가 다시 만들기로 돌아가는 순환이 같은 작업공간 안에서 이어집니다.

업무마다 에이전트를 나누는 것도 같은 이유입니다. 영업 업무와 재무 업무를 한 에이전트에 맡기면 두 업무의 접속 정보와 대화 기록이 한곳에 쌓여, 에이전트가 다른 업무의 맥락으로 답하거나 맡은 일에 필요 없는 비밀 정보까지 갖게 됩니다. 역할마다 에이전트를 따로 두는 구성은 Agentic AI 멀티에이전트 프로필과 역할 기반 팀 구성 백서에서 자세히 다룹니다.

대화에서 승인과 예약 작업까지 이어지는 주요 기능

업무 담당자의 화면은 대화, 승인, 예약 작업 순서로 이어집니다. 채팅 창에서 일을 시키고 「/」 메뉴로 스킬을 붙이며, 사람의 허락이 필요한 작업은 승인 카드로 모입니다. 같은 일은 예약 작업으로 정해진 주기마다 되풀이하고 결과를 메신저로 받습니다. 스킬은 개인 작업공간에서 만든 뒤 관리자의 게시 검토를 거쳐 사내 스킬 허브에 올라가고, 다른 부서가 설치해 씁니다. 권한은 관리자, 팀 관리자, 작업공간 주인, 일반 사용자 네 가지입니다. 질문 가드레일과 위험한 명령 차단은 화면에서 끌 수 없으며, 대화 모델 목록에는 운영자가 정한 이름 규칙에 맞는 게이트웨이 모델만 나타납니다.

▲ 업무 담당자가 채팅으로 일을 시키고, 스킬을 붙이고, 승인 카드에 답하고, 예약 작업으로 되풀이하는 흐름 (백서 73쪽)

그림은 채팅, 스킬 붙이기, 승인, 평일 아침 예약 실행까지 네 화면의 흐름입니다.

예약 작업은 사람이 보지 않는 동안 실행되므로 실행 기록에 담을 내용도 달라집니다. 담당자가 중간 결과를 읽고 다음 지시를 내리던 확인 절차가 빠지면, 조회 단계에서 기간을 잘못 잡았을 때 작성 단계는 틀린 데이터로 그럴듯한 보고서를 만들고 발송 단계는 그 보고서를 그대로 내보냅니다. 그래서 실행 기록에는 성공과 실패 여부와 함께 각 실행이 어떤 스킬과 도구를 거쳤는지가 남아야 담당자가 원인을 거꾸로 따라갈 수 있습니다.

관련 실무 가이드AI Agent Studio ↗

OPENMARU AAS가 있을 때와 없을 때 달라지는 업무 장면

AAS가 있으면 업무 담당자는 규칙 재설명과 결과 재입력에서, IT 담당자는 흩어진 에이전트와 예약 작업 관리에서 벗어납니다. 견적 요청 한 건으로 보면 도입 전에는 다섯 단계를 모두 사람이 처리합니다. 도입 후에는 스킬과 점검 코드가 처리하고 사람은 고객·영업기회 확인과 품목·최종 확인 두 지점에서만 답합니다. 백서는 처리 시간 수치를 지어내지 않고, 도입 조직이 시범 도입 전후에 처리 시간, 규칙 위반 차단 건수, 사람 확인 횟수를 직접 재도록 측정 틀을 제시합니다.

▲ 견적 요청 한 건이 요청 접수부터 PDF 저장·영업기회 일지 기록까지 가는 동안 사람 손이 가는 단계의 도입 전후 비교 (백서 82쪽)

표는 백서의 업무 장면 여덟 가지 가운데 다섯 가지를 옮긴 것입니다.

업무 장면	AAS가 없을 때	AAS가 있을 때
업무 방법 만들기	개발자에게 규칙을 설명하고 구현을 기다림	말로 정의하면 에이전트가 스킬로 만듦
업무 규칙 변경	다시 설명하고 수정·배포를 기다림	말로 고치고 지난 견적 전체에 다시 대어 봄
반복 보고	실패해도 뒤늦게 앎	실패·멈춤 작업이 한 화면에 모임
자료와 모델	직원이 외부 AI 서비스에 자료를 붙여 넣음	조직 안 sLLM과 게이트웨이 모델만 사용
담당자 교체	업무 방법이 사람과 함께 떠남	스킬과 예약 작업이 작업공간에 남음

첫 시범 업무는 시작 신호와 사람이 판단하는 단계가 분명하고, 결과물이 위키, CRM, 드라이브처럼 조직이 이미 쓰는 시스템에 쌓이는 업무에서 고르는 것이 판단하기 쉽습니다. 명함 인식, 화자를 구분한 회의록, 공공 서식 채우기가 이런 조건을 갖춘 예입니다. 한 업무에서 정착을 확인한 뒤 사내 스킬 허브로 다른 부서에 넓히는 순서가 위험이 가장 작습니다.

Apache-2.0 공개 코드에서 지원 책임을 세 층으로 나누는 방법

OPENMARU AAS의 코드는 OSI 승인 허용형 라이선스인 Apache-2.0이므로 도입 조직은 설치, 수정, 재배포를 할 수 있고 공급사 종속 위험이 작습니다. 다만 회사 이름과 로고는 Apache-2.0의 허락 범위가 아니라 별도 상표 정책을 따르므로, 수정 배포본에는 회사 이름이 들어간 제품명을 쓸 수 없습니다. 공개본은 Docker Compose로 작업공간 하나를 실행하며, 사용자마다 작업공간을 두는 쿠버네티스 구성은 공개하지 않았습니다. 지원 책임은 공개 코어, 조직 스킬, 사내 허브 세 층으로 나눕니다. 개발자에게는 스킬과 MCP(에이전트가 외부 도구를 부르는 표준 규약) 연동이 확장 지점으로 열려 있습니다.

▲ 공개 코어·조직 스킬·사내 허브의 3층 구조와 층별 책임 주체 — 업무 결과의 정확성 책임은 스킬을 만든 부서에 남는다 (백서 92쪽)

업무 결과의 정확성에 대한 책임은 결국 스킬을 만든 부서에 남습니다.

발전 8단계의 현재 위치와 도입 4단계 순서

OPENMARU AAS는 발전 방향을 8단계로 정해 두었고, 2026년 11월 현재 앞의 네 단계를 제공하고 다음 두 단계를 일부 제공합니다. 내 에이전트 보기, 화면에서 고치기, 콘솔 안에서 일 시키기, 사람마다 자기 에이전트가 제공 단계입니다. 사내 스킬 허브는 결제 없이 일부 제공되고, 팀 공용 에이전트와 두 번째 에이전트 플랫폼 연결은 착수 전입니다. 도입은 AI 단계 진단, 내부 sLLM 준비, 첫 업무 정의, 부서 확산의 4단계로 나누고 단계마다 결재 산출물을 남깁니다. 가트너는 2025년 말까지 생성형 AI 프로젝트의 최소 30%가 PoC 뒤 중단될 것으로 전망했으므로, 첫 업무는 한 부서의 좁은 업무 하나로 시작해야 합니다.