GenAI 시스템의 숨겨진 기술 부채: 고전적 ML과의 차이점과 대응 전략

3줄 요약

• GenAI는 도구 확산, 프롬프트 과부하, 불투명한 파이프라인 등 고전적 ML과는 다른 독특한 기술 부채를 발생시킵니다.
• 고전적 ML에서는 데이터 정제와 피처 엔지니어링에 시간을 투자했다면, GenAI에서는 평가, 이해관계자 관리, 주관적 품질 모니터링에 더 많은 시간을 할애해야 합니다.
• MLflow Traces, Databricks Feature Store, AI Gateway 등의 도구를 활용하여 GenAI 시스템의 기술 부채를 효과적으로 관리할 수 있습니다.

📌 주요 내용

GenAI 시스템은 혁신적인 기능을 제공하지만, 제대로 관리하지 않으면 빠르게 누적되는 독특한 기술 부채를 발생시킵니다. Databricks의 최신 블로그는 고전적 머신러닝과 GenAI 워크플로우의 차이점을 분석하고, GenAI 특유의 기술 부채 유형과 대응 전략을 제시합니다.

고전적 ML과 GenAI 워크플로우의 핵심 차이점

고전적 머신러닝과 GenAI는 데이터 수집, 피처 엔지니어링, 모델 최적화, 배포, 평가 등 유사한 워크플로우 단계를 따르지만, 실행 세부사항과 시간 배분은 근본적으로 다릅니다.

데이터 수집 및 변환

고전적 ML에서는 소매 판매나 장비 고장과 같은 실제 이벤트를 나타내는 구조화된 데이터(CSV, JSON)를 수집합니다. 반면 GenAI는 언어 모델이 관련성 있는 응답을 제공하는 데 도움이 되는 맥락적 지식을 수집하며, 구조화된 데이터와 비구조화된 데이터(이미지, 비디오, 텍스트 파일) 모두를 활용합니다.

GenAI에서 데이터 변환은 청킹(chunking), 임베딩 표현 생성, 메타데이터 추가 등을 포함합니다. 구조화된 데이터의 경우, LLM이 테이블 조인을 고려하지 않도록 테이블을 비정규화하는 작업이 필요할 수 있습니다.

모델 최적화

고전적 ML에서는 교차 검증, 그리드 서치, 랜덤 서치 등을 통한 하이퍼파라미터 튜닝에 집중합니다. GenAI에서는 temperature, top-k, top-p와 같은 일부 하이퍼파라미터를 변경할 수 있지만, 대부분의 노력은 모델 동작을 안내하는 프롬프트 튜닝에 투입됩니다.

평가

고전적 ML에서는 분류를 위한 F1 스코어나 회귀를 위한 RMSE(평균 제곱근 오차)와 같은 정량적 지표를 사용할 수 있습니다. 그러나 GenAI에서 LLM 출력의 정확성은 요약이나 번역의 품질과 같은 주관적 판단에 의존하므로, 응답 품질은 정량적 지표가 아닌 가이드라인으로 평가됩니다.

GenAI 프로젝트에서의 시간 배분 변화

모델 개발 루프

고전적 ML 프로젝트에서는 대부분의 시간을 피처와 입력 데이터를 반복적으로 개선하는 데 사용합니다. Databricks Feature Store와 같은 도구는 많은 팀이 관여하거나 수동으로 관리하기에는 너무 많은 피처가 있을 때 유용합니다.

반면 GenAI 프로젝트에서는 데이터 수집과 평가 사이의 상대적 시간 배분이 뒤바뀝니다. 데이터 수집은 일반적으로 모델에 충분한 컨텍스트를 수집하는 것을 포함하며, 광범위한 정제가 필요하지 않습니다. 하지만 평가는 훨씬 더 주관적이고 복잡하며, 결과적으로 시간이 많이 소요됩니다.

초기 10개의 평가 질문만으로는 사용자가 지원 봇에게 물어볼 수 있는 전체 범위의 질문을 다루지 못할 수 있으며, 이 경우 더 많은 평가를 수집해야 합니다. MLflow의 Evaluation Datasets는 항상 올바르게 작동해야 하는 “골든 셋” 예제를 버전 관리하고 개발하며 감사하는 데 유용합니다.

이해관계자 관리의 중요성

응답 품질이 최종 사용자 입력에 의존하기 때문에, 엔지니어는 요구사항을 수집하고 우선순위를 정하며 사용자 피드백을 반복하기 위해 비즈니스 최종 사용자 및 제품 관리자와 훨씬 더 많은 시간을 보냅니다.

Databricks Apps에 호스팅된 간단한 UI를 통해 MLflow Feedback API를 호출하여 응답 품질 피드백을 수집할 수 있습니다. 피드백은 MLflow Trace와 MLflow Evaluation Dataset에 추가되어 피드백과 모델 개선 사이의 선순환을 만듭니다.

GenAI 시스템의 5가지 주요 기술 부채

1. 도구 확산(Tool Sprawl)

도구는 LLM의 기능을 확장하는 강력한 방법이지만, 사용하는 도구의 수가 증가하면 관리가 어려워집니다. 도구 확산은 발견 가능성과 재사용 문제뿐만 아니라 GenAI 시스템의 품질에도 부정적인 영향을 미칠 수 있습니다.

주요 실패 지점:

• 도구 선택: LLM은 광범위한 도구 중에서 올바른 도구를 선택해야 합니다. 주간 판매 통계와 월간 판매 통계를 위한 데이터 API 호출처럼 도구가 거의 유사한 작업을 수행하는 경우, 올바른 도구가 호출되도록 보장하기 어렵습니다.
• 도구 매개변수: 올바른 도구를 선택한 후에도 LLM은 사용자의 질문을 도구에 전달할 올바른 매개변수 세트로 파싱해야 합니다.

Databricks Unity Catalog과 AI Gateway를 활용한 적절한 거버넌스 전략은 여러 도구와 액세스를 확장 가능하게 관리하는 데 도움이 됩니다.

2. 프롬프트 과부하(Prompt Stuffing)

최첨단 모델이 여러 페이지의 지침을 처리할 수 있더라도, 지나치게 복잡한 프롬프트는 상충되는 지침이나 오래된 정보와 같은 문제를 야기할 수 있습니다. 이는 특히 프롬프트가 편집되지 않고 여러 도메인 전문가나 개발자에 의해 시간이 지나면서 계속 추가될 때 발생합니다.

Anthropic의 프롬프트 엔지니어링 가이드에서 언급했듯이, 일반적으로 하나의 길고 복잡한 프롬프트보다 여러 개의 작은 프롬프트를 사용하는 것이 명확성, 정확성, 문제 해결에 도움이 됩니다.

MLflow Prompt Registry와 같은 프레임워크는 프롬프트 버전을 추적하고 예상 입력 및 출력을 강제함으로써 프롬프트를 관리 가능하게 유지하는 데 도움이 됩니다. Databricks에서 실행할 수 있는 DSPy와 같은 프롬프트 최적화 도구는 프롬프트를 개별적으로 또는 전체적으로 최적화할 수 있는 독립적인 모듈로 분해합니다.

3. 불투명한 파이프라인(Opaque Pipelines)

응답이 오류를 반환할 때—”죄송합니다. 질문에 답할 수 없습니다”라는 두려운 메시지—중간 LLM 호출의 입력과 출력을 검사하는 것이 근본 원인을 정확히 찾아내는 데 중요합니다.

적절한 계측을 통해 애플리케이션에 관찰 가능성을 구현하는 것이 에이전트 상호작용을 보다 투명하게 만드는 첫 걸음입니다. MLflow Traces와 같은 프레임워크를 사용하면 자동 추적 캡처와 수동 계측의 조합으로 전체 범위의 에이전트 상호작용을 다룰 수 있는 유연성을 제공합니다.

MLflow Traces의 trace 데코레이터는 모든 함수에 사용되어 입력과 출력을 캡처할 수 있으며, 동시에 특정 코드 블록 내에서 사용자 정의 MLflow Traces 스팬을 생성하여 보다 세밀한 작업을 로깅할 수 있습니다.

4. 인간 피드백 캡처 및 활용 시스템 부족

LLM은 몇 가지 간단한 프롬프트를 전달하고 결과를 함께 연결하면 뉘앙스와 지침을 잘 이해하는 것처럼 보이는 무언가를 만들 수 있기 때문에 놀랍습니다. 그러나 사용자 피드백으로 응답을 근거 지우지 않고 이 경로를 너무 멀리 가면 품질 부채가 빠르게 쌓일 수 있습니다.

가능한 한 빨리 “데이터 플라이휠”을 만드는 것이 도움이 되며, 이는 세 단계로 구성됩니다:

• 성공 지표 결정
• 사용자가 작동하는 것에 대한 피드백을 제공할 수 있는 UI를 통해 이러한 지표를 측정하는 방법 자동화
• 지표를 개선하기 위해 프롬프트나 파이프라인을 반복적으로 조정

MLflow Feedback API와 Databricks Apps를 활용하면 비즈니스 사용자가 접근할 수 있는 환경에서 피드백 UI를 호스팅할 수 있습니다.

5. 정기적인 이해관계자 체크인 없이 구축

최종 사용자, 비즈니스 스폰서, 인접 팀과 정기적으로 상의하여 올바른 것을 구축하고 있는지 확인하는 것은 모든 종류의 프로젝트에서 기본입니다. 그러나 GenAI 프로젝트에서는 이해관계자 커뮤니케이션이 그 어느 때보다 중요합니다.

정기적이고 밀접한 커뮤니케이션이 중요한 이유:

• 소유권과 통제: 정기적인 회의는 이해관계자들이 애플리케이션의 최종 품질에 영향을 미칠 수 있는 방법이 있다고 느끼도록 도와줍니다. 비평가가 아닌 협력자가 될 수 있습니다.
• 우리는 우리가 모르는 것을 모릅니다: GenAI는 매우 새로운 기술이어서 기술적인 사람과 비기술적인 사람 모두 대부분 LLM이 무엇을 제대로 처리할 수 있고 처리할 수 없는지 모릅니다. LLM 애플리케이션을 개발하는 것은 관련된 모든 사람에게 학습 여정이며, 정기적인 접점은 모든 사람에게 정보를 제공하는 방법입니다.

모델 배포 루프의 차이점

고전적 ML 배포 시간 소비 요소:

• 리팩토링: 노트북 코드를 보다 견고하게 만들기 위해 상당한 노력이 필요합니다. Databricks Asset Bundles MLOps Stacks 템플릿과 같은 코드 저장소 폴더 구조를 설정하면 이 리팩토링 프로세스에 필요한 토대를 제공할 수 있습니다.
• 품질 모니터링: 데이터 오류가 다양한 형태를 취할 수 있고 감지하기 어렵기 때문에 품질 모니터링도 시간이 많이 소요됩니다.

GenAI 배포 시간 소비 요소:

• 품질 모니터링: GenAI의 경우 실시간 요구사항과 주관적 평가로 인해 모니터링이 상당한 시간을 차지합니다. Databricks AI Gateway와 같은 API 게이트웨이를 설정하면 LLM API에 대한 가드레일 확인을 수행하여 안전 및 데이터 프라이버시 요구사항을 지원할 수 있습니다.
• 테스트: GenAI 애플리케이션에서 테스트는 종종 더 많은 시간이 소요됩니다. MLflow Traces의 trace 데코레이터와 같은 계측 도구를 사용하여 에이전트 출력의 신뢰할 수 있는 진실의 소스를 집계한 후에야 개발자는 실패 모드를 식별하고 그에 따라 테스트를 설계할 수 있습니다.

👨‍💻 개발자에게 미치는 영향

GenAI 개발 패러다임 전환의 필요성

고전적 ML에서 GenAI로 전환하는 팀은 이러한 새로운 부채 소스를 인식하고 그에 따라 개발 관행을 조정해야 합니다. 고전적 ML 프로젝트를 지배했던 데이터 정제 및 피처 엔지니어링보다는 평가, 이해관계자 관리, 주관적 품질 모니터링, 계측에 더 많은 시간을 투자해야 합니다.

실무 적용 전략

1. 도구 관리: Unity Catalog과 AI Gateway를 활용하여 도구 확산을 체계적으로 관리하고, 전략적으로 최소한의 도구만 사용하세요.

2. 프롬프트 최적화: MLflow Prompt Registry를 사용하여 프롬프트 버전을 추적하고, DSPy를 활용하여 복잡한 프롬프트를 모듈화하세요.

3. 관찰 가능성 구축: MLflow Traces를 활용하여 LLM 체인의 모든 단계를 추적하고, 문제 발생 시 신속하게 근본 원인을 파악하세요.

4. 피드백 루프 구축: Databricks Apps와 MLflow Feedback API를 활용하여 사용자 피드백을 지속적으로 수집하고 모델 개선에 반영하세요.

5. CI/CD 자동화: Databricks Asset Bundles를 사용하여 데이터 및 AI 프로젝트의 지속적 통합 및 배포를 관리하세요.

장기적 유지보수 관점

GenAI 프로젝트에서는 데이터 액세스 제어 적용, 안전을 관리하고 프롬프트 인젝션을 방지하기 위한 가드레일 설치, 비용 급증 방지 등 다양한 형태의 기술 부채를 해결해야 합니다.

고전적 ML과 GenAI는 동일한 기술 영역의 다른 맛입니다. 차이점을 인식하고 솔루션을 구축하고 유지하는 방법에 미치는 영향을 고려하는 것이 중요하지만, 변하지 않는 진리도 있습니다. 커뮤니케이션은 여전히 격차를 메우고, 모니터링은 여전히 재앙을 방지하며, 깔끔하고 유지 관리 가능한 시스템은 장기적으로 여전히 혼란스러운 시스템보다 성능이 뛰어납니다.

원문 기사 보기