조선시대에도 있었다? 네트워크 이중화와 분산 백업에서 배우는 사이버 레질리언스

IT 인프라의 핵심 과제는 단순히 빠른 시스템을 만드는 데 있지 않습니다. 장애가 발생해도 연결이 유지되고, 하나의 경로가 끊겨도 다른 경로로 전환되며, 중요한 데이터가 손실되더라도 다시 복구할 수 있어야 합니다.

이런 문제는 현대 IT에서만 등장한 것은 아닙니다. 조선시대에도 멀리 떨어진 곳의 긴급 상황을 빠르게 전달하고, 하나의 통신수단이 제 역할을 하지 못할 때 이를 보완하며, 국가의 중요한 기록을 여러 지역에 나누어 보관하기 위한 체계가 존재했습니다.

전국의 긴급 상황을 신속하게 전달하기 위한 봉수, 봉수의 한계를 보완하기 위해 운영한 파발, 국가의 핵심 기록을 여러 지역에 분산 보관하고 재난 이후 다시 복구한 사고(史庫)와 조선왕조실록이 대표적입니다.

물론 수백 년 전의 제도를 현대 IT 기술과 동일선상에서 비교할 수는 없습니다. 하지만 해결하려 했던 문제는 놀랄 만큼 비슷합니다. 

오늘날의 고가용성(HA), 이중화(Redundancy), 재해복구(DR), 그리고 궁극적으로 사이버 레질리언스(Cyber Resilience)가 해결하려는 문제이기도 합니다.

1. 봉수: 전국의 상태를 전달하는 조선의 통신 네트워크

전화도 인터넷도 없던 시대에 국경에서 발생한 긴급 상황을 한양까지 빠르게 전달하려면 어떻게 해야 했을까요?

조선은 봉수(烽燧)라는 전국적인 통신체계를 운영했습니다.

봉수는 주요 산봉우리의 봉수대를 연결해 낮에는 연기, 밤에는 횃불로 정보를 전달하는 방식이었습니다. 각 봉수대는 인접한 봉수대의 신호를 확인한 뒤 다시 다음 봉수대로 전달했고, 이렇게 연결된 정보가 최종적으로 한양까지 도달했습니다.

세종 때에는 지방에서 한양으로 연결되는 봉수 체계가 정비됐고, 한양의 목멱산, 현재의 남산은 전국에서 올라오는 신호를 받는 중앙 봉수대 역할을 했습니다.

| 단순한 ON/OFF가 아니었던 5단계 상태 정보

봉수는 단순히 불을 켜고 끄는 방식도 아니었습니다.

상황에 따라 신호를 5단계로 구분했습니다. 평상시에는 1개, 적이 나타나거나 접근하고 국경을 넘거나 실제 전투가 벌어지는 등 상황이 심각해질수록 신호의 수를 늘렸습니다.

현대 IT에 그대로 대응시킬 수는 없지만, 개념적으로 보면 꽤 흥미롭습니다.

각 지역의 상태를 감지하고 일정한 규칙에 따라 상태 정보를 표준화한 뒤 여러 노드를 거쳐 중앙으로 전달한다는 점에서는 오늘날의 네트워크 모니터링과 이벤트·알람 체계를 떠올릴 수 있습니다.

현대의 네트워크 관리 시스템 역시 장비와 회선의 상태를 지속적으로 확인하고 CPU·메모리·트래픽·인터페이스·서비스 상태 등의 이벤트를 중앙 관리 시스템으로 전달합니다.

오늘날 네트워크 가시성(Visibility)과 모니터링이 중요한 이유도 여기에 있습니다. 장애 대응의 시작은 결국 장애가 발생했다는 사실을 얼마나 빨리 인지하느냐이기 때문입니다.

2. 봉수가 멈추면 파발로: 하나의 통신 방식에 의존하지 않는다

아무리 잘 설계된 통신체계라도 단일 방식에는 한계가 있습니다.

봉수 역시 마찬가지였습니다.

봉수는 빠르고 효율적이었지만 연기와 횃불이라는 시각적 신호에 의존했습니다. 때문에 구름이나 안개가 짙으면 신호를 확인하기 어려웠고, 전쟁 중 봉수대가 파괴되거나 중간 전달 과정이 끊어지면 정보 전달에도 문제가 발생했습니다.

또 하나의 중요한 한계는 전달할 수 있는 정보량이었습니다.

5단계 신호를 통해 긴급도는 빠르게 전달할 수 있었지만, 적군의 규모나 이동 방향, 아군의 피해 상황과 같은 상세 정보를 전달하기에는 한계가 있었습니다.

임진왜란에서는 이러한 문제가 실제로 드러났습니다. 전쟁 초기 봉수가 제대로 작동하지 않고 일부 봉수대가 파괴되면서 통신 기능에 문제가 발생했고, 이를 보완하기 위한 통신수단으로 파발(擺撥)의 필요성이 커졌습니다. 이후 조선은 봉수와 파발을 함께 운영했습니다.

| 봉수와 파발은 서로 다른 특성을 가진 통신수단

봉수는 짧고 정형화된 정보를 빠르게 전달하는 데 강점이 있었습니다.

반면 파발은 사람이 말을 타거나 직접 이동하면서 문서를 전달했기 때문에 속도와 비용 측면에서는 봉수와 다른 특성을 가졌지만, 훨씬 많은 정보를 구체적으로 전달할 수 있었습니다.

따라서 이를 현대 IT에 비유한다면 단순한 Active-Standby 장비 이중화라기보다,

정도로 이해하는 것이 적절합니다.

| 빠른 네트워크보다 중요한 것은 ‘끊겨도 이어지는 네트워크’

기업의 네트워크에서 고가용성을 확보하려면 단순히 고성능 장비를 도입하는 것만으로는 부족합니다. 
시스템 구성 요소 중 하나만 문제가 생겨도 전체 시스템이 중단되기 때문입니다. 

따라서 중요한 서비스는 일반적으로 다음과 같은 방법을 이용해 장애 영향을 줄입니다.

• 네트워크 장비 이중화
• 복수의 통신 회선 구성
• Active-Active 또는 Active-Standby 구성
• 서버 및 애플리케이션 이중화
• 데이터센터 간 서비스 분산
• 장애 발생 시 정상 자원으로의 Failover

 

특히 ADC(Application Delivery Controller)는 여러 서버의 상태를 지속적으로 확인하는 Health Check를 수행하고, 정상 상태인 서버로 트래픽을 분산합니다.

특정 서버가 장애 상태로 판단되면 해당 서버를 서비스 대상에서 제외하고 정상 서버로 요청을 전달함으로써 애플리케이션 서비스의 연속성을 높일 수 있습니다.

서비스 범위가 데이터센터 단위로 확대되면 GSLB(Global Server Load Balancing)를 통해 여러 사이트 또는 데이터센터의 상태를 기반으로 사용자의 요청을 정상 사이트로 전달하는 구성도 가능합니다.

3. 조선왕조실록: 분산 백업은 실제 재난에서 효과가 있었을까?

네트워크가 끊기지 않는 것만큼 중요한 문제가 있습니다.

바로 데이터를 잃지 않는 것입니다.

기업의 핵심 데이터가 하나의 서버나 하나의 데이터센터에만 존재한다면 화재, 침수, 정전, 랜섬웨어, 스토리지 장애와 같은 사고가 발생했을 때 심각한 데이터 손실로 이어질 수 있습니다.

조선에서도 비슷한 고민을 했습니다.

국가의 핵심 기록인 『조선왕조실록』을 한 장소에만 보관하지 않았습니다.

조선 전기에는 춘추관을 비롯해 충주·성주·전주 등 여러 사고(史庫)에 실록을 나누어 보관했습니다. 하나의 장소가 아니라 지리적으로 떨어진 여러 장소에 중요 기록을 분산시킨 것입니다.

현대 IT의 개념으로 표현한다면 완전히 동일한 기술은 아니지만 지리적 분산(Geo-Redundancy) 또는 Off-site Backup에 가까운 사고방식입니다.

임진왜란이라는 대규모 Disaster

그리고 1592년, 이 분산 구조는 실제 재난을 맞았습니다.

임진왜란으로 춘추관·충주·성주 사고의 실록은 소실됐습니다.

네 곳 가운데 전주사고본만 살아남았습니다.

전주 지역까지 전쟁의 위협이 다가오자 전주사고의 실록은 정읍 내장산 등 안전한 장소로 옮겨졌고, 이후 여러 장소를 거치며 보존됐습니다.

만약 모든 실록이 한곳에 보관되어 있었다면 조선 전기의 국가 기록 상당 부분이 한 번의 재난으로 사라졌을 가능성이 있습니다.

IT 관점에서 보면 매우 익숙한 문제입니다.

동일한 데이터의 복사본을 여러 개 만들어 놓더라도 같은 서버, 같은 랙, 같은 건물 또는 동일한 재난 영향권 안에 있다면 진정한 재해 대비라고 하기 어렵습니다. 화재나 침수, 대규모 정전처럼 장애 범위가 확대되면 백업본까지 동시에 영향을 받을 수 있기 때문입니다.

4. 백업의 목적은 보관이 아니라 ‘복구’다

조선왕조실록 사례가 흥미로운 이유는 단지 전주사고본이 살아남았기 때문만은 아닙니다.

살아남은 기록을 이용해 실제로 복구했기 때문입니다.

전쟁 이후 조선은 전주사고에 남아 있던 실록을 바탕으로 실록을 다시 인쇄했고, 복구된 실록은 다시 여러 사고에 분산 보관됐습니다.

바로 이 지점에서 백업(Backup)과 재해복구(Disaster Recovery)의 차이가 드러납니다.

백업은 데이터의 복사본을 확보하는 것입니다.

하지만 DR은 재난 발생 이후 업무와 서비스를 실제로 다시 운영 가능한 상태로 만드는 것까지 포함합니다.

따라서 백업 파일이 존재한다고 해서 DR이 완성되는 것은 아닙니다.

5. DR의 완성은 Failover에서 끝나지 않는다

실제 DR 환경에서는 데이터를 복구하는 것과 함께 서비스 트래픽을 정상 시스템으로 전환하는 과정도 중요합니다.

예를 들어 주 데이터센터에 장애가 발생했다면 DR 센터에 서버와 데이터가 준비돼 있더라도 사용자 요청이 계속 장애가 발생한 센터를 향하고 있다면 서비스를 정상적으로 제공할 수 없습니다.

따라서 데이터 복제와 인프라 복구뿐 아니라 서비스 경로를 함께 전환할 수 있어야 합니다.

파이오링크는 이러한 서비스 연속성을 위해 ADC와 HCI 기반의 인프라를 활용할 수 있습니다.

ADC는 개별 서버와 애플리케이션의 상태를 확인해 장애 자원을 서비스 대상에서 제외하고 정상 서버로 트래픽을 전달합니다.

ADC의 서버 부하분산(SLB) 기능은 범위를 사이트 또는 데이터센터 수준으로 확대(GSLB)합니다. 각 사이트의 서비스 상태를 확인하고 정책에 따라 정상 데이터센터로 사용자 요청을 전달함으로써 센터 장애 상황에서도 서비스 접근 경로를 유지할 수 있습니다.

HCI 기반 DR 환경에서는 VM과 데이터를 다른 사이트에 복제하고 장애 발생 시 DR 사이트에서 워크로드를 기동할 수 있습니다.

그리고 주 센터가 복구된 이후에는 데이터를 다시 동기화하고 서비스를 원래 환경으로 되돌리는 Failback까지 고려해야 합니다.

따라서 실질적인 DR 체계는 단순한 백업 장비나 복제 기능 하나가 아니라 데이터 + 컴퓨팅 + 네트워크 + 애플리케이션 전송 전체를 함께 설계해야 합니다.

6. 장애를 막는 것에서, 장애를 견디는 인프라로

전통적인 IT 운영의 목표는 장애를 최대한 발생하지 않도록 하는 것이었습니다.

물론 예방은 여전히 중요합니다.

하지만 시스템이 복잡해지고 하이브리드 클라우드와 멀티클라우드, AI 인프라까지 등장하면서 모든 장애와 공격을 완벽하게 차단한다는 것은 현실적으로 어렵습니다.

장비는 고장날 수 있고, 회선은 끊길 수 있습니다. 소프트웨어에는 결함이 있을 수 있으며 사이버 공격도 끊임없이 변화합니다.

그래서 이제는 “어떻게 장애를 완전히 없앨 것인가?”뿐 아니라,

가 더욱 중요한 질문이 되고 있습니다.

이것이 사이버 레질리언스(Cyber Resilience)의 핵심입니다.

파이오링크가 지향하는 사이버 레질리언스 역시 네트워크와 보안, 인프라를 개별 장비의 관점에서만 바라보지 않습니다. 장애와 사이버 공격을 예측하고 예방하는 것에서부터 영향을 최소화하고, 서비스와 데이터를 복구하고, 다시 정상적인 비즈니스 상태로 돌아가는 전체 과정을 바라봅니다.

연결하고, 우회하고, 복구한다

조선의 봉수와 파발, 그리고 조선왕조실록의 사례를 현대 IT 기술과 그대로 비교할 수는 없습니다.

하지만 수백 년의 시간 차이에도 불구하고 해결하려 했던 문제에는 공통점이 있습니다.

오늘날 IT 인프라도 결국 같은 질문에 답해야 합니다.

연결되어 있는가?
하나가 멈춰도 다른 경로로 이어질 수 있는가?
그리고 시스템이 무너져도 데이터와 서비스를 다시 복구할 수 있는가?

고가용성, 이중화, 백업, DR은 서로 다른 기술처럼 보이지만 궁극적인 목적은 하나입니다.

수백 년 전 중요한 정보와 기록을 지키기 위해 여러 전달 경로와 보관 장소를 고민했던 것처럼, 오늘날의 IT 인프라 역시 장애를 피하는 것에서 한 걸음 더 나아가 장애를 견디고 다시 회복할 수 있는 구조를 준비해야 합니다. 그것이 ‘멈추지 않는 IT’, 그리고 사이버 레질리언스입니다.

ve-Active