수업 #3 — 채널톡 CS를 AI가 받는다고? 웹훅으로 자동답변 파이프라인 만들기
Source: bbojjak-viewer.vercel.app/lessons/lesson-03 Type: article By: 뽀짝이 / 뽀짝이의 서재 (지피터스 AI스터디) Valid as of: 2026-04-28
Key Insight
웹훅 + transform 함수 조합으로 외부 서비스(채널톡) 이벤트를 에이전트 자동 트리거로 전환하는 실전 구현기. 핵심 원칙: “모르면 안 답한다” — AI 자동응대는 단일 지식 저장소 + 3겹 안전장치로 신뢰성을 확보한다.
핵심 Takeaway
- 웹훅 = 이벤트 Push 트리거: 에이전트가 외부 서비스를 폴링하지 않고 외부 서비스가 변경 이벤트를 에이전트 URL로 POST. OpenClaw
hooks로 엔드포인트 생성, 채널톡→n8n→OpenClaw 체인으로 구현 (출처: “웹훅” 섹션) - transform 함수 = 데이터 어댑터: 원시 JSON → 에이전트 자연어 변환. 봇 메시지 필터링 + 핵심 정보 추출 + 에이전트용 메시지 생성. 에이전트가 파싱 부담 없이 의도 파악 가능 (출처: “transform” 섹션)
- AI 자동응대 안전장치 3겹: (1) 비로그인 개인정보 차단, (2) 불확실 시 사람에게 에스컬레이션, (3) 기존 데이터 47개 전수 대조. “확실한 건 바로, 애매한 건 사람에게” (출처: “안전장치” 섹션)
- 단일 지식 저장소 원칙: 운영 문서 하나(policies.md 등)가 채널톡 CS·Q&A 게시판·카톡 문의 전부 커버. 문서 업데이트 = CS 품질 자동 향상. chatbase 이중 관리 문제 해소 (출처: “chatbase vs 뽀짝이” 섹션)
- 통합 삽질 3연타와 범용화 교훈: 인증 불일치(n8n 프록시), 미문서 이벤트 타입(
push→ chatId 존재 시 범용 처리), 서버 캐시(Gateway 재시작). 실전 통합은 항상 예외 케이스가 숨어있음 (출처: “삽질” 섹션들)
상세 요약
chatbase에서 에이전트로 전환한 이유
기존 SaaS 챗봇(chatbase)의 구조적 한계: 별도의 지식 저장소 이중 관리. 에이전트가 이미 알고 있는 운영 정책을 chatbase에도 따로 학습시켜야 하는 비효율. 학습 데이터가 낡아지면 틀린 답변이 나와도 눈치채기 어렵다.
에이전트로 교체 시 이점: 운영 문서(policies.md, about-ai-study.md 등)를 에이전트가 직접 참조 → 단일 진실 소스. 문서만 업데이트하면 CS 품질이 자동으로 따라온다.
이 원칙은 agentic-webhook-integration의 핵심 설계 동기이기도 하다.
웹훅 파이프라인 구조
채널톡 → n8n 프록시 → OpenClaw /hooks/ → transform → 에이전트 → 채널톡 API → Slack 보고
n8n이 중간에 들어간 이유: 채널톡이 커스텀 Authorization: Bearer 헤더를 지원하지 않아 n8n이 토큰을 주입하는 프록시 역할. 보안 요구사항(인증)과 외부 서비스 제약 사이의 현실적 타협.
transform 함수 설계 원칙
- 필터 우선: 봇/매니저 응답은 처리하지 않음 (무한 루프 방지)
- 범용 조건: 이벤트 타입이 아닌 데이터 존재 여부로 판단 (
chatId존재 → 처리) - 자연어 출력: JSON 구조 대신 에이전트가 바로 이해할 수 있는 문장 생성
미문서화된 push 이벤트 타입을 발견한 후, 특정 이벤트 타입을 화이트리스트로 처리하던 방식에서 “chatId만 있으면 처리”로 범용화한 것이 핵심 설계 개선.
안전장치 아키텍처
| 계층 | 안전장치 | 대응 방식 |
|---|---|---|
| 인증 | 비로그인 개인정보 차단 | 로그인 안내로 우회 |
| 지식 | 모르는 질문 탐지 | Slack 에스컬레이션 (사람 컨펌) |
| 품질 | 기존 데이터 전수 대조 | 47개 Q&A 대조, 5건 추가 |
“확실한 건 바로 답하고, 애매한 건 사람에게 넘기는 것” — AI 자동 응대의 핵심 원칙. agent-identity-design의 Boundaries 설계가 실전에서 구현된 사례.
연결되는 위키 페이지
- agentic-webhook-integration — 이 소스에서 추출한 웹훅+transform 통합 패턴
- heartbeat-mechanism — 능동적 하트비트 vs 반응적 웹훅 대비
- agent-identity-design — Boundaries 안전장치의 실전 구현
- OpenClaw — hooks/transform 기능을 제공하는 에이전트 프레임워크
- bbojjak-openclaw-agentic-architecture-lesson01 — 시리즈 Lesson 01
- bbojjak-openclaw-soul-md-lesson02 — 시리즈 Lesson 02
- bbojjak-openclaw-multi-agent-team-lesson04 — 시리즈 Lesson 04 (멀티에이전트 팀 설계)
- bbojjak-openclaw-agents-error-learning-lesson05 — 시리즈 Lesson 05 (AGENTS.md 절대 규칙·오류 학습 루프)
- bbojjak-openclaw-session-architecture-lesson06 — 시리즈 Lesson 06 (세션·컴팩션·채널 라우팅)
- bbojjak-openclaw-runtime-architecture-lesson07 — 시리즈 Lesson 07 (터미널 vs 런타임 아키텍처 비교)
- bbojjak-openclaw-memory-architecture-lesson08 — 시리즈 Lesson 08 (기억 3단계·Full-context·Prompt Caching)
- bbojjak-openclaw-scheduling-design-lesson09 — 시리즈 Lesson 09 (하트비트 vs 크론잡·3가지 사고·스케줄링 설계)
- bbojjak-openclaw-skill-design-lesson10 — 시리즈 Lesson 10 (에이전트 스킬 시스템·SKILL.md·n8n→스킬 전환)
- bbojjak-openclaw-automation-layers-lesson11 — 시리즈 Lesson 11 (exec·자동화 3계층·exec-approvals·Trust but verify)
- bbojjak-openclaw-subagent-orchestration-lesson12 — 시리즈 Lesson 12 (sessions_spawn·맥락의 격차·판단 최소화 원칙)
- bbojjak-openclaw-playwright-image-pipeline-lesson13 — 시리즈 Lesson 13 (Playwright·HTML→PNG·browser 도구·디자인 시스템)
- bbojjak-openclaw-gateway-architecture-lesson14 — 시리즈 Lesson 14 (Gateway·멀티채널 라우팅·Tailscale Funnel·보안 4중 잠금)
- bbojjak-openclaw-multichannel-session-lesson15 — 시리즈 Lesson 15 특별편 (Slack 스레드·텔레그램 토픽 세션 분리·DM 함정·bindings)
- bbojjak-openclaw-token-optimization-lesson16 — 시리즈 Lesson 16 (토큰 소비처 5순위·RTK·hook vs 지침·능동적 compact·Sonnet 전환)
- bbojjak-openclaw-agent-security-lesson17 — 시리즈 Lesson 17 (프롬프트 인젝션·보안 3원칙·에이전트 분리·심층 방어)
- bbojjak-openclaw-skill-ecosystem-lesson18 — 시리즈 Lesson 18 (보안 스킬 선택 3단계·구조>스킬·즉시 학습+SSOT·오픈 생태계 신뢰 평가)
- bbojjak-openclaw-resilience-failover-lesson19 — 시리즈 Lesson 19 (Model Failover·세션 스티킨스·Agent Loop·작업별 모델 분리·34% 절감)
- bbojjak-openclaw-information-boundary-lesson20 — 시리즈 Lesson 20 (분리 이후 운영·일방향 동기화·민감정보 추출·에스컬레이션·오탐 관리)