https://www.youtube.com/watch?v=55mOuHllXu4
1. 이건 꼭 알아야 한다[^1]
[? 질문] DevOps/플랫폼/인프라 팀이 겪는 인프라 역량(스킬) 격차는 실제로 무엇이며, 왜 계속 병목이 되는가[^2]
[= 답] 인프라 전문가 수가 수요(개발/QA/엔지니어링 인력)에 비해 압도적으로 적고(대표적으로 “10x” 격차), 동시에 인프라와 애플리케이션이 점점 복잡해지며, 팀/부서별로 자동화 도구가 제각각인 자동화의 섬(islands of automation) 상태가 누적되어 대기시간·마찰·불일치가 구조적으로 발생한다.[^3]
[? 질문] 인프라 자동화는 어떤 성숙도 단계를 거치며, 많은 회사는 어디에 머물러 있는가[^4]
[= 답] 수동 구축 → 부분 자동화(IaC 등) → 자동화의 섬/사일로 → 마찰 없는(frictionless) 셀프서비스(표준·보안·속도) → (미래) 애플리케이션이 인프라를 더 직접 정의하는 단계로 진화한다. 다수 기업은 “부분 자동화 + 도구 난립 + 팀 간 마찰” 구간(발표에서 ‘오렌지 라인’)에 머문다.[^5]
[? 질문] 이 병목을 “마찰 없는 세계”로 끌어올리는 실질적 방법은 무엇인가[^6]
[= 답] 서로 다른 자동화(IaC, Helm, Jenkins 파이프라인, GitHub Actions 등)를 **블루프린트(blueprints)**라는 반복 가능한 단위로 “비즈니스 플로우” 수준에서 합성/모델링하고, 자산 자동 발견(auto discovery)과 거버넌스를 붙여, IDE·CI(Jenkins) 등 어떤 진입점에서도 동일한 환경을 셀프서비스로 배포·운영(라이프사이클 관리 포함)하게 만든다.[^7]
2. 큰 그림[^8]
이 발표는 DevOps/플랫폼 팀이 감당해야 하는 인프라 요청이 폭증하는 현실에서, 소수의 인프라 전문가에게 업무가 집중되는 인프라 스킬 격차가 어떻게 생기고 어떤 형태로 조직의 속도를 떨어뜨리는지 설명한다.[^9] 그리고 수동/부분 자동화 단계에서 흔히 발생하는 “자동화의 섬” 문제를 넘어, 표준화된 셀프서비스를 제공하는 마찰 없는 인프라 자동화로 이동하는 경로를 제안한다.[^10]
- 병목의 본질은 인력 비율(수요 대비 공급)과 복잡성이다: 인프라를 제대로(보안/품질/인증된 IaC) 만들 수 있는 사람은 소수인데, 서비스해야 하는 개발자 수는 수천~수만 명 규모가 되어 대기시간과 불만이 누적된다.[^11]
- 도구가 DevOps를 보장하지 않는다: Terraform 같은 도구가 있어도 조직 문화·프로세스가 DevOps 방식으로 정렬되지 않으면 속도 저하(레거시·온프렘·VM 혼재 포함)가 지속된다.[^12]
- 해법으로 블루프린트 기반의 구성요소(빌딩블록) 합성 + 셀프서비스 + 거버넌스 + 라이프사이클 관리를 제시하며, “DevOps 모놀리스” 대신 “DevOps를 위한 마이크로서비스(빌딩블록)” 관점으로 전환하라고 주장한다.[^13]
3. 하나씩 살펴보기[^14]
3.1 발표자 소개와 문제의식: 인프라/자동화 스킬 갭을 어떻게 메울 것인가[^15]
발표자는 자신을 Tomer라고 소개하고, Quali의 Field CTO로서 오늘의 주제가 “인프라 및 인프라 자동화(automation) 주변의 스킬 갭을 메우는 것(bridging the skills gap)”이라고 제시한다.[^16] 여기서 말하는 스킬 갭은 단순히 인력이 부족하다는 의미를 넘어, 조직이 요구하는 속도·표준·보안을 만족하는 인프라 자동화를 안정적으로 제공할 역량이 제한된다는 맥락으로 깔린다.[^17]
이어 발표자는 청중에게 짧은 “10초짜리 연습”을 시킨다.[^18]
- 회사에서 DevOps/플랫폼/인프라를 “하는 사람”의 수를 떠올려 본다.[^19]
- 그 사람들이 “서비스해야 하는 사람”(개발, 엔지니어링, QA 등)의 수와의 비율(ratio)을 계산해 보라고 한다.[^20]
- 예시로 “DevOps 팀 5명이 개발/엔지니어링/QA 500명을 서비스”하는 상황을 든다.[^21]
이 도입은 이후 발표 전반에서 반복되는 핵심 전제—소수의 인프라 담당자가 다수의 내부 고객을 받치는 구조—를 직관적으로 체감시키기 위한 장치다.[^22]
3.2 인프라 자동화 성숙도 경로: 수동 → 부분 자동화 → 사일로 → 마찰 없는 셀프서비스 → (미래) 앱이 인프라 정의[^23]
발표자는 “인프라 자동화에 대해 이야기하자”며, 자동화의 출발점이 대개 수동(manual) 작업임을 전제한다.[^24]
3.2.1 1단계: 수동 구축의 출발점[^25]
인프라 수요는 “클라우드에 무언가가 필요”하거나 “온프렘에 무언가가 필요”한 형태로 시작한다.[^26] 그 무언가는 단순히 VM일 수도 있고, Lambda 함수 같은 서버리스 컴포넌트일 수도 있다.[^27] 초기에는 설계(designing), 구축(building), 아키텍팅(architecting) 등 모든 것을 “천천히, 수동으로” 진행한다.[^28]
하지만 어느 시점에 수동 방식의 한계를 깨닫는다.[^29]
- 어렵고(hard)
- 일관되지 않고(not consistent)
- 안정적이지 않으며(not stable)
- 여러 “동기화/표준화” 성격의 기능을 해친다고 표현한다(문맥상 표준화·일관성 유지가 깨진다는 문제의식).[^30]
- 예로 “수동으로 하면 태깅(tagging)을 모두 똑같이 맞추기 어렵다”고 든다.[^31]
즉 수동은 속도뿐 아니라 표준 준수(태그), 재현성, 안정성에서 조직 규모가 커질수록 더 큰 비용을 만든다는 메시지다.[^32]
3.2.2 2단계: 부분 자동화(IaC 등)로 이동[^33]
다음 성숙도 단계는 “그 작업의 일부를 자동화”하는 것이다.[^34] 도구는 CloudFormation, Terraform, Pulumi(발표 자막에는 Plum으로 표기) 등 무엇이든 상관없다고 말한다.[^35] 중요한 건 “자동화의 시작”이다.[^36]
그런데 현실에서 많은 기업은 여기서 문제가 생긴다고 지적한다.[^37]
- 여러 팀/부서가 각자 자동화를 하고 싶어 한다.[^38]
- 그 결과 자동화가 하나로 정렬되지 않고 “서로 다른 방식”으로 존재한다.[^39]
- 그래서 “자동화의 섬(islands of automation)”이 만들어진다.[^40]
- 도구가 여러 개고 서로 상호작용해야 하는데, 이를 함께 작동하게 만드는 것이 매우 어렵다.[^41]
- 결국 비즈니스 프로세스를 달성할 수 없고, 다시 사일로(silos)와 프로세스 단절이 생긴다고 말한다.[^42]
여기서의 핵심은 “IaC 도입” 자체가 종착점이 아니라, 팀별·도구별 분절이 생기면 오히려 상호운용이 어려워져 원하는 속도/표준화를 달성하지 못한다는 경고다.[^43]
3.2.3 3단계: 우리가 원하는 수준—마찰 없는(frictionless) 셀프서비스[^44]
발표자는 다음 레벨이 “우리가 회사에서 정말 보고 싶은 것”이라고 말하며, 그 모습을 구체적으로 묘사한다.[^45]
- 마찰 없는 인프라 제공: 개발자가 원할 때 원하는 것을 얻는다.[^46]
- DevOps/플랫폼 팀은 **셀프서비스(self service)**를 제공한다.[^47]
- 그 셀프서비스는 빠르고( fast, rapid ), 안전하고(secure), 표준화된(standardized) 인프라를 매우 빠르게 제공한다.[^48]
즉 “개발자가 원하는 인프라를 즉시 쓰게 하되, 무질서가 아니라 보안·표준을 내장한 셀프서비스”가 목표 상태다.[^49]
3.2.4 (미래) 앱이 인프라를 정의하는 단계[^50]
더 미래에는 “애플리케이션이 어떻게든 인프라를 스스로 정의”하게 되어, 우리가 인프라를 그렇게 많이 생각하지 않아도 되는 방향을 말한다.[^51] 이는 플랫폼 추상화가 더 올라가거나, 앱 중심 선언이 강화되는 미래상을 암시한다.[^52]
3.2.5 현실 진단: 대부분은 ‘오렌지 라인’에 있다[^53]
발표자는 자신들이 일하는 많은 회사가 “오렌지 라인 어딘가”—즉 여러 도구로 일부 자동화를 하고 있지만 매우 어렵고, 팀 간 마찰이 많은 구간—에 있다고 말한다.[^54] 그리고 질문을 던진다.[^55]
[? 질문] 이런 팀들을 어떻게 성숙도 모델에서 끌어올려 마찰 없는 세계로 이동시킬 수 있을까[^56]
[= 답] 이후 섹션에서 ‘무엇이 느리게 하는지’와 ‘주요 장애물 3가지’, 그리고 블루프린트 기반 접근으로 그 이동 경로를 제시한다.[^57]
3.3 속도를 떨어뜨리는 현실 요인: DevOps “채택”의 한계와 레거시/하이브리드 부담[^58]
본격적인 갭/난점을 다루기 전에 “무엇이 우리를 느리게 하는가(what’s slowing us down)”를 이야기하자고 전환한다.[^59]
3.3.1 도구가 있어도 DevOps가 아니다[^60]
발표자는 2014, 2016, 2018년에도 DevOps “채택(adoption)”을 이야기했는데, 지금도 여전히 그 과정 중이라고 말한다.[^61] 중요한 문장으로 다음을 강조한다.[^62]
- Terraform이 있다고 해서 회사 문화가 DevOps를 하고 있다는 뜻이 아니다.[^63]
- 모든 프로세스가 DevOps 방식으로 구성되어 있다는 뜻도 아니다.[^64]
즉 DevOps는 툴체인 도입이 아니라 문화·프로세스의 운영 방식이라는 점을 상기시킨다.[^65]
3.3.2 레거시/온프렘/VM 혼재가 발목을 잡는다[^66]
또한 레거시 인프라가 “정말로 우리를 붙잡고 있다(holding us back)”고 말한다.[^67] 이유는 인프라가 AWS의 서버리스, RDS 같은 매니지드 서비스만으로 구성된 ‘깔끔한’ 상태가 아니기 때문이다.[^68]
- 온프렘(on-prem)도 있고[^69]
- VM 워크로드도 있으며[^70]
- 따라서 올바른 속도(velocity)로 일하기 어렵다고 말한다.[^71]
여기서의 포인트는 많은 조직이 하이브리드/레거시 공존 상태이고, 이 현실이 자동화 표준화와 속도 향상에 추가 비용을 만든다는 것이다.[^72]
3.4 플랫폼 팀이 SDLC 전반에서 떠안는 책임: Inner loop와 Outer loop[^73]
발표자는 DevOps/플랫폼 팀이 SDLC 전반에서 수행해야 하는 일을 “숫자”가 아니라 “범위”로 보여준다.[^74] 애플리케이션이 무엇이든, 인프라가 무엇이든 상관없이 해야 하는 일이 있다고 전제한다.[^75]
3.4.1 개발자 Inner loop: 빠르게 개발/테스트/디버그[^76]
“개발자를 위한 inner loop”가 있고, 개발자가 매우 빠르게 개발하고, 테스트하고, 디버그(deduct로 표기됐지만 문맥상 debug)할 수 있어야 한다고 말한다.[^77] 즉 로컬/개발 환경에서의 생산성 루프를 최대한 짧게 만드는 것이 중요하다는 관점이다.[^78]
3.4.2 Merge 이후 Outer loop: 드리프트·시크릿·정책·비용 통제[^79]
메인 브랜치에 머지(merge)된 이후에 발생하는 모든 것을 “outer loop”로 표현하며, 다음을 예로 든다.[^80]
- 드리프트 감지(drift detection)[^81]
- 시크릿 관리(secrets managed in the right way)[^82]
- 정책과 비용 통제(policies and cost control)[^83]
그리고 이것은 마이크로서비스 수나 인프라 컴포넌트 수와 무관하게 DevOps/플랫폼 팀의 일이라고 말한다.[^84] 즉 규모가 커질수록 outer loop 운영 부담이 기하급수적으로 커질 수 있음을 암시한다.[^85]
3.5 DevOps 팀의 진화를 막는 3가지: 복잡성, 개발용 툴의 운영 전이, 자동화의 섬[^86]
발표자는 다시 질문 형태로 핵심 논점을 꺼낸다.[^87]
[? 질문] DevOps 팀이 진화해서 마찰 없는 세계로 가는 것을 무엇이 막고 있는가[^88]
[= 답] (1) 복잡성 증가, (2) 개발용으로 만든 내부 도구/스크립트를 운영까지 밀어 넣는 문제, (3) 자동화의 섬(도구 난립과 호출 방식 난립)이라는 “주로 3가지”라고 제시한다.[^89]
3.5.1 (1) 복잡성: 앱/인프라가 너무 복잡해진다[^90]
어느 시점에서 애플리케이션과 인프라는 “너무 복잡해져서” 어렵다고 말한다.[^91] 여기에 “확장성 이슈/도전(scalability issues or challenges)”이 붙는다.[^92] 그리고 이 복잡성을 해결할 만큼 충분히 빠르게 인프라를 제공하기가 어렵다고 한다.[^93]
즉, 조직이 성장할수록 “요청량 증가”뿐 아니라 “요청 1건당 복잡도”도 증가하여 플랫폼 팀의 처리량을 더 떨어뜨린다는 구조다.[^94]
3.5.2 (2) 개발용으로 만든 내부 도구가 스테이징/프로덕션까지 간다[^95]
두 번째 장애물로 “사내에서 만든 개발 도구(in house development tools), 스크립트, 빠른 유틸리티”를 든다.[^96] 이런 것들이 원래는 개발을 위해 만들어졌는데, 어느새 스테이징과 프로덕션으로 “푸시”된다는 것이다.[^97]
- 개발용으로는 적합하지만 운영용으로는 “그렇게 만들어진 것이 아니다(not really meant for that).”[^98]
- 그럼에도 그것들을 운영까지 확장하려고 하면 발목을 잡는다고 말한다.[^99]
여기서의 메시지는 “임시방편으로 만든 자동화/도구를 운영 표준으로 승격시키는 순간” 기술부채와 안정성 문제가 폭발한다는 경고다.[^100]
3.5.3 (3) 자동화의 섬: 도구/호출 방식이 너무 많다[^101]
세 번째로 다시 “islands of automation”을 강조한다.[^102]
- 도구가 너무 많고(way too many tools)[^103]
- 그것을 호출하는 방식도 너무 많다(way too many ways to invoke them)[^104]
- 어떤 것은 개발자 로컬 머신에서, 어떤 것은 Jenkins에서, 어떤 것은 ‘아무도 내부를 모르는 스크립트’에서 실행된다.[^105]
이렇게 되면 표준화된 프로세스와 재현성을 만들기가 어려워지고, 결국 조직 전체의 속도/안정성이 하락하는 방향으로 흐른다는 논지다.[^106]
3.6 스킬 갭이 만드는 깔때기(funnel) 병목: “10x 비율”과 대기시간, 그리고 ‘영구 VM’ 문제[^107]
발표자는 초반에 했던 비율 계산 연습을 다시 상기시키며, 실제 현장에서 흔히 보는 구조를 “깔때기(funnel), 병목(bottleneck)”으로 설명한다.[^108]
3.6.1 전형적 구조: 사용자(수요)는 많고, 인프라 전문가(공급)는 매우 적다[^109]
그림을 상정하며 “위에는 사용자(automation을 만들거나 인프라를 요청/소비하는 사람)가 많고, 아래에는 인프라 전문가가 매우 적다”고 말한다.[^110] 그리고 이 비율이 보통 “10x”라고 한다.[^111]
또한 구체 사례를 제시한다.[^112]
- 현재 함께 일하는 고객사에 개발자가 11,000명 있다.[^113]
- 그 중에서 “좋은 품질, 보안, 인증된(secure certified) Terraform 파일”을 실제로 만들 수 있는 사람은 15명뿐이다.[^114]
이 숫자는 발표에서 의도적으로 충격을 주는 데이터 포인트로, “요청 폭주 vs 전문 인력 부족”이 단순 불평이 아니라 구조적 현실임을 보여준다.[^115]
[!IMPORTANT] 병목의 계산이 아니라 ‘체감’을 바꾸는 수치
11,000명의 요구를 15명이 감당해야 한다는 예시는, “IaC를 잘 짜는 능력”이 희소 자원일 때 플랫폼 팀이 어떻게 항상 대기열을 만들 수밖에 없는지 설명하는 근거로 쓰인다.[^116]
3.6.2 결과 1: 인프라 대기시간이 길어진다(S3 버킷도 몇 시간~몇 주)[^117]
이 병목의 결과로 “개발자들이 인프라를 받기까지 대기시간(wait times)이 매우 길어지는 것”을 든다.[^118]
- 단지 S3 버킷 하나인데도 몇 시간이 걸릴 수 있다.[^119]
- 몇 주가 걸릴 수도 있다.[^120]
- 몇 분이 걸릴 수도 있지만, “그 몇 분조차도 허용 가능한 것보다 길 수 있다”고 말한다.[^121]
즉 문제는 단지 “주 단위 지연” 같은 극단뿐 아니라, 개발자 inner loop 관점에서는 “몇 분 지연”도 생산성을 크게 해친다는 인식이다.[^122]
3.6.3 결과 2: 마찰이 커지고 사람들은 불행해지며, 결국 떠날 수 있다[^123]
팀 계층(플랫폼/인프라 계층과 개발자 계층) 간 마찰이 가득한 환경에서 “모두를 행복하게 유지하기가 정말 어렵다”고 말한다.[^124] 그리고 사람들은 행복하지 않고, 결국 떠날 수도 있다고 한다.[^125]
여기서 발표자는 스킬 갭이 단지 기술 문제가 아니라 조직 건강/이직 리스크로 이어질 수 있음을 강조한다.[^126]
3.6.4 결과 3: “한 번 늦게 받은 환경은 절대 놓지 않는다” → 장기 고착(5~10년 VM)[^127]
발표에서 특히 인상적인 행태로, 환경 제공이 늦으면 사용자가 다음번엔 “일단 받은 것을 절대 놓지 않는다”고 말한다.[^128]
- 예: VM 하나를 받는데 2주를 기다렸다면, 그 VM은 “그게 끝”이며[^129]
- 그 VM을 회사에서 5년, 6년, 10년 동안 계속 쓰게 된다고 한다.[^130]
그리고 “왜 그게 나쁜지 여러분은 상상할 수 있을 것”이라고 덧붙인다.[^131] 즉 장기 고착된 자원은 보안 패치/표준 변경/비용 최적화/아키텍처 개선을 어렵게 하고, 레거시를 더 강화하는 악순환을 암시한다.[^132]
3.7 Quali의 제안: ‘블루프린트’로 자동화의 섬을 합성하고 비즈니스 플로우를 모델링한다[^133]
지금까지 “일관되게 환경을 제공하기 어렵다”, “보안 인프라를 제공할 사람이 너무 적다”는 문제를 이야기했고, 이제 Quali가 제공하는 개념으로 “블루프린트(blueprints)”를 소개한다.[^134]
3.7.1 블루프린트의 핵심 정의: 흩어진 자동화를 ‘구성 요소’로 모아 합성(composition)한다[^135]
발표자는 블루프린트를 다음처럼 설명한다.[^136]
- 자동화의 섬 세계에 존재하는 “서로 다른 자동화”를 가져온다.[^137]
- 그것들을 “함께 구성(compose)한다.”[^138]
- 이 구성 요소는 IaC 블록일 수도 있고(infrastructure as code blocks), 애플리케이션 설정일 수도 있다(application configurations).[^139]
- Terraform이든 Helm이든 Jenkins 파이프라인이든 GitHub Actions든, 환경을 만드는 방식이 무엇이든 중요하지 않다.[^140]
- 중요한 것은 여러 빌딩블록/컴포넌트를 모아 “이게 나의 블루프린트”라고 선언하는 것이라고 말한다.[^141]
즉 블루프린트는 특정 도구에 종속된 템플릿이라기보다, 여러 자동화 산출물을 한 환경 단위로 조립한 ‘상위 패키지’ 개념으로 제시된다.[^142]
3.7.2 블루프린트는 ‘반복 가능한 배포 프로세스’를 만든다[^143]
블루프린트를 만든 뒤에는 이를 “반복 가능한(repeatable) 프로세스”로 배포(deploy)하고, 사용자가 이를 쓰게(enable users to use that) 하는 것이 목표라고 말한다.[^144] 여기서 반복 가능성은 일회성 실행이 아니라, 동일한 정의로 동일한 품질/정책을 재현하는 의미로 읽힌다.[^145]
3.7.3 “S3 버킷 하나”가 아니라 “비즈니스 플로우”를 모델링해야 한다[^146]
발표자는 블루프린트 설계의 첫 부분은 “필요한 컴포넌트가 무엇인지 파악”하는 것이라면서, 그 컴포넌트는 비즈니스 플로우를 충족해야 한다고 강조한다.[^147]
그리고 “S3 버킷” 예시를 다시 드는데, 단순 자원 1개로는 충분하지 않다는 점을 구체화한다.[^148]
- 적절한 권한(permissions)이 없으면 S3 버킷이 아니다.[^149]
- 접근할 URL이 없으면(또는 전달되지 않으면) S3 버킷이 아니다.[^150]
- 파일 업로드 권한이 없으면 S3 버킷이 아니다.[^151]
- 따라서 “전체 비즈니스 플로우”가 블루프린트 안에서 모델링되어야 한다고 말한다.[^152]
이 부분의 논리는 “인프라 요청을 리소스 단품으로 처리하면, 사용자는 결국 다시 플랫폼 팀에 추가 요청을 하게 되고(권한/접근/연계), 대기열이 반복된다”는 문제의식으로 연결된다.[^153]
3.7.4 블루프린트를 셀프서비스로 확장하면 속도/성장(velocity)이 붙는다[^154]
이렇게 모델링된 블루프린트를 “확장 가능한(scalable) 셀프서비스”로 사용자에게 제공할 수 있다고 말한다.[^155] 그리고 블루프린트를 환경이 필요한 시스템(예: 개발자 IDE, CI/CD 등)에 연결하면, 갑자기 빠르게 성장하고 속도(velocity)를 높일 수 있다고 주장한다.[^156]
3.8 Inner loop(속도)와 Outer loop(타임투마켓)를 블루프린트로 연결한다[^157]
발표자는 다시 inner loop를 호출하며 “여기서 속도가 중요하다”고 말한다.[^158]
- 개발자는 IDE/노트북에서 필요한 모든 것을 “바로 여기”서 가져야 한다.[^159]
- 그것이 velocity(속도)라고 정의한다.[^160]
동시에 outer loop에 대해선 “타임투마켓(time to market)”이라고 연결한다.[^161]
- 비즈니스는 경쟁사보다 조금 더 빠르게 무언가를 전달해야 한다.[^162]
그리고 “비즈니스 프로세스를 생각할 때” 특정 비즈니스 플로우에 필요한 모든 컴포넌트를 블루프린트에 포함하고, 이를 오케스트레이션(orchestrate), 관리(manage)하여 최종 사용자(end user)에게 제공하고 싶다고 말한다.[^163]
즉 블루프린트는 개발자 체감 속도(inner loop)와 비즈니스 성과(outer loop/타임투마켓)를 동시에 겨냥하는 ‘운영 단위’로 설명된다.[^164]
3.9 IaC 실행은 쉽고, 환경 ‘라이프사이클 관리’가 어렵다: 그래서 상위 레이어가 필요하다[^165]
발표자는 “IaC 파일을 그냥 실행(launch)하는 것” 자체는 괜찮다고 말한다.[^166] (Pulumi든 Terraform이든.)[^167] 그러나 진짜 어려운 것은 “환경 라이프사이클 전체에 걸쳐 그것을 관리(manage throughout environment life cycle)하는 능력”이라고 강조한다.[^168]
즉 **프로비저닝(생성)**이 아니라, 생성 후의 변경/업데이트/정책 준수/운영까지 포함한 전체 수명주기 관리가 핵심 난제라는 주장이다.[^169] 그리고 자신들이 “환경을 모델링하는 능력 위에(on top of)” 그 관리 능력을 제공하고 싶다고 말한다.[^170]
3.10 제안하는 실행 모델: 3단계(자산 파악 → 거버넌스 → 반복 가능한 블루프린트로 전달)[^171]
발표자는 “정말로 필요한 것은 3개의 간단한 단계(three simple steps)”라고 정리한다.[^172]
- 자산(assets)이 무엇인지 파악한다.[^173]
- 이를 “자동 발견(auto discovery)”이라고 부른다.[^174]
- 어떤 자산을 쓰든 발견해서 가져오고, 모든 것이 올바르게 거버넌스(governed)되도록 보장한다.[^175]
- 예: 비용이 많이 드는 “큰 RDS”를 사람들이 마음대로 쓰지 못하게 한다.[^176]
- 그리고 “반복 가능한 블루프린트(repeatable blueprints)” 개념을 사용해 최종 사용자에게 전달(deliver)한다.[^177]
여기서 거버넌스는 단지 금지 규칙이 아니라, 셀프서비스를 가능하게 하는 “안전장치”로 기능한다는 맥락이다.[^178]
[!TIP] 셀프서비스의 전제는 ‘발견 + 승인/정책 내장’
자산을 자동 발견해 등록하고, 사용 가능한 형태로 정책/비용 통제를 걸어둔 뒤, 승인된 조합을 블루프린트라는 반복 가능한 형태로 제공해야 “빠르면서도 통제되는 셀프서비스”가 된다는 흐름이다.[^179]
3.11 SDLC 전반에서의 유연성: IDE 원클릭 환경 + Jenkins도 같은 블루프린트를 사용[^180]
블루프린트를 모델링하고, 오케스트레이션하고, 제공하고, 최종 사용자에게 활성화(enable)할 수 있으면 SDLC 전반에서 유연성이 커진다고 말한다.[^181]
3.11.1 개발자는 IDE에서 바로 환경을 런치한다[^182]
- 개발자는 IDE에서 직접 환경을 시작(launch)할 수 있다.[^183]
- 모든 것이 모델링되어 있으므로, DevOps/플랫폼 팀은 “알 필요가 없다(doesn't need to know about it)”고 말한다.[^184]
- 이미 모델링되어 있고, 이미 승인(approved)되어 있으며, 모든 정책이 그 안에 들어 있다.[^185]
- 그래서 “원 클릭(one click)”으로 환경을 갖게 된다고 한다.[^186]
즉 셀프서비스가 단순 포털이 아니라, 개발자 작업 지점(IDE)까지 내려오는 경험을 강조한다.[^187]
3.11.2 Jenkins도 ‘Terraform + Helm + 조정 작업’ 대신 동일한 환경 블루프린트를 런치한다[^188]
발표자는 기존 Jenkins가 Terraform 파일을 실행하던 관행을 언급한다.[^189] 그리고 그 대신을 제시한다.[^190]
- 과거 방식: Terraform 실행 → Helm 실행 → 모니터링/시크릿 등 이것저것 “트윅(tweak)”[^191]
- 제안 방식: 개발자가 하는 것과 “정확히 같은 방식”으로 환경을 실행하라.[^192]
왜냐하면 그 환경은 “비즈니스 플로우를 위해” 만들어졌고, 반복 가능한 블루프린트 컨텍스트가 있기 때문이다.[^193]
또한 Jenkins가 이 블루프린트 컨텍스트를 통해 해당 환경에 변경을 롤아웃(roll out changes)할 수 있다고 말한다.[^194] 이는 개발자-로컬과 CI/CD의 환경 정의가 분리되지 않고, 같은 상위 모델을 공유한다는 의미로 제시된다.[^195]
3.12 “DevOps 모놀리스”를 피하고, 빌딩블록(DevOps 마이크로서비스)로 생각하라[^196]
발표자는 마지막 핵심 메시지로 “정말 중요한 것”을 강조한다.[^197]
- 많은 조직이 거대한 “DevOps 모놀리스(Devops monolith)”를 만든다고 말한다.[^198]
- Terraform에 더하고, 더하고, 더하고, Helm 트리거도 붙이고, 검증(validation)도 붙이면서 거대한 모듈이 된다는 묘사다.[^199]
대신 그는 사고방식을 바꾸라고 한다.[^200]
- “빌딩 블록(building block) 관점”으로 생각하라.[^201]
- 예: RDS 모듈, S3 모듈, Helm 차트를 각각 블록으로 두고[^202]
- 그것들을 하나의 블루프린트로 결합(combine)하면 된다.[^203]
- 그러면 한 번 배포(deploy it once)로 3개의 서로 다른 빌딩블록이 함께 제공된다.[^204]
그리고 이를 비유로 정리한다.[^205]
- “DevOps를 위한 마이크로서비스(microservices for Devops)”처럼 생각하라.[^206]
- 더 이상 거대한 모놀리스가 아니라 마이크로서비스다.[^207]
- 각 블록은 서로 다른 팀/서로 다른 전문성(expertise)을 가진 팀이 유지보수할 수 있다.[^208]
- 그 결과, 모든 것을 한 팀이 다 알 필요가 없어진다.[^209]
- 예를 들어 S3와 ACL만 담당하는 ‘마이크로서비스(블록)’만 잘 관리하면 된다는 식으로 설명한다.[^210]
이 결론은 초반의 스킬 갭 문제(희소한 Terraform 전문가 등)를 “전체를 아는 소수”에 의존하지 않도록 설계를 분해하고, 조립 가능한 상위 단위(블루프린트)로 제공하라는 조직 설계/아키텍처 처방으로 연결된다.[^211]
3.13 마무리: 감사 및 부스 안내[^212]
발표자는 “이게 전부다(that’s all)”라고 말하며 발표를 마친다.[^213] 그리고 들어줘서 고맙다고 인사한 뒤, 부스 3052로 방문해 달라고 안내한다.[^214]
4. 핵심 통찰[^215]
- [h 인프라 자동화의 문제는 ‘자동화 유무’가 아니라 ‘자동화의 정렬과 합성’이다.] 팀마다 다른 도구/방식으로 자동화하면 상호작용이 어려워지고, 결국 사일로와 마찰이 재생산된다는 논지다.[^216]
- [h “Terraform이 있다 = DevOps를 한다”가 아니다.] 도구 도입은 일부일 뿐이며, 문화·프로세스·레거시/하이브리드 현실이 속도를 계속 결정한다는 지적이다.[^217]
- [c 스킬 갭은 숫자로 증명되는 병목이며, 대기시간·이탈·레거시 고착으로 이어진다.] 11,000 개발자 vs 15 Terraform 전문가 같은 구조에서는 요청 처리 지연이 구조적으로 발생하고, 늦게 받은 환경을 장기 고정(5~10년 VM)시키는 행동까지 촉발한다.[^218]
- [h ‘리소스 단품’이 아니라 ‘비즈니스 플로우’를 제공해야 재요청과 마찰을 줄인다.] S3 버킷도 권한/접근/업로드까지 포함해야 “쓸 수 있는 것”이 되며, 이런 전체 흐름을 블루프린트에 담아야 한다는 주장이다.[^219]
- [h IaC 실행보다 어려운 것은 환경 라이프사이클 관리다.] 생성 이후의 운영·변경·정책·비용 통제를 다루는 상위 레이어가 필요하다고 본다.[^220]
- [h DevOps 모놀리스 대신 빌딩블록(DevOps 마이크로서비스)로 분해하면 전문성을 분산시킬 수 있다.] 각 팀이 특정 블록(S3+ACL 등)을 책임지고, 블루프린트에서 조립해 제공하면 “모두가 모든 것을 아는 소수”에 덜 의존하게 된다.[^221]
- 실행 시사점(발표 논리 기준)
- 자산을 자동 발견하고, 비용/정책 거버넌스를 먼저 내장한 뒤, 승인된 조합을 반복 가능한 블루프린트로 제공하라.[^222]
- 개발자 IDE와 CI(Jenkins)가 서로 다른 정의를 쓰지 않게, 동일한 블루프린트 컨텍스트로 환경을 런치/변경하도록 맞춰라.[^223]
- 거대한 IaC 모듈을 키우기보다, 재사용 가능한 모듈(예: RDS, S3, Helm)을 조립 가능한 블록으로 관리하라.[^224]
5. 헷갈리는 용어 정리[^225]
인프라 자동화 성숙도(maturity path/model): 수동 구축에서 시작해 부분 자동화(IaC)로 가고, 자동화의 섬/사일로를 거쳐, 보안·표준을 내장한 마찰 없는 셀프서비스로 진화한다는 단계적 관점.[^226]
자동화의 섬(islands of automation): 팀/부서별로 서로 다른 자동화 도구·스크립트·호출 방식이 난립해 상호운용이 어려워지고, 비즈니스 프로세스가 단절되는 상태.[^227]
마찰 없는(frictionless) 인프라: 개발자가 원할 때 즉시 인프라를 얻되, DevOps/플랫폼 팀이 보안·표준·속도를 내장한 셀프서비스로 제공하는 목표 상태.[^228]
Inner loop: 개발자가 개발/테스트/디버그를 빠르게 반복하는 개발자 중심 루프.[^229]
Outer loop: 메인 브랜치 머지 이후 드리프트 감지, 시크릿 관리, 정책/비용 통제 등 운영·거버넌스 작업이 중심인 루프.[^230]
블루프린트(blueprint): Terraform/Helm/Jenkins/GitHub Actions 등 다양한 자동화 빌딩블록과 구성요소를 비즈니스 플로우 단위로 합성해, 반복 가능하게 배포·오케스트레이션·제공(셀프서비스)하는 상위 모델.[^231]
자동 발견(auto discovery): 조직이 사용하는 자산(assets)을 발견해 가져오고, 거버넌스 하에 두기 위한 단계로 제시됨.[^232]
DevOps 모놀리스(DevOps monolith): Terraform 코드에 계속 기능을 덧붙이고 Helm/검증 등을 한 덩어리로 엮어 커진 거대한 자동화 모듈/시스템을 지칭.[^233]
DevOps를 위한 마이크로서비스(microservices for Devops): RDS/S3/Helm 등 기능별 블록을 독립적으로 관리하고, 블루프린트에서 조립해 제공하는 빌딩블록 사고방식에 대한 비유.[^234]
참고(콘텐츠 정보)[^235]
- 제목: AWS re:Invent 2022 - Navigating the infrastructure skills gap for DevOps teams (PRT089)[^235]
- 채널: AWS Events[^235]
- 길이: 13분 13초[^235]
- 링크: https://www.youtube.com/watch?v=55mOuHllXu4[^235]
[^1]: @[00:00]~ 발표 주제 소개(인프라/자동화 스킬 갭을 메우는 것).
[^2]: @[00:02] “bridging this skills gap, around infrastructure and infrastructure automation.”
[^3]: @[05:52]~@[06:48] 사용자층 대비 인프라 전문가가 매우 적고 보통 10x 비율이라 설명 + @[05:29]~@[05:48] 자동화의 섬/도구 난립 + @[04:47]~@[05:07] 복잡성.
[^4]: @[00:44]~@[02:39] 수동→부분 자동화→마찰 없는 셀프서비스→미래(앱이 인프라 정의) 전개.
[^5]: @[02:39]~@[02:56] 대부분 오렌지 라인(여러 도구로 일부 자동화, 팀 간 마찰) 언급.
[^6]: @[02:54]~@[03:06] 성숙도 모델에서 마찰 없는 세계로 어떻게 이동할지 질문 + @[08:13]~@[12:39] 블루프린트/셀프서비스/빌딩블록 해법 제시.
[^7]: @[08:13]~@[09:26] 블루프린트 개념 + @[10:42]~@[11:09] 자동 발견/거버넌스/반복 가능한 블루프린트 단계 + @[11:21]~@[11:56] IDE/Jenkins 통합 사용.
[^8]: @[00:02]~@[02:56] 발표 주제 및 현실 진단 구간.
[^9]: @[00:02]~@[00:40] 스킬 갭 소개 및 팀 비율 계산 연습.
[^10]: @[01:27]~@[02:25] 부분 자동화와 자동화의 섬 문제, 그리고 마찰 없는 셀프서비스 목표 설명.
[^11]: @[06:16]~@[06:28] 11,000 개발자 vs 15 Terraform 전문가 사례 + @[06:43]~@[06:48] 10x 비율.
[^12]: @[03:19]~@[03:28] Terraform이 있다고 DevOps 문화/프로세스가 보장되지 않음 + @[03:28]~@[03:43] 레거시/온프렘/VM 언급.
[^13]: @[10:20]~@[12:55] 라이프사이클 관리 필요 + IDE/Jenkins 활용 + DevOps 모놀리스 대신 빌딩블록/마이크로서비스 비유.
[^14]: 전체 타임라인을 순서대로 재구성한 본론 섹션.
[^15]: @[00:00]~@[00:40] 도입부 흐름.
[^16]: @[00:00]~@[00:02] “My name is Tomer… field CTO for Quali… talk about bridging skills gap…”
[^17]: @[00:02]~@[00:09] 인프라 및 자동화 스킬 갭을 다룬다고 명시.
[^18]: @[00:09]~@[00:15] “quick exercise… Take 10 seconds.”
[^19]: @[00:15]~@[00:20] DevOps/플랫폼/인프라 하는 사람 수를 세어보라고 요청.
[^20]: @[00:15]~@[00:30] 그 사람들이 서비스하는 사람 대비 비율을 계산하라고 함.
[^21]: @[00:32]~@[00:40] “Five people… serving 500 people…” 예시.
[^22]: @[05:48]~@[06:54] 후반부에서 같은 연습을 다시 불러 병목으로 연결.
[^23]: @[00:44]~@[02:39] 인프라 자동화 성숙도 경로 설명.
[^24]: @[00:40]~@[00:44] “let’s start and talk about infrastructure automation.”
[^25]: @[00:44]~@[01:16] 수동 구축의 출발 및 문제.
[^26]: @[00:49]~@[00:52] 클라우드/온프렘에 무언가 필요.
[^27]: @[00:52]~@[00:55] VM일 수도 Lambda일 수도.
[^28]: @[00:55]~@[01:02] 설계/구축/아키텍팅을 수동으로 천천히.
[^29]: @[01:02]~@[01:12] “we understand… hard, not consistent, not stable…”
[^30]: @[01:03]~@[01:12] 수동의 비일관/불안정 문제 진술.
[^31]: @[01:12]~@[01:16] 태깅을 수동으로 일관되게 하기 어렵다는 예.
[^32]: @[01:03]~@[01:16] 수동 작업의 운영 품질 문제를 태깅 예시로 구체화.
[^33]: @[01:16]~@[01:31] 부분 자동화 단계.
[^34]: @[01:16]~@[01:27] “next stop… automate part of those tasks.”
[^35]: @[01:27]~@[01:31] CloudFormation, Terraform, Pulumi 등 도구 예.
[^36]: @[01:27]~@[01:31] 도구보다 “부분 자동화로 가는 단계” 자체를 강조.
[^37]: @[01:31]~@[01:59] 자동화의 섬과 사일로 문제.
[^38]: @[01:31]~@[01:43] 여러 팀/부서가 자동화 원함.
[^39]: @[01:43]~@[01:45] “But it is different.”
[^40]: @[01:31]~@[01:43] “islands of automation” 표현.
[^41]: @[01:45]~@[01:57] 서로 다른 도구들이 상호작용해야 해서 함께 작동시키기 어려움.
[^42]: @[01:57]~@[01:59] “eventually we have silos, processes again.”
[^43]: @[01:45]~@[01:59] 상호운용 난제로 비즈니스 프로세스 달성 실패 주장.
[^44]: @[01:59]~@[02:25] 마찰 없는 단계 설명.
[^45]: @[01:59]~@[02:06] “next level… what we really all want to see…”
[^46]: @[02:06]~@[02:11] “Developers get whatever they want, when they want.”
[^47]: @[02:11]~@[02:18] DevOps/플랫폼 팀이 셀프서비스 제공.
[^48]: @[02:18]~@[02:25] fast/rapid/secure/standardized 인프라를 매우 빠르게 제공.
[^49]: @[02:06]~@[02:25] 목표 상태를 속도+보안+표준+셀프서비스로 정의.
[^50]: @[02:25]~@[02:39] 미래 단계 언급.
[^51]: @[02:25]~@[02:34] “application… defining the infrastructure themselves.”
[^52]: @[02:34]~@[02:39] “won’t really need to think about infrastructure that much.”
[^53]: @[02:39]~@[02:56] 현실 진단(오렌지 라인).
[^54]: @[02:39]~@[02:54] 많은 기업이 여러 도구로 일부 자동화, 매우 어려움.
[^55]: @[02:54]~@[03:06] 성숙도 모델 상향 이동 질문.
[^56]: @[02:54]~@[03:06] “move them up… toward the frictionless world.”
[^57]: @[03:06] 이후 ‘느리게 하는 것’과 갭을 다루겠다고 전환.
[^58]: @[03:06]~@[03:43] 속도 저하 요인.
[^59]: @[03:06] “let’s talk about what’s slowing us down.”
[^60]: @[03:13]~@[03:28] 도구≠DevOps.
[^61]: @[03:13]~@[03:20] 2014/16/18에도 DevOps adoption을 말했고 지금도 과정 중.
[^62]: @[03:20]~@[03:28] Terraform 예시로 문화/프로세스 부재를 지적.
[^63]: @[03:20]~@[03:25] “The fact you have terraform doesn’t mean the culture…”
[^64]: @[03:25]~@[03:28] “Doesn’t mean all the processes…”
[^65]: @[03:19]~@[03:28] DevOps를 문화/프로세스로 규정.
[^66]: @[03:28]~@[03:43] 레거시/온프렘/VM 언급.
[^67]: @[03:28]~@[03:34] “legacy infrastructure… holding us back.”
[^68]: @[03:34]~@[03:39] AWS 서버리스/RDS 매니지드만 있는 게 아님.
[^69]: @[03:39]~@[03:42] “We also have on-prem stuff.”
[^70]: @[03:42]~@[03:43] “We also have VM workloads.”
[^71]: @[03:43]~@[03:50] 속도를 내기 어렵다고 연결.
[^72]: @[03:28]~@[03:50] 하이브리드 현실이 속도 저하 요인이라는 맥락.
[^73]: @[03:50]~@[04:37] SDLC 전반의 업무 범위.
[^74]: @[03:50]~@[03:59] 플랫폼 팀이 SDLC 동안 해야 하는 일을 보라고 제안.
[^75]: @[03:59]~@[04:06] 앱/인프라와 무관하게 해야 한다는 전제.
[^76]: @[04:06]~@[04:11] inner loop 설명.
[^77]: @[04:06]~@[04:11] 개발/테스트/디버그를 매우 빠르게.
[^78]: @[04:06]~@[04:11] 속도 중심 inner loop 정의.
[^79]: @[04:11]~@[04:37] outer loop 설명.
[^80]: @[04:11]~@[04:16] “after the merge to the main branch.”
[^81]: @[04:16]~@[04:20] drift detection 필요.
[^82]: @[04:20]~@[04:22] secrets 관리.
[^83]: @[04:22]~@[04:25] policies and cost control.
[^84]: @[04:25]~@[04:37] 마이크로서비스/컴포넌트 수와 무관하게 플랫폼 팀의 일.
[^85]: @[03:50]~@[04:37] SDLC 전반 부담을 강조하는 흐름.
[^86]: @[04:37]~@[05:48] 3가지 장애물.
[^87]: @[04:37]~@[04:44] “So what’s stopping DevOps teams…” 질문.
[^88]: @[04:37]~@[04:44] 마찰 없는 세계로의 진화를 막는 요인 질문.
[^89]: @[04:44]~@[05:36] “mainly three things” 후 복잡성/도구/자동화의 섬 제시.
[^90]: @[04:47]~@[05:07] 복잡성/스케일 이슈.
[^91]: @[04:47]~@[04:55] “become too complex.”
[^92]: @[04:55]~@[04:59] scalability issues.
[^93]: @[04:59]~@[05:07] 복잡성을 다룰 만큼 빠르게 인프라 제공이 어려움.
[^94]: @[04:47]~@[05:07] 복잡성→속도 저하 논리.
[^95]: @[05:07]~@[05:29] 개발용 내부 도구의 운영 전이.
[^96]: @[05:07]~@[05:20] in-house tools/scripts/utilities 언급.
[^97]: @[05:07]~@[05:20] staging/production까지 밀어 넣음.
[^98]: @[05:20]~@[05:23] “not really meant for that… meant for development.”
[^99]: @[05:23]~@[05:29] 개발용 도구를 운영에 푸시하는 것이 발목을 잡음.
[^100]: @[05:07]~@[05:29] 임시 개발 도구의 운영화 문제 제기.
[^101]: @[05:29]~@[05:48] islands of automation 재강조.
[^102]: @[05:29]~@[05:33] “the third thing… islands of automation.”
[^103]: @[05:33]~@[05:36] way too many tools.
[^104]: @[05:33]~@[05:36] way too many ways to invoke them.
[^105]: @[05:36]~@[05:48] developer station/Jenkins/아무도 모르는 스크립트.
[^106]: @[05:29]~@[05:48] 도구/호출 방식 난립의 문제를 설명.
[^107]: @[05:48]~@[07:55] 비율→대기시간→고착 문제.
[^108]: @[05:48]~@[06:54] 연습 상기 + funnel/bottleneck 결과로 전개.
[^109]: @[05:54]~@[06:13] 사용자층 vs 인프라 전문가층 설명.
[^110]: @[05:54]~@[06:09] 위에 많은 사용자, 아래에 적은 전문가.
[^111]: @[06:43]~@[06:48] “Usually we see the 10x ratio…”
[^112]: @[06:13]~@[06:33] 11,000 vs 15 사례.
[^113]: @[06:16]~@[06:18] “11,000 developers…”
[^114]: @[06:18]~@[06:28] “15 people… secure certified Terraform files.”
[^115]: @[06:16]~@[06:33] 병목을 수치로 보여주는 사례로 사용.
[^116]: @[06:16]~@[06:33] 사례 제시 후 “how much work… how hard…” 설명.
[^117]: @[06:50]~@[07:11] 대기시간 결과.
[^118]: @[06:54]~@[06:59] “super long wait times…”
[^119]: @[06:59]~@[07:03] S3 버킷도 hours.
[^120]: @[07:03]~@[07:05] weeks 가능.
[^121]: @[07:05]~@[07:11] minutes도 허용치보다 길 수 있음.
[^122]: @[06:54]~@[07:11] 지연의 상대성을 설명.
[^123]: @[07:11]~@[07:31] 불만/이탈.
[^124]: @[07:11]~@[07:26] 마찰이 가득한 환경에서 모두를 행복하게 하기 어려움.
[^125]: @[07:26]~@[07:31] “People are not happy… they might go away.”
[^126]: @[07:26]~@[07:31] 인력 유지 문제로 연결.
[^127]: @[07:31]~@[07:55] 환경 고착(영구 VM) 문제.
[^128]: @[07:31]~@[07:40] “you’re never gonna let go.”
[^129]: @[07:43]~@[07:47] 2주 기다린 VM이면 “that’s it.”
[^130]: @[07:47]~@[07:51] 5~10년 VM 고착.
[^131]: @[07:51]~@[07:55] “Why is that bad?… imagine…”
[^132]: @[07:51]~@[07:55] 나쁨의 이유는 청중 상상에 맡기되, 장기 고착의 문제를 지적.
[^133]: @[08:02]~@[09:26] Quali 블루프린트 소개.
[^134]: @[08:02]~@[08:17] 문제 재언급 후 “what we Quali provides… blueprints.”
[^135]: @[08:17]~@[08:47] 블루프린트 정의(자동화 합성).
[^136]: @[08:17]~@[08:24] 자동화의 섬 세계에서 다양한 자동화를 가져온다고 설명.
[^137]: @[08:17]~@[08:24] “take all the different automations…”
[^138]: @[08:24]~@[08:26] “Compose them all together.”
[^139]: @[08:26]~@[08:30] IaC 블록/앱 설정 가능.
[^140]: @[08:30]~@[08:40] Terraform/Helm/Jenkins/GitHub Actions 등 불문.
[^141]: @[08:40]~@[08:47] 빌딩블록을 모아 “this is my blueprint.”
[^142]: @[08:17]~@[08:47] 도구 비종속 상위 조립 단위로 설명.
[^143]: @[08:47]~@[09:00] 반복 가능한 배포 프로세스 언급.
[^144]: @[08:47]~@[08:56] “repeatable process to deploy… enable users…”
[^145]: @[08:47]~@[08:56] repeatable 강조.
[^146]: @[09:00]~@[09:20] 비즈니스 플로우 모델링(S3 예시).
[^147]: @[09:00]~@[09:04] 컴포넌트는 비즈니스 플로우를 충족해야 함.
[^148]: @[09:04]~@[09:15] S3 버킷 단품의 불충분함 설명.
[^149]: @[09:06]~@[09:09] 권한 없으면 S3 버킷이 아님.
[^150]: @[09:09]~@[09:11] URL(접근 정보) 없으면 불충분.
[^151]: @[09:11]~@[09:15] 업로드 권한 없으면 불충분.
[^152]: @[09:15]~@[09:20] 전체 비즈니스 플로우를 블루프린트에 모델링.
[^153]: @[09:04]~@[09:20] 리소스 단품 제공의 한계를 논리적으로 강화.
[^154]: @[09:20]~@[09:41] 셀프서비스 확장과 속도.
[^155]: @[09:20]~@[09:26] scalable self-service로 enable.
[^156]: @[09:26]~@[09:41] 시스템과 연결하면 빠르게 성장/속도 향상.
[^157]: @[09:41]~@[10:20] inner/outer loop를 속도/타임투마켓으로 연결.
[^158]: @[09:41]~@[09:46] inner loop에서 velocity 중요.
[^159]: @[09:46]~@[09:53] IDE/노트북에서 필요한 것 즉시.
[^160]: @[09:53]~@[09:55] “That’s velocity.”
[^161]: @[09:55]~@[10:05] outer loop = time to market.
[^162]: @[09:59]~@[10:05] 경쟁사보다 빠르게.
[^163]: @[10:05]~@[10:20] 비즈니스 플로우 컴포넌트 포함→오케스트레이션/관리/제공.
[^164]: @[09:41]~@[10:20] 개발 경험과 비즈니스 성과의 연결.
[^165]: @[10:20]~@[10:36] IaC 실행 vs 라이프사이클 관리.
[^166]: @[10:20]~@[10:24] “just launching an IaC file… that’s nice”
[^167]: @[10:20]~@[10:24] Pulumi/Terraform 언급.
[^168]: @[10:24]~@[10:31] 라이프사이클 전반 관리가 어렵다고 강조.
[^169]: @[10:20]~@[10:31] 생성 이후 운영 어려움을 핵심으로 둠.
[^170]: @[10:31]~@[10:36] “provide… on top of the ability to model the environment.”
[^171]: @[10:36]~@[11:09] 3단계 정리.
[^172]: @[10:36]~@[10:42] “three simple steps.”
[^173]: @[10:42]~@[10:44] “figure out what are the assets.”
[^174]: @[10:44]~@[10:46] “We call that auto discovery.”
[^175]: @[10:49]~@[10:55] 자산을 발견/가져오고 거버넌스 보장.
[^176]: @[10:55]~@[11:00] 큰 RDS로 비용 폭탄 방지 예시.
[^177]: @[11:02]~@[11:09] repeatable blueprints로 end users에 deliver.
[^178]: @[10:49]~@[11:00] 거버넌스를 비용/정책 통제로 설명.
[^179]: @[10:42]~@[11:09] 자동 발견→거버넌스→블루프린트 제공 흐름.
[^180]: @[11:09]~@[11:56] IDE 원클릭 및 Jenkins 동일 환경 런치.
[^181]: @[11:09]~@[11:21] 블루프린트 모델링/오케스트레이션/제공이 유연성을 준다고 설명.
[^182]: @[11:21]~@[11:38] IDE에서 환경 런치.
[^183]: @[11:21]~@[11:27] “developer can now launch… from his IDE”
[^184]: @[11:27]~@[11:32] 플랫폼 팀이 알 필요 없다고 표현.
[^185]: @[11:32]~@[11:36] 모델링/승인/정책 포함.
[^186]: @[11:36]~@[11:38] 원클릭 환경.
[^187]: @[11:21]~@[11:38] 개발자 접점으로 셀프서비스를 내림.
[^188]: @[11:38]~@[12:05] Jenkins와 블루프린트.
[^189]: @[11:38]~@[11:43] Jenkins가 Terraform을 런치해 왔다고 언급.
[^190]: @[11:43]~@[11:56] 그 대신 “환경을 그대로 런치” 제안.
[^191]: @[11:43]~@[11:50] Terraform/Helm/모니터링/시크릿 트윅 묘사.
[^192]: @[11:50]~@[11:56] 개발자가 하는 것과 동일하게 환경 런치.
[^193]: @[11:56] 비즈니스 플로우를 위해 만든 환경이라는 근거.
[^194]: @[11:56]~@[12:05] Jenkins가 변경을 롤아웃.
[^195]: @[11:50]~@[12:05] 개발자와 CI의 환경 정의를 통일하는 맥락.
[^196]: @[12:05]~@[13:02] DevOps 모놀리스 vs 빌딩블록/마이크로서비스 비유.
[^197]: @[12:05]~@[12:13] “what’s really important…” 전환.
[^198]: @[12:05]~@[12:13] “huge… Devops monolith” 표현.
[^199]: @[12:13]~@[12:23] Terraform에 계속 더하고 Helm/validation 붙여 거대 모듈이 됨.
[^200]: @[12:23]~@[12:28] “Instead of thinking this way, start thinking…”
[^201]: @[12:28] building block notion 제안.
[^202]: @[12:28]~@[12:36] RDS/S3 모듈, Helm chart 예시.
[^203]: @[12:28]~@[12:36] 블루프린트로 결합.
[^204]: @[12:36]~@[12:39] 한 번 배포, 세 블록.
[^205]: @[12:39]~@[12:47] 마이크로서비스 비유.
[^206]: @[12:39]~@[12:43] “Think about it as microservices for Devops.”
[^207]: @[12:43]~@[12:47] 모놀리스가 아니라 마이크로서비스.
[^208]: @[12:47]~@[12:52] 각 블록은 다른 팀이 유지보수 가능.
[^209]: @[12:52]~@[12:55] “you don’t need to care about everything.”
[^210]: @[12:55]~@[13:02] S3와 ACL만 책임지는 블록 예시.
[^211]: @[12:39]~@[13:02] 스킬 갭을 구조적으로 완화하는 설계 처방으로 연결.
[^212]: @[13:02]~@[13:06] 마무리.
[^213]: @[13:02]~@[13:04] “That’s all for me.”
[^214]: @[13:04]~@[13:06] 감사 및 booth 3052 방문 요청.
[^215]: 발표 전체 논리에서 도출한 통찰(복수 구간 근거).
[^216]: @[01:31]~@[01:59] 자동화의 섬 → 사일로/프로세스 문제.
[^217]: @[03:19]~@[03:28] 도구≠DevOps 문화/프로세스.
[^218]: @[06:16]~@[06:28] 11,000 vs 15 + @[06:54]~@[07:11] 대기시간 + @[07:43]~@[07:51] VM 장기 고착.
[^219]: @[09:04]~@[09:20] S3 버킷 예시로 비즈니스 플로우 모델링 강조.
[^220]: @[10:20]~@[10:31] IaC 실행은 쉽고 라이프사이클 관리는 어렵다.
[^221]: @[12:05]~@[13:02] DevOps 모놀리스 비판 및 빌딩블록/마이크로서비스 비유.
[^222]: @[10:42]~@[11:09] auto discovery + 거버넌스 + repeatable blueprints.
[^223]: @[11:21]~@[12:05] IDE와 Jenkins가 동일한 환경 블루프린트를 사용.
[^224]: @[12:28]~@[12:39] RDS/S3/Helm 블록을 조립해 블루프린트 구성.
[^225]: 발표에서 반복 사용된 개념어를 정리한 섹션.
[^226]: @[00:44]~@[02:39] 성숙도 경로 설명.
[^227]: @[01:31]~@[01:59] islands of automation 정의 맥락.
[^228]: @[02:06]~@[02:25] frictionless + self-service + secure/standardized.
[^229]: @[04:06]~@[04:11] inner loop 설명.
[^230]: @[04:11]~@[04:25] outer loop(머지 이후 운영 항목) 설명.
[^231]: @[08:17]~@[09:26] 블루프린트 구성/반복/셀프서비스 설명.
[^232]: @[10:42]~@[10:46] auto discovery 정의.
[^233]: @[12:05]~@[12:23] DevOps monolith 설명.
[^234]: @[12:39]~@[12:52] microservices for Devops 비유.
[^235]: 사용자가 제공한 메타데이터(제목/채널/길이/링크).