저는 대화(conversation)를 중심으로 구축된 소비자용 AI 데모들을 계속해서 보고 있습니다.

채팅 친구, 라이프 코치, 귀여운 UI를 가진 제2의 두뇌 같은 것들 말이죠.

제 생각에 그것은 대부분 방향이 잘못되었습니다.

일반 사람들이 실제로 복제하게 될 첫 번째 AI 에이전트는 훨씬 더 지루한 것입니다:

정해진 일정에 따라 짜증 나는 웹사이트들을 확인하고, 의미 있는 변화가 생겼을 때만 알림을 보내주는 감시 에이전트 (watcher agent)입니다.

"나와 대화해줘"가 아닙니다.

그보다는 다음과 같습니다: "이 보기 싫은 허가 포털을 30분마다 확인하고 내 상태가 변경되면 알려줘."

이러한 패턴은 이미 OpenClaw, Distill.io, changedetection.io와 같은 도구들에 존재합니다. 그리고 솔직히 말해서, 이는 현재 주목받고 있는 화려한 소비자용 에이전트 제품들보다 훨씬 더 유용합니다.

이 생각이 떠오르게 만든 포스트

구직 자동화 및 브라우저 에이전트 (browser-agent) 워크플로우를 조사하던 중, r/openclaw에서 다음과 같은 제목의 스레드를 발견했습니다:

"OpenClaw가 내 잃어버린 고양이를 찾았어요!"

읽어보기 전까지는 낚시성 글처럼 들릴 수도 있습니다.

핵심 내용은 간단했습니다: 사용자가 OpenClaw에 상황을 설명했고, 에이전트는 무언가 변할 때까지 동물 보호소(humane society) 목록과 관련 포럼을 계속 확인했습니다.

그것이 전체 패턴입니다.

유용한 부분은 모델이 아니었습니다.

glm 5.1도 아닙니다.
GPT-5도 아닙니다.
Claude Opus 4.6도 아닙니다.

유용한 부분은 위임된 지속성 (delegated persistence)이었습니다.

인간은 20분마다 같은 소스들을 수동으로 다시 확인하는 일을 멈추게 되었습니다.

이것은 사람들이 깨닫는 것보다 더 큰 카테고리입니다.

가장 고통스러운 개인적 과업들은 어렵지 않습니다. 반복적일 뿐입니다.

많은 현실 세계의 과업들은 극적인 의미에서의 지능을 요구하지 않습니다.

그것들은 다음을 요구합니다:

• 인내심
• 반복
• 저수준의 브라우저 작업 (low-level browser work)
• 나중에 다시 확인해야 한다는 기억

예시:

• 기업 채용 페이지 전반의 채용 공고
• 허가 및 라이선스 포털
• 유용한 알림을 절대 보내지 않는 학교 포털
• 아파트 매물
• 재입고 및 가격 하락
• 중고 장비 분류 광고
• 보호소 및 지역 게시판을 통한 유실 반려동물 검색

이것은 사실 챗봇 (chatbot)의 문제가 아닙니다.

이것은 감시 (watcher)의 문제입니다.

웹사이트 모니터링은 이미 이에 대한 수요를 증명했습니다

사람들은 수년 동안 "이 페이지를 지켜보고 변경되면 알려달라"는 서비스에 비용을 지불해 왔습니다.

이것이 중요한 이유는 해당 동작이 이미 검증되었음을 의미하기 때문입니다. AI는 단지 그 패턴을 더 똑똑하게 만들 뿐입니다.

기존 제품들이 이미 증명하고 있는 것은 다음과 같습니다:

흥미로운 점은 changedetection.io가 이미 에이전트 (agent) 동작을 향해 나아가고 있다는 것입니다.

이 서비스는 다음과 같은 기능들을 지원합니다:

• Discord 알림
• Slack 알림
• Telegram 알림
• 이메일 (email)
• 웹훅 (webhooks)
• 브라우저 단계 (browser steps)
• OpenAI 호환 AI 엔드포인트 (OpenAI-compatible AI endpoints)

그 시점에서, 당신은 단순히 HTML의 차이점 (diff)을 비교하는 것이 아닙니다.

당신은 의사결정 계층 (decision layer)을 구축하고 있는 것입니다.

모니터 (Monitor) vs 에이전트 (agent): 실제로 중요한 경계선

이것은 제가 계속해서 되돌아오는 구분점입니다.

웹사이트 모니터는 변경 사항을 감지합니다.

감시 에이전트 (watcher agent)는 그 변경 사항이 당신을 번거롭게 할 만큼 가치가 있는지 결정합니다.

사소하게 들릴 수 있지만, 이것은 UX (사용자 경험) 전체를 바꿉니다.

모니터는 말합니다: 무언가 변경되었습니다

이것은 다음과 같은 경우에 유용합니다:

• 정확한 페이지를 알고 있을 때
• 정확한 셀렉터 (selector)를 알고 있을 때
• 당신이 신경 쓰는 정확한 텍스트를 알고 있을 때

Distill.io는 이 작업에 능숙합니다.

에이전트는 말합니다: 이 변경 사항은 아마도 중요할 것입니다, 이유는 다음과 같습니다

이것이 업그레이드된 형태입니다.

모든 차이점 (diff)을 전달하는 대신, 에이전트는 다음과 같은 일을 할 수 있습니다:

• 미적인 (cosmetic) 변경 사항 무시
• 여러 리스팅 (listings) 비교
• 변경된 내용 요약
• 신호 (signal)와 소음 (noise) 분류
• 확신이 높을 때만 에스컬레이션 (escalate)
• 인접한 소스 탐색 지속

이것이 바로 OpenClaw 이야기가 먹혀들었던 이유입니다.

"와, AI가 브라우징을 할 수 있네"가 아니었습니다.

"와, 이제 탭들을 계속 지켜보고 있지 않아도 되겠네"였습니다.

내가 실제로 구축할 아키텍처 (architecture)

만약 내가 오늘 이것을 만든다면, 3개의 계층으로 나눌 것입니다.

1) 탐지 (Detection)

가장 단순하고 신뢰할 수 있는 것을 먼저 사용하십시오.

• 빠른 관리형 모니터링을 위한 Distill.io
• 오픈 소스 (open-source)의 유연성을 위한 changedetection.io
• 사이트가 동적(dynamic)이거나, 불안정(flaky)하거나, 로그인이 많이 필요한 경우 Playwright

Docker를 이용한 changedetection.io

docker run -d \
  --name changedetection \
  -p 5000:5000 \
...

이렇게 하면 빠르게 안정적인 기본 감시자 (watcher)를 구축할 수 있습니다.

Playwright가 더 나은 선택인 경우

대상 사이트가 다음과 같은 특징을 가진다면:

• 로그인 벽 (login walls)
• 쿠키 배너 (cookie banners)
• 복잡한 다단계 양식 (weird multi-step forms)
• 클라이언트 사이드 렌더링 콘텐츠 (client-rendered content)
• 안티 봇 (anti-bot) 이상 동작

그냥 Playwright를 사용하세요.

npm init -y
npm install playwright
npx playwright install

허가 포털 (permit portal)을 감시하는 예시 스크립트:

const { chromium } = require('playwright');
const fs = require('fs');

...

이것만으로도 충분히 유용합니다.

하지만 진짜 흥미로운 부분은 판단력 (judgment)을 추가할 때 시작됩니다.

2) 판단 (Judgment)

이 단계가 바로 LLM이 실제로 제값을 하는 지점입니다.

채팅 UI로서가 아니라,

필터 (filter)로서 말이죠.

예시 프롬프트 (prompt):

You are reviewing website changes for a user.

Return JSON with:
...

changedetection.io를 사용하거나 자체 워크플로우 엔진을 사용 중이라면, 이 기능은 OpenAI 호환 엔드포인트 (OpenAI-compatible endpoint) 뒤에 위치할 수 있습니다.

이것이 중요한 이유는 앱을 다시 작성하지 않고도 모델 제공자 (model providers)를 교체할 수 있기 때문입니다.

예를 들어, Standard Compute를 가리키는 OpenAI SDK를 사용하면 다음과 같습니다:

import OpenAI from 'openai';

const client = new OpenAI({
...

이것은 토큰당 과금 (per-token billing) 방식에서 매우 번거로워지는 전형적인 작업 부하 (workload) 유형입니다.

감시 에이전트 (Watcher agents)는 설계상 반복적입니다.

하루 종일 실행됩니다.
노이즈가 많은 수많은 페이지를 검사합니다.
종종 여러 소스를 확인합니다.
대부분의 확인 작업은 유용한 결과물을 만들어내지 않습니다.

즉, 비용 모델이 매우 중요하다는 뜻입니다.

모든 백그라운드 확인 작업이 예상치 못한 청구서를 만들 수 있다는 느낌을 준다면, 사람들은 시스템을 너무 공격적으로 제한하거나 사용을 중단해 버립니다.

정액제 컴퓨팅 (Flat-rate compute)이 이러한 패턴에 훨씬 더 적합합니다.

Standard Compute가 여기서 흥미로운 이유는 토큰당 과금에 대한 불안감 대신, 예측 가능한 월간 가격으로 OpenAI 호환 API를 제공하기 때문입니다. 페이지 감시, 필터링, 요약 및 알림 라우팅과 같은 반복적인 에이전트 작업 부하의 경우, 모든 작은 백그라운드 결정에 비용을 지불하는 것보다 이러한 가격 모델이 훨씬 더 합리적입니다.

3) 에스컬레이션 (Escalation)

알림을 다른 대시보드로 보내지 마세요.

사용자가 이미 머물고 있는 곳으로 보내세요:

• Slack
• Discord
• Telegram
• 이메일 (email)
• SMS
• n8n, Make 또는 Zapier로의 웹훅 (webhook)

Discord 웹훅 (webhook) 예시:

await fetch(process.env.DISCORD_WEBHOOK_URL, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
...

n8n 웹훅 (webhook) 호출 예시:

await fetch('https://your-n8n-instance/webhook/permit-alert', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
...

이것이 올바른 형태입니다.

중요해지기 전까지는 보이지 않아야 합니다.

실용적인 워크플로우 (workflow) 예시

다음은 채용 공고를 위한 최소한의 감시 파이프라인 (pipeline)입니다.

1. Playwright가 5개의 기업 채용 페이지를 엽니다.
2. 공고 제목과 링크를 추출 (Extract) 합니다.
3. 이전 실행 결과와 비교합니다.
4. 새로운 공고를 LLM (대규모 언어 모델)에 보내 필터링합니다.
5. 역할이 사용자의 기준과 일치할 경우에만 알림을 보냅니다.

의사 코드 (Pseudo-code):

const listings = await scrapeCompanyPages();
const newListings = diffAgainstPrevious(listings);

...

이것은 지루합니다.

그렇기 때문에 승리하는 것입니다.

실제 환경에서 이러한 시스템이 실패하는 지점

감시 에이전트 (Watcher agents)는 유용하지만, 마법은 아닙니다.

실패 모드 (failure modes)는 예측 가능합니다:

• 만료된 세션 (expired sessions)
• CAPTCHA
• 셀렉터 드리프트 (selector drift)
• 안티 봇 (anti-bot) 변경 사항
• 조용한 로그인 실패 (silent login failures)
• 노이즈가 많은 페이지 차이 (noisy page diffs)
• 에이전트가 쓰레기 데이터를 너무 자주 에스컬레이션 (escalating) 함

그리고 두 번째 문제: 자율성 침식 (autonomy creep).

에이전트에게 더 많은 자유를 줄수록, 멍청한 행동을 할 가능성이 높아집니다.

이러한 시스템에 대한 저의 규칙은 간단합니다:

1. 자동으로 감시 (watch) 한다
2. 자동으로 요약 (summarize) 한다
3. 자동으로 에스컬레이션 (escalate) 한다
4. 승인이 있을 때만 행동 (act) 한다

이렇게 하면 끔찍한 상황을 만들지 않으면서 대부분의 가치를 얻을 수 있습니다.

에이전트를 구축하는 개발자들에게 이것이 중요한 이유

실제 사용자를 위한 AI 워크플로우 (workflows)를 구축하고 있다면, 이 카테고리에 주목할 가치가 있습니다.

왜냐하면 "감시 및 알림 (watch and notify)" 패턴은 사람들이 실제로 원하는 모든 특성을 가지고 있기 때문입니다:

• 상시 가동되는 유용성 (always-on utility)
• 쉬운 투자 대비 수익 (easy ROI)
• 별도의 교육 불필요 (no training required)
• 백그라운드에서 작동
• 기존 자동화 도구와 깔끔하게 매핑됨

또한 개발자들이 이미 사용 중인 도구들과도 완벽하게 결합됩니다:

• Playwright
• changedetection.io
• OpenClaw
• n8n
• Make
• Zapier
• OpenAI 호환 API (OpenAI-compatible APIs)

그리고 이는 매우 구체적인 인프라 요구 사항을 만들어냅니다:

반복적인 백그라운드 작업을 위해 저렴하고, 신뢰할 수 있으며, 단순한 추론 (inference) 기능이 필요합니다.

단 한 번의 영웅적인 프롬프트 (prompt)가 아닙니다.

수천 개의 아주 작은 결정들이 필요합니다.

바로 이 지점에서 대부분의 AI 가격 책정 방식이 난처해집니다.

나의 견해

지루한 에이전트들이 인상적인 에이전트들을 이길 것입니다.

그들이 더 똑똑해서가 아닙니다.

반복되는 번거로움을 제거해주기 때문입니다.

대부분의 사람들이 사랑하게 될 첫 번째 개인용 에이전트는 아마도 동반자(companion)도 아니고 범용 비서(general assistant)도 아닐 것입니다.

그것은 사람들이 잠을 자는 동안 못생긴 웹사이트들을 계속해서 확인해 주는 존재일 것입니다.

그리고 마침내 현실이 변했을 때, 그 업데이트가 사람들을 깨울 만큼 가치가 있는 것인지 판단합니다.

그것은 화려하지 않습니다.

그저 유용할 뿐입니다.

유용함은 대개 승리합니다.

만약 여러분이 이런 에이전트를 구축하고 있다면, 저는 다음과 같은 스택 (stack)으로 시작할 것을 권장합니다:

• 탐지를 위한 changedetection.io 또는 Playwright
• 판단을 위한 OpenAI 호환 모델 엔드포인트 (OpenAI-compatible model endpoint)
• 에스컬레이션 (escalation)을 위한 Slack/Discord/Telegram/웹훅 (webhooks)
• 에이전트가 지속적으로 실행될 것으로 예상된다면 고정 비용 형태의 추론 계층 (flat-cost inference layer)

마지막 부분이 사람들이 생각하는 것보다 더 중요합니다.

감시 에이전트 (Watcher agents)는 자유롭게 실행할 수 있을 때만 진정한 가치를 발휘합니다.

만약 토큰 소비 (token spend)를 끊임없이 걱정하게 된다면, 결국 덜 감시하는 감시자를 만들게 될 것입니다.

그리고 그것은 에이전트를 만드는 목적 자체를 무색하게 만듭니다.