AI 에이전트 기본기 Q&A — 왜 에이전트인가부터 프레임워크 선택까지 24문답
에이전트가 무엇이고 언제 쓰지 않아야 하는지, 네 프레임워크가 무엇으로 갈리는지를 결론부터 정리하고, 자주 굳어지는 오해를 함께 교정한다.
에이전트를 설계하다 보면 같은 질문이 반복해서 돌아온다. "이건 에이전트로 만들어야 하나", "LangChain과 LangGraph 중 무엇을 쓰나", "RAG는 아직 필요한가" 같은 것들이다. 이 글은 그 질문들에 결론부터 답하고 근거를 뒤에 붙인다.
절반은 오해를 교정하는 문항이다. "에이전트는 LLM에 도구를 붙인 것", "RAG를 쓰면 환각이 사라진다", "chunk_size=500이면 청크가 500자" 같은 직관이 왜 틀렸는지가 실제로는 더 중요하다.
실행 모델 쪽 질문은 실행 모델 Q&A, 멀티에이전트와 제품 구현은 멀티에이전트 Q&A, 신뢰성·비용·안전·조직은 운영 Q&A로 나눠 두었다.
핵심 판정 기준 정리
설계에서 반복해 등장하는 갈림길들이다. 값이 아니라 무엇으로 가르는가가 요점이다.
| 판정 | 기준 | 왜 그 기준인가 |
|---|---|---|
| 에이전트인가 워크플로인가 | 경로를 누가 정하는가 | 사람이 미리 정했으면 워크플로다. LLM이 런타임에 정하면 에이전트다. 도구 개수가 아니다 |
| 그래프인가 체인인가 | 순환·조건분기·중단 재개의 필요 여부 | 에이전트 개수가 아니다. 단일 에이전트도 도구 루프가 있으면 그래프가 맞다 |
| 에이전트를 쓰지 않을 때 | 흐름이 선형이고 분기가 없을 때 | 에이전트는 비결정성·비용·지연을 모두 늘린다. 결정적으로 풀 수 있는 문제는 결정적으로 |
| 추상화와 제어권 | 반비례한다 | 역할만 정의하면 굴러가는 편의를 얻으면, 특정 조건에서 되돌아가게 만드는 일이 어려워진다 |
| RAG의 병목 | 생성이 아니라 검색 | Pre-Retrieval(로더 정제·청킹·임베딩)이 먼저이고 리랭커는 그다음이다 |
| 청크 크기 | 글자 수가 아니라 답변에 필요한 최소 의미 단위 | 숫자부터 정하면 왜 그 값인지 설명할 수 없다. 청킹 후 길이 분포를 찍어 검증한다 |
| 파인튜닝과 RAG | 해결하는 문제가 다르다 | RAG는 지식(갱신·출처), 파인튜닝은 행동양식(형식·톤·도메인 표현) |
Q. 왜 에이전트가 필요한가
Naive RAG가 검색 실패를 스스로 모르기 때문이다.
LLM은 학습 시점 밖을 모르고, 그래서 RAG로 근거를 주입했다. 그런데 검색이 빗나가도 시스템은 그 사실을 알아채지 못하고 잘못된 문서 위에 그럴듯한 답을 만든다. 실패를 판정하고 쿼리를 고쳐 되돌아가려면 판단 주체와 사이클이 있어야 한다.
| 계층 | 무엇이 문제인가 | 해법 | 그래도 남는 문제 |
|---|---|---|---|
| LLM 단독 | 학습 시점 이후를 모름 | 외부 근거 주입 | 근거를 어떻게 찾나 |
| LLM 단독 | 지난 대화를 기억 못 함 | 이력을 상태로 저장 | 길어지면 토큰 초과 |
| Naive RAG | 검색 실패를 감지 못 함 | 관련성·환각 판정 노드 | 루프 제어 구조 필요 |
| DAG 체인 | 되돌아가는 흐름을 표현 못 함 | 사이클 지원 실행기 | 종료 조건 설계 필요 |
각 계층의 상세는 AI 에이전트란 무엇인가에 있다.
Q. 에이전트를 어떻게 정의하나
"LLM에 도구를 붙인 것"은 절반만 답한 것이다.
도구는 절반이고, 계획 수립과 자기 검토 루프가 나머지다. 도구만 있으면 함수 호출기지 에이전트가 아니다. 루프 형태의 기준선이 ReAct — 추론 → 도구 호출 → 관찰의 반복이다.
| 구성요소 | 역할 |
|---|---|
| LLM | 판단 |
| Tool | 외부 실행 |
| Planning | 작업 분해 |
| Memory | 상태 |
Q. 챗봇과 에이전트는 무엇이 다른가
반복을 누가 감당하는가가 다르다.
챗봇은 사람이 재질문을 던져 품질을 올린다. 에이전트는 계획·도구·자기검토 루프로 스스로 올린다. 화면이 같아 보여도 실패했을 때 누가 다시 시도하는지가 갈린다.
Q. 워크플로와 에이전트는 무엇으로 가르나
경로를 누가 정하는가다.
사람이 코드로 미리 정해 두었으면 워크플로이고, LLM이 런타임에 다음 단계를 고르면 에이전트다. 판단 기준을 오류 비용과 복잡도의 2×2로 두면 대부분의 사례가 갈린다 — 자세한 것은 워크플로와 에이전트의 경계에 있다.
Q. 에이전트를 안 쓰는 게 맞는 경우는 언제인가
흐름이 선형이고 분기가 없을 때다.
에이전트는 비결정성·비용·지연을 전부 늘린다. 결정적으로 풀 수 있는 문제를 LLM 라우팅에 맡기면 재현성만 잃는다. 순서가 정해진 구간은 고정 엣지로 빼는 것이 원칙이다.
Q. RAG를 왜 쓰나
재학습 대신 답할 근거를 그때그때 주입하는 방식이기 때문이다.
환각·기억불가·토큰상한이라는 세 한계에 동시에 대응한다. 셋 중 앞의 둘은 "모르는 것"의 문제라 외부 근거로 메울 수 있고, 토큰 상한은 그 근거를 얼마나 넣을 수 있는지의 문제라 성격이 다르다.
Q. 컨텍스트 윈도우가 커졌는데 RAG가 아직 필요한가
필요하다. 길이는 늘었지만 비용·지연·중간 정보 소실이 남는다.
전체를 넣는 것과 필요한 것만 넣는 것은 다른 문제다. 컨텍스트가 길어질수록 중간 구간의 검색 정확도가 떨어지는 현상도 관측된다 — 관련 실측은 하네스를 만드는 다섯 가지에 있다.
Q. RAG의 진짜 병목은 어디인가
생성이 아니라 검색이다.
| 구간 | 하는 일 | 순서 |
|---|---|---|
| Pre-Retrieval | 로더 정제·청킹·임베딩·색인 | 먼저 |
| Retrieval | 질의로 후보를 뽑음 | 다음 |
| Post-Retrieval | 재순위·선별 | 그다음 |
리랭커부터 손대는 경우가 많은데, 앞단이 부실하면 재순위가 살릴 후보 자체가 없다.
Q. 청크 크기는 어떻게 정하나
글자 수부터 정하지 않는다. 답변에 필요한 최소 의미 단위를 먼저 정하고, 청킹 후 길이 분포를 찍어 검증한다.
숫자를 먼저 정하면 왜 그 값인지 설명할 수 없고, 도메인이 바뀔 때 근거 없이 다시 추측하게 된다. 실제 분할 결과가 어떻게 어긋나는지는 LangChain으로 RAG 파이프라인 만들기에 실측과 함께 있다.
Q. chunk_size=500이면 청크가 500자인가
아니다. 목표치일 뿐이다.
스플리터가 지정한 구분자를 못 찾으면 초과한다. 실제로 수천 자짜리 청크가 나오는 경우가 흔하다. 설정값을 결과로 착각하면 "왜 검색이 안 되나"를 엉뚱한 곳에서 찾게 된다.
Q. 임베딩 모델을 바꾸려면 어떻게 하나
전체 재색인이다.
질문과 문서가 같은 벡터 공간에 있어야 하므로 부분 교체가 불가능하다. 모델 교체는 코드 한 줄이지만 색인 비용은 전체 문서 수에 비례한다.
Q. 벡터 검색이 키워드 검색보다 나은가
우열이 아니라 다른 실패 모드를 가진다.
| 방식 | 강한 곳 | 약한 곳 |
|---|---|---|
| 벡터 | 의미가 비슷한 표현, 동의어 | 사번·상품코드·심볼명 같은 정확 일치 |
| 키워드 | 고유명사·식별자 | 표현이 다른 같은 뜻 |
실무 정답은 대체로 하이브리드다.
Q. 벡터DB는 무엇을 기준으로 고르나
성능보다 운영 기준이다.
이미 쓰는 DB에 얹을 수 있는지, 메타데이터 필터가 되는지, 키워드 검색과 섞어야 하는지를 먼저 본다. 벤치마크 수치는 대개 워크로드가 다르다.
Q. RAG를 쓰면 환각이 없어지나
줄어들 뿐 사라지지 않는다.
검색이 빗나가면 엉뚱한 문맥 위에 그럴듯한 답을 만든다. 근거를 붙였다는 사실과 그 근거가 맞다는 사실은 다르다. 검증 노드를 붙여도 보장 범위가 어디까지인지는 groundedness와 그 대가에서 따로 다룬다.
Q. 파인튜닝 대신 RAG를 하면 되나
양자택일이 아니다. 해결하는 문제가 다르다.
| RAG | 파인튜닝 | |
|---|---|---|
| 다루는 것 | 지식 | 행동양식 |
| 강한 곳 | 갱신·출처 표시 | 형식·톤·도메인 표현 |
| 바뀔 때 비용 | 색인만 다시 | 학습을 다시 |
지식이 자주 바뀌면 RAG, 출력 형태가 고정돼야 하면 파인튜닝이다.
Q. LangChain과 LangGraph는 무엇이 다른가
LangChain 체인은 한 방향으로 흐르고 끝나는 사실상 DAG이고, LangGraph는 순환 가능한 상태 그래프다.
결정적 차이는 반복 횟수가 런타임에 정해진다는 점이다. 도구를 몇 번 부를지 미리 알 수 없는 에이전트는 DAG로 표현되지 않는다.
배타 관계가 아니다. 실무 조합은 노드 안쪽을 LCEL 체인으로 짜고, 노드 사이의 흐름·상태·반복을 LangGraph가 관장하는 형태다. 두 축의 비교는 체크포인터·HITL 편에 아홉 축으로 정리돼 있다.
Q. 멀티 에이전트면 그래프, 단일이면 체인인가
개수를 기준으로 답하면 어긋난다.
기준은 순환·조건분기·상태 공유·중단 재개의 필요 여부다. 단일 에이전트라도 도구 루프가 있으면 그래프가 맞고, 여러 역할이 순서대로만 도는 파이프라인이면 체인으로 충분하다.
Q. LangGraph를 쓰려면 LangChain이 필수인가
아니다. 같은 회사가 만들었지만 LangChain 없이 사용 가능하다.
LCEL 체인을 노드 안에서 쓰면 편리하지만 의존은 아니다. 이 오해가 "LangGraph를 도입하면 LangChain 전체를 들여야 한다"는 판단으로 이어지곤 한다.
Q. LangGraph의 차별점을 하나만 꼽으면
사이클이다.
대부분의 프레임워크가 DAG라 되돌아감을 표현하지 못한다. 여기에 지속성이 붙어 체크포인트와 Human-in-the-Loop이 가능해진다. 상태 설계가 어떻게 이어지는지는 State와 Reducer가 정하는 것에 있다.
Q. 언제 LangGraph를 안 쓰나
단계가 고정된 단방향 파이프라인이다. LCEL이 더 짧고 읽기 쉽다.
되돌아갈 일이 없는데 상태 스키마와 조건부 엣지를 선언하면 코드만 늘어난다.
Q. LangChain을 쓰면 모델 교체가 자유로운가
인터페이스는 같지만 프롬프트는 모델마다 다시 튜닝해야 한다.
코드 교체 비용은 줄고 품질 검증 비용은 그대로 남는다. "한 줄만 바꾸면 된다"는 말은 앞의 절반만 맞다.
Q. 네 프레임워크 중 무엇을 쓰겠나
목적에 따라 갈린다. 축을 놓고 보면 선택이 단순해진다.
| 축 | LangChain(LCEL) | CrewAI | AutoGen | LangGraph |
|---|---|---|---|---|
| 핵심 은유 | 배관 자재 + 파이프 | 조립 라인(역할 분업) | 회의실(대화) | 상태 기계 / 그래프 |
| 흐름 형태 | 단방향 DAG | 순차/계층 Process | 대화 턴의 연쇄 | 사이클 허용 |
| 종료 조건 | 체인 끝 | Task 소진 → 자동 | 수동 설계 필수 | 조건부 엣지 + 재귀 한도 |
| 지속성·재개 | 별도 컴포넌트 | 약함 | 약함 | 체크포인터 내장 |
| 적합 상황 | 정형 파이프라인 | 형식 고정 리포트 | 코드 생성-실행 루프 | 조건분기·재시도·HITL |
추상화 수준과 제어권은 반비례한다.
역할만 정의하면 굴러간다는 편의를 얻으면, 특정 조건에서 되돌아가게 만드는 일이 어려워진다. 코드를 더 쓰는 만큼 실패 지점을 통제하는 것이 반대편이다.
축별 상세 비교는 제어권을 얼마나 쥘 것인가에 열두 축으로 있다.
Q. CrewAI와 AutoGen의 결정적 차이는 무엇인가
종료 조건의 소재지다.
CrewAI는 Task 리스트가 유한해 끝이 구조적으로 보장된다. AutoGen은 대화가 본질이라 끝을 사람이 설계해야 하고, 설계하지 않으면 실제로 멈추지 않는다. 두 프레임워크의 구현 차이는 CrewAI의 Agent · Task · Crew와 AutoGen 편에 나눠 있다.
Q. CrewAI에서 품질을 좌우하는 필드는 무엇인가
description이 아니라 **expected_output**이다.
산출물 계약서 역할을 한다. 목차를 통째로 박아 형식을 강제하면 결과물의 편차가 크게 준다. 역할 설명을 아무리 다듬어도 출력 형태가 정해지지 않으면 매번 다른 것이 나온다.
용어 정리
| 용어 | 뜻 |
|---|---|
| RAG | 외부 문서를 검색해 근거로 주입한 뒤 답을 생성하는 기법 |
| Naive RAG | 검색 1회 → 생성 1회로 끝나는 단방향 RAG. 검색 실패를 감지 못 함 |
| Agentic RAG | 검색 자체를 도구로 만들어 "검색이 필요한가"부터 에이전트가 판단하는 RAG |
| Pre / Post-Retrieval | 검색 이전(청킹·임베딩·색인) / 검색 이후(재순위·선별) 단계 |
| Chunking / Overlap | 문서를 검색 단위로 자르는 것 / 경계 손실을 줄이려 앞 조각 끝을 겹치는 것 |
| Embedding | 텍스트를 의미를 담은 실수 벡터로 변환. 질문과 문서는 같은 모델이어야 함 |
| Retriever | 질문을 받아 관련 문서를 돌려주는 인터페이스 |
| LCEL | ` |
| Runnable | invoke/stream/batch를 갖는 LangChain 공통 인터페이스 |
| StateGraph | 상태 스키마를 받아 노드·엣지를 조립하는 LangGraph 그래프 빌더 |
| ReAct | 추론 → 도구 호출 → 관찰을 반복하는 에이전트 패턴 |
| DAG | 되돌아가는 경로가 없는 방향 그래프. 반복 횟수를 런타임에 정할 수 없다 |
여기까지가 "무엇을 쓸 것인가"의 판단이다. 고르고 나면 다음 질문은 "그래서 상태를 어떻게 설계하나"로 옮겨 간다. 리듀서·도구 루프·체크포인터·승인 게이트는 실행 모델 Q&A에서 이어 다룬다.