Step 157. ARP 스푸핑 2 — 양방향 가로채기와 평문의 최후
Level 2 — 보안 입문과 공격 스킬 기초 | 난이도 ★★★★☆ | 예상 소요 시간 3시간
전제: Step 156을 마쳤다. ARP의 who-has/is-at 구조와 위조 응답의 원리를 scapy로 확인했다. tshark로 캡처 파일을 읽을 수 있다(Step 83~84).
- 준비물: WSL 리눅스 + 파이썬 venv(scapy) + tshark. 실제 랩(MS2·Kali Host-only)이 있으면 출력 예시 절차를 재현할 수 있습니다.
- ⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다.
- 안전 한계: 실제 네트워크로 ARP 스푸핑 패킷을 보내는 것은 절대 금지입니다. 오늘의 스푸핑 장면은 scapy로 패킷을 파일(pcap)로만 조립해 tshark로 판독합니다 — 전송은 한 번도 없습니다. 랩에서의 실제 공격 진행은 "출력 예시"입니다.
한쪽만 속이면 절반만 보입니다. 피해자가 게이트웨이로 보내는 요청은 보이지만, 돌아오는 응답은 보이지 않습니다. 완전한 MITM은 양방향 — 피해자에게는 "내가 게이트웨이", 게이트웨이에게는 "내가 피해자"라고 동시에 속이는 것입니다.
그리고 이 상태에 도달하면 드러나는 것이 있습니다. HTTP, FTP, Telnet 같은 평문 프로토콜은 계정과 비밀번호가 캡처에 글자 그대로 찍힙니다. 오늘의 실습은 두 축입니다 — 양방향 스푸핑의 패킷 구조를 pcap으로 조립·판독하고(실측), 그 위에서 평문 자격 증명이 어떻게 보이는지 확인합니다(실측). "왜 HTTPS가 세상을 바꿨는가"를 패킷으로 납득하는 날입니다.
1. 학습 목표
이 챕터를 끝내면 다음을 할 수 있습니다:
- 단방향과 양방향 스푸핑의 차이를 "무엇이 보이는가"로 설명한다
- 양방향 스푸핑의 패킷 구성(두 방향의 위조 is-at)을 scapy로 조립한다
- 스푸핑된 ARP 트래픽을 tshark로 판독하고, 탐지 신호(중복 IP 경고)를 찾는다
- IP 포워딩이 MITM에서 "연결 유지 장치"임을 설명한다
- 평문 프로토콜의 자격 증명이 캡처에 노출되는 것을 확인하고, HTTPS의 필요성을 증거로 말한다
2. 배경 지식 — 오늘의 도구와 개념
오늘의 도구 한눈에 보기
| 구분 | 내용 |
|---|---|
| 언어·환경 | WSL 리눅스, 파이썬 3 + scapy 2.7, tshark 4.2 |
| 오늘의 명령 | scapy wrpcap()(파일 저장), tshark -r(판독), -T fields, -z expert, arp.duplicate-address-frame |
| 필요한 개념 | 양방향 스푸핑, IP 포워딩, 평문 프로토콜, Step 84의 이상 탐지 |
| 오늘의 산출물 | 스푸핑 시연 pcap + 탐지 관점 분석 노트 — 공격자와 방어자의 두 시선 |
2-1. 왜 양방향인가 — 대화의 두 방향
ARP 테이블은 장비마다 따로 있습니다. 피해자의 테이블만 오염시키면 피해자→게이트웨이 방향만 공격자를 거칩니다. 게이트웨이의 테이블도 오염시켜야 게이트웨이→피해자 응답도 공격자를 거칩니다.
속임 1: 피해자에게 "게이트웨이(192.168.56.1)는 내 MAC이야"
속임 2: 게이트웨이에게 "피해자(192.168.56.101)는 내 MAC이야"
결과: 피해자 ←→ 공격자 ←→ 게이트웨이 (완전한 MITM)
두 개의 거짓말이 하나의 왕복 통로를 만듭니다. 랩 도구들이 터미널 두 개에 arpspoof를 하나씩 띄우는 이유가 이것입니다.
2-2. IP 포워딩 — 안 켜면 도청이 아니라 방해
공격자 장비가 패킷을 받았다고 끝이면, 피해자의 인터넷은 끊깁니다 — 들통나는 순간입니다. 받은 패킷을 원래 목적지로 대신 전달해야 통신이 살고, 그래야 오래 엿볼 수 있습니다. 리눅스에서 이 스위치가 /proc/sys/net/ipv4/ip_forward입니다. MITM 공격에서 이 파일은 "도청 모드와 방해 모드를 가르는 스위치"입니다.
2-3. 평문 프로토콜 — 암호화 전 시대의 유산
HTTP, FTP, Telnet은 설계 당시 암호화가 없었습니다. 로그인 한 번의 아이디·비밀번호가 패킷 본문에 글자 그대로 실립니다. Step 85에서 루프백으로 확인했던 그 사실이, 오늘은 "중간자의 시점"에서 다시 등장합니다 — 같은 구간에 설 수 있는 사람에게 평문은 그냥 문서입니다.
2-4. 방어자의 시점 — 스푸핑은 시끄럽다
공격자 관점의 스푸핑은 조용한 속임수지만, 방어자 관점에서는 흔적이 있습니다. 같은 IP를 두 MAC이 다투고, 묻지 않은 is-at이 반복되고, 캐시 항목이 자주 뒤집힙니다. tshark/Wireshark는 이런 장면에 "Duplicate IP address configured" 경고를 붙입니다. 오늘 pcap을 판독하며 이 경고를 직접 일으켜 봅니다 — 공격을 만들어 봐야 탐지의 얼굴이 보입니다.
3. 따라 하기
3-1. 스푸핑 장면을 pcap으로 조립하기
실제 전송 대신, 공격이 진행 중인 네트워크에서 캡처했다면 보일 패킷들을 scapy로 파일에만 조립합니다. 등장인물: 게이트웨이(192.168.56.1 / 08:00:27:aa:bb:cc), 피해자(192.168.56.101 / 08:00:27:11:22:33), 공격자(MAC aa:bb:cc:dd:ee:ff).
from scapy.layers.l2 import Ether, ARP
from scapy.utils import wrpcap
GW_IP, GW_MAC = "192.168.56.1", "08:00:27:aa:bb:cc"
VICTIM_IP, VICTIM_MAC = "192.168.56.101", "08:00:27:11:22:33"
ATK_MAC = "aa:bb:cc:dd:ee:ff"
pkts = []
# 정상 상태: 게이트웨이의 자기 소개 (gratuitous ARP)
pkts.append(Ether(src=GW_MAC, dst="ff:ff:ff:ff:ff:ff") /
ARP(op=2, psrc=GW_IP, hwsrc=GW_MAC, pdst=GW_IP, hwdst="00:00:00:00:00:00"))
# 공격: 피해자에게 "게이트웨이는 나야" (위조 is-at 반복)
for _ in range(3):
pkts.append(Ether(src=ATK_MAC, dst=VICTIM_MAC) /
ARP(op=2, psrc=GW_IP, hwsrc=ATK_MAC, pdst=VICTIM_IP, hwdst=VICTIM_MAC))
# 공격: 게이트웨이에게 "피해자는 나야" (양방향의 반쪽)
for _ in range(3):
pkts.append(Ether(src=ATK_MAC, dst=GW_MAC) /
ARP(op=2, psrc=VICTIM_IP, hwsrc=ATK_MAC, pdst=GW_IP, hwdst=GW_MAC))
wrpcap("arp_spoof_demo.pcap", pkts)
print(f"저장 완료: {len(pkts)}개 패킷")
출력 (2026-09-09 실측):
저장 완료: 7개 패킷
읽는 법: 전송 함수(sendp)가 아니라 파일 저장(wrpcap)을 썼다는 것이 안전 한계의 핵심입니다. 이 파일은 "스푸핑이 진행 중인 랩을 캡처한 것"과 같은 내용을 담은 모형입니다.
3-2. 공격자 화면 재현 — tshark 판독
방금 만든 파일을 tshark로 엽니다.
tshark -r arp_spoof_demo.pcap
출력 (2026-09-09 실측):
1 0.000000 PCSSystemtec_aa:bb:cc → Broadcast ARP 42 Gratuitous ARP for 192.168.56.1 (Reply)
2 0.000146 aa:bb:cc:dd:ee:ff → PCSSystemtec_11:22:33 ARP 42 192.168.56.1 is at aa:bb:cc:dd:ee:ff
3 0.000228 aa:bb:cc:dd:ee:ff → PCSSystemtec_11:22:33 ARP 42 192.168.56.1 is at aa:bb:cc:dd:ee:ff
4 0.000309 aa:bb:cc:dd:ee:ff → PCSSystemtec_11:22:33 ARP 42 192.168.56.1 is at aa:bb:cc:dd:ee:ff
5 0.000389 aa:bb:cc:dd:ee:ff → PCSSystemtec_aa:bb:cc ARP 42 192.168.56.101 is at aa:bb:cc:dd:ee:ff
6 0.000459 aa:bb:cc:dd:ee:ff → PCSSystemtec_aa:bb:cc ARP 42 192.168.56.101 is at aa:bb:cc:dd:ee:ff
7 0.000525 aa:bb:cc:dd:ee:ff → PCSSystemtec_aa:bb:cc ARP 42 192.168.56.101 is at aa:bb:cc:dd:ee:ff
읽는 법: 1번이 정상 상태 — 게이트웨이의 진짜 MAC이 자기 IP를 주장합니다. 2~4번은 피해자를 향한 반복 속임("게이트웨이는 공격자 MAC"), 5~7번은 게이트웨이를 향한 반복 속임("피해자는 공격자 MAC"). 같은 MAC aa:bb:cc:dd:ee:ff이 두 개의 서로 다른 IP를 주장하는 것 — 이 대비가 스푸핑의 얼굴입니다.
3-3. 방어자의 무기 — 필드 추출과 중복 IP 경고
주장하는 IP와 MAC만 뽑아 나란히 놓으면 다툼이 숫자로 보입니다.
tshark -r arp_spoof_demo.pcap -T fields -e frame.number -e arp.src.proto_ipv4 -e arp.src.hw_mac -e arp.dst.proto_ipv4
출력 (2026-09-09 실측):
1 192.168.56.1 08:00:27:aa:bb:cc 192.168.56.1
2 192.168.56.1 aa:bb:cc:dd:ee:ff 192.168.56.101
3 192.168.56.1 aa:bb:cc:dd:ee:ff 192.168.56.101
4 192.168.56.1 aa:bb:cc:dd:ee:ff 192.168.56.101
5 192.168.56.101 aa:bb:cc:dd:ee:ff 192.168.56.1
6 192.168.56.101 aa:bb:cc:dd:ee:ff 192.168.56.1
7 192.168.56.101 aa:bb:cc:dd:ee:ff 192.168.56.1
1번 행과 2~4번 행을 비교하세요 — 같은 IP(192.168.56.1)를 두 개의 MAC이 주장합니다. 이것을 Wireshark 계열은 자동으로 경고합니다.
tshark -r arp_spoof_demo.pcap -q -z expert,note
출력 (2026-09-09 실측):
Warns (6)
=============
Frequency Group Protocol Summary
3 Sequence ARP/RARP Duplicate IP address configured (192.168.56.1)
3 Sequence ARP/RARP Duplicate IP address configured (192.168.56.101)
표시 필터 arp.duplicate-address-frame으로 이런 패킷만 골라낼 수도 있습니다. 탐지 규칙의 씨앗: "같은 IP를 두 MAC이 다투면 의심하라" — Step 84의 ‘짝 없는 대답’이 ARP에서는 ‘한 IP에 두 주인’으로 나타납니다.
3-4. IP 포워딩 확인
공격자 장비에서 통신을 살려 두는 스위치를 확인합니다 (읽기만 합니다).
cat /proc/sys/net/ipv4/ip_forward
출력 (2026-09-09 실측, WSL):
1
읽는 법: 1이면 포워딩 켜짐, 0이면 꺼짐입니다. 이 실측 환경(WSL)은 기본이 1이지만, 일반 리눅스의 기본값은 0입니다 — 랩의 Kali에서는 echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward로 켭니다. 이 스위치가 꺼진 채 스푸핑만 하면 피해자의 인터넷이 끊겨 공격이 바로 드러납니다 — 포워딩은 MITM의 생명줄입니다.
3-5. (랩이 있는 경우) 실제 양방향 스푸핑 — 출력 예시
MS2·Kali Host-only 랩에서의 진행입니다. 아래는 출력 예시이며, 이 책의 실측 환경에서는 패킷 전송을 하지 않았습니다.
# 터미널 1 — 피해자에게 속이기
sudo arpspoof -i eth0 -t 192.168.56.101 192.168.56.1
# 터미널 2 — 게이트웨이에게 속이기
sudo arpspoof -i eth0 -t 192.168.56.1 192.168.56.101
# 포워딩 켜기
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
# 캡처
sudo wireshark & # eth0 캡처, 필터: http 또는 ftp
# 피해자(MS2)가 랩 안의 평문 서비스에 로그인하면 — Wireshark 패킷 상세 (화면 예시)
FTP Request: USER admin
FTP Request: PASS msfadmin
양방향이 살아 있어야 요청과 응답이 모두 보입니다. 한쪽만 보이면 스푸핑 한 방향이 죽은 것 — 6절의 벽 2에서 다룹니다.
3-6. 평문의 최후 — HTTPS 대비 실험의 연결
3-5의 장면에서 PASS msfadmin이 보인 이유는 FTP가 평문이라서입니다. 같은 MITM 자리에서도 HTTPS는 내용이 암호문이라 읽히지 않습니다. Step 85의 대조 실험(HTTP는 읽히고 HTTPS는 안 읽힘)이 바로 이 자리 — 중간자의 의자 — 에서 성립하는 이유입니다. 스푸핑이 위치를 훔치고, 암호화가 내용을 지킵니다. 둘은 다른 층의 방어입니다.
4. 미션과 연습문제
미션 — 스푸핑 시연 pcap과 탐지 노트
- 3-1의 스크립트를 변형해, "공격 전 정상 ARP 왕복(who-has → 정상 is-at)" 장면을 패킷 2개로 앞에 추가한 pcap을 만듭니다 (총 9개 패킷)
- tshark로 판독해 ① 정상 구간과 ② 공격 구간의 경계를 패킷 번호로 표시합니다
-T fields출력에서 "같은 IP를 다투는 두 MAC"을 찾아 인용합니다-z expert,note의 경고를 캡처하고, 이 경고가 무엇을 의미하는지 한 줄로 적습니다- 탐지 노트 완성: "내가 이 네트워크의 방어자라면 어떤 필터와 경고로 이 공격을 잡겠는가"를 필터 문장 2개 이상으로 적습니다
연습문제
문제 1. 단방향 스푸핑 상태에서 공격자에게 보이는 것과 안 보이는 것은 무엇인가요? 왜 그런가요?
문제 2. IP 포워딩을 켜지 않은 MITM이 "도청이 아니라 방해"가 되는 이유를 패킷의 흐름으로 설명해 보세요.
문제 3. tshark의 "Duplicate IP address configured" 경고가 스푸핑 탐지에 유효한 논리를, 3-3의 필드 추출 결과와 연결해 설명해 보세요.
문제 4. MITM에 성공한 공격자 앞에서도 HTTPS 트래픽의 내용이 안 읽히는 이유와, 그럼에도 공격자가 볼 수 있는 것(메타데이터)은 무엇인지 써 보세요.
5. 모범 답안과 완료 기준
미션 모범 답안
2번의 경계 표시 예 (2026-09-09 실측 기반 — 여러분의 9패킷 버전은 번호가 하나씩 밀립니다):
[pcap 판독 노트]
정상 구간: 1~3번 — who-has와 게이트웨이의 정상 is-at (08:00:27:aa:bb:cc)
공격 구간: 4번부터 — 모든 is-at의 hwsrc가 aa:bb:cc:dd:ee:ff
경계의 증거: 같은 IP 192.168.56.1을 주장하는 MAC이 08:00:27:aa:bb:cc → aa:bb:cc:dd:ee:ff로 바뀜
3번의 인용 예: 3-3 출력에서 192.168.56.1 행이 08:00:27:aa:bb:cc와 aa:bb:cc:dd:ee:ff로 갈라지는 부분.
4번의 한 줄 예: "같은 IP 주소를 둘 이상의 MAC이 주장하는 프레임이 관찰됐다는 경고 — ARP 스푸핑 또는 주소 충돌의 신호."
5번의 필터 예:
arp.duplicate-address-frame ← 중복 IP 다툼만 보기
arp.opcode == 2 and (반복 빈도 확인) ← 응답 폭주 감시
검증하는 법: ① 정상 구간이 있는 pcap인가(공격만 있으면 대비가 안 됨). ② 경계를 패킷 번호로 지적했는가. ③ 탐지 필터가 실제로 파일에 적용돼 결과가 나왔는가 — 필터를 쓰고 안 돌려 본 문서는 미완성입니다.
연습문제 해답
문제 1 해답. 피해자→게이트웨이 방향(요청)만 보이고, 게이트웨이→피해자 방향(응답)은 안 보입니다. ARP 테이블은 장비마다 별개라서, 피해자의 테이블만 오염됐다면 게이트웨이는 여전히 피해자의 진짜 MAC으로 곧장 보내기 때문입니다. 대화의 절반만 보이는 상태가 단방향입니다.
문제 2 해답. 오염된 캐시 때문에 피해자의 패킷은 공격자에게 배달됩니다. 포워딩이 꺼져 있으면 공격자의 장비는 그 패킷을 "내 것이 아닌데 왔다"며 버립니다 — 패킷이 게이트웨이에 도달하지 못하니 피해자의 통신은 끊깁니다. 엿보는 것이 아니라 길을 막은 셈이고, 피해자는 곧 이상을 눈치챕니다.
문제 3 해답. 정상 네트워크에서 하나의 IP는 하나의 MAC에 안정적으로 대응합니다(장비 교체 등 드문 예외 제외). 그런데 3-3의 출력처럼 같은 IP(192.168.56.1)가 두 MAC(08:00:27:…, aa:bb:cc:…)에 번갈아 묶이는 것은 누군가 주장을 위조하고 있다는 강한 신호입니다. 스푸핑이 본질적으로 "한 IP에 두 주인" 사건을 만들므로, 이 경고는 그 사건의 직접적 표지입니다.
문제 4 해답. HTTPS의 내용은 TLS 세션 키로 암호화돼 있고, 그 키 합의는 서버의 인증서로 보호되므로 중간자는 암호문만 얻습니다. 다만 메타데이터 — 어느 서버와 통신하는지(IP, 경우에 따라 도메인), 패킷의 크기와 시각, 통신량의 리듬 — 는 암호화 밖에 있어 보입니다. 그래서 방어 설계는 "내용 암호화"와 "중간 경유 자체의 탐지"를 함께 잡습니다.
완료 기준 체크리스트
- [ ] 단방향/양방향 스푸핑의 차이를 "보이는 범위"로 설명할 수 있다
- [ ] scapy로 스푸핑 시연 pcap을 파일로만 조립했다 (전송 없음)
- [ ] tshark
-T fields로 ARP 주장 필드를 추출해 다툼을 확인했다 - [ ] "Duplicate IP address configured" 경고의 의미를 설명할 수 있다
- [ ]
ip_forward의 역할(연결 유지 장치)을 설명할 수 있다 - [ ] 평문 자격 증명 노출과 HTTPS의 차이를 증거로 말할 수 있다
- [ ] 미션: 시연 pcap + 탐지 노트 완성
6. 흔한 실수와 해결
벽 1. pcap을 만들었는데 tshark가 "Duplicate IP" 경고를 안 띄운다
원인: 같은 IP를 주장하는 서로 다른 MAC이 파일 안에 없는 것입니다 — 정상 패킷과 위조 패킷이 같은 IP를 두고 다퉈야 경고가 뜹니다. 위조만 있고 정상이 없으면 다툼이 성립하지 않습니다.
해결: 3-1처럼 정상 is-at을 먼저 넣고 위조를 뒤에 넣으세요. 경고는 "대비" 위에서 켜집니다.
벽 2. (랩 재현 시) 요청만 보이고 응답이 안 보인다
증상: Wireshark에 피해자가 보낸 패킷만 잡힙니다.
원인: 스푸핑이 한 방향만 살아 있습니다 — arpspoof 두 개 중 하나가 죽었거나 틀렸습니다.
해결: 두 터미널이 모두 살아 있는지, -t 뒤의 IP 순서(피해자·게이트웨이)가 반대가 아닌지 확인하세요. 양방향이 모두 살아야 왕복이 보입니다.
벽 3. (랩 재현 시) 스푸핑을 걸자 피해자 인터넷이 끊긴다
원인: ip_forward가 0입니다 — 공격자 장비가 패킷을 전달하지 않아 길이 막혔습니다.
해결: cat /proc/sys/net/ipv4/ip_forward로 확인하고 echo 1 | sudo tee ...로 켜세요. 3-4에서 보았듯 환경에 따라 기본값이 다르므로(실측 WSL은 1), "켰다고 생각"하지 말고 반드시 읽어 확인하는 것이 순서입니다.
벽 4. 패킷을 진짜 네트워크에 보내고 싶은 충동
원인: 파일 조립은 왠지 "가짜 실험"처럼 느껴질 수 있습니다.
해결: 그 충동은 올바른 방향 — 단, 목적지가 문제입니다. VirtualBox Host-only 랩(MS2+Kali)이 그 운동장입니다. 집 공유기·기숙사·회사 망에 한 번이라도 위조 ARP를 뿌리면 같은 네트워크의 모든 장비의 통신이 여러분 손에 걸립니다. 파일 조립이 가짜 실험이 아닌 이유는, 3-2~3-3의 판독 결과가 실제 캡처와 한 글자도 다르지 않기 때문입니다.
벽 5. 평문 캡처가 기대와 다르다 — HTTPS 사이트만 테스트했다
증상: 랩에서 캡처해도 내용이 암호문뿐입니다.
원인: 대상이 HTTPS라면 그것이 정상 결과입니다 — 암호화가 일하고 있는 것입니다.
해결: 평문 실험은 평문 대상으로 — 랩 안에 띄운 HTTP/FTP 서비스입니다. "HTTPS는 중간자에게도 안 읽힌다"는 결과 그 자체가 소중한 관찰이니 노트에 남기세요.
7. 정리
오늘의 개념
| 개념 | 한 줄 설명 |
|---|---|
| 양방향 스푸핑 | 피해자·게이트웨이 양쪽 테이블 오염 — 왕복 전체가 공격자 경유 |
| IP 포워딩 | 받은 패킷을 목적지로 대신 전달 — MITM의 연결 유지 장치 |
| Duplicate IP 경고 | 한 IP를 두 MAC이 다투는 신호 — 스푸핑 탐지의 씨앗 |
| 평문 프로토콜 | HTTP/FTP/Telnet — 자격 증명이 패킷에 글자 그대로 |
| 위치 vs 내용 | 스푸핑은 위치(경유지)를 훔치고, TLS는 내용을 지킨다 — 다른 층의 방어 |
| 공격-탐지 쌍 | 공격을 만들어 본 자만이 탐지의 얼굴을 안다 |
오늘의 명령어·도구
| 명령·도구 | 하는 일 |
|---|---|
wrpcap("파일", 패킷목록) |
패킷을 전송 대신 pcap 파일로 저장 |
tshark -r 파일 |
캡처 파일 판독 |
tshark -T fields -e arp.src.proto_ipv4 -e arp.src.hw_mac |
주장하는 IP·MAC 추출 |
tshark -q -z expert,note |
전문가 경고(중복 IP 등) 요약 |
arp.duplicate-address-frame |
중복 IP 다툼 프레임만 보는 표시 필터 |
cat /proc/sys/net/ipv4/ip_forward |
포워딩 스위치 읽기 |
arpspoof (랩 전용) |
양방향 속임 자동화 — 출력 예시로만 |
명령어보다 중요한 감각
오늘 만든 pcap은 7개의 패킷이지만, 그 안에 공격의 전체 지도가 있습니다 — 정상, 속임의 반복, 양방향의 두 거짓말, 그리고 그 위에 켜지는 탐지 경고까지. 이 지도를 읽을 수 있으면 더 이상 도구의 출력을 "마법의 글자"로 보지 않습니다. 그리고 잊지 마세요 — 이 기술이 무서운 이유는 정교해서가 아니라 어디서나 통해서입니다. 카페 와이파이, 기숙사 망, 허가 없는 사내망 어디서든 한 줄이면 시작됩니다. 그래서 이 지식의 첫 문장은 항상 같습니다 — 내 랩에서만. 그 한 줄을 지키는 사람에게만 이 기술은 무기가 아니라 교양이 됩니다.
전부 체크되면 Step 157 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.