음성 에이전트(Voice agent)는 세련되게 들리고 즉각적으로 응답할 수 있지만, "저에게 전화하지 마세요"라는 단 한 문장으로 신뢰 사고를 일으킬 수 있습니다.

만약 그 요청이 SMS 경로만 업데이트한다면, 당신의 에이전트는 내일도 계속 전화를 걸 수도 있습니다. 만약 그것이 통화 기록(Call transcript)만 업데이트한다면, 당신의 후속 워크플로우(Follow-up workflow)는 계속 문자를 보낼 수도 있습니다. AI 콜러(AI callers), 인박스 에이전트(Inbox agents), 스케줄링 봇(Scheduling bots) 또는 다단계 아웃리치 워크플로우(Multi-step outreach workflows)를 출시하는 개발자들에게 동의(Consent)는 더 이상 정적인 체크박스가 아닙니다. 그것은 런타임 상태(Runtime state)입니다.

이 지점에서 **AI 동의 원장 (AI consent ledger)**이 도움이 됩니다. 이는 모든 에이전트 작업에 간단한 규칙을 부여합니다: 사람에게 연락하거나, 정보를 보강(Enriching)하거나, 기록하거나, 에스컬레이션(Escalating)하기 전에, 하나의 내구성이 있는 장소에서 최신 동의 상태를 확인하십시오.

이 가이드는 당신의 제품을 컴플라이언스(Compliance) 미로로 만들지 않으면서 해당 원장을 설계하는 방법을 보여줍니다.

이것은 기술적 아키텍처 가이드이며, 법적 조언이 아닙니다. 만약 당신의 워크플로우가 규제 대상인 아웃리치, 의료, 금융, 고용 또는 민감한 개인 데이터와 관련이 있다면, 자격을 갖춘 법률 검토자를 참여시키십시오.

AI 에이전트가 동의를 더 어렵게 만드는 이유

AI 에이전트는 그 경계를 모호하게 만듭니다.

프로덕션 에이전트(Production agent)는 다음과 같은 일을 할 수 있습니다:

• 인바운드 전화 응대
• 음성 메시지 요약
• 후속 링크 문자 전송
• 다른 통화 일정 예약
• CRM 레코드 정보 보강 (Enrich)
• 다음 주에 캠페인 단계 트리거
• 케이스를 사람에게 전달
• 도구 호출(Tool call) 실패 후 재시도
• 음성에서 SMS 또는 이메일로 전환

각 단계는 그 자체로는 유효할 수 있습니다. 위험은 한 채널에서 동의가 변경되었을 때 나머지 워크플로우가 이를 인지하지 못할 때 발생합니다.

일반적인 실패 형태는 간단합니다:

1. 사용자가 눈앞에 있는 채널에서 권한을 철회합니다.
2. 에이전트는 해당 메시지를 대화 텍스트로 기록합니다.
3. 철회 상태를 확인하지 않았기 때문에 다른 워크플로우가 계속 실행됩니다.

이것은 LLM(Large Language Model)의 문제가 아닙니다. 상태 관리(State-management)의 문제입니다.

AI 동의 원장이란 무엇인가?

**AI 동의 원장 (AI consent ledger)**은 권한 이벤트의 추가 전용(Append-only) 기록과 다음 질문에 답하는 빠른 읽기 모델(Fast read model)의 결합입니다:

이 특정 에이전트가 지금 이 사람에 대해 이 특정 작업을 수행하도록 허용되었는가?

이 원장(Ledger)은 채널(Channel), 신원(Identity), 에이전트(Agent), 워크플로(Workflow), 도구(Tool) 및 시간에 걸쳐 동의(Consent)와 철회(Revocation)를 추적해야 합니다.

유용한 원장은 다음 사항을 저장합니다:

• 동의가 누구에게 속해 있는가
• 어떤 채널에 적용되는가
• 어떤 목적을 포괄하는가
• 언제 부여되었거나 철회되었는가
• 어떻게 캡처되었는가
• 어떤 워크플로 또는 에이전트가 이에 따라 행동했는가
• 어떤 증거가 해당 결정을 뒷받침하는가
• 철회가 하나의 채널만 중단해야 하는지, 아니면 관련된 모든 연락(Outreach)을 중단해야 하는지 여부

AI 워크플로(AI workflows)에서 가장 중요한 부분은 로그(Log)가 아닙니다. 행동을 취하기 전의 정책 확인(Policy check)입니다.

대부분의 팀이 놓치는 동의 접점

에이전트가 권한 상태를 생성, 사용 또는 변경할 수 있는 모든 지점을 매핑하는 것부터 시작하십시오.

1. 음성 철회 (Voice revocation)

사용자는 다음과 같이 말할 수 있습니다:

• “저에게 전화하지 마세요.”
• “명단에서 빼 주세요.”
• “이 번호로 다시는 연락하지 마세요.”
• “이메일로만 연락해 주세요.”
• “대신 문자로 보내주세요.”
• “저는 이것을 요청한 적이 없습니다.”

이러한 문구들을 전사 데이터(Transcripts) 내부에 묻어두지 마십시오. 이를 동의 이벤트 후보(Candidate consent events)로 추출해야 합니다.

음성 철회는 까다로운데, 에이전트가 긴 대화 도중에 이를 들을 수 있기 때문입니다. 단순히 최종 요약(Final summary)만을 보는 것이 아니라, 권한 변경을 감시하는 별도의 분류기(Classifier) 또는 결정론적 문구 계층(Deterministic phrase layer)이 필요합니다.

2. SMS 키워드 및 자연어 (Natural language)

자연어(Natural language)도 포착해야 합니다:

• “제발 문자 좀 그만 보내세요”
• “잘못된 번호입니다”
• “대신 제 사무실로 전화하세요”
• “관심 없으니 삭제해 주세요”

정확한 키워드는 결정론적(Deterministic)으로 처리할 수 있습니다. 자연어는 분류(Classified)한 후, 불확실할 경우 확인 절차나 사람의 검토(Human review)로 라우팅(Routed)할 수 있습니다.

3. 이메일 및 알림 설정 (Email and notification preferences)

에이전트는 원래 음성 기반이었던 워크플로에서 이메일을 초안 작성하거나 보낼 수 있습니다. 만약 이메일에 별도의 동의 목적이 있다면, 원장은 그 사실을 알고 있어야 합니다.

에이전트가 다른 도구를 사용할 수 있다고 해서 동의 범위가 조용히 확장되어서는 안 됩니다.

4. CRM 가져오기 및 오래된 목록 (CRM imports and stale lists)

많은 AI 워크플로는 가져온 연락처(Imported contacts)로 시작됩니다. 해당 가져오기 데이터에는 오래된 동의 플래그(Consent flags), 불완전한 채널 이력, 또는 증거가 전혀 없는 데이터가 포함되어 있을 수 있습니다.

가져온 권한은 검증될 때까지 낮은 신뢰도(lower-trust)로 취급하십시오. 에이전트가 더 안전한 모드를 선택할 수 있도록 출처(source)와 타임스탬프(timestamp)를 저장하십시오.

5. 인간의 오버라이드 (Human overrides)

인간에게는 오버라이드(override) 경로가 필요하지만, 오버라이드는 보이지 않는 관리자 편집이 아니라 이유가 포함된 명시적인 이벤트여야 합니다.

좋은 오버라이드 기록은 다음 질문에 답할 수 있어야 합니다:

• 누가 상태를 변경했는가
• 왜 변경했는가
• 어떤 증거를 검토했는가
• 변경 사항이 일시적인가 아니면 영구적인가

실용적인 동의 데이터 모델 (A practical consent data model)

쓰기 모델(write model)은 추가 전용(append-only)으로 유지하십시오. 이를 통해 별도의 현재 상태 뷰(current-state view)를 구축하십시오.

다음은 간결한 TypeScript 스타일의 모델입니다:

type ConsentChannel = "voice" | "sms" | "email" | "push" | "in_app";
type ConsentPurpose =
  | "support_followup"
...

몇 가지 세부 사항이 중요합니다:

• scope는 정책에서 명시하지 않는 한 "전화 중단"이 실수로 "모든 것 중단"으로 변하는 것을 방지합니다.
• purpose는 예약 알림에 대한 동의가 프로모션(promotions)에 대한 동의로 변하는 것을 방지합니다.
• evidenceRef를 통해 시스템이 왜 그런 결정을 내렸는지 설명할 수 있습니다.
• confidence를 통해 불확실한 AI 추출 이벤트가 맹목적으로 행동하는 대신 일시 중지되도록 할 수 있습니다.

모든 에이전트 작업에 필요한 런타임 체크 (The runtime check every agent action needs)

상태를 변경하거나 연락을 취하는 모든 작업 전에, 원장(ledger)에 결정을 요청하십시오.

type ConsentDecision = {
  allowed: boolean;
  reason: string;
...

에이전트는 결코 최종 권한을 가져서는 안 됩니다. 에이전트는 작업을 요청할 수만 있습니다. 해당 작업이 허용되는지는 백엔드(backend)에서 결정합니다.

음성 전사(voice transcripts)로부터 철회(revocation)를 처리하는 방법

음성 에이전트에는 전사(transcript)를 둘러싼 작은 파이프라인이 필요합니다.

1단계: 전사 구간(transcript spans) 캡처

전체 전사 블롭(blob)만 저장하지 마십시오. 타임코드가 포함된 구간(spans)을 저장하십시오.

{
  "span_id": "span_928",
  "speaker": "user",
...

2단계: 동의 의도(consent intent) 추출

명확한 문구에는 결정론적 규칙(deterministic rules)을 사용하고, 완곡한 표현에는 LLM 분류기(classifier)를 사용하십시오.

{
  "intent": "revocation",
  "channels": ["voice", "sms"],
...

3단계: 신뢰도 정책(confidence policy) 적용

정책 예시:

• confidence >= 0.90: 즉시 철회 이벤트(revocation event) 기록
• confidence 0.65 - 0.89: 워크플로(workflow)를 일시 중단하고 사람의 검토(human review) 요청
• confidence < 0.65: 신호(signal)로 저장하되, 상태를 자동으로 변경하지 않음

철회(revocation)의 경우, 원치 않는 연락을 계속하는 것보다 오탐(false positive)을 허용하는 방향을 선호하십시오. 새로운 동의 부여(consent grants)에 대해서는 더 엄격하게 적용하십시오.

4단계: 활성 워크플로(active workflows) 중단

원장(ledger) 기록은 관련 워크플로를 취소하거나 일시 중단하는 이벤트를 방출(emit)해야 합니다.

await eventBus.publish("consent.revoked", {
  tenantId,
  subjectId,
...

그 후 워커(workers)는 향후 단계를 중단해야 합니다:

on("consent.revoked", async (event) => {
  await workflowStore.pauseRuns({
    tenantId: event.tenantId,
...

만약 철회가 예약된 작업(scheduled jobs)을 취소하지 못한다면, 원장은 제어 시스템(control system)이 아닌 일기장(diary)에 불과하게 됩니다.

채널 인지 규칙(channel-aware rules) 설계

모든 권한 이벤트가 동일한 의미를 갖는 것은 아닙니다.

정책 매트릭스(policy matrix)를 사용하십시오:

이 매트릭스는 프롬프트(prompt)가 아닌 코드나 정책 설정(policy configuration)에 존재해야 합니다.

아키텍처 내 원장의 위치

간단한 프로덕션 흐름은 다음과 같습니다:

1. 에이전트(Agent)가 동작을 제안합니다.
2. 런타임 정책(Runtime policy)이 도구 권한(tool permission)을 확인합니다.
3. 동의 원장(Consent ledger)이 사용자 권한을 확인합니다.
4. 속도 제한기(Rate limiter)가 예산과 빈도를 확인합니다.
5. 도구 실행기(Tool executor)가 동작을 수행합니다.
6. 감사 로그(Audit log)가 결정 사항과 증거를 기록합니다.

이 순서는 매우 중요합니다. 도구를 먼저 호출한 다음 나중에 동의를 확인하지 마십시오.

음성 에이전트(voice agents)의 경우, 양방향 모두에 원장을 배치하십시오:

• 아웃바운드(outbound) 전화 또는 문자 발송 전
• 실시간 통화 중 철회 의사가 나타날 때
• 통화 종료 후 요약(summaries)이 처리될 때
• 캠페인 재시도(campaign retries) 전
• 사람에게 전달(human handoff)되는 후속 조치 전

관측 가능성(Observability): 무엇을 로그로 남길 것인가

모든 동의 결정은 작은 영수증(receipt)을 생성해야 합니다.

{
  "decision_id": "cd_456",
  "workflow_run_id": "run_789",
...

이는 디버깅 (debugging)과 사용자 신뢰에 도움이 됩니다. 누군가가 에이전트가 왜 자신에게 연락했는지 또는 연락하지 않았는지 물을 때, 구체적인 답변을 제공할 수 있습니다.

다음 지표들을 추적하세요:

• 채널별로 감지된 철회 (revocations)
• 검토가 필요한 불확실한 동의 이벤트
• 차단된 에이전트 작업 (agent actions)
• 철회 후 일시 중지된 워크플로 (workflows)
• 철회 시점부터 워크플로 취소까지의 시간
• 동의 정보는 가져왔으나 증거가 없는 연락
• 오탐 (false-positive) 및 미탐 (false-negative) 검토 결과

핵심 지표는 "메시지를 얼마나 많이 보냈는가"가 아닙니다. "얼마나 많은 작업이 올바르게 허용, 차단 또는 일시 중지되었는가"입니다.

흔한 실수들

실수 1: 프롬프트를 정책으로 취급하는 것

시스템 프롬프트 (system prompt)는 에이전트에게 동의를 준수하라고 지시할 수 있습니다. 하지만 재시도 (retries), 워커 (workers), 큐 (queues) 및 통합 (integrations) 전반에 걸쳐 동의를 강제할 수는 없습니다.

정책은 백엔드 체크 (backend checks)에 있어야 합니다.

실수 2: 현재 상태만 저장하는 것

단일 can_contact=false 플래그는 해당 결정이 왜 내려졌는지에 대한 이유를 숨깁니다. 감사 (audits), 디버깅 (debugging) 및 안전한 복구를 위해서는 이벤트 히스토리 (event history)가 필요합니다.

실수 3: 목적을 무시하는 것

로그인 코드를 보낼 수 있는 권한이 프로모션 시퀀스 (promotional sequence)를 보낼 수 있는 권한은 아닙니다. 동의를 목적과 결합하세요.

실수 4: 예약된 작업이 체크를 우회하게 두는 것

큐에 쌓인 작업 (queued jobs)은 예약될 때뿐만 아니라 실행 시점 (execution time)에도 동의 여부를 확인해야 합니다. 예약과 발송 사이에 동의 상태가 변경될 수 있습니다.

실수 5: 채널 전반으로 동의를 확장하는 것

사용자가 알림을 위해 전화번호를 제공했다고 해서, 에이전트가 영원히 전화를 걸고, 문자를 보내고, 정보를 보강하고, 녹음하고, 이메일을 보낼 수 있다고 가정하지 마세요. 확장은 명시적이어야 합니다.

작은 구현 체크리스트

다음 내용을 1차 검토용으로 사용하세요:

• 사람에게 연락, 기록, 보강(enrich) 또는 업데이트를 수행하는 모든 에이전트 동작을 나열합니다.
• 각 동작에 대한 목적을 정의합니다.
• 추가만 가능한(append-only) 동의 이벤트를 생성합니다.
• 현재 상태를 나타내는 읽기 모델(read model)을 구축합니다.
• 도구 실행(tool execution) 전 백엔드 동의 확인 단계를 추가합니다.
• 음성 및 SMS로부터 권한 철회(revocation)를 추출합니다.
• 권한 철회 후 활성화된 워크플로우를 일시 중지합니다.
• 단순 플래그(flag)뿐만 아니라 증거 참조(evidence references)를 저장합니다.
• AI가 추출한 이벤트가 불확실할 경우 인간의 검토(human review) 단계를 추가합니다.
• 동의 결정 영수증(consent decision receipts)을 로그로 남깁니다.
• 권한 철회 후 대기열에 있는 작업(queued jobs)을 테스트합니다.
• 가져온 CRM 동의 사항을 별도로 검토합니다.

원장(Ledger) 테스트하기

실제 실패 사례(failure modes)로부터 테스트 케이스를 생성하세요.

it("음성으로 모든 채널 철회를 말한 후 예약된 SMS를 차단함", async () => {
  await ledger.append({
    subjectId: "c1",
...

또한 다음 사항을 테스트하세요:

• 정책이 모든 연락을 금지한다고 명시된 경우, SMS STOP이 향후 음성 연락을 차단하는지 여부.
• "대신 이메일로 보내주세요"라고 했을 때, 이메일 권한이 존재하지 않으면 이메일을 보내지 않는지 여부.
• 가져온 CRM 동의 사항이 만료되거나 검증을 필요로 하는지 여부.
• 신뢰도가 낮은 권한 철회 시 워크플로우가 일시 중지되는지 여부.
• 인간의 재량권 행사(human override)가 이벤트와 영수증을 생성하는지 여부.
• 재시도하는 워커(retrying worker)가 실행 전 동의 여부를 다시 확인하는지 여부.

이것이 더 넓은 AI 아키텍처와 연결되는 방식

동의 원장은 다음과 같은 다른 런타임 제어(runtime controls)와 함께 작동할 때 가장 효과적입니다:

• 런타임 정책 (Runtime policy): 도구 호출(tool call)이 안전한지 결정합니다.
• 속도 제한 (Rate limiting): 빈도와 비용을 제어합니다.
• 테넌트 격리 (Tenant isolation): 고객 간의 상태 유출을 방지합니다.
• 출력 출처 (Output provenance): 생성된 결정에 대한 증거를 저장합니다.
• 승인 게이트 (Approval gates): 위험한 동작을 검토를 위해 일시 중지합니다.

동의는 더 큰 시스템 내의 하나의 경계(boundary)입니다. 하지만 이는 사용자가 즉각적으로 이해할 수 있는 경계입니다. 사용자가 중단을 요청하면, 시스템은 중단해야 합니다.

FAQ

AI 동의 원장이란 무엇인가요?

AI 동의 원장은 동의 및 권한 철회 이벤트에 대한 추가 전용(append-only) 기록이며, AI 에이전트가 사람에게 연락, 기록, 보강 또는 행동할 수 있는지 여부를 결정하는 런타임 읽기 모델(runtime read model)을 포함합니다.

이것은 음성 에이전트(voice agents)만을 위한 것인가요?

아니요. 음성 에이전트는 이 문제를 명확하게 드러낼 뿐이지만, 동일한 패턴이 SMS 에이전트, 이메일 에이전트, 지원 코파일럿(support copilots), CRM 자동화, 알림 시스템, 그리고 개인 데이터를 사용하는 AI 워크플로(AI workflows)에도 적용됩니다.

LLM이 동의 여부를 결정할 수 있나요?

LLM은 “제발 나를 좀 내버려 두세요”와 같은 모호한 언어를 분류하는 데 도움을 줄 수 있지만, 최종적인 집행 계층(enforcement layer)이 되어서는 안 됩니다. 후보 이벤트(candidate events)를 작성하고, 신뢰도 규칙(confidence rules)을 적용한 뒤, 백엔드 정책(backend policy)이 결정하도록 하세요.

한 채널에서의 철회(revocation)가 모든 채널을 중단시켜야 하나요?

사용자의 발언, 제품 정책, 그리고 법적 맥락에 따라 다릅니다. “문자 그만 보내세요”는 특정 채널에 국한될 수 있습니다. 반면 “나에게 연락하지 마세요”는 일반적으로 모든 연락(outreach)을 중단해야 합니다. 이를 정책 매트릭스(policy matrix)에 인코딩하세요.

대기 중인 작업(queued jobs)이 동의 여부를 다시 확인해야 하나요?

네. 어제 예약된 작업이 오늘 무효가 될 수 있습니다. 대기 중인 모든 연락 작업은 실행 직전에 최신 동의 상태를 즉시 확인해야 합니다.

무엇을 가장 먼저 구축해야 하나요?