2024~2026년 프로덕션 AI 실패의 대부분은 모델 품질 때문이 아니었다.
Gartner에 따르면 2026년 말까지 기업 애플리케이션의 40%가 AI 에이전트를 내장할 것으로 예측된다.
2025년의 5% 미만에서 8배 점프다.
시장 규모도 78억 달러에서 2030년까지 520억 달러를 넘긴다.
멀티 에이전트 시스템에 대한 기업 문의는 2024년 Q1 대비 2025년 Q2에 1,445% 폭증했다.
숫자만 보면 “에이전트가 대세”라는 얘기인데,
정작 프로덕션에 올린 팀들은 데모와 현실 사이의 괴리에 시달리고 있다.
데모는 잘 된다.
프로덕션에서 깨진다.
모델을 바꿔도 나아지지 않는다.
문제는 모델이 아니라 모델을 감싸는 시스템이다.
“에이전트”라는 단어가 실제로 의미하는 것
에이전트를 한 줄로 정의하면 이렇다.
루프 안에 감싸진 LLM으로,
상태를 관찰하고,
도구를 호출하고,
결과를 기록하고,
완료 시점을 스스로 결정할 수 있는 시스템.
일반적인 LLM 호출과 비교하면 차이가 명확하다.
일반 호출은 사용자가 프롬프트를 보내고,
LLM이 학습 데이터 기반으로 답하고,
끝이다.
한 번 쏘고 끝나는 구조다.
에이전트는 다르다.
사용자가 목표를 전달하면,
LLM이 “다음에 뭘 해야 할지” 판단한다.
도구를 호출하고,
결과를 확인하고,
다시 판단한다.
목표를 달성했다고 스스로 판단하면 그때 종료된다.
이 루프가 핵심이다.
비유가 하나 있다.
LLM은 CPU고,
에이전트는 프로세스이며,
에이전틱 프레임워크는 운영체제다.
LLM 자체는 연산 엔진일 뿐이고,
그걸 감싸는 시스템 아키텍처가 에이전트를 만든다.
실제 코드로 보면 이렇다.
# 오케스트레이터 = 이 코드 자체 (LLM이 아님)
def run_agent(user_query: str):
messages = [system_prompt, tools_definition, user_query]
while True: # ← 이 루프가 에이전트의 전부
response = llm.call(messages) # LLM은 판단만 한다
if response.has_action():
tool_name, params = parse_action(response)
result = execute_tool(tool_name, params) # 실행은 코드가
messages.append(response)
messages.append(result) # 다시 루프 시작
elif response.has_answer():
return response.answer # 종료 판단도 LLM이
여기서 중요한 건 오케스트레이터가 LLM이 아니라 코드(while 루프)라는 점이다.
LLM은 “다음에 뭘 할지” 판단만 하고,
실제 도구 실행과 흐름 제어는 코드가 한다.
ReAct: 에이전트의 기본 심장 박동
에이전트에서 가장 기본이 되는 패턴이 ReAct(Reason + Act)다.
LLM이 “생각(Thought) → 행동(Action) → 관찰(Observation)”을 반복하는 구조다.
“강남구 아파트 시세 알려줘”라는 질문이 들어오면,
내부에서 이런 일이 벌어진다.
── 루프 1회차 ──
LLM: Thought: 강남구 아파트 실거래가를 조회해야 한다.
LLM: Action: search_real_estate_api("강남구", "34평")
오케스트레이터: Action 감지 → API 실행 → 결과 수신
도구 결과: {"은마": "22.3억", "대치 래미안": "28.1억"}
── 루프 2회차 ──
LLM: Thought: 데이터를 받았다. 정리해서 답변하자.
LLM: Answer: "강남구 34평 기준 은마 22.3억, 대치 래미안 28.1억..."
오케스트레이터: Answer 감지 → 루프 종료 → 사용자에게 반환
LLM이 직접 API를 호출하는 게 아니다.
LLM은 “search_real_estate_api를 호출하겠다”는 의사결정만 하고,
실제 호출은 오케스트레이터 코드가 한다.
7가지 디자인 패턴: 전부 필수가 아니다
에이전트에는 ReAct 외에도 여러 패턴이 있다.
- ReAct
- Reflection
- Planning
- Tool Use
- Multi-Agent Collaboration
- Sequential Workflows
- Human-in-the-Loop
중요한 건, 전부 필수가 아니라는 것이다.
에이전트의 필수 요소는
LLM, 루프, 도구, 종료 조건 네 가지뿐이다.
나머지 패턴은 작업 복잡도에 따라 조합하는 것이다.
Reflection: 자기 출력을 다시 평가하는 구조
Reflection은 LLM이 자기가 생성한 출력을
별도의 호출로 비판/평가하는 패턴이다.
response_1 = llm.call("강남구 취득세 계산. 매매가 15억, 1주택자")
review = llm.call(f"아래 답변의 사실 오류를 검토해라:\n{response_1}")
final = llm.call(f"원본: {response_1}\n피드백: {review}\n수정본 작성")
Reflection의 목적은 지능 향상이 아니라 리스크 감소다.
Planning: “먼저 계획 세워”라는 별도 호출
Planning도 LLM 호출이다.
차이는 “실행하지 마, 계획만 세워”라는 사전 단계라는 점이다.
plan = llm.call("""
요청: '강남구 아파트 매매 시 총 비용 분석'
단계별 계획을 JSON으로 작성해라. 실행하지 마.
""")
for step in plan:
execute_step(step)
복잡한 작업에서는 계획 객체 없이 장기 실행 에이전트를 만들지 않는 게 원칙이다.
Tool Use: “정확해야 하는 건 LLM이 계산하지 마”
이 원칙이 에이전트 아키텍처의 가장 중요한 설계 결정이다.
# LLM이 직접 계산 ← 절대 하면 안 됨
"매매가 15억의 취득세는..." # 환각 확률 높음
# LLM이 도구 호출을 판단 ← 올바른 패턴
LLM: "calculate_tax 도구를 호출하겠다"
오케스트레이터: calculate_tax(price=1_500_000_000, houses=1)
결과: 27_000_000 # 정확한 계산
LLM은 “어떤 도구를 어떤 파라미터로 호출할지”를 결정하고,
계산 자체는 결정론적 코드가 수행해야 한다.
Multi-Agent: 왜 같은 LLM을 여러 개로 나누는가
같은 LLM인데 Research Agent, Calculator Agent로 나누는 이유가 있다.
하나의 에이전트에 도구 30개를 전부 주면,
프롬프트가 길어지고,
엉뚱한 도구를 고르는 확률이 올라간다.
Orchestrator
├── Research Agent (search_api만)
├── Calculator Agent (tax_calc, fee_calc만)
├── Writer Agent (텍스트 생성 전문)
└── QA Agent (검증 전문)
각 에이전트의 컨텍스트가 짧고 명확해서 정확도가 올라간다.
프로덕션에서 깨지는 진짜 이유
프로토타입과 프로덕트의 차이는 더 나은 프롬프트가 아니라 아키텍처다.
프로덕션 에이전트 3대 원칙:
- 오케스트레이션은 인프라다
- 상태는 외부에 있어야 한다
- 제로 트러스트 실행
초기 시스템은 추론, 상태 저장, 도구 호출, 실행을 한 루프에 다 넣는다.
해커톤에서는 돌아가지만,
스케일/장애복구/컴플라이언스가 붙으면 무너진다.
“에이전트 워싱”에 속지 않기
진짜 에이전트인지 판별하는 기준은 명확하다.
- LLM이 루프 안에서 판단하는가?
- 도구를 사용하는가?
- 스스로 종료 시점을 결정하는가?
- 실패 시 다른 전략을 시도하는가?
하나라도 빠지면 에이전트가 아니라 자동화 스크립트다.
프롬프트 엔지니어링의 시대는 끝나가고 있다.
2026년의 승부처는 LLM을 감싸는 시스템 아키텍처다.
에이전트의 핵심은 더 똑똑한 모델이 아니라 더 나은 루프다.
Top comments (0)