랭체인에서 RunnableLambda과 Tool Calling 방식의 활용방법 비교

 

공학/엔지니어링 함수를 LangChain에서 구현할 때, RunnableLambda 방식과 Tool Calling 방식 각각의 특징과 장단점, 적합한 상황을 분석해 설명드립니다.

1. RunnableLambda 방식

구현 방법

• CoolProp의 Python 함수(예: PropsSI 등) 또는 직접 만든 steam property 변환 함수를 RunnableLambda로 감싼 뒤, LangChain 체인 내에서 한 단계로 사용합니다.
• 예시:

  from langchain_core.runnables import RunnableLambda
  from CoolProp.CoolProp import PropsSI
  
  def get_steam_prop(args):
      return PropsSI(args["output"], args["input1"], args["value1"], args["input2"], args["value2"], args["fluid"])
  
  steam_runnable = RunnableLambda(get_steam_prop)
  steam_runnable.invoke({"output": "H", "input1": "T", "value1": 373.15, "input2": "P", "value2": 101325, "fluid": "Water"})
  

장점

• 간결함: RunnableLambda로 간단히 래핑하면 즉시 체인 워크플로우에 포함 가능.
• 유연성: 거의 모든 Python 함수 로직을 래핑, 체인 내부 데이터 변환/후처리에 더 적합.
• 호환성: 직접 체인, 파이프라인, 프롬프트 등과 쉽게 조합해 쓸 수 있음.
• 빠른 개발: 추가적인 schema 정의 없이 바로 함수 추가/수정 가능.

단점

• 모델이 직접 함수 호출을 결정하지 못함: LLM 등이 도구의 존재를 '인지'해 중간에 직접 호출·응답 구조를 만들고 싶으면 한계.
• 동적 사용성 부족: 사용자 자유로운 자연어 질의에 따라 LLM이 도구를 자동 선택, 실행하는 복잡한 에이전트형 시스템엔 한계.

2. Tool Calling 방식

구현 방법

• CoolProp 기반 steam property 함수를 @tool 을 달아 Tool로 등록하거나 RunnableLambda.as_tool()로 변환.
• 이렇게 하면 LangChain의 'tool calling' 기능(예: 에이전트, 챗봇)에서 LLM이 필요에 따라 자동 호출할 수 있음.
• 예시:

  from langchain_core.tools import tool
  from CoolProp.CoolProp import PropsSI
  
  @tool
  def get_steam_prop(output: str, input1: str, value1: float, input2: str, value2: float, fluid: str):
      return PropsSI(output, input1, value1, input2, value2, fluid)
  # or
  from langchain_core.runnables import RunnableLambda
  steam_runnable = RunnableLambda(get_steam_prop).as_tool(
      name="get_steam_prop",
      description="설명",
      # arg_types, schema, 등 타입 명시 가능
  )
  

장점

• 에이전트·LLM과 자연스러운 통합: LLM이 자연어 입력을 분석, 언제 어떤 파라미터로 함수를 쓸지 스스로 결정.
• 스키마 명확화: 입력/출력 타입 자동 추론, 명세 가능—에러 방지 및 API 문서화 용이.
• 확장성: 여러 도구 병렬 구성, 함수 차원에서 재사용·테스트 쉬움.
• 복잡한 대화 흐름/에이전트에 적합: LLM이 필요시만 도구 호출, 그 외엔 자체 답변, 멀티툴 연동 등 고난도 시나리오 적용.

단점

• 초기 정의 절차 약간 번거로움: Tool 등록 및 스키마/설명 명세 필요.
• 단계 조립에는 Runnable보다 장황할 수 있음: tool형식으로 wrapping/unwrapping 필요.

3. 선택 기준·추천

상황/목표	추천 방식	이유
단순 체인 워크플로우, 데이터 전처리, 후처리, 변환	RunnableLambda	코드 간결, 파이프라인에서 빠른 반복 개발
LLM/에이전트 기반 자연어→도구 자동 호출, 챗봇, Tool API	Tool Calling (@tool, .as_tool)	스키마명확, LLM통합, 복잡한 대화·멀티툴
향후 확장성 고려, 자동 문서화/검증 필요	Tool Calling	스키마 및 설명, 자동화툴 활용 가능

결론

• 데이터 가공·간단 파이프라인이면 RunnableLambda로 시작해도 좋습니다.
• LLM 주도 에이전트, 챗봇, 여러 도구 활용, 확장성이 관건이라면 성장성·API 명확화·자동처리 장점이 큰 Tool Calling 방식이 더 좋습니다.
• CoolProp 기반 증기 함수는 간단히 RunnableLambda로 래핑→향후 필요에 따라 .as_tool() 또는 @tool로 변경해 tool calling 체계로 확장하는 식으로 접근 가능합니다.

실제 목적·시스템 구조에 따라 혼합 전략도 무난합니다. 

Tool Calling → LLM 직접 통합(확장성, 자동화),
RunnableLambda → 빠른 함수 조합(단계적 개발, 체인형 파이프라인)

핵심: LLM이 도구 호출을 주도하는 에이전트/챗봇엔 Tool Calling,
단순 데이터 처리에는 RunnableLambda가 간결

[펼치기]