Airbridge 제품 이해
공개 문서와 엔지니어링 블로그, 데모 앱으로 살펴본 개인 학습 기록 (2026-10 기준)
AB180과 세 제품
사용자를 데려오고, 다시 부르고, 행동을 보는 흐름을 세 제품이 나눠 맡음
AB180
Airbridge자체 개발
데려오기: 광고 성과 측정
- 모바일 측정 파트너(MMP, Mobile Measurement Partner)
- 어느 광고가 앱 설치나 구매를 만들었는지 판정
- 매체에서 클릭 같은 접점 데이터와 비용, SKAN 데이터 수집
- 판정 결과를 매체에 다시 보내 광고 학습과 정산에 활용
이 페이지의 주제
Braze국내 총판
다시 부르기: CRM 메시지
- 마케팅 자동화 솔루션
- 조건에 맞는 사용자에게 푸시, 이메일, 알림톡 자동 발송
Amplitude국내 총판
보기: 제품 분석
- 제품 분석 도구
- 이벤트 기준 퍼널, 리텐션, 코호트 분석
Braze와 Amplitude는 미국 회사 제품, AB180은 국내 총판. 블로터 기사 ↗
예상 아키텍처
공개 엔지니어링 블로그를 바탕으로 예상해 본 구조.
시점이 다른 글을 합친 것이라 실제 구조와 다를 수 있음.
공개 글에 나온 단계추정한 연결외부Integration 관련 기능
받기와 보내기
구조도의 연동은 두 방향으로 나뉨. 주기는 헬프센터 연동 개요 기준.
받기: 매체 → Airbridge
- 광고 채널 연동 클릭 같은 접점 데이터, 1시간
- 비용 연동 캠페인별 광고비, 4시간
- SKAN 연동 애플이 묶음으로 주는 iOS 성과, 24시간
- 캠페인 API 연동 캠페인 정보, 24시간
보내기: Airbridge → 외부
- 전환 API, 포스트백 판정된 전환을 매체로, 기본 실시간
- 데이터 스토리지 원본 데이터를 고객 저장소로, 하루 1회
- 오디언스 조건에 맞는 사용자 묶음을 매체나 CRM으로, 하루 1회
공식 Integrations 페이지 기준 광고 채널 330개 이상 (2026-10 확인).
단계별 역할
이벤트 수집과 분석
- 이벤트 수집 들어온 이벤트를 받아 큐에 넘김
- 이벤트 큐 받는 일과 처리하는 일을 분리(추정)
- 공통 전처리 서로 다른 입력을 공통 형식으로 맞춤
- 종류별 라우팅 이벤트 종류마다 맡은 워커로 나눠 보냄. 먼저 처리할 종류보다 앞서 나가지 않게 기다려 같은 사용자 흐름의 순서를 지킴
- 처리 위치 기록 실제로 끝난 지점까지만 Kafka에 기록해, 재시작해도 빠지는 이벤트가 없게 함
- 도메인별 처리 이벤트 종류별 비즈니스 로직 실행. 워커마다 언어와 동시 처리 수를 따로 정함
포스트백, 밖으로 보내기
- 필터와 변환 채널별 조건으로 보낼지 결정. 템플릿으로 매체 형식에 맞춤
- 전송 작업 큐 변환과 외부 호출을 분리
- 외부 HTTP 호출 매체 API로 요청을 보내고 응답을 기록
- 응답 코드와 본문 기록 매체가 돌려준 응답을 Kafka에 남김. 성공과 실패 판정, 재시도 판단의 재료로 추정
- 연동 설정 API 매체별 포스트백 설정(커넥션)을 저장
- 매체 받은 전환으로 광고 학습과 정산
비용 등 매체 데이터 수집
- 수집 작업 조율 수집 일정과 완료 대기 관리
- 수집 작업 대기 수집 작업을 쌓아 두고, 실패한 작업은 다시 처리
- 수집 코드 매체 API 호출과 비즈니스 로직을 Airflow에서 떼어 Lambda에서 실행
- 변환과 저장 공통 형식으로 바꿔 성과와 합침(추정)
데모 앱으로 따라가 본 연동
데모 앱에서 메타 전환 API 연동을 처음부터 끝까지 따라가 봄.
설정은 바꾸지 않고 보기만 함.
여기까지는 Airbridge가 받은 데이터만 보임. 매체가 실제로 받았는지는 매체 화면에서 확인.
출처
- Airbridge Integrations
- Airbridge 헬프센터
- AB180 엔지니어링 블로그 (위 구조도의 글 4편. 설정 API는 「주니어 개발자의 시작: AB180에서 배운 엔지니어링 문화 (AB180 인턴 후기)」)