“이거 수정 좀 해주세요”가 왜 이렇게 위험한 말일까

Q10. 잘못 처리된 입고를 SAP에서 올바르게 처리하는 방법은?

A. 기존 입고 데이터를 수정한다
B. 테이블에서 직접 DELETE 한다
C. 입고 취소(역전표)를 생성한다
D. 다음 입고에서 보정한다

✅ 정답: C
👉 SAP는 사건을 지우지 않고, 사건을 추가한다.

“이거 수정 좀 해주세요”가 왜 이렇게 위험한 말일까

실무에서 정말 자주 듣는 말이 있다.

“이거 금액만 좀 수정해 주세요.”
“날짜만 바꾸면 될 것 같은데요?”
“그냥 잘못 들어간 거라서요.”

일반적인 웹 시스템이라면
크게 문제 될 말이 아니다.

하지만 **SAP**에서
이 말은 공기를 얼게 만든다.

왜냐하면 SAP에서 이 말은 사실상 이렇게 들리기 때문이다.

“과거에 일어난 사건을
없었던 것처럼 바꿔달라.”

 

 

 

---

1. SAP에서 ‘수정’은 단순한 UPDATE가 아니다

많은 사람들이 무의식적으로 이렇게 생각한다.

• 화면에서 값 바꾸기 = DB UPDATE
• 숫자 고치기 = 실수 수정

하지만 SAP에서 다루는 대부분의 데이터는
**단순 데이터가 아니라 ‘문서(Document)’**다.

문서는:

• 특정 시점에
• 특정 주체가
• 실제로 일어났다고 공식 인정한 사건

이다.

이걸 수정한다는 건
사건의 기록 자체를 바꾸는 행위다.

---

2. 왜 SAP는 “수정” 대신 “취소”를 강제할까

현실을 그대로 떠올려보자.

• 물건을 잘못 입고했다
  → 그 사실은 사라지지 않는다
  → 대신 “잘못된 입고를 취소했다”는 사건이 추가된다

SAP는 이 현실을 시스템에 그대로 반영한다.

그래서 SAP의 선택지는 항상 이거다.

• ❌ 기존 사건을 고친다
• ✔ 기존 사건을 취소하고, 새로운 사건을 기록한다

이 방식 덕분에:

• 과거는 보존되고
• 변경 이력은 명확해지고
• 누가, 언제, 왜 바꿨는지가 남는다

ERP로서 아주 정직한 태도다.

---

3. 전표 삭제가 거의 불가능한 진짜 이유

여기서 많은 사람들이 이렇게 묻는다.

“그럼 왜 삭제는 아예 안 되게 해놨어요?”

이유는 단순하다.

삭제는 ‘아무 일도 없었다’고
거짓말하는 행위이기 때문이다.

SAP는:

• 회계
• 감사
• 법적 책임

이 전부를 전제로 설계된 시스템이다.

과거 숫자가 조용히 바뀌는 순간,
SAP는 증명 능력을 잃는다.

그래서:

• 삭제 ❌
• 취소 ✔
• 역전표 ✔

라는 불편한 구조를 끝까지 고수한다.

---

4. 실무에서 “수정 좀 해달라”가 특히 위험한 순간들

이 말이 특히 위험해지는 순간들이 있다.

• 월말 마감 직전
• 이미 송장이 처리된 후
• 다른 문서와 연계가 끝난 뒤

이때 수정을 허용하면:

• 재고는 맞는데 회계가 틀어지고
• 회계는 맞는데 리포트가 깨지고
• 나중에는 아무도 책임을 못 진다

그래서 SAP는
아예 못 고치게 만들어 버린다.

사람을 믿지 않고
구조를 믿는 선택이다.

---

5. 개발자가 이 말을 제일 경계해야 하는 이유

개발자 입장에서 이 말은 더 위험하다.

“DB에서 직접 바꾸면 안 되나요?”
“배치로 한 번 맞추면 될 것 같은데요?”

이건 거의 항상 사고의 시작이다.

왜냐하면:

• SAP 데이터는 단일 테이블이 아니고
• 하나의 문서는 수십 개 흐름과 연결돼 있으며
• 한 군데만 고치면 반드시 어딘가가 깨진다

SAP 개발에서 가장 중요한 원칙은 이거다.

데이터를 고치지 말고,
흐름을 따라가라.

---

6. 그래서 SAP는 불편하지만, 강하다

여기까지 오면 이 문장이 자연스럽게 이해된다.

“SAP는 불편하지만, 믿을 수 있다.”

불편한 이유:

• 수정이 안 되고
• 취소 절차가 길고
• 월말이 힘들다

강한 이유:

• 모든 숫자에 출처가 있고
• 모든 변경에 이유가 남고
• 과거를 언제든 설명할 수 있다

이건 UI 문제가 아니라
철학의 문제다.

---

7. 이 글에서 반드시 남겨야 할 한 문장

이 시리즈의 거의 결론에 해당하는 문장이다.

SAP에서 ‘수정’은
실수를 고치는 행위가 아니라
역사를 바꾸는 행위다.

그래서 SAP는:

• 끝까지 거부하고
• 끝까지 귀찮게 하고
• 끝까지 기록을 남긴다

---

다음 단계 (여기서 시리즈를 어떻게 확장할까)

여기까지 왔다면
구매 → 입고 → 송장 → 월말 → 취소
하나의 큰 고리가 완성됐다.

다음으로 가장 자연스러운 확장은 둘 중 하나다.

1️⃣ 개발자 관점 정리
– 왜 SAP에서는 SELECT가 UPDATE보다 중요한가

2️⃣ 판매(SD) 흐름
– “이상하게 익숙한 구조”의 정체

어느 쪽으로 가도
지금까지 만든 사고방식이 그대로 재사용된다.

이제 SAP는 더 이상
“외워야 할 시스템”이 아니다.
이해하면 예측되는 시스템이다.