"ChatGPT한테 시키면 되지 않나요?"
요즘 데이터 수집을 검토하는 분들이 가장 많이 하는 질문입니다. 맞는 질문이에요. ChatGPT나 Claude에게 "이 사이트에서 상품명과 가격을 수집하는 파이썬 코드를 짜줘"라고 하면, 몇 분 안에 꽤 그럴듯한 크롤러 코드가 나옵니다. 몇 년 전이라면 개발자를 붙여야 했던 일이죠.
그래서 이 글은 "AI로는 안 됩니다"라는 이야기가 아닙니다. 되는 범위는 분명히 있고, 그 범위라면 직접 하는 게 맞습니다. 다만 실제로 운영해 보면 막히는 지점이 정해져 있어서, 어디까지 AI로 되고 어디서부터 다른 문제가 시작되는지를 먼저 알고 시작하면 시행착오를 크게 줄일 수 있습니다.
되는 것부터 인정하겠습니다
구조가 단순한 사이트에서, 소량을, 한 번 수집하는 일이라면 AI가 짜준 크롤러로 충분합니다. 코드를 몰라도 AI와 대화하며 고쳐 나갈 수 있고, 비용도 사실상 들지 않습니다. 실제로 저희 블로그에도 ChatGPT로 크롤링 봇을 만드는 방법을 소개한 글이 있습니다.
AI가 잘하는 것을 정리하면 이렇습니다.
크롤러 코드 작성 자체 — 셀렉터 찾기, 파싱 로직, 엑셀 저장까지
에러 메시지를 주면 코드 수정안 제시
수집한 데이터의 정리·가공 코드
여기까지는 AI 시대에 확실히 쉬워졌습니다. 문제는, 크롤링에서 코드는 절반이 안 된다는 점입니다.
막히는 지점 다섯 가지
1. 차단은 코드 문제가 아니라 인프라 문제입니다
AI가 짜준 코드는 대부분 기본적인 요청 방식을 씁니다. 작은 사이트에선 돌아가지만, 대형 커머스·포털·SNS처럼 봇 탐지가 강한 사이트에선 금방 막힙니다. IP가 차단되고, 캡차가 뜨고, 빈 화면이 내려옵니다.
이걸 뚫는 건 더 좋은 코드가 아니라 인프라입니다. 유동 IP(레지덴셜 프록시), 브라우저 지문 관리, 캡차 대응 — 전부 코드 생성으로 해결되지 않고, 돈과 운영이 드는 영역입니다. AI에게 "차단을 우회해줘"라고 해도 인프라 없이는 실행할 수 없습니다.
2. 조용한 고장 — 깨진 걸 알아채는 눈이 없습니다
사이트 화면 구조는 예고 없이 바뀌고, 그 순간 크롤러는 멈추거나 빈 값을 쌓기 시작합니다. AI는 고쳐 달라고 하면 고쳐 주지만, 깨졌다는 사실을 먼저 알아채 주지는 않습니다.
운영에서 무서운 건 이 지점입니다. 2주 동안 수집이 비어 있었는데 월말 분석 때 처음 발견하는 상황 — 지나간 기간의 데이터는 복구되지 않습니다. 자동 수집에는 수집량 감시, 이상 감지, 알림 같은 모니터링 체계가 함께 있어야 하는데, 이건 크롤러 코드 바깥의 시스템입니다.
3. 복잡한 구조에서는 결국 사람이 디버깅합니다
스크롤할 때마다 내용이 로드되는 동적 페이지, 로그인 세션, 중첩 프레임 같은 구조에서는 AI가 짠 코드의 성공률이 뚝 떨어집니다. "된다"와 "안 된다"를 오가는 코드를 붙잡고 AI와 수십 번 왕복하다 보면, 어느 순간부터는 코드를 읽을 줄 아는 사람이 필요해집니다. 코딩을 모르는 상태로 시작했다면 여기가 실질적인 벽입니다.
4. 정기·대량 수집은 스크립트가 아니라 시스템입니다
매일 수만 건을 안정적으로 수집하려면 스케줄링, 실패 시 재시도, 중복 제거, 값 형식 검증 같은 장치가 필요합니다. 한 번 도는 스크립트와 매일 도는 수집 시스템은 다른 물건입니다. AI는 이 구성요소들의 코드도 짜 줄 수 있지만, 조립하고 운영하는 것은 여전히 사람의 일입니다.
5. 법적 판단과 책임은 AI가 지지 않습니다
수집 대상이 공개 데이터인지, 개인정보·저작권 이슈는 없는지, 약관과 서버 부하 측면에서 문제가 없는지 — AI는 참고 의견은 주지만 판단과 책임은 사용자 몫입니다. 특히 수집한 데이터를 사업에 쓸 계획이라면, 이 부분은 시작 전에 짚고 가야 합니다.
관점을 바꾸면: AI는 개발비를 낮췄고, 그래서 가치는 운영으로 갔습니다
다섯 가지를 관통하는 결론은 하나입니다. AI가 낮춘 것은 크롤러 개발 비용이고, 크롤링의 실제 비용은 갈수록 운영에 있습니다. 차단 대응 인프라, 고장 감지와 수리, 데이터 품질 관리 — 예전에도 이게 어려웠지만, 개발이 쉬워진 지금은 격차가 더 선명해졌습니다.
그래서 저희도 AI를 씁니다. 사이트 변경으로 크롤러가 멈추면 AI가 먼저 원인을 분석해 수정안을 만들고, 사람이 검수해서 반영하는 체계를 운영하고 있습니다. AI 덕에 수리가 빨라졌지만, 그 AI가 일하게 만드는 건 감시 체계·인프라·검수 프로세스입니다. AI 단독과 운영 체계 안의 AI — 결과물의 차이는 여기서 납니다.
그래서, 언제 AI로 직접 하고 언제 맡기나
상황권장단순한 사이트, 소량, 1회성AI로 직접 — 충분하고 가장 저렴합니다코드를 다룰 사람이 있고, 대상이 까다롭지 않음AI 보조 + 직접 운영도 해볼 만합니다차단 강한 사이트(대형 커머스·SNS 등)인프라가 관건 — 수집 서비스 영역입니다매일·매주 반복 수집, 데이터가 업무에 연결됨모니터링·유지보수가 관건 — 수집 서비스 영역입니다
한 줄로 줄이면: 한 번 돌릴 코드는 AI에게, 계속 돌아야 하는 수집은 운영 체계에 맡기는 게 합리적입니다.
자주 묻는 질문
Q. AI가 더 발전하면 크롤러 운영도 알아서 하지 않을까요? 수리 속도는 계속 빨라질 겁니다. 저희도 그 방향으로 AI를 활용하고 있고요. 다만 차단 대응 인프라(프록시 등)와 "깨졌음을 감지하는 체계"는 코드 생성과는 다른 축의 문제라, AI가 좋아질수록 오히려 이 운영 기반의 비중이 커지는 흐름입니다.
Q. AI로 만들다가 막히면 그때 맡겨도 되나요? 됩니다. 실제로 그렇게 오시는 분들이 많고, 직접 해 보신 분일수록 요건이 명확해서 진행이 빠릅니다. 시도해 본 코드나 막힌 지점을 공유해 주시면 검토에 도움이 됩니다.
Q. 맡기면 AI로 만든 것보다 뭐가 다른가요? 크롤러 개발만 놓고 보면 차이가 줄고 있는 게 사실입니다. 차이는 운영에서 납니다 — 차단 대응 인프라, 수집 감시와 자동 알림, 사이트 변경 시 무상 수리, 데이터 품질 검증이 서비스에 포함됩니다.
함께 보면 좋은 글
지금 바로 시작하기
AI로 시도해 보다 막히셨나요? 대상 사이트와 막힌 지점을 알려주시면, 수집 가능 여부와 적합한 방식을 무료로 진단해 드립니다.
