"왜 이 사이트만 분석이 안 되죠?" — 화면 캡처가 실패하는 사이트들 (보안 장비·동적 렌더링)

---

들어가며 — 제일 잘 깨지는 단계, 렌더링

지난주에는 URL 분석이 "지금 돌아가는 진짜 운영 사이트"를 본다는 이야기를 드렸습니다. 만든 환경이 아니라 사용자가 실제로 쓰는 환경, 테스트 데이터가 아니라 진짜 데이터, 어제가 아니라 오늘을 본다는 것이었죠. 그런데 그 "진짜 화면을 본다"는 게, 말은 간단해도 실제로는 가장 자주 깨지는 대목입니다. 오늘은 바로 그 이야기입니다. 왜 어떤 사이트는 분석이 매끄럽게 되고, 어떤 사이트는 화면 캡처부터 실패하는지를요.

자동 분석을 써보신 분이라면 한 번쯤 겪으셨을 겁니다. 잘 되던 도구가 특정 사이트에서만 "분석 실패"나 "화면을 가져올 수 없습니다"를 뱉는 경우요. 또는 분석은 됐는데 결과 화면이 이상하게 텅 비어 있거나, 절반만 그려져 있거나, 엉뚱한 화면이 잡혀 있는 경우도 있습니다. 이게 전부 "화면을 실제로 그리는" 단계, 그러니까 렌더링 단계에서 뭔가 어긋난 것입니다.

이게 왜 중요하냐면, 화면을 제대로 못 그리면 그 페이지는 분석 자체가 안 되기 때문입니다. 코드가 아니라 화면을 봐야 하는 방식에서는, "화면이 없으면 볼 게 없다"가 됩니다. 그래서 "이 사이트 분석 잘 되네"라는 말의 절반은, 사실 "이 사이트를 안정적으로 그려낼 수 있네"라는 뜻입니다. 렌더링이 약한 도구는 까다로운 사이트에서 무너집니다. 도구의 진짜 실력은 쉬운 사이트가 아니라 까다로운 사이트에서 드러나는 것이죠.

오늘은 렌더링이 실패하거나 어긋나는 전형적인 경우들을, 전부 익명 사례로 풀어보겠습니다. 특정 사업이나 특정 기관을 지적하려는 게 아니라, 어디서나 비슷하게 반복되는 패턴이라 하나로 묶어서 봅니다. 크게 여섯 갈래로 가보겠습니다. 보안 장비에 막히는 경우, 자바스크립트가 뒤늦게 채우는 동적 화면, 끝이 없는 무한 스크롤, 팝업·쿠키 배너·느린 로딩·지역 제한 같은 가림막들, 그리고 "그려지긴 했는데 진짜가 아닌" 가짜 화면, 마지막으로 그걸 어떻게 넘어서는지까지요.

한 가지 미리 짚어드리면, 이 문제들은 "도구가 못 만들어서" 생기는 게 아닙니다. "웹이 원래 제각각이라서" 생깁니다. 세상 모든 사이트가 똑같은 방식으로 만들어졌다면 렌더링도 쉬울 텐데, 현실은 사이트마다 만든 방식·속도·정책이 다 다릅니다. 오래된 사이트, 최신 프레임워크로 지은 사이트, 외부 모듈이 잔뜩 붙은 사이트, 보안이 빡빡한 사이트… 이 다양함을 전부 안정적으로 다루는 게 렌더링의 숙제입니다. 그래서 "왜 이 사이트만 안 되지?"라는 물음은, 사실 "이 사이트가 다른 방식으로 만들어졌구나"인 경우가 대부분입니다. 오늘 글을 다 읽으시면, 특정 사이트에서만 결과가 휑하게 나올 때 그 원인을 짚는 감이 조금 잡히실 겁니다.

그리고 하나 더 말씀드리면, 오늘 이야기의 밑바닥에는 지난주와 같은 정신이 흐릅니다. "못 본 건 못 봤다고 정직하게 남긴다"는 것이요. 렌더링이 실패했을 때 가장 나쁜 처리는 실패를 감추고 "분석 완료"로 넘겨버리는 것입니다. 가장 좋은 처리는 "이 페이지는 이런 이유로 제대로 못 봤다"고 구분해서 남기는 것이고요. 오늘 여섯 갈래를 관통하는 핵심이 바로 이 정직함입니다.

조금 다르게 표현하면, 오늘 이야기는 "화면을 그리는 일"이 실은 하나의 관문이라는 것입니다. 우리는 흔히 분석이라고 하면 "무엇이 규칙에 맞고 안 맞나를 따지는" 뒷단을 떠올립니다. 그런데 그 뒷단이 아무리 정교해도, 앞단에서 화면을 제대로 못 그리면 뒷단은 헛돕니다. 잘못 그려진 화면을 아무리 꼼꼼히 따져봐야, 결론은 잘못된 화면에 대한 결론일 뿐이니까요. 그래서 "무엇을 보느냐"의 정확성이 "어떻게 따지느냐"의 정교함보다 먼저입니다. 오늘은 그 "무엇을 보느냐"가 어디서 어긋나는지를 하나씩 짚는 자리입니다. 뒷단의 규칙 이야기는 다음 달들에서 본격적으로 다룰 텐데, 그 전에 앞단이 튼튼해야 한다는 것을 오늘 먼저 짚어두는 셈입니다.

본론 1 — 문 앞에서 막힘: 보안 장비(접근 차단)

기계적 접속을 막는 사이트

첫 번째 갈래는 보안 장비입니다. 일부 사이트는 앞단에 접속을 걸러내는 보안 장비를 두고, 기계적인 접속(자동화된 접근)을 막아둡니다. 보안이나 트래픽 관리 때문이죠. 그래서 자동 분석이 접속하면 "이건 사람이 아닌 것 같은데?" 하고 막거나, 진짜 화면 대신 "접근이 제한되었습니다", "비정상적인 접근이 감지되었습니다" 같은 대체 페이지를 돌려줍니다.

이러면 분석 도구는 "화면을 가져왔다"고 생각하는데, 사실 그 화면이 진짜 사이트가 아니라 차단 안내 페이지입니다. 그럼 엉뚱한 걸 분석하게 됩니다. 차단 페이지를 보고 "이 사이트는 내용이 거의 없네"라고 결론 내리는, 황당한 일이 벌어지는 것이죠. 화면은 분명히 캡처됐는데, 그 안에 우리가 보려던 페이지는 없는 셈입니다.

이게 특히 곤란한 이유는, 실패가 실패처럼 안 보인다는 데 있습니다. "화면을 못 가져왔습니다"라고 대놓고 실패하면 차라리 다시 시도하면 됩니다. 그런데 차단 페이지는 어쨌든 하나의 멀쩡한 화면이라, "성공적으로 가져왔다"로 착각하기 쉽습니다. 그래서 보안 장비 문제는 "실패를 성공으로 오인하는" 위험까지 안고 있습니다.

보안 장비의 대응 방식도 한 가지가 아닙니다. 어떤 곳은 아예 접속을 끊어버려 "연결할 수 없음"으로 실패시키고, 어떤 곳은 잠깐 기다리라는 대기 화면을 보여주며, 어떤 곳은 앞서 말한 것처럼 "접근이 제한되었습니다" 같은 안내 페이지를 돌려줍니다. 제각각이라, 도구 입장에서는 "이게 정상 화면인지 차단인지"를 매번 새로 가려야 합니다. 그래서 보안 장비를 다루는 일은 "한 가지 방법으로 다 통하는" 문제가 아니라, 사이트마다 다른 반응을 그때그때 읽어내야 하는 문제입니다. 이 점이 보안 장비를 특히 까다롭게 만듭니다.

사람처럼, 실제 브라우저로 접속하기

이걸 풀려면 지난주에 잠깐 언급한 그 방식이 필요합니다. 실제 사용자가 쓰는 브라우저와 똑같은 방식으로, 화면 뒤에서(헤드리스로) 페이지를 진짜로 그려내며 접속하는 것이죠. 코드만 긁어오는 게 아니라, 진짜 브라우저가 페이지를 여는 것과 같은 경로로 들어가면, 사이트 입장에서도 일반 방문자와 비슷하게 보이니 진짜 화면을 받을 가능성이 높아집니다.

다만 이것도 사이트마다 정책이 달라서, 그래도 끝까지 막는 사이트가 있습니다. 여기서 중요한 태도는 "무리하게 뚫으려 하지 않는다"입니다. 사이트가 자동 접속을 막아두었다면 그 정책에는 이유가 있고, 그걸 억지로 우회하는 건 사이트에 부담을 주는 일이기도 합니다. 그래서 가능한 범위에서 정중하게 접속하되, 그래도 막히는 사이트는 "여기는 자동으로 못 봤다"고 정직하게 남기는 게 맞습니다. 무리한 우회로 몇 페이지 더 긁는 것보다, 못 본 걸 못 봤다고 밝히는 편이 결과의 신뢰를 지킵니다.

차단을 못 넘거나, 착각하면

보안 장비를 못 다루는 도구는 두 가지로 실패합니다. 하나는 그 사이트를 아예 못 보고 분석에서 통째로 빠지는 것이고, 다른 하나는 차단 페이지를 진짜 사이트로 착각해 엉뚱한 걸 분석하는 것입니다. 둘 다 문제인데, 특히 후자가 더 고약합니다. 못 본 건 "못 봤다"고 표시라도 되는데, 착각한 건 "봤다"고 결과에 섞여 들어가니까요.

그래서 "받아온 이 화면이 진짜 사이트가 맞나"를 확인하는 것도 렌더링 단계의 중요한 일이 됩니다. 단순히 "화면을 받았다"가 아니라 "제대로 된 화면을 받았나"를 한 번 더 가려야 하는 것이죠. 이 판별 이야기는 뒤의 본론 5에서 다시 자세히 다루겠습니다.

여기서 묘한 역설이 하나 있습니다. 보안이 잘 갖춰진 사이트일수록 차단이 빡빡해서, 자동 분석이 더 어렵다는 것입니다. 정작 잘 관리된 사이트가 분석하기에는 더 까다로운 경우가 생기는 셈이죠. 그래서 "이 사이트는 분석이 잘 안 된다"가 곧 "이 사이트가 부실하다"를 뜻하지는 않습니다. 오히려 그 반대일 수도 있습니다. 이 점을 구분해서 다루는 것도 정직한 분석의 몫입니다.

공공 사이트에서 특히 자주 겪는 이유

공공 사이트에서는 이 보안 장비 문제를 유독 자주 겪습니다. 이유가 있습니다. 공공 사이트는 민감한 정보를 다루는 경우가 많고, 외부의 자동화된 공격 시도에 대한 방어를 앞단에 두는 것이 일반적이기 때문입니다. 그래서 사람이 브라우저로 들어가면 멀쩡히 열리는데, 자동 접속처럼 보이는 요청은 앞단에서 걸러지는 경우가 종종 있습니다. 담당자 입장에서는 "우리 사이트는 잘 열리는데 왜 저 도구는 못 본다는 거지?" 싶으실 수 있는데, 이건 도구가 부실해서가 아니라 사이트가 자동 접속을 막고 있어서일 때가 많습니다.

이럴 때 중요한 건, 도구가 "못 봤다"를 어떻게 처리하느냐입니다. 어떤 도구는 이걸 조용히 삼키고 마치 문제가 없는 것처럼 넘어갑니다. 그러면 담당자는 "우리 사이트는 아무 이상 없다"는 잘못된 안심을 하게 됩니다. 좋은 처리는 "이 페이지는 보안 장비 때문에 자동으로 접근하지 못했다"고 명확히 남기는 것입니다. 그래야 담당자가 "아, 여기는 별도로 확인해야겠구나" 하고 대응할 수 있습니다. 못 본 것을 못 봤다고 밝히는 게, 결국 담당자에게 더 유용한 정보인 셈입니다.

본론 2 — 자바스크립트가 뒤늦게 채우는 화면: 동적 렌더링

처음엔 빈 껍데기, 나중에 채워지는 화면

두 번째 갈래는 동적 렌더링입니다. 요즘 사이트는 처음 받아오는 화면이 빈 껍데기인 경우가 많습니다. 첫 화면에는 뼈대만 있고, 그다음에 자바스크립트가 돌면서 메뉴·목록·본문·이미지를 하나씩 채웁니다. 사용자 눈에는 순식간에 다 뜬 것처럼 보이지만, 실제로는 "받아온 뒤에 그려지는" 시간차가 있습니다.

문제는, 페이지를 띄우고 너무 빨리 캡처하면 아직 안 채워진 상태를 찍는다는 것입니다. 메뉴가 안 떴거나, 목록이 비어 있거나, 이미지가 안 나온 상태로요. 이러면 화려한 사이트인데도 "내용이 거의 없는 휑한 사이트"로 잡힙니다. 코드만 긁어보는 방식이 요즘 사이트에서 특히 약한 이유가 여기 있습니다. 코드(첫 껍데기)에는 정작 중요한 내용이 안 들어 있고, 그 내용은 화면이 다 그려진 뒤에야 나타나니까요. 그래서 "코드가 아니라 화면을 끝까지 그려서 본다"는 원칙이 중요합니다.

특히 핵심 기능이 자바스크립트로 뒤늦게 그려지는 사이트라면, 그 핵심을 통째로 놓칠 수 있습니다. 검색 결과, 동적으로 펼쳐지는 메뉴, 외부에서 불러오는 위젯 같은 게 다 그렇습니다. 화면은 캡처됐는데 정작 봐야 할 게 빠진, "겉만 그려진" 화면이 되는 것이죠.

지연 로딩 — "충분히 다 떴나"를 판단하기

여기에 지연 로딩이 겹칩니다. 어떤 사이트는 외부에서 데이터를 받아와 화면을 채우는데, 그 외부 응답이 느리면 한참 동안 빈 화면입니다. 이때 캡처하면 "내용 없는 사이트"로 보입니다. 실제로는 잠시 후 다 뜨는데도요. 그래서 "충분히 다 떴나"를 기다렸다가 봐야 합니다.

그런데 "충분히 다 떴나"를 아는 게 생각보다 까다롭습니다. 무작정 오래 기다리면 페이지 하나에 시간이 너무 듭니다. 수십에서 수백 페이지를 보는데 페이지마다 길게 기다리면 분석이 끝이 없어지죠. 반대로 너무 빨리 진행하면 미완성 화면을 찍습니다. 그래서 "다 떴는지"를 똑똑하게 판단해서, 다 떴으면 바로 진행하고 아직이면 적당히 더 기다리는 균형이 필요합니다. 너무 빨라도(미완성), 너무 늦어도(시간 낭비) 안 되는 것입니다.

이 판단은 몇 가지 신호로 합니다. 화면 높이가 더 안 변하는지, 로딩 표시가 사라졌는지, 주요 요소가 다 나타났는지 같은 것들이요. 사람은 화면을 보며 "이제 다 떴네" 하고 직관적으로 아는데, 기계는 그걸 신호로 판단해야 합니다. 이 판단이 정교할수록 빠르면서도 빠짐없이 봅니다. 그리고 이 "다 떴나"는 한 화면 크기에서만이 아니라, 데스크톱·태블릿·모바일 각각에서 확인해야 합니다. 같은 페이지라도 화면 크기에 따라 배치가 달라지고, 어떤 크기에서만 늦게 뜨는 요소가 있을 수 있으니까요.

동적 렌더링을 놓치면

동적 렌더링을 못 다루면, 뒤늦게 뜨는 콘텐츠를 통째로 놓칩니다. 그럼 위반이 적어 보이는데, 사실은 콘텐츠를 다 안 본 것입니다. 이건 "문제가 없어서 위반이 적은" 것과 겉으로는 똑같아 보여서 더 위험합니다. 실제로는 "안 봐서 위반이 안 잡힌" 것인데도요.

한 사이트는 메인의 제일 큰 영역이 외부에서 받아오는 슬라이드 배너였는데, 그게 뜨는 데 몇 초가 걸렸습니다. 분석이 그걸 안 기다리고 찍으니, 메인의 핵심 영역이 텅 빈 채로 캡처됐습니다. 그러니 "메인이 휑하다"는 엉뚱한 판단이 나온 것이죠. 실제로는 화려한 배너가 있는데도요. 반대로 어떤 사이트는 모든 게 빨리 떠서 굳이 안 기다려도 됐습니다. 이렇게 사이트마다 "뜨는 속도"가 천차만별이라, 일률적으로 "몇 초 기다린다"가 아니라 "이 사이트는 지금 다 떴나"를 그때그때 판단해야 합니다. 그게 까다로운 부분입니다.

한 걸음 더 들어가 보면, 동적 렌더링은 "코드만 보는 방식"과 "화면을 그려서 보는 방식"의 차이를 가장 극명하게 드러내는 대목입니다. 코드만 긁어오는 방식은 첫 껍데기, 즉 아직 내용이 안 채워진 뼈대만 봅니다. 그 뼈대에는 "여기에 목록이 들어올 것"이라는 표시만 있고, 정작 어떤 목록이 어떻게 들어왔는지는 없습니다. 그러니 코드만으로는 "화면에 실제로 무엇이 그려졌나"를 알 수 없습니다. 반면 화면을 끝까지 그려서 보는 방식은, 사용자가 실제로 마주하는 그 완성된 화면을 봅니다. 요즘 사이트가 점점 더 자바스크립트로 화면을 채우는 쪽으로 가고 있어서, 이 차이는 앞으로 더 벌어질 겁니다. "코드가 아니라 화면을 본다"는 원칙이 단순한 구호가 아니라 실질적인 차이를 만드는 이유가 여기 있습니다.

본론 3 — 끝이 없는 화면: 무한 스크롤

스크롤해야 나타나는 콘텐츠

세 번째 갈래는 무한 스크롤입니다. 요즘 사이트는 한 번에 다 보여주지 않고, 스크롤을 내릴수록 콘텐츠가 더 나타나는 경우가 많습니다. 게시글 목록이 끝없이 이어지거나, 이미지가 스크롤할 때마다 하나씩 뜨거나요. 사용자는 스크롤을 내려가며 다 보는데, 분석은 페이지를 띄우자마자 캡처하면 "맨 위 일부"만 찍습니다. 아직 스크롤을 안 내렸으니 아래 콘텐츠가 안 그려진 상태니까요.

그래서 화면 절반이 텅 빈 채로 캡처되거나, 목록이 몇 개만 보이는 채로 분석됩니다. 사용자는 스크롤을 내려서 수백 개를 다 보는데, 분석은 맨 위 몇 개만 본 셈입니다. 이러면 콘텐츠가 가득한 페이지가 "내용 적은 페이지"로 둔갑합니다.

어디까지 내려야 하나

이걸 풀려면 분석할 때도 스크롤을 내려서 콘텐츠를 불러와야 합니다. 그런데 "어디까지" 내릴지가 문제입니다. 무한 스크롤은 말 그대로 끝이 없을 수 있습니다. 끝까지 내리려다 영원히 못 끝낼 수도 있고, 너무 일찍 멈추면 또 절반만 봅니다. 그래서 "충분히 내렸나, 더 내려도 새 콘텐츠가 안 나오나"를 판단하면서 적절히 멈춰야 합니다. 사람이 "이쯤이면 됐다" 하고 멈추던 그 감각을 자동으로 흉내 내야 하는 것이죠.

판단 기준은 보통 "더 내려도 새 콘텐츠가 안 나오면 멈춘다"입니다. 스크롤을 내렸는데 화면 높이가 더 안 늘어나면, 끝에 도달했거나 더 불러올 게 없는 것입니다. 그때 멈춥니다. 다만 점검 목적상 "수백 개를 다 봐야 하나"라는 현실적 고민도 있습니다. 게시글 1,000개를 전부 보는 게 의미 있을 때도, 없을 때도 있으니까요. 그래서 "어느 선까지"는 점검 목적과 시간 예산에 따라 정하되, 적어도 "맨 위 몇 개만 보고 끝"은 아니게 충분히 내리는 게 핵심입니다.

이 고민이 본론 2의 지연 로딩과 사실 같은 뿌리입니다. 둘 다 "충분히 됐나"를 판단해서 멈추는 문제니까요. 지연 로딩은 "콘텐츠가 다 떴나", 무한 스크롤은 "더 내려도 새 게 없나". 결국 핵심은 "기계가 사람처럼 '이제 됐다'를 알아채는 것"입니다. 이 판단력이 요즘 사이트를 제대로 보는지를 가르는 한 기준이 됩니다.

그리고 무한 스크롤에는 한 가지 더 미묘한 지점이 있습니다. 스크롤을 내리면서 새 콘텐츠가 불러와질 때, 위쪽의 오래된 콘텐츠는 화면에서 걷어내는 사이트도 있다는 것입니다. 화면을 가볍게 유지하려는 방식인데, 이러면 "끝까지 내렸을 때 화면에 남아 있는 건 마지막 부분뿐"이 되기도 합니다. 그래서 무한 스크롤을 다룰 때는 그저 끝까지 내리는 게 능사가 아니라, 내리는 과정에서 나타난 콘텐츠를 놓치지 않고 챙기는 것도 함께 신경 써야 합니다. 이런 세부까지 다루려면, "한 번 찍고 끝"이 아니라 "내려가며 살펴본다"는 태도가 필요합니다.

무한 스크롤을 못 다루면

무한 스크롤을 못 다루는 도구는 그런 사이트에서 "맨 위만" 봅니다. 그럼 결과가 빈약하게 나옵니다. 앞서 말씀드렸듯, 위반이 적어 보이는데 사실은 콘텐츠를 다 안 본 것이죠. 실제로 어떤 게시판형 페이지를 분석했더니 "콘텐츠가 거의 없다"는 결과가 나온 적이 있습니다. 이상해서 직접 들어가 보니, 스크롤을 내릴수록 게시글이 수백 개 이어지는 무한 스크롤 페이지였습니다. 분석은 맨 위 몇 개만 보고 "내용 적음"으로 판단한 것이었고요. 사람이 보면 콘텐츠가 가득한 페이지인데, 캡처는 빈 페이지로 본 셈입니다. 이런 건 스크롤을 충분히 내려서 콘텐츠를 다 불러온 다음에야 제대로 잡힙니다.

본론 4 — 화면을 가리는 것들: 팝업·쿠키 배너·느린 로딩·지역 제한

팝업과 쿠키 배너에 가림

네 번째 갈래는 화면을 가리는 것들입니다. 사이트를 열자마자 큰 팝업 공지가 뜨거나, 쿠키 동의 배너가 화면 아래를 덮거나, 전면 광고가 화면 전체를 가리는 경우가 있습니다. 이 상태로 캡처하면, 정작 봐야 할 콘텐츠는 가림막 뒤에 있는데 가림막만 찍힙니다. 화면 한가운데를 큰 팝업이 차지하고, 그 뒤의 실제 페이지는 안 보이는 것이죠.

이걸 다루려면 가림막을 적절히 처리하고 봐야 합니다. 닫을 수 있는 건 닫고, 감안할 건 감안해서, 그 뒤의 진짜 콘텐츠가 캡처되게 하는 것입니다. 다만 여기서도 조심스러운 태도가 필요합니다. 쿠키 동의 배너처럼 사용자의 선택이 필요한 요소를 함부로 눌러 처리하는 건 신중해야 하니, "화면을 읽기 위해 가림막을 감안하되, 사이트에 영향을 주는 행동은 최소화한다"는 균형을 지킵니다. URL 분석은 기본적으로 사이트를 "읽기만" 하지, 무언가를 제출하거나 바꾸지 않는다는 원칙 위에서 이 처리가 이뤄집니다.

느린 로딩 — 오래 걸리는 사이트

가림막과는 결이 다르지만, 느린 로딩도 캡처를 어긋나게 만듭니다. 어떤 사이트는 첫 화면이 뜨는 데만도 한참 걸립니다. 외부 모듈이 많이 붙었거나, 큰 이미지가 잔뜩이거나, 서버 응답이 느리거나 해서요. 이러면 "다 떴나"를 판단하는 시간이 길어지고, 페이지 하나에 드는 시간이 늘어납니다. 앞서 본 "너무 오래 기다리면 분석이 끝이 없다"는 문제가 여기서 실제로 나타나죠.

그런데 느린 로딩은 그 자체가 중요한 진단 대상이기도 합니다. 사용자에게도 이 사이트는 느린 사이트일 테니까요. 그래서 "얼마나 빨리, 얼마나 안정적으로 뜨는지"를 재는 것 자체가 하나의 점검 항목이 됩니다. 화면이 뜨는 데 오래 걸리는지, 뜨는 도중에 배치가 출렁이며 밀리는지, 특정 리소스가 유독 느린지 같은 것들을요. 캡처를 방해하는 느린 로딩이, 뒤집어 보면 "이 사이트의 성능이 이렇다"는 실측 데이터가 되는 셈입니다.

이 성능 이야기는 사실 행안부가 정한 웹사이트 품질의 여러 영역 — 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성 — 중 효율성이나 접속성과 맞닿아 있습니다. 페이지가 빨리 뜨는지, 안정적으로 접속되는지는 그 자체로 품질의 한 축이니까요. 그래서 캡처 과정에서 마주치는 "느려서 다 뜰 때까지 기다려야 하는" 상황이, 단지 캡처를 방해하는 걸림돌로 끝나지 않고 "이 사이트는 이만큼 느리다"는 진단으로 이어집니다. 걸림돌을 데이터로 바꾸는 셈이죠. 캡처가 어렵다는 사실 자체에서도 사이트에 대한 정보를 얻는 것입니다.

지역·권한에 따라 다른 화면

또 하나, 접속하는 환경에 따라 다른 화면이 나오는 경우가 있습니다. 어떤 사이트는 접속 위치나 권한에 따라 다른 화면을 보여줍니다. 분석이 접속한 환경에서 보이는 화면이, 실제 대상 사용자가 보는 화면과 다를 수 있는 것이죠. 이러면 "맞는 화면을 봤는지"가 애매해집니다. 분명 화면은 그려졌는데, 그게 우리가 확인하려던 그 화면이 맞는지 확신하기 어려운 상황입니다.

이건 "실패"로 잡히지 않아서 더 까다롭습니다. 화면은 멀쩡히 그려졌으니 도구는 성공으로 처리하는데, 그 화면이 대상 사용자가 보는 것과 다르면 결과의 의미가 흐려집니다. 그래서 이런 경우도 "본 화면이 어떤 조건에서의 화면인지"를 인지하고, 확신이 안 서면 그 한계를 남기는 게 정직한 처리입니다.

이 지역·권한별 화면 문제는 앞서 본 로그인 안쪽 이야기와도 이어집니다. 공통점은 "접속하는 쪽의 조건에 따라 보이는 게 달라진다"는 것이죠. 로그인 여부, 접속 위치, 부여된 권한 — 이런 조건들이 화면을 바꿉니다. 그래서 "URL 하나를 넣으면 그 사이트의 모든 화면을 다 본다"는 건 애초에 성립하기 어렵습니다. 자동 분석이 보는 건 "특정 조건에서 열리는 공개 화면"이고, 그 조건 밖의 화면들은 별도의 영역으로 남습니다. 이 경계를 흐리지 않고 분명히 하는 것, 즉 "여기까지가 자동으로 본 범위다"를 정직하게 긋는 것이 오히려 결과를 믿게 만듭니다. 경계를 뭉개고 "다 봤다"고 하는 순간, 그 결과 전체의 신뢰가 흔들리니까요.

가림막들의 공통점

팝업·배너·전면 광고, 느린 로딩, 지역·권한별 화면 — 이 가림막들의 공통점은 "화면은 그려졌다"는 것입니다. 실패로 잡히지 않고 그냥 분석으로 넘어가기 쉽습니다. 그런데 그려진 게 우리가 보려던 진짜 콘텐츠가 아닙니다. 이 지점이 다음 본론의 핵심으로 이어집니다. "그려지긴 했는데 진짜가 아닌" 경우를 어떻게 가려내느냐 하는 문제로요.

본론 5 — 그려지긴 했는데 가짜인 경우

가장 위험한 실패는 "성공처럼 보이는 실패"

지금까지 본 함정들을 관통하는 가장 위험한 형태가 이것입니다. 실패하면 차라리 "실패했네" 하고 다시 시도하면 됩니다. 그런데 "그려지긴 했는데 진짜가 아닌" 경우는 알아채기가 어렵습니다. 보안 장비의 차단 페이지, 로그인 화면, 팝업에 가린 화면, 덜 그려진 화면이 다 여기 해당합니다. 이것들은 하나의 멀쩡한 화면이라, 도구가 "성공적으로 캡처했다"로 착각하기 쉽습니다.

지난달에 짚었던 로그인 안쪽 이야기도 이 갈래입니다. 로그인을 해야 보이는 페이지는, 그냥 접속하면 로그인 화면만 보입니다. 분석은 "화면 가져왔다"고 하지만, 그건 로그인 화면이지 우리가 보려던 신청 내역이나 마이페이지가 아닙니다. 그래서 "URL 분석으로 다 봤다"가 아니라 "공개 영역은 봤다"가 정확한 표현이라고 말씀드렸던 것이죠.

이 "가짜 화면"이 제일 위험한 이유는 분명합니다. 실패는 "실패했네" 하고 다시 시도하면 그만인데, 가짜 화면은 "성공했네" 하고 엉뚱한 걸 결과로 내니까요. 그래서 좋은 도구는 "캡처 성공"에서 멈추지 않고 "제대로 된 화면을 캡처했나"까지 확인합니다.

어떻게 진짜인지 가려내나

그럼 이걸 어떻게 확인할까요. 몇 가지 신호를 봅니다. 화면에 "로그인", "접근 제한", "비정상적인 접근", "잠시 후 다시" 같은 문구가 가득하면 가짜일 가능성이 높습니다. 화면이 거의 비어 있으면 덜 그려졌거나 차단됐을 수 있습니다. 원래 보려던 페이지의 특징 — 제목이나 주요 요소 — 이 안 보이면 엉뚱한 화면일 수 있습니다. 이런 신호들로 "이건 진짜 콘텐츠가 아닌 것 같다"를 판단하는 것입니다. 완벽하진 않아도, 명백한 가짜는 거를 수 있습니다.

여기서 화면을 읽는 방식이 힘을 발휘합니다. ViewCheck는 화면을 판독할 때 세 가지를 함께 씁니다. 페이지의 구조(어떤 요소들이 어떻게 배치됐나), 실제로 계산된 화면 값(색·크기·간격의 실제 수치), 그리고 화면을 눈처럼 보고 컴포넌트를 감지하는 시각 AI입니다. 여기에 더해, 이미지 속에 글자로 박혀 있는 안내문처럼 필요한 경우에는 화면 속 글자를 읽어내는 보완 수단도 씁니다. 다만 이건 항상 도는 필수 단계가 아니라, "이미지로 된 텍스트나 페이지 유형을 판단해야 할 때" 필요에 따라 쓰는 도구입니다. 이렇게 여러 방식으로 화면을 겹쳐 읽으면, "이 화면이 차단 안내인지, 로그인 화면인지, 진짜 콘텐츠인지"를 좀 더 확실히 가릴 수 있습니다.

가짜를 걸렀으면, 사유를 남긴다

가짜를 걸러냈다면, 그걸 어떻게 처리할지도 정해야 합니다. 그냥 "분석 실패"로 뭉뚱그리지 않고, 왜 못 봤는지를 구분해서 남깁니다. 로그인 화면이면 "이 페이지는 로그인 안쪽이라 못 봤다", 차단이면 "보안 장비 차단으로 못 봤다", 덜 그려졌으면 "다시 시도" 같은 식으로요. 이렇게 사유를 구분해서 남겨야, 나중에 "이 부분은 왜 비었지?"를 추적할 수 있습니다.

가짜를 진짜로 세는 것보다, "이건 이런 이유로 못 봤다"고 남기는 게 백 배 낫습니다. 전자는 결과를 오염시키지만, 후자는 결과의 정직함을 지킵니다. 이 태도가 앞서 여러 번 강조한 "못 본 건 못 봤다고 남긴다"의 실제 모습입니다.

왜 사유를 구분해서 남기는 게 그렇게 중요할까요. 사유가 다르면 대응도 다르기 때문입니다. "로그인 안쪽이라 못 봤다"면 담당자가 직접 로그인해서 확인하면 되고, "보안 장비 차단이라 못 봤다"면 접근 정책을 살펴보면 되고, "덜 그려져서 다시 시도 중"이라면 잠시 기다리면 됩니다. 그런데 이걸 뭉뚱그려 "분석 실패"라고만 남기면, 담당자는 무엇을 어떻게 해야 할지 알 수 없습니다. 실패에도 종류가 있고, 그 종류를 아는 것이 다음 행동을 정합니다. 그래서 "왜 못 봤는지"를 구분해 남기는 건 단순한 기록이 아니라, 그다음 대응으로 이어지는 실용적인 정보인 셈입니다.

두 엔진의 역할 분담도 여기서 한 번 짚고 가면 좋겠습니다. ViewCheck에는 성격이 다른 두 엔진이 있습니다. 하나는 화면의 구조와 실제 값을 읽어 규칙을 통과/미통과로 빠르게 판정하는 규칙 엔진이고, 다른 하나는 화면을 눈처럼 보고 컴포넌트를 감지하는 시각 AI 엔진입니다. 여기엔 분명한 규칙이 있습니다. 규칙 엔진이 값으로 통과/미통과를 확정한 건, 시각 AI가 뒤집지 않습니다. 시각 AI는 규칙 엔진이 판단을 유보한 빈칸(해당 여부를 확정 못 한 자리)만 채우되, 확신이 있을 때만 채웁니다. 없는 걸 봤다고 지어내지 않고, 못 찾으면 빈칸으로 그냥 둡니다. 그리고 왜 그렇게 판단했는지 근거를 남깁니다. 이 원칙이 "가짜를 진짜로 세지 않는다"는 오늘의 주제와 정확히 맞닿아 있습니다. 확신 없는 감지를 결과로 밀어 넣지 않는 것, 그게 신뢰의 바탕이니까요.

본론 6 — 그래서 어떻게 넘어서나

이 함정들을 어떻게 다루는지 정리해보겠습니다. 핵심은 "한 번 시도하고 실패하면 포기"가 아니라 "끈질기게, 그리고 똑똑하게" 다루는 것입니다.

① 충분히 기다리고, 충분히 내린다

동적 렌더링과 지연 로딩은 "다 떴나"를 판단해서 기다리고, 무한 스크롤은 "더 나올 게 있나"를 보며 내립니다. 너무 빨리 보지 않는 게 기본입니다. 미완성 화면을 찍느니, 조금 기다려서 완성된 화면을 찍는 게 낫습니다. 다만 무작정 기다리는 게 아니라 "다 떴다"는 신호를 보고 판단하니, 빠른 사이트는 빠르게, 느린 사이트는 필요한 만큼만 기다립니다.

② 실패하면 다시 시도한다

한 번 실패했다고 그 페이지를 버리지 않습니다. 일시적인 문제 — 네트워크 지연이나 서버가 잠깐 바빴던 것 같은 — 일 수 있으니, 다시 시도합니다. 여러 번 시도해도 안 되면 그제서야 "이 페이지는 못 봤다"고 솔직히 남깁니다.

이게 의외로 큰 차이를 만듭니다. 웹은 원래 불안정합니다. 같은 페이지도 어떨 땐 잘 뜨고 어떨 땐 느립니다. 서버가 잠깐 바빴거나 네트워크가 출렁였거나 해서요. 그래서 "한 번 안 됐다"가 곧 "이 페이지는 못 본다"를 뜻하지는 않습니다. 잠시 후 다시 하면 되는 경우가 많습니다. 재시도를 안 하는 도구는 이런 일시적 실패까지 전부 "못 봄"으로 처리해서, 멀쩡한 페이지를 놓칩니다. 사람으로 치면, 페이지가 한 번 안 떴다고 영영 안 가보는 것과 같죠. 보통은 새로고침 한 번이면 되는데도요. 그래서 끈질긴 재시도가 커버리지를 지킵니다. 수십에서 수백 페이지를 볼 때, 이 재시도 유무가 "몇 페이지나 제대로 봤나"를 크게 가릅니다.

다만 여기에도 균형이 있습니다. 재시도를 무한정 반복하면 그것대로 시간이 끝없이 늘어납니다. 그래서 "몇 번까지 다시 해보고, 그래도 안 되면 못 봤다고 남긴다"는 선을 정합니다. 무작정 포기하지도, 무작정 매달리지도 않는 것이죠. 그리고 재시도할 때도 사이트에 부담을 주지 않도록 간격을 두고 정중하게 다시 두드립니다. 앞서 보안 장비 이야기에서 "무리하게 뚫지 않는다"고 한 그 태도가, 재시도에서도 똑같이 적용됩니다. 끈질기되 예의를 지키는 것 — 이게 여러 사이트를 상대로 안정적으로 도는 비결입니다.

③ "진짜 화면인지" 확인한다

캡처한 게 차단 안내인지, 로그인 화면인지, 팝업에 가린 건지, 덜 그려진 건지를 확인합니다. 진짜 콘텐츠가 맞으면 분석하고, 아니면 "이건 못 봤다"고 처리합니다. 가짜를 진짜로 분석하는 것보다, "못 봤다"고 솔직히 남기는 게 낫습니다. 본론 5에서 본 그 판별이, 여기서 실제 처리로 이어집니다.

④ 못 본 건 숨기지 않는다

이 모든 노력에도 못 보는 페이지는 남습니다. 로그인 안쪽, 끝까지 차단하는 사이트 같은 것들이요. 이건 억지로 우기지 않고 "이 페이지들은 자동으로 못 봤다"고 결과에 남깁니다. 그래야 "다 봤다"는 착시가 안 생깁니다. 커버리지를 솔직히 보여주는 게, 오히려 결과를 믿게 만듭니다. "100페이지 중 95개를 봤고 5개는 로그인 안쪽이라 못 봤다"가, "100페이지 다 봤다"(실은 5개가 가짜)보다 훨씬 신뢰할 만하니까요.

끈질김과 정직함이 실력이다

정리하면, 렌더링을 잘한다는 건 "쉬운 사이트를 빨리 그린다"가 아니라 "까다로운 사이트도 끈질기게 진짜 화면으로 그려낸다, 그리고 그래도 못 그린 건 솔직히 남긴다"입니다. 이 끈질김과 정직함이 사실 분석 도구의 숨은 실력입니다. 화려한 결과 화면보다, 까다로운 사이트에서 안 무너지는 게 진짜 실력이죠.

그래서 도구를 고르실 때, 데모를 돌려보신다면 "쉬운 사이트" 말고 "우리 사이트 중에서 제일 까다로운 페이지"로 돌려보시길 권합니다. 무한 스크롤 게시판, 외부 위젯이 잔뜩 붙은 메인, 로그인 안쪽에 가까운 페이지, 보안이 빡빡한 페이지 같은 것들이요. 거기서 결과가 제대로 나오면 그 도구는 렌더링이 탄탄한 것이고, 거기서 휑하게 나오면 약한 것입니다. 잘 되는 사이트로만 데모하면 다들 비슷해 보이지만, 까다로운 사이트로 돌리면 차이가 확 드러납니다.

이건 도구를 만드는 입장에서도 마찬가지입니다. 쉬운 사이트만 잘 되게 만드는 건 어렵지 않습니다. 진짜 공은 까다로운 사이트를 하나씩 만나면서 "이 사이트는 왜 안 됐지" 하고 고치는 데 듭니다. 그 누적이 렌더링의 실력이 됩니다. 그래서 많은 사이트를 겪어본 도구일수록 까다로운 사이트에 강합니다. 시행착오가 쌓인 것이니까요.

본론 7 — "그럼 안 되는 사이트는 그냥 포기해야 하나"

여기까지 읽으시면 한 가지 걱정이 드실 수 있습니다. "그렇게 까다로운 사이트가 많다면, 자동 분석은 결국 절반만 보는 반쪽짜리 아닌가" 하는 걱정이요. 이 오해를 풀어두고 싶습니다.

먼저, 오늘 말씀드린 함정들은 대부분 "넘을 수 있는" 것들입니다. 동적 렌더링·지연 로딩·무한 스크롤·팝업 가림 같은 건, 충분히 기다리고 내리고 감안하면 대체로 진짜 화면에 도달합니다. 정말로 끝까지 못 보는 건 로그인 안쪽처럼 애초에 접속 권한이 필요한 영역, 그리고 끝까지 자동 접속을 막는 일부 사이트 정도입니다. 그러니 "까다롭다"가 곧 "못 본다"는 아닙니다. 대부분은 "조금 더 끈질기게 다루면 되는" 것들이고, 정말 못 보는 건 그중 일부입니다.

둘째, 정말 못 보는 부분이 있어도, 그걸 정직하게 남기면 결과는 여전히 쓸모가 있습니다. "100페이지 중 92개를 봤고 8개는 로그인 안쪽이라 못 봤다"는 결과는, 92개에 대해서는 충분히 신뢰할 수 있는 정보입니다. 문제는 못 본 8개를 숨기고 "다 봤다"고 할 때 생깁니다. 그러면 92개의 진짜 정보까지 의심스러워지죠. 그래서 "못 본 걸 남기는 것"은 결과를 반쪽으로 만드는 게 아니라, 오히려 본 부분의 신뢰를 지키는 장치입니다.

셋째, 자동 분석의 진짜 강점은 "한 사이트를 완벽히 다 보는 것"이 아니라 "여러 사이트, 수십에서 수백 페이지를 같은 잣대로 빠르게 훑는 것"에 있습니다. 사람이 손으로 한다면 며칠씩 걸릴 규모를, 일관된 기준으로 한 번에 훑어 "어디가 특히 약한지"를 드러냅니다. 그 과정에서 못 보는 페이지가 일부 나오더라도, 전체 그림을 그리는 데는 충분합니다. 그리고 못 본 페이지는 "여기는 사람이 따로 확인하세요"라고 짚어주니, 사람의 눈과 자동 분석이 역할을 나눠 갖는 그림이 됩니다. 자동 분석이 넓게 훑고, 사람이 못 본 자리를 좁게 확인하는 분업이죠.

그러니 "안 되는 사이트는 포기"가 아니라 "되는 만큼 정직하게 보고, 안 되는 건 안 된다고 남겨 사람에게 넘긴다"가 정확한 그림입니다. 완벽하지 않아도 정직하면, 그 결과는 믿고 쓸 수 있습니다. 반대로 완벽한 척하지만 정직하지 않으면, 아무리 화려해도 믿기 어렵습니다.

그래서 ViewCheck는

ViewCheck도 이 함정들을 다루는 데 공을 들였습니다. 보안 장비는 실제 사용자가 쓰는 브라우저처럼 화면 뒤에서 페이지를 진짜로 그려내며 접속해 넘되, 그래도 끝까지 막는 곳은 무리하게 뚫지 않고 "못 봤다"로 남깁니다. 동적 렌더링과 지연 로딩은 "다 떴나"를 신호로 판단해 기다리고, 무한 스크롤은 "더 나올 게 없나"를 보며 충분히 내립니다. 팝업·배너 같은 가림막은 감안해서 그 뒤의 콘텐츠를 보고, 느린 로딩은 성능 데이터로 함께 잽니다. 그리고 캡처한 게 진짜 화면인지를 여러 신호로 확인하고, 실패한 페이지는 다시 시도하며, 그래도 못 본 건 사유와 함께 정직하게 남깁니다.

이게 화려한 기능은 아닙니다. 사용자 눈엔 그냥 "분석이 잘 되네" 정도로만 보입니다. 그런데 그 "잘 되네"가, 까다로운 사이트에서 안 무너지는 끈질김에서 나옵니다. 겉으로 안 보이는 이 방법이, 같은 "URL 분석"이라도 까다로운 사이트에서 결과가 갈리는 이유입니다.

그리고 이 모든 처리가 사이트를 "읽기만" 하는 원칙 위에서 이뤄집니다. 화면을 그려내서 분석할 뿐, 데이터를 바꾸거나 지우거나 무언가를 제출하지 않습니다. 그래서 실제 사용자가 쓰고 있는 운영 사이트라도 안전하게 볼 수 있습니다. 조심스러운 운영본을, 조심스러운 채로 정확히 보는 것 — 이게 오늘 이야기한 함정들을 넘어서는 바탕입니다.

물론 ViewCheck도 모든 걸 다 보는 건 아닙니다. 로그인 안쪽, 끝까지 차단하는 사이트, 지역·권한에 따라 갈리는 화면 같은 건 여전히 한계가 있습니다. 그건 솔직히 "못 봤다"고 남깁니다. 다 본 척하는 것보다 그게 맞으니까요.

🔐 특허로 지키는 부분

오늘 본 "캡처한 화면이 진짜 콘텐츠인지 — 차단 안내인지, 로그인 화면인지, 덜 그려진 화면인지 — 를 여러 신호로 가려내고, 실패한 페이지를 재시도하며, 못 본 건 커버리지에 사유와 함께 정직하게 남기는 방법"은 ViewCheck가 출원한 5건의 특허 중 시각 요소 분석(스크린샷 기반 화면 판별) 주제의 한 갈래와 맞닿아 있습니다. "화면을 그린다"는 단순한 일처럼 보이지만, "그려진 게 진짜 그 페이지가 맞나"를 자동으로 판별하고 가짜를 진짜로 세지 않도록 거르는 절차 자체를 권리로 정리해 둔 데 차별점이 있습니다. 렌더링의 토대를 "안정적으로" 돌리는 그 끈질김이, 사실 이 방법 위에 서 있습니다.

다만 솔직히 짚어둘 게 있습니다. 특허는 "방법을 지키는 장치"이지 "모든 사이트를 다 본다는 보증서"가 아닙니다. 로그인 안쪽처럼 끝내 못 보는 영역은 남고, 특허는 그걸 "정직하게 남기는 방법"을 보호하는 것이지 "다 본다"를 보장하지 않습니다. 그래서 "특허가 있으니 다 봅니다"가 아니라 "못 본 건 못 봤다고 남기는 방법을 만들고 지켜두었다" 정도로 받아들여 주시면 됩니다. 그리고 현재는 등록이 아니라 출원 단계임을 정확히 표기합니다. (특허 출원 기술 / 자체 개발)

마무리

오늘은 화면 캡처(렌더링)가 실패하거나 어긋나는 사이트들을 봤습니다. 보안 장비에 막히는 경우(차단 안내를 진짜로 착각), 자바스크립트가 뒤늦게 채우는 동적 화면(덜 뜬 채 찍힘), 끝이 없는 무한 스크롤(맨 위만 찍힘), 팝업·쿠키 배너·느린 로딩·지역 제한 같은 가림막들, 그리고 그려지긴 했지만 진짜가 아닌 가짜 화면까지요. 이걸 넘으려면 충분히 기다리고·내리고, 실패하면 다시 시도하고, 진짜 화면인지 확인하고, 못 본 건 솔직히 남겨야 합니다. 렌더링의 실력은 쉬운 사이트가 아니라 까다로운 사이트에서 드러납니다.

기억하실 한 문장은 이것입니다. "분석이 잘 되네"의 절반은 "이 사이트를 진짜로 그려낼 수 있네"입니다. 그러니 도구를 보실 땐 결과 화면만이 아니라 "까다로운 사이트에서도 안 무너지나, 못 본 건 솔직히 남기나"를 함께 보시면 좋겠습니다. 그게 겉으로 안 보이는 실력입니다.

오늘 이야기를 한 문장 더 압축하면, "캡처가 어렵다는 것"과 "사이트가 부실하다는 것"은 다른 말이라는 점입니다. 잘 만든 사이트일수록 보안이 빡빡해 오히려 자동 접속이 어렵기도 하고, 요즘 방식으로 잘 지은 사이트일수록 화면을 뒤늦게 채워 캡처 타이밍이 까다롭기도 합니다. 그러니 "이 사이트는 분석이 힘드네"를 곧바로 "이 사이트는 나쁘네"로 읽지 않는 신중함이 필요합니다. 캡처의 난이도와 사이트의 품질은 별개의 축이고, 그 둘을 섞지 않는 것 역시 정직한 분석의 태도입니다.

혹시 자동 분석을 쓰시다가 특정 사이트만 결과가 휑하게 나온 적이 있다면, 오늘 본 유형 중 하나일 가능성이 높습니다. "도구가 이상한가"보다 "이 사이트가 까다로운 방식이구나"로 보시면, 원인을 찾기가 쉬워집니다. 그리고 그게 잡히면 보통 "조금 기다리기·스크롤 내리기·재시도·진짜 화면 확인" 같은 처리로 풀립니다. 오늘도 끝까지 읽어주셔서 고맙습니다. 다음 편에서는 이번 달의 주제를 이어, 그 까다로운 사이트들을 실제로 어떻게 안정적으로 다루는지를 조금 더 깊게 풀어보겠습니다.

krds.viewcheck.co.kr