리눅스 업데이트가 거북이처럼 기어가는 모습을 지켜볼 때 오는 아주 특유의 짜증(관심 있으시다면 저는 이걸 '펭귄 분노'라고 부릅니다)이 있습니다. 실패하는 것도, 충돌하는 것도, 불평하는 것조차 아닙니다. 그저 각 패키지와 하나하나 협상이라도 하는 듯 한 발짝씩 나아갈 뿐이죠. 제 시스템에는 문제가 없었습니다. 인터넷도 안정적이었고, 스트리밍, 파일 다운로드, Docker 풀까지 모두 순조로웠습니다. 그런데 apt update에 이어 apt upgrade를 실행하는 순간, 모든 것이 정중하다 못해 수동공격적인 속도로 느려졌습니다. 마치 리눅스가 "언젠가는 도착할 거야"라고 말하는 것 같았죠.
그리고 한동안 저는 그냥 받아들였습니다. 업데이트란 원래 시간이 걸리는 법이니까요. 스포일러 경고: 아닙니다. 전혀 그렇지 않습니다.
문제는 내 시스템이 아니었습니다
느린 업데이트의 원인은 잘못된 미러 선택
출처: Roine Bertelson/MakeUseOf
리눅스는 중앙 서버 하나에서 업데이트를 받지 않습니다. 전 세계 곳곳에 호스팅된 동일한 패키지 복사본인 '미러(mirror)'에서 가져옵니다. 이론적으로는 훌륭한 구조입니다. 중복성, 속도, 안정성까지 확보되니까요. 하지만 실제로는 시스템이 조용히 미러 하나를 골라 운을 믿고 사용할 뿐입니다.
운이 좋으면 빠른 로컬 미러에 연결되어 즉각적인 속도를 체감할 수 있습니다. 하지만 어쩌면 지구 반대편에 있는, 과부하 상태이거나 성능이 부족하거나 그날따라 컨디션이 안 좋은 서버에 갇힐 수도 있습니다. 그리고 시스템은 마치 장기 연애 중인 사람처럼 그 미러를 계속 사용합니다. 제 경우가 딱 그랬습니다. 겉으로 보기에 잘못된 점은 없었습니다. 에러도, 경고도 없었죠. 다만 유독 업데이트만 비정상적으로 오래 걸렸을 뿐입니다.
가장 짜증 나는 부분은 얼마나 미묘하냐는 점입니다. "이거 고장 났네"라고 생각하게 되지 않습니다. "아, 업데이트는 원래 이 정도 걸리나 보다"라고 생각하게 되죠. 하지만 그렇지 않습니다.
미러를 바꿨더니 모든 게 달라졌습니다
더 나은 서버 하나로 업데이트가 극적으로 빨라짐
해결책은 거의 무례할 정도로 간단했습니다. 더 나은 미러로 바꾼 것뿐입니다. Linux Mint와 우분투 계열 배포판에서는 이 기능이 시스템 설정에 기본으로 들어 있습니다. 터미널 의식을 치를 필요도, 포럼을 뒤질 필요도, 2012년 블로그 글에서 명령어를 복사해 붙여넣을 필요도 없습니다.
- 소프트웨어 소스(Software Sources) 열기
- 'Download from' 또는 'Mirror' 섹션 찾기
- 미러 자동 테스트를 돌리거나 가까운 지역의 미러를 직접 선택
- 적용 후 저장소 새로고침
이게 전부입니다. 바로 그 '튜닝'입니다. 다시 업데이트를 실행했을 때 저는 고작해야 약간의 개선을 기대하고 있었습니다. 대신 업데이트가 그냥… 확 진행됐습니다. 패키지들이 쏟아져 들어왔고, 마치 제 시스템이 잠에서 깨어나 꽤 쓸 만한 인터넷 연결이 있다는 사실을 기억해낸 것 같았습니다. 같은 머신, 같은 네트워크, 같은 업데이트였지만 완전히 다른 경험이었습니다. 최적화했다기보다는, 애초에 존재할 이유가 없던 리미터를 제거한 느낌이었습니다.
병렬 다운로드도 함께 활성화했습니다
APT 멀티태스킹으로 불필요한 대기 시간 제거
미러 변경이 얼마나 큰 차이를 만드는지 확인하고 나니 궁금해졌습니다. 설정 하나가 이만큼을 해결한다면, 눈앞에 숨어 있으면서 놓치고 있는 것들이 더 있지 않을까요? 알고 보니 APT는 기본적으로 보수적으로 작동하도록 설계되어 있습니다. 항상 가장 공격적인 다운로드 방식을 쓰지 않는다는 뜻입니다. 줄 서서 기다리고, 순서를 지키고, 끼어들지 않는 식이죠.
공용 미러에서 예의를 지키려는 입장에서는 훌륭한 태도입니다. 하지만 커피가 식기 전에 시스템 업데이트를 끝내고 싶은 사용자에게는 그렇게 반갑지만은 않죠. 그래서 저는 살짝 밀어붙였습니다.
APT 설정을 수정하면 더 적극적인 다운로드 동작을 활성화할 수 있습니다. 예를 들면 다음과 같습니다:
Acquire::Queue-Mode "host";
Acquire::Retries "3";환경에 따라 파이프라인 깊이를 조정하거나 여러 개의 동시 연결을 허용하면, 한 줄로 빈틈없이 차례를 기다리는 대신 훨씬 효율적으로 패키지를 가져올 수 있습니다.
추가로 이것도 넣었습니다:
Acquire::Languages "none";평생 쓸 일이 없는 언어의 번역 파일까지 내려받아 '문화적 완성도'를 채울 필요는 없으니까요.
결과는 미러 교체만큼 드라마틱하지 않았지만, 두 가지를 합치면 시간이 더 단축됐습니다. 업데이트가 더 이상 '해야 할 일'처럼 느껴지지 않았고, 백그라운드에서 자연스럽게 일어나는 이벤트처럼 느껴졌습니다. 원래 있어야 할 자리로 돌아간 거죠.
리눅스는 왜 기본적으로 이렇게 하지 않을까?
시스템은 안정성과 공유 자원을 우선시한다
리눅스가 고의로 우리의 시간을 낭비한다고 비난하기 전에, 여기에는 이유가 있습니다. 미러는 공유 인프라입니다. 모든 머신이 갑자기 공격적인 병렬 다운로드로 미러 서버를 몰아붙인다면 금방 아수라장이 될 것입니다. 그래서 배포판들은 안전하게 움직입니다. 보수적인 기본값, 예측 가능한 동작, 공유 서버에 불필요한 부하 없음. 많은 리눅스 설계 결정 뒤에 있는 철학이기도 합니다. 안정성이 먼저, 성능이 다음, 혼란은 선택 사항.
하지만 그 대가로, 시스템은 이미 필요 없어진 지 오래된 보조바퀴를 달고 계속 달릴 수 있습니다. 특히 쾌적한 인터넷 회선으로 개인 PC를 업데이트하는 사용자라면 더욱 그렇습니다. 데이터 센터의 수십 대 서버를 관리하는 경우와는 상황이 다르니까요.
업데이트 문제 해결은 은근하지만 지속적인 마찰을 없앴다
예상 못 했던 부분은 여기입니다. 사실 제 시스템은 이전에 느리다고 느껴진 적이 없습니다. 눈에 띄는 방식으로는요. 앱은 잘 실행됐고, 멀티태스킹도 부드러웠습니다. '성능 문제'라고 외칠 만한 건 아무것도 없었습니다. 하지만 업데이트를 돌릴 때마다 낮은 강도의 마찰이 있었습니다. "아, 이거 좀 걸리겠는데" 하는 그 느낌 말입니다. 시스템 유지보수가 귀찮고 피하고 싶은 일처럼 느껴질 만큼의 저항감이었죠.
미러를 고치고 APT가 우체국 창구 앞 줄 서듯 행동하지 않도록 만든 뒤, 그 마찰은 완전히 사라졌습니다.
이제 업데이트는 신경 쓸 필요가 없을 만큼 빨라졌습니다. 실행하면 끝나고, 저는 제 할 일로 돌아가면 됩니다. 정신적 부담도, 기다림의 시간도, 배경에서 쌓여가는 은근한 원망도 없습니다. 그래서 깨달았습니다. 때로는 당신의 시스템이 느린 게 아닙니다. 그냥 불필요하게 정중할 뿐입니다. 그리고 조금 더 빨라도 된다고 말해주는 데는 설정 하나면 충분합니다.