지난 기사에서 CS 대응 답장 생성을 「실행 게이트를 결정하기 위한 판단의 연속」으로 재정의했다. 여기에서는 그 골격을 실제로 어떻게 구성할 것인가에 대해 이야기하고자 한다.

1. 블록이라는 단위

본 기사에서는 판단의 최소 단위를 **블록 (Block)**이라고 부른다. 블록이란 특정 상태(state)의 조건을 만족하면 독립적으로 발화하여, 답장에 포함해야 할 액션(action)을 하나 추가하는 단위를 말한다. 여러 블록이 각자의 조건에 따라 동시에 (OR 결합으로) 발화하며, 발화한 블록들의 조합이 최종적인 답장이 된다. 「진단이 확정되면 교체를 제안한다」, 「책임 소재가 불분명하면 공감의 한마디를 덧붙인다」와 같은 개별 규칙이 각각 하나의 블록에 해당한다.

역할별로 나누면, 블록은 온도감 대응 · 정보 수집 · 답변 안내 · 대응 실행 · 보류 연결 · 클로즈의 6개 그룹으로 나뉜다. 감정적인 케어, 사실 확인, 정보 제공, 실제 액션, 결론을 보류하여 연결하는 처리, 마무리 인사라는 6가지 기능에 대응한다.

「결함인가, 사용자 측의 문제인가」를 판별하는 판단은 많은 현장에서 **미구조화 (Unstructured)**된 상태로 운용되고 있다. 미구조화란 판단 기준이 어디에도 기록되어 있지 않고, 경험을 쌓은 사람의 머릿속에만 체크리스트로서 존재하는 상태를 말한다. 기록되어 있지 않기 때문에 인수인계가 불가능하고, 누락이 있어도 알아차릴 수 없으며, 부분적인 자동화도 할 수 없다.

이는 상품 × 증상 × 부품의 매트릭스(확인해야 할 사항 + 결함이라고 판정하는 요소)로 작성함으로써 구조화 및 자동화할 수 있는 대상이 된다. 머릿속에만 있던 암묵지(Tacit knowledge)를 검색 가능한 표로 변환하는 것이다.

블록의 정체 — 루틴의 숙달과 적응적 숙달

이 「블록」이라는 단위 자체가 무엇인지 인지과학의 프레임워크를 빌려 정리해 둔다. 블록(진단 매트릭스나 온도감 대응 등의 형태)은 「루틴의 숙달 (Routine expertise)」의 외부화다. 지금까지 축적되어 온 「이럴 때는 이렇게 판단한다」라는 경험의 결정체를 누구나 참조할 수 있는 형태로 꺼내 놓은 것에 불과하다.

반면, 블록 자체를 재구성하는 힘—새로운 상황을 마주했을 때 기존 블록 중 무엇이 맞지 않는지 파악하고, 입도(Granularity)를 조정하거나 새로운 블록을 추가하는 힘—은 이와는 별개의 능력이다. 인지과학에서는 이를 「적응적 숙달 (Adaptive expertise)」이라고 부르며, 정해진 절차를 빠르고 정확하게 수행하는 「루틴의 숙달 (Routine expertise)」과 구분한다 (Hatano & Inagaki, 1986).

이 구분이 중요한 이유는 시스템이 자동화하는 것은 전차(루틴의 숙달 내용)뿐이며, 후자(블록을 설계·개정하는 힘)는 자동화의 대상이 되지 않는다는 선을 그을 수 있기 때문이다. 블록이 늘어나더라도 블록을 재구성하는 인간의 역할은 사라지지 않는다.

왜 이 세 가지를 구분하는가 — 원리 · 능력 · 미구조화

판단을 인간에게 남길지 여부에는 사실 세 가지 이유가 있으며, 각각 시간에 따른 움직임이 다르다.

지금까지 다루어 온 「미구조화」된 진단이나, 「능력」으로서의 루틴의 숙달/적응적 숙달은 이 분류에서 ②③에 해당한다. 반면, 실행 게이트(금전 · 불가역적인 대응의 승인)는 ①의 「원리」에 해당한다. 이것만은 진단의 자동화가 아무리 진행되더라도 인간에게 계속 남을 판단이다.

이유를 적지 않고 분류하면 위험할 수도 있다. 사실은 작성하면 그만인 「미구조화」를 「이것은 AI의 능력 한계니까 어쩔 수 없다」라는 변명으로 사용해 버리는 상황이 발생할 수 있다. 분류에는 이유와 「무엇이 변하면 재검토할 것인가」를 반드시 세트로 작성해야 한다.

2. 아키텍처 전체

① state 추출: 고객 메시지 → 후속 대응 여부 · 진단 플래그 (사실 면에 대해서만)
※ 주문 번호 누락 시나 증상 특정은 드롭다운 선택을 통해 인간이 확정 (AI 의존도를 낮춤)
② 블록 발화: state → 조건을 만족한 블록이 독립적으로 액션 추가 (OR 결합)
...

교환 · 환불 등 금전이 움직이고 되돌릴 수 없는 실행의 승인은 진단 정밀도와 관계없이 항상 인간이 수행한다. 「원리」는 여기에만 적용되며, 진단의 자동화가 아무리 진행되더라도 움직이지 않는 경계선으로서 설계하고 있다.

블록을 독립 발화 및 OR 결합으로 만듦으로써, 메인(main) 처리는 「루프 → 조건 판정 → 액션 추가 → 결합」이라는 범용 규칙 엔진이 되며, 복잡성은 모두 블록(데이터) 측으로 이동한다.

3. 온도감 — 마지막에 얹는 「양념」

처음에는 온도감(Temperature)을 가장 먼저 판정하여 다른 블록의 발화(Firing)에 영향을 미치게 하는 안을 고려했다. 하지만 이는 사실의 판단(무엇이 일어났는가·무엇을 할 것인가)과 감정의 전달 방식(어떻게 전달할 것인가)을 동일한 레이어에서 혼재시키게 된다. 그래서 온도감은, 다른 블록이 확정된 후에 인간이 마지막에 얹는 맛付け(Seasoning) 레이어로서 분리했다.

맛付け는 서두나 말미의 한마디뿐만 아니라 문장 전체에 걸친다. 온도감이 높은 고객일수록 단어 선택에 정중함이 필요하기 때문에, 그곳에 투입되는 토큰(Token)량이 늘어나는 것을 허용한다.

저온: 블록 결합만 수행, AI 미사용 (최저 비용·완전 결정론적)
중온: 연결 부위만 AI가 다듬음 (가벼운 공수)
고온: 문장 전체를 AI가 온도감에 맞춰 다시 작성 (토큰 사용 허용)

중요한 것은, 온도가 아무리 높아지더라도 다시 작성되는 것은 말투(Wording)뿐이며, 블록의 발화(무엇을 전달할 것인가·어떤 액션을 취할 것인가)는 온도와 무관하게 결정론적인 상태로 유지된다는 점이다. 압축·재현성·감사 가능성(Auditability)이 필요한 부분은 '무엇을 결정했는가'이며, 그 부분은 온도에 좌우되지 않는다. 토큰을 사용해도 되는 부분은 '어떻게 전달할 것인가'뿐이며, 가치가 발생하는 곳에만 예산을 할당하는 설계가 된다.

이러한 분리는 인간의 관여 포인트를 두 종류로 정리한다는 의미도 갖는다. 실행 게이트(원리·거버넌스, 항상 인간)와는 별개로, 온도감의 맛付け(감각적인 판단, 인간의 직관을 의도적으로 남기는 영역)라는 성질이 다른 두 번째 인간 터치포인트(Human touchpoint)가 생긴다.

4. 롤플레이를 통해 검증하며 알게 된 것

이 모델이 정말로 기능하는지, 두 가지 대조적인 케이스(결함·실행계 케이스와 고객 사정·반품/환불 케이스)를 롤플레이를 통해 검증했다.

보여진 공통의 골격은 다음 네 가지였다.

• 진단·정책 해당성이 확정될 때까지 실행계 액션은 발화시키지 않는다 (원리는 실행 승인에만 적용한다)
• 확정에는 자기 신고가 아닌 증거를 요구하며, 증거가 불충분하면 재요청을 통해 입도(Granularity)를 높인다
• 기업 측이 비용을 지불하기 전에 고객 측의 의사·조건 동의를 확인하는 게이트를 배치하면 불필요한 재작업(Rework)을 방지할 수 있다
• 온도감 대응 블록은 '책임이 확정되었는가'에 따라 사과와 유감 표명을 전환할 필요가 있다

동시에 검증을 통해 발견된 추가적인 설계 요소도 있다. 실행계 액션에는 실행 전에 확정해야 할 부수 정보와 쌍으로 발화하는 블록이 필요한 경우가 있다는 점. 현상 확인 등의 전제 조건은 자기 신고가 아닌 증거를 요구하는 운용으로 한다는 점. 고객 사정에 따른 비용 관련 질문은 사내 규정이 명문화되어 있다면 템플릿화할 수 있지만, 그렇지 않다면 원리 측(에스컬레이션)으로 넘긴다는 점이다.

5. 블록은 얼마나 재사용할 수 있는가

두 패턴의 롤플레이에서 발화한 블록을 종류별로 집계해 보니, 세 가지 층으로 나뉘었다.

• 완전 공통 (로직 동일, 파라미터만 다름): 주문 정보 대조, 시각적 증거 요청, 실행 게이트 화면, 온도감 라우팅 등
• 골격 공통 + 알파 (개별 로직 필요): 실행 + 부수 단계의 쌍 발화, 규정 설명, 고객 동의 게이트 등
• 완전 개별: 상품 × 증상 × 부품 진단, 증상별 사실 확인·트러블슈팅 질문

단 두 패턴의 비교만으로도 종류 기반의 7~8할이 앞의 두 층(완전 공통·골격 공통 + 알파)에 수렴했으며, 신규 로직이 필요했던 것은 마지막 층뿐이었다. 패턴을 늘릴수록 이 비율은 더욱 공통 측으로 기울 것으로 예상된다. 이 마지막 층만 체크리스트화할 수 있다면, 나머지는 범용 엔진 + 데이터(블록 정의)만으로 전체를 구현할 수 있다는 전망의 근거가 된다.

6. 구현을 통해 보인 설계상의 귀결

이 골격은 경량화된 구조(스프레드시트 정도)로도 구현할 수 있는 설계로 되어 있다. 포인트는 지식의 성질에 따라 취급 방식을 나누었다는 점이다. 계속해서 늘어나는 진단 지식(상품 × 증상의 조합)은 검색형으로 관리하고, 잘 변하지 않는 공통 규칙(블록 정의)은 목록형으로 관리한다. 성질이 다른 지식을 동일한 구조로 다루려 하지 않는 것이 가벼움의 이유다.

이렇게 나누면 main 측의 처리는 '대조 → 루프 → 나열 → 게이트로 넘길지 여부 판정'이라는 범용 규칙 엔진만 남게 된다. 개별 기업의 차이·상품 차이는 코드 외부의 데이터 측에 가두어둘 수 있다. state 추출의 병목 현상 또한 AI에게 읽히는 부분을 최대한 줄이고, 인간이 선택지에서 확정하는 방식으로 유도함으로써, 필요하다면 AI 호출 없이도 동작할 수 있는 설계가 가능하다.

7. 업종을 넘나들며 검증하여 얻은 최종 결론

이 모델을 성질이 다른 여러 업종에 책상 위에서 대입해 보았다. 실제 데이터로 검증한 것이 아니라, 어디까지나 모델을 대입해 본 단계의 검증임을 미리 밝혀둔다.

대체로 그대로 유용하게 활용할 수 있었다. 6개 그룹 분류, 실행 게이트 (Execution Gate), 고객 동의 게이트 (Customer Consent Gate), 진단 매트릭스 (Diagnosis Matrix) 형식은 업종이 바뀌어도 이름만 바꾸면 기능했다. 바뀌는 것은 블록의 내용(조건과 문구)뿐이다.

다만 한 가지, 업종별로 조정이 필요한 부분이 있다. 바로 「원리 (Principle)」를 발동시키는 조건 리스트다. 이번 기준은 「금전·비가역성」이었지만, 업종에 따라서는 금전이 움직이지 않더라도 본인 확인을 실수하는 것이 비가역적인 사고로 이어지는 경우가 있으며, 이럴 때는 「본인 확인성·보안 (Security)」과 같은 조건이 원리 측에 추가된다. 승인 계층(누가, 몇 단계로 승인할 것인가) 또한 다루는 금액 규모나 업종에 따라 달라질 수 있다.

형태 (6개 그룹·게이트 구조·매트릭스 형식·main)는 업종을 불문하고 공통적이다. 업종·회사마다 커스텀 설계가 필요한 것은 「원리(인간의 승인을 필수적으로 할 것인지에 대한 판단)의 경계 설정」뿐이다.

범용적인 부분과 원리의 경계를 설정하는 부분은 성질이 상당히 다르다. 이러한 비즈니스 모델도 가능할지 모른다고 아직 생각하기 시작한 단계다.

판단의 연속성을 뒷받침한다는 지난번 이야기로 돌아가면, 이 형태가 최종적으로 하고 있는 것은 「무엇을 인간이 결정해야 하는가」를 사전에 확실히 정해두는 것이다. 그 외에는 전부 데이터로 만들어 버릴 수 있다.

Discussion