증상부터 정확히 정의한다

"Purchase가 안 잡힌다"는 보고를 받으면 먼저 정확히 어느 지점에서 빠지는지 구분해야 합니다. 결제 페이지 진입(PageView)은 잡히는데 결제 완료 버튼을 누른 뒤 Purchase 이벤트만 안 잡히는 경우와, 결제 페이지 자체에 아무 이벤트도 안 잡히는 경우는 원인이 완전히 다릅니다. 전자는 베이스 코드는 정상이고 개별 이벤트 트리거 코드에 문제가 있는 경우이고, 후자는 결제 페이지 자체에서 픽셀 베이스 코드가 로드되지 않았거나 자바스크립트 에러로 페이지 전체 스크립트 실행이 중단된 경우입니다.

자바스크립트 에러가 뒤쪽 코드 실행을 막는 원리

브라우저는 자바스크립트 코드를 위에서 아래로 순서대로 실행하다가, 처리되지 않은 에러(uncaught error)를 만나면 그 스크립트 블록의 나머지 코드 실행을 멈춥니다. 결제완료 페이지에서 자사몰 자체 기능(쿠폰 적용 로직, 결제 수단별 UI 처리 등)을 담당하는 코드에서 에러가 나고, 그 코드 아래에 메타 Purchase 픽셀 호출 코드가 붙어 있다면, 위쪽 에러 때문에 Purchase 호출 자체가 아예 실행되지 못하고 건너뛰어집니다. 이 경우 픽셀 코드 자체는 문법적으로 아무 문제가 없는데도 결과적으로 이벤트가 누락되는 상황이 벌어집니다.

개발자 도구 콘솔에서 먼저 확인해야 하는 것

결제 완료 페이지를 열고 브라우저 개발자 도구(F12 또는 우클릭 > 검사)의 콘솔(Console) 탭을 확인하면, 빨간색으로 표시되는 에러 메시지와 함께 어느 파일의 몇 번째 줄에서 에러가 났는지가 함께 표시됩니다. 이 정보만으로도 문제가 픽셀 코드 자체의 문법 오류인지, 아니면 그 위에 있는 자사몰 자체 코드의 오류 때문에 연쇄적으로 실행이 막힌 것인지 상당 부분 구분할 수 있습니다. 코드를 수정하기 전에 이 단계를 건너뛰면, 픽셀 코드만 다시 심어봐도 근본 원인인 위쪽 에러가 그대로 남아 같은 문제가 재발합니다.

Pixel Helper로 재현할 때 흔히 하는 실수

Pixel Helper를 열어놓고 결제완료 페이지에 그냥 진입만 해보고 "Purchase가 안 뜬다"고 판단하는 경우가 있는데, Purchase처럼 버튼 클릭이나 결제 API 응답 시점에 맞춰 발동하도록 짜인 이벤트는 페이지에 진입한 것만으로는 절대 잡히지 않습니다. 실제 결제 프로세스를 끝까지 진행해(테스트 결제 환경이 있다면 그 환경에서) 버튼을 눌러본 뒤에 Pixel Helper 화면을 확인해야 정확한 진단이 됩니다. 이 차이를 모르고 "코드가 죽었다"고 잘못 판단해 멀쩡한 코드를 다시 심는 시간 낭비가 실무에서 자주 일어납니다.

코드 위치 재배치로 근본 원인을 없애는 법

가장 안정적인 해결책은 Purchase 픽셀 호출 코드를 자사몰 자체 로직과 최대한 분리하는 것입니다. 구체적으로는 결제완료 여부를 서버가 확실하게 응답하는 시점(결제 성공 API 콜백, 또는 결제완료 페이지 자체의 렌더링 완료 시점)에 픽셀 코드만 독립적으로 실행되도록 try-catch 구문으로 감싸는 방법이 실무에서 많이 쓰입니다. try-catch로 감싸두면 픽셀 호출 자체에서 예외가 나더라도 그 예외가 페이지의 다른 기능에 영향을 주지 않고, 반대로 다른 코드의 에러가 픽셀 호출을 막는 상황도 줄일 수 있습니다. 개발팀과 협업할 수 있는 환경이라면, 픽셀 호출 코드를 결제 로직과 완전히 분리된 별도 스크립트 블록으로 옮기는 것이 가장 근본적인 해결책입니다.

서버사이드 이벤트(CAPI)로 이중 안전장치를 두는 방법

브라우저 자바스크립트 에러에 취약한 클라이언트 사이드 픽셀만 의존하면 이런 문제가 반복될 수밖에 없습니다. 서버에서 결제 완료를 직접 감지해 전송하는 전환API(CAPI)를 함께 구축해두면, 프론트엔드 자바스크립트 에러와 무관하게 서버가 결제 완료를 인지한 시점에 이벤트를 전송할 수 있습니다. 픽셀과 CAPI 양쪽에서 같은 event_id를 써서 중복 제거를 설정해두면, 프론트엔드 코드가 죽더라도 서버 쪽 신호가 백업 역할을 해 Purchase 데이터 유실을 크게 줄일 수 있습니다.