AI 에이전트가 ERP에 직접 접근해서는 안 되는 이유: 대신 실행 계층(Execution Layer)을 구축하세요

tags: ai, n8n, fastapi, architecture

지금 모두가 AI 에이전트를 만들고 있습니다.

그것은 더 이상 어려운 일이 아닙니다.

LLM을 호출하는 Python 스크립트를 작성하는 것은 간단합니다. API를 연결하고, 프롬프트(prompt)를 보내고, 응답을 받으면 그것을 에이전트라고 부를 수 있습니다.

진짜 문제는 그 에이전트가 비즈니스 시스템 내부에서 유용한 무언가를 수행하고 싶어 할 때 시작됩니다.

재고 업데이트.

공급업체 결제 생성.

CRM 레코드 변경.

트랜잭션(transaction) 게시.

고객 알림 트리거.

ERP 데이터베이스 접근.

이 지점이 많은 AI 에이전트 데모가 위험해지는 구간입니다.

왜냐하면 가공되지 않은 LLM은 확률적(probabilistic)이기 때문입니다.

기업의 실행(execution)에는 통제가 필요합니다.

문제점

대부분의 AI 에이전트 예시는 데모 상으로는 깔끔해 보입니다.

사용자가 무언가를 질문합니다.

에이전트가 이를 이해합니다.

에이전트가 도구(tool)를 호출합니다.

시스템이 무언가를 업데이트합니다.

끝.

하지만 실제 ERP 또는 백엔드(backend) 환경에서는 그것만으로는 충분하지 않습니다.

AI가 생성한 액션이 운영 시스템(production system)에 도달하기 전에, 다음과 같은 기본적인 질문에 대한 답이 필요합니다.

이 액션을 누가 승인했는가?

페이로드(payload)가 검증되었는가?

사용자가 이 작업을 수행할 권한이 있는가?

공급업체가 활성 상태인가?

금액이 승인 임계값을 초과했는가?

재고 업데이트가 허용된 범위 내에 있는가?

최종 API 요청이 결정론적(deterministic)이었는가?

모든 단계가 로그(log)에 기록되었는가?

액션이 잘못되었을 경우 책임은 누구에게 있는가?

이것이 AI 실험과 AI 기반 비즈니스 워크플로우(workflow) 사이의 간극입니다.

AI-to-ERP 직접 실행이 위험한 이유

AI 에이전트가 ERP 시스템에 직접 데이터를 작성해서는 안 됩니다.

AI가 쓸모없기 때문이 아닙니다.

ERP 시스템에는 비즈니스에 핵심적인 데이터가 포함되어 있기 때문입니다.

그곳에는 고객, 송장, 공급업체, 결제, 재고, 급여, 승인 및 재무 기록이 들어 있습니다.

만약 AI 에이전트가 잘못된 페이로드를 보내거나, 잘못된 레코드를 선택하거나, 비즈니스 규칙을 건너뛴다면, 그 피해는 이론적인 수준에 그치지 않습니다.

보고, 운영, 재무, 컴플라이언스(compliance) 및 고객 신뢰에 영향을 미칠 수 있습니다.

그것이 제가 LLM이 실행을 직접 제어하는 패턴을 선호하지 않는 이유입니다.

LLM은 추론(reasoning)을 돕는 역할을 해야 합니다.

그것은 의도(intent)를 추출해야 합니다.

문맥(context)을 요약해야 합니다.

요청을 분류(classify)해야 합니다.

응답 초안을 작성해야 합니다.

하지만 실행(execution)은 결정론적 시스템(deterministic systems)에 의해 처리되어야 합니다.

더 나은 패턴: AI 실행 계층 (AI execution layer)

더 안전한 아키텍처는 다음과 같습니다:

Webhook 요청
→ AI 추출 (AI extraction)
→ 스키마 검증 (Schema validation)
...

이는 추론(reasoning)과 실행(execution)을 분리합니다.

AI는 ERP를 직접 업데이트하지 않습니다.

대신, 구조화된 출력(structured output)을 생성합니다.

그 출력은 검증됩니다.

그다음 비즈니스 규칙(business rules)에 따라 해당 동작을 허용할지, 차단할지, 또는 사람의 승인이 필요한지를 결정합니다.

그 과정이 모두 끝난 후에야 워크플로(workflow)가 ERP 또는 백엔드 API를 호출합니다.

로우코드 오케스트레이션 (low-code orchestration)이 도움이 되는 부분

이 지점이 바로 n8n과 같은 도구들이 유용해지는 부분입니다.

로우코드(low-code)가 백엔드 엔지니어링을 대체하기 때문이 아닙니다.

대체하지 못합니다.

여전히 Python, FastAPI, Django, API, 검증 모델(validation models), 데이터베이스, 그리고 적절한 인프라가 필요합니다.

하지만 로우코드 오케스트레이션은 가시적인 실행 계층(execution layer)을 제공합니다.

워크플로를 볼 수 있습니다.

라우팅 로직(routing logic)을 볼 수 있습니다.

승인 체크포인트(approval checkpoints)를 추가할 수 있습니다.

AI 추론(reasoning)을 API 실행(execution)으로부터 분리할 수 있습니다.

모든 결정을 로그(log)로 남길 수 있습니다.

비즈니스 팀과 기술 팀이 프로세스를 검토하기 더 쉽게 만들 수 있습니다.

AI가 실제 시스템을 건드리기 시작할 때는 이러한 가시성이 매우 중요합니다.

예시 아키텍처

실제적인 설정은 다음과 같을 수 있습니다:

n8n Webhook
    ↓
FastAPI AI 추출 서비스 (AI Extraction Service)
...

이 아키텍처에서:

FastAPI가 백엔드 서비스 계층을 처리합니다.
Pydantic이 엄격한 스키마(schemas)를 강제합니다.
n8n이 오케스트레이션(orchestration)과 승인 라우팅(approval routing)을 처리합니다.
ERP API는 검증된 요청만 수신합니다.
모든 결정은 로그로 기록됩니다.

AI는 유용하지만, 맹목적으로 신뢰되지는 않습니다.

데모 시나리오

두 가지 일반적인 ERP 스타일의 워크플로를 중심으로 작은 데모 컨셉을 만들었습니다:

저위험 재고 업데이트 (Low-risk inventory update)
고위험 공급업체 결제 (High-risk vendor payment)

재고 업데이트는 검증을 통과하고 허용된 한도 내에 있으면 진행될 수 있습니다.

공급업체 결제는 금액이 정의된 임계값(threshold)을 초과하는 경우 사람의 승인이 필요합니다.

유효하지 않거나 불완전한 요청은 ERP 계층(layer)에 도달하기 전에 차단됩니다.

예시:

{
  "request_text": "warehouse WH-01의 item SKU-1001 재고를 25개 늘려줘",
  "source": "webhook",
...

AI 추출(extraction) 서비스는 이를 구조화된 의도(structured intent)로 변환합니다.

그 다음, 검증(validation) 단계에서 필수 필드들을 확인합니다.

그 다음, 가드레일(guardrails)이 해당 동작을 계속 진행할 수 있을지 결정합니다.

오직 이 모든 과정을 거친 후에야 모의(mock) ERP 엔드포인트가 요청을 받게 됩니다.

가드레일이 확인하는 사항

몇 가지 간단한 규칙 예시:

10,000 이상의 공급업체 결제는 승인이 필요함.
공급업체 ID(vendor ID)가 누락되면 검증 실패.
500 유닛 이상의 재고 업데이트는 승인이 필요함.
알 수 없는 동작 유형(action type)은 차단됨.
신뢰도(confidence)가 낮은 AI 추출은 사람의 검토가 필요함.
비활성 공급업체에 대한 결제는 차단됨.

이러한 규칙들은 복잡하지 않습니다.

그것이 핵심입니다.

실행 계층(execution layer)은 예측 가능해야 합니다.

LLM이 런타임(runtime)에 모든 비즈니스 규칙을 결정하는 책임을 맡아서는 안 됩니다.

감사 로그(audit logs)가 중요한 이유

AI가 비즈니스 실행에 관여한다면, 감사 로그(audit logs)는 선택 사항이 아닙니다.

다음 사항들을 반드시 알아야 합니다:

어떤 요청이 들어왔는가
AI가 무엇을 추출했는가
검증(validation) 결과가 어떠했는가
어떤 가드레일 결정이 내려졌는가
승인이 필요했는가
누가 승인했는가
어떤 ERP 동작이 실행되었는가
어떤 응답이 돌아왔는가

이것이 없다면, 당신은 AI 워크플로우(workflow)를 가진 것이 아닙니다.

보이지 않는 자동화 리스크를 가진 것뿐입니다.

이 데모가 아닌 것

이것은 프로덕션(production)용 ERP 커넥터가 아닙니다.

이것이 그 자체로 컴플라이언스(compliance) 문제를 해결한다고 주장하지 않습니다.

이것은 인증(authentication), RBAC(역할 기반 액세스 제어), 속도 제한(rate limits), 비밀 관리(secret management), 모니터링(monitoring) 또는 적절한 보안 검토를 대체하지 않습니다.

셀프 호스팅(Self-hosting) 또한 시스템을 자동으로 컴플라이언스 준수 상태로 만들어주지 않습니다.

컴플라이언스는 구현, 호스팅, 계약, 액세스 제어(access control), 로깅(logging), 데이터 처리 및 내부 정책에 달려 있습니다.

이 데모의 목표는 더 단순합니다:

아키텍처 패턴을 보여주는 것입니다.

추론(reasoning)을 위한 AI.

실행(execution)을 위한 결정론적 시스템(deterministic systems).

가시성(visibility)을 위한 오케스트레이션(orchestration).

고위험 작업에 대한 승인 (Approval).

책임 소재 파악을 위한 감사 로그 (Audit logs).

이것이 ERP 시스템에 중요한 이유

이 패턴은 다음과 같은 환경에 잘 적용됩니다:

Odoo
Oracle
Django/FastAPI 비즈니스 시스템
내부 관리 포털 (Internal admin portals)
재무 워크플로 (Finance workflows)
재고 워크플로 (Inventory workflows)
CRM 자동화
지원 티켓 라우팅 (Support ticket routing)
벤더 및 송장 처리 (Vendor and invoice processing)

시스템이 더 중요할수록, 핸드오프(handoff) 설계는 더욱 중요해집니다.

주요 질문은 이것이 아닙니다:

어떤 LLM을 사용해야 하는가?

더 나은 질문은 다음과 같습니다:

AI는 어디에서 멈추고, 통제된 실행(controlled execution)은 어디에서 시작되는가?

GitHub 데모

이 패턴을 위한 작은 참조 리포지토리(reference repo)를 준비 중입니다:

리포지토리 구조는 다음을 포함합니다:

FastAPI 백엔드
모의(Mock) ERP 엔드포인트
Pydantic 검증 (Pydantic validation)
가드레일 규칙 (Guardrail rules)
감사 로그 저장소 (Audit log storage)
n8n 워크플로 내보내기 (n8n workflow export)
샘플 페이로드 (Sample payloads)
데모 스크립트
보안 참고 사항

데모 흐름은 다음과 같습니다:

웹훅 요청 (Webhook request) → AI 추출 (AI extraction) → 스키마 검증 (schema validation) → 가드레일 결정 (guardrail decision) → 필요 시 사람의 승인 (human approval if needed) → 모의 ERP 실행 (mock ERP execution) → 감사 로그 (audit log)

마지막 생각

AI 에이전트는 비즈니스 시스템 내부에서 더욱 유용해질 것입니다.

하지만 보이지 않는 관리자 사용자처럼 작동하도록 허용해서는 안 됩니다.

미래는 하나의 챗봇이 모든 것을 제어하는 모습이 아닙니다.

더 나은 방향은 통제된 실행 계층(controlled execution layers), 명확한 권한, 검증 규칙, 승인 체크포인트, 그리고 감사 추적(audit trails)입니다.

그곳이 바로 AI가 실제 운영에 유용해지는 지점입니다.

AI가 텍스트를 생성할 수 있기 때문이 아닙니다.

해당 워크플로가 요구하는 통제 장치를 우회하지 않고 비즈니스 워크플로를 지원할 수 있기 때문입니다.

Odoo, Oracle, Django/FastAPI 백엔드 또는 n8n 기반 자동화를 위해 이 패턴을 탐색하고 계신다면, 귀하의 환경에 어떻게 적응시킬 수 있을지 기꺼이 논의하겠습니다.