메뉴 관리 자동화의 도전과 해결 전략

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

DevOps

대상자

*소프트웨어 개발자, 자동화 도구 사용자, 중소규모 레스토랑 운영자**

- 난이도: 중간 (API 통합 및 웹 자동화 기초 지식 필요)

- 핵심 관심사: 복잡한 웹 인터페이스 자동화, 데이터 추출/전송, DevOps 아키텍처 설계

핵심 요약

Runner H의 한계: 복잡한 UI 자동화(로그인, 폼 입력)와 Google Sheets 데이터 저장 시 불안정한 성능을 보임.
성공적인 대안: iFood에서의 데이터 추출과 Zapier를 통한 데이터 통합으로 하이브리드 아키텍처 구축.
핵심 도구:

- Runner H: Webhook을 통해 Zapier로 데이터 전송.

- Zapier: Google Sheets API 및 Webhook을 활용한 데이터 정합성 보장.

섹션별 세부 요약

1. 문제 정의: 다중 플랫폼 메뉴 관리의 복잡성

현재 문제점:

- Menu Legal, iFood, PDF 등 3개 플랫폼 간 메뉴 일관성 유지 필요.

- API 부재 또는 복잡성으로 인한 수작업 입력과 오류 발생.

목표: 자동화를 통해 시간 절약과 데이터 정확성 개선.

2. Runner H의 초기 활용 시도와 한계

Runner H의 기능:

- 자연어 기반 웹 자동화 (예: "Login to Menu Legal").

- UI 자동화 (폼 입력, 인터페이스 상호작용).

발생한 문제:

- 로그인 실패: Bing 검색 또는 잘못된 인증 정보 보고.

- 폼 입력 거부: "Termos de Serviço 위반"으로 인해 수동 PDF 생성.

- 데이터 저장 오류: 헤더 행 삭제 및 데이터 저장 실패.

3. 데이터 추출 중심의 재설계: iFood를 기반으로 한 하이브리드 아키텍처

Runner H의 역할:

- iFood에서 상품 정보 추출: Nome, Descrição, Preço, ID único 등 6가지 필드 추출.

- Webhook으로 Zapier에 데이터 전송.

Zapier의 역할:

- Google Sheets API를 통해 데이터 저장 및 플랫폼 간 동기화.

- Runner H의 한계 극복 (예: HTTP 요청 제한, 오류 처리 강화).

API 활용:

- Zapier의 API 통합 기능으로 안정적 데이터 전송.

4. 학습 및 전략적 결론

AI Agent의 한계:

- UI 자동화 시 복잡한 데이터 구조 처리 실패 (예: 헤더 행 삭제).

- API 기반 접근이 더 안정적 (예: Zapier의 API 활용).

하이브리드 아키텍처의 장점:

- Runner H의 데이터 추출 능력과 Zapier의 통합 능력 결합.

- 사용자 친화적 자동화 (예: 최소한의 개발 지식 요구).

결론

권장 사항:

- 복잡한 UI 자동화는 Runner H가 아닌 API 기반 도구 (예: Zapier, Google Apps Script) 활용.

- 하이브리드 아키텍처를 채택하여 데이터 추출과 저장을 분리.

- Zapier의 API 통합 기능을 통해 데이터 정합성 보장.

핵심 팁:

- Webhook을 사용해 Runner H와 Zapier 간 실시간 데이터 전송.

- Google Sheets API 대신 Zapier의 Google Sheets 커넥터 사용 (더 안정적).

- Runner H의 한계를 인지하고 수작업 검증과 에러 로깅 필수.