AI 및 LLMOps를 활용한 DevOps: 파이프라인에서 소통 가능한 모델까지

인포매텍 디지털 » Recursos » AI 및 LLMOps를 활용한 DevOps: 파이프라인에서 소통 가능한 모델까지

생성형 인공지능과 대규모 언어 모델의 등장으로 소프트웨어 개발, 배포 및 운영 방식이 완전히 바뀌었습니다. 좋은 것을 갖는 것만으로는 더 이상 충분하지 않다. 데브옵스 파이프라인 기존 MLOps를 적용하는 방식으로도 불가능합니다.LLM을 도입하면 모델이 말하고, 추론하고, 즉흥적으로 행동하며, 때로는 예측할 수 없는 방식으로 작동하는 영역으로 들어가게 됩니다.

이 새로운 시나리오에서는 팀은 LLM 기반 애플리케이션의 전체 수명주기를 관리하기 위해 DevOps, AI 및 LLMOps를 결합해야 합니다.실험 및 신속한 엔지니어링부터 배포, 모니터링, 보안 및 비용 최적화에 이르기까지, 이 글에서는 복잡한 내용들을 쉽게 풀어 설명하고 ChatOps, DevOps, MLOps, GenAIOps 및 LLMOps를 현대적인 운영 환경에 적용하는 방법을 단계별로 안내합니다.

DevOps와 MLOps에서 LLMOps까지: 모델이 더 이상 고정적이지 않은 이유

수년간 엔지니어링 팀의 최우선 과제는 다음과 같았습니다. 소프트웨어 배포 자동화 개발과 인프라 간의 마찰을 줄입니다.그리하여 DevOps가 탄생했습니다. DevOps는 지속적 통합, 지속적 배포, 코드형 인프라, 관찰 가능성, 그리고 부서 간의 끝없는 인수인계를 없애는 협업 문화를 의미합니다.

데이터가 제품의 일부가 되면서 비로소 그 특징이 드러났습니다. MLOps는 머신러닝 모델의 재현성과 추적성에 대한 요구에 대한 대응으로 등장했습니다.데이터셋 버전 관리, 학습 파이프라인 오케스트레이션, 드리프트 감지, 예측 모델의 지속적인 평가와 같은 관행이 표준화되었습니다.

문제는 LLM은 DevOps 및 MLOps에 내재된 많은 가정을 깨뜨립니다.이것들은 정적인 API나 확정적인 숫자를 반환하는 단순한 함수가 아닙니다. 자연어로 응답하고, 문맥, 지침, 도구 및 데이터를 실시간으로 혼합하며, 동일한 입력에 대해 두 가지 다른 출력을 생성할 수 있습니다.

이것은 단순히 모델과 가중치를 변경하는 것만으로는 충분하지 않습니다.또한 프롬프트, 템플릿, 의미론적 보안 정책, 제한 사항, 연결된 도구, 주입된 컨텍스트, 심지어 시스템 동작을 결정하는 비즈니스 규칙까지 제어해야 합니다.

LLMOps란 무엇이며, 실제로 어떤 문제를 해결하는가?

LLMOps를 다음과 같이 볼 수 있습니다. LLM 기반 애플리케이션의 안전하고 통제된 지속 가능한 배포, 유지 관리 및 확장을 가능하게 하는 운영 프레임워크이는 DevOps 관행, MLOps 및 생성형 모델에 특화된 새로운 기능이 공존하는 포괄적인 개념입니다.

본질적으로, LLMOps는 "완벽한 모델을 훈련시키는 것"보다는 실제 운영 환경에서 모델의 동작을 관리하는 데 더 중점을 둡니다.여기에는 프롬프트 흐름의 설계 및 버전 관리 방법, LLM이 내부 데이터 소스에 연결되는 방식, 토큰 비용 및 지연 시간 모니터링 방법, 의미론적 위험(환각, 정보 유출, 편향, 유해한 반응 등) 관리 방법 등이 포함됩니다.

LLMOps가 해결해야 할 요구 사항 중 DevOps/MLOps만으로는 충족할 수 없는 요구 사항은 다음과 같습니다. 대화 추적, 응답 품질의 자동 평가, 행동 변형의 A/B 비교와 같이 다양한 측면우리는 단순히 정확성만을 이야기하는 것이 아니라 일관성, 비즈니스와의 연계성, 그리고 보안까지 이야기하고 있습니다.

또한, 비용은 더 이상 모델 교육 및 호스팅에만 국한되지 않습니다.각 프롬프트, 확장 컨텍스트 및 동시 호출은 상용 API에서 GPU 또는 토큰 소비를 유발합니다. 이러한 소비를 가시화하고 장비, 서비스 및 사용 사례와 연결하는 LLMOps 계층이 없으면 비용이 예측할 수 없이 증가합니다.

ChatOps + LLMOps + DevOps: 운영이 대화형으로 변모합니다

가장 강력한 트렌드 중 하나는 DevOps 문화 내에서 ChatOps와 LLMOps의 통합팀들은 대시보드, 스크립트, 파이프라인에만 국한되지 않고 슬랙, 마이크로소프트 팀즈, 디스코드와 같은 채팅 채널을 통해 시스템의 상당 부분을 운영하기 시작했습니다.

ChatOps는 일상적인 운영(배포, 로그 조회, 재부팅, 구성 변경)을 제안합니다. 이러한 작업은 통신 채널 내의 봇에 의해 실행됩니다.팀 전체에 투명하게 공개됩니다. 모든 명령, 행동 및 결과가 대화에 기록됩니다.

LLM을 해당 접근 방식에 추가하면 새로운 차원의 지능이 나타납니다. 자연어를 이해하고, 의도를 해석하며, 복잡한 명령을 실행하거나 상황을 분석할 수 있는 챗봇 운영자가 모든 정확한 스크립트나 플래그를 기억할 필요가 없습니다.

이러한 수렴의 대표적인 예는 다음과 같습니다. LLM으로 구동되는 봇이 Prometheus 메트릭과 Loki 로그를 읽습니다. 누군가가 "그룹 X의 서비스가 느립니다"라고 쓰고 복제본 수를 늘리거나, 롤백을 수행하거나, 특정 테스트를 실행하는 등의 조치를 제안할 때, 이 모든 내용을 자연어로 설명해 주세요.

문화적, 운영적 차원에서 이는 다음과 같이 해석됩니다. 더 빠른 의사 결정, 반복적인 작업에 대한 수동 개입 감소, 그리고 DevOps 팀을 위한 더욱 원활한 경험끊임없이 문제 해결에만 매달리다가 전략적인 개선 작업에 착수하는 사람들.

실제 운영 환경에서 LLM 라이프사이클의 핵심 원칙

진지한 LLM 과정을 운영하는 것은 일회성 프로젝트가 아니라 지속적인 과정입니다. 이는 반복되는 순환 과정이며, 그 안에서 발생하는 각 변화는 시스템의 동작을 바꿀 수 있다.각 조직마다 현실에 맞게 조정되기는 하지만, 일반적으로 서로 영향을 주고받는 여섯 가지 주요 단계가 있습니다.

첫 번째는 모델의 훈련 또는 적응 단계기본 모델을 그대로 사용하는 것부터 자체 데이터에 미세 조정, LoRa 또는 기타 튜닝 기법을 적용하는 것까지 다양한 방법이 있습니다. 여기서 중요한 것은 성능뿐 아니라 데이터 세트, 적용된 필터, 하이퍼파라미터, 토크나이저 버전, 테스트된 아키텍처 등 모든 기록을 남기는 것입니다.

이 단계가 즉흥적으로 진행되고 문서화되지 않은 경우, 이 모델은 통치 없이 탄생했습니다.이후에는 시스템이 왜 그런 식으로 반응하는지 설명하거나 감사 시 필요할 때 특정 결과를 재현하는 것이 거의 불가능해질 것입니다.

두 번째 단계는 배포입니다. 이 단계에서는 모델이 연구실을 떠나 실제 운영 환경에 투입됩니다. LLMOps에서 이는 단순히 "컨테이너에 넣는 것"만을 의미하는 것이 아닙니다. 우리는 결정해야 한다 어떤 하드웨어를 사용해야 할까요?장시간 실행되는 컨텍스트에 대한 메모리 관리 방법, 적용할 클러스터 토폴로지, 트래픽에 따른 확장 방법 지연 시간이 급증하거나 비용이 감당할 수 없을 정도로 높아지지 않고도 가능합니다.

바로 그 지점에서 여러 가지 요소들이 작용하게 됩니다. 지속적인 행동 중심 모니터링CPU와 RAM 사용량만 살펴보는 것으로는 충분하지 않습니다. 응답의 의미적 품질, 스타일의 안정성, 오류율, 토큰당 비용의 변화, 위험하거나 일관성이 없는 응답의 발생, 그리고 다양한 사용 패턴에서의 응답 시간 변화를 모니터링해야 합니다.

후속 단계에서는 최적화 및 미세 조정 작업이 수행됩니다. 터치 프롬프트, RAG 조정, 모델 변형 테스트, 양자화, A/B 테스트 수행, 의미론적 보안 정책 변경 또는 비즈니스 규칙 개선이는 거의 장인 정신에 입각한 과정으로, 데이터, 엔지니어링 및 비즈니스 담당자들이 함께 모여 무엇을 우선시할지 결정합니다.

결론적으로, 이 모든 것은 다음 범주에 속합니다. 보안 및 거버넌스의 계층 구조 (접근 제어, 감사, 정보 유출 방지, 사용 제한, 규정 준수) 및 지속적인 업데이트 논리를 기반으로 모델과 그 생태계가 데이터, 규정 및 내부 요구 사항의 변화에 ​​​​적응하도록 조정됩니다.

Azure에서 GenAIOps 및 알림 흐름 접근 방식

LLMOps 분야에는 이러한 라이프사이클을 구조화하기 위한 매우 구체적인 제안들이 있습니다. 기업 환경에서 가장 앞선 제안 중 하나는 다음과 같습니다. Azure DevOps와 통합된 Azure Machine Learning 기반의 프롬프트 흐름을 사용하는 GenAIOps이는 LLM 기반 애플리케이션 구축에 매우 체계적인 접근 방식을 제안합니다.

프롬프트 흐름은 단순히 프롬프트 편집기가 아닙니다. LLM 상호작용 흐름의 설계, 테스트, 버전 관리 및 배포를 위한 완벽한 플랫폼단순한 경우(단일 프롬프트)부터 여러 노드, 외부 도구, 제어 및 자동 평가를 포함하는 복잡한 오케스트레이션에 이르기까지 다양합니다.

핵심적인 특징은 다음과 같습니다. 흐름의 중앙 저장소이는 기업 라이브러리 역할을 합니다. 각 팀이 프롬프트를 별도의 문서나 자체 저장소에 보관하는 대신, 명확한 분기, 수정 내역 및 이력을 갖춘 단일 관리 저장소로 통합합니다.

또한, 이 플랫폼은 변형 및 하이퍼파라미터 실험 기능을 추가합니다. 프롬프트, 모델, 온도 설정 또는 보안 정책의 다양한 조합을 테스트할 수 있습니다. 흐름의 여러 노드에서 결과를 비교하고 명확한 지표를 통해 결과를 비교합니다.

배포와 관련하여, 알림 흐름을 지원하는 GenAIOps를 사용합니다. 이 기능은 워크플로와 프로세스 세션을 모두 포함하는 Docker 이미지를 생성합니다.이러한 기능은 Azure App Services, Kubernetes 또는 관리형 프로세스와 같은 환경에서 바로 실행할 수 있습니다. 이를 기반으로 A/B 배포를 통해 실제 환경에서 플로우 버전을 비교할 수 있습니다.

또 다른 강점은 데이터 세트와 흐름 간의 관계 관리 능력입니다. 각 평가 흐름은 여러 표준 및 테스트 데이터 세트와 함께 작동할 수 있습니다.이를 통해 최종 사용자에게 제공하기 전에 다양한 시나리오에서 동작을 검증할 수 있습니다.

또한 이 플랫폼은 실제 변경 사항이 있을 때만 데이터 세트 및 흐름의 새 버전을 자동으로 등록합니다. CSV 및 HTML과 같은 형식으로 포괄적인 보고서를 생성합니다. 직관이 아닌 데이터에 기반한 의사결정을 지원하기 위해서입니다.

알림 흐름을 포함한 GenAIOps의 4단계

GenAIOps 접근 방식은 수명 주기를 명확하게 구분되는 네 단계로 나누어 "AI를 가지고 이것저것 시도해보고 결과를 보자"라는 식의 전형적인 혼란을 방지하는 데 도움을 줍니다.

첫 번째 단계인 초기화는 다음 사항에 중점을 둡니다. 비즈니스 목표를 명확하게 정의하고 대표적인 데이터 사례를 수집하십시오.여기서는 프롬프트 흐름의 기본 구조를 개략적으로 설명하고 아키텍처를 설계한 다음, 이를 더욱 정교하게 다듬을 것입니다.

실험 단계에서는 해당 샘플 데이터에 흐름이 적용됩니다. 프롬프트, 모델 및 구성의 다양한 변형을 평가합니다.최소한의 품질 및 일관성 기준을 충족하는 적절한 조합이 발견될 때까지 이 과정은 끊임없이 반복됩니다.

다음으로는 평가 및 개선 단계가 이어지는데, 이 단계에서는 보다 규모가 크고 다양한 데이터 세트를 사용하여 엄격한 비교 테스트를 수행합니다.해당 흐름이 정의된 표준에 부합하는 일관된 성능을 보일 때에만 다음 단계로 넘어갈 준비가 된 것으로 간주됩니다.

마지막으로 구현 단계에서는 효율성을 높이기 위해 흐름을 최적화하고 실제 운영 환경에 배포합니다. A/B 테스트 배포 옵션, 모니터링, 사용자 피드백 수집 및 지속적인 개선 주기 등이 포함됩니다.모든 것이 확정된 것은 아닙니다. 실제 사용 환경에서 관찰되는 내용을 바탕으로 흐름이 지속적으로 조정됩니다.

이 방법론은 코드 우선 방식의 사전 구축된 파이프라인을 포함하는 GenAIOps 저장소 템플릿으로 제공됩니다. LLM 기반 애플리케이션의 개발, 평가 및 배포를 위한 로컬 및 클라우드 기반 실행 도구 각 프로젝트마다 바퀴를 새로 발명할 필요 없이.

Azure DevOps와의 통합: 리포지토리, 파이프라인 및 인증

GenAIOps를 이론에서 실제 조직에 적용하려면 Azure DevOps와의 통합이 핵심입니다. 일반적인 템플릿은 다음과 같이 시작합니다. Azure Repos에 main과 development라는 두 개의 주요 브랜치가 있는 리포지토리가 있습니다.이는 서로 다른 환경과 코드 홍보 전략을 반영합니다.

샘플 저장소는 GitHub에서 복제되었으며 Azure Repos와 연결되어 있습니다. 저희는 보통 개발 브랜치에서 기능 브랜치를 생성하는 방식으로 작업합니다.변경 사항은 풀 리퀘스트를 통해 전송되며, 이는 자동으로 검증 및 실험 파이프라인을 실행합니다.

Azure DevOps가 Azure Machine Learning 및 기타 서비스와 상호 작용하려면 구성이 필요합니다. Azure의 서비스 엔티티를 기술적 ID로 사용이 ID는 Azure DevOps 서비스 연결에 사용되므로 파이프라인은 키를 일반 텍스트로 노출하지 않고 인증됩니다.

일반적으로 이 엔티티는 ML 구독 또는 작업 리소스에 대한 소유자 권한을 가지고 있습니다. 파이프라인은 엔드포인트를 프로비저닝하고, 모델을 등록하고, 키 저장소에서 정책을 업데이트할 수 있습니다.보안을 강화하려면 권한을 처리하는 YAML 단계를 수정하여 역할을 '기여자'로 변경할 수 있습니다.

또한 Azure DevOps에는 다음과 같은 변수 그룹이 생성됩니다. 이 저장소는 서비스 연결 이름이나 리소스 식별자와 같은 민감한 데이터를 저장합니다.이러한 변수들은 파이프라인에 환경 변수로 노출되어 코드에 중요한 정보를 하드코딩하는 것을 방지합니다.

로컬 및 원격 저장소를 구성하면 다음을 수행할 수 있습니다. 개발 브랜치는 브랜치 정책으로 보호됩니다. 병합을 허용하기 전에 풀 리퀘스트 파이프라인을 실행해야 합니다. 이 파이프라인은 빌드 유효성 검사 및 실험 흐름을 처리하여 오류가 있는 변경 사항이 도입되는 것을 방지합니다.

코드가 개발 단계에 들어가면 개발 파이프라인이 시작됩니다. 여기에는 CI와 CD의 모든 단계가 포함됩니다.실험 및 평가 실행, Azure ML 모델 레지스트리에 흐름 기록, 엔드포인트 및 스모크 테스트 배포, 새로 생성된 엔드포인트 통합 등이 포함됩니다.

동일한 패턴이 프로덕션 환경과 연결된 버전 또는 릴리스 브랜치 전체에 걸쳐 복제됩니다. 거기서, 프로덕션 환경을 위한 CI/CD 파이프라인은 실험, 평가 및 배포의 주기를 반복합니다.하지만 인프라 및 생산 수준 데이터에 대해서는 더 큰 제어 권한과 필요한 경우 추가적인 수동 검토가 가능합니다.

핵심적인 세부 사항은 이러한 파이프라인에 포함된 "인간 참여형 검토"입니다. CI 단계가 완료되면 CD는 담당자가 수동으로 승인할 때까지 잠금 상태로 유지됩니다. 이 과정은 Azure Pipelines 인터페이스에서 진행됩니다. 일정 시간(예: 60분) 내에 승인되지 않으면 실행이 거부됩니다.

현지 구현 및 LLM 제공업체와의 연계

모든 것이 파이프라인을 중심으로 돌아가는 것은 아닙니다. GenAIOps는 파이프라인 외에도 다양한 기능을 지원합니다. 신속한 실험을 위한 로컬 실행템플릿 저장소를 복제하고 루트 디렉터리에 .env 파일을 생성한 다음, 그 안에 Azure OpenAI 또는 기타 호환 가능한 엔드포인트에 대한 연결을 정의할 수 있습니다.

이러한 연결에는 api_key, api_base, api_type, api_version과 같은 매개변수가 포함됩니다. 흐름 내에서 이름으로 참조됩니다. (예를 들어, 특정 API 버전을 사용하는 "aoai"라는 연결). 이러한 방식으로 코드 변경 없이 동일한 흐름을 로컬과 클라우드에서 실행할 수 있습니다.

이 모드를 사용하려면 간단히 가상 환경 또는 conda를 생성하고 필요한 종속성을 설치합니다. (promptflow, promptflow-tools, promptflow-sdk, openai, jinja2, python-dotenv 등). 여기에서 로컬 실행 폴더에 테스트 스크립트를 작성하고 정의된 흐름에 대한 실험을 실행할 수 있습니다.

이러한 클라우드/온프레미스 이중성은 성숙한 DevOps 사고방식과 매우 잘 어울립니다. 해당 시스템은 소규모로 로컬에서 테스트되고, 파이프라인에서 공식적으로 검증된 후, 제어 및 감사 기능을 갖춘 상위 환경으로 배포됩니다.모든 항목은 Git에서 버전 관리되고 Azure DevOps에 연결되어 있습니다.

AI 및 LLMOps를 활용한 DevOps 생태계의 일반적인 도구

Azure의 특정 제품 외에도 AI 및 LLMOps를 갖춘 최신 DevOps 생태계는 일반적으로 다음과 같은 요소에 의존합니다. 챗옵스, 모델 오케스트레이션, 모니터링 및 관찰 가능성을 포괄하는 도구 모음.

ChatOps 계층에서는 여러 기능을 결합하는 것이 일반적입니다. Hubot 같은 봇을 사용하는 SlackMicrosoft Teams는 Power Virtual Agents 기반 에이전트를 사용하고, Discord는 Botpress나 Rasa 같은 프레임워크와 함께 사용하여 파이프라인, 모니터링 시스템 및 내부 서비스와 연결되는 맞춤형 어시스턴트를 구축할 수 있습니다.

LLMOps/MLOps 영역에서는 빈번하게 발생합니다. Kubeflow 및 MLflow와 같은 플랫폼 파이프라인, 모델 기록 및 실험을 관리할 뿐만 아니라 고급 지표 추적, 실행 비교 또는 심층 시각화를 위한 Weights & Biases(W&B)와 같은 특정 도구도 제공합니다.

LLM에서 애플리케이션을 구축할 때 일반적으로 사용하는 방법이 있습니다. LangChain이나 OpenLLM 유형 라이브러리와 같은 프레임워크이러한 솔루션은 프롬프트 체인, 외부 데이터 연결, 도구 및 다단계 에이전트의 조립을 용이하게 합니다. 동시에 LLM(학습 생명 유지 관리)에 특화된 관찰 가능성 솔루션이 등장하여 프롬프트, 응답, 비용 및 품질을 모니터링할 수 있게 되었습니다.

기존 DevOps와의 통합 측면에서 Jenkins 또는 GitLab CI와 같은 도구는 CI/CD 부분에서 여전히 중요한 역할을 합니다. 지속적인 클라우드 네이티브 배포를 위한 Kubernetes 및 ArgoCD또한 메트릭, 대시보드 및 로그를 위해 Prometheus, Grafana 및 Loki와 같은 관찰 가능성 스택을 사용합니다.

도전 과제, 한계 및 점진적 도입

이러한 관행과 도구의 도입은 모두 공짜로 얻어지는 것이 아닙니다. 프롬프트, 모델 버전 및 흐름 변형 관리의 복잡성 특히, 이는 상당한 문제입니다. 여러 팀이 동시에 작업할 때 —적용하는 것이 바람직한 시나리오 GitOps와 같은 전략 변경 사항 및 배포를 조정합니다.

또한, ChatOps 봇과 LLM 자체는 실행 능력을 갖추고 있습니다. 이는 상당한 보안 위험을 초래합니다. 운영 환경에서 과도한 권한이 부여되었거나 데이터 노출 지점이 제대로 제어되지 않은 경우입니다.

여기에 추가된 것은 민감한 라이선스 또는 상업용 API를 사용하는 오픈 소스 모델에 대한 의존성 이는 조건, 가격 또는 한도를 변경할 수 있습니다. 설상가상으로, 실제 생산 단계에서 LLM에 대한 철저한 평가는 여전히 많은 의문점이 해결되지 않은 채 미개척 분야로 남아 있습니다.

따라서 DevOps 내에서 LLMOps와 ChatOps의 도입을 다루는 것이 타당합니다. 점진적이고 통제된 방식으로간단한 봇을 사용하여 반복적인 작업(재부팅, 로그 조회, 빌드 태깅 등)을 자동화하는 것부터 시작합니다.

나중에 소개될 수 있습니다. LLM은 지원 작업, 사건 분류 또는 디버깅 지원에 사용됩니다.예를 들어, 로그를 기반으로 오류를 설명하거나 내부 문서를 기반으로 완화 방안을 제시하는 방식입니다.

기존 머신러닝 운영이 안정화되면 다음 단계로 넘어갈 차례입니다. 특수 언어 모델을 사용하여 LLMOps를 처리합니다. 고객 서비스, DevSecOps 또는 QA와 같은 영역에서 이전 단계에서 학습한 모든 것을 활용합니다.

이러한 모든 활동이 지향하는 궁극적인 목표는 다음과 같습니다. 대화형, 예측형, 그리고 점점 더 자율적인 엔지니어링 환경개발 및 운영의 상당 부분이 자연어로 표현되고 AI가 배포, 확장 또는 롤백에 대한 사전 예방적 결정을 내리는 데 도움을 주는 환경입니다.

DevOps, ChatOps, MLOps, GenAIOps, LLMOps 등 이 모든 요소가 갖춰지면 조직은 다음과 같은 이점을 누릴 수 있습니다. 실질적인 가치를 제공하는 LLM 기반 시스템을 구축하고 유지하기 위한 견고한 프레임워크단순한 프로토타입이나 개별 테스트에 머무르는 대신, 품질, 비용, 안전 및 비즈니스와의 연계성을 유지하면서 생산 단계에 도달하면 곧바로 문제가 발생하는 방식을 지양해야 합니다.