Arch Linux 마이그레이션: Debian에서 Arch로 전환한 이유와 과정

홈랩을 굴리다 보면 한 번쯤은 운영체제 선택을 다시 보게 됩니다. 저도 꽤 오래 Debian을 메인 서버와 작업용 장비에 섞어 써왔는데요, 어느 순간부턴 패키지 흐름과 시스템 구성을 좀 더 제가 주도적으로 가져가고 싶어졌습니다. 결국 Arch Linux 마이그레이션을 직접 진행해봤고, 단순히 ‘최신 패키지가 좋아 보여서’가 아니라 실제로 왜 옮겼는지, 어떤 부분에서 만족했고 어디서 삽질했는지까지 정리해봤습니다. 혹시 지금 Debian을 쓰고 있는데 Linux 전환을 고민 중이라면, 이 글이 판단 기준을 잡는 데 도움이 될 겁니다.

저는 13년 정도 인프라 일을 하면서 느낀 게 하나 있습니다. 운영체제는 정답보다 운영 방식이 더 중요하다는 점이죠. 안정성만 볼 건지, 패키지 최신성을 볼 건지, 아니면 시스템을 내가 어느 정도까지 이해하고 통제하고 싶은지에 따라 선택이 달라지거든요. 이번 글은 Arch가 무조건 낫다는 이야기가 아니라, Debian에서 Arch로 넘어갈 때 실제로 어떤 생각과 과정을 거치게 되는지를 경험 기준으로 풀어보는 글입니다.

Debian 환경 분석부터 Arch 설치, 데이터 이전, 검증까지의 전체 마이그레이션 흐름입니다.

왜 Debian에서 Arch로 옮겼을까

쉽게 말해 Debian은 예측 가능하고 안정적인 쪽에 강하고, Arch Linux는 가볍고 직접 구성하는 재미와 통제감이 큰 쪽입니다. 저도 한동안은 Debian 특유의 차분함이 정말 좋았거든요. 서버에 올려두면 조용히 자기 할 일 하면서 크게 신경 쓸 게 없으니까요. 근데 홈랩에서 이것저것 실험하다 보니, 새 도구를 붙일 때 패키지 흐름이 조금 답답하게 느껴지더라고요.

특히 제가 중요하게 본 건 아래 세 가지였습니다.

• 패키지 관리 흐름: 필요한 구성만 올리고 군더더기 없이 유지하고 싶었습니다.
• 학습 효과: 시스템 부팅, 네트워크, initramfs(초기 RAM 파일시스템), bootloader(부트로더) 같은 기본기를 다시 손으로 만져보고 싶었습니다.
• 변경 통제: 자동으로 많은 것이 깔리는 방식보다, 내가 설치한 것만 정확히 알고 운영하는 쪽이 편했습니다.

물론 반대급부도 있습니다. Arch는 편하게 굴리려면 결국 문서를 자주 읽고, 변경 사항을 챙기고, 내 시스템을 내가 책임져야 하거든요. 이게 누군가에겐 귀찮음인데, 저한테는 오히려 장점이더라고요. 그래서 이번 Arch Linux 마이그레이션은 단순 교체가 아니라 운영 철학을 바꾸는 작업에 가까웠습니다.

마이그레이션 전에 이해해야 할 개념

저도 처음엔 ‘설치만 하면 비슷하지 않나?’ 싶었는데, 실제로는 접근 방식이 꽤 다릅니다. 여기서 중요한 개념 몇 가지를 먼저 짚고 가겠습니다.

패키지 정책 차이

Debian은 안정성 중심으로 검증된 패키지를 오래 유지하는 편입니다. 반면 Arch Linux는 rolling release(롤링 릴리스, 큰 버전 업그레이드 없이 지속적으로 최신 패키지를 반영하는 방식) 성격이 강합니다. 이 차이는 단순히 최신/구버전 문제가 아니라, 운영 리듬 자체를 바꿉니다.

설치 철학 차이

Debian은 설치 과정에서 비교적 많은 걸 잡아줍니다. Arch는 기본 뼈대만 주고, 나머지는 사용자가 조립하는 느낌이죠. 쉽게 말해 Debian이 ‘잘 정리된 공구함’이라면, Arch는 ‘공구는 줄 테니 네가 필요한 구조를 직접 만들라’에 가깝습니다.

시스템 이해도 요구치

Arch를 쓰면 파일시스템, 마운트, 네트워크, locale(로캘, 언어/지역 설정), user management(사용자 관리) 같은 기본 개념을 더 자주 보게 됩니다. 귀찮기도 한데요, 신기하게도 몇 번 삽질하고 나면 시스템이 훨씬 덜 무섭습니다. 이건 꽤 큰 장점이더라고요.

마이그레이션 전에 제가 먼저 체크한 것들

여기서 중요한 포인트! 운영체제 갈아타기 전에 제일 먼저 할 일은 설치 USB를 만드는 게 아닙니다. 현재 시스템 의존성 파악이 먼저거든요. 저도 초반에 이걸 대충 봤다가 서비스 하나가 안 떠서 한참 찾았습니다 ㅎㅎ

1. 서비스 목록 정리: 웹서버, SSH, 컨테이너, cron(주기 작업), 모니터링 에이전트를 먼저 적어둡니다.
2. 데이터 위치 확인: /etc, /var/lib, /srv, 사용자 홈 디렉터리처럼 실제 필요한 데이터가 어디 있는지 확인합니다.
3. 패키지 의존성 확인: Debian에서 쓰던 패키지 이름이 Arch에서 그대로 통하지 않는 경우가 많습니다.
4. 부팅 방식 확인: UEFI(통합 확장 펌웨어 인터페이스)인지 legacy BIOS인지 확인해야 합니다.
5. 백업 검증: 백업이 있다는 것과 복구가 된다는 건 다릅니다. 작은 파일이라도 실제 복원 테스트를 해보세요.

제가 실제로 메모했던 항목은 대략 이런 식이었습니다.

# Debian 쪽에서 현재 상태 점검
lsblk -f
ip addr
systemctl list-unit-files --type=service
crontab -l
sudo ss -tulpn
sudo find /etc -maxdepth 2 -type f | sort

이 단계가 지루해 보여도 정말 중요합니다. Arch Linux 마이그레이션은 설치보다 이전 대상 파악이 절반입니다.

실전 설치 과정: Debian에서 Arch로의 전환 순서

이제 본격적으로 설치 과정입니다. 저는 테스트 장비에서 먼저 한 번 해보고, 그 다음 실제로 쓰는 시스템에 적용했습니다. 그게 마음이 제일 편하더라고요.

1. 설치 미디어로 부팅하고 네트워크 확인

ip link
ping -c 3 archlinux.org
timedatectl

유선이면 대부분 바로 잡히지만, 무선은 장비 따라 추가 설정이 필요할 수 있습니다. 시간 동기화가 꼬이면 나중에 패키지 검증이나 TLS(전송 계층 보안) 관련 문제가 생길 수 있어서 꼭 확인했습니다.

2. 디스크 파티션과 파일시스템 준비

lsblk
fdisk /dev/sdX
mkfs.fat -F32 /dev/sdX1
mkfs.ext4 /dev/sdX2
mount /dev/sdX2 /mnt
mkdir -p /mnt/boot
mount /dev/sdX1 /mnt/boot

여기서 <code>/dev/sdX는 실제 디스크로 바꿔야 합니다. 이 부분은 정말 조심하셔야 합니다. 저도 예전에 습관적으로 명령 넣다가 다른 디스크를 건드릴 뻔한 적이 있거든요. ⚠️ 장비가 여러 개 달린 홈랩이면 특히 lsblk 결과를 두 번 보세요.

UEFI 부팅용 파티션과 루트 파티션을 나누고, /mnt 아래에 마운트하는 흐름을 시각화한 이미지입니다.

3. 기본 시스템 설치

pacstrap /mnt base linux linux-firmware vim networkmanager sudo
genfstab -U /mnt >> /mnt/etc/fstab
arch-chroot /mnt

처음엔 이게 뭔가 싶었는데, 생각보다 구조는 단순합니다. pacstrap으로 기본 시스템을 넣고, genfstab으로 마운트 정보를 만들고, arch-chroot로 새 시스템 안에 들어가는 방식이거든요.

4. 시간대, 로캘, 호스트명 설정

ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime
hwclock --systohc
vim /etc/locale.gen
locale-gen
echo "LANG=ko_KR.UTF-8" > /etc/locale.conf
echo "arch-host" > /etc/hostname

/etc/hosts도 함께 맞춰두는 편이 좋습니다.

cat > /etc/hosts <<'EOF'
127.0.0.1 localhost
::1       localhost
127.0.1.1 arch-host.localdomain arch-host
EOF

5. 네트워크와 사용자 설정

systemctl enable NetworkManager
passwd
useradd -m -G wheel -s /bin/bash myuser
passwd myuser
EDITOR=vim visudo

visudo에서 wheel 그룹 sudo 권한을 활성화합니다. 저는 최소 권한 원칙을 좋아해서, 처음엔 꼭 필요한 계정만 만들고 나중에 확장하는 편입니다.

6. 부트로더 설정

pacman -S grub efibootmgr
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg

부팅 환경은 장비마다 차이가 큽니다. 그래서 저는 이 단계에서 절대 서두르지 않습니다. 설치가 다 된 것 같아도, 사실 가장 긴장되는 순간은 첫 재부팅 직전이거든요.

7. 재부팅 후 기본 패키지 정리

exit
umount -R /mnt
reboot

부팅이 올라오면 SSH, 에디터, 모니터링 도구, 컨테이너 런타임 같은 필수 패키지를 하나씩 올립니다. Debian에서 쓰던 환경을 그대로 복제하려 하기보다, 정말 필요한 구성만 다시 쌓는다는 느낌으로 접근하니 훨씬 깔끔했습니다.

설정과 데이터 이전은 이렇게 했습니다

운영체제를 바꾸는 것보다 더 중요한 건 서비스 복구입니다. 특히 홈랩이나 개인 서버는 ‘부팅 성공’보다 ‘기존 워크로드가 제대로 도는가’가 핵심이죠.

1. /etc 설정 비교: 서비스 설정 파일을 그대로 덮어쓰기보다, 새 기본 설정과 비교하며 필요한 값만 반영했습니다.
2. 데이터 디렉터리 이전: 애플리케이션 데이터는 rsync(증분 복사 도구)로 옮겼습니다.
3. 비밀 정보 분리: 키 파일, 인증서, 토큰은 따로 점검했습니다.
4. 서비스 단위 재기동: 한 번에 다 올리지 말고 서비스별로 검증했습니다.

sudo rsync -avh /old-root/etc/nginx/ /etc/nginx/
sudo rsync -avh /old-root/var/lib/docker/ /var/lib/docker/
sudo systemctl daemon-reload
sudo systemctl restart nginx
sudo systemctl status nginx

근데 여기서 함정이 하나 있습니다. Debian에서 잘 돌던 설정이 Arch에서도 그대로 맞는다고 생각하면 안 된다는 거죠. 경로, 기본 서비스명, 패키지 분리가 조금씩 다를 수 있거든요. 저도 여기서 몇 번 멈췄습니다.

설정 파일 비교, 데이터 복사, systemd 서비스 재시작과 상태 확인 과정을 보여주는 이미지입니다.

⚠️ 실제로 겪었던 문제와 해결 방법

이 섹션은 좀 현실적으로 가보겠습니다. 설치 과정 문서만 보면 다 매끈하게 끝날 것 같지만, 실제 Linux 전환은 꼭 한두 군데서 걸립니다.

문제 1. 네트워크는 잡혔는데 이름 해석이 이상함

부팅은 됐는데 외부 패키지 저장소 접근이 들쑥날쑥했던 적이 있었습니다. 확인해보니 DNS(도메인 네임 시스템) 설정이 기대와 다르게 잡혀 있더라고요.

resolvectl status
systemctl status NetworkManager

해결은 단순했습니다. NetworkManager가 관리하도록 두고, 중복 네트워크 설정 파일을 정리했습니다. 여러 네트워크 관리 도구를 섞어 쓰면 꼭 꼬이더라고요.

문제 2. 부팅은 되는데 원하는 커널 옵션이 반영되지 않음

이건 주로 GRUB 설정 재생성을 빼먹었을 때 생겼습니다. 설정 파일만 수정하고 끝낸 줄 알았는데 실제 부팅 메뉴에는 반영이 안 된 거죠.

grub-mkconfig -o /boot/grub/grub.cfg

별거 아닌데, 처음엔 왜 안 되지 싶어서 한참 봤습니다 ㅎㅎ

문제 3. 서비스는 설치됐는데 자동 시작이 안 됨

Debian에서 당연히 올라오던 서비스가 Arch에선 비활성 상태인 경우가 있었습니다. 특히 설치와 활성화가 분리돼 있다는 걸 잠깐 잊고 있었거든요.

systemctl enable --now sshd
systemctl enable --now docker

이건 systemd(시스템 및 서비스 관리자) 운영할 때 자주 보는 패턴이라, 설치 후 enable --now 습관을 들이면 편합니다.

문제 4. 예전 설정을 통째로 덮어써서 오히려 꼬임

제가 가장 크게 삽질한 부분입니다. 예전 /etc 설정을 거의 그대로 가져왔더니 새 환경 기본값과 충돌하더라고요. 여기서 배운 건 하나입니다. 설정은 이관이 아니라 재해석이 필요하다는 거죠. 특히 네트워크, 로깅, 인증 관련 설정은 꼭 새 기본 파일과 비교하세요.

검증과 결과: 마이그레이션이 끝났는지 어떻게 확인할까

운영체제 설치가 끝났다고 마이그레이션이 끝난 건 아닙니다. 실제 검증 항목이 통과해야 비로소 끝난 거죠. 저는 아래 순서로 확인했습니다.

1. 부팅 확인: 재부팅 후 정상 로그인 가능 여부
2. 네트워크 확인: 내부 통신, 외부 통신, DNS 확인
3. 서비스 확인: 웹, SSH, 컨테이너, 스케줄러 점검
4. 로그 확인: journalctl로 에러 여부 점검
5. 리소스 확인: 디스크 마운트, 메모리, 프로세스 상태 확인

systemctl --failed
journalctl -p 3 -xb
df -h
free -h
ss -tulpn

제가 직접 해보니, Arch로 옮기고 나서 가장 만족스러웠던 부분은 시스템이 가볍고 구조가 머릿속에 잘 들어온다는 점이었습니다. 내가 뭘 설치했고, 왜 돌아가고 있는지 추적이 쉽더라고요. 반면 운영 자동화가 덜 되어 있어서, 손이 더 가는 순간도 분명히 있습니다. 그래서 개인적으로는 ‘무조건 전환’보다 ‘내가 원하는 운영 방식에 맞는가’를 기준으로 보시는 걸 추천드립니다.

서비스 정상 상태, 디스크 마운트, 시스템 로그 점검 등 마이그레이션 검증 결과를 시각화한 이미지입니다.

Debian과 Arch, 누구에게 더 맞을까

사실 이 질문이 제일 중요합니다. 둘 다 좋은 운영체제인데, 쓰는 사람의 목적이 다를 뿐이죠.

• Debian이 더 맞는 경우: 장기 안정 운영, 표준화된 서버 환경, 예측 가능한 업데이트를 선호할 때
• Arch가 더 맞는 경우: 직접 구성, 최신 패키지 흐름, 시스템 학습 효과, 가벼운 환경을 원할 때

저는 홈랩과 개인 작업 환경에서는 Arch가 꽤 잘 맞았습니다. 하지만 모든 프로덕션 서버에 바로 동일하게 들이밀 생각은 없습니다. 역할이 다르니까요. 이 균형감이 중요합니다.

자주 묻는 질문

Q. Debian에서 Arch로 바로 넘어가도 될까요?

가능은 합니다. 다만 메인 장비 하나만 있는 상태라면 먼저 테스트 장비나 가상머신에서 설치 과정을 한 번 돌려보는 걸 추천드립니다. 저도 그게 훨씬 안전했습니다.

Q. Arch Linux 마이그레이션이 초보자에게도 괜찮을까요?

초보자도 할 수는 있지만, 부팅 구조와 파일시스템, 네트워크 기본 개념을 조금 알고 시작하면 훨씬 덜 힘듭니다. 아무것도 모른 채 시작하면 중간에 왜 안 되는지 판단이 어렵거든요.

Q. 기존 Debian 설정 파일은 그대로 복사하면 되나요?

일부는 가능하지만, 통째로 덮어쓰는 건 추천하지 않습니다. 새 환경 기본 설정과 비교해서 필요한 값만 옮기는 방식이 안전합니다.

마무리: 운영체제를 바꾸는 게 아니라 운영 방식을 바꾸는 일

이번 Arch Linux 마이그레이션을 하면서 다시 느낀 건, 운영체제 전환은 설치 이벤트가 아니라 운영 습관의 재설계라는 점입니다. Debian에서는 안정성과 편의성을 많이 얻었고, Arch에서는 통제감과 학습 효과를 얻었습니다. 둘 중 뭐가 더 낫다기보다, 내가 어떤 엔지니어링 경험을 원하는지가 더 중요하더라고요.

혹시 지금 Debian에서 다른 배포판으로 Linux 전환을 고민하고 계신다면, 먼저 서비스 의존성부터 정리해보세요. 그 다음 테스트 환경에서 설치를 한 번 끝까지 밀어보면 감이 확 옵니다. 드디어 됐다! 하는 순간도 분명히 오고요. 반대로 ‘아, 이건 내 운영 스타일이 아니구나’를 빨리 깨닫는 것도 큰 수확입니다.

다음 글에서는 이번 환경을 바탕으로 systemd 서비스 정리와 백업 자동화를 어떻게 붙였는지 이어서 다뤄볼 예정입니다. 이전 글에서 홈랩 스토리지 구성 이야기를 보셨다면, 이번 마이그레이션과 함께 보면 더 흐름이 잘 보이실 겁니다.

안정성, 최신성, 학습 효과, 운영 편의성 관점에서 Debian과 Arch 선택 기준을 요약한 인포그래픽입니다.