수업 #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 설계가 실전에서 구현된 사례.

연결되는 위키 페이지