AI 에이전트 프레임워크 2026, LangChain·LlamaIndex·OpenAI Agents 도입 기준
요약: AI 에이전트 프레임워크 도입 전 LangChain, LlamaIndex, OpenAI Agents SDK를 비용·보안·운영 기준으로 비교합니다.
AI 에이전트 프레임워크를 찾는 팀은 대개 이미 챗봇 데모를 넘어섰다. 사내 문서를 검색하고, 티켓 초안을 만들고, 코드 변경 후보를 제안하고, 경우에 따라 여러 도구를 순서대로 호출하는 워크플로우를 고민한다. 여기서 프레임워크 선택을 “예제가 짧은가”로 끝내면 운영 단계에서 비용, 권한, 품질 검증 문제가 한꺼번에 터진다.
NAVER D2가 공개한 ENGINEERING DAY 세션은 경험을 축적하고 성장하는 AI 에이전트 프레임워크라는 방향을 다룬다. 같은 D2의 Playwright E2E 테스트 하네스 글은 에이전트가 실제 브라우저 환경에서 실패하지 않도록 검증 구조를 만드는 흐름을 보여준다. 이 두 신호는 한국 개발 조직에도 같은 질문을 던진다. “어떤 프레임워크가 똑똑한가”보다 “우리 업무가 평가 가능하고, 롤백 가능하고, 권한 통제 가능한가”를 먼저 봐야 한다.
이 글은 LangChain, LangGraph, LlamaIndex, OpenAI Agents SDK, 자체 오케스트레이션을 모두 같은 기준에서 비교한다. 특정 제품을 밀기 위한 글이 아니다. 사내 LLM, RAG, 업무 자동화, 고객지원 자동화, 개발 생산성 도구를 검토하는 팀이 파일럿 전에 무엇을 적어야 하는지 정리한 실무 판단 문서다.
- AI 에이전트 프레임워크 선택은 모델 성능보다 도구 권한, 상태 관리, 평가, 로그 설계에서 갈린다.
- 문서 기반 RAG가 중심이면 LlamaIndex 계열, 복잡한 실행 흐름과 그래프 제어가 필요하면 LangGraph 계열, OpenAI 모델 중심의 가벼운 에이전트 런타임은 OpenAI Agents SDK를 먼저 볼 만하다.
- 운영 API를 호출하는 에이전트는 사람 승인, 예외 만료, 비용 상한, 실행 로그가 없으면 파일럿을 멈추는 편이 낫다.
- 30일 파일럿은 “정답률”만 재지 말고 실패한 도구 호출, 사람 검토 시간, 토큰 비용, 권한 위반 시도를 함께 기록해야 한다.
이 글이 필요한 사람
- 사내 LLM 도입을 챗봇에서 업무 자동화 에이전트로 확장하려는 개발 리더
- LangChain, LlamaIndex, OpenAI Agents SDK 중 무엇으로 파일럿을 시작할지 정해야 하는 AI 플랫폼 담당자
- 고객지원, 영업지원, 문서검색, 티켓 처리 같은 반복 업무를 에이전트로 줄이려는 운영 담당자
- 에이전트 도구 호출이 개인정보, 운영 API, 비용 폭증으로 이어질까 걱정하는 보안 담당자
- PoC 성공 후 실제 운영 전환 기준을 만들어야 하는 CTO, 팀장, 구매 담당자
AI 에이전트 프레임워크 선택에서 먼저 정할 것
프레임워크 이름부터 고르면 논의가 흐려진다. LangChain은 에이전트 하네스와 미들웨어를 조합하는 방향이 강하고, LangGraph는 결정론적 흐름과 에이전트식 흐름을 섞어야 할 때 유리하다. LlamaIndex는 사내 데이터, 문서, 인덱스, RAG 파이프라인을 에이전트 도구로 묶는 쪽에 강점이 있다. OpenAI Agents SDK는 적은 원시 개념으로 에이전트, 도구, 핸드오프, 가드레일, 트레이싱을 다루는 Python-first 접근을 제시한다.
하지만 구매 담당자나 팀장에게 필요한 답은 “어느 라이브러리가 더 유명한가”가 아니다. 우리 팀이 관리해야 할 상태가 대화 메모리인지, 파일 작업인지, 브라우저 테스트인지, 운영 API 승인인지, 문서 검색인지부터 정해야 한다. 같은 AI 에이전트 프레임워크라도 문서 질의응답, 티켓 생성, 코드 리뷰, 웹 테스트 자동화는 실패 양상이 다르다.
| 먼저 정할 질문 | 예시 답변 | 프레임워크 판단에 미치는 영향 |
|---|---|---|
| 에이전트가 읽는 데이터는 무엇인가 | 사내 위키, PDF, 코드 저장소, 고객 문의, 장애 로그 | 문서 인덱싱과 검색 품질이 핵심이면 LlamaIndex/RAG 설계 비중이 커진다. |
| 에이전트가 쓰기 작업을 하는가 | 티켓 생성, 댓글 작성, 배포 요청, CRM 수정 | 사람 승인, 롤백, 감사 로그가 없으면 쓰기 도구는 비활성화한다. |
| 흐름이 단순 호출인가 다단계 상태 기계인가 | 검색 후 요약 vs 조건별 분기와 재시도 | 그래프 기반 상태 관리가 필요하면 LangGraph나 자체 오케스트레이션을 검토한다. |
| 평가가 가능한가 | 정답 데이터셋, 실패 케이스, E2E 테스트 하네스 존재 | 테스트가 없으면 프레임워크보다 평가 데이터 구축이 먼저다. |
| 운영 비용을 추적할 수 있는가 | 토큰, 도구 호출, 실패 재시도, 사람 검토 시간 | 비용 로그가 없으면 PoC 결과를 운영 예산으로 환산하기 어렵다. |
LangChain·LlamaIndex·OpenAI Agents SDK 비교
공식 문서를 기준으로 보면 세 도구는 겹치는 부분이 있지만 출발점이 다르다. LangChain은 모델, 도구, 프롬프트, 미들웨어를 조합해 에이전트 하네스를 만드는 쪽이다. LlamaIndex는 LLM이 사내 데이터에 접근하도록 커넥터, 인덱스, 검색, 워크플로우를 묶는 데 초점을 둔다. OpenAI Agents SDK는 에이전트, 도구, 핸드오프, 가드레일, 트레이싱 같은 원시 개념을 적게 두고 Python 코드로 흐름을 짜는 방식에 가깝다.
| 선택지 | 맞는 상황 | 주의할 점 | 파일럿 기준 |
|---|---|---|---|
| LangChain / LangGraph | 도구 호출, 미들웨어, 그래프형 워크플로우, 여러 모델 연동을 세밀하게 제어해야 할 때 | 추상화가 많아지면 팀원이 흐름을 읽기 어려워질 수 있다. | 상태 전이, 재시도, 사람이 승인하는 지점을 다이어그램과 로그로 남긴다. |
| LlamaIndex | 사내 문서, PDF, DB, API 데이터를 검색·인덱싱하고 에이전트 도구로 연결해야 할 때 | RAG 품질이 낮으면 에이전트가 잘못된 근거로 행동한다. | 검색 근거 노출률, 출처 누락률, 오래된 문서 사용 여부를 측정한다. |
| OpenAI Agents SDK | OpenAI 모델 중심으로 빠르게 에이전트, 도구, 핸드오프, 가드레일, 트레이싱을 만들 때 | 특정 모델·플랫폼 의존도가 생길 수 있다. | 도구 스키마, 가드레일 실패 처리, 트레이싱 데이터 보관 기준을 정한다. |
| 자체 오케스트레이션 | 프레임워크 의존을 줄이고 기존 백엔드/워크플로우 엔진과 깊게 붙여야 할 때 | 평가·트레이싱·도구 스키마를 직접 만들어야 한다. | 유지보수 담당자, 장애 대응, 문서화를 비용에 포함한다. |
조건부 결론은 간단하다. “문서를 잘 찾아 답하는 직원”이 목표라면 검색 품질과 데이터 파이프라인부터 본다. “여러 도구를 사용해 업무를 끝내는 동료”가 목표라면 상태 관리와 도구 권한을 본다. “코드 리뷰나 브라우저 테스트를 대신 수행하는 실행자”가 목표라면 샌드박스, E2E 테스트, 실행 로그를 먼저 본다. 프레임워크는 그다음이다.
실무 시나리오 1: 고객지원 티켓 초안 에이전트
첫 번째 시나리오는 고객지원 티켓 초안 생성이다. 에이전트가 고객 문의를 읽고, 사내 도움말과 장애 공지를 검색하고, 답변 초안을 만들어 상담원이 승인한다. 이 경우 에이전트가 직접 고객에게 메시지를 보내면 안 된다. 초안 생성까지만 허용하고, 발송은 사람 승인 뒤 기존 상담 시스템에서 처리하는 편이 안전하다.
이 시나리오에서는 LlamaIndex 같은 데이터 중심 프레임워크가 먼저 검토 대상이 된다. 이유는 모델의 말솜씨보다 근거 문서가 맞는지가 더 중요하기 때문이다. 오래된 정책 문서, 지역별 예외, 약관 변경 사항이 섞여 있으면 답변 품질이 흔들린다. 따라서 프레임워크 비교표에는 검색 근거 표시, 문서 최신성, 출처별 신뢰도, 질의 로그 마스킹 기능을 넣어야 한다.
비용 계산도 토큰만 보면 부족하다. 실패한 초안이 상담원 검토 시간을 얼마나 늘렸는지, 잘못된 근거 때문에 재문의가 늘었는지, 상담원이 초안을 얼마나 수정했는지를 같이 봐야 한다. “모델 호출 비용은 낮지만 상담원 수정 시간이 길다”면 자동화가 아니라 업무를 한 단계 더 만든 셈이다.
실무 시나리오 2: 개발팀 코드·브라우저 테스트 에이전트
두 번째 시나리오는 개발팀 에이전트다. 이 에이전트는 이슈를 읽고, 관련 코드를 찾고, 테스트를 실행하고, 브라우저에서 화면이 깨지지 않는지 확인한다. NAVER D2의 Playwright E2E 테스트 하네스 주제처럼 에이전트가 실제 웹 환경을 다룰수록 “실행 결과가 재현 가능한가”가 핵심이 된다.
이 경우에는 LangGraph나 OpenAI Agents SDK처럼 도구 호출, 실행 상태, 실패 재시도, 핸드오프를 명확히 남길 수 있는 구조가 필요하다. 브라우저 자동화 도구는 강력하지만 위험하다. 로그인 세션, 테스트 계정, 결제 버튼, 운영 데이터 접근을 잘못 열면 작은 PoC가 사고가 된다. 따라서 개발 에이전트는 기본적으로 샌드박스 저장소, 테스트 환경, 읽기 전용 토큰, 승인된 명령 목록에서만 움직여야 한다.
이 조건이면 검토할 만하다. 테스트 케이스가 이미 있고, 스테이징 환경이 분리돼 있으며, 실패 로그를 개발자가 재현할 수 있고, 에이전트가 만든 변경 사항을 사람이 리뷰한다면 파일럿 가치가 있다. 반대로 테스트가 거의 없고 운영 DB 접속이 개발자 로컬에 열려 있다면 에이전트 프레임워크보다 개발 환경 격리가 먼저다.
비용·보안·운영 리스크를 숫자로 잡는 법
AI 에이전트 프레임워크 도입비는 패키지 비용으로 끝나지 않는다. 모델 비용, 벡터 DB 또는 검색 인프라, 로그 저장, 평가 데이터 구축, 사람 검토 시간, 실패 재시도, 보안 리뷰 시간이 모두 들어간다. 특히 에이전트는 한 번의 사용자 요청 안에서 여러 번 모델을 호출하고 도구를 실행할 수 있다. 챗봇보다 비용 편차가 커지는 이유다.
| 리스크 | 실제 확인 항목 | 게이트 기준 |
|---|---|---|
| 비용 폭증 | 요청당 모델 호출 횟수, 도구 호출 수, 재시도 수, 실패 실행률 | 주간 예산 상한과 알림을 두고, 초과 시 자동 중지한다. |
| 권한 과다 | 도구별 읽기/쓰기 권한, 운영 API 접근, 승인 필요 여부 | 쓰기 작업은 기본 비활성화하고 사람 승인 없이는 실행하지 않는다. |
| 근거 없는 답변 | 검색 근거 누락률, 오래된 문서 사용, 출처 표시 실패 | 출처 없는 답변은 초안으로도 사용하지 않는 규칙을 둔다. |
| 테스트 부재 | 정답 세트, 회귀 테스트, 브라우저 E2E 케이스, 실패 샘플 | 최소 50개 이상 평가 케이스 없이 운영 전환하지 않는다. |
| 운영 불투명 | 트레이싱, 실행 로그, 프롬프트/도구 버전, 담당자 승인 이력 | 장애 발생 시 한 실행을 재구성할 수 있어야 한다. |
보안팀 관점에서는 “모델이 무엇을 아는가”보다 “에이전트가 무엇을 할 수 있는가”가 더 중요하다. 문서를 읽는 에이전트와 결제 취소 API를 호출하는 에이전트는 위험 등급이 다르다. 프레임워크가 아무리 좋아도 도구 권한을 한 덩어리로 열어두면 내부 자동화가 내부 공격 표면이 된다.
파일럿 순서: 데모보다 평가셋부터
AI 에이전트 파일럿은 멋진 데모 영상을 만드는 순서가 아니다. 먼저 성공과 실패를 기록할 수 있어야 한다. 평가셋이 없으면 프레임워크 비교가 취향 싸움이 된다. 같은 30개 업무 요청을 LangChain, LlamaIndex, OpenAI Agents SDK, 자체 구현에 넣어보고 결과 품질, 비용, 실패 원인, 개발 시간을 비교해야 한다.
- 업무 범위 제한: 고객지원 초안, 내부 문서 질의, 티켓 분류처럼 실패해도 되돌릴 수 있는 업무 1개를 고른다.
- 평가셋 작성: 실제 문의나 이슈에서 개인정보를 제거한 뒤 정답 근거와 금지 행동을 붙인다.
- 도구 목록 분리: 읽기 도구, 쓰기 도구, 운영 API 도구를 나누고 쓰기 도구는 승인 전 비활성화한다.
- 프레임워크 2~3개 비교: 모든 후보를 다 보려 하지 말고 데이터 중심, 그래프 중심, 경량 SDK 중심으로 대표만 고른다.
- 로그와 비용 수집: 요청별 토큰, 도구 호출, 실패 재시도, 사람 검토 시간을 같은 형식으로 저장한다.
- 보류 조건 명시: 권한 위반 시도, 출처 없는 답변, 예산 초과, 회귀 실패가 일정 기준을 넘으면 파일럿을 멈춘다.
- 운영 전환 판단: 성공률만 보지 말고 사람이 줄인 시간, 사고 가능성, 유지보수 난이도를 함께 본다.
실무 스켈레톤: 프레임워크 파일럿 정책
아래 YAML은 실제 프레임워크 설정 파일이 아니다. 도입 전에 팀이 합의해야 할 범위, 도구 권한, 평가 기준, 비용 추적 항목을 한 장으로 묶는 정책 스켈레톤이다. 이 문서가 없으면 PoC는 성공해도 운영 전환 회의에서 막힌다.
# agent-framework-pilot.yaml
# 목적: 특정 프레임워크를 바로 적용하는 설정이 아니라, 도입 검토 범위와 통제 항목을 합의하기 위한 스켈레톤이다.
organization:
owner: ai-platform-team
reviewers: [security-team, backend-team, legal-or-privacy-owner]
target_use_case: internal-research-and-ticket-triage
data_classification: internal-only
pilot_scope:
duration_days: 30
frameworks_to_compare:
- langchain_or_langgraph
- llamaindex_workflows
- openai_agents_sdk
- custom_orchestration
allowed_tools:
- name: search_internal_docs
data_access: internal-documents
approval_required: false
- name: create_ticket_draft
data_access: issue-tracker
approval_required: true
- name: call_production_api
data_access: production-system
approval_required: true
default_enabled: false
quality_and_safety_gates:
min_eval_cases: 50
require_tool_call_log: true
require_human_approval_for_write_actions: true
block_personal_data_export: true
rollback_trigger:
- hallucinated_action_above_threshold
- unauthorized_tool_attempt
- cost_per_successful_task_exceeds_budget
cost_tracking:
measure:
- model_input_tokens
- model_output_tokens
- tool_calls
- failed_runs
- human_review_minutes
report_cycle: weekly
정책 파일의 핵심은 “무엇을 허용하지 않을지”를 먼저 적는 것이다. 특히 운영 API 호출, 고객에게 직접 발송, 개인정보가 포함된 문서 반출, 비용 상한 없는 반복 실행은 파일럿 초기에 막아야 한다. 도구를 덜 열어도 된다. 처음부터 많이 열면 어떤 실패가 프레임워크 문제이고 어떤 실패가 권한 설계 문제인지 구분하기 어렵다.
배포 전 점검 스크립트 예시
다음 Python 스크립트는 실제 LangChain, LlamaIndex, OpenAI API를 호출하지 않는다. 정책 스켈레톤에 최소 통제 항목이 있는지만 점검한다. 이런 검사는 단순해 보여도 파일럿 회의에서 빠지는 항목을 줄여준다. 실제 환경에서는 YAML 스키마 검증, 시크릿 검사, 도구 권한 매핑, CI 검사를 더 붙이면 된다.
#!/usr/bin/env python3
# AI 에이전트 프레임워크 파일럿 전, 최소 통제 항목이 빠지지 않았는지 점검하는 예시다.
# 실제 API 키나 운영 계정 ID를 코드에 넣지 않는다.
from __future__ import annotations
import sys, yaml
from pathlib import Path
REQUIRED_GATES = {
'min_eval_cases',
'require_tool_call_log',
'require_human_approval_for_write_actions',
'block_personal_data_export',
}
def stop(message: str) -> None:
print('[FAIL] ' + message)
raise SystemExit(1)
def main(path: str) -> None:
data = yaml.safe_load(Path(path).read_text(encoding='utf-8'))
frameworks = data.get('pilot_scope', {}).get('frameworks_to_compare', [])
if len(frameworks) < 2:
stop('비교 대상 프레임워크가 2개 미만입니다. 구매/도입 판단용 파일럿으로 보기 어렵습니다.')
tools = data.get('pilot_scope', {}).get('allowed_tools', [])
for tool in tools:
if tool.get('data_access') == 'production-system' and tool.get('default_enabled') is not False:
stop(f"{tool.get('name')} 운영 API 도구는 기본 비활성화가 안전합니다.")
if tool.get('approval_required') is not True and 'create' in tool.get('name', ''):
stop(f"{tool.get('name')} 쓰기성 도구에 사람 승인 조건이 없습니다.")
gates = set((data.get('quality_and_safety_gates') or {}).keys())
missing = REQUIRED_GATES - gates
if missing:
stop('누락된 품질/보안 게이트: ' + ', '.join(sorted(missing)))
print('[OK] 파일럿 스켈레톤 기본 점검 통과. 이제 각 프레임워크 공식 문서 기준으로 구현 가능 범위를 확인하세요.')
if __name__ == '__main__':
if len(sys.argv) != 2:
stop('usage: python check_agent_framework_pilot.py agent-framework-pilot.yaml')
main(sys.argv[1])
도입을 보류해야 하는 경우
다음 조건이면 프레임워크 구매나 구현을 서두르지 않는 편이 낫다. 첫째, 에이전트가 처리할 업무가 아직 문장으로 정의되지 않았다. “업무 자동화”라고만 쓰여 있고 성공 기준이 없으면 어떤 프레임워크도 평가할 수 없다. 둘째, 사내 문서 품질이 낮다. 오래된 문서와 최신 정책이 섞여 있으면 RAG 기반 에이전트는 그 혼란을 더 빠르게 출력한다. 셋째, 운영 API 권한이 개인 계정이나 공유 토큰에 묶여 있다. 이 상태에서 도구 호출을 붙이면 사고 추적이 어렵다.
넷째, 보안팀과 법무/개인정보 담당자가 파일럿 범위를 모른다. 고객 데이터, 직원 데이터, 소스코드, 장애 로그가 들어가는 순간 검토 대상이 바뀐다. 다섯째, 실패했을 때 되돌리는 절차가 없다. 에이전트가 잘못 만든 티켓, 잘못 분류한 문의, 잘못 실행한 테스트 결과를 사람이 어떻게 되돌릴지 정하지 않으면 운영팀이 위험을 떠안는다.
30일 파일럿 체크리스트
| 주차 | 할 일 | 통과 기준 |
|---|---|---|
| 1주차 | 업무 범위, 평가셋, 도구 목록, 금지 행동 정의 | 성공/실패 케이스가 문서화되고 보안 리뷰 담당자가 지정된다. |
| 2주차 | 프레임워크 2~3개로 같은 평가셋 실행 | 결과 품질, 비용, 실패 원인을 같은 표로 비교한다. |
| 3주차 | 사람 승인 흐름, 로그, 권한 만료, 비용 알림 연결 | 쓰기성 도구가 승인 없이 실행되지 않고 트레이싱이 남는다. |
| 4주차 | 실제 업무 일부에 제한 적용 후 운영 전환 판단 | 절감 시간, 실패율, 보안 이슈, 유지보수 비용이 기준 안에 들어온다. |
파일럿 결과가 애매하면 보류가 정답일 수 있다. AI 에이전트는 “조금 틀려도 귀여운 데모”가 아니라 업무를 실제로 움직이는 실행 계층이다. 정확도 90%라는 숫자만 보고 운영에 넣으면 나머지 10%가 승인 없는 쓰기 작업, 잘못된 고객 안내, 비용 폭증으로 나타날 수 있다.
함께 보면 좋은 글
자주 묻는 질문
AI 에이전트 프레임워크는 챗봇 프레임워크와 무엇이 다른가요?
챗봇은 대화 응답이 중심인 경우가 많다. 에이전트 프레임워크는 모델이 도구를 호출하고, 상태를 유지하고, 여러 단계를 거쳐 업무 결과물을 만들도록 돕는 실행 구조까지 포함한다. 그래서 권한, 로그, 평가, 사람 승인 설계가 더 중요해진다.
LangChain과 LlamaIndex 중 무엇을 먼저 봐야 하나요?
사내 데이터 검색과 RAG 품질이 핵심이면 LlamaIndex를 먼저 검토할 만하다. 여러 도구 호출, 미들웨어, 그래프형 워크플로우가 핵심이면 LangChain/LangGraph 쪽을 먼저 비교하는 편이 낫다. 업무 성격이 기준이지 유행이 기준이 아니다.
OpenAI Agents SDK만으로 운영 에이전트를 만들 수 있나요?
공식 문서 기준으로 에이전트, 도구, 핸드오프, 가드레일, 트레이싱 같은 기본 원시 개념을 제공한다. 다만 운영 전환에는 데이터 보관, 권한 정책, 비용 상한, 평가셋, 사내 시스템 연동 기준이 별도로 필요하다.
AI 에이전트 파일럿 비용은 어떻게 계산해야 하나요?
모델 토큰 비용만 계산하면 부족하다. 도구 호출, 실패 재시도, 벡터 DB나 검색 인프라, 로그 저장, 사람 검토 시간, 보안 리뷰 시간을 함께 잡아야 실제 운영 예산에 가까워진다.
프레임워크 없이 직접 만들면 더 안전한가요?
직접 만들면 의존성은 줄지만 평가, 트레이싱, 도구 스키마, 재시도, 권한 분리, 문서화를 직접 책임져야 한다. 이미 백엔드 플랫폼 역량이 강한 팀이면 가능하지만, 작은 팀은 검증된 프레임워크를 제한적으로 쓰는 편이 더 안전할 수 있다.
출처와 확인일
- NAVER D2 — 도구에서 동료로 — AI 에이전트 자율 성장 프레임워크 (확인일: 2026-06-20)
- NAVER D2 — AI 에이전트를 위한 Playwright E2E 테스트 하네스 구축하기 (확인일: 2026-06-20)
- LangChain Docs — LangChain overview and agent harness (확인일: 2026-06-20)
- LlamaIndex Docs — Framework for building LLM-powered agents over your data (확인일: 2026-06-20)
- OpenAI Agents SDK — OpenAI Agents SDK documentation (확인일: 2026-06-20)
이 글은 일반적인 IT 도입 판단 가이드다. 각 프레임워크의 기능, 가격, 라이선스, API, 호스팅 방식은 변경될 수 있다. 실제 도입 전에는 공식 문서와 계약 조건을 다시 확인하고, 보안·개인정보·법무 검토가 필요한 업무는 조직의 내부 절차를 따라야 한다. 네이버 검색 수요 데이터는 후보 선정용으로만 사용했고 본문 출처로 쓰지 않았다.
댓글
댓글 쓰기