오후 7시 8분에 예약이 사라집니다.

여섯 명이 8시에 만나기로 되어 있었습니다. 한 명은 이미 퇴근했습니다. 다른 한 명은 10시까지 집에 가야 합니다. 누군가는 채식주의자입니다. 두 명은 조용히 35달러를 한도로 정했습니다.

그때 iMessage로 취소 메시지가 도착합니다:

죄송합니다, 오늘 밤 귀하의 일행을 모실 수 없게 되었습니다.

그룹은 그룹답게 반응합니다.

“근처에 다른 곳 있어?”

“난 다 괜찮아.”

“브루클린(Brooklyn)은 어때?”

세 개의 스크린샷이 도착합니다. 누군가는 작년에 문을 닫은 장소를 제안합니다. 원래 계획을 조직했던 사람은 그룹이 이미 내린 모든 결정을 다시 검토하기 시작합니다.

이 지점에서 일반적인 챗봇(chatbot)은 잘못된 종류의 도움을 주는 경향이 있습니다. 바로 더 많은 아이디어를 제공하는 것입니다.

하지만 취소된 계획은 백지 상태가 아닙니다. 그것은 복구(recovery) 문제입니다.

취소를 실패한 의존성(failed dependency)처럼 다루세요

소프트웨어에서 하나의 서비스가 실패했다고 해서 애플리케이션 전체를 다시 구축하는 것은 아닙니다. 무엇이 고장 났는지 식별하고, 작동 중인 상태를 보존하며, 가능한 가장 작은 구성 요소(component)를 교체합니다.

그룹 계획도 동일한 예우를 받을 자격이 있습니다.

대안을 찾기 전에, 여전히 유효한 모든 것을 고정하세요:

그룹 인원: 6명
시작 시간: 8:00 경
종료 시간: 10:00 이전
...

예약은 실패했습니다. 하지만 이 제약 조건(constraints)들은 실패하지 않았습니다.

이 차이가 중요한 이유는 “다른 어디로 가야 할까?”라는 질문이 위치, 시간, 비용, 음식, 분위기를 한꺼번에 실수로 다시 열어버리기 때문입니다. 그러면 모든 사람이 조금씩 다른 문제를 풀게 됩니다.

그 결과는 협업이 아닙니다. 그것은 인간 중개자를 통해 논쟁하는 여섯 개의 브라우저 탭일 뿐입니다.

영향을 받은 결정만 다시 논의하세요

유용한 질문은 다음과 같습니다:

취소로 인해 무엇이 변했는가?

장소가 취소되었다면, 장소는 바뀌어야 합니다. 그룹 인원은 아마 바뀌지 않을 것입니다. 개인의 예산, 식단 요구 사항, 통근 거리, 또는 반드시 떠나야 하는 시간도 마찬가지입니다.

나는 이것을 취소의 폭발 반경(blast radius)이라고 부릅니다.

공정한 대안은 그 반경을 작게 유지합니다. 다른 모든 사람이 조급해한다는 이유만으로 누군가 더 많은 돈을 쓰게 하거나, 훨씬 더 멀리 이동하게 하거나, 제약 조건을 무시하게 해서는 안 됩니다.

공정함(Fair)이 모든 선택지가 모두를 똑같이 즐겁게 해야 한다는 것을 의미하지는 않습니다. 그런 기준을 적용한다면 대부분의 그룹은 자정까지 인도 위에 서 있게 될 것입니다.

그것은 혼란(disruption)이 유연성이 가장 낮은 사람에게 전가되지 않음을 의미합니다.

Photo by Brands&People on Unsplash

또 다른 추천 목록을 쏟아내지 말고, 회복 세트(recovery set)를 생성하세요

남아있는 제약 조건(constraints)이 명확해지면, 2개에서 4개 사이의 옵션을 만드세요. 그 이상은 안 됩니다.

각 옵션은 네 가지 부분이 필요합니다:

옵션(OPTION)
그것이 무엇인지

...

취소된 저녁 식사의 경우, 메시지는 다음과 같을 수 있습니다:

A — 같은 동네에 머물기
모두의 도착 시간을 보존하고 추가 이동을 피합니다.
트레이드오프(Trade-off): 음식 선택지가 적음.
실행 사항(Action): 6인석 예약 가능 여부 및 현재 가격 확인.

B — 그룹의 중간 지점 방향으로 지하철 한 정거장 이동하기
이동을 감당할 수 있는 수준으로 유지하며, 더 많은 채식 옵션을 제공할 수 있습니다.
트레이드오프(Trade-off): 이미 근처에 있는 사람들이 다시 이동해야 함.
실행 사항(Action): 현재 이동 시간 및 예약 가능 여부 확인.

C — 저녁 식사에서 캐주얼한 푸드홀(food-hall) 형식으로 전환하기
그룹을 나누지 않고도 식단 선호도를 처리하기가 더 쉬워집니다.
트레이드오프(Trade-off): 덜 친밀하며 잠재적으로 더 시끄러울 수 있음.
실행 사항(Action): 폐점 시간, 좌석, 실시간 혼잡도 확인.

무엇이 빠져 있는지 주목하세요: 14개의 "멋진 장소들", 동네 가이드, 그리고 숨겨진 명소에 대한 문단 말입니다.

그룹은 더 이상 영감을 필요로 하지 않습니다. 그들에게 필요한 것은 결정(commit)입니다.

그룹이 실제로 답변할 수 있는 결정 메시지를 전달하세요

주최자는 "어떻게 생각하세요?(Thoughts?)"로 끝내서는 안 됩니다.

그것은 단지 논의를 다시 시작할 뿐입니다.

범위가 정해진 결정(bounded decision)을 사용하세요:

기존 예약은 사라졌지만, 우리의 예산, 시간, 그리고 여행 제한 사항은 여전히 유효합니다. 이것이 실행 가능한 세 가지 백업 안입니다. 7시 20분까지 A, B, 또는 C로 답장해 주세요. 과반수가 결정되지 않으면, 추가 이동이 가장 적은 A로 결정하겠습니다.

이제 침묵은 의미를 갖습니다. 대안(fallback)이 가시화되었습니다. 결정에는 마감 기한이 있습니다.

저의 오렌지색 태비 고양이인 Marlow는 더 단순한 복구 프로토콜(recovery protocol)을 사용합니다. 어떤 계획이든 실패하면, 집으로 돌아가 저녁을 요구하는 것입니다. 이는 내부적으로 일관적이지만, 여섯 명의 인간에게 확장(scale)하기에는 그리 좋지 않습니다.

AI 어시스턴트가 유용해지는 지점

여기서 AI의 유용한 역할은 채팅방에서 가장 열정적인 사람을 흉내 내는 것이 아닙니다. 그룹이 시간 압박을 받는 동안 문맥(context)을 보존하는 것입니다:

1. 자발적으로 제공된 제약 조건(constraints)을 포착합니다.
2. 취소로 인해 실제로 무효화된 것이 무엇인지 식별합니다.
3. 현재 확인 가능한 두 개에서 네 개의 대안을 제시합니다.
4. 각 대안이 왜 적합한지 설명합니다.
5. 요약된 목록을 결정 메시지로 변환합니다.

이러한 워크플로(workflow)가 구축되면, 그룹은 한 사람에게 전체 상황을 수동으로 재구성해 달라고 요청하는 대신, iMessage 계획 프로세스에 현지 추천을 위한 Karpo를 명시적으로 초대할 수 있습니다.

초대는 중요합니다.

어시스턴트는 대화에 조용히 끼어들거나, 사용을 선택하지 않은 사람들의 프로필을 구축해서는 안 됩니다. 그룹 내 비사용자들에 대해서는, 해당 결정에 대해 그들이 자발적으로 제공한 제약 조건만 필요합니다.

"채식 옵션이 필요함"이면 충분합니다. 그 이유를 추론할 필요는 없습니다.

"35달러 이상은 지출할 수 없음"이면 충분합니다. 그 누구도 소프트웨어나 그룹에 자신의 재정적 이력(financial biography)을 제공할 의무는 없습니다.

챗봇(chatbot)과의 진짜 차이점

챗봇은 가장 최근의 메시지에 답합니다.

결정 워크플로(decision workflow)는 계획의 상태(state)를 유지합니다.

그 상태에는 선호도 그 이상의 것이 포함됩니다. 여기에는 엄격한 제약 조건(hard constraints), 이전의 합의 사항, 실시간 조건, 사회적 결과, 그리고 완료를 위해 필요한 행동이 포함됩니다.

취소된 그룹 계획의 경우, 유용한 시퀀스(sequence)는 다음과 같습니다:

맥락 유지 (preserve context)
→ 실패 원인 격리 (isolate the failure)
→ 2~4개의 실행 가능한 대안 생성 (generate 2–4 viable backups)
...

추천의 품질 또한 여전히 중요합니다. 가격, 영업시간, 교통 상황, 그리고 예약 가능 여부는 결정 시점에 반드시 확인되어야 합니다.

하지만 더 큰 개선은 AI에게 올바른 문제를 해결하도록 요청하는 데서 옵니다.

다음과 같이 묻지 마세요:

우리가 무엇을 더 할 수 있을까?

대신 다음과 같이 물으세요:

이 그룹을 다시 움직이게 만들 수 있는 가장 작고 공정한 변화는 무엇인가?

이것이 단순히 선택지를 만들어내는 것과 계획을 회복하는 것 사이의 차이입니다.