IT 자산관리, 서버 목록 작성부터 교체 주기 결정까지

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

서버 장애가 발생했는데 담당자가 장비 위치와 유지보수 계약 여부를 찾느라 시간을 허비한다면, 문제는 장비 성능보다 IT 자산관리 체계에 있을 가능성이 큽니다. VL시스템의 인프라 컨설턴트에게 서버 목록 작성부터 운영 정보 연결, 교체 우선순위 결정까지 실무자가 궁금해하는 내용을 물었습니다.

첫 순서는 장비 구매가 아니라 현황을 발견하는 일입니다

Q. 엑셀에 서버 목록이 있는데도 다시 조사해야 하나요?

A. 목록에 모델명과 구매일만 적혀 있다면 운영에 필요한 자산대장으로 보기 어렵습니다. 실제 장애 대응에는 장비가 설치된 랙 위치, 담당 부서, IP 주소, 운영체제, 서비스 용도, 보증 만료일과 유지보수 연락처가 함께 필요합니다. 먼저 전산실과 사무공간을 직접 확인하고 네트워크 관리 화면, 가상화 플랫폼, 구매 문서를 대조해야 누락된 자산을 찾을 수 있습니다.

IT자산관리시스템의 용어와 개념을 살펴보면 자산관리가 단순한 재물조사와 다르다는 점을 이해하기 쉽습니다. 특히 가상 서버와 클라우드 인스턴스는 눈에 보이지 않으므로 물리 장비 조사와 별도의 검색 절차가 필요합니다. 사용 중인 서버를 누가 어떤 업무에 쓰는지 답하지 못한다면 아직 조사가 끝난 것이 아닙니다.

• 물리 자산: 서버, 스위치, 방화벽, 스토리지, UPS와 랙 부속품
• 논리 자산: 가상머신, 운영체제, 데이터베이스, 인증서와 소프트웨어 라이선스
• 계약 자산: 보증 기간, 유지보수 범위, 임대 조건과 갱신일

자산번호를 붙이기 전에 식별 기준부터 통일합니다

Q. 장비 이름은 부서별로 편하게 정하면 안 되나요?

A. 서버명이 ‘회계서버’, ‘회계2’, ‘NEW-ERP’처럼 섞이면 검색과 자동화가 어려워집니다. 자산번호는 사람이 읽을 수 있으면서도 위치나 담당자가 바뀌어도 유지되는 고유값이어야 합니다. 반면 호스트명은 시스템 역할과 운영 환경을 표현하도록 별도 규칙을 적용하는 편이 안전합니다. 두 값을 하나로 합치면 장비 이동이나 용도 변경 때 과거 기록이 끊길 수 있습니다.

예를 들어 자산번호는 VL-SV-0001처럼 고정하고, 호스트명은 PRD-ERP-DB01처럼 운영 환경과 역할을 담을 수 있습니다. 같은 모델의 서버라도 시리얼번호, 관리 IP, 랙 위치를 함께 기록하면 현장에서 잘못된 장비의 전원을 내리는 사고를 줄일 수 있습니다. 라벨에는 자산번호와 QR 코드를 표시하되 비밀번호나 외부에서 악용될 상세 네트워크 정보는 넣지 않는 것이 좋습니다.

1. 회사 전체에서 사용할 자산 유형 코드를 정의합니다.
2. 중복되지 않는 영구 자산번호를 발급합니다.
3. 호스트명, 시리얼번호와 관리 IP를 연결합니다.
4. 실물 라벨과 관리대장의 값이 일치하는지 교차 확인합니다.

전문가 조언: 좋은 자산번호는 장비의 현재 위치를 설명하기보다 장비의 생애 전체를 추적할 수 있어야 합니다.

서버 한 대가 어떤 업무를 지탱하는지 연결합니다

Q. 하드웨어 정보만 정확하면 장애 대응에 충분한가요?

A. 서버는 요청을 받아 데이터나 기능을 제공하는 역할을 합니다. 기본 개념은 서버 용어 설명에서도 확인할 수 있지만, 기업 IT 시스템에서는 한 대의 서버가 여러 애플리케이션과 데이터베이스에 얽혀 있다는 점이 더 중요합니다. 장비 목록에 업무 서비스를 연결하지 않으면 장애가 발생해도 영향 범위를 빠르게 판단하기 어렵습니다.

자산마다 ‘중요’라고 표시하는 대신 서비스 중단이 매출, 고객 응대, 생산 또는 법정 업무에 미치는 영향을 구체적으로 기록해 보세요. ERP 데이터베이스 서버가 멈추면 회계팀만 영향을 받는지, 물류 출고와 전자결재까지 중단되는지 확인해야 합니다. 의존 관계를 조사할 때는 담당자의 기억뿐 아니라 방화벽 정책, 접속 로그와 애플리케이션 설정도 함께 검증해야 합니다.

• 업무 연결: 제공 서비스, 이용 부서, 서비스 책임자
• 기술 연결: 연동 서버, 데이터베이스, 스토리지와 네트워크 경로
• 중단 영향: 허용 가능한 정지 시간과 데이터 손실 범위
• 복구 연결: 백업 위치, 복구 절차 문서와 비상 연락망

수집한 정보는 변경 절차와 묶어야 살아 있습니다

Q. 자산대장이 몇 달만 지나면 틀리는 이유는 무엇인가요?

A. 최초 조사가 부족해서가 아니라 변경 업무와 자산 갱신이 분리돼 있기 때문입니다. 서버 증설, 메모리 교체, IP 변경, 가상머신 이전이 승인된 뒤에도 대장을 수정하는 책임자가 없다면 정보는 즉시 낡기 시작합니다. 구매 요청부터 설치, 변경, 이동, 반납과 폐기까지 각 업무 단계에 자산정보 갱신 항목을 넣어야 합니다.

변경 신청서에는 대상 자산번호와 변경 전후 값을 기록하고, 완료 승인 전에 관리대장 반영 여부를 확인하는 방식이 실용적입니다. 자동 수집 도구를 사용하더라도 담당 부서와 계약 조건 같은 업무 정보는 사람이 관리해야 합니다. 반대로 CPU, 메모리, 운영체제 버전처럼 시스템에서 확인 가능한 항목을 매번 수기로 입력하면 오타와 갱신 지연이 늘어납니다.

1. 구매 승인 시 임시 자산번호와 담당자를 지정합니다.
2. 검수 시 시리얼번호, 사양과 보증 정보를 확정합니다.
3. 설치 시 랙 위치, IP, 서비스 관계를 등록합니다.
4. 변경 완료 조건에 자산대장 갱신을 포함합니다.
5. 반납·폐기 시 데이터 삭제 증적과 최종 처리일을 남깁니다.

누가 입력하는가보다 누가 정확성을 승인하는가를 정하는 것이 핵심입니다. 인프라 담당자는 기술 정보를, 구매 담당자는 계약 정보를, 서비스 책임자는 업무 중요도를 검증하도록 역할을 나누면 관리 부담도 줄어듭니다.

교체 순위는 장비 나이보다 운영 위험으로 정합니다

Q. 서버는 구매 후 몇 년이 지나면 바꿔야 하나요?

A. 사용 연수 하나로 교체 시점을 결정하면 아직 충분한 장비를 버리거나, 위험한 장비를 계속 운영할 수 있습니다. 제조사 지원 종료, 부품 조달 가능성, 장애 빈도, 성능 여유, 전력 효율과 서비스 중요도를 함께 평가해야 합니다. 같은 시기에 산 서버라도 테스트 장비와 핵심 데이터베이스 서버의 교체 순위는 달라야 합니다.

점수표를 만들 때는 지원 종료가 임박하고 장애 시 대체 장비가 없는 자산에 높은 위험 점수를 부여합니다. CPU 사용률이 낮다는 이유만으로 교체를 미루기 전에는 운영체제와 펌웨어 보안 업데이트가 계속 제공되는지도 확인해야 합니다. 예산은 단순 구매가뿐 아니라 마이그레이션 작업, 라이선스 변경, 랙 전력과 서비스 중단 비용까지 포함해 산정합니다.

• 즉시 검토: 지원 종료, 반복 장애, 예비 부품 부재가 겹친 핵심 장비
• 계획 교체: 지원 기간은 남았지만 용량 증가나 호환성 문제가 예상되는 장비
• 유지 관찰: 지원과 성능이 충분하고 장애 시 우회 수단이 있는 장비

“오래된 장비”가 아니라 고장 이후 복구 방법이 불확실한 장비를 먼저 찾아야 교체 예산의 설득력이 높아집니다.

도구는 자산 규모와 운영 방식에 맞춰 선택합니다

Q. 엑셀, CMDB, 자동 탐지 도구 중 무엇이 적합한가요?

A. 자산 수가 적고 변경 빈도가 낮다면 구조화된 스프레드시트로 시작할 수 있습니다. 다만 여러 담당자가 동시에 수정하거나 서버와 네트워크 장비의 의존 관계를 관리해야 한다면 권한, 변경 이력과 승인 기능을 갖춘 IT 자산관리 시스템이 유리합니다. 자동 탐지는 수집 속도를 높이지만 모든 업무 맥락을 알아서 채워 주는 도구는 아닙니다.

도입 비용은 제품 라이선스만 보면 안 됩니다. 초기 데이터 정제, 에이전트 설치, 네트워크 검색 범위 설정, 기존 서비스데스크 연동과 운영 교육에 드는 비용도 비교해야 합니다. 지나치게 복잡한 제품을 선택하면 현장 담당자가 입력을 피하면서 다시 개인 파일을 만들 수 있습니다. 먼저 필수 필드와 갱신 절차를 정한 뒤 그 과정을 가장 적은 수작업으로 지원하는 도구를 고르세요.

• 스프레드시트: 시작이 빠르고 저렴하지만 동시 편집과 변경 추적에 한계가 있습니다.
• 전용 ITAM: 구매·계약·폐기 관리에 강하지만 초기 데이터 설계가 필요합니다.
• CMDB: 서비스 의존 관계와 변경 영향을 표현하기 좋지만 지속적인 운영 규칙이 필수입니다.
• 자동 탐지: 누락 자산 발견에 유용하지만 방화벽 밖 장비와 업무 책임자는 별도 확인해야 합니다.

시범 적용은 전체 회사를 한꺼번에 대상으로 삼기보다 핵심 서버군 한 곳에서 시작하는 편이 좋습니다. 발견률, 필드 정확도, 갱신 소요시간을 측정하면 도구가 실제 운영 부담을 줄이는지 판단할 수 있습니다.

지원 종료와 조직 변화가 자산대장의 다음 질문을 만듭니다

Q. 구축을 마친 뒤에는 무엇을 주기적으로 확인해야 하나요?

A. 자산관리에는 완성 시점이 없습니다. 제조사의 펌웨어 지원 정책, 운영체제 수명주기, 라이선스 방식과 클라우드 과금 구조가 달라지면 같은 자산의 위험도와 비용도 바뀝니다. 2026년 현재 정보를 등록했더라도 다음 계약 갱신일까지 그대로 믿기보다 월별 자동 점검과 분기별 책임자 검토를 조합해야 합니다.

조직 개편도 중요한 변화 요인입니다. 부서가 합쳐지거나 담당자가 퇴사하면 장비는 작동해도 승인권자와 서비스 책임자가 사라질 수 있습니다. 인사 이동 시 자산 인계 절차를 연결하고, 사용자가 없는 서버는 즉시 삭제하지 말고 접속 로그와 업무 의존성을 확인한 뒤 격리·관찰·폐기 순서로 처리해야 합니다. 공공 영역의 대규모 IT 서비스 개념은 범정부 IT 서비스 시스템 설명에서도 참고할 수 있습니다.

1. 매월 미등록 IP, 신규 가상머신과 만료 예정 인증서를 탐지합니다.
2. 분기마다 서비스 책임자에게 용도와 중요도를 재확인합니다.
3. 반기마다 지원 종료 일정과 유지보수 계약 범위를 대조합니다.
4. 조직 개편 직후 소유자가 사라진 자산과 계정을 별도 점검합니다.

다음 점검일에는 장비 수량만 비교하지 말고 지원 정책, 계약 단가, 담당 조직과 서비스 의존 관계가 어떻게 달라졌는지를 질문해야 합니다. 이 요소들은 시간이 흐르며 바뀌므로, 교체 순위 역시 고정된 표가 아니라 최신 운영 조건에 따라 다시 계산되어야 합니다.