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

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가 이 파이프라인 위에서 에이전트를 운영하는 이유는 단순합니다. 에이전트가 "되는 것 같다"와 "실제로 쓸 만하다" 사이의 거리는, 이렇게 단계를 쪼개지 않고는 좁혀지지 않거든요.

블로그 목록으로