업무 전문가가 만드는 AI 에이전트-AI Agent Studio(AAS) 제품 소개 [발표자료 다운로드]

MSAP.ai AAS(AI Agent Studio)는 그 화면을 만드는 제품이다. 업무 규칙이 바뀔 때마다 IT 개발 요청을 거치지 않고 담당자가 직접 에이전트를 고치고, 관리자와 보안 담당은 같은 데이터를 역할에 맞는 화면으로 본다.

전체 45장, PDF로 45쪽이다. 표지와 목차를 빼면 일곱 편으로 나뉘고, 편마다 간지 한 장과 본문 네 장에서 다섯 장, 정리 한 장으로 이루어진다. 화면은 운영 설치본과 쿠버네티스 배포본에서 찍은 예시이며, 숫자는 조직마다 달라진다.

강점만 적지 않았다. 아직 부족한 다섯 항목과 각 항목의 대응 방법을 강점과 같은 비중으로 담았다.

도입 검토 회의나 부서 공유 자료로 바로 쓸 수 있도록 원본 구성 그대로 PDF로 공개한다.

이 발표자료는 영상 일곱 편으로 나눠 설명하도록 구성했다. 한 편이 질문 하나에 답하므로 필요한 편부터 보아도 된다.

아래 재생목록은 클라우드네이티브TV의 AI 에이전트와 AX 영상 모음이다.

발표자료의 일곱 편은 다음 순서로 이어진다.

에이전트의 구조와 기업 도입 기준을 먼저 정리하려면 AI 에이전트란 무엇인가를 함께 보면 된다.

AI 에이전트 콘솔을 검토하는 회의에서 반복해서 나오는 질문을 기준으로 슬라이드를 배치했다.

1. MSAP.ai AAS는 어떤 제품인가
2. AAS가 맞는 조직은 어떤 조건을 갖췄는가
3. AAS는 Hermes Agent의 무엇을 바꾸는가
4. 업무 담당자는 콘솔에서 무엇을 하는가
5. 정기 업무의 실패는 어떻게 드러나는가
6. 보안 담당은 무엇을 확인할 수 있는가
7. 파일럿은 어떻게 시작하는가

탑재는 공급사가 정하고 정착은 담당자가 정한다. 둘 사이에 만들고 지켜볼 창구가 없으면 에이전트는 시험 단계에서 멈춘다.

Gartner는 특정 업무용 AI Agent를 탑재한 기업용 애플리케이션이 2025년 5% 미만에서 2026년 말 40%로 늘어난다고 전망했다. 같은 시기 McKinsey 조사에서 업무 기능 하나를 기준으로 확대 적용까지 간 비율은 10%를 넘지 않았다. Gartner는 2027년 말까지 에이전트형 AI 프로젝트의 40% 이상이 비용 증가와 불분명한 사업 가치, 부족한 위험 통제로 중단된다고 본다.

AI 에이전트의 개념과 기업 도입 효과를 먼저 정리하려면 AI 에이전트(AI Agent)란? Agentic AI 개념부터 기업 도입까지를 함께 보면 된다.

▲ AI Agent 탑재는 공급사가 정하고 업무 정착은 담당자가 정한다 (발표자료 4쪽)

메신저는 사람끼리 대화하려고 만든 도구라서 진행 단계와 실행 승인과 되묻기가 모두 같은 말풍선으로 흘러간다. 승인이 “네” 한 줄로 끝나면 승인할 때 무엇을 보았는지 기록되지 않는다.

설정도 흩어진다. 에이전트마다 봇을 등록하고 토큰을 복사하며, 모델과 스킬과 정기 업무는 설정 파일과 서버 폴더와 명령줄 도구에 나뉘어 있다. 동작이 바뀌어도 원인을 대화창에서 찾을 수 없다.

챗봇은 질문 하나에 답 하나를 돌려주고 멈추므로 다음 일을 정하는 주체가 언제나 사람이다. 에이전트는 목표를 받으면 어떤 도구를 부르고 언제 멈출지를 스스로 판단해 여러 단계를 이어 간다. 그래서 챗봇을 고를 때 쓰던 검토 항목만으로는 되돌리기 어려운 동작을 걸러 내지 못하고, 실행 직전에 사람이 무엇을 보고 승인하는지를 따로 설계해야 한다.

▲ 채팅 창구에서는 승인이 메시지 한 줄로 끝나 무엇을 보고 승인했는지 남지 않는다 (발표자료 5쪽)

실행의 대부분은 사람이 화면을 보지 않는 동안 일어난다. 운영 설치본의 최근 7일 세션 152개 가운데 92%가 사람의 대화가 아니라 정기 업무에서 시작됐다.

전달 대상이 없는 정기 업무는 실패해도 아무도 모른다. 처음부터 전달 대상 없이 만든 작업, 대화방이 지워져 대상이 사라진 작업, 퇴사자의 개인 대화방으로 남은 작업이 그렇다. 이런 실패는 결과를 기다리던 사람이 가장 늦게 발견한다.

한 번 써 보는 것과 같은 업무를 계속 맡기는 것은 요구가 다르다. 반복 업무를 에이전트에게 넘기려면 수행 절차를 저장해 두는 기억, 담당자가 자리에 없어도 요청이 들어오는 채널, 사람 없이 도는 무인 실행, 결과를 확인하는 검증이 함께 있어야 한다. 정기 업무의 실패를 드러내는 화면은 그 가운데 검증 자리를 채운다.

▲ 에이전트 세션의 92%는 사람이 보지 않는 정기 업무에서 시작된다 (발표자료 6쪽)

AI Agent 도구는 만드는 쪽 셋과 지켜보는 쪽 셋으로 나뉜다. 만드는 쪽은 상용 에이전트 빌더, 오픈소스 워크플로 빌더, 채팅 워크스페이스다. 지켜보는 쪽은 관제와 거버넌스 도구, 플랫폼 전용 콘솔, 조직 운영 콘솔이다.

제작 도구는 자사 실행 엔진을 전제로 하고, 관측 도구는 운영자와 보안팀을 위한 것이다. 업무 담당자가 한 제품으로 만들기와 지켜보기를 함께 하는 선택지는 비어 있다. 조직 안 설치, 업무 담당자 사용, 만들기와 지켜보기, 쓰던 플랫폼 연결을 모두 갖춘 구분은 발표자료의 교차표에서 하나도 나오지 않는다.

▲ 만드는 도구와 지켜보는 도구 사이에 업무 담당자 자리가 비어 있다 (발표자료 9쪽)

국가 망 보안체계 N²SF는 업무 정보를 기밀, 민감, 공개 세 등급으로 나누고, 기밀 등급 업무는 분리된 망에 남긴다. 그 업무에서는 외부 클라우드 빌더가 기능과 관계없이 검토 대상에서 빠진다.

남는 길은 두 가지다. 빌더와 런타임과 스토어를 한 공급사가 제공하는 온프레미스 일체형 플랫폼을 새로 들이거나, 쓰던 오픈소스 에이전트 플랫폼 위에 콘솔만 얹는다. AAS는 두 번째 방식이다. 외부 클라우드를 쓸 수 있는 조직이라면 완성도가 더 높은 글로벌 클라우드 빌더를 먼저 검토하는 편이 맞다.

▲ N²SF 기밀 등급 업무에서는 외부 클라우드 빌더가 검토 대상에서 빠진다 (발표자료 11쪽)

AAS에서 담당자가 정의하는 대상은 셋이다. 누가 일하는지는 에이전트와 프로파일, 어떻게 일하는지는 스킬, 언제 일하는지는 정기 업무로 정한다. 실행은 플랫폼이 맡는다.

콘솔의 기능은 만들기, 시키기, 지켜보기, 나누기 네 묶음이다. 1980~90년대 디베이스와 폭스프로가 데이터베이스 엔진 위에서 현업이 업무 프로그램을 직접 만들게 했듯이, AAS는 같은 역할 분담을 에이전트에 적용한다. 선례가 남긴 관리 문제인 판 이력과 고칠 사람의 부재는 스킬 판 관리와 실패 관측으로 다룬다.

▲ AAS에서는 담당자가 정의하고 플랫폼이 실행한다 (발표자료 15쪽)

지금 AAS가 연결하는 플랫폼은 오픈소스 Hermes Agent 하나다. 읽는 길은 런타임부터 MCP 서버까지 모든 계층에 닿고, 바꾸는 길은 프로파일과 스킬과 정기 업무까지만 닿는다.

런타임의 플러그인과 설정과 버전은 바꾸지 않는다. MCP(Model Context Protocol) 서버와 외부 시스템은 호출 관계와 자격증명의 이름과 위치만 읽는다. 그래서 AAS가 멈춰도 정기 업무는 플랫폼에서 계속 실행되고, 콘솔을 붙이거나 떼어도 운영 중인 에이전트에 영향이 없다.

▲ AAS가 멈춰도 정기 업무는 Hermes Agent에서 계속 실행된다 (발표자료 16쪽)

사람마다 에이전트를 받고, 그 안에 업무별 프로파일을 둔다. 프로파일마다 성격 문서와 모델과 스킬과 정기 업무와 메신저 연결을 따로 가진다.

새 프로파일은 기존 프로파일을 복제하거나 다른 에이전트에서 가져와 시작한다. 이때 비밀값은 복사되지 않는다. 사용자당 에이전트는 기본 세 개이고, 30일 동안 쓰지 않거나 사내 로그인 그룹에서 빠지면 데이터를 남긴 채 자동으로 멈춘다. 스킬은 저장할 때마다 판이 남고, 에이전트가 스스로 고친 스킬도 판 비교로 검토한다.

▲ 업무 구성은 나눠 쓰되 비밀값은 복제와 가져오기에서 따라가지 않는다 (발표자료 21쪽)

팀 채팅은 진행 단계 카드와 승인 카드와 되묻기 카드를 따로 보여 준다. 실행하려는 명령은 실행 전에 승인 카드로 올라오고, 빠진 조건은 질문마다 한 장씩 묻는다.

봇 등록과 토큰 복사 없이 콘솔 로그인만으로 에이전트와 대화한다. 회의 탭은 한 메시지를 여러 에이전트에게 동시에 보내고, 정해진 할 일은 칸반 카드로 이어진다. 파일럿 단계에서는 회의방을 조직 안 설치본으로 한정하고, 외부 에이전트 연결은 별도 보안 검토를 거친다.

2026년의 AI 도입 논의는 모델 성능 비교에서 권한 설계로 옮겨 왔다. OWASP Gen AI Security Project는 2025년 12월 9일 에이전트 애플리케이션의 10대 위험 목록을 공개했다. 실행 전 승인을 기록으로 남기는 화면은 그 권한 설계가 운영 중에도 지켜지는지 확인하는 수단이다.

▲ 승인 카드가 명령마다 사람의 확인을 대화 기록에 남긴다 (발표자료 23쪽)

첫 화면의 오늘 볼 것은 실패한 작업, 만료가 다가온 자격증명, 답을 기다리는 대화처럼 사람이 바로 처리할 항목만 모은다. 화면 예시는 게이트웨이 12개 중 9개 실행, 활성 정기 업무 76개, 실패 1건, 만료 또는 임박 자격증명 7개다.

게이트웨이가 꺼진 프로파일의 정기 업무는 실패로도 기록되지 않는다. 그래서 9/12 같은 실행 상태는 실패 건수만큼 중요한 신호다. 하루 두 번 08:30과 18:30에 요약을 메신저로 보내고, 실패가 0건이어도 보낸다. 요약이 오지 않으면 그것이 수집이나 발송 이상의 신호다.

▲ 게이트웨이가 꺼진 프로파일의 정기 업무는 실패로도 기록되지 않는다 (발표자료 24쪽)

AAS에는 문서 판독부터 개인 비서까지 10개 카테고리의 업무 에이전트 예시가 들어 있다. 세 카테고리는 사람이 보낸 사진과 파일과 녹음으로 시작하고, 일곱은 정기 업무가 중심이다.

명함 인식은 조직 안 AI 게이트웨이의 비전 모델로 명함을 읽는다. 어느 시스템에 무엇을 쓸지 예행 결과를 먼저 보여 주고, 같은 사람이 있으면 멈춰서 갱신 여부를 되묻고, 없는 회사는 만들지 않는다. 중복 고객사가 하나 생기면 이후 영업 집계가 모두 어긋나므로, 판독 정확도보다 기록 전 확인이 잘못된 등록을 막는다.

▲ 명함 인식은 판독 정확도 대신 기록 전 확인으로 잘못된 등록을 막는다 (발표자료 29쪽)

공문 판독은 HWP와 HWPX, PDF, DOCX를 문서 변환 도구 서버로 바꾸고, 스캔본은 외부 키가 필요 없는 CPU 오프라인 OCR로 읽는다. 공공서식은 채울 값을 먼저 보여 주고 확인을 받은 뒤 저장한다.

화자 구분 회의록은 조직 안 GPU 서버에서 음성 인식과 화자 분리를 하고, 근거가 없는 화자는 미확인으로 남긴다. 지시사항은 지시 원장으로, 할 일은 칸반으로 갈라진다. 두 업무 모두 외부 OCR이나 STT 없이 끝나므로 기밀 등급 업무가 남은 기관에서도 같은 구성으로 실행할 수 있다.

▲ 공문 판독과 화자 구분 회의록은 외부 OCR·STT 없이 조직 안에서 끝난다 (발표자료 30쪽)

Cron 헬스체크는 정기 업무의 상태를 다섯 가지로 나눈다. 지금도 실패 중, 이미 풀림, 마지막 실행 실패, 멈춘 작업, 알림이 안 가는 작업이다.

화면 예시에서는 정기 업무 95개 가운데 활성 76개, 이미 풀린 사건 62건, 알림이 안 가는 작업 15개였다. 이미 풀린 기록을 따로 떼어 오래된 기록이 진짜 문제를 가리지 않게 한다. 읽지 못한 프로파일은 0건이 아니라 수집 실패로 표시한다. 0이라는 숫자를 믿을 수 있어야 운영 판단을 내릴 수 있다.

▲ 읽지 못한 프로파일은 0건이 아니라 수집 실패로 표시된다 (발표자료 34쪽)

자격증명 화면은 값을 보여 주지 않는다. 화면 예시에서 103개 가운데 만료 또는 임박 7개, 빈 값 3개, 백업과 임시 파일 8개, 여러 곳에 복사된 것 17개를 찾았다. 중복은 값의 해시를 비교해 같은 값이 몇 곳에 있는지로만 표시한다.

흐름 그림은 정기 업무에서 스킬과 스크립트를 거쳐 MCP 서버와 외부 호스트까지의 호출 관계를 스킬 문서와 실행 기록에서 자동으로 그리고, 선마다 근거 파일과 줄을 붙인다. 토큰을 바꾸기 전에 멈출 스킬과 정기 업무를 미리 찾을 수 있다.

▲ 자격증명을 값 없이 점검하고 토큰 교체 전에 멈출 스킬을 미리 찾는다 (발표자료 35쪽)

AAS는 플랫폼 데이터를 읽기 전용으로만 열고, 모든 변경은 Hermes Agent 공식 API로 보낸다. 플랫폼이 거절하면 거절 문구가 화면에 그대로 뜬다. 예외는 사내 마켓 패키지 설치와 삭제 두 가지뿐이다.

대화 본문과 호출 인자 값은 읽지 않는다. 변경 기록에는 누가 언제 무엇을 어떻게 바꿨는지를 남기되 비밀값의 값은 남기지 않는다. 콘솔 컨테이너에는 플랫폼 데이터 쓰기 권한도 컨테이너 엔진 소켓도 없다. 모델과 음성 인식과 OCR까지 조직 안에서 끝나는 온프레미스 구성도 같은 원칙을 따른다.

▲ AAS는 플랫폼을 읽기 전용으로 열고 변경은 공식 API 하나로 보낸다 (발표자료 36쪽)

AAS가 앞서는 항목은 대부분 관측 기능이다. 정기 업무 건강 감시, 실행 근거가 붙은 호출 관계 그림, 값 없는 자격증명 점검, 쓰던 플랫폼 위에 얹는 방식, 만들기와 지켜보기가 한 화면, 업무 에이전트 카탈로그 동봉이다.

부족한 항목은 첫 유즈케이스에 걸리는지부터 확인해야 도입 범위를 정할 수 있다.

▲ AAS가 앞서는 여섯 항목은 대부분 관측 기능이고 부족한 다섯 항목에는 대응이 있다 (발표자료 40쪽)

첫 유즈케이스는 반복량과 결과 확인 용이성, 사람 확인 단계, 연결 시스템 수, 외부 반출 여부로 고른다. 기준을 가장 많이 채운 후보 가운데 연결 시스템이 가장 적은 하나를 고르면, 명함 인식과 공문 판독이 먼저 올라온다.

파일럿은 첫 유즈케이스 확정, 조직 안 설치와 연결, 지켜보기, 사내 마켓 확산의 4단계다. 세 번째 단계는 성공 기준을 채우고 알림이 안 가는 작업이 0개일 때 넘어간다. 확인 시간이 수작업 시간보다 길면 중단하고 다음 후보로 간다. 확정 회의에는 부서 담당자와 IT 관리자와 보안 담당이 함께 앉아 업무 하나, 기준 하나, 책임자 한 명을 정한다.

▲ 파일럿은 기간이 아니라 다음 단계로 넘어가는 조건으로 나눈다 (발표자료 42쪽)

MSAP.ai AAS 도입에서 내릴 판단은 두 조건으로 좁혀진다. 업무 데이터를 외부 클라우드에 둘 수 없는가, 그리고 Hermes Agent를 운영하거나 도입할 계획인가. 둘 다 그렇다면 검토 대상이고, 외부 클라우드를 쓸 수 있다면 글로벌 클라우드 빌더를 먼저 본다.

AAS가 맞는 자리는 부서 담당자가 에이전트와 스킬을 직접 고치고, 관리자가 사람이 보지 않는 동안의 실행을 확인해야 하는 조직이다. 플랫폼을 고치지 않으므로 도입 위험이 콘솔 범위 안에 머문다.

검토를 시작한다면 다음 순서를 권한다.

1. 부족한 다섯 항목이 첫 업무에 걸리는지 확인해야 한다.
2. 반복량과 결과 확인 용이성과 연결 시스템 수로 첫 유즈케이스를 골라야 한다.
3. 단계마다 넘어가는 조건과 계속, 확대, 중단을 판단할 책임자를 정해야 한다.
4. 확정 회의에 부서 담당자와 IT 관리자와 보안 담당이 함께 참석해야 한다.

MSAP.ai AAS는 어떤 제품인가

AI Agent 플랫폼에 연결되는 일반 사용자용 콘솔이다. 부서 담당자가 에이전트와 스킬과 정기 업무를 직접 정의하고, 실행은 플랫폼이 맡는다. 만들기, 시키기, 지켜보기, 나누기 네 기능 묶음을 한 콘솔에서 제공한다.

AAS가 맞는 조직은 어떤 조건을 갖췄는가

업무 데이터를 외부 클라우드에 둘 수 없고, Hermes Agent를 운영하거나 도입할 계획인 조직이다. 외부 클라우드를 쓸 수 있으면 글로벌 클라우드 빌더를 먼저 검토하는 편이 맞다.

AAS는 Hermes Agent의 무엇을 바꾸는가

프로파일과 스킬 문서와 정기 업무만 공식 API로 바꾼다. 런타임의 플러그인과 설정과 버전은 바꾸지 않고, 플랫폼 데이터는 읽기 전용으로만 연다. AAS가 멈춰도 정기 업무는 플랫폼에서 계속 실행된다.

업무 담당자는 콘솔에서 무엇을 하는가

에이전트와 업무별 프로파일을 만들고, 스킬 문서를 판 이력과 함께 고치고, 정기 업무를 등록한다. 팀 채팅에서는 승인 카드로 명령을 확인하고, 사내 스킬 마켓에서 다른 부서가 만든 스킬을 설치한다.

정기 업무의 실패는 어떻게 드러나는가

Cron 헬스체크가 지금도 실패 중, 이미 풀림, 마지막 실행 실패, 멈춘 작업, 알림이 안 가는 작업으로 나눠 보여 준다. 첫 화면에 사람이 손댈 항목을 모으고, 하루 두 번 요약을 메신저로 보낸다.

보안 담당은 무엇을 확인할 수 있는가

자격증명을 값 없이 이름과 위치와 쓰는 곳으로 점검하고, 근거 줄이 붙은 호출 관계 그림과 변경 기록을 본다. 설계 원칙 다섯 가지는 설치본을 열어 원칙마다 직접 확인할 수 있다.

파일럿은 어떻게 시작하는가

결과 확인이 쉽고 연결 시스템이 적은 업무 하나를 첫 유즈케이스로 고른다. 이어서 조직 안 설치와 연결, 지켜보기, 사내 마켓 확산 순서로 진행하고, 단계마다 넘어가는 조건을 미리 정한다.

MSAP.ai 자료

• AI 에이전트란 무엇인가 — 정의, 구조, 기업 도입 기준
• 업무 담당자가 만드는 AI 에이전트 (AAS : AI Agent Studio) 백서
• Hermes Agent — AI 에이전트 도입 점검 기준과 보안 지침 발표자료
• AI 에이전트 필수 기능 여덟 가지, 도입 전 점검 기준
• 사내 AI 구축, 오픈소스 Hermes 에이전트와 Gemma 4 도입 가이드
• LiteLLM 제품 소개 — LLM 게이트웨이 기능과 도입 순서 발표자료
• AI 에이전트 개념부터 운영까지 — 설계, 도입, 보안
• AI 에이전트 플랫폼 도입 가이드 — AI Native Platform 체크리스트
• MCP(Model Context Protocol) — 레거시를 버리지 않고 AI 도입하는 해법
• AI 에이전트 빌더 4종 심층 비교
• 멀티 에이전트 시스템 설계 — 협업 패턴과 실패 모드

외부 자료

• Hermes Agent GitHub 저장소
• Model Context Protocol 공식 사이트

편별 정리 슬라이드와 첫 유즈케이스 후보 매트릭스, 역할별 파일럿 준비 목록이 PDF 한 파일에 들어 있다. 아래 버튼에서 같은 45쪽 PDF를 다시 내려받을 수 있다.