AI 추출 API는 구조화된 웹 데이터를 약속하지만, 신뢰성은 여전히 가장 어려운 과제

Google News는 AI 기반 API가 웹 개발을 재편한다는 SitePoint 헤드라인을 노출했지만, 더 큰 변화는 한 기사에만 국한되지 않는다. 이제 개발자는 먼저 맞춤형 파서를 작성하지 않고도 웹페이지를 API로 보내고 타입이 지정된 레코드를 요청할 수 있다.

이 변화는 단순해 보인다. 그러나 웹 개발의 어려운 부분을 결정론적 코드에서 모델이 매개하는 서비스로 옮긴다. 애플리케이션은 여전히 JSON을 받지만, 그 값은 렌더링, 프롬프트, 모델 동작, 그리고 계속 변하는 원본 콘텐츠에 따라 달라질 수 있다.

배포된 헤드라인은 특정 출시와 관련해 독립적으로 검증할 수 있는 세부 정보를 거의 제공하지 않는다. 하지만 그 전제는 Cloudflare, Google, OpenAI 및 기타 API 제공업체 전반에서 문서화된 기술적 흐름을 반영한다.

핵심 경쟁은 AI 추출과 수동 복사의 대결이 아니다. 모델 기반 해석과 명시적 선택자, 규칙, 실패 상태를 갖춘 기존 추출 코드 간의 대결이다.

AI API는 경직된 스크레이퍼보다 낯선 레이아웃을 더 잘 처리한다. 기존 파이프라인은 테스트, 재현, 감사가 더 쉽다. 가장 신뢰할 만한 개발 패턴은 어느 한쪽을 구식이라고 선언하는 대신 두 접근법을 결합한다.

Google News가 포착한 페이지에서 타입이 지정된 레코드로의 전환

웹 추출은 “이 요소를 찾아라”에서 “검증된 이 필드를 반환하라”로 이동하고 있다.

전통적인 스크레이퍼는 페이지를 문서 트리로 취급한다. 개발자는 CSS 선택자, XPath 표현식 또는 페이지별 규칙으로 요소를 찾는다. 그런 다음 문자열을 정리하고, 타입을 변환하며, 필드가 사라졌을 때의 처리 방식을 결정한다.

이 과정은 소스가 안정적일 때 잘 작동한다. 그러나 게시자가 클래스 이름을 바꾸거나, 콘텐츠를 클라이언트 측 컴포넌트로 옮기거나, 지역별로 다른 레이아웃을 표시하면 비용이 커진다.

AI 추출 API는 더 폭넓은 지시를 수용한다. 개발자는 제품명, 구매 가능 상태, 기사 작성자, 발행일, 정규 URL을 요청할 수 있다. 서비스는 페이지를 렌더링하거나 읽고, 내용을 해석한 뒤 요청된 필드를 반환한다.

Cloudflare는 2026년 7월 이 접근법을 구체화했다. Browser Rendering의 `/json` endpoint는 URL 또는 제공된 HTML을 받는다. 개발자는 프롬프트, JSON Schema 또는 둘 다 제공할 수 있다.

Cloudflare는 제품 세부 정보, 채용 공고, 기사 메타데이터 및 기타 구조화된 레코드와 관련된 예시를 문서화했다. 이는 추출을 페이지별 브라우저 스크립트 모음이 아니라 호스팅된 API 작업으로 만든다.

이 변화는 애플리케이션 아키텍처에 영향을 준다. 웹페이지는 사람의 읽기만을 위해 설계된 목적지가 아니라 타입이 지정된 워크플로의 일시적 입력값이 될 수 있다.

채용 애플리케이션은 다양한 채용 페이지를 하나의 내부 스키마로 변환할 수 있다. 모니터링 서비스는 공개 피드를 제공하지 않는 웹사이트의 공지를 정규화할 수 있다. 연구 제품은 기사를 인덱싱하기 전에 날짜, 조직, 주장 내용을 추출할 수 있다.

그렇다고 브라우저 자동화가 사라지는 것은 아니다. 추출 서비스는 여전히 페이지를 로드하고, 관련 콘텐츠를 기다리며, 리디렉션이나 인증을 처리해야 한다. AI는 콘텐츠 획득을 대체하는 것이 아니라 그 이후에 작동한다.

같은 구분은 Google News에도 적용된다. 집계 피드는 기사의 존재와 헤드라인을 알려줄 수 있다. 하지만 그 자체로 원문 페이지에 담긴 모든 주장을 확립하지는 않는다.

따라서 개발자는 두 가지 별도의 신뢰도 판단을 내려야 한다. 첫째, 시스템이 의도한 소스를 가져왔는가? 둘째, 시스템이 그 소스를 정확하게 해석했는가?

스키마는 author 필드가 문자열인지 검증할 수 있다. 하지만 반환된 문자열이 실제 작성자의 이름인지는 확립할 수 없다. 타입 정확성과 사실 정확성은 여전히 서로 다른 속성이다.

이 차이가 SitePoint 헤드라인이 중요한 이유를 설명한다. AI 추출은 개발자가 구축하는 인터페이스를 바꾸지만, 소스 검증의 필요성을 없애지는 않는다.

즉각적인 이점은 통합 작업의 감소다. 지속적인 과제는 해석된 데이터가 언제 프로덕션 시스템에 들어갈 자격이 있는지 판단하는 일이다.

구조화된 출력은 AI API 통합을 더 쉽게 만든다

스키마로 제약된 출력은 모델 응답을 일반적인 애플리케이션 코드가 검사하고, 거부하고, 라우팅할 수 있는 형태로 바꾼다.

자유 형식의 모델 텍스트는 불편한 경계를 만든다. 개발자는 JSON을 요청할 수 있지만, 응답에는 설명 문구, 누락된 키, 예상치 못한 타입 또는 형식 오류가 포함될 수 있다.

구조화된 출력은 이러한 불확실성을 줄인다. 개발자는 허용된 필드와 타입을 설명하는 스키마를 제공한다. 그러면 API는 응답을 해당 형태로 제한한다.

Google은 structured output을 데이터 추출, 분류, 에이전트 워크플로에 적합한 기능으로 문서화한다. 예시에서는 JSON Schema와 타입이 지정된 애플리케이션 모델을 통해 표현된 스키마를 보여 준다.

OpenAI는 2024년 8월 schema outputs 버전을 도입했다. 회사는 엄격한 스키마 준수와, 구문적으로 유효한 JSON 생성만을 목표로 했던 이전 JSON 모드를 구분했다.

이 기능은 여러 측면에서 개발자 경험을 바꾼다.

첫째, 애플리케이션 코드는 더 이상 관련 답을 찾기 위해 산문을 검색할 필요가 없다. 알려진 객체를 역직렬화하고 일반적인 검증 규칙을 적용할 수 있다.

둘째, 개발자는 필드를 필수로 표시할 수 있다. 누락된 발행일은 조용히 빈 데이터베이스 값이 되는 대신 검토 대기열을 트리거할 수 있다.

셋째, 스키마는 추출 단계와 다운스트림 서비스 사이의 계약이 된다. 프런트엔드 코드, 데이터베이스, 큐, 분석 시스템은 같은 필드 정의를 사용할 수 있다.

기사 모니터링 파이프라인을 생각해 보자. 대상 객체에는 제목, 작성자, 발행 타임스탬프, 정규 URL, 조직, 짧은 사실 주장 목록이 포함될 수 있다.

추출기는 이러한 필드를 반환하지만, 파이프라인은 이를 즉시 게시해서는 안 된다. 정규 도메인을 검증하고, 날짜를 정규화하며, 작성자를 페이지 메타데이터와 비교하고, 원문 구절을 보존할 수 있다.

마지막 필드는 중요하다. 뒷받침하는 맥락이 없는 추출된 사실은 감사하기 어렵다. 더 나은 스키마는 각 중요한 값과 함께 소스 텍스트, 페이지 URL, 조회 시간, 추출 버전을 포함한다.

이 아키텍처는 모델을 의심 없이 신뢰하는 데이터베이스가 아니라 불확실성을 지닌 파서로 취급한다. 모델은 구조화된 해석을 제안한다. 결정론적 코드는 그 해석이 운영 규칙을 충족하는지 결정한다.

이 설계는 목표가 분명한 재시도도 지원한다. 필수 날짜가 없으면 애플리케이션은 더 명확한 지시와 함께 해당 필드만 다시 실행할 수 있다. 모든 다운스트림 작업을 반복할 필요는 없다.

스키마 제약에도 한계는 있다. Google은 구조화 모드가 JSON Schema의 일부만 지원한다고 언급한다. OpenAI 역시 올바른 구조가 반환된 값 내부의 실수를 막아 주지는 않는다고 설명한다.

모델은 완벽하게 유효한 날짜 필드에 잘못된 날짜를 넣을 수 있다. 기사 업데이트 시간을 최초 발행 시간과 혼동할 수도 있다. 홍보성 문구를 독립적으로 확립된 사실로 해석할 수도 있다.

따라서 개발자는 의미 정확성을 스키마 준수와 별도로 측정해야 한다. 성공적인 API 응답은 전송과 형식이 작동했음을 증명한다. 추출이 정확했음을 증명하지는 않는다.

이 지점에서 AI 기반 API는 기존 파서와 다르다. 선택자는 요소가 사라지면 대개 눈에 띄게 실패한다. 반면 모델은 그럴듯한 대체값을 반환할 수 있다.

그럴듯함은 탐색 단계에서는 유용하다. 그러나 시스템이 결과를 조용히 저장하거나 재게시하거나 그에 따라 행동할 때는 위험해진다.

실용적인 대응은 계층형 검증이다. 팀은 민감한 레코드에 대해 스키마, 도메인 규칙, 신뢰도 임계값, 소스 인용, 사람의 검토를 결합할 수 있다.

내부 연구 시스템을 구축하는 개발자는 검증된 자료를 검색 가능한 지식 기반에 보존할 수도 있다. 이렇게 하면 추출된 주장을 이를 뒷받침하는 문서와 연결해 둘 수 있다.

AI 데이터 추출은 스크레이퍼와 API 제공업체에 압력을 가한다

AI 추출은 단순히 파서 코드를 대체하는 것이 아니라, 웹사이트와 애플리케이션 사이의 인터페이스를 누가 통제하는지를 바꾼다.

웹사이트 운영자는 전통적으로 구조화된 접근을 제공할지 결정한다. API를 공개하거나, 스키마 마크업을 추가하거나, RSS 피드를 제공하거나, 정보를 렌더링된 페이지 안에 남겨 둘 수 있다.

AI 추출은 그 경계를 약화시킨다. 제3자 서비스는 사이트 소유자의 협력 없이 사람을 위한 페이지를 비공식적인 구조화 인터페이스로 변환할 수 있다.

이러한 변화는 여러 집단에 동시에 압력을 가한다.

스크래핑 공급업체는 브라우저 인프라, 프록시 관리, 스케줄링, 신뢰성 제어가 여전히 중요한 이유를 보여야 한다. 모델 해석은 조회 엔지니어링을 대체하는 것이 아니라 또 하나의 파이프라인 단계가 된다.

API 제공업체는 다른 질문에 직면한다. 개발자가 웹사이트에서 받아들일 만한 레코드를 도출할 수 있다면, 일부는 공식 API 구축이나 라이선스 획득을 미룰 수 있다.

공식 API에는 여전히 결정적인 이점이 있다. 안정적인 식별자, 문서화된 의미, 업데이트 보장, 권한 제어, 공개 페이지에서 얻을 수 없는 데이터를 제공할 수 있다.

AI가 생성한 인터페이스는 기본적으로 그러한 보장을 전혀 제공하지 않는다. availability라는 필드는 현재 재고, 지역별 이용 가능 여부, 또는 마케팅 라벨을 의미할 수 있다. 의도된 의미를 정의할 수 있는 것은 소스 소유자뿐이다.

웹사이트 소유자는 더 나은 기계 판독 가능 데이터를 게시할 유인도 얻는다. 명확한 메타데이터는 추출 오류를 줄이고 검색, 어시스턴트, 집계 서비스 전반에서 콘텐츠가 표시되는 방식을 개선할 수 있다.

Google News는 이 구분의 중요성을 보여 준다. 집계 서비스는 제목과 목적지를 전달할 수 있다. 독자는 여전히 기사를 위해 게시자에게 의존하며, 애플리케이션은 피드 메타데이터와 원본 보도를 구분해야 한다.

압력은 프런트엔드 개발로도 확장된다. 팀들은 수년간 반응형 시각 인터페이스를 설계하면서 기계 접근은 별도의 백엔드 문제로 취급해 왔다.

이제 AI 에이전트는 독자로서 이러한 인터페이스와 상호작용한다. 페이지를 렌더링하고, 컨트롤을 해석하며, 데이터를 수집하고, 때로는 작업을 실행한다. 접근성 레이블과 시맨틱 HTML은 이러한 상호작용을 개선할 수 있지만, 어느 쪽도 정확한 해석을 보장하지는 않는다.

일반적으로 MCP라고 부르는 Model Context Protocol은 또 다른 경로를 추가한다. 이는 AI 애플리케이션이 도구와 데이터 소스에 연결하는 방식을 표준화한다. 웹사이트 운영자는 에이전트가 HTML에서 의미를 재구성하도록 방치하는 대신, 권한이 부여된 커넥터를 제공할 수 있다.

이는 “API 대 스크레이핑”보다 더 유용한 경쟁 구도를 만든다. 새롭게 부상하는 선택지는 공식 구조화 접근, 모델 매개 추출, 그리고 두 방식을 모두 사용하는 하이브리드 시스템을 포함한다.

공식 인터페이스는 반복적이고 고가치인 작업에 가장 적합하다. AI 추출은 롱테일 소스, 프로토타입, 일관된 스키마가 없는 문서에 잘 맞는다.

하이브리드 시스템은 공식 데이터로 시작해 추출로 빈틈을 메우고, 충돌 사례를 검토로 보낼 수 있다. 또한 오래되었거나 일치하지 않는 레코드를 탐지하기 위해 화면에 표시된 페이지 콘텐츠와 API 응답을 비교할 수 있다.

경제적 트레이드오프는 개발 시간에만 국한되지 않습니다. 팀은 렌더링 지연 시간, 모델 호출, 재시도율, 검토 인력, 소스 변경으로 인한 실패까지 고려해야 합니다.

짧은 프롬프트는 이런 복잡성을 감출 수 있습니다. “이 사이트의 모든 목록을 추출해”라는 요청은 크롤러를 유지보수하는 일보다 쉬워 보입니다. 하지만 실제 운영 환경의 동작은 여전히 페이지네이션, 중복 감지, 지역별 차이, 동의 배너, 오류 복구에 좌우됩니다.

이 변화는 테스트 방식도 바꿉니다. 기존 스크레이퍼 테스트는 흔히 저장된 HTML 픽스처와 예상 셀렉터 결과를 사용합니다. AI 추출에는 레이아웃 변화, 모호한 표현, 누락된 필드, 적대적 콘텐츠를 포함하는 더 폭넓은 평가 세트가 필요합니다.

팀은 필드 수준의 정밀도와 재현율을 측정해야 합니다. 또한 지원되지 않는 값, 충돌하는 소스, 모델 또는 프롬프트 업데이트 후 발생한 변화도 추적해야 합니다.

이러한 평가 규율이 AI 추출이 인프라가 될지, 아니면 편리한 데모로 남을지를 결정합니다.

진짜 문제는 신뢰할 수 없는 페이지의 데이터를 신뢰하는 일입니다

AI 추출기에 제공되는 모든 웹페이지는 데이터이면서 동시에 잠재적인 지시 표면입니다.

기존 HTML 파서는 문장을 명령으로 해석하지 않습니다. 언어 모델은 그럴 수 있습니다. 이 차이는 일반적인 잘못된 마크업을 넘어서는 보안 위험을 초래합니다.

공격자는 페이지에 숨겨진 지시문이나 눈에 보이는 지시문을 배치할 수 있습니다. 이러한 지시문은 추출기에 작업을 무시하거나, 반환 값을 변경하거나, 컨텍스트를 공개하거나, 연결된 도구를 호출하라고 요구할 수 있습니다.

OWASP는 이 문제를 프롬프트 인젝션으로 분류합니다. 해당 가이드는 웹사이트와 파일 같은 외부 소스를 통해 전달되는 간접 공격을 구체적으로 지목합니다.

추출이 더 광범위한 권한을 가진 에이전트와 연결되면 위험은 커집니다. 읽기 전용 프로세스는 잘못된 데이터를 생성할 수 있습니다. 데이터베이스, 이메일 또는 배포 권한을 가진 에이전트는 훨씬 더 큰 결과를 초래할 수 있습니다.

구조화된 출력은 일부 형식 위험을 줄이지만, 프롬프트 인젝션을 해결하지는 못합니다. 악성 페이지는 필요한 스키마를 유지하면서도 값을 조작하려 시도할 수 있습니다.

예를 들어 추출기는 공급업체 이름과 결제 목적지를 요청할 수 있습니다. 적대적인 문서는 유효한 필드를 반환하면서도 공격자가 통제하는 계정으로 대체하도록 모델에 지시할 수 있습니다.

애플리케이션은 추출된 콘텐츠 주위에 엄격한 신뢰 경계를 설정해야 합니다.

모델에는 작업에 필요한 콘텐츠만 제공해야 합니다. 스크립트, 주석, 숨겨진 요소, 관련 없는 내비게이션은 유용한 근거를 제공하지 않는다면 추론 전에 제거할 수 있습니다.

자격 증명은 모델 컨텍스트 밖에 유지해야 합니다. 추출 서비스는 범위가 좁은 토큰을 사용해야 하며, 더 광범위한 에이전트 세션의 권한을 상속해서는 안 됩니다.

영향이 큰 작업에는 결정론적 검사가 필요합니다. 모델이 도출한 URL은 요청을 보내기 전에 도메인 허용 목록을 통과해야 합니다. 금융 또는 신원 데이터는 권위 있는 소스와의 비교가 필요합니다.

개발자는 모델 출력을 신뢰할 수 없는 입력으로도 취급해야 합니다. HTML을 렌더링하기 전에 값을 이스케이프하고, 데이터베이스 작업은 매개변수화하며, URL을 가져오기 전에 검증해야 합니다.

출처 정보는 또 다른 방어 수단을 제공합니다. NIST의 AI 위험 프로필은 출처 추적을 콘텐츠의 원본과 이력을 기록하는 방법으로 설명합니다.

추출 시스템에서 유용한 출처 정보에는 소스 URL, 수집 타임스탬프, 눈에 보이는 근거 텍스트, 렌더링 구성, 모델 식별자, 프롬프트 버전, 검증 결과가 포함됩니다.

이 기록은 팀이 잘못된 답변을 조사하는 데 도움이 됩니다. 또한 모델 업데이트나 소스 수정 후 데이터를 재처리할 수 있게 합니다.

재현성은 여전히 어렵습니다. 웹사이트 콘텐츠는 바뀌고, 개인화된 페이지는 서로 다르며, 모델 서비스도 발전합니다. 향후 재시도에서는 동일한 입력을 마주하지 못하거나 같은 해석을 만들어내지 못할 수 있습니다.

팀은 적절한 경우 합법적으로 보관한 스냅샷이나 암호학적 해시를 저장해 이러한 불확실성을 줄일 수 있습니다. 불필요한 개인정보를 보관하지 않으면서 관련 구절은 보존할 수 있습니다.

데이터 보호도 똑같이 주의해야 합니다. 공개 URL이라고 해서 추출한 모든 필드가 무기한 저장, 집계 또는 자동화된 의사결정에 적합하다는 의미는 아닙니다.

개발자는 접근 약관, 개인정보 보호 의무, 지식재산권, robots 지침을 고려해야 합니다. 기술적으로 가능하다는 사실만으로 이러한 정책적 질문에 답이 되지는 않습니다.

공격자가 없어도 품질 위험은 나타납니다. 페이지에는 오래된 가격, 지역별 이용 가능 여부, 중복된 날짜, 스폰서 문구 또는 본문 기사와 모순되는 댓글이 포함될 수 있습니다.

모델에는 명시적인 근거 우선순위가 필요합니다. 페이지 메타데이터는 정식 URL을 결정할 수 있고, 눈에 보이는 기사 본문은 사실 주장에 근거를 제공합니다. 댓글 섹션이 발행사가 보도한 정보를 덮어써서는 안 됩니다.

그렇더라도 모호성은 남습니다. 올바른 결과는 때로 확신에 찬 추측이 아니라 null입니다.

스키마는 소스가 불확실한 경우 그 불확실성을 허용해야 합니다. 유용한 필드로는 not_found, ambiguous, conflicting, requires_review가 포함될 수 있습니다.

이 설계는 완전한 레코드를 더 적게 만들 수 있습니다. 하지만 모든 필드에 그럴듯한 값을 강제로 넣는 방식보다 더 안전한 시스템을 만듭니다.

가장 중요한 신뢰성 지표는 API가 JSON을 반환하는 빈도가 아닙니다. 후속 사용자가 각각의 중요한 값을 충분한 근거까지 추적할 수 있는 빈도입니다.

Google News 신호 이후 개발자가 주시해야 할 점

다음 단계는 헤드라인 수준의 시연이 아니라 측정된 정확도, 승인된 접근, 운영 가시성이 결정할 것입니다.

향후 몇 달 동안 세 가지 신호에 주목할 필요가 있습니다.

첫 번째는 추출 제공업체가 현실적인 페이지에서 필드 수준 평가를 공개하는지 여부입니다. 스키마 준수만으로는 더 이상 충분하지 않습니다. 개발자에게는 모호한 날짜, 동적 콘텐츠, 지역별 변형, 누락된 필드, 변경된 레이아웃에 대한 결과가 필요합니다.

제공업체는 지원되지 않는 값을 어떻게 평가하는지 공개해야 합니다. 모든 필드를 채우는 시스템은 완성돼 보일 수 있지만, 신중한 경쟁사보다 더 많은 잘못된 레코드를 생성할 수 있습니다.

독립적인 평가는 시장을 강화할 수 있습니다. 테스트 세트에는 일반적인 실패와 의도적으로 적대적인 페이지가 모두 포함돼야 합니다. 결과는 렌더링 성공, 추출 정확도, 근거 품질을 구분해야 합니다.

두 번째 신호는 승인된 머신 인터페이스의 성장입니다. 웹사이트 소유자는 권한과 필드 의미를 정의하는 안정적인 API, 피드, 구조화된 메타데이터 또는 에이전트 커넥터를 게시할 수 있습니다.

AI 추출이 이러한 인터페이스를 없애지는 않을 것입니다. 오히려 비정형 접근이 오류를 만들어내는 지점을 보여 주면서 이에 대한 수요를 높일 수 있습니다.

개발자는 콘텐츠 플랫폼이 인용, 안정적인 식별자, 명시적인 사용 제어를 제공하는지 지켜봐야 합니다. 단지 유려한 텍스트를 반환하는 엔드포인트보다 이런 기능이 더 중요합니다.

세 번째 신호는 운영 파이프라인 내부의 향상된 관측성입니다. 팀은 어떤 소스가 값을 뒷받침했는지, 어떤 모델이 이를 생성했는지, 어떤 검증 규칙이 이를 수용했는지 확인할 수 있어야 합니다.

추출 시스템은 시간에 따른 변화를 보고해야 합니다. 누락된 작성자나 상충하는 날짜의 급증은 소스 재설계, 렌더링 실패 또는 모델 회귀를 드러낼 수 있습니다.

사람의 검토율도 중요합니다. 대부분의 레코드를 자동화하지만 어려운 사례마다 전문가에게 보내는 시스템도 여전히 상당한 가치를 제공할 수 있습니다. 운영자는 그 인력에 대한 정직한 측정치를 확보해야 합니다.

Google News 헤드라인은 실제 아키텍처 변화의 방향을 가리킵니다. 모델이 페이지와 문서를 필요할 때 해석할 수 있게 되면서, 웹 개발은 사전에 마련된 인터페이스에 덜 의존하게 되고 있습니다.

하지만 성공하는 시스템은 해석을 진실로 취급하지 않을 것입니다. 모델의 유연성을 명시적 스키마, 결정론적 검증, 제한된 권한, 출처 정보, 검토와 결합할 것입니다.

개발자에게 당면한 질문은 AI가 페이지를 추출할 수 있는지 여부가 아닙니다. 많은 조건에서 분명히 가능합니다. 더 나은 질문은 애플리케이션이 결과를 신뢰하기 전에 어떤 근거가 존재해야 하는가입니다.

범위가 제한된 워크플로 하나로 시작해 대표적인 평가 세트를 만드세요. 중요한 필드에는 인용을 요구하고, 불확실성을 보존하며, AI 경로를 결정론적 기준선과 비교하세요. 소스, 프롬프트 또는 모델이 바뀔 때마다 정확도를 추적하세요. 이러한 통제가 감당할 수 있는 수준으로 유지된다면 워크플로를 확장하세요. 예상 이점을 압도한다면 기존 파서나 공식 API를 유지하세요. Google News는 이 추세를 부각하는 데 도움이 될 수 있지만, 아키텍처는 운영 환경의 근거가 결정해야 합니다.