[Network] 네트워크 설계 및 변경 시 고려 사항

 

 

1. IT 인프라 구축 설계서 및 운영 매뉴얼 작성 가이드

IT 인프라는 기관의 핵심 비즈니스와 이를 지원하는 서비스 요구 사항, 그리고 새로운 서비스 도입이나 신기술 수용과 같은 IT 환경 변화에 따라 지속적으로 확장되고 진화한다. 이를 효과적으로 관리하기 위해서는 체계적인 구축 설계서와 운영 매뉴얼이 필요하다.

 

(1) 구축 설계서

구축 설계서는 IT 인프라 설계의 기초가 되는 문서로, 기관의 비즈니스 요구 사항과 이를 지원하는 IT 인프라의 구체적인 물리적·논리적 구성을 정의한다.

 

-구축 설계서에 포함해야 할 내용

서비스 요구 사항 분석	- 기관의 핵심 비즈니스 목표와 이를 지원하는 서비스 정의.
물리적 구성 방안	- 서버, 네트워크, 보안 장비 등의 배치와 물리적 연결 방식.
논리적 구성 설계	- 장비별 역할 정의 및 서비스 트래픽 흐름 경로 설계. - 정책 기반 라우팅, VLAN 구성, IP 블록 할당 등 논리적 정책 수립.
정책 및 보안 요소	- 서비스별 보안 정책 및 운영 기준. - 장애 대비 및 재해복구(DR) 방안.

 

(2) 운영 매뉴얼

운영 매뉴얼은 구축된 IT 인프라를 안정적으로 운영·관리하기 위한 문서로, 관리자가 실질적인 업무에 활용할 수 있도록 작성된다.

 

- 운영 매뉴얼 작성 시 포함해야 할 내용

네트워크 구성 정보		- 전체 네트워크 구성도(간략 및 서비스 영역별 상세 구성도). - VLAN 설계 및 구성 정책. - IP 블록 할당 정책 및 주요 백본 스위치의 포트 사용률.
장비 설정 내용
	L3	- 정책 기반 라우팅(PBR) 설정 및 이유. - 루트 필터링과 정적 라우팅(32비트 호스트 라우팅 포함) 설정 이유. - NAT 설정 내용 및 연계 서비스 정보.
	L4	- SLB(Switch Load Balancer) 메트릭 설정 이유(예: 해시 또는 라운드 로빈 방식). - 헬스 체크 방식 선택 이유(예: ICMP 사용).
장애 관리		- 장애 발생 내역 및 재발 방지를 위한 분석 결과. - 주요 장애 처리 이력 및 원인 분석.
주요 서비스 서버 정보		- 서비스 제공 서버 목록 및 담당자 연락처. - 주요 서비스의 트래픽 흐름도.
변경 관리		- 물리적 구성 변경 및 논리적 설정 변경 사항 기록. - 변경 사항 발생 시 버전별 업데이트.
히스토리 관리		- 주기적 점검 결과 및 장비 상태 기록. - 주요 변경 이력과 장애 복구 기록.

 

(3) 운영 매뉴얼 작성 시 유의 사항

명확성	누구나 읽고 이해할 수 있도록 직관적으로 작성.
현행화	최신 변경 사항을 반영하여 항상 최신 상태 유지.
간결성	불필요한 설명을 지양하고 핵심 내용만 포함.
활용성	네트워크 구성 변경, 신규 시스템 도입 또는 장애 분석 등에 활용 가능하도록 구조화
인수인계 용이성	관리자가 변경될 경우에도 즉각적인 인수인계가 가능하도록 체계적으로 관리.

 

2. 효율적인 네트워크 장애 처리 접근법

 네트워크 운영 중 다양한 장애를 마주하게 되며, 이를 효과적으로 처리하는 방법에 대한 고민이 늘 따라온다. 장애를 완벽히 해결하는 "왕도"는 없지만, 경험과 체계적인 접근법을 통해 문제를 해결하고 성장하는 것이 중요하다. 아래는 장애 처리 시 반드시 고려해야 할 원칙과 단계이다.

 

- 증상 나열 및 기록

장애 처리의 첫걸음은 문제의 증상을 정확히 나열하는 것이다.

노트 활용	자신이 직접 확인한 증상과 주변에서 들은 내용을 구분하여 기록함.
객관성 유지	주변의 의견에 휘둘리지 말고 자신만의 관점에서 증상을 정리해야 함.

 

- 작업 내용 기록 및 설정 파일 백업

작업 내용 기록	장애 발생 전후의 작업 내용을 상세히 적고, 적용 시간을 명확히 기록함. 이는 이후 원인 분석에 중요한 참고 자료가 됨.
설정 파일 백업	장애 이전 설정 파일을 반드시 백업하여 필요 시 원상 복구가 가능하도록 대비합니다.

 

- 차분한 태도와 신뢰

장애 처리 중 혼란스러운 상황에서도 작업자에게 신뢰를 보여주고 침착한 태도를 유지한다.

긴장 완화

장애 처리자는 논리적 연속성을 유지하며 문제를 해결해야 하므로, 혼란을 유발하는 요구는 최소화해야 함.

 

- 로그 데이터에 기반한 분석

로그 활용	로그 데이터를 통해 장애 원인을 추론하고 증상을 입증함
집단 토의	팀원들과 논의해 주요 증상을 분리하고 논점을 흐리지 않도록 주의함.

 

- 문제 분리와 원인 규명

증상 분리	주요 장애 증상을 다른 문제와 분리하여 초점을 맞춤
간단한 해결 우선	복잡하게 확대 해석하지 말고, "가장 간단한 대답이 정답이다"라는 오컴의 면도날 원칙을 이용.

 

- 변경 사항 점검

최근 작업 확인	네트워크가 갑자기 멈췄다면 최근 변경된 사항을 먼저 점검함
물리 계층 진단	하드웨어 문제나 물리적 연결 상태를 우선적으로 확인함

 

- 리부팅은 최후의 수단

리부팅 전 준비	리부팅하기 전 모든 로그를 수집하고 증거를 확보함.
리부팅 후 대응	리부팅으로 장애가 종료되더라도 원인 분석은 끝까지 이어져야 함.

 

- 장비 신뢰

장비에 대한 신뢰를 잃고 습관적으로 리부팅하거나 버그 탓으로 돌리는 태도는 피해야 한다.

장비 문제 확인

버그로 의심될 경우 제조사에 문의해 공식적인 기술 문서를 확보하고, 필요 시 OS를 업그레이드함.

 

- 하위 계층부터 점검

하위 계층 확인

로그와 증상을 통해 물리 계층부터 차근차근 분석해 실마리를 찾음

 

- 멘토에게 도움 요청

적극적인 도움 요청	장애 해결이 어려운 경우 즉시 멘토나 전문가의 도움을 요청함.
Know-How와 Know-Who 활용	기술뿐 아니라 네트워크와의 연결을 활용해 빠르게 문제를 해결함.

 

- 문제를 설명하며 실마리 찾기

문제를 다른 사람에게 설명하며 스스로 놓친 부분을 발견할 수 있다.

간단한 설명

초등학생에게 설명하듯 쉽고 명료하게 문제를 정리하다 보면 새로운 관점에서 실마리를 찾을 수 있음

 

장애 처리는 단순히 기술력만으로 이루어지지 않는다. 체계적이고 논리적인 접근, 침착한 태도, 그리고 협업이 모두 어우러져야 효과적으로 문제를 해결하고 더 나은 엔지니어로 성장할 수 있다.

 

3. 네트워크 변경을 위한 고려 사항

 네트워크를 운영하다 보면 서비스 장애 해결이나 새로운 기능 구현 등의 이유로 네트워크 변경이 필요할 때가 있다. 이런 변경 작업은 단순한 VLAN 추가나 서버 교체와 같은 일상적인 변경을 넘어서는 규모의 작업을 포함한다. 이를 성공적으로 수행하기 위해서는 구성 측면과 경제적 측면의 고려가 필수적이다.

 

- 구성 측면의 고려 사항

네트워크 변경 시, 엔지니어는 다음 세 가지 요소를 중심으로 개선안을 작성해야 한다.

단순화	- 네트워크는 직관적이고 이해하기 쉬운 구조로 설계되어야 함. 이를 통해 운영 및 관리 효율성을 극대화할 수 있음.
표준화	- 가능한 표준 프로토콜과 기술을 사용하여 특정 벤더에 종속되지 않도록 해야 함 - 비표준 기술을 사용할 경우, 향후 표준 기술로 전환이 가능하도록 대체 방안을 마련해야 함. - 네트워크 설계는 조직이 채택한 표준 모델과 구축 설계서에 근거하여 작성해야 함.
안정성	- 변경 작업은 네트워크 안정성을 강화하는 방향으로 진행되어야 함. - 변경 후의 안정성이 기존 상태보다 저하된다면, 해당 변경안은 상급 관리자들에게 승인받기 어려울 것임.

 

- 경제적 측면의 고려 사항

 기술적인 측면만큼이나 중요한 것이 경제적 요인이다. 네트워크 변경은 비용 효율성과 성능 향상이라는 두 가지 목표를 동시에 충족해야 한다.

비용 절감	- 장비 비용뿐만 아니라 유지보수 비용, 인건비 등의 경상 비용까지 절감 방안을 포함해야 함. - 예를 들어, 기존 장비 두 대를 신형 장비 한 대로 대체해 비용 효율성을 극대화할 수 있음.
성능 및 용량 증대	- 새로운 기술이나 하드웨어를 통해 네트워크의 성능과 용량을 향상시켜야 함. - 이는 네트워크의 성장 가능성을 확보하는 데 필수적임.
비즈니스 신뢰성 향상	- 네트워크 변경은 조직의 비즈니스 연속성과 신뢰성을 강화해야 함. - 안정적이고 효율적인 네트워크는 조직의 경쟁력을 높이는 핵심 요소임.