LiteLLM이랑 LangChain, 둘 중 뭘 써야 하나?

이 질문을 처음에 그대로 가지고 조사를 시작했다. 그런데 각각의 문서를 읽으면 읽을수록 비교가 이상해졌다. LiteLLM 문서에서는 모델 라우팅이나 폴백 정책 이야기가 나오고, LangChain 문서에서는 체인이니 메모리니 하는 이야기가 나온다. 같은 카테고리의 도구가 맞나 싶었다.

결론적으로 “둘 중 뭘 써야 하나”라는 질문 자체가 좀 틀어져 있었다.

• LiteLLM: 여러 모델 제공자의 API를 통합하고, 호출을 운영하기 쉽게 만드는 레이어
• LangChain: 프롬프트, 메모리, 체인, 도구 호출을 조합해서 LLM 앱의 흐름을 설계하는 프레임워크

하나는 호출 인프라고, 다른 하나는 앱 구성 프레임워크다. 비교 대상이 아니라 다른 층에 있는 도구였다.

LiteLLM이 필요해지는 순간

내 경우에 LiteLLM을 처음 찾아본 건, 프로젝트에서 OpenAI랑 Anthropic을 번갈아 쓰게 되면서였다. 모델마다 API 형식이 미묘하게 달라서 래퍼 코드가 점점 지저분해지고 있었다.

LiteLLM은 이런 상황에서 쓰는 도구다.

• 모델 공급자가 여러 개라서 호출 방식 차이를 한 곳에서 감추고 싶을 때
• 로그, 비용 추적, 라우팅, 폴백 정책을 공통으로 관리하고 싶을 때
• 모델을 자주 바꾸거나 A/B 비교를 해야 할 때

그래서 LiteLLM을 한마디로 표현하면 “LLM API 어댑터 겸 운영 게이트웨이”가 제일 맞는 것 같다. 호출을 예쁘게 감싸고, 운영에 필요한 부가 기능을 한 레이어에서 처리해주는 거다.

LangChain이 필요해지는 순간

반면에 LangChain은 호출 하나를 감싸는 것보다, 그 호출들을 어떻게 연결하느냐에 관심이 있다.

이런 경우에 자연스럽게 LangChain을 보게 된다.

• 프롬프트를 단계별로 연결해야 할 때
• 검색 결과를 가져와서 요약하고 답변을 생성하는 RAG 파이프라인을 짤 때
• 도구 호출, 메모리, 출력 파싱을 묶어서 하나의 흐름으로 관리해야 할 때
• 에이전트 형태로 확장할 가능성이 있을 때

LangChain은 “호출 도구”가 아니라 “LLM 앱 조립 프레임워크”라고 보는 게 맞다. 처음에 이 구분을 못 잡아서 한참 혼란스러웠다.

같은 표에 넣으면 왜 꼬이나

둘 다 LLM 관련 도구니까 한 표에 놓고 기능 체크를 하고 싶어지는데, 실제로 해보면 비교 축이 안 맞는다.

• LiteLLM에 대한 질문: “어떤 모델을 어떤 방식으로 호출하고 운영할까?”
• LangChain에 대한 질문: “그 호출들을 어떤 흐름으로 연결할까?”

필요성의 기준도 다르다. LiteLLM은 운영 복잡도가 올라갈수록 빛을 보고, LangChain은 애플리케이션 로직이 복잡해질수록 빛을 본다. 그러니까 “어느 쪽이 더 좋다”가 아니라 “지금 내가 어디서 복잡도를 느끼고 있나”가 진짜 질문이었다.

같이 쓰면 오히려 깔끔하다

실무에서는 아래처럼 같이 쓰는 구성이 자연스럽다.

애플리케이션 로직
   ↓
LangChain
   ↓
LiteLLM
   ↓
모델 제공자들

LangChain이 “검색 -> 요약 -> 답변 생성” 같은 체인을 구성하고, 실제 모델 호출이나 폴백, 비용 추적은 LiteLLM이 맡는 식이다. 이렇게 놓으니까 각 레이어의 책임이 깔끔하게 나뉜다.

그래서 내가 정리한 기준

프로젝트에서 모델 호출 추상화가 급하면 LiteLLM을 먼저 넣는다. 앱 흐름이 복잡해지기 시작하면 LangChain을 검토한다. 운영 대상 모델도 많고 앱 로직도 복잡하면 같이 쓴다.

처음에 “둘 중 하나”를 골라야 한다고 생각했던 게 삽질의 시작이었다. 이 둘은 해결하는 문제가 다르다. LiteLLM은 호출과 운영을 단순하게 만들고, LangChain은 애플리케이션 흐름을 설계하게 도와준다. 어떤 복잡도를 줄여주는 도구인지를 먼저 보는 게 제일 실용적이었다.