1편. 설계의 대상은 Workflow다

Workflow를 어렵게 생각할 필요는 없습니다. 어떤 Trigger가 발생한 뒤 원하는 Outcome이 나오기까지 여러 작업과 판단이 연결되는 구조라고 이해하면 됩니다.

고객이 환불을 요청하는 상황을 생각해보겠습니다.

환불 요청 접수 → 주문 조회 → 환불 가능 여부 판단 → 환불 금액 계산 → 환불 승인 → 결제 취소 → 고객 안내

이 전체가 하나의 Workflow입니다.

모든 단계의 성격이 같지는 않다

여기서 중요한 점이 하나 있습니다. 위의 일곱 단계는 서로 다른 종류의 일입니다.

• 주문 조회는 시스템이 잘합니다.
• 환불 금액 계산도 명확한 Rule이 있다면 시스템이 잘합니다.
• 고객 귀책인지 회사 귀책인지 가리는 데는 사람의 판단이 필요할 수 있습니다.
• 환불 승인은 리스크 때문에 최종적으로 사람이 결정해야 할 수도 있습니다.

같은 Workflow 안에 있지만 성격이 전부 다릅니다. 그래서 “이 업무를 AI로 바꾸자”는 말은 사실 성립하지 않습니다. 이 업무 안에는 AI가 필요 없는 단계, AI가 도울 수 있는 단계, 사람이 여전히 필요한 단계가 섞여 있으니까요.

그냥 전부 AI에게 맡기면 안 되나

여기서 한 가지 반문이 나올 수 있습니다. 성능이 계속 좋아지고 있으니 그냥 다 맡기면 되지 않느냐는 질문이죠. 세 가지 이유로 그렇게 하지 않습니다.

첫째, 품질이 흔들립니다. 같은 업무를 같은 방식으로 맡겨도 결과가 매번 같다는 보장이 없습니다. 모델 버전이 올라가거나 프롬프트(Prompt)를 한 줄 고치면 또 달라집니다. 값을 대조하면 언제나 같은 답이 나오던 판단까지 AI에게 넘기면, 예측 가능하던 것이 예측 불가능해집니다. 어제 되던 게 오늘 안 되는데 아무도 모르는 상태가 됩니다.

둘째, 호출 비용이 쌓입니다. 한 건에 몇 원이라도 하루 수천 건이면 이야기가 달라집니다. 조건문 한 줄이면 끝나는 판단을 매번 모델에 물어보는 건 비싼 방법으로 싼 문제를 푸는 일입니다. 게다가 이 비용은 업무량에 비례해서 늘어납니다.

셋째, AI는 책임지지 않습니다. 잘못된 판단으로 손실이 나면 그 피해는 회사가 고스란히 떠안습니다. 고객에게 사과하는 것도, 기준을 다시 세우는 것도 결국 사람의 몫입니다. 그래서 되돌리기 어렵거나 손실이 큰 결정에는 사람이 반드시 필요합니다.

세 가지를 뒤집으면 AI를 어디에 두어야 하는지가 나옵니다. 판정이 매번 같아야 하는 곳에는 Rule을, 호출량이 많고 단순한 곳에는 시스템을, 책임을 물어야 하는 곳에는 사람을 둡니다. 그러고 남는 자리, 즉 값이 아니라 뜻을 읽어야 하고 사람이 하기엔 양이 많은 판단이 AI의 자리입니다.

그래서 질문이 이렇게 바뀝니다.

“AI로 무엇을 할 것인가”가 아니라 “이 Workflow 안에서 누가 무엇을 하는 것이 가장 적절한가.”

이 관점을 이해하면 앞으로 나올 FRAME, MAP, FIND, EXTRACT, REDESIGN, APPLY & REVIEW가 단순한 실습 순서가 아니라 하나의 논리로 연결됩니다. AI는 Workflow 안에서 역할을 맡는 여러 주체 중 하나이고, AX 설계란 그 역할 배치를 다시 정하는 일입니다.

Case Study. 상품정보 변경 정합성 문제

이 연재가 처음부터 끝까지 따라갈 Case Study를 꺼내겠습니다.

오픈마켓(Open Market)에서 상품정보를 등록하고 수정하는 과정에 정합성 체크가 없다면, 셀러(Seller)가 상품명이나 카테고리 같은 핵심 정보를 자유롭게 바꿀 수 있습니다. 그러면 과거 주문과 리뷰는 그대로인데 상품의 현재 정체성만 달라지는 문제가 생깁니다.

고객은 사과를 구매했는데 나중에 주문목록에는 오렌지가 보입니다. 사과 상품을 보고 있는데 리뷰에는 과거 오렌지 구매자의 리뷰가 남아 있습니다.

지금은 이 문제를 운영팀이 변경 건을 전수로 확인하는 방식으로 막고 있습니다. 변경 물량이 늘어나는 만큼 검수 인력도 더 필요하고, 이미 고객에게 노출된 뒤에야 확인이 이뤄집니다.

이 문제를 풀 때도 “AI로 상품정보를 검사하자”에서 시작해서는 안 됩니다. 어떤 정보는 Rule로 통제할 수 있고, 어떤 정보는 비정형 판단이 필요하며, 어떤 조치는 AI가 틀렸을 때 사업 리스크가 큽니다. 전체 Workflow를 먼저 살펴봐야 합니다.

다음 편 예고

Workflow가 설계의 대상이라는 것까지 왔습니다. 그런데 “우리 회사 고객센터 업무”처럼 덩어리째 들고 오면 아무것도 분해할 수 없습니다. 다음 편에서는 그 덩어리를 실습 가능한 한 조각으로 좁히는 FRAME을 다루겠습니다.

한 줄로 남깁니다. 설계의 단위는 AI 기능이 아니라 Trigger에서 Outcome까지의 Workflow입니다.