Part 4. Agent ERP — AI에게 도구를 빌려준 ERP
Part 3에서 에이전트가 도구로 행동하고 MCP로 도구를 빌리며 조직처럼 묶인다는 것을 봤다. 이 부는 그것을 ERP와 실제로 결합한다. 이 부가 끝나면 ‘AI 에이전트 ERP’가 추상이 아니라 구현 가능한 시스템으로 보인다.
12장. MCP + FastAPI 결합 아키텍처 — 실제 그림
섹션 제목: “12장. MCP + FastAPI 결합 아키텍처 — 실제 그림”핵심 질문: 에이전트와 ERP를 실제로 어떻게 한 시스템으로 잇는가? AI가 호출할 때도 사람과 똑같이 통제되는가?
결합은 세 층이다. (1) ERP Core — 기존 비즈니스 로직을 REST API로 노출. 인간은 GUI가, AI는 API가 호출한다. AI Agent도 API의 또 다른 사용자이며 별도 경로를 만들지 않는다. (2) MCP Layer — 그 API들을 AI가 발견·호출 가능한 도구로 래핑. (3) Agent Layer — LLM이 Agentic Loop를 돌며 도구를 선택·실행, 외부효과는 사람 승인(HITL)을 요청.
상태를 바꾸는(mutating) 도구는 네 가지 계약 원칙을 지킨다: (a) 멱등성 키 — 같은 요청 2번 = 1번 효과. (b) LLM 친화 DTO — 명확한 타입·예시로 AI가 오용하지 않게. (c) Saga 패턴 — 여러 단계 작업은 실패 시 보상 트랜잭션을 정의. (d) 도메인 이벤트 — 상태 변화를 발행해 다른 모듈이 구독. 권한은 API 레이어에서 한 번, DB 행 수준에서 한 번 이중 방어한다.
워크드 예시 — 발주(issuePurchaseOrder)의 한살이
섹션 제목: “워크드 예시 — 발주(issuePurchaseOrder)의 한살이”AI가 발주를 호출한다 → API가 호출자 권한 확인 → 멱등성 키 확인(중복 차단) → 금액이 일정 기준 이상이면 즉시 실행하지 않고 승인 카드 발행(Red List) → 승인되면 발주 생성 + 도메인 이벤트 발행 → 재고·회계 모듈이 그 이벤트를 구독해 예정 입고·미결 채무를 갱신 → 입고 실패 시 Saga 보상으로 발주 취소. AI가 호출하든 사람이 호출하든 이 경로는 동일하다. (“AI 전용 빠른 경로”를 따로 만드는 것은 금지다 — 권한·감사의 구멍이 된다.)
한 장 요약 — 인간은 GUI, AI는 MCP로 같은 ERP를 쓴다(별도 경로 금지). mutating 도구는 멱등성·DTO·Saga·이벤트 4원칙과 권한 이중 방어를 지킨다.
13장. 신뢰의 공학 — 환각 5계층·Red List·6대 원칙
섹션 제목: “13장. 신뢰의 공학 — 환각 5계층·Red List·6대 원칙”핵심 질문: “오픈소스가 겁난다. 환각이 무섭다. 솔직히 AI 자체가 두렵다.” — 이 두려움을 어떻게 다루는가?
이 두려움은 무지가 아니라 20년 경력자의 정확한 직감이다. 회피하지 말고 시스템 설계의 1번 입력값으로 삼는다. 환각은 LLM이 ‘다음 단어를 확률로 생성’하는 데서 오는 본질이라 없앨 수 없다 — BMS의 IR 드롭처럼 설계로 관리한다.
환각 방어 5계층 — ① 입력 검증(모호하면 다시 묻기) → ② 출처 강제(RAG, 없으면 “모릅니다”) → ③ 자기 검증 → ④ 교차 모델 검증 → ⑤ 인간 결재. 핵심 원칙은 자동차 안전설계와 같다 — 사고가 안 나게 하는 게 아니라 사고가 나도 사람이 안 죽게.
위험도에 따라 자율성을 차등한다. 가역적인 일(뉴스·회의록·내부 메모·자료 검색)은 자율 실행 OK. 비가역적인 일은 자율 금지(Red List)다.
Red List 7종: ① 고액(일정 금액 이상) 구매 ② 외부 메일 발송 ③ 견적 송부 ④ 거래처 관련 액션 ⑤ 인사 결정 ⑥ 계약 서명 ⑦ BMS 안전 결정. LLM이 호출해도 즉시 실행되지 않고 승인 카드로 라우팅된다. Red List 1페이지가 시스템의 헌법 1조다.
6대 안전 원칙: Human-in-the-Loop(외부효과는 5년차에도 사람 결재), Reversibility(되돌릴 수 없을수록 엄격), Audit Trail(추적 가능), Blast Radius(장애 격리), Kill Switch(한 명령어로 전 에이전트 정지), Gradual Trust(점진적 신뢰).
워크드 예시 — “거래처에 견적 보내줘”가 막히는 과정
섹션 제목: “워크드 예시 — “거래처에 견적 보내줘”가 막히는 과정”AI가 견적 초안을 만든다(가역, 자율 OK) → 단가 근거를 회사 SOP·과거 견적에서 RAG로 인용(절차 환각 방어) → ‘외부 발송’은 Red List에 걸림 → 자동 발송 대신 승인 카드 발행 → 사람이 단가·납기 검증 후 승인 → 그제야 발송. 환각이 나도 외부로 새지 않는다.
한 장 요약 — 환각은 없앨 수 없으니 5계층으로 검출하고, 위험도로 자율성을 차등하며, Red List와 6대 원칙으로 외부효과를 통제한다. 두려움을 1번 입력값으로 삼는다.
14장. 안전 경계가 있는 Tool Use 오케스트레이터
섹션 제목: “14장. 안전 경계가 있는 Tool Use 오케스트레이터”핵심 질문: 13장의 원칙들을 어떻게 코드로 강제해, AI가 규칙을 우회할 수 없게 만드는가?
AI 에이전트 ERP의 심장 agent.service는 단순 컨트롤러가 아니라 회사 헌법(Red List) + 비용 예산 + Kill Switch + 학습 루프를 강제하는 안전 경계 오케스트레이터다. 모든 LLM 호출은 순서가 정해진 5개 가드를 통과한다.
- Kill Switch — 단일 플래그로 전체 또는 특정 에이전트만 즉시 정지(발전소 비상정지).
- Cost Budget — 월 예산(예: 수만 원) 80% 경고, 100% 도달 시 저비용 모델로 자동 강등, 120% 도달 시 정지. 분기 모델 벤치마크 + 즉시 교체로 벤더 인질화 회피.
- Idempotency — 멱등성 키로 중복 실행 차단.
- Red List — 7종 액션을 HITL 승인 카드로 라우팅.
- Hallucination — 13장의 5계층.
모든 결정은 결정 로그에 1행씩 기록된다 — 사용자 메시지, 호출 도구, 토큰·비용, 그리고 학습 필드(AI가 제안했는지·확신도·사람이 뒤집었는지·결과 점수). 수백 개 테이블에 공통 감사 필드와 AI 학습 필드를 일괄 추가한다. 비기능 목표 — 응답 P95 5초 이내, 동일 도구 최대 10회 호출 후 차단, 모든 LLM 호출 비용·지연·결과 영구 보존.
워크드 예시 — ‘사람이 뒤집은 기록’이 만드는 자기개선
섹션 제목: “워크드 예시 — ‘사람이 뒤집은 기록’이 만드는 자기개선”AI가 어떤 발주를 ‘A 공급사 추천(확신도 0.7)‘으로 제안했는데 사람이 ‘B 공급사’로 뒤집었다. 3개월 뒤 그 발주의 결과(납기·품질)가 점수로 기록된다. 이 데이터가 쌓이면 “이 맥락에서 사람은 B를 택하고 결과가 좋았다”는 패턴이 추출되어, AI의 다음 추천이 사람의 실제 판단에 수렴한다. 사람이 뒤집은 기록 자체가 학습 자산이 된다.
한 장 요약 — agent.service는 5개 가드(정지·예산·중복·헌법·환각)로 모든 호출을 감싸고, 모든 결정을 학습 필드와 함께 로그로 남긴다. 사람이 뒤집은 기록이 곧 자기개선의 연료다.
15장. Harness Engineering과 5-에이전트 설계 파이프라인
섹션 제목: “15장. Harness Engineering과 5-에이전트 설계 파이프라인”핵심 질문: AI에게 코드를 맡기면 빠르지만, 같은 파일을 계속 고치고 테스트 없이 짜고 폭주한다. 어떻게 막는가?
AI가 코드를 쓰되, 잘못된 방향이면 자동으로 멈추도록 만든 것이 Harness Engineering이다. 절대 원칙 — 어떤 작업이든 시작 전 반드시 graphify(지식그래프)를 먼저 읽는다. 코드뿐 아니라 문서·계획·디버깅 모두 예외 없다.
| 게이트 | 차단 조건 |
|---|---|
| PLAN | 계획서 없이 코딩 금지 |
| GRAPHIFY-QUERY | 영향 파일 모른 채 수정 금지 |
| TDD | 실패 테스트 먼저(RED) 후 구현 |
| 3STRIKES | 같은 파일 3회 수정(땜질) 차단 |
| GRAPHIFY-STALE | 커밋 후 그래프 미갱신 차단 |
이 게이트는 Hook으로 자동 집행된다(코드 수정 시도 시 거부). 인간은 방향을 잡고 검증·승인하며, AI는 코드를 짜되 폭주하지 못한다.
새 모듈을 설계할 때는 한 번에 코딩하지 않고 5명의 전문가 에이전트가 순차 파이프라인으로 산출물을 넘긴다.
| 순서 | 에이전트 | 산출물 |
|---|---|---|
| 1 | Domain & Process Designer | 업무 불변식·예외 흐름 |
| 2 | Data Architect | 데이터 모델·마이그레이션 |
| 3 | System Architect | API 계약·도구 시그니처 |
| 4 | Execution Planner | 4시간 단위 작업 분해 |
| 5 | Validator | PASS / 조건부 / 반려 |
3대 원칙 — (1) 회의체가 아니라 파이프라인(순서 어기면 작동 안 함). (2) Validator는 끝이 아니라 각 단계마다 호출(앞 단계 결함을 일찍 잡아야 비용이 작다). (3) 각 에이전트는 거부권을 가진다. 파이프라인 선두에 동사 추출 5단계를 두어, 테이블·API가 동사 카탈로그에서 파생되게 한다.
한 장 요약 — Harness 게이트가 AI 코딩 폭주를 자동 차단하고, 5-에이전트 순차 파이프라인이 각 단계 거부권으로 설계 품질을 강제한다.
16장. 멀티테넌트·지식그래프·Digital Twin으로의 확장
섹션 제목: “16장. 멀티테넌트·지식그래프·Digital Twin으로의 확장”핵심 질문: 이 시스템을 자사용을 넘어 키우면 어디까지 가는가?
멀티테넌트(회사 칸막이): 한 시스템에 여러 회사가 자기 데이터만 보며 함께 쓰는 구조로 확장 가능하다. 각 회사 직원은 자기 자리에만, 운영팀만 모든 자리에 출입한다. 이를 가능케 하는 것이 출입카드(JWT)와 카드인식기(DB의 행 수준 보안, RLS)다. 이는 자사용을 넘어 상용 SaaS로 키우는 경로다. 단, 한 단계만 잘못돼도 다른 회사 데이터가 섞이는 사고가 나므로 백업→단계 검증→다음 단계 순서를 반드시 지킨다.
Enterprise Knowledge Graph: graphify는 단순 개발 도구가 아니라 코드·문서·업무의 관계를 잇는 지식그래프다. 조직 지식자산으로 확장하면 ‘견적↔BOM↔인증↔거래처’의 의존 관계를 그래프로 질의할 수 있다.
Digital Twin Organization: 충분히 성숙하면 회사의 업무 흐름·의사결정이 시스템 안에 ‘디지털 쌍둥이’로 존재한다. 신규 정책이나 생산 변경을 실제 적용 전에 시뮬레이션해 결과를 예측한다.
워크드 예시 — 셀 단종 시뮬레이션
섹션 제목: “워크드 예시 — 셀 단종 시뮬레이션”“한 LFP 셀이 단종된다”는 가정을 디지털 트윈에 넣으면, 지식그래프가 영향받는 BOM·제품·진행 중 프로젝트·재인증 필요 항목·관련 거래처를 즉시 펼치고, 대체 셀 적용 시 원가·납기·인증 리스크를 시나리오로 비교한다. 실제 발주 전에 충격을 예측한다.
한 장 요약 — 멀티테넌트(테넌트+RLS+JWT)로 여러 회사를 칸막이 운영하고, graphify를 지식그래프로 확장하며, Digital Twin으로 적용 전 시뮬레이션을 한다. 단, 데이터 격리는 단계별 검증이 생명이다.
다음 → 〈Part 5. Autonomous Enterprise〉: 이 모든 것이 모여 ‘회사 자체가 자율 운영되는 구조’가 된다.