평가 주도 개발(Evaluation Driven Development)을 통한 LLM 신뢰성 확보 과정
요약
Dosu는 오픈 소스 소프트웨어 유지관리의 비코딩 업무 부담을 줄여주는 AI 팀원입니다. Dosu 팀은 LLM의 확률적 특성으로 인한 신뢰성 문제를 해결하기 위해 '평가 주도 개발(Evaluation Driven Development, EDD)' 방식을 도입하여 제품의 성능을 지속적으로 개선하고 있습니다.
핵심 포인트
- LLM 기반 제품의 신뢰성 확보를 위해 평가 주도 개발(EDD) 방법론이 필수적임
- Dosu는 개발자의 비코딩 업무(이슈 분류, 질문 응답 등)를 자동화하여 개발 몰입도를 높임
- 프롬프트 수정 시 특정 영역의 개선이 다른 영역의 성능 퇴보(regression)를 유발할 수 있음
- LangSmith를 활용하여 LLM의 활동을 모니터링하고 EDD 프로세스를 확장함
*편집자 주: 다음은 Dosu의 CEO인 Devin Stein이 작성한 게스트 블로그 포스트입니다. Dosu는 소프트웨어 개발, 유지보수 및 지원을 돕는 엔지니어링 팀원입니다.
현 시점에서 프로덕션 등급(production-grade)의 LLM 제품을 구축하는 것이 어렵다는 사실은 잘 알려져 있습니다. 어떤 제품이 성공하기 위해서는 신뢰성(Reliability)이 매우 중요하지만, 제품이 일련의 확률적 함수(probabilistic functions)를 기반으로 작동할 때 신뢰성을 보장하는 것은 결코 간단하지 않습니다.
Dosu에서 우리는 지속적으로 제품을 반복 개선하고 있습니다. 우리가 수행하는 모든 변경 사항에 대해 최종 사용자에게 미치는 영향을 이해해야 합니다. 평가 주도 개발 (Evaluation Driven Development, EDD)은 우리가 확신을 가지고 제품을 출시할 수 있게 해줍니다. 지난 몇 달 동안 LangSmith는 Dosu의 활동을 쉽게 모니터링하고 검색할 수 있게 함으로써 우리가 EDD를 확장할 수 있도록 지원해 주었습니다.
Dosu란 무엇인가?
LangChain GitHub 저장소에서 시간을 보내본 적이 있다면, 소프트웨어 프로젝트의 개발, 유지보수 및 지원을 돕는 AI 팀원인 Dosu를 이미 만나보셨을 수도 있습니다.
Dosu는 보람차지만 시간 소모가 많기로 악명 높은 역할인 오픈 소스 소프트웨어 유지관리자(maintainer)로 활동하던 시절의 경험에서 탄생했습니다. 제가 운영하는 오픈 소스(OSS) 프로젝트의 인기가 높아짐에 따라, 새로운 기능을 개발하는 대신 지원 업무에 훨씬 더 많은 시간을 소비하고 있는 저 자신을 발견했습니다.
유지관리자들에게 이러한 책임은 빈번하게 번아웃(burnout)을 유발하며, 일부는 모든 열린 이슈(issue)와 PR(Pull Request)을 단순히 닫아버리는 과정인 '이슈 파산(issue bankruptcy)'을 선언하게 만들기도 합니다. 오픈 소스(OSS) 커뮤니티 또한 이러한 상황으로 인해 고통받으며, 사람들은 유지관리자가 자신의 이슈에 응답하기를 며칠, 몇 주, 심지어 몇 달씩 기다리기도 합니다.
이러한 현상은 오픈 소스에만 국한되지 않습니다. 업계 내에서도 개발자 시간의 최대 85%가 즉석 질문에 답하기, 이슈 분류(triaging), 오버헤드 처리와 같은 비코딩(non-coding) 작업에 소비됩니다.
Dosu는 이러한 작업들을 개발자의 부담에서 덜어줌으로써, 개발자들이 자신이 좋아하는 일, 즉 몰입 상태(flow)를 유지하며 코드를 작성하고 훌륭한 기능을 출시하는 데 집중할 수 있도록 합니다. 동시에 Dosu는 오픈 소스 소프트웨어 (OSS) 커뮤니티의 자원이 되어, 커뮤니티 구성원들이 예기치 못한 문제에 직면하거나 코드만이 답할 수 있는 새로운 질문이 생길 때마다 즉각적인 피드백을 제공합니다.
초기 단계
Dosu는 2023년 6월 말에 출시되었습니다. 당시에는 처리량이 매우 적어서 모든 응답을 하나하나 검토할 수 있었습니다. 매일 우리는 단지 grep과 print 문만을 사용하여 로그를 세밀하게 조사하며 개선이 필요한 부분을 식별했습니다.
그 작업은 매우 고통스러웠지만, Dosu의 아키텍처 (architecture)를 설계하고 개발하는 데 있어 매우 중요했습니다. 이를 통해 우리 팀은 사람들이 Dosu를 어떻게 사용하려고 하는지, 어떤 유형의 요청에 탁월한 성능을 보이는지, 그리고 어떤 부분에서 부족한지를 깊이 이해할 수 있었습니다.
개선해야 할 점이 무엇인지 파악하고 나면, 다음 질문은 '어떻게 개선할 것인가'였습니다. 전통적인 코드 업데이트와 달리, LLM 로직을 변경하는 것은 간단하지 않습니다. 작은 변화가 전체 성능에 어떤 영향을 미칠지 알기 어렵기 때문입니다. 우리는 프롬프트 (prompt)를 약간 수정했을 때 한 영역에서는 더 나은 결과를 가져오지만, 다른 영역에서는 성능 퇴보 (regression)를 일으키는 경우를 자주 목격했습니다.
우리는 변경 사항의 영향을 측정할 방법이 필요했습니다. 모든 변경 사항에 대해 우리는 다음 사항을 반드시 확인하고자 했습니다:
- 잘 수행하고 있는 영역에서의 성능 유지
- 어려움을 겪고 있는 영역에서의 성능 향상
우리가 진행 상황을 벤치마킹하기 위해 평가 주도 개발 (evaluation driven development)로 눈을 돌린 것은 바로 이 초기 단계였습니다.
평가 주도 개발 (Evaluation Driven Development)
테스트 주도 개발 (TDD)과 마찬가지로, 평가 주도 개발 (EDD)은 우리가 개발해 나가야 할 최종 목표를 제시합니다. 평가(evaluations)
- 소수의 초기 평가(evals)를 통해 새로운 동작(behavior)을 생성합니다.
- 새로운 동작을 사용자에게 출시합니다.
- 프로덕션(production) 환경에서 결과를 모니터링하고 실패 모드(failure modes)를 식별합니다.
- 각 실패 모드에 대한 예시를 오프라인 평가(offline evals)에 추가합니다.
- 성능 향상을 위해 업데이트된 평가를 반복(iterate)합니다.
- 재출시 및 반복
이러한 개발 워크플로(workflow)는 Dosu가 시작되었을 때 우리에게 효과적이었지만, 사용량이 증가함에 따라 Dosu의 활동량을 따라가는 것이 어려워졌습니다.
규모 확장 시 높은 품질 기준 유지하기
현재 Dosu는 수천 개의 리포지토리(repositories)에 설치되어 있으며 하루 중 언제라도 응답을 생성합니다. 우리는 다양한 유형의 시나리오를 지능적으로 처리하기 위해 수십 개의 서브모듈(submodules)을 구축했으며, 모델과 해당 분야의 연구가 진화함에 따라 문제 해결 방식에 대해 끊임없이 반복(iterating)하고 있습니다.
Dosu의 성장은 흥미로웠지만, 그에 따른 과제도 따랐습니다. Dosu의 활동이 증가하면서 프로덕션 환경에서 응답을 모니터링하고 실패 모드(failure modes)를 식별하는 것이 거의 불가능해졌는데, 이는 우리의 평가 주도 개발(EDD) 워크플로에서 매우 중요한 부분입니다.
우리는 LLM 모니터링 스택(monitoring stack)을 업그레이드할 때가 되었다고 결정했습니다. 우리는 Dosu의 활동을 모니터링하는 데 도움이 될 뿐만 아니라, 기존 워크플로에 맞출 수 있을 만큼 유연한 도구를 찾았습니다. 우리의 기준 중 일부는 다음과 같았습니다:
- 프롬프트(Prompts)는 Git에 존재해야 함 — EDD의 정신에 따라, 우리는 프롬프트를 코드(code)로 취급합니다. 프롬프트에 대한 모든 변경 사항은 코드 변경과 동일한 표준으로 처리되어야 합니다.
- 코드 수준의 트레이싱(Code-level tracing) — Dosu는 단순히 일련의 LLM 요청 그 이상입니다. 우리는 단일 트레이스(trace) 내에서 LLM 요청 간의 메타데이터(metadata)를 추적하기를 원했습니다.
- 데이터 내보내기 용이성 — 우리는 유지하고 싶은 기존의 평가 데이터셋(evaluation datasets)과 툴링(tooling)을 보유하고 있었습니다.
- 맞춤 설정 및 확장 가능성 — LLM 분야는 빠르게 진화하고 있습니다. LLM 애플리케이션을 구축하는 표준화된 방법은 없습니다. 우리는 어떤 메타데이터를 추적할지 제어할 수 있기를 원했으며, 우리의 요구 사항을 충족하도록 도구를 맞춤화할 수 있는 능력을 원했습니다.
우리는 우리의 요구 사항을 충족하는 제품을 찾기 위해 LLM 모니터링 및 평가(monitoring and evaluation) 환경을 탐색했습니다. 우리의 초기 파트너 중 하나인 LangChain 팀과의 통화 이후, LangSmith가 모든 요구 사항을 충족하는 것으로 보여 매우 기뻤습니다.
SDK를 통한 LangSmith 구현
우리를 가장 흥분하게 만든 것은 LangSmith의 매끄러운 UI나 광범위한 기능 세트가 아니라, 바로 SDK였습니다. LangSmith SDK는 우리가 찾고 있던 세밀한 제어(fine-grain controls)와 맞춤화(customizability) 기능을 제공했습니다.
LangSmith를 테스트하기 위해, 우리는 LLM 관련 함수 몇 개에 @traceable 데코레이터(decorator)를 추가하기만 하면 되었습니다. 계측(instrument)하는 데 단 몇 분밖에 걸리지 않았으며, 이러한 변경 사항을 프로덕션(production)에 푸시하자마자 LangSmith UI로 트레이스(traces)가 쏟아져 들어오는 것을 즉시 확인할 수 있었습니다.
@traceable 데코레이터의 예상치 못한 놀라운 기능은 함수와 LLM 호출 트레이스를 모두 LangSmith로 보낼 수 있다는 점입니다. 이를 통해 우리는 LangSmith UI의 단일 트레이스 내에서 가공되지 않은 함수 입력(raw function inputs), 렌더링된 프롬프트 템플릿(rendered prompt templates), 그리고 LLM 출력(LLM output)을 모두 확인할 수 있습니다.
LangSmith는 별도의 설정 없이도 Dosu의 모든 활동에 대한 가시성(visibility)을 제공했습니다. 다음 단계는 LangSmith를 활용하여 실패 모드(failure modes)를 식별하고 이를 우리의 EDD 워크플로에 통합하는 것이었습니다.
실패 식별하기
Dosu는 사용자로부터 수많은 요청을 받습니다. 코드베이스에 대한 간단한 질문부터 새로운 라이브러리 버전으로 업그레이드할 때 발생하는 에러 트레이스(error traces), 그리고 기능의 상태를 묻는 질문에 이르기까지 매우 다양합니다. Dosu가 받을 수 있는 입력값이 많다는 것은 발생 가능한 실패 모드도 더 많다는 것을 의미합니다.
실패 모드, 즉 Dosu가 제대로 처리하지 못하는 요청을 식별하려고 할 때, 우리는 다음과 같은 다양한 신호(signals)를 살펴볼 수 있습니다:
- 명시적 피드백 (Explicit Feedback): ChatGPT를 통해 대중화된 전형적인 따봉(thumbs up/down) 피드백입니다.
- 사용자 감성 (User Sentiment): 사용자가 GitHub 이슈에서 Dosu와 상호작용할 때, 그들의 응답은 보통 Dosu가 도움이 되었는지 여부를 보여줍니다.
- 내부 오류 (Internal Errors): LLM은 여러 가지 이유로 실패할 수 있습니다. 입력 또는 출력이 너무 컸나요? 생성된 응답이 원하는 스키마 (schema)와 일치하지 않았나요?
- 응답 시간 (Response Time): Dosu에서는 속도보다 품질을 우선시하지만, 응답이 왜 느린지 이해하는 것도 중요합니다. 어떤 요청은 빠른 응답을 필요로 하는 반면, 어떤 요청은 느리더라도 더 정밀한 응답을 필요로 합니다.
LangSmith의 고급 검색 기능은 비정상적인 동작을 식별하는 것을 쉽게 만들어 줍니다. 우리는 다음과 같은 다양한 기준을 사용하여 검색을 수행할 수 있습니다: 명시적 사용자 피드백, 최근 오류 사례, 응답 시간 지연 또는 부정적인 감성 등입니다. 또한 LangSmith를 사용하면 각 트레이스 (trace)에 추가적인 메타데이터 (metadata)를 첨부하여 검색 기능을 더욱 확장할 수 있습니다.
우리는 이미 예상치 못한 여러 실패 모드 (failure modes)를 식별했습니다. 예를 들어, 사용자가 수천 줄의 로그나 OpenAI 임베딩 (embedding)의 가공되지 않은 부동 소수점 (float) 값을 공유할 때 응답이 극도로 느려지는 패턴을 발견했습니다.
우리 팀이 가장 좋아했던 실패 사례 중 하나는 Dosu에게 풀 리퀘스트 (pull request)에 라벨을 달아달라고 요청했을 때 발생했습니다. Dosu는 풀 리퀘스트에 라벨을 다는 대신, 그날 밤 자신이 가고 싶어 열광하는 콘서트에 대해 사용자에게 이야기하기로 결정했습니다. Dosu가 스위프티 (Swiftie, 테일러 스위프트의 팬)인지에 대해서는 아직 결론이 나지 않았습니다.
일단 실패 모드를 찾으면, EDD 워크플로우는 이전과 동일합니다.
- LangSmith에서 추가 사례를 검색합니다.
- 이를 평가 데이터셋 (eval datasets)에 추가합니다.
- 평가를 통해 반복 (iterate)합니다.
- Dosu의 새 버전을 배포하고, 이 과정을 반복합니다.
평가 데이터셋 수집 자동화
Dosu의 평가 주도 개발 (Evaluation Driven Development)의 미래는 밝습니다. 저희 팀은 프로덕션 트래픽 (production traffic)으로부터 평가 데이터셋 (evaluation datasets)을 자동으로 구축할 수 있도록 LangSmith를 더욱 커스텀하고 있습니다. Dosu의 엔지니어들이 대화 주제, 사용자 세그먼트 (user segments), 요청 카테고리 (request categories) 등을 기반으로 데이터셋을 큐레이션 (curate)하는 과정을 최대한 단순하게 만들고자 합니다.
Dosu와 LangChain의 협업에는 흥미로운 플라이휠 효과 (flywheel effect)가 존재합니다. LangSmith는 저희가 Dosu의 성능을 개선하기 위해 더 빠르게 반복 (iterate)할 수 있도록 돕습니다. Dosu의 개선은 LangChain 팀의 유지보수 및 지원 부담을 직접적으로 줄여주며, 이를 통해 LangChain 팀이 LangSmith의 기능을 출시하는 데 더 많은 시간을 할애할 수 있게 하여 결과적으로 Dosu의 개발 속도를 높여줍니다. 그리고 이 과정은 계속됩니다!
추신: Dosu는 채용 중입니다! jobs*@dosu.dev*로 연락주세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 LangChain Blog의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기