AI 에이전트 ERP의 자가학습 설계 — 컬럼 6개에서 폐루프까지

신진형 · 에스엘파워 · 2026.07.05

“AI 기능이 달린 ERP”와 “시간이 지날수록 판단이 좋아지는 ERP”는 완전히 다른 시스템입니다. 왜 학습 엔진보다 기록 구조를 먼저 박아야 하는지는 〈에이전트 자가학습〉에 적었습니다. 이 글은 그다음 질문 — 그 구조를 실제로 어떻게 설계하는가 — 에 대한 답입니다. 컬럼 → 테이블 → 피드백 루프 → 학습 엔진 순으로 무엇을 만들어야 하는지, SL.AIMS의 자가학습 구조를 설계·검토하며 정리한 구현 청사진의 기록입니다.

Logging System과 Learning System은 다르다

요즘 만들어지는 “AI ERP”의 대부분은 이렇게 동작합니다. 사람이 요청하면, AI 에이전트가 데이터를 조회해 판단을 내리고, 그 판단과 근거를 DB에 저장합니다. 여기까지만 보면 꽤 그럴듯합니다. 판단 근거가 기록되니 감사(audit)도 되고, “AI가 왜 그렇게 했는지” 설명도 가능하니까요.

그런데 여기서 멈추면 그 시스템은 **Logging System(기록 시스템)**이지 **Learning System(학습 시스템)**이 아닙니다. 판단을 기록하기만 하는 AI는 자신의 판단이 좋았는지 나빴는지 영원히 알지 못하고, 따라서 영원히 같은 실수를 반복합니다. 1년을 운영해도 첫날과 똑같은 품질의 판단을 내립니다.

“현재 구조는 ‘AI가 학습할 준비’는 되어 있지만, ‘AI가 성장하는 구조’는 아니다. 컬럼과 테이블은 잘 설계해 놓고도 마지막 30%(실행 → 평가 → 학습 → 반영 루프)를 구현하지 않는 것이 가장 흔한 실패 패턴인데, AI 시스템은 오히려 그 마지막 30%가 핵심이다.” — AI 에이전트 시스템을 검토한 아키텍트들이 공통적으로 내리는 진단

같은 "AI ERP"라도 왼쪽은 판단을 저장할 뿐이고, 오른쪽은 판단의 결과가 다음 판단으로 되돌아옵니다. 이 되돌아오는 화살표 하나가 두 시스템의 결정적 차이입니다.

쉽게 비유하면 이렇습니다. 신입사원이 매일 업무 일지를 꼼꼼히 쓰지만 아무도 읽어주지 않고, 본인도 다시 열어보지 않는다면 그 일지는 성장에 아무 도움이 되지 않습니다. 일지를 쓰는 행위(Logging)와, 일지를 돌아보고 상사의 피드백을 받아 다음 주 업무 방식을 바꾸는 행위(Learning)는 전혀 다른 것입니다. AI 에이전트도 정확히 같습니다.

‘자가 학습’의 실제 의미 — 모델 재학습이 아니다

“자가 학습형 ERP”라고 하면 많은 분들이 “그럼 LLM 모델을 매일 밤 파인튜닝한다는 건가?”라고 오해합니다. 아닙니다.

❌ 자가 학습이 아닌 것	✅ 실제의 자가 학습
업무 데이터로 LLM을 실시간 재학습(fine-tuning)하는 것. 비용·안정성·규제·재현성 문제로 실제 업무 시스템에서는 거의 채택하지 않습니다.	AI의 판단, 사용 도구, 당시 컨텍스트, 사람의 피드백, 최종 결과 점수를 데이터로 축적하고, 이후 유사한 상황에서 그 축적물을 검색·참조하여 더 나은 판단을 내리게 하는 것.

즉 학습의 실체는 “모델이 똑똑해지는 것”이 아니라 **“모델에게 주어지는 컨텍스트(경험 데이터)가 풍부해지고 정제되는 것”**입니다. 같은 LLM이라도 과거 유사 사례 20건, 검증된 패턴, 실패에 대한 반성 메모가 함께 주어지면 판단 품질이 달라집니다. 검색 증강 생성(RAG)은 외부 지식을 검색해 판단 품질을 높이고, Reflexion 계열 연구는 에이전트가 자신의 실패를 언어로 반성해 메모리에 남기면 다음 시도의 성공률이 유의하게 오른다는 것을 보여줬습니다. 주요 AI 랩들이 에이전트 제품에 장기 메모리와 자기 반성 메커니즘을 공통적으로 탑재하는 이유이기도 합니다.

“에이전트의 지능은 모델 그 자체보다 모델을 둘러싼 컨텍스트 파이프라인에서 나온다. 똑같은 모델을 쓰더라도 어떤 팀은 성장하는 에이전트를, 어떤 팀은 정체된 에이전트를 만든다. 차이는 경험 데이터를 축적하고 되먹임하는 구조의 유무다.” — 에이전트 아키텍처 실무자들 사이의 공통된 견해 (RAG · Reflexion · Memory 연구 흐름의 요지)

판단의 생애주기로 설계 순서를 정하라

자가 학습 구조를 설계할 때 기능 목록(“패턴 마이닝, 임베딩 검색, 반성 엔진…”)부터 나열하면 반드시 순서가 꼬입니다. 올바른 접근은 판단(Decision) 하나가 태어나서 학습 재료가 되기까지의 시간 순서로 설계 대상을 나누는 것입니다.

단계	시점	만드는 것	구축 순서
Phase A	판단 전	과거 유사 사례 검색 (Similarity Retrieval)	3번째 — 과거 판단이 쌓여야 의미가 있음
Phase B	판단 시점	판단 + 근거를 원장에 기록 (Decision Log)	★ 가장 먼저
Phase C	직후~단기	사람 평가 + 결과 자동검증 (Feedback · Outcome Eval)	2번째
Phase D	장기 축적 후	패턴 발견 · 반성 · 정책 개선 (Mining · Reflection · Policy)	마지막 — 데이터가 쌓인 뒤에만

컬럼 설계 — 모든 업무 테이블에 남겨야 할 6가지 흔적

AI 에이전트가 데이터를 조회하고, 변경안을 만들고, 일부 업무를 직접 실행하는 순간부터 모든 업무 레코드는 최소한 세 가지 질문에 답할 수 있어야 합니다 — (1) 이 레코드는 사람이 만들었나, AI가 제안했나, 시스템이 자동 생성했나? (2) AI가 제안했다면 신뢰도는 얼마이고 판단 근거 로그는 어디에 있나? (3) 사람이 AI 제안을 고치거나 거부했다면 왜 그랬나?

이 세 질문에 답하기 위한 최소 단위가 아래의 표준 6컬럼 블록입니다. 모든 트랜잭션 테이블에 동일하게 삽입합니다.

컬럼	타입(예: Prisma)	역할
`aiSuggested`	`Boolean @default(false)`	이 레코드/변경이 AI 제안으로 생성됐는지 표시
`aiConfidence`	`Float?`	AI 제안의 신뢰도(0~1)
`aiDecisionId`	`String?`	판단 원장(Decision Log)을 역참조 — “근거 표시 의무”의 핵심 연결고리
`inputActorType`	`String? @default("01")`	입력 주체 구분 공통코드 (01=HUMAN, 02=AGENT, 03=SYSTEM)
`humanOverridden`	`Boolean @default(false)`	사람이 AI 제안을 수정·거부했는지
`humanOverrideReason`	`String?`	왜 고쳤는지 — 훗날 정책 개선의 원재료가 되는 가장 중요한 필드

어떤 테이블에 적용할지는 우선순위로 정합니다.

우선순위	대상	이유
1순위 필수	AI가 실제로 제안·변경하는 트랜잭션 테이블 (주문, 승인, 정정요청, 견적 등)	이게 없으면 “AI가 왜 그렇게 판단했는지” 감사 추적이 그 지점에서 끊김
2순위	같은 업무 파이프라인의 부속 테이블 (첨부, 이력, 상세)	핵심 문서에만 넣고 부속을 빠뜨리면 상세 데이터에서 추적이 끊기는 “반쪽 적용”이 됨
3순위 재량	마스터·참조 데이터 (코드, 품목마스터 등)	“AI 제안” 개념이 성립하기 애매하므로, 예외로 둘지 원칙대로 넣을지 처음부터 명문화
예외 취급	에이전트 인프라 테이블 자신 (판단 로그 등)	“이 로그가 AI 제안인지”를 묻는 것은 재귀적으로 의미가 옅음 — 전용 학습 필드로 원칙 충족

테이블 설계 — 학습 원재료가 쌓이는 핵심 4테이블

6컬럼이 “각 업무 테이블에 남기는 흔적”이라면, 아래 4테이블은 그 흔적들이 모여 실제로 학습 가능한 형태로 축적되는 중앙 저장소입니다.

① Decision Log — 판단 원장

모든 AI 판단 1건 = 이 테이블 1행. 자가 학습의 심장입니다.

필드	의미와 학습 활용 관점
`decisionType` / `agentType`	어떤 종류의 판단인지 — 집계·데이터 게이트의 기준 단위
`decisionResult` (JSON)	판단 내용 자체
`contextSnapshot` (JSON)	판단 당시 근거가 된 입력값 스냅샷 — 이후 유사 상황 비교의 기준 데이터
`toolsUsed`	AI가 사용한 도구 목록 — “어떤 도구 조합이 좋은 결과를 냈는가” 분석용
`humanFeedback` / `humanFeedbackAt`	correct / wrong / partial — 진짜 학습 신호의 핵심
`outcomeScore` / `outcomeVerifiedAt`	N일 후 자동 결과검증 점수(-1 ~ +1)와 시각
`learnedPattern`	패턴 마이닝의 산출물이 역기록되는 자리
`similarDecisionIds`	유사 판단 로그 ID 목록 — 유사 사례 기반 추천·검증에 사용

② Agent Memory — 장기 기억

임베딩 기반 유사도 검색이 가능한 저장소(pgvector 등)입니다. kind 구분값을 코드화(단기 / 장기 / 도메인 요약 / 실패 반성)해서 성격이 다른 기억이 섞이지 않게 합니다. 흔한 실패는 Memory 테이블을 만들어 놓고 Decision Log와 연결하는 컬럼이 없어서 “기억은 있는데 어떤 판단에서 왜 생겼는지 추적 불가”가 되는 것입니다. 설계 시점에 Decision ↔ Memory 역참조 컬럼을 반드시 넣어야 합니다.

③ Knowledge Item — 마이닝된 지식

패턴 마이닝이 발견한 “반복 패턴”이 최종적으로 쌓이는 곳입니다. sourceType(수동입력 / 결재사례 / 패턴마이닝 등)으로 출처를 구분하고, supportingDecisionIds로 이 패턴이 어떤 판단들에서 나왔는지 근거를 반드시 남깁니다. 근거 없는 패턴은 신뢰할 수 없습니다.

④ Agent Task — HITL 큐

사람 개입(Human-in-the-Loop)이 대기하는 큐입니다. 승인/반려용으로만 좁게 설계하지 않습니다. taskType을 확장 가능한 코드로 설계해 두면, 나중에 “정책 변경 제안” 같은 새로운 유형의 사람 개입도 신규 테이블 없이 이 큐에 얹을 수 있습니다.

연결 관계는 단순합니다 — 업무 테이블의 aiDecisionId가 판단 원장을 가리키고, 판단 원장에서 기억(반성 저장)·지식(패턴 집계)·HITL 큐(override 사유 반복 → 정책변경 제안)로 데이터가 흘러갑니다. 연결 컬럼이 하나라도 빠지면 그 지점에서 학습 추적이 끊깁니다.

피드백 클로즈드 루프 — 루프를 진짜로 ‘닫는’ 법

루프가 “닫힌다”는 것은 아키텍처 그림에서 화살표가 예쁘게 이어진다는 뜻이 아닙니다. 각 화살표마다 실제로 값을 쓰는 코드와, 그 값을 읽어 다음 판단에 쓰는 코드가 둘 다 존재한다는 뜻입니다. 한쪽만 있으면 — 대개 “쓰기”만 있고 “읽기”가 없습니다 — 루프는 닫힌 것처럼 보이지만 실제로는 열려 있습니다.

루프는 여섯 마디입니다. ① Decision(판단+근거 기록) → ② Result(실행/반영) → ③ Human Feedback(맞음/틀림/일부맞음 + 사유) → ④ Outcome Eval(N일 후 자동 결과검증) → ⑤ Learning(패턴 발견 + 반성) → ⑥ Policy Update(제안 → 사람 승인 필수) → 다시 ①로. 정책 갱신의 마지막 방아쇠는 반드시 사람이 당깁니다.

HITL을 “승인/반려 버튼”으로만 쓰는 시스템이 많습니다. 그러나 학습 관점에서 HITL은 가장 값진 교사 신호(supervision signal)의 공급원입니다. 사람이 AI의 추천을 수정했다면, 그 순간 “왜 수정했습니까?”를 한 줄이라도 받아 저장해야 합니다. 그 한 줄이 쌓여 정책 개선의 원재료가 됩니다.

“AI 에이전트 ERP의 경쟁력은 ‘자동 입력’이 아니라 ‘근거 있는 제안 → 사람 승인 → 결과 검증 → 다음 판단 개선’의 순환 구조다. 승인 버튼만 있는 HITL은 안전장치일 뿐이지만, 수정 사유까지 수집하는 HITL은 학습 장치가 된다.” — 업무 시스템에 에이전트를 도입한 팀들이 공통적으로 도달하는 결론

자가 학습 6단계 엔진 (Level 1~6)

루프를 실제 코드로 구현할 때는 아래 6개 엔진을 독립 모듈로 나눠 단계적으로 구축하는 것이 현실적입니다. 낮은 레벨일수록 먼저, 그리고 모든 업무 도메인(인사·회계·구매·생산·품질·영업…)이 재사용하는 공통 프레임워크로 만들어야 도메인마다 학습 구조를 중복 개발하는 낭비를 막을 수 있습니다.

레벨	엔진	하는 일
Level 1	Decision Evaluation Engine	판단 후 N일(예: 30일)이 지나면 결과를 자동 평가해 Outcome Score(-1~+1)를 계산. 이게 없으면 AI는 자기가 잘했는지 못했는지 평생 모름
Level 2	Human Feedback Collector	AI가 추천할 때마다 맞음 / 틀림 / 일부 맞음 + 수정 이유를 반드시 수집·저장
Level 3	Pattern Mining Engine	매일 밤 판단 로그를 분석해 반복 패턴을 자동 추출. 예: “최근 3개월 인사결정에서 결재권자가 거절한 이유 Top 20”
Level 4	Similarity Retrieval	새로운 판단 직전, 현재 상황을 임베딩해 과거 유사 사례 N건을 검색하고 “그때 사람은 어떻게 판단했는가”를 참고자료로 주입
Level 5	Reflection Engine	실패한 판단에 대해 “왜 실패했지? 다음부터 이렇게 하자”를 자동 생성해 Memory에 저장 (Reflexion 계열 연구에서 검증된 방식)
Level 6	Policy Evolution Engine	override 사유·피드백이 일정 기준 이상 누적되면 정책 변경을 제안. 확정은 반드시 사람이

구체적인 예로 보면 이렇습니다 — 승진 추천 시나리오입니다(인명은 가상의 예시입니다).

1일차. AI가 인사 데이터를 보고 “A부서 홍길동 과장의 부장 승진”을 추천합니다. 판단 내용, 참고한 데이터 스냅샷, 사용 도구, 신뢰도 0.82가 판단 원장에 1행으로 기록됩니다. (Phase B)
1일차, 10분 뒤. 인사 결재권자가 추천을 검토하고 “일부 맞음”으로 평가하면서 “이 직급의 승진은 조직 규모도 함께 봐야 함”이라는 수정 사유를 남깁니다. (Level 2)
30일 후. 배치가 돌면서 실제 승진 발령과 이후 조직 지표를 확인해 이 판단에 Outcome Score +1을 기록합니다. (Level 1)
그날 밤. 패턴 마이닝이 최근 1,000건의 인사 판단을 분석해 “10명 이하 조직의 부장 승진은 90% 승인된다”는 패턴을 발견하고 Knowledge Item에 근거 판단 ID들과 함께 저장합니다. (Level 3)
3개월 후. 새로운 승진 판단이 들어오자, AI는 판단 전에 유사 사례 20건을 검색해 참고하고(Level 4), 과거 실패 판단에서 생성된 반성 메모 “조직 규모를 반드시 확인할 것”을 함께 주입받아(Level 5) 더 정확한 추천을 냅니다.
6개월 후. “연차 승인 기준이 최근 3개월간 일관되게 달라졌다”는 신호가 누적되자, 시스템이 정책 변경안을 만들어 HITL 큐에 올리고, 사람이 승인하면 정책이 갱신됩니다. (Level 6)

이 시나리오에서 LLM 모델 자체는 한 번도 재학습되지 않았다는 점에 주목해야 합니다. 바뀐 것은 판단에 주입되는 경험 데이터의 양과 질뿐입니다. 그런데 판단 품질은 눈에 띄게 좋아집니다. 이것이 업무 시스템에서의 자가 학습입니다.

데이터 게이트와 안전 불변식 — 학습이 폭주하지 않게

자가 학습 구조에서 가장 위험한 것은 학습이 안 되는 것이 아니라, 잘못 학습되는 것입니다. 적은 표본으로 성급하게 일반화하거나, 시스템이 스스로 만든 가짜 신호로 자신을 오염시키는 경우입니다.

먼저 데이터 게이트 — 패턴 마이닝·정책 제안 같은 Phase D 엔진은 판단 유형별로 최소 표본 수(예: 판단 N건 이상, 피드백 M건 이상)를 넘기 전에는 산출물을 내지 않도록 게이트를 겁니다. “판단 12건을 보고 정책을 바꾸자고 제안하는 AI”는 도움이 아니라 리스크입니다.

다음으로 루프를 지키는 5가지 불변식입니다.

불변식	이유
사람 피드백은 반드시 사람이 실제로 검토한 경우에만 기록. 시스템이 자동으로 “정답”을 채우는 것은 금지	가짜 학습 신호를 스스로 만들어내는 순환 오염(feedback loop contamination) 방지
Outcome Score는 도메인별로 값의 범위를 강제(clamp)	검증기 버그 하나가 학습 데이터 전체를 오염시키는 것을 프레임워크 레벨에서 차단
정책 개선 엔진의 산출물은 ‘제안’이지 확정이 아님. 코드가 정책 테이블을 직접 갱신하는 경로는 존재해서는 안 됨	AI가 스스로 규칙을 바꾸는 것은 안전·통제 관점에서 가장 위험한 지점 — 반드시 사람이 마지막 방아쇠를 당김
동일 판단에 대한 반성·패턴은 중복 생성되지 않음 (dedup 키 필요)	배치가 여러 번 돌아도 같은 결론이 여러 번 쌓여 가중되지 않도록
유사 사례 검색은 같은 판단 유형(decisionType) 내에서만	도메인이 다른 판단끼리 잘못 참고되는 것(컨텍스트 누수) 방지

“자가 학습 시스템 설계의 절반은 학습을 ‘시키는’ 설계이고, 나머지 절반은 학습을 ‘막는’ 설계다. 언제 배우면 안 되는지, 무엇으로부터 배우면 안 되는지를 정의하지 않은 학습 루프는 시간이 지날수록 나빠지는 시스템을 만든다.” — 피드백 루프 오염을 경험해 본 ML 시스템 운영자들의 공통 조언

왜 이렇게까지 안전장치가 필요한가 — ERP가 다루는 데이터는 급여, 인사평가, 근로시간, 회계, 계약처럼 법적·조직적 책임과 직결되기 때문입니다. AI 에이전트 ERP에서 가장 위험한 것은 AI가 업무를 대신 처리하는 것 자체가 아니라, **“왜 그런 판단을 했는지 알 수 없는 상태에서 업무 데이터가 변경되는 것”**입니다. 그래서 자가 학습 구조와 감사(audit) 구조는 사실 같은 뿌리에서 나옵니다. 판단 근거를 남기는 6컬럼과 판단 원장은 학습의 재료인 동시에, 감사·분쟁·내부통제 상황에서의 증빙이기도 합니다. AI의 권한 경계를 어디에 긋는지는 〈에이전트가 할 수 있는 일과 없는 일〉에 있습니다.

자주 묻는 질문

Q. LLM이 더 좋아지면 이런 구조 없이도 되지 않나요? A. 모델이 좋아져도 당신 조직의 의사결정 이력은 모델 안에 없습니다. “우리 회사 결재권자가 어떤 기준으로 승인하는가”는 축적된 경험 데이터에서만 나옵니다. 모델이 좋아질수록 오히려 좋은 컨텍스트 파이프라인의 가치가 커집니다.

Q. 컬럼과 테이블만 잘 만들어 두면 절반은 된 것 아닌가요? A. 아닙니다. 그게 바로 가장 흔한 실패 패턴입니다. 컬럼이 있어도 채우고 읽는 코드가 없으면 Logging System에 머뭅니다. 실행 → 평가 → 학습 → 반영의 마지막 30%가 핵심입니다.

Q. 어디서부터 시작해야 하나요? A. Phase B(판단 원장 + 표준 6컬럼)부터입니다. 선행 조건이 없고, 오늘부터 쌓이는 데이터가 이후 모든 단계의 원재료가 되기 때문입니다. 그다음이 피드백 수집(Level 2)이고, 패턴 마이닝·정책 제안은 데이터 게이트를 넘긴 뒤 가장 마지막입니다.

Q. AI가 정책을 스스로 바꾸게 하면 더 빠르지 않나요? A. 빠르지만 가장 위험합니다. 정책 자동 갱신 경로는 코드에 존재해서는 안 되며, AI는 ‘제안’까지만, 확정은 반드시 사람이 해야 합니다. 이것은 성능 문제가 아니라 통제·안전 문제입니다.

설계 검증 최종 체크리스트

No	점검 항목	단계
1	모든 트랜잭션 테이블에 표준 6컬럼이 있고, 신규 테이블 템플릿에 기본 포함되는가	Phase B
2	판단 1건 = 판단 원장 1행으로 기록되며, 검색에 쓸 필드가 contextSnapshot 안에 있는가	Phase B
3	업무 레코드 → 판단 원장 → 메모리 → 지식 항목의 역참조 연결 컬럼이 모두 있는가	Phase B
4	AI 추천마다 맞음/틀림/일부맞음 + 수정 사유가 수집되는가 (자동 채움 금지)	Phase C
5	N일 후 Outcome Score를 계산하는 배치가 있고, 점수 범위가 clamp되는가	Phase C
6	민감 업무는 HITL 승인 후에만 반영되며, 승인 큐의 taskType이 확장 가능한가	Phase C
7	패턴 마이닝·반성·정책 제안에 최소 표본 데이터 게이트가 걸려 있는가	Phase D
8	패턴에 근거 판단 ID(supportingDecisionIds)가 남고, dedup 키로 중복 생성이 방지되는가	Phase D
9	유사 사례 검색이 같은 decisionType 내에서만 이뤄지는가	Phase A
10	정책 테이블을 코드가 직접 갱신하는 경로가 존재하지 않는가 (제안 → 사람 승인만 존재)	Phase D
11	루프의 모든 화살표에 ‘쓰는 코드’와 ‘읽는 코드’가 둘 다 존재하는가	전체
12	이 프레임워크가 특정 도메인 전용이 아니라 전 업무 도메인 공통으로 재사용 가능한가	전체

본문의 컬럼·테이블 명칭은 이해를 돕기 위한 예시이며, 각 조직의 스키마 규칙에 맞게 조정해 쓰면 됩니다. 인용된 견해는 특정 개인의 발언이 아니라 관련 실무·연구 커뮤니티에서 공유되는 공통 견해를 요약한 것입니다.

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 개념 편은 〈에이전트 자가학습〉에, 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.