오늘날 AI 데모를 만드는 것은 쉽습니다.

OpenAI를 n8n이나 Make에 연결하고, 프롬프트(Prompt)를 작성한 뒤, Run을 클릭하면 모든 것이 인상적으로 보입니다.

제가 AgenticScales를 구축하는 동안 많은 워크플로우(Workflow)가 시작된 방식이 바로 이와 같았습니다.

어려운 점은 그것들이 작동하게 만드는 것이 아니었습니다.

어려운 점은 불편한 질문들을 던지는 것이었습니다:

• API가 타임아웃(Time out)되면 어떻게 되는가?
• AI가 정답을 모를 때는 어떻게 되는가?
• 고객이 환불을 요청하면 어떻게 되는가?
• 누군가 의미 없는 메시지로 시스템에 스팸을 보내면 어떻게 되는가?

이러한 워크플로우들을 더 많이 작업할수록, 프로덕션(Production) AI는 프롬프트와는 거의 관련이 없으며, 실패를 처리하는 것과 모든 관련이 있다는 사실을 깨달았습니다.

아래의 모든 교훈은 워크플로우의 약점을 발견하고, 그것이 실제 문제가 되기 전에 재설계하는 과정에서 얻은 것입니다.

1. API가 항상 응답할 것이라고 가정하지 마세요

저의 첫 번째 실수 중 하나는 해피 패스(Happy path, 정상적인 경로)에만 집중한 것이었습니다.

테스트 중에는 워크플로우가 완벽하게 작동했기에, 저는 그것이 준비되었다고 가정했습니다.

그러다 질문을 던지기 시작했습니다: 만약 LLM API가 타임아웃되거나, 속도 제한(Rate limit)에 걸리거나, 프로세스 중간에 에러를 반환하면 어떻게 될까?

재시도(Retry) 및 폴백 로직(Fallback logic)이 없다면, 단 한 번의 실패가 전체 워크플로우를 망가뜨릴 수 있습니다.

그래서 저는 API 실패를 예외적인 상황이 아닌, 예상 가능한 상황으로 취급하기 시작했습니다.

현재 제가 하는 방식

• 실패한 요청을 자동으로 재시도합니다 (절대 멈춰 있지 않도록 타임아웃 설정 포함).
• 실패를 명확하게 로그(Log)로 남깁니다.
• 재시도 후에도 호출이 계속 실패하면, 우아하게 성능을 저하시킵니다(Degrade gracefully): 요청을 누락시키는 대신 티켓을 상담원 대기열로 라우팅(Route)합니다.

워크플로우는 절대로 작업을 조용히 잃어버려서는 안 됩니다.

저의 지원 흐름(Support flow)에서는 이것이 내장된 안전장치입니다: 분류(Classification)가 실패하면, 티켓은 시스템 속으로 사라지는 대신 needs_human으로 표시되어 사람에게 전달됩니다.

2. AI가 민감한 요청을 혼자 처리하게 해서는 안 됩니다

고객 지원 워크플로우를 설계하면서, 저는 모든 요청에 AI가 생성한 응답을 제공해서는 안 된다는 것을 빠르게 깨달았습니다.

환불 요청, 보안 문제, 또는 법적 불만 사항은 단순한 "비밀번호를 어떻게 재설정하나요?"와 같은 질문보다 훨씬 더 큰 리스크를 수반합니다.

모델이 대부분의 경우 성능을 잘 발휘하더라도, 민감한 주제에 대한 단 한 번의 잘못된 응답이 심각한 문제를 일으킬 수 있습니다.

결국 저는 모든 티켓(ticket)이 AI에 도달해서는 안 된다는 것을 깨달았습니다.

어떤 요청들은 너무 많은 리스크를 안고 있습니다.

환불.

법적 불만 사항.

보안 문제.

화가 난 고객.

워크플로우가 이러한 카테고리 중 하나를 감지하면, AI를 완전히 건너뛰고 대화를 상담원(human)에게 넘깁니다.

생성된 응답 없음.

추측 없음.

불필요한 리스크 없음.

고객은 단순히 팀의 담당자가 후속 조치를 취할 것이라는 메시지를 받게 됩니다.

때로는 AI가 할 수 있는 가장 현명한 행동은 대화에 참여하지 않는 것입니다.

3. 자동화에는 경계가 필요합니다

초기에 저는 자동화를 '전부 아니면 전무(all-or-nothing)'의 결정으로 취급했습니다.

모든 것을 자동화하거나, 아니면 모든 것을 수동으로 승인하거나.

테스트를 통해 저는 실제 정답은 그 중간 어디쯤에 있다는 것을 배웠습니다.

핵심은 자동화가 어디서 끝나고 인간의 판단(human judgment)이 어디서 시작되는지를 결정하는 것입니다.

현재 제가 하는 방식

저는 작업을 두 가지 경로로 나눕니다:

저위험 및 근거 기반 (Low-risk and grounded)

답변이 검증된 지식 소스(knowledge source)에서 직접 나오고 주제가 저위험이라면, 응답을 자동으로 보낼 수 있습니다.

민감하거나 검증 불가능한 경우 (Sensitive or unverifiable)

요청이 중요하거나, 불분명하거나, 잠재적으로 위험한 요소를 건드린다면 인간이 최종 결정을 내립니다.

질문은 인간이 모든 것을 승인해야 하는가 하는 것이 아닙니다.

질문은 어떤 작업이 자동화하기에 충분히 안전한지, 그리고 어떤 작업이 항상 인간의 통제하에 있어야 하는지입니다.

그 경계를 올바르게 설정하는 것이 자동화를 신뢰할 수 있게 만드는 핵심입니다.

4. '제로 인벤션(Zero-Invention)' 정책을 채택하십시오

제가 매우 빠르게 알아차린 한 가지는 LLM(대규모 언어 모델)이 다음과 같이 말하는 것을 싫어한다는 점입니다:

_"잘 모르겠습니다."

정보가 누락되면, 모델은 종종 그 공백을 채우려고 시도합니다.

이는 브레인스토밍(brainstorming)에는 유용합니다.

하지만 비즈니스 프로세스에서는 위험합니다.

현재 제가 하는 방식

모든 워크플로우(workflow)는 지식 소스(knowledge source)에 근거하며, 제 프롬프트에는 다음과 같은 엄격한 규칙이 포함되어 있습니다:

제공된 데이터에 명시적으로 나와 있지 않은 정책, 계정 정보, 환불 금액 또는 사실을 절대로 지어내지 마십시오. 정보를 확인할 수 없는 경우, 담당자가 후속 조치를 취할 것이라고 답변하십시오.

그 결과는 실질적입니다.

제가 직접 만든 지원 봇(support bot)에게 아직 문서화되지 않은 환불 정책에 대해 물었을 때, 봇은 답변을 지어내지 않았습니다.

그저 해당 정보가 없으며 팀원이 후속 조치를 취할 것이라고 답변했을 뿐입니다.

이것이 바로 제가 고객을 대할 때 원하는 정확한 동작입니다.

5. 오남용으로부터 AI 예산 보호하기

이 교훈은 저를 완전히 당황하게 만들었습니다.

제 워크플로우 중 하나를 테스트하던 중 이상한 점을 발견했습니다.

모든 메시지가 전체 파이프라인(pipeline)을 트리거(trigger)하고 있었습니다.

심지어 다음과 같은 메시지조차 말입니다:

"안녕"

또는 단순히:

"?"

워크플로우는 실제로 처리할 가치가 있는 내용이 없다는 것을 깨닫기 전에, 분류(classification)를 수행하고, 지식 베이스(knowledge base)를 쿼리(query)하며, 유료 AI 호출(paid AI calls)을 실행했습니다.

그때 문제점을 발견했습니다.

지루함을 느끼는 방문자가 수백 개의 의미 없는 메시지를 보내 조용히 실제 청구서를 만들어낼 수 있다는 점이었습니다.

악의적인 사용자도 정확히 똑같은 일을 할 수 있습니다.

워크플로우가 고장 났기 때문이 아닙니다.

제가 워크플로우에 실제 요청(real request)과 노이즈(noise)의 차이를 가르치지 않았기 때문입니다.

현재 제가 하는 방식

저는 유료 AI 호출을 하기 전에 저렴한 규칙 기반 필터(rule-based filter)를 실행합니다.

• 실제 요청은 전체 AI 워크플로우를 거칩니다.
• 모호한 메시지는 명확화 흐름(clarification flow)을 트리거합니다.
• 반복되는 저가치 메시지는 미리 정의된 응답으로 처리됩니다.

비싼 AI 호출은 실제로 가치를 더할 때만 발생합니다.

제가 배운 교훈 중 하나는 워크플로우 노드(node)를 단순히 논리에 의해서만 배치해서는 안 된다는 것입니다.

비용에 따라서도 배치해야 합니다.

가장 저렴한 필터가 보통 가장 먼저 와야 합니다.

노드를 논리뿐만 아니라 비용에 따라 정렬하십시오.

마치며

AgenticScales를 구축하기 전에는, AI 자동화의 어려운 부분이 모델이 좋은 답변을 생성하게 만드는 것이라고 생각했습니다.

이제 저는 그것이 쉬운 부분이라고 생각합니다.

어려운 부분은 API가 실패하거나, 사용자가 예상치 못한 방식으로 행동하거나, 비용이 증가하거나, 또는 AI가 자신이 아는 지식의 한계에 도달했을 때도 신뢰성을 유지하는 시스템을 구축하는 것입니다.

프로덕션 환경에 적합한 (Production-ready) AI는 자동화를 극대화하는 것에 관한 것이 아닙니다.

그것은 명확한 경계를 설계하는 것에 관한 것입니다:

• AI가 행동할 수 있는 시점.
• AI가 도움을 요청해야 하는 시점.
• 인간이 반드시 개입해야 하는 시점.

오늘날 제가 가장 신뢰하는 워크플로우 (workflows)는 모든 것을 자동화하는 워크플로우가 아닙니다.

언제 자동화하지 말아야 할지를 정확히 아는 워크플로우입니다.

그것이 인상적으로 보이는 데모 (demo)와 기업이 의존할 수 있는 시스템 사이의 차이입니다.

AI 워크플로우를 구축하면서 혹독한 경험을 통해 얻은 프로덕션 관련 교훈이 있으신가요? 댓글로 여러분의 이야기를 들려주세요.