OpenClaw vs LangChain: 프레임워크를 사용하지 않는 이유

Claw-Stack을 본 사람들이 가장 먼저 묻는 질문은 LangChain을 사용하지 않는 이유는 무엇인가 하는 것입니다. 파이썬 AI 에이전트를 위한 지배적인 프레임워크이며, 거대한 생태계를 가지고 있고, 그 외에 직접 구축해야 할 많은 배관 작업을 처리합니다. 답변은 “프레임워크”가 무엇을 의미하는지, 그리고 우리가 실제로 필요한 것이 무엇인지와 관련이 있습니다.

OpenClaw가 하는 것 (그리고 하지 않는 것)

OpenClaw는 npm 패키지입니다. 설치하고 구성한 다음 Claude에 도구(파일 시스템, 셸, MCP 서버, 메모리)에 대한 접근을 제공하는 로컬 프로세스로 실행합니다. 프레임워크가 아니라 런타임입니다. 에이전트 로직을 어떻게 구성해야 하는지 지시하지 않습니다. 도구 호출을 실행하고 세션을 관리할 뿐입니다.

이것은 의미 있는 구분입니다. OpenClaw는 도구가 어떻게 호출되는지에 대한 의견을 가지고 있지만, 에이전트가 무엇을 하는지에 대한 의견은 없습니다. 확장할 기본 클래스가 없고, 구성할 체인이 없으며, 정의할 그래프가 없습니다. 에이전트가 어떻게 동작해야 하는지 설명하는 CLAUDE.md 파일을 작성하면, OpenClaw가 해당 컨텍스트와 등록한 도구로 Claude 세션을 실행합니다.

LangChain은 그 반대입니다. 에이전트 로직을 어떻게 구조화해야 하는지에 대한 강한 의견이 있습니다: 체인, 러너블, 에이전트, 도구, 메모리, 검색기. 고전적 의미의 프레임워크입니다 — 골격을 제공하고 당신이 세부 사항을 채웁니다. 골격이 당신의 사용 사례와 일치할 때 유용합니다. 그렇지 않을 때는 문제가 됩니다.

추상화 문제

LangChain의 추상화는 LLM 호출을 파이프라인으로 구성한다는 아이디어 중심으로 설계되었습니다: 입력 → 검색 → LLM → 출력 → 다음 LLM 호출. 이는 RAG 시스템과 간단한 질문-답변 에이전트에 잘 작동합니다. 파이프라인 모델에 맞지 않는 것이 필요할 때 싸움을 시작합니다.

예를 들어, 우리의 다중 에이전트 회의 프로토콜은 여러 Claude 인스턴스를 구조화된 토론의 “참여자”로 실행합니다. 각 참여자는 대화 기록을 읽고, 응답을 생성하며, 필요에 따라 합의를 신호하거나 다른 라운드를 요청합니다. 조정자는 그 다음 계속할지 여부를 결정합니다. 이 중 어느 것도 LangChain의 에이전트/도구 모델에 깔끔하게 맞지 않습니다. 결국 프로토콜을 사용자 정의 도구가 있는 에이전트로 억지로 넣거나, LangChain의 대부분의 추상화를 우회해야 합니다.

OpenClaw를 사용하면 우리는 조정 로직을 직접 작성합니다. 조정자 에이전트는 공유 파일에서 현재 상태를 읽고, 참여자 에이전트를 서브프로세스로 호출하며, 그들의 응답을 수집하고, 다음에 무엇을 할지 결정하는 OpenClaw 세션입니다. 이는 JavaScript(Node.js ES 모듈)로 작성되었으며, 6개의 소스 파일(조정자, 세션 관리자, 요약자, 합의 감지기, 타임아웃 핸들러, 의사록 작성자)에 걸쳐 있으며, 모든 줄이 우리가 이해하는 것을 수행합니다.

디버깅 경험

LangChain 에이전트에서 뭔가 잘못되면, 오류는 종종 추상화 스택의 여러 계층 깊숙이 있습니다. 당신은 체인을 호출하는 러너블을 디버깅하고 있고, 그것은 LLM을 호출하고, 출력을 반환하고, 출력 파서에 의해 파싱되고… 어딘가에서 뭔가 실패했습니다. 유용한 스택 추적을 얻으려면 추상화의 어느 계층이 어느 동작을 담당하는지 이해해야 합니다.

OpenClaw를 사용하면 기본적으로 두 곳을 봐야 합니다: 도구 구현과 Claude 세션 로그입니다. 에이전트가 잘못된 도구를 호출했다면 세션 기록을 확인합니다. 도구가 잘못된 출력을 생성했다면 도구를 확인합니다. 도움이 되려고 시도하는 중간 계층이 없습니다.

이는 들리는 것보다 더 중요합니다. 우리는 몇 시간 동안 실행되고, 수십 개의 도구 호출을 포함하며, 수백 KB의 컨텍스트를 축적하는 세션을 실행했습니다. 2시간 후에 뭔가 잘못되면, 세션 로그를 읽고 정확히 무엇이 일어났는지 이해할 수 있기를 원합니다. 얇은 런타임의 경우, 세션 로그 는 무엇이 일어났는지의 완전한 기록입니다. 두꺼운 프레임워크의 경우, 프레임워크의 내부 상태는 또한 검사해야 하는 병렬 진실의 소스입니다.

락인과 생태계 종속성

LangChain은 500개 이상의 통합 패키지를 가지고 있습니다. 많은 것들이 커뮤니티 유지되며 라이브러리 업데이트에서 깨집니다. 에이전트 로직을 LangChain의 추상화 주위에 구축하면, 그들이 모두 유지되고 호환 가능하다는 암묵적 종속성을 수용하는 것입니다.

OpenClaw의 통합 모델은 다릅니다: 통합은 MCP(Model Context Protocol)를 통해 발생합니다. MCP 서버는 단지 도구를 노출하는 프로세스입니다. 새로운 데이터 소스를 위한 MCP 서버를 작성하는 것은 약 50줄의 코드입니다. 인터페이스는 표준이고, 프로토콜은 간단하며, 제3자 통합이 깨질 때, 수정은 해당 서버로 격리됩니다 — 에이전트 로직을 통해 계단식으로 나타나지 않습니다.

이것이 우리가 프레임워크 코드 없이 웹 자동화 계층(26개 Chrome DevTools Protocol 도구), 우리의 AI 및 기술 콘텐츠 수집기, 그리고 우리의 백업 통합을 구축할 수 있었던 이유입니다. 각각은 시작할 때 OpenClaw에 도구를 등록하는 독립 실행형 MCP 서버입니다.

LangChain이 합리적인 경우

이것은 LangChain에 대한 전반적인 주장이 아닙니다. 주요 제어 흐름이 관련 문서를 검색하고, LLM에 전달하고, 답변을 반환하는 RAG 시스템을 구축하는 경우 — LangChain의 추상화는 해당 패턴에 잘 매핑됩니다. LCEL(LangChain Expression Language)은 검색 파이프라인 구성에 진정으로 깔끔합니다.

또한 처음부터 구축하는 데 시간이 걸릴 벡터 데이터베이스, 문서 로더, 임베딩 모델과의 강력한 통합을 가지고 있습니다. 빠르게 프로토타이핑하거나 기존 Python 애플리케이션에 일반적인 AI 기능을 구축하는 팀의 경우, 프레임워크 오버헤드는 통합 바로가기의 가치가 있습니다.

우리의 사용 사례는 다릅니다. 우리는 자율적으로 실행되고, 몇 일과 몇 주에 걸쳐 상태를 축적하며, 복잡한 작업에서 여러 에이전트를 조정하고, 뭔가 잘못되었을 때 디버깅해야 하는 AI 에이전트 시스템을 구축하고 있습니다. 그를 위해, 우리는 찾을 수 있는 가장 투명하고 최소한의 런타임을 원했습니다.

원칙: 얇은 런타임, 풍부한 기술

우리의 아키텍처는 “얇은 런타임, 풍부한 기술”이라고 생각하기 시작한 원칙을 따릅니다. OpenClaw는 런타임입니다: 도구 디스패치, 세션 관리, Claude 인터페이스를 처리합니다. 그 외 모든 것 — 메모리, 보안, 다중 에이전트 조정, 브라우저 자동화 — 독립적으로 배포 가능한 별도 모듈에 있습니다.

이는 각 기술을 격리하여 테스트할 수 있고, 다른 기술을 건드리지 않고 교체할 수 있으며, 전체 시스템을 이해하지 않고도 추론할 수 있음을 의미합니다. 단점은 더 많은 배선을 작성해야 한다는 것입니다. 장점은 뭔가 깨질 때, 그것은 거의 항상 배선에 있다는 것입니다 — 당신이 작성하고 이해하는 부분입니다.

우리는 이 접근법을 보편적으로 올바른 것으로 전도하지 않습니다. 디버깅하고, 확장하며, 모든 수준에서 이해해야 하는 연구 프로젝트에 대한 올바른 트레이드오프입니다. 마감일에 제품 기능을 출시하는 경우, LangChain의 프레임워크 오버헤드는 그만한 가치가 있을 수 있습니다. 우리에게는 그렇지 않았습니다.