AI 워크플로우가 배포되어도 안전한지 어떻게 알 수 있을까요?

당신은 하나의 AI 워크플로우를 구축했습니다. 테스트에서는 작동합니다. 팀원들이 프롬프트를 검토했고, 데모도 잘 진행되었습니다.

그래서 당신은 그것을 출시합니다. 그리고 일주일 만에 무언가 고장 납니다. 리드가 잘못된 담당자에게 할당됩니다. 에이전트가 더 이상 존재하지 않는 도구를 호출합니다. 테스트에서 30초 걸리던 워크플로우가 이제 4분이 걸리거나, 아예 완료되지 않습니다.

저는 이 패턴을 5명, 50명, 500명의 팀 전반에 걸쳐 반복되는 것을 보았습니다. 워크플로우는 코드 리뷰를 통과합니다. 30분짜리 스프린트 리뷰에서 데모가 잘 진행됩니다. 그러고 나서 실제 프로덕션 트래픽을 만나면 48시간 이내에 무너집니다.

문제는 너무 일찍 출시했다는 것이 아닙니다. 문제는 '테스트에서는 작동한다'는 것이 워크플로우가 실제 데이터, 실제 예외 케이스, 그리고 당신이 예상하지 못한 행동을 하는 실제 사용자들을 만났을 때 어떤 일이 벌어질지 알려주지 않는다는 것입니다.

다음은 AI 워크플로우를 프로덕션에 배포하기 전에 실제로 확인해야 할 사항들입니다.

테스트와 프로덕션 사이의 격차

대부분의 팀은 전통적인 소프트웨어를 테스트하는 방식과 동일하게 AI 워크플로우를 테스트합니다: 행복한 경로(happy path)를 실행하고, 몇 가지 예외 케이스를 실행하며, 출력이 합리적으로 보이는지 확인하고, 출시합니다.

이러한 접근 방식은 AI 워크플로우에 특정한 실패 모드를 가지고 있습니다. 전통적인 코드는 결정론적(deterministic)입니다. 입력 A로 작동하면, 매번 입력 A로 작동합니다. 반면, AI 워크플로우는 확률적(probabilistic)입니다. 동일한 입력이라도 모델의 동작이 당신의 통제 범위를 벗어난 요소들—컨텍스트 윈도우 압박, API 지연 시간, 모델 버전 업데이트, 그리고 실행되는 순간의 프롬프트 특정 문구—에 따라 다른 출력을 생성할 수 있습니다.

행복한 경로를 테스트하는 것은 워크플로우가 작동할 수 있다는 것만을 알려줍니다. 그것이 계속해서 작동할지 여부는 알려주지 않습니다.

출시 전에 확인해야 할 사항들

워크플로우가 수용하는 모든 입력을 검토하고 다음 질문을 던지세요: 이 필드가 누락되면 워크플로우는 어떻게 작동할까요? 예상치 못한 문자가 포함되어 있으면요? 테스트 데이터보다 훨씬 길거나 짧으면요?

이것은 당연하게 들리지만, 제가 보는 가장 흔한 실패 지점입니다. 리드에 회사 도메인이 있을 때는 완벽하게 작동하는 CRM 리드 할당 워크플로우가 도메인 필드가 비어 있으면 조용히 실패합니다. 정보 보강(enrichment) 단계는 아무것도 반환하지 않고, 조건부 확인(conditional check)은 아무것도 전달하지 않으며, 할당(assignment) 단계는 실행되지 않습니다. 오류도 없고, 알림도 없습니다. 리드는 그저 거기에 3일 동안 머물다가 영업 담당자가 Slack 채널 #revenue-ops에서 "제 리드는 어디에 있나요?"라고 물어볼 때까지 기다립니다.

해결책은 가능한 모든 입력을 처리하는 것이 아닙니다. 그것은 워크플로우가 설계되지 않은 입력을 만났을 때 어떻게 작동하는지 아는 것입니다. 큰 소리로 실패하나요(fail loudly)? 조용히 건너뛰나요(skip silently)? 아니면 올바르게 보이지만 실제로는 아닌 부분적인 출력을 생성하나요?

2. 단계가 실패하면 어떻게 될까요?

대부분의 AI 워크플로우는 체인입니다: 1단계가 2단계에 데이터를 공급하고, 2단계가 3단계에 데이터를 공급합니다. 테스트할 때는 모든 단계가 성공합니다. 하지만 실제 운영 환경(production)에서는 단계가 실패합니다.

API 호출이 시간 초과됩니다(times out). 모델이 빈 응답을 반환합니다. 도구 호출이 500 오류를 반환합니다. 데이터 소스가 일시적으로 사용할 수 없게 됩니다.

워크플로우의 각 단계에 대해 다음 세 가지 질문에 답하세요:

• 이 단계가 실패하면 다음 단계는 무엇을 받나요?
• 워크플로우는 계속 진행되나요, 재시도하나요, 아니면 중지하나요?
• 누가 그것이 실패했다는 것을 알게 되나요?

만약 세 번째 질문에 대한 답이 "고객이 불평하기 전까지는 아무도 모른다"라면, 문제가 있는 것입니다. 조용한 실패(Silent failures)는 축적되기 때문에 큰 소리로 실패하는 것보다 더 나쁩니다. 1일 차에 크게 실패하는 워크플로우는 화요일까지 수정됩니다. 하지만 3주 동안 조용히 실패하는 워크플로우는 한 달 동안 정리해야 할 400개의 손상된 기록을 만듭니다.

3. 모델이 변경되면 어떻게 될까요?

모델 제공업체들은 자신들의 모델을 업데이트합니다. 때로는 이를 발표하기도 하고, 때로는 그렇지 않기도 합니다. 때로는 업데이트가 성능을 개선시키지만, 때로는 워크플로우를 깨뜨리는 방식으로 동작을 변경시키기도 합니다.

신뢰성 있게 구조화된 JSON 출력을 생성하던 프롬프트가 일반 산문(prose)을 출력하기 시작할 수 있습니다. 6개월 동안 작동했던 도구 호출 패턴(tool-calling pattern)이 모델의 함수 호출 동작(function-calling behavior)이 변경되면서 더 이상 작동하지 않을 수도 있습니다. 예전에는 200 토큰에 불과했던 응답이 모델이 좀 더 상세하게 설명하기로 결정하면서 800 토큰까지 부풀어 오를 수 있습니다. 저는 조용한 모델 업데이트(silent model update)가 출력 길이를 변경시켜 워크플로우의 API 비용을 하룻밤 사이에 4배나 급증시켰는데, 아무도 그 사실을 11일 동안 알아차리지 못했던 경험을 목격했습니다.

모델 변화를 막을 수는 없습니다. 하지만 대비할 수는 있습니다. 배포하기 전에 다음 사항들을 준비하세요:

• 각 단계에서 어떤 모델이 사용되는지, 구체적인 버전까지 문서화하세요.
• 각 단계별로 예상 출력 형식이 어떻게 되는지 기록해 두세요.
• 어떤 모델 업데이트가 발생하더라도 출력이 여전히 기대하는 바와 같은지 검증할 수 있는 테스트 케이스를 만드세요.

워크플로우가 어떤 모델 버전을 사용하는지 모른다면, 나중에 문제를 진단할 수 없습니다.

워크플로우가 오늘 작동한다고 해서 영원히 작동할 것이라고 확신할 수 있을까요?

대부분의 팀은 사용자 불만(user complaints)에 의존합니다. 이는 워크플로우가 문제가 생겼다는 사실을 누군가 알아차리기 5~10 영업일 동안 실패하고 있었다는 의미이며, 그 사이에 손실이 이미 쌓였다는 뜻입니다.

배포하기 전에, 워크플로우가 정상 상태(healthy)임을 알려주는 최소한 하나의 신호(signal)를 설정하세요:

• 출력이 여전히 예상된 형식인지 확인하는 예약 테스트 실행(scheduled test run)
• 갑작스러운 변화를 확인할 수 있는 단계 완료 시간 기록(log of step completion times)
• 성공적인 완료 횟수 대 실패 횟수의 일일 카운트
• 정기적인 일정으로 출력 샘플에 대한 인간 검토(human review)

신호가 정교할 필요는 없습니다. 존재하기만 하면 됩니다. "47개의 리드가 처리되었고, 오류는 0개이며, 평균 완료 시간은 28초입니다"라는 일일 Slack 메시지만으로 충분합니다. 지난 72시간 동안 아무도 불평하지 않았다고 해서 모든 것이 괜찮다고 가정하는 것은 부족한 것입니다.

재검증 습관 만들기 (Building a Re-Verification Habit)

위의 5가지 질문은 일회성 관문(one-time gate)이 아닙니다. 이는 반복적인 실천입니다. 워크플로우는 표류합니다(drift). 모델은 업데이트됩니다. 데이터 형태가 바뀝니다. 지난 8월에 검토했던 워크플로우와 10월에 실행되는 워크플로우는, 사람이 코드를 건드리지 않았더라도 동일하지 않습니다.

실용적인 접근 방식은 다음과 같습니다. 주기(cadence)를 정하고 (대부분의 팀에게는 격주가 적절합니다), 달력에 30분을 블록하세요. 그 시간 동안 위의 5가지 질문을 다시 한번 검토하세요. 모든 것을 재테스트할 필요는 없습니다. 지난 검토 이후로 무언가 변경되었는지 확인하기만 하면 됩니다.

지난 검토 이후 모델이 업데이트되었나요? 지난 14일 동안 누군가 프롬프트(prompt)를 수정했나요? 입력 데이터 형식이 바뀌었나요? 팀원이 퇴사하여 소유권 공백(ownership gap)이 생겼나요? 요청량이 20% 이상 변했나요?

아무것도 변경되지 않았다면, 검토는 10분밖에 걸리지 않습니다. 무언가 변경되었다면, 그것이 사고(incident)가 되기 전에 포착할 수 있습니다. 비용은 적습니다. 이 과정을 건너뛰었을 때의 비용은 고객이 문제를 제기하기 전까지 아무도 알아차리지 못하는 조용한 실패입니다.

배포 전 체크리스트 (The Pre-Ship Checklist)

AI 워크플로우를 프로덕션에 배포하기 전에, 다음 7가지 질문에 답할 수 있는지 확인하세요:

1. 각 입력 필드가 비어 있거나 형식이 잘못되었을 때 워크플로우는 어떻게 작동하나요?
2. 단계가 실패했을 때 다음 단계는 무엇을 받게 되나요?
3. 워크플로우는 크게 실패(loudly)하나요, 아니면 조용히(silently) 실패하나요?
4. 각 단계는 어떤 모델 버전을 사용하나요?
5. 각 단계의 예상 출력은 어떻게 생겼나요?
6. 각 단계의 소유자는 누구인가요? 누가 알림을 받나요(paged)? 누가 변경할 수 있나요?
7. 사용자가 보고하기 전에 실패를 어떻게 감지할 건가요?

만약 7가지 질문 모두에 답할 수 없다면, 아직 배포 준비가 되지 않은 것입니다. 그렇다고 해서 완벽하게 답변해야 한다는 의미는 아닙니다. 단지 그 답을 알고 있어야 합니다. 설령 그 답이 '모르겠다'일지라도, 그리고 '이에 대해 이렇게 하겠다'라는 계획까지 가지고 있어야 합니다.

대부분의 팀들이 잘못하는 것들

가장 흔한 실수는 이 목록의 어떤 항목도 건너뛰는 것이 아닙니다. 사전 배포 검토(pre-ship review)를 일회성 이벤트로 취급하는 대신 지속적인 습관으로 여기지 않는 것입니다.

8월에는 배포해도 안전했던 워크플로우가 10월에는 안전하지 않을 수 있습니다. 모델이 변경되었고, 데이터 볼륨은 두 배가 되었으며, 팀원은 한 명 이탈했고, 비즈니스 요구사항도 바뀌었기 때문입니다. 출시 때 단 한 번 검토되고 다시는 돌아보지 않는 워크플로우는 실패를 향해 서서히 표류하는 워크플로우이며, 매번 작은 기능 저하(quiet degradation)가 일어납니다.

AI 워크플로우를 끊임없는 문제 해결(firefighting) 없이 운영하는 팀들은 더 나은 프롬프트나 더 똑똑한 모델을 가지고 있는 것이 아닙니다. 그들은 무언가가 고장 날 때만 아니라, 정기적으로 워크플로우를 재검토하는 습관을 가지고 있습니다.

캘린더 알림을 설정하세요. 2주마다 위 7가지 질문들을 검토해 보세요. 30분밖에 걸리지 않습니다. 금요일 밤 11시에 P1 인시던트가 되기 전에 문제를 포착할 수 있습니다.

제2의 의견이 필요한 때

때로는 워크플로우에 너무 가까워서 그 허점을 볼 수 없을 때가 있습니다. 직접 만들었고, 테스트했고, 어떻게 작동해야 하는지 알고 있기 때문입니다. 그 지식이 오히려 사각지대(blind spot)가 됩니다. 워크플로우가 무엇을 해야 하는지를 '모르는' 상태로 되돌릴 수 없기 때문에, 상황이 잘못되었을 때 실제로 무엇을 하는지 볼 수 없습니다.

새로운 시각은 당신이 놓친 부분을 포착할 수 있습니다. 바로 여기서 진단 검토(diagnostic review)가 필요합니다. 워크플로우를 설명하고, 구축한 것을 공유하며, 잠재적인 실패 경계(failure boundaries)가 어디에 있을지 독립적인 평가를 받으세요. 일반적인 체크리스트가 아닙니다. 당신의 특정 워크플로우, 당신의 특정 실패 모드(failure modes), 그리고 당신의 특정 복구 계획(repair plan)을 구체적으로 살펴봅니다.

AI 워크플로우를 출시할 예정이고 라이브로 가기 전에 사전 진단이 필요한 경우, TryPromptFlow에서 컨설턴트 스타일의 검토를 진행하여 실패 경계를 매핑하고 복구 계획을 제공합니다. 무료 진단을 한 번 받을 수 있으며 신용카드 등록은 필요하지 않습니다.