LLMOps란 무엇인가요?
최근 GPT-4와 같은 대규모 언어 모델(large language model, 이하 LLM)의 사용이 보편화되면서 이를 활용한 애플리케이션이 활발히 개발되고 있습니다. 예를 들어 24시간 영어 선생님 역할을 하는 애플리케이션이나 고객 서비스 문의에 사람처럼 답변하는 애플리케이션과 같은 방식으로 LLM은 우리 생활 곁으로 가까이 다가오고 있습니다.
그러나 이러한 LLM 기반 애플리케이션을 직접 개발해 상용 서비스화하는 것은 여전히 어려운 과제입니다. 만능처럼 보이는 LLM은 그저 현재 문맥을 파악한 뒤 확률에 따른 답변을 생성해 그럴듯한 응답을 제공하는 데 집중하기 때문에 엉뚱한 답변 등으로 서비스 품질이 떨어지는 것을 막으려면 여러 가지 기술을 적용하는 복잡한 과정이 필요하기 때문입니다.
LLM이 유의미한 답변을 제공하도록 개발하기 위해서는 데이터셋 준비, 모델 학습, 배포 등의 절차가 필요합니다. 즉, 원하는 도메인에 해당하는 데이터셋을 수집하고 이를 LLM이 학습할 수 있는 형태로 가공해야 하며, 모델을 학습하고 평가할 수 있는 환경을 구축해야 하고, 완성된 모델을 사용자가 문제없이 활용할 수 있도록 안정적으로 배포하고 모니터링해야 합니다.
이러한 과정을 효율적으로 관리할 수 있도록 지원하는 것이 바로 이번 글에서 다룰 LLMOps의 역할입니다. LLMOps는 전반적인 LLM의 라이프 사이클을 관리하면서 데이터 사이언티스트와 소프트웨어 엔지니어가 원활히 협업할 수 있도록 돕는 역할도 수행합니다.
최근 LLMOps는 LLM 학습과 배포뿐 아니라 프롬프트 엔지니어링과 에이전트 제작, 종합적인 테스트 환경까지 더 넓은 범위를 포함해 지원하기 시작했습니다. 이는 관리가 필요한 도메인이 LLM 자체뿐 아니라 LLM 애플리케이션 제작에 꼭 필요한 컴포넌트들까지로 확장됐기 때문입니다. 따라서 LLMOps는 이제 모델 관리를 넘어 LLM 애플리케이션의 전체 워크플로를 지원하는 방향으로 정의가 변화하고 있습니다.
MLOps와의 차이점은 무엇인가요?
그렇다면 LLMOps는 머신 러닝 개발의 워크플로를 지원하는 MLOps와는 어떤 차이가 있을까 요? 아래는 일반적인 LLM 애플리케이션의 기본적인 추론(inference) 과정입니다.
LLM 애플리케이션은 ML 추론 과정과 같이 입력, 전처리, 모델(모델에 질의하는 과정), 후처리 순서로 추론하지만, 그 과정에 RAG(Retrieval-Augmented Generation, 검색 증강 생성)와 프롬프트 엔지니어링 등 LLM만의 복잡한 과정이 추가됩니다. 이런 부분에서 MLOps와 차이가 있다고 할 수 있습니다.
그뿐만 아니라 모델을 평가하는 방식에도 차이가 있습니다. ML에서는 0 혹은 1로 평가하거나 일정 기준에 따른 점수로 표현되는 지표를 통해 평가하는 방식을 사용하는데요. LLM은 답이 숫자 형태가 아니라 자연어 형태로 나오기 때문에 답변의 유창성이나 관련성, 일관성 같은 사람의 개입이 필요한 평가 항목이 추가로 존재합니다. 따라서 LLMOps는 사람이 결과를 쉽게 평가할 수 있는 환경을 함께 제공해야 합니다.
이와 같은 차이점 때문에 LLMOps는 MLOps와는 조금 다른 형태로 발전하고 있습니다.
LINE Game Platform에서 LLMOps를 개발한 이유
저희가 개발한 LLMOps 환경을 본격적으로 소개하기 앞서 LLMOps를 개발한 이유를 말씀드리려고 하는데요. LINE Game Platform의 업무 특성을 소개하면 이유를 설명하는 데 도움이 될 것 같습니다.
LINE Game Platform은 현재 30개 이상의 게임과 각 게임에서 사용하는 여러 플랫폼 기능을 지원하고 있습니다. 이때 각 게임은 모든 플랫폼 기능을 전부 도입하는 것이 아니라 필요한 것만 선택해서 도입하기 때문에 플랫폼 사용에 있어서 일괄적인 절차를 적용할 수 없습니다. 각 게임의 상황에 맞게 커스터마이징한 여러 절차를 통해 게임이 출시되고 운영됩니다. 이 과정에서 필수적으로 많은 인력이 필요한데요. 필요 인력의 규모를 줄이기 위해 여러 가지 API를 개발해 제공하고 있지만 충분하지는 않았습니다.
그런데 GPT-3.5가 출시되면서 LLM 사용이 용이해졌고 이를 사내에서도 자유롭게 활용할 수 있게 됐습니다. 기존 게임 플랫폼의 지식 베이스를 활용한 RAG와 에이전트를 통해 자연어 기반의 결과 생성을 지원하는 인하우스 도구를 개발해서 사용자 문의 대응 및 프로세스 개선에 활용해 봤습니다. 그 과정에서 여러 PoC(proof of concept, 개념 증명)를 진행했으며, 그중 이번 글에서 소개할 예시는 LINE Game Platform의 개발사 가이드 문서인 LINE Game Developers를 벡터 데이터베이스에 임베딩한 후 RAG를 사용해 개발사의 문의에 대응하는 챗봇입니다. 아래는 이 챗봇이 작동하는 모습입니다.
이 챗봇은 일반적으로 데이터셋에 포함된 내용에 대한 질문에는 잘 답변했는데요. 데이터셋의 내용과 조금만 다른 질문을 하면 엉뚱한 답변을 하는 할루시네이션 문제가 발생했습니다. 이를 막기 위해 여러 가지 처리를 하는 과정에서 답변을 고도화하는 문제뿐 아니라 작업 과정 자체와 관련된 문제들이 함께 발생했습니다.
- LLM 개발자는 전문 지식이 포함된 답변의 품질을 판단하기 어렵다.
- 전문 지식을 갖춘 사람은 개발 과정에 참여하기 어렵다.
- 작은 수정에도 답변의 변동 폭이 커서 검증하기 어렵다.
프로젝트의 구조적인 문제 역시 작업 진행에 걸림돌이 되었습니다.
- 프롬프트 체이닝(prompt chaining) 등 프롬프트 엔지니어링 과정이 프로젝트를 복잡하게 만든다.
- 기존 개발자들에게 생소한 도메인인 LLM에 대한 작업 노하우가 쉽게 공유되지 않는다.
PoC 프로젝트가 많아지면서 위와 같은 문제들이 반복적으로 발생했고, 전반적인 워크플로를 정의하기 위해 LLMOps를 함께 개발하기 시작했습니다.
LLMOps를 위해 고려한 부분
LLMOps 환경을 개발할 때 가장 중요하게 생각했던 점은 도메인 전문가도 쉽게 참여할 수 있도록 프로젝트 작업 과정의 가시성을 확보하는 것이었습니다. 도메인 전문가는 개발에 익숙하지 않을 가능성이 높기 때문에 이들이 적극적으로 프로젝트에 참여할 수 있도록 작업 과정을 시각화하는 것이 필수라고 판단했습니다.
다만 모든 과정을 시각화하는 것은 비효율적입니다. 따라서 도메인 전문가의 개입이 필요한 부분만 시각화하고 나머지 부분은 플랫폼 형태로 은닉하거나 컴포넌트로 사용할 수 있는 것을 목표로 삼았습니다. 시각화를 통해 도메인 전문가가 작업 과정에 적극적으로 참여하고, 공통화된 컴포넌트를 통해 개발자의 노하우가 프로젝트 전반에 공유될 수 있도록 도모했습니다. 이를 위해 LLM 애플리케이션을 서비스화하기 위해 필요한 과정을 개념적으로 정의했습니다.
LLM 애플리케이션을 위한 워크플로 정의
저희는 LLM 애플리케이션을 도메인 전문가가 주도해 개발할 수 있도록 LLM 애플리케이션의 개발 과정을 아래와 같이 크게 다섯 가지 단계로 분리했습니다. 그리고 도메인 전문가가 LLM 애플리케이션에 사용할 데이터 준비부터 시작해 프롬프트 작성과 애플리케이션 제작 및 배포, 최종적으로 테스트 후 결과 확인까지 엔드 투 엔드로 작업할 수 있는 환경을 구성했으며, 이를 위해 별도의 관리자용 콘솔도 구축했습니다.
그럼 각 단계에서 어떤 부분을 중점적으로 고려해 개발했는지 소개하겠습니다.
입력 단계에서 고려한 점
데이터는 AI/ML 분야에서 가장 중요한 요소 중 하나입니다. 모델을 학습하거나 테스트할 때 수집된 데이터를 활용하기 때문입니다. 정보 통신 분야에서 흔히 말하는 "Garbage In, Garbage Out"이라는 표현처럼 모델 학습에 사용하는 데이터가 부실하면 성능은 보장할 수 없습니다. LLM은 자연어를 기반으로 학습하고 테스트하기 때문에 도메인에 맞지 않는 데이터로 작업을 진행할 경우 올바른 답변을 제공하지 못할 수 있습니다.
따라서 데이터 검증은 필수입니다. 그러나 정적인 방법으로 양질의 데이터를 수집하고 판단하는 것은 어렵습니다. 특히 도메인 집약적인 데이터의 경우 더욱 그렇습니다. 따라서 도메인 전문가의 검증이 필요한데요. 일반적인 AI/ML 작업 환경에서는 대규모 데이터를 다루기 때문에 도메인 전문가가 이와 같은 작업 환경을 설치해 확인하는 것은 어렵습니다.
이를 해결하기 위해 저희는 Streamlit을 이용해 웹 환경에서 데이터를 간단하게 수집하고 검토할 수 있는 시스템을 우선적으로 개발했습니다. 아래는 저희가 개발한 시스템 화면입니다.
저희가 개발한 웹 시스템에서 제공되는 데이터셋은 끊김 없는(seamless) 개발 과정을 지원하기 위해 학습과 테스트에 쉽게 마운트할 수 있도록 설계했습니다. 이를 통해 데이터 정합성에 대해 도메인 전문가와 데이터 엔지니어가 별도로 커뮤니케이션을 진행해야 하는 부담을 줄였습니다.
또한 해당 데이터는 학습과 테스트뿐 아니라 RAG를 통해 문서 검색(document retrieval) 등의 작업도 지원할 수 있도록 다양한 컴포넌트에 연동했습니다. 이를 통해 도메인 전문가가 검증된 데이터를 기준으로 다양한 작업을 진행할 수 있게 지원하고 있습니다.
프롬프트와 애플리케이션, 배포 단계에서 고려한 점
LLM 애플리케이션에는 자연어로 명령을 내리는 '프롬프트'라는 요소가 있습니다. 그러나 자연어로 작성한다고 해서 아무렇게나 써도 되는 것은 아닙니다. LLM이 잘 이해할 수 있도록 구조화된 형태로 작성해야 하며, 이렇게 작성하기 위해서는 노하우가 필요합니다.
따라서 프롬프트는 사용자 간에 노하우를 주 고받을 수 있도록 프로젝트 구분 없이 공유할 수 있어야 하며, 프로젝트에 쉽게 적용할 수 있어야 합니다. 또한 모델마다 잘 처리할 수 있는 프롬프트가 다르기 때문에 자신의 프로젝트에 적합한 모델을 빠르게 확인할 수 있는 환경이 필요합니다.
즉, 프롬프트를 공유하고 즉시 실행해 볼 수 있는 환경을 제공하는 것이 중요한데요. 저희는 아래와 같이 사용가 간에 노하우를 공유할 수 있는 프롬프트 스토어(prompt store)를 구축하고 즉시 프롬프트를 실행할 수 있는 환경을 구성했습니다.
또한 프롬프트 엔지니어링을 통해 프롬프트를 여러 개 사용하면 프로젝트의 복잡성이 배로 올라가는데요. 이때 복잡한 로직을 쉽게 파악하고 코드를 재사용할 수 있도록 아래와 같이 LanFlow를 이용해 로직을 그래프로 시각화했습니다. 이를 통해 도메인 전문가는 로직의 흐름을 직관적으로 이해하고 재사용할 수 있으며, 개발 과정에 직접 참여할 수 있습니다.
마지막으로 쿠버네티스를 통해 LLM 애플리케이션을 쉽게 배포할 수 있도록 만들었습니다. 이를 통해 도메인 전문가는 복잡한 인프 라 설정 과정 없이 애플리케이션을 빠르고 안정적으로 배포할 수 있으며, 실제 환경에서 LLM 애플리케이션이 어떠한 답변을 내리는지 빠르게 확인할 수 있습니다.
이와 같은 통합 환경은 LLM 애플리케이션의 개발과 배포 과정을 크게 간소화해 도메인 전문가가 핵심 기능 개발에 집중할 수 있도록 도와줍니다(이를 구현한 자세한 내용은 앞서 발행한 모두를 위한 LLM 애플리케이션 개발 환경 구축 사례 글을 참고하시기 바랍니다).
테스트 단계에서 고려한 점
LLM 애플리케이션은 앞서 이야기한 것처럼 프롬프트가 조금만 바뀌어도 결과가 크게 달라질 수 있습니다. 게다가 프롬프트를 여러 개 사용하는 환경에서는 그 변화의 폭이 더 커질 수 있습니다. 따라서 LLM 애플리케이션을 작업할 때에는 반복적인 테스트를 통한 프롬프트 검증이 필수인데요. 규모가 큰 데이터 환경에서 이를 하나하나 요청하며 확인하기는 쉽지 않습니다. 프롬프트의 개수가 늘어나고 애플리케이션의 개수가 늘어나면 테스트를 위한 비용은 곱절로 늘어날 것입니다.
그렇기 때문에 LLMOps 환경에서는 이를 효과적으로 수행할 수 있도록 지원해야 했는데요. LINE Game Platform에서는 Harness를 이용해 LLM 애플리케이션의 결과를 아래와 같이 지표를 통해 어느 정도 정량화해서 도메인 전문가가 쉽게 파악할 수 있도록 만들었습니다(이를 구현한 자세 한 내용은 앞서 발행된 Harness를 이용해 LLM 애플리케이션 평가 자동화하기 글을 참고하시기 바랍니다).
프로젝트 규모와 관련해 고려한 점
이러한 워크플로를 작성하면서 컴포넌트가 하나 둘 생겨났고, LLMOps 프로젝트의 규모가 자연스럽게 커졌습니다. LINE Game Platform의 LLMOps 환경은 다수의 Python AI/ML 라이브러리를 사용하기 때문에 Python을 주 언어로 개발하고 있는데요. 순수한 Python 개발 환경은 이러한 대규모 프로젝트를 지탱하는 데 한계가 있습니다. 이에 저희는 효율적이고 안정적인 개발 환경을 갖추기 위해서 Poetry와 의존성 주입기(dependency injector)를 도입해 프로젝트 관리 및 종속성 관리를 시작했습니다(이에 대한 자세한 내용은 앞서 발행된 Poetry를 이용한 멀티 프로젝트 Python 애플리케이션 개발 방법 글을 참고하시기 바랍니다).
LLMOps 개발 후 개선된 점
LLMOps의 개발을 통해 여러 가지를 개선할 수 있었습니다.
먼저, 도메인 전문가가 LLM 애플리케이션에 보다 쉽게 접근할 수 있게 되었습니다. 이를 통해 각 전문가들이 자신의 분야에 맞는 애플리케이션을 직접 활용하고 개선할 수 있는 기회가 마련됐으며, 결과적으로 LLM의 활용도를 높이는 데 기여했습니다. 또한 직군에 상관없이 자신 의 아이디어를 직접 인하우스 툴로 구현할 수 있게 되었습니다. 이는 조직의 효율을 높이고 다양한 관점에서 문제를 바라보고 해결할 수 있는 길을 열어줬습니다. 저희 조직 구성원들은 자신의 아이디어를 실험하고 구현하는 데 필요한 도구와 환경을 얻었고, 이를 통해 보다 창의적이고 효율적으로 업무를 수행할 수 있게 되었습니다. 마지막으로 중복 개발을 줄여 개발자들이 신규 기능 개발 작업에 집중할 수 있게 되었습니다.
이와 같은 개선들이 바로 LLMOps를 구상한 초기에 달성하고자 했던 목표이며, 더욱 고도화된 LLMOps 환경을 개발하기 위한 중요한 기반이 되고 있습니다.
마치며
LLMOps 환경은 여전히 정해진 답이 없는 분야입니다. 그럼에도 저희 LINE Game Platform에서 시도한 방법들이 저희 조직에는 긍정적인 효과를 가져왔기에 이렇게 글로 공유하게 되었는데요. 저희의 경험이 여러분의 LLMOps 환경 구축에 도움이 되기를 바라며 이만 마치겠습니다. 긴 글 읽어주셔서 감사합니다.