풀 스택 관측 가능성이란 무엇인가요?

풀 스택 관측 가능성은 외부 아웃풋, 특히 지표, 이벤트, 로그 및 추적(MELT)을 포함한 원격 측정 데이터를 기반으로 시스템의 내부 상태를 이해하는 기능인 관측 가능성을 기반으로 합니다.

기존의 관측 가능성은 개별 시스템 또는 애플리케이션에 대한 가시성을 제공하지만, 풀 스택 관측 가능성은 인프라 및 클라우드 네이티브 애플리케이션에서 사용자 경험에 이르기까지 기술 스택의 모든 계층에서 원격 측정 데이터의 상관관계를 분석합니다. 이 접근 방식을 통해 조직은 전체 IT 환경을 전체적으로 파악할 수 있습니다.

IT 환경이 더욱 복잡해짐에 따라 이러한 포괄적인 접근 방식은 점점 더 중요해지고 있습니다. 이제 많은 조직들은 여러 클라우드에서 수천 개의 마이크로서비스를 관리하고 있으며, 하나의 사용자 트랜잭션이 수십 개의 서로 다른 서비스에 영향을 미칠 수 있습니다.

하나의 서비스에 오류가 발생하면 시스템 전체에 장애가 발생할 수 있습니다. 기존의 모니터링 툴과 관측 가능성 솔루션은 서비스 간 상호 작용을 확인할 수 없기 때문에 이러한 연쇄적인 문제를 놓치는 경우가 많습니다.

풀 스택 관측 가능성은 원격 측정 데이터를 관측 가능성 데이터의 신뢰할 수 있는 단일 소스로 통합하여 이러한 사일로를 제거하는 데 도움이 됩니다. 성능 문제가 발생하면 팀은 전체 스택에서 문제를 추적할 수 있으므로, 인시던트 후 서비스를 복원하는 데 필요한 평균 시간인 평균 복구 시간(MTTR)을 크게 줄일 수 있습니다.

풀 스택 관측 가능성을 통해 조직은 애플리케이션의 성능을 최적화하고 근본 원인을 더 빠르게 식별하여 문제를 사전에 해결하고 시스템 안정성을 개선할 수 있습니다. 

모니터링, 관측 가능성, 풀 스택 관측 가능성은 조직이 IT 환경을 이해하는 방식이 발전했음을 나타냅니다. 각 접근 방식은 시스템 동작에 대한 점점 더 복잡해지는 질문에 답합니다.

"무슨 일이 일어나고 있나요?"

모니터링은 시스템이 임계값을 초과하면 사전 정의된 지표와 경고를 추적합니다. 또한 대시보드와 알림을 통해 CPU 사용량, 메모리 소비, 네트워크 지연 시간 등의 시스템 상태 지표를 파악합니다.

기존 모니터링은 시스템 성능에 대한 스냅샷을 제공하지만, 근본적인 원인에 대한 깊은 인사이트는 거의 제공하지 않습니다. 예를 들어, 모니터링은 응답 시간이 2초를 초과한다는 플래그를 지정할 수 있지만, 원인이 데이터베이스 쿼리, 네트워크 정체 또는 애플리케이션 코드인지 설명할 수는 없습니다.

애플리케이션 성능 관리(APM), 네트워크 성능 관리(NPM)과 같은 툴은 이러한 기능을 확장하지만, 여전히 전체 시스템이 아닌 특정 도메인에 초점을 맞춥니다.

"왜 이런 일이 발생하나요?"

관측 가능성을 통해 팀은 사전 정의된 쿼리 없이 시스템의 동작을 탐색할 수 있습니다. 또한 문제가 발생하면 지표, 로그 및 추적을 통해 조사를 제공합니다.

모니터링의 사후 대응 경고와 달리, 관측 가능성은 여러 기능을 제공합니다. 성능이 저하되면 팀은 요청을 추적하고, 로그를 검사하고, 패턴을 분석하여 특정 원인을 식별할 수 있습니다. 하지만 표준 관측 가능성은 일반적으로 개별 애플리케이션이나 서비스에 중점을 둡니다.

"모든 것이 어떻게 함께 작동하나요?"

풀 스택 관측 가능성은 계층 간에 데이터를 자동으로 상호 연관시키고 IT 환경 전반의 문제를 매핑하여 인과 관계를 파악할 수 있습니다.

주요 차이점은 범위 및 자동화입니다. 전자 상거래 사이트에서 결제가 실패하면 풀 스택 관측 가능성을 통해 전체 연결고리가 드러납니다. 즉, 프런트 엔드 오류가 발생하여 중복 API 호출을 유발하고, 인덱싱되지 않은 쿼리가 데이터베이스에 과부하를 일으키고, 시간 초과가 발생하여 수익에 영향을 미칩니다. 이러한 포괄적인 뷰를 통해 문제 해결을 몇 시간이 소요되는 조사에서 안내에 따른 몇 분만의 해결로 전환할 수 있습니다.

풀 스택 관측 가능성 플랫폼은 여러 시스템에서 실시간으로 원격 측정 데이터를 수집하여 기술 스택을 지속적으로 모니터링합니다. 에이전트, SDK 및 자동 계측을 통해 또는 기존 로그 및 지표 엔드포인트를 판독하여 데이터를 수집한 후 상관관계 파악을 통해 구성 요소 간의 관계를 매핑합니다.

최신 풀 스택 관측 가능성 플랫폼은 머신 러닝(ML)과 운영을 위한 인공 지능(AIOps)을 사용하여 최소한의 수동 구성으로 이상 징후를 자동으로 감지하고, 장애를 예측하고, 실시간 인사이트를 제공합니다.

풀 스택 관측 가능성 플랫폼은 지표, 이벤트, 로그 및 추적(MELT)의 네 가지 주요 원격 측정 데이터 유형을 수집합니다. 

지표는 시간 경과에 따른 애플리케이션 및 시스템 성능의 기본 측정값입니다. 지표는 CPU 사용량, 메모리 소비, 지연 시간, 처리량 및 기타 성능 지표를 추적하여 팀이 사용자에게 영향을 미치기 전에 성능 저하 및 용량 문제를 식별하는 데 도움을 줍니다.

일반적인 메트릭은 다음과 같습니다.

• 호스트 지표: 메모리,디스크 및 CPU 사용량
• 네트워크 지표: 가동 시간, 지연 시간, 처리량
• 애플리케이션 지표: 응답 시간 및 오류율
• 서버 풀 지표: 총 인스턴스, 실행 중인 인스턴스 수
• 외부 종속성 지표: 가용성, 서비스 상태

이벤트는 특정 시간에 발생하는 개별적인 발생입니다. 이를 통해 팀은 특정 시스템 변경 사항과 문제 간의 상호 관계를 파악하여 인시던트 타임라인을 설정할 수 있습니다.

예를 들면 다음과 같습니다.

• 배포 및 구성 변경: 코드 릴리스, 서버 다시 시작 또는 데이터베이스 업데이트
• 서비스 저하: API 속도 저하, 메모리 누수 또는 네트워크 정체
• 시스템 중단: 데이터베이스 장애 또는 완전한 서비스 사용 불가

로그는 세분화되고 타임스탬프가 찍힌 레코드를 생성하여, 문제 해결을 위한 컨텍스트와 함께 시스템 동작에 대한 정확한 뷰를 제공합니다. 예를 들어, 로그는 트랜잭션 실패로 이어진 데이터베이스 쿼리의 정확한 순서를 보여줄 수 있습니다.

추적은 프런트 엔드에서 전체 아키텍처를 거쳐 다시 사용자에게 돌아오는 사용자 요청의 엔드투엔드 경로를 매핑합니다. 예를 들어, 추적을 통해 송금 요청이 인증, 사기 탐지, 계정 검증 및 트랜잭션 처리 시스템을 통해 어떻게 이동하는지 확인할 수 있습니다.

각 여정이 여러 시스템을 거치기 때문에 추적은 풀 스택 관측 가능성에 필수적입니다.

MELT 데이터를 수집한 후 플랫폼은 의미론적 관계를 통해 전체 기술 스택에서 이러한 정보의 상관관계를 실시간으로 파악함으로써 컨테이너, 마이크로서비스, 데이터베이스와 같은 다양한 구성 요소가 상호 작용하는 방식을 이해합니다.

DevOps 팀, 사이트 안정성 엔지니어링(SRE) 팀, IT 직원을 포함한 조직 내 팀들은 문제의 '내용, 위치 및 이유'를 신속하게 식별하여 가능한 근본 원인을 정확하게 찾아내고 수동 조사를 크게 줄일 수 있습니다.

OpenTelemetry(OTel)는 공급업체에 구애받지 않는 원격 측정 수집을 위한 사실상의 프레임워크 및 에코시스템으로 부상했습니다. 이 오픈 소스 프레임워크는 소프트웨어 개발 키트(SDK), API, 그리고 대부분의 경우 소스 코드 수정 없이 원격 측정 수집을 가능하게 하는 자동 계측을 제공합니다.

조직들이 OTel을 사용하여 선택한 관측 가능성 플랫폼에 관계없이 풀 스택 가시성을 유지함에 따라 다중 공급업체 환경과 복잡한 분산 시스템에서 OTel의 중요성이 점점 더 커지고 있습니다.

풀 스택 관측 가능성은 몇 가지 핵심 기능을 통해 포괄적인 가시성을 제공합니다. 이러한 플랫폼에는 일반적으로 다음이 포함됩니다.

• 검색 및 매핑 자동화
• 근본 원인 분석
• 통합 대시보드
• 예측 최적화

풀 스택 관측 가능성 플랫폼은 새로 배포된 서비스를 자동으로 검색하고 모니터링을 시작하여 Kubernetes, AWS 및 기타 클라우드 환경 전반에서 관계 맵을 지속적으로 업데이트할 수 있습니다. 이 접근 방식을 사용하면 기존의 여러 모니터링 툴에 비해 수동 구성을 줄일 수 있습니다.

예를 들어, 온프레미스 데이터 센터에서 클라우드 환경으로 마이그레이션하는 동안 플랫폼은 새로운 클라우드 서비스를 자동으로 검색하고 전환 중에 두 환경 모두에서 가시성을 유지할 수 있습니다.

플랫폼은 모든 계층에 걸쳐 원격 측정 데이터의 상관관계를 파악함으로써 몇 시간이 아닌 몇 분 만에 자동화된 근본 원인 분석을 수행할 수 있습니다. 성능 문제가 발생하면 시스템은 원인이 애플리케이션 코드에 있는지, 네트워크 지연 시간인지, 인프라 문제인지 파악합니다.

이 플랫폼은 타사 결제 프로세서로 인한 지연 시간 증가를 정확히 찾아내어, 문제 해결을 탐정 수사 작업에서 안내에 따른 해결로 전환합니다.

대시보드는 원격 측정 데이터를 기술 및 비즈니스 이해관계자 모두를 위한 직관적인 시각화로 통합합니다. 이러한 인터페이스는 애플리케이션 성능을 모니터링하고, 디지털 경험을 추적하고, 비즈니스 KPI를 지속적으로 측정하여 모든 수준에서 실행 가능한 인사이트를 제공합니다.

예를 들어, 대시보드는 결제 실패가 2초를 초과하는 API 응답 시간과 상관관계가 있음을 보여줄 수 있으며, 이를 통해 팀은 해결의 우선순위를 정할 수 있습니다.

머신 러닝 모델은 과거 패턴과 이상 징후를 분석하여 용량 요구 사항을 예측하고, 리소스 할당을 최적화하고, 성능 문제가 발생하기 전에 예방하여 시스템 성능과 사용자 경험을 모두 개선합니다.

풀 스택 관측 가능성은 운영 효율성과 비즈니스 가치를 모두 높이는 포괄적인 가시성을 제공함으로써 조직의 복잡한 IT 환경 관리 방식을 혁신합니다.

풀 스택 관측 가능성은 평균 수리 시간(MTTR)을 몇 시간에서 몇 분으로 단축하여 다운타임을 줄이는 데 도움이 될 수 있습니다. 팀이 애플리케이션 로그, 네트워크 지표 및 데이터베이스 성능을 확인하여 각 계층을 개별적으로 조사하는 대신, 자동화된 상관관계 파악을 통해 근본 원인을 즉시 파악할 수 있습니다. 또한 문제가 메모리 누수, 네트워크 구성 오류 또는 데이터베이스 교착 상태로 인해 발생하는지 여부를 확인할 수 있습니다.

자동화 플랫폼 또는 런북과 통합되면 풀 스택 관측 가능성은 독립적으로 문제를 해결하는 자가 복구 치료를 트리거할 수 있습니다. 예를 들어, 메모리 소비가 임계값에 접근하면 시스템은 사용자가 영향을 받기 전에 자동으로 리소스를 확장하거나 서비스를 다시 시작할 수 있습니다.

풀 스택 관측 가능성은 최대 부하에 맞게 프로비저닝되었지만 최소 용량으로 실행되는 컨테이너, 환경 전반의 중복 서비스, 완료된 프로젝트에서 분리된 고아 리소스와 같은 특정 리소스 비효율성을 식별하는 데 도움이 됩니다. 이러한 가시성을 통해 조직은 인프라를 적절한 크기로 조정하고 불필요한 클라우드 비용을 줄일 수 있습니다.

AI 기반 분석도 IT 팀이 사용자에게 영향을 미치기 전에 문제를 예방하는 데 도움이 됩니다. 예를 들어, 소매 플랫폼은 블랙 프라이데이 몇 주 전에 데이터베이스 쿼리 패턴이 점진적으로 느려지는 것을 감지하여, 팀이 인덱스를 최적화하고 트래픽이 가장 많은 동안 결제 실패를 방지하도록 지원할 수 있습니다.

DevOps 팀은 문제 해결에 소요되는 시간을 줄이고 기능을 구축하는 데 더 많은 시간을 할애합니다. 분산 추적은 코드 변경이 모든 종속 서비스의 프로덕션 성능에 어떤 영향을 미치는지 보여주는 반면, 자동화된 계측은 수동 구성을 제거합니다.

풀 스택 관측 가능성을 통해 개발자는 마이크로서비스, 데이터베이스, 타사 통합을 통해 몇 시간이 아닌 몇 분 만에 느린 API 호출을 추적할 수 있습니다. 이러한 가시성을 통해 성능 회귀가 프로덕션 단계에 도달하기 전에 미리 식별하여 롤백 빈도(장애로 인해 배포를 되돌려야 하는 빈도)와 디버깅 시간을 모두 줄일 수 있습니다. 

풀 스택 관측 가능성은 포괄적인 감사 추적 및 이상 징후 탐지를 통해 보안 태세를 강화합니다. 인시던트가 발생하면 팀은 로그와 추적을 통해 기존 인시던트 대응보다 더 빠르게 공격 벡터를 식별하고, 영향을 평가하고, 취약점을 수정할 수 있습니다.

또한 이 기술은 시스템 액세스 및 데이터 흐름에 대한 상세한 감사 추적을 유지하여 규정 준수 요구 사항을 지원합니다. 예를 들어, 금융 서비스 회사는 풀 스택 관측 가능성을 사용하여 사베인즈-옥슬리(SOX) 법과 같은 규정에 대한 감사 가능성을 지원하고 타임스탬프가 찍힌 상세한 레코드를 통해 SLA 성과를 문서화합니다.

풀 스택 관측 가능성은 기술 지표를 비즈니스 결과에 직접 연결합니다. 조직은 애플리케이션 성능이 고객 경험, 전환율 및 수익에 미치는 영향을 실시간으로 추적할 수 있습니다.

예를 들어, 전자상거래 회사는 페이지 로드 시간과 장바구니 포기율의 상관관계를 파악하여, 사용자 행동 패턴을 분석하고 팀이 수익에 직접적인 영향을 미치는 최적화의 우선순위를 정하는 데 도움을 줄 수 있습니다. 

풀 스택 관측 가능성 솔루션은 포괄적인 가시성을 제공하지만, 조직은 이러한 복잡한 시스템을 구현하고 유지 관리하는 과정에서 잠재적인 문제에 직면할 수 있습니다.

엔터프라이즈 환경에서는 매일 수천 개의 서비스를 통해 페타바이트 단위의 원격 측정 데이터가 생성됩니다. 조직은 포괄적인 가시성과 스토리지 비용, 쿼리 성능, 데이터 보존과 관련된 실질적인 제약 사이에서 균형을 유지해야 합니다.

적절한 샘플링 전략과 데이터 우선순위 지정이 없다면 이러한 방대한 양의 데이터가 풀 스택 관측 가능성 툴에 과부하를 유발하여 인사이트를 지연시키고 이상 징후를 모호하게 만들 수 있습니다. 예를 들어, 빈도가 높은 거래 시스템을 모니터링하는 금융 서비스 회사는 초당 수백만 개의 이벤트를 생성할 수 있으므로, 지능적인 필터링 및 집계 기능이 없다면 실시간 분석이 불가능합니다. 

대부분의 조직은 수년간 누적된 수십 개의 모니터링 툴을 운영하며, 각 툴은 특정 팀 또는 기술을 지원합니다. 기술 스택은 일반적으로 여러 프로그래밍 언어, 레거시 시스템, 멀티클라우드 환경, 마이크로서비스, 인프라 구성 요소, 프레임워크에 걸쳐 있어 상호 운용이 어렵고 파편화된 데이터를 생성합니다. 이러한 파편화는 시스템 상태에 대한 통합된 뷰를 만든다는 풀 스택 관측 가능성의 핵심 목적에 방해가 됩니다.

또한 일부 툴은 주로 애플리케이션용으로 설계되었기 때문에 모바일 앱과 IoT 디바이스를 동일한 관측 가능성 프레임워크에 통합하기가 어려웠습니다. 

풀 스택 관측 가능성을 위해서는 팀 운영 방식에 근본적인 변화가 필요합니다. 개발, 운영, 보안 및 비즈니스 팀은 공유 데이터 및 지표를 중심으로 협업해야 하며, 그렇지 않으면 데이터가 사일로화된 상태로 유지되고 중요한 문제에 대해 어느 팀도 책임을 지지 않게 됩니다.

예를 들어, 프로덕션 중단이 발생하면 애플리케이션 로그(개발), 인프라 지표(운영), 보안 이벤트(InfoSec)의 상관관계를 파악해야 할 수 있습니다. 공유 데이터가 없으면 근본 원인 분석이 불가능해집니다.

조직은 명확한 소유권 모델을 확립하고, 직원에게 새로운 워크플로에 대해 교육하고, 비즈니스 성과에 대한 중요 지표를 정의해야 합니다. 이러한 기반이 없으면 팀은 고립된 익숙한 툴에 계속 종속되고 통합 관측 가능성을 달성할 수 없게 됩니다.

풀 스택 관측 가능성은 기업 전반의 민감한 데이터를 중앙 집중식 플랫폼으로 집계함으로써 고유한 규정 준수 문제를 야기합니다. 원격 측정 데이터에는 개인 식별 정보(PII), 결제 카드 정보 또는 보호되는 건강 정보가 포함되는 경우가 많습니다. 이러한 유형의 데이터는 일반 데이터 보호 규정(GDPR), 건강 보험 양도 및 책임에 관한 법률(HIPAA), 캘리포니아 소비자 개인정보 보호법(CCPA) 및 기타 규정의 적용을 받습니다.

데이터 마스킹, 토큰화, 지리적 제한 및 역할 기반 액세스 제어가 없는 조직은 민감한 데이터가 승인되지 않은 사용자에게 노출되거나 규제 요구 사항을 위반할 위험이 있습니다. 예를 들어, 유럽 고객의 트랜잭션 문제를 해결하려면 개인 식별 정보(PII)가 포함된 로그에 액세스해야 할 수 있습니다. 미국에 본사를 둔 엔지니어가 해당 데이터를 확인할 경우 GDPR 제한 사항을 위반할 수 있습니다.

조직들은 이미 신호 대 잡음비(SNR), 즉 중요 경고를 정상적인 운영 데이터와 구별하는 데 어려움을 겪고 있습니다. 풀 스택 관측 가능성은 기술 스택의 모든 계층에서 원격 측정 데이터를 동시에 집계하여 잠재적인 경고 수를 늘림으로써 이러한 문제를 증폭시킵니다.

예를 들어, 단일 API 시간 초과로 인해 애플리케이션 계층, 인프라 모니터링, 합성 사용자 모니터링 및 비즈니스 KPI 대시보드에서 알림이 트리거될 수 있습니다. 지능형 상관관계 파악과 중복 제거가 없으면 팀은 하나의 문제에 대해 수십 개의 경고를 수신할 수 있습니다.

적절한 구성과 자동화된 상관관계 파악 기능이 없는 경우 풀 스택 관측 가능성 플랫폼은 여러 시스템의 중복된 경고로 팀에 과도한 부담을 주고, 이로 인해 잠재적으로 중요한 시스템 간 문제가 노이즈에 묻힐 수 있습니다.

인공 지능은 분석, 자동화 및 기능을 통해 풀 스택 관측 가능성을 혁신하고 있습니다. 기존의 관측 가능성이 시스템에 대한 가시성을 제공하는 반면, AI는 전체 기술 스택의 패턴을 분석하여 문제가 운영에 영향을 미치기 전에 미리 예측하고 방지함으로써 가시성을 개선합니다.

인프라에서 애플리케이션에 이르기까지 모든 계층에서 광범위한 데이터 스트림을 구문 분석하는 ML 알고리즘은 인간 분석에서 놓칠 수 있는 패턴, 이상 징후, 상관관계를 식별합니다. 이러한 프로세스를 통해 팀은 사후 대응적 문제 해결에서 사전 예방적 최적화로 전환할 수 있습니다.

풀 스택 관측 가능성에 AI를 사용하면 다음과 같은 여러 이점이 있습니다. 

AI 기반 플랫폼은 들어오는 원격 측정 데이터를 분석하여 이상 징후를 감지한 다음, 스택 전체에서 시정 조치를 자동으로 수행합니다. 예를 들어, 메모리 누수가 여러 서비스에 영향을 미치는 경우 시스템은 사람의 개입 없이 영향을 받는 컨테이너를 재시작하고, 리소스를 확장하고, 트래픽을 다시 라우팅할 수 있습니다.

대규모 언어 모델(LLM)을 사용하면 사용자는 복잡한 쿼리 구문이 아닌 일반 언어를 통해 관측 가능성 데이터를 쿼리할 수 있습니다. 팀은 도메인별 쿼리 언어를 작성하는 대신, "어제 유럽 고객의 결제가 실패한 이유는 무엇인가요?"라고 질문하고 전체 스택에서 상관관계가 있는 인사이트를 얻을 수 있습니다. 이러한 접근 방식은 기술 전문가가 아닌 이해관계자를 위해 관측 가능성 데이터에 대한 액세스를 민주화합니다. 

기존의 상관관계 기반 분석과 달리 인과적 AI는 시스템 이벤트 간의 인과관계를 식별하기 위해 작동합니다. 풀 스택 환경에서는 데이터베이스 지연 시간이 결제 실패와 상관관계가 있을 뿐만 아니라, 특정 쿼리 패턴이 종속 서비스를 통해 계단식 지연을 유발한다는 점을 이해해야 합니다.

머신 러닝 모델은 과거 패턴을 분석하여 용량 수요를 예측하고, 장애 지점을 예측하고, 스택 전반에서 리소스 할당을 최적화합니다. 이러한 예측을 통해 문제가 사용자에게 영향을 미치기 전에 선제적 확장, 유지 관리 예약, 성능 미세 조정을 수행할 수 있습니다.

AI 시스템은 풀 스택 관측 가능성에 대한 새로운 모니터링 문제를 야기합니다. 기존 소프트웨어는 결정론적 패턴을 따릅니다. 즉, 애플리케이션에 오류가 발생하면 MELT 데이터의 상관관계를 파악하여 원인이 메모리 누수, 데이터베이스 오류 또는 API 시간 초과인지 정확하게 파악합니다.

AI 모델은 확률적 아웃풋을 생성하므로, 동일한 입력에 대해 다른 응답이 나올 수 있습니다. 풀 스택 환경에서는 이러한 가변성이 여러 계층을 통해 계단식으로 나타납니다. AI 모델의 예기치 않은 아웃풋으로 인해 다운스트림 API에서 오류가 발생할 수 있습니다. 이러한 오류는 데이터베이스 쿼리에 영향을 미치고, 궁극적으로 사용자 인터페이스에 영향을 줄 수 있습니다. 전체 스택에서 이러한 확률적 변동을 추적하는 작업은 기존 시스템을 모니터링하는 작업보다 기하급수적으로 복잡해집니다.

예를 들어, 고객 서비스 챗봇은 동일한 질문에 대해 서로 다른 응답을 제공할 수 있는데, 이러한 변동이 백엔드 서비스, 결제 처리, 고객 만족도 지표에 어떤 영향을 미치는지 동시에 추적하려면 풀 스택 관측 가능성이 필요합니다.

조직은 풀스택 환경 내에서 AI 기반 시스템을 효과적으로 모니터링하기 위해 기존 성능 지표와 함께 모델 드리프트, 데이터 품질 문제, 예측 정확도를 추적해야 합니다.