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

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

[? 질문] 엔터프라이즈에서 마이크로서비스/컨테이너/서버리스 확산으로 복잡해진 인프라·배포·운영을, **표준화(거버넌스/보안/컴플라이언스)**와 **개발 속도(자율성/생산성)**를 동시에 만족시키면서 어떻게 운영할 수 있는가[^2]
[= 답] 운영팀이 **표준 템플릿(환경/서비스)**을 정의·버전관리하고, 개발팀은 이를 **셀프서비스(원클릭 배포)**로 사용해 워크로드와 CI/CD까지 함께 생성·운영하도록 하는 관리형 플랫폼(AWS Proton) 접근이 균형점이 된다[^3]

[? 질문] 엔터프라이즈 고객들이 이 문제를 해결하려 할 때 나타나는 대표적 접근 패턴은 무엇이며 각각의 트레이드오프는 무엇인가[^4]
[= 답] (1) 중앙 인프라팀이 모두 배포(통제↑, 속도↓ 병목) (2) 전통적 PaaS/옵션 제공(속도↑, 인프라 통제↓) (3) 인하우스 개발자 플랫폼 구축(중간 지점 가능하지만 별도 개발/운영 부담)이며, Proton은 운영 부담을 낮추며 균형을 제공한다[^5]

[? 질문] AWS Proton을 실제로 쓰려면 운영자(인프라 관리자)와 개발자는 각각 무엇을 준비·수행해야 하는가[^6]
[= 답] 운영자는 Environment(공유 기반) 템플릿/Service 템플릿을 IaC로 정의하고 콘솔에 등록·버전관리하며 실제 **환경(예: VPC, ECS 클러스터 등)**을 배포한다; 개발자는 카탈로그에서 템플릿을 선택해 파라미터 입력만으로 서비스 인스턴스 + CI/CD + 모니터링 연계까지 생성하고 상태/버전 준수 여부를 콘솔에서 확인한다[^7]

---

2. 큰 그림[^8]

이 발표는 엔터프라이즈가 마이크로서비스로 전환하면서 발생하는 운영 표준화 요구와 개발팀의 빠른 배포/자율성 요구의 충돌을 배경으로, AWS의 관리형 서비스인 AWS Proton으로 CI/CD를 포함한 애플리케이션 배포·운영 방식을 어떻게 정립할 수 있는지 설명한다.[^9] 서비스가 등장한 배경(아마존 내부 경험 포함)과 고객들의 기존 해결 패턴, Proton의 핵심 개념(환경/서비스 템플릿), 운영자·개발자 관점의 실제 사용 흐름, 템플릿 버전 전략과 프리뷰/비용/시작 방법까지 다룬다.[^10]

• 운영팀은 조직 표준(네트워크/보안/배포 방식/모니터링)을 강제하고 싶지만, 개발팀은 이를 기다리느라 속도가 느려지는 문제를 겪는다.[^11] Proton은 이 둘을 템플릿 기반 셀프서비스로 연결한다.[^12]
• Proton의 중심은 **Environment(공유 기반 리소스)**와 **Service(워크로드)**를 **템플릿(IaC)**으로 정의하고, 개발자가 이를 카탈로그에서 선택해 원클릭 배포 + CI/CD 파이프라인 + 운영 도구까지 한 묶음으로 생성하는 방식이다.[^13]
• 템플릿은 버전관리되며, 콘솔에서 각 서비스 인스턴스가 최신 템플릿을 따르는지/어떤 버전 차이가 있는지(경고 등)를 한눈에 보고 컴플라이언스를 점검할 수 있다는 점을 강조한다.[^14]

---

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

3.1 세션 시작: 발표 범위와 진행 방식 안내[^16]

발표자는 온라인 이벤트 시청자에게 인사한 뒤, 실시간 Q&A 참여 방법(화면의 Q&A/질문 창에 궁금한 점 남기면 메시지로 답변)을 안내한다.[^17] 이어 오늘 다룰 내용의 흐름을 “AWS Proton을 사용해 엔터프라이즈 환경에 DevOps 운영 방식을 어떻게 적용할 것인가”로 잡고, 다음 순서로 진행하겠다고 예고한다.[^18]

• Proton이 나오게 된 배경[^19]
• Proton이 해결하려는 문제 정의와 해결 방식[^20]
• 사용자 관점에서 Proton을 어떤 방식으로 사용하는지[^21]
• 실제 체험을 위한 필수 정보(프리뷰/비용/시작 가이드 등) 소개[^22]

3.2 배경: 마이크로서비스 확산과 “관리해야 할 것”의 폭발[^23]

발표는 “이제는 마이크로서비스 시대”라는 전제로 시작한다.[^24] 많은 고객이 더 빠른 신규 서비스 출시와 고도화 대응을 위해 클라우드 도입뿐 아니라, 커다란 애플리케이션을 더 잘게 쪼개는 기반(마이크로서비스)을 마련하고 있다고 말한다.[^25]

마이크로서비스의 정의는 “기존의 하나의 커다란 애플리케이션을 여러 조각(컴포넌트)으로 쪼개 처리하도록 하는 아키텍처”로 설명된다.[^26] 발표자는 쇼핑몰 예시를 들어, 과거 하나의 애플리케이션에 묶여 있던 기능을 다음처럼 분리할 수 있다고 말한다.[^27]

• 화면을 보여주는 Store Front(스토어 프론트) 서비스[^28]
• Payment(결제) 서비스[^29]
• Order(주문) 서비스[^30]
• 각 서비스가 사용하는 별도 데이터베이스[^31]

이렇게 분리하면 각 컴포넌트 개발이 전체 서비스에 미치는 영향을 최소화하고, 컴포넌트 자체는 더 빠르게 배포해 나갈 수 있다고 주장한다.[^32]

하지만 발표자는 “마이크로서비스 하나를 만들기 위해서도 정말 많은 자원들이 필요하고, 이를 잘 관리할 수 있어야 한다”고 강조한다.[^33] 특히 컨테이너와 서버리스 기반으로 갈수록 구조가 더 복잡해진다고 한다.[^34]

마이크로서비스 1개를 올리기 위해 필요한 것들(발표자가 열거)[^35]

발표는 “하나의 간단한 마이크로서비스를 올린다고 생각해 보자”는 가정으로, 필요한 요소를 단계적으로 늘어놓는다.[^36]

1. 컴퓨팅 자원

• 서버리스라면 예: Lambda 같은 형태일 수 있고[^37]
• 서버에서 컨테이너로 올린다면 예: ECS/Fargate 같은 컨테이너 서비스일 수 있다고 언급한다.[^38]

2. 외부 접근을 가능케 하는 네트워크/엔드포인트 구성

• 외부에서 접근 가능하게 하려면 엔드포인트, 접근 경로를 어떻게 할지 등을 결정해야 한다고 말한다.[^39]

3. 배포/빌드 자동화를 위한 CI/CD 파이프라인

• “CI/CD 파이프라인 역시 필요”하다고 명시한다.[^40]

4. 운영 안정성 확인을 위한 모니터링/각종 설정

• “더 안정적으로 운영할 수 있는지 확인하기 위한 여러 가지 모니터링 설정들도 필요”하다고 말한다.[^41]

이 나열은 “마이크로서비스 = 코드만 쪼개는 문제”가 아니라, 실제로는 배포·운영·보안·모니터링까지 포함한 운영 체계 전체의 복잡도가 증가한다는 논지를 만들기 위한 전개다.[^42]

3.3 조직 관점의 충돌: 운영팀의 표준화 vs 개발팀의 속도/자율성[^43]

발표자는 “이게 실제로 우리의 조직에는 어떤 의미일까요?”라고 질문을 던지고, 운영팀과 개발팀의 서로 다른 요구를 대비시킨다.[^44]

운영팀(운영 형태 입장)의 요구[^45]

운영팀은 위에서 열거된 모든 항목(컴퓨팅, 네트워크, CI/CD, 모니터링 등)이 회사의 네트워크 정책/보안 정책에 맞게 배포되었는지, 성공적으로 운영되는지 등을 확인할 수 있기를 원한다고 말한다.[^46] 즉, 운영팀의 핵심 관심은 정책 준수(거버넌스)와 통제다.[^47]

개발팀(개발자 입장)의 현실과 요구[^48]

반면 개발자 관점에서는 “이 모든 것들을 다 신경 쓰면서 일일이 개발하기 쉽지” 않다고 말한다.[^49] 특히 전체 스택을 한 서비스가 아니라 “수십 개, 많게는 수백 개”를 만들어야 할 때 문제는 더 커진다고 한다.[^50]

여기서 발표자는 “표준화에 대한 욕구(운영)와 개발 속도/생산성에 대한 욕구(개발)의 충돌”이 발생한다고 정리한다.[^51]

• 운영팀은 모든 자원이 운영 정책에 맞게 생성·관리되는지 확인해야 하고, 수많은 마이크로서비스가 조건을 충족하는지 확인하고, 필요 시 수정하게 해야 하며, 신규 서비스 도입 시 승인/가이드를 제공해야 한다고 말한다.[^52]
• 개발팀은 속도와 자율성이 더 중요하며, “개발 준비가 됐는데 다른 사람을 한참 기다리고 있다”는 식의 병목을 싫어한다고 말한다.[^53]
• 개발자는 업데이트(정책/인프라 변경)가 필요한 것을 이해하지만, 애플리케이션 개발에 집중해야 하는데 인프라 관련 요구가 계속 오면 집중 시간이 줄어든다는 현실을 든다.[^54]

이 대목의 결론은 “개발자가 인프라 탭에서 이것저것 하라는 요구를 계속 받으면 애플리케이션에 집중할 시간이 줄어든다”는 문제의식이다.[^55]

3.4 아마존닷컴의 실제 경험: 마이크로서비스 증가가 통제 불가능 상태를 만들다[^56]

발표자는 이 문제가 “아마존닷컴에서 경험했던 어려움”이라고 말하며 내부 사례를 든다.[^57] 규모가 확장되면서 마이크로서비스 개수가 늘어 수백 개 수준이 되자, 버전 업데이트를 어떻게 할지, 배포를 어떻게 할지, 각종 이미지(컨테이너 이미지로 추정)를 개발 쪽으로 관리하다 보니 “완전히 컨트롤 불가능한 상황”이 되었다고 설명한다.[^58]

그 결과 인프라 팀은 더 이상 “우리 인프라 자원들이 보안 정책을 준수하고 있다”고 자신 있게 말하기 어려운 상황이 되어간다고 말한다.[^59] 그리고 이는 아마존만의 문제가 아니라 많은 엔터프라이즈 고객이 겪는 문제라고 확장한다.[^60]

3.5 엔터프라이즈 고객의 3가지 접근 패턴과 한계[^61]

발표자는 관찰 결과, 많은 엔터프라이즈 고객이 이 문제를 접근할 때 “세 가지 패턴”이 있다고 정리한다.[^62] 이 패턴들은 “표준화와 속도를 어떻게 다룰 것인가” 관점에서 차이가 난다고 한다.[^63]

패턴 1: 중앙(인프라팀)이 직접 모든 것을 배포[^64]

가장 표준화된 형태를 유지할 수 있는 시나리오로, 개발자가 필요한 클라우드 자원을 받기 위해서는 반드시 인프라 팀에 요청(티켓/매칭 등)을 하고, 인프라 팀이 작업한 뒤 결과를 전달하는 방식이라고 설명한다.[^65]

• 장점: 인프라/보안/정책에 대한 **통제(컨트롤)**를 인프라 조직이 강하게 유지 가능[^66]
• 단점: 비즈니스 관점에서 인프라 팀이 개발 속도의 병목 포인트가 되어 고민이 생긴다고 지적[^67]

패턴 2: 전통적 PaaS/플랫폼 서비스로 개발자 자율성 확대[^68]

전통적인 PaaS(플랫폼) 서비스를 사용해 개발자가 코드 저장소부터 시작해 필요한 것들을 직접 구성할 수 있게 되면 개발 속도는 확보되지만, “인프라에 대한 컨트롤 자체는 어려워진다”고 말한다.[^69] 즉, 개발 속도를 고정(확보)하는 대신 인프라 제어를 포기하게 되는 구도가 생긴다고 설명한다.[^70]

패턴 3: 인하우스 개발자 플랫폼을 별도 구축[^71]

두 옵션의 중간 지점을 찾기 위해 사내 개발자 플랫폼을 만드는 고객도 많다고 말한다.[^72] 이를 통해 컨트롤과 속도의 균형점을 찾을 수는 있지만, 고객 입장에서는 “제3의 애플리케이션을 별도로 개발하고 관리”해야 하는 부담을 안고 가야 한다고 강조한다.[^73]

특히 이런 개발자 플랫폼은 비즈니스 성과와 직접 연관이 크지 않다고 예를 들어 설명한다.[^74] 커머스 회사라면 개발자 플랫폼을 만들어도 그것 자체가 매출 같은 성과로 직결되는 것이 아니라 “순전히 운영을 잘하기 위해 감내해야 하는 비용”이라는 논리다.[^75]

[!IMPORTANT] 운영 플랫폼 구축의 딜레마
개발 생산성을 위해 플랫폼이 필요해지지만, 엔터프라이즈는 그 플랫폼을 직접 만들고 운영하는 일이 “비즈니스 차별화”가 아니라 “운영비”가 되기 쉽다는 문제의식을 제시한다.[^76]

3.6 AWS Proton의 등장: 운영 통제와 개발 생산성의 균형을 ‘관리형’으로 제공[^77]

이런 문제를 해결하기 위해 등장한 서비스가 AWS Proton이라고 소개한다.[^78] 발표자는 Proton이 “상황을 모두 제어하고 싶은 운영자 니즈”와 “개발자 니즈” 사이에서 균형을 잡을 수 있는 방법을 관리형으로 제공한다고 말한다.[^79]

Proton이 제공하는 방향성은 다음처럼 표현된다.[^80]

• 최소한의 운영 부담[^81]
• (정책/표준 준수) 컴플라이언스 확보[^82]
• 개발 효율성/속도 확보[^83]

또한 Proton을 “컨테이너 및 서버리스 애플리케이션을 사용하는 고객을 위해 만든, 완전 관리형 애플리케이션 배포 서비스”로 소개한다.[^84]

Proton의 작동 방식(큰 흐름)[^85]

• 인프라 관리자가 필요한 템플릿을 정의해 Proton에 발행/등록[^86]
• 개발자는 그 옵션을 탐색해 클릭하고 배포(셀프서비스)[^87]
• 템플릿에는 인프라 자원뿐 아니라 CI/CD 파이프라인, 애플리케이션 모니터링에 필요한 도구까지 포함될 수 있다고 강조[^88]
• 배포 완료 후 인프라 관리자와 개발팀이 함께 자원의 정상 여부를 모니터링하고, 템플릿이 구형인지(최신 버전인지) 등도 확인 가능하다고 말한다.[^89]

이 대목은 “플랫폼 팀이 하던 일을 ‘템플릿 표준화 + 셀프서비스’로 치환”하는 구도이며, 운영·개발 양측이 동일한 화면/기준으로 상태와 준수 여부를 본다는 점을 강조한다.[^90]

3.7 Proton을 만들며 정리된 핵심 기능과 고객 체감 장점[^91]

Proton이 나오기까지 내부 개발자 플랫폼을 쓰는 엔터프라이즈 고객들과 많은 대화가 있었고, 그 과정을 통해 “운영자 컨트롤”과 “개발자 생산성”을 모두 잡기 위한 핵심 기능을 확정했다고 말한다.[^92]

발표에서 언급되는 핵심 기능 요소는 다음과 같다.[^93]

• 개발자를 위한 셀프서비스 인터페이스[^94]
• 운영자를 위한 원클릭(표준화된 배포/생성) 경험[^95]
• CI/CD 파이프라인과의 통합[^96]
• 다양한 서드파티 서비스와의 통합 지원[^97]

이어 고객이 느낄 장점을 “세 가지”로 정리한다.[^98]

1. (운영/표준 관점) AWS가 신규로 제공하는 기능을 더 빠르고 확실하게, 자신감을 가지고 도입 가능[^99]

• 인프라 팀이 충분히 테스트하고 제어된 옵션이 표준으로 개발자에게 전달되므로, 문제 발생 여지를 최소화하고 더 빠르게 전달할 수 있다고 설명한다.[^100]

2. (개발 관점) 개발팀은 클라우드 기반 애플리케이션을 빠르게 개발하고, 필요하면 기존 애플리케이션 전환 작업에도 더 집중 가능[^101]

3. (인프라팀 관점) 인프라팀은 반복적인 태스크에서 벗어나 비즈니스에 맞는 최적 아키텍처를 정리하는 데 더 집중 가능[^102]

[!TIP] 발표자가 제시하는 역할 재배치의 요지
운영팀은 “표준 템플릿/가드레일 제공자”가 되고, 개발팀은 “그 위에서 빠르게 배포·반복”하는 구조로 책임을 재정렬한다는 메시지다.[^103]

3.8 Proton 사용을 위한 2가지 핵심 개념: Environment와 Service[^104]

이제 “실제로 사용하려면 어떻게 쓰는지”로 넘어가며 Proton의 두 가지 핵심 개념을 소개한다.[^105]

(1) Environment: 서비스 배포를 위한 ‘배경’ 역할의 공유 자원[^106]

발표자는 Environment를 “개발자들이 만들어 올리는 실제 서비스가 배포될 수 있는 배경 역할을 하는 고유 자원”이라고 설명한다.[^107] 여기에 포함될 수 있는 예시는 다음처럼 제시된다.[^108]

• VPC[^109]
• ECS 클러스터 같은 공유 기반 리소스[^110]

즉 Environment는 개별 서비스 이전에 깔리는 공통 기반(네트워크/클러스터 등)으로 제시된다.[^111]

(2) Service: 환경 위에서 실행되는 실제 워크로드 묶음[^112]

Service는 환경 위에서 실행되는 실제 워크로드이며, 개발자가 개발해서 올리는 대상이라고 한다.[^113] 예시로 다음을 든다.[^114]

• 서버리스/컨테이너 기반 웹 서비스[^115]
• Lambda 기반 데이터 처리 애플리케이션 등[^116]

정리하면 Environment는 “배포의 토대”, Service는 “올릴 애플리케이션”이라는 2층 구조로 설명된다.[^117]

3.9 템플릿(IaC)로 표준을 정의: CloudFormation, 파라미터/스키마, 그리고 패키징[^118]

Environment와 Service를 정리(정의)하기 위해 인프라 관리자가 템플릿을 준비해야 한다고 말한다.[^119] 이 템플릿은 “현 시점 기준 CloudFormation을 사용해 정의”한다고 언급한다.[^120] 또한 향후 다른 IaC들과의 통합(확장)을 진행 중이라고 덧붙인다.[^121]

발표자는 IaC 템플릿으로 단순히 리소스만 만드는 것이 아니라, 다음 요소들을 “스펙업(묶어서)” 개발자에게 제공한다고 말한다.[^122]

• 컨테이너/서버리스 리소스[^123]
• CI/CD 파이프라인[^124]
• (트래킹/모니터링) 모니터링 정책 및 운영 도구[^125]

운영자/개발자 역할 분담을 개념으로 재정리[^126]

발표자는 역할을 이렇게 정리한다.[^127]

• Proton과 관련된 모든 자원은 인프라 관리자가 정한다.[^128]
• 특히 “공유 자원 배경지 역할”을 하는 Environment는 인프라 관리자 쪽에서 생성해 준다.[^129]
• 개발자는 Service 템플릿을 사용해 개발에 필요한 자원을 원클릭으로 생성한다.[^130]
• 결과로 생성된 실제 리소스(인스턴스/자원)는 함께 모니터링/관리한다.[^131]

이 설명을 통해 Proton은 “운영 표준은 운영자가 템플릿으로 고정”하고 “개발자는 선택/입력만으로 빠르게 프로비저닝”하는 협업 구조를 만든다는 점을 강조한다.[^132]

3.10 예시 시나리오: 3개 마이크로서비스 × 2가지 서비스 패턴 × 스테이징/프로덕션 환경[^133]

발표자는 “실제 환경에서 적용되면 어떤 모습인지”를 예시로 든다.[^134] 가정은 다음과 같다.[^135]

• 서비스 패턴 2가지가 있다(예: Fargate 기반 웹서비스, Lambda 기반 웹서비스 등으로 제시)[^136]
• 마이크로서비스 3개를 배포하려고 한다.[^137]
• 배포 환경은 스테이징과 프로덕션 두 가지다.[^138]

환경 템플릿 적용: 스테이징 vs 프로덕션의 접근성 차등[^139]

• 스테이징 환경: 외부에서 접근할 수 없게(사설/내부 접근 중심) 구성, 개발자는 접근 가능[^140]
• 프로덕션 환경: 인터넷 트래픽을 받을 수 있도록 설정[^141]
• 프로덕션은 “모든 개발자가 접근할 수는 없고 특정(허용된) 인원만 접근”하도록 구성하겠다고 말한다.[^142]

이 차등을 Environment 템플릿으로 배포해 표준화한다는 흐름이다.[^143]

서비스 인스턴스 생성: 템플릿 + CI/CD 파이프라인까지 같이 생성[^144]

환경과 템플릿 준비가 되면, 개발자는 각 환경에 대해 서비스를 띄우기 위해 서비스 인스턴스를 생성한다.[^145] 이 과정에서 “Proton까지 포함해 CI/CD 파이프라인까지 같이 생성해서 사용”한다고 설명한다.[^146]

여기서 강조하는 포인트는 다음이다.[^147]

• 3개 마이크로서비스가 있다면, 개발자는 원하는 것을 클릭해 똑같이 클라우드 자원과 CI/CD 파이프라인을 반복 생성할 수 있다.[^148]
• 지금은 3개지만 다음 주에 4번째, 5번째 마이크로서비스를 만들기로 결정해도, “어떤 서비스 스펙(템플릿)을 사용할지”만 정해서 바로 시작할 수 있다고 말한다.[^149]

즉, 신규 마이크로서비스 증가에 대해 “표준 방식으로 복제/확장”이 가능해진다는 주장이다.[^150]

3.11 운영자(인프라 관리자)가 해야 할 일 4가지: 표준 정의→등록→버전관리→환경 배포[^151]

발표자는 이제 “운영자 입장에서 무엇을 해야 하는가”를 구체화한다.[^152] 운영자 관점에서의 핵심은 “인프라 표준 모델이 무엇인지 템플릿으로 정의”하는 것이다.[^153]

발표에서 운영자가 수행해야 한다고 정리한 작업은 총 네 가지로 제시된다.[^154]

1. 조직이 원하는 인프라 표준/모델을 템플릿으로 정의[^155]
2. 정의한 템플릿을 Proton에서 사용할 수 있도록 등록(카탈로그화)[^156]
3. 템플릿을 계속 버전관리(소프트웨어 버전/구성 변경을 버전으로 관리)[^157]
4. 개발자가 서비스 배포할 수 있는 “배경”인 Environment(공유 환경) 배포[^158]

이 네 가지를 통해 운영자는 환경 표준을 만들고 지속적으로 업데이트하는 역할에 “더 집중”할 수 있다고 말한다.[^159]

(중요 포인트로 강조) 템플릿 관리와 버전관리[^160]

발표자는 이 중 “가장 핵심적으로 해야 할 것 중 하나는 템플릿 관리”라고 다시 강조한다.[^161] 프리뷰 시점에는 콘솔에서 계정별 등록을 하게 되어 있고, 프리뷰 종료 후 GA 시점에는 멀티 계정 관점의 확장이 가능해질 것처럼 언급한다.[^162]

3.12 템플릿 작성 디테일: 파라미터 처리와 스키마 정의, 참조 파일 지정[^163]

발표자는 “템플릿을 실제로 어떻게 작성하는가”로 더 깊게 들어간다.[^164] 권장 방식은 “극한(최대한)으로 확장성과 재사용성을 갖도록” 템플릿을 정리하는 것이라고 말한다.[^165]

이를 위해 파라미터 포함을 강조한다.[^166] 논리는 다음과 같다.[^167]

• 인프라 관리자가 모든 자원을 고정해 템플릿을 제공하되[^168]
• “템플릿 재사용성을 최대한 확보”하기 위해 일부는 변수/파라미터 처리[^169]
• 개발자가 입력하는 값을 받아 템플릿에 넣는 구조라는 뜻이라고 설명한다.[^170]

또한 CI/CD 파이프라인을 정의하는 템플릿도 별도로 작성해야 하며, 파라미터에 어떤 값이 어떤 형식으로 들어와야 하는지 정리하기 위해 **스키마(schema)**를 잡아야 한다고 말한다.[^171] 그리고 추가로 다른 파일들을 참조해야 하는 경우, 참조 누락이 없도록 지정해야 한다는 식의 체크 포인트도 언급한다.[^172]

3.13 CloudFormation 예시: Route 53 레코드(서브도메인) 변수를 파라미터+스키마로 받기[^173]

발표자는 CloudFormation 템플릿 예시를 보여주며(말로 설명), 서비스별로 필요한 DNS 레코드를 동적으로 만드는 시나리오를 든다.[^174]

예시는 “Store Front 웹서비스를 띄우려면 외부 트래픽을 받아 테스트할 도메인이 필요”하다는 문제에서 출발한다.[^175] 그런데 스테이징에서 테스트할 때는 프로덕션과 다른 도메인 네임을 써야 한다고 말한다.[^176]

그래서 “하나의 템플릿만 작성해 바꿔 쓰기 위해 변수 처리”를 했고, 이를 위해 서브도메인(subdomain) 같은 값을 외부 입력(파라미터)으로 받게 한다는 설명이다.[^177] 배포 시점에 입력 값이 들어오고, 그 값으로 “완성된 템플릿을 만든다”는 식으로 표현한다.[^178]

이때 입력 값의 제약을 스키마로 정의한다는 점을 예시로 보여준다.[^179] 설명 중에는 “서브 도메인 값이 string” 등의 형식 정의를 언급한다.[^180]

[!TIP] 템플릿 재사용성 확보 포인트
환경(스테이징/프로덕션)마다 달라지는 값(예: 도메인/서브도메인)을 파라미터로 분리하고, 입력값 제약/형식을 스키마로 고정해 운영 표준을 유지한다는 접근을 제시한다.[^181]

3.14 템플릿을 콘솔에 등록할 때 필요한 정보: 이름/설명/생성 자원 안내[^182]

템플릿을 만들면 끝이 아니라, 개발자가 콘솔에서 선택해 쓸 수 있도록 등록해야 한다고 말한다.[^183] 등록 과정에서 템플릿 생성에 필요한 옵션들을 지정하고, 템플릿의 이름이 무엇인지, 어떤 자원을 생성하는지 등 **설명(Description)**을 추가로 적어야 개발자가 “내가 뭘 생성하는구나”를 알고 사용할 수 있다고 설명한다.[^184]

즉, 템플릿은 기술적 IaC뿐 아니라 개발자 경험(카탈로그에서 이해 가능한 문서화)을 포함해야 한다는 메시지다.[^185]

또한 고객이 쉽게 시작할 수 있도록 샘플 템플릿을 준비해 두었고, 뒤(마무리 파트)에서 안내하겠다고 연결한다.[^186]

3.15 버전관리 전략: 마이너 버전 vs 메이저 버전, 그리고 예시(EFS 옵션 추가)[^187]

발표자는 템플릿 “버전관리”가 필요하다고 했던 말을 다시 꺼내며, 어떤 변경이 왜 버전업이 되는지 설명한다.[^188]

버전업이 필요한 변경의 예시(발표에서 든 사례)[^189]

• Lambda 런타임을 예: Python 3.7에서 3.8로 올리는 등 소프트웨어 버전 업데이트[^190]
• 보안 정책 변경으로 기존 자원 외에 예: IAM Role 같은 리소스를 추가 생성해야 하는 경우[^191]

이런 변화가 생기면 인프라 팀은 모든 개발자가 새 표준으로 마이그레이션할 수 있도록 “버전”을 제공하고, 콘솔에서 확인/경고 등을 통해 관리한다고 설명 흐름을 만든다.[^192]

Proton 버전의 종류: 마이너 vs 메이저[^193]

발표자는 Proton의 버전에 마이너 버전과 메이저 버전이 있다고 말한다.[^194]

• 마이너 버전: (표현상) 생성되는 리소스/오퍼레이션 변화 등을 수반하는 경우가 마이너 버전 업그레이드라고 설명한다.[^195]
• 메이저 버전: 사용자 인풋(입력)이 변경/추가되는 경우, 대표적으로 스키마 변경이 생기면 메이저 버전 업이라고 설명한다.[^196]

메이저 버전업 예시: Fargate 템플릿에 EFS 옵션을 추가하고 싶다[^197]

발표자는 이해를 돕기 위해 다음 예시를 든다.[^198]

• 기존 Fargate 관리형(?) 템플릿에 EFS를 새 옵션으로 추가하고 싶다[^199]
• 과거에는 “그냥 과거에는 쓰고 넘어갔을(포기했을) 텐데”, 이제는 옵션으로 제공할 수 있게 된다[^200]
• 개발자에게 “EFS를 쓰고 싶은지” 입력을 받고 쉽게 선택하게 할 수 있다[^201]
• 그러면 템플릿에 파라미터가 하나 추가되고, 스키마가 변경되므로 이 경우는 메이저 버전업이라고 정리한다.[^202]

이 파트의 요지는 “옵션 추가로 개발자 선택지를 늘리는 변경은 입력 스키마를 건드리므로 메이저 버전업”이라는 기준을 제시하는 것이다.[^203]

3.16 콘솔에서 버전 상태를 확인하고 컴플라이언스를 점검: 최신/구버전/경고[^204]

발표자는 콘솔 화면 흐름을 말로 설명하며, 버전 퍼블리시 후 새로운 버전을 생성할 수 있다고 말한다.[^205] 그리고 서비스 리스트로 돌아가면 개발자가 생성한 서비스들이 어떤 템플릿 버전을 쓰는지 보이고, 권장된 최신 버전을 쓰는 인스턴스에는 문제가 표시되지 않지만, 버전 차이가(특히 메이저 차이) 나는 경우 “경고성”으로 표시되는 것을 확인할 수 있다고 설명한다.[^206]

이를 통해 운영자는 환경에 배포된 자원들이 어떤 상태이며, 어떤 버전을 쓰고 있는지, 관리대상에서 무엇을 조치해야 하는지 “한눈에 확인”할 수 있게 된다고 말한다.[^207]

[!IMPORTANT] 운영 통제의 구현 방식
“표준 템플릿 버전”을 중심으로, 각 팀이 만든 서비스가 최신 표준을 따르는지/구버전인지가 표면화되고(경고), 운영이 이를 근거로 조치할 수 있다는 접근을 설명한다.[^208]

3.17 마지막 운영자 작업: Environment(공유 기반) 만들기 예시(VPC, ECS 클러스터 등)[^209]

운영자가 해야 할 마지막 작업은 “환경을 만드는 것”이라고 다시 짚는다.[^210] 앞서 설명한 것처럼 VPC 같은 것들이 Environment에 포함된다고 했고, 예시로 파이프라인의 스테이지, VPC, ECS 클러스터 템플릿 자원 등을 생성해주는 IAM Role 같은 것이 Environment로 생성될 수 있다고 설명한다.[^211]

이 Environment 생성까지 완료되면, 운영자가 해야 하는 작업이 “모두 완료”된 것이라고 정리한다.[^212]

3.18 개발자는 어떻게 쓰나: 카탈로그에서 선택→파라미터 입력→서비스 생성→상태/자원 확인[^213]

이제 개발자 관점으로 전환한다.[^214] 결론적으로 개발자는 “애플리케이션 코드 작성에 더 집중”하게 된다고 말한다.[^215]

개발자는 Proton에서 템플릿 기반 셀프서비스로 필요한 서비스를 클릭해 배포하고, 생성된 클라우드 자원들을 콘솔에서 확인하는 식으로 일부 인프라 관련 작업을 셀프서비스로 할 수 있다고 설명한다.[^216]

개발자 서비스 생성 흐름(콘솔 상)[^217]

1. 인프라 관리자가 템플릿을 잘 준비해두면, 개발자가 콘솔에 들어갔을 때 카탈로그 형식으로 템플릿을 볼 수 있다.[^218]
2. 개발자는 작업할 애플리케이션에 맞는 템플릿 타일을 선택한다(예: Fargate 선택).[^219]
3. 서비스 생성에 필요한 파라미터 값을 입력한다.[^220] 이 입력 항목은 운영자가 정의한 스키마에 따라 제약되며, “반드시 입력해야 하는 것 정도만” 입력하면 된다는 식으로 설명한다.[^221]
4. 생성 후 서비스 리스트에서 “최신 버전 템플릿으로 배포됐는지”, “헬스 상태는 정상인지” 등을 하나의 뷰로 확인할 수 있다고 말한다.[^222]

발표자는 이 흐름이 의미하는 바를 “인프라나 정책 때문에 시간을 소모하지 않고도 안전하고 빠르게 애플리케이션 개발을 할 수 있게 된다”로 정리한다.[^223]

3.19 서비스 상세에서 종속 리소스까지 한 번에: 예전엔 여러 콘솔/계정/요청이 필요했다[^224]

개발자가 서비스 리스트에서 특정 서비스를 클릭하면 서비스 상세 페이지로 들어가고, 각 인스턴스가 정상적으로 돌아가는지 등을 조회할 수 있다고 말한다.[^225]

발표자는 “원래 같았으면” 개발자가 인프라 상태를 확인하려고 여러 콘솔(예: 클러스터 들어가고, Lambda 들어가고 등)로 이동해야 했고, 어떤 계정 접근 권한이 없으면 인프라팀에 요청해 작업을 받아야 했다고 과거의 번거로움을 묘사한다.[^226]

그런데 Proton에서는 콘솔 화면에서 “종속 리소스 생성도 모두”와 “자원에 대한 정보”를 볼 수 있게 된다고 설명한다.[^227] 그리고 이런 관점(한 화면에서 상태/리소스 확인)은 운영자와 개발자 모두에게 해당된다고 말한다.[^228]

또한 원래 분리돼 운영·개발팀이 따로 하던 모니터링을 Proton을 통해 “중앙에서 같이 모니터링할 수 있는 기능”까지 추가됐다고 설명한다.[^229]

---

3.20 시작하기 정보: 프리뷰/리전/비용/샘플 템플릿/지원 채널[^230]

마무리로 “Proton을 써보고 싶은 고객에게 필요한 정보”를 안내한다.[^231]

프리뷰 상태와 리전[^232]

발표 시점 기준 Proton은 프리뷰라고 말한다.[^233] 별도 사전 신청 없이, 지원되는 5개 리전에서 콘솔 접속 후 “Proton”을 검색하면 바로 테스트를 시작할 수 있다고 안내한다.[^234] 언급된 리전은 다음과 같다.[^235]

• (미국) 오하이오[^236]
• (유럽) 프랑크푸르트[^237]
• (아시아) 일본 도쿄[^238]
• (기타) 더블린 등 포함해 총 5개라고 말한다.[^239]

또한 2021년 중 글로벌하게 정식 출시(확장) 예정이라고 언급한다.[^240]

비용 모델[^241]

Proton 자체를 사용하기 위한 기본 비용/추가 청구는 없다고 말한다.[^242] 다만 Proton을 통해 배포되는 컨테이너/Lambda 등 실제 리소스에 대해서는 해당 AWS 서비스의 비용이 청구되는 구조라고 설명한다.[^243] (즉, “관리 계층은 무료, underlying 리소스는 과금” 모델로 안내)[^244]

샘플 템플릿과 가이드 제공[^245]

최초 시작 절차 가이드와, 서비스 팀이 오랜 시간 쌓아온 베스트 프랙티스를 담은 샘플 템플릿이 오픈되어 있다고 말한다.[^246] Proton 옵션에서 바로 사용 가능한 샘플을 살펴보길 권하며, 조직에 어떻게 적용할지 같이 고민해보자고 제안한다.[^247]

현재 샘플은 컨테이너 서비스 중심으로 구성돼 있고, 향후 고객 피드백 기반으로 확장 예정이라고 덧붙인다.[^248]

도움 요청/피드백 요청[^249]

PoC/테스트 중 도움이 필요하면 세션의 Q&A 등을 통해 의사를 밝혀 달라고 안내하며, 적시에 지원하겠다고 말한다.[^250] 또한 더 좋은 세션을 만들기 위해 의견이 필요하니 피드백을 남겨 달라고 요청하며 발표를 마무리한다.[^251]

---

4. 핵심 통찰[^252]

1. 엔터프라이즈 DevOps의 본질적 갈등은 **표준화(통제/보안/컴플라이언스)**와 **속도(자율/생산성)**가 같은 문제 공간에서 충돌한다는 점으로 제시된다.[^253] Proton은 이 갈등을 “운영팀이 템플릿으로 표준을 만들고, 개발팀은 셀프서비스로 소비”하는 방식으로 정리한다.[^254]
2. 마이크로서비스 전환은 애플리케이션 분해만이 아니라 컴퓨팅/네트워크/CI/CD/모니터링까지 함께 폭증시키며, 이 운영 요소를 통제하지 못하면 조직은 “정책 준수에 자신 있게 말할 수 없는 상태”로 간다는 경고가 포함된다.[^255]
3. 고객의 전형적 선택지(중앙배포, PaaS 자율, 인하우스 플랫폼)는 각각 뚜렷한 트레이드오프를 가지며, 특히 인하우스 플랫폼은 “비즈니스 성과와 직접 연관이 약한 운영비”가 될 수 있다는 관점을 제시한다.[^256]
4. Proton의 설계 핵은 **Environment(공유 기반)**와 **Service(워크로드)**를 분리하고, 이를 IaC 템플릿으로 표준화해 재사용성을 확보하는 것이다.[^257]
5. 운영 거버넌스는 “승인 프로세스”만으로는 확장에 취약하며, 템플릿 버전관리와 콘솔에서의 버전 준수 가시화(경고) 같은 체계가 있어야 대규모 마이크로서비스 환경에서 통제가 가능하다는 메시지다.[^258]

• 실행 시사점(발표 내용에 근거한 적용 행동)[^259]
  • 운영팀: 먼저 스테이징/프로덕션 등 Environment 템플릿을 정책(외부접근/권한) 차등으로 설계하고 배포한다.[^260]
  • 운영팀: Service 템플릿에 CI/CD와 모니터링 도구까지 포함해 “개발자가 클릭하면 운영 가능한 상태”가 되도록 패키징한다.[^261]
  • 운영팀: 변경 유형에 따라 마이너/메이저 버전 규칙을 세우고(특히 입력 스키마 변경은 메이저), 콘솔 경고를 통해 마이그레이션 대상을 관리한다.[^262]
  • 개발팀: 카탈로그에서 표준 템플릿을 선택하고 필요한 파라미터만 입력해 빠르게 반복 생성하며, 서비스 상세에서 종속 리소스/상태를 확인하는 운영 습관을 갖는다.[^263]

---

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

• AWS Proton: 컨테이너/서버리스 애플리케이션을 위한 완전 관리형 애플리케이션 배포 서비스로, 운영자가 템플릿으로 표준을 제공하고 개발자가 셀프서비스로 배포·운영할 수 있게 하는 서비스로 설명된다.[^265]
• Environment(환경): 서비스가 배포될 “배경 역할”의 공유 기반 리소스 묶음. 예: VPC, ECS 클러스터 등이 포함될 수 있다고 발표에서 언급된다.[^266]
• Service(서비스): Environment 위에서 실행되는 실제 워크로드 묶음. 예: 컨테이너/서버리스 웹서비스, Lambda 기반 데이터 처리 앱 등.[^267]
• 템플릿(Template): 인프라 관리자가 IaC로 정의해 Proton에 등록하는 표준 배포 청사진. 리소스뿐 아니라 CI/CD, 모니터링 정책/도구까지 포함 가능하다고 설명된다.[^268]
• 스키마(Schema): 개발자가 입력하는 파라미터 값의 형식/제약을 정의해 표준을 유지하기 위한 구조로 설명된다.[^269]
• 마이너 버전 / 메이저 버전: 템플릿 버전 관리 체계. 발표에서는 “입력(스키마) 변경/추가가 수반되면 메이저”라고 예시(EFS 옵션 추가)로 설명한다.[^270]

---

---

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

• 제목: DevOps in Enterprise: 엔터프라이즈 CI/CD 적용 방안 - 염지원[^272]
• 출처/채널: Amazon Web Services Korea[^273]
• 길이: 29분 39초[^274]
• 링크: https://www.youtube.com/watch?v=UuQ_RATSbj4[^275]

---

[^1]: @[00:42] “aws … 사용해서 어떻게 엔터… 환경에 … 운영 방식을 적용할 수 있을지”, @[00:52] “배경… 해결하고자 하는 문제… 어떻게 해결… 어떤 방식으로 … 사용…” [^2]: @[01:21] “더 빠른 신규 서비스 출시…”, @[02:18] “많은 자원… 잘 관리”, @[03:42] “표준화… 개발 속도… 충돌” [^3]: @[07:42] “이런 문제… aws 포토(프로톤)”, @[08:16] “템플릿을 정의… 개발자… 클릭하고 배포”, @[08:32] “CI/CD… 모니터링… 포함” [^4]: @[05:17] “세 가지 패턴”, @[05:33] “표준화 그리고 속도…” [^5]: @[05:41] 중앙 배포, @[06:28] PaaS 자율/통제 약화, @[07:00] 인하우스 플랫폼 부담, @[07:42] 프로톤으로 해결 [^6]: @[10:53] “실제로 사용…”, @[15:11] “인프라 관리자…”, @[24:22] “개발자…” [^7]: @[11:03] Environment, @[11:20] Service, @[15:22] 템플릿 등록/버전관리/환경 배포, @[25:06] 개발자 카탈로그/입력/생성 [^8]: @[00:42]~@[01:09] 세션 구성, @[01:17] 이후 문제 전개 [^9]: @[03:12] 네트워크/보안 정책 준수, @[04:10] 개발 속도/자율성, @[07:52] 균형 제공 [^10]: @[00:52] 배경/문제/해결/사용 방식/필수 정보, @[20:10] 샘플 템플릿, @[27:35] 프리뷰/리전/비용 [^11]: @[03:12] 운영팀 정책 준수 요구, @[04:10] 개발팀 속도 요구 [^12]: @[08:16] 템플릿 정의→개발자 클릭 배포 [^13]: @[11:03] Environment, @[11:20] Service, @[12:01] CI/CD/모니터링까지 묶음 제공 [^14]: @[23:12] 버전 정보/경고, @[26:06] 최신버전/헬스 확인 [^15]: @[00:52]~@[29:33] 전체 전개 [^16]: @[00:05] 인사, @[00:21] 진행 안내 [^17]: @[00:26] Q&A/질문 창, @[00:33] 실시간 답변 [^18]: @[00:42] 엔터프라이즈 적용, @[00:52] 배경/문제/해결/사용 [^19]: @[00:52] “배경…” [^20]: @[00:52] “해결하고자 하는 문제…” [^21]: @[01:02] “사용자 관점…” [^22]: @[01:09] “필연 정보…” [^23]: @[01:17] “마이크로서비스 시대” [^24]: @[01:17] “이제는 … 마이크로서비스…” [^25]: @[01:21] “더 빠른 신규 서비스 출시… 클라우드… 기반 마련” [^26]: @[01:35] “하나의 커다란 어플리케이션… 쪼개서” [^27]: @[01:48] 쇼핑몰 예시 도입 [^28]: @[01:48] “스토어 프론트…” [^29]: @[01:48] “페이먼트(결제)…” [^30]: @[01:48] “주문 서비스…” [^31]: @[01:48] “각각… 데이터베이스…” [^32]: @[02:05] “전체 서비스 영향을 최소화… 빠르게…” [^33]: @[02:18] “많은 자원… 관리” [^34]: @[02:26] “컨테이너와 서버리스… 더 복잡” [^35]: @[02:34] 이후 나열 [^36]: @[02:34] “간단한… 올린다고…” [^37]: @[02:40] “서버리스…” [^38]: @[02:40]~@[02:47] “컨테이너…” [^39]: @[02:47]~@[02:55] “외부 접근… 결정” [^40]: @[02:55]~@[03:01] “CI/CD 파이프라인…” [^41]: @[03:01]~@[03:08] “모니터링…” [^42]: @[03:08] “조직 의미”로 전환 [^43]: @[03:08]~@[04:37] 운영 vs 개발 대비 [^44]: @[03:08] “의미”, @[03:12] 운영 요구 [^45]: @[03:12] 운영 관점 설명 [^46]: @[03:12]~@[03:25] 정책 준수/운영 확인 [^47]: @[03:25] 운영이 확인 원함 [^48]: @[03:25]~@[03:42] 개발 관점 [^49]: @[03:25] “쉽지” [^50]: @[03:34]~@[03:42] “수십…수백” [^51]: @[03:42]~@[03:48] “표준화… 충돌” [^52]: @[03:51]~@[04:10] 운영팀 역할/검증 [^53]: @[04:10]~@[04:21] “기다리고” [^54]: @[04:25]~@[04:37] “인프라 탭… 집중 시간 줄어” [^55]: @[04:25]~@[04:37] 동일 [^56]: @[04:37]~@[05:09] 아마존 경험 [^57]: @[04:37] “아마존닷컴…” [^58]: @[04:42]~@[04:59] “수백개… 컨트롤 불가” [^59]: @[04:59]~@[05:09] “정책 준수… 자신있게 말하기 어려운” [^60]: @[05:09]~@[05:17] “많은 고객들…” [^61]: @[05:17]~@[07:10] 3 패턴 [^62]: @[05:17] “세 가지 패턴” [^63]: @[05:27]~@[05:33] 표준/속도 관점 [^64]: @[05:33]~@[06:14] 중앙 배포 [^65]: @[05:41]~@[06:04] 티켓/요청/전달 [^66]: @[06:04] “컨트롤…” [^67]: @[06:14]~@[06:23] “병목” [^68]: @[06:23]~@[06:50] PaaS [^69]: @[06:28]~@[06:43] “직접… 컨트롤 어려워” [^70]: @[06:43]~@[06:50] “속도… 대신 제어 포기” [^71]: @[06:50]~@[07:10] 인하우스 [^72]: @[06:50]~@[07:00] “플랫폼…” [^73]: @[07:00]~@[07:10] “별도 개발/관리 부담” [^74]: @[07:13]~@[07:30] 비즈니스 성과 연관 낮음 [^75]: @[07:30]~@[07:37] “운영 위해 비용” [^76]: @[07:21]~@[07:37] 해당 논지 [^77]: @[07:37]~@[08:10] 프로톤 소개 [^78]: @[07:42] “aws 포토(프로톤)” [^79]: @[07:42]~@[07:52] “균형… 관리형” [^80]: @[07:52]~@[08:00] “운영 부담… 컴플라이언스…” [^81]: @[07:52] “최소한의 운영 부담” [^82]: @[07:52] “컴플라이언스” [^83]: @[07:52] “개발…” [^84]: @[08:00]~@[08:10] “완전 관리형… 배포 서비스” [^85]: @[08:10]~@[08:51] 흐름 설명 [^86]: @[08:16] “템플릿 정의… 발행” [^87]: @[08:16]~@[08:26] “클릭하고 배포” [^88]: @[08:32]~@[08:43] “CI/CD… 모니터링… 포함” [^89]: @[08:43]~@[08:51] “모니터링… 구형 확인” [^90]: @[08:43]~@[08:59] 동일 [^91]: @[09:08]~@[10:35] 핵심 기능/장점 [^92]: @[09:08]~@[09:18] “많은 대화… 핵심기능” [^93]: @[09:18]~@[09:35] 기능 나열 [^94]: @[09:18] “셀프 서비스” [^95]: @[09:24] “원클릭…” [^96]: @[09:24]~@[09:26] “CI/CD… 통합” [^97]: @[09:26]~@[09:35] “서드파티…” [^98]: @[09:41]~@[10:35] 장점 3가지 [^99]: @[09:48]~@[10:03] “신규 기능… 도입” [^100]: @[10:03]~@[10:18] “테스트… 문제 최소화…” [^101]: @[10:18]~@[10:30] 개발 집중 [^102]: @[10:30]~@[10:35] “최적 아키텍처… 집중” [^103]: @[10:30]~@[10:35] 역할 전환 [^104]: @[10:58] “두가지 핵심 개념” [^105]: @[10:53]~@[11:03] 전환 [^106]: @[11:03] Environment 설명 [^107]: @[11:03]~@[11:13] “배경 역할” [^108]: @[11:13]~@[11:19] 예시 [^109]: @[11:13] “vpc” [^110]: @[11:13]~@[11:19] “ecs 클러스터…” [^111]: @[11:03]~@[11:19] 동일 [^112]: @[11:20] Service 설명 [^113]: @[11:20]~@[11:28] “실제 워크로드” [^114]: @[11:28]~@[11:39] 예시 [^115]: @[11:28] “웹 서비스…” [^116]: @[11:28]~@[11:39] “람다 기반…” [^117]: @[11:03]~@[11:39] 대비 [^118]: @[11:39]~@[12:17] 템플릿/IaC [^119]: @[11:39]~@[11:47] “템플릿… 정리” [^120]: @[11:47]~@[11:53] “클라우드포메이션…” [^121]: @[11:53]~@[12:01] “통합…” [^122]: @[12:01]~@[12:17] “파이프라인… 모니터링… 묶어서” [^123]: @[12:01]~@[12:08] “서버리스/컨테이너…” [^124]: @[12:01] “CI/CD” [^125]: @[12:01]~@[12:17] “트랙… 모니터링…” [^126]: @[12:17]~@[13:05] 역할 정리 [^127]: @[12:17] “정리해 보면” [^128]: @[12:22] “모든 자원… 인프라 관리자” [^129]: @[12:29]~@[12:40] “환경… 생성” [^130]: @[12:40]~@[12:49] “원클릭 생성” [^131]: @[12:49]~@[12:56] “자원… 모니터링” [^132]: @[12:56]~@[13:05] “간편…” [^133]: @[13:05]~@[14:45] 예시 시나리오 [^134]: @[13:05] “샘플…” [^135]: @[13:13]~@[13:35] 가정 [^136]: @[13:19]~@[13:30] “파게이트… 람다…” [^137]: @[14:17] “3가지 마이크로 서비스” [^138]: @[13:30]~@[13:35] “스테이징… 포덕” [^139]: @[13:41]~@[13:59] 접근성 차등 [^140]: @[13:41]~@[13:50] 스테이징 [^141]: @[13:50]~@[13:56] 프로덕 트래픽 [^142]: @[13:56]~@[13:59] 접근 제한 [^143]: @[13:59]~@[14:05] 템플릿 배포 [^144]: @[14:05]~@[14:45] 서비스 인스턴스/파이프라인 [^145]: @[14:05]~@[14:17] “서비스 인스턴스” [^146]: @[14:17]~@[14:26] “CI/CD… 같이 생성” [^147]: @[14:26]~@[14:53] 반복 생성/확장 [^148]: @[14:26]~@[14:40] “클라우드 자원과… 파이프라인 생성” [^149]: @[14:40]~@[14:53] “네번째 다섯번째… 바로 시작” [^150]: @[14:40]~@[14:53] 동일 [^151]: @[15:11]~@[15:55] 운영자 4가지 [^152]: @[14:53]~@[15:11] “더 자세히” [^153]: @[15:11]~@[15:22] “표준… 템플릿” [^154]: @[15:22]~@[15:55] “총 네 가지” [^155]: @[15:11]~@[15:22] 정의 [^156]: @[15:22]~@[15:30] 등록 [^157]: @[15:30]~@[15:45] 버전관리 [^158]: @[15:45]~@[15:55] 환경 배포 [^159]: @[15:55]~@[16:01] “지속적… 역할” [^160]: @[20:19]~@[20:26] 버전 이야기 연결 [^161]: @[16:11] “핵심… 템플릿 관리” [^162]: @[16:16]~@[16:22] 프리뷰/향후 언급 [^163]: @[16:38]~@[17:50] 파라미터/스키마/참조 [^164]: @[16:38] “작성…” [^165]: @[16:38]~@[16:44] “확장… 권장” [^166]: @[16:54] “파라미터 포함” [^167]: @[16:54]~@[17:11] 이유 설명 [^168]: @[17:03] “관리자… 정리” [^169]: @[17:03]~@[17:08] “재사용성…” [^170]: @[17:08]~@[17:11] “입력 값 받아…” [^171]: @[17:25]~@[17:31] “스키마” [^172]: @[17:31]~@[17:50] “다른 파일 참조…” [^173]: @[18:04]~@[19:24] DNS 예시 [^174]: @[18:04]~@[18:16] 예시 소개 [^175]: @[18:22]~@[18:28] “도메인 필요” [^176]: @[18:28]~@[18:34] 스테이징은 다른 네임 [^177]: @[18:34]~@[18:42] 변수 처리 [^178]: @[18:50]~@[19:09] 배포 시점 입력/완성 [^179]: @[19:09]~@[19:13] “스키마…” [^180]: @[19:13]~@[19:24] “스트링…” [^181]: @[16:54]~@[19:24] 파라미터+스키마 논지 종합 [^182]: @[19:24]~@[19:58] 등록 설명 [^183]: @[19:24]~@[19:33] “콘솔에서…” [^184]: @[19:39]~@[19:58] “이름… 설명…” [^185]: @[19:48]~@[19:58] 개발자 이해 [^186]: @[20:06]~@[20:10] 샘플 템플릿 예고 [^187]: @[20:19]~@[22:24] 버전관리 상세 [^188]: @[20:19]~@[20:26] “버전…” [^189]: @[20:26]~@[20:52] 변경 예시 [^190]: @[20:31]~@[20:36] “파이썬 3.7→3.8” [^191]: @[20:40]~@[20:46] “보안 정책… IAM…” [^192]: @[20:52]~@[21:00] “마이그레이션…” [^193]: @[21:10]~@[21:31] 마이너/메이저 [^194]: @[21:10] “마이너… 메이저…” [^195]: @[21:15]~@[21:24] 마이너 설명 [^196]: @[21:24]~@[21:31] 메이저/스키마 [^197]: @[21:36]~@[22:13] EFS 예시 [^198]: @[21:36] “예…” [^199]: @[21:36]~@[21:46] “efs… 추가” [^200]: @[21:52]~@[22:00] “옵션으로 제공” [^201]: @[22:00]~@[22:05] “입력 받고” [^202]: @[22:05]~@[22:22] “파라미터 추가… 스키마 변경… 메이저” [^203]: @[22:22]~@[22:24] 정리 [^204]: @[22:31]~@[23:46] 콘솔 버전/경고 [^205]: @[22:33]~@[22:43] “새로운… 생성” [^206]: @[23:00]~@[23:28] 버전 차이/경고 [^207]: @[23:30]~@[23:36] “한눈에 확인” [^208]: @[23:12]~@[23:36] 버전 가시화 [^209]: @[23:46]~@[24:22] 환경 생성 [^210]: @[23:46]~@[23:48] “환경…” [^211]: @[24:00]~@[24:11] “vpc… ecs… iam role…” [^212]: @[24:11]~@[24:22] “작업 완료” [^213]: @[24:22]~@[26:30] 개발자 흐름 [^214]: @[24:22] “개발자…” [^215]: @[24:29]~@[24:36] “코드 작성… 집중” [^216]: @[24:36]~@[24:49] “클릭해서 배포… 콘솔 확인” [^217]: @[25:06]~@[26:13] 생성 흐름 [^218]: @[25:06]~@[25:16] “카탈로그 형식” [^219]: @[25:18]~@[25:29] “파게이트 선택” [^220]: @[25:29]~@[25:38] “입력” [^221]: @[25:38]~@[25:58] “스키마… 반드시 입력…” [^222]: @[26:06]~@[26:19] “최신버전… 헬스…” [^223]: @[26:19]~@[26:30] “시간 소모 없이…” [^224]: @[26:30]~@[27:21] 상세/종속/모니터링 [^225]: @[26:30]~@[26:41] “조회” [^226]: @[26:41]~@[26:57] “원래… 콘솔… 요청” [^227]: @[26:57]~@[27:01] “자원… 정보” [^228]: @[27:01]~@[27:10] “운영자… 개발자…” [^229]: @[27:11]~@[27:21] “중앙… 모니터링” [^230]: @[27:25]~@[29:05] 시작 정보 [^231]: @[27:25]~@[27:35] “필요한 정보” [^232]: @[27:35]~@[28:06] 프리뷰/리전/출시 [^233]: @[27:35] “프리뷰” [^234]: @[27:40]~@[27:55] “사전 신청… 콘솔… 검색…” [^235]: @[27:45]~@[27:51] 5개 리전 언급 [^236]: @[27:45] “오하이오” [^237]: @[27:45] “프랑크푸르트” [^238]: @[27:51] “일본 도쿄” [^239]: @[27:51] “더블린… 5개” [^240]: @[28:00]~@[28:06] “2021… 글로벌…” [^241]: @[28:06]~@[28:19] 비용 [^242]: @[28:06]~@[28:11] “기본 비용… 없다” [^243]: @[28:11]~@[28:19] “배포되는 자원 비용” [^244]: @[28:06]~@[28:19] 동일 [^245]: @[28:30]~@[28:59] 샘플/확장 [^246]: @[28:30]~@[28:42] “가이드… 샘플 템플릿” [^247]: @[28:42]~@[28:55] “권해… 고민” [^248]: @[28:55]~@[28:59] “피드백… 확장” [^249]: @[29:05]~@[29:33] 지원/피드백 [^250]: @[29:05]~@[29:20] “도움… Q&A… 지원” [^251]: @[29:20]~@[29:33] “의견…” [^252]: @[01:17]~@[27:21] 전체 논지 종합 [^253]: @[03:42] “충돌”, @[05:33] 표준/속도 [^254]: @[08:16] 템플릿 기반, @[24:36] 개발자 셀프서비스 [^255]: @[02:34]~@[03:08] 운영 요소 증가, @[04:59] 정책 준수 자신감 저하 [^256]: @[05:41]~@[07:37] 3패턴 및 비용 논지 [^257]: @[11:03] Environment, @[11:20] Service, @[11:47] IaC [^258]: @[20:19]~@[23:36] 버전/경고/가시화 [^259]: @[13:30]~@[13:59] 환경 차등, @[12:01] 파이프라인/모니터링 포함, @[21:24] 스키마 변경=메이저 [^260]: @[13:41]~@[13:59] 스테이징/프로덕션 접근 차등 [^261]: @[12:01]~@[12:17] “파이프라인… 모니터링…” [^262]: @[21:24]~@[22:22] 메이저/마이너, @[23:12] 경고 [^263]: @[25:06]~@[26:19] 셀프서비스/상태 확인 [^264]: @[07:42]~@[22:22] 용어 등장 구간 [^265]: @[08:00]~@[08:10] “완전 관리형…”, @[07:42] 균형 [^266]: @[11:03]~@[11:19] Environment 정의/예시 [^267]: @[11:20]~@[11:39] Service 정의/예시 [^268]: @[12:01]~@[12:17] 템플릿에 포함 요소 [^269]: @[17:25]~@[17:31] “스키마”, @[19:09]~@[19:24] 형식 정의 [^270]: @[21:10]~@[22:22] 버전 체계 및 EFS 예시 [^271]: 사용자 제공 메타데이터(제목/채널/길이/링크) [^272]: 사용자 입력 제목 [^273]: 사용자 입력 채널 [^274]: 사용자 입력 길이 [^275]: 사용자 입력 링크