• * inote 사이드 프로젝트에서 "책/독서" 기능 개발 중인데, 독서 검색 관련 ai 개발작업 하면서 "LangChain"을 발견하게 되었고, 이에 대한 학습을 접하게 됨.
  
  LLM 자체(Groq, Open AI)는 사실 "텍스트 넣으면 텍스트가 나오는 아주 단순한 함수. 하지만 실제 서비스를 만들려면 그 주변에 필요한것이 많음.

• 여러 단계 연결, 외부 함수 호출, 대화 기록 관리, 검색(RAG) 연동 등... 이런 LLM 주변 배관 작업을 표준화된 부품으로 만들어둔 프레임워크

이전 Agent = Harness + model 학습 내용. LangChain이 정확하게 이 harness 부분을 미리 만들어서 라이브러리로 제공하는 것.
-> 직접 하나하나 짜지 않고 표준 부품을 갖다 쓰는 것.

핵심 개념 4가지

1. Tool — LLM이 호출할 수 있는 외부 함수를 표준 형태로 감싼 것. 우리가 만들 "카카오 도서 검색", "교보 베스트셀러 조회"가 바로 이 Tool이 됨

Agent — LLM이 "이번 요청엔 어떤 Tool을 써야 하지?"를 스스로 판단해서 호출하는 실행기. if/else로 미리 분기 안 짜도, LLM이 알아서 고름

AgentExecutor — Agent의 판단 → Tool 실행 → 결과를 LLM에 다시 넣기 → 재판단, 이 반복 루프를 관리해주는 실행 엔진

1. Chain — 여러 단계(프롬프트 → LLM → 파싱 → 다음 단계)를 파이프라인처럼 연결한 것. 이름 자체가 여기서 옴

EX) 우리 독서 채팅 기능에 적용하면

1) 사용자가 "이번달 베스트셀러 알려줘" / "어린왕자 검색해줘" / "인생책 추천해줘"처럼 자유롭게 물어봐도, Agent가 알아서 판단해요.

from langchain.tools import Tool
from langchain.agents import AgentExecutor, create_tool_calling_agent

def search_kakao_books(query: str) -> str:
    """카카오 도서 검색 API 호출 — 특정 도서 검색"""
    ...

def get_kyobo_bestsellers(category: str = "전체") -> str:
    """교보문고 베스트셀러 조회"""
    ...

tools = [
    Tool(name="search_books", func=search_kakao_books,
         description="특정 도서를 제목/저자로 검색할 때 사용"),
    Tool(name="get_bestsellers", func=get_kyobo_bestsellers,
         description="분야별 베스트셀러 목록이 필요할 때 사용"),
]

agent = create_tool_calling_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools)

result = executor.invoke({"input": "이번달 소설 베스트셀러 알려줘"})

→ Agent가 "아, 이건 get_bestsellers를 써야겠다"고 스스로 판단해서 호출

"이 함수를 언제 써야 하는지" 설명(description)만 잘 써주면, 나머지 판단은 LLM+Agent가 알아서 해요. 이게 순수 Groq function calling이랑 결정적으로 다른 점.

Groq도 함수 호출은 되지만, 여러 Tool 사이에서 "몇 번이고 반복해서 판단하고 호출하는" 루프 관리는 LangChain의 AgentExecutor가 표준화해서 대신 해줘요.

[목표]

• 실무 채용 공고에 자주 등장하는 표준 LLM 오케스트레이션 프레임워크

• "Tool 여러 개를 Agent가 알아서 골라 쓰는" 패턴을 직접 만들어봤다는 게 이력서에 구체적으로 쓸 수 있는 경험이 됨

• 마침 만다라트 AI 기술학습 축에 있는 "RAG 파이프라인 구현"·"pgvector 실전 적용"도 LangChain의 Retriever/VectorStore 연동으로 자연스럽게 이어짐

[재정리]
LangChain는 LLM(대형 언어 모델)을 활용해 실제 애플리케이션을 만들기 쉽게 해 주는 프레임워크입니다.
아래는 핵심 개념과 사용법을 정리한 간단 가이드입니다.

예시 1: "이번달 소설 베스트셀러 알려줘" (Tool이 필요한 경우)

1. 사용자 입력
   "이번달 소설 베스트셀러 알려줘"
        ↓
2. 서버(inote-ai)가 이 메시지 + "내가 쓸 수 있는 도구 목록"을 LLM에게 통째로 보냄

   LLM에게 보내는 내용:
   ─────────────────────────────
   사용자: "이번달 소설 베스트셀러 알려줘"

   [사용 가능한 도구]
   - search_books: 특정 도서를 제목/저자로 검색할 때 사용
   - get_bestsellers: 분야별 베스트셀러 목록이 필요할 때 사용
   ─────────────────────────────
        ↓
3. LLM의 판단 (이게 핵심! LLM이 직접 답을 안 하고 "판단"만 함)

   LLM 응답: "이건 텍스트 답변이 아니라,
   get_bestsellers(category='소설') 함수를 호출해야 할 것 같다"
   → 이 판단은 사람이 읽는 문장이 아니라, 프로그램이 읽는
     구조화된 신호(함수명 + 파라미터)로 옴
        ↓
4. LangChain의 AgentExecutor가 이 신호를 가로챔
   → "아, LLM이 get_bestsellers를 부르고 싶어하네"
   → 실제 파이썬 함수 get_kyobo_bestsellers(category="소설")를 실행
     (이건 LLM이 아니라 우리 서버 코드가 진짜로 실행하는 거예요!)
        ↓
5. 함수 실행 결과 (진짜 데이터)
   ["1위 아몬드", "2위 불편한 편의점", "3위 여름의 빌라"]
        ↓
6. AgentExecutor가 이 결과를 다시 LLM에게 넘김

   LLM에게 다시 보내는 내용:
   ─────────────────────────────
   사용자: "이번달 소설 베스트셀러 알려줘"
   [get_bestsellers 실행 결과]: 1위 아몬드, 2위 불편한 편의점, 3위 여름의 빌라
   → 이 데이터를 참고해서 자연스럽게 답변해줘
   ─────────────────────────────
        ↓
7. LLM이 이번엔 진짜 텍스트 답변을 만듦

   최종 답변: "이번 달 소설 베스트셀러는 1위 《아몬드》,
   2위 《불편한 편의점》, 3위 《여름의 빌라》예요!"
        ↓
8. 사용자에게 전달

핵심: LLM이 "베스트셀러가 뭐더라..." 하고 아무렇게나 지어내지 않고, 진짜 서버 함수를 호출해서 실제 데이터를 받아온 다음에 그걸 바탕으로 답변해요. 그래서 정확함.

예시 2: "오늘 기분이 좋아" (Tool이 필요 없는 경우)

1. 사용자 입력: "오늘 기분이 좋아"
        ↓
2. 서버가 똑같이 [메시지 + 도구 목록]을 LLM에게 보냄
        ↓
3. LLM의 판단: "이건 도구 필요 없네, 그냥 대화하면 되겠다"
   → 바로 텍스트 답변 생성 (함수 호출 신호 없음)
        ↓
4. AgentExecutor: "어? 함수 호출 신호가 없네" → 그냥 LLM 답변을 그대로 통과시킴
        ↓
5. 사용자에게 전달: "오늘 기분 좋으시다니 저도 좋네요! 무슨 좋은 일 있으셨어요?"

정리