AI 워크플로우를 구축하는 것은 쉽다. 하지만 이를 신뢰할 수 있게 만드는 것은 시스템 엔지니어링이다

AI 워크플로우의 첫 번째 버전을 구축하는 것은 보통 쉽습니다.

LLM (Large Language Model)을 몇 가지 도구에 연결합니다.
몇 가지 지침을 추가합니다.
모델이 다음에 무엇을 할지 결정하게 합니다.
데모를 실행합니다.
작동합니다.

문제는 그 워크플로우가 실제 프로세스의 일부가 되는 나중에 시작됩니다.

갑자기 중요한 질문은 더 이상 프롬프트 (Prompt)에 관한 것이 아니게 됩니다.

그것은 신뢰성 (Reliability)에 관한 것입니다.

도구가 실패하면 어떻게 되나요?
모델이 잘못된 것을 재시도하면 어떻게 되나요?
워크플로우의 상태 (State)가 변경되었는데 에이전트 (Agent)가 여전히 실패를 주장하면 어떻게 되나요?
에이전트는 성공을 주장하지만 실제로는 어떤 도구도 실행되지 않았다면 어떻게 되나요?
한 에이전트가 다른 에이전트에게 잘못된 컨텍스트 (Context)를 전달하면 어떻게 되나요?

이 지점에서 AI 워크플로우는 프롬프트 엔지니어링 (Prompt Engineering)을 벗어납니다.

그것은 **시스템 엔지니어링 (Systems Engineering)**이 됩니다.

데모는 시스템이 아니다

많은 AI 워크플로우 데모는 해피 패스 (Happy Path, 정상 경로)에 최적화되어 있습니다.

사용자가 무언가를 요청합니다.
에이전트가 생각합니다.
에이전트가 도구를 호출합니다.
도구가 결과를 반환합니다.
에이전트가 결과를 요약합니다.
모두가 박수를 칩니다.

하지만 프로덕션 (Production) 워크플로우는 해피 패스에서 작동하지 않습니다.

그것들은 다음과 같은 혼란스러운 현실 속에서 작동합니다:

부분적 실패 (Partial failures)
잘못된 입력 (Bad inputs)
타임아웃 오류 (Timeout errors)
유효하지 않은 도구 응답 (Invalid tool responses)
중복 재시도 (Duplicate retries)
누락된 컨텍스트 (Missing context)
권한 거부 (Permission denials)
상태 불일치 (State inconsistencies)
비용 제한 (Cost limits)
인간의 승인 (Human approvals)
복구 경로 (Recovery paths)

첫 번째 버전은 아이디어가 가능하다는 것을 증명합니다.

프로덕션 버전은 시스템이 신뢰할 수 있다는 것을 증명해야 합니다.

이것들은 매우 다른 목표입니다.

프롬프트는 추론을 가이드할 수 있지만, 신뢰성을 관리할 수는 없다

프롬프트는 중요합니다.

프롬프트는 모델이 다음을 이해하도록 돕습니다:

자신이 어떤 역할을 수행하고 있는지
어떤 목표를 추구해야 하는지
어떻게 추론해야 하는지
어떤 어조를 사용해야 하는지
어떤 제약 조건 (Constraints)을 고려해야 하는지

하지만 프롬프트가 전체 워크플로우의 신뢰성을 책임져서는 안 됩니다.

프롬프트가 안전하지 않은 동작을 방지하는 유일한 수단이 되어서는 안 됩니다.

프롬프트가 어떤 단계가 이미 완료되었는지 기억하는 유일한 수단이 되어서는 안 됩니다.

프롬프트가 재시도 (Retry)가 안전한지 결정하는 유일한 수단이 되어서는 안 됩니다.

프롬프트가 도구 (Tool)가 실제로 실행되었음을 증명하는 유일한 수단이 되어서는 안 됩니다.

AI 워크플로우가 실제 시스템에 영향을 미치기 시작하면, 런타임 (Runtime)은 일관성 (Consistency)이 필요한 부분에 대해 책임을 져야 합니다.

"모델은 추론할 수 있습니다. 시스템은 통제해야 합니다."

핵심 분리: 추론, 실행, 상태, 증거

신뢰할 수 있는 AI 워크플로우는 네 가지 관심사 (Concerns) 사이의 명확한 분리가 필요합니다:

추론 (Reasoning): 모델이 추론을 담당합니다.
실행 (Execution): 런타임이 실행을 담당합니다.
상태 (State): 워크플로우 엔진이 상태를 관리합니다.
증거 (Evidence): 감사 계층 (Audit layer)이 증거를 기록합니다.

이러한 책임들이 서로 뒤섞이면 디버깅 (Debugging)이 매우 고통스러워집니다.

예를 들어, 다음과 같은 방식은 취약합니다:

const result = await agent.run(`
  고객 불만 사항을 읽고,
  에스컬레이션 (Escalation)이 필요한지 결정하세요,
...

왜 그럴까요?

너무 많은 것이 하나의 확률적 단계 (Probabilistic step) 안에 숨겨져 있기 때문입니다.

에이전트 (Agent)가 실제로 이메일을 보냈나요?
해당 동작이 허용되었나요?
고객 데이터가 유효했나요?
에스컬레이션 규칙이 트리거되었나요?
이메일 도구 (Email tool)가 실패했나요?
최종 응답이 증거에 기반했나요, 아니면 추측에 기반했나요?

더 신뢰할 수 있는 아키텍처 (Architecture)는 작업을 분리합니다:

const decision = await agent.reason({
  task: "이 불만 사항을 에스컬레이션해야 합니까?",
  context
...

이 방식은 마법 같은 요소가 적습니다.

또한 훨씬 더 신뢰하기 쉽습니다.

재시도 문제 (The Retry Problem)

재시도 (Retries)는 AI 워크플로우에서 가장 과소평가되는 문제 중 하나입니다.

전통적인 소프트웨어에서 실패한 API 호출을 재시도하는 것은 대개 간단합니다.

요청이 타임아웃 (Timeout)되면, 다시 시도하세요.

하지만 AI 워크플로우는 다른 종류의 실패를 야기합니다.

도구 호출 (Tool call)이 실패하는 것은 모델의 추론 (Reasoning) 단계가 실패하는 것과 같지 않습니다.
네트워크 타임아웃 (Network timeout)은 잘못된 계획 (Bad plan)과 같지 않습니다.
잘못된 형식의 JSON 응답 (Malformed JSON response)은 비즈니스 컨텍스트 (Business context)가 누락된 것과 같지 않습니다.
저품질의 답변 (Low-quality answer)은 사용 불가능한 의존성 (Unavailable dependency)과 같지 않습니다.

서로 다른 실패에는 서로 다른 재시도 전략 (Retry strategies)이 필요합니다.

예를 들어:

switch (failure.type) {
  case "tool_timeout":
    return retrySameToolCall();
...

모든 실패를 "그냥 에이전트 (Agent)를 다시 실행하라"는 식으로 처리한다면, 시스템은 비용이 많이 들고, 느려지며, 신뢰할 수 없게 될 수 있습니다.

때로는 올바른 재시도가 '재시도를 하지 않는 것'일 수도 있습니다.

때로는 다음과 같은 대응이 올바른 응답일 수 있습니다:

범위 축소 (Reduce scope)
컨텍스트 초기화 (Reset context)
명확한 설명 요청 (Ask for clarification)
사람에게 에스컬레이션 (Escalate to a human)
워크플로우 중단 (Stop the workflow)
실패 기록 (Record the failure)

비용을 고려한 재시도 (Cost-aware retries)는 단순히 결제 금액에 관한 문제가 아닙니다.

그것은 신뢰성 (Reliability)에 관한 문제입니다.

상태는 명시적이어야 한다 (State Must Be Explicit)

현재 상태를 설명할 수 없는 워크플로우는 신뢰성 있게 복구될 수 없습니다.

에이전트 (Agent)가 프로세스 중간에 있다면, 시스템은 다음 사항을 알고 있어야 합니다:

어떤 단계가 실행 중인지
어떤 단계가 완료되었는지
어떤 도구 (Tools)가 실행되었는지
어떤 출력값 (Outputs)이 생성되었는지
어떤 승인 (Approvals)이 대기 중인지
어떤 오류 (Errors)가 발생했는지
다음에 무엇이 안전하게 일어날 수 있는지

명시적인 상태 (Explicit state)가 없다면, 복구는 추측의 영역이 됩니다.

이는 워크플로우가 외부 시스템을 변경 (Mutate)할 때 특히 위험합니다.

다음과 같은 워크플로우를 상상해 보십시오:

고객 불만 사항을 읽습니다.
내부 티켓 (Ticket)을 생성합니다.
에스컬레이션 이메일을 보냅니다.
CRM을 업데이트합니다.
불만 사항을 처리됨으로 표시합니다.

만약 워크플로우가 4단계에서 실패한다면, 어떤 일이 일어나야 할까요?

1단계부터 다시 시작해야 할까요?
이메일을 다시 보내야 할까요?
중복된 티켓을 생성해야 할까요?
불만 사항을 처리됨으로 표시해야 할까요?

정답은 상태 (State)에 달려 있습니다.

신뢰할 수 있는 워크플로우에는 체크포인트 (Checkpoints)가 필요합니다.

workflow.checkpoint("ticket_created", {
  ticketId,
  complaintId,
...

체크포인트는 복구를 가능하게 만듭니다.

또한 디버깅 (Debugging)을 가능하게 만듭니다.

증거가 주장보다 강력하다 (Evidence Beats Claims)

AI 워크플로우에서 가장 위험한 실패 모드 중 하나는 허위 완료 (False completion)입니다.

에이전트(Agent)는 다음과 같이 말합니다:

"완료했습니다, 이메일을 보냈습니다."

하지만 이메일은 발송되지 않았습니다.

또는 이메일 도구(Tool)가 실패했을 수도 있습니다.

또는 권한이 거부되었을 수도 있습니다.

또는 에이전트가 도구를 호출조차 하지 않았을 수도 있습니다.

모델의 최종 답변은 증거가 아닙니다.

그것은 주장 (Claim)일 뿐입니다.

신뢰할 수 있는 워크플로우는 실제로 무슨 일이 일어났는지 증명할 수 있어야 합니다.

증거 기록 (Evidence record)에는 다음과 같은 내용이 포함될 수 있습니다:

{
  "actor": "support-agent-01",
  "action": "send_email",
...

이제 시스템은 다음 질문에 답할 수 있습니다:

누가 행동했는가
무엇이 요청되었는가
허용되었는가
무엇이 실행되었는가
어떤 결과가 돌아왔는가
언제 발생했는가
무엇이 이를 증명하는가

이것이 에이전트를 신뢰하는 것과 시스템을 신뢰하는 것의 차이입니다.

멀티 에이전트 워크플로우는 신뢰성을 더 어렵게 만든다

멀티 에이전트 시스템 (Multi-Agent Systems, MAS)은 모든 신뢰성 문제를 증폭시킵니다.

단일 에이전트 (Single-Agent) 워크플로우에서는 하나의 모델이 문맥 (Context)을 놓치거나 잘못된 가정을 할 수 있습니다.

멀티 에이전트 워크플로우에서는 한 에이전트의 근거 없는 주장이 다른 에이전트의 입력값 (Input)이 될 수 있습니다.

예를 들어:

리서치 에이전트 (Research Agent)가 올바른 데이터를 수집했다고 말합니다.
분석 에이전트 (Analyst Agent)가 그 데이터를 사용하여 보고서를 생성합니다.
리뷰어 에이전트 (Reviewer Agent)가 보고서를 승인합니다.
커뮤니케이션 에이전트 (Communication Agent)가 고객에게 보고서를 보냅니다.

만약 첫 번째 주장이 틀렸다면, 전체 워크플로우는 신뢰할 수 없게 됩니다.

최종 출력물은 일관성 있어 보일 수 있습니다.

하지만 기반이 무너진 상태입니다.

그렇기 때문에 멀티 에이전트 워크플로우에는 강력한 경계 (Boundaries)가 필요합니다:

명시적인 핸드오프 (Explicit handoffs)
범위가 지정된 문맥 (Scoped context)
증거 기록 (Evidence records)
검증 게이트 (Validation gates)
책임 추적 (Responsibility tracking)
상태 체크포인트 (State checkpoints)

에이전트들은 검증된 사실인 것처럼 모호한 자연어 요약 (Natural-language summaries)을 서로에게 전달해서는 안 됩니다.

좋은 핸드오프에는 다음과 같은 내용이 포함되어야 합니다:

{
  "from": "research-agent",
  "to": "analyst-agent",
...

이는 다음과 같은 방식보다 훨씬 더 신뢰할 수 있습니다:

"데이터를 수집했습니다. 계속 진행하세요."

관측 가능성 (Observability)은 선택이 아니다

AI 워크플로우가 운영 단계에 들어서면, 관측 가능성 (Observability)은 필수적인 토대가 됩니다.

유용한 트레이스 (Trace)는 다음 사항들을 보여주어야 합니다:

모델이 의도한 것
모델이 받은 컨텍스트 (Context)
모델이 요청한 작업
권한이 부여되었는지 여부
어떤 도구 (Tool)가 실행되었는지
어떤 상태 (State)가 변경되었는지
어떤 증거 (Evidence)가 기록되었는지
에이전트 (Agent)가 사후에 주장한 내용

이것이 없다면, 팀은 결국 대화 기록 (Transcript)과 추측에 의존하여 디버깅을 하게 됩니다.

이는 확장 가능하지 (Scale) 않습니다.

전통적인 로그 (Log)는 무언가 발생했다는 사실을 알려줍니다.

AI 워크플로우의 관측 가능성 (Observability)은 왜 무언가가 발생했는지, 모델이 무엇을 믿었는지, 런타임 (Runtime)이 무엇을 허용했는지, 그리고 실제로 무엇이 실행되었는지를 설명할 수 있어야 합니다.

즉, 관측 가능성에는 다음 두 가지가 모두 포함되어야 함을 의미합니다:

추론 트레이스 (Reasoning traces)
런타임 증거 (Runtime evidence)

하나만 있고 다른 하나가 없다면 불완전합니다.

아키텍처 패턴 (The Architecture Pattern)

프로덕션 환경의 AI 워크플로우는 하나의 거대한 프롬프트 체인 (Prompt chain)이어서는 안 됩니다.

다음과 같은 모습이어야 합니다:

사용자 요청 (User Request)
     ↓
의도 해결 (Intent Resolution)
...

모델은 여전히 중요합니다.

하지만 더 이상 모든 것을 책임지지는 않습니다.

모델은 경계 (Boundaries), 실행 (Execution), 그리고 복구 (Recovery)를 관리하는 시스템 내부에서 추론합니다.

이것이 바로 변화의 핵심입니다.

AI 워크플로우는 운영 시스템이다

AI 워크플로우가 비즈니스 프로세스의 일부가 될 때, 이는 다른 운영 시스템 (Operational system)과 동일한 엔지니어링 규율 (Engineering discipline)이 필요합니다.

다음과 같은 요소들이 필요합니다:

명확한 입력 (Inputs)
명시적인 상태 (Explicit state)
제한된 실행 (Bounded execution)
권한 확인 (Permission checks)
재시도 정책 (Retry policies)
실패 처리 (Failure handling)
관측 가능성 (Observability)
감사 추적 (Audit trails)
복구 경로 (Recovery paths)
검증 게이트 (Verification gates)

이것은 관료주의가 아닙니다.

이것이 워크플로우를 신뢰할 수 있게 만드는 요소입니다.

AI 에이전트 (AI Agents)에게 더 많은 책임을 부여할수록, 이를 둘러싼 시스템은 더욱 중요해집니다.

결론

AI 워크플로우를 구축하는 것은 쉽습니다.

이를 신뢰할 수 있게 만드는 것이 어려운 부분입니다.

AI 에이전트의 미래는 더 나은 프롬프트나 더 큰 모델만으로 승리하지 못할 것입니다.

더 나은 런타임 아키텍처 (Runtime architecture)를 통해 승리할 것입니다.

프롬프트는 추론을 안내합니다.

하지만 신뢰할 수 있는 AI 워크플로우에는 다음이 필요합니다:

체크포인트 (Checkpoints)
재시도 (Retries)
권한 (Permissions)
실행 경계 (Execution Boundaries)
관측 가능성 (Observability)
감사 추적 (Audit Trails)
증거 (Evidence)
복구 (Recovery)

그렇기 때문에 프로덕션 (Production) 환경의 AI 워크플로우는 단순한 프롬프트 엔지니어링 (Prompt Engineering)이 아닙니다.

그것은 시스템 엔지니어링 (Systems Engineering)입니다.