jacobhan.me

움직이는 표적 방어와 소프트웨어 정의 네트워크: 10년치 연구를 한 줄로 꿴 체계적 문헌고찰

원 논문 · Souto et al., "Moving Target Defense in Software-Defined Networks: A Systematic Review", IEEE Access, vol. 14, pp. 32252–32272, 2026년 3월 3일 발행 · DOI 10.1109/ACCESS.2026.3668537 · 텍사스 공과대학교(Texas Tech University) 전기컴퓨터공학과

공격자는 가만히 멈춰 있는 표적을 가장 좋아한다. 같은 IP 주소, 같은 포트, 같은 경로가 며칠·몇 주·몇 달 동안 그 자리에 있다면, 그 시간은 전부 공격자의 정찰 예산이 된다. 움직이는 표적 방어, 즉 MTD(Moving Target Defense, 이동 표적 방어)는 이 비대칭을 거꾸로 뒤집어 보겠다는 발상에서 출발한다. 그리고 SDN(Software-Defined Networking, 소프트웨어 정의 네트워크)은 그 발상을 실제 네트워크에서 실행할 수 있게 해주는 가장 유력한 무대다. 이 글은 텍사스 공과대학교 연구진이 2015년부터 2025년까지 출간된 97편의 실증 연구를 PRISMA(Preferred Reporting Items for Systematic Reviews and Meta-Analyses, 체계적 문헌고찰과 메타분석을 위한 보고 기준) 절차에 따라 정리한 결과를, 이 분야를 처음 보는 사람도 따라올 수 있도록 풀어 쓴 해설이다.

목차
  1. 왜 이 논문을 봐야 하는가
  2. 전제 개념: MTD와 SDN, 그리고 둘이 만나는 지점
  3. 연구 방법: 302편에서 97편으로 좁히기까지
  4. MTD를 분류하는 아홉 가지 방식
  5. 컨트롤러와 평가 환경의 편향
  6. 어떤 공격을, 무엇으로 측정했는가
  7. 기법과 공격의 교차표가 드러낸 사각지대
  8. 성능과 보안의 줄다리기
  9. 사이버물리 시스템에 적용할 때의 현실
  10. 앞으로의 연구 방향
  11. 정리

왜 이 논문을 봐야 하는가

MTD와 SDN을 각각 다룬 서베이는 이미 여러 편 있다. 그러나 이 둘이 만나는 지점, 그러니까 "프로그래머블 네트워크 위에서 이동 표적 방어를 어떻게 구현하고 어떻게 측정했는가"를 한 자리에서 정량적으로 비교한 연구는 거의 없었다. 기존 서베이는 대부분 개념 분류에 머물거나, 짧은 시간 범위만 다루거나, 기법과 공격을 따로따로 논했다. 그래서 어떤 방어 기법이 어떤 공격에 얼마나 자주 시험되었는지, 어느 컨트롤러 위에서 무엇으로 측정되었는지를 가로질러 보려면 독자가 직접 수십 편의 논문을 모자이크처럼 맞춰야 했다.

이 논문이 내세우는 차별점은 세 가지다. 첫째, 2015–2025년 10년 전체를 다룬다. 둘째, 기법·컨트롤러·환경·공격·지표의 다섯 차원을 교차표로 엮어 빈도를 센다. 셋째, 그 결과로 드러난 공백(어떤 공격은 거의 시험되지 않았고, 어떤 지표는 거의 보고되지 않는다는 식의 사실)을 다음 연구가 메워야 할 과제로 제시한다. 연구자가 다음 논문 주제를 고를 때, 엔지니어가 어떤 기법을 시범 적용할지 결정할 때, 발 디딜 지도가 되는 글이다.

비유

도시 한복판에 늘 같은 자리에 서 있는 동상이 있다면 누구나 표적 연습용 종이를 그 위에 붙일 수 있다. 그런데 동상이 매시간 다른 위치로 이동한다면, 표적지를 미리 붙여둘 수가 없다. MTD는 이 "동상을 움직이자"는 발상이고, SDN은 도시 전체를 한눈에 보면서 동상을 어디로 옮길지 중앙에서 지시할 수 있는 관제센터에 해당한다. 이 논문은 지난 10년간 사람들이 동상을 어떻게 움직여 봤는지, 어떤 식의 공격을 가정하고 얼마나 빨리 옮겼는지, 옮기는 비용은 얼마였는지를 한 표에 모은 것이다.

전제 개념: MTD와 SDN, 그리고 둘이 만나는 지점

이동 표적 방어란 무엇인가

MTD는 시스템의 속성을 능동적으로, 그리고 주기적으로 바꿔서 공격자가 미리 모아둔 정찰 정보를 무효화시키는 방어 전략이다. 바꾸는 대상은 IP 주소, 포트 번호, 라우팅 경로, 서비스 위치, 호스트 위치, 심지어 운영체제 종류까지 다양하다. 핵심은 "공격자가 다음 행동을 결정하는 데 필요한 가정"을 흔드는 것이다. 가정이 흔들리면 공격에 드는 시간과 비용이 늘어나고, 정찰에서 실제 침투로 넘어가는 창문이 좁아진다.

소프트웨어 정의 네트워크란 무엇인가

SDN은 네트워크의 제어 평면(control plane)과 데이터 평면(data plane)을 분리하는 아키텍처다. 기존 네트워크에서는 각 스위치가 자기 머리로 라우팅을 판단하지만, SDN에서는 중앙의 컨트롤러가 네트워크 전체 상태를 보면서 흐름 규칙(flow rule)을 스위치에 내려보낸다. 컨트롤러와 스위치 사이의 통신 표준이 OpenFlow다. OpenFlow는 패킷 헤더의 어느 필드를 보고 어떤 동작을 할지를 match–action 테이블 형태로 정의한다. 이 구조 덕분에 컨트롤러는 IP 매핑이나 경로를 거의 실시간으로 바꿀 수 있다.

비유

예전 네트워크가 사거리마다 신호 판단을 스스로 하는 자율 교통경찰을 두는 방식이라면, SDN은 시 전체의 신호를 관제센터 한 곳에서 일괄적으로 바꾸는 방식이다. 평소엔 둘 다 별 차이가 없어 보이지만, 갑자기 모든 사거리의 진행 방향을 동시에 비틀어 침입한 차량의 추적을 따돌리고 싶을 때 차이가 난다. SDN은 그 "동시에 비틀기"가 기술적으로 가능한 무대다.

둘이 만나면 왜 강한가

MTD는 전략을 제공하고 SDN은 기제를 제공한다. 컨트롤러가 네트워크 전체 상태를 보고 있기 때문에 어떤 흐름을 어디로 옮길지 즉시 결정할 수 있고, OpenFlow를 통해 그 결정을 빠르게 데이터 평면에 적용할 수 있다. 두 기술이 만나면 "탐지–결정–실행" 고리가 빨라지고, 보안과 성능 사이의 균형을 정책 수준에서 조정할 수 있다. 다만 풀어야 할 숙제도 함께 따라온다. 규칙을 자주 바꾸면 일관성(rule consistency)이 흔들리고, 컨트롤러 부하가 늘며, 지연에 민감한 트래픽은 흔들림에 약하다. 그리고 이 모든 비용을 어떻게 측정해야 할지에 대한 합의가 거의 없다. 이 논문이 가장 강하게 짚는 지점이 바로 이 측정의 공백이다.

연구 방법: 302편에서 97편으로 좁히기까지

저자들은 IEEE Xplore, Scopus, Web of Science 세 곳에서 2015년부터 2025년까지의 영어 동료심사 논문을 모았다. 검색어는 "MTD AND SDN", "Moving Target Defense AND Software-Defined Networking"의 조합이다. 처음 모은 302편에서 중복 113편을 빼고 189편을 초록으로 거른 뒤 본문 검토 단계에서 다시 23편이 빠져 최종 97편이 남았다. 이 절차는 PRISMA 가이드라인을 따랐고, 흐름은 PRISMA 다이어그램으로 정리되어 있다.

PRISMA 선정 절차 (논문 본문 Figure 2 요약)
① 데이터베이스 검색: 302편
↓ 중복 113편 제거
② 초록 스크리닝: 189편
↓ SDN 내 MTD 구현 미명시 69편 제외
③ 본문 스크리닝: 120편
↓ 방법론 부실·정량 결과 부재 23편 제외
④ 최종 분석: 97편

각 논문에서 저자·연도·출판 형태부터 사용한 MTD 기법, SDN 컨트롤러, 평가 환경(시뮬레이션·실물 testbed·하이브리드), 공격 시나리오, 평가 지표까지 20개가 넘는 속성을 뽑았다. 다만 저자들은 한 가지를 명시적으로 인정한다. 이 리뷰는 "근거 지도"이지 "효과 순위표"가 아니다. 각 연구의 위험 편향을 정식 점수로 매기지는 않았다. 그래서 결과는 "어떤 패턴이 자주 등장한다"는 사실로 읽어야지 "어느 기법이 더 우수하다"는 판정으로 읽으면 안 된다. 평가 환경의 차이, 공격 모델의 차이, 측정 지표의 차이 때문에 같은 척도로 줄 세우는 것 자체가 어렵다는 게 이 리뷰의 또 다른 발견이기도 하다.

MTD를 분류하는 아홉 가지 방식

저자들은 "무엇을 움직이는가"를 기준으로 MTD를 아홉 갈래로 나눈다. 분류는 상호 배타적이지 않다. 실제 구현에서는 여러 기법이 함께 쓰이는 경우가 많다. 다만 어떤 기법이 그 시스템의 주된 방어 원리인지를 보고 갈래를 정한다.

1. 주소·포트 변이 (IP/Port Hopping)

가장 많이 쓰이는 기법이다. 호스트의 IP나 포트 매핑을 주기적으로 바꿔서 정찰과 스캐닝을 헛돌게 만든다. OpenFlow 규칙 업데이트만으로 컨트롤러에서 가상 주소와 실주소를 다시 매핑하면 되니 구현 부담이 낮다. 자주 바꾸면 효과는 올라가지만 흐름 테이블이 자주 갱신되면서 지연이 늘어난다.

2. 서비스 셔플링 (Service Shuffling)

활성 서비스나 가상 머신을 호스트 사이에서 옮겨가며 노출 시간을 줄인다. NFV(Network Function Virtualization, 네트워크 기능 가상화)나 클라우드 오케스트레이션과 같이 엮어 배치 위치를 동적으로 바꾸는 방식이 많다. 핵심 서비스를 짧은 주기로 옮기면, 일단 침투한 공격자도 발판을 유지하기 어렵다.

3. 경로·라우트 변이 (Route/Path Mutation)

포워딩 경로 자체를 주기적으로 바꿔서 토폴로지를 가리고 링크 플러딩 공격을 회피한다. 컨트롤러가 네트워크 전역을 보기 때문에 라우트 재계산이 효율적이지만, 너무 자주 바꾸면 제어 평면이 과부하 상태로 들썩이고 일시적 패킷 손실이 생길 수 있다.

4. 동적 무작위화 (Dynamic Randomization)

IP, 포트, 경로 같은 여러 차원을 트래픽 상황이나 위험 수준에 따라 함께 흔드는 방식이다. 위협 탐지 결과나 머신러닝 모듈의 피드백을 받아 변이 빈도와 범위를 조정한다. 단일 차원만 흔드는 기법보다 적응성이 높다.

5. 패킷·트래픽 난독화 (Packet/Traffic Obfuscation)

패킷 헤더(TTL, 시퀀스 번호 등)를 조작하거나 의도적인 타이밍 지터를 끼워 넣어서 트래픽 핑거프린팅을 방해한다. 정찰 도구가 모으는 정보의 신뢰도를 떨어뜨리는 게 목표다.

6. 토폴로지 변이 (Topology Mutation)

논리적 연결 구조 자체를 바꿔서, 공격자가 그리는 네트워크 지도가 실제와 어긋나도록 만든다. 링크를 숨기거나 가상화하고, 흐름을 미끼 노드로 우회시키며, 일부 경로를 일시적으로 비활성화한다.

7. 가상 머신·호스트 이동 (VM/Host Migration)

워크로드 자체를 다른 물리 노드로 옮긴다. 클라우드나 에지 환경의 지속적 위협을 막는 데 효과적이지만, 이동 중 다운타임과 상태 일관성 문제가 따라온다. 컨트롤러가 흐름 업데이트를 정확히 동기화해줘야 한다.

8. 플랫폼·소프트웨어 다양성 (Platform/Software Diversity)

같은 취약점이 시스템 전체를 무너뜨리지 못하도록, 운영체제 커널이나 컨트롤러 프레임워크, 소프트웨어 버전을 일부러 다양하게 가져간다. 자원 부담이 크지만 단일 취약점에 대한 회복력이 강해진다.

9. 복합 및 기만 기반 (Composite and Deception-based)

기존의 무작위화에 허니팟(honeypot), 섀도우 컨트롤러, 미끼 흐름 같은 기만 요소를 결합한다. 공격자를 잘못된 표적으로 유도하면서 동시에 위협 정보를 모으는 게 목적이다. 가짜 토폴로지 정보를 흘려 정찰 에이전트를 함정에 빠뜨리는 식이다.

이 아홉 가지를 빈도로 줄 세우면, 어떤 기법이 압도적으로 많이 연구되는지가 한눈에 보인다.

MTD 기법별 연구 빈도 (논문 Figure 5 재구성, n=97)
IP Hopping
34.0%
Service Shuffling
15.5%
Dynamic Randomization
11.3%
Path Mutation
9.3%
Topology Mutation
6.2%
Port Hopping
6.2%
Route Mutation
5.2%
Packet Obfuscation
5.2%
VM Migration
2.1%
기타 (다양성·프로토콜)
~4%

IP 호핑과 서비스 셔플링 두 가지가 전체의 절반 가까이를 차지한다. 이유는 명료하다. 둘 다 OpenFlow 규칙 조작이나 가상화 오케스트레이션으로 비교적 쉽게 구현되며, Mininet 같은 에뮬레이터 안에서 재현하기 쉽다. 반대로 VM 이동, 플랫폼 다양성, 프로토콜 변이는 자원 부담이 크고 실험 셋업이 무겁기 때문에 거의 시도되지 않았다. 이것이 곧 "쉽게 시뮬레이션할 수 있는 기법이 더 많이 연구된다"는 편향이고, 이 편향은 뒤이어 공격 시나리오 선택에도 영향을 준다.

컨트롤러와 평가 환경의 편향

어떤 컨트롤러가 쓰였는가

SDN 컨트롤러는 곧 MTD 정책이 실제로 집행되는 자리다. 어느 컨트롤러를 골랐는가가 곧 어떤 실험이 가능한지를 결정한다. 97편이 사용한 컨트롤러를 빈도로 추리면 다음과 같다.

SDN 컨트롤러 사용 빈도 (논문 Figure 6 재구성, n=97)
Ryu
29.9%
ONOS
17.5%
Generic / 명시 안 함
12.4%
POX
11.3%
OpenDaylight
10.3%
Floodlight
7.2%
자체 구현 컨트롤러
6.2%
NOX / 컨트롤러 없음
~5%

Ryu가 압도적이다. 단순히 성숙한 플랫폼이라서가 아니라, Ryu가 Mininet과 Python 기반 실험 워크플로와 잘 맞물리기 때문이다. 빠른 프로토타이핑이 쉽고, 학계에서 재현하기 좋고, 개념 검증 수준의 평가에 잘 어울린다. 뒤집어 말하면 컨트롤러 선택은 운영 현장의 현실성보다 실험의 편의성에 더 좌우되어 왔다. 그래서 이 문헌에서 검증된 아키텍처와 워크로드가 실제 운영 환경의 그것과 얼마나 닮았는지는 별도로 따져봐야 한다.

어디서 실험했는가

평가 환경의 쏠림은 더 극단적이다.

평가 환경 분포 (논문 Figure 7 재구성, n=97)
시뮬레이션
83.5% (81편)
실물 testbed
12.4% (12편)
하이브리드
4.1% (4편)

시뮬레이션 환경, 그중에서도 Mininet 기반 에뮬레이션이 압도적이다. 실물 testbed에서 검증된 연구는 8편 중 1편꼴이며, 둘을 섞은 하이브리드 평가는 더 드물다. 이 쏠림은 단순한 통계 이상의 의미가 있다. 시뮬레이션에서 다룰 수 있는 공격과 측정할 수 있는 지표가 곧 이 분야의 "측정된 진실"이 되기 때문이다. 시뮬레이션에서 재현하기 쉬운 스캐닝과 플러딩이 가장 많이 시험되고, 시뮬레이션에서 측정하기 쉬운 패킷 수준 지표가 주로 보고된다. 사이버물리 시스템이나 산업 통신에서 중요한 "복원 시간", "서비스 연속성", "제어 안정성" 같은 운영·임무 수준의 지표는 그만큼 덜 다뤄진다.

비유

가로등 아래에서 잃어버린 열쇠를 찾는 사람의 우화가 있다. 어두운 곳에서 떨어뜨렸지만 보이는 곳이 가로등 밑이라 거기서만 찾는 그림이다. 시뮬레이션은 가로등 불빛이고, 실제 운영 환경은 어두운 길거리다. MTD 연구의 무게중심이 어디로 쏠려 있는지를 가장 잘 보여주는 통계가 이 평가 환경 분포다.

어떤 공격을, 무엇으로 측정했는가

공격 시나리오의 분포

평가에서 가정된 공격 유형 (논문 Figure 8 재구성)
정찰·스캐닝
33.1%
DoS / DDoS 플러딩
30.1%
핑거프린팅·타이밍 공격
16.2%
도청·스니핑
5.9%
공격 모델 없음
5.1%
권한 상승·익스플로잇
4.4%
기타·복합 공격
~4%
웜·악성코드 전파
0.7%

정찰·스캐닝과 DoS/DDoS 두 가지를 합치면 전체의 60%를 넘는다. SDN 컨트롤러 자체가 정찰의 고가치 표적이고 동시에 플러딩의 병목이라는 구조적 이유가 한몫한다. 그러나 다른 한편으로는 앞서 본 평가 환경의 쏠림이 그대로 연장된 결과이기도 하다. 스캐닝과 플러딩은 Mininet에서 스크립트 몇 줄로 재현이 되지만, 다단계 침입이나 내부자 위협, 악성코드 전파 같은 시나리오는 상태 보존이 필요하고 모의가 어렵다. 핑거프린팅 공격에 IP 호핑이 자주 짝지어지는 것은 자연스러운 매칭이지만, 그 외 짝짓기는 빈약한 편이다.

측정 지표의 다섯 갈래

이 리뷰가 평가 지표를 정리한 방식은 다음과 같다. 모두 한 가지 결론을 가리킨다. 표준화가 거의 없다.

결정적인 통계가 하나 더 있다. 지연을 명시적으로 측정한 연구는 27%, 처리량은 15%, 에너지나 메모리 같은 자원 오버헤드를 잰 연구는 8% 미만이다. 즉 대부분의 논문이 "어떤 공격을 얼마나 막았다"는 말은 하지만, "그 대가로 네트워크가 얼마나 느려졌고 컨트롤러는 얼마나 더 일했는가"는 말하지 않는다. 비교 가능한 벤치마크가 없는 상황에서 이 누락은 분야 전체의 발목을 잡는다.

기법과 공격의 교차표가 드러낸 사각지대

이 논문이 다른 서베이와 차별화되는 가장 큰 지점이 교차표(cross-tabulation) 분석이다. 어떤 기법이 어떤 공격에 짝지어 평가되었는지를 빈도로 세어 보면, 연구가 몰린 칸과 거의 비어 있는 칸이 한눈에 드러난다. 본문 Figure 9의 히트맵을 정리하면, IP 호핑이 DoS/DDoS 플러딩과 14회, 정찰·스캐닝과 13회 짝지어진 게 가장 큰 봉우리다. 그 다음으로 서비스 셔플링이 DoS 6회, 권한 상승 5회, 핑거프린팅 3회 정도다. 반면 토폴로지 변이, VM 이동, 플랫폼 다양성 같은 기법은 어느 공격과 짝지어도 한 자릿수 빈도에 머문다.

MTD 기법주로 짝지어진 공격거의 시험되지 않은 공격
IP HoppingDoS/DDoS, 정찰·스캐닝, 핑거프린팅웜·악성코드, 권한 상승 (간헐적)
Service ShufflingDoS/DDoS, 권한 상승도청, 웜 전파
Path / Route Mutation도청, 정찰·스캐닝권한 상승, 복합 공격
Topology Mutation권한 상승, 정찰플러딩, 도청
VM MigrationDoS/DDoS (소수)다단계·내부자·악성코드 거의 전부
Platform Diversity정찰, 웜 (각 1편)대부분의 공격

저자들이 강조하는 두 가지 불균형이 여기서 나온다. 첫째, 기법–공격 불균형이다. 평가 지형의 가장 큰 두 봉우리가 정찰과 DoS인 반면, 내부자 위협이나 권한 상승, 악성코드 전파 같은 시나리오는 통계 바닥에 가깝다. 둘째, 기법–지표 불균형이다. 대부분의 연구가 지연·처리량·공격 성공 확률에 머물고, CVSS(Common Vulnerability Scoring System, 공통 취약점 점수 체계)나 복원 시간 같은 시스템 차원의 척도를 도입한 연구는 손에 꼽힌다. 이 두 불균형 때문에 같은 도구로 비교하기가 어렵고, 어느 기법이 어느 환경에서 더 우수한지를 일반화하기 어렵다.

교차표가 보여주는 것은 "어떤 짝짓기가 더 효과적인가"가 아니다. "어떤 짝짓기가 더 자주 시험되었는가"이다. 자주 시험되었다는 사실 자체가 우월성의 증거는 아니라는 점을, 저자들은 본문에서 분명하게 못 박는다.

성능과 보안의 줄다리기

이동 표적 방어의 본질은 트레이드오프다. 더 자주, 더 넓게, 더 깊게 흔들수록 공격자 입장에서는 표적 추정이 어려워지지만, 정상 트래픽도 그만큼 진동에 노출된다. 본문 Table 2는 기법별로 어떤 종류의 부담이 따라오는지를 정리하는데, 핵심을 추리면 다음 표가 된다.

기법주된 오버헤드관찰된 영향
IP / Port Hopping 제어 평면 churn(요동), 중간 정도의 지연 변이가 잦을수록 흐름 규칙 업데이트가 늘어 컨트롤러 부하가 증가. 변이 속도가 중간 수준이면 데이터 평면 영향은 제한적
Path / Route Mutation 지연·처리량 변동 경로 재계산이 잦을 때 경로 불안정과 일시적 처리량 저하. 혼잡 상황에서 더 두드러짐
Service Shuffling / Migration 높은 연산·오케스트레이션 비용 서비스 이전과 VM·컨테이너 마이그레이션 동안 CPU·메모리·세션 재구성 부담이 큼. 지속 위협엔 강하지만 재구성 중 다운타임 가능
Dynamic / Adaptive MTD 여러 차원에 걸친 누적 오버헤드 다중 기제를 함께 굴리면 견고성이 올라가지만 제어 평면 요동과 협조 복잡도가 증폭
Deception-Based MTD 중간 정도의 자원 오버헤드 미끼 서비스와 허니팟은 정상 트래픽 지연은 적게 주지만, 그럴듯해 보이게 유지하려면 모니터링·관리 자원이 계속 든다

중요한 단서가 있다. 이 표의 영향은 절대값이 아니라 "맥락에 따라 달라지는 경향"이다. 같은 IP 호핑이라도 작은 토폴로지에서는 제어 평면 요동이 국소적으로 흡수되지만, 메시 구조가 큰 네트워크에서는 한 번의 변이가 수많은 스위치에 연쇄적인 규칙 갱신을 일으키며 컨트롤러 CPU와 남방 대역폭, 분산 컨트롤러 간 동기화 부담을 동시에 끌어올린다. 트래픽 성격도 영향을 준다. 짧고 상태가 없는 짧은 흐름이 많으면 변이 충격이 흡수되지만, 영상 스트리밍이나 산업 제어 채널처럼 길고 상태 보존이 필요한 흐름이 많은 환경에서는 변이가 일어날 때마다 세션 복구 지연이나 미세 패킷 손실이 그대로 체감 품질 저하로 이어진다.

비유

이 트레이드오프는 도시 한복판에서 도로를 자주 막거나 우회시키는 것과 비슷하다. 시간당 우회 횟수를 늘리면 추적자는 따돌리기 쉬워지지만, 출퇴근 차량도 그만큼 시간을 더 쓴다. 작은 동네라면 큰 영향이 없을 수 있어도, 도시 전체 단위로 가면 누적 통행 시간이 폭증한다. MTD의 변이 빈도와 SDN의 네트워크 규모 사이에도 똑같은 비례가 성립한다.

스마트한 적응 vs. 측정의 공백

최근 연구는 트레이드오프를 완화할 수단으로 적응형 정책을 제안한다. 마르코프 결정 과정(Markov Decision Process)을 써서 정상 흐름 방해를 최소화하는 위험 인지 정책을 짜거나, 강화학습으로 컨트롤러가 언제 어디서 변이를 트리거할지 학습하게 한다. 블록체인 기반 분산 신뢰 체계도 등장하지만, 트랜잭션 지연이라는 새로운 비용을 들고 온다. 다만 이 모든 지능형 접근에 공통적으로 빠진 게 있다. 표준 벤치마크다. 지연·처리량·에너지·메모리를 같은 방법으로 잰 비교 가능한 결과가 거의 없기 때문에, 어느 적응 전략이 더 낫다고 말하기 어렵다. 이게 이 분야 전체가 풀어야 할 가장 큰 숙제로 다시 돌아온다.

일관성과 확장성: 잘 알려지지 않은 근본 제약

한 번 짚고 가야 할 근본 제약이 있다. 규칙 일관성과 제어 평면 확장성은 분리해서 생각할 수 없다. 변이 이벤트가 일어나는 동안 옛 규칙과 새 규칙이 짧게 공존하는 "업데이트 창(update window)"이 생긴다. 이 창 안에서 일부 패킷은 오라우팅되거나 폐기되거나 잘못된 정책 체인을 탄다. 변이 빈도가 높을수록, 흐름 테이블이 클수록, 남방 대역폭이 좁을수록 이 창은 길어진다. TCP 세션이나 산업 제어 채널처럼 연결 친화도가 필요한 상태 보존 흐름에서는 더 까다롭다. 변이 입자(granularity)를 잘게 가져갈수록 공격자 불확실성은 커지지만 제어 평면이 비명을 지르고, 굵게 가져가면 평면은 조용하지만 공격 면적이 더 예측 가능해진다. 이 균형은 단순히 알고리즘 문제가 아니라 아키텍처 차원의 설계 결정이다.

사이버물리 시스템에 적용할 때의 현실

스마트 그리드, 산업 제어 시스템(ICS, Industrial Control System), 차량 네트워크, 사물 인터넷(IoT, Internet of Things) 같은 사이버물리 시스템(CPS)은 MTD가 가장 절실한 분야이면서 동시에 가장 까다로운 무대다. 운영 신뢰도가 보안만큼 중요하고, 일부 통신은 마이크로초 단위의 결정성을 요구한다. 이 환경의 현실적 제약을 저자들은 다음과 같이 정리한다.

레거시 프로토콜과의 상호운용성

스마트 그리드와 ICS 현장은 여전히 DNP3, Modbus, IEC-61850, IEC-104 같은 프로토콜로 돌아간다. 이 프로토콜들은 보안보다 결정성과 호환성을 우선 설계로 가져갔기 때문에, MTD가 IP를 바꾸거나 경로를 우회하면 보호 계전(protection relay) 협조나 SCADA(Supervisory Control and Data Acquisition, 감시 제어 및 데이터 수집) 트래픽이 오작동할 위험이 있다. 변이를 어디까지 허용할지에 대한 도메인별 가이드가 필요한 이유다.

실시간성과 결정성

시간 민감 네트워킹(TSN, Time-Sensitive Networking), 5G/6G 네트워크 슬라이싱, URLLC(Ultra-Reliable Low-Latency Communications, 초고신뢰 저지연 통신)처럼 종단 지연이 엄격히 묶인 환경에서 잦은 IP 호핑이나 경로 변이는 제어 평면 지터, 일시적 패킷 재정렬, 마이크로 단위 단절을 만들어내 그 자체로 SLA 위반이 된다. "보안을 위해 흔드는 것"과 "결정성을 위해 가만히 두는 것" 사이의 줄다리기가 가장 첨예하게 일어나는 영역이다.

저자들이 제안한 ICS 적용 가이드라인

본문 Table 3은 산업 제어 환경에서 MTD를 도입할 때의 실용 지침을 정리한다. 핵심을 옮기면 다음과 같다.

항목권장 방법근거
변이 주기 비임계 흐름에 한해 제어 주기나 유지보수 시간대에 맞춰 1–5분 단위로 제한 제어 명령의 동기 이탈 방지, 보호·SCADA 트래픽의 결정성 보장
보호 채널 고정 계전, 페일오버 링크, 시간 임계 프로토콜은 정적 경로 유지 IEC 61850 GOOSE, DNP3 같은 임계 동작의 10밀리초 미만 지연 요건 충족
프로토콜 호환성 Modbus, DNP3, IEC-104를 SDN 흐름 매핑이나 프록시 변환 계층으로 흡수 레거시 장비에 도달성을 유지하면서 MTD 동역학을 깨지 않기 위함
롤백·회복 패킷 손실 급증이나 컨트롤러 장애 시 베이스라인으로 자동 복귀하는 기제 정의 재구성 또는 네트워크 분할 사고 시 안전 복구 보장
균형 잡힌 적용 하이브리드 오케스트레이션(일부 호핑 + 정적 제어 평면) 실시간 제약은 지키면서 비임계 흐름에만 MTD를 선택적으로 적용
모니터링과 검증 지연, PDR(Packet Delivery Ratio, 패킷 전달률), CPU 부하를 지속적으로 로깅하여 변이 빈도를 동적으로 조정 런타임 적응 튜닝과 불안정 조기 탐지
테스트와 벤치마킹 Mininet(제어 로직)과 OPAL-RT, RTAC 같은 HIL(Hardware-in-the-Loop) 장비를 결합한 하이브리드 testbed 활용 실 운영 배치 전 지연과 결정성에 대한 현실적 검증

저자들은 이 표의 원칙을 적용한 예시 시나리오도 제시한다. 중전압 마이크로그리드 SCADA가 Modbus/TCP로 감시 제어를, DNP3로 보호 계전 통신을 한다고 가정하자. OpenDaylight 컨트롤러가 IP·경로 변이를 담당하며, 평상시에는 비임계 모니터링 흐름만 15초 주기로 IP를 바꾼다. 제어와 보호 채널은 고정 경로로 핀(pin)된 상태로 유지한다. 침입 탐지 모듈이 정찰·스캐닝 징후를 잡으면 변이 주기를 일시적으로 5초로 단축하고, 미끼 호스트를 활성화해 공격자를 유도한다. 이 모든 동안 흐름 테이블 업데이트 총 소요 시간은 200밀리초 이하로 유지되어 보호 계전 협조의 서브사이클(sub-cycle) 요건을 깨지 않는다. 이런 식으로 주소 변이, 경로 다변화, 기만을 한 정책 안에 묶어 운영 안전 요건과 보안 요건을 함께 충족시킨다는 게 저자들이 그리는 모범이다.

앞으로의 연구 방향

저자들이 마지막으로 펼치는 그림은 이 분야가 다음 10년 동안 어디로 가야 하는가에 대한 처방이다. 일곱 갈래로 정리할 수 있다.

1. 디지털 트윈과의 결합

디지털 트윈(Digital Twin)은 운영 중인 네트워크의 상태를 계속 모사해두는 가상 복제본이다. 이 위에서 MTD 정책을 미리 돌려보면, 실 환경에 적용하기 전에 효과와 부작용을 확인할 수 있다. 시뮬레이션 일변도에서 벗어나는 가장 현실적인 다리이지만, 현재까지 시도된 사례는 거의 없다.

2. 인공지능 기반 적응 오케스트레이션

강화학습과 마르코프 결정 과정을 쓴 연구는 일부 있지만, 대부분의 MTD는 여전히 정적이거나 단순 반응형이다. 다음 단계는 공격자 행동에 동적으로 적응하면서 여러 기법을 병렬로 조율하는 인공지능 기반 오케스트레이션이다. 동시에 한 가지 경고가 따라온다. 머신러닝 모델 자체가 방어 인프라의 일부가 되는 순간, 모델의 설명 가능성과 적대적 입력에 대한 견고성, 데이터 오염 공격 방어 같은 새로운 과제가 생긴다. 머신러닝 모델 자체가 새 공격 면이 될 수 있다.

3. 표준 testbed와 벤치마크 데이터셋

Mininet 일변도를 벗어나려면 공유 트래픽 트레이스, 공격 스크립트 라이브러리, 도메인 간 워크로드(엔터프라이즈, IoT, 차량, CPS)를 제공하는 표준 testbed가 필요하다. 누구든 같은 조건에서 같은 측정을 반복할 수 있게 만들어야 비교가 가능해진다.

4. 통합 위험 점수와 측정 표준

공통 취약점 점수 체계(CVSS)와 같은 기존 보안 프레임워크에 MTD 고유 변수를 더한 통합 위험 점수가 필요하다. 거기에 더해 지연·처리량·패킷 손실·제어 평면 오버헤드 같은 흔한 지표마저도 측정 방법과 시간 창, 트래픽 프로파일, 집계 방식이 연구마다 다르다. 최소한의 공통 정의와 보고 가이드라인이 있어야 한다.

5. 에지·IoT 환경에서의 MTD

자원 제약과 지연 제약이 동시에 걸리는 에지·IoT는 MTD의 다음 전선이다. 차량 접근 제어나 IoT 허니팟 같은 시도는 있지만, 컨트롤러 부하를 최소화하면서 수천 대 단위로 확장 가능한 경량 분산 구현이 아직 부족하다.

6. MTD–SDN 코어 벤치마크

저자들이 직접 제안하는 구체적인 그림이 있다. 다음 지표를 최소 측정 집합으로 정의하자는 제안이다.

제안된 코어 벤치마크 지표

평균과 95퍼센타일 지연(RTT), 처리량, 지터, 패킷 전달률(PDR), 공격 성공률·확률(ASR/ASP), 평균 침해 시간(MTTC), 컨트롤러 CPU·메모리 사용률, 규칙 설치 시간, 흐름 churn 비율.

표준 시나리오는 ① 정찰과 DoS 플러딩 결합, ② 크로스파이어·스텔스 링크 플러딩, ③ 내부자 권한 상승, ④ 도청·핑거프린팅. 대표 토폴로지는 Fat-Tree(k=4), IoT 에지 네트워크, 단순화된 마이크로그리드·ICS testbed.

출발점으로 Mininet과 Ryu·ONOS를 쓰는 작은 오픈소스 레퍼런스 구현을 GitHub 같은 공개 저장소에 올리고, Zenodo로 영구 식별자를 받아 커뮤니티가 함께 키워가자는 게 저자들의 제안이다. 거창한 컨소시엄이 아니라 작고 재현 가능한 출발점이라는 점이 현실적이다.

7. CPS·ICS를 위한 실행 가능한 가이드라인

앞서 표 형태로 정리한 ICS 가이드라인은 사실상 이 분야에서 처음 제시된 운영 지침 중 하나다. 도메인 특수성을 흡수할 수 있는 추상화 계층이나 미들웨어 기반 MTD 오케스트레이터가 있어야, 같은 정책을 여러 산업 도메인에 이식할 수 있다. 현재처럼 정책이 프로토콜별 구현에 박혀 있으면 도메인을 옮길 때마다 재설계가 필요하다.

정리

이 리뷰가 10년치 연구에서 끌어낸 핵심은 네 줄로 요약된다. 첫째, 지난 10년 동안 가장 많이 시험된 MTD 기법은 IP·포트 호핑이고, 가장 많이 가정된 공격은 정찰과 DoS다. 둘째, 그 두 기법과 두 공격의 짝짓기는 시뮬레이션 환경에서 쉽게 재현되는 짝이라서 그렇지, 우열의 증거는 아니다. 셋째, 평가 지표의 절대다수가 패킷 수준에 머물러 있어서, "보안을 얻기 위해 운영이 얼마를 지불했는가"라는 질문에는 분야 전체가 아직 답을 갖고 있지 않다. 넷째, 표준 벤치마크와 실물 testbed, 그리고 CPS 도메인을 위한 운영 지침이 함께 만들어져야 MTD가 학술 실험을 넘어 실제 인프라 보호 수단으로 자리 잡을 수 있다.

연구자라면, 이 리뷰에서 빈 칸으로 남은 짝짓기—특히 권한 상승, 다단계 침입, 악성코드 전파에 대한 토폴로지 변이와 플랫폼 다양성—가 다음 논문의 좋은 후보다. 산업 현장 엔지니어라면, CPS 가이드라인이 제시한 "변이는 비임계 흐름에만, 보호 채널은 고정, 롤백 기제는 반드시"라는 세 가지 원칙이 출발점이 된다. 정책 결정자라면, 표준 벤치마크 부재가 분야 전체의 비교 불가능성을 만들고 있고 이걸 풀어주는 공공재가 어디서든 한 번은 만들어져야 한다는 메시지를 가져갈 수 있다.

이동 표적 방어는 매혹적인 아이디어다. 공격자를 끌어들이는 정적인 표적을 지우고, 끊임없이 자리를 옮기며 적의 정찰을 헛돌게 한다. 그러나 매혹적인 아이디어와 신뢰할 수 있는 방어 사이에는 표준, 측정, 그리고 운영 환경에서의 검증이라는 긴 다리가 놓여 있다. 이 논문은 그 다리의 어디까지가 놓였고 어디부터가 비어 있는지를 처음으로 한 폭의 지도에 그렸다. 그 지도는 다음 10년 동안 이 분야가 어디를 향해 가야 하는지를 비교적 분명하게 가리키고 있다.

참고 · 본문에 인용된 모든 수치(연구 편수, 비율, 그림·표 통계)는 Souto et al., "Moving Target Defense in Software-Defined Networks: A Systematic Review", IEEE Access, vol. 14, pp. 32252–32272, 2026의 본문, Figure 3·4·5·6·7·8·9, Table 1·2·3을 직접 인용한 것입니다. DOI: 10.1109/ACCESS.2026.3668537. 본 글은 Creative Commons Attribution 4.0 라이선스로 공개된 원 논문의 내용을 한국어 일반 독자를 위해 요약·해설한 것이며, 원문의 학술적 권위는 저자들에게 있습니다.