왜 Docker 컨테이너부터 확인해야 할까?

 

 

※ 이 글은 운영자가 직접 Intel N100 홈서버에서 Debian과 Docker 기반 서비스를 운영하며 서버 상태를 점검하고 기록한 경험을 바탕으로 작성했습니다. 글의 문장 정리와 구성에는 AI 도구의 도움을 약간 받았지만, 최종 내용은 운영자가 직접 검토하고 확인했습니다.

왜 Docker 컨테이너부터 확인해야 할까?

도입

지난주에는 홈서버의 업타임과 CPU, 메모리, 디스크를 차례대로 살펴보며 서버 자체의 건강 상태를 점검했습니다.

하지만 서버가 정상적으로 켜져 있다고 해서 그 위에서 운영하는 모든 서비스까지 정상이라는 뜻은 아닙니다.

Debian에는 문제없이 접속되는데 WordPress가 열리지 않거나, Jellyfin 화면이 나타나지 않거나, n8n 자동화가 멈춰 있는 상황도 생길 수 있습니다.

처음 이런 일을 겪으면 서버 전체에 문제가 생겼다고 생각하기 쉽습니다.

그러나 Docker 기반 홈서버에서는 서버보다 먼저 해당 서비스를 실행하는 컨테이너가 살아 있는지 확인하는 편이 문제의 범위를 빠르게 좁히는 데 도움이 됩니다.

이번 글에서는 Docker 서비스 점검을 시작할 때 왜 컨테이너 상태부터 확인해야 하는지 운영자의 시선으로 정리해 보겠습니다.

서버가 켜져 있는 것과 그 안의 Docker 서비스가 정상적으로 동작하는 것은 서로 다른 문제입니다.

서비스 장애가 발생하면 docker ps로 컨테이너 실행 여부를 먼저 확인하고, 필요하면 docker ps -a와 로그를 확인하는 점검 흐름을 정리한 인포그래픽.

※ 다이어그램은 실제 Intel N100 Debian 홈서버의 Docker 서비스 점검 흐름을 바탕으로 AI 도구를 활용해 제작하며, 최종 구성과 내용은 운영자가 직접 검수합니다.
출처: 디지털 장난감

본문

① 서버와 서비스는 같은 상태가 아니다

홈서버를 자동차에 비유하면 이해하기 쉽습니다.

자동차의 시동이 정상적으로 걸려 있어도 내비게이션이나 에어컨 같은 개별 기능은 작동하지 않을 수 있습니다.

홈서버도 비슷합니다.

Debian 운영체제와 네트워크가 정상이어도 Docker 안에서 실행되는 WordPress, Jellyfin, n8n 같은 서비스는 각각 멈출 수 있습니다.

따라서 서버에 접속할 수 있다는 사실만으로 서비스까지 정상이라고 판단해서는 안 됩니다.

서버 점검은 기반이 정상인지 확인하는 과정이고, 컨테이너 점검은 실제 서비스가 실행되고 있는지 확인하는 과정입니다.

② Docker 컨테이너는 서비스의 실행 단위다

Docker 컨테이너는 애플리케이션과 실행에 필요한 환경을 묶어 동작시키는 격리된 실행 공간입니다.

Linux 환경에서는 호스트 운영체제의 커널을 공유하지만, 각 컨테이너의 프로세스와 파일 시스템, 네트워크 설정 등을 분리하여 관리할 수 있습니다.

예를 들어 하나의 홈서버에서 다음과 같이 여러 컨테이너를 운영할 수 있습니다.

• WordPress 웹서비스 컨테이너
• MariaDB 데이터베이스 컨테이너
• Jellyfin 미디어 서버 컨테이너
• n8n 자동화 컨테이너

이렇게 서비스를 분리하면 특정 컨테이너를 재시작하거나 업데이트할 때 다른 서비스에 미치는 영향을 줄일 수 있습니다.

반대로 특정 컨테이너가 종료되면 문제가 발생한 컨테이너와 연결된 서비스만 영향을 받는 경우도 많습니다.

③ 문제를 만나면 먼저 실행 여부부터 확인한다

웹페이지가 열리지 않는다고 해서 처음부터 설정 파일이나 방화벽, 공유기, 저장 장치까지 모두 확인하면 점검 범위가 너무 넓어집니다.

먼저 컨테이너가 실행 중인지 확인하면 가장 기본적인 가능성을 빠르게 구분할 수 있습니다.

서비스 접속 문제 발견

↓

Docker 컨테이너 실행 여부 확인

↓

실행 중이면 포트·로그·서비스 응답 확인

↓

종료 상태이면 종료 원인과 재시작 여부 확인

컨테이너가 보이지 않는다면 이미 종료되었거나 아직 시작되지 않았을 가능성을 생각할 수 있습니다.

컨테이너가 실행 중이라면 다음 단계에서 포트 연결, 애플리케이션 로그, 데이터베이스 연결 같은 항목으로 점검 범위를 좁힐 수 있습니다.

④ 가장 기본적인 확인 명령은 docker ps다

현재 실행 중인 컨테이너는 다음 명령으로 확인할 수 있습니다.

docker ps

docker ps는 현재 실행 중인 컨테이너만 표시합니다.

실행되어야 할 서비스가 목록에 없다면 중지된 컨테이너까지 확인할 수 있는 다음 명령을 사용합니다.

docker ps -a

이번 글에서는 두 명령의 역할만 기억해 두면 충분합니다.

docker ps는 현재 살아 있는 컨테이너를 보고, docker ps -a는 종료된 컨테이너를 포함한 전체 목록을 확인합니다.

목록에 표시되는 NAME, STATUS, PORTS, IMAGE 같은 항목은 이번 주 후반 포스팅에서 하나씩 자세히 살펴보겠습니다.

⑤ 컨테이너가 실행 중이어도 서비스는 실패할 수 있다

컨테이너가 Up 상태로 보인다고 해서 서비스가 반드시 정상이라고 단정할 수는 없습니다.

컨테이너 내부의 애플리케이션이 응답하지 않거나, 데이터베이스 연결이 끊겼거나, 포트 설정이 잘못되었을 수도 있습니다.

따라서 컨테이너 확인은 문제 해결의 끝이 아니라 첫 번째 분기점입니다.

실행 상태를 확인한 뒤에는 실제 서비스 접속 여부와 로그, 포트 연결 상태를 차례대로 살펴보아야 합니다.

운영노트

홈서버를 처음 운영할 때는 웹서비스가 열리지 않으면 Debian이나 네트워크부터 의심하곤 했습니다.

하지만 점검 범위를 넓게 잡으면 원인을 찾기 전에 여러 설정을 건드리게 되고, 오히려 처음 상태를 기억하기 어려워질 수 있었습니다.

그래서 지금은 먼저 해당 서비스를 담당하는 컨테이너가 실행 중인지 확인하고, 그 결과에 따라 다음 점검 방향을 정하려고 합니다.

단순한 순서지만 서비스 장애를 서버 전체 문제와 구분하는 데 도움이 되었습니다.

문제가 생기면 많은 항목을 한꺼번에 확인하기보다, 서비스가 실행되는 가장 가까운 지점부터 확인하는 것이 먼저였습니다.

에디터의 해석노트

Docker 점검에서 중요한 것은 명령어를 많이 외우는 일이 아닙니다.

서버와 컨테이너, 실제 서비스의 상태를 서로 구분하여 바라보는 습관이 먼저입니다.

서버가 정상이라면 컨테이너를 확인하고, 컨테이너가 실행 중이라면 서비스 응답과 로그를 확인합니다.

컨테이너 상태는 장애의 원인을 바로 확정하는 답이 아니라, 다음에 어디를 확인할지 알려주는 출발점입니다.

이 순서를 반복하면 문제를 만났을 때 불필요하게 서버 전체를 다시 설정하는 일을 줄일 수 있습니다.

참고 링크 (References)

1. Docker Docs : What is a container?
2. Docker CLI Reference : docker container ls
3. Docker Docs : Running containers
4. Docker Docs : Start containers automatically

트러블슈팅

문제 1. docker ps에 원하는 컨테이너가 보이지 않는다

docker ps는 현재 실행 중인 컨테이너만 보여줍니다.

종료된 컨테이너까지 확인하려면 다음 명령을 사용합니다.

docker ps -a

문제 2. Docker 명령을 실행할 권한이 없다고 나온다

사용자 권한 설정에 따라 permission denied 메시지가 나타날 수 있습니다.

현재 환경에서 Docker를 어떤 계정으로 운영하도록 설정했는지 먼저 확인하고, 임의로 권한을 변경하기 전에 기존 운영 방식을 점검합니다.

문제 3. 컨테이너는 Up인데 웹페이지가 열리지 않는다

컨테이너 실행 여부만으로 서비스 정상 상태를 확정할 수는 없습니다.

포트 매핑, 애플리케이션 로그, 데이터베이스 연결, 리버스 프록시 설정과 실제 서비스 응답을 추가로 확인합니다.

문제 4. 컨테이너가 계속 재시작한다

Restarting 상태가 반복된다면 애플리케이션 오류나 설정값, 볼륨 권한, 의존 서비스 연결 실패 등을 확인해야 합니다.

원인을 모른 채 재시작만 반복하기보다 로그를 먼저 확인하는 편이 안전합니다.

문제 5. 여러 컨테이너 중 무엇이 해당 서비스인지 모르겠다

컨테이너의 NAME과 IMAGE를 함께 확인합니다.

Docker Compose를 사용한다면 프로젝트의 compose 파일과 서비스 이름도 함께 비교합니다.

문제 상황	먼저 확인할 방향
목록에 컨테이너가 없음	docker ps -a로 종료 상태 포함 확인
Docker 명령 권한 오류	현재 사용자와 Docker 운영 권한 확인
Up 상태지만 접속 불가	포트·로그·서비스 응답 확인
재시작 상태 반복	로그와 설정, 의존 서비스 확인
서비스 컨테이너 구분 어려움	NAME·IMAGE·Compose 서비스명 비교

핵심 체크포인트 10

1. 서버가 켜져 있어도 Docker 서비스는 별도로 중단될 수 있다.
2. 서버 상태와 컨테이너 상태, 실제 서비스 응답은 서로 구분해서 확인한다.
3. Docker 컨테이너는 애플리케이션을 실행하는 격리된 단위다.
4. 특정 컨테이너가 멈추면 해당 컨테이너와 연결된 서비스만 영향을 받는 경우가 많다.
5. 서비스 장애가 발생하면 먼저 담당 컨테이너의 실행 여부를 확인한다.
6. docker ps는 현재 실행 중인 컨테이너를 표시한다.
7. docker ps -a는 종료된 컨테이너를 포함한 전체 목록을 표시한다.
8. 컨테이너가 Up 상태여도 실제 애플리케이션은 정상적으로 응답하지 않을 수 있다.
9. 컨테이너 확인은 문제 해결의 결론이 아니라 다음 점검 방향을 정하는 출발점이다.
10. 실행 상태를 확인한 뒤 포트, 로그, 연결된 서비스와 실제 응답을 차례대로 살펴본다.

마무리

이번 글에서는 Docker 기반 홈서버에서 서비스 문제가 발생했을 때 왜 컨테이너부터 확인해야 하는지 살펴보았습니다.

서버가 정상적으로 실행되는 것과 WordPress, Jellyfin, n8n 같은 개별 서비스가 정상적으로 동작하는 것은 서로 다른 문제입니다.

따라서 서비스가 열리지 않을 때는 처음부터 서버 전체를 의심하기보다 해당 서비스를 담당하는 컨테이너가 실제로 실행 중인지 먼저 확인하는 것이 좋습니다.

docker ps로 실행 중인 목록을 확인하고, 목록에 없다면 docker ps -a로 종료 상태까지 살펴봅니다.

그 결과에 따라 로그와 포트, 애플리케이션 응답으로 점검 범위를 좁힐 수 있습니다.

Docker 서비스 점검의 첫 단계는 서버 전체를 다시 설정하는 일이 아니라, 해당 컨테이너가 지금 실행되고 있는지 확인하는 일입니다.