새벽에 울리는 알람, 실패한 잡(Job)을 마주했을 때
평온한 새벽, 갑자기 슬랙(Slack) 알람이 울려요. 어제 배포한 데이터 마이그레이션 잡이 멈춰 있다는 메시지예요. 급하게 터미널을 열어 kubectl 명령어를 입력하지만, 머릿속이 하얘져요. 대체 어떤 명령어를 써야 이 잡이 왜 죽었는지, 로그는 어디서 봐야 하는지 바로 떠오르지 않거든요.
소규모 스타트업의 1인 운영자라면 이런 상황이 정말 자주 발생해요. 배포는 자동화되어 있어도, 정작 한 번 실행되고 끝나는 잡(Job) 작업이 실패했을 때 이를 추적하는 과정은 오롯이 운영자의 몫이기 때문이에요. 단순한 조회 명령부터 복잡한 디버깅까지, 제대로 된 잡 kubectl 명령어를 모르면 장애 복구 시간은 끝없이 길어질 수밖에 없어요.
이 글을 끝까지 읽고 나면, 당황하지 않고 잡의 상태를 정확히 파악하고 로그를 뽑아내며, 필요할 때 즉시 작업을 재개하거나 삭제하는 능력을 갖추게 될 거예요. 실무에서 바로 복사해서 쓸 수 있는 명령어 위주로 차근차근 설명할게요.
이 글에서 함께 다룰 내용들
- 잡의 현재 상태와 실행 결과를 확인하는 조회 명령
- 잡을 새로 생성하고 관리하는 실전 커맨드
- 실패한 작업의 원인을 찾는 로그 및 디버깅 방법
- 출력 형식을 바꿔서 데이터를 효율적으로 보는 팁
- 운영 중 자주 마주치는 실수와 해결 방법
잡(Job) 작업을 시작하기 전 꼭 알아야 할 기본 지식
쿠버네티스에서 잡(Job)은 데포이먼트(Deployment)와는 완전히 다른 개념이에요. 데포이먼트가 서비스를 끊김 없이 계속 유지하는 것이 목적이라면, 잡은 정해진 작업이 완료되면 스스로 종료되는 것이 목적이에요. 데이터 백업, DB 스키마 변경, 배치 계산 같은 일회성 작업에 최적화되어 있어요.
운영자가 명령어를 입력하기 전에, 지금 내가 다루려는 리소스가 어떤 성격인지 명확히 구분해야 해요. 잘못된 명령어를 쓰면 실행 중인 서비스를 중단시키거나, 완료된 작업을 불필요하게 다시 실행하는 사고가 날 수 있거든요.
리소스 유형별 비교 분석
| 구분 | 잡(Job) | 데포이먼트(Deployment) | 크론잡(CronJob) |
|---|---|---|---|
| 주 목적 | 일회성 작업 완료 | 지속적인 서비스 유지 | 정기적인 주기 작업 |
| 종료 시점 | 성공/실패 시 종료 | 수동 삭제 전까지 유지 | 스케줄 종료 후 대기 |
| 재시도 정책 | 설정된 횟수만큼 수행 | 항상 원하는 개수 유지 | 다음 스케줄까지 대기 |
잡(Job)의 성공 기준은 내부 프로세스가 0이 아닌 종료 코드를 반환하지 않는 것이에요. 만약 프로세스가 실행은 되었지만 내부 에러로 인해 종료 코드를 잘못 반환하면, 쿠버네티스는 이를 실패로 간주하고 재시도할 수 있어요.
명령어를 배우기 전에 확인해야 할 체크리스트도 있어요. kubectl 접근 권한이 있는지, 현재 컨텍스트(Context)가 작업하려는 클러스터를 가리키고 있는지 반드시 확인하세요. 잘못된 클러스터에서 삭제 명령을 내리는 것만큼 무서운 일은 없으니까요.
운영 효율을 높이는 잡 kubectl 명령어 실전 단계
이제 본격적으로 명령어를 사용할 차례예요. 단순히 외우는 게 아니라, 어떤 흐름으로 작업이 진행되는지 이해하는 것이 중요해요. 조회에서 시작해 디버깅으로 이어지는 흐름을 따라와 보세요.
STEP 1. 잡의 상태와 진행 상황 조회하기
가장 먼저 해야 할 일은 현재 잡이 잘 돌아가고 있는지 확인하는 거예요. kubectl get jobs 명령어를 입력하면 현재 클러스터에 있는 모든 잡의 목록을 볼 수 있어요. 하지만 여기서 보이는 정보는 매우 제한적이에요.
잡이 성공했는지, 아니면 계속해서 실패하며 재시도 중인지 자세히 알고 싶다면 kubectl describe job [잡_이름] 명령어를 사용해야 해요. 이 명령어를 통해 우리는 잡의 이벤트 로그를 볼 수 있는데, 여기서 Pod가 왜 생성되지 않는지, 혹은 왜 계속 죽는지에 대한 힌트를 얻을 수 있어요.
kubectl get jobs: 전체 잡 목록과 완료 횟수 확인kubectl get job [잡_이름] -o wide: 더 자세한 정보 출력kubectl describe job [잡_이름]: 잡의 상세 상태와 이벤트 로그 확인
주의할 점은 잡(Job) 자체의 상태가 ‘Completed’라고 해서 내부의 실제 데이터 작업이 완벽했다는 뜻은 아니라는 점이에요. 프로세스가 끝났다는 뜻일 뿐이니 반드시 로그를 병행해서 확인해야 해요.
STEP 2. 잡 생성 및 관리하기
잡은 보통 YAML 파일을 통해 생성해요. kubectl apply -f [파일명].yaml 명령어를 가장 많이 사용하게 될 거예요. 만약 이미 실행 중인 잡의 설정을 살짝 바꾸고 싶다면 kubectl patch를 쓸 수도 있지만, 실무에서는 안전하게 YAML 파일을 수정하고 다시 apply 하는 방식을 권장해요.
작업이 끝난 잡을 지울 때는 kubectl delete job [잡_이름]을 사용해요. 이때 한 가지 알아두면 좋은 점은, 잡을 삭제하면 그 잡이 생성했던 Pod들도 함께 삭제된다는 사실이에요. 만약 Pod의 로그를 나중에라도 확인해야 한다면, 잡을 삭제하기 전에 로그를 먼저 확보하거나 Pod를 별도로 보존하는 전략이 필요해요.
작업이 실패해서 잡이 무한 재시도 중이라면, backoffLimit 설정을 확인하세요. 이 설정값이 너무 크면 실패한 작업이 계속 돌아가며 클러스터 자원을 낭비할 수 있어요.
STEP 3. 실패 원인을 찾는 디버깅과 로그 확인
잡이 실패했다면 이제 범인을 찾아야 해요. 잡은 데포이먼트와 달리 Pod가 종료되면 사라질 수 있기 때문에 로그를 보는 타이밍이 정말 중요해요. 가장 확실한 방법은 kubectl logs -l job-name=[잡_이름] 처럼 라벨(Label)을 사용하는 거예요.
이 방식은 잡에 연결된 모든 Pod의 로그를 한 번에 훑어볼 수 있게 해줘서 매우 편리해요. 만약 특정 Pod 안으로 직접 들어가서 환경을 조사해야 한다면 kubectl exec -it [포드_이름] — /bin/bash 명령어를 사용하세요. 하지만 잡이 이미 종료된 상태라면 exec 명령어를 쓸 수 없으니, 반드시 종료 전에 로그를 확인하는 습관을 들여야 해요.
kubectl logs -l job-name=[잡_이름]: 잡과 연결된 Pod들의 로그 확인kubectl logs [포드_이름] --previous: 재시작된 Pod의 이전 로그 확인(매우 유용!)
STEP 4. 효율적인 데이터 확인을 위한 출력 포맷 활용
운영자는 수많은 데이터를 다뤄요. 눈으로 하나씩 읽는 건 비효율적이죠. kubectl은 다양한 출력 옵션을 제공해요. 예를 들어, 잡의 상태를 JSON이나 YAML 형식으로 뽑아내면 다른 자동화 스크립트에서 활용하기 아주 좋아요.
kubectl get job [잡_이름] -o json 명령어를 사용하면 잡의 모든 메타데이터를 JSON 구조로 받아볼 수 있어요. 또한 custom-columns 옵션을 쓰면 우리가 보고 싶은 정보만 골라서 표 형태로 만들 수도 있어요. 이는 대시보드를 만들거나 모니터링 도구와 연동할 때 큰 힘이 됩니다.
STEP 5. 실전 시나리오: 데이터 마이그레이션 잡 실행하기
가상의 시나리오를 하나 만들어볼게요. 여러분은 현재 DB의 데이터를 다른 테이블로 옮기는 잡을 실행해야 해요. 전체적인 흐름은 다음과 같아요.
- 먼저 마이그레이션용 YAML 파일을 작성해요. 이때
activeDeadlineSeconds를 설정해서 작업이 너무 오래 걸리면 강제로 종료되도록 안전장치를 마련해요. kubectl apply -f migration-job.yaml로 작업을 시작해요.kubectl get job -w명령어를 사용해 실시간으로 작업이 완료되는 과정을 지켜봐요. (-w 옵션은 watch의 약자로, 변화를 실시간으로 보여줘요.)- 만약 에러가 발생하면 즉시
kubectl logs -l job-name=migration-job으로 원인을 파악해요. - 작업이 성공하면
kubectl delete job migration-job으로 깔끔하게 정리해요.
자주 하는 실수와 해결법
실무에서 운영자들이 가장 많이 저지르는 실수들을 정리했어요. 비슷한 상황을 겪고 있다면 바로 적용해 보세요.
- ❌ 실수: 잡이 완료되었는데 로그가 안 보여요.
왜 발생하나요? 잡이 성공적으로 끝나면서 연결된 Pod가 삭제되었기 때문이에요.
✅ 해결법: 잡을 생성할 때 ttlSecondsAfterFinished 설정을 사용하여 완료 후 일정 시간 동안은 Pod가 유지되도록 하세요. - ❌ 실수: 잡을 수정했는데 반영이 안 돼요.
왜 발생하나요? 이미 실행 중인 잡의 스펙(Spec)은 상당 부분 수정이 불가능해요.
✅ 해결법: 기존 잡을 삭제하고 새로운 설정으로 다시 apply 하세요. - ❌ 실수: 실패한 잡이 계속해서 무한 재시도해요.
왜 발생하나요? backoffLimit 설정이 너무 크게 잡혀 있기 때문이에요.
✅ 해결법: 잡 설정 파일에서 backoffLimit을 적절한 횟수(예: 3~4회)로 제한하세요. - ❌ 실수: Pod는 떴는데 잡 상태는 여전히 Running이에요.
왜 발생하나요? Pod 내부의 프로세스가 종료되지 않고 계속 돌고 있기 때문이에요.
✅ 해결법: kubectl logs를 통해 프로세스가 무한 루프에 빠졌는지 확인하세요. - ❌ 실수: 특정 잡의 Pod만 골라서 보고 싶어요.
왜 발생하나요? 단순히 kubectl get pods를 하면 너무 많은 정보가 섞여 나와요.
✅ 해결법: kubectl get pods -l job-name=[잡_이름] 명령어로 필터링하세요.
자주 묻는 질문
Q. 실행 중인 잡을 강제로 멈추고 싶을 때는 어떻게 하나요?
가장 빠른 방법은 kubectl delete job [잡_이름] 명령어를 사용하는 거예요. 그러면 잡과 그에 속한 모든 Pod가 즉시 종료됩니다.
Q. 잡이 실패했을 때 자동으로 알림을 받을 수 있나요?
kubectl 자체 기능만으로는 어렵지만, Prometheus와 Alertmanager를 연동하거나, 쿠버네티스 이벤트를 감시하는 별도의 컨트롤러를 구축하여 알림을 받을 수 있어요.
Q. 완료된 잡의 리소스를 자동으로 정리하고 싶어요.
잡의 스펙에 ttlSecondsAfterFinished 필드를 추가해 보세요. 작업이 끝난 후 지정된 초(second)가 지나면 쿠버네티스가 알아서 잡을 삭제해 줍니다.
Q. 잡 명령어를 쓸 때 -n 옵션은 왜 중요한가요?
잡이 특정 네임스페이스(Namespace)에 생성되었다면, -n [네임스페이스_이름] 옵션을 붙이지 않으면 찾을 수 없기 때문이에요. 항상 현재 네임스페이스를 확인하세요.
성공적인 잡 운영을 위한 최종 요약
오늘 배운 내용을 바탕으로, 이제 여러분은 어떤 잡 작업이 들어와도 당황하지 않고 대처할 수 있을 거예요. 마지막으로 핵심만 정리해 드릴게요.
- 상태 확인은
describe job으로 상세히 보세요. - 로그 확인은 라벨을 활용한
kubectl logs -l job-name=...이 가장 효율적이에요. - 실패한 Pod의 이전 로그를 보려면
--previous옵션을 잊지 마세요. - 리소스 정리를 위해
ttlSecondsAfterFinished설정을 적극 활용하세요. - 작업 전 반드시 클러스터와 네임스페이스를 확인하는 습관을 가지세요.
이제 이론은 충분해요. 오늘 배운 명령어들을 실제 테스트 환경이나 스테이징 클러스터에서 직접 입력해 보세요. 눈으로 보는 것과 직접 타이핑하는 것은 완전히 다르니까요. 실습 중에 막히는 부분이 있다면 언제든 댓글로 질문을 남겨 주세요. 함께 고민해 드릴게요!
오늘의 학습이 도움이 되었다면, 다음 단계로 넘어가 볼까요? 쿠버네티스의 기초를 더 탄탄히 다지고 싶다면 클러스터 구축 입문 글을, 잡과 유사한 스케줄링 작업이 궁금하다면 쿠버네티스 크론잡(CronJob) 가이드를 읽어보시는 것을 추천해요.
