기능이 아니라 방법을 지킨다 — ViewCheck가 특허를 5개 낸 이유

들어가며 — 특허 자랑이 아니라, "왜 하필 다섯 개"

이번 주는 1개월차, 그러니까 오리엔테이션 성격으로 큰 그림을 그려 온 첫 달의 마지막 주입니다. 이 달을 되짚어 보면 이렇습니다. 첫 주에 웹 품질을 보는 세 가지 시점 — 만들기 전(설계), 만든 후(운영), 그 위에서(판단) — 을 깔았고, 그다음 주부터 그 세 시점을 하나씩 풀었습니다. 운영 시점은 URL 분석으로, 설계 시점은 Figma 분석으로, 그리고 지난주에는 그 결과를 판단으로 잇는 LLM 분석과, 그 뒤에서 돌아가는 두 개의 분석 엔진 이야기까지 드렸습니다. 이번 주는 그 세 시점을 밑에서 떠받치고 있는 다섯 개의 특허를 한자리에 모아 소개하는 주간입니다. 오늘 월요일은 "왜 하필 다섯 개인가", 수요일은 "기능은 베껴도 방법은 못 베낀다", 그리고 금요일은 "다섯 개 특허가 세 개 방법에 어떻게 걸치는지"를 한 장의 지도로 정리하는 순서입니다.

먼저 오해부터 걷어내고 시작하겠습니다. 이 글은 특허 자랑이 아닙니다. "우리 특허 다섯 개 있으니 대단하죠"라는 이야기를 하려는 게 아닙니다. 그런 자랑은 사실 읽는 분께 아무 쓸모가 없습니다. 오늘 정말로 드리고 싶은 이야기는 두 가지입니다. 하나는 "왜 하필 하나가 아니라 다섯 개로 나눠서 냈는가"이고, 다른 하나는 "그게 이 도구를 쓰는 분께 실제로 무슨 의미가 있는가"입니다. 이 두 질문에 정직하게 답하는 게 오늘 글의 전부입니다.

그리고 한 가지 전제를 분명히 못 박아 두겠습니다. 지금 말씀드리는 다섯 건은 전부 출원 중인 기술입니다. "등록특허"가 아니라 "출원 기술"입니다. 이 구분을 흐리지 않고 오늘 글 내내 그대로 유지하겠습니다. 특허라는 말이 주는 무게 때문에 은근슬쩍 "등록된 것처럼" 들리게 쓰는 경우가 있는데, 그건 정직하지 않습니다. 출원은 출원이라고, 있는 그대로 적겠습니다.

ViewCheck는 결국 이 달 내내 본 세 가지 분석 방법 — URL 분석·Figma 분석·LLM 분석 — 이 한 도구 안에 모인 것입니다. 아래는 그 세 방법이 합쳐져 한 화면에서 846규칙 결과를 집계해 보여주는 모습입니다. 겉으로 보이는 건 결과 화면 한 장이지만, 그 뒤에는 세 개의 방법과 다섯 개의 핵심 기술이 깔려 있다는 걸 떠올리면서 보시면 좋겠습니다. 화면은 단순한데, 그 단순함을 만들기 위해 뒤에서 도는 것들이 결코 단순하지 않다는 게 오늘의 주제이기도 합니다.

ViewCheck가 846규칙 전체를 한 화면에 집계해 보여주는 종합 결과 화면. 상단 점수 카드와 그 아래 영역별 결과가 함께 보이는 넓은 상단 뷰. 겉으로는 결과 화면 하나지만 그 뒤에 세 방법과 다섯 핵심 기술이 깔려 있다는 걸 보여주는 자리 (게재 시 기관명·도메인 블러)

특허라는 주제를 꺼내면 대개 두 가지 반응이 나옵니다. 하나는 "특허 있으면 대단한 거 아니냐"는 막연한 신뢰이고, 다른 하나는 "요즘 특허 없는 데가 어디 있냐"는 시큰둥함입니다. 저희는 이 두 반응 모두와 조금 거리를 두고 싶습니다. 특허가 있다고 결과가 저절로 좋아지는 것도 아니고, 그렇다고 특허가 아무 의미 없는 장식인 것도 아니니까요. 오늘 하고 싶은 이야기는 그 사이 어딘가에 있습니다. "왜 이 방법을 굳이 다섯 개로 나눠서 권리로 정리했는가, 그 나눔이 무엇을 말해 주는가." 특허의 개수 자체가 자랑거리라는 게 아니라, 그 개수가 나온 이유 안에 ViewCheck가 웹 분석을 바라보는 관점이 담겨 있다는 이야기입니다.

오늘은 이 다섯 개가 각각 무엇인지 한 줄씩 소개하고, "왜 다섯 개로 쪼갰는지", 그게 왜 의미가 있는지를 풀어 보겠습니다. 깊은 기술 설명은 다음 달부터 영역별로 따로 파겠습니다. 이번 달은 개요를 도는 달이니, 오늘도 큰 그림만 잡고 가시면 충분합니다. 참고로 각 특허가 어느 방법에 정확히 걸치는지를 1:1로 대응시키는 지도는 이번 주 금요일 편에서 그립니다. 오늘은 그 지도를 그리기 전에, "애초에 왜 여러 개로 나뉘어 있는가"라는 밑그림에 집중하겠습니다.

본론 1 — 기능은 흉내 낼 수 있습니다 (메뉴판과 레시피)

비유 하나로 시작하겠습니다. 식당 메뉴판을 떠올려 보십시오. "김치찌개, 된장찌개, 제육볶음"이라고 적힌 메뉴판은 누구나 똑같이 베낄 수 있습니다. 옆 가게가 그 메뉴 이름을 그대로 따라 적는 건 일도 아닙니다. 사진을 찍어서 그대로 인쇄해도 되고, 손으로 옮겨 적어도 됩니다. 메뉴 이름 자체에는 지켜야 할 비밀이랄 게 없으니까요.

그런데 그 김치찌개를 똑같은 맛으로 끓여 내는 레시피는 어떨까요. 그건 베끼기가 어렵습니다. 같은 재료를 똑같이 줘도, 불 조절을 어떻게 하는지, 어느 순서로 넣는지, 얼마나 끓이는지에 따라 맛이 완전히 달라집니다. 메뉴판은 종이 한 장으로 복제되지만, 레시피는 만드는 사람의 손끝에 붙어 있어서 그렇게 쉽게 옮겨지지 않습니다. 그래서 정말 지킬 가치가 있는 건 메뉴판이 아니라 레시피입니다.

여기서 잠깐, 왜 메뉴판은 지킬 수 없고 레시피는 지킬 수 있는지 그 성격의 차이를 짚어 두겠습니다. 메뉴판은 "무엇을 파는가"의 목록입니다. 겉으로 드러나 있고, 그래서 누구나 볼 수 있고, 볼 수 있으니 옮겨 적을 수 있습니다. 반면 레시피는 "그것을 어떻게 만드는가"의 절차입니다. 겉으로 드러나지 않고, 여러 번의 시행착오 끝에 다듬어지며, 그 안에 만든 사람의 판단이 촘촘히 박혀 있습니다. 드러나 있는 것은 지킬 수 없고, 드러나지 않은 절차라야 지킬 가치가 생깁니다. 특허라는 제도 자체가 바로 이 "드러나지 않은 절차"를 대상으로 합니다. 겉모습이 아니라 만드는 방법을, 그것도 새롭고 스스로 만든 방법을 정리해서 권리로 인정받는 것이니까요.

소프트웨어도 정확히 똑같습니다. "접근성 검사 기능, AI 분석 기능, 리포트 기능"이라고 적힌 기능 목록은 누구나 따라 적을 수 있습니다. 화면에 버튼 하나를 만들고 그 위에 "AI 분석"이라고 이름을 붙이는 건 전혀 어렵지 않습니다. 소개 페이지에 "우리도 접근성 봅니다, 성능도 봅니다, 리포트도 나옵니다"라고 나열하는 것도 마찬가지로 쉽습니다. 그 목록은 메뉴판이니까요.

문제는 그 기능을 "어떻게 만드느냐"입니다. 여기서부터가 레시피의 영역입니다. 같은 "AI 분석"이라는 이름을 달고 있어도, 코드만 보고 판정하는지 화면까지 함께 보는지, 판단할 수 없는 빈칸(N/A)을 어떻게 처리하는지, 같은 사이트를 두 번 돌렸을 때 같은 결과가 나오는지는 만드는 방법에 따라 하늘과 땅 차이입니다. 이름은 같은데 속은 전혀 다른 것이죠. 손님에게는 똑같이 "김치찌개"라고 나가지만, 한 그릇은 정성껏 우린 육수로 끓였고 다른 한 그릇은 물에 양념만 풀었을 수 있습니다.

이 달 내내 우리가 본 게 바로 이 차이입니다. "846규칙 자동 판정"이라고 똑같이 말해도, 어떤 도구는 코드만 훑어보고 절반 가까이를 "판단 불가"로 흘려보냅니다. 반대로 화면까지 그려서 그 빈칸을 채우는 도구는 판정할 수 있는 항목이 훨씬 많아집니다. "위반 목록을 준다"고 똑같이 말해도, 어떤 도구는 목록만 길게 뱉어 놓고 끝냅니다. 수백 건이 주르륵 나오는데 그중 무엇부터 손대야 할지는 알려 주지 않죠. 반면 어떤 도구는 그 수백 건에 우선순위를 매기고, 어느 페이지의 어느 자리가 왜 문제인지, 어떻게 고치면 되는지까지 붙여 줍니다. 기능 이름은 똑같은데 방법이 다르고, 그 방법의 차이가 곧 결과의 차이를 만듭니다.

그래서 ViewCheck가 지키려고 한 것은 "기능"이 아니라 "방법"입니다. 버튼의 모양이나 화면의 배치, 메뉴의 구성 같은 건 누가 봐도 베낄 수 있습니다. 그건 메뉴판이니까요. 하지만 "코드와 화면을 충돌 없이 겹쳐 보는 방법", "판단 불가능한 빈칸을 확신도로 걸러 채우는 방법", "수백 건의 위반을 흔들리지 않는 기준으로 줄 세우는 방법" 같은 것은, 그 자체가 만들기 어려운 레시피입니다. 오래 다듬어야 나오고, 한 번 만들어 놓으면 그 안에 노하우가 응축되어 있습니다. 이걸 권리로 정리해 둔 것이 특허입니다. 다시 말해, 특허로 지킨 건 "무엇을 보여 주는가(기능)"가 아니라 "그것을 어떻게 만들어 내는가(방법)"입니다.

이 차이를 조금 더 손에 잡히게 그려 보겠습니다. 어느 담당자분이 두 개의 도구로 같은 사이트를 돌렸다고 해보죠. A 도구는 "위반 12건"이라고 나오고, B 도구는 "위반 180건"이라고 나옵니다. 얼핏 보면 A 도구가 더 좋은 사이트로 판정한 것 같지만, 실은 그 반대일 수 있습니다. A 도구는 코드만 훑고 애매한 건 다 "판단 불가"로 넘겨 버려서 12건밖에 못 본 것이고, B 도구는 화면까지 그려서 코드로는 안 보이던 문제까지 180건을 잡아낸 것일 수 있으니까요. 같은 사이트인데 결과가 열다섯 배 차이 나는 이유는, 사이트가 달라서가 아니라 "보는 방법"이 달라서입니다. 그리고 담당자에게 정말 필요한 건 "덜 본 12건"이 아니라 "제대로 본 180건"입니다. 문제를 못 본다고 문제가 없어지는 게 아니니까요. 방법의 차이가 이렇게 결과의 신뢰도를 통째로 가릅니다.

한 가지 더 짚고 싶은 게 있습니다. 방법을 지킨다는 건 단순히 "남이 못 베끼게 막는다"는 방어적인 의미만 있는 게 아닙니다. 방법을 명확히 정리해 두면, 만드는 쪽에서도 그 방법을 흔들림 없이 반복할 수 있습니다. "지난번엔 이렇게 판정했는데 이번엔 저렇게 나오네" 하는 일이 줄어듭니다. 레시피가 종이에 적혀 있으면 오늘 끓인 찌개와 내일 끓인 찌개의 맛이 같아지듯이, 방법이 정리되어 있으면 결과의 일관성이 올라갑니다. 특허를 낸다는 것은 그 방법을 "말로 설명할 수 있을 만큼 또렷하게 정리했다"는 뜻이기도 합니다. 머릿속에만 있던 감을 문서로 꺼내 놓는 과정에서, 방법 자체가 더 단단해집니다.

본론 2 — 그럼 왜 하나가 아니라 다섯 개인가

방법을 지킨다는 건 알겠는데, 그럼 왜 하필 다섯 개일까요. 하나로 뭉뚱그려서 "웹 분석 방법"이라고 크게 한 건 낼 수도 있었을 텐데 말입니다. 답은 이렇습니다. ViewCheck의 분석이 애초에 다섯 개의, 서로 겹치지 않는 핵심 기술 단위로 나뉘어 있기 때문입니다.

집에 자물쇠를 단다고 생각해 보겠습니다. 현관문 하나만 잠가 놓고 "우리 집 보안 완벽합니다"라고 하기는 어렵습니다. 창문이 열려 있으면 현관을 아무리 튼튼하게 잠가도 소용이 없으니까요. 그래서 현관, 창문, 뒷문, 그리고 정말 중요한 물건을 넣어 둔 금고처럼, 지켜야 할 자리마다 하나씩 자물쇠를 답니다. 자리의 성격이 다르니 자물쇠도 따로입니다. 특허도 비슷합니다. 분석 방법에는 성격이 다른 핵심 자리가 여럿 있고, 그 자리마다 하나씩 정리하다 보니 다섯 개가 된 것입니다. 한 덩어리로 뭉뚱그리지 않은 이유는, 각 기술이 저마다 독립적으로 의미가 있어서입니다. 하나를 빼도 나머지가 각자의 역할을 하고, 하나를 떼어 놓고 봐도 그 자체로 완결된 방법입니다.

아래 이미지는 그 다섯 개의 핵심 기술이 세 개의 방법 기둥을 어떻게 떠받치는지를 자물쇠로 표현한 개념 도식입니다. 자물쇠가 다섯 개인 이유가, 지켜야 할 자리가 다섯 군데라서라는 걸 그림으로 보시면 감이 더 잡히실 겁니다.

세 개의 방법 기둥(설계·운영·판단) 둘레에 다섯 개의 서로 다른 자물쇠가 배치되어, 각 자물쇠가 하나의 독립된 핵심 기술 단위를 지키는 모습. 다섯 개의 독립된 기술 단위가 세 개의 방법을 지킨다는 구조를 담은 개념 도식 (Gemini 1:1)

다섯 건을 한 줄씩 소개하면 이렇습니다. 모두 출원 중인 기술이고, 깊은 설명은 다음 달부터 영역별로 따로 하겠습니다. 오늘은 "이런 자리들이 있어서 다섯 개로 나뉘었다"는 정도만 잡으시면 됩니다. 그리고 미리 말씀드리면, 아래 다섯 가지는 서로 완전히 동떨어진 기술이 아니라, 하나의 분석이 흐르는 동안 순서대로 맞물려 도는 단계들이기도 합니다. 그래서 각각을 읽으실 때 "이게 앞의 것과 어떻게 이어지나"를 함께 떠올리시면, 왜 다섯이 한 도구 안에 모여야 하는지가 더 선명해집니다.

① 시점 비교 — 설계와 운영을 교차로 맞춰 보는 방법

첫 번째 자리는 "시점을 교차해서 보는 방법"입니다. 이 달 내내 강조한 세 시점 — 설계·운영·판단 — 을 기억하실 겁니다. 설계 시점(디자인 파일)에서 본 결과와 운영 시점(실제 사이트)에서 본 결과는 종종 어긋납니다. "디자인은 통과였는데 배포본은 위반"인 그 간극 말입니다. 이 두 시점을 나란히 놓고 "어디서 어긋났는지"를 맞춰 보는 방법이 여기에 해당합니다. 한 시점만 봐서는 절대 안 보이는 문제가, 두 시점을 겹쳐 봐야 비로소 드러납니다. 도면과 실물을 대조하는 감리와 비슷한 일을, 웹에서 자동으로 하는 것이죠.

② 기준 자동 판정 — 846규칙을 화면에 대조하는 방법

두 번째 자리는 "정해진 기준에 자동으로 대조하는 방법"입니다. KRDS의 846규칙 — 색·타이포·간격 같은 디자인 스타일(DS) 120개, 버튼·폼·표 같은 컴포넌트(CP) 446개, 폼 구조·오류 처리 같은 기본 패턴(BP) 108개, 검색·로그인 같은 서비스 패턴(SP) 172개 — 을 화면의 실제 요소와 하나하나 맞춰 보고 통과·미통과·해당 없음으로 판정하는 방법입니다. 846개를 사람이 손으로 일일이 대조하는 건 현실적으로 불가능에 가깝습니다. 그걸 자동으로, 그것도 일관된 기준으로 해내는 절차가 여기입니다. "기준이 있다"와 "그 기준을 자동으로 적용한다"는 완전히 다른 일입니다. 규칙집을 갖고 있는 것과, 그 규칙집을 실제 화면에 정확히 적용하는 것은 별개의 기술이니까요.

③ 렌더링 기반 화면 수집·측정 — 실제 화면을 그려서 재는 방법

세 번째 자리는 "실제 사용자가 보는 화면을 그대로 그려 내서, 그 위에서 재는 방법"입니다. 요즘 웹사이트는 코드만 받아와서는 화면이 그려지지 않습니다. 자바스크립트가 돌고 이미지가 붙고 스타일이 적용되어야 사용자가 보는 그 화면이 나옵니다. 그래서 진짜 브라우저처럼 페이지를 끝까지 그려 낸 뒤, 그 위에서 색 대비·간격·크기 같은 걸 픽셀 단위로 재야 합니다. 이건 운영 시점(URL 분석)의 핵심이자, 성능·보안 같은 영역이 성립하는 토대이기도 합니다. "대충 캡처했다"와 "사용자가 보는 그대로 끝까지 그려 냈다"는 결과물이 완전히 다르고, 후자를 안정적으로 해내는 것 자체가 만만한 일이 아닙니다. 어떤 사이트는 보안 장비가 자동 접근을 막고, 어떤 사이트는 무한 스크롤로 콘텐츠가 계속 붙습니다. 이런 변수를 하나씩 넘어서 "진짜 화면"에 도달하는 절차가 이 자리에 정리되어 있습니다.

④ 위반 위험도 등급화 및 개선 우선순위 산정 — 수백 건을 줄 세우는 방법

네 번째 자리는 "찾은 위반들을 위험도에 따라 등급으로 나누고, 무엇부터 고칠지 우선순위를 매기는 방법"입니다. 분석을 돌리면 위반이 수백 건씩 나옵니다. 그걸 그냥 목록으로 던지면 받아 든 사람은 막막합니다. "이걸 다 언제 고치나" 싶은 것이죠. 그래서 치명도(얼마나 심각한 문제인가), 빈도(얼마나 여러 곳에서 반복되는가), 위치(사용자가 자주 마주치는 자리인가)를 종합해서 P0부터 P3까지 등급을 매기고, "이것부터"라는 출발점을 만들어 줍니다. "다 고쳐야 한다"는 막막함을 "여기부터 시작하면 된다"로 바꾸는 방법입니다. 한정된 예산과 인력으로 움직여야 하는 공공 현장에서는 이 줄 세우기가 특히 값집니다. 순서만 잘 잡아도 같은 노력으로 훨씬 큰 개선이 나오니까요.

⑤ 코드·화면 결합 판정 — 두 정보를 겹쳐서 판단하는 방법

다섯 번째 자리는 "코드가 말하는 것과 화면이 보여 주는 것을 겹쳐서 판단하는 방법"입니다. 코드만 보면 이미지 위에 얹힌 가짜 버튼을 진짜 버튼으로 착각하고, 화면만 보면 그 버튼에 이름(라벨)이 없다는 걸 놓칩니다. 두 정보를 나란히 놓고 대조해야 "화면엔 버튼처럼 보이는데 코드엔 이름이 없다"는 결론에 도달합니다. 코드를 읽는 눈과 화면을 보는 눈을 동시에 굴리는 일인데, 이걸 사람 한 명이 하기는 어렵습니다. 이 결합 판정이 있어야 코드로는 안 보이는 비표준 UI, 화면으로는 확인 안 되는 구조 속성을 함께 잡아냅니다. ViewCheck의 뒤에서 두 개의 엔진 — 코드를 읽는 규칙 엔진과 화면을 보는 시각 엔진 — 이 도는 이유가 바로 이 자리에 있습니다.

이렇게 다섯 개로 나눠 놓고 보면, 각각이 "겹치지 않는 독립된 기술 단위"라는 게 또렷하게 보입니다. ①은 시점을 맞추는 쪽, ②는 기준에 대조하는 쪽, ③은 실제 화면을 그려 재는 쪽, ④는 결과를 줄 세우는 쪽, ⑤는 코드와 화면을 겹치는 쪽입니다. 하는 일이 저마다 다릅니다. 한 덩어리로 묶기에는 성격이 너무 다르고, 그렇게 묶으면 오히려 각 방법의 고유함이 흐려집니다. 그래서 다섯 개입니다. 자물쇠를 다섯 개 단 이유가, 지켜야 할 자리가 다섯 군데라서인 것과 똑같습니다.

아래는 그 핵심 기술들이 실제로 작동하는 한 장면입니다. 규칙으로 1차 판정을 내린 위에, 화면을 인식하는 시각 분석이 얹혀서 규칙만으로는 판단하지 못한 항목을 보강하는 모습입니다. 다섯 방법 중 "기준 자동 판정"과 "코드·화면 결합 판정"이 함께 도는 장면이라고 보시면 됩니다.

ViewCheck KRDS 규칙검증 화면에서 AI 품질분석을 실행해, 규칙만으로 판정하지 못한 항목에 화면 인식 기반 보강이 더해진 모습. 코드 기반 규칙 판정 위에 화면 기반 시각 분석이 얹히는 한 장면 (게재 시 기관명·도메인 블러)

본론 3 — 그래서 이걸 쓰는 분께는 무슨 의미인가

특허가 다섯 개 있다는 게, 이 도구를 실제로 쓰는 분께는 무슨 의미일까요. 과장 없이 딱 세 가지만 말씀드리겠습니다. 그리고 그 세 가지 끝에, 반드시 함께 짚어야 할 솔직한 단서도 붙이겠습니다.

① 진짜 자기 기술이라는 뜻입니다

특허를 내려면 "이게 새롭고, 남이 하던 방식과 다르며, 직접 만든 방법"임을 문서로 정리해서 출원해야 합니다. 남의 걸 가져다 이름만 바꿔 단 것이라면 애초에 출원 대상이 되지 않습니다. 심사 과정에서 "이미 있던 것"이라는 게 드러나면 권리로 인정받지 못하니까요. 그러니 다섯 건을 출원했다는 사실은, 적어도 그 다섯 개 방법은 빌려온 게 아니라 직접 설계하고 만들었다는 뜻입니다. 남의 서비스 위에 껍데기만 씌운 게 아니라, 분석의 핵심 절차를 스스로 만들었다는 것이죠. 도구를 고를 때 "이 회사가 정말 자기 기술을 가진 곳인가, 아니면 남의 것을 조립해 파는 곳인가"는 꽤 중요한 질문인데, 출원 이력은 그 질문에 대한 하나의 답이 됩니다.

② 쉽게 사라지지 않는다는 뜻입니다

직접 만든 핵심 기술이라면, 어느 날 갑자기 "그 기능 이제 못 씁니다"가 되기 어렵습니다. 남의 외부 서비스에 얹혀 있는 기능은 그쪽이 정책을 바꾸거나 가격을 올리거나 문을 닫으면 함께 흔들립니다. 어제까지 잘 쓰던 기능이 오늘 갑자기 막히는 일이 실제로 종종 벌어지죠. 반면 자기 방법으로 만든 기능은 그런 외부 변수에 덜 휘둘립니다. 오래 쓸 도구를 고를 때는 "이게 3년 뒤에도 그대로 있을까"가 은근히 중요한데, 핵심을 직접 만들어 두었다는 건 그 지속 가능성에 대한 하나의 근거가 됩니다. 특히 공공 분야처럼 한 번 도입하면 오래 쓰는 환경에서는 이 안정성이 더 크게 다가옵니다.

③ 차별화가 유지된다는 뜻입니다

레시피를 권리로 지켜 두면, 옆에서 똑같이 따라 만들기가 어려워집니다. 메뉴판은 베껴도 그 뒤의 레시피는 함부로 못 베끼니까요. 이 말은 곧, ViewCheck가 만들어 내는 결과의 "질적 차이"가 쉽게 따라잡히지 않는다는 뜻입니다. 기능 목록만 흉내 낸 도구는 이름은 비슷해도 속이 다르고, 그 차이는 실제로 돌려 보면 결과에서 드러납니다. 방법을 지켜 둔다는 건 그 결과의 차이를 계속 유지한다는 것입니다. 사용자 입장에서는 "겉보기만 비슷한 여러 도구" 사이에서 진짜 차이를 만드는 게 무엇인지, 그 기준점을 하나 갖게 되는 셈입니다.

이 세 가지를 한 문장으로 묶으면 이렇습니다. 특허가 다섯 건 있다는 건, "이 도구가 자기 방법을 갖고 있고, 그 방법이 외부에 휘둘리지 않으며, 쉽게 복제되지 않는다"는 세 가지 안정성을 한꺼번에 말해 주는 신호입니다. 하나하나는 사소해 보여도, 오래 쓸 도구를 고르는 입장에서는 이 세 가지가 겹쳐질 때 비로소 "믿고 맡겨도 되겠다"는 판단이 섭니다. 특히 공공 현장처럼 담당자가 바뀌어도 같은 기준으로 계속 점검해야 하는 환경에서는, 도구가 자기 방법을 또렷하게 갖고 있다는 게 곧 업무의 연속성으로 이어집니다. 담당자가 바뀌어도 방법은 그대로 남으니까요.

여기서 솔직하게 짚어야 할 게 있습니다. "특허가 다섯 개 있으니 무조건 최고"라는 뜻은 결코 아닙니다. 특허는 "이 방법을 직접 만들고 지켜 두었다"는 증거이지, "그래서 결과가 완벽하다"는 보증서가 아닙니다. 이 둘을 헷갈리면 안 됩니다. 결과의 품질은 그 방법이 실제 현장에서 얼마나 잘 작동하느냐로 갈립니다. 그건 이 달 내내 본 빈칸 채우기, 우선순위 매기기, 개선안 붙이기가 실제로 제대로 도느냐의 문제이지, 특허가 몇 개냐의 문제가 아닙니다. 그러니 "특허 있으니 믿으세요"가 아니라 "이 방법들을 직접 만들고 지켜 두었으니, 실제로 돌려 보고 판단해 주세요" 정도로 받아들이시는 게 정확합니다. 방법을 지켰다는 사실과 결과가 좋다는 사실은 이어져 있지만, 같은 말은 아닙니다.

본론 4 — 왜 여러 단계라서 여러 권리인가

앞에서 "다섯 개의 자리가 있어서 다섯 개"라고 말씀드렸는데, 이걸 조금 다른 각도에서 한 번 더 풀어 보겠습니다. ViewCheck의 분석은 한 방에 끝나는 게 아니라 여러 단계를 거칩니다. 그 단계 하나하나가 저마다 고유한 방법을 요구하고, 그래서 권리도 여러 개로 나뉜 것입니다.

한번 분석이 흘러가는 순서를 따라가 보겠습니다. 먼저 실제 사이트를 사용자가 보는 것과 똑같이 그려 냅니다(렌더링 화면 수집·측정). 그렇게 그려 낸 화면을 846규칙에 대조해 통과·미통과·해당 없음을 판정합니다(기준 자동 판정). 이때 코드만으로 판단이 안 서는 항목은 화면 인식과 겹쳐서 다시 봅니다(코드·화면 결합 판정). 설계 단계에서 본 결과가 있다면 지금 운영 결과와 맞춰 봅니다(시점 비교). 마지막으로 이렇게 나온 위반들을 위험도로 줄 세워 "무엇부터"를 정해 줍니다(위험도 등급화·우선순위). 이 다섯 단계가 순서대로, 혹은 서로 물리며 돌아갑니다.

화면을 그려 내고(수집·측정), 기준에 대조하고(자동 판정), 코드와 화면을 겹쳐 보고(결합 판정), 설계와 운영을 맞춰 보고(시점 비교), 위반을 줄 세우는(위험도 등급화) 다섯 단계가 왼쪽에서 오른쪽으로 이어지며, 각 단계마다 하나의 독립된 방법이 붙는 흐름을 담은 개념 도식 (Gemini 1:1)

이걸 보면 왜 하나로 묶을 수 없는지가 분명해집니다. 화면을 그려 내는 방법과 위반을 줄 세우는 방법은 하는 일이 완전히 다릅니다. 앞 단계는 "사용자가 보는 진짜 화면을 어떻게 안정적으로 만들어 내느냐"의 문제이고, 뒷 단계는 "이미 찾은 문제들을 어떤 기준으로 어떻게 순서 매기느냐"의 문제입니다. 재료를 손질하는 기술과 상을 차리는 기술을 하나로 묶을 수 없는 것과 같습니다. 각 단계가 독립적으로 발전할 수 있고, 독립적으로 의미가 있기 때문에, 권리도 단계별로 정리하는 게 자연스럽습니다.

그리고 이 단계들 뒤에는 앞서 말씀드린 두 개의 엔진이 있습니다. 하나는 코드를 읽어서 규칙에 대조하는 규칙 엔진이고, 다른 하나는 화면을 이미지로 인식하는 시각 엔진입니다. 규칙 엔진은 "이 코드가 기준에 맞나"를 빠르고 정확하게 판정하는 데 강하고, 시각 엔진은 "코드로는 안 보이는 것이 화면에 있나"를 잡아내는 데 강합니다. 이 두 엔진이 각자의 자리에서 일하고, 그 결과를 겹쳐서 최종 판정을 냅니다. 다섯 개의 방법이 이 두 엔진 위에서 돌아가는 구조인 것이죠. 두 엔진이 있으니 다섯 방법이 각자 제 역할을 할 수 있고, 다섯 방법이 나뉘어 있으니 두 엔진의 결과가 서로 충돌하지 않고 제자리를 찾습니다.

단계로 나눠 보면 또 하나 분명해지는 게 있습니다. 앞 단계가 무너지면 뒷 단계가 아무리 정교해도 소용이 없다는 점입니다. 예를 들어 화면을 제대로 못 그려 냈다면(수집·측정 실패), 그 위에서 아무리 정확하게 846규칙을 대조해도(자동 판정) 틀린 화면을 재는 것이니 결과가 맞을 리 없습니다. 반대로 화면은 잘 그렸는데 위반을 줄 세우는 방법이 없다면(등급화 없음), 담당자는 제대로 그려 낸 수백 건의 위반 앞에서 여전히 막막합니다. 그래서 이 다섯 방법은 어느 하나만 잘한다고 되는 게 아니라, 각 단계가 제 몫을 해야 전체가 성립합니다. 이건 자물쇠 다섯 개가 각자 다른 문을 지켜야 집 전체가 안전해지는 것과 같은 이치입니다. 한 자리가 뚫리면 나머지가 아무리 튼튼해도 의미가 줄어드니까요. 방법을 다섯으로 나눠 각각을 단단히 다진 이유가 여기에도 있습니다.

여기서 한 가지 오해를 미리 풀어 두겠습니다. "그럼 특허 다섯 개가 결국 한 도구의 부품이니, 사실상 하나 아니냐"고 하실 수 있습니다. 그렇지 않습니다. 자동차에 엔진 특허와 브레이크 특허가 따로 있는 것과 같습니다. 둘 다 한 대의 자동차 안에 들어가지만, 엔진 만드는 방법과 브레이크 만드는 방법은 전혀 다른 기술이고 따로 지킬 가치가 있습니다. ViewCheck의 다섯 방법도 마찬가지입니다. 한 도구 안에서 함께 돌지만, 각각은 따로 떼어 놓고 봐도 독립된 기술입니다. 그래서 다섯 개로 정리한 것이지, 억지로 쪼갠 게 아닙니다.

본론 5 — 공공 웹 품질 분야에서 특히 의미 있는 이유

이걸 공공 웹 품질이라는 분야에 놓고 보면, 조심스럽게 한 가지 의미가 더 있습니다. 단정하지 않고, 있는 그대로만 말씀드리겠습니다.

공공기관 웹사이트는 한두 곳이 아닙니다. 전국에 수천 개가 있고, 매년 개편되며, 점검할 사람은 늘 부족합니다. 이 달 내내 짚어 온 그 규모와 인력의 문제입니다. 담당자 한두 명이 수백 페이지짜리 사이트를 손으로 다 보는 건 애초에 불가능하고, 그나마 볼 줄 아는 사람도 조직에 한두 명뿐인 경우가 많습니다. 이런 분야에서 "분석 방법을 직접 만들고 지켜 둔 도구"가 있다는 건, 적어도 그 도구가 급조된 단발성 제품이 아니라 기술적 토대를 갖추고 있다는 하나의 신호가 될 수 있습니다. 방법을 정리해서 출원까지 했다는 건, 그만큼 그 방법을 오래 다듬고 검증했다는 뜻이기도 하니까요.

아래는 그 방법들이 실제로 결과로 이어지는 한 장면입니다. 846규칙이 카테고리별로 판정되고, 그 판정 위에 위험도와 우선순위가 얹혀 "무엇부터 봐야 하는지"가 정리된 모습입니다. 다섯 방법 중 "기준 자동 판정"과 "위험도 등급화·우선순위"가 결과 화면에서 만나는 자리라고 보시면 됩니다.

ViewCheck 규칙 검증 결과가 카테고리(DS·CP·BP·SP)별로 통과·미통과·해당 없음으로 판정되고, 그 위에 위험도와 우선순위가 정리된 목록 화면. 기준 자동 판정과 위험도 등급화가 결과에서 만나는 자리 (게재 시 기관명·도메인 블러)

다만 여기서도 단정은 하지 않겠습니다. "특허가 있으니 공공에서 무조건 이 도구를 써야 한다"는 이야기가 아닙니다. 도구를 고를 때는 특허 개수만 보는 게 아니라, 실제로 우리 사이트를 돌려 봤을 때 결과가 쓸 만한지, 개선안이 현장에서 실제로 실행 가능한지, 담당자가 그 결과를 갖고 윗선에 보고할 수 있을 만큼 근거가 또렷한지를 직접 봐야 합니다. 특허는 그 판단을 돕는 하나의 재료일 뿐, 그 자체가 결론이 아닙니다. 그래서 다음 달부터 각 방법을 영역별로 깊게 파면서, "이 방법이 실제로 어떻게 작동하고, 어떤 결과를 내는지"를 하나씩 눈으로 확인하실 수 있게 보여 드리려는 것입니다. 자랑으로 끝나지 않고 실물로 증명하는 쪽으로 가겠다는 뜻입니다.

조금 더 현실적인 이야기를 해보겠습니다. 공공기관 담당자분들이 웹 품질 점검 도구를 검토할 때 가장 자주 부딪히는 어려움이, "어느 도구가 진짜인지 겉만 봐서는 모르겠다"는 것입니다. 소개 자료만 놓고 보면 다들 비슷비슷합니다. 접근성 봅니다, 성능 봅니다, KRDS 기준 봅니다, 리포트 나옵니다 — 다 적혀 있죠. 그 목록만으로는 진짜 실력을 가진 도구와 이름만 붙여 놓은 도구를 가려내기가 어렵습니다. 바로 이 지점에서 "방법을 직접 만들고 정리해 두었는가"가 하나의 판별 기준이 됩니다. 방법을 스스로 만든 곳은 그 방법을 설명할 수 있고, 왜 그렇게 판정했는지 근거를 댈 수 있습니다. 반대로 남의 것을 조립한 곳은 결과는 내놓아도 "왜 그런지"를 깊이 있게 설명하지 못하는 경우가 많습니다. 그래서 도구를 검토하실 때는 기능 목록만 보지 마시고, "이 판정이 왜 이렇게 나왔는지 설명해 달라"고 한 번 물어보시길 권합니다. 그 대답의 깊이가 방법의 유무를 드러냅니다.

한 가지 덧붙이면, 공공 분야에서 방법을 지킨다는 것에는 또 다른 결이 있습니다. 공공 웹 품질 점검은 결과가 근거로서 재현되어야 하는 일입니다. "우리 사이트가 이만큼 개선됐다"를 보고하려면, 같은 방법으로 같은 기준으로 다시 재서 비교할 수 있어야 합니다. 방법이 흔들리면 그 비교 자체가 성립하지 않죠. 그래서 방법을 또렷하게 정리해 두었다는 건, 이 재현 가능성의 토대를 갖췄다는 것과도 이어집니다. 정리된 방법 위에서만 "지난번 대비 얼마나 나아졌나"라는 질문에 숫자로 답할 수 있습니다. 이 시점 비교와 추세 읽기가 실제로 어떻게 쓰이는지는 이 시리즈 뒷부분에서 따로 다룰 예정입니다.

본론 6 — 그래서 도구를 고를 때 무엇을 봐야 하나

여기까지 오면 자연스럽게 이런 생각이 드실 겁니다. "특허가 방법의 차이를 지킨다는 건 알겠는데, 그럼 실제로 도구를 고를 때 그 차이를 어떻게 알아보나." 소개 페이지에 적힌 기능 목록은 다 비슷해 보이는데 말입니다. 그래서 오늘 이야기한 다섯 개의 방법을, "도구를 고를 때 던져 볼 다섯 가지 질문"으로 바꿔 보겠습니다. 이 질문들은 특허가 있느냐 없느냐를 묻는 게 아니라, 그 도구가 방법을 제대로 갖췄는지를 결과로 확인하는 실무 점검표에 가깝습니다.

질문 ① — 코드만 보나, 화면까지 보나

첫 번째 질문입니다. "이 도구는 사이트를 실제로 그려 내서 화면을 보나요, 아니면 코드만 받아서 판단하나요." 이게 왜 중요하냐면, 요즘 웹은 코드만 봐서는 절반밖에 못 보기 때문입니다. 이미지 위에 얹힌 가짜 버튼, 자바스크립트로 나중에 그려지는 메뉴, 화면에서만 드러나는 겹침 같은 건 코드만 봐서는 안 잡힙니다. 확인하는 방법은 간단합니다. 결과에 스크린샷이 있는지, 색 대비나 간격이 "느낌"이 아니라 픽셀 단위 수치로 나오는지를 보면 됩니다. 화면을 그려서 재는 도구라야 그 수치가 나옵니다. 오늘 이야기한 다섯 방법 중 "렌더링 기반 화면 수집·측정"과 "코드·화면 결합 판정"이 여기에 답합니다.

질문 ② — 판단 못 하는 항목을 어떻게 처리하나

두 번째 질문입니다. "판단할 수 없는 항목이 나왔을 때, 그냥 넘기나요, 채우려고 하나요." 846규칙을 대조하다 보면 그 페이지에 없는 요소에 대한 규칙은 "해당 없음(N/A)"이 됩니다. 여기까지는 정상입니다. 문제는 그 N/A를 얼마나 정직하게, 또 얼마나 적극적으로 다루느냐입니다. 코드만 보고 애매하면 다 N/A로 던져 버리는 도구는, 겉으로는 "위반이 적네" 싶어도 사실은 "많이 못 본 것"입니다. 반대로 화면 인식으로 그 빈칸을 다시 들여다보고 채우는 도구는 판정할 수 있는 항목이 더 많습니다. 확인하는 방법은, 결과에서 "해당 없음"의 비율이 지나치게 높지 않은지, 그리고 그 N/A가 왜 N/A인지 설명이 붙는지를 보는 것입니다. 이건 "기준 자동 판정"과 "코드·화면 결합 판정"이 실제로 얼마나 잘 도는지를 가르는 지점입니다.

질문 ③ — 위반을 그냥 쏟아 내나, 줄을 세워 주나

세 번째 질문입니다. "위반이 수백 건 나왔을 때, 목록만 던지나요, 무엇부터 고칠지 순서를 매겨 주나요." 이건 받아 든 사람의 실무를 완전히 갈라놓는 차이입니다. 순서 없이 던져진 수백 건은 그 자체로 또 하나의 숙제입니다. 어디서부터 손대야 할지 모르니, 결국 아무것도 못 하고 덮어 두게 되죠. 반면 치명도·빈도·위치를 종합해 P0부터 P3까지 줄을 세워 주면, "이번 분기에는 P0와 P1만 잡자"는 실행 계획이 바로 나옵니다. 확인하는 방법은, 결과에 우선순위 등급이 있는지, 그 등급이 무슨 근거로 매겨졌는지가 보이는지입니다. "위반 위험도 등급화 및 개선 우선순위 산정"이 여기에 답합니다.

질문 ④ — 한 페이지만 보나, 사이트 전체를 보나

네 번째 질문입니다. "이 도구는 메인 한 장만 보나요, 아니면 사이트 안쪽 페이지까지 따라 들어가 보나요." 사람이 손으로 점검할 때 가장 자주 빠뜨리는 게 바로 깊은 페이지입니다. 정작 사용자가 오래 머무는 신청·조회·안내 페이지는 안쪽에 있는데, 점검은 메인에서 끝나는 경우가 많죠. 여러 페이지를 따라 들어가 보는 도구라야 "메인은 새로 단장했는데 3년 전 신청 페이지는 그대로"인 상황이 드러납니다. 확인하는 방법은, 분석 대상 페이지 수를 설정할 수 있는지, 그리고 페이지별 결과가 따로 나오는지를 보는 것입니다. 이건 시점을 맞춰 보는 방법, 그리고 사이트 전체를 훑는 운영 시점의 힘과 이어집니다.

질문 ⑤ — 두 번 돌리면 같은 결과가 나오나

다섯 번째 질문입니다. 어쩌면 가장 중요한 질문입니다. "같은 사이트를 두 번 돌리면 같은 결과가 나오나요." 이게 왜 결정적이냐면, 결과를 근거로 쓰려면 재현이 되어야 하기 때문입니다. 두 번 돌렸는데 점수가 다르게 나오는 도구는, 그 숫자를 갖고 보고할 수가 없습니다. "지난번 대비 나아졌다"고 말하려면 같은 방법으로 같은 기준으로 다시 잴 수 있어야 하는데, 매번 결과가 흔들리면 그 비교 자체가 성립하지 않죠. 방법이 또렷하게 정리되어 있는 도구라야 같은 입력에 같은 출력이 나옵니다. 확인하는 방법은 말 그대로, 같은 주소를 두 번 넣어 보는 것입니다. 재현되는 결과라야 증빙이 되고, 증빙이 되어야 근거가 됩니다.

이 다섯 가지 질문은 공교롭게도 오늘 이야기한 다섯 개의 방법과 하나씩 맞물립니다. 특허가 있느냐를 직접 묻지 않아도, 이 질문들에 결과로 답하는 도구라면 그 뒤에 방법이 갖춰져 있다는 뜻입니다. 반대로 기능 목록은 그럴싸한데 이 질문들 앞에서 흐릿해지는 도구라면, 메뉴판만 있고 레시피는 없는 것일 수 있습니다. 그래서 저희는 "특허 다섯 개 있습니다"라고 말하기보다, 실제로 돌려 보시고 이 다섯 질문으로 확인해 달라고 말씀드리는 편입니다. 방법은 말이 아니라 결과로 증명되는 것이니까요. 특허는 그 방법을 지켜 두는 울타리일 뿐, 울타리 안에서 실제로 무엇이 자라는지는 직접 들어와서 보셔야 알 수 있습니다. 그리고 저희는 그 울타리 안을 언제든 활짝 열어 보여 드릴 준비가 되어 있습니다.

그래서 ViewCheck는

ViewCheck는 이 달 내내 본 세 가지 분석 방법 — 운영 시점의 URL 분석, 설계 시점의 Figma 분석, 판단 시점의 LLM 분석 — 을 한 도구에 모았습니다. 그리고 그 방법의 핵심을 다섯 개의 기술 단위로 정리해 특허로 출원했습니다. ① 시점 비교(설계와 운영을 교차로 맞춰 보는 방법), ② 기준 자동 판정(846규칙을 화면에 대조하는 방법), ③ 렌더링 기반 화면 수집·측정(실제 화면을 그려서 재는 방법), ④ 위반 위험도 등급화 및 개선 우선순위 산정(수백 건을 줄 세우는 방법), ⑤ 코드·화면 결합 판정(코드와 화면을 겹쳐 판단하는 방법). 이 다섯이 세 방법을 아래에서 떠받치고 있습니다.

거창하게 들릴 수 있지만, 결국 핵심은 "기능이 아니라 방법을 지킨다"는 한마디입니다. 화면 모양이나 메뉴 구성은 누구나 베낄 수 있습니다. 그건 메뉴판이니까요. 하지만 실제 화면을 안정적으로 그려 내는 방법, 그 위에서 846규칙을 자동으로 판정하는 방법, 코드와 화면을 겹쳐 빈칸을 채우는 방법, 두 시점을 맞춰 간극을 잡는 방법, 수백 건을 흔들림 없이 줄 세우는 방법은 직접 만들어야만 나옵니다. 그 방법을 다섯 개로 나눠 지켜 둔 것입니다.

각 특허가 어느 방법에 구체적으로 걸치는지는 이번 주 금요일에 한 장의 지도로 정리하겠습니다. 그리고 다섯 개 방법 각각이 실제로 어떻게 작동하는지는 다음 달, 그러니까 2개월차부터 영역별로 깊게 파겠습니다. 특히 다음 달은 운영 시점(URL 분석)을 본격적으로 파고드는 달입니다. 화면을 어떻게 픽셀 단위로 재는지, 안 보이는 값들을 어떻게 읽어 내는지 같은 걸 사례와 함께 풀 예정입니다. 위험도 등급화가 어떤 기준으로 도는지는 4개월차에서, 846규칙의 네 카테고리(DS·CP·BP·SP)가 각각 어떤 성격인지는 5개월차에서 하나씩 깊게 다룹니다. 오늘은 "왜 다섯 개인지, 그게 왜 의미가 있는지"라는 큰 그림만 잡고 가시면 됩니다.

🔐 특허로 지키는 부분

오늘 글은 그 자체가 특허 이야기였습니다. ViewCheck가 출원한 다섯 건 — ① 시점 비교(설계·운영 교차 검증), ② 기준 자동 판정(846규칙), ③ 렌더링 기반 화면 수집·측정, ④ 위반 위험도 등급화 및 개선 우선순위 산정, ⑤ 코드·화면 결합 판정(코드와 화면을 겹쳐 판단) — 은 모두 "기능"이 아니라 "그 기능을 만드는 방법"을 권리로 정리한 것입니다. 화면의 모양이나 메뉴의 구성이 아니라, 실제 화면을 그려 내고 기준에 대조하고 빈칸을 채우고 위반을 줄 세우는 절차 그 자체에 차별점이 있습니다. 이 다섯이 각각 독립된 자리를 지키기 때문에 하나로 뭉뚱그리지 않고 다섯 개로 나뉘어 있습니다.

다만 솔직히 짚어 두어야 할 게 있습니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 다섯 개 특허가 있다고 해서 결과가 자동으로 완벽해지는 게 아니라, 그 방법들이 실제 현장에서 잘 작동할 때 결과가 좋아지는 것이고, 특허는 그 방법을 보호하는 역할을 할 뿐입니다. 그래서 "특허가 있으니 믿으세요"가 아니라 "이 방법들을 직접 만들고 지켜 두었으니, 실제로 돌려 보고 판단해 주세요" 정도로 받아들여 주시면 됩니다. 그리고 이 다섯 건은 현재 모두 출원 중입니다. "등록특허"가 아니라 "출원 기술"로 정확히 표기합니다. (특허 출원 기술 / 자체 개발)

마무리

오늘은 ViewCheck가 특허를 다섯 개 낸 이유를 봤습니다. 기능 목록(메뉴판)은 누구나 베낄 수 있지만, 그 기능을 만드는 방법(레시피)은 함부로 베끼지 못합니다. 그래서 지킨 것은 기능이 아니라 방법이고, 그 방법이 다섯 개의 독립된 핵심 기술 단위 — 시점 비교, 기준 자동 판정, 렌더링 기반 화면 수집·측정, 위반 위험도 등급화 및 우선순위 산정, 코드·화면 결합 판정 — 로 나뉘어 다섯 건이 되었습니다. 지켜야 할 자리가 다섯 군데라서 자물쇠도 다섯 개인 셈입니다.

오늘 이야기를 한 문장으로 압축하면 이렇습니다. "기능은 흉내 낼 수 있어도, 그 기능을 만드는 방법은 못 베낀다." 그래서 ViewCheck는 화면에 보이는 기능이 아니라, 그 뒤에서 도는 방법을 다섯 개로 나눠 지켰습니다. 실제 화면을 그려 내고, 기준에 대조하고, 코드와 화면을 겹치고, 두 시점을 맞추고, 위반을 줄 세우는 그 다섯 단계 각각이 저마다 지킬 가치가 있는 레시피였기 때문입니다.

이걸 쓰는 분께 의미는 세 가지였습니다. 진짜 자기 기술이라는 것, 쉽게 사라지지 않는다는 것, 차별화가 유지된다는 것. 다만 특허는 결과를 보장하는 보증서가 아니라 방법을 지키는 장치라는 것, 그리고 지금은 모두 출원 중이라는 것까지 솔직하게 짚었습니다. 자랑으로 끝내지 않고, 할 수 있는 것과 아직 증명해야 할 것을 갈라서 말씀드리는 게 이 시리즈의 태도이기도 합니다.

이번 주 나머지 글에서 이걸 더 구체화하겠습니다. 수요일에는 "기능은 같은데 결과가 다른 이유"를 익명 사례로 풀고, 금요일에는 "다섯 개 특허가 세 개 방법에 어떻게 걸치는지"를 한 장의 지도로 정리하겠습니다. 이번 주가 1개월차의 마지막 주입니다. 세 시점과 다섯 특허를 다 봤으니, 다음 달부터는 각 시점을 영역별로 깊게 파 내려갑니다. 그 첫 타자가 운영 시점, URL 분석입니다. 오늘도 끝까지 읽어 주셔서 고맙습니다. 수요일에 사례로 이어가겠습니다.

krds.viewcheck.co.kr