콘텐츠로 이동

GitOps와 배포 상태

3교시에서 확인한 Kubernetes 선언은 요청 경로와 모델 연결의 목표이지, 대상 환경의 준비나 배포 완료가 아닙니다. Pod, Deployment, Service, overlay, 이미지 지문과 모델 지문은 실행하려는 상태를 보여 주며, 수강생은 그 선언을 읽고 공동 클러스터에 적용하지 않습니다. 대상 환경은 아직 확인 전이며, 로컬 API 성공이나 설정 파일 검사를 Candidate B 배포 완료로 바꾸지 않습니다.

이 페이지는 그 목표를 Git 기록으로 읽고, 반영, 준비, 실제 요청을 나눠 배포 완료를 주장할 수 있는 범위를 정합니다. Candidate B의 모델 승인은 유지되지만, Git에 적힌 overlay가 있다고 API가 그 모델을 실행 중이라고 말할 수는 없습니다. 릴리스 회의의 “오버레이가 있고 API도 응답한다”는 말은 결론이 아니라, 네 증거를 순서대로 확인하라는 신호입니다.

이 페이지가 남기는 판단은 확인한 GitOps 단계와 아직 보지 못한 단계입니다. 운영 신호는 배포 완료의 다섯 번째 단계가 아니라, 5교시에서 같은 모델 식별값과 시간 범위로 모을 조사 자료입니다. 네 증거가 모이지 않으면 대상 확인 상태는 target_pending으로 두고, 운영 신호를 어떤 범위에서 읽을지로 넘어갑니다.

이 페이지에서 하지 않는 일

수강생은 공동 클러스터에 Application을 만들거나 반영(sync)하거나 되돌리지 않습니다. 강사가 보여 준 화면이 있으면 확인한 단계와 시각만 기록하고, 화면이 없으면 정적 overlay만 읽습니다.

Git 기록으로 배포하는 GitOps

배포 변경의 기준은 Git에 남은 검토 기록이며, 그 기록만으로 대상 서비스가 실행 중이라고 말할 수 없습니다. 누가 어떤 overlay를 골랐는지를 나중에 다시 보려면, 사람 기억이나 대화가 아니라 검토를 마친 변경의 식별값이 필요합니다. 식별값이 보여도 그 목표가 대상 환경에 반영됐는지, 실행 단위가 준비됐는지는 아직 열린 질문입니다.

GitOps는 Git에 저장한 배포 선언을 목표 상태로 삼고, 배포 조정기가 대상 환경의 현재 상태와 비교해 맞추려는 운영 방식입니다. 이 과정에서 조정기는 Argo CD이며, 검토한 변경의 40자리 식별값과 overlay 경로를 읽어 적용하려는 목표를 만듭니다. 목표는 “지금 이 모델을 이 경로로 실행하라”는 선언이지, 이미 실행 중이라는 관측이 아닙니다.

Argo CD Application에서 QA가 먼저 읽는 값은 애플리케이션 이름, 선택한 overlay 경로, 검토한 변경 식별값입니다. 기준 모델 overlay는 baseline, 교체 후보는 candidate-b, 되돌리기 의도는 rollback이며, 세 경로는 서로 다른 목표입니다. 설정 템플릿을 읽었다고 대상 클러스터에 그 목표가 적용된 것은 아니므로, 수강생은 파일을 적용하거나 반영을 실행하지 않습니다.

Git 기록과 목표를 확인한 뒤에는 “이 변경을 적용할 목표가 맞는가”만 말할 수 있습니다. 아래 표는 같은 화면에서 섞기 쉬운 세 자료를 나눕니다.

자료 보여주는 것 이 자료만으로 아직 모르는 것
Git 변경 기록 검토를 마친 변경의 40자리 식별값 그 변경이 대상 환경에 반영됐는지
Argo CD가 읽는 목표 선택한 overlay와 적용하려는 모델 경로 실행 단위가 요청을 받을 준비인지
실제 실행 상태 대상 환경에서 관측한 Pod, API, 모델 정보 Git 기록만 보고는 알 수 없음

목표는 다음 절에서 현재 상태와 같은 시각의 같은 증거가 아님을 확인한 뒤에야, 반영 여부를 물을 수 있습니다. 플랫폼 담당자가 목표를 등록하더라도 QA는 반영, 준비, 실제 요청을 별도 근거로 요청해야 합니다.

목표 상태와 현재 상태의 차이

목표 상태와 현재 상태는 서로 다른 시각의 자료이므로, 하나를 다른 하나로 바꿔 쓸 수 없습니다. 설정 변환이 성공하면 목표가 문법적으로 만들어졌다는 뜻이고, 클러스터가 그 목표를 실행 중이라는 뜻은 아닙니다. 두 상태를 같은 완료로 합치면, 아직 연결조차 확인하지 못한 대상 환경을 배포 성공으로 보고하게 됩니다.

목표 상태는 배포하려는 선언입니다. 3교시에서 렌더링한 overlay는 Candidate B 또는 기준 모델이 어떤 프로필, 예상 SHA-256, 저장소 경로를 선택하는지를 보여 줍니다. 그 결과는 GitOps가 맞추려는 입력이지, 대상 환경의 현재 객체를 읽은 결과가 아닙니다.

현재 상태는 클러스터가 실제로 적용하고 실행 중인지를 관찰한 것입니다. 현재를 말하려면 배포 조정기가 대상 Kubernetes API에 연결해 살아 있는 객체를 읽고, 목표와 차이를 계산할 수 있어야 합니다. 연결이 없으면 차이는 계산되지 않으며, 그때는 다음 절의 반영됨, 준비됨 값도 확인할 수 없습니다.

설정 변환 결과는 목표 근거입니다. YAML이 만들어졌다고 Pod와 API가 대상 환경에서 떠 있는 것은 아니므로, 목표 반영 여부와 서비스 준비 상태를 따로 확인해야 합니다. 아래 표는 두 상태가 답하는 질문을 나눕니다.

상태 확인하는 질문 필요한 자료 빠지면 할 수 없는 말
목표 상태 적용하려는 모델과 경로가 승인된 식별값인가 overlay 렌더, Git 식별값 “대상 환경이 그 모델을 실행 중이다”
현재 상태 클러스터가 그 목표를 적용하고 실행 중인가 대상 API로 읽은 객체, 반영과 준비 값 “목표 파일이 있으니 서비스가 정상이다”

QA는 목표만 맞으면 배포를 승인하지 않습니다. 목표가 맞아도 현재를 못 보면 target_pending을 유지하고, 플랫폼 담당자에게 반영과 준비 자료를 요청합니다.

배포 반영과 서비스 준비 상태

반영됨과 준비됨은 다른 질문이므로, 한 단어를 배포 완료와 같게 쓰지 않습니다. 목표가 대상에 복사됐다는 사실과, 그 실행 단위가 요청을 받을 수 있다는 사실은 연속되지만 같은 증거가 아닙니다. 한 화면의 상태 단어만 보고 운영 완료를 적으면, 아직 모델 정보와 실제 요청을 확인하지 않은 채 승인한 것과 같습니다.

반영됨(Synced)은 Git의 목표 상태가 대상 환경에 반영됐다는 뜻입니다. 이 값은 “선언한 overlay와 식별값이 클러스터 객체에 적용됐는가”에 답하며, 컨테이너가 이미 건강한지, 공개 API가 올바른 모델 정보를 내는지는 답하지 않습니다. 반영됨이 아니면 준비 상태를 성공으로 확대하지 않습니다.

준비됨(Healthy)은 적용된 실행 단위가 요청을 받을 준비인지에 가깝습니다. Argo CD는 관리하는 자원의 상태를 모아 이 값을 보여 주며, Risk API Pod와 모델 예측 단위는 각각 준비 검사를 가집니다. 준비됨이어도 /v1/model의 프로필, 버전, 임계값이 승인 기록과 같은지는 별도로 봐야 합니다.

한 단어의 정상만으로는 운영 완료를 말할 수 없습니다. 아래 표는 두 값을 배포 완료의 일부 근거로만 읽고, 다음 확인을 열어 둡니다.

상태 값 이 값이 답하는 질문 이 값만으로 말할 수 없는 것
반영됨 목표가 대상에 적용됐는가 실행 단위가 준비됐는지, 실제 요청이 성공했는지
준비됨 적용된 자원이 기대한 실행 상태에 가까운가 확인한 API가 승인된 모델 정보를 내는지
둘 다 보임 반영과 준비 화면을 읽었는가 같은 시각의 실제 요청과 운영 신호

QA 해석은 “반영됨 또는 준비됨이면 배포 완료”가 아닙니다. 둘을 확인했으면 다음으로 모델 예측 단위의 역할과, 실제 요청의 모델 정보를 요청합니다. 화면이 없으면 두 값 모두 미확인으로 남깁니다.

Kubernetes에서 모델을 제공하는 KServe

KServe는 모델 파일 묶음을 예측 서비스와 API 요청 경로로 연결하는 구성이며, 그 연결을 선언한 것이 서비스 준비를 뜻하지는 않습니다. 3교시에서 본 요청 경로는 외부 호출자가 Risk API를 부르고, Risk API가 내부 예측 단위에 점수 계산을 넘기는 구조입니다. 선언 그림이 있다고 예측 단위와 공개 요청이 이미 성공한 것은 아닙니다.

모델 파일 묶음은 학습 결과와 모델 정보를 한 경로에 둔 단위입니다. 현재 구성의 InferenceService는 읽기 전용 저장소에서 그 묶음을 읽고, 예상 모델 SHA-256이 맞는지 확인한 뒤에야 준비 상태로 올라갑니다. 파일 이름만 같고 내용 지문이 다르면 예측 단위는 준비에 실패해야 하며, 이 실패를 모델 품질 저하로 바꿔 쓰지 않습니다.

예측 서비스는 KServe 예측 단위가 내부 추론 경로로 점수를 계산하는 층입니다. Kubernetes에서 Risk API는 backend=kserve로 이 층을 호출하고, 공개 입구는 /v1/predict입니다. 내부 추론 경로는 수업용 공개 주소에 없으므로, 공개 200을 내부 예측 단위의 준비 완료와 같은 칸에 두지 않습니다.

InferenceService YAML이 있으면 예측 단위와 API 요청이 이미 성공했다고 보지 않습니다. 아래 표는 세 역할을 나눠, 준비 상태를 선언과 따로 확인하게 합니다.

역할 현재 구성에서 하는 일 준비됐다는 근거 선언만 있을 때 모르는 것
모델 파일 묶음 프로필과 내용 지문이 있는 예측 규칙 예상 SHA-256과 저장소 경로가 같은 묶음을 가리킴 그 경로의 파일이 지금 마운트됐는지
예측 서비스 검사를 통과한 입력으로 점수를 계산 예측 단위의 준비 검사 공개 API가 그 단위를 호출하는지
KServe를 거친 API 경로 Risk API가 내부 예측 단위를 호출 대상 /v1/model과 정상 요청 운영 시간대의 신호

QA는 모델 서비스에도 별도 준비 상태가 있다고 기록합니다. 다음 절의 배포 완료는 이 준비와 실제 요청을 네 증거 안의 서로 다른 칸으로 둡니다.

배포 완료를 확인하는 네 단계

배포 완료는 올바른 목표, Argo 반영, Pod와 KServe 준비, 실제 요청 성공의 네 증거가 같이 있을 때만 말합니다. 운영 기록은 이 네 단계의 다섯 번째가 아니며, 같은 모델의 운영 신호를 읽는 다음 교시 자료입니다. 모델 승인, 반영됨, 준비됨, HTTP 200을 하나의 통과로 합치면 아직 확인하지 않은 칸을 숨기게 됩니다.

첫 증거는 목표가 올바른지입니다. overlay가 고른 프로필, 예상 SHA-256, 저장소 경로가 승인된 모델 패키지와 같은지 정적 자료로 확인합니다. 목표가 틀리면 뒤에 반영과 준비가 좋아 보여도 잘못된 모델을 배포한 것입니다.

둘째와 셋째 증거는 그 목표가 반영됐는지, Pod와 모델 서비스가 준비됐는지입니다. 반영 자료와 준비 자료는 서로 바꾸지 않으며, 강사 화면이 없으면 두 칸 모두 미확인입니다. 넷째 증거는 대상 /v1/model과 정상 예측 요청이 그 모델 정보로 성공했는지이며, 로컬 Compose의 200을 이 칸에 복사하지 않습니다.

네 확인 자료가 모두 필요하며, 모델 승인은 배포 완료가 아닙니다. 아래 표는 각 단계의 보고 가능 범위를 고정합니다.

단계 확인하는 것 이 단계만으로 말할 수 있는 것 아직 모르는 것
1. 올바른 목표 overlay의 프로필, 모델 SHA-256, 경로 적용하려는 식별값이 승인 기록과 맞는가 대상에 반영됐는가
2. Argo 반영 검토한 변경 식별값, 반영됨 Git 선언이 대상에 적용됐는가 실행 단위가 준비됐는가
3. Pod와 KServe 준비 Risk API와 예측 단위의 준비, 준비됨 컨테이너가 요청을 받을 준비가 됐는가 지금 요청이 같은 모델을 실행하는가
4. 실제 요청 성공 대상 /v1/model과 정상 예측 확인한 URL이 그 모델 정보를 응답하는가 같은 모델의 운영 신호

한 단계라도 없으면 배포 완료를 적지 않고 target_pending을 유지합니다. 잘못된 승인은 다른 모델이나 미준비 서비스를 사용자에게 노출하고, 불필요한 보류는 이미 확인한 목표 검사를 무시해 검토를 늦춥니다. 네 증거가 모이지 않은 지금, 5교시로 넘어가는 조건은 운영 신호로 배포를 완성하는 것이 아니라, 확인한 모델 식별값과 미확인 범위를 인계한 뒤 신호를 모을 범위를 정하는 것입니다.

대상 환경 연결 오류 사례

Application 설정을 볼 수 있어도 대상 Kubernetes API 응답이 시간 초과이면, 현재 상태를 비교할 수 없습니다. 이름, 배포 경로, 검토한 변경 식별값은 GitOps가 읽으려는 목표를 보여 줄 뿐입니다. 목표가 화면에 있다고 기준 모델이 이미 반영됐다고 쓰면, 비교조차 못 한 상태를 배포 성공으로 바꾸게 됩니다.

준비된 사례에서 읽을 수 있는 것은 애플리케이션 설정과, 대상 Kubernetes API에 닿지 못했다는 비교 실패입니다. 다음 표는 수업용으로 제공된 오프라인 기록의 안전한 필드만 옮긴 것이며, 수강생이 대상 환경에 접속해 관측한 결과가 아닙니다.

확인 항목 준비된 기록 쓸 수 있는 판단
목표 경로 기준 모델 overlay 배포 조정기가 읽으려는 목표만 확인
현재 상태 비교 ComparisonError 대상 객체와의 차이를 계산하지 못함
동기화 상태 Unknown 반영 성공을 확인하지 못함
연결 결과 대상 Kubernetes API 시간 초과 클러스터 내부 상태는 미확인

비교 오류와 동기화 미확인이 함께 있으면, 반영됨과 준비됨을 성공으로 적지 않습니다. 대상 주소나 클러스터 식별자는 보고서에 복사하지 않으며, 확인 범위는 “현재 상태 비교 불가”까지입니다.

시간 초과는 연결 층의 관측이지, Pod나 모델 서비스 내부가 실패했다는 증거가 아닙니다. 연결이 없으면 실행 단위의 이벤트, 로그, 준비 검사를 본 것이 아니므로 그 층을 원인으로 확정하지 않습니다. 원인 후보는 “대상 Kubernetes API에 도달하지 못함”으로 남기고, 애플리케이션 실패와 구분합니다.

설정이 보인다고 GitOps 완료를 선언하지 않습니다. 아래 표는 이 사례에서 보고서에 남을 칸과 비울 칸을 나눕니다.

보이는 것 보고서에 쓸 수 있는 사실 쓰면 안 되는 결론
애플리케이션 이름, overlay 경로, 변경 식별값 목표 설정을 읽었다 그 목표가 이미 반영됐다
비교 오류, 동기화 미확인 현재 상태를 비교하지 못했다 반영됨 또는 준비됨을 확인했다
대상 Kubernetes API 응답 시간 초과 연결 층에서 확인이 멈췄다 Pod, KServe, 공개 API가 내부 실패했다

QA는 result=BLOCKED와 target_pending을 함께 적고, 플랫폼 담당자에게 연결 경로 확인을 요청합니다. 다음 절은 그 실패를 어느 층에서 멈출지 순서를 고정합니다.

배포 실패 위치의 확인 순서

연결 오류가 있으면 위에서부터 확인하고, 첫 실패 지점 아래 층은 미확인으로 남깁니다. 아래 층을 추측해 채우면 서빙 담당자에게 모델 로그를 요청하거나, 아직 보지 못한 Pod를 원인으로 적게 됩니다. 시간 초과 하나로 예측 단위나 공개 API 내부가 실패했다고 단정하지 않습니다.

확인 순서는 배포 조정기, 서비스 연결 경로, 클러스터 API, 실행 단위입니다. 조정기가 Application 설정을 읽고 비교를 시도하는지, 그 요청이 대상 환경으로 나가는지, 대상 Kubernetes API가 응답하는지, 그다음에야 Pod와 모델 서비스를 봅니다. 앞 절의 시간 초과는 클러스터 API 진입 경계에서 멈추는 관측으로 읽고, 실행 단위는 아직 보지 못한 층으로만 둡니다.

첫 실패 지점에서 확인을 중단합니다. 그 아래는 “실패”가 아니라 “응답 미확인” 또는 “실행 상태 미확인”입니다. 수강생은 공동 환경의 연결을 고치거나 반영을 재시도하지 않으며, 멈춘 층과 담당 팀만 기록합니다.

추측으로 아래 층을 채우지 않는 것이 이 절의 품질 관리입니다. 아래 표는 각 층에서 할 수 있는 말과, 첫 실패 아래에서 비울 칸을 보여 줍니다.

확인 층 이 층에서 묻는 것 첫 실패가 여기이면 그 아래 층
배포 조정기 Application 목표를 읽고 비교를 시도하는가 조정기 설정을 플랫폼이 확인 연결 경로 이하는 미확인
서비스 연결 경로 대상 환경으로 나가는 경로가 열려 있는가 연결 경로를 플랫폼이 확인 클러스터 API 이하는 미확인
클러스터 API 대상 Kubernetes API가 현재 객체를 돌려주는가 시간 초과면 현재 비교 불가 실행 단위는 미확인
실행 단위 Pod와 KServe가 준비됐는가 이 층까지 도달했을 때만 준비 실패를 논의 공개 API 모델 정보는 다음 확인

지금 준비된 사례는 클러스터 API 앞에서 멈추므로, 실행 단위와 공개 API 내부를 원인 후보에서 강화하지 않습니다. 소유자는 플랫폼 담당자이고, QA는 미확인 층을 공란으로 인계합니다.

서비스 복구 완료의 확인 조건

복구 완료는 ‘복구를 검토한다면’이라는 가정만으로 말할 수 없으며, 되돌리기 설정이나 모델 승인으로도 대신하지 않습니다. 기준 모델 overlay가 있고 Candidate B가 평가를 통과했다는 사실은, 대상 환경이 이전 모델로 돌아왔다는 증거가 아닙니다. 수강생은 되돌리기를 실행하거나 반영하지 않으며, 완료 조건을 기준으로 무엇이 아직 없는지만 적습니다.

복구 완료를 말하려면 이전 모델 식별, 준비 상태, 실제 요청, 운영 신호가 같은 기준 모델을 가리켜야 합니다. 식별은 profile, version, 모델 SHA-256이 기준 모델과 같은지이고, 준비는 반영과 준비가 그 목표를 가리키는지이며, 실제 요청은 대상 /v1/model과 정상 예측이 같은 식별값을 응답하는지입니다. 운영 신호는 같은 모델과 같은 확인 시각의 지표, 로그, 처리 경로이며, 다른 모델의 신호를 복구 증거로 붙이지 않습니다.

되돌리기 overlay는 기준 모델 경로를 다시 선택한다는 의도입니다. 그 파일이 있다는 것은 scope=static인 복구 계획이지, 대상 환경의 복구 결과가 아닙니다. 네 증거가 한 기준 모델을 가리키지 않으면 복구 완료는 보류이고, 현재 실제 환경 확인 자료가 없으므로 완료를 선언하지 않습니다.

가정과 완료를 한 칸에 두지 않습니다. 아래 표는 복구를 검토할 때 필요한 독립 증거입니다.

증거 같은 기준 모델을 가리키는 조건 이것만 있으면 부족한 이유
이전 모델 식별 프로필, 버전, SHA-256이 기준 모델과 같음 식별만으로는 반영과 요청 성공을 모름
준비 상태 그 목표의 반영과 Pod, KServe 준비 준비만으로는 공개 API 모델 정보를 모름
실제 요청 대상 URL이 같은 식별값으로 정상 응답 한 요청 성공만으로는 운영 시간대를 모름
운영 신호 같은 모델, 같은 범위의 지표와 로그 신호만으로는 배포 목표와 준비를 모름

QA 해석은 “복구 완료 미확인, 확인 자료 없음”입니다. 잘못된 승인은 아직 기준 모델이 아닌 서비스를 복구됐다고 사용자에게 알리는 위험이고, 불필요한 보류는 나중에 네 증거가 모여도 가정이 완료가 아님을 구분하지 못해 판단을 늦춥니다. 다음 교시에서는 이 미확인을 유지한 채, 운영 신호를 어떤 환경, 모델, 시간 범위에서 모을지를 정합니다.

이어서 읽을 자료