C# 개발자를 위한 Linux 패키지 업데이트

Linux 패키지 관리가 Windows와 다른 점

[0:00 - 0:38] 팀은 Windows에서 온 개발자들이 흔히 겪는 장애물을 설명하며 시작합니다. Windows에서는 각 애플리케이션이 일반적으로 자체 업데이트를 관리합니다. Visual Studio는 Edge와 독립적으로 업데이트를 확인하며, 이는 프린터 드라이버와는 별도로 업데이트됩니다. 기계에 설치된 모든 것을 추적하는 단일 시스템은 없습니다.

Linux는 중앙 집중식 접근 방식을 취합니다. apt(Advanced Package Tool)와 같은 패키지 관리자는 공식 저장소에서 설치된 모든 소프트웨어를 추적합니다. 업데이트를 실행하면 apt는 설치된 모든 패키지를 한 번에 쿼리합니다. 브라우저 업데이트, 라이브러리 패치, SDK 업그레이드, 보안 수정 모두 동일한 파이프라인을 통해 도착합니다.

C# 개발자에게 이는 실질적인 함의가 있습니다. .NET 런타임, HTTPS 호출이 종속된 OpenSSL 라이브러리, 애플리케이션이 연결된 시스템 레벨 종속성은 모두 이 시스템에 의해 관리됩니다. 비-Windows 플랫폼에서 처음으로 C#을 시작하는 경우, 패키지 관리자가 어떻게 작동하는지 아는 것이 나중에 미스터리한 빌드 실패를 추적하는 것을 피하게 합니다. 경우에 따라 여러 개의 별도 업데이트를 Windows에서 조정해야 하는데 apt upgrade 하나만으로 전체 스택을 정렬할 수 있습니다.

GUI: 업데이트 관리자

[0:38 - 1:34] 시각적 워크플로우를 선호하는 개발자를 위해, 팀은 처음으로 업데이트 관리자를 설명합니다. Linux Mint에는 Windows 업데이트와 유사하게 작동하는 것이 포함되어 있습니다. 하단 오른쪽 코너의 작업 표시줄의 작은 아이콘을 열면, 정확히 어떤 것이 업데이트될 것인지 보입니다: Microsoft Edge, Firefox, curl, libssh 등. 각 항목은 현재 버전, 새 버전 및 다운로드 크기를 표시합니다.

모든 패키지는 기본적으로 선택되어 있지만 특정 업데이트를 건너뛰고자 하는 경우 항목의 선택을 해제할 수 있습니다. 프로젝트에 특정 도구 버전이 필요하고 변경을 원하지 않을 때 유용합니다.

"업데이트 설치"를 클릭하고, 프롬프트가 표시되면 비밀번호를 입력하며, 프로세스가 완료될 때까지 기다립니다. 비밀번호 프롬프트는 시스템 패키지를 수정하는 것이 관리 작업이기 때문에 존재하며, 이는 다음 섹션에서 다룰 것입니다.

GUI가 잘하는 한 가지: 업데이트를 위험 수준에 따라 분류하고 시스템 안정성에 영향을 줄 수 있는 변경 사항에 대해 더 보수적입니다. 세부 사항에 대해 걱정하지 않고 단순히 환경을 건강하게 유지하고자 하는 Linux 초보 개발자에게 업데이트 관리자는 확실한 기본값입니다.

sudo 이해하기

[1:34 - 1:51] 터미널로 이동하기 전에 Tim은 모든 명령줄 패키지 작업에 나타나는 sudo에 대해 설명할 시간을 가집니다. 입력하기 전에 그것이 무엇을 하는지 이해할 만한 가치가 있습니다. 대부분의 Windows 사용자 계정은 기본적으로 관리 계정이며, 시스템 소프트웨어를 설치, 제거 및 수정하는 완전한 접근을 제공합니다. Linux는 반대 접근 방식을 취합니다: 여러분의 계정은 제한된 권한으로 실행되며 필요한 경우에만 관리자 권한으로 상승합니다.

sudo로 명령을 앞에 붙이면 비밀번호 입력 요청이 뜨며 신원을 확인합니다. 인증이 완료되면 그 명령은 루트 권한으로 실행되고, 이후에는 권한이 정상으로 돌아갑니다. 패키지 관리(소프트웨어 설치, 제거 또는 업데이트)는 기기의 모든 응용 프로그램에 영향을 미칠 수 있는 시스템 수준 작업이므로, 명시적 sudo 접두사를 사용하면 다른 작업을 하려다 의도치 않게 시스템 패키지를 수정하는 일을 방지할 수 있습니다.

Windows를 사용한 경험이 있는 경우, 이를 관리자 권한으로 Visual Studio를 실행하는 것과 비슷하게 생각해 보십시오. 다만 Linux에서는 개별 명령을 상승시키지 전체 애플리케이션을 상승시키는 것이 아닙니다. 이는 보다 목표지향적 모델입니다.

명령줄: apt update

[1:51 - 2:28] sudo에 대해 설명한 후, Tim은 터미널로 이동합니다. 그곳에서 작업하면 업데이트 프로세스에 대한 더 정교한 제어가 가능하며, 팀은 세 개의 명령을 순서대로 설명합니다. 각 명령이 무엇을 하는지 이해하는 것이 중요합니다 왜냐하면 그는 명칭이 오해의 소지가 있다고 지적합니다.

첫 번째 명령은:

sudo apt update

sudo apt update

일반적인 가정은 이 명령이 패키지를 업데이트한다는 것입니다. 그렇지 않습니다. apt update는 사용 가능한 소프트웨어의 로컬 카탈로그인 패키지 인덱스를 새로 고칩니다. 시간이 지나면서 유지보수 담당자가 새로운 버전을 출시할 때 그 카탈로그는 오래되기 때문에 이 명령을 실행하면 저장소 서버에서 최신 버전을 다운로드합니다. 귀하의 기계의 소프트웨어에 대한 변경 사항은 없습니다. 이는 순수하게 정보를 수집하는 단계입니다.

이를 실행한 후, apt는 최신 버전이 있는 여러 패키지를 보고합니다. 변경 사항을 확정하기 전에 전체 목록을 검사할 수 있습니다:

apt list --upgradeable

apt list --upgradeable

이는 새로운 버전이 가능한 모든 패키지에 대한 행별 보기를 제공하며, 현재 및 새 버전 번호를 포함합니다. 귀하의 기계에서 .NET을 사용하고 있다면, 이는 SDK 업데이트, 런타임 패치, 또는 애플리케이션이 의존하는 라이브러리의 변경 사항을 볼 수 있는 곳입니다. 귀하의 기계에 어떤 .NET 버전이 사용되는지 이해하면 특정 업그레이드를 안전하게 적용해야 하는지 또는 테스트가 필요한지 여부를 결정하는 데 도움이 됩니다.

명령줄: apt upgrade

[3:01 - 3:40] 인덱스를 최신 상태로 만든 후, 팀은 실제로 새로운 버전을 설치하는 두 번째 명령으로 이동합니다:

sudo apt upgrade

sudo apt upgrade

명칭에 주목하십시오: 최신 정보를 가져오는 데는 update를 사용하고, 패키지를 변경하는 것은 upgrade입니다. 그 두 단계 분할은 의도적입니다. "사용 가능한 것을 확인" 단계와 "변경 적용" 단계를 분리하여, 이동하기 전에 검토, 연구 또는 백업할 시간을 제공합니다.

기본적으로 upgrade는 수행할 작업과 하지 않을 작업에 대한 엄격한 규칙을 따릅니다. 그것은 이미 시스템에 있는 패키지의 최신 버전을 다운로드 및 설치하지만, 기존 패키지를 제거하거나 이전에 없던 새 패키지를 설치하지는 않습니다. 새 버전이 설치되지 않은 종속 항목을 필요로 할 때, upgrade은 새로운 종속 항목을 자동으로 가져오는 대신 해당 패키지를 보류합니다.

장점은 예측 가능성입니다. 귀하의 .NET 스택을 최신 상태로 유지하는 것은 중요하지만 이를 통제된 방식으로 수행하는 것도 중요합니다. 시스템은 변경될 내용을 요약하여 알리고, 진행하기 전에 확인을 요청하므로 사용자의 명시적인 허가 없이 아무것도 발생하지 않습니다.

명령줄: full-upgrade

[3:40 - 4:19] 안전한 업데이트가 적용된 후, Tim은 upgrade이 고의로 보류했던 모든 것을 처리하는 세 번째 명령을 소개합니다:

sudo apt full-upgrade

sudo apt full-upgrade

full-upgrade은 upgrade이 고의적으로 피하는 경우를 처리합니다. 패키지 업데이트가 새로운 종속 항목 설치나 충돌하는 패키지 제거를 필요로 할 경우, full-upgrade가 이를 처리합니다. 커널 업그레이드, 주요 시스템 라이브러리 변경 및 OS 레벨 패치는 여기서 적용됩니다.

이를 별도의 단계로 실행하면 계층화된 접근을 제공합니다. 복잡한 종속성 해결 중 문제가 발생하면, 이미 간단한 업데이트는 적용되어 있으므로 더 복잡한 것만 트러블슈팅할 필요가 있습니다.

Linux에서 C# 애플리케이션을 컴파일하는 빌드 파이프라인을 관리하는 팀에게 이 단계적 워크플로우는 특히 중요합니다. 자동화된 CI/CD 환경에서는 안정성을 위해 apt upgrade만 실행하고, 나머지 full-upgrade는 시스템 변경 후 모든 것이 여전히 컴파일되고 통과하는지 확인할 수 있는 유지 관리 윈도우에 예약하여 실행할 수 있습니다.

패키지 수가 다른 이유

정기적으로 사람들을 혼란스럽게 만드는 부분: 업데이트 매니저에서는 23개의 업데이트를 보여주지만, 명령줄에서는 79개의 패키지를 보고할 수 있습니다. 이것들은 다른 업데이트 집합이 아닙니다; 같은 시스템인데 다르게 계산된 것입니다.

GUI는 관련된 패키지를 논리적 단위로 그룹화합니다. 업데이트 관리자에서 단일 "Firefox 업데이트"는 실제로 Firefox 바이너리, 로컬화 팩, 해당이 의존하는 공유 라이브러리 및 설정 패키지로 구성될 수 있으며, 각각은 apt에 의해 별도의 패키지로 추적됩니다. 따라서 업데이트 관리자가 하나의 업데이트로 제시하는 것을 apt는 네 개 또는 다섯 개의 개별 패키지 업그레이드로 나열합니다.

이를 알게 되면, 차이는 더 이상 당황스럽지 않습니다. 누군가는 "업그레이드해야 할 패키지가 100개 있었다"라고 말할 수도 있지만, 업데이트 관리자에는 동일한 변경 사항이 30개의 업데이트로 표시됩니다.

Flatpak: 별도의 패키지 관리자

[5:56 - 6:41] 놓치기 쉬운 점이 하나 있습니다: Linux에는 여러 패키지 관리자를 설치할 수 있으며, apt는 자신이 관리하는 패키지만 알 수 있습니다. Flatpak은 그런 대안 중 하나입니다. 이는 애플리케이션을 자체 종속성과 함께 패키징하여 시스템의 나머지 부분과 격리하는 샌드박스 기반 시스템입니다.

Flatpak을 통해 소프트웨어를 설치한 경우, apt upgrade을 실행해도 해당 애플리케이션에 영향을 주지 않습니다. 개별적으로 업데이트해야 합니다:

flatpak list
flatpak update

flatpak list
flatpak update

flatpak list 명령은 Flatpak을 통해 설치된 모든 것을 보여주고, flatpak update은 해당 패키지를 최신 버전으로 업데이트합니다. 통합 개발 환경(IDE), 데이터베이스 도구, 또는 커뮤니케이션 앱을 통해 설치한 경우, 정기적으로 확인하는 것이 좋은 관행입니다.

리눅스에서는 소프트웨어가 apt, Flatpak, Snap 또는 수동 설치를 통해 제공될 수 있습니다. 각각은 자체 업데이트 메커니즘을 가지고 있으므로 철저한 업데이트 루틴은 모두를 고려해야 합니다. 모든 애플리케이션이 자체 업데이트 프로그램을 포함하고 있다고 익숙해져 있다면, 여기서 중요한 차이점은 어떤 패키지 관리자가 어떤 소프트웨어를 소유하고 있는지를 알고 각 패키지에 맞는 업데이트 명령어를 실행해야 한다는 것입니다.

어떤 메소드를 사용해야 하나요?

[4:19 - 5:32] 팀의 의견은 두 가지 접근법 모두 유효하며, 올바른 선택은 여러분의 워크플로우에 따라 다르다는 것입니다. 시각적 인터페이스가 더 편하다면, 업데이트 관리자가 포인트 앤 클릭 인터페이스를 통해 apt와 동일한 업데이트를 처리합니다. 명령을 외우거나 잘못된 순서로 실행되는 것을 걱정할 필요가 없습니다. 그렇긴 하지만, 명령줄에 익숙해져야 하는 좋은 이유가 있습니다: 자동화. 크론을 사용하여 전체 업데이트 순서를 실행하는 간단한 셸 스크립트를 작성하고 이를 주간 실행으로 예약할 수 있습니다. 시스템을 유지 관리하는 데 있어 생각할 필요 없이 최신 상태로 유지해 주는 세 줄의 스크립트는 시간이 지남에 따라 누적되는 작은 투자입니다.

자동화를 넘어서, 명령줄은 상황에 따라 특정 업그레이드 수준을 선택적으로 적용하거나 출력을 분석을 위해 다른 도구로 파이프할 수 있게 해줍니다. 이 옵션들은 GUI를 통해 사용할 수 없습니다.

설치된 패키지 감사

[7:16 - 7:54] 업데이트 과정의 유용한 부수 효과도 있습니다: 업데이트 목록을 검토하는 것이 시스템에 설치된 항목을 감사하는 역할을 합니다. 새로운 업데이트 대기 중인 패키지를 볼 때, 아직도 필요한 것인지 자문해 보는 것이 좋습니다.

Edge를 주로 사용하는 경우에도 업데이트 목록에서 Firefox를 보거나 그 반대의 경우도 있을 수 있습니다. 웹 애플리케이션의 크로스 브라우저 테스트를 위해 두 개의 브라우저를 설치해 두는 것은 합리적이지만, 더 넓은 원칙은 업데이트 목록이 개발 환경의 전체 발자국을 노출한다는 것입니다. 이전 프로젝트에서 남은 오래된 도구들, 종속성으로 포함되었으나 정리되지 않은 개발 라이브러리, 여섯 달 전에 설치해놓고 잊어버린 패키지들: 이 모든 것이 여기 나타납니다.

그런 관리가 기대 이상의 보답을 가져옵니다. 깨끗한 개발 환경은 팀원 간에 복제하기 쉽고, 컨테이너화하기 더 간단하며, "내 컴퓨터에서는 작동함"과 같은 버그를 발생시킬 가능성이 적습니다. 만약 Linux 박스에 Dockerfile에 포함되지 않은 패키지가 설치되어 있다면, 이는 프로덕션 환경에서 존재하지 않을 것에 의존하고 있을 수 있습니다. C# 애플리케이션을 Docker에 배포하는 것에 익숙해지면 로컬 패키지와 생산 환경 간의 연결이 훨씬 더 명확해집니다.

결론

[7:54 - 8:25] Tim이 시연한 바와 같이, 업데이트 매니저를 통해서든 명령줄을 통해서든 전체 과정은 최대 몇 분 정도 소요되며, OS 수준에서 기술 부채가 누적되는 것을 방지합니다. 일주일에 한 번씩 하는 습관으로 만들면 가끔의 번거로운 작업이 아닌 개발 도구, 런타임 종속성 및 시스템 라이브러리를 정렬할 수 있습니다. 이러한 정렬은 크로스 플랫폼 C# 개발을 좌절감 없는 신뢰할 수 있는 과정으로 만들어줍니다.

전체 단계별 설명을 보려면 Tim Corey의 비디오를 그의 YouTube 채널에서 확인하세요.