🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

RSS 수집, 관리형 브라우저 렌더링, AI 분석, 벡터 검색을 결합해 여러 웹사이트의 콘텐츠를 자동으로 수집하고 검색 가능한 인사이트로 전환하는 이벤트 기반 시스템을 설명한다.

📌 핵심 요약

• 수작업 웹 모니터링과 페이지 구조에 의존하는 규칙 기반 스크래퍼의 한계를 해결하기 위해 자바스크립트 중심 페이지까지 렌더링하는 Amazon Bedrock AgentCore Browser를 활용한다.
• Amazon EventBridge가 15분마다 RSS 수집 Lambda를 실행하고, URL 해시와 Amazon S3를 이용해 새 문서를 판별한 뒤 HTML, 화면 캡처, 메타데이터, 이미지를 구조적으로 저장한다.
• S3 업로드 이벤트와 Amazon SQS가 수집 단계와 처리 단계를 분리하며, 두 번째 Lambda가 HTML을 정제한 후 Amazon Bedrock으로 요약, 주제, 엔터티, 범주, 실행 가능한 인사이트를 추출한다.
• 원문과 AI 생성 메타데이터 및 임베딩은 Amazon OpenSearch Serverless에 색인되어 키워드 검색과 의미 기반 벡터 검색을 함께 지원한다.
• 운영 단계에서는 브라우저 세션 비용, HTML 전처리, SQS 재시도와 데드레터 큐, 생성 결과의 근거성 통제, OpenSearch Serverless의 최소 비용을 핵심 고려사항으로 제시한다.

🧩 주요 포인트

1. 관리형 원격 브라우저가 동적 웹페이지를 완전히 렌더링하므로 페이지 변경에 따른 수집 실패 가능성을 낮추지만, 일반 HTTP 요청보다 시간과 비용이 커 중복 제거가 필수적이다.
2. S3와 SQS를 경계로 수집과 AI 처리를 분리하면 두 단계가 독립적으로 확장되고 실패한 분석 작업을 재시도할 수 있어 전체 파이프라인의 복원력이 높아진다.
3. 정제된 본문에서 인사이트와 임베딩을 생성해 함께 색인하면 정확한 단어가 일치하지 않아도 관련 문서를 찾을 수 있지만, 저용량 환경에서는 검색 서비스의 고정 비용을 비교해야 한다.

🧠 상세 정리

1. 수작업 모니터링과 기존 스크래퍼의 한계

여러 웹사이트에서 인사이트를 얻으려면 담당자가 각 사이트를 방문하고 콘텐츠를 복사한 뒤 분석 가능한 형태로 정리해야 하므로 대상이 늘수록 작업 부담이 빠르게 커진다. 디자인 팀은 경쟁 제품을, 마케팅 팀은 콘텐츠 동향을, 제품 관리자는 시장 정보를 지속적으로 추적해야 하지만 수작업 방식에서는 실제 분석 전에 반복적인 수집 업무가 선행된다. 규칙 기반 스크래퍼는 일부 과정을 자동화할 수 있으나 특정 페이지 구조와 강하게 결합되어 있어 사이트 개편이나 자바스크립트 기반 프런트엔드 전환 시 파이프라인이 조용히 중단될 수 있다. 글에서 제시하는 해결책은 관리형 브라우저로 완성된 페이지를 확보한 뒤 수집, AI 처리, 검색을 분리해 이러한 취약성을 줄이는 자동화 시스템이다.

2. 적용 대상과 전체 해결 범위

이 시스템은 산업 동향을 추적하는 디자인·제품 팀을 위해 만들어졌지만, 동일한 구조를 경쟁 정보, 시장 조사, 콘텐츠 큐레이션, 규제 준수 모니터링에 적용할 수 있다. 경쟁사 블로그와 제품 발표 및 보도자료를 수집하면 AI가 새로운 기능, 가격 변화, 전략적 움직임과 같은 정보를 식별하도록 구성할 수 있다. 산업 뉴스, 분석 보고서, 전문 매체를 모니터링하면 사업과 관련된 신흥 기술이나 시장 흐름을 검색할 수 있고, 여러 출처의 콘텐츠 중 대상 독자에게 관련성이 높은 자료를 선별하는 용도로도 활용할 수 있다. 규제 웹사이트와 뉴스 출처를 지속적으로 확인하는 구성은 사업에 영향을 줄 수 있는 변경 사항을 발견하는 데 쓰이며, 공통 기반은 외부 콘텐츠를 자동 수집해 검색 가능한 인사이트로 바꾸는 과정이다.

3. 이벤트 기반 아키텍처와 RSS 수집

아키텍처는 콘텐츠 수집과 후속 처리를 분리하는 이벤트 기반 패턴을 따르며, Amazon EventBridge 일정이 15분마다 RSS 동기화 Lambda 함수를 실행한다. 이 함수는 설정된 RSS 피드를 파싱하고 기본값 24시간인 조정 가능한 시간 범위 안에 게시된 문서를 선별한다. 각 URL의 해시를 고유 식별자로 사용하고 Amazon S3에 이미 존재하는지 확인함으로써 같은 문서를 다시 처리하지 않는다. 새 문서만 원격 브라우저 수집 단계로 넘기기 때문에 비용이 큰 브라우저 세션의 불필요한 실행을 억제할 수 있다. 수집 단계와 처리 단계가 분리되어 여러 피드를 동시에 다루는 동안에도 후속 분석 작업은 별도의 속도로 확장될 수 있다.

4. AgentCore Browser를 이용한 동적 콘텐츠 확보

새 문서가 발견되면 Lambda 함수는 Amazon Bedrock AgentCore에서 원격 브라우저 세션을 열고 Playwright를 Chrome DevTools Protocol로 연결해 제어한다. 이는 Lambda 내부에서 실행되는 일반적인 헤드리스 브라우저가 아니라 AgentCore가 호스팅하고 WebSocket 연결을 통해 제어되는 관리형 브라우저 서비스다. 브라우저는 전체 페이지를 렌더링하고 자바스크립트와 동적 요소가 로드되기를 기다린 뒤 완성된 HTML, 화면 캡처, 페이지 이미지와 관련 메타데이터를 확보한다. 일반 HTTP 요청으로는 누락될 수 있는 동적 콘텐츠를 온전히 전달하는 것이 이후 AI 추출 품질을 좌우하므로 이 단계가 파이프라인의 기반이 된다. 수집 결과는 도메인과 URL 해시를 기준으로 S3에 정리되며, 메타데이터에는 원본 URL, 제목, 시각 정보, 다운로드한 자산 참조가 포함된다.

5. SQS 기반 처리 분리와 HTML 전처리

S3에 메타데이터 파일이 올라오면 업로드 이벤트가 Amazon SQS 큐에 메시지를 발행하고, 두 번째 Lambda 함수가 해당 메시지를 받아 원시 HTML을 처리한다. 큐를 사이에 두면 콘텐츠 수집 성공 여부와 AI 분석 성공 여부가 직접 결합되지 않으며, 처리 실패 시 자동 재시도할 수 있다. 데드레터 큐는 반복해서 실패한 작업을 별도로 보존해 문서가 아무 분석 없이 유실되는 상황을 줄인다. 분석 함수는 1MB를 넘는 큰 HTML에 html-to-text를 사용해 내용을 단순화하고, 더 작은 파일에는 본문과 대표 이미지를 잘 추출하는 Mozilla Readability를 적용한다. 원시 HTML을 그대로 모델에 보내지 않고 먼저 정제하면 토큰 사용량을 줄이는 동시에 AI 생성 결과의 일관성을 높일 수 있어, 글은 이 과정을 단순한 최적화가 아니라 신뢰할 수 있는 결과를 위한 전제 조건으로 평가한다.

6. AI 인사이트 추출과 의미 검색

정제된 콘텐츠는 사용자 정의가 가능한 프롬프트와 함께 Amazon Bedrock으로 전달되며, 모델은 간결한 요약, 핵심 주제, 주요 인물·기업·제품, 관련 범주, 실행 가능한 인사이트를 추출한다. 사용할 수 있는 모델은 AWS 리전에 따른 Amazon Bedrock 지원 범위 안에서 선택한다. 같은 처리 함수는 의미 검색에 사용할 벡터 임베딩도 생성하고, 원문과 AI 추출 메타데이터 및 임베딩 벡터를 Amazon OpenSearch Serverless에 함께 기록한다. 인덱스가 키워드 검색과 벡터 검색을 모두 지원하므로 정확한 표현이 포함된 자료뿐 아니라 용어가 달라도 개념적으로 가까운 콘텐츠를 찾을 수 있다. 예를 들어 새로운 디자인 동향을 묻는 검색은 원문에 질문과 동일한 단어가 없어도 의미적으로 관련된 결과를 반환할 수 있어 경쟁 정보와 시장 조사에서 탐색 범위를 넓힌다.

7. 책임 있는 AI 통제와 사용자 접근

외부 웹 콘텐츠가 기반 모델로 전달되고 생성된 결과가 조직 내부에 게시되므로, 운영 환경에서는 원문과 생성 결과 사이에 통제 지점을 마련해야 한다. Amazon Bedrock Guardrails의 콘텐츠 필터링은 수집된 페이지에 포함된 유해하거나 부적절한 자료가 검색 인덱스로 넘어가는 것을 차단하고, 금지 주제와 단어 필터는 결과 범위를 팀의 기대에 맞게 제한한다. 문맥 근거성 검사는 요약과 인사이트가 원문에 근거하는지 확인해 생성된 주장이 사실처럼 색인될 위험을 낮춘다. 사용자는 Amazon Cognito 인증이 적용된 React 기반 화면에서 결과를 탐색하고 검색하며, 다른 AI 도구는 Amazon CloudFront를 통해 공개되는 MCP 서버로 프로그래밍 방식의 검색과 조회를 수행한다. 처리 구성요소는 Amazon VPC 안에서 실행되고 Amazon CloudWatch가 관측성을 제공하며, IAM은 최소 권한 원칙에 따라 접근을 통제한다.

8. 비용·신뢰성의 교훈과 정리 절차

테스트에서 AgentCore Browser를 통한 Playwright 렌더링은 한 건당 10~30초가 걸렸고 일반 HTTP 요청보다 비용이 상당히 높았으므로, S3 확인과 URL 해시를 이용한 중복 제거가 대규모 운영의 핵심 비용 통제로 제시된다. 그 대신 일반 스크래퍼가 처리하지 못할 페이지를 안정적으로 수집할 수 있어 후속 분석이 완전한 입력을 받는다는 이점이 있다. SQS와 데드레터 큐는 처리 실패를 재시도하게 해 신뢰성을 높이고, 벡터 임베딩은 단어 일치에 제한되지 않는 검색을 가능하게 한다. Amazon OpenSearch Serverless는 사용량과 무관한 최소 용량 비용이 있으므로 지속적인 질의량이 있는 운영 환경에 적합하며, 처리량이 적다면 더 낮은 기본 비용으로 벡터 검색을 제공하는 Amazon RDS와 pgvector를 출발점으로 고려할 수 있다. 실습 후 지속적인 요금을 피하려면 S3 콘텐츠 버킷을 비우고 프로젝트 디렉터리에서 cdk destroy를 실행하거나 생성한 스택을 삭제해야 한다.

🧾 핵심 주장 / 시사점

• 수집 정확도가 후속 AI 분석의 상한을 결정하므로, 동적 페이지를 안정적으로 렌더링하는 브라우저 단계는 부가 기능이 아니라 전체 파이프라인의 품질 기반이다.
• 비용이 큰 브라우저 실행 전의 URL 중복 확인, 모델 호출 전의 HTML 정제, 처리 실패 전후의 큐 분리는 각각 비용·출력 품질·신뢰성을 담당하는 핵심 경계다.
• 검색 저장소는 기능만으로 선택하기보다 예상 질의량과 최소 운영비를 함께 비교해야 하며, 일관된 운영 부하에는 OpenSearch Serverless가, 저용량 시작 환경에는 RDS와 pgvector가 대안이 될 수 있다.

✅ 액션 아이템

• RSS 수집 주기를 15분 단위로 두고 URL 해시·S3 존재 여부로 신규 문서만 판별해 브라우저 렌더링 중복을 줄인다.
• S3 업로드와 SQS로 수집·AI 처리를 분리하고 재시도·데드레터 큐를 둬 분석 실패가 전체 파이프라인을 막지 않게 한다.
• Bedrock 추출 요약·주제·엔터티·인사이트와 임베딩을 OpenSearch Serverless에 같이 색인해 키워드·의미 검색 기준을 정의한다.

❓ 열린 질문

• 브라우저 세션 비용 대비 어떤 출처·문서에만 AgentCore Browser 렌더링을 적용할 것인가?
• 생성 요약과 실행 가능 인사이트의 근거성을 원문 HTML·메타데이터와 어떻게 대조·통제할 것인가?
• 저용량 운영에서 OpenSearch Serverless 최소 고정 비용이 키워드·벡터 검색 이득을 상쇄하지 않는 임계는 어디인가?