기술 세부 사항

이 페이지는 세부 내용을 원하는 사람을 위한 문서입니다. 여기에 있는 모든 내용은 측정하거나 소스에서 확인한 것이며 추정값이 아닙니다.

위젯 로드 방식

두 단계입니다. 먼저 작은 로더가 버튼만 그리고 다른 일은 하지 않습니다. 채팅 자체는 다섯 트리거 중 하나가 작동해야 가져옵니다. 브라우저 유휴 상태(늦어도 3초 후), 버튼 위의 마우스나 손가락, 페이지의 명령, MousePlayer의 불편 신호 또는 서비스 워커 등의 푸시 안내입니다.

이유가 있습니다. 대부분의 방문자는 채팅을 열지 않습니다. 이들의 페이지 로드를 지연시키지 않아야 합니다. 적용할 트리거는 script 태그에서 정합니다.

• 로더: CDN에서 gzip으로 전송 시 3.48 kB
• 전체 위젯: 같은 방식으로 전송 시 85.5 kB이며 트리거가 작동해야 전송
• 버튼 표시까지: 11–21 ms
• 레이아웃 이동: 0.0000 — 표시 전에 공간을 확보

비교 대상도 측정했으며 세 개 모두 brotli로 압축했습니다. Crisp 로더는 2,876 B, Intercom은 3,161 B입니다. 당사의 3,069 B는 그 사이이며 자릿수가 다를 정도로 작은 것이 아닙니다. 다르게 주장한다면 측정하지 않은 것입니다.

사이트에 영향을 주지 않음

위젯은 닫힌 shadow DOM에 있습니다. 운영자의 스타일은 위젯에, 위젯 스타일은 페이지에 적용되지 않습니다. * { box-sizing: border-box }를 설정하거나 모든 것을 재정의하는 CSS 프레임워크를 사용해도 마찬가지입니다.

엄격한 Content Security Policy에서도 콘솔 메시지 없이 실행됩니다. eval, 웹 글꼴, 추적 픽셀이 없습니다. style-src의 적용 대상이 아닌 constructable stylesheet로 스타일을 설정합니다. 따라서 버튼, 채팅 창, 제품 투어, 사이트의 상담원 콘솔에는 unsafe-inline이 필요하지 않습니다. style-src 'self', 심지어 style-src 'none'에서도 측정한 결과 위반 0건이며 스타일이 모두 적용되었습니다. 현재 Chromium에서 측정했습니다. constructable stylesheet가 없는 이전 브라우저(예: 16.4 이전 Safari)는 <style> 요소로 대체하며 엄격한 정책은 이를 차단합니다.

다른 서버로 보내는 요청은 0건입니다. 모두 reactive.chat에서 가져오며 자체 도메인이면 운영자의 주소에서 가져옵니다. 로고와 아바타 같은 이미지는 직접 지정한 주소에서 가져옵니다.

프로토콜

연결에는 WebSocket을 사용합니다. 네트워크가 WebSocket을 통과시키지 않으면 일반 HTTPS 요청(Server-Sent Events 또는 롱 폴링)을 사용합니다. 프로토콜은 버전이 있으며 오류 코드 31개를 정의합니다. 26개는 위젯용이고 나머지는 상담원 화면과 웹사이트 검색용입니다. 각각 정해진 클라이언트 동작(즉시 재시도, 대기 후 재시도, 재연결 후 재시도, 재시도 안 함)이 있으며 일부에는 종료 코드도 있습니다. 목록에 없는 오류는 일시적인 서버 오류처럼 처리합니다. 대기 후 재시도하며 5회 후에는 메시지를 미전달로 간주해 다시 보낼 수 있습니다. 끝없이 반복하지 않습니다.

간격을 늘리며 재연결합니다. 연결이 끊기면 메시지를 버퍼에 넣고 복구되는 즉시 보냅니다. 모든 메시지는 ID를 포함하며 서버가 중복을 인식해 두 번 저장하지 않습니다.

접근성

WCAG 2.2 AA를 기준으로 구축했습니다.

• 열린 창 안에서 포커스를 유지하고 ESC로 닫으며 포커스는 이전 위치로 복귀
• aria-live로 새 메시지 알림
• 텍스트와 표면의 대비를 가정하지 않고 계산 — 아래 참조
• 완전한 키보드 조작과 눈에 보이는 포커스 테두리

대비 계산

색상을 지정하면 표면은 정확히 그 색상을 사용합니다. 그 위의 텍스트는 일반 텍스트의 WCAG 요구 사항인 4.5:1에 도달할 때까지 조정합니다.

두 테마와 세 조합에서 색상 178개, 즉 데이터 지점 1,068개를 측정했습니다. 4.5:1 미만은 한 건도 없었으며 최저값은 4.50:1입니다.

다른 제공업체와의 차이입니다. 다른 곳에서는 아무도 읽지 못할 정도로 위젯을 설정할 수 있습니다.

개인정보

가림 처리는 두 곳에서 일어납니다. 데이터가 기기 밖으로 나가기 전 방문자의 브라우저에서, 그리고 저장 전 서버에서 다시 처리합니다. 카드 번호(Luhn 검사 포함), IBAN, 이메일 주소, 전화번호, 세금 번호와 신분증 번호를 인식합니다. 주문 번호와 고객 번호는 그대로 둡니다.

한 곳만으로는 충분하지 않아 두 곳에서 처리합니다. 브라우저 쪽은 끌 수 있고 서버 쪽은 도착한 내용만 볼 수 있습니다.

규칙

위젯이 말을 거는 시점은 코드의 조건이 아닌 선언형 규칙 목록으로 정합니다. 기본 규칙은 여섯 개입니다. 페이지에 머무름, 반복 클릭, JavaScript 오류, 막힌 양식, 구매 의도, 결제 이탈입니다. 반복 클릭, 막힌 양식과 구매 의도는 MousePlayer와 함께 사용할 때만 감지합니다. 계정에서 자체 규칙을 추가할 수 있습니다. Free 요금제에서는 프로젝트당 활성 안내 하나를 적용합니다.

실용적인 차이입니다. 규칙을 바꾸려면 배포가 아니라 계정의 설정을 변경하면 됩니다.

연동

웹훅과 Slack은 완료되었습니다. 그 밖에 30개 이상 서비스의 연결이 준비되어 있습니다. 대부분 모의 상대 서비스로 테스트했지만 실제 서비스에서는 아직 실행하지 않았으며 계정의 연동 페이지에 그렇게 표시됩니다.

서버 API(REST와 MCP)는 대화, 메시지, 프로젝트, 방문자, 이벤트와 규칙을 읽고 메시지와 이벤트를 작성하며 웹훅을 등록합니다. 방문자 목록과 MCP는 프로젝트별로 끌 수 있습니다.

모든 연동은 회로 차단기가 있는 큐로 처리합니다. 타사 서비스가 멈추면 반복 실패 후 잠시 건너뜁니다. 채팅 메시지는 이 때문에 지연되지 않습니다. 이 계층에서 가장 중요한 규칙입니다.

아직 완료되지 않은 사항

연동 중에 뒤늦게 알게 되지 않도록 안내합니다.

• MousePlayer가 아직 합의한 이벤트를 직접 발생시키지 않으므로 MousePlayer 브리지는 폴링합니다.
• 첨부 파일, A/B 테스트와 자체 도메인은 베타입니다. 작동하고 측정도 했지만 아직 변경될 수 있습니다.
• 이메일, Telegram, SMS, WhatsApp, Messenger와 Instagram 채널은 모의 상대 서비스로 테스트했으며 실제 계정에서는 아직 검증하지 않았습니다. 채널 답변이 최종 실패해도 현재 대화에 표시되지 않습니다.

문서에서 더 알아보기

위젯, 서버와 연결의 협력 방식: 아키텍처와 흐름. 연결, HTTP 대체 연결과 재연결: 전송. 모든 장: 문서.