공식 API와 웹 크롤링, 어떤 방식으로 데이터를 수집해야 할까?

외부 서비스의 데이터를 가져오려 할 때 일반적으로 두 가지 방법을 검토하게 됩니다.

• 서비스가 제공하는 공식 API 사용
• 웹페이지에 표시되는 내용을 크롤링

예를 들어 다음과 같은 데이터를 수집할 수 있습니다.

• 상품 정보
• 주문과 배송
• 뉴스
• 채용 공고
• 공공 데이터
• 소셜 콘텐츠
• 부동산 매물
• 기업 정보
• 지도와 장소
• 사용자 활동

API가 있다면 무조건 API를 사용해야 하는지, 크롤링이 더 빠르고 저렴한지 고민할 수 있습니다.

일반적으로 공식 API는 데이터 구조와 사용 방법이 문서화되어 있어 안정적인 연동에 유리할 수 있습니다.

반면 API가 없거나 필요한 정보가 제공되지 않는다면 웹 크롤링을 검토할 수 있습니다.

하지만 선택은 단순히 개발이 쉬운 방식이 아니라 다음 조건을 기준으로 해야 합니다.

필요한 데이터를 허용된 범위에서 지속적으로 안정되게 확보할 수 있는 방식은 무엇인가?

API란?

API는 서로 다른 서비스가 정해진 규칙으로 데이터를 주고받을 수 있게 만든 연결 방식입니다.

예를 들어 다음 주소에 요청을 보내면 상품 데이터를 JSON 형식으로 받을 수 있습니다.

{
  "id": 1001,
  "name": "상품 A",
  "price": 25000,
  "status": "SALE"
}

개발자는 화면에 표시된 글자를 찾아 읽는 대신 정해진 데이터 항목을 직접 받을 수 있습니다.

웹 크롤링이란?

웹 크롤링은 사용자가 보는 웹페이지에 접속해 필요한 내용을 추출하는 방식입니다.

예시:

<div class="product">
  <h2>상품 A</h2>
  <span class="price">25,000원</span>
</div>

프로그램이 제목과 가격이 표시된 위치를 찾아 데이터를 가져옵니다.

API와 크롤링의 기본 차이

공식 API를 우선 검토할 이유

1. 데이터 구조가 명확할 가능성이 높습니다

API는 보통 다음 정보를 문서로 제공합니다.

• 요청 주소
• 인증 방법
• 입력값
• 응답값
• 오류 코드
• 호출 제한
• 예제

웹페이지의 위치를 추측해서 읽는 것보다 필요한 데이터를 명확하게 받을 수 있습니다.

2. 화면 디자인 변경의 영향을 덜 받을 수 있습니다

웹사이트가 디자인을 바꿔도 API 응답이 유지된다면 연동 서비스는 계속 작동할 수 있습니다.

다만 API도 버전과 정책이 변경될 수 있으므로 영구적으로 동일하다고 볼 수는 없습니다.

3. 데이터가 정제되어 있을 수 있습니다

웹 화면에는 다음이 함께 섞여 있을 수 있습니다.

• 표시용 문구
• 통화 기호
• 광고
• 추천 영역
• 줄바꿈
• 숨겨진 데이터

API에서는 숫자와 상태값이 비교적 명확하게 구분될 수 있습니다.

4. 대량 데이터와 페이지 이동이 체계적일 수 있습니다

API는 다음 기능을 제공할 수 있습니다.

• 페이지 번호
• 커서
• 기간 검색
• 수정 시각
• 상태 필터
• 정렬

전체 데이터를 처음부터 다시 가져오지 않고 변경된 데이터만 요청할 수 있는 경우도 있습니다.

5. 서비스 정책이 상대적으로 명확할 수 있습니다

API 문서와 이용약관에서 다음 내용을 확인할 수 있습니다.

• 상업적 사용
• 저장 가능 여부
• 재배포
• 호출 한도
• 표시 의무
• 개인정보
• 이용료

실제 서비스 활용 전에 현재 정책을 확인해야 합니다.

크롤링이 필요할 수 있는 경우

1. 공식 API가 없습니다

웹서비스가 외부 데이터 제공 기능을 운영하지 않을 수 있습니다.

2. API에 필요한 데이터가 없습니다

API는 상품명과 가격만 제공하지만 화면에는 다음 정보가 추가로 있을 수 있습니다.

• 리뷰 수
• 상세 옵션
• 배지
• 재고 안내
• 프로모션
• 사용자 설명

필요한 정보가 API 범위에 없다면 다른 방법을 검토해야 합니다.

3. API 이용 승인을 받기 어렵습니다

• 제휴사만 사용 가능
• 별도 계약 필요
• 심사 필요
• 특정 사업자만 허용
• 높은 이용료
• 국가 제한

4. 공개 페이지의 소규모 정보를 일회성으로 수집합니다

장기 운영 시스템이 아니라 내부 조사와 일회성 데이터 정리가 목적이라면 크롤링이 현실적일 수 있습니다.

다만 데이터 이용 조건은 별도로 확인해야 합니다.

API가 항상 쉬운 것은 아닙니다

API 문서가 있다는 이유만으로 키만 연결하면 끝이라고 보기는 어렵습니다.

다음 작업이 필요할 수 있습니다.

• 개발자 계정 생성
• 앱 등록
• 인증
• OAuth
• 토큰 갱신
• 데이터 변환
• 호출 제한
• 웹훅
• 오류 재시도
• 관리자
• 로그
• 데이터 동기화

API가 제공하는 데이터 구조와 우리 서비스의 데이터 구조가 다르면 변환 작업이 필요합니다.

API 개발 비용을 높이는 조건

1. 인증 방식이 복잡합니다

• API 키
• OAuth
• 사용자별 동의
• 토큰 갱신
• 인증서
• IP 허용
• 전자서명

사용자마다 외부 계정을 연결해야 한다면 단일 서버 키보다 복잡합니다.

2. 여러 API를 조합해야 합니다

예를 들어 주문 데이터를 가져오기 위해 다음 API를 각각 호출할 수 있습니다.

• 주문 목록
• 주문 상세
• 상품
• 고객
• 배송
• 결제

데이터를 서로 연결하고 중복 요청을 줄여야 합니다.

3. 호출량 제한이 있습니다

예시:

분당 100회
하루 10,000회
사용자별 제한

전체 데이터를 한 번에 가져오지 못하고 작업을 나눠야 할 수 있습니다.

4. 웹훅이 필요합니다

웹훅은 외부 서비스에서 이벤트가 발생했을 때 우리 서버에 알려주는 방식입니다.

예시:

결제 완료
→ 외부 서비스가 우리 서버에 알림
→ 주문 상태 변경

웹훅에는 다음 처리가 필요할 수 있습니다.

• 인증
• 중복 수신
• 순서 변경
• 실패 재처리
• 로그

5. 데이터 동기화가 필요합니다

한 번 데이터를 받아오는 것과 두 시스템의 데이터를 계속 맞추는 것은 다릅니다.

• 신규 생성
• 수정
• 삭제
• 충돌
• 마지막 동기화
• 실패 재처리

양방향 동기화는 한쪽 데이터만 읽는 연동보다 복잡합니다.

크롤링 비용을 높이는 조건

• 로그인
• 동적 화면
• CAPTCHA
• 무한 스크롤
• 사이트 다수
• 잦은 화면 변경
• 대량 데이터
• 이미지·파일
• 짧은 수집 주기
• 관리자와 모니터링

안정성 비교

API의 주요 장애 요인

• API 서버 장애
• 인증 만료
• 호출 제한
• 버전 종료
• 응답 형식 변경
• 계정 정지
• 이용료 변경

크롤링의 주요 장애 요인

• HTML 구조 변경
• 로그인 변경
• 자동화 차단
• 주소 변경
• 데이터 로딩 방식 변경
• 화면 요소 추가·삭제

두 방식 모두 유지보수가 전혀 필요 없는 것은 아닙니다.

다만 공식적인 연동 채널이 있다면 화면 구조에 의존하는 크롤링보다 예측 가능한 운영이 가능할 수 있습니다.

데이터 범위 비교

API가 제공하는 정보와 화면의 정보가 다를 수 있습니다.

필요한 데이터가 실제로 어디에 존재하는지 먼저 확인해야 합니다.

API와 크롤링을 함께 사용할 수도 있습니다

하나의 방식만 선택해야 하는 것은 아닙니다.

예시:

공식 API:
상품 ID, 가격, 재고

웹 크롤링:
공개 상세 설명과 프로모션 문구

다만 동일한 데이터가 서로 다르게 나타날 수 있으므로 기준 원본을 정해야 합니다.

내부 API를 사용하는 방식은 주의해야 합니다

웹사이트 화면은 내부적으로 API를 호출해 데이터를 표시할 수 있습니다.

브라우저 개발 도구에서 해당 주소가 보인다고 공식 API인 것은 아닐 수 있습니다.

• 외부 사용을 전제로 하지 않음
• 인증 구조가 변경될 수 있음
• 사전 안내 없이 주소 변경
• 이용 조건이 불분명함
• 호출 제한과 차단 가능성

공식 문서와 제공 조건이 있는지 확인해야 합니다.

선택 기준 1. 장기 운영인가?

단기간 조사

크롤링이 효율적일 수 있습니다.

핵심 사업 서비스

공식 API와 계약 가능한 데이터 공급원을 우선 검토하는 것이 좋습니다.

서비스의 핵심 데이터가 비공식적인 화면 구조에만 의존하면 운영 위험이 커질 수 있습니다.

선택 기준 2. 데이터가 얼마나 자주 바뀌는가?

실시간에 가까운 정보가 필요하다면 API의 갱신 주기와 웹훅 제공 여부를 확인합니다.

화면 크롤링을 지나치게 짧은 간격으로 반복하는 방식은 안정성과 비용 측면에서 불리할 수 있습니다.

선택 기준 3. 데이터 저장과 재사용이 가능한가?

데이터를 수집할 수 있다는 사실과 장기간 저장·재가공·재판매할 수 있다는 것은 다른 문제입니다.

다음을 확인해야 합니다.

• 저장 가능 여부
• 보관 기간
• 사용자에게 표시 가능 여부
• 원문 링크 표시
• 재배포
• 상업적 이용
• 개인정보

선택 기준 4. 데이터 품질

• 고유 ID가 있는가?
• 업데이트 시각이 있는가?
• 삭제 상태를 알 수 있는가?
• 값이 구조화되어 있는가?
• 누락 데이터가 얼마나 있는가?
• 중복을 구분할 수 있는가?

데이터 품질이 낮으면 수집 이후 정제 비용이 커집니다.

선택 기준 5. 운영 비용

API 운영비

• API 이용료
• 호출량 비용
• 서버
• 저장
• 개발·유지보수

크롤링 운영비

• 서버
• 브라우저 자동화
• 프록시 등 외부 도구
• 구조 변경 대응
• 모니터링
• 재수집

초기 개발비뿐 아니라 1년 동안의 운영 비용을 비교하는 것이 좋습니다.

방식 선택표

API를 검토할 때 확인할 질문

공식 API가 있는가?
필요한 데이터가 모두 있는가?
상업적 사용이 가능한가?
데이터 저장이 가능한가?
호출량 제한은 얼마인가?
월 이용료는 얼마인가?
웹훅을 제공하는가?
버전 종료 정책은 무엇인가?
개발·운영 계정을 분리할 수 있는가?
장애와 지원 문의 창구가 있는가?

크롤링을 검토할 때 확인할 질문

로그인이 필요한가?
공개 페이지인가?
수집 항목은 무엇인가?
사이트 구조가 자주 바뀌는가?
수집 주기는 얼마인가?
데이터 양은 얼마인가?
자동화 제한이 있는가?
이용 조건을 확인했는가?
실패를 어떻게 감지하는가?
구조 변경 유지보수 예산이 있는가?

개발 업체에 전달할 정보

데이터 사용 목적:
대상 서비스:
공식 API 문서:
필요한 데이터:
API에서 제공되지 않는 데이터:
예상 호출량:
수집 주기:
사용자별 계정 연결:
데이터 저장 기간:
상업적 활용:
관리자 기능:
실패 알림:
월 운영비 범위:
향후 데이터 확대 계획:

견적서에서 확인할 항목

• API와 크롤링 중 어떤 방식을 사용하는가?
• 해당 방식을 선택한 이유는 무엇인가?
• 이용료와 외부 비용은 얼마인가?
• 데이터 저장과 이용 조건을 누가 확인하는가?
• 호출 제한과 재시도가 포함되는가?
• 사이트 또는 API 변경 대응은 어떻게 하는가?
• 데이터 누락과 중복을 어떻게 확인하는가?
• 관리자와 모니터링이 포함되는가?
• 대체 데이터 공급원이 있는가?
• 계약 종료 후 데이터와 소스를 받을 수 있는가?

마무리

공식 API와 웹 크롤링 중 무엇이 더 좋은지는 데이터와 사업 목적에 따라 달라집니다.

일반적으로는 다음 순서로 검토하는 것이 좋습니다.

1. 공식 API 또는 정식 데이터 제공 방식이 있는지 확인
2. 필요한 데이터와 사용 조건 확인
3. API로 부족한 정보만 별도 방식 검토
4. 장기 운영과 변경 대응 비용 비교
5. 실패와 데이터 품질 관리 구조 설계

빠르게 수집할 수 있는 방법보다 장기간 안정적으로 사용할 수 있는 방법을 선택하는 것이 중요합니다.