재해복구

재해복구(DR; Disaster Recovery)란, 각종 재해 및 위험요소에 의해 정보시스템이 중단됐을 때 이를 정상으로 회복시키는 것을 의미한다. 영어 약자인 디알(DR)이라고 하는 경우가 많다. IT에서의 재해는 사전적 의미를 벗어나 지진, 태풍, 홍수, 화재 등의 자연재해 및 테러로 인한 폭파, 전쟁, 해킹, 통신장애, 전력공급차단 등 외부요인에 의한 재해, 그리고 시스템 결함, 기계적 오류, 관리정책 오류, 사용자 실수 같은 내부적 요인에 의한 장애 등 다양한 사례를 포함한다.

개요

공공부문 정보화 사업의 확산으로 인한, 다수의 정보 시스템이 많은 곳에 도입되었고 이를 통해 각 기관은 내부 업무 프로세스 및 대면 서비스 등을 정보시스템을 통해 수행하고 있따. 업무의 정보시스템 의존도가 높아짐에 따라 정보시스템 중단사태가 발생할 경우 기관 전체의 업무가 마비될 수도 있는 심각한 위험성을 겪을 수 있는 상황에 이르렀다. 2001년에 발생한 미국의 9.11 태러사태 이전까지만 해도 국내의 재해재난에 대한 정보시스템 대비책은 극히 미약한 실정이었으나 최근 국내외 각종 사고사례가 증가되면서 이에 대한 대비책 마련은 필수 사항으로 자리매김되었다. 재해 예방 및 복구 방식에는 여러 종류가 있는데 각 기관의 설정에 맞는 적절한 재해 예방 및 복구방식을 선택하는 것이 중요하다. 재해복구를 위해서는 사전에 재해복구를 위한 계획 및 이를 지원하는 시스템이 준비되어야 하는데, 이를 각각 재해복구계획 및 재해복구시스템이라 일컫는다.

핵심 용어

• 백업(backup) : 백업은 데이터 복구의 핵심 구성 요소이다. 백업은 데이터의 특정 시점 복사본을 만드는 것이다. 데이터는 비구조적일 수도, 구조적인 데이터일 수도 있다. 백업은 파일, 블록 또는 이미지 기반일 수 있다. 각 백업 유형마다 장단점이 있다.

• 비즈니스 연속성(BC; Business Continuity) : 비즈니스 연속성은 '비즈니스 회복성'이라고도 하며, 광범위한 형태의 데이터 보호를 지칭한다. '재해복구'의 경우와 마찬가지로 데이터와 IT 서비스의 복원을 포함하지만 재해 중 비즈니스 운영을 지속하기 위한 프로세스와 절차도 포함한다.

• 지속적 데이터 보호(CDP; Continuous Data Protection) : 지속적 데이터 보호는 '지속적 백업' 또는 '실시간 백업'이라고도 하며, 데이터에 대한 모든 변경의 복사본을 자동으로 저장하여 IT 관리자가 어느 시점으로든 데이터를 복원할 수 있도록 하는 데이터 백업을 의미한다.

• 고가용성(HA; High Availability) : 고가용성은 재해 중 비즈니스를 지속하는 데 도움이 될 수 있는 기술의 특성이다. HA 기술은 프로덕션 시스템의 예비성을 제공하여 하나가 실패하면 다른 하나로 신속하게 '페일오버(failover)'해서 원래 시스템을 대체한다. 손상에 대비한 보호 기능은 제공하지 않는다. 고가용성은 전혀 다른 요구 사항을 충족하기 위한 기술이므로 견고한 DR 전략의 대체제로 간주해서는 안된다.

• 복제(Repllication) : 복제는 재해 발생시 IT 관리자가 최신 데이터를 복원할 수 있도록 한 위치에서 다른 위치로 데이터를 복사하는 프로세스이다. 동기 복제 솔루션은 주 스토리지와 복제 사이트에 동시에 데이터를 써서 주 복사본과 복제본이 항상 동기화되도록 한다. 비동기 복제 솔루션은 이와 달리 먼저 주 스토리지에 데이터를 쓴 다음 데이터를 복제 사이트로 복사한다. 이 경우 복제는 예약에 따라 실시되는 경우가 많다. 비동기 복제는 비용이 덜 들고 대역폭이 덜 필요하며 장거리에 걸쳐 사용할 수 있다. 동기 복제는 핵심 애플리케이션의 고가용성을 제공한다. 주 스토리지에서 복제본으로의 페일오버는 거의 즉각적으로 이뤄지므로 사용자가 경험하는 다운타임은 제로에 가깝다.

요소 및 절차

1. 복구 제도 : 재해 발생시 복구시점까지의 단계별 시스템 유지 수준에 따른 역할 분담 및 업무 범위 책정을 제도적으로 마련한다. 전사적 합의가 필요하다.
2. 복구 조직 : 재해 발생시 체계적인 대처로 최단 시간에 업무 정상화를 꾀할 수 있는 조직을 구성한다. 때에 따라서는 인력 자원이 필요하다.
3. 복구 시스템 : 재해 복구를 위한 기반 시설로서 장소, 시스템, 네트워크 등의 전산 인트라를 구축한다. 높은 비용의 투자가 필요하다.
4. 복구 계획 및 절차 : 업무 중요도 및 우선 순위 파악 후 평상시 백업 요구수준을 책정하며 재해 발생 요인 및 상황에 따른 대처 방안을 마련한다.
5. 데이터 백업 : 정보시스템 현황에 알맞은 백업 정책을 구성하여 효과적인 재난 대비 복구시스템을 구축 한다. 백업 방식(유형)을 결정한다.
6. 백업 관리 : 백업 작업에 대한 확인 및 데이터 정합성을 파악한며 주기적인 백업 데이터 소산 작업을 실시한다. 유사시를 대비한 백업 데이터 신뢰도 검증 작업이다.
7. 복구 테스트 : 백업 데이터 확인을 통한 복구 테스트를 실시하여 재난 발생 시 소요되는 시간 및 문제점을 사전에 확인 조치 할 수 있어야 한다. 모의 훈련을 실시하는 방법이 있다.
8. 사후 점검 및 확인 : 재난 및 장애 상황 분석, 효과적인 대처 방안을 마련하고, IT 재해 복구 체재 최적화 작업을 실시한다. 필요시 복구계획 및 절차를 수정한다.

재해복구 계획 수립

1. 내부 시스템 감사

   조직의 모든 활동과 자원을 평가해 IT시스템과 애플리케이션 기능을 완전히 이해해야 한다. 모든 중요한 기능, 시스템, 애플리케이션을 파악하고 각각이 멈췄을 때 비즈니스에 미치는 영향을 설명하는 비즈니스 영향 분석(BIA)을 개발하고, 모든 문제가 다뤄지도록 조직의 모든 부서에 대한 의견을 구해야 한다.

2. 외부 공급 업체 확인

   조직에서 사용하는 데이터나 애플리케이션을 호스팅하는 써드파티 업체와 서비스 수준 협약(SLA)을 검토해 해당 서비스와 관련한 모든 문제의 영향을 이해해야 한다. 각 공급 업체와 잠재적인 문제의 위험을 평가하고 운영에 중요한 공급 업체 손실에 대비한 비상 계획과 전략을 수집한다.

3. 취약점 이해

   잠재적 취약성 영역과 운영 절차에서 전력에 이르기까지 조직에 피해를 줄 방법을 문서로 작성한다. 다른 유형의 피해는 없는지도 확인한다. 인간의 실수, 자연재해, 정전, 사이버 공격, 소프트웨어 문제, 하드웨어 고장은 혼란을 야기할 수 있다. 이러한 각각의 발생 위험, 그들이 가질 수 있는 영향 및 복구해야 할 것이 무엇인지 문서로 만들어야 한다. 위험 요소로는 가동 중지 시간, 고객 손실, 생산성 감소, 수익 손실, 명예훼손 및 회복 비용이 포함된다.

4. 카탈로그 시스템 및 서비스

   IT인벤토리 구성 요소에 대한 모든 정보를 상세하게 추가한다. 보증 기간 만료일, 위치, 버전 번호, 설치 또는 구매 날짜, 필수 및 지원 장비의 최신 업데이트도 반드시 넣어야 한다. 영향이 미치기 전에 각 구성요소를 복구해야 하는 상태(복구 시점 목표(RPO), 이를 수행하기 위한 목표 시간(복구 시간 목표), 최대 허용 가능 중단 시간(MTD)를 정한다.

5. 위험 경감

   적절한 지원 시스템 및 전략을 수립하면 파악할 수 있는 위험을 줄일 수 있다. 여기에는 데이터 백업 및 IT자산 정기 점검이 포함됀다. 바이러스 백신 소프트웨어, 네트워크 모니터링, 직원 교육 같은 조치로 잠재적인 위협을 발견하고 중요한 데이터와 애플리케이션을 보호하는 중복 저장으로 손상을 안화한다.

6. 재해복구계획 문서화

   재해복구계획엥는 핵심 기능을 복구 및 복원하는 단기 계획과 전체 IT 역량으로 복귀하는 과정에서 어떤 측면을 처리할 것인지를 우선시하는 것이 계획에 모두 퐇마돼야 한다. 모든 자산에 대해 필요한 시간 내에 복구 목표를 달성하는 방법에 대한 전략을 수집한다. 여기에는 복구 프로세스의 일부로 연락해야 할 모든 공급 업체의 연락처 정보도 있어야 한다. 사고 대응 프로세스의 일환으로 가능한 한 모든 시간대를 백업하고 실행하는 프로세스를 수립해야 한다. 이로 인해 기존 시스템이 강화되거나 새로운 도구가 배포될 수 있다. 현 직장이 사용할 수 없는 경우에 대비하여 임대할 수 있는 대체 사무실 공간을 확인하고 기존 보험이 적절한지도 확인해야 한다.

7. 직원 교육

   계획을 모든 직원에게 알리고 재해복구계획에 따라 책임을 이해하며 이행할 수 있도록 공식적인 교육을 마련해야 한다. 교육은 정기적으로 이뤄져야 하며, 회복 가정에서 직원의 역할에 영향을 미치는 계획이 변경될때마다 수행해야 한다.

8. 재해복구계획 테스트

   정기적으로 재해복구계획을 테스트하여 백업 소프트웨어부터 공급 업에 연락처 등 세부 정보에 이르기까지 다양한 기술 측면이 필요에 따라 작동하는지 확인해야 한다. 테스트는 모든 백업과 복구 절차를 평가하고 수정해야 할 부분을 파악한다.

9. 업데이트

   기술과 비즈니스는 끊임없이 진화하기 때문에 개발을 고려해 계획을 수립해야 한다. IT환경이나 조직에 변화가 잉쓰면 시스템이나 직원에게 재해복구계획을 업데이트하도록 알려야 한다. 일단 재난이 발생했다면 재해복구계획을 적용한 결과를 검토하고 부족한 부분을 개선해야 한다. 계획이 모든 개정 사항을 문서 앞부분의 별도 섹션에서 넣고 이후 꾸준히 모니터링 해야 한다.

재해복구시스템

유형

구축형태별 구분

• 독자구축 : 재해복구시스템을 독자적으로 구축하는 방식으로, 보안유지 및 복구의 신뢰성이 가장 높으나, 구축 및 유지비용이 가장 많이 소요된다. 비교적 규모가 큰 금융기관 등에서 주로 채택하고 있는 방식이다.
• 공동구축 : 두 개 이상의 기관이 재해복구시스템을 공동으로 이용하는 방식이다. 비용측면에서 독자구축의 경우보다 적게 소요되지만 봉나과 운용측면에서는 고려할 사항이 많고, 광역재해 발생시 공동이용기관간의 동시 재해복구가 불가능하다는 단점이 있다. 이 방식에서는 공동이용기관의 합의가 매우 중요하다.
• 상호구축 : 별도의 재해복구시스템을 구축하는 대신, 두 개 이상의 기관이 상호간의 재해복구시스템의 역할을 수행하거나, 단일 기관이 여러 개의 정보시스템 사이트를 가지고 있는 경우에는 사이트 상호간에 서로 재해복구센터의 역할을 수행하도록 하는 방식이다. 구축 및 운영비용이 저렴한 장점이 있으나 서로 다른 기관과의 이러한 방식의 재해복구시스템을 구축하는 경우 보안성 및 재해복구에 대한 신뢰성이 대단히 낮다.

운영주체별 구분

• 자체운영 : 기관 자체의 인력으로 재해복구시스템을 운영하는 방식이다. 보안성 및 신뢰성이 가장 높으나, 재해복구를 위한 추가의 인력이 확보되어야 하며 운영비용이 높다. 일반적으로 독자구축 형 재해복구센터에서 사용되는 운영방식이다.
• 공동운영 : 두 개 이상의 기관이 재해복구시스템의 운영인력을 상호 공유하는 방식이다. 일반적으로 공동구축형 또는 상호구축형 재해복구시스템에서 사용되는 운영방식이다. 자체운영에 비해 운영비용을 절감할 수 있으나, 기관간 신뢰가 전제되어야 하고, 보안성 유지를 위한 협의가 중요하다.
• 위탁운영 : 재해복구시스템의 운영을 민간 IDC 운영자 등 외부의 다른 기관에 위탁하는 방식이다. 정보시스템 운영기관의 보안성 유지가 가장 큰 문제로 대두되나, 위탁 운영 업체의 보안 유지에 대한 신뢰성이 높다면 전문적인 재해복구서비스를 제공받을 수 있으며 초기투자 비용이 적게 드는 장점이 있어, 최근 사용이 증가하는 추세에 있다. 미국의 대형금융기관 및 공공기관 등에서 이러한 형태의 사용 예를 볼 수 있다.

복구수준별 유형

• 미러 사이트(Mirror Site) : 주요 운영 시스템 DBMS에 대한 실시간 미러링으로 주센터와 백업센터간 동일한 시스템 이미지 구성 및 데이터 손실이 없어 재해/장애 발생시에도 영향이 없는 복제 시스템을 구성한다. 또한 주 센터 및 백업센터간 네트워크 이중화 구성을 통해 신속한 복구가 가능하다. 말단 사용자는 장애 상황을 알 수가 없다.
• 핫 사이트(Hot Site) : 미러 사이트와 거의 동일한 방식이나 시설 측면에서 완벽한 이중화는 아니고, 주 센터와 백업센터간의 DB를 직접 이중화하는 방안이다. 백업센터에서 LOG를 적용하여 DB를 갱신하는 시간이 소요된다.
• 웜 사이트(Warm Site) : 주기적으로 시스템 및 데이터 백업 테이프를 로컬이나 원격지에 보관 및 소산하는 방식으로 전통적인 백업 방식이다. 저비용 구성이 가능하고 대부분의 테이프(TAPE) 및 디스크(DISK) 백업 방식이 여기에 속한다.
• 콜드 사이트(Cold Site) : 주요 업무에서 발생되는 데이터, 원격지 배치(Batch)형 작업 및 비 실시간 백업으로 처리한다.

구현 기술

H/W적 복제 방식

• 디스크 장치를 이용한 복제 : 자료가 최종적으로 저장되는 디스크를 복제 대상으로하여, 사용중인 원본 디스크를 원거리 지역의 복구용 디스크로 복제하는 방식이 바로 디스크 수준의 복제 방식이다. 주 센터의 원본 디스크와 재해복구센터의 복구용 디스크는 기본적으로 마이크로코드(Microcode 2) 수준에서 완벽한 호환성을 제공하여야 하지만, 디스크에 별도의 가상화 솔루션 등을 활용한다면 이기종 디스크 간에도 복제가 가능하다. 디스크 장치를 이용한 복제방식의 구성 시, 최초에는 디스크 전체를 대상으로 복제 작업을 수행하므로 많은 시간이 소요되나, 이후 운영 시에는 디스크의 변경분만을 복제하므로, 고속 복제가 가능하다.

S/W적 복제 방식

• 운영체제를 이용한 복제 : 데이터를 디스크에 저장, 관리하기 위한 논리적인 볼륨을 만들어 사용한다. 즉, 데이터는 논리적 볼륨에서 관리, 전송되어 이것이 물리적 디스크에 저장되는 것이다. 운영체제를 이용한 복제 방식은 서버에서 디스코로 데이터를 전송하고 저장하는 중간 단계에서 데이터 블록을 복제하여 재해복구센터로 보내는 방식이다. 따라서 운영체제를 이용한 복제 방식에는 주 센터와 재해복구센터의 양쪽 서버에 데이터의 복제를 관리하기 위한 동일한 복제솔루션을 설치하여야 한다. 복제솔루션은 해당 서버 자체에서 수행되거나, 별도의 디스크 관리 서버 자원을 사용하여 수행될 수 있다 그러므로 재해복구시스템 구축 시 기존의 운영환경의 용량 및 부하를 감안하여 서버 자원의 적정성을 검토하여야 한다. 일반적으로 중간 정도의 성능과 용량의 디스크를 사용하거나, 이기종 디스크를 사용하는 운영환경에서 재해복구시스템을 구축하는 경우에 주로 사용된다.
• DBMS를 이용한 복제 방식 : 주 센터의 DBMS에서 사용되는 SQL(Structured Query Language)문 혹은 변경 로그를 원격 사이트의 DBMS에 전송하여 복제하는 방식이다. 주 센터와 재해복구센터의 DBMS 및 복제 솔루션이 동일하여아 하며, 디스크, 논리적 볼륨 및 플랫폼의 종류가 다르더라도 구현이 가능하다. 또한, DBMS를 이용한 복제 솔루션은 주 센터와 재해복구센터 서버의 자원을 사용하여 동작하므로 서버 자원의 증설을 검토하여야 한다.

데이터 전송 방식

데이터 복구 시스템에서는 데이터 복제방식과 더불어 데이터전송 방식을 알맞게 혼합하여 현 시스템과 재해복구 수준에 최적화된 재해복구시스템을 구축하는 것이 중요하다. 핮지만, 주센터 운영시스템에서의 실수나 오류로 인한 잘못된 데이터의 추가 및 변경도 재해복구센터에 동일하게 복제되어 주센터의 논리적 데이터 오류에 의한 장애시 원격지에서도 동일한 장애가 발생하게 된다. 따라서 재해복구시스템만 구축되면 모든 장애와 재해를 막을 수 있는 것은 아니다.

Sync(동기 복제)

Sync 방식은 어떠한 상황에서도 완벽한 데이터 복구를 보장하여 준다. 이 방식은 사용자 혹은 작업이 주센터의 운영 시스템에서 데이터를 추가 혹은 변경하였을 경우 주센터뿐 아니라 재해복구센터에서도 정상적으로 추가 혹은 변경이 완료 되었다는 것을 시스템에서 확인한 후에 사용자 혹은 직업에게 추가 혹은 변경 완료신호를 보내게 되는 방식이다. 따라서 주센터와 재해복구센터간의 데이터 정합성은 항상 유지되므로 가장 안전하고 신뢰성이 높은 방식이다. 그러나, 주센터와 재해복구센터 간을 연결하는 고속의 회선이 필요하다. 왜냐하면, 주센터 뿐 아니라 재해복구센터에 있는 데이터 역시 빠른 시간 내에 추가, 변경하여야 응답속도의 지연을 막아 기존의 서비스 수준을 유지할 수 있기 때문이다. 결국 이러한 요구는 고속회선을 위한 많은 회선 비용과 주센터와 재해복구센터간의 거리 제한을 가져올 수 있다. 또한 주센터와 재해복구센터간의 회선 장애 혹은 재해복구시스템의 장애 및 운영 실수는 즉시 주센터의 운영 시스템에도 영향을 미치어 서비스 장애로 이어질 수 있다. 따라서 재해복구시스템 유지 관리의 어려움과 운영수준 유지를 위한 인력, 비용이 추가로 발생하게 된다.

ASync(비동기 복제)

Async 방식의 가장 큰 특징은 Sync 방식과 달리 재해복구시스템을 구축하여 데이터를 복제하더라도 기존 운영 서비스의 성능에 거의 영향을 주지 않는다는 것이다. 재해복구시스템을 Async 방식으로 구축하면 기존 운영 서비스는 기존과 동일하게 동작하고, 데이터 복제는 기존 운영 시스템의 서비스와는 별도로 디스크, 서버 및 DbMS 수준의 전송방식에 따라 운영 서비스 이후 독립적으로 동작된다. 즉, 데이터 복제를 수행하기는 하나 그것이 언제 수행되는지는 재해복구를 위한 시스템의 환경 및 여러 조건에 따라 정해진다. 하지만, Sync 방식에 비해 현 시점에서 운영시스템의 100% 데이터 복제를 보장하지는 못한다.

시스템 구축

운영 상황에 맞는 재해복구시스템 설계가 완료되면 시스템 구축을 수행하게 된다. 올바른 구축 실행을 위해서는 다음과 같은 순서에 맞추어 구축 계획 및 실행을 검토해야 한다.

일정 및 방안 수립

실행 전에 주요 계획가 일정(Mile Stone) 및 범위를 확정하여 계획이 수립되었는지 확인하고 이에 따른 관리를 실행한다.

재해복구 체계구현

• 사전 준비 : 구축 꼐획에 따른 제한복구시스템을 위한 장비의 발주, 네트워크 구성, 기존시스템 복제 방법 및 절차, 담당 인력 및 업무의 분장 등이 준비되고 있는지 확인한다.
• 데이터 복제 : 재해복구시스템을 구축하기 위해서는 기존 데이터의 복제가 필요하다. 이를 수행하기 위한 방법에는 재해복구시스템을 주센터에 구축하여 복제 후 재해복구센터로 재해복구시스템을 옮기는 방법과 재해복구시스템을 재해복구센터에 구축 후 복제를 하는 방법이 있다.
• 기능 점검 : 최초의 데이터 전체를 복제하고 환경 설정이 완료되어 재해복구시스템이 구축되면, 재해복구 솔루션의 복제 및 복구 기능이 정상 작동하는지를 테스트하여야 한다.

테스트

• 테스트 시나리오 작성 : 재해복구 기능 및 데이터 정합성을 세밀하게 테스트할 수 있는 유형별, 상황별 테스트 시나리오를 작성해야 한다.
• 단위/통합 테스트 : 운영환경에서 계획된 시나리오에 의한 재해발생, 재해분석보고, 복구시스템으로 전환 등과 같은 절차에 의한 복구 전환 테스트를 실시한다.

운영관리/완료 보고

재해보구 운영체계에 대한 훈련 및 운영 메뉴얼, 재해복구 모의훈련 계획서 등의 필요한 문서를 제공하고 인수인계 및 완료보고를 실시한다.

고려사항

• RTO(Recovery Time Objective) : RTO란 각 업무별로 서비스 중단을 감내할 수 있는 시간을 정의하는 것으로, RTO가 규정으로 정해져 있는 기관들도 있지만 그렇지 못한 기업이나 기관들은 업무 중단에 따른 손실 비용과 기업의 연속성에 어떠한 영향을 끼칠지 감안해 이를 설정해야 한다. 각 업무별 RTO에 대한 정의가 끝나면 이와 연관된 IT 자원들이 어떻게 구성돼 있으며, 이에 대한 각 요소들의 복구 절차와 RTO에 대한 정의가필요하다.
• RPO(Recovery Point Objective) : RTO에 대한 정의가 완료되면 복구시점에 대해 정의해야 한다. 이를 RPO라고 한다. 복구할 데이터의 중요도에 따라 RPO는 바로 재해 직전, 1시간, 3시간, 하루, 일주일, 한 달 등 다양한 시점이 나올 수 있다. RPO=0이 가장 이상적이겠지만 문제는 비용이다. 이는 솔루션에 대한 비용뿐만 아니라 운영센터와 재해복구센터 간 데이터를 손실 없이 동기화하기 위해 필요한 큰 네트워크 대역폭으로 인해 발생하는 과도환 회선 비용, 네트워크 장비 등에 대한 유지비용을 불러오기 때문이다. 따라서 어붐와 데이터의 중요도에 따라 RPO를 정의해야 한다.

참고자료

• 정종길 기자, 〈(기획특집) '선택'아닌'필수', DR시스템〉, 《컴퓨터월드》, 2016-09-29
• 퀘스트소프트웨어, 〈재해 복구(DR) 관련 핵심 용어 정리〉, 《네이버 블로그》, 2018-09-05
• 제임스, 〈IT 재해 복구 (Disaster Recovery)개념 설명.〉, 《네이버 블로그》, 2006-07-18
• 이진현 이사, 〈(전문가 기고)취약점 드러낸 IT재해복구 진단②〉, 《디지털데일리》, 2018-12-12
• nhojimin, 〈(시스템)재해복구〉, 《구글 블로그》, 2016-01-27

같이 보기

• 장애
• 백업

이 재해복구 문서는 하드웨어에 관한 토막글입니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 이 문서의 내용을 채워주세요.

개발 : 프로그래밍, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어 □■⊕, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인 하드웨어 L2 스위치 • L3 스위치 • L4 스위치 • L7 스위치 • PTL • VTL • 가상 인터넷데이터센터(VIDC) • 나스(NAS) • 네트워크 스위치 • 다스(DAS) • 라우터 • 랙 • 맥주소 • 모뎀 • 방화벽 • 백본 • 백업장비 • 부대시설 • 브릿지 • 브릿지 테이블 • 샌 • 서버 • 스토리지 • 웹방화벽 • 웹스토리지 • 유니버설 플래시 스토리지 • 유피에스(UPS) • 이더넷 • 인터넷데이터센터(IDC) • 인프라 • 전산실 • 캐리어 이더넷 • 컴퓨터 클러스터 • 컴프레서 • 케이블 • 케이지 • 클라우드 스토리지 • 파이버 채널 • 펌웨어 • 하드웨어 • 항온항습기 하드웨어 관리 CDC • CDN • 가상머신 • 가상화 • 가용성 • 고가용성(HA) • 대역폭 • 라우팅 • 랙 • 레이드 • 레플리케이션 • 로드밸런싱 • 마스터 • 마스터-슬레이브 • 미러링 • 미러사이트 • 백업 • 백업사이트 • 복구 • 볼팅 • 부하 • 비즈니스 연속성(BC) • 서버 가상화 • 소산백업 • 스탠바이 • 스토리지 가상화 • 슬레이브 • 액티브 • 액티브-스탠바이 • 액티브-액티브 • 오프라인 백업 • 웜사이트 • 장애 • 장애복구 • 재해복구(DR) • 재해복구센터 • 지속적 데이터 보호(CDP) • 콜드사이트 • 페일오버 • 프로비저닝 • 프록시 • 핫사이트 • 핫스왑 네트워크 ADSL • AP • DSL • VPN • 게이트웨이 • 경로 • 공유기 • 네트워크 • 네트워크 가상화 • 네트워크 관리 시스템(NMS) • 네트워크 기기 • 네트워크 모니터링 • 네트워크 인터페이스 • 네트워크 장비 • 네트워크 케이블 • 네트워크 트래픽 • 네트워크 트래픽 모니터링 장비 • 라우터 • 랜(LAN) • 랜카드 • 리피터 • 망 • 무선 • 무선공유기 • 무선네트워크 • 무선랜 • 무선랜카드 • 무선브릿지 • 브릿지 • 수동 광통신망 • 아이피(IP) • 왠(WAN) • 유선 • 유선랜 • 유무선 • 인터넷공유기 • 전산망 • 전용회선 • 정보통신망 • 최단경로 • 컴퓨터 네트워크 • 터미널 • 통신 네트워크 • 통신회선 • 허브 • 호스트 • 홉 • 회선 통신 1세대 이동통신 • 2세대 이동통신 • 3세대 이동통신 • 4G(4세대 이동통신) • 5G(5세대 이동통신) • 6G • CDMA • GSM • IMT2000 • LTE • PC통신 • WCDMA • 공중전화 • 광선 • 광섬유 • 광케이블 • 기지국 • 디지털 • 모스부호 • 무선단말기 • 무선전화 • 무선통신 • 문자메시지 • 방송 • 방송통신 • 변조 • 보이스톡 • 브로드밴드 • 비디오폰 • 송신기 • 수신기 • 스마트폰 • 스타링크 • 아날로그 • 영상통화 • 와이맥스 • 와이브로 • 와이파이 • 유무선통신 • 유선전화 • 유선통신 • 음성 • 음성통화 • 이동통신 • 일반전화 • 전기통신번호 • 전기통신사업 • 전달 매개체 • 전신 • 전파 • 전화 • 전화기 • 점대점 통신 • 주파수 • 주파수 간섭 • 채널 • 초고속 인터넷 • 카폰 • 커버리지 • 통신 • 통신장비 • 페이스톡 • 프로토콜 • 헤르츠 • 휴대전화 위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반