저가 LLM과 웹 스크래핑 자동화, 어디까지 써먹을 수 있을까
저가 LLM 열풍, 왜 개발자들은 계속 실망할까
많은 개발자들이 요즘 "싼 모델로 어디까지 할 수 있나"를 시험하다가, 비슷한 좌절을 반복하고 있습니다. 이번 스트림에서 나온 GLM 4.6V, Z.AI, Kimi K2, Anti‑gravity 이야기는 그 좌절의 압축판에 가깝습니다.
벤치마크는 비슷한데, 체감은 한참 떨어지는 이유
영상 속에서 GLM 4.6V를 써보니 코드 품질이 너무 약해서 결국 상위 모델(GLM 4.6)로 다시 갈아타는 장면이 나옵니다. 파라미터 수, 벤치마크 점수만 보면 "3~6% 차이"라는 숫자가 붙지만, 실제로는 "일을 시킬 수 있느냐"의 차이로 느껴지죠. 저는 이 지점이 핵심이라고 봅니다. 벤치마크는 시험지를 외워서 잘 푸는 모델을 뽑아줄 뿐, 여러분 팀의 레거시 코드와 지저분한 요구사항을 견디는 모델을 골라주지 않습니다.
여기서 많이들 놓치는 부분이 있습니다. 무료·저가 모델을 메인 빌더로 쓰려고 할 때, 본인이 이미 시니어급 개발자로서 프롬프트 설계와 에이전트 구성을 잘 다룬다는 전제가 없으면, 모델 성능이 아니라 "내 시간"이 비용으로 새어 나가게 된다는 점입니다. 저라면 GLM 4.6V 같은 모델은 실험용, 또는 보조 에이전트 정도로만 두고, 핵심 기능 구현에는 검증된 유료 모델을 쓸 것 같습니다.
한국 개발자에게 저가 모델이 특히 애매해지는 지점
국내 환경에서는 더 애매합니다. 원화 결제, 기업 카드 정산, 보안 규정 같은 현실 제약 때문에 팀에서 쓸 수 있는 모델 풀이 애초에 좁습니다. 이 상황에서 "조금 더 느리고, 조금 더 멍청한" 저가 LLM을 도입하면, 팀 내에서는 곧 이런 말이 나오곤 합니다. 차라리 그냥 내가 짜는 게 더 빨라서.
제 기준에서는, "저가 LLM을 메인으로 쓸지, 유료를 쓸지"의 기준은 간단합니다. 한 달에 두세 번 취미 프로젝트를 하는 사람이면 무료·저가 모델이 맞고, 매일 실제 서비스 코드를 만지는 사람이라면 유료 모델이 더 싸게 먹힙니다. 시간 단위 인건비가 결국 가장 큰 비용이기 때문입니다.
코드 짜는 AI, 왜 Codeex와 도구 조합이 중요한가
많은 사람들이 여기서 막히는 부분이 바로 "어떤 모델을 중심에 두고, 뭘 조합해야 안정적으로 개발이 굴러가냐"입니다. 스트림에서 눈에 띄는 장면은, 여러 오픈웨이트·저가 모델이 삽질을 하는 동안 Codeex가 비교적 안정적으로 대형 기능을 원샷으로 구현해낸 부분입니다.
Codeex를 '메인 빌더'가 아니라 '문제 해결사'로 둘 때
스트리머는 "클로드 코드로 안 풀릴 때 Codeex로 옮기면 바로 된다"는 식으로 씁니다. 즉, Codeex를 항상 켜두는 메인 툴이 아니라, 막힐 때 꺼내는 공수도 고수 같은 포지션으로 두는 셈입니다. 이게 중요한 시사점입니다.
저가 모델들은 초안 생성, 리팩터링, 단순 패턴 코딩에는 쓸 만하지만, 설계와 아키텍처를 한 번에 잡아주는 데는 자주 실패합니다. 반대로 Codeex 같은 유료 상위 모델은 "설계 + 구현 + 수선"을 한 번에 밀어붙이는 데 강하고요. 그래서 저라면 이렇게 생각합니다. 싸구려 모델 여러 개를 돌리는 것보다 "비싼 모델 하나를 문제 해결사로 두고, 나머지는 반복 작업에 쓰는 구조"가 더 현실적이라고요.
CLI, 에이전트, 그리고 시스템 프롬프트 설계의 의미
스트림에서는 agents.md로 에이전트 구성을 코딩 환경에 붙이고, 그걸 Anti‑gravity나 Codeex에 이식하려는 시도를 합니다. 여기서 보이는 패턴이 흥미롭습니다. 결국 모델의 IQ를 끌어올리는 것보다, "역할을 잘게 쪼개서 시스템 프롬프트와 파일 구조로 고정해두는 것"이 더 중요해지는 방향입니다.
국내 개발자 입장에서 보면, 이 흐름은 의미가 큽니다. 회사마다 선택하는 모델은 달라도, 에이전트 스펙과 시스템 프롬프트는 그대로 이식할 수 있기 때문입니다. 회사가 내일 GLM에서 오픈AI로, 오픈AI에서 Anthropic으로 갈아타더라도, agents.md와 비즈니스 로직만 남으면 됩니다. 이 관점에서 보면, "어떤 모델이 3% 더 똑똑한가"보다 "에이전트 구조를 몇 번이나 다시 짤 필요가 없는가"가 훨씬 중요한 질문이 됩니다.
웹 검색 API + LLM, 리드 제너레이션이 완전히 달라진 이유
이 부분에서 많은 분들이 "아, 이게 진짜 돈 되는 포인트구나" 하고 느낍니다. 스트림 후반부에서 OpenAI Responses API와 웹 검색을 묶어, 사실상 Perplexity와 B2B 리드 SaaS를 동시에 대체하는 아이디어가 즉석에서 나옵니다.
'퍼플렉시티 같은 검색'이 아니라 '리드를 뽑는 검색'
코드는 단순합니다. 웹 검색 기능이 붙은 Responses API를 curl로 호출하고, LLM이 자연어로 검색 쿼리를 설계합니다. 그리고 검색 결과에서 실제 쇼피파이 스토어를 골라내고, 다시 그 페이지를 읽어 이메일, 주소, 구글맵 링크 등을 뽑아 CSV로 정리합니다.
표면적으로는 "퍼플렉시티를 복제했다"처럼 보이지만 실질적으로는 완전히 다른 결과물이 나옵니다. 퍼플렉시티는 "정리된 답변"을 주지만, 여기서는 "돈이 되는 행(row) 단위 데이터"가 나옵니다. 이 차이가 큽니다. 국내에서 클레이(Clay), 헌터(Hunter) 같은 서비스를 쓰는 이유가 바로 그 행 단위 데이터를 얻으려는 것인데, 그 비용 구조를 LLM 웹 검색이 직접 흔들기 시작한 셈입니다.
기존 웹 스크래핑 스택을 대체할 수 있을까
현실적으로는 아직 완전한 대체라고 말하긴 이릅니다. 스트림에서도 OVH 서버, 레지던셜 프록시, 캡차 솔버, 퍼즐 솔버를 붙여 전통적인 스크래퍼를 굴리는 사람 이야기가 나옵니다. 이 방식은 대량, 반복, 초고정밀 수집에서는 여전히 강력합니다.
다만 여기서 중요한 페르소나 분기가 생깁니다. 수십만 건 이상을 주기적으로 긁어야 하는 데이터 브로커나 대규모 마케팅 에이전시라면, 여전히 전통 스크래핑 스택이 유리합니다. 반면, 특정 니치 타깃으로 한 달에 수십~수백 건의 고정밀 리드만 필요하고, 개발 리소스가 넉넉하지 않은 스타트업·1인 사업자에게는 LLM+웹 검색이 훨씬 유리한 선택입니다.
저라면 후자의 상황이라면, 비싼 스크래핑 인프라를 올리기보다 Responses API와 소형 백엔드(예를 들어 FastAPI + 간단한 프론트)를 먼저 붙여 실험판을 만들어 보겠습니다. 여기서 나오는 리드 품질과 단가를 본 뒤에, 정말 필요할 때만 전통 스크래핑으로 확장하는 편이 덜 위험해 보입니다.
시작 전 반드시 체크할 것
누구에게 기회이고, 누구에게는 과장일까
이 전략은 특히 두 부류에게 유리합니다. 하나는 B2B SaaS, 에이전시, 프리랜서처럼 "소량의 정교한 리드"가 곧 매출로 이어지는 사람들입니다. 다른 하나는 이미 LLM을 개발에 적극적으로 쓰고 있고, 간단한 API 연동 정도는 충분히 감당할 수 있는 개발자입니다. 이들에게 저가 LLM, Codeex, 웹 검색 API 조합은 꽤 공격적인 무기가 될 수 있습니다.
반대로, 코드를 거의 쓰지 않는 팀, 그리고 "이메일 10만 개 쏘는 대량 발송"이 핵심 전략인 사업자에게는 이 방식이 애매합니다. 요청 단가가 쌓이면서, 전통적인 이메일 데이터 구매나 클레이 같은 SaaS가 여전히 더 싸게 먹힐 수 있기 때문입니다. 그리고 AI가 만들어준 리드를 어느 정도 수작업으로 검수하고, 메시지를 다듬을 수 있는 여유가 있는 팀이 아니라면, "머신이 뽑아준 데이터"를 신뢰하기도 쉽지 않습니다.
현실적 제약과 첫 행동
현실적으로는 몇 가지 제약을 인정하고 시작하는 편이 좋습니다. 첫째, 저가 LLM만으로는 안정적인 개발 경험을 기대하기 어렵다는 점입니다. 최소한 하나의 상위 유료 모델(Codeex든, Claude Sonnet이든)을 "막힐 때 부르는 해결사"로 둬야 합니다. 둘째, LLM 기반 웹 스크래핑은 언제든 정책 변경, 가격 변경의 영향을 크게 받습니다. 특정 API 한 곳에만 의존해 사업 모델을 짜면, 어느 날의 공지 한 줄에 제품이 휘청일 수 있습니다.
그래서 제 기준에서는, 이 방향을 시험해 보고 싶은 분들에게 첫 행동은 굉장히 작게 잡는 것이 좋겠습니다. Responses API 웹 검색과 하나의 LLM만 연결해 "내 업계에서 고객이 될 만한 20개 회사와 연락처를 뽑아내는 스크립트" 정도를 먼저 만들어 보는 것입니다. 이 작은 실험만 제대로 돌아가면, 그다음은 프론트엔드를 붙여 소형 내부 도구로 쓰든, SaaS로 포장하든, 선택의 문제로 바뀝니다.
기술은 이미 나와 있고, 오히려 문제는 선택과 집중입니다. 어디까지를 LLM에 맡기고, 어디까지는 여전히 사람이 책임져야 하는지, 각자 사업과 커리어의 맥락에서 선을 그어야 할 타이밍입니다.
출처 및 참고 :
이 노트는 요약·비평·학습 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.