개인 개발 중인 프로덕트에서, 유저의 생생한 목소리("~가 필요하다", "~가 번거롭다")를 수집하는 데이터 수집처를 새로 늘리는 작업을 하고 있었습니다. 후보 사이트가 십수 개 있었기에, AI에게 "먼저 robots.txt와 이용약관을 한 번 쭉 체크해줘"라고 부탁하여 돌려보았는데, 그 과정에서 여러 가지 깨달음이 있었기에 실제로 직접 움직여 확인한 내용의 기록으로서 공유합니다. 결론부터 말하자면, "스크레이핑해도 되는가"는 robots.txt,

・이용약관・실제 HTTP 응답(HTTP response)이라는 세 가지를 각각 별개로 확인할 필요가 있었습니다.

1. 발단: 「robots.txt만 보면 되는」 시대는 끝나 있었다

(애초에 robots.txt가 무엇인지 모르는 분들을 위해 한마디 덧붙이자면, https://example.com/robots.txt와 같이 각 사이트의 루트 직하에 놓인 설정 파일로, "이 URL은 크롤링(Crawl)해도 된다/안 된다"를 사이트 측에서 크롤러(Crawler)를 향해 선언하기 위한 것입니다. 누구나 읽을 수 있다는 전제하에 각 사이트가 스스로 공개하고 있는 파일이므로, 내용을 확인하는 것 자체에는 아무런 문제가 없습니다.)

처음에는 단순하게, 각 사이트의 robots.txt에서 ClaudeBot 등의 AI 크롤러가 허용되어 있는지만 확인하면 된다고 생각했습니다. 그런데 실제로 십수 개 사이트 분량의 결과를 나열해 보니, robots.txt가 깨끗하더라도 이용약관 측에서 AI 이용 자체를 금지하고 있는 사이트가 여럿 나타났습니다.

2. 약관 측에서 AI를 명시하여 금지하고 있는 사이트가 있었다

가장 명확했던 것이 프로그래밍 Q&A 사이트인 teratail입니다. robots.txt에 AI 크롤러에 대한 개별 차단은 없었으나, 이용약관을 확인해 보니 다음과 같은 조항이 있었습니다.

당사의 사전 서면 허락 없이, 본 서비스상의 데이터(게시 데이터 등을 포함합니다)를 정보 해석, 인공지능(AI) 개발, 기계 학습(Machine Learning), 또는 학습용 데이터셋(Dataset) 작성 등의 목적으로 수집, 복제, 이용하거나 제3자에게 제공하는 행위(제7조 제21호)

"정보 해석" 「인공지능(AI) 개발」 「학습용 데이터셋 작성」과 같이 AI 용도를 콕 집어 명시하여 금지하고 있었습니다. robots.txt 측만 보고 "차단되어 있지 않으니 괜찮다"라고 판단했다면 그대로 놓쳤을 부분입니다 (이 약관은 최종 개정일 2026년 6월 4일 시점의 것입니다. 약관은 개정될 수 있으므로, 본 기사 집필 시점의 내용으로 읽어주세요).

Disallow: /가 아니게 되고 있다

3. robots.txt 측도 단순한 약관과는 반대로, robots.txt 측에서 철저하게 관리하는 사이트도 있었습니다. 크라우드 소싱 사이트인 클라우드웍스(CrowdWorks)는 다음과 같은 헤드라인과 함께 AI 크롤러를 차단하고 있습니다.

# AI 학습용 크롤러의 크롤링 거부
# https://developers.facebook.com/docs/sharing/webmasters/web-crawlers/
# https://developers.openai.com/api/docs/bots
...

Q&A 사이트인 OKWAVE는 더욱 철저하여, robots.txt에 나열된 User-agent가 150개(집필 시점, 2026년 8월)에 달했습니다. anthropic-ai
・ClaudeBot
・Claude-User
・Claude-SearchBot
・Claude-Web
・Claude-Code
와 같이 Claude 관련해서만 5종류 정도를 개별적으로 명시하여 차단하고 있었습니다. 요미우리 신문의 「발언 코마치(発言小町)」에 이르러서는 AI 크롤러뿐만 아니라 curl ・ wget ・ Scrapy ・ Mechanize와 같은 범용 도구의 User-Agent까지 개별적으로 Disallow: / 하고 있었는데, 이는 실제로 저도 확인해 보았으나 그 철저함에 웃음이 나올 정도였습니다. robots.txt는 예고 없이 변할 수 있는 것이므로, 여기에 언급한 숫자나 내용은 모두 집필 시점의 것으로 읽어주시기 바랍니다.

이 시점에서 「robots.txt」와 「이용약관」 양쪽을 매번 세트로 확인하는 운용으로 전환했습니다. 어느 한쪽이 깨끗하더라도 다른 한쪽에서 막혀 있는 케이스가 흔히 있기 때문입니다. 실제로 이 기간에 후보로 살펴본 십수 개 사이트 중, 약관과 robots.txt를 모두 통과할 수 있었던 곳은 1~2할 정도였습니다 (어느 사이트가 통과했는지는 이번에 밝히지 않겠습니다).

4. 「사전 서면 허가」를 프리랜서 개인 개발자는 어떻게 받아야 하는가

애초에 왜 약관에 굳이 AI 이용을 금지하는 조항을 추가하는 사이트가 늘어나고 있는 걸까. 궁금해서 AI에게 조사해 보았더니, 저작권법에 다음과 같은 조문(제30조의 4)이 있었습니다.

저작물은 다음에 열거하는 경우 그 밖에 해당 저작물에 표현된 사상 또는 감정을 스스로 향유하거나 타인에게 향유하게 하는 것을 목적으로 하지 않는 경우에는 그 필요하다고 인정되는 범위 내에서 어떤 방법에 의한 것인지에 관계없이 이용할 수 있다. 다만, 해당 저작물의 종류 및 용도 그리고 해당 이용의 태양에 비추어 저작권자의 이익을 부당하게 해치는 경우에는 그러하지 아니하다.

이 조문의 「다음에 열거하는 경우」 중 하나로 「정보 해석 (Information Analysis)」 용도로 제공하는 경우가 명시되어 있습니다. 즉, 일본의 법률은 AI 개발이나 머신러닝 (Machine Learning)을 위해 데이터를 사용하는 것 자체에는 의외로 관대한 편입니다. 그렇기 때문에 사이트 측은 법률만으로는 막을 수 없는 부분을 약관 (계약)을 통해 개별적으로 금지할 수밖에 없습니다. teratail의 조항은 바로 그 패턴이었습니다.

다만, 두 가지 주의해야 할 점이 있습니다.

첫 번째는, 이 조문이 효력을 발휘하는 것이 「인간이 내용을 읽고 즐기거나 참고하려는 목적이 아닌 경우」에 한정된다는 점입니다. 이번 사례처럼 수집한 게시물을 그대로 대시보드에 인용 표시하는 방식은 바로 사람이 읽도록 하기 위한 이용이므로, 이 조문만으로는 모두 커버하지 못할 가능성이 있습니다.

두 번째는, 「약관에 AI 금지라고 적혀 있다면 법률상으로는 허용되는 일이라도 정말로 막을 수 있는가」, 「애초에 회원 가입도 하지 않은 방문자가 그 약관에 얽매이는가 (teratail의 조항도 주어는 『등록 사용자는』였습니다)」라는 점은 법률가들 사이에서도 의견이 갈리는 듯합니다. 저는 변호사가 아니므로, 여기서는 「그런 논점이 있다」는 소개 정도로 그치겠습니다. 실제로 판단이 필요한 상황에서는 전문가에게 확인하시기 바랍니다.

「사전 서면 허가 없이」라는 표현은 뒤집어 생각하면 허가만 받는다면 길이 열려 있다는 뜻으로도 읽힙니다. 하지만 프리랜서로서 혼자 개발하는 프로덕트 (Product)에게 이것이 현실적인 선택지가 될 수 있느냐 하면 이야기는 달라집니다.

실제로 비슷한 형태로 정규 루트를 시도해 본 적이 있습니다. 다른 후보로서 Reddit의 API 액세스 (API Access)를 신청했으나, 돌아온 것은 이유를 밝히지 않는 정형화된 거절 통지였습니다. 개인 개발자가 공식 서포트 (Official Support)에 문의해도 기업처럼 담당자와 협상할 수 있는 것이 아니라, 정형화된 문구의 벽에 부딪혀 그대로 끝나는 것이 실정입니다.

고문 변호사가 있는 것도 아니기에, 조문의 문구를 스스로 읽고 스스로 「이것이 해당되는지 여부」를 판단할 수밖에 없습니다. 판단을 그르치면 그 책임 또한 혼자 짊어져야 합니다. 동정을 바라는 것이 아니라, 개인으로서 데이터를 다루는 이상 피할 수 없는 역할이라고 생각하지만, 약관을 하나씩 읽으면서 「법무부가 있는 회사라면 이 조문을 어떻게 해석할까」라고 몇 번이고 생각했습니다.

5. 여담: 가장 「문제없어 보이던」 사이트에서 일어난 일

teratail이나 OKWAVE처럼 명확한 거부가 이어지는 가운데, 하나 문제없어 보이는 사이트도 있었습니다. robots.txt는 ClaudeBot을 포함한 주요 크롤러 (Crawler)에게 Allow를 명시하고 있었고, 이용 약관에도 AI 수집을 금지하는 조항은 보이지 않았습니다.

User-Agent: ClaudeBot
Allow: /
User-Agent: Claude-User
...

다만, 구현에 들어가기 직전에 만약을 위해 생(raw) HTML을 AI에게 curl로 가져오게 했더니, 게시물 데이터가 전혀 포함되어 있지 않다는 것을 알게 되었습니다. 응답 헤더 (Response Header)의 Content-Security-Policy를 보니, 외부 BaaS (Backend as a Service) 도메인이 connect-src에 포함되어 있어, 실제로는 브라우저상의 JavaScript가 BaaS로 직접 데이터를 가져가는 구성인 듯했습니다. 「약관도 robots.txt도 깨끗해도 실제 HTTP 응답은 따로 확인하지 않으면 알 수 없다」는 이야기로서, 이 시점에 메모로 남겨두었습니다.

그런데, 이 글을 쓰기 위해 만약을 위해 다시 한번 동일한 확인을 요청했더니, 이번에는 게시물 제목이 그대로 <h3

태그 안에 들어있었고, 생(raw) HTML에 게시 데이터가 그대로 포함되어 있었습니다. 3가지의 서로 다른 User-Agent로 시도해 보아도 결과는 동일했습니다. 응답 자체도 0.3초 정도 만에 돌아왔기에, 스트리밍 과정에서의 누락 같은 단순한 문제도 아닌 듯했습니다. 결국, 며칠 전의 "데이터가 들어있지 않았다"라는 확인 결과가 무엇이었는지는 특정할 수 없었습니다. 사이트 측의 구현이 바뀌었는지, 혹은 지난번 확인 절차에 어떤 문제가 있었는지 판단할 수 있는 재료는 남아있지 않습니다.

1차 정보(Primary Information)는 한 번 확인했다고 끝나는 것이 아니라, 시간이 지나면 상황도, 심지어는 자기 자신의 확인 결과조차 바뀔 수 있습니다. 지금까지 써온, 약관과 robots.txt를 하나씩 조사해 온 이야기의 교훈 및 근본과 같다고 생각했기에, 짧은 에피소드로 덧붙여 둡니다.

요약

• 새로운 데이터 수집처를 찾는 과정에서, robots.txt는 깨끗하지만 이용 약관에서 AI 이용을 명시적으로 금지하고 있는 사이트(teratail 등), 반대로 robots.txt 측에서 AI 크롤러(Crawler)를 철저하게 차단하고 있는 사이트(CloudWorks, OKWAVE, Hatsugen Komachi 등)가 일본 국내 UGC 사이트에서 눈에 띄게 늘어나고 있음을 알 수 있었다.
• "허가되어 있는가"는 robots.txt나 이용 약관 중 어느 한쪽만으로는 판단할 수 없으며, 양쪽을 매번 세트로 확인해야 한다. 후보로 살펴본 수십 개의 사이트 중 양쪽 모두 통과할 수 있었던 곳은 1~2할 정도였다.
• "사전 서면 허가"와 같은 조항이 있더라도, 프리랜서 개인 개발 단계에서는 정식 루트를 통한 허가 취득 자체의 허들이 높다(정형화된 문구로 거절당하고 끝나는 경우도 있다). 조항의 해석도, 그 책임을 지는 것도 결국은 자기 자신이다.
• 덤으로, 약관도 robots.txt도 깨끗해 보였던 사이트라도 실제 HTTP 응답을 확인하지 않으면 알 수 없는 함정이 있었다. 게다가 그 확인 결과 자체도 나중에 다시 확인했을 때는 재현되지 않았다. 1차 정보는 한 번 확인하고 끝내지 말고, 매번 다시 확인하는 것이 안전하다.

(본 기사는 법적 조언이 아닙니다. 실제 판단이 필요한 상황에서는 전문가에게 확인하십시오)

Discussion