AWS 에이전트가 한 번에 출처까지 붙여 준 답변, 링크를 열면 근거가 있을까?

고객이 특정 소프트웨어 버전에 보안 업데이트가 아직 제공되는지 묻습니다. 지원 에이전트는 확신에 찬 답변을 내놓고 제조사 문서의 링크를 붙입니다. 링크는 잘 열리고 공식 도메인도 맞습니다. 그런데 그 문서는 최신 버전을 설명하고, 고객이 쓰는 것은 이전 버전입니다.

AWS는 2026년 11월 5일 Amazon Bedrock AgentCore에서 Web Answer를 정식 출시했습니다. Bedrock AgentCore는 AI 에이전트를 실행하고 다른 시스템에 연결하는 AWS 인프라입니다. 새 관리형 커넥터는 도구를 한 번 호출하면 공개 웹을 검색하고, 관련 페이지를 읽고, 출처를 붙인 답변을 작성합니다. AWS 문서에 안내된 리전은 미국 동부 버지니아 북부, 즉 us-east-1입니다. 각 단계를 따로 만들던 팀은 구현 부담을 덜 수 있습니다. 고객에게 답을 보내기 전 살펴볼 결과물도 한 번에 얻습니다. AWS 출시 및 사용 가이드 · AWS 커넥터 문서

버전별 지원 여부, 출시일, 개정된 지침은 이런 도구를 시험하기 좋은 주제입니다. 맞는 자료를 찾으면 실용적인 답을 얻을 수 있습니다. 반대로 주제는 비슷하지만 다른 주장을 뒷받침하는 페이지를 검색 결과로 받기 쉽습니다. 답과 근거가 실제로 어떻게 이어지는지 확인해 봅시다.

2020년 미국 버지니아주 애슈번에서 촬영한 AWS 데이터센터 건물. 지역의 맥락을 보여주는 사진입니다. Vahurzpu 촬영, 잘라내고 크기 조정, CC BY-SA 4.0. 이미지 출처 · 라이선스.

도구 한 번 호출로 여러 단계를 처리합니다

AWS는 관련 커넥터를 두 가지 제공합니다. Web Search Tool은 제목, 링크, 요약문, 게시일 같은 정보와 함께 순위를 매긴 검색 결과를 반환합니다. 어떤 결과를 읽고 어떻게 답변을 만들지는 호출하는 쪽에서 정합니다. Web Answer는 자연어 질문을 받아 검색을 계획하고, 관련 페이지를 읽고, 답변과 출처를 돌려줍니다. 팀이 어느 단계까지 직접 운영할지 정할 때 이 차이가 중요합니다. AWS Web Answer와 Web Search 비교

고객 지원 절차의 일부로 사실관계 하나를 확인해야 한다면 답변 생성까지 맡겨 중간 단계를 줄일 수 있습니다. 모델에 검색 요약문 스무 개를 주고 고르게 하는 대신, 특정 버전이나 정책에 관한 진술과 그 출처를 요청할 수 있습니다. 반면 검토자가 서로 다른 문서를 비교하거나, 어떤 결과가 나왔는지 두루 살피거나, 특정 출처가 왜 우선인지 설명해야 한다면 검색 결과를 직접 보는 편이 판단 과정을 확인하기 쉽습니다. 같은 앱에서도 질문에 따라 두 경로를 쓸 수 있습니다.

같은 고객 지원 업무에 검색을 활용하는 두 가지 방법. Web Search 경로에서는 자료 읽기와 답변 작성이 호출자에게 남습니다. Telli.sh 자체 제작.

커넥터는 AgentCore Gateway에서 Model Context Protocol 도구로 제공됩니다. AWS 문서에는 텍스트와 구조화된 답변 목록을 포함한 결과 형식이 나와 있습니다. 각 답변 블록에는 별도의 인용을 넣을 수 있으며, 가능한 경우 URL과 도메인이 제공됩니다. 도구에서 오류가 나면 응답에 isError가 표시됩니다. AWS는 Web Answer 결과를 최종 사용자에게 보여주는 앱에 원래 인용과 링크를 보존하고 표시하라고 요구합니다. 화면에서도 답변 블록과 해당 인용의 연결을 유지하세요. 출처를 구분 없이 하단에 모으면 근거가 붙어 있는 것처럼 보이더라도 검토하기 어렵습니다. AWS 응답 형식과 허용 사용 기준

질문에 범위를 지정합니다

가상의 소프트웨어 업체 ExampleSync를 생각해 봅시다. 고객은 독일에서 표준 지원 플랜으로 ExampleSync Server 4.2를 사용한다고 합니다. 문의 시점을 기준으로 이 버전과 플랜에 보안 업데이트가 제공되는지 물으면 유용합니다. 적용되는 지원 수명주기 문구, 출처 URL, 적용 날짜를 요청하고, 인용한 페이지가 다른 제품이나 에디션을 설명한다면 명시하도록 합니다. 고객 이름, 계정 번호, 라이선스 키, 비공개 서신은 필요하지 않습니다.

이렇게 질문하면 지원 결정을 내리는 단계와 근거를 요청하는 단계가 분리됩니다. “이 고객에게 지원 대상이라고 말해도 될까요?”라고 물으면 시스템이 계약 관계 전체를 판단하려 할 수 있습니다. 특정 릴리스에 대해 공개된 지원 수명주기를 물으면 검토자가 확인할 대상이 명확해집니다. 공개 일정에 개별 유지보수 계약 내용이 없다면, 남은 결정은 계약 담당 경로에서 확인하도록 안내할 수 있습니다.

현재 커넥터 문서에는 버전 1.1.0 이상에서 도메인 제한, 게시일 필터, 국가 힌트를 설정할 수 있다고 나옵니다. 에이전트가 제조사의 문서와 지원 사이트를 포함하도록 지정할 수 있습니다. AWS는 대상별 도메인 설정도 안내합니다. 검색 범위를 사용자 프롬프트에만 맡기지 않고 게이트웨이에서 적용할 수 있습니다. 국가 설정은 검색 결과를 좁혀 줍니다. 지역에 따라 답이 달라질 때는 결과가 해당 지역이나 계약에 실제로 적용되는지 확인해야 합니다. AWS 필터 설정과 입력 형식

도메인을 좁히면 재게시 문서를 피하기 쉽지만, 업체가 여러 사이트에 자료를 나눠 올리면 결과가 빠질 수 있습니다. 게시일 필터를 좁게 설정하면 2년 전 문서가 지금도 유효한데도 놓칠 수 있습니다. 반대로 최신 페이지가 아직 적용되지 않은 날짜를 설명할 수도 있습니다. 페이지 게시일, 명시된 적용일, 확인일을 따로 다루세요. 결과가 충돌하면 서로 다른 출처를 보존하고, 어떤 것이 적용되는지 사람이 판단할 수 있게 합니다.

인용 링크를 열어 근거 문장까지 확인합니다

지원 업무에서 인용은 근거의 위치를 가리킵니다. 우선 답변을 좌우하는 주장에 달린 페이지를 엽니다. 문서 제목과 언어가 적절한지 확인하고 해당 구절을 찾습니다. 제품명, 버전, 에디션, 지역이 일치해야 합니다. 답변에 날짜가 있다면 날짜를 명시한 문장이나 표를 읽습니다. 지원 종료 정책을 일반적으로 설명한 문서는 내용이 정확하더라도 특정 버전의 종료일을 확인해 주지 못할 수 있습니다.

검토자는 답변을 어떻게 사용할지 결정하기 전에 실제 근거 구절과 적용 범위를 확인합니다. Telli.sh 자체 제작.

예를 들어 결과는 4.2 버전에 12월까지 보안 업데이트를 제공한다고 답합니다. 출처는 제조사의 지원 수명주기 페이지이지만, 표에는 표준 지원과 연장 지원이 별도 행에 있습니다. 표준 지원은 9월에 끝나고 연장 지원은 12월에 끝납니다. 링크가 잘 열리고 인용한 날짜가 페이지에 있어도 검토자는 이 차이를 찾아야 합니다. 검토 화면에서 해당 인용을 문제의 주장에 붙여 두고 플랜이 다르다는 점을 쉽게 표시할 수 있어야 합니다.

때로는 질문에 필요한 구분이 빠져 있습니다. 사용자가 에디션을 알려 주지 않았다면 확인 질문이 가장 안전할 수 있습니다. 근거가 불완전한 경우도 있습니다. 제품 소개에 기능이 어느 버전에 적용되는지 나오지 않거나, 릴리스 노트가 시험 환경 배포만 언급하고 정식 출시 여부를 밝히지 않을 수 있습니다. 확인한 내용과 아직 알 수 없는 내용을 화면에서 구분하면 사용자가 설명 없는 링크를 하나씩 해석할 필요가 줄어듭니다.

정답이 불확실한 질문에서도 같은 과정을 시험해 보세요. 예를 들어 지원 일정에 없는 버전에 대해 묻습니다. 공개 문서에서 지원 상태를 확인할 수 없다는 설명과 도움이 되는 다음 조치가 기대 결과입니다. 답을 만들어 내는 능력과 답변을 보류할 상황을 알아보는 능력을 함께 평가할 수 있습니다.

첫 연동은 측정하기 쉽게 설계합니다

1. 문서에 지정된 리전의 테스트 게이트웨이를 사용합니다. AWS 가이드에 따라 Web Answer를 연결하고, 게이트웨이 서비스 역할에 커넥터 호출에 필요한 권한을 줍니다. 호출자에는 테스트에 맞는 별도의 게이트웨이 호출 권한을 부여합니다. 과금 요청이 승인된 테스트 계정이나 격리 환경을 사용합니다. AWS 설정 가이드
2. 프롬프트를 다듬기 전에 작은 질문 세트를 만듭니다. 최신 자료로 답할 수 있는 질문, 관련은 있지만 오래된 자료가 나오는 질문, 플랜에 따라 답이 다른 질문, 출처가 충돌하는 질문, 공개 근거가 부족한 질문을 포함합니다. 각 경우에 적절한 답변이 어떤 동작을 해야 하는지 적어 둡니다.
3. 테스트 질문과 공개 문서로 시작합니다. 목적이 분명할 때만 도메인과 날짜 제한을 전달합니다. 구조화된 답변 블록을 살피고, 화면에 출처 링크를 유지하고, 검토자가 답변 문장과 원문을 대조할 수 있게 합니다.
4. 현재의 수동 절차나 순위 기반 검색 커넥터와 비교합니다. 근거가 확인된 주장, 타당하게 보류한 답변, 검토자가 다시 열어 본 질문의 수를 기록합니다. 가능하면 질문 접수부터 최종 승인까지 시간을 재서 사람이 검토하는 비용도 반영합니다.
5. 도구 오류, 출처 누락, 시간 초과에 대비한 대체 절차를 정합니다. 지원 담당자가 공식 문서를 열거나 동료에게 사례를 넘길 수 있게 합니다. 원인 분석용 코드에는 필요한 이유만 기록하고, 원본 티켓에는 조직의 보존 및 접근 규칙을 적용합니다.

AWS의 11월 5일 가이드에 따르면 Web Answer는 도구 호출 1,000회에 10달러입니다. 그 예시 단가에서는 100회가 1달러, 250회가 2.50달러입니다. 게이트웨이 사용량과 호출하는 에이전트의 모델, 재호출 비용은 별도로 고려해야 합니다. 고객 지원에서 비교할 단위는 검증을 마치고 실제로 쓸 수 있는 답변 한 건입니다. 짧은 답이라도 세 번 고치고 몇 분간 출처를 수동으로 확인해야 한다면, 늦게 나와도 한 번의 검토로 승인되는 답보다 운영비가 더 들 수 있습니다. AWS 가이드의 가격 안내

사용 범위를 확대하기 전에 걸린 시간과 자주 발생한 실패 원인을 기록합니다. 에디션이 달라서 실패하는 경우가 많다면 질문 양식에 에디션 항목을 추가합니다. 오래된 페이지가 문제라면 업체의 기준 정책이 무엇이고 변경이 어디에 게시되는지 확인합니다. 유용한 출처가 허용 목록 밖에 자주 있다면 지원 업무 담당자와 게이트웨이 정책을 조정합니다. 원인에 따라 필요한 조치가 달라집니다.

답이 명확한 질문과 출처가 충돌하는 질문의 결과를 나눠서 비교하세요. 평범한 질문 19개가 즉시 승인되지만 20번째 질문에 서로 다른 지역의 정책 두 개가 섞인다면, 평균만으로는 검토자가 어디에 시간을 쓰는지 알기 어렵습니다. 각 건이 검토로 넘어간 이유와 처리 시간을 기록합니다. 커넥터 설정을 바꾼 뒤에도 같은 사례를 사용합니다. 수정된 정책으로 바로 쓸 수 있는 답변이 늘어나면서도 불확실한 사례는 적절한 담당자에게 전달되는지 확인하기 위해서입니다.

실질적으로 절약할 수 있는 시간은 범위가 분명한 질문을 던진 뒤 검토자가 바로 확인할 근거를 받기까지 걸리는 시간입니다. AWS는 검색과 답변 생성을 한 요청에 묶습니다. 어떤 근거를 인정할지 정하고 직원이 그 근거를 직접 열어볼 수 있게 할 때 지원팀에 가치가 생깁니다.

출처

• 2026년 11월 5일 AWS 정식 출시 발표
• 2026년 11월 5일 AWS Web Answer 사용 가이드 및 공개 데모
• AWS Web Answer 커넥터, 필터, 응답 형식 및 허용 사용 기준
• AWS Web Search Tool 커넥터
• Vahurzpu가 촬영한 참고 사진, CC BY-SA 4.0

---

지원 과정에서 나온 질문과 출처 확인, 결정을 검색할 수 있게 정리하려면 Telli.sh 계정을 만들어 보세요.