AI 에이전트와 사내 시스템을 연동하는 3가지 방법 | 안전 설계와 비용

AI 에이전트와 사내 시스템을 연동하는 3가지 방법 | 안전 설계와 비용

안녕하세요, 주식회사 Webharu 대표이사 구리타입니다. 일본 미야기현 시오가마시에 있는 회사지만 상담은 거의 온라인으로 받고 있으며, 안건 비율은 일본 전국이 약 6~7할, 해외가 약 2할, 미야기현 내가 약 1할입니다.

결론부터 말씀드립니다. AI 에이전트와 사내 시스템을 연결하는 방법은 API 연동·CLI 툴·MCP 서버의 3가지입니다. 직원이 매일 쓰는 Claude나 ChatGPT에서 사내 시스템을 다루게 하고 싶다면, 정답은 MCP 서버입니다. 그리고 “AI에 전권을 주지 않는다”는 운영 규칙이 아니라 구조로 만들 수 있습니다.

“ChatGPT나 Claude는 사내에 도입했다. 그런데 고객 관리나 재고 시스템에는 AI가 닿지 않아서, 결국 스크린샷과 복사·붙여넣기로 데이터를 옮기고 있다.” AI 도입 상담에서 가장 자주 듣는 상태입니다. Webharu는 자사 SaaS 2개에서 MCP 서버를 실제 운영하고 있으므로, 그 설계를 그대로 바탕으로 씁니다.

AI 에이전트와 사내 시스템을 연결하는 3가지 방법인 API 연동·CLI 툴·MCP 서버를 맞는 케이스·AI와의 궁합·개발 규모로 비교한 표. AI에서 직접 조작하게 하려면 MCP 서버
결정적인 기준은 “어느 AI를, 누가 쓰는가”
이 글의 요점
AI 에이전트와 사내 시스템의 연동란?
AI 에이전트와 사내 시스템의 연동이란 고객 관리·재고·핵심 시스템 등의 업무 시스템을 AI에서 읽고 쓸 수 있게 하는 것입니다. 방법은 API 연동·CLI 툴·MCP 서버의 3가지이며, 직원이 쓰는 Claude나 ChatGPT에서 직접 조작하게 하려면 MCP 서버가 정답입니다.
목차

AI 에이전트와 사내 시스템을 연결하는 방법은 3가지

어느 것을 쓸지는 어느 AI를 누가 쓰는가로 정해집니다.

  • API 연동: 시스템에 외부에서 읽고 쓸 수 있는 입구를 만든다. 모든 연동의 토대가 된다
  • CLI 툴: 사내 툴 쪽에서 AI를 호출한다. 특정 업무에 작게 AI를 더한다
  • MCP 서버: Claude나 ChatGPT 등의 AI에서 사내 시스템을 직접 조작할 수 있게 하는 공통 규격

정해진 처리를 뒤에서 돌리기만 한다면 API 연동으로 충분합니다. 특정 사내 툴에 AI 기능을 하나 더하고 싶을 뿐이라면 CLI가 가장 빠른 길입니다. 직원이 대화하고 있는 AI 자체에 조작을 맡기고 싶다면 MCP 서버를 고르십시오.

API 연동 | 업무 시스템과 AI를 잇는 토대

API는 시스템을 외부에서 읽고 쓰기 위한 입구입니다. 입구가 없는 시스템에는 AI도 프로그램도 닿지 못합니다. Webharu는 자사 CMS인 HaruCMS에 REST API(기사 작성·조회·수정·삭제, 이미지 업로드 등)를 만들고, 그 위에 MCP 서버를 얹었습니다. API라는 토대가 먼저 있었기 때문에 MCP는 얇게 만들 수 있었습니다. 설계 기록은 자사 SaaS 2개를 MCP에 대응시킨 글에 있습니다.

다만 API만 있는 상태에서 AI에 쓰게 하려고 하면, 엔드포인트와 인증 방식을 매번 AI에 설명해야 하는 수고가 남습니다. AI와의 대화 속에서 시스템을 조작하고 싶다면 API 위에 한 단계(MCP)가 더 필요합니다.

CLI 툴 | 사내 툴 쪽에서 AI를 호출한다

API와 MCP가 “AI가 사내 시스템을 다루는” 방향이라면, CLI 툴은 반대 방향입니다. 사내 툴 쪽에서 AI를 호출합니다.

Webharu는 로컬 앱이나 사내 툴에서 API 키 없이 Claude를 호출할 수 있는 CLI 브리지를 직접 만들어, AI 사이트 빌더 안건에서 쓰고 있습니다. API 키를 발급해 각 툴에 나눠 주면 키 관리와 유출 대책이 그대로 운영 부담이 됩니다. 반면 브리지를 거치면 나눠 줄 키 자체가 없습니다.

맞는 것은 “AI가 견적서 초안을 써 주는 버튼이 있으면 좋겠다” 같은 특정 업무로의 작은 연동입니다. 대신 툴마다 개별 개발이 되므로, 전사적으로 AI를 쓰는 토대로는 MCP를 고릅니다.

MCP 서버 | 직원이 쓰는 AI에서 직접 조작한다

MCP(Model Context Protocol)는 AI가 외부 시스템을 조작하기 위한 공통 규격입니다. API가 시스템의 입구라면, MCP는 AI가 그 입구를 쓰기 위한 손입니다. MCP 서버를 준비해 두면 직원이 Claude나 ChatGPT에 “지난주 문의를 목록으로 만들어 줘”, “이 글을 초안으로 등록해 줘”라고 부탁하기만 해도 사내 시스템이 움직입니다.

Webharu는 CMS인 HaruCMS에서 툴 8개짜리 MCP 서버와 개발자용 문서·llms.txt를 일반 공개했고, 메일 API인 HaruMail에서도 송수신을 MCP로 조작할 수 있게 해 두었습니다. 팔기 위한 견본이 아니라, 매일 저희가 직접 쓰는 구조입니다.

한편 외부 SaaS의 범용 MCP(Webflow MCP 1.0)를 시험했을 때는 연결하기만 해도 대량의 정보를 읽어 들여 AI 컨텍스트의 대부분을 써 버려서 실용적이지 않았습니다(Webflow MCP를 시험해 본 글). 그래서 자사 MCP는 툴 수를 줄이고, 돌려주는 정보를 작게 유지하는 설계로 했습니다. MCP는 만들면 끝이 아닙니다. 이 설계의 질이 쓸 수 있느냐 없느냐를 가릅니다.

AI 에이전트에 사내 시스템을 맡기는 안전 설계 4가지

정보시스템이나 DX 담당자분들이 가장 신경 쓰는 것은 “AI에 사내 시스템의 키를 넘겼다가 마음대로 삭제되거나 전송되지는 않을까”입니다. 답은, 위험한 조작을 애초에 실행할 수 없는 형태로 API와 MCP를 만들면 AI에 전권을 주지 않고도 연결할 수 있다는 것입니다.

“AI에 신중하게 지시합시다” 같은 운영 규칙으로는 지킬 수 없습니다. 지키는 것은 구조입니다. 아래 4가지는 Webharu가 자사 서비스의 실제 운영에서 쓰고 있는 설계입니다. 품의나 경영층 설명에서는 “만에 하나 AI가 오작동해도 피해는 구조상 이 범위에서 멈춘다”고 단언할 수 있는지가 관건이므로, 그 형태로 씁니다.

AI 에이전트와 사내 시스템을 연결할 때의 안전 설계 4가지. 키 자동 실효, 위험 조작의 2단계화, 감사 로그, 쓰기 허용 목록. 운영 규칙만으로 지키는 것은 피한다
4가지 모두 Webharu 자사 서비스에서 실제 운영 중인 설계

키 실효 | 사람이 빠지면 키도 멈춘다

HaruCMS에서는 멤버를 정지하면 그 사람이 발급한 API 키도 자동으로 실효됩니다. 키가 계정과 별개로 살아남으면 “로그인은 막았는데 밖에서는 아직 쓸 수 있다”는 구멍이 생기기 때문입니다. 인사이동이나 퇴직이 있는 사내 시스템이라면 가장 먼저 넣어 두고 싶은 항목일 것입니다.

위험 조작의 2단계화 | 한 번에 실행할 수 없는 API로 만든다

HaruMail에서는 송신 계열 툴이 전부 “초안을 만드는” 데까지만 할 수 있습니다. 실제 송신은 confirm_send라는 별도의 툴로만 실행할 수 있는 구조입니다. AI가 오해하더라도 초안이 1통 생길 뿐입니다. 메일 송신·결제·삭제·공개처럼 되돌릴 수 없는 조작은 모두 같은 사고방식으로 2단계로 만들 수 있습니다.

감사 로그 | 모든 조작을 나중에 추적할 수 있다

쓰기 조작은 전부 감사 로그에 남깁니다. 언제·어느 키가·무엇을 했는지 알 수 있으므로, 예상 밖의 움직임이 있어도 바로 특정하고 그 키만 멈출 수 있습니다.

허용 목록 | 쓸 수 있는 범위를 처음부터 좁힌다

Webharu의 운영 기반을 조작하는 관리용 MCP에서는 쓸 수 있는 조작을 안전한 허용 목록 안으로만 좁혀 두었습니다. 전부 만질 수 있는 키를 넘기고 쓰는 쪽이 조심하는 것이 아니라, 넘기는 권한 자체를 작게 하는 사고방식입니다.

AI 에이전트와 사내 시스템은 읽기 전용부터 3단계로 연결한다

처음부터 핵심 시스템에 대한 쓰기는 계획하지 마십시오. Webharu가 권하는 진행 방식은 3단계입니다.

AI 에이전트와 사내 시스템을 연동하는 3단계. 읽기 전용으로 시작해 2단계 승인이 붙은 쓰기, 감사 로그를 갖춘 본격 운영으로 넓힌다
각 단계마다 “무슨 일이 있어도 피해는 여기까지”가 정해져 있다
  1. 읽기 전용으로 연결한다: AI에는 데이터를 읽는 것만 허용합니다. 쓰기 권한이 없으므로 삭제되거나 덮어써지는 사고는 구조상 일어나지 않습니다. “AI가 사내 데이터에 대해 답할 수 있다”는 것만으로 복사·붙여넣기 전기 작업의 대부분이 사라집니다
  2. 쓰기를 2단계 승인을 붙여 연다: 등록·송신·공개는 “AI가 초안을 만들고, 사람이 확인해 확정한다”는 형태로 더합니다. HaruMail의 confirm_send와 같은 사고방식입니다
  3. 본격 운영: 감사 로그와 키 관리를 갖춘 다음, 대상 시스템과 허용하는 조작을 넓힙니다

이 순서라면 어느 단계에서도 피해의 상한이 정해져 있습니다. 품의도 “우선 읽기 전용 범위에서”처럼 단계로 나누면 승인하는 쪽의 판단 재료가 갖춰져 통과되기 쉬워집니다.

AI 에이전트와 사내 시스템의 연동 비용(Webharu의 경우)

Webharu의 개발 메뉴도 위의 3단계에 맞추어 두었습니다(세금 별도·2026년 10월 기준).

메뉴내용요금
MCP 스타터기존 API에 읽기 전용 MCP를 씌우는 입문 단계. 기간 기준 4~6주¥2,500,000~
API+MCP 풀팩API 설계부터 인증·레이트 리밋·감사 로그·위험 조작의 2단계화·MCP 서버·개발자용 문서까지 일체¥5,000,000~
풀 통합쓰기까지 개방·여러 AI에서 사용·업무 시스템별 개별 견적¥10,000,000~
운영 보수API 사양 변경 대응·모니터링·키 관리월 ¥150,000~

개발 기간은 현재 시스템에 API가 있는지에 따라 크게 달라집니다. 잘 정비된 API가 이미 있으면 MCP를 씌우는 부분은 얇게 끝나고, 없으면 접속 창구 설계부터 시작하는 만큼 길어지기 때문입니다. 외주처를 고를 때 물어봐야 할 것은 MCP 서버 개발 비용 시세에 관한 글에 5가지로 정리했습니다.

AI 도입의 벽은 AI의 성능이 아니라 접속 창구

AI 도입이 잘 안 되는 원인의 대부분은 AI의 성능이 아니라, AI가 자사 데이터에 닿지 못하는 데 있습니다. 뒤에서 도는 자동 처리는 API, 작은 연동은 CLI, 직원의 AI에서 직접 쓰게 하려면 MCP. 그리고 안전은 키 실효·2단계화·감사 로그·허용 목록이라는 구조로 만든다. Webharu가 자사 서비스의 실제 운영에서 확인해 온 결론입니다.

API·MCP 서버 개발은 인증·레이트 리밋·감사 로그·공개 문서까지 일체로 맡고 있습니다(API·MCP 개발 서비스 페이지). “우리 회사의 이 업무를 AI에 맡길 수 있을까?”라는 판단만이라도 괜찮으니 무료 상담으로 보내 주십시오. MCP와 API 구현의 후속 이야기는 뉴스레터(메일은 일본어)에서 먼저 공개하고 있습니다.

제작 실적

자주 묻는 질문

AI 에이전트와 사내 시스템의 연동 개발에는 얼마가 드나요?

Webharu에서는 3단계입니다(세금 별도·2026년 10월 기준). 읽기 전용 MCP 스타터가 ¥2,500,000~(기간 기준 4~6주), API 설계부터 인증·감사 로그·MCP 서버·개발자용 문서까지 일체인 풀팩이 ¥5,000,000~, 쓰기까지 개방하는 업무 시스템별 풀 통합이 ¥10,000,000~입니다. 운영 보수는 월 ¥150,000~입니다.

AI 에이전트와 사내 시스템을 연결하는 방법에는 무엇이 있나요?

3가지입니다. 시스템끼리 뒤에서 연결하는 API 연동, 사내 툴 쪽에서 AI를 호출하는 CLI 툴, Claude나 ChatGPT 등의 AI에서 직접 조작할 수 있는 MCP 서버. 직원이 매일 쓰는 AI에 사내 시스템을 다루게 하고 싶다면 MCP 서버입니다.

사내 시스템이 오래되어 API가 없습니다. AI 에이전트와 연동할 수 있나요?

가능합니다. 그 경우에는 접속 창구(API) 설계부터 시작합니다. 모든 기능을 API로 만들 필요는 없으며, AI에 맡기고 싶은 업무의 데이터만 읽기 전용 입구를 먼저 만드는 것이 정석입니다.

AI가 사내 데이터를 삭제하거나 외부로 보내지는 않나요?

구조로 막습니다. Webharu의 실제 운영에서는 멤버를 정지하면 키도 자동으로 실효된다, 송신 등의 위험 조작은 확인용 별도 툴을 거치지 않으면 실행할 수 없다, 모든 쓰기를 감사 로그에 남긴다, 쓰기는 허용 목록의 조작만 가능하다, 이 4가지를 넣어 두었습니다.

ChatGPT와 Claude 어느 쪽에서도 쓸 수 있나요?

MCP 서버로 만들면 Claude·ChatGPT·Cursor 등 대응하는 AI 어느 것에서든 같은 접속 창구를 쓸 수 있습니다. 특정 AI 전용으로 만들어 넣지 않는 것이, 갈아탈 때 다시 만들지 않기 위한 요점입니다.

먼저 무엇부터 시작하면 되나요?

사내에서 “화면을 보면서 복사·붙여넣기로 옮겨 적는” 일이 가장 많은 업무를 하나 골라, 그 데이터를 읽기 전용으로 AI에 연결하는 것부터입니다. 쓰기 권한이 없으므로 사고는 구조상 일어나지 않고, 효과는 금방 알 수 있습니다.