공동구매 커머스 업무 자동화 에이전트

의뢰자는 SNS 인플루언서와 함께 공동구매를 운영하는 1인 사업자였고, 데이터베이스 없이 비슷한 인플루언서 찾기, 반응 좋았던 공구 상품 정리, 섭외 메시지 발송을 모두 수작업으로 해 왔습니다. 무엇을 자동화할 수 있는지 판단할 근거가 없는 상태였습니다.

SNS 쪽 제약도 컸습니다. 공식 API로는 먼저 연락하지 않은 상대에게 DM을 보낼 수 없고 비공식 자동화는 계정 정지 위험이 있어서, 무엇을 자동으로 하고 무엇을 사람이 해야 하는지 경계를 실측으로 정해야 했습니다.

• 통화 내용을 전사해 기능 세 가지(유사 인플루언서, 인기 상품, 섭외)와 판정 항목 Q1~Q8을 정하고, 데이터베이스를 쌓기 전에 PoC로 바로 확인하는 방향을 제안했습니다.
• 가상 데스크톱·브라우저·코딩 에이전트를 한 컨테이너 이미지에 넣고, 원격 화면으로 진행 상황을 볼 수 있는 격리 작업 VM을 만들었습니다.
• SNS 접근은 읽기 전용 가드를 거치게 하고 시간당 요청 수와 요청 간격을 코드로 강제했으며, DM은 문구 준비와 보내기 직전 단계까지만 자동으로 두었습니다.
• 작업 큐·엔진 어댑터·진행 스트림·피드백 저장을 갖춘 러너 API와 웹 창구를 만들고, 👍👎 피드백이 다음 실행 프롬프트에 그대로 들어가게 했습니다.
• 결과를 만든 세션과 분리된 판정 에이전트가 채점하게 해 자기 평가를 배제했고, 두 코딩 에이전트 엔진을 같은 과제로 비교했습니다.

• 유사 인플루언서 15명을 5분 22초에 찾았고, 분리된 판정 에이전트의 화면 채점은 ○12·△3·×0이었습니다. 경계에 있는 3명을 엄격히 내리면 합격선에 1명 모자란다는 점도 보고서에 그대로 적었습니다.
• 인기 공구 게시물은 원본 대조 31/31 정확, 조사 범위(18계정) 안 재현율 31/36이었습니다.
• 엔진 비교에서 한 엔진이 같은 과제를 6분 35초 대 16분 45초, 입력 토큰 1:9.2로 처리해 주력 엔진을 정했습니다.
• Q1~Q7은 합격선을 넘었고, 공수 추정(Q8)은 실측이 아닌 추정이라 △로 판정했습니다. 결과는 79초 데모 영상과 보고서로 정리했습니다.

SNS 자동화에서는 기술적으로 가능한 것보다 계정이 다치지 않는 범위가 먼저였습니다. 읽기 전용, 속도 제한, DM 반자동을 프롬프트 지시가 아니라 코드 가드로 묶어 두었기 때문에 에이전트에게 자율을 줄 수 있었습니다.

또 PoC 판정을 만든 세션 밖에서 받는 구조가 중요했습니다. 판정자를 분리하자 합격선에 아슬아슬하게 걸친 항목이 드러났고, 그 여유의 크기까지 보고에 담을 수 있었습니다.