패키지 설치와 버전 기록

왜 설치보다 목록이 먼저일까요?

패키지 설치는 파일 몇 개를 내려받는 작업으로 끝나지 않습니다. 실행 파일과 라이브러리, 의존 관계가 바뀌고 이후 재현할 환경도 달라집니다. 작은 운영 실습실에 필요한 것은 Python 3와 HTTP 응답을 조회할 curl입니다. 기존 구성부터 읽으면 이미 있는 도구를 다시 설치하거나 다른 저장소의 버전을 섞는 일을 줄일 수 있습니다. 오늘의 완료 기준은 설치 성공 문구가 아니라 다른 담당자가 출처·버전·실행 경로를 같은 순서로 확인할 수 있는 기록입니다.

환경과 증거의 범위

이 모듈의 OS 명령은 앞에서 준비한 systemd Linux VM에서 실행합니다. 패키지 레슨은 Debian/Ubuntu의 apt와 dpkg로 범위를 좁힙니다. 다른 배포판에서는 해당 관리자의 공식 절차를 확인하며 apt를 억지로 설치하지 않습니다. Python 기능 테스트는 macOS에서도 실행할 수 있지만 계정 전환과 /proc 관찰은 Linux 검증을 대체하지 않습니다. ZIP을 풀고 그 폴더에서 bash check.sh를 실행하며 starter의 TODO를 구현하고 테스트 파일은 유지합니다. 관리자 준비와 일반 사용자 관측을 구분해 기록합니다.

배포판·커널·아키텍처

cat /etc/os-release는 사용자 공간 배포판 식별 자료이고 uname -m은 기계 아키텍처 관찰입니다. uname -r은 실행 중인 커널 릴리스를 알려 줍니다. 셋은 답하는 질문이 다릅니다. Linux라는 한 단어로 Ubuntu 버전을 확정할 수 없고 설치된 커널 패키지가 바뀌어도 현재 부팅 커널이 바로 바뀌지는 않습니다. 이 실습은 기본 저장소에서 도구를 받으므로 인터넷에서 찾은 임의의 바이너리를 실행할 이유가 없습니다. 아키텍처 불일치가 의심되면 설치 파일과 실행 환경을 대조합니다.

목록 갱신과 실제 설치

sudo apt-get update는 저장소의 패키지 목록을 갱신합니다. 이미 설치된 프로그램을 모두 업그레이드하는 명령이 아닙니다. apt-get -s install python3 curl은 예정된 설치·변경을 모의 실행합니다. 의존 패키지와 제거 예정 항목을 읽고 이 실습에 불필요한 제거가 있으면 진행을 멈춰 원인을 확인합니다. 승인된 실습 VM에서 sudo apt-get install python3 curl을 실행하고 관리자 작업의 목적을 기록합니다. 매 레슨에서 전체 업그레이드를 습관처럼 실행하면 변화의 원인을 좁히기 어렵습니다.

패키지 버전과 프로그램 버전

dpkg-query가 알려 주는 설치 버전에는 배포판의 수정 번호가 포함될 수 있습니다. python3 --version은 지금 선택된 인터프리터가 보고하는 버전입니다. 두 문자열은 역할이 달라 완전히 같아야 한다고 검사하지 않습니다. command -v python3가 개인 홈의 실행 파일을 가리킨다면 OS 패키지를 설치했어도 앱은 다른 Python을 쓰는 상황입니다. 실행 경로와 패키지 소유 관계를 대조하고 앱 실행에 쓸 인터프리터를 정합니다. Python 라이브러리와 OS 패키지를 같은 목록으로 취급하지 않습니다.

출처를 기록하는 이유

apt-cache policy python3 curl은 설치 버전과 후보 버전, 저장소 우선순위 정보를 보여 줍니다. 설치됨과 후보가 다르다고 즉시 업데이트하지 않고 현재 앱 요구를 확인합니다. 출처 기록에는 저장소 호스트와 배포판 suite를 포함하되 인증 정보가 들어간 URL은 제출하지 않습니다. 자동 검사는 Installed 필드와 기록 존재를 검사할 뿐 저장소 신뢰성 자체를 인증하지 않습니다. VM의 기본 저장소와 실제 policy 결과가 일치하는지는 사람이 읽어 판단해야 합니다.

관리자 권한을 좁혀 씁니다

저장소 목록 갱신과 시스템 설치는 관리자 영역입니다. 버전 조회·경로 확인·내 evidence 폴더 쓰기는 일반 사용자 영역입니다. curl 실행까지 sudo로 올리면 서비스가 할 수 있는 작업과 관리자가 할 수 있는 작업을 섞습니다. 설치 오류를 해결하려고 bcweb에 sudo 그룹을 추가하지 않습니다. 이전 모듈의 최소 권한 표를 유지하며 관리자 콘솔에서 필요한 설치만 수행합니다. 패키지 기록에는 실행한 관리자 명령과 변경 이유를 함께 남깁니다.

오류를 단계별로 읽습니다

Unable to locate package가 보이면 이름 철자·배포판·목록 갱신 성공 여부를 먼저 읽습니다. 저장소 연결 실패와 패키지가 없는 경우를 혼동하지 않습니다. lock 파일을 열 수 없다는 오류는 관리자 자격 부족 또는 다른 패키지 작업 중이라는 가능성을 나눠 봅니다. 잠금 파일을 삭제하거나 다른 설치 프로세스를 중단해 우회하지 않습니다. 운영 실습실의 다른 작업이 끝난 뒤 재시도합니다. 명령을 찾지 못한다면 설치 목록과 PATH를 비교하고 그 결과를 오류 기록에 남깁니다.

재현 기록을 완성합니다

evidence에는 os.txt, arch.txt, python-path.txt, python-version.txt, curl-version.txt, packages.txt, origin.txt, decision.md를 남깁니다. 생성 시각은 관측 시점을 설명하며 버전을 임의의 정답 숫자로 고정하지 않습니다. decision에는 필요한 표준 라이브러리 import가 성공했는지와 실제 경로가 의도한 패키지인지 적습니다. Python 표준 라이브러리 웹 앱이므로 pip 패키지를 추가할 필요는 없습니다. 테스트 통과와 설치 기록의 사실성을 별도로 확인합니다.

인계할 판단

동료가 같은 VM을 받았을 때 어떤 명령을 어떤 계정으로 실행해야 하는지 알 수 있어야 합니다. 설치 로그가 길다고 좋은 증거는 아닙니다. 변경된 패키지와 이유, 현재 실행 경로, 실패했던 단계와 해결 근거를 간결하게 묶습니다. 임의의 저장소 추가나 인증 해제 옵션을 해결책으로 적지 않습니다. 패키지 설치가 끝났다는 사실은 앱이 실행되고 데이터가 읽힌다는 보장이 아니므로 다음 레슨에서 HTTP 응답까지 이어 확인합니다.

명령·API 의미의 기준은 공식 문서에서 확인합니다. 상세 원리는 더 읽기의 서재 장으로 연결합니다.

다음 단계에서 서비스 관리자가 앱을 실행할 때도 선택한 인터프리터 경로가 필요합니다. 패키지가 설치되었다는 증거와 실행 프로세스가 그 인터프리터를 사용했다는 증거를 구분하며, 서비스 상태의 정상 표시만으로 버전과 응답 일치를 확정하지 않습니다.