Part 1. 문제 — 왜 ERP는 사람에 종속되는가

신진형 · 에스엘파워 · 2026.06.27

모든 해법은 문제를 정확히 보는 데서 시작한다. 이 부는 세 가지를 한다. ERP를 도입하고도 회사가 사람에 종속되는 구조적 이유를 해부하고(1장), 왜 대부분의 AI 도입이 성과를 못 내는지 — ‘자동화’를 ‘AX’로 착각하기 때문임을 — 보이고(2장), 해법의 첫 단추가 기술 도입이 아니라 질문을 바꾸는 것임을 동사-우선 설계로 제시한다(3장).

1장. ERP는 왜 실패하는가 — 지식은 사람 머릿속에 남는다

핵심 질문: ERP를 도입하고, 매뉴얼을 만들고, KPI를 관리하고, 교육까지 했는데 왜 회사는 여전히 ‘그 사람’이 없으면 멈추는가?

답은 직원이 게을러서가 아니다. 회사의 두뇌가 사람 머릿속에 흩어져 있기 때문이다. 이 구조는 세 가지 방식으로 회사를 반복해서 무너뜨린다.

① 핵심 노하우가 사람 머릿속에 있다. 견적을 어떻게 뽑는지, 까다로운 거래처를 어떻게 응대하는지, KC 인증 서류를 어떻게 꾸미는지 — 이건 ERP 어디에도 없다. ERP에는 ‘견적서 번호 Q-2026-0412, 금액 3,200만원’이라는 결과만 남는다. ‘왜 그 단가로 책정했는가’, ‘이 고객에겐 왜 분할 납품을 제안했는가’라는 판단의 근거는 그 사람 머릿속에만 있다. 그 사람이 퇴사하면 평균 3~6개월간 그 업무 품질이 무너진다(추정).

② 인수인계는 ‘설명’으로 재현되지 않는다. 인수인계 문서는 쓰는 순간 이미 낡는다. 실제 업무는 매일 진화하기 때문이다. 같은 ‘발주 처리’라도 전임자는 “공급사 리드타임을 14일로 잡고 2주 앞당겨 발주”했는데, 후임자는 그 맥락을 몰라 정시에 발주했다가 라인을 세운다. 같은 일도 사람마다 다르게 처리되고 표준이 사라진다.

③ 같은 일을 매번 처음부터 한다. 같은 견적·보고서·클레임 응대를 백지에서 다시 시작한다. 게다가 메뉴가 50개 넘는 ERP는 현장 직원이 30%만 쓴다. 화면이 어렵고 복잡하기 때문이다. 결국 회사가 비싸게 만든 자산의 70%가 잠잔다.

왜 ERP는 이걸 못 고치는가

기존 ERP는 데이터는 저장하지만 판단과 맥락은 저장하지 못한다. 이것이 단 하나의 근본 원인이다. ERP는 “기억하는 창고”다. 입력하면 보관하고, 시키면 계산한다. 10년을 써도 첫날과 똑같이 일한다. 더 똑똑해지지 않는다. 노하우는 안 쌓인다 — 사람이 떠나면 같이 떠난다.

워크드 예시 — 김 과장의 퇴사

영업 김 과장이 퇴사한다고 하자. 그가 ERP에 남긴 것: 거래처 마스터, 견적 이력 320건, 수주 데이터. 그가 ERP에 못 남긴 것: “A사는 분할 입고를 선호하니 단가를 5% 양보해도 물량으로 회수된다”, “B사 구매팀장은 기술 스펙 변경에 민감하니 견적 전 반드시 R&D 검토를 붙인다”, “C사는 연말에만 대량 발주하니 11월에 재고를 미리 잡아둔다”. 이 세 줄이 김 과장의 진짜 자산이다. 후임은 이 세 줄을 6개월에 걸쳐 시행착오로 다시 배운다. ERP는 320건의 결과를 저장했지만, 그 결과를 만든 세 줄의 판단 기준은 저장하지 못했다.

리더가 놓치는 리스크 — SPOF

회사의 핵심 판단이 한 사람(특히 대표나 핵심 인력)에게만 집중되어 있다면, 그 사람이 곧 **단일 장애점(SPOF, Single Point of Failure)**이다. 회사가 한 사람의 머리에 인질로 잡혀 있는 상태다. 진짜 AX는 그 판단을 시스템에 이전 가능한 형태로 풀어내는 일이다. 이 문장이 이 책 전체의 과녁이다.

한 장 요약 — ERP는 데이터는 저장하지만 판단과 맥락은 저장하지 못한다. 그래서 노하우가 사람 머릿속에 남고, 사람이 바뀌면 회사가 리셋된다. 문제는 교육 부족이 아니라 ‘두뇌가 분산된 구조’ 그 자체이며, 그것이 SPOF 리스크를 만든다.

2장. AX의 세 가지 착각과 진짜 병목

핵심 질문: 돈은 썼는데 성과가 없다. GPU를 사고, 솔루션을 도입하고, 교육까지 했는데 왜 손익이 안 움직이는가?

먼저 냉정한 숫자. MIT의 「State of AI in Business 2025」는 기업 생성형 AI 도입의 95%가 손익(P&L)에 측정 가능한 효과를 내지 못한다고 보고한다. 원인은 모델 성능이 아니라 업무와의 통합·학습 격차다. Gartner는 에이전트 AI 프로젝트의 40% 이상이 2027년까지 취소될 것으로 본다.

이유는 하나로 모인다. 대부분의 기업이 ‘자동화’를 만들어 놓고 그것을 ‘AX(AI 전환)‘라고 부른다.

착각	흔한 말	진실
1	”챗봇 좀 써봤으니 AX를 안다”	도구 사용 경험은 출발선일 뿐. 회사라는 유기체를 바꾸는 일과는 다른 차원
2	”문서를 척척 요약하니 AI를 잘 쓴다”	그것은 입력 1번→출력 1번의 단발성 추론. 개인이 편해질 뿐 업무 흐름은 안 바뀜
3	”에이전트 100개 돌리면 AX 성공“	‘에이전트 워싱’. 기존 도구에 이름표만 붙인 것

착각 2가 특히 중요하다. 대량 문서 요약·엑셀 분석·PPT 자동 생성은 놀랍지만 모두 ‘단발성 추론 호출’이다. 개인 생산성은 오르지만 회사의 업무 흐름은 그대로다.

진짜 병목은 기술이 아니다

병목은 둘이다. ① 과거의 마인드를 가진 사람 — “코딩은 사람이 해야 한다”는 직업의식, AI를 가장 신뢰하지 못하는 태도. ② 흩어진 지식과 주인 없는 데이터(진짜 원인) — 업무 노하우가 사람 머릿속에만 있고, 그 데이터를 누가 책임지는지 정해지지 않은 상태. 평가할 데이터가 없으면 AX는 불가능하다.

워크드 예시 — 두 회사의 같은 ‘AI 도입’

X사: 전 직원에게 AI 계정을 주고 “각자 알아서 생산성 올리세요”라고 한다. 6개월 후 개인들은 메일 초안을 빨리 쓰지만 회사 KPI는 그대로다(→ 자동화). Y사: “신규 입사에서 일어나는 결정 연쇄”를 데이터로 정의하고, 그 흐름을 AI가 처리하고 사람이 승인하게 한다. 6개월 후 온보딩 시간이 줄고 그 절차가 회사 자산으로 남는다(→ 인지). 같은 ‘AI 도입’이지만 X사는 95%에, Y사는 5%에 속한다.

한 장 요약 — AX 실패의 본질은 자동화를 AX로 착각하는 것이다. 진짜 병목은 모델이 아니라 과거의 마인드와 ‘흩어진 지식·주인 없는 데이터’다.

3장. 동사-우선 설계 — 질문을 바꾼다

핵심 질문: ERP를 만들 때 우리는 늘 “○○관리 화면을 만들어줘”라고 물었다. 에이전트 시대에는 무엇을 먼저 물어야 하는가?

전통 ERP는 “사람이 화면에 입력 → 시스템이 저장”이라 설계 시작점이 Form/Table(명사)이었다. 에이전트 시스템은 “이벤트 발생 → 에이전트가 Tool 호출 → 정책 분기 → 필요 시 인간 승인”이라 시작점이 Event와 Tool(동사)이다. 그래서 첫 질문이 바뀐다. 명사부터 묻지 말고 동사(confirmOrder, flagQualityHold)부터 묻는다. 그 동사 목록이 곧 에이전트가 호출할 수 있는 업무 단위가 된다. 화면 설계는 맨 마지막이다.

‘화면’부터 만들면 결국 평범한 ERP가 된다 — 사람이 일일이 눌러야 하니까. ‘동사’부터 만들면 AI가 그 일을 대신할 수 있다.

모든 모듈 공통 5단 프롬프트

AI에게 한 모듈에 대해 다음 5단을 순서대로 던진다. 화면 얘기는 5단 이후다.

이 모듈에서 1년간 실제 일어나는 사건을 시간 순서로 20개 이내 열거하라.
각 사건마다 — 누가(Actor) / 무엇을 보고(Context) / 어떤 판단(Decision) / 결과(Output) / 다음 트리거(Next).
각 결정을 분류하라 — 자동화 가능 / 정책 분기 / 인간 승인 필수.
결정에 필요한 외부 시스템을 식별하라 — 메일·회계·근태·결제·세금계산서 등.
동사를 의미론적 메서드명(confirmOrder, issueITAccount)으로 정리하고 입출력 타입을 명세하라.

워크드 예시 — 구매(Purchase) 모듈

5단 프롬프트를 구매 모듈에 돌리면 다음 동사 카탈로그가 나온다.

requestQuotation(itemId, qty, dueDate) -> QuotationReq
evaluateSupplier(quotationReqId) -> SupplierRanking   # 정책 분기(최저가+납기 가중치)
issuePurchaseOrder(supplierId, lines[], dueDate) -> PO  # 고액(일정 금액 이상)이면 인간 승인
receiveGoods(poId, receivedLines[]) -> GoodsReceipt    # 부분/초과 허용
matchThreeWay(poId, grId, invoiceId) -> MatchResult    # 자동, 불일치만 사람
approveInvoice(invoiceId) -> ApprovalResult            # 인간 승인

이 6개 동사가 곧 구매 모듈의 도구(Tool) 카탈로그다. 여기서 비로소 테이블과 화면이 파생된다. 모듈 전체로 보면 서로 다른 화면 수십 세트가 아니라, 동사 약 200개가 같은 패턴(동사+입력+결정+출력+다음 동사)으로 묶인 하나의 그래프가 된다. 에이전트는 그 그래프를 따라 움직인다.

한 장 요약 — 질문을 “화면을 만들어줘”에서 “의사결정을 동사로 뽑아줘”로 바꾼다. 동사 카탈로그가 곧 도구 카탈로그가 되고, 테이블·API·화면이 그로부터 파생된다.

다음 → 〈Part 2. AI의 본질〉: 그 동사를 실행할 ‘AI’란 정확히 무엇이고, 왜 이번에는 다른가.