OpenClix

규칙은 대시보드나 데이터베이스가 아니라 하나의 JSON 파일에 있다. 스키마 마이그레이션도 없다. 배포 시간대도 없다. 앱을 그 설정으로 향하게 하면, 앱 리소스에 포함되어 있든 HTTPS로 받아오든, 다음 실행에서 인게이지먼트 동작이 바뀐다. 인프라 티켓을 기다리는 데 익숙한 팀에게는 그것이 곧 전부인 셈이다.

OpenClix는 기기에서 실행되므로 로컬 우선 용도에는 호스팅 컨트롤 플레인도 API 키도 없다. 앱이 스스로 실행하는 순수한 푸시 알림 로직과 앱 내 메시징이다. 알림이 앱에서 나가므로 지연이 낮게 유지된다. 주의할 점은, 보통 서버 측에서 하던 원격 세그먼트 분할 같은 일은 범위에 들지 않는다는 것이다.

OpenClix 클라이언트 코드를 실행 시점에 패키지 레지스트리에서 당겨오는 대신, 기록으로 남긴 소스로 자기 저장소에 가져온다. 모든 줄을 읽는다. 동작을 직접 패치한다. 독점 SDK에 묶이지 않는다. 업그레이드가 자기 몫이 된다는 뜻이기도 한데, 편의보다 통제를 중시한다면 공정한 거래다.

폴더 구조가 읽기 쉽다. 인터페이스와 스키마가 명시적이다. 저장소에는 예제, 픽스처, 문서화된 편집 지점이 들어 있다. 그래서 AI 에이전트가 설정을 읽고 규칙을 조정해, 검토 가능한 diff를 건넬 수 있다. 코딩 에이전트에게 사내 관례를 설명하려 애써 본 적이 있는가. 여기서는 그럴 필요가 없다. 문서를 가리키면, 추측 없이 일할 만큼의 구조가 갖춰져 있다.

OpenClix는 앱이 이미 내보내는 이벤트에 반응하므로, 메시지를 움직이려고 별도의 추적 파이프라인을 세울 필요가 없다. 그 이벤트를 한 번 규칙에 연결하면, 같은 훅이 온보딩, 연속 기록, 재인게이지먼트를 감당한다. 트리거마다 디버그 사유가 있어 메시지가 떴는지 안 떴는지 이유를 보기 쉽다.

규칙의 모든 판단은 확인할 수 있는 사유를 드러낸다. 그 유도는 왜 새벽 2시에 나갔을까. 다른 하나는 왜 한 번도 뜨지 않았을까. 운영 중인 백엔드에 무작정 테스트 발송하는 대신, 로직을 로컬에서 추적한다. 작은 차이지만 실제 사용자층에 맞춰 타이밍을 다듬을 때는 큰 차이다.