Bing 웹마스터 API로 크롤링 수집 자동화 구축

구글 검색 콘솔처럼 Bing도 자동화 없이는 운영이 힘들다. 사이트맵을 수동으로 제출하고, 크롤 상태를 매일 확인하는 건 반복적이고 오류가 나기 쉽다. 이번에 Bing Webmaster API를 통합해서 우리 콘텐츠 수집 체인을 한 단계 격상시켰다.

왜 Bing인가

팀에서 처음 이 작업을 제안했을 때 반응이 다양했다. "우리 트래픽에서 Bing 비중이 별로 크지 않은데?" 하는 의문도 있었다. 하지만 두 가지 이유로 우선순위를 높였다.

첫째, SEO 인프라는 멀티 채널이어야 한다. 구글이 절대다수지만, Bing(+Edge)의 점유율도 무시할 수 없고, 특히 기업 사용자나 특정 지역에서는 더 중요하다. 전체 검색 가시성을 높이려면 주요 엔진을 모두 커버해야 한다.

둘째, 자동화의 확장성. 이미 구글 Search Console API 같은 것들을 다루고 있었는데, Bing도 같은 패턴으로 통합하면 향후 더 많은 검색 엔진이나 수집 채널을 쉽게 추가할 수 있다. 단순히 Bing 하나가 아니라 "검색 수집 자동화 플랫폼"으로 진화하는 기초를 다지는 셈이다.

구현 전략: 모듈화로 유연성 확보하기

변경 파일들을 보면 단순 "API 호출 스크립트"가 아니라 4개의 독립 모듈로 나뉜 걸 알 수 있다.

이렇게 분리한 이유는 각 기능의 라이프사이클이 다르기 때문이다.

• 사이트맵 제출은 배포 파이프라인의 일부 → bing_submit 은 CI/CD에서 호출
• 백로그 시딩은 주 1회 배치 작업 → bing_seed 는 스케줄러에서 실행
• 통계는 매시간 수집 → bing_stats 는 cron 또는 람다로 호출
• 모니터링은 on-demand 또는 webhook 기반 → bing_crawl 은 필요할 때 트리거

하나의 거대한 모듈이었다면, 나중에 A 기능은 자주 쓰는데 B 기능만 비활성화하고 싶을 때 코드 수정이 불가피했을 것이다. 지금처럼 분리하면 각 팀(배포 담당/운영/분석)이 필요한 모듈만 선택적으로 쓸 수 있다.

API 연동의 공통 패턴과 보안 고려사항

.gitignore 업데이트가 포함된 것도 중요한 부분이다. API 키나 인증 토큰은 절대 저장소에 들어가면 안 된다. 우리는 환경 변수나 시크릿 매니저(예: AWS Secrets Manager, 사내 정책)에서 읽도록 구성했다.

외부 API 연동할 때마다 체크리스트가 있다:

• 인증 방식: OAuth / API Key / JWT 등. Bing은 어떤 방식인가?
• Rate Limit: API 호출 수 제한이 있는가? 재시도 로직은?
• 에러 핸들링: API가 timeout/429/5xx를 반환하면?
• 모니터링: 실패한 API 호출을 어떻게 추적할 건가?
• 보안: 민감한 정보(토큰, URL)를 로그에 남기지 말 것

# 예시: 안전한 API 호출 패턴
def call_bing_api(endpoint, params):
    headers = {
        'Authorization': f'Bearer {os.getenv("BING_API_TOKEN")}'
    }
    # 로그에는 endpoint만, params는 민감한 데이터 제외
    logger.info(f"Calling Bing API: {endpoint}")

    response = requests.get(endpoint, headers=headers, params=params, timeout=30)
    response.raise_for_status()
    return response.json()

도메인 지식과 팀 커뮤니케이션

이 작업을 진행하면서 발견한 것 중 하나는 검색 엔진 API는 도메인 지식이 필요하다는 점이다. 단순 CRUD API가 아니라:

• 사이트맵 형식이 맞아야 한다
• URL 정규화 규칙이 있다 (www.example.com vs example.com)
• 크롤 예산(crawl budget) 개념이 있다
• 제출했다고 해서 즉시 인덱싱되는 게 아니다

팀원들이 이 부분을 이해하지 못하면 "API 호출했는데 왜 안 보여?" 하는 오류가 반복된다. 그래서 docs/hedvion-CLAUDE.md 업데이트도 함께했다. 각 모듈의 역할, 예상 반응 시간, 트러블슈팅 방법을 문서화해서 나중에 온보딩이나 운영 때 참조할 수 있게.

배운 점과 확장성

이 작업은 단순히 "Bing API 연동"을 넘어 우리 검색 수집 아키텍처를 재설계하는 계기가 됐다. 같은 패턴으로 다른 검색 엔진이나 수집 채널을 추가할 수 있는 기반을 마련했기 때문이다.

또한 팀 관점에서 생각해보니, API 연동 작업은 혼자가 아니라 여러 팀과 맞춰야 한다. 배포 팀(사이트맵 제출 시점), 인프라 팀(API 키 관리), 분석 팀(통계 수집), 보안 팀(감시 규칙). 각자의 요구사항을 수렴하고 타협점을 찾는 과정이 코드보다 오래 걸렸다. 하지만 그렇게 했기 때문에 나중에 "아, 이 부분은 고려 안 했네" 하는 후폭풍이 적을 수 있다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.