ABAP로 개발을 마쳤다면 다음 관문은 배포입니다. 그런데 SAP의 배포는 일반적인 개발과 사뭇 다릅니다. 파일을 서버에 올리는 방식이 아니라, 트랜스포트(Transport) 라는 SAP 고유의 이관 체계를 통해서만 코드가 운영으로 갈 수 있습니다. 처음 SAP를 접했을 때 가장 낯설었던 부분이기도 해서, 이 글에서 트랜스포트의 개념부터 실제 배포 절차까지 단계별로 정리합니다.
1. 먼저 이해할 것: SAP의 3-시스템 구조
SAP 프로젝트는 보통 세 개의 시스템으로 운영됩니다.
| 시스템 | 역할 |
|---|---|
| DEV (개발) | 개발자가 코드를 작성하는 곳. 모든 변경은 여기서만 발생 |
| QAS (품질/테스트) | 이관받아 테스트하는 곳 |
| PRD (운영) | 실제 업무가 돌아가는 곳 |
핵심 원칙은 “운영에서는 절대 직접 수정하지 않는다” 입니다. 모든 변경은 DEV에서 만들어져 QAS를 거쳐 PRD로 “이동”합니다. 이 이동을 관리하는 체계가 CTS(Change and Transport System) 이고, 이동의 단위가 트랜스포트 요청(Transport Request, 줄여서 TR 또는 CTS라고 부릅니다) 입니다.
일반 개발에 비유하면 Git의 브랜치 머지 + 배포 파이프라인이 하나로 합쳐진 것과 비슷한데, 차이점은 소스 파일이 아니라 “오브젝트(프로그램, 테이블, CDS 뷰 등)” 단위로 움직인다는 것입니다.
2. 배포의 전체 흐름 요약
전체 그림을 먼저 보면 이렇습니다.
- DEV에서 오브젝트 생성/수정 → 저장 시 TR에 자동 기록
- 개발 완료 → 태스크(Task) 릴리스
- TR(요청) 릴리스 → 이 순간 변경분이 파일로 추출됨
- QAS에서 임포트(STMS) → 테스트
- PRD에서 임포트 → 배포 완료
이제 각 단계를 자세히 봅니다.
3. 1단계: 트랜스포트 요청(TR) 생성
DEV에서 오브젝트를 새로 만들거나 수정하고 저장하면, 패키지가 이관 대상(Z 패키지 등)인 경우 TR을 지정하라는 팝업이 자동으로 뜹니다.
- 새 요청 생성(Create Request): 설명(Description)을 입력해 새 TR을 만듭니다. 설명은 나중에 운영 반영 이력이 되므로 규칙을 정해 쓰는 것이 좋습니다. 예:
[FI] 전표 인터페이스 오류 수정 (요청번호/날짜) - 기존 요청 선택(Own Requests): 진행 중인 TR이 있으면 거기에 담습니다.
이때 TR의 종류를 구분해야 합니다.
| 종류 | 용도 |
|---|---|
| Workbench Request | 프로그램, 테이블, CDS 등 개발 오브젝트 (클라이언트 무관) |
| Customizing Request | IMG 설정 변경 (클라이언트 종속) |
| Local Object ($TMP) | 이관하지 않는 개인 연습용 — TR이 생성되지 않음 |
주의: 연습용으로 Local Object($TMP)로 만든 오브젝트는 나중에 이관이 필요해지면 패키지를 변경(SE03 등)해서 TR에 담아야 합니다. 처음부터 용도에 맞는 패키지를 고르는 것이 낫습니다.
TR은 계층 구조입니다. 요청(Request) 아래에 개발자별 태스크(Task) 가 달리고, 실제 오브젝트는 태스크에 기록됩니다. 여러 개발자가 한 요청을 공유하며 각자의 태스크에 작업하는 구조입니다.
4. 2단계: 내 TR 확인하기 (SE09/SE10)
트랜잭션 SE09 또는 SE10을 실행하면 내 트랜스포트 목록이 보입니다 (둘은 사실상 같은 화면입니다).
- Modifiable(수정 가능): 아직 작업 중인 요청
- Released(릴리스됨): 이미 추출 완료된 요청
요청을 펼치면 태스크와 그 안의 오브젝트 목록이 보입니다. 배포 전에 여기서 의도한 오브젝트만 담겨 있는지 반드시 확인하세요. 엉뚱한 오브젝트가 섞여 나가는 사고가 의외로 흔합니다.
5. 3단계: 릴리스 (Release)
개발과 단위테스트가 끝나면 릴리스합니다. 릴리스는 “이 변경분을 확정해서 이관 파일로 추출한다”는 의미이며, 한 번 릴리스하면 되돌릴 수 없습니다.
- SE09/SE10에서 내 요청 펼치기
- 태스크를 먼저 선택 → 릴리스 버튼(트럭 아이콘) — 하위 태스크가 모두 릴리스되어야 요청을 릴리스할 수 있습니다
- 요청(상위) 선택 → 릴리스 — 이 순간 변경분이 트랜스포트 디렉토리에 데이터 파일(R…)과 코파일(K…)로 추출되고, 대상 시스템(QAS)의 임포트 큐에 등록됩니다
릴리스 전 체크리스트:
- 오브젝트가 모두 활성화(Activated) 상태인가 (비활성 오브젝트는 이관 후 오류의 주범)
- 다른 TR에 잠겨 있는(Locked) 오브젝트는 없는가 — 같은 오브젝트가 다른 미릴리스 TR에 잠겨 있으면 릴리스가 안 됩니다. 이 경우 그 TR을 먼저 릴리스하거나 잠금을 조정해야 합니다
- 문법 오류/신텍스 체크 완료했는가
6. 4단계: QAS 임포트 (STMS)
릴리스된 TR을 QAS로 들여오는 작업입니다. 조직에 따라 개발자가 직접 하기도 하고, Basis 담당자나 이관 담당자가 수행하기도 합니다 (운영 임포트는 대부분 권한이 통제됩니다).
- QAS 시스템에서 트랜잭션 STMS 실행
- Import Overview(임포트 개요) → QAS의 임포트 큐(Import Queue) 열기
- 대기 중인 TR 목록에서 내 요청 확인 (안 보이면 새로고침 또는 “Adjust Import Queue”)
- 해당 TR 선택 → 임포트(트럭 아이콘) → 대상 클라이언트, 실행 옵션(즉시/예약) 지정 → 실행
- 완료 후 리턴 코드(RC) 확인:
| RC | 의미 |
|---|---|
| 0 | 성공 |
| 4 | 경고 (대부분 진행 가능하지만 로그 확인 필요) |
| 8 | 오류 (오브젝트 이관 실패 — 원인 분석 필수) |
| 12 이상 | 심각한 오류 (임포트 자체 실패) |
RC=8이 나면 로그에서 어떤 오브젝트가 실패했는지 확인합니다. 흔한 원인은 의존 오브젝트 누락(예: 프로그램은 갔는데 참조하는 테이블/구조가 안 감), 이관 순서 꼬임, 대상 시스템에만 있는 수정과의 충돌입니다.
7. 5단계: 테스트 후 PRD 임포트
QAS에서 테스트가 완료되면 같은 방식으로 PRD 임포트 큐에서 임포트합니다. 운영 반영에서 특히 중요한 것들:
- 이관 순서: 여러 TR이 있으면 릴리스된 순서대로 반영해야 합니다. 뒤 TR이 앞 TR의 변경을 전제로 하는 경우, 순서가 바뀌면 옛 버전이 최신을 덮는 사고가 납니다.
- 의존성 세트로 반영: 딕셔너리(테이블/구조) TR과 프로그램 TR이 나뉘어 있다면 딕셔너리부터 반영합니다.
- 반영 시점: 사용자가 사용 중인 프로그램을 반영하면 실행 중 덤프가 날 수 있어, 업무 영향이 있는 변경은 사용 시간 외 반영이 원칙입니다.
- 반영 후 확인: PRD에서 버전 관리(프로그램 → Utilities → Versions)로 최신 버전이 반영됐는지, 대상 오브젝트가 활성 상태인지 확인합니다.
8. 알아두면 좋은 것들
- 긴급 수정(핫픽스): 운영 장애 대응도 원칙은 같습니다. DEV에서 수정 → 별도 TR로 빠르게 릴리스 → QAS 검증(간소화하더라도 생략은 비권장) → PRD 반영. 운영 직접 수정은 시스템 설정상 막혀 있는 것이 정상입니다.
- 버전 비교: 시스템 간 소스가 다른지 확인할 때는 프로그램의 버전 관리에서 원격 비교(Remote Comparison)를 쓰면 DEV/QAS/PRD 소스를 직접 비교할 수 있습니다.
- SE01/SE03: SE01은 트랜스포트 조직자의 확장 화면, SE03은 오브젝트의 패키지 변경·잠금 조회 같은 관리 도구 모음입니다. TR 관련 문제 해결 시 자주 쓰게 됩니다.
- ABAP Cloud(BTP)는 다릅니다: BTP ABAP 환경에서는 전통적 STMS 대신 소프트웨어 컴포넌트 + gCTS(Git 기반 CTS) 로 배포가 이루어집니다. Git 저장소에 커밋/풀 하는 방식이라 일반 개발의 배포와 훨씬 비슷합니다. 온프레미스와 클라우드의 배포 체계가 다르다는 점은 실기 시험 준비 시에도 알아둘 포인트입니다.
정리하면 ABAP 배포는 “TR에 담고 → 태스크/요청 릴리스(SE10) → 큐에서 임포트(STMS) → RC 확인” 의 흐름이고, 실수는 대부분 릴리스 전 오브젝트 확인 소홀과 이관 순서에서 나옵니다. 다른 플랫폼에서 넘어온 개발자에게는 답답하게 느껴질 수 있지만, 수백 명이 쓰는 운영 시스템의 변경을 오브젝트 단위로 추적·통제하는 체계라고 생각하면 SAP가 왜 이렇게 만들었는지 수긍이 갑니다. 실무에서 겪은 이관 사고 사례나 궁금한 점은 댓글로 나눠주세요.