추측 없는 진단 — RAG로 근거를 대는 컴플라이언스

AI가 "그렇대"가 아니라 "846규칙 원문·KRDS 공식 문서에 근거해 그렇다"를 보여주기까지

들어가며 — "왜 미통과인데?"라는 한마디 앞에서

지난 1편에서 우리는 "URL 한 줄을 채팅에 넣으면 크롤링 → KRDS 846규칙 판정 → 24개 분석 카드가 대화로 펼쳐진다"는 큰 그림을 그렸다. 그 글의 끝부분에서 우리는 한 문장을 흘리듯 적어두었다. "우리는 AI가 똑똑하다고 믿지 않는다. 다만 근거를 댈 수 있게 강제할 뿐이다." 이번 3편은 바로 그 문장 하나를 30,000자로 풀어쓰는 글이다.

장면을 하나 떠올려 보자. 어느 공공기관 담당자가 ViewCheck로 자기 사이트를 분석했다. 결과 카드 중 하나에 이렇게 적혀 있다. "이 페이지의 신청 폼은 BP 카테고리의 오류 안내 규칙을 충족하지 못합니다 — 미통과." 담당자는 잠시 멈춘다. 그리고 묻는다.

"왜 미통과인데?"

이 한마디가 사실은 모든 것을 가른다. 만약 시스템이 "음… AI가 그렇게 판단했습니다" 정도로 얼버무린다면, 그 결과는 보고서에 쓸 수 없다. 외주 개발사에 전달할 수도 없다. 무엇보다, 담당자 본인이 그 결과를 믿을 수 없다. 반대로 시스템이 "KRDS 기본 패턴 가이드의 '오류 처리' 항목에서 이렇게 규정하고 있고, 당신 페이지의 이 폼은 그 조건을 이렇게 충족하지 못합니다"라고 출처를 들어 답한다면, 그 결과는 곧장 행동으로 옮겨질 수 있다.

이 둘의 차이는 기술적으로는 작아 보일지 몰라도, 실무에서는 '쓸 수 있는 도구'와 '못 믿을 장난감'을 가르는 결정적 선이다. 그리고 우리가 이 시리즈 내내 "추측이 아니라 실측", "그렇대가 아니라 근거"라고 반복하는 이유의 거의 전부가 여기에 담겨 있다.

이번 글에서 우리는 AI에게 근거를 강제하는 기법인 RAG(Retrieval-Augmented Generation, 검색 증강 생성)를 중심에 두고, ViewCheck가 KRDS 컴플라이언스 판정을 '근거 있는 판정'으로 만들기 위해 어떤 실험을 하고 있는지 이야기하려 한다. 다만 1편과 마찬가지로 이건 "우리가 다 풀었다"는 자랑이 아니다. RAG는 강력하지만 만병통치약이 아니고, 우리도 그 한계 안에서 계속 씨름하고 있다. 그 씨름의 기록이라고 봐주면 좋겠다.

AI가 "그럴듯하게 틀린다"는 문제 — 환각이라는 이름의 함정

먼저 문제부터 정직하게 짚자. 큰 언어 모델(LLM)을 무언가를 '판정'하는 데 쓸 때 가장 무서운 건, 모델이 모른다고 솔직하게 말하지 않고 그럴듯하게 틀린다는 점이다. 학계에서는 이걸 '환각(hallucination)'이라고 부른다. 사실과 다른데도 자신감 있게, 문법적으로 매끄럽게, 마치 진실인 양 만들어내는 출력을 말한다.

이건 막연한 우려가 아니라 잘 정리된 연구 주제다. 지 외(Ji et al.)가 2023년 ACM Computing Surveys에 발표한 「Survey of Hallucination in Natural Language Generation」은 자연어 생성에서의 환각을 체계적으로 정리한 대표적 서베이로, 환각이 무엇이고 왜 생기며 어떻게 측정·완화하는지를 폭넓게 다룬다(Ji, Z., Lee, N., Frieske, R., et al., ACM Computing Surveys, Vol. 55, Article 248, 2023). 이 서베이의 문제의식은 단순하다. 생성 모델은 유창하지만, 유창함이 곧 정확함을 보장하지는 않는다는 것이다.

공공 영역에서 이 문제는 특히 치명적이다. 사기업의 마케팅 카피라면 한두 번 그럴듯하게 틀려도 큰일이 나지 않는다. 그러나 "당신 정부 사이트는 이 규정을 위반했습니다"라는 판정이 틀렸다면? 멀쩡한 페이지를 고치느라 예산과 시간을 낭비하거나, 반대로 진짜 문제를 놓쳐서 시민의 불편이 방치된다. 둘 다 행정의 신뢰를 갉아먹는다. 그래서 우리는 처음부터, LLM을 분석에 쓰되 LLM의 자유 발언을 그대로 믿지는 않는 구조를 고집했다.

이 대목에서 법률 분야의 실증 연구 하나를 소개하고 싶다. 일반 챗봇이 아니라 '근거를 댄다'고 광고하는 전문 도구조차 얼마나 자주 틀리는지를 보여주는 연구이기 때문이다. 스탠퍼드 대학교 RegLab의 마게쉬 외(Magesh et al.)는 2024년 5월 시점의 주요 법률 AI 연구 도구들을 사전 등록된 방식으로 평가했고, 그 결과를 「Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools」라는 제목으로 발표했다(스탠퍼드 로스쿨·RegLab, Journal of Empirical Legal Studies, 2025).

스탠퍼드 HAI의 정리에 따르면, 이 연구는 LexisNexis와 Thomson Reuters의 법률 AI 도구가 각각 17% 이상의 빈도로 환각을 일으킨다는 점을 확인했다(Stanford HAI, "AI on Trial: Legal Models Hallucinate in 1 out of 6 (or More) Benchmarking Queries"). 보도와 후속 정리에 따르면 구체적 수치는 Lexis+ AI 약 17%, Westlaw AI-Assisted Research 약 33%, 그리고 비교군인 GPT-4가 약 43% 수준이었다. 다시 말해, RAG를 쓴다는 전문 도구가 범용 챗봇보다는 환각을 크게 줄였지만 — 그래도 6번에 1번꼴로는 여전히 틀렸다는 것이다.

이 연구가 우리에게 준 교훈은 두 갈래다. 하나는 "RAG는 환각을 줄인다 — 분명히, 의미 있게." 다른 하나는 "RAG를 쓴다고 환각이 0이 되지는 않는다 — 자만하지 마라." 우리는 이 두 문장을 책상 앞에 붙여두는 심정으로 작업한다. RAG에 기대되, RAG를 맹신하지 않는 것. 이 글의 후반부에서 우리가 'DOM 규칙으로 AI를 가둔다'고 표현하는 이유도 결국 여기서 출발한다.

RAG란 무엇인가 — "외워서 답하기"에서 "찾아보고 답하기"로

이제 RAG가 정확히 무엇인지부터 차근히 풀어보자. 비전공자 담당자도 이해할 수 있게, 비유부터 시작한다.

LLM을 한 명의 똑똑한 시험 응시자라고 생각해 보자. 보통의 LLM은 '오픈북 없는 시험'을 치르는 학생과 비슷하다. 학습 과정에서 방대한 텍스트를 읽으며 머릿속(파라미터)에 지식을 욱여넣었고, 시험장에서는 그 기억에만 의존해 답을 쓴다. 똑똑하지만 문제가 있다. 기억은 흐릿하고, 최신 내용은 모르며, 헷갈리면 그럴듯하게 지어낸다. 정확히 환각이 생기는 지점이다.

RAG는 이 학생에게 오픈북 시험을 허락하는 것에 가깝다. 문제를 받으면 곧장 답을 쓰지 않고, 먼저 관련 자료를 '찾아서' 책상에 펼친 뒤, 그 자료를 근거로 답을 작성하게 한다. 머릿속 기억(파라미터 지식)에만 의존하는 대신, 외부 지식 창고(비파라미터 지식)를 그때그때 검색해 끌어와 보강하는 것이다.

이 아이디어를 학술적으로 정식화한 대표 논문이 루이스 외(Lewis et al.)가 2020년 발표한 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」다(Patrick Lewis et al., NeurIPS 2020, arXiv:2005.11401). 이 논문은 RAG를 "사전학습된 파라미터 메모리와 비파라미터 메모리를 결합한 언어 생성 모델"로 정의한다. 영어 원문의 표현을 그대로 옮기면 이렇다.

"models which combine pre-trained parametric and non-parametric memory for language generation." (Lewis et al., 2020)

논문이 짚는 문제의식도 명료하다. 큰 언어 모델은 파라미터 안에 사실 지식을 저장하고 여러 NLP 과제에서 최고 성능을 내지만, 그 지식에 '정확히 접근하고 조작하는' 능력은 여전히 제한적이어서, 지식 집약적 과제에서는 과제 특화 구조에 뒤처진다는 것이다. RAG는 바로 그 빈틈 — '모델이 아는 것'과 '정확히 인용할 수 있는 것' 사이의 간극 — 을 메우려는 시도다.

조금 더 최근의 큰 그림을 보려면 가오 외(Gao et al.)의 서베이가 좋다. 2023년 말 공개되고 2024년에 개정된 「Retrieval-Augmented Generation for Large Language Models: A Survey」는 RAG를 "LLM으로 질문에 답하기 전에 외부 지식 베이스에서 관련 정보를 검색하는 기법"으로 정리하면서, 이 기법이 답변 정확도를 크게 높이고 모델의 환각을 줄이는 것으로 입증되었다고 명시한다(Gao, Y., Xiong, Y., et al., arXiv:2312.10997, 2023–2024).

이 서베이가 짚는 RAG의 효용은 우리 문제와 정확히 겹친다. 서베이는 LLM이 환각·오래된 지식·불투명한 추론 같은 난점을 겪는데, RAG가 정확성과 신뢰성을 높이고, 지식을 지속적으로 갱신하며, 도메인 특화 정보를 통합하게 해준다고 적는다. "지식이 계속 개정된다", "도메인이 특수하다", "근거가 투명해야 한다" — 이 세 가지는 공공 웹 KRDS 컴플라이언스의 조건 그 자체다. KRDS와 행안부 지침은 계속 개정되고, 도메인은 매우 특수하며, 판정의 근거는 반드시 투명해야 한다. RAG가 우리 문제에 잘 들어맞는 도구라고 우리가 판단한 데에는 이런 배경이 있다.

왜 KRDS 컴플라이언스에 RAG가 필요했나 — 세 가지 이유

"RAG가 좋다더라"는 일반론을 넘어서, ViewCheck가 구체적으로 왜 KRDS 판정에 RAG를 끌어왔는지를 세 가지로 정리해 보겠다. 이게 이 글의 척추다.

첫째, KRDS와 행안부 지침은 '살아 움직이는' 기준이기 때문이다. 1편에서도 짚었듯, 행정안전부의 「전자정부 웹사이트 품질관리 지침」은 한 번 만들고 끝이 아니라 계속 개정된다. 가장 최근 개정은 2025년 6월 25일 자 행정안전부고시 제2025-46호이고, 이번 개정에서는 세부 기술 항목을 고시 본문에서 덜어내 별도의 「품질관리 가이드」로 위임하는 방향까지 택했다(국가법령정보센터·행정안전부). KRDS 역시 웹사이트와 Figma 파일로 '살아 있는' 형태로 운영되며 버전이 갱신된다. 이렇게 기준이 자주 바뀌는 영역에서, 판정 로직 안에 규칙 내용을 통째로 하드코딩해 박아두면 개정 때마다 코드를 뜯어고쳐야 한다. RAG는 규칙 내용을 '검색 가능한 데이터'로 분리해 두므로, 기준이 바뀌면 지식 베이스만 갱신하면 된다. 코드와 지식을 분리하는 것 — 이게 첫 번째 이유다.

둘째, 도메인이 지독하게 특수하기 때문이다. 범용 LLM은 인터넷의 방대한 텍스트를 학습했지만, 'KRDS BP-037 규칙의 정확한 충족 조건' 같은 건 그 학습 데이터에 거의 없거나, 있어도 부정확하다. 실제로 1편에서 우리는 인터넷에 떠도는 'KRDS 디자인 토큰 1,082개'라는 숫자가 우리 실측(색상 토큰 약 586개, 전체 약 768개)과 다르다는 점을 지적한 바 있다. 모델이 '어디서 주워들은' 부정확한 지식으로 판정하게 두면, 그 판정은 신뢰할 수 없다. RAG는 모델에게 "네 기억 말고, 내가 지금 펼쳐주는 KRDS 공식 원문을 보고 판단해"라고 강제한다. 도메인 특수성이 강할수록 RAG의 가치는 커진다.

셋째, 그리고 가장 중요하게 — 근거가 투명해야 하기 때문이다. 공공 영역의 진단은 '결과'만으로 부족하다. '근거'가 함께 와야 한다. 담당자가 그 근거를 외주사에 전달하고, 감사에 대응하고, 내부 보고에 인용할 수 있어야 비로소 도구가 일을 한다. RAG는 본질적으로 '검색해 온 근거 문서'를 손에 쥔 채 답을 만들기 때문에, 그 근거를 결과에 함께 노출하기 쉽다. ViewCheck의 참조패널이 가능한 것도 이 구조 덕분이다. 흥미롭게도 법률 AI 업계에서도 같은 흐름이 관찰된다. 규제 당국이 투명성·위험 완화·책임성에 집중하면서, 검증 가능한 인용과 설명 가능한 추론, 문서화된 워크플로를 '컴플라이언스 요건'으로 다루기 시작했다는 것이다(criminallawlibraryblog.com, "Interpretability and Retrieval Augmented Generation (RAG)" 정리). 근거를 대는 일이 더 이상 '있으면 좋은 것'이 아니라 '있어야 하는 것'이 되어가는 셈이다.

이 세 가지 — 살아 움직이는 기준, 특수한 도메인, 투명한 근거 — 가 RAG를 우리 시스템의 한 축으로 들인 이유다. 다만 한 가지 더 짚고 넘어가야 한다. RAG를 KRDS에 적용한다는 게 말처럼 단순하지 않다는 점이다.

RAG를 KRDS에 적용한다는 것의 진짜 난이도

"규칙 원문을 검색해서 AI 앞에 펼쳐주면 되는 거 아냐?" — 처음엔 우리도 그렇게 가볍게 생각했다. 막상 해보니 단계마다 함정이 있었다.

먼저 무엇을 지식 베이스에 넣을 것인가의 문제가 있다. KRDS 컴플라이언스 판정의 근거가 될 수 있는 문서는 한 종류가 아니다. 846규칙의 원문 정의가 있고, KRDS 공식 사이트의 가이드라인 본문이 있고, 각 컴포넌트·패턴의 공식 스펙이 있고, 행안부 지침과 그 가이드가 있고, KWCAG·WCAG 같은 접근성 표준이 있다. 이 이질적인 문서들을 어떤 단위로 잘라(청킹), 어떻게 색인할 것인가는 그 자체로 설계 문제다. 너무 크게 자르면 검색의 정밀도가 떨어지고, 너무 잘게 자르면 맥락이 끊긴다.

다음은 검색의 정확도다. 담당자의 어떤 페이지가 'BP 오류 처리' 규칙과 관련 있을 때, 시스템이 정확히 그 규칙 원문을 찾아와야 한다. 엉뚱한 규칙을 찾아오면, 그 뒤의 모든 판정이 틀어진다. RAG의 품질은 생성 모델이 아니라 사실 검색 단계에서 절반 이상 결정된다. 가오 외 서베이가 RAG 프레임워크를 '검색(retrieval)·생성(generation)·증강(augmentation)'의 삼원 구조로 나눠 분석한 것도, 검색이 그만큼 독립적으로 중요하다는 방증이다(arXiv:2312.10997).

그리고 검색해 온 근거를 모델이 제대로 '쓰게' 만드는 문제가 남는다. 근거 문서를 앞에 펼쳐줘도, 모델이 그걸 무시하고 자기 기억대로 답해 버리면 헛수고다. 앞서 본 스탠퍼드 연구의 17% 환각률이 바로 이 지점의 어려움을 보여준다. 검색은 잘 됐는데 모델이 검색 결과를 충실히 따르지 않거나, 검색 결과를 과잉 해석해 없는 결론을 만들어내는 경우가 실제로 존재한다.

마지막으로, KRDS 특유의 난이도가 있다. KRDS는 단순한 텍스트 규정이 아니라 '시각적' 디자인 시스템이라는 점이다. "버튼의 모서리 반경은 이래야 한다", "이 색상 대비는 이 기준을 넘어야 한다" 같은 규정은, 텍스트로 검색해 온 근거만으로는 '실제 화면이 그걸 지켰는지'를 판단하기 어렵다. 텍스트 근거(RAG)와 시각 판정(Vision)이 만나야 비로소 완결되는 영역이 있는 것이다. 이 지점이 ViewCheck의 KRDScan 엔진이 RAG와 Vision AI를 한 몸에 둔 이유이기도 한데, 그 이야기는 조금 뒤에 하겠다.

요컨대 RAG는 '근거를 댄다'는 방향은 옳지만, 그 방향을 실제로 구현하는 일은 청킹·검색·생성·시각화의 각 단계마다 까다로운 설계 결정을 요구한다. 우리가 "RAG를 적용했습니다"라고 한 줄로 끝내지 않고 이렇게 길게 적는 이유는, 그 한 줄 뒤의 어려움을 솔직히 공유하는 게 이 시리즈의 약속이기 때문이다.

ViewCheck의 근거 파이프라인 — 어떻게 근거를 붙이는가

이제 ViewCheck가 실제로 어떻게 'AI의 답에 근거를 붙이는지'를, 1편의 3단계 흐름 위에 겹쳐 그려보자. 1편에서 본 큰 흐름은 이랬다.

[1] URL 한 줄 입력 → 크롤링(Playwright, 다중 페이지)
[2] KRDS 846규칙 판정 (DS 120 · CP 446 · BP 108 · SP 172)
[3] 24개 분석 카드가 대화로 펼쳐짐 + Q&A + 참조패널

여기서 '근거'가 끼어드는 지점은 [2]와 [3] 사이, 그리고 [3]의 Q&A 단계다. 조금 더 자세히 풀면 이렇다.

판정 결과(통과/미통과/해당없음)
      ↓
판정과 관련된 KRDS 규칙·공식 문서를 '검색'해 끌어옴 (Retrieval)
      ↓
검색한 근거를 AI 앞에 펼치고, "이 근거로 설명/보강하라"고 요구 (Augmented Generation)
      ↓
결과 카드 + 참조패널: "이 판정은 이 규칙·이 문서에 기반한다"를 함께 표시
      ↓
담당자가 "왜?"라고 되물으면 → 같은 근거로 Q&A 답변

핵심은 '판정'과 '근거 설명'의 역할 분리다. 여기서 1편에서 강조한 '충돌 방지 원칙'이 다시 등장한다. 통과/미통과의 판정 자체는 가능한 한 DOM 규칙(KRDSrule 엔진)이 if/else 로직으로 내린다. 즉 ARIA 속성이 있는지, CSS 값이 기준을 넘는지, 특정 구조가 존재하는지 같은 '명확히 검사 가능한' 것들은, AI가 아니라 결정론적 규칙 코드가 판정한다. AI는 그 판정을 뒤집지 않는다.

그렇다면 RAG와 AI는 어디서 일하는가? 두 군데다. 하나는 '왜 그렇게 판정됐는지'를 설명하는 근거 제시다. 규칙 코드가 "BP-037 미통과"라고 내리면, RAG가 BP-037의 원문과 KRDS 공식 가이드의 해당 대목을 끌어와, 사용자가 이해할 수 있는 설명과 개선 방향으로 풀어준다. 다른 하나는 DOM이 비워둔 빈칸('해당없음')과 DOM이 볼 수 없는 시각 영역을 채우는 일이다. 이건 4편(예고)에서 다룰 'N/A를 줄이는 연구'와 직결된다.

이 분업의 의미는 분명하다. 가장 환각이 위험한 곳(판정 그 자체)에서는 AI를 빼고 결정론적 규칙을 쓰고, AI는 '근거를 풀어 설명하는' 비교적 안전한 자리와 '규칙으로는 닿지 않는' 보완의 자리에만 둔다. AI에게 권한을 주되, 그 권한의 범위를 좁게 가둔다. 우리가 "DOM 규칙으로 AI를 가둔다"고 표현하는 게 바로 이것이다. 스탠퍼드 연구가 보여준 '근거를 댄다는 도구도 6번에 1번은 틀린다'는 교훈을, 우리는 이 분업으로 흡수하려 한다 — AI가 틀려도, 그 틀림이 핵심 판정을 오염시키지 못하도록.

증적으로 보는 참조패널 — "인용 탭"이 하는 일

말로만 설명하면 추상적이니, 실제 화면을 하나 보자. ViewCheck 분석 결과에는 근거를 확인할 수 있는 참조 영역이 있다. 아래는 그 인용/참조 패널의 실제 캡처다.

ViewCheck 분석 화면의 인용·참조 탭으로, KRDS 규칙과 공식 문서 근거가 판정 결과와 함께 표시된 실제 프로덕션 캡처. — ViewCheck 분석 결과의 참조패널(인용 탭) 실제 캡처. 판정 결과 옆에서 "이 판정이 어떤 규칙·어떤 문서에 근거했는지"를 확인할 수 있다. 결과만 던지지 않고 근거를 함께 펼치는 것이 RAG 파이프라인의 가시적 결과물이다. — 실제 분석 화면

이 작은 패널 하나가 사실 이 글 전체의 주제를 압축한다. 결과 카드가 "여기가 문제"라고 말할 때, 그 옆 또는 아래에서 "그 근거는 이 규칙, 이 문서의 이 대목"이라고 바로 확인할 수 있다는 것 — 이게 '근거를 대는 컴플라이언스'의 사용자 경험이다.

이 경험이 왜 중요한지, 담당자의 실제 행동 단위로 다시 그려보자.

담당자가 결과에서 미통과 항목을 본다.
의심이 든다. "이게 정말 문제 맞아? 우리 사이트는 이렇게 만든 이유가 있는데."
참조패널을 연다. KRDS 공식 가이드의 해당 규정과, 846규칙 중 어느 규칙이 적용됐는지가 보인다.
납득한다. 혹은, 납득하지 못하더라도 '무엇에 근거한 판정인지'는 명확히 안다.
그 근거를 그대로 복사해 외주 개발사에 전달한다. "이 규칙, 이 페이지, 이렇게 고쳐주세요."

5번 단계가 결정적이다. 근거가 없으면 4번에서 멈춘다. "AI가 그렇대"는 외주사를 설득하지 못한다. 근거가 있어야 비로소 5번, 실제 개선으로 넘어간다. 우리가 참조패널에 공을 들이는 이유는 멋있어서가 아니라, 이 5번 단계를 가능하게 만들기 위해서다.

물론 솔직히 말하면, 모든 규칙에 대해 똑같이 풍부한 근거를 제시하는 단계까지는 아직 가지 못했다. 근거 문서가 잘 정비된 규칙도 있고, 더 채워 넣어야 하는 규칙도 있다. 이 '근거 커버리지를 넓히는 일'은 지식 베이스를 계속 보강하는 작업과 맞물려 진행 중이다. 다시 한번, 완성이 아니라 진행이다.

지식 베이스를 어떻게 짓는가 — 규칙 원문부터 공식 문서까지

근거를 대려면, 댈 근거가 먼저 있어야 한다. ViewCheck의 RAG가 검색해 오는 지식 베이스에는 어떤 것들이 들어가는지 정리해 보자. (구체적 운영 수치는 인프라/R&D 트랙에서 따로 다룰 예정이니, 여기서는 '무엇이 들어가는가'의 큰 그림만 보겠다.)

846규칙의 원문 정의: DS·CP·BP·SP 각 규칙이 '무엇을, 왜, 어떤 조건으로' 요구하는지의 정의. 판정의 1차 근거다.
KRDS 공식 가이드라인 본문: krds.go.kr에 공개된 원칙·스타일·컴포넌트·기본 패턴·서비스 패턴의 설명. KRDS는 각 구조 요소(스타일·컴포넌트·기본 패턴·서비스 패턴)에 대해 접근성 가이드를 제공하고, 웹 콘텐츠 접근성에서 WCAG 2.1 AA 충족을 기준으로 삼는다고 공식적으로 밝히고 있다(KRDS 공식, krds.go.kr).
공식 컴포넌트·패턴 스펙: 각 컴포넌트가 가져야 할 구조·상태·접근성 속성의 상세 규격.
행안부 지침과 품질관리 가이드: 7대 품질 영역의 상위 기준. 앞서 본 고시 제2025-46호 체계.
접근성 표준(KWCAG·WCAG): KRDS가 준거로 삼는 국내외 접근성 기준. KRDS 자체가 KWCAG 2.2와 WCAG 2.1을 따른다고 명시한다.

이 문서들의 성격이 제각각이라는 점이 설계의 묘미이자 난점이다. 어떤 건 짧고 단정적인 규칙 문장이고, 어떤 건 길고 설명적인 가이드 본문이며, 어떤 건 표와 수치로 된 스펙이다. 같은 '검색 대상'이라도 잘라내는 단위와 검색되는 방식이 달라야 한다.

특히 흥미로운 건 KRDS의 '구현 수준' 개념이다. KRDS의 서비스 패턴 사용성 가이드는 구현 수준을 '필수(Must-Do)·권장(Better)·최선(Best)' 세 단계로 나누고, 필수 항목을 우선하되 서비스 상황에 따라 권장·최선으로 점진 확대하라고 안내한다(KRDS 공식 가이드라인). 이건 판정 로직에 직접 영향을 준다. 어떤 규칙은 '필수'라서 미충족 시 명확한 미통과지만, 어떤 규칙은 '권장·최선'이라 미충족을 곧장 실패로 단정하면 과한 판정이 된다. RAG가 이 '수준' 정보를 함께 끌어와 줘야, 판정과 설명이 KRDS의 본래 의도에 맞게 균형을 잡는다. 근거 문서가 단지 '맞다/틀리다'를 넘어 '얼마나 엄격히 봐야 하는가'까지 알려주는 셈이다.

이런 정밀함이 결국 1편에서 우리가 강조한 '실측' 원칙과 만난다. 'KRDS 토큰이 1,082개냐 768개냐' 같은 사소해 보이는 숫자 하나도 실제 데이터로 확인하듯, '이 규칙이 필수냐 권장이냐'도 공식 문서에서 직접 확인해 근거에 반영한다. 추측으로 엄격도를 정하지 않는다. 지식 베이스를 짓는 일은 곧 '추측의 자리를 근거로 메우는 일'이다.

'의미로 검색한다'는 것 — 단어 매칭을 넘어서

RAG의 검색이 어떻게 '관련 있는 근거'를 찾아내는지, 비전공자 담당자를 위해 한 단계 더 풀어보자. 여기엔 RAG가 단순 키워드 검색과 결정적으로 다른 지점이 있다.

옛날식 검색은 '단어가 똑같이 들어 있는 문서'를 찾는다. "오류 안내"라는 단어가 들어 있는 문서를 찾는 식이다. 문제는, 같은 뜻을 다른 단어로 적은 문서를 놓친다는 것이다. 규칙 원문은 "오류 메시지"라고 적었는데 가이드는 "유효성 안내"라고 적었다면, 단어 매칭으로는 둘을 연결하지 못한다. KRDS처럼 용어가 풍부하고 표현이 다양한 도메인에서 이건 치명적이다.

RAG는 대신 '의미로 검색한다'. 문장을 의미의 좌표(임베딩, embedding)로 바꿔서, 단어가 달라도 '뜻이 가까운' 문서를 찾아낸다. "오류 안내"와 "유효성 메시지"가 단어는 달라도 의미 공간에서 가까이 있으면, 함께 검색된다. 이게 RAG가 이질적인 KRDS 문서들(짧은 규칙 문장, 긴 가이드 본문, 표 형태 스펙)을 가로질러 관련 근거를 모을 수 있는 핵심 메커니즘이다.

여기서 한 걸음 더 나아가면 '지식 그래프'가 등장한다. 규칙과 규칙, 컴포넌트와 패턴, 규칙과 접근성 표준이 서로 어떻게 연결되는지를 그래프로 엮어두면, '이 규칙과 관련된 다른 규칙·문서'까지 함께 끌어올 수 있다. 예컨대 어떤 버튼 컴포넌트 규칙을 검색했을 때, 그 버튼이 충족해야 할 접근성 표준(KWCAG·WCAG의 해당 항목)까지 연결해 함께 펼치는 식이다. KRDS가 각 컴포넌트·패턴 아래에 WCAG 적합성을 명시한다는 점은(KRDS 공식), 이런 연결을 만들기에 좋은 토대가 된다. 규칙과 표준이 공식 문서 차원에서 이미 이어져 있으니, 그 연결을 지식 그래프로 옮기면 근거의 그물이 더 촘촘해진다.

다만 솔직히 말하면, 의미 검색도 지식 그래프도 만능은 아니다. 의미가 '가깝다'는 게 항상 '관련 있다'는 뜻은 아니어서, 그럴듯하지만 엉뚱한 문서가 끌려올 때가 있다. 그래서 우리는 의미 검색의 결과를 그대로 신뢰하지 않고, 규칙 카테고리·페이지 유형 같은 결정론적 조건으로 한 번 더 거른다. 의미의 유연함과 규칙의 엄격함을 섞는 것 — 이게 검색 정밀도를 끌어올리는 우리 방식이다. 이 역시 완성됐다기보다, 계속 튜닝하는 영역이다.

RAG와 Vision의 만남 — 텍스트 근거만으로 부족할 때

앞에서 한 번 짚었듯, KRDS는 '시각적' 디자인 시스템이다. 그래서 텍스트 근거(RAG)만으로는 완결되지 않는 판정 영역이 존재한다. 이 대목을 조금 더 풀어보자.

예를 들어 어떤 규칙이 "주요 행동 버튼은 시각적으로 충분히 구별되어야 한다"고 요구한다고 하자. RAG는 이 규칙의 원문과, KRDS 공식 가이드의 버튼 관련 설명을 정확히 검색해 올 수 있다. 하지만 '이 사이트의 실제 버튼이 정말로 충분히 구별되는가'는, 텍스트 근거만 봐서는 알 수 없다. 화면을 봐야 한다.

여기서 1편에서 소개한 세 번째 엔진, **KRDScan(Vision AI·RAG)**이 일한다. KRDScan은 두 가지를 한 몸에 둔다. 하나는 이미지나 비표준 방식으로 구현된 UI를 '시각적으로 감지'하는 Vision AI고, 다른 하나는 규칙 원문·공식 문서를 검색해 근거를 대는 RAG 지식베이스다. 이 둘이 협력한다. Vision이 "화면의 이 영역에 이런 버튼이 있다"를 감지하면, RAG가 "그 버튼에 적용되는 규칙은 이것이고, 그 규칙의 요구 조건은 이렇다"를 끌어온다. 시각 정보와 규칙 근거가 합쳐져야, '화면이 규칙을 지켰는가'라는 시각적 판정이 비로소 근거를 갖는다.

이 결합이 중요한 이유는, DOM만 보는 규칙 엔진이 닿지 못하는 곳을 시각 + 근거가 함께 메우기 때문이다. DOM 구조에는 멀쩡히 버튼 태그가 없는데 이미지로 버튼을 그려 넣은 사이트, 비표준 방식으로 컴포넌트를 흉내 낸 사이트 — 이런 경우 DOM 규칙은 "해당 컴포넌트 없음(해당없음)"으로 처리하기 쉽다. 하지만 사람 눈에는 분명히 버튼이 보인다. Vision이 그걸 감지하고, RAG가 그에 맞는 규칙 근거를 붙여주면, '해당없음'으로 빠질 뻔한 규칙이 근거 있는 판정으로 살아난다.

다만 여기서도 충돌 방지 원칙은 변하지 않는다. DOM이 이미 명확히 통과/미통과로 판정한 규칙을, Vision이나 RAG가 함부로 뒤집지 않는다. Vision + RAG는 어디까지나 DOM이 비워둔 빈칸과, DOM이 볼 수 없는 시각 영역만 채운다. 누가 무엇을 책임지는지를 분명히 해야 결과가 흔들리지 않는다는 원칙은, RAG가 끼어들어도 그대로 유지된다. 근거를 더 풍부하게 대되, 판정의 일관성은 깨지 않는 것 — 이 균형이 우리가 가장 신경 쓰는 지점이다.

이 'RAG + Vision' 결합은 솔직히 우리 시스템에서 가장 실험적이고, 가장 어려운 영역이기도 하다. 시각 감지가 틀리면 근거도 엉뚱한 데 붙고, 근거가 부정확하면 시각 판정의 의미가 흐려진다. 두 불확실성이 곱해질 수 있다는 뜻이다. 그래서 이 영역은 특히 보수적으로 — '확신이 낮으면 단정하지 않는' 쪽으로 — 운영한다. 다음 편들에서 N/A와 시각 판정 이야기를 더 깊이 풀 때, 이 균형 잡기의 디테일을 더 보여줄 수 있을 것이다.

"근거를 댄다"는 것의 두 얼굴 — 신뢰와 검증 가능성

RAG가 근거를 댄다는 건, 단지 결과를 그럴듯하게 꾸민다는 뜻이 아니다. 거기엔 두 가지 서로 다른 가치가 들어 있다. 신뢰(trust)와 검증 가능성(verifiability)이다. 이 둘은 비슷해 보이지만 다르다.

신뢰는 사용자가 결과를 받아들이는 심리적 문턱을 낮춘다. "AI가 그렇대"보다 "공식 규칙에 근거해 그렇다"가 당연히 더 신뢰를 얻는다. 그런데 우리는 이 신뢰가 '과신'으로 번지는 걸 가장 경계한다. 근거가 붙어 있다고 해서 그 판정이 항상 옳은 건 아니기 때문이다. 스탠퍼드 연구가 보여줬듯, 근거를 댄다는 도구도 틀릴 수 있다. 근거의 존재가 '맹신해도 된다'는 신호가 되어서는 안 된다.

그래서 우리가 더 무게를 두는 건 검증 가능성이다. 검증 가능성이란 "이 판정이 옳은지 사용자가 직접 확인할 수 있는가"다. 근거를 함께 노출하는 진짜 이유가 여기 있다. 사용자가 그 근거를 열어보고, 공식 문서와 대조하고, "음, 이 경우엔 우리 사이트가 예외에 해당하는 것 같은데?"라고 스스로 판단할 수 있게 하는 것. 근거는 AI를 믿게 만드는 장치가 아니라, AI를 의심할 수 있게 만드는 장치여야 한다. 이게 우리가 도달한 다소 역설적인 결론이다.

이 관점은 앞서 인용한 법률 AI 흐름과도 통한다. 규제가 '검증 가능한 인용·설명 가능한 추론·문서화된 워크플로'를 요구한다는 건, 결국 "AI를 믿어라"가 아니라 "AI를 검증할 수 있게 하라"는 주문이다. ViewCheck의 참조패널도 같은 철학 위에 서 있다. 우리는 사용자가 우리 판정을 검증하고, 필요하면 반박할 수 있기를 바란다. 그 반박이 결국 우리 지식 베이스와 규칙을 더 정확하게 만들 거라고 믿기 때문이다.

1편에서 우리 팀이 스스로에게 거는 규칙으로 "추측으로 결론 내지 말고, 실제 데이터로 검증하라"를 소개한 바 있다. 이 규칙은 제품 사용자에게도 똑같이 적용된다. 우리는 사용자가 우리 결과를 '실제 근거로 검증'할 수 있기를 바란다. 만드는 사람이 추측 대신 실측을 약속한다면, 그 약속의 증거를 사용자 손에도 쥐여줘야 한다. 근거를 대는 일은, 그 증거를 건네는 일이다.

RAG의 한계 — 우리가 자만하지 않는 이유

이쯤에서 RAG의 한계를 정직하게 모아두고 가자. RAG는 환각을 줄이지만, 없애지는 못한다. 그 '줄이지만 없애지 못함'의 디테일을 알아야, 도구를 올바르게 쓸 수 있다.

첫째, 검색이 틀리면 근거도 틀린다. RAG의 답은 검색해 온 문서의 품질에 종속된다. 엉뚱한 규칙을 검색해 오면, 그 위에 아무리 잘 생성해도 근거 자체가 잘못이다. 이른바 '잘못된 근거로 정연하게 틀리는' 더 교묘한 환각이 생길 수 있다. 그래서 우리는 검색 정밀도에 가장 많은 공을 들이고, 확신이 낮으면 단정하지 않는 쪽을 택한다.

둘째, 모델이 근거를 무시하거나 과잉 해석할 수 있다. 근거 문서를 펼쳐줘도 모델이 자기 기억대로 답하거나, 근거를 부풀려 없는 결론을 만들 수 있다. 스탠퍼드 연구가 정리한 법률 도구들의 17~33% 환각률이 이 어려움의 실증이다(Magesh et al., 2025). 우리가 '핵심 판정은 DOM 규칙이 결정론적으로 내리고, AI는 설명·보완에만 둔다'는 분업을 고집하는 이유가 바로 이 한계 때문이다.

셋째, 지식 베이스가 낡으면 근거도 낡는다. RAG는 검색 대상이 최신이어야 최신 답을 준다. KRDS·행안부 지침이 개정됐는데 지식 베이스가 옛 버전이면, 근거를 댔지만 '낡은 근거'를 대는 셈이다. 그래서 지식 베이스 갱신은 일회성 작업이 아니라 상시 운영 과제다. 가오 외 서베이가 RAG의 장점으로 '지속적 지식 갱신'을 든 것은 역으로, 갱신을 게을리하면 그 장점이 단점으로 뒤집힌다는 뜻이기도 하다.

넷째, 시각 영역의 불확실성이 곱해진다. 앞서 본 RAG + Vision 결합에서, 두 단계의 오차가 누적될 수 있다. 이 영역은 특히 보수적으로 운영하지만, 그래도 우리가 가장 어렵게 여기는 부분이다.

이 한계들을 늘어놓는 게 제품에 불리해 보일 수도 있다. 하지만 우리는 반대로 생각한다. 한계를 아는 도구가, 한계를 모르는 도구보다 안전하다. "우리 RAG는 완벽합니다"라고 말하는 순간, 사용자는 검증을 멈추고 맹신하기 시작한다. 그게 진짜 위험이다. 그래서 우리는 매번 근거를 함께 보여주면서도, "이 근거를 직접 확인하세요"라는 메시지를 함께 건넨다. 도구의 겸손이 사용자의 안전이 된다고 믿는다.

검색·생성·증강 — RAG의 세 단계를 KRDS로 풀어보기

가오 외 서베이는 RAG 프레임워크를 검색(retrieval)·생성(generation)·증강(augmentation)의 세 축으로 나눠 분석한다(arXiv:2312.10997). 이 학술적 구분이 KRDS 컴플라이언스에서는 구체적으로 어떻게 작동하는지, 단계별로 한 번 더 풀어보자. 추상적인 RAG 개념을 우리 도메인에 착지시키는 작업이다.

검색 단계 — '관련 있는 그 규칙'을 찾기. 담당자의 페이지에서 어떤 신청 폼이 발견됐다고 하자. 이때 시스템은 846규칙 전체 중에서 '이 폼에 적용되는 규칙'을 골라내야 한다. 폼 작성·동의·오류 처리 같은 기본 패턴(BP) 규칙, 신청·검색 같은 서비스 패턴(SP) 규칙이 후보가 된다. 여기서 엉뚱한 규칙(예컨대 메인 페이지 배너에만 해당하는 규칙)을 끌어오면, 그 뒤 모든 게 어긋난다. 그래서 검색 단계는 '페이지 유형 + 컴포넌트 종류 + 규칙 카테고리'를 함께 고려해 후보를 좁힌다. 1편에서 '페이지 유형마다 적용되는 규칙이 다르다'고 강조한 이유가 여기서 다시 드러난다. 로그인 화면에서만 의미 있는 규칙을, 신청 화면 분석에 끌어오면 안 된다.

증강 단계 — 찾아온 근거를 모델 앞에 '제대로' 펼치기. 검색이 규칙 원문과 공식 가이드 대목을 찾아오면, 그걸 그냥 통째로 모델에 던지는 게 아니다. 어떤 순서로, 어느 만큼, 어떤 맥락과 함께 펼치느냐가 결과를 바꾼다. 너무 많은 근거를 한꺼번에 펼치면 모델이 핵심을 놓치고, 너무 적게 펼치면 맥락이 부족해진다. 또 앞서 본 KRDS의 '구현 수준(필수·권장·최선)' 정보도 이 단계에서 함께 주입되어야, 모델이 '이건 필수라 엄격히, 저건 권장이라 유연하게' 판단할 근거를 갖는다. 증강은 '근거를 펼치는 기술'이고, 생각보다 섬세하다.

생성 단계 — 펼쳐진 근거로 '설명'을 만들기. 마지막으로 모델은 펼쳐진 근거를 토대로, 사용자가 읽을 설명과 개선 방향을 만든다. 여기서 우리가 거는 제약이 중요하다. "펼쳐준 근거 안에서만 말하라. 근거에 없는 내용을 지어내지 말라." 이 제약이 환각을 억제하는 마지막 방어선이다. 그리고 생성된 설명에는 '어느 근거를 썼는지'가 함께 따라붙어, 참조패널로 노출된다. 생성 단계의 출력은 '설명'이지만, 그 설명은 항상 '출처'와 한 묶음으로 나온다.

이 세 단계를 관통하는 원칙은 하나다. 단계마다 '근거에서 멀어지지 않게' 붙잡는 것. 검색은 관련 근거를 정확히, 증강은 그 근거를 제대로, 생성은 그 근거 안에서만. 어느 한 단계라도 근거의 끈을 놓치면, 그 순간 RAG는 '근거기'에서 '추측기'로 전락한다. 우리가 가장 경계하는 게 바로 그 전락이다.

멀티페이지에서의 근거 — 사이트 전체로 확장할 때

1편에서 우리는 '다중 페이지 분석이 기본'이라는 원칙을 양보하지 않는 첫 번째 원칙으로 소개했다. RAG의 근거 제시도 이 다중 페이지 위에서 작동해야 한다는 점을, 한 번 짚고 넘어가자. 단일 페이지에서 근거를 대는 것과, 100페이지짜리 사이트 전체에서 근거를 대는 것은 난이도가 다르다.

같은 규칙이 여러 페이지에서 각각 다르게 판정될 수 있다. 메인 페이지에서는 통과한 'BP 오류 처리' 규칙이, 정작 신청 페이지에서는 미통과일 수 있다. 이때 근거는 '어느 페이지의 무엇이 그 규칙을 위반했는지'를 페이지 단위로 추적할 수 있어야 한다. "당신 사이트의 이 규칙이 미통과"라는 사이트 전체 차원의 결론과, "구체적으로 이 페이지의 이 요소가 원인"이라는 페이지 차원의 근거가 함께 와야, 담당자가 실제로 고칠 곳을 찾는다.

이건 단순히 결과를 합치는 문제가 아니다. 사이트 전체로 보면 '한 페이지라도 어기면 사이트가 그 규칙을 어긴 것'이라는 보수적 집계를 택하더라도, 근거 제시는 그 보수적 결론의 '원인 페이지'를 정확히 짚어줘야 의미가 있다. 막연히 "사이트 어딘가가 문제"라고만 하면, 담당자는 100페이지를 다시 손으로 뒤져야 한다. 그건 자동화의 의미를 반쯤 잃는 것이다. 그래서 우리는 근거를 '사이트 결론 + 페이지별 위치'의 두 층위로 관리하려 한다.

솔직히 이 다중 페이지 근거 추적은 우리가 지금도 정교화하고 있는 영역이다. 페이지가 수십, 수백 개로 늘어날수록 근거의 양도 폭증하고, 그걸 사용자가 길을 잃지 않게 정리해 보여주는 일은 그 자체로 UX 과제다. '근거를 많이 대는 것'과 '근거를 알아보기 쉽게 대는 것'은 다른 문제다. 우리는 후자를 향해 계속 다듬는 중이다. 다중 페이지에서 근거를 어떻게 집계·정리하는지의 구체적 디테일은, 인프라 트랙에서 따로 풀어볼 만한 주제다.

담당자 관점의 한 장면 — 근거가 만드는 차이

추상을 다시 구체로 내려보자. 1편에 등장한 가상의 주무관에게 돌아간다. 이번엔 그가 '근거'를 손에 쥐었을 때 무엇이 달라지는지에 초점을 맞춘다.

그는 ViewCheck로 사이트를 분석했고, 결과 중 신청 페이지의 한 항목이 미통과로 떴다. 예전 같으면 두 가지 길 중 하나였다. 결과를 그냥 믿고 외주사에 "고쳐 달라"고 막연히 요청하거나, 결과를 못 믿어서 무시하거나. 둘 다 좋은 길이 아니다. 막연한 요청은 외주사와 핑퐁을 부르고, 무시는 문제를 방치한다.

이번엔 다르다. 그는 미통과 항목 옆 참조패널을 연다. 거기엔 적용된 KRDS 규칙과, 그 근거가 된 공식 가이드의 해당 대목이 보인다. 그는 그 규정이 '필수' 수준인지 '권장' 수준인지까지 확인한다. 만약 필수 항목이라면, 그는 망설임 없이 그 근거를 복사해 외주사에 전달한다. "이 규칙, 이 페이지, 이렇게 고쳐주세요. 근거는 이 공식 문서입니다." 외주사는 더 이상 "그게 정말 필요하냐"고 따지기 어렵다. 출처가 붙은 요청이기 때문이다.

만약 그 항목이 애매하다고 느껴지면 — 예컨대 "우리 사이트는 이런 사정 때문에 이렇게 만들었는데" 싶으면 — 그는 채팅으로 그냥 되묻는다. "이 항목, 이런 경우에도 미통과인가요?" 그러면 시스템은 같은 근거 문서를 토대로 답한다. 답이 그를 완전히 설득하지 못할 수도 있다. 하지만 적어도 그는 '무엇에 근거한 판정인지'를 명확히 알고, 그 위에서 자기 판단을 내릴 수 있다.

이 장면에서 ViewCheck가 한 일은 '담당자 대신 판단하기'가 아니다. 담당자가 더 빠르고 더 근거 있게 판단하도록, 출처를 정리해 건넨 것이다. 최종 판단과 책임은 여전히 사람에게 있다. 1편에서 말한 그 구도를, 우리는 RAG로도 똑같이 지킨다. AI는 근거를 모아 건네는 동료이지, 결정을 대신하는 상관이 아니다.

근거의 형식 — '어떻게 보여줄 것인가'도 설계다

근거를 검색하고 생성하는 것까지 했다면, 마지막 관문이 남는다. 그 근거를 사용자에게 '어떤 형식으로' 보여줄 것인가다. 이건 사소해 보이지만, 실제로는 근거의 효용을 좌우하는 결정적 단계다. 아무리 정확한 근거를 끌어와도, 사용자가 알아볼 수 없는 형식으로 들이밀면 그 근거는 없는 것이나 마찬가지다.

우리가 고민한 형식의 축은 대략 셋이다. 첫째, 출처의 구체성이다. "KRDS 가이드에 따르면"처럼 막연한 출처는 검증을 어렵게 한다. "KRDS 기본 패턴 가이드의 오류 처리 항목"처럼 구체적이어야, 사용자가 그 대목을 직접 찾아갈 수 있다. 둘째, 판정과 근거의 거리다. 판정 결과(미통과)와 그 근거를 너무 멀리 떼어놓으면, 사용자가 둘을 연결하지 못한다. 결과 바로 옆 또는 아래에서 근거를 확인할 수 있어야 한다. 셋째, 근거의 위계다. 핵심 근거(적용 규칙)와 보조 근거(관련 표준, 공식 가이드)를 같은 무게로 늘어놓으면 사용자가 길을 잃는다. '가장 직접적인 근거'를 앞세우고, 보조 근거는 펼쳐볼 수 있게 정리하는 위계가 필요하다.

증적으로 본 참조패널(인용 탭)은 이 세 축을 한 화면에 담으려는 시도다. 판정 옆에서, 구체적 출처를, 위계 있게 보여주는 것. 물론 이게 모든 규칙에 대해 완벽하게 구현됐다고는 말 못 한다. 어떤 규칙은 근거 형식이 잘 정돈됐고, 어떤 규칙은 더 다듬어야 한다. 근거의 '내용'을 채우는 일과 근거의 '형식'을 다듬는 일은 둘 다 진행 중이고, 둘 다 끝이 없는 작업이다.

이 형식의 문제가 왜 중요한지는, 다시 담당자의 행동으로 돌아가면 분명해진다. 담당자가 근거를 외주사에 전달할 때, 그 근거의 형식이 그대로 '지시의 명확성'이 된다. "이 규칙, 이 페이지, 이 공식 문서의 이 대목"이라는 형식이 잘 갖춰져 있으면, 그 자체로 완결된 작업 지시가 된다. 형식이 부실하면, 담당자가 그걸 다시 정리하느라 시간을 쓴다. 근거의 형식을 다듬는 일은, 결국 담당자의 일을 덜어주는 일이다. 우리가 형식에 공을 들이는 이유다.

해외 사례와의 대화 — 근거 중심 컴플라이언스의 흐름

KRDS에 RAG로 근거를 대는 우리 실험이 외딴 시도가 아니라는 점도 짚고 싶다. '근거 중심 AI 컴플라이언스'는 지금 여러 고위험 도메인에서 동시에 일어나는 흐름이다.

법률 분야가 가장 앞서 있다. 앞서 인용한 스탠퍼드 RegLab의 연구는 비판적이었지만, 그 비판의 전제는 "법률 AI 도구들이 RAG로 근거를 대는 방향으로 이미 움직이고 있다"는 사실이었다. 즉 업계 표준이 '근거 없는 생성'에서 '근거 있는 생성'으로 옮겨가는 중이고, 연구자들은 그 근거가 충분히 믿을 만한지를 까다롭게 검증하는 단계로 진입한 것이다(Magesh et al., Journal of Empirical Legal Studies, 2025). 우리에게 이건 좋은 신호다. 근거를 대는 일이 '경쟁 우위'를 넘어 '기본 요건'이 되어간다는 뜻이기 때문이다.

법률 외에도 규제 준수에 RAG를 쓰는 연구들이 꾸준히 나온다. 예컨대 의료기기 규정 준수에 RAG 기반 프레임워크를 적용해 표준 적용 여부를 판단하고 관할권 간 추론을 돕는 연구도 발표됐다(arXiv, "Standard Applicability Judgment and Cross-jurisdictional Reasoning: A RAG-based Framework for Medical Device Compliance"). 도메인은 다르지만 구조는 같다. 복잡하고 자주 바뀌는 규정, 높은 정확성 요구, 투명한 근거의 필요 — 이 조건들이 모이는 곳마다 RAG가 호출된다.

ViewCheck가 다루는 KRDS 컴플라이언스도 정확히 그 조건의 한가운데 있다. 우리는 이런 해외·타 도메인 사례를 자주 들여다본다. 1편에서 "KRDS를 점검하는 도구가 KRDS만 알아서는 안 된다"고 적었듯, 근거 중심 컴플라이언스를 만드는 도구는 다른 도메인이 같은 문제를 어떻게 푸는지를 알아야 한다. 법률 AI가 '근거의 신뢰도'를 어떻게 평가하는지, 의료 규정 AI가 '관할권 차이'를 어떻게 다루는지 — 이런 사례들은 우리가 KRDS의 '구현 수준(필수·권장·최선)'을 더 정교하게 판정에 반영하는 데 실마리를 준다. 남의 것을 베끼는 게 아니라, 잘 만든 시도들끼리 대화시키면 우리 빈틈이 더 잘 보이기 때문이다.

추측 금지라는 우리 자신의 규칙 — 만드는 사람부터

이 글의 제목에 '추측 없는 진단'이라는 표현을 넣은 데에는, 제품의 동작 원리를 넘어선 의미가 하나 더 있다. 그건 우리 팀 자신의 작업 규칙이기도 하다는 점이다. 제품이 사용자에게 '근거 있는 판정'을 약속한다면, 그 제품을 만드는 우리부터 '추측 없는 개발'을 해야 앞뒤가 맞는다.

우리 작업 원칙 중에 이런 게 있다. "기능 구현이든 버그 수정이든, 추측으로 원인을 판단하거나 해결 방안을 제시하지 말 것. 반드시 실제 소스 코드를 읽고, API 호출 결과를 확인하고, 데이터를 조회하고, 배포 상태를 확인한 뒤에 판단할 것." 코드 경로만 훑어보고 "문제없다"고 결론 내리는 걸 금지한다. 반드시 실제로 돌려보고, 응답을 눈으로 확인한 뒤에야 "된다"고 말한다. 확인 안 된 사항은 "확인 안 됨"이라고 정직하게 명시한다.

이게 RAG의 철학과 정확히 같다는 걸, 우리는 작업하면서 자주 깨닫는다. RAG가 모델에게 "기억 말고 근거를 보고 답하라"고 요구하듯, 우리는 우리 자신에게 "추측 말고 실측을 보고 판단하라"고 요구한다. 모델이 환각을 일으키듯, 개발자도 '코드가 이럴 것이다'라는 추측으로 환각을 일으킬 수 있다. 그 추측이 그럴듯할수록 위험하다. 모델의 환각을 근거 검색으로 억제하듯, 우리는 우리의 추측을 실측 검증으로 억제한다.

이 글에서 인용한 모든 출처를 WebSearch로 실재 여부를 검증한 것도 같은 맥락이다. RAG·환각 연구의 학술 원전(루이스 외, 가오 외, 지 외), 법률 AI의 실증 연구(마게쉬 외, 스탠퍼드 HAI), 국내 공식 기준(행안부 고시, KRDS 공식) — 이 인용들은 '들어본 것 같다'가 아니라 실제로 찾아 확인한 것들이다. 근거를 대는 컴플라이언스를 주제로 한 글이, 정작 자기 인용은 추측으로 채운다면 그건 자기모순이다. 우리는 그 모순을 피하려 했다. 만드는 사람이 추측을 금지하지 않으면서, 어떻게 추측 없는 진단을 만들겠는가.

이 자기 규율은 답답하고 느리다. 추측으로 빨리 결론 내는 편이 늘 더 쉽다. 하지만 공공 영역의 진단 도구에서, 우리는 빠른 추측보다 느린 실측이 옳다고 믿는다. 그 믿음이 제품의 신뢰로 이어지고, 길게 보면 그게 더 빠른 길이라고 생각한다. 근거를 대는 일은, 그래서 제품의 기능이면서 동시에 우리의 윤리다.

RAG는 '정답기'가 아니라 '근거기'다 — 톤에 대하여

이 글을 닫기 전에, 1편에서 했던 약속 하나를 다시 확인하고 싶다. 우리는 ViewCheck를 '완성된 정답기'가 아니라 '점점 더 정확해지는 진단 동료'로 포지셔닝한다고 했다. RAG 이야기로 이 포지셔닝을 한 번 더 벼려보자.

RAG는 '정답기'가 아니다. RAG는 '근거기'다. RAG가 하는 일은 정답을 보증하는 게 아니라, 답에 근거를 붙여 검증 가능하게 만드는 것이다. 이 구분이 중요하다. 만약 우리가 RAG를 '정답기'로 포장하면, 그건 1편에서 경계한 '대화형의 함정'이나 'AI 맹신'과 다를 바 없는 과장이 된다. RAG를 쓴다는 도구조차 6번에 1번은 틀린다는 실증을 우리는 알고 있다. 그 사실을 숨기고 "근거 기반이라 정확합니다"라고만 말하는 건 정직하지 않다.

그래서 우리는 이렇게 말한다. ViewCheck의 RAG는 '근거를 대는' 도구이지, '정답을 보증하는' 도구가 아니다. 우리가 보증하려는 건 정답이 아니라 추적 가능성이다. 모든 판정이 어떤 규칙·어떤 문서에 닿아 있는지를 추적할 수 있게 하는 것. 그래서 사용자가 그 추적을 따라가 직접 검증할 수 있게 하는 것. 거기까지가 우리가 책임지는 영역이고, 최종 판단은 사용자의 몫으로 남긴다.

이 톤이 홍보 글로서는 답답하게 들릴지도 모른다. "그냥 좋다고, 정확하다고 하면 안 돼?" 그러나 공공 영역의 진단 도구에서, 우리는 과장된 자신감보다 정직한 한계 인정이 길게 보면 더 신뢰받는다고 믿는다. 근거를 대는 도구가 정작 자기 한계에 대해서는 근거 없이 '완벽하다'고 우긴다면, 그건 자기모순이다. 우리는 그 모순을 피하고 싶다. RAG로 근거를 대는 컴플라이언스를 만들면서, 우리 자신의 주장에도 똑같이 근거를 대고 한계를 밝히려는 이유가 여기 있다.

다음 편으로 가는 다리 — 근거에서 N/A로

이번 글에서 우리는 '근거를 대는 일'에 집중했다. AI가 "그렇대"라고 얼버무리는 대신 "846규칙 원문·KRDS 공식 문서에 근거해 그렇다"를 보여주는 RAG 파이프라인. 그 근거가 참조패널로 노출되어 담당자의 실제 행동(외주사 전달, 보고, 검증)을 가능하게 만드는 구조. 그리고 RAG의 한계와, 그 한계를 DOM 규칙 분업으로 가두는 우리의 보수적 설계.

하지만 한 가지 큰 주제를 자꾸 다음으로 미뤄왔다. 바로 '해당없음(N/A)'을 줄이는 일이다. 이번 글에서 우리는 "DOM이 비워둔 빈칸을 Vision + RAG가 채운다"고 여러 번 언급했지만, 그 '빈칸을 어떻게 줄이고 채우는가'는 그 자체로 한 편을 통째로 할애할 만큼 깊은 주제다. 어떤 규칙이 진짜로 해당없음인지(컴포넌트가 정말 없음), 아니면 분석이 '못 본' 것뿐인지(결함)를 가르는 일 — 이건 근거를 대는 일만큼이나 진단의 정확성을 좌우한다.

근거(이번 편)와 N/A 해소(다음 주제)는 사실 동전의 양면이다. 근거를 잘 대려면 판정이 명확해야 하고, 판정을 명확히 하려면 '애매하게 비워둔 N/A'를 줄여야 한다. 그래서 트랙 A의 다음 편들에서는 이 'N/A를 줄이는 연구'와, 그와 짝을 이루는 '환각을 더 적극적으로 억제하는 실험'을 이어서 다룰 예정이다.

마무리 — 추측을 근거로 바꾸는 일

처음으로 돌아가자. "왜 미통과인데?"라는 한마디. 이 글은 그 한마디에 제대로 답하기 위한 우리의 실험을 30,000자에 걸쳐 풀어쓴 것이다.

답은 이렇게 요약된다. AI에게 "알아서 판단해"라고 맡기는 대신, 판단에 필요한 근거 문서(846규칙 원문, KRDS 공식 가이드, 컴포넌트 스펙, 행안부 지침, 접근성 표준)를 먼저 검색해 펼쳐주고, 그 근거를 함께 제시하게 한다. 가장 환각이 위험한 핵심 판정은 결정론적 DOM 규칙이 내리고, AI와 RAG는 그 판정을 설명하고 보완하는 자리에만 둔다. 그리고 모든 결과 옆에는, 사용자가 직접 검증할 수 있도록 근거를 노출한다.

RAG는 환각을 줄이는 강력한 도구다. 루이스 외의 원전이 그 토대를 놓았고, 가오 외의 서베이가 그 효용을 정리했으며, 우리 같은 도메인 특화 컴플라이언스가 그 응용처가 된다. 동시에 RAG는 만병통치약이 아니다. 스탠퍼드의 실증이 보여줬듯, 근거를 댄다는 도구조차 틀릴 수 있다. 우리는 이 두 사실 사이에서, RAG에 기대되 맹신하지 않는 균형을 잡으려 매일 씨름한다.

공공 웹의 품질을 진단할 때, 우리가 끝내 지키고 싶은 건 단순하다. 추측을 사실로 위장하지 않는 것. 모르면 모른다고 하고, 안다면 그 근거를 댄다. AI가 똑똑해서 믿는 게 아니라, AI가 근거를 댈 수 있게 강제했기 때문에 검증할 수 있는 것이다. 그 차이가 장난감과 도구를 가른다고, 우리는 여전히 믿는다.

다음 편에서는 이 근거의 이야기를 'N/A를 줄이는 연구'로 이어가겠다. 비워둔 빈칸을 어떻게 채우고, 채우면서도 어떻게 추측에 빠지지 않는가 — 근거를 대는 일의 또 다른 얼굴을 함께 들여다보자.

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 검증했다. RAG·환각 연구의 학술 원전과 국내 공식 기준을 함께 실었다.

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

행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 국가법령정보센터. https://www.law.go.kr/행정규칙/전자정부웹사이트품질관리지침
KRDS(범정부 UI/UX 디자인시스템) 공식 사이트 — 디지털 정부서비스 UI/UX 가이드라인. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/
KRDS, "UI/UX 가이드라인 소개" — 스타일·컴포넌트·기본 패턴·서비스 패턴별 접근성 가이드 및 WCAG 2.1 AA 준거 명시. https://www.krds.go.kr/html/site/utility/utility_07.html
KRDS, 「디지털 정부서비스 UI/UX 가이드라인」(PDF, 2024). KRDS-uiux 공식 배포 저장소. https://raw.githubusercontent.com/KRDS-uiux/upload-files/main/디지털%20정부서비스%20UIUX가이드라인%20[240709].pdf

해외 — RAG / 환각 연구 / 컴플라이언스 AI

Lewis, P., Perez, E., Piktus, A., et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." Advances in Neural Information Processing Systems (NeurIPS) 33, 2020. arXiv:2005.11401. https://arxiv.org/abs/2005.11401
Gao, Y., Xiong, Y., Gao, X., et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." 2023–2024. arXiv:2312.10997. https://arxiv.org/abs/2312.10997
Ji, Z., Lee, N., Frieske, R., et al. "Survey of Hallucination in Natural Language Generation." ACM Computing Surveys, Vol. 55, No. 12, Article 248, 2023. https://dl.acm.org/doi/10.1145/3571730
Magesh, V., Surani, F., Dahl, M., et al. "Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools." Journal of Empirical Legal Studies, 2025. Stanford RegLab. https://reglab.stanford.edu/publications/hallucination-free-assessing-the-reliability-of-leading-ai-legal-research-tools/
Stanford HAI, "AI on Trial: Legal Models Hallucinate in 1 out of 6 (or More) Benchmarking Queries." Stanford Institute for Human-Centered AI. https://hai.stanford.edu/news/ai-trial-legal-models-hallucinate-1-out-6-or-more-benchmarking-queries