소개
작업 환경
실행 환경: Aside
LLM(두뇌): OpenAI Codex gpt-5.6-sol
작업 대상: 로그인된 쿠팡 Wing, 다운로드 파일, Excel, NAS
보조 에이전트: 사용하지 않음
쉽게 말하면, Aside가 로그인된 브라우저와 파일을 움직이는 손과 작업 환경이었다면, 무엇을 확인하고 어떤 순서로 수집·검증할지 판단한 두뇌는 OpenAI Codex의 gpt-5.6-sol이었습니다.
쿠팡 Wing의 로켓그로스 정산자료가 너무 복잡해서, 저는 브라우저 AI Aside에게 “로켓그로스 최종지급액 구조를 파악해 달라”는 원하는 결과만 요청했습니다.
다운로드할 파일, 조회 기간, 반복 횟수, 중복 기준, 계산식, 엑셀 시트 구성은 지정하지 않았어요.
그 뒤 Aside가 로그인된 Wing 화면과 네트워크 요청을 직접 확인하고, 리포트 생성·다운로드·중복 제거·계산 검증·엑셀 통합·원본 정리까지 필요한 과정을 스스로 설계해 실행했습니다.
결과가 기대 이상이라서, 그다음에는 2018년부터 쌓인 일반 Wing 정산 전체도 같은 방식으로 맡겼습니다.
이 글에서 가장 강조하고 싶은 부분은 내가 직접 입력한 프롬프트 한줄을 Aside가 결과물을 알아서 어디까지 만들어냈는가?입니다.
제가 한 일: 원하는 결과를 한 번 설명하고, Wing 로그인과 저장 위치만 결정했습니다.
Aside가 한 일: 화면과 요청 방식을 분석해 수집·중복 제거·검증·파일 생성의 전체 절차를 스스로 설계하고 실행했습니다.
이런 분들께 도움돼요
관리자 사이트에서 파일을 여러 개 내려받아 반복적으로 합치는 분
로그인 이후의 실제 웹 업무를 AI에게 맡기고 싶은 분
기존 자료 전체를 한 번 정리한 뒤, 다음부터 신규 데이터만 추가하고 싶은 분
Claude Code나 스크립트 자동화는 부담스럽지만 브라우저 업무는 줄이고 싶은 분
문제 상황
로켓그로스 정산현황에는 지급행이 나열되어 있지만, 최종지급액을 구성하는 상세 내용은 여러 리포트에 흩어져 있어요.
판매수수료
입출고·배송비
보관비
반품 회수·재입고비
반출비와 반출 배송비
재고 손실 보상
광고비
기타 부가서비스 비용
지급행도 70% 주정산과 30% 최종액정산으로 나뉘어요. 화면에서 보이는 지급행마다 리포트를 전부 내려받으 면 동일한 매출기간 자료가 중복될 수 있고, 비용은 월별 자료와 정산행을 다시 연결해야 했습니다.
제가 입력한 것은 이 한 번의 요청이 전부였습니다
아래 요청 한 번으로 시작했습니다.
지금 가장 시급한 건 쿠팡 로켓그로스 정산현황이야.
상세리포트에서 엑셀 다운로드 메뉴를 눌러보면 엄청 많은 리포트가 나오는데,
각각 다 열어봐야 전체 최종지급액의 구조를 알 수 있는 것 같아.여기까지가 제가 한 지시였습니다. 다운로드할 파일명, 조회 기간별 반복 방법, 합칠 열, 계산식, 중복 제거 기준, 결과 엑셀의 시트 구성은 따로 지시하지 않았습니다.
그 뒤는 Aside 가 알아서 진행했습니다
Aside는 제가 지시하지 않은 아래 작업을 실제 화면과 자료를 보며 스스로 정했습니다.
로그인된 Wing 화면과 네트워크 요청 구조 분석
27개 지급행에서 15개 고유 매출기간을 찾아 중복 수집 방지
비동기 리포트 생성 요청, 완료 대기, 파일 다운로드 반복
API와 엑셀 자료를 비교해 계산식과 검증 기준 결정
원본 ZIP, 10개 시트 누적관리 엑셀, 업데이트 방법 작성
로켓그로스 결과를 바탕으로 구·신규 화면의 8년치 일반 정산 429건까지 확장
고객 주문상세 개인정보를 제외하고 공개용 이미지의 금액 마스킹
사용한 도구
Aside: 로그인된 브라우저에서 화면 탐색, 요청 분석, 자료 수집, 검증, 파일 정리
쿠팡 Wing: 로켓그로스 및 일반 정산 원본
Excel: 정산현황, 상세자료, 월별 요약, 검증 결과를 누적관리
NAS: 원본자료, 누적관리 파일, 참고자료를 정산 유형별로 보관
Aside Vault: 비밀번호를 AI에게 노출하지 않고 Wing 로그인에 사용
Aside가 쿠팡 로켓그로스 정산 자료를 만든 과정
1. 로켓그로스 지급행과 상세리포트의 구조부터 분석
Aside는 Wing의 로켓그로스 정산현황과 다운로드 메뉴를 직접 확인했어요.
확인 결과 이번 기준자료에는 지급행이 27건 있었지만, 고유한 매출기간은 15개였습니다. 70%와 30% 지급행의 상세 판매 리포트가 동일했기 때문에, 지급행마다 무작정 파일을 받는 대신 고유 매출기간별로 한 번만 수집하는 방식으로 바꿨어요.
또한 최종지급액을 다음 구조로 정리했습니다.
최종지급액
= 지급액
- 추가상계
- CFS 최종비용
+ 재고 손실 보상단순히 화면의 합계만 옮긴 것이 아니라, 판매수수료 리포트와 정산 API의 매출액·수수료·할인·정산대상액이 일치하는지도 기간별로 검증했습니다.
2. 필요한 원본자료를 유형별로 모두 수집
로켓그로스 상세리포트는 생성 요청을 한 뒤 완료될 때까지 기다렸다가 다운로드해야 하는 비동기 방식이었어요. 여러 정산그룹을 한꺼번에 요청해도 실제 파일에는 첫 기간만 들어가는 경우가 있어, Aside가 고유 정산그룹별로 나눠 처리했습니다.
수집한 자료는 다음처럼 구분했어요.
정산현황 API 원문
기간별 판매수수료 리포트
광고비 월별 원본
비용 유형별 상세 리포트
재고 손실 보상 상세
리포트 형식 확인용 샘플
그리고 관리용 엑셀을 10개 시트로 구성했습니다.
대시보드
정산현황 누적
기간별 요약
판매파일 검증
판매상세 누적
광고비 월별
광고캠페인 상세
재고보상 상세
CFS비용 현황
업데이트 방법
금액은 공개용 화면에서 마스킹했습니다.
특히 마지막 업데이트방법 시트에는 다음 자료가 생겼을 때 무엇을 추가해야 하는지도 적었습니다. 한 번 쓰고 버리는 엑셀이 아니라 앞으로 계속 갱신할 기준 파일로 만든 거예요.
3. 예상보다 잘 돼서 일반 Wing 정산 전체로 확대
로켓그로스 결과물을 확인하고 나니, 일반 Wing 정산도 같은 방식으로 정리할 수 있겠다는 생각이 들었어요.
일반 정산은 로켓그로스보다 거래기간이 훨씬 깁니다.
2018년 자료부터 존재
구화면과 신규화면의 조회 방식이 다름
한 번에 최대 2개월만 조회 가능
신규·구화면 전환 구간이 일부 겹침
상세 엑셀 다운로드 목록에는 최근 30건만 표시
주정산 70%와 최종액정산 30% 외에 일부 과거 조정행 존재
Aside는 전체 기간을 2개월 단위로 나누고, 구화면과 신규화면의 결과를 각각 수집한 뒤 정산 고유키로 합쳤습니다. 전환 구간도 따로 비교해 누락과 중복을 막았어요.
최종적으로 2018-06-19부터 2026-09-29까지 지급행 429건이 하나의 일반 정산 누적관리 엑셀로 정리됐습니다.
검증식도 통일했습니다.
계산 최종지급액
= 지급액
- 총차감액
+ 기타지급조정429건 전체의 계산 결과와 Wing의 최종지급액 차이는 0건이었습니다. 실제 금액은 공개하지 않습니다.
4. 일반 정산과 로켓그로스를 억지로 합치지 않음
처음에는 “쿠팡 정산자료를 엑셀 하나로 정리한다”는 생각이었지만, 분석해 보니 일반 정산과 로켓그로스는 구조가 달랐어요.
그래서 서로 다른 계산 구조를 한 파일에 억지로 섞지 않고, 정산 유형별 기준 엑셀은 각각 하나씩 유지하기로 했습니다.
프로세스는 공유하지만 원본자료와 누적데이터는 분리한 구조예요.
각 정산 폴더는 다음 원칙으로 관리합니다.
누적관리/: 계 속 갱신할 기준 엑셀원본자료/: Wing에서 수집한 원본과 ZIP참고자료/: 정산구조 검증자료README.md: 중복 제거 기준과 다음 업데이트 방법
고객명과 주문상세 개인정보는 누적 엑셀과 원본 ZIP에서 제외했습니다. 정산 검증에 필요한 지급행과 합계 자료만 남겼어요.
Claude Code로 했다면 어땠을까
Claude Code로도 이 작업을 할 수 없다는 뜻은 아닙니다. 브라우저 자동화 도구와 스크립트 실행 환경을 연결하고, 다음 작업들을 단계적으로 설계한다면 가능했을 거예요.
Wing 로그인과 세션 처리
구화면·신규화면별 요청 분석
기간 분할과 반복 조회
비동기 리포트 생성 대기
다운로드 목록 관리
엑셀 파싱과 통합
중복 제거 키 설계
검증식 구현
원본과 결과 파일의 저장 규칙
하지만 이 과정에서는 제가 자동화 구조나 코드를 먼저 설계하지 않았어요. Aside가 이미 로그인된 브라우저 안에서 출발해, 화면과 네트워크 요청을 확인하고, 다운로드와 파일 작업까지 이어서 처리했습니다.
그래서 제가 느낀 차이는 다음과 같았습니다.
Claude Code는 자동화 시스템을 함께 만드는 개발 파트너에 가깝고, Aside는 브라우저에서 실제 업무를 넘겨받아 결과까지 만드는 작업 담당자에 가까웠습니다.
이번에는 “프롬프트 한 줄로 모든 것이 즉시 끝났다”기보다, 한 번의 결과 중심 요청에서 시작해 AI가 필요한 중간 단계를 스스로 찾아갔다는 표현이 더 정확합니다.
저는 로그인처럼 사람이 해야 하는 단계와 저장 위치 같은 업무 기준만 결정했습니다. 어떤 API를 쓰고, 몇 개씩 요청하고, 어떤 키로 중복을 제거할지는 Aside가 실제 자료를 보면서 정했습니다.
결과와 배운 점
확인된 결과
로켓그로스 지급행 27건, 고유 매출기간 15개를 누적관리 파일로 정리
로켓그로스 판매상세 392행을 비중복으로 통합
일반 정산 2018-06-19부터 2026-09-29까지 지급행 429건 통합
구화면·신규화면 전환 구간의 누락과 중복 확인
일반 정산 429건의 계산 검증차이 0건
로켓그로스와 일반 정산의 구조 차이를 반영해 별도 파일로 관리
원본자료 ZIP과 누적 엑셀의 무결성 확인
고객 주문상세 개인정보 제외
다음 업데이트부터 신규 고유키만 추가할 수 있는 기준 마련
가장 놀랐던 점
저는 처음에 로켓그로스 정산자료가 어떻게 구성되는지만 알고 싶었어요. 그런데 결과물에는 제가 나중에 필요하다고 생각할 만한 raw 데이터, 검증자료, 대시보드, 업데이트 절차까지 들어 있었습니다.
사람에게 업무를 맡겼을 때 “자료를 모아주세요”라고 하면, 어떤 형태로 정리할지 다시 설명해야 하는 경우가 많아요. Aside는 자료를 실제로 살펴본 뒤 제가 관리하기 좋은 형태를 제안하고, 파일 구조까지 만들었습니다.
시행착오
로켓그로스 리포트는 여러 정산그룹을 한꺼번에 요청해도 첫 기간만 들어오는 경우가 있어 기간별로 다시 요청해야 했어요.
70%와 30% 지급행을 모두 다운로드하면 같은 상세자료가 중복됐어요. 고유 매출기간 기준으로 한 번만 저장하도록 바꿨어요.
일반 정산은 구화면과 신규화면의 최종지급액 필드가 달라 화면별 기준을 따로 적용해야 했어요.
Wing 다운로드 목록에는 최근 30건만 보여서, 상세파일은 작은 배치로 생성하고 바로 내려받아야 했어요.
로그인 정보와 고객 개인정보는 AI 작업 편의보다 보안 원칙을 우선했습니다. 비밀번호는 사용자가 직접 입력했고, 주문상세 개인정보는 결과물에서 제외했어요.
꿀팁
AI에게 다운로드 방법을 하나씩 지시하기보다 원하는 최종 결과와 관리 목적을 먼저 말해보세요.
“이번 한 번만 정리”인지 “앞으로 누적관리”인지 처음부터 구분하세요.
원본자료, 누적파일, 참고자료의 저장 위치를 나누면 다음 업데이트가 쉬워져요.
중복 제거에 사용할 고유키와 계산 검증식을 결과물에 함께 남기세요.
공개 사례글에는 금액, 계정, 고객정보를 마스킹하고 과정과 구조를 보여주는 편이 좋아요.
앞으로의 계획
지금은 전체 과거자료를 기준 파일로 만든 상태예요.
앞으로는 Aside의 정기 작업이나 cron job으로 다음 흐름을 실행할 수 있을 것 같아요.
Wing에서 마지막 수집일 이후 지급행 조회
기존 정산 고유키와 비교
신규 지급행만 원본자료에 추가
누적관리 엑셀 갱신
계산 검증차이가 있으면 알림
신규 자료가 없으면 파일을 변경하지 않음
여러 거래처의 Wing 계정도 관리하고 있어서, 업무 프로세스는 공통으로 사용하되 계정·Vault·프로젝트·저장 폴더는 거래처별로 분리할 계획입니다.
도움이 필요한 부분
정산자료처럼 매번 새 데이터가 추가되는 업무는 어느 주기로 점검하는 것이 효율적일까요?
신규 정산행 추가뿐 아니라 기존 정산행의 금액이 나중에 수정되는 경우도 자동으로 탐지하는 좋은 방법이 있을까요?
브라우저 AI에게 장기간 운영 업무를 맡길 때 추가로 남겨야 할 검증 로그나 안전장치가 있다면 궁금합니다.
도움 받은 글 (옵션)
GPTERS 24기 에이전트하네스 학습 자료: 사례글 작성 가이드
Aside 공식 문서: https://docs.aside.com/
