SAP는 왜 삭제하지 않고, 반드시 취소하게 만들까

Q9. SAP에서 전표 삭제가 거의 불가능한 이유는?
A. 기술적으로 구현이 어렵기 때문이다
B. 시스템 성능 저하를 막기 위해
C. 과거 사건의 추적 가능성을 유지하기 위해
D. 사용자 교육이 어렵기 때문이다

✅ 정답: C👉 SAP는 **설명 가능성(Audit)**을 최우선으로 둔다.

SAP는 왜 삭제하지 않고, 반드시 취소하게 만들까

SAP를 처음 만난 사람은 거의 예외 없이 이렇게 말한다.

“이거 너무 불편한데요?”
“왜 삭제 버튼이 없어요?”
“그냥 수정하면 되지 않나요?”

이 질문에 대한 답을 이해하지 못하면
SAP는 끝까지 느리고 답답한 시스템으로 남는다.

하지만 이 질문에 답하는 순간,
SAP는 전혀 다른 얼굴을 드러낸다.

---

1. SAP는 ‘편한 시스템’이 아니라 ‘증명 가능한 시스템’이다

대부분의 웹 시스템은 이렇게 설계된다.

• 잘못 넣었으면 수정
• 필요 없으면 삭제
• 과거 데이터는 덮어쓰기

이건 업무 처리 속도에는 좋다.
하지만 증명에는 치명적이다.

반면 SAP는
처음부터 목표가 다르다.

SAP의 목표는
**“빠르게 처리하는 것”이 아니라
“나중에 반드시 설명할 수 있는 것”**이다.

그래서 SAP에는:

• DELETE가 거의 없고
• UPDATE가 극도로 제한되며
• 대신 취소 / 역전표 / 반대 전표가 존재한다

이건 불친절이 아니라 의도적인 선택이다.

---

2. SAP에서 ‘문서(Document)’는 로그가 아니라 증거다

SAP에서 가장 중요한 개념 하나만 고르라면
나는 주저 없이 이걸 고른다.

Document(문서)

SAP에서 문서는:

• 화면이 아니다
• 단순 데이터도 아니다

문서는 이런 성격을 가진다.

“그 시점에 실제로 일어났다고
회사가 공식적으로 인정한 사건”

그래서 문서에는 항상:

• 번호가 있고
• 생성 시점이 고정되고
• 나중에 구조적으로 바꿀 수 없다

이 개념이 없으면
이후에 나오는 모든 불편함이 이해되지 않는다.

---

3. 왜 SAP는 ‘취소’를 강제할까 (논리적으로 따져보자)

현실 세계를 생각해 보자.

• 물건을 잘못 입고했다
  → 그 사실 자체는 사라지지 않는다
  → “잘못됐다”는 사건이 추가로 발생한다

SAP는 이 현실을 그대로 시스템에 옮긴다.

그래서 SAP의 사고는 이렇다.

• ❌ “없었던 일로 하자”
• ✔ “있었던 일을 취소하는 일이 발생했다”

이 차이 하나 때문에:

• 모든 이력이 남고
• 감사(Audit)가 가능하고
• 숫자가 언제든 추적된다

ERP가 가져야 할 태도로는
굉장히 정직하다.

---

4. 이 철학이 왜 중요한가 (실무 관점)

이 철학은 나중에 이렇게 터진다.

• 왜 입고 취소가 귀찮은지
• 왜 전표 삭제가 안 되는지
• 왜 월말에 숫자 맞추는 게 힘든지
• 왜 “수정 좀 해주세요”가 위험한 말인지

즉, 이 글에서 설명한 개념은
앞으로 나올 모든 불편함의 근원이다.

이걸 이해하고 보면:

• SAP의 제약 = 결함 ❌
• SAP의 제약 = 통제 장치 ⭕

로 인식이 바뀐다.

---

5. 워밍업 정리 (여기까지만 기억하면 된다)

이 글에서 꼭 고정해야 할 건 두 가지다.

1. SAP는 삭제보다 설명 가능성을 선택했다
2. SAP의 문서는 데이터가 아니라 증거다

이 두 개만 머릿속에 넣고 가면
다음 글부터는 훨씬 편해진다.

---

다음 글 예고 (바로 실무로 들어간다)

다음 글에서는 바로 이 장면으로 간다.

“구매팀이 구매 오더를 만들었습니다.”
그런데 왜 회계는 아무 반응이 없을까?

다음 글

구매 오더는 왜 ‘아무 일도 안 일어난 것처럼’ 취급될까

여기서부터
SAP의 불편함은 점점 논리적인 제약으로 바뀌기 시작한다.

SAP는 느린 시스템이 아니다.
거짓말을 허용하지 않는 시스템이다.