Build a daily dependency watcher with LangGraph and Amazon Bedrock AgentCore web search

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS는 Amazon Bedrock AgentCore Web Search API와 LangGraph로 검색 규칙을 코드에서 강제하고, 출처 검증과 중복 제거를 거쳐 새 보안 정보를 보고하는 일일 의존성 감시 구현을 소개한다.

📌 핵심 요약

• Amazon Bedrock AgentCore Web Search API는 기존 AWS 자격 증명으로 서명한 요청을 받아 Amazon이 운영하는 웹 인덱스에서 최신 결과를 제공하며, 쿼리를 제3자 검색 엔진으로 보내지 않는다. 결과에는 제목·URL·게시일·관련 발췌문이 포함되고, 도메인과 게시일 범위 필터를 지원한다.
• 예제는 LangGraph에서 npm, PyPI, 컨테이너 베이스 이미지의 세 조사 분기를 병렬 실행한다. 날짜 범위·차단 도메인·검색 예산은 코드로 통제하며, 분기당 최대 4회, 실행당 최대 12회 검색한다.
• 근거 검사는 인용 URL의 검색 결과 포함 여부, 출처의 패키지명 언급, CVE 또는 권고 ID의 일치, 게시일의 감시 범위 포함 여부를 확인한다. 심각도·악용 여부·영향 버전·권고 조치와 최초 공개 시점은 검증하지 않으므로, 운영 보안 업무에는 권위 있는 취약점 피드 대조와 조치 전 사람의 검토가 필요하다.
• 7일 범위의 시험 실행에서 12회 검색으로 출처 80개를 확보했고, 세 분기의 병렬 실행은 36초로 순차 실행 기준 99초보다 짧았다. 근거 검사에서 발견 사항 2개가 탈락하고 4개가 통과했으며, 기존 보고를 제외한 2개만 새로 보고됐다. 두 번째 실행에서는 새 보고가 없었다.
• keep_new는 LangGraph store를 조회해 중복 보고를 막는다. 예약 실행에는 InMemoryStore 대신 DynamoDBStore 같은 영속 저장소를 사용하도록 안내하며, 모든 에이전트가 공유하는 Web Search 기본 할당량은 계정당 리전별 초당 10개 요청이다.

🧩 주요 포인트

1. 모델은 검색어와 발견 사항을 작성하고 코드는 날짜 범위·차단 도메인·검색 예산을 강제하므로, 조사 자율성과 운영 제약을 분리할 수 있다.
2. 출처 대조는 근거 없는 URL·패키지·식별자와 기간 밖 자료를 걸러내지만 보안 판단 전체를 보증하지 않으므로, 심각도·악용 여부·권고 조치에는 추가 검증이 필요하다.
3. LangGraph 병렬 실행은 조사 시간을 줄이고 keep_new는 반복 보고를 줄이지만, 지속 운영에는 영속 저장소와 계정당 리전별 초당 10개 요청의 공유 할당량을 함께 고려해야 한다.

🧠 상세 정리

1. 최신 웹 검색과 AWS 기반 접근 제어

보안 권고, 제품 출시, 가격, 규제처럼 오늘 달라진 정보를 다루는 에이전트는 모델의 학습 데이터만으로 답할 수 없어 웹 검색이 필요하다. 원문은 운영 환경에서 최신성뿐 아니라 인용 가능한 결과, 인정할 출처에 대한 통제, 내부 업무를 드러낼 수 있는 검색어의 처리 방식도 중요하다고 설명한다. Amazon Bedrock AgentCore Web Search API는 기존 AWS 자격 증명으로 서명한 단일 API 호출을 통해 Amazon이 운영하는 웹 인덱스를 검색하며, 쿼리를 제3자 검색 엔진으로 전달하지 않는다. 각 결과에는 페이지 제목, URL, 게시일, 검색어와 관련된 발췌문이 포함되고, 요청에서 도메인을 포함하거나 제외하고 게시일 범위를 제한할 수 있다. AWS Lambda, Amazon ECS, AgentCore runtime에서는 실행 역할로 호출하므로 별도의 검색 API 키를 저장하거나 교체할 필요가 없으며, AgentCore Gateway를 통하면 관리자의 하나의 출처 정책을 모든 에이전트와 MCP 클라이언트에 적용할 수 있다.

2. 실행 환경과 필요한 권한

예제를 실행하려면 Web Search API를 제공하는 AWS 리전의 계정, Python 3.10 이상, 노트북 실행 주체의 AWS 자격 증명이 필요하며, 원문은 미국 동부 버지니아 북부 리전인 us-east-1을 사용한다. 해당 주체에는 웹 검색 IAM 권한과 Amazon Bedrock의 Anthropic Claude 모델 접근 권한이 있어야 하고, 자격 증명은 환경 변수나 AWS CLI 프로필에서 가져올 수 있다. 패키지의 최소 버전은 boto3 1.43.127, bedrock-agentcore 1.26.0, langchain-aws 1.9.3이며, langchain과 langgraph도 설치한다. 검색 권한은 AWS 소유의 웹 검색 도구 리소스에 대한 bedrock-agentcore:InvokeWebSearch 작업으로 부여하며, Gateway 서비스 역할도 같은 권한을 사용한다. Web Search와 모델 호출은 사용량에 따라 과금되고 예제의 한 번 실행은 최대 12회 검색하므로, 실행 환경과 권한뿐 아니라 검색 횟수의 상한도 설정 단계에서 명시된다.

3. 모델이 바꿀 수 없는 검색 규칙

각 조사 분기는 create_web_search_toolkit으로 자체 검색 도구를 만들고, 코드에서 정한 차단 도메인과 감시 시작일을 모든 검색 요청에 붙인다. 예제는 exclude_domains에 BLOCKLIST를, published_after에 감시 시작 시각을 지정하고, model_filters=False, max_searches=4, return_sources=True를 설정한다. model_filters=False이면 모델에는 검색어 인자만 노출되며, 도구는 검색 네 번을 수행한 뒤 추가 검색을 중단한다. 반환값은 모델이 읽는 텍스트와 그래프가 검사할 수 있는 출처 데이터 형태의 아티팩트로 제공되므로, 생성된 설명과 실제 검색 근거를 코드에서 대조할 수 있다. Gateway 인자를 지정하지 않은 도구는 Web Search API를 직접 호출하며, 각 분기가 별도의 툴킷을 가지므로 서로 병렬로 검색할 수 있다. 같은 도구를 Deep Agents의 하위 에이전트에 전달할 수도 있고, 고정 규칙이 있는 경우 모델이 전달하는 필터 인자는 그 범위를 더 좁힐 수만 있다.

4. 세 생태계의 병렬 조사와 구조화된 결과

감시는 감시 대상 목록과 시간 범위를 입력받아 시작하고, fan_out이 LangGraph의 Send API로 npm, PyPI, 컨테이너 베이스 이미지에 각각 하나의 조사 분기를 보낸다. 각 분기의 에이전트는 Amazon Bedrock의 Anthropic Claude 모델을 호출해 검색어를 결정하고, 검색 도구와의 상호작용을 반복한 뒤 발견 사항을 구조화해 반환한다. 분기는 create_agent와 Pydantic 응답 스키마를 사용하므로 자유 형식의 산문 대신 정해진 필드를 갖춘 결과를 만든다. 발견 사항에는 패키지, 한 줄 제목, 출처가 제공한 CVE 또는 권고 ID, 출처에 명시된 심각도와 악용 여부, 권고 조치, 출처 URL이 들어간다. 각 분기는 반환 직전에 근거 검사를 통과한 항목만 남기고, 세 분기가 모두 끝나면 LangGraph가 결과를 합쳐 keep_new를 한 번 실행한다. 마지막 report 단계는 이미 보고된 항목을 제외한 새 발견 사항을 출처가 연결된 표로 구성해 보안팀에 제공한다.

5. 근거 검사의 범위와 보안 판단의 한계

각 분기의 근거 검사는 그 분기가 직접 검색해 받은 자료와 발견 사항을 비교하는 네 가지 조건으로 구성된다. 인용 URL이 검색 결과에 실제로 있었는지, 출처 제목이나 본문이 패키지명을 완전한 단어로 언급하는지, 발견 사항의 CVE 또는 권고 ID가 해당 텍스트에 나타나는지, 게시일이 감시 범위 안에 있는지를 확인한다. 아티팩트에는 이미 파싱된 날짜가 담겨 있고, 날짜가 없으면 범위 밖으로 처리하므로 출처의 시간 조건도 코드로 적용된다. 이 검사는 근거 없는 URL, 패키지를 언급하지 않는 출처, 만들어 낸 식별자, 기간 밖 자료를 걸러내지만 심각도, 악용 여부, 영향 버전, 권고 조치까지 확인하지는 않는다. 또한 인덱스가 이번 주 게시물로 표시한 페이지가 오래된 사건을 설명할 수 있으므로 최초 공개 시점을 증명하지도 않는다. 따라서 원문은 운영 보안 업무에서 권위 있는 취약점 피드와 발견 사항을 대조하고, 실제 조치에 앞서 사람이 검토하도록 명시한다.

6. 7일 감시 범위에서 확인한 실행 결과

원문의 시험은 7일 감시 범위로 실행됐으며, 세 조사 분기가 합계 12회 검색해 출처 80개를 받았다. 병렬 실행의 실제 경과 시간은 36초였고, 분기들을 순차로 실행했을 때의 비교 기준은 각 분기의 시간을 합친 99초였다. 근거 검사는 두 발견 사항을 제외했는데, 하나는 출처가 패키지를 언급하지 않았고 다른 하나는 발견 사항의 CVE ID가 해당 출처에 없었다. 반환된 출처 중 차단 도메인에 속하는 것은 없었으며, 네 발견 사항이 검사를 통과한 뒤 keep_new가 그중 두 개만 새로 보고했다. 나머지 두 개는 앞선 시험 실행에서 이미 보고돼 저장소가 다시 내보내지 않았고, 원문은 LangGraph Studio에서 병렬 분기와 결과를 확인한 모습을 제시한다. 최종 보고의 모든 행은 출처로 연결되며, 이는 사용자에게 표시하는 출력에 출처 링크를 요구하는 Web Search 이용 조건과도 연결된다.

7. 재실행의 중복 제거와 영속 저장

일일 예약 감시는 같은 보안 권고를 매번 반복해서 보여 주지 않아야 하므로, 검색 결과의 근거 검사 뒤에 별도의 중복 제거 단계가 배치된다. keep_new는 검사를 통과한 발견 사항을 LangGraph store와 비교하고 새 항목을 기록해, 이전에 보고한 항목이 다시 보고되지 않도록 한다. 같은 입력으로 두 번째 실행을 했을 때 분기들은 다시 검색했고 두 발견 사항을 유지했지만, 두 항목 모두 저장소에 이미 보고 이력이 있어 최종 보고에는 새 항목이 없었다. 이 결과는 중복 제거가 검색 자체를 생략하는 방식이 아니라, 매 실행의 조사 결과에서 기존 보고를 제외하는 방식임을 보여 준다. 원문은 예약 작업에 사용할 때 InMemoryStore를 정확한 키 조회를 지원하는 영속 저장소로 교체하도록 안내하며, 예로 langgraph-checkpoint-aws의 DynamoDBStore를 제시한다.

8. 기존 앱 통합과 운영 확장 시 고려사항

기존 LangChain 앱에 검색을 추가할 때는 현재 실행 주체나 실행 역할에 검색 권한을 부여하고, Web Search API를 지원하는 리전을 툴킷에 지정하면 되며 이 리전은 모델이나 앱의 다른 부분과 달라도 된다. 도구의 기본 이름은 web_search이므로 기존 도구와 이름이 겹치면 변경하고, 서로 다른 규칙이나 예산이 필요한 에이전트와 분기에는 각각 툴킷을 만든다. 모든 에이전트가 계정의 검색 할당량을 공유하므로 병렬 분기의 요청을 합산해야 하며, 기본 한도는 계정당 각 리전에서 초당 10개 요청이다. Deep Agents에서는 create_deep_agent로 모델, 도구, 시스템 프롬프트, 하위 에이전트를 구성하고 연구용 하위 에이전트의 도구 목록에 검색 도구를 전달하되, 검색 규칙은 매 호출에 적용되는 툴킷 옵션으로 설정한다. 출처 대조는 에이전트 출력에 적용하거나 미들웨어로 추가할 수 있고, 원문의 시험에서는 조정 에이전트가 연구 하위 에이전트에 위임해 약 1분 만에 인용을 포함한 답변을 반환했다. 도입부는 AgentCore runtime 실행과 Gateway를 통한 팀 간 제공도 예고하지만, 제공된 본문은 운영 배포 절의 시작에서 끊겨 해당 절차의 구체적인 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 검색 규칙과 예산을 코드에 두고 모델에는 검색어 결정을 맡기는 구조는, 모델의 조사 능력을 활용하면서도 모든 검색에 동일한 제약을 적용하는 방식이다.
• 출처 링크와 식별자가 일치한다는 사실만으로 심각도나 권고 조치의 정확성이 보장되지는 않는다. 이 예제의 근거 검사는 보안 판단을 위한 일부 조건을 확인하는 단계로 해석해야 한다.
• 36초의 병렬 실행 결과와 중복 없는 재보고는 서로 다른 구성 요소에서 나온 효과다. LangGraph의 병렬 분기는 시간을 줄이고, LangGraph store와 keep_new는 보고 이력을 관리한다.

✅ 액션 아이템

• npm, PyPI, 컨테이너 베이스 이미지 조사에 날짜 범위·차단 도메인·분기당 최대 4회 검색 예산을 코드로 적용.
• 근거 검사를 통과한 발견 사항도 권위 있는 취약점 피드와 대조하고, 심각도·악용 여부·권고 조치는 조치 전 사람의 검토를 거침.
• 예약 실행에는 DynamoDBStore 같은 영속 저장소를 적용하고, 병렬 검색량을 계정당 리전별 초당 10개 요청의 공유 할당량과 대조.

❓ 열린 질문

• 근거 검사가 확인하지 않는 심각도·악용 여부·영향 버전·권고 조치는 권위 있는 취약점 피드와 사람의 검토를 통해 어떻게 검증할 것인가?
• 여러 에이전트가 동시에 검색할 때 계정당 리전별 초당 10개 요청의 공유 할당량 안에서 병렬 분기의 요청을 어떻게 배분할 것인가?
• InMemoryStore를 DynamoDBStore 같은 영속 저장소로 바꾼 예약 실행에서 keep_new의 중복 보고 방지가 유지되는지 어떻게 확인할 것인가?