제1장. 서버와 Ubuntu Server의 이해

장의 목표

이 장을 학습한 뒤에는 다음을 설명할 수 있어야 한다.

서버가 단순한 "고성능 컴퓨터"가 아니라 서비스를 제공하는 시스템이라는 점
Ubuntu Server가 어떤 구조 위에서 동작하며, 관리자는 어떤 계층을 다루는지
서버 관리자에게 필요한 핵심 책임이 무엇인지
서버를 처음 접속했을 때 무엇을 먼저 확인해야 하는지
한 대의 Ubuntu Server를 시스템 관점에서 읽는 기본 방법

전제와 범위

이 장은 다음을 전제로 한다.

독자는 컴퓨터공학 학부 수준의 운영체제, 네트워크, 프로그래밍 기초를 갖추고 있다.
대상 시스템은 GUI가 없는 일반적인 Ubuntu Server 환경이다.
설명은 Ubuntu Server LTS 계열과 systemd 기반 운영을 기준으로 한다.

이 장은 아직 고급 설정이나 보안 하드닝으로 들어가지 않는다. 먼저 서버를 이해하는 관점을 세운다.

1.1 서버란 무엇인가

일상적으로 "서버"라는 단어는 두 가지 의미로 섞여 쓰인다.

물리적 또는 가상 컴퓨터 자체를 가리키는 의미
네트워크를 통해 다른 시스템에 기능이나 자원을 제공하는 소프트웨어를 가리키는 의미

운영 관점에서는 두 번째 의미가 더 중요하다.

정의 — 서버(server)는 네트워크를 통해 클라이언트에게 서비스나 자원을 제공하는 시스템 또는 프로그램이다.

예를 들어 다음은 모두 서버다.

웹 페이지를 제공하는 Nginx
데이터를 저장하고 조회하는 PostgreSQL
원격 로그인 기능을 제공하는 OpenSSH
파일을 업로드·다운로드하게 하는 파일 서버 소프트웨어

즉, 서버의 본질은 "강한 컴퓨터"가 아니라 지속적으로 요청을 받고 응답하는 역할에 있다.

많은 초보자가 서버를 단순히 "24시간 켜져 있는 PC"로 이해하는데, 이 설명은 절반만 맞다. 서버는 항상 켜져 있을 가능성이 높지만, 중요한 점은 지속적인 서비스 제공과 관리 가능성이다. 서버는 단순히 동작하는 것이 아니라, 다음 특성을 만족해야 한다.

예측 가능해야 한다.
재부팅 후에도 같은 상태로 복원되어야 한다.
오류가 발생했을 때 원인을 추적할 수 있어야 한다.
접근 권한과 보안이 통제되어야 한다.

이 네 가지는 이후 모든 장의 기준이 된다.

1.2 서버와 데스크톱의 차이

데스크톱 운영체제와 서버 운영체제는 커널 수준에서 유사할 수 있다. 그러나 실제 사용 목적과 운영 방식은 상당히 다르다.

데스크톱은 대개 한 명의 사용자가 직접 로그인하여 상호작용하는 환경이다.
서버는 다수의 클라이언트가 네트워크를 통해 간접적으로 사용하는 환경이다.

이 차이는 시스템 운영 방식에 직접적인 영향을 준다.

서버 환경의 특징

1) 상시 가동

서버는 보통 장시간 연속 실행된다. 따라서 메모리 누수, 로그 누적, 디스크 포화, 파일 디스크립터 고갈 같은 문제가 중요해진다.

2) 원격 관리

서버는 물리적으로 앞에 앉아서 조작하지 않는 경우가 많다. 관리자는 보통 SSH를 통해 원격으로 접속한다. 즉, 서버 관리는 GUI보다 CLI 중심이다.

3) 서비스 중심

데스크톱은 브라우저, 에디터, IDE 같은 "사용자 프로그램"이 중심이다. 서버는 웹 서버, DB 서버, 메시지 브로커, 배치 작업처럼 백그라운드 서비스가 중심이다.

4) 안정성과 복구성 중시

데스크톱은 불편하면 재부팅하면 되는 경우가 많다. 서버는 재부팅 자체가 서비스 중단이므로, 변경 전 검토와 복구 계획이 훨씬 중요하다.

그림 1-1. 데스크톱과 서버의 사용 모델 비교
이 그림의 핵심은 사용 경로의 차이다. 데스크톱은 사용자가 시스템과 직접 상호작용한다. 서버는 사용자가 네트워크를 통해 간접적으로 시스템과 상호작용한다.

즉, 서버 관리자에게 중요한 질문은 다음과 같다.

누가 접속하는가
어떤 포트로 접속하는가
어떤 프로세스가 요청을 처리하는가
처리 결과는 어디에 기록되는가

1.3 Ubuntu Server는 무엇을 제공하는가

Ubuntu Server는 Linux 커널 위에서 동작하는 범용 서버 운영체제 배포판이다. 운영자 관점에서 Ubuntu Server의 장점은 "사용자가 많다"가 아니라, 다음과 같은 운영 편의성과 표준성에 있다.

1) 표준적인 서비스 관리 체계

Ubuntu Server는 일반적으로 systemd를 사용한다. 즉, 서비스 시작, 종료, 재시작, 자동 시작, 로그 확인을 일관된 방식으로 처리할 수 있다.

2) 패키지 관리 체계

apt와 .deb 기반 패키지 관리는 설치, 업그레이드, 의존성 관리에 유리하다. 운영자는 필요한 소프트웨어를 저장소 기반으로 설치하고 관리할 수 있다.

3) 네트워크/클라우드 친화성

클라우드 VM, 온프레미스 서버, 가상머신 등 다양한 환경에서 쉽게 배치할 수 있다. 초기화 도구, SSH 기반 관리, 자동화 도구와의 연동도 비교적 수월하다.

4) 풍부한 문서와 사례

운영체제는 "기능"보다 "문제가 생겼을 때 추적 가능한가"가 더 중요하다. Ubuntu는 사용자층이 넓어서 대부분의 일반적인 문제에 대한 해결 사례를 찾기 쉽다.

그림 1-2. Ubuntu Server의 기본 계층 구조
이 계층 구조는 매우 중요하다. 운영 문제는 항상 특정 계층에서 발생한다.

예를 들어,

부팅 자체가 안 되면 부트로더나 커널 계층을 의심해야 한다.
서비스가 자동 시작되지 않으면 systemd 계층을 봐야 한다.
프로세스는 살아 있지만 응답이 이상하면 애플리케이션 계층을 봐야 한다.
네트워크 접속이 안 되면 서비스가 아니라 포트, 라우팅, 방화벽을 봐야 한다.

관리자는 문제를 "무조건 앱 버그"로 보거나 "무조건 OS 문제"로 보는 것이 아니라, 어느 계층의 문제인지 먼저 분리해야 한다.

1.4 서버 관리자의 역할

서버 관리자는 단순히 프로그램을 설치하는 사람이 아니다. 운영자에게는 다음 다섯 가지 책임이 있다.

1) 가용성

서비스가 가능한 한 계속 동작해야 한다. 서비스가 죽었을 때 자동 재시작되는지, 재부팅 후 다시 올라오는지, 장애 시 빠르게 복구 가능한지가 핵심이다.

2) 보안

누가 접근할 수 있는지, 어떤 권한을 가지는지, 민감한 정보가 어디에 저장되는지를 통제해야 한다. 특히 서버는 외부 네트워크에 노출될 수 있으므로, 보안은 기본값이어야 한다.

3) 성능

CPU, 메모리, 디스크, 네트워크가 어떻게 사용되는지 관찰하고, 병목을 구분할 수 있어야 한다. "느리다"는 현상은 원인이 아니라 증상이다.

4) 복구성

실수나 장애는 반드시 발생한다. 따라서 백업, 로그, 설정 파일, 복구 절차가 준비되어 있어야 한다.

5) 재현성

서버 한 대가 잘 돌아가는 것만으로는 충분하지 않다. 같은 구성을 다시 만들 수 있어야 한다. 이 점이 없으면 장애 후 복구, 확장, 인수인계가 모두 어려워진다.

그림 1-3. 서버 운영자의 핵심 책임
이 다섯 항목은 서로 분리되어 있지만 실제 운영에서는 강하게 연결되어 있다.

예를 들어,

로그를 남기지 않으면 복구성과 보안성이 동시에 떨어진다.
root로 모든 서비스를 실행하면 편해 보일 수 있으나 보안성과 재현성이 악화된다.
수작업으로 설정을 바꾸면 일시적으로는 빨라 보여도 재현성과 복구성이 떨어진다.

따라서 좋은 관리자는 "지금 당장 되게 하는 것"과 "나중에도 유지 가능한 것"을 구분한다.

1.5 서버는 어떻게 요청을 처리하는가

서버를 이해하려면, 클라이언트 요청이 시스템 내부를 어떻게 통과하는지 아는 것이 중요하다.

예를 들어 사용자가 웹 브라우저에서 어떤 주소로 접속한다고 하자. 그 요청은 대개 다음 흐름을 따른다.

클라이언트가 도메인 이름을 DNS를 통해 IP 주소로 해석한다.
해당 IP의 특정 포트로 네트워크 연결을 시도한다.
Ubuntu Server의 커널이 연결을 수신한다.
해당 포트를 listen 중인 프로세스가 요청을 받는다.
프로세스는 파일, 메모리, DB, 다른 서비스 등을 이용해 응답을 생성한다.
결과가 네트워크를 통해 클라이언트로 돌아간다.
필요하면 access log, error log, application log가 기록된다.

그림 1-4. 요청 처리의 전체 흐름
이 그림은 운영자가 반드시 체득해야 하는 기본 모델이다.

서버 장애를 볼 때도 같은 흐름을 뒤에서부터 또는 앞에서부터 추적한다.

예를 들어 "사이트 접속이 안 된다"는 상황을 보면, 운영자는 다음처럼 생각한다.

DNS가 틀렸는가
서버 IP는 맞는가
포트가 열려 있는가
프로세스가 살아 있는가
앱이 요청을 정상 처리하는가
내부 DB 연결은 되는가
오류 로그가 남았는가

즉, 운영은 결국 시스템의 데이터 흐름을 추적하는 일이다.

1.6 서버 운영은 계층을 읽는 일이다

운영자는 한 번에 모든 것을 보지 않는다. 대신 시스템을 계층별로 나누어 관찰한다.

1) 하드웨어/가상 인프라 계층

CPU, 메모리, 디스크, NIC, VM 상태 같은 물리·가상 자원 계층이다. 이 계층이 불안정하면 상위 서비스도 안정적일 수 없다.

2) 운영체제 계층

커널, 스케줄링, 메모리 관리, 파일시스템, 네트워크 스택이 여기에 해당한다.

3) 서비스 관리 계층

systemd가 대표적이다. 어떤 서비스가 언제 시작되고, 실패 시 어떻게 처리되는지가 여기서 결정된다.

4) 애플리케이션 계층

웹 서버, API 서버, DB, 배치 프로세스, 메시지 브로커 같은 실제 서비스가 여기에 있다.

5) 운영 정책 계층

권한, 로그, 백업, 모니터링, 배포 절차, 문서화, 변경 관리가 여기에 속한다.

초보자는 종종 "명령어를 많이 알면 운영을 잘한다"고 생각한다. 그러나 실제로 중요한 것은 문제를 어떤 계층에서 볼지 판단하는 능력이다.

예를 들어 CPU 사용률이 높다고 해서 반드시 앱 코드가 문제는 아니다. 로그 폭증, 무한 재시작, 잘못된 cron 작업, 비정상적인 트래픽, 커널 레벨 I/O 대기 등이 원인일 수 있다. 즉, 증상과 원인을 혼동하면 안 된다.

1.7 관리자에게 필요한 첫 번째 사고방식

서버를 처음 접했을 때는 "무엇을 바꿀까"보다 **"무엇이 있는가"**를 먼저 파악해야 한다.

관리자의 기본 동작은 다음 순서로 요약할 수 있다.

시스템 정체 확인
현재 상태 관찰
서비스 구조 파악
변경 위험도 판단
최소 변경 수행
결과 검증
기록 남기기

이 흐름은 매우 중요하다. 경험이 부족할수록 바로 설정 파일부터 열고 수정하고 싶어지지만, 운영에서 가장 위험한 행동이 바로 상태를 파악하지 않은 변경이다.

그림 1-5. 운영자의 기본 루프
이 루프는 디버깅, 성능 분석, 보안 점검, 배포, 장애 대응 모두에 적용된다.

1.8 Ubuntu Server를 처음 보면 무엇을 확인해야 하는가

실무에서 서버에 처음 접속했을 때 가장 먼저 해야 하는 일은 "상태 인벤토리"를 만드는 것이다. 즉, 이 서버가 무엇인지, 어떤 환경인지, 무엇을 하고 있는지를 빠르게 파악해야 한다.

보통 다음 항목을 먼저 확인한다.

시스템 정체

호스트 이름
OS 버전
커널 버전
시스템 부팅 후 경과 시간

현재 접속 계정

현재 사용자가 누구인지
sudo 권한이 있는지
이 계정이 root인지 일반 사용자인지

실행 중인 핵심 서비스

어떤 서비스가 활성 상태인지
어떤 서비스가 부팅 시 자동 시작되는지

네트워크 노출 상태

어떤 포트가 열려 있는지
어느 주소에 바인딩되어 있는지
외부와 통신 가능한지

자원 상태

CPU 부하
메모리 사용량
디스크 사용량

이 다섯 영역만 봐도 서버의 성격을 상당 부분 파악할 수 있다.

1.9 요약

이 장에서 기억해야 할 핵심은 다음 세 가지다.

서버는 단순한 컴퓨터가 아니라 네트워크를 통해 기능을 제공하는 시스템이다.
Ubuntu Server 관리자는 OS, 서비스, 네트워크, 보안, 복구를 하나의 시스템으로 보아야 한다.
운영의 출발점은 변경이 아니라 관찰이다.

다음 장부터는 파일시스템, 사용자, 프로세스, systemd, 네트워크, 보안, 백업 등 세부 주제로 들어간다. 그러나 그 모든 주제는 결국 이 장에서 소개한 하나의 관점, 즉 **"서버를 계층적으로 읽고 상태를 관찰한다"**는 원리 위에 올라가 있다.

실습 해설

이 절에서는 제1장의 개념을 실제 Ubuntu Server에서 어떻게 확인하는지 단계적으로 해설한다. 실습 목적은 무언가를 설치하는 것이 아니라, 서버를 읽는 기본 절차를 익히는 데 있다.

실습 1. 이 서버는 무엇인가: 시스템 정체 파악

목표 — 접속한 시스템이 어떤 Ubuntu Server인지 확인하고, 운영자가 가장 먼저 보는 기본 정보를 읽는다.

사용 명령

bash

hostnamectl
uname -a
uptime
whoami
id
cat /etc/os-release

1단계. 호스트 이름과 기본 시스템 정보 확인

bash

hostnamectl

이 명령은 다음과 같은 정보를 보여준다.

Static hostname
Operating System
Kernel
Architecture

운영 관점에서 여기서 중요한 것은 다음이다.

호스트 이름: 현재 접속한 서버가 정확히 어느 서버인지 식별하는 기준
OS 정보: Ubuntu Server 계열인지, 다른 배포판인지 확인
커널 버전: 커널 관련 기능이나 문제 분석의 기준
아키텍처: x86_64인지 arm64인지에 따라 패키지나 바이너리 선택이 달라질 수 있음

초보자는 서버 이름을 제대로 확인하지 않고 작업하다가, staging 서버가 아니라 production 서버를 수정하는 실수를 하기도 한다. 따라서 호스트 이름 확인은 형식적인 절차가 아니라 안전 절차다.

2단계. 커널과 부팅 상태 확인

bash

uname -a
uptime

uname -a는 커널 이름, 버전, 아키텍처를 보여준다. uptime은 시스템이 얼마나 오래 켜져 있었는지와 현재 load average를 보여준다.

여기서 해석 포인트는 다음과 같다.

부팅 직후라면 최근 재부팅이 있었을 가능성
장기간 uptime이면 안정적으로 동작 중일 수 있지만, 반대로 패치가 오래 안 된 상태일 수도 있음
load average가 높다고 해서 즉시 문제라고 단정할 수는 없지만, 관찰 대상임

예를 들어 uptime이 몇 분에 불과하다면 다음 질문을 던져야 한다.

방금 재부팅된 이유는 무엇인가
계획된 작업이었는가
장애 후 재기동이었는가

즉, 숫자 하나도 항상 맥락과 함께 읽어야 한다.

3단계. 현재 작업 계정 확인

bash

whoami
id

이 두 명령은 현재 사용자의 이름과 UID/GID, 그룹 정보를 보여준다.

운영 관점에서 중요한 이유는 분명하다.

현재 사용자가 root인지 일반 계정인지
sudo 가능한 그룹에 속하는지
이후 수행할 명령이 시스템 전체에 영향을 줄 수 있는지

예를 들어 root 계정으로 로그인되어 있다면, 한 번의 실수로 시스템 전체 설정을 망가뜨릴 수 있다. 반대로 일반 사용자라면 필요한 작업에 sudo가 필요한지 먼저 판단해야 한다.

4단계. 운영체제 릴리스 정보 확인

bash

cat /etc/os-release

이 파일은 OS 이름, 버전 식별자, codename 등의 기본 정보를 제공한다. 문서화나 장애 분석 보고서에 환경 정보를 남길 때 매우 자주 참조한다.

예를 들어 어떤 서비스가 특정 버전에서만 재현되는 문제를 보인다면, 이 파일 정보는 기본 증거가 된다.

실습 1의 핵심 해설

이 실습에서 익혀야 하는 것은 명령 자체보다 읽는 순서다.

어떤 서버인지 확인한다.
얼마나 안정적으로 실행 중인지 확인한다.
어떤 권한으로 작업 중인지 확인한다.
환경 정보를 기록할 수 있게 정리한다.

즉, 서버에 들어가자마자 설정을 바꾸지 않는다. 먼저 "내가 지금 어디에 들어와 있는가"를 확인한다.

실습 2. 이 서버는 무엇을 하고 있는가: 서비스와 포트 파악

목표 — 현재 시스템에서 어떤 서비스가 동작 중인지, 외부와 어떻게 연결되는지를 확인한다.

사용 명령

bash

systemctl list-units --type=service --state=running
systemctl list-unit-files --type=service
ss -lntup
ps aux --sort=-%cpu | head

1단계. 실행 중인 서비스 보기

bash

systemctl list-units --type=service --state=running

이 명령은 현재 활성 상태의 서비스 목록을 보여준다. Ubuntu Server라면 보통 다음과 같은 서비스가 보일 수 있다.

ssh.service
systemd-journald.service
cron.service
networkd 또는 관련 네트워크 서비스
웹 서버나 DB 서버가 설치되어 있다면 그 서비스들

이 목록을 통해 다음을 추정할 수 있다.

이 서버는 단순한 테스트 서버인지
웹 서버 역할을 하는지
DB 서버 역할을 하는지
배치/예약 작업이 존재하는지

중요한 점은 서비스의 이름만으로 역할을 추정하되, 추정과 확인을 구분하는 것이다. 예를 들어 nginx.service가 보인다고 해서 반드시 실제로 외부 트래픽을 받는다고 단정할 수는 없다. 다음 단계에서 포트를 확인해야 한다.

2단계. 설치된 서비스와 자동 시작 가능성 보기

bash

systemctl list-unit-files --type=service

이 명령은 서비스 유닛 파일과 enable/disable 상태를 보여준다.

운영 해석은 다음과 같다.

enabled: 부팅 시 자동 시작 대상
disabled: 수동으로 시작해야 하는 경우가 많음
static: 다른 유닛에 의해 간접적으로 사용됨

서비스가 현재는 실행 중이지만 enabled가 아니라면, 재부팅 후 자동으로 올라오지 않을 수 있다. 즉, "지금 살아 있다"와 "항상 살아 있다"는 다른 문제다.

3단계. 포트와 바인딩 상태 확인

bash

ss -lntup

이 명령은 listen 중인 TCP/UDP 소켓과 해당 프로세스를 보여준다.

여기서 봐야 할 핵심은 세 가지다.

어떤 포트가 열려 있는가
어떤 주소에 바인딩되어 있는가
어떤 프로세스가 그 포트를 점유하는가

예를 들어 다음처럼 읽는다.

127.0.0.1:5432 → PostgreSQL이 로컬 전용으로 열려 있음
0.0.0.0:22 → SSH가 모든 인터페이스에서 접속을 받음
0.0.0.0:80 → 웹 서버가 외부 요청을 받을 가능성이 높음

이 해석은 매우 중요하다. 서비스가 존재하는 것과, 외부에 노출되어 있는 것은 전혀 다른 이야기다.

4단계. 자원을 많이 쓰는 프로세스 확인

bash

ps aux --sort=-%cpu | head

이 명령은 CPU 사용률이 높은 프로세스를 위에서부터 보여준다. 이 실습의 목적은 성능 튜닝이 아니라, 현재 서버의 활동성을 감각적으로 읽는 것이다.

예를 들어 다음과 같은 질문을 던질 수 있다.

CPU를 많이 쓰는 프로세스가 서버의 본래 역할과 일치하는가
이상한 스크립트나 예상치 못한 프로세스가 있는가
백그라운드 작업이 과도하게 돌고 있는가

서버 이해는 결국 "이 시스템은 원래 무엇을 해야 하는가"와 "실제로 지금 무엇을 하고 있는가"를 비교하는 일이다.

실습 2의 핵심 해설

이 실습의 핵심은 서비스와 네트워크를 연결해서 읽는 것이다.

systemctl은 서비스 관리 관점
ss는 네트워크 노출 관점
ps는 프로세스 실행 관점

같은 서버를 세 가지 다른 관점에서 본 셈이다.

이 세 결과를 합치면 다음과 같은 문장을 만들 수 있어야 한다.

"이 서버는 SSH와 웹 서비스를 제공하고 있으며, 웹 서버는 외부에서 80 포트로 접근 가능하고, DB는 로컬에서만 열려 있다."

이 수준의 요약이 가능하면 서버를 읽기 시작한 것이다.

실습 3. 서버를 시스템으로 설명해 보기: 관찰 결과를 문장으로 정리

목표 — 앞선 실습에서 얻은 정보를 바탕으로, 접속한 Ubuntu Server를 짧은 운영 보고 형태로 요약한다.

권장 형식

- Hostname:
- OS / Kernel:
- Uptime:
- Current User:
- Main Running Services:
- Public Listening Ports:
- Local-only Ports:
- Initial Operational Notes:

예시 해설

Hostname: api-prod-01
OS / Kernel: Ubuntu Server, Linux kernel 6.x
Uptime: 18 days
Current User: admin with sudo group
Main Running Services: ssh, nginx, docker
Public Listening Ports: 22, 80, 443
Local-only Ports: 5432
Initial Operational Notes:
  - 웹 서비스를 제공하는 생산 서버로 보임
  - DB는 로컬 접근만 허용되어 상대적으로 안전
  - Docker가 설치되어 있어 일부 앱이 컨테이너로 동작할 가능성 있음
  - 장기 uptime이므로 보안 업데이트 시점 확인 필요

이 정리는 매우 단순해 보이지만, 실제 운영에서는 이 단계가 중요하다. 시스템을 이해하지 못한 상태에서 수정하는 것보다, 짧게라도 현황을 요약하고 나서 작업하는 편이 훨씬 안전하다.

장 마무리

제1장은 의도적으로 개념 위주로 구성했다. 그 이유는 명확하다. 서버 운영에서 가장 흔한 실패는 "명령어를 몰라서"가 아니라, 시스템을 구조적으로 보지 못해서 발생하기 때문이다.

이 장에서 가져가야 할 핵심 문장은 다음 하나다.

Ubuntu Server 관리자는 명령을 입력하는 사람이 아니라, 시스템의 상태와 계층을 읽고 통제하는 사람이다.

다음 장부터는 이 관점을 바탕으로 파일시스템, 사용자, 프로세스, systemd, 네트워크를 더 엄밀하게 다루면 된다.

제1장. 서버와 Ubuntu Server의 이해 ​

장의 목표 ​

전제와 범위 ​

1.1 서버란 무엇인가 ​

1.2 서버와 데스크톱의 차이 ​

서버 환경의 특징 ​

1.3 Ubuntu Server는 무엇을 제공하는가 ​

1) 표준적인 서비스 관리 체계 ​

2) 패키지 관리 체계 ​

3) 네트워크/클라우드 친화성 ​

4) 풍부한 문서와 사례 ​

1.4 서버 관리자의 역할 ​

1) 가용성 ​

2) 보안 ​

3) 성능 ​

4) 복구성 ​

5) 재현성 ​

1.5 서버는 어떻게 요청을 처리하는가 ​

1.6 서버 운영은 계층을 읽는 일이다 ​

1) 하드웨어/가상 인프라 계층 ​

2) 운영체제 계층 ​

3) 서비스 관리 계층 ​

4) 애플리케이션 계층 ​

5) 운영 정책 계층 ​

1.7 관리자에게 필요한 첫 번째 사고방식 ​

1.8 Ubuntu Server를 처음 보면 무엇을 확인해야 하는가 ​

1.9 요약 ​

실습 해설 ​

실습 1. 이 서버는 무엇인가: 시스템 정체 파악 ​

1단계. 호스트 이름과 기본 시스템 정보 확인 ​

2단계. 커널과 부팅 상태 확인 ​

3단계. 현재 작업 계정 확인 ​

4단계. 운영체제 릴리스 정보 확인 ​

실습 1의 핵심 해설 ​

실습 2. 이 서버는 무엇을 하고 있는가: 서비스와 포트 파악 ​

1단계. 실행 중인 서비스 보기 ​

2단계. 설치된 서비스와 자동 시작 가능성 보기 ​

3단계. 포트와 바인딩 상태 확인 ​

4단계. 자원을 많이 쓰는 프로세스 확인 ​

실습 2의 핵심 해설 ​

실습 3. 서버를 시스템으로 설명해 보기: 관찰 결과를 문장으로 정리 ​

장 마무리 ​

제1장. 서버와 Ubuntu Server의 이해

장의 목표

전제와 범위

1.1 서버란 무엇인가

1.2 서버와 데스크톱의 차이

서버 환경의 특징

1.3 Ubuntu Server는 무엇을 제공하는가

1) 표준적인 서비스 관리 체계

2) 패키지 관리 체계

3) 네트워크/클라우드 친화성

4) 풍부한 문서와 사례

1.4 서버 관리자의 역할

1) 가용성

2) 보안

3) 성능

4) 복구성

5) 재현성

1.5 서버는 어떻게 요청을 처리하는가

1.6 서버 운영은 계층을 읽는 일이다

1) 하드웨어/가상 인프라 계층

2) 운영체제 계층

3) 서비스 관리 계층

4) 애플리케이션 계층

5) 운영 정책 계층

1.7 관리자에게 필요한 첫 번째 사고방식

1.8 Ubuntu Server를 처음 보면 무엇을 확인해야 하는가

1.9 요약

실습 해설

실습 1. 이 서버는 무엇인가: 시스템 정체 파악

1단계. 호스트 이름과 기본 시스템 정보 확인

2단계. 커널과 부팅 상태 확인

3단계. 현재 작업 계정 확인

4단계. 운영체제 릴리스 정보 확인

실습 1의 핵심 해설

실습 2. 이 서버는 무엇을 하고 있는가: 서비스와 포트 파악

1단계. 실행 중인 서비스 보기

2단계. 설치된 서비스와 자동 시작 가능성 보기

3단계. 포트와 바인딩 상태 확인

4단계. 자원을 많이 쓰는 프로세스 확인

실습 2의 핵심 해설

실습 3. 서버를 시스템으로 설명해 보기: 관찰 결과를 문장으로 정리

장 마무리