바로투입이력카드
SAP 게시판

교육·자격증공부 방법

SAP 시스템 구조와 ABAP 이해하기 — ABAP 입문 1장 ②

에이든ABAP 개발자운영자모듈 MMSD기타조회 13

앞선 1편에서는 회사가 왜 SAP를 쓰고, 구매·입고 데이터가 SE11(테이블 구조)과 SE16(데이터 조회) 화면에서 어떻게 연결되는지 살펴보았습니다.

이번 2편에서는 "SAP 시스템은 내부적으로 어떻게 생겼고, 내가 만드는 ABAP 프로그램은 어디서 어떻게 실행되는지"를 실제 SAP 화면과 함께 알아봅니다. 일반 웹·앱 프로그래밍과 달리 SAP는 코드를 내 PC에 저장하지 않고 서버에서 바로 작성·실행하며, 클라이언트(MANDT)와 트랜스포트(SE09 이관)라는 고유한 운영 방식을 씁니다.

이번 글에서 배울 내용과 진행 순서

이번 2편에서는 아래 네 단계를 실제 화면 샘플과 함께 차례대로 배웁니다.

  1. 1단계 — SAP의 3층 구조(3-Tier)와 내 서버 정보(System → Status) 확인하기: 내 PC 화면(SAP GUI), 애플리케이션 서버, 데이터베이스가 어떻게 역할을 나누는지 알아보고, System → Status 화면에서 서버 이름(SID)과 ABAP 버전을 직접 확인합니다.

  2. 2단계 — 클라이언트(MANDT)와 T000 테이블 확인하기: 로그인할 때 적는 세 자리 숫자(001, 100 등)가 무엇인지, 왜 데이터는 클라이언트마다 따로 있고 프로그램은 서버 전체에 하나만 있는지 SE16 화면으로 확인합니다.

  3. 3단계 — 개발(DEV)·품질(QAS)·운영(PRD) 서버와 SE09 트랜스포트 화면 보기: 왜 회사는 서버를 세 대로 나누어 쓰고, 개발한 프로그램을 SE09에서 어떤 절차로 포장해 운영 서버로 옮기는지 살펴봅니다.

  4. 4단계 — ABAP 6가지 개발 영역(RICEFW)과 실제 리포트 실행 화면 · 코드 보기: 현업에서 말하는 RICEFW가 무엇인지 알고, 1편의 구매·입고 데이터를 화면에 띄워 주는 ZEDU_PO_LIST 리포트의 선택 화면 → SALV 결과 표 → SE38 소스 코드 화면을 순서대로 읽어 봅니다.


1단계: SAP 시스템의 3층 구조(3-Tier)와 서버 정보 확인하기

화면 · 애플리케이션 서버 · 데이터베이스의 역할 분담

SAP 시스템은 크게 세 개의 층(3-Tier Architecture)으로 나뉘어 돌아갑니다.

┌────────────────────────────────────────────────────────┐
│ 1. 프레젠테이션 층 (Presentation Tier)                   │
│    - 사용자 PC의 SAP GUI 또는 웹 브라우저(SAP Fiori)      │
│    - 화면을 그려 주고 키보드·마우스 입력만 서버로 전달     │
└───────────────────────────┬────────────────────────────┘
                            │ 네트워크 통신
┌───────────────────────────▼────────────────────────────┐
│ 2. 애플리케이션 층 (Application Tier)                    │
│    - ABAP 프로그램이 실제로 저장되고 실행되는 서버        │
│    - 업무 로직 처리, 권한 검사, 화면 구성                  │
└───────────────────────────┬────────────────────────────┘
                            │ SQL 조회·저장 (Open SQL)
┌───────────────────────────▼────────────────────────────┐
│ 3. 데이터베이스 층 (Database Tier)                       │
│    - 모든 업무 테이블과 개발 객체가 저장되는 금고          │
│    - SAP HANA, Oracle 등의 관계형 데이터베이스            │
└────────────────────────────────────────────────────────┘

각 층이 하는 일을 개발자 관점에서 풀어서 보면 이렇습니다.

  • 프레젠테이션 층 (화면): 내 PC에 설치한 SAP GUI입니다. 이곳은 서버가 보내 준 화면을 보여 주고 내가 누른 키(Enter, F8 등)를 서버로 전달하는 창구 역할만 합니다. 내가 작성한 ABAP 코드는 내 PC에서 실행되지 않습니다.

  • 애플리케이션 층 (두뇌): ABAP 프로그램이 실제로 실행되는 서버입니다. 서버 안에는 사용자의 요청을 순서대로 배분하는 디스패처(Dispatcher)와 실제로 ABAP 코드를 한 줄씩 실행하는 여러 개의 작업 프로세스(Work Process)가 돌아가고 있습니다.

  • 데이터베이스 층 (금고): 모든 테이블과 데이터가 저장된 곳입니다. ABAP 개발자는 데이터베이스에 별도로 직접 접속하지 않고, ABAP 코드 안에 SELECT 문(Open SQL)을 적어 애플리케이션 서버가 DB에서 데이터를 가져오도록 명령합니다.

개발자가 꼭 기억해야 할 성능 원칙

프로그램이 느려지는 가장 흔한 원인은 애플리케이션 서버와 데이터베이스 사이에서 **불필요하게 많은 데이터를 한꺼번에 읽거나(SELECT *), 반복문(LOOP) 안에서 DB를 수천 번씩 호출하는 것**입니다. 그래서 실무에서는 *"꼭 필요한 열과 행만 한 번에 묶어서 읽는다"*는 원칙을 가장 중요하게 여깁니다.

샘플 화면으로 보기: System → Status에서 SID와 ABAP 버전 확인하기

회사에는 여러 대의 SAP 서버가 있기 때문에 각 서버마다 세 글자 영문·숫자 이름인 시스템 ID(SID, 예: DEV, QAS, PRD, A4H)와 두 자리 인스턴스 번호(예: 00)를 붙여 구분합니다.

내가 지금 어느 서버, 어느 데이터베이스에 접속해 있고 어떤 버전의 ABAP 문법을 쓸 수 있는지는 SAP GUI 상단 메뉴 System → Status...를 누르면 즉시 확인할 수 있습니다.

그림 1-1. 상단 메뉴 System → Status를 눌러 접속 클라이언트(001), 서버 이름, DB(HDB), SAP_BASIS 버전을 확인하는 화면.
그림 1-1. 상단 메뉴 System → Status를 눌러 접속 클라이언트(001), 서버 이름, DB(HDB), SAP_BASIS 버전을 확인하는 화면.

화면의 번호 표시(① ~ ③)를 순서대로 따라가 보세요.

  • ① Client · User: 현재 내가 로그인한 클라이언트 번호(001)와 사용자 아이디(DEVELOPER)입니다. 오른쪽 Program (screen) 칸에는 방금 내가 보고 있던 프로그램 이름(ZEDU_PO_LIST)이 함께 표시됩니다.

  • ② Server Name · Database System:

- Server Name에 적힌 vhcala4hci_A4H_00에서 가운데 세 글자 A4H가 이 서버의 SID이고, 끝의 두 자리 00이 인스턴스 번호입니다. - 아래 Database data 구역의 Database System에 적힌 HDB는 이 서버가 SAP HANA 데이터베이스를 쓰고 있다는 뜻입니다.

  • ③ Product Version 돋보기 버튼과 SAP_BASIS 릴리스:

- Product Version 오른쪽의 돋보기 아이콘(Component information)을 누르면 오른쪽 아래 Installed Software 창이 열립니다. - 여기서 SAP_BASIS 줄의 Release(816)가 바로 이 서버에서 사용할 수 있는 ABAP 문법 버전을 나타냅니다(예: 740 이상이면 DATA(...) 인라인 선언 등 모던 문법 사용 가능).


2단계: 클라이언트(MANDT) — 한 서버 안의 독립된 회사 공간

로그인할 때 입력하는 세 자리 숫자 001, 100의 정체

SAP 로그인 화면을 열면 아이디와 비밀번호 위에 Client(클라이언트)라는 세 자리 숫자 칸(예: 001, 100, 200)이 있습니다.

클라이언트(Client)는 하나의 SAP 서버 안에 만들어 둔 독립된 회사(또는 데이터) 공간입니다. 아파트 한 동(SAP 서버 1대) 안에 101호, 102호(클라이언트 100, 200)가 나뉘어 있어서 각 집마다 살림살이와 출입문 열쇠가 따로 있는 모습을 떠올리면 쉽습니다.

  • 클라이언트마다 사용자 계정(ID/비밀번호), 업무 데이터(구매오더·회계 전표), 업무 설정(Customizing)이 완전히 분리되어 있습니다. 따라서 100번 클라이언트에 만든 아이디로는 200번 클라이언트에 로그인할 수 없습니다.

  • 물리적으로는 같은 데이터베이스 테이블을 함께 쓰지만, 테이블의 맨 첫 번째 열에 MANDT(클라이언트 번호)라는 필드를 두어 데이터를 구분합니다.

예를 들어 구매오더 테이블(ZEDU_POH) 안에 데이터가 아래처럼 들어 있다고 해 보겠습니다.

  • MANDT: 001 · 구매오더(EBELN): 4500000001 · 거래처: 한빛금속

  • MANDT: 001 · 구매오더(EBELN): 4500000002 · 거래처: 대성철강

  • MANDT: 100 · 구매오더(EBELN): 4500000001 · 거래처: (클라이언트 100의 전혀 다른 거래처)

내가 클라이언트 001로 로그인해서 조회하면 SAP는 자동으로 MANDT = '001'인 데이터만 보여 주고 100번 데이터는 숨깁니다. 실제로 SE16에서 서버의 클라이언트 목록 테이블인 T000을 조회해 보면, 맨 앞 열 MANDT로 각 클라이언트가 나뉘어 있는 것을 볼 수 있습니다.

그림 1-2. SE16에서 조회한 클라이언트 목록 테이블(T000). 맨 앞 열 MANDT 값(000, 001)으로 각 클라이언트 공간이 구분됩니다.
그림 1-2. SE16에서 조회한 클라이언트 목록 테이블(T000). 맨 앞 열 MANDT 값(000, 001)으로 각 클라이언트 공간이 구분됩니다.

초보자가 가장 헷갈리는 핵심: 클라이언트 종속 vs 클라이언트 독립

그렇다면 *"클라이언트가 다르면 ABAP 프로그램도 클라이언트마다 따로 만들어야 하나요?"*라는 궁금증이 생깁니다. 정답은 "아니요, 프로그램은 한 번만 만듭니다"입니다.

SAP 안의 모든 것은 아래 두 가지로 나뉩니다.

  1. 클라이언트 종속 (Client-dependent) — 방마다 따로 있는 것

- 대상: 구매오더·재고·회계 전표 같은 업무 데이터, 사용자 계정, 대부분의 업무 설정 - 구분 방법: 1편의 SE11 화면(그림 1-3)에서 보았듯 첫 번째 키 필드가 MANDT(데이터 타입 CLNT)로 시작하면 클라이언트 종속 테이블입니다.

  1. 클라이언트 독립 (Client-independent / Cross-client) — 서버 전체에 하나만 있는 것

- 대상: ABAP 프로그램 코드, 테이블의 구조 정의(열 구성), 함수 모듈, 클래스 같은 모든 개발 객체 - 구분 방법: 테이블의 첫 번째 키 필드에 MANDT가 없으면 시스템 전체가 공유하는 클라이언트 독립 테이블입니다(3편에서 볼 개발 객체 목차 테이블 TADIR가 대표적입니다).

이 구조 덕분에 개발자는 개발용 클라이언트(예: 100)에서 프로그램을 딱 한 번만 작성하면 됩니다. 테스트용 클라이언트(예: 110)에 로그인해서 그 프로그램을 실행하면, 프로그램 코드는 그대로 쓰되 데이터만 110번 클라이언트의 데이터를 자동으로 읽어 옵니다.

ABAP에서 SELECT 문을 작성할 때도 WHERE MANDT = '001' 같은 조건은 직접 적지 않습니다. SAP가 현재 로그인한 클라이언트를 자동으로 조건에 붙여 주기 때문입니다.

" WHERE 조건에 MANDT(클라이언트 번호)를 적지 않아도
" 현재 로그인한 클라이언트의 데이터만 안전하게 읽어 옵니다.
WHERE h~ebeln  IN @s_ebeln
  AND h~lifnr  IN @s_lifnr
  AND h~bedat  IN @s_bedat

3단계: 개발(DEV) · 품질(QAS) · 운영(PRD) 서버와 SE09 트랜스포트

왜 서버를 세 대로 나누어 쓸까요?

실제 회사에서는 SAP 서버 한 대에서 개발과 실제 업무를 함께 처리하지 않습니다. 보통 역할에 따라 최소 세 대의 독립된 서버를 두며, 이 서버 구성을 시스템 랜드스케이프(System Landscape)라고 부릅니다.

  1. 개발 서버 (DEV, Development): ABAP 개발자가 프로그램을 새로 만들거나 수정하고, 컨설턴트가 설정을 바꾸며 기본적인 단위 테스트를 하는 서버입니다.

  2. 품질 검증 서버 (QAS / QA, Quality Assurance): 실제 운영 환경과 비슷한 대량 데이터를 넣어 두고, 운영 서버에 반영하기 전에 컨설턴트와 현업 담당자가 통합 테스트를 진행하는 서버입니다.

  3. 운영 서버 (PRD, Production): 전사 임직원이 매일 실제 구매·생산·회계 업무를 처리하는 서버입니다. 운영 서버에서는 절대 프로그램을 직접 만들거나 수정하지 않습니다.

샘플 화면으로 보기: SE09 트랜스포트(Transport Request) 이관 상자

개발 서버(DEV)에서 다 만든 프로그램을 품질 서버(QAS)와 운영 서버(PRD)로 옮길 때 사용하는 공식 이관 도구가 트랜스포트(Transport)이며, 개발자는 SE09(또는 SE10, Transport Organizer) 화면에서 이 이관 상자를 관리합니다.

그림 1-3. SE09(Transport Organizer)에서 트랜스포트 요청(TR)을 조회하고 이관 대상 객체를 확인하는 화면.
그림 1-3. SE09(Transport Organizer)에서 트랜스포트 요청(TR)을 조회하고 이관 대상 객체를 확인하는 화면.

화면의 번호 표시(① ~ ③)를 따라가며 이관 절차를 확인해 보세요.

  • ① SE09 첫 화면(왼쪽): 내 아이디(DEVELOPER)로 작업 중인 요청(Modifiable)이나 이미 봉인된 요청(Released)을 선택하고 Display(조회) 버튼을 누릅니다.

- 개발 객체(프로그램·테이블 구조) 변경은 Workbench Requests에 담기고, 컨설턴트의 업무 설정 변경은 Customizing Requests에 담깁니다.

  • ② 트랜스포트 요청(TR) 번호와 객체 목록(오른쪽):

- 상자 번호 A4HK900012(서버SID + K + 6자리 번호) 아래에 작업 단위인 Task(A4HK900013)가 있고, 그 안에 내가 만들고 수정한 테이블(ZEDU_POH), 프로그램(ZEDU_PO_LIST), 메시지 클래스(ZEDU_MSG)가 빠짐없이 기록되어 있습니다.

  • ③ 트럭 아이콘 Release Directly(F9)로 상자 봉인하기:

- 개발과 단위 테스트가 끝나면 상단 툴바의 트럭 모양 아이콘(Release Directly, F9)을 눌러 Task와 TR 상자를 순서대로 해제(Release, 봉인 완료)합니다. - 봉인이 끝나면 Basis 담당자가 STMS 화면에서 이 상자를 품질 서버(QAS)로 반입(Import)하고, 현업 검증이 끝나면 최종적으로 운영 서버(PRD)에 반영합니다.


4단계: ABAP이 하는 6가지 일(RICEFW)과 실제 리포트 화면 · 코드 보기

현업에서 부르는 6가지 개발 영역: RICEFW

프로젝트 현장에 가면 개발할 프로그램 목록을 RICEFW(또는 오브젝트 목록)라고 부르며 6가지 종류로 분류합니다.

  • R — Report (리포트): 데이터베이스에서 업무 데이터를 조회·가공해 화면 표(ALV)로 보여 주는 프로그램입니다. (예: 구매오더 대비 입고·미입고 현황 조회). 신입 ABAP 개발자가 가장 먼저 배우고 실무에서 가장 많이 개발하는 핵심 영역입니다.

  • I — Interface (인터페이스): SAP와 외부 시스템(쇼핑몰, 물류 창고 시스템, 은행, 그룹웨어 등) 사이에 데이터를 주고받는 연결 프로그램입니다(RFC, BAPI, IDoc, REST API 등 활용).

  • C — Conversion (컨버전 / 데이터 이관): 처음 SAP를 도입할 때 기존 시스템이나 엑셀에 있던 자재·거래처·회계 잔액 데이터를 SAP로 일괄 등록하는 프로그램입니다(BDC, BAPI 등 활용).

  • E — Enhancement (확장): SAP 표준 프로그램의 원본 코드는 건드리지 않고, SAP가 미리 마련해 둔 갈고리 지점(User Exit, BAdI, Enhancement Spot)에 우리 회사만의 검증 규칙이나 자동 계산 로직을 끼워 넣는 개발입니다.

  • F — Form (출력 양식): 구매발주서, 거래명세서, 납품서처럼 인쇄하거나 PDF로 내보내는 문서 양식을 만드는 작업입니다(Smart Forms, Adobe Forms 등).

  • W — Workflow (워크플로): 전표 승인이나 발주 결재가 정해진 결재선을 따라 자동으로 흘러가도록 만드는 작업입니다.

샘플 화면으로 보기 ①: 리포트(ZEDU_PO_LIST)를 실행했을 때 나오는 선택 화면

그렇다면 신입 개발자가 가장 많이 만드는 Report(조회 프로그램)는 실제로 어떻게 생겼을까요? 1편에서 살펴본 구매오더·품목·입고 테이블을 합쳐서 보여 주는 ZEDU_PO_LIST 프로그램을 SE38에서 실행(F8)하면, 가장 먼저 아래의 선택 화면(Selection Screen)이 나타납니다.

그림 1-4. 구매오더 현황 리포트(ZEDU_PO_LIST)를 실행했을 때 먼저 나타나는 조회 조건 입력 화면(Selection Screen).
그림 1-4. 구매오더 현황 리포트(ZEDU_PO_LIST)를 실행했을 때 먼저 나타나는 조회 조건 입력 화면(Selection Screen).
  • ① 조회 조건 입력칸(조회 조건 블록): 사용자가 보고 싶은 구매오더 번호 범위(4500000001 ~ 4500000010), 거래처, 구매조직(1000), 발주일 기간을 넣는 화면입니다. 웹 개발처럼 HTML/CSS를 짤 필요 없이 ABAP 선언문 몇 줄이면 자동으로 그려집니다.

  • ② Execute(F8) 버튼: 조건을 입력한 뒤 왼쪽 위 시계 아이콘(F8)을 누르면 서버가 데이터베이스에서 조건에 맞는 데이터를 읽어 옵니다.

샘플 화면으로 보기 ②: 실행 결과로 출력되는 SALV 그리드 표 화면

선택 화면에서 F8을 누르면 곧바로 아래와 같은 SALV 그리드(Grid) 결과 화면이 열립니다.

그림 1-5. 조회 조건 입력 후 F8을 눌렀을 때 출력되는 구매오더 현황 SALV 그리드 결과 화면.
그림 1-5. 조회 조건 입력 후 F8을 눌렀을 때 출력되는 구매오더 현황 SALV 그리드 결과 화면.
  • ① SALV 표준 도구 모음: 개발자가 별도로 코딩하지 않아도 정렬, 필터, 합계(Σ), 엑셀 파일 내보내기 버튼이 상단에 기본으로 붙습니다.

  • ② 3개 테이블 조인 및 미입고 수량 계산 결과: 1편의 SE16에서 따로따로 보았던 헤더(ZEDU_POH), 품목(ZEDU_POI), 입고(ZEDU_GR) 데이터가 한 줄로 합쳐져 발주수량 · 입고수량 · 미입고수량 · 입고상태(입고완료 / 일부입고 / 미입고)를 한눈에 비교해 줍니다.

  • ③ 통화 참조가 적용된 원화 금액(NETWR): 8,950,000 KRW, 13,800,000 KRW처럼 통화 키(WAERS)에 맞춰 금액이 정확하게 표시됩니다.

샘플 화면으로 보기 ③: 이 리포트를 움직이는 SE38 ABAP 소스 코드

방금 본 선택 화면(그림 1-4)과 결과 표(그림 1-5)를 만든 실제 ABAP 코드는 어떻게 생겼을까요? SE38에서 ZEDU_PO_LIST의 소스 코드를 열어 보면 전체 구조가 놀라울 만큼 단순합니다.

그림 1-6. SE38 편집기에서 연 ZEDU_PO_LIST 프로그램의 실제 ABAP 소스 코드 화면.
그림 1-6. SE38 편집기에서 연 ZEDU_PO_LIST 프로그램의 실제 ABAP 소스 코드 화면.

화면의 세 구간(① ~ ③)을 위에서 아래로 천천히 읽어 보세요.

  1. ① 상단 편집기 툴바: 코드를 고친 뒤 문법을 검사(Ctrl+F2)하고, 성냥개비 모양의 활성화(Activate, Ctrl+F3)를 누른 뒤, 바로 옆 F8 아이콘으로 실행해 볼 수 있습니다.

  2. ② 선택 화면 선언부(25~33행, SELECT-OPTIONS · PARAMETERS):

- SELECT-OPTIONS: s_ebeln FOR gs_poh-ebeln처럼 적어 준 다섯 줄이 바로 그림 1-4에서 본 ~부터 ~까지 범위 입력칸을 자동으로 만들어 줍니다.

  1. ③ 본문 실행 구간(39~48행, START-OF-SELECTION): 사용자가 조건을 넣고 F8을 누르면 여기서부터 위에서 아래로 차례대로 실행됩니다.

- PERFORM check_authority ...: 먼저 이 사용자가 데이터를 볼 권한이 있는지 검사하고, 권한이 없으면 멈춥니다(RETURN). - PERFORM get_data.: 데이터베이스에서 조건에 맞는 구매오더와 입고 내역을 읽어 옵니다(SELECT). - PERFORM set_data.: 발주 수량에서 입고 수량을 빼서 미입고 수량과 입고 상태를 계산합니다. - PERFORM display_salv.: 완성된 표를 SAP 표준 그리드 도구(CL_SALV_TABLE)에 넘겨 그림 1-5 화면을 띄웁니다.

이처럼 "① 권한 확인 → ② 데이터 조회 → ③ 데이터 가공 → ④ 화면 출력" 네 단계가 실무 ABAP 조회 리포트의 변치 않는 기본 뼈대입니다.


핵심 정리 및 다음 편 안내

이번 ABAP 입문 1장 ②에서 배운 핵심을 정리해 보겠습니다.

  • 3-Tier 구조와 System → Status: SAP는 화면(SAP GUI) · 애플리케이션 서버(ABAP 실행) · 데이터베이스(테이블 저장) 세 층으로 나뉘며, System → Status에서 서버의 SID(A4H), DB 종류(HDB), SAP_BASIS 버전(816)을 확인합니다.

  • 클라이언트(MANDT)와 T000: 한 서버 안의 독립된 회사 데이터 공간입니다. 업무 데이터는 클라이언트마다 따로(종속) 있지만, ABAP 프로그램과 테이블 구조는 서버 전체에 하나만(독립) 존재합니다.

  • DEV → QAS → PRD와 SE09 트랜스포트: 안전한 운영을 위해 개발·품질·운영 서버를 나누어 쓰며, 개발 서버에서 만든 변경 사항은 SE09에서 트랜스포트 요청(TR) 상자에 담아 봉인(Release)한 뒤 순서대로 이관합니다.

  • RICEFW와 리포트 실행 흐름: 가장 기본이 되는 리포트(Report)는 선택 화면 입력(SELECT-OPTIONS) → F8 실행(START-OF-SELECTION: 권한 확인 → 조회 → 가공 → 출력) → SALV 그리드 표 순서로 동작합니다.

다음 편(ABAP 입문 1장 ③)에서는 무엇을 배우나요? 1장의 마지막 편인 「SAP 개발 객체와 ABAP 학습 지도」에서는 SE93(T-code 연결 화면), SE38 프로그램 속성(Attributes) 화면, SE80 패키지 트리, SE16·SE11로 보는 TADIR(개발 객체 목차 테이블) 화면을 통해 왜 프로그램 이름을 항상 Z로 시작하고 연습은 $TMP 패키지에 해야 하는지, 그리고 초보자를 위한 5단계 학습 로드맵과 미니 퀴즈를 다룹니다.

출처와 이용 안내
  • 이 글은 SAP와 ABAP 입문자를 위해 직접 작성한 「따라하며 배우는 SAP ABAP 입문」 연재 자료입니다.

  • 본문의 화면 캡처(SE16의 T000 조회)와 샘플 화면(System → Status, SE09, ZEDU_PO_LIST 선택 화면·SALV 결과·SE38 소스 코드)은 ABAP 실습 환경(A4H, SAP_BASIS 816, 클라이언트 001)에서 직접 실행해 확인한 결과와 로그를 바탕으로 제작했습니다. [SYSTEM CHECK]

  • 참고 자료: SAP Learning (*Discussing the SAP Three-Tier Client Server Architecture*, *Defining the ABAP Platform Landscape*, *Introducing the Concept of Clients*), SAP Help Portal (*ABAP Programming*). RICEFW 분류와 클라이언트 종속 첫 키 필드 관례는 현업 표준 용어를 기준으로 설명했습니다. [미확인]

  • 회사마다 시스템 구성(클라이언트 번호, 이관 절차)이 다를 수 있으므로 실무에서는 소속 프로젝트의 안내를 먼저 확인해 주세요.

  • SAP와 SAP 제품명은 SAP SE의 상표이며, 바로투입은 SAP와 관련이 없습니다.

댓글 0

아직 댓글이 없어요.

교육·자격증 목록전체 목록