포스트백 연동 오류 트러블슈팅(1): 데이터가 유실되거나 중복 집계되는 '서버 응답 오류(HTTP Status 500/400)' 현상 원인 규명 및 매칭율 개선

포스트백·전환 API 연동에서 HTTP 400 응답은 파라미터 오류(필수값 누락, 형식 오류, 해싱 오류 등)를 의미하며 응답 본문에 구체적 원인이 담깁니다. HTTP 500은 드물지만 플랫폼(수신 서버) 측 문제를 의미합니다. 이 두 오류는 원인의 소재 자체가 다르므로, 400이 반복된다면 광고주 쪽 요청 구성을 먼저 의심해야 하고 500이 반복된다면 매체 상태 페이지나 공식 채널을 통해 장애 여부부터 확인해야 합니다.

서버 응답을 로그로 남겨두면 사후에도 원인 진단이 가능합니다. 포스트백 요청이 실패해도 자사 쇼핑몰의 주문 처리 자체는 정상적으로 이어지기 때문에, 로그가 없으면 어떤 주문의 포스트백이 실패했는지, 실패 이유가 무엇이었는지 나중에 재구성할 방법이 없습니다. 최소한 요청 시각, 대상 URL, 응답 코드, 응답 본문을 함께 저장해두는 로깅 체계를 포스트백 발송 로직에 처음부터 포함시켜야 합니다.

프로덕션 배포 전 페이로드 검증 도구(예: 메타 전환 API 페이로드 헬퍼)를 활용하면 실제 이벤트를 전송하지 않고도 필수 파라미터·형식·해싱 여부 등 흔한 실수를 사전에 점검할 수 있습니다. 이런 도구를 거치지 않고 바로 운영 환경에 배포하면, 오류가 실사용자 트래픽에서 발생한 뒤에야 발견되는 경우가 많아 그 사이에 발생한 전환 데이터를 되돌릴 수 없이 잃게 됩니다.

픽셀(클라이언트사이드)과 전환 API·포스트백(서버사이드)을 동시에 운영할 때는 동일한 event_id(주문번호 등 고유값)를 양쪽에 동일하게 실어 보내야 플랫폼이 두 이벤트를 하나로 중복제거합니다. event_id를 양쪽에서 다르게 생성하면 중복제거가 실패해 전환이 두 배로 집계됩니다. 2026년 기준으로는 픽셀과 서버사이드를 병행하면서 event_id 기반 중복제거를 설정하는 것이 표준 구성이며, 이를 통해 손실됐던 전환 데이터의 20~30%를 복구하고 귀인 정확도를 개선할 수 있습니다.

event_id로 쓸 값은 주문번호처럼 시스템 전체에서 유일하고 재사용되지 않는 값이어야 합니다. 타임스탬프만으로 만든 값이나 세션 ID처럼 재사용 가능성이 있는 값을 쓰면, 서로 다른 두 전환이 우연히 같은 event_id를 갖게 돼 정상적인 전환 하나가 중복으로 오인돼 누락 처리될 위험이 있습니다. 프론트엔드 스크립트와 백엔드 서버 양쪽에서 이 값을 동일하게 생성·전달하는 로직을 한 곳(예: 주문 생성 API 응답)에서 관리하는 것이 안전합니다.

400·500 오류를 로그로 잡아내고 event_id 중복제거까지 갖췄다면, 그다음은 실패율이 높은 특정 파라미터나 특정 시간대를 좁혀가며 원인을 좁히는 단계입니다. 예를 들어 특정 결제수단에서만 400 오류가 몰린다면 그 결제수단의 콜백 데이터에 필수 파라미터가 누락되고 있을 가능성이 크고, 특정 시간대에만 500 오류가 몰린다면 매체 측 정기 점검 시간과 겹치는지부터 확인해야 합니다. 이렇게 좁혀진 원인은 다음 강의에서 다루는 타임스탬프 불일치 문제와도 종종 겹쳐서 나타납니다.

500 오류가 반복되면 매체 측 일시적 장애일 가능성이 있으므로, 포스트백 발송 로직에는 즉시 실패 처리하는 대신 짧은 간격을 두고 몇 차례 재전송을 시도하는 재시도 로직을 갖추는 것이 권장됩니다. 다만 400 오류는 요청 자체의 구조적 문제이므로 재시도해도 같은 오류가 반복될 뿐이라, 재시도 로직은 500 오류에 한정해 적용하고 400 오류는 별도로 알림을 보내 사람이 직접 파라미터를 점검하도록 분리해야 합니다. 이 구분 없이 모든 오류에 무조건 재시도를 걸면 오류 로그만 불필요하게 쌓이고 실제 원인 파악은 오히려 늦어집니다.

포스트백 실패율이 평소 대비 눈에 띄게 올라가는 시점을 자동으로 감지해 담당자에게 알림을 보내는 체계가 없으면, 매체 대시보드의 전환수가 이상하게 줄어든 것을 뒤늦게 사람이 눈으로 발견할 때까지 오류가 방치됩니다. 실패율 임계치를 정해두고 이를 넘기면 슬랙이나 메일로 즉시 알림이 가도록 구성해두면, 6강에서 다루는 픽셀 헬퍼 같은 수동 점검 도구에 의존하지 않고도 오류를 초기에 잡아낼 수 있습니다.

400 오류는 파라미터 구성 문제라 개발팀이, 500 오류는 매체 측 이슈일 가능성이 커서 마케터가 매체 담당자에게 문의하는 쪽이 대응이 빠릅니다. 오류가 발생했을 때 누가 어떤 유형을 맡을지 미리 정해두지 않으면, 로그를 확인하고도 "이건 누구 소관인지" 논의하는 데 시간을 쓰다 정작 데이터 유실 기간만 길어지는 경우가 흔합니다. 이 담당 구분을 11강에서 다루는 주간 점검 체크리스트에 함께 명시해두면 오류 대응 시간을 크게 줄일 수 있습니다.