직원 두 명을 AI로 고용하기, 3편 – AI 운영 에이전트의 하루 자동 루틴 설계
0. 2편 복습과 3편에서 할 이야기
2편에서는 첫 번째 직원, GPT 리서처 봇을 위한 프롬프트를 설계해서, 매번 같은 구조의 CSV를 뽑아내는 단계까지 만들었습니다.
이 CSV에는 최소한 상품명, URL이 들어 있고, 필요하다면 가격, 평점, 리뷰수 같은 정보도 함께 들어가도록 확장했습니다.
이제 3편에서는 두 번째 직원, AI 운영 에이전트의 업무를 설계합니다. 목표는 단순합니다.
“매일 새벽 05:00에, 어제까지의 데이터를 기준으로 상품을 자동으로 지우고, 추가하고, 갱신하는 루틴을 짠다.”
여기서 중요한 건 에이전트의 “똑똑함”이 아니라, 무엇을 언제 어떻게 할지를 사람 기준으로 먼저 정의하는 것입니다.
1. AI 운영 에이전트의 역할 정의
먼저 두 번째 직원의 직무부터 다시 정리합니다. 이 에이전트의 한 줄 정의는 다음과 같습니다.
“매일 정해진 시간에, 소싱 후보와 판매 데이터를 보고 안 팔리는 상품은 정리하고, 새 상품은 올리고, 정보는 최신으로 맞추는 운영 담당자.”
조금 더 쪼개면, 역할은 세 가지입니다.
- 루틴 1: 상품 소싱 – GPT 봇이 만든 URL 리스트에서 새로운 상품을 가져오기
- 루틴 2: 상품 정리 – 안 팔리는 상품 자동 삭제/중단
- 루틴 3: 상품 등록·갱신 – 국내 마켓에 자동으로 올리고, 가격·재고 정보를 최신 상태로 맞추기
실제 개발 구현은 시스템마다 다르겠지만, 이 세 가지 역할을 “사람이 한다면 어떤 순서로 무엇을 보면서 할지” 기준으로 설계해 두면, 나중에 개발자에게 업무를 넘기기도 훨씬 수월합니다.
2. 하루 루틴 전체 그림: 05:00에 한 번 도는 시나리오
운영 에이전트의 하루는 “언제 돌릴 것인가?”에서 시작합니다. 이 글에서는 이해를 돕기 위해 매일 새벽 05:00에 한 번 도는 시나리오로 설명하겠습니다.
큰 흐름은 아래와 같습니다.
- 05:00 – 어제 기준 데이터 불러오기
- 05:05 – 안 팔리는 상품 필터링 및 삭제/중단
- 05:15 – GPT 봇이 만든 CSV에서 신규 상품 읽기
- 05:25 – 상품 정보 수집·번역·정제
- 05:35 – 마진율·수수료 규칙을 적용해 가격 계산
- 05:45 – 국내 마켓별 규칙에 맞춰 자동 등록 또는 정보 갱신
- 05:55 – 예외(에러, 정책 위반, 품절 등) 로그 정리 및 요약 리포트 작성
이 루틴을 한 번 잘 만들어 두면, 에이전트는 매일 같은 패턴으로 움직이고, 사람은 그 결과를 요약된 로그만 보고 필요한 곳에만 손을 대면 됩니다.
3. 루틴 1 – 상품 소싱: 신규 상품 가져오기
첫 번째 루틴은 “새 물건 들여오기”입니다. 여기서 에이전트는 GPT 리서처 봇이 만든 CSV 파일을 읽어서, 오늘 새로 올릴 후보 상품을 결정합니다.
3-1. 입력 파일 구조 정의
예를 들어, 우리는 2편에서 이런 헤더를 가진 CSV를 만들었습니다.
- 최소형:
상품명,URL - 확장형:
상품명,URL,가격,평점,리뷰수
에이전트 입장에서는 이 파일을 “오늘 참고할 소싱 후보 리스트”로 바라봅니다. 실제 구현에서는:
- 파일 경로(예:
/data/gpt_sourcing/2026-04-10.csv) 규칙을 정하거나 - 항상 같은 이름(예:
latest_sourcing.csv)으로 덮어쓰게 해 두고 - 에이전트가 이 파일을 읽어 각 행을 하나의 “후보 상품”으로 처리합니다.
3-2. 소싱 루틴의 단계
소싱 루틴은 대략 아래와 같이 나눌 수 있습니다.
- CSV 파일 읽기
- 각 행(상품명+URL)에 대해
- 이미 우리 DB/시트에 등록된 상품인지 확인
- 이미 등록된 상품이면 “중복 후보”로 표시하고 건너뛰기
- 신규인 경우에만 “소싱 대상”으로 목록에 추가
- 오늘 처리할 최대 신규 상품 수를 제한 (예: 하루 50개까지만)
이렇게 해서, GPT 봇이 가져온 수십~수백 개 후보 중에서 “오늘 실제로 자동 등록까지 진행할 대상”만 추립니다.
4. 루틴 2 – 안 팔리는 상품 자동 삭제/중단
두 번째 루틴은 “쌓아두기만 하는 재고를 정리하는 일”입니다. 사람이 직접 한다면, 대충 이런 기준으로 볼 것입니다.
- 최근 30일 동안
- 판매 0건
- 상세페이지 조회(유입) 거의 0
- 경쟁 상품 대비 가격이 이미 충분히 낮은데도 반응이 없다
- 재고·배송 리스크가 큰 상품
이걸 에이전트 관점에서 룰로 바꾸면 다음과 같습니다.
4-1. 안 팔리는 상품 기준 정하기
예시 기준:
- 최근 30일 판매량 = 0
- 최근 30일 클릭 수(또는 상세페이지 유입) < 10
- 등록된 지 45일 이상 지남
- 가격/마진 조정 시도(예: 1~2회) 후에도 변화 없음
이 네 가지를 모두 만족하는 상품을 “정리 대상”으로 표시합니다. (이 기준은 각자 사업 구조에 맞게 바뀔 수 있습니다.)
4-2. 삭제 vs 중단 전략
완전 삭제가 불안하다면, 단계별로 나눌 수 있습니다.
- 1단계: “전시 중단” – 마켓에서는 안 보이게 하지만, 내부 데이터에는 남겨둠
- 2단계: “완전 삭제” – 일정 기간(예: 90일) 더 지켜봤는데도 반응이 없다면 완전 삭제
에이전트 루틴에서는:
- 기준에 맞는 상품 리스트를 뽑고
- “이번 회차에서 중단/삭제할 상품 수”를 제한(예: 최대 100개)한 뒤
- 각 마켓 API로 상태를 변경합니다.
그리고 이 내용을 “오늘 정리된 상품 리스트”로 로그에 남겨, 사람이 나중에 한 번에 확인할 수 있게 합니다.
5. 루틴 3 – 국내 마켓 자동 업로드·정보 갱신
세 번째 루틴은 “올릴 것 올리고, 고칠 것 고치는 일”입니다. 여기서 에이전트가 하는 핵심은 세 가지입니다.
- 상품 정보 크롤링·번역·정제
- 마진율·수수료를 반영한 가격 계산
- 마켓별 필수 옵션에 맞는 업로드/갱신
5-1. 상품 정보 크롤링·번역·정제
소싱 대상 URL이 정해졌다면, 에이전트는 각 URL에서 필요한 정보를 수집합니다.
- 상품명(영문)
- 상세 설명
- 스펙(사이즈, 색상, 소재, 전압 등)
- 이미지 URL들
- 원화/달러 가격, 배송비
- 판매자 정보(브랜드, 셀러 등)
그다음 해야 할 일:
- 국내 고객 기준으로 보기 좋게 상품명·설명을 번역/요약
- 마켓 정책에 맞지 않는 표현(과장, 금지 키워드 등) 제거
- 카테고리 매핑(아마존 카테고리 → 쿠팡/스마트스토어 카테고리 등)
여기서 GPT를 다시 활용해 “번역/요약/카테고리 추천”을 하게 할 수도 있고, 에이전트가 별도의 룰·테이블을 참고하도록 설계할 수도 있습니다.
5-2. 마진율·수수료 반영한 가격 계산
가격 계산은 에이전트에게 넘기는 가장 중요한 설정 값입니다. 예를 들어:
- 목표 순이익률: 30%
- 마켓 수수료: 12%
- PG/결제 수수료: 3%
- 기타 비용(광고, 운영비 등): 5% 정도 레벨
- 환율: 1달러 = 1,350원 (일 단위로 업데이트)
에이전트는 이런 값을 입력으로 받아, 아마존 상품 원가·배송비·관부가세를 고려한 후 판매가를 계산합니다.
계산 공식을 글에서 자세히 쓰기보다는, 대략 이런 느낌의 흐름으로 정리하면 됩니다.
- 원가(상품+해외배송) × 환율 = 기준 원가(원화)
- 기준 원가에 관부가세/수수료를 더해 “총 비용” 계산
- 총 비용을 기준으로 목표 마진율이 나오도록 판매가 역산
- 마켓 가격 정책(990원, 9,900원 단위 등)에 맞게 반올림
이렇게 계산된 판매가는, 에이전트가 나중에 “가격 조정 루틴”에서도 재사용할 수 있습니다.
5-3. 마켓별 필수 옵션 맞춰 업로드
각 국내 마켓은 요구하는 필수 정보가 조금씩 다릅니다. 예를 들어:
- 공통: 상품명, 카테고리, 이미지, 가격, 재고, 배송비, 옵션(색상/사이즈)
- 마켓별:
- 배송형태(해외직배송/국내발송),
- 배송비 정책(무료/조건부 무료/고정),
- 관부가세 안내 문구,
- 전기·전자 제품의 KC 관련 필드 등
에이전트 설계 시에는 “마켓별 설정 값”을 별도의 설정 파일이나 테이블로 정리해 두는 편이 좋습니다.
예를 들면:
margin_target = 0.3exclude_keywords = ["성인", "주류", ...]for_market_A: category_mapping, shipping_type, shipping_fee_policyfor_market_B: ...
이렇게 정리해 두면, 에이전트는:
- 상품 정보 + 가격 계산 결과를 바탕으로
- 각 마켓 API 규격에 맞게 요청을 조립한 뒤
- 자동으로 신규 등록 또는 기존 상품 갱신을 실행합니다.
6. 에러·예외 처리 전략
자동화에서 가장 중요한 건 “잘 될 때”가 아니라 “안 될 때”입니다. 운영 에이전트에게 반드시 알려줘야 할 예외 처리 규칙은 대략 다음과 같습니다.
6-1. 잘못된 URL
- HTTP 오류(404, 500 등)가 나거나,
- 리다이렉트가 이상하게 걸리는 URL,
- 로그인/성인인증/차단 페이지로만 가는 URL
→ 이런 경우에는:
- “소싱 실패”로 표시하고
- 해당 행을 건너뛰며
- 로그에
실패 사유: 잘못된 URL 또는 접근 불가를 남깁니다.
6-2. 품절 상품
- 아마존 쪽에서 품절 또는 “일시 재고 없음” 상태인 상품
→ 신규 등록 단계에서는 제외 → 이미 국내에 등록되어 있는 상품이라면:
- 전시 중단 또는 “품절 처리” 상태로 전환
- 로그에
품절에 따른 자동 중단기록
6-3. 정책 위반 키워드/카테고리
- 금지 키워드(성인, 의료, 위험물 등)가 상품명·설명에 포함되어 있거나
- 마켓에서 허용하지 않는 카테고리인 경우
→ 자동 등록/갱신을 막고, “사람 검수 필요” 상태로 별도 리스트에 올립니다. 이 리스트는 사람이 직접 확인해서 “정말 버릴지, 수정해서 살릴지” 판단합니다.
6-4. API 에러·쿼터 초과
마켓 API 호출 중 에러가 발생하면:
- 재시도 횟수(예: 최대 3회)를 정해 두고
- 그래도 실패하면 해당 상품만 “실패”로 표시
- 실패 내역을 로그에 남긴 뒤, 전체 루틴은 계속 진행합니다.
결론적으로, 에이전트는 “문제 있는 상품만 따로 모아서 사람에게 넘기는 역할”까지 해줘야 합니다. 그래야 사람이 매일 로그만 한 번 훑어봐도 전체 상태를 파악할 수 있습니다.
7. 최소 관리 포인트: 사람이 보는 건 딱 두 가지
이제 자동화가 잘 돌아간다면, 사람은 무엇을 해야 할까요? 이상적인 그림에서 사람의 역할은 “모니터링과 예외 처리” 두 가지뿐입니다.
7-1. 매일 아침 확인할 요약 리포트
에이전트가 매일 새벽 루틴을 돌고 나면, 대략 이런 형식의 요약 리포트를 남길 수 있습니다.
- 오늘 신규 등록 상품: 37개
- 오늘 전시 중단/삭제 상품: 22개
- 가격/정보 갱신된 상품: 58개
- 소싱 실패(잘못된 URL/접근 불가): 5개
- 정책 위반 의심 상품(사람 검수 필요): 3개
사람은 아침에 이 리포트만 보고:
- “오늘 자동화가 정상적으로 돌았는지”
- “내가 직접 봐야 할 상품은 몇 개인지”
를 한눈에 파악하면 됩니다.
7-2. 주기적인 로그 점검
일 단위로는 요약 리포트만 보고, 주 1회 또는 월 1회 정도는 좀 더 긴 로그를 점검하는 것도 좋습니다.
- 최근 30일 간
- 신규 등록 수
- 자동 삭제/중단 수
- 정책 위반/실패 건수
- 품목/카테고리별 성과(소싱→등록→판매까지 걸리는 시간 등)
이런 데이터를 보고 룰을 조금씩 조정하는 것이, “사람 직원 2명이 점점 더 일을 잘하게 만드는 과정”과 비슷합니다.
8. 정리: 한 명은 매일 후보를 모으고, 한 명은 매일 관리·등록을 돈다
여기까지 정리하면, 우리가 만든 구조는 이렇게 요약할 수 있습니다.
- GPT 리서처 봇
- 매번 같은 구조의 CSV로 “소싱 후보 리스트”를 만든다.
- 사람 대신 아마존에서 조건에 맞는 상품을 찾아오는 리서처 역할.
- AI 운영 에이전트
- 매일 새벽 05:00에 자동으로 루틴을 돌린다.
- 전날 데이터 기준으로 안 팔리는 상품을 정리한다.
- GPT 봇이 만든 CSV에서 신규 상품을 가져와 정보 수집·정제·가격 계산을 하고, 국내 마켓에 등록·갱신한다.
- 잘못된 URL, 품절, 정책 위반 같은 예외를 잡아서 사람에게 로그로 보고한다.
사람이 하는 일은 점점 줄어듭니다.
- 일일 단위: 요약 리포트 확인 + 예외 몇 건 처리
- 주간/월간 단위: 룰과 설정 값(마진율, 제외 키워드, 마켓 옵션)을 조정
이 정도면 “사람 직원 두 명이 하던 반복 작업” 상당 부분을 AI 두 명에게 넘긴 셈입니다.
이제 남은 건, 이 구조를 실제 본인 시스템에 맞춰 얼마나 라이트하게 혹은 빡세게 구현할지를 결정하는 일입니다.
다음 단계로, “완전 자동으로 가기 전에 최소 셋업(반자동)부터 시작하는 현실적인 도입 단계”
처음으로
