LangChain State of AI 2023

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

2023년 하반기 LangSmith의 익명 사용 데이터는 LLM 애플리케이션 개발이 검색, 맞춤형 구성, 다중 평가를 중심으로 진행됐으며 에이전트는 신뢰성과 성능 제약으로 제한적으로 채택됐음을 보여준다.

📌 핵심 요약

• 분석은 2023년 7월 2일부터 12월 11일까지 수집된 LangSmith 익명 메타데이터를 기반으로 하며, 전체 사용량의 약 15%는 LangChain을 사용하지 않는 이용자에게서 발생했다.
• 복합 쿼리의 42%가 검색을 포함해 자체 데이터와 LLM을 결합하는 주된 방식으로 자리 잡은 반면, 에이전트가 포함된 비율은 약 17%로 신뢰성과 성능 문제가 확산을 제한했다.
• LLM 제공자는 OpenAI와 AzureOpenAI가 선두였고, 오픈소스 모델은 Hugging Face·LlamaCpp·Ollama·GPT4All을 통한 로컬 실행이 두드러졌으며 벡터 저장소도 Chroma·FAISS·Qdrant·DocArray 같은 로컬 제품의 사용이 많았다.
• LCEL은 복잡하고 맞춤화된 체인 구성을 쉽게 만들어 사용량이 빠르게 증가했으며, 고급 검색에서는 기본 제공 방식보다 애플리케이션별 맞춤 검색 전략이 가장 많이 사용됐다.
• 시험 실행의 83%에는 피드백이 연결됐고 피드백이 있는 실행은 평균 2.3종의 평가를 사용했으며, LLM 기반 평가가 다수를 차지하고 맞춤 평가자도 약 40%에 달해 단일 범용 지표의 한계를 드러냈다.

🧩 주요 포인트

1. 검색은 복합 쿼리의 42%를 차지했지만 에이전트는 17%에 그쳐, 데이터 결합은 보편화된 반면 자율적 단계 결정은 신뢰성과 성능 제약을 받았다.
2. OpenAI·AzureOpenAI의 선두와 오픈소스 모델 및 로컬 벡터 저장소의 높은 사용량은 호스팅 서비스 활용과 로컬·무료 실험이 함께 진행됐음을 보여준다.
3. 피드백 적용률 83%, 평균 2.3종의 평가, 맞춤 평가자 약 40%라는 결과는 LLM 애플리케이션의 정확성을 하나의 지표만으로 판정하기 어렵다는 의미를 갖는다.

🧠 상세 정리

1. 2023년 생성형 AI 확산과 분석 배경

2023년에는 ChatGPT의 확산을 계기로 생성형 AI에 대한 관심이 급증했고, 스타트업부터 대기업까지 각자의 생성형 AI 전략을 찾고 있었다. 기업들이 제기한 핵심 문제는 제품에 생성형 AI를 통합하는 방법, 따라야 할 참조 아키텍처, 용도에 적합한 모델과 기술 스택, LLM 애플리케이션 시험 방식이었다. 불확실성이 큰 상황에서 각 조직은 다른 팀이 실제로 무엇을 만들고 어떤 기술을 사용하는지도 알고 싶어 했다. LangChain 팀은 이러한 요구를 파악하기 위해 LangSmith에서 수집된 익명화 메타데이터를 분석 근거로 사용했다. 통계 범위는 2023년 7월 2일부터 12월 11일까지이며, 사람들이 무엇을 만들고 어떻게 구성하며 어떤 방식으로 시험하는지를 중심으로 결과를 정리했다.

2. LangSmith 사용 범위와 주요 애플리케이션 유형

LangSmith는 추적, 회귀 시험, 평가 기능 등을 제공해 프로토타입을 운영 단계로 옮기는 과정을 지원하는 클라우드 플랫폼으로 소개됐다. LangChain과 긴밀하게 통합되지만 LangChain 외부에서도 사용할 수 있으며, 실제 LangSmith 사용량의 약 15%가 LangChain을 사용하지 않는 이용자에게서 발생했다. 복합 쿼리 가운데 42%는 관련 문맥을 가져오는 검색을 포함해, 자체 데이터와 LLM을 결합하는 대표적인 구현 방식으로 나타났다. LangChain은 60개가 넘는 벡터 저장소 연동과 여러 고급 검색 전략을 제공하며 이러한 사용 방식을 지원했다. 반면 LLM이 수행 단계를 결정하는 에이전트는 복합 쿼리의 약 17%에 포함됐고, 글은 신뢰성과 성능이 충분하지 않은 점을 더 높은 채택을 막는 요인으로 해석했다.

3. LCEL과 맞춤형 체인 구성

LangChain Expression Language인 LCEL은 여러 구성 요소를 조합해 복잡하고 맞춤화된 체인을 만드는 방법으로 최근 몇 달 사이 추가된 주요 기능이다. 글은 생성형 AI 활용 방식이 아직 정립되지 않은 초기 단계이기 때문에 개발팀이 다양한 구성으로 반복적인 실험과 맞춤화를 수행하고 있다고 설명한다. LCEL은 구성 요소를 연결하고 변경하는 과정을 단순화해 이러한 실험에 적합한 수단으로 제시됐다. 기능이 추가되고 관련 문서가 개선되면서 LCEL 사용량도 몇 달 동안 빠르게 증가했다. 글에서 이 증가세는 모든 애플리케이션에 동일한 체인을 적용하기보다 각 목적에 맞춰 구성 요소를 선택하고 조합하려는 개발 경향을 보여주는 사용 지표로 다뤄진다.

4. LLM 제공자와 오픈소스 모델 접근 방식

LLM 제공자 순위에서는 OpenAI가 가장 많은 사용자를 확보했고 AzureOpenAI가 바로 뒤를 이었으며, Anthropic과 Vertex AI도 상위권에 포함됐다. 오픈소스 모델과 상호작용하는 주요 경로로는 Hugging Face가 4위, Fireworks AI가 6위, Ollama가 7위로 제시됐다. 오픈소스 모델만 보면 이용자는 Hugging Face, LlamaCpp, Ollama, GPT4All 같은 도구를 활용해 모델을 로컬에서 직접 실행하는 경우가 많았다. 오픈소스 모델에 응용 프로그램 인터페이스로 접근할 수 있게 하는 제공자 중에서는 Fireworks AI가 선두였고 Replicate, Together, Anyscale이 뒤를 이었다. 이 순위는 처리량이나 품질 비교가 아니라 각 제공자를 한 번이라도 사용한 이용자 수를 기준으로 산정됐다는 제한이 함께 명시됐다.

5. 벡터 저장소와 임베딩 선택

검색이 LLM 애플리케이션의 큰 비중을 차지하면서 관련 문맥을 찾는 기반인 벡터 저장소의 선택도 주요 분석 대상이 됐다. 60개가 넘는 LangChain 연동 제품 가운데 Chroma, FAISS, Qdrant, DocArray 같은 로컬 벡터 저장소가 모두 상위 5개 안에 들었으며, 이용자 수 기준에서는 로컬·무료 제품이 유리할 수 있다고 설명됐다. 호스팅 제품 중에서는 Pinecone이 유일하게 상위 5개에 포함됐고 Weaviate가 뒤를 이어, 벡터 전용 데이터베이스가 기존 데이터베이스에 벡터 기능을 추가한 방식보다 더 많이 사용됐다. 기존 데이터베이스 계열에서는 Postgres의 PGVector, Supabase, Neo4j, Redis, Azure Search, Astra DB가 앞선 제품으로 제시됐다. 임베딩은 OpenAI가 가장 많이 사용됐고 Hugging Face가 2위였으며, GPT4All과 Ollama도 상위 8개에 포함돼 LLM 제공자 순위보다 선택지가 더 분산된 모습을 보였다.

6. 맞춤형 고급 검색 전략

글은 임베딩 사이의 코사인 유사도만 계산하는 기본 검색으로는 충분하지 않은 경우가 많아 개발자들이 여러 고급 검색 전략을 사용한다고 설명한다. 가장 흔한 전략은 LangChain에 미리 포함된 방식이 아니라 사용자가 직접 구현한 맞춤 검색이었으며, 이는 맞춤 로직을 구현하기 쉽다는 점과 높은 성능을 위해 애플리케이션별 처리가 필요하다는 점을 함께 보여줬다. Self Query는 사용자의 질문에서 메타데이터 필터를 추출하고, Hybrid Search는 주로 Supabase와 Pinecone 같은 제공자별 연동을 통해 사용됐다. Contextual Compression은 기본 검색 결과를 후처리해 문맥을 압축하는 방식으로 소개됐다. Multi Query는 하나의 질의를 여러 질의로 변환해 각각의 결과를 검색하고, TimeWeighted VectorStore는 최근 문서에 더 높은 우선순위를 부여하는 전략으로 정리됐다.

7. 평가 지표와 시험 방식

평가와 시험은 LLM 애플리케이션을 만드는 개발자들이 겪는 가장 큰 어려움 가운데 하나로 제시됐으며, LangSmith는 이를 지원하는 수단으로 소개됐다. 전체 시험 실행의 83%에는 어떤 형태로든 피드백이 연결돼 있어 대부분의 이용자가 애플리케이션을 평가할 지표를 구성하고 있었다. 피드백이 기록된 실행은 평균 2.3종의 서로 다른 피드백을 사용했으며, 글은 이를 하나의 지표에 전적으로 의존하기 어렵다는 신호로 해석했다. 기록된 피드백의 다수는 LLM을 이용해 출력을 평가하는 방식이었고, 우려와 주저가 존재함에도 실제 사용에서는 지배적인 시험 방법으로 나타났다. 평가자의 약 40%는 사용자가 직접 만든 맞춤 평가자였으며, 이는 평가 기준이 각 애플리케이션에 특화돼 범용 평가자 하나로 모두 처리하기 어렵다는 관찰과 일치했다.

8. 정확성 중심 평가와 운영 단계 전환

이용자들은 유해성, 프롬프트 유출, 기타 보호 장치보다 애플리케이션 출력의 정확성을 우선적으로 시험하고 있었다. 평가 기법 가운데 Exact Matching의 사용량이 낮았다는 사실은 정확성 판단이 결과 문자열을 그대로 비교하는 방식만으로 해결되기 어렵다는 점을 보여줬다. 글은 LLM 애플리케이션 개발의 첫 본격적인 해가 끝나는 시점에 많은 팀이 프로토타입과 운영 단계 사이의 격차를 줄이려 한다고 설명한다. 공개된 사용 통계의 목적은 실제 팀들이 무엇을 만들고, 어떤 제공자와 검색 방식을 사용하며, 출력을 어떻게 평가하는지 보여주는 데 있다. 결론에서는 LangChain 사용 여부와 관계없이 LangSmith가 애플리케이션을 프로토타입에서 운영 단계로 전환하는 주요 수단으로 부상하고 있다고 주장한다.

🧾 핵심 주장 / 시사점

• 검색의 높은 비중과 맞춤 검색 전략의 우세는 LLM 자체보다 애플리케이션별 데이터 연결과 검색 로직이 실제 구현의 중요한 차별 요소였음을 보여준다.
• 에이전트 채택률 17%는 복잡한 쿼리와 예외 처리 가능성에도 불구하고 신뢰성과 성능이 실제 적용 범위를 제한하고 있었음을 나타낸다.
• 다중 피드백과 맞춤 평가자의 높은 비율은 LLM 출력의 정확성을 평가할 때 애플리케이션 문맥에 맞춘 복수의 기준이 필요했음을 시사한다.

✅ 액션 아이템

• LangSmith의 검색 42%·에이전트 17%·비-LangChain 사용 15%를 기준으로 적용 우선순위 재검토.
• OpenAI·AzureOpenAI의 선두와 Hugging Face·Ollama의 로컬 실행 경향을 함께 반영한 모델 접근 방식 비교.
• 피드백 83%·평균 2.3종·맞춤 평가자 약 40%를 반영한 LangSmith 평가 기준 구성.

❓ 열린 질문

• LangSmith에서 검색 42%와 에이전트 17%의 격차는 어떤 기능을 먼저 적용해야 함을 보여주는가?
• OpenAI·AzureOpenAI의 선두와 Hugging Face·Ollama의 로컬 실행 경향 사이에서 어떤 제약을 우선해야 하는가?
• 피드백 83%와 평균 2.3종, 맞춤 평가자 약 40%라는 결과는 단일 평가 지표의 한계를 어떻게 보여주는가?