엔터프라이즈 컴퓨팅 환경은 클라우드 네이티브를 향해 발전하고 있습니다. 네트워크 경계도 자연스럽게 사내 LAN과 SD-WAN을 넘어 관리 주체가 다른 여러 외부 네트워크로 확장되고 있습니다. 이런 변화는 애플리케이션과 네트워크 성능 모니터링에 넓은 사각지대를 만듭니다. 기업이 직접 관찰할 범위 밖에 있는 통신사 백본, 인터넷 피어링, CSP 내부 경로, SaaS 내부 네트워크까지 속속들이 들여다볼 수 없기 때문입니다. 여기에 여러 CSP를 함께 쓰는 멀티 클라우드 환경은 경로 조합이 늘어 사각지대가 더 넓습니다. 그렇다면 온프레미스와 멀티 클라우드가 뒤섞인 현대적인 엔터프라이즈 환경에서, 사용자가 애플리케이션에 도달하기까지 전체 경로를 모니터링하고 지연이나 장애를 측정할 방법은 없을까요? 이번 포스팅에서는 구글 클라우드가 제안하는 Cloud Network Insights로 전체 네트워크 구간을 모니터링하고 측정하는 방법을 알아보겠습니다.
구간 별 데이터만으로는 장애 원인을 찾기 어려운 이유
과거에는 장애 구간을 순서대로 짚어 나갈 수 있었습니다. 사내 네트워크 장비와 전용 회선, 데이터센터를 차례로 확인하면 됐습니다. 클라우드 네이티브 기술 기반의 현대적인 애플리케이션은 다릅니다. 사용자와 애플리케이션 사이에 사내 네트워크뿐 아니라 SD-WAN, ISP, 인터넷, CDN, 여러 CSP와 SaaS가 놓여 있습니다. 경로가 길어진 만큼 성능 데이터도 여러 곳으로 흩어집니다.
네트워크가 여러 클라우드와 인터넷을 지나면 성능 데이터도 구간별로 흩어집니다. 사내 라우터와 스위치 상태는 SNMP 기반 도구에서 확인하면 되지만, 범위 밖 정보는 외부 사업자를 통해 알아봐야 합니다. 구글 클라우드의 트래픽 정보는 Cloud Monitoring과 VPC Flow Logs에 남습니다. 다른 클라우드와 SaaS의 상태는 각 사업자가 제공하는 콘솔에서 확인해야 합니다.
도구마다 수집하는 항목과 주기도 다릅니다. 장비 관리 도구는 CPU 사용률과 인터페이스 오류를 보여 줍니다. 플로 로그는 출발지와 목적지, 전송량을 기록합니다. 애플리케이션 성능 관리 도구는 서버와 코드의 처리 시간을 측정합니다. 각각의 데이터는 해당 구간을 이해하는 데 유용합니다. 하지만 사용자가 애플리케이션에 도달하는 전체 과정을 하나의 경로로 보여 주지는 못합니다.
장애를 두고 서로 다른 판단을 하는 이유
외부 네트워크의 모니터링 정보가 충분하지 않으면 서비스 지연이나 장애의 원인을 찾기 어렵고, 책임 소재를 가리기도 애매합니다. 문제 구간을 특정하지 못하면 모두가 각자의 입장에서 상황을 보게 됩니다.
애플리케이션 팀은 서버와 코드가 정상이라고 판단합니다. 네트워크 팀은 사내 장비와 회선에 이상이 없다고 답합니다. 외부 사업자도 자체 시스템에서는 장애를 발견하지 못했다고 설명합니다. 어느 한 팀의 판단이 반드시 틀린 것은 아닙니다. 각 팀이 서로 다른 위치에서 서로 다른 대상을 확인하기 때문입니다. 애플리케이션 팀은 서버 안쪽을 봅니다. 네트워크 팀은 조직이 관리하는 장비까지만 확인합니다. 외부 사업자는 자신의 서비스 영역만 조사합니다. 이 데이터를 하나로 연결하지 못하면 문제가 시작된 지점을 찾기 어렵습니다.
간헐적으로 발생하는 장애는 조사하기가 더 어렵습니다. 사용자가 문제를 신고한 뒤에는 네트워크 상태가 이미 정상으로 돌아왔을 수 있습니다. 장애 당시의 패킷이나 경로 정보가 남아 있지 않으면 같은 현상을 다시 재현해야 하는데, 이게 말처럼 쉽지 않습니다.
출발지부터 목적지까지 같은 기준으로 측정
이런 한계를 넘어서려면 사용자와 가까운 출발지에서 애플리케이션이 있는 목적지까지 같은 기준으로 측정해야 합니다. 전체 경로에서RTT와 패킷 손실, 지터, 경로 변경을 지속해서 수집하면 어느 구간부터 성능이 나빠졌는지 비교할 수 있습니다.
네트워크 정보만으로는 충분하지 않습니다. DNS 조회와 TCP 연결, TLS 협상, 서버 응답 시간도 함께 확인해야 합니다. 네트워크 수치는 정상인데 서버 응답이 늦다면 애플리케이션을 먼저 살펴봅니다. 특정 네트워크 홉부터 손실이 늘었다면 ISP나 외부 네트워크 구간을 우선 조사합니다.
실제 사용자 트래픽이 없는 시간에도 측정을 이어 가는 것이 중요합니다. 사용자가 접속한 뒤 로그를 수집하는 방식만으로는 장애를 미리 발견하기 어렵습니다. 능동형 합성 트래픽으로 경로를 계속 확인하면 업무 시작 전에도 문제를 찾을 수 있습니다. 장애 전후에 경로와 성능이 어떻게 달라졌는지도 확인할 수 있습니다.
이렇게 측정하면 된다는 것은 네트워크 관리자라면 대개 압니다. 문제는 이 방식을 현실에서 어떻게 시스템으로 만드느냐입니다. 대부분 이 질문 앞에서 막힙니다. 다행히 답은 있습니다. 지금부터 소개할 구글 클라우드의 Cloud Network Insights가 바로 그 답입니다.
Cloud Network Insights는 어떻게 사각지대를 줄이나?
Cloud Network Insights는 Network Intelligence Center에서 제공하는 서비스입니다. Broadcom의 AppNeta 기술을 바탕으로 멀티 클라우드와 하이브리드 환경의 네트워크 상태와 애플리케이션 성능을 모니터링합니다. Google Cloud는 2026년 2월 프리뷰로 공개한 뒤, 6월 8일 정식 출시(GA)했습니다.
Cloud Network Insights의 측정 범위는 구글 클라우드에 한정되지 않습니다. 다른 클라우드와 온프레미스, 지점, 인터넷 애플리케이션과 API로 이어지는 경로도 확인할 수 있습니다. 모니터링은 세 가지 관점으로 나눠 볼 수 있습니다.
- 네트워크 경로 모니터링: 네트워크 레이어 3·4에서 출발지와 목적지 사이의 홉을 보여 줍니다. 왕복 시간(RTT), 패킷 손실, 지터, 경로 변경을 측정해 지연이나 손실이 시작된 구간을 좁힙니다.
- 웹 경로 모니터링: 웹 애플리케이션과 API의 응답 상태를 확인합니다. DNS 조회와 TCP·TLS 연결 시간, HTTP 상태 코드, 전체 트랜잭션 시간을 측정합니다. 실제 브라우저 엔진과 스크립트로 전체 페이지와 사용자 흐름을 시험할 수도 있습니다.
- 에이전트 워크로드 모니터링: 에이전트와 외부 도구 사이의 연결성과 네트워크 성능을 합성 테스트로 확인합니다. 에이전트나API의 응답 저하가 네트워크 경로에서 비롯됐는지 조사할 데이터를 제공합니다. 사용자나 에이전트의 실제 요청이 없을 때도 합성 테스트를 실행하므로 서비스에 영향이 나타나기 전에 이상 징후를 발견할 수 있습니다.
모니터링 포인트와 중앙 제어 영역이 경로를 측정하는 방법
Cloud Network Insights가 어떻게 전 구간을 모니터링할까요? 답은 아키텍처에 있습니다. 구조는 모니터링 포인트(Monitoring Point)와 중앙 제어 영역으로 나뉩니다. 모니터링 포인트는 네트워크와 웹 애플리케이션을 시험하는 경량 소프트웨어 에이전트입니다. 컨테이너나 가상 어플라이언스 형태로 구글 클라우드와 다른 클라우드, 데이터센터, 지점에 배치합니다.
모니터링 포인트는 작고 반복적인 합성 트래픽을 보내고, 수집한 텔레메트리를 중앙 제어 영역으로 전달합니다. 중앙 제어 영역은 구글 클라우드에서 호스팅하고 AppNeta가 관리합니다.
네트워크 경로는 두 가지 방식으로 측정합니다. 단일 종단 방식에서는 모니터링 포인트가 URL이나 IP 주소, API 엔드포인트 같은 외부 대상을 시험하고 왕복 성능을 측정합니다. 양쪽 끝에 모니터링 포인트를 배치하는 이중 종단 방식에서는 방향별 지연과 지터를 측정하고, 오가는 경로가 다른 비대칭 라우팅까지 확인합니다.
수집한 성능 지표는 Cloud Monitoring으로 내보냅니다. 경로 변경과 모니터링 포인트의 연결 상태 변경, 경보 같은 이벤트는 Cloud Logging에서 확인합니다. 구글 클라우드 콘솔에서는 모니터링 포인트의 상태와 소프트웨어 버전을 봅니다. Cloud Monitoring 대시보드에서는 지연 시간과 패킷 손실, 지터 같은 주요 지표를 살펴보고 알림 정책과 채널을 설정합니다. 홉별 경로나 웹 트랜잭션 타임라인을 상세히 분석할 때는 AppNeta 화면을 사용합니다.
Gemini를 활용한 지능적인 장애 분석
네트워크 경로 모니터링 데이터는 장애 구간을 좁히는 데 쓰입니다. 패킷이 거친 홉과 각 구간의 지연·손실을 함께 보면, 내부 네트워크와 클라우드 연결, ISP 가운데 어디부터 조사할지 판단하기 쉽습니다. 직접 관리하지 않는 구간의 문제도 측정 데이터로 정리해 외부 사업자와 공유할 수 있습니다.
웹 경로 모니터링 데이터는 대응 팀을 가리는 데 쓰입니다. DNS 조회와 TCP·TLS 연결, 서버 대기, 다운로드 가운데 어느 단계에서 시간이 늘었는지 확인합니다. 병목이 네트워크인지 애플리케이션인지 드러나므로, 네트워크 팀과 애플리케이션 팀 가운데 어느 쪽이 먼저 대응할지 빠르게 정할 수 있습니다.
Gemini Cloud Assist와 연계하면 원인 분석이 더 빨라집니다. 운영자는 자연어로 Cloud Network Insights의 텔레메트리를 조회하고 다른 구글 클라우드 지표와 비교합니다. 여러 화면을 오가며 가설을 검증하던 시간을 줄일 수 있습니다. 지표와 로그는 Google Cloud Observability에 모이고 OpenTelemetry 생태계와도 연계되어, 기존 관측 체계에 붙이기 쉽습니다.
알림은 Cloud Logging의 경보와 이벤트 로그를 기반으로 구성합니다. Cloud Network Insights가 제공하는 템플릿이나 사용자 정의 로그 기반 정책을 사용하고, 이메일과 Slack, PagerDuty, SMS, Pub/Sub 같은 기존 Cloud Monitoring 알림 채널로 전달합니다.
멀티 클라우드 네트워크의 가시성을 확보하세요!
앞서 살펴본 바와 같이 Cloud Network Insights는 출발지부터 목적지까지 같은 기준으로 경로를 측정하고, 홉 단위로 장애 구간을 드러내며, Gemini로 원인 분석을 돕습니다. 조직이 직접 관리하지 않는 구간의 문제까지 데이터로 정리해 외부 사업자와 공유할 수 있습니다.
물론 가시성 확보는 경로를 측정하는 데서 끝나지 않습니다. 측정 결과를 담당 팀의 대응 절차와 연결해야 실제 복구 시간이 줄어듭니다. 모든 경로를 한 번에 감시하기보다, 결제와 인증, 데이터 복제처럼 장애 비용이 큰 핵심 여정부터 시작하는 편이 효율적입니다.
멀티 클라우드 장애 원인을 빠르게 찾는 모니터링 체계를 준비하고자 한다면 메가존소프트 문의 포털을 통해 상담을 신청해 주세요.
