ERP를 AI에 붙이기 전에 정해야 하는 여섯 가지

클로드 코드 창에 품목 하나를 적고 "지금 몇 개 있어?"라고 친다. 잠시 뒤 창고별 수량이 줄줄이 뜬다. ERP에 로그인한 사람은 아무도 없다.

돌아온 표에는 칸이 일곱 개뿐이다. 품목코드, 품목명, 규격, 수량, 단위, 창고코드, 창고명. 단가와 거래처는 없다.

그 두 칸은 내가 뺐다.

연결은 쉬운 쪽이었다

ERP를 AI에 붙이는 일 자체는 솔직히 어렵지 않다. 이카운트를 포함해 대부분의 ERP가 공식 API를 열어 뒀다. 인증 절차와 호출 규칙도 벤더 문서에 다 있다. 둘 사이에 MCP 서버를 하나 두면 끝이다.

MCP(Model Context Protocol)는 AI가 외부 시스템을 "도구"로 부르게 해 주는 표준이다. ERP API를 도구로 감싸 두면 클로드는 ERP 주소 규칙이나 세션을 몰라도 된다. get_inventory 같은 도구 이름만 부른다.

문서를 펴고 첫 응답을 받기까지 반나절 걸렸다. 근데 60명이 쓰는 물건으로 만드는 데는 두 달이 들었다. 그 두 달을 잡아먹은 건 코드보다 결정이었다.

아래 여섯 개는 겪고 나서야 "이걸 먼저 정했어야 했다"는 걸 안 것들이다.

하나. AI에게 무엇을 보여줄 것인가

ERP에는 회사 정보가 거의 다 들어 있다. 매입 단가, 판매 금액, 거래처 연락처, 마진. 재고 하나 묻는데 단가를 같이 넘길 이유는 없다.

근데 API는 그렇게 골라 주지 않는다. 재고 조회 API를 부르면 그 품목에 딸린 값이 통째로 온다. 필요한 칸만 달라고 할 방법이 없다. 거르는 일은 전부 중간에 둔 MCP 서버가 맡는다.

그래서 제일 많이 불리는 재고 도구는 두 번 거른다.

1. 먼저 가린다. 이름에 단가·금액·부가세·원가가 붙은 값, 거래처 코드·거래처명·전화·이메일·주소는 별표로 바꾼다.
2. 그다음 남긴다. 통과 목록에 있는 일곱 칸만 내보내고 나머지는 버린다.

중요한 건 두 번째다. 가리기만 하면 ERP에 새 칸이 생겼을 때 그 칸은 걸러지지 않고 그대로 나간다. 내보낼 칸만 적어 두면 새 칸은 목록에 없으니 그냥 버려진다. 새 정보가 필요할 때마다 목록을 고쳐야 하지만, 그 정도 번거로움은 감수할 만하다.

가린 값을 두고 AI가 "모른다"고 답하게 할지, "볼 수 없다"고 답하게 할지도 정해야 했다. 별표만 넘기면 AI는 칸이 있다는 건 알고 값만 모른다. 아예 버리면 칸이 있었다는 사실도 모른다. 나는 버리는 쪽을 골랐다. 칸이 있다는 걸 알면 다음 질문이 "그럼 단가는 어디서 봐?"로 넘어간다. 거기 답하다 보면 결국 단가를 보는 경로가 하나 더 생긴다.

둘. 물을 때마다 ERP에 갈 것인가

ERP API에는 대개 조회 제한이 있다. 한 번에 볼 수 있는 기간이 정해져 있고 호출 사이엔 간격을 둬야 한다. 품목 수백 개를 하나씩 물으면 답이 오기까지 몇 분이 걸린다. 그 몇 분을 기다려 주는 사람은 없다.

길은 두 가지다.

방식	좋은 것	나쁜 것
물을 때마다 ERP에 간다	항상 지금 숫자다	느리다. 호출 제한에 걸린다. ERP가 멈추면 같이 멈춘다
쌓아 두고 거기서 읽는다	바로 답한다. ERP에 부담이 없다	마지막으로 가져온 시점의 숫자다

나는 쌓아 두는 쪽을 기본으로 했다. 급할 때만 쓰는 실시간 조회 도구는 따로 뒀다. 데이터는 로컬 DB(SQLite)에 동기화해 두고 조회 도구가 거기서 읽는다.

대신 조건이 하나 있다. 답에 "언제 기준 숫자인지"를 같이 붙여야 한다. 안 붙이면 사람은 늘 지금 숫자라고 믿는다. 30분 전 재고인 줄 모르고 출고를 잡으면 그건 시스템이 낸 사고다.

셋. 도구를 무엇 단위로 나눌 것인가

API 하나에 도구 하나를 맞추는 게 제일 쉽다. 근데 그렇게 만든 도구가 제일 안 쓰인다.

API는 시스템 사정대로 나뉘어 있고 사람의 질문은 그렇게 안 나뉜다. "이거 만들려면 뭐가 몇 개 들어가"라는 질문 하나에 API 셋이 필요하다. 도구를 API에 맞추면 그 셋을 AI가 알아서 조합해야 한다. 조합이 틀려도 사람은 왜 틀렸는지 모른다.

그래서 현장에서 실제로 나오는 질문 단위로 나눴다. "재고 몇 개야", "창고별로 보여줘", "이거 만들려면 뭐 들어가"가 각각 도구 하나다. 지금 도구는 37개다. 감싼 API 수보다 적은데, 여러 API를 하나로 묶은 도구가 있어서 그렇다.

동기화 도구는 조회 도구에서 떼어 냈다. ERP에서 데이터를 가져오는 일은 느리고 제한도 걸린다. 그걸 조회 도구에 넣으면 질문 하나 던지고 몇 분을 기다려야 한다.

넷. 쓰기를 열 것인가

조회를 여는 것과 저장까지 여는 것은 무게가 전혀 다르다. 조회가 틀리면 화면이 틀리고 저장이 틀리면 장부가 틀린다.

열고 나서 안 게 있다. API가 열려 있어도 ERP 안에서 막힌다. 저장 API 열 개를 붙여 봤는데 통과한 건 넷뿐이었다. 나머지는 API가 아니라 ERP 안의 권한 설정과 기준정보에서 걸렸다. 계정에 입력 권한이 없거나 창고 유형이 안 맞는 식이었다.

그래서 쓰기를 설계할 때 볼 건 API 문서보다 그 계정으로 사람이 ERP에 들어가 같은 작업을 할 수 있는지다. 사람이 못 하는 건 API로도 못 한다. 거꾸로 사람이 할 수 있는 건 AI도 할 수 있다. 권한을 넉넉히 준 계정을 AI에 물리면 그만큼 위험해진다.

나는 조회를 기본으로 두고 쓰기는 사람이 한 번 확인해야 넘어가게 했다. 승인 창을 어디에 둘지는 키움 MCP를 분해한 글에서 다른 사례로 다시 다뤘다.

함께 읽기키움증권 MCP, 클로드에 붙이면 주문까지 되나요NEWS · 2026.09.11→

다섯. 누가 무엇을 불렀는지 남길 것인가

이건 안 정하면 자동으로 "안 남긴다"로 굳는다. 그러면 나중에 무슨 일이 있었는지 확인할 방법이 없다.

로그인 성공과 실패, 세션 만료와 재시도, 도구 오류를 전부 기록했다. 이 기록 덕을 크게 본 적이 한 번 있다.

팀즈에 붙은 재고 조회 봇은 당연히 우리 MCP 서버를 거친다고 믿었다. 구조도에도 그렇게 그려 뒀다. 근데 기록을 보니 그 경로로 들어온 호출이 0건이었다. 확인해 보니 팀즈 쪽 자동화 흐름 다섯 개가 전부 ERP API를 바로 부르고 있었다. 중간에 둔 가림막을 통째로 건너뛴 거다.

기록이 없었으면 틀린 구조도를 계속 믿었을 거다. 실제로 어떻게 연결돼 있는지는 구조도 말고 로그를 봐야 안다.

여섯. 멈췄을 때 어떻게 알 것인가

제일 오래 붙잡고 있던 게 이거다. 코드는 멀쩡했고 원인은 설정 한 칸이었다.

대부분의 ERP는 미리 등록한 IP 주소에서 온 API 로그인만 받아 준다. 등록 안 된 주소에서 부르면 막힌다. 여기에 함정이 둘 있다.

하나. 거부가 에러로 오지 않는다. HTTP 응답은 정상이고 거부 사유는 본문 안에 코드로 박혀 온다. 응답 코드만 보고 성공으로 처리하면 다음 호출이 "로그인하세요"로 실패한다. 에러는 재고 조회에서 보이는데 원인은 그 앞 로그인에 있다.

또 하나. 클라우드에서 부르면 나가는 주소가 고정이 아니다.

한 달 사이 네 번 터졌다. 세 번은 아예 멈춰서 바로 알았는데 네 번째는 성공과 실패가 번갈아 나와서 한참 헤맸다. 원인은 클라우드 자동화 도구가 요청을 내보내는 주소였다. 같은 대역 안에서 요청마다 바뀌었고, 한 번 실행하는 동안에도 로그인과 조회가 다른 주소로 나갔다.

여기서 규칙 두 개를 얻었다.

• 허용목록은 지우지 않고 추가만 한다. 내 기록에 "칸이 다섯 개까지"라고 적혀 있었다. 그걸 믿고 안 쓰는 줄 알았던 항목을 지웠다가 다른 시스템을 멈춰 세운 적이 있다. 실제 상한은 스무 개였다. 같은 일을 두 번 겪고서야 등록 화면 안내문을 직접 읽었다. 기록보다 화면을 먼저 본다.
• 간헐적 실패는 확률 문제로 본다. 성공과 실패가 번갈아 나오면 코드를 뒤지기 전에 요청마다 달라지는 값을 찾는다.

근본 해결책은 클라우드가 ERP를 직접 부르지 않고 고정 서버 한 곳을 거치게 하는 거다. 그러면 허용목록에는 주소 하나만 올리면 된다.

정리

여섯 개 모두 안 정하고 넘어가면 기본값이 대신 정해 버린다.

정할 것	안 정하면 생기는 일
AI에게 보여줄 칸	API가 주는 대로 다 나간다. 단가와 거래처도 같이
실시간이냐 쌓아 두느냐	실시간 조회가 된다. 느려서 아무도 안 쓴다
도구를 나누는 단위	API 하나가 도구 하나가 된다. AI가 조합을 틀려도 원인을 찾을 수 없다
쓰기 허용 범위	계정 권한 전체가 열린다. 사람이 할 수 있는 건 AI도 다 한다
기록 남길 범위	아무것도 안 남는다. 구조도가 맞는지 나중에 확인할 길이 없다
실패 감지 방법	대개 현장 사람이 먼저 알아챈다

이 여섯 개는 벤더 문서 어디에도 없다. 근데 시스템이 오래 버티느냐는 여기서 갈린다.

무엇을 만들었고 60명이 어떻게 쓰는지는 ONE STOCK 글에 따로 적었다.

함께 읽기이카운트 ERP 위에 AI를 얹었다AI SYSTEMS · 2026.03.07→

자주 받는 질문