집이나 소규모 사무실에서 네트워크 경계부터 분류 라우팅을 한 장비에서 처리하고 싶다면 소프트웨어 라우터에 올린 OpenWrt 위에 Luci 기반 패널인 OpenClash를 얹는 구성을 자주 선택합니다. Windows·macOS에서만 클라이언트를 돌리는 방식과 달리 라우터 쪽에서는 커널 모듈·패키지 관리(opkg)· WAN과 LAN 브리징이라는 새 축이 생겨 초보에게는 허들이 높습니다. 이 글은 2026년 현재까지도 타당한 절차를 기준으로, 기기 선택·펌웨어 선택· 초기 접속부터 OpenClash 설치 의존성·Mihomo 또는 Clash Meta 계열 코어 정렬· 구독(또는 정적 설정) 불러오기· 인터페이스 점검까지 한 흐름으로 적었습니다. 본 게이트웨이 교체형도, 상위 공유기 뒤에 두는 보조 라우터형도 같은 Luci 패널 패턴 위에서 조정 방법만 달라집니다.
먼저 정하기: 장비·목표 형태(OpenWrt 이미지)
OpenWrt는 기판마다 패키지 아키텍처와 무선 드라이버 지원이 다릅니다. 커뮤니티 빌드도 많으니 공식 하드웨어 테이블에서 정확한 모델명으로 검색한 뒤, 내부 플래시 용량이 작으면 extroot·USB 루트 확장이나 경량 프로필을 미리 염두에 두세요. 이미지는 공장 UI에서 복구할 수 있는지, TFTP·시리얼 점퍼가 필요한지도 함께 적어 둡니다.
구성은 크게 둘로 나눌 수 있습니다. 첫째, 기존 ISP 모뎀·공유기의 LAN에 OpenWrt 박스를 붙이고 가정 내부 클라이언트의 기본 게이트웨이만 OpenWrt로 돌리는 방식입니다. 둘째, OpenWrt가 직접 WAN을 붙잡는 메인 라우터 방식입니다. 후자는 DHCP·DNS·포트 포워딩까지 모두 OpenWrt가 담당하므로 첫 부팅 직후 WAN 인터페이스 이름(eth0·pppoe-wan 등)을 Luci에서 한 번 확인하는 습관이 필요합니다.
OpenWrt 설치·첫 로그인(Luci·SSH)
제조사 절차에 따라 이미지를 플래시하거나 sysupgrade로 올립니다. 완료 후 PC를 OpenWrt의 LAN 대역(기본은 192.168.1.0/24 등 문서에 안내된 값)에 두고 브라우저로 접속하면 Luci 초기 설정 마법사가 뜹니다. 비밀번호를 설정하고 무선 라디오 매핑이 있다면 SSID부터 정리하면 이후 테스트가 빨라집니다.
SSH 역시 열어 두세요. GUI가 잠깐이라도 안 보일 때 패키지나 방화벽 규칙을 되돌리는 속도가 달라집니다.
ssh [email protected]
opkg update패키지 인덱스가 갱신되지 않는다면 시간 동기화·DNS·외부 회선 상태를 우선 확인합니다.
WAN/LAN 게이트웨이 개념을 짚어두기
WAN은 상위 ISP 또는 상위 라우터 쪽 계약대역입니다. LAN은 집 장치들이 붙은 내부 브리지입니다. 클라이언트가 게이트웨이 주소만 OpenWrt로 받게 되면 해당 트래픽은 라우팅 규칙에 따라 브라우저· 게임 패치 프로그램· IoT 디바이스까지 한꺼번에 따라가거나 예외 처리됩니다. 상위 라우터 뒤에 둘 때는 WAN이 사실상 업링크 LAN 단일 홉이지만 Luci 카드에서는 여전히 논리적 WAN이라고 불리는 경우가 많으니 카드 이름과 물리 포트 순서만 혼동하지 않으면 됩니다.
패키지·의존성과 코어(Mihomo 및 Clash Meta 계열)
OpenClash 플러그인 계열(luci-app-openclash 등 커뮤니티에서 배포되는 이름 사용)은 내부에서 Clash 규격을 해석할 Mihomo·Clash Meta 등 최신 패밀리 바이너리를 선택할 수 있습니다. 패키지가 자동 조합 의존성을 끌고 오더라도, 커널 모듈이 비어 있는 환경이면 재부팅 후 사라지거나 Tproxy·iptables 방식 매칭이 실패하기도 하니 OpenWrt 버전 문자열(OpenWrt 23.x / 24.x 등)과 커널 릴리스를 기록해 두었다가 릴리스 노트를 대조하는 습관이 좋습니다.
저장 공간이 빠듯하면 핵심 패키지와 로그 디렉터리 경로를 USB나 외장에 두는 식으로 경로를 정리하고, 수동으로 코어 zip을 덮어쓸 때는 실행 권한·아키텍처 일치를 꼭 확인합니다.
OpenClash(Luci App) 설치하기
배포 채널은 릴리스 페이지·소스 트리·사전 빌드된 ipk 묶음 등 여러 갈래가 있습니다. 공통 원칙은 다음과 같습니다.
- 문서에 적힌 시그니처·체크섬이 있으면 검증하고, 모르는 사람이 패치했다고 적힌 비공식 패키지만 섞어 쓰지 않습니다.
- Luci 패키지 화면이나
opkg install명령으로 ipk 계열 파일을 깔았다면 설치 종료 문자열까지 읽습니다. 디스크 마모나 디렉터리 풀이 중간에서 끊기면 부분 설치 상태가 되어 패널 버튼이 회색일 수 있습니다. - 설치 후 Luci 재로드를 한 번 돌린 뒤 메뉴 트리에 OpenClash 항목이 들어오는지 확인합니다.
Luci에서 코어 패밀리 맞추고 서비스 켜기
메뉴에 들어가면 대개 런타임 패밀리 선택· 업데이트 소스 설정· 디버그 레벨 카드가 잡혀 있습니다. 패밀리를 고른 다음 자동 업데이트가 실패했을 때의 수동 교체 순서를 메모합니다. 패널 버튼을 눌러 실행 파일이 기동되는지 상태 표시등이 초록색인지부터 확인하면 이후 라우팅 문제와 분리되어 디버깅이 빨라집니다.
프로파일 또는 구독 URL 반영하기
패널에 있는 가져오기 필드나 파일 업로드를 이용해 노드와 규칙 묶음을 채웁니다. 실패 원인 파악 순서로는 시간 동기화, DNS 순환, 패널 안의 테스트 버튼, 그리고 패널 표시 레벨의 로그 순이 일반적입니다. YAML 문법 에러 메시지가 뜨면 줄 번호 근처의 따옴표·들여쓰기부터 손보는 것이 패널 기능을 덮어쓰는 것보다 안전합니다.
WAN/LAN 시나리오별 검증 절차
메인 라우터 형태라면 DHCP를 켠 클라이언트가 DNS와 게이트웨이를 모두 OpenWrt에서 받는지, 직접 경로여야 할 트래픽이 불필요하게 우회 구간을 타는지 확인합니다. 보조 라우터 형태라면 상위 공유기가 여전히 NAT를 담당하므로 OpenWrt의 WAN은 사설 대역이고, 내부 클라이언트가 기본 게이트웨이를 OpenWrt로만 돌렸는지 점검합니다. 양쪽 모두에서 DNS 누수를 막기 위해 클라이언트가 직접 외부 DNS로 나가는 경로가 남아 있지 않은지 네트워크 진단 도구로 스냅샷을 남깁니다.
문제 해결 체크리스트
- 패키지 설치 실패: 스토리지 여유, 인덱스 미러, ABI 불일치를 순서대로 봅니다.
- 서비스가 즉시 종료: 코어 바이너리 권한·아키텍처·필수 라이브러리 누락을 로그 첫 줄에서 확인합니다.
- 전체 구간이 느려짐: 노드 품질 문제인지 규칙이 국내 트래픽까지 덮었는지, 하드웨어 NAT offload와 충돌하는지를 나눕니다.
- 외부 업데이트 소스 접근 불가: 순수 WAN만으로 테스트한 뒤 별도 백업 회선으로 한 번이라도 패키지·코어 업데이트 경로를 열어둡니다.
더 짧은 Q&A 한눈에 보기
질: OpenWrt를 처음 쓸 때 가장 헷갈리는 게 인터페이스 이름이라면?
답: Luci 디바이스 페이지에서 각 물리 포트 라벨을 찍어두면 이후 패널 카드 순서 바꿀 때 실수가 줄어듭니다.
질: OpenClash 패널 업데이트가 GUI에서만 된다면?
답: SSH로 패키지 재설치·강제 깨끗한 설정 디렉터리 백업 후 덮어쓰기를 병행해 예전 환경 변수가 묻어 있는지 확인합니다.
라우터 셸과 데스크톱 클라이언트를 어떻게 나누면 되나요
한 PC에서만 테스트용으로 GUI를 띄우는 방식은 설치 과정은 단순하지만, 회사 노트북과 스마트 TV· 게임기가 같은 규칙을 공유하지 못합니다. 반면 라우터 셸에서는 커널 경로까지 손대야 해서 디버깅 스텝이 길지만, 집안 트래픽이 한 디바이스에 모일 때 같은 YAML 계보를 다른 단말에 반복 설치하지 않아도 됩니다.
OpenWrt는 한 번 패키지·커널 ABI가 엇갈리면 복구에 시간을 씁니다. 업데이트 주기 불투명한 서드파티 펌과 달리, Mihomo/Clash Meta 계열을 추적 가능한 패널로 묶고 구독만 갈아 끼우는 흐름을 유지하면 장기 운용이 훨씬 가벼워집니다. 공용 다운로드 플로우가 이를 전제로 맞춰져 있으니, 단말용 클라이언트가 필요할 때는 동일한 계보의 바이너리를 골라보는 것도 한 방법입니다.