프로젝트에서 보기 →

AWS 에서 DevOps 시작하기 (레벨 200) – 정영준:: AWS Builders Online Series

태그
기술 AWS데브옵스
시작일
종료일
수정일

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

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

[? 질문] DevOps란 정확히 무엇이며, AWS에서 DevOps를 “시작한다”는 것은 무엇을 바꾸는 일인가[^2]
[= 답] DevOps는 **소프트웨어 개발(Development)**과 **IT 운영(Operations)**을 결합하기 위한 문화·철학·사례·도구의 조합이며, 목적은 빠른 피드백을 바탕으로 지속적으로 개선하는 개발 접근을 가능하게 만드는 것이다.[^3] 이를 위해서는 단순히 도구를 도입하거나 문화만 바꾸는 것이 아니라 운영 모델(조직/책임), 아키텍처 패턴(구조/분리/확장), **소프트웨어 배포(파이프라인/자동화)**가 함께 변화해야 한다.[^4]

[? 질문] “진정한 DevOps”를 가능하게 하는 조직/아키텍처 원칙은 무엇인가[^5]
[= 답] 서비스는 가능한 작은 독립 단위로 나누되(기능보다 스케일/확장 단위 중심), 각 서비스가 서로 다른 배포·개발 라이프사이클을 가질 수 있어야 하며, 팀은 2-Pizza Team(대략 15명 미만) 단위로 나뉘어 **개발팀이 직접 운영까지 책임(You build it, you run it)**지는 형태가 선결되어야 한다.[^6] 이를 가능하게 하려면 자동화가 필수이며, 서비스 간 결합은 API로 최소화해야 한다.[^7]

[? 질문] AWS에서 DevOps를 구현할 때 어떤 도구·서비스 조합으로 파이프라인을 구성하며, 최근에는 무엇이 추가되었는가[^8]
[= 답] 소스(CodeCommit)–빌드(CodeBuild)–배포(CodeDeploy)–관측(CloudWatch/X-Ray/CloudTrail Logs)–오케스트레이션(CodePipeline) 같은 AWS Developer Tools로 CI/CD 파이프라인을 구성할 수 있고, **CDK(Cloud Development Kit)**로 인프라/파이프라인을 “코드로” 더 쉽게 정의·배포할 수 있다.[^9] 대규모 환경에서 데이터/경보/상관관계 분석이 어려워지는 문제를 위해, AIOps/ML 기반의 Amazon DevOps Guru 같은 도구로 이상징후 탐지·노이즈 감소·원인 추정 등을 자동화하는 접근을 소개한다.[^10]

2. 큰 그림[^11]

이 콘텐츠는 AWS 솔루션즈 아키텍트가 “AWS에서 DevOps를 어떻게 시작할 것인가”를 레벨 200 난이도로 설명하는 세션이다.[^12] DevOps의 정의를 먼저 정교하게 잡고(단순 도구론/문화론 배제), 아마존 내부 사례(모놀리식→서비스 분리→파이프라인 분리)를 통해 조직·아키텍처·자동화가 함께 변해야 함을 보여준 뒤, AWS에서 이를 구현하는 개발자 도구와 CDK, 그리고 ML 기반 운영 인사이트 도구(DevOps Guru)까지 연결한다.[^13]

  • DevOps의 핵심은 빠른 피드백 루프이며, 이를 위해 운영 모델·아키텍처·배포 체계가 함께 진화해야 한다.[^14]
  • “마이크로서비스로 나눴다”만으로는 부족하며, 서비스는 독립적 라이프사이클과 API 기반 결합 최소화를 가져야 DevOps 효과(영향 최소화, 빠른 적용)가 난다.[^15]
  • AWS는 *Code 계열 도구 + 관측 도구 + IaC(CDK/CloudFormation) + AIOps(DevOps Guru)**로 엔터프라이즈급 DevOps 구현을 지원한다.[^16]

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

3.1 세션 구성: DevOps 개념 → 아마존 사례 → AWS 도구 → 추가 학습 경로[^18]

📸 0:31

발표자는 오늘 세션의 흐름을 먼저 제시한다.[^19]

  1. DevOps에 대한 기본 설명(정의/핵심 관점)부터 시작한다.[^20]
  2. 아마존에서 DevOps를 어떻게 해왔는지 간단히 소개한다.[^21]
  3. DevOps를 말할 때 흔히 등장하는 문화(Culture)–프랙티스(Practices)–도구(Tools) 축을 언급하고, 이들을 AWS 관점에서 간략히 정리한다.[^22]
  4. DevOps를 위한 AWS 도구들을 더 구체적으로 살펴본다.[^23]
  5. AWS가 고객 피드백을 받아 어떤 서비스/기능을 추가 개발해왔는지도 소개한다.[^24]
  6. 마지막으로 참고 가능한 링크/자료까지 안내한다.[^25]

[!NOTE] 발표자가 강조하는 전제
DevOps는 “이것만 하면 된다”는 단일 처방이 아니라, AWS에서도 여러 접근/시도를 했고 고객 피드백을 반영하며 서비스가 확장되어 왔다.[^26]

3.2 DevOps 정의를 다시 세우기: 문화·철학·사례·도구의 조합[^27]

📸 1:34

발표자는 “DevOps란 무엇인가”를 명확히 하려 한다.[^28]

  • DevOps는 소프트웨어 개발과 정보기술 운영을 결합한 형태의 문화, 철학, 사례(Practices), 도구(Tools) 조합이다.[^29]
  • 표현이 어렵게 들릴 수 있으나, 본질적으로는 빠르게 피드백을 받아 개선할 수 있게 만드는 새로운 개발 접근이라고 말한다.[^30]

여기서 DevOps를 단일 범주의 것(예: 자동화 도구, CI/CD, 혹은 조직문화)으로 축소하는 것을 경계한다.[^31] DevOps는:

  • 개발 방식(methodology)만의 변화가 아니라,[^32]
  • 팀을 새로 구성하고 운영 방식까지 바꾸며,[^33]
  • 도구를 도입하고 프로세스를 개선하는 것까지 포함하는,[^34]
  • “전체적인 형태의 접근 방법론”이다.[^35]

3.3 DevOps 변화에 필요한 3가지 모델: 운영 모델·아키텍처 패턴·소프트웨어 배포[^36]

📸 2:20

발표자는 DevOps를 위한 변화는 세 가지가 함께 필요하다고 못 박는다.[^37]

  • 오퍼레이션 모델(Operations model)[^38]
  • 아키텍처 패턴(Architecture pattern)[^39]
  • 소프트웨어 배포(Software delivery)[^40]

이 3가지는 “서로서로 긴밀히 연관되어” 같이 발전해야 한다는 논리다.[^41] 따라서:

  • DevOps는 “새 도구 도입”으로만 국한되지 않는다.[^42]
  • DevOps는 “팀 컬처를 바꾸는 것만”으로도 해결되지 않는다.[^43]
  • [h 이 모든 것이 동시에 수반되어야 가능한 접근]이라고 설명한다.[^44]

3.4 아마존의 DevOps 진화 5가지 특징: 작은 단위, 자동화, 표준화, 관리되는 프로세스, IaC[^45]

📸 2:57

아마존에서 DevOps를 오래전부터 해왔고, 그것이 어떤 형태로 발전해왔는지 논의가 있었다고 하며, 이를 5가지 특징으로 정리한다.[^46]

  1. 유연함을 위해 작은 단위로 개발/배포 단위를 분리했다.[^47]

    • 변화(릴리즈)를 더 자주/더 안전하게 하기 위해 단위를 줄이는 방향이다.[^48]

  2. 개발·배포·디버깅·운영 등 수동 작업을 제거하고 대부분 자동화했다.[^49]

    • 도구를 활용해 배포하고, 모니터링하고, 탐지하는 흐름이 자동화되었다고 말한다.[^50]

  3. 팀마다 제각각 도구를 만들거나 익숙한 도구를 쓰는 방식보다 표준화된 도구 + 표준 프로세스를 활용했다.[^51]

    • 개인/팀 편차를 줄이고 재사용 가능한 체계를 만드는 의미로 전개된다.[^52]

  4. 파이프라인은 “자동화만”이 아니라 프로세스에 의해 매니지드되고, 디버깅/리뷰 가능해야 하며,
    새 프로젝트나 새 개발자가 와도 적응 가능하도록 표준 프로세스 안에서 일할 수 있게 구성했다고 설명한다.[^53]

  5. **인프라를 코드로 관리(IaC)**하여 로지컬하게 관리하고, 코드처럼 리뷰/개선 가능하게 만들었다.[^54]

[!IMPORTANT] DevOps를 “자동화”로만 보면 놓치는 포인트
발표자 설명에서 자동화는 핵심이지만, 그 자동화가 표준화된 도구/프로세스, 리뷰·디버깅 가능한 운영 체계, IaC 기반 변경관리와 결합되어야 한다는 흐름으로 제시된다.[^55]

3.5 아마존 초기의 문제: 하나의 거대한 웹페이지/서비스, 하나의 파이프라인, 느린 적용 사이클[^56]

📸 4:55

아마존의 초창기(특히 Amazon.com)는 “모놀리식 형태의 웹 페이지”였다고 말한다.[^57] 이 구조에서는:

  • 작은 변화 하나를 적용하기 위해서도, 개발자들이 각각 특정 영역(예: 카트 등)을 담당하지만 결과적으로는 전체 서비스 업데이트 사이클을 따라야 한다.[^58]
  • 운영 파이프라인도 “단 하나”에 가까워서, 빌드/테스트/모니터링 등이 모든 개발자가 특정 시점에 변경분을 한꺼번에 넣고, 서비스 적용까지 특정 사이클을 기다리는 형태가 된다.[^59]

즉, 피드백과 릴리즈가 느리고 결합이 크다.[^60]

3.6 1차 개선: 서비스 단위로 분리, 팀 분리로 개발 효율 향상[^61]

📸 5:37

이를 해결하기 위해 아마존은:

  • 서비스를 더 작은 형태로 나누고,[^62]
  • 서비스 단위로 개발팀을 분리하고,[^63]
  • 그 결과 운영 파이프라인/개발 효율을 향상시킬 수 있었다고 설명한다.[^64]

하지만 여기서 끝이 아니라고 이어간다.[^65]

3.7 2차 개선: 마이크로서비스여도 파이프라인이 하나면 DevOps가 “완벽”해지기 어렵다[^66]

📸 6:05

서비스(애플리케이션) 자체가 클라우드 네이티브/마이크로서비스 구조로 바뀌어도,[^67] 운영 파이프라인이 하나로 묶여 있으면 DevOps를 완전하게 구현하기 어렵다고 말한다.[^68]

그래서 운영 파이프라인도 서비스 단위로 분리한다.[^69]
그 결과:

  • 개발자와 서비스 운영 파이프라인이 각각 “자기 서비스”에 얼라인되고,[^70]
  • 개발자가 운영도 하면서 피드백을 바탕으로 다시 개발하는 형태의
    마이크로서비스 개발 라이프사이클 구성이 가능해진다고 설명한다.[^71]

3.8 고객들이 흔히 하는 오해/다양한 접근: 모놀리식+자동화면 DevOps인가?[^72]

📸 6:52

발표자는 고객을 만나보면 DevOps 접근이 다양하다고 말하며, 흔한 케이스를 든다.[^73]

  • 여전히 모놀리식 아키텍처인데도,[^74]
  • “이미 자동화 툴을 다 쓰고 있고 모듈별로 나뉘어 있으니 DevOps다”라고 말하는 경우를 본다고 한다.[^75]

발표자는 이 접근이 “가능”할 수는 있으나, DevOps의 최고의 장점(빠른 피드백/영향 최소화)을 온전히 달성하기는 어렵다고 논리를 편다.[^76]

  • DevOps의 강점: 빠른 피드백을 적용하고,[^77]
  • 잘못되어도 전체 서비스에 미치는 영향(블라스트 레디우스)을 최소화하는 것인데,[^78]
  • 모놀리식은 그 목표를 만족시키는 아키텍처로 보기 어렵다는 취지다.[^79]

3.9 서비스 분리 원칙: 기능/컴포넌트가 아니라 “스케일 단위”로 나눠라[^80]

📸 8:07

발표자는 “서비스를 나눌 때 기능 단위로 나눠야 한다”는 일반적 생각을 언급하며 다른 관점을 제시한다.[^81]

  • 기능/컴포넌트 단위로만 나누는 접근보다는,[^82]
  • 스케일(확장) 단위로 나누는 것이 운영/관리 측면에서 더 편하다고 말한다.[^83]

또한:

  • 가능한 작은 유닛으로 가져가되(작은 단위),[^84]
  • 데이터는 특정 도메인 안에서 활용되게 하고,[^85]
  • 각 서비스는 스케일 단위/확장 단위 기반으로 분리해 관리하는 것이 좋은 프랙티스라고 정리한다.[^86]

3.10 독립 라이프사이클이 핵심: 서비스 간 결합을 API로, 상호 영향 최소화[^87]

📸 8:29

발표자는 서비스 A, B 예시를 든다.[^88]

  • A와 B가 각자 개발 주기가 분리되어 있다면,[^89]
  • A 팀과 B 팀이 배포/개발을 위해 매번 “긴밀하게 커뮤니케이션”할 필요가 없어야 한다는 취지다.[^90]

대규모 환경에서 배포할 때마다 “다른 서비스 영향”을 고려해야 한다면, 그것은 DevOps/애자일 환경으로 보기 어렵다고 말한다.[^91]

따라서 결론은:

  • 각 서비스는 서로 다른 라이프사이클로 움직일 수 있어야 하고,[^92]
  • 통합은 API로 하며,[^93]
  • 서비스 간 제약을 최소화해야 한다.[^94]

이것이 서비스를 나누는 원칙 중 “매우 중요한 원칙”이라고 강조한다.[^95]

3.11 조직 모델: 2-Pizza Team과 “개발팀이 직접 운영” (문화 변화의 선결 과제)[^96]

📸 9:15

서비스 분리 원칙은 조직 설계로 이어진다.[^97]

  • 서비스를 직접 운영하는 팀 단위로 조직을 나누고,[^98]
  • 서비스 간 제약을 최소화하며,[^99]
  • 개발 결정(우선순위/방향)을 서비스 단위·팀 단위로 내릴 수 있게 만드는 것이[^100] DevOps에서 선결되어야 하는 중요한 과제이며, 문화적 변화의 전제 요건이라고 말한다.[^101]

그리고 “이 모든 것들을 개발팀이 직접 운영”해야 한다고 다시 강조한다.[^102]

  • 개발, 보안, 운영, 버그 테스팅, 서비스 분석까지 모두 개발팀이 할 수 있게 조직을 재구성해야 한다는 주장이다.[^103]

다만 작은 팀이 이 모든 것을 하기에는 부담이 있으므로 자동화가 필수라는 논리로 이어진다.[^104]

3.12 2-Pizza Team이란 무엇인가: 대략 15명 미만, 자동화 없이는 감당 불가[^105]

📸 10:08

발표자는 2-Pizza Team을 설명하며 농담 섞인 질문을 던진다.[^106]

  • 피자를 많이 먹는 사람 기준이면 2명일까?
  • 100명이 먹는 거대한 피자면 100명 팀일까?[^107]

그리고 일반적으로는:

  • 2-Pizza Team은 “12명~15명 미만”의 팀을 의미한다고 정리한다.[^108]

이런 규모의 팀이 개발/운영/보안/테스트/분석까지 감당하려면:

  • 앞서 말한 다양한 일들을 자동화하지 않으면 감당할 수 없게 된다고 말한다.[^109]

자동화는 개발 단계에서 빠르게 개발하는 것뿐 아니라,[^110]

  • 검증/테스팅 단계 자동화,[^111]
  • 프로덕션 레벨 품질 검증,[^112]
  • 사전 데이터를 확보/추출(표현상 “데이터 사전 데이터들을…”)[^113] 같은 운영 품질 체계를 포함하는 방향으로 언급된다.[^114]

3.13 아키텍처 변화는 DevOps의 선결 과제: 독립 확장 가능한 구조 + 이를 지탱하는 인프라 필요[^115]

📸 11:56

발표자는 조직/자동화만으로는 부족하다고 다시 선을 긋는다.[^116]

  • 팀이 자동화하고 DevOps 필요성을 인식해도,[^117]
  • 아키텍처가 DevOps/애자일에 적합하게 변화하지 않으면 DevOps가 될 수 없다고 말한다.[^118]

현대적 애플리케이션의 요구사항으로:

  • 독립적으로 확장 가능한 구조,[^119]
  • 이를 지원하는 인프라스트럭처[^120] 가 필요하며, 애플리케이션 아키텍처도 DevOps를 위해 변화해야 한다는 결론이다.[^121]

3.14 산업 사례 언급: Airbnb, Oscar, Gilt, MLB 등의 DevOps 활용 맥락[^122]

📸 12:19

발표자는 다양한 산업군에서 조직/아키텍처/인프라 변화로 DevOps가 이미 적용되고 있고 좋은 사례가 공유된다고 말한다.[^123]

  • 오스카(Oscar), 에어비앤비(Airbnb), 길트(Gilt) 등은 DevOps/오픈소스/컨퍼런스에서 주요 사례로 소개되어 왔다고 언급한다.[^124]
  • MLB 사례는 “마이너리그 경기”처럼 트래픽/이벤트 변동이 큰 상황에서:[^125]
    • 중계 시스템/데이터 수집 시스템을 확장해 DevOps 테스트 등을 수행하고,[^126]
    • 시즌 오프가 되면 정리해 비용 효율적 구조를 만들며,[^127]
    • DevOps를 적용하는 전략의 예로 제시한다.[^128]

3.15 AWS DevOps 도구 개요: 개발→스테이징→프로덕션 파이프라인에 필요한 것들[^129]

📸 13:35

이제 발표는 “DevOps를 위한 AWS 도구가 무엇인지”로 넘어간다.[^130]

발표자는 DevOps 파이프라인을 예로 들어 단계별 도구 필요성을 설명한다.[^131]

개발(Development) 단계

  • 소스 저장/관리를 위한 CodeCommit[^132]
  • 다양한 개발환경 플러그인/IDE로 Cloud9 언급[^133]
  • “AWS Developer Tools” 묶음으로 개발 단계 도구들을 지칭[^134]

스테이징(Staging) 단계

  • 디펜던시(Dependency) 체크[^135]
  • 패키징, 빌드[^136]
  • 검증/테스트 도구 필요[^137]

프로덕션(Production) 단계

  • 프로덕션에서 동작 가능한지 더 강한 테스트 필요[^138]
  • (표현상) 카오스 엔지니어링처럼 실패를 주입해 안정성을 검증하는 접근도 언급[^139]
  • 네트워크 구성의 적정성, 성능 테스트 등의 필요성[^140]

발표자는 베타/감마/프로덕션으로 환경을 나눌 수도 있다고 말한다.[^141]

  • 베타에서는 성능 테스트 위주로 데이터 추출,[^142]
  • 감마에서는 프로덕션과 거의 동일한 환경을 만들어 프로덕션 준비 상태를 검증,[^143]
  • 이러한 일련의 파이프라인을 구성할 필요가 있다는 전개다.[^144]

3.16 Code*와 관측 도구로 구성하는 AWS 파이프라인 레퍼런스[^145]

📸 15:15

발표자는 AWS가 제공하는 도구들을 파이프라인 요소로 정리한다.[^146]

  • 소스: CodeCommit[^147]
  • 빌드: CodeBuild[^148]
  • 테스트: CodeBuild + 다양한 서드파티 도구[^149]
  • 배포: CodeDeploy + “다양한 형태의 디플로이먼트 툴”[^150]
  • 모니터링/성능 검증: X-Ray, CloudWatch, CloudTrail Logs(표현상 ‘클라우드와치 클라우드와 7 로고스’)[^151]
  • 전체 파이프라인 오케스트레이션/모니터링: CodePipeline[^152]

발표자는 각 서비스를 하나하나 자세히 설명하기는 어렵다고 하면서도,[^153] AWS가 엔터프라이즈에서 사용할 수 있는 “엔터프라이즈급 DevOps 도구들”을 CI/CD, IaC, 모니터링, 서포트 등 다양한 범주로 제공한다고 말한다.[^154]

또한 2020 re:Invent에서 AI 기반 DevOps 도구까지 제공하게 되었다고 언급하며(후반부 DevOps Guru로 연결), 자료를 참고하면 도움이 된다고 말한다.[^155]

3.17 마이크로서비스/서버리스에 최적화된 AWS 개발자 도구, 그리고 고객 피드백 기반 확장(2016년 이후)[^156]

📸 16:37

발표자는 AWS 개발자 도구들이 특별히 마이크로서비스와 서버리스를 지원하도록 제작되어 왔다고 말한다.[^157]

  • 2016년 이후 고객 피드백을 바탕으로 다양한 기능을 추가해왔고,[^158]
  • 엔터프라이즈급 DevOps 환경을 고객이 직접 도구를 만들지 않고도[^159]
  • AWS 개발도구로 표준화된 방식으로 적용할 수 있다는 메시지다.[^160]

3.18 인프라 유연성이 DevOps를 좌우: VM 직접 운영 vs 관리형(서버리스/컨테이너)로 집중 영역을 바꾸기[^161]

📸 17:17

발표자는 아키텍처 변화가 운영 책임 모델 변화와 연관된다고 말하며,[^162] DevOps를 잘 하려면 인프라가 아키텍처 변화를 유연하게 수용해야 한다고 주장한다.[^163]

이를 위해 많이 사용하는 것이:

  • **서버리스(Serverless)**와 **컨테이너(Container)**라고 말한다.[^164]

여기서 선택지를 제시한다:

  • VM 기반(EC2 등)으로 직접 인프라를 운영/관리할 수도 있고, 그것으로도 DevOps는 가능하다.[^165]
  • 하지만 DevOps를 하게 되면 팀은 애플리케이션 배포/빌드 파이프라인 등에 더 집중해야 하는데,[^166]
  • 네트워크/인스턴스 관리 같은 인프라 운영에 노력(시간)을 쓰기보다는,[^167]
  • 애플리케이션 아키텍처 개선과 기능 추가에 더 집중하는 편이 “훨씬 더 좋다”는 방향으로 설명한다.[^168]

그래서:

  • Lambda, EKS(및 “남다… 2 ks”로 발화된 관리형 서비스들)를 사용해 AWS가 운영/관리해주는 인프라 위에서 DevOps를 하면 운영이 더 편하고 효율이 좋아진다고 말한다.[^169]

서버리스는 Lambda만이 아니라:

  • API Gateway, S3, Aurora Serverless, DynamoDB 등도 있어 데이터베이스/데이터 계층까지 서버리스 형태로 활용할 수 있다는 점을 짚는다.[^170]

컨테이너 중심 고객에게는:

  • EKS 또는 ECS로 컨테이너 워크로드를 배치/관리할 수 있다고 안내한다.[^171]

3.19 마이크로서비스 도입 시 소프트웨어 딜리버리에서 자주 나오는 4가지 질문[^172]

📸 19:08

DevOps 환경에서 소프트웨어 딜리버리는 더 발전(고도화)된다고 말하며,[^173] 마이크로서비스 적용 시 자주 나오는 질문들을 나열한다.[^174]

  1. 릴리즈 프로세스가 너무 다양한데 어떻게 적용할 것인가[^175]
  2. DevOps 모범 사례를 어떻게 만들고 적용할 것인가[^176]
  3. 내부적으로 어떤 방법론/프로세스로 이를 수행할 것인가[^177]
  4. 분산 아키텍처에서 로깅/모니터링을 어떻게 할 것인가 (서버리스 포함)[^178]

그리고 “프로비저닝(Provisioning)하는 베스트 프랙티스 아키텍처”를 AWS 서비스 기반으로 제공하고 있다고 연결한다.[^179]

  • 예: CodePipeline + Lambda를 이용한 방법도 있다고 언급한다.[^180]
  • 다만 “가장 좋은 방법”은 한눈에 보이고 통제/관리 가능한 방식이라고 말한다.[^181]

3.20 CDK(Cloud Development Kit): 프레임워크처럼 IaC/파이프라인을 코드로 구현[^182]

📸 20:08

발표자는 “한눈에 보이고 통제 가능한 방법” 중 하나로 AWS CDK를 제시한다.[^183]

CDK의 포지셔닝:

  • 애플리케이션을 개발할 때 “프레임워크를 사용하듯이” CDK를 사용해 DevOps를 구현할 수 있다고 말한다.[^184]

화면 예시로 설명하는 흐름(발표자가 강조하는 ‘코드 몇 줄’ 감각):

  • VPC 생성이 한두 줄 코드로 가능하다고 말한다.[^185]
  • 생성된 VPC에 애플리케이션을 “패키징해서 넣을 수 있는” 구성 요소를 객체화해 생성할 수 있다고 설명한다.[^186]
  • 서버를 부트스트래핑하고 연결한 뒤,[^187]
  • 오토스케일링 그룹을 VPC에 연계해 지정하면,[^188]
  • 애플리케이션 배포가 곧 Infrastructure as Code로 배포되며,[^189]
  • 결과적으로 DevOps 파이프라인을 코드로 관리하게 된다고 말한다.[^190]

또한 CDK로 배포하면:

  • CDK 정의가 CloudFormation 템플릿으로 변환되고,[^191]
  • CloudFormation이 애플리케이션을 배포/관리하므로,[^192]
  • DevOps가 CloudFormation 기반으로 구성되는 형태라고 설명한다.[^193]

기존에는 CloudFormation이 “복잡해서 DevOps 하기 어렵지 않냐”는 인식이 있었는데,[^194] CDK를 쓰면 그 복잡성을 줄여 더 쉽게 할 수 있다는 점을 장점으로 제시한다.[^195]

[!TIP] CDK를 DevOps 관점에서 이해하는 한 문장
“인프라 구성(네트워크/컴퓨팅/오토스케일링)과 배포 파이프라인을 애플리케이션 코드처럼 작성·리뷰·배포하게 해주는 도구”로 소개된다.[^196]

3.21 지속적 배포와 블루/그린 배포: 트리거→아티팩트→빌드→배포의 자동 흐름[^197]

📸 21:40

발표자는 DevOps의 “가장 큰 장점”으로 **지속적인 배포(Continuous Deployment)**를 든다.[^198]
그리고 프로덕션 레벨에서는 **블루/그린 배포(Blue/Green Deployment)**를 하게 된다고 말한다.[^199]

CDK/IaC 기반으로 파이프라인을 구성하는 예시 흐름:

  • 소스 액션 등을 지정하고,[^200]
  • Git 리포지토리 트리거로 변경을 감지하면,[^201]
  • 훅(Hooking)하여 자동으로 아티팩트를 생성하고,[^202]
  • CodeBuild를 호출해 배포하는 구조를 만든다고 설명한다.[^203]
  • 결과적으로 빌드 프로젝트 기반 자동 배포가 되어 “코드로 인프라를 배포”할 수 있게 된다는 결론이다.[^204]

블루/그린 배포를 발표자가 설명하는 방식

  • 블루(Blue): 기존 운영 중인 아티팩트/환경[^205]
  • 그린(Green): 새 버전이 배포된 새로운 환경[^206]
  • 그린 환경이 정확히 배포됐는지 전환 전 검증을 수행하고,[^207]
  • 트래픽을 일정 수준 이상 전환해 본 뒤,[^208]
  • 문제 없으면 그린으로 완전 전환,[^209]
  • 이후 블루 환경을 제거하는 방식이라고 설명한다.[^210]

발표자는 이런 배포도 IaC로 “간단하게” 할 수 있다고 정리한다.[^211]

3.22 마이크로서비스가 커질수록 운영 데이터가 폭증: 넷플릭스 사례로 보는 복잡성, 그리고 사람이 감당하기 어려운 상관관계 분석[^212]

📸 23:27

발표자는 최근 AWS가 개발자 친화 기능을 늘렸다고 말한 뒤,[^213] re:Invent에서 소개된 “고급 DevOps 도구”로 DevOps Guru를 소개하기 전에 넷플릭스 마이크로서비스 구조를 예로 든다.[^214]

넷플릭스는 DevOps를 잘하는 사례로 유명하지만,[^215] 시간이 지나면 화면처럼 아키텍처가 매우 복잡해진다고 말한다.[^216]

  • 서비스는 스케일 아웃 포인트 기준으로 나누다 보면 쉽게 수백 개가 되고,[^217]
  • 수십~수백 서비스가 복잡한 호출 구조를 가진다.[^218]
  • 이때 모니터링/관리가 어려워진다.[^219]

문제의 핵심은 “피드백을 줄 수 있느냐”로 연결된다.[^220]

  • 수십 개 서비스가 오케스트레이션되고,[^221]
  • 데이터를 모아 의미를 추출해 피드백을 주는 일이 필요하지만,[^222]
  • 사람에게는 데이터량이 너무 많고 어려울 수 있다는 주장이다.[^223]

대규모 DevOps 환경에서 생기는 구체적 어려움으로 발표자는 다음을 든다:

  • 파이프라인에서 발생하는 데이터 볼륨이 매우 크다.[^224]
  • 단계별 데이터 패턴이 서로 이질적이라 모니터링하고 의미를 추출하기 어렵다.[^225]
  • 문제 발생 시 데이터 소스/도구들이 완전히 연관되지 않는 경우가 있어, 개발자/운영자가 **수동으로 상호 연결(상관관계 분석)**해야 하는 일이 생긴다.[^226]
  • 새 서비스가 추가되면 새 모니터링 팩터/메트릭이 필요해지고, 패턴이 복잡해져 “어느 순간” 문제가 되는데, 이를 찾기 위한 인사이트가 필요하다.[^227]
  • DevOps/CloudOps에는 비즈니스 도메인 전문지식이 필요해지지만 이는 모든 사람이 갖기 어렵다.[^228]
  • 자잘한 경보가 많이 발생하고 누적되면, 중요한 경보도 놓치게 된다.[^229]

3.23 해결 방향: AIOps/ML 기반 접근, Amazon DevOps Guru의 역할[^230]

📸 26:24

이 문제에 대해 발표자는 “어떻게 대응할 수 있을까”라는 질문을 세우고,[^231] 답으로 AI/ML(머신러닝) 기반 접근을 제시한다.[^232]

  • 개발자/운영자가 찾아내기 어려운 패턴/메트릭 변화를 모니터링하여 사용자에게 알려주고 대응하게 해주는[^233]
  • 새로운 형태의 모니터링 DevOps 도구가 DevOps Guru라고 설명한다.[^234]

Kubernetes, 컨테이너 환경에서:

  • 컨테이너 인프라/네트워크 로그,[^235]
  • 서비스 응답 속도/Latency 변화 등의 패턴을 모니터링하고,[^236]
  • 예를 들어 특정 패턴이면 EC2 인스턴스 자원이 부족해진다든지,[^237]
  • 네트워크 패턴이면 공격 가능성이 있다든지 하는[^238] “흐름 디텍팅/어브노말(이상) 디텍팅” 요구가 있었는데,[^239] DevOps Guru는 이런 것을 인프라 레벨에서 처리하도록 도와주는 도구로 이해하면 된다고 말한다.[^240]

“SageMaker나 Kubeflow로도 되지 않나?”에 대한 답

발표자는 반론 가능성을 먼저 언급한다.[^241]

[? 질문] SageMaker나 Kubeflow로도 이상 탐지/ML을 구현할 수 있는데, 왜 DevOps Guru인가[^242]
[= 답] 물론 가능하지만, DevOps Guru를 쓰면 그런 도구들로 ML을 구성해 DevOps 레벨로 전개하는 것보다 훨씬 손쉽게 사용할 수 있고, DevOps 파이프라인에 바로 집어넣을 수 있으며, 운영 문제를 자동 감지해 인사이트를 제공하므로 사용자는 애플리케이션 개선/빌드에 집중할 수 있다는 설명이다.[^243]

3.24 DevOps Guru의 기능 설명: 심각도 높은 이상 감지, 노이즈 제거, 변경 추적, 로그/메트릭 연관, 인텔리전트 모니터링[^244]

📸 28:42

발표자는 DevOps Guru가 해주는 일을 비교적 구체적으로 열거한다.[^245]

  • 심각도 높은 사고/이상을 감지[^246]
  • 노이즈 제거[^247]
  • 장애와 트리거된 관련 메트릭들의 이상 및 변경사항 추적[^248]
  • 로그 이벤트를 서로 연관(상관관계)시키기[^249]
    • 즉 사용자가 놓친 로그, 연관관계를 몰라 의미를 찾기 어려운 부분을 찾도록 도움[^250]
  • 상황별로 어떤 데이터를 “장애”로 볼지 “원인”으로 볼지에 대한 가치 분석을 도와줌[^251]
  • 결과적으로 더 인텔리전트한 모니터링 환경을 구성할 수 있다고 말한다.[^252]

적용/배포 단위

  • 계정(Account) 단위 또는 CloudFormation 단위로 적용/관리할 수 있다고 한다.[^253]
  • CloudFormation 단위 적용은 앞서 말한 CDK 기반 디플로이 파이프라인 단위 적용과 같은 의미라고 연결한다.[^254]

데이터/통합

  • DevOps Guru의 데이터셋 안에서 통계 및 로그 분석을 시작해 인사이트를 생성해 볼 수 있다고 언급한다.[^255]
  • SNS 및 서드파티 플랫폼과 통합해 DevOps Guru 알림(노티피케이션)을 활용할 수 있다고 말한다.[^256]
  • 이렇게 하면 DevOps가 단순 자동화 도구를 넘어 AI/ML로 “현대화된 빌드 파이프라인” 형태로 활용되도록 돕는다고 결론 낸다.[^257]

3.25 결론: AWS 도구는 엔터프라이즈급으로 인정, 베스트 프랙티스/사례 기반으로 DevOps 시작에 도움[^258]

📸 30:20

마지막 결론 파트에서 발표자는 다음을 정리한다.[^259]

  • AWS의 디플로이먼트(배포) 툴은 2018년 이후 다양한 분야에서 인정받아왔다고 말한다.[^260]
  • 엔터프라이즈급 도구 세트와 현대화된 애플리케이션을 위한 구축 솔루션, 베스트 프랙티스를 제공하는 것으로 알려져 있다고 언급한다.[^261]
  • AWS는 광범위한 사용 사례를 바탕으로 대규모 고객 사례 지원 경험이 있다고 설명한다.[^262]
  • 그래서 DevOps 환경을 배포(구축)하는 데 도움이 될 것이라고 말한다.[^263]

또한 AWS는 “한두 가지 도구만”이 아니라 여러 도구로:

  • DevOps 파이프라인을 어떻게 빌드할지,[^264]
  • 모니터링을 어떻게 향상시킬지,[^265]
  • 파이프라인을 어떻게 발전시킬지,[^266]
  • 성장하는 다른 개발팀들은 팀 구성/컬처를 어떻게 바꾸는지[^267] 등의 베스트 프랙티스를 볼 수 있으니, DevOps 시작 시 AWS 도구를 적극 활용하라고 권한다.[^268]

마지막으로:

  • 화면의 링크를 통해 개발자 도구/블로그 포스트로 더 자세한 정보를 확인할 수 있고,[^269]
  • 디지털 교육 자료도 참고해 DevOps와 AWS 개발자 도구를 공부하면[^270]
  • 개발 환경을 더 현대화된 환경으로 발전시키는 데 도움이 될 것이라고 마무리한다.[^271]
  • 세션 청취 감사 및 설문 요청으로 종료한다.[^272]

4. 핵심 통찰[^273]

  1. DevOps는 “CI/CD 도구 도입”이나 “문화 개선” 중 하나가 아니라 운영 모델·아키텍처·배포 체계가 함께 바뀌는 총체적 변화로 정의된다.[^274]
  2. DevOps의 가치(빠른 피드백/영향 최소화)를 얻으려면, 서비스는 작아야 할 뿐 아니라 서로 독립적인 라이프사이클을 가져야 하며 결합은 API로 최소화되어야 한다.[^275]
  3. 서비스 분리는 기능 중심 사고에서 벗어나 스케일/확장 단위 중심으로 해야 운영이 쉬워진다는 관점을 제시한다.[^276]
  4. 2-Pizza Team처럼 작은 팀이 end-to-end(개발~운영~분석)를 책임지려면, 인간의 노력으로는 한계가 있어 자동화와 표준 프로세스가 사실상 전제 조건이 된다.[^277]
  5. 마이크로서비스가 커질수록 운영 데이터/경보/상관관계가 폭증해 “사람이 이해하기 어려운 복잡성”이 생기며, 이 지점에서 AIOps(DevOps Guru) 같은 ML 기반 도구가 필요해진다는 문제의식을 제시한다.[^278]
  • 실행 시사점(콘텐츠가 권하는 방향을 행동으로 옮기면)[^279]
    • 서비스가 “나뉘어 있긴 한데” 배포가 서로 얽혀 있다면, 서비스별 파이프라인 분리를 우선 점검한다.[^280]
    • 팀이 작을수록 수동 운영을 줄이기 위해 표준화된 도구/프로세스를 채택하고 자동화 범위를 넓힌다.[^281]
    • IaC를 CloudFormation만으로 접근하기 어렵다면 CDK로 추상화해 파이프라인/인프라를 코드처럼 다룬다.[^282]
    • 경보 노이즈/원인분석에 시간이 많이 든다면 DevOps Guru와 SNS/서드파티 연동으로 이상탐지·알림 흐름을 구성하는 방식을 검토한다.[^283]

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

  • DevOps: 개발과 운영을 결합하기 위한 문화·철학·사례·도구의 조합이며, 빠른 피드백 기반 개선을 목표로 하는 접근.[^285]
  • 운영 모델(Operations model): 누가 무엇을 운영 책임지는지(조직/책임/프로세스) 관점의 구조.[^286]
  • 아키텍처 패턴(Architecture pattern): 서비스를 어떻게 나누고 결합을 어떻게 줄이며(예: 마이크로서비스), 독립 확장성을 어떻게 확보하는지에 대한 구조적 방식.[^287]
  • 소프트웨어 배포(Software delivery): 빌드–테스트–배포–검증을 포함한 전달 체계(파이프라인) 전반.[^288]
  • 2-Pizza Team: 피자 두 판으로 먹을 수 있을 정도의 작은 팀, 발표에서는 대략 15명 미만 규모로 설명.[^289]
  • IaC(Infrastructure as Code): 인프라를 코드로 정의/리뷰/배포/관리하는 방식.[^290]
  • AWS CDK(Cloud Development Kit): 인프라를 고수준 코드로 정의하면 CloudFormation 템플릿으로 변환해 배포되게 하는 IaC 도구(프레임워크처럼 사용한다고 설명).[^291]
  • Blue/Green Deployment: 기존(Blue)과 신규(Green) 환경을 병행해 검증 후 트래픽 전환, 문제 없으면 완전 전환 후 기존 제거.[^292]
  • AIOps / DevOps Guru: ML 기반으로 운영 데이터/메트릭/로그의 이상 징후를 감지하고 노이즈를 줄이며 상관관계를 제안해 인사이트를 제공하는 도구로 소개.[^293]

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

  • 제목: AWS 에서 DevOps 시작하기 (레벨 200) – 정영준:: AWS Builders Online Series[^295]
  • 채널: Amazon Web Services Korea[^296]
  • 길이: 32분 27초[^297]
  • 링크: https://www.youtube.com/watch?v=_VEds_73Guc[^298]

[^1]: @[00:31] “대고 옵스 시작하기… 먼저… 데브옵스에 대해서 한번 설명… 아마존에서 데브옵스를 어떻게 했는지… 도구들… 마지막으로… 확인할 수 있는 내역” 전개 예고.
[^2]: @[01:32] “데브옵스란 무엇일까요… 정의를 정확하게…”
[^3]: @[01:38] “소프트웨어 개발과 정보 기술의 운영을 결합… 문화 철학 사례 및 도구의 조합” / @[01:48] “빠르게 피드백을 바탕으로 개선… 새로운 개발 접근 방법”
[^4]: @[02:20] “변화에는 세가지 모델… 오퍼레이션 모델… 아키텍처 패턴… 소프트웨어 배포… 같이 발전” / @[02:34] “단순 도구 도입… 컬처만 바꾼다고… 안 된다… 동시에 수반”
[^5]: @[06:52] “고객… 여러가지 접근” 이후 “진정한 의미…” 설명 전개.
[^6]: @[07:47] “유닛을… 작게… 스케일 단위 확장 단위 기반으로 분리” / @[09:15] “2피자 팀으로 조직… 문화적 변화의 전제” / @[10:23] “일반적으로 2피자 팀은… 15명이 미만”
[^7]: @[09:01] “서로 다른 라이프 사이클… api를 통해서…” / @[10:29] “자동화 해야… 감당할 수 없게”
[^8]: @[13:35] “DevOps를 위한 AWS 도구…”
[^9]: @[15:15] CodeCommit/CodeBuild/CodeDeploy/CloudWatch/X-Ray/CloudTrail Logs/CodePipeline 나열 / @[20:08] “클라우드 디벨롭먼트 킷” / @[21:09] “CloudFormation 템플릿화… 배포/관리”
[^10]: @[26:24] “aiml 머신러닝 기반” / @[28:42] “데브옵스 구루… 이상 감지… 노이즈 제거… 연관”
[^11]: @[00:13] 세션 주제 선언 / @[01:21] 마지막에 추가 확인 내역 언급.
[^12]: @[00:09] “AWS… 솔루션즈 아키텍트” / @[00:13] “AWS에서 데브옵스 시작하기”
[^13]: @[04:50] 아마존 초기 구조→분리 / @[13:40] AWS 파이프라인 도구 / @[20:08] CDK / @[23:46] DevOps Guru
[^14]: @[01:48] “빠르게 피드백…” / @[02:20] 3모델 동시 발전
[^15]: @[07:26] “잘못 되더라도 전체 서비스 영향 최소화” / @[09:01] “서로 다른 라이프사이클… API”
[^16]: @[15:15] Code* 및 모니터링 / @[20:08] CDK / @[23:46] DevOps Guru
[^17]: @[00:31] 콘텐츠 구성 소개.
[^18]: @[00:31]~@[01:21] 오늘 다룰 순서 설명.
[^19]: @[00:31] “오늘의 주제… 먼저… 그리고… 마지막…”
[^20]: @[00:31] DevOps 소개 예고.
[^21]: @[00:40] “아마존에서 데브옵스를 어떻게 했는지”
[^22]: @[00:48] “컬처… 프랙티스… 도구”
[^23]: @[00:57] “도구들에 대해서 좀 더 알아보도록”
[^24]: @[01:07] “고객 피드백… 서비스들 추가 개발”
[^25]: @[01:21] “마지막으로… 확인할 수 있는 내역”
[^26]: @[01:02] “AWS에서… 다양한 접근 방법… 시도… 고객 피드백… 서비스 추가 개발”
[^27]: @[01:29] “데브옵스 대한 소개”
[^28]: @[01:34] “정의를 좀 더 정확하게 하고 싶은데요”
[^29]: @[01:38] 정의 문장.
[^30]: @[01:48] “빠르게 피드백… 개선”
[^31]: @[02:34] “단순 도구 도입… 국한되지 않고”
[^32]: @[01:56] “단순… 개발해서… 방법론을 사용해서”
[^33]: @[02:01] “적용한 팀을 빌드하고”
[^34]: @[02:09] “도구를 사용… 프로세스를 개선”
[^35]: @[02:15] “전체적인 형태… 접근 방법론”
[^36]: @[02:20] “세가지 모델 필요”
[^37]: @[02:20] “변화에는… 필요합니다”
[^38]: @[02:22] “오퍼레이션 모델”
[^39]: @[02:22] “아키텍처 패턴”
[^40]: @[02:22] “소프트웨어 배포”
[^41]: @[02:22] “다 서로서로… 연관… 같이 발전”
[^42]: @[02:34] “단순한… 도구의 도입… 국한되지”
[^43]: @[02:40] “팀의 컬처를 바꾼다고만 해서 되는 것도 아닙니다”
[^44]: @[02:48] “모든 것들이 다 한번에 동시에 수반”
[^45]: @[03:07] “5가지 특징”
[^46]: @[02:57] “아마존에서도… 오래전부터… 논의” / @[03:07] “정리해보면 5가지”
[^47]: @[03:11] “유연함… 작은 단위… 개발/배포 단위”
[^48]: @[03:11] 같은 문맥.
[^49]: @[03:20] “수동… 제거… 대부분 자동화”
[^50]: @[03:26] “배포… 모니터링… 탐지… 자동화”
[^51]: @[03:39] “표준화 된 도구… 표준 프로세스”
[^52]: @[04:05] “새 개발자… 적응… 프로세스 안에서”
[^53]: @[03:45]~@[04:17] “매니지드… 디버깅… 리뷰… 표준 프로세스”
[^54]: @[04:30] “인프라… 코드로써 관리… 리뷰… 코드로 정의”
[^55]: @[03:20]~@[04:44] 5특징 종합 설명.
[^56]: @[04:50] 아마존 초기 이야기.
[^57]: @[04:55] “초창기… 아마존닷컴은… 모놀리식 형태”
[^58]: @[05:02]~@[05:18] “작은 변화… 전체… 주기에 따라 업데이트”
[^59]: @[05:24]~@[05:37] “단 하나의 파이프라인… 특정 사이클 기다림”
[^60]: @[05:35] “특정한 사이클… 기다릴 수 밖에”
[^61]: @[05:37] 서비스로 나누고 팀 분리.
[^62]: @[05:37] “작은 형태의 서비스로 나누고”
[^63]: @[05:45] “서비스 단위로 개발팀 분리”
[^64]: @[05:45]~@[05:50] “개발 효율성… 향상”
[^65]: @[05:54] “그런데 이것들도…”
[^66]: @[06:05]~@[06:22] 파이프라인 하나의 한계.
[^67]: @[06:05] “마이크로서비스… 구조”
[^68]: @[06:05]~@[06:17] “운영 파이프라인… 하나… 완벽한 형태… 어렵다”
[^69]: @[06:17] “파이프라인… 서비스 단위로 나누게 됩니다”
[^70]: @[06:22] “개발자와… 파이프라인… 얼라인”
[^71]: @[06:33]~@[06:38] “개발자가 운영도… 피드백… 다시 개발”
[^72]: @[06:52] 고객 접근 방식 언급.
[^73]: @[06:52] “고객들을 만나다보면… 여러가지 접근”
[^74]: @[06:59] “여전히 모놀리식”
[^75]: @[07:04]~@[07:08] “자동화 툴… 모듈… 데브옵스다”
[^76]: @[07:16]~@[07:33] “최고의 장점… 빠른 피드백… 영향 최소화… 어렵다”
[^77]: @[07:16] “빠른 피드백”
[^78]: @[07:26] “잘못 되더라도… 영향 최소화”
[^79]: @[07:33] “아키텍처라고 보기는 어려울”
[^80]: @[08:07]~@[08:21] 스케일 단위 분리 강조.
[^81]: @[08:07] “기능… 컴포넌트 단위로… 생각… 있는데”
[^82]: @[08:07] 같은 맥락.
[^83]: @[08:07]~@[08:21] “스케일 단위로… 운영 관리 편”
[^84]: @[07:47] “유닛… 작게”
[^85]: @[07:52] “데이터는… 도메인 안에서 활용”
[^86]: @[07:58]~@[08:03] “스케일 단위… 분리하여 관리”
[^87]: @[08:29]~@[09:15] 독립 라이프사이클/ API 통합.
[^88]: @[08:29] “예를 들어 a… b…”
[^89]: @[08:29]~@[08:45] “개발 주기… 나눠져”
[^90]: @[08:45] “긴밀하게 커뮤니케이션… 필요 없겠죠”
[^91]: @[08:50]~@[08:59] “다른 서비스 영향 고려… 어려울”
[^92]: @[09:01] “서로 다른 라이프 사이클”
[^93]: @[09:01] “api를 통해서”
[^94]: @[09:15] “서비스 간 제약 최소화”
[^95]: @[09:15] “매우 중요한 원칙”
[^96]: @[09:15]~@[09:56] 조직/운영 책임.
[^97]: @[09:15] 2피자 팀 조직으로 교직을 나눔.
[^98]: @[09:15] “2p자 팀으로… 서비스 직접 운영”
[^99]: @[09:15] “서비스 간 제약… 최소화”
[^100]: @[09:24] “개발의 결정을… 서비스 단위… 팀 단위”
[^101]: @[09:24]~@[09:31] “문화적 변화의 전제 요건”
[^102]: @[09:31] “이 모든 것들이 개발팀이 직접 운영”
[^103]: @[09:38]~@[09:56] “개발 보안… 운영… 테스팅… 분석까지”
[^104]: @[10:01]~@[10:40] 작은 팀 부담→자동화 필요.
[^105]: @[10:03]~@[10:29] 2피자 팀 설명.
[^106]: @[10:08] 피자 농담.
[^107]: @[10:15] 100명 피자 예시.
[^108]: @[10:23] “12명… 15명 미만”
[^109]: @[10:29]~@[10:40] “자동화… 감당할 수 없게”
[^110]: @[10:48] “개발 스테이지… 매우 빠르게”
[^111]: @[10:58] “검증… 테스팅… 자동화”
[^112]: @[10:58]~@[11:03] “프로덕션 레벨… 검증”
[^113]: @[11:03] “데이터 사전 데이터들을…”(발화 그대로)
[^114]: @[10:48]~@[11:06] 자동화 범위 설명.
[^115]: @[11:27]~@[12:15] 아키텍처 변화 필요.
[^116]: @[11:56] “아키텍처… 변화하지 않는다면… 될 수 없겠죠”
[^117]: @[11:56] “기존 팀… 오토메이션… 필요성 인식”
[^118]: @[12:09] “아키텍처… 변화… 중요한 선결 과제”
[^119]: @[11:32]~@[11:42] “독립적으로 확장 가능한 형태”
[^120]: @[11:42] “서포트하는 인프라스트럭처”
[^121]: @[11:54] “아키텍쳐도… 변화 필요”
[^122]: @[12:19]~@[13:22] 산업 사례.
[^123]: @[12:19] “다양한 산업군… 좋은 사용 사례”
[^124]: @[12:35]~@[12:46] “오스카… 에어비앤비… 길트”
[^125]: @[12:47] MLB 언급.
[^126]: @[12:57]~@[13:03] “중계 시스템… 데이터 개더링… 돌린”
[^127]: @[13:03] “시즌 오프… 정리… 비용 효율”
[^128]: @[13:13]~@[13:22] “전략이라고 볼 수”
[^129]: @[13:35]~@[15:15] AWS 도구/파이프라인 설명.
[^130]: @[13:35] “AWS 도구가 어떤 것이 있는지”
[^131]: @[13:40] “DevOps 파이프라인… 예제를 통해”
[^132]: @[13:40]~@[13:56] “코드 커밋”
[^133]: @[13:56] “클라우드나인”
[^134]: @[14:06] “AWS 디벨로퍼 툴”
[^135]: @[14:17] “디펜던시 체크”
[^136]: @[14:17] “패키징… 빌드”
[^137]: @[14:27] “검증 도구”
[^138]: @[14:28] “프로덕션 레벨… 테스트”
[^139]: @[14:43] “카오스 엔지니어링… 실패를 주입”
[^140]: @[14:43]~@[14:52] “네트워크 구성… 성능 테스트”
[^141]: @[15:01] “베타 감마 프로덕션으로 나눠서”
[^142]: @[15:01]~@[15:15] “베타… 성능 테스트”
[^143]: @[15:01]~@[15:15] “감마… 프로덕션과 거의 동일”
[^144]: @[15:15] “파이프라인… 필요”
[^145]: @[15:15]~@[15:56] 도구 매핑.
[^146]: @[15:15] “CodeCommit… CodeBuild…”
[^147]: @[15:26] “소스… 코드 커밋”
[^148]: @[15:26] “빌드… 코드 빌드”
[^149]: @[15:37] “테스트… 코드 빌드… 서드파티”
[^150]: @[15:37]~@[15:48] “배포… 코드 디플로이”
[^151]: @[15:37]~@[15:48] “엑스레이… 클라우드와치… 클라우드… 로고스(CloudTrail Logs 취지)”
[^152]: @[15:48] “코드 파이프라인”
[^153]: @[15:56] “하나하나 자세히… 어렵지만”
[^154]: @[15:56]~@[16:19] “엔터프라이즈급… 다양한 도구… cid… iac… 모니터링…”
[^155]: @[16:19]~@[16:31] “2020 리인벤트… ai 기반… 도구”
[^156]: @[16:37]~@[17:09] 개발자 도구 성격/확장.
[^157]: @[16:37] “마이크로서비스와 서버리스를 잘 지원… 제작”
[^158]: @[16:46] “2016년 이후… 피드백… 기능 추가”
[^159]: @[16:55] “직접 만드실 필요없이”
[^160]: @[16:55]~@[17:09] “표준화된 방법으로 적용”
[^161]: @[17:09]~@[19:03] 서버리스/컨테이너 논의.
[^162]: @[17:17] “운영 책임 모델 변화… 연관”
[^163]: @[17:27] “인프라… 유연하게… 수용”
[^164]: @[17:35] “서버리스와 컨테이너”
[^165]: @[17:39]~@[17:50] “vm 기반… 직접 운영… 여기서도 데브옵스”
[^166]: @[17:50]~@[17:57] “배포… 빌드 파이프라인… 집중”
[^167]: @[17:57]~@[18:02] “ec2 인스턴스 자체를 관리… 노력”
[^168]: @[18:02]~@[18:13] “아키텍처 개선… 기능 추가”
[^169]: @[18:13]~@[18:28] “AWS가 운영… 인프라… 훨씬 편”
[^170]: @[18:28]~@[18:47] “람다… api gateway… s3… 오로라 서버리스… 다이나모db”
[^171]: @[18:48]~@[19:03] “eks… ecs… 컨테이너 워크로드”
[^172]: @[19:08]~@[19:46] 4가지 질문.
[^173]: @[19:08] “소프트웨어 딜리버리… 발전”
[^174]: @[19:12] “4가지 정도… 질문”
[^175]: @[19:21] “릴리즈 프로세스가 너무 다양한데”
[^176]: @[19:21]~@[19:30] “모범 사례를 어떻게”
[^177]: @[19:30] “내부적으로… 방법론 프로세스”
[^178]: @[19:36]~@[19:46] “로깅… 모니터링… 서버리스도”
[^179]: @[19:46]~@[19:57] “베스트 프랙티스… 제공”
[^180]: @[19:57]~@[20:01] “코드 파이프라인과 람다”
[^181]: @[20:01]~@[20:08] “한눈에 보이고… 통제”
[^182]: @[20:08]~@[21:29] CDK 소개/예시.
[^183]: @[20:08] “좋은 방법… aws 클라우드 디벨롭먼트 킷”
[^184]: @[20:16] “프레임워크를 사용하듯이”
[^185]: @[20:25] “vpc… 한줄 내지는 두 줄”
[^186]: @[20:32]~@[20:41] “객체화 해서 생성”
[^187]: @[20:41] “부트스트랩핑… 연결”
[^188]: @[20:41]~@[20:57] “오토 스케일링 그룹… 지정”
[^189]: @[20:41]~@[20:57] “코드로서 인프라… 배포”
[^190]: @[20:57] “파이프라인… 코드로 관리”
[^191]: @[21:09] “CloudFormation 템플릿화”
[^192]: @[21:09] “CloudFormation에서 배포되고 관리”
[^193]: @[21:09]~@[21:23] “DevOps가… CloudFormation에서 구성”
[^194]: @[21:29] “CloudFormation… 복잡… 어렵지 않냐”
[^195]: @[21:29] “CDK를 사용… 쉽게”
[^196]: @[20:16]~@[21:23] 프레임워크처럼 사용, CFN 변환/관리 설명 종합.
[^197]: @[21:40]~@[22:22] 지속적 배포/트리거/CodeBuild.
[^198]: @[21:40] “지속적인 배포… 가장점”
[^199]: @[21:40] “프로덕션 레벨… 블루그린 디플로이”
[^200]: @[21:57] “소스 액션 같은 것들 지정”
[^201]: @[21:57] “git… 트리거”
[^202]: @[21:57] “호킹… 아티팩트 생성”
[^203]: @[22:15] “코드 빌드 호출해서 배포”
[^204]: @[22:15]~@[22:22] “자동 배포… 코드로 인프라 배포”
[^205]: @[22:36]~@[22:41] “기존 운영… 블루”
[^206]: @[22:41]~@[22:52] “새 버전… 그린”
[^207]: @[22:52]~@[23:02] “전환 전에 검증”
[^208]: @[23:02] “트래픽을 일정 수준… 전환”
[^209]: @[23:09] “문제 없이 작동… 완벽하게… 배포”
[^210]: @[23:15] “블루… 제거”
[^211]: @[23:20] “iac를 이용해서 간단하게”
[^212]: @[23:49]~@[26:21] 넷플릭스 예시와 운영 복잡성.
[^213]: @[23:27]~@[23:41] “개발자 친화 기능… 추가”
[^214]: @[23:41]~@[23:49] “리인벤트… 데브옵스 구루” 소개 예고
[^215]: @[23:57] “넷플릭스… 잘하는 사례”
[^216]: @[24:01] “시간이 지나면… 복잡”
[^217]: @[24:14] “서비스가 수백개”
[^218]: @[24:14]~@[24:27] “복잡한 호출 구조”
[^219]: @[24:27] “모니터링… 어렵고 관리… 어렵”
[^220]: @[24:41]~@[24:51] “데이터를 모아서 피드백” 문제 제기
[^221]: @[24:41] “오케스트레이션”
[^222]: @[24:48] “데이터 모아서”
[^223]: @[24:51] “사람이… 데이터 량이 많고 어려”
[^224]: @[24:56]~@[25:01] “데이터 볼륨… 매우 크고”
[^225]: @[25:01] “이질적인 패턴… 의미 추출 어려움”
[^226]: @[25:12]~@[25:26] “수동으로… 상호 연결… 상관관계 분석”
[^227]: @[25:35]~@[25:51] “새 서비스… 새 매트릭… 인사이트 필요”
[^228]: @[25:57]~@[26:07] “비즈니스 버티컬 전문 지식… 어렵”
[^229]: @[26:11]~@[26:21] “작은 경보 누적… 중요한 경보 놓침”
[^230]: @[26:24]~@[26:49] ML 기반 접근 제안.
[^231]: @[26:24] “그럼 이것들을 어떻게 대응할 수 있을까”
[^232]: @[26:24]~@[26:35] “aiml 머신 러닝 기반”
[^233]: @[26:39]~@[26:49] “찾아내기 어려운 패턴… 알려주고”
[^234]: @[26:49] “새로운 형태… 도구”
[^235]: @[26:57]~@[27:02] “컨테이너… 로그”
[^236]: @[27:02] “서비스 응답속도… 변화 모니터링”
[^237]: @[27:02]~@[27:27] “인스턴스 부족” 예시
[^238]: @[27:02]~@[27:27] “공격일 가능성” 예시
[^239]: @[27:27] “흐름 디텍팅… 어부노말 디텍팅”
[^240]: @[27:27]~@[27:34] “인프라 레벨에서 처리… 도구”
[^241]: @[27:34]~@[27:53] “세이지메이커… 큐브플로우… 생각”
[^242]: @[27:34] “구할 수 있지 않는가” 취지의 반문.
[^243]: @[27:53]~@[28:31] “훨씬 손쉽게… 파이프라인에 집어넣고… 자동 감지… 인사이트… 앱 개선에 집중”
[^244]: @[28:42]~@[30:14] DevOps Guru 기능/적용/통합.
[^245]: @[28:42] 기능 열거 시작.
[^246]: @[28:42] “심각도… 감지”
[^247]: @[28:42] “노이즈 제거”
[^248]: @[28:42]~@[28:55] “관련 매트릭… 이상… 변경사항 추적”
[^249]: @[28:55] “로그 이벤트… 연관”
[^250]: @[28:55]~@[29:06] “미처 보지 못한 로그… 의미 찾기 어려운 부분”
[^251]: @[29:06] “장애… 원인… 매트릭스 가치 분석”
[^252]: @[29:06]~@[29:22] “인텔리전스 모니터링 환경”
[^253]: @[29:25] “카운트 단위(계정)로… 클라우드포메이션 단위”
[^254]: @[29:31]~@[29:43] “cdk… 파이프라인 단위 적용… 동일 의미”
[^255]: @[29:44]~@[29:55] “통계 및 로그 분석… 인사이트 생성”
[^256]: @[29:55]~@[30:00] “sns… 서드파티… 통합”
[^257]: @[30:00]~@[30:14] “aiml 통해… 현대화… 빌드 파이프라인”
[^258]: @[30:20]~@[31:30] 결론 파트.
[^259]: @[30:20] “결론 입니다”
[^260]: @[30:22] “2018년 이후… 인정”
[^261]: @[30:30]~@[30:41] “엔터프라이즈급… 베스트 프랙티스”
[^262]: @[30:41]~@[30:47] “광범위한 사용 사례… 지원 경험”
[^263]: @[30:49]~@[30:58] “배포하는 데… 도움이”
[^264]: @[31:02] “파이프라인… 어떻게 빌드”
[^265]: @[31:02] “모니터링… 향상”
[^266]: @[31:02] “파이프라인… 발전”
[^267]: @[31:02]~@[31:30] “팀 구성… 컬쳐… 베스트 프랙티스”
[^268]: @[31:30] “AWS 도구… 적극 활용”
[^269]: @[31:38] “링크… 개발자 도구… 블로그”
[^270]: @[31:50] “디지털 교육”
[^271]: @[31:59]~@[32:04] “현대화… 도움”
[^272]: @[32:09]~@[32:23] 감사/설문 요청/종료.
[^273]: @[01:48]~@[30:14] 전체 내용의 반복 핵심에서 도출.
[^274]: @[02:20] 3모델 / @[02:48] 동시 수반.
[^275]: @[07:16]~@[07:33] DevOps 장점 / @[09:01] API·독립 라이프사이클.
[^276]: @[08:07]~@[08:21] 스케일 단위 분리.
[^277]: @[09:38]~@[10:40] 작은 팀 end-to-end 부담→자동화.
[^278]: @[24:56]~@[26:35] 데이터/경보/상관관계 문제→ML 접근 / @[28:42] DevOps Guru 기능.
[^279]: @[31:02]~@[31:30] “어떻게 빌드/향상/발전” 메시지에 근거한 실행 재표현.
[^280]: @[06:17] 파이프라인 서비스 단위 분리.
[^281]: @[03:39] 표준화 / @[10:29] 자동화 필요.
[^282]: @[21:29] CloudFormation 복잡→CDK로 쉽게.
[^283]: @[29:55] SNS/서드파티 통합 + 이상탐지/노이즈제거.
[^284]: @[01:38]~@[30:00] 용어들이 반복 등장.
[^285]: @[01:38] DevOps 정의.
[^286]: @[02:20] 운영 모델.
[^287]: @[02:22] 아키텍처 패턴 + @[07:47]~@[08:03] 서비스 분리 원칙.
[^288]: @[02:22] 소프트웨어 배포 + @[13:40] 파이프라인 설명.
[^289]: @[10:23] 2-Pizza Team 규모.
[^290]: @[04:30] “인프라… 코드로써 관리”
[^291]: @[21:09] CDK→CloudFormation 템플릿 / @[20:16] 프레임워크처럼.
[^292]: @[22:36]~@[23:15] 블루/그린 설명.
[^293]: @[26:39]~@[30:14] DevOps Guru 설명.
[^294]: @[00:13] 세션 정보 + 사용자 제공 메타.
[^295]: 사용자 제공 제목.
[^296]: 사용자 제공 채널.
[^297]: 사용자 제공 길이.
[^298]: 사용자 제공 링크.

← 프로젝트에서 보기