두 엔진의 분업과 협업 — 코드 보는 엔진, 화면 보는 엔진

들어가며 — 판단 시점의 문을 여는 이야기

지난주까지 웹 품질을 보는 세 가지 시점을 한 바퀴 돌았습니다. 만들기 전에 보는 설계 시점, 만든 뒤에 보는 운영 시점, 그리고 그 위에서 무엇부터 손댈지를 정하는 판단 시점. 그중 설계 시점(Figma 분석)을 지난주에 다뤘고, 그 앞선 주에는 운영 시점(URL 분석)을 봤습니다. 이번 주는 마지막 남은 시점, 바로 판단 시점의 문을 엽니다.

그런데 판단 시점 이야기를 제대로 하려면, 그 밑에 깔린 구조부터 짚고 가야 합니다. ViewCheck가 사이트 하나를 분석할 때, 실제로는 성격이 다른 두 개의 엔진이 함께 일합니다. 하나는 화면 뒤의 코드를 읽어 판정하는 규칙 엔진이고, 다른 하나는 실제로 그려진 화면(스크린샷)을 보고 무엇이 있는지 감지하는 시각 AI 엔진입니다. 오늘은 이 두 엔진이 어떻게 나눠 일하고, 어떻게 협업해서 하나의 결과로 합쳐지는지를 정리하겠습니다.

핵심 질문은 이것입니다. "왜 엔진이 둘이나 필요할까요? 하나로 다 하면 안 될까요?" 답은 지난 몇 주에 이미 깔려 있습니다. 코드만 보면 화면을 놓치고(이미지로 만든 버튼 같은 것들), 화면만 보면 구조를 놓칩니다(코드 속 라벨 같은 것들). 두 엔진은 애초에 보는 대상이 달라서, 하나로는 절반밖에 못 봅니다. 그래서 둘이 나눠 보고 합치는 것입니다. 사람으로 치면, 코드를 잘 읽는 사람과 화면을 잘 보는 사람이 같은 사이트를 같이 점검하는 셈입니다.

오늘 글은 이 둘이 각각 무엇을 잘하는지, 어떤 순서로 일하는지, 그리고 합칠 때 어떤 규칙을 지키는지를 차근차근 풉니다. 조금 구조적인 이야기라 천천히 가겠습니다. 이번 달은 세 가지 방법을 개요로 훑는 달이니, 깊은 기술은 다음 달 이후로 미루고 "둘이 왜, 어떻게 나눠 일하는가"의 큰 틀에 집중합니다. 이 틀이 잡히면, 왜 ViewCheck가 엔진을 둘로 나눴는지, 그리고 왜 그 편이 "하나짜리"보다 나은지가 보입니다.

한 가지 미리 말씀드릴 것이 있습니다. 오늘 이야기는 지난 몇 주 동안 깔아온 큰 그림의 한 조각입니다. 첫 주에 "한 관점으로는 절반만 보인다"고 했고, 그다음 주들에서 운영과 설계 시점을 봤습니다. 오늘은 그 세 번째 시점(판단) 안에서 "코드와 화면을 어떻게 같이 보는가"를 푸는 것입니다. 돌이켜보면 여태 드린 이야기는 결국 하나였습니다. 한 관점으로는 절반만 보이니, 여러 관점을 나눠 보고 합치자는 것. 두 엔진 이야기는 그 원리를 분석 엔진 수준에서 그대로 구현한 사례입니다.

미리 한 가지 오해를 풀고 가겠습니다. "엔진이 둘"이라고 하면 흔히 "같은 일을 두 번 해서 서로 대조하는 이중 점검"을 떠올리십니다. 그런데 여기서 말하는 두 엔진은 그런 이중 점검이 아닙니다. 같은 일을 두 번 하는 것이 아니라, 아예 다른 일을 나눠서 하는 것입니다. 코드 엔진은 코드로만 볼 수 있는 것을 보고, 화면 엔진은 화면으로만 볼 수 있는 것을 봅니다. 겹치는 영역이 아니라 보완하는 영역인 것이지요. 그래서 둘의 결과를 합쳐도 "누가 맞나"를 두고 다투는 구조가 아니라, "네가 못 본 걸 내가 봤다"고 서로 채워주는 구조입니다. 이 차이를 먼저 잡아두면 오늘 이야기가 훨씬 선명하게 들어옵니다.

본론 1 — 두 엔진은 보는 게 다르다

먼저 두 엔진이 각각 무엇을 보는지부터 정리하겠습니다. 이름은 편의상 "코드 보는 엔진"과 "화면 보는 엔진"으로 부르겠습니다.

코드 보는 엔진 (규칙 엔진)

첫 번째 엔진은 화면 뒤의 구조, 즉 코드를 봅니다. 웹페이지는 우리가 보는 화면 뒤에 그 화면을 만들어내는 코드(HTML 구조)가 있습니다. 규칙 엔진은 그 코드를 읽어서 판정합니다. "이 버튼에 이름(라벨)이 붙어 있는가", "제목 구조(h1부터 h6까지)가 논리적으로 짜여 있는가", "이 입력창에 설명이 제대로 연결돼 있는가" 같은 것들을 봅니다.

이 엔진이 잘하는 것은 명확하고 빠른 판정입니다. 코드는 기계가 읽기 좋은 형태라서, "있다/없다", "맞다/틀리다"가 딱 떨어집니다. 그래서 1초에서 3초 남짓이면 846개 규칙을 한 번 훑습니다. 빠르고, 일관되고, 몇 번을 돌려도 같은 결과가 나옵니다. 사람이 손으로는 도저히 감당 못 하던 규모와 일관성을, 이 엔진이 해결합니다. 분석의 뼈대를 빠르게 세우는 역할입니다.

여기서 846개 규칙이라는 게 무엇인지 잠깐 짚겠습니다. KRDS(정부 디지털 서비스의 디자인 기준)를 자동 판정 항목으로 풀어놓은 것이 846개인데, 성격에 따라 네 묶음으로 나뉩니다. 색·타이포·간격 같은 디자인 스타일(DS)이 120개, 버튼·폼·표 같은 컴포넌트(CP)가 446개, 폼 구조나 오류 처리 같은 기본 패턴(BP)이 108개, 검색·로그인·신청 같은 서비스 패턴(SP)이 172개입니다. 이 네 묶음을 더하면 정확히 846개입니다. 규칙 엔진은 이 846개를 코드 기준으로 한 항목씩 판정합니다. 아래 화면이 그 코드 기반 판정이 카테고리별로 어떻게 정리되는지를 보여주는데, 규칙 하나하나가 통과·미통과로 떨어지는 것이 코드 엔진의 1차 결과물입니다.

KRDS 규칙 검증 결과에서 컴포넌트 규칙들이 통과·미통과·해당없음으로 상세하게 판정된 목록 화면. 코드 엔진이 만든 1차 판정 뼈대가 규칙별로 딱딱 떨어지는 모습 (기관명·도메인 블러)

다만 이 엔진에게도 못 보는 영역이 있습니다. "코드에 드러나지 않는 것"입니다. 이미지로 만든 버튼, 시각적으로만 구분되는 위계, 색 대비가 실제 화면에서 주는 느낌 같은 것들이지요. 코드만 읽으니, 코드에 안 적힌 것은 알 도리가 없습니다. 이것이 규칙 엔진 단독의 한계이고, 바로 여기서 두 번째 엔진이 필요해집니다.

이 한계를 조금 더 구체적으로 그려보겠습니다. 예를 들어 어떤 버튼을 개발자가 정식 버튼 태그가 아니라 이미지 한 장으로 만들어 얹어두었다고 하겠습니다. 화면에서는 누가 봐도 버튼이지만, 코드로 읽으면 그냥 그림 파일 하나입니다. 규칙 엔진은 그 자리에서 "버튼이 없다"가 아니라 "버튼에 대해 판정할 것이 없다", 즉 해당없음(N/A)으로 처리합니다. 코드에 버튼이 안 적혀 있으니 버튼 규칙을 적용할 대상 자체가 없다고 보는 것이지요. 문제는 여기서 생깁니다. 그 자리에 실제로는 버튼이 있고, 게다가 이름도 없어서 화면을 못 보는 사용자에게는 아무것도 아닌 요소인데, 코드만 보는 엔진은 이 위반을 "해당없음"이라는 빈칸으로 남겨버립니다. 위반이 없어서 통과가 아니라, 못 봐서 빈칸인 것입니다. 이 빈칸이 뒤에서 계속 이야기할 "가짜 N/A"이고, 두 번째 엔진이 존재하는 가장 큰 이유입니다.

화면 보는 엔진 (시각 AI 엔진)

두 번째 엔진은 실제로 그려진 화면, 즉 스크린샷을 봅니다. 사람이 눈으로 화면을 훑듯, 이미지를 보고 "여기 버튼이 있네", "이건 카드 모양이네", "이 영역은 표처럼 보이네" 하고 인식합니다. 코드가 아니라 생김새로 판단하는 것입니다.

이 엔진이 잘하는 것은 코드에 드러나지 않는 시각적인 요소입니다. 이미지로 만든 버튼도 화면에서는 버튼처럼 보이니까 감지하고, 요소들이 화면상에서 어떻게 배치돼 있는지, 어떤 것이 어떤 것과 시각적으로 묶여 있는지를 봅니다. 사용자가 실제로 마주하는 것은 코드가 아니라 화면이므로, 화면을 보는 이 엔진이 "사용자 관점"에 가장 가깝습니다.

화면 엔진의 강점을 조금 더 풀면 이렇습니다. 코드가 어떻게 짜여 있든, 사용자는 화면에 그려진 것을 봅니다. 그러니 화면을 보는 엔진은 "사용자 경험"을 가장 직접적으로 봅니다. 코드로는 완벽한데 화면에서는 두 요소가 겹쳐 보인다면, 사용자에게는 겹쳐 보이는 것이 현실입니다. 화면 엔진은 그 현실을 잡습니다. 그래서 코드 엔진이 "기준대로 만들어졌는가"를 본다면, 화면 엔진은 "실제로 그렇게 보이는가"를 봅니다. 미묘하지만 중요한 차이입니다. 만들어진 것과 보이는 것이 언제나 같지는 않으니까요. 이것은 설계 시점에서 봤던 "도면과 결과물은 다를 수 있다"는 이야기의 엔진 버전이기도 합니다.

다만 화면 엔진은 코드 엔진만큼 빠르거나 명확하지는 않습니다. 화면을 인식하는 일은 코드를 읽는 일보다 무겁고, "이게 정말 버튼이 맞는가"에는 확신도가 따라붙습니다. 그래서 모든 판정을 이 엔진에게만 맡기면 느려지고 결과가 들쑥날쑥할 수 있습니다. 화면 인식이라는 무거운 작업을, 꼭 필요한 곳에만 써야 하는 이유입니다. 이 점은 뒤에서 순서 이야기를 할 때 다시 짚겠습니다.

둘은 상호 보완이다

정리하면 이렇습니다. 코드 엔진은 빠르고 명확하지만 시각을 못 봅니다. 화면 엔진은 시각을 보지만 무겁고 덜 명확합니다. 공교롭게도 서로의 약점이 정확히 상대의 강점입니다. 그래서 둘을 하나로 뭉치기보다, 나눠서 각자 잘하는 일을 시키고 결과를 합치는 편이 낫습니다. 첫 주에 "세 시점은 경쟁이 아니라 분업"이라고 말씀드렸는데, 두 엔진도 똑같이 분업입니다.

비유하자면 건물 점검에 두 전문가가 붙는 것과 비슷합니다. 한 명은 설계도면과 자재 명세서(코드)를 꼼꼼히 봅니다. 다른 한 명은 실제로 지어진 건물을 눈으로 둘러봅니다(화면). 도면만 보면 "실제로 어떻게 보이는지"를 알 수 없고, 눈으로만 보면 "벽 안에 무엇이 들었는지"를 알 수 없습니다. 둘이 같이 봐야 안과 밖이 다 잡힙니다. 웹도 똑같습니다. 코드(안)와 화면(밖)을 둘 다 봐야 합니다. 한 명에게 둘 다 시키는 것보다, 각 분야 전문가가 나눠 보고 결과를 합치는 편이 빠르고 정확합니다.

왼쪽에서 코드 구조 트리를 빠르고 정확하게 읽는 엔진과, 오른쪽에서 그려진 화면 이미지를 보며 이미지로 된 버튼을 잡아내는 엔진, 두 출력이 화살표로 하나의 결과 시트로 합쳐지는 개념 도식 (Gemini 1:1)

한 가지 덧붙이면, 이 분업은 "정확도"만을 위한 것이 아닙니다. 뒤에서 자세히 보겠지만, 화면 인식은 코드 읽기보다 시간도 자원도 더 듭니다. 그래서 두 엔진을 나눠 쓰면 정확도와 효율을 동시에 챙길 수 있습니다. 값싸고 빠른 코드 판정으로 대부분을 처리하고, 무겁고 정밀한 화면 인식은 꼭 필요한 곳에만 쓰는 것이지요. 이 "정확도와 효율을 함께 잡는다"는 것이 두 엔진 구조의 진짜 이득인데, 그 얼개가 다음에 볼 "순서"에 담겨 있습니다.

본론 2 — 어떤 순서로 일하나

두 엔진이 동시에 마구잡이로 일하는 것은 아닙니다. 효율을 위해 순서가 있습니다. 이 순서를 이해하면, 왜 이 구조가 빠르면서도 촘촘한지가 보입니다.

1단계: 규칙 엔진이 뼈대를 빠르게 세운다

가장 먼저 규칙 엔진이 846개 규칙을 빠르게 훑습니다. 코드로 명확히 답이 나오는 항목은 여기서 거의 다 처리됩니다. 통과·미통과가 확정되고, 코드로는 도저히 볼 수 없는 것은 해당없음(N/A)으로 남습니다. 이것이 1차 뼈대입니다. 빠르니까(1초에서 3초) 먼저 돌려서 큰 틀을 잡는 것입니다.

이 단계가 끝나면 상당수의 N/A가 남습니다. 그중에는 정당한 N/A(그 페이지에 정말 해당 요소가 없어서 판정할 것이 없는 경우)도 있고, 이른바 "가짜 N/A"(화면에는 있는데 코드로 못 봐서 빠진 경우)도 섞여 있습니다. 이 둘을 갈라내는 것이 다음 단계의 몫입니다.

이 두 종류의 N/A를 구별하는 것이 왜 중요한지 짚고 넘어가겠습니다. 정당한 N/A는 문제가 아닙니다. 예를 들어 로그인 화면에 표가 없으면 표 관련 규칙은 당연히 해당없음이고, 이건 정직한 판정입니다. 그 페이지에 없는 것을 억지로 있다고 할 수는 없으니까요. 반면 가짜 N/A는 문제입니다. 화면에는 분명히 있는데 코드로 못 봐서 빠진 것이라, 실제로는 위반일 수 있는 것이 조용히 "해당없음"으로 묻혀버립니다. 만약 이 둘을 구별하지 않고 N/A를 전부 "괜찮은 것"으로 뭉뚱그리면, 사이트가 실제보다 좋아 보이는 착시가 생깁니다. 위반이 될 뻔한 것들이 빈칸 뒤에 가려지니까요. 그래서 규칙 엔진이 세운 뼈대에는 이 착시의 위험이 남아 있고, 그 위험을 걷어내는 것이 바로 화면 엔진이 다음에 할 일입니다.

2단계: 화면 엔진이 빈칸을 본다

그다음 화면 엔진이 들어옵니다. 그런데 여기가 똑똑한 부분인데, 화면 엔진이 모든 것을 다 보는 것이 아닙니다. 규칙 엔진이 이미 확정한 항목은 건드리지 않고, N/A로 남은 빈칸 위주로 화면을 봅니다. "코드로는 버튼 없음(N/A)이었는데, 화면에는 정말 버튼이 있는가?"를 확인하는 것이지요.

이렇게 하면 효율적입니다. 화면 인식은 무거운 작업이라, 모든 규칙을 다 화면으로 보면 분석 한 번이 너무 오래 걸립니다. 대신 코드로 이미 끝난 항목은 빼고 빈칸만 화면으로 보면, 빠르면서도 빈칸이 채워집니다. 규칙 엔진이 큰 그물로 먼저 거르고, 화면 엔진이 그 그물을 빠져나간 것만 촘촘히 줍는 식입니다.

왼쪽에서 오른쪽으로 흐르는 컨베이어 벨트 같은 3단계 파이프라인. 1단계 코드 엔진이 빈칸이 있는 뼈대 격자를 빠르게 세우고, 2단계 화면 엔진이 그 빈칸을 채우고, 3단계에서 판단 기능이 그 위에 우선순위와 개선 메모를 얹는 개념 도식 (Gemini 1:1)

생각해보면 이것은 사람이 일하는 방식과도 닮았습니다. 점검을 두 명이 한다면, 한 명이 빠르게 명확한 것부터 쫙 처리하고, 다른 한 명은 "이건 애매하니 자세히 봐 달라"고 넘겨받은 것만 집중해서 봅니다. 둘 다 모든 것을 처음부터 다 보면 시간 낭비니까요. 빠른 1차 거르기와 남은 것의 정밀 확인. 이 분업이 사람 팀에서도, 두 엔진 사이에서도 똑같이 효율적입니다. 무거운 작업(화면 인식)을 꼭 필요한 데만 쓰는 것이 핵심입니다.

3단계: 합치고, 그 위에 판단을 얹는다

두 엔진의 결과를 합치면, 코드로 본 것과 화면으로 채운 것이 더해져 더 촘촘한 판정이 됩니다. 규칙 엔진 혼자였을 때보다 판정된 항목의 비율이 올라가고, N/A는 줄어듭니다. 그리고 그 위에 판단 기능이 우선순위를 매기고 개선안을 더합니다. 코드로 뼈대, 화면으로 빈칸, 그 위에 판단. 이 세 단계가 이어지는 것입니다. 각 단계가 앞 단계의 결과를 받아서 다음으로 넘기는, 일종의 컨베이어 벨트처럼 흐릅니다. 그래서 사람이 중간중간 손으로 결과를 옮기거나 합칠 필요 없이, 한 번 돌리면 끝까지 이어집니다.

이 "판단을 얹는다"는 대목이 바로 이번 주가 여는 판단 시점의 이야기입니다. 두 엔진이 촘촘한 판정을 만들어내면, 그 위에서 "이 위반이 우리 기관 상황에서 얼마나 급한가", "무엇부터 손대야 하는가"를 정리하는 단계가 얹힙니다. 그 판단 단계 자체가 무엇인지는 이번 주 수요일 글에서 본격적으로 풀고, 그 판단이 실제로 어떻게 결과를 읽고 개선안까지 내놓는지는 금요일 글에서 이어가겠습니다. 오늘은 그 판단이 딛고 서는 토대, 즉 두 엔진의 협업 구조를 잡는 자리입니다.

왜 이 순서가 중요한가

순서를 거꾸로 하면 비효율적입니다. 화면 엔진으로 전부 다 본 다음에 코드로 확인한다면, 무거운 작업을 다 해놓고 나서 거르는 셈이라 느립니다. 코드로 먼저 빠르게 거르고, 남은 빈칸만 화면으로 보는 편이 빠르면서도 빠짐이 없습니다. "값싸고 빠른 것을 먼저, 무겁고 정밀한 것은 필요한 데만." 이것이 두 엔진을 효율적으로 쓰는 핵심 원칙입니다.

이 원칙이 실무에서 왜 중요한지는 규모를 떠올리면 분명해집니다. 공공 사이트는 페이지가 수십에서 수백 장에 이르는 경우가 많습니다. 한 페이지당 846개 규칙을 판정하는데, 만약 그 전부를 무거운 화면 인식으로 처리한다면 사이트 한 곳을 보는 데만 엄청난 시간과 비용이 듭니다. 그런데 대부분을 값싼 코드 판정으로 처리하고 화면은 빈칸만 본다면, 같은 규모라도 훨씬 가볍게 끝납니다. 페이지가 많아질수록 이 순서의 이득이 커집니다. 다중 페이지 분석의 구체적인 원리와 집계 방식은 6개월차(다중 페이지 분석)에서 깊게 다루는데, 오늘은 "코드로 먼저 거르는 순서가 규모에 강하다" 정도만 잡고 가시면 됩니다.

본론 3 — 합칠 때 지키는 규칙

두 엔진의 결과를 합치는 일은 단순히 더하는 것이 아닙니다. 잘못하면 충돌이 나서 오히려 결과가 흔들립니다. 그래서 합칠 때 지키는 규칙이 필요합니다. 네 가지로 정리하겠습니다.

규칙 ① 코드가 확정한 건 뒤집지 않는다

규칙 엔진이 "이 버튼에는 라벨이 없으니 미통과"라고 명확히 판정한 항목은, 화면 엔진이나 판단 기능이 "그래도 괜찮아 보이는데" 하고 바꾸지 않습니다. 코드로 확실한 것은 확실한 것이니까요. 화면 엔진은 어디까지나 "코드가 못 본 빈칸"을 채우는 역할이지, 코드의 판정을 검열하는 역할이 아닙니다.

왜 이것이 중요한가 하면, 이 규칙을 안 지키면 결과가 들쑥날쑥해지기 때문입니다. 같은 사이트를 돌렸는데 어제는 통과, 오늘은 미통과가 되면, 사람 점검에서 봤던 그 기준 흔들림이 이번에는 자동 분석에서 재현됩니다. 자동화의 가장 큰 장점이 일관성인데, 그 장점이 무너지는 것이지요. 그래서 "확정된 것은 고정"이라는 울타리가 일관성을 지킵니다. 두 번 돌리면 같은 답이 나와야 그 결과를 근거로 쓸 수 있습니다.

규칙 ② 화면 엔진은 빈칸만 채운다

화면 엔진이 채우는 것은 N/A로 남은 빈칸입니다. 코드로는 "버튼 없음"이었는데 화면에는 버튼이 있으면, 그 빈칸을 "버튼 있음, 그리고 이러이러하니 판정"으로 채웁니다. 빈칸을 채우는 것이지, 이미 채워진 칸을 다시 쓰는 것이 아닙니다. 이렇게 역할을 명확히 나누면 두 엔진이 같은 항목을 두고 부딪히지 않습니다. 규칙 ①과 ②는 사실 한 몸입니다. "코드가 채운 칸은 코드 것, 빈칸만 화면 것"이라는 담당 구역이 분명하니, 서로의 영역을 넘보지 않습니다.

규칙 ③ 확신도를 같이 단다

화면 인식에는 확신도가 따라붙습니다. "이것이 버튼일 확률이 높다"와 "버튼인지 애매하다"는 다릅니다. 확신이 높은 것은 판정에 반영하고, 애매한 것은 함부로 단정하지 않습니다. 확신 없는 것을 억지로 채워 넣으면 오히려 부정확해지니까요. 그래서 확신도로 걸러서 믿을 만한 것만 채우고, 애매한 것은 솔직하게 N/A로 남깁니다.

이 대목이 특히 중요합니다. "빈칸을 채운다"는 말이 "빈칸을 무조건 다 메운다"는 뜻이 아니기 때문입니다. 화면에 뭔가 있긴 한데 그것이 버튼인지 장식인지 확신이 서지 않으면, 우겨서 "버튼 있음"으로 채우지 않습니다. 확신이 없으면 없다고 두는 것이지요. 이렇게 하는 이유는 단순합니다. 없는 것을 지어내지 않기 위해서입니다. 화면 엔진이 애매한 것까지 다 채워버리면, 실제로는 없는 위반을 만들어내거나 실제로는 없는 컴포넌트를 있다고 우기게 됩니다. 그것은 분석이 아니라 창작입니다. 그래서 "증거가 확실할 때만 채우고, 애매하면 N/A로 남긴다"는 원칙이 결과의 신뢰를 지킵니다. 감지 못 한 것을 억지로 지어내지 않으니, 화면 엔진이 채운 빈칸은 그만큼 믿을 만합니다.

여기서 짚고 싶은 것은, 이 절제가 겉으로는 손해처럼 보인다는 점입니다. 애매한 것을 다 채우면 판정된 항목 수가 늘어나 보이고, 빈칸이 줄어드니 겉보기엔 더 촘촘한 분석처럼 느껴집니다. 그런데 그 늘어난 판정 중에 틀린 것이 섞여 있으면, 결과 전체를 못 믿게 됩니다. 담당자가 그 결과를 보고 멀쩡한 요소를 고치느라 시간을 쓰거나, 반대로 잘못된 "통과" 판정을 믿고 진짜 문제를 방치하게 되니까요. 그래서 화면 엔진은 "많이 채우는 것"보다 "확실한 것만 채우는 것"을 택합니다. 숫자를 예쁘게 만드는 대신, 채운 것 하나하나를 믿을 수 있게 만드는 쪽을 고른 것이지요. 증거에 근거해서만 판정하고, 증거가 없으면 솔직히 못 봤다고 남기는 이 태도가, 결국 결과를 오래 신뢰받게 만듭니다.

규칙 ④ 근거를 남긴다

합친 결과의 각 판정에는 "왜 이렇게 판정했는가"가 따라붙어야 합니다. "코드에 라벨이 없어서 미통과", "화면에서 버튼이 감지돼서 판정", "KRDS 몇 번 규칙 위반" 같은 근거 말입니다. 근거가 있어야 사람이 검토하고 믿을 수 있습니다. 근거 없는 판정은 결국 추측일 뿐입니다.

근거가 어느 엔진에서 나왔는지까지 함께 있으면 더 좋습니다. "이 판정은 코드 기반", "이것은 화면 인식 기반(확신도 높음)"처럼요. 그러면 사람이 검토할 때 판단이 쉬워집니다. "코드 기반이면 거의 확실하겠구나", "화면 기반이면 한 번 더 눈으로 볼까" 하고 나눠서 대할 수 있습니다. 어느 엔진이 어떤 근거로 판정했는지가 투명하면, 결과를 더 잘 믿거나 적절히 의심할 수 있습니다. 블랙박스처럼 "그냥 위반이래"가 아니라 "코드에 라벨이 없어서, 라는 이유로 위반"이면 검토도 빠르고 고치기도 쉽습니다.

이 네 규칙을 지키면 두 엔진의 결과가 충돌 없이 일관되게 합쳐집니다. 그냥 두 결과를 섞는 것이 아니라, "코드 우선, 화면은 빈칸만 보강, 확신도로 거르고, 근거를 단다"는 질서가 있는 것입니다. 아래는 그 두 엔진 결과가 합쳐진 뒤, KRDS 표준 대비 어디가 얼마나 차이 나는지를 비교해 보여주는 화면입니다. 코드로 본 것과 화면으로 채운 것이 하나의 비교표로 정리됩니다.

AI 종합보고서의 KRDS 비교분석 표준대비 화면. 두 엔진의 판정이 합쳐진 결과를 KRDS 표준과 나란히 비교해 어디가 얼마나 차이 나는지 보여주는 표준대비 탭 (기관명·도메인 블러)

왜 "섞기"가 아니라 "질서"가 필요한가

두 엔진의 결과를 아무 규칙 없이 그냥 합치면 오히려 더 혼란스러워집니다. 같은 버튼을 두고 코드 엔진은 "통과", 화면 엔진은 "애매함"이라고 하면, 둘 중 무엇을 따라야 할까요? 질서가 없으면 그때그때 다르게 처리돼서 결과를 믿을 수 없게 됩니다. 그래서 "코드가 확정한 것은 코드를 따른다, 화면은 코드가 비운 데만 본다"는 우선순위가 미리 정해져 있어야 합니다. 이 우선순위 덕분에 두 엔진이 같은 것을 두고 다투지 않습니다. 각자 담당 구역이 명확하니까요. 협업이 잘 되는 팀이 "누가 무엇을 맡는지" 분명한 것처럼, 두 엔진도 담당이 명확해야 결과가 깔끔합니다.

이 질서가 없으면 어떤 일이 벌어지는지 상상해보면 이해가 빠릅니다. 규칙 없이 두 엔진의 목소리를 섞으면, 확신 높은 코드 판정을 애매한 화면 인식이 흔들어버리는 일이 생깁니다. 명확하게 미통과였던 것이 "화면으로는 괜찮아 보인다"는 이유로 통과로 바뀌고, 다음번엔 또 다르게 나오고요. 그렇게 되면 자동 분석의 존재 이유였던 "일관되고 재현 가능한 결과"가 사라집니다. 결국 두 엔진을 두는 것보다, 규칙 엔진 하나만 쓰는 것보다도 못한 결과가 될 수 있습니다. 그래서 "무엇을 우선하고, 누가 어디를 채우고, 어디까지 믿을지"의 질서가 두 엔진 구조의 진짜 핵심입니다. 엔진이 둘이라는 사실보다, 둘을 질서 있게 합친다는 사실이 더 중요합니다.

본론 4 — 하나짜리보다 나은 이유

이제 처음의 질문으로 돌아가겠습니다. "그냥 하나로 다 하면 안 될까요?" 왜 굳이 둘로 나눴을까요. 두 가지 "하나짜리"를 각각 상상해보면 답이 나옵니다.

하나로 코드만 보면

코드만 보는 엔진 하나로 하면, 빠르고 일관되지만 앞서 말한 가짜 N/A를 못 채웁니다. 이미지로 만든 버튼, 비표준 방식으로 구현된 요소가 다 N/A로 빠져서 "절반만 본 분석"이 됩니다. 그러면 위반이 실제보다 적어 보이는 착시가 생깁니다. 판정된 항목만 놓고 보면 점수가 그럴듯한데, 사실은 코드로 못 본 영역이 통째로 빠져 있는 것이지요. 이 착시는 위험합니다. "우리 사이트 괜찮네" 하고 넘겼는데, 실은 화면으로만 보이는 문제들이 그대로 남아 있는 상태니까요.

하나로 화면만 보면

반대로 화면만 보는 엔진 하나로 하면, 시각은 잡지만 느리고 덜 명확합니다. 코드로 1초면 끝날 명확한 판정까지 무겁게 화면으로 처리하니 비효율적이고, 확신도 문제로 결과가 들쑥날쑥할 수 있습니다. 빠르고 확실한 영역까지 굳이 화면으로 보는 것은 낭비입니다. 게다가 화면 인식만으로는 코드 속에 숨은 구조 정보(라벨이 있는지, 제목 위계가 논리적인지 같은 것)를 정확히 읽기 어렵습니다. 화면에는 안 드러나지만 코드에는 적혀 있는 정보를 놓치게 되는 것이지요. 결국 화면만 보는 엔진도 절반만 보는 것은 마찬가지입니다. 놓치는 절반이 반대쪽일 뿐입니다.

둘로 나누면

둘로 나누면 각자 잘하는 것을 합니다. 코드로 빠르고 확실한 것은 코드가 처리하고, 화면으로만 보이는 것은 화면이 채웁니다. 그래서 빠르면서(코드가 대부분 처리) 빠짐이 없고(화면이 빈칸 보강), 일관되면서(코드 우선 규칙) 시각까지 봅니다(화면 엔진). 하나짜리 각각의 약점을 둘이 서로 메우는 구조입니다.

비용 측면에서도 그렇습니다. 화면 인식은 코드 읽기보다 무겁습니다. 시간도 자원도 더 듭니다. 모든 규칙을 다 화면으로 보면 분석 한 번이 너무 오래 걸리고 비싸집니다. 그런데 코드로 대부분을 처리하고 화면은 빈칸만 보면, 무거운 작업을 최소한만 쓰니까 빠르고 경제적입니다. "정확도"와 "효율"을 동시에 잡는 것이지요. 둘 중 하나만 쓰면 정확도(코드만)나 효율(화면으로 다 보기) 중 하나를 포기해야 하는데, 나눠 쓰면 둘 다 챙깁니다. 이것이 분업의 진짜 이득입니다.

이 이득이 실무에서 어떻게 체감되는지 잠깐 그려보겠습니다. 만약 화면만 보는 엔진 하나로 수백 페이지짜리 사이트를 분석한다면, 담당자는 결과를 받기까지 오래 기다려야 합니다. 그렇다고 코드만 보는 엔진 하나로 빠르게 끝내면, 결과는 금방 나오지만 이미지 버튼 같은 문제가 통째로 빠진 "절반짜리 보고서"를 손에 쥐게 됩니다. 두 경우 모두 담당자에게는 반쪽짜리 선택입니다. 두 엔진 구조는 이 딜레마를 없앱니다. 코드로 빠르게 대부분을 끝내니 결과가 지나치게 오래 걸리지 않고, 화면으로 빈칸을 메우니 절반이 빠지지도 않습니다. "빨리 받되 빠짐없이 받는다"가 가능해지는 것이지요. 속도와 완성도 중 하나를 포기하라는 요구를 받지 않는다는 것, 이것이 사용하는 입장에서 느끼는 두 엔진의 가장 실질적인 값어치입니다.

이것이 여태 계속 나온 그 원리입니다. 한 관점만으로는 절반만 봅니다. 코드 관점과 화면 관점을 나눠 보고 합쳐야 전체가 보입니다. 두 엔진은 그 원리를 분석 엔진 수준에서 구현한 것입니다. 사람이 부서를 나눠 협업하듯, 엔진도 관점을 나눠 협업합니다. 그리고 사람 협업과 마찬가지로, 나눈다는 사실보다 잘 합친다는 사실이 성패를 가릅니다.

한 걸음 더 들어가 보면, "둘로 나눈다"는 선택에는 또 다른 장점이 숨어 있습니다. 각 엔진을 따로 발전시킬 수 있다는 점입니다. 하나의 엔진이 코드와 화면을 뭉뚱그려 처리한다면, 어느 한쪽을 개선하려 할 때 다른 쪽까지 건드리게 되어 조심스러워집니다. 그런데 둘이 분리돼 있으면, 코드 판정 로직은 코드 판정대로 정교하게 다듬고, 화면 인식은 화면 인식대로 따로 발전시킬 수 있습니다. 담당이 나뉘어 있으니 개선도 나뉘어 이뤄지는 것이지요. 서로의 영역을 침범하지 않으면서 각자 깊어질 수 있다는 것은, 오래 유지하고 발전시켜야 하는 분석 도구에서 무시할 수 없는 이점입니다. 지금 잘 나눠둔 구조가, 앞으로 두 엔진을 각각 더 정확하게 만들 수 있는 여지를 남겨두는 셈입니다.

본론 5 — 버튼 하나가 두 엔진을 거치는 과정

말로만 하면 다소 추상적이니, "버튼 하나"가 두 엔진을 어떻게 거치는지 따라가 보겠습니다. 세 가지 버튼 사례로 풀겠습니다. 이 세 장면을 보면 두 엔진의 협업이 한눈에 들어옵니다.

사례 ① 코드에 멀쩡하게 있는 버튼

표준 방식으로 만든 버튼이 있다고 하겠습니다. 코드에 버튼 태그로 제대로 되어 있고, 이름(라벨)도 붙어 있습니다.

규칙 엔진: "버튼 있음, 라벨 있음, 크기 충분 → 통과." 끝. 명확하게 처리됩니다.
화면 엔진: 이미 확정됐으니 보지 않습니다(규칙 ①②에 따라 빈칸이 아니므로 건드리지 않습니다).
결과: 통과. 규칙 엔진이 순식간에 마무리합니다.

이런 경우가 대부분입니다. 그래서 규칙 엔진이 빠르게 뼈대를 세울 수 있는 것입니다. 잘 만든 사이트일수록 이 사례의 비율이 높고, 그만큼 분석이 가볍게 끝납니다.

KRDS 규칙 검증에서 버튼·입력창·표 등 컴포넌트가 규격·구조·상태 기준으로 통과·미통과 판정된 컴포넌트 상세보기 목록. 부품 하나하나가 어떤 근거로 판정됐는지 규칙별로 펼쳐진 뷰 (기관명·도메인 블러)

사례 ② 이미지로 만든 버튼

화면에서는 분명 버튼인데, 코드로는 그냥 이미지인 경우입니다.

규칙 엔진: "여기는 이미지네. 버튼 규칙은 해당없음(N/A)." 빈칸으로 남깁니다.
화면 엔진: 빈칸을 살펴보다가 "어라, 화면에는 여기 버튼처럼 생긴 것이 있네. 확신도 높음." → 그 빈칸을 "버튼 있음"으로 채우고 판정합니다. "그런데 이 버튼, 이름이 없어서 화면을 못 보는 사용자가 쓰는 스크린리더로는 안 읽히겠는데? → 미통과."
결과: 미통과(화면 엔진이 빈칸을 채워 발견). 규칙 엔진만 있었다면 N/A로 묻혔을 위반이 드러납니다.

이것이 바로 앞서 말한 "가짜 N/A를 채우는" 실제 모습입니다. 코드만 봐서는 "해당 없음"으로 조용히 넘어갔을 문제가, 화면을 보는 엔진 덕분에 수면 위로 올라옵니다. 이런 이미지 버튼은 겉보기엔 멀쩡해서 담당자도 눈치채기 어려운데, 정작 화면을 못 보는 사용자에게는 아무 이름도 없는 버튼이 됩니다. 두 엔진 구조가 실제로 값어치를 하는 대목이 여기입니다.

사례 ③ 애매한 것

화면에 뭔가 있긴 한데, 버튼인지 그냥 장식인지 애매한 경우입니다.

규칙 엔진: 코드로도 불분명함 → N/A.
화면 엔진: "버튼 같기도 하고 아닌 것 같기도… 확신도 낮음." → 억지로 단정하지 않고 N/A로 남깁니다(규칙 ③).
결과: N/A로 솔직하게 남김. 확신 없는 것을 우겨넣어 부정확하게 만드느니, 못 봤다고 두는 편이 낫습니다.

이 세 사례를 나란히 보면 두 엔진이 어떻게 협업하는지가 한눈에 보입니다. 명확한 것은 코드가 빠르게, 코드가 못 본 빈칸은 화면이, 화면으로도 애매한 것은 솔직히 N/A로. 각 단계가 자기 역할을 하고, 넘길 것은 넘기고, 못 하는 것은 인정합니다. 이 흐름이 "질서 있는 협업"의 실제 모습입니다. 특히 사례 ③이 중요합니다. 애매한 것을 솔직하게 N/A로 남기는 이 절제가, 결과 전체의 신뢰를 지탱합니다. 억지로 채운 하나가 나머지 전부의 신뢰를 갉아먹으니까요.

본론 6 — 이 분업이 공공 사이트에서 특히 유효한 이유

지금까지는 두 엔진이 "어떻게" 나눠 일하는지를 봤습니다. 이번에는 "왜 하필 공공 사이트에서 이 구조가 유독 잘 맞는가"를 짚겠습니다. 몇 가지 이유가 있습니다.

첫째, 공공 사이트는 규모가 큽니다. 페이지가 수십에서 수백 장에 이르고, 그 각각을 846개 규칙으로 봐야 합니다. 이 규모에서는 "값싼 코드 판정으로 대부분 처리하고 무거운 화면 인식은 빈칸만"이라는 순서가 결정적입니다. 만약 모든 페이지의 모든 규칙을 무거운 방식으로 처리해야 한다면 분석이 현실적으로 끝나지 않습니다. 두 엔진의 순서 덕분에 큰 사이트도 감당할 수 있는 것입니다.

둘째, 공공 사이트는 오래된 경우가 많습니다. 몇 년 전에 만들어져 조금씩 손봐온 사이트일수록 비표준 방식으로 구현된 부분이 섞여 있습니다. 이미지로 대충 만든 버튼, 정식 컴포넌트가 아니라 손으로 흉내 낸 요소 같은 것들이지요. 이런 것들은 코드만 봐서는 놓치기 쉬운데, 바로 화면 엔진이 채우는 빈칸입니다. 오래된 사이트일수록 "가짜 N/A"가 많고, 그만큼 화면 엔진의 값어치가 커집니다.

셋째, 공공 사이트는 결과를 근거로 써야 합니다. 담당자가 상급자에게 보고하거나, 개선 예산을 요청하거나, 개발사에 수정을 요구할 때, 그 근거가 되는 것이 분석 결과입니다. 그러니 결과는 일관되고 재현 가능해야 하고, 각 판정에는 근거가 붙어 있어야 합니다. 앞서 본 규칙 ①(코드 확정은 안 뒤집기)과 규칙 ④(근거 남기기)가 정확히 이 필요를 받쳐줍니다. 두 번 돌려도 같은 결과가 나오고, "왜 위반인지"가 명확하니 보고서로 쓸 수 있습니다.

넷째, 공공 사이트는 접근성이 특히 중요합니다. 민간 사이트는 불편하면 사용자가 다른 곳으로 가지만, 공공 사이트는 대체재가 없습니다. 세금을 내거나 민원을 넣거나 복지 혜택을 신청하는 창구가 그 사이트 하나뿐입니다. 그런데 접근성 문제의 상당수가 "화면에는 멀쩡한데 코드에 이름이 없는" 형태, 즉 두 엔진이 겹쳐봐야 잡히는 경계의 문제입니다. 사례 ②의 이미지 버튼이 대표적이지요. 화면만 봐서도, 코드만 봐서도 안 잡히고, 둘을 겹쳐봐야 "화면엔 있는데 코드엔 이름이 없다"는 결론이 나옵니다. 두 엔진 구조가 이 경계의 문제를 놓치지 않습니다.

다섯째, 공공 사이트는 행정안전부가 정한 넓은 품질 기준을 따라야 합니다. 「전자정부 웹사이트 품질관리 지침」은 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성이라는 7대 영역을 요구하는데, 이 일곱 가지는 코드 한 줄이나 화면 한 장만 봐서는 판정되지 않습니다. 접근성처럼 코드와 화면을 겹쳐봐야 잡히는 것이 있는가 하면, 신뢰성이나 효율성처럼 실제로 사이트에 접속해봐야 재는 것도 있습니다. 이렇게 성격이 제각각인 넓은 영역을 한 번에 감당하려면, 단일 관점의 엔진 하나로는 부족합니다. 코드를 읽는 눈과 화면을 보는 눈이 함께 있어야 이 폭을 감당할 수 있습니다. 두 엔진 구조가 이 넓은 요구에 대응하는 토대가 되는 것이지요.

이 다섯 가지를 종합하면, 두 엔진 구조는 공공 사이트라는 대상에 상당히 잘 맞는 설계입니다. 규모에 강하고, 오래된 사이트의 숨은 문제를 드러내고, 근거를 남겨 보고에 쓸 수 있고, 경계의 접근성 문제를 잡으며, 넓은 품질 요구를 감당합니다. 물론 이 구조가 만능은 아닙니다. 로그인 안쪽 페이지나, 눌러봐야 나오는 동적인 상호작용처럼 화면을 가만히 그려보는 것만으로는 완전히 다 잡기 어려운 영역도 있습니다. 그런 한계는 앞으로 영역별 글에서 솔직하게 짚겠습니다. 다만 "공개된 화면을 넓고 일관되게, 코드와 시각을 함께 본다"는 영역에서는, 두 엔진의 분업이 분명한 강점을 냅니다.

그래서 ViewCheck는

ViewCheck가 코드를 보는 엔진과 화면을 보는 엔진, 두 엔진을 함께 두는 이유가 바로 이것입니다. 코드 엔진이 846개 규칙을 빠르게 판정해 뼈대를 세우고, 화면 엔진이 N/A로 남은 빈칸 중 "화면에는 있는데 코드로 못 본 것"을 채우고, 합칠 때는 "코드 우선, 빈칸만 보강, 확신도로 거름, 근거 표시"라는 규칙을 지킵니다. 그 위에 판단 단계가 우선순위와 개선안을 얹습니다. 위에서 본 실화면들이 그 결과물의 일부입니다.

거창한 것이 아니라, 지난 몇 주에 본 문제들을 실제로 푸는 구조입니다. 코드만 봐서 생기는 가짜 N/A를 화면 엔진이 메우고, 화면 인식이 함부로 뒤집어 생길 수 있는 편차를 "코드 우선" 규칙이 막습니다. 두 엔진을 따로 두는 것이 목적이 아니라, 둘을 질서 있게 합쳐서 "빠르고, 촘촘하고, 일관된" 판정을 만드는 것이 목적입니다. 엔진이 둘이라는 사실은 수단일 뿐이고, 진짜 결과물은 그 둘이 합쳐 만들어내는 한 장의 신뢰할 만한 판정입니다.

그리고 이 모든 과정이 사용자 입장에서는 여전히 "주소 한 줄 넣고 결과를 받는다"로 요약됩니다. 뒤에서 두 엔진이 나눠 일하고, 순서를 지켜 흐르고, 네 가지 규칙으로 결과를 합치는 복잡한 일이 벌어지지만, 앞에서 담당자가 마주하는 것은 깔끔하게 정리된 결과 한 장입니다. 복잡함은 시스템이 감당하고, 사용자에게는 판정과 근거만 건네는 것이지요. 담당자가 코드를 읽을 줄 몰라도, 화면 인식이 어떻게 작동하는지 몰라도, 두 엔진이 협업해 만들어낸 결과를 그대로 받아 볼 수 있습니다. 좋은 도구의 조건이 바로 이것이라고 생각합니다. 안에서는 정교하게 나눠 일하되, 밖에서는 단순하게 한 장으로 건네는 것 말입니다.

이 두 엔진이 각각 내부에서 어떻게 작동하는지 — 코드 엔진의 규칙 판정 로직, 화면 엔진의 인식 방식, 판단 단계가 근거를 대는 방식 같은 것들 — 는 다음 달 이후 영역별 글에서 깊게 다룹니다. 판단 시점을 깊이 파는 것은 8개월차(LLM 분석)이고, 네 카테고리(DS·CP·BP·SP)의 성격 차이는 5개월차, 다중 페이지 분석은 6개월차, 위반의 위험도를 P0부터 P3까지 어떻게 나누는지는 4개월차에서 각각 자세히 풀 예정입니다. 오늘은 "코드 엔진이 뼈대, 화면 엔진이 빈칸, 규칙대로 합침" 정도의 큰 틀만 잡으시면 충분합니다.

🔐 특허로 지키는 부분

오늘 본 "코드 기반 판정과 화면 기반 분석을 충돌 없이 결합하는 방법", 그리고 "화면을 보고 컴포넌트를 인식하는 방식"은 ViewCheck가 출원한 기술 주제와 맞닿아 있습니다. 말로는 "코드도 보고 화면도 본다"가 간단해 보여도, 두 엔진을 "코드 확정은 안 뒤집고, 화면은 빈칸만, 확신도로 거르고, 근거를 단다"는 질서로 안정적으로 합치는 절차 자체가 결코 쉬운 일이 아닙니다. 그 방법을 권리로 정리해 둔 데 차별점이 있습니다.

다만 솔직히 짚어둘 것이 있습니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 두 엔진을 합친 결과가 실제로 정확한가는, 오늘 본 빈칸 채우기와 확신도 거르기가 제대로 작동하느냐로 결정되는 것이고, 특허는 그 방법을 보호하는 것입니다. 그래서 "특허가 있으니 믿으세요"가 아니라 "이 방법을 직접 만들어 지켜두었다" 정도로 받아들여 주시면 됩니다. 그리고 현재는 출원 단계입니다. "등록특허"가 아니라 "출원 기술"로 정확히 표기합니다. 이 특허들을 한눈에 정리해 소개하는 자리는 다음 주에 따로 마련하겠습니다. (특허 출원 기술 / 자체 개발)

마무리

오늘은 ViewCheck 분석의 밑바탕이 되는 두 엔진 구조를 봤습니다. 두 엔진은 보는 대상이 다릅니다. 하나는 코드를, 하나는 화면을 봅니다. 코드 엔진이 빠르게 뼈대를 세우고, 화면 엔진이 남은 빈칸을 채우고, 합칠 때는 "코드 우선, 빈칸만 보강, 확신도로 거름, 근거 표시"를 지킵니다. 하나로는 절반만 보지만, 둘이 나눠 보고 합치면 빠르면서도 촘촘하고 일관된 판정이 됩니다.

돌이켜보면, 여태 드린 이야기 전부가 하나의 원리로 모입니다. 한 관점으로는 절반만 보이니, 여러 관점을 나눠 보고 질서 있게 합치자는 것. 세 시점(운영·설계·판단)이 그랬고, 오늘 본 두 엔진(코드·화면)이 그렇습니다. 시점을 나누든 엔진을 나누든, 나눈다는 사실보다 잘 합친다는 사실이 더 중요합니다. 나누기만 하고 못 합치면 오히려 혼란이 되고, 잘 합치면 각자의 강점만 남고 약점은 서로 메워집니다.

이번 주는 그 판단 시점을 여는 주입니다. 오늘 두 엔진이라는 토대를 잡았으니, 수요일에는 그 위에 얹히는 판단 단계, 즉 "LLM 분석이란 무엇인가"를 풀겠습니다. 그리고 금요일에는 그 판단이 실제로 결과를 어떻게 읽고, 어떻게 개선안까지 내놓는지를 이어가겠습니다. 오늘이 "누가 무엇을 보는가"였다면, 수요일은 "그 위에서 무엇을 판단하는가", 금요일은 "그래서 어떻게 고치는가"인 셈입니다. 세 편을 다 읽고 나면 판단 시점의 밑그림이 한 장으로 잡히실 것입니다.

두 엔진 이야기를 한 문장으로 줄이면 이렇습니다. "코드로 빠르게 거르고, 화면으로 빈칸을 채우고, 질서 있게 합친다." 하나로는 빠르거나 정확하거나 둘 중 하나만 되는데, 나눠 쓰면 빠르면서 정확해집니다. 그것이 엔진을 둘 둔 이유의 전부입니다.

오늘 딱 하나만 가져가신다면 이 문장이면 좋겠습니다. 코드를 보는 눈과 화면을 보는 눈은 서로 다른 절반을 보고, 그 둘을 질서 있게 합쳐야 비로소 사이트의 전체가 보입니다. 어느 한쪽만으로는 절반의 진실만 손에 쥐게 됩니다. 두 엔진이 각자의 절반을 정직하게 보고, 겹치지 않게 나누고, 확신 있는 것만 채워 하나로 합치는 것 — 그 위에서 비로소 "그래서 무엇부터 고칠까"라는 판단이 의미를 갖습니다. 오늘도 긴 이야기를 끝까지 읽어주셔서 진심으로 고맙습니다. 이번 주 수요일, 두 엔진 위에 얹히는 그 판단 단계 이야기로 다시 찾아뵙겠습니다.

krds.viewcheck.co.kr