How an AWS team detects dashboard content failures at scale using Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS 팀은 Amazon Bedrock 기반의 시각 분석과 결정론적 수치 비교를 결합해 수백 개 대시보드의 콘텐츠 오류를 검증하고, 탐지 시간을 최대 72시간에서 1시간 미만으로 단축했다.

📌 핵심 요약

• 인프라와 데이터 파이프라인이 정상이어도 대시보드에는 빈 차트, 오래된 데이터, 잘못된 수치가 나타날 수 있으며, 자동 모니터링으로 30일간 발견한 콘텐츠 오류 802건 중 사용자 신고가 동반된 비율은 1% 미만이었다.
• AWS 팀은 Amazon Quick 기반 AWS Insights의 수백 개 대시보드를 대상으로 콘텐츠 검증을 구축했으며, 평균 탐지 시간을 최대 72시간에서 1시간 미만으로 단축했다.
• 검증 구조는 등록·일정 관리, 화면 캡처, AI 분석, 알림 전달, 관측 데이터 저장의 5단계이며, 시각 검증은 매시간, 수치 검증은 주간 데이터 갱신 시 실행된다.
• Amazon Bedrock의 모델은 화면 이상 탐지와 지표 식별·값 추출을 수행하고, 결정론적 코드는 단위와 소수점 정밀도를 정규화해 수치 일치 여부를 판정한다. 모호한 시각 분석 결과와 수치 불일치는 사람이 검토한다.
• 운영 과정에서는 오탐 방지와 비교 규칙의 일관성을 중시했다. 수치 비교를 결정론적 코드로 교체한 뒤 모델 업그레이드로 추출 단계를 개선했으며, 재현율은 0.88에서 0.95로 높아졌다.

🧩 주요 포인트

1. 콘텐츠 오류 802건에 비해 사용자 신고는 1% 미만 → 인프라 상태와 신고만으로는 사용자 화면의 품질을 충분히 파악하기 어려움.
2. 시각 검증과 수치 검증의 병행 → 화면의 구조적 이상과 정상적으로 표시된 잘못된 수치를 별도로 점검해 표현 계층의 검증 공백을 보완.
3. Amazon Bedrock의 의미 해석과 결정론적 코드의 판정 분리 → 추출 정확도는 모델로 개선하면서 수치 비교 규칙의 일관성은 코드로 확보.

🧠 상세 정리

1. 정상 인프라에서도 발생하는 콘텐츠 오류

글은 중요한 회의 직전에 사용자가 대시보드를 열었지만 차트가 비어 있는 상황으로 문제를 설명한다. 서버가 가동되고 API가 응답하며 데이터 파이프라인이 예정대로 완료되어도, 사용자가 보는 화면의 콘텐츠는 손상될 수 있다. 표와 차트에는 빈 화면뿐 아니라 오래되거나 잘못된 데이터가 나타날 수 있으며, 원인으로는 상위 파이프라인 실패, 권한 변경, 일시적인 인프라 문제가 제시된다. 이러한 장애는 인프라 모니터링에 드러나지 않아 사용자가 직접 신고해야 발견되는 경우가 생긴다. 차트가 정상적으로 표시되더라도 수치 자체가 틀릴 수 있고, 그 데이터를 AI가 경영진용 설명에 사용하면 잘못된 수치가 의사결정에 쓰이는 인사이트로 이어질 수 있다.

2. 관측 결과로 드러난 표현 계층의 검증 공백

자동 모니터링 도입 후 30일간 수집한 데이터에서는 행 수준 데이터 권한 오류, 필터의 레코드 누락, 렌더링 문제 등을 포함해 콘텐츠 오류 802건이 확인됐다. 이 가운데 사용자 신고가 동반된 비율은 1% 미만이어서, 신고에 반응하는 지원 방식만으로는 상당수의 콘텐츠 저하를 파악하기 어려웠다. 수치 오류는 필터 설정, 집계 로직, 갱신 시점의 문제로 발생하며, 상위 단계의 검사가 통과한 뒤에도 최종 화면에 나타날 수 있다. Amazon CloudWatch Synthetics는 페이지 로딩과 링크 연결, 지연 시간 같은 엔드포인트 상태를 확인하고, 데이터 계층 검증은 상위 파이프라인의 문제를 점검한다. 이 솔루션은 두 검증 체계를 대체하지 않고, BI 표현 계층에서 실제 콘텐츠의 의미와 정확성을 확인하는 마지막 검증 단계를 보완한다.

3. 대시보드 소유자가 받는 알림과 검토 결과

솔루션은 Amazon Quick 기반 AWS Insights에 호스팅된 수백 개 대시보드를 동시에 검사하도록 구축됐다. 대시보드 소유자는 지표와 대시보드 비교 범위를 설정하며, 담당 영역에서 시각적 콘텐츠 오류가 발견되면 Slack 알림을 받는다. 알림에는 문제가 발생한 영역의 이름, 오류를 보여 주는 스크린샷, AI 신뢰도 점수, 조사에 사용할 모니터링 대시보드의 직접 링크가 포함된다. 수치 검증은 매주 데이터가 갱신될 때 실행되며, 사람이 읽을 수 있는 보고서로 결과를 제공하고 표시된 불일치 항목에 검토자의 주의를 집중시킨다. 검토를 통해 확인된 데이터 문제는 담당 팀으로 전달되며, 글은 이러한 자동 콘텐츠 감시를 통해 평균 탐지 시간이 최대 72시간에서 1시간 미만으로 줄었다고 설명한다.

4. 5단계 처리 구조와 화면 증거 수집

전체 처리 과정은 영역 등록과 일정 관리, 스크린샷 캡처, AI 분석, 알림 전달, 관측 데이터 저장의 5단계로 구성되며, 검증 주기 사이에는 사용량을 줄일 수 있는 서버리스 및 관리형 AWS 서비스를 사용한다. 첫 단계에서는 Amazon EventBridge가 매시간 시각 검증을 시작하고 주간 데이터 갱신이 수치 검증을 촉발하며, Amazon Redshift의 설정 레지스트리가 영역 식별자와 담당자, 실행 일정 정보를 관리한다. 시각 검증에서는 AWS Lambda가 헤드리스 브라우저 세션을 조정해 사용자가 보는 방식으로 각 대시보드 영역을 렌더링한다. 수치 검증의 기준값을 확보할 때는 화면을 여는 것만으로 부족하므로, 에이전트형 브라우저 자동화로 대시보드를 탐색하고 필요한 필터를 적용한다. 저장 전에는 Amazon Rekognition으로 탐지한 텍스트와 숫자를 마스킹용 문구와 합성 숫자로 대체하며, 스크린샷은 Amazon S3에 저장하고 Amazon CloudFront를 통해 분석 단계에 제공한다.

5. 시각 검증에서의 문맥 판단과 오탐 통제

시각 콘텐츠 검증은 각 스크린샷을 대시보드 영역의 문맥 메타데이터와 함께 한 번에 분석하는 방식으로 수행된다. Amazon Bedrock에서 제공되는 Anthropic Claude 모델은 빈 타일, 오류 상태, 누락된 시각 요소 같은 구조적 이상을 탐지한다. 가장 어려운 판단은 필터 조합에 해당하는 데이터가 실제로 없어 비어 있는 정상 상태와, 파이프라인 오류 때문에 차트가 비어 있는 장애 상태를 구분하는 일이다. 이를 위해 분석 전 스크린샷을 마스킹하고, 모델 출력은 자유 형식 설명 대신 신뢰도 점수가 포함된 구조화된 판정으로 제한하며, 모호한 결과는 자동 알림 대신 사람의 검토로 보낸다. 글은 오탐이 쌓이면 담당자가 알림을 신뢰하지 않게 된다고 지적하며, 매시간 실행되는 감시에서는 처리 속도보다 정확성과 설명 가능성을 우선하는 설계를 강조한다.

6. 수치 교차 검증에서의 모델과 코드 역할 분담

수치 교차 검증은 여러 대시보드에 표시된 동일 지표의 값이 서로 일관되는지를 확인한다. 같은 지표라도 화면마다 이름과 배치가 다를 수 있으므로, Amazon Bedrock의 LLM이 캡처된 화면에서 지정된 지표를 찾아 값과 단위를 읽고 비교할 값의 쌍을 구성한다. 반면 단위를 어떻게 맞출지, 어느 자리에서 반올림할지, 어떤 허용 오차를 적용할지는 모델이 일관되게 처리하지 못할 수 있어 결정론적 코드가 담당한다. 예를 들어 12억 달러와 1,200백만 달러처럼 표현 단위가 다른 값이나 58.484와 58.5처럼 소수점 정밀도가 다른 값을 정규화한 뒤 일치 또는 불일치 판정을 반환한다. 이 방식은 의미를 이해해야 하는 지표 식별과 정확한 규칙 적용이 필요한 비교를 분리하며, 검토자가 불일치 항목을 확인할 수 있도록 명확한 신호를 제공한다.

7. 담당자 전달과 운영 이력의 유지

알림 전달 단계에서는 시각적 오류가 확인되면 Slack Block Kit 형식의 알림을 생성해 등록된 영역 소유자에게 보낸다. 알림은 화면 증거와 신뢰도 점수, 조사 링크를 함께 제공하므로 담당자는 어떤 영역에서 어떤 문제가 관찰됐는지 확인할 수 있다. 장애가 지속되는 경우에는 시스템이 자동으로 티켓을 생성해 담당 팀으로 전달하며, 수치 불일치는 별도의 검증 보고서에 모아 사람이 검토하도록 한다. 마지막 단계에서는 분석 결과를 Amazon Redshift에 저장해 시간에 따른 추세와 반복적인 패턴을 분석할 수 있게 하고, Amazon CloudWatch로 모니터링 시스템 자체의 운영 지표를 수집한다. 따라서 화면의 이상을 탐지하는 단계뿐 아니라 책임자에게 증거를 전달하고 결과를 보존하는 과정까지 하나의 처리 흐름에 포함된다.

8. 운영에서 확인한 비교 일관성과 추출 정확도

초기 수치 검증은 한 LLM 에이전트가 값을 추출하고 비교한 뒤 다른 판정 에이전트가 독립적으로 확인하는 2단계 구조였으며, 두 에이전트 모두 계산기 도구를 사용할 수 있었다. 그럼에도 실제 운영에서는 단순 산술보다 반올림 시점, 허용 오차, 단위 차이의 처리에서 간헐적인 불일치가 나타났다. 비교 단계를 결정론적 코드로 교체하면서, 값이 올바르게 추출됐다는 조건 아래 비교의 정확성을 모델 성능에 의존하지 않고 확보하도록 바꿨다. 이후 모델 업그레이드는 추출 단계의 오독으로 인한 잘못된 경보를 줄였으며, 글은 재현율이 0.88에서 0.95로 높아졌다고 보고한다. 두 검증 방식의 공통 교훈은 보기·읽기·탐색처럼 의미 이해가 필요한 작업은 AI에 맡기고 정확한 판정 규칙은 코드로 처리하는 것이며, 제공된 원문은 마지막 운영 성과 항목 도중에 끝나므로 그 이후의 결과는 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 사용자 신고가 동반된 콘텐츠 오류가 1% 미만이라는 관측은, 신고 건수만으로 실제 대시보드 품질을 판단하기 어렵다는 점을 보여 준다.
• 정상적인 빈 화면과 실제 장애를 구분해야 하므로, 시각 검증의 신뢰도는 단순한 빈 영역 탐지뿐 아니라 문맥을 이해하는 능력에 달려 있다.
• 결정론적 비교도 값이 정확히 추출됐다는 조건이 필요하므로, 비교 규칙의 일관성과 모델의 추출 정확도는 각각 관리해야 하는 품질 요소다.

✅ 액션 아이템

• 콘텐츠 오류 802건과 사용자 신고 1% 미만의 관측을 근거로, 사용자 신고 중심 탐지의 한계 검토.
• 시각 검증과 수치 검증의 대상 및 실행 주기를 매시간·주간 데이터 갱신 구조와 대조해 검토.
• Amazon Bedrock의 지표 식별·값 추출과 결정론적 코드의 수치 판정을 분리하고, 모호한 결과와 수치 불일치는 사람 검토 대상으로 설정.

❓ 열린 질문

• 콘텐츠 오류 802건 중 사용자 신고가 동반된 비율이 1% 미만인 상황에서, 사용자 신고는 탐지 체계에서 어떤 역할을 맡아야 하는가?
• 시각 검증의 매시간 실행과 수치 검증의 주간 데이터 갱신 시 실행은 각각의 오류를 발견하는 데 충분한가?
• 재현율이 0.88에서 0.95로 높아진 뒤에도 Amazon Bedrock의 값 추출 오류가 수치 판정에 미치는 영향을 어떻게 확인할 것인가?