다시 돌아오는 순간을 위한 설계: 워크스트림 연속성 디자인 (Workstream Continuity Design) 소개

대부분의 소프트웨어는 정보가 어디에 있는지 기억하는 데는 능숙합니다.

하지만 작업이 어느 단계에 와 있는지를 기억하는 데는 훨씬 서툽니다.

AI 에이전트와의 일상적인 상호작용을 생각해 보십시오:

당신은 작업을 위임합니다.
당신은 다른 두 개의 워크스트림 (workstreams)으로 전환합니다.
90초 후에 당신은 돌아옵니다.
에이전트가 말합니다, "완료되었습니다."

에이전트가 단순히 초안을 생성한 것인가요, 아니면 영구적인 상태 (durable state)를 변경한 것인가요? 어떤 가정이 바뀌었나요? 어떤 증거가 결과를 뒷받침하나요? 에이전트가 권한 범위 내에 머물렀나요? 인간의 결정이 필요한가요? 당신 없이도 작업이 안전하게 계속될 수 있나요?

이 질문들에 답하려면 대개 채팅 메시지, 기록 (records), 알림 (notifications), 로그 (logs), 탭 (tabs), 승인 (approvals), 그리고 생성된 결과물 (artifacts)의 혼합물로부터 컨텍스트 (context)를 재구성해야 합니다.

시스템은 활동 (activity)은 유지했습니다. 하지만 운영 상황 (operating picture)을 보존하는 데는 실패했습니다.

그 간극이 바로 **워크스트림 연속성 디자인 (Workstream Continuity Design)**의 주제입니다.

인터페이스는 모든 전환 시점에서 작업이 어디에 와 있는지를 기억합니다.

전체 공개 연구판은 Zenodo에서 확인할 수 있습니다:

Workstream Continuity Design: Design Bible v0.4

소프트웨어는 지속적인 작업의 환경이 되고 있습니다

전통적인 애플리케이션 디자인은 종종 사용자가 직접적인 실행자라고 가정합니다.

사용자는 페이지를 열고, 객체 (object)를 조작하고, 양식을 제출하고, 응답을 받은 뒤 다음으로 넘어갑니다. 페이지, 기록 (records), 문서, 그리고 세션 (sessions)은 이 모델의 자연스러운 단위입니다.

그러한 구조들은 여전히 유용합니다. 하지만 그 주변의 운영 모델이 변하고 있습니다.

이제 소프트웨어는 작업을 시작한 사람이 다른 곳에 있는 동안에도 작업을 계속할 수 있습니다. 한 명의 사용자가 다음과 같은 것들을 감독할 수 있습니다:

기술적인 질문을 조사 중인 에이전트
코드 변경 사항을 준비 중인 또 다른 에이전트
답변을 기다리는 고객 사례 (customer case)
승인으로 인해 차단된 배포 (deployment)
인간의 검토를 받고 있는 문서
예외 상태 (exception state)에 진입한 백그라운드 워크플로우 (background workflow)

핵심적인 상호작용은 반복적으로 **스위치인 (switch-in)**이 됩니다:

워크스트림 (workstream)에 진입하여, 해당 운영 상태 (operating state)를 획득하고, 다음 결정을 내리거나 위임한 뒤, 다른 곳으로 이동합니다.

재구성 비용 (reconstruction cost)은 매 스위치 (switch)마다 발생합니다. 때로는 며칠 후에, 하지만 종종 단 몇 초 또는 몇 분 후에 발생하기도 합니다.

에이전트 (Agents)는 병렬 실행 (parallel execution), 확률적 계획 (probabilistic plans), 변화하는 가정 (changing assumptions), 도구 사용 (tool use), 그리고 외부 부수 효과 (external side effects)를 통해 이 문제를 증폭시킵니다. 또한 에이전트는 까다로운 책임 조건 (accountability condition)을 만들어냅니다. 즉, 사람이 직접 수행하지 않았거나 전개 과정을 지켜보지 못한 작업에 대해서도 책임을 져야 할 수 있다는 점입니다.

워크스트림 연속성 (workstream continuity)란 무엇인가?

**워크스트림 연속성 (Workstream continuity)**이란, 시스템이 사람이 동시적인 워크스트림들 사이를 이동할 때, 가용 가능한 주의력 (attention) 범위 내에서 최소한으로 충분한 운영 상태 (operating state)를 재구성할 수 있게 해주는 정도를 의미합니다.

해당 운영 상태에는 다음이 포함됩니다:

의도 (Intent)
의미 있는 변화 (Meaningful change)
책임 (Responsibility)
권한 (Authority)
증거 (Evidence)
결과 (Consequence)
가장 안전하고 유용한 다음 행동 (The safest useful next action)

워크스트림 연속성 디자인 (Workstream Continuity Design), 또는 WCD는 이러한 품질을 중심으로 시스템을 설계하는 실무를 말합니다.

지속 가능한 단위는 **워크스트림 (workstream)**입니다. 이는 관련 객체 (objects), 행위자 (actors), 결정 (decisions), 의존성 (dependencies), 산출물 (artifacts), 정책 (policies), 이벤트 (events), 그리고 시간이 흐름에 따른 재개 상태 (resume state)를 연결하는 목표 지향적인 작업 과정입니다.

워크스트림은 여러 페이지, 기록, 대화, 에이전트 실행 (agent runs), 그리고 세션 (sessions)에 걸쳐 있을 수 있습니다. 따라서 마지막 URL로 돌아가는 것만으로는 불충분합니다. 위치 (location)는 목적 (purpose), 변화된 가정 (changed assumptions), 책임 (responsibility), 또는 권한 (permission)을 복구해주지 않기 때문입니다.

다섯 가지 약속

제안된 이 규율은 다섯 가지 약속에 기반합니다.

1. 모든 집중의 전환 (focus transition)은 일급 상호작용 (first-class interaction)이다

제품은 사람이 워크스트림에 진입하거나 다시 진입하는 순간을 의도적으로 설계해야 합니다.

여기에는 30초 후의 빠른 전환, 한 시간 동안 지속된 중단, 다른 기기로의 복귀, 그리고 타인으로부터 물려받은 인수인계 (handoff)가 모두 포함됩니다.

2. 워크스트림은 페이지보다 오래 지속된다

시스템은 내비게이션 (navigation)과 무관하게 목표, 상태, 행위자, 권한, 의미 있는 변화, 증거, 그리고 재개 지점 (resume point)을 보존해야 합니다.

브라우저 세션은 사라질 수 있습니다. 작업의 과정은 이해 가능한 상태로 유지되어야 합니다.

3. 운영 상태(Operational state)와 행위 주체성(Agency)은 분리되어야 합니다

"AI 활성(AI active)" 상태만으로는 작업이 준비되었는지, 차단되었는지, 대기 중인지, 검토 중인지, 아니면 실패했는지를 알려주지 못합니다.

마찬가지로, 단일 담당자(assignee) 필드로는 다음 사항들을 적절히 나타낼 수 없습니다:

누가 여전히 책임을 지고 있는가 (Accountable)
지금 누가 또는 무엇이 행동하고 있는가 (Acting)
다음에 누가 행동해야 하는가
어떤 권한(Authority)이 적용되는가

이것들은 서로 다른 차원이며, 별도로 저장되고 렌더링되어야 합니다.

4. 인터페이스는 의미 있는 변화를 재구성합니다

감사(Audit)를 위해서는 가공되지 않은 연대기(Raw chronology)가 필요하지만, 상황 파악(Orientation)을 위해서는 비효율적입니다.

운영자는 보통 다음과 같은 진술(Statements)이 필요합니다:

동의 만료로 인해 준비된 아웃리치(Outreach)가 무효화됨
법적 승인이 도착하여 실행 차단이 해제됨
고객의 답변으로 인해 요청된 범위(Scope)가 변경됨
에이전트가 산출물(Artifact)을 생성했으나, 증거(Evidence)가 불완전함
책임이 서비스에서 인간 검토자(Human reviewer)로 이관됨

시스템은 기저의 이벤트들을 보존하는 동시에, 검토 가능한 의미론적 차이(Semantic delta)를 제시해야 합니다.

5. 감독(Oversight)은 발생 가능한 일에 영향을 미쳐야 합니다

승인 버튼 하나만으로는 의미 있는 인간의 감독을 확립할 수 없습니다.

연속성 표면(Continuity surface)은 제시(Presentation)를 정책 집행(Policy enforcement), 출처(Provenance), 결과(Consequence), 개입(Intervention), 가역성(Reversibility), 격리(Containment), 그리고 복구(Recovery)와 연결해야 합니다.

인터페이스는 그 경계를 설명해야 하며, 아키텍처는 그 경계를 유지해야 합니다.

공유된 연속성 문법 (A shared continuity grammar)

동등한 상황들이 동등한 의미론(Semantics)을 통해 표현될 때, 빠른 전환이 더 쉬워집니다.

WCD는 다음과 같은 압축된 연속성 문법을 제안합니다:

GOAL · ATTN · STATE · DELTA · ACTORS · AUTH · EVIDENCE · EFFECT · NEXT

각 슬롯은 특정한 운영 질문에 답합니다:

GOAL (목표): 우리가 추구하는 결과는 무엇인가?
ATTN (주의): 왜 이 워크스트림 (workstream)이 지금 주의를 기울여야 하는가?
STATE (상태): 현재 작업은 어떤 상태에 있는가?
DELTA (변화): 무엇이 실질적으로 변했는가?
ACTORS (행위자): 누가 소유하고, 지금 행동하며, 다음에 행동하는가?
AUTH (권한): 어떤 행동이 허용, 거부, 만료 또는 검증 불가능한가?
EVIDENCE (증거): 현재 상태나 권장 사항을 뒷받침하는 것은 무엇인가?
EFFECT (영향): 범위, 외부 효과, 그리고 가역성은 무엇인가?
NEXT (다음): 가장 안전하고 유용한 다음 행동 또는 대기 조건은 무엇인가?

CRM 워크스트림 (workstream)은 다음과 같은 모습일 수 있습니다:

GOAL      Northstar 갱신 자격 확인
ATTN      사람의 검토 필요
STATE     검토 중
...

이는 신호등 방식보다 더 표현력이 풍부하며, 대화 기록을 다시 재생하는 것보다 훨씬 더 압축적입니다.

문법 (grammar)은 또한 여러 단계의 압축 수준을 가질 수 있습니다. 포트폴리오 뷰 (portfolio view)는 주의 (attention), 상태 (state), 변화 (delta), 그리고 다음 행동 (next action)만을 보여줄 수 있습니다. 워크스트림 (workstream)에 진입하면 전체 문법이 확장됩니다. 결정 (decision) 및 감사 (audit) 뷰는 출처, 정책 근거, 대안, 원시 이벤트 (raw events), 승인, 영수증, 그리고 복구 이력을 추가합니다.

기존 인터페이스 패턴도 여전히 중요하다

WCD가 모든 제품을 거대한 커맨드 센터 (command center)로 만들 필요는 없습니다.

대시보드 (dashboards), 큐 (queues), 테이블 (tables), 채팅 (chats), 알림 (notifications), 워크플로 빌더 (workflow builders), 그리고 활동 피드 (activity feeds)는 모두 정당한 문제들을 해결합니다. 병행되는 위임된 작업 (concurrent delegated work) 환경 아래에서 이들의 역할은 더 명확한 경계가 필요합니다.

대시보드 (dashboard)가 의무, 의미 있는 변화, 소유자, 다음 행위자, 결과, 그리고 안전한 행동을 중심으로 구성될 때, 강력한 연속성 표면 (continuity surface)이 될 수 있습니다.

채팅 (chat)은 호출, 명확화, 그리고 설명을 위해 유용하게 남을 수 있습니다. 하지만 지속적인 작업을 위한 유일한 상태 모델 (state model)이 되어서는 안 됩니다.

활동 피드 (activity feed)는 연대기적 순서와 귀속 (attribution)을 보존할 수 있습니다. 하지만 운영자가 수십 개의 낮은 수준의 이벤트 (low-level events)로부터 모든 중요한 변화를 추론하도록 강요해서는 안 됩니다.

알림 (notification)은 주의를 환기할 수 있습니다. 알림의 목적지는 일반적인 레코드를 여는 대신, 관련 운영 컨텍스트 (operating context)를 재구성해야 합니다.

목표는 모든 정보를 담고 있는 하나의 거대한 창(pane)을 만드는 것이 아니라, 하나의 일관된 운영 모델 (operating model)을 구축하는 것입니다.

권장(Recommendation), 신뢰도(confidence), 그리고 권한(permission)은 서로 다릅니다

많은 AI 인터페이스는 다음과 같은 여러 개의 독립적인 질문들을 시각적으로 하나로 뭉뚱그려 표현합니다:

기계가 무엇을 관찰하거나 생성했는가?
무엇을 권장하는가?
증거(evidence)가 얼마나 강력한가?
현재 무엇이 승인(authorized)되었는가?

높은 모델 점수가 권한을 부여하는 것은 아닙니다.

초안(draft)이 완성되었다고 해서 외부 작업(external action)이 발생했다는 의미는 아닙니다.

승인 아티팩트(approval artifact)가 반드시 수정된 페이로드(payload), 다른 수신자, 또는 나중에 수행될 작업을 승인하는 것은 아닙니다.

녹색 상태(green status)가 건강함, 정확함, 승인됨, 허용됨, 그리고 완료됨을 동시에 의미해서는 안 됩니다.

WCD는 권장(recommendation), 증거(evidence), 불확실성(uncertainty), 결과(consequence), 승인(approval), 그리고 권한 부여(authorization)를 별개의 시스템 개념으로 취급합니다.

결과가 중대한 작업(consequential work)의 경우, 권한(authority)은 에이전트(agent)에 의해 주장되거나 브라우저에 의해 추론되는 것이 아니라, 독립적인 정책 서비스(policy service)에 의해 해결되어야 합니다. 실행(execution) 단계에서는 이전의 승인이 존재하더라도 현재의 정책을 다시 확인해야 합니다.

기계 작업에는 책임 있는 표면(accountable surface)이 필요합니다

연속성 문법(continuity grammar)은 신뢰할 수 있는 기반 기록(underlying records)에 의존합니다.

그러한 이유로, 본문(the Bible)은 운영자가 확인할 수 있는 기계의 주장(claims), 제안(proposals), 상태 변경(state changes), 예외(exceptions), 그리고 작업(actions)을 위해 **WCD 책임 표현 프로필 (WCD Accountable Expression Profile)**을 제안합니다.

핵심 아이디어는 결과가 중대한 기계 표현(machine expressions)이 다음과 같아야 한다는 것입니다:

타입화됨 (Typed)
귀속 가능함 (Attributable)
증거와 연결됨 (Connected to evidence)
내구성이 있는 워크스트림에 결합됨 (Bound to a durable workstream)
결과가 제한됨 (Bounded in consequence)
현재 권한에 따라 해결됨 (Resolved against current authority)
적절한 인간 개입 경로와 쌍을 이룸 (Paired with an appropriate human intervention path)

에이전트는 콘텐츠를 생성하고 분류를 제안할 수 있습니다. 하지만 자신의 증거가 충분하다거나, 자신의 작업이 되돌릴 수 있다거나, 자신의 권한이 유효하다는 것을 일방적으로 인증해서는 안 됩니다.

신원(Identity), 증거(evidence), 정책(policy), 실행(execution), 그리고 워크스트림(workstream) 서비스는 각각 자신이 권위 있게 검증할 수 있는 사실들을 제공합니다.

연속성 측정하기

연속성 기능은 사용자가 빠르게 클릭하거나 좋다고 말했다는 이유만으로 성공적이라고 간주되어서는 안 됩니다.

이 프레임워크는 다음과 같은 측정 지표를 제안합니다:

방향 설정 시간 (Time to Orientation): 주의(attention)가 필요한지 식별하고 적절한 워크스트림(workstream)을 선택하는 데 얼마나 걸리는가?
의사결정 준비 시간 (Time to Decision Readiness): 의사결정, 실질적 차이(material delta), 행위자(actors), 권한(authority), 증거(evidence), 결과(consequence), 그리고 안전한 옵션들을 정확하게 이해하는 데 얼마나 걸리는가?
오판 준비율 (False-ready rate): 어떤 작업이 준비되지 않았거나 허용되지 않았음에도 불구하고, 누군가가 준비되었거나 허용되었다고 믿는 빈도는 어느 정도인가?
워크스트림 간 오염 (Cross-workstream contamination): 사실, 의도, 권한 또는 증거가 다른 활성 워크스트림으로부터 잘못 가져와지는 빈도는 어느 정도인가?
다음 행위자 정확도 (Next-actor accuracy): 사용자가 다음에 누가 행동해야 하는지를 정확하게 식별할 수 있는가?
개입 지연 시간 (Intervention latency): 사람이 일탈하는 머신 프로세스(machine process)를 얼마나 빨리 감지하고 억제할 수 있는가?

이해력과 의사결정의 품질이 정확하게 유지될 때에만 속도는 개선 사항으로서 의미를 갖습니다.

이 카테고리는 의도적으로 반증 가능하게(falsifiable) 설계되었습니다. 만약 명시적인 워크스트림, 차이(delta), 행위자(actor), 증거(evidence), 결과(consequence), 그리고 정책(policy) 모델 없이도 기존의 대시보드, 큐(queues), 히스토리, 알림(notifications)이 동일하게 잘 작동한다면, 제안된 이 카테고리는 기존의 기업용 UX 관행으로 회귀해야 합니다.

제안의 주장 내용

기저에 깔린 인간 요인(human-factors) 연구는 이미 확립되어 있습니다: 작업 전환(task switching), 중단 회복(interruption recovery), 목표 재구성(goal reconstruction), 상황 인식(situation awareness), 감독 제어(supervisory control), 적절한 의존(appropriate reliance), 분산 인지(distributed cognition), 감사 가능성(auditability), 그리고 우아한 회복(graceful recovery).

워크스트림 연속성 디자인(Workstream Continuity Design)은 이러한 영역들을 특정 운영 단위와 상호작용 리듬을 중심으로 독창적으로 합성한 것입니다: 즉, 사람, 서비스, 그리고 부분적으로 자율적인 소프트웨어 행위자(software actors)를 가로질러 지속되는 내구성 있는 병렬 작업(durable concurrent work)입니다.

용어(terminology), 연속성 문법(continuity grammar), 패턴 라이브러리(pattern library), 지표(metrics), 성숙도 모델(maturity model), 그리고 책임 표현 프로필(accountable-expression profile)은 모두 설계 및 표준 제안 사항입니다. 이들은 프로토타입(prototypes), 비교 연구(comparative studies), 접근성 평가(accessibility evaluation), 현장 배포(field deployment), 그리고 수정(revision)을 필요로 합니다.

현재 문서는 공개된 비동료 검토(non-peer-reviewed) 연구판이며, 이는 해당 카테고리가 이미 증명되었다는 선언이 아닙니다.

전체 디자인 바이블 (The full Design Bible)

완전한 Workstream Continuity Design Bible v0.4에는 다음 내용이 포함되어 있습니다:

카테고리 정의 및 경계
13가지 핵심 디자인 원칙
표준 정보 아키텍처 (canonical information architecture)
워크스트림 및 에이전시 모델 (workstream and agency model)
연속성 문법 (continuity grammar) 및 운영 차이 (operational diff)
22가지 상호작용 패턴 (interaction patterns)
인간 감독 및 안전 아키텍처 (human-oversight and safety architecture)
평가 지표 및 연구 프로토콜 (evaluation metrics and study protocols)
4단계 성숙도 모델 (four-level maturity model)
AI-first CRM 사례 연구
디자인 리뷰 체크리스트
공개 연구 및 표준 질문들

Zenodo에서 전체 공개 연구판 읽기

이 문서는 CC BY 4.0 라이선스 하에 제공됩니다.

제가 테스트하는 데 가장 관심이 있는 질문들은 다음과 같습니다: