▲

robots.txt에 대해 내가 틀렸던 점

 (evgeniipendragon.com)
7P by GN⁺ 18시간전 | ★ favorite | 댓글 1개
  • robots.txt 설정을 통해 웹사이트 크롤러 전체 차단 시도 후 예상치 못한 부작용 발생 경험
  • LinkedIn 포스트 미리보기가 사라지고, 게시글 도달 범위도 감소 현상 확인
  • 원인은 robots.txt가 LinkedInBot의 페이지 접근을 막아 메타 태그 수집을 방해했기 때문임
  • Open Graph Protocol이 소셜 미디어에서 미리보기 생성 시 핵심 역할 수행함을 새롭게 인식
  • robots.txt를 부분 허용 방식으로 수정하고 문제를 해결함, 향후 기능 변경 시 충분한 테스트 필요성 인지

서론: robots.txt 설정과 의도치 않은 문제 경험

  • 최근 블로그에서 robots.txt 설정을 학습하면서 내 콘텐츠에 대한 데이터 권리 문제에 대해 생각함
  • 웹사이트에 모든 크롤러를 차단하려고 robots.txt를 수정함
  • 예상치 않게, 웹사이트에서 원치 않은 결과가 발생함

LinkedIn 포스트 미리보기 문제

  • robots.txt를 바꾼 후, LinkedIn에 내 블로그 링크를 올리자 미리보기(썸네일, 요약문) 가 보이지 않음
  • 이전까지는 정상적으로 미리보기가 제공되었으나, 변경 후에는 노출 및 반응이 급격히 감소함
  • 처음에는 일시적 문제라 생각했으나 2주 이상 현상 지속됨
  • LinkedIn Post Inspector로 분석 시, robots.txt가 LinkedInBot의 접근을 제한해서 메타 정보 수집이 불가한 것으로 판명됨
  • 소셜 미디어 플랫폼에서 링크 미리보기 생성을 위해 페이지 요청 및 메타 태그 수집이 필수임

Open Graph Protocol 소개

  • Open Graph Protocol(OGP) 은 Facebook이 만든 표준 프로토콜로, 웹페이지를 소셜 그래프 객체로 만들어 줌
  • OGP는 최소한의 필수 메타 태그를 정의함
    • og:title: 게시글 제목
    • og:type: 객체 유형, 예시로 "video.movie"
    • og:image: 썸네일 이미지 URL
    • og:url: 해당 객체의 대표 URL
  • 이 프로토콜 덕분에 다양한 소셜 플랫폼에서 콘텐츠가 효과적으로 요약되고 매력적으로 표시될 수 있음

robots.txt 부분적 허용으로 해결

  • 문제 해결을 위해, robots.txt를 LinkedInBot만 허용하는 방식으로 수정함
  • 만약 다른 소셜 플랫폼의 미리보기도 필요하다면, 각 봇을 별도로 허용해야 함
  • 현재 적용 중인 설정 예시: 
    User-agent: LinkedInBot
Allow: /

User-agent: *
Disallow: /

회고 및 배운 점

  • 모든 크롤러를 무조건 차단하면 콘텐츠 노출 및 프리젠테이션 문제가 발생할 수 있음
  • 변경 효과에 대해 충분한 테스트 없이 조치한 것이 실수였음을 인지함
  • 이번 경험으로 Open Graph Protocol, LinkedIn Post Inspector 등 유용한 도구와 웹 표준에 대해 더 많이 알게 되었음
  • 기능 추가·변경 시, 영향 영역 전체에 대해 충분한 이해와 검증이 필요함
  • 처음엔 OGP와 robots.txt 차단의 관계를 연결하지 못했으나, 경험을 통해 중요성 인식함
▲
GN⁺ 18시간전  [-]
Hacker News 의견

  • 예전에는 robots.txt의 주요 목적이 검색 엔진에서 중복 콘텐츠 패널티를 방지하는 데 있었음. 관리하기 힘든 동적 사이트를 운영하다보면 쿼리 파라미터 등으로 동일한 페이지가 여러 URL로 노출되고, 검색 엔진에서 패널티를 먹었음. robots.txt는 "이게 정식 URL이니, 나머지는 무시해줘"라고 알리는 기능이었음. 이 외에도 ‘착한’ 크롤러가 무한 링크 크롤링에서 헤매지 않도록 도와줬음. 물론 '나쁜' 크롤러는 신경도 안 썼고, 이런 봇들은 IP 차단 등으로 막았음. User-Agent 기반으로 차단하는 건 의미 없었음. 악의적인 봇이 얌전히 규정을 지켜줄 거라 믿는 건 순진한 생각임. DNT(Do Not Track) 헤더도 마찬가지로, 추적을 업으로 삼는 기업한테 "추적 말아 주세요"라고 부탁하는 것과 같음. 또는 악의적인 패킷이 직접 헤더에 "난 악성임"이라고 표기하길 바라는 RFC의 Evil Bit 아이디어와 비슷함

    • Evil Bit 제안은 만우절 RFC였다는 점을 기억해야 함 RFC 3514 보기

    • 결국 robots.txt가 사이트맵(sitemap)과 역할이 비슷하냐는 생각도 들지만, 사실 정반대임. robots.txt는 크롤러가 접근하지 말아야 할 곳을, sitemap은 인덱싱을 원하는 곳을 알려줌. 중복 콘텐츠 패널티 관리라는 원래의 목적은 몰랐어서, SEO 컨트롤에 대한 관점에 새로운 맥락을 더해준다는 느낌을 받음

    • 핵심은 어떤 행동을 ‘금칙’이라고 선언하면 일부 정직하거나 실수로 유저 에이전트 이름을 제대로 안 감춘 경우에만 효과를 보게 됨. 그 이상으로는 잘 안 통해서, 결국 다소 상징적인 조치임

    • DNT 헤더처럼, 현실적으로 실행 불가능해 보이는 시도가 종종 비난받는 면도 있지만, 사실 DNT 아이디어는 법적 장치와 함께 적용하고자 한 시도였음. 실제 완전한 기술적 차단은 어려워도, 대규모로 범법 행위를 저지르다 보면 결국 내부 고발로 드러날 수 있음을 감안해야 함

    • 규칙을 정하면 모두가 지킬 거라 믿는 사람들이 있는데, 그게 과연 문화적인 차이에서 기인한 믿음인지 의문이 들기도 함

  • 2003년에 직접 검색 엔진을 만들어서 웹을 크롤링한 적이 있음. 대표 메일 주소를 유저 에이전트에 넣었더니, 정말 많은 항의 메일을 받았음. 나는 최대한 성실하고 매너 있게 크롤러를 만들었는데도 사람들은 Google이 아니면 원치 않더라고 느꼈음. 이런 태도야말로 Google에 대항하는 경쟁자의 등장을 막는 방법임. LinkedIn 미리보기 문제에만 국한된 게 아니라, 웹이 다양한 봇과 사용자를 위해 개방적이어야 한다는 점을 생각해야 함. 물론 악질 크롤러는 막아야 하지만, 모든 봇을 기본적으로 악의적으로 취급하는 자세는 바람직하지 않음

    • 내가 봇을 착하게 운영하는 입장에서 가장 짜증났던 경험은, 누군가 내 봇 유저 에이전트로 악성 봇을 만들어 공격한 뒤 나한테 항의가 온 적이 있음

    • 누구나 본인의 봇을 보호하고 싶어 할 수 있으나, 실제로는 본인 봇만의 문제가 아니고, 똑같은 봇이 9000개쯤 돌아다니며 서버 리소스를 과다하게 쓰는 것이 문제임. 이런 봇들은 실제로 리퍼럴 트래픽은 가져다주지 않음

    • 나도 초반에는 모든 것을 차단하는 접근을 했었지만, 웹의 상호 연결성과 복합성을 깨닫게 되었음. 자신의 리소스에 대한 주도권을 갖는 것은 중요하다고 생각함. 다만 원하는 트래픽을 허용인지 차단인지 할 땐 ‘왜’라는 질문을 스스로 해야 하고, 각 봇이 무엇을 하는지 알아야 함. 이런 과정은 시간과 노력이 필요함. AI 회사들이 데이터 학습 용도로 마구잡이 크롤링하는 관행 때문에 robots.txt에 처음 관심을 갖게 됨. 나는 허용/차단 여부를 직접 선택하고 싶음. 모든 봇이 robots.txt를 지키는 것은 아니지만, 상당수는 이를 따름. 직접 테스트할 수 있는 한 방법은, 브라우징 지원 모델을 통해 특정 링크 스크래핑 요청을 해보는 것임. 근본적으로 봇이 악성인지는 그 회사가 데이터를 활용하는 방식과 내가 어떻게 느끼는지가 더 중요함

    • “모든 봇이 악성인 게 아니니 무조건 막지 말라”는 주장에, 나는 기본적으로 신뢰할 근거 없이 접근하는 건 위험한 전략이라고 생각함

    • 알 수 없는 크롤러에 의심을 품는 게 당연함. 대다수의 크롤러가 악성이고, 선악을 사전에 알 길이 없으니, 기본적으로 모르는 봇을 잠정적으로 악성으로 간주하는 게 이치에 맞음

  • 비판적인 의견은 자제하려고 노력하지만, 이 글은 저자가 자신의 행동 결과를 너무 심각하게 깨달은 척 하는 게 놀라움. 개인 성장 스토리도 의미가 있지만, 이 글은 통찰이 아니라 무지에 대한 고백에 더 가까움. 결국 주목받고 싶어서 글을 올린 것으로 느껴짐

    • 저자가 페이지 미리보기 fetcher를 크롤러로 인식하지 못했고, robots.txt로 차단할 생각이 없었던 것임. 뻔한 내용은 아닐지라도, 최소한 본인 입장에서 새로 배우는 점은 있었음. 실제 사람이 직접 쓴 블로그 글은 웹의 평균적인 퀄리티를 높일 수 있다고 봄

    • 구글에 노출되지 않으니 여기(Hacker News)에 글을 올린 거임

    • 나에게도 실질적으로 새롭게 다가온 부분이 있었음. Open Graph Protocol과 Robots Exclusion Protocol을 추가로 배우는 계기가 되었음. 스스로 배우거나 흥미를 느낀 것은 기록해두고 나누는 편임. 다른 사람에게도 흥미로울 수 있다고 생각해서 공유한 것임

    • 이 글이 어떻게 프론트페이지에 올라왔는지 의문임. ‘물을 막으면 착한 놈은 피해가고, 나쁜 놈은 무시한다’라는 너무 당연한 얘기를 길게 쓴 것 같음. 결국 robots.txt는 정중한 ‘하지 마세요’일 뿐이지, 방화벽이 아니라는 점은 자명함

  • robots.txt의 문제점은, 결국 크롤러의 목적이 아니라 크롤러의 ‘정체성’에 의존해서 필터링한다는 것임. 저자도 AI 수집을 막으려고 모든 봇을 막았지만, OpenGraph 미리보기용 크롤러(LinkedIn 등)는 다시 허용함. 그런데 Twitter나 Mastodon 등 다른 플랫폼에서 공유하면 어쩔 거냐는 문제도 있음. 모든 소셜 미디어의 UA를 일일이 허용해야 하고, 이는 결국 소수 대형 플랫폼에만 유리한 구조임. 본질적으로 “AI 학습은 막되, 검색 인덱싱, 미리보기, 아카이브 등은 허용”하는 수단이 필요함. 이를 실질적으로 집행하려면 법적 틀이 따라야 하겠지만 그것도 쉽지 않음

    • robots.txt의 근본적 용도에 대한 논의가 항상 존재해왔음. 내 생각엔 원래(그리고 여전히) 대부분 크롤러(링크를 따라가며 새로 탐색하는 작동방식) 전용이라고 봄. 검색엔진이 대표적 예시. 하지만 사용자가 직접 특정 URL을 요청하는 경우(예: 브라우저, iCal 구독 등)는 robots.txt를 따를 필요 없음. 실제로 Google Calendar 같은 서비스가 robots.txt 차단에 막혀 구독이 안 되는 일도 있었으나 잘못된 동작이라고 생각함. URL 프리뷰의 경우, 사용자가 단일 링크만 요청한다면 크롤링이 아니라 특정 요청에 가까움. 하지만 장문의 메시지에 여러 링크가 있을 땐, 그것 또한 일종의 크롤링에 가까워짐. 결론적으로 소셜 미디어의 URL 프리뷰 기능이 robots.txt를 따라야 할지는 아직 애매하다고 생각함

    • Common Crawl 같은 데이터는 검색엔진에도, AI 학습 등에도 재사용될 수 있음. 용도 구분이 쉽지 않음

    • 정보 공유 방식을 in-band가 아니라 out-of-band로 나누면 해결할 수 있음. 오픈그래프 메타데이터를 별도 경로/헤더로 제공하면, 그 경로(쓸모없는 데이터)는 허용하고, 본문 콘텐츠는 강력히 거부 가능. 법적 프레임워크가 반드시 필요한 건 아님

    • 기능별/목적별로 분류해서 허용/차단할 수 있는 표준을 만드는 아이디어가 마음에 듦. 다만, 기능 검증과 스푸핑 방지가 관건이고 결국은 법적 문제도 맞물림. 실제로 소셜 미디어 미리보기 등 다양한 플랫폼에 다시 허용해야 할 것 같고, 허용/차단할 대상을 신중히 선택하는 과정에서 많이 배우고 있음. 이처럼 여러 의견을 듣는 과정이 큰 참고가 되고 있음

  • OP에게, 1) LinkedIn만 생각했으나, 실제로는 Facebook, Bluesky 등 다른 소셜 미디어에서도 내 링크가 공유될 수 있음. Facebook의 ai.robots.txt 에서도 FB 미리보기용 크롤러까지 함께 차단해버릴 수 있음을 경험함 (ai.robots.txt 예시).

  1. Google 순위와 robots.txt 차단 관련해서, robots.txt로 검색 노출을 막아도 간접적인 링크 등 다른 변수도 있지만, 직접 크롤링을 허용하는 게 네이버/구글 SEO에 기본적으로 훨씬 유리함. 차단하면 검색 결과에서 썸네일/설명 등이 노출 안 되어 품질이 떨어짐. 만약 검색엔진 트래픽이 중요하다면 robots.txt로 완전 차단은 고민해야 함

  • 피드백 고마움! 1) 나 역시 LinkedIn과 HN만 생각했음. 다른 사람들이 내 블로그 링크를 다양한 플랫폼에 공유한다는 점은 미처 떠올리지 못함. 여러 플랫폼 접근 허용을 재고해야 할 수도 있음. 2) 검색엔진 트렌드가 AI 요약 위주로 가는 걸 보니, 앞으로는 사이트 자체에 유입되는 유기적 트래픽이 줄어들 거라고 생각함. 그러니 Google 검색 트래픽 감소가 별로 아쉽지는 않음. 앞으로 생각이 바뀔 수도 있겠지만, 현재로선 HN과 소셜 공유를 통한 구전 효과가 내 블로그엔 더 의미 있는 트래픽을 만들어 줄 것으로 여김. 내린 결정이 스스로 발목을 잡지 않는지, 추가로 더 조사해 보려고 함. 다양한 의견이 의사결정에 큰 도움을 주고 있음

  • robots.txt로 ‘크롤링’과 ‘인덱싱’을 혼동해서 발생하는 또 다른 부작용이 있음.
    새로운 페이지를 Google 인덱스에 원천 차단하려면 robots.txt 차단이 효과 있음.
    하지만 이미 인덱싱되어 있는 페이지를 삭제하려고 robots.txt에만 추가하는 건 실수임. 구글은 크롤링을 못하니 메타데이터 없이 계속 검색 결과에 노출시키고, noindex 메타태그도 확인할 수 없어서 결국 오랫동안 검색에 남을 수 있음. 구글이 나중에야 해당 페이지를 완전히 제거하지만, 이 과정이 매우 답답할 수 있음

    • 구글은 robots.txt에 의해 차단된 URL을 외부 링크 등을 통해 알 수 있고, 이 경우 크롤링은 못 해도 인덱싱된 기록이 결과에 남을 수도 있음 (경고 참고: 구글 공식문서). 검색 결과에서 완전히 삭제하려면 코드 내 noindex 태그를 반드시 넣어야 하며, robots.txt 차단 시 이 태그도 읽지 못하니 주의해야 함

    • 내 경우 구글이 인덱스에서 제거하길 꼭 원치는 않음. 인덱싱에는 무관심하고, 크롤링-스크래핑만 신경씀. 용어를 혼동 쓴 적이 있던 건 인정함

  • 이 글은 본론만 한두 줄이면 족할 얘기를 너무 늘여 쓴 느낌임. 마치 학창시절 분량 늘리기 식 느낌이랄까

    • 문제를 한 단락이면 설명할 수 있었을 것임. 내 글의 목적은 내 경험과 문제, 리서치, 그리고 그 해결책까지의 여정을 기록하는 것에 있었음. 기술 비전문가도 따라올 수 있도록 최대한 자세히 쓴 것임

  • robots.txt의 근본적 한계는, 실제로 robots.txt를 지키는 봇이 아니라 안 지키는 봇이 문제임. robots.txt는 오늘날 트래픽 문제가 되는 봇 대부분을 통제하지 못함. 서버를 손상시키는 악질 봇일수록 robots.txt에 전혀 신경 쓰지 않음

    • 이러한 봇을 잡으려면 ‘허니팟’이 유용할 수 있음. robots.txt에 /honeypot 경로를 명시적으로 차단시키고, index.html에 display:none 처리된 <a href="/honeypot">ban me</a> 링크를 추가함. 이 경로를 접속하는 IP는 바로 차단하면 됨

    • 왜 비추천을 받았는지 모르겠음. OpenAI, Anthropic 등 주요 회사가 robots.txt를 얼마나 잘 준수하는지 신뢰할 근거가 없음. 이들 회사는 트래픽을 주거용 ISP IP로 우회하는 등 탐지 자체를 어렵게 하고, ‘타사 광고’를 통해 직접 추적을 회피하는 방식으로 책임을 분산함

  • 가장 충격받는 점은 robots.txt와 meta robots 태그를 동시에 해석하고 충돌 시 어떤 우선순위로 허용/차단해야 하는지, 잘 정리된 파서 라이브러리가 거의 없다는 것임. 공식 구글 레퍼런스 파서는 C++11 기반이라 희귀한 경우고, 실제 유행하는 Python이나 JS용 라이브러리는 개발자가 따로 구현해야 할 상황임. 심지어 meta robots 같은 경우 아예 robots.txt 파일이 아니라 index.html 내부에 정보가 숨어 있음. 봇 작성자가 도덕적으로 잘하려 해도 구현 난이도로 인해 어렵다는 게 문제임

    • Python 표준라이브러리엔 urllib.robotparser (공식문서)가 있음. 한편 rel=nofollow는 robots.txt와 전혀 다른 목적임. 이 속성은 해당 링크에 대해 검색엔진이 ‘신뢰(링크값 부여)’하지 말라는 것으로, “이 링크를 따라가지 마”라는 의미는 아님(상세설명). 원래 의도는 스팸커뮤니티에서 무차별적으로 본인 사이트 링크를 남기는 것을 막는 것임

    • 자원이 넉넉하지 않은 ‘선량한’ 봇 개발자는 서버를 무차별 폭격하지 않기에, 사실상 라이브러리가 부족해서 곤란을 느끼는 일은 크지 않음

    • 선의로 제대로 된 봇을 만들고 싶다면, parser 라이브러리를 직접 다른 언어로 오픈소스화해서 공개하는 것도 충분히 가능하다고 생각함. 어려울 게 없음

  • 재미있게도 Apple은 이 문제를 다르게 접근함. iMessage에서 링크를 공유할 땐, ‘보내는 쪽’ 클라이언트가 직접 프리뷰를 긁어서 만듦. LinkedIn 같은 서비스는 서버 측이 직접 링크 데이터를 긁는 이유(스팸, 피싱 방지 등)가 있겠지만, 확실히 색다른 방식임

    • 나도 메시지 내부 링크를 받은 후 클라이언트가 직접 프리뷰를 생성하는 게 합리적이라 생각했음. 그리고 이미 누군가 이 점을 지적했다는 사실도 기대했음. 다만 서버가 직접 스크랩하는 여러 이유도 이해함. 1) 모든 페이지를 긁어 활용 가능한 미래를 대비; 2) 페이지가 바뀌거나 404가 나오거나, 클라이언트 데이터베이스가 손실되었을 때도 서버에선 미리 뺀 프리뷰 정보를 줄 수 있음; 3) 클라이언트 쪽에서 프리뷰 안 만들어도 되고 메시지와 함께 빠르게 전망을 볼 수 있음. 결국 iMessage처럼 ‘보내는 사람’이 프리뷰를 만든다면 이 중 ‘1번’과 ‘2번 일부’만 남고, 서버가 재시도를 계속하는 게 안정성 면에서 더 나은 선택일 수 있음
답변달기