AI에 앞선 데이터 기반: 두 분기 안에 투자를 회수하는 개선 과제

대부분의 AI 계획은 회사 데이터가 이미 준비되어 있고 남은 일은 모델 선택이라고 가정합니다. 업력이 있는 기업에서 데이터는 대개 올바른 시스템에 있지만 형태가 잘못되어 있습니다. 같은 고객이 세 가지 방식으로 등록되어 있고, 상품 코드가 온라인 스토어와 창고에서 서로 다른 의미를 가지며, 매출이 분석 도구의 속성과 원장 사이에서 다르게 나옵니다.

무엇을 고쳐야 하는지 가장 빨리 찾는 방법은 실제 기록을 따라가는 것입니다. 주문, 송장, 재고 이동의 표본을 뽑아, 온라인 스토어나 견적 도구에서 결제 대행사, CRM, 창고를 거쳐 회계 패키지와 리포팅 계층에 이르기까지 각 기록이 거치는 모든 시스템을 추적합니다. 기록을 손으로 다시 입력하는 곳, 스프레드시트로 복사하는 곳, 식별자가 바뀌는 곳, 기록이 사라지는 곳을 적어 둡니다. 그 지점들이 바로 개선 과제 목록입니다.

아래의 개선 과제는 두 분기 안에 투자를 회수할 것으로 보는 항목입니다. 모두 이미 비용을 발생시키고 있는 수작업이나 리포팅 오류를 없애며, 나중에 같은 기록을 읽게 될 모든 AI 기능의 전제 조건입니다.

모든 후속 활용은 데이터 결합에 달려 있습니다. 고객별 매출을 보려면 주문 시스템과 원장이 같은 고객 키를 공유해야 합니다. 상품별 마진을 보려면 온라인 스토어, 창고, 매입 원장이 상품 코드의 의미에 합의해야 합니다. 주문이나 상품에 관한 질문에 답하는 AI 어시스턴트는 키에 담긴 모호함을 그대로 물려받습니다.

점검은 빠르게 할 수 있습니다. 식별자마다 값이 채워져 있는지, 그리고 하나의 코드가 하나의 상품을 뜻하도록 전체 모집단에서 고유한지를 확인합니다. 이 둘은 별개의 테스트입니다. 상품 코드 필드가 모든 레코드에 채워져 있더라도 서로 다른 두 품목이 같은 코드를 쓸 수 있으며, 그것만으로 어시스턴트가 확신에 찬 어조로 엉뚱한 상품을 설명하거나, 거래 파트너에게 보낸 카탈로그가 올바른 코드 아래 잘못된 품목을 제시하게 됩니다.

투자 회수는 이 개선으로 사라지는 업무에서 나옵니다. 오배송에 따른 대변 전표, 고객 거래명세서 대사에 드는 시간, 두 시스템의 수치가 맞지 않아 매달 손으로 다시 만드는 보고서입니다.

Google Analytics 4 표준 속성은 사용자 수준 및 이벤트 수준 데이터를 기본 2개월, 최대 14개월까지 보관하며, 이벤트 데이터를 더 오래 보관하려면 유료 360 등급이 필요합니다. 표준 보고서는 집계 테이블로 돌아가기 때문에 과거 합계를 계속 보여 줍니다. 그래서 누군가 전년 대비 탐색 분석이나 퍼널을 만들다가 이전 기간이 비어 있는 것을 발견할 때까지 데이터 손실은 드러나지 않습니다. 보관 기간 설정을 늘려도 아직 삭제되지 않은 데이터만 보호됩니다.

지속 가능한 해결책은 BigQuery 내보내기로, 원시 이벤트를 회사가 소유한 데이터 웨어하우스로 복사합니다. 표준 속성은 일일 내보내기로 하루 최대 100만 건의 이벤트를 보낼 수 있습니다. 스트리밍 내보내기는 용량 제한이 없고 기가바이트당 $0.05가 드는데, Google은 1기가바이트를 이벤트 약 60만 건으로 봅니다. 이 요율이라면 중견기업의 저장 비용은 작년 행동 데이터 없이 성수기를 계획하는 데 따르는 비용에 비하면 미미합니다.

이 과제에는 기한이 내재되어 있습니다. 한 달을 미룰 때마다 복구할 수 없는 이벤트 이력이 한 달씩 사라지며, 2027년 계획 수립 주기에는 2026년 성수기 데이터 전체가 필요할 것입니다.

전자 송장은 고객 마스터 데이터를 규제 준수의 전제 조건으로 바꿉니다. 독일에서는 전년도 매출액이 €800,000를 넘은 기업이 2027년 1월 1일부터 국내 기업 간 송장을 구조화된 전자 형식으로 발행해야 하며, 그 밖의 모든 기업은 2028년 1월 1일부터 뒤따릅니다. 수신은 2025년 1월 1일부터 이미 의무입니다. 영국 정부는 2029년 4월부터 모든 VAT 송장을 전자 방식으로 발행해야 한다고 밝히고, 교환 네트워크로 Peppol을 확정했으며, 상세한 시행 로드맵은 10월 28일 예정인 2026년 예산안과 함께 내놓겠다고 했습니다.

투자를 회수하는 작업은 두 나라 모두 같으며, 기한보다 훨씬 앞서 시작됩니다. 고객 마스터의 고객 VAT 식별 번호, 세금 번호, 전자 수신 주소를 빠짐없이 채우고 검증합니다. 송장 행의 상품 코드와 세금 코드를 표준화합니다. 주문 시스템과 송장 사이의 수작업 단계를 없앱니다. 송장이 반려되면 현금 회수가 늦어지므로, 깨끗한 마스터 데이터는 규정을 충족할 뿐 아니라 회수 기간도 줄여 줍니다. 그리고 이번 분기에 독일 법인을 위해 만든 데이터 모델은 나중에 영국에서도 다시 쓸 수 있습니다.

마지막 과제는 시스템이라기보다 규율입니다. 경영 보고서는 매출을 온라인 스토어나 CRM에서, 비용을 원장에서, 마케팅 성과를 광고 플랫폼에서 가져오는데, 이 세 가지가 일치하는 경우는 드뭅니다. 이사회 보고 자료와 재무제표가 아무도 설명하지 못하는 금액만큼 차이가 나면 자료의 모든 수치가 신뢰를 잃고, 어느 숫자가 맞는지 논쟁하는 사이 의사결정이 늦어집니다.

월간 브리지가 이 문제를 정리합니다. 결산 후 경영 보고 패키지의 주요 수치를 하나씩 원장과 대사하고, 차이를 이름이 붙은 반복 항목으로 나눕니다. 시점 차이, 환불, 세금, 관계사 간 거래, 테스트 주문 등입니다. 브리지는 손으로 조립하지 않고 시스템에서 생성하며, 합의된 기준을 넘는 미설명 잔차는 패키지를 배포하기 전에 조사합니다. 반복 항목에 이름이 붙고 나면, 남는 것은 대개 아무도 문서화하지 않았던 몇 가지 프로세스입니다.

이는 모든 AI 리포팅 어시스턴트에 필요한 기반이기도 합니다. 특정 지역의 마진이 왜 떨어졌는지 묻는 질문에 모델이 정확히 답하려면, 모델이 읽는 수치가 이미 대사되어 있어야 합니다. 저희가 원장에서 바깥쪽으로 브리지를 구축하는 것은 모든 프로젝트를 주문, 원장, 로그에서 시작하는 것과 같은 이유에서입니다. 대시보드의 품질은 그 아래 기록의 품질을 넘지 못합니다.

2026년 11월에는 실제 주문, 송장, 재고 이동의 표본을 모든 시스템에 걸쳐 추적하고, 기록이 다시 입력되거나 복사되거나 새 식별자를 받는 지점을 모두 목록으로 만듭니다.

11월 말 이전에 모든 속성의 GA4 이벤트 보관 기간을 14개월로 설정하고 각 속성을 BigQuery에 연결해, 2026년 성수기 데이터를 온전히 보존합니다.

12월 말까지, 시스템 전반에서 고객, 상품, 주문 식별자의 고유성과 완전성을 점검하고, AI 기능이나 거래용 카탈로그가 의존하기 전에 중복 상품 코드를 정리합니다.

독일 법인이 있다면 2027년 1월 1일 이전에 €800,000 기준을 넘는지, 송장 발행과 고객 마스터 데이터가 준비되었는지 확인하고, 영국 로드맵이 발표되면 같은 데이터 모델로 영국 의무화에 대비합니다.

2027년 1월 결산부터는 이름이 붙은 대사 항목과 잔차 기준을 갖춘, 경영 보고 패키지에서 원장으로 이어지는 월간 브리지를 공개합니다.

2027년 6월까지, 대사를 마친 데이터를 바탕으로 첫 AI 활용 사례를 선정하고 같은 기록으로 기준선을 측정합니다.