🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Dosu는 생산 환경 LLM 제품의 신뢰성을 높이기 위해 변경의 영향을 평가 데이터로 검증하는 EDD를 도입했고, LangSmith로 모니터링·검색·실패 사례 수집을 확장했다.

📌 핵심 요약

• 이 글은 Dosu CEO Devin Stein의 기고문으로, 확률적 함수에 기반한 LLM 제품에서 신뢰성을 확보하는 일이 어렵다는 문제의식에서 출발한다.
• Dosu는 오픈소스 유지보수자가 겪는 지원 부담과 개발자들의 비코딩 업무를 줄이기 위해 만들어진 AI 엔지니어링 팀메이트이며, 코드베이스 질문·이슈 대응·지원 업무를 돕는다.
• 초기에는 사용량이 적어 grep과 print 문으로 모든 응답을 직접 확인했지만, 프롬프트나 LLM 로직의 작은 변경이 어떤 영역에서는 개선을, 다른 영역에서는 회귀를 일으킬 수 있다는 문제가 드러났다.
• Dosu는 EDD를 통해 새 동작을 평가 사례로 정의하고, 프로덕션에서 실패 모드를 찾은 뒤, 그 사례를 오프라인 평가 데이터에 추가하며 반복 개선하는 절차를 세웠다.
• 사용량이 수천 개 저장소로 확대되자 LangSmith SDK의 traceable 데코레이터와 검색 기능을 활용해 함수 입력, 렌더링된 프롬프트, LLM 출력, 오류·지연·감성·사용자 피드백을 추적하고 평가 데이터 수집을 자동화하는 방향으로 발전시키고 있다.

🧩 주요 포인트

1. 이 글은 Dosu CEO Devin Stein의 기고문으로, 확률적 함수에 기반한 LLM 제품에서 신뢰성을 확보하는 일이 어렵다는 문제의식에서 출발한다.
2. Dosu는 오픈소스 유지보수자가 겪는 지원 부담과 개발자들의 비코딩 업무를 줄이기 위해 만들어진 AI 엔지니어링 팀메이트이며, 코드베이스 질문·이슈 대응·지원 업무를 돕는다.
3. 초기에는 사용량이 적어 grep과 print 문으로 모든 응답을 직접 확인했지만, 프롬프트나 LLM 로직의 작은 변경이 어떤 영역에서는 개선을, 다른 영역에서는 회귀를 일으킬 수 있다는 문제가 드러났다.
4. Dosu는 EDD를 통해 새 동작을 평가 사례로 정의하고, 프로덕션에서 실패 모드를 찾은 뒤, 그 사례를 오프라인 평가 데이터에 추가하며 반복 개선하는 절차를 세웠다.
5. 사용량이 수천 개 저장소로 확대되자 LangSmith SDK의 traceable 데코레이터와 검색 기능을 활용해 함수 입력, 렌더링된 프롬프트, LLM 출력, 오류·지연·감성·사용자 피드백을 추적하고 평가 데이터 수집을 자동화하는 방향으로 발전시키고 있다.

🧠 상세 정리

1. 생산 환경 LLM 제품에서 신뢰성이 어려운 이유

글은 생산 수준의 LLM 제품을 만드는 일이 어렵다는 현실에서 시작한다. 일반적인 제품도 신뢰성이 중요하지만, LLM 제품은 확률적인 함수들의 연쇄 위에 세워지기 때문에 같은 방식으로 안정성을 보장하기 어렵다. Dosu 팀은 제품을 계속 반복 개선하고 있었고, 매번 변경이 실제 최종 사용자에게 어떤 영향을 주는지 이해해야 했다. 이때 평가 주도 개발, 즉 EDD는 변경을 자신 있게 배포하기 위한 기준으로 제시된다. 글의 핵심은 Dosu가 EDD를 실천하는 과정에서 LangSmith를 이용해 활동을 모니터링하고 검색하며 그 흐름을 확장했다는 점이다.

2. Dosu가 해결하려는 문제

Dosu는 소프트웨어 프로젝트의 개발, 유지보수, 지원을 돕는 AI 엔지니어링 팀메이트로 소개된다. 글쓴이는 오픈소스 유지보수자로 일하면서 프로젝트가 커질수록 새 기능 개발보다 지원 업무에 더 많은 시간을 쓰게 되는 문제를 겪었다. 유지보수자는 반복적인 질문 대응, 이슈 분류, PR 처리 부담 때문에 번아웃에 이르기도 하고, 때로는 열린 이슈와 PR을 모두 닫는 ‘이슈 파산’을 선언하기도 한다. 오픈소스 커뮤니티 역시 관리자의 응답을 며칠, 몇 주, 몇 달씩 기다리는 불편을 겪는다. Dosu는 이런 부담을 개발자에게서 덜어내고, 커뮤니티 구성원에게는 코드가 답할 수 있는 질문에 대해 즉각적인 피드백을 주는 역할을 목표로 한다.

3. 초기 운영 방식과 직접 관찰의 가치

Dosu는 2023년 6월 말에 출시되었고, 초기에는 사용량이 충분히 낮아 팀이 모든 응답을 직접 살펴볼 수 있었다. 당시 팀은 grep과 print 문만으로 로그를 훑으며 개선할 부분을 찾아냈다. 이 과정은 매우 수고로운 작업이었지만, Dosu의 아키텍처를 설계하고 개발하는 데 중요한 기반이 되었다. 팀은 사람들이 Dosu를 어떻게 사용하려 하는지, 어떤 요청에서 잘 작동하는지, 어떤 요청에서 부족한지를 깊이 이해할 수 있었다. 그러나 제품이 개선될수록 단순 관찰만으로는 변경 효과를 체계적으로 판단하기 어렵다는 문제가 나타났다.

4. 프롬프트와 LLM 로직 변경의 회귀 문제

글은 전통적인 코드 변경과 LLM 로직 변경의 차이를 강조한다. 일반 코드에서는 특정 수정의 영향 범위를 비교적 명확히 추적할 수 있지만, LLM에서는 작은 프롬프트 조정이 전체 성능에 어떤 영향을 줄지 예측하기 어렵다. Dosu 팀은 실제로 어떤 프롬프트의 사소한 변경이 한 영역에서는 더 나은 결과를 만들면서도 다른 영역에서는 성능 저하를 일으키는 사례를 여러 번 보았다. 따라서 팀은 잘하고 있던 영역의 성능은 유지하면서, 부족했던 영역의 성능을 개선하고 있는지 확인할 측정 방법이 필요했다. 이 필요성이 Dosu가 평가 주도 개발을 도입하게 된 직접적인 배경이다.

5. EDD가 Dosu에 적용된 방식

EDD는 테스트 주도 개발처럼 개발자가 지향할 목표를 제공하는 방식으로 설명된다. 여기서 평가, 즉 eval은 Dosu의 핵심 로직, 모델, 프롬프트에 대한 변경과 새 기능의 영향을 이해하기 위한 기준선 역할을 한다. Dosu의 절차는 먼저 소수의 초기 평가 사례로 새 동작을 만들고, 이를 사용자에게 출시한 뒤, 프로덕션 결과를 모니터링해 실패 모드를 찾는 순서로 구성된다. 발견한 실패 모드마다 예시를 오프라인 평가 데이터에 추가하고, 갱신된 평가를 기준으로 성능을 개선한 다음 다시 배포한다. 이 반복 루프가 초기 Dosu에서는 잘 작동했지만, 사용량이 증가하면서 활동을 따라잡기 어려워졌다.

6. 규모가 커지며 생긴 모니터링 한계와 도구 요구사항

현재 Dosu는 수천 개 저장소에 설치되어 하루 종일 응답을 생성하는 수준으로 성장했다고 설명된다. 팀은 다양한 상황을 지능적으로 처리하기 위해 수십 개의 하위 모듈을 만들었고, 모델과 연구 흐름이 발전함에 따라 문제 해결 접근도 계속 반복하고 있다. 그러나 활동량이 늘어나자 프로덕션 응답을 모니터링하고 실패 모드를 식별하는 일이 거의 불가능해졌고, 이는 EDD 워크플로에 핵심적인 장애가 되었다. Dosu 팀은 프롬프트를 코드처럼 Git에 보관할 수 있고, LLM 요청 사이의 메타데이터까지 추적하며, 기존 평가 데이터와 도구를 유지할 수 있는 모니터링 스택을 원했다. 또한 LLM 애플리케이션을 만드는 표준 방식이 아직 고정되어 있지 않기 때문에, 추적할 메타데이터를 제어하고 도구를 필요에 맞게 확장할 수 있어야 했다.

7. LangSmith SDK 도입과 추적 가시성

Dosu 팀이 LangSmith에서 가장 매력적으로 본 것은 UI나 기능 목록보다 SDK가 제공하는 세밀한 제어와 사용자화 가능성이었다. LangSmith를 시험하기 위해 팀은 LLM 관련 함수 몇 곳에 @traceable 데코레이터를 추가했으며, 몇 분 만에 계측을 마치고 프로덕션에 반영했다. 변경이 배포되자 LangSmith UI로 trace가 즉시 들어오기 시작했고, Dosu 활동 전반을 볼 수 있는 가시성이 생겼다. 특히 @traceable 데코레이터는 함수 trace와 LLM 호출 trace를 함께 전송할 수 있어, 원시 함수 입력, 렌더링된 프롬프트 템플릿, LLM 출력을 하나의 trace에서 확인하게 해주었다. 이 가시성은 실패 모드를 찾아 EDD 흐름에 다시 연결하기 위한 기반이 되었다.

8. 실패 모드 탐지와 평가 데이터 확장

Dosu가 받는 요청은 코드베이스에 대한 단순 질문부터 새 라이브러리 버전 업그레이드 중 생긴 오류 trace, 기능 상태 질문까지 다양하다. 입력의 종류가 많아질수록 Dosu가 잘 처리하지 못하는 실패 모드도 늘어난다. 팀은 명시적 좋아요·싫어요 피드백, GitHub 이슈에서 드러나는 사용자 감성, 입력이나 출력 크기 문제와 스키마 불일치 같은 내부 오류, 응답 시간 지연 등을 신호로 삼는다. LangSmith의 고급 검색 기능은 이런 기준으로 이상 행동을 찾아내게 해주며, 추가 메타데이터를 trace에 붙여 검색 능력을 더 넓힐 수 있게 한다. 실제로 팀은 사용자가 수천 줄의 로그나 OpenAI 임베딩의 원시 float 값을 공유했을 때 응답이 매우 느려지는 패턴을 찾았고, PR 라벨링 요청에 Dosu가 콘서트 이야기를 해버린 사례도 발견했다.

9. 자동 평가 데이터 수집과 반복 개선의 선순환

실패 모드를 발견한 뒤 Dosu 팀의 EDD 흐름은 다시 기존 절차로 돌아간다. LangSmith에서 추가 예시를 검색하고, 그 예시를 평가 데이터셋에 넣은 뒤, 평가를 기준으로 반복 개선하고 새 버전의 Dosu를 배포한다. 글의 후반부는 Dosu 팀이 LangSmith를 더 사용자화해 프로덕션 트래픽에서 평가 데이터셋을 자동으로 만들려 한다고 설명한다. 목표는 엔지니어들이 대화 주제, 사용자 세그먼트, 요청 범주 등을 기준으로 평가 데이터셋을 쉽게 큐레이션하도록 만드는 것이다. 또한 LangSmith가 Dosu 개선 속도를 높이고, 개선된 Dosu가 LangChain 팀의 유지보수와 지원 부담을 줄이며, 그 결과 LangSmith 기능 개발 시간이 늘어나는 선순환도 언급된다.

🧾 핵심 주장 / 시사점

• LLM 제품의 신뢰성은 단순히 프롬프트를 잘 쓰는 문제가 아니라, 변경이 기존 강점과 약점에 어떤 영향을 주는지 지속적으로 측정하는 운영 체계의 문제로 다뤄진다.
• EDD의 핵심은 프로덕션에서 발견한 실제 실패를 오프라인 평가 데이터로 되돌려 넣는 루프이며, 이 루프가 있어야 개선과 회귀를 동시에 관리할 수 있다.
• LangSmith가 Dosu에 제공한 가치는 단순 로그 수집이 아니라 함수 입력, 프롬프트, LLM 출력, 피드백, 오류, 지연, 메타데이터를 검색 가능한 trace로 묶어 실패 탐지와 평가 데이터 확장을 가능하게 한 점이다.

✅ 액션 아이템

• Dosu가 도입한 EDD 방식처럼 동작 변경 전후에 평가 사례를 고정해 새 기능 영향을 먼저 점검하고, 실패 구간을 오프라인 데이터셋에 즉시 반영한다.
• LangSmith traceable 데코레이터와 검색을 조합해 함수 입력·렌더링 프롬프트·LLM 출력·오류·지연·감성 피드백을 함께 추적해 실패 원인 단위를 분해한다.
• 지원 부하를 줄이기 위해 Dosu가 해결한 코드베이스 질문·이슈 대응 맥락에서 비코딩 업무 처리율과 응답 품질을 함께 모니터링한다.

❓ 열린 질문

• 작은 프롬프트/LLM 로직 변경이 일부 기능에서 개선을 만들면서 다른 기능에서 회귀를 유발할 때 우선순위 판단 기준은 무엇인가?
• LangSmith로 수집한 오류·지연·감성 지표를 몇 주 간격으로 오프라인 평가셋 업데이트에 반영하면 EDD 개선 속도를 최적화할 수 있는가?
• 수천 개 저장소 규모의 부하에서 grep·print 방식 대비 traceable 기반 모니터링이 어떤 실패 패턴 탐지 우위를 실제로 제공하는지 어떻게 측정할 것인가?