# AI 에이전트 구축에 더 이상 LangChain을 사용하지 않는 이유

> Clean Markdown view of GeekNews topic #15459. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=15459](https://news.hada.io/topic?id=15459)
- GeekNews Markdown: [https://news.hada.io/topic/15459.md](https://news.hada.io/topic/15459.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-06-21T23:34:22+09:00
- Updated: 2024-06-21T23:34:22+09:00
- Original source: [octomind.dev](https://www.octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents)
- Points: 10
- Comments: 2

## Summary

Octomind는 LangChain의 높은 추상화 수준이 복잡한 요구사항을 처리하는 데 장애물이 되어 이를 사용하지 않기로 결정했습니다. 기존에 [LangChain은 무의미합니다](https://news.hada.io/topic?id=9704), [LangChain의 문제점](https://news.hada.io/topic?id=9828) 글에서도 계속 얘기되었고요. [Thoughtworks Technology Radar, 30호](https://news.hada.io/topic?id=14160) 에서도 LangChain을 Hold(주의해서 사용할 기술)에 지정했습니다.

## Topic Body

- Octomind는 AI 에이전트를 사용하여 Playwright에서 엔드 투 엔드 테스트를 자동으로 생성하고 수정함.  
- 초기에는 LangChain 프레임워크를 사용했으나, 시간이 지나면서 LangChain의 높은 추상화 수준이 문제를 일으킴.  
  
#### LangChain의 문제점  
- LangChain의 추상화는 초기에는 유용했으나, 복잡한 요구사항이 생기면서 코드 이해와 유지보수가 어려워짐.  
- LangChain의 내부 구조를 이해하고 디버깅하는 데 많은 시간이 소요됨.  
- 예를 들어, 단순한 영어 단어를 이탈리아어로 번역하는 코드에서도 LangChain을 사용하면 복잡도가 증가함.  
  
#### LangChain의 추상화 문제  
- LangChain은 여러 추상화를 겹쳐 사용하여 코드의 복잡성을 증가시킴.  
- 이러한 추상화는 코드의 이해와 디버깅을 어렵게 만듦.  
- 예를 들어, API에서 JSON 데이터를 가져오는 간단한 작업에서도 LangChain을 사용하면 복잡도가 증가함.  
  
#### 개발 팀에 미친 영향  
- 복잡한 에이전트 아키텍처를 구현하려 할 때 LangChain이 제한 요소로 작용함.  
- LangChain을 제거한 후, 요구사항에 맞게 자유롭게 코딩할 수 있게 됨.  
  
#### AI 애플리케이션 구축에 프레임워크가 필요한가?  
- LangChain은 초기에는 유용했으나, 장기적으로는 프레임워크 없이 개발하는 것이 더 나았을 것임.  
- 대부분의 AI 애플리케이션은 간단한 코드와 몇 가지 외부 패키지로 충분히 구현 가능함.  
- 에이전트 사용 패턴이 확립될 때까지는 간단한 접근 방식을 권장함.  
  
#### 모듈형 빌딩 블록을 사용한 빠르고 간결한 개발  
- 프레임워크는 구조를 강제하지만, AI 애플리케이션은 아직 확립된 사용 패턴이 없음.  
- 모듈형 빌딩 블록 접근 방식은 간단한 저수준 코드를 선호하며, 개발 속도를 높임.  
- 벡터 데이터베이스와 같은 모듈형 구성 요소를 사용하여 코드베이스를 간결하고 적응 가능하게 유지함.  
  
#### GN⁺의 의견  
- **LangChain의 한계**: LangChain의 높은 추상화는 초기에는 유용하지만, 복잡한 요구사항이 생기면 오히려 장애물이 될 수 있음.  
- **모듈형 접근의 장점**: 모듈형 빌딩 블록 접근 방식은 코드의 이해와 유지보수를 용이하게 하며, 개발 속도를 높임.  
- **프레임워크의 필요성 재고**: 모든 AI 애플리케이션에 프레임워크가 필요한 것은 아니며, 간단한 코드와 외부 패키지로도 충분히 구현 가능함.  
- **개발 속도의 중요성**: AI 분야는 빠른 실험과 프로토타이핑이 중요하며, 프레임워크는 이를 제한할 수 있음.  
- **미래의 에이전트 사용 패턴**: 에이전트 사용 패턴이 확립될 때까지는 간단한 접근 방식을 유지하는 것이 좋음.

## Comments



### Comment 26530

- Author: yangeok
- Created: 2024-06-24T10:01:04+09:00
- Points: 1

실패한 아키텍처라는 말이 돌더니 긱뉴스에서도 보게 되네요

### Comment 26471

- Author: neo
- Created: 2024-06-21T23:34:23+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=40739982) 
- **첫 상업용 LLM 에이전트를 작년 10월/11월에 구축했음**: LangChain을 사용하지 않고 에이전트를 처음부터 직접 구축하는 것이 더 나은 결과를 얻는 데 도움이 되었음.

- **LLM 프레임워크의 복잡성**: LangChain 같은 LLM 프레임워크는 자바나 파이썬의 복잡성을 도입하는 경향이 있음.

- **LangChain과 ChatGPT의 비교**: LangChain은 ChatGPT가 등장하기 전에 만들어졌지만, ChatGPT가 더 나은 대화형 모델을 제공하면서 LangChain의 필요성이 줄어듦.

- **LangChain의 가치 논란**: LangChain은 개발자와 LLM 사이에 위치하려 했으나, 실질적인 가치를 추가하지 못하고 불필요한 추상화를 도입함.

- **좋은 추상화와 나쁜 추상화**: 좋은 추상화는 애플리케이션 로직을 다루고, 나쁜 추상화는 필요한 작업을 추상화하여 통찰력을 잃게 함.

- **에이전트 사용의 문제점**: 콘텐츠 생성에 에이전트를 사용하는 것보다 순차적인 프롬프트를 사용하는 것이 더 쉽고 효과적임.

- **Ragged 프레임워크 소개**: LLM과 쉽게 연결할 수 있는 경량 커넥터인 Ragged를 소개함. ORM과 유사한 통합 인터페이스를 제공함.

- **LangChain의 유용성 부족**: LangChain의 접근 방식이 흥미롭지만, 실제로는 LLM 런타임 라이브러리를 직접 사용하는 것이 더 효율적임.

- **빠르게 변하는 에이전트 프레임워크**: 사용 중인 에이전트 프레임워크가 빠르게 변하고, 작은 버전 변경도 현재 설정을 깨뜨릴 수 있음.

- **LangChain의 복잡성 문제**: LangChain은 단순한 사용 사례에는 너무 복잡하고, 복잡한 사용 사례에는 적응하기 어려움. 직접 코딩하는 것이 더 나은 경우가 많음.