글

엔드포인트는 죽는다 — X·Threads·Google Trends 무료 수집을 유지하는 규율 3가지

이미지
무료 수집 경로는 자산이 아니다. 규율이 자산이다 2026년 4월, 내 사이드 프로젝트 trend-scout (매일 여러 플랫폼의 트렌드를 한 번에 모으는 오픈소스)가 X에서 쓰던 Nitter mirror 3개가 같은 날 HTTP 000과 403으로 떨어졌다. Q2 들어 Nitter 생태계는 사실상 죽었다. 그때 내가 배운 건 “Nitter 대체 경로 3개” 자체가 아니었다. 엔드포인트는 언제든 죽는다 는 전제 위에서 어떻게 다음 경로를 찾느냐 는 규율이었다. 경로 자체는 플랫폼 정책에 따라 언제든 막히지만, 규율은 플랫폼이 바뀌어도 남는다. 이 글에선 내가 2026년 4월에 다시 세운 수집 경로 3개(X Syndication, Jina Reader, Google Trends RSS)를 각각 어떤 규율로 찾았는지 기록한다. 경로가 막힌 뒤에 새 경로를 찾으려는 독자가 이 세 규율을 패턴으로 복제할 수 있게 썼다. YES 3번 공감 YES, Nitter mirror 리스트를 주기적으로 갱신하다 어느 날 3개가 전부 HTTP 000으로 떨어지는 걸 본 적이 있다. YES, 개인 사이드 프로젝트에 X API Basic $100/월이 어색한 시점이 있다. YES, “playwright 쓰면 된다”는 조언이 실제론 로그인 벽과 TLS 지문 체크에 막힌 적이 있다. 실측 먼저 — 7 플랫폼 566건 플랫폼 수집량 경로 Naver 226 공식 검색 API Reddit 200 인증 RSS Threads 71 Jina Reader 경유 HackerNews 30 공식 API GitHub Trending 24 HTML 파싱 Google Trends 15 RSS 피드 X Syndication 0 테스트 반복으로 rate-limit 소진 X가 0건으로 찍힌 이유는 경로가 막혀서가 아니라 개발 중 동일 IP로 반복 호출해 per-IP 차단에 걸렸기 때문이다. 정상 범위는 20~30...

Kimi K2.6 써보고 판정을 보류했다 — 첫날 생긴 6가지 의문

이미지
Kimi 후기 쓰려다 판정을 보류한 이유 Moonshot AI가 Kimi K2.6을 푼 지 3일째 되는 날, Kimi Code CLI를 맥 스튜디오에 깔고 Claude Opus 4.7과 같은 작업 6건을 나란히 돌렸다. 원래 “Kimi vs Claude — 대안이냐 보완이냐” 식의 후기를 쓰려고 했는데, 6건을 다 돌려보고 나니 판정이 안 선다. Kimi가 확실히 이긴 건 1~2건이다. Claude가 이긴 것도 2건이다. 나머지는 동률 또는 비교 조건 자체가 공정했는지 의심스럽다. 구독은 일단 유지했지만 “$19/월을 왜 내는지”에 대한 답이 아직 없다. 이 상태에서 “대안이 아니라 보완이다” 같은 깔끔한 결론을 내리는 건 독자 기만에 가깝다. 그래서 결론 대신 의문 6가지를 공유한다. Kimi를 써볼지 말지 망설이는 사람에게는 “써봤더니 좋더라”보다 “써봤는데 이런 게 애매하더라”가 더 쓸모 있을 거다. 글 끝에 $19 구독을 유지한 이유 1개와 해지 임계 조건 3개 도 정리했다. 실험 조건 먼저 기기: 맥 스튜디오 M4 Max 128GB (ssh로 접근) Kimi Code CLI v1.37.0, $19/월 구독 결제 (Kimi 앱에서 바로 됨) Claude: Opus 4.7 (1M context), Claude Code 기본 세팅 테스트 6건, 한 번씩만 실행 (평균 아님) 프롬프트는 동일하게 붙여넣었다. 단, MCP 접근성은 Claude Code 쪽이 훨씬 풍부 하다. 이 MCP 접근성 차이가 이미 공정 비교 여부를 의심스럽게 만든다. 의문 1. Kimi가 CLAUDE.md를 “읽었다”는 건 무슨 의미인가 첫 테스트로 CLAUDE.md를 두고 “이 프로젝트 규율 3개 요약해”라고 물었다. Kimi는 정확히 3개를 요약했다. 겉으론 좋은 신호다. 하지만 다음 턴에 내가 “아첨 금지 규칙 어기지 말고 답해”라고 강조했는데, Kimi는 첫 문장을 “현명한 결정입니다”로 시작했다. 규율을 “읽은” 것과 “따르는” 것은 다르다. 원인...

Claude Opus 4.7 말투, 나는 4.6으로 내렸다 — 5일 써본 솔직한 판정

먼저 결론 — 나는 기본 작업을 4.6으로 내렸다 Claude Opus 4.7을 5일 돌려본 뒤, 블로그 글 교정과 단일 파일 리팩터링은 4.6으로 내렸다. Opus 4.7 말투가 내 작업 루프에서 마찰을 늘렸기 때문이다. 긴 리서치와 큰 코드베이스 탐색만 4.7에 남겼다. 이 글은 그 판단에 이르게 된 5일치 기록이다. 내가 실제로 겪은 장면 하나 평소 쓰던 CLAUDE.md 규칙 “반말. 서두 칭찬 금지. 결론부터.”를 그대로 붙였는데, 4.7은 처음엔 지시를 지켰다. 네 번째 턴부터 달라졌다. 내 입력: 블로그 한 문단을 주고 “문장만 다듬어. 의미는 그대로.” 4.7 응답: “주신 문장은 이미 의미가 명확하지만 더 자연스럽게 쓸 수 있는 방법을 제안드리면 세 가지가 있습니다…” + A/B/C안 제시 + 각 안의 장단점 설명 내가 시킨 것: 문장 하나 다듬기 받은 것: 안 시킨 A/B/C 비교 리포트 4.6 때는 같은 프롬프트에 한 문장이 돌아왔다. 지난 5일간 이 패턴을 13번 기록했다. r/ClaudeAI에서는 이 “반박 + 대안 제시 + 수정 실행” 패턴을 “arguing loop”라고 부른다. Reddit·X에서 올라온 실제 불만 Opus 4.7은 2026년 4월 16일 출시됐다. 4월 17일부터 r/ClaudeAI에 회귀 지적 글이 올라왔다. “ Claude Opus 4.7 feels weird ” (4월 20일) “ I genuinely hate the conversation tone of Opus 4.7 ” (4월 21일) “ Why the huge divergence in lovers and haters of Claude Opus 4.7? ” (4월 21일) 해외 리뷰 블로그에서는 Opus 4.7 backlash 분석 과 Legendaril...

ChatGPT 쓰는 걸 창피해하는 해외 — 한국 블로그와 결의 차이 관찰

이미지
같은 날 해외와 한국 피드가 완전히 달랐다 2026년 4월 하순 어느 날, Threads 71개와 Naver 블로그 226개를 같이 긁어 봤다. AI 키워드 기준으로 위로 올라온 글의 결이 해외와 한국이 정반대 였다. 영어권은 “ChatGPT 쓰는 거 창피하다”는 비판이 상위, 한국은 “이렇게 쓰면 편하다”는 활용법이 상위. 단정할 수준의 데이터는 아니다. 샘플이 작고 플랫폼 2개뿐이다. 그래도 온도차가 뚜렷해서 비교 기록으로 남긴다. 해외 Threads 상위 비판 포스트 7개 engagement 순서 (♥좋아요 + 💬댓글 + 🔁리포스트 + 👁조회 합계). 1. “It is SO embarrassing to openly admit to using chatGPT my GOD” — 5,800 ChatGPT 썼다고 드러내 말하는 게 너무 창피하다는 짧은 한탄. ( 원문 검색 ) 2. “What’s the most obvious sign that someone is using AI/ChatGPT?” — 5,200 AI 쓴 사람을 가장 확실히 구별하는 단서가 뭐냐는 질문. 댓글은 em dash, 확장된 리스트, 감탄사 구조 같은 AI 문체 신호로 가득. ( 원문 ) 3. “Ppl really vent to ChatGPT?” — 4,000 사람들이 진짜 ChatGPT한테 감정 상담을 한다고? 믿기지 않는다는 반응. ( 원문 검색 ) 4. “Ai getting scary day by day! Thoughts on this???🤯” — 3,800 AI가 날이 갈수록 무섭다. 다들 어떻게 생각하느냐. ( 원문 ) 5. “I used ChatGPT ONCE. My former best friend was plugging our convos in there” — 2,600 친한 친구가 우리 대화 내용을 ChatGPT에 넣고 있었다는 걸 알고 절교했다는 글. ( 원문 ) 6. “everyone using ChatGPT on th...

ChatGPT Plus 쿼터 터져도 작업 안 끊기는 법 — 3층 LLM fallback 체인

이미지
ChatGPT 쓰다가 “5시간 뒤에 다시 시도하세요” 떠본 적 있으시죠? 한참 몰입해서 작업하는 중에 흐름 끊기면 돌아오기 어려우시죠? 그렇다고 다른 구독을 한 개 더 붙이는 게 정답은 아닌 것 같죠? ChatGPT Plus 쿼터와 맥 스튜디오 로컬 LLM을 같은 에이전트 안에서 연결했다. 쿼터가 터지는 순간 로컬 gpt-oss:120b로 자동 전환되어 대화가 끊기지 않는다. 이건 “쿼터 우회”보다 넓은 이야기. 상용 AI 서비스의 예측 불가능한 중단에 대비해 자기 기기를 안전망으로 두는 아키텍처 선택이다. 문제의 실체 Plus 쿼터는 gpt-5.4 와 gpt-5.4-mini 를 공유한다. 실제 로그에서도 두 모델이 같은 시점에 rate_limit 로 함께 돌아오는 걸 직접 확인했다. 한 쪽이 막히면? 다른 쪽도 같이 터진다. fallback을 같은 모델 패밀리 안에서만 잡으면 의미가 없다는 뜻. 진짜 fallback이 되려면 쿼터 시스템이 다른 모델을 체인 끝에 둬야 한다. 선택지는 세 개였다. 첫째, 그냥 기다린다. 5시간씩 끊기면서. 둘째, Plus를 해지하고 다른 걸 쓴다. 비슷한 문제가 반복될 가능성. 셋째, 쿼터와 무관한 모델을 fallback 체인 끝에 꽂아둔다. 셋째를 골랐다. 그게 1편에서 벤치마크했던 gpt-oss:120b . 로컬 추론 47 tok/s. Codex보다 느리지만 reasoning 내장, 무엇보다 쿼터가 없다. 원리 먼저 — fallback 체인 설계 원칙 도구 특정 설정으로 들어가기 전에 원리를 적어둔다. 세 층의 역할을 구분해 체인을 짠다. Primary : 가장 먼저 시도되는 모델. 가장 빠르고 품질 좋은 옵션. 대부분의 시간 여기서 돈다. Mid-tier : Primary 실패 시 다음으로 시도되는 후보. 주의 — Primary와 같은 쿼터 풀이면 의미가 제한적. ChatGPT Plus는 gpt-5.4 와 gpt-5.4-mini 가 쿼터 공유. 최종 fallback : 모두 실패했을 때 마지...

Chrome DevTools MCP 공식 출시 — AI 에이전트가 드디어 브라우저를 본다

이미지
“AI 에이전트는 브라우저를 볼 수 없다”는 전제가 깨졌다. Google이 Chrome DevTools MCP를 공식 출시했고, 출시 직후 GitHub 스타 35,975개를 기록했다. 도구는 29개, 설치는 npx 한 줄이다. 지금까지 Claude Code로 프론트엔드 작업을 하면 “코드 짜기 → 빌드 → 브라우저 열기 → 콘솔 확인 → 버그 재현 → 다시 코드”의 핑퐁이 반복됐다. 에이전트는 브라우저를 못 보니 사람이 중간 다리 역할을 해야 했다. 이제 이 전체 루프를 에이전트가 혼자 돈다. 공식 출시 핵심 팩트 GitHub : ChromeDevTools/chrome-devtools-mcp, 스타 35,975개 (2026-04 기준) 도구 수 : 29개 (6개 카테고리로 분류) 설치 : npx chrome-devtools-mcp 한 줄 호환 : Claude Code, Gemini CLI, Cursor, VS Code Copilot, Windsurf 등 20개 이상 AI 클라이언트 공식 지원 Chrome 144부터 : 자동 연결 지원. 헤드리스 가능, 기존 브라우저 세션에도 붙음 29개 도구는 6개 카테고리로 묶인다. 입력 자동화(클릭·폼·파일 업로드), 네비게이션(페이지 열기·탭 전환), 에뮬레이션(모바일 기기·네트워크 쓰로틀링), 콘솔 검사, 네트워크 추적, 성능 프로파일링. 에이전트가 할 수 있게 된 것 구체적으로 무엇이 바뀌었는지 정리한다. 스크린샷 기반 판단 : 에이전트가 화면 상태를 직접 눈으로(비전으로) 본다. “이 버튼이 잘렸다”를 사람이 스크린샷 붙여주지 않아도 된다 콘솔 에러 자동 분석 : 소스맵까지 따라가서 스택 트레이스 확인. “무슨 에러?” 대신 “이 함수 142줄에서 null 참조”까지 즉시 UI 자동 조작 : 클릭, 타이핑, 폼 제출을 에이전트가 직접 실행. 테스트 시나리오 자동 수행 Lighthouse 감사 자동화 : 성능 점수 목표치까지 수정-측정 루프를 자율로 반복 네트워크 요청 추적 : 어떤...

OpenClaw 디스코드 멀티봇 7개 자율 협업 — 1박 2일 시도 끝 결론

디스코드 한 서버에 AI 에이전트 7개 띄워서 자기들끼리 일 위임하게 만들어본 적 있으시죠? OpenClaw 봇이 멘션엔 답하는데 자동 협업은 안 돼서 답답하셨죠? 설정 어디를 만져야 멀티봇 오케스트레이션이 진짜 작동하는지 궁금하셨죠? OpenClaw 디스코드 멀티봇 7개를 한 서버에 올리고 CEO 봇이 다른 C-level 봇에게 자동으로 일을 위임하게 만드는 시도를 1박 2일 했다. 결론부터 적는다 — OpenClaw 디스코드 봇 응답 모드는 설계상 채팅 전용 이고, 이 모드에서 봇이 다른 봇을 도구로 호출하는 경로가 차단돼 있다. config 어디를 만져도 안 됐다. 시도한 것 — 9단계 작업 전 상태: Mac Studio M4 Max 128GB에 OpenClaw 설치, Discord 토큰 7개(CEO/CTO/CCO/CRO/CMO/DEVIL/SIMON) 보유, “에이전트들끼리 떠드는 단계”에서 멈춰 있었다. 1. 진단 : Hermes Agent도 같이 깔려 있었지만 active_agents: 0 . 실제 운영은 OpenClaw였다. 2. 백엔드 모델 비교 : gpt-oss:120b · gemma4:26b · qwen3.6:35b-a3b · Hermes 4.3 36B(Q4) 4종을 같은 7-에이전트 한국어 프롬프트로 측정. 결과는 따로 정리했지만(이전 글 참조), 이번 작업에서는 Plus 쿼터 보존을 위해 mini 모델로 갔다. 3. 진짜 멈춘 원인 : 처음엔 Discord 충돌·rate limit 의심. 실제는 channels.discord.enabled: false . 이벤트 자체를 안 받고 있었다. 4. Discord 멀티봇 활성화 : .discord-tokens.env 에 7봇 토큰이 있었지만 OpenClaw config 어디서도 참조 안 함(레거시). 소스 검색해 channels.discord.accounts.<id> 멀티 계정 구조가 있다는 걸 발견. bindings에 match.accountId: ...