AI 도입 전략2026.08.04읽는 시간 9분
AI 시스템 연동이란? 5분 정리: 읽기·실행·기록
ERP·CRM을 AI에 붙이기 전에 정해야 할 세 개 층
—VIEWS
—LIKES
—SAVES
ERP·CRM을 AI에 붙이기 전에 정해야 할 세 개 층
AI 도입 상담에서 이 세 질문은 거의 늘 이 순서로 나옵니다. 세 질문은 각각 AI 시스템 연동의 서로 다른 층을 가리킵니다. 읽기, 실행, 기록입니다. 이 글에서는 연동을 이 세 층으로 나눠 보고 층마다 무엇을 정해야 하는지, 우리 회사는 어느 층까지 올려야 하는지, 비용과 기간은 어떻게 잡는지까지 정리합니다.
AI 시스템 연동은 AI가 사내 시스템의 데이터를 읽고 허용된 기능을 호출하고 그 결과를 기록으로 남기도록 경로를 설계하는 작업입니다. 모델을 바꾸거나 프롬프트를 다듬는 일과는 층이 다릅니다. GPT-5를 붙여도 ERP 로그인 정보가 없으면 지난달 매출은 나오지 않습니다.
많은 회사가 여기서 두 가지를 섞어서 생각합니다. 하나는 슬랙, 노션, 구글 드라이브처럼 담당자가 직접 쓰는 도구를 붙이는 일입니다. 다른 하나는 ERP, 그룹웨어, 사내 데이터베이스처럼 회사의 기간계 시스템을 붙이는 일입니다. 앞쪽은 대체로 SaaS가 제공하는 커넥터로 며칠 안에 끝나고 뒤쪽은 권한 체계와 감사 요건 때문에 설계가 필요합니다. 도구 레벨에서 먼저 막힌다면 AI 도구 연결이 왜 어려운지부터 보시는 게 순서에 맞습니다. 이 글은 기간계 시스템 쪽을 다룹니다.
기간계 시스템 연동이 까다로운 이유는 기술이 아니라 전제입니다. 사내 시스템의 권한은 사람을 기준으로 설계돼 있습니다. 영업 3팀 김 과장은 자기 담당 계정만 보고 재무팀은 전 계정을 보지만 계약서 원본은 못 봅니다. AI에게 계정을 하나 만들어 주는 순간, 이 설계에 없던 행위자가 하나 늘어납니다. 그 행위자가 무엇을 읽고 무엇을 바꿀 수 있는지 정하는 일이 연동 작업의 절반입니다.
같은 말로 쓰이는 경우가 많지만 다릅니다. API 연동은 시스템끼리 정해진 규격으로 데이터를 주고받는 기술 방식입니다. AI 시스템 연동은 그 API 위에서 "무엇을 호출할지 AI가 판단한다"는 조건이 하나 더 붙습니다. 이 조건 하나가 설계 산출물을 바꿉니다.
구분 | 기존 API 연동 | AI 시스템 연동 |
|---|---|---|
호출 대상 결정 | 개발자가 코드에 고정 | AI가 상황을 보고 선택 |
호출 시점 | 배치 일정 또는 이벤트 | 대화·요청이 들어올 때마다 |
입력값 | 검증된 스키마 | 자연어에서 해석한 값 |
실패 처리 | 재시도·예외 코드 | 재시도 + 사람 검토 경로 |
권한 단위 | 서비스 계정 1개 | 요청자 권한 승계 또는 역할별 분리 |
감사 대상 | 요청·응답 로그 | 요청·판단 근거·실행 결과 |
필요 산출물 | 인터페이스 명세 | 도구 목록 + 권한 표 + 승인 규칙 |
표에서 실무 부담이 가장 큰 줄은 마지막 두 줄입니다. 기존 연동에서는 명세서 하나로 끝났던 문서가 AI 연동에서는 "AI가 쓸 수 있는 기능 목록"과 "각 기능을 누구 권한으로 실행하는지", "어디까지는 사람 승인을 받는지"까지 세 벌로 늘어납니다.
도입 순서가 뒤집혔기 때문입니다. 2023~2024년에는 모델 성능이 병목이었고 지금은 연결이 병목입니다. 그래서 같은 예산을 써도 성과 차이가 벌어집니다.
세일즈포스 뮬소프트가 2026년 발표한 커넥티비티 벤치마크 리포트는 9개국 IT 리더 1,050명을 조사했습니다. 여기서 기업이 쓰는 애플리케이션은 평균 957개였고 그중 서로 연결된 것은 27%에 그쳤습니다. 응답자 96%는 AI 도입 과정에서 데이터 관련 장벽을 겪었다고 답했습니다. 같은 조사에서 IT 리더 86%는 적절한 통합 없이 도입한 AI 에이전트가 가치보다 복잡도를 더 키울 것을 우려했고 94%는 에이전트를 성공시키려면 API 중심 아키텍처가 필요하다고 봤습니다. 이미 도입한 조직에서도 에이전트 절반은 다른 시스템과 이어지지 않은 사일로 상태로 돌아갑니다.
숫자 세 개를 이어 보면 그림이 분명해집니다. 앱은 957개, 연결된 것은 4분의 1, 그리고 거의 모두가 데이터 장벽을 겪었습니다. AI가 우리 회사 숫자를 못 가져오는 이유는 모델이 아니라 이 27%입니다.
기간 감각도 참고할 만합니다. 딜로이트의 생성형 AI 현황 조사에서는 비경영진 응답자 60%가 확산 장벽을 넘는 데 12개월 이상 걸릴 것으로 봤습니다. 같은 질문에 경영진은 47%였습니다. 현장과 경영진의 체감이 13%포인트 벌어져 있습니다. 이 간격이 연동 프로젝트에서 "왜 이렇게 오래 걸리나"라는 마찰로 나타납니다.
바꿔 말하면 지금 연동 설계를 문서로 남겨 두는 회사는 1년짜리 격차를 앞당겨 회수합니다. 반대로 커넥터만 꽂아 두면 6개월 뒤에 사일로 정리부터 다시 시작해야 합니다.
연동을 한 덩어리로 보면 견적도 일정도 나오지 않습니다. 읽기, 실행, 기록으로 끊으면 층마다 산출물과 승인 주체가 분명해지고 어디까지 할지도 고를 수 있습니다.
AI가 사내 데이터를 조회하는 층입니다. 매출 테이블, 고객 이력, 제품 매뉴얼, 과거 상담 기록이 대상입니다.
이 층에서 정할 것은 범위와 승계 방식 두 가지입니다. 범위는 "어느 테이블, 어느 컬럼까지"이고, 승계 방식은 "요청한 사람의 권한을 그대로 따를지, AI 전용 역할을 따로 만들지"입니다. 요청자 권한을 승계하면 김 과장이 물어볼 때와 재무팀이 물어볼 때 답이 달라집니다. 번거롭지만 이게 안전한 기본값입니다.
산출물은 읽기 대상 목록과 권한 매핑 표입니다. 문서 중심으로 시작한다면 사내 문서를 AI에 연결하는 방법에 검색 구조까지 정리해 두었습니다.
대표 실패는 편의상 전체 읽기 권한을 준 뒤 되돌리지 못하는 경우입니다. 한 번 열어 둔 범위는 이해관계자가 늘어난 다음에는 좁히기 어렵습니다.
AI가 시스템의 기능을 호출하는 층입니다. 티켓 생성, 일정 등록, 견적서 초안 작성, 재고 조회 같은 동작이 들어갑니다.
이 층의 핵심은 목록을 좁게 시작하는 것입니다. "CRM을 다룰 수 있다"가 아니라 "상담 메모를 추가할 수 있다" 수준까지 쪼갭니다. 각 기능은 세 칸으로 분류합니다. AI가 바로 해도 되는 것, 초안까지만 만들고 사람이 확정하는 것, 아예 열지 않는 것입니다. 금액이 바뀌거나 외부로 나가는 동작은 두 번째 칸에서 시작하는 게 안전합니다.
산출물은 기능 목록과 승인 규칙 표입니다. 이 표가 없으면 나중에 "AI가 왜 그걸 했느냐"는 질문에 답할 근거가 없습니다.
대표 실패는 되돌리기를 설계하지 않은 채 쓰기 권한을 여는 것입니다. 잘못 등록된 100건을 한 번에 취소할 방법이 없으면 운영팀이 손으로 지웁니다.
누가 요청했고 AI가 어떤 판단으로 어떤 데이터를 읽었고 어떤 기능을 실행했는지 남기는 층입니다. 감사 대응만을 위한 층이 아닙니다. 오류가 났을 때 원인을 찾는 유일한 단서이기도 합니다.
같은 뮬소프트 조사에서 중앙 집중 거버넌스 체계를 갖춘 조직은 54%였고 API 네 개 중 하나 이상은 거버넌스 밖에 있었습니다. 절반 가까운 조직이 "돌아가는 건 아는데 무엇을 했는지는 모르는" 상태입니다.
이 층에서 정할 것은 보존 항목과 보존 기간, 그리고 열람 권한입니다. 요청 원문에 고객 개인정보가 들어가는 업무라면 로그 자체가 개인정보 파일이 되므로 마스킹 규칙까지 함께 정합니다. 조직 차원의 규정과 맞물리는 부분은 AI 도입 거버넌스 가이드에서 정책 문서 형태로 다뤘습니다.
대표 실패는 로그를 남기되 아무도 보지 않는 경우입니다. 주 1회라도 담당자가 실행 이력을 훑는 절차가 붙어야 층이 작동합니다.
같은 3층 구조를 적용해도 시스템마다 난이도가 다릅니다. 순서를 정할 때 참고하시면 됩니다.
시스템 | 읽기 | 실행 | 기록 주의점 |
|---|---|---|---|
ERP | 어려움. 테이블 구조가 업무 용어와 다름 | 매우 제한. 마감·전표는 열지 않는 편이 안전 | 회계 감사 요건과 보존 기간을 맞춤 |
CRM | 쉬움. API가 정리돼 있음 | 메모·활동 기록까지 우선 개방 | 고객 개인정보 마스킹 필수 |
그룹웨어 | 보통. 결재선·조직도 해석이 필요 | 초안 등록까지만, 결재 상신은 사람 | 결재 이력과 AI 로그를 분리 보관 |
사내 문서함 | 쉬움. 검색 구조만 잡으면 됨 | 대체로 불필요 | 열람 권한이 문서별로 다름 |
사내 DB·데이터웨어하우스 | 보통. 뷰를 따로 만들어 노출 | 읽기 전용 유지 | 쿼리 원문까지 남김 |
읽기가 쉬운 쪽부터 시작해 실행은 가장 늦게 여는 순서가 사고를 줄입니다. 실무에서는 CRM 읽기 → 문서함 읽기 → CRM 메모 쓰기 → 그룹웨어 초안 순서가 무난합니다.
다음 중 세 개 이상 해당하면 1층 읽기 연동을 검토할 시점입니다. 다섯 개 이상이면 2층 실행까지 설계에 넣는 게 좋습니다.
같은 데이터를 찾으려고 두 개 이상의 시스템을 번갈아 엽니다.
담당자가 시스템에서 값을 복사해 문서로 옮기는 일이 주 3회 이상 반복됩니다.
AI로 만든 초안을 사람이 시스템에 다시 입력합니다.
같은 질문에 담당자마다 답이 다릅니다.
데이터 조회 요청이 특정 담당자 한 명에게 몰립니다.
업무 처리 이력을 나중에 추적해야 하는 규제나 계약 조건이 있습니다.
이미 AI 도구를 쓰고 있는데 사내 데이터가 없어 답변을 신뢰하지 못합니다.
세 개 미만이면 연동보다 업무 정의부터입니다. 이 판단이 어디에 속하는지 헷갈리면 AX 컨설팅 가이드에서 전환 단계 전체를 먼저 보시는 게 낫습니다.
층별로 끊어서 견적을 받으면 정확합니다. 한 덩어리로 물으면 답이 나오지 않습니다.
범위 | 기간 | 무엇이 남는가 |
|---|---|---|
연동 설계만 | 2~4주 | 대상 목록, 권한 표, 승인 규칙, 우선순위 |
1층 읽기 구축 | 4~8주 | 조회 가능한 AI + 권한 매핑 |
2층 실행 추가 | 6~12주 | 승인 규칙이 붙은 실행 도구 |
3층 기록 정비 | 2~4주 | 감사 로그 + 점검 절차 |
기간이 늘어나는 요인은 대체로 기술이 아닙니다. 권한 표를 승인해 줄 사람이 정해지지 않았거나 레거시 시스템에 API가 없어 우회 경로를 만들어야 하는 경우입니다. 앞의 뮬소프트 조사에서도 응답자 37%가 시스템 비호환성을 통합 장애 요인으로 지목했습니다. 착수 전에 이 두 가지를 확인하면 일정이 크게 흔들리지 않습니다.
전체 권한으로 시작합니다
편하다는 이유로 관리자 계정을 준 다음 좁히려 하면 그 시점에는 이미 여러 업무가 그 권한에 의존합니다.
되돌리기를 나중으로 미룹니다
쓰기 기능을 열 때 취소 경로를 같이 만들지 않으면 첫 사고에서 운영팀이 손으로 수습합니다.
층을 섞어 한 번에 갑니다
읽기 검증도 끝나지 않은 상태에서 실행까지 붙이면 오류 원인이 데이터인지 판단인지 구분되지 않습니다.
로그를 남기고 보지 않습니다
기록은 저장이 아니라 점검 절차까지가 한 세트입니다.
네 가지 모두 기술 문제가 아니고 순서 문제입니다. 설계 단계에서 대부분 막을 수 있습니다.
여기까지 정하고 나면 다음 질문이 자연스럽게 따라옵니다. 시스템마다 연동을 따로 만들어야 하느냐입니다. ERP에 하나, CRM에 하나, 그룹웨어에 하나씩 붙이면 시스템 수만큼 유지보수 대상이 늘어납니다.
그래서 나온 것이 공통 연결 규칙입니다. 공식 문서 기준으로 MCP(모델 컨텍스트 프로토콜)는 AI 애플리케이션을 외부 데이터와 도구, 업무 흐름에 연결하기 위한 오픈 표준입니다. 앞에서 정리한 읽기와 실행을 시스템별 맞춤 코드 대신 표준 규격으로 노출하자는 접근입니다. 다음 글에서는 MCP가 왜 등장했는지, 기존 API 연동과 무엇이 다른지 이어서 다룹니다.
연동에서 예산이 새는 지점은 기술 선택이 아닙니다. 범위입니다. 앞의 조사에서 IT 리더 86%가 통합 없는 에이전트를 걱정한 이유도 같습니다. 어디까지 열지 정하지 않고 붙이면 복잡도만 남습니다.
NextGenAI는 30분 무료 진단에서 읽기·실행·기록 세 층 중 어디까지 필요한지, 어느 시스템부터 시작할지를 문서로 정리해 드립니다. 진단 결과만 받고 내부에서 진행하셔도 됩니다.
층을 어디까지 올리느냐로 갈립니다. 연동 설계 문서만 받는 범위가 가장 작고 읽기 층 구축이 그다음입니다. 실행 층까지 붙이면 승인 규칙과 롤백 경로를 함께 만들어야 해서 규모가 커집니다. 견적을 물으실 때는 "AI 연동 얼마인가요"가 아니라 "읽기 층만 먼저 견적해 주세요"처럼 층을 지정하시는 편이 정확한 답을 받습니다. 대상 시스템 개수와 레거시 여부가 변수입니다.
RELATED · 함께 읽으면 좋은 글
