왜 시뮬레이션이 적용되지 않는가 — 설정했다와 적용되었다는 다르다

개념

이 레슨이 존재하는 이유

네트워크 저하 테스트에서 가장 많은 시간이 사라지는 곳은 도구 사용법이 아니다. 도구를 켰는데 아무 일도 일어나지 않는 상황 이다.

PC에 Clumsy를 띄우고, 모바일 핫스팟을 켜고, 폰을 연결하고, Start를 눌렀는데 폰은 여전히 빠르다. 설정을 몇 번 바꿔보다 반나절이 지나간다. 그리고 대부분은 원인을 모른 채 "이 도구는 안 되네"로 끝난다.

이 레슨은 그 반나절을 없앤다.

원인 ① — 통과하는 패킷은 보이지 않는다

가장 흔하고, 가장 구조적인 원인이다.

Clumsy는 내부적으로 WinDivert 라는 커널 드라이버를 쓴다. WinDivert는 윈도우 네트워크 스택의 여러 계층에서 패킷을 가로챌 수 있는데, 기본 감시 대상은 NETWORK 계층 이다.

        스마트폰              PC (모바일 핫스팟)              인터넷
        테스트 대상      →      NAT · 라우팅       →       실제 서비스
 
                        패킷은 PC를 '통과'할 뿐이다
 
 
  NETWORK 계층                       NETWORK_FORWARD 계층
  ─────────────────                  ──────────────────────
  PC 자신이 보내고 받는 패킷            핫스팟을 통과해 지나가는
  → Clumsy 기본 감시 대상              스마트폰 패킷
                                     → 감시되지 않음

PC가 종착지인 트래픽과, PC를 거쳐 지나가는 트래픽은 다른 계층에서 처리된다. 핫스팟에 연결된 스마트폰의 패킷은 후자다. 그래서 필터를 아무리 고쳐도, Start를 몇 번을 눌러도 폰 트래픽에는 닿지 않는다.

도구가 고장 난 게 아니라 애초에 보고 있는 곳이 다르다.

해결 방향은 셋

① 저하 지점을 스마트폰 자체로 옮긴다        ← 가장 확실 (레슨 3)
   iOS 네트워크 링크 컨디셔너 / Android 개발자 옵션
 
② Windows를 유지해야 한다면 포워드 계층을 지원하는 포크를 쓴다
   clumsy-hotspot — NETWORK_FORWARD를 감시하도록 수정된 버전
   (방향 필터 대신 필터에 true 를 입력해야 한다)
 
③ 저하 지점을 PC가 아닌 다른 곳으로 옮긴다
   공유기 QoS (레슨 4 보조) / 리눅스 AP + tc netem (레슨 5)

대부분의 팀에게 정답은 ① 이다. 추가 장비도, 커널 드라이버 설치 승인도 필요 없고, 오늘 당장 된다.

나머지 일곱 가지 실패 원인

구조 문제를 해결해도 아래에서 또 막힌다. 도구를 바꾸기 전에 이 목록을 먼저 훑는다.

1. 도구 노후화. NEWT(Network Emulator for Windows Toolkit)는 2010년 배포 도구다. Windows 10 이상에서 어댑터를 인식하지 못하거나 통신을 전면 차단하는 사례가 보고되어 있다. 오래된 블로그 글을 보고 NEWT를 설치하는 것이 이 영역에서 가장 흔한 시간 낭비다.

2. 필터 범위. Clumsy의 필터 true 는 "PC 자신의 모든 트래픽"을 뜻한다. 핫스팟 클라이언트는 여기에 포함되지 않는다. 원인 ①의 다른 표현이다.

3. 권한·보안. 관리자 권한으로 실행하지 않았거나, 백신·EDR이 커널 드라이버(WinDivert) 로딩을 차단해 시작 자체가 실패한다. 조용히 실패하는 경우가 많아 알아채기 어렵다.

4. 단위 혼동. Clumsy는 KB/s, 테스트 케이스는 보통 Mbps 다.

Mbps → KB/s :  × 1000 ÷ 8
 
100 Mbps = 12,500 KB/s
 30 Mbps =  3,750 KB/s
 10 Mbps =  1,250 KB/s
  1 Mbps =    125 KB/s
0.1 Mbps =     12 KB/s

단위를 틀리면 8배 차이가 난다. "설정은 했는데 체감이 안 된다"의 상당수가 이것이다.

5. 기기 자동 우회. 스마트폰은 Wi-Fi 품질이 나빠지면 알아서 셀룰러로 전환한다. 이게 동작하면 저하를 아무리 걸어도 폰은 멀쩡하다.

테스트 기기의 모바일 데이터를 반드시 끈다. 이건 선택이 아니라 전제 조건이다. Limited Service 재현이 안 되는 이유의 1순위가 이것이다.

6. 측정 시점. 앱·브라우저 캐시 때문에 저하 적용 후에도 이전 응답이 그대로 표시된다. 화면이 빠르게 뜨니 "적용 실패"로 오인한다. 시크릿 모드를 쓰거나 앱 캐시를 지우고 시작한다.

7. 하드웨어. 무선랜 어댑터가 없는 데스크탑에는 Windows 설정에 [모바일 핫스팟] 항목 자체가 나타나지 않는다. 메뉴를 못 찾아 헤매는 경우가 있는데, 하드웨어가 없는 것이다.

8. 적용 확인 누락. 설정만 하고 실제 속도를 확인하지 않은 채 테스트를 시작한다. 결과가 이상해도 조건 때문인지 제품 때문인지 구분할 수 없다.

설정했다 ≠ 적용되었다

여덟 번째 원인이 사실상 이 레슨 전체의 결론이다.

도구의 Start 버튼을 눌렀다는 사실은 조건이 적용되었다는 증거가 아니다. 증거는 측정값이다. 이 원칙을 절차로 만들면 다음 6단계가 된다.

① 기기 준비
   테스트 기기의 모바일 데이터를 끄고 Wi-Fi만 연결한다
   → 자동 우회를 막는 필수 단계
 
② 기준선 측정
   저하를 걸기 전에 정상 속도를 측정해 기록한다
   → 나중에 "원래 얼마였는지"를 말할 수 있어야 한다
 
③ 조건 적용
   선택한 방법으로 목표 조건을 설정하고 시작한다
 
④ 적용 확인
   다시 측정해 목표값 ±20% 이내인지 확인한다
   → 벗어나면 도구·경로를 점검한다. 여기서 멈춰야 한다
 
⑤ 캐시 제거
   앱 캐시를 삭제하거나 시크릿 모드를 사용한다
   → 이전 응답이 표시되지 않게 한다
 
⑥ 근거 확보
   조건명과 측정 결과 스크린샷을 TC에 첨부한 뒤 실행을 시작한다

④에서 벗어났는데 그냥 진행하는 것이 최악이다. 그 뒤로 나오는 모든 결과가 무효가 된다. 조건이 안 걸린 상태로 "저하 테스트 통과"를 기록하면, 실제 사용자가 겪는 문제는 그대로 남는다.

무엇으로 측정할 것인가

지연과 손실 조건을 걸었다면 대역폭 측정만으로는 확인이 안 된다. ping 을 함께 돌려야 한다.

ping -c 30 <폰 IP 또는 외부 주소>

출력 마지막 줄의 packet loss 와 min/avg/max/stddev 를 본다. stddev가 지터에 해당한다.

조용한 실패를 알아채는 법

이 영역 도구들은 실패를 조용히 한다. 에러 창이 안 뜬다. 그래서 "적용 안 됐을 때의 증상"을 미리 알아두는 것 이 도움이 된다.

증상: 저하를 걸었는데 속도가 그대로다
  → 원인 ①(포워드 계층), 5(셀룰러 우회), 3(드라이버 차단) 순으로 의심
 
증상: 속도는 느려졌는데 앱은 멀쩡하다
  → 원인 6(캐시) 또는 대역폭만 걸고 지연·손실을 안 걸었다
 
증상: 폰이 아예 인터넷이 안 된다
  → 손실·대역폭을 너무 극단적으로 걸었거나, 도구가 통신을 전면 차단했다
     (원인 1, 오래된 도구에서 흔함)
 
증상: 처음엔 됐는데 몇 분 뒤 풀린다
  → 폰이 셀룰러로 전환했거나(원인 5), 다른 Wi-Fi로 붙었다

실무에서 왜 필요한가

반나절이 아니라 10분

이 레슨의 실용적 가치는 단순하다. 도구가 안 먹을 때 무작위로 설정을 바꿔보는 대신 순서대로 점검 할 수 있다는 것이다.

[점검 순서 — 위에서부터]
1. 모바일 데이터 껐는가?                    ← 가장 흔함
2. 저하 지점이 폰 트래픽 경로 위에 있는가?    ← 구조 문제
3. 단위를 맞게 넣었는가? (Mbps vs KB/s)
4. 관리자 권한으로 실행했는가?
5. 캐시를 지웠는가?
6. 측정해서 확인했는가?

신뢰할 수 있는 테스트 결과가 나온다

적용 확인 절차 없이 수행한 네트워크 테스트는 결과를 믿을 수 없다. 통과했다고 기록해도 그게 조건이 안 걸려서인지 제품이 잘 만들어져서인지 구분되지 않는다.

측정 스크린샷 한 장을 TC에 붙이는 습관이 이 문제를 통째로 없앤다. 모듈 28 레슨 8에서 다룬 "증거" 개념이 여기서도 똑같이 적용된다.

보안 정책과 충돌하지 않는다

WinDivert 계열 도구는 커널 드라이버를 설치한다. 회사에 따라 이건 사전 승인이 필요한 행위다. 승인 없이 설치했다가 EDR에 걸려 보안팀의 연락을 받는 일이 실제로 일어난다.

도구를 고르기 전에 "이게 무엇을 설치하는가"를 확인하는 것 도 QA의 판단 영역이다. 기기 내장 기능(레슨 3)은 이 문제가 없다는 것이 큰 장점이다.

실습 과제

과제 1 — 실패 원인 점검표 만들기

본문의 8가지 원인을 우리 팀 환경에 맞춰 체크리스트로 옮긴다. 각 항목에 우리 환경에서의 확인 방법 을 한 줄씩 적는다.

예: "모바일 데이터 OFF — 설정 > 연결 > 데이터 사용에서 확인, 상태바에 LTE/5G 아이콘이 없어야 함"

이 체크리스트를 팀 위키나 TC 템플릿 첫 줄에 붙인다.

과제 2 — 단위 환산표 직접 만들기

우리가 쓸 조건값(레슨 1 과제 1에서 만든 표)을 다음 단위로 각각 환산한 표를 만든다.

직접 계산해서 채운다. 한 번 만들어두면 매번 실수하지 않는다.

과제 3 — 6단계 절차 실행하고 증거 남기기

아무 방법이든 하나 골라(레슨 3의 기기 내장 기능이 가장 쉽다) 6단계 절차를 그대로 수행하고, 각 단계의 증거를 남긴다.

• ②의 기준선 측정 스크린샷
• ④의 적용 후 측정 스크린샷
• 두 값의 차이가 목표와 ±20% 이내인지 계산

±20%를 벗어났다면 그 원인을 찾는 것까지가 과제다.

과제 4 — 조용한 실패 재현하기

일부러 실패 조건을 만들어 증상을 관찰한다.

• 모바일 데이터를 켠 채로 Wi-Fi에 저하를 걸어본다 → 어떻게 되는가
• 대역폭만 걸고 지연·손실은 안 걸어본다 → 앱 체감이 달라지는가
• 캐시를 지우지 않고 같은 화면을 다시 열어본다 → 속도가 어떤가

실패 증상을 직접 본 사람은 다음에 그 증상을 알아본다.

과제 5 — 도구 도입 전 확인 항목 정리

우리 팀이 쓸 후보 도구 3개에 대해 다음을 조사해 표로 만든다.

이 표를 들고 보안팀·인프라팀과 미리 이야기한다. 테스트 직전에 막히는 것보다 훨씬 낫다.

자가 체크리스트

• NETWORK 계층과 NETWORK_FORWARD 계층의 차이를 그림으로 설명할 수 있다
• Clumsy가 핫스팟 클라이언트 트래픽을 못 잡는 이유를 설명할 수 있다
• 구조 문제의 세 가지 해결 방향을 말하고 각각의 장단점을 안다
• 시뮬레이션 실패 원인 8가지를 나열할 수 있다
• Mbps ↔ KB/s ↔ 바이트/초를 정확히 환산할 수 있다
• 모바일 데이터를 꺼야 하는 이유와, 안 껐을 때의 증상을 안다
• '설정했다'와 '적용되었다'의 차이를 절차로 설명할 수 있다
• 적용 확인 6단계를 순서대로 수행할 수 있다
• 목표값 ±20%를 벗어났을 때 진행하면 안 되는 이유를 설명할 수 있다
• 대역폭·지연·손실을 각각 무엇으로 측정하는지 안다
• 조용한 실패의 증상별로 의심할 원인을 순서대로 댈 수 있다
• 커널 드라이버 설치 도구의 사내 승인 필요성을 판단할 수 있다

흔한 실수

Start를 누른 것으로 적용을 확신한다. 이 영역에서 가장 비싼 실수다. 결과 전체가 무효가 되는데, 그 사실을 아무도 모른 채 릴리즈된다.

모바일 데이터를 켜둔 채 테스트한다. 폰이 셀룰러로 우회해 저하가 전혀 체감되지 않는다. Limited 재현 실패의 1순위 원인이다.

오래된 도구를 검색 결과 상단이라는 이유로 설치한다. NEWT처럼 10년 넘은 도구는 현재 OS에서 동작하지 않거나 통신을 전면 차단한다. 배포 연도를 확인하는 습관 하나로 반나절을 아낀다.

단위를 확인하지 않는다. Mbps를 KB/s 칸에 그대로 넣으면 8배 차이가 난다. 반대도 마찬가지다.

캐시를 안 지우고 "적용 안 됐다"고 판단한다. 화면이 빨리 뜨는 이유가 네트워크가 아니라 캐시일 수 있다.

대역폭만 걸고 저하 테스트를 했다고 본다. 작은 API 호출은 대역폭을 거의 쓰지 않아 아무 변화가 없다. 지연과 손실을 함께 걸어야 재시도·타임아웃 경로가 열린다.

보안 승인 없이 커널 드라이버를 설치한다. 기술적으로 되는 것과 회사에서 해도 되는 것은 다르다.

참고 자료

• WinDivert 공식 문서 — 계층(NETWORK / NETWORK_FORWARD) 구분과 필터 문법. Clumsy 계열 도구의 동작 원리를 이해하는 출발점
• clumsy-hotspot — NETWORK_FORWARD 계층을 지원하도록 수정된 Clumsy 포크. Windows 핫스팟 구성을 유지해야 할 때의 대안
• fast.com — 브라우저만으로 다운로드 대역폭을 측정. 적용 확인의 최소 수단
• ping 매뉴얼 — packet loss 와 stddev(지터) 해석. 지연·손실 조건 확인에 필수
• 모듈 9 QA를 위한 개발 지식 — 트래픽 가로채기와 DevTools. 저하가 실제로 걸렸는지 요청 단위로 확인할 때 쓴다
• 모듈 28 레슨 8 표준 기반 테스트 계획 실전 — '증거' 개념. 측정 스크린샷을 TC에 붙이는 습관의 근거