광고 노출은 기록됐는데 SDK는 왜 실행되지 않았을까
내부 노출 기록과 실제 SDK 실행이 어긋난 제품을 조사했습니다. 후보를 소비하는 FE의 누락 분기를 찾아 실행과 결과 처리까지 연결했습니다.
다른 팀의 제품에서 광고 노출은 내부에 기록됐는데 공급사에는 SDK 실행 흔적이 없었습니다. 제가 추적한 질문은 하나였습니다. 서버의 광고 후보가 제품 FE의 실제 SDK 호출까지 도달했는가? 내부 tracker 호출은 이 질문의 답이 아니었습니다.
같은 후보를 받아도 같은 실행이 일어나지는 않았다
서버 응답의 광고 source·provider와 해당 제품 FE의 유형 분기를 순서대로 대조했습니다. 서버는 후보를 내려줬지만, 소비 FE에는 이 source를 처리할 handler가 없었습니다. 제품은 기본 fallback으로 내려갔고, 이 경로에서도 내부 노출 기록은 남을 수 있었습니다. 서버 응답 정상, 내부 기록 정상이라는 두 신호가 실제 광고 실행을 보증하지 않는 반례였습니다.
1월에 제가 만든 공용 광고 흐름은 후보 선택과 공급사 SDK 신호 해석을 분리했습니다. 그러나 공용 adapter가 존재해도 각 제품 FE의 후보 순회가 호출하지 않으면 실행되지 않습니다. 4월의 수정은 공용 구조를 다시 만드는 일이 아니라 소비 제품의 빠진 호출 경로를 완성하는 일이었습니다.
실행 가능한 입력부터 제품의 결과까지 연결했다
후보의 source·provider와 필수 SDK parameter를 확인한 뒤, 유효한 입력만 공급사 실행 함수로 보냈습니다. 입력이 중첩되거나 최상위에 놓인 두 형태도 구분했습니다. SDK 정보·provider·필수값이 잘못되면 실행 가능한 광고로 취급하지 않도록 테스트했습니다.
함수만 추가하고 후보 순회 분기를 그대로 두면 여전히 fallback이 선택됩니다. 그래서 후보 분기 → adapter 호출 → SDK callback·timeout → 제품의 완료 결과까지 연결했습니다. 공용 adapter가 돌려주는 상태와 이 제품이 읽는 boolean 결과는 동일한 의미가 아니어서 변환 경계를 명시했습니다. 공급사의 닫힘을 곧바로 광고 완료로 간주하지 않는 조건도 지켰습니다.
서버의 후보 → source·입력 확인 → 공급사 SDK 실행
→ 제품의 완료 결과 → 다음 후보 또는 참여
제품 소유 팀과 끝까지 확인했다
4월 17일 누락 경로와 검증 환경을 제품 소유 팀에 공유하고 로컬 진입과 전체 QA를 함께 확인했습니다. SDK가 실제 호출되는 것까지 확인했고, 21일에는 담당자들과 광고 및 기존 콘텐츠의 동작을 점검한 뒤 배포했습니다. 다른 팀 제품의 회귀 위험까지 제가 단독으로 보증하지 않고 소유 팀의 검증을 포함한 이유입니다.
확인된 결과는 누락된 handler 경유로 공급사 SDK가 실행되고 제품이 그 결과를 읽는 경로를 배포한 것입니다. 공급사 측 실제 노출 집계나 매출 회복량은 별도 확인이 필요합니다. 공용 기능을 만들었는지보다 소비 제품이 그 기능까지 도달해 어떤 결과로 처리하는지를 확인한 일이 이 사례의 핵심입니다.