제품 검증, 출시 전략 및 엔드투엔드 AI 워크플로우

이득:

위험을 줄이는 릴리스 전략(청록색, 카나리아, 기능 플래그) 및 제품 검증 규율(상태 확인, 연기 테스트, 골든 신호 모니터링) 이해
배포 전 명확한 롤백 계획을 준비하고 배포 후 중요한 비즈니스 경로를 확인하는 습관을 구현하는 능력
모듈 전반에 걸쳐 학습된 모든 부분을 엔드투엔드 AI 지원 워크플로우에 결합하고 모든 단계에서 'AI가 생산하고, 인간이 검증하고 보증한다'는 원칙을 적용하는 능력

이 전체 모듈은 프로덕션(실제 고객이 사용하는 라이브 환경)에 대한 코드 및 인프라의 안전한 전달이라는 한 지점을 향해 흘러갔습니다. 이제 우리는 체인에서 가장 중요하고 스트레스가 많은 링크에 있습니다. 변경 사항을 적용하고 실제로 작동하는지 확인하는 것입니다. 여기서 실수는 추상적인 것이 아닙니다. 이는 고객, 수익 및 평판에 직접적인 영향을 미칩니다. 그렇기 때문에 성숙한 팀은 "희망"이 아닌 제어된 릴리스 전략과 체계적인 검증을 통해 프로덕션에 착수합니다.

이 마지막 단원에서는 두 가지를 결합합니다. (1) 위험을 줄이는 릴리스 방법(카나리아, 청록색, 기능 플래그)과 제품 검증 규율; (2) CI/CD, IaC, 컨테이너, 모니터링, 인시던트, 비용, 스크립트, 보안 등 모듈 전체에서 배운 모든 부분이 단일 AI 기반 엔드 투 엔드 워크플로로 통합되는 방식입니다. 마지막으로 초기 인용문을 반복해 보겠습니다. AI는 모든 단계에서 초안을 생성하고 가속화합니다. 하지만 "이 라이브를 진행합니다" 버튼을 누르고 결과를 보증하는 사람은 바로 당신입니다.

위험을 줄이는 릴리스 전략

모든 사용자에게 동시에 변경 사항을 적용하는 것은 가장 위험한 방법입니다. 성숙한 방법:

블루-그린 배포: "블루"(라이브)와 "그린"(새 버전)이라는 두 개의 동일한 환경이 유지됩니다. 새 버전을 준비하고 녹색으로 테스트한 후 트래픽이 갑자기 녹색으로 전환됩니다. 문제가 있으면 트래픽이 즉시 파란색으로 돌아갑니다. 빠른 롤백이 가장 큰 장점입니다.
카나리아 배포: 새 버전은 소수의 사용자(예: 5%)에게 처음 출시됩니다. 측정항목이 양호하면 점차적으로 100%까지 늘립니다. 문제는 전체 사용자가 아닌 일부 사용자에게 영향을 미칩니다.
기능 플래그: 새로운 기능이 코드에 입력되지만 플래그에 의해 차단됩니다. 요청 시 특정 사용자에게 공개됩니다. 배포와 "릴리스"에는 차이가 있습니다. 문제가 있는 경우 코드를 롤백하지 않고 플래그가 꺼집니다.

팁: 가장 빠른 안전망은 각 배포 전에 롤백을 준비하는 것입니다. "뭔가 잘못되면 어떻게 60초 안에 이전 버전으로 되돌릴 수 있나요?" 질문에 대한 명확한 대답이 없으면 해당 배포를 수행할 준비가 되지 않은 것입니다.

Prod 검증: 배포가 끝나도 작업은 끝나지 않습니다

배포가 "친환경"으로 보인다고 해서 그것이 작동하고 있다는 의미는 아닙니다. 체계적인 검증:

상태 확인: 서비스가 작동 중입니까, /healthz가 응답합니까?
스모크 테스트: 가장 중요한 몇 가지 사용자 경로(로그인, 결제, 검색)가 실제로 작동합니까? 자동적이고 빠릅니다.
골든 신호 관찰: 배포 후 오류율, 대기 시간, 트래픽이 정상입니까? (6번 장치에는 4개의 신호가 있습니다.)
점진적 확장: Canary 비율을 높이면서 각 단계의 측정항목을 살펴보세요.
관찰 기간: 배포 후 일정 기간(예: 30분) 동안 면밀히 모니터링합니다. 교활한 문제는 즉시 눈에 띄지 않습니다.

주의: AI는 연기 테스트 또는 검증 목록을 생성할 수 있지만 어떤 사용자 경로가 "중요"한지 결정하는 것은 귀하의 임무입니다. AI는 일반 목록을 제공합니다. 가장 많은 수익을 창출하는 경로인 결제 흐름을 테스트해야 한다는 것은 귀하만이 알고 있습니다.

출시 전략 비교

전략

주요 이점

비용/복잡성

가장 적합한

청록색

즉시 롤백

두 가지 환경 = 리소스 2배

빠른 검색이 중요한 경우

카나리아

작은 조각에 대한 영향을 제한합니다.

교통관리 필요

거대한 사용자 기반

기능 플래그

배포와 릴리스를 분리합니다.

플래그 관리 부채

점진적/목표 개방

롤링 업데이트

간단하고 리소스 친화적입니다.

느린 롤백

간단한 서비스

엔드투엔드 AI 기반 워크플로우

이제 전체 모듈을 단일 흐름으로 결합해 보겠습니다. 새로운 마이크로서비스를 게시한다고 가정해 보겠습니다. AI는 각 단계에서 초안을 생성합니다. 각 단계에서 다음을 확인합니다.

코드 및 컨테이너(단원 4): AI는 최적화되고 안전한 Dockerfile을 생성합니다. 비밀이 없음과 크기를 확인합니다.
CI/CD(2단위): AI 테스트-빌드-배포 파이프라인을 작성합니다. 권한 범위를 좁히고 비밀 참조를 확인합니다.
인프라(단원 3): AI Terraform으로 필요한 리소스를 정의합니다. 계획 출력을 읽고 예기치 않은 삭제를 찾지 않습니다.
오케스트레이션(단위 5): AI는 Kubernetes 매니페스트를 생성합니다. 리소스 제한, 프로브 및 RBAC를 확인합니다.
보안(단위 10): AI 스캔 출력의 우선순위를 지정합니다. 악용 가능한 항목을 먼저 잡아야 합니다.
모니터링(6부): AI가 경보 규칙과 대시보드를 생성합니다. 과거 데이터로 임계값을 테스트합니다.
릴리스 및 검증(본 단원): AI 연기 테스트 및 롤백 계획의 개요를 설명합니다. 카나리아를 시작하고 측정항목을 확인한 후 버튼을 누르세요.
사건이 발생하는 경우(단원 7): AI가 가설과 사후 스케치를 생성합니다. 교훈을 확인하고 학습합니다.
비용(단위 8): AI는 새로운 리소스의 낭비를 모니터링합니다. 귀하는 적절한 규모의 결정을 내립니다.

모든 단계에서 공통 규칙은 일정하게 유지됩니다. 즉, AI가 생산하고 가속화하며 인간이 확인하고 보증합니다. 이것이 모듈의 본질입니다.

세 개의 미니 케이스

사례 1 - 카나리아는 재해를 5%로 제한했습니다. 팀에서는 카나리아를 사용하는 5% 사용자에게 새 버전을 제공했습니다. AI가 생성한 대시보드는 이 슬라이스에서 오류율이 8%로 급증한 것을 즉시 보여주었습니다. 팀은 이를 100%까지 늘리지 않고 다시 가져왔습니다. 이 문제는 사용자의 5%에게만 영향을 미쳤으며 이는 몇 분 동안 지속되었습니다. 대규모 배포가 이루어지면 모든 고객이 영향을 받게 됩니다.

사례 2 - 스모크 테스트에서 누락된 경로를 발견했습니다. AI는 연기 테스트 세트를 제공했지만 '결제' 흐름은 없었습니다. 엔지니어는 가장 중요한 수익원이 결제라는 것을 알고 이를 추가했습니다. 배포 후 테스트가 결제 단계에서 바로 중단되었습니다. 타사 키가 만료되었습니다. 확인 결과 몇 분 만에 소리 없이 발생한 수익 손실이 포착되었습니다.

사례 3 - 90초 안에 롤백 준비가 완료되었습니다. 청록색을 설치한 팀은 새 버전을 녹색으로 전환했습니다. 2분 후에는 지연 시간이 두 배로 늘어났습니다. 미리 준비한 롤백으로 90초 만에 교통 상황을 파란색으로 바꿨다. 그들은 부담을 느끼지 않고 침착하게 근본 원인(새 버전에서는 느린 쿼리)을 찾았습니다. 준비된 롤백 경로로 인해 중단이 거의 보이지 않게 되었습니다.

복사 가능한 템플릿 4개

1) 출시 전략 선택:

다음 서비스를 제공하겠습니다: [SERVICE/CONTEXT: 사용자 수, 중단 허용 범위, 인프라]. 청록색, 카나리아, 기능 플래그 중 어느 것을 추천하시나요? 이러한 맥락에서 각각의 장점, 비용 및 롤백 속도를 비교하십시오. 제안을 하되 최종 결정은 내가 내릴 것이라고 말씀해 주십시오.

2) 스모크 테스트/검증 목록:

배포 후 실행할 [SERVICE]에 대한 스모크 테스트 및 확인 목록 초안을 생성합니다. 상태 확인, 가장 중요한 사용자 경로, 몇 분 동안 어떤 측정항목을 모니터링해야 합니까? 가장 중요한 비즈니스 경로를 표시하고 해당 필드를 공백으로 남겨둔다고 가정합니다.

3) 롤백 계획:

저는 [배포 방법]을 사용합니다. 명확한 롤백 계획을 작성해 주십시오. 어떤 명령/단계를 사용하여 이전 버전으로 롤백하는지, 시간이 얼마나 걸리는지, 롤백 자체의 위험은 무엇인지(예: 데이터베이스 마이그레이션은 롤백할 수 없음), 롤백하기 전에 무엇을 확인해야 합니까?

4) 엔드 투 엔드 릴리스 체크리스트:

새로운 [SERVICE] 프로젝트 출시를 위한 엔드투엔드 준비 체크리스트(코드/이미지 보안, 파이프라인, 인프라 계획, 모니터링 및 경보, 보안 스캐닝, 출시 전략, 롤백 및 검증)를 생성합니다. "나는 준비됐나요?"라는 질문으로 각 항목을 확인하세요. 질문으로 바꿔보세요.

약한 프롬프트 / 강한 프롬프트

약함: "이것을 어떻게 프로덕션에 적용할 수 있나요?"

결과: 맥락이 없습니다. AI는 일반적인 배포 단계를 나열하지만 위험 허용 범위, 사용자 규모 및 롤백 요구 사항을 해결하지 않습니다.

Güçlü: "저는 1,000만 명의 사용자를 대상으로 결제 서비스를 제공할 예정입니다. 가동 중지 시간에 대한 허용 범위는 매우 낮습니다. Canary 또는 Blue-Green을 추천하시나요? 배포 후 어떤 중요한 경로를 테스트해야 하고, 어떤 측정항목을 몇 분 동안 모니터링해야 하며, 60초 롤백 계획은 어떻게 해야 할까요? 최종 결정은 제가 내릴 것입니다."

차이점: 두 번째 프롬프트는 규모, 허용 오차 및 롤백 기대치를 제공합니다. 전략 + 검증 + 실행 취소가 필요하며 결정은 인간에게 맡깁니다.

일반적인 실수

롤백 계획 없이 배포합니다. 돌아갈 길이 없다면 모든 배포는 도박입니다.
빅뱅 배포. 한 번에 전체 사용자에게 제공하면 위험이 극대화됩니다.
"녹색 = 작동 중"이라고 가정합니다. 상태 확인을 통과한 서비스가 중요한 경로에서 중단될 수 있습니다.
중요한 비즈니스 경로를 AI로 떠나고 있다고 생각합니다. 결제 등의 방법을 표시해야 합니다.
배포 후 모니터링하지 않습니다. 처음 1분에는 교활한 문제가 나타나지 않습니다. 관찰창이 필요합니다.
데이터베이스 마이그레이션은 되돌릴 수 있다고 생각합니다. 일부 변경 사항은 롤백되지 않습니다. 별도로 계획되어 있습니다.

요약하면

프로덕션으로 가는 것은 체인에서 가장 중요한 링크이며 "희망"이 아니라 제어된 전략으로 수행됩니다. 청록색은 즉각적인 롤백을 제공하고 카나리아 효과를 작은 조각으로 제한하고 기능 플래그 배포를 릴리스와 분리합니다. 배포가 완료되더라도 작업은 끝나지 않습니다. 상태 점검, 연기 테스트, 골든 시그널 모니터링을 통한 체계적인 검증이 필수적입니다. AI는 Dockerfile에서 파이프라인, Terraform에서 경보 규칙, 사후 분석에서 비용 분석에 이르기까지 전체 모듈의 모든 단계에서 초안을 생성하고 가속화합니다. 그러나 각 단계를 확인하고 라이브 버튼을 누르고 결과를 보증하는 유능한 사람이 남아 있습니다. 이것이 엔드투엔드 AI 기반 DevOps의 황금률입니다.

응용과제

게시할 서비스(실제 또는 가상)를 선택하세요. (1) “출시 전략 선택” 템플릿을 통해 상황에 맞는 전략을 선택하고 그 이유를 작성하세요. (2) "스모크 테스트/검증 목록" 템플릿을 사용하여 검증 목록을 생성하고 가장 중요한 비즈니스 경로를 직접 추가하세요. (3) "롤백 계획" 템플릿을 이용하여 60초 롤백 계획을 작성하고, 되돌릴 수 없는 단계가 있는지 확인합니다.

체크리스트

[ ] 내 상황에 맞는 출시 전략(카나리아/청록색/플래그)을 선택했습니다.
[ ] 배포 전에 명확하고 빠른 롤백 계획이 준비되어 있습니다.
[ ] Smoke 테스트에 가장 중요한 비즈니스 경로(예: 결제)를 직접 추가했습니다.
[ ] 배포 후 관찰 창을 통해 골든 시그널을 모니터링합니다.
[ ] 되돌릴 수 없는 단계(데이터베이스 마이그레이션 등)도 계획했습니다.
[ ] 모든 단계에서 AI 설계도를 검증했습니다. 나는 라이브를 하기로 결정했다.

모듈 시험

1. 다음 중 클라우드에서 DevOps 및 AI를 포지셔닝하는 가장 좋은 방법은 무엇입니까?

A) 인공지능은 보조자이자 의사결정 지원 도구입니다. 제품에 영향을 미치는 중요한 결정은 사람에게 책임이 있습니다 ✔
B) 인공 지능은 사람의 승인 없이 제품 배포와 비밀 순환을 마무리할 수 있습니다.
다) 인공지능은 문서 작성에만 유용할 뿐 인프라와는 아무런 관련이 없습니다.
D) 인공지능은 항상 엔지니어보다 더 신뢰할 수 있는 명령을 생성하므로 감사가 필요하지 않습니다.

설명: 인공 지능 파이프라인, 구성, 스크립트 및 로그와 같은 텍스트 집약적인 작업을 가속화하는 보조자 및 의사 결정 지원 도구입니다. 생산 출시, 비밀 관리, 최종 적용 등 가동 중지 시간, 비용, 보안에 영향을 미치는 결정에 대한 책임은 유능한 엔지니어에게 있습니다.

2. 인공지능이 생성한 DevOps 명령이나 구성을 구현하기 전의 검증 원칙에 대한 가장 정확한 표현은 무엇입니까?

A) 출력이 매끄럽고 확실해 보인다면 프로덕션 환경에서 직접 실행할 수 있습니다.
B) 구문 오류가 없는 경우에만 출력이 안전하며 추가 검사가 필요하지 않습니다.
C) 출력을 소스에 연결하고, 계획/모의 실행하고, 시스템 컨텍스트에 따라 필터링합니다. 그럼 신청하세요 ✔
D) 현장에서 직접 첫 시도를 하고 결과를 지켜보는 것이 가장 빠른 검증이다.

설명: 3단계 확인이 필수적입니다. 출력을 소스에 연결하고(실제로 공식 문서에 있는 명령/플래그입니다), 건조 상태로 실행하고(plan/--dry-run에서 어떤 일이 일어나는지 확인), 시스템 필터를 통해 전달합니다(아키텍처 및 보안 컨텍스트에 적합한지 여부). 유창함은 정확성을 의미하지 않습니다.

3. 실제 데이터베이스 비밀번호가 포함된 .env 파일의 오류 또는 배포 문제에 대해 인공 지능에 요청할 때 올바른 접근 방식은 무엇입니까?

A) <PLACEHOLDER>로 실제 비밀을 가리세요. 마스킹된 오류 및 컨텍스트만 공유 ✔
B) 전체 .env 파일을 그대로 붙여넣으면 문제가 더 빨리 해결됩니다.
다) 비밀글은 이미 base64이므로 일반 붙여넣어도 안전합니다.
D) 비밀번호를 붙여넣는 것은 인공지능이 절대 저장하지 않기 때문에 안전합니다.

설명: 실제 비밀은 AI 프롬프트에 붙여넣어지지 않습니다. 비밀번호, 토큰 등의 값은 <PLACEHOLDER>로 마스킹됩니다. 오류 메시지와 필요한 컨텍스트만 공유됩니다. 비밀이 이미 유출된 경우 즉시 취소하고 교체해야 합니다.

4. 다음 중 CI/CD 파이프라인에서 비밀(비밀번호, 토큰)을 올바르게 관리하는 방법은 무엇입니까?

A) 플랫폼의 비밀 저장소에 보관되며 일반 텍스트로 작성되지 않고 참조(예: ${{ secrets.X }})로 호출됩니다. ✔
B) 편의를 위해 파이프라인 YAML에 일반 텍스트로 작성됩니다.
다) 각 작업 시작시 에코와 로그를 눌러 검증한다.
D) 가장 광범위한 권한(모두 쓰기)으로 정의하면 보안이 강화됩니다.

설명: 비밀은 일반 텍스트로 YAML에 기록되지 않습니다. 이는 플랫폼의 비밀 저장소에 보관되며 ${{ secrets.X }}와 같은 참조로 호출됩니다. 또한 최소 권한의 원칙에 따라 토큰 권한이 좁아지고 비밀 로그가 기록되지 않습니다.

5. Terraform을 사용한 인프라 관리에서 변경 사항을 실시간으로 구현하기 전에 취해야 할 가장 중요한 단계는 무엇입니까?

A) 'terraform Apply'를 직접 실행합니다. 그 계획은 시간 낭비야
B) State 파일을 공용 저장소에 백업
C) 'terraform plan'을 실행하고 출력에서 삭제/교체 줄을 확인한 후 적용 ✔
D) 공급자 버전을 제거하고 최신 버전이 자동으로 제공되는지 확인합니다.

설명: 'terraform 적용' 전에 'terraform 계획'을 실행해야 합니다. 계획에는 아무것도 하지 않고 무엇을 추가하고, 무엇을 변경하고, 특히 무엇을 삭제(폐기)할지 표시됩니다. 예기치 않은 삭제 또는 교체 줄이 표시되면 적용을 적용해서는 안 됩니다.

6. 프로덕션 데이터베이스의 '-/+ 교체' 줄이 Terraform 계획 출력에 나타나는 경우 이는 무엇을 의미하며 어떻게 해야 합니까?

A) 소스는 현장에서 업데이트되며 위험은 없습니다.
B) 리소스가 삭제되고 다시 생성됩니다. 데이터 손실 위험이 있으므로 예상하지 못한 경우 적용을 중지해야 합니다 ✔
C) 새로운 리소스를 추가해도 기존 데이터베이스는 영향을 받지 않습니다.
D) 이는 단지 경고일 뿐이므로 무시해도 됩니다.

설명: '-/+ 교체'는 리소스가 삭제되고 다시 생성됨을 의미합니다. 데이터베이스의 경우 이는 데이터 손실을 의미합니다. 예상하지 못한 경우 적용을 중지하고 변경 사항을 안전한 메서드로 변환하거나 변경할 수 없는 필드를 그대로 두어야 합니다.

7. 다음 중 보안 및 크기 측면에서 Dockerfile이 프로덕션 준비가 되어 있다는 사실은 무엇입니까?

A) 편의상 ENV를 사용하여 이미지에 비밀 정보를 삽입하고 루트로 실행합니다.
B) 항상 ':latest' 태그를 사용하고 기본 이미지를 최대한 크게 유지하세요.
C) 단일 단계 빌드 및 최종 이미지에 모든 빌드 도구 유지
D) Secret을 포함하지 않음, 비인가된 USER와 작업, 작고 안정적인 기본 이미지 사용 및 다단계 빌드 ✔

설명: 프로덕션 준비 이미지: 비밀을 포함하지 않고(런타임에 주입), 루트 대신 승인되지 않은 USER로 실행하고, 작은 버전의 기본 이미지(slim/alpine, :latest가 아님)를 사용하고, 다단계 빌드로 축소됩니다. 또한 게시되기 전에 취약점을 검사합니다.

8. Kubernetes 배포에 대한 리소스 제한을 정의하지 않을 때 발생하는 가장 중요한 위험은 무엇입니까?

A) 제한은 필수 필드이므로 포드가 시작되지 않습니다.
B) 모니터링 보드에는 경고만 표시되며 동작에는 영향을 미치지 않습니다.
C) Kubernetes는 위험 없이 안전한 기본 제한을 자동으로 적용합니다.
D) 포드는 무제한으로 성장하고 노드의 리소스를 소비하여 인접 서비스에 충돌을 일으킬 수 있습니다. ✔

설명: 리소스 제한이 없는 포드는 무제한으로 성장할 수 있고 실행 중인 노드의 모든 리소스를 소비하며 메모리 누수 등으로 인해 인접 서비스가 중단될 수 있습니다. 그렇기 때문에 요청/제한을 정의하는 것이 견고성의 기초입니다.

9. 모니터링 및 알람 설정 시 '경보 피로'를 방지하는 방법은 무엇입니까?

A) 가능한 한 많은 지표에 대해 경보를 설정하고 변동이 있을 때마다 경고를 생성합니다.
B) 모든 경보를 가장 높은 심각도 수준으로 설정합니다.
C) 시간을 설정하지 않고 순시값으로 알람 발생(for)
D) 경보를 조치 지향적이고 적절한 긴급 상태로 유지하고, 기록 데이터로 임계값을 테스트하고, 불필요한 데이터를 병합합니다. ✔

설명: 각 경보는 실행 가능하고 적절한 긴급성이어야 합니다. 조치가 필요하지 않은 정보는 보드에 표시되며 누구도 깨우지 않습니다. 시스템의 과거 데이터를 기준으로 경보 임계값을 테스트하고 불필요하거나 반복적인 경보를 통합합니다. 이렇게 하면 실제 알람이 소음 속에서 사라지지 않습니다.

10. 생산사고 시 최우선 순위는 무엇입니까?

A) 먼저 정확한 근본 원인을 찾아 원인이 분명할 때만 줄이세요.
B) 먼저 사후 보고서를 작성한 후 서비스를 터치합니다.
C) 우선(복원/복구 서비스)을 줄이고, 근본 원인 분석은 나중에 ✔
라) 먼저 사건의 책임자를 찾아 신고한다.

설명: 황금률은 '먼저 줄이고 나중에 조사하라'입니다. 목표는 먼저 서비스를 복원하거나 알려진 양호한 버전으로 롤백(완화)하는 것입니다. 근본 원인 분석은 압력이 가라앉은 후 침착하게 이루어집니다. 정확한 근본 원인을 찾기 위해 기다리면 복구 시간(MTTR)이 늘어납니다.

11. 흠 없는 사후 문화의 주요 목적은 무엇입니까?

가) 잘못한 사람을 찾아 책임을 묻는다.
B) 시스템과 프로세스에 중점을 두고 학습을 장려합니다. ✔ 비난보다는 반복을 방지하는 학습 레슨
다) 절대로 신고하지 말고 잊어버린지 확인한다
D) 기술적 세부사항만 작성하고 실행 가능한 항목은 추가하지 않음

설명: 비난 없는 사후 분석은 '누가 그랬는가'가 아니라 '어떤 시스템과 프로세스가 이런 실수를 허용했는지'에 초점을 맞춘다. 사람들은 자신이 처벌받지 않을 것이라는 것을 안다면 공개적으로 실수를 공유합니다. 숨겨진 오류가 반복됩니다. 보고서는 고발 보고서가 아니라 행동 지향적인 항목으로 가득 찬 학습 문서입니다.

12. 클라우드 비용 최적화(FinOps)에서 약정 할인(Reserved/Savings Plan)으로 전환하기 전에 취해야 할 가장 논리적인 단계는 무엇입니까?

A) 가능한 가장 긴 약속을 먼저 취하고, 낭비에 대해서는 나중에 생각하십시오.
B) 먼저 폐기물을 정리(유휴 폐쇄, 적절한 크기 조정)한 후 전용 사용을 약속합니다. ✔
C) 모든 리소스를 즉시 스팟 용량으로 이동
D) 송장 데이터를 검토하지 않고 가장 비싼 품목을 삭제하는 행위

설명: 폐기물을 먼저 정리해야 합니다(유휴 자원 폐쇄, 초과된 자원 감소). 그렇지 않으면 낭비되는 사용량을 1~3년 동안 할인된 가격으로 잠그게 됩니다. 적절한 크기 조정 및 유휴 청소에는 약정이 필요하지 않으며 위험이 거의 없습니다.

13. AI 제안 스크립트에 'rm -rf "$DIR"/' 줄이 있는 경우 가장 중요한 보안 조치는 무엇입니까?

A) 스크립트를 읽지 않고 prod에서 직접 실행하면 속도가 빨라집니다.
B) set -euo Pipefail 및 빈 변수 제어를 추가하고 먼저 테스트 실행을 시도합니다. ✔
다) 변수명을 짧게 하면 충분하다
D) rm 대신 rm -rf --force를 사용하면 문제가 해결됩니다.

설명: $DIR이 비어 있는 경우 이 명령문은 루트 디렉터리 삭제를 시도할 수 있습니다. 'set -u'를 사용하여 정의되지 않은 변수에서 중지하고 변수를 삭제하기 전에 변수가 비어 있지 않은지 확인하면(예: [ -n "$DIR" ] || 종료 1) 재난을 피할 수 있습니다. 또한 파괴적인 작업은 먼저 테스트 실행으로 시도해야 합니다.

14. 클라우드 액세스 키가 실수로 공용 저장소로 유출된 경우 가장 먼저 해야 할 일은 무엇입니까?

A) 즉시 키를 취소하고 갱신(회전)합니다. 삭제만으로는 부족해요✔
B) 저장소에서 파일을 삭제하면 키는 안전합니다.
C) 아무도 본 사람이 없어서 아무것도 하지 않는다
D) 저장소를 비공개로 설정하면 키를 순환할 필요가 없습니다.

설명: 유출된 비밀은 즉시 취소되고 순환되어야 합니다. 파일을 삭제하는 것만으로는 충분하지 않습니다. 비밀은 Git 기록에 남아 있고 공개 저장소는 몇 초 내에 봇에 의해 스캔되기 때문입니다. 취소/반품 이후에는 영향을 평가하고, 재발 방지를 위해 시크릿 스캐너를 추가합니다.

15. 다음 중 새 버전의 Prod를 출시할 때 위험을 최소화하는 접근 방식은 무엇입니까?

A) 새 버전을 모든 사용자에게 동시에 제공(빅뱅)하고 롤백 계획을 준비하지 않음
B) '녹색'으로 표시되는 즉시 배포가 완료된 것으로 간주하여 추가 확인을 수행하지 않습니다.
C) 카나리아/블루-그린/기능 플래그, 기성 롤백 계획 및 스모크 테스트 + 배포 후 메트릭 모니터링과 같은 통제된 전략 사용 ✔
D) 중요한 비즈니스 경로에 대한 테스트를 전적으로 인공 지능에 맡기고 전혀 결정하지 않습니다.

설명: 제어된 릴리스 전략(Canary를 사용하여 작은 비율로 시작, 청록색을 사용하여 즉시 롤백, 기능 플래그를 사용하여 배포와 릴리스 분리)은 위험을 제한합니다. 또한 배포 전 명확한 롤백 계획과 배포 후 연기 테스트를 통한 골든 신호 모니터링이 필수적입니다. '녹색으로 보인다'고 해서 효과가 있다는 뜻은 아닙니다.