설계 단계부터 인간 개입(Human-in-the-Loop): 아웃바운드 워크플로우에서 승인이 필요한 이유

제가 참여했던 모든 AI 영업 데모는 대략 같은 시나리오를 따릅니다.

누군가 대시보드를 보여줍니다. 회사 이름을 입력하고 버튼을 누르면, 30초 후 개인화된 이메일 시퀀스가 화면에 나타납니다. 초안이 작성되고, 형식이 갖춰지며, 전송할 준비가 되어 있습니다. 청중은 감탄하며 고개를 끄덕입니다. 발표자는

데이터 보강(Enrichment)도 마찬가지입니다. 기업 정보학적 데이터(firmographic data)를 가져오고, 계정 내에서 적절한 연락처를 찾으며, 활성화된 자격 신호(qualifying signals)가 있는지 확인하는 일은 연구 작업이며, 이는 인간보다는 빠르고 일관성이 유지되는 것이 이점을 주는 종류의 연구 작업입니다. 사람이 할 경우, 누가 하느냐와 얼마나 피곤하냐에 따라 품질이 달라집니다. 시스템이 할 경우, 품질은 규칙이 얼마나 잘 작성되었는지에 따라 달라지며, 이 규칙은 한 번 고치면 계속 그 상태를 유지할 수 있습니다.

신호 감지(Signal detection)도 여기에 속합니다. 만약 영업 부사장(VP of Sales)이 회사에 새로 합류했다는 것은 세상에 대한 사실입니다. 시스템은 이를 관찰할 수 있습니다. 하지만 시스템이 도움 없이 할 수 없는 것은, 이 특정 페르소나, 이 특정 계정의 맥락에서, 그리고 당신이 시작하기를 바라는 대화에 대해 알고 있는 정보를 바탕으로 그 사실이 무엇을 의미하는지 결정하는 것입니다. 이것이 해석(interpretation) 단계이며, 매칭 및 데이터 보강 단계가 필요로 하지 않는 무언가를 요구합니다.

초안 작성(Drafting) 역시 제대로 수행된다면 이 범주에 속합니다. 만약 페르소나별 메시지를 인코딩하고, 이 신호에 대한 좋은 오프닝 라인이 무엇인지 정의했으며, 어떤 비즈니스 가설로 시작할지 확립했다면, 초안은 조립(assembly)입니다. 올바른 조각들을 올바른 순서대로 배치하는 것입니다. 초안의 품질은 사람이 타이핑했는지 여부가 아니라 입력된 정보의 품질에 달려 있습니다.

이 모든 단계들이 공유하는 점은 다음과 같습니다. 검증할 수 있다는 것입니다. 테스트 세트를 대상으로 실행하고, 출력물을 검사하며, 숙련된 인간이 했을 결과물과 비교하여, 당신이 자신의 이름을 걸고 자랑스러워할 만한 결과를 산출할 때까지 논리를 조정할 수 있습니다. 이것이 이들을 자동화하기에 안전하게 만드는 이유입니다.

의도적으로 인간에게 남겨두는 단계들

그리고 자동화될 수 있을 것 같지만, 그렇게 해서는 안 되는 단계들이 있습니다. 그 구별은 역량(capability)이 아니라 결과와 맥락(consequence and context)에 달려 있습니다.

메시지 승인(Messaging approval). 초안이 발송되기 전에 인간이 이를 확인합니다. 이것이 가장 중요한 검토 지점이며, 대부분의 자동화 데모가 이야기를 느리게 만든다는 이유로 건너뛰는 부분입니다.

이것이 존재하는 이유는 시스템이 초안을 잘못 작성하기 때문이 아닙니다. 시스템 자체만으로는 처리할 수 없는 표준적인 영역이 존재하기 때문입니다. 초안은 페르소나에 맞고, 적절한 신호를 참조하며, 올바른 가설로 시작하여 훌륭할 수 있지만, 이 특정 잠재 고객에게 오늘이라는 특정 날짜에는 여전히 틀릴 수 있습니다. 상업적 관계는 데이터 외부에서 존재하는 맥락을 가지고 있습니다. 시스템은 이 계정이 이미 경쟁사와 대화 중이라는 것을 알지 못합니다. 지난주에 선임 담당자가 챔피언(champion)과 커피를 마셨다는 것도 모릅니다. 오늘 아침 회사에서 구조조정(layoffs)을 발표했다는 사실도 모르며, 지금이 적절한 시기가 아닐 수도 있습니다.

인간 검토 단계가 자동화가 신뢰할 수 없다는 표시가 아닙니다. 오히려 시스템이 자신이 무엇을 모르는지 알고 있다는 것을 설계했다는 증거입니다.

상업적 판단(Commercial judgment). 가격 논의, 계약 협상, 양보(concessions), 거래 구조 등은 법적인 이유뿐 아니라 어떤 경우에도 자동화되어서는 안 됩니다. 이러한 순간들은 상황을 실시간으로 읽고, 이 특정 구매자가 무엇을 중요하게 생각하는지에 대한 판단을 내리며, 플레이북에 예측된 내용이 아닌 실제로 대화에서 일어나고 있는 일에 대응할 만큼 충분히 현장에 존재해야 합니다.

시스템은 패턴 매칭(pattern matching)을 기반으로 어떤 계정이 가장 높은 확률로 성사될지 알려줄 수 있습니다. 하지만 거래를 살리기 위해 할인을 제공해야 하는지 여부는 알려주지 못합니다. 그것은 관계에 관한 문제이며, 권한과 맥락, 그리고 틀릴 수도 있고 회복할 수도 있는 능력을 가진 사람이 필요합니다.

민감한 발송(Sensitive sends). 챔피언의 퇴사. 위험에 처한 갱신 계약(At-risk renewals). 창업자 대 창업자 아웃리치(Founder-to-founder outreach). 잘못된 어조가 단순히 비효율적일 뿐만 아니라 실제로 손상을 입힐 수 있는 모든 메시지입니다. 이들은 초안이 아무리 좋아도 항상 인간을 거쳐야 합니다. 왜냐하면 잘못되었을 때의 비용이 비대칭적이기 때문입니다.

챔피언이 떠날 때, 다음 30일을 어떻게 처리하느냐가 계정을 유지할 수 있을지 결정할 수 있습니다. 그것은 템플릿화(templating) 문제가 아닙니다. 관계 문제입니다. 그리고 사람의 손길이 필요합니다.

체크포인트 패턴(Checkpoint Pattern)

실제로는 생성(generation)과 전달(delivery)을 분리하고 그 사이에 검토 대기열(review queue)을 두는 워크플로우의 형태를 띱니다.

시스템은 기계적인 단계들, 즉 계정 매칭(accounts matching), 연락처 정보 보강(contacts enriching), 신호 감지(detecting signals), 초안 생성(generating drafts) 등을 처리합니다. 이 초안들은 검토 대기열로 들어갑니다. 사람이 그 대기열을 열고, 초안을 보고, 편집하거나 승인하거나 혹은 폐기할 수 있습니다. 일단 승인되면, 발송 기록이 CRM, 전달 시스템, 그리고 팀원들이 누구에게 무엇이 말해졌는지 정렬 상태를 유지하는 모든 공유 레코드에 기록됩니다.

account_match()         → queue
  ↓
contact_enrich()        → queue
...

검토 대기열은 인간의 판단이 존재하는 곳입니다. 이것은 병목 현상(bottleneck)이 아니라, 그 자체가 목적이기 때문에 의도적으로 배치된 게이트(gate)입니다.

미리 결정해야 할 한 가지가 있습니다. 검토자가 좋은 결정을 내리기 위해 무엇을 봐야 하는가? 만약 그들이 초안과 수신자 이름만 본다면, 적절하지 않은 것을 승인하고 유지했어야 할 것을 거부할 것입니다. 검토 인터페이스는 초안을 발생시킨 신호(signal), 페르소나 근거(persona rationale), 캠페인 맥락(campaign context)를 노출해야 합니다. 단순히 서명하는 것이 아니라, 실제로 검토할 수 있도록 충분한 정보를 보여줘야 합니다.

맥락을 전혀 제공하지 않는 검토 단계는 안전장치(safety measure)가 아닙니다. 그것은 마치 인간 개입(human-in-the-loop)을 유지하고 있는 것처럼 느끼게 하지만 실제로는 그들의 판단 능력을 제거하는 체크박스에 불과합니다.

이것이 한계가 아닌 설계 선택인 이유

프레이밍(framing)이 여기서 중요합니다. 많은 팀들이 인간 검토 단계를 일시적인 불편함, 즉 시스템이 충분히 좋아지면 결국 자동화하여 제거할 무언가로 생각합니다.

그것은 잘못된 모델입니다.

**의도적으로 인간에게 남겨두는 것은 자동화가 아직 다루지 못한 잔여 범주(residual category)의 것이 아닙니다. 그것은 어떤 판단에 대해 누가 책임을 져야 하는지에 대한 의도적인 설계 결정입니다. 상업적 통화, 관계에 중요한 메시지, 그리고 비대칭적인 하방 위험(asymmetric downside)을 가진 모든 것은 시스템이 그럴듯한 것을 초안 작성할 수 없기 때문에 인간에게 남겨두는 것이 아니라, 책임 구조가 적절하기 때문에 인간의 영역으로 남겨둡니다. (stay human).

잘 설계된 아웃바운드 시스템의 목표는 사람들을 프로세스에서 제거하는 것이 아닙니다. 그들의 주간 일정에서 수동적이고 반복적인 작업을 제거하여, 실제로 그들이 필요한 순간에 집중할 수 있도록 하는 것입니다. 매일 2시간을 리서치와 초안 작성에 쓰는 영업 담당자(rep)가 없다면, 그는 중요한 통화에 쓸 2시간을 갖게 됩니다. 이것이 복리 효과입니다 (compound).

이러한 사고 모델로 시스템을 구축하면, 기계적인 단계는 자동화하고, 판단 단계는 의도적으로 남겨두며, 승인 게이트(approval gates)를 명시할 때, 데모 버전에서는 절대 보여주지 못하는 것을 얻게 됩니다. 즉, 팀이 실제로 신뢰하는 아웃바운드 프로세스입니다. 빠르기 때문이 아니라, 무엇이 자동화되었고 무엇이 그렇지 않은지 정확히 알기 때문에, 그들은 자신의 판단이 어디에서 기대되는지 알고 있으며, 어떤 격차(gap)가 있는지 알려주는 놀라운 일만을 기다리지 않습니다.

승인 체크리스트 (The Approval Checklist)

여기는 저희가 내부적으로 사용하는 1차 게이트입니다. 이것을 복사하고, 적응시키고, 자체 검토 기준을 정의하는 출발점으로 사용하세요.

OUTBOUND APPROVAL CHECKLIST
─────────────────────────────────────────────
ACCOUNT MATCH
...

마지막 항목인

기계적/관계적 경계를 어디에서 그어야 하는지, 그리고 처음으로 이를 구축할 때 의사 결정 프레임워크가 어떻게 생겼는지에 대한 전체 분석은 **의도적으로 인간이 개입하는 부분(what stays human on purpose)**의 원본 게시글에서 시작하는 것이 좋습니다. 검토 인터페이스로서의 커맨드 센터(command centre)에 대한 섹션은 이 글과 함께 읽어볼 가치가 있습니다.

귀하의 팀은 검토 단계를 어떻게 처리하나요? 실제로 유용할 만큼 충분한 컨텍스트를 제공하는 검토 인터페이스를 구축해 본 분이 계신지, 그리고 사람들이 신뢰하는 게이트와 단순히 승인만 하는 게이트 사이의 차이를 만든 것이 무엇인지 궁금합니다. 댓글로 공유해주세요.