유주영HR Operations · DSRVEN
작업 파일

자산관리 규정 개정 + 교체 대상 선정

HR-07규정승인 완료

규정을 법률·세무 / 정보보안 / 구조·실무 세 관점으로 분석해 전면 개정(대표이사 승인). 개정본과 개정이력을 같은 소스에서 생성하고, 신설한 노후화 기준을 자산대장에 적용해 교체 대상을 Tier로 선정.

기간
2026.03
스택
Python · python-docx
대체한 것
2년 묵은 규정 + 재량 판단

2년 넘게 손대지 않은 자산관리규정을 법률·세무·정보보안 세 관점으로 뜯어 전면 개정하고, 그 규정에서 새로 정의한 기준으로 실제 노후 자산 교체 대상을 선정했다. 규정을 쓰는 일과 데이터로 판단하는 일이 하나로 이어진 프로젝트.


1. 한눈에

역할 현행 규정 분석 · 개정안 작성 · 문서 생성 자동화 · 교체 대상 분석 (1인)
기간 2026-03
산출물 개정 규정 본문 · 개정이력 문서 · 별표 3종 · 교체 대상 추천 보고서
스택 Python · python-docx (문서 생성) · Excel 자산대장 분석
개정 규모 우선순위 [상] 15건 반영 · 조문 신설 3개 · 별표 신설 1개
승인 대표이사

2. 배경 — 무엇이 문제였나

현행 자산관리규정은 2023년 11월 개정본이었다. 그 사이 회사는 커졌고, 자산은 늘었고, 무엇보다 규정이 다루지 않는 상황이 실무에서 계속 발생했다.

구체적으로 이런 것들이었다.

  • 퇴사자가 장비를 반납할 때 데이터를 지웠는지, 계정 권한이 회수됐는지를 규정이 말하지 않았다. 실무에서는 하고 있었지만 근거 조항이 없었다.
  • 자산을 분실하거나 파손했을 때 얼마를 어떻게 변상하는지가 모호했고, 자칫 급여에서 일방적으로 공제하는 방식은 법적으로 문제가 될 수 있었다.
  • “노후 장비”의 기준이 없었다. 교체 요청이 올 때마다 개별 판단이었다.
  • 규정에 “렌탈 자산”과 “무형자산(SW 라이선스·SaaS)“이 들어 있었지만, 렌탈은 실제로 없었고 무형자산은 정보보안 영역이었다. 규정이 실제 관리 대상과 어긋나 있었다.

3. 어떻게 접근했나 — 세 개의 렌즈로 나눠 봤다

규정을 통째로 읽고 “고칠 것”을 찾는 대신, 성격이 다른 세 관점으로 각각 훑고 나온 항목을 우선순위로 정렬했다.

관점 무엇을 봤나 대표 결과
법률 / 세무 근로기준법상 임금 공제 · 법인세법상 내용연수 · 처분 시 세무 처리 임금 일방 공제 불가 원칙 명문화, 내용연수표 신설, 처분 시 세무 절차 규정
정보보안 퇴사·반납·처분 시 데이터 처리 · 단말 보안 설정 데이터 완전 삭제 의무, 디스크 암호화 의무, 자동 화면잠금, 계정 권한 회수 절차
규정 구조 / 실무 정의의 부재 · 절차의 공백 · 서식과 조문의 불일치 자산대장·가용재고·노후화·반납확인서 정의 신설, 지급/회수 절차 단계화

이렇게 나눈 이유는, 한 사람이 한 번에 읽으면 자기가 익숙한 관점의 문제만 보이기 때문이다. 실무자는 절차 공백을 보고, 법무는 책임 소재를 보고, 보안은 데이터를 본다. 세 번 나눠 읽으니 서로 다른 층위의 15건이 나왔다.

여기서 [상] 15건을 이번 개정에 반영하고, 나머지는 “차기 개정 검토” 항목으로 문서에 남겼다. 한 번에 다 고치려다 개정 자체가 늦어지는 것을 피했다.


4. 무엇을 바꿨나 — 핵심만

신설한 정의 (규정이 말할 수 있게 만든 것)

용어 정의 왜 필요했나
자산대장 보유 자산 현황을 기록·관리하는 전자 문서 “기록한다”의 대상이 어디인지 조문이 지목할 수 있게
가용재고 회수 후 초기화·점검이 완료되어 재지급 가능한 자산 회수품과 지급 가능품을 구분
노후화 구매일로부터 4년 경과 (법인세법 시행규칙 근거 명시) 교체 판단을 개별 재량에서 기준으로
자산 반납 확인서 반납 물품·사유·데이터 삭제 확인을 포함한 서식 퇴사 반납 절차의 근거

신설한 조문

  • 제11조의2 [분실 및 도난] — 기존 규정에 아예 없던 상황
  • 제12조 [데이터 보안] — 기존 “데이터 백업” 1개 항을 보안 전반으로 확장. 삭제 의무, 디스크 암호화(운영체제별 명시), 자동 화면잠금 시간까지 규정
  • 제19조의2 [규정 위반에 대한 조치] — 규정에 위반 시 조치가 없으면 규정이 아니라 권고가 된다

절차를 단계로 쪼갰다

지급은 “인수확인서를 받아야 한다” 한 줄이었다. 이를 지급 요청 → 재고 확인 → 인수확인서 작성(외관 상태 기록) → 자산대장 기록 4단계로 규정하고, 신규 입사자는 입사일까지 지급 완료를 원칙으로 명시했다.

회수도 마찬가지로 반납 기한(최종 근무일까지), 보안 조치 3종(데이터 삭제 / 시스템 접근 권한 회수 / 반납확인서 기록) 을 조문화했다.

법률 리스크를 명시적으로 닫았다

변상 기준을 과실 정도에 따라 단계별로 차등하도록 바꾸고, 임금·퇴직금에서 일방적으로 공제할 수 없으며 별도 변상 합의를 통해서만 청구 가능하다는 원칙을 명문화했다. 실무 편의보다 법적 안정성을 택한 조항이다.

서식(별표)을 조문과 맞췄다

조문만 고치면 현장에서 쓰는 종이가 그대로라서 아무것도 바뀌지 않는다. 인수확인서에 자산 분류 체크박스와 인수 시 상태란을, 반납확인서에 데이터 삭제 확인란과 계정 회수 확인란(보안 담당 서명 포함) 을 넣었다. 자산 분류 및 내용연수표는 새로 만들었다.


5. 문서를 코드로 생성했다

개정 규정 본문과 개정이력 문서를 워드 파일로 직접 편집하지 않고 스크립트로 생성했다.

  규정 본문 정의 (코드)          개정 내역 정의 (코드)
        │                              │
        ▼                              ▼
  generate_docx.py            generate_history_docx.py
        │  ├ 조문/항/호 계층 스타일 함수
        │  ├ 표 테두리·음영 헬퍼
        │  └ 표지·문서이력·본문·별표 조립
        ▼                              ▼
   개정 규정 .docx              개정이력 .docx

왜 이렇게 했나.

  • 규정 문서는 조 → 항 → 호의 계층이 있고, 각 층마다 들여쓰기와 번호 체계가 일정해야 한다. 손으로 편집하면 반드시 어긋나고, 어긋난 곳을 찾는 데 드는 시간이 더 크다.
  • 개정은 한 번에 끝나지 않는다. 검토 의견을 받아 여러 번 다시 뽑는다. 매번 손으로 고치면 그때마다 새로운 불일치가 생긴다.
  • 조문마다 왜 그렇게 바꿨는지를 코드 주석으로 함께 남겼다. 개정 사유가 문서 밖 기억이 아니라 산출물 옆에 붙어 있다.

결과적으로 개정본과 개정이력이 같은 소스에서 나온 두 산출물이 되어, 서로 어긋날 수 없게 됐다.


6. 그 규정으로 실제 판단을 내렸다 — 교체 대상 선정

개정에서 정의한 노후화(구매일로부터 4년) 기준을 자산대장에 적용해, 노후 노트북 교체 대상을 선정했다.

선정 조건 (경영진 지시 기준 반영)

항목 기준
직군 시니어 개발 직군 우선
자산 연수 2~3년 이상
사양 메모리 16GB 이하
제외 불용 자산 · 이미 교체 완료된 인원

Tier로 나눠 제출했다. 전체를 한 줄로 세우는 대신 최우선/차순위로 층을 나눠, 예산이 얼마가 되든 위에서부터 자르면 되도록 구성했다. 총 17명을 추천하고, 자산 연수와 본인 사용 기간을 분리해 표기했다 — 같은 4년 된 장비라도 처음부터 한 사람이 쓴 것과 중간에 넘겨받은 것은 다르기 때문이다.

부수적으로 교체 완료됐지만 구형 장비가 반납되지 않은 건을 발견해 함께 보고했다. 자산대장을 기준으로 대조하니 드러난 항목이고, 이런 누락이 바로 §4에서 반납 절차를 조문화한 이유였다.


7. 이 프로젝트의 구조 — 규정과 데이터가 한 바퀴 돌았다

   실무에서 반복되는 문제
            │
            ▼
   3개 관점 분석 (법률·세무 / 보안 / 구조·실무)
            │
            ▼
   규정 개정 ── "노후화 = 4년" 같은 기준을 정의로 확정
            │
            ▼
   자산대장에 그 기준을 적용 ── 교체 대상 17명 선정
            │
            ▼
   적용 과정에서 새 문제 발견 (미반납 자산)
            │
            └──► 다음 개정 항목으로

규정을 문서로 끝내지 않고 그 규정으로 실제 판단을 내려 본 것이 이 프로젝트의 실질이다. 기준이 없으면 판단이 매번 재량이 되고, 판단해 보지 않으면 기준이 현실과 맞는지 알 수 없다.