고객 지원 시스템이 주문 환불을 권합니다. 화면에는 “높은 확신”이라고 쓰여 있지만 담당자는 어떤 주문인지, 어떤 정책 버전인지, 대체 배송이 이미 나갔는지 볼 수 없습니다. 권고가 맞을 수도 있습니다. 그러나 담당자는 알 방법이 없습니다. 보고된 사고가 아니라 설명을 위한 고객 지원 상황입니다.
의사결정 지원 시연은 더 살펴보기 쉬운 방식을 보여줍니다. 검토자는 최종 제안만 받지 않고 개별 측정값을 보고 원본 검사 자료를 열 수 있습니다. 시연은 독립 검증이 특히 중요한 의료 환경에서 이뤄집니다. 임상 정확성을 입증하지는 않습니다. 공급자의 성과 주장을 빌리지 않으면서 설계 교훈을 덜 민감한 업무에 옮길 수 있습니다.
결론은 근거를 압축합니다
압축은 유용합니다. 주문을 환불할지 묻는 사람은 장부의 모든 이벤트를 읽고 싶지 않습니다. 권고는 긴 기록을 다음 행동으로 바꿀 수 있습니다. 하지만 압축은 결과를 뒤집을 수 있는 세부사항도 버립니다.
설명용 주문 이력을 생각해 보세요. 고객이 소포를 받지 못했다고 말합니다. 모델은 운송업체 정보에서 “미배송”을 보고 환불을 제안합니다. 다른 레코드에는 오늘 아침 대체품이 발송됐다고 적혀 있습니다. 권고안이 그 기록을 숨기면 담당자는 한 문제에 두 번 보상할 수 있습니다. 두 사실과 시점을 모두 보여주면 정보를 바탕으로 선택할 수 있습니다.
인터페이스는 행동을 권하기 전에 네 가지 질문에 답해야 합니다. 무엇을 관찰했나요? 어디서 왔나요? 얼마나 최신인가요? 무엇 때문에 이 권고가 틀릴 수 있나요? 문장으로 된 이유는 답의 일부일 뿐입니다.
원본 관찰과 검토자를 연결하는 권고안에 출처와 불확실성을 담아 검토자가 원본 레코드를 살펴볼 수 있게 합니다.
“배송 실패로 환불”이라는 문장은 자연스러워도 운송업체 상태가 오래됐을 수 있습니다.
| 보이는 요소 | 검토자가 확인할 수 있는 것 |
|---|---|
| 권고안과 제안된 행동 | 행동이 업무와 맞는지 |
| 시각이 있는 원본 관찰 | 사실이 최신이고 완전한지 |
| 누락되거나 충돌하는 근거 | 멈추거나 조사해야 하는지 |
| 원본 레코드 링크 | 요약이 결정적인 세부사항을 빼먹었는지 |
| 결과와 수정 이력 | 비슷한 제안이 반복해서 실패하는지 |
개념적인 인터페이스 점검표이며 특정 대시보드가 더 나은 결정을 만든다는 주장은 아닙니다.
불확실성을 작은 글씨가 아니라 업무에 넣기
시스템이 불확실한 이유는 여러 가지입니다. 원본이 응답하지 않았거나, 식별자 두 개가 같은 주문을 가리킬 수 있거나, 마지막 색인 이후 정책이 바뀌었을 수 있습니다. 모델이 자유 형식의 불만을 해석하기 어려울 수도 있습니다. 서로 다른 실패 유형이므로 표시 방식도 달라야 합니다.
운영자가 빠진 사실 하나를 확인할 수 있다면 “낮은 확신”만으로 부족합니다. “운송업체 정보는 어제 마지막으로 갱신됨” 또는 “대체품 레코드를 가져올 수 없음”이라고 보여주세요. 점수의 근거가 없다면 정밀한 백분율을 화면에 칠하지 마세요. 검토자가 다음 확인 대상을 정할 수 있게 하는 것이 목적입니다.
데이터 동기화에도 같은 구조가 중요합니다. 목적지가 새 고객 상태를 받는다면 변경을 만든 원본 이벤트 ID, 시각, 규칙을 보존하세요. 누군가 왜 캠페인에 고객이 포함됐는지 묻는다면 팀이 결정을 거꾸로 추적할 수 있습니다. 설명 없는 복사 값은 근거 없는 결론입니다.
이 Tajo 제안 화면은 활동 기록이 보고하는 것과 아직 증명되지 않은 것을 나눕니다. 쓰기는 적용됐지만 대상 확인은 대기 중입니다. 기존 Tajo 활동 피드는 결과와 원본 이벤트를 보여 줍니다. 추가된 검증 패널은 그 경계를 더 잘 보이게 하는 그림입니다.
쓰기가 끝나도 증거는 필요합니다
고객 동기화가 끝났나요?
쓰기가 적용됐습니다. 검증은 대기 중입니다.
대상 시스템의 상태는 아직 확인하지 않았습니다.
동기화 활동
- 요청 수락됨
- 업데이트 적용됨
- 대상 확인 대기 중
실행 예시 · 14:32 UTC
확인된 내용
- 제공업체 응답
- 수락됨
- 쓰기 결과
- 적용됨
- 대상에서 다시 읽기
- 대기 중
호출 성공만으로 최종 상태를 증명할 수 없습니다.
Tajo 활동 피드를 참고한 제안 화면입니다. 이 그림의 검증 상태는 예시이며 대상에서 다시 읽는 기능이 이미 구현됐다는 뜻은 아닙니다.
모든 것을 노출하지 않고 검토 가능하게 하기
일상적인 동작 대부분은 사건 파일을 열 필요가 없어야 합니다. 좋은 인터페이스는 권고안을 간결하게 유지하면서 근거를 한 단계 안에서 볼 수 있게 합니다. 선택을 바꿀 수 있는 불일치만 강조할 수도 있습니다. 근거를 완전히 숨기는 것과는 다릅니다.
더 많은 데이터를 보여주는 데에는 실제 개인정보 비용이 있습니다. 검토자는 원본 레코드를 지배하는 접근 규칙 아래 이 결정에 필요한 필드만 봐야 합니다. 근거를 보여준다는 것이 고객 이력을 무제한 공개할 권한은 아닙니다. 보존과 감사 로그에도 소유자가 필요합니다.
또 다른 우려는 자동화 편향입니다. 보이는 권고안도 검토자의 판단을 이끌 수 있습니다. 검토자가 의도적으로 심어 둔 모순을 발견하는지, 인터페이스와 씨름하지 않고 “근거 부족”을 선택할 수 있는지 시험하세요. 배포 후 수정과 번복 패턴을 측정하세요. 그럴듯한 설명은 성과 지표가 아닙니다.
검토 인터페이스에는 이견을 기록할 자리도 필요합니다. 담당자가 환불 제안을 거부한다면 시스템을 개선할 만큼 좁은 이유를 물으세요. 잘못된 주문 매칭, 오래된 운송업체 상태, 누락된 대체품 기록, 정책 예외가 될 수 있습니다. 모든 이견에 긴 글을 요구하지 마세요. 이유를 모아 한 원본에서 문제가 반복되는지 살피세요. 개별 검토에서 시스템 수리로 가는 경로가 됩니다. 워크플로 발견 가이드는 제안을 만들기 전에 실제 예외 경로를 찾는 데 도움을 줍니다. 결론 옆의 근거는 오늘 검토자를 돕고 수정 데이터는 내일의 결정 경로를 개선할 수 있습니다.
결과가 큰 행동에는 검토 경로가 제품 계약의 일부여야 합니다. 시스템은 제안하고, 사용한 근거를 밝히고, 확인하지 못한 것을 명시하고, 결과를 기록합니다. 근거로 선택할 수 없다면 가장 유용한 결론은 “기다리세요”일 수 있습니다.
자주 묻는 질문
설명이 있으면 권고안을 믿을 수 있나요?
아닙니다. 그럴듯한 설명이 틀린 결과와 함께 나올 수 있습니다. 검토자는 자신 있는 문장만이 아니라 원본 관찰, 출처, 불확실성, 결과를 볼 수 있어야 합니다.
자동 제안 옆에는 어떤 근거가 있어야 하나요?
사용된 구체적 관찰 내용과 출처·시점, 누락된 입력, 관련 규칙 또는 모델 버전, 원본 레코드를 살펴볼 방법을 보여주세요.
언제 사람이 결과를 검토해야 하나요?
결과가 시스템의 허용 범위를 넘거나 근거가 불완전하고 오래됐거나 다툼이 있을 때입니다. 검토자는 실질적으로 반대하고 행동을 멈출 수 있어야 합니다.