UX 라이팅 자동 분석 — 공공언어 바로쓰기·행정용어 점검, ViewCheck는 어떻게 접근하고 있나

"신청" 버튼 하나에도 공공언어 원칙이 있다 — 어려운 행정용어·외래어를 자동으로 진단하는 실험 기록

---

들어가며 — "제출"이냐 "신청"이냐, 버튼 한 줄의 무게

공공 웹사이트를 쓰다 보면 이런 버튼 문구를 만난다.

"서식 제출", "입력 완료 후 접수 처리", "민원신청서 登錄"

화면 가운데 이렇게 적혀 있다고 상상해 보자. 이 버튼을 누르면 무슨 일이 생길까? '내 민원이 접수된다'는 걸 알아채는 데 몇 초가 걸릴까? 그리고 이 문구는 누구를 위한 것인가 — 담당자? 시스템? 아니면 민원인?

이것이 UX 라이팅(UX Writing)의 세계다. 표면적으로는 아주 작은 문제처럼 보인다. 버튼 두 글자, 안내문구 한 줄. 그런데 그 두 글자가 사람을 막기도 하고, 그 한 줄이 서비스 전체의 인상을 결정하기도 한다. 특히 공공 웹사이트라면 더욱 그렇다. 어떤 시민이, 어떤 상황에서, 어떤 배경지식을 갖고 그 화면 앞에 앉을지 알 수 없기 때문이다.

대한민국에서는 2009년부터 공공언어를 쉽게 쓰는 정책을 추진해 왔다. 「국어기본법」은 공공기관이 공문서를 일반 국민이 알기 쉬운 용어와 문장으로 써야 한다고 명시하고 있다. 국립국어원은 수십 년에 걸쳐 행정용어 순화 자료를 만들어 왔다. 그럼에도 불구하고 2024년 기준, 공공언어에서 외국어·외래어를 자주 또는 매우 자주 접촉한다는 시민 비율은 77.9%에 달한다(국립국어원 의뢰, 한국리서치 조사, 2023년 말 전국 7,800명 대상). 법도 있고 지침도 있고 가이드도 있는데, 왜 현장은 여전히 어려울까?

ViewCheck는 이 문제를 '측정'과 '자동 진단'의 관점에서 접근하고 있다. 사람이 화면을 하나하나 열어 "이 문구가 어려운 행정용어인가"를 판단하는 대신, 분석 엔진이 웹사이트 전체를 크롤링하며 버튼 라벨·안내문구·오류 메시지에 쓰인 표현을 자동으로 점검하고 개선 권장 표현을 제시하는 것이다. 우리는 이걸 'UX 라이팅 자동 분석'이라 부른다.

아직 완성된 기능이 아니다. 솔직히 말하면, '자동으로 진단한다'는 말이 어느 수준에서 성립하는지를 우리 스스로도 계속 따져보고 있는 단계다. 이 글은 그 실험의 현재 상태, 우리가 참고하고 있는 근거들, 그리고 아직 해결하지 못한 문제들을 있는 그대로 적은 기록이다.

---

공공언어란 무엇인가 — 법과 정책의 배경부터

UX 라이팅을 이야기하기 전에, 한국에서 '공공언어'가 어떤 법적·정책적 맥락에 놓여 있는지를 먼저 정리해 두고 싶다. 이게 단순한 스타일 가이드 수준이 아니라, 법령에 근거한 의무라는 점이 중요하기 때문이다.

「국어기본법」 제14조 제1항은 이렇게 규정한다.

"공공기관등은 공문서를 일반 국민이 알기 쉬운 용어와 문장으로 써야 하며, 어문규범에 맞추어 한글로 작성하여야 한다."

(「국어기본법」, 국가법령정보센터 — https://www.law.go.kr/법령/국어기본법)

여기서 '공공기관등'의 범위는 단순히 중앙정부 기관에 그치지 않는다. 지방자치단체, 공공기관, 그리고 이들이 운영하는 웹사이트까지 포함된다. 즉, 공공 웹사이트의 버튼 문구, 안내 텍스트, 오류 메시지는 원칙적으로 「국어기본법」의 적용 대상이다. '알기 쉬운 용어와 문장'이라는 기준은 법조문에 명시된 의무인 것이다.

이 법에 따라 문화체육관광부와 국립국어원은 오랫동안 공공언어 개선 정책을 추진해 왔다. 그 결과물 중 하나가 「한눈에 알아보는 공공언어 바로 쓰기」(개정판, 2024년)다. 이 자료는 국립국어원 누리집에서 누구나 내려받을 수 있는 공개 지침서로, 어려운 행정용어를 쉬운 우리말로 바꾸는 원칙과 예시를 담고 있다(국립국어원, https://www.korean.go.kr/front/etcData/etcDataView.do?etc_seq=699).

또 국립국어원에는 「알기 쉬운 행정용어」라는 별도 자료집도 있다. 이 자료는 행정 현장에서 자주 쓰이는 어려운 용어들을 수집하고, 각각에 대한 순화어와 설명을 제공한다(국립국어원, https://korean.go.kr/front/etcData/etcDataView.do?mn_id=&etc_seq=638). 예를 들어 '개구부'는 '열린구역'으로, '채묘'는 '종자붙임'으로 바꾸는 식이다. 전문 행정용어 수준이지만, 실제 이런 단어들이 공문서나 웹 안내문에 버젓이 쓰이는 걸 볼 때 이 작업이 얼마나 필요한지를 실감하게 된다.

국립국어원이 2021년에 발간한 연구보고서 「행정문서 표현 개선 및 쉬운 공공언어 쓰기 지침 개발」(https://www.korean.go.kr/front/reportData/reportDataView.do?mn_id=45&report_seq=1122)은 이 문제를 더 체계적으로 파고든다. 행정문서에 쓰이는 표현들이 실제로 얼마나 어려운지, 어떤 유형의 어려움이 있는지를 분석하고, 개선 지침을 제안한 연구다. ViewCheck가 UX 라이팅 분석 규칙을 설계할 때 참고한 자료 중 하나이기도 하다.

2018년 행정안전부 정부혁신조직실이 마련한 「쉽고 바른 공공언어 사용을 위한 공문서 용어 개선 정착 추진계획」은 정부 차원에서 이 문제를 얼마나 심각하게 보고 있는지를 보여준다. 이 문서는 보도자료, 법령, 민원서류 양식과 같이 국민을 대상으로 한 공문서에는 가능한 한 어려운 용어를 쓰지 말도록 하는 내용을 담고 있다.

이처럼 공공언어 개선은 수십 년의 역사를 가진 국가 정책 과제다. 그러나 한 가지 문제가 있다. 이 모든 지침과 정책은 '사람이 직접 글을 검토해서 고친다'는 것을 전제한다. 공공 웹사이트에는 수백 개의 페이지, 수천 개의 텍스트 요소가 있다. 그걸 사람이 하나하나 읽어가며 "이 표현이 어려운가?"를 판단하는 일은, 물리적으로 매우 어렵다. 바로 여기서 자동 분석의 필요성이 생긴다.

---

왜 지금도 어려운 말이 공공 웹을 가득 채우는가

법이 있고 지침이 있는데 왜 현장은 달라지지 않을까. 이 질문을 몇 가지 구조적인 이유로 풀어보려 한다.

첫째, 텍스트를 '만드는' 사람과 '검토하는' 사람이 분리되어 있지 않다. 공공 웹사이트의 콘텐츠는 대부분 각 부서에서 자체적으로 작성한다. 담당자는 자신의 업무 분야를 잘 아는 행정 전문가이지, UX 라이터가 아니다. 전문가일수록 자기 분야의 용어가 '당연히 아는 말'처럼 느껴진다. "담보물건"이라는 단어를 쓸 때, 그게 일반 시민에게 낯선 말이라는 걸 실감하기 어렵다. 이건 담당자의 잘못이 아니라 역할의 구조적 한계다.

둘째, 외부 개발사 중심의 구축 방식. 공공 웹사이트는 대부분 외주 개발사가 구축한다. 개발사는 기능 구현에 집중하고, 버튼 문구 같은 '텍스트'는 발주 기관이 제공하거나 개발자가 관행적으로 쓰던 표현을 그대로 쓴다. "Submit"을 "제출"로 직역하거나, 시스템 메시지를 그대로 노출하거나, 전임 담당자가 쓰던 문구를 그대로 복사하는 식이다. 텍스트에 대한 전문적 검토 단계가 프로세스에 존재하지 않는 것이다.

셋째, 외래어·외국어의 폭발적 증가. 한국리서치가 2023년 말 전국 만 15세~79세 7,800명을 대상으로 실시한 조사(국립국어원 의뢰)에 따르면, 공공언어에서 외국어·외래어를 자주 또는 매우 자주 접촉한다는 응답이 2022년 36.6%에서 2023년 77.9%로 1년 사이에 41.3%p나 급등했다(출처: 뉴시스, 2024년 10월, https://www.newsis.com/view/NISX20241008_0002913479). AI, 플랫폼, 빅데이터, 거버넌스 같은 신조어가 정책 문서와 웹사이트에 무분별하게 쓰이면서 시민의 체감 어려움이 급격히 커진 것이다. 문체부와 국립국어원이 '소버린 AI'를 '독자 인공지능'으로 순화어를 확정한 것처럼(퍼블릭타임스, https://www.public25.com/news/articleView.html?idxno=30797), 새로운 외래어는 계속 생겨나고 순화어 작업은 늘 한발 뒤따라가는 형국이다.

넷째, '말의 의미를 몰라 곤란했던 경험'이 늘고 있다. 같은 연구에서 공공언어의 뜻을 이해하지 못해 곤란을 겪은 비율은 2015년 5.6%에서 2020년 36.3%로 증가했다고 보고되었다. 아이러니한 점은, 이 비율이 고학력자일수록 오히려 높게 나타난다는 것이다. 고학력자들이 공공 웹을 더 적극적으로 이용하기 때문에, 어려운 말을 더 자주, 더 많이 접한다는 해석이 가능하다.

이 네 가지 구조를 보면, "더 쉬운 말로 써주세요"라고 권고하는 것만으로는 한계가 있다는 게 분명해진다. 사람이 체크하기 어렵고, 텍스트에 전문 검토 단계가 없으며, 외래어는 계속 새로 생겨난다. 이 상황에서 자동화된 진단 도구가 들어올 여지가 있다.

---

UX 라이팅이란 무엇인가 — '글쓰기'보다 '설계'에 가까운 일

여기서 잠깐 UX 라이팅이 무엇인지를 정리해 두고 싶다. 공공언어 개선과 UX 라이팅은 결이 겹치지만 같은 개념은 아니기 때문이다.

UX 라이팅(UX Writing)은 사용자가 인터페이스 안에서 읽고 상호작용하는 모든 텍스트를 설계하는 일이다. 버튼 라벨, 오류 메시지, 빈 상태 안내문(empty state), 도움말 텍스트, 로딩 중 문구, 성공·실패 알림, 폼 레이블, 플레이스홀더 텍스트… 화면에 글자가 나타나는 곳이면 어디든 UX 라이팅의 영역이다.

닐슨 노먼 그룹(Nielsen Norman Group, 이하 NN/g)은 UX 라이팅에 대한 입문 FAQ에서 이렇게 정리한다. UX 라이팅은 "제품과 사람 사이의 대화"를 설계하는 일이며, 마케팅 카피나 일반 콘텐츠 라이팅과는 목적이 다르다. 마케팅 카피는 설득하는 것을 목표로 하지만, UX 라이팅은 사용자가 목표를 달성하도록 안내하는 것을 목표로 한다(NN/g, "UX Writing: FAQs from Practitioners", https://www.nngroup.com/articles/ux-writing-faqs/).

NN/g는 또한 가독성(readability)과 스캔 가능성(scannability)이 왜 중요한지를 수십 년에 걸친 연구로 보여줬다. 특히 1997년에 발표된 닐슨과 모크스(Morkes & Nielsen)의 연구는 지금도 UX 라이팅의 고전으로 꼽힌다. 이 연구는 5개의 다른 글쓰기 스타일을 가진 웹사이트를 동일한 사용자들에게 테스트한 결과, 간결하게 쓴 버전은 그렇지 않은 버전보다 사용성이 58% 높았고, 스캔 가능하게 포맷한 버전은 47% 높았으며, 객관적(비홍보성) 언어를 쓴 버전은 27% 높았다. 그리고 이 세 가지를 동시에 적용한 버전은 무려 124% 높은 사용성을 보였다(NN/g, "Concise, SCANNABLE, and Objective: How to Write for the Web", https://www.nngroup.com/articles/concise-scannable-and-objective-how-to-write-for-the-web/).

124%라는 수치는 단순히 "글을 잘 쓰면 좋다"는 수준이 아니다. 텍스트가 사용성에 미치는 영향이 그만큼 크다는 실증이다. 그리고 이건 전문가에게도 동일하게 적용된다. NN/g는 도메인 전문가(specialist)를 대상으로 한 별도 연구에서도 평이한 언어(plain language)를 더 선호한다는 결과를 얻었다. 전문가라도 이해가 빠른 언어를 싫어하지 않는다. 오히려 더 복잡한 개념을 다루기 때문에, 표현 자체가 명확할수록 인지적 부담이 준다(NN/g, "Plain Language For Everyone, Even Experts", https://www.nngroup.com/videos/plain-language-for-experts/).

이 연구들이 공공 웹에 주는 함의는 분명하다. 공공 서비스의 텍스트가 어려우면, 그게 단순히 '불편'의 문제가 아니라 '서비스 이용 포기'로 이어질 수 있다. 민원을 신청하려다 버튼 문구가 헷갈려서 되돌아간 시민, 오류 메시지를 이해하지 못해 몇 번씩 시도하다 포기한 노인 — 이 모든 실패 경험이 UX 라이팅 문제로 귀결된다.

---

GOV.UK가 가르쳐 준 것 — 9세 읽기 수준이 의미하는 것

해외 공공 웹의 사례 중에서 UX 라이팅을 가장 체계적으로 다루는 곳을 하나만 꼽으라면, 영국의 GOV.UK를 말하게 된다.

GOV.UK의 공식 콘텐츠 가이드라인("Content design: planning, writing and managing content - Writing for GOV.UK", https://www.gov.uk/guidance/content-design/writing-for-gov-uk)은 매우 선명한 원칙을 제시한다. 모든 GOV.UK 콘텐츠는 평이한 영어(plain English)로 쓰여야 한다. 그리고 목표 읽기 수준은 9세다.

'9세 읽기 수준'이라는 표현은 종종 오해를 받는다. "어린이용으로 만드나?"라는 반응이 나오기도 한다. 그런데 GOV.UK가 이 수준을 택한 이유는 다르다. 9세 무렵이면 대부분의 사람이 일상적으로 쓰는 약 5,000개의 핵심 어휘를 자동적으로 인식할 수 있게 된다. 이 단어들은 문자를 하나하나 읽는 것이 아니라 '형태'로 즉시 인식된다. 그렇게 익숙한 단어들은 인지 부담 없이 읽힌다는 것이다.

GOV.UK 가이드라인은 또 이렇게 말한다.

"Research shows that 80% of people prefer sentences written in plain English — and the more complex the issue, the greater that preference."

(GOV.UK 콘텐츠 원칙 문서, https://assets.publishing.service.gov.uk/media/5a7c43cded915d7d70d1daf0/GOV.UK_content_principles.pdf)

복잡한 주제일수록, 오히려 쉬운 표현을 원한다는 것이다. 의료, 법적 사안, 세금, 복지 신청처럼 이해관계가 걸린 복잡한 서비스일수록 텍스트가 명확해야 한다. 공공 서비스는 대부분 그런 복잡한 사안을 다룬다.

GOV.UK는 구체적인 대체 표현도 제시한다. "purchase" 대신 "buy", "assist" 대신 "help", "approximately" 대신 "about" 등이다. 작은 변화 같지만, 이런 단어들이 화면 전체에 걸쳐 일관되게 적용될 때 사용자가 느끼는 서비스의 신뢰도와 명확성이 달라진다.

한국 공공 웹의 맥락으로 번역해 보면 이렇다. "접수 처리"는 "신청"으로, "서식 제출"은 "보내기"로, "개인 정보 수집·이용 동의 확인서 서명"은 "동의하기"로 바꾸는 것이 영국의 GOV.UK 방식이다. 표현은 단순해지지만 의미는 오히려 명확해진다.

미국도 비슷한 방향을 법으로 정했다. 2010년에 서명된 「Plain Writing Act of 2010」은 연방 기관이 "국민이 이해하고 사용할 수 있는 명확한 정부 문서"를 작성하도록 의무화했다. 이 법의 집행을 위한 「Plain Language Action and Information Network(PLAIN)」이 운영되고 있으며, 가이드라인은 전문 기술 용어를 피하고, 짧고 명확하게 쓰고, 수동태 대신 능동태를 쓰도록 권고한다(U.S. Digital.gov, "An introduction to plain language", https://digital.gov/resources/an-introduction-to-plain-language).

흥미로운 점은, 이 미국 가이드라인이 웹에서는 특히 더 짧게 써야 한다고 강조한다는 것이다. 사람들은 종이 문서보다 웹에서 25% 더 느리게 읽으며, 따라서 웹 문서를 종이 문서의 50%로 줄여야 한다는 것이다. 공공 웹사이트의 길고 빽빽한 안내문이 왜 문제가 되는지를 수치로 설명해 준다.

---

KRDS는 UX 라이팅을 어떻게 다루나

대한민국의 KRDS(KoRea Design System)는 디자인 토큰, 컴포넌트, 패턴 위주로 알려져 있다. 그렇다면 KRDS는 UX 라이팅에 대해서는 어떤 입장을 갖고 있을까?

KRDS 공식 사이트(https://www.krds.go.kr/)와 디지털 정부서비스 UI/UX 가이드라인(행정안전부, 2024년 2월 배포)을 살펴보면, KRDS는 버튼, 입력창, 팝업, 알림 등 각 컴포넌트에 대해 사용 맥락과 텍스트 작성 원칙을 함께 제시하고 있다. 예를 들어 버튼 컴포넌트에서는 라벨이 행동을 명확히 표현해야 하며, 되도록 동사형으로 쓰도록 권고한다. 모달 다이얼로그에서는 확인·취소 버튼의 텍스트가 직관적이어야 한다는 원칙을 다룬다.

KRDS의 서비스 패턴(SP) 영역은 특히 UX 라이팅과 연결점이 많다. 로그인 화면, 검색 화면, 민원 신청 화면, 정책 안내 화면 — 이런 서비스 흐름에서 사용자를 안내하는 텍스트가 어떻게 설계되어야 하는지를 패턴으로 정의하고 있기 때문이다. 오류 메시지는 무엇이 잘못됐는지와 어떻게 고쳐야 하는지를 모두 담아야 한다는 원칙, 필수 입력 항목의 표시 방식, 도움말 텍스트의 위치와 길이 같은 것들이 KRDS SP 규칙 안에 녹아 있다.

ViewCheck가 관리하는 KRDS 846규칙 중 기본 패턴(BP) 108개, 서비스 패턴(SP) 172개에는 이런 UX 라이팅과 직결된 규칙들이 포함된다. 예를 들어 폼 제출 버튼의 텍스트가 행동을 명확히 표현하는지, 오류 안내 메시지가 존재하는지와 그 내용이 사용자가 이해할 수 있는 형식인지, 빈 상태(empty state) 화면에 안내 텍스트가 있는지 같은 것들이다. 이런 규칙들은 '텍스트가 있는가/없는가'의 구조적 판정과 '텍스트가 어려운가/쉬운가'의 내용적 판정이 뒤섞여 있어, 자동 분석의 설계가 쉽지 않다.

---

ViewCheck UX 라이팅 분석 — 무엇을 어떻게 보나

이제 ViewCheck가 실제로 어떻게 UX 라이팅을 분석하는지를 이야기할 차례다. 다시 한번 강조하지만, 이 기능은 아직 연구·실험 단계이고, 모든 문제를 해결했다고 말할 수 없다. 그 솔직함 위에서 설명한다.

ViewCheck의 UX 라이팅 분석은 크게 세 가지 층위로 접근한다.

층위 1: 구조적 텍스트 요소 존재 여부

가장 기본적인 층위다. 화면에 있어야 할 텍스트 요소가 있는가를 본다. 버튼에 라벨이 없거나, 폼 입력창에 레이블이 없거나, 이미지에 대체 텍스트가 없거나, 오류 메시지가 없는 경우다. 이건 DOM 구조를 분석하면 자동으로 판정할 수 있다. KRDS 846규칙 중 CP(컴포넌트) 및 BP(기본패턴) 카테고리에서 이런 규칙들을 다룬다.

층위 2: 행정용어·어려운 표현 패턴 매칭

두 번째 층위는 텍스트의 '내용'으로 들어간다. 국립국어원의 행정용어 순화 목록, 공공언어 바로쓰기 지침, 그리고 실제 공공 웹에서 수집된 어려운 표현들을 기반으로, 분석 엔진이 버튼 라벨·안내문구·오류 메시지에 쓰인 표현을 스캔한다. 순화 대상으로 분류된 표현이 발견되면 이를 '주의 필요' 항목으로 표시하고, 대체 표현을 함께 제시한다.

예를 들어 이런 것들이다.

현재 표현	유형	권장 표현
접수 처리 완료	행정용어	신청이 완료되었습니다
서식 제출	행정용어	신청하기 / 보내기
개인정보 수집·이용 동의서 서명 확인	복합 행정용어	동의하기
오류 발생	시스템 메시지	다시 시도해 주세요
해당 없음	행정용어	적용 안 됨
업로드	외래어	올리기
다운로드	외래어	내려받기
스캔	외래어	검색 / 읽기
로그인	외래어	로그인 (이미 표준어로 정착)

마지막 '로그인'처럼 이미 일상 언어로 정착한 외래어는 굳이 바꾸라고 하지 않는다. 언어 순화는 모든 외래어를 한국어로 바꾸는 게 목적이 아니라, 국민의 이해를 어렵게 만드는 표현을 명확하게 바꾸는 것이 목적이기 때문이다.

층위 3: LLM 기반 맥락 분석

세 번째 층위는 가장 어렵고 아직 실험 단계인 부분이다. 패턴 매칭으로는 잡을 수 없는 어려운 표현들이 있다. 예를 들어 "전산 오류로 인한 처리 불가 상태 발생 시 재시도 바랍니다"처럼, 단어 하나하나는 각각 쓰이는 말이지만 문장 전체가 어렵고 딱딱한 경우다. 이런 건 LLM(대규모 언어 모델)이 문장 전체의 맥락을 보고 판단할 때 더 잘 처리된다.

ViewCheck는 KRDS 846규칙 판정에서 DOM이 판정한 결과를 AI가 뒤집지 않는다는 원칙을 갖고 있다. UX 라이팅의 세 번째 층위에서도 같은 원칙이 적용된다. DOM 구조 분석(층위 1)과 패턴 매칭(층위 2)이 이미 판정한 것은 LLM이 변경하지 않는다. LLM은 두 층위가 처리하지 못한 맥락적 판단에만 개입한다. 그리고 LLM이 판단할 때는 반드시 그 근거를 함께 제시한다 — 공공언어 바로쓰기 원칙의 어떤 기준에 따라 이 문장이 어렵다고 판단했는지를.

---

---

버튼 라벨 분석 — 가장 작고 가장 중요한 텍스트

UX 라이팅 분석에서 가장 먼저, 그리고 가장 집중적으로 보는 곳은 버튼 라벨이다. 이유는 단순하다. 버튼은 사용자가 '행동'을 결정하는 순간에 읽는 텍스트이기 때문이다.

NN/g의 연구에 따르면 사용자는 웹 페이지의 텍스트 중 평균 20~28%만 읽는다. 나머지는 스캔하거나 건너뛴다. 그런 스캔 행동 안에서 거의 확실하게 읽히는 것이 버튼이다. 무언가를 하려는 사람은 '할 수 있는 버튼'을 찾아 화면을 훑고, 버튼을 발견하면 그 라벨을 읽고 누를지 말지를 결정한다. 이 짧은 순간에 버튼 라벨이 명확하지 않으면, 사용자는 멈추고 생각하고, 경우에 따라 포기한다.

ViewCheck가 수집한 실제 공공 웹사이트 버튼 라벨들을 보면, 몇 가지 반복 패턴이 보인다.

패턴 1: 명사형 + 처리·완료

• "신청서 제출" → 권장: "신청하기"
• "민원 접수 처리" → 권장: "접수하기" 또는 "신청하기"
• "작업 취소 처리" → 권장: "취소하기"

이 패턴은 '행위'를 표현해야 할 버튼에 행정 문서식 명사구를 쓰는 경우다. "제출", "처리", "완료" 같은 단어들이 뒤에 붙으면, 버튼이 아니라 공문서 항목처럼 느껴진다. KRDS의 버튼 컴포넌트 원칙도 버튼 라벨은 동사형으로 행동을 명확히 표현해야 한다고 규정한다.

패턴 2: 시스템·개발자 중심 용어

• "Submit" (영문 그대로) → 권장: "보내기" 또는 "신청하기"
• "저장 성공" / "에러 발생" → 권장: "저장되었습니다" / "다시 시도해 주세요"
• "NULL 값 오류" → 권장: "입력하지 않은 항목이 있습니다"

시스템 메시지를 사용자 메시지로 번역하지 않은 채 그대로 노출하는 경우다. 개발 과정에서 백엔드 오류 코드가 그대로 화면에 나타나는 일은 공공 웹에서 드물지 않게 발생한다. 이런 표현들은 패턴 매칭으로 비교적 쉽게 잡을 수 있다.

패턴 3: 한자어·외래어 혼재

• "인터넷 뱅킹 서비스 이용 동의" → 권장: "인터넷 뱅킹 이용 동의"
• "온라인 플랫폼 서비스 개인정보처리방침 확인" → "개인정보 처리 방침 확인"
• "디지털 전환 프로세스 진행 중" → "처리 중" 또는 "진행 중"

플랫폼, 프로세스 같은 외래어가 행정 문서식 한자어와 결합해 더욱 어렵게 느껴지는 경우다. 단어들을 쪼개 보면 각각은 아는 말이지만, 이렇게 길게 연결되면 한 번에 의미를 파악하기 어렵다.

패턴 4: 이중 부정·조건부 안내

• "개인정보 수집에 동의하지 않으시면 서비스 이용이 불가합니다" → 권장: "동의하지 않으면 서비스를 이용할 수 없습니다"
• "해당 항목 미입력 시 처리 불가" → 권장: "이 항목을 입력해야 합니다"

이중 부정과 조건부 문장은 독자가 한 번 더 머릿속에서 뒤집어야 이해되는 구조다. 특히 동의 여부를 묻는 화면에서 이런 표현이 나오면, 사용자가 선택에 혼란을 겪을 수 있다.

---

오류 메시지 분석 — 가장 중요한 순간에 쓰이는 글

UX 라이팅에서 버튼 라벨만큼 중요한 것이 오류 메시지다. 오류 상황은 사용자가 가장 스트레스를 받는 순간이다. 그 순간에 화면에 나타나는 글이 문제를 명확히 설명하고 해결 방법을 알려주면 사용자는 계속할 수 있다. 그렇지 않으면 포기한다.

KRDS의 기본 패턴(BP) 규칙 중에는 오류 처리와 관련된 항목들이 있다. 오류 메시지는 무엇이 잘못됐는지(what)와 어떻게 고쳐야 하는지(how)를 모두 담아야 한다는 것이 핵심 원칙이다.

ViewCheck가 분석하며 발견한 오류 메시지 유형들을 보면, 이 원칙에서 벗어난 패턴이 반복된다.

"오류가 발생했습니다." — 무엇이 오류인지, 어떻게 해야 하는지를 전혀 알려주지 않는다. 이건 메시지가 아니라 사실 통보에 가깝다. 사용자 입장에서는 "그래서 나는 뭘 해야 하나요?"라는 질문만 남는다.

"입력값이 올바르지 않습니다." — 어떤 입력값이, 왜 올바르지 않은지를 말해주지 않는다. 폼에 10개 항목이 있을 때, 어느 항목이 문제인지를 모르면 사용자는 전체를 다시 확인해야 한다.

"서버 오류: 500 Internal Server Error" — 시스템 오류 코드를 그대로 노출한다. 일반 시민이 이 메시지를 보고 무엇을 해야 할지 알 수 없다.

"세션이 만료되었습니다. 재로그인 바랍니다." — 'session', '만료'는 기술 용어에 가깝다. "오랫동안 사용하지 않아 연결이 끊겼습니다. 다시 로그인해 주세요."처럼 풀어 쓸 수 있다.

ViewCheck의 UX 라이팅 분석은 이런 오류 메시지 패턴을 자동으로 수집하고, KRDS BP 규칙에 비추어 구조적으로 문제가 있는지를 판정한다. "what이 없는 오류 메시지", "how가 없는 오류 메시지"는 규칙 위반으로 분류된다. 그리고 어떻게 개선할 수 있는지를 권장 형식과 함께 제시한다.

---

---

안내문구 분석 — 사용자를 안내하는 텍스트의 조건

버튼과 오류 메시지 다음으로 중요한 것이 안내문구다. 폼 작성을 돕는 도움말 텍스트, 각 서비스 단계에서 사용자에게 다음 행동을 알려주는 안내, 빈 상태(empty state)에서 "아직 내용이 없습니다"를 알려주는 텍스트 등이 여기에 해당한다.

안내문구는 사용자가 '어디에 있고, 무엇을 해야 하는지'를 명확히 알 수 있게 해주는 방향 표지판 같은 역할을 한다. 공공 웹에서는 이 방향 표지판이 행정 문서 형식으로 쓰인 경우가 많다.

실제 예시를 보자.

민원 신청 안내문구 (개선 전):

"본 민원은 관련 법령에 의거 처리기한 내 처리 원칙에 따라 접수일로부터 영업일 기준 5일 이내 처리 완료를 목표로 하고 있으나, 구비서류 미비 및 행정 사항 검토 등으로 인해 처리가 지연될 수 있음을 사전에 고지하는 바입니다."

이 문장은 한 호흡에 읽기 어렵다. "관련 법령에 의거", "처리기한 내 처리 원칙에 따라", "접수일로부터 영업일 기준", "구비서류 미비 및 행정 사항 검토" — 각각의 요소는 이해되지만 한 문장 안에 다 들어가 있어 파악이 어렵다.

개선 후 제안:

"이 민원은 접수 후 영업일 기준 5일 이내에 처리됩니다. 서류가 부족하거나 추가 확인이 필요한 경우, 처리가 늦어질 수 있습니다."

두 문장으로 나누고, 수동적 법률 문체를 능동적 안내문으로 바꿨다. 의미는 같지만 훨씬 빠르게 읽힌다.

ViewCheck의 분석 엔진은 이런 안내문구를 여러 기준으로 평가한다. 문장 길이(지나치게 긴 단일 문장), 수동태 남용, 이중 부정, 한자어·외래어 밀도, 그리고 행정 문서식 투의 특정 표현 패턴들이다. 각 기준에서 주의 필요 수준을 판정하고, 개선 방향을 제시한다.

완전히 자동화된 '완성된 개선안'을 생성하는 것은 아직 어렵다. 텍스트의 의미와 맥락을 완전히 이해하지 못한 상태에서 자동으로 문장을 바꾸면 오히려 의미가 훼손될 수 있기 때문이다. 지금 단계에서 ViewCheck의 접근은 "이 부분이 어렵다, 이런 이유로, 이런 방향으로 개선을 고려해 보라"는 신호를 주는 것에 가깝다. 최종 판단과 개선은 담당자가 한다.

---

다중 페이지 UX 라이팅 분석 — 한 페이지로는 부족한 이유

ViewCheck는 처음부터 다중 페이지 분석을 기본값으로 설계했다. UX 라이팅 분석에서도 이 원칙은 똑같이 적용된다.

왜 다중 페이지가 중요할까? 공공 웹사이트에서 UX 라이팅 문제는 특정 페이지에 집중되는 경향이 있다. 메인 페이지는 상대적으로 잘 다듬어져 있는 경우가 많다. 눈에 잘 띄고, 대외 이미지와 직결되는 페이지이기 때문이다. 그런데 민원 신청 단계, 오류 화면, 빈 상태 화면, 완료 확인 화면처럼 '흐름의 중간과 끝'에 있는 페이지들은 상대적으로 덜 다듬어진 경우가 많다. 바로 그 페이지들이 시민이 실제로 어려움을 겪는 곳이다.

예를 들어 어떤 지자체 사이트를 분석했더니, 메인 페이지의 버튼 라벨들은 동사형으로 잘 쓰여 있었지만, 민원 신청서 페이지의 오류 메시지들은 전부 시스템 메시지 그대로였다는 결과가 나왔다. 메인만 보면 "이 사이트는 UX 라이팅이 잘 되어 있네"라는 결론이 나왔겠지만, 실제로 민원을 신청하는 시민이 마주하는 화면은 달랐다.

ViewCheck의 다중 페이지 분석은 이런 불일치를 잡아낸다. 사이트 전체에서 UX 라이팅 문제가 어느 페이지 유형에서 집중적으로 나타나는지, 어떤 패턴이 반복되는지를 집계하고 시각화한다. 담당자는 "우리 사이트 어디에서 UX 라이팅이 가장 시급한가"를 한눈에 볼 수 있다.

이 집계 과정에서 우리가 주의하는 것이 하나 있다. UX 라이팅 문제는 성격상 "페이지 하나라도 이 문제가 있으면 사이트 전체 문제"로 보는 OR 로직보다, "어느 페이지에서 얼마나 자주 나타나는지"의 빈도와 분포로 보는 게 더 유용하다는 점이다. 버튼 라벨 문제가 20개 페이지 중 3개에 나타난다면, 나머지 17개가 아니라 3개를 먼저 고치는 게 맞다. 전체 집계와 페이지별 상세를 함께 보여주는 이유가 여기에 있다.

---

"자동"의 한계 — 언어를 기계가 판단할 때의 어려움

이쯤에서 솔직한 이야기를 해야 할 것 같다. UX 라이팅의 자동 분석은 다른 분석 영역에 비해 훨씬 어렵다. 왜 그럴까?

첫째, 언어는 맥락에 따라 달라진다. 같은 단어가 어떤 맥락에서는 적절하고, 어떤 맥락에서는 부적절하다. "실행"이라는 단어는 프로그램을 돌리는 맥락에서는 자연스럽지만, 민원 신청의 완료 버튼에 쓰이면 어색하다. 단어 자체만으로는 어려운지 쉬운지를 판단할 수 없고, 문장 전체, 그리고 그 문장이 놓인 화면의 맥락까지 봐야 한다.

둘째, '어렵다'의 기준이 대상에 따라 다르다. 20대 대졸 청년에게 쉬운 말이 65세 이상 어르신에게는 어려울 수 있다. 행정에 익숙한 공무원에게 당연한 용어가 처음 민원을 신청하는 시민에게는 낯설 수 있다. '쉬운 언어'의 기준 자체가 대상에 따라 달라지는 것이다. GOV.UK가 '9세 읽기 수준'이라는 명확한 기준을 택한 이유도 여기에 있다 — 모호한 '쉬운'이 아니라 측정 가능한 기준으로 정한 것이다.

셋째, 오탐(false positive)의 위험. 자동 분석이 "이 표현이 어렵다"고 판정했는데, 실제로는 그 표현이 해당 서비스에서 반드시 필요한 전문 용어인 경우가 있다. 예를 들어 의료 민원 서비스에서 의학 용어를 쓰는 것은 어쩔 수 없을 수 있다. 이런 경우 자동 판정이 오히려 혼란을 줄 수 있다.

이 세 가지 한계 때문에, ViewCheck의 UX 라이팅 분석은 결과를 '판정'보다는 '신호(signal)'로 제시한다. "이 표현이 어렵다고 확정한다"가 아니라, "이 표현이 어려울 수 있다, 검토해 보라"는 방식이다. 최종 판단은 사람이 한다. 우리가 하는 건 그 판단을 내릴 수 있도록 빠르게 후보를 수집하고 근거를 제시하는 일이다.

---

KRDS 846규칙과 UX 라이팅의 연결 — 구조와 내용 사이

ViewCheck의 24기능 분석 카드 중 하나인 'UX 라이팅'은 KRDS 846규칙의 특정 카테고리와 직접 연결된다.

KRDS 846규칙 중 기본 패턴(BP) 108개에는 이런 규칙들이 있다.

• 폼 입력 오류 안내 메시지 존재 여부 및 형식(what + how를 포함하는지)
• 버튼 라벨의 행동 명확성(동사형 여부)
• 필수 항목 표시 일관성
• 빈 상태(empty state) 안내 텍스트 존재 여부
• 확인·취소 버튼의 의미 명확성
• 성공·실패 피드백 메시지 존재 여부

서비스 패턴(SP) 172개에는 이런 것들이 있다.

• 로그인 화면 오류 안내 문구 형식
• 검색 결과 없음 화면의 안내 문구 존재 여부
• 신청 완료 화면에서 다음 단계 안내 여부
• 정책 안내 화면에서 핵심 내용 먼저 제시 여부

이 규칙들은 텍스트가 '있는가/없는가'(구조적 판정)와 텍스트가 '적절한 형식인가'(내용적 판정)의 두 축을 갖는다. 구조적 판정은 DOM 분석으로 자동화 가능하지만, 내용적 판정은 텍스트의 실제 내용을 봐야 하므로 패턴 매칭 또는 LLM 분석이 필요하다.

UX 라이팅 분석 카드는 이 BP·SP 규칙들의 판정 결과와, 텍스트 내용에 대한 패턴 분석 결과를 통합해 보여준다. 담당자는 "이 화면에서 오류 메시지 형식이 규칙을 위반했고, 그 메시지에 쓰인 표현이 어렵다"는 두 레이어의 문제를 한 화면에서 확인할 수 있다.

이 통합 뷰가 의미 있는 이유는 현장에서 이 두 문제가 항상 함께 나타나기 때문이다. 오류 메시지가 없는 페이지(구조 문제)와, 오류 메시지는 있지만 시스템 코드를 노출하는 페이지(내용 문제)는 사실상 같은 류의 문제다 — 사용자가 오류 상황에서 도움을 받지 못한다는 것. 두 개를 분리해서 보면 각각 별개의 문제처럼 보이지만, 함께 보면 "이 사이트는 오류 처리 UX가 취약하다"는 패턴이 보인다.

---

---

'어렵다'를 어떻게 측정하나 — 가독성 지표의 가능성과 한계

UX 라이팅 분석에서 빠질 수 없는 주제가 가독성 측정이다. "이 텍스트가 얼마나 어려운가"를 수치로 표현할 수 있을까?

영어권에서는 플레시-킨케이드 읽기 수준(Flesch-Kincaid Grade Level), 건닝 포그 지수(Gunning Fog Index), SMOG 지수 같은 가독성 공식들이 오랫동안 쓰여 왔다. 이 공식들은 문장 길이, 단어 길이, 음절 수 같은 텍스트 구조적 특성을 수치화한다. GOV.UK의 콘텐츠 팀도 Flesch 점수를 참고한다.

한국어의 가독성 측정은 영어보다 훨씬 복잡하다. 한국어는 단어 경계가 영어처럼 공백으로 명확히 구분되지 않고, 음절 구조가 다르며, 조사·어미가 발달해 있어 '단어 길이'나 '음절 수'만으로는 어려움을 포착하기 어렵다. 한자어 밀도, 외래어 비율, 피동형·사동형 남용 여부, 명사구 연속 사용 등을 복합적으로 봐야 한다.

국립국어원이 2021년 발간한 「행정문서 표현 개선 및 쉬운 공공언어 쓰기 지침 개발」 연구는 이 문제를 다각도로 분석한다. 이 연구는 행정 문서의 어려움이 어디서 오는지를 분류한다. 어휘 수준(한자어·외래어·전문용어의 높은 밀도), 문장 구조 수준(과도하게 긴 문장, 복잡한 내포절), 담화 수준(불필요한 반복, 비논리적 전개)으로 나눠서 본다.

ViewCheck는 한국어 텍스트의 어려움을 측정하기 위해 이 연구의 분류 체계를 참고해 몇 가지 지표를 적용하고 있다.

• 어휘 난이도 지표: 국립국어원의 순화 대상 행정용어 목록, 자주 쓰이는 어려운 한자어 목록과의 매칭 비율
• 외래어·외국어 밀도: 순화어 기준으로 분류된 외래어 표현이 전체 텍스트에서 차지하는 비율
• 문장 길이: 단위 텍스트(버튼 라벨, 오류 메시지, 안내문구) 평균 글자 수
• 수동태·이중 부정 패턴: 규칙 기반 패턴 탐지

이 지표들이 "이 텍스트의 어려움 점수는 X점"처럼 단일 숫자로 완벽히 표현될 수 없다는 건 잘 알고 있다. 각 지표는 특정 유형의 어려움을 잡는 데는 유용하지만, 언어의 맥락성을 완전히 반영하지는 못한다. 그래서 지금은 지표별 결과를 개별적으로 보여주고, 각각에 해당하는 구체적인 텍스트 예시를 함께 제시하는 방식을 택하고 있다. 숫자 하나보다, "이 문장이 이 기준으로 어렵다"는 구체적인 사례가 담당자에게 더 직접적으로 유용하기 때문이다.

---

개선 권장 표현 — 단순 경고가 아니라 대안 제시

UX 라이팅 분석이 단순히 "이게 어렵습니다"를 나열하는 것으로 끝나면 담당자에게 실제로 도움이 되지 않는다. ViewCheck는 문제를 지적하는 동시에, 가능한 경우 개선 권장 표현을 함께 제시하려 한다.

권장 표현은 주로 두 가지 소스에서 온다.

소스 1: 국립국어원 순화어 목록

국립국어원은 수십 년간 어려운 행정용어를 쉬운 우리말로 순화한 자료를 축적해 왔다. 문화체육관광부는 행정분야 전문용어 표준화 고시(312개)와 순화어(21,295개)를 제공하고 있다. 이 목록은 "정착 과정"에서 어려운 용어와 권장 대체어를 1:1로 매핑한 데이터로, 패턴 매칭 기반의 권장 표현 제시에 직접적으로 활용할 수 있다.

예를 들어 "행락철"은 "나들이철"로, "채묘"는 "종자붙임"으로, "무의도서"는 "의료기관 없는 섬"으로 순화하는 식이다. 이런 매핑 데이터가 있으면, 공공 웹 텍스트에서 해당 표현이 발견됐을 때 자동으로 대체 표현을 제시할 수 있다.

소스 2: KRDS 컴포넌트 텍스트 원칙

KRDS 가이드라인에는 각 컴포넌트의 텍스트가 어떻게 쓰여야 하는지에 대한 원칙이 있다. 버튼은 동사형으로, 오류 메시지는 what+how 형식으로, 빈 상태는 긍정적 안내형으로 — 이런 원칙들은 구체적인 권장 표현 형식을 도출하는 데 쓰인다.

소스 3: 분석 과정에서 수집된 우수 사례

ViewCheck가 공공 웹사이트 수백 곳을 분석하며 수집한 데이터 안에는 잘 쓰인 버튼 라벨, 명확한 오류 메시지, 친절한 안내문구의 사례들이 있다. 이 우수 사례들이 같은 맥락에서 다른 사이트에 권장 참고 표현으로 쓰일 수 있다.

다만 여기서도 중요한 제약이 있다. 자동으로 생성된 권장 표현은 반드시 담당자의 검토를 거쳐야 한다. 텍스트는 그 서비스의 법적·행정적 맥락과 맞아야 하고, 때로는 정확성을 위해 일정 수준의 전문 용어가 필요할 수 있다. ViewCheck가 제시하는 권장 표현은 '참고 방향'이지 '교체 명령'이 아니다.

---

실제 분석 사례 — 한 공공 웹사이트의 UX 라이팅 진단

ViewCheck로 실제 공공 웹사이트를 분석하면 UX 라이팅 관점에서 어떤 결과가 나오는지, 익명으로 처리한 사례를 통해 보여주려 한다. (실제 데이터를 익명 처리한 것으로, 구체적인 기관명과 URL은 밝히지 않는다.)

사이트 A: 광역 지자체 민원 포털

• 분석 페이지 수: 47페이지
• 발견된 UX 라이팅 주의 표현: 버튼 라벨 12건, 오류 메시지 23건, 안내문구 31건
• 주요 패턴:
  • 버튼 라벨의 73%가 명사형 (동사형 권장)
  • 오류 메시지 중 'what 없음' 17건, 'how 없음' 19건
  • 안내문구 평균 길이 84자 (권장 40자 이내)
  • 외래어·외국어 표현 8건 (순화 가능 6건, 정착어 2건)

이 결과를 보면 이 사이트의 UX 라이팅 약점이 어디에 있는지가 보인다. 버튼 라벨을 동사형으로 바꾸는 것이 우선 과제이고, 오류 메시지에 'what'과 'how'를 추가하는 것이 그다음이다. 안내문구를 더 짧게 나누는 것도 필요하다.

사이트 B: 중앙부처 정책 안내 사이트

• 분석 페이지 수: 112페이지
• 발견된 UX 라이팅 주의 표현: 버튼 라벨 5건, 오류 메시지 4건, 안내문구 67건
• 주요 패턴:
  • 안내문구에서 이중 부정 표현 29건
  • 외래어·외국어 표현 41건 (순화 가능 33건)
  • 정책 용어 중 순화 목록에 있는 표현 18건
  • 단일 문장 100자 초과 26건

이 사이트는 버튼과 오류 메시지는 비교적 잘 되어 있지만, 안내문구에서 이중 부정과 외래어 문제가 집중된다. 정책 사이트 특성상 외래어 신조어 사용이 많고, 정책 설명 문구가 긴 것이 주요 원인이다.

두 사이트의 결과가 다른 것은 서비스 유형이 다르기 때문이다. 민원 포털은 '행동'을 요구하는 UI가 많아 버튼·오류 문제가 두드러지고, 정책 사이트는 '설명'이 많아 안내문구·외래어 문제가 두드러진다. UX 라이팅 분석이 사이트 유형별로 다른 패턴을 보이는 이유다.

---

공공언어 개선이 서비스 품질에 미치는 영향 — 측정의 어려움

공공언어 바로쓰기가 중요하다는 건 직관적으로 납득된다. 그런데 "어려운 말을 쉬운 말로 바꿨더니 민원 신청 완료율이 X% 높아졌다"는 식의 인과관계를 직접 측정하는 것은 어렵다. 왜 어려울까?

공공 웹사이트에서는 A/B 테스트를 하기 어렵다. 같은 서비스를 두 버전으로 나눠 일부 시민에게는 어려운 말을, 다른 시민에게는 쉬운 말을 보여주는 실험은 현실적·윤리적으로 어렵다. 그리고 서비스 완료율은 텍스트만의 영향이 아니라, UI 설계, 프로세스 복잡도, 서버 성능 등 수많은 요소의 합이다.

NN/g의 124% 사용성 향상 연구는 통제된 실험실 환경에서 나온 결과다. 실제 공공 서비스에서도 비슷한 효과가 나타날 가능성은 높지만, 그 수치를 그대로 공공 웹에 대입하는 건 과학적으로 정확하지 않다.

국립국어원이 발간한 「공공언어 개선의 정책효과 조사 연구」(kplain.kr)는 이 문제를 정책적 시각에서 접근한다. 공공언어 개선이 국민의 이해도와 만족도에 영향을 미친다는 설문 기반의 간접 증거를 제시하지만, 구체적인 서비스 지표(완료율, 이탈율)와의 직접 연결은 어렵다고 인정한다.

ViewCheck도 같은 한계를 갖고 있다. UX 라이팅 분석 결과가 "이렇게 개선하면 민원 완료율이 X% 높아집니다"라고 예측하는 것은 현재 단계에서 할 수 없다. 우리가 할 수 있는 건 "공공언어 원칙과 KRDS 텍스트 기준에 비추어, 이 텍스트가 얼마나 어렵고 어떻게 개선될 수 있는지"를 진단하는 것이다. 그 진단이 실제로 어떤 효과로 이어지는지는, 개선을 실행한 기관이 직접 측정해야 하는 영역이다.

---

담당자가 UX 라이팅 분석 결과를 실제로 쓰려면

분석 결과가 나왔다. 그다음은 뭘 해야 할까? 실무 담당자 입장에서 이 결과를 어떻게 활용하면 좋을지를 생각해 봤다.

1단계: 우선순위 결정

버튼 라벨, 오류 메시지, 안내문구 중 어디서 문제가 가장 많고 가장 심각한지를 본다. 사용자가 가장 자주 마주치는 화면, 그리고 이탈이 가장 자주 일어나는 화면에서 먼저 고치는 것이 효율적이다.

2단계: 외주 개발사와 협의

많은 공공 웹사이트는 외주 개발사가 유지보수 중이다. UX 라이팅 분석 결과를 개발사와 공유할 때, "이 버튼 문구를 이렇게 바꿔주세요"처럼 구체적인 요청을 할 수 있어야 효과적이다. ViewCheck의 결과는 어느 페이지의 어느 요소에서 어떤 문제가 있는지를 구체적으로 제시하기 때문에, 이 요청을 만드는 데 직접 활용할 수 있다.

3단계: 개선 전후 기록

개선을 하기 전과 후를 각각 분석해 비교하는 것이 권장된다. "개선 전 주의 표현 67건, 개선 후 31건"처럼 수치로 변화를 보여주면 담당자로서 보고 자료를 만들 때 활용할 수 있다.

4단계: 국어책임관과 협력

「국어기본법」에 따라 공공기관에는 '국어책임관 제도'가 운영된다. 국어책임관은 공공기관에서 사용되는 문서나 보도자료를 쉽고 명확한 우리말로 작성하도록 점검하고 개선하는 역할이다. ViewCheck의 UX 라이팅 분석 결과를 국어책임관에게 공유하면, 보다 전문적인 언어 개선 작업으로 이어질 수 있다.

5단계: 정기적 재분석

공공 웹사이트는 콘텐츠가 계속 바뀐다. 새로운 정책이 추가되고, 새로운 페이지가 생겨난다. 한 번 개선했다고 끝이 아니라, 주기적으로 UX 라이팅을 재진단하는 것이 필요하다. ViewCheck의 다중 페이지 분석은 이런 정기 진단에도 활용될 수 있다.

---

---

공공언어와 디지털 접근성 — 겹치는 영역, 겹치는 과제

UX 라이팅과 접근성(accessibility)은 종종 별개의 과제처럼 다뤄지지만, 실제로는 깊이 겹친다.

디지털 접근성의 핵심 목표 중 하나는 '인지 접근성(cognitive accessibility)'이다. 인지 장애가 있거나, 읽기 능력이 낮거나, 한국어가 모국어가 아닌 사람도 공공 서비스를 이용할 수 있어야 한다는 것이다. WCAG(Web Content Accessibility Guidelines) 2.2와 이를 한국화한 KWCAG 2.2에는 이해 가능성(Understandable)이라는 원칙이 있고, 여기에는 '읽기 쉬운 수준'과 '예측 가능한 동작'에 관한 기준이 포함된다.

ViewCheck의 접근성 분석과 UX 라이팅 분석은 이 겹치는 지점에서 서로를 보완한다. 접근성 관점에서 "이 버튼에 ARIA 라벨이 없다"는 구조 문제를 잡았을 때, UX 라이팅 관점에서 "그 버튼의 보이는 텍스트도 어렵다"는 내용 문제를 함께 보여줄 수 있다. 구조와 내용 두 축에서 동시에 접근성 문제를 진단하는 것이다.

이 시너지는 특히 고령 사용자와 장애인을 위한 공공 서비스에서 중요하다. 화면 낭독기를 쓰는 시각장애인에게 "ARIA 라벨이 있지만 그 라벨이 어려운 행정용어"라면, 기술적 접근성은 확보됐지만 실제 이용 가능성은 낮다. 기술적 접근성과 언어적 접근성이 함께 높아져야 진짜 접근성이 된다.

---

다음 단계로 — ViewCheck UX 라이팅 분석의 로드맵

솔직히 말하면, ViewCheck의 UX 라이팅 분석은 아직 갈 길이 멀다. 지금 우리가 하고 있는 것과, 앞으로 하려는 것을 구분해서 이야기하자.

지금 하고 있는 것:

• KRDS BP·SP 규칙 중 텍스트 관련 항목의 구조적 판정 (DOM 분석)
• 국립국어원 순화 대상 행정용어·외래어 패턴 매칭
• 버튼 라벨 동사형 여부, 오류 메시지 what+how 포함 여부 패턴 판정
• 권장 대체 표현 제시 (국립국어원 목록 + KRDS 원칙 기반)
• 다중 페이지 UX 라이팅 문제 분포 시각화

연구·실험 중인 것:

• 한국어 문장 난이도 지표 개발 (한자어 밀도, 문장 길이, 이중 부정 패턴 조합)
• LLM 기반 맥락적 어려움 판단 (패턴으로 잡히지 않는 복잡한 표현)
• 서비스 유형별(민원·정책·정보 등) UX 라이팅 기준 차별화
• 개선 전후 비교 대시보드

아직 답을 찾고 있는 것:

• 한국어 가독성 측정의 표준 지표 — 아직 합의된 기준이 없다
• 서비스 맥락에 따른 '적절한 전문 용어'와 '줄여야 할 어려운 표현'의 경계
• LLM이 생성한 개선 제안의 품질 검증 방법
• UX 라이팅 개선이 실제 서비스 지표에 미치는 효과 측정

이 로드맵이 완성되는 시점이 언제인지는 모른다. 언어와 기술이 모두 계속 변하기 때문이다. 다만 방향은 분명하다 — 공공 웹의 텍스트가 더 쉽고, 더 명확하고, 더 많은 사람이 이해할 수 있는 방향으로 가도록, 자동화된 진단이 그 과정을 도울 수 있게 만드는 것.

---

국어책임관 제도와 자동 분석의 공존

앞서 국어책임관 제도를 잠깐 언급했는데, 이 제도와 자동 분석 도구의 관계를 조금 더 생각해 보고 싶다.

국어책임관은 공공기관에서 국어 사용을 점검하고 개선하는 전문 역할이다. 「국어기본법」에 근거한 제도로, 기관 내에서 공문서, 보도자료, 웹 콘텐츠 등을 언어 전문가 관점에서 감수하는 기능을 한다.

ViewCheck 같은 자동 분석 도구가 이 역할을 대체할 수 있을까? 그렇지 않다. 자동 분석이 할 수 있는 건 '빠른 스크리닝'이다. 수백 개 페이지를 몇 분 안에 스캔해서 주의가 필요한 표현들을 뽑아 내는 것. 이 스크리닝 결과를 국어책임관이 검토하면, 국어책임관이 혼자 전체를 읽어가는 것보다 훨씬 효율적으로 작업할 수 있다. 자동 분석이 '1차 필터'가 되고, 국어책임관이 '최종 판단자'가 되는 구조다.

이 구조는 ViewCheck가 공공 웹 전반의 품질 진단에서 지향하는 방향과 일치한다. 자동화는 사람이 물리적으로 할 수 없는 범위(수백 페이지, 수천 개 텍스트 요소)를 커버하고, 사람은 자동화가 놓칠 수 있는 맥락적 판단(이 표현이 이 서비스의 특성상 적절한가)을 담당한다. 사람을 대체하는 것이 아니라, 사람이 더 잘 일할 수 있도록 돕는 것이다.

---

해외 사례와의 비교 — 우리는 지금 어디에 있나

GOV.UK Content Style Guide나 미국의 Plain Language Guidelines와 비교하면, 한국 공공 웹의 UX 라이팅 현황은 어느 수준일까?

솔직하게 말하면, 비교가 쉽지 않다. 공공 웹 UX 라이팅에 대한 체계적인 국가 단위 조사 데이터가 아직 충분하지 않기 때문이다. ViewCheck가 분석한 몇백 곳의 사이트 데이터는 있지만, 이걸 한국 공공 웹 전체의 대표 수치로 일반화하기는 어렵다.

다만 몇 가지 구조적 차이는 관찰된다.

영국 GOV.UK의 경우, 중앙에서 콘텐츠 디자인팀이 운영되고, GDS(Government Digital Service)의 콘텐츠 원칙이 모든 GOV.UK 서비스에 적용된다. "9세 읽기 수준"이라는 일관된 기준, 구체적인 A/Z 스타일 가이드, 그리고 중앙 편집팀의 감수 프로세스가 있다. 이 구조 덕분에 GOV.UK 전체의 텍스트 일관성이 높다.

한국의 경우, KRDS가 디자인 원칙을 제공하고, 국립국어원이 언어 기준을 제공하지만, 각 기관이 자체적으로 웹사이트를 운영하는 분산 구조다. 중앙에서 감수 프로세스를 통제할 수 없다. 각 기관의 국어책임관이 그 역할을 하지만, 기관마다 역량과 자원이 다르다.

이 구조적 차이는 "어느 나라가 더 좋다"는 판단의 문제가 아니다. 한국의 공공 웹 구조에서는, 자동 진단 도구가 오히려 더 중요한 역할을 할 수 있다. 중앙 편집팀이 없는 분산 구조에서, 각 기관이 스스로 자신의 웹사이트 UX 라이팅을 진단하고 개선할 수 있는 도구가 있으면 격차를 줄이는 데 기여할 수 있기 때문이다.

---

UX 라이팅과 법적 리스크 — 이해하기 어려운 텍스트의 법적 함의

공공언어의 어려움은 사용자 경험의 문제만이 아니다. 법적 차원의 함의도 있다.

「국어기본법」 제14조는 공공기관이 공문서를 "일반 국민이 알기 쉬운 용어와 문장으로" 써야 한다고 규정한다. 이 조항을 엄밀히 해석하면, 공공 웹사이트의 텍스트가 지나치게 어려울 경우 이 조항을 위반할 소지가 있다. 물론 현실에서 이 조항 위반으로 제재가 이뤄지는 경우는 극히 드물지만, 기준 자체는 법으로 정해져 있다.

더 실질적인 리스크는 다른 데 있다. 공공 서비스에서 동의를 받는 화면(개인정보 동의, 이용약관 동의 등)의 텍스트가 지나치게 어렵거나, 이중 부정으로 의미가 불명확할 경우, 그 동의의 유효성에 대한 법적 분쟁의 소지가 생길 수 있다. "이해하기 어려운 말로 동의를 받았다"는 주장은, 특히 개인정보 관련 사안에서 실제로 제기될 수 있는 논점이다.

이처럼 UX 라이팅의 어려움은 사용자 불편을 넘어 법적 위험 요소로 이어질 수 있다. ViewCheck의 24기능 중 '법적 리스크' 분석과 'UX 라이팅' 분석이 연결되는 지점이 여기다. 동의 화면, 약관 화면, 개인정보 안내 화면의 텍스트가 얼마나 명확한지는 사용성과 법적 위험 두 관점에서 동시에 진단할 수 있다.

---

마무리 — 두 글자를 바꾸는 일의 무게와 가능성

처음으로 돌아가 보자. "제출"이냐 "신청하기"냐. 버튼 두 글자의 차이. 작아 보이지만, 그 두 글자가 몇십 개의 페이지에 걸쳐, 몇만 명의 시민이 매일 마주하는 화면에 반복된다면 — 그건 더 이상 작은 일이 아니다.

ViewCheck의 UX 라이팅 자동 분석은 그 두 글자를 자동으로 찾아내고, 어떻게 바꾸면 좋을지를 제안하는 일을 하려고 한다. 아직 완성된 기능이 아니고, 한국어 언어 분석의 어려움 때문에 계속 실험하고 있는 단계다.

그러나 방향 자체는 분명하다고 믿는다. 공공 웹의 텍스트가 더 쉬워질수록, 더 많은 시민이 서비스를 이해하고 이용할 수 있게 된다. 그건 접근성이기도 하고, 효율성이기도 하고, 국민에 대한 존중이기도 하다. 「국어기본법」이 1990년대에 그 방향을 법으로 정했고, KRDS가 디자인 시스템으로 구현하려 하고, GOV.UK와 USWDS가 해외에서 실증해 왔다. ViewCheck는 그 방향으로, 자동 진단이라는 방법으로, 작은 기여를 하려 한다.

다음 편에서는 이 시리즈의 다른 기능들을 계속 풀어간다. '공공언어 바로쓰기'라는 오래된 과제가 AI 자동 분석과 만날 때 어떤 가능성이 열리고 어떤 한계가 있는지, 이 기록이 조금이라도 실무적으로 유용했으면 한다.

---

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 직접 검증했다. 국내 법령·기관 자료와 해외 연구·가이드라인을 함께 실었다.

국내 — 법령 / 공공기관 자료

1. 「국어기본법」 제14조 제1항 (공공기관의 공문서 알기 쉬운 언어 사용 의무). 국가법령정보센터. https://www.law.go.kr/법령/국어기본법

2. 국립국어원, 「한눈에 알아보는 공공언어 바로 쓰기」 (개정판, 2024). 공공언어과 발간. https://www.korean.go.kr/front/etcData/etcDataView.do?mn_id=&etc_seq=699

3. 국립국어원, 「알기 쉬운 행정용어」. 공공언어과 발간. https://korean.go.kr/front/etcData/etcDataView.do?mn_id=&etc_seq=638

4. 국립국어원, 「행정문서 표현 개선 및 쉬운 공공언어 쓰기 지침 개발」 (연구보고서, 2021). https://www.korean.go.kr/front/reportData/reportDataView.do?mn_id=45&report_seq=1122

5. 뉴시스, "외래어 접촉 비율 1년 사이 41.3%p 상승 — 공공언어 외국어 남용 현황" (2024. 10.). 국립국어원 의뢰, 한국리서치 조사(전국 만 15세~79세 7,800명). https://www.newsis.com/view/NISX20241008_0002913479

6. 퍼블릭타임스, "공공언어 외국어 남용 줄인다… 문체부·국어원 우리말 대체어 공개". https://www.public25.com/news/articleView.html?idxno=30797

7. 행정안전부, 전자정부 웹사이트 UI·UX 가이드라인 (KRDS 공식). https://www.krds.go.kr/

8. 행정안전부 정부혁신조직실, 「쉽고 바른 공공언어 사용을 위한 공문서 용어 개선·정착 추진계획」 (2018. 9.). 국가기록원. https://dams.pa.go.kr/dams/DOCUMENT/2023/11/30/DOC/SRC/0A04202311301611096041877011783.pdf

해외 — 디자인 시스템 / UX 연구

9. GOV.UK, "Content design: planning, writing and managing content — Writing for GOV.UK". Government Digital Service. https://www.gov.uk/guidance/content-design/writing-for-gov-uk

10. GOV.UK, "GOV.UK content principles: conventions and research background". Government Digital Service. https://assets.publishing.service.gov.uk/media/5a7c43cded915d7d70d1daf0/GOV.UK_content_principles.pdf

11. Nielsen Norman Group, "Concise, SCANNABLE, and Objective: How to Write for the Web" (Morkes & Nielsen 1997 연구 — 5개 글쓰기 스타일 비교, 124% 사용성 향상 실증). https://www.nngroup.com/articles/concise-scannable-and-objective-how-to-write-for-the-web/

12. Nielsen Norman Group, "UX Writing: FAQs from Practitioners". https://www.nngroup.com/articles/ux-writing-faqs/

13. Nielsen Norman Group, "Plain Language For Everyone, Even Experts" (전문가도 평이한 언어를 선호한다는 연구). https://www.nngroup.com/videos/plain-language-for-experts/

14. Nielsen Norman Group, "UX Writing: Study Guide". https://www.nngroup.com/articles/ux-writing-study-guide/

15. U.S. Digital.gov, "An introduction to plain language" (Plain Writing Act of 2010 배경, PLAIN 가이드라인). https://digital.gov/resources/an-introduction-to-plain-language

---