Airo 제작기 6화 — 매출 엑셀을 손으로 받아 올리던 일을 없애기까지, 내 PC에서 서버로 그리고 API로

5화까지 읽으셨다면 Airo가 매출과 원가를 한 화면에 모아 마진을 계산한다는 걸 아실 겁니다. 그런데 그 매출 숫자는 어디서 왔을까요? 처음엔 제가 판매처마다 엑셀을 내려받아 구글 드라이브 폴더에 넣고, 제 PC에서 도는 프로그램이 그 폴더를 읽어 올리는 방식이었습니다. 6화는 이 일을 없앤 이야기입니다. 6월 11일 «내 PC → 서버», 6월 27일 «엑셀 → API», 그리고 7월 초에 만난 함정까지입니다.

왜 내 PC에서만 도는 수집이 문제였나요?

결론부터 말하면, 제 PC가 꺼지면 회사 매출이 멈췄기 때문입니다.

2화에서 구글 드라이브를 연결해 «내 PC가 꺼져도» 볼 수 있게 했다고 썼습니다. 그런데 스마트스토어 자료를 읽어 정리하는 프로그램은 여전히 제 PC의 작업 스케줄러로 아침 7시에 돌고 있었습니다. 6월 11일 이전 계획서 첫머리에 문제를 두 줄로 적어 두었습니다.

• 웹 화면에서 «동기화» 버튼을 누를 수 없다(PC에서만 돌기 때문)
• 다른 사람에게 Airo를 쓰게 할 수 없다

쿠팡 자료는 이미 서버에서 돌고 있었으니, 스마트스토어만 옮기면 되는 일이었습니다. 다만 조건을 하나 달았습니다. 옮긴 뒤 숫자가 하나라도 달라지면 안 된다. 매출 숫자가 바뀌면 그동안 본 마진과 광고 판단이 전부 흔들리니까요.

서버로 옮길 때 숫자가 같은지 어떻게 확인했나요?

«옮기고, 다시 돌리고, 대조한다»가 전부였습니다.

1. PC 프로그램에만 있던 정리 규칙 4종(채널별 유입, 범용 통계, 쇼핑 행동, 원가 정리)을 서버 쪽 코드로 그대로 옮겼습니다.
2. 옮기기 전에 지금 장부를 통째로 찍어 두었습니다(전 사진).
3. 드라이브 폴더에 쌓인 1,400여 개 파일, 15만 줄이 넘는 자료를 서버 경로로 처음부터 다시 처리했습니다.
4. 다시 찍어서(후 사진) 둘을 비교했습니다.

그날 작업일지에 남은 결과입니다.

그리고 바로 끄지 않았습니다. PC 수집과 서버 수집을 6월 14일까지 같이 돌리고, 대조한 뒤에 PC 쪽을 끄기로 정했습니다. 같은 자료가 두 번 들어와도 한 줄로 합쳐지게 만들어 두었기 때문에 겹칠 걱정은 없었습니다. «바꾼 뒤에도 옛것을 한동안 같이 돌린다»는 이 습관은 뒤에서도 계속 씁니다.

옮기다가 무엇을 발견했나요?

이게 6월 11일의 진짜 수확이었습니다. 서버 쪽 자동 작업을 들여다보니 정해진 시각에 저절로 도는 서버 작업 4개가 전부 실패하고 있었습니다.

원인은 로그인 검사였습니다. Airo는 로그인하지 않은 사람이 들어오면 로그인 화면으로 돌려보냅니다. 그런데 정해진 시각에 서버가 스스로 부르는 자동 작업도 «로그인 안 한 손님»으로 보고 로그인 화면으로 돌려보내고 있었던 겁니다. 작업은 시작조차 못 하고 있었습니다. 스마트스토어 숫자가 그동안 멀쩡히 들어왔던 건 제 PC 쪽 프로그램이 따로 돌고 있었기 때문이고요.

같은 날 하나 더 나왔습니다. 이미 처리한 파일 목록을 불러올 때 1,000줄까지만 읽고 있었습니다. 목록은 이미 4,500줄이 넘었으니, 서버는 1,000번째 이후 파일을 «처음 보는 파일»로 알고 매번 다시 처리하려 했습니다. 둘 다 PC가 돌아가는 동안엔 드러나지 않던 문제였습니다.

그래서 이때부터 자동화를 하나 더 붙일 때마다 «원래 하던 쪽을 끄면 정말 혼자 도는가»를 따로 확인합니다. PC가 대신 일하는 동안엔 서버가 고장 나 있어도 화면 숫자는 멀쩡하니까요.

엑셀을 아예 없앨 수는 없었나요?

서버로 옮겨도 남는 일이 있었습니다. 엑셀을 내려받아 폴더에 넣는 건 여전히 사람 몫이었으니까요. 그래서 6월 27일, 판매처가 열어 둔 API(프로그램끼리 자료를 주고받는 창구)에서 주문을 직접 받아 오는 쪽으로 넘어갔습니다.

이 전환에서 가장 걱정한 건 5화의 원가 연결이었습니다. API로 받은 주문이 이미 만들어 둔 «옵션 → 상품 코드 → 원가» 연결에 그대로 붙지 않으면, 원가를 처음부터 다시 연결해야 합니다. 그래서 설계서 맨 위에 «성패의 핵심»이라고 적고 이것부터 확인했습니다.

다시 연결할 필요가 없다는 게 확인되자 그날 밤 일이 빨라졌습니다.

하룻밤에 무엇을 바꿨나요?

6월 27일 저녁부터 28일 0시까지 커밋 기록을 순서대로 보면 이렇습니다.

1. 그림자 수집(18:56): 기존 숫자는 건드리지 않고 API로 같은 기간 매출을 따로 받아 나란히 비교하는 화면부터 만들었습니다.
2. 쿠팡 기준 바꾸기(20:14): 쿠팡 매출을 «결제한 날» 기준으로 받도록 바꿔, 어제 판 것이 다음 날 바로 보이게 했습니다.
3. 매일 자동 수집(22:23): 판매처마다 시각을 나눠 매일 돌게 했습니다(스마트스토어 아침 8시 30분, 쿠팡 오후 1시 30분).
4. 옵션 단위 수집(22:50): 원가를 붙일 수 있게 옵션 단위로 받았습니다. 이때까지 화면 숫자는 그대로.
5. 화면 승격(23:00): 화면의 매출·마진 출처를 API로 바꿨습니다. 단, 스위치 하나로 즉시 되돌릴 수 있게 만들었습니다.
6. 환불·수수료(23:15~28일 0:00): 네이버 취소·반품, 네이버·쿠팡 수수료까지 API로 채웠습니다.

여기서도 원칙은 같았습니다. 날짜·판매처별로 API 자료가 있으면 API, 없으면 예전 업로드 자료를 쓰게 해서 지난 기록을 하나도 버리지 않았습니다. 원가 연결이 붙는 비율은 쿠팡 99.5%, 스마트스토어 95%였습니다.

API 숫자는 판매처 화면과 맞았나요?

사흘 뒤인 6월 30일에 맞춰 봤습니다. 스마트스토어 환불 금액을 네이버 판매성과 엑셀과 날짜별로 대조했더니 비교한 날 중 6일은 1원까지 같았습니다. 다른 3일은 전부 Airo 쪽이 더 컸는데, 원인은 «발송 전 취소»였습니다. Airo는 이것도 환불로 셌고, 네이버 판매성과는 빼고 있었습니다. 그래서 반품만 환불로 세도록 맞췄습니다.

같은 날 매출 차이도 하나 나왔습니다. 수집하는 기간이 10일뿐이라 지난달 앞쪽 날짜가 덜 들어와 있었습니다. 수동 수집 기간을 35일로 늘려 지난달 전체를 다시 받게 했습니다.

API로 바꾸고 나서 문제는 없었나요?

있었습니다. 그리고 이게 이 화에서 가장 따라 하실 만한 대목입니다.

7월 7일, 홈 화면의 «같은 요일 평균»이 이상하게 낮았습니다. 제가 «4주 평균이 너무 적다»고 했고, 클로드가 원인을 찾았습니다. 스마트스토어 주문 API는 «최근에 상태가 바뀐 주문»을 돌려줍니다. 그래서 2주 넘게 지난 주문도 반품·구매확정으로 상태가 바뀌면 몇 건씩 섞여 들어오는데, 저장할 때 이 몇 건짜리 합계가 이미 다 채워진 지난날 하루 매출을 덮어쓰고 있었습니다. 6월 16일 하루 매출이 199만 원에서 6,900원으로 바뀌어 있었을 정도입니다. 어제·오늘 숫자는 맞으니 한동안 아무도 몰랐던 겁니다.

그때 제가 한 말이 기록에 남아 있습니다.

「잘못된 데이터로 잘못된 판단은 큰일」

고친 방법은 세 가지였습니다.

1. 수집 창에 안전핀: 이번에 받아 오는 기간 안의 날짜만 저장하고, 그보다 지난 날짜는 마지막으로 다 채워진 값을 그대로 두게 했습니다.
2. 손상된 날 복구: 판매처 판매리포트보다 30% 넘게 적게 찍힌 날(스마트스토어 34일·쿠팡 3일, 모두 37건)을 리포트 값으로 바로잡았습니다(제가 승인).
3. 출처 순서 정하기: 스마트스토어는 판매리포트가 있는 날은 리포트를 먼저 쓰고, 리포트가 없는 오늘과 쿠팡은 API를 쓰게 했습니다.

화면에서 근사치로 보여 주던 «같은 요일 평균»은 «안 맞으면 없애고 정확할 때 다시» 띄우기로 했습니다. 엑셀을 «완전히» 없애겠다던 목표에서 한 발 물러난 셈이지만, 숫자가 맞는 쪽을 골랐습니다.

그래서 지금 손으로 받는 자료는 몇 개인가요?

7월 7일, 제가 클로드에게 «내가 손으로 다운로드 받는 것 전수 정리»를 시켰습니다. 자료마다 «API로 대체됐나?»를 따져 보니, 이미 API가 대신하고 있어서 제가 더는 안 받던 폴더 연결이 7개였습니다. 구매확정, 정산 내역, 광고 소재 보고서, 검색어, 키워드, 매체, 상품 성과입니다. 이 연결을 정리하고, 남는 자료는 판매처별 폴더 네 개로 다시 나눴습니다.

반대로 API가 없어서 남은 것도 분명히 적었습니다. 성별·나이 같은 고객 통계는 주문 API에 아예 없고, 11번가 광고 보고서는 11번가가 API를 열어 두지 않아 파일로만 받을 수 있습니다. «다 없앴다»보다 «무엇이 왜 남았는지 안다»가 더 쓸모 있었습니다.

이 시기에서 따라 할 만한 것은 무엇인가요?

1. 옮길 때는 전·후 사진을 찍으세요. 수집 방식을 바꾸기 전에 지금 숫자를 통째로 저장하고, 바꾼 뒤 같은 기간을 다시 돌려 비교하면 «달라졌나?»에 숫자로 답할 수 있습니다.
2. 옛 방식은 며칠 같이 돌리세요. 같은 자료가 두 번 들어와도 한 줄로 합쳐지게만 해 두면 겹칠 걱정 없이 병행할 수 있습니다.
3. 원래 하던 쪽을 꺼 보세요. PC가 대신 일하는 동안엔 서버 고장이 안 보입니다. 저는 자동 작업 4개가 전부 멈춰 있는 걸 이때 알았습니다.
4. API 숫자도 판매처 화면과 대조하세요. 특히 지난 날짜를 다시 받을 때 값이 줄어드는지 보세요. 어제 숫자가 맞는다고 지난달 숫자도 맞는 건 아닙니다.
5. 되돌리는 스위치를 먼저 만드세요. 새 출처로 바꾸는 날, 한 번에 옛 출처로 돌아가는 방법이 있으면 마음 놓고 바꿀 수 있습니다.

클로드에게 이런 일을 맡길 때 제가 가장 많이 한 말은 «바꿔 줘»가 아니라 «숫자 맞는지 봐 줘»였습니다. 자동화는 손을 덜어 주지만, 틀린 숫자를 자동으로 쌓기도 합니다.

다음 화 예고: 7화에서는 광고비를 숫자로 따지기 시작한 이야기를 씁니다. «클릭당 얼마»가 아니라 «실제로 산 사람» 기준으로 광고 효율을 다시 계산했더니 무엇이 보였는지(6~7월 기록)입니다.