AI 에이전트가 ERP·CRM을 대신 쓰면, 시스템에서 점검할 4가지

📰 2026년 10월 19일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.

짧게 먼저 정리할게요. 10월 6일 CIO닷컴에 실린 기고는 AI 에이전트가 앞에 서도 ERP·CRM 같은 기록 시스템은 오히려 더 중요해진다고 봤어요. 사람이 화면에서 하던 조회와 입력을 에이전트가 맡으면, 그동안 사람이 화면을 거치며 지켜 오던 것들을 이제 시스템이 직접 지켜야 하거든요. AI 에이전트 도입 전에 지금 시스템에서 볼 곳은 네 군데예요. 에이전트가 어떤 통로로 들어오는지, 화면에만 있던 규칙이 서버에도 있는지, 같은 요청이 두 번 오면 어떻게 되는지, 되돌리고 되짚을 길이 있는지. 직접 만들고 운영해 본 개발사 기준으로 정리했어요.

“에이전트는 화면 위에서 사람처럼 일하는 거 아닌가요? 시스템은 그대로 둬도 되죠?”

AI 에이전트 이야기를 하다 보면 자주 듣는 말이에요. 반은 맞아요. 화면을 대신 눌러 주는 방식도 있으니까요. 그런데 에이전트가 하루에 몇백 건씩 값을 바꾸기 시작하면 사정이 달라져요. 사람이 일할 땐 화면이 막아 주던 실수를 이제는 시스템이 막아야 해요.

업무를 어떤 순서로 다시 그릴지는 같은 기고를 바탕으로 AI 에이전트 도입 전, 업무부터 다시 그리는 6단계에 정리해 뒀어요. 이 글은 그다음 이야기예요. 업무 말고 시스템 쪽이에요.

---

1. 이번 기고에서 무엇을 다시 봐야 하나요

“기록 시스템은 사라지지 않고 더 무거워진다”는 대목이에요. 기고자 라지 사르메이(Rajjie Sarmey)는 은행·통신 업계에서 CIO와 CTO를 지낸 사람이에요. 그는 직원이 “이 청구 분쟁 처리해 줘”처럼 결과만 말하고, 여러 화면을 오가는 일은 에이전트가 맡는 쪽으로 일이 바뀐다고 봤어요. 그러면서 ERP·CRM이 사용자 눈에 덜 보일수록 데이터 정합성과 API, 거래 통제가 더 중요해진다고 짚었어요.

먼 이야기만은 아니에요. 최근 1년 사이 나온 자료를 모으면 이래요.

공식 외부 기준 — 이 글이 기대는 자료

날짜	출처	내용
2025년 8월 26일	가트너 보도자료	2026년 말까지 기업용 애플리케이션의 40%에 업무별 AI 에이전트가 들어간다고 전망했어요(2025년엔 5% 미만)
2026년 7월 21일	파노라마 컨설팅(ERP 컨설팅사)	에이전트에 ERP 쓰기 권한을 주기 전에 정할 질문으로 실행 범위, 되돌리는 경로, 근거 기록, 에이전트끼리 부딪칠 때의 최종 권한을 꼽았어요
2026년 10월 6일	CIO닷컴 기고	에이전트가 앞에 서도 기록 시스템은 정본으로 남고 데이터 정합성·API·거래 통제가 더 중요해진다고 봤어요

(가트너 수치는 전망치예요. CIO닷컴 글은 개인 의견을 담은 기고고요.)

기고는 업무를 먼저 다시 그리라고 말해요. 그 말이 맞다면, 다시 그린 업무를 받아 줄 시스템도 함께 봐야 해요. 아래 네 가지가 그 점검이에요.

2. 에이전트는 화면으로 들어오나요, API로 들어오나요

가능하면 API로 들어오게 하는 쪽이 운영하기 편해요. 에이전트가 시스템을 만지는 길은 크게 둘이에요. 사람이 쓰는 화면을 대신 클릭하고 입력하는 방식, 그리고 프로그램끼리 쓰는 창구로 바로 요청하는 방식이에요.

자사 실무 기준 예시 — 에이전트가 시스템을 만지는 두 길

방식	좋은 점	운영하면서 생기는 일
화면 대신 조작	기존 시스템을 거의 안 고치고 시작해요	화면 문구나 배치가 바뀌면 멈춰요. 기록엔 “사람이 입력”으로 남기 쉬워요
API 요청	동작마다 들어가는 값과 결과가 정해져 있어요	API가 없거나 조회만 열려 있으면 먼저 만들어야 해요

(자사 실무 기준 예시예요. 시스템 구조에 따라 두 방식을 섞어 쓰기도 해요.)

그래서 첫 질문은 단순해요. 우리 ERP·CRM에 쓰기 API가 있나요? 오래된 사내 시스템은 조회 창구만 있거나, 화면이 데이터베이스에 바로 붙어 있어 창구 자체가 없는 경우가 꽤 있어요. 이럴 땐 에이전트보다 연동 작업이 먼저예요. 연동이 견적을 얼마나 바꾸는지는 기존 시스템 연동이 있으면 왜 더 어려워질까요에 정리해 뒀어요.

용어 정리 — API는 프로그램끼리 데이터를 주고받는 정해진 창구예요. 값을 읽기만 하는 조회 창구와 값을 바꾸는 쓰기 창구는 따로 열려요. 실무에선 “조회 API는 있는데 쓰기 API는 없어요”처럼 말해요.

3. 화면에서만 막던 규칙은 API에서도 막히나요

여기가 가장 자주 비어 있는 자리예요. 사람이 쓰던 시스템은 규칙을 화면에서 지키는 경우가 많아요. 할인율이 20%를 넘으면 입력칸이 빨개지고, 필수값을 빼면 저장 버튼이 안 눌리는 식이죠. 사람은 늘 그 화면을 거치니 문제가 없었어요.

에이전트가 API로 들어오면 화면을 거치지 않아요. 서버에 같은 규칙이 없으면 사람이라면 못 넣었을 값이 그대로 들어가요. 누가 일부러 뚫은 게 아니라 처음부터 그렇게 만들어져 있던 거예요.

자사 실무 기준 예시 — 화면 규칙이 서버에도 있는지 보는 표

규칙 종류	사람이 화면에서 쓸 때	에이전트가 API로 쓸 때 확인할 것
금액·비율 상한	입력칸이 막아 줘요	서버도 같은 상한으로 거절하나요
필수값	저장 버튼이 안 눌려요	빠진 채로 저장되진 않나요
승인 단계	결재 버튼이 따로 있어요	승인 없이 바로 확정되는 API가 있진 않나요
처리 순서	출고 전엔 반품 버튼이 안 보여요	순서를 건너뛴 요청도 받아 주나요

(자사 실무 기준 예시예요. 특정 고객사 사례가 아니에요.)

점검은 어렵지 않아요. 화면에서 막히는 규칙을 목록으로 뽑고, 같은 값을 개발 서버의 API로 보내 봐요. 몇 건만 보내 봐도 어디가 비었는지 금방 드러나요.

4. 같은 요청이 두 번 들어가면 어떻게 되나요

한 번만 처리되도록 시스템이 막아 줘야 해요. 에이전트는 응답이 늦거나 연결이 끊기면 같은 요청을 다시 보내도록 만드는 경우가 많아요. 다시 보내는 것 자체는 정상 동작이에요. 문제는 첫 요청이 사실은 처리됐는데 응답만 늦었을 때예요. 그러면 환불이 두 번, 주문이 두 번 들어가요.

사람은 화면을 보고 “이미 처리된 건이네” 하고 멈춰요. 에이전트가 실행하는 자리엔 그걸 볼 사람이 없어요. 그래서 요청마다 고유 번호를 받아 같은 번호는 한 번만 처리하게 해 둬야 해요.

용어 정리 — 멱등성은 같은 요청을 여러 번 보내도 한 번 보낸 것과 결과가 같은 성질이에요. 보통 요청마다 고유 번호(멱등 키)를 붙여 만들어요. 실무에선 “이 환불 API는 멱등 처리돼 있나요?”처럼 물어요.

결제 대행사 API처럼 처음부터 이 장치를 갖춘 곳도 있어요. 하지만 회사 안에서 만든 ERP·CRM의 쓰기 기능엔 이게 없는 경우가 있어요. 그동안은 사람이 버튼을 두 번 누를 일이 드물어서 티가 안 났을 뿐이에요.

5. 에이전트가 한 일을 되돌리고 되짚을 수 있나요

되돌리는 길과 근거 기록이 시스템 안에 있어야 해요. ERP 컨설팅사 파노라마 컨설팅은 7월 21일 글에서 자율적으로 한 모든 행동에는 되돌리는 경로가 문서로 있어야 한다고 썼어요. 기록은 결론만 남는지, 그 판단에 쓴 데이터까지 남는지 물어보라고 했고요.

개발 쪽 말로 옮기면 이래요.

• 되돌리기 — 잘못 들어간 값을 지우는 대신 취소·정정 거래로 바로잡을 수 있나요? 회계처럼 지우면 안 되는 데이터일수록 이 길이 먼저 있어야 해요.
• 멈추기 — 에이전트를 멈췄을 때 이미 다른 시스템으로 넘어간 처리도 같이 멈추나요?
• 되짚기 — 기록에 “어떤 에이전트가, 누구 요청으로, 어떤 데이터를 보고, 무엇을 바꿨는지”가 함께 남나요?

같은 글에서 새겨 둘 문장이 하나 더 있어요. 설정 화면에만 있는 통제는 다음 업데이트 때 사라질 수 있다는 거예요. 그래서 기록 요구는 화면 설정에 맡기지 말고 계약서에 적어 두라고 권해요. 에이전트에 권한을 어디까지 줄지는 AI 에이전트에 직원 권한을 주기 전에 확인할 5가지에서 따로 다뤘어요.

6. 외주로 맡긴다면 견적서와 PoC에 무엇을 적을까요

기존 시스템 보강을 별도 항목으로 적어 두세요. 사내 AI 에이전트를 외주로 만들 때 견적서에 에이전트 화면과 모델 연동만 있고, 정작 ERP·CRM 쪽 작업은 빠져 있는 경우가 있어요. 그러면 개발 도중에 “서버 검증이 없어서 추가 작업이 필요해요”라는 말을 듣게 돼요.

자사 실무 기준 예시 — 견적서에 옮겨 적을 문장

점검 항목	견적서·계약서 문장 예시
통로	에이전트가 쓰는 쓰기 동작 목록을 내고, 동작마다 API인지 화면 조작인지 표시한다
규칙	해당 동작의 화면 검증 규칙을 서버에도 적용하고, 적용 여부를 시험 결과로 낸다
중복	쓰기 동작은 요청 번호 기준으로 한 번만 처리되게 한다
되돌리기·기록	동작마다 취소·정정 경로와 기록 항목(요청자·근거 데이터·결과)을 산출물로 낸다

(자사 실무 기준 예시 문구예요. 실제 계약서는 법무 검토를 거쳐 정하세요.)

AI 플랫폼 도입 전 PoC에서 뭘 확인할지도 여기서 정해져요. 정확도만 재고 끝내지 말고 쓰기 동작 하나를 골라 일부러 세 번 흔들어 보세요. 규칙을 어긴 값을 보내 보고, 같은 요청을 두 번 보내 보고, 처리된 건을 되돌려 보는 거예요. PoC 예산을 어떻게 잡는지는 AI PoC 비용 가이드에 있어요.

흔한 실수 조회로 시작한 PoC가 잘 되자 곧바로 쓰기까지 여는 거예요. 조회는 틀려도 화면에 엉뚱한 답이 뜰 뿐이지만, 쓰기는 틀리면 데이터가 바뀌어요. 조회 PoC의 정확도는 쓰기가 안전하다는 근거가 못 돼요. 쓰기는 따로 시험하세요.

7. 운영까지 해 본 개발사는 어떻게 보나요

에이전트 도입이 기존 시스템을 다시 들여다보게 만드는 계기라고 봐요. 기고자가 말한 역설도 같은 이야기예요. 사용자 눈엔 애플리케이션이 덜 보이는데 운영에선 더 중요해진다는 거죠.

저희도 자체 SaaS 4종을 운영하면서 외부 연동을 붙일 때마다 같은 자리부터 봐요. 관리자 화면에서만 지켜지던 규칙이 서버에도 있는지, 같은 요청이 두 번 와도 괜찮은지요. 납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각하는 이유예요. 위 네 가지는 에이전트가 아니어도 외부 연동이 늘어나는 시스템이라면 언젠가 손봐야 할 자리이기도 해요. 도입 효과를 무엇으로 잴지는 AI로 8시간이 10분 됐다는데, 비용 절감은 얼마일까요?를 참고하세요.

AI 에이전트를 붙이고 싶은데 지금 시스템이 받아 줄 수 있을지 감이 안 온다면, 아직 범위가 정해지지 않았어도 괜찮아요. 쓰기 동작 몇 개만 골라 어디를 보강해야 하는지부터 같이 짚어 볼 수 있어요. 저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해 온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 우리 시스템이 에이전트를 받을 준비가 됐는지 같이 봐요 →

8. 자주 묻는 질문 (FAQ)

AI 플랫폼 도입 전에 PoC에서 뭘 확인해야 하나요?

정확도와 함께 쓰기 동작 하나를 골라 세 가지를 일부러 해 보세요. 규칙을 어긴 값을 보냈을 때 막히는지, 같은 요청을 두 번 보냈을 때 한 번만 처리되는지, 처리된 건을 되돌릴 수 있는지요. 조회만 시험한 PoC로는 쓰기가 안전한지 알 수 없어요.

우리 시스템에 API가 없으면 AI 에이전트 도입은 어렵나요?

화면을 대신 조작하는 방식으로 시작할 수는 있어요. 다만 화면이 바뀌면 멈추고 기록도 흐려져요. 조회부터 시작하고, 자주 쓰는 쓰기 동작 몇 개만 API로 여는 순서가 현실적이에요.

사내 AI 에이전트를 외주로 만들면 기존 ERP도 손대야 하나요?

대개 조금은 손대요. 에이전트가 쓸 쓰기 동작에 서버 쪽 검증과 중복 방지, 정정 경로가 있는지 먼저 보고, 없으면 그 보강이 견적에 따로 들어가야 해요. 견적서에 기존 시스템 보강 항목이 있는지 확인하세요.