ML 도입 플레이북은(는) 무엇을 하나요?
이 스킬은 기존 소프트웨어 엔지니어링 프로젝트에 머신러닝 모델을 구현하기 위한 적응형 방법론을 제공합니다. 전통적인 SWE와 MLOps 사이의 간극을 메우며, ML을 어떻게 연구하고, 분리하고, 학습시키고, 통합할지 구조화합니다.
활성화 시점
- 사용자가 기존 코드베이스에 "ML 추가" 또는 "알고리즘 추가"를 요청합니다.
- 비ML 애플리케이션에 새 모델(예: 추천, 분류, 예측) 통합을 계획합니다.
- 에이전트가 ML 구성 요소를 적응형으로 구축, 학습, 배포하는 워크플로를 구조화합니다.
1단계: 문제 정의 및 타당성 조사
모델 코드를 작성하기 전에 "왜"와 "어떻게"를 확립합니다.
- 휴리스틱 확인: 사용자에게 간단한 휴리스틱(예: 정규 표현식, 규칙 기반 정렬)으로 문제를 더 빠르게 해결할 수 있는지 물어봅니다. 가능하다면 그 방법으로 시작합니다.
- 메트릭 정의: ML 모델이 개선하려는 비즈니스 메트릭(예: 클릭률, 지연 시간 감소)을 정의합니다.
- 오류 예산: "잘못된" 예측이 무엇인지 정의하고 시스템이 이를 어떻게 처리해야 하는지 정의합니다.
2단계: 데이터 준비
깨끗하고 접근 가능한 데이터 없이 ML은 쓸모가 없습니다.
- 데이터 소스 감사: 학습 데이터가 어디에 있는지 확인합니다. 라이브 데이터베이스인가요, 정적 CSV인가요, 아니면 API인가요?
- 데이터 계약: 입력 데이터의 스키마를 설정합니다. 어떤 특징(feature)이 필요한가요? 특징이 누락되면 어떻게 되나요?
- 정보 누수 방지: 사용자가 제안한 데이터 분할이 미래 정보를 실수로 학습 세트에 누출하지 않는지 확인합니다(예: 시계열 데이터의 경우 시간 순 분할).
3단계: 아키텍처 통합 및 분리
모델 추론을 핵심 비즈니스 로직에 강하게 결합하지 마십시오.
- API 경계: 모델을 API 엔드포인트(예:
fastapi-patterns또는django-patterns사용) 또는 전용 서비스 클래스 뒤에 배치할 것을 제안합니다. - 대체 메커니즘: 기본 상태를 설계합니다. 모델이 응답에 너무 오래 걸리거나 오류를 발생시키면 시스템이 하드코딩된 규칙으로 우아하게 대체(fallback)해야 합니다.
- 기능 플래그: 새 ML 추론 호출을 기능 플래그로 감싸서 안전하게 롤아웃(또는 롤백)할 수 있도록 합니다.
4단계: 모델 구현 및 학습
재현 가능성과 반복을 위해 코드를 구조화합니다.
- 간단하게 시작: 먼저 베이스라인 모델(예: 간단한 scikit-learn 로지스틱 회귀 또는 기본 PyTorch 선형 레이어)을 구축합니다.
- 재현 가능성:
pytorch-patterns또는 유사한 모범 사례(무작위 시드 고정, 코드를 장치에 독립적으로 만들기, 텐서/배열 모양을 명시적으로 문서화)를 적용합니다. - 자동화된 증거: 데이터 변환 및 추론 스키마에 대한 테스트를 요구합니다. 베이스라인과 비교하는 평가 스크립트 없이 모델을 수락하지 마십시오.
5단계: MLOps로 인계
베이스라인 모델이 통합되면 지속적인 운영으로 초점을 전환합니다.
mle-workflow참조: 사용자를 실험 추적, 모델 레지스트리 및 드리프트 감지 설정으로 안내합니다.- CI/CD: 모델 평가 단계를 기존 CI 파이프라인에 추가하여 향후 커밋이 모델 성능을 저하시키지 않도록 합니다.
반복적인 에이전트 워크플로
이 플레이북을 통해 사용자를 도울 때 에이전트는 다음을 수행해야 합니다:
- 명확한 질문을 하여 아키텍처를 제안하기 전에 1단계를 완료합니다.
- 데이터 계약 초안을 2단계에서 사용자 승인을 위해 작성합니다.
- 분리 인터페이스(API/서비스)를 3단계에서 학습 루프를 작성하기 전에 작성합니다.
- 재현 가능한 스크립트를 4단계에서 제공하여 모델을 학습시키고 아티팩트를 저장합니다.