Azure meets SAP: Microsoft Teams를 위한 SAP on Azure 설명

By Mirko Peters · 2026-11-05

Microsoft Azure에서 SAP를 실행한다는 것의 실제 의미: 인증된 가상 머신과 스토리지, 먼저 구축해야 하는 랜딩 존, 하이브리드 연결, 세 가지 배포 경로, 그리고 지원되는 SAP 시스템을 지원되지 않는 시스템으로 바꾸는 실수들.

Automatically translated with AI from the original post. Read the English original

Microsoft MVP로서 저는 대부분의 시간을 Azure, Entra ID, Microsoft 365를 깊이 이해하고 있는 분들과 보냅니다. 그런데 이분들이 갑자기 "SAP 이전을 지원해 달라"는 요청을 받는 경우가 많습니다. 이들에게 SAP는 고유한 용어를 가진 별개의 세계처럼 느껴질 것입니다. 다행히 Azure의 SAP는 생각보다 훨씬 평범합니다. 핵심은 두 가지 규칙으로 요약됩니다. 인증된 구성 안에 머무르고, 첫 번째 SAP 시스템이 들어오기 전에 기반을 먼저 구축하는 것입니다. 이 글에서는 실제 작업 순서에 따라 두 가지를 차례로 살펴보겠습니다.

Azure의 SAP가 실제로 의미하는 것

Azure의 SAP란 SAP 시스템이 Microsoft Azure에서 실행된다는 뜻입니다. SAP HANA 데이터베이스, 애플리케이션 서버, 중앙 서비스는 Azure 가상 머신에 올라가고 Azure 스토리지와 네트워킹을 사용합니다. 하지만 SAP 소프트웨어 자체는 바뀌지 않습니다. SAP S/4HANA는 여전히 S/4HANA이고, SAP NetWeaver는 여전히 NetWeaver입니다. 바뀌는 것은 그 아래의 기반뿐입니다.

이 구분을 보면 누가 무엇을 책임지는지 알 수 있습니다. Microsoft는 가상 머신, 디스크, 네트워크, ID, 모니터링 같은 플랫폼을 제공합니다. SAP는 애플리케이션과 데이터베이스를 제공하며, 고객은 SAP가 기대하는 방식으로 이를 운영합니다. 두 영역이 만나는 지점이 가운데에 있는 인증된 인프라입니다.

여기서 함께 헷갈리기 쉬운 두 번째 주제와 구분해 두는 것이 도움이 됩니다. Power BI나 Microsoft Fabric에서 보고서를 만들기 위해 SAP 데이터를 Azure로 복사하는 것은 데이터 통합입니다. 유용한 작업이지만 성격이 다릅니다. 반면 Azure에서 SAP를 실행한다는 것은 운영 시스템 자체가 그곳에 있고, 거래를 그곳에서 처리하며, 사용자에게 그곳에서 서비스를 제공한다는 뜻입니다.

SAP 제품군 전체를 먼저 조망하고 싶다면 M365.FM의 SAP 주제 페이지에 관련 콘텐츠가 모여 있습니다.

"인증"이 모든 것을 결정하는 이유

SAP의 세계에서 "Azure에서 실행된다"는 실제로 "인증된 Azure에서 실행된다"는 뜻입니다. SAP와 Microsoft는 특정 가상 머신 유형과 스토리지 옵션을 특정 SAP 제품 및 시나리오에 대해 테스트하며, 이러한 조합만 지원됩니다. Microsoft는 Azure용 SAP 인증 및 구성과 Azure에서 지원되는 SAP 소프트웨어를 문서로 제공합니다. SAP HANA의 경우 SAP가 제공하는 HANA Hardware Directory가 기준 목록이며, NetWeaver 기반 시스템의 경우 SAP Note 1928533에 지원되는 Azure VM 유형이 나와 있습니다.

인증은 Azure 전체의 속성이 아닙니다. 특정 가상 머신, 특정 스토리지 옵션, 특정 SAP 시나리오가 함께 맞물렸을 때 생기는 속성입니다. 웹 애플리케이션에는 완벽한 사양의 VM이라도 HANA 목록에는 아예 없을 수 있습니다. 그럼에도 그것을 선택한다면 비용을 아낀 것이 아니라, 어느 벤더도 책임지려 하지 않는 시스템을 만든 것입니다.

스토리지도 같은 원칙을 따릅니다. Azure 관리 디스크는 일상적으로 쓰는 기본 구성 요소이고, Azure NetApp Files는 여러 SAP 아키텍처에서 사용되는 NFS 스토리지를 제공하며, 프리미엄(SSD) 스토리지의 Azure Files는 공유 디렉터리를 호스팅할 수 있습니다. Azure Files의 저렴한 표준 계층은 SAP 중앙 서비스 고가용성 공유에서 지원되지 않으므로, 여기서는 저렴한 옵션이 잘못된 선택입니다. Microsoft는 이러한 경계를 Azure VM의 SAP 워크로드 지원 시나리오에 정리해 두고 있습니다.

대부분의 문제를 막아 주는 습관은 다음과 같습니다. 머신 한 대의 크기를 정하기 전에, 사용할 SAP 제품과 시나리오에 대한 인증 목록을 열어 보고 그 기준에 맞춰 설계하십시오.

가장 먼저 구축할 랜딩 존

Azure 랜딩 존은 어떤 워크로드든 배포되기 전에 ID, 네트워크, 보안, 거버넌스를 제공하는 기반입니다. Microsoft의 Cloud Adoption Framework는 이를 두 부분으로 나눕니다.

• 플랫폼 랜딩 존: 관리 그룹, 중앙 연결, ID, 보안 및 관리 서비스를 포함하는 공유 기반입니다.
• 애플리케이션(워크로드) 랜딩 존: 개발, 테스트, 운영 등 일반적으로 구성되는 개별 환경이며, 각각 플랫폼 가드레일을 상속받는 구독으로 이루어집니다.

SAP는 재무, 공급망, 운영을 담당하기 때문에 대부분의 워크로드보다 이 점이 더 중요합니다. 첫 번째 SAP 시스템이 들어오기 전에 정책, 네트워크 규칙, ID가 이미 준비되어 있어야 합니다. 나중에 덧붙이려면 실제 운영 중인 비즈니스 시스템의 리소스를 옮겨야 합니다.

Microsoft는 허브-스포크 또는 Azure Virtual WAN 네트워크 토폴로지를 기반으로 한 참조 설계를 담은 Azure의 SAP 랜딩 존 액셀러레이터를 제공합니다. Azure Policy와 관리 그룹 계층 구조가 가드레일을 설정하고, 이후 모든 SAP 시스템은 그 안에 배치됩니다. 덕분에 두 번째, 세 번째 SAP 시스템을 들일 때 명명 규칙, 액세스, 네트워크 규칙을 다시 논쟁할 필요가 없어집니다.

SAP를 데이터 센터와 연결된 상태로 유지하기

SAP를 Azure로 옮긴다고 해서 모든 것을 뒤에 남겨 두는 경우는 드뭅니다. 대부분의 환경은 오랫동안 하이브리드 상태를 유지하므로, 이들을 하나로 묶어 주는 다리가 바로 연결성입니다.

주요 프라이빗 옵션은 Azure ExpressRoute입니다. 공용 인터넷을 통하지 않고 데이터 센터와 Azure 사이를 잇는 전용 프라이빗 연결입니다. ExpressRoute를 사용할 수 없는 경우에는 사이트 간 VPN이 대안이 됩니다. 어느 쪽이든 연결은 보통 중앙 허브 또는 Virtual WAN에서 종료되며, SAP 가상 네트워크는 거기서부터 이 연결에 접근합니다. Azure 내부에서는 일반적인 SAP 설계가 애플리케이션 계층과 데이터베이스 계층을 각각 별도의 서브넷으로 나누고, 네트워크 보안 그룹, 라우팅 테이블, 방화벽으로 보호하는 방식입니다.

ID는 주의 깊게 살펴볼 필요가 있습니다. Microsoft 팀들이 가정을 잘못하기 쉬운 부분이기 때문입니다. Microsoft Entra ID는 SAP 애플리케이션에 대한 단일 로그인(SSO)에 매우 적합합니다. 하지만 Windows에서 실행되는 SAP NetWeaver 및 S/4HANA 시스템은 SAP 애플리케이션 자체에 Entra ID 계정을 사용하지 않습니다. 여전히 온프레미스에서 확장된 Active Directory Domain Services나 Microsoft Entra Domain Services가 필요합니다. 로그인과 운영 체제 디렉터리는 서로 다른 문제입니다.

세 가지 배포 옵션

Azure에서 SAP를 배포하는 정답은 하나가 아닙니다. 팀의 운영 방식에 맞는 경로를 선택하십시오.

1. 일반 Azure 가상 머신. 운영 체제, SAP 설치, 패치, 모니터링을 직접 관리합니다. 제어권은 최대이지만 작업량도 최대입니다. SAP와 Azure 기술을 사내에 충분히 갖추고 있을 때 적합합니다.
2. Azure Center for SAP solutions. SAP을 최상위 워크로드로 다룰 수 있게 해 주는 Azure 서비스입니다. 단일 서버, 분산, 분산 고가용성 시스템에 대한 인프라를 생성하고 SAP 소프트웨어를 설치할 수 있으며, Azure에서 이미 실행 중인 SAP 시스템을 등록할 수도 있습니다. 각 시스템은 SAP solutions용 가상 인스턴스(Virtual Instance for SAP solutions)가 되며, 이는 SID, 중앙 서비스, 데이터베이스 및 애플리케이션 서버를 논리적으로 보여 주는 뷰입니다. 여기에서 상태와 정상 여부를 확인하고, 시스템을 시작하거나 중지하고, 모범 사례 기준의 품질 검사를 실행하며, 모니터링 데이터를 확인할 수 있습니다. 자세한 내용은 Azure Center for SAP solutions 개요에서 확인할 수 있습니다.
3. SAP on Azure 배포 자동화 프레임워크. 반복 가능하고 버전 관리되는 배포와 DevOps 워크플로를 원하는 팀을 위한 오픈 소스 Infrastructure as Code 방식입니다.

간단한 판단 기준은 다음과 같습니다. 완전한 제어와 탄탄한 기술 역량이 있다면 일반 VM이 적합하고, 가이드를 따르는 설정과 시스템 관리를 한곳에서 하고 싶다면 Azure Center for SAP solutions가 적합하며, 같은 방식으로 배포하는 시스템이 많다면 자동화 프레임워크가 적합합니다.

흔한 실수

처음 진행하는 마이그레이션에서 가장 큰 어려움을 겪는 경우는 대개 선택 사항처럼 보였던 단계에서 비롯됩니다.

• 인증을 형식적인 절차로 여기는 것. 인증되지 않은 VM이나 스토리지 유형을 사용하면 지원되던 시스템이 지원되지 않는 시스템으로 바뀌며, 보통 가장 곤란한 순간에 이를 알게 됩니다.
• 랜딩 존을 건너뛰는 것. "거버넌스는 나중에 추가하면 된다"는 말은 실제로 지켜지는 경우가 드물며, 운영 중인 SAP 시스템 주변에 ID 및 네트워크 규칙을 나중에 적용하는 작업은 느리고 위험합니다.
• Windows 기반 SAP 시스템에서 Entra ID가 Active Directory를 대체한다고 가정하는 것. 대체하지 않습니다.
• 연결성을 마지막에 설계하는 것. SAP 애플리케이션 계층과 데이터베이스 계층을 온프레미스와 Azure에 나누거나 Azure 리전 간에 걸쳐 배치하는 구성은 지원되지 않습니다.
• 모든 것이 Azure에서 실행된다고 가정하는 것. Azure VMware Solution은 일반적으로 SAP 워크로드를 호스팅하는 지원 플랫폼이 아니며, SAP HANA Large Instances는 더 이상 신규 고객에게 제공되지 않습니다.
• 데이터베이스에 Azure Site Recovery를 사용하는 것. Azure Site Recovery는 SAP 데이터베이스 계층에서 지원되지 않습니다. 재해 복구에는 SAP HANA System Replication처럼 데이터베이스가 기본으로 제공하는 복제 기능을 사용하십시오.

이 항목들은 Microsoft와 SAP의 지원 범위가 더 이상 일치하지 않는 지점입니다. 이러한 제한은 작업을 방해하려는 것이 아니라, 두 벤더가 시스템을 책임지고 지원할 수 있는 영역을 표시하는 것입니다.

결론: 작업 순서

한 가지만 기억해야 한다면 순서를 기억하십시오. 먼저 SAP 시스템이 성능, 가용성, 복구 측면에서 무엇을 필요로 하는지 정의합니다. 그다음 랜딩 존을 구축하고, 네트워크와 디렉터리를 데이터 센터와 다시 연결합니다. 관리 범위를 정합니다. 즉, 일반 VM, Azure Center for SAP solutions, 자동화 프레임워크 중 무엇을 사용할지 선택합니다. 인증된 컴퓨팅과 스토리지를 선택한 뒤, 데이터베이스 자체 기능을 중심으로 고가용성과 재해 복구를 설계합니다.

모든 것을 한 번에 옮길 필요는 없습니다. 하나의 시스템부터 시작하면 위험이 아직 작을 때 랜딩 존이 어디서 부족한지, 팀이 어디에서 지원이 필요한지 확인할 수 있습니다. Microsoft 전문가에게 SAP on Azure는 낯선 영역이 아닙니다. 인증을 절대 타협하지 않는 단 하나의 규칙을 지키면서 내리는 일반적인 엔지니어링 결정의 집합입니다.