메타 광고 레퍼런스 아카이빙 도구 제작 EP.2

소개

Meta Ad Library에서 경쟁사 광고를 수동으로 찾아보던 시간을 없애고, 키워드만 등록하면 자동으로 수집되는 대시보드를 Claude Code와 함께 제작하였습니다.


이슈

  • 광고 소제를 제작할 때 전문 그래픽 디자이너가 아닌 마케터이기 때문에, 다른 사례를 보면서 참고하는 것이 큰 도움이 됨.

  • 메타 광고 라이브러리를 활용해서 특정 키워드 검색 결과의 데이터를 계속 아카이빙 하는 시스템을 구축하고자 함.

    • 기존 메타 라이브러리는 핀터레스트와 같이 이미지만 쭉 보기 어려움

    • 현재 운영 중인 광고 이미지가 확인되며 과거에 운영된 데이터는 확인이 어려움

    • 다른 SaaS 서비스에서 ‘광고주’ 기준으로는 데이터를 확인할 수 있는 서비스는 있으나 ‘키워드’ 기준으로 데이터 아카이빙 하는 것은 발견 못 함.

진행 방법

사용한 도구

claude code
Python
Playwright 웹 스크래핑

전체 아키텍처 및 최종 결과물

결과물의 이미지는 위와 같습니다.
원하는 키워드를 등록해두면 매주 월요일과 금요일 오전 9시 기준으로, 해당 키워드로 검색되는 광고 소재들이 자동으로 스크랩됩니다. 또한 하단의 [지금 수집] 버튼을 통해, 필요할 경우 현재 시점의 데이터도 즉시 한 번 더 수집할 수 있도록 기능을 추가했습니다..

아울러 핀터레스트와 유사하게, 광고 이미지에 마우스를 올리면 즐겨찾기를 설정할 수 있으며, 즐겨찾기한 광고 소재만 모아볼 수 있는 전용 메뉴도 함께 구성했습니다.

이 기능을 활용하면 실제 광고 소재를 제작할 때, 레퍼런스로 활용하고 싶은 광고만 선별적으로 필터링하여 효율적으로 참고할 수 있을 것으로 기대됩니다.


제작 과정 주요 이슈 및 해결 방안

  1. 로컬에서 웹으로 배포할 때 이미지가 안 불러와짐

로컬에서 npm run dev로 테스트할 때는 광고 이미지가 잘 보였는데, Vercel로 배포하고 나니 이미지가 전부 깨져서 안 보였습니다.

🚀 해결 방안



수집한 광고 이미지 URL이 Meta 서버의 임시 URL이었습니다. 이 URL은 일정 시간이 지나면 만료되거나, 외부에서 직접 접근이 차단되는 경우가 있었어요. 로컬에서는 캐시 덕분에 보였던 것이고, 배포 환경에서는 새로 불러오려니 접근이 안 됐던 거죠.

이미지를 영구적으로 저장할 외부 호스팅이 필요했습니다. 처음에는 Cloudflare R2를 시도했는데 설정이 복잡해서, 결국 imgbb라는 무료 이미지 호스팅 서비스로 변경했습니다.

수집 파이프라인에 이미지 업로드 단계를 추가했어요:
1. Meta에서 이미지 URL 수집
2. 해당 이미지를 다운로드
3. imgbb API로 업로드
4. 반환된 영구 URL을 DB에 저장

이렇게 하니 배포 환경에서도 이미지가 안정적으로 표시됐습니다.

  1. [지금 수집] 기능으로 일정 외 필요한 시점에 데이터 업데이트 하는 기능 추가

처음에는 GitHub Actions 스케줄로 월/금 오전 9시에만 자동 수집되도록 설정했습니다.
그런데, 신규 키워드를 추가했을 때나, 금일 시점의 데이터를 업데이트 하는 기능도 있으면 좋겠다 싶었습니다.


🚀 해결 방안

대시보드에서 버튼 하나만 누르면 바로 수집이 시작되는 기능이 필요했습니다.

핵심은 웹 UI에서 GitHub Actions를 직접 트리거하는 것이었어요. GitHub API 중에 workflow_dispatch라는 게 있는데, 이걸 호출하면 수동으로 워크플로우를 실행할 수 있습니다.

결과

이제 키워드 등록 후 바로 "지금 수집" 버튼을 누르면:

1. GitHub Actions가 즉시 실행됨
2. 등록된 모든 키워드에 대해 광고 수집
3. 몇 분 후 대시보드에서 새 광고 확인 가능

스케줄 수집은 정기적인 모니터링용으로 유지하고, 급할 때는 수동 수집으로 바로 데이터를 가져올 수 있게 됐습니다.

결과와 배운 점

배포 환경은 로컬과 다르다는 걸 다시 한번 느꼈습니다. 로컬에서 잘 되던 게 배포하면 안 되는 경우가 많아요. 특히:

- 외부 리소스 의존성 (이미지 URL 만료)

- 데이터 타입 불일치 (유연한 로컬 vs 엄격한 DB)

- 쉘 스크립트의 공백 처리 (예상치 못한 분리)

이런 부분들은 직접 겪어봐야 알게 되는 것 같은데 비 개발자다 보니 이러한 상황을 미리 예견할 수 없는 점은 한계인 것 같습니다.

또한 서비스 기획을 처음부터 탄탄하게 하고 시작한 것이 아니기 때문에 중간 중간에 추가하는 기능이 많아졌습니다. 그러면서 코드가 꼬여서인지 제대로 작동하는 것들이 생기고 그러한 버그를 잡는데 시간이 좀 오래 걸렸던 것 같습니다.

시간이 걸려서라도 유용한 기능을 만들었긴 한데 미리 서비스에 대한 기획이 잘 된 다음 ui를 구축하면 좋겠다는 생각을 해보았습니다.

2
7개의 답글

뉴스레터 무료 구독

👉 이 게시글도 읽어보세요