13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] 패키지 관리

  • [Linux] Flatpak vs Snap vs AppImage 2026년 리눅스 데스크톱 앱 완벽 비교 분석

    [Linux] Flatpak vs Snap vs AppImage 2026년 리눅스 데스크톱 앱 완벽 비교 분석

    Flatpak vs Snap vs AppImage 2026년 리눅스 데스크톱 앱 완벽 비교 분석

    리눅스 데스크톱을 쓰다 보면 결국 한 번은 부딪히는 주제가 있습니다. 바로 Flatpak, Snap, AppImage 중 뭘 써야 하냐는 문제죠. 저도 홈랩에서 우분투(Ubuntu), 페도라(Fedora), 데비안(Debian) 계열을 번갈아 굴리다 보니 이 셋을 계속 만나게 되더라고요. 처음엔 “앱만 실행되면 된 거 아닌가?” 싶었는데, 실제로 써보니 설치 방식, 업데이트 방식, 권한 모델, 배포 철학이 꽤 다릅니다. 특히 리눅스 앱을 여러 배포판에서 관리해야 한다면 이 차이를 알아두는 게 정말 시간 절약이 커집니다.

    이번 글은 2026년 시점에서 새 제품 이야기나 확인 안 된 루머는 빼고, 공식 문서와 널리 알려진 사실만 바탕으로 정리했습니다. 결론부터 말하면, 데스크톱 리눅스에서 범용성과 사용자 경험은 Flatpak이 강하고, 운영 일관성과 자동 업데이트는 Snap이 편하며, 가장 가볍고 휴대성 있는 단일 파일 배포는 AppImage가 확실합니다. 다만 “무조건 이게 정답”은 아니고, 쓰는 환경에 따라 선택이 달라집니다.

    Flatpak 중심으로 Snap과 AppImage 구조를 비교한 리눅스 앱 생태계 개요 이미지

    세 가지 패키징 방식이 앱, 런타임, 저장소, 샌드박스와 어떻게 연결되는지 한눈에 보여주는 개요 이미지입니다.

    1. 왜 Flatpak, Snap, AppImage 비교가 중요한가

    예전 패키지 관리는 배포판 저장소가 거의 전부였어요. 그런데 데스크톱 앱은 배포판 릴리스 주기와 앱 업데이트 주기가 잘 안 맞는 경우가 정말 많거든요. 제가 직접 해보니 배포판 기본 저장소는 안정적이지만 버전이 느리고, 서드파티 저장소는 편하지만 관리 포인트가 늘어나더라고요. 이런 틈을 메우려고 나온 게 바로 이 세 가지 포맷입니다.

    • Flatpak: 배포판 독립적인 앱 배포와 샌드박스에 집중합니다.
    • Snap: snapd 기반으로 설치, 격리, 자동 업데이트를 한 덩어리로 제공합니다.
    • AppImage: 앱 하나를 파일 하나로 배포하는 단순함에 집중합니다.

    중요한 포인트! 셋 다 “배포판마다 다른 의존성 지옥”을 줄이려는 목적은 비슷하지만, 해결 방식이 완전히 다릅니다. 그래서 설치만 보고 고르면 나중에 권한 문제, 업데이트 정책, 디스크 사용량에서 다시 삽질하게 되거든요. 저도 처음엔 그랬습니다 ㅎㅎ

    2. 쉽게 이해하는 핵심 개념

    쉽게 말해 보겠습니다.

    • Flatpak은 “공용 런타임 위에 앱을 얹는 방식”에 가깝습니다.
    • Snap은 “스토어와 데몬 중심 관리형 패키지”에 가깝습니다.
    • AppImage는 “설치라기보다 실행 가능한 휴대용 앱 파일”에 가깝습니다.

    Flatpak은 Runtime(런타임)과 Sandbox(샌드박스, 격리 실행 환경) 개념이 핵심입니다. 앱은 런타임 위에서 동작하고, 필요한 권한은 포털이나 명시적 권한으로 접근합니다. 실제로 써보니 데스크톱 통합이 생각보다 잘 되어 있어서, GUI 앱 배포에는 꽤 설득력이 있더라고요.

    Snap은 snapd가 설치와 업데이트를 관리합니다. 특히 자동 업데이트가 기본이라 운영 관점에서는 장점이 분명하죠. 대신 사용자는 “내가 원하는 시점”보다 “정책에 따른 갱신”을 체감하는 일이 생깁니다. 서버나 관리형 워크스테이션에서는 편한데, 데스크톱 사용자는 호불호가 좀 갈리더라고요.

    AppImage는 더 단순합니다. 파일 하나 받아서 실행 권한만 주면 돌릴 수 있는 형태죠. 루트 권한 없이도 쓰기 쉽고, USB나 NAS에서 옮겨 다니기에도 편합니다. 다만 Flatpak이나 Snap처럼 통합된 권한 모델이나 중앙 저장소 중심 운영이 기본 철학은 아니에요. 이건 장점이자 한계입니다.

    3. Flatpak vs Snap vs AppImage 한눈에 비교

    항목 Flatpak Snap AppImage
    기본 철학 데스크톱 앱 중심, 런타임+샌드박스 통합 패키지 관리, snapd 기반 운영 하나의 앱 = 하나의 파일
    설치 방식 원격 저장소(Remote) 또는 .flatpakref Snap Store와 snap 명령 파일 다운로드 후 실행 권한 부여
    격리 모델 샌드박스, 포털 기반 접근 strict/classic 등 confinement 포맷 자체의 통합 샌드박스 모델은 약함
    업데이트 flatpak update 또는 소프트웨어 센터 자동 refresh 기본 제작자가 업데이트 정보를 넣으면 외부 도구로 갱신 가능
    배포판 독립성 높음 높음 매우 높음
    적합한 용도 GUI 데스크톱 앱 정책형 배포, 일관된 운영 휴대용 실행, 빠른 테스트

    제가 실제로 써보니 선택 기준은 정말 단순해요. “일반 데스크톱 사용자”면 Flatpak을 먼저 보고, “자동 갱신과 관리 일관성”이 중요하면 Snap을 보고, “설치 없이 빨리 실행”이 목적이면 AppImage가 편합니다.

    4. 실전 구현: Flatpak, Snap, AppImage 직접 만져보기

    비교 글은 손으로 만져봐야 감이 와요. 아래 명령어는 각 포맷의 철학 차이를 확인하기 좋은 최소 예시입니다.

    4-1. Flatpak 기본 흐름

    1. Flatpak 설치 여부를 확인합니다.
    2. 원격 저장소를 등록합니다.
    3. 앱을 설치하고, 권한과 런타임을 함께 봅니다.
    flatpak --version
    flatpak remotes
    flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
    flatpak install flathub org.gimp.GIMP
    flatpak list
    flatpak info org.gimp.GIMP
    flatpak run org.gimp.GIMP
    flatpak update

    Flatpak은 앱만 보는 게 아니라 runtime도 같이 봐야 합니다. 왜냐하면 앱이 공용 기반을 공유하거든요. 처음엔 이게 좀 복잡해 보였는데, 여러 앱을 돌리다 보면 “중복 패키징을 조금 줄이면서도 샌드박스 유지”라는 의도가 이해가 돼요.

    4-2. Snap 기본 흐름

    1. snapd가 동작 중인지 확인합니다.
    2. 앱 정보를 확인하고 설치합니다.
    3. 권한 격리 수준과 업데이트 정책을 확인합니다.
    snap version
    snap find vlc
    sudo snap install vlc
    snap info vlc
    snap list
    snap refresh --list

    Snap의 포인트는 refresh(자동 업데이트)와 confinement(접근 제한)입니다. 특히 strict는 기본적으로 필요한 접근만 열어 두는 방향이라 보안적으로 명확해요. 다만 앱에 따라 classic이 필요한 경우가 있어서, 여기서 사용감이 갈릴 수 있습니다.

    Flatpak 설치 흐름과 Snap 확인 과정을 비교하는 데스크톱 리눅스 터미널 이미지

    Flatpak과 Snap을 같은 시스템에서 비교 테스트하는 터미널 예시 이미지입니다.

    4-3. AppImage 기본 흐름

    1. AppImage 파일을 내려받습니다.
    2. 실행 권한을 부여합니다.
    3. 그냥 실행합니다.
    chmod +x SomeApp.AppImage
    ./SomeApp.AppImage

    정말 끝입니다. 이 단순함 때문에 AppImage를 좋아하는 분들이 많아요. 저도 테스트용 앱은 AppImage로 먼저 돌려보는 편입니다. 시스템에 깊게 설치하지 않고 바로 확인할 수 있으니까요. 근데 여기서 끝이 아니라, 데스크톱 메뉴 통합이나 업데이트 방식은 제작자와 도구에 따라 편차가 있어요. 이 부분이 Flatpak, Snap과 가장 큰 차이입니다.

    5. ⚠️ 실제로 많이 겪는 문제와 트러블슈팅

    이 섹션은 이론보다 중요합니다. 제가 직접 해보니 여기서 시간을 제일 많이 쓰더라고요.

    5-1. Flatpak에서 파일 접근이 안 되는 경우

    샌드박스 때문에 사용자가 기대하는 경로 접근이 바로 안 될 수 있어요. 특히 홈 디렉터리 전체 접근을 기대하는 앱에서 헷갈리기 쉽습니다.

    flatpak info --show-permissions org.gimp.GIMP
    flatpak permission-reset org.gimp.GIMP

    해결 포인트는 “왜 막혔지?”보다 “원래 기본 차단이구나”로 생각을 바꾸는 거예요. Flatpak은 기본적으로 최소 권한을 지향하니까요. 포털을 통해 파일 열기 같은 동작은 자연스럽게 되지만, 앱이 직접 넓은 파일시스템 접근을 기대하면 차이가 느껴질 수 있습니다.

    5-2. Snap에서 자동 업데이트 타이밍이 부담스러운 경우

    Snap은 자동 갱신이 기본이라 편해요. 그런데 데스크톱에서는 “지금은 건드리지 마…” 싶은 순간이 있죠. 저도 원격 작업 중일 때 이 부분이 꽤 신경 썼었습니다.

    snap refresh --time
    snap refresh --hold

    운영 기준이 분명한 환경이면 오히려 장점이에요. 반대로 개인 데스크톱에서 사용자가 수동 제어를 더 선호한다면 체감이 달라질 수 있습니다.

    5-3. AppImage에서 실행은 되는데 통합이 어색한 경우

    AppImage는 포맷 자체가 단순한 대신, 메뉴 등록, 아이콘 통합, 업데이트 UX가 일관되지 않을 수 있어요. 어떤 앱은 아주 부드럽고, 어떤 앱은 파일 하나 던져놓고 끝나는 식입니다. 이 편차가 은근 커요.

    ls -lh SomeApp.AppImage
    file SomeApp.AppImage

    그리고 환경에 따라 FUSE 관련 이슈를 만날 수도 있어요. 이건 AppImage 문서에서도 자주 다루는 부분이라, 실행이 안 되면 먼저 해당 앱 제공 문서와 AppImage 쪽 가이드를 같이 보는 게 빠릅니다.

    Flatpak 권한, Snap 업데이트, AppImage 실행 설정을 정리한 리눅스 앱 트러블슈팅 이미지

    패키지 형식별로 자주 만나는 문제와 점검 명령을 정리한 트러블슈팅 흐름 이미지입니다.

    6. 검증: 어떤 사용자에게 뭐가 더 맞는가

    비교는 결국 “누가 쓰느냐”로 정리돼요. 저는 아래처럼 판단합니다.

    • Flatpak 추천: GNOME, KDE 같은 데스크톱 환경에서 GUI 앱을 안정적으로 쓰고 싶은 사용자
    • Snap 추천: 자동 업데이트, 배포 일관성, 정책형 운영을 중시하는 사용자
    • AppImage 추천: 설치 부담 없이 바로 실행하고 싶은 사용자, 테스트 용도, 휴대성 중시 사용자

    제가 홈랩에서 여러 배포판을 오가며 써보면, 일반 데스크톱 앱은 Flatpak 쪽이 가장 무난했어요. 관리 체계가 중요할 때는 Snap이 편했습니다. AppImage는 “지금 당장 이 앱만 돌려보자” 할 때 압도적으로 빨라요. 드디어 됐다! 싶은 순간이 AppImage에서 자주 나오긴 합니다. 대신 장기 운영은 Flatpak이나 Snap 쪽이 더 정돈된 느낌이 있어요.

    사용 시나리오 추천 포맷 이유
    일반 데스크톱 앱 설치 Flatpak 샌드박스와 데스크톱 통합의 균형이 좋음
    운영 정책 중심 관리 Snap snapd와 자동 업데이트 모델이 명확함
    설치 없이 바로 실행 AppImage 단일 파일이라 가장 단순함
    배포판 간 빠른 테스트 AppImage 또는 Flatpak 상황에 따라 휴대성 또는 통합성 선택

    사용자 유형과 목적에 따라 어떤 포맷이 더 적합한지 정리한 결과 요약 이미지입니다.

    7. 정리: 2026년 리눅스 앱 선택 기준

    Flatpak vs Snap vs AppImage를 한 줄로 정리하면 이렇습니다. Flatpak은 데스크톱 친화적 균형형, Snap은 관리형 운영 친화형, AppImage는 휴대용 단순 실행형이에요.

    혹시 이런 경험 있으신가요? 같은 앱인데 배포 방식이 다르다고 체감 품질이 달라지는 경우요. 실제로 써보니 설치 성공 여부보다 더 중요한 건 그다음입니다. 업데이트가 자연스러운지, 파일 접근이 납득되는지, 제거와 재설치가 쉬운지, 그리고 내 워크플로에 맞는지가 훨씬 중요하더라고요.

    개인적으로는 초보자나 일반 사용자에게는 Flatpak을 먼저 권하고, 운영 일관성이 핵심인 환경에는 Snap, 빠른 테스트나 일회성 사용에는 AppImage를 권합니다. 이 조합으로 가면 크게 후회할 일이 적었어요.

    다음 글에서는 Flatpak 권한과 Portal 동작 방식을 조금 더 깊게 다뤄볼 예정입니다. 이전 글에서 다뤘던 리눅스 저장소 기반 패키징과 함께 보면 왜 이런 포맷이 등장했는지 더 선명하게 보이실 겁니다.

    Flatpak, Snap, AppImage 장단점을 요약한 데스크톱 리눅스 비교 인포그래픽

    글 전체 내용을 빠르게 복습할 수 있도록 세 포맷의 장단점을 요약한 인포그래픽입니다.

    8. 자주 묻는 질문 FAQ

    Q1. 데스크톱 리눅스에서는 무엇부터 쓰면 될까요?

    특별한 이유가 없다면 Flatpak부터 시작하는 게 무난해요. GUI 앱 경험이 비교적 자연스럽고, 배포판 독립성도 좋으니까요.

    Q2. Snap은 왜 호불호가 갈리나요?

    자동 업데이트와 관리 일관성은 장점인데, 사용자가 수동 제어를 선호하면 불편하게 느낄 수 있어서 그래요.

    Q3. AppImage는 설치가 필요 없다는 게 정말 장점인가요?

    네, 테스트와 휴대성 측면에서는 강력한 장점이에요. 다만 장기 운영에서는 통합성과 업데이트 UX를 꼭 따져봐야 합니다.

    Q4. 세 가지를 같이 써도 되나요?

    된다고 할 수 있죠. 저도 그렇게 써요. 중요한 건 포맷의 철학을 이해하고, 앱 성격에 맞게 고르는 겁니다.

  • [Linux] YUM에서 DNF로: CentOS 7에서 Rocky Linux 9로 마이그레이션

    [Linux] YUM에서 DNF로: CentOS 7에서 Rocky Linux 9로 마이그레이션

    [리눅스] YUM에서 DNF로: CentOS 7에서 Rocky Linux 9로 마이그레이션

    CentOS 7에서 Rocky Linux 9로 넘어가야 하는 시점이 오면 제일 먼저 부딪히는 게 YUM DNF 마이그레이션이더라고요. 운영 서버를 오래 굴려보신 분들은 아시겠지만, 패키지 관리자(package manager) 하나 바뀌는 문제가 생각보다 큽니다. 단순히 명령어만 바뀌는 게 아니라 저장소(repository), 의존성(dependency), 자동화 스크립트, 보안 업데이트 흐름까지 전부 영향받거든요. 특히 CentOS EOL 이후에는 더 미루기 어려워졌습니다. 저도 홈랩이랑 사내 테스트 장비에서 리눅스 OS 이전을 여러 번 해봤는데, 처음엔 “yum만 dnf로 바꾸면 끝 아닌가?” 싶었다가 삽질 좀 했습니다. 이번 글에서는 Rocky Linux 9 기준으로 YUM에서 DNF로 옮길 때 무엇을 확인해야 하는지, 어떤 식으로 이전하면 덜 위험한지 경험 기준으로 정리해보겠습니다.

    CentOS 7에서 Rocky Linux 9로 YUM DNF 마이그레이션 개요 이미지

    CentOS 7 환경에서 Rocky Linux 9 환경으로 넘어가며 패키지 관리 흐름이 바뀌는 모습을 보여주는 개요 이미지입니다.

    1. 왜 지금 YUM DNF 마이그레이션을 봐야 할까요?

    여기서 중요한 포인트가 있습니다. CentOS 7은 이미 수명 주기 종료(EOL, End of Life) 상태라서, 운영 환경에 그대로 두면 보안 패치와 유지보수 측면에서 부담이 커져요. 실제로 서버를 오래 운영하다 보면 “지금 잘 돌아가는데 굳이?”라는 생각이 드는데요, 이런 시기에 더 무서운 건 조용히 쌓이는 기술 부채(technical debt)입니다.

    패키지 관리자 관점에서 보면 CentOS 7은 익숙한 YUM(Yellowdog Updater Modified, RPM 계열 패키지 관리 도구) 중심이었고, Rocky Linux 9는 DNF(Dandified YUM, 개선된 차세대 패키지 관리자)가 기본입니다. 이름만 보면 YUM의 후속 버전처럼 보이지만, 실제로 써보니까 의존성 해결 방식, 메타데이터 처리, 플러그인 사용감이 꽤 달라졌더라고요.

    • CentOS 7은 오래된 운영 환경에 익숙한 자동화가 많이 붙어 있어요.
    • Rocky Linux 9는 보안과 최신 패키지 생태계 측면에서 훨씬 유리합니다.
    • YUM DNF 마이그레이션은 명령어 치환이 아니라 운영 습관 전체를 점검하는 작업에 가깝습니다.

    2. YUM과 DNF, 쉽게 말해 뭐가 다른가요?

    쉽게 말해, YUM이 오래된 익숙한 작업 방식이라면 DNF는 그걸 좀 더 현대적으로 다듬은 도구예요. 저도 처음엔 헷갈렸는데, 실제로 써보니까 차이는 몇 가지로 정리되더라고요.

    항목 CentOS 7 / YUM Rocky Linux 9 / DNF
    기본 패키지 관리자 yum dnf
    의존성 처리 기본적이며 오래된 방식 더 개선된 의존성 해결
    메타데이터 처리 익숙하지만 구형 환경 중심 성능과 관리 편의성이 개선됨
    자동화 스크립트 영향 yum 명령 하드코딩 사례 많음 dnf 기준으로 스크립트 점검 필요
    운영 포인트 레거시 유지보수 현행 표준 운영에 가까움

    Rocky Linux 9에서 yum 명령이 아예 완전히 사라진 건 아닐 수 있어요. 다만 운영 기준으로는 DNF를 표준으로 보고 스크립트와 문서를 정리하는 게 맞습니다. 저는 이 부분을 대충 넘겼다가 자동 배포 스크립트 일부가 애매하게 남아서, 나중에 어떤 서버는 yum, 어떤 서버는 dnf를 쓰는 어정쩡한 상태가 됐더라고요. 이런 건 초기에 정리하는 게 진짜 중요합니다.

    3. 마이그레이션 전략: 인플레이스 업그레이드보다 새 환경 이전이 안전합니다

    여기서 많이 물어보시는 게 “CentOS 7을 Rocky Linux 9로 바로 올리면 되나요?”인데요, 제 경험상 신규 Rocky Linux 9 서버를 만들고 워크로드를 이전하는 방식이 훨씬 안전했어요. 특히 메이저 버전을 두 단계 가까이 건너뛰는 식의 접근은 패키지 충돌, 라이브러리 차이, 서비스 설정 변경 때문에 예상보다 위험하거든요.

    1. 현재 CentOS 7 서버에서 설치 패키지와 저장소 구성을 수집합니다.
    2. 애플리케이션, 데이터, 설정 파일을 분리해서 백업합니다.
    3. 새 Rocky Linux 9 서버를 준비합니다.
    4. DNF 기준으로 필요한 패키지를 다시 설치합니다.
    5. 서비스 설정을 이관하고 동작을 검증합니다.
    6. 컷오버(cutover, 운영 전환) 후 구 서버를 단계적으로 종료합니다.

    이 방식이 귀찮아 보여도, 장애 대응이 훨씬 쉬워요. 실패했을 때 원복(rollback)도 명확하고요.

    4. 실전 구현: CentOS 7에서 현재 상태 정리하기

    제가 직접 해보니 마이그레이션의 절반은 “현재 상태를 얼마나 정확히 기록하느냐”에서 갈려요. 특히 오래된 서버는 누가 왜 추가했는지 모르는 패키지와 서드파티 저장소(third-party repository)가 꼭 있거든요.

    4-1. 설치된 패키지 목록 백업

    rpm -qa | sort > /root/centos7-rpm-list.txt
    yum repolist all > /root/centos7-repolist.txt
    yum history list > /root/centos7-yum-history.txt

    이 세 파일만 있어도 나중에 정말 도움이 돼요. 특히 rpm -qa 결과는 “어떤 기능 때문에 이 패키지가 필요했는지”를 추적하는 출발점이 됩니다.

    4-2. 서비스 목록과 활성화 상태 확인

    systemctl list-unit-files --type=service > /root/centos7-services.txt
    systemctl list-units --type=service --state=running > /root/centos7-running-services.txt

    운영 서버는 패키지보다 서비스가 더 중요해요. 패키지는 다시 깔면 되지만, 어떤 서비스가 자동 시작되었는지를 놓치면 전환 후에 “설치는 됐는데 왜 안 뜨지?” 상황이 바로 생기거든요.

    4-3. 설정 파일과 애플리케이션 데이터 백업

    tar czf /root/etc-backup.tar.gz /etc
    mkdir -p /root/migration-notes
    cp -a /var/www /root/migration-notes/ 2>/dev/null
    cp -a /opt /root/migration-notes/ 2>/dev/null

    물론 실제 운영에서는 애플리케이션별 데이터 경로를 더 정확히 잡아야 합니다. 웹 서버라면 /var/www, 자체 배포 앱이면 /opt, DB면 별도 덤프가 필수죠.

    CentOS 7 서버에서 YUM DNF 마이그레이션 사전 점검을 수행하는 이미지

    이전 작업 전에 현재 서버의 패키지와 서비스 상태를 정리하는 과정을 보여주는 이미지입니다.

    5. 실전 구현: Rocky Linux 9에서 DNF 기반으로 재구성하기

    이제 새 서버 쪽입니다. Rocky Linux 9에 들어오면 운영 습관을 DNF 중심으로 재정리하는 게 핵심이에요.

    5-1. 시스템 갱신과 기본 도구 설치

    sudo dnf update -y
    sudo dnf install -y dnf-plugins-core vim tar rsync

    dnf-plugins-core는 실무에서 꽤 자주 써요. 저장소 관리나 쿼리 작업할 때 진짜 편하더라고요.

    5-2. 자주 쓰는 YUM 명령을 DNF로 치환

    기존 YUM 명령 Rocky Linux 9 DNF 명령 설명
    yum install httpd dnf install httpd 패키지 설치
    yum remove httpd dnf remove httpd 패키지 제거
    yum update dnf update 패키지 갱신
    yum search nginx dnf search nginx 패키지 검색
    yum info podman dnf info podman 패키지 정보 확인
    yum repolist dnf repolist 저장소 목록 확인

    처음엔 별 차이 없어 보이죠. 근데 운영 자동화에서 이 차이가 커요. Ansible(앤서블, 자동화 도구) 플레이북이나 셸 스크립트 안에 yum이 하드코딩되어 있으면, 이참에 dnf 기준으로 정리하는 게 좋아요.

    5-3. 패키지 그룹과 저장소 확인

    sudo dnf repolist
    sudo dnf group list
    sudo dnf module list

    여기서 module(모듈, 버전 스트림 관리 기능) 개념이 처음엔 좀 낯설 수 있어요. 예전처럼 무조건 패키지 이름만 보고 설치하다가 원하는 버전이 안 맞는 경우가 생기거든요. 특히 언어 런타임이나 DB 클라이언트 계열은 모듈/저장소 정책을 한 번 더 확인하는 습관이 필요합니다.

    5-4. 예시: 웹 서버 재구성

    sudo dnf install -y httpd
    sudo systemctl enable --now httpd
    sudo systemctl status httpd

    여기서 중요한 포인트! 패키지 설치만 끝내고 만족하면 안 돼요. 서비스 활성화, 방화벽, SELinux(Security-Enhanced Linux, 보안 정책 프레임워크)까지 같이 봐야 실제 서비스가 떠요.

    sudo firewall-cmd --permanent --add-service=http
    sudo firewall-cmd --permanent --add-service=https
    sudo firewall-cmd --reload
    sudo restorecon -Rv /var/www/html

    CentOS 7에서 대충 넘어가던 권한/보안 이슈가 Rocky Linux 9에선 더 또렷하게 드러나는 경우가 많았어요. 저도 처음엔 “분명 httpd는 떴는데 왜 페이지가 안 보이지?” 하다가 SELinux 컨텍스트(context) 때문에 한참 봤었네요.

    Rocky Linux 9에서 DNF 기반 패키지 관리와 서비스 설정을 보여주는 이미지

    Rocky Linux 9에서 DNF, systemd, firewall-cmd, SELinux를 함께 점검하는 흐름을 보여주는 이미지입니다.

    6. ⚠️ 실제로 많이 걸리는 문제와 해결법

    이 섹션은 제가 특히 강조하고 싶은 부분이에요. YUM DNF 마이그레이션 자체보다, 주변 요소에서 더 많이 막히거든요.

    6-1. 서드파티 저장소가 그대로 안 붙는 문제

    CentOS 7 시절에 붙여둔 외부 저장소가 Rocky Linux 9에서는 바로 호환되지 않는 경우가 있어요. 배포판 버전, GPG 키, 패키지 경로가 달라졌기 때문입니다.

    • 기존 .repo 파일을 그대로 복사하지 마세요.
    • Rocky Linux 9 지원 여부를 먼저 확인하세요.
    • 지원이 불분명하면 OS 기본 저장소 우선으로 재설계하는 게 안전해요.

    6-2. 패키지 이름이 달라졌거나 사라진 문제

    레거시 패키지는 이름이 바뀌거나 더 이상 기본 저장소에 없을 수 있어요. 이럴 때는 억지로 같은 이름만 찾기보다, 기능 단위로 대체 패키지를 찾는 쪽이 낫습니다.

    sudo dnf search <keyword>
    sudo dnf provides '*/binary-name'

    예전엔 패키지 이름을 외워서 설치했다면, 이제는 파일 제공자(provides) 검색을 더 자주 써요. 이거 진짜 편하더라고요.

    6-3. 오래된 스크립트가 yum 전제인 문제

    배치 스크립트나 운영 문서에 이런 코드가 많이 남아 있어요.

    yum install -y rsync
    if yum repolist | grep -q epel; then
      echo "repo exists"
    fi

    이런 부분은 명시적으로 DNF 기준으로 바꾸는 게 좋아요.

    dnf install -y rsync
    if dnf repolist | grep -q epel; then
      echo "repo exists"
    fi

    호환 래퍼(wrapper)가 있더라도 운영 표준은 하나로 맞추세요. 혼용하면 나중에 문서, 인수인계, 자동화에서 꼭 꼬여요.

    6-4. SELinux와 방화벽 이슈

    사실 패키지 설치는 됐는데 서비스가 안 되는 경우, 원인은 DNF가 아니라 보안 정책인 경우가 많아요. 특히 다음 항목을 꼭 같이 봐야 합니다.

    • getenforce로 SELinux 상태 확인
    • journalctl -xeu 서비스명으로 서비스 로그 확인
    • firewall-cmd --list-all로 방화벽 규칙 확인
    • 웹/앱 데이터 경로의 컨텍스트와 권한 확인

    7. 검증: 마이그레이션 결과를 어떻게 확인할까요?

    저는 전환 작업이 끝나면 “설치됐다”가 아니라 “운영 관점에서 정상인가”를 봐요. 검증 체크리스트를 짧게라도 만드는 게 좋습니다.

    1. 필수 패키지가 DNF 기준으로 모두 설치되었는지 확인
    2. 주요 서비스가 부팅 후 자동 시작되는지 확인
    3. 애플리케이션 로그에 의존성 오류가 없는지 확인
    4. 방화벽과 SELinux 정책이 서비스 요구사항과 맞는지 확인
    5. 모니터링과 백업 작업이 새 서버에서 정상 동작하는지 확인
    dnf repolist
    rpm -qa | sort
    systemctl --failed
    ss -tulpn
    journalctl -p err -b

    이 다섯 줄만 잘 봐도 초반 점검은 꽤 돼요. 저는 여기에 애플리케이션 헬스체크(health check)까지 붙여서 최종 확인하는 편이에요. 드디어 됐다! 싶은 순간이 여기서 오죠.

    Rocky Linux 9 이전 후 YUM DNF 마이그레이션 검증 결과 이미지

    이전 후 서비스 상태와 로그를 검증하는 운영 점검 결과를 보여주는 이미지입니다.

    8. 정리와 FAQ: CentOS EOL 이후 운영 습관도 같이 바꿔야 합니다

    이번 YUM DNF 마이그레이션에서 핵심은 간단해요. CentOS 7의 레거시 운영 습관을 Rocky Linux 9 환경에 그대로 들고 오지 말자는 거예요. 패키지 관리자만 바뀌는 게 아니라 저장소 운영, 보안 정책, 자동화 기준까지 함께 정리해야 실제로 편해져요. 저도 처음엔 명령어 몇 개만 바꾸면 되는 줄 알았는데, 결국 문서와 스크립트까지 손봐야 마음이 편하더라고요.

    다음 글에서는 Rocky Linux 9로 넘어온 뒤 EPEL(Extra Packages for Enterprise Linux)이나 컨테이너 도구를 어떻게 정리하면 좋은지 다뤄볼 예정입니다. 이전 글에서 다룬 시스템 백업 전략과 함께 보시면 흐름이 더 잘 잡히실 겁니다.

    자주 묻는 질문

    • Q. CentOS 7에서 Rocky Linux 9로 바로 인플레이스 업그레이드해도 되나요?
      제가 직접 해본 기준으로는 권장하지 않아요. 새 서버를 만들고 데이터와 설정을 옮기는 방식이 훨씬 안전했습니다.
    • Q. Rocky Linux 9에서도 yum 명령을 써도 되나요?
      일부 환경에서는 동작할 수 있어도 운영 표준은 DNF로 맞추는 게 좋아요. 문서와 자동화도 함께 정리하세요.
    • Q. 가장 많이 놓치는 건 뭔가요?
      서드파티 저장소, SELinux, 자동 시작 서비스, 그리고 배포 스크립트 안의 yum 하드코딩입니다.
    YUM DNF 마이그레이션 핵심 체크포인트 요약 이미지

    CentOS 7에서 Rocky Linux 9로 옮길 때 꼭 확인할 체크포인트를 요약한 이미지입니다.

    마무리 체크리스트

    • CentOS EOL 대응이 필요한 서버인지 확인
    • 기존 YUM 기반 패키지와 저장소 목록 백업
    • Rocky Linux 9 신규 서버 준비
    • DNF 기준으로 패키지 재설치 및 저장소 정리
    • 서비스, 방화벽, SELinux, 로그까지 검증
    • 자동화 스크립트와 운영 문서를 DNF 기준으로 통일

    혹시 지금 CentOS 7 서버를 붙잡고 계신다면, 오늘은 최소한 패키지 목록이랑 서비스 목록부터 백업해보세요. 그 한 걸음이 나중에 진짜 큰 차이를 만들어요.

  • [Linux] Ubuntu Server vs Debian Stable: 홈서버 OS 선택 가이드

    [Linux] Ubuntu Server vs Debian Stable: 홈서버 OS 선택 가이드

    홈서버 OS, 뭘 골라야 할까요?

    홈서버를 처음 세팅하거나 기존 OS를 갈아엎으려고 할 때 가장 먼저 부딪히는 질문이 있죠. “Ubuntu Server랑 Debian Stable 중에 뭐가 나아요?” 저도 13년 전에 똑같이 고민했거든요. 그 이후로도 계속 두 배포판을 번갈아 쓰면서 비교해왔습니다.

    Ubuntu Server와 Debian Stable 비교는 리눅스 커뮤니티에서 영원히 끝나지 않는 토론 주제 중 하나예요. “어차피 Ubuntu도 Debian 기반이잖아요”라고 하시는 분들도 있는데, 맞는 말이긴 한데 실제로 써보면 체감 차이가 꽤 납니다. 특히 홈서버 운영하면서 패키지 버전 때문에 삽질해본 분들은 공감하실 거예요.

    이 글에서는 두 OS를 홈랩에서 직접 운영하면서 느낀 차이점을 솔직하게 정리해드릴게요. 어느 쪽이 무조건 낫다가 아니라, 여러분의 상황에 맞는 선택을 할 수 있도록 도와드리는 게 목표입니다.

    Ubuntu Server와 Debian Stable 비교 개요 — 홈서버 OS 선택 가이드

    Ubuntu Server와 Debian Stable — 둘 다 훌륭한 서버 배포판이지만, 방향성이 꽤 다릅니다.

    두 배포판의 철학 차이부터 이해하기

    기술적인 비교 전에 철학적인 차이를 먼저 이해하는 게 중요해요. 쉽게 말해서, 두 리눅스 배포판이 추구하는 방향이 근본적으로 다릅니다.

    Debian Stable은 “절대 깨지지 않는 안정성”을 최우선으로 둡니다. Debian 프로젝트는 커뮤니티가 자발적으로 운영하는 비영리 프로젝트인데요, 패키지를 Stable 브랜치에 올리기 전에 수개월에서 1~2년씩 테스트를 거칩니다. 덕분에 패키지 버전이 좀 구식이더라도, 한번 올라간 패키지는 진짜 안 깨져요. 제가 Debian Stable 서버를 3년 넘게 돌린 적 있는데, apt upgrade 하다가 시스템이 망가진 적이 단 한 번도 없었습니다.

    Ubuntu Server는 Canonical이 개발하고 지원하는데요, Debian을 기반으로 하면서 더 최신 패키지와 사용 편의성을 추가한 형태입니다. 6개월마다 일반 릴리스가 나오고, 2년마다 LTS(Long Term Support, 장기 지원 버전)가 나옵니다. LTS는 5년간 보안 업데이트를 받을 수 있어서 서버용으로는 주로 LTS를 씁니다.

    릴리스 사이클 한눈에 비교

    항목 Debian Stable Ubuntu Server LTS
    릴리스 주기 약 2년 (불규칙) 2년 (짝수 연도 4월)
    지원 기간 약 3년 + LTS 1년 5년 (ESM 포함 10년)
    패키지 신선도 보수적 (안정 우선) 비교적 최신
    개발 주체 커뮤니티 Canonical (기업)
    기업 지원 서드파티 유료 Canonical 공식 지원

    패키지 관리: 신선도 vs 안정성

    홈서버 운영하면서 가장 많이 체감하는 차이가 바로 패키지 버전이에요. 이게 생각보다 꽤 중요하더라고요.

    예를 들어볼게요. 제가 Docker를 Debian Stable에서 공식 저장소로 설치하려고 했더니, 패키지 버전이 꽤 오래된 버전이었습니다. 물론 Docker 공식 저장소를 별도로 추가하면 최신 버전을 쓸 수 있지만, 이런 식으로 외부 저장소를 여러 개 추가하다 보면 나중에 의존성 충돌이 생기기도 하거든요. 반면 Ubuntu Server는 Docker 공식 저장소의 패키지와 호환이 잘 되는 편이었습니다.

    그렇다고 Debian이 무조건 불편한 건 아니에요. 패키지가 구식인 대신, 그 버전에서 발생할 수 있는 버그나 보안 취약점은 백포팅(backporting, 최신 보안 패치를 구버전에 역이식)으로 꾸준히 처리해줍니다. 홈서버에서 특별히 최신 기능이 필요한 게 아니라면 충분해요.

    # Debian에서 backports 저장소 추가하는 방법
    # 더 최신 패키지가 필요할 때 활용
    echo "deb http://deb.debian.org/debian $(lsb_release -cs)-backports main" | \
      sudo tee /etc/apt/sources.list.d/backports.list
    
    sudo apt update
    
    # backports에서 특정 패키지 설치
    sudo apt install -t $(lsb_release -cs)-backports <패키지명>

    Ubuntu는 PPA(Personal Package Archive, 개인 패키지 저장소)라는 시스템도 있어서 공식 저장소에 없는 최신 패키지를 쉽게 추가할 수 있습니다. 홈랩에서 이것저것 실험하기엔 편한데, 프로덕션 서버에선 PPA 남발하면 나중에 관리하기 복잡해지더라고요. 경험상 PPA는 정말 필요한 것만 추가하는 게 낫습니다.

    # Ubuntu PPA 추가 예시
    sudo add-apt-repository ppa:저장소/이름
    sudo apt update
    sudo apt install 패키지명
    
    # 추가된 PPA 목록 확인
    ls /etc/apt/sources.list.d/

    네트워크 설정: Netplan vs interfaces

    이 부분에서 처음에 좀 당황했는데요. Ubuntu Server는 Netplan(넷플랜)이라는 독자적인 네트워크 설정 방식을 사용합니다. YAML 파일로 네트워크를 정의하고, 이걸 systemd-networkd나 NetworkManager에 위임하는 구조예요.

    # Ubuntu Netplan 설정 예시
    # /etc/netplan/00-installer-config.yaml
    network:
      version: 2
      ethernets:
        eth0:
          addresses:
            - 192.168.1.100/24
          routes:
            - to: default
              via: 192.168.1.1
          nameservers:
            addresses:
              - 8.8.8.8
              - 1.1.1.1
    # Netplan 설정 적용
    sudo netplan apply

    Debian은 전통적인 /etc/network/interfaces 방식을 기본으로 씁니다. 오래된 방식이지만 레퍼런스가 많아서 오히려 익숙한 분들도 많아요.

    # Debian /etc/network/interfaces 예시
    auto eth0
    iface eth0 inet static
      address 192.168.1.100
      netmask 255.255.255.0
      gateway 192.168.1.1
      dns-nameservers 8.8.8.8 1.1.1.1

    솔직히 Netplan이 처음엔 낯설었는데, 익숙해지면 YAML로 깔끔하게 관리되는 게 나름 편합니다. 근데 Debian의 interfaces 방식도 간결하고 직관적이라 나쁘진 않아요.

    Ubuntu Netplan과 Debian 네트워크 설정 방식 구조 비교 다이어그램

    Ubuntu의 Netplan과 Debian의 전통적인 네트워크 설정 방식 비교 — 구조는 다르지만 목적은 같습니다.

    실전 홈서버 운영 시나리오별 비교

    이론적인 비교는 충분히 했으니, 실제 홈서버에서 어떤 용도로 쓰냐에 따라 어떤 게 나은지 정리해볼게요.

    시나리오 1: Docker + 컨테이너 환경

    요즘 홈서버는 거의 Docker로 돌리시죠? 이 경우엔 솔직히 Ubuntu Server LTS가 좀 더 편합니다. Docker 공식 문서의 설치 가이드가 Ubuntu 기준으로 작성된 게 많고, 커뮤니티 레퍼런스도 Ubuntu가 압도적으로 많거든요. 처음 세팅할 때 막히는 상황이 생기면 구글링하면 바로 해결책이 나오는 게 Ubuntu 쪽이 훨씬 유리합니다.

    # Ubuntu에서 Docker 공식 저장소로 설치
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
      sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
    
    echo "deb [arch=$(dpkg --print-architecture) \
      signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
      https://download.docker.com/linux/ubuntu \
      $(lsb_release -cs) stable" | \
      sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
    
    sudo apt update && sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin

    시나리오 2: NAS / 파일 서버

    Samba나 NFS로 파일 서버를 운영한다면, 솔직히 두 리눅스 배포판 다 크게 차이 없습니다. 다만 Debian Stable이 장기간 무중단 운영에 더 적합하다는 느낌이 있어요. 업데이트할 때 패키지 변화가 적으니까 예상치 못한 설정 파일 변경이 덜 발생합니다. 저도 NAS 용도로는 Debian을 선호하는 편이에요.

    시나리오 3: 홈 자동화 (Home Assistant 등)

    Home Assistant(홈 어시스턴트)나 Node-RED 같은 홈 자동화 플랫폼을 돌릴 때는 Ubuntu가 유리합니다. 이런 애플리케이션들이 최신 Python 버전이나 최신 의존성 패키지를 필요로 하는 경우가 많아서, 패키지가 보수적인 Debian에서는 추가 설정이 필요할 수 있거든요.

    시나리오 4: 가상화 호스트 (Proxmox 아닌 일반 KVM)

    KVM(Kernel-based Virtual Machine, 커널 기반 가상화)으로 VM 여러 대를 돌리는 경우엔 Debian Stable을 추천드립니다. 호스트 OS는 최대한 안정적이고 변화가 없는 게 좋거든요. VM 안에서 Ubuntu를 돌리면 되니까 호스트는 Debian으로 단단하게 깔아두는 게 제 스타일입니다.

    ⚠️ 주의사항 및 실제 삽질 경험

    두 배포판 모두 써보면서 겪은 실제 문제들을 공유할게요.

    Ubuntu Snap 패키지 주의

    Ubuntu Server를 쓰다 보면 일부 패키지가 apt 대신 Snap(스냅)으로 설치되는 경우가 있습니다. Snap은 샌드박스 환경에서 실행되는 패키지 포맷인데, 경로가 일반 apt 패키지와 달라서 처음엔 당황스럽더라고요. 예를 들어 snap으로 설치된 프로그램은 /snap/bin/에 있어서 스크립트 짤 때 경로 실수가 생기기도 했습니다.

    # Snap 패키지 목록 확인
    snap list
    
    # Snap 대신 apt로 설치하고 싶을 때 (예: lxd)
    sudo snap remove lxd
    sudo apt install lxd  # 혹은 공식 apt 저장소 활용

    Debian 업그레이드 시 설정 파일 충돌

    Debian에서 메이저 버전 업그레이드(예: Bullseye → Bookworm)할 때 설정 파일 충돌 처리가 까다로울 수 있어요. apt가 기존 설정 파일을 유지할지 새 버전으로 교체할지 물어보는데, 여기서 잘못 선택하면 서비스가 안 뜰 수 있습니다. 업그레이드 전에 설정 파일 백업은 필수예요!

    # 중요 설정 파일 백업 스크립트 예시
    backup_dir="/backup/config_$(date +%Y%m%d)"
    sudo mkdir -p "$backup_dir"
    
    # 주요 설정 디렉토리 백업
    sudo cp -a /etc/nginx "$backup_dir/"
    sudo cp -a /etc/samba "$backup_dir/"
    sudo cp -a /etc/network "$backup_dir/"
    
    echo "백업 완료: $backup_dir"

    💡 팁: 어떤 배포판이든 unattended-upgrades는 설정하세요

    홈서버라고 보안 업데이트를 소홀히 하면 안 됩니다. 두 리눅스 배포판 모두 unattended-upgrades로 보안 패치를 자동 적용할 수 있어요.

    # 자동 보안 업데이트 설치
    sudo apt install unattended-upgrades
    sudo dpkg-reconfigure --priority=low unattended-upgrades
    
    # 설정 확인
    cat /etc/apt/apt.conf.d/50unattended-upgrades
    홈서버 용도별 Ubuntu Server vs Debian Stable 선택 플로우차트

    홈서버 용도에 따른 OS 선택 플로우차트 — 어떤 서비스를 돌릴지에 따라 최적의 선택이 달라집니다.

    리눅스 서버 안정성 관점에서의 최종 비교

    리눅스 서버 안정성을 최우선으로 본다면, Debian Stable이 살짝 앞서는 게 사실입니다. 하지만 Ubuntu Server LTS도 5년 지원에 Canonical의 상업적 지원이 뒷받침되니까 절대 불안정한 선택은 아니에요.

    비교 항목 Debian Stable Ubuntu Server LTS 홈서버 관점 추천
    시스템 안정성 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ 장기 무중단: Debian
    패키지 최신성 ⭐⭐⭐ ⭐⭐⭐⭐ 최신 기능 필요: Ubuntu
    레퍼런스/커뮤니티 ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 초보자: Ubuntu
    서버 배포판 다양성 ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ Docker 환경: Ubuntu
    리소스 사용량 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ 저사양 서버: Debian
    설치 편의성 ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 입문자: Ubuntu

    🎉 결론: 이런 분께 이걸 추천드려요

    13년 동안 두 배포판을 오가며 내린 제 결론은 이렇습니다.

    Ubuntu Server LTS를 선택하세요, 만약:

    • 리눅스 서버가 처음이거나 경험이 많지 않은 경우
    • Docker, Kubernetes 같은 컨테이너 기반 인프라를 주로 운영할 때
    • 최신 패키지와 기능이 중요한 홈 자동화, 미디어 서버 환경
    • 구글링으로 빠르게 문제를 해결하고 싶을 때
    • 향후 Canonical의 기업 지원이나 클라우드 연계를 고려할 때

    Debian Stable을 선택하세요, 만약:

    • “한번 세팅하면 몇 년 동안 손 안 대고 싶다”는 스타일
    • 저사양 하드웨어에서 최소한의 리소스로 운영할 때
    • KVM, LXC 같은 가상화 호스트로 쓸 때
    • Snap 같은 추가 패킹 레이어 없이 깔끔하게 관리하고 싶을 때
    • 리눅스에 어느 정도 익숙하고 직접 설정하는 걸 즐길 때

    저 개인적으론 요즘 홈랩에서 가상화 호스트는 Debian, 컨테이너 워크로드가 있는 VM은 Ubuntu Server LTS로 역할을 나눠서 쓰고 있어요. 둘 다 훌륭한 리눅스 서버 배포판이라, 어떤 걸 선택하든 공부하고 경험 쌓는 데는 부족함이 없습니다.

    다음 글에서는 선택한 OS 위에 Docker와 Docker Compose로 홈서버 스택을 구성하는 방법을 다룰 예정이에요. 어떤 배포판을 고르든 그 내용은 공통으로 적용되니 기대해주세요!

    Ubuntu Server vs Debian Stable 최종 비교 요약 인포그래픽 — 홈서버 OS 선택 가이드

    Ubuntu Server vs Debian Stable 최종 선택 가이드 — 여러분의 홈서버 상황에 맞게 골라보세요.

    자주 묻는 질문 (FAQ)

    Q. Ubuntu Server LTS와 Debian Stable 중 보안 업데이트가 더 빠른 쪽은?

    두 배포판 모두 중요한 CVE(보안 취약점)에 대해 신속하게 업데이트를 배포합니다. 다만 Ubuntu는 Canonical의 전담 보안 팀이 있어서 대형 취약점 대응이 약간 더 조직적으로 이뤄지는 편이에요. Debian도 커뮤니티 보안 팀이 매우 적극적이라 실질적인 차이는 크지 않습니다.

    Q. 나중에 Ubuntu에서 Debian으로, 또는 반대로 마이그레이션 할 수 있나요?

    직접 마이그레이션은 권장하지 않습니다. 같은 Debian 계열이라도 패키지 구성이나 설정 위치가 미묘하게 달라서 문제가 생길 수 있어요. OS를 바꿀 때는 깔끔하게 새로 설치하고, 서비스 설정과 데이터를 옮기는 방식이 훨씬 안전합니다.

    Q. 홈서버에 Ubuntu Desktop 버전을 쓰면 안 되나요?

    쓸 수는 있지만, 서버 용도라면 GUI(그래픽 인터페이스) 없는 Ubuntu Server나 Debian이 리소스를 훨씬 적게 쓰고 관리가 단순합니다. Desktop 버전은 GUI 관련 패키지와 서비스가 많아서 서버로는 오버스펙이에요.