두 시스템이 각각 2대를 보고했다 — 실제 자산은 몇 대인가

두 시스템이 각각 2대를 보고했다 — 실제 자산은 몇 대인가

자산 분모의 신뢰도를 결정하는 신원 해소(identity resolution) 문제

게시 날짜

작성자

Team Riskmap

자산 가시성 논의는 대개 "얼마나 많이 찾았는가"로 수렴합니다. 그러나 여러 시스템에서 자산 정보를 모으는 순간, 더 어려운 질문이 생깁니다. 서로 다른 시스템이 보고한 두 레코드가 같은 장비인가, 다른 장비인가. 이 판정을 신원 해소(identity resolution)라고 합니다. 자산 관리 데이터를 교차 검증한 조사에서 조직은 예상보다 20~30% 많은 장비를 발견했고, 두 소스가 각각 2대를 보고할 때 실제 자산 수는 2대일 수도, 3대일 수도, 4대일 수도 있었습니다. 본 글은 신원 해소가 실패하는 유형을 정리하고, 그 실패가 커버리지·조치율 같은 모든 비율 지표를 어떻게 왜곡하는지 다룹니다.

1. 문제 정의 — 분모는 계산된 값이다

앞선 글 「보안 도구는 도입했는데, 자산의 28%에는 걸려 있지 않다」에서 우리는 커버리지를 계산하려면 조직 전체의 자산 분모가 필요하다고 정리했습니다. 이번 글은 그 분모가 어떻게 만들어지는지를 다룹니다.

분모는 세는 값이 아니라 계산되는 값입니다. EDR이 1,200대, 자산관리 시스템이 1,050대, Active Directory가 1,380대, 네트워크 스캔이 1,610대를 보고했다고 가정합니다. 조직의 실제 자산은 몇 대입니까?

단순 합계(5,240대)는 명백히 틀립니다. 최댓값(1,610대)도 틀립니다. 어떤 소스에도 없는 자산이 있을 수 있고, 한 장비가 여러 소스에 서로 다른 모습으로 들어가 있을 수도 있습니다. 정답을 얻으려면 레코드 간 동일성 판정을 거쳐야 하며, 이 판정이 틀리는 방향은 두 가지입니다.

  • 과소병합(under-merge) — 같은 장비가 2대, 3대로 세어집니다. 자산 수가 부풀고, 커버리지가 실제보다 낮게 보이며, 중복 티켓이 발행됩니다.

  • 과대병합(over-merge) — 서로 다른 장비가 한 대로 합쳐집니다. 자산 수가 줄고, 커버리지가 실제보다 높게 보이며, 한 대의 조치 완료가 다른 대의 미조치를 가립니다.

둘 중 위험한 쪽은 과대병합입니다. 과소병합은 담당자가 "같은 장비가 두 번 뜬다"고 신고하면서 드러나지만, 과대병합은 아무도 신고하지 않습니다. 사라진 자산은 화면에 없기 때문입니다.

2. 조사가 말하는 숫자

통계

출처

비고

20~30% — 여러 인벤토리 소스를 교차 검증했을 때 조직이 예상보다 더 많이 발견한 장비 비율

Sevco Security, State of the Cybersecurity Attack Surface

다중 소스 상관분석 기반

2대 → 2 / 3 / 4대 — 두 소스가 각각 2대를 보고할 때 가능한 실제 자산 수

동일

상관분석 없이는 확정 불가

반년 주기 검토 / 주 단위 비인가 자산 처리 — 자산 인벤토리 유지에 요구되는 최소 주기

CIS Critical Security Controls v8.1, Control 1

1번 통제가 전체 통제의 첫 항목

2,500개 이상 — 실제 기업 환경에서 관측된 서로 다른 운영체제 버전 수

Forescout Vedere Labs, The Riskiest Devices of 2025

장비 1,900만 대 분석

마지막 숫자가 신원 해소의 난이도를 보여줍니다. 한 조직의 자산은 단일 규격이 아니며, 수집 경로마다 다른 필드를 다른 형식으로 내놓습니다.

3. 식별자는 모두 결함이 있다

신원 해소는 식별자 비교로 수행됩니다. 문제는 현장에서 쓰이는 모든 식별자에 고유 결함이 있다는 점입니다.

식별자

결함

결과

IP 주소

DHCP 환경에서 수시로 바뀌고, 재사용된다

어제의 A가 오늘의 B — 과대병합

MAC 주소

모바일 OS의 주소 랜덤화, 가상 NIC·본딩·도커 브리지, L3 구간에서 유실

한 대가 여러 대로 — 과소병합

호스트명

재설치·복제 시 중복, 대소문자·도메인 접미사 표기 차이

양방향 오류

시리얼 번호

가상머신에서 동일 값 또는 공백, 제조사별 표기 불일치

가상 자산의 집단 과대병합

하드웨어 UUID

골든 이미지 복제 시 그대로 승계

수십 대가 한 대로

에이전트 ID

에이전트 재설치 시 새로 발급

같은 장비의 유령 레코드 생성

여기에 문자열 정규화 문제가 겹칩니다. 같은 값이 수집 경로에 따라 다르게 표현되는 경우입니다. 대소문자, 앞뒤 공백, 전각·반각 문자, 그리고 특히 유니코드 정규화 형식의 차이(macOS는 자모 분리형 NFD, Windows는 결합형 NFC를 쓰는 경우가 있습니다)가 그렇습니다. 사람 눈에는 똑같은 한글 경로·앱 이름이 바이트 수준에서 다르면, 비교는 "다른 자산"으로 결론을 냅니다. 이 한 가지 차이로 같은 장비의 같은 소프트웨어가 두 건으로 남는 사례는 드물지 않습니다.

4. 유령 자산 — 그리고 되살아나는 자산

신원 해소의 또 다른 축은 소멸 판정입니다.

폐기된 장비는 자산 목록에서 내려가야 합니다. 그러나 소스가 여럿이면 소멸 신호도 여럿입니다. EDR에서는 사라졌지만 AD 계정은 남아 있고, 자산관리 시스템에는 '사용 중'으로 표시돼 있습니다. 어느 신호를 믿을 것인가를 정하지 않으면 두 가지 일이 번갈아 일어납니다.

  • 유령 자산 잔존 — 없는 장비가 계속 집계되어 분모를 부풀립니다. 커버리지는 영원히 100%에 도달하지 못합니다.

  • 삭제된 자산의 부활 — 정리한 자산이 다른 소스의 오래된 보고로 다시 생성됩니다. 특히 복구 로직만 있고 정리 로직이 없는 구성에서 반복적으로 발생합니다.

실무에서 이 둘은 반드시 짝으로 설계해야 합니다. 오삭제를 되살리는 절차만 있고 유실된 자산을 정리하는 절차가 없으면, 잔존 레코드가 영구화됩니다. 반대로 정리만 공격적으로 돌면 잠시 꺼져 있던 장비가 사라집니다. 기준은 '마지막 관측 시점(last seen)'과 '관측 소스 수'를 함께 보는 것입니다.

5. 분모가 틀리면 모든 비율이 틀린다

신원 해소 오류는 한 화면에서 끝나지 않고 지표 전체로 전파됩니다.

  • 통제 커버리지 — 과소병합으로 분모가 20% 부풀면, 실제 95% 커버리지가 79%로 보고됩니다. 반대로 과대병합이 있으면 미보호 자산이 분모에서 사라져 커버리지가 실제보다 높게 나옵니다.

  • 취약점 조치율 — 중복 자산은 중복 티켓을 만들고, 한쪽만 닫히면 조치율은 올라가지만 노출은 그대로입니다.

  • EOL·수명 통계 — 같은 장비가 두 번 세어지면 지원 종료 자산 비율도 두 번 반영됩니다.

  • 라이선스·비용 산정 — 자산 수 기반 비용 계산이 중복분만큼 과다 집행됩니다.

즉 신원 해소는 자산 관리의 전처리 단계가 아니라, 모든 보안 지표의 분모를 결정하는 공정입니다.

6. 실무 — 신원 해소를 설계 대상으로 다루기

① 식별자에 등급을 부여한다. 강한 키(에이전트가 보고한 하드웨어 식별자 조합, 클라우드 인스턴스 ID)와 약한 키(IP, 호스트명)를 분리하고, 약한 키 단독으로는 병합하지 않습니다. 약한 키만 일치할 때는 '병합 후보'로 두고 사람이 확인합니다.

② 소스별 신뢰도를 선언한다. 같은 필드가 충돌할 때 어느 소스를 이길 것인지 미리 정합니다. 선언하지 않으면 마지막에 들어온 값이 이기고, 자산 정보는 수집 순서에 따라 흔들립니다.

③ 병합을 되돌릴 수 있게 만든다. 병합 이력을 보관하고 분리(unmerge)를 지원합니다. 과대병합은 발견되기 어려우므로, 발견됐을 때 복구가 가능해야 신뢰를 회복할 수 있습니다.

④ 수집 시점에 정규화한다. 대소문자·공백·유니코드 정규화 형식을 적재 직전 한 지점에서 통일합니다. 화면마다 비교 규칙을 따로 적으면 어느 한 화면에서 반드시 어긋납니다.

⑤ 모순 신호를 과대병합 탐지에 쓴다. 한 자산에 서로 다른 OS 계열이 보고되거나, 동일 시각에 다른 네트워크 세그먼트에서 관측되면 병합이 잘못됐을 가능성이 높습니다. 이런 모순을 경보로 올립니다.

⑥ 중복률과 미해소율을 지표로 보고한다. '병합 후보로 남은 레코드 수', '단일 소스에만 존재하는 자산 수', '최근 30일간 미관측 자산 수'를 월 단위로 봅니다. 이 세 숫자가 자산 분모의 신뢰도입니다.

7. 지금 확인해 볼 수 있는 세 가지 질문

  1. 우리 자산 수는 어떤 연산으로 나온 값인가? 한 시스템의 레코드 수라면, 그것은 조직의 자산 수가 아니라 그 시스템이 아는 자산 수입니다.

  2. 같은 장비가 두 건으로 남아 있는 사례를 몇 건으로 추정하는가? 추정할 수 없다면 커버리지 수치의 오차 범위도 알 수 없습니다.

  3. 폐기한 자산은 몇 일 후에, 어떤 근거로 목록에서 내려가는가? 기준이 없다면 분모에는 이미 없는 장비가 섞여 있습니다.

8. 결론

자산 가시성의 어려움은 수집에 있지 않습니다. 수집은 커넥터를 늘리면 됩니다. 어려운 쪽은 모아 놓은 레코드가 실제 세계의 몇 개 사물에 대응하는지 판정하는 일입니다.

두 소스가 각각 2대를 보고했을 때 답이 2대인지 4대인지 말할 수 없는 조직은, 커버리지도 조치율도 말할 수 없습니다. 보안 지표를 신뢰할 수 있게 만드는 작업은 새로운 탐지 기술이 아니라, 신원 해소 규칙을 명시적으로 정하고 그 규칙이 틀렸을 때 드러나게 만드는 데서 시작됩니다.

참고 자료

[1] Sevco Security, "State of the Cybersecurity Attack Surface" https://content.sevcosecurity.com/report-state-of-the-cybersecurity-attack-surface-h1-2024

[2] Center for Internet Security, "CIS Critical Security Controls v8.1 — Control 1: Inventory and Control of Enterprise Assets" https://www.cisecurity.org/controls/inventory-and-control-of-enterprise-assets

[3] Forescout Vedere Labs, "The Riskiest Devices of 2025" https://www.forescout.com/research-labs/the-riskiest-devices-of-2025/

[4] Riskmap Insights, 「보안 도구는 도입했는데, 자산의 28%에는 걸려 있지 않다」 (2026. 8. 15.)