AI가 90시간 만에 IoT 취약점 99개 발견? 임베디드 보안의 변화 񟿿

수작업으로는 약 9개월이 걸리던 임베디드 TCP/IP 스택 분석이 약 90시간으로 줄어들었다면, 그 사이 AI는 무엇을 찾아냈을까요?

2026년 11월 공개된 Forescout Vedere Labs의 연구는 그 답을 숫자로 보여줍니다. 연구진은 상용 생성형 AI와 정적·동적 분석 도구를 결합해 임베디드 TCP/IP 스택 10개를 분석했고, 총 99개의 취약점을 확인했습니다. 이 가운데 66개는 기존에 알려지지 않았던 신규 취약점이었습니다.

이는 단순히 분석 속도가 빨라졌다는 이야기가 아닙니다. IoT 기기 곳곳에 오랫동안 숨어 있던 네트워크 보안 문제를, 이전보다 훨씬 넓은 범위에서 찾아낼 수 있게 됐다는 의미입니다.

분석 항목	결과
분석 대상	임베디드 TCP/IP 스택 10개
확인된 취약점	99개
신규 취약점	66개
고위험·치명적 신규 취약점 비율	52%
정적 분석 시간	약 10시간
동적 검증 포함 전체 시간	약 90시간
정적 분석 모델 비용	약 935달러

특히 주목할 점은 분석 대상이 일반적인 웹 애플리케이션이 아니라 IoT 장비의 공통 네트워크 기반인 TCP/IP 스택이라는 사실입니다. TCP/IP 스택은 스마트홈 카메라, 산업용 컨트롤러, 의료기기, 라우터, 스마트미터, 빌딩 자동화 장비처럼 서로 다른 제품군에 반복적으로 탑재됩니다.

즉, 하나의 공통 스택에서 발견된 결함은 단일 제품의 문제가 아닐 수 있습니다. 동일한 네트워크 라이브러리를 사용하는 수십 개, 많게는 수백 개 제품으로 영향을 넓힐 가능성이 있습니다.

AI가 IoT 취약점을 찾는 방식

이번 사례에서 AI는 펌웨어를 통째로 읽고 “취약점을 찾아 달라”고 요청받은 것이 아닙니다. 연구진은 AI의 추론 능력에 정적 분석, 역공학, 에뮬레이션, 동적 검증을 연결했습니다.

분석 흐름은 다음과 같습니다.

1. 펌웨어·소스코드·바이너리에서 CPU 구조와 소프트웨어 구성을 확인합니다.
2. Semgrep, Joern 같은 정적 분석 도구가 의심스러운 코드 패턴을 후보로 추출합니다.
3. 네트워크 패킷처럼 외부 공격자가 조작할 수 있는 입력이 해당 코드까지 실제로 도달하는지 확인합니다.
4. AI 에이전트가 코드와 데이터 흐름을 검토해 악용 가능성을 판단합니다.
5. 에뮬레이션 또는 실행 환경에서 PoC를 생성하고 재현에 성공한 문제만 최종 취약점으로 확정합니다.

이 방식의 핵심은 AI 단독 판단이 아니라는 점입니다. 정적 분석 도구가 후보를 넓게 찾고, AI가 우선순위와 맥락을 판단하며, 실행 기반 검증이 최종 사실 여부를 가리는 구조입니다.

빨라진 발견 속도, 더 커진 IoT 공급망의 과제

확인된 취약점 가운데 상당수는 메모리 손상, 정수 계산 오류, 입력 검증 부족, 프로토콜 파싱 문제였습니다. 이런 결함은 악의적인 패킷 하나로 서비스 중단, 비정상 동작, 경우에 따라 원격 코드 실행으로 이어질 수 있습니다.

그러나 AI가 취약점을 빠르게 찾는다고 해서 IoT 환경이 자동으로 안전해지는 것은 아닙니다. 취약한 TCP/IP 스택이 확인되면 다음 단계가 더 어렵기 때문입니다.

• 어떤 제품이 해당 스택과 버전을 사용하고 있는가?
• 제조사는 영향을 받는 장비를 정확히 식별할 수 있는가?
• 운영 중인 산업·의료·에너지 장비에 안전하게 패치를 배포할 수 있는가?
• 이미 단종됐거나 제조사가 사라진 제품은 어떻게 보호할 것인가?

결국 이번 연구가 보여준 것은 두 가지입니다. AI는 IoT 보안의 사각지대를 훨씬 빠르게 비출 수 있게 됐습니다. 반면 취약점을 찾는 속도만큼 빠르게 제품을 식별하고 패치하지 못한다면, 그 빛은 더 많은 위험 노출을 드러내는 경고가 될 수도 있습니다.

AI는 코드를 읽는 대신, IoT 분석 파이프라인을 움직인다

AI가 IoT 펌웨어를 한 번 훑고 취약점을 스스로 찾아낸다는 그림은 매력적입니다. 하지만 실제 현장은 훨씬 더 정교합니다. 이번 사례의 핵심은 거대언어모델(LLM)이 단독으로 보안 연구를 수행했다는 데 있지 않습니다. 정적 분석, 역공학, 도달 가능성 판단, 에뮬레이션, 동적 검증을 하나의 흐름으로 연결하고, 그 사이의 판단 작업을 AI가 가속했다는 점에 있습니다.

즉, AI는 모든 코드를 완벽히 이해하는 마법의 탐지기가 아니라, 기존 보안 도구가 만든 단서를 읽고 우선순위를 정하며 다음 분석 단계를 실행하는 오케스트레이터에 가깝습니다.

펌웨어 분석은 ‘한 번의 질문’으로 끝나지 않는다

IoT 장비의 펌웨어는 일반 애플리케이션보다 분석 난도가 높습니다. 소스코드가 없는 경우가 많고, 함수명과 변수명이 제거된 바이너리만 남아 있을 수 있습니다. 또한 CPU 아키텍처, 엔디언 방식, 메모리 배치, 드라이버 의존성도 제품마다 다릅니다.

그래서 분석은 다음과 같은 단계로 진행됩니다.

펌웨어 또는 소스코드 확보
        ↓
CPU 아키텍처·파일 구조·실행 코드 식별
        ↓
정적 분석 규칙으로 의심 코드 탐색
        ↓
외부 네트워크 입력이 도달하는지 추적
        ↓
AI가 코드·데이터 흐름을 해석해 악용 가능성 평가
        ↓
에뮬레이션 또는 빌드 환경에서 실제 실행
        ↓
PoC 재현 후 취약점 확정

이 흐름에서 정적 분석 도구는 “위험해 보이는 코드 위치”를 찾고, AI는 “이 코드가 실제 공격 경로에 놓여 있는지”를 추론합니다. 마지막으로 동적 검증이 “실제로 재현되는 문제인지”를 확인합니다.

결정론적 도구가 후보를 만들고, AI가 맥락을 읽는다

Semgrep, Joern, Ghidra 같은 도구는 정해진 규칙과 코드 구조에 따라 일관되게 동작합니다. 예를 들어 TCP/IP 스택에서 다음과 같은 패턴을 찾을 수 있습니다.

• 패킷 길이보다 작은 버퍼에 데이터를 복사하는 코드
• 길이 계산 과정에서 발생할 수 있는 정수 오버플로
• DNS, DHCP, ICMPv6 헤더를 충분히 검증하지 않는 파서
• NULL 포인터 확인 없이 실행되는 함수 호출
• 네트워크 입력값이 검증 없이 메모리 연산에 사용되는 흐름

하지만 이런 탐지 결과가 곧바로 취약점은 아닙니다. 정적 분석은 보수적으로 동작하기 때문에, 실제로는 호출되지 않는 코드나 공격자가 도달할 수 없는 경로까지 후보로 올립니다. 여기서 AI의 역할이 중요해집니다.

AI 에이전트는 함수 호출 관계, 변수 값의 이동, 입력값 검증 여부, 오류 처리 흐름을 함께 살펴보며 다음 질문에 답합니다.

“이 코드가 위험해 보이는가?”가 아니라, “외부 공격자가 조작한 패킷으로 이 지점까지 도달해 메모리 손상이나 비정상 동작을 유발할 수 있는가?”

이 과정은 단순 키워드 검색보다 훨씬 깊은 판단을 요구합니다. AI는 후보의 설명을 만들고, 필요한 추가 분석을 수행하며, 더 복잡한 모델이나 도구 호출이 필요한 지점을 골라낼 수 있습니다.

IoT 펌웨어에서는 ‘도달 가능성’이 특히 중요하다

IoT 보안에서 취약점의 위험도는 코드 결함 자체만으로 정해지지 않습니다. 장비의 네트워크 노출 방식, 사용하는 프로토콜, 인증 구조, 배포 환경까지 고려해야 합니다.

예를 들어 버퍼 오버플로 가능성이 있는 함수가 발견됐더라도 다음 조건이 충족되지 않으면 실제 공격으로 이어지지 않을 수 있습니다.

1. 외부 네트워크 패킷이 해당 함수까지 전달돼야 합니다.
2. 공격자가 문제를 유발하는 특정 필드를 제어할 수 있어야 합니다.
3. 사전에 인증을 통과하지 않아도 경로에 도달할 수 있어야 합니다.
4. 오류 처리나 길이 검증 로직이 중간에 공격을 차단하지 않아야 합니다.
5. 실제 장비 또는 에뮬레이션 환경에서 비정상 동작이 재현돼야 합니다.

AI 보조 하니스는 바로 이 조건들을 체계적으로 검토합니다. 정적 분석이 수백 개의 의심 사례를 제시하면, AI는 코드 흐름을 추적해 우선 검증할 후보를 좁힙니다. 그 결과 연구진은 362개의 정적 분석 후보를 대상으로 실제 검증을 수행할 수 있었습니다.

AI의 판단만으로 취약점을 확정할 수 없는 이유

LLM은 코드를 설명하고, 결함 가능성을 추론하며, 테스트 입력을 제안하는 데 뛰어납니다. 그러나 그럴듯한 설명을 사실처럼 제시할 수도 있습니다. 특히 IoT 바이너리 분석에서는 역컴파일 결과가 원본 코드와 다를 수 있어, AI가 잘못된 코드 표현을 기반으로 판단할 위험도 존재합니다.

따라서 최종 단계에는 반드시 동적 검증이 필요합니다.

• 펌웨어를 빌드하거나 에뮬레이터에서 실행합니다.
• 조작된 네트워크 패킷을 전송합니다.
• 크래시, 메모리 오류, 비정상 응답, 권한 상승 가능성을 관찰합니다.
• 재현 가능한 Proof of Concept을 확보합니다.

이 검증 단계를 통과해야 비로소 “실제 취약점”으로 확정할 수 있습니다. AI는 이 과정에서 테스트 코드와 패킷 구조를 생성하고, 실행 결과를 해석하며, 재현 절차를 문서화하는 역할을 수행할 수 있습니다. 하지만 물리 장비, 드라이버, 특수 주변기기에 의존하는 펌웨어라면 인간 전문가의 개입이 여전히 필요합니다.

핵심은 AI 도입이 아니라 분석 흐름의 자동화다

이 기술이 보여주는 가장 중요한 변화는 AI가 사람을 완전히 대체한다는 점이 아닙니다. 오히려 반복적이고 시간이 많이 드는 분석 단계를 자동화해, 보안 전문가가 더 어려운 판단에 집중할 수 있게 한다는 데 있습니다.

역할	담당 주체
코드 패턴 탐색	정적 분석 도구
바이너리 구조 복원	역공학 도구와 분석가
데이터 흐름·공격 가능성 판단	AI 에이전트와 전문가
패킷·PoC 생성	AI와 자동화 스크립트
실제 재현과 최종 확정	에뮬레이션, 동적 분석, 인간 검증
패치 영향 판단과 제품 대응	제조사·보안팀·운영팀

결국 IoT 보안에서 경쟁력을 만드는 것은 “AI에게 취약점을 찾아달라고 묻는 것”이 아닙니다. 발견, 판정, 검증, 제품 식별, 패치 대응까지 이어지는 분석 파이프라인을 구축하는 것입니다.

AI는 코드를 대신 읽는 단순한 도구가 아니라, 수많은 보안 도구와 분석 단계를 연결해 더 빠르게 움직이게 만드는 새로운 운영 계층으로 자리 잡고 있습니다.

IoT 공통 네트워크 스택이 공급망 위험으로 번지는 구조

스마트미터와 IP 카메라, 산업용 컨트롤러는 전혀 다른 제품처럼 보입니다. 제조사도 다르고, 쓰이는 장소와 기능도 다릅니다. 그러나 장비 내부에서 동일하거나 유사한 TCP/IP 스택을 사용한다면 이야기는 달라집니다. 한 곳에서 발견된 결함이 공급망을 타고 수십, 수백 개 IoT 제품으로 확산될 수 있기 때문입니다.

제품이 아니라 ‘공통 부품’을 봐야 하는 이유

많은 IoT 장비는 제한된 메모리와 처리 성능에서 동작합니다. 제조사는 네트워크 통신 기능을 처음부터 직접 개발하기보다, 검증된 임베디드 TCP/IP 스택을 가져와 펌웨어에 통합하는 경우가 많습니다.

예를 들어 다음과 같은 구성 요소가 여러 제품에 재사용될 수 있습니다.

• TCP·UDP 패킷 처리
• DNS, DHCP, HTTP, MQTT 프로토콜 처리
• IPv4·IPv6 연결 기능
• 버퍼 관리와 패킷 길이 계산
• 네트워크 인터페이스 제어 코드

이 공통 코드에 버퍼 오버플로, 정수 오버플로, 입력값 검증 누락 같은 문제가 있다면 제품별 애플리케이션이 달라도 동일한 취약점이 남을 수 있습니다. 즉, 취약점의 출발점은 한 줄의 코드이지만, 영향 범위는 하나의 제품군을 넘어설 수 있습니다.

IoT 공급망 취약점은 “어느 제품이 취약한가”보다 “어떤 공통 소프트웨어가 들어갔는가”를 먼저 확인해야 합니다.

하나의 결함이 여러 산업으로 퍼지는 과정

공통 네트워크 스택 취약점은 보통 다음 경로로 확산됩니다.

1. 스택 개발사 또는 오픈소스 프로젝트가 네트워크 라이브러리를 배포합니다.
2. 칩 제조사, 운영체제 업체, 솔루션 기업이 해당 코드를 SDK나 펌웨어에 포함합니다.
3. 장비 제조사가 이를 기반으로 카메라, 게이트웨이, 계측기, 제어기를 만듭니다.
4. 최종 사용자는 내부 구성 요소를 알지 못한 채 장비를 설치하고 장기간 운영합니다.
5. 나중에 공통 스택의 취약점이 발견되면, 영향을 받는 제품을 역추적해야 합니다.

문제는 이 과정에서 코드의 출처와 버전 정보가 사라지거나 불완전해지는 경우가 많다는 점입니다. 제조사가 동일한 스택을 사용했더라도 일부 기능만 수정했을 수 있고, 오래된 포크 버전을 유지했을 수도 있습니다. 따라서 취약점 하나가 공개됐다고 해서 영향 제품을 즉시 정확히 파악하기는 어렵습니다.

패치가 있어도 위험이 끝나지 않는 이유

공통 TCP/IP 스택 개발자가 보안 패치를 배포하더라도, 실제 IoT 환경에서는 다음 단계가 남습니다.

• 장비 제조사가 패치를 자신의 펌웨어에 통합해야 합니다.
• 통합된 펌웨어가 하드웨어별로 테스트를 통과해야 합니다.
• 운영자가 장비를 중단하거나 재부팅할 수 있는 일정이 필요합니다.
• 현장에 설치된 장비까지 업데이트가 전달돼야 합니다.

산업 현장, 병원, 에너지 시설처럼 운영 중단 비용이 큰 환경에서는 이 과정이 특히 느립니다. 제품이 단종됐거나 제조사가 사라진 경우에는 공식 패치가 제공되지 않을 수도 있습니다. 이때 취약점은 기술 문제가 아니라 장기 운영과 자산 관리의 문제가 됩니다.

AI 분석이 중요한 이유: 숨은 공통점을 찾기 위해서

AI 기반 임베디드 취약점 분석은 펌웨어와 바이너리 속에 숨어 있는 공통 스택을 더 빠르게 조사하는 데 의미가 있습니다. 소스코드가 없는 장비라도 함수 구조, 패킷 처리 로직, 알려진 코드 패턴을 분석해 사용된 네트워크 구성 요소와 잠재적 결함을 추정할 수 있습니다.

특히 대규모 IoT 환경에서는 다음과 같은 질문에 답하는 데 도움이 됩니다.

• 우리 조직의 장비 중 같은 TCP/IP 스택을 쓰는 제품은 무엇인가?
• 취약한 버전이 어느 펌웨어에 포함돼 있는가?
• 외부 네트워크에서 실제로 공격 가능한 장비는 무엇인가?
• 즉시 패치할 수 없는 장비는 어떻게 분리·완화할 것인가?

결국 IoT 보안의 핵심은 개별 장비를 따로 점검하는 데만 있지 않습니다. 공통 네트워크 스택이라는 연결 고리를 찾아내고, 취약점 발견부터 제품 식별·패치·격리까지 이어지는 대응 체계를 만드는 것이 더 중요합니다.

IoT 빠른 분석에도 남아 있는 사각지대

AI 보안 하니스는 취약점 후보를 빠르게 넓게 찾는 데 큰 강점을 보입니다. 그러나 후보가 실제 공격으로 이어지는지, 운영 중인 장비에 얼마나 큰 영향을 주는지를 판정하는 일은 전혀 다른 문제입니다. 특히 소스코드가 없는 IoT 펌웨어에서는 AI의 추론도 역공학 품질, 실행 환경, 실제 하드웨어 제약이라는 벽에 부딪힙니다.

후보 탐지와 실제 취약점 판정은 다르다

정적 분석 도구는 버퍼 길이 계산, 포인터 처리, 패킷 필드 검증처럼 위험해 보이는 코드 패턴을 빠르게 찾아냅니다. 하지만 코드에 위험한 연산이 있다는 사실만으로 곧바로 취약점이 확정되지는 않습니다.

실제 위험으로 판단하려면 최소한 다음 조건을 확인해야 합니다.

• 외부 공격자가 해당 코드 경로에 도달할 수 있는가
• 공격자가 입력값을 충분히 제어할 수 있는가
• 메모리 손상이나 오류가 실제로 발생하는가
• 오류가 단순 서비스 장애인지, 코드 실행까지 가능한 문제인지
• 운영 환경의 방어 기능이 공격을 차단하는지

예를 들어, 패킷 길이를 잘못 계산하는 코드가 발견됐더라도 해당 기능이 비활성화돼 있거나, 특정 내부 네트워크에서만 호출되거나, 앞단의 검증 로직으로 차단된다면 실제 위험도는 낮아질 수 있습니다. 반대로 겉보기에는 단순한 정수 오버플로라도 네트워크 패킷으로 원격 재현된다면 심각한 IoT 공급망 취약점이 될 수 있습니다.

바이너리 펌웨어는 AI에게도 어려운 대상이다

현실의 IoT 장비는 소스코드 대신 컴파일된 펌웨어 바이너리만 제공하는 경우가 많습니다. 이때 분석 과정은 소스코드 검사보다 훨씬 복잡해집니다.

바이너리에는 보통 함수명, 변수명, 자료형 정보, 개발자 주석이 제거돼 있습니다. 분석 도구와 AI는 기계어를 역컴파일해 원래 코드와 유사한 형태로 복원해야 하지만, 이 과정에서 정보가 손실되거나 잘못 해석될 수 있습니다.

특히 다음 문제가 반복적으로 발생합니다.

• 최적화된 코드 때문에 함수 경계와 변수 역할이 불명확함
• CPU 아키텍처와 엔디언 차이로 분석 난도가 높아짐
• 역컴파일 결과가 원본 로직과 다르게 표현됨
• 하나의 펌웨어 이미지에 여러 실행 파일과 라이브러리가 섞여 있음
• 드라이버와 주변 장치 의존성 때문에 실행 경로를 재현하기 어려움

이 때문에 바이너리 분석은 소스코드 분석보다 비용과 시간이 더 많이 들고, 오탐도 늘어나는 경향이 있습니다. AI가 역공학 결과를 바탕으로 논리적으로 추론하더라도, 입력 데이터 자체가 부정확하면 결론 역시 흔들릴 수밖에 없습니다.

동적 검증이 필요한 이유

AI가 “악용 가능성이 높다”고 판단한 결과도 실제 실행 환경에서 재현하지 못하면 확정된 취약점으로 보기 어렵습니다. 따라서 에뮬레이션, 테스트 장비, 패킷 생성, 디버깅을 통한 동적 검증이 필수입니다.

동적 검증에서는 다음과 같은 작업이 이뤄집니다.

1. 펌웨어 또는 네트워크 스택을 실행 가능한 환경으로 구성합니다.
2. AI가 제안한 공격 입력을 패킷이나 요청 형태로 생성합니다.
3. 충돌, 메모리 접근 오류, 비정상 동작 여부를 관찰합니다.
4. 동일한 현상이 반복되는지 확인합니다.
5. 공격 영향과 완화 가능성을 평가합니다.

문제는 많은 IoT 장비가 일반적인 가상 환경에서 쉽게 실행되지 않는다는 점입니다. 특정 칩셋, 센서, 통신 모듈, 독점 드라이버를 요구하는 장비는 실제 하드웨어 없이는 동작을 완전히 재현하기 어렵습니다. 결국 AI 자동화가 빨라져도 마지막 단계에서는 보안 연구자와 제품 엔지니어의 경험이 중요합니다.

논리와 설계의 취약점은 여전히 어렵다

현재 AI 기반 분석은 메모리 손상, 길이 계산 오류, 프로토콜 파싱 문제처럼 코드와 데이터 흐름에서 드러나는 취약점에 특히 강합니다. 반면 정상적으로 동작하는 코드가 제품의 보안 정책을 우회하는 경우는 자동 탐지가 훨씬 어렵습니다.

대표적인 사각지대는 다음과 같습니다.

• 인증 절차를 우회할 수 있는 설계 오류
• 권한 분리 실패와 잘못된 접근 제어
• 예측 가능한 난수 또는 초기 시퀀스 번호
• TCP 상태 머신의 비정상적인 전이
• DNS 캐시 오염과 같은 프로토콜 의미론 문제
• 여러 기능을 조합해야만 드러나는 비즈니스 로직 결함

이런 문제는 코드 한 줄의 위험성보다 “이 장비가 무엇을 보호해야 하는가”를 이해해야 발견할 수 있습니다. 즉, AI가 코드 분석을 자동화할 수는 있어도 IoT 제품의 운영 목적, 네트워크 구조, 안전 요구사항까지 완전히 이해하는 단계에는 아직 도달하지 못했습니다.

빠른 발견 이후의 대응 체계가 더 중요하다

AI 하니스는 취약점을 발견하는 속도를 크게 높입니다. 그러나 취약점이 확인된 뒤 영향을 받는 제품을 식별하고, 제조사에 알리고, 패치를 개발해 현장 장비에 적용하는 과정은 여전히 느립니다.

특히 장기 운영되는 산업용·의료용 IoT 장비는 업데이트를 즉시 적용하기 어렵습니다. 따라서 기업은 AI 분석 결과를 단순 보고서로 끝내지 말고, 다음 대응 체계와 연결해야 합니다.

• SBOM 기반의 영향 제품 식별
• 펌웨어 버전과 자산 목록의 지속적 관리
• 네트워크 분리 및 접근 제어 강화
• 취약 장비의 우선순위 기반 패치 계획
• 제조사 보안 공지와 지원 종료 일정 추적
• 패치 불가 장비를 위한 보완 통제 적용

결국 AI는 취약점 연구를 더 빠르게 만들지만, 위험을 제거하는 것은 조직의 운영 역량입니다. IoT 보안의 핵심은 더 많은 후보를 찾는 데서 끝나지 않습니다. 그 후보를 정확히 검증하고, 실제 장비의 위험을 줄이는 조치까지 연결하는 데 있습니다.

IoT 취약점을 찾은 다음, 패치가 장비에 닿을 때까지

AI 보안 하니스는 임베디드 TCP/IP 스택의 취약점 분석 시간을 수개월에서 수시간 수준으로 줄일 수 있습니다. 그러나 여기에는 불편한 질문이 남습니다.

단종된 IoT 장비에 패치가 도착하지 않는다면, 취약점을 더 빨리 발견하는 것만으로 안전해질 수 있을까요?

정답은 쉽지 않습니다. 취약점 발견은 보안 대응의 시작일 뿐, 실제 위험을 줄이려면 발견 결과가 제품 식별·영향 평가·패치 배포·현장 적용까지 이어져야 합니다.

발견 속도와 패치 속도 사이의 격차

공통 TCP/IP 스택에서 발견된 취약점은 하나의 제품에만 머물지 않습니다. 같은 스택을 탑재한 스마트미터, 산업용 컨트롤러, 의료 장비, 카메라, 라우터, 빌딩 자동화 장비로 확산될 수 있습니다.

문제는 취약한 코드가 확인된 뒤에도 다음 단계를 거쳐야 한다는 점입니다.

1. 취약한 TCP/IP 스택과 버전 식별
2. 해당 스택을 포함한 IoT 제품 목록 확인
3. 제조사의 영향도 분석 및 패치 개발
4. 펌웨어 검증과 인증 절차 진행
5. 고객 환경에 업데이트 배포
6. 운영 중인 장비에 실제 적용
7. 업데이트 실패 장비의 격리 또는 교체

AI가 첫 번째 단계의 속도를 높여도, 나머지 단계가 느리다면 노출 기간은 길어집니다. 특히 산업·의료·에너지 분야에서는 장비를 멈추고 업데이트하는 일 자체가 위험하거나 비용이 클 수 있습니다.

IoT 공급망에서 패치가 멈추는 지점

IoT 보안의 어려움은 취약점이 코드에 있다는 사실보다, 그 코드가 어디에 쓰였는지 추적하기 어렵다는 데 있습니다. 제조사는 네트워크 스택을 직접 개발하지 않고, 칩셋 업체·운영체제 공급사·외부 라이브러리 업체로부터 받아 사용하는 경우가 많습니다.

이 과정에서 다음과 같은 문제가 발생합니다.

• 제품의 정확한 소프트웨어 구성 정보를 보유하지 못함
• SBOM은 존재하지만 실제 펌웨어 버전과 일치하지 않음
• 공급업체가 더 이상 해당 스택을 지원하지 않음
• 제품 제조사가 폐업했거나 보안 지원을 종료함
• 현장 장비가 인터넷에 연결되지 않아 원격 업데이트가 어려움
• 운영자가 장애 우려로 펌웨어 업데이트를 미룸

결국 “패치가 있다”는 사실과 “현장 장비가 안전해졌다”는 사실은 전혀 다릅니다.

단종 장비는 패치보다 완화 조치가 중요하다

지원이 종료된 IoT 장비는 제조사 패치를 기대하기 어렵습니다. 이 경우에는 취약점 제거보다 공격 경로를 줄이는 보완 통제가 현실적인 대응이 됩니다.

대응 방법	핵심 목적
네트워크 분리	취약 장비가 외부 또는 업무망과 직접 통신하지 않도록 제한
방화벽 정책 강화	불필요한 포트·프로토콜·원격 접속 차단
마이크로 세그멘테이션	장비별 통신 범위를 최소화해 침해 확산 방지
IPS·NDR 적용	악성 패킷, 비정상 DNS·DHCP·TCP 트래픽 탐지
자산 식별	취약 스택이 포함된 장비의 위치와 중요도 파악
장비 교체 계획	위험도와 운영 중요도에 따라 단계적 교체 추진

예를 들어 네트워크 패킷 처리 과정에서 원격 코드 실행으로 이어질 수 있는 취약점이 발견됐다면, 해당 장비가 외부에서 직접 접근 가능한지부터 확인해야 합니다. 인터넷 노출을 제거하고, 허용된 관리망에서만 통신하도록 제한하면 즉각적인 위험을 크게 낮출 수 있습니다.

AI 보안 도입의 기준은 ‘탐지’가 아니라 ‘조치’다

AI 기반 취약점 분석 도구를 도입할 때는 “얼마나 많은 버그를 찾는가”만 평가해서는 부족합니다. 더 중요한 질문은 다음과 같습니다.

• 발견된 취약점이 어떤 IoT 제품에 영향을 주는가?
• 해당 제품의 소유 부서와 설치 위치를 알 수 있는가?
• 패치 가능 여부와 지원 종료일을 확인할 수 있는가?
• 패치가 불가능한 장비를 격리할 수 있는가?
• 취약점 발견부터 조치 완료까지의 시간을 측정하는가?

AI는 취약점 후보를 빠르게 만들고, 분석가가 우선순위를 정하는 일을 돕습니다. 하지만 패치 관리 체계, 자산 관리, 네트워크 분리, 제조사 대응 체계가 없다면 AI가 찾아낸 결과는 경고 목록으로만 남을 수 있습니다.

더 빨리 찾는 만큼, 더 빨리 대응해야 한다

AI는 방어자에게만 주어지는 기술이 아닙니다. 공격자 역시 공개된 펌웨어와 상용 AI 모델, 자동화 도구를 조합해 취약점을 대규모로 탐색할 수 있습니다. 따라서 IoT 보안의 경쟁력은 발견 능력 자체보다 발견 이후의 대응 속도와 완성도에서 갈립니다.

가장 현실적인 목표는 명확합니다. AI가 찾아낸 취약점을 SBOM, 자산 목록, 네트워크 정책, 펌웨어 업데이트 체계와 연결해야 합니다. 패치할 수 있는 장비는 신속히 업데이트하고, 패치할 수 없는 장비는 분리·감시·교체해야 합니다.

취약점 연구가 수시간으로 단축되는 시대에는, 패치가 장비에 도달하는 시간도 함께 단축되어야 합니다. 그렇지 않으면 AI는 IoT의 약점을 더 빨리 발견하는 도구가 될 뿐, 그 약점을 더 빨리 없애는 도구가 되지는 못합니다.