UI 컴포넌트 라이팅
(Component Microcopy)

개요

UI 컴포넌트는 시민이 공공 서비스와 직접 상호작용하는 접점입니다. 각 컴포넌트에 최적화된 마이크로카피 공식을 적용하면 오조작·이탈을 줄이고 완료율을 높입니다. 정부24·복지로·국민신문고·고용24·서울시 응답소의 반복 패턴을 KRDS 컴포넌트 기준으로 다시 정리했습니다.

공공 서비스 화면은 버튼 하나, 배너 하나로 끝나지 않습니다. 같은 과업 안에서 어떤 KRDS 컴포넌트를 묶어야 시민이 판단 → 입력 → 실행 → 후속 처리를 끊기지 않고 이해하는지 먼저 정해야 합니다. 이 표는 실제 공공서비스 화면을 빠르게 재구성할 때 쓰는 조합 기준입니다.

전 원칙 재점검 기준으로 보면 이번 순회에서 7장은 Button / Search / Modal / Table / Structured list / Result page를 먼저 채우는 편이 효율적입니다. 대표 사이트에서 실패 패턴이 반복되고, KRDS 조합으로 바로 옮기기 쉬운 여섯 축이기 때문입니다.

표기 문제도 7장에서는 컴포넌트 문제로 다시 적어야 합니다. 표 헤더, 상태표 레이블, 탐색 레이블, 숨은 레이블, 기호 압축은 각각 다른 컴포넌트에 붙지만, 공통으로 CASE 묶음, krds-lint fixture, Description, 숨은 레이블 메모를 같은 라운드에서 함께 남겨야 다음 회귀와 Figma handoff가 흔들리지 않습니다.

이번 라운드의 Result page는 대표 사이트에서 실제로 다시 볼 화면 1개씩을 먼저 고정해 두고, 새 사례를 늘리기 전에 기존 CASE 묶음 어디에 붙는지부터 판정합니다.

D-9-3 우선축 화면은 Description만 추가한다고 끝나지 않습니다. 4장에서 정한 위험·복구 순서가 7장에서는 상태 배지, 배너, 버튼, 링크 이름까지 같은 첫 블록 순서로 내려와야 합니다.

홈택스·국민건강보험·고용24·국민신문고·서울특별시 응답소·전자가족관계등록시스템은 입력창이나 버튼 이름만 다듬어서는 충분하지 않습니다. 공식 화면에서 이미 보이는 효력 발생일, 검색 범위, 결과 수신 채널, 로그인 유지 시간, 모집 현황·본인부담액, 발급번호·조회 가능 기간 같은 판단 단서를 Description, 기본 예시 문구, 숨은 레이블 메모까지 같은 라운드에서 같이 내려야 실제 신청·재확인 흐름이 끊기지 않습니다.

4.1 버튼 레이블

버튼은 다음 행동과 결과를 예고해야 합니다. "확인"처럼 맥락 없는 레이블은 시민이 다음에 무슨 일이 일어날지 예측할 수 없게 만듭니다. 복지로·응답소·고용24처럼 과업이 다른 버튼이 함께 있는 화면일수록 이름과 위계를 분리해야 합니다.

홈택스의 메뉴 이름은 실제로는 링크이지만 사용자가 누르는 순간 과업이 시작되므로 버튼과 같은 기준으로 봐야 합니다. 환급, 세법 확인, 세무대리, 증명서 발급, 선납 안내처럼 실수 비용이 큰 화면일수록 제도명을 앞세우지 말고 조회, 신청, 등록, 위임 취소, 발급, 선납 같은 과업 동사를 먼저 둬야 합니다.

메뉴 이름이 짧다고 좋은 것이 아닙니다. 신청 및 해지, 발급·취소·수정, 제출전/제출후처럼 서로 다른 행동이나 단계를 점(·), 슬래시(/), 괄호() 하나로 뭉치면 사용자는 먼저 현재 상태와 분기 기준부터 해석해야 합니다. 메뉴는 압축이 아니라 선택 구조를 보여줘야 하므로, 행동·단계·대상이 갈리면 KRDS 컴포넌트도 함께 분리해야 합니다.

비교표, 계산기, 모의 조회로 사용자가 이미 판단을 끝냈다면 버튼은 더 이상 `안내 보기`에 머물면 안 됩니다. 결과를 본 직후 바로 실행할 수 있는 신청·신고·집행 CTA를 같은 영역에서 보여줘야 합니다.

비교나 계산을 마친 뒤 다음 신청·신고·집행으로 바로 넘어가야 하는 화면은 CASE 37을 먼저 붙여 봅니다. 같은 결과 영역에서 지금 나온 판단, 바로 실행할 CTA, 지금 눌러야 하는 이유가 같이 읽히는지 확인하고, 버튼 위계 문제는 CASE 9, 메뉴 이름 문제는 CASE 39와 이어 판정합니다.

버튼 사례를 더 채울 때는 버튼 하나만 떼어 보지 말고 메뉴 진입 → 비교·판단 결과 → 후속 행동 순서로 봅니다. 아래 표는 다음 순회에서 바로 쓰는 수집 기준입니다.

CASE 39, CASE 9, CASE 37은 다른 카드처럼 보여도 실제 검수에서는 한 흐름입니다. 사용자는 먼저 메뉴나 링크로 들어오고, 같은 화면에서 여러 CTA 중 무엇을 눌러야 할지 고르고, 판단 결과를 본 뒤 다음 신청·신고·집행 버튼으로 이어집니다. 버튼 QA는 이 세 순간을 끊지 말고 한 번에 확인해야 합니다.

aria-label, 숨은 텍스트, 아이콘 버튼 이름, 토글 상태 문구도 시민이 실제로 듣는 인터페이스 문장입니다. 여기서 서비스 상세 이동, 1번째 배너, AI 켜기, 새창처럼 내부 표현이나 상태 단어만 남기면 목적과 현재 상태를 예측할 수 없습니다.

4.2 입력 폼

폼은 레이블·플레이스홀더·안내문 3중 구조로 시민이 무엇을, 어떻게, 왜 입력해야 하는지 인지 부하 없이 전달합니다.

입력 화면 앞단에 공식 용어가 몰린다고 해서 그 단어를 레이블 첫 줄에 그대로 올리면 안 됩니다. 레이블은 시민이 지금 입력하거나 선택할 대상을 보여주고, 공식 용어의 뜻과 다음 판단은 도움말로 내려야 합니다.

파일 업로드는 단순 입력이 아니라 증빙 제출 단계입니다. 허용 형식, 파일당 용량, 총 용량이나 개수, 변환이 필요한 형식, 반려됐을 때 다시 제출하는 경로를 업로드 전에 먼저 보여줘야 합니다.

업로드 전에 제한 조건과 재제출 경로를 알아야 하는 화면은 CASE 24를 먼저 붙여 봅니다. 같은 업로드 영역에서 허용 형식, 용량/개수 제한, 변환 필요 형식, 재제출 경로가 같이 읽히는지 확인합니다.

예상 비용이나 세금, 수수료를 계산하는 화면에서는 숫자 입력칸만 두면 안 됩니다. 어떤 값을 넣는지, 무엇이 더해지고 빠지는지, 감면·비과세·면제 조건이 있는지, 계산 뒤에 무엇을 해야 하는지를 입력 전에 함께 보여줘야 합니다.

숫자를 넣는 순간 예상 비용이나 수수료가 계산되는 화면은 CASE 35를 먼저 붙여 봅니다. 같은 입력·결과 영역에서 계산 기준, 포함 또는 제외 항목, 감면·비과세 조건, 계산 뒤 행동이 같이 읽히는지 확인하고, 예상값이 바로 나오면 CASE 36으로 이어 붙여 판정합니다.

계산기나 모의 조회에서 보여주는 숫자는 최종값이 아닌 경우가 많습니다. 그래서 `이 값이 어느 시점을 기준으로 한 예상값인지`, `무엇이 바뀌면 달라지는지`, `언제 확정되거나 정산되는지`, `차이가 생기면 어디로 가야 하는지`를 결과와 함께 보여줘야 합니다.

확정 전 예상값을 먼저 보여주는 화면은 CASE 36을 먼저 붙여 봅니다. 같은 과업 안에서 감액·환수·추징까지 이어지는 화면은 그다음 CASE 41, 최종 확정 근거는 CASE 42로 이어 붙여 예상값, 차이, 확정 결과를 같은 순서로 판정합니다.

예상 수령액, 반기 선지급액, 조기 환급 예정액, 예상 배당액처럼 먼저 보여준 값이 나중에 달라질 수 있다면 `추후 변경될 수 있음`만으로는 부족합니다. 왜 달라지는지, 차액이 감액·추가 지급·환수·추징·환급 중 무엇으로 처리되는지, 사용자가 지금 신고나 확인을 해야 하는지까지 한 번에 보여줘야 합니다.

예상값이 정산·심사·선순위 확정 뒤 바뀌는 화면은 CASE 41을 먼저 붙여 봅니다. 같은 과업 안에서 확정 화면까지 이어지는 경우는 CASE 42를 같이 붙여 왜 바뀌었는지, 차액이 어떻게 처리되는지, 지금 무엇을 해야 하는지가 한 흐름으로 읽히는지 확인합니다.

연말정산 환급세액, 건강보험 지역가입자 보험료, 가산세 자동계산 결과, 국세 환급금처럼 결과가 이미 계산돼 나왔더라도 숫자만 보여 주면 부족합니다. 어떤 기준으로 산출됐는지, 직전 값과 비교해 무엇이 늘거나 줄었는지, 지금 납부·분납·경감 신청·계좌 등록·수정 신고 중 무엇을 해야 하는지 한 번에 보여줘야 합니다.

세금 납부나 경매 대금 납부처럼 돈이 바로 나가는 화면에서는 `납부하기` 버튼만 두면 부족합니다. 한 번에 다 내야 하는지, 나눠 낼 수 있는지, 미리 내면 할인되는지, 기한을 넘기면 어떤 불이익이 생기는지를 한 번에 보여줘야 합니다.

4.3 선택지 (라디오·드롭다운·체크박스)

선택지는 서로 겹치지 않고(MECE), 이중부정을 포함하지 않아야 합니다. 시민이 한 번에 올바른 선택지를 고를 수 있어야 합니다.

KRDS의 동의 컴포넌트는 항목을 나열하는 데서 끝나면 안 됩니다. 무엇에 동의하는지, 필수인지 선택인지, 왜 필요한지, 동의 후 어떻게 철회하는지를 첫 화면에서 분리해 보여줘야 합니다.

여권 재발급 유형, 납부 기한 연장 사유, 공탁금 출급 상황처럼 선택에 따라 필요한 서류와 처리 시간이 달라지면, 선택지 이름만 던지지 말고 결과 예측 문장을 바로 붙여야 합니다.

전입신고, 사업자 등록 정정, 집행문 부여 신청처럼 내 상황에 따라 인터넷 신청 가능 여부나 실제 신청처가 갈리면 서비스 이름만 두면 안 됩니다. 시작 전에 어떤 경우가 인터넷으로 가능하고, 어떤 경우는 기관에 직접 제출해야 하며, 신청처가 어떻게 갈리는지 먼저 보여줘야 합니다.

피부양자 등록, 연말정산 부양가족 조회, 소송 기록 열람처럼 신청인이 본인인지, 가족인지, 이해관계인인지에 따라 필요한 증빙과 동의가 달라지면 첫 줄에서 그 차이를 보여줘야 합니다. 같은 신청서라도 누구로 들어왔는지에 따라 필요한 서류와 권한이 달라지기 때문입니다. 같은 규칙은 직거래인지 공인중개사 거래인지에 따라 매도인·매수인이 함께 신고해야 하는지 달라지는 부동산 거래 신고에도 그대로 적용됩니다.

신청 주체가 바뀌는 순간 준비 서류와 동의 범위가 달라지는 화면은 CASE 19를 먼저 붙여 봅니다. 같은 첫 분기 영역에서 누가 신청하는지, 추가 서류, 필요 동의, 함께 신청해야 하는 사람 또는 처리 권한 차이가 같이 읽히는지 확인합니다.

외국인 여부, 영세율 적용 유형, 미성년 자녀 여부처럼 같은 신청서 안에서도 특정 답을 고른 순간에만 필수 입력이나 첨부가 생기는 경우가 있습니다. 빨간 별표만 두거나 다음 단계 오류에서 알리지 말고, 그 선택이 만들어내는 필수 항목을 바로 드러내야 합니다.

특정 답을 고르는 순간에만 입력이나 첨부가 더 생기는 화면은 CASE 20을 먼저 붙여 봅니다. 같은 입력·첨부 영역에서 해당자만 필수, 지금 추가로 필요한 입력·첨부, 누락 시 다시 확인되거나 멈추는 단계가 같이 읽히는지 확인합니다.

등본과 초본, 일반증명서와 상세증명서, 일반용과 금융거래용처럼 같은 증명서 안에서도 포함 정보와 제출처가 다르면 종류 이름만 두면 안 됩니다. 어떤 정보가 들어 있는지, 보통 어디에 내는지, 비슷한 종류와 무엇이 다른지 먼저 보여줘야 합니다.

비슷한 증명서 이름만 보고 고르기 쉬운 화면은 CASE 22를 먼저 붙여 봅니다. 같은 선택 영역에서 무엇이 포함되는지, 주요 제출처, 유사 종류와 차이, 종류 비교 또는 제출처 예시 경로가 같이 읽히는지 확인합니다.

주민등록번호 뒷자리 표시 여부, 세대원 포함 범위, 말소 사항 포함 여부, 세무정보 열람 기간처럼 같은 업무 안에서도 공개 범위를 고르는 순간이 있습니다. 이때는 범위 이름만 두지 말고, 무엇이 보이는지, 어느 제출처나 공개 대상에 필요한지, 불필요한 정보는 어떻게 줄일지, 해제는 어디서 하는지 함께 보여줘야 합니다.

공개 수준을 고르는 순간 개인정보 최소화와 제출 목적을 같이 판단해야 하는 화면은 CASE 23을 먼저 붙여 봅니다. 같은 선택 영역에서 노출되는 정보, 권장 범위, 생략 권장 정보, 해제 또는 재설정 경로가 같이 읽히는지 확인합니다.

4.4 모달 · 토스트

모달과 토스트는 시민의 흐름을 끊습니다. 메시지는 [원인 + 해결책] 최단 청크로 구성합니다.

세션 종료는 단순 오류가 아니라 사용 흐름이 끊기는 순간입니다. 만료 전 경고 모달, 자동 저장 토스트, 재로그인 또는 메인 복귀 버튼을 따로 흩어두지 말고 한 흐름으로 이어야 합니다.

모달 사례는 오류 문장만 모으지 말고 경고 → 만료 → 재진입 흐름으로 수집합니다. 같은 경고라도 남은 시간, 저장 여부, 다시 들어가는 길이 분리되면 별도 사례로 보강합니다.

CASE 16은 오류 문장 하나가 아니라 세션 종료 흐름 전체를 보는 카드입니다. 사용자는 먼저 남은 시간을 보고, 세션이 실제로 끊긴 뒤 저장 여부를 확인하고, 다시 로그인하거나 메인으로 돌아가는 길을 택합니다. 모달 QA는 이 세 순간을 끊지 말고 한 번에 기록해야 합니다.

4.5 아코디언 · 툴팁

인라인 헬프는 시민이 페이지를 벗어나지 않고 도움을 받을 수 있게 합니다. 맥락에 맞는 도구를 선택합니다.

4.6 빈 화면 (Empty State)

빈 화면은 시민이 막다른 길에 부딪힌 순간입니다. 원인을 설명하고 다음 행동을 안내해야 합니다. "내역 없음"은 설명이 아닙니다.

4.7 단계 표시기 (Step Indicator)

단계 표시기는 시민이 전체 여정에서 자신의 위치를 인식하게 합니다. 단계 번호와 섹션 이름을 함께 표시합니다.

4.8 태그 · 배지

태그와 배지는 상태·분류를 한눈에 전달합니다. 4음절 이내, 상태값은 정해진 위계를 따릅니다.

4.9 검색창

검색창은 입력 예시만 보여주는 영역이 아닙니다. 입력 필드, 지우기 버튼, 검색 버튼의 이름이 각각 분리되어야 하고, 결과가 없을 때는 다음 행동까지 이어져야 합니다.

검색 사례는 버튼 이름만 바꾸는 것으로 끝내지 않고 플레이스홀더 → 컨트롤 이름 → 결과 없음 세 지점을 한 번에 기록합니다. 같은 검색창이라도 무엇을 검색하는지와 실패 뒤 어디로 되돌려 주는지가 다르면 별도 사례로 승격합니다.

CASE 10과 CASE 49는 따로 보이지만 실제 검색 흐름에서는 하나입니다. 사용자는 먼저 무엇을 넣어야 할지 판단하고, 검색 결과 카드나 추천어를 읽고, 결과가 없으면 다시 검색합니다. 검색 QA는 이 세 순간을 끊지 말고 한 번에 기록해야 합니다.

4.10 탭 (Tab)

탭은 동일 계층의 정보를 분류합니다. MECE 원칙(상호 배타·전체 포괄)을 지켜야 시민이 올바른 탭을 선택할 수 있습니다.

탭, GNB, 카드 제목은 누르기 전에도 의미가 보여야 합니다. 정부24·홈택스·대한민국법원처럼 붙여 쓴 복합어가 많은 서비스에서는 단어 경계를 먼저 풀고, 무엇을 하는 메뉴인지 바로 알 수 있게 써야 합니다.

4.11 표 · 데이터 그리드

정부24 신청 상세, 국민신문고 상태표처럼 표는 공공 서비스의 기본 골격입니다. 이때 헤더는 데이터 이름이 아니라 시민의 판단을 돕는 짧은 레이블이어야 합니다.

온라인으로 발급한 서류는 PDF를 내려받게 하고 끝내면 안 됩니다. 제출처가 어떻게 진위를 확인하는지, 전자 발급본이 종이와 같은 효력을 가지는지, 바로 제출할 수 있는 경로가 무엇인지 함께 보여줘야 합니다.

증명서나 집행 서류를 바로 신청·발급할 수 없다면, 막혔다는 사실보다 먼저 왜 지금 경로가 맞지 않는지와 어떤 다음 경로가 있는지를 알아야 합니다. 온라인 대리 신청 불가, 체납 여부 확인, 신청처 분기처럼 조건이나 예외를 한 줄로 밝히고, 바로 이어서 다음 행동이나 대체 경로를 보여줘야 합니다.

신청 버튼을 누르기 전에, 내가 이 서비스를 신청할 수 있는지와 어떤 기준으로 판단되는지를 먼저 알아야 합니다. 세대주 변경, 사업장 현황 신고, 개명 허가처럼 자격이나 허가 기준이 있는 업무는 `누가 대상인지`, `판단 기준`, `기한 또는 불이익`, `사전 확인 경로`를 시작 화면에서 함께 보여줘야 합니다.

표 사례는 헤더만 고치고 끝내지 말고 헤더 → 상태 요약 → 다음 행동까지 함께 수집합니다. 발급 결과 화면은 표보다 Structured list가 먼저 결론을 여는지 같이 봅니다.

CASE 4, CASE 5, CASE 13, CASE 27은 표와 Structured list가 서로 다른 위치에 있지만 실제 검수에서는 한 흐름입니다. 사용자는 먼저 신청 자격과 준비물을 읽고, 진행 상태를 짧게 파악하고, 발급 결과의 효력·보관 기간·재출력 경로를 확인합니다. 표 QA는 이 세 순간을 끊지 말고 한 번에 기록해야 합니다.

4.12 배너 · 인라인 경고

배너와 인라인 경고는 설명을 길게 붙이는 영역이 아닙니다. 상태 한 줄과 행동 한 개만 남겨야 사용자가 다음 판단을 빠르게 내릴 수 있습니다.

공공서비스의 완료 화면 상단은 사실상 결과 배너입니다. 완료 사실만 알리고 끝내지 말고, 접수번호·처리 기간·결과를 확인하거나 받는 방법을 바로 붙여야 합니다.

CASE 31, CASE 32, CASE 33은 모두 결과 화면처럼 보이지만 실제 검수에서는 한 흐름입니다. 사용자는 결과를 본 직후 `지금 바로 해야 할 후속 행동`, `자동으로 이어지는 것과 별도로 신청·신고해야 하는 것`, `이의가 있을 때의 기한과 다음 절차`를 함께 판단합니다. 그래서 결과 뒤 후속 흐름 QA는 완료 뒤 후속 처리, 혜택·의무 안내, 불복·재심사 안내를 따로 떼지 말고 같은 첫 영역에서 함께 확인해야 합니다.

신고가 끝나거나 허가가 나온 뒤에도 실제 과업은 남아 있는 경우가 많습니다. 주소를 다른 기관에 다시 바꾸거나, 잘못 낸 신고를 바로잡거나, 신분증·여권 같은 파생 서류를 다시 발급해야 합니다. 이런 화면에서는 `지금 해야 할 후속 행동`, `연계 기관 또는 문서`, `기한 또는 미이행 위험`, `바로 가는 경로`를 첫 결과 영역에서 함께 보여줘야 합니다.

등록·허가·환급 결정이 났다고 끝이 아닙니다. 어떤 혜택은 바로 적용되고, 어떤 혜택은 다시 신청해야 하며, 어떤 의무는 기한 안에 신고해야 합니다. 이런 화면에서는 `자동으로 이어지는 것`, `별도 신청 또는 신고`, `놓치기 쉬운 기한·요건`, `바로 가기 경로`를 함께 보여줘야 합니다.

이용권, 바우처, 포인트처럼 받은 뒤 실제 사용 판단이 필요한 혜택은 어디에 쓸 수 있는지와 언제 사라지는지를 같이 보여줘야 합니다. 사용 가능 항목, 사용 불가 항목, 유효 기간, 잔액, 소멸·환수 위험이 흩어지면 사용자는 결제 단계에서 막히거나 만료를 뒤늦게 알게 됩니다.

심사 결과나 처분에 동의하지 않을 때는 `무슨 절차가 가능한지`, `언제까지 신청해야 하는지`, `그다음 무엇이 이어지는지`를 한 번에 알아야 합니다. `심사청구`, `불복청구`, `이의신청` 같은 절차 이름만 던지지 말고 `가능 여부`, `신청 기한`, `기한 경과 시 결과`, `불복 뒤 다음 절차`를 함께 보여줘야 합니다.

등급, 과세 방식, 소송 유형처럼 여러 선택지 중 하나를 고르게 하는 화면에서는 이름만 나열하지 말고 어떤 차이가 있는지 먼저 보여줘야 합니다. 사용자는 무엇을 고르는지보다 어떤 선택이 내 상황에 맞는지 판단해야 하므로, `등급·방식별 차이`, `예상 비용·혜택`, `누구에게 유리한지`, `바로 비교할 경로`를 같은 영역에 둬야 합니다.

절차 자체를 정한 뒤 등급·방식·경로 차이를 고르는 화면은 CASE 34를 먼저 붙여 봅니다. 같은 첫 선택 영역에서 비교 대상, 옵션별 차이, 예상 비용·혜택, 비교 CTA가 같이 읽히는지 확인하고, 절차 자체를 고르는 문제라면 CASE 60으로 넘깁니다.

`비교 선택`이 비용·혜택 차이를 보여주는 규칙이고, `신청 분기`가 이미 고른 절차 안의 준비물·처리 기간을 설명하는 규칙이라면, 절차 선택은 그보다 앞에서 어떤 절차 자체가 내 상황에 맞는지 가르는 규칙입니다. 민원 유형, 휴업·폐업, 개인회생·파산처럼 잘못 고르면 다시 판단해야 하거나 결과가 완전히 달라지는 화면에서는 서비스 이름만 두면 안 됩니다.

절차 이름만 보고 들어가면 되돌리기 어려운 화면은 CASE 60을 먼저 붙여 봅니다. 같은 첫 분기 영역에서 내 상황, 선택 기준, 오선택 위험, 비교·상담 CTA가 같이 읽히는지 확인하고, 절차를 정한 다음 화면에서만 비교 선택이나 신청 분기 규칙으로 넘깁니다.

안심상속, 금융정보 조회, 판결문 열람처럼 조회·열람 서비스는 결과를 열기 전까지 어디까지 보이는지 알기 어렵습니다. 시작 화면이나 첫 목록에서 `무엇이 조회되는지`, `무엇이 빠지는지`, `따로 확인·제출·철회해야 하는 경로`, `수수료·정정 기한·결과 해석`을 같이 보여줘야 합니다.

조회 범위와 제외 항목이 함께 갈리는 화면은 CASE 53을 먼저 붙여 봅니다. 같은 시작 화면이나 첫 목록에서 무엇이 조회·열람되는지, 빠지는 항목, 따로 확인·제출·철회해야 하는 경로, 동의 철회·정정 기한·수수료·결과 해석이 같이 읽히는지 확인하고, 조회 결과 해석이 더 핵심이면 CASE 42, 열람 권한·대리 범위가 더 앞서면 CASE 59로 이어 판정합니다.

CASE 5, CASE 42, CASE 54, CASE 55, CASE 56은 카드 이름은 달라도 실제 검수에서는 한 흐름입니다. 사용자는 결과 화면 첫 블록에서 `지금 무슨 상태인지`, `언제 반영되거나 얼마나 더 기다려야 하는지`, `지금 무엇을 하거나 어디에 문의해야 하는지`를 바로 판단합니다. 상태·결과 QA는 확정 결과, 변경·승인 결과, 심사·판정 절차, 대기·지연 상태를 따로 떼지 말고 같은 첫 영역에서 확인해야 합니다.

수령 방식 변경, 환급 계좌 변경, 원클릭 환급 신청, 외국 판결 승인처럼 상태를 바꾸는 절차는 완료 문구만으로는 부족합니다. `무엇에 적용되는지`, `언제부터 반영되거나 지급되는지`, `이미 진행 중인 건은 예외인지`, `자동으로 바뀌지 않는 항목은 무엇인지`를 한 자리에서 보여줘야 합니다.

완료 뒤 실제 반영 범위와 예외를 다시 판단해야 하는 화면은 CASE 54를 먼저 붙여 봅니다. 같은 완료 화면이나 결과 배너에서 적용 범위, 반영 또는 효력 발생 시점, 이미 진행 중인 건 예외, 자동으로 바뀌지 않는 항목, 별도 처리·집행 경로가 같이 읽히는지 확인하고, 아직 승인 대기 상태가 더 핵심이면 CASE 56, 결과 뒤 후속 의무가 더 앞서면 CASE 31·32로 이어 판정합니다.

장기요양 등급, 신고 유형 판정, 개명 허가처럼 결과가 심사나 판정에 달린 화면에서는 `심사 중`이라는 상태만으로는 부족합니다. `무엇을 기준으로 판단하는지`, `누가 어떤 단계로 검토하는지`, `언제 결과가 오는지`, `결과가 다르면 어디로 이어지는지`를 먼저 보여줘야 합니다.

판정 기준과 심사 단계가 시작 전에 보여야 하는 화면은 CASE 55를 먼저 붙여 봅니다. 같은 시작 화면이나 단계 표시기 아래에서 판정 기준, 심사 주체와 단계, 예상 소요 기간·결과 통보 시점, 결과별 다음 행동 또는 이의 경로가 같이 읽히는지 확인하고, 절차 자체를 고르는 문제가 더 핵심이면 CASE 60, 접수 뒤 기다리는 상태가 더 앞서면 CASE 56으로 이어 판정합니다.

민원 진행, 세금 환급 입금 대기, 법무부 심사 대기처럼 결과를 기다리는 시간이 긴 화면에서는 `처리 중`, `환급금: ○○원`, `접수되었습니다`만으로는 부족합니다. `현재 단계`, `예상 남은 기간 또는 예정일`, `지연 사유와 문의 경로`, `보완 요청·완료 알림 채널`을 같은 영역에서 보여줘야 합니다.

접수 뒤 오래 기다리는 동안 정상 범위인지, 지연인지 판단해야 하는 화면은 CASE 56을 먼저 붙여 봅니다. 같은 상태 영역이나 완료 뒤 첫 결과 화면에서 현재 단계, 예상 남은 기간 또는 예정일, 지연 사유 또는 기한 초과 시 문의 경로, 보완 요청·완료 알림 채널, 다시 확인하거나 바로 이동할 CTA가 같이 읽히는지 확인하고, 최종 결과 해석이 더 핵심이면 CASE 42, 일시적인 서비스 장애가 더 앞서면 CASE 25로 이어 판정합니다.

신청 조건이 나이·소득·재산·기한·병역처럼 여러 축으로 나뉘고 하나라도 빠지면 자격 확인이 다시 필요하거나 절차가 멈추는 화면에서는 `신청 가능` 한 줄만 두면 안 됩니다. 사용자가 각 조건을 따로 확인하고, 모두 충족인지 판단할 수 있게 조건별 체크리스트와 확인 경로를 같이 보여줘야 합니다. 같은 구조는 협의이혼 의사확인처럼 함께 방문해야 하는 사람, 숙려기간, 추가 협의서가 동시에 조건이 되는 화면에도 그대로 적용됩니다.

조건을 하나씩 넘기는 게 아니라 모두 충족하는지 먼저 판정해야 하는 화면은 CASE 57을 먼저 붙여 봅니다. 같은 시작 화면이나 첫 선택 영역에서 모두 충족해야 하는 조건 목록, 각 조건의 기준 수치 또는 상태, 직접 확인·계산 경로, 조건을 못 맞추면 생기는 결과나 다음 경로, 조건을 확인한 뒤 바로 가는 CTA가 같이 읽히는지 확인하고, 사람·관할·방문 경로 분기가 더 앞서면 CASE 18, 선택한 답 때문에 추가 입력이 늦게 나타나면 조건부 필수 항목 예시로 이어 판정합니다.

전입신고, 사업장 주소 정정, 등록부 정정처럼 같은 업무 이름이라도 어느 주민센터·세무서·가정법원이 처리하는지 다르면 서비스 이름만 보여줘서는 안 됩니다. 사용자가 `어디에 내야 하는지`, `기관이 갈리는 기준`, `예외`, `확인 경로`를 첫 화면에서 바로 판단할 수 있어야 합니다.

채널 분기와 관할 분기가 함께 붙는 화면은 CASE 18과 CASE 58을 같이 붙여 봅니다. 새 사례를 만들기 전에 먼저 어느 경로로 들어가야 하는지와 결국 어느 기관이 받는지가 같은 첫 분기 영역에서 읽히는지 확인합니다.

증명서 대리 발급, 세무대리 위임, 소송 대리인 등록처럼 다른 사람이 내 대신 처리하는 화면에서는 대리 관계 자체를 먼저 설명해야 합니다. 누가 대신할 수 있는지, 어떤 서류가 필요한지, 어디까지 맡기는지, 끝내는 방법을 한 자리에서 보여줘야 합니다.

대리 가능한 대상과 권한 범위가 첫 권한 영역에서 갈리는 화면은 CASE 59를 먼저 붙여 봅니다. 홈택스처럼 동의 문장과 위임 범위가 같은 화면에 붙는 경우는 CASE 38, CASE 11, CASE 59를 같이 붙여 누가 대신할 수 있는지, 어디까지 맡기는지, 언제 끝나고 어떻게 해지하는지가 같은 블록에서 읽히는지 확인합니다.

결과가 `보완 요청`이나 `반려`로 바뀌는 순간에는 왜 막혔는지, 언제까지 다시 낼 수 있는지, 어디서 바로 고치면 되는지를 먼저 알아야 합니다. `완료`, `판독 불가`, `불수리 통지`처럼 결과 이름만 남기지 말고 사유와 기한, 정정 경로를 같은 영역에서 보여줘야 합니다.

이메일, 전자송달, 알림톡, 문자, 우편처럼 채널이 다르면 받는 내용과 도착 시점, 놓쳤을 때의 위험이 달라집니다. 채널 이름이나 서비스 이름만 두지 말고 무엇이 언제 또는 언제부터 오는지 바로 붙여야 사용자가 설정 여부와 확인 경로를 판단할 수 있습니다. 이런 채널 이름 단독은 새 사전 항목보다 완료·상태 문장과 다시 확인 경로를 함께 보는 구조 규칙으로 먼저 다룹니다.

채널 이름보다 먼저 수신 내용과 재확인 경로를 확인해야 하는 화면은 CASE 21을 먼저 붙여 봅니다. 같은 설정·완료 영역에서 받는 내용, 도착 시점 또는 적용 시작 시점, 도착 채널, 완료·상태가 어떻게 바뀌는지, 놓쳤을 때 다시 확인할 경로가 같이 읽히는지 확인합니다.

갱신·신고·불복처럼 기한을 넘기면 권리나 기능이 바로 막히는 화면에서는 경고 배너가 단순 공지문이 아니라 우선순위 안내 역할을 해야 합니다. 남은 기간, 넘겼을 때 결과, 바로 할 행동을 한 덩어리로 보여줘야 합니다.

공모·신고·법정 신고처럼 특정 기간에만 열리는 서비스는 상세 화면에 들어간 뒤 막히면 이미 늦습니다. 서비스 카드나 시작 화면에서 `지금 가능한 기간`, `기한이 끝난 뒤 상태`, `예외 신청·기한 후 구제 가능 여부`, `다음 열림 시점 또는 대체 경로`를 같이 보여줘야 합니다.

서비스에 들어가기 전 지금 신청 가능한지를 먼저 판단해야 하는 화면은 CASE 45를 먼저 붙여 봅니다. 같은 시작 화면이나 배너에서 신청 가능 기간, 기한 경과 후 상태, 예외·구제 여부, 다음 시점 또는 대체 경로가 같이 읽히는지 확인하고, 이미 진행 중인 과업의 카운트다운 경고라면 CASE 17로 넘깁니다.

혜택, 과세 유형, 법적 보호처럼 한 번 시작한 뒤에도 유지 조건이 달라지는 서비스는 승인 사실만 보여주면 안 됩니다. 결과 배너나 상세 안내에서 `계속 받으려면 필요한 조건`, `자동 종료·전환 시점`, `종료 뒤 이어지는 제도·의무`, `미리 준비할 경로`를 같이 보여줘야 합니다.

한 번 승인되거나 유지되는 상태 뒤에 조건·전환·종료 의무가 남는 화면은 CASE 46을 먼저 붙여 봅니다. 같은 상태·결과 영역에서 계속 유지하려면 필요한 조건, 자동 종료 또는 전환 시점, 종료 뒤 이어지는 의무, 지금 준비할 경로가 같이 읽히는지 확인하고, 별도 신고·의무가 더 앞선 문제는 CASE 32, 특정 신청 기간이 다시 열리는 문제는 CASE 45로 이어 판정합니다.

안전, 생계, 납부 누락처럼 지금 놓치면 피해가 커지는 화면에서는 온라인 신청 버튼만 먼저 보여주면 안 됩니다. 현재 화면에서 바로 연결할 채널, 왜 먼저 해야 하는지, 온라인에서 이어질 다음 절차, 확인 경로를 한 자리에서 보여줘야 합니다.

지금 바로 연락·이동할 채널이 온라인 절차보다 앞서는 화면은 CASE 47을 먼저 붙여 봅니다. 같은 시작 화면이나 배너에서 지금 바로 연결할 채널, 먼저 연결해야 하는 이유, 온라인에서 이어지는 다음 절차, 누락·중복 처리 확인 경로가 같이 읽히는지 확인하고, 일반 상담 채널 안내가 더 핵심이면 CASE 50, 다른 기관·다른 사이트에서 병행해야 할 절차가 더 앞선 문제는 CASE 48로 이어 판정합니다.

정책자금, 연계 납부, 법원 보호 절차처럼 한 화면의 신청만으로 끝나지 않는 서비스는 다른 기관이나 별도 절차를 같이 안내해야 합니다. 무엇을 더 해야 하는지, 어디서 처리하는지, 왜 필요한지, 끝난 뒤 어디로 돌아와야 하는지를 한 자리에서 보여줘야 합니다.

본 절차와 함께 다른 기관·사이트·보전 절차를 같이 처리해야 하는 화면은 CASE 48을 먼저 붙여 봅니다. 같은 시작 화면이나 배너에서 같이 해야 하는 절차, 처리 기관 또는 연결 사이트, 먼저 또는 함께 해야 하는 이유, 끝난 뒤 돌아올 복귀 경로가 같이 읽히는지 확인하고, 즉시 연락·보호 채널이 더 앞선 문제는 CASE 47, 결과 뒤 별도 신고·의무가 더 핵심이면 CASE 32로 이어 판정합니다.

푸터, 고객센터, 장애인 지원 연락처처럼 상담 채널을 보여주는 영역에서는 채널 이름만 두거나 번호·운영시간·요금을 한 문장에 압축하면 안 됩니다. 무엇을 도와주는 채널인지, 언제 연결되는지, 무료인지까지 같이 보여줘야 사용자가 자기 문제에 맞는 연락처인지 바로 판단할 수 있습니다.

상담 채널이 화면 하단이나 도움말에 흩어져 있어도 누가, 언제, 얼마로 연결되는지 빨리 판단해야 하는 화면은 CASE 50을 먼저 붙여 봅니다. 같은 연락처 영역에서 상담 채널 이름, 상담 대상, 전화번호 또는 연결 경로, 운영시간, 무료·일반 통화요금·추가 서비스 요금 여부가 같이 읽히는지 확인하고, 긴급 연결·즉시 보호 채널이 더 앞선 문제는 CASE 47, 대기·지연 상태 뒤 문의 경로가 더 앞선 문제는 CASE 56으로 이어 판정합니다.

권리 보호, 세금 의무, 상속처럼 한 번 시작하거나 지나가면 되돌리기 어려운 절차는 메뉴 이름만 보여주면 안 됩니다. 버튼을 누르기 전에 어떤 효력이 생기는지, 언제까지 신청·취소·정정할 수 있는지, 무엇이 되돌릴 수 없는지, 대안 절차가 있는지를 같은 영역에서 보여줘야 합니다.

효력·기한·취소 불가 여부 때문에 누르기 전에 다시 판단해야 하는 화면은 CASE 52를 먼저 붙여 봅니다. 같은 시작 화면이나 배너에서 이 절차로 생기는 효력, 신청·취소·정정 기한, 기한 경과 후 또는 취소 불가 결과, 비교할 다른 선택지·대안 절차, 보관해야 할 증빙 또는 다음 확인 경로가 같이 읽히는지 확인하고, 단순 옵션 비교가 더 핵심이면 CASE 34, 결과 뒤 이의·재심사가 더 앞선 문제는 CASE 33으로 이어 판정합니다.

점검, 연계 중단, 일시 오류처럼 지금 이 화면을 사용할 수 없는 상황에서는 `잠시 후 다시`만으로는 부족합니다. 왜 막혔는지, 언제 다시 가능한지, 급하면 어디로 가야 하는지, 중복 처리 여부는 어디서 확인하는지까지 같이 보여줘야 합니다.

지금 막힌 이유와 다시 가능한 시점을 먼저 알아야 하는 화면은 CASE 25를 먼저 붙여 봅니다. 같은 배너나 시작 영역에서 이용 불가 이유, 복구 시각 또는 다음 확인 시각, 대체 경로, 중복 처리 여부 확인 경로가 같이 읽히는지 확인하고, 접수 뒤 오래 기다리는 상태가 더 핵심이면 CASE 56, 기기·브라우저 제약이 더 핵심이면 이용 환경 안내 규칙으로 이어 판정합니다.

PC·모바일·앱마다 가능한 작업이 다르면 진입 뒤에 차단하지 말고, 현재 환경에서 무엇이 되는지와 바꿔야 할 환경을 먼저 보여줘야 합니다. 특히 PC 전용 서비스, 앱 전용 기능, 모바일 제한 화면은 대체 경로를 함께 줘야 합니다.