AI 인박스(Inbox)를 만드는 것을 멈추고, 대신 의사결정 계층(Decision Layer)을 구축하세요

저는 AI 기반 이메일 도구를 만드는 데 6개월을 보냈습니다. 그러고 나서 그중 절반을 삭제했습니다.

모델이 나빴기 때문도 아니고, 임베딩 (Embeddings)이 잘못되었기 때문도 아닙니다. 제가 만들고 있던 것을 포함하여 시장에 있는 모든 "AI 인박스 (AI inbox)"가 실제로 무엇을 하고 있는지 마침내 깨달았기 때문입니다.

그것들은 더 많은 것을 표면 위로 드러내고 있었습니다.

더 많은 "스마트 제안 (Smart suggestions)". 더 많은 "우선순위 신호 (Priority signals)". 더 많은 "검토를 기다리는 AI 초안 답장 (AI-drafted replies)". 더 많은 배지, 더 많은 배너, 더 많은 넛지 (Nudges). 이 카테고리의 모든 제품은 새로운 인터페이스를 추가하고 그것을 지능이라고 부르기 위해 경쟁하고 있었습니다.

제가 6개월 동안 만든 프로토타입도 그 모든 것을 수행했습니다. 저는 그것을 매일 사용했습니다. 그리고 매일 아침 인박스는 제가 시작했던 날만큼이나 시끄러웠습니다. 모델은 어떤 이메일이 중요한지에 대해 정확했습니다. 하지만 저는 여전히 다른 모든 이메일을 읽었습니다. 왜냐하면 그것들이 바로 거기에 있었고, 어쩌면 이것도 중요할지 모른다고 제안하는 작은 색상 점이 찍혀 있었기 때문입니다.

모델은 잘못된 문제를 해결하고 있었습니다.

카테고리의 버그 (The category bug)

선도적인 이메일 도구들을 이러한 관점에서 살펴보십시오:

Superhuman은 읽는 속도를 빠르게 만들었습니다. 당신은 여전히 모든 것을 읽습니다.
Shortwave는 더 똑똑하게 분류했습니다. 당신은 여전히 모든 것을 읽습니다.
Motion / Reclaim은 더 선제적으로 변했습니다. 그들은 소음 위에 캘린더 계층을 추가했습니다.

그들 중 누구도 빼앗지는 않습니다. 그들은 모두 더합니다. "AI 어시스턴트 (AI assistant)"는 당신 앞에 무언가를 하나 더 놓아도 된다는 면허가 되었습니다.

더 깊은 버그: 이 도구들은 이메일을 주요 (primary) 인터페이스로 취급하며 이를 개선하려고 시도합니다. 하지만 당신이 원하는 것은 이메일이 아닙니다. 당신이 원하는 것은 _당신이 내려야 하는 의사결정 (decisions you have to make)_입니다. 이메일은 가끔 그러한 의사결정을 포함하고 있지만, 그렇지 않은 수백 개의 이메일 아래에 파묻혀 있는, 저렴하고 신뢰할 수 없는 운송 수단 중 하나일 뿐입니다.

운송 수단을 더 예쁘게 만드는 것은 신호 대 잡음비 (Signal-to-noise ratio) 문제를 해결하지 못합니다. 그것은 문제를 숨길 뿐입니다.

올바른 추상화: 의사결정 계층 (Decision layer)

의사결정 계층은 당신의 인박스를 대체하지 않습니다. 그것은 메일, 캘린더, Slack 및 기타 모든 운송 수단 위에 위치하며, 정확히 한 가지만을 드러냅니다. 바로 시스템이 진정으로 당신의 판단을 필요로 하는 항목들입니다.

단순히 "더 나은 인박스"가 아닌 의사결정 계층이 되게 하는 세 가지 속성은 다음과 같습니다:

더하는 것보다 더 많이 뺍니다. 네 번 연속으로 무시한 신호는 다시는 당신에게 도달해서는 안 됩니다. 단순히 뮤트(Mute)하는 것이 아니라, 완전히 사라져야 합니다.
관계를 데이터로 취급합니다. 같은 것을 요청하는 두 사람이 있다고 해서 그것이 동일한 요청은 아닙니다. 한 명은 당신과 함께한 모든 마감 기한을 지켜왔지만, 다른 한 명은 매번 3일씩 늦게 결과물을 보냅니다. 이러한 차이는 대기열(Queue)에 가중치를 부여해야 합니다.
당신의 승인 없이는 행동하기를 거부합니다. 모델은 초안을 작성하고, 제안하고, 계획할 수 있습니다. 하지만 전송하거나, 수정하거나, 확정(Commit)할 수는 없습니다. '행동 전 승인(Approval-before-action)'은 UI의 친절함이 아니라 스키마 수준의 제약 조건(Schema-level constraint)이어야 합니다.

이 중 그 어느 것도 AI 기능이 아닙니다. 이것들은 경계(Boundary) 기능입니다. AI는 하단의 분류(Classification) 작업에는 유용하지만, 진정한 가치는 시스템이 무엇을 표면화하지 않기로 거부하느냐에 달려 있습니다.

다음은 실제 프로덕션 환경에서 각 기능이 어떻게 구현되는지에 대한 모습입니다.

패턴 1 — 폐쇄 루프 억제 학습 (Closed-loop suppression learning)

시스템이 수행하는 가장 유용한 단 한 가지는 바로 '잊는 것'입니다.

사용자가 주의 항목(Attention item)을 해제할 때마다, 우리는 DISMISSED 또는 IGNORED 신호를 가진 FeedbackEvent를 기록합니다. 해당 테이블을 관리하는 것은 비용이 적게 드는 부분입니다. 흥미로운 부분은 이를 매주 읽어들이는 작업(Job)입니다:

export async function runFeedbackAdaptation(userId: string): Promise<number> {
  const since = new Date(Date.now() - LOOK_BACK_DAYS * 24 * 60 * 60 * 1000);

...

그 후, 모든 새로운 주의 항목의 업서트(Upsert) 경로에서 억제 세트(Suppression set)를 읽어옵니다:

export function isSuppressed(
  set: Set<string>,
  source: string,
...

만약 해당 튜플(Tuple)이 억제 세트에 포함되어 있다면, 새로운 주의 항목은 강제로 SILENT 계층으로 분류됩니다. 감사 로그(Audit log)에는 기록되지만, 사용자에게 알림(Page)이 가지는 않습니다.

짚고 넘어갈 만한 몇 가지 설계 선택 사항은 다음과 같습니다:

우선순위 버킷(Priority buckets)이 중요합니다. 첫 번째 버전은 (source, type)에만 키를 두었습니다. 만약

오래된 데이터(stale check)를 확인하는 작업은 실제로 매우 중요한 역할을 합니다. 그 이후로 활동이 없는 사용자에게 부여된 1년 전의 "신뢰할 수 있음 (reliable)" 배지는 시스템의 핵심적인 근거가 되어서는 안 됩니다. 완전한 지수적 감쇠 (exponential decay)를 구현하기 전까지는, 두 번의 반감기 (half-lives) 동안 접촉이 없었던 모든 사용자를 '알 수 없음 (unknown)' 상태로 강등시킵니다.

이 배지는 인박스 카드(inbox card) 위에 작은 칩(chip) 형태로 표시됩니다. 하지만 실제로 유용한 곳은 에이전트 프롬프트 (agent prompt) 내부입니다:

export async function buildTrustHintForPrompt(userId: string): Promise<string> {
  const rows = await prisma.contactTrustScore.findMany({
    where: { userId, totalCount: { gte: MIN_DATA_POINTS } },
...

이제 모델이 "Mina가 업데이트를 요청하고 있습니다"와 "Sarah가 업데이트를 요청하고 있습니다" 중 무엇을 더 시급하게 노출할지 결정할 때, 모델은 정중하게 한 번 넛지(nudge)를 주었을 때 누가 결과물을 가져다줄지, 혹은 마감 기한을 세 번이나 다시 말해줘야 하는 사람이 누구인지에 대한 실제 데이터를 갖게 됩니다. 프롬프트에는 특정 인물에 대한 감정이 전달되지 않습니다. 오직 숫자만이 전달됩니다.

생산성 도구 산업은 지난 10년 동안 어떤 회의 참석자가 실제로 제시간에 나타나는지조차 모르는 캘린더를 만드는 데 시간을 허비해 왔습니다. 이는 참으로 이상한 일입니다.

패턴 3 — 스키마 제약 조건으로서의 실행 전 승인 (Approval-before-action)

세 번째 패턴은 다소 지루할 수 있지만, 대부분의 AI 어시스턴트가 가장 많이 실수하는 부분입니다.

모델은 답장을 초안(draft)할 수 있습니다. 일정 변경을 제안할 수 있습니다. 일련의 행동 시퀀스를 계획할 수 있습니다. 하지만 모델은 그 어떤 것도 전송하거나, 이동하거나, 확정(commit)할 수 없습니다. 이는 우리가 모델을 신뢰하지 못해서가 아닙니다(때로는 신뢰하기도 합니다). 다만 사용자가 시스템이 자신을 대신해 수행하고 있는 작업의 범위(surface area)를 알 필요가 있기 때문입니다. "조용히 전송됨 (silently sent)"은 한 번 발생하면 사용자의 신뢰를 결코 회복할 수 없는 버그의 범주입니다.

이는 스키마 수준에서 강제됩니다. 에이전트가 제안하는 모든 행동은 상태 열거형 (status enum)을 가진 PendingAction 행에 저장됩니다. 해당 열거형의 상태 머신 (state machine)이 곧 계약입니다. 오직 하나의 전이 (approve())만이 실제 부수 효과 (side effect)를 실행할 수 있습니다. 에이전트는 하루 종일 propose()를 할 수 있지만, 사용자의 의도적인 전이 없이는 아무것도 발송되지 않습니다.

가장 위험도가 낮은 작업 클래스 — 집중을 위한 캘린더 시간 확보, 항목 나중에 보기(snoozing), 알림 설정과 같은 내부 전용 작업 — 는 auto로 표시하여 승인 과정을 건너뛸 수 있습니다. 외부 당사자와 접촉하는 모든 것(메일 발송, 타인의 캘린더 수정 등)은 항상 승인 단계를 거칩니다. 이 경계는 의도적으로 보수적입니다. 단 한 명의 사용자라도 자신의 AI 어시스턴트가 VC(벤처 캐피털)에게 말도 없이 사과 메일을 보냈다는 사실을 알게 되는 날, 해당 카테고리의 모든 AI 어시스턴트는 판매하기가 더 어려워질 것입니다.

실제 적용 모습

이 세 가지 패턴의 합은 더 똑똑한 인박스(Inbox)가 아닙니다. 그것은 어느 날이든 대략 6개에서 12개 정도의 항목을 포함하는 작고 조용한 대기열(Queue)입니다. 각 항목은 명시적인 요청이거나, 기한이 다가오는 추적된 약속이거나, 확인을 기다리는 제안된 작업입니다. 모델은 오전 내내 수백 개의 다른 사항들을 읽고 추론하며 시간을 보냈지만, 시스템은 그 모든 것들에 대해 당신이 알 필요가 없다고 결정했습니다.

당신이 항목을 거절(dismiss)할 때마다 시스템은 학습합니다. 연락처가 신뢰할 수 있는 결과물을 지속적으로 전달하면, 그들의 요청 우선순위는 올라갑니다. 모델이 좁은 화이트리스트(safelist) 밖에서 행동하기를 원할 때는 먼저 물어봅니다. 노이즈 플로어(noise floor)를 몇 주간 학습시킨 결과, 당신이 무엇을 무시하는지 실제로 알고 있는 누군가가 정리해 놓은 듯한 느낌을 주는 대기열이 만들어집니다.

이 중 어떤 것도 프런티어 모델(Frontier model)을 필요로 하지 않습니다. 하단의 분류기(Classifier)는 엄격한 비용 가드레일이 적용된 작고 저렴한 LLM(대규모 언어 모델)입니다. 가치의 거의 대부분은 경계(Boundaries)에 있습니다. 즉, 시스템이 무엇을 드러내지 않기로 거부하는지, 당신 없이 무엇을 수행하기를 거부하는지, 그리고 당신과 함께 일하는 사람들에 대해 무엇을 기억하는지에 달려 있습니다.

만약 당신이 이 카테고리에서 무언가를 구축하고 있는데, *사용자에게 더 많은 것을 보여주는 새로운 인터페이스(surface)*를 추가하고 있다면, 잠시 멈추고 무언가를 더하는 것이 아니라 빼는(subtracts) 것을 만들고 싶지는 않은지 자문해 보십시오. 시장은 더 똑똑한 인박스들로 가득 차 있습니다. 아직 제대로 된 의사결정 계층(Decision layer)은 없습니다.

저는 klorn.ai에서 이를 구현하여 출시하고 있습니다. 가입을 요청하려는 것이 아닙니다. 더 많은 사람들이 이를 향해 구축해 나가야 한다고 생각하기 때문에 이 패턴을 공유하는 것입니다. 위에 제시된 폐쇄 루프 억제(Closed-loop suppression) 및 신뢰 점수(Trust-score) 코드는 실제 구현된 코드의 발췌본입니다.

Fastify, Prisma, 그리고 Postgres를 사용하여 TypeScript로 구축되었습니다. 제시된 코드 패턴은 실제 운영 환경(Production)의 발췌본입니다.