매체별 정산서 양식 차이

광고 정산 업무를 자동화하려는 순간 처음 부딪히는 벽은 로직이 아니라 파일입니다. 네이버, 카카오, 구글이 내려 주는 정산 데이터는 모두 "엑셀"이지만 그 안의 구조는 서로 다른 세계입니다. 미디어렙의 정산 자동화 시스템을 만들며 매체 3사의 파일을 하나의 파이프라인으로 읽어냈는데, 그 과정에서 확인한 정산서 양식의 차이와 파서 설계 대응을 정리합니다.

정산서 양식 차이의 핵심: 계정을 어디서 찾는가

정산 자동화의 첫 질문은 "이 행이 누구의 지출인가"입니다. 답은 계정 식별자에 있는데, 이 식별자의 위치와 형태가 매체마다 다릅니다.

네이버와 카카오는 컬럼 위치가 안정적이라 "몇 번째 컬럼" 방식이 통합니다. 반면 구글 파일은 상단에 요약 블록이 있고 그 아래 어딘가에 헤더 행이 나타나는 구조라 행 번호를 못 박는 순간 깨집니다. 우리 파서는 구글 파일에서 "계정 ID" 같은 헤더 텍스트를 상단 수십 행 안에서 탐색해 헤더 위치를 동적으로 확정합니다.

함정 1: 데이터처럼 생긴 잡행

정산 파일에는 데이터가 아닌 행이 섞여 있습니다. 합계 행, 소계 행, 빈 구분 행입니다. 이 행들을 데이터로 읽으면 집계가 두 배로 부풀거나 파싱이 깨집니다.

구글 파일이 특히 그랬습니다. 우리는 "데이터 행"의 형태 조건(특정 컬럼이 비어 있고 다른 컬럼이 숫자인 패턴)을 정의해 조건에 맞는 행만 인정하는 휴리스틱으로 합계·잡행을 걸렀습니다. 중요한 것은 이 조건이 매체별 파서 안에 있다는 점입니다. 매체마다 잡행의 생김새가 다르므로 공통 로직으로 뭉치면 반드시 어느 한쪽에서 새거나 어긋납니다.

함정 2: 같은 계정, 다른 표기

계정 식별자는 매핑 테이블과 대조해야 하는데, 표기가 흔들립니다. 앞뒤 공백, 특수문자, 대소문자 차이로 같은 계정이 다른 문자열이 됩니다. 그래서 대조 전에 양쪽 모두 정규화(공백·특수문자 정리)를 거칩니다.

여기에도 매체별 예외가 있습니다. 구글은 계정 식별자가 한글 이름이라 영숫자 기준의 일반 정규화를 적용하면 오히려 식별자가 뭉개집니다. 구글 파서만 최소한의 정리(양끝 공백 제거)로 규칙을 달리했습니다. 정규화 규칙조차 매체 속성을 따라가야 한다는 것이 실무의 디테일입니다.

함정 3: 한 매체 안의 여러 상품

카카오는 광고 상품 계열별로 정산 파일이 나뉘어 네 종류의 파일이 내려옵니다. 다행히 네 파일이 공통 포맷을 써서 파서 하나에 상품 유형 파라미터를 주는 방식으로 처리했습니다. 파일 유형의 판별 자체는 파일명 패턴으로 자동화해 사용자가 업로드할 때 종류를 고르지 않게 했습니다.

판별 규칙은 파일명 패턴만으로 충분했습니다. 매체들이 내려 주는 파일명에 상품·매체 표식이 일정하게 들어 있어 업로드 화면에서 매체를 고르는 UI 자체를 없앨 수 있었습니다. 다만 패턴에 안 걸리는 파일은 미지정 유형으로 분류해 사람이 확인하게 남겼습니다.

이 구조가 주는 교훈은 분류 축의 발견입니다. "매체 3사"라고 생각하고 시작하면 파서 3개를 설계하게 되지만 실제 파일은 "양식 유형" 기준으로 나뉩니다. 카카오 4종은 한 양식이고 구글은 사실상 다른 종족입니다. 파서는 매체 수가 아니라 양식 수만큼 만드는 것이 맞습니다.

파서 계층이 있어야 나머지가 산다

이 모든 차이를 흡수하는 파서 계층 위에, 계정을 대행사로 보내는 라우팅과 시트 기입이 올라갑니다. 파서가 매체별 차이를 다 삼켜 주므로 뒷단은 "정규화된 계정 식별자와 금액"이라는 단일 형태만 다룹니다. 라우팅 설계는 계정 매핑 라우팅 설계에서, 시트 기입은 엑셀 템플릿 전기 자동화에서 이어집니다.

전체 시스템의 그림은 광고비 정산 자동화 사례에서 볼 수 있고 형식이 제각각인 엑셀을 읽는 일반적인 접근은 엑셀 자동 파싱과 헤더 자동 감지에서도 다룬 적이 있습니다.

자주 묻는 질문

매체 정산 파일이 바뀌면 자동화가 깨지지 않나요?

깨질 수 있지만 영향 범위가 설계에 달렸습니다. 매체별 지식을 파서 하나에 모아 두면 양식 변경 시 그 파서만 고치면 되고 헤더를 위치가 아닌 텍스트로 찾는 방식이면 소소한 변동은 수정 없이 흡수됩니다. 반대로 행·열 번호를 하드코딩한 자동화는 변경마다 전체 점검이 필요해집니다.

정산 파일의 합계 행은 왜 문제가 되나요?

데이터 행과 구분 없이 읽으면 합계가 이중으로 집계되기 때문입니다. 매체마다 합계·소계 행의 생김새가 달라 "데이터 행"의 형태 조건을 매체별로 정의해 걸러내야 합니다. 이 필터가 없으면 자동화 결과가 수작업보다 위험해집니다.

계정 번호가 분명 매핑에 있는데 매칭이 안 되는 이유는요?

대부분 표기 차이입니다. 앞뒤 공백, 특수문자, 숫자에 붙는 소수점 꼬리 때문에 눈으로는 같아 보여도 문자열은 다릅니다. 매칭 전에 양쪽을 같은 규칙으로 정규화하면 대부분 해결되며 한글 식별자처럼 정규화 규칙 자체가 달라야 하는 예외도 확인해야 합니다.

파서는 매체 수만큼 만들면 되나요?

매체 수가 아니라 양식 수 기준입니다. 한 매체가 여러 상품 파일을 공통 양식으로 내려 주면 파서 하나로 충분하고 반대로 한 매체 안에서 양식이 갈리면 파서를 나눠야 합니다. 실제 파일 샘플을 모아 양식의 분류 축부터 확인하는 것이 설계의 첫 단계입니다.