위반 846개, 무엇부터 고치나 — 개선 로드맵 자동 생성의 우선순위 알고리즘

severity·영향·난이도를 한꺼번에 고려해 "지금 당장 고쳐야 할 것"을 정렬하기까지

---

들어가며 — "결과가 나왔는데, 어디서부터 시작하죠?"

분석이 끝난 뒤의 장면을 상상해 보자.

ViewCheck LLM 분석이 완료되면 채팅에 결과 카드가 차곡차곡 쌓인다. 종합 점수, 카테고리별 성적, 접근성 항목 미통과 목록, 보안 헤더 현황, 반응형 이슈, SEO 체크리스트… 그리고 '오류 리스트' 카드를 열면 KRDS 846개 규칙 중 미통과 판정을 받은 항목들이 죽 펼쳐진다.

숫자가 크다. 어떤 사이트는 미통과가 200개가 넘는다. 어떤 사이트는 100페이지를 분석했더니 "같은 위반이 전 페이지에 걸쳐 반복"이라는 결과가 나온다. 이 상황에서 담당자는 어김없이 같은 질문을 한다.

"알겠는데, 그래서 어디서부터 시작하면 되죠?"

이게 별것 아닌 것처럼 들릴 수 있지만, 사실 이 질문은 꽤 심각한 문제를 담고 있다. 200개의 위반 목록을 앞에 두고 "중요한 것부터 해"라는 말은 아무 도움이 안 된다. 무엇이 중요한지를 판단하는 기준이 필요하고, 그 기준으로 정렬하는 로직이 필요하며, 그 결과를 "Phase 1에는 이것, Phase 2에는 저것"처럼 단계로 나눠주는 구조가 있어야 담당자가 실제로 움직일 수 있다.

ViewCheck LLM 분석의 24가지 기능 중 하나인 '개선 로드맵' 카드는 그 질문에 답하려는 시도다. 이 편에서는 그 로드맵 카드 뒤에서 작동하는 우선순위 알고리즘이 어떻게 설계되어 있는지, 어떤 고민을 거쳤는지, 그리고 어디가 아직 부족한지를 솔직하게 풀어보려 한다.

---

'무엇부터 고칠 것인가'가 왜 어려운가

직관적으로 생각하면 답이 쉬워 보인다. "제일 심각한 것부터 고치면 되지 않나?" 맞는 말이다. 그런데 "제일 심각한 것"이 뭔지를 어떻게 판단하느냐가 문제다.

KRDS 규칙 하나를 예로 들어보자. CP-001이라는 규칙이 미통과를 받았다. 이 규칙이 심각한지 아닌지는 맥락에 따라 달라진다.

• 그 규칙이 사용자의 핵심 태스크(로그인, 신청서 제출, 검색)를 직접 막는 규칙인가?
• 그 위반이 사이트의 한 페이지에서만 나타나는가, 아니면 100페이지 모두에서 반복되는가?
• 그 규칙을 고치려면 얼마나 많은 작업이 필요한가? CSS 한 줄 수정으로 끝나는가, 아니면 컴포넌트 전면 재설계가 필요한가?
• 그 규칙 위반이 법적 의무(접근성 법령)와 관련이 있는가, 아니면 권고 수준인가?

이 네 가지 변수가 모두 "심각도"에 영향을 미친다. 그런데 이 변수들이 때로는 서로 충돌한다. severity가 높아도(=이론적으로 나쁜 규칙) 고치는 데 드는 노력이 어마어마하다면 당장 Phase 1에 넣기 어렵다. 반대로 severity가 낮아도 고치는 건 CSS 한 줄인데 100페이지 모두에 걸쳐 반복된다면, 빠르게 고쳐서 전체 점수를 끌어올리는 게 현실적으로 나을 수 있다.

이처럼 "무엇부터 고칠 것인가"는 하나의 변수가 아니라 여러 변수의 합산으로 결정되는 다차원 문제다. 그리고 이 다차원 문제를 자동으로, 일관성 있게 처리하는 알고리즘을 만드는 것 — 그게 우리가 씨름하는 과제다.

---

우선순위 결정 프레임워크들 — 선배들의 고민

우리가 처음부터 이 문제를 혼자 생각한 건 아니다. "우선순위를 어떻게 매길 것인가"는 소프트웨어 개발의 오랜 숙제이고, 그 답으로 제안된 프레임워크들이 여럿 있다. 우리가 로드맵 알고리즘을 설계하면서 참고한 것들을 먼저 소개한다.

RICE 스코어링 — Intercom이 만든 단순 공식

RICE는 Reach(영향 범위) × Impact(임팩트) × Confidence(확신도) ÷ Effort(투입 노력)의 약자다. Intercom이 내부 의사결정 개선을 위해 개발한 프레임워크로, 점수가 높을수록 먼저 해야 할 일이다(Intercom Blog, "RICE: Simple prioritization for product managers").

공식 자체는 단순하다. 어떤 작업이 100명의 사용자에게 영향을 미치고(Reach=100), 임팩트는 "높음"(Impact=2), 확신도는 80%(Confidence=0.8), 투입 노력은 2 person-month(Effort=2)라면 RICE 스코어는 (100 × 2 × 0.8) / 2 = 80이다.

RICE의 장점은 의사결정의 편향을 줄여준다는 데 있다. 그냥 "중요할 것 같다"는 직관 대신, 변수를 명시적으로 숫자로 표현하게 만든다. ProductPlan에 따르면 RICE는 제품 관리자들이 이해관계자에게 우선순위 결정을 방어하는 데 도움을 주는 도구이기도 하다(ProductPlan, "RICE Scoring Model").

다만 RICE 스코어는 맹목적으로 따를 것이 못 된다. Intercom 스스로도 "어떤 작업이 다른 작업의 선행 조건이 되는 경우, 점수가 낮아도 먼저 해야 할 수 있다"고 강조한다. 알고리즘이 낸 숫자는 판단의 보조 도구이지, 그 숫자가 판단 자체를 대체할 수는 없다는 것이다.

MoSCoW 방법 — "반드시 해야 하는 것"부터

MoSCoW는 Must have / Should have / Could have / Won't have의 약자다. 1994년 Dai Clegg가 개발하고 DSDM(Dynamic Systems Development Method) 방법론에서 처음 광범위하게 사용된 이후, Scrum이나 애자일 방법론 전반에서 요구사항 분류 도구로 쓰인다(Agile Business Consortium, "MoSCoW Prioritisation").

MoSCoW의 핵심은 단순화다. RICE처럼 복잡한 수치 계산 없이, 각 요구사항을 "이게 없으면 출시 불가" / "있으면 좋지만 없어도 감" / "여유 있으면 고려" / "이번에는 안 한다"의 네 바구니에 던져 넣는다. Agile Business Consortium은 Must have 항목이 전체 노력의 60%를 초과하면 프로젝트 성공 확률이 떨어진다고 조언한다 — Must have가 너무 많으면 결국 "다 Must have"가 되어 아무 의미 없어지기 때문이다.

KRDS 개선 로드맵에 MoSCoW를 적용한다면 "법령 의무 위반"은 Must have, "KRDS 가이드 권고 위반"은 Should have 혹은 Could have로 분류하는 식의 매핑이 가능하다.

영향-노력 매트릭스 — 2×2로 자르기

가장 직관적인 프레임워크 중 하나는 단순한 2×2 매트릭스다. X축은 고치는 데 드는 노력(Effort), Y축은 고쳤을 때 기대되는 임팩트(Impact). 이 두 축으로 4개의 사분면이 만들어진다.

• 고임팩트 × 저노력 (Quick Win): 지금 당장 해야 할 것.
• 고임팩트 × 고노력 (Major Projects): 계획적으로 접근해야 할 것.
• 저임팩트 × 저노력 (Fill-ins): 짬날 때 해도 되는 것.
• 저임팩트 × 고노력 (Thankless Tasks): 하지 않는 게 나은 것.

Product School에 따르면 이 Impact-Effort 매트릭스는 제품 개발뿐 아니라 기술 부채 해소 계획에도 광범위하게 활용된다(ProductSchool, "Impact Effort Matrix & How to Use One"). 기술 부채 처리 분야의 모범 사례로는 "전체 개발 역량의 15~20%를 부채 해소에 배분하라"는 제안도 있다.

위험 기반 우선순위 — CVSS의 교훈

보안 취약점 분야에는 CVSS(Common Vulnerability Scoring System)라는 오래된 우선순위 도구가 있다. 취약점의 심각도를 0~10 사이 숫자로 표현하고, 그 점수에 따라 패치 우선순위를 결정하는 방식이다. Phoenix Cyber에 따르면 CVSS는 최악의 시나리오를 가정하고 취약점의 본질적 심각도를 측정하는 표준 프레임워크다(Phoenix Cyber, "Common Vulnerability Scoring System (CVSS)").

그런데 보안 업계는 이제 "CVSS만으로는 부족하다"는 컨센서스에 도달했다. Picus Security는 "CVSS는 당신의 환경을 고려하지 않는다"고 지적한다(Picus Security, "Vulnerability Prioritization: Why CVSS Isn't Enough"). 이론적으로 심각도가 9.8인 취약점도, 당신의 시스템에서 실제로 악용 가능하지 않다면 우선순위를 낮출 수 있다. 반대로 CVSS 점수는 낮아도 당신의 핵심 자산에 직접 닿는 취약점이라면 최우선으로 처리해야 한다.

이 교훈이 KRDS 개선 로드맵에도 그대로 적용된다. "이 규칙의 severity가 높다"는 것만으로 우선순위를 정하면 안 된다. 그 위반이 이 사이트의 어떤 기능에 영향을 미치는지까지 같이 봐야 한다.

---

접근성 분야의 우선순위 — Deque와 WebAIM이 쌓아온 방법론

KRDS 846규칙의 상당 부분은 접근성(accessibility)과 맞닿아 있다. 그래서 접근성 전문 기관들이 이미 정리해 둔 우선순위 프레임워크가 우리에게 특히 유용한 참고점이 된다.

Deque의 5단계 severity 체계

Deque는 웹 접근성 자동화 엔진인 axe-core를 만든 회사로, 접근성 위반의 심각도를 5단계로 분류한다.

• Blocker (차단): 사용자가 핵심 태스크를 아예 완료하지 못하게 막는 위반. 예: 키보드 트랩, 폼 제출 불가.
• Critical (치명적): 핵심 기능 접근을 크게 저하시키는 위반. 예: 버튼 라벨 없음, 이미지 대체 텍스트 없음.
• Serious (심각): 경험을 상당히 떨어뜨리는 위반. 예: 색상 대비 불충분, 폼 레이블 없음.
• Moderate (보통): 눈에 띄지만 핵심 태스크를 완전히 막지는 않는 위반.
• Minor (경미): 엣지 케이스이거나 관례 위반 수준.

Deque는 "우선순위 결정의 첫 번째 물결에서 가장 실용적인 방법은 impact category로 분류하는 것"이라고 말한다(Deque, "Accessibility Prioritization: Tactical Roadmap II"). 특히 Blocker와 Critical 위반은, 그것이 사용자가 로그인하거나 폼을 제출하거나 콘텐츠를 탐색하는 것을 막는다면, 무조건 가장 먼저 해소해야 한다.

axe-core의 GitHub 이슈 스레드(#2798)를 보면, 이 4단계 severity 분류가 단순히 "나쁜 정도"를 재는 게 아니라 사용자의 장애 정도와 태스크 완료 가능성이라는 두 축을 교차해서 결정된다는 걸 알 수 있다. 예컨대 키보드 사용자가 아예 접근 불가인 경우는 Critical, 스크린 리더 사용자에게 정보가 충분히 전달되지 않지만 우회 방법이 있는 경우는 Serious로 분류되는 식이다.

WebAIM의 severity rating — 빈도까지 고려하라

WebAIM은 "접근성 위반 심각도 평가로 개선 우선순위를 정하라(Using Severity Ratings to Prioritize Web Accessibility Remediation)"는 글에서 단순히 위반 하나의 심각도를 보는 것을 넘어, 빈도(frequency)와 함께 봐야 한다고 강조한다(WebAIM Blog, "Using Severity Ratings to Prioritize Web Accessibility Remediation").

어떤 위반이 Serious 수준이어도 사이트 한 구석 페이지에서만 발생한다면, Moderate 수준이어도 모든 페이지의 모든 링크에서 반복되는 위반보다 덜 시급할 수 있다. 빈도와 심각도를 두 축으로 놓는 매트릭스를 사용하면, "심각하고 자주 발생하는" 위반이 가장 높은 우선순위를 받는다.

접근성 전략의 또 다른 관점 — 사이트임프루브

Siteimprove는 "WCAG 체크리스트를 넘어서, 사용자 여정(user journey)에 접근성을 매핑하라"는 관점을 제시한다(Siteimprove, "Map Accessibility to User Journeys: Beyond WCAG Checklists"). 규칙 위반 목록 자체보다, 사용자가 실제로 그 사이트에서 무엇을 하려 하는가를 먼저 파악한 뒤 그 경로에 걸리는 위반을 우선 해소하라는 것이다.

공공 웹사이트에서 사용자의 핵심 여정은 대개 "공지사항 확인", "민원 신청", "증명서 발급", "담당 부서 검색"처럼 명확하다. 이 핵심 여정에 걸리는 위반이 사이드 페이지의 위반보다 당연히 먼저다.

---

ViewCheck 로드맵 알고리즘 — 설계 원칙 세 가지

다양한 프레임워크를 검토한 뒤, ViewCheck 로드맵 알고리즘의 설계 원칙을 세 가지로 정리했다.

원칙 1: 단일 변수로 판단하지 않는다

앞서 말한 것처럼, severity 하나로 우선순위를 결정하면 안 된다. ViewCheck 로드맵은 최소 세 가지 변수를 조합한다.

1. severity (위반의 심각도): P0/P1/P2/P3의 4단계로 분류. P0는 "사용자 핵심 태스크를 직접 차단하는 치명적 위반", P1은 "준법 의무와 직결된 위반", P2는 "UX와 디자인 일관성에 영향", P3는 "권고 수준 개선".

2. reach (영향 범위): 그 위반이 사이트 전체의 몇 퍼센트 페이지에서 발생하는가. 다중 페이지 분석(100+ 페이지)을 돌리면 각 위반이 몇 개 페이지에서 반복됐는지가 집계된다. 1페이지만 해당이면 낮은 reach, 80페이지에서 같은 패턴이 반복되면 높은 reach.

3. effort (수정 난이도): 이 위반을 고치는 데 얼마나 많은 작업이 필요한가. 우리는 이것을 미리 정해둔 규칙별 krds-fix-templates.json에서 가져온다. 예를 들어 "색상 대비 CSS 값 수정"은 easy, "전체 네비게이션 컴포넌트 ARIA 재구조화"는 hard 식으로 사전에 태그된 값이다.

이 세 변수를 조합해서 최종 우선순위 스코어를 만든다. RICE와 비슷한 발상이지만, KRDS 도메인에 맞게 변수를 재정의한 버전이다.

원칙 2: 법령 의무는 별도 트랙으로 올린다

공공기관의 웹 담당자에게는 특수한 압박이 있다. 단순히 "점수가 낮다"가 아니라, "법령 위반"이 될 수 있는 항목이 있기 때문이다.

행안부 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25.) 은 공공 웹의 품질 기준을 7대 영역으로 규정하고 있으며, 특히 접근성 영역은 「장애인차별금지 및 권리구제 등에 관한 법률」과도 연결된다. 접근성을 지키지 않는 공공기관 웹사이트는 법적 분쟁의 대상이 될 수 있다.

이런 맥락에서 ViewCheck 로드맵은 severity×reach×effort의 공통 스코어와는 별도로, 법령 의무와 직결된 규칙들은 별도 "Compliance 트랙"으로 분리해서 Phase 1에 강제 배치한다. 알고리즘이 낸 스코어가 낮아도, 법적 의무인 항목은 최우선이다. 이건 MoSCoW의 "Must have는 반드시"라는 원칙과 일맥상통한다.

원칙 3: 실현 가능한 단계로 쪼갠다

로드맵의 본래 목적은 "무엇을 해야 하는가"를 넘어, "이번 스프린트/이번 달/이번 분기에 무엇을 할 수 있는가"를 제시하는 데 있다. 위반 목록을 우선순위 순서로 쭉 나열하는 것만으로는 충분하지 않다.

ViewCheck 로드맵은 결과를 **3~4단계(Phase)**로 묶어 제시한다.

• Phase 1 (즉시 조치, 0~4주): P0·P1 위반 중 effort가 easy 또는 medium이고 reach가 높은 것들.
• Phase 2 (단기 계획, 1~3개월): P1·P2 위반 중 effort가 medium, 또는 P0이지만 effort가 hard인 것들.
• Phase 3 (중기 계획, 3~6개월): P2·P3 위반 중 reach가 낮거나 effort가 hard인 것들.
• Phase 4 (장기 과제, 6개월 이상): 구조적 개편이 필요한 근본적 위반, 또는 KRDScan Vision AI가 감지한 비표준 UI 컴포넌트의 전면 교체 등.

이 단계화가 중요한 이유는, 담당자가 "일단 Phase 1부터 외주사에 전달하면 된다"는 행동 가능한 단위를 갖게 되기 때문이다.

---

severity 분류의 실제 — P0~P3가 어떻게 결정되는가

이론적으로 설명한 P0~P3 분류가 실제로 어떻게 작동하는지 좀 더 구체적으로 들어가 보자.

P0: 핵심 태스크 차단 위반

가장 높은 우선순위 P0는 "이 위반이 있으면 사용자가 핵심 기능을 아예 이용할 수 없다"는 기준으로 정의된다.

예를 들어 폼 제출 버튼에 접근 가능한 이름(accessible name)이 없어서 스크린 리더 사용자가 그 버튼이 무엇인지 알 수 없는 경우, 또는 모달 팝업에 키보드 포커스가 갇혀서(keyboard trap) 키보드만 쓰는 사용자가 페이지를 벗어나지 못하는 경우다. Deque axe-core에서 critical로 분류되는 위반들이 대부분 P0에 해당한다.

P0 위반의 특징은, reach가 낮아도(한 페이지에서만 발생해도) Phase 1에 들어간다는 점이다. 민원 신청서 페이지가 딱 한 장이어도, 거기서 폼이 작동 안 하면 그 사이트의 존재 이유가 무너진다.

P1: 준법 의무 직결 위반

P1은 법령 의무와 연결된 위반이다. 「장애인차별금지법」 적용 대상 기관(공공기관은 대부분 해당)에서 접근성 관련 KWCAG 34개 항목을 충족하지 못하는 위반, 또는 행안부 지침이 명시적으로 요구하는 7대 품질 영역 핵심 항목 위반이 P1으로 분류된다.

P1도 severity가 크다. 다만 P0와의 차이는, P0는 기능 자체의 완전한 차단이라면, P1은 의무 이행 실패다. 시민이 해당 기능을 이용할 수 있을 수도 있지만, 법적 의무를 다하지 않은 상태인 것이다.

P2: UX·디자인 품질 위반

P2는 법령 의무보다는 KRDS 디자인 시스템의 권고 기준, 즉 디자인 스타일(DS), 컴포넌트(CP) 일부, 기본 패턴(BP) 권고 사항에 해당하는 위반이다. 사이트가 기능은 하지만 KRDS의 시각적 일관성·UX 패턴을 따르지 않는 경우다.

예를 들어 버튼의 색상 토큰이 KRDS 공식 토큰과 다른 경우, 간격(spacing) 수치가 8pt 그리드를 따르지 않는 경우, 카드 컴포넌트의 구조가 KRDS 공식 컴포넌트 스펙과 다른 경우 등이 P2다. 이용자의 핵심 태스크를 직접 막지는 않지만, 정부 디자인 시스템의 일관성을 해친다.

P3: 권고 수준 개선

P3는 명시적 규정 위반은 아니지만 KRDS 공식 문서가 "권고한다"고 표현하는 수준의 개선 사항이다. 한국어 가이드라인의 "~하는 것이 좋다", "~를 고려하라" 표현에 해당하는 항목들이 이 범주에 들어온다. 시스템 여유가 생겼을 때 챙기면 좋은 것들이다.

---

다중 페이지 분석과 로드맵의 결합 — reach가 바꾸는 우선순위

ViewCheck의 가장 중요한 설계 원칙 중 하나는 "다중 페이지 분석이 기본"이다. 그리고 이 다중 페이지 데이터가 로드맵 알고리즘에서 어떤 역할을 하는지가 흥미롭다.

단일 페이지 분석의 맹점

메인 페이지 한 장만 분석하면 놓치는 것들이 있다. 실제로 우리가 여러 공공 사이트를 분석해 보면, 메인 페이지는 비교적 잘 만들어져 있지만 신청 화면이나 검색 결과 페이지에서 동일한 패턴의 위반이 대량으로 반복되는 경우가 많다.

예를 들어 어떤 사이트에서 "폼 라벨 연결 누락"이라는 위반을 발견했다고 하자. 메인 페이지 분석에서는 이 위반이 1건으로 집계된다. 하지만 100페이지 분석을 돌리면, 이 사이트의 모든 입력 폼 — 검색창, 로그인 폼, 신청서, 설문 폼 — 에서 동일한 패턴이 반복된다는 사실이 드러난다. reach가 1페이지에서 80페이지로 뛰는 것이다.

reach가 높다는 것은 두 가지 의미를 동시에 갖는다. 하나는 "이 위반의 영향을 받는 사용자 수가 훨씬 많다"는 것이고, 또 하나는 "이 위반이 개별 페이지의 문제가 아니라 공통 컴포넌트나 템플릿의 문제"라는 신호다. 공통 컴포넌트 하나를 고치면 80개 페이지가 한꺼번에 개선된다. 이건 "고노력 × 고임팩트"가 아니라 사실상 "단기 노력으로 최대 임팩트"인 케이스다.

반복 위반의 특별 처리

ViewCheck 로드맵 알고리즘은 동일한 규칙 위반이 여러 페이지에서 반복될 때, 단순히 건수를 더하는 것에서 한 발 더 나아간다. 위반이 공통 컴포넌트에서 기인한다고 판단되면, 이를 개별 위반 N개가 아니라 "1개의 루트 원인 수정으로 N개 해소 가능"으로 표현한다.

이건 개발자에게 매우 중요한 신호다. "이 폼 컴포넌트 하나 고치면 신청 관련 페이지 27개의 같은 위반이 전부 사라집니다"라는 메시지를 전달하면, 그 수정의 ROI(투자 대비 수익)가 바로 보인다. 외주사에 "이거 고쳐 주세요"라고 요청할 때도, 왜 이게 중요한지 수치로 설명할 수 있다.

다중 페이지 OR 로직 — 페이지 하나라도 fail이면 사이트 fail

우리의 또 다른 원칙은 "다중 페이지 분석에서 어느 한 페이지라도 fail이면, 그 규칙은 사이트 전체에서 fail"이다. 메인이 pass여도 신청 화면이 fail이면, 그 사이트는 그 규칙에서 fail이다.

이 OR 로직이 로드맵과 결합하면, "모든 페이지에서 fail"인 위반과 "95페이지에서 pass, 5페이지에서 fail"인 위반이 상당히 다르게 취급된다. 전자는 구조적 문제이고, 후자는 예외적 발생이다. 후자의 경우 그 5페이지를 개별적으로 수정하는 전략이 더 효율적일 수 있다.

---

KRDS 규칙별 fix 메타데이터 — 알고리즘의 숨은 재료

로드맵 알고리즘이 "이 위반을 고치는 데 얼마나 걸리는지"를 추정할 수 있는 이유는, ViewCheck에 krds-fix-templates.json이라는 데이터가 있기 때문이다.

이 JSON 파일에는 846개 각 규칙별로 다음 정보가 담겨 있다.

• howToFix: 이 위반을 고치려면 구체적으로 어떤 조치를 해야 하는가의 설명.
• estimatedTime: 수정에 예상되는 시간 (예: "30분", "2-4시간", "1-2일").
• difficulty: easy / medium / hard 중 하나.
• priority (P0~P3): 우선순위 등급.

이 메타데이터는 처음부터 자동으로 만들어진 게 아니다. KRDS 공식 문서를 읽고, 실제 개발 현장의 수정 경험을 반영해서, 규칙 하나하나에 대해 수작업으로 채워 넣은 것들이다. 아직 완성도가 100%는 아니고, 특히 estimatedTime은 맥락에 따라 편차가 크기 때문에 "추정치"로 받아들여야 한다.

그럼에도 이 데이터가 중요한 이유는, 알고리즘이 "severity만 보고" 위반을 정렬하는 대신 "severity + 수정 난이도 + 영향 범위"를 조합할 수 있게 해주기 때문이다.

예를 들어 P0이지만 hard 난이도인 위반은 Phase 2로 들어가고, P2이지만 easy 난이도이면서 reach가 전체 페이지의 70%인 위반은 Phase 1 후반부에 들어갈 수 있다. 이런 세밀한 조정이 가능한 것은 이 fix 메타데이터 덕분이다.

---

공공기관 맥락에서의 특수성 — 준법과 납기가 동시에 온다

ViewCheck가 주로 다루는 대상이 공공기관 웹사이트라는 점은 로드맵 알고리즘 설계에 특수한 제약을 더한다.

감사 대비 증빙

공공기관 웹 담당자에게 감사는 언제든 올 수 있는 현실이다. 행안부나 NIA(한국지능정보사회진흥원)가 사이트 품질을 점검하러 오거나, 국정감사에서 "접근성 위반이 몇 개냐"는 질문이 나오거나. 이런 상황에서 담당자는 단순히 "우리가 위반을 고쳤다"는 것만이 아니라, "언제 어떤 기준으로 어떤 것을 먼저 고쳤는지"의 이력과 근거를 제시해야 한다.

이 맥락에서 로드맵은 단순히 "할 일 목록"이 아니라 개선 이력의 골격이 된다. "Phase 1에서 P0 위반 X건을 YYYY-MM-DD까지 완료하기로 계획하고, 완료했다"는 기록이 감사 대비 증빙이 되는 것이다. 따라서 로드맵 알고리즘의 결과물은 엑셀이나 PDF로 내보낼 수 있어야 하고, 날짜와 담당자가 붙을 수 있는 형태여야 한다.

예산 사이클과 용역 단계

공공기관은 대개 1년 단위 예산을 짜고, 웹사이트 개선은 용역 발주를 통해 진행된다. 즉 "지금 당장 고쳐"라는 명령이 내려도, 실제 실행은 "내년도 예산에 반영 → 하반기 용역 발주 → 연말 완료"의 사이클을 따른다.

이 현실을 무시하면 로드맵이 현실 적합성을 잃는다. "이번 달 안에 모두 고쳐라"는 Phase 1 계획은 사실상 불가능할 수 있다. 그래서 ViewCheck의 로드맵 시간 단위는 기본값이 아니라, 사이트의 개선 역량과 운영 주기를 입력하면 그에 맞게 조정되는 방향으로 발전시키려 한다. 아직 완성된 기능은 아니지만, 이 방향이 맞다는 건 우리가 여러 공공기관 담당자들과 대화하면서 계속 확인하는 부분이다.

---

알고리즘의 한계 — 솔직하게 말하는 것들

이 시리즈의 톤 원칙대로, 우리가 아직 해결하지 못한 부분을 솔직하게 적어야 한다.

1. 수정 난이도 추정의 부정확성

krds-fix-templates.json의 estimatedTime과 difficulty는 "평균적인" 상황을 가정한다. 하지만 실제 수정 난이도는 사이트의 기술 스택, 프레임워크, 개발 팀의 숙련도에 따라 천차만별이다. 레거시 JSP 기반 사이트에서 ARIA 속성을 고치는 것과, 최신 React 기반 사이트에서 고치는 건 전혀 다른 작업이다.

우리는 이 문제를 완전히 풀지 못했다. 현재는 "평균 추정치"를 제공하되, 사용자가 직접 수정 난이도를 오버라이드할 수 있는 기능을 고민 중이다.

2. 의존성(dependency) 처리

RICE 스코어 설명에서도 언급됐듯, "어떤 작업이 다른 작업의 선행 조건"인 경우가 있다. KRDS에서도 마찬가지다. 예를 들어 색상 토큰을 교체하는 작업(DS 규칙)이 완료되어야, 그 토큰을 사용하는 컴포넌트들의 색상 대비 관련 위반(CP·DS 규칙)이 자연히 해소되는 경우가 있다.

현재 알고리즘은 이런 의존성을 자동으로 감지하지 못한다. 각 위반을 독립적으로 점수를 매기고 정렬하는 수준이다. 의존성 그래프를 그려서 "이 작업을 하면 저 작업이 자동 해소된다"는 연쇄를 표현하는 것은 다음 단계 과제다.

3. 사이트 고유 맥락의 부재

위에서 언급한 "사용자 핵심 여정"을 알아야 로드맵의 초점을 잡을 수 있다. 그런데 ViewCheck는 사이트를 외부에서 분석하기 때문에, "이 사이트에서 시민이 가장 많이 하는 행동이 무엇인가"를 자동으로 알 수 없다. 사이트 운영자만이 아는 맥락이다.

현재는 "검색, 로그인, 신청, 민원 처리"를 공공 웹의 일반적인 핵심 여정으로 가정하고, 그 경로에 걸리는 규칙들에 가중치를 높이는 방식을 쓴다. 하지만 사이트마다 핵심 여정이 다를 수 있고, 담당자가 이 맥락을 입력할 수 있는 인터페이스를 만드는 것도 앞으로의 과제다.

4. 수정 후 재분석 필요

로드맵은 현재 상태의 스냅샷이다. Phase 1 작업을 완료한 뒤 재분석을 하면, 그 결과가 달라져 있고 Phase 2 계획도 업데이트가 필요하다. "개선 → 재분석 → 로드맵 갱신"의 사이클을 얼마나 매끄럽게 만들 수 있는가도 미해결 과제다.

---

해외 공공기관은 어떻게 하는가 — GOV.UK의 사례

해외 사례를 잠깐 들여다보자. 영국 정부디지털서비스(GDS)는 공공 섹터 웹사이트의 접근성 모니터링을 꾸준히 수행하고, 그 결과를 공개한다.

GDS의 2022~2024년 접근성 모니터링 보고서에 따르면, 1,203개 웹사이트와 21개 모바일 앱이 모니터링됐고, 거의 모든 테스트 대상에서 접근성 문제가 발견됐다(UK Government, "Accessibility monitoring of public sector websites and mobile apps from 2022 to 2024"). 이 규모의 데이터는 "개선이 완료된 사이트"보다 "여전히 개선 중인 사이트"가 압도적으로 많다는 현실을 보여준다.

GDS의 접근성 블로그("How organisations respond to accessibility monitoring")는 모니터링 후 기관들이 어떻게 대응하는지를 정리했다. 단계별 오류 보고 방식이 도입되면서 웹 개발자들이 문제를 더 쉽게 처리할 수 있게 됐다는 점이 언급된다(UK Accessibility in Government Blog, 2023). 다시 말해 "단계별로 쪼개서 보여주는 것"이 기관들의 실제 대응 효율을 높인 것이다.

또한 GDS는 2024년 초부터 WCAG 2.2 기준으로 모니터링을 시작하며, 서비스들이 AA 수준 이상을 충족해야 한다고 밝혔다(UK Government, "Get to WCAG 2.2 faster with the GOV.UK Design System", 2024). 기준이 올라가면 새로운 미통과 항목이 생기고, 그만큼 로드맵 갱신이 필요하다 — 이건 영국도, 한국도 마찬가지 상황이다.

GDS의 전략은 두 가지를 동시에 추구한다. 개별 사이트의 위반을 고치게 하는 것과, GOV.UK Design System을 통해 "처음부터 접근성 있는 컴포넌트"를 쓰게 만드는 것. 후자가 훨씬 근본적인 접근이다. 모든 정부 서비스가 공통 디자인 시스템의 접근성 있는 컴포넌트를 쓴다면, 개별 사이트에서 접근성 위반이 발생하는 빈도 자체가 줄어드는 것이다.

KRDS와 ViewCheck의 관계도 이와 유사하다. KRDS 컴포넌트를 제대로 써서 사이트를 만든다면, ViewCheck 분석에서 CP 위반 상당 부분이 처음부터 통과가 된다. 로드맵의 궁극적 목표는 "위반을 고치는 것"을 넘어 "위반이 생기지 않는 개발 문화"를 만드는 것이다.

---

UX 부채와 기술 부채의 교차점 — 로드맵이 다루는 더 넓은 그림

닐슨 노먼 그룹(NN/g)은 "UX debt: How to Identify, Prioritize, and Resolve"라는 글에서 UX 부채(UX debt)를 기술 부채와 유사한 개념으로 정의한다(Nielsen Norman Group, "UX Debt: How to Identify, Prioritize, and Resolve"). 기술 부채가 "빠른 개발을 위해 타협한 코드의 누적 비용"이라면, UX 부채는 "빠른 개발을 위해 타협한 사용자 경험의 누적 비용"이다. 사후에 고치는 비용이 처음부터 제대로 만드는 비용보다 항상 크다.

KRDS 위반 역시 UX 부채이자 기술 부채다. "이 컴포넌트가 ARIA 속성 없이 돌아가고 있다"는 사실은, 기술적으로는 문제없어 보이지만 장애 사용자에게는 사이트 이용을 막는 UX 부채다.

NN/g는 UX 부채를 관리하는 방법으로 "백로그에 추가하기 전에 스프레드시트에서 먼저 우선순위를 정하라"고 권고한다. 많은 항목을 한꺼번에 백로그에 넣으면 팀이 압도당하거나 중요한 항목들이 묻힌다. 소수로 정제한 뒤 백로그에 넣어야 실행으로 이어진다는 것이다.

이건 ViewCheck 로드맵이 추구하는 방향과 정확히 같다. 846개 규칙 중 미통과를 받은 것들을 그대로 개발 팀의 백로그에 던지면 팀이 무너진다. 알고리즘으로 정렬하고, 단계별로 쪼개고, 한 단계에 들어가는 항목 수를 적절히 제한해야 실행 가능한 계획이 된다.

---

비용·MM 추정과 로드맵의 연결 — "얼마나 드나요"

공공기관 담당자가 로드맵을 갖고 예산을 잡으러 가거나 용역 발주를 준비할 때, 반드시 따라오는 질문이 있다. "이거 다 고치면 얼마나 들어요?"

ViewCheck의 24가지 기능 중 '비용·MM' 카드가 바로 이 질문에 답하려는 시도다. 로드맵과 비용 추정은 사실 하나의 데이터에서 나온다.

• Phase 1에 포함된 규칙들의 estimatedTime 합산 → Phase 1 작업 공수(Man-Month) 추정.
• 공수에 공공 IT 용역 단가를 곱하면 → 대략적인 예산 범위.

이 추정이 정확하다고 주장하지는 않는다. 위에서 말한 것처럼 실제 수정 난이도는 사이트 맥락에 따라 크게 달라지기 때문이다. 하지만 "전혀 감이 없는 것"과 "대략의 수량 감"을 구분하는 데는 도움이 된다. 예산 회의에서 "아마 1,000만 원에서 3,000만 원 사이"라는 범위를 제시하는 것과 "모르겠습니다"는 완전히 다른 대화를 만든다.

다만 이 비용 추정은 반드시 "이 추정은 ViewCheck의 기계적 계산이며, 실제 용역 견적과 다를 수 있습니다"라는 면책 조항과 함께 사용해야 한다. 담당자가 이 숫자를 그대로 예산 문서에 적으면 곤란하다.

---

GOV.UK Design System의 우선순위 접근 — "처음부터 잘 만들기"

GOV.UK의 접근성 전략("A new accessibility strategy for the GOV.UK Design System", 2023)은 몇 가지 중요한 원칙을 담고 있다(UK Government Accessibility Blog, "A new accessibility strategy for the GOV.UK Design System"). 그중 우리가 특히 주목하는 부분이 있다.

GOV.UK Design System은 "처음부터 접근성 있게 만들기(accessibility by default)"를 목표로 한다. 디자인 시스템의 모든 컴포넌트와 패턴이 가장 흔히 쓰이는 보조기술과 함께 검증되고, WCAG AA 수준을 충족하게 만들어져 있다. 그래서 이 시스템을 쓰는 서비스는 "내가 접근성 검사를 따로 안 해도 기본값은 접근성 있다"는 출발점에서 시작할 수 있다.

KRDS도 이 방향을 지향하고 있다. KRDS 공식 사이트(krds.go.kr)는 각 컴포넌트가 WCAG와 KWCAG 기준을 어떻게 충족하는지를 문서화하고 있다. 즉 KRDS 컴포넌트를 제대로 구현하면 ViewCheck 분석에서 CP 관련 위반이 많이 해소된다.

이 시각으로 보면 "개선 로드맵"의 이상적인 엔드 게임은 단지 "위반을 다 고쳤다"가 아니라 **"이제부터 KRDS 컴포넌트를 쓰니까 위반이 처음부터 생기지 않는다"**로 전환하는 것이다. 하지만 현실적으로 레거시 사이트에서 이 전환은 점진적일 수밖에 없다. 그 점진적 여정의 지도를 그려주는 것이 로드맵의 진짜 역할이다.

---

자동화와 사람의 역할 분담 — 알고리즘이 대신할 수 없는 것

로드맵을 자동으로 만든다고 해서, 사람의 판단이 필요 없어지는 건 아니다. 오히려 우리는 반대 방향의 위험을 더 경계한다.

자동화된 로드맵이 내놓은 우선순위를 맹목적으로 따르는 것. 이건 Deque가 강조하는 "우선순위는 가이드이지, 절대적 규칙이 아니다"는 원칙을 어기는 것이다. 알고리즘이 낸 결과는 "이 항목들이 이 이유로 중요해 보인다"는 출발점이지, "반드시 이 순서대로 해야 한다"는 명령이 아니다.

사람의 판단이 필요한 영역은 명확하다.

첫째, 담당자만 아는 맥락. 어떤 페이지가 이 사이트에서 실제로 가장 많이 쓰이는지, 어떤 기능이 내부적으로 가장 중요한지는 외부에서 분석해서는 알 수 없다. 로드맵을 받은 담당자가 이 맥락을 더해 조정해야 한다.

둘째, 정치적 맥락. "저 페이지는 올해 용역 범위 밖이라서 못 건드린다", "저 컴포넌트는 내년에 전면 교체 예정이라 지금 고치기 애매하다" 같은 판단은 조직 안에서만 할 수 있다.

셋째, 리소스 현실. 내부 개발팀이 있는 기관과 없는 기관의 실행 가능 범위는 완전히 다르다. 연간 예산 규모, 외주사와의 계약 구조, 팀의 기술 수준에 따라 같은 로드맵도 다르게 실행된다.

알고리즘은 이 세 가지를 모른다. 알고리즘이 할 수 있는 건 "KRDS 규칙과 수집된 데이터를 기반으로, 일반적으로 가장 중요한 순서를 추정하는 것"이다. 그 추정을 현실에 맞게 조정하는 건 사람의 일이다.

이 분업이 명확해야, 사용자가 로드맵을 적절히 활용하고 적절히 의심할 수 있다.

---

LLM이 로드맵에 기여하는 방식 — 근거 설명과 요약

ViewCheck LLM 분석에서 '개선 로드맵' 카드는 단순히 정렬된 위반 목록을 보여주는 데 그치지 않는다. LLM이 각 Phase에 포함된 위반들에 대해 왜 이것이 지금 당장 중요한지를 사람의 언어로 설명하는 역할을 한다.

예를 들어 이런 식이다.

"Phase 1에 포함된 12개 항목 중 7개는 접근성 관련 위반입니다. 이 중 4개는 스크린 리더 사용자가 핵심 기능(신청 폼 제출)을 완료하지 못하게 하는 Critical 수준입니다. 나머지 3개는 키보드 접근 경로에서 발생하는 Serious 수준이며, 이 두 가지를 묶어서 처리하면 공통 컴포넌트 수정으로 해소할 수 있습니다."

이런 설명은 알고리즘이 자동으로 생성하기 어렵다. 정렬된 숫자를 의미 있는 맥락으로 바꾸는 것은 언어 모델이 잘하는 일이다. 다만 이 설명 역시 "추정이다, 확인하라"는 단서가 붙는다. LLM이 생성한 요약을 그대로 공식 보고서에 올리기보다는, 담당자가 검토한 뒤 손을 보아 쓰는 것을 권한다.

RAG(검색 증강 생성)도 여기서 역할을 한다. Phase 1 위반들을 설명할 때, 관련된 KRDS 공식 규칙 원문이나 KWCAG 조항이 참조패널에 같이 뜬다. "이 규칙이 이렇게 말하고 있으니 이 위반이 중요하다"는 근거가 LLM의 말에 공식 출처로 받쳐지는 것이다.

---

다음 단계로 — 로드맵 알고리즘의 발전 방향

지금까지 ViewCheck의 로드맵 알고리즘이 현재 어떻게 작동하는지, 어떤 프레임워크를 참조했는지, 어디가 아직 부족한지를 솔직하게 풀었다. 마지막으로 우리가 이 알고리즘을 어떤 방향으로 발전시키려 하는지 짧게 적어두자.

의존성 그래프 도입

규칙 위반들 사이의 의존성을 표현하는 그래프 구조를 도입하면, "이 작업을 하면 저 작업이 자동 해소된다"는 연쇄를 알고리즘이 인식하고 로드맵에 반영할 수 있다. 예를 들어 디자인 토큰 교체가 완료되면 color-related DS 규칙 20개가 자동 해소된다는 식의 연결을 표현하는 것이다.

사용자 맥락 입력 인터페이스

"이 사이트의 핵심 사용자 여정은 무엇인가", "내부 개발팀이 있는가, 외주 의존인가", "개선 목표 완료 기한은 언제인가" 같은 맥락을 담당자가 채팅으로 입력하면, 그 맥락이 알고리즘에 반영되어 로드맵이 더 현실적으로 조정되는 방향이다.

재분석 사이클 지원

Phase 1 작업 완료 후 재분석을 하면, 로드맵이 자동으로 "Phase 1 달성률"을 계산하고 Phase 2 계획을 갱신하는 루프를 만드는 것. 이렇게 되면 로드맵이 일회성 문서가 아니라 지속적으로 갱신되는 개선 추적 도구가 된다.

사이트 간 벤치마킹 연결

"우리 사이트와 비슷한 규모의 다른 기관이 평균 몇 개월 만에 Phase 1을 완료했는가" 같은 벤치마크 데이터가 쌓이면, 로드맵의 타임라인 추정도 더 현실적으로 만들 수 있다. 물론 이를 위해서는 충분한 데이터 수집과 프라이버시 고려가 선행되어야 한다.

이 발전 방향들이 모두 완성된다면 ViewCheck의 로드맵 카드는 상당히 다른 모습이 될 것이다. 하지만 지금 당장은 "자동으로 우선순위를 정렬하고 단계별 묶음을 제시하는" 수준에서 시작해서, 사용자의 반응을 보며 조금씩 개선하는 중이다.

---

마무리 — "무엇부터?"라는 질문에 답하려는 노력

공공 웹 품질 개선에서 "무엇부터 고칠 것인가"는 단순한 질문 같지만, 사실 severity·reach·effort·법적 의무·사이트 맥락·예산 주기·의존성을 동시에 고려해야 하는 복합적 의사결정이다.

ViewCheck의 개선 로드맵 카드는 그 복합적 의사결정을 자동화하려는 시도다. RICE, MoSCoW, Impact-Effort 매트릭스, Deque의 severity 체계, 위험 기반 우선순위 같은 선배 프레임워크들로부터 영감을 받아, KRDS 846규칙 도메인에 맞게 재정의한 우선순위 알고리즘을 만들었다.

그리고 이 알고리즘이 사람의 판단을 대체할 수 없다는 사실을 알기에, 알고리즘의 결과를 "판단의 출발점"으로, 최종 결정은 사람에게로 돌려주는 방향을 유지하려 한다.

아직 의존성 처리도 부족하고, 수정 난이도 추정도 거칠고, 사용자 맥락을 받는 인터페이스도 완성되지 않았다. "개선 중인 알고리즘이 개선 로드맵을 만든다"는, 약간 재귀적인 상황이기도 하다.

그래도 방향은 맞다고 믿는다. "결과가 나왔는데, 어디서부터 시작하죠?"라는 질문에 의미 있는 답을 건네는 도구를 만드는 것. 우리는 그 답의 완성도를 한 단계씩 높여가는 중이다.

다음 편에서는 LLM 분석 시리즈를 마무리하는 종합 편으로, 30편에 걸쳐 다룬 주제들을 하나의 그림으로 엮어 보겠다.

---

참고문헌

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

1. 행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 행정안전부 법령정보. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636

2. 국가법령정보센터, 「전자정부 웹사이트 품질관리 지침」 행정규칙. https://www.law.go.kr/admRulLsInfoP.do?admRulId=37565

3. KRDS(범정부 UI/UX 디자인시스템) 공식 사이트. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/

4. 행정안전부 보도자료, "누구나 쉽게 사용할 수 있는 공공 웹·앱 혁신, '범정부 UI/UX 디자인시스템(KRDS)'으로부터". https://www.mois.go.kr/frt/bbs/type010/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000008&nttId=115144

해외 — 우선순위 프레임워크 / 접근성 / 품질관리

5. Intercom Blog, "RICE: Simple prioritization for product managers" (Sean McBride). https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/

6. ProductPlan, "RICE Scoring Model" (Glossary). https://www.productplan.com/glossary/rice-scoring-model

7. Agile Business Consortium, "MoSCoW Prioritisation" — DSDM Project Framework Handbook. https://www.agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html

8. Deque Systems, "Accessibility Prioritization: Tactical Roadmap [Part 2]". https://www.deque.com/blog/accessibility-prioritization-tactical-roadmap-part-ii/

9. Deque Systems, "A11y Prioritization: Strategic Plan". https://www.deque.com/blog/accessibility-prioritization-laying-foundation-strategic-plan/

10. WebAIM Blog, "Using Severity Ratings to Prioritize Web Accessibility Remediation". https://webaim.org/blog/severity-ratings/

11. Siteimprove, "Map Accessibility to User Journeys: Beyond WCAG Checklists". https://www.siteimprove.com/blog/map-accessibility-to-user-journeys-beyond-wcag-checklists/

12. UK Government (GDS), "Accessibility monitoring of public sector websites and mobile apps from 2022 to 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

13. UK Government Accessibility Blog, "How organisations respond to accessibility monitoring" (2023). https://accessibility.blog.gov.uk/2023/08/23/how-organisations-respond-to-accessibility-monitoring/

14. UK Government Accessibility Blog, "A new accessibility strategy for the GOV.UK Design System" (2023). https://accessibility.blog.gov.uk/2023/01/06/a-new-accessibility-strategy-for-the-gov-uk-design-system/

15. UK Government Accessibility Blog, "Get to WCAG 2.2 faster with the GOV.UK Design System" (2024). https://accessibility.blog.gov.uk/2024/01/11/get-to-wcag-2-2-faster-with-the-gov-uk-design-system/

16. Nielsen Norman Group, "UX Debt: How to Identify, Prioritize, and Resolve". https://www.nngroup.com/articles/ux-debt/

17. Picus Security, "Vulnerability Prioritization: Why CVSS Isn't Enough". https://www.picussecurity.com/resource/blog/vulnerability-prioritization-why-cvss-isnt-enough

18. Phoenix Cyber, "Common Vulnerability Scoring System (CVSS): A Complete Guide to Vulnerability Scoring & Prioritization". https://phoenixcyber.com/blog/understanding-cvss-vulnerability-prioritization/

19. ProductSchool, "Impact Effort Matrix & How to Use One + Examples". https://productschool.com/blog/product-fundamentals/impact-effort-matrix

20. dequelabs/axe-core GitHub Issue #2798, "Definition of Impact: Critical/Serious/Moderate/Minor". https://github.com/dequelabs/axe-core/issues/2798

---