SAP 에서 데이터를 다건 또는 단건으로 자동 입력해야 할 때 가장 먼저 마주치는 선택지가 BDC(Batch Data Communication) 와 BAPI(Business Application Programming Interface) 입니다. 둘 다 "표준 트랜잭션을 ABAP 코드로 자동화한다" 라는 목적은 같지만, 동작 방식·성능·호환성·CBO(자체 개발 화면) 대응 면에서 성격이 완전히 다릅니다.
신입 ABAP 개발자가 가장 자주 묻는 질문이 "그래서 어느 걸 써야 하나요" 입니다. 정답은 단순합니다 — 가능하면 BAPI, BAPI 가 없거나 회사 특화 화면이 끼어 있으면 BDC. 그런데 그 한 줄로 끝낼 수 있는 결정이 실제 업무에서는 모듈러 신입에게 자주 혼란을 줍니다. 비슷한 자동화 작업인데 어떤 자재는 BAPI 로 깨끗하게 처리되고 어떤 자재는 BDC 가 강제되는 이유, BAPI 가 명백히 빠른데 왜 회사에서 여전히 BDC 자동화 프로그램이 운영되고 있는지 같은 부분이 익숙해질 때까지 시간이 걸립니다.
이 글은 BDC 와 BAPI 의 동작 방식 차이 → 성능 비교 → Custom 필드 대응 → 시스템 업그레이드 호환성 → 의사결정 트리 → 흔히 빠뜨리는 함정 순서로 둘의 차이를 정리한 메모입니다. 양쪽 다 익숙한 개발자가 신입에게 한 번에 설명해 줄 때 보여줄 만한 표를 한 화면에 모았습니다.
핵심 — 한눈 비교 표
| 항목 | BDC | BAPI |
|---|---|---|
| 동작 방식 | 화면 흐름을 따라가며 키 입력 시뮬레이션 | 함수 모듈 호출 — DB 직접 업데이트 |
| 대상 트랜잭션 | SAP 표준 + CBO(자체 개발 화면) 모두 | SAP 표준만 (SAP 가 제공하는 것) |
| 성능 | 상대적으로 느림 (화면 단계마다 검증) | 빠름 (DB 직접 접근) |
| 데이터 무결성 | 화면이 통과하면 사용자 입력과 동일 | SAP 가 무결성 보장 (공식 인터페이스) |
| 시스템 업그레이드 | 화면 변경 시 깨질 수 있음 | SAP 가 하위 호환 보장 |
| Custom 필드 | 화면에 있으면 그대로 입력 가능 | EXTENSIONIN 같은 확장 구조 필요 |
| 디버깅 | MODE 'A' 로 화면 보면서 가능 | RETURN 메시지 분석 / 함수 디버깅 |
| COMMIT 처리 | CALL TRANSACTION 안에서 자동 | BAPI_TRANSACTION_COMMIT 별도 호출 |
핵심 한 줄: "BAPI 가 있고 요구사항이 표준 안에 들면 BAPI / 그 외에는 BDC". 둘 중 하나만 알아두지 말고 둘 다 도구상자에 가지고 있어야 어떤 자동화 요청에도 대응 가능합니다.
1단계 — BDC 가 어떻게 동작하나
BDC 는 사용자가 SAP 화면에서 키보드와 마우스로 진행하는 과정을 그대로 흉내냅니다.
사용자 흐름:
MM01 → 자재번호 입력 → Enter → 뷰 선택 → Enter → Basic Data 1 입력 → 저장
BDC 시뮬레이션:
화면 1 (PROGRAM=SAPLMGMM DYNPRO=0060)
BDC_OKCODE = '=ENTR'
RMMG1-MATNR = 'TEST-MAT-001'
RMMG1-MBRSH = 'M'
RMMG1-MTART = 'FERT'
화면 2 (PROGRAM=SAPLMGMM DYNPRO=0070)
BDC_OKCODE = '=ENTR'
MSICHTAUSW-DYTXT(01) = 'X'
화면 3 (PROGRAM=SAPLMGMM DYNPRO=4004)
BDC_OKCODE = '=BU' (저장)
MAKT-MAKTX = '테스트 자재'
...
화면 한 단계씩 진행하므로 표준 트랜잭션이 가진 모든 검증(필수 입력 체크·고객 BAdI·SET/GET 파라미터 등) 이 그대로 흐릅니다. 사용자가 손으로 진행한 것과 100% 같은 결과가 나와 회사 특화 검증이 들어간 트랜잭션도 그대로 자동화 가능. 다만 화면 자체에 강하게 의존하므로 SAP 패치로 화면 구조가 바뀌면 BDC 가 깨집니다.
2단계 — BAPI 가 어떻게 동작하나
BAPI 는 SAP 가 미리 만들어 둔 함수 모듈을 호출하는 방식. 화면을 거치지 않고 DB 를 직접 업데이트합니다.
" 자재마스터 생성 BAPI 예시
DATA: ls_head TYPE bapimathead,
ls_clientd TYPE bapi_mara,
ls_clientx TYPE bapi_marax,
ls_return TYPE bapiret2.
ls_head-material = 'TEST-MAT-001'.
ls_head-ind_sector = 'M'.
ls_head-matl_type = 'FERT'.
ls_head-basic_view = 'X'.
ls_clientd-base_uom = 'EA'.
ls_clientd-matl_group = '001'.
ls_clientx-base_uom = 'X'.
ls_clientx-matl_group = 'X'.
CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA'
EXPORTING
headdata = ls_head
clientdata = ls_clientd
clientdatax = ls_clientx
IMPORTING
return = ls_return.
" SAP 표준 BAPI 는 별도 COMMIT 필요
IF ls_return-type NA 'EA'.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING wait = 'X'.
ELSE.
CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
ENDIF.
BAPI 는 SAP 가 공식으로 제공하는 인터페이스라 SAP 가 직접 책임집니다. 데이터 무결성 보장·시스템 업그레이드 호환성·릴리즈 가이드 모두 SAP 가 관리. 다만 BAPI 가 검증해 주는 범위는 SAP 가 표준으로 정의한 영역에 한정되므로, 회사가 추가한 화면 검증 로직(BAdI · User-Exit) 은 안 흐를 수 있습니다.
3단계 — 성능 비교
대량 처리에서 BAPI 가 훨씬 빠릅니다. 화면을 거치지 않으니 화면 그리기·검증 라운드트립이 없습니다.
| 시나리오 | BDC (참고) | BAPI (참고) |
|---|---|---|
| 자재마스터 1만 건 생성 | 수 시간 (환경에 따라) | 수십 분 |
| PO 100 건 생성 | ~10 분 | ~1~2 분 |
| 단건 생성 | 차이 미미 | 차이 미미 |
표의 수치는 시스템 부하·인덱스·DB 상황에 따라 크게 달라지므로 절대값이 아니라 "BAPI 가 명백히 빠르다" 의 상대 비교로만 봐 주세요. 단건 자동화는 사람이 체감할 만한 차이가 없지만, 마이그레이션이나 대량 업로드 같은 케이스는 BAPI 가 운영 시간을 크게 줄여줍니다.
4단계 — Custom 필드 / Custom 화면 대응
회사가 자재마스터에 자체 필드(예: ZZ_MAT_GRADE) 를 추가했다면 둘의 대응 방식이 갈립니다.
" 케이스 A: BDC — Custom 필드도 화면에 있으면 자동 입력 가능
PERFORM bdc_field USING 'MARA-ZZ_MAT_GRADE' 'A+'.
" → 화면이 그 필드를 가지고 있으면 정상 입력" 케이스 B: BAPI — EXTENSIONIN 같은 확장 구조 필요
DATA lt_ext TYPE TABLE OF bapiparex.
APPEND VALUE #( structure = 'BAPI_TE_MARA'
valuepart1 = 'TEST-MAT-001A+ ' ) TO lt_ext.
CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA'
EXPORTING headdata = ls_head ...
TABLES extensionin = lt_ext.
" → BAPI 가 EXTENSIONIN 을 받도록 IMG 에 매핑 등록되어 있어야 작동
" → 일부 BAPI 는 EXTENSIONIN 자체를 지원하지 않음회사 특화 필드가 많은 자재마스터·PO 같은 환경에서는 BDC 가 손쉬운 선택. BAPI 의 EXTENSIONIN 은 IMG 설정·매핑 등록·BAdI 구현까지 같이 가야 작동해서 셋업이 더 무겁습니다. 이 부분이 회사에서 BAPI 가 있는데도 BDC 자동화가 운영되는 가장 흔한 이유.
5단계 — 시스템 업그레이드 호환성
[ SAP EHP 또는 S/4HANA 마이그레이션 시점 ]
BDC:
→ MM01 화면의 필드 순서가 바뀜
→ 기존 BDC 가 "이 화면에 이 필드가 없다" 에러
→ BDC 코드 전체 재검토·재레코딩
BAPI:
→ SAP 가 BAPI 시그니처 하위 호환 유지
→ 코드 변경 없이 그대로 동작 (대부분의 경우)
→ 신기능은 새 BAPI 또는 추가 파라미터로 제공
SAP 가 BAPI 를 "공식 인터페이스" 로 위치 부여하면서 강하게 보장하는 부분이 호환성입니다. 단, S/4HANA 환경에서 이미 사용 중단 예고(deprecated) 된 BAPI 도 있으므로 마이그레이션 전에는 SAP Note · Simplification List 확인 필요.
의사결정 트리
자동화 요건이 들어왔을 때 BDC / BAPI 선택 흐름.
요건 분석
│
├─ 표준 BAPI 가 존재하는가? ─────────── NO ──→ BDC
│ │
│ YES
│ │
├─ BAPI 가 요구사항을 모두 충족하는가? ─ NO ──→ BAPI(EXTENSIONIN) 시도 → 안 되면 BDC
│ │
│ YES
│ │
├─ Custom 필드가 BAPI 에 매핑되어 있는가? NO ──→ BDC
│ │
│ YES
│ │
└─ 대량 처리 / 성능 중요한가? ──── YES ──→ BAPI (강력 권장)
│
NO
│
→ BAPI 우선 / BDC 도 가능일반적으로 SAP 표준 트랜잭션을 자동화한다면 BAPI 가 있는지 먼저 SE37 에서 검색 하고, 있으면 그것부터 시도. 한계가 있을 때만 BDC 로 내려가는 흐름이 가장 안전합니다.
자주 쓰이는 BAPI 예시
자주 자동화하는 표준 트랜잭션 ↔ BAPI 매핑.
| 표준 T-Code | 대응 BAPI | 용도 |
|---|---|---|
MM01 / MM02 |
BAPI_MATERIAL_SAVEDATA |
자재마스터 생성 / 변경 |
ME21N |
BAPI_PO_CREATE1 |
PO 생성 |
ME22N |
BAPI_PO_CHANGE |
PO 변경 |
VA01 |
BAPI_SALESORDER_CREATEFROMDAT2 |
영업오더 생성 |
MIGO |
BAPI_GOODSMVT_CREATE |
자재 이동 (GR / GI) |
FB01 |
BAPI_ACC_DOCUMENT_POST |
FI 전표 등록 |
XK01 / XK02 |
BAPI_VENDOR_CREATE / 변경 |
공급업체 마스터 |
이 표에 없는 트랜잭션이 BAPI 가 없는 경우가 많습니다. SE37 에서 "BAPI_*" 또는 트랜잭션 키워드로 검색해 BAPI 존재 여부 먼저 확인.
흔히 빠뜨리는 함정
BAPI 호출 후 COMMIT 누락
CALL FUNCTION 'BAPI_PO_CREATE1' ...
" ❌ BAPI_TRANSACTION_COMMIT 없음 — DB 반영 안 됨BAPI 는 자체적으로 COMMIT 안 합니다. 성공적으로 호출 후 BAPI_TRANSACTION_COMMIT 명시 호출이 필수.
BDC 가 BAPI 보다 항상 느리다고 단정
단건 처리는 사실상 차이 없거나 미미합니다. 화면 검증 로직이 비즈니스적으로 중요한 경우(예: 회사 BAdI 가 화면에 박혀 있는 트랜잭션) 는 오히려 BDC 가 안전한 선택이 될 수 있습니다.
LOOP 안 BAPI 호출 시 COMMIT 안 함
LOOP AT lt_data INTO ls_data.
CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA' ...
" ❌ LOOP 끝에 한 번만 COMMIT — 에러난 건도 같이 커밋될 위험
ENDLOOP.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.LOOP 안 BAPI 호출은 매 건마다 결과 확인 후 COMMIT 또는 ROLLBACK 결정. 에러 건 분리·재처리 가능하게 설계.
LOOP AT lt_data INTO ls_data.
CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA' ...
IF ls_return-type CA 'EA'.
CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
ELSE.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING wait = 'X'.
ENDIF.
ENDLOOP.BDC 가 BAPI 가능한 트랜잭션에 쓰임
" ❌ BAPI_PO_CREATE1 이 있는데도 ME21N BDC 작성
CALL TRANSACTION 'ME21N' USING gt_bdcdata ...표준 BAPI 가 존재하면 BAPI 가 우선. BDC 는 BAPI 가 없거나 회사 특화 필드 매핑이 불가능한 경우에만 선택.
Custom 필드 BAPI 매핑 누락
BAPI 의 EXTENSIONIN 으로 Custom 필드를 넘기려면 IMG 의 BAPI 매핑 설정 + BAdI 구현이 같이 가야 합니다. 코드만 짜놓고 매핑이 빠지면 EXTENSIONIN 데이터가 BAPI 안에서 무시됩니다.
BAPI 메시지 무시
CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA' ...
" ❌ ls_return 안 보고 다음 진행BAPI 는 에러 발생 시 SY-SUBRC 가 아닌 RETURN 테이블의 TYPE 으로 알려줍니다. TYPE = 'E' 또는 'A' 가 하나라도 있으면 실패로 간주.
BDC MODE 'A' 운영 배포
CALL TRANSACTION 'MM01' USING gt_bdcdata MODE 'A' ... " ❌ 운영 사용자 화면 떠 버림테스트 후 운영 배포 시 'N'(백그라운드) 으로 변경 잊지 않기.
요약
| 상황 | 선택 |
|---|---|
| 표준 BAPI 존재 + 요건 충족 | ✅ BAPI 우선 |
| 대량 처리 (수천 ~ 수만 건) | ✅ BAPI (성능) |
| 시스템 업그레이드 예정 | ✅ BAPI (호환성) |
| BAPI 없음 / CBO 화면 | ⚙️ BDC (유일 선택) |
| Custom 필드 BAPI 미지원 | ⚙️ BDC 또는 BAPI(EXTENSIONIN + IMG 매핑) |
| 회사 BAdI / 화면 검증 중요 | ⚙️ BDC (검증 그대로 흐름) |
BDC 와 BAPI 는 경쟁 관계가 아니라 도구상자의 다른 칸에 있는 두 도구입니다. BAPI 가 있으면 BAPI, BAPI 가 없거나 회사 특화 화면이 끼면 BDC — 이 단순한 기준만 따라가도 대부분의 자동화 요건에 맞는 도구가 자연스럽게 결정됩니다. 신입 모듈러는 둘 다 한 번씩 직접 구현해 보는 경험이 가장 빨리 익숙해지는 길이며, 익숙해진 뒤에는 BAPI 우선 + BDC 폴백 패턴으로 가는 것이 운영 안전성 면에서 추천됩니다.
Disclaimer — 이 포스트는 실무 정리 노트를 바탕으로 AI 보조로 정리되었습니다.
BDC(Batch Data Communication) · BAPI(Business Application Programming Interface) 는 SAP 표준 자동화 메커니즘으로 ECC 6.0 / S/4HANA on-premise 환경에서 동일하게 동작합니다.
BAPI_TRANSACTION_COMMIT · BAPI_TRANSACTION_ROLLBACK 은 BAPI 호출 후 명시적으로 호출해야 하며 BAPI 함수 모듈 자체는 자동 COMMIT 하지 않습니다. SAP 표준 BAPI 의 하위 호환성 보장은 SAP 의 공식 정책이지만, S/4HANA 마이그레이션 시 일부 BAPI 가 deprecated 되거나 대체 방식(RAP·OData) 으로 권고되는 경우가 있어 마이그레이션 전에는 SAP Note 와 Simplification List 확인이 필요합니다.
본문의 성능 수치 예시는 시스템 환경에 따라 크게 달라지므로 절대값이 아닌 상대 비교 참고용으로만 활용하시기 바랍니다. S/4HANA Cloud(ABAP Cloud / Steampunk) 환경에서는 BDC 사용이 제한되며 BAPI 도 Released API 만 사용 가능하므로, 클라우드 환경 자동화는 RAP(RESTful Application Programming Model) 기반 비즈니스 객체 호출이 표준 권장 방식입니다.
