다섯 특허 ↔ 세 방법, 한 장으로 보는 지도 — 1개월차 마무리

들어가며 — 오리엔테이션의 마지막, 한 장 지도

오늘이 1개월차, 그러니까 오리엔테이션의 마지막 글입니다. 한 달 동안 꽤 많은 것을 깔아두었습니다. 처음엔 "왜 사람 손만으로는 웹 품질 점검이 버거운지"를 이야기했고, 그다음엔 "웹 품질을 보는 세 시점 — 설계·운영·판단"이라는 큰 틀을 세웠습니다. 이어서 그 세 시점을 하나씩, 운영 시점의 URL 분석과 설계 시점의 Figma 분석, 그리고 판단 시점의 LLM 분석으로 풀어드렸지요. 이번 주 월요일과 수요일에는 "그 방법들을 받치는 다섯 건의 특허"가 왜 필요했고, 기능은 베껴도 방법은 왜 못 베끼는지를 짚었습니다.

오늘은 이 모든 것을 한 장으로 묶습니다. "다섯 개의 특허가 세 개의 방법에 어떻게 걸치는지"를 그린 매핑 지도입니다. 이 지도가 왜 중요하냐면, 앞으로 다음 달부터 펼칠 심층편들의 목차이기 때문입니다. "아, 이 특허가 이 방법을 받치는 것이었구나" 하고 전체 그림이 한 번 잡히면, 다음 달부터 이어질 영역별 깊은 이야기를 따라가기가 훨씬 수월해집니다. 오리엔테이션이라는 한 달의 목적이 바로 여기에 있습니다. 깊이 파고들기 전에, 전체 지도를 먼저 손에 쥐어드리는 것이지요.

사실 지도라는 것이 원래 그렇습니다. 낯선 도시를 걸을 때, 골목 하나하나를 다 외우고 나서야 길을 나서는 사람은 없습니다. 전체 지형을 한 번 훑어 "여기가 중심이고, 저쪽이 강이며, 이 길이 저 광장으로 이어지는구나" 정도만 잡아두면, 막상 걸을 때 헤매지 않습니다. 오늘 그리는 지도도 그런 쓰임입니다. 다섯 특허와 세 방법의 세부를 지금 다 이해하실 필요는 없습니다. "무엇이 어디에 걸치는지"라는 큰 지형만 눈에 담으시면, 다음 달부터 각 골목을 걸을 때 길을 잃지 않습니다. 그래서 오늘 글은 정보를 빽빽이 채우기보다, 이미 본 것들의 관계를 느슨하게 이어드리는 데 목적이 있습니다.

미리 말씀드리면, 오늘 글은 새로운 사실을 소개하는 자리가 아닙니다. 한 달 동안 나눠서 본 조각들 — 세 시점, 세 방법, 다섯 특허 — 을 한 표 위에 나란히 놓고, 서로 어떻게 맞물리는지 잇는 자리입니다. 그래서 오늘은 편하게 읽으셔도 됩니다. 외울 것도 없습니다. "이 특허가 저 방법에 걸치는구나" 하는 큰 그림만 눈에 익히시면, 다음 달부터의 글들이 "아, 이게 그 표의 이 칸 이야기였구나" 하고 저절로 자리를 잡습니다.

아래는 그 세 방법이 결국 모여 한 화면의 846규칙 결과로 집계된 모습입니다. 오늘 그릴 지도의 "종착점"이라고 보시면 됩니다. 다섯 특허와 세 방법이 결국 이 한 화면의 결과로 모입니다. 화면 상단엔 전체 준수율과 네 카테고리(디자인 스타일·컴포넌트·기본 패턴·서비스 패턴)의 요약이 있고, 그 아래로 규칙 하나하나의 판정이 이어집니다. 오늘 이야기가 어디로 향하는지, 이 그림을 먼저 마음에 담아두고 시작하겠습니다.

URL 하나로 분석한 846규칙 전체 집계 종합 화면. 상단 요약 점수 카드와 그 아래 규칙별 판정이 이어지는, 다섯 특허와 세 방법이 결국 모이는 종착점 (기관명·도메인 블러)

본론 1 — 다섯 특허, 한 줄씩 다시 보기

먼저 이번 주에 본 다섯 건을 한 줄씩 다시 짚겠습니다. 다섯 건 모두 현재 출원 중인 기술입니다. 등록특허가 아니라 출원 기술이라는 점을 먼저 정확히 해두겠습니다. 오늘 이야기는 "이미 확정된 권리를 자랑하는" 자리가 아니라, "이런 방법들을 직접 만들어 권리로 정리해 두려 한다"는 이야기에 가깝습니다.

① 시점 비교(설계·운영 교차 검증) — 만들기 전의 설계 도면과 운영 중인 실제 화면을, 같은 기준으로 견주어 보는 방법입니다. 설계 시점(Figma)과 운영 시점(URL)이라는 두 시점을 하나의 잣대 위에 올려 교차로 확인합니다. "도면에선 맞았는데 운영에선 어긋난 곳"이 이 비교에서 드러납니다.
② 기준 자동 판정(846규칙) — 화면이나 도면의 요소가 KRDS 기준에 맞는지, 846개 규칙으로 자동 대조하는 방법입니다. 846규칙은 디자인 스타일(DS) 120개, 컴포넌트(CP) 446개, 기본 패턴(BP) 108개, 서비스 패턴(SP) 172개로 나뉩니다. 준수율이라는 숫자가 결국 이 판정에서 나옵니다.
③ 렌더링 기반 화면 수집·측정 — 운영 중인 사이트를 실제로 브라우저에 띄워, 화면을 그대로 수집하고 측정하는 방법입니다. 스크린샷을 뜨고, 화면에 계산된 색·간격·크기를 실제로 재는 것이지요. 정적인 코드만 훑는 것이 아니라, "실제로 그려진 그 화면"을 다룹니다.
④ 위반 위험도 등급화 및 개선 우선순위 산정 — 발견된 위반 수백 건에 위험도를 매겨 P0부터 P3까지 등급을 나누고, "무엇부터 고칠지"의 순서를 만드는 방법입니다. 긴 목록을 "오늘 고칠 다섯 개"로 좁혀주는 자리이기도 합니다.
⑤ 코드·화면 결합 판정(DOM·Vision 융합) — 코드로 읽는 판정과 화면으로 보는 판정을 결합하는 방법입니다. 코드(DOM)로 확인 가능한 부분은 코드로 보고, 코드만으로는 판단이 어려운 시각적 영역은 화면(Vision)으로 봅니다. 두 방식이 서로의 빈칸을 메웁니다.

이 다섯을 관통하는 감각이 하나 있습니다. 전부 "사람이 눈으로 하나하나 따지던 일을, 같은 잣대로 자동화한 방법"이라는 점입니다. 색이 규정에 맞는지, 버튼에 라벨이 있는지, 이 위반이 저 위반보다 급한지 — 원래는 숙련된 사람이 오래 들여다봐야 겨우 판단하던 것들입니다. 그것을 매번 같은 기준으로, 재현 가능하게 자동으로 내주는 절차, 그 절차가 다섯 특허의 공통 뿌리입니다.

그리고 한 가지 더 짚어둘 것이 있습니다. 위반을 찾는 데서 끝내지 않고 "어떻게 고치라"는 개선안까지 글로 정리해 주는 기능이 있는데(지난 판단 시점 편에서 본 그 개선안입니다), 이것은 위 다섯 방법 중 판단 영역이 실제로 내주는 산출물에 해당합니다. 오늘은 개선안을 별도의 여섯 번째 방법으로 세지 않고, 다섯 방법이 만들어낸 결과 위에 얹히는 실용적 출력으로만 다루겠습니다. 방법은 다섯, 개선안은 그 다섯이 협력해 내주는 결과물, 이렇게 정리하는 편이 정확합니다.

본론 2 — 세 방법, 세 시점을 다시 세워두기

다섯 특허를 어디에 걸칠지 이야기하려면, 걸칠 자리인 "세 방법"을 먼저 다시 세워두어야 합니다. 이 세 방법은 한 달 내내 이야기한 세 시점과 그대로 짝을 이룹니다.

URL 분석 = 운영 시점 — 실제로 서비스 중인 사이트에 주소를 넣고, 사람들이 지금 쓰고 있는 그 화면을 통째로 점검하는 방법입니다. "지금 이 순간의 사이트"를 보는 자리입니다.
Figma 분석 = 설계 시점 — 아직 코드로 만들기 전, 디자인 도면 단계에서 미리 점검하는 방법입니다. "만들기 전에 잡는다"는 자리이지요.
LLM 분석 = 판단 시점 — 규칙만으로 다 채우지 못한 빈칸을 메우고, 흩어진 위반을 해석해 우선순위와 개선안으로 잇는 방법입니다. "그래서 무엇부터 어떻게"를 잡아주는 자리입니다.

이 세 방법의 관계를 한 문장으로 줄이면 이렇습니다. 설계 시점에서 미리 잡고, 운영 시점에서 현실을 확인하고, 판단 시점에서 결론을 내립니다. 시간 순서로 보면 설계 → 운영이고, 그 둘 위에 판단이 얹히는 구조입니다. 세 시점이 서로 다른 순간의 사이트를 보기 때문에, 셋을 합쳐야 비로소 사이트의 전 생애가 한눈에 들어옵니다. 하나만 보면 반쪽입니다. 설계만 보면 "도면은 좋았는데 실제로 어떻게 나왔는지"를 모르고, 운영만 보면 "왜 그렇게 만들어졌는지"의 원류를 놓칩니다.

그래서 오늘 지도의 핵심은 단순합니다. 다섯 개의 특허가 이 세 방법 위에 어떻게 배치되는가. 어떤 특허는 한 방법에만 깊게 걸리고, 어떤 특허는 두세 방법에 두루 걸칩니다. 한 특허가 여러 방법을 받치기도 하고, 한 방법이 여러 특허로 받쳐지기도 합니다. 이 유연한 배치가 바로 "다섯 개로 나눠 낸" 이유와도 이어집니다. 독립된 기술 단위로 정리해 두었기 때문에, 여러 자리에 자유롭게 걸칠 수 있는 것입니다. 하나의 큰 덩어리로 뭉쳐두었다면 이런 유연한 배치는 나오지 않았을 것입니다.

다섯 특허 자물쇠가 URL·Figma·LLM 세 방법 기둥에 선으로 이어지고, 일부 특허는 여러 기둥에 동시에 걸치는 한 장의 연결 지도. 한 특허가 여러 방법을 받치고 한 방법이 여러 특허로 받쳐지는 구조를 담은 개념 도식 (Gemini 1:1)

이 지도를 읽는 방법을 미리 귀띔해 드리면 두 가지 방향이 있습니다. 세로로 읽으면 "각 방법에 무슨 특허가 걸치나"가 보이고, 가로로 읽으면 "각 특허가 어느 방법을 받치나"가 보입니다. 세로 방향은 "URL 분석 하나를 돌릴 때 어떤 방법들이 함께 작동하는가"를 알려주고, 가로 방향은 "이 특허 하나가 여러 시점에서 어떻게 쓰이는가"를 알려줍니다. 아래에서 방법별로 하나씩 훑은 뒤, 마지막에 이 둘을 한 표로 겹쳐 보겠습니다.

본론 3 — URL 분석(운영 시점)에 걸치는 특허

먼저 운영 시점, URL 분석입니다. 실제로 서비스 중인 사이트에 주소를 넣고 통째로 점검하는 방법이지요. 세 방법 중 가장 종합적인 자리이고, 그만큼 다섯 특허 중 가장 많은 넷이 여기에 걸칩니다.

③ 렌더링 기반 화면 수집·측정이 URL 분석의 토대입니다. 운영 사이트를 실제 브라우저에 띄워 화면을 그대로 수집하고, 화면에 계산된 색·간격·크기를 실제로 재는 것에서 모든 것이 시작됩니다. 정적인 파일만 훑는 것과, 실제로 그려진 화면을 재는 것은 전혀 다릅니다. 운영 시점 편에서 강조했듯, 스테이징에선 멀쩡한데 운영에선 깨지는 일이 흔한데, 그런 어긋남은 오직 "실제로 그려진 화면"을 재야 잡힙니다. 그래서 이 렌더링 기반 수집·측정이 URL 분석의 출발점이자 뼈대입니다.

**② 기준 자동 판정(846규칙)**이 그 위에서 판정을 내립니다. 수집한 화면의 요소가 KRDS 846규칙에 맞는지 자동으로 대조하는 것이지요. 디자인 스타일 120개, 컴포넌트 446개, 기본 패턴 108개, 서비스 패턴 172개, 도합 846개의 규칙이 한 번의 분석에서 순차로 돌아갑니다. 준수율이라는 숫자가 여기서 나오고, 어느 규칙에서 왜 깎였는지까지 규칙 단위로 거슬러 올라갈 수 있습니다. 근거 없이 뚝 떨어진 점수가 아니라, 846개의 개별 판정이 쌓여 만들어진 비율이라는 감각이 중요합니다.

④ 위반 위험도 등급화 및 개선 우선순위 산정이 그 결과를 정리합니다. 운영 사이트는 페이지가 많아 위반이 수백 건씩 쏟아지는데, 이걸 그냥 나열하면 담당자는 어디부터 손대야 할지 막막합니다. 그래서 각 위반에 위험도를 매겨 P0부터 P3까지 줄을 세웁니다. 사용자를 아예 막아버리는 치명적 위반은 위로, 잘 안 쓰는 페이지의 사소한 위반은 아래로. 이 등급화가 있어야 긴 목록이 "이것부터"라는 행동 가능한 형태로 바뀝니다. 이 위험도 등급화의 원리는 다음 달이 아니라 **4개월차(위험도)**에서 본격적으로 파고듭니다.

**① 시점 비교(설계·운영 교차 검증)**도 URL 분석에 걸칩니다. 운영 시점은 이 비교의 "운영 쪽 절반"을 담당합니다. 설계 도면과 운영 화면을 같은 잣대로 견줄 때, 운영 화면 쪽 데이터가 바로 URL 분석에서 나옵니다. 또한 운영 사이트는 페이지가 많으니, 같은 사이트를 여러 시점에 걸쳐 다시 점검하며 "지난번보다 나아졌나"를 비교하는 일도 이 시점 비교의 몫입니다. 한 장의 사진이 아니라 연속된 기록으로 사이트를 따라가는 방식이지요. 여러 페이지를 한꺼번에 집계해 일관성을 보는 다중 페이지 이야기는 **6개월차(다중 페이지)**에서 자세히 다룹니다.

한 가지 더, URL 분석에는 앞서 다섯 특허를 관통한다고 말씀드린 "실제로 그려진 화면을 본다"는 성격이 가장 짙게 배어 있습니다. 정적인 코드만 보는 도구는 "코드상으로는 이렇게 되어 있다"까지밖에 못 갑니다. 그런데 요즘 웹은 코드가 브라우저에서 실제로 실행되어야 비로소 최종 화면이 완성됩니다. 같은 코드라도 화면 크기나 실행 순서에 따라 다르게 그려지기도 하지요. 렌더링 기반 수집(③)이 이 "실제 실행 결과"를 다루기 때문에, URL 분석은 코드 검사만으로는 잡히지 않는 어긋남까지 짚어낼 수 있습니다. 운영 시점 편에서 "가정이 아니라 현실을 본다"고 했던 그 말이, 특허의 언어로는 바로 이 렌더링 기반 수집·측정입니다.

또한 위험도 등급화(④)가 URL 분석에서 특히 값진 이유도 짚어두겠습니다. 운영 사이트는 페이지가 많아 위반이 수백 건씩 나오는데, 그 목록을 그냥 던져주면 담당자는 압도됩니다. "이렇게 많이 잘못돼 있었나" 하는 부담에 아예 손을 못 대기도 하지요. 그런데 같은 목록이라도 위험도로 줄이 세워지고 "이 다섯 개부터"라는 출발점이 생기면, 막막함이 실행으로 바뀝니다. 목록을 만드는 것과 그 목록을 행동으로 번역하는 것은 다른 일이고, 그 번역을 맡는 것이 ④입니다. 그래서 화면을 수집하고(③) 규칙으로 판정한(②) 뒤에, ④가 그 결과를 "행동 가능한 순서"로 바꿔주는 흐름이 URL 분석 안에 담겨 있습니다.

URL 분석에 가장 많은 특허가 걸치는 이유는 분명합니다. 실제 운영 화면이 "화면 수집·기준 판정·우선순위·시점 비교"를 한꺼번에 요구하기 때문입니다. 살아 움직이는 사이트를 통째로 본다는 것은, 그만큼 여러 방법을 동시에 동원해야 한다는 뜻입니다. 그래서 URL 분석은 세 방법 중 가장 종합적이고, 다음 달 심층편의 첫 타자로 삼기에도 가장 알맞습니다. 이 자리에서 네 특허가 실제로 어떻게 맞물려 돌아가는지를 하나씩 뜯어보는 것이, 바로 다음 달의 이야기입니다.

본론 4 — Figma 분석(설계 시점)에 걸치는 특허

다음은 설계 시점, Figma 분석입니다. 아직 코드로 만들기 전, 디자인 도면 단계에서 미리 점검하는 방법이지요. 여기엔 **② 기준 자동 판정(846규칙)**이 중심을 잡습니다.

Figma 분석의 핵심은, 도면의 색·간격·크기·구조가 KRDS 기준에 맞는지를 점검하는 것입니다. 디자인 파일에서 색 토큰과 글자·간격 값을 뽑아 표준 팔레트와 대조하고, 버튼이나 입력창 같은 컴포넌트가 규격대로 설계되었는지, 비활성·오류 같은 상태 설계가 빠지지 않았는지를 봅니다. 이 "기준에 맞나"를 자동으로 대조하는 일이 정확히 ② 기준 자동 판정입니다. 설계 시점에서 이 점검이 값진 이유는 단순합니다. 도면에서 잡으면 싸고, 운영에서 잡으면 비싸기 때문입니다. 만들기 전에 어긋남을 발견하면 도면 한 곳만 고치면 되지만, 다 만든 뒤에 발견하면 코드를 뜯어야 합니다.

그렇다면 나머지 특허들은 어떨까요. 여기서 솔직하게 짚어야 할 부분이 있습니다. 설계 시점에는 ③ 렌더링 기반 화면 수집·측정의 비중이 작습니다. 도면 단계에는 아직 "실제로 브라우저에 그려진 운영 화면"이 없기 때문입니다. 도면은 도면이지, 렌더링된 결과물이 아닙니다. 마찬가지로 운영 데이터가 없으니 다중 페이지의 시점 추세 같은 것도 아직 이르고, 위반 위험도 등급화(④)는 도면에서 나온 표준 이탈 항목에 한해 보조적으로 얹히는 정도입니다. "이 도면의 이 부분이 위험도가 높으니 개발에 넘기기 전에 먼저 처리하세요" 하는 식으로요.

대신 **① 시점 비교(설계·운영 교차 검증)**에서 설계 시점은 아주 중요한 한 축을 맡습니다. 시점 비교는 설계와 운영, 두 시점을 같은 잣대로 견주는 방법인데, 그 "설계 쪽 절반"이 바로 Figma 분석입니다. 도면을 846규칙으로 판정해 둔 결과가 있어야, 나중에 운영 화면과 나란히 놓고 "도면에선 맞았는데 실제로 어디서 어긋났나"를 짚을 수 있습니다. 설계 시점 점검이 없으면 이 교차 검증은 반쪽만 남습니다. 그래서 Figma 분석은 그 자체로도 값지지만, 시점 비교의 절반을 채운다는 점에서 더 값집니다.

여기서 설계 시점만의 값어치를 한 번 더 강조하고 싶습니다. Figma 분석에 걸치는 특허가 URL보다 적다고 해서, 설계 시점이 덜 중요하다는 뜻은 결코 아닙니다. 오히려 반대에 가깝습니다. 같은 어긋남이라도 발견 시점이 빠를수록 고치는 비용이 작아지기 때문입니다. 도면에서 색 토큰 하나가 표준을 벗어난 것을 발견하면 도면에서 값 하나만 바꾸면 되지만, 그 도면이 그대로 코드로 옮겨져 수십 개 화면에 퍼진 뒤에 발견하면 수십 곳을 뜯어고쳐야 합니다. 그래서 걸치는 특허의 수가 아니라 "언제 잡느냐"로 보면, 설계 시점 점검은 가장 값이 큰 자리 중 하나입니다. 표에 표시가 적다고 비중이 작은 것이 아니라, 이 시점의 성격이 "판정 중심"이라 그런 것뿐입니다.

그리고 설계 시점의 판정(②)은 운영 시점의 판정(②)과 같은 846규칙을 쓴다는 점도 짚어둘 만합니다. 도면을 볼 때든 운영 화면을 볼 때든 같은 잣대로 재기 때문에, 나중에 시점 비교(①)에서 두 결과를 나란히 놓고 견줄 수 있습니다. 만약 설계 점검과 운영 점검이 서로 다른 기준을 썼다면, 둘을 비교하는 일 자체가 성립하지 않았을 것입니다. 같은 자를 대야 두 시점의 길이를 견줄 수 있는 법이지요. 그래서 ②라는 하나의 잣대가 설계와 운영 양쪽에 공통으로 걸치는 배치가, 시점 비교(①)를 가능하게 하는 바탕이 됩니다.

정리하면 Figma 분석은 ②를 중심에 두고, ①의 절반을 채우며, ④가 보조로 얹히는 자리입니다. 화면 수집(③)이나 다중 페이지 운영 데이터가 필요한 특허의 비중은 작습니다. 설계 시점이라는 자리의 성격이 그렇습니다. 아직 "실물"이 없는 단계이니, "기준에 맞게 그려졌나"를 보는 판정이 중심일 수밖에 없습니다. 이 설계 시점을 도면 하나하나까지 깊게 파는 이야기는 **7개월차(Figma 분석)**에서 따로 다룹니다. 오늘은 "설계 시점엔 ②가 중심이고, ①의 절반을 여기서 채운다"는 큰 배치만 잡아두시면 됩니다.

전체 준수율·핵심 위험·개선 우선순위가 위에서부터 한 장으로 정리된 종합·임원 보고 요약 화면. 여러 시점과 여러 특허가 만들어낸 결과가 "현황 → 우선 과제 → 기대 효과"의 뼈대로 압축되는 자리 (기관명·도메인 블러)

본론 5 — LLM 분석(판단 시점)에 걸치는 특허

세 번째는 판단 시점, LLM 분석입니다. 규칙으로 다 채우지 못한 빈칸을 메우고, 흩어진 위반을 해석해 우선순위와 개선안으로 잇는 방법이지요. 여기엔 **⑤ 코드·화면 결합 판정(DOM·Vision 융합)**과 ④ 위반 위험도 등급화가 중심으로 걸치고, 개선안이 그 위에 얹힙니다.

**⑤ 코드·화면 결합 판정(DOM·Vision 융합)**이 판단 시점의 핵심 엔진입니다. 이 대목은 지난 판단 시점 편에서 본 "두 엔진" 이야기와 그대로 이어집니다. ViewCheck는 코드로 판정하는 규칙 엔진과, 화면으로 판정하는 화면 엔진, 두 엔진을 함께 씁니다. 규칙 엔진은 코드(DOM)를 읽어 846규칙을 빠르게 판정하지만, 코드만으로는 판단이 어려운 시각적 영역이 남습니다. 이를테면 이미지나 캔버스로 그려진 UI, 표준을 벗어난 방식으로 구현된 컴포넌트 같은 것들이지요. 그 코드로 못 본 빈칸을, 화면 엔진이 실제 화면을 학습된 방식으로 살펴 채웁니다. 코드가 "해당 없음(N/A)"으로 남긴 자리를, 화면 판정이 "있다/없다, 맞다/틀리다"로 메우는 것입니다. 이 "코드와 화면을 결합해 서로의 빈칸을 메우는" 절차가 정확히 ⑤입니다.

여기서 한 가지 원칙을 짚어두겠습니다. 두 엔진은 서로를 뒤집지 않습니다. 코드가 이미 "통과" 또는 "미통과"로 판정한 것을 화면 판정이 함부로 번복하지 않고, 화면 판정은 주로 코드가 비워둔 빈칸(N/A)과 코드가 보지 못하는 시각적 영역을 독자적으로 채웁니다. 이렇게 역할을 나눠두면 두 판정이 충돌하지 않으면서도 서로의 사각지대를 메웁니다. 한 엔진이 놓친 것을 다른 엔진이 잡되, 확실히 판정된 것은 건드리지 않는 것. 이 분업의 규칙이 ⑤ 특허가 지키려는 방법의 핵심입니다.

④ 위반 위험도 등급화도 판단 시점에 걸칩니다. 빈칸을 채워 판정을 마쳤다 해도, 그것만으로는 아직 "무엇이 급한가"를 모릅니다. 채워진 결과 위에서 "그래서 뭐가 제일 급한가"를 가려 줄을 세우는 일, 그것이 판단 시점의 몫입니다. 앞서 URL 분석에서도 ④가 걸친다고 했는데, 그것과 어긋나지 않습니다. URL 분석이 위반을 쏟아내는 자리라면, LLM 분석은 그 위반을 해석해 우선순위로 번역하는 자리입니다. 같은 위험도 등급화가 "결과를 만드는 쪽(URL)"과 "결과를 해석하는 쪽(LLM)" 양쪽에 걸치는 셈이지요.

그리고 그 위에 개선안이 얹힙니다. "이 위반을 이렇게 고치면 됩니다" 하는 개선 방법과 예시 코드를 글로 정리해 주는 것인데, 이것이 판단 시점의 가장 실용적인 산출물입니다. 위반을 찾는 것과 고치는 것 사이에는 생각보다 큰 간극이 있습니다. "이 버튼에 라벨이 없습니다"라는 지적만 받으면 담당자는 "그래서 어떻게 하라는 거지?" 싶지만, "이렇게 라벨을 붙이면 됩니다"라는 구체적 방법이 함께 있으면 그 간극이 확 줄어듭니다. 다만 앞서 말씀드렸듯 이 개선안은 별도의 여섯 번째 특허가 아니라, 다섯 방법이 만들어낸 결과 위에 얹히는 출력으로 다룹니다. 개선안의 원리와 실제 개선 실행 이야기는 **8개월차(LLM 분석)**에서 본격적으로 풀겠습니다.

판단 시점이 왜 필요한지, 조금 더 근본에서 말씀드리겠습니다. 규칙 판정만으로는 "해당 없음(N/A)"이 적지 않게 남습니다. 그 페이지에 그 요소가 아예 없거나, 코드만으로는 있다 없다를 가리기 어려운 경우이지요. 이 빈칸을 그대로 두면 "분석은 돌렸는데 실제로 판정된 것은 얼마 안 되는" 반쪽짜리 결과가 됩니다. 판단 시점이 하는 일이 바로 이 빈칸을 메우는 것입니다. 화면 엔진이 실제 화면을 살펴 "여기 이 컴포넌트가 있고, 이건 기준에 맞다/틀리다"를 채워 넣으면, N/A였던 자리가 실제 판정으로 바뀝니다. 코드로 못 본 것을 화면으로 보는 이 결합(⑤)이 있어야, 분석이 비로소 "충분히 본" 상태에 가까워집니다. 이 N/A를 어떻게 줄이고 채우는지가 **8개월차(LLM 분석)**의 핵심 주제이기도 합니다.

또 하나, 판단 시점은 "사실을 결정으로 번역하는" 자리입니다. 앞의 렌더링 수집과 규칙 판정이 "무엇이 어떻게 됐다"는 사실을 만들어낸다면, 판단 시점은 그 사실을 "그래서 무엇을 할 것인가"로 옮깁니다. 위반이 몇백 건이라는 사실만으로는 아무 결정도 내리기 어렵습니다. 그런데 그 위반을 위험도로 줄 세우고(④), 코드와 화면을 결합해 빈칸까지 메운(⑤) 결과 위에서 "이번 분기엔 이 다섯 개를 이 순서로"라는 결정이 나옵니다. 그래서 판단 시점은 실무자보다 오히려 의사결정자에게 더 요긴한 자리이기도 합니다. 데이터 더미를 결정 가능한 형태로 정리해 주니까요.

아래는 그 판단 시점의 한 결과입니다. 분석 결과를 KRDS 표준과 대조해 "기준 대비 어디가 부족한지"를 정리한 비교 화면이지요. 다섯 특허가 채우고 줄 세운 결과가, 이렇게 "표준 대비"라는 형태로 정리되어 나옵니다. 코드와 화면이 결합해 판정하고(⑤), 위험도로 줄을 세우고(④), 그 위에 개선안이 얹힌 결과가 한 장으로 압축된 모습입니다.

AI 종합보고서의 KRDS 비교분석 화면. 분석 결과를 KRDS 표준과 대조해 "기준 대비 어디가 부족한지"를 정리한, 다섯 특허가 채우고 줄 세운 결과의 종착 화면 (기관명·도메인 블러)

본론 6 — 한 장 매트릭스: 특허 × 방법

지금까지 방법별로 훑은 것을 한 표로 묶으면 이렇습니다. ◎는 핵심으로 걸침, ○는 보조로 걸침, —는 이 시점에선 비중이 작음을 뜻합니다.

특허 방법 영역(출원 중)	URL 분석(운영)	Figma 분석(설계)	LLM 분석(판단)
① 시점 비교(설계·운영 교차)	◎ 운영 쪽 절반	◎ 설계 쪽 절반	○ 결과 대조
② 기준 자동 판정(846규칙)	◎ 준수율 산출	◎ 도면 점검 핵심	○ 판정 근거
③ 렌더링 기반 화면 수집·측정	◎ 화면 수집 토대	—	○ 화면 근거
④ 위반 위험도 등급화·우선순위	◎ 위반 줄세움	○ 도면 위험 표시	◎ 판단·해석
⑤ 코드·화면 결합 판정(DOM·Vision)	◎ 두 판정 결합	—	◎ 빈칸 채움 엔진

이 표를 세로로 읽어보겠습니다. URL 분석 열을 위에서 아래로 훑으면 다섯 중 다섯에 표시가 있습니다. 운영 시점이 가장 종합적인 자리라는 것이 한눈에 드러나지요. 실제 화면을 수집하고(③), 846규칙으로 판정하고(②), 위반을 줄 세우고(④), 코드와 화면을 결합하고(⑤), 나아가 시점 비교의 한 축까지 맡으니(①), 다섯 방법이 이 한 자리에 다 모입니다. Figma 열은 ②를 중심으로 ①·④가 얹히는 좁고 단정한 배치이고, LLM 열은 ⑤·④가 중심을 잡는 판단 특화 배치입니다.

이번엔 가로로 읽어보겠습니다. ① 시점 비교는 URL과 Figma 양쪽에 핵심으로 걸치고 LLM에도 보조로 걸칩니다. 세 방법 모두에 손을 뻗는 셈인데, 당연합니다. "여러 시점을 견준다"는 것이 이 특허의 본질이니 여러 시점에 걸칠 수밖에 없습니다. ② 기준 자동 판정 역시 세 방법 모두에 걸칩니다. 846규칙이라는 잣대는 운영 화면이든 설계 도면이든 판단 근거로든 어디서나 쓰이기 때문입니다. 반면 ③ 렌더링 수집은 URL에 핵심으로 걸리되 Figma엔 걸리지 않습니다. 도면 단계엔 아직 렌더링된 실물이 없으니까요. ⑤ 코드·화면 결합도 URL과 LLM에 걸치되 Figma엔 걸리지 않습니다. 역시 운영 실물이 있어야 성립하는 방법이기 때문입니다.

다섯 행의 특허 자물쇠와 세 열의 방법 기둥이 만나는 격자 매트릭스. 꽉 찬 원과 빈 원 표식으로 핵심 연결과 보조 연결을 구분해 "5 × 3 특허-방법 매핑"을 담은 개념 도식 (Gemini 1:1)

이 매트릭스가 알려주는 것을 한 문장으로 줄이면 이렇습니다. 한 특허가 여러 방법을 받치고, 한 방법이 여러 특허로 받쳐집니다. 그리고 그 겹침에는 규칙이 있습니다. "실물(운영 화면)이 있어야 성립하는 특허(③⑤)"는 운영·판단 시점에 몰리고, "기준과 시점 자체를 다루는 특허(①②)"는 세 방법에 두루 퍼집니다. 이 규칙을 알아두면, 다음 달부터 어떤 방법 이야기를 읽든 "아, 이 방법엔 이런 성격의 특허가 걸리겠구나" 하고 미리 짐작이 됩니다.

이 매트릭스를 다르게 읽는 방법도 하나 있습니다. "실물이 있어야 성립하는 특허"와 "실물 없이도 성립하는 특허"로 나눠 보는 것입니다. 렌더링 수집(③)과 코드·화면 결합(⑤)은 실제로 그려진 운영 화면이 있어야 작동합니다. 그래서 운영·판단 시점에 몰리고, 아직 실물이 없는 설계 시점엔 걸리지 않습니다. 반대로 시점 비교(①)와 기준 판정(②)은 실물이 없어도 성립합니다. 도면이든 화면이든 같은 잣대로 견주고 판정하는 방법이니, 설계·운영·판단 어디에나 퍼질 수 있지요. 위험도 등급화(④)는 그 중간쯤입니다. 위반이 있는 곳이면 어디서든 줄을 세울 수 있으니, 세 시점에 두루 걸치되 위반이 가장 많이 쏟아지는 운영·판단 시점에서 특히 짙게 작동합니다. 이렇게 "실물 의존도"라는 한 축으로 다시 보면, 표의 ◎와 — 가 왜 그 자리에 놓였는지가 한결 또렷해집니다.

한 가지 더 강조하고 싶은 점이 있습니다. 표의 —(비중 작음) 칸을 억지로 채우지 않았다는 것입니다. Figma 열의 ③·⑤ 자리를 "이것도 됩니다" 하고 채워 넣을 수도 있었겠지만, 설계 시점엔 실물이 없어 그 방법의 비중이 실제로 작습니다. 그래서 정직하게 —로 두었습니다. 지도는 있는 그대로 그려야 쓸모가 있습니다. 모든 칸을 ◎로 칠한 화려한 표는 보기엔 그럴듯해도, 정작 "어느 방법에 무엇이 진짜 핵심인가"를 가려주지 못합니다. 빈 칸이 있는 지도가, 꽉 찬 지도보다 정확합니다.

본론 7 — 이 지도가 앞으로의 목차입니다

이 한 장 지도가 왜 중요하냐면, 다음 달부터 펼칠 심층편의 목차이기 때문입니다. 2개월차부터는 이 표의 칸을 하나씩 깊게 팝니다. 오늘은 "어느 특허가 어느 방법에 걸치나"라는 배치도만 그렸다면, 다음 달부터는 그 각 칸이 "실제로 어떻게 작동하나"를 뜯어봅니다.

첫 타자는 URL 분석입니다. 다음 달(2개월차)은 운영 시점의 URL 분석을 깊게 파는 달입니다. 표의 URL 열에 걸친 네 특허 — 렌더링 수집(③), 기준 판정(②), 위험도 등급화(④), 시점 비교(①) — 가 한 번의 분석에서 실제로 어떻게 맞물려 돌아가는지를 단계별로 풀어드립니다. 오늘 "URL 분석이 가장 종합적인 자리"라고만 말씀드린 그 안을, 다음 달에 열어 보여드리는 셈이지요.

그 뒤로는 표의 칸들이 달마다 하나씩 열립니다. 위반 위험도 등급화(④)를 정면으로 다루는 것은 **4개월차(위험도)**입니다. P0부터 P3까지 등급을 어떻게 가르고, 그 등급이 준수율에 어떻게 다르게 반영되는지를 파고듭니다. 846규칙의 네 카테고리(DS·CP·BP·SP) 각각의 성격과 깊은 내용은 **5개월차(4대 카테고리)**에서 하나씩 다룹니다. 여러 페이지를 한꺼번에 집계해 일관성과 추세를 보는 다중 페이지 이야기는 **6개월차(다중 페이지)**입니다. 설계 시점의 Figma 분석은 **7개월차(Figma)**에서, 판단 시점의 LLM 분석과 개선안·빈칸 채움은 **8개월차(LLM)**에서 본격적으로 열립니다.

그러니 오늘 이 지도를 머릿속에 한 장 넣어두면, 앞으로의 글들이 저마다 자리를 잡습니다. 4개월차 글을 읽을 땐 "아, 이게 표의 ④ 이야기구나", 5개월차 글을 읽을 땐 "이게 ② 안쪽 이야기구나", 8개월차 글을 읽을 땐 "이게 ⑤와 ④가 판단 시점에서 하는 일이구나" 하고요. 한 달짜리 오리엔테이션의 목적이 바로 이것이었습니다. 깊이 파기 전에 전체 지도를 먼저 그려, 앞으로 읽을 글들이 길을 잃지 않게 하는 것.

여기서 한 가지 안심하셔도 될 부분을 말씀드리겠습니다. 오늘 지도를 완벽히 외우실 필요는 전혀 없습니다. 지도는 필요할 때 다시 펴 보면 되는 것이지, 통째로 암기하는 것이 아닙니다. 다음 달부터 각 칸을 열 때마다 "이 칸이 지도의 어디에 있었지" 하고 오늘 글을 다시 펼치면 됩니다. 그렇게 심층편을 하나씩 따라가다 보면, 표를 억지로 외우지 않아도 각 칸의 위치가 저절로 몸에 익습니다. 오늘은 "이런 지도가 있다"는 것만 편하게 담아두시면 충분합니다.

본론 8 — 특허를 겸손하게 읽는 법

여기서 한 박자 쉬고, 오늘 그린 지도를 어떻게 받아들이면 좋을지 솔직하게 말씀드리겠습니다. "특허 다섯 개가 세 방법을 다 받친다니 대단하다"는 인상만 남는다면, 그건 오늘 글을 절반만 읽으신 것입니다.

먼저 정확한 표기부터 다시 하겠습니다. 다섯 건은 모두 출원 중입니다. 등록특허가 아니라 출원 기술입니다. 출원과 등록은 다릅니다. 출원은 "이런 방법으로 권리를 정리하겠다고 접수한 단계"이고, 등록은 심사를 거쳐 권리가 확정된 단계입니다. ViewCheck는 현재 출원 단계이므로, "등록특허"라고 부풀리지 않고 "출원 기술"이라고 정확히 적습니다. 마케팅에서 이런 표기 하나가 별것 아닌 듯 보여도, 정확하지 않으면 그 순간부터 나머지 이야기 전체의 신뢰가 흔들립니다. 그래서 이 부분은 매번 정확하게 적어두려 합니다.

다음으로, 더 중요한 이야기입니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 오늘 그린 지도가 아무리 그럴듯해 보여도, 결과의 품질은 각 칸의 방법이 실제로 얼마나 잘 작동하느냐로 결정되는 것이지, 특허가 있다는 사실 자체로 보장되는 것이 아닙니다. 렌더링 수집이 실제로 운영 화면을 정확히 재는가, 846규칙 판정이 실제로 맞게 판정하는가, 위험도 등급이 실제로 현실적인 우선순위를 내는가, 두 엔진이 실제로 서로의 빈칸을 잘 메우는가 — 이 "실제로"들이 품질을 만듭니다. 그리고 그 "실제로"는 다음 달부터의 심층편에서 하나씩 보여드릴 몫입니다.

그래서 오늘 지도를 받아들이는 올바른 자세는 "특허 다섯으로 다 받친다니 믿을 만하다"가 아니라, "이 방법들을 직접 만들어 권리로 지켜두었고, 이제 하나씩 그 작동을 보여주겠다" 정도입니다. 특허는 우리가 이 방법을 남보다 먼저, 직접 설계해 정리했다는 증거일 뿐입니다. 그 방법이 실전에서 얼마나 잘 도는지는, 직접 넣어보시고 결과를 확인하시는 것이 가장 빠릅니다. 특허를 근거로 "믿어 달라"고 말하는 대신, 방법의 작동을 결과로 보여드리겠다는 것 — 이것이 이 시리즈 내내 지키려는 태도입니다.

이 태도가 왜 중요한지, 반대 경우를 상상해 보면 분명해집니다. 만약 "특허가 다섯 개나 있으니 결과는 무조건 정확합니다"라고 말한다면, 그건 특허의 성격을 오해하게 만드는 과장입니다. 특허는 방법이 새롭고 구분된다는 것을 인정받으려는 절차이지, 그 방법이 매번 옳은 답을 낸다는 보증이 아닙니다. 세상의 어떤 자동 분석도 100% 완벽하지 않고, ViewCheck도 예외가 아닙니다. 그래서 저희는 결과에 확신의 등급을 두고, 코드로 확실히 판정된 것과 화면으로 보조 판정한 것을 구분하며, 판단이 어려운 자리는 "해당 없음"으로 정직하게 비워둡니다. 완벽하다고 우기는 대신, 어디까지 확실하고 어디부터 불확실한지를 함께 보여드리는 것 — 그것이 특허보다 오히려 더 신뢰를 만드는 태도라고 믿습니다. 다음 달부터의 심층편도 그 정직함의 연장선에서, 각 방법이 어디까지 해내고 어디서 한계가 있는지를 숨기지 않고 보여드리겠습니다.

한 가지 덧붙이면, 특허를 다섯 개로 나눠 낸 것 자체에도 이런 정직함이 배어 있습니다. 하나의 거대한 "만능 특허"로 뭉뚱그리지 않고, 시점 비교·기준 판정·화면 수집·위험도 등급화·코드화면 결합이라는 다섯 개의 독립된 방법 단위로 나눈 것은, 각 방법이 실제로 구분되는 기술이기 때문입니다. 그리고 그렇게 나눠두었기에 오늘처럼 "어느 방법이 어느 시점에 걸치나"를 한 장 지도로 그릴 수 있었습니다. 뭉뚱그린 하나였다면 이런 지도는 애초에 그려지지 않았을 것입니다. 나눠 낸 것이 곧 정직하게 지도를 그릴 수 있는 바탕이 된 셈입니다.

그래서 ViewCheck는

ViewCheck는 세 방법(URL·Figma·LLM)을 한 도구에 모았고, 그 방법을 다섯 건의 특허(출원 중)로 받칩니다. 운영 시점의 URL 분석엔 렌더링 수집(③)·기준 판정(②)·위험도 등급화(④)·시점 비교(①)가, 설계 시점의 Figma 분석엔 기준 판정(②)이 중심으로 걸치며 시점 비교(①)의 절반을 채웁니다. 판단 시점의 LLM 분석엔 코드·화면 결합(⑤)과 위험도 등급화(④)가 걸치고, 그 위에 개선안이 얹힙니다. 이 매핑이 이 도구의 뼈대 지도입니다.

거창하게 들릴 수 있지만, 결국 한 달 동안 본 모든 것이 이 한 장으로 모입니다. 세 시점(설계·운영·판단), 세 방법(URL·Figma·LLM), 다섯 특허(시점 비교·기준 판정·화면 수집·위험도 등급화·코드화면 결합), 그리고 846규칙이 집계된 하나의 결과 화면. 흩어져 보였던 조각들이 서로 어떻게 맞물리는지, 오늘 지도로 한 번 이어드렸습니다. krds.viewcheck.co.kr에서 분석을 한 번 돌려보시면, 오늘 지도의 각 칸이 실제 결과 화면의 어디에 대응하는지가 눈에 들어오실 겁니다.

그리고 솔직히, 오늘 이야기한 지도는 어떤 특정 도구의 자랑이라기보다, "웹 품질을 제대로 보려면 이 방법들이 필요하다"는 일반적인 뼈대에 가깝습니다. 설계에서 미리 잡고, 운영에서 현실을 확인하고, 판단에서 결론을 내리는 것. 그 각 단계를 같은 기준으로 자동화하는 것. 이 골격은 도구가 달라도 통합니다. ViewCheck는 그 골격을 하나의 도구에 모아 담고, 각 방법을 직접 만들어 권리로 지켜둔 것뿐입니다. 그게 실제로 맞는지는, 다음 달부터의 심층편과 직접 넣어보시는 경험이 답해 드릴 것입니다.

🔐 특허로 지키는 부분

오늘 그린 지도 자체가 다섯 특허의 배치도입니다. ① 시점 비교(설계·운영 교차 검증) ② 기준 자동 판정(846규칙) ③ 렌더링 기반 화면 수집·측정 ④ 위반 위험도 등급화 및 개선 우선순위 산정 ⑤ 코드·화면 결합 판정(DOM·Vision 융합) — 이 다섯 방법이 세 방법(URL·Figma·LLM)에 걸쳐 작동합니다. 한 특허가 여러 방법을 받치고, 한 방법이 여러 특허로 받쳐지는 이 유연한 배치가, "기능"이 아니라 "방법"을 권리로 정리한 결과입니다. 다섯으로 나눠 낸 덕분에 각 방법을 여러 시점에 자유롭게 걸칠 수 있었고, 그 덕에 오늘 같은 한 장 지도를 정직하게 그릴 수 있었습니다.

다만 솔직히 짚어둘 것이 있습니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 이 지도가 그럴듯해 보여도, 결과의 품질은 각 칸의 방법이 실제로 잘 작동하느냐로 결정되는 것이고, 그건 다음 달부터의 심층편에서 하나씩 보여드릴 몫입니다. 그래서 "특허 다섯 개로 다 받친다니 대단하다"가 아니라 "이 방법들을 직접 만들고 지켜두었으니, 이제 하나씩 그 작동을 보여드리겠다" 정도로 받아들여 주시면 됩니다. 그리고 현재는 출원 중입니다. 등록특허가 아니라 출원 기술로 정확히 표기합니다. (특허 출원 기술 / 자체 개발)

마무리

오늘로 1개월차 오리엔테이션을 마칩니다. 한 달 동안 세 시점(설계·운영·판단), 세 방법(URL·Figma·LLM), 다섯 특허(시점 비교·기준 판정·화면 수집·위험도 등급화·코드화면 결합)를 봤고, 오늘 그것을 한 장 매트릭스로 묶었습니다. 다섯 특허가 세 방법에 걸치고, 세 방법이 846규칙의 하나의 결과로 모입니다. 이 지도가 앞으로의 목차입니다.

돌아보면 한 달이라는 시간이, 흩어진 개념들을 하나씩 놓고 마지막에 이어 붙이기에 꼭 알맞았습니다. 첫 주에 큰 틀을 세우지 않고 곧장 세부로 들어갔다면, 아마 지금쯤 "그래서 이게 다 무슨 관계였지" 하고 길을 잃으셨을지도 모릅니다. 세 시점을 세우고, 세 방법을 하나씩 보고, 다섯 특허를 짚은 뒤에야 오늘의 지도가 의미를 갖는 것처럼, 이해에는 순서가 있습니다. 그 순서를 지켜 한 달을 걸어온 셈입니다.

한 달을 한 줄로 줄이면 이렇습니다. 사람 손만으로는 웹 품질을 다 따라잡기 어렵다는 데서 출발해, 웹을 보는 세 시점을 세우고, 그 시점을 URL·Figma·LLM 세 방법으로 풀었으며, 그 방법을 다섯 특허로 받친다는 것을 확인하고, 오늘 그 전부를 한 장 지도로 이었습니다. 조각으로 흩어져 보였던 것들이, 실은 하나의 그림이었다는 것을 마지막에 보여드린 셈입니다.

다음 달(2개월차)부터는 이 지도의 칸을 하나씩 깊게 팝니다. 첫 타자는 URL 분석입니다. 실제 운영 사이트를 주소만으로 통째로 점검하는 그 방법을, 표의 렌더링 수집·기준 판정·위험도 등급화·시점 비교가 한 번의 분석에서 어떻게 맞물려 돌아가는지로 풀어가겠습니다. 오늘 스무 개가 넘는 분석 영역과 846규칙, 다섯 특허를 한 장에 모아 두었으니, 다음 달엔 그중 URL이라는 칸 하나를 열어 안을 들여다보는 셈입니다. 숲을 봤으니, 이제 나무 하나하나로 들어갑니다.

혹시 이번 달 글을 중간부터 읽으셨더라도 괜찮습니다. 오늘 지도 한 장이면 그동안의 조각들이 어디에 놓이는지 대강 잡히실 테고, 궁금한 칸이 있으면 해당 달의 심층편에서 다시 만나면 되니까요. 오리엔테이션은 시작을 위한 준비이지, 끝이 아닙니다. 오히려 오늘부터가 본론의 문 앞입니다.

오리엔테이션을 끝까지 함께 읽어 주셔서 고맙습니다. 오늘 딱 하나만 가져가신다면, "다섯 특허가 세 방법에 걸치고, 세 방법이 하나의 결과로 모인다"는 이 한 문장이면 좋겠습니다. 이 문장만 손에 쥐고 계시면, 다음 달부터의 심층편이 저마다 제자리를 찾아 들어옵니다. 나머지 세부는 그때그때 필요한 만큼만 열어 보시면 충분합니다. 지도를 한 번 그려두었으니, 이제 함께 그 길을 하나씩 걸어가면 됩니다. 다음 달, 심층편에서 다시 뵙겠습니다.

krds.viewcheck.co.kr