$1.2B 밸류에이션 3개월, 우리 결제 로그는 왜 아직 쓰레기통인가

XDOF는 로봇을 만들지 않는다. 로봇이 물건을 집고, 놓고, 실패할 때 발생하는 데이터를 수집하고 구조화한다. 그것만으로 스텔스를 벗어난 지 석 달 만에 $1.2B(약 1.6조 원) 밸류에이션으로 시리즈 B 협상 테이블에 올랐다.

제품도, 로봇도 없이.

이게 결제·정산을 직접 굴리는 팀에게 불편한 이유는, 우리도 매일 정확히 같은 구조의 데이터를 생산하고 있기 때문이다. 그리고 대부분 그걸 90일 후 자동 삭제되는 운영 로그로 취급하기 때문이다.

단, 이걸 "데이터를 잘 관리해야 한다"는 교훈으로만 읽으면 핵심을 놓친다. XDOF가 진짜 보여준 건 구조화 타이밍의 경제학이다.

로봇 데이터의 본질 — 행동 로그의 구조화

XDOF가 파는 것의 본질은 이렇다. 로봇이 물건을 집을 때 손목 각도가 얼마였는지, 실패했을 때 어떤 센서 값이 어떤 순서로 변화했는지, 성공 패턴과 실패 패턴이 어떻게 다른지. 이 데이터를 라벨링하고 포맷을 통일하면 다른 AI·로봇 업체들이 학습에 쓸 수 있다.

핵심은 "수집"이 아니라 "구조화"다. 로봇 회사들은 이미 자체 센서 데이터를 어마어마하게 쌓고 있다. 그런데 AI 훈련에 실제로 쓸 수 있는 포맷으로 라벨링된 건 거의 없다. 그 간극을 XDOF가 채운다.

그리고 시장은 그 간극의 가치를 석 달 만에 $1.2B으로 평가했다. 이게 단순 투자 열기라기엔, 시리즈 B로 오기까지의 속도가 너무 비정상적으로 빠르다.

결제 로그는 이미 로봇 데이터다

우리 결제·정산 파이프라인도 매일 막대한 행동 데이터를 생산한다. 어떤 PG사에서 어떤 카드로 얼마짜리 결제가 들어왔는지, 실패했다면 에러 코드가 무엇이었는지, 정산 배치가 몇 시에 돌았고 몇 건이 매칭됐는지.

문제는 이걸 "문제 생겼을 때 뒤져보는 파일"로만 취급한다는 거다. 평소엔 어딘가에 쌓이다가 보존 정책 기간이 지나면 증발한다.

직접 겪어봤는데, 결제 실패 패턴 하나만 제대로 구조화해도 달라진다. 지난 분기에 특정 카드사의 에러 코드 51(한도 초과)이 저녁 9~11시 사이에 집중된다는 걸 뒤늦게 발견했다. 그 시간대에 결제 수단 변경 프롬프트를 먼저 띄웠더니 전환율이 올라갔다. 데이터는 원래부터 있었다. 볼 수 있는 구조가 없었을 뿐이다.

구체적 트레이드오프: 지금 10ms vs. 1년 후 수십 시간

결제 이벤트를 전부 저장하는 건 스토리지 관점에서 큰 문제가 아니다. 트랜잭션 한 건당 23KB라고 하면, 월 100만 건도 23GB 수준이다. 비용이 아니라 구조가 문제다.

원시 로그를 그냥 쌓으면, 나중에 "작년 3월에 특정 PG사 실패율이 갑자기 오른 이유"를 조사할 때 로그 파일을 grep으로 뒤지는 수밖에 없다. 그것도 그 시점 로그 포맷이 지금과 같다는 가정 하에. 포맷이 바뀌었다면? 재파싱이다.

XDOF의 밸류에이션이 말하는 건 이거다. 잘 구조화된 데이터는 그 자체로 자산이다. 규모가 작을수록 오히려 처음부터 구조를 잡는 게 유리하다. 수백만 건의 레거시 데이터를 나중에 재처리하는 비용이 훨씬 크니까.

트레이드오프를 수치로 보면: 이벤트 발생 시점에 10ms를 더 써서 구조화된 포맷으로 기록하는 것 vs. 1년 후 비정형 로그를 마이그레이션하는 엔지니어링 작업(현실적으로 수십 시간). 선택지가 명확하다.

우리 팀이라면 — 정산 데이터를 자산으로 만드는 실제 시나리오

XDOF식 접근을 정산 파이프라인에 적용하면 단계가 세 개다.

첫째, 이벤트 스키마를 고정한다. 결제 성공·실패·취소·환불·정산 완료 등 핵심 이벤트마다 동일한 구조의 JSON을 남긴다. 최소 필드: 이벤트 타입, 타임스탬프(KST+UTC 모두), PG사 코드, 에러 코드, 금액, 통화, 사용자 ID 해시. 기존 로그 파이프라인에 슬리브처럼 끼워 넣는 건 하루짜리 작업이다.

둘째, 이 이벤트를 분석 전용 테이블로 따로 흘린다. 프로덕션 DB에 직접 분석 쿼리를 날리면 부하가 걸리니까. MySQL 이벤트 테이블 하나에 INSERT IGNORE로 쌓는 것만으로도 보름치가 쌓이면 패턴이 보이기 시작한다.

여기서 Notion API를 활용하는 것도 현실적인 선택지다. 우리 팀은 정산 예외 케이스(금액 불일치, 누락 건)를 예전엔 슬랙 채널에 수동으로 기록했는데, Notion 데이터베이스로 옮기고 API로 자동 적재하니 월 단위 집계가 쿼리 한 줄로 됐다. 화려한 도구가 아니어도 구조만 잡히면 충분히 쓸만하다.

셋째가 결정적이다. 6개월치 구조화된 이벤트가 쌓이면 자동화 판단의 기준이 생긴다. "이 에러 코드가 N회 이상 연속으로 나오면 알림", "특정 PG사 실패율이 시간당 X%를 넘으면 서킷 브레이커" 같은 룰을 직관이 아니라 데이터로 설정할 수 있게 된다. 지금 직관으로 하는 운영 판단이 숫자 기반이 되는 시점이다.

지금 바로 쓸 수 있는 시사점

지금 당장 결제 이벤트 스키마를 문서화해라. 현재 로그에 어떤 필드가 있고, 없는 필드 중 꼭 있어야 할 게 뭔지. 이 작업 자체가 파이프라인의 맹점을 드러낸다. 문서화 과정에서 이미 뭔가 하나는 발견하게 된다.

정산 예외 케이스 로그를 슬랙 복붙에서 구조화 DB나 Notion 데이터베이스로 이동해라. 필드 5개짜리 테이블로 시작해도 된다. 3개월 치가 쌓이면 분기 보고가 자동화된다.

90일 로그 보존 정책을 재검토해라. XDOF는 과거 로봇 데이터일수록 희소성이 있다고 봤다. 결제 실패 패턴에도 계절성이 있다. 1년 전 같은 시기 데이터가 없으면 비교 기준 자체가 없다.

마지막으로, 이 작업을 "언젠가 할 일"로 미루는 건 사실 "영원히 안 할 일"과 같다. XDOF가 3개월 만에 $1.2B을 받은 건 남들이 정리하지 않은 데이터를 먼저 정리했기 때문이다. 선점 효과는 규모와 무관하다. 구조화를 시작하는 시점이 빠를수록, 나중에 자동화나 이상 감지 도구를 붙일 때 쓸 수 있는 기반이 그만큼 두터워진다.

원문: AI News & Artificial Intelligence | TechCrunch