보이는 화면을 본다 — 코드가 아니라 '그려진 결과물'을 기준으로

---

들어가며 — 사용자가 마주하는 건 코드가 아니라 화면입니다

지난주에 URL 분석의 파이프라인을 큰 틀로 살펴봤습니다. 주소 한 줄을 넣으면 그 뒤에서 사이트를 수집하고, 실제로 그려내고, 그 화면을 스캔해서 정보를 뽑아낸다는 흐름이었습니다. 그중에서 오늘은 두 번째 단계, "실제로 그려낸다"는 부분을 깊게 파보려 합니다. 말은 짧지만 사실 이 한 단계가 URL 분석의 성격을 통째로 결정합니다. 여기서 무엇을 기준으로 삼느냐 — 코드냐, 그려진 화면이냐 — 가 갈리기 때문입니다.

지난달 내내 한 문장을 반복해서 강조했습니다. "코드가 아니라 화면을 본다." 그때는 개념으로만 말씀드렸는데, 오늘은 그게 실제로 어떻게 일어나는지, 그리고 왜 하필 "그려진 화면"이 진짜인지를 구체적으로 풀어보겠습니다. 이 이야기가 중요한 이유는, 같은 "웹 품질 점검"이라는 이름을 달고도 도구마다 결과가 다르게 나오는 가장 큰 원인 중 하나가 바로 이 지점이기 때문입니다. 어떤 도구는 코드만 읽고, 어떤 도구는 화면을 끝까지 그려서 봅니다. 겉보기엔 비슷해 보여도, 이 차이가 "사용자가 실제로 겪는 문제를 잡느냐 못 잡느냐"를 가릅니다.

오늘 글은 조금 기술적인 이야기지만, 최대한 쉽게 풀겠습니다. 어려운 용어를 늘어놓는 대신, "사람이 웹페이지를 볼 때 실제로 벌어지는 일"에 빗대어 설명드리려 합니다. 결론부터 미리 말씀드리면 이렇습니다. 웹페이지에는 두 개의 층이 있는데, 하나는 코드라는 설계도이고 다른 하나는 그 설계도가 그려낸 화면이라는 결과물입니다. 사용자는 결과물을 보고, 그래서 품질도 결과물을 기준으로 봐야 합니다. 이 단순한 원칙을 실제로 지키느냐 마느냐가, 오늘 이야기의 전부입니다.

이 주제를 굳이 한 주를 통째로 들여 다루는 이유가 있습니다. 웹 품질을 점검한다는 도구가 시중에 적지 않은데, 그중 상당수가 화면을 그려서 보지 않고 코드만 훑습니다. 이유는 간단합니다. 코드를 읽는 건 빠르고 가볍지만, 화면을 진짜 브라우저처럼 끝까지 그려내는 건 훨씬 무겁고 손이 많이 가는 일이기 때문입니다. 그래서 "빠르게 결과를 뽑는" 쪽을 택하면 자연히 코드만 보게 됩니다. 그런데 그 편의를 택하는 순간, 사용자가 실제로 겪는 시각 문제를 통째로 놓치게 됩니다. 편하지만 절반만 보는 길과, 무겁지만 사용자가 보는 그대로 보는 길 — 이 갈림길을 어느 쪽으로 가느냐가 오늘의 핵심입니다. 그 어려운 쪽을 제대로 해내느냐가, 같은 이름을 달고도 결과가 다르게 나오는 이유입니다.

위 화면이 오늘 이야기의 요약본이기도 합니다. 같은 페이지 하나를 세 가지 화면 크기로 각각 실제로 그려낸 뒤, 그 그려진 결과를 놓고 비교한 모습입니다. 코드는 하나인데 화면은 크기마다 다르게 그려지고, 그 다르게 그려진 화면에서만 드러나는 문제가 있습니다. 코드만 봐서는 절대 이 비교를 할 수 없습니다. 왜 그런지, 지금부터 하나씩 짚어보겠습니다.

---

본론 1 — 코드는 설계도, 화면은 결과물입니다

웹페이지에는 두 개의 층이 있습니다

먼저 이 구분부터 확실히 하고 가겠습니다. 우리가 흔히 "웹페이지"라고 부르는 것에는 사실 두 개의 층이 겹쳐 있습니다. 하나는 코드입니다. HTML이라는 구조, CSS라는 스타일 규칙, 자바스크립트라는 동작 명령이 적힌 층입니다. 다른 하나는 그 코드가 실제로 그려낸 화면입니다. 우리가 브라우저 창에서 눈으로 보는, 색과 글자와 버튼이 배치된 그 결과물입니다.

이 둘의 관계는 설계도와 완성된 건물의 관계와 비슷합니다. 코드는 "여기에 벽을 세우고, 저기에 문을 달아라"라고 적힌 설계도이고, 화면은 그 설계도대로 지어진 건물입니다. 설계도를 읽으면 건물이 어떻게 지어질지 짐작할 수 있지만, 짐작과 실제가 항상 같지는 않습니다. 시공 과정에서 뭔가 어긋나기도 하고, 설계도에는 안 적힌 자재나 마감이 현장에서 더해지기도 합니다. 그래서 건물의 실제 상태를 알려면 설계도만 봐서는 부족하고, 지어진 건물을 직접 봐야 합니다.

웹도 똑같습니다. 코드라는 설계도만 읽어서는 화면이 실제로 어떻게 그려졌는지 완전히 알 수 없습니다. 그래서 실제로 그려진 화면을 봐야 하는 것입니다. 이게 오늘 이야기의 출발점입니다.

공공 사이트에서 흔한 장면을 하나 그려보겠습니다. 어느 담당자분이 "우리 홈페이지 코드는 표준에 맞게 잘 짜여 있다"는 개발사의 말을 믿고 안심하고 계셨습니다. 그런데 실제 운영 화면을 열어 보니, 메인 배너의 중요한 안내가 통째로 이미지로 박혀 있고, 모바일에서는 신청 버튼이 화면 밖으로 살짝 밀려 나가 있었습니다. 코드는 표준에 맞았을지 모릅니다. 그런데 그 코드가 그려낸 화면은 사용자에게 불편했습니다. 설계도가 맞다고 결과물까지 맞다는 보장이 없다는 걸, 이 장면 하나가 보여줍니다. 그래서 "코드가 맞으니 됐다"가 아니라 "그려진 화면이 맞는지"를 따로 확인해야 하는 것입니다.

코드 기반 분석의 강점과 한계

여기서 오해하지 않으셨으면 하는 게 있습니다. 코드를 읽는 게 나쁘다는 이야기가 아닙니다. 코드 기반 분석에는 분명한 강점이 있습니다. 빠르고, 구조를 정확히 봅니다. "여기 버튼 태그가 있고, 라벨이 붙어 있고, 제목이 순서대로 정리돼 있고" 같은 구조적 사실은 코드를 읽는 게 가장 정확합니다. 그래서 URL 분석도 코드를 읽습니다. 코드를 안 읽는 게 아니라, 코드만 읽지 않는 것입니다.

문제는 코드만 읽을 때 생깁니다. 설계도에는 안 적혀 있는데 결과물에는 나타나는 게 있고, 설계도대로 안 그려지는 경우도 있기 때문입니다. 예를 들어 코드에는 "이 여백은 8픽셀"이라고 적혀 있어도, 옆 요소가 예상보다 커지거나 줄바꿈이 생기면 실제 화면에서의 간격은 달라집니다. 코드에는 "이 글자색은 이 값"이라고 적혀 있어도, 그 글자가 반투명하게 겹쳐 있거나 배경 이미지 위에 놓여 있으면 실제로 보이는 색은 다릅니다. 설계도의 "의도된 값"과 화면의 "실제 결과"가 어긋나는 것입니다.

이 어긋남은 예외적인 사고가 아니라 웹에서 늘 있는 일입니다. 요즘 웹페이지는 여러 조각의 코드가 서로 얽혀서 화면을 만들고, 그 조각들이 상호작용하면서 최종 결과가 나옵니다. 그래서 조각 하나하나를 아무리 정확히 읽어도, 그것들이 합쳐진 최종 화면은 직접 봐야 알 수 있습니다. 부분의 합이 전체와 다를 수 있다는 것입니다.

사용자는 결과물을 씁니다

가장 근본적인 이유는 이것입니다. 사용자는 코드를 보지 않습니다. 화면을 봅니다. 사용자가 불편한 건 "코드가 이상해서"가 아니라 "화면이 이상해서"입니다. 버튼이 안 보이고, 글자가 안 읽히고, 모바일에서 겹치고. 이 모든 불편은 결과물에서 벌어집니다.

그러니 사용자 경험을 보려면 사용자가 실제로 마주하는 결과물, 즉 그려진 화면을 봐야 합니다. 코드는 그 화면을 만드는 재료일 뿐입니다. 재료가 아무리 좋아도 완성품이 잘못 나오면 사용자는 완성품을 겪습니다. 요리에 비유하면, 레시피가 완벽해도 실제로 나온 요리가 짜거나 타 있을 수 있습니다. 손님은 레시피를 먹는 게 아니라 요리를 먹습니다. 그러니 맛을 보려면 레시피를 검토하는 게 아니라 요리를 직접 맛봐야 합니다. 코드 기반 분석이 레시피를 검토하는 일이라면, 화면 기반 분석은 요리를 직접 맛보는 일입니다. 둘 다 필요하지만, "손님이 실제로 경험하는 것"에 더 가까운 쪽은 요리, 즉 화면입니다.

이 관점의 차이는 조직 안에서도 그대로 드러납니다. 디자인 담당자는 화면을 봅니다. "색 예쁘고, 배치 깔끔하고, 통과." 개발 담당자는 코드를 봅니다. "태그 구조 맞고, 오류 없고, 통과." 두 분 다 자기 자리에서 성실하게 봤고, 둘 다 "이상 없음"입니다. 그런데 그 버튼은 실은 이미지 위에 얹힌 장식일 뿐, 키보드로는 선택되지 않고 보조기술은 아무것도 읽어주지 못합니다. 화면만 본 디자이너도, 코드 조각만 본 개발자도 이 사실에 도달하지 못했습니다. 두 정보가 만나는 지점을 아무도 안 봤기 때문입니다. 부서 사이의 틈으로 문제가 새는 것이죠. 렌더링 기반 분석은 바로 이 틈을 봅니다. 그려진 화면에서 "여기 버튼처럼 생긴 게 있다"를 확인하고, 동시에 그 자리의 코드를 읽어 "그런데 이건 눌리는 버튼이 아니다"를 잡아냅니다. 사람 조직에서는 틈으로 새던 문제가, 한 번의 분석 안에서 메워집니다.

---

본론 2 — 왜 '렌더링 후의 화면'이 진짜인가

코드만 받아오면 빈 껍데기일 때가 많습니다

이제 핵심으로 들어가겠습니다. "실제로 그려낸다"는 것, 즉 렌더링이라는 단계가 왜 그렇게 중요한지입니다.

옛날 웹사이트는 HTML 코드 안에 내용이 대부분 들어 있었습니다. 그래서 코드만 받아와도 화면을 어느 정도 짐작할 수 있었습니다. 그런데 요즘 사이트는 다릅니다. 처음 받아오는 코드는 거의 빈 껍데기에 가깝고, 자바스크립트라는 동작 명령이 실행되면서 그 안을 채웁니다. 메뉴도, 목록도, 표도, 배너도 대부분 나중에 그려집니다. 사용자가 페이지에 들어온 뒤 몇 초 사이에 화면이 완성되는 것입니다.

이게 무슨 뜻이냐면, 코드만 받아서 보면 "내용이 거의 없는 사이트"로 보인다는 것입니다. 실제로는 화면 가득 콘텐츠가 있는데도 말입니다. 자바스크립트가 돌기 전의 빈 껍데기를 붙잡고 아무리 정밀하게 분석해봐야, 사용자가 보는 화면과는 전혀 다른 걸 보고 있는 셈입니다. 그래서 코드를 받아오는 것만으로는 부족하고, 진짜 브라우저처럼 그 코드를 끝까지 실행해서 화면을 완성시켜야 합니다. 자바스크립트가 다 돌고, 이미지가 다 로딩되고, 스타일이 다 적용된 그 상태 — 그게 사용자가 보는 화면입니다.

조금 더 풀어보겠습니다. 코드만 받아오는 방식으로 어느 공공 사이트를 열면, 받아온 코드에는 메뉴 이름도, 목록의 항목도, 표의 내용도 거의 들어 있지 않은 경우가 많습니다. 그것들이 전부 자바스크립트가 실행된 뒤에야 화면에 채워지기 때문입니다. 그런데 그 빈 껍데기를 그대로 분석하면, "이 사이트는 메뉴도 없고 콘텐츠도 없다"는 엉뚱한 결론이 나옵니다. 사용자는 메뉴가 가득한 화면을 보고 있는데, 분석은 텅 빈 페이지를 보고 있는 것이죠. 이 간극은 사소한 오차가 아니라, 분석 전체를 무의미하게 만드는 근본적인 어긋남입니다. 그래서 "끝까지 그려낸다"는 이 한 단계가, 그 뒤 모든 측정의 진위를 결정합니다.

헤드리스 브라우저 — 화면만 없는 진짜 브라우저

이 일을 사람 없이 자동으로 해내는 환경을 흔히 "헤드리스 브라우저"라고 부릅니다. 이름이 낯설지만 개념은 단순합니다. 우리가 쓰는 브라우저와 똑같이 페이지를 띄우고 끝까지 그려내는데, 단지 모니터에 화면을 표시하지 않을 뿐입니다. 머리(화면)만 없을 뿐, 안에서 벌어지는 일은 진짜 브라우저와 같습니다. 자바스크립트를 실행하고, 이미지를 로딩하고, 스타일을 적용해서 완성된 화면을 만듭니다.

이게 왜 중요하냐면, "사용자가 모니터 앞에서 보던 그 화면"을 사람 없이 기계가 똑같이 만들어낼 수 있어야, 비로소 그 화면을 기준으로 분석할 수 있기 때문입니다. 실제 브라우저가 그려내는 것과 다른 방식으로 화면을 짐작하면, 그 짐작 위에서 아무리 정밀하게 재봐야 어긋난 결과만 나옵니다. 사용자가 겪는 화면에 최대한 가깝게 그려내는 것 — 이게 모든 분석의 토대입니다.

그리고 실제 환경을 재현한다는 건 자잘한 것까지 챙긴다는 뜻이기도 합니다. 사람이 사이트를 볼 때 무의식적으로 하던 동작들이 있습니다. 화면을 가리는 배너가 뜨면 닫고, 페이지가 다 뜰 때까지 잠깐 기다리고, 아래 내용을 보려고 스크롤을 내리고. 자동 분석도 이런 동작을 비슷하게 처리해야 "사용자가 실제로 보는 화면"에 가까워집니다. 대충 받아서 첫 화면만 보면, 스크롤을 내려야 나타나는 콘텐츠나 로딩이 끝난 뒤의 최종 모습을 놓칩니다. 사용자가 실제로 겪는 건 "다 뜬 뒤, 스크롤까지 내려본" 화면인데, 분석이 "덜 뜬 첫 화면"만 보면 서로 다른 걸 보는 셈입니다. 그래서 렌더링은 단순히 "한 장 찍는다"가 아니라, 사용자가 그 페이지를 실제로 겪는 과정을 재현하는 일에 가깝습니다.

진짜 화면에 도달하는 것 자체가 관문입니다

그런데 "사용자가 보는 그대로 끝까지 그려낸다"는 게 말처럼 쉽지 않습니다. 여러 변수가 앞을 가로막기 때문입니다. 어떤 사이트는 팝업이나 쿠키 동의 배너가 화면을 가리고 있어서 그걸 감안해야 하고, 어떤 사이트는 로딩이 느려서 다 뜰 때까지 기다려야 하며, 어떤 사이트는 스크롤을 내려야 콘텐츠가 나타납니다. 사람이 직접 볼 때 무의식적으로 하던 이런 동작들을, 자동 분석도 비슷하게 처리해야 "사용자가 실제로 보는 화면"에 가까워집니다.

여기에 더해, 어떤 사이트는 보안 장비가 자동 접근을 막고, 어떤 사이트는 무한 스크롤로 콘텐츠가 계속 붙고, 어떤 사이트는 특정 조건에서만 열립니다. 이런 변수를 하나씩 넘어서 "진짜 화면"에 도달하는 것 자체가 URL 분석의 첫 관문입니다. 이 관문에서 무너지면, 그 뒤의 정교한 측정과 판정은 다 의미가 없어집니다. 잘못 그려진 화면을 아무리 정밀하게 재봐야 틀린 결과만 나오니까요. "빨리 대충 받아왔다"와 "사용자가 보는 그대로 끝까지 그려냈다"는 결과물이 완전히 다르고, 후자를 안정적으로 해내는 게 실은 만만한 일이 아닙니다. 렌더링을 제대로 하느냐가, 같은 URL 분석이라도 결과의 신뢰도를 가르는 첫 갈림길인 셈입니다.

---

본론 3 — 코드만 보면 놓치는 것들

렌더링을 해서 실제 화면을 봐야 하는 이유를, 이번엔 "코드만 보면 구체적으로 무엇을 놓치는가"로 뒤집어서 정리해보겠습니다. 크게 세 갈래입니다. 이미지로 된 것, 시각적인 수치, 시각적인 관계입니다.

첫째, 이미지로 만든 것들

가장 대표적인 사각지대입니다. 공공 사이트에는 이미지로 만든 요소가 의외로 많습니다. 이미지 버튼, 이미지 배너, 인포그래픽, 그리고 이미지 안에 박아 넣은 글자입니다. 코드로만 보면 이런 건 그냥 "이미지 한 장"입니다. 그 안에 버튼이 있는지, 무슨 글자가 적혀 있는지, 어떤 안내를 하는지를 코드는 알지 못합니다.

예를 들어 "○○ 신청 안내"라는 중요한 정보가 통째로 이미지로 박혀 있다고 해보겠습니다. 코드로만 보면 "그림 파일 하나"라, 그 페이지가 무슨 안내를 하는지 분석이 전혀 모릅니다. 그런데 화면으로 보면 사람이 눈으로 읽듯 그 안내를 파악할 수 있고, 더 나아가 "이 중요한 안내가 이미지라서 화면을 못 보는 사용자에게는 전달되지 않겠구나"라는 접근성 문제까지 잡아낼 수 있습니다. 화면을 못 보는 사용자 입장에서는 그 안내가 아예 없는 것이나 마찬가지이니까요. 이런 판단은 화면을 실제로 그려서 봐야만 가능합니다. 필요할 때는 이미지 속 글자를 인식하는 보완적인 방법도 함께 씁니다만, 핵심은 "이미지로 된 요소가 화면에 실제로 어떻게 나타나는지를 본다"는 것입니다.

이미지 버튼은 특히 골치 아픈 사각지대입니다. 화면상으로는 분명 버튼처럼 생겼고 사용자도 버튼으로 인식해서 누르는데, 코드상으로는 진짜 버튼으로 정의돼 있지 않은 경우가 있습니다. 그러면 마우스로는 눌리지만 키보드로는 선택되지 않고, 화면을 읽어주는 보조기술은 그 버튼의 존재조차 알려주지 못합니다. 코드만 보면 "버튼 없음"이고 화면만 보면 "버튼 있음"인데, 이 둘을 겹쳐봐야 비로소 "화면엔 버튼인데 코드엔 버튼이 아님 → 접근성 위반"이라는 결론이 나옵니다.

이런 이미지 요소가 공공 사이트에 많은 데는 이유가 있습니다. 디자인을 정교하게 잡고 싶은데 코드로 구현하기 번거로우면, 통째로 이미지 한 장으로 만들어 붙이는 게 빠르고 편하기 때문입니다. 행사 안내 배너, 이용 절차 안내, 축하 문구, 각종 홍보 포스터가 그렇게 이미지로 처리되는 일이 잦습니다. 보기에는 깔끔하지만, 그 안에 담긴 정보와 기능은 화면을 못 보는 사용자에게 전달되지 않습니다. 코드만 보는 도구는 이 이미지들을 그냥 "장식용 그림"으로 넘겨버리기 쉽습니다. 화면을 실제로 그려서 그 안에 무엇이 담겼는지를 봐야, "이건 단순 장식이 아니라 정보와 기능을 품은 이미지인데 대체 수단이 없다"는 걸 잡아낼 수 있습니다.

둘째, 시각적인 수치들

두 번째는 화면에서 실제로 재야만 나오는 수치들입니다. 두 요소 사이의 간격이 정확히 몇 픽셀인지, 글자색과 배경색의 대비가 얼마인지, 버튼이 화면에서 실제로 얼마나 큰지 같은 것입니다.

앞서 말씀드렸듯 코드에 적힌 값과 화면의 실제 값은 다를 수 있습니다. 그래서 화면에서 요소의 실제 위치와 크기, 실제로 계산된 색을 재야 진짜 수치가 나옵니다. "이 회색 글씨가 좀 흐린데?"라는 느낌이 "대비 비율이 기준 미달"이라는 수치로 바뀌고, "간격이 좀 좁아 보이는데"가 "실제 간격이 규격보다 작음"으로 바뀌며, "버튼이 작아 보인다"가 "실제 크기가 터치 기준에 못 미침"으로 바뀝니다. 느낌이 측정으로 바뀌는 것입니다.

이 측정의 핵심 강점은 재현된다는 것입니다. 같은 화면을 몇 번을 재도 같은 수치가 나오고, 누가 재도 같습니다. 지난달에 짚었던 "사람마다, 날마다 다르게 보는" 편차 문제가 여기서 사라집니다. 사람은 매번 조금씩 다르게 보지만, 화면에서 좌표와 색과 크기를 숫자로 읽어내면 그 값은 일정합니다. 그래서 이 수치로 시점 비교도, 객관적 보고도 가능해집니다.

여기서 "화면에서 잰다"가 "코드 값을 읽는다"와 왜 다른지 한 번 더 짚을 만합니다. 코드에는 "이 글자색은 이 값"이라고 적혀 있을 수 있습니다. 그런데 실제 화면에서는 그 글자가 반투명하게 겹쳐 있거나 배경 이미지 위에 놓여 있어서, 눈에 보이는 색이 코드 값과 다를 수 있습니다. 코드 값만 믿으면 "대비 충분"인데, 화면에서 실제로 보이는 색을 재면 "대비 미달"인 경우가 생깁니다. 사용자가 보는 건 화면이니, 화면에서 실제로 보이는 색을 재야 진짜 대비가 나옵니다. 간격도 마찬가지입니다. 코드에는 여백이 이만큼이라고 돼 있어도, 옆 요소가 예상보다 커지거나 줄바꿈이 생기면 실제 화면 간격은 달라집니다. 그래서 코드의 "의도된 간격"이 아니라 화면의 "실제 간격"을 재는 것입니다. 의도와 결과가 다를 수 있다는 이야기가, 측정의 수준에서도 똑같이 적용됩니다.

셋째, 시각적인 관계들

세 번째는 요소들 사이의 관계입니다. 이 버튼이 저 텍스트보다 눈에 띄는지(위계), 여러 요소가 같은 선에 정렬돼 보이는지, 화면 전체가 균형 잡혀 보이는지. 이런 "보이는 느낌"은 코드의 구조만 봐서는 나오지 않습니다. 화면 전체를 봐야 알 수 있습니다.

정렬을 예로 들어보겠습니다. 사람 눈에는 1~2픽셀 어긋남은 "정렬됐다"로 보입니다. 그런데 화면에서 여러 요소의 좌표를 비교하면 "왼쪽 끝이 몇 픽셀 어긋남"이 정확히 드러납니다. 이런 미세한 어긋남이 화면 곳곳에 쌓이면 "어딘가 정돈이 안 된 느낌"을 주는데, 그 정체를 좌표로 짚어내는 것입니다. 같은 컴포넌트가 화면마다 모서리 둥글기나 형태가 조금씩 다른 것도, 화면을 봐야 "통일성이 깨졌다"를 알 수 있습니다. 이런 관계적 품질은 코드 조각을 아무리 정확히 읽어도 안 보이고, 오직 완성된 화면 전체를 볼 때만 드러납니다.

위계도 마찬가지입니다. 어느 페이지에서 가장 중요한 행동이 "신청하기"라면, 그 버튼이 화면에서 가장 눈에 띄어야 합니다. 그런데 코드상으로는 버튼이 제대로 정의돼 있어도, 화면에서는 주변의 다른 요소에 묻혀 눈에 안 띌 수 있습니다. 색이 배경과 비슷하거나, 크기가 작거나, 덜 중요한 요소가 오히려 더 튀거나. 이런 위계의 어긋남은 "코드에 버튼이 있나 없나"로는 절대 안 나옵니다. 화면 전체에서 이 요소가 저 요소보다 시각적으로 앞서는지를 봐야 합니다. 사용자가 "어디를 눌러야 할지 헷갈린다"고 느끼는 불편의 상당수가 바로 이 위계 문제인데, 그건 완성된 화면을 통째로 놓고 볼 때만 잡힙니다.

위 화면이 그 예입니다. "깔끔하다" 혹은 "어수선하다"는 막연한 느낌이, 화면에서 실제로 잰 색·간격·크기라는 측정값으로 분해되어 기준과 대조되는 모습입니다. 코드에 적힌 의도가 아니라 화면에 실제로 그려진 결과를 재기 때문에, 의도와 결과가 어긋난 지점까지 그대로 드러납니다.

---

본론 4 — 그려진 화면을 어떻게 읽나

화면을 봐야 한다는 건 알겠는데, 그럼 기계가 "화면을 본다"는 게 구체적으로 무슨 뜻일까요. 사람은 화면을 보면 모양과 글자와 색이 한꺼번에 눈에 들어옵니다. 기계는 이걸 몇 갈래로 나눠서 읽고, 그 결과를 합쳐서 사람처럼 화면을 이해합니다. 크게 세 가지 방법을 함께 씁니다.

구조를 읽는다 — DOM

첫째, 화면 뒤의 구조를 읽습니다. 화면에 보이는 요소가 코드상으로 어떤 요소인지, 어떤 이름과 속성을 갖고 있는지, 제목과 목록의 구조가 논리적으로 짜여 있는지를 봅니다. 앞서 말씀드린 "이 버튼이 진짜 버튼으로 정의돼 있는지, 키보드로 눌리는지, 보조기술이 읽을 수 있는지"가 여기서 나옵니다. 구조는 코드를 읽는 게 가장 정확하니, 이 부분은 코드 층을 봅니다.

실제 계산값을 읽는다 — computed style

둘째, 화면에 실제로 적용된 계산값을 읽습니다. 코드에 적힌 스타일 규칙이 여러 겹으로 얹히고 서로 덮어쓴 끝에, 브라우저가 최종적으로 "이 요소는 실제로 이 색, 이 크기, 이 간격으로 그린다"고 확정한 값이 있습니다. 이 최종 계산값을 읽으면, 코드에 적힌 "의도"가 아니라 화면에 그려진 "실제 결과"를 알 수 있습니다. 앞서 계속 말씀드린 "코드 값과 화면 값의 차이"를 메우는 게 바로 이 계산값입니다. 브라우저가 실제로 그려낸 값이니, 이보다 진짜에 가까운 수치는 없습니다.

이 계산값이 왜 중요한지 조금 더 풀어보겠습니다. 웹페이지의 스타일은 한 곳에서 딱 정해지는 게 아니라, 여러 규칙이 겹쳐서 정해집니다. 어떤 규칙은 전체에 적용되고, 어떤 규칙은 특정 부분에만 적용되며, 화면 크기에 따라 달라지는 규칙도 있습니다. 이 규칙들이 서로 우선순위를 다투며 덮어쓴 끝에 최종 값이 나옵니다. 그래서 코드의 한 줄만 봐서는 "이 요소가 실제로 무슨 색으로 그려질지"를 확정하기 어렵습니다. 여러 규칙이 합쳐진 결과를 브라우저가 계산해줘야 비로소 확정됩니다. 그 확정된 값이 계산값이고, 그건 화면을 실제로 그려낸 다음에만 얻을 수 있습니다. 렌더링을 해야 계산값이 나오고, 계산값이 나와야 진짜 수치로 잴 수 있다는 — 여기서도 렌더링이 앞단의 필수 전제가 됩니다.

화면을 시각으로 감지한다 — 시각 AI

셋째, 그려진 화면 자체를 시각적으로 봅니다. 화면을 이미지로 캡처해서, 거기에 어떤 컴포넌트가 있는지를 감지하는 것입니다. 이게 필요한 이유는, 앞서 본 이미지 버튼처럼 코드상 구조로는 안 잡히는데 화면상으로는 분명히 존재하는 요소가 있기 때문입니다. 코드로는 "그냥 이미지"인데 화면으로는 "버튼처럼 생긴 것"을, 시각적으로 감지해내는 역할입니다.

여기서 중요한 원칙이 있습니다. 이 시각적 감지는 코드가 이미 명확히 판정한 것을 뒤집지 않습니다. 코드로 통과 혹은 미통과가 확정된 항목은 그대로 두고, 코드만으로는 판단이 안 서서 "해당 없음"으로 비어 있던 빈칸만 채웁니다. 그것도 확신이 있을 때만 채웁니다. 화면에서 뭔가를 확실히 감지했을 때만 빈칸을 메우고, 애매하면 무리하게 채우지 않고 "해당 없음"으로 남겨둡니다. 있지도 않은 걸 있다고 지어내면 오히려 잘못된 판정이 되니까요. 그리고 무엇을 근거로 그렇게 판단했는지 흔적을 남깁니다. 이렇게 조심스럽게 다루기 때문에, 시각적 감지는 코드 분석을 대체하는 게 아니라 코드가 못 보는 사각지대를 메우는 조력자 역할을 합니다.

이 세 가지가 합쳐지면 화면을 꽤 입체적으로 읽게 됩니다. "여기 좌표에 버튼처럼 생긴 게 있고(시각 감지), 실제 크기는 이만하며(계산값), 그런데 코드에는 버튼으로도 라벨로도 정의돼 있지 않다(구조)"는 식으로요. 사람이 화면을 볼 때 "저기 버튼 있고, 신청하기라고 써 있고, 좀 작네" 하고 한 번에 파악하는 그것을, 기계는 세 갈래로 나눠서 각각 정밀하게 읽고 합쳐서 해냅니다. 나눠서 하는 만큼 각각을 사람보다 꼼꼼하게 할 수 있다는 장점이 있습니다.

이 세 방법은 서로의 약점을 메우는 관계입니다. 구조만 읽으면 "코드에 뭐가 정의돼 있나"는 알아도 그게 화면에 실제로 어떻게 그려졌는지는 모릅니다. 계산값만 읽으면 "이 요소가 실제로 이 크기다"는 알아도 코드상 그게 어떤 의미의 요소인지는 약합니다. 시각 감지만 하면 "화면에 뭔가 있다"는 봐도 그 정확한 속성은 흐립니다. 그래서 세 방법을 따로 쓰면 각각 절반짜리인데, 같은 화면을 두고 셋을 겹쳐 읽으면 비로소 온전한 그림이 됩니다. 중요한 건 이 셋이 모두 "하나의 그려진 화면"을 공통의 바탕으로 삼는다는 점입니다. 먼저 화면을 제대로 그려두었기 때문에, 그 위에서 구조도 읽고 계산값도 읽고 시각으로도 감지하는 세 갈래가 서로 어긋나지 않고 같은 대상을 가리킬 수 있는 것입니다. 렌더링이 토대라는 말이 여기서도 유효합니다.

---

본론 5 — 하나의 화면이 아니라, 여러 크기로 그려서 봅니다

코드는 하나인데 화면은 크기마다 다릅니다

렌더링 이야기에서 빠질 수 없는 게 화면 크기입니다. 요즘 웹페이지는 화면 크기에 따라 배치가 달라지도록 만들어져 있습니다. 데스크톱에서는 요소가 가로로 넉넉하게 펼쳐지고, 모바일에서는 그 요소들이 세로로 쌓입니다. 코드는 하나지만, 그 코드가 그려내는 화면은 크기마다 다른 것입니다.

그래서 화면 하나만 그려서 봐서는 부족합니다. 데스크톱 크기로만 그려서 보면, 모바일에서만 생기는 문제를 통째로 놓칩니다. 지난달에 "모바일을 통째로 빠뜨려서 사고가 난" 이야기를 드렸는데, 그 사고의 원인이 바로 이것입니다. 하나의 크기만 보고 "괜찮다"고 판단한 것이죠. 여러 크기로 각각 그려서 봐야, 크기마다 다르게 나타나는 문제가 드러납니다.

세 개의 뷰포트로 실제로 그립니다

ViewCheck의 URL 분석은 같은 페이지를 세 가지 화면 크기로 각각 실제로 그려서 봅니다. 데스크톱은 가로 1920 세로 1080, 태블릿은 가로 768 세로 1024, 모바일은 가로 390 세로 844입니다. 이 세 크기로 각각 페이지를 끝까지 그려낸 뒤, 그 그려진 화면들을 비교합니다. 짐작이 아니라 실제로 그 크기로 띄워서 보는 것입니다.

이렇게 하면 "데스크톱에선 두 버튼이 안 겹쳤는데 모바일에선 겹친다", "데스크톱에선 여유로운 배치가 모바일에선 화면 밖으로 밀린다" 같은, 크기별로만 나타나는 문제가 잡힙니다. 특히 손가락으로 누르는 대상의 크기가 중요합니다. 화면에서 실제로 그려진 버튼이나 링크의 크기를 재서, 그것이 손가락으로 편하게 누를 수 있는 최소 기준인 가로세로 44픽셀에 못 미치는 곳을 짚어냅니다. "버튼이 작아서 자꾸 잘못 눌린다"는 민원이, 여기서는 화면을 실제로 그려서 재기 때문에 오픈 전에 수치로 잡히는 것입니다. 눈으로는 "좀 작나?" 싶던 게, 실제 그려진 크기로 재면 "기준 미달"로 딱 떨어집니다.

여기서 다시 렌더링의 의미가 살아납니다. 코드만 봐서는 "모바일에서 이 두 요소가 겹치는지"를 알 수 없습니다. 코드에 적힌 규칙만으로는 최종 배치가 어떻게 될지 확정되지 않으니까요. 실제로 모바일 크기로 그려봐야, 그 크기에서 요소들이 어디에 어떻게 놓이는지가 나옵니다. "여러 크기로 각각 진짜로 그려서 본다"는 게, 반응형 품질을 보는 유일하게 정직한 방법인 셈입니다.

반응형이 특히 중요한 이유는, 화면 크기에 따라 문제가 아예 다르게 나타나기 때문입니다. 데스크톱에서는 가로가 넉넉하니 요소들이 여유롭게 배치되지만, 모바일에서는 그 요소들이 세로로 쌓이면서 서로 겹치거나, 화면 밖으로 밀리거나, 가로 스크롤이 생깁니다. 같은 페이지인데 화면 크기 하나 바꿨다고 완전히 다른 문제가 튀어나오는 것이죠. 그래서 "데스크톱에서 통과했으니 모바일도 괜찮겠지"라는 짐작이 위험합니다. 실제로는 반대인 경우가 흔합니다. 데스크톱은 멀쩡한데 모바일만 깨지거나, 태블릿 크기에서만 애매하게 어긋나거나. 세 크기를 다 실제로 그려봐야 이 차이가 드러납니다. 그리고 요즘 공공 사이트 방문자의 상당수가 모바일로 들어온다는 걸 생각하면, 모바일 화면을 실제로 그려서 챙기는 일은 선택이 아니라 기본입니다. 사람이 손으로 점검할 때 가장 자주 빠뜨리던 "절반의 화면"을, 렌더링은 기본으로 챙깁니다.

위 화면은 그려진 화면 위의 부품 하나를 골라 뜯어본 모습입니다. "버튼 하나"가 화면에서 잰 색·간격·크기라는 측정값 묶음으로 바뀌고, 각 값이 기준과 대조되어 통과인지 미통과인지가 나옵니다. 화면을 실제로 그려서 재기 때문에 나올 수 있는 결과입니다.

---

본론 6 — 그래도 한계는 있습니다 (솔직히)

화면을 실제로 그려서 보는 게 강력하지만, 만능은 아닙니다. 지난달부터 지켜온 태도대로, 한계도 솔직하게 짚겠습니다. 강점만 자랑하고 한계를 숨기면, 그게 오히려 신뢰를 깎는 길이니까요.

눌러봐야 나오는 것

첫째, 가만히 그려낸 화면을 보는 것만으로는 다 잡히지 않는 게 있습니다. 폼을 비우고 제출했을 때 나오는 오류 메시지, 모달을 열고 닫는 흐름처럼 "동작을 해봐야 나오는 것들"입니다. 렌더링은 기본적으로 "지금 그려진 화면"을 재는 것이라, 사용자가 무언가를 눌러야 비로소 나타나는 동적인 영역은 별도의 처리가 필요합니다. 일부는 자동으로 흉내 낼 수 있지만, 복잡한 상호작용일수록 한계가 있습니다. 이런 동적 영역은 솔직히 자동화가 더 까다로운 부분입니다.

또 하나, URL만 넣어서 그려내는 건 기본적으로 누구나 접근할 수 있는 공개 페이지입니다. 로그인을 해야 들어가지는 페이지, 본인인증 뒤에 나오는 신청 내역 같은 건 주소만으로는 그려낼 수 없습니다. 공공 사이트는 민원이나 신청처럼 로그인 뒤가 중요한 경우가 많으니, "그려서 다 봤다"가 아니라 "공개 영역은 그려서 봤다"가 정확한 표현입니다. 이 경계를 흐리지 않는 게, 결과를 정직하게 읽는 출발입니다. 어디까지 자동으로 그려서 잡히고 어디부터 별도 처리가 필요한지, 그 경계를 분명히 해두는 게 오히려 신뢰를 지키는 길이라고 봅니다.

시각 감지도 틀릴 수 있다

둘째, 화면을 시각적으로 감지하는 것도 항상 완벽하지는 않습니다. 흐릿한 이미지나 배경과 구분이 잘 안 되는 요소는 잘못 감지하거나 못 감지할 수 있습니다. 그래서 앞서 말씀드렸듯, 시각적 감지 결과는 "확신도"와 함께 다룹니다. 확실히 감지한 것만 쓰고, 애매한 것은 무리하게 판정하지 않습니다. 무작정 다 믿으면 잘못된 판정으로 이어지니, 조심스럽게 다루는 것입니다.

화면은 '무엇이 있나'까지, '적절한가'는 그다음

셋째, 화면을 재는 것은 "어디에 무엇이 어떻게 있나"는 잘 보지만, "그게 사용자 흐름상 적절한가"는 재지 못합니다. 예를 들어 "이 버튼이 여기 있는 게 자연스러운가", "이 위반이 우리 기관 맥락에서 얼마나 급한가"는 측정값으로 나오지 않습니다. 그건 맥락 판단의 영역이라, 지난달에 말씀드린 세 번째 시점이 봐야 합니다. 화면 측정은 "측정"이지 "판단"이 아닙니다. 측정값을 깔끔하게 깔아주면, 판단은 그 위에서 이뤄집니다.

이 구분을 흐리지 않는 게 오히려 정직한 태도라고 생각합니다. "화면을 그려서 다 본다"고 뭉뚱그리면 듣기에는 좋지만, 실제로는 측정이 잘하는 영역과 판단이 필요한 영역이 분명히 나뉩니다. 렌더링과 화면 측정은 "무엇이 어떤 상태로 있는지"를 흔들림 없이 깔아주는 데까지가 강점이고, "그래서 무엇부터 고쳐야 하는지"는 그 위에 사람과 판단 시점이 얹혀야 답이 나옵니다. 이 경계를 솔직히 그어두는 게, 오히려 각 단계를 제대로 쓰는 길입니다.

그래서 조합입니다

이 한계들 때문에, 화면을 그려서 보는 것 하나로 모든 걸 끝내지 않습니다. 렌더링으로 화면을 그리고, 그 화면에서 구조·계산값·시각을 함께 읽고, 그 위에서 맥락을 판단하는 — 각자 잘하는 걸 합치는 구조입니다. 화면을 그려서 보는 단계는 "코드가 못 보는 시각·이미지 문제"를 메우는 핵심 조각이지, 그 자체로 전부는 아닙니다. 전부인 척하면 그것도 또 하나의 "한 시점만 보기"가 됩니다.

여기서 재미있는 균형이 있습니다. 코드 분석은 구조는 정확히 보지만 보이는 결과는 모르고, 화면 분석은 보이는 결과는 보지만 구조적 의미는 약합니다. 화면 분석은 "여기 버튼처럼 생긴 게 있다"까지는 보는데, 그게 코드상 진짜 버튼으로 정의돼 있는지는 코드를 봐야 압니다. 그래서 "화면엔 버튼인데 코드엔 버튼이 아님 → 접근성 문제"라는 결론은, 화면 분석과 코드 분석을 맞대야 나옵니다. 한쪽만으로는 절반이고, 둘을 겹쳐야 "보이는 것과 실제 구조의 불일치"가 드러납니다. 렌더링으로 화면을 그려두는 게 그 겹쳐보기의 토대가 되는 것입니다.

---

그래서 ViewCheck는

ViewCheck의 URL 분석이 화면을 보는 방식이 바로 이 렌더링 기반입니다. 주소 한 줄을 넣으면, 진짜 브라우저처럼 페이지를 끝까지 그려냅니다. 자바스크립트가 다 돌고 이미지가 다 붙은, 사용자가 실제로 보는 그 화면을 만들어냅니다. 그것도 데스크톱·태블릿·모바일 세 크기로 각각 그려서요. 그런 다음 그 그려진 화면에서 구조를 읽고, 실제 계산값을 읽고, 시각적으로 감지해서, 코드만으로는 놓치던 이미지 버튼·시각 위반·모바일 깨짐 같은 걸 잡아냅니다.

거창한 게 아니라, "사용자가 보는 화면을 기계가 있는 그대로 그려서 본다"는 것입니다. 코드라는 설계도가 아니라, 그 설계도가 그려낸 결과물을요. 사람이 화면을 보며 무의식적으로 하던 "저기 버튼 있고, 신청이라고 써 있고, 좀 작네"를, 기계가 구조·계산값·시각으로 나눠 정밀하게 읽고 합쳐서 해냅니다. 그리고 한계 — 동적 영역, 시각 감지 오류, 맥락 판단 불가 — 는 솔직히 인정하고, 코드 분석과 판단 시점을 조합해서 메웁니다.

한 가지 더 강조하고 싶은 건, 이 렌더링 기반이라는 토대가 URL 분석뿐 아니라 다른 분석에도 그대로 이어진다는 점입니다. 화면을 실제로 그려서 색·타이포·간격·모서리·크기를 KRDS 공식 기준과 대조하는 이 방식은, 설계 단계의 디자인 파일을 볼 때도 같은 원리로 작동합니다. 운영 중인 사이트든 설계 중인 디자인이든, 결국 "사람이 눈으로 볼 결과물을 기준으로 잰다"는 원칙은 한결같습니다. 그래서 오늘 이야기는 URL 분석 한 곳에만 국한된 게 아니라, ViewCheck가 화면을 대하는 태도 전체를 관통하는 이야기이기도 합니다.

이 렌더링된 화면과 그 측정값이 다음 단계로 넘어갑니다. 이 측정값으로 어떻게 846규칙을 판정하고 준수율을 내는지는 다음 달(3개월차)에서 본격적으로 풀고, 오늘은 "코드가 아니라 그려진 화면을 기준으로 삼는다"는 그 토대까지입니다. 한 가지 덧붙이면, 이 "실제로 그려서 본다"가 왜 그렇게 중요한지는 지난달 이야기를 떠올리면 분명합니다. 사람의 수작업 점검이 안고 있던 큰 문제가 편차와 재현 불가였습니다. 사람마다, 날마다 다르게 보니 결과를 믿기 어려웠습니다. 화면을 실제로 그려서 좌표·색·크기의 숫자로 바꿔놓으면, 누가 봐도 같고 다시 봐도 같습니다. "느낌"을 "측정"으로 바꾸는 것 — 그 출발점이 바로 이 렌더링 단계입니다.

🔐 특허로 지키는 부분

오늘 본 "URL만으로 사이트를 실제 사용자처럼 끝까지 그려내고, 그 그려진 화면에서 시각과 구조를 함께 재며, 여러 화면 크기로 각각 그려서 보는 방법"은 ViewCheck가 출원한 5건의 특허 중 렌더링 기반 화면 수집·측정 주제와 맞닿아 있습니다. 말로는 "화면을 그려서 본다"로 간단해 보여도, 자바스크립트가 다 돌고 외부 요소가 다 붙은 진짜 화면을 안정적으로 그려내고, 같은 화면을 누가 봐도·몇 번을 재도 같은 수치가 나오게 만드는 절차 — 어떤 기준으로 요소를 잡고, 좌표·색·크기를 어떻게 뽑는지 — 자체를 권리로 정리해 둔 데 차별점이 있습니다.

다만 솔직히 짚어둘 게 있습니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 측정이 실제로 정확하냐는 오늘 본 렌더링과 화면 판독이 얼마나 사용자가 보는 화면에 가깝게 작동하느냐로 결정되는 것이고, 특허는 그 방법을 보호하는 것입니다. 그래서 "특허가 있으니 믿으세요"가 아니라 "이 방법을 직접 만들고 지켜두었다" 정도로 받아들여 주시면 됩니다. 그리고 현재는 출원 중입니다. "등록특허"가 아니라 "출원 기술"로 정확히 표기합니다. (특허 출원 기술 / 자체 개발)

마무리

오늘은 렌더링, 즉 "실제로 그려낸 화면을 기준으로 본다"는 것의 의미를 봤습니다. 웹페이지에는 코드라는 설계도와 그것이 그려낸 화면이라는 결과물, 두 층이 있고, 사용자는 결과물을 씁니다. 그래서 결과물을 봐야 하는데 — 요즘 사이트는 코드만 받아오면 빈 껍데기라, 진짜 브라우저처럼 끝까지 그려내야 사용자가 보는 화면이 나옵니다. 그렇게 그려낸 화면에서 구조·실제 계산값·시각을 함께 읽으면, 코드만으로는 놓치던 이미지 버튼·시각 수치·시각 관계가 드러납니다. 그것도 세 가지 화면 크기로 각각 그려서 보니, 모바일에서만 생기는 문제까지 챙깁니다. 단, 동적 영역·시각 감지 오류·맥락 판단은 한계라, 코드 분석과 판단 시점을 조합합니다.

한 줄로 줄이면, "코드가 아니라 그려진 결과물을 본다"가 렌더링 기반 분석입니다. 코드는 설계도, 화면은 사용자가 마주하는 결과물이고, 그 결과물을 실제로 그려내서 재는 것 — 그게 URL 분석이 다른 코드 기반 도구와 근본적으로 갈리는 지점입니다. 사람이 눈으로 "보고 느끼던" 일을, 기계가 "그려서 재는" 일로 바꾼 셈입니다. 그리고 이 바꿈이 있어야, 지난달부터 이야기해 온 "감이 아니라 근거로 보는 점검"이 비로소 가능해집니다. 그려진 화면을 숫자로 바꿔놓아야, 그 숫자가 재현되고, 재현되어야 증빙이 되니까요.

이번 주 나머지 글에서 더 들어가겠습니다. 수요일엔 "같은 화면인데 코드가 달라서 구조 분석이 컴포넌트를 놓치는" 사례를 익명으로 풀고, 금요일엔 그려진 화면에서 실제로 무엇을 어떻게 뽑아내는지를 한눈에 정리하겠습니다. 오늘이 "왜 그려진 화면을 봐야 하느냐"였다면, 수요일은 "코드가 화면을 어떻게 배신하느냐", 금요일은 "그래서 화면에서 무엇을 뽑느냐"인 셈입니다.

오늘 딱 하나만 가져가신다면 이 문장이면 좋겠습니다. 사용자는 코드를 보지 않고 화면을 봅니다. 그러니 품질도 코드가 아니라, 실제로 그려진 화면을 기준으로 봐야 합니다. 설계도가 아니라 결과물을, 짐작이 아니라 실제로 그려낸 그 화면을 보는 것 — 그 단순한 원칙을 끝까지 지키는 게 렌더링 기반 분석의 전부입니다. 오늘도 끝까지 읽어주셔서 고맙습니다. 수요일에 사례로 이어가겠습니다.

krds.viewcheck.co.kr