블로그 목록으로
엔지니어링

AI 에이전트 파이프라인을 8단계로 쪼개다: 의도 이해부터 자가 교정까지

AICLUDE Engineering

"LLM 호출 한 번"으로 만든 에이전트의 한계

프로토타입 단계에서는 한 번의 LLM 호출로도 꽤 그럴듯한 에이전트가 만들어집니다. 시스템 프롬프트에 도구 목록을 주고, 사용자의 질문을 그대로 전달하면 LLM이 적당한 답을 돌려줍니다. 문제는 실사용입니다.

  • 사용자가 의도를 불완전하게 말했을 때 — 도구를 잘못 부릅니다.
  • 프롬프트 인젝션이 섞여 들어왔을 때 — 시스템 규칙을 우회합니다.
  • 도구 실행이 실패했을 때 — 대안을 모색하지 않고 실패한 결과를 그대로 사용자에게 내보냅니다.
  • 답변이 사실과 다를 때 — 스스로 알아차리지 못합니다.

AICLUDE 플랫폼의 코어 파이프라인은 이 문제들을 실행을 8단계로 명시적으로 분해해서 해결합니다. 각 단계는 특정한 실패 모드를 담당하고, 독립적으로 교체·모니터링·재계획이 가능합니다.

8단계 파이프라인

1단계 — Input Processing

언어 감지, 바이너리 새니타이징, 입력 길이 제한. 다음 단계가 신뢰할 수 있는 형태로 입력을 정돈합니다. 여기서 길이 제한에 걸리면 LLM 호출 자체가 발생하지 않습니다.

2단계 — Understanding

사용자 메시지를 분석해 ExecutionPlan을 만듭니다. 단순한 "다음에 부를 도구" 수준이 아니라, 실행 전략(single / serial / parallel / dag)과 태스크 배열, 그리고 결과 병합 지시까지 한 번에 구조화합니다.

strategy: dag
tasks:
  - id: fetch_schedule
    tool: calendar_list
  - id: fetch_emails
    tool: gmail_search
  - id: summarize
    dependsOn: [fetch_schedule, fetch_emails]
mergeInstruction: "일정과 메일을 근거로 오늘의 우선순위 3개를 추리세요."

3단계 — Preflight Check

LLM을 거치지 않는 규칙 기반 사전 검사입니다. 파괴적 도구 호출, 모호한 의도, RAG 컨텍스트 누락 등을 미리 차단하거나 사용자에게 확인을 요청합니다. LLM을 한 번 더 호출하지 않고도 잘못된 실행을 멈출 수 있다는 것이 핵심입니다.

4단계 — Execution

계획에 따라 태스크를 실행합니다. DAG 전략이면 Kahn 위상 정렬로 웨이브 단위 병렬 실행을 돌리고, 의존 태스크가 실패하면 후속 태스크를 캐스케이딩 스킵합니다. 각 태스크는 내부적으로 ReAct 루프(LLM → 도구 호출 → 관찰 → 다시 LLM, 최대 10회)를 돌리며, 필요하면 실시간으로 Adaptive Replan(실패 원인과 성공 결과를 LLM에 넘겨 새 전략을 생성)으로 재계획합니다.

5단계 — Fast Gate

응답을 스트리밍하기 전에 도는 Regex 기반 실시간 필터입니다. 유해 콘텐츠, 민감 정보 노출, XSS 패턴을 밀리초 단위로 걸러냅니다. LLM 검증보다 빠르고 결정적이라, 1차 안전망으로 가장 적합합니다.

6단계 — Quick Verification (Reflection Loop)

생성된 응답을 경량 LLM이 재검토합니다. is_valid: false와 함께 correction_prompt가 돌아오면, 해당 프롬프트를 시스템 메시지에 주입하고 temperature를 낮춰 즉시 재생성합니다. 이것을 "한 번에 완벽한 답"보다 싸게 만들 수 있는 이유는, 경량 검증이 실패하는 케이스만 재생성 비용을 치르기 때문입니다.

7단계 — Postflight + Surgical Fix

응답 구조에 대한 후검증입니다. 아티팩트 URL이 살아있는지, 빈 출력이 아닌지 같은 결정적 점검을 수행하고, 자동 수정 가능한 실패는 Surgical Fix로 해당 부분만 LLM에 다시 맡겨 교정합니다. 응답 전체를 재생성하지 않고 문제 지점만 고치기 때문에 지연이 최소화됩니다.

8단계 — Deep Verify + Cross-turn Correction

사용자에게 응답이 이미 나간 뒤 fire-and-forget으로 도는 심층 검증입니다. 페르소나 일치도, 사실 정확도, 도구 결과 반영 여부, 안전성을 다차원으로 점수화하고 결과를 DB에 남깁니다. 여기서 나온 correction_prompt는 다음 턴의 시스템 프롬프트에 자동 주입되어, 턴을 넘어가며 모델이 스스로를 교정합니다.

왜 "한 번에 완벽한 답"보다 이 쪽이 싼가

많은 분이 "검증 LLM을 여러 번 돌리면 오히려 비용이 올라가는 것 아니냐"고 묻습니다. 실제로는 반대입니다.

  • 실패 케이스만 비용을 치른다 — 경량 Quick Verify는 대부분의 응답을 한 번에 통과시킵니다. 재생성 비용은 실패 trace가 생긴 소수 케이스에만 발생합니다.
  • Surgical Fix가 전체 재생성을 대체한다 — 빈 응답이나 깨진 아티팩트만 콕 집어 고치니, 토큰 비용이 일반 재생성의 10~20% 수준입니다.
  • Deep Verify는 비동기 — 사용자 지연 시간에 영향을 주지 않고 품질 데이터를 쌓습니다.
  • Cross-turn Correction은 무료 업그레이드 — 같은 사용자와의 다음 턴에서, 이전 턴 검증 결과를 시스템 프롬프트에 넣기만 하면 되므로 추가 호출이 필요 없습니다.

결과적으로 "한 번에 완벽하게"를 목표로 프롬프트에 규칙을 잔뜩 쌓는 방식보다, 실패를 빨리 발견하고 싸게 고치는 쪽이 평균 응답 품질과 평균 비용 모두에서 우월합니다.

각 단계를 독립적으로 교체·관찰할 수 있다는 것

8단계로 쪼갠 가장 큰 실용적 가치는, 각 단계를 독립적으로 갈아끼울 수 있다는 점입니다. Understanding 단계는 강한 추론 모델로, Fast Gate는 규칙 엔진으로, Deep Verify는 저비용 모델로 — 단계별로 최적의 조합을 선택할 수 있습니다. 어느 단계에서 실패가 많은지 DB 메트릭으로 보이기 때문에, 개선 포인트도 명확해집니다.

AICLUDE가 이 파이프라인 위에서 에이전트를 운영하는 이유는 단순합니다. 에이전트가 "되는 것 같다"와 "실제로 쓸 만하다" 사이의 거리는, 이 단계 분해 없이는 좁혀지지 않기 때문입니다.

블로그 목록으로