내 네트워크에 무엇이 연결되어 있나요?

네트워크에 무엇이 붙어 있는지 모르는 상태에서는 어떤 접근제어 정책도 정확할 수 없습니다. Genian NAC와 ZTNA는 GDPI(Genian Device Platform Intelligence)를 통해 에이전트 설치 없이도 네트워크에 연결된 단말의 제조사·제품명·모델까지 식별합니다.

이 글에서는 GDPI가 단말의 정체를 알아내는 원리부터, 식별 결과를 실제 정책으로 이어주는 600여 개의 분류 조건, 그리고 CVE와 EoL 정보가 자동으로 따라붙는 구조까지 차례로 살펴보겠습니다.

여러분의 사내 네트워크에는 지금 몇 대의 단말이 연결되어 있나요?

자산대장을 펼쳐 보면 답이 나올 것 같지만, 실제로 고객사에 방문해서 확인해 보면 대장에 적힌 숫자와 네트워크에서 실제로 살아 움직이는 숫자가 딱 맞아떨어지는 경우는 생각보다 드뭅니다. 회의실 구석의 IP 전화기, 창고 벽에 붙어 있는 라벨 프린터, 협력업체 직원이 잠깐 꽂아 둔 노트북, 누군가 테스트하려고 물려 놓고 잊어버린 IP 카메라. 이런 단말들은 자산대장에는 없지만 네트워크에는 분명히 있습니다.

보안의 출발점은 언제나 "무엇이 있는지 아는 것"입니다. 차단할 대상을 모르는데 차단 정책을 정확하게 세울 수는 없으니까요. 그래서 지니언스는 제품의 가장 아래층에 단말을 식별하는 기술을 두고 있습니다. 그것이 GDPI 입니다.

GDPI는 무엇을 하는 기술인가요?

GDPI는 Genian Device Platform Intelligence의 약자로, 네트워크에 연결된 장비의 제조업체·제품 이름·모델명을 다양한 지능형 방법으로 식별하는 기술입니다.

여기서 말하는 "장비 플랫폼(Device Platform)"이라는 표현부터 짚고 넘어가겠습니다. 지니언스가 말하는 장비 플랫폼은 네트워크에 접속하는 데 사용되는 모든 하드웨어 또는 소프트웨어, 혹은 하드웨어와 소프트웨어(OS)의 조합을 뜻합니다. 즉 "Windows 11이 설치된 PC"도 하나의 플랫폼이고, "Extreme AP3000 무선 AP"도 하나의 플랫폼입니다.

플랫폼이 식별되고 나면, 단순히 이름만 아는 데서 끝나지 않고 아래와 같은 정보들이 함께 따라옵니다.

• 장비 사진
• 장비 연결 유형(유선, 무선)
• 장비의 EoL(End of Life) 상태
• 장비의 EoS(End of Sale) 상태
• 제조사 및 제조 국가
• 제조업체 비즈니스 연속성 상태
• 제조업 자격 취득 현황

"MAC 주소 00:0C:29:… 인 어떤 것"이 아니라 "어느 제조사의 무슨 모델이고, 지원이 언제 끝나며, 어떤 취약점을 갖고 있는 장비"로 보이기 시작하는 것이죠. 관리자 화면에서는 노드 목록의 플랫폼 컬럼에서 바로 확인하실 수 있습니다.

[그림1] 노드 목록 – 플랫폼 컬럼에 식별된 장비 플랫폼이 표시됩니다

대시보드에서는 전체 자산이 어떤 플랫폼과 어떤 노드 타입으로 구성되어 있는지 한눈에 요약해 줍니다. 아래 화면은 테스트 환경이라 단순하지만, 실제 운영 환경에서는 이 위젯만 봐도 "우리 회사에 저런 장비가 있었나?" 싶은 것들이 꽤 보이실 겁니다.

[그림2] 대시보드 – 노드 플랫폼 및 노드 타입 분포

어떻게 단말의 정체를 알아내나요?

가장 많이 받는 질문입니다. "에이전트도 안 깔았는데 그걸 어떻게 알죠?"

답은 네트워크 센서에 있습니다. 단말은 네트워크에 연결되는 순간 반드시 무언가를 말합니다. IP를 받으려고 DHCP를 요청하고, 옆자리 장비를 찾으려고 ARP를 뿌리고, 프린터라면 자기가 프린터라고 광고합니다. Genian의 네트워크 센서는 L2 구간에서 이 대화를 듣고 단서를 모읍니다. 지니언스가 사용하는 주요 수집 방법은 다음과 같습니다.

능동적 방법 — 센서가 먼저 물어보고 답을 받는 방식

• HTTP / HTTPS 헤더 및 본문
• 웹 브라우저 사용자 에이전트(User-Agent)
• TELNET / SSH / SMTP 배너
• 오픈 포트(포트 스캔 결과)
• SNMP OID / Description
• SIP
• 그 외 다수

수동적 방법 — 단말이 스스로 흘리는 정보를 듣기만 하는 방식

• 웹 브라우저 사용자 에이전트(SPAN 포트 사용)
• MAC 주소(OUI)
• 호스트 이름
• DHCP Request
• UPnP
• HPSLP
• 그 외 다수

비유하자면 지문 채취와 지문 DB 대조에 가깝습니다. 센서가 모은 단서들을 GPDB(Genian Platform DataBase)에 저장된 패턴과 대조해서 "이 조합이면 이 제조사의 이 모델"이라고 판정하는 구조입니다. GPDB에는 GDPI와 관련된 장비 플랫폼 탐지 패턴과 플랫폼 정보가 저장되어 있고, 지니언스의 장비 플랫폼 엔지니어가 지속적으로 업데이트하고 있습니다.

그래서 에이전트를 설치할 수 없는 장비 — IP 카메라, 프린터, 산업용 제어기, 협력업체 노트북 — 도 네트워크에 붙는 순간 목록에 나타납니다. 오히려 에이전트를 못 붙이는 장비일수록 GDPI의 가치가 큽니다. 보안 사각지대는 대부분 그런 곳에서 생기니까요.

물론 에이전트가 설치된 단말이라면 더 정밀한 정보(설치 소프트웨어, 백신 상태, WMI 수집 정보 등)를 추가로 얻을 수 있습니다. GDPI는 "에이전트 대신"이 아니라 "에이전트 이전"에 동작하는 층이라고 이해하시면 되겠습니다.

600개 넘는 분류 조건은 어떻게 활용되나요?

식별은 출발점일 뿐입니다. 식별한 결과를 실제 정책으로 이어 주지 못하면, 예쁜 목록 하나가 늘어난 것에 지나지 않습니다.
Genian ZTNA 6.0 기준으로 노드그룹에 사용할 수 있는 분류 조건은 약 600개입니다. 크게 네 갈래로 나뉩니다.

• 노드 정보 — IP·MAC·노드타입·플랫폼·운영체제 유형·열린 포트·인증 사용자·태그·트래픽 등
• 에이전트 정보 — 설치 소프트웨어·백신·시스템 사용자 계정·USB 장치·WMI 정보수집·업데이트 상태 등
• 장비 정보 — 구매일자·제조사·내용연수·일련번호·책임자·책임부서 등 자산관리 항목
• 추가정보 수집 — GPI 검사결과, 외부 솔루션 연동 값 등

[그림3] 노드그룹 조건설정 화면 – 좌측이 조건 카테고리 목록입니다

이 중에서 GDPI와 직접 맞닿아 있는 조건들만 추려 보면 이렇습니다.

• 플랫폼 (10종) — 감지된/확인된 플랫폼이 같으면·다르면·문자열 포함·정규식 매칭, 플랫폼 일치여부, 플랫폼 상태
• 노드 타입 (11종) — 감지된/확인된 노드타입, 확장 노드타입, 노드타입 일치여부
• 운영체제 유형 (7종) — 감지된/확인된 OS 유형, 운영체제 이름 문자열 포함
• MAC 주소 (8종) — MAC 일치, OUI 일치, Vendor명 포함, 알려진 MAC, 정규식 매칭
• 플랫폼 보안 취약점 (21종) — CVE 존재 여부, CVSS 지표별 조건, 발행일자 기준 조건 등

여기서 눈여겨보실 부분은 "감지된"과 "확인된"이 조건마다 쌍으로 존재한다는 점입니다. 감지된 값은 GDPI가 자동으로 판별한 값이고, 확인된 값은 관리자가 수동으로 지정한 값입니다. 그리고 이 둘을 비교하는 "플랫폼 일치여부", "노드타입 일치여부" 조건이 따로 있습니다. 자동 판별 결과와 관리자가 등록해 둔 값이 어긋나는 노드를 잡아내는 데 쓰는 조건이지요. MAC 위조가 의심되는 상황을 골라내는 용도로도 활용하실 수 있습니다.

조건을 조합해 노드그룹을 만들고, 그 노드그룹을 노드정책이나 제어정책에 연결하면 "식별 → 분류 → 조치"가 자동으로 이어집니다.

새로 출시되는 단말도 식별이 되나요?

당연히 나올 수밖에 없는 질문입니다. 스마트폰만 해도 한 달에 몇 종씩 새로 나오니까요.
GPDB는 매주 업데이트됩니다. (Professional / Enterprise 에디션은 매주, Basic 에디션은 매월 업데이트됩니다.) 관리자가 별도로 무언가를 등록하지 않아도, 시장에 새로 나온 장비가 GPDB에 반영되면 그 다음부터는 자동으로 식별됩니다.

실제로 2026년 8월 6일자 업데이트에는 12종의 플랫폼이 추가되었습니다. 면면을 보시면 범위가 짐작되실 겁니다.

• Extreme AP3000 무선 AP, Handreamnet SG9330GX 스위치
• Samsung Galaxy Watch Ultra2 · Galaxy Watch 9 (웨어러블)
• SmartTouch ST-QERA75 전자칠판 (ICS/OT → IoT/OT)
• TJONE TNO-5704SVRT · TNP-2836SZRT 네트워크 카메라 (보안장비)
• Huawei · Lava · Motorola · Vivo · ZTE 스마트폰 5종

현재 정책서버가 어떤 시점의 데이터를 갖고 있는지는 [시스템] – [업데이트 관리] – [운영정보 데이터] 에서 확인하실 수 있습니다. 노드정보 감지 데이터가 곧 GPDB이고, CVE 업데이트 정보도 같은 화면에서 갱신 시각을 확인할 수 있습니다.

[그림5] 시스템 > 업데이트 관리 > 운영정보 데이터 – 항목별 갱신 시각

그럼에도 플랫폼이 탐지되지 않는 경우가 있습니다. 원인은 대체로 두 가지입니다.

• 정보 부족 — 장비가 패킷을 보내지 않거나 어떤 요청에도 응답하지 않는 경우입니다. OS 방화벽이 활성화되어 있을 가능성이 큽니다.
• GPDB에 일치하는 패턴 없음 — 노드 정보에는 특정 플랫폼의 증거가 있지만, GPDB에 아직 해당 패턴이 없는 경우입니다.

두 번째 경우라면 "잘못된 플랫폼 보고" 기능으로 해당 노드 정보를 Genian Cloud로 보낼 수 있습니다. 보고가 접수되면 지니언스의 플랫폼 엔지니어가 패턴을 조사해서 GPDB에 반영합니다. 기본적으로는 알 수 없는 플랫폼 노드에 대해 매일 자동 전송되도록 되어 있고, 폐쇄망이나 내부 정책상 외부 전송을 원하지 않으시면 [설정] – [환경설정] – [노드관리] – [노드정보 검색] – [플랫폼미탐지보고] 옵션을 Off 로 두시면 됩니다.

패턴이 반영되기 전까지는 관리자가 직접 지정하실 수도 있습니다. [관리] – [노드] 에서 해당 노드의 IP 주소를 클릭하고, 플랫폼상태 탭에서 플랫폼을 수동 입력하면 됩니다. 수동으로 지정한 노드는 노드보기에서 플랫폼 이름 옆에 아이콘이 표시되어 자동 감지 값과 구분됩니다.

CVE·EoL 추적은 어떻게 자동화되나요?

MITRE가 제공하는 CVE 데이터베이스에는 매월 1,000건이 넘는 새로운 취약점이 등록됩니다. 이걸 관리자가 일일이 자사 장비와 대조하는 것은 현실적으로 불가능에 가깝습니다.

GDPI가 이 지점에서 한 번 더 일을 합니다. 플랫폼이 식별되면 그 플랫폼에 매핑된 CVE가 노드에 자동으로 따라붙습니다. "우리 회사에 이 취약점 영향을 받는 장비가 있나?"를 사람이 찾는 게 아니라, 제품이 먼저 알려주는 구조인 셈이지요.

그리고 이 CVE 정보를 그대로 노드그룹 조건으로 쓸 수 있습니다. 사용 가능한 CVE 조건은 21종입니다.

• 존재 여부 — CVE가 존재하면 / 존재하지 않으면, CVE ID에 문자열 포함 / 미포함
• CVSS 지표 — Base Severity, Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality, Integrity, Availability
• 시점 기준 — 발행일자가 이후 / 이전 / 이내, 최근 수정일자가 이후 / 이전 / 이내
• 설명 — CVE 설명에 특정 문자열 포함 / 미포함

예를 들어 "Base Severity가 Critical이면서 최근 30일 이내에 발행된 CVE를 가진 노드"라는 노드그룹을 하나 만들어 두면, 조건에 해당하는 장비가 네트워크에 나타나는 순간 그룹에 자동으로 편입됩니다. 여기에 알림이나 격리 액션을 연결해 두면 긴급 취약점 대응이 사람 손을 덜 타게 됩니다.

EoL·EoS 추적도 같은 방식입니다. 플랫폼 조건 중 "플랫폼 상태" 조건을 쓰면 아래 세 가지 상태로 노드를 골라낼 수 있습니다.

• 판매종료 (End of Sale) — 신규 구매가 불가능한 장비
• 지원종료 (End of Life) — 제조사 지원이 끝나 보안 패치를 더 이상 받을 수 없는 장비
• 사업종료 (Out of Business) — 제조사 자체가 사업을 접은 장비

세 번째 항목이 특히 실무에서 유용합니다. 제조사가 없어진 장비는 취약점이 발견되어도 패치가 나올 수 없으니, 사실상 교체 외에는 답이 없는 자산이기 때문입니다. 이런 노드를 자동으로 묶어 두면 자산 교체 예산을 잡을 때, 그리고 보안 감사 대응 자료를 만들 때 "어림잡은 숫자"가 아니라 근거 있는 목록을 그대로 제출하실 수 있습니다.

어떤 단말까지 인식 가능한가요?

원칙은 단순합니다. IP를 사용하면서 네트워크에 무언가를 말하는 것이라면 대상입니다. 식별된 장비에는 아래와 같은 노드 타입이 부여됩니다.

• PC / 모바일 단말 / 서버
• 네트워킹 장비 / 라우터 / 스위치 / 무선 장비
• 보안 장비 / 프린터 / IP 전화(VoIP)
• IoT · OT · 기타
• 정책서버 / 네트워크센서 / 가상센서 / 스위치 포트 등 Genian 자체 장비
• 사용자 정의 노드 타입(직접 정의해서 추가 가능)

여기에 더해 확장 노드 타입으로 한 단계 더 세분화됩니다. 같은 IoT/OT 안에서도 오디오·영상 장치인지, 산업용 제어 장비(ICS/OT)인지, 게이밍 디바이스인지가 구분되고, 같은 모바일 안에서도 스마트폰인지 웨어러블인지 태블릿인지가 나뉩니다.

솔직하게 한계도 말씀드리겠습니다. 방화벽으로 모든 요청을 막고 아무 응답도 하지 않는 장비, GPDB에 아직 패턴이 없는 갓 출시된 장비는 곧바로 식별되지 않을 수 있습니다. 다만 앞 절에서 말씀드린 미탐지 보고와 수동 지정으로 보완할 수 있고, 보고가 쌓일수록 GPDB가 좋아지는 구조라서 시간이 지날수록 사각지대는 줄어듭니다.

참고로 지니언스는 GDPI가 식별하는 장비 목록을 외부에 공개하고 있습니다. https://www.genians.com/dpi-list/ 에서 제조사·모델명으로 직접 검색해 보실 수 있고, 플랫폼별 CVE·EOS·EOL·노드 타입·제조사 본사 국가까지 확인할 수 있습니다. 도입을 검토 중이시라면 보유하고 계신 장비를 먼저 몇 개 검색해 보시는 것도 좋은 방법입니다.

마치며

보안 업계에서 오래 회자되는 말이 있습니다. "보이지 않는 것은 관리할 수 없고, 관리할 수 없는 것은 보호할 수 없다."
Zero Trust도 결국 같은 자리에서 출발합니다. 아무것도 신뢰하지 않고 매번 검증하겠다는 원칙은 훌륭하지만, 검증할 대상이 무엇인지 모르면 그 원칙은 적용될 수가 없습니다. GDPI는 그 첫 번째 관문에 해당하는 기술입니다.

스프레드시트로 관리하는 자산대장은 작성을 마친 그 순간부터 낡기 시작합니다. 반면 네트워크에 붙는 순간 자동으로 식별되고, 매주 갱신되는 데이터베이스로 정보가 최신화되며, 취약점과 지원종료 정보까지 함께 따라붙는 목록은 시간이 지날수록 정확해집니다. 자산관리와 접근제어를 각각 다른 숙제로 두고 계셨다면, 두 숙제가 같은 데이터 위에서 풀린다는 점을 한번 확인해 보시기 바랍니다.

혹시 지금 사용 중인 환경에서 미탐지 노드가 많아 고민이시거나, 식별 결과를 어떤 정책으로 연결해야 할지 막막하시다면 언제든 지니언스를 찾아주세요. 함께 고민해 드리겠습니다. 감사합니다.