이전 편에서 봤듯이, SAP S/4HANA 구축 프로젝트는 여전히 사람 중심이다.
2026.02.25 - [IT 인사이트] - 왜 SAP S/4HANA로 전환하는가? ERP 구축 프로젝트의 진짜 이유와 현실
왜 SAP S/4HANA로 전환하는가? ERP 구축 프로젝트의 진짜 이유와 현실
많은 기업들이 SAP ERP를 도입해 사용하고 있다.그런데 또다시 막대한 예산을 들여 SAP S/4HANA 구축 프로젝트를 진행한다. 여기서 자연스럽게 질문이 생긴다.이미 ERP가 있는데 왜 다시 구축할까?왜
james3030.tistory.com
- 요구사항 분석은 회의 중심
- 데이터 정비는 수작업 중심
- 테스트 시나리오는 사람이 만든다
- 결함 분석은 경험 의존
그래서 ERP 프로젝트는 늘 이렇게 흘러간다.
회의 → 문서 → 개발/설정 → 통합 테스트에서 폭발 → 재설계 → 일정 지연
그렇다면 질문이 생긴다.
SAP ERP 프로젝트에 AI를 적용하면 무엇이 달라질까?
ERP 전체를 한 번에 바꾸겠다는 접근은 위험하다.
범위는 넓고, 데이터는 민감하고, 조직은 복잡하다.
그래서 이번 글에서는 딱 3가지만 본다.
✅ 회의록 입력
→ 요구사항 자동 정리
→ 영향도 자동 추천
→ 테스트 시나리오 자동 생성
목표는 단순하다.
사람이 회의에서 한 말이
바로 실행 가능한 “설계·테스트 작업 패키지”로 바뀌는 구조
ERP 프로젝트 사고는 왜 반복될까?
ERP 프로젝트의 실패는 보통 여기서 시작된다.
- 회의에서 나온 말이 문서로 정확히 정리되지 않는다
- 기존 Z 커스터마이징이 고려되지 않는다
- 영향도 분석이 누락된다
- 결국 통합 테스트(SIT)에서 터진다
문제는 “업무를 몰라서”가 아니다.
업무 요구가 SAP 내부 구조와 어디까지 연결되는지
설계 단계에서 제대로 추적하지 못하는 것이 본질이다.
그래서 가장 먼저 바꿔야 할 구간이:
요구사항 정의 → 영향도 분석 → 테스트 설계
실제 사례: 부분 출고 + 반품 요구
제조업 A사가 S/4HANA 전환 중이라고 가정하자.
워크숍에서 이런 요구가 나온다.
“주문 100개 중 50개만 출고하고,
그중 10개가 반품되면 매출을 차감해야 합니다.
반품 금액은 출고 당시 가격 기준이어야 합니다.”
말은 단순하다.
하지만 SAP 내부에서는 이렇게 연결된다.
- 출고 (LIKP/LIPS)
- 가격 조건 (KONV)
- 청구 문서 (VBRK/VBRP)
- 회계 전표 (BKPF/BSEG)
- Z 커스터마이징 (예: ZRSD2000)
설계 단계에서 이 연결을 놓치면:
- 반품 금액 불일치
- 회계 전표 오류
- SIT 폭발
- 일정 지연
이게 ERP 프로젝트의 현실이다.
🔴 To-Be: AI Agent는 실제로 어떻게 동작하는가
핵심은 “AI가 추측하지 않는다”는 것이다.
SAP 내부 구조를 근거로 답을 만든다.
즉, RAG(Retrieval-Augmented Generation) 구조다.
1️⃣ SAP 내부 “지식 사전” 구축
AI에 거래 데이터를 넣는 게 아니다.
가져오는 건 구조 정보다.
- DDIC: 테이블·필드 정의
- Z 오브젝트 목록
- Transport 변경 이력
- 인터페이스 목록
SAP를 “지도”처럼 만든다.
2️⃣ Vector DB – 의미 기반 검색 엔진
예를 들어 다음처럼 저장한다.
- “VBRK는 청구 문서 헤더 테이블이다.”
- “KONV는 가격 조건을 저장한다.”
- “ZRSD2000은 반품 가격 재계산 로직이다.”
회의록에 “반품/매출/가격”이 나오면
관련 SAP 오브젝트를 의미 기반으로 찾는다.
이게 SAP 영향도 분석 자동화의 1단계다.
3️⃣ Graph DB – 연쇄 영향 추적
Vector 검색만으로는 부족하다.
Graph DB에는 관계를 저장한다.
- ZRSD2000 → KONV 참조
- VBRK → BKPF 전표 생성
- LIKP → VBRK 연계
이제 AI는 단순 검색이 아니라
영향도 체인을 추적한다.
4️⃣ 회의록을 넣으면 벌어지는 일
회의록 입력:
“부분 출고 후 반품, 출고 당시 가격 기준”
AI는 이렇게 움직인다.
Step A – 요구사항 카드 생성
RQ-001: 부분 출고 매출 인식 규칙
RQ-002: 반품 시 매출 차감
RQ-003: 출고 당시 가격 기준
RQ-004: 회계 전표 정합성 조건
회의록이 구조화된다.
Step B – SAP 오브젝트 매핑
- 출고 → LIKP/LIPS
- 반품/청구 → VBRK/VBRP
- 가격 → KONV
- 회계 → BKPF/BSEG
- 커스터마이징 → ZRSD2000
Step C – 영향도 경고
요구: 출고 당시 가격 기준
기존 로직: 현재 가격 기준 가능성
AI가 이렇게 경고한다.
리스크: 반품 금액 불일치 → 회계 전표 오류 가능
즉, 테스트에서 터질 문제를 설계 단계에서 잡는다.
최종 산출물은 무엇인가?
AI Agent가 내놓는 결과는 이 구조다.
(1) 요구사항 카드
- 승인 필요 부서
- 예외 케이스 포함
(2) 영향 오브젝트 Top 10 + 근거
(3) SIT/UAT 테스트 시나리오 자동 생성
정상 흐름
예외 시나리오
가격 변경 케이스
재청구 케이스
(4) 테스트 데이터 체크리스트
고객
자재
가격 조건
세금 코드
플랜트
회의에서 나온 말이
바로 실행 가능한 설계·테스트 패키지로 바뀐다.
현실적인 도입 전략
전사 전체에 적용하면 실패한다.
현실적인 접근은:
- SD 한 프로세스만 대상
- DDIC 20~30개 사전화
- Z 프로그램 50~200개 목록화
- 회의록 5개 테스트
작게 시작해 정확도를 검증한다.
ERP 프로젝트는 “통째로”가 아니라 “반복 구간부터”
1편에서 ERP 프로젝트의 본질을 봤다.
사람 중심이고, 문서 중심이며, 반복 고통이 많다.
2편에서는 그중에서도
가장 사고가 많이 나는 구간을 바꿨다.
- 회의록 → 요구사항 구조화
- SAP 내부 지식 기반 영향도 분석
- 테스트 시나리오 자동 생성
ERP를 통째로 바꾸는 게 아니다.
가장 반복적이고 가장 위험한 구간부터 바꾸는 것이다.
'IT 인사이트' 카테고리의 다른 글
| K-푸드 수출이 터지는 진짜 이유: ‘규제’는 마지막 검토가 아니다 (0) | 2026.02.25 |
|---|---|
| ITSM을 도입했는데 왜 운영은 느릴까? AIOps가 필요한 진짜 이유 (0) | 2026.02.25 |
| 왜 SAP S/4HANA로 전환하는가? ERP 구축 프로젝트의 진짜 이유와 현실 (0) | 2026.02.25 |
| 서울대학교 SDN 설계 전략 총정리: Spine-Leaf·VXLAN·사설 IP 전환 아키텍처 분석 (0) | 2026.02.25 |
| 서울대학교 SDN 전환 이유 분석: 공인 IP 한계부터 Spine-Leaf·VXLAN 구조까지 (0) | 2026.02.25 |