행복 회로(Happy path)만 테스트하지 말고, 예외 상황(Edge cases)도 테스트하세요.

직접 작성한 예외 상황은 이미 생각했던 것만 잡아낼 뿐임. 그래서 실제 대화가 어떻게 흘러갔는지(주문이 진짜 들어갔는지, 가격이 맞았는지) 확인하는 것도 병행해야 함. 에이전트는 에러가 아니라 틀린 답을 내놓으며 조용히 실패하니까.

계획대로 흘러가지 않을 때 무슨 일이 벌어지는지 테스트해 봐. 누락된 데이터, 중복 요청, API 타임아웃, 불분명한 지시사항들을 살펴봤음.

워크플로우가 성공적으로 돌아갔는지 확인하는 것보다 최종 결과를 확인하는 게 더 중요하다고 생각함. 때로는 겉보기엔 다 괜찮아 보여도 실제 작업은 제대로 완료되지 않은 경우가 있거든.

먼저 코드/워크플로우를 따라가 봐. 모든 If에는 Else가 있어야 함. AI가 모든 'else' 케이스를 커버할 수 있도록 테스트 케이스를 만들게 시켜. '예외(edge)' 상황은 정상적이지 않은 경로에서 발생하니까.

중복과 누락된 필드에 대한 좋은 목록이네. 내가 하나 더 추가하자면, 출시 전에 예외 상황을 누가 책임질지 결정하라는 거야. 모든 자동화는 결국 '맞지 않는' 케이스들을 쌓아두게 됨. 매일 그 더미를 확인할 사람을 지정하지 않으면, 조용히 썩어가고 사람들은 시스템 전체를 불신하게 될 거야.

출시 전에 실행해 볼 만한 두 가지 체크리스트:

• 내일 아침에 아무것도 잃지 않고 수동 방식으로 되돌릴 수 있는가? 예전 프로세스가 모두의 기억 속에 생생할 때 그 폴백(fallback) 방식을 문서화해 둬.
• 1~2주 동안 수동 프로세스와 병렬로 실행해서 결과를 비교해 봐. 겉보기엔 멀쩡한 오답이 가장 비싼 대가를 치르게 하니까, 병렬 실행이 그걸 잡아내는 가장 저렴한 방법임.

그다음엔 '잘 돌아갔다'는 말 대신, 시간 절약이나 주당 에러 발생률처럼 비즈니스에 중요한 숫자 하나를 추적해.

내가 가장 먼저 테스트할 예외 상황은 신뢰를 깨뜨리는 케이스임. 소규모 비즈니스 AI 워크플로우라면, '어떤 실수가 사장님으로 하여금 내일부터 이 툴을 안 쓰게 만들까?'를 물어볼 거야. 잘못된 고객 응대, 중복 송장, 예약 누락, 잘못된 인수인계, 조용한 실패 같은 것들. 그게 실제로 구축할 가치가 있는 기능이 무엇인지 알려줄 거야.