• 목록

쿠버네티스에서 컨테이너가 실행 중이라고 표시되는데 접속은 되지 않는 상황이 있습니다. 반대로 요청은 잠깐 실패했을 뿐인데 컨테이너가 계속 다시 시작되기도 합니다.

두 상황을 모두 서버가 죽었다고 표현하면 상태 점검 설정을 어디서 고쳐야 할지 알기 어렵습니다. 이 글은 readiness와 liveness를 처음 구분하는 개발자를 위해 점검 결과가 어떤 운영 판단으로 이어지는지 정리합니다.

등장하는 서비스와 시간 순서는 이해를 위한 가상 사례입니다.

AI 생성 삽화 · 개념 이해를 위한 AI 연출 이미지이며 실제 시스템 구성도나 측정 결과가 아닙니다.

핵심 정리
readiness는 요청을 받을 준비를, liveness는 재시작으로 회복할 상태인지를 판단하는 데 사용합니다. 점검 URL을 만들기 전에 실패했을 때 어떤 조치를 원하는지부터 정합니다.

1. 실행 중이라는 표시에서 한 걸음 더 확인합니다

프로세스가 떠 있다는 사실과 사용자 요청을 처리할 수 있다는 사실은 서로 다른 관찰입니다. 식당의 조명이 켜져 있어도 주문을 받을 준비가 끝난 것은 아닌 상황을 떠올리면 이해하기 쉽습니다.

가상의 상품 조회 서비스가 시작된 뒤 내부 자료를 읽는 데 시간이 걸린다고 가정하겠습니다. 그동안 프로그램은 실행되지만 필요한 자료가 없어 정상 결과를 내지 못합니다.

운영 화면에 실행 여부만 보여 주면 배포 담당자는 준비가 끝났다고 착각할 수 있습니다. 상태를 설명할 때는 프로세스 실행, 요청 처리 준비, 실제 요청 성공을 별도 항목으로 적는 편이 좋습니다.

어떤 항목이 확인되지 않았는지 드러나야 다음 조사도 구체적으로 시작할 수 있습니다.

2. 점검 이름보다 실패 이후의 동작을 봅니다

쿠버네티스 공식 문서는 readiness 실패 시 해당 Pod를 연결하는 Service의 EndpointSlice에서 트래픽 대상이 조정되고, liveness 실패가 설정된 허용 횟수를 넘으면 컨테이너 재시작으로 이어진다고 설명합니다. startup probe가 구성되어 있으면 그것이 성공하기 전까지 나머지 두 점검은 시작되지 않습니다.

이 차이를 설정 검토의 출발점으로 삼을 수 있습니다. 점검 실패에 대한 요구가 새 요청을 잠시 받지 않는 것인지, 프로그램을 다시 시작하는 것인지 먼저 적어 봅니다.

동일한 불편을 보더라도 바라는 회복 방식이 다르면 같은 조건을 복사해서는 안 됩니다. 특히 readiness 실패만으로 이미 처리 중인 요청이 모두 취소된다고 해석하지 않아야 합니다.

요청 종료 방식은 애플리케이션과 연결 경로를 함께 살펴야 합니다.

3. 가상의 배포 과정을 시간 순서로 읽습니다

새 버전이 시작되고 초기 자료를 읽는 동안에는 아직 주문 조회를 받을 수 없다고 가정합니다. 자료 준비가 끝나면 새 요청을 받기 시작하고, 나중에 내부 작업이 멈추면 별도의 이상 상태가 됩니다.

이 세 구간을 시작 준비 중, 요청 처리 가능, 회복 조치 필요로 나누어 봅니다. 구간 이름을 붙이면 준비가 오래 걸린다는 이유로 정상 초기화를 계속 중단시키는 설계를 발견하기 쉬워집니다.

반대로 시작이 끝났다는 기록만 있고 그 이후 멈춤을 확인하지 못하는 빈틈도 보입니다. 예시의 시간은 특정 서비스에 적용할 권장값이 아닙니다.

실제 설정을 정할 때는 평소 시작 시간과 느린 경우의 기록을 함께 확인해야 합니다. 개발 PC에서 한 번 성공한 시간만으로 운영 환경의 여유를 정하지 않는 편이 좋습니다.

4. 공유 서비스 장애를 내 프로그램의 고장과 구분합니다

상품 서버 여러 개가 하나의 외부 가격 서비스를 이용한다고 가정하겠습니다. 가격 서비스가 잠깐 응답하지 않는 동안 모든 상품 서버를 다시 시작하면 가격 서비스 자체가 회복되는 것은 아닙니다.

오히려 시작 작업과 재연결이 동시에 늘어날 수 있습니다. 이 사례에서 먼저 검토할 질문은 재시작이 원인을 바꾸는가입니다.

가격 정보가 없으면 어떤 요청까지 처리할 수 없는지, 이전 값을 보여 줄 수 있는 요청이 있는지도 나누어 봅니다. 의존 서비스 하나의 응답 실패를 모든 기능의 고장과 동일하게 취급하면 서비스가 제공할 수 있는 범위를 지나치게 줄일 수 있습니다.

점검 기준을 만들 때는 외부 연결 문제와 내부 진행 불능을 어떤 신호로 구별할지 설명을 남기는 것이 도움이 됩니다.

5. 상태 점검 자체의 부담도 생각합니다

점검용 경로가 정상 주문 처리보다 많은 작업을 한다면 상태를 알아보는 행위가 부하를 더할 수 있습니다. 예를 들어 가상의 점검 경로가 모든 상품을 읽고 큰 보고서를 매번 생성하도록 설계되어 있다고 생각해 봅니다.

응답이 늦어졌을 때 서비스가 느린 것인지 점검이 무거운 것인지 판단하기 어렵습니다. 상태를 표현하는 데 필요한 최소한의 관찰이 무엇인지 먼저 찾습니다.

점검 결과에는 운영 판단에 필요한 정보만 남기고 고객 자료나 상세 내부 설정이 노출되지 않도록 접근 범위를 검토합니다. 같은 경로를 여러 감시 도구가 반복 호출하는지도 확인합니다.

점검 간격을 줄이는 선택은 발견 시간을 줄일 수 있지만 관찰 대상이 받는 요청도 늘린다는 점을 함께 계산해야 합니다.

6. 정상과 실패를 각각 재현해 봅니다

설정 파일 문법이 맞는 것만으로 점검 설계가 검증되지는 않습니다. 테스트 환경에서 준비가 늦은 시작, 일시적인 의존 서비스 실패, 내부 작업 정지처럼 서로 다른 상황을 나누어 봅니다.

각 상황마다 기대하는 상태 변화와 재시작 여부를 먼저 기록합니다. 이후 실제 이벤트와 애플리케이션 로그를 같은 시간대로 맞춰 비교합니다.

예상하지 못한 재시작이 있었다면 점검 실패가 먼저였는지 프로그램 종료가 먼저였는지도 확인해야 합니다. 단순히 정상으로 돌아왔다는 결과만 보면 불필요한 재시작이 반복되었는지 놓칠 수 있습니다.

시험 과정에서 사용한 설정과 관찰 결과를 함께 남기면 다음 배포에서 조건이 바뀌었을 때 비교할 기준이 생깁니다.

7. 면접과 코드 리뷰에서는 이유까지 설명합니다

readiness는 준비 상태이고 liveness는 생존 상태라고 외우는 것만으로는 실제 설계를 설명하기 부족합니다. 우리 서비스에서 준비 완료를 무엇으로 판단하며, 어떤 실패는 기다리고 어떤 실패는 다시 시작할지까지 말해 봅니다.

가상의 문서 변환 서비스라면 작업 수신 준비와 변환 작업자의 진행 여부를 별도로 설명할 수 있습니다. 한 점검에 모든 책임을 넣었다면 그 조건이 실패할 때 조치가 과도하지 않은지도 묻습니다.

설정값을 제안할 때는 관찰한 시작 시간, 허용할 감지 지연, 시험한 실패 상황을 근거로 붙입니다. 점검 종류를 많이 사용하는 것보다 실패 신호와 회복 조치가 맞게 연결되는지가 설계의 핵심입니다.

운영자가 이벤트를 보고 판단할 수 있도록 점검 경로의 의미도 문서에 남깁니다. 리뷰 자료에는 정상 상태의 화면만 첨부하기보다 시험한 실패에서 어떤 이벤트가 남았는지 요약합니다.

가상의 비교표에 기대 동작, 관찰 동작, 남은 질문을 세 칸으로 적으면 설정을 고치는 근거가 분명해집니다. 재시작이 필요하다고 판단한 조건도 설명으로 남깁니다.

그 조건이 단순히 응답 한 번이 늦었던 것인지 실제 진행이 멈췄다는 신호인지 구분해야 합니다. 운영 환경의 여러 Pod가 같은 순간에 실패했을 때도 개별 프로그램 문제인지 공통 의존성 문제인지 비교할 수 있게 시간 정보를 맞춥니다.

점검 결과를 원인 자체로 취급하기보다 원인을 좁혀 가는 관찰로 사용하는 태도가 중요합니다.

8. 자주 묻는 질문

Q1. readiness가 실패하면 바로 재시작하나요?

그 실패 자체는 요청 수신 준비 상태에 반영됩니다. 재시작이 함께 보였다면 liveness 결과, 프로세스 종료, 배포 이벤트 등 다른 원인을 시간 순서로 확인해야 합니다.

Q2. 두 점검에 같은 URL을 써도 되나요?

가능하지만 그 URL의 실패가 두 조치 모두에 적합한지 검토해야 합니다. 일시적인 외부 연결 실패까지 재시작 조건에 넣는 구조인지 먼저 살펴봅니다.

Q3. startup probe는 모든 서비스에 필요한가요?

초기화 특성과 기존 점검 동작을 보고 판단합니다. 시작 준비가 긴 서비스라면 정상 초기화가 고장으로 처리되는지 시험한 결과가 구성 판단에 도움이 됩니다.

Q4. 상태 점검이 성공하면 사용자 기능도 정상인가요?

점검이 관찰한 범위에서 성공한 것입니다. 실제 사용자 경로의 응답과 업무 결과는 별도의 확인 항목으로 두어야 놓치는 구간을 줄일 수 있습니다.

참고 자료

• Kubernetes 공식 문서: Liveness, Readiness, and Startup Probes