Running인데 왜 접속이 안 될까? Docker 장애를 실제 사례로 해결해 보기

 

 

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

Running인데 왜 접속이 안 될까? Docker 장애를 실제 사례로 해결해 보기

도입

이번 한 주 동안 Docker 컨테이너를 확인하는 기본 방법을 하나씩 살펴보았습니다.

먼저 docker ps 명령으로 실행 중인 컨테이너를 확인했고, STATUS에 표시되는 Running, Exited, Restarting의 의미도 알아보았습니다.

이어지는 글에서는 docker logs 명령으로 컨테이너가 출력한 로그를 확인하는 방법을 정리했습니다.

그런데 실제 운영을 시작하면 조금 당황스러운 상황을 만나게 됩니다.

브라우저에서는 웹사이트가 열리지 않는데, docker ps를 실행해 보면 WordPress 컨테이너가 Running으로 표시되는 경우입니다.

처음에는 저도 Running이면 모든 것이 정상이라고 생각했습니다.

하지만 홈서버를 운영하면서 컨테이너가 실행 중인 것과 실제 서비스가 정상적으로 동작하는 것은 서로 다른 의미라는 점을 경험했습니다.

이번 글에서는 이번 주에 배운 내용을 하나의 점검 흐름으로 연결해, 접속 장애가 생겼을 때 무엇부터 확인하면 좋은지 실제 사례를 중심으로 정리해 보겠습니다.

Running은 서비스가 완전히 정상이라는 뜻이 아니라, 컨테이너의 주 프로세스가 실행 중이라는 뜻입니다.

docker ps와 docker logs를 함께 활용해 STATUS 확인부터 로그 분석, 데이터베이스와 네트워크 점검까지 가는 실제 장애 해결 흐름 정리한 인포그래픽.

※ 다이어그램은 Docker 컨테이너의 STATUS와 로그를 이용해 접속 장애의 원인을 확인하는 흐름을 바탕으로 AI 도구를 활용해 제작할 예정이며, 최종 구성과 내용은 운영자가 직접 검수합니다.
출처: 디지털 장난감

본문

① Running은 ‘정상’이 아니라 ‘실행 중’이라는 의미입니다

Docker에서 Running이라는 STATUS는 컨테이너의 주 프로세스가 현재 실행 중이라는 뜻입니다.

하지만 이것이 곧 웹사이트가 정상적으로 열리고, 데이터베이스가 연결되며, 모든 기능이 문제없이 동작한다는 의미는 아닙니다.

예를 들어 WordPress 컨테이너는 실행 중이지만 데이터베이스 연결에 실패했을 수 있습니다.

웹 서버 프로세스는 살아 있지만 애플리케이션 내부에서 오류가 발생했을 수도 있습니다.

Running은 문제 해결이 끝났다는 표시가 아니라, 다음 확인 단계로 넘어가기 위한 출발점에 가깝습니다.

② 가장 먼저 STATUS를 확인합니다

웹사이트 접속이 되지 않는다고 해서 바로 설정 파일을 수정하거나 Docker를 재설치할 필요는 없습니다.

먼저 현재 컨테이너의 상태부터 확인합니다.

docker ps

이 단계에서는 컨테이너가 현재 어떤 상태인지 빠르게 살펴봅니다.

• Running이라면 컨테이너는 실행 중이므로 로그와 실제 서비스 상태를 확인합니다.
• Exited라면 컨테이너가 종료된 원인을 로그에서 찾아봅니다.
• Restarting이라면 시작과 종료를 반복하는 이유를 확인합니다.

STATUS는 현재 상황을 분류하는 첫 번째 체크포인트입니다.

여기서 정상 여부를 모두 판단하는 것이 아니라, 다음에 무엇을 볼지 결정합니다.

③ Running이라면 다음은 로그입니다

STATUS를 확인했는데 WordPress 컨테이너가 Running으로 표시된다면 다음으로 로그를 확인합니다.

docker logs wordpress

로그에는 컨테이너 안의 프로그램이 실행되면서 출력한 메시지가 표시됩니다.

처음에는 영어 문장이 많아 부담스러울 수 있지만 모든 내용을 한 번에 해석할 필요는 없습니다.

먼저 다음과 같은 표현이 있는지 살펴봅니다.

• Error : 실행 과정에서 오류가 발생했을 가능성이 있습니다.
• Failed : 연결이나 시작, 인증 등의 과정이 실패했을 수 있습니다.
• Warning : 즉시 중단되지는 않았지만 확인이 필요한 메시지일 수 있습니다.

오류 단어 하나만 보고 원인을 단정하지 않고, 해당 메시지의 앞뒤 내용과 반복 여부를 함께 확인하는 것이 좋습니다.

④ 실제 운영에서는 이렇게 확인했습니다

한 번은 홈서버에서 운영하던 WordPress 사이트가 갑자기 열리지 않았습니다.

브라우저에서는 오류 화면이 나타났지만, 컨테이너 상태를 확인해 보니 WordPress는 Running으로 표시되었습니다.

처음에는 Docker 자체에 문제가 생겼다고 생각해 컨테이너를 다시 만들거나 재설치할까 고민했습니다.

하지만 이번 주에 정리한 순서대로 먼저 상태와 로그를 확인했습니다.

브라우저 접속 실패

↓

docker ps 실행

↓

WordPress가 Running인지 확인

↓

docker logs wordpress 실행

↓

데이터베이스 연결 오류 단서 확인

↓

DB 설정과 연결 상태 점검

결과적으로 Docker 전체를 다시 설치할 필요는 없었습니다.

로그에서 데이터베이스 연결 과정과 관련된 오류 메시지를 확인했고, WordPress와 데이터베이스 컨테이너의 설정을 다시 점검했습니다.

이 사례를 통해 Running이라는 한 단어만으로 서비스의 정상 여부를 판단하면 안 된다는 점을 배웠습니다.

⑤ 로그를 본 뒤에는 원인의 범위를 좁힙니다

로그에서 데이터베이스 연결 오류가 보인다고 해서 곧바로 한 가지 원인으로 단정할 수는 없습니다.

다음과 같이 확인 범위를 조금씩 좁혀 가는 과정이 필요합니다.

• 데이터베이스 컨테이너도 실행 중인지 확인합니다.
• WordPress와 데이터베이스의 컨테이너 이름과 네트워크 연결을 살펴봅니다.
• 환경 변수에 입력한 데이터베이스 이름과 사용자 정보가 서로 맞는지 확인합니다.
• 최근에 설정 파일이나 Compose 파일을 변경했는지 운영 기록을 확인합니다.

로그는 문제의 정답을 항상 한 줄로 알려주는 도구는 아닙니다.

대신 어디부터 살펴봐야 하는지를 알려주는 단서에 가깝습니다.

⑥ 바로 재설치하지 않는 이유

Docker를 처음 사용할 때는 문제가 생기면 삭제하고 다시 설치하는 것이 가장 빠른 해결 방법처럼 느껴질 수 있습니다.

하지만 원인을 확인하지 않은 상태에서 재설치를 반복하면 같은 문제가 다시 발생할 수 있습니다.

설정이나 데이터, 네트워크 연결에 원인이 있다면 컨테이너만 새로 만든다고 해결되지 않을 수도 있습니다.

재설치는 문제의 원인을 확인하고 필요한 설정과 데이터를 점검한 뒤 선택하는 마지막 단계로 남겨두는 것이 좋습니다.

상태와 로그를 먼저 확인하면 불필요한 삭제를 줄이고, 필요한 부분만 수정할 가능성이 높아집니다.

⑦ 이번 주 명령어를 하나의 흐름으로 연결하기

이번 주에 다룬 명령어는 많지 않습니다.

하지만 두 명령어를 어떤 순서로 사용하는지 이해하면 Docker 문제 해결의 기본 흐름을 만들 수 있습니다.

서비스 이상 발견

↓

docker ps

↓

STATUS 확인

↓

docker logs 컨테이너명

↓

오류 단서 확인

↓

관련 설정과 서비스 점검

새로운 명령어를 계속 추가하기보다 이 순서를 반복해 익히는 것이 먼저였습니다.

운영노트

이번 주 글을 준비하면서 가장 크게 느낀 점은 명령어보다 확인 순서가 더 중요하다는 것이었습니다.

예전에는 접속 문제가 생기면 설정 파일부터 열거나 Docker를 다시 실행하는 경우가 많았습니다.

원인을 알지 못한 상태에서 여러 설정을 건드리다 보니 처음의 문제보다 상황이 더 복잡해질 때도 있었습니다.

하지만 이제는 먼저 docker ps로 상태를 확인하고, 이어서 docker logs로 원인의 단서를 찾아보려고 합니다.

상태를 확인하고 로그를 읽은 뒤 필요한 부분만 수정하는 순서가 홈서버를 더 차분하게 운영하게 만들었습니다.

에디터의 해석노트

초보 운영자에게 가장 어려운 순간은 오류 메시지를 만났을 때가 아니라, 무엇부터 해야 할지 모를 때일 수 있습니다.

이럴 때 고정된 확인 순서가 있으면 당황하지 않고 첫 단계를 시작할 수 있습니다.

docker ps는 현재 상태를 분류하는 명령이고, docker logs는 다음 확인 방향을 찾는 명령입니다.

Running은 정상을 의미하는 것이 아니라, 문제를 확인하기 위한 출발점입니다.

이번 주의 목적은 명령어 두 개를 외우는 것이 아니라, 상태 확인에서 원인 확인으로 이어지는 운영 습관을 만드는 것이었습니다.

참고 링크 (References)

1. Docker CLI Reference : docker container ls
2. Docker CLI Reference : docker container logs
3. Docker Docs : Running containers
4. Docker Docs : View container logs

트러블슈팅

문제 1. Running인데 웹사이트가 열리지 않는다

Running은 컨테이너의 주 프로세스가 실행 중이라는 뜻입니다.

docker logs 컨테이너명으로 애플리케이션 오류가 있는지 확인하고, 필요한 데이터베이스나 다른 서비스의 상태도 함께 살펴봅니다.

문제 2. STATUS는 Running인데 Error가 계속 출력된다

컨테이너 실행 상태와 내부 애플리케이션 상태는 다를 수 있습니다.

오류가 반복되는지, 실제 서비스 기능에 영향을 주는지, 어느 시점부터 발생했는지를 확인합니다.

문제 3. 로그를 봐도 무엇이 문제인지 모르겠다

Error, Failed, Warning 같은 단어와 그 앞뒤 메시지부터 살펴봅니다.

서비스 이름, 포트, 데이터베이스, 파일 경로처럼 반복되는 표현을 기준으로 확인 범위를 좁힙니다.

문제 4. 바로 재설치하고 싶어진다

재설치 전에 현재 설정과 데이터, 로그를 먼저 보관하고 확인합니다.

같은 설정 오류가 남아 있다면 재설치 후에도 같은 문제가 반복될 수 있습니다.

문제 5. 어디까지 확인했는지 헷갈린다

확인한 명령과 결과를 짧게 기록합니다.

예: 7월 19일 / 사이트 접속 실패 / WordPress Running / DB 컨테이너 Running / WordPress 로그에서 DB 연결 오류 확인 / 환경 변수 점검 예정

문제 상황	먼저 확인할 방향
Running인데 접속 안 됨	애플리케이션 로그와 의존 서비스 확인
STATUS는 정상인데 Error 반복	오류 반복 여부와 실제 기능 영향 확인
로그 내용을 이해하기 어려움	핵심 오류 단어와 앞뒤 메시지 확인
바로 재설치하고 싶음	원인과 설정, 데이터부터 점검
확인 과정이 헷갈림	명령과 결과를 한두 줄로 기록

핵심 체크포인트 10

1. Running은 서비스 전체가 정상이라는 뜻이 아니라 컨테이너의 주 프로세스가 실행 중이라는 뜻이다.
2. 접속 문제가 생기면 먼저 docker ps로 컨테이너 상태를 확인한다.
3. STATUS는 현재 상황을 분류하고 다음 확인 방향을 정하는 정보다.
4. Running 상태에서도 애플리케이션이나 데이터베이스 연결 오류가 발생할 수 있다.
5. docker logs 컨테이너명으로 컨테이너가 출력한 오류 단서를 확인한다.
6. Error, Failed, Warning은 로그를 살펴보기 시작하는 기준이 될 수 있다.
7. 로그 한 줄만으로 원인을 단정하지 말고 앞뒤 메시지와 반복 여부를 함께 본다.
8. 로그에서 찾은 단서를 기준으로 관련 컨테이너와 설정의 범위를 좁혀 간다.
9. 원인을 확인하지 않은 재설치는 같은 문제를 반복시킬 수 있으므로 마지막 선택으로 남긴다.
10. 서비스 이상 → docker ps → STATUS → docker logs → 원인 점검의 순서를 습관으로 만든다.

마무리

이번 주에는 Docker 컨테이너를 확인하는 가장 기본적인 흐름을 차례대로 살펴보았습니다.

docker ps로 현재 상태를 확인하고, STATUS의 의미를 읽은 뒤, docker logs로 문제의 원인을 찾는 단서를 확인했습니다.

각 명령어를 따로 배우는 것도 중요하지만 실제 운영에서는 이 명령들을 하나의 순서로 연결하는 것이 더 중요했습니다.

Running으로 표시된다고 해서 접속 장애가 없는 것은 아닙니다.

컨테이너 상태가 정상처럼 보여도 내부 애플리케이션과 데이터베이스, 네트워크 연결에서 오류가 발생할 수 있습니다.

STATUS로 현재를 확인하고, 로그로 원인의 범위를 좁힌 뒤, 필요한 부분만 수정하는 것이 Docker 장애 점검의 기본 흐름입니다.