AI 진단 결과를 외주 개발사에 그대로 던질 수 있을까 — '근거 붙은 지시서' 만들기

ViewCheck LLM 분석의 오류 리스트·근거 데이터를 외주사 지시서로 전환하는 실전 워크플로우

들어가며 — "이 부분 좀 고쳐주세요"라는 말의 한계

공공기관 담당자가 외주 개발사에 가장 자주 던지는 말 중 하나가 있다.

"이 부분 좀 고쳐주세요."

짧고 간단해 보이지만, 이 한 마디 안에는 엄청난 정보의 공백이 숨어 있다. '이 부분'이 정확히 어느 페이지의, 어느 요소인지. '고쳐야 하는 이유'가 어떤 기준에 근거한 것인지. 고친 뒤 '무엇이 달라야' 수정이 완료된 것인지. 이것들이 전부 빠져 있으면, 외주사 입장에서는 추측에 기대어 작업할 수밖에 없다.

추측이 개입되면 결과는 두 가지 중 하나다. 담당자가 원하던 것과 전혀 다른 결과물이 나오거나, 개발사가 "더 구체적으로 알려주세요"라는 회신을 보내오거나. 어느 쪽이든, 일이 두 번 세 번 반복된다. 마감은 다가오는데 커뮤니케이션 비용만 계속 쌓인다.

이 글은 그 고리를 끊는 방법에 대한 이야기다.

ViewCheck의 LLM 분석을 쓰면, 분석이 끝난 뒤 다양한 결과 카드가 대화 형태로 펼쳐진다. 그 중에서도 이 글이 집중하는 건 '오류 리스트' 카드와 그 안에 담긴 근거 데이터다. 규칙 ID, 위반 위치, 근거 원문, 개선 방향이 한 화면에 정리되어 있는 그것. 이걸 그대로 복사해서 외주사에 넘기면 어떻게 될까? 정확히 그 실험을 해봤고, 그 과정에서 배운 것을 이 글에 정리한다.

미리 말해두지만, "이렇게 하면 무조건 됩니다"를 말하려는 게 아니다. '이렇게 하면 커뮤니케이션의 출발선이 달라진다'는 이야기를 하려는 것이다. 외주 개발사와의 협업은 여전히 사람 사이의 일이고, 도구가 그 관계를 대신할 수는 없다. 다만 출발선이 달라지면, 그 위에서 이루어지는 대화의 질이 달라진다.

정부 사무실 책상에서 오류 항목이 번호 목록으로 정리된 화면을 집중해서 보는 30대 한국인 공공기관 여성 담당자의 모습. — "이 부분 좀 고쳐주세요" — 짧은 한 마디 뒤에는 늘 정보의 공백이 있다.

모호한 지시서가 만드는 악순환

발주사(공공기관)와 수주사(외주 개발사)의 커뮤니케이션이 왜 자꾸 엉키는지를 이해하려면, 먼저 양쪽의 입장 차이를 봐야 한다.

담당자 입장에서는 이렇다. "저도 이 오류가 정확히 뭔지는 잘 모르겠어요. 어디선가 접근성 문제가 있다는 얘기를 들었고, 그냥 고쳐줬으면 좋겠어요." 혹은 "KRDS 기준을 맞춰야 한다는 건 알겠는데, 어떤 항목이 안 맞는 건지를 저도 몰라서요."

개발사 입장에서는 이렇다. "요청이 너무 두루뭉술해서, 어디서부터 시작해야 할지 모르겠어요. 다시 여쭤봐야 할 것 같습니다." 혹은 "이게 우선순위가 높은 건가요, 낮은 건가요? 모두 다 고쳐야 하나요?"

이 간극에서 발생하는 커뮤니케이션 비용은 생각보다 크다. 소프트웨어 품질 분야에서 오래전부터 반복적으로 확인된 사실 하나가 있다. 요구사항의 모호함은 프로젝트 실패의 가장 흔한 원인 중 하나라는 것. 요구사항 명세 전문가들의 연구에 따르면, 같은 짧은 요구사항 문장을 20~30명에게 독립적으로 해석하게 했을 때 완전히 동일한 해석을 내놓는 경우가 거의 없다고 한다(Lansa, "Mind the Gap: Addressing Ambiguity in Requirements", lansa.com). 요구사항은 상호의존성, 모호성, 변동성, 충돌이라는 4가지 속성을 본질적으로 가지고 있다는 것도 같은 맥락에서 지적된다.

공공기관의 웹사이트 개선 요청이 여기에 딱 들어맞는다. "접근성 개선해 주세요"라는 요청은 20명에게 해석시키면 20가지가 나온다. 어떤 사람은 화면 낭독기 지원을, 어떤 사람은 색상 대비를, 어떤 사람은 키보드 내비게이션을 떠올린다. 전부 맞는 말이지만, 전부 다른 일이다.

반면 이렇게 요청하면 다르다.

"CP-011 규칙에 따라, /service/apply 페이지의 '신청하기' 버튼(요소: button.apply-btn)에 aria-label 속성이 누락되어 있습니다. WCAG 2.1 4.1.2 기준 미충족. 해당 요소에 aria-label='신청하기' 또는 적절한 대체 텍스트를 추가해 주세요."

같은 '접근성 개선 요청'이지만, 두 번째는 어느 페이지의 어느 요소에서, 어떤 규칙을, 어떤 방식으로 고쳐야 하는지가 명확하다. 이 수준의 요청이 가능해지려면, 무엇이 필요할까? 정확한 분석 결과와 그 근거가 필요하다.

ViewCheck 오류 리스트 카드 — 무엇이 담겨 있나

ViewCheck LLM 분석을 실행하면, 24개의 결과 카드 중 하나로 오류 리스트 카드가 생성된다. 이 카드는 단순한 목록이 아니다. 각 항목에 여러 층위의 정보가 함께 담겨 있다.

실제로 분석을 돌려보면 이런 항목들이 나온다.

첫째로, 규칙 ID와 카테고리 정보다. DS-044, CP-011, BP-003, SP-015처럼 어떤 KRDS 규칙의 어느 카테고리에서 발생한 문제인지가 명시된다. DS는 디자인 스타일, CP는 컴포넌트, BP는 기본 패턴, SP는 서비스 패턴을 뜻한다. 숫자 하나가 구체적인 규칙 하나를 가리킨다.

둘째로, **위반 위치(페이지 URL + 요소 정보)**다. 어느 페이지에서 문제가 발생했는지, 가능하면 어떤 요소인지까지 포함된다. 메인 페이지 한 장이 아니라 여러 페이지를 크롤링하기 때문에, "메인은 괜찮은데 신청 페이지에서 문제가 있다"는 식의 페이지별 차별화가 된다.

셋째로, 판정 결과와 근거다. 단순히 '미통과'가 아니라, 왜 미통과인지의 이유가 붙는다. "이 요소가 이 규칙의 이 조건을 충족하지 못했다"는 식이다. 이 근거가 있어야 외주사 개발자가 무엇을 확인하고, 무엇을 바꿔야 하는지를 알 수 있다.

넷째로, 심각도(Severity) 정보다. P0(심각), P1(높음), P2(중간), P3(낮음)으로 구분된다. 모든 오류를 다 고칠 수 없다면, 어느 것부터 고쳐야 하는지를 판단하는 기준이 된다.

다섯째로, 개선 방향 힌트다. 어떤 방식으로 고치면 되는지의 실마리가 제공된다. 완성된 코드 스니펫까지는 아니더라도, 개발자가 이해할 수 있는 수준의 기술적 방향이 제시된다.

ViewCheck LLM 분석 오류 리스트 화면. KRDS 규칙 ID별로 위반 항목이 나열되고 각 항목에 심각도와 판정 근거가 표시된 실제 프로덕션 캡처. — ViewCheck LLM 분석의 실제 오류 리스트 화면. 규칙 ID, 위반 위치, 심각도, 근거가 한 화면에 정리되어 있다. — 실제 분석 화면

이 정보들이 한 화면에 모여 있다는 게 핵심이다. 담당자가 하나씩 수집해서 조합할 필요 없이, 분석이 끝나면 이미 '지시서의 원재료'가 준비되어 있는 셈이다.

다만 솔직하게 말하면, 이 결과를 그대로 복사-붙여넣기 하는 것만으로 완벽한 지시서가 되는 건 아니다. 담당자가 맥락을 더하고, 우선순위를 조정하고, 외주사와 공유할 수 있는 형식으로 정제하는 작업이 여전히 필요하다. 다만 그 작업이 '처음부터 혼자 만드는 것'에서 '이미 만들어진 것을 정제하는 것'으로 바뀐다는 차이가 있다. 그 차이가 실무에서는 꽤 크다.

오류 리스트의 현실적 한계 — 솔직한 이야기

이 글이 '근거 붙은 지시서'를 다루는 이상, 오류 리스트의 한계에 대해서도 솔직하게 짚어야 한다.

첫째, 모든 규칙이 자동 판정되는 건 아니다. ViewCheck의 846개 KRDS 규칙 중 일부는 DOM(페이지 구조 데이터)을 분석하면 자동으로 통과/미통과를 판정할 수 있지만, 일부는 사람이 눈으로 봐야 판단되는 시각적 영역이거나, 사용자가 실제로 상호작용해봐야 알 수 있는 동적 영역이다. 이런 규칙들은 '해당없음(N/A)' 상태로 남는 경우가 있다. 오류 리스트에 없다고 문제가 없는 게 아닐 수 있다는 뜻이다.

둘째, 판정이 항상 100% 맞지는 않는다. 자동화 분석은 빠르고 일관되지만, 맥락에 따라 판정이 틀릴 수도 있다. 예를 들어 어떤 요소가 특정 조건에서만 표시되는 경우, 크롤링 시점에 그 조건이 충족되지 않아 '미탐지'로 빠질 수 있다. 분석 결과는 시작점이지, 최종 판결이 아니다.

셋째, 오류 리스트는 '무엇'을 알려주지만, '어떻게 고칠지'는 개발자의 몫이다. 분석 결과가 "이 버튼에 ARIA 레이블이 없다"고 알려줄 수는 있어도, 그 프로젝트의 코드베이스에서 어떤 방식으로 레이블을 추가하는 게 가장 적합한지는 그 코드를 아는 개발자가 판단해야 한다.

이 한계를 알고 사용하는 것과 모르고 사용하는 것은 결과가 다르다. 우리가 오류 리스트를 '지시서의 출발점'이라고 표현하는 이유가 여기에 있다. 도착점이 아니라 출발점. 이 차이를 명심하고 워크플로우를 설계하면, 실망 없이 쓸 수 있다.

왜 '근거'가 결정적으로 중요한가

버그 리포팅(bug reporting) 분야에서 오래전부터 축적된 경험이 있다. 명확한 결함 보고서가 개발 생산성에 미치는 영향이다.

소프트웨어 테스팅 업계의 리소스들은 이 점을 일관되게 강조한다. "모호하게 작성된 버그 리포트에 기반하면 개발자가 버그를 수정하는 데 명확하게 작성된 리포트에 비해 최대 50% 더 많은 시간을 쓸 수 있다"는 분석이 있다(BrowserStack, "How to write a good Defect Report"). 즉, 리포트의 질이 개발 속도에 직결된다.

좋은 결함 보고서에는 무엇이 들어가야 하는가. 현장 전문가들이 공통적으로 꼽는 핵심 요소들이 있다.

**재현 가능한 단계(Steps to Reproduce)**가 가장 중요하다. 이게 없으면 개발자가 문제를 눈으로 확인할 수 없다. "이 페이지에서 이 버튼을 누르면 이렇게 된다"는 식의 번호 매긴 단계가 있어야 한다(TechSmith, "How to Write a Bug Report"). 공공 웹 개선 요청에서는 "어느 페이지의 어느 요소"가 이에 해당한다.

예상 결과 vs 실제 결과가 명확해야 한다. "이렇게 되어야 하는데, 실제로는 이렇게 됐다"는 대비가 개발자에게 문제의 본질을 즉각적으로 이해시킨다. KRDS 규칙 맥락에서는 "이 규칙은 이 조건을 요구하는데, 현재 이 요소는 그 조건을 충족하지 못한다"가 그 역할을 한다.

**심각도(Severity)와 우선순위(Priority)**가 있어야 한다. 표준화된 심각도/우선순위 척도는 개발팀이 각 결함의 긴박성과 영향을 이해하는 데 도움이 된다(Kualitee, "Best Practices for Reporting and Tracking Software Defects"). ViewCheck의 P0~P3 분류가 이 역할을 한다.

**시각적 증거(Visual Evidence)**가 설득력을 더한다. 스크린샷이나 영상은 글로 설명하기 어려운 시각적 맥락을 즉각적으로 전달한다. 오류 리스트와 함께 해당 페이지의 스크린샷을 첨부하면 지시서의 완성도가 올라간다.

ViewCheck의 오류 리스트가 이 네 가지 요소를 어느 정도 포함하고 있다는 게, 우리가 이걸 '지시서의 원재료'라고 부르는 이유다. 규칙 ID가 '예상 결과 기준'을 제공하고, 위반 위치가 '재현 단계'를 명시하며, P0~P3 심각도가 '우선순위'를 잡아준다. 여기에 담당자가 맥락과 스크린샷을 더하면 꽤 쓸 만한 지시서가 된다.

실전 워크플로우 — LLM 분석에서 외주 지시서까지

구체적인 워크플로우를 단계별로 정리해 보자. 이건 우리가 실제로 실험해본 흐름이다. 반드시 이 순서대로 할 필요는 없고, 각 담당자의 상황에 맞게 조정해서 쓰면 된다.

STEP 1. LLM 분석 실행

ViewCheck 채팅창에 대상 사이트 주소를 입력한다. 가능하면 '다중 페이지' 분석 옵션을 사용한다. 메인 페이지 한 장만 보면, 신청 페이지·로그인 페이지·검색 결과 페이지 같은 곳에서 발생하는 문제를 놓친다. 공공 웹의 실제 사용자 경험은 메인이 아니라 그 '뒤쪽'에서 이루어지기 때문이다.

분석이 완료되기까지 시간이 걸린다. 크롤링 → 846규칙 판정 → 24개 카드 생성의 과정이 자동으로 진행된다. 이 사이에 다른 일을 해도 된다.

STEP 2. 오류 리스트 카드 확인

분석이 끝나면 24개의 결과 카드를 스크롤한다. 이 중 오류 리스트 카드를 찾는다. 이 카드에서 심각도별로 정렬된 위반 항목 전체를 확인한다.

첫 번째로 확인할 것은 P0(심각) 항목이다. 이건 보통 접근성 문제 중에서도 시각 장애인이 아예 이용할 수 없는 수준, 또는 주요 기능이 완전히 작동하지 않는 문제다. 이걸 먼저 챙겨야 한다.

P1(높음), P2(중간) 순서로 내려가며 전체 규모를 파악한다. "총 몇 개의 미통과 항목이 있고, 그 중 P0+P1이 몇 개다"라는 윤곽을 잡아두는 게 다음 단계에서 우선순위를 정하는 데 도움이 된다.

STEP 3. 우선순위 정하기

오류 리스트의 모든 항목을 외주사에 한꺼번에 넘기는 건 좋은 방법이 아닐 수 있다. 항목이 많으면 외주사도 압도되고, 어디서부터 시작해야 할지 오히려 막막해진다.

현실적으로 한 스프린트(통상 2주) 또는 한 번의 유지보수 요청으로 처리할 수 있는 양을 가늠한다. 그리고 그 양에 맞게 이번 지시서에 담을 항목을 고른다. P0 전부 + P1 일부 정도가 한 회의 적정 분량인 경우가 많다.

우선순위를 정할 때 고려할 요소는 심각도 외에도 있다. 얼마나 많은 페이지에서 반복되는 문제인가(반복 빈도), 시민이 직접 만지는 기능에서 발생하는가(사용자 접점), 법적 의무사항에 해당하는가(컴플라이언스 리스크) 같은 것들이다.

STEP 4. 지시서 초안 작성

선정된 항목을 외주사가 읽을 수 있는 형식으로 정리한다. 정해진 형식이 있는 건 아니지만, 다음 항목들이 포함되면 충분하다.

항목 번호 — 이번 지시서 안에서의 순번
규칙 ID — 예: CP-011
카테고리 — 예: 컴포넌트(CP)
심각도 — 예: P0
위반 페이지 URL — 예: /service/apply
위반 요소 설명 — 예: '신청하기' 버튼 (button.apply-btn)
판정 근거 — ViewCheck 오류 리스트의 근거 텍스트 복사
개선 방향 — ViewCheck가 제시한 힌트 + 담당자 메모
확인 기준 — 수정 후 무엇이 달라야 완료인지

이 형식으로 작성된 지시서는, 개발자가 첫 줄을 읽는 순간 무엇을 해야 할지를 알 수 있다. 다시 확인을 요청하거나 해석을 위한 회의를 소집할 필요가 없다.

STEP 5. 근거 원문 첨부 또는 링크

지시서에서 인용한 규칙 ID에 대해, 가능하면 KRDS 공식 사이트의 해당 규칙 설명 링크를 첨부한다(krds.go.kr). 또는 ViewCheck가 제공하는 KRDS 참조 패널에서 해당 규칙의 원문을 복사해 붙인다.

이 단계가 왜 중요한가. 외주사 개발자는 KRDS 전체를 다 알지 못할 수 있다. 규칙 ID만 던져주면 "이 규칙이 뭔지 모르겠어요"라는 회신이 올 수 있다. 규칙 원문까지 함께 제공하면, 개발자가 별도로 찾아볼 필요 없이 즉시 이해하고 작업에 들어갈 수 있다.

STEP 6. 수정 확인 기준 명시

"고쳤습니다"와 "제대로 고쳤습니다"는 다르다. 지시서 각 항목 마지막에 확인 기준을 명시해 두면 이 모호함이 사라진다.

예: "수정 완료 후 ViewCheck로 동일 페이지 재분석 시 CP-011이 통과(Pass)로 전환되어야 함."

또는 더 구체적으로: "/service/apply 페이지에서 button.apply-btn에 aria-label 또는 텍스트 콘텐츠가 존재하고, 스크린리더가 '신청하기'로 읽을 수 있어야 함."

이 기준이 있으면, 외주사는 제출 전에 스스로 확인할 수 있다. 그리고 담당자는 재분석 한 번으로 수정이 완료됐는지를 검증할 수 있다.

밝은 현대적 사무실에서 한국인 담당자 두 명이 책상에 놓인 명세서를 함께 검토하는 모습. — "이 규칙이 뭔가요?" — 근거가 붙어야 개발자와의 첫 대화가 달라진다.

접근성 개선 요청 — KWCAG 항목과 엮기

오류 리스트에서 접근성 관련 항목을 외주사에 전달할 때, ViewCheck는 한 가지 장점을 더 갖고 있다. KRDS 846규칙과 KWCAG(한국형 웹 콘텐츠 접근성 지침) 33개 항목을 연결해서 보여준다는 점이다.

KWCAG 2.2는 디지털포용법 제21조 및 동법 시행령 제20조에 근거해 운영되는 국가 표준이다. 4가지 원칙과 14개 지침, 33개 검사항목으로 구성되어 있으며, 시각장애·저시력장애·청각장애·지체장애 등 다양한 유형의 장애를 가진 사용자가 웹 콘텐츠에 접근할 수 있도록 하기 위한 기술적 규격을 담고 있다(KWCAG 2.2 공식, a11ykr.github.io/kwcag22/).

외주사에 접근성 개선을 요청할 때, 단순히 "CP-011이 미통과입니다"라고만 하는 것보다, "CP-011은 KWCAG 4.1.2(이름, 역할, 값)과 연관된 항목으로, 보조기술(스크린리더)이 해당 요소의 역할과 이름을 인식하지 못하는 경우 발생합니다"라고 연결해서 전달하면 개발자의 이해도가 높아진다.

접근성 관련 개선 요청을 발주사-수주사 사이에서 명확하게 커뮤니케이션하려면, 공통의 언어가 필요하다는 점을 전문가들은 지적한다. WCAG 요구사항에 관한 프로젝트 관리자 가이드(OmbuLabs, "WCAG Accessibility Requirements: A Guide for Project Managers")는 접근성 개선 작업에서 팀 교육과 명확한 명세 제공이 함께 이루어져야 한다고 강조한다. 특히 처음 접근성 요건을 적용하는 팀이라면 초기 검토 단계에서 교육과 이해를 위한 추가 시간을 계획해야 한다는 것이다.

ViewCheck의 LLM 분석은 접근성 결과를 보여줄 때 KWCAG 항목과 KRDS 규칙을 같이 제시한다. 이걸 외주사 지시서에 그대로 담으면, 개발자 입장에서는 "KRDS CP-011은 KWCAG 4.1.2에 해당하고, 이건 접근성 법적 기준에도 연결된 사항"이라는 맥락까지 한 번에 이해할 수 있다.

다중 페이지 결과를 지시서에 담는 방법

단일 페이지만 분석하면, 신청 페이지에서 발생하는 문제를 메인 페이지 분석에서 잡아낼 수 없다. 그래서 ViewCheck는 처음부터 다중 페이지 분석을 기본으로 설계했다. 그리고 다중 페이지 분석을 하면, 같은 문제가 얼마나 많은 페이지에서 반복되는지를 알 수 있게 된다.

이 '반복 빈도' 정보는 외주 지시서에서 매우 유용하다.

예를 들어, CP-011(aria-label 누락)이 10개 페이지에서 공통적으로 발생하고 있다면, 이건 페이지별로 하나씩 고치는 게 아니라 공통 컴포넌트 또는 공통 템플릿 수준에서 수정하는 게 맞다. 이 맥락이 지시서에 담겨야, 외주사가 "이걸 10번 반복 수정할 게 아니라 공통 컴포넌트에서 한 번에 고치겠습니다"라는 올바른 판단을 내릴 수 있다.

반대로, DS-021(특정 폰트 스타일 관련)이 특정 페이지 한 곳에서만 발생하고 있다면, 이건 해당 페이지 전담 개발자에게 직접 전달하는 게 효율적이다.

다중 페이지 분석 결과를 지시서에 담을 때 권장하는 구조가 있다.

사이트 전체 요약 섹션: "총 N개 페이지 분석. P0 M건, P1 K건, 전체 미통과 X건. 사이트 전체 점수: 00점."

반복 패턴 섹션: "다음 N개 규칙이 5페이지 이상에서 공통 발생. 공통 템플릿/컴포넌트 수정 권장."

페이지별 상세 섹션: "각 페이지별 고유 문제 목록."

이 구조로 정리하면, 외주사의 기술 리드가 전체 개요를 파악하고, 하위 개발자들이 페이지별로 나눠서 작업하기가 쉬워진다.

여러 브라우저 탭이 열린 대형 모니터와 함께 손으로 쓴 스티커 메모가 붙은 한국인 개발자의 작업 공간 위에서 내려다본 모습. — 같은 오류가 10개 페이지에 반복되고 있다면, 그건 공통 컴포넌트를 고쳐야 한다는 신호다.

외주사와의 커뮤니케이션 — 무엇이 달라지나

'근거 붙은 지시서'를 사용하면 외주사와의 커뮤니케이션이 구체적으로 어떻게 달라지는지를 이야기해보자.

첫 번째 변화는 초기 확인 질문이 줄어든다는 것이다. "이게 정확히 어떤 문제인가요?", "이 규칙이 뭔가요?", "어느 페이지를 말씀하시는 건가요?" 같은 질문들이 사라진다. 이미 지시서에 다 담겨 있기 때문이다.

두 번째 변화는 작업 범위의 합의가 빨라진다. 모호한 요청은 항상 '어디까지'가 논쟁거리가 된다. 명확한 규칙 ID와 페이지 목록이 있으면, "이 항목들 전부가 이번 작업 범위"라는 합의가 한 번에 된다.

세 번째 변화는 수정 검증이 객관화된다. "제대로 고친 건지"를 판단하는 기준이 담당자의 주관적 판단이 아니라, ViewCheck 재분석 결과라는 객관적 지표가 된다. "고쳤는데 왜 아직도 뭔가 지적이 있나요?"라는 갈등이 줄어든다.

네 번째 변화는 누적 관리가 된다. 지시서 형식으로 기록이 남으면, "저번에 CP-011을 고쳤는데 또 나왔네요"라는 이슈가 발생했을 때 이전 지시서를 찾아볼 수 있다. 무엇이, 언제, 어떻게 요청되었고, 어떻게 처리됐는지의 히스토리가 쌓인다.

물론 이 모든 게 지시서 하나로 해결되는 건 아니다. 외주 개발사와의 협업에는 계약 조건, 인력 역량, 일정, 예산, 관계의 질 같은 훨씬 복잡한 요소들이 얽혀 있다. 지시서의 질이 아무리 높아도, 계약에 접근성 수정이 포함되지 않았다면 진행이 안 된다. 담당자가 지시서를 잘 써도, 외주사 개발자가 WCAG를 모른다면 별도 교육이 필요할 수 있다.

우리가 말하는 건 '완전한 해결'이 아니라 '출발선의 변화'다. 커뮤니케이션의 첫 단추가 달라지면, 그다음에 이어지는 과정이 조금씩 원활해진다. 그 조금씩의 차이가 프로젝트 전체에 걸쳐 쌓이면, 결국 결과의 질이 달라진다.

근거 있는 요청이 갖는 또 다른 힘 — 내부 설득

외주사 방향으로만 이야기했는데, 사실 '근거 붙은 지시서'는 조직 내부 방향으로도 쓸 수 있다.

담당자가 외주 개발사에 추가 개선을 요청하거나, 다음 유지보수 예산에 접근성 개선 항목을 포함시키려면, 윗선의 승인이 필요하다. 그 승인을 받으려면 "왜 해야 하는가"를 설득해야 한다.

"우리 사이트에 접근성 문제가 있어요"라는 말은 설득력이 약하다. 하지만 이렇게 제시하면 달라진다.

"ViewCheck 분석 결과, 우리 사이트의 신청 페이지에서 KRDS CP-011(버튼 ARIA 레이블 누락)을 포함한 P0 등급 미통과 항목이 총 N건 발견되었습니다. 이 중 M건은 KWCAG 4.1.2 기준에도 미달하는 사항으로, 장애인 웹 접근성 의무 준수 관련 법적 리스크에 해당합니다. 개선에 필요한 예상 공수는 ViewCheck 비용 추정에 따르면 약 X인일 규모입니다."

규칙 ID, 심각도, 건수, 법적 근거, 예상 비용이 한 단락에 들어간다. 이 수준의 보고서를 A4 한 장짜리 내부 결재 자료로 쓸 수 있다. LLM 분석 결과에서 다 가져올 수 있는 데이터다.

GOV.UK(영국 정부 디지털 서비스)는 외주 계약에서 접근성 기준을 명시적으로 포함시키는 방법을 안내하면서, "디지털 서비스가 접근성 요건을 충족하지 않으면, 외주 공급자에게 위탁했더라도 법적 책임은 발주 기관에 있다"고 명확히 밝힌다(GOV.UK, "Understanding accessibility requirements for public sector bodies", gov.uk). 공공기관이 접근성 개선을 단순한 서비스 품질 문제가 아니라 법적 의무 사항으로 인식해야 하는 이유다.

이 법적 맥락과 ViewCheck 분석 결과를 결합하면, 내부 설득 자료의 무게가 달라진다. "괜찮아 보이니까 해야죠"가 아니라, "이 규칙을 위반하면 이런 법적 리스크가 있고, 현재 우리 사이트는 N건을 위반하고 있습니다"로 말이 바뀐다.

KRDS 참조 패널 — 원문을 증거로

ViewCheck LLM 분석의 오류 리스트와 함께 쓸 수 있는 또 하나의 기능이 KRDS 참조 패널이다. 채팅에서 특정 규칙에 대해 "이 규칙 원문 보여줘"라고 묻거나, 분석 결과 카드의 규칙 ID를 클릭하면 해당 규칙의 공식 원문과 KRDS 공식 사이트(krds.go.kr) 관련 링크가 패널에 펼쳐진다.

이걸 지시서에 첨부하는 방식은 간단하다. 패널에 표시된 규칙 원문을 복사해서 지시서의 해당 항목 아래에 "【근거 원문】"이라는 소제목으로 붙여 넣으면 된다.

예를 들면 이렇다.

항목 3 — CP-011 카테고리: 컴포넌트(CP) | 심각도: P0 위반 페이지: /service/apply 위반 요소: '신청하기' 버튼 (button.apply-btn) 판정 근거: 해당 버튼에 aria-label 속성 또는 텍스트 콘텐츠가 없어 보조기술이 버튼의 역할과 이름을 인식할 수 없음 개선 방향: aria-label='신청하기' 또는 동등한 대체 텍스트 추가 【근거 원문】 KRDS CP-011: 상호작용 가능한 요소(버튼, 링크 등)는 보조기술이 역할과 이름을 인식할 수 있도록 적절한 레이블을 가져야 한다. (KRDS 공식, krds.go.kr 컴포넌트 접근성 규격 참조) 확인 기준: ViewCheck 재분석 시 CP-011 → Pass 전환. 브라우저 개발자 도구에서 aria-label 속성 확인.

이 형식으로 작성된 지시서 항목은, 외주사 개발자가 "어디서 확인할 수 있나요?"라는 질문 없이 바로 작업에 들어갈 수 있는 수준이다.

RAG(Retrieval-Augmented Generation) 기반으로 운영되는 ViewCheck의 참조 패널은, KRDS 공식 문서뿐만 아니라 규칙 원문, 공식 컴포넌트 스펙, 실제 판정 근거 등을 검색해서 함께 제시하도록 설계되어 있다. 이건 ViewCheck가 처음부터 "AI가 그렇대"가 아니라 "KRDS 원문에 따르면"으로 답하도록 설계한 원칙과 연결된다. 지시서에 이 원문이 담기면, 외주사도 같은 원문을 보고 같은 기준으로 이해하게 된다.

우선순위가 없는 지시서는 없다 — P0~P3 활용법

오류 리스트에는 P0부터 P3까지의 심각도 정보가 함께 있다. 이 정보를 지시서에 잘 활용하면, 외주사와의 작업 우선순위 논의가 훨씬 간결해진다.

P0(심각): 사이트를 사용할 수 없게 만드는 수준의 문제. 또는 접근성 기준에서 특정 사용자 그룹을 완전히 배제하는 문제. 예: 폼의 오류 메시지가 화면에 전혀 표시되지 않음, 키보드로 아무 동작도 할 수 없음.

P1(높음): 사이트를 쓸 수는 있지만 현저히 불편하거나, 특정 기능이 부분적으로 작동 안 하는 문제. 예: 이미지에 alt 텍스트가 없어 스크린리더 사용자가 내용을 알 수 없음, 색상 대비가 기준 이하여서 저시력 사용자가 텍스트를 읽기 어려움.

P2(중간): 서비스 이용에 직접 지장을 주진 않지만, KRDS 기준 미충족이나 사용성 저하 요인인 문제. 예: 버튼 크기가 KRDS 최소 기준(44×44px)보다 작음, 특정 폰트 크기가 기준 이하.

P3(낮음): 미세한 디자인 편차나 선택적 권장 사항. 예: 특정 색상 토큰의 정확한 값과 미미한 차이.

외주사에 지시서를 전달할 때, 이 심각도 분류를 명확히 전달하고, 이번 작업에서 어느 수준까지 처리할 것인지를 합의하는 것이 중요하다. "이번 스프린트에서 P0 전부와 P1 중 접근성 관련 항목을 처리해 주세요. P2와 P3는 다음 기회에"처럼 명확한 스코프 합의가 가능하다.

이 명확한 스코프 합의가 없으면, 외주사 입장에서는 "전부 다 고쳐야 하나요?"라는 불확실성 속에서 과도한 견적을 내거나, 반대로 일부만 처리하고 끝냈다가 나중에 "이것도 해달라고 했는데요"라는 분쟁이 생길 수 있다. 스코프를 명확히 하는 것이 발주사에도, 수주사에도 좋다.

수정 후 재검증 — 루프를 닫는 법

지시서를 전달하고, 외주사가 수정을 완료했다고 통보해왔다. 그다음은? 단순히 "알겠습니다"로 끝내면 안 된다. 수정이 의도대로 이루어졌는지 확인하는 '루프 닫기'가 필요하다.

ViewCheck를 사용하는 담당자에게 가장 간단한 재검증 방법은 동일한 URL로 ViewCheck LLM 분석을 다시 실행하는 것이다.

재분석 결과에서 이전에 P0 미통과였던 항목들이 어떻게 바뀌었는지를 확인한다. 통과로 전환된 항목, 여전히 미통과인 항목, 그리고 혹시 새로 추가된 미통과 항목이 있는지를 확인한다.

이 재분석 결과를 외주사에 공유하면, 수정 완료 확인이 공식화된다. "ViewCheck 재분석 결과, 요청드린 P0 항목 N건 중 M건이 통과로 전환되었습니다. 잔여 K건에 대해서는 추가 확인이 필요합니다."

이런 식의 객관적 검증 루프가 확립되면, 담당자와 외주사 양쪽이 주관적 판단 대신 공통의 기준으로 소통하게 된다. "아, 그게 이미 고쳤는데요"와 "아직 안 됐는데요" 사이의 소모적 논쟁이 줄어든다.

물론 재분석으로 모든 걸 확인할 수는 없다. 동적 상호작용을 테스트해야 하는 항목이나, 시각적 판단이 필요한 항목은 사람이 직접 확인해야 한다. 하지만 자동으로 확인 가능한 항목에 대해서만이라도 재분석으로 루프를 닫는 것이 담당자의 업무 효율을 상당히 높인다.

듀얼 모니터에서 수정 전후 웹사이트 분석 리포트를 나란히 놓고 비교하는 한국인 담당자의 모습. — 수정 전·후 재분석 비교. 루프가 닫혀야 개선이 완료된다.

반복 사이클로 만들기 — 일회성이 아닌 루틴

오류 리스트 → 지시서 → 수정 → 재검증의 흐름을 한 번의 일회성 이벤트로 끝내는 건 아깝다. 이걸 루틴으로 만들면 공공 웹의 품질이 지속적으로 개선된다.

예를 들어, 분기 1회 ViewCheck LLM 분석 → 오류 리스트 기반 지시서 생성 → 외주사 수정 → 재검증 → 결과 기록의 사이클을 정례화한다. 이렇게 하면 다음과 같은 것들이 생긴다.

품질 추이 데이터: 분기별 ViewCheck 점수 변화를 보면, 사이트가 개선되고 있는지, 정체되고 있는지를 숫자로 볼 수 있다. 보고서에 실을 수 있는 구체적인 수치가 생긴다.

반복 오류 패턴 파악: 여러 분기에 걸쳐 같은 규칙이 계속 미통과로 나온다면, 그건 일시적 수정으로 해결되지 않는 구조적 문제라는 신호다. 외주사에 "이번에도 똑같은 오류가 나왔어요"라는 말을 할 수 있게 된다.

외주 계약의 품질 기준화: 외주 계약 갱신 시, "ViewCheck 분석 기준 P0 0건 유지"를 계약 조건에 포함시킬 수 있다. 영국 GOV.UK의 접근성 요건 문서에서도 "계약 갱신 시 접근성 요건을 계약 조건에 포함하라"는 지침이 있듯이(GOV.UK, "Understanding accessibility requirements for public sector bodies"), 품질 기준을 계약으로 묶으면 담당자가 매번 요청하지 않아도 수준이 유지된다.

담당자의 개인 역량 축적: 반복 사이클을 거치면서 담당자 본인이 KRDS 규칙과 KWCAG 항목에 점점 익숙해진다. 처음에는 "이게 뭔가요?"라고 물어야 했던 규칙들을, 나중에는 직접 설명할 수 있게 된다. 이건 담당자 개인에게도, 조직에게도 자산이 된다.

지시서 작성이 어려운 진짜 이유 — 솔직한 고민

지금까지 근거 붙은 지시서를 만드는 방법을 이야기했는데, 실무 담당자 입장에서 "그래도 막막하다"는 느낌이 드는 이유가 있다. 이걸 솔직하게 짚어보자.

첫째, 규칙 ID가 뭘 뜻하는지 잘 모른다. CP-011이 중요하다는 건 알겠는데, 이게 정확히 어떤 규칙인지를 이해하려면 KRDS 공식 사이트를 찾아봐야 한다. 시간이 걸린다. 이에 대해 ViewCheck는 KRDS 참조 패널을 통해 규칙 원문을 채팅 안에서 바로 확인할 수 있도록 한다. 찾아보는 수고가 줄어든다.

둘째, 어떤 항목이 진짜 중요한지 모른다. 오류가 100개가 나왔는데, 어느 게 정말 급한 건지 판단하기 어렵다. 이에 대해 ViewCheck의 P0~P3 심각도 분류가 도움이 된다. 하지만 최종 판단은 여전히 담당자의 맥락을 아는 사람이 해야 한다. "이 기능이 우리 시민 서비스에서 얼마나 중요한가"는 ViewCheck가 아는 게 아니라 담당자가 아는 것이기 때문이다.

셋째, 외주사가 기준을 모를 수 있다. KRDS가 생긴 지 얼마 안 됐고, 모든 외주 개발사가 KRDS를 공부한 건 아니다. 지시서에 규칙 원문을 붙여도 "이게 뭔가요?"라는 반응이 올 수 있다. 이건 지시서 한 장으로 해결할 수 없는 교육과 인식의 문제다. 우리가 이걸 언급하는 이유는, "지시서를 잘 써도 안 될 수 있다"는 걸 미리 알고, 그 경우를 대비해야 한다는 것이다.

넷째, 수정 후 검증이 번거롭다. 재분석을 돌리고, 결과를 비교하고, 외주사에 피드백을 주는 과정 자체가 추가 업무다. 이게 일상 업무 위에 쌓이면 지속하기 어렵다. 이건 현실적인 한계다. 모든 수정 건을 완벽하게 검증하는 게 불가능할 수 있다. 그 경우 우선순위가 높은 P0 항목만이라도 반드시 재검증하는 식으로 범위를 제한하는 게 현실적이다.

이 어려움들을 이야기하는 이유는 "그래서 못 한다"가 아니라, "이 어려움을 알고 접근하면 더 잘 쓸 수 있다"는 것이다. 도구가 어렵게 느껴지는 건 대개 기대와 현실의 간극 때문이다. 기대를 현실에 맞게 조정하면, 같은 도구가 훨씬 쓸 만해진다.

외주 개발사 입장에서 — 받는 사람이 원하는 것

지금까지 발주사(담당자) 입장에서 이야기했는데, 잠깐 외주사(개발자) 입장에서도 생각해 보자.

좋은 버그 리포트는 "전문적 공감의 행위"라는 말이 있다(AgileTest, "The Anatomy of a Great Defect Report"). 결함을 발견한 사람이 결함을 고칠 사람을 위해, 최대한 명확하게 상황을 전달하는 행위. 이건 지적하거나 비난하는 게 아니라, 협력의 행위다.

외주 개발자가 모호한 지시서를 받으면 무슨 일이 벌어지는지를 생각해 보면, 이 전문적 공감의 중요성이 더 분명해진다. 개발자는 먼저 문제를 파악하기 위해 사이트를 직접 탐색해야 한다. 그 과정에서 무엇이 문제인지를 자신이 추측해야 한다. 추측한 내용을 바탕으로 수정한다. 그리고 "이게 맞나요?"를 확인 요청한다. 이 과정이 한 번이면 다행이고, 보통은 여러 번 반복된다.

반면 명확한 지시서를 받은 개발자는 다르다. 어느 파일의 어느 요소를 어떻게 수정해야 하는지를 처음부터 알고 작업에 들어간다. 수정 후 확인 기준도 알고 있으니, 제출 전에 스스로 검증한다. 담당자에게 확인 요청 없이 "완료됐습니다"를 보낸다.

이 두 시나리오의 차이는 발주사-수주사 모두에게 이익이다. 개발자 입장에서는 불필요한 추측과 회신 대기 시간이 줄어든다. 담당자 입장에서는 기다리는 시간과 재작업 가능성이 줄어든다. 같은 돈, 같은 시간으로 더 많은 문제가 해결된다.

지시서 템플릿 — 바로 쓸 수 있는 형식

이론보다 실용적인 것을 원하는 분들을 위해, 바로 쓸 수 있는 지시서 템플릿을 정리했다. ViewCheck LLM 분석 결과에서 데이터를 채워 넣기만 하면 된다.

[웹사이트 개선 요청서]

수신: [외주 개발사명] 발신: [기관명 담당자] 기준일: [ViewCheck 분석 실행일] 분석 도구: ViewCheck LLM 분석 (KRDS 846규칙 기반) 분석 대상 URL: [사이트 주소] 분석 페이지 수: [N]페이지

전체 요약

분석 미통과 항목: 총 X건 (P0: A건 / P1: B건 / P2: C건 / P3: D건)
이번 요청 대상: P0 전부(A건) + P1 중 접근성 관련 M건
처리 기한: [날짜]

항목 [N]

항목	내용
규칙 ID	CP-011
카테고리	컴포넌트(CP)
심각도	P0
위반 페이지	/service/apply
위반 요소	'신청하기' 버튼 (button.apply-btn)
판정 근거	해당 버튼에 aria-label 속성 또는 텍스트 콘텐츠가 없음 — 보조기술이 버튼의 이름을 인식할 수 없음
KRDS 원문	[ViewCheck 참조 패널에서 복사]
KWCAG 연관 항목	4.1.2 이름, 역할, 값
개선 방향	aria-label='신청하기' 또는 버튼 내부에 텍스트 추가
확인 기준	ViewCheck 재분석 시 CP-011 → Pass. 브라우저 접근성 검사기(axe, Wave 등)에서 오류 없음

이 형식으로 항목마다 한 블록씩 정리하면, 외주사가 체크리스트처럼 처리하고 완료 여부를 확인할 수 있다.

책상 위에 펜이 놓인 깔끔하게 인쇄된 문서와 그 옆 웹사이트 화면이 보이는 노트북의 클로즈업. — 지시서는 도착점이 아니라 대화의 출발점. 명확한 첫 장이 깔끔한 마무리를 만든다.

규모별 접근 — 대형 사이트와 소규모 사이트

공공 웹은 규모가 제각각이다. 수천 페이지짜리 대형 부처 포털이 있는가 하면, 수십 페이지짜리 지역 문화재단 사이트도 있다. 같은 워크플로우가 두 경우에 동일하게 적용되기는 어렵다.

소규모 사이트(10~50페이지): 오류 리스트 전체를 한 번의 지시서에 담는 게 현실적일 수 있다. 항목 수가 많지 않으므로, 한 번에 모든 P0+P1을 처리하는 스프린트를 계획할 수 있다.

중규모 사이트(50~200페이지): 심각도와 페이지 유형으로 분류해서 복수의 지시서로 나누는 게 좋다. 예: 1차 지시서 — 신청 관련 페이지 P0 전부. 2차 지시서 — 목록/상세 페이지 P0+P1. 3차 지시서 — 전체 P2 우선순위 상위.

대형 사이트(200페이지 이상): 서브도메인 또는 서비스 영역 단위로 나눠서 팀을 분리하는 게 현실적이다. ViewCheck의 다중 페이지 분석 결과에서 페이지 유형별 분류가 가능하기 때문에, "신청 서비스 팀은 이 파일, 게시판 서비스 팀은 저 파일"처럼 분리 배분할 수 있다.

어느 규모든 공통적으로 중요한 건 "처음에 너무 많이 담지 말라"는 것이다. 처음부터 100건을 한 번에 처리하려 하면 외주사도 담당자도 지친다. 10~~20건을 명확하게 처리하고, 검증하고, 다음 10~~20건으로 넘어가는 반복 사이클이 장기적으로 더 효율적이다.

디자인 스타일 오류 — 토큰 채택 관련 지시서

KRDS 846규칙 중 DS(디자인 스타일) 카테고리의 오류는, 접근성과는 성격이 다른 지시서를 필요로 한다.

DS 관련 오류는 주로 색상 값, 폰트 크기, 간격 수치 같은 디자인 토큰의 미채택과 관련이 있다. 예: "이 버튼의 배경색이 KRDS 색상 토큰 primary-color 값과 다릅니다." 이 경우 개발자에게 필요한 정보는 "어떤 값을 써야 하는가"이다.

ViewCheck는 DS 오류를 보여줄 때, 현재 적용된 값과 KRDS 기준 값을 함께 제시한다. 예: "현재: #3366CC / KRDS 기준: #2D5BFF (primary-color)."

이 정보를 지시서에 담으면 된다.

항목 [N] — DS-044 위반 요소: 홈 > 메인 배너 > '자세히 보기' 버튼 현재 값: background-color: #3366CC KRDS 기준: primary-color 토큰 (#2D5BFF) 개선 방향: CSS에서 하드코딩된 색상 값을 KRDS 색상 토큰 변수로 교체

이 수준이 되면 개발자가 Figma 파일이나 KRDS 개발자 문서(krds.go.kr 개발자 섹션)를 찾아보지 않고도 어떤 값으로 수정해야 하는지를 바로 알 수 있다.

서비스 패턴 오류 — 가장 설명하기 어려운 것들

SP(서비스 패턴) 카테고리의 오류는, 개발자에게 전달하기 가장 어려운 종류다. 이건 단순한 속성값의 문제가 아니라, 서비스의 흐름과 구조에 관한 문제이기 때문이다.

예를 들어 SP-015(검색 결과 없음 안내 패턴)가 미통과라는 건, "검색 결과가 없을 때 적절한 안내 메시지와 대안을 제공하지 않는다"는 의미다. 이걸 고치려면 단순히 코드 한 줄을 바꾸는 게 아니라, 검색 결과가 없는 케이스를 설계하고 구현해야 한다.

이런 종류의 지시서에는 기술 스펙 외에 시나리오 설명이 필요하다.

항목 [N] — SP-015 위반 내용: /search 페이지에서 검색 결과가 0건일 때 "결과가 없습니다"라는 텍스트만 표시되고, 대안 안내(다른 검색어 제안, 관련 카테고리 링크, 문의 방법 등)가 없음 KRDS 기준: SP-015 — 검색 결과가 없을 경우 원인 설명 + 검색어 변경 제안 + 관련 메뉴 링크 중 하나 이상 제공 개선 시나리오:

오타 감지: "혹시 이런 검색어를 찾으셨나요?" 제안

관련 카테고리: "이런 항목은 어떠세요?" 링크 제공

문의 안내: "원하는 내용을 찾지 못하셨다면 민원 접수 페이지를 이용하세요" (3가지 중 1가지 이상 구현 필요)

서비스 패턴 지시서는 이처럼 '무엇을 고치라'보다 '어떤 시나리오를 구현하라'에 가깝다. ViewCheck의 SP 오류 설명이 이 방향을 어느 정도 제시해 주지만, 담당자가 자기 서비스의 맥락을 더해 시나리오를 구체화하는 작업이 필요하다.

공공기관 조달과 외주 지시서 — 계약 연계 관점

잠깐 더 큰 그림을 보자. 외주 지시서는 단순한 업무 지시 문서를 넘어, 계약과 연결될 때 더 강한 힘을 갖는다.

공공기관의 IT 외주 계약에는 품질 기준이 포함될 수 있다. 하지만 많은 계약서에 "웹 접근성 지침 준수"라는 조항이 있어도, 어느 기준으로 판정하는지, 어떻게 검증하는지가 명시되지 않은 경우가 많다. 이 모호함이 분쟁의 씨앗이 된다.

ViewCheck 기반의 지시서와 재검증 루프를 계약 수행 과정에서 정례화하면, "ViewCheck 분석 기준 P0 0건 유지"라는 구체적인 품질 기준을 계약서에 포함시키는 근거가 된다. 계약 갱신 시 이 기준을 삽입하면, 다음 계약부터는 외주사도 계약 이행 조건으로 ViewCheck 기준을 인지하고 작업한다.

영국 공공 서비스 접근성 요건 가이드는 조달 계약에 접근성을 명시적으로 포함시키는 방법을 상세히 안내하고 있다. 여기서 핵심은 "법적 책임은 발주 기관에 있다"는 사실이다. 외주사가 만든 사이트가 접근성 기준을 충족하지 않아도, 시민에게 서비스를 제공하는 책임 기관은 발주 공공기관이다(GOV.UK, "Understanding accessibility requirements for public sector bodies"). 이 맥락에서 발주 기관이 명확한 기준을 제시하고 검증하는 것은 선택이 아니라 의무에 가깝다.

우리 팀이 ViewCheck로 이 문제를 완전히 해결할 수 있다고 말하지는 않는다. 계약, 조달, 법령은 ViewCheck가 건드릴 수 있는 영역 밖이다. 다만 "담당자가 명확한 근거와 검증 수단을 가지면, 그 계약 과정이 달라질 수 있다"는 점은 믿는다.

마무리 — '근거가 붙은 대화'가 달라지는 것들

처음으로 돌아가자. "이 부분 좀 고쳐주세요"라는 말의 한계.

ViewCheck LLM 분석의 오류 리스트는 그 한계를 바꾸는 출발점이다. 규칙 ID, 위반 위치, 판정 근거, 심각도 — 이 네 가지가 붙으면, "이 부분 좀 고쳐주세요"가 "CP-011 기준 미달, /service/apply 페이지 신청 버튼, P0, KRDS 원문 첨부, 재검증 기준 명시"로 바뀐다.

그 변화는 외주사와의 커뮤니케이션을 바꾸고, 내부 보고를 바꾸고, 나아가 외주 계약의 품질 기준을 바꾸는 시작점이 될 수 있다.

물론 이게 쉬운 일이라고 말하고 싶지는 않다. 오류 리스트를 지시서로 만들고, 외주사에 전달하고, 검증하고, 기록하는 사이클이 처음에는 낯설고 번거롭게 느껴질 수 있다. 규칙 ID가 뭔지 모르는 상태에서 시작하면 더 그렇다.

그래서 우리는 이 워크플로우를 한 번에 완벽하게 구현하라고 권하지 않는다. 다음번 외주사 커뮤니케이션에서 오류 리스트 한 항목만 근거를 붙여서 전달해 보는 것. 그 첫 번째 경험이 어땠는지를 보는 것. 그게 시작이다.

ViewCheck LLM 분석 시리즈의 다음 편에서는 분석 결과를 보고서 형식으로 만드는 작업, 즉 임원보고서나 성과 대시보드 카드를 어떻게 활용하는지를 다룰 예정이다.

공공 웹 품질 개선의 과정을 모호한 말 대신 근거 있는 대화로 채워가는 일 — 작은 변화처럼 보여도, 그게 쌓이면 사이트가 달라진다.

참고문헌

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

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

행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정 시행). 국가법령정보센터. https://www.law.go.kr/행정규칙/전자정부웹사이트품질관리지침
행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부개정 및 「품질관리 가이드」 수정본 안내(고시 제2025-46호). https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
KRDS(범정부 UI/UX 디자인시스템) 공식 사이트 — 디지털 정부서비스 UI/UX 가이드라인. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/
한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2. (A11y Korea, 비공식 한국어 편집본). https://a11ykr.github.io/kwcag22/
한국디지털접근성진흥원, 정보통신접근성(웹접근성) 품질인증 소개. 디지털포용법 제21조 및 동법 시행령 제20조 근거. http://www.kwacc.or.kr/Accessibility/Certification
행정안전부 보도자료, "누구나 쉽게 사용할 수 있는 공공 웹·앱 혁신, '범정부 UI/UX 디자인시스템(KRDS)'으로부터". https://www.mois.go.kr/frt/bbs/type010/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000008&nttId=115144

해외 — 디자인 시스템 / 결함 리포팅 / 접근성

GOV.UK, "Understanding accessibility requirements for public sector bodies". HM Government. https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
GOV.UK Design System(공식), "Accessibility". Government Digital Service. https://design-system.service.gov.uk/accessibility/
BrowserStack, "How to write a good Defect Report" — 모호한 리포트 대비 명확한 리포트의 생산성 차이(최대 50% 시간 절감). https://www.browserstack.com/guide/how-to-write-a-good-defect-report
AgileTest, "The Anatomy of a Great Defect Report" — 결함 보고서는 협력의 행위. https://agiletest.app/defect-reports/
Kualitee, "Best Practices for Reporting and Tracking Software Defects" — 표준화된 심각도·우선순위 척도. https://www.kualitee.com/blog/defect-management-tool/best-practices-for-reporting-and-tracking-software-defects/
Lansa, "Mind the Gap: Addressing Ambiguity in Requirements" — 요구사항 모호성, 20~30명 해석 실험. https://lansa.com/blog/app-development/rapid-app-development/ambiguity-in-requirements/
OmbuLabs, "WCAG Accessibility Requirements: A Guide for Project Managers" — 접근성 명세와 팀 교육의 중요성. https://www.ombulabs.ai/blog/wcag-accessibility-requirements-project-managers.html
TechSmith, "How to Write a Bug Report: A Step-by-Step Guide" — 재현 단계(Steps to Reproduce)의 중요성. https://www.techsmith.com/blog/bug-report/