https://www.youtube.com/watch?v=SMaeVYSZlcI

description: |-

1. 이건 꼭 알아야 한다[^1]

[? 질문] 기업(엔터프라이즈)이 하이브리드(온프렘+클라우드) 환경에서 더 빠르고 안전하게 제품/서비스를 출시(배포)하려면 무엇이 필요한가[^2]
[= 답] **DevOps(철학+실천+도구)**를 기반으로 Infrastructure as Code, Microservices, Logging/Monitoring, CI/CD를 적용해 **속도(velocity)**를 올리고, AWS의 자동화·확장·보안 모델(공유 책임)을 활용해야 한다.[^2]

[? 질문] AWS로 전환(또는 확장)할 때, “모니터링/운영”은 무엇이 어떻게 달라져야 하는가[^18]
[= 답] VM/서버 중심의 에이전트 기반 엔드포인트 모니터링만으로는 서버리스·마이크로서비스를 운영할 수 없으므로, **스트리밍 텔레메트리(메트릭/로그/이벤트)**와 코드로 심는 관측(Observability), 그리고 이를 서비스/비즈니스 컨텍스트로 묶는 “단일 창(single pane of glass)” 체계로 바뀌어야 한다.[^18][^19]

[? 질문] AWS에서의 “용량(capacity)·비용(cost) 관리”는 온프렘과 무엇이 다른가, 그리고 왜 중요한가[^43]
[= 답] 온프렘의 CapEx(자본 지출) 기반 장기 구매·계획에서 AWS의 OpEx(운영 지출) 기반 사용량 과금으로 바뀌면서, 과대/과소 프로비저닝의 페널티 구조가 달라진다(특히 과대 프로비저닝은 매달 계속 비용 누수). 따라서 **서비스 컨텍스트 기반의 사용량/성능/비용 상시 모니터링과 예측(what-if 포함)**이 핵심 운영 과제가 된다.[^43][^44][^46]

---

2. 큰 그림[^1]

이 웨비나는 AWS가 말하는 DevOps의 핵심 구성요소와 모범 사례를 먼저 정리한 뒤, BMC의 **Truesight(모니터링·이벤트·자동화·용량/비용 관리)**가 하이브리드 환경에서 어떻게 “가시성(visibility)”을 제공하는지 설명하고, 마지막으로 NICE inContact가 AWS+BMC를 통해 실제로 어떤 방식으로 엔터프라이즈 IT 인프라를 전환했는지(단계적 마이그레이션, 모니터링 전략 전환, 성과 지표) 사례로 보여준다.[^2][^15][^27]

• DevOps는 속도(velocity)를 올리는 운영 모델이며, 이를 위해 AWS에서는 Infrastructure as Code, Microservices, Logging/Monitoring, CI/CD를 핵심 모범 사례로 제시한다.[^2][^3][^4]
• 엔터프라이즈 전환의 현실은 하이브리드이므로, 온프렘과 AWS 전반을 서비스/비즈니스 컨텍스트로 묶어 “단일 창”에서 모니터링·이벤트·티켓·원인 분석까지 연결하는 통합 가시성이 중요하다고 주장한다.[^15][^38][^39]
• NICE inContact 사례는 “리프트 앤 시프트 → 서비스 활용 확대 → 서버리스/마이크로서비스 중심 → 자동화 강화”의 단계적 접근과, 그 과정에서 “엔드포인트 모니터링 → 스트리밍/코드 기반 관측”으로 바꾸어 MTTR 70% 감소, 5초 내 알림, 하드웨어 CapEx 6분기 0 같은 결과를 얻었다고 제시한다.[^27][^31][^33]

---

3. 하나씩 살펴보기[^1]

3.1 오프닝: 발표자, 아젠다, 학습 목표[^1]

웨비나는 AWS의 Michael Miller(파트너 솔루션스 아키텍트)가 진행하며, BMC Software의 Seth(솔루션 마케팅 매니저), NICE inContact의 Dennis Sherman(클라우드 인프라 디렉터)이 함께 발표한다고 소개한다.[^1]
아젠다는 (1) AWS에서의 DevOps 개요와 모범 사례, (2) BMC Truesight로 “완전히 가시적인 클라우드(fully visible cloud)” 구현, (3) NICE inContact가 BMC와 AWS를 통해 엔터프라이즈 IT를 어떻게 변환했는지 사례, (4) Q&A 순서로 구성된다.[^1]
학습 목표는 다음을 이해하게 하는 것이라고 명시한다:

• DevOps 모델을 왜/어떻게 사용하는지, 그리고 **복잡한 인프라(하이브리드 포함)**를 어떻게 관리하는지[^2]
• 마이크로서비스와 컨테이너를 어떻게 적용하는지[^2]
• AWS 및 BMC Truesight를 통해 환경 전반(온프렘+클라우드)의 통합 가시성을 어떻게 확보하는지[^2]

3.2 “전통적 개발 모델은 끝나가고 있다”: DevOps가 필요한 배경[^2]

Michael은 “전통적인 개발(및 운영) 모델은 변화하고 있다”고 전제하면서, 소프트웨어가 비즈니스 방식을 바꾸고 사용자 기대치가 높아졌다고 말한다.[^2] 기대치의 내용은 (a) 제품 경험의 즉시성, (b) 신뢰성(reliability), (c) 보안(security) 측면에서 모두 더 높은 수준을 요구한다는 것이다.[^2]
이러한 기대를 충족하려면 리소스와 애플리케이션을 빠르고 신뢰성 있게 프로비저닝해야 하며, 고객이 “혁신 속도”를 체감하려면 기업이 애플리케이션과 인프라를 빠르게, 대규모로 푸시(배포)할 수 있어야 한다고 연결한다.[^2]
여기서 DevOps가 “핵심 역할(vital role)”을 한다고 말하며, AWS 관점에서 DevOps를 **세 가지 요소의 결합(철학, 실천, 도구)**으로 정의한다.[^3] 이 세 요소를 함께 가져가면 조직의 velocity(변화/개선 속도)가 증가해, 전통적 프로세스 조직보다 더 빠르게 제품을 진화시키고 경쟁력을 얻는다고 주장한다.[^3]

[!IMPORTANT] DevOps 정의(본 웨비나의 프레이밍) DevOps = 철학(Philosophies) + 실천(Practices) + **도구(Tools)**의 결합이며, 목적은 조직의 **속도(velocity)**를 높여 더 빠른 개선/혁신을 가능하게 하는 것이다.[^3]

3.3 AWS가 제시하는 DevOps 4대 모범 사례: IaC, 마이크로서비스, 모니터링, CI/CD[^3]

Michael은 DevOps의 핵심 실천으로 네 가지를 제시한다: Infrastructure as Code, Microservices, Logging/Monitoring, CI/CD이며, 이 모든 것의 기반에 더 큰 커뮤니케이션과 협업이 있다고 강조한다.[^3]

3.3.1 Infrastructure as Code(IaC): 인프라를 코드로 프로비저닝/관리[^3]

IaC는 인프라를 코드로 프로비저닝하고 관리하는 방식이라고 설명한다.[^3] 코드 기반 모델이기 때문에 개발자와 시스템 관리자가 인프라와 프로그램적으로 상호작용할 수 있고, 환경이 스케일할수록 이 특성이 중요해진다고 말한다.[^3]
또한 IaC는 인프라에도 **버전 관리(version control)**와 지속적 통합(CI) 같은 기법을 적용할 수 있게 해주며, 결과적으로 엔지니어가 인프라를 코드로 다루기 때문에 서버와 애플리케이션을 빠르게 배포할 수 있다고 연결한다.[^3]

3.3.2 Microservices: 단일 앱을 작은 서비스들의 집합으로 구성[^3]

마이크로서비스는 하나의 애플리케이션을 “더 작은 서비스들의 집합”으로 만들고, 각 서비스는 자기 프로세스에서 실행되며 다른 서비스와는 경량 API로 통신한다고 정의한다.[^3]
또한 보통 마이크로서비스는 비즈니스 기능(business capability) 단위로 구성되고, 각 서비스는 **단일 목적(single purpose)**에 스코프가 맞춰진다고 설명한다.[^3]
장점으로는 서비스별로 다른 프레임워크/언어를 쓸 수 있고, 독립적으로 배포할 수 있어 유연성이 크다는 점을 든다.[^3]

3.3.3 Logging & Monitoring: 24/7 가용성과 잦은 변경을 전제로 하는 능동 모니터링[^4]

서비스가 24/7 가용해야 하고 애플리케이션/인프라 업데이트 빈도가 높아질수록 **능동 모니터링(active monitoring)**이 더 중요해진다고 말한다.[^4]
구성 요소로는 알림(alert) 생성, 데이터의 실시간 분석, 애플리케이션과 인프라에서 나오는 데이터/로그를 캡처→분류→분석하는 활동을 포함한다고 설명한다.[^4]
이를 통해 변경이 사용자에게 어떤 영향을 주는지 이해하고, 문제나 예상치 못한 변화의 **근본 원인(root cause)**을 비추어볼 수 있다고 주장한다.[^4]

3.3.4 CI/CD: 지속적 통합과 지속적 전달로 품질과 배포 속도 동시 개선[^4]

**지속적 통합(CI)**은 개발자가 코드 변경을 중앙 저장소(repo)에 자주 머지하고, 그 결과 자동 빌드가 트리거되는 개발 관행이라고 설명한다.[^4] 목적은 소프트웨어 품질을 개선하고 검증/배포 시간을 줄이는 것이라고 한다.[^4]
**지속적 전달(CD)**은 CI 이후 빌드 단계를 통과한 변경을 사전 운영(pre-production)과 운영(production) 환경으로 배포하는 것으로 확장한다고 말한다.[^4]
CD가 제대로 구현되면 개발자는 표준화된 테스트를 통과한 “배포 준비된 빌드 아티팩트”를 항상 갖게 되고, 결과적으로 빠르고 신뢰성 있게 빌드-테스트-배포하면서 품질을 올리고 출시 시간을 줄일 수 있다고 결론내린다.[^5]

3.4 AWS에서 DevOps를 할 때의 이점 5가지(자동화, 과금, 보안, 관리형 서비스, 확장성)[^5]

Michael은 “DevOps on AWS”의 이점으로 다음을 열거한다.[^5]

1. 시스템 운영 자동화: 배포, 테스트 워크로드, 컨테이너 관리, 구성 관리 같은 수동 작업을 자동화하여 더 빠르고 효율적으로 만든다.[^5]
2. Pay-as-you-go: 필요한 기간 동안 필요한 서비스만 사용하고 그만큼만 비용을 지불하며, 선결제/위약금/장기 계약이 없다고 설명한다.[^5]
3. 보안 향상: 누가 어떤 리소스/서비스에 어떻게 접근하는지에 대한 세밀한 제어가 가능하며, 이는 AWS **IAM(Identity and Access Management)**으로 구현한다고 말한다.[^6]
4. 완전관리형(fully managed) 서비스 활용: 인프라 설치/운영 부담을 줄여 코어 제품 개발에 집중하게 해준다고 설명한다.[^6]
5. 스케일을 위해 설계: 단일 인스턴스부터 수천 개까지 확장 가능하며, 데이터/컴퓨팅 리소스의 프로비저닝·구성·스케일링을 단순화하는 서비스들이 있다고 말한다.[^6]

3.5 AWS 공유 책임 모델: ‘클라우드의 보안’ vs ‘클라우드 안의 보안’[^6]

Michael은 보안과 컴플라이언스는 AWS와 고객 간의 **공유 책임(shared responsibility)**이라고 정의한다.[^6]
AWS는 호스트 OS, 가상화 계층, 데이터센터 물리 보안 등 클라우드 인프라 자체를 운영·관리·통제하며, 고객(및 APN 파트너/ISV/통합업체)은 게스트 OS(업데이트/패치), 애플리케이션 소프트웨어, AWS 제공 보안 구성(예: 방화벽 구성 등) 같은 클라우드 내부의 구성/운영 책임을 가진다고 설명한다.[^6][^7]
이 구분을 “security of the cloud”(AWS 책임)과 “security in the cloud”(고객 책임)로 부른다고 명시한다.[^7]
또한 EC2, VPC, S3 같은 서비스는 IaaS 범주로서 고객이 필요한 보안 구성/관리 작업을 수행해야 한다고 예시한다.[^8]
AWS가 다양한 표준/인증을 충족했고, 컴플라이언스 정보는 aws.amazon.com/compliance에서 확인할 수 있다고 안내한다.[^8]

3.6 BMC 소개 및 시장 맥락: “디지털 트랜스포메이션은 선택이 아니라 생존”[^9]

Seth는 BMC가 약 40년 동안 고객 IT 운영의 변화를 도와왔고, 메인프레임→분산 컴퓨팅→가상화→클라우드→마이크로서비스까지 전환을 지원해왔다고 소개한다.[^9] 이를 “고객이 변화를 관리하고 비즈니스를 변환하도록 돕는 것”이 BMC의 미션이라고 설명한다.[^9]

이어 시장 상황을 “디지털 전환이 가져오는巨大한 기회이자巨大한 파괴”로 묘사한다.[^10] 디지털로 인해 시장 안정성이 흔들리고 파괴(disruption)가 커졌으며, 이제 조직이 전환하지 못하면 “파괴당하는 쪽”이 될 수 있으니 사실상 선택지가 없다고 주장한다.[^10]
동시에 좋은 소식으로 AWS가 이를 돕는다고 말한다.[^10]

또 하나의 현실로, 중앙 IT가 의식적으로 전환 계획을 세우지 않아도 조직 내 DevOps 팀/라인오브비즈니스가 이미 AWS 같은 퍼블릭 클라우드를 쓰고 있을 가능성이 높다고 지적한다.[^11] 따라서 “지금 전환해야 하는 이유”는 기회뿐 아니라, 조직 내부에서 이미 변화가 진행 중일 수 있기 때문이라고 결론낸다.[^11]

3.7 디지털 전환 기업의 성과(정량 주장): 목표 달성 3배, 신시장 2배, ROI 90%↑[^12]

Seth는 디지털 전환을 하는 조직이 그렇지 않은 조직보다:

• 비즈니스 목표를 달성할 가능성이 3배 높고[^12]
• (특히 글로벌/신지역 확장 맥락에서) 신시장 침투에 성공할 가능성이 2배 높으며[^12]
• 100% 온프렘에 머무는 기업 대비 투자 수익률이 90% 더 높다고 말한다.[^13]

여기서 “IT가 단순 비용센터로 지원하는 것”이 아니라, 디지털로 전환되면 IT가 곧 비즈니스가 된다고 주장한다.[^12] 그래서 비즈니스 얼라인먼트/비즈니스 인식이 결정적으로 중요하다고 깔고 간다.[^12]

3.8 엔터프라이즈 전환 과제: 리프트&시프트 vs 리팩터링/클라우드 네이티브, 비용 패러다임, 자동화, 서비스 컨텍스트[^13]

Seth는 엔터프라이즈가 전통적 서비스 딜리버리 모델에서 AWS로 가는 여정에서 고려해야 할 선택들을 나열한다.[^13]

• 워크로드를 리프트 앤 시프트(기존 그대로 옮김)할지, 리팩터링하거나 클라우드 네이티브 서비스를 새로 만들어 기존 엔터프라이즈 앱과 상호작용하게 할지 결정해야 한다.[^13]
• DevOps CI/CD 모델을 채택하되, 아직 남아 있는 기존 비즈니스/시스템과 매끄럽게 통합되어야 한다.[^14]
• 클라우드로 가면 용량 관리뿐 아니라 비용/클라우드 비용(Expense) 관리가 새로운 패러다임이 되며, 가격/비용 모델이 달라진다고 강조한다.[^14]
• 인프라를 코드로 계측(IaC)하는 자동화뿐 아니라, 이슈 대응·규정준수·취약점 관리 등에서 **자동 대응/자동 복구(remediation)**가 중요하다고 말한다.[^14]
• 성능 보장/서비스 연속성은 새 클라우드 서비스와 기존 서비스가 연결되어 있다는 점을 이해해야 하며, 이를 위해 서비스 컨텍스트를 유지해야 한다고 설명한다.[^14][^15]

3.9 BMC Truesight 포지셔닝: 하이브리드 전반 “단일 창”과 서비스 모델 컨텍스트[^15]

Seth는 Truesight가 온프렘 데이터센터, 프라이빗 클라우드, AWS까지 걸친 모니터링·대응·자동화를 지원하도록 구축되어 왔다고 말한다.[^15]
목표는 AWS와 데이터센터 자산을 한 곳에서 보고(“single pane of glass”), 모니터링·이벤트 관리·근본원인 분석·대응을 수행하는 통합 뷰를 만드는 것이라고 설명한다.[^16]

특히 차별점으로 “자산 관점(assets up)”이 아니라 “비즈니스 서비스 관점(business service down)”에서 볼 수 있도록 깊고 의미 있는 서비스/애플리케이션 컨텍스트를 만든다고 강조한다.[^16]
이는 IT가 디지털 전환을 통해 비즈니스를 ‘직접 제공’하는 상황에서 비즈니스 목표와 정렬된 컨텍스트가 필요하기 때문이라고 논리를 연결한다.[^16]
또한 이를 가능하게 하는 자동화/애널리틱스 기법이 필요하며, Dennis가 일부를 설명할 것이라고 예고한다.[^17]

3.10 NICE inContact 소개: 글로벌 규모와 “nines” 업타임 보장[^18]

Dennis는 NICE inContact를 “글로벌 컨택센터 소프트웨어 리더”라고 소개하며, 이는 Gartner 평가 기준으로 최근 3년간 클라우드 컨택센터 분야 리더로 선정되었다고 말한다.[^18]
회사 규모/성과로:

• 전 세계 25만(250,000) 에이전트가 솔루션을 운영하고[^18]
• 고객은 100개+ 국가에 걸쳐 있으며[^18]
• **Fortune 100의 85%**를 고객으로 두고[^18]
• 업계에서 유일하게 업타임 “nines”(복수의 9로 표현되는 고가용성 수준)의 계약 보장을 제공한다고 언급한다.[^18]

또한 단일 플랫폼에서 **음성(voice), WFO(워크포스 최적화), 분석(analytics), 자동화(automation)**를 제공하며, 이 모든 것을 하나의 서비스 딜리버리 플랫폼에서 제공하는 것이 리더십의 이유라고 설명한다.[^19]
“진정한 클라우드”로서 **사용량 기반 결제(pay for what you use)**와 확장 유연성을 제공한다고 덧붙인다.[^19]
다만 글로벌 스케일로 제공하는 것은 많은 도전과 기회를 만들며, Dennis는 이를 “기회(opportunities)”로 부르고 싶다고 말한다.[^20]

3.11 왜 퍼블릭 클라우드(AWS)였나: 해외 데이터센터의 어려움과 하이브리드 현실[^20]

글로벌 제공을 확대하는 과정에서 “기존 방식대로는 계속할 수 없다”는 결론에 도달했다고 말한다.[^20] 그는 “우리를 여기까지 데려온 방식이 우리가 가려는 곳까지 데려다주지 못한다(what got us here won’t get us there)”는 표현으로 전환 필요성을 요약한다.[^20]
그래서 퍼블릭 클라우드를 고려했지만, **프라이빗 클라우드 + 퍼블릭 클라우드의 결합(하이브리드)**은 복잡하며 한 번에 전부 옮길 수 없었다고 한다.[^20][^21]
그는 프라이빗 방식이 “죽어가는 공룡(dying dinosaur)”이 될 수 있다고 비유하며, 특히 외국에 데이터센터를 세우는 어려움을 예로 든다.[^21] 미국 내에서도 빠르지 않은데 해외는 더 어렵다는 것이다.[^22]

또한 당시 업계에 확립된 베스트 프랙티스가 충분치 않아 “직접 해답을 찾아야 했다”고 말하고, 이를 매끄럽게 하기 위해 BMC와 AWS와의 파트너십을 선택했다고 설명한다.[^21]
추가 도전으로는 고객 기반 성장 속도가 인프라 구축 속도보다 빠르다는 점(좋은 문제지만 문제), 다양한 지역으로 고객이 확장되며, 비용을 낮추고 다운타임을 최소화해야 한다는 점을 든다.[^21][^22]

3.12 “모니터링은 목적이 있어야 한다”: 액션 가능한 피드백(Feedback) 철학[^22]

Dennis는 모니터링을 매우 강하게 정의한다: “모니터링을 위한 모니터링은 가치가 거의 없고, 모니터링은 목적을 가져야 한다”고 말한다.[^22]
그 목적은 **actionable feedback(조치 가능한 피드백)**이며, 모니터링은 피드백을 제공해야 유용하다고 주장한다.[^22]

이런 관점에서, 기존 제품/서비스/인프라 투자에 더해 추가 투자(툴/플랫폼)를 결정해야 했고, 그 결과 BMC에 투자했다고 말한다.[^22]
BMC를 선택한 이유로는:

• 모니터링, 용량 관리, ITSM을 포함하는 “완전히 통합된 포트폴리오(fully integrated portfolio)”를 제공했고[^23]
• 이를 통해 “의미 있는 모니터링(=actionable feedback)”을 만들 수 있었으며[^23]
• 미래 로드맵/비전이 있었고, AWS로 가며 필요한 실시간(real-time) 기능을 제공했으며[^23]
• 팀 내부에 BMC 경험 인력이 있어 도입 저항이 낮았다는 점을 든다.[^23]

3.13 “단일 창(single pane of glass)”의 가치: 중앙화된 관리/리포팅[^24]

Dennis는 상사(클라우드 운영 VP)의 발언을 인용하며, 중앙화된 관리/중앙 리포팅이 “실제 가치(real value)”를 만든다고 말한다.[^24]
그는 이를 “인프라 건강 상태에 대한 single pane of glass 뷰”로 표현하며, 이것이 엔터프라이즈와 고객 모두에 가치가 있다고 주장한다.[^24]

3.14 디지털 전환은 ‘한 번 하고 끝’이 아니라 지속 과정 + 성숙도 모델[^24]

Dennis는 디지털 전환이 아직 진행 중이며, 기술이 바뀌면 전환도 계속될 것이라고 말한다.[^24] “디지털 전환은 한 번 하는 것이 아니다”라는 인식이다.[^24]
그는 Darwin의 문장을 인용한다: 가장 강하거나 가장 똑똑한 종이 아니라 변화에 가장 잘 적응하는 종이 살아남는다는 말로, 디지털 전환의 상징이 “적응”이라고 해석한다.[^25]

또한 조직 성숙도 관점에서 변화의 축들을 나열한다.[^25]

• 기본 모니터링에서 시작해, 용량 관리를 도입하고, 더 성숙하면 서비스 지향 모니터링으로 간다.[^25]
• 프라이빗 클라우드 → 퍼블릭 클라우드로 전환한다.[^25]
• **워터폴(캐스케이드)**에서 DevOps와 CI/CD로 전환한다.[^25]
• 여기에 **자동화(automation)**를 “뿌린다(sprinkle in)”고 표현하며, 이 자동화가 장기적으로 성공에 기여할 것이라 본다.[^25]

3.15 NICE inContact의 “과거 상태”: 사일로형(컬럼) 모니터링과 수동 용량관리, 혼돈의 알림[^26]

Dennis는 현재를 이해하려면 과거를 알아야 한다며 이전 운영을 상세히 설명한다.[^26]

• 모니터링이 “컬럼(기둥)들”로 분리되어 있었다: 서버 엔드포인트에는 Patrol agent, 네트워크는 별도 네트워크 툴, 음성(voice)도 별도 툴로 모니터링했다.[^26]
• 용량 관리는 **단독(standalone)**으로, 수동(manually) 수행되었고, 리포팅/알림과 통합되지 않았다.[^26]
• ITSM도 **분절된 구현(disjointed)**이었다.[^26]
• 누군가 콘솔을 보고 있지 않거나 알림을 놓치면 운영이 “카오스(chaotic)”가 되었고 문제가 누락되기도 했다고 말한다.[^26]

즉, 모니터링은 했지만 “피드백이 체계적으로 전달/조치”되기 어려운 구조였던 셈이다.[^26]

3.16 Truesight Ops로의 통합: 알림→이벤트→CMDB→ITSM 티켓의 연결[^27]

Dennis는 Truesight Operations Management로 통합하면서 “단일 창”을 얻었다고 말한다.[^27]
구체적으로는:

• 다른 툴들에서 발생하는 알림이 Truesight로 들어오고[^27]
• 엔터프라이즈 인시던트가 모니터링의 모든 영역에서 리포트되며[^27]
• 새로 추가된 컴포넌트를 발견(discover)하여 CMDB에 등록하고[^27]
• ITSM 툴이 해당 알림에 대해 티켓을 생성할 수 있게 된다.[^27]

결과적으로 인프라 전반의 뷰가 한 곳에서 묶이며, 이것이 다시 Dennis가 강조한 actionable feedback으로 이어진다고 결론낸다.[^27]

3.17 AWS 전환(퍼블릭 클라우드) 여정: 멀티-페이즈 + 모니터링 전략의 전환[^27]

Dennis는 AWS로의 전환을 “멀티-페이즈 접근”이라고 규정한다.[^27]

3.17.1 Phase 1: “리프트 앤 시프트”로 AWS에 발 담그기[^28]

첫 단계는 AWS 세계에 “발가락을 담그는(dip toe)” 수준에서 시작했다고 말한다.[^28]
모놀리식 인프라 일부를 퍼블릭 클라우드로 옮겼고, 비즈니스 운영 방식이나 모니터링 전략에 큰 변화는 없었다고 설명한다.[^28]
방식은 전형적인 VM 접근으로, VM에 에이전트를 설치해 데이터를 Truesight “단일 창”으로 가져오는 형태였다.[^28]

3.17.2 Phase 2: AWS의 풍부한 기능(마이크로서비스/람다) 활용 → 모니터링 난이도 급상승[^28]

2단계에서 AWS의 마이크로서비스나 Lambda 같은 기능을 활용하기 시작하자 모니터링 관점에서 완전히 다른 문제가 생겼다고 말한다.[^28]
핵심 문제는 이것들이 “엔드포인트가 아니라서” 에이전트를 설치할 수 없다는 점이다.[^28]
따라서 모니터링 전략과 모델 자체를 바꿔야 했고, “모니터링을 염두에 두고 제품을 개발”하기 시작했다고 한다.[^29]

구체적 변화는 다음과 같다.[^29]

• 코드에 경보/피드백 로직을 넣어 배포한다(“alerts and feedback in code”).[^29]
• 애플리케이션 문제가 생기면, AWS에서 작성한 함수가 BMC 이벤트 모니터링으로 알림을 전송할 수 있게 한다.[^29]
• 더 이상 엔드포인트를 모니터링하지 않고, **데이터 스트림(streams of data)**을 모니터링한다.[^29]
• AWS의 커스텀 메트릭을 만들고, 이를 Pulse real-time으로 모니터링한다고 말한다.[^29]
• 이 모든 것이 단일 창에서 “완전한 텔레메트리 피드백 루프”로 귀결된다고 주장한다.[^29]

[!TIP] 서버리스 시대 모니터링 전환의 핵심 문장 “엔드포인트 모니터링에서 스트리밍 데이터(메트릭/로그/이벤트) 모니터링으로 바뀌어야 한다.”[^29]

3.18 현재(당시) 아키텍처 관점: 동적 베이스라인으로 ‘임계치’가 아니라 ‘편차’를 잡는다[^29]

Dennis는 인프라를 전체 흐름 관점에서 보면 “모든 것이 Truesight로 향한다(all things point to Truesight)”고 말한다.[^29][^30]
특히 슬라이드에 있는 Dynamic Baselining 기능이 큰 가치였다고 언급한다.[^30]

동적 베이스라인의 의미를 이렇게 설명한다.[^30]

• 단순히 CPU가 특정 임계치(threshold)에 도달할 때까지 기다리는 것이 아니라[^30]
• “정상 베이스라인”에서 벗어나는 **편차(deviation)**를 감지한다.[^30]
• 그래서 문제가 ‘심각해진 뒤’가 아니라, 정상 범위를 벗어나는 조짐 단계에서 잡아내는 더 실용적이고 선제적(proactive) 접근이라고 평가한다.[^30]
• 이 방식은 DevOps 팀과 고객 모두에 가치가 있는데, “무언가가 일어나기를 기다리지 않기” 때문이라고 말한다.[^30]

그는 이를 엔터프라이즈급의 더 성숙한 모니터링 접근이라고 부른다.[^30]

3.19 성과(결과 지표): MTTR 70% 감소, 5초 알림, 6분기 CapEx 0[^31]

Dennis는 “엔터프라이즈급 솔루션” 주장만으로는 부족하고 모두가 결과를 원한다고 말하며, 구체적 수치를 제시한다.[^31]

• [h MTTR(평균 복구 시간) 70% 감소] : 문제를 더 빨리 알고 더 빨리 해결하게 되었다는 의미로, 고객 만족/금전적 효과(다운타임 크레딧 감소)를 연결한다.[^31]
• [h 에러 감지→엔지니어 알림까지 5초 이내] : 자동화된 알림으로 감지 시점부터 통지까지 5초 내에 이뤄진다고 말한다.[^31]
• [h 하드웨어 자본 지출(CapEx) 6개 분기 연속 0] : 용량 관리 도구와 개선된 예측(포캐스팅) 능력 덕분에 하드웨어 구매가 6분기 동안 없었다고 말한다.[^31]

Dennis는 이 모든 것이 더 많은 업타임, 더 적은 지출로 이어지고 “보스가 더 행복해진다”고 농담 섞어 덧붙인다.[^31]

3.20 운영 관점의 효과: “프로젝트 작업”에 집중하고 “비계획(unplanned)” 작업을 줄인다[^32]

Dennis는 이 접근이 환경에서 “무엇이 중요한지”에 집중하게 해준다고 말한다.[^32]
그 결과:

• 프로세스 개선(예: 워터폴/애자일에서 CI/CD 프로세스로 전환)을 추진할 수 있고[^32]
• 장애 대응 등 비계획 작업보다 “프로젝트”에 시간을 쓰게 되어 비즈니스에도 큰 이점이라고 설명한다.[^32]

3.21 NICE inContact의 마이그레이션 “4단계 모델”을 정리[^33]

Dennis는 자신들의 접근이 “베스트 프랙티스가 될 수 있다”고 조심스럽게 말하면서, 단계별로 구체화한다.[^33]

3.21.1 Phase 1: Like-for-like 리프트&시프트 (모놀리스 + EC2/VM + 에이전트)[^33]

• 기존 모놀리식 접근을 유지한 채 EC2 인스턴스/VM으로 옮긴다.[^33]
• VM에 에이전트를 설치해 데이터를 콘솔(Truesight)로 가져오는 형태다.[^33]
• 데이터센터를 퍼블릭 클라우드로 “연장”하는 느낌이라고 표현한다.[^33]

3.21.2 Phase 2: 일부 서비스 도입 + 모놀리스 디커플링 + VM 풋프린트 축소 + 스트리밍 모니터링[^33]

• 서비스를 도입하면서 모놀리스에서 서비스들을 분리(디커플링)하려고 한다.[^33]
• VM 풋프린트를 줄이고, EBS 등 AWS 스토리지/컴퓨트 기능을 더 활용한다는 취지로 말한다.[^33]
• 핵심은 엔드포인트 관리에서 스트리밍 데이터로 이동하는 것이다.[^34]
• 이 단계에서 Dennis는 **BMC AWS KM(knowledge module)**을 도입했다고 말한다. 이는 AWS에 플러그인되어 비전통적 엔드포인트에서 나오는 메트릭 스트림을 수집할 수 있게 해준다고 설명한다.[^34]

3.21.3 Phase 3: “대부분 서비스” + 매우 작은 EC2 풋프린트 (람다·마이크로서비스 중심)[^34]

• 일부 서비스가 아니라 “대부분 서비스”로 옮기고 EC2/VM 비중을 매우 낮춘다.[^34]
• Lambda와 마이크로서비스를 적극 활용한다.[^34]
• 여기서 중요한 전환점으로 “용량 관점이 compute 성장 관리가 아니라 cost 관점 관리로 바뀐다”고 강조한다.[^35]

3.21.4 Phase 4: 프로세스가 성숙하면 자동화를 더 깊게 (Bladelogic 계획)[^35]

• 프로세스를 마스터한 뒤 자동화를 더 많이 도입할 계획이라고 말한다.[^35]
• 이미 일부 자동화는 있지만, 이 모델에서 성공하려면 자동화가 필수라고 강조한다.[^35]
• 구체적으로 BMC Bladelogic으로 자동화를 확대하고 싶다고 언급한다.[^35]

3.21.5 “중심은 Truesight”: 호스팅 위치/기술과 무관한 단일 창[^35]

Dennis는 어떤 기술로 어디에 호스팅하든 상관없이, 자신들에게 중심은 BMC Truesight이며 이것이 서비스의 “완전한 뷰”를 제공하는 단일 창이라고 재강조한다.[^35][^36]

3.22 (발표 요약 슬라이드) Truesight 기능군: ML 기반 모니터링, 이상탐지, PCA, 로그 분석, 자동화[^36]

Michael이 다시 받아, BMC Truesight가 엔터프라이즈 고객의 IT 투자 극대화를 돕는다고 요약한다.[^36]
포함 범주로 비용 통제, 가시성, 성능 관리, 모니터링/로깅 운영 데이터, 보안과 자동화 등을 “하이브리드 아키텍처” 전반에서 수행한다고 말한다.[^36]
또한 머신러닝을 통한 엔터프라이즈 클래스 모니터링, 운영 분석, 통합 뷰, 텔레메트리 데이터 기반 역추적(reverse engineer)으로 “진짜 이슈”를 찾는 것, 실시간 신뢰 자동화 등을 언급한다.[^36][^37]
기능 예시로 dynamic baselines, multivariate anomaly detection, probable cause analysis, log analytics, statistical metric model, business process automation 등을 나열한다.[^37]

3.23 Q&A 1: “서비스/비즈니스 컨텍스트”란 무엇인가 — 디스커버리로 관계를 모델링한다[^37]

질문: Seth에게 “서비스와 비즈니스 컨텍스트를 사용한다는 의미를 더 말해달라”[^37]
Seth 답변의 핵심은 “컨텍스트 없는 텔레메트리(이벤트/메트릭/로그)는 정보가 아니라 액션이 불가능하다”는 것이다.[^37]

Seth는 이를 위해 BMC의 핵심 테넌트로 “컨텍스트 생성”을 제시하고, Discovery라는 툴을 설명한다.[^38]
Discovery는 데이터센터와 AWS 퍼블릭 클라우드 자산을 100% 디스커버리할 뿐 아니라, 자산 간 **관계(relationships)**까지 찾아 “서비스 뷰/애플리케이션 뷰” 모델을 만든다고 말한다.[^38]
이렇게 모델을 만들면, 예를 들어 특정 영역에서 이벤트 폭풍(event storm)이 발생했을 때 어떤 비즈니스 서비스가 영향을 받는지, 영향의 심각도가 무엇인지 파악하여 우선순위를 정하고 리소스를 배분할 수 있다고 설명한다.[^38][^39]
또한 많은 고객이 자산/관계를 매일 재발견(rediscover)하고, 필요에 따라 더 자주/덜 자주 수행하며, 그 결과가 서비스데스크와 모니터링 도구 통합으로 흘러가 수동 개입 없이 컨텍스트가 유지된다고 말한다.[^39]

3.24 Q&A 2: AWS 활용이 늘수록 모니터링은 어떻게 바뀌나 — “통제 범위 변화”와 “서버리스”[^40]

질문: Dennis에게 “AWS를 활용하기 시작하면 모니터링이 어떻게 바뀌나”[^40]
Dennis는 먼저 AWS에서는 “환경을 더 이상(온프렘처럼) 통제할 수 없다”고 말한다. 대신 그 안에서 무엇을 올리고 어떻게 쓰는지는 통제하지만, 환경 자체는 관리 범위가 달라진다는 취지다.[^40]
두 번째로 서버리스 개념을 든다. EC2는 에이전트 설치로 동일한 게임이지만, 서버리스에서는 그 방식이 통하지 않는다고 한다.[^40]
그래서 이를 “혁신 기회”로 보고 접근했으며, 코드를 개발할 때 모니터링을 염두에 두어야 하고, 엔드포인트 데이터 수집에서 스트리밍 데이터 수집으로 바꾸는 것을 고려해야 한다고 말한다.[^41]
또한 어떤 메트릭/KPI를 볼지 “매우 신중해야” 하며, 그 KPI를 얻도록 설계를 해야 한다고 결론짓고, BMC 같은 회사가 모니터링 전략 수립을 도울 수 있다고 말한다.[^41]

3.25 Q&A 3: 비용/클라우드 비용 관리 전략 — CapEx vs OpEx, 유휴 자원, ‘매달 새는’ 과대 프로비저닝[^41]

질문: Seth에게 “비용 관리 전략을 더 말해달라”[^41]

Seth는 전통 데이터센터 용량 계획은 보통 3년(혹은 연간) 주기로 CapEx 구매를 계획하고 자산을 확보하는 방식이었다고 설명한다.[^42] 이때 과대 프로비저닝의 페널티는 “결국 쓰면 된다”는 논리로 상대적으로 작았다고 말한다.[^42]
하지만 3년 수요를 정확히 예측하기는 어렵고, 업계 연구로 서버 30%가 사실상 사용되지 않는 ‘코마토즈(comatose)’ 상태, 스토리지 40%가 미사용이라는 수치를 제시한다.[^42]

AWS로 가면 CapEx가 아니라 OpEx로 바뀌고, 자원 소비가 곧 비용이며 매달 청구서가 나온다고 말한다.[^43] Pay-as-you-go의 장점이 있지만, 과대 프로비저닝의 페널티가 “한 번의 감가상각이 아니라 매달 계속 과금”으로 더 심각해진다고 지적한다.[^43]
따라서 분석가들이 “cloud expense management”라고 부르는 영역이 중요해지며, 모든 AWS 서비스를 적극적으로 모니터링하며 비용과 성능의 균형을 맞춰야 한다고 주장한다.[^44]

특히 오토스케일/탄력성을 활용하려면 비즈니스 서비스의 사용량을 이해하고 그에 맞는 AWS 리소스 소비를 구성해야 한다고 말한다.[^44]
또한 운영(operations)이 일/주/월 단위로 사용량과 서비스 소비를 “계속” 관리해야 한다고 강조한다.[^45]

리프트&시프트 맥락에서는, 현재 온프렘에서의 사용량(평균/피크)과 전체 애플리케이션/서비스 딜리버리 컨텍스트를 이해하고, AWS 인스턴스 타입/리소스 매핑(예: t2.micro 등 표현)과 what-if 모델링으로 사이징을 해야 한다고 설명한다.[^45][^46]
단일 구성요소만 보고 옮기면 성능에 어떤 영향이 있을지 놓칠 수 있으므로, 가치사슬의 여러 애플리케이션 상호작용까지 포함해 전체 모델을 보라고 조언한다.[^46]
마지막으로 이 영역(클라우드 비용/전통 용량)이 “다시 뜨거워졌다(back to the future)”며, 마이그레이션 전에 현 상태를 정확히 파악하고 계획하라고 권고한다.[^47]

3.26 Q&A 4: 실제로 AWS로 무엇을 옮겼나 — “옴니채널 라우팅의 컴퓨트” 중심, 음성 스위치는 프라이빗 유지[^47]

질문: Dennis에게 “구체적으로 어떤 시스템을 AWS로 옮겼나”[^47]
Dennis는 **옴니채널 라우팅(omni-channel routing)**을 지탱하는 인프라를 옮겼다고 답한다.[^47]
즉 음성 기능을 뒷받침하는 컴퓨트 인프라를 퍼블릭 클라우드로 옮겼고, 반면 음성 스위치 같은 보이스 컴포넌트는 프라이빗 데이터센터(프라이빗 클라우드)에 남겼다고 말한다.[^48]
이는 리프트&시프트가 “모든 것을 다 옮기는 것”이 아니라, 지금 당장 AWS에 두는 게 말이 되는 것과 그렇지 않은 것을 구분하는 접근이었다고 설명한다.[^48]

3.27 Q&A 5: AWS와 Truesight는 어떻게 통신/통합하나 — CloudWatch/API, 에이전트, 스트리밍/체크 방식[^49]

질문: “AWS와 BMC Truesight는 두 시스템인데 어떻게 커뮤니케이션하나”[^49]
Seth는 통합 방식이 “3가지 모달리티”가 있고 유스케이스에 따라 다르다고 답한다.[^49]

1. CloudWatch 기반 커넥터/API 통합: AWS 계정 레벨에서 성능 텔레메트리 및 빌링(billing) 정보까지 API로 가져오며, 여러 AWS 계정도 자동 디스커버리 가능하다고 설명한다.[^49][^50] CloudWatch 메트릭과 빌링을 Truesight 모니터링/용량관리 솔루션으로 가져오는 유스케이스다.[^50]

2. **고정밀 모니터링(High fidelity)**을 위한 에이전트 모델: 특정 인스턴스는 “초경량 에이전트”로 텔레메트리를 Truesight로 직접 보낼 수 있다고 말한다.[^50]

3. 스트리밍 텔레메트리/에이전트리스 체크: Dennis가 말한 스트리밍 모델로 들어오는 텔레메트리를 관측하거나, ping/HTTP check 같은 방식으로 엔드포인트를 에이전트 없이 모니터링할 수도 있다고 언급한다.[^50][^51]

결국 서비스의 중요도, 원하는 정밀도, 계정 전체 vs 일부 범위, 빌링 정보 필요성에 따라 선택하며, NICE inContact는 서비스별로 이들을 혼합 사용한다고 설명한다.[^51]

3.28 Q&A 6: AWS의 빠른 혁신 속도를 따라잡는 방법 — 교육/지원/파트너 활용[^51]

질문: “AWS가 너무 빨리 혁신하는데 고객/파트너가 어떻게 따라가나”[^51]
Michael은 AWS 고객들이 혁신 속도 자체를 AWS 선택 이유로 든다고 말하며, 이를 돕기 위해:

• 트레이닝/자격증, 부트캠프, 글로벌 서밋, re:Invent 같은 이벤트[^52]
• TAM(Technical Account Manager), 솔루션스 아키텍트, AWS 프로페셔널 서비스와의 직접 상호작용[^52]
• 배포/운영을 돕는 수많은 시스템 통합 파트너 존재[^52] 등을 제시한다.[^52]

3.29 Q&A 7: 마이그레이션의 도전 — 서버리스에서의 용량 계획은 ‘비용 통제+예측’ 문제[^52]

질문: Dennis에게 “AWS 마이그레이션 중 겪은 도전과 해결”[^52]
Dennis는 가장 큰 도전으로 퍼블릭 클라우드에서의 용량 관리를 꼽는다.[^52]
프라이빗에서는 원리를 마스터했지만, 서버리스(람다, 마이크로서비스 등)에서는 용량 계획이 다르다고 말한다.[^53]
그의 결론은 다음과 같다:

• CapEx(고정 예산)에서 OpEx로 전환되며, 관리를 잘 못하면 비용이 “통제 불능”으로 커질 수 있다.[^53]
• 퍼블릭 클라우드에서는 “비용 통제(cost control)”가 핵심이며, 이를 캡처·추적·리포트하는 좋은 방법이 필요하다.[^53]
• 가장 중요한 것은 워크로드를 **예측(forecast)**할 수 있어야 한다는 점이다.[^53]
• 비용이 폭주할 잠재력도 있지만, 반대로 잘하면 비용 절감 잠재력도 크며, 이를 위해 좋은 용량 관리/통제 역량이 핵심이라고 말한다.[^53][^54]
• 이 과제는 “여전히 개발/개선 중”이라고 솔직히 말한다.[^54]

3.30 통합에 쓰는 프로토콜/API 및 마무리 안내[^54]

“웹 서비스나 XML 프로토콜을 쓰느냐”는 질문에, AWS 통합은 AWS API를 통한 직접 보안 API 통합이라고 답한다.[^54]
마지막으로 다음 단계로 BMC를 AWS Marketplace에서 찾아보라는 안내, Truesight 관련 페이지, AWS DevOps 페이지, AWS 체험 링크 등을 제공하며 종료한다.[^54][^55]

---

4. 핵심 통찰[^1]

1. [c DevOps의 목적은 ‘도구 도입’이 아니라 조직의 속도(velocity)를 높여 시장 경쟁력을 확보하는 것이다.] 철학·실천·도구가 결합될 때 빠른 개선/배포가 가능해진다는 프레임을 반복적으로 깐다.[^3][^5]

   • 실행: IaC/CI/CD를 “기술”이 아니라 배포/운영 리드타임을 줄이는 조직 시스템으로 설계한다.[^3][^5]

2. [h 하이브리드는 전환의 기본값이며, 통합 가시성은 ‘자산 리스트’가 아니라 ‘서비스 컨텍스트’여야 한다.] 이벤트/로그/메트릭이 많아질수록 컨텍스트 없이는 우선순위·영향도·라우팅이 불가능하다는 주장이 Q&A에서 구체화된다.[^38][^39]

   • 실행: 디스커버리로 자산 관계를 모델링하고, 서비스/애플리케이션 뷰를 운영(자동 갱신 포함)한다.[^38][^39]

3. [c 서버리스/마이크로서비스로 갈수록 모니터링은 ‘에이전트 설치’에서 ‘스트리밍 텔레메트리+코드 기반 관측’으로 바뀐다.] NICE inContact가 2단계에서 모니터링 모델을 바꿨다는 부분이 핵심 사례로 제시된다.[^28][^29]

   • 실행: KPI를 먼저 정의하고, 애플리케이션 코드/플랫폼 이벤트/커스텀 메트릭으로 피드백 루프를 설계한다.[^41]

4. [h AWS 전환은 ‘용량 관리 = 컴퓨트’에서 ‘용량 관리 = 비용’으로 관점 전환을 요구한다.] Seth와 Dennis 모두 CapEx→OpEx 변화와 과대 프로비저닝 비용 누수 위험을 강조한다.[^43][^53]

   • 실행: 리프트&시프트 전 “현재 사용량(평균/피크) + 서비스 딜리버리 전체 맥락”을 측정하고, what-if 사이징/비용 모델링을 수행한다.[^45][^46]

5. [h 성숙한 모니터링은 임계치(threshold)보다 ‘정상 대비 편차’(동적 베이스라인)로 더 빨리 잡아낸다.] NICE inContact는 이를 선제적 접근으로 평가하고 DevOps/고객 가치로 연결한다.[^30]

   • 실행: 단순 임계치 알람을 넘어 베이스라인/이상탐지 기반 알림 정책을 설계한다.[^30][^37]

6. [m “툴”의 성공 기준은 기능 나열이 아니라 결과(지표)로 증명되어야 한다.] MTTR 70% 감소, 5초 알림, CapEx 6분기 0 같은 수치가 의사결정 설득의 중심으로 등장한다.[^31]

   • 실행: 전환 프로그램의 KPI를 MTTR, 알림 리드타임, 비용/CapEx, 다운타임 크레딧 등으로 명시하고 추적한다.[^31][^53]

---

5. 헷갈리는 용어 정리[^2]

DevOps: 철학·실천·도구의 결합으로 조직의 속도(velocity)를 높여 더 빠른 제품 개선/배포를 가능하게 하는 운영/개발 모델.[^3]
Infrastructure as Code(IaC): 인프라를 코드로 프로비저닝/관리하여 버전관리·CI 같은 소프트웨어 기법을 인프라에 적용하는 방식.[^3]
Microservices: 하나의 애플리케이션을 작은 서비스들로 분해하고 API로 통신하게 하며, 서비스별 독립 배포가 가능한 아키텍처 접근.[^3]
CI(Continuous Integration): 개발자가 중앙 repo에 자주 머지하면 자동 빌드가 트리거되는 개발 관행.[^4]
CD(Continuous Delivery): CI 이후 변경을 사전 운영/운영 환경에 배포 가능 상태로 지속 유지하는 확장 관행.[^4][^5]
Shared Responsibility Model: AWS는 ‘클라우드의 보안’, 고객은 ‘클라우드 안의 보안’을 책임지는 보안/컴플라이언스 분담 모델.[^7]
CloudWatch: AWS 서비스/인스턴스에서 나오는 메트릭 등 텔레메트리를 API로 제공하는 모니터링 기반(웨비나에서는 Truesight 통합의 한 방식으로 언급).[^49][^50]
Single pane of glass: 온프렘+클라우드 전반의 상태/이벤트/컨텍스트를 한 화면/한 시스템에서 통합적으로 보는 운영 관점(중앙화된 관리/리포팅).[^24][^27]
Dynamic Baselining: 고정 임계치가 아니라 정상 상태 기준선 대비 편차를 감지해 이상을 더 선제적으로 탐지하는 접근.[^30]
MTTR: Mean Time To Resolution/Repair, 평균 복구(해결) 시간. NICE inContact는 70% 감소를 성과로 제시.[^31]
CapEx / OpEx: 자본 지출(장기 자산 구매) / 운영 지출(사용량 기반 비용). AWS 전환의 비용 패러다임 전환으로 반복 언급.[^43][^53]
Lift and shift: 애플리케이션 구조 변경 없이(또는 최소 변경) 기존 워크로드를 클라우드로 “그대로” 옮기는 방식.[^13][^33]
Serverless: 서버(인스턴스) 관리 없이 함수/관리형 서비스 중심으로 실행하는 모델(웨비나에서는 Lambda 예시로, 에이전트 설치 기반 모니터링이 어려워 전략 전환이 필요하다고 설명).[^28][^40]

---

참고(콘텐츠 정보)[^1]

• 제목: Transform Enterprise IT Infrastructure with AWS DevOps[^1]
• 채널/출처: Amazon Web Services (YouTube Webinar)[^1]
• 길이: 55분 26초[^1]
• 링크: https://www.youtube.com/watch?v=SMaeVYSZlcI[^1]
• 키워드(제공): AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud, real-time analytics, Zoomdata, MemSQL, Databricks, AWS Webinars[^1]

[^1]: @[00:01] "hi everyone welcome today's webinar transformed Enterprise IT infrastructure with AWS devops..." 및 영상 메타(사용자 제공 링크/길이/채널). [^2]: @[00:54] "understand the why and how it using a DevOps model... including hybrid environments..." [^3]: @[02:18] "DevOps as a combination of three factor... philosophies practices and tools..." + @[02:53] "four primary best practices... infrastructure as code microservices logging monitoring and CI CD..." [^4]: @[04:19] "creating alerts and performing real-time analysis..." + @[04:40] "CI CD for continuous integration..." [^5]: @[05:11] "continuous delivery... deployment ready build artifact..." + @[05:27] "benefits of DevOps on AWS include..." [^6]: @[06:05] "improve security... using IAM..." + @[06:46] "AWS shared responsibility model..." [^7]: @[07:17] "security of the cloud versus security in the cloud..." [^8]: @[08:08] "EC2... VPC... S3... categorized as infrastructure as a service..." + @[08:43] "AWS ... standards and certifications..." [^9]: @[09:15] "BMC has been in business for almost 40 years..." [^10]: @[10:12] "digital transformation... huge opportunity... likely to become disrupted..." [^11]: @[11:31] "there's likely groups... already leveraging AWS..." [^12]: @[12:03] "digitally transform... three times more likely..." + @[12:22] "IT becomes the business..." [^13]: @[12:50] "twice as likely... new markets..." + @[13:11] "90 percent higher return..." [^14]: @[14:00] "DevOps continuous integration... integrate seamlessly..." + @[14:19] "capacity management... cost... cloud expense management..." [^15]: @[15:14] "Truesight as a platform... across both the data center... and AWS..." [^16]: @[16:08] "unified view... single pane of glass..." + @[16:30] "service and application contexts..." [^17]: @[17:17] "requires a variety of automation and analytics techniques..." [^18]: @[18:39] "nice and contact is the global leader..." + @[18:56] "more than 250,000 agents..." + @[19:15] "85 of the Fortune 100..." [^19]: @[19:37] "complete solution of voice... analytics and automation..." + @[19:55] "pay for what you use..." [^20]: @[20:28] "we couldn't keep doing things the way we had been doing them..." [^21]: @[21:02] "private... dying dinosaur..." + @[21:22] "hybrid cloud... no established best practices... partnership with BMC and AWS..." [^22]: @[22:09] "keep our costs down... minimizing our downtime" + @[22:23] "monitoring for the sake of monitoring is... no value..." [^23]: @[22:57] "monitoring capacity management ITSM..." + @[23:15] "actionable feedback..." + @[23:31] "real time capabilities..." [^24]: @[24:12] "single pane of glass view..." (VP quote context) [^25]: @[24:54] "Darwin... most adaptable to change..." + @[25:27] "maturation... waterfall... DevOps and CI/CD... automation..." [^26]: @[26:02] "columns... patrol agent... network tool... voice... disjointed ITSM... chaotic..." [^27]: @[27:00] "truesight operations management... single pane of glass..." + @[27:19] "CMDB... ITSM... tickets..." + @[27:37] "monitoring is about feedback..." [^28]: @[27:54] "multi-phased approach... lift and shift..." + @[28:33] "agent on a VM..." [^29]: @[29:10] "develop... with monitoring in mind..." + @[29:25] "no longer monitor endpoints... now monitor streams of data..." + @[29:37] "complete telemetry feedback loop..." [^30]: @[30:15] "dynamic baselining... detect deviations..." + @[30:32] "not waiting... proactive..." [^31]: @[31:16] "MTTR reduction to seventy percent" + @[31:31] "within five seconds..." + @[31:53] "six consecutive quarters with no capital spend..." [^32]: @[32:16] "focus on what matters... CI/CD processes... projects versus unplanned work..." [^33]: @[33:17] "started with the lift and shift..." + @[33:37] "like-for-like... extending your data center..." + @[33:55] "introduced some services... decreasing VM footprint..." [^34]: @[34:23] "BMC AWS km... metrics... non-traditional endpoint..." [^35]: @[35:06] "compute... cost perspective..." + @[35:24] "introduce more automation... Bladelogic..." + @[35:42] "center of it all is BMC truesight..." [^36]: @[36:17] "in summary BMC truesight helps..." + @[36:34] "machine learning..." + @[36:52] "telemetry data..." [^37]: @[37:09] "dynamic baselines... multivariate anomaly detection... probable cause analysis... log analytics..." + @[37:21] Q&A 시작. [^38]: @[38:04] "telemetry data... without context..." + @[38:04]~@[38:28] "discovery... relationships... service view..." [^39]: @[38:44] "event storm... identify which business services are impacted..." + @[39:24] "rediscover... flows automatically..." [^40]: @[40:18] "you don't have control of these environments..." + @[40:33] "serverless... agent... doesn't work..." [^41]: @[41:09] "streaming data collection..." + @[41:25] "monitoring strategy..." [^42]: @[42:16] "capex model... three-year cycle..." + @[42:52] "30% of servers... comatose... 40% of storage unused..." [^43]: @[43:14] "capex model to an opex-model..." + @[43:55] "overprovision... now overpaying every month..." [^44]: @[44:19] "actively monitor... balance the cost... with the performance..." + @[44:47] "utilization... create the appropriate consumption..." [^45]: @[45:07] "operations needs to become... stay on top..." + @[45:26] "lift and shift... mapping..." [^46]: @[46:07] "entire service delivery context..." + @[46:22] "look at the entire service delivery model..." [^47]: @[47:16] "cloud expense management... research..." + @[47:41] 질문 전환. [^48]: @[48:03] "voice switches... stayed in our private..." + @[48:23] "lift and shift... not absolutely everything..." [^49]: @[49:10] "three different modalities..." + @[49:32] "leveraging cloud watch..." + @[49:50] "discover... consume cloud watch metrics..." [^50]: @[50:11] "agent model... super-lightweight agent..." + @[50:34] "streaming telemetry... ping... HTTP check..." [^51]: @[51:12] "depends on criticality... billing..." + @[51:45] 혁신 속도 질문. [^52]: @[52:01] "training and certifications... boot camps... reinvent..." + @[52:14] "TAM... solutions architect... professional services..." [^53]: @[52:51] "biggest challenges... capacity management..." + @[53:26] "operating expense... out of control..." + @[53:41] "forecast..." [^54]: @[53:58] "starting to get our arms around it..." + @[54:26] "leverage the AWS API..." + @[54:49] 마무리 링크 안내 시작. [^55]: @[55:11] "aws.amazon.com slash DevOps..." + @[55:24] "thank you everyone"