IT 시스템 장애는 엉터리 자산대장에서 시작됩니다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

장애가 발생했는데 담당자가 서버의 위치, 보증 기간, 연결된 스위치 포트를 찾느라 한 시간을 허비한다면 기술보다 기록 체계가 먼저 무너진 것입니다. 장비는 정상적으로 구매했지만 자산명, 운영 목적, 담당자, 네트워크 연결 정보가 서로 다른 문서에 흩어져 있으면 IT 시스템 복구 시간은 예상보다 길어집니다.

특히 서버와 네트워크 장비가 빠르게 늘어난 조직에서는 엑셀 파일 하나를 자산대장이라고 부르는 실수가 반복됩니다. 이번 글에서는 실제 현장에서 흔히 나타나는 실패 유형을 바탕으로 이것만은 하지 말아야 할 IT 인프라 자산관리 방식을 짚어봅니다.

구매 목록을 IT 자산대장이라고 부르지 마세요

모델명과 가격만 기록한 대장은 장애 대응에 쓸 수 없습니다

첫 번째 실패는 구매일, 제조사, 모델명, 금액만 적어 놓고 자산관리가 끝났다고 생각하는 것입니다. 이 정보는 회계 처리에는 도움이 되지만 서버 장애나 네트워크 단절이 발생했을 때는 충분하지 않습니다. 운영자는 해당 장비가 어떤 서비스를 제공하는지, 어느 랙에 설치됐는지, 어떤 장비와 연결됐는지를 즉시 확인할 수 있어야 합니다.

예를 들어 같은 모델의 서버가 다섯 대 있는데 자산번호와 호스트명이 연결되어 있지 않다고 가정해 보겠습니다. 전원 장애 알림에는 호스트명만 표시되지만 구매대장에는 시리얼 번호만 있다면 담당자는 서버실에서 장비 라벨을 하나씩 대조해야 합니다. 이 과정에서 정상 장비의 전원을 잘못 내리는 2차 장애까지 발생할 수 있습니다.

자산관리의 개념과 시스템이 담당해야 할 범위를 이해하려면 IT자산관리시스템 용어 설명도 참고할 수 있습니다. 핵심은 물건의 보유 여부만 세는 것이 아니라 취득부터 배치, 변경, 유지보수, 폐기까지 운영 정보를 연결하는 데 있습니다.

• 식별 정보: 자산번호, 호스트명, 시리얼 번호, 관리 IP를 서로 연결합니다.
• 물리 정보: 건물, 서버실, 랙 번호, 랙 유닛 위치와 전원 회선을 기록합니다.
• 서비스 정보: 장비의 운영 목적, 중요도, 허용 중단 시간, 사용 부서를 표시합니다.
• 연결 정보: 상단 스위치, 포트 번호, VLAN, 방화벽 정책과 저장장치 연결을 남깁니다.
• 계약 정보: 보증 종료일, 유지보수 업체, 장애 접수 방법과 계약 번호를 포함합니다.

자산대장을 보고 5분 안에 장비의 위치와 서비스 영향 범위를 설명할 수 없다면 운영용 대장이 아니라 구매 목록에 가깝습니다.

담당자 기억에 의존한 구성 변경은 반드시 흔적을 잃습니다

구두 승인과 사후 기록이 만든 방화벽 장애

두 번째 실패는 “작은 변경이니 작업 후 적어 두자”는 습관입니다. 긴급하게 방화벽 포트를 열거나 서버 메모리를 추가한 뒤 기록을 미루면, 며칠 후에는 변경 이유와 승인자를 기억하기 어렵습니다. 인수인계가 발생하면 그 정보는 거의 사라지고, 남은 설정만 보고 의도를 추측해야 합니다.

한 사무실에서는 외부 솔루션 점검을 위해 임시 방화벽 정책을 추가했지만 종료일을 기록하지 않았습니다. 담당자는 점검이 끝난 뒤 정책을 삭제하려 했으나 비슷한 이름의 운영 정책을 제거했고, 내부 사용자의 업무 시스템 접속이 끊겼습니다. 변경 대상, 원복 조건, 검증 방법을 적지 않은 것이 직접적인 원인이었습니다.

규모가 큰 공공·기업 시스템은 여러 서비스와 운영 주체가 연결되므로 단일 장비만 보고 변경 영향을 판단하기 어렵습니다. 범정부 IT 서비스 시스템 설명처럼 서비스가 상호 연계되는 구조를 떠올리면, 구성 항목 간 관계를 기록해야 하는 이유가 더 분명해집니다.

1. 작업 전: 대상 장비, 현재 설정, 영향 서비스와 승인자를 변경 요청서에 적습니다.
2. 작업 직전: 설정 백업 파일을 만들고 파일명에 장비명과 시간을 포함합니다.
3. 작업 중: 실제 실행한 명령과 예상 밖의 결과를 시간순으로 기록합니다.
4. 검증 단계: 포트 연결 여부만 보지 말고 로그인, 조회, 저장 등 사용자 동작을 시험합니다.
5. 작업 후: 자산대장과 구성 문서를 같은 업무 티켓에서 갱신하고 원복 가능 여부를 확인합니다.

자동 수집 정보도 사람이 확인하지 않으면 틀립니다

네트워크 검색이나 에이전트로 장비 정보를 자동 수집하면 입력 부담은 줄지만, 그것만으로 정확한 대장이 완성되지는 않습니다. 종료된 가상 서버가 계속 남거나 같은 장비가 IP 변경으로 중복 등록될 수 있고, 외부 협력사 장비가 회사 소유 자산처럼 잡히기도 합니다. 자동 수집은 발견 수단이며 소유권과 중요도를 판정하는 절차는 아닙니다.

• 신규 발견 자산은 소유 부서와 운영 목적을 확인하기 전까지 ‘미분류’ 상태로 둡니다.
• 30일 이상 통신이 없는 장비는 바로 삭제하지 말고 휴면, 철거, 장애 가능성을 구분합니다.
• 가상머신, 물리 호스트, 스토리지 사이의 종속 관계를 별도 필드로 연결합니다.
• 자동 수집 값과 담당자 입력 값이 다르면 최근 변경 티켓을 기준으로 검증합니다.

폐기와 계약 종료를 미루면 비용과 보안 위험이 함께 남습니다

전원이 꺼진 서버도 관리 대상에서 사라진 것은 아닙니다

세 번째 실패는 사용하지 않는 서버의 전원만 끄고 자산대장에는 운영 중으로 남겨 두는 것입니다. 반대로 대장에서는 폐기 처리했지만 랙에 장비가 그대로 꽂혀 있는 경우도 있습니다. 두 상태가 일치하지 않으면 유지보수 갱신 수량이 부풀고, 남은 디스크와 관리 포트가 보안 사각지대가 됩니다.

폐기 서버의 디스크에는 고객 정보, 계정 파일, 인증서, 데이터베이스 백업이 남아 있을 수 있습니다. 단순 포맷이나 파일 삭제만으로는 조직의 보안 기준을 충족하지 못할 수 있으므로 저장매체 종류와 데이터 등급에 맞는 삭제 방식, 삭제 확인서, 반출 기록을 정해야 합니다. 임대 장비라면 반납 전에 데이터 제거 책임이 어느 쪽에 있는지도 계약서에서 확인해야 합니다.

또 다른 손실은 유지보수 계약의 자동 갱신입니다. 실제로는 철거한 스위치와 서버가 계약 목록에 남아 연간 비용이 청구되거나, 반대로 핵심 장비가 누락돼 장애 당일 유상 지원부터 협의하는 상황이 생깁니다. 자산 상태와 계약 상태를 별도로 관리하되 종료일을 서로 대조해야 이런 실패를 줄일 수 있습니다.

폐기는 구매보다 더 세분화해야 합니다

자산 상태를 ‘사용’과 ‘폐기’ 두 가지로만 두지 마세요. 도입 예정, 설치 중, 운영, 예비 장비, 수리, 격리, 철거 대기, 데이터 삭제 완료, 반출 완료처럼 실제 흐름에 맞춰 구분해야 합니다. 그래야 현장 담당자와 재무·보안 담당자가 같은 단어를 서로 다르게 이해하는 일을 막을 수 있습니다.

• 철거 전: 서비스 종료 승인과 대체 시스템의 정상 동작을 확인합니다.
• 철거 시: 케이블, IP, DNS, 방화벽 및 모니터링 설정을 함께 제거합니다.
• 데이터 처리: 저장매체별 삭제 또는 물리 파기 결과를 증빙합니다.
• 반출 후: 실물 수량, 시리얼 번호, 계약 종료 여부를 최종 대조합니다.

폐기 완료일은 서버 전원을 끈 날이 아니라 데이터 제거, 실물 반출, 계약 변경이 모두 확인된 날로 기록하는 편이 안전합니다.

내일이 아니라 오늘 서버 한 대를 역추적해 보세요

30분 표본 점검이 대장의 약한 연결고리를 드러냅니다

자산관리 솔루션을 새로 구매하기 전에 현재 기록이 현장에서 얼마나 쓸 수 있는지 먼저 시험해 보세요. 중요한 업무를 담당하는 서버 한 대를 고르고 자산번호만으로 설치 위치, 운영 서비스, 네트워크 연결, 최근 변경, 보증 상태를 역추적합니다. 담당자에게 전화하거나 여러 메신저방을 검색해야만 답을 찾는다면 그 과정 자체가 개선 대상입니다.

대규모 데이터센터와 고성능 인프라에 관한 데이터센터 기술 관련 기사에서도 하드웨어와 소프트웨어를 함께 최적화하는 관점이 강조됩니다. 조직의 자산관리 역시 장비 목록 하나만 정확하게 만드는 일이 아니라 서버, 네트워크, 서비스, 계약, 담당자를 하나의 운영 흐름으로 연결하는 작업이어야 합니다.

점검 결과는 곧바로 모든 장비에 확대하지 말고 누락이 반복되는 필드를 먼저 고정하는 것이 좋습니다. 예를 들어 랙 위치와 스위치 포트가 자주 비어 있다면 두 항목을 필수값으로 지정하고, 변경 작업을 닫기 전에 갱신 여부를 확인하게 만드세요. 작은 규칙을 실제 업무 절차에 심는 편이 한 번의 전수조사보다 오래 유지됩니다.

1. 업무 영향도가 높은 서버 한 대를 선정하고 타이머를 30분으로 맞춥니다.
2. 자산번호, 호스트명, 시리얼 번호가 동일한 장비를 가리키는지 확인합니다.
3. 랙 위치에서 장비를 찾고 대장에 적힌 스위치 포트와 실제 케이블을 대조합니다.
4. 최근 3개월 변경 기록에서 메모리, IP, 운영체제, 담당자 변경이 반영됐는지 봅니다.
5. 보증 종료일과 장애 접수 연락처를 확인해 실제 접수가 가능한 상태인지 검증합니다.
6. 찾지 못했거나 서로 달랐던 항목 세 개만 골라 담당자와 수정 기한을 지정합니다.

점검 결과는 정확도 지표로 남겨야 반복됩니다

자산대장의 품질을 단순 등록 건수로 평가하면 빈 항목과 오래된 정보가 가려집니다. 표본 장비 가운데 위치가 일치한 비율, 담당자가 확인된 비율, 최근 변경이 반영된 비율, 폐기 증빙이 연결된 비율을 월별로 비교해 보세요. 숫자가 낮은 부서에는 입력을 독촉하기 전에 어떤 업무 단계에서 기록이 끊기는지 확인해야 합니다.

• 위치·시리얼·호스트명 일치율을 기본 정확도 지표로 사용합니다.
• 변경 완료 후 자산대장 갱신까지 걸린 시간을 측정합니다.
• 보증 종료 90일 이내 장비의 교체 또는 연장 결정 여부를 표시합니다.
• 담당자가 없는 자산과 30일 이상 응답하지 않는 자산을 별도 목록으로 관리합니다.

지금 바로 핵심 서버 한 대의 자산번호를 검색해 설치 위치와 연결 포트를 찾아보세요. 5분 안에 현장 장비까지 특정하지 못했다면 누락된 필드 하나를 확인하고, 오늘 처리하는 변경 티켓의 필수 항목으로 추가하는 것부터 시작하면 됩니다.