안녕하세요, 비즈니스 혁신 파트너 BSG입니다.
이 블로그에서 가장 많이 읽힌 글 중 하나가 “2027년, SAP ECC 지원이 끝납니다” 였습니다.
그 글을 읽은 분들이 다음으로 묻는 질문은 대개 이겁니다.
"그럼 우리 SAP는 어디에서 돌려야 하나요?"
지금 회사 전산실에 있는 서버를 계속 쓸지, 클라우드로 옮길지. 옮긴다면 어디로, 어떤 방식으로 옮길지.
오늘은 그중 가장 많이 선택되는 길 중 하나인 SAP on AWS, 즉 SAP를 AWS 위에서 운영하는 이야기를 해보겠습니다.
SAP는 회사의 가장 핵심 시스템입니다.
그래서 오랫동안 “SAP만큼은 우리 전산실에”라는 인식이 강했죠.
그런데 상황이 바뀌었습니다.
서버 교체 주기가 돌아옵니다.
ECC에서 SAP Cloud ERP로 전환하려면 대개 더 큰 메모리를 가진 서버가 필요합니다.
어차피 하드웨어를 새로 사야 하는 시점이라면, 그 돈을 클라우드에 쓰는 게 나은지 따져보게 됩니다.
필요할 때만 크게 쓸 수 있습니다.
연말 결산이나 대규모 데이터 이관처럼 잠깐 큰 자원이 필요한 순간을 위해, 1년 내내 큰 서버를 놀려둘 필요가 없어집니다.
테스트 서버를 잠깐 띄웠다가 끄는 것도 쉬워지고요.
데이터를 다른 곳에 쓰기 쉬워집니다.
SAP 데이터가 클라우드에 있으면, 같은 클라우드의 분석 도구나 AI 서비스와 연결하기가 훨씬 수월합니다.
앞선 글들에서 계속 말씀드린 “AI는 결국 데이터”라는 이야기가 여기서 현실이 됩니다.
“SAP on AWS”라고 하면 한 가지 방식 같지만, 실제로는 크게 세 갈래가 있습니다.
① SAP가 운영해주는 방식
SAP의 클라우드 전환 패키지인 RISE with SAP를 통해 SAP Cloud ERP Private을 쓰는 방식입니다.
인프라와 기술 운영을 SAP가 책임지고, 그 인프라로 AWS 같은 클라우드를 선택할 수 있습니다.
운영 부담이 가장 적은 대신, 인프라를 우리가 직접 다루는 자유도는 낮습니다.
② 우리가(또는 파트너가) 직접 운영하는 방식
이미 보유한 SAP 라이선스로, AWS 위에 SAP를 직접 구축하고 운영하는 방식입니다.
인프라 구성과 운영 방식을 회사 사정에 맞게 정할 수 있고, 다른 AWS 서비스와 자유롭게 연결할 수 있습니다.
대신 운영 역량이 필요하죠.
이 경우 많은 기업이 운영 파트너와 함께합니다.
③ 일단 옮기고, 나중에 전환하는 방식
지금 쓰는 ECC를 그대로 AWS로 먼저 옮기고, SAP Cloud ERP 전환은 그다음에 진행하는 방식입니다.
서버 교체 시점은 다가오는데 전환 준비가 아직이라면, 인프라 문제부터 해결하고 전환을 차분히 준비할 수 있습니다.
정답은 회사마다 다릅니다.
운영을 얼마나 맡기고 싶은지, 얼마나 유연하게 쓰고 싶은지, 전환 일정이 어떤지에 따라 선택이 갈립니다.
SAP를 올릴 수 있는 클라우드는 여러 곳입니다.
그중 AWS가 자주 선택되는 데는 이유가 있습니다.
SAP를 가장 오래, 가장 많이 돌려본 곳 중 하나입니다.
AWS는 오래전부터 SAP 운영을 위한 인프라를 준비해왔습니다.
SAP HANA처럼 큰 메모리가 필요한 시스템을 위한 대용량 서버도 SAP 인증을 받아 제공합니다.
운영 사례가 많다는 건 그만큼 겪어본 문제와 해법이 쌓여 있다는 뜻입니다.
구축과 운영을 돕는 도구가 갖춰져 있습니다.
SAP 시스템을 정해진 모범 구성으로 자동 배포하는 도구, SAP HANA 데이터베이스를 AWS 저장소로 바로 백업하는 도구처럼
SAP 운영에 특화된 도구들이 있어 구축 기간과 운영 부담을 줄일 수 있습니다.
SAP 데이터를 AI와 바로 연결할 수 있습니다.
AWS는 SAP의 ABAP 프로그램에서 AWS 서비스를 직접 호출할 수 있는 개발 도구를 제공합니다.
SAP 안에서 AWS의 분석 서비스나 Amazon Bedrock 같은 생성형 AI 서비스를 쓸 수 있다는 뜻이죠.
앞서 다룬 사내 AI 챗봇이나 문서 자동 처리 같은 일을 SAP 데이터와 엮기가 수월해집니다.
국내에 이미 많이 쓰고 있습니다.
앞선 글에서 다뤘듯 국내 민간 클라우드 시장에서 AWS의 비중이 압도적입니다.
이미 다른 시스템을 AWS에서 운영하고 있다면, SAP까지 같은 곳에 두는 게 관리와 연결 모두에서 유리합니다.
클라우드로 옮긴다고 모든 게 자동으로 좋아지지는 않습니다.
미리 따져봐야 할 것들이 있습니다.
비용은 '구조'로 봐야 합니다.
서버를 사는 것과 달리 클라우드는 쓰는 만큼 냅니다.
서버 크기를 어떻게 잡느냐, 항상 켜둘 서버와 필요할 때만 켤 서버를 어떻게 나누느냐, 장기 약정을 어떻게 활용하느냐에 따라 비용이 크게 달라집니다.
처음 설계가 몇 년치 비용을 좌우합니다.
라이선스 조건을 확인해야 합니다.
지금 가진 SAP 라이선스를 클라우드에서 그대로 쓸 수 있는지, 데이터베이스 라이선스는 어떻게 되는지 미리 확인해야 합니다.
이 부분을 놓치면 이관 후 예상치 못한 비용이 생깁니다.
멈춰서는 안 되는 시간을 정해야 합니다.
SAP는 회사가 멈추면 안 되는 시스템입니다.
이관 당일 몇 시간까지 멈춰도 되는지, 장애 시 얼마 안에 복구해야 하는지를 미리 정해야 설계가 나옵니다.
백업·재해복구 글에서 다룬 기준이 여기서 그대로 쓰입니다.
옮긴 뒤의 운영을 누가 할지 정해야 합니다.
클라우드로 옮기면 전산실 관리는 줄지만, 클라우드 운영이라는 새로운 일이 생깁니다.
비용 관리, 보안 설정, 장애 대응. 이걸 사내에서 할지 파트너와 할지 이관 전에 정해두는 게 좋습니다.
SAP on AWS 프로젝트가 까다로운 건, 두 세계를 모두 알아야 하기 때문입니다.
SAP를 잘 아는 회사는 클라우드 인프라에 약하고, 클라우드를 잘 아는 회사는 SAP 업무와 데이터 구조를 모르는 경우가 많습니다.
그런데 SAP on AWS에서 생기는 문제는 대개 그 둘이 만나는 지점에서 터집니다.
서버 크기가 SAP 업무량에 안 맞거나, 백업 설계가 SAP 운영 방식과 어긋나는 식으로요.
BSG는 국내 유일의 SAP 플래티넘 파트너이자 AWS MSP 인증을 보유한 파트너입니다.
그리고 SAP on AWS 분야에서 글로벌 Top 3 실적을 기록한 경험이 있습니다.
두 세계를 함께 다뤄온 만큼, 이관 설계부터 이후 운영까지 한 흐름으로 함께할 수 있습니다.
ECC 지원 종료가 다가오면서 많은 기업이 SAP 전환을 고민하고 있습니다.
그런데 "무엇으로 바꿀지"만큼 중요한 질문이 "어디에서 돌릴지" 입니다.
인프라 결정은 한 번 하면 몇 년을 갑니다.
그리고 그 결정이 앞으로 SAP 데이터를 AI와 얼마나 쉽게 연결할 수 있을지까지 좌우합니다.
우리 SAP를 어디에, 어떤 방식으로 올릴지 고민이시라면, 지금 구조부터 함께 진단해보시죠.
출처 : AWS for SAP 공식 자료, SAP RISE with SAP 안내, BSG Partners SAP·AWS 구축 경험
기획 : 도예원