FAQ

사용자가 무언가를 설치해야 하나요?

아니요. 사용자는 스크립트 태그 하나를 HTML에 붙여넣기만 하면 됩니다 — npm 패키지, 빌드 단계, 의존성이 없습니다. 추가 기능은 같은 오리진에서 자동으로 로드됩니다.

제 CSS와 충돌하나요?

아니요. 위젯은 Shadow DOM 내부에서 렌더링되어 스타일을 페이지로부터 완전히 격리합니다.

싱글 페이지 앱(React, Vue, Next.js)을 지원하나요?

예. 스크립트는 한 번 로드되어 라우트 변경 전반에 걸쳐 유지됩니다. React/Next.js에서는 스크립트를 루트 레이아웃에 배치하세요.

Next.js App Routertsx

// app/layout.tsx (App Router)
import Script from 'next/script';
import { ReactNode } from 'react';

export default function RootLayout({ children }: { children: ReactNode }) {
  return (
    <html lang="en">
      <body>
        {children}
        <Script id="respondo-init" strategy="afterInteractive">
          {`
            window.Respondo = window.Respondo || {};
            Respondo.init = Respondo.init || function(c) { window.RespondoAIConfig = c; };
            Respondo.q = Respondo.q || [];
            Respondo.identify = Respondo.identify || function(d) { Respondo.q.push(['identify', d]); };
            Respondo.init({
              agentId: 'YOUR_AGENT_ID',
              channelId: 'YOUR_CHANNEL_ID'
            });
          `}
        </Script>
        <Script src="https://api.respondo.ai/widget/widget.js" strategy="afterInteractive" />
      </body>
    </html>
  );
}

대화가 해결되면 어떻게 되나요?

해결 후 새 메시지가 오면 이전 대화와 연결된 후속 대화가 자동으로 열립니다(Inbox에는 "Continued from #N"으로 표시). 언어 같은 맥락과 이전 대화 기록이 이어지고, 방문자에게는 하나의 연속된 채팅으로 보입니다. 해결된 대화를 팀원이 처리하고 있었다면 후속 대화는 AI가 아니라 팀으로 다시 라우팅되고, 그렇지 않으면 AI가 넘겨받습니다.

위젯은 어떻게 로드되나요?

위젯은 비동기(async)로 로드되므로 페이지 렌더링을 절대 차단하지 않습니다. 코어 번들은 약 180KB(gzip 압축 시 약 50KB)이며, 선택적 기능(캠페인, 제품 투어)은 위젯이 마운트된 후 별도의 지연 청크로 로드되므로 초기 페이지 렌더링은 절대 차단되지 않습니다.

이관은 어떻게 작동하나요?

사용자는 "상담원과 대화" 버튼을 클릭하거나, 사람을 요청하는 문구를 입력할 수 있으며, AI가 지식 베이스를 근거로 답변할 수 없으면 스스로 대화를 넘깁니다. 이관되면 AI는 응답을 중단하고 모든 후속 메시지는 지원팀으로 전달됩니다. 자세한 내용은 이관 및 인계 섹션을 참고하세요.

이관 후에도 사용자가 AI와 계속 대화할 수 있나요?

예. 위젯은 "AI로 계속하기" 버튼을 표시하여 사용자가 이관을 해제하고 AI 대화를 재개할 수 있게 합니다.

지식 베이스 및 웹사이트 크롤링#

내 웹사이트 크롤링이 차단된 이유는 무엇인가요?

"차단됨"은 사이트 또는 그 보호 계층(Cloudflare, WAF, 안티봇 플러그인)이 저희 크롤러를 거부했다는 뜻입니다. 시작 페이지나 robots.txt가 매 시도마다 접근 오류 또는 "브라우저 확인 중" 챌린지로 응답했거나, robots.txt가 저희 크롤러를 명시적으로 금지하고 있습니다. 이전에 가져온 페이지는 그대로 유지되며, 사이트가 허용하기 전까지 재동기화는 같은 방식으로 실패합니다. 사이트 소유자에게 보호 설정에서 User-Agent RespondoAI-Crawler(전체 문자열: Mozilla/5.0 (compatible; RespondoAI-Crawler/1.0; +https://respondo.ai/bot))를 허용하도록 요청하세요 — Cloudflare에서는 Security → WAF → Custom rules입니다 — 그리고 robots.txt가 원인이라면 User-agent: RespondoAI-Crawler에 대한 허용 규칙을 추가하도록 요청하세요. Respondo는 고정된 크롤러 IP 주소를 공개하지 않습니다. User-Agent 기준으로 허용 목록을 설정하고, 소스에 표시된 오류에 IP가 명시되어 있다면 그 IP도 허용하세요. 사이트를 변경할 수 없다면 같은 콘텐츠를 파일이나 붙여넣은 텍스트로 추가하세요.

크롤링은 끝났는데 몇 페이지만 찾았습니다

페이지는 사이트의 사이트맵(robots.txt의 Sitemap: 줄 또는 /sitemap.xml 같은 일반적인 위치)과 시작 URL에서 링크를 따라가며 찾습니다 — 최대 10단계 링크 깊이, 소스당 최대 5,000페이지입니다. 같은 사이트에 있고 시작 URL의 경로 아래에 있는 페이지만 가져옵니다. https://example.com/help에서 시작한 크롤링은 /blog를 건너뛰므로, 루트에서 시작하거나 포함 경로를 추가하세요. 어떤 링크나 사이트맵도 가리키지 않는 페이지, robots.txt가 금지한 페이지, 로그인 뒤에 있는 페이지는 찾지 못합니다. 거의 동일한 페이지(인쇄용 버전, 추적 매개변수가 붙은 변형)는 하나로 병합됩니다. 콘텐츠가 전부 JavaScript로 그려지는 페이지는 감지되어 브라우저 기반 대체 방식으로 렌더링되므로, 페이지 수가 적다면 보통 렌더링이 아니라 범위나 사이트맵 문제입니다.

크롤링을 사이트의 한 섹션으로 제한하려면 어떻게 하나요?

웹사이트 추가 대화상자에서 Advanced를 열고 Only crawl paths starting with(다음으로 시작하는 경로만 크롤링) 및/또는 Skip paths starting with(다음으로 시작하는 경로 건너뛰기)를 한 줄에 경로 하나씩, 각 필드당 최대 50개까지 입력하세요. 매칭은 전체 경로 세그먼트 단위로 이루어집니다. /docs는 /docs 및 /docs/getting-started와 일치하지만 /docs-archive와는 일치하지 않습니다. 끝의 슬래시는 무시되며, 전체 URL을 붙여넣어도 경로 부분만 사용됩니다. 건너뛰기 규칙이 포함 규칙보다 우선합니다. 같은 규칙이 사이트맵과 해당 소스의 이후 모든 재동기화에 적용됩니다.

Respondo는 내 웹사이트를 얼마나 자주 다시 크롤링하나요?

각 웹사이트 소스의 페이지 패널에는 Auto-refresh 일정이 있습니다: Off(끄기), Daily(24시간마다), Weekly(7일마다). 예약된 크롤링은 증분 방식입니다. 사이트맵의 lastmod가 이전 크롤링보다 오래된 페이지는 건너뛰고, 변경되지 않은 페이지는 다시 색인하지 않으며, 변경된 페이지는 다시 색인하고, 사라진 페이지는 제거합니다. 즉시 새로고침하려면 소스 메뉴의 Re-sync 또는 Knowledge 페이지의 Re-sync all을 사용하세요.

"이번에는 사이트를 읽을 수 없었습니다" — 무슨 일이 있었나요?

이는 일반적인 실패입니다. 사이트가 제때 응답하지 않았거나, 도메인이 확인되지 않았거나, 서버가 오류를 반환했거나, 시작 페이지에 읽을 수 있는 텍스트가 없었거나, 주소를 찾을 수 없었던 경우입니다. 세부 정보는 소스에 표시됩니다. URL이 브라우저의 시크릿 창에서 열리는지, 도메인에 오타가 없는지, 시작 페이지가 로그인 화면이 아닌 실제 콘텐츠 페이지인지 확인하세요. 소셜 네트워크와 메시징 플랫폼(Facebook, Instagram, LinkedIn, X, YouTube 등)은 아예 가져올 수 없으며 크롤링 시작 전에 거부됩니다. 기존 페이지는 유지됩니다. 일정이 설정된 소스는 다음 실행 때 다시 시도하며, 그렇지 않으면 사이트에 다시 접근할 수 있게 된 후 재동기화하세요.

"검색 인덱스가 가득 찼습니다"와 "이 소스를 색인할 수 없었습니다"는 무슨 뜻인가요?

두 메시지 모두 콘텐츠를 성공적으로 읽은 뒤에 나타납니다. 인덱스가 가득 참은 이 소스가 복사되는 검색 인덱스에 Respondo 쪽 공간이 없다는 뜻입니다 — Respondo의 한도이지 콘텐츠의 문제가 아닙니다. 페이지는 저장되어 있고, 이미 색인된 모든 것은 계속 답변에 사용되며, 저희 팀에 자동으로 알림이 가고, 공간이 생기면 소스가 색인됩니다. 그전에 재동기화하면 같은 방식으로 실패합니다. 이 소스를 색인할 수 없었습니다는 이번에 검색 인덱스 구축이 실패했다는 뜻입니다 — 저희 쪽의 일시적인 오류이며, 기존 데이터는 그대로이고 작업은 자동으로 재시도됩니다. 두 메시지 중 하나가 계속되면 오류의 "Copilot에 질문하기"를 사용하세요.

긴 페이지는 앞부분만으로 답변되나요?

아니요. 크롤링된 각 페이지는 약 1,600자 단위의 서로 겹치는 청크로 나뉘고, 각 청크는 페이지 제목과 함께 개별적으로 색인되므로 긴 글의 어느 부분에서든 답변이 나올 수 있습니다. 인용은 여전히 페이지당 링크 하나를 표시합니다. 이 변경 전에 가져온 페이지는 이후 재동기화 때 다시 분할됩니다.

크롤링 오류에 대한 도움은 어떻게 받나요?

Knowledge 페이지의 모든 크롤링 또는 색인 오류에는 Copilot에 질문하기 버튼이 있습니다. 오류가 첨부된 상태로 Copilot이 열리고, Copilot은 Respondo 자체 도움말 문서를 바탕으로 귀하의 사례에 맞는 구체적인 단계를 답변합니다. 이 도움은 무료이며 AI 요청 수에 포함되지 않습니다. 단계로 해결되지 않으면 그렇게 말하세요 — "도움이 되지 않았어요"라고만 해도 충분합니다. 그러면 Copilot이 문제를 Respondo 팀에 넘기는 카드를 제안합니다. 카드에는 정확히 무엇이 전송되는지 표시되고, 확인하기 전까지는 아무것도 전송되지 않으며, 답변은 같은 Copilot 스레드로 도착합니다. 넘길 수 없는 상황이라면 Copilot이 침묵하는 대신 그 사실을 분명히 알려 줍니다.

고객에게 도착하지 않는 메시지#

답장에 "Not delivered"라고 표시됩니다 — 무슨 뜻이고 먼저 무엇을 해야 하나요?

받은편지함의 모든 발신 메시지에는 전달 상태 표시가 붙습니다: Queued(비슷한 시각에 작성된 답장은 하나로 묶여 몇 분 뒤 한 통의 이메일로 나갑니다), Sending…, Sent, Delivered, 또는 빨간색 실패 표시입니다. 실패는 세 가지 모습입니다: Not delivered — 채널이 메시지를 거부했습니다. Bounced — 옆에 반송 하위 유형이 함께 표시되며, 수신자의 메일 서버가 이메일을 거부했다는 뜻입니다. Marked as spam — 수신자가 스팸으로 신고했습니다. 라벨에 마우스를 올리거나 클릭하면 툴팁에 제공업체가 보낸 문구가 그대로 나오고, 반송이라면 원본 SMTP 진단 메시지까지 표시됩니다. 그 옆에는 최대 두 개의 작업이 있습니다 — 실제로 다시 보내는 Retry / Send again, 그리고 오류를 첨부한 채 Copilot을 여는 Ask Copilot입니다. 재시도 버튼이 아예 없다면 그 주소는 차단된 상태이며 다시 보내도 똑같이 실패합니다. Sent 또는 Delivered 옆에 N files not delivered가 붙어 있다면 본문은 도착했지만 첨부 파일은 도착하지 못했다는 뜻입니다 — 해당 채널이 그 파일을 전달할 수 없었습니다.

이메일이 왜 고객에게 도착하지 않았나요?

원인은 네 가지이고, 라벨로 구분됩니다. 영구 반송은 주소가 존재하지 않거나 메일을 받지 않는다는 뜻입니다 — 재시도 버튼이 없고 주소는 차단 목록에 올라갑니다. 일시 반송은 메일함이 가득 찼거나 수신 서버의 일시적인 문제입니다. Send again이 제공되고 대개 나중에 성공합니다. 진단 메시지에 SPF, DKIM, DMARC 또는 5.7.515가 언급된 반송은 성격이 다릅니다: 귀하의 발신 도메인이 인증 검사를 통과하지 못해 수신자의 메일 시스템이 메시지를 거부한 것입니다. 도메인을 고치기 전까지 새 답장도 똑같이 반송되므로, 그동안에는 다른 채널로 답하고 Settings → Channels의 이메일 채널에서 DNS 레코드를 수정하세요. 마지막으로 Marked as spam은 수신자가 "스팸 신고"를 눌렀다는 뜻입니다: 주소가 차단되고 더는 발송하지 않습니다. 캠페인 리포트에는 추가로 The email provider rejected this message(이메일이 나가기도 전의 영구 거부 — 대개 확인되지 않은 발신 도메인이나 형식이 잘못된 주소)와, 특정 연락처가 아니라 워크스페이스 설정의 문제인 The email provider rejected our credentials가 나타날 수 있습니다.

차단 목록이란 무엇이고, 주소를 어떻게 해제하나요?

워크스페이스별로 비공개로 관리되는, Respondo가 발송을 거부하는 이메일 주소 목록입니다. 메시지가 하드 바운스(영구 거부)되거나, 누군가 귀하의 이메일을 스팸으로 신고하거나, 수동으로 차단한 경우 주소가 목록에 오릅니다. 소프트 바운스는 절대 주소를 차단하지 않습니다. 차단이 유효한 동안 해당 주소로의 캠페인 발송은 This address is blocked after an earlier bounce or complaint와 함께 건너뛰고, 받은편지함의 답장은 나가기 전에 거부됩니다. 차단되는 것은 언제나 메시지의 실제 수신자뿐입니다 — 반송 알림이 임의의 주소를 막을 수는 없습니다. 대시보드에는 이 목록을 보여주는 화면이 없습니다: 소유자나 관리자는 GET https://api.respondo.ai/api/v1/integrations/email/suppressions로 목록을 읽고 DELETE https://api.respondo.ai/api/v1/integrations/email/suppressions/<email>로 한 건을 해제할 수 있으며, Respondo 지원팀에 요청해도 됩니다. 하드 바운스는 메일함이 실제로 복구되었다고 확신할 때만 해제하세요 — 죽은 주소로 다시 보내면 도메인 평판이 손상됩니다.

WhatsApp이 답장을 받지 않습니다 — 24시간 창

WhatsApp은 고객의 마지막 메시지로부터 24시간 이내에만 비즈니스가 자유 형식 메시지를 보낼 수 있게 합니다. 그 이후는 Meta가 오류 131047로 거부합니다. Respondo는 이 창을 사람별로 추적하며, 창이 만료된 것을 알고 있으면 답장이 나가기 전에 막습니다. 창 기록이 아예 없는 경우 — 가져온 연락처이거나 한 번도 메시지를 보낸 적 없는 번호 — 에는 막지 않습니다: 메시지는 Meta로 가고 Meta가 판단합니다. 앞으로 갈 길은 정확히 두 가지입니다. 고객이 다시 메시지를 보내기를 기다리거나 — 그 메시지가 창을 24시간 더 열어 주고 그때 답장이 나갑니다 — Meta 승인을 받은 템플릿을 보내는 것입니다. 템플릿은 대화 작성창에서 보낼 수 없습니다. Outbound → WhatsApp templates에서 관리하세요: Sync는 번호에 이미 등록된 것을 가져오고, New template은 Meta에 심사를 신청합니다(심사에는 하루 이상 걸립니다). 그런 다음 승인된 템플릿을 해당 연락처를 대상으로 하는 아웃바운드 캠페인으로 보내세요. 템플릿은 창 안팎을 가리지 않고 도달하지만, 상태가 approved일 때만 가능합니다.

"해당 채널의 연결이 끊어졌습니다" / "해당 채널이 연결되어 있지 않습니다"

Disconnected는 연동은 존재하지만 더 이상 활성 상태가 아니라는 뜻입니다 — 액세스 토큰이 취소되었거나 만료되었거나, 누군가 연결을 끊었습니다. Not connected는 연락처의 해당 엔드포인트 뒤에 연동이 아예 없다는 뜻입니다. 둘 다 Settings → Channels에서 고칩니다. 연결이 끊긴 채널은 별도 제목 아래에 모이고 각 카드에 Reconnect 버튼이 있습니다. 다시 연결한 뒤 메시지를 재시도하세요. 비슷해 보이지만 다른 두 경우가 있습니다: 발신 도메인이 확인되지 않은 이메일 채널은 Live로 전환할 수 없고 DKIM과 SPF가 확인될 때까지 아무것도 보내지 않으며, 수신 전용 채널은 설계상 발신을 거부하므로 거기서 Retry는 결코 성공하지 않습니다.

"이 사람에게 연락할 채널이 없습니다" / "이 연락처에 이메일 주소가 없습니다"

둘 다 받은편지함이 아니라 캠페인의 발송 리포트에 나타납니다. 첫 번째는 연락처의 엔드포인트 중 어느 것도 캠페인이 발송하는 채널과 맞지 않았다는 뜻입니다. 유일한 엔드포인트가 수신 전용 채널에 있다면 그것은 의도적인 건너뛰기로 따로 보고됩니다. 두 번째는 캠페인이 이메일을 보내는데 연락처에 등록된 주소가 없다는 뜻입니다. Telegram에는 고유한 경우가 있습니다: 상대가 귀하의 봇에 한 번도 메시지를 보낸 적이 없으면 쓸 수 있는 대화 자체가 없습니다. Bot API가 봇이 먼저 말을 거는 것을 금지하기 때문에 상대가 첫 메시지를 보내야 합니다. 연락처에 빠진 주소를 추가하거나, 캠페인이 대상으로 삼는 채널을 넓히거나, 이메일로 대체되도록 허용해 해결하세요.

연락처가 수신을 거부했습니다 — 무엇을 보낼 수 있나요?

They had already unsubscribed는 연락처에 전역 수신 거부가 설정되어 있다는 뜻입니다 — 귀하의 이메일에 있는 수신 거부 링크로, 가져오기로, 또는 팀원이 직접 전환해 설정됩니다. 캠페인과 시리즈는 이메일뿐 아니라 모든 채널에서 이런 연락처를 건너뛰며, 발송은 실패가 아니라 건너뜀으로 기록됩니다. 대화 안에서 팀원이 보내는 일대일 답장은 의도적으로 차단되지 않습니다: 수신 거부는 일괄 발송에 관한 것이고, 먼저 말을 건 사람에게 답하는 것은 사람의 판단이기 때문입니다. 상태는 연락처에 Outbound: Subscribed / Unsubscribed로 표시되고, 연락처 목록을 이 값으로 필터링할 수 있으며, 연락처의 Re-subscribe 버튼으로 되돌릴 수 있습니다 — 본인이 요청했을 때만 사용하세요.

재시도는 몇 번까지 하나요? Retry를 눌러도 안전한가요?

받은편지함에서 보낸 답장은 최대 다섯 번까지 시도하는 대기열로 넘어가며, 시도 사이에 대략 3분, 10분, 30분, 30분을 기다립니다. 재시도되는 것은 일시적 실패뿐입니다 — 타임아웃, 거부된 연결, 속도 제한, 제공업체 자체의 서버 오류. 영구 거부(존재하지 않는 주소, 확인되지 않은 발신 도메인, 거부된 자격 증명)는 반복해도 같은 답이 오므로 즉시 실패로 표시됩니다. 캠페인 발송은 자체 대기열에서 최대 여섯 번 시도하며 대기 시간은 더 짧습니다 — 5초, 30초, 2분, 10분. 이 횟수를 다 쓰면 발송은 "queued" 상태로 영원히 남지 않고 Delivery kept failing and was stopped after several attempts로 종료됩니다. 손으로 Retry를 눌러도 안전합니다. 정말로 실패 상태인 메시지에만 작동하고, 이메일이라면 먼저 원본이 어떻게 되었는지 제공업체에 확인합니다: 그 이메일이 실제로 나갔다면 두 번째 사본을 보내는 대신 행이 전달됨으로 바뀌고, 진짜 재발송은 새 멱등성 키로 나갑니다. 두 번째 사본이 잘못될 상황 — 하드 바운스, 스팸 신고, 아직 전송 중인 발송 — 에서는 버튼이 없거나 이유와 함께 재시도가 거부됩니다.

원인이 여전히 분명하지 않습니다 — 어떻게 도움을 받나요?

실패한 모든 메시지 옆에는 Ask Copilot 버튼이 있습니다. 오류와 채널, 대화를 첨부한 채 Copilot이 열리고, Copilot은 Respondo 자체 도움말 문서를 바탕으로 바로 그 실패에 맞는 단계를 답변합니다. 이 도움은 무료이며 AI 요청 수에 포함되지 않습니다. 단계로 해결되지 않으면 그렇게 말하세요 — "도움이 되지 않았어요"라고만 해도 충분합니다. 그러면 Copilot이 문제를 Respondo 팀에 넘기는 카드를 제안합니다. 카드에는 정확히 무엇이 전송되는지 표시되고, 확인하기 전까지는 아무것도 전송되지 않으며, 답변은 같은 Copilot 스레드로 도착합니다. 넘길 수 없는 상황이라면 Copilot이 침묵하는 대신 그 사실을 분명히 알려 줍니다.