ㅁ 배포 아키텍처

ㅇ 정의:
AI 모델을 실제 서비스 환경에 배포하기 위한 구조와 방식, 모델과 애플리케이션 간의 연계 형태를 설계하는 방법.

ㅇ 특징:
서비스 요구사항, 성능, 확장성, 유지보수성에 따라 구조가 달라짐. 네트워크 통신 방식, 리소스 할당, 장애 대응 전략이 중요.

ㅇ 적합한 경우:
모델 크기, 호출 빈도, 응답 시간 요구사항에 따라 적합한 배포 방식을 선택.

ㅇ 시험 함정:
배포 구조의 차이를 단순히 ‘같다’고 오해하거나, 네트워크/리소스 제약을 무시한 선택.

ㅇ 시험 대비 “패턴 보기” 예시:
– O: “모델이 독립 서비스로 배포되면 언어별 클라이언트에서 접근 가능하다.”
– X: “모델을 웹서버에 포함하면 확장성이 높아진다.”

================================

1. Model-in-service

ㅇ 정의:
AI 모델을 애플리케이션 서버 프로세스 내부에 직접 포함하여 배포하는 방식.

ㅇ 특징:
네트워크 호출 없이 메모리 내에서 바로 모델 실행, 응답 속도가 빠르지만 서버 리소스와 함께 확장해야 함.

ㅇ 적합한 경우:
모델 크기가 작고 요청량이 적거나 예측 지연시간이 매우 중요한 경우.

ㅇ 시험 함정:
모델이 크거나 요청이 많을 때도 이 방식을 사용하면 확장성 저하.

ㅇ 시험 대비 “패턴 보기” 예시:
– O: “Model-in-service 방식은 네트워크 오버헤드가 거의 없다.”
– X: “Model-in-service는 모델과 애플리케이션을 독립적으로 확장할 수 있다.”

================================

2. Model-as-service

ㅇ 정의:
AI 모델을 별도의 독립 서비스(예: REST API, gRPC)로 배포하고, 애플리케이션이 네트워크를 통해 호출하는 방식.

ㅇ 특징:
모델과 애플리케이션이 분리되어 독립적인 확장 가능, 다양한 언어/플랫폼에서 접근 가능.

ㅇ 적합한 경우:
모델 크기가 크거나 호출량이 많아 독립적인 리소스 관리와 확장이 필요한 경우.

ㅇ 시험 함정:
네트워크 지연과 통신 오류 가능성을 무시하면 안 됨.

ㅇ 시험 대비 “패턴 보기” 예시:
– O: “Model-as-service는 언어와 플랫폼에 독립적인 접근을 지원한다.”
– X: “Model-as-service는 네트워크 지연이 전혀 없다.”

================================

3. 웹서버 내 포함 vs 독립 서비스

ㅇ 정의:
모델을 웹서버 프로세스 내부에 포함하는 구조와, 별도의 프로세스나 서버로 분리하는 구조의 비교.

ㅇ 특징:
포함 시 통신 속도 빠르지만 확장성 제한, 분리 시 확장성과 독립성 높지만 네트워크 지연 존재.

ㅇ 적합한 경우:
포함: 소규모, 저빈도 서비스 / 분리: 대규모, 고빈도 서비스.

ㅇ 시험 함정:
포함 구조가 항상 더 빠르다고 생각하는 오류(대규모 트래픽 시 병목 발생).

ㅇ 시험 대비 “패턴 보기” 예시:
– O: “독립 서비스 구조는 장애 격리와 독립 확장이 가능하다.”
– X: “웹서버 내 포함 구조는 항상 더 효율적이다.”

================================

4. 확장성

ㅇ 정의:
서비스 요청 증가에 따라 시스템 성능을 유지하거나 향상시키는 능력.

ㅇ 특징:
수평 확장(서버 추가)과 수직 확장(서버 성능 향상) 방식 존재.

ㅇ 적합한 경우:
사용량 변동이 심하거나 성장 가능성이 높은 서비스.

ㅇ 시험 함정:
수평/수직 확장의 장단점을 혼동.

ㅇ 시험 대비 “패턴 보기” 예시:
– O: “수평 확장은 인스턴스를 추가하여 처리량을 늘린다.”
– X: “수직 확장은 서버를 여러 대 추가하는 방식이다.”

================================

5. 리소스 사용

ㅇ 정의:
CPU, 메모리, GPU, 네트워크 등 시스템 자원의 소비 패턴.

ㅇ 특징:
모델 크기, 요청 빈도, 처리 방식에 따라 자원 사용량이 달라짐.

ㅇ 적합한 경우:
제한된 자원 환경에서는 경량화 모델 또는 배치 처리 고려.

ㅇ 시험 함정:
GPU 사용량과 CPU 사용량의 차이를 혼동.

ㅇ 시험 대비 “패턴 보기” 예시:
– O: “대규모 딥러닝 모델은 GPU 메모리 사용량이 크다.”
– X: “GPU는 항상 CPU보다 전력을 적게 사용한다.”

ㅁ 추가 학습 내용

컨테이너 기반 배포는 애플리케이션과 실행 환경을 패키징하여 일관된 환경에서 배포할 수 있게 해주는 방식으로, Docker는 컨테이너 생성과 관리에 사용되고 Kubernetes는 대규모 컨테이너 오케스트레이션을 담당한다. 무중단 배포 전략에는 Blue-Green 방식과 Rolling Update 방식이 있으며, Blue-Green은 두 개의 환경을 번갈아 사용하여 전환 시 다운타임을 없애고, Rolling Update는 일부 인스턴스씩 순차적으로 교체하여 서비스 중단을 최소화한다. 모델 버전 관리는 MLOps의 핵심 요소로, 모델의 변경 이력과 버전을 체계적으로 관리하여 재현성과 안정성을 확보한다. 서빙 프레임워크로는 TensorFlow Serving과 TorchServe가 있으며, 각각 TensorFlow와 PyTorch 모델을 효율적으로 배포하고 확장할 수 있도록 지원한다. 배포 아키텍처를 선택할 때는 보안 측면에서 인증과 인가 절차를 고려하고, 서비스 부하 분산을 위한 로드밸런싱, 성능 향상을 위한 캐싱 전략, 장애 발생 시 복구 목표 시간(RTO)과 복구 시점 목표(RPO) 개념을 이해하여야 한다.