임원 보고 5분 컷 — ViewCheck LLM 분석이 만들어 주는 것

ViewCheck 종합총평·임원보고서 카드를, 의사결정자가 읽는 보고서로 쓰는 법

---

들어가며 — 보고 전날 밤의 풍경

공공기관 웹사이트 운영을 담당해 본 사람이라면, 이 장면을 알 것이다. 보고 전날 오후 5시. 팀장이 자리로 다가와 말한다. "내일 임원 보고에 우리 사이트 품질 현황도 넣어야 할 것 같은데, 오늘 중으로 한 장 만들어 줄 수 있어요?"

그 말 한 마디가 야근의 시작이다. 사이트 품질 현황이 어디 한 장에 딱 정리되어 있는 자료가 없다. 접근성 점검 결과는 작년 것이고, KRDS 준수율이라는 개념은 들어봤지만 우리 사이트 수치가 얼마인지는 모른다. 보안 헤더가 몇 개인지, 성능 지표가 어느 수준인지, 개선이 필요한 항목이 몇 개인지 — 전부 처음부터 확인해야 한다. 결국 새벽 두 시가 되어서야, 어딘가에서 긁어모은 숫자들을 엑셀에 붙여 넣고 파워포인트로 옮긴 "그럭저럭 읽히는 보고 자료"가 완성된다.

문제는 그 자료가 얼마나 정확한지, 임원이 진짜로 궁금한 것에 대답하고 있는지는 사실 자신이 없다는 것이다.

이 글은 그 야근을 없애자는 이야기가 아니다. 솔직히 말하면, 그 보고가 담아야 하는 내용 자체를 빠르게 뽑아주는 도구가 있다면, 야근의 밀도는 달라질 수 있다는 이야기다. ViewCheck LLM 분석의 24개 결과 카드 중에는 '임원보고서'와 '종합총평'이라는 카드가 있다. 이 두 카드가 무엇을 담고 있고, 어떻게 의사결정 보고에 연결되는지를 이 글에서 풀어보려 한다.

그리고 미리 말해두고 싶은 게 하나 있다. 이 글은 "ViewCheck가 보고서를 만들어 드립니다"를 말하려는 게 아니다. 도구는 도구다. 데이터를 꺼내주고, 구조를 잡아주고, 숫자에 근거를 더해줄 뿐이다. 그 데이터를 맥락 있는 보고로 만드는 건 결국 사람의 몫이다. 우리가 하려는 이야기는, 그 '사람의 몫'에 집중할 수 있도록 나머지를 최대한 줄이는 것이다.

---

---

임원이 보고서에서 찾는 것은 결국 세 가지다

임원 보고는 "많은 정보를 전달하는 것"이 목적이 아니다. 적어도 잘 만들어진 임원 보고는 그렇지 않다. 경영 커뮤니케이션 연구에서 오래전부터 반복적으로 지적해 온 것이 있다. 의사결정자는 시간이 없고, 정보는 넘쳐난다. 그들이 보고서를 읽을 때 실제로 찾는 건 세 가지뿐이다.

첫째, 현황은 어떤가(What's the situation)? 지금 우리 사이트의 품질이 어느 수준인지, 숫자로 빠르게 파악하고 싶다. 장문의 설명보다 명확한 수치와 등급이 더 읽힌다.

둘째, 뭐가 문제인가(What's the problem)? 모든 항목을 다 알고 싶은 게 아니다. 가장 심각한 것, 리스크가 큰 것, 빨리 처리해야 하는 것을 먼저 보고 싶다. 항목이 846개든 1,000개든 임원이 그걸 다 읽는 일은 없다.

셋째, 무엇을 승인해야 하는가(What action is needed)? 보고는 결국 의사결정으로 끝나야 한다. 예산을 투입해야 하는가, 외주 개선을 지시해야 하는가, 그냥 모니터링만 해도 되는가. 이 질문에 대한 답이 없는 보고서는 "그래서 어쩌란 거야"로 끝난다.

이 세 가지는 사실 오래된 원칙이다. 미군은 'BLUF(Bottom Line Up Front)'라는 커뮤니케이션 원칙을 공식 훈령에 담아 사용한다. 미국 육군 훈령 AR 25-50에는 이런 문구가 있다. "육군 문서는 행동 지향적이어야 한다. 첫 문장이나 첫 단락에서 독자에게 이 문서의 목적을 분명히 알려야 한다(Army correspondence is action-oriented; it lets the reader know the purpose of the correspondence in the first sentence or paragraph)."(BLUF, Wikipedia / Animalz.co) 결론을 먼저 말하고, 그다음에 근거를 대라는 것이다. 이건 공공 보고에서도 마찬가지다.

문제는, 대부분의 웹 품질 분석 결과물이 이 원칙과 정반대 구조를 갖는다는 점이다. 항목별 체크리스트, 세부 수치, 기술 용어로 가득 찬 보고서는 "결론을 먼저" 읽어주지 않는다. 담당자가 직접 그 방대한 데이터에서 핵심을 추려 다시 한 장으로 가공해야 한다. 그게 야근의 정체다.

ViewCheck LLM 분석의 '임원보고서' 카드와 '종합총평' 카드는, 그 가공 작업의 상당 부분을 먼저 해두는 방식으로 설계되었다. 물론 완벽하지 않다. 맥락을 추가하고, 기관의 상황에 맞게 조율하는 건 여전히 담당자의 몫이다. 그 조율에 쏟을 에너지가 더 많아지도록, 데이터 정리 단계를 줄이는 것 — 이게 우리가 하려는 일이다.

---

"종합총평" 카드 — 한 문단으로 전체를 파악한다

ViewCheck LLM 분석의 24개 결과 카드 중 가장 먼저 등장하는 건 '종합총평'이다. 이름 그대로, 사이트 전체의 분석 결과를 한 문단 안에 압축해 정리한다.

종합총평 카드가 담는 것은 대략 이런 내용이다.

• 분석 대상 사이트와 분석 범위(몇 페이지, 어떤 유형의 페이지들)
• KRDS 846규칙 기준 전체 준수율과 카테고리별(DS·CP·BP·SP) 핵심 수치
• 가장 반복적으로 나타나는 미통과 패턴 1~3가지
• 7대 품질영역(행안부 지침) 중 특히 주의가 필요한 영역
• 전반적인 우선순위 한 줄 요약

이 카드가 중요한 이유는 단순히 "요약이 있다"는 게 아니다. 이 요약이 실제 크롤링 데이터와 846규칙 판정 결과에 근거해 생성된다는 점이다. 사람이 직접 결과를 보고 요약을 쓰는 것과 같은 출발점에서 시작하되, 사람보다 훨씬 빠르게 처리한다.

물론 이 요약이 항상 "딱 필요한 말"을 해주느냐 하면 — 그렇진 않다. 기관의 맥락, 최근 감사나 민원 이슈, 예산 상황 같은 것들은 시스템이 알 수 없다. 종합총평이 만들어준 구조 위에, "우리 기관의 상황에서 이 수치가 왜 중요한지"를 담당자가 덧붙여야 진짜 임원 보고가 된다.

그런데 그 '덧붙이는' 작업이, 전부 처음부터 만드는 것과는 완전히 다른 수준의 에너지를 요구한다. 빈 캔버스 앞에서 시작하는 것과, 이미 스케치된 구조 위에 살을 붙이는 것의 차이다. 종합총평 카드의 역할은 그 스케치다.

---

"임원보고서" 카드 — 숫자·우선순위·리스크가 이미 정렬되어 있다

종합총평이 한 문단짜리 개관이라면, '임원보고서' 카드는 한 페이지짜리 구조화된 요약이다. 이 카드는 다음과 같은 구조로 정보를 정렬한다.

1. 전체 준수율 수치 (한눈에 보이는 숫자) KRDS 846규칙 기준으로 통과/미통과/해당없음이 몇 개인지, 전체 준수율이 몇 퍼센트인지를 명시한다. 846개라는 규칙 수와 각 카테고리(DS 120·CP 446·BP 108·SP 172)의 실측 결과가 포함된다.

2. 카테고리별 현황 (4개 축의 건강 상태) 디자인 스타일, 컴포넌트, 기본 패턴, 서비스 패턴 각각의 준수율과 주요 미통과 항목을 정리한다. 임원이 "어느 영역이 가장 문제야?"를 물었을 때 바로 답할 수 있는 구조다.

3. 최우선 개선 항목 (P0·P1 위반) 모든 미통과 항목을 나열하는 게 아니라, 심각도 기준으로 최우선 처리가 필요한 항목들을 추려낸다. P0(즉시 대응)와 P1(단기 처리) 수준의 위반이 무엇인지를 보여준다. 항목 수가 수백 개더라도, 임원에게 건넬 이야기는 그 중 5~10개다.

4. 리스크 한 줄 요약 법적 리스크, 접근성 취약점, 보안 취약점처럼 "이건 그냥 넘어가면 안 된다"는 영역을 한 줄씩 짚어준다. 행안부 지침 위반이 어떤 법적·행정적 맥락에서 문제가 되는지까지는 시스템이 모두 알기 어렵지만, "이 항목이 미통과고 이 수치다"까지는 제공된다.

5. 권고 액션 (다음 단계 힌트) 무엇을 어디서부터 시작하면 좋은지를 개선 로드맵 카드와 연결해 요약한다. "2주 안에 이것, 3개월 안에 저것" 식의 타임라인 힌트가 포함된다.

이 구조는 우연히 나온 게 아니다. 임원 대시보드 설계에 관한 연구와 관행들이 오랫동안 공통적으로 지적해 온 것들을 따른 것이다. 닐슨 노먼 그룹(Nielsen Norman Group)은 대시보드에서 **사전 주의 처리(preattentive processing)**를 활용해야 한다고 강조한다. 사람이 시각적으로 빠르게 처리하는 신호 — 색상, 위치, 크기, 길이 같은 속성 — 를 이용해, 독자가 천천히 읽기 전에 이미 핵심을 파악할 수 있게 설계하라는 것이다(Nielsen Norman Group, "Dashboards: Making Charts and Graphs Easier to Understand", nngroup.com). 임원보고서 카드도 같은 원칙을 반영한다. 핵심 수치가 가장 먼저, 가장 크게, 색상으로 구분되어 보이도록 한다.

---

5분 보고의 구조 — BLUF를 공공 보고에 적용하면

이제 실제 보고 상황으로 들어가 보자. 임원이 5분을 준다. 그 5분 안에 웹사이트 품질 현황을 보고해야 한다. 어떻게 구성해야 할까?

BLUF(Bottom Line Up Front) 원칙을 공공 웹 품질 보고에 적용하면, 구조는 대략 이렇게 된다.

[0분 ~ 1분] 결론부터 우리 사이트의 KRDS 준수율은 X%다. 이 중 즉시 처리가 필요한 항목이 N개, 단기 개선이 필요한 항목이 M개다. 가장 주의가 필요한 영역은 [접근성 / 디자인 스타일 / 보안 등]이다.

[1분 ~ 2분] 근거 이 수치는 KRDS 846규칙으로 우리 사이트의 K개 페이지를 분석한 결과다. 메인 한 페이지가 아니라, 검색·신청·목록·상세 등 실제 사용자가 자주 방문하는 유형의 페이지들을 포함했다. 카테고리별로 보면, [DS: 어떤 수준, CP: 어떤 수준, BP: 어떤 수준, SP: 어떤 수준].

[2분 ~ 3분] 핵심 이슈 2~3개 전체 미통과 항목 중 임원 수준에서 알아야 할 것들만 추려낸다. 예를 들어, "접근성 기준을 충족하지 못한 구간이 반복적으로 나타나며, 이는 행안부 고시 기준에서 지적받을 수 있는 수준이다" 같은 식이다. 기술 용어를 쓰지 않고, 리스크와 의미로 설명한다.

[3분 ~ 4분] 다음 액션 무엇을 어떻게 할지를 제안한다. "2주 내 P0 항목 3개 외주 수정 지시 → 3개월 내 CP 영역 개선 계획 수립 → 반기 단위 재분석 정례화" 같은 식의 타임라인이 있으면 임원이 결정하기 쉽다.

[4분 ~ 5분] 질문 받기 "이 항목은 왜 미통과냐", "다른 기관과 비교하면 어느 수준이냐", "이게 법적 문제로 이어질 수 있냐" 같은 질문이 나온다. ViewCheck의 LLM 분석은 이 후속 질문에 대한 답도 채팅으로 물어볼 수 있다. KRDS 규칙 원문과 행안부 지침 근거가 함께 제시된다.

이 구조가 자연스럽게 만들어지려면, 보고 전에 데이터가 이 구조에 맞게 이미 정렬되어 있어야 한다. 임원보고서 카드와 종합총평 카드가 그 정렬 역할을 한다. 물론 기관의 맥락을 추가하는 건 사람이 해야 한다. 하지만 수치와 구조가 준비되어 있으면, 그 맥락 추가에 집중할 수 있다.

---

---

846개 규칙이라는 방대함을, 어떻게 1페이지로 압축하나

여기서 한 가지 의문이 생긴다. KRDS 846규칙이라는 숫자는 사실 꽤 크다. 디자인 스타일 120개, 컴포넌트 446개, 기본 패턴 108개, 서비스 패턴 172개 — 이걸 다 이해한 다음 보고하려 하면 담당자 자신도 한참 걸린다. 그게 임원 보고로 올라가려면 어떻게 압축되어야 할까.

ViewCheck가 이 압축을 접근하는 방식은 크게 두 단계다.

1단계: 심각도 분류 (P0~P3) 846개 규칙은 각각 심각도 등급이 부여되어 있다. P0는 즉각 대응이 필요한 수준, P1은 단기 개선 필요, P2는 중기 계획, P3는 개선 권고 수준이다. 미통과 항목이 수백 개 나오더라도, P0·P1에 해당하는 건 보통 10~30개 수준이다. 임원 보고에서 다루는 건 이 P0·P1이다.

2단계: 카테고리 준수율로 패턴 요약 개별 규칙보다 "어느 카테고리가 약한가"를 먼저 본다. DS(디자인 스타일) 준수율이 50%라면 색상·타이포·간격 전반이 기준에 맞지 않는다는 뜻이다. SP(서비스 패턴) 준수율이 낮다면 로그인·검색·신청 같은 핵심 사용자 여정이 약하다는 신호다. 이 카테고리 수준의 패턴이, 담당자가 임원에게 전달해야 할 "큰 그림"에 해당한다.

이 두 단계를 통해 846개가 임원 보고에서는 "4개 카테고리의 건강 상태 + 우선순위 상위 N개 이슈"로 압축된다. 그게 "5분 컷" 보고가 가능한 이유다.

물론 이 압축이 항상 완벽하지는 않다. 예를 들어 컴포넌트(CP) 카테고리의 경우, 해당 사이트에 존재하지 않는 컴포넌트는 "해당없음(N/A)"으로 처리되어 준수율 계산에서 빠진다. 그래서 사이트의 성격에 따라 N/A 비율이 높게 나올 수 있고, 그럴 때 "왜 이 수치가 이렇게 나왔냐"를 담당자가 설명할 수 있어야 한다. 도구가 숫자를 주지만, 그 숫자의 맥락은 사람이 책임진다. 이걸 우리는 솔직하게 말한다.

---

McKinsey가 말하는 '데이터 문화'와 공공 웹 보고의 거리

데이터 기반 의사결정이 얼마나 중요한지에 대해서는 수많은 연구가 있다. McKinsey는 보고서에서 "조직이 데이터를 의사결정의 일관된 기반으로 활용하고, 회사 리더와 데이터 이니셔티브 리더 사이에 정기적인 소통이 이뤄져야 한다"고 강조하며, 데이터 기반 조직이 신규 고객 획득에서 23배, 기존 고객 유지에서 6배, 수익성에서 19배 높은 성과를 낸다는 분석을 제시한 바 있다(McKinsey, "Why data culture matters").

그런데 이 통계를 공공기관의 웹사이트 품질 보고에 그대로 가져오기는 어렵다. 공공 서비스는 수익성으로 평가되지 않는다. 그 대신 평가 기준이 있다. 행정안전부는 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호, 2025.6.25. 시행)을 통해 전자정부 웹사이트에 대한 품질진단 시행 의무를 규정하고 있다(국가법령정보센터). 공공기관의 장은 이 지침을 근거로 자체 품질진단을 시행해야 하고, 그 결과는 내부 보고로 이어진다.

바로 이 지점이, '데이터 기반 보고'가 공공 영역에서 의미를 갖는 방식이다. 수익 지표 대신, 지침 준수 여부가 의사결정의 기반이 된다. 임원이 "우리가 이 기준을 얼마나 따르고 있는가", "감사나 지적을 받을 소지가 있는가", "어디에 예산과 인력을 투입해야 하는가"를 판단하는 데 필요한 데이터가, 결국 KRDS 846규칙 준수율이라는 숫자로 나타나는 것이다.

그런데 이 숫자를 아는 공공기관이 얼마나 될까. 행안부 수준진단 결과는 공개되지만, 자기 사이트의 KRDS 준수율을 실시간으로, 항목별로 파악하고 있는 기관은 많지 않다. 그게 현실이다. 그 정보의 비대칭을 줄이는 것 — 담당자가 언제든 URL 하나로 현황을 파악하고, 그 결과를 임원에게 바로 보고할 수 있는 것 — 이 ViewCheck가 목표로 하는 지점이다.

Gartner는 2024년 데이터·분석 예측 보고에서 "자동화된 데이터 스토리텔링이 5년 이내에 가장 보편적인 분석 소비 형태가 될 것"이라고 예측한 바 있다(TechTarget, "Gartner predicts data storytelling will dominate BI by 2025"). 공공 영역이 민간보다 이 흐름을 늦게 따라가는 건 사실이지만, 지침과 감사라는 구조적 압력이 있는 한, 결국 여기도 "숫자로 말하는 보고"를 요구하게 된다.

---

종합총평 카드 — 텍스트로 된 요약을 어떻게 보고에 쓰나

종합총평은 텍스트 기반이다. 846개 규칙의 전체 흐름을 문장으로 정리한다. 이것을 임원 보고에 쓰려면 그냥 복사·붙여넣기로 되진 않는다. 그 이유와 활용 방법을 구체적으로 짚어보자.

종합총평이 잘 하는 것:

• 사이트 전체를 관통하는 패턴을 자연어로 표현한다. "이 사이트는 메인 페이지는 비교적 양호하지만, 신청·접수 관련 페이지에서 반복적인 접근성 문제가 나타난다"는 식의 서술이 가능하다.
• 여러 페이지에서 공통적으로 나타난 미통과 패턴을 요약한다. 개별 페이지 결과를 하나씩 읽지 않아도, 사이트의 '취약 패턴'이 무엇인지 파악된다.
• KRDS 4개 카테고리 중 상대적으로 약한 영역을 짚어준다.

종합총평이 잘 못하는 것:

• 기관의 맥락(최근 민원 동향, 진행 중인 사업, 예산 상황)을 알지 못한다.
• "이 수치가 지난 점검 때와 비교해 개선됐는가"는 이전 데이터가 없으면 알 수 없다.
• "이게 법적으로 문제가 되는가"에 대한 판단은 시스템이 아니라 사람이 해야 한다.

그래서 실제 활용법은 이렇다. 종합총평 카드의 내용을 보고서의 '현황 요약' 섹션의 뼈대로 사용하고, 거기에 담당자가 아는 맥락 정보를 살로 붙인다. 예를 들어 종합총평에서 "서비스 패턴(SP) 영역의 준수율이 낮다"는 내용이 나왔다면, 담당자는 거기에 "특히 최근 민원이 집중된 신청 페이지가 SP 영역에 해당한다"는 맥락을 추가한다. 그게 진짜 임원 보고가 되는 순간이다.

텍스트 요약을 바로 복사해 쓰는 게 아니라, 그걸 발판으로 삼아 담당자가 아는 정보를 더하는 방식 — 이게 종합총평의 올바른 사용법이다.

---

임원보고서 카드 — 숫자를 어떻게 '의미'로 바꾸나

임원보고서 카드는 숫자가 중심이다. 준수율, 카테고리별 점수, 미통과 항목 수. 그런데 숫자 자체는 의미가 아니다. 숫자를 의미로 바꾸는 건 담당자의 몫이다.

예를 들어 DS(디자인 스타일) 준수율이 45%로 나왔다고 해보자. 이게 좋은 건지 나쁜 건지, 숫자만 보면 알기 어렵다. 의미로 바꾸면 이렇게 된다. "우리 사이트의 색상, 타이포그래피, 간격 등 시각적 디자인 요소가 KRDS 기준에서 절반 이상 미충족 상태다. 이는 사용자가 정부 서비스에 기대하는 통일된 시각 경험을 제공하지 못하고 있다는 의미이며, KRDS 적용 기관 간 일관성 측면에서 개선이 필요한 수준이다."

혹은 BP(기본 패턴) 준수율이 낮게 나왔다면: "폼 작성, 동의 절차, 오류 안내 같은 사용자 상호작용 구간에서 기준 미충족이 나타났다. 이는 민원 신청 과정에서 이용자의 혼란과 이탈로 이어질 수 있는 영역이다."

이 '해석'은 시스템이 해주지 않는다. 담당자가 KRDS의 카테고리가 무엇을 의미하는지를 충분히 이해하고 있어야 가능하다. 역으로 말하면, 임원보고서 카드를 잘 활용하려면 KRDS 4개 카테고리(DS·CP·BP·SP)가 각각 어떤 사용자 경험과 연결되는지를 담당자가 먼저 이해하고 있어야 한다.

이 시리즈의 앞선 편들이 그 이해를 위한 기반을 만들었다. 이 글은 그 위에서 "실제 보고에 어떻게 쓰나"를 다루는 셈이다.

---

데이터 스토리텔링 — 숫자를 이야기로 바꾸는 법

좋은 임원 보고서는 단순히 숫자를 나열하지 않는다. 숫자를 이야기로 바꾼다. 이게 '데이터 스토리텔링'의 핵심이다.

Domo는 데이터 스토리텔링에 대해 이렇게 정리한다. "강력한 데이터 시각화는 개별 인사이트를 설득력 있는 내러티브로 엮는다. 시작점에서 발견의 여정을 거쳐 특정 결론에 이르는 논리적 순서로 시각화를 구성해야 한다"(Domo, "Data Storytelling: Turn Dashboards Into Business Impact"). 단순히 차트를 모아두는 게 아니라, 그 차트들이 하나의 이야기를 말하도록 구성하라는 것이다.

공공 웹 품질 보고에서 이 원칙을 적용하면 이렇게 된다.

이야기의 시작: "우리 사이트는 현재 KRDS 846규칙 기준 X%의 준수율을 보이고 있다. 이는 [높다/보통이다/개선이 필요하다]."

이야기의 여정: "특히 [특정 카테고리]에서 미통과율이 높게 나타났으며, 이는 [어떤 사용자 경험 영역]과 직접 연결된다. 반복적으로 나타나는 패턴은 [무엇무엇]이다."

이야기의 결론: "즉각 처리가 필요한 P0 항목은 N개이며, 이를 개선하면 [어떤 효과를 기대할 수 있다]. 권고 액션은 다음과 같다."

ViewCheck의 임원보고서 카드는 이 이야기의 재료를 제공한다. 담당자는 그 재료로 "우리 기관의 이야기"를 구성한다.

데이터 스토리텔링을 위한 실용적 팁을 몇 가지 정리하면 이렇다.

수치는 3개 이하로: 임원이 기억할 수 있는 숫자는 많지 않다. 전체 준수율 하나, 가장 취약한 카테고리 하나, 즉각 처리 필요 항목 수 하나 — 이 세 가지가 명확하면 충분하다.

비교 기준을 제시하라: 준수율 65%가 좋은지 나쁜지는, 비교 대상이 있어야 안다. 지난 점검 결과, 혹은 동종 기관의 일반적 수준(파악 가능한 경우) 같은 비교 기준이 있으면 맥락이 생긴다.

리스크를 '어떤 일이 생길 수 있다'로 표현하라: "접근성 미통과 17개"보다 "장애인 이용자가 주요 신청 화면에서 스크린 리더를 사용하기 어려운 상태"가 임원에게 더 와닿는다. 기술 지표를 사용자 경험과 연결하라.

다음 액션을 선택지로 제시하라: "개선이 필요합니다" 보다 "세 가지 옵션이 있습니다: ①즉시 외주 수정(예산 N만원, 2주), ②내부 인력 처리(3개월), ③우선순위 항목만 선별 처리(예산 M만원, 1개월)" 같은 선택지가 있으면 의사결정이 쉽다.

---

다중 페이지 분석이 보고의 신뢰도를 높이는 이유

임원 보고에서 "이 결과는 얼마나 믿을 수 있냐"는 당연한 질문이다. 그리고 이 질문에 답하는 방식 중 가장 중요한 것 중 하나가, 분석 대상의 범위다.

"메인 페이지만 봤습니다"라는 분석과 "검색, 신청, 목록, 상세 등 50페이지를 분석했습니다"라는 분석은 신뢰도가 다르다. 전자는 "그게 전부야? 실제로 시민들이 민원 신청하는 화면은 봤어?"라는 반문을 피하기 어렵다. 후자는 그런 반문을 차단한다.

ViewCheck는 처음부터 다중 페이지 분석을 기본으로 설계했다. URL 한 줄을 입력하면, 사이트의 여러 유형의 페이지를 실제 브라우저(Playwright)로 방문해 데이터를 수집한다. 메인뿐 아니라 검색, 신청, 목록, 상세, 로그인 같은 페이지들이 분석 대상이 된다. 이 다중 페이지 결과가 임원보고서 카드와 종합총평 카드에 반영된다.

이 다중 페이지 접근이 임원 보고에서 특히 중요한 이유가 있다. 임원이 "어느 페이지가 가장 문제야?"라고 물을 때, "메인만 봐서 모릅니다"라고 대답하는 것과 "신청 화면에서 접근성 관련 미통과가 집중되어 있습니다"라고 대답하는 것은 차원이 다른 보고다.

물론 다중 페이지를 분석할수록 N/A 비율이 달라지기도 하고, 페이지 유형에 따라 적용되는 규칙이 다르기 때문에 결과 해석에 주의가 필요하다. 예를 들어 로그인 화면에서만 의미 있는 SP(서비스 패턴) 규칙들이, 그 화면이 포함된 분석과 그렇지 않은 분석에서 다른 결과를 낼 수 있다. 이 맥락을 이해하고 보고에 포함시키는 것도 담당자의 역할이다.

---

실제 시나리오 — 신규 담당자가 처음 임원 보고를 준비하는 경우

추상적인 이야기만 하지 말고, 구체적인 시나리오를 하나 그려보자.

서울시 산하 한 공공기관에 올해 초 발령받은 홈페이지 운영 담당자 A씨. 전임자에게 인수인계를 받았지만, 웹사이트 품질 점검에 관한 정보가 별로 없다. 그러다 3월에 팀장에게서 지시가 내려온다. "올해 상반기 경영진 보고에 디지털 서비스 품질 현황을 포함하게 됐어. 다음 달 말까지 준비해 줘."

A씨는 KRDS를 처음 들어봤다. 행안부 지침은 이름만 알고 있다. 어디서 시작해야 할지 막막하다.

그가 ViewCheck LLM 분석을 처음 써보는 건 이 상황이다. 기관 홈페이지 URL을 채팅창에 붙여넣고 잠시 기다린다. 크롤링이 돌고, 결과 카드가 나타나기 시작한다. 그는 종합총평 카드를 읽으며 처음으로 "우리 사이트의 현황이 이런 거구나"를 파악한다.

임원보고서 카드에는 수치가 정렬되어 있다. 전체 준수율 X%, 카테고리별 수치, P0 항목 몇 개. 그는 이 구조를 그대로 보고서 초안에 가져온다. 여기서 멈추지 않고, KRDS가 뭔지 한 줄 설명을 추가하고, 행안부 고시가 무엇인지 각주를 달고, P0 항목 중 시민 신청과 연관된 것들을 "최우선 관심 항목"으로 강조한다.

그 결과물이 한 페이지짜리 보고서다. 5분 동안 임원에게 보고할 수 있는 구조다. 임원이 "이 수치는 좋은 건가요 나쁜 건가요?"라고 물으면, A씨는 "KRDS 적용 기관의 일반적 수준과 비교해 [어떤 수준]이며, 행안부 품질진단 기준에서 개선이 필요한 영역입니다"라고 답한다. 그 자리에서 더 구체적인 질문이 나오면, 채팅 창에서 바로 추가 질문을 해볼 수도 있다.

A씨가 이 보고를 잘 해낸 건 ViewCheck 덕분인가? 아니다. ViewCheck가 데이터의 뼈대를 잡아줬고, A씨가 그 위에 기관 맥락을 입혔기 때문이다. 도구와 사람의 분업이 제대로 된 경우다.

---

---

보고에 넣으면 안 되는 것 — 도구가 주는 정보의 한계

ViewCheck LLM 분석의 결과를 보고에 활용할 때, 주의해야 할 점도 있다. 도구가 주는 정보를 전부 그대로 보고서에 쓰면 안 된다는 것이다.

구체적으로 보면:

"이 수치가 좋다/나쁘다"는 절대 평가를 함부로 쓰지 말라. ViewCheck의 준수율 수치가 "업계 표준 대비 어떤 수준"인지를 도구가 단정할 수 없다. 비교 기준이 되는 공개 데이터가 충분히 않기 때문이다. 비교가 필요하다면 행안부 품질진단 공개 자료처럼 공식 출처를 찾아야 한다.

AI의 판단을 "공식 기준"으로 포장하지 말라. 임원보고서 카드의 내용 일부는 LLM이 생성한 텍스트를 포함한다. 이건 분석의 해석이지, 행안부 고시나 KRDS 공식 문서의 직접 인용이 아니다. 보고서에서 공식 기준을 인용할 때는 원문 출처를 확인해야 한다.

N/A(해당없음) 항목의 비율을 오해하지 말라. N/A 비율이 높으면 "분석 범위가 적은 게 아닌가" 싶을 수 있는데, 사실은 해당 사이트에 특정 컴포넌트가 존재하지 않아서 N/A인 경우도 많다. 이 맥락을 이해하지 않으면 보고서에서 이 수치를 오해할 수 있다.

동적 상호작용 영역은 자동 분석의 한계가 있다. 실제로 사용자가 버튼을 누르고, 폼을 작성하고, 오류를 만나는 런타임 경험은 정적 분석으로 완전히 커버되지 않는다. 이 영역에서 나온 N/A 항목은 "자동 분석 불가"로 표시되며, 별도의 수동 점검이 필요하다.

이 한계들을 알고 보고서에 담으면, 오히려 신뢰도가 높아진다. "이 도구가 분석한 범위는 여기까지이고, 이 항목들은 추가 점검이 필요합니다"라고 말할 수 있는 담당자가, "모든 게 완벽히 분석됩니다"라고 말하는 사람보다 훨씬 신뢰받는다. 임원은 그 차이를 안다.

---

보고서에 근거를 붙이는 법 — KRDS 참조패널 활용

ViewCheck LLM 분석에는 '참조패널'이라는 기능이 있다. 임원보고서 카드의 특정 항목에 대해 "왜 이게 미통과야?"라고 채팅으로 물으면, 참조패널에서 관련 KRDS 규칙의 원문과 행안부 지침을 함께 보여준다.

이게 보고에서 중요한 이유가 있다. 임원이 "이 항목을 고치는 게 법적 의무야, 아니면 그냥 권고야?"라고 물을 때, 담당자가 즉각 "이 항목은 행안부 고시 제2025-46호에서 요구하는 항목입니다"라고 답할 수 있어야 한다. 그 근거를 보고서에 각주로 달아도 된다.

참조패널에서 나온 KRDS 규칙 원문을 보고서에 직접 인용할 때는, 인용 형식을 맞추는 게 좋다. "KRDS CP-072: [규칙명] 기준, 우리 사이트는 [어떤 상태]입니다"처럼 규칙 ID와 내용을 명시하면, 이후 외주 개발사에 개선을 지시할 때 그대로 사용할 수 있다.

보고서에 근거를 붙이는 건 단순히 "신뢰도 높아 보이려는" 것이 아니다. 보고 이후에 실제로 개선이 일어나야 하고, 그 개선을 지시하는 사람이 담당자이기 때문이다. 근거가 명확해야 외주사가 무엇을 왜 고쳐야 하는지 알 수 있고, 개선 결과를 검증할 때도 같은 기준으로 확인할 수 있다. 보고서는 시작이지 끝이 아니다.

---

---

7대 품질영역을 보고에 어떻게 담나

행안부 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호)은 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)을 다룬다. ViewCheck LLM 분석의 24개 결과 카드는 이 7대 영역을 포함하지만, 구성이 KRDS 카테고리(DS·CP·BP·SP)와 7대 품질영역을 별개의 축으로 다룬다.

임원 보고에서 이 두 축을 어떻게 연결할지가 담당자의 과제다. 실무적으로는 이렇게 하면 된다.

KRDS 4개 카테고리 → 편의성에 주로 해당 DS, CP, BP, SP는 "사이트를 편리하게 쓸 수 있는가"와 직결된다. 편의성 영역의 핵심 지표로 임원에게 제시할 수 있다.

접근성 카드(KWCAG) → 접근성 영역 ViewCheck의 접근성 카드는 KWCAG(한국형 웹 콘텐츠 접근성 지침) 기준의 분석을 포함한다. 이 결과가 7대 품질영역의 '접근성'에 해당한다.

보안 카드 → 신뢰성 영역 보안 헤더 13종, SSL, 쿠키 보안 등의 결과가 신뢰성 영역에 해당한다.

웹 성능 카드(Web Vitals) → 효율성 영역 LCP, CLS, FCP, TTFB 같은 핵심 웹 지표가 효율성 영역이다.

SEO 카드 → 개방성 영역 메타태그, robots.txt, sitemap.xml 등이 개방성과 연결된다.

웹 성능·보안 카드의 응답시간 데이터 → 접속성 영역 TTFB, DNS·TCP·TLS 시간 분해 같은 데이터가 접속성에 해당한다.

이 매핑을 보고서에 명시하면, 행안부 지침 7대 영역 기준으로 우리 사이트의 상태를 한눈에 보여줄 수 있다. 임원이 "행안부 감사에서 어느 영역이 지적받을 수 있냐"고 물었을 때, 이 틀로 대답하면 된다.

---

반복 보고를 위한 설계 — "한 번만"이 아니라 "정기적으로"

임원 보고가 일회성 이벤트가 되면 의미가 절반으로 줄어든다. 올해 한 번 분석해서 보고했는데, 개선이 이뤄졌는지, 어느 항목이 해소됐는지 — 이걸 비교할 다음 데이터가 없으면 "열심히 했다"는 사실만 남고 "개선됐다"는 증거는 없다.

공공기관의 디지털 서비스 품질 관리가 제대로 이뤄지려면, 반기 혹은 연 2회 정도의 정기 분석과 보고가 필요하다. 행안부 지침도 품질진단을 정기적으로 시행하도록 규정한다. 이 반복 보고의 구조를 초기에 잡아두면, 두 번째 보고부터는 첫 보고보다 훨씬 쉬워진다. 전 회차 수치와 이번 수치를 비교하는 것만으로 보고의 골격이 완성되기 때문이다.

ViewCheck는 이 반복 분석에도 활용할 수 있다. 같은 URL을 다시 입력하면 최신 결과가 나온다. 지난 분석과 비교해 어느 항목이 개선됐는지, 어느 항목이 여전히 미통과인지를 확인할 수 있다. 다만 이 비교 기능을 체계적으로 활용하려면, 각 분석 결과를 저장하고 추적하는 것이 담당자의 몫이다.

반복 보고의 이점은 또 있다. 임원이 두 번째 보고를 받으면, "지난번이랑 비교하면?"이라고 묻는다. 그 질문에 "X항목이 통과로 바뀌었고, Y항목은 아직 미통과입니다"라고 답하는 순간, 보고가 단순한 현황 공유에서 '진척 보고'로 격상된다. 이게 의사결정자의 신뢰를 쌓는 방법이다.

McKinsey가 강조한 "데이터와 분석 이니셔티브 리더 사이에 정기적인 소통이 이뤄져야 한다"는 원칙(McKinsey, "Why data culture matters")이 공공 웹 품질 관리에도 적용된다. 정기적으로 데이터를 보고하고, 개선을 추적하고, 다음 행동을 결정하는 사이클 — 이게 형식적 품질진단이 실질적 개선으로 연결되는 구조다.

---

NN/g의 대시보드 원칙이 임원 보고서에 주는 교훈

닐슨 노먼 그룹(Nielsen Norman Group)은 대시보드 UX에 관한 연구를 오랫동안 해왔다. 그 중 임원 보고서 설계에도 직접 적용되는 원칙이 있다.

NN/g의 연구에 따르면, 대시보드에서 **사전 주의 처리(preattentive attributes)**를 활용하면 사용자가 정보를 더 빠르고 정확하게 파악한다. 색상, 위치, 크기, 길이 같은 시각적 속성이 뇌에서 의식적인 처리 없이 즉각 인식된다는 것이다(Nielsen Norman Group, "Dashboards: Making Charts and Graphs Easier to Understand"). 임원보고서에서 "준수율 45% — 위험" 옆에 빨간 배경을 쓰는 것, "준수율 85% — 양호" 옆에 초록 배경을 쓰는 것이 단순하지만 효과적인 이유다.

또 NN/g는 대시보드가 "사용자 목표(user goals)" 중심으로 설계될 때 사용성이 크게 향상된다고 강조한다. 임원의 목표는 "모든 데이터를 알고 싶다"가 아니라 "결정에 필요한 핵심만 빠르게 파악하고 싶다"이다. 이 목표에 맞게 보고서를 설계한다는 건, 불필요한 상세 데이터를 걷어내고 핵심에 집중한다는 것이다.

DataCamp는 효과적인 대시보드 설계에 대해 이렇게 정리한다. "임원 대시보드에는 성과 지표(KPI)를 중심으로, 경영진이 깊이 파고들 필요 없이 최신 동향을 파악할 수 있도록 소화하기 쉬운 형태로 데이터를 제공해야 한다"(DataCamp, "Effective Dashboard Design"). 많은 임원 대시보드가 실패하는 이유는 "특정 비즈니스 질문에 답하는 대신 포괄적인 데이터를 제시"하기 때문이라는 진단도 함께 제시한다.

이 원칙들이 공공 웹 품질 보고에 시사하는 바는 명확하다. 846개 규칙을 전부 보여주지 말고, 그 중 의사결정에 필요한 것만 구조화해서 보여주어야 한다. ViewCheck의 임원보고서 카드가 그 필터링을 먼저 해주지만, 최종 보고서에서 담당자가 다시 한 번 "임원이 이걸 왜 알아야 하는가"를 기준으로 필터링해야 한다.

---

보고 후 — 임원의 질문을 채팅으로 이어받는 법

5분 보고가 끝나도, 임원의 질문은 계속된다. "이 항목 개선에 예산이 얼마나 들어?" "다른 기관은 어떤 수준이야?" "언제쯤 개선될 수 있어?" 이 질문들이 보고 현장에서 바로 나올 수도 있고, 며칠 후 이메일로 올 수도 있다.

ViewCheck LLM 분석의 채팅 Q&A 기능은 이 후속 질문을 받는 데 활용할 수 있다. 예를 들어 "이 항목의 개선 예상 비용이 어떻게 되냐"고 채팅으로 물으면, '비용·MM' 카드의 데이터와 연결해 답한다. "이 항목을 고치면 어떤 효과가 있냐"고 물으면, '개선 로드맵' 카드와 연결된 근거가 나온다.

물론 AI의 답이 항상 정확한 건 아니다. 예산 추정은 특히 그렇다. 기관의 규모, 개발 환경, 외주사 단가에 따라 실제 비용은 크게 달라진다. ViewCheck가 제시하는 비용 추정은 일반적인 참고 수준이지, 견적으로 쓸 수 있는 수치가 아니다. 이 점을 임원에게도 솔직하게 말하는 게 맞다. "이 수치는 일반적인 참고 수준이며, 실제 견적은 외주사에서 받아야 합니다."

후속 질문이 나올 것 같은 영역을 보고 전에 미리 파악해 두는 것도 좋다. 임원이 자주 묻는 질문 유형은 비슷하다. 비용, 일정, 법적 리스크, 다른 기관 대비 수준. 이 네 가지에 대한 답을 미리 준비해 두면, 5분 보고가 10분 대화로 자연스럽게 이어져도 흔들리지 않는다.

---

---

임원 보고서를 만들 때 흔히 하는 실수들

실제로 공공기관 웹 품질 보고서를 만들 때 흔히 보이는 실수들을 정리해 보자. 이 실수들을 피하면 보고의 질이 크게 달라진다.

실수 1: 숫자를 너무 많이 넣는다 846개 중 몇 개, 카테고리별로 각각 몇 개, 세부 항목별로 몇 개… 숫자가 많아질수록 임원이 보고서에서 찾아야 할 게 늘어난다. 핵심 수치 3개, 핵심 이슈 3개. 이 정도면 충분하다. 나머지는 별첨에 두라.

실수 2: 기술 용어를 설명 없이 쓴다 KRDS, DS, CP, BP, SP, KWCAG, axe-core — 이 단어들이 임원에게 익숙하지 않다면, 쓸 때마다 괄호 안에 한 줄 설명을 붙여야 한다. "컴포넌트(CP) 준수율"이 아니라 "UI 구성 요소 기준 준수율(KRDS 컴포넌트 규칙 기준)"처럼.

실수 3: 결론 없이 현황만 나열한다 "이런 수치가 나왔습니다"로 끝나는 보고서는 반쪽짜리다. "그래서 우리는 이걸 해야 합니다"가 반드시 따라와야 한다. 현황과 제안이 세트다.

실수 4: 메인 페이지만 분석했으면서 "사이트 전체 현황"이라고 쓴다 이건 오해를 부른다. 분석 범위를 명시하라. "이번 분석은 메인 페이지 포함 N개 페이지를 대상으로 했으며…"라고 쓰면, 나중에 "왜 신청 페이지는 안 봤냐"는 지적을 피할 수 있다.

실수 5: 이전 결과와 비교하지 않는다 처음 보고라면 어쩔 수 없지만, 두 번째 보고부터는 반드시 전회 대비 변화를 포함해야 한다. 변화가 없다면 그것도 보고해야 한다. "3개월 동안 개선 진행 중, 이 항목은 해소, 이 항목은 아직 진행 중."

실수 6: 도구의 결과를 그대로 붙여넣는다 ViewCheck 임원보고서 카드의 내용을 그대로 보고서에 복사하면, 기관의 맥락이 빠진다. 항상 "우리 기관에서 이 수치가 의미하는 것은"이라는 해석을 추가해야 한다.

---

행안부 지침과 KRDS 공식 자료 — 보고서 근거로 쓸 수 있는 공식 출처

임원 보고서에 근거를 붙일 때, 활용할 수 있는 공식 출처를 정리해 두자.

행안부 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호, 2025.6.25. 시행) 국가법령정보센터(law.go.kr)와 행정안전부 공식 사이트(mois.go.kr)에서 확인 가능. 이 고시가 자체 품질진단의 법적 근거다. 보고서에 "행안부 고시 제2025-46호에 따라 시행한 품질진단 결과"라고 인용하면 공식성이 생긴다.

KRDS 공식 사이트 (krds.go.kr) 각 규칙의 원문, 컴포넌트 스펙, 서비스 패턴 정의를 확인할 수 있다. KRDS 특정 규칙 ID를 인용할 때의 원문 출처로 사용한다.

전자정부 웹사이트 품질관리 가이드 (행안부 배포) 지침보다 더 구체적인 점검 기준을 담은 가이드로, 행안부 사이트에서 배포한다. 보고서에서 "이 항목의 점검 기준은 행안부 웹사이트 품질관리 가이드 X섹션에 근거합니다"라고 인용할 수 있다.

KWCAG (한국형 웹 콘텐츠 접근성 지침) 접근성 관련 항목을 보고할 때 근거로 사용. 국내 법률(「장애인차별금지법」)과도 연결되어 법적 맥락을 보고할 때 도움이 된다.

이 출처들을 보고서 말미 각주나 참고 자료 섹션에 정리해 두면, 임원이 "이게 공식 기준에 따른 거야?"라고 물을 때 바로 제시할 수 있다.

---

마무리 — 도구가 주는 뼈대, 사람이 입히는 살

이 글에서 이야기한 것들을 한 줄로 요약하면 이렇다.

ViewCheck LLM 분석의 종합총평 카드와 임원보고서 카드는, 846개 규칙 분석 결과에서 임원이 필요한 정보를 압축하고 구조화하는 뼈대를 만들어준다. 그 위에 담당자가 기관의 맥락, 해석, 다음 액션을 입히면 5분 보고가 가능한 한 장짜리 보고서가 된다.

완성된 보고서를 만들어주는 도구는 없다. 어느 도구도 "우리 기관의 최근 민원 동향"을 알 수 없고, "이번 감사에서 어떤 기준으로 지적받을지"를 예측할 수 없다. 그건 사람만이 알 수 있는 것이다.

하지만 데이터 정리, 구조 잡기, 수치 추출 — 이 작업들에 쏟던 야근을 줄이고, 해석과 맥락 추가에 더 집중할 수 있다면 보고의 질이 달라진다. 그게 우리가 임원보고서 카드와 종합총평 카드를 설계한 이유다. 완벽하지 않고, 아직 개선 중인 기능이지만, 방향은 분명하다.

5분 보고는 "빨리 끝내기"가 아니라 "핵심만 담기"다. 그 핵심을 담는 데 도움이 되는 도구로, ViewCheck를 써보고 있다면 — 그 경험이 어떤지, 어떤 게 부족한지 피드백을 주면 좋겠다. 그게 다음 개선의 출발점이 된다.

다음 편에서는 이 시리즈의 또 다른 활용 각도를 들여다볼 예정이다. 오늘도 길게 읽어주셔서 감사하다.

---

참고문헌

본문에 인용한 출처는 작성 시점(2026년 6월)에 실재 여부를 직접 검색·확인한 것만 포함했다.

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

1. 행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 국가법령정보센터. https://www.law.go.kr/행정규칙/전자정부웹사이트품질관리지침
2. 행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부 개정 및 「전자정부 웹사이트 품질관리 가이드」 수정본 안내(고시 제2025-46호). https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
3. KRDS(범정부 UI/UX 디자인시스템) 공식 사이트. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/
4. 행정안전부, "2022년 공공 웹사이트 품질관리 수준진단 가이드". https://www.mois.go.kr/frt/bbs/type013/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000006&nttId=93477

해외 — 임원 보고 / 데이터 스토리텔링 / UX 연구

5. Wikipedia, "BLUF (communication) — Bottom Line Up Front". 미군 AR 25-50 인용. https://en.wikipedia.org/wiki/BLUF_(communication)
6. Animalz, "BLUF: The Military Standard That Can Make Your Writing More Powerful". https://www.animalz.co/blog/bottom-line-up-front
7. Nielsen Norman Group, "Dashboards: Making Charts and Graphs Easier to Understand". https://www.nngroup.com/articles/dashboards-preattentive/
8. DataCamp, "Effective Dashboard Design: Principles, Best Practices, and Examples". https://www.datacamp.com/tutorial/dashboard-design-tutorial
9. McKinsey & Company, "Why data culture matters". https://www.mckinsey.com/~/media/McKinsey/Business%20Functions/McKinsey%20Analytics/Our%20Insights/Why%20data%20culture%20matters/Why-data-culture-matters.ashx
10. McKinsey & Company, "The data-driven enterprise of 2025". https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-data-driven-enterprise-of-2025
11. Domo, "Data Storytelling: Turn Dashboards Into Business Impact". https://www.domo.com/blog/data-storytelling-best-practices-from-dashboards-to-impact
12. TechTarget, "Gartner predicts data storytelling will dominate BI by 2025". https://www.techtarget.com/searchbusinessanalytics/feature/Gartner-predicts-data-storytelling-will-dominate-BI-by-2025

---