대량의 데이터 처리(예: 문서 수십만 건 임베딩화, FAQ 1000개 답변 생성)
여러 사용자의 요청을 동시에 응답할 때 서버에서 활용
영어 기사 100개를 한글로 번역할 때, 1~100번을 각각 순차 실행하면 시간이 엄청 걸림.
병렬화 사용 시, 10개씩 한 번에 10조(10x10)로 쪼개 동시에 보내 훨씬 빨리 끝남.
특정 ‘LLM 모델’이나 ‘외부 서비스’가 실패하거나 제한 상태일 때, 자동으로 후보 모델이나 다른 방식으로 재시도하는 로직이 미리 설정되어 있음.
try/except 구조나 조건문, 체인 설정 내에서 전환
API 한도가 찼거나, 서버 오류 발생시 시스템 안정성 확보
“최소한의 결과”라도 꼭 반환해야 할 때
OpenAI 모델이 다운됐을 때, 자동으로 HuggingFace LLM 또는 내 서버의 LLM으로 요청을 넘김.
법률 문서 요약 중 특수한 에러 발생시, 요약 없이 원문을 리턴하도록 함.
각 단계에서 입력, 처리, 출력, 오류 등을 모니터링 및 기록(log).
전체 workflow의 시간, 에러, 프롬프트 내용, LLM 응답 등 전 과정을 추적할 수 있게 해줌.
작업 과정 성능 분석, 디버깅이 필요한 복잡한 LLM chain
API 응답 지연/실패 시 원인 추적
여러 데이터 묶음을 하나의 큰 묶음(batch)으로 만들어 동시에 서버에 쏩니다.
LLM API는 보통 여러 input을 리스트로 받아 한 번에 처리할 수 있습니다(입력 길이 주의).
비용/속도 최적화
LLM의 입력 요청 단위 개수가 꽤 클 때
LLM이 토큰 하나씩 출력할 때마다, 결과를 실시간으로 바로 클라이언트에 전송.
chunk 단위 데이터 전송, SSE(Server Sent Events) 등 다양한 기술 활용
챗봇, 실시간 문서 생성, UX 개선
사용자가 “답변 대기시간”을 체감 못하게 할 때
ChatGPT처럼, 답변이 한 글자 한 글자 눈앞에서 실시간 생성됨.
뉴스 요약 서비스에서 긴 문장이 바로 생성될 때, 첫 문장부터 바로 표시
한 작업(예: LLM 요청)이 끝날 때까지 기다리지 않고, 다른 작업을 동시에 진행할 수 있게 프로그래밍.
Python의 async/await, JavaScript의 Promise 등과 유사
API 호출/응답 속도가 오래 걸리는 경우
여러 사용자의 동시 요청 처리
10명의 사용자가 동시에 챗봇 서비스를 시작
각자의 요청/응답이 병렬로 돌아가며, 남들 요청이 끝나기 전에도 내 요청은 기다릴 필요 없이 비동기적으로 처리됨
여러 체인(chain)이나 도구(tool), 프롬프트(template)를 블록처럼 이어붙여 복잡한 워크플로우를 만듦.
함수 조립, 체인에 체인 연달아 붙이기 등이 전형적
복잡한 다단계 프로세스(검색→선별→가공→포맷화…)
재사용성과 모듈화가 중요한 서비스
유저 질문 → 관련 문서 검색(벡터DB) → 답변 요약 → 결과를 이메일 양식으로 변환 → 전송
여러 LLM output을 종합해 최종 의사결정 안내문 작성
[사용자 입력]
↓
[병렬화: 여러 후보 질문 동시 제출]
↓
[배칭: 질문 묶어서 LLM에 전달]
↓
[트레이싱: 각 단계 로깅]
↓
[검색 실패시 폴백으로 로직 변경]
↓
[스트리밍으로 결과 실시간 표시]
↓
[여러 체인/도구를 조합해 최종 결과 가공]
↓
[결과 제공]
이렇게 각 기능이 고도화된 LLM 워크플로우(즉, LangChain Core)가 “더 빠르고, 안전하고, 신뢰가능하고, 재사용/유지보수 쉬운 AI 서비스를 만드는 데” 핵심기술로 쓰입니다!