노트북 홈서버 k3s 구축기 - 2. usb 굽기 및 홈 네트워크 분석

0. 이번 판의 하드웨어

역할	실물
서버가 될 노트북	Lenovo ThinkBook 16 G7 IML (Core Ultra 5 125H · RAM 32GB) — 내장 NVMe에 Windows 유지
Proxmox가 설치될 디스크	GIGABYTE 1TB SATA SSD (GP-GSTFS31100TNTD) — 다 밀어놔 깨끗한 상태
SSD를 외장으로	넥스트유 6.35cm(2.5") USB 외장 케이스 — 쿠팡에서 7000원 정도?
설치 USB	8GB USB 메모리 (안의 파일은 굽는 순간 전부 지워짐)
콘솔	데스크탑 (같은 공유기 LAN, 유선)

---

1. 설치 USB 굽기 — Rufus, DD 모드

노트북에 Proxmox VE ISO와 Rufus는 받아둔 상태. 이번 작업은 서버가 될 노트북에서 시작한다.

• ISO — 설치 디스크(CD/DVD) 한 장을 통째로 떠놓은 이미지 파일. OS 설치는 빈 컴퓨터에 OS를 넣는 작업이라, 설치기 자체가 "부팅 가능한 디스크" 형태여야 한다.
• Rufus — 그 ISO를 USB에 부팅 가능한 형태로 새겨주는 Windows용 무료 도구. (리눅스의 dd 명령을 GUI로 해주는 것)
• "굽는다" — CD-R 시절 레이저로 디스크를 태워(burn) 기록하던 데서 온 관용어.
• 구운 후 USB 내용은 다 지워진다 — 굽기는 파일 추가가 아니라 디스크 재구성. 부팅은 파일이 아니라 디스크 맨 앞(파티션 테이블·부트 코드)을 읽기 때문에, 기존 파티션을 버리고 ISO 구조를 0번 바이트부터 통째로 덮어쓴다. → 기존 파일 전부 삭제.
• 왜 DD 모드인가 — 부팅은 파일이 아니라 "정해진 위치"를 읽는 연쇄다. ISO는 개발진이 그 위치까지 전부 설계·테스트해둔 완성 디스크의 사진이고, DD 모드 = 그 사진을 그대로 인화(1바이트도 안 바꿈)라 무조건 부팅된다. 반면 ISO 모드 = Rufus가 안의 파일만 꺼내 자기 방식으로 재배치 — 내용은 같아도 위치가 어긋나서, 부팅 연쇄가 중간에 길을 잃고 grub rescue에서 멈추는 사고가 흔하다. 그래서 Proxmox 공식 문서는 DD(통째 복사)를 요구한다.
• ISO모드는 왜 존재하지 그럼? — DD로 부으면 8GB USB가 통째로 "1.5GB짜리 설치 디스크"가 돼서 나머지 공간은 못 쓴다(현재 USB가 지금 그 상태). ISO 모드는 일반 파티션(FAT32)에 파일을 넣는 방식이라 남는 공간에 다른 파일도 담을 수 있다.

굽기 완료. 장치 표시가 "다중 파티션"으로 바뀌었다 — USB가 파일 담는 저장소가 아니라 Proxmox 설치 디스크 그 자체가 됐다는 증거다.

왜 다중 파티션이 됐냐면 — DD가 ISO를 통째로 복제하면서 ISO가 원래 갖고 있던 파티션 구조까지 그대로 새겨져서다. USB 안은 지금 이렇게 생겼다:

8GB USB (= proxmox ISO가 그대로 새겨짐)
┌────────────────────────────────────────────┐
│ 맨 앞  : 파티션 테이블 + 부트코드 (BIOS 부팅용) │
│ 칸 1   : EFI 부팅 파티션(FAT) ← UEFI가 찾는 칸 │ ← Windows가 읽음 (D:)
│ 칸 2   : 설치 내용물 (리눅스 형식)              │ ← Windows가 못 읽음 (E:, "포맷?" 뜨는 칸)
└────────────────────────────────────────────┘

이 구조의 이름이 ISOHybrid다 — 한 파일이 CD로 구워도, USB에 통째로 부어도(DD) 부팅되도록 두 규격을 겹쳐 담은 포장이라는 뜻. 이에 대해 자세하게는 안파헤치고(EFI, UEFI), 알아야 할 중요한 거 하나만 짚으면: 이런 이미지는 재조립(ISO 모드)하지 말고 통째로(DD) 부어야 개발진이 테스트한 그 디스크가 그대로 재현된다.

---

 

2. 네트워크 — 설계, 그리고 우리집 해부

내가 만들 것 — 3층 구조

• 1층: Proxmox — 노트북에 설치하는 하이퍼바이저. VM을 만들고 관리한다.
• 2층: VM 3대 — 각각 k3s 서버 노드가 된다(3대 전부 컨트롤플레인 겸 일꾼 — 이유는 노드구축할 때).
• 3층: 클러스터 — k3s 위에 서비스(대기열·예매·프론트)와 ArgoCD·LGTM 스택(Grafana 포함)·Redis·Kafka·MySQL·Calico·MetalLB·Traefik을 올린다.

조작은 전부 데스크탑(콘솔)에서 한다 — 노트북은 설치 후 화면 닫고 구석에 두는 서버다. 그래서 이 절의 질문은 하나다: 데스크탑에서 노트북 속 VM들까지 어떻게 닿는가.

 

기준점 — 표준 집의 네트워크

인터넷(ISP) ──공인 IP 1개──▶ [공유기] ── 사설망 192.168.0.x 창조
                                ├─ 유선: 데스크탑 (.100)
                                └─ WiFi: 노트북   (.101)

• 공인 IP(인터넷 어디서든 통하는 주소)는 공유기 하나만 받는다. 집 안 기기는 유선이든 WiFi든 전부 공유기한테서 사설 IP(그 집 안에서만 통하는 주소)를 받는다 = 같은 망.
• 같은 망끼리는 주소로 직접 통신한다. 공유기 관리 페이지의 "연결된 기기 목록" = 이 망의 주민 명단.
• 이 망(서로 주소로 직접 통신하는 기기들의 무리)에서 공유기가 하는 일은 셋이다: 주소 체계 선포("이 안은 192.168.0.x를 쓴다, 나는 .1이다") · 번호 발급과 명단 관리(DHCP) · 주민이 인터넷 갈 때 대표로 나가주기(NAT — 뒤에서 다시 만난다). 셋 다 소프트웨어 기능이라, 공유기라는 전용 기계가 아니어도 — 컴퓨터든 VM이든 — 맡을 수 있다.

그러면 답의 모양도 정해진다 — VM들이 이 기기 목록에 주민으로 오르면, 데스크탑에서 직행이 된다. 남은 건 그걸 어떻게 만드느냐다.

 

고려 1 — 노트북의 재료: 물리 NIC 두 개

NIC	실물	상태
유선	Intel I219-V — 옆면 RJ-45 랜포트의 주인	노는 중
WiFi	Intel AX211	통신 중

NIC(랜카드) = 신호를 쏘고 받는 부품이자 MAC 주소(기기 고유번호)의 주인. 용어를 한 줄로 정리하면 — NIC은 칩, 랜포트는 그 칩이 쓰는 구멍, RJ-45는 그 구멍의 규격, 거기에 랜선이 꽂힌다. 노트북이 바깥세상과 통하는 길은 이 둘뿐이다.

 

고려 2 — Proxmox의 특성: VM은 가상 스위치에 꽂힌다

Proxmox를 설치하면 노트북 안에 가상 스위치 vmbr0(브리지)가 생기고, Proxmox 자신과 VM들(각자 가상 NIC = 자기 MAC·IP)이 여기 꽂힌다. 여기서 둘을 기억해야 한다.

• 스위치의 원칙: 스위치는 망을 만들 수 없고, 넓힐 수만 있다. 주소를 나눠주는 건 라우터(공유기)의 일이다.
• 가상이라서 생기는 제약: 신호를 실제로 쏘는 건 물리 부품뿐이라, 바깥과 이으려면 고려 1의 물리 NIC 중 하나가 바깥 다리가 돼야 한다.

가상 스위치는 필요하면 여러 개 만들 수 있고, 스위치 하나마다 고를 수 있는 길이 두 갈래였다.

• 유선 NIC에 잇기 → 집 망의 연장. VM들이 공유기한테 직접 IP를 받는다 — 위에서 정한 답 그대로, 기기 목록의 주민이 된다. (WiFi NIC으론 왜 안 되는지는 아래에서.)
• 직결하지 않기 → 별개의 섬. 직결 안 한 스위치는 그 자체로 고립된 섬이고, 세상과 이어지는 길은 하나뿐이다 — 누군가 집 망과 섬 양쪽에 걸쳐 서서, 섬의 선포자 겸 문이 되는 것. 공유기가 인터넷과 집 망 사이에서 하는 그 포지션을, 집 망과 섬 사이에서 한 번 더 하는 셈이다. 그 "누군가"가 누구냐로 갈린다.
  • 노트북 자신 = NAT 방식. 노트북이 집 망에선 주민(IP 하나)이면서, 자기 휘하에 사설망을 하나 더 만들어 VM들을 그 위에서 돌린다. VM들은 인터넷에 나갈 수 있지만(전부 노트북 신원으로 나가서 — WiFi로도 된다), 콘솔과 같은 망이 아니라서 접근이 안 된다 — 집 망에서 보이는 건 노트북 1대뿐. 랜선 없이 노트북만으로 굴릴 때 쓰는 방식.
  • 방화벽 VM(OPNsense) = 격리망. OPNsense가 연장(vmbr0)에선 주민이면서, 섬에선 선포자 겸 유일한 문이 된다. 모든 출입이 방화벽을 통과한다.

 

 

결정 — 연장으로 시작, 공개 때 섬

• 구축·검증 단계 = 연장. 콘솔에서 전부 직접 닿아야 만들고 고치는 속도가 나온다.
• NAT 방식은 탈락. VM이 노트북 뒤에 숨어 콘솔 직행이 깨진다 — 우리 요구와 정반대.
• 외부 공개 시점 = 섬 + 문지기. 섬용 스위치(두 번째 가상 스위치, 관례상 vmbr1)를 하나 더 만들어 노드들을 옮기고 OPNsense를 세운다 — 공개 서버가 뚫려도 집 망으로 못 번지게. 그때부터 콘솔의 관리 접근은 문지기가 내주는 전용 통로(VPN)로 바뀐다.
• 이사와 문지기 시공은 별도 편. 설계는 처음부터 여기까지 포함한다.

왜 유선 NIC이어야 하나 — WiFi는 안 되나

• 망 안 통신은 보낸사람 MAC이 적힌 봉투(프레임) 단위다. 브리지에 탄 VM의 봉투는 VM 자신의 MAC으로 나간다 — 그래야 공유기가 VM을 별개 주민으로 등록한다.
• 유선 포트는 "한 구멍 뒤 MAC 여러 개"가 정상 설계라 이걸 받아준다. WiFi는 인증 맺은 MAC 하나와의 계약이라, 공유기(무선 신호를 받는 쪽, AP)가 낯선 MAC(VM)의 봉투를 버린다 — 한 대여도 안 된다(Proxmox Wiki — WLAN).
• 그래서 다리는 노는 중인 유선 NIC(I219-V)이다. 랜선이 필요하다.

 

 

그래서 할 일 — 토대 둘

콘솔에서 직행해야 할 곳 — 웹UI :8006 · 노드 SSH · kubectl 6443 · MetalLB 서비스 주소들 · 부하 테스트(k6) 트래픽의 목적지 — 에 전부 닿으려면 토대가 둘 필요하다. (:8006 같은 숫자는 포트 — 한 주소 안에서 서비스별로 나뉜 창구 번호다. 랜포트라는 물리 구멍과는 다른 말.)

1. 노트북을 랜선으로 공유기에 꽂는다 — 유선 NIC이 vmbr0의 바깥 다리가 되고, vmbr0은 집 망의 연장이 된다. (나중에 설 OPNsense도 바깥 다리는 vmbr0로 딛는다.)
2. 데스크탑(콘솔)·노트북·VM이 같은 망(같은 기기 목록)에 있어야 한다.

                 랜선 1가닥 (밖으로 나가는 바깥 다리)
                    │
  ┌─ 노트북 ────────┴─────────────┐
  │   유선 NIC (I219-V)            │
  │        │                       │
  │   vmbr0 = 가상 스위치          │
  │    ├─ Proxmox 자신             │
  │    ├─ VM 1  ├─ VM 2  ├─ VM 3  │
  └────────────────────────────────┘

표준 집이라면 여기서 끝이다 — 랜선 하나만 꽂으면 토대 2까지 저절로 채워진다.

 

그런데 우리집은 표준이 아니었다.

---

우리집 해부 — 두 기기의 주소가 다르다

해부는 데스크탑과 노트북의 ipconfig를 나란히 놓는 데서 시작됐다.

기기	주소	기본 게이트웨이	발급자
데스크탑 (유선)	121.168.x.x (DNS 접미사 kornet — KT망에 직접 물렸다는 흔적)	121.168.x.1 — 집 안에 없다(KT 장비)	KT 직접 → 공인 IP
노트북 (WiFi)	172.30.1.x	172.30.1.254 — 거실 공유기	거실 공유기 → 사설 IP

기본 게이트웨이 = 그 기기가 다른 망으로 나갈 때 처음 거치는 관문. 이게 누구냐가 곧 "누구 밑에 사는가"다. 같은 집의 두 기기가 서로 다른 발급자한테, 서로 다른 종류의 주소를 받고 있다.

실측도 일치한다 — 데스크탑에서 노트북 쪽 망의 입구(노트북의 게이트웨이 = 거실 공유기 .254)에 ping을 쏴도 100% 손실. 입구조차 안 닿으니 그 안의 노트북은 당연히 못 닿는다.

공인 IP와 사설 IP

• 사설 IP = RFC 1918이 내부망용으로 떼어둔 대역. 수백만 집이 같은 번호를 재사용하므로 인터넷에선 배달 불능이다.
  • 10.x.x.x — 대규모 조직·클라우드에서 흔함
  • 172.16.x.x–172.31.x.x — ★노트북(172.30.1.x)이 여기
  • 192.168.x.x — 가정 공유기 기본값으로 제일 흔함
• 공인 IP = 집·회사 설정에서 만나는 주소 기준으론, 사설 대역 밖은 사실상 전부 공인이다(엄밀히는 127.x 루프백, 169.254.x 링크로컬, 통신사 내부용 100.64.x 같은 예외 대역도 있다). 전 세계 유일, 인터넷 어디서든 통한다. 유한 자원이라 ISP가 관리하고, 가정 회선엔 몇 개만 준다.
• 함정 하나: 121.168은 192.168과 닮았지만 사설이 아니다 — KT가 보유한 공인 블록.
• 주소만 봐도 위치가 읽힌다: 사설 대역 = 공유기(NAT) 뒤 / 공인 = 인터넷에 직접.

 

드러난 구조 — 선을 뽑아가며 그린 지도

【 KT 인터넷 】
      │  (이 선 뽑으면 → 데스크탑 사망 확인. 위치상 온 집이 같이 죽는 선이다)
      ▼
┌─ 내 방 모뎀 — 주소 안 만드는 분배기 ────────┐
│   LAN ──▶ 옆방 PC     : KT 공인 IP ①        │
│   LAN ──▶ 내 데스크탑  : KT 공인 IP ②        │ ◀━ "큰길" (KT가 직접 발급)
│   LAN ──▶ 빈 포트 ★                         │
│   LAN4 ─▶ 거실행 ───────────┐               │
└─────────────────────────────│───────────────┘
                              │ 벽 속 링크 (뽑으면 → 온 집 WiFi 사망)
                              ▼
┌─ 거실 공유기 — 골목 선포자, KT 공인 IP ③ ────┐
│   [인터넷 구멍] ← 방에서 온 링크 도착          │
│   ─── 이 안쪽 = 사설 골목 172.30.1.x ───     │
│   WiFi ~~▶ 노트북 · 핸드폰                   │ ◀━ "골목" (공유기 DHCP가 발급)
│   LAN ──▶ TV                                │
│   LAN4 ─▶ 죽은 예비선                        │
└──────────────────────────────────────────────┘

• KT 선이 내 방으로 들어와 모뎀(주소를 만들지 않는 분배기 — 정체는 결론에서 밝혀진다)에 꽂히고, 모뎀에 꽂힌 기기들은 KT한테 공인 IP를 직접 받는다 — "큰길".
• 모뎀의 LAN4가 벽을 타고 거실 공유기의 인터넷 구멍으로 이어지고, 공유기가 사설 골목(172.30.1.x)을 선포해 WiFi로 뿌린다 — "골목". 노트북이 여기 산다.
• 실물을 보면 방 벽 한 구멍에서 랜선이 두 가닥으로 갈라져 나온다(아래 사진). 이유 = 페어 분할. 랜선 8가닥을 4+4로 갈라 링크 2개(방으로 들어오는 길 + 거실로 가는 길)로 쓴 시공. 대가: 이 구간 최대 100Mbps.

ping이 죽은 이유 — 두 기기가 다른 세계에 있다

원인은 구조 그 자체다.

• 데스크탑은 큰길에 있다 — KT한테 직접 받은 공인 IP, 게이트웨이는 집 밖 KT 라우터.
• 노트북은 골목에 있다 — 거실 공유기가 선포한 사설망(172.30.1.x)의 주민.
• 사설 주소는 인터넷에서 배달 불능이다. 그래서 데스크탑이 .254로 쏜 ping은 자기 게이트웨이(집 밖 KT 라우터)로 나간 뒤 거기서 폐기된다 — 골목 문 앞에도 못 간다. 이게 스크린샷의 100% 손실이다.
• 골목의 문을 공인 IP ③으로 직접 두드려도 결과는 같다 — 공유기의 장부(NAT — 골목에서 시작된 대화의 기록)에 없는 첫 방문은 버려지고, 밖→안은 포트포워딩으로만 열린다. 골목 안 주민끼리만 문 없이 직행한다.

 

그래서 생기는 문제

• 콘솔과 서버가 다른 세계다. 데스크탑(큰길)에서 노트북(골목)으로 직행이 안 되니, 이대로는 웹UI도 SSH도 kubectl도 성립하지 않는다.
• 우회로도 전부 막혀 있다.
  • 거실 공유기를 방으로 가져온다? 불가 — 온 집 WiFi(폰·노트북)와 TV가 그 공유기에 매달려 있다. 애초에 방안에있는 모뎀에서 선이 거실로 이어져서 공유기에 연결되기에, 가져오면 너무 복잡해질 것 같다.(왜 이렇게 했던거지 기사님..)
  • 모뎀의 빈 포트에 노트북을 직결해 큰길에 합류한다? 접근 자체는 성립하지만 발급에서 죽는다 — 브리지는 호스트 1 + VM 3 = 새 공인 IP 4개를 요구한다(현재 3개 사용 중, 합계 7개). 가정 회선이 내주는 공인 IP는 몇 개 수준이라 클러스터가 불성립하고, 설령 다 받아도 노드들이 NAT 방패 없이 인터넷에 알몸으로 선다.

 

 

결론 — 서버를 어디에 꽂을 것인가

후보들은 하나씩 논리와 실물 앞에서 죽었다.

후보	판정
거실 공유기를 방으로 가져온다	✗ 위에서 본 대로 — 가족이 매달려 있다
모뎀 빈 포트에 노트북 직결(큰길 합류)	✗ 위에서 본 대로 — 공인 IP 총량 불성립 + 알몸 노출
노트북을 거실 골목에 두고 포트포워딩으로 관리	✗ 관리 문들(웹UI·SSH·6443)이 데스크탑만이 아니라 인터넷 전체에 열림 + 서비스 늘 때마다 규칙 누더기 + 가족 장비 조작 + 서버 거실 상주
공유기 없이 처음부터 OPNsense + VPN으로	✗ OPNsense는 Proxmox 위의 VM — 관리 통로를 만드는 도구를 만들려면 관리 통로가 먼저 필요한 순환. 구축 내내 노트북을 직접 만져야 한다
모뎀을 버리고 새 공유기가 최상류를 대체	✗ 라벨 한 장으로 사망(아래)
모뎀은 그대로, 빈 포트에 새 공유기 → "내 골목" 창조	✓

최상류 교체안(모뎀을 공유기로)은 모뎀을 뒤집어 라벨을 읽는 순간 죽었다. 제품명 KT GiGA UTP — 벽에서 오는 KT 회선을 이더넷으로 바꿔주는 진짜 모뎀(회선 종단 장비)이라 일반 공유기의 WAN이 이 자리를 대신할 수 없고, 라벨 맨 아래엔 "본 제품은 (주)KT의 자산으로, 서비스 해지 시 반납"이라 적혀 있다. 버릴 수도, 대체할 수도 없는 물건이다.

 

 

그래서 답은 소거로 남았다 — 모뎀은 그대로 두고, 빈 포트에 공유기를 꽂아 내 방에 사설 골목을 만든다.

모뎀(KT GiGA UTP): 인터넷선 · 옆방 PC(공인 유지) · 거실행(LAN4) — 전부 그대로
                    └ 빈 포트 ──▶ [새 공유기 WAN]
새 공유기(내 골목):  LAN ◀── 내 데스크탑(콘솔) · 노트북(서버)

• 내 데스크탑이 큰길에서 골목으로 이사하며 공인 IP를 반납하고, 그 자리를 새 공유기가 받는다 — 집 전체 공인 IP 사용은 3개 그대로, 새로 요구하는 게 없다.
• 옆방 PC와 거실 공유기는 손대지 않는다 — 가족 망 무영향. 내 공유기가 죽어도 내 골목만 죽는다.
• 대가: 공유기 한 대 + 랜선 두 가닥(모뎀↔공유기, 노트북↔공유기) 구매.
• 배선 후 검증: 데스크탑 ipconfig에 사설 IP + 게이트웨이 = 새 공유기가 뜨면 이사 완료 — 그리고 그 100% 손실이던 ping이 처음으로 뚫릴 것.

이걸로 토대 둘이 채워진다 — 노트북이 랜선으로 공유기에(유선 다리), 콘솔·노트북·VM이 같은 망에. 보통 집이 공짜로 갖고 시작하는 표준 상태를,나는 공유기 한 대를 사서 직접 만들어야한다.

[외부 공개 시점의 최종형]
인터넷(KT) ── 모뎀(큰길)
                └ [내 공유기] ─ 내 골목 ─┬ 데스크탑(콘솔)
                                        └ 노트북 ─ vmbr0(연장) ─ [OPNsense] ─ vmbr1(서버 섬) ─ k3s 노드

단, 구축·검증 단계엔 k3s 노드들이 vmbr0(연장)에 직접 꽂힌다 — 콘솔 직행. OPNsense와 vmbr1은 외부 공개 시점의 이사 후 모습이고, 그때 내 공유기는 "443 창구 → OPNsense" 하나만 여는 첫 번째 문이 된다(문 두 겹 — 이중 NAT).

공유기하나랑 랜선 두개 시켜놨으니.. 오기전까지 좀만 쉬었다가 다시 작업 이어가야할 것 같다.

---

 

3. 다음

• 3부. 내 골목 개통, 그리고 Proxmox 설치 — 공유기 배선(그 100% 손실이던 ping이 처음 뚫리는 순간) · 듀얼부팅 시계 맞추기(RTC=UTC) · F12 부팅 · 설치 마법사(★디스크 선택 — 내장 NVMe가 아니라 외장 SSD) · 데스크탑 브라우저에서 웹UI :8006 첫 접속.