신뢰와 안전

목적

Dot은 사용자가 시스템의 현재 상태, 데이터 범위, 행동 영향, AI 결과의 확정 여부를 이해한 상태에서 결정하게 한다. 신뢰는 친근한 문구나 시각적 완성도만으로 만들 수 없다. 예측 가능성, 상태의 정직함, 복구 가능성, 사용자의 통제권이 함께 있어야 한다.

신뢰의 기준

기술 구현을 모두 설명할 필요는 없지만 사용자의 결정을 바꿀 정보는 숨기지 않는다.

데이터 상태

• 지표에는 기간, 대상 범위, 마지막 갱신 시각을 제공한다.
• cached 또는 지연된 데이터가 최신처럼 보이지 않게 한다.
• 일부 데이터만 불러왔으면 전체를 대표하는 표현을 쓰지 않는다.
• 값이 0인지 아직 계산되지 않았는지 구분한다.
• 외부 변경과 충돌하면 자동 덮어쓰기보다 비교와 선택을 제공한다.
• 운영 환경, preview, sandbox처럼 데이터 신뢰도나 쓰기 가능 여부가 다르면 EnvironmentBanner로 일관되게 알린다.

권한과 민감한 정보

• 사용자가 볼 수 없는 기능을 무조건 숨기는 것과 비활성으로 설명하는 것 중 학습 가치와 보안을 기준으로 선택한다.
• 권한 부족 오류는 필요한 역할과 요청 경로를 사용자의 언어로 설명한다.
• 개인 정보와 학습 기록은 현재 작업에 필요한 최소 범위만 노출한다.
• 복사, 내보내기, 공유 행동은 포함되는 정보 범위와 대상을 실행 전에 알려준다.
• 민감한 값은 URL, toast, 브라우저 title처럼 예상치 못한 위치에 노출하지 않는다.
• 지원용 식별자는 본문보다 낮은 계층으로 제공하고 쉽게 복사할 수 있게 할 수 있다.

위험한 행동

• 삭제, 발행, 권한 변경, 외부 발송은 대상과 범위를 구체적으로 표시한다.
• 되돌릴 수 있는지와 복구 경로를 실행 전에 말한다.
• 여러 대상에 적용할 때 선택 수와 전체 범위를 분리한다.
• 파괴 행동의 trigger를 실수로 누르기 쉬운 주 행동 가까이에 두지 않는다.
• 위험을 색만으로 나타내지 않고 명시적인 제목과 설명을 제공한다.
• 사용자가 결과를 이해하지 못한 채 문자열을 입력하게 하는 확인은 최후 수단이다. 먼저 정보 구조와 대상 확인을 개선한다.

AI 결과의 신뢰

• AI 제안과 사람이 확정한 결과를 같은 상태로 표시하지 않는다.
• 입력 범위, 적용 기준, 누락 가능성처럼 판단에 필요한 조건을 제공한다.
• 결과가 생성 중, 생성 완료, 검토 필요, 수정됨, 확정됨 중 어디에 있는지 보여준다.
• 확신을 수치로 제공하려면 그 수치의 의미와 사용자가 취할 행동이 분명해야 한다. 의미 없는 정밀도를 만들지 않는다.
• AI가 학습자의 성취, 평가, 피드백에 영향을 주면 사람이 검토하고 수정할 경로를 제공한다.
• 생성 실패나 일부 누락을 완성된 결과처럼 보여주지 않는다.
• 사용자의 수정이 저장됐는지, 다시 생성하면 무엇을 덮어쓰는지 알려준다.

설명과 확신의 정도

문구는 시스템이 아는 범위만 말한다.

• 확인되지 않은 상태에 완료됐어요를 쓰지 않는다.
• 예측에는 기준 시점과 변할 수 있는 조건을 함께 제공한다.
• 원인을 모르면 추측해 단정하지 않고 확인 가능한 복구 행동을 제안한다.
• 성공 범위를 검증하지 못하면 요청을 보냈어요처럼 시스템이 확인한 단계까지만 말한다.
• 사용자가 잘못했다는 표현보다 완료하지 못한 작업과 복구 방법을 설명한다.

정서적 안전

• 학습 결과와 오류를 사용자의 능력이나 성실성으로 평가하는 문장으로 쓰지 않는다.
• 실패·미완료 상태는 사실과 다음 행동 중심으로 설명한다.
• 경고를 반복 노출해 불안을 키우지 않고 실제 위험 수준에 맞춘다.
• 캐릭터는 정서적 연결과 안내가 필요한 순간에만 사용하며 오류의 심각성을 가볍게 만들지 않는다.
• 사람에게 영향을 주는 운영 결정은 대상과 근거를 확인할 충분한 시간을 제공한다.

감사 가능성과 이력

• 중요한 운영 변경에는 수행자, 시점, 대상, 결과를 확인할 경로를 제공한다.
• 이력은 원시 로그를 그대로 노출하기보다 사용자가 이해하는 행동 문장으로 번역한다.
• 자동 처리와 사람의 수정을 구분한다.
• 최신 상태와 과거 상태를 혼동하지 않게 시각 계층을 나눈다.
• 이력이 필요한 작업에서 toast만 남기고 영구적인 결과를 없애지 않는다.

Flexible, Link, Glow의 적용

• Flexible: 권한, 데이터 신뢰도, 영향 범위에 따라 설명과 확인 수준을 조정하되 핵심 안전 조건은 생략하지 않는다.
• Link: 입력, 자동 처리, 사람의 검토, 최종 적용, 변경 이력을 연결해 결과의 맥락을 보존한다.
• Glow: 불확실한 순간의 다음 안전한 방향을 안내하는 데만 사용한다. 신뢰를 시각 효과로 대신하지 않는다.

예외와 피해야 할 사용

• 정상처럼 보이게 하려고 stale, partial, unknown 상태를 숨기지 않는다.
• 불완전한 AI 결과를 확정 상태와 같은 표현으로 보여주지 않는다.
• 권한 부족을 일반 네트워크 오류로 처리하지 않는다.
• 파괴 행동을 더보기 메뉴에 넣었다는 이유만으로 확인을 생략하지 않는다.
• 개인 정보가 들어간 원문을 오류 메시지나 진단 정보에 반복 노출하지 않는다.
• 경고 문구를 모두 destructive 색으로 만들지 않는다.
• 사용자를 안심시키기 위해 검증하지 않은 약속을 하지 않는다.
• 캐릭터나 친근한 말투로 데이터 손실과 외부 발송의 영향을 축소하지 않는다.

상태와 접근성

• warning, destructive, success 상태는 텍스트 레이블과 설명을 가진다.
• 권한과 보안 메시지는 screen reader에서 관련 행동보다 먼저 이해할 수 있어야 한다.
• 민감한 값의 표시·숨김 trigger에는 상태가 포함된 accessible name을 제공한다.
• 확인 dialog의 초기 focus는 가장 안전한 선택을 기준으로 정하고, 위험 행동에 자동 focus하지 않는다.
• 시간이 지나면 사라지는 피드백에 중요한 보안·권한 정보를 두지 않는다.
• 자동 갱신으로 상태가 바뀌면 사용자의 focus를 빼앗지 않고 필요한 변경만 알린다.
• 데이터 표에서 민감한 열을 시각적으로 숨겼다면 보조 기술에서도 같은 정책을 적용한다.

검토 질문

• 값의 범위와 마지막 갱신 시점을 사용자가 알 수 있는가?
• 0, unknown, not loaded, partial을 구분하는가?
• 행동이 누구와 어떤 데이터에 영향을 주는지 실행 전에 보이는가?
• AI 제안과 사람의 확정 결과가 명확히 구분되는가?
• 시스템이 실제로 확인한 수준보다 강하게 성공을 말하지 않는가?
• 사용자의 입력과 자동 처리, 변경 이력이 연결되는가?
• 민감한 정보가 URL, toast, log 형태로 새지 않는가?
• 위험 행동의 확인 수준이 영향과 복구 가능성에 비례하는가?
• 접근성 사용자가 동일한 경고, 상태, 안전 행동을 이해할 수 있는가?
• 브랜드 표현이 신뢰의 근거를 보완하는가, 가리고 있는가?