UX 아키텍처·디자인시스템·접근성

1. 버튼은 같은데 ‘완료’의 뜻이 다르면

도서관 강좌 신청의 모바일 화면은 제출 전 검토에 ‘완료’라고 표시하고, 큰 화면은 신청번호를 받은 뒤에만 ‘완료’라고 표시한다고 하자. 색과 모서리를 똑같이 맞춰도 사용자는 채널을 바꾸는 순간 다른 규칙을 배우게 된다.

앞 절 UR-LIB의 문제는 검토 화면과 실제 신청 확정을 혼동하는 것이었다. 이번에는 이미 정한 정보·과업·상태를 여러 화면과 공통 요소로 어떻게 유지할지 다룬다. 가상 설계를 설명하는 절이며 실제 도서관을 조사하거나 디자인시스템·접근성 시험을 운영 서비스에 적용한 결과가 아니다.

앞 절에서 가져올 판단

사용자 목표·성공조건 사용자 조사·문제정의·UX 계획에서는 사용자 목표·맥락·관찰과 미확인을 조사·설계·검증 계획에 연결했다. 같은 색을 쓰는 것보다 어떤 과업을 어떤 조건에서 완료해야 하는지가 먼저였다.

앞 절에서 가져올 판단

정보·상태 계약 콘셉트·정보구조·상호작용은 C01부터 C05까지의 정보와 EDIT·REVIEW·SUBMITTING·CONFIRMED·REJECTED·UNKNOWN의 UR-S1 상태를 구별했다. 검토·버튼 클릭·시간초과는 실제 확정 응답과 같은 사건이 아니었다.

정확한 정의와 이 절의 경계

UX 아키텍처는 사용자 목표를 여러 화면·채널에서 일관되게 실현하기 위해 정보·행동·상태·공통 요소와 접근성 규칙의 관계를 조직한 경험 구조다.

소프트웨어 내부 배치 구조와 구별되는 사용자 경험의 구조다. UX 계획과 콘셉트·정보구조·과업 상태는 앞 두 절의 정의를 재사용하고, 여기서는 채널 간 일관성·공통 요소·접근성·관리 경계를 담당한다. 실제 서비스의 접근성 전체 적합이나 한국의 법적 인증을 주장하지 않는다.

같은 목표를 서로 다른 표면에 연결한다

채널마다 열 수·탐색 배치가 달라도 같은 신청의 확정 조건과 용어는 유지한다. 별도 상담 경로가 있다면 무엇을 조회·처리할 권한이 있는지부터 정하고, 웹 화면의 픽셀 배열을 그대로 복제하려 하지 않는다. 구조의 일관성은 모든 화면을 동일하게 만드는 것과 다르다.

규칙·구성요소·패턴을 함께 관리한다

디자인시스템(design system)은 일관된 제품 경험을 만들고 유지하기 위해 공유하는 설계 원칙·규칙·재사용 요소·사용 지침과 관리 체계다. UI 구성요소(component)는 정한 역할과 입력·상태·행동을 가지고 화면에서 재사용하는 단위다. 버튼 모양의 파일만으로 전체 체계가 완성되는 것은 아니다.

GOV.UK Design System은 스타일·구성요소·패턴을 구별해 사용하도록 안내한다. [UA-S1] UR-LIB에서는 글자·간격은 스타일, 오류 안내 입력은 구성요소, 검토→제출→결과 확인의 조합은 패턴의 예다. 이 분류를 실제 제품의 모든 책임 경계와 동일하다고 강요하지는 않는다.

관리에는 담당·판본·변경 이유와 소비 화면의 확인이 포함된다. 어느 파일을 고치면 어떤 동작과 설명을 함께 검토해야 하는지 알 수 있어야 공통화가 도움이 된다.

경험 구조와 구현 구조의 연결을 좁혀 쓴다

UX 아키텍처가 실제 서버의 확정을 새로 만들어 주지는 않는다. 화면이 표현할 상태와 데이터 계약을 연결하되, 책임을 넘어선 보장을 문서에 쓰지 않는다. 경험 구조의 기본 질문과 내부 소프트웨어 구조는 관련되지만 같은 지도는 아니다.

2. 값의 이름이 의도를 전달하게 한다

디자인 토큰(design token)은 재사용할 설계 값에 읽을 수 있는 이름과 필요한 유형·설명을 붙인 정보 단위다. 토큰 별칭(alias)은 다른 토큰을 참조하여 값을 얻는 연결이다. Design Tokens Community Group(DTCG)의 2025.10 규격은 이런 정보의 교환과 참조 형식을 설명한다. 이 문서는 Community Group 규격이며 W3C 표준이나 Recommendation과 같은 지위라고 표시하지 않는다. [UA-S2]

이 절의 의미 토큰은 ‘중립색 900’보다 ‘본문 글자색’처럼 사용 목적을 표현한다. 같은 원시 값도 오류·일반 본문·비활성 표시에서 맡는 역할이 다르므로 이름을 무조건 합치지 않는다. 토큰을 썼다는 사실은 대비·의미·접근성이 저절로 적합하다는 뜻도 아니다.

UA-T1: 색 하나의 영향이 어디로 가는가

이 예는 도구 독립적인 설명용 참조 그래프다. 실제 DTCG JSON 파일을 구현하거나 변환한 결과가 아니다.

result.message.text는 text.primary를 거쳐 palette.ink의 값을 사용한다. 토큰 값을 바꾸면 결과 안내 외에 같은 의미 토큰을 참조하는 다른 화면도 영향 대상이다. 그 사용 집합을 찾지 않고 첫 화면만 확인하면 공통화가 오히려 오류를 넓힐 수 있다.

UA-T1에는 유효 참조 사슬뿐 아니라 존재하지 않는 대상과 a→b→a 순환을 거부하는 예를 둔다. 임의의 기본값으로 바꾸어 성공처럼 통과시키지 않는다. 이름·유형·연결이 유효해도 실제 화면의 의미와 가독성은 별도로 확인한다.

구성요소 계약은 모양 외의 상태를 포함한다

UR-LIB의 결과 안내 요소는 적어도 상태, 요청 식별자, 사용자에게 알릴 문장, 다음 행동을 받는다. CONFIRMED를 표시하려면 R1의 확인된 결과와 신청번호가 있어야 하고, UNKNOWN에는 결과 확인 경로를 남긴다. 색상이나 아이콘만으로 상태를 전하지 않는다.

입력 요소라면 이름·레이블·입력값·필수 여부·오류·도움과 키보드 초점을 함께 명세한다. 문구의 길이, 확대, 작은 화면, 오류가 여러 개일 때도 어떻게 읽고 이동하는지 확인할 수 있어야 한다.

이 계약은 자체 설계안이다. 컴포넌트 라이브러리에 같은 이름이 존재한다는 이유로 실제 구현이 이 모든 조건을 충족했다고 표시하지 않는다. 화면 팀은 올바른 조합과 데이터를, 공통 요소 담당은 기본 동작과 변경 영향을 함께 확인한다.

UA-S1: 한 요청의 결과를 다른 요청에 붙이지 않는다

서버 상태와 UI 상태를 연결하는 핵심은 표시색이 아니라 같은 의도를 가리키는 식별자와 결과의 근거다. 공통 결과 요소를 재사용하더라도 잘못된 R2를 넘기면 R1 사용자에게 잘못된 사실을 전달한다.

검토 창이 닫히거나 키보드 초점이 돌아오는 행동도 서버의 신청 취소·철회를 의미하지 않는다. 입력·응답 계약과 화면의 이동을 별도의 사건으로 관리한다.

접근성은 여러 사용 방식으로 과업을 가능하게 하는 조건이다

웹 접근성은 장애를 포함한 다양한 사용 조건에서 이용자가 웹의 정보와 기능을 인지·이해·조작할 수 있도록 하는 특성과 실천이다. 키보드 초점(focus)은 현재 키보드 입력을 받거나 조작할 위치를 나타내는 상태다. 초점이 어디 있는지 모르거나 이동할 수 없으면 버튼의 색이 예뻐도 사용할 수 없다.

이 절은 WCAG 2.2의 2024-12-12 고정 Recommendation 판본을 학습 기준으로 사용한다. 인지·운용·이해·견고성의 관점에서 내용을 보되 한국 법령이나 인증의 적용을 대신 판단하지 않는다. [UA-S3] ‘최신판을 확인했다’거나 모든 장애인의 필요를 충족했다는 주장도 아니다.

실제 대상·콘텐츠·기술·지원 환경을 정한 뒤 기준을 매핑한다. 색 대비만의 검사와 서비스 전체의 접근성 평가를 구별해야 한다.

키보드·초점·읽기 순서가 과업을 지킨다

키보드로 강좌 선택·조건 확인·수정·제출·결과 조회를 진행할 수 있는지 살핀다. 정지 화면만으로는 버튼의 작동과 이동 경로를 알 수 없다. WCAG의 키보드 기준은 기능의 키보드 조작을 다루며 입력 경로 자체가 본질적인 경우의 예외를 구별한다. [UA-S7]

UR-LIB의 예제에서는 초점이 논리적인 순서로 이동하고 위치가 보이며, 고정된 안내막이 현재 조작 대상을 완전히 가리지 않도록 설계한다. 이와 관련된 초점 순서·표시·가림 기준은 각각 별도로 확인한다. [UA-S3]

시각적 열의 배치가 바뀌어도 실제 읽기·조작 순서와 레이블이 의미 있게 남아야 한다. 마우스로 클릭해 보았다는 기록은 이 키보드 경로의 검증을 대신하지 않는다.

UA-F1: 모달 검토 창의 경계를 정한다

UR-LIB가 제출 전 내용을 모달 창으로 검토하도록 별도 설계 가정을 둔다. ARIA Authoring Practices Guide(APG, 접근 가능한 리치 인터넷 응용을 위한 제작 실무 안내)의 모달 패턴은 열릴 때 내부로 초점을 옮기고, 내부 이동과 닫기·적절한 위치 복귀를 다룬다. 최초 초점과 복귀 위치는 내용과 과업에 따라 정한다. [UA-S5]

UA-F1은 세 조작 수정, 제출, 닫기를 가진 간단한 창이다. 열면 수정에 초점을 두고, Tab은 수정→제출→닫기→수정으로, Shift+Tab은 반대로 이동한다. Escape는 창을 닫고 계속 존재하는 ‘검토’ 호출 버튼으로 돌아간다. 이것은 이 예의 계약이지 모든 창에서 첫 버튼을 택하라는 일반 법칙이 아니다.

여기서 Shift+Tab은 Shift 키를 누른 상태에서 Tab 키를 누른다는 뜻이며 두 키 이름의 덧셈이 아니다. 창을 열어 수정에 초점이 있는 상태에서 Shift+Tab을 한 번 누르면 이전 위치인 닫기로 순환하고, 다시 Tab을 누르면 수정으로 돌아온다. 그 뒤 Escape를 누르면 창을 닫고 바깥의 검토 호출 버튼으로 복귀한다. 이 순서에서 초점 이동은 어느 요소가 다음 키 입력을 받는지를 바꿀 뿐 제출을 실행하거나 서버 신청을 취소하지 않는다. Shift+Tab 뒤 바깥 화면으로 빠져나간다는 답은 창 내부 순환 계약을 놓친 것이므로 위의 세 조작 순서를 다시 따라가 본다.

호출 요소가 삭제되었거나 과업이 다음 단계로 진행되면 의미 있는 다른 복귀 위치가 필요하다. 창 밖을 조작하지 못하게 표시만 하고 실제 행동은 허용하는 불일치도 점검한다. 이 유한 상태 검사는 실제 브라우저·보조기기의 상호작용 시험이 아니다.

ARIA 이름만 붙이면 행동이 생기는 것은 아니다

ARIA(Accessible Rich Internet Applications)는 보조기술에 역할·상태·속성을 전달하는 접근성 기술이다. APG의 모달 설명은 역할·이름·모달 상태와 실제 키보드 행동을 함께 다룬다. [UA-S5] 일반 영역에 dialog라는 역할 이름만 붙여도 초점 이동·닫기·배경 조작 제한이 자동 완성되는 것은 아니다. 실제 구현의 기본 기능과 필요한 보완을 확인한다.

UR-LIB에서 ‘제출’처럼 보이는 요소가 키보드로 동작하지 않으면 같은 모양의 기본 버튼으로 바꾸는 선택부터 검토한다. 익숙한 기본 요소를 불필요한 맞춤 동작으로 대체하면서 책임을 늘리지 않는다.

이 절은 특정 라이브러리가 지원하지 않는다고 가정하지 않는다. 실제 프로젝트에서는 이미 사용하는 구성요소의 문서·유형·동작을 먼저 확인하고, 부족한 부분만 현재 요구에 맞게 수정한다.

3. 오류·미확인·완료를 보이는 방식과 읽히는 방식으로 연결한다

연락처 입력을 거부했다면 어디가 무엇 때문에 잘못되었는지와 수정할 위치를 연결한다. 텍스트를 지우고 빨간 테두리만 남기는 방식은 사용자가 원인을 알기 어렵다. 오류의 식별과 이름·역할·값은 관련 기준에서 별도로 다룬다. [UA-S3]

신청 결과가 동적으로 바뀌면 화면을 보는 사람뿐 아니라 그 변화를 인지할 다른 방식도 고려한다. WAI의 상태 메시지 설명은 초점을 옮기지 않고도 중요한 변경을 보조기기가 전달할 수 있는 의미를 다룬다. 모든 문장을 과도하게 알리는 것이 목적은 아니다. [UA-S6]

UA-S1의 UNKNOWN을 CONFIRMED 문구로 안내하는 것은 전달 기술 이전에 내용이 잘못된 것이다. 올바른 상태·문장·식별자를 먼저 확인하고 필요한 변화만 적절히 전달한다. 화면에 보이는 문장과 접근 가능한 이름이 서로 다른 행동을 가리키지 않도록 점검한다.

UA-C1: 색 이름이 아니라 대비를 계산한다

명암 대비비는 밝은 색과 어두운 색의 상대휘도에 각각 0.05를 더한 값의 비율이다. 식은 (L밝음+0.05)/(L어두움+0.05)다. 여기서 상대휘도는 검정 0부터 흰색 1까지의 밝기를 나타내며, 실제 RGB 값은 정한 색공간의 변환을 거쳐야 한다. [UA-S4]

UA-C1에서는 그 변환을 이미 마친 상대휘도를 직접 주어 산술만 확인한다. 배경은 0.80이고 글자 후보 A는 0.05, B는 0.14다. 모두 큰 글자·로고·비활성 등의 예외가 아닌 일반 본문이며 이 예의 판정 기준은 4.5:1이다.

A: (0.80+0.05)/(0.05+0.05) = 8.5:1 → 충족
B: (0.80+0.05)/(0.14+0.05) = 4.473684…:1 → 미충족

반올림한 4.5라는 표기만 보고 B를 통과시키지 않는다. 실제 색공간·배경·투명도·글자 유형을 확인하지 않은 화면에는 이 값을 그대로 적용할 수 없다. 좋은 대비도 전체 접근성 적합이나 최적 가독성을 보증하지 않는다.

모든 요소에 같은 대비 기준을 적용하지 않는다

일반 본문 대비비와 큰 글자·로고·비활성 요소 등의 조건은 구별한다. UA-C1은 그 예외가 없는 경우만 계산했다. 글자가 아닌 경계·그래픽의 조건을 본문 글자 기준 하나로 대신하지 않는다. [UA-S4]

내용을 확대하거나 좁은 화면에서 재배치했을 때 중요한 안내가 잘리거나 과업 순서가 어긋나는지도 본다. 그림이 의미를 전달하면 대체 정보가 필요한지 판단하고, 장식 이미지에 무의미한 설명을 반복시키지 않는다. 재배치와 비텍스트 정보는 별도 기준의 대상이다. [UA-S3]

규칙 수를 줄여 보기 좋게 만들기보다 대상·예외·판정 증거를 구별한다. 자동 검사 도구가 판정하지 못한 항목은 실제 사람의 확인으로 연결한다.

일부 검사를 통과했다고 전체 적합으로 계산하지 않는다

가상 체크리스트 UA-A1에 관련 항목 열 개가 있고 아홉은 통과, 하나는 위반이라고 하자. ‘90%이므로 적합’이라는 결론은 안 된다. 위반을 고치고 영향 범위를 다시 확인한다. 미확인 하나가 있어도 확인한 것으로 세지 않는다.

WCAG 적합성은 목표 수준의 요구, 전체 페이지와 완결된 절차 등 정한 조건을 함께 다룬다. [UA-S3] UA-A1의 열 항목 자체가 그 전체 목록은 아니다. 전부 통과해도 이 열 항목의 점검 결과일 뿐 모든 기준·페이지를 포괄했다고 주장할 수 없다.

관찰 도구의 결과를 모으되 규범의 수준·범위와 실제 확인 범위를 따로 적는다. 접근성 평가 도구만으로 전체 적합 여부를 결정할 수 없고 사람 판단이 필요한 부분이 있다. [UA-S8]

변경은 공통 요소와 소비 화면을 함께 검사한다

본문 글자 토큰을 바꾸면 그 값을 쓰는 결과·오류·도움 화면의 배경 조합을 찾는다. 제출 요소의 행동을 바꾸면 작은 화면뿐 아니라 큰 화면·키보드·보조기기의 과업 흐름까지 영향 대상이다.

변경 요청에는 이유·대상·현재 사용처·계약 변화·검사·담당과 완료 조건을 적는다. 현재 요구에 맞는 명확한 기준으로 정리하고 오래된 잘못된 경로를 남겨 두어 두 의미가 동시에 살아 있지 않도록 한다. 이 절의 절차는 변경된 사용처와 계약을 확인하는 교육용 관리 사례다.

공통 요소의 검사와 완성 화면의 검사는 서로 다르다. 올바른 입력 요소를 엉뚱한 레이블·상태와 조합하면 사용자 경험은 다시 깨지므로 실제 사용하는 맥락에서도 확인한다.

공통화할 것과 맥락에 남길 것

공통화는 반복을 줄이되 서로 다른 업무 의미를 지우지 않아야 한다. 예외가 필요하면 이유와 검증 범위를 남기고, 장식의 차이와 과업 계약의 차이를 나누어 판단한다.

UA-LIB 검토 기록의 작성 예

UR-C1과 UR-S1의 확정·미확인 의미를 작은 화면과 큰 화면에서 유지한다. 공통 결과 요소는 요청 R1과 그 확인 결과를 연결하며 R2 결과를 재사용하지 않는다. UA-T1의 누락·순환 참조를 거부하고 실제 소비 화면을 추적한다. UA-F1의 키보드 흐름과 UA-C1의 대비 계산을 확인하되 실제 브라우저·보조기기·장애 사용자 평가 및 전체 기준 적합은 별도 미확인이다. 목표 수준·페이지·과업과 검증 담당을 명시하여 후속 검사로 연결한다.

이 기록은 구현·테스트의 질문을 구체화한다. 다음 절에서는 이런 설계안을 어떤 프로토타입과 과업으로 관찰하고, 발견한 문제의 수치·원인·개선을 어떻게 해석할지 이어 다룬다.

공식 범위와 답안의 연결

UX 아키텍처의 답안은 사용자 목표를 정보·상태·채널·공통 요소·접근성 계약에 연결하고 변경 영향을 검증하는 흐름이다. 토큰이나 구성요소 목록에 그치지 않고 실제 과업의 입력·응답·초점·오류·확정 의미를 조직한다. 본 절의 계산과 유한 상태 사례는 전체 웹 접근성 적합·법적 인증·실제 사용성 효과를 대신하지 않는다.

독립 연습 — 토큰의 성공과 화면의 성공을 구분한다

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

UA-C1의 일반 본문 B는 상대휘도 0.80과 0.14이며 큰 글자 등 예외가 없는 원래 조건이다. 토큰 별칭은 누락·순환 없이 해석된다. 체크리스트 열 항목 중 아홉은 통과하고 이 대비 항목 하나만 위반했다.

• 대비비를 충분한 자릿수로 계산하고 4.5 기준을 판정하라.
• 별칭 해석 성공과 90% 통과로 전체 접근성 적합을 선언할 수 있는지 설명하라.

4. 자체 10점 문제

UX 아키텍처에서 디자인시스템·디자인 토큰·구성요소와 접근성 계약의 관계를 설명하고, 공통화가 곧 적합성 보장은 아닌 이유를 제시하시오.

실제 기출이 아닌 자체 작성 문제다. 토큰 목록보다 실제 행동과 의미가 일치하는지, 확인한 범위가 어디까지인지 설명한다.

5. 자체 25점 문제

도서관 강좌 신청을 작은 화면과 큰 화면에서 제공한다. UR-S1의 상태 의미를 유지하면서 UX 아키텍처·공통 요소·토큰·접근성 계약을 설계하고 UA-S1·UA-T1·UA-F1·UA-C1의 판정과 변경 검증 방안을 제시하시오.

실제 기출이 아닌 자체 작성 문제다. 문제의 가상 규약을 실제 서비스 시험 결과나 전체 표준 적합으로 확대하지 않는다.