게이트웨이를 단순 파이프로 쓰지 마십시오: 실제로 하는 일
By Mirko Peters ·
팟캐스트 블로그 동반 콘텐츠에 다시 오신 것을 환영합니다! Power BI 데이터 세트 새로 고침이 한없이 느려지며 로딩 아이콘만 돌아가는 상황을 보신 적이 있거나, 경영진이 가장 필요로 할 때 엔터프라이즈 대시보드가 자꾸 시간 초과로 끊긴다면, 아마 문제의 원인을 잘못 짚고 계실 가능성이 큽니다. 많은 아키텍트와 관리자가 Power Platform 데이터 게이트웨이를 온-프레미스 데이터베이스와 클라우드 사이에서 데이터를 단순히 오가게 하는 수동적인 배관 장치 정도로 여깁니다. 하지만 실제는 그와 전혀 다릅니다.
Automatically translated with AI from the original post. Read the English original

팟캐스트 블로그 동반 콘텐츠에 다시 오신 것을 환영합니다! Power BI 데이터 세트 새로 고침이 한없이 느려지며 로딩 아이콘만 돌아가는 상황을 보신 적이 있거나, 경영진이 가장 필요로 할 때 엔터프라이즈 대시보드가 자꾸 시간 초과로 끊긴다면, 아마 문제의 원인을 잘못 짚고 계실 가능성이 큽니다. 많은 아키텍트와 관리자가 Power Platform 데이터 게이트웨이를 온-프레미스 데이터베이스와 클라우드 사이에서 데이터를 단순히 오가게 하는 수동적인 배관 장치 정도로 여깁니다. 하지만 실제는 그와 전혀 다릅니다.
이번 게시물에서는 게이트웨이의 아키텍처적 실체를 깊이 살펴보겠습니다. 게이트웨이가 어떻게 고성능 처리 엔진 역할을 하는지, 그리고 구성을 무시하면 왜 보고서 성능이 실제로 무너지는지 다루겠습니다. 이러한 아키텍처 개념을 더 자세히 알아보고 실제 문제 해결 시나리오에 대한 생생한 설명을 듣고 싶다면, 관련 팟캐스트 에피소드 Configure the Power Platform Data Gateway for Reliable Connectivity를 꼭 들어 보시기 바랍니다.
게이트웨이가 실제로 어떻게 동작하는지 함께 살펴보고, 병목을 고속도로로 바꾸기 위해 구체적으로 실행할 수 있는 단계들도 알아보겠습니다.
오해받는 중개자: 게이트웨이가 실제로 하는 일
게이트웨이 성능을 개선하려면, 먼저 클라우드 서비스가 온-프레미스 데이터 원본에 요청을 보낼 때 내부에서 실제로 무슨 일이 일어나는지 이해해야 합니다. 종이 위의 데이터 흐름은 겉보기에 단순합니다. Power BI 서비스가 게이트웨이 클러스터와 통신하고, 클러스터는 호스트 머신과 통신하며, 호스트 머신이 데이터 원본에 대해 쿼리를 실행한 뒤 같은 경로를 거슬러 결과를 반환합니다. 하지만 이것은 수동적인 릴레이가 아닙니다.
게이트웨이는 모든 단계에서 무거운 작업을 수행합니다. 인증 핸드셰이크를 처리하고, TLS(Transport Layer Security) 암호화를 종료했다가 다시 설정하며, 쿼리 페이로드를 변환하고, 대용량 메모리 버퍼를 관리합니다. 암호화, 쿼리 변환, 임시 파일 버퍼링을 모두 담당하기 때문에 게이트웨이 머신은 완전한 기능을 갖춘 처리 엔진입니다. 이를 가벼운 미들웨어처럼 취급하는 것은 재앙을 부르는 지름길입니다.
배포 모드도 자세히 살펴봐야 합니다. 개인 모드 게이트웨이는 단일 사용자 시나리오만을 위해 설계되었으므로 공유 엔터프라이즈 보고서에는 절대 사용하지 말아야 합니다. 프로덕션 워크로드에는 표준 데이터 게이트웨이를 배포해야 하며, 고가용성과 로드 밸런싱을 보장하려면 노드 두 개 이상으로 구성된 클러스터 방식이 이상적입니다. 또한 최신 아키텍처에서는 Azure VNet 데이터 게이트웨이를 활용해 인바운드 노출을 완전히 없앨 수 있으며, 이는 보안팀을 안심시키면서도 강력한 성능을 제공합니다.
기본 설정과 숨은 성능 저해 요인
Power Platform 데이터 게이트웨이를 새로 설치하면, 설치 프로그램은 거의 모든 하드웨어에서 별도 조정 없이 작동하도록 보수적인 기본 설정을 적용합니다. 안타깝게도 이러한 기본 설정은 엔터프라이즈 환경에서 보이지 않는 성능 저해 요인으로 작용합니다.
예를 들어 동시성을 살펴보겠습니다. 기본 상태에서 게이트웨이는 병렬 쿼리 실행을 제한하는 보수적인 대기열로 동작하는 경우가 많습니다. 강력한 하드웨어가 놀고 있는 상태에서 새로 고침이 순차적으로 대기하고 있다면 리소스를 낭비하고 있는 것입니다. 호스트의 실제 용량에 맞춰 병렬 쿼리 한도를 높여야 합니다.
버퍼 크기 설정도 또 다른 주요 함정입니다. 버퍼가 너무 작으면 게이트웨이는 데이터를 디스크로 넘겨야 하고, 이는 심각한 I/O 병목을 일으킵니다. RAM에 여유를 주십시오. 또한 보안팀의 안티바이러스 소프트웨어에 적절한 예외 항목이 설정되어 있는지 확인하십시오. 게이트웨이 설치 경로, 캐시 경로, 로그 경로에 대한 실시간 검사가 켜져 있으면 모든 임시 파일이 집중적으로 검사되어 쿼리 처리가 사실상 멈출 수 있습니다.
StreamBeforeRequestCompletes 설정에 대해서도 짚고 넘어가야 합니다. 이 설정은 저지연 로컬 네트워크(LAN)에서 성능을 크게 개선할 수 있지만, 지연 시간이 긴 VPN 환경에서는 심각한 위험을 초래합니다. 마지막으로, 업데이트 후 설정이 초기화되는 현상을 주의하십시오. 게이트웨이 소프트웨어를 업데이트할 때마다 기본 구성이 재설정되면서 직접 조정해 둔 튜닝 설정이 사라질 수 있습니다. 게이트웨이를 업그레이드한 직후에는 반드시 성능 튜닝 설정을 다시 적용하십시오.
네트워크 요인: 라우팅, 지연 시간, 그리고 콜드 포테이토 현실
게이트웨이 호스트에 아무리 고성능 하드웨어를 투입하더라도 네트워크 라우팅에 근본적인 문제가 있다면 성능은 여전히 저하됩니다. 지연 시간은 네트워크 홉을 거칠 때마다 누적되며, 잘못된 라우팅은 다른 모든 최적화 노력을 무력화합니다.
많은 조직이 "통제"를 위해 모든 트래픽을 기업 VPN과 중앙 집중식 웹 프록시로 우회시키는 함정에 빠집니다. 하지만 이런 불필요한 우회 경로는 실제로 수백 마일의 물리적 거리와 추가 네트워크 홉을 더하고, 리소스를 많이 소모하는 TLS 검사로 인한 지연까지 발생시킵니다. 대신 트래픽이 가장 가까운 Microsoft 엣지 POP(Point of Presence)으로 최대한 빠르게 직접 빠져나가도록 하십시오. 트래픽이 엣지 POP에 도달하면 이후에는 최적화된 Microsoft 글로벌 백본 네트워크를 타고 목적지까지 곧바로 이동합니다.
민감하고 대화형인 분석 작업에는 Microsoft 네트워크 라우팅 기본 설정을 구성하여 최상위 성능을 확보하십시오. 일반 인터넷 라우팅 옵션은 대량의 저우선순위 데이터 전송에만 사용하십시오. 기업 VPN 우회 경로를 벗어나는 것만으로도 보고서 새로 고침 시간을 개선하는 데 가장 큰 효과를 낼 수 있는 경우가 많습니다.
하드웨어와 호스팅: 제대로 된 게이트웨이 호스트 구축 방법
게이트웨이는 처리 부하가 큰 엔진이므로, 성능이 부족하거나 리소스가 과다 할당된 공유 가상 머신에서 실행하면 장애를 자초하는 것과 다름없습니다. 게이트웨이 호스트를 1등급 엔터프라이즈 인프라처럼 다뤄야 합니다.
하드웨어 측면에서는 최소 16GB RAM, 물리 CPU 코어 8개 이상, 캐시와 로그 파일용 고속 SSD 또는 NVMe 스토리지를 기준 사양으로 삼으십시오. 가상 머신을 사용하는 것도 전혀 문제없지만, CPU와 메모리 리소스를 반드시 확실하게 예약하고 절대 과다 할당하지 않아야 합니다.
단일 장애 지점을 없애고 처리량을 확장하려면 최소 두 개 노드로 구성된 게이트웨이 클러스터를 배포하십시오. 클러스터의 모든 노드는 동일한 버전 번호와 일치하는 구성을 갖추는 것이 매우 중요합니다. 하드웨어 사양이 적절한지 확인하려면 기본 제공되는 게이트웨이 성능 보고서와 Windows 성능 모니터(PerfMon) 카운터를 함께 사용해 CPU 사용률, RAM 사용량, 프라이빗 바이트, 쿼리 실행 시간 등 실제로 중요한 지표를 측정하십시오.
사전 예방적 최적화 및 유지 관리 모범 사례
인프라에는 지속적인 관리와 돌봄이 필요하며, 데이터 게이트웨이도 예외가 아닙니다. 가장 흔한 관리 실수 중 하나가 프로덕션 게이트웨이에서 자동 업데이트를 켜 두는 것입니다. 검증되지 않은 소프트웨어 업데이트는 구성 파일을 변경하거나 호환성 문제를 일으켜 업무에 필수적인 보고서를 중단시킬 수 있습니다.
대신 프로덕션에 적용하기 전에 업데이트를 테스트할 스테이징 환경을 마련하십시오. 문제가 생겼을 때 신속하게 복구할 수 있도록 클러스터 및 데이터 소스 설정을 항상 유지하고 백업해 두십시오. 또한 주간 상태 대시보드를 구축해 새로 고침 급증 시점을 일정과 연관 지어 분석하고, 리소스 집약적인 작업을 시간대별로 고르게 분산하십시오.
PowerShell 스크립트를 활용해 서비스 상태, 소프트웨어 버전, 큐 깊이를 모니터링하는 자동화된 상태 점검을 실행하고, 업무량이 적은 시간대에 예약된 정상 서비스 재시작을 구현하십시오. OS 빌드, .NET Framework 버전, 열린 포트, 바이러스 백신 예외 항목을 문서화하십시오. 게이트웨이를 실제 인프라처럼 다룬다는 것은 일상적인 운영에 체계적인 IT 거버넌스를 적용한다는 뜻입니다.
안정적인 연결을 위한 구현 체크리스트
이 개념들을 바로 실천에 옮길 수 있도록, 팀과 함께 복사해 붙여 넣고 검토할 수 있는 간단하고 실행 가능한 체크리스트를 준비했습니다.
- 모드 확인: Standard 게이트웨이(Personal은 절대 사용하지 않음)로 실행 중인지 확인하고, 최소 두 개 노드로 클러스터를 구성하십시오.
- 동시성 조정: 데이터 소스 및 노드별 병렬 쿼리 수를 늘리고, RAM 사용량을 모니터링하면서 버퍼 크기를 키우십시오.
- 스토리지 최적화: 게이트웨이 캐시와 로그를 고속 SSD 또는 NVMe 드라이브에 배치하고, 포괄적인 바이러스 백신 예외 항목을 구성하십시오.
- 스트리밍 평가: 실제 네트워크 지연 시간을 기준으로 StreamBeforeRequestCompletes 설정을 검토합니다.
- 라우팅 수정: Microsoft 365 및 Power Platform 엔드포인트의 트래픽은 로컬에서 나가도록 라우팅하고, 불필요한 VPN이나 프록시는 우회합니다.
- 트래픽 우선순위 지정: 분석 트래픽에 대해 Microsoft Network 라우팅 기본 설정이 활성화되어 있는지 확인합니다.
- 하드웨어 적정 규격화: 호스트에 최소 16GB RAM, 물리 코어 8개 이상이 있는지 확인하고, 가상화된 환경이라면 리소스가 예약되어 있는지 확인합니다.
- 성능 모니터링: Gateway Performance 보고서를 활성화하고 PerfMon 카운터를 연결합니다.
- 상태 자동화: PowerShell 상태 점검을 구현하고, 일정에 따라 서비스를 정상 종료한 후 재시작하도록 설정합니다.
- 업데이트 거버넌스: 보조 노드에서 소프트웨어 업데이트를 단계적으로 적용하고, 구성 백업을 유지하며, 운영 기준선을 문서화합니다.
결론
Power Platform 데이터 게이트웨이는 단순한 브리지나 단순 전달 통로 이상의 존재입니다. 하이브리드 분석 아키텍처의 중심에 자리한 정교한 처리 엔진입니다. 기본 설정에서 벗어나 Microsoft 글로벌 백본을 활용하도록 네트워크 라우팅을 최적화하고, 적절한 호스트 하드웨어에 투자하며, 철저한 운영 습관을 유지하면 새로 고침 병목 현상을 완전히 없애고 조직이 요구하는 초고속 보고를 제공할 수 있습니다.
이러한 아키텍처 원칙에 대한 더 깊은 논의와 새로 고침 시간을 몇 분이라도 줄이는 실용적인 팁을 더 알고 싶다면, 팟캐스트 에피소드 Configure the Power Platform Data Gateway for Reliable Connectivity를 꼭 확인해 보시기 바랍니다. 지금 바로 청취하고 구독하여 엔터프라이즈 연결을 직접 관리해 보십시오!