ㅁ 인프라 및 자동화

1. Kubernetes Operators

ㅇ 정의:
– Kubernetes API를 확장하여 특정 애플리케이션이나 서비스의 배포, 관리, 운영을 자동화하는 컨트롤러 패턴.
– Custom Resource Definition(CRD)을 활용하여 도메인 특화 리소스를 정의하고, 해당 리소스의 상태를 관리.

ㅇ 특징:
– 선언적 구성(Declarative Configuration) 기반 자동화.
– 애플리케이션 수명주기(Lifecycle) 관리 가능.
– 복잡한 운영 로직을 코드로 구현하여 반복 작업 최소화.

ㅇ 적합한 경우:
– 데이터베이스, 메시지 브로커 등 상태 유지(Stateful) 애플리케이션 관리.
– 반복적이고 표준화된 배포/운영 작업 자동화.

ㅇ 시험 함정:
– 단순한 Deployment YAML 작성과 Operators 개념을 혼동.
– CRD와 Operator의 차이를 묻는 문제에서 ‘CRD만으로 자동화 가능’이라고 오답 유도.

ㅇ 시험 대비 “패턴 보기” 예시:
– (O) Kubernetes Operators는 특정 애플리케이션의 배포와 관리 로직을 자동화한다.
– (X) Kubernetes Operators는 모든 Kubernetes 클러스터 기능을 대체한다.

2. Feature Store 구현

ㅇ 정의:
– 머신러닝 모델 학습과 예측 시 일관된 피처 데이터를 제공하기 위해 피처를 저장, 관리, 제공하는 시스템.
– 온라인/오프라인 스토어를 통해 실시간 및 배치 피처 제공.

ㅇ 특징:
– 피처 재사용성 향상 및 데이터 품질 보장.
– 학습-서빙 간 데이터 스큐(Skew) 방지.
– 데이터 버전 관리 및 접근 제어 기능 포함.

ㅇ 적합한 경우:
– 여러 모델이 동일한 피처를 공유하는 환경.
– 실시간 예측 서비스에서 지연을 최소화해야 하는 경우.

ㅇ 시험 함정:
– 단순 데이터 레이크/웨어하우스와 혼동.
– Feature Store가 모델 저장소(Model Registry) 역할까지 한다고 착각.

ㅇ 시험 대비 “패턴 보기” 예시:
– (O) Feature Store는 학습과 예측에서 동일한 피처를 일관되게 제공한다.
– (X) Feature Store는 모델의 파라미터를 저장하고 버전 관리한다.

3. Explainability Logging

ㅇ 정의:
– 모델의 예측 결과에 대한 설명 가능성(Explainability) 정보를 로그로 기록하여 추적, 감사, 디버깅에 활용하는 기법.
– SHAP, LIME 등의 설명 기법 결과를 함께 저장.

ㅇ 특징:
– 모델 의사결정 근거를 사후 분석 가능.
– 규제 준수, 책임성 확보에 유리.
– 운영 환경에서 예측 편향 감지 가능.

ㅇ 적합한 경우:
– 금융, 의료 등 규제가 엄격한 산업.
– 모델 성능 저하 원인 분석 및 개선 필요 시.

ㅇ 시험 함정:
– Explainability Logging을 단순 예측 결과 로깅과 혼동.
– 모든 로그가 설명 정보를 포함한다고 생각하는 오류.

ㅇ 시험 대비 “패턴 보기” 예시:
– (O) Explainability Logging은 예측 결과와 함께 설명 정보를 기록한다.
– (X) Explainability Logging은 로그 저장 공간을 줄이기 위해 사용된다.

ㅁ 추가 학습 내용

Kubernetes Operators
– Operator SDK의 개념과 사용 방법
– Helm 기반 Operator 개발 방식
– Operator Lifecycle Manager(OLM)의 역할과 개념

Feature Store 구현
– Feast, Tecton 등 대표 오픈소스 및 상용 솔루션의 구조
– 온라인 스토어와 오프라인 스토어 간의 동기화 방식
– 데이터 스큐를 방지하기 위한 전략

Explainability Logging
– GDPR, AI Act 등 규제와의 연계성
– SHAP 값 계산에 따른 비용과 실시간 로깅 시의 성능 영향
– 설명 정보 처리 시의 보안 및 프라이버시 이슈