Debian 12(Bookworm)에서 Clash Verge 설치: 구독 가져오기와 systemd --user 사용자 서비스로 자동 시작

① 왜 Debian 12 전용으로 정리할까요?

Debian은 안정판(stable) 중심이라 패키지 버전이 Ubuntu LTS와도 미묘하게 다르고, 검색어에 Debian 12·Bookworm이 붙었을 때 “그냥 Ubuntu 글을 따라 하면 되지 않나?”라고 생각하기 쉽지만, 기본 저장소에 그래픽 Clash 클라이언트가 없는 경우가 많고, 릴리스 노트·보안 업데이트 리듬도 다릅니다. Fedora처럼 SELinux·firewalld가 기본 화두인 환경도 아니고, Arch처럼 AUR로 올리는 흐름도 아닙니다. 그래서 “Debian Clash”로 찾았을 때 발행판 이름과 설치 단계가 맞는 글이 따로 있으면 첫 설치 시간이 확 줄어듭니다.

Clash Verge(커뮤니티에서 자주 언급되는 Clash Verge Rev 포함)는 프로필을 고르고 코어를 띄우기 쉬운 그래픽 클라이언트라, 터미널만으로 config.yaml을 만지기 싫은 사용자에게 맞습니다. 전체 생태계는 2026년 Clash 생태계 글에서 한 번 잡아 두면 레거시 앱과의 차이를 정리하기 쉽습니다. 이번 주제의 초점은 “설치와 구독”에 더해 사용자 세션이 열릴 때 프록시 스택이 같이 올라오게 맞추는 것입니다.

② 설치 전 점검: Bookworm에서의 패키지·권한·보안

Debian 12에서 서드파티 GUI 앱은 .deb, AppImage, 혹은 배포자가 안내하는 압축 해제형 바이너리로 제공되는 경우가 많습니다. .deb를 쓸 때는 sudo apt install ./패키지.deb처럼 로컬 deb 의존성을 같이 끌어오는 방식이 흔하고, 빌드마다 필요한 최소 런타임(GTK·WebKit 계열 등)이 다를 수 있으니 설치 로그의 의존성 오류를 그대로 해결하는 순서가 안전합니다. AppImage는 chmod +x 후 실행하고, 실행 파일의 절대 경로를 메모해 두면 이후 systemd 사용자 서비스의 ExecStart=에 그대로 넣을 수 있습니다.

노트북에서 Wi-Fi 펌웨어가 non-free 쪽에 있는 기기라면, 네트워크 자체가 불안정하면 프록시 앱만 디버깅하게 됩니다. 데스크톱에 UFW나 다른 방화벽 도구를 올렸다면 로컬 프록시 포트가 막히지 않았는지 확인합니다. 오픈소스 GitHub 저장소는 라이선스·이슈·기여 방식을 보는 용도로 두고, 설치 패키지를 받는 주 경로는 신뢰할 수 있는 배포 안내와 사이트 다운로드 페이지를 함께 참고하는 편이 버전 혼선이 적습니다.

③ Debian 12에서 Clash Verge 설치: 일반적인 순서

배포 형식에 맞춰 앱을 설치한 뒤 한 번 실행해 의존 라이브러리 경고가 없는지 봅니다. Wayland 세션에서 창이 뜨지 않거나 트레이 아이콘이 안 보이면, GNOME·KDE Plasma 등 데스크톱 환경별로 “트레이 확장”이나 “백그라운드 실행 허용” 설정을 확인합니다. 설치 직후에는 아직 구독이 없어도 앱 셸이 뜨는지·로그에 치명적 오류가 없는지만 보면 됩니다.

터미널에 익숙하다면 which clash-verge 또는 패키지 관리자로 바이너리 경로를 확인해 메모하세요. 나중에 systemd --user 유닛을 만들 때 이 경로가 그대로 들어갑니다. 바이너리를 자주 옮기면 유닛 파일도 매번 고쳐야 하므로, 고정 디렉터리(예: ~/Applications 또는 /opt에 심볼릭 링크)를 쓰는 편이 운영이 단순합니다.

④ 구독(Subscription) URL로 프로필 가져오기

앱을 연 뒤 프로필·Profiles 화면에서 URL로 가져오기·새 구독에 들어가 공급자가 준 구독 주소를 붙여 넣습니다. 복사 과정에서 앞뒤 공백·줄바꿈이 섞이면 실패하는 경우가 많으니, 텍스트 편집기에 한 번 붙여 넣어 정리한 뒤 다시 복사하는 습관이 좋습니다.

가져온 뒤에는 업데이트·갱신을 눌러 노드가 채워졌는지 확인합니다. 갱신이 안 되거나 목록이 비면 만료·요청 제한(레이트 리밋)·User-Agent 요구 등을 의심합니다. 이런 증상은 OS를 가리지 않으므로 구독 링크 FAQ를 함께 보시면 원인 분기가 빨라집니다. 프로필이 여러 개일 때는 현재 활성 프로필이 무엇인지 꼭 확인하세요. 잘못된 프로필이 선택되어 있으면 규칙은 있는데 노드 풀이 비어 보이는 일이 생깁니다.

⑤ 연결 방식: 시스템 프록시와 TUN, 그리고 DNS

Linux 데스크톱에서도 축은 두 가지입니다. 시스템 프록시는 데스크톱 환경 설정에 HTTP/HTTPS/SOCKS 엔드포인트를 반영하는 방식이고, TUN은 가상 인터페이스 뒤에서 트래픽을 넓게 잡는 방식입니다. 브라우저·일부 앱은 시스템 프록시를 잘 따르지만, 터미널·일부 런처·자체 스택을 쓰는 프로그램은 환경 변수나 자체 설정 때문에 빗나갈 수 있습니다.

“노드 지연은 뜨는데 웹만 안 열린다”는 질문은 DNS·규칙·실제로 프록시가 켜졌는지로 갈립니다. TUN을 켠 상태에서 DNS가 꼬이면 프로필의 fake-ip·DoH 설정을 함께 봐야 합니다. 개념을 더 깊게 잡고 싶다면 TUN 모드 심화 글의 점검 순서를 참고하면 Debian에서도 진단이 수월합니다. 프록시 그룹 구조가 헷갈리면 프록시 그룹 가이드로 맞춥니다.

⑥ 로그인할 때 자동 실행: XDG 자동 시작(.desktop)

그래픽 클라이언트를 “그냥 켜지게”만 하고 싶다면 자동 시작(Autostart)이 가장 직관적입니다. ~/.config/autostart/에 .desktop 파일을 두고 Exec=에 실행 파일의 전체 경로를 적습니다. 핵심은 그래픽 세션이 올라온 뒤 사용자 환경 변수를 그대로 물려받기 쉽다는 점이라, Wayland·DISPLAY 이슈가 systemd 백그라운드 서비스보다 적은 편입니다.

AppImage라면 Exec=에 AppImage 경로를 그대로 쓰고, 경우에 따라 빌드 안내에 있는 인자 규칙을 따릅니다. 메뉴에 앱이 등록되어 있다면 해당 .desktop 파일을 복사해 자동 시작 폴더로 옮기는 방법도 있습니다. “전원을 켜자마자 로그인 화면만 있고 사용자 세션이 없을 때”까지 코어를 띄워야 한다면 다음 절의 systemd·linger 논의와 요구사항이 달라지므로, 가정을 먼저 정하는 것이 좋습니다.

⑦ systemd --user 사용자 서비스로 자동 실행 맞추기

systemctl --user는 “로그인한 사용자 단위”로 서비스를 관리합니다. 그래픽 앱을 유닛으로 올릴 때는 그래픽 세션이 준비된 뒤 실행되도록 의존 관계를 두는 편이 안전합니다. 빌드·데스크톱 환경마다 최적 값이 달라 아래는 출발점이며, ExecStart=는 반드시 실제 바이너리 경로로 바꿉니다.

~/.config/systemd/user/clash-verge.service를 만든 뒤 systemctl --user daemon-reload, systemctl --user enable --now clash-verge.service 순으로 활성화합니다. 실패하면 journalctl --user -u clash-verge.service -e로 “DISPLAY 없음”, “실행 파일 없음”, “권한 거부”를 빠르게 갈라 봅니다.

[Unit]
Description=Clash Verge (user graphical session)
After=graphical-session-pre.target

[Service]
Type=simple
ExecStart=/usr/bin/clash-verge
Restart=on-failure

[Install]
WantedBy=default.target

위 예시의 ExecStart는 패키지가 설치한 실제 경로로 교체해야 합니다. .desktop 자동 시작에서는 되는데 systemd --user에서만 실패한다면 환경 변수 전달 문제를 우선 의심합니다. “사용자 로그인 없이도 항상 떠 있어야 한다”는 요구는 linger(loginctl enable-linger)와 보안 모델을 다시 검토해야 하는 영역입니다.

⑧ Debian에서 자주 겪는 차이: 안정판 패키지와 데스크톱 스택

Bookworm은 라이브러리가 비교적 보수적이라, 최신 빌드의 GUI 클라이언트가 요구하는 GLIBC·GTK 버전과 맞지 않으면 설치 단계에서 막히기도 합니다. 이때는 배포자가 안내하는 호환 빌드를 쓰거나, 컨테이너·별도 사용자 환경 같은 다른 전략을 검토해야 합니다. 반대로 한 번 맞춰 두면 재부팅 후에도 동작이 잘 유지되는 편이라 서버·워크스테이션 겸용으로 쓰는 사용자에게는 오히려 덜 스트레스인 경우도 있습니다.

Fedora 글에서 강조했던 SELinux·firewalld 튜닝은 Debian 기본 데스크톱에선 상대적으로 드물지만, 사용자가 직접 방화벽 스크립트를 올렸다면 같은 맥락으로 로컬 포트를 점검하면 됩니다. Arch의 롤링 업데이트처럼 “어제까지 되던 게 오늘 안 된다” 리듬도 약해서, 장애가 나면 클라이언트 설정·구독·DNS 쪽을 우선 의심하는 편이 빠릅니다.

⑨ 트러블슈팅 체크리스트: 한 번에 하나씩

아래는 한 번에 여러 가설을 섞지 말고 위에서부터 밟는 순서입니다.

1. 클라이언트에서 코어 실행·시스템 프록시/TUN 스위치가 실제로 켜져 있는지 확인합니다.
2. 브라우저·터미널이 시스템 프록시를 따르는지, 수동 프록시가 예전 값으로 남아 있지 않은지 확인합니다.
3. 다른 VPN·가상 어댑터가 동시에 켜져 있으면 충돌합니다. 한쪽을 끄고 다시 시도합니다.
4. 프록시 그룹이 빈 그룹을 가리키거나, 규칙 모드에서 의도치 않게 DIRECT로 빠지는 도메인이 없는지 확인합니다.
5. DNS가 로컬에서 깨지면 “사이트만 안 열린다”로 보입니다. 프로필의 DNS·fake-ip·fallback을 공급자 문서에 맞게 두었는지 확인합니다.
6. 자동 시작이 중복이면 프로세스가 두 개 떠서 포트가 겹칠 수 있습니다. ps로 중복 실행 여부를 확인합니다.

⑩ 정리: Debian 12에서는 “설치·구독·연결·사용자 자동 시작”을 한 세트로

Debian 12에서 Clash Verge를 쓸 때의 핵심은 Ubuntu·Fedora·Arch 튜토리얼의 패키지 관리자 전제를 그대로 가져오지 않는 것과, 구독만 넣었다고 끝이 아니라는 것입니다. 시스템 프록시와 TUN 중 무엇을 켰는지에 따라 어떤 앱이 잡히는지가 달라지고, 자동 시작은 .desktop이 단순할 때가 많지만 systemd --user가 재시작 정책·로그 측면에서 유리할 때도 있습니다. 노드 지연은 정상인데 웹만 안 열리면 DNS·규칙·프록시 적용 여부를 의심하는 순서가 실전에서 가장 빠릅니다.

상용 VPN 앱과 비교해 Clash 계열은 처음 설정이 길어 보일 수 있지만, 한 번 구조를 잡아 두면 구독과 규칙을 같은 방식으로 여러 기기에 가져갈 수 있다는 장점이 있습니다. 전체 흐름을 한 번에 잡고 싶다면 Clash 입문 튜토리얼을 함께 보시고, 클라이언트 설치와 경로 정리는 다운로드 페이지에서 맞춰 보세요. 규칙 기반 프록시를 안정적으로 쓰려면 DNS·분류 순서를 같은 축으로 맞추는 것이 중요합니다. → Clash를 무료로 내려받고, Debian 데스크톱에서도 Bookworm 환경에 맞게 첫 설정을 마쳐 보세요.