LangChain · LCEL · Runnable

LCEL로 프롬프트·모델·파서 연결하기

LangChain Runnable을 파이프로 조합해 입력이 프롬프트와 모델, 출력 파서를 지나는 과정을 확인합니다.

무료 공개 · 최근 수정

단계가 있는 모델 호출 만들기

모델 애플리케이션은 사용자 문자열을 그대로 모델에 보내는 데서 끝나지 않습니다. 입력값을 검증하고 프롬프트에 넣은 뒤 모델을 호출하며, 반환 메시지를 화면이나 다른 함수가 사용할 자료형으로 바꿔야 합니다. 이 과정을 하나의 큰 함수로 작성하면 어느 단계에서 형식이 바뀌었는지 찾기 어렵고, 모델이나 출력 형식 하나를 바꾸기 위해 전체 코드를 수정하게 됩니다.

LangChain 표현 언어(LangChain Expression Language; LCEL)는 각 처리 단계를 Runnable이라는 공통 인터페이스로 다루고 | 연산자로 연결합니다. 셸 파이프에서 앞 명령의 출력이 다음 명령의 입력이 되듯, 프롬프트의 출력은 모델 입력이 되고 모델의 출력은 파서 입력이 됩니다. 핵심은 짧게 쓰는 문법보다 각 단계의 입력과 출력 계약을 드러내는 데 있습니다.

입력값이 프롬프트 템플릿과 채팅 모델, 문자열 출력 파서를 차례로 통과하는 흐름

그림: 각 Runnable의 출력이 다음 Runnable의 입력으로 전달됩니다.

Ollama가 실행 중인 환경에서 다음 예제를 사용할 수 있습니다.

pip install -U langchain-core langchain-ollama
from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import ChatPromptTemplate
from langchain_ollama import ChatOllama
 
prompt = ChatPromptTemplate.from_template(
    "{topic}을 처음 배우는 사람에게 두 문장으로 설명해 줘."
)
model = ChatOllama(model="gemma3:1b", temperature=0)
chain = prompt | model | StrOutputParser()
 
print(chain.invoke({"topic": "AI 에이전트"}))

출력 문장은 모델과 버전에 따라 달라집니다. 확인해야 할 것은 고정된 답이 아니라 딕셔너리 입력이 프롬프트로 변환되고, 모델 메시지가 마지막에 문자열로 바뀐다는 점입니다.

이 예제의 자료형은 다음 순서로 변합니다.

  1. {"topic": "AI 에이전트"} 딕셔너리가 템플릿 변수에 들어갑니다.
  2. 프롬프트 Runnable이 모델이 읽을 메시지 묶음을 만듭니다.
  3. 채팅 모델이 응답 메시지 객체를 반환합니다.
  4. StrOutputParser가 메시지에서 문자열 내용을 꺼냅니다.

각 경계를 알고 있으면 다음 단계를 연결할 때 어떤 값을 넘겨야 하는지 예측할 수 있습니다. 예를 들어 문자열을 기대하는 함수에 메시지 객체가 들어가 생긴 오류는 모델 품질 문제가 아니라 파이프라인 계약 문제입니다.

파이프라인 경계를 관찰하기

파이프를 짧게 만들면 각 단계의 책임과 실패 위치가 분명해집니다. 템플릿 변수 누락은 모델 호출 전에 발생하고, 모델 연결 오류는 모델 단계에서 발생하며, 형식 불일치는 파서에서 드러납니다. 처음에는 전체 체인만 실행하지 말고 프롬프트 결과와 모델 응답을 따로 출력해 경계를 확인하는 것이 좋습니다. 구조화된 JSON이 필요하다면 단순 문자열 파서 대신 필드와 자료형을 선언한 스키마 검증을 결합합니다.

Runnable은 같은 구성 요소를 단일 호출, 여러 입력의 일괄 처리나 스트리밍 같은 실행 방식으로 다룰 수 있게 합니다. 그렇다고 모든 체인을 길게 연결해야 하는 것은 아닙니다. 서로 다른 재시도 정책이나 접근 권한이 필요한 단계는 별도 함수나 서비스 경계로 분리하는 편이 낫습니다. 재사용 가능성과 오류 격리가 파이프 길이보다 중요한 기준입니다.

LCEL이 실행 권한이나 에이전트 반복을 자동으로 제공하는 것은 아닙니다. LCEL 체인은 정해진 단계의 데이터 흐름을 조합하는 데 적합하고, 실행 결과에 따라 이전 단계로 돌아가는 상태 머신은 별도의 제어 구조가 필요합니다. 문서 검색을 앞에 붙이면 RAG가 되고, 도구 선택과 반복 제어를 결합하면 에이전트 구조가 됩니다.

참고 문서

설명이 어렵거나 잘못된 부분을 발견하셨나요?

문서 수정 의견 보내기