2편. FRAME: 업무를 하나로 좁힌다

누군가 이렇게 말한다고 해보겠습니다.

“계약 검토 업무를 AI로 바꾸고 싶습니다.”

이 과제는 범위가 너무 큽니다. 이 상태로는 AI로 무엇을 할 수 있을지 구체적으로 떠올리기 어렵습니다. ’계약 검토’라는 표현 안에 서로 다른 업무가 너무 많이 들어 있기 때문입니다. 계약서 접수, 조항 확인, 위험조항 판단, 수정안 작성, 법무 검토 요청, 협상, 승인이 전부 여기 포함될 수 있습니다.

그래서 먼저 업무의 경계를 설정합니다.

Trigger	영업팀으로부터 계약서가 접수된다
Outcome	위험 조항과 검토 의견이 정리된다

이렇게 잡으면 다뤄야 할 Workflow가 선명해집니다. 질문도 “계약 검토 전체를 AI로 바꾼다”에서 “영업팀에서 계약서를 받은 뒤 위험 조항과 검토 의견이 정리되기까지의 Workflow를 어떻게 바꿀 것인가”로 구체화됩니다.

FRAME의 목적은 문제정의를 거창하게 만드는 것이 아닙니다. 실습 가능한 업무 단위로 Scope를 설정하는 것입니다.

Scope가 크면 뒤가 전부 무너진다

범위를 좁히지 않으면 이후 단계에서 차례로 문제가 생깁니다.

• MAP에서 수십 개의 단계가 쏟아집니다.
• FIND에서 AI를 어디에 적용해야 할지 고르기 어려워집니다.
• EXTRACT에서 서로 다른 종류의 전문가 판단이 뒤섞입니다.

조직에서 ‘고객센터 AX’, ‘네트워크 장애 대응 AX’, ‘계약 업무 AX’ 같은 큰 과제를 들고 왔더라도, 실제로 설계할 때는 그 안에서 하나의 Trigger와 Outcome으로 설명할 수 있는 단위를 골라야 합니다.

자기 업무에 던져볼 질문

• 이 일은 정확히 무엇이 발생하면 시작되나요?
• 어떤 결과가 나오면 이 일은 끝났다고 볼 수 있나요?
• 지금 가장 문제가 되는 구간은 어디인가요?
• 조직 전체 업무가 아니라, 하루 안에 설계해볼 수 있는 한 조각은 어디인가요?
• 지금 설명한 Scope 안에 사실 서로 다른 Workflow가 여러 개 섞여 있지는 않나요?

Case Study. FRAME

’상품정보 정합성을 AI로 개선한다’라고 잡으면 범위가 너무 큽니다. 상품명, 카테고리, 브랜드, 옵션, 가격, 이미지, 리뷰, 주문 이력이 전부 섞일 수 있습니다.

그래서 이렇게 좁혔습니다.

• Trigger: 셀러(Seller)가 기존 상품의 핵심 정보를 변경한다
• Outcome: 상품의 정체성을 훼손하는 변경이 탐지되고 위험도에 맞게 처리된다
• Scope: 변경 발생 → 정합성 판단 → 후속 조치 → 셀러 문의 대응까지
• Pain Point: 운영팀이 변경 건을 전수 수기 검수하고 있음

이 정도로 좁히고 나면 무엇을 분해해야 할지가 분명해집니다.

다음 편 예고

경계를 그었으니 이제 그 안을 들여다볼 차례입니다. 다음 편에서는 지금 그 업무가 실제로 어떻게 돌아가고 있는지 분해하는 MAP을 다루겠습니다.

한 줄로 남깁니다. Trigger와 Outcome 한 쌍으로 설명되지 않는 범위는 아직 설계할 수 있는 단위가 아닙니다.