부동산 마케팅
웹사이트와 Facebook의 고객 리드를 하나의 운영 화면으로
폼과 Lead Ads 웹훅을 공통 PostgreSQL 모델로 모으고 권한이 적용된 관리 화면과 이메일 알림으로 연결했습니다.
문제
웹 폼과 Facebook Lead Ads에서 서로 다른 형식과 시점으로 리드가 들어왔습니다. 이메일과 스프레드시트로 전달하면 중복, 처리 상태, 담당자 접근 권한이 점차 어긋납니다. 언제 들어왔고 누가 접근했으며 이후 어떻게 처리했는지도 추적하기 어려웠습니다.
제약 조건
- 공개 폼과 Meta 웹훅은 외부 요청을 받으면서도 관리 기능이나 리드 데이터를 노출하지 않아야 합니다.
- 이벤트 재전송, 필드 누락, 지연 도착에 대비해 중복을 식별하고 안전하게 재시도해야 합니다.
- 리드 데이터는 민감한 운영 정보이므로 수량, 내용, 고객 신원을 공개할 수 없습니다.
우리가 한 일
PostgreSQL을 운영 데이터의 기준으로 사용
리드, 소스, 상태, 운영 관계를 PostgreSQL에서 관리하고 관리 화면의 읽기·쓰기·권한에 공통 트랜잭션 모델을 적용했습니다.
채택하지 않은 대안 BigQuery는 분석에 적합하지만 빈번한 상태 변경과 관계형 업무를 다루는 일상 운영 데이터베이스로는 선택하지 않았습니다.
공개 진입점과 관리 기능 분리
웹 폼, 웹훅 수신, 인증된 관리 기능의 경계를 명확히 해 외부 트래픽이 내부 운영에 미치는 영향을 줄였습니다.
채택하지 않은 대안 공개 영역과 관리 영역은 위험과 확장 양상이 다르므로 모든 경로와 권한을 구분 없는 구조에 넣지 않았습니다.
웹훅을 즉시 수신하고 재전송 방지
Facebook Lead Ads 이벤트를 도착 즉시 검증하고 처리하며 소스 식별자로 같은 이벤트의 중복 등록을 방지했습니다.
채택하지 않은 대안 정기 조회에만 의존하면 알림이 지연되고 원래 이벤트 순서를 파악하기 어려워 수신 시점 처리를 적용했습니다.
역할과 감사 이력을 핵심 모델에 반영
화면에서 버튼을 숨기는 데 그치지 않고 인증, 역할별 접근, 작업 기록으로 관리 화면을 통제합니다.
채택하지 않은 대안 민감한 정보 접근에는 추적 가능한 백엔드 경계가 필요하므로 공유 계정이나 프론트엔드 조건으로 권한 검증을 대신하지 않았습니다.
성과
- 웹 폼과 Facebook Lead Ads가 하나의 운영 데이터 모델로 통합되었습니다.
- 권한이 있는 담당자는 흩어진 이메일과 스프레드시트 대신 역할에 맞는 관리 화면에서 작업할 수 있습니다.
- 알림, 소스, 처리 상태를 시스템 작업 흐름 안에서 추적할 수 있습니다.
기술
- Go
- PostgreSQL
- Google Cloud Run
- Cloud SQL
- Meta Webhooks
돌아보며
다시 시작한다면 데이터 보존 규칙과 최소 권한 목록을 첫 출시의 요구사항으로 정하겠습니다. 출시 후로 미룰 수 없습니다. 리드 시스템을 신뢰할 수 있는지가 여기에 달려 있기 때문입니다.