Prodantix

Prodantix는 소프트웨어를 만드는 사람들을 위해 만들어졌습니다. 모든 제품 팀은 늘 같은 세 가지를 묻습니다. 사람들이 우리 앱 안에서 실제로 무엇을 하고 있는지, 어떤 부분을 누구에게 보여 줘야 하는지, 그리고 무언가를 말하기에 적당한 때는 언제인지.

대부분의 회사는 이 세 가지 일마다 다른 도구를 삽니다. 문제는 거기서 시작됩니다. 도구마다 사용자에 대한 기록을 따로 갖고 있고, 그 기록들은 조금씩 어긋나기 시작합니다. 한 도구는 고객이 계정 설정을 끝냈다고 알고 있습니다. 다른 도구는 아직 따라오지 못해서, 지난주에 이미 끝낸 단계의 안내 메일을 보냅니다. 고객이 항의하거나 두 대시보드가 서로 다른 숫자를 보여 주기 전까지는 아무도 알아채지 못합니다.

엔진은 어떻게 구성되어 있는가

엔진은 네 개의 기본 요소로 이루어져 있고, 나머지는 모두 그 위에 올라갑니다. 각 요소가 다음 요소로 이어지므로 순서대로 보는 편이 좋습니다. 개념 레퍼런스에 전부 설명되어 있습니다.

이벤트

사용자가 한 하나의 행동을, 일어나는 순간에 잡아 둔 것입니다. 가입 완료, 페이지 열기, 중간에 그만둔 양식 같은 것들입니다. 이벤트는 원신호이며, 바깥에서 시스템으로 들어오는 유일한 것입니다. 나머지는 전부 여기서 파생됩니다.

사용자 상태

한 사용자에 대해 알려진 모든 것을, 살아 있고 조회 가능한 형태로 투영한 것입니다. 그 사람의 이벤트에서 파생되며 새 이벤트가 도착하는 순간 갱신됩니다. 분석과 기능 플래그, 메시징이 모두 이 같은 진실 공급원을 읽습니다. 야간 집계도 아니고, 어떤 작업이 맞춰 주는 사본도 아닙니다. 오직 하나만 존재합니다.

판단

사용자 상태를 기준으로 평가되는 규칙입니다. 누가 어떤 집단에 속하는지, 누가 플래그를 받는지, 누가 메시지 조건을 충족하는지를 정합니다. 판단은 질문받는 그 순간의 실시간 상태를 읽으므로, 낡은 그림을 근거로 답할 수 없습니다.

액션

판단이 성립했을 때 엔진이 하는 일입니다. 기능을 열어 주거나, 메시지를 보내거나, 워크플로를 시작합니다. 액션 자체도 이벤트로 기록되며, 바로 그것이 루프를 닫습니다. 엔진이 한 일이 엔진이 아는 것의 일부가 되는 것입니다.

분석은 상태를 읽는 일

Prodantix의 분석은 사용자 사본을 따로 들고 있는 별도의 저장소가 아닙니다. 사용자 상태를 직접 읽는 일입니다. 퍼널과 리텐션, 코호트는 엔진의 나머지가 작동하는 바로 그 실시간 투영에 대한 질의입니다. 그래서 데이터 웨어하우스로 가는 SQL 왕복도, 야간 집계를 기다리는 일도 없습니다. 상태는 이미 질문의 형태로 놓여 있습니다. 코호트는 여기서 일급 객체입니다. 이름이 있고 조건절로 정의되며, 사람들이 조건을 충족하거나 벗어남에 따라 소속이 계속 갱신됩니다.

다시 물을 질문을 저장해 두기

대시보드는 이름이 붙은 타일의 묶음이고, 타일은 이미 실행해 본 질의에 그것을 어떻게 그릴지를 더한 것입니다. 질의는 탐색기가 보낸 그대로 저장되므로, 타일이 쥐고 있는 것은 답의 그림이 아니라 질문 자체입니다. 하나를 열면 질의가 다시 돌고, 같은 질의 상태로 탐색기에 돌아가 기간을 옮기거나 분해 기준을 바꿀 수 있습니다. 그래서 대시보드는 낡은 내보내기 파일이 되지 않습니다. 볼 때마다 엔진이 살아 있는 상태에서 답해 주는 질문들의 묶음입니다.

숫자가 저 혼자 움직일 때

모든 차트를 지켜보는 사람은 없습니다. 지켜보는 몫은 Prodantix가 맡습니다. 계열을 구간 단위로 읽어 그 계열의 기준선과 흩어진 정도를 구한 다음, 거기서 너무 멀리 떨어진 구간을 위아래 양쪽 모두 표시합니다. 급락과 급등이 함께 보고되고, 각각 어떤 기준선에서 벗어났는지와 얼마나 멀리 나갔는지가 함께 나오므로 진짜 균열과 흔한 잡음을 가려낼 수 있습니다. 민감도는 고정된 규칙이 아니라 설정이며, 탐지기는 짐작하지 않습니다. 거의 평평한 계열이나 아직 형태를 갖추기에 너무 짧은 계열에서는 거짓 경보 대신 아무것도 나오지 않습니다.

상태가 가리키는 사람들

사용자 상태는 투영이고, 사람 목록은 그것을 한 사람씩 읽는 자리입니다. 콘솔은 프로젝트가 만난 모든 사람을 최근에 움직인 순서로 늘어놓고, 검색창과 내려갈수록 계속 불러오는 목록을 함께 둡니다. 각 행에는 엔진이 그 사람에 대해 쌓아 둔 것이 담깁니다. 이벤트 수, 서로 다른 세션 수, 처음과 마지막으로 본 시각, 마지막으로 한 일, 속한 그룹, 그리고 예약된 속성(이름, 이메일, 전화번호, 아바타)이 저마다의 열로 빠져나와 있습니다. 행을 열면 속성 표가 통째로 보이는데, 여기에는 정해진 필드 묶음이 아니라 여러분의 이벤트가 넣어 둔 것이 들어 있습니다. 그룹에는 자체 탭과 자체 속성이 있습니다. 회사나 워크스페이스는 그 자체로 하나의 대상이고, 그에 관한 사실은 구성원 각자가 아니라 그 대상에 속하기 때문입니다.

한 사람, 여러 개의 ID

방문자는 여러분이 그가 누구인지 알기 전에 먼저 도착합니다. SDK가 ID를 하나 붙여 주고, 그는 페이지 셋을 읽은 다음에야 가입합니다. 누군가 엔진에게 그가 누구인지 알려 주기 전까지 그 프로필에는 이름이 없고, 목록은 추측하는 대신 그대로 그렇게 말합니다. 가입이 일어나면 여러 ID가 하나의 기준 신원으로 이어지는 사슬로 묶이므로, 익명으로 남긴 자취는 두 번째 프로필을 만드는 대신 이름이 붙은 계정 안으로 접혀 들어갑니다. 각 행에는 몇 개의 ID가 그리로 이어지는지 나오고, 프로필이 그 목록을 보여 줍니다. 엔진 혼자 판단할 수 없는 곳에서는 두 프로필을 직접 합칠 수 있습니다. 어느 신원을 남길지는 여러분이 고르고, 충돌하는 항목은 그쪽 속성이 이기며, 수치는 더해집니다. 이렇게 합친 것은 다시 갈라지지 않습니다. 합치기 전 프로필은 감사 기록에 남으므로 무엇이 적혀 있었는지는 되찾을 수 있지만, 한번 합쳐진 두 사람은 다시 나눌 수 없습니다.

한 세션을 되짚어 보기

애널리틱스는 어제 열한 명이 같은 폼을 도중에 그만두었다는 사실까지는 알려줍니다. 이유는 알려주지 못합니다. 세션 리플레이는 페이지 자체를 기록합니다. 브라우저 SDK가 사용자가 작업하는 동안 문서와 그 위에서 일어나는 모든 변화를 붙잡아 순서가 매겨진 청크로 묶어 레코더로 올리고, 콘솔이 그 세션을 일어난 그대로 재생합니다. 모든 기록은 엔진의 나머지 부분이 쓰는 것과 같은 식별자 아래에 놓이므로, 세션은 별도의 도구 안에만 존재하는 방문자 ID가 아니라 이미 찾아볼 수 있는 사람의 것이 됩니다.

기록이 남겨도 되는 것

마스킹은 무언가를 설정하기 전부터 켜져 있습니다. 입력란에 친 글자는 청크가 올라가기 전에 브라우저 안에서 별표로 바뀌므로, 레코더에 닿은 것에는 애초에 내용이 담겨 있지 않습니다. 길이와 단어 경계는 남아서 재생 화면은 여전히 그 페이지처럼 보이고, 낱말 자체는 사라집니다. 비밀번호, 이메일, 전화번호 입력란은 마스킹이 켜져 있든 꺼져 있든 가려지므로, 꺼도 자격 증명 입력란이 드러날 수는 없습니다. 화면에 보이는 글은 그것까지 가려 달라고 하지 않는 한 그대로 남습니다. 청크마다 마스킹 여부가 기록되고 콘솔이 세션에 그 표시를 달아 주므로, 둘 중 무엇을 보고 있는지 늘 알 수 있습니다. 기록은 비공개 저장소에 있습니다. 콘솔은 한 번에 청크 하나에 대해 수명이 짧은 서명 링크를 요청하고, 그것 없이는 아무것도 닿지 않습니다. 그 뒤로 세션이 얼마나 남아 있는지는 이용 중인 요금제가 정합니다.

사람에 따라 다른 것을 보여 주기

팀은 새로운 것을 먼저 소수의 사용자에게만 내보내 상황을 본 뒤 모두에게 여는 경우가 많습니다. Prodantix는 사용자 상태에 대해 조건을 평가해 누가 무엇을 볼지 정합니다. 속성과 연산자와 값의 조합을, 저장된 명단에서 찾는 대신 플래그가 질문받는 그 순간에 검사합니다. 새 기능을 고객의 2퍼센트에게만 열어 사용 방식을 지켜본 다음, 다음 배포를 기다리지 않고 범위를 넓히거나 거둬들일 수 있습니다.

아직 도움이 될 때 도착하는 메시지

메시지는 아직 도움이 될 때에만 보낼 가치가 있습니다. Prodantix는 어떤 사람이 무언가를 한 순간, 또는 하지 못한 순간에 메시지를 보낼 수 있습니다. 고객이 요금제 한도에 다다르면 바로 그 자리에서 알게 됩니다. 이미 포기하고 다른 곳으로 떠난 다음 날 아침이 아니라요.

상대가 답장을 보내올 때

메시지는 누군가 답할 때까지 한 방향으로 가고, 답이 오면 그때부터는 지원 대화가 됩니다. Prodantix는 그것도 함께 맡는데, 그 안의 AI는 보내지 않고 초안을 씁니다. 모델에게 주어지는 것은 그 대화와 그 사람 본인의 상태뿐이고 그 밖에는 없습니다. 다른 고객의 대화도, 여러분 프로젝트의 나머지도 주어지지 않습니다. 모델은 제안 답변을 쓰고, 그 답변이 대화의 한 마디가 되는 것은 여러분의 상담원이 보내기를 누를 때뿐입니다. 그러니 “보내지 말고 제안하라”는 누군가 기억해야 할 규칙이 아니라 코드가 지어진 방식입니다. 대화는 자체 자격 증명도 지닙니다. 프로젝트 키는 프로젝트를 가리키고 SDK를 설치한 모든 페이지 안에 실려 다니므로 사람을 대신할 수 없습니다. 대화마다 그 하나의 대화에만 유효한 토큰이 발급되고, 요청 본문에 적힌 식별자가 상대를 정하는 일은 결코 없습니다. 대화를 여는 것은 공개 키 외에 아무것도 필요 없는 유일한 경로라서, 프로젝트별로도 호출자별로도 횟수가 제한됩니다.

순서를 직접 엮기

어떤 대응은 한 걸음으로 끝나지 않고, 그 순서는 직접 짜고 싶어집니다. 워크플로는 작은 그래프입니다. 수동으로, 또는 누군가 코호트에 들어오거나 빠져나갈 때 시작되어 노드를 따라 움직입니다. 액션 노드는 무언가를 합니다(로그 한 줄을 쓰거나, 여러분의 웹훅을 호출합니다). 지연 노드는 기다립니다. 최대 서른 날입니다. 대기 노드는 이름이 붙은 신호가 올 때까지 멈춰 있고, 신호가 끝내 오지 않을 때를 위한 출구를 따로 둘 수 있습니다. 분기 노드는 사용자 상태에 조건을 대 보고 맞는 길, 아니면 기본 길로 갑니다. 실행은 한 번에 한 노드씩 나아가고 다음을 집기 전에 각 단계가 확정되므로, 다시 시작해도 처음부터 되풀이하지 않고 실제로 도달했던 지점에서 이어집니다. 웹훅은 호출 전에 검사합니다. 대상은 공개된 https 주소여야 하고, 요청은 검사가 통과시킨 바로 그 주소로 가며, 리다이렉트는 따라가지 않고, 응답 없이 매달린 호출은 끊습니다.

AI 오케스트레이션, 그리고 루프가 닫히는 방식

위의 인터페이스들은 여전히 단계를 잇는 일을 여러분에게 남깁니다. 무언가를 알아채고, 그것이 누구에게 해당하는지 가려내고, 무엇을 할지 정하는 일입니다. Prodantix는 그 루프를 스스로 돌릴 수 있습니다. 엔진이 실시간 상태에서 의미 있는 순간을 감지하고, 해당하는 코호트를 고르고, 액션을 결정합니다. 이것이 흔한 자동화를 넘어서는 지점은 마지막에 있습니다. 액션이 이벤트로 기록되어, 다음 판단이 읽을 바로 그 사용자 상태로 되접힙니다. 시스템 자신의 행동이 그 사람에 대해 아는 것의 일부가 되며, 옆에서 벌어진 별개의 사건으로 남지 않습니다.

제안은 사람을 기다립니다

엔진은 자기 결론대로 알아서 움직이지 않습니다. 엔진이 내놓는 것은 제안이고, 제안은 글로 적힌 계획입니다. 이 플래그들, 이 코호트들, 이 메시지. 승인되기 전에 제안이 지목한 플래그와 코호트와 대화는 모두 여러분 자신의 테넌트에 대고 확인되며, 확인되지 않는 참조는 조용히 빠지는 대신 제안 전체를 무산시킵니다. 악의적인 내용을 읽어 버린 모델이 여러분의 프로젝트 바깥으로 손을 뻗지 못하는 이유가 바로 이것입니다. 승인은 사람의 행위이고, 무언가가 일어나는 지점도 거기입니다. 실행은 여러분이 손으로 쓰는 것과 같은 플래그와 메시지 경로를 지나므로 권한도, 감사 기록도, 요금제의 한도도 그대로 적용됩니다. 두 번 승인해도 두 번째에는 아무 일도 일어나지 않습니다.

이벤트를 들여보내기

모든 것은 수집 엔드포인트로 보낸 이벤트에서 시작하고, 엔진은 그것을 곧바로 사용자 상태에 접어 넣습니다. SDK는 웹과 모바일, 서버를 지원합니다. React만은 예외로, 생명주기 때문에 전용 어댑터가 필요합니다. 클라이언트를 한 번만 설치하고 StrictMode에서도 안전한 provider와 hook입니다. 퀵스타트가 몇 줄로 연결해 줍니다.

키와 환경

모든 SDK 호출은 프로젝트 키를 지니며, 키는 콘솔에서 발급합니다. 프로젝트를 만들면 live와 test 두 환경이 생기고 각각 고유한 키를 갖습니다. 개발은 test로, 배포는 live로 합니다. 두 키 모두 생성 직후 딱 한 번만 표시됩니다. 서버가 해시만 저장하기 때문에 이후 어떤 화면도 다시 보여 줄 수 없습니다. 교체는 고른 환경의 새 키를 발급하며, 이전 키를 즉시 끊을지 유예 기간을 둘지는 여러분이 정합니다.

엔진과 대화하는 네 가지 방법

REST는 세 개의 호스트에 걸쳐 있습니다. 플래그와 메시징용, 이벤트 수집용, 세션 리플레이용이며 각각 /openapi.json에 자체 OpenAPI 문서를 제공합니다. 수집은 202를 반환하는데, 이는 이벤트가 처리를 위해 접수되었다는 뜻이지 저장되었다는 뜻은 아닙니다. 형식이 잘못된 이벤트는 뒤쪽 파이프라인에서 버려질 수 있습니다. GraphQL은 프로젝트와 플래그, 워크플로, 분석, 메시징, 코호트, 청구를 포함한 애플리케이션 모델 전체를 다룹니다. 실시간 인터페이스는 플래그 변경과 메시지, 워크플로 실행을 전달하고 인증되지 않은 연결은 즉시 끊습니다. MCP 인터페이스는 에이전트가 도구 호출로 읽고 쓰게 해 주며, 기계 대 기계 전용이라 브라우저 요청은 거부합니다.

데이터는 계속 여러분의 것입니다

Prodantix는 저희 서버에서도, 여러분의 서버에서도 돌릴 수 있고 어느 쪽이든 똑같이 동작합니다. 넣어 둔 모든 것은 원할 때 언제든 전부 다시 꺼낼 수 있습니다. 저희는 여러분의 데이터를 팔지 않고, AI 모델 학습에도 쓰지 않습니다. 구조상 Prodantix는 여러분이 어디에 가지고 있는 것보다 가장 완전한 고객 기록을 갖게 됩니다. 그래서 이 약속은 다른 곳에서보다 여기서 더 무겁습니다.

이런 분께 맞습니다

Prodantix는 이 일을 위해 두세 개의 도구를 따로 돌리고 있고, 그것들이 서로 어긋나는 데 지친 팀에 맞습니다. 고객이 늘어나 이제는 여기저기 물어보는 것만으로 무슨 일이 일어나는지 알 수 없게 됐을 때 가장 쓸모가 큽니다.

바로가기 Prodantix: prodantix.com