- AI 에이전트와 사내 시스템의 연동란?
- AI 에이전트와 사내 시스템의 연동이란 고객 관리·재고·핵심 시스템 등의 업무 시스템을 AI에서 읽고 쓸 수 있게 하는 작업을 말합니다. 방법은 ①API 연동 ②CLI 툴 ③MCP 서버의 3가지이며, 직원이 쓰는 AI 클라이언트(Claude·ChatGPT 등)에서 직접 조작하게 하려면 MCP가 가장 유력한 선택지입니다.
안녕하세요, Webflow 전문가에서 AI 웹사이트 제작·AI 개발로 주 무대를 넓히고 있는 마사토입니다. 일본 미야기현 시오가마시에서 웹 제작 회사 “Webharu”를 하고 있습니다.
“ChatGPT나 Claude는 사내에 도입했다. 그런데 고객 관리나 재고 같은 업무 시스템에는 AI가 닿지 않아, 결국 스크린샷과 복사·붙여넣기로 데이터를 나르고 있다”——AI 도입 상담에서 가장 자주 듣는 상태입니다. 이 글은 고객 관리·재고·핵심 시스템 같은 업무 시스템을 가진 기업의 정보시스템 담당·DX 담당·기술 책임자를 위해 썼습니다(앞으로 새로 서비스를 만들고 싶은 개인·소규모를 위한 내용은 아닙니다). AI 에이전트와 사내 시스템을 연동하는 방법을 3가지로 정리하고, 어느 것을 언제 고를지, 그리고 품의나 경영층 설명에서 반드시 질문받는 “AI에 전권을 주지 않는 안전 설계”까지, 자사에서 실제 운영 중인 사례를 기반으로 해설합니다.
✓이 글의 내용
- 연동 방법은 3가지——API 연동·CLI 툴·MCP 서버
- 3방식 비교표(맞는 케이스·AI 클라이언트와의 궁합·개발 규모감)
- 3방식 각각의 해설과, 저희의 실제 사례
- “AI에 전권을 주지 않는” 안전 설계 만드는 법(품의·사내 설명에 그대로 쓸 수 있는 형태로)
- 읽기 전용부터 작게 시작하는 진행법
결론: AI 에이전트와 사내 시스템의 연동 방법은 3가지
결론부터 씁니다. 사내 시스템을 AI 에이전트에서 조작할 수 있게 하는 방법은 크게 다음 3가지입니다.
- ①API 연동——시스템에 “밖에서 읽고 쓸 수 있는 입구”를 만든다. 모든 연동의 토대가 되는 기본형
- ②CLI 툴——사내 툴이나 앱 쪽에서 AI를 호출한다. 특정 업무에 작게 AI를 넣는 방식
- ③MCP 서버——Claude·ChatGPT·Cursor 등의 AI 클라이언트에서 사내 시스템을 직접 조작할 수 있게 하는 표준 규격
구분해 쓰는 결론도 먼저. 직원이 매일 쓰는 AI에 사내 시스템을 만지게 하고 싶다면 정답은 MCP입니다. 정해진 처리를 뒤에서 자동으로 돌리기만 한다면 API 연동으로 충분합니다. 특정 사내 툴에 AI 기능을 하나 넣고 싶을 뿐이라면 CLI가 최단입니다.
3방식 비교——결정타는 “어느 AI에서·누가 쓰는가”
위 표를 한 줄로 정리하면, “직원이 대화하고 있는 AI 그 자체에 조작시키고 싶다면 MCP, 그 외는 용도 나름”입니다.
API 연동은 시스템끼리 뒤에서 잇는 자동 처리(매일 밤 데이터를 동기화한다, 폼 내용을 기간계에 등록한다 등)에 맞습니다. 다만 API만 있는 상태로 AI에 쓰게 하려면, 엔드포인트나 인증 설명을 매번 AI에 가르치는 “번역의 수고”가 남습니다.
CLI 툴은 방향이 반대로, 사내 앱 쪽에서 AI를 호출합니다. 만드는 범위가 작게 끝나는 반면, 앱마다 개별 개발이 됩니다.
MCP 서버는 Claude·ChatGPT·Cursor 등 대응 AI 클라이언트에서 직접 쓸 수 있는 공통 규격이라는 점이 결정타입니다. 특정 AI 서비스 전용으로 만들어 넣으면 갈아탈 때마다 다시 만들어야 하지만, MCP라면 AI 쪽을 바꿔도 연결 지점은 그대로 쓸 수 있습니다(2026년 시점에 대응 클라이언트는 계속 늘고 있습니다). 오래 쓰는 업무 시스템일수록 여기서 효과가 큽니다.
방법①API 연동——업무 시스템과 AI를 잇는 기본형
API는 “시스템에 밖에서 읽고 쓰기 위한 입구”입니다. AI 이전부터 있던 구조지만, AI 연동에서도 모든 토대는 여기입니다. 입구가 없는 시스템에는 AI도 프로그램도 닿을 수 없습니다.
저희 실제 사례에서는 자사 CMS “HaruCMS”에 REST API(글의 작성·취득·갱신·삭제, 이미지 업로드 등)를 구현하고, 그 위에 뒤에서 이야기할 MCP 서버를 얹었습니다. 먼저 API라는 토대가 있으므로 MCP는 얇게 만들 수 있다——이 순서가 정석입니다. 설계 판단의 전 기록은 자사 CMS에 API와 MCP 서버를 구현한 이야기에 썼습니다.
API 연동이 단독으로 맞는 것은 사람도 AI도 개입하지 않는 자동 처리입니다. 반대로 “AI와의 대화 안에서 시스템을 조작하고 싶다”면, API 위에 한 단(MCP)이 더 필요합니다.
방법②CLI 툴——사내 툴에 AI를 넣는 것은 역방향의 연동
①과 ③이 “AI가 사내 시스템을 만진다” 방향인 데 비해, CLI 툴은 “사내 툴 쪽에서 AI를 호출한다”는 역방향의 연동입니다.
저희 실제 사례를 들겠습니다. 로컬 앱이나 사내 툴에서 AI(Claude)를 API 키 없이 호출할 수 있는 CLI 브리지를 자체 개발해, AI 사이트 빌더의 실제 프로젝트에서 쓰고 있습니다. API 키를 발행해 각 툴에 나눠 주면 키 관리와 유출 대책이 그대로 운용 부담이 되는데, 이 방식이라면 그 걱정거리 자체를 없앨 수 있습니다.
맞는 것은 “견적 초안을 AI에 쓰게 하는 버튼이 있으면 좋겠다” 같은, 특정 업무에의 핀포인트 AI 도입입니다. 작게 만들 수 있는 반면, 툴마다 개별 개발이 되므로 전사적 AI 활용의 토대에는 ③의 MCP를 고릅니다.
방법③MCP 서버——AI 클라이언트에서 직접 쓸 수 있는 표준 규격
MCP(Model Context Protocol)는 AI가 외부 시스템을 조작하기 위한 공통 규격입니다. API가 “시스템의 입구”라면, MCP는 “AI가 그 입구를 쓰기 위한 손”에 해당합니다. MCP 서버를 준비하면 직원이 쓰는 Claude나 ChatGPT와의 대화 안에서 “지난주 문의를 목록으로 보여 줘” “이 글을 초안으로 등록해 줘” 같은 조작이 직접 가능해집니다.
저희는 자사 SaaS 2개에서 MCP 서버를 구현해 실제 운영하고 있습니다. CMS인 “HaruCMS”에서는 툴 8개짜리 MCP 서버와 개발자 문서·llms.txt까지 일반 공개하고 있고, 메일 API인 “HaruMail”에서는 송수신을 MCP 경유로 조작할 수 있습니다. 팔기 위한 그림이 아니라, 매일 저희가 쓰고 있는 구조입니다.
직접 겪어서 얻은 배움도 있습니다. 외부 SaaS의 범용 MCP(Webflow MCP 1.0)를 시험해 봤더니, 접속하는 것만으로 대량의 정보를 읽어 들여 AI의 컨텍스트 대부분을 소비해 실용에 닿지 않았습니다(실측 상세는 Webflow MCP를 시험한 글). 이 경험에서 자사 MCP는 “툴 수를 좁힌다·돌려주는 정보를 작게 유지한다” 설계를 철저히 하고 있습니다. MCP는 만들면 끝이 아니라, 이 설계 품질로 실용성이 결정됩니다.
MCP 서버 만드는 법의 실무는 MCP 서버 개발 해설 글에, 기존 SaaS·자사 서비스에 얹는 이야기는 SaaS에의 MCP 도입 글에 나눠 썼습니다.
안전 설계——“AI에 전권을 주지 않는다”는 구조로 만들 수 있다
DX 담당·정보시스템 담당의 가장 큰 불안은 여기라고 생각합니다. “AI에 사내 시스템의 키를 주고, 멋대로 지워지거나 보내지지 않을까.” 답부터 쓰면, 위험한 조작을 애초에 실행할 수 없는 형태로 API·MCP를 설계하면, AI에 전권을 주지 않고 연동할 수 있습니다. “AI에 정중히 지시합시다”라는 운용 룰 의존으로는 지킬 수 없습니다. 지키는 것은 구조입니다. 아래 4가지는 품의서나 경영층 설명 자료에 그대로 쓸 수 있는 형태로 듭니다——“만에 하나 AI가 오작동해도, 피해는 구조상 이 범위에서 멈춘다”고 잘라 말할 수 있는 것이 사내 승인의 결정타가 되기 때문입니다. 저희가 실제 운영 중인 설계는 다음 4가지입니다.
①키의 무효화 설계——사람이 빠지면 키도 멈춘다
HaruCMS에서는 멤버를 정지하면, 그 사람이 발행한 API 키도 자동으로 무효화됩니다. 키가 계정과 독립적으로 살아남으면 “로그인은 막았는데 외부에서는 아직 쓸 수 있다”는 구멍이 생기기 때문입니다. 담당자의 이동·퇴직을 피할 수 없는 사내 시스템에서는 이 설계가 첫 번째 필수 항목입니다.
②위험 조작의 2단계화——한 방에 실행할 수 없는 API로 만든다
HaruMail에서는 발송 계열 툴은 전부 “초안 작성”까지만 가능하고, 실제 발송은 confirm_send라는 별도 툴로만 실행할 수 있습니다. AI가 오해해도 초안이 1통 생길 뿐입니다. 프롬프트로 “멋대로 보내지 마”라고 부탁하는 것이 아니라, 애초에 한 방에 보낼 수 없는 구조로 만든다——메일 발송·결제·삭제·공개처럼 되돌릴 수 없는 조작은 전부 같은 발상으로 2단계화할 수 있습니다.
③감사 로그——전 조작을 기록하고, 나중에 추적할 수 있다
모든 쓰기 조작을 감사 로그에 기록합니다. 언제·어느 키가·무엇을 했는지가 남으므로, 예상 밖의 움직임이 있어도 바로 특정할 수 있고 해당 키만 멈출 수 있습니다.
④허용 리스트——쓸 수 있는 범위를 처음부터 좁힌다
자사 운영 기반을 조작하는 관리 MCP에서는 쓰기 가능한 조작을 안전한 허용 리스트 안으로 한정하고 있습니다. “전부 만질 수 있는 키를 주고 쓰는 쪽이 조심한다”가 아니라, 주는 권한 자체를 좁힙니다.
진행법——읽기 전용부터 작게 시작하는 3단계
처음부터 핵심 시스템에의 쓰기를 계획하지 마세요. 저희가 추천하는 진행법은 3단계입니다.
- 제1단계: 읽기 전용으로 잇는다. AI에는 데이터 참조만 허용합니다. 쓰기 권한이 없으므로 사라지거나 덮어써지는 사고는 구조상 일어나지 않습니다. “AI가 사내 데이터에 답할 수 있다”는 것만으로 화면을 보며 복사·붙여넣기로 옮겨 적는 작업의 대부분이 사라집니다
- 제2단계: 쓰기를 2단계 승인 방식으로 개방한다. 등록·발송·공개는 “AI가 초안을 만든다→사람이 확인해 확정한다” 형태로 추가합니다. 위의 HaruMail의 confirm_send와 같은 발상입니다
- 제3단계: 본격 운영. 감사 로그와 키 관리를 갖춘 뒤, 대상 시스템과 허용할 조작을 넓혀 갑니다
이 순서라면 각 단계에서 “뭔가 있어도 피해는 여기까지”라는 상한이 늘 정해져 있습니다. 작게 시작해 효과가 보인 범위만 넓히는 것이 AI 연동의 정석입니다.
저희 개발 메뉴도 이 3단계에 대응합니다. 제1단계에 해당하는 MCP 스타터(읽기 전용)가 ¥2,500,000(세금 별도·기준 4~6주), REST API 설계부터 인증·인가·레이트 리밋·감사 로그·위험 조작의 2단계화·MCP 서버·개발자 문서까지 일체인 API＋MCP 풀팩이 ¥5,000,000(세금 별도), 쓰기 전면 개방·복수 AI 클라이언트·업무 시스템별의 풀 통합이 ¥10,000,000~(세금 별도·개별 견적)입니다. 품의도 “우선 읽기 전용 범위에서”라고 단계로 끊으면, 승인의 판단 재료가 갖춰져 통과시키기 쉬워집니다.
정리: AI 활용의 벽은, AI의 성능이 아니라 연결 지점
AI 도입이 잘 안 되는 원인의 대부분은 AI의 성능이 아니라, AI가 자사의 데이터에 닿지 못하는 것입니다. 연동 방법은 3가지——뒤의 자동 처리는 API, 핀포인트 도입은 CLI, 직원의 AI에서 직접 쓰게 하려면 MCP. 그리고 안전은 운용 룰이 아니라, 무효화 설계·2단계화·감사 로그·허용 리스트라는 구조로 만든다. 저희가 자사 서비스의 실제 운영에서 확인해 온 결론입니다.
Webharu에서는 API·MCP 서버 개발을 인증·레이트 리밋·감사 로그·공개 문서까지 일체로 받고 있습니다(API·MCP 개발의 서비스 상세). “우리 이 업무는 AI에 맡길 수 있나?”라는 판정만이라도 괜찮으니, 무료 상담에서 부담 없이 오세요.
자주 묻는 질문
AI 에이전트와 사내 시스템의 연동 개발은 얼마나 드나요?
저희는 3단계 메뉴로 받고 있습니다(모두 세금 별도). ①MCP 스타터(읽기 전용) ¥2,500,000——기존 REST API에 읽기 전용 MCP 층을 씌우는 입구 플랜으로 기준 4~6주 ②API＋MCP 풀팩 ¥5,000,000——REST API 설계부터 인증·인가·레이트 리밋·감사 로그·위험 조작의 2단계화·MCP 서버·개발자 문서까지 일체 ③풀 통합 ¥10,000,000~——쓰기 전면 개방·복수 AI 클라이언트·업무 시스템별 개별 견적. 운용 보수는 월 ¥150,000~입니다. 품의를 통과시키기 쉬운 점에서 읽기 전용 스타터로 시작하는 기업이 다수입니다.
개발 기간은 어느 정도 걸리나요?
기존 시스템에 API가 있는지에 따라 크게 달라집니다. 정리된 API가 이미 있으면 MCP 서버를 씌우는 부분은 얇게 끝나고, 없으면 연결 지점(API) 설계부터 시작하므로 길어집니다. 저희는 “읽기 전용의 작은 범위를 먼저 움직이고, 효과를 보고 나서 넓힌다”는 단계 방식을 취하므로, 첫 성과까지의 거리를 짧게 할 수 있습니다.
기존 사내 시스템이 낡아서 API가 없습니다. 연동할 수 있나요?
할 수 있습니다. 그 경우는 연결 지점(API) 설계부터 시작합니다. 전 기능을 API화할 필요는 없고, AI에 만지게 하고 싶은 업무의 데이터만 먼저 읽기 전용 입구를 만드는 것이 정석입니다. 토대인 API가 생기면 그 위에 MCP 서버를 얹어 사내의 AI 클라이언트에서 쓸 수 있게 합니다.
AI가 사내 데이터를 멋대로 지우거나 외부로 보내지는 않나요?
설계로 막습니다. 저희 실제 운영에서는 ①멤버를 정지하면 그 사람이 발행한 키도 자동으로 무효화 ②메일 발송 등 위험 조작은 confirm_send라는 별도 툴을 거치지 않으면 실행할 수 없는 2단계제 ③모든 쓰기 조작을 감사 로그에 기록 ④쓰기는 허용 리스트 안의 조작만——의 4가지를 구조에 심어 두었습니다. 운용 룰이 아니라 구조로 지키는 것이 원칙입니다.
ChatGPT와 Claude, 어느 쪽에서든 쓸 수 있나요?
MCP 서버로 만들면 Claude·ChatGPT·Cursor 등 대응 AI 클라이언트 어디에서든 같은 연결 지점을 쓸 수 있습니다(2026년 시점에 대응 클라이언트는 계속 늘고 있습니다). 특정 AI 서비스 전용으로 만들어 넣지 않는 것이, 갈아탈 때 다시 만들지 않기 위한 요점입니다.
우선 무엇부터 시작하면 되나요?
사내에서 가장 “화면을 보면서 복사·붙여넣기로 옮겨 적고 있는” 업무를 하나 골라, 그 데이터를 읽기 전용으로 AI에 잇는 것부터 시작하세요. 쓰기 권한이 없으므로 사고는 구조상 일어나지 않고, 효과는 바로 체감할 수 있습니다. 어느 업무가 맞는지 모르겠다면, “이건 AI에 맡길 수 있나?”의 판정만이라도 저희 무료 상담을 쓰실 수 있습니다.
