ABAP & 기술 관점

ABAP 개발에서 UPDATE 문 사용이 제한적인 이유로 가장 적절한 설명은?

A. 성능이 느리기 때문이다
B. 최신 문법이 아니기 때문이다
C. 문서 불변성과 감사 추적을 깨뜨릴 수 있기 때문이다
D. HANA에서 지원하지 않기 때문이다

✅ 정답: C

 

Ⅵ. ABAP & 기술 관점

SAP 개발이 이렇게 ‘조심스러울’ 수밖에 없는 이유

여기까지 왔다면 눈치챘을 거다.
SAP 개발은 빠르게 바꾸는 기술이 아니라
끝까지 설명 가능한 결과를 만드는 기술이다.

그래서 ABAP은 투박해 보이고,
그래서 UPDATE보다 SELECT가 많고,
그래서 배치가 아직도 살아 있다.

 

 

 

---

1. ABAP은 느린 언어가 아니라 ‘보수적인 언어’다

ABAP을 처음 보면 이런 인상이 든다.

• 문법이 오래됐다
• 코드가 장황하다
• 최신 웹 프레임워크 느낌이 아니다

하지만 이건 목표가 다르기 때문이다.

ABAP의 목표는:

• 빨리 바꾸기 ❌
• 예쁘게 쓰기 ❌
• 절대 틀리지 않기 ⭕

그래서 ABAP은:

• 암묵적 변경을 싫어하고
• 자동 반영을 경계하며
• 개발자에게 “한 번 더 생각하라”고 강요한다

---

2. 왜 SAP 개발은 SELECT가 이렇게 많은가

실무 ABAP 요구사항을 떠올려보자.

• 이 금액은 왜 이렇게 나왔나
• 이 전표는 어디서 시작됐나
• 이 재고는 어떤 이동을 거쳤나

전부 변경 요청이 아니라 설명 요청이다.

그래서 ABAP 개발의 핵심은 이거다.

데이터를 바꾸는 코드보다
데이터를 해석하는 코드

S/4HANA 이후에는 특히:

• 집계 테이블 ❌
• 계산은 조회 시점 ⭕

이 되면서
SELECT + JOIN + 집계 로직이 더 중요해졌다.

---

3. UPDATE가 위험해지는 구조적 이유

SAP 데이터의 본질을 다시 떠올리면 답이 보인다.

• 대부분의 핵심 데이터는 문서
• 문서는 불변
• 변경은 취소 + 신규 문서

이 구조에서 UPDATE는 거의 항상 문제를 만든다.

• 한 테이블은 맞는데
• 문서 흐름이 끊기고
• 회계와 어긋나며
• 감사 시 설명이 안 된다

그래서 SAP 개발의 불문율은 이거다.

UPDATE는 마지막 수단이고,
보통은 쓰지 않는다.

---

4. ABAP에서 Commit을 직접 다루는 이유

일반 애플리케이션에서는:

• 프레임워크가 알아서 커밋하고
• 개발자는 크게 신경 안 쓴다

SAP는 정반대다.

• Commit은 사건 확정
• 한 LUW에 여러 단계 포함
• 실패 시 전부 Rollback

그래서 ABAP에서는:

• COMMIT WORK
• ROLLBACK WORK

를 명시적으로 다룬다.

이건 귀찮음이 아니라
책임을 개발자에게 명확히 넘기는 설계다.

---

5. 왜 배치(Job)가 아직도 중요한가

“S/4HANA면 실시간 아닌가요?”
여기서 또 오해가 나온다.

• 실시간 계산 ⭕
• 실시간 결정 ❌

월말 마감, 대량 정산, 대규모 전표 생성은:

• 시간도 중요하지만
• 통제와 재현성이 더 중요하다

그래서 SAP는 여전히:

• 배치(Job)
• 실행 이력
• 재처리 가능성

을 중시한다.

배치는 느린 방식이 아니라
안전한 방식이다.

---

6. HANA 시대의 ABAP 역할 변화

S/4HANA 이후 ABAP은 이렇게 역할이 바뀌었다.

• 계산 엔진 ❌
• 오케스트레이터 ⭕
• 무거운 계산 → HANA
• 흐름 제어 / 검증 → ABAP

ABAP은:

• 언제 계산할지
• 어떤 기준으로 볼지
• 어떤 문서를 인정할지

를 결정한다.

숫자를 만드는 게 아니라
숫자를 해석할 규칙을 관리한다.

---

7. 시험에서 기술 관점을 어떻게 묻나

자격증에서 ABAP/기술 문제는
코드를 묻지 않는다.

대신 이런 걸 묻는다.

• Commit의 의미
• LUW의 목적
• 실시간 계산의 전제
• 집계 제거 이유

정답 키워드:

• Consistency
• Transaction
• Commit
• Real-time calculation

오답 패턴:

• 성능 튜닝
• 코드 최적화
• 편의 기능

---

🔑 이 파트의 핵심 문장

이 글에서 반드시 남겨야 할 문장은 이거다.

ABAP은
데이터를 바꾸기 위한 언어가 아니라
데이터를 함부로 바꾸지 못하게 하기 위한 언어다.

그래서:

• 불편하고
• 조심스럽고
• 느려 보인다

하지만 그 덕분에
SAP의 숫자는 끝까지 살아남는다.

---

다음 글 예고

이제 마지막 퍼즐로 간다.

“그럼 SAP는
이 모든 걸 어떻게 ‘사람’으로부터 지켜낼까?”

다음 글

Ⅶ. 통제, 권한, 감사
– SAP가 끝까지 무너지지 않는 진짜 이유

여기서:

• 권한(Role)
• 분리 통제(SoD)
• 감사 로그

가 하나로 묶이며
SAP의 진짜 무기가 드러난다.