온톨로지와 메모리 시스템 (11/13) — LangChain은 지식 시스템에서 무엇을 하는가
지난 글에서는 GraphDB를 다뤘다. 관계형 테이블이나 벡터 검색만으로는 설명하기 어려운 연결, 즉 "이 메모는 어떤 프로젝트의 결정 근거였는가", "이 개념은 어떤 실패 사례와 연결되는가" 같은 질문을 구조적으로 다루려면 그래프적 시각이 필요하다는 이야기였다.
그런데 여기서 자연스럽게 다음 질문이 나온다. 그래프까지 준비했으면 이제 지식 시스템은 완성된 걸까? 실제로는 그렇지 않다. 저장 구조가 좋아졌다고 해서 시스템이 곧바로 "잘 생각하는 흐름"을 갖게 되지는 않는다. 여전히 누군가는 지금 질문이 무엇인지 읽고, 어떤 데이터를 꺼낼지 정하고, 어떤 도구를 언제 쓸지 결정하고, 그 결과를 다시 모델 입력으로 묶어야 한다.
바로 그 자리에서 LangChain 같은 프레임워크가 등장한다.
이 글의 핵심은 단순하다. LangChain은 지식을 저장하는 시스템이 아니라, 이미 존재하는 여러 지식 구성요소를 작업 흐름으로 연결하는 오케스트레이션 계층이다. 이 문장을 정확히 이해하면, LangChain을 과대평가하는 실수도 줄고 과소평가하는 실수도 줄어든다.
LangChain은 "무엇을 가진 시스템"이 아니라 "어떻게 연결할지 정하는 시스템"이다
처음 접하면 LangChain을 거대한 AI 엔진처럼 느끼기 쉽다. 하지만 LangChain 자체가 지식을 갖고 있는 것은 아니다. LangChain이 직접 모델을 학습시키는 것도 아니고, 데이터를 영구 저장하는 것도 아니며, 그래프 데이터베이스를 대신하는 것도 아니다.
LangChain이 하는 일은 훨씬 실무적이다.
사용자의 입력이 들어왔을 때:
- 어느 모델을 호출할지 정하고
- 어떤 프롬프트 형태로 가공할지 정하고
- 검색이 필요하면 어떤 retriever를 부를지 정하고
- 외부 도구가 필요하면 어떤 tool을 실행할지 정하고
- 그 중간 결과를 다시 다음 단계의 입력으로 넘기고
- 최종적으로 사람이 읽을 수 있는 응답으로 묶는다
즉 LangChain은 "정답을 보관하는 장소"가 아니라, 정답에 도달하기 위해 여러 부품을 순서 있게 움직이는 배선과 제어 로직에 가깝다.
지식 시스템 관점에서 보면 이것은 매우 중요하다. Second Brain이 단순 노트 저장소를 넘어서려면, 저장된 정보가 "현재 작업" 안으로 실제로 들어와야 한다. LangChain은 그때 저장소와 모델 사이를 잇는 조립대 역할을 한다.
오케스트레이션이라는 말은 정확히 무엇을 뜻할까
"오케스트레이션"이라는 단어는 자주 쓰이지만, 막상 들으면 추상적으로 느껴진다. 여기서는 아주 구체적으로 이해하는 편이 좋다.
오케스트라에서 바이올린, 첼로, 플루트가 각각 악기 자체의 역할을 수행하듯, 지식 시스템에서도 부품들은 각자 전문 역할이 있다. LLM은 언어 생성과 추론을 담당하고, 벡터 스토어는 의미적으로 비슷한 문서를 찾고, GraphDB는 관계를 저장하고, 검색기는 후보를 회수하고, 계산기나 웹 API는 외부 작업을 수행한다.
하지만 악기만 있다고 음악이 저절로 나오지는 않는다. 누가 어느 타이밍에 들어가야 하는지, 무엇을 먼저 하고 무엇을 나중에 해야 하는지, 중간 결과를 다음 단계에서 어떻게 해석할지 정해야 한다. 이 "순서와 연결"이 바로 오케스트레이션이다.
LangChain은 보통 다음 같은 질문에 답하는 층이다.
- 지금 이 요청은 바로 모델에 던져도 되는가?
- 먼저 검색을 해야 하는가?
- 검색한다면 벡터 검색이 맞는가, 키워드 검색이 맞는가, 그래프 순회가 맞는가?
- 한 번 검색한 결과를 요약한 뒤 다시 모델에 넣을 것인가?
- 도구 실행 결과가 불충분하면 한 번 더 질의를 바꿔 재검색할 것인가?
이런 판단은 데이터베이스가 하지 않는다. 모델도 스스로 안정적으로 하지 못한다. 그래서 오케스트레이션 계층이 별도로 필요하다.
LangChain과 LLM의 관계: 두뇌가 아니라 조립 프레임이다
많은 초심자가 LangChain을 "LLM을 더 똑똑하게 만드는 것"으로 이해한다. 절반만 맞는 표현이다. LangChain이 모델 자체를 더 똑똑하게 만드는 것은 아니다. GPT 계열 모델이든, Claude 계열 모델이든, 로컬 모델이든, 핵심 추론 능력은 기본적으로 모델이 가지고 있다.
LangChain은 그 모델이 적절한 맥락을 받도록 돕는다.
예를 들어 사용자가 "지난달 읽은 논문 메모와 이번 프로젝트 회의록을 연결해서, 지금 설계안의 리스크를 설명해 줘"라고 요청했다고 해 보자. 모델 단독으로는 이 문장을 읽고 그럴듯한 답을 만들 수는 있다. 하지만 실제 메모와 회의록을 모르면 정확한 답은 못 한다.
이때 필요한 일은 다음과 같다.
- "지난달 읽은 논문 메모"가 무엇을 뜻하는지 찾는다.
- "이번 프로젝트 회의록"에 해당하는 문서를 찾는다.
- 둘 사이의 공통 개념이나 충돌 지점을 추려낸다.
- 그 재료를 모델이 답변 가능한 프롬프트 형태로 정리한다.
이 과정 전체를 설계하는 것이 LangChain의 몫이다. 다시 말해 LLM이 "문장을 만드는 엔진"이라면, LangChain은 그 엔진 앞뒤에 필요한 문맥 조립 장치다.
LangChain과 retriever의 관계: 검색 자체보다 검색을 어떻게 끼워 넣을지가 중요하다
Retriever는 관련 정보를 꺼내 오는 구성요소다. 벡터 검색기일 수도 있고, BM25 같은 키워드 기반 검색기일 수도 있고, GraphDB 질의기일 수도 있다. 중요한 점은 retriever가 "찾아오는 일"을 담당한다는 것이다.
LangChain은 retriever를 대체하지 않는다. 대신 retriever를 작업 흐름 안에 배치한다.
예를 들어 같은 질문이라도 다음처럼 달라질 수 있다.
- 정의를 묻는 질문이면 의미 기반 검색 몇 건만 가져온다.
- 사람-프로젝트-결정 관계를 묻는 질문이면 GraphDB 질의를 먼저 실행한다.
- 최신 상태가 중요하면 문서 검색 전에 날짜 필터를 건다.
- 검색 결과가 너무 넓으면 한 번 요약한 뒤 다시 좁혀서 재검색한다.
즉 retriever가 "문서를 회수하는 손"이라면, LangChain은 그 손을 언제 어떻게 뻗을지 정하는 상위 흐름이다.
Second Brain 관점에서는 이 차이가 크다. 좋은 지식 시스템은 문서를 많이 저장하는 시스템이 아니라, 현재 질문에 맞는 기억 회수 방식을 고르는 시스템이기 때문이다.
LangChain과 tool의 관계: 답변만 만드는 시스템에서 행동 가능한 시스템으로
도구 사용이 들어오면 LangChain의 역할은 더 분명해진다. 어떤 질문은 문서 검색만으로 충분하지만, 어떤 질문은 계산, API 호출, 데이터 변환, 외부 상태 확인이 필요하다.
예를 들어 사용자가 이렇게 묻는다고 해 보자.
"내 독서 메모 중에서 생산성 관련 글만 모아서 최근 30일 기록과 비교해 공통 습관을 뽑아 줘."
여기에는 최소한 여러 단계가 숨어 있다.
- 메모 저장소에서 생산성 관련 문서를 찾는다.
- 최근 30일 로그를 읽는다.
- 둘을 비교 가능한 형식으로 정리한다.
- 공통 패턴을 추출한다.
여기서 일부 단계는 retriever가 맡고, 일부 단계는 파서나 계산기 같은 tool이 맡고, 마지막 서술은 LLM이 맡을 수 있다. LangChain은 이 역할 분담을 흐름으로 만든다.
그래서 LangChain은 단순 Q&A 래퍼보다 한 단계 위에 있다. "질문을 받고 답한다"가 아니라, 질문을 해석하고 필요한 부품을 호출해 결과를 조립한다는 쪽에 더 가깝다.
가장 흔한 혼동 1: LangChain은 모델이 아니다
이 부분은 꼭 분리해서 이해해야 한다.
모델은 언어를 생성하고, 요약하고, 비교하고, 추론한다. 성능 한계도 모델에 따라 달라진다. 반면 LangChain은 모델 위에 얹히는 애플리케이션 계층이다.
그래서 답변 품질이 낮을 때 원인이 항상 LangChain인 것은 아니다. 모델의 추론 능력이 약한 것일 수도 있고, 프롬프트가 빈약한 것일 수도 있고, 검색된 문서가 틀렸을 수도 있다. LangChain은 이 부품들을 묶는 흐름을 제공하지만, 각 부품 자체의 품질을 마법처럼 바꾸지는 않는다.
이 점을 놓치면 "LangChain을 쓰면 AI가 더 똑똑해진다"는 오해가 생긴다. 더 정확한 표현은 이렇다. LangChain을 잘 쓰면, 모델이 똑똑해 보일 수 있는 조건을 더 안정적으로 만들어 준다.
가장 흔한 혼동 2: LangChain은 데이터베이스가 아니다
이것도 매우 흔한 착각이다. 특히 RAG를 처음 구성할 때 그렇다.
사람들은 종종 "LangChain에 문서를 넣는다"고 말한다. 표현상 틀린 말은 아니지만, 구조적으로는 부정확하다. 실제 문서는 보통 벡터 데이터베이스, 문서 저장소, SQL, GraphDB 같은 외부 저장 계층에 들어간다. LangChain은 그 저장소를 읽고 활용하는 쪽이다.
즉:
- 저장은 데이터베이스가 한다.
- 생성은 LLM이 한다.
- 회수는 retriever가 한다.
- 외부 실행은 tool이 한다.
- 이들을 연결해 하나의 경험으로 만드는 것은 LangChain이 한다.
이 역할 분리를 이해하면 시스템 설계가 훨씬 명료해진다. 그래프를 강화해야 할 문제를 LangChain 설정으로 해결하려 하거나, 모델 성능 한계를 체인 구조로 덮으려는 식의 비효율도 줄어든다.
GraphDB 다음에 LangChain을 보는 이유
Part 3에서 GraphDB를 이야기했다면, 그 다음에 LangChain이 나오는 것은 자연스럽다. GraphDB는 "무엇이 무엇과 연결되어 있는가"를 저장하는 계층이다. 하지만 저장된 관계가 있다고 해서 사용자의 현재 질문에 자동으로 들어오지는 않는다.
예를 들어 다음과 같은 지식 그래프가 있다고 하자.
- 사람 A는 프로젝트 X의 의사결정자였다.
- 프로젝트 X는 설계 원칙 P를 채택했다.
- 원칙 P는 과거 실패 사례 F를 반영해 만들어졌다.
사용자가 "왜 우리는 이번에도 비슷한 구조를 택해야 하죠?"라고 물었을 때, 시스템이 해야 하는 일은 단순 저장이 아니다. 현재 질문을 해석하고, 관련 엔터티를 찾고, 그래프에서 관계를 따라가고, 필요한 경우 벡터 검색으로 보조 문서를 모으고, 그 결과를 설명 가능한 문장으로 합성해야 한다.
그래프는 관계를 보관한다. LangChain은 그 관계를 질문-응답 흐름 안으로 호출하는 조정자다.
그래서 둘은 경쟁 관계가 아니라 계층이 다르다. GraphDB는 기억의 구조를 다루고, LangChain은 그 구조를 현재 작업에 연결하는 실행 흐름을 다룬다.
실무 예시 1: "내 메모로 답하는 개인 비서"는 어떻게 움직이나
가장 흔한 예시는 개인 지식 비서다. 사용자가 "내가 예전에 쓴 블로그 초안 중에서 RAG와 메모리의 차이를 설명한 부분을 찾아서, 지금 쓰는 글의 도입부로 다시 정리해 줘"라고 요청한다고 해 보자.
이때 내부 흐름은 대략 이렇게 움직인다.
먼저 LangChain은 이 요청이 일반 상식 답변이 아니라 개인 저장소 기반 회수형 작업이라고 판단한다. 그다음 메모 저장소에 연결된 retriever를 호출해 관련 초안들을 찾는다. 검색 결과가 여러 개 나오면 일부를 압축 요약해 핵심 문단만 남긴다. 필요하면 GraphDB에서 해당 초안이 연결된 주제 노드, 과거 수정 이력, 관련 프로젝트 메모를 추가로 가져온다. 그런 다음 이 재료를 LLM에게 넘겨 "지금 글의 도입부"라는 목적에 맞게 다시 쓰게 한다.
여기서 핵심은 어느 한 부품이 전부를 하지 않는다는 점이다. 좋은 경험은 부품의 총합이 아니라, 부품이 연결되는 순서에서 나온다.
실무 예시 2: "회의 기록에서 다음 판단을 뽑아내는 시스템"
조금 더 업무형 예시도 보자.
사용자가 "이번 주 회의록과 지난 분기 회고를 바탕으로, 지금 프로젝트에서 다시 반복되는 실패 패턴이 있는지 정리해 줘"라고 물었다고 하자.
이 질문은 단순 요약이 아니다. 시간 범위가 있고, 두 종류의 문서가 있고, 비교라는 작업이 있다. 여기서 LangChain은 먼저 회의록과 회고 문서를 각각 회수하게 만들 수 있다. 그 뒤 한 번에 전부 모델에 넣지 않고, 각 문서 집합에서 실패 패턴 후보를 먼저 추출한 뒤 마지막 단계에서 비교하게 만들 수도 있다.
왜 이런 구조가 중요할까? 문서가 많아질수록 한 번에 전부 넣는 방식은 금방 비효율적이 되기 때문이다. 오케스트레이션은 단지 "연결"이 아니라, 제한된 컨텍스트 창 안에서 어떤 순서로 압축하고 회수하고 합성할지 결정하는 기술이기도 하다.
실무 예시 3: GraphDB와 벡터 검색을 함께 쓰는 경우
Second Brain이 커질수록 한 가지 검색 방식만으로는 부족하다. 어떤 질문은 의미적으로 비슷한 문단을 찾는 것이 중요하고, 어떤 질문은 "누가 어떤 결정을 내렸는가" 같은 구조적 관계가 더 중요하다.
예를 들어 사용자가 "이 개념이 왜 우리 팀 운영 원칙으로 굳어졌는지 설명해 줘"라고 묻는다면:
- 벡터 검색은 이 개념을 언급한 메모들을 넓게 모아 주고
- GraphDB는 그 개념이 어떤 결정, 어떤 사람, 어떤 사건과 연결되는지 좁고 정확하게 보여 준다
- LLM은 그 재료를 사람이 읽기 좋은 설명으로 합친다
LangChain은 바로 이 혼합 흐름을 구성하는 데 유용하다. 어떤 질문에서는 그래프를 먼저 타고, 어떤 질문에서는 벡터 검색을 먼저 하고, 어떤 질문에서는 둘을 병렬 후보로 가져와 합칠 수 있다. 중요한 것은 LangChain이 "정답 저장소"라서가 아니라, 서로 다른 회수 전략을 하나의 응답 파이프라인으로 묶기 좋기 때문이다.
LangChain을 과하게 신비화할 필요는 없다
실무에서 LangChain을 보는 가장 건강한 관점은 이렇다. 이것은 마법 지능이 아니라 애플리케이션 조립 프레임워크다.
좋은 점은 분명하다. 모델 호출, 프롬프트 템플릿, 문서 로딩, 검색, 도구 실행, 중간 단계 연결을 일정한 패턴으로 관리하기 쉬워진다. 실험 속도도 빨라진다. 지식 시스템을 "한 번 묻고 한 번 답하는 데모"에서 "복수 구성요소가 협력하는 작업 흐름"으로 확장하기에도 편하다.
반대로 한계도 분명하다. LangChain을 넣는다고 지식 품질이 자동으로 좋아지지 않는다. 엉성한 문서 구조, 부정확한 메타데이터, 나쁜 그래프 설계, 낮은 품질의 검색 결과는 그대로 드러난다. 오케스트레이션은 나쁜 재료를 요리할 수는 있어도, 재료 자체를 다른 것으로 바꾸지는 못한다.
그래서 LangChain은 대체재가 아니라 접착제에 가깝다. LLM의 대체재도 아니고, GraphDB의 대체재도 아니고, 벡터DB의 대체재도 아니다. 이들을 지금의 질문에 맞는 경로로 엮어 주는 실행층이다.
마무리: LangChain은 Second Brain의 "행동 가능한 연결부"다
이 연재를 한 문장으로 줄이면 이렇다. 좋은 Second Brain은 많이 저장하는 시스템이 아니라, 필요한 순간에 올바른 맥락을 조립하는 시스템이다.
그 관점에서 보면 역할이 분명해진다.
GraphDB는 관계를 저장한다. 벡터 스토어는 의미적으로 가까운 정보를 회수한다. LLM은 설명하고 비교하고 요약한다. 도구는 외부 작업을 수행한다. LangChain은 이 모든 것을 현재 작업의 흐름으로 묶는다.
그래서 "LangChain은 정확히 무엇을 하는가?"라는 질문에 대한 가장 정확한 답은 이것이다.
LangChain은 지식 시스템의 두뇌가 아니라, 두뇌가 기억과 도구를 제때 활용할 수 있게 만드는 오케스트레이션 계층이다.
이 구분만 명확해도, 개인 지식 시스템을 설계할 때 무엇을 모델 문제로 봐야 하고, 무엇을 데이터 구조 문제로 봐야 하며, 무엇을 실행 흐름 문제로 봐야 하는지가 훨씬 또렷해진다. 그리고 바로 그 또렷함이, "메모가 많은 사람"에서 "메모를 실제로 활용하는 사람"으로 넘어가는 지점이 된다.
참고 자료
- LangChain 공식 문서의 retriever, tool, chain, agent 개념 정리
- RAG와 agent orchestration 설계 논의 전반
시리즈 전체 안내: 시리즈 목차
댓글
댓글 쓰기