사내 IT자산관리 시스템을 한 달 운영해봤더니 달라진 것

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

퇴사한 직원의 노트북이 어디에 있는지 모르고, 장애가 난 서버의 보증 기간을 확인하느라 구매 메일함부터 뒤지고 있나요? 이런 문제는 장비가 부족해서가 아니라 IT자산 정보가 한곳에 모여 있지 않아서 생기는 경우가 많습니다. 엑셀 한 장으로 시작한 사내 자산 목록을 IT자산관리 시스템으로 옮겨 한 달간 운영해보니, 가장 먼저 달라진 것은 장비 수가 아니라 질문에 답하는 속도였습니다.

IT자산관리는 장비 목록보다 넓은 개념입니다

하드웨어와 소프트웨어, 담당자까지 연결합니다

초보자가 생각하는 IT자산관리는 대개 노트북과 모니터의 모델명, 수량을 적는 일에 가깝습니다. 그러나 실제 기업 인프라에서는 서버, 네트워크 스위치, 무선 AP, 방화벽, 스토리지, UPS뿐 아니라 운영체제와 소프트웨어 라이선스, 유지보수 계약, 공인 IP, 도메인, 인증서도 관리 대상이 됩니다. 장비가 어느 사무실과 서버실에 있는지, 누가 사용하거나 관리하는지도 함께 기록해야 정보가 살아 움직입니다.

IT자산관리시스템의 용어 정의를 보면 자산의 도입부터 운용과 폐기까지 이어지는 관리 관점을 이해할 수 있습니다. 즉, 구매한 물건을 세는 작업이 아니라 IT 시스템의 전체 생애주기를 추적하는 운영 체계라고 보는 편이 정확합니다. 서버 한 대가 어떤 업무를 제공하고, 어느 스위치 포트와 연결되며, 장애가 나면 누구에게 연락해야 하는지까지 이어져야 합니다.

처음부터 복잡한 CMDB를 만들 필요는 없습니다. 다만 아래 범주는 구분해 두어야 나중에 자산 수가 늘어도 목록을 다시 뜯어고치는 일을 줄일 수 있습니다.

• 물리 자산: 서버, PC, 스위치, 공유기, 랙, UPS와 주변 장치
• 가상 자산: 가상머신, 클라우드 인스턴스, 볼륨과 백업 저장소
• 논리 자산: 운영체제, 상용 라이선스, 도메인, SSL 인증서와 계정
• 운영 정보: 사용자, 관리 담당자, 설치 위치, 계약 업체와 만료일

한 달 운영의 출발점은 자산번호 규칙이었습니다

이름만 보고도 종류와 위치를 짐작하게 만듭니다

첫 주에는 자산을 입력하기보다 식별 규칙부터 정했습니다. 제조사가 부여한 시리얼 번호는 중복 가능성이 낮지만 너무 길고, 직원이 전화로 읽거나 장비에서 바로 찾기 어렵습니다. 반대로 사내 별칭만 사용하면 담당자가 바뀌었을 때 의미를 알 수 없습니다. 그래서 자산번호는 내부 식별용으로 만들고 제조사 시리얼 번호는 별도 필드에 원문 그대로 보존했습니다.

예를 들어 서울 본사의 운영 서버라면 SEL-SRV-001, 부산 지사의 네트워크 스위치라면 BUS-SW-003처럼 구성할 수 있습니다. 다만 자산번호에 부서명이나 사용자 이름을 과도하게 넣으면 조직 개편과 인사이동 때 번호까지 바꿔야 합니다. 쉽게 변하지 않는 위치와 장비 종류만 번호에 넣고, 사용자와 부서는 변경 가능한 속성으로 관리하는 것이 안정적입니다.

네트워크 장비 이름도 같은 원칙을 적용했습니다. 호스트명, 자산번호, 관리 IP가 서로 다른 역할을 가진다는 점을 구분하니 기록이 훨씬 명확해졌습니다. 한 필드에 여러 값을 쉼표로 몰아넣지 않는 것도 중요합니다.

1. 회사와 지점을 나타내는 영문 약어를 두세 글자로 정합니다.
2. SRV, SW, FW, AP처럼 장비 유형 코드를 통일합니다.
3. 세 자리 이상의 순번을 부여하고 삭제된 번호는 재사용하지 않습니다.
4. 라벨에는 자산번호와 QR 코드만 표시하고 민감한 IP 정보는 넣지 않습니다.
5. 예외 규칙과 코드 목록을 문서화해 신규 담당자도 같은 방식으로 등록하게 합니다.

자산번호는 장비의 현재 사용자를 설명하는 문장이 아닙니다. 이동과 용도 변경 뒤에도 유지될 수 있는 짧고 고유한 식별자로 설계하는 것이 좋습니다.

서버와 네트워크 장비는 관계를 기록해야 보입니다

단일 장비 정보에서 서비스 연결도로 확장합니다

서버의 CPU와 메모리 용량만 기록해서는 장애 대응에 큰 도움이 되지 않습니다. 해당 서버가 ERP를 제공하는지, 파일 공유를 담당하는지, 어떤 가상머신이 구동되는지 알아야 영향 범위를 판단할 수 있습니다. 서버의 기본 개념이 낯설다면 서버에 관한 지식백과 설명을 먼저 읽고 클라이언트에 서비스를 제공한다는 역할부터 이해하면 좋습니다.

운영 둘째 주에는 서버와 스위치, 업무 서비스 사이의 관계를 연결했습니다. 예를 들어 가상화 호스트 A에 인사시스템 VM이 있고, 이 호스트가 코어 스위치 12번 포트와 연결된다는 식입니다. 여기에 백업 대상 여부와 복구 담당자를 덧붙이자 장애가 발생했을 때 확인해야 할 경로가 선명해졌습니다. IT 인프라는 장비의 집합이 아니라 연결된 서비스 구조이기 때문입니다.

처음 관계 정보를 입력할 때는 완벽한 자동 탐색보다 핵심 서비스부터 수작업으로 검증하는 편이 안전합니다. 스캔 도구가 발견한 IP 하나가 프린터인지 임시 테스트 서버인지 판단하려면 결국 현장 정보가 필요합니다. 다음 표처럼 자산별 핵심 필드를 다르게 두면 불필요한 입력을 줄일 수 있습니다.

• 매출이나 업무 중단에 직접 영향을 주는 핵심 서비스를 먼저 연결합니다.
• 장비 간 물리 연결과 서비스 간 논리 의존성을 별도로 표시합니다.
• 확인하지 못한 관계는 추측해 입력하지 말고 상태를 ‘검증 필요’로 남깁니다.

엑셀에서 시스템으로 옮길 때 데이터부터 씻었습니다

중복과 빈칸을 그대로 가져오지 않는 방법

기존 엑셀에는 같은 장비가 자산번호, 호스트명, 시리얼 번호 기준으로 각각 한 줄씩 들어가 있었습니다. ‘서버실’, ‘전산실’, ‘본사 4층’처럼 위치 표기도 제각각이었고 퇴사자가 계속 사용자로 남은 항목도 발견됐습니다. 이 상태로 시스템에 일괄 등록하면 검색은 가능해져도 데이터에 대한 신뢰는 높아지지 않습니다.

그래서 세 번째 주에는 원본을 바로 수정하지 않고 사본에서 정제했습니다. 시리얼 번호와 MAC 주소를 중복 판별 기준으로 삼고, 위치와 자산 상태는 선택형 값으로 통일했습니다. 사용 중, 재고, 수리 중, 대여, 폐기 예정, 폐기 완료처럼 상태를 제한하니 담당자마다 다른 표현을 쓰는 문제가 줄었습니다. 자유 입력란을 최소화하고 선택값을 표준화하는 것이 초보자에게 특히 효과적입니다.

개인정보와 보안정보의 범위도 함께 결정해야 합니다. 사용자 이름과 연락처는 업무상 필요한 수준만 저장하고, 관리자 비밀번호나 장비의 비밀키는 자산관리 시스템에 평문으로 넣지 않아야 합니다. 계정 금고나 비밀 관리 도구의 참조 위치만 연결하는 편이 안전합니다.

1. 기존 파일을 읽기 전용 원본으로 보관하고 정제용 사본을 만듭니다.
2. 자산번호, 시리얼 번호, MAC 주소의 중복을 각각 검사합니다.
3. 부서명, 위치, 상태, 장비 유형의 표기 방식을 통일합니다.
4. 필수값이 비어 있는 장비에는 임의 값을 넣지 않고 현장 확인 대상으로 분류합니다.
5. 소량의 표본을 먼저 가져와 한글 깨짐, 날짜 형식, 필드 매핑을 확인합니다.
6. 전체 등록 후 실제 장비 10% 이상을 골라 시스템 기록과 대조합니다.

나쁜 데이터를 빠르게 검색할 수 있게 만드는 것은 자산관리 개선이 아닙니다. 이관 전에 중복과 상태값부터 다듬어야 이후 자동화도 신뢰할 수 있습니다.

비용은 프로그램 가격보다 운영 방식에서 갈렸습니다

무료 도구와 상용 서비스의 선택 기준

IT자산관리 시스템의 비용을 물으면 월 구독료부터 떠올리기 쉽지만 실제 예산에는 구축과 운영 시간이 포함됩니다. 오픈소스 도구는 라이선스 비용을 낮출 수 있는 대신 서버 준비, 보안 업데이트, 백업, 장애 대응을 내부에서 맡아야 합니다. SaaS는 초기 구축이 빠르고 원격 근무 환경에 적용하기 편하지만 사용자 수나 자산 수가 늘면 구독료가 함께 증가할 수 있습니다.

상용 솔루션의 견적은 관리 자산 수, 관리자 계정 수, 자동 탐색 에이전트, API 연동, 기술지원 등급에 따라 크게 달라집니다. 따라서 변동 가능성이 큰 단일 가격표를 기준으로 결정하기보다 3년 총소유비용을 계산해야 합니다. 서버와 데이터베이스 운영 인력, 초기 데이터 정제, 라벨 제작, 교육, 유지보수, 데이터 반출 비용까지 포함하면 서로 다른 방식의 장단점이 보입니다.

소규모 사무실은 필수 필드가 정리된 스프레드시트와 정기 실사만으로도 출발할 수 있습니다. 반면 서버와 네트워크 장비가 여러 지점에 흩어져 있거나 입퇴사가 잦고 감사 대응이 필요하다면 변경 이력, 권한 분리, 자동 탐색 기능이 있는 시스템이 유리합니다. 서비스 시스템이 여러 조직과 절차에 걸쳐 운영되는 관점은 범정부 IT 서비스 시스템 관련 설명에서도 참고할 수 있습니다.

• 엑셀 중심: 자산 수가 적고 담당자 한 명이 관리할 때 부담이 낮습니다.
• 오픈소스: 내부에 리눅스와 데이터베이스 운영 역량이 있을 때 비용 효율이 좋아집니다.
• SaaS: 빠른 도입, 지점 간 접속, 정기 업데이트를 중시할 때 적합합니다.
• 구축형 상용 솔루션: 사내 인증 연동, 세밀한 권한, 감사와 기술지원이 중요할 때 검토할 만합니다.

초보자가 자주 묻던 질문은 운영 규칙에 답이 있었습니다

등록 범위와 실사 주기를 결정하는 FAQ

Q. 마우스와 케이블도 모두 등록해야 하나요?
모든 물품을 같은 수준으로 관리할 필요는 없습니다. 가격, 보안 영향, 장애 영향, 분실 가능성 중 하나라도 큰 자산을 개별 관리하고 저가 소모품은 품목별 수량으로 관리하는 편이 현실적입니다. 예외적으로 전원 케이블이나 광모듈처럼 저렴해도 장애 복구에 중요한 부품은 예비 수량과 보관 위치를 기록하는 것이 좋습니다.

Q. 자산 실사는 얼마나 자주 해야 하나요?
노트북처럼 이동이 잦은 장비는 분기 또는 반기 단위로 확인하고, 랙에 고정된 서버와 네트워크 장비는 정기 점검 일정에 맞춰 확인할 수 있습니다. 전체 실사만 기다리지 말고 입사, 퇴사, 자리 이동, 수리 입고, 장비 반출 이벤트가 발생할 때 즉시 상태를 갱신해야 기록이 오래 유지됩니다.

Q. 자동 탐색 도구가 있으면 수기 관리가 필요 없나요?
자동 탐색은 IP, 운영체제, 설치 소프트웨어 같은 기술 정보를 빠르게 모으지만 구매일, 소유 부서, 실제 사용자, 보증 계약과 폐기 승인까지 판단하지는 못합니다. 에이전트 설치가 제한된 장비도 있으므로 자동 수집 결과와 구매·인사·현장 데이터를 결합해야 합니다.

• Q. 누가 수정 권한을 가져야 하나요? 조회 권한은 넓게 제공하되 삭제와 일괄 변경은 소수 관리자에게 제한합니다.
• Q. 퇴사자 장비는 어떻게 처리하나요? 계정 회수, 데이터 보존, 장비 점검, 재고 전환을 하나의 인수 절차로 묶습니다.
• Q. 폐기한 장비 기록도 지워야 하나요? 삭제하지 말고 폐기 일자, 승인자, 저장장치 파기 증빙을 남긴 채 상태만 변경합니다.
• Q. QR 코드는 꼭 필요한가요? 필수는 아니지만 현장에서 모바일로 자산 화면을 열고 실사 결과를 갱신할 때 시간을 크게 줄여 줍니다.

클라우드와 산업 장비까지 한 장부에 담을 수는 없습니다

자산관리 시스템이 해결하지 못하는 경계와 예외

한 달 동안 운영하며 확인한 가장 큰 한계는 IT자산관리 시스템이 보안 솔루션이나 모니터링 도구를 대신하지 않는다는 점입니다. 자산 목록에 서버가 등록돼 있어도 CPU 과부하나 디스크 장애를 실시간으로 알려주지는 않습니다. 취약점 점검, 로그 분석, 백업 복구 테스트 역시 별도 도구와 절차가 필요하며 자산관리 시스템은 그 결과를 연결하는 기준점으로 활용해야 합니다.

클라우드 자산은 생성과 삭제가 빠르므로 월 1회 수기 실사만으로 정확도를 유지하기 어렵습니다. 클라우드 API와 태그 정책을 이용해 자동 동기화하되, 짧게 생성되는 임시 인스턴스를 어디까지 보관할지 기준을 정해야 합니다. 개발자가 임의로 만든 테스트 자원, 관리형 데이터베이스, 서버리스 함수, SaaS 관리자 계정은 전통적인 물리 장비 항목만으로 표현하기 어렵다는 예외도 있습니다.

공장 설비의 제어 장치, 의료기기, 연구 장비처럼 중단 위험이 큰 운영기술 자산은 일반 사무용 PC와 같은 방식으로 자동 스캔하면 안 될 수 있습니다. 제조사 보증과 안전 규정을 먼저 확인하고, 수동 조사 또는 수동 등록 방식을 선택해야 합니다. 개인정보가 저장된 장비의 폐기 또한 일반 재고 처리와 분리해 데이터 삭제 및 저장매체 파기 증빙을 남겨야 합니다.

• 실시간 장애 감지는 서버·네트워크 모니터링 시스템의 역할로 분리합니다.
• 비밀번호와 인증키는 전용 비밀 관리 도구에 저장하고 자산 장부에는 넣지 않습니다.
• 클라우드 자산은 계정, 리전, 비용 태그와 소유자를 API로 동기화합니다.
• 산업·의료 장비는 능동 스캔 전에 제조사와 현장 책임자의 승인을 확인합니다.
• 인수합병이나 외주 운영 환경에서는 자산의 법적 소유자와 실제 운영자를 따로 기록합니다.

모든 IT 정보를 하나의 화면에 넣는 것보다 각 시스템이 맡을 경계를 정하고 동일한 자산번호로 연결하는 편이 오래갑니다. VL시스템처럼 서버와 네트워크 구축 및 운영을 함께 살펴보는 관점이 필요한 이유도 여기에 있습니다. 장비 목록에서 출발하되 서비스 의존성, 변경 책임, 보안 예외까지 단계적으로 넓혀야 실제 현장에서 사용할 수 있는 IT 인프라 장부가 됩니다.