분석 → 개선 → 재진단, 공공웹 품질을 '점수로 관리'한다는 것 — ViewCheck LLM 분석 활용

한 번 진단하고 끝이 아니다. 루프를 돌릴 때 비로소 '관리'가 된다.

들어가며 — "진단은 했는데, 그다음은요?"

공공 웹사이트 품질 진단을 맡은 실무 담당자들과 이야기하다 보면, 어느 지점에서 공통된 표정이 나온다. "진단은 했어요. 그런데 그다음은 어떻게 해야 하죠?"

도구를 돌리면 문제 목록이 나온다. 때로는 수백 개, 때로는 수십 페이지짜리 보고서가 나온다. 그리고 거기서 멈춘다. 문제를 고쳤는지 어떻게 확인하지? 개선 후에 점수가 얼마나 올랐지? 한 달 뒤에 또 새로운 문제가 생기면 어떻게 알지? 재점검 주기는 얼마나 잡아야 하지? 이런 질문들이 이어지지만, 대부분의 도구와 방법론은 '1회 점검'으로 설계되어 있다. 진단은 있는데 관리가 없다.

이 글은 그 지점에서 시작한다. ViewCheck LLM 분석을 '활용'한다는 것이 실제로 무엇을 의미하는지 — 단순히 URL을 넣고 결과를 받는 것을 넘어, 분석 → 개선 → 재진단이라는 루프를 어떻게 조직의 품질 관리 체계로 연결하는가. 이 편에서는 그 흐름을 구체적으로 풀어본다.

미리 말해두고 싶은 건, 이건 완성된 해법이 아니라는 점이다. 우리가 실제로 분석을 반복 운영하면서 발견한 것들, 막혔던 지점들, 지금도 개선 중인 부분들을 솔직하게 적으려 한다. "ViewCheck를 쓰면 품질 관리가 자동으로 된다"는 이야기가 아니라, "이 도구를 어떻게 루프의 한 부분으로 쓸 수 있는가"에 대한 이야기다.

밝은 사무실 회의 테이블에서 웹 품질 보고서를 검토하는 30~40대 한국인 공공기관 직원 세 명의 모습. — 진단 결과를 받아 든 순간이 시작일 뿐이다. 어떻게 개선하고, 언제 다시 점검하는지가 진짜 품질 관리의 내용이다.

'1회 점검'이라는 관성 — 왜 루프가 없는가

공공 웹의 품질 점검이 1회성으로 끝나는 데는 이유가 있다. 구조적인 이유다.

첫 번째는 '이벤트 기반' 점검 문화다. 행정안전부의 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025년 6월 25일 시행)은 공공 웹사이트의 품질 진단을 의무화하고 있지만, 많은 기관에서 이를 특정 시점의 이벤트로 인식한다. 연말 결산 시점, 새 시스템 오픈 직전, 혹은 외부 감사를 앞두고. 그 시점에 점검을 하고, 보고서를 만들고, 제출하고, 그다음 이벤트가 생길 때까지 잊는다. 품질은 '점수를 받는 것'이지 '유지하는 것'이 아닌 셈이다.

두 번째는 비용 문제다. 전통적인 점검 방식 — 전문가가 직접 페이지를 열고 체크리스트를 대조하는 방식 — 은 시간도 사람도 많이 든다. 100페이지짜리 사이트를 꼼꼼히 점검하는 데 며칠이 걸린다. 그러면 재점검은 더 어렵다. 개선을 하고 나서 "정말 고쳐졌는지"를 확인하는 데도 또 며칠이 필요하다. 루프를 돌리는 비용이 너무 크니 루프를 포기한다.

세 번째는 결과가 '행동'으로 연결되지 않는다는 점이다. 수백 개의 미통과 항목이 나왔다. 그런데 그게 다 동등하게 중요한가? 무엇부터 고쳐야 하는가? 어떤 것은 개발자가 코드를 수정해야 하고, 어떤 것은 콘텐츠 담당자가 텍스트를 바꿔야 하고, 어떤 것은 외주사에 요청해야 한다. 이 결과가 누구에게, 어떤 형태로 전달되어야 실제로 고쳐지는가? 여기까지 연결이 되지 않으면, 아무리 정확한 진단도 보고서 서랍 속에서 잠든다.

ViewCheck LLM 분석을 설계하면서 우리가 가장 오래 붙잡고 있던 질문 중 하나가 바로 이것이다. "결과를 내는 것"과 "그 결과가 실제로 품질 개선으로 이어지는 것" 사이에는 큰 간격이 있다. 도구가 그 간격을 다 메울 수는 없다. 하지만 간격을 줄이는 방향으로 설계할 수는 있다.

해외의 답 — 영국 GDS의 '지속 모니터링' 모델

루프를 어떻게 만드는가에 대해, 참고가 될 만한 해외 사례가 있다. 영국 정부디지털서비스(GDS)가 운영하는 공공 웹 접근성 모니터링 체계다.

영국 GDS는 「공공기관 접근성 규정(PSBAR)」에 따라 공공기관 웹사이트와 모바일 앱을 주기적으로 모니터링한다. 2022년 1월부터 2024년 9월까지의 모니터링 결과를 담은 보고서에 따르면, GDS는 이 기간 동안 1,203개의 공공 웹사이트와 21개의 모바일 앱을 점검했다(GOV.UK, "Accessibility monitoring of public sector websites and mobile apps from 2022 to 2024", 2024).

이 모니터링 체계가 흥미로운 이유는, 단순히 "점검하고 끝"이 아니라는 구조 때문이다. GDS는 접근성 문제를 발견하면 해당 기관과 후속 커뮤니케이션을 진행한다. 문제를 고쳤는지 확인하고, 고치지 않은 기관에는 평등 기구(equality body)에 권고하는 절차가 이어진다. 총 26,171건의 접근성 문제가 발견됐고, 그중 13,882건이 수정됐다. 수정률은 53%다. 완벽하지 않지만, 발견 → 통보 → 개선 → 확인이라는 루프가 실제로 작동했다는 증거다.

2023년 8월, GDS 블로그에는 "기관들이 접근성 모니터링에 어떻게 반응하는가"라는 제목의 글이 올라왔다. 이 글에서 실제로 GDS 모니터링을 받은 기관의 담당자들이 소감을 밝혔다. 공통적으로 나온 이야기는 이렇다 — "모니터링을 받기 전에는 우리 사이트에 이 정도의 문제가 있는지 몰랐다. 그리고 모니터링 결과를 받고 나서 처음으로 '무엇부터 고쳐야 하는지'를 명확히 알게 됐다"(GDS Blog, "How organisations respond to accessibility monitoring", 2023).

이 구조에서 우리가 주목한 것은 '주기성'이다. GDS는 3년마다 종합 보고서를 발간하지만, 실제 모니터링은 지속적으로 이루어진다. 특정 이벤트가 아니라 상시 루프다. 그리고 그 루프 안에서 각 기관은 "우리 점수가 이번에 어떻게 됐는가"를 추적하게 된다. 점수가 '한 번 받는 것'이 아니라 '추적하는 것'이 되는 순간, 관리의 성격이 달라진다.

ViewCheck가 지향하는 방향도 비슷하다. 한 번의 분석 보고서가 아니라, 반복적으로 돌릴 수 있는 도구. 그리고 반복할수록 "점수가 어떻게 변했는가"를 볼 수 있는 구조. 아직 완성된 형태는 아니고, 우리가 계속 만들어가는 중이다.

분석 → 개선 → 재진단 루프의 구조

그렇다면 ViewCheck LLM 분석을 중심으로 한 루프는 실제로 어떻게 돌리는가. 우리가 실제 분석 운영에서 발견한 흐름을 정리하면 이렇다.

1단계 — 분석(Analyze): 현재 상태를 정확히 측정한다

모든 것은 URL을 넣는 것으로 시작한다. ViewCheck는 Playwright로 실제 브라우저를 띄워 사이트를 크롤링하고, KRDS 846개 규칙(DS 120·CP 446·BP 108·SP 172)으로 판정하고, 24개의 분석 결과 카드를 대화로 펼쳐낸다. 이 단계의 핵심은 '정확한 현재 상태'를 확보하는 것이다.

여기서 중요한 건 '다중 페이지'다. 메인 한 장만 보면 "메인의 상태"를 알 뿐이다. 신청 페이지, 검색 페이지, 로그인 페이지처럼 시민이 실제로 쓰는 화면들을 봐야 "사이트 전체의 상태"를 알 수 있다. 루프를 돌릴 때도 마찬가지다. 개선 전과 후를 비교하려면, 비교 기준이 되는 '기준 분석'이 사이트 전체를 커버해야 한다. 메인만 본 기준 분석과 전체를 본 재진단은 비교 자체가 무의미하다.

2단계 — 개선(Improve): 결과를 행동으로 연결한다

분석 결과가 나왔다. 그다음은 무엇부터 고칠 것인가를 결정해야 한다. 여기서 ViewCheck의 24개 분석 카드 중 몇 가지가 특히 중요해진다.

오류 리스트 카드: 어떤 규칙이, 어느 페이지에서, 몇 번 미통과됐는지. 반복 횟수가 많은 것이 우선이다.
개선 로드맵 카드: 규칙별 우선순위(P0~P3)와 예상 수정 비용(시간·MM). 무엇이 급하고, 무엇이 많은 공수가 드는지.
위반 매트릭스 카드: 어떤 규칙 위반이 어느 페이지 유형에서 반복되는지. 특정 페이지 유형 전체를 고쳐야 하는 패턴을 잡을 때 유용하다.

그리고 Q&A가 있다. "이 항목이 왜 미통과인지"를 채팅으로 물으면, 근거가 된 KRDS 규칙과 공식 문서가 참조패널에 함께 나온다. 이 근거를 외주 개발사에 그대로 전달하면 모호한 구두 설명 대신, 출처가 붙은 명확한 요구사항이 된다. "이 컴포넌트가 KRDS CP-XXX 규칙의 이 조건을 충족하지 못했습니다, 이렇게 수정해 주세요"라는 식으로.

개선이 끝나면 즉시 재진단에 들어가지 않아도 된다. 오히려 "이 개선이 실제 배포에 반영됐는가"를 확인한 후, 재진단 시점을 잡는 것이 좋다.

3단계 — 재진단(Re-diagnose): 개선이 실제로 효과가 있었는가

같은 URL로 다시 ViewCheck를 돌린다. 이번에도 다중 페이지, 기준 분석과 동일한 범위로. 결과를 비교한다.

재진단에서 볼 것은 두 가지다. 첫째, 미통과했던 항목이 통과로 바뀌었는가. 둘째, 개선 과정에서 새로운 미통과 항목이 생기지 않았는가. 두 번째가 생각보다 자주 발생한다. A를 고치다가 B가 깨지는 경우. 이걸 '회귀(regression)'라고 부르는데, 재진단이 없으면 회귀를 모른 채 배포하게 된다.

재진단 결과에서 "이번 분석의 점수"와 "기준 분석의 점수"를 나란히 놓으면, 루프가 얼마나 효과가 있었는지 수치로 확인할 수 있다. DS(디자인 스타일) 카테고리 점수가 48에서 67로 올랐다, BP(기본 패턴) 점수가 71에서 83으로 올랐다, 같은 식으로. 이 수치가 다음 개선의 목표가 되고, 그 목표가 또 다음 루프의 출발점이 된다.

루프는 이 세 단계를 반복한다. 분석 → 개선 → 재진단 → 분석 → 개선 → 재진단. 단순하게 들리지만, 이 반복 자체가 품질 관리의 본질이다.

노트북·웹 감사 체크리스트·색깔 메모지·개선 지표 노트가 놓인 한국인 디자이너 책상의 탑다운 뷰. — 분석 결과는 색깔 메모지가 된다. 무엇이 급하고, 누가 담당하고, 어디서 확인하는가 — 루프는 이 구체적인 작업에서 돌아간다.

점수를 '한 번 받는 것'에서 '추적하는 것'으로

루프를 돌리는 것과 단순 반복의 차이는 '추적'에 있다. 점수를 기록하고, 그 변화를 시간 축 위에 놓을 때 비로소 관리가 시작된다.

품질 개선 방법론의 고전인 PDCA(Plan-Do-Check-Act) 사이클은 이 논리의 뿌리다. 1950년대 W. Edwards Deming이 정립한 이 방법론은 계획 → 실행 → 확인 → 조치의 반복을 통해 프로세스를 지속 개선한다는 것이고, 지금도 ISO 9001 품질경영시스템 요구사항의 핵심 프레임이다(PECB, "The Plan-Do-Check-Act (PDCA) Cycle: A Guide to Continuous Improvement"). 핵심은 '확인(Check)' 단계다. 실행한 것이 효과가 있었는지를 측정하지 않으면, 다음 계획을 개선할 수 없다.

ASQ(미국품질협회)는 지속 개선 측정에 대해 이렇게 말한다. "개선 과정을 측정하면 어디에서 개선이 이루어졌는지 파악하고, 시간이 지남에 따라 진행 상황을 추적할 수 있다." 그리고 "변화가 성공적이었다면 더 넓은 범위에서 실행하고, 결과를 지속적으로 평가하라. 변화가 효과가 없었다면 다시 사이클을 시작하라"(ASQ, "How to Measure Continuous Improvement"). 이 구조가 웹 품질에도 그대로 적용된다.

ViewCheck의 성과 대시보드 카드와 위반 매트릭스 카드는 이 '추적' 기능을 위해 설계된 것들이다. 분석 시점마다의 점수, 카테고리별 상태, 어떤 규칙이 지속적으로 미통과되는지를 시각화한다. 지금 우리가 계속 발전시키고 있는 부분이기도 하다. 점수를 '하나의 숫자'로 보는 것에서 나아가, "이번 분석과 지난 분석의 차이"를 한눈에 볼 수 있는 트렌드 뷰로. 아직 완성된 형태는 아니지만, 방향은 분명하다.

ViewCheck LLM 분석의 성과 대시보드 카드 실제 캡처 화면. 카테고리별 KRDS 846규칙 판정 점수와 통계가 표시되어 있다. — ViewCheck 성과 대시보드 카드 실제 화면. 카테고리별 점수, 판정 비율, 규칙 위반 현황이 한 화면에 정리된다. 이 숫자들이 루프의 기준점이 된다. — 실제 분석 화면

점수는 무엇을 측정하는가 — 846규칙의 네 축

루프를 돌릴 때 "점수가 올랐다"는 것이 무엇을 의미하는지 정확히 이해해야, 점수 관리가 실질적인 품질 관리로 연결된다. ViewCheck의 KRDS 점수는 4개 카테고리의 합산이다.

DS(디자인 스타일, 120규칙): 색상, 타이포그래피, 간격, 레이아웃의 수치적 준수. 예를 들어 KRDS 기준 색상 토큰을 쓰는가, 정해진 폰트 크기 체계를 따르는가, 간격 단위가 KRDS 그리드에 맞는가. 이 카테고리 점수가 낮으면, 사이트가 KRDS 디자인 언어에서 얼마나 벗어나 있는지를 의미한다.

DS 점수를 개선하는 건 종종 '디자인 토큰 정리'와 연결된다. KRDS가 정의한 색상·간격·타이포 토큰을 코드베이스에 적용하는 작업. 한 번 제대로 토큰을 정리하면 DS 카테고리의 여러 규칙이 한꺼번에 통과로 바뀌는 경우가 많다. 루프를 돌릴 때, "이번 스프린트에서 DS 토큰을 정리했다"고 했다면, 재진단 결과에서 DS 점수 변화를 확인하는 것이 그 스프린트의 효과 측정이 된다.

CP(컴포넌트, 446규칙): 버튼, 입력창, 탭, 모달 같은 UI 컴포넌트의 구조와 접근성. ARIA 속성이 올바른가, 라벨이 있는가, 키보드로 작동하는가. CP 점수가 낮은 사이트는 스크린 리더나 키보드 사용자가 불편을 겪을 가능성이 높다.

CP 점수 개선은 개발자의 코드 수정과 직결된다. 특히 ARIA 속성, 포커스 관리, 키보드 접근성 관련 규칙들이 여기 몰려 있다. CP 카테고리에서 반복적으로 미통과되는 규칙 패턴을 오류 리스트와 위반 매트릭스로 확인하면, "어떤 컴포넌트를 공통으로 수정해야 전체 점수가 올라가는가"를 파악할 수 있다.

BP(기본 패턴, 108규칙): 폼 입력, 동의/확인 절차, 오류 안내, 필터/정렬 같은 반복 상호작용의 패턴. 사용자가 자주 하는 일련의 행동이 KRDS 기준에 맞게 설계되어 있는가를 본다. BP 점수가 낮으면 "기능은 있는데 쓰기 불편하다"는 UX 문제와 연결되는 경우가 많다.

SP(서비스 패턴, 172규칙): 검색, 로그인, 신청서 제출, 정책 정보 확인 같은 서비스 단위의 흐름. 가장 시민 접점에 가까운 규칙들이 여기에 있다. SP 점수는 "이 서비스를 실제로 이용할 때 KRDS 기준의 경험을 받는가"를 측정한다.

루프를 돌릴 때, 이 네 카테고리를 함께 보는 것이 중요하다. 어떤 기관은 DS는 잘 관리되지만 CP가 약하다. 어떤 기관은 BP와 SP에서 반복적으로 미통과가 나온다. 카테고리별 점수 추이를 보면, "우리 사이트의 품질이 어느 방향으로 개선되고 있고, 어느 영역이 아직 취약한가"가 보인다.

개선의 우선순위를 정하는 법 — P0부터 P3까지

846개 규칙이 모두 동등하게 중요한 건 아니다. 어떤 미통과는 즉각 수정이 필요한 중대 결함이고, 어떤 미통과는 나중에 여건이 될 때 개선해도 되는 항목이다. 루프를 효율적으로 돌리려면, 이 우선순위를 올바르게 잡는 것이 핵심이다.

ViewCheck의 개선 로드맵 카드는 미통과 항목을 P0~P3의 4단계 우선순위로 분류한다.

P0 — 즉시 수정(Critical): 접근성 심각 결함, 보안 취약점, 법적 의무 미이행처럼 즉시 조치가 필요한 항목. 예를 들어 이미지에 대체 텍스트가 전혀 없는 경우, 로그인 폼에 자동완성이 비활성화되어 있어 인증앱과 충돌하는 경우.

P1 — 단기 수정(High): 사용자 경험에 직접 영향을 주는 KRDS 핵심 규칙 미통과. 주요 컴포넌트의 ARIA 속성 누락, 폼 오류 안내 미제공 같은 것들. 다음 배포 주기 안에 수정하는 것이 권장된다.

P2 — 중기 개선(Medium): 기능은 작동하지만 KRDS 가이드라인의 세부 기준을 충족하지 못하는 항목. 간격 단위, 색상 토큰 불일치처럼 시각적 일관성 관련 사항이 많이 여기에 해당한다.

P3 — 장기/모니터링(Low): 점진적으로 개선할 항목. 현재 시스템 구조상 단기에 수정하기 어려운 것들, 혹은 해당없음(N/A)에서 추가 정보를 통해 재분류될 가능성이 있는 항목.

루프를 설계할 때 실용적인 접근은 이렇다. 첫 번째 루프에서는 P0와 P1에 집중한다. 이것만 수정해도 점수 변화가 명확하게 보이고, 실제로 시민 경험에 가장 큰 영향을 미치는 부분이 개선된다. P2와 P3는 이후 루프에서 차례로 다룬다. 한 루프에서 모든 걸 고치려 하면 오히려 아무것도 제대로 고치지 못하는 경우가 생긴다.

누가 무엇을 — 개선의 책임 분산

"이 결과를 보고 고쳐라"가 통하지 않는 이유 중 하나는, 웹사이트 품질은 한 사람이 혼자 고칠 수 없기 때문이다. 개발자가 코드를 수정해야 하는 것, 디자이너가 시각 요소를 바꿔야 하는 것, 콘텐츠 담당자가 텍스트를 수정해야 하는 것, 외주사에 요청해야 하는 것이 섞여 있다.

ViewCheck의 24개 분석 카드는 이 '역할별 분리'를 어느 정도 자연스럽게 한다.

디자인 스타일 카드: 디자이너와 퍼블리셔가 볼 내용. 색상·폰트·간격의 KRDS 준수 여부.
컴포넌트 카드 + 오류 리스트 카드: 개발자가 볼 내용. ARIA 속성, DOM 구조, 키보드 접근성.
접근성(KWCAG) 카드: 접근성 전문가 또는 외주사에 전달할 내용. KWCAG 34항목의 세부 미통과와 개선 방향.
임원보고서 카드 + 성과 대시보드 카드: 경영진·부서장이 볼 내용. 전체 점수와 주요 리스크 요약.
비용·MM 카드: 개선 공수를 산출하고 외주 발주 규모를 잡을 때.

루프를 조직으로 확장할 때, 이 역할 분리가 실질적인 업무 흐름으로 연결되어야 한다. ViewCheck 결과를 받은 주무관이 "전부 개발팀에 넘기면 되겠지"라고 생각하면 루프는 끊긴다. 각 카드의 결과가 어느 팀으로, 어떤 형태로 전달되는가를 미리 정해두는 것 — 그것이 조직 차원의 루프 설계다.

언제 재진단할 것인가 — 주기의 설계

재진단 주기는 정해진 답이 없다. 사이트의 변경 빈도, 팀의 규모, 예산에 따라 달라진다. 다만 몇 가지 기준점을 제시할 수 있다.

이벤트 기반 재진단: 큰 배포가 있을 때마다. 새 기능이 추가되거나, 디자인 리뉴얼이 있거나, 외주사가 교체될 때. 이 시점은 새로운 문제가 생기기 가장 쉬운 시점이기도 하다.

정기 주기 재진단: 월별, 분기별처럼 정해진 주기로. 변경이 많은 사이트라면 월별이 적당하고, 변경이 적다면 분기별도 충분할 수 있다. 영국 GDS의 공공기관 모니터링이 3년 보고서 주기를 유지하면서도 상시 모니터링을 병행하듯, 정기 주기와 이벤트 기반을 함께 운영하는 것이 현실적이다.

점수 기반 재진단: 특정 점수 임계값 아래로 떨어지면 즉시. 예를 들어 카테고리 점수가 70점 아래로 내려가면 재진단을 트리거하는 식이다. 이건 더 자동화된 형태인데, ViewCheck의 반복 실행을 스케줄링할 수 있다면 구현 가능하다.

어떤 주기를 택하든, 핵심은 재진단을 "계획된 일"로 만드는 것이다. "언젠가 다시 돌려봐야지"로 두면 영원히 안 한다. 분기 캘린더에 미리 박아두고, 그날 담당자가 URL을 넣고 결과를 확인하는 게 루프가 유지되는 가장 현실적인 방법이다.

WCAG·KWCAG와 재진단 — 접근성은 '상태'가 아니라 '활동'이다

접근성 영역은 루프의 중요성이 특히 강조된다. WCAG(Web Content Accessibility Guidelines) 2.2는 2023년 10월 W3C 표준으로 확정됐고, 영국 GDS는 2024년 10월부터 WCAG 2.2 기준으로 모니터링을 전환했다(GOV.UK, "UK Government websites to meet WCAG 2.2 from October 2024"). 표준이 바뀌면, 이전에 통과했던 사이트가 새 기준에서 미통과가 될 수 있다. 점검은 한 번으로 끝나지 않는다.

국내에서도 마찬가지다. 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2에 근거한 34개 항목이 ViewCheck의 접근성(KWCAG) 카드에 포함된다. 그리고 행안부 「전자정부 웹사이트 품질관리 지침」은 계속 개정된다 — 2024년 개정, 2025년 개정, 앞으로도 이어질 것이다(행정안전부, 「전자정부 웹사이트 품질관리 지침」 행정안전부고시 제2025-46호). 기준이 살아 움직이는 한, 점검도 살아 움직여야 한다.

접근성 전문가들이 흔히 하는 말이 있다. "접근성은 프로젝트(project)가 아니라 실행(practice)이다." 한 번에 완료되는 것이 아니라 지속적으로 실천해야 하는 것이라는 뜻이다. 이 말이 루프 기반 관리의 본질을 잘 담고 있다. 사이트는 변하고, 기준은 변하고, 콘텐츠는 변한다. 그 변화 속에서 품질을 유지하는 건 1회 점검이 아니라 지속 활동이다.

AllAccessible의 WCAG 2.2 감사 가이드(2025)는 이 맥락에서 의미 있는 관점을 제시한다. 감사(audit) → 수정(remediation) → 재검사(re-test) → 모니터링(monitoring)의 4단계를 접근성 개선의 표준 주기로 설명한다. 재검사와 모니터링을 별도의 단계로 분리한 것이 인상적이다. 수정하고 나서 "됐겠지"가 아니라, 수정이 실제로 효과를 냈는지 확인하고, 그 상태를 지속적으로 관찰하는 것까지가 하나의 사이클이다.

밝은 사무실에서 20대 후반 한국인 개발자가 두 번째 모니터에 체크리스트를 띄워놓고 접근성 코드 수정에 집중하는 모습. — 접근성은 한 번 고치고 끝나는 것이 아니다. 고치고, 확인하고, 다시 모니터링하는 루프가 지속 가능한 접근성이다.

재진단 결과를 어떻게 읽는가 — 숫자 이면의 의미

재진단 결과를 받았다. 숫자를 어떻게 해석해야 할까. 단순히 "점수가 올랐다"고 만족하기 전에, 몇 가지를 같이 확인하는 것이 중요하다.

1. 어떤 카테고리가 올랐는가

전체 점수가 65에서 72로 올랐다면, 그 7점이 어느 카테고리에서 온 것인지 확인해야 한다. DS에서 많이 올랐다면 디자인 토큰 정리가 효과를 낸 것이고, CP에서 올랐다면 컴포넌트 접근성 개선이 반영된 것이다. 이 분해가 없으면, 다음 루프에서 어디에 집중해야 할지 방향이 흐릿해진다.

2. 새로운 미통과가 생겼는가

앞서 말한 회귀 확인이다. 고친 부분은 좋아졌는데, 다른 부분이 새로 나빠졌다면 루프가 부작용을 낳고 있는 것이다. 재진단 결과에서 "이전에는 통과였는데 이번에는 미통과인 항목"을 별도로 확인해야 한다. ViewCheck의 오류 리스트는 이 비교를 위한 데이터를 제공한다.

3. N/A(해당없음) 항목의 변화

N/A 항목이 줄었다면, 전보다 더 많은 규칙을 실제로 판정할 수 있게 됐다는 의미다. 이건 긍정적인 변화일 수 있다. 반대로 N/A가 늘었다면, 이전에 감지됐던 컴포넌트가 이번에 감지되지 않은 것일 수 있다 — 이건 조사가 필요하다. 점수 자체는 비슷한데 N/A가 늘었다면, 실제로 판정되는 규칙이 줄어든 것이니 수치가 보여주는 것보다 상황이 더 복잡할 수 있다.

4. 점수 개선 속도

루프를 몇 번 돌리다 보면, 처음에는 빠르게 점수가 오르다가 어느 지점에서 정체되는 현상이 나타난다. 이건 자연스러운 현상이다. 초반에는 쉽게 고칠 수 있는 P0·P1 항목들이 해결되면서 빠른 상승이 일어나지만, 그 이후에는 구조적인 문제나 시간이 오래 걸리는 P2·P3 항목들만 남기 때문이다. 이 정체를 "더 이상 개선이 안 된다"로 읽으면 안 된다. 다음 루프에서 P2 항목 중 무엇을 다음 스프린트에 담을지 결정하는 것이 이 시점의 작업이다.

일관성 카드와 다중 페이지 재진단

루프를 돌릴 때 특히 중요한 카드 중 하나가 일관성 카드다.

공공 웹사이트는 대부분 여러 부서, 여러 시기에 걸쳐 조금씩 추가된 페이지들이 모여 있다. 메인 페이지는 최근 리뉴얼됐지만 하위 서비스 페이지는 5년 전 구조 그대로인 경우, 게시판 목록은 KRDS 기준에 맞지만 신청서 양식은 다른 회사가 만든 것이라 스타일이 달라진 경우. 이렇게 되면 "메인만 보면 좋은데 실제 이용하면 오락가락"하는 경험이 생긴다.

일관성 카드는 여러 페이지의 분석 결과를 교차해서 "어떤 규칙이 어떤 페이지 유형에서는 통과하지만 다른 페이지 유형에서는 미통과하는가"를 보여준다. 특정 컴포넌트가 A 페이지에서는 올바르게 구현됐지만 B 페이지에서는 아닌 경우 — 이게 '일관성 위반'이다.

일관성 문제는 개선 후 재진단에서 중요한 체크포인트다. A 페이지를 고쳤으면, B 페이지도 같은 방식으로 고쳐졌는가? 메인의 접근성을 개선했으면, 서브 페이지들도 같은 기준으로 함께 개선됐는가? 이것을 루프 안에서 확인하지 않으면, 개선이 특정 페이지에만 국소적으로 적용되고 전체 사이트의 품질은 여전히 고르지 않은 상태로 남는다.

NN/g(닐슨 노먼 그룹)의 UX 벤치마킹 관련 연구는 UX 품질 측정에서 일관성을 별도로 추적해야 한다는 점을 강조한다. "벤치마킹 프로그램은 릴리스에 걸쳐 측정을 반복해 진행 상황을 추적한다. 주요 지표는 효과성(태스크 성공률), 효율성(소요 시간), 오류 수, 만족도다"(NN/g, UX 메트릭스 및 ROI 보고서 관련 아티클). 이 관점을 공공 웹 품질 루프에 적용하면, 카테고리 점수 외에 '일관성 지수' — 얼마나 많은 페이지에서 동일한 기준이 적용되고 있는가 — 도 추적 지표로 삼아야 한다.

다중 페이지 재진단 없이는 이 일관성 추적이 불가능하다. 다시 한번, 루프를 돌릴 때 단일 페이지만 보는 것의 한계다. 메인만 보고 "개선됐다"고 판단했는데, 서비스 페이지들은 여전히 미통과 상태라면 — 그건 개선이 아니라 착시다.

루프와 구독 모델 — 왜 반복이 가치를 만드는가

이 지점에서 한 가지 솔직한 이야기를 해야 할 것 같다. ViewCheck의 반복 활용이 우리에게 중요한 건, 서비스로서의 가치 창출과도 연결되기 때문이다. 이 점은 숨기지 않고 말하겠다.

1회성 진단 도구는 "써봤는데 별로"로 끝나는 경우가 많다. 결과를 받고, 개선을 하고, 그걸 확인할 필요가 없다면 두 번째 분석을 할 이유가 없다. 반면 루프 기반의 활용은 자연스럽게 반복을 만든다. 개선을 하고 나면 확인하고 싶어지고, 주기적으로 상태를 점검하고 싶어지고, 트렌드를 보고 싶어진다.

하지만 이건 사용자 입장에서도 손해가 아니다. 오히려 반복 활용이 가치를 만든다. 한 번의 진단 결과를 보는 것보다, 3개월 전 결과와 지금 결과를 비교하는 것이 훨씬 더 많은 정보를 준다. "우리 사이트가 지금 좋은가"보다, "우리 사이트가 나아지고 있는가, 어느 방향으로"가 관리에 더 유용한 질문이다.

USWDS(미국 연방 웹 디자인 시스템)가 제공하는 성숙도 모델(Maturity Model) 관점도 이와 연결된다. USWDS는 연방 웹사이트의 USWDS 적용 수준을 3단계(원칙 통합 → UX 가이드 준수 → 코드 사용)로 나누고, 각 기관이 단계별로 점진적으로 성숙해가는 것을 추적한다(USWDS 공식, designsystem.digital.gov). "한 번에 다 되면 좋겠지만, 단계별로 나아가는 구조"를 제도화한 것이다. 공공 웹 품질도 마찬가지다. 한 번의 점검으로 모든 문제가 해결되기를 기대하는 것보다, 매 루프마다 조금씩 나아지는 궤적을 만드는 것이 현실적이고 지속 가능하다.

책상 위에 키보드 옆에 놓인, 6개월간 품질 점수 상승 추이를 보여주는 꺾은선 그래프 프린트. — 6개월치 점수 추이를 보면, 어느 시점에 개선이 이루어졌는지, 어느 구간에서 정체됐는지가 보인다. 점수는 '받는 것'이 아니라 '읽는 것'이 될 때 의미가 생긴다.

루프를 막는 것들 — 솔직한 장벽들

루프를 돌리는 것이 이론적으로 맞다는 건 다들 안다. 그런데 현실에서 루프가 끊기는 경우가 많다. 우리가 실제로 관찰한 장벽들을 솔직하게 적어본다.

장벽 1: "점검이 끝났으면 됐지, 또 해야 해요?" 품질 점검을 이벤트로 인식하는 문화. 특정 목적(감사, 사업 종료 보고, 오픈 전 점검)이 달성되면 다음 이벤트까지 관심이 사라진다. 이건 도구의 문제가 아니라 조직 문화의 문제다. 루프를 도입하려면, 품질 관리를 "한 번 해결하는 것"이 아니라 "지속하는 것"으로 인식을 바꾸는 게 먼저다.

장벽 2: "결과를 받았는데 누가 고쳐요?" 결과가 나왔지만 개선 실행을 담당할 사람이 명확하지 않은 경우. 담당자가 기획자인데, 실제 수정은 개발자가 해야 하고, 개발자 예산은 별도 부서 승인이 필요하고… 이런 구조에서는 진단 결과가 전달되기도 전에 루프가 끊긴다. 조직 내에서 "이 결과를 누가, 어떤 프로세스로 처리하는가"를 미리 정해두는 것이 루프의 전제 조건이다.

장벽 3: "또 돌리면 또 문제가 나올 것 같아서…" 재진단을 두려워하는 심리. 처음 분석에서 이미 수백 개의 미통과 항목이 나왔는데, 개선을 하고 나서 또 돌리면 또 새로운 문제가 나올까 봐 걱정하는 것. 재진단을 "또 다른 문제가 나오는 것"이 아니라 "개선이 얼마나 효과가 있었는지 확인하는 것"으로 프레이밍을 바꾸는 게 중요하다. 재진단에서 새 문제가 나오는 건 좋은 일이다 — 몰랐던 걸 알게 된 것이기 때문이다.

장벽 4: 분석 범위가 달라지는 문제 기준 분석과 재진단의 크롤링 범위가 달라지면 비교가 의미 없어진다. 처음에는 메인 + 서브 20페이지를 봤는데, 재진단에서는 메인 + 서브 5페이지만 본 경우, 점수 변화가 실제 개선을 반영하는지 크롤링 범위 차이를 반영하는지 알 수 없다. 루프를 설계할 때 "매 분석에서 동일한 페이지 세트를 보는 것"을 기준으로 삼는 것이 중요하다.

장벽 5: 외주사 교체 이후 개선을 담당했던 외주사가 교체되면, 새 외주사가 이전 분석 결과를 모르는 채 작업을 시작하는 경우가 있다. 이때 재진단을 돌리면 이전보다 점수가 떨어지는 경우가 생긴다. 외주사 교체 시점에 기준 분석을 다시 실행하고, 새 외주사에게 결과를 인계하는 것이 루프를 유지하는 실용적인 방법이다.

재진단 결과를 보고서로 — 임원보고서 카드의 역할

루프를 조직 차원에서 운영하려면, 분석 결과가 "운영 담당자만 보는 것"에서 나아가 의사결정자에게 전달될 필요가 있다. 예산을 결정하는 부서장, 사업을 발주하는 관리자, 전체 방향을 결정하는 경영진 — 이들이 "우리 사이트 품질이 어떻게 변하고 있는가"를 알아야, 개선에 필요한 자원이 할당된다.

ViewCheck의 임원보고서 카드는 이 역할을 위해 만들어졌다. 846개 규칙의 세부 판정 결과를 경영진이 읽을 필요는 없다. 대신 "전체 준수율이 어느 수준인가", "어느 카테고리에서 리스크가 가장 큰가", "개선을 하면 준수율이 어느 수준으로 올라갈 것으로 예상되는가" 같은 요약이 필요하다. 임원보고서 카드는 이 요약을 제공한다.

루프를 운영할 때, 분기마다 임원보고서 카드 결과를 부서 회의에 올리는 것 자체가 "품질 관리를 조직의 어젠다로 만드는" 첫 번째 단계가 된다. "지난 분기 우리 사이트의 DS 카테고리 점수가 이만큼 올랐고, CP 카테고리는 아직 이 부분이 남아 있습니다"를 수치로 보고하면, "그다음에 무엇을 할 것인가"가 더 구체적인 토론이 된다.

이 점은 GDS 모니터링 모델에서도 확인된다. GDS가 3년마다 공개 보고서를 내는 것은, 개별 기관의 담당자뿐 아니라 정책 결정자와 의회, 시민이 "공공 웹 접근성이 어떻게 변하고 있는가"를 확인할 수 있게 하는 구조다. 투명성과 책무성이 지속 개선의 동력이 된다(GOV.UK, "Accessibility monitoring of public sector websites and mobile apps from 2022 to 2024"). ViewCheck가 임원보고서 카드를 통해 하려는 것도 같은 논리다 — 품질 정보를 조직 내 적절한 수준까지 끌어올리는 것.

법적 리스크와 루프 — 재진단이 '증거'가 되는 이유

재진단 루프가 단순히 내부 관리 도구를 넘어, 외부에 대한 '증거'가 되는 맥락도 있다.

공공 웹사이트의 접근성 미준수는 법적 리스크와 연결된다. 영국에서는 PSBAR 위반 시 평등 기구의 조사가 개시될 수 있고, 미국에서는 ADA(미국 장애인법) 위반으로 소송 대상이 된다. 국내에서도 「장애인차별금지법」과 관련 지침에 따라 접근성 미준수가 시정 요청의 근거가 될 수 있다.

이런 맥락에서 루프를 돌린 기록은 '우리가 접근성 개선에 노력하고 있었다'는 증거가 된다. 특정 시점에 어떤 문제를 알았고, 어떤 개선을 했고, 재진단에서 어떤 변화가 있었는지의 기록. 이것이 없으면 "몰랐습니다" 또는 "하고 있었습니다" 중 어느 쪽도 증명할 수 없다. ViewCheck LLM 분석의 법적 리스크 카드는 이런 맥락에서 주목할 영역 중 하나다.

한편, WCAG 2.2가 2025년 ISO/IEC 40500:2025로 국제 표준화됐다는 점도 이 맥락에서 중요하다(Skynet Technologies, "WCAG 2.2 as an ISO accessibility standard", 2025). 국제 표준화는 "이 기준을 지켜야 하는가"의 문제가 아니라 "이 기준을 지켰는지 어떻게 증명하는가"의 문제를 더 명확히 만든다. 재진단 루프는 그 증명의 과정이기도 하다.

루프를 시작하는 가장 단순한 방법

여기까지 읽고 나면, 루프를 돌리는 것이 꽤 복잡하게 느껴질 수 있다. 주기를 설계하고, 역할을 분산하고, 보고 구조를 만들고… 하지만 시작은 훨씬 단순해도 된다.

가장 단순한 루프의 시작은 이렇다.

오늘 ViewCheck를 돌린다. 결과를 받는다. 특히 오류 리스트 카드와 개선 로드맵 카드를 본다.
P0 항목 중 가장 쉽게 고칠 수 있는 것 하나를 고른다. 복잡한 구조 변경이 필요 없는 것, 예를 들어 이미지 대체 텍스트 추가, 버튼 라벨 수정 같은 것.
그것을 고친다. 고치고 나서 배포한다.
일주일 뒤, 같은 URL로 ViewCheck를 다시 돌린다. 그 항목이 통과로 바뀌었는가? 다른 것이 새로 미통과가 됐는가?
이 두 결과를 나란히 본다. 이게 루프다.

루프를 한 번 경험하면, 다음 루프를 설계하는 게 훨씬 쉬워진다. 처음부터 완벽한 주기를 설계하려 하지 않아도 된다. 한 번 돌리고, 무엇이 달라졌는지 확인하고, 다음 루프를 계획하는 것. 반복 자체가 루프 운영 능력을 키운다.

우리가 이 과정에서 계속 발견하는 건, 처음에는 작은 개선이 연속으로 이어지다 보면 어느 순간 "관리하고 있다"는 감각이 생긴다는 것이다. 점수가 올랐기 때문이 아니라, 어제보다 오늘 무엇이 어떻게 달라졌는지를 '아는' 상태가 됐기 때문이다. 그것이 1회 진단과 반복 루프의 가장 큰 차이다.

밝은 사무실에서 30대 한국인 여성과 남성 두 명이 나란히 앉아 품질 개선 체크리스트가 표시된 노트북 화면을 함께 검토하며 한 명이 화면을 가리키는 모습. — 첫 루프는 작아도 된다. P0 항목 하나, 개선 하나, 재확인 하나. 이 세 단계를 처음 경험하는 것이 가장 중요하다.

루프가 조직에 주는 것 — 숫자 이상의 가치

마지막으로, 루프를 반복하면서 점수 이상으로 얻게 되는 것들을 이야기하고 싶다.

공통 언어: 루프를 돌리면서 팀 안에 "DS 점수", "CP 미통과", "P1 항목" 같은 공통 어휘가 생긴다. 기획자, 개발자, 디자이너, 외주사가 같은 단어로 품질을 이야기할 수 있게 된다. 이게 생기기 전까지는 "접근성이 좀 부족하다"는 말이 모두에게 다른 의미로 전달된다. 공통 언어는 협업의 마찰을 줄인다.

문제의 패턴화: 여러 번 루프를 돌리면, "우리 사이트에서 반복적으로 나오는 문제"의 패턴이 보인다. 특정 컴포넌트가 항상 문제가 된다면, 그 컴포넌트의 설계 자체를 다시 봐야 한다는 신호다. 루프가 없으면 이 패턴을 발견할 수 없다. 1회 점검은 스냅샷이고, 반복 점검은 영상이다.

외주사 관리 도구: 개선을 외주사에 맡겼을 때, 재진단 결과는 외주사 성과 측정의 객관적 기준이 된다. "저번 분석 결과 vs 이번 분석 결과"를 나란히 놓고, 계약에서 요청한 항목이 실제로 개선됐는지 확인할 수 있다. 주관적인 평가 대신 수치 기반의 피드백이 가능해진다.

지식 축적: 루프를 돌릴 때마다 "이 규칙은 우리 사이트에서 이런 이유로 계속 미통과된다"는 지식이 팀에 쌓인다. 이 지식이 쌓이면, 새로운 기능을 만들 때 처음부터 "이 패턴으로 만들면 나중에 재진단에서 미통과 나온다"를 예방할 수 있게 된다. 루프는 진단 도구이기도 하지만, 학습 도구이기도 하다.

아직 우리가 못 하는 것들 — 솔직한 한계

이 글에서 루프와 지속 관리의 가치를 많이 이야기했다. 그런데 솔직하게 말해야 할 것도 있다. ViewCheck가 아직 완성하지 못한 부분들이다.

현재 ViewCheck는 각 분석 시점의 결과를 보여주지만, "이전 분석과 이번 분석의 점수 변화를 자동으로 시각화하는" 트렌드 뷰는 아직 개발 중이다. 루프를 돌리는 사람이 직접 두 분석 결과를 열어놓고 비교해야 한다. 이 비교를 자동화해서 "지난 3개 분석의 DS 점수 추이"를 한 줄로 보여주는 것 — 이게 완성되면 루프의 가치가 훨씬 명확하게 전달될 것이다. 현재 우리가 만들어가고 있는 부분이다.

재진단 결과와 기준 분석 결과를 연결해서 "어떤 항목이 개선됐고, 어떤 항목이 새로 발생했는가"를 diff 뷰로 보여주는 것도 마찬가지다. 지금은 두 결과를 각각 열고 눈으로 비교해야 한다. 이 비교를 자동화하는 것이 루프 경험을 크게 개선할 것이다.

분석 주기를 예약하는 기능, 특정 임계값 아래로 떨어지면 알림을 보내는 기능도 아직 없다. 이런 것들이 갖춰지면 루프가 훨씬 자연스럽게 돌아가겠지만, 지금은 담당자가 직접 주기를 관리해야 한다.

이 한계들을 적는 이유는, "완성됐다"고 말하지 않기 위해서다. 우리가 지금 어디에 있고, 어디로 가려는지를 같이 보여주는 것이 이 시리즈의 톤이다.

마무리 — 루프가 품질을 만든다

ViewCheck LLM 분석이 '활용'의 맥락에서 실제로 무엇을 의미하는지, 이 편에서 집중해서 다뤘다.

결론은 단순하다. 분석 → 개선 → 재진단. 이 루프를 돌리는 것이 공공 웹 품질을 '점수로 관리'하는 것의 본질이다.

1회성 점검은 스냅샷이다. 어느 한 시점의 상태를 찍어두는 것. 반면 루프는 영상이다. 어떤 방향으로, 어떤 속도로 변하고 있는가를 보는 것. 스냅샷으로는 "지금 어디 있는가"를 알 수 있지만, "어떻게 관리되고 있는가"는 알 수 없다. 루프가 있어야 관리가 된다.

영국 GDS가 1,203개 공공 웹사이트를 모니터링하고 26,171건의 문제 중 13,882건을 수정하는 과정에서 얻은 것도 이것이다. 발견 → 통보 → 개선 → 확인이라는 루프가 실제로 작동했을 때, 단일 점검으로는 절대 달성할 수 없는 규모의 개선이 이루어진다(GOV.UK, 2024). 루프는 규모를 만든다.

ViewCheck가 그 루프의 한 부분이 될 수 있기를 바란다. URL을 넣고 결과를 받는 것을 넘어, 그 결과가 개선으로 연결되고, 개선이 재진단으로 확인되고, 그 확인이 다음 루프의 출발점이 되는 것. 이 흐름이 조직 안에서 자연스럽게 돌아가는 상태 — 그게 우리가 이 기능으로 만들고 싶은 것이다.

당연히 아직 갈 길이 멀다. 트렌드 뷰, diff 비교, 재진단 예약, 알림… 우리가 지금 만들어가고 있는 것들이다. 이 편에서 말한 내용 중 일부는 "이미 되는 것"이고, 일부는 "이렇게 하면 더 잘 된다는 것"이고, 일부는 "우리가 가려는 방향"이다. 그 구분이 항상 명확하진 않았을 수도 있다. 다음 편들에서 더 구체적인 기능과 사례를 통해 채워나가겠다.

이 시리즈의 다음 편에서 이어진다.

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 검증했다. 표준·공식 문서와 국내외 연구·기사를 함께 실었다.

국내 — 공식 기준 / 정책자료

행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부 개정 안내 (행정안전부고시 제2025-46호, 2025. 6. 25. 시행). 행정안전부 법령정보. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
KRDS(범정부 UI/UX 디자인시스템) 공식 사이트. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/
행정안전부, "누구나 쉽게 사용할 수 있는 공공 웹·앱 혁신, '범정부 UI/UX 디자인시스템(KRDS)'으로부터" 보도자료. https://www.mois.go.kr/frt/bbs/type010/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000008&nttId=115144

해외 — 디자인 시스템 / 접근성 모니터링 / 품질 방법론

GOV.UK, "Accessibility monitoring of public sector websites and mobile apps from 2022 to 2024", Government Digital Service, 2024. https://www.gov.uk/government/publications/accessibility-monitoring-of-public-sector-websites-and-mobile-apps-from-2022-to-2024/accessibility-monitoring-of-public-sector-websites-and-mobile-apps-from-2022-to-2024
GDS Blog, "What GDS has found from public sector accessibility monitoring", Accessibility in government, 2024년 12월 17일. https://accessibility.blog.gov.uk/2024/12/17/what-gds-has-found-from-public-sector-accessibility-monitoring/
GDS Blog, "How organisations respond to accessibility monitoring", Accessibility in government, 2023년 8월 23일. https://accessibility.blog.gov.uk/2023/08/23/how-organisations-respond-to-accessibility-monitoring/
GOV.UK, "Public sector website and mobile application accessibility monitoring". https://www.gov.uk/guidance/public-sector-website-and-mobile-application-accessibility-monitoring
PECB, "The Plan-Do-Check-Act (PDCA) Cycle: A Guide to Continuous Improvement". https://pecb.com/en/article/the-plan-do-check-act-pdca-cycle-a-guide-to-continuous-improvement
ASQ (American Society for Quality), "How to Measure Continuous Improvement", Quality Progress. https://asq.org/quality-progress/articles/how-to-measure-continuous-improvement
ASQ, "Continuous Improvement Model". https://asq.org/quality-resources/continuous-improvement
U.S. Web Design System (USWDS), "Website standards" — USWDS Maturity Model. https://designsystem.digital.gov/website-standards/
AllAccessible, "Website Accessibility Audit: Complete 2025 WCAG 2.2 Guide + Free Template". https://www.allaccessible.org/blog/website-accessibility-audit-guide-wcag-template
Skynet Technologies, "WCAG 2.2 as an ISO accessibility standard" (ISO/IEC 40500:2025). https://www.skynettechnologies.com/blog/wcag-2.2-as-an-iso-standard-latest-compliance-expectation-for-businesses-in-2025
Nielsen Norman Group, "UX Metrics & ROI" 관련 보고서 및 아티클 (UX 벤치마킹·측정·추적 방법론). https://www.nngroup.com/reports/ux-metrics-roi/