기능은 베껴도 방법론은 못 베낀다 — 겉보기 기능 뒤에 숨은 '방법'을 알아보는 법

들어가며 — "기능 목록은 다 똑같던데요"의 함정

이번 주 월요일에는 "왜 하필 특허가 다섯 건이나 필요했나"를 말씀드렸습니다. 겉으로 드러나는 화면이나 버튼 같은 기능은 누구나 흉내 낼 수 있지만, 그 기능을 실제로 굴러가게 만드는 방법(방법론)은 쉽게 베낄 수 없다는 이야기였습니다. 오늘은 그 이야기를 한 발 더 밀어보려 합니다. "기능은 베껴도 방법론은 못 베낀다"는 말이, 실제 현장에서 어떻게 드러나는지를요.

도구를 고르는 입장에서 가장 흔히 빠지는 함정이 하나 있습니다. 바로 "기능 목록 비교"입니다. A 도구도 접근성 검사가 된다고 하고, B 도구도 된다고 합니다. A도 AI 분석을 준다 하고, B도 준다 합니다. 그래서 표를 만들어 항목마다 동그라미를 치다 보면, "둘 다 다 있네, 그럼 싼 걸로" 하는 결론에 도달합니다. 아주 자연스러운 판단입니다. 기능 목록만 놓고 보면 실제로 거의 똑같아 보이니까요.

그런데 막상 그 둘을 같은 사이트에 나란히 돌려보면, 결과가 딴판인 경우가 많습니다. 어느 쪽은 위반을 한 무더기 뱉어놓고 끝나는데, 어느 쪽은 그 위반에 우선순위를 붙이고 어디를 어떻게 고칠지까지 정리해 줍니다. 어느 쪽은 돌릴 때마다 결과가 조금씩 흔들리는데, 어느 쪽은 어제와 오늘이 같게 나옵니다. 기능 이름은 분명 같은데 왜 이런 차이가 날까요. 답은 하나입니다. 기능 이름은 같아도, "그 기능을 어떻게 만들었느냐"가 다르기 때문입니다.

오늘은 그 "같은 기능, 다른 결과"가 갈리는 지점을 짚고, 겉보기 기능 뒤에 숨은 방법을 알아보는 법을 정리하려 합니다. 미리 말씀드리면, ViewCheck가 그 방법의 핵심으로 삼은 것은 세 가지입니다. 세 시점을 하나의 자로 교차 판정하는 것, 두 엔진을 질서 있게 합치는 것, 그리고 그 결과를 위험도로 정리하는 것. 이 세 가지가 오늘의 뼈대입니다.

한 가지 먼저 짚어두겠습니다. 오늘 이야기는 특정 제품을 깎아내리려는 게 아닙니다. "다른 도구는 못 한다" 같은 단정도 하지 않겠습니다. 그저 "겉보기 기능과 그 뒤의 방법은 다른 층위의 이야기"라는 것, 그리고 "그 방법을 알아보는 눈이 있으면 도구를 훨씬 잘 고를 수 있다"는 것을 보여드리려는 겁니다. 사례는 전부 익명으로, 어디서나 비슷하게 반복되는 전형을 하나로 묶어서 봅니다.

비유를 하나 들어보겠습니다. 식당을 고를 때 메뉴판만 보고 고르는 경우를 떠올려 보십시오. A 식당도 파스타를 팔고, B 식당도 파스타를 팝니다. 메뉴판에 적힌 이름은 똑같이 "토마토 파스타"입니다. 그런데 실제로 나온 접시는 전혀 다를 수 있습니다. 한쪽은 좋은 재료를 제대로 손질해서 냈고, 한쪽은 대충 데워서 냈으니까요. 메뉴판의 이름이 같다고 접시가 같은 게 아닙니다. 접시를 가르는 건 이름이 아니라 레시피, 즉 그 요리를 어떻게 만드느냐입니다. 점검 도구도 정확히 이렇습니다. 기능 목록은 메뉴판이고, 그 기능을 만드는 방법은 레시피입니다. 오늘 글은 "메뉴판 말고 레시피를 보는 법"에 관한 이야기라고 생각하시면 됩니다.

본론 1 — 같은 기능 이름 아래 결과가 갈리는 세 자리

먼저, 같은 기능 이름 아래에서 결과가 실제로 갈리는 대표적인 자리 세 곳을 보겠습니다. 접근성 검사, AI 분석, 그리고 리포트. 이 셋은 어느 점검 도구나 "됩니다"라고 말하는 기능인데, 그 "됩니다" 안의 깊이가 천차만별입니다.

위쪽에는 누구나 따라 적을 수 있는 기능 목록(메뉴판)이 나란히 놓이고, 아래쪽에는 그 기능을 결과로 바꾸는 방법(레시피)이 겹겹의 절차로 이어지는 대비 도식. 이름은 베낄 수 있어도 방법은 그대로 옮겨 붙일 수 없음을 나타냄 (Gemini 1:1)

이 세 자리를 하나씩 보기 전에, 한 가지를 미리 붙잡아 두면 좋겠습니다. 아래에서 볼 차이들은 전부 "기능이 있느냐 없느냐"의 문제가 아니라 "그 기능이 얼마나 깊으냐"의 문제라는 점입니다. 세 자리 모두, 두 도구가 다 "됩니다"라고 답할 수 있습니다. 그런데 그 "됩니다"의 속을 열어 보면 깊이가 다릅니다. 그 깊이를 만드는 게 방법이고요.

접근성 검사 — "검사한다"는 같지만 깊이가 다르다

"접근성 검사"는 어느 도구나 한다고 합니다. 그런데 어떻게 검사하느냐가 갈립니다. 누구는 자동 검사 도구 하나만 돌려서 그 결과를 그대로 뱉습니다. 누구는 여러 검사 엔진을 교차로 돌려서, 한쪽이 놓친 것을 다른 쪽으로 잡습니다. 누구는 코드만 훑어서 "이미지에 대체 텍스트가 없다" 정도만 잡는데, 누구는 화면까지 봐서 "이 이미지로 만든 버튼은 라벨이 없어서 화면 낭독기가 못 읽는다"까지 잡습니다. 검사 이름은 똑같이 "접근성 검사"인데, 파고드는 깊이가 다릅니다.

이 차이가 왜 중요하냐면, 얕게 검사한 결과와 깊게 검사한 결과가 겉으로는 구분이 안 되기 때문입니다. 둘 다 "접근성 검사 완료"라는 라벨을 답니다. 둘 다 그럴싸한 목록을 보여줍니다. 그런데 얕은 검사는 정작 중요한 문제를 통째로 놓치고 있을 수 있습니다. 겉보기로는 둘 다 "검사가 됐다"이지만, 실제로 잡아낸 것은 다릅니다.

더 곤란한 건, 얕은 검사가 오히려 안심을 준다는 점입니다. 문제를 적게 잡으니 "우리 사이트는 괜찮네"라는 느낌을 줍니다. 그런데 그건 문제가 없어서가 아니라, 못 봐서 안 보이는 것일 수 있습니다. 깊게 검사하는 도구는 오히려 문제를 더 많이 꺼내 놓아 처음엔 불편하게 느껴질 수 있지만, 그게 실제 사용자가 겪는 현실에 더 가깝습니다. "적게 나와서 좋은 도구"가 아니라 "실제를 정확히 비추는 도구"가 좋은 도구입니다. 이 구분은 검사 결과의 개수만 봐서는 알 수 없고, 그 검사가 어떤 방법 위에 서 있는지를 봐야 알 수 있습니다.

AI 분석 — "AI를 쓴다"는 같지만 쓰는 법이 다르다

"AI 분석 제공"도 흔한 문구입니다. 그런데 AI를 어떻게 쓰느냐가 천지 차이를 만듭니다. 누구는 AI에게 화면을 통째로 던지고 "알아서 판단해"라고 맡깁니다. 그러면 결과가 들쑥날쑥합니다. 어제는 통과였던 게 오늘은 미통과로 나오고, 같은 화면을 봐도 판정이 흔들립니다. 누구는 규칙 엔진으로 정확한 뼈대를 먼저 만들어 두고, AI는 그 뼈대 위의 빈칸만 채우게 씁니다. 그러면 결과가 일관됩니다.

"AI를 쓴다"는 같은 말인데, 토대 위에서 쓰느냐 통째로 맡기느냐가 결과의 신뢰를 가릅니다. 통째로 맡긴 AI는 그럴듯한 문장을 잘 만들지만, 같은 질문에 매번 다르게 답할 수 있습니다. 토대 위에서 빈칸만 채우는 AI는, 뼈대가 이미 정해져 있으니 흔들릴 여지가 적습니다. 이 차이는 기능 목록에는 절대 안 적힙니다. 둘 다 그냥 "AI 분석"이라고 적히니까요.

리포트 — "보고서를 준다"는 같지만 쓸모가 다르다

"리포트 제공"도 마찬가지입니다. 누구는 위반 목록을 길게 뽑아서 끝냅니다. 화면 가득 빨간 표시가 뜨고, 항목이 수백 개 나열됩니다. 그런데 그 목록을 받아 든 담당자는 막막합니다. 어느 게 급한지, 뭘 먼저 고쳐야 하는지, 어떻게 고치는지가 없기 때문입니다. 위반을 "찾는" 데서 멈춘 리포트입니다.

누구는 그 위반에 우선순위를 매기고, "어디를, 어떻게 고치라"는 개선 방향까지 붙입니다. 같은 "리포트 제공"인데, 하나는 목록만 주고 하나는 실제 업무로 이어지는 지도를 줍니다. 아래는 ViewCheck가 위반 항목 하나하나에 우선순위와 개선 방향을 붙여 정리한 종합 결론 화면인데, "보고서를 준다"가 같은 문구라도 그 안의 쓸모가 이렇게 달라질 수 있다는 걸 보여줍니다.

ViewCheck AI 종합보고서의 종합 결론 화면. 위반을 찾는 데 그치지 않고, 어느 것이 급한지(우선순위)와 어떻게 고칠지(개선 방향)가 함께 정리된 모습 (게재 시 기관명·도메인 블러)

이 세 자리에서 보듯, 기능 이름은 표면입니다. "접근성 검사", "AI 분석", "리포트 제공" — 이 라벨들은 누구나 붙일 수 있습니다. 그 라벨 밑의 "어떻게"가 결과를 만듭니다. 그리고 그 "어떻게"가 바로 오늘 이야기할 방법론입니다.

본론 2 — 겉보기 기능은 베껴도, '방법'은 왜 못 베끼나

그럼 ViewCheck가 말하는 그 "방법"이란 구체적으로 무엇일까요. 화면과 버튼 같은 겉모습이 아니라, 결과의 깊이를 만드는 그 뒷단의 절차 말입니다. 세 가지로 나눠 보겠습니다. 이 셋이 오늘 글의 심장입니다.

방법 ① — 세 시점을 하나의 자로 교차 판정한다

첫 번째 방법은, 하나의 사이트를 서로 다른 세 시점에서 보고 그 결과를 같은 잣대로 합치는 것입니다. 세 시점이란 설계 시점, 운영 시점, 맥락 시점을 말합니다.

설계 시점은 사이트가 만들어지기 전, 디자인 단계를 봅니다. 디자인 파일에서 색·글자·간격 같은 값을 뽑아 표준과 대조합니다. 아직 만들기 전이라, 여기서 잡으면 가장 싸게 고칠 수 있습니다. 운영 시점은 지금 실제로 돌아가는 진짜 사이트를 봅니다. 사용자가 실제로 마주하는 그 화면을, 그 데이터가 들어찬 상태 그대로 봅니다. 맥락 시점은 그 위에서 "이 화면이 실제 상황에서 말이 되는가"를 판단합니다. 규칙만으로는 딱 잘라 말하기 어려운, 판단이 필요한 자리를 봅니다.

여기서 중요한 건, 이 세 시점을 그냥 따로따로 보는 게 아니라는 점입니다. 세 시점 모두를 하나의 규칙 체계로 교차 판정한다는 게 핵심입니다. ViewCheck의 규칙 체계는 846개 규칙으로 이루어져 있습니다. 디자인 스타일 120개, 컴포넌트 446개, 기본 패턴 108개, 서비스 패턴 172개. 이 846개가 세 시점 모두에 같은 자로 적용됩니다. 설계 단계에서 잡은 문제와 운영 단계에서 잡은 문제가 같은 규칙 언어로 표현되니, 서로 비교하고 합칠 수 있습니다.

이게 왜 따라 하기 어렵냐면, 시점 하나만 보는 도구를 만드는 건 어렵지 않지만, 세 시점을 하나의 자로 묶어서 서로 충돌 없이 합치는 건 시간과 시행착오가 들기 때문입니다. 설계에서 본 "이 색이 표준과 어긋난다"와 운영에서 본 "이 화면에 색이 잘못 쓰였다"를 같은 규칙 아래 놓으려면, 규칙 체계 자체가 세 시점을 다 감당하도록 설계돼 있어야 합니다. 화면 이름 하나 따라 적는 것과는 차원이 다른 일입니다.

조금 더 풀어보겠습니다. 왜 하필 세 시점을 하나로 묶는 게 그렇게 중요할까요. 세 시점은 각자 잘 보는 게 다르기 때문입니다. 설계 시점은 아직 만들기 전이라 값을 정확히 대조할 수 있지만, 실제로 어떻게 굴러갈지는 모릅니다. 운영 시점은 진짜로 굴러가는 것을 보지만, 만들기 전에 미리 잡을 수는 없습니다. 맥락 시점은 규칙만으로 딱 잘라 말하기 어려운 자리를 판단하지만, 그 판단이 흔들리지 않으려면 밑에 단단한 규칙 뼈대가 있어야 합니다. 이 셋은 서로의 약점을 메워 줍니다. 그런데 셋이 각자 다른 언어로 결과를 내면 서로 메워 줄 수가 없습니다. 세 시점을 846개 규칙이라는 공통 언어로 묶는 이유가 바로 이겁니다. 같은 언어를 써야 설계에서 놓친 것을 운영에서 잡고, 운영에서 애매한 것을 맥락에서 판단하는 협업이 성립합니다.

846이라는 숫자도 그냥 나온 게 아닙니다. 디자인 스타일 120개는 색·글자·간격 같은 값을 수치로 대조하는 규칙이고, 컴포넌트 446개는 버튼·입력창·표 같은 요소가 제대로 갖춰졌는지 보는 규칙이고, 기본 패턴 108개는 폼 구조나 오류 처리 같은 화면 짜임새를 보는 규칙이고, 서비스 패턴 172개는 검색·로그인·신청 같은 실제 서비스 흐름을 보는 규칙입니다. 이 네 갈래가 합쳐져 하나의 자를 이룹니다. 이 자가 있으니 "어느 항목이 어긋났는지"를 세 시점 모두에서 같은 방식으로 말할 수 있습니다. 자가 없으면 시점마다 제각기 다른 말을 하게 되고, 그 결과는 합쳐지지 않습니다.

방법 ② — 두 엔진을 질서 있게 합친다

두 번째 방법은, 성격이 다른 두 개의 분석 엔진을 질서 있게 합치는 것입니다.

하나는 코드의 구조를 읽어서 규칙으로 판정하는 엔진입니다. 화면 뒤의 구조를 뜯어보고, "이 버튼에 라벨이 있나", "이 표에 제목 행이 있나", "이 색과 배경의 대비가 기준을 넘나" 같은 것을 값으로 따집니다. 구조로 판단할 수 있는 것은 이 엔진이 빠르고 정확하게 잡습니다. 다른 하나는 화면을 눈으로 보듯 시각적으로 분석하는 엔진입니다. 코드만으로는 알 수 없는 것 — 이미지로 만든 버튼, 그림 안에 들어간 글자, 비표준 방식으로 그려진 컴포넌트 — 을 화면을 봐서 감지합니다.

이 둘을 그냥 붙여 놓으면 오히려 결과가 엉킵니다. 한쪽이 "통과"라 했는데 다른 쪽이 "미통과"라 하면, 어느 쪽을 믿어야 할지 혼란스러워집니다. 그래서 순서와 규칙이 필요합니다. ViewCheck의 방법은 이렇습니다. 구조로 판정할 수 있는 것은 규칙 엔진이 먼저 확정합니다. 규칙 엔진이 확정한 판정은 시각 엔진이 뒤집지 않습니다. 시각 엔진은 규칙 엔진이 "해당 없음"으로 남긴 자리, 즉 구조만으로는 판단이 안 되는 빈칸을 채우는 역할을 맡습니다. 이렇게 역할을 나누면 두 엔진이 서로 충돌하지 않고, 각자 잘하는 영역을 맡아 결과를 더 깊게 만듭니다.

이 "질서 있게 합치기"가 방법의 핵심입니다. 두 엔진을 각각 만드는 것보다, 둘을 충돌 없이 협업시키는 절차를 세우는 게 훨씬 어렵습니다. 어느 쪽이 먼저 판정하고, 어느 쪽이 어디를 채우고, 둘의 결과가 어긋날 때 무엇을 우선하는지 — 이 순서를 잘못 잡으면 결과가 오히려 나빠집니다. 그 순서를 시행착오 끝에 잡아 두었다는 게 겉보기 기능에는 안 보이는 방법입니다.

여기서 한 가지 오해를 풀어두고 싶습니다. "두 엔진을 쓴다"고 하면, 흔히 시각 엔진이 규칙 엔진의 부족한 부분을 도와주는 보조 역할이라고 생각하기 쉽습니다. 그런데 그렇지 않습니다. 둘은 각자 잘하는 영역이 완전히 다른, 대등한 분업 관계입니다. 구조로 판단할 수 있는 것 — 라벨이 붙었는지, 대비가 기준을 넘는지 — 은 규칙 엔진이 훨씬 빠르고 정확합니다. 화면을 봐야만 알 수 있는 것 — 이미지 안에 글자가 들어갔는지, 표준을 벗어난 방식으로 그려진 버튼인지 — 은 시각 엔진만 잡을 수 있습니다. 어느 쪽도 다른 쪽을 대신할 수 없습니다. 그래서 둘 중 하나만 있는 도구는, 나머지 절반을 통째로 못 보는 셈입니다. 코드만 보는 도구는 화면에만 드러나는 문제를 놓치고, 화면만 보는 도구는 구조로 정밀하게 따져야 하는 것을 놓칩니다.

그리고 이 협업에는 한 가지 분명한 원칙이 있습니다. 규칙 엔진이 구조로 "통과" 또는 "미통과"를 확정한 것은, 시각 엔진이 뒤집지 않는다는 겁니다. 만약 이 원칙이 없으면, 규칙 엔진은 "통과"라 하고 시각 엔진은 "미통과"라 하는 충돌이 여기저기서 생깁니다. 그러면 어느 쪽을 믿어야 할지 알 수 없어지고, 결과 전체의 신뢰가 무너집니다. 그래서 확정된 판정은 건드리지 않고, 시각 엔진은 오직 규칙 엔진이 "구조만으로는 판단 못 하겠다"며 남긴 빈칸만 채웁니다. 이렇게 역할과 우선순위를 못 박아 두었기 때문에, 두 엔진의 결과가 하나로 깔끔하게 모입니다. 이 원칙 하나를 세우는 데도 적지 않은 시행착오가 있었습니다.

아래는 규칙 엔진이 화면 속 컴포넌트를 인식해 그 상세 판정을 펼쳐 보여주는 화면입니다. 코드 뒤가 아니라 화면에 보이는 컴포넌트 단위로 점검한 결과가 이렇게 생겼습니다.

ViewCheck KRDS 규칙검증 화면에서 전체 규칙의 판정 결과를 펼쳐 보여주는 모습. 846개 규칙이 통과·미통과·해당 없음으로 갈려, 세 시점의 결과가 하나의 자로 정리된 자리 (게재 시 기관명·도메인 블러)

방법 ③ — 결과를 위험도로 정리한다

세 번째 방법은, 그렇게 나온 판정을 위험도로 정리하는 것입니다.

846개 규칙을 돌리면 위반이 여럿 나옵니다. 그런데 위반이 다 똑같이 급한 건 아닙니다. 어떤 위반은 당장 사용자가 서비스를 못 쓰게 만드는 심각한 것이고, 어떤 위반은 불편하지만 서비스는 돌아가는 것이고, 어떤 위반은 다듬으면 좋은 정도입니다. 이걸 구분하지 않고 한 무더기로 던지면, 받아 든 사람은 "다 고쳐야 하나" 싶어 손을 못 댑니다.

그래서 ViewCheck는 위반마다 위험도 등급을 매깁니다. 가장 급한 것부터 나중에 다듬을 것까지 층을 나눠서, "이것부터 고치세요"를 분명히 합니다. 그리고 각 위반에 "어디를 어떻게 고치라"는 개선 방향을 붙입니다. 그러면 위반 목록이 "찾은 것"에서 "할 일"로 바뀝니다. 앞서 본 종합 결론 화면이 바로 이 정리의 결과입니다.

이 위험도 정리도 겉보기로는 단순해 보입니다. "그냥 급한 순서로 줄 세운 거 아니냐" 싶으실 수 있습니다. 그런데 무엇을 급하다고 볼지, 어떤 기준으로 층을 나눌지, 페이지가 여러 개일 때 한 페이지의 심각한 위반과 여러 페이지에 흩어진 가벼운 위반 중 무엇을 위로 올릴지 — 이런 판단이 쌓여야 위험도 정리가 실제로 쓸모 있어집니다. 이 역시 하루아침에 나오는 게 아니라, 규칙 하나하나에 무게를 매기고 다듬은 결과입니다.

특히 페이지가 많은 사이트에서 이 위험도 정리의 값어치가 드러납니다. 한 페이지만 보면 위반이 몇 개 안 되니 그냥 눈으로 훑어도 됩니다. 그런데 수십, 수백 페이지를 보면 위반이 수천 건씩 쌓입니다. 이걸 그냥 한 줄로 나열하면 아무도 못 봅니다. 여기서 "같은 위반이 여러 페이지에 반복되는가", "이 위반이 사용자의 핵심 흐름을 막는가" 같은 걸 따져 위로 끌어올려야, 담당자가 "그래, 이것부터"라고 손을 댈 수 있습니다. 위반을 찾는 것과, 그 위반을 우선순위 있는 할 일로 바꾸는 것은 전혀 다른 일입니다. 앞의 것은 기능이고, 뒤의 것은 방법입니다.

세 방법을 합치면 이렇습니다. 세 시점을 846개 규칙 하나의 자로 교차 판정하고, 두 엔진을 질서 있게 합쳐 결과를 깊게 만들고, 그 결과를 위험도로 정리해 할 일로 바꿉니다. 화면과 버튼은 이 위에 얹힌 겉모습일 뿐이고, 결과의 깊이를 만드는 건 이 세 방법입니다.

그리고 이 세 방법은 따로 노는 게 아니라 서로 맞물려 돌아갑니다. 세 시점을 하나의 자로 묶는 방법이 없으면 여러 시점의 결과를 합칠 수 없고, 두 엔진을 질서 있게 합치는 방법이 없으면 각 항목의 판정이 흔들리고, 위험도로 정리하는 방법이 없으면 아무리 정확히 판정해도 할 일로 이어지지 않습니다. 셋 중 하나만 빠져도 나머지의 값어치가 절반으로 줄어듭니다. 그래서 이 세 방법은 하나의 묶음으로 봐야 하고, 그 묶음 전체를 그대로 옮겨 붙이는 게 어렵기 때문에 "방법은 못 베낀다"는 말이 성립합니다. 화면 하나, 버튼 하나는 흉내 낼 수 있어도, 이렇게 맞물린 절차 전체를 똑같이 재현하는 건 다른 차원의 일입니다.

본론 3 — KRDS 표준 대비, 방법이 만든 결과의 얼굴

방금 본 세 방법이 실제로 어떤 결과를 만드는지, 화면 하나로 짚어보겠습니다. 아래는 분석한 사이트가 표준 대비 어느 항목에서 얼마나 어긋났는지를 항목별로 비교해 보여주는 화면입니다.

AI 종합보고서의 KRDS 비교분석(표준 대비) 화면. 분석 사이트가 표준 대비 각 항목에서 얼마나 떨어져 있는지 항목별로 비교되어, 어디를 얼마나 손봐야 하는지가 한눈에 읽히는 모습 (게재 시 기관명·도메인 블러)

이 화면이 방법론의 얼굴입니다. 왜냐하면 이런 "표준 대비 항목별 비교"는, 앞서 말한 세 방법이 다 갖춰져야 나오기 때문입니다. 우선 846개 규칙이라는 하나의 자가 있어야 "어느 항목"을 정의할 수 있습니다. 자가 없으면 비교할 기준 자체가 없습니다. 그다음, 코드로 판정할 것과 화면으로 감지할 것을 나눠 처리하는 두 엔진이 있어야 각 항목의 값이 채워집니다. 마지막으로, 그 값들이 위험도로 정리돼야 "어디부터 손봐야 하는지"가 읽힙니다.

기능 목록에 "표준 비교 제공"이라고 한 줄 적는 건 누구나 할 수 있습니다. 그런데 그 한 줄이 실제로 이런 화면으로 이어지려면, 그 뒤에 세 방법이 다 돌아가고 있어야 합니다. 겉보기 기능은 "표준 비교"라는 라벨이고, 방법은 그 라벨을 이 화면으로 만들어 내는 뒷단의 절차입니다. 라벨은 베낄 수 있어도, 라벨을 이 화면으로 바꾸는 절차는 그대로 옮겨 붙일 수 없습니다.

본론 4 — 공공 사이트에서 방법 차이가 더 크게 벌어지는 이유

같은 방법 차이라도, 어떤 사이트에서 보느냐에 따라 그 차이가 더 크게 벌어지기도 합니다. 공공 사이트가 바로 그런 곳입니다. 이유가 몇 가지 있습니다.

첫째, 공공 사이트는 페이지가 아주 많습니다. 안내·공고·민원·정책·통계가 부서마다 쌓여, 페이지 수가 수백에서 수천에 이르기도 합니다. 메인 한 장만 보는 도구와 사이트 전체를 보는 도구의 차이가, 여기서는 결정적으로 벌어집니다. 메인은 대개 가장 공들여 관리하는 얼굴이라 깔끔합니다. 그런데 사용자가 실제로 업무를 보는 곳은 신청·조회·안내 페이지입니다. 메인만 본 결과와 전체를 본 결과는, 같은 사이트를 본 것이라고 믿기 어려울 만큼 다를 수 있습니다. 페이지를 함께 보고 일관성까지 따지는 방법이 있느냐가, 여기서 큰 갈림이 됩니다.

둘째, 공공 사이트는 사용자 층이 아주 넓습니다. 젊은 사용자만 오는 게 아니라, 고령의 사용자도 오고, 오래된 기기를 쓰는 분도 오고, 화면 낭독기에 의존하는 분도 옵니다. 그래서 접근성이 특히 중요한데, 앞서 봤듯 접근성 검사는 얕게 하느냐 깊게 하느냐의 차이가 큽니다. 코드만 훑는 얕은 검사는 "이미지로 만든 버튼"이나 "그림 안에 든 글자" 같은, 실제로 취약 계층이 가장 많이 걸려 넘어지는 문제를 통째로 놓칩니다. 화면까지 보는 방법이 있어야 이런 게 잡힙니다. 사용자 층이 넓을수록, 놓친 문제 하나가 더 많은 사람에게 영향을 줍니다.

셋째, 공공 사이트는 여러 부서가 각자 콘텐츠를 올립니다. 형식이 통일되지 않은 채 온갖 게시물이 쌓이고, 그 과정에서 화면이 크고 작게 깨집니다. 이런 문제는 한 페이지를 정밀하게 보는 것만으로는 안 잡힙니다. 여러 페이지에 걸쳐 같은 자로 훑어야, "이 형식의 게시물이 여기저기서 화면을 뚫고 나간다" 같은 게 드러납니다. 세 시점을 하나의 자로 묶고, 그 자를 여러 페이지에 일관되게 적용하는 방법이 있어야 가능한 일입니다.

넷째, 공공 사이트는 품질을 "증명"해야 하는 자리가 많습니다. 내부 보고든 외부 점검이든, "우리 사이트가 표준을 얼마나 지키는지"를 근거와 함께 설명해야 할 때가 옵니다. 이때 위반을 한 무더기 던지는 목록으로는 설명이 안 됩니다. 어느 항목이 표준 대비 얼마나 어긋났는지, 무엇이 급한지, 어떻게 개선할지가 정리돼 있어야 보고가 됩니다. 위험도로 정리하는 방법이 있느냐가, 여기서 실무의 부담을 크게 가릅니다.

정리하면, 공공 사이트는 페이지가 많고, 사용자 층이 넓고, 콘텐츠가 제각각이고, 품질을 증명해야 하는 곳입니다. 이 네 가지 조건이 겹치는 곳일수록, 겉보기 기능이 같아도 방법의 차이가 결과의 차이로 크게 벌어집니다. 그래서 공공 사이트를 점검하는 도구를 고를 때는, 기능 목록보다 방법을 더 꼼꼼히 봐야 합니다.

본론 5 — 그래서, 도구를 고를 때 방법을 드러내는 질문들

그럼 도구를 고르는 입장에서, 기능 목록 너머의 이 방법을 어떻게 알아볼 수 있을까요. 몇 가지 질문을 던지면 꽤 갈립니다. 이 질문들은 전부 "그 기능이 있느냐"가 아니라 "그 기능을 어떻게 만들었느냐"를 묻습니다.

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

"이미지로 만든 버튼"을 잡느냐로 갈립니다. 코드만 보는 도구는 이걸 놓치거나 "해당 없음"으로 흘립니다. 화면까지 보는 도구는 잡습니다. 앞서 두 엔진 이야기에서 본 그 차이입니다. 물어볼 한 마디는 이겁니다. "이미지로 만든 버튼도 잡나요?" 이 질문 하나에, 코드만 보는지 화면까지 보는지가 드러납니다.

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

메인 한 장만 보는 것과, 여러 페이지를 보고 일관성과 추세까지 비교하는 것은 다릅니다. 공공 사이트처럼 페이지가 많은 곳일수록 이 차이가 큽니다. 메인은 대개 가장 잘 관리되는 페이지라, 메인만 보면 사이트가 실제보다 좋아 보입니다. 물어볼 한 마디는 이겁니다. "몇 페이지까지 한 번에 보나요, 페이지 사이 비교도 되나요?"

질문 ③ — AI를 어떻게 쓰나

통째로 맡기나, 토대 위에서 빈칸만 채우나. 후자가 결과가 일관됩니다. 앞서 본 두 방식의 차이입니다. 물어볼 한 마디는 이겁니다. "AI 판정이 매번 같게 나오나요, 판단에 근거가 붙나요?" 통째로 맡긴 도구는 이 질문 앞에서 흔들립니다.

질문 ④ — 위반에 우선순위와 개선안을 주나

위반 목록만 주나, 위험도와 "어떻게 고치라"까지 주나. 세 번째 방법에서 본 그 자리입니다. 물어볼 한 마디는 이겁니다. "위반에 급한 순서와 고치는 방법이 붙나요?" 목록만 뽑는 도구는 여기서 "그건 알아서 판단하셔야 한다"고 답하게 됩니다.

질문 ⑤ — 같은 결과가 또 나오나 (재현되나)

같은 사이트를 다시 돌리면 같은 결과가 나오나. 규칙 엔진으로 뼈대를 잡은 도구라면 재현이 됩니다. AI에 통째로 맡긴 도구라면 흔들립니다. 물어볼 한 마디는 이겁니다. "어제 돌린 것과 오늘 돌린 게 같게 나오나요?"

이 다섯 질문의 공통점은, 전부 기능 목록에는 안 보이는 것을 묻는다는 점입니다. 기능 목록에는 "접근성 검사 ○, AI 분석 ○, 리포트 ○"만 적혀 있습니다. 그 동그라미들이 어떤 방법 위에 서 있는지는 안 적혀 있습니다. 이 질문들은 바로 그 방법을 끄집어냅니다. 그리고 방법이 탄탄한 도구일수록, 이 질문들에 막힘없이 답합니다.

다섯 질문을 오늘의 세 방법과 이어 보면 관계가 더 또렷해집니다. 질문 ①(코드냐 화면이냐)과 질문 ⑤(재현되나)는 두 엔진을 질서 있게 합치는 방법과 맞닿아 있습니다. 화면까지 보려면 시각 엔진이 있어야 하고, 재현되려면 규칙 엔진이 뼈대를 잡아 줘야 하니까요. 질문 ②(한 페이지냐 전체냐)는 세 시점을 하나의 자로 묶어 여러 페이지에 일관되게 적용하는 방법과 이어집니다. 질문 ④(우선순위와 개선안)는 위험도로 정리하는 방법 그 자체입니다. 질문 ③(AI를 어떻게 쓰나)은 세 방법을 관통하는 원칙 — 규칙 뼈대 위에서 AI를 쓴다 — 을 묻습니다. 그러니 이 다섯 질문에 답한다는 건, 곧 세 방법을 갖췄다는 뜻이기도 합니다. 질문은 방법을 비추는 거울인 셈입니다.

그리고 이 질문들은 파는 쪽을 곤란하게 하려는 게 아닙니다. 오히려 서로에게 좋습니다. 방법이 탄탄한 도구라면 이 질문들에 답하면서 자기 강점을 보여줄 기회가 되고, 고르는 쪽은 겉모습에 휩쓸리지 않고 실속을 확인할 수 있습니다. 방법이 부실한 도구만 이 질문 앞에서 말을 흐리게 됩니다. 그러니 도구를 파는 사람을 만나면, 부담 없이 이 다섯 질문을 던져 보시길 권합니다.

본론 6 — 기능 목록만 보고 골랐다가 생긴 일 (익명 사례 2건)

실제로 기능 목록만 보고 골랐다가 생긴 일을 두 가지, 익명으로 옮겨 보겠습니다.

사례 ① — "기능은 다 있던데요"

한 조직이 점검 도구를 골랐습니다. 후보 도구들의 기능 목록을 나란히 놓고 비교해 보니, 다들 "접근성·성능·검색 노출·보안 점검" 항목을 갖추고 있었습니다. 항목마다 동그라미가 고르게 찍혔습니다. 그래서 가장 저렴한 것을 골랐습니다. 합리적인 선택처럼 보였습니다.

막상 돌려보니 문제가 드러났습니다. 위반은 한 무더기 쏟아지는데, 어느 게 급한지 알 수가 없었습니다. 우선순위가 없으니 "다 고쳐야 하나" 싶어 손을 못 대고, 개선 방법도 안 적혀 있어 위반 이름마다 따로 검색해 봐야 했습니다. 기능은 분명 "다 있었"지만, 그 기능이 실제 업무로 이어지지 않았습니다. "검사는 됐는데, 그래서 뭘 해야 하지"에서 멈춘 겁니다. 기능 목록의 동그라미는 맞았지만, 그 동그라미 뒤에 위험도 정리라는 방법이 없었던 거죠.

사례 ② — "AI 준다더니 결과가 흔들려요"

다른 조직은 "AI 분석"이라는 문구를 보고 골랐습니다. AI가 알아서 판단해 준다니 든든해 보였습니다. 그런데 돌려볼 때마다 결과가 조금씩 달랐습니다. 어제는 통과였던 항목이 오늘은 미통과로 나오고, 같은 페이지를 다시 봐도 판정이 흔들렸습니다. AI에 통째로 맡긴 방식이라, 같은 화면을 봐도 판정이 매번 조금씩 달라진 겁니다.

"AI를 준다"는 맞았습니다. 다만 그 AI를 "어떻게 쓰는지"가 빠져 있었습니다. 결과를 못 믿으니 결국 사람이 다시 확인해야 했고, 자동화의 의미가 반쯤 사라졌습니다. 규칙 엔진으로 뼈대를 잡고 AI는 빈칸만 채우는 방법이었다면 겪지 않았을 일입니다.

두 사례의 공통점은 분명합니다. 기능 목록(메뉴판)은 맞았는데, 그 기능을 만드는 방법(레시피)을 안 봤다는 겁니다. 메뉴판에 적힌 "AI 분석"이라는 이름은 같아도, 그 요리를 어떻게 만드는지가 다르면 접시에 나온 결과가 달라집니다. 그래서 두 조직 다 "기능은 다 있는데 쓸모가 없는" 상황에 빠졌습니다.

그리고 이런 일이 생기면, 손해는 생각보다 큽니다. 도구를 도입하는 데 든 예산과 시간은 이미 나갔고, 막상 써 보니 업무로 이어지지 않으니 다시 다른 도구를 알아봐야 합니다. 그 사이 사이트의 문제는 그대로 남아 있습니다. "싼 걸 골랐다"고 생각했는데, 결과적으로는 두 번 사는 셈이 되기도 합니다. 처음 고를 때 기능 목록 너머의 방법을 한 번 더 들여다봤다면 피할 수 있었던 비용입니다. 그래서 도구 선택에서 "방법을 보는 눈"은 단순히 좋은 습관이 아니라, 실제 예산을 아끼는 일이기도 합니다.

한 가지 덧붙이면, 두 사례 다 "속았다"고 말하기도 애매합니다. 후보 도구들이 거짓말을 한 건 아니니까요. 그 도구들도 실제로 "접근성 검사"를 하고, 실제로 "AI 분석"을 줍니다. 기능 목록에 적힌 건 다 사실입니다. 문제는 그 사실이 말해 주지 않는 부분 — 얼마나 깊게 검사하는지, AI를 어떻게 쓰는지 — 이 결과를 갈랐다는 겁니다. 그러니 "거짓 기능을 걸러내라"가 아니라 "참인 기능 뒤의 방법을 확인하라"가 오늘의 교훈입니다.

본론 7 — 방법이 특허로 지켜지면 왜 따라 하기 어렵나

여기서 월요일 이야기와 이어집니다. 위 다섯 질문에 잘 답하는 도구, 즉 방법이 탄탄한 도구는 그 방법을 만드는 데 시간과 시행착오가 들었습니다. 세 시점을 하나의 자로 묶는 것, 두 엔진을 충돌 없이 합치는 것, 위반을 위험도로 정리하는 것 — 이런 건 하루아침에 나오지 않습니다.

그래서 그 방법을 권리(특허)로 정리해 두면, 옆에서 똑같이 따라 만들기가 더 어려워집니다. 기능 이름이야 얼마든지 따라 적을 수 있습니다. "우리도 접근성 검사 됩니다", "우리도 AI 분석 줍니다"라고요. 그런데 그 이름 뒤의 방법까지 그대로 베끼면 권리 문제가 생기고, 베끼지 않으면 같은 깊이의 결과가 안 나옵니다. 이게 월요일에 말씀드린 "레시피를 지킨다"의 실제 의미입니다. ViewCheck가 다섯 건을 특허로 출원해 둔 것도 이 지점입니다.

다섯 건이 다루는 방법을 오늘의 질문과 이어 보면 이렇습니다. 코드 뒤가 아니라 화면에 보이는 요소를 시각적으로 분석하고 감지·검증하는 방법(질문 ①·⑤), 여러 페이지를 함께 보고 비교하는 방법(질문 ②), 위반을 위험도로 등급화하는 방법(질문 ④) 등이 그 방법들입니다. "기능 이름"이 아니라 "그 기능을 만드는 방법"을 권리로 정리해 둔 데 차별점이 있습니다.

왜 방법을 권리로 지켜야 하느냐고 물으실 수 있습니다. 기능 이름은 원래 누구나 쓸 수 있는 말입니다. "접근성 검사"라는 이름을 특정 회사가 독차지할 수는 없습니다. 그건 당연합니다. 그런데 그 이름을 결과로 바꾸는 구체적인 방법 — 세 시점을 어떻게 하나로 묶는지, 두 엔진을 어떤 순서로 합치는지, 위반에 어떻게 무게를 매기는지 — 은 직접 만들어 낸 고유한 절차입니다. 이걸 아무나 그대로 가져다 쓰게 두면, 시간과 시행착오를 들여 만든 쪽만 손해입니다. 그래서 그 방법을 권리로 정리해, 이름은 공용으로 두되 방법은 지키는 겁니다. 이게 겉보기 기능과 방법론을 구분해서 다루는 이유이기도 합니다.

다만 여기서 솔직하게 짚어둘 게 있습니다. 특허가 있다고 결과가 자동으로 좋아지는 건 아닙니다. 특허는 방법을 보호하는 장치이지, 품질 보증서가 아닙니다. 다섯 질문에 잘 답하느냐는 그 방법이 실제로 잘 작동하느냐로 결정되는 것이고, 특허는 그 방법을 남이 함부로 가져가지 못하게 지키는 것입니다. 그리고 지금은 등록이 아니라 출원 단계입니다. "등록특허"가 아니라 "출원 기술"로 정확히 표기하는 게 맞습니다. 그래서 "특허가 있으니 믿으세요"가 아니라, "이 방법들을 직접 만들고 지켜두었으니, 직접 돌려보고 판단하시라" 정도로 받아들여 주시면 됩니다.

본론 8 — 그래도 기능 목록은 쓸모가 있다 (1차 거르개)

오해는 말아 주십시오. "기능 목록 비교가 다 쓸모없다"는 게 아닙니다. 기능 목록은 1차 거르개로는 아주 유용합니다. 아예 그 기능 자체가 없는 도구를 걸러내는 데는 좋습니다. "접근성 점검 기능이 애초에 없다"면 후보에서 빼면 되니까요. 이 1차 거르개 없이 처음부터 다섯 질문을 던지는 건 비효율적입니다.

다만 기능 목록은 딱 거기까지입니다. 후보를 몇 개로 추린 다음에는, 앞서의 다섯 질문으로 "방법"을 들여다봐야 합니다. 그리고 제일 확실한 건, 직접 돌려보는 겁니다. 우리 사이트나 비슷한 공공 사이트를 후보 도구에 넣어보고, 결과가 쓸 만한지·우선순위가 납득되는지·개선안이 실용적인지를 눈으로 보는 것. 기능 목록 표 백 개보다 데모 한 번이 낫습니다.

ViewCheck도 마찬가지입니다. "기능 있어요"를 믿어 달라고 하기보다, 직접 돌려보고 위 다섯 질문으로 따져보시길 권합니다. 그게 월요일부터 말씀드린 "방법으로 판단하라"는 겁니다. 방법이 탄탄하면 데모에서 드러나고, 겉만 그럴듯하면 데모에서 무너집니다. 데모는 기능 목록이 숨기는 것을 보여주는 가장 정직한 자리입니다.

한 가지 덧붙이면, 데모를 볼 때도 오늘의 다섯 질문을 손에 쥐고 보시면 좋습니다. 그냥 "오, 결과가 많이 나오네"에서 끝내지 마시고, "이 결과가 급한 순서로 정리돼 있나", "이미지로 만든 요소도 잡았나", "다시 돌리면 같게 나오나"를 하나씩 확인하시는 겁니다. 그러면 겉보기 화면의 화려함에 휩쓸리지 않고, 그 밑의 방법을 볼 수 있습니다.

그리고 데모를 볼 때 한 가지만 더 챙기시길 권합니다. 메인 페이지만 넣지 마시라는 겁니다. 메인은 대개 가장 잘 관리되는 얼굴이라, 어떤 도구에 넣어도 그럭저럭 나옵니다. 진짜 차이는 사용자가 실제로 업무를 보는 안쪽 페이지 — 신청·조회·안내 — 에서 드러납니다. 그런 페이지를 여러 개 넣어 보면, 얕은 방법과 깊은 방법의 차이가 확 벌어집니다. 결과가 많은 페이지에서도 흔들리지 않고 위험도 있게 정리되는지, 페이지 사이의 일관성까지 보는지를 눈으로 확인하시는 겁니다. 이 한 가지만 챙겨도 데모의 정직함이 크게 올라갑니다.

그래서 ViewCheck는

ViewCheck는 위 다섯 질문에 답하도록 만들어졌습니다. 코드만이 아니라 화면까지 보고, 한 페이지가 아니라 사이트 전체를 보고, AI를 토대 위에서 빈칸만 채우게 쓰고, 위반에 위험도와 개선안을 붙이고, 같은 결과가 재현되게 합니다. 그 뒷단에서 돌아가는 게 오늘 말씀드린 세 방법입니다. 세 시점을 846개 규칙 하나의 자로 교차 판정하고, 두 엔진을 질서 있게 합치고, 결과를 위험도로 정리하는 것.

거창하게 들릴 수 있는데, 결국 "기능이 있다"가 아니라 "기능을 이렇게 만들었다"를 보여드리려는 겁니다. URL 분석 하나만 돌려도 결과가 스무 개가 넘는 영역으로 펼쳐지는데, 그 스무 개가 넘는 영역이 다 이 세 방법 위에 서 있습니다. 접근성도, 성능도, 검색 노출도, 보안도, 반응형도 — 저마다 다른 화면으로 보이지만, 그 밑을 받치는 방법은 하나로 이어져 있습니다.

이 스무 개가 넘는 영역을 어떤 순서로 읽고, 그 결과를 어떻게 카테고리로 묶어 보는지는 다음 달들에서 하나씩 깊게 다룰 예정입니다. 예를 들어 위반을 위험도로 나누는 방법은 4개월차에서 본격적으로 파고, 결과를 몇 개의 카테고리로 정리해 읽는 법은 5개월차에서 다룹니다. 오늘은 그 모든 영역의 밑을 받치는 "세 방법"이 무엇인지, 그리고 그것이 왜 겉보기 기능과 다른 층위의 이야기인지까지만 짚었습니다. 밑을 받치는 방법을 먼저 이해하고 나면, 각 영역의 화면을 읽을 때 "이 결과가 어떤 방법에서 나온 것인가"가 보이기 시작합니다.

세 시점(설계·운영·맥락)이 하나의 846규칙 자로 모이고, 그 아래 두 엔진(구조 판정·시각 감지)이 질서 있게 결합되어, 마지막에 위험도 등급으로 정리되는 흐름을 한 장에 담은 개념 도식 (Gemini 1:1)

그 방법의 핵심을 다섯 건의 특허로 지켜둔 것도 그래서입니다. 겉으로 드러나는 기능 이름은 누구나 따라 적을 수 있지만, 그 이름을 결과로 바꾸는 방법은 직접 만들어 지켜두었습니다. 다시 말씀드리지만, 이건 "특허가 있으니 최고"라는 자랑이 아닙니다. "이 방법들을 직접 만들었고, 그래서 다섯 질문에 답할 토대가 있다"는 한 가지 신호일 뿐입니다. 판단은 직접 돌려보시고 하시면 됩니다.

🔐 특허로 지키는 부분

오늘 본 세 방법 — 세 시점을 하나의 자로 교차 판정하는 것, 두 엔진을 질서 있게 합치는 것, 결과를 위험도로 정리하는 것 — 은 ViewCheck가 출원한 다섯 건의 특허와 직접 맞닿아 있습니다. 코드 뒤가 아니라 화면에 보이는 요소를 시각적으로 분석·감지·검증하는 방법, 여러 페이지를 함께 보고 비교하는 방법, 위반을 위험도로 등급화하는 방법 등이 그 방법들입니다. 기능 이름 하나 따라 적는 것과, 그 이름을 이런 결과로 바꾸는 방법을 만드는 것은 전혀 다른 층위의 일입니다. 후자를 권리로 정리해 둔 데 차별점이 있습니다.

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

마무리

오늘은 "기능은 베껴도 방법론은 못 베낀다"는 말이 실제로 어떻게 드러나는지를 봤습니다. 접근성 검사도, AI 분석도, 리포트도, 이름은 같은데 그 밑의 방법이 다르면 결과가 갈립니다. 기능 목록(메뉴판)이 같아도, 그 기능을 만드는 방법(레시피)이 다르면 접시에 나온 결과가 달라집니다.

ViewCheck가 방법의 핵심으로 삼은 것은 세 가지였습니다. 세 시점을 846개 규칙 하나의 자로 교차 판정하고, 두 엔진을 질서 있게 합치고, 결과를 위험도로 정리하는 것. 이 세 방법이 결과의 깊이를 만들고, 그 방법의 핵심을 다섯 건의 특허로 지켜두었습니다. 화면과 버튼 같은 겉보기 기능은 이 위에 얹힌 표면일 뿐입니다.

오늘 딱 하나만 가져가신다면 이 문장이면 좋겠습니다. "기능 목록이 같다고 결과가 같은 게 아니다." 메뉴판의 이름은 같아도 레시피가 다르면 접시가 다릅니다. 도구를 고를 때 메뉴판만 보고 고르면, 접시에 무엇이 나올지는 돌려보기 전까지 모릅니다. 그러니 메뉴판 너머의 레시피 — 코드냐 화면이냐, 한 페이지냐 전체냐, AI를 어떻게 쓰느냐, 우선순위가 붙느냐, 재현되느냐 — 를 확인하시고, 가장 확실하게는 직접 접시를 받아 보시는 겁니다.

그러니 도구를 고르실 때는 기능 목록 너머를 봐 주십시오. 다섯 질문 — 코드냐 화면이냐, 한 페이지냐 전체냐, AI를 어떻게 쓰느냐, 우선순위와 개선안이 붙느냐, 재현되느냐 — 으로 방법을 들여다보고, 가장 확실하게는 직접 돌려보는 것. 그 방법의 핵심을 직접 만들고 지켜둔(출원 중) 도구라면, 그 다섯 질문에 답할 토대가 있을 겁니다.

이번 주 금요일에는 이 방법 이야기를 마무리하면서, "다섯 건의 특허가 세 시점(설계·운영·맥락)에 어떻게 걸치는지"를 한 장의 지도로 정리하겠습니다. 세 시점과 다섯 특허가 어떻게 맞물리는지 한눈에 보고, 다음 달부터는 각 영역을 하나씩 깊게 파 들어가겠습니다. 오늘도 끝까지 읽어주셔서 고맙습니다. 금요일에 지도로 이어가겠습니다.

krds.viewcheck.co.kr