Ubuntu 24.04 서버 운영

Baseline(기준선): 변경 전후를 비교할 수 있게 대상·시각·상태를 모은 기록입니다.

설치는 파일을 복사하는 작업이 아니라 어느 disk를 지우고 어떤 boot·network·identity 기준으로 서버를 시작할지 결정하는 변경입니다. 화면에 Install이 보인다는 이유만으로 진행하지 말고 설치 대상이 실습 VM인지, 기존 data가 있는 물리 서버인지, rollback이 가능한지부터 확인합니다.

기준선은 “설치가 끝났다”는 메모가 아닙니다. 이후 장애나 변경이 생겼을 때 비교할 수 있도록 OS release, kernel, clock, CPU·memory·disk, interface와 주소를 같은 시각에 기록한 증거 묶음입니다. 정상이라는 결론보다 무엇을 관찰했는지가 먼저입니다.

교육 사례에서 설치 직전 확인한 disk는 100GiB인데 작업서는 80GiB를 지정했습니다. VM 이름만 같다는 이유로 진행하지 않습니다. 가상 disk 추가나 잘못된 console 연결도 원인일 수 있습니다. serial과 장치 연결을 대조하고 대상이 확정될 때까지 설치를 멈춥니다.

하나의 기준선은 여러 명령의 출력으로 구성됩니다. OS release는 배포판, kernel은 현재 실행 중인 운영체제 핵심, mount는 사용 중인 filesystem을 설명합니다. 한 값이 정상이어도 다른 값의 정상 여부는 별도로 확인합니다. 같은 시각과 대상 이름으로 묶어야 다음 운영자가 비교할 수 있습니다.

왜 이런가

한 시점의 OS·장치·주소를 함께 기록해야 나중에 달라진 층을 구분할 수 있습니다. 명령 하나의 성공을 서버 전체의 정상 판정으로 확대하지 마십시오.

언제 문제가 되는가

작업서와 실제 disk 용량이 다르면 다른 VM이나 추가 disk를 보고 있을 수 있습니다. 설치 화면에서 진행하기 전에 대상 identity부터 대조하십시오.

초보자가 자주 하는 오해

물리 서버나 기존 VM에서 대상 disk를 잘못 고르면 data를 복구하지 못할 수 있습니다. asset ID, disk serial, 용량과 연결 위치가 작업 승인서와 다르면 즉시 중단하고 선임에게 escalation하십시오.

직접 확인하는 방법

아래 읽기 전용 명령의 결과를 한 기록에 모으고, 작업서의 대상·용량과 실제 disk·mount·route를 대조하십시오. 명령 실패도 기록에 남기십시오.

Working directory(현재 작업 디렉터리): 상대 경로를 해석할 때 기준이 되는 현재 위치입니다.

prompt는 운영체제의 출력과 사용자의 입력 경계를 알려 주는 표시입니다. $나 #를 명령의 일부로 복사하지 않습니다. 특히 # prompt는 대개 root 권한을 뜻하므로 같은 명령도 영향 범위가 달라집니다.

절대 경로는 /에서 시작하고 상대 경로는 현재 작업 directory를 기준으로 해석됩니다. cd가 성공했다는 사실만으로 의도한 위치라고 단정하지 말고 pwd와 ls -la로 현재 위치와 숨김 항목을 확인합니다.

교육 사례에서 /srv/lab에 있다고 생각하고 ./data를 조회했지만 실제 pwd는 /home/learner였습니다. 같은 상대 경로도 시작 위치가 다르면 다른 파일을 가리킵니다. 먼저 pwd와 ls로 대상을 확인하고 cd 뒤에 다시 확인합니다. 특히 삭제·덮어쓰기 명령은 절대 경로와 소유자를 대조하기 전 실행하지 않습니다.

셸은 입력 문자열을 명령 이름과 인자로 나누어 실행합니다. 따옴표는 공백이나 특수 문자가 포함된 값을 하나의 인자로 전달할 때 필요합니다. 파이프는 앞 명령의 출력을 뒤 명령의 입력으로 연결하며 원본 파일을 직접 바꾸는 뜻은 아닙니다. 반면 리다이렉션 >는 대상 파일을 덮어쓸 수 있으므로 읽기 명령과 구분합니다.

왜 이런가

셸은 입력 문자열을 명령 이름과 인자로 나누어 실행합니다. 따옴표는 공백이나 특수 문자가 포함된 값을 하나의 인자로 전달할 때 필요합니다. 파이프는 앞 명령의 출력을 뒤 명령의 입력으로 연결하며 원본 파일을 직접 바꾸는 뜻은 아닙니다. 반면 리다이렉션 >는 대상 파일을 덮어쓸 수 있으므로 읽기 명령과 구분합니다.

언제 문제가 되는가

교육 사례에서 /srv/lab에 있다고 생각하고 ./data를 조회했지만 실제 pwd는 /home/learner였습니다. 같은 상대 경로도 시작 위치가 다르면 다른 파일을 가리킵니다. 먼저 pwd와 ls로 대상을 확인하고 cd 뒤에 다시 확인합니다. 특히 삭제·덮어쓰기 명령은 절대 경로와 소유자를 대조하기 전 실행하지 않습니다.

초보자가 자주 하는 오해

인터넷에서 찾은 명령을 `sudo`와 함께 바로 실행하지 않습니다. 먼저 `type`, `--help`, `man`과 package 출처로 명령의 소유자·option·변경 범위를 확인하십시오.

직접 확인하는 방법

현재 위치를 확인하고 안전하게 이동한 뒤 도움말과 종료 상태를 판독한다.

Permission(접근 권한): owner·group·other별 읽기·쓰기·실행 허용 범위를 정하는 규칙입니다.

Linux는 화면에 보이는 사용자 이름만으로 접근을 결정하지 않습니다. process의 UID와 GID, 대상 파일의 소유자·group, rwx bit와 추가 정책을 함께 평가합니다. chmod 777은 문제를 해결하는 만능 명령이 아니라 누구나 읽고 쓰고 실행할 수 있게 범위를 넓히는 위험한 변경입니다.

서비스 계정은 사람이 로그인하는 개인 계정과 목적이 다릅니다. 필요한 directory에만 접근하게 하고 shell login과 불필요한 home directory를 제한하면 credential 오용과 사고의 blast radius를 줄일 수 있습니다.

교육 사례에서 파일 읽기 권한은 있지만 상위 디렉터리의 통과 권한이 없어 접근이 거부되었습니다. 파일 하나의 mode만 바꾸면 해결되지 않을 수 있습니다. 경로의 각 디렉터리와 실제 process의 UID·group을 확인합니다. 모든 대상에 777을 주는 방법은 원인을 설명하지 못하고 무관한 쓰기까지 열어 버립니다.

디렉터리의 읽기와 실행 권한은 파일과 의미가 다릅니다. 읽기는 항목 이름 목록을, 실행은 경로 탐색을 허용합니다. group에 사용자를 추가한 뒤에도 기존 로그인 session이 새 group을 반영하지 않을 수 있습니다. id로 현재 session의 group을 확인하고 새 session에서 필요한 행동만 허용되는지 시험합니다.

왜 이런가

디렉터리의 읽기와 실행 권한은 파일과 의미가 다릅니다. 읽기는 항목 이름 목록을, 실행은 경로 탐색을 허용합니다. group에 사용자를 추가한 뒤에도 기존 로그인 session이 새 group을 반영하지 않을 수 있습니다. id로 현재 session의 group을 확인하고 새 session에서 필요한 행동만 허용되는지 시험합니다.

언제 문제가 되는가

교육 사례에서 파일 읽기 권한은 있지만 상위 디렉터리의 통과 권한이 없어 접근이 거부되었습니다. 파일 하나의 mode만 바꾸면 해결되지 않을 수 있습니다. 경로의 각 디렉터리와 실제 process의 UID·group을 확인합니다. 모든 대상에 777을 주는 방법은 원인을 설명하지 못하고 무관한 쓰기까지 열어 버립니다.

초보자가 자주 하는 오해

권한 오류를 없애려고 전체 경로에 777을 부여하지 않습니다. 실제 사용자·group과 상위 디렉터리의 통과 권한을 확인합니다.

직접 확인하는 방법

실습용 서비스 계정과 group directory를 만들고 허용·거부 접근을 모두 검증한다.

Service(서비스 process 관리 단위): systemd가 시작·종료·재시작과 의존성을 관리하는 실행 단위입니다.

package가 설치되었다는 사실과 service가 실행 중이라는 사실은 다릅니다. enable은 다음 boot의 시작 관계를 만들고 start는 현재 session에서 process를 시작합니다. 둘 중 하나만 확인하면 재부팅 뒤 또는 현재 요청 처리에서 장애가 날 수 있습니다.

변경 작업은 “명령 성공”으로 끝나지 않습니다. 변경 전 version과 상태, 적용한 package와 configuration, 현재 상태, 대표 기능, log, 재부팅 또는 restart 이후 상태, rollback 위치를 한 묶음으로 남깁니다.

교육 사례에서 package는 설치되었지만 service가 설정 오류로 시작하지 못했습니다. 설치 성공과 실행 성공은 다른 검사입니다. systemctl status와 journal에서 최초 오류를 확인한 뒤 설정 검사 기능을 사용합니다. 설정이 맞아도 listen 주소가 localhost에만 묶여 있으면 외부 요청 가능 여부는 별도로 확인해야 합니다.

enable은 다음 부팅의 시작 연결을 설정하고 start는 지금 실행을 요청합니다. active 상태는 관리자가 보는 process 상태이며 API 응답의 의미까지 보장하지 않습니다. restart는 진행 중인 요청에 영향을 줄 수 있으므로 변경 창과 복구 방법을 준비합니다. reload 지원 여부도 service마다 다르므로 사용 전에 해당 unit과 프로그램 문서를 확인합니다.

왜 이런가

enable은 다음 부팅의 시작 연결을 설정하고 start는 지금 실행을 요청합니다. active 상태는 관리자가 보는 process 상태이며 API 응답의 의미까지 보장하지 않습니다. restart는 진행 중인 요청에 영향을 줄 수 있으므로 변경 창과 복구 방법을 준비합니다. reload 지원 여부도 service마다 다르므로 사용 전에 해당 unit과 프로그램 문서를 확인합니다.

언제 문제가 되는가

교육 사례에서 package는 설치되었지만 service가 설정 오류로 시작하지 못했습니다. 설치 성공과 실행 성공은 다른 검사입니다. systemctl status와 journal에서 최초 오류를 확인한 뒤 설정 검사 기능을 사용합니다. 설정이 맞아도 listen 주소가 localhost에만 묶여 있으면 외부 요청 가능 여부는 별도로 확인해야 합니다.

초보자가 자주 하는 오해

active 표시는 API의 정상 응답을 보장하지 않습니다. listen 주소·port와 대표 기능을 따로 확인합니다.

직접 확인하는 방법

실습 service를 설치하고 enable·start·log·재부팅 경계를 확인한다.

Mount point(마운트 지점): filesystem을 현재 디렉터리 tree의 특정 경로에 연결한 위치입니다.

“서버에 접속되지 않는다”는 하나의 원인이 아닙니다. interface link, IP address, route, DNS, remote port와 application 상태는 서로 다른 층입니다. 이름 해석이 실패했는데 firewall을 먼저 바꾸면 증거를 잃고 새로운 장애를 만들 수 있습니다.

storage도 disk가 보이는 것, partition과 filesystem이 있는 것, mount된 것, application이 쓸 수 있는 것이 각각 다릅니다. /dev/sdb 같은 이름은 연결 순서에 따라 바뀔 수 있으므로 영구 mount에는 UUID 같은 안정적인 identity를 사용합니다.

원인까지 확인된 교육 사례에서는 /data의 용량 부족 신고 뒤 작업서·이전 기준선·mount 설정을 대조해 원격 volume의 mount가 풀린 것을 확인했습니다. 아래 실습은 그 결론을 모르는 최초 진단 단계에서 시작합니다. 디렉터리 이름이 같아도 실제 저장 장치는 달라질 수 있습니다. findmnt로 대상 경로의 source를 확인한 뒤 df와 du의 범위를 맞춥니다. 원인을 확인하기 전 파일을 삭제하면 다른 filesystem의 데이터를 지울 위험이 있습니다.

network 진단도 이름·주소·route·port를 한 덩어리로 보지 않습니다. 이름 해석 성공은 연결 성공이 아니며 ping 성공은 application port의 응답을 보장하지 않습니다. 각 조회는 배제할 가설을 하나씩 정해 수행합니다. 결과가 서로 어긋나면 먼저 대상과 시각이 같은지 확인하고 설정 변경은 그 다음에 검토합니다.

왜 이런가

경로 이름은 저장 장치를 보장하지 않고 DNS 응답은 port 연결을 보장하지 않습니다. 실패한 기능에 가장 가까운 관찰값부터 앞뒤 층을 대조하십시오.

언제 문제가 되는가

별도 volume이 빠진 /data에 쓰면 root filesystem을 채울 수 있습니다. 파일 삭제보다 먼저 해당 경로가 실제로 어느 mount에 속하는지 확인하십시오.

초보자가 자주 하는 오해

원격 SSH session에서 `netplan apply`를 바로 실행하면 접속을 잃을 수 있습니다. 원격 network 변경은 console 접근과 rollback 계획을 확보한 뒤 `netplan try`처럼 시간 제한 복구가 가능한 절차를 우선합니다. filesystem 생성 명령은 대상 disk의 기존 data를 파괴할 수 있으므로 이 단원의 자동 실습에서는 실행하지 않습니다.

직접 확인하는 방법

읽기 전용 증거부터 수집해 network 또는 storage 장애 범위를 좁히고 안전하게 복구한다.