
목차
SAP 기술 변경 관리 도구는 무엇이, 어떤 순서로, 누구의 승인을 받아 운영 환경에 들어가는지를 통제합니다. 거의 모든 평가에 오르는 도구는 네 가지입니다. SAP Cloud ALM은 신규 프로그램을 위한 SAP의 전략적 선택입니다. Solution Manager ChaRM은 온프레미스 환경에서 검증된 네이티브 옵션입니다. Rev-Trac은 대량 처리와 병렬 개발에 맞습니다. Basis Technologies의 ActiveControl은 원래 Transport Express라는 이름으로 판매되었고, 또 하나의 주요 서드파티 옵션입니다. 어떤 기능 비교표보다 먼저, 배포 모델과 트랜스포트 물량이 후보를 좁혀 줍니다.
유럽 제조 그룹의 롤아웃을 이끌던 시절에 호된 교훈을 얻었습니다. 한 개발자가 아무 승인 없이 트랜스포트를 곧바로 운영 환경에 반영했습니다. 점검은 하나도 거치지 않았습니다. 시스템이 멈추지는 않았지만 재고 수치가 엉망이 되었고, 정리하는 데 이틀이 걸렸습니다. 그때부터 변경 관리 도구를 진지하게 다루게 되었습니다.
SAP 시스템 환경을 관리하기 시작했을 때는 트랜스포트를 기술적인 인수인계로 생각했습니다. 코드를 옮기고, 테스트하고, 끝. 의존성 하나를 놓친 일을 겪은 뒤로 그 생각은 바뀌었습니다. 실제로 중요한 요소는 다음과 같습니다.
- 변경 요청 워크플로. 문서화되지 않은 변경도, 뒷문도 없어야 합니다. 모든 것에 기록이 남아야 합니다.
- 트랜스포트 순서 관리. 순서가 틀리면 시스템 간 불일치를 바로잡느라 몇 시간을 씁니다.
- 오브젝트 이력. 누가, 언제, 무엇을, 왜 바꿨는지 남깁니다.
- 의존성 및 충돌 점검. 자주 건너뛰고, 가장 큰 고통을 낳습니다.
- 감사 로그. SOX 요건이 없어도 유용합니다. 무언가 깨졌을 때 이 기록이 필요해집니다.
- 승인 게이트. 무엇이든 운영 환경에 닿기 전에 두는 적정한 마찰입니다.
- 반영 권한 제한. 모든 사람이 운영 환경에 임포트할 필요는 없습니다.
도구 평가를 촉발하는 문제는 보통 네 가지입니다. 트랜스포트가 운영 환경으로 곧바로 밀려 들어가는 일. 재무는 티켓, 물류는 이메일을 쓰는 것처럼 부서마다 다른 승인 방식. 두 개발자가 서로 다른 트랜스포트에서 같은 오브젝트를 수정해, 마지막 임포트가 상대의 작업을 덮어쓰는 일. 그리고 아무도 쓸 시간이 없었던 문서입니다.
- 변경 요청문서화, 뒷문 없음
- 승인 게이트운영 환경 앞의 적정한 마찰
- 순서 및 충돌 점검순서와 의존성을 먼저 확인
- 운영 환경 반영반영 권한이 있는 사람만
- 감사 추적누가 언제 무엇을 왜 바꿨는지
운영 환경의 모든 변경은 승인된 요청까지 거슬러 추적할 수 있습니다
SAP Cloud ALM
SAP Cloud ALM은 SAP의 클라우드 기반 애플리케이션 라이프사이클 관리 서비스이며 Solution Manager의 후속입니다. Enterprise Support, cloud edition 조건의 SAP 클라우드 구독과, 온프레미스 고객의 SAP Enterprise Support에 포함되어 있습니다.
변경 및 배포 관리는 "피처(feature)"로 변경 문서와 이를 실어 나르는 트랜스포트를 묶습니다. S/4HANA Private Edition과 릴리스 7.40 이상의 온프레미스 ABAP 시스템(ECC 포함)은 Change and Transport System(CTS)에 연결됩니다. Public Edition에서는 Adaptation Transport Organizer를 쓰고, BTP와 Integration Suite 콘텐츠에는 SAP Cloud Transport Management를 씁니다. CTS+는 지원되지 않습니다.
중요한 한계가 두 가지 있습니다. ChaRM에 있는 품질 게이트 관리는 SAP가 Cloud ALM의 현재 범위에 없다고 밝히고 있습니다. 또한 SAP는 ChaRM 변경 데이터를 이전할 계획이 없습니다. Solution Manager의 진행 중인 변경 주기를 닫은 뒤 Cloud ALM 배포 관리를 활성화할 것을 권장합니다(SAP Support). 규제 환경이나 리트로핏, 전자 서명이 걸린 복잡한 ChaRM 구성이라면, 빠진 기능이 채워질 때까지 기다리라는 것이 SAP 자체의 가이드입니다.
이럴 때 적합합니다. 어떤 에디션이든 새 S/4HANA 프로그램을 시작하거나, RISE 또는 GROW를 쓰거나, Solution Manager를 퇴역시킬 계획이 있는 경우입니다. Cloud ALM이 해당 기능을 지원하기 전까지는 승인 게이트를 자사 프로세스에서 직접 보완해야 합니다.
Solution Manager ChaRM
SAP Enterprise Support 비용을 내고 계시다면 Solution Manager 7.2의 Change Request Management(ChaRM)는 이미 보유하고 계신 것입니다. 대부분의 고객은 제공되는 기능의 일부만 씁니다. 변경 요청과 변경 문서, 긴급 변경, 복사 트랜스포트, 이중 환경 리트로핏, 품질 게이트 관리입니다.
외부 도구를 살지, 이미 가진 ChaRM을 쓸지 고민하던 제조업 SAP 고객을 알고 있습니다. 변경량은 하루 50~60건 정도였습니다. 의존성 요건을 평가해 보니 ChaRM이 추가 라이선스 없이 감당할 수 있었습니다. 석 달 만에 2,000건이 넘는 트랜스포트를 배포 문제 없이 처리했습니다. 차이를 만든 것은 품질 게이트와 승인 워크플로를 제대로 구성한 일이었습니다.
문제는 시간입니다. "라이선스에 포함"이라고 해서 공짜는 아니며, 제대로 된 ChaRM 구성에는 몇 달이 걸립니다. Solution Manager 7.2의 주류 유지보수는 2027년 말에 끝납니다. Business Suite 연장 유지보수를 구매한 고객은 2030년까지 Solution Manager 제한 연장 유지보수를 받으며, 여기에는 변경 통제 관리가 계속 포함됩니다.
이럴 때 적합합니다. Solution Manager가 이미 가동 중이고, 감사인이 완전한 추적성을 기대하며, 품질 게이트나 리트로핏이 지금 당장 필요한 경우입니다. 새 ChaRM 구축을 시작하기보다 S/4HANA 일정에 맞춰 Cloud ALM으로의 전환을 계획하십시오.
Rev-Trac
Rev-Trac은 SAP 환경 전반에서 트랜스포트 순서 관리, 충돌 감지, 승인을 자동화하며 SAP 시스템 안에서 네이티브로 실행됩니다. 공급사는 현재 고객사 전체 기준으로 릴리스 주기가 60% 빨라지고 트랜스포트 오류가 99% 줄었다고 밝힙니다(Rev-Trac). 이는 공급사의 주장으로 받아들이고, 귀사와 비슷한 환경의 레퍼런스를 요청하십시오.
제가 가까이서 지켜본 한 구축 사례에서는 팀이 매달 평균 15건의 운영 이슈를 겪고 있었고, 대부분이 순서 관리 미흡에서 비롯된 것이었습니다. Rev-Trac을 도입하고 석 달이 지나자 그 숫자가 2건으로 줄었습니다. 자동 점검이 운영 환경에 닿기 전에 거의 모든 충돌을 걸러 냈습니다.
설치만으로 성과가 나지는 않습니다. 의존성 계획을 제대로 세우지 않고 Rev-Trac에 뛰어든 글로벌 기업이 몇 주 동안 애를 먹는 모습을 본 적이 있습니다. Rev-Trac은 시스템과 사용자 수에 따라 연 $150,000에서 $500,000까지 들 수 있습니다. 충분히 복잡한 환경이라면 도구가 아니라 운영 장애가 줄어드는 효과에 비용을 내는 것입니다.
이럴 때 적합합니다. 하루에 수백 건의 트랜스포트를 처리하거나, 병렬 개발 트랙이 여럿이거나, ECC와 S/4HANA가 섞인 환경에서 충돌이 이미 운영 환경까지 올라오고 있는 경우입니다.
ActiveControl(구 Transport Express)
이 글의 이전 버전은 "Transport Express"를 별도의 가벼운 도구로 설명했습니다. 그것은 잘못이었습니다. Transport Express(Transport Expresso로 적기도 합니다)는 Basis Technologies 변경 관리 제품의 원래 이름이고, 이후 ActiveControl로 이름이 바뀌었습니다. 오늘날에는 승인 워크플로, 복사 트랜스포트, ServiceNow 연동, CI/CD 파이프라인을 지원하는 SAP 인증 변경, 릴리스, DevOps 자동화 도구입니다(Basis Technologies). Rev-Trac의 아래가 아니라 경쟁 상대입니다.
값비싼 릴리스 조율 도구를 정당화하기 어려웠던 한 제약 고객은 변경 문서화를 개선하려고 Transport Express로 바꿨습니다. 두 달 안에 트랜스포트 오류가 65% 줄었습니다.
이럴 때 적합합니다. 자동화된 SAP 변경 및 릴리스 관리를 더 넓은 DevOps 툴체인과 연결하고 싶고, Rev-Trac도 후보에 올라 있는 경우입니다.
의사결정에 쓰신다면 제가 이렇게 위치를 잡겠습니다.
| SAP Cloud ALM | Solution Manager ChaRM | Rev-Trac | ActiveControl | |
|---|---|---|---|---|
| 제공사 | SAP | SAP | Rev-Trac | Basis Technologies |
| 라이선스 | SAP 클라우드 구독 및 Enterprise Support에 포함 | Enterprise Support에 포함, 구성 작업 필요 | 상용 구독 | 상용 구독 |
| 지원 시스템 | Public Edition(ATO), Private Edition 및 ABAP 7.40 이상 온프레미스(CTS), BTP(Cloud Transport Management) | CTS와 CTS+를 통한 ABAP 시스템 | ECC 및 S/4HANA 환경 | ECC 및 S/4HANA 환경 |
| 승인과 품질 게이트 | 피처 승인, 품질 게이트 관리는 아직 범위 밖 | 완전한 품질 게이트 관리 | 규칙 기반 승인 라우팅 | 구성 가능한 승인 워크플로 |
| 충돌 및 순서 점검 | 피처를 순서대로 배포, 현재 범위는 SAP에 확인 | 구성 시 시스템 간 오브젝트 잠금과 다운그레이드 보호 | 자동화, 핵심 강점 | 자동화 |
| DevOps 연동 | API, Jira 연동 | 제한적, 맞춤 인터페이스 | Jira, Git, Jenkins 커넥터 | ServiceNow 및 CI/CD 연동 |
| 향후 전망 | SAP의 전략 도구 | 주류 유지보수 2027년 종료 | 공급사 로드맵 | 공급사 로드맵 |
트랜스포트 순서와 의존성 점검이 제대로 갖춰지지 않으면, 충분히 테스트한 변경도 운영 환경을 무너뜨릴 수 있습니다. 좋은 코드도 잘못된 시점에 옮기면 나쁜 코드만큼 큰 피해를 냅니다.
모든 시스템 환경에 같은 수준의 통제가 필요한 것은 아닙니다. 다음 질문부터 시작하십시오.
- 현재 어떤 배포 모델을 쓰고 있습니까, 혹은 어디로 옮기려 합니까? Public Edition, Private Edition, 온프레미스 S/4HANA, ECC 중 어느 쪽입니까?
- 평상시와 릴리스 피크 때 하루 트랜스포트는 몇 건입니까?
- 병렬로 개발하는 팀은 몇이며, 시간대는 몇 개에 걸쳐 있습니까?
- 감사인이 SOX, GxP 등을 위해 트랜스포트 단위의 증빙을 요구합니까?
- 승인은 오늘날 실제 통제 지점입니까, 아니면 이메일로 쫓아다니는 일입니까?
- 개발자들이 운영 환경에서 서로의 작업을 덮어쓴 적이 있습니까?
| 귀사의 상황 | 제가 시작할 지점 |
|---|---|
| RISE 또는 GROW 기반 신규 S/4HANA 프로그램 | Cloud ALM으로 시작하고, 물량이나 병렬 트랙이 요구할 때만 Rev-Trac 또는 ActiveControl 추가 |
| ChaRM이 잘 돌아가는 온프레미스 환경 | S/4HANA 전환 기간에는 ChaRM 유지, 이후 Cloud ALM 전환 계획 |
| ChaRM에서 리트로핏이나 전자 서명을 쓰는 규제 산업 | Cloud ALM이 해당 기능을 지원할 때까지 ChaRM 유지, 2027년이 발목을 잡으면 서드파티 도구 검토 |
| 하루 수백 건의 트랜스포트, 병렬 트랙 | Rev-Trac 또는 ActiveControl, 문서화를 위해 Cloud ALM 병행 |
| Solution Manager가 없는 소규모, 저물량 환경 | 규율 있는 CTS 경로와 승인을 갖춘 Cloud ALM |
복잡한 환경에서는 답이 두 가지 도구인 경우가 많습니다. 변경 문서화와 SAP와의 정렬에는 Cloud ALM, 대량 처리 시의 순서 및 충돌 통제에는 Rev-Trac 또는 ActiveControl입니다.
맞는 도구는 기능이 가장 많은 도구가 아니라, 실제 문제를 해결해 주는 도구입니다. 거버넌스가 허술한 환경에서 ChaRM이 실패하고 규율이 잡힌 환경에서는 더 단순한 구성이 성공하는 모습을 보았습니다. 변경 통제는 품질 게이트와 테스트 도구와도 맞물려야 합니다. 문제가 트랜스포트가 아니라 사람에게 있다면, 변경 관리 계획 가이드가 그쪽을 다룹니다.
SAP 기술 변경 관리 도구란 무엇입니까?
SAP 시스템에 대한 변경을 통제해, 모든 구성 및 코드 변경이 추적되고 승인되며 올바른 순서로 임포트되도록 하는 도구입니다. 가장 많이 평가되는 네 가지는 SAP Cloud ALM, Solution Manager ChaRM, Rev-Trac, ActiveControl입니다. 도구가 없으면 스프레드시트와 이메일, 기억에 의존하게 되고, 의존성 하나만 놓쳐도 운영 중단이 생길 수 있습니다.
SAP Cloud ALM이 Solution Manager ChaRM을 대체합니까?
네, 시간이 지나면서 그렇게 됩니다. Cloud ALM은 SAP의 전략적 후속 제품이고 Solution Manager 7.2의 주류 유지보수는 2027년에 끝납니다. Cloud ALM은 이미 Public Edition, Private Edition, 7.40 이상의 온프레미스 ABAP 시스템의 트랜스포트를 관리할 수 있습니다. SAP는 ChaRM 변경 데이터를 이전하지 않으며, 품질 게이트 관리는 아직 Cloud ALM의 범위에 들어 있지 않습니다. ChaRM 구성이 복잡한 규제 고객에게는 해당 기능이 나올 때까지 기다리도록 권고합니다.
SAP Cloud ALM으로 ECC 트랜스포트를 관리할 수 있습니까?
네. Cloud ALM의 변경 및 배포 관리는 릴리스 7.40 이상 SAP NetWeaver ABAP 시스템의 Change and Transport System에 연결됩니다. ECC, 온프레미스 S/4HANA, Private Edition이 여기에 해당합니다. CTS+는 지원되지 않으며, 관리 대상 시스템에는 선행 서포트 패키지와 SAP Note가 필요합니다.
Transport Express는 어떻게 되었습니까?
Transport Express(Transport Expresso로 적기도 함)는 Basis Technologies의 SAP 변경 관리 제품이 처음 쓰던 이름이었습니다. 트랜스포트 관리에서 변경, 릴리스, DevOps 자동화로 커지면서 ActiveControl로 이름이 바뀌었습니다. 도구를 비교하고 계시다면 Rev-Trac과 함께 ActiveControl을 평가하십시오.
Rev-Trac은 언제 의미가 있습니까?
트랜스포트 물량이 많거나, 여러 개발 트랙이 병렬로 돌아가거나, 충돌이 이미 운영 환경까지 올라오고 있을 때입니다. 강점은 자동 충돌 감지와 순서 관리입니다. 먼저 의존성 계획을 세워 두어야 하고 비용도 상당하므로, 타당성은 운영 장애 감소에 달려 있습니다.
SAP 변경 관리 도구는 어떻게 고릅니까?
배포 모델에서 시작해 트랜스포트 물량, 병렬 트랙 수, 감사 요건, 이미 Solution Manager를 쓰고 있는지를 차례로 보십시오. 실제로 겪고 있는 문제를 해결하는 도구를 고르고, 구성과 교육 예산을 확보하십시오. 이쪽이 도구 자체보다 더 중요합니다.
다음 단계
지금 ERP 프로젝트를 진행 중이십니까?
이 글이 지금 진행 중인 프로젝트와 맞닿아 있다면, 30분 대화가 일주일간의 내부 분석보다 대개 더 많은 진전을 가져옵니다.



