3-9. 요청과 응답 흐름 이해¶
3-9의 판단은 배포된 endpoint가 필요한 응답 필드를 남기는지 확인하는 것입니다. Argo CD와 KServe가 resource를 만들었더라도, 응답과 로그에 request_id, model_version, score, threshold, prediction, latency, validation_failure가 없으면 운영 중 문제를 추적하기 어렵습니다.
이번 절은 API framework를 다시 배우는 시간이 아닙니다. API wrapper, KServe transformer, custom predictor, API gateway 중 어떤 구현을 쓰더라도 운영에서 확인할 필드는 유지되어야 합니다.
3-9-1. 요청 처리 경로¶
요청 처리 경로는 client payload가 모델 server까지 도달하는 순서입니다. KServe built-in runtime만 쓰면 raw inference에는 적합하지만, threshold 적용이나 custom response field는 별도 계층이 필요할 수 있습니다.
client request
→ ingress / gateway
→ transformer or custom predictor
→ model server runtime
→ response
→ structured log and metric
| 계층 | 맡는 일 | 확인할 것 |
|---|---|---|
| client | payload와 request metadata 전송 | 입력 field, request id |
| gateway/transformer | schema 검증, request id, threshold 적용 | validation failure, custom response |
| model server runtime | 모델 로딩과 inference | raw score 또는 prediction |
| log/metric layer | log, metric, trace emission | JSONL, Prometheus, trace payload |
이 구조를 알아야 KServe를 추상화로만 오해하지 않습니다. 실제 모델 점수 계산은 runtime이 하고, 운영 응답 필드는 transformer나 custom predictor가 보강할 수 있습니다.
3-9-2. 응답 필드¶
응답 필드는 HTTP 200을 넘어선 운영 확인 항목입니다. endpoint가 정상 응답하더라도 어떤 모델 alias와 threshold로 예측했는지 모르면 배포 판단을 할 수 없습니다.
| 응답 필드 | 의미 | 4장/5장에서 쓰는 방식 |
|---|---|---|
request_id |
요청 단위 추적 키 | 로그와 trace 조회 |
model_name |
모델 계열 | 배포 대상 식별 |
model_version 또는 model_alias |
현재 모델과 후보 모델 구분 | registry alias와 배포 revision 대조 |
score |
positive class 가능성 | score distribution |
threshold |
prediction 변환 기준 | threshold 변경 후보 확인 |
prediction |
최종 예측 | prediction distribution |
latency_ms |
요청 처리 시간 | latency 기준 |
validation_failure |
입력 계약 실패 여부 | validation failure rate |
이 표가 4장과 5장으로 넘어가는 핵심 handoff입니다. 필드가 빠지면 대시보드에서 그 값을 볼 수 없고, 최종 판단에서 “확인하지 못했다”로 남겨야 합니다.
3-9-3. 오류 응답과 validation failure¶
오류 응답은 모델 실패와 입력 계약 실패를 구분하게 해 줍니다. 잘못된 payload가 들어왔을 때 500 서버 오류로 처리되면 운영자는 모델 장애인지 client 입력 문제인지 구분하기 어렵습니다.
| 오류 유형 | 바람직한 처리 | 관측값 |
|---|---|---|
| 필수 field 누락 | validation error | validation_failure=true, failed field |
| 타입 오류 | validation error | error detail과 request id |
| runtime model load 실패 | service error | KServe event, Pod log |
| storageUri 접근 실패 | readiness failure | InferenceService NotReady |
| threshold 설정 누락 | response contract failure | endpoint contract 미충족 |
이 오류 구분은 4장 observability에서 직접 사용합니다. validation failure는 입력 계약 문제이고, model load 실패는 serving runtime 문제이며, threshold 누락은 응답 필드 문제입니다.
3-9-4. 보고서 handoff¶
3장의 마지막 산출물은 endpoint 확인 결과입니다. 수강생은 “배포했다”가 아니라 “어떤 것은 확인했고 어떤 것은 4장에서 더 봐야 한다”를 남깁니다.
| handoff 항목 | 확인 상태 | 4장 확인 경로 |
|---|---|---|
| Argo CD sync | 확인/미확인 | sync status와 revision |
| KServe readiness | 확인/미확인 | InferenceService condition |
| response fields | 확인/미확인 | 대표 요청 응답과 structured log |
| latency metric | 확인/미확인 | Prometheus metric |
| score/prediction distribution | 확인/미확인 | Grafana dashboard |
보고서 문장은 다음처럼 씁니다.
후보 모델의 GitOps 배포 파일은 확인했습니다. 다만 최종 배포 판단에는 response field와 운영 로그가 필요하므로, 4장에서 request_id 기반 로그, latency metric, score/prediction distribution을 확인합니다.