[AI] 17. ADR 086‐090 ‐ LLM 최적화 및 MLOps - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki
ADR 086-090: Exaone 8B 제외 및 Gemini API 유지 — 효율성·품질·안정성 (통합)
작성일: 2026-02-23
상태: 제안됨 (Proposed)
비고: ADR-086은 086~090 통합 건. ADR-087부터 별도 항목으로 기술함.
📚 목차
- ADR-086: 효율성·답변 품질·안정성 — Exaone 8B 제외, Gemini API 유지 (086~090 통합)
- ADR-087: SageMaker 도입 — LLM 파인튜닝 필수 5대 기능
- ADR-088: 채용 트렌드 배치 학습 파이프라인 — cron+Celery 트리거, SageMaker Training, WebBaseLoader→S3, 추후 Airflow
- ADR-089: 학습·배포용 Docker 이미지 관리 — AWS ECR 사용
- ADR-090: 개인화 추천 도입 — RAG 연계, 단계적 전략, Amazon Personalize 검토
ADR-086: 효율성·답변 품질·안정성 — Exaone 8B 제외, Gemini API 유지 (086~090 통합)
📋 메타데이터
| 항목 | 내용 |
|---|---|
| 상태 | 제안됨 (Proposed) |
| 작성일 | 2026-02-23 |
| 결정자 | AI팀 |
| 관련 기능 | 채팅, 요약, 일반 QA, LLM 라우팅, 모니터링, 폴백 |
| 관련 ADR | ADR-083 (8B 요약·32B 일반 QA), ADR-081 (SageMaker 도입), ADR-068 (Langfuse) |
🎯 컨텍스트 (Context)
경량 LLM(Exaone 8B) 도입과 Gemini API 유지 중 효율성, 답변 품질, 안정성 세 가지 관점에서 선택을 명확히 할 필요가 있다. 8B를 호스팅해 요약·경량 용도로 쓰는 대안이 있었으나, 운영·품질·비용을 종합하면 Exaone 8B는 제외하고 Gemini API를 유지하는 것이 낫다는 결론이다.
현재 상태:
- Gemini API:
llm_service.py에서gemini-3-flash-preview사용, 채팅·분석·RAG 등 다수 기능에서 사용 중. - Exaone 8B: vLLM Docker 또는 SageMaker 도입 시 요약 전용 후보로 논의됨(ADR-083).
- Exaone 32B: ADR-083에 따라 당분간 미사용(비용·할당량 제약). 일반 QA·면접은 Gemini·파인튜닝 8B로 대체.
문제점:
- 8B 자체 호스팅 시: GPU 인프라·스케일링·장애 대응 부담, 답변 품질이 Gemini Flash 대비 상대적으로 낮거나 불안정할 수 있음.
- 8B와 Gemini를 병행하면: 라우팅 복잡도·비용 이중화·품질 일관성 관리가 어려움.
요구사항:
- 효율성: 인프라·운영 부담 최소화, API 호출 기반으로 비용·트래픽 예측 용이.
- 답변 품질: 요약·경량 QA에서 품질이 안정적이고 일관되게 유지.
- 안정성: 장애·지연·한계에 대한 대응이 단순하고, 폴백 경로가 명확함.
🔍 선택지 분석 (Options)
Option 1: Exaone 8B 제외, Gemini API 유지 (권장) ⭐
Exaone 8B는 도입·호스팅하지 않고, 요약·경량 채팅·분석 등은 Gemini API만 사용한다. 32B는 기존대로 일반 QA·면접·트렌드 활용.
[요약·경량 채팅·분석] → Gemini API (gemini-3-flash-preview)
[일반 QA·면접·트렌드] → Gemini·파인튜닝 8B (32B 당분간 미사용, ADR-083)
| 장점 | 단점 |
|---|---|
| ✅ 효율성: 8B용 GPU·SageMaker 엔드포인트 불필요, 운영 단순 | ⚠️ Gemini API 의존·비용·할당량 관리 필요 |
| ✅ 답변 품질: Gemini Flash가 요약·경량 용도에서 검증된 품질·안정성 제공 | ⚠️ 외부 API 장애 시 폴백(32B) 설계 필요 |
| ✅ 안정성: 관리형 API로 가용성·스케일링 부담 감소, 폴백만 정의하면 됨 | - |
Option 2: Exaone 8B 도입(요약 전용), Gemini와 병행
ADR-083처럼 8B를 요약 전용으로 호스팅하고, 일부는 Gemini, 일부는 8B로 라우팅.
| 장점 | 단점 |
|---|---|
| ✅ 8B로 요약 비용 절감 가능(호출 단가 가정 시) | ❌ 8B 인프라·모니터링·장애 대응 부담 |
| - | ❌ 품질·안정성이 Gemini 대비 낮을 수 있음, 라우팅·배포 복잡도 증가 |
Option 3: 경량 용도 전부 32B로 통합, Gemini 축소
요약·경량 QA까지 32B로 처리하고, Gemini는 최소한만 사용 또는 제거.
| 장점 | 단점 |
|---|---|
| ✅ 모델 단일화 | ❌ 32B 비용·지연 증가, 경량 작업에 과한 리소스 사용 |
결정 (Decision)
Option 1: Exaone 8B 제외, Gemini API 유지를 선택합니다.
근거:
- 효율성: 8B 전용 GPU·엔드포인트를 두지 않아 인프라·배포·모니터링 부담이 줄고, 비용은 API 사용량 기준으로 예측 가능하다.
- 답변 품질: 요약·경량 QA는 현재 Gemini Flash로 이미 안정적으로 서비스되고 있으며, 8B 자체 호스팅 시 품질·일관성 검증과 유지 비용이 추가로 든다.
- 안정성: 관리형 API인 Gemini를 주력으로 두고, 장애·한도 시에만 32B로 폴백하는 단순한 구조가 운영·장애 대응에 유리하다.
ADR-083의 "8B 요약 전용" 시나리오는 철회하고, 요약은 Gemini API 유지로 정리한다.
구현 방향 및 세부 정책
아래는 위 결정에 따른 라우팅, 아키텍처 정리, 모니터링, 폴백을 한 덩어리로 정리한 것이다.
1) Gemini API 사용 범위 및 라우팅
| 용도 | LLM | 비고 |
|---|---|---|
| 일반 채팅·경량 QA | Gemini API | llm_service.py |
| 요약(이력서·채용공고·대화) | Gemini API | 8B 미사용 |
| RAG 기반 답변 생성 | Gemini API (기본) | rag_service.py model=gemini |
| 면접 질문 생성·꼬리질문 | Gemini 또는 SageMaker 8B | 32B 당분간 미사용(ADR-083) |
| 채용 트렌드·심화 QA | SageMaker 8B(파인튜닝) | 배치 학습 연동(8B, ADR-083·087) |
- 라우팅은 용도 기준 고정. 부하 기반 자동 분배는 당단계 도입하지 않음.
rag_service.py·llm_service.py등에 주석/문서로 "Gemini 사용 범위" 반영, 설정 기본값은 Gemini 유지.
2) Exaone 8B 제외에 따른 아키텍처·인프라 정리
docker-compose.yml의exaone-8b서비스: 로컬/개발용으로만 유지하거나 제거. 프로덕션에서는 사용하지 않음.VLLM_8B_BASE_URL: 프로덕션에서 참조하지 않거나 제거. 애플리케이션은 8B를 호출하지 않음.- 문서·ADR: "Exaone 8B는 효율성·품질·안정성 이유로 제외, Gemini API 유지" 명시. ADR-081·083의 8B 관련 문구는 "8B 제외, Gemini 유지"에 맞게 수정 검토.
- 로컬에서 8B 실험이 필요하면 profile 또는 별도 compose로만 구동.
3) Gemini API 품질·비용 모니터링
- Langfuse: 트레이스·토큰·지연·에러율로 품질 모니터링(ADR-068). Langfuse 대시보드에서 Gemini 트레이스·에러율·지연 확인 주기 정의.
- 비용: Gemini API 사용량(요청 수·토큰 수)을 주기적으로 수집해 대시보드 또는 정기 리뷰로 추적. 필요 시 비용 알람 임계값 정의.
- (선택) CloudWatch 등에 커스텀 지표 전송은 구현·유지보수 부담을 고려해 후순위.
4) LLM 폴백 전략 — Gemini 실패 시 32B
- 정책: 채팅·요약·RAG 등 Gemini를 쓰는 경로에서, 재시도 후에도 실패하면 동일 요청을 SageMaker 8B 엔드포인트(또는 보조 경로)로 전달한다. 32B는 당분간 미사용(ADR-083)이므로 폴백 후보는 8B 또는 재시도만.
- 구현:
llm_service.py등에서 Gemini 실패 시 8B(SageMaker Endpoint) 호출 경로 구현(재시도 횟수·타임아웃 정책 포함). 폴백 사용률·에러율 모니터링 및 알람.
Consequences (결과)
긍정적 영향:
- 8B 관련 인프라·코드·배포 제거 또는 미도입으로 효율성·안정성 확보.
- 요약·경량 용도 품질은 Gemini 기준으로 일관 유지.
- 라우팅·아키텍처·모니터링·폴백이 하나의 정책(8B 제외, Gemini 유지)으로 정리됨.
부정적 영향 / 트레이드오프:
- Gemini API 비용·할당량·정책에 종속; 폴백과 모니터링 설계·구현 필요.
- 폴백 시 32B 비용·지연 증가 가능 → 모니터링으로 완화.
후속 작업:
-
docker-compose.yml에서 exaone-8b 프로덕션 사용 여부 정리 및 주석,VLLM_8B_BASE_URL미사용 표기 -
rag_service.py·llm_service.py에 Gemini 사용 범위 주석/문서 반영 -
llm_service.py에서 Gemini 실패 시 32B 폴백 로직 구현(재시도·타임아웃 정책 포함) - Langfuse 품질 확인 주기 및 Gemini 사용량·비용 추적 방법 정의
- ADR-081·083에서 8B 관련 문구 "8B 제외, Gemini 유지"에 맞게 수정 검토
이력
| 날짜 | 변경 내용 |
|---|---|
| 2026-02-23 | 초기 작성 (086~090 5건 분리) |
| 2026-02-23 | 086~090 통합, 단일 ADR-086으로 재작성 |
ADR-087: SageMaker 도입 — LLM 파인튜닝 필수 5대 기능
📋 메타데이터
| 항목 | 내용 |
|---|---|
| 상태 | 제안됨 (Proposed) |
| 작성일 | 2026-02-23 |
| 결정자 | AI/인프라팀 |
| 관련 기능 | LLM 파인튜닝, SageMaker Studio, Training, Model Registry, Endpoints, Pipelines |
| 관련 ADR | ADR-081 (SageMaker 도입), ADR-083 (8B 파인튜닝·32B 미사용), ADR-084 (패키징·배포 파이프라인) |
🎯 컨텍스트 (Context)
LLM 파인튜닝(예: EXAONE 8B에 채용 트렌드 데이터 반영)을 SageMaker로 수행하려면 개발·학습·버전 관리·배포·자동화를 한 플랫폼에서 처리할 수 있는 기능 세트가 필요하다. AWS 비용·RunPod 32B GPU 할당량 제약으로 파인튜닝·서빙은 8B로 수행한다(ADR-083). AWS SageMaker에는 이를 위한 5가지 핵심 기능이 있으며, 도입 시 이 구성을 기준으로 삼을지 결정해야 한다.
현재 상태:
- SageMaker 도입은 ADR-081에서 결정됨. 8B 파인튜닝·서빙은 ADR-083에서 정리(32B 당분간 미사용).
- 파인튜닝 파이프라인(데이터 수집 → 전처리 → 학습 → 모델 등록 → 배포)은 아직 구체적인 SageMaker 기능 매핑이 없음.
요구사항:
- 작업실: 코드 작성·실험·S3/학습 코드 관리를 저렴한 환경에서 수행.
- 학습 엔진: GPU는 필요할 때만 잠깐 켜서 학습 후 자동 종료(비용 절감).
- 모델 버전 관리: v1, v2 등 버전별 등록·선택·롤백.
- 서비스 배포: 학습된 모델을 API(엔드포인트)로 서빙.
- 자동화: 데이터 추가 시 재학습부터 배포까지 한 흐름으로 실행.
🔍 선택지 분석 (Options)
Option 1: SageMaker LLM 파인튜닝 필수 5대 기능 전부 도입 (권장) ⭐
아래 5가지를 SageMaker 도입의 표준 구성으로 채택한다.
| # | 기능 | 역할 | 사용법 요약 |
|---|---|---|---|
| 1 | SageMaker Studio (또는 Notebook Instances) | 코드 작성·테스트 작업실 | Jupyter Notebook에서 Python 작성, S3 업로드·학습 코드·파이프라인 실행 명령. 저렴한 인스턴스로 띄워 두고 GPU는 학습 시에만 Training Job으로 사용 → 비용 절감. |
| 2 | SageMaker Training Jobs ⭐ | 실제 GPU 학습(파인튜닝) 엔진 | Studio에서 Estimator.fit() 등으로 "이 S3 데이터 + 이 train.py 로 A100 1대 빌려서 학습 돌려줘" 요청 → 백그라운드에서 GPU 서버를 잠깐 띄워 학습만 수행 후 자동 종료. 비용 절감의 핵심. |
| 3 | SageMaker Model Registry | 학습 완료 모델 버전 관리 | "v1: 어제 학습", "v2: 오늘 데이터 추가 학습" 식으로 등록. 성능이 좋은 버전을 골라 배포·롤백 가능. |
| 4 | SageMaker Endpoints (Real-time Inference) | 학습된 모델 API 배포 | Model Registry에서 모델 선택 후 Endpoint로 배포 → 프론트/앱에서 API 호출로 EXAONE 등 모델 응답 사용. |
| 5 | SageMaker Pipelines | 전 과정 워크플로 자동화 | 전처리 → Training Job → Model Registry 등록 → Endpoint 업데이트를 파이썬으로 묶어 자동화. 데이터만 추가돼도 재학습·배포까지 한 번에 실행 가능. |
아키텍처 흐름:
[Studio/Notebook] → 코드·실험, fit() 호출
↓
[Training Job] → S3 데이터 + train.py, GPU 일시 사용 후 종료
↓
[Model Registry] → 모델 버전 등록 (v1, v2, ...)
↓
[Endpoint] → 선택 버전으로 Real-time Inference API 배포
↑
[Pipelines] → 위 전 과정을 한 파이프라인으로 자동화
| 장점 | 단점 |
|---|---|
| ✅ 학습·버전·배포·자동화를 한 플랫폼에서 일관되게 운영 | ⚠️ 5가지 기능 학습·설정 부담 |
| ✅ GPU는 Training Job으로만 사용해 비용 최소화 | ⚠️ Pipeline 정의·유지보수 필요 |
| ✅ Model Registry로 롤백·감사·재현 가능 | - |
Option 2: Training + Endpoints만 최소 도입
Studio·Model Registry·Pipelines 없이, Training Job으로 학습하고 수동으로 모델 등록 후 Endpoint만 배포.
| 장점 | 단점 |
|---|---|
| ✅ 도입 범위 작음 | ❌ 버전 관리·재학습 자동화 없음, 휴먼 에러·재현 어려움 |
| - | ❌ 코드·실험 환경을 별도로 구축해야 함 |
Option 3: 파인튜닝만 RunPod/로컬, SageMaker는 추론만
학습은 RunPod 또는 로컬 GPU에서 하고, SageMaker는 이미 학습된 모델을 Endpoint로 배포하는 용도만 사용.
| 장점 | 단점 |
|---|---|
| ✅ 기존 RunPod 워크플로 활용 | ❌ 학습·배포·버전 관리가 플랫폼별로 분리됨 |
| - | ❌ 재학습·롤백 자동화와 통합 모니터링이 어려움 |
결정 (Decision)
Option 1: LLM 파인튜닝을 위해 SageMaker 필수 5대 기능(Studio, Training Jobs, Model Registry, Endpoints, Pipelines) 전부 도입을 표준으로 채택합니다.
근거:
- 비용: Studio는 저사양으로 두고, GPU는 Training Job에서만 일시 사용하므로 상시 GPU 인스턴스보다 비용이 낮다.
- 재현·롤백: Model Registry로 버전 관리하고, Pipelines로 전처리→학습→등록→배포를 코드로 고정하면 재현 가능·롤백이 수월하다.
- ADR-081·083·084와의 정합성: SageMaker 도입(081), 8B 파인튜닝·서빙(083), 패키징·배포 파이프라인(084)을 이 5대 기능으로 구체화하면, 채용 트렌드 반영 재학습부터 서비스 배포까지 한 흐름으로 운영할 수 있다.
도입 순서 제안:
- 1단계: Studio(또는 Notebook) + Training Jobs — 학습 코드 작성·실행 및 S3 연동.
- 2단계: Model Registry + Endpoints — 학습 결과 등록·배포 및 API 서빙.
- 3단계: Pipelines — 전 과정 자동화 및 데이터 추가 시 재학습·배포 트리거.
Consequences (결과)
긍정적 영향:
- LLM 파인튜닝 전 과정(개발·학습·버전·배포·자동화)을 SageMaker 한 플랫폼에서 처리 가능.
- GPU 비용은 Training Job 사용 시간만 발생.
- ADR-084의 “Pipelines + Model Registry” 목표와 동일한 구성으로 정렬됨.
부정적 영향 / 트레이드오프:
- Studio, Training, Registry, Endpoints, Pipelines 각각 설정·학습 필요.
- Pipeline 정의 코드 유지보수 부담.
후속 작업:
- SageMaker Studio(또는 Notebook Instances) 도메인·사용자 설정 및 S3 버킷 연동
- EXAONE 8B 파인튜닝용
train.py및 입력 데이터 포맷(S3 경로) 정의 - Training Job용 이미지(ECR)·인스턴스 타입(A100 등)·IAM 역할 정의
- Model Registry 그룹명·스테이징(Staging/Production) 규칙 정리
- Endpoint 배포 절차 및 애플리케이션 연동 URL 관리
- SageMaker Pipeline 정의(전처리 → Training → 등록 → Endpoint 업데이트) 및 실행·스케줄 정책
이력
| 날짜 | 변경 내용 |
|---|---|
| 2026-02-23 | 초기 작성 — LLM 파인튜닝 필수 5대 기능(Studio, Training, Registry, Endpoints, Pipelines) 표준 채택 |
| 2026-02-23 | ADR-083 반영 — SageMaker 파인튜닝·서빙 대상 32B → 8B로 수정(비용·할당량 제약) |
ADR-088: 채용 트렌드 배치 학습 파이프라인 — cron+Celery 트리거, SageMaker Training, WebBaseLoader→S3, 추후 Airflow
📋 메타데이터
| 항목 | 내용 |
|---|---|
| 상태 | 제안됨 (Proposed) |
| 작성일 | 2026-02-23 |
| 결정자 | AI/인프라팀 |
| 관련 기능 | 채용 트렌드 수집, 배치 학습, 스케줄러, SageMaker Training Job, LangChain WebBaseLoader |
| 관련 ADR | ADR-087 (SageMaker 5대 기능), ADR-083 (8B 파인튜닝·32B 미사용), ADR-094 (WebBaseLoader 자체 크롤링), ADR-015 (Celery Beat → Airflow) |
🎯 컨텍스트 (Context)
채용 트렌드 데이터로 EXAONE 8B를 배치 학습(파인튜닝) 하려면, 데이터 수집(LangChain WebBaseLoader) → S3 적재 → 주기적 학습 트리거 → GPU 학습 실행까지 한 파이프라인으로 정리할 필요가 있다. ADR-083에 따라 32B는 비용·할당량 제약으로 당분간 미사용하므로 파인튜닝 대상은 8B이다. 특히 누가 언제 학습을 시작하는지(스케줄/트리거)와 실제 GPU 학습은 어디서 도는지를 명확히 해야 한다.
현재 상태:
- ADR-094: 채용 트렌드 수집은 LangChain WebBaseLoader 자체 크롤링 선택. 수집 결과는 S3 등에 적재 후 SageMaker 파이프라인과 연동.
- ADR-083: 8B SageMaker 파인튜닝·서빙, 32B 당분간 미사용. 채용 트렌드 등 실시간/주기 수집 → 배치 학습(8B) 시나리오.
- ADR-087: GPU 학습은 SageMaker Training Job이 담당(Studio, Training, Registry, Endpoints, Pipelines). 파인튜닝 모델은 8B.
- ADR-015: 배치/스케줄은 Celery Beat (V3) 먼저, 복잡도 증가 시 Airflow (V4+) 전환.
요구사항:
- 트리거: 주기적으로 “배치 학습 시작”을 실행할 스케줄러 필요(cron + Celery → 추후 Airflow).
- GPU 학습: Lambda는 GPU 미지원이므로, 실제 학습은 SageMaker Training Job에서만 수행. 트리거는 SageMaker Training Job 시작 요청만 담당.
- 데이터: WebBaseLoader로 수집한 데이터를 배치(batch) 데이터로 S3에 두고, Training Job이 해당 S3 경로를 입력으로 사용.
🔍 선택지 분석 (Options)
Option 1: cron + Celery(Beat) 트리거 → SageMaker Training Job, WebBaseLoader→S3 배치 데이터, 추후 Airflow (권장) ⭐
- 스케줄/트리거: cron + Celery Beat로 주기 실행(예: 매일 새벽). Celery 태스크가 SageMaker Training Job 시작 API를 호출. 추후 워크플로 복잡도 증가 시 Airflow DAG로 이전(ADR-015과 동일 정책).
- 데이터: LangChain WebBaseLoader로 채용 트렌드 URL 크롤링 → 전처리 후 S3에 배치 데이터 적재. Training Job은 해당 S3 경로를 입력으로 사용.
- GPU 학습: SageMaker Training Job만 GPU 사용. Lambda/Celery는 “Training Job 시작” 트리거만 수행.
흐름:
[URL 목록] → [WebBaseLoader] → 채용 트렌드 크롤링 → [S3] 배치 데이터 적재
↓
[cron / Celery Beat] → 주기 실행 → [Celery Task] → SageMaker Training Job 시작 API 호출
↓
[SageMaker Training Job] → S3 데이터 읽기 → GPU 학습 → Model Registry / Endpoint
↑
(추후) [Airflow DAG] 로 트리거 대체
| 장점 | 단점 |
|---|---|
| ✅ ADR-015 (Celery Beat → Airflow)와 동일한 스케줄 정책 | ⚠️ Celery·Redis 인프라 유지 |
| ✅ GPU는 SageMaker에서만 사용, Lambda GPU 제약 회피 | ⚠️ Airflow 전환 시 DAG·의존성 이전 작업 필요 |
| ✅ WebBaseLoader→S3→Training Job으로 데이터 흐름 단순 | - |
Option 2: Lambda 트리거 + SageMaker Training Job
EventBridge( cron )로 주기 실행되는 Lambda가 SageMaker Training Job을 시작. GPU 학습은 여전히 SageMaker.
| 장점 | 단점 |
|---|---|
| ✅ 서버리스, Celery 인프라 불필요 | ⚠️ 기존 배치 정책(ADR-015)은 Celery Beat → Airflow. 학습 트리거만 Lambda로 두면 스케줄러가 이원화됨 |
| ✅ 구현 단순 | - |
Option 3: Airflow 단독 (처음부터 Airflow)
처음부터 Airflow DAG로 WebBaseLoader 크롤링 → S3 적재 → SageMaker Training Job 시작을 정의.
| 장점 | 단점 |
|---|---|
| ✅ DAG 시각화·의존성 관리 우수 | ❌ Airflow 인프라·운영 부담이 초기부터 큼. ADR-015는 V3 Celery Beat → V4+ Airflow 전환 |
| - | ❌ 단순 주기 1회 트리거에는 오버엔지니어링 가능성 |
결정 (Decision)
Option 1: cron + Celery(Beat) 트리거 → SageMaker Training Job, WebBaseLoader→S3 배치 데이터, 추후 Airflow 전환을 선택합니다.
근거:
- ADR-015 정합성: 배치/스케줄은 이미 Celery Beat(V3) → Airflow(V4+)로 결정되어 있으므로, 채용 트렌드 배치 학습 트리거도 동일하게 cron + Celery로 구현하고, 추후 Airflow로 이전한다.
- GPU는 SageMaker만: Lambda는 GPU를 지원하지 않으므로, “트리거”만 Lambda 또는 Celery로 하고 실제 GPU 학습은 SageMaker Training Job에서만 수행한다. Celery 태스크(또는 Lambda)는
boto3등으로 SageMakercreate_training_job호출만 한다. - 데이터 흐름: WebBaseLoader 크롤링 → S3 배치 데이터 → Training Job 입력은 ADR-094·083·087과 동일한 구조로, 한 번 정의해 두면 재학습·배포 자동화(ADR-087 Pipelines)와도 연결 가능하다.
구현 요약:
- 트리거: cron 또는 Celery Beat 스케줄 → Celery Task 실행 → SageMaker Training Job 시작 API 호출(입력: S3 배치 데이터 경로).
- 데이터: WebBaseLoader로 URL 크롤링 → 전처리 →
s3://bucket/.../batch/등에 적재. Training Job은 해당 경로를input으로 사용. - 추후: 동일 워크플로를 Airflow DAG로 옮겨 트리거만 Airflow가 담당하도록 전환.
Consequences (결과)
긍정적 영향:
- 채용 트렌드 배치 학습 파이프라인이 트리거(cron+Celery → Airflow)·데이터(WebBaseLoader→S3)·실행(SageMaker Training Job)으로 명확히 정리됨.
- 기존 ADR(015, 094, 083, 087)과 충돌 없이 일관된 구조 유지.
부정적 영향 / 트레이드오프:
- Celery·Redis 등 스케줄 인프라 유지 필요. Airflow 전환 시 DAG 작성·테스트 부담.
후속 작업:
- WebBaseLoader 크롤링 → S3 배치 데이터 적재 스크립트/태스크 및 경로 규칙 정의 (ADR-094 참조)
- Celery Beat 스케줄에 “SageMaker Training Job 시작” 태스크 추가(입력: S3 경로)
- Training Job용 IAM·S3 접근 권한 및
train.py입력 인자(S3 path) 정리 - (추후) 동일 흐름을 Airflow DAG로 이전 시 DAG·의존성 정의
이력
| 날짜 | 변경 내용 |
|---|---|
| 2026-02-23 | 초기 작성 — cron+Celery 트리거, SageMaker Training Job, Tavily→S3, 추후 Airflow 전환 |
| 2026-02-23 | ADR-083 반영 — 배치 학습(파인튜닝) 대상 32B → 8B로 수정 |
| 2026-02-23 | ADR-094 참조: 데이터 수집 Tavily → LangChain WebBaseLoader 자체 크롤링으로 변경 |
ADR-089: 학습·배포용 Docker 이미지 관리 — AWS ECR 사용
📋 메타데이터
| 항목 | 내용 |
|---|---|
| 상태 | 제안됨 (Proposed) |
| 작성일 | 2026-02-23 |
| 결정자 | AI/인프라팀 |
| 관련 기능 | Docker 이미지 레지스트리, SageMaker Training·Endpoint, CI/CD |
| 관련 ADR | ADR-084 (패키징·배포), ADR-087 (SageMaker 5대 기능) |
🎯 컨텍스트 (Context)
학습된 모델을 담은 Docker 이미지(vLLM·커스텀 서빙 이미지 등)를 어디서 관리할지 결정이 필요하다. AWS SageMaker Training Job·Endpoint는 커스텀 이미지를 사용할 때 컨테이너 레지스트리에서 이미지를 pull하며, 팀에선 CI/CD용 Harbor 등 다른 레지스트리를 쓸 수 있어 선택을 명시해야 한다.
요구사항:
- SageMaker Training Job·Endpoint에서 사용할 이미지 저장소 일원화
- 학습된 모델로 교체 시 이미지 버전·배포 경로 명확화
🔍 선택지 분석 (Options)
Option 1: AWS ECR 사용 (권장) ⭐
학습·배포용 Docker 이미지는 AWS ECR(Elastic Container Registry) 에서 관리한다. CI/CD에서 빌드한 이미지를 ECR에 푸시하고, SageMaker는 해당 ECR 이미지 URI를 사용해 Training Job·Endpoint를 생성·갱신한다.
[빌드] → Docker 이미지 → ECR 푸시 → SageMaker Training / Endpoint 에서 ECR 이미지 참조
| 장점 | 단점 |
|---|---|
| ✅ SageMaker와 동일 리전·IAM으로 별도 인증 없이 사용 | ⚠️ AWS 외 레지스트리(Harbor)와 이원화 시 동기화 정책 필요 |
| ✅ ADR-084의 "ECR 푸시 → 모델 등록 → 엔드포인트 배포"와 일치 | - |
| ✅ 버전·태그로 이미지 관리·롤백 용이 | - |
Option 2: Harbor 등 CI/CD 레지스트리 단독
모든 이미지를 Harbor 등 기존 CI/CD 레지스트리에서만 관리하고, SageMaker가 해당 레지스트리에서 pull하도록 설정.
| 장점 | 단점 |
|---|---|
| ✅ 레지스트리 단일화 | ❌ SageMaker가 외부 레지스트리 접근 시 VPC·인증·네트워크 설정 복잡 |
| - | ❌ ADR-084·087에서 전제한 ECR 흐름과 불일치 |
Option 3: Harbor 빌드 → ECR 미러링
CI/CD는 Harbor에 푸시하고, 동일 이미지를 ECR로 미러링한 뒤 SageMaker는 ECR만 사용.
| 장점 | 단점 |
|---|---|
| ✅ Harbor는 소스 of truth, SageMaker는 ECR만 참조 | ⚠️ 미러링 파이프라인·동기화 유지보수 필요 |
결정 (Decision)
Option 1: 학습·배포용 Docker 이미지는 AWS ECR에서 관리하기로 합니다.
근거:
- SageMaker 연동: Training Job·Endpoint가 같은 리전 ECR 이미지를 사용할 때 추가 네트워크·인증 설정 없이 IAM만으로 동작한다.
- 기존 ADR 정합성: ADR-084에서 "vLLM Docker 이미지를 ECR에 올리고, SageMaker 모델은 해당 이미지로 등록"이라고 했으며, 이미지 관리 주체를 ECR로 명시하면 일관된다.
- 학습된 모델 교체: 새 버전 이미지를 ECR에 푸시한 뒤, SageMaker Model Registry·Endpoint에서 해당 ECR 이미지 URI로 모델/엔드포인트를 갱신하면 된다.
구현 요약:
- 학습·서빙용 Dockerfile 빌드 산출물 → ECR 리포지토리에 푸시(태그: 버전 또는
latest). - SageMaker Training Job·Model·Endpoint 정의 시 이미지 URI는
{account}.dkr.ecr.{region}.amazonaws.com/{repo}:{tag}형식의 ECR URI 사용. - CI/CD에서 Harbor를 함께 쓰는 경우, SageMaker용 이미지는 ECR에도 푸시하는 단계를 두어 ECR을 SageMaker 전용 레지스트리로 사용.
Consequences (결과)
긍정적 영향:
- 학습·배포용 이미지 저장소가 ECR로 고정되어 SageMaker 연동·문서화가 단순해짐.
- 학습된 모델로 교체할 때 "ECR에 새 이미지 푸시 → Endpoint/모델 갱신" 흐름으로 통일 가능.
부정적 영향 / 트레이드오프:
- 팀이 Harbor를 주 레지스트리로 쓰는 경우, ECR 푸시 단계를 CI/CD에 추가하거나 ECR 전용 푸시 정책을 유지해야 함.
후속 작업:
- ECR 리포지토리 생성(학습용·서빙용 구분 여부 정리) 및 IAM 정책 정리
- CI/CD에서 Docker 빌드 후 ECR 푸시 절차 및 태그 규칙 정의
- SageMaker Training Job·Endpoint 설정 시 사용할 ECR 이미지 URI 규칙 문서화
이력
| 날짜 | 변경 내용 |
|---|---|
| 2026-02-23 | 초기 작성 — 학습·배포용 Docker 이미지 관리 주체를 AWS ECR로 결정 |
ADR-090: 개인화 추천 도입 — RAG 연계, 단계적 전략, Amazon Personalize 검토
📋 메타데이터
| 항목 | 내용 |
|---|---|
| 상태 | 제안됨 (Proposed) |
| 작성일 | 2026-02-23 |
| 결정자 | AI팀 |
| 관련 기능 | 개인화 추천, RAG, 채용공고·학습·면접 추천 |
| 관련 ADR | ADR-054 (RAG 리트리버), ChromaDB 컬렉션(resumes, job_postings, portfolios) |
🎯 컨텍스트 (Context)
서비스는 이미 RAG로 사용자별 이력서·채용공고·포트폴리오를 검색해 질의응답을 제공하고 있다. 최종 목표는 이를 기반으로 개인화 추천(맞춤 채용공고, 학습 포인트, 면접 질문 등)을 제공하는 것이다. RAG와 추천은 역할이 다르므로, 추천 도입 시점·방식·플랫폼을 결정할 필요가 있다.
현재 상태:
- RAG: ChromaDB 컬렉션(resumes, job_postings, portfolios) + MMR 리트리버,
user_id기준 검색. 질문에 맞는 문서를 꺼내 LLM이 답변 생성. - 추천: 별도 추천 엔진/API는 없음. “이 사용자에게 맞는 N개 아이템”을 랭킹해 주는 기능은 미구현.
요구사항:
- RAG와 충돌하지 않고 추천 기능을 단계적으로 도입할 수 있는 전략 수립.
- 추천 대상(채용공고, 학습 주제, 면접 유형 등) 및 데이터(행동 로그, 속성) 정의.
- 관리형 서비스(Amazon Personalize) 도입 여부 및 시점 검토.
🔍 선택지 분석 (Options)
Option 1: 단계적 도입 — 행동 데이터 수집 선행, 이후 Amazon Personalize 검토 (권장) ⭐
- Phase 1: RAG 유지. 추천을 위해 행동 이벤트 수집만 선행(채용공고 클릭/스크랩, 면접 참여, 채팅 주제 등). 저장소·스키마만 정의하고 별도 추천 API는 두지 않음.
- Phase 2: 이벤트가 일정량 쌓이면 Amazon Personalize 또는 자체 랭킹 모델을 도입해 “맞춤 채용공고 추천”, “추천 학습/면접” API를 제공.
- RAG와의 관계: RAG는 “질문 → 문서 검색 → 답변”으로 유지. 추천은 “사용자 → 추천 아이템 목록”으로 별도 API/UI. 필요 시 “추천된 공고 + 이력서 RAG”로 “왜 추천되었는지” 설명 생성.
| 장점 | 단점 |
|---|---|
| ✅ RAG와 역할 분리, 기존 서비스 영향 최소 | ⚠️ Phase 2까지 실제 추천 결과는 없음 |
| ✅ Personalize는 관리형이라 추천 모델·인프라 부담 적음 | ⚠️ 상호작용 데이터 품질·양에 따라 추천 품질 좌우 |
| ✅ RAG가 쌓은 사용자별 문서가 추천 후보·설명 생성에 활용 가능 | - |
Option 2: RAG 기반 유사도로 1차 추천, 추후 Personalize
RAG와 동일한 ChromaDB·임베딩을 이용해 “이력서와 유사한 채용공고”를 유사도 top-k로 먼저 제공(추천처럼 보이게). 나중에 행동 데이터가 쌓이면 Personalize로 전환하거나 혼합.
| 장점 | 단점 |
|---|---|
| ✅ 별도 추천 인프라 없이 빠르게 “비슷한 공고” 제공 가능 | ❌ 행동 기반 개인화가 아니라 콘텐츠 유사도에 불과 |
| ✅ RAG 인프라 재사용 | ❌ “클릭/지원” 등 선호 반영 불가 |
Option 3: 처음부터 Amazon Personalize 단독
행동 데이터를 가정하고 바로 Personalize 데이터셋·캠페인을 설계.
| 장점 | 단점 |
|---|---|
| ✅ 관리형 추천 일원화 | ❌ 데이터 부재 시 콜드스타트·품질 이슈, 비용 대비 효과 불명확 |
결정 (Decision)
Option 1: 단계적 도입 — 행동 데이터 수집 선행, 이후 Amazon Personalize 검토를 선택합니다.
근거:
- RAG와 목표 정합성: RAG는 “문서 검색 + 답변 생성”, 개인화 추천은 “아이템 랭킹”으로 역할이 다르며, RAG가 만든 사용자별 데이터는 추천 후보·설명에 활용 가능하므로 RAG를 유지한 채 추천을 추가하는 구조가 적합하다.
- 데이터 선행: Personalize는 사용자–아이템 상호작용(클릭, 지원, 스크랩 등)이 있어야 효과가 크므로, 먼저 이벤트 수집·스키마를 정립하고, 일정량 쌓인 뒤 Personalize 도입을 검토하는 것이 위험을 줄인다.
- 도입 시점: RAG·면접·채팅이 안정된 뒤, “맞춤 채용공고/학습/면접 추천”을 서비스 차별화로 넣을 때 Personalize 또는 자체 모델을 도입한다.
구현 방향 요약:
- 추천 대상 후보: 맞춤 채용공고, 추천 학습 포인트, 면접 질문/유형.
- Phase 1: 이벤트 수집(채용공고 조회/스크랩/지원, 면접 참여, 채팅 세션 주제 등) 스키마·저장소(S3 또는 이벤트 스트림) 정의. 추천 API는 구현하지 않거나 “RAG 유사도 기반 비슷한 공고” 수준만 제공.
- Phase 2: 이벤트가 충분히 쌓이면 Amazon Personalize 데이터셋·솔루션·캠페인 설계 및 “개인화 추천” API 연동. RAG는 그대로 두고, 추천 결과에 대해 “이 공고와 내 이력서” 등 설명이 필요하면 RAG 컨텍스트를 활용.
Consequences (결과)
긍정적 영향:
- RAG와 개인화 추천이 역할이 분리되어 설계가 명확해짐.
- 행동 데이터를 먼저 쌓아 두어, 추후 Personalize 또는 자체 모델 도입 시 데이터 기반으로 검토 가능.
부정적 영향 / 트레이드오프:
- Phase 2 전까지는 “진짜” 행동 기반 개인화 추천이 없을 수 있음. 필요 시 Phase 1에서 RAG 유사도 기반 “비슷한 공고”를 임시 추천으로 제공 가능.
후속 작업:
- 추천용 행동 이벤트 스키마 및 저장소(이벤트 로그/S3 등) 정의
- 채용공고 조회/스크랩/지원, 면접 참여 등 이벤트 수집 파이프라인 설계
- Phase 2: 이벤트 양·품질 검토 후 Amazon Personalize 데이터셋·캠페인 설계 및 API 연동
- (선택) Phase 1에서 RAG 유사도 기반 “비슷한 채용공고” API 제공 여부 결정
이력
| 날짜 | 변경 내용 |
|---|---|
| 2026-02-23 | 초기 작성 — 개인화 추천 단계적 도입, RAG 연계, Amazon Personalize 검토 |