KoreaDevKNOWLEDGE SHARING

콘텐츠 유형학습하기

AI INFRASTRUCTURE · 12 / 12

AI 인프라 종합 프로젝트

요구사항을 설계로 바꾸고 구축·인수·장애 주입·복구·운영·인수인계를 하나의 evidence package로 완성합니다.

난이도
중급
구성
핵심 단원 3개 · 판단 활동 · 3단계 평가

NEW HIRE ONBOARDING

첫 업무를 받는 순서로 시작합니다

중학교를 졸업하고 처음 IT 업무를 맡은 신입사원도 따라올 수 있도록, 어려운 정의보다 상황·할 일·증거·보고할 경계를 먼저 확인합니다.

  1. 01

    상황을 한 문장으로 읽기

    요구사항에서 설계, 구축, 장애 시험과 교대까지 앞 과정의 산출물을 연결합니다. 미측정 성능과 미검증 복구는 인수 완료로 바꾸지 않습니다.

  2. 02

    오늘 맡은 일

    장애 복구와 운영 인수인계의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

  3. 03

    완료를 보여 주는 증거

    공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

  4. 04

    멈추고 선임에게 확인할 경계

    기능 시험은 성공했지만 restore 시험과 교대 담당자의 접근 확인이 없습니다. 인수 판정은?

낯선 용어 먼저 풀기

SLO(Service Level Objective, 서비스 수준 목표)
정해진 관찰 구간에서 서비스가 달성하려는 측정 가능한 품질 목표입니다.

이 과정의 운영 질문

다른 담당자가 같은 증거로 인수하고 복구할 수 있습니까?

요구사항에서 설계, 구축, 장애 시험과 교대까지 앞 과정의 산출물을 연결합니다. 미측정 성능과 미검증 복구는 인수 완료로 바꾸지 않습니다.

CORE UNIT 1 / 3

요구사항과 architecture 설계

SLO·capacity·security·failure domain을 설계서로 바꿉니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

브라우저 판독·작업 계획 작성만 수행. 실제 장비·고객 traffic 조작 없음.

3처음 보는 값과 아직 실행하지 않은 시험은 어떻게 적습니까?

미확인으로 기록합니다. 교육용 예상 출력과 실제 측정값을 구분하고, 승인 없는 작업으로 빈칸을 채우지 않습니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. 요구사항과 architecture 설계의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. 요구사항과 architecture 설계의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. 요구사항과 architecture 설계의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
요구사항과 architecture 설계 실습 환경과 안전 경계
하드웨어2-node 설계·인수·장애 증거 묶음 fixture
소프트웨어JSON 작업 기록·Kubernetes API v1 예제
필요 권한브라우저 판독·작업 계획 작성만 수행
네트워크실제 장비·고객 traffic 조작 없음

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Kubernetes API v1 · 교육 fixture 2026.2 · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장요구 R1에서 확인을 시작합니다
  2. 2장배치의 실습 대상을 고정합니다
  3. 3장공통 경계의 출력과 의미를 구분합니다
  4. 4장설계 판정의 진행과 중단을 결정합니다
  5. 5장요구사항과 architecture 설계의 복구를 재검증합니다
요구사항과 architecture 설계의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · 요구 R1에서 확인을 시작합니다

다음 연결: 배치의 실습 대상을 고정합니다

  1. 요구 R1에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. 배치의 실습 대상을 고정합니다

    실습 상황:: 배치 fixture를 읽고 rack 장애 요구를 만족하지 못하는 이유와 설계 수정 두 가지를 작성합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 요구 미확인·공통 경계 미대응 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 공통 경계의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 node 이름이 달라도 rack과 PDU가 같아 독립 failure domain이 아니라는 점을 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 설계 판정의 진행과 중단을 결정합니다

    요구 R1과 미충족 경계를 연결하고 독립 배치 또는 승인된 요구 변경, 검증 시험을 제시하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. 요구사항과 architecture 설계의 복구를 재검증합니다

    가정이 틀리면 영향받는 요구와 후속 시험을 역추적합니다. 장비만 교체하지 말고 설계 revision·검증 항목·인수 기준을 함께 갱신합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

replica 수와 공통 실패 경계를 함께 설계합니다

SLO(Service Level Objective, 서비스 수준 목표): 정해진 관찰 구간에서 서비스가 달성하려는 측정 가능한 품질 목표입니다.

설계는 제품 목록이 아니라 사용자 요구를 측정 가능한 조건과 의존성으로 바꾸는 작업입니다. 최대 사용자 수만으로는 GPU 수를 정할 수 없습니다. 입력 길이·동시성·응답 지연·가용성·데이터 보존과 운영 인력을 함께 알아야 합니다.

요구사항 ID를 SLO, 자원 가정, failure domain과 검증 항목에 연결하면 설계 선택의 이유를 추적할 수 있습니다. 수치가 없는 항목은 미확인으로 표시하고 이를 해소할 시험을 정합니다. 먼저 장비를 고른 뒤 수치를 맞추면 필요한 실패 경계가 빠집니다.

fixture는 replica 두 개를 서로 다른 node에 배치하지만 같은 rack PDU를 사용합니다. node 장애에는 여유가 있어도 PDU 장애에는 둘 다 멈춥니다. rack 단위 가용성이 요구사항이라면 전원 경로를 나누거나 요구를 승인 절차로 다시 합의해야 합니다.

배치 fixture를 읽고 rack 장애 요구를 만족하지 못하는 이유와 설계 수정 두 가지를 작성합니다.

node 두 대의 배치 fixture를 요구 R1과 대조해 rack과 PDU를 함께 쓰는 두 항목이 미충족임을 보이는 표입니다.
그림 읽는 법 replica 수와 공통 실패 경계를 함께 설계합니다. 배치 fixture를 요구 R1과 한 줄씩 대조하는 표이고 왼쪽 배지 1에서 4까지가 순서입니다. 첫째 칸이 확인 항목, 둘째 칸이 fixture 값, 셋째 칸이 요구 R1이 요구하는 것, 넷째 칸이 판정과 그 근거입니다. replica 배치는 node-01과 node-02로 나뉘어 충족이지만, rack이 둘 다 rack-a이고 PDU도 둘 다 pdu-a여서 둘째·셋째 행은 미충족입니다. 넷째 행의 입력 길이·동시성·응답 지연·가용성·데이터 보존·운영 인력은 fixture에 값이 없어 미확인으로 남기고 이를 해소할 시험을 정합니다. 마지막 파란 상자는 설계 수정 두 가지 중 하나를 고르고 검증 시험을 함께 적으라는 규칙입니다. 표 안의 node 이름·rack·PDU·요구 ID는 교육용 fixture이며 실제 장비에서 얻은 값이 아닙니다. 자료: Google SRE Workbook: Implementing SLOs · K3s Architecture를 바탕으로 저자 구성.
왜 이런가
요구사항 ID를 SLO, 자원 가정, failure domain과 검증 항목에 연결하면 설계 선택의 이유를 추적할 수 있습니다. 수치가 없는 항목은 미확인으로 표시하고 이를 해소할 시험을 정합니다. 먼저 장비를 고른 뒤 수치를 맞추면 필요한 실패 경계가 빠집니다.
언제 문제가 되는가
요구 미확인·공통 경계 미대응 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
측정하지 않은 throughput이나 전력 여유를 견적 수치로 확정하지 않습니다. 비용표에는 가정과 단위를 쓰고 확정 전 항목을 미확인으로 남깁니다.
직접 확인하는 방법
기능·성능·가용성·보안·복구 요구를 ID로 정리합니다. 각 요구에 가정과 검증 방법을 연결합니다.
이 절을 정리하면요구 R1과 미충족 경계를 연결하고 독립 배치 또는 승인된 요구 변경, 검증 시험을 제시하면 성공입니다.

CHAPTER 1 / 5

요구 R1에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. 기능·성능·가용성·보안·복구 요구를 ID로 정리합니다. 2. 각 요구에 가정과 검증 방법을 연결합니다. 3. 요청 경로의 power·network·storage·GPU 공통 경계를 표시합니다. 4. 비용과 복구 부담, 미해결 가정의 owner를 적습니다.

CHAPTER 2 / 5

배치의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
jq -r '.nodes[] | [.name,.rack,.pdu,.replica] | @tsv' design.json

CHAPTER 3 / 5

공통 경계의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
node-01	rack-a	pdu-a	model-1
node-02	rack-a	pdu-a	model-2

CHAPTER 4 / 5

설계 판정의 진행과 중단을 결정합니다

CHAPTER 5 / 5

요구사항과 architecture 설계의 복구를 재검증합니다

CONCRETE CASES

배치 fixture를 읽고 rack 장애 요구를 만족하지 못하는 이유와 설계 수정 두 가지를 작성합니다.

fixture는 replica 두 개를 서로 다른 node에 배치하지만 같은 rack PDU를 사용합니다. node 장애에는 여유가 있어도 PDU 장애에는 둘 다 멈춥니다. rack 단위 가용성이 요구사항이라면 전원 경로를 나누거나 요구를 승인 절차로 다시 합의해야 합니다.

잘못된 대응과 확인할 경계

측정하지 않은 throughput이나 전력 여유를 견적 수치로 확정하지 않습니다. 비용표에는 가정과 단위를 쓰고 확정 전 항목을 미확인으로 남깁니다.

가정이 틀리면 영향받는 요구와 후속 시험을 역추적합니다. 장비만 교체하지 말고 설계 revision·검증 항목·인수 기준을 함께 갱신합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 배치 fixture를 읽고 rack 장애 요구를 만족하지 못하는 이유와 설계 수정 두 가지를 작성합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 요구 미확인·공통 경계 미대응 조건이 보이면 다음 변경으로 넘어가지 마십시오.

node-01	rack-a	pdu-a	model-1
node-02	rack-a	pdu-a	model-2

값 자체를 외우는 것이 아니라 node 이름이 달라도 rack과 PDU가 같아 독립 failure domain이 아니라는 점을 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

측정하지 않은 throughput이나 전력 여유를 견적 수치로 확정하지 않습니다. 비용표에는 가정과 단위를 쓰고 확정 전 항목을 미확인으로 남깁니다.

KEY TERMS

이번 단원 핵심 용어

SLO(Service Level Objective, 서비스 수준 목표)
정해진 관찰 구간에서 서비스가 달성하려는 측정 가능한 품질 목표입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

요구사항과 architecture 설계의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 2 / 3

구축과 인수 시험

revision 기반 구축과 계층별 acceptance evidence를 완성합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

브라우저 판독·작업 계획 작성만 수행. 실제 장비·고객 traffic 조작 없음.

3앞 단원 「요구사항과 architecture 설계」에서 어떤 증거를 남겼습니까?

요구 R1과 미충족 경계를 연결하고 독립 배치 또는 승인된 요구 변경, 검증 시험을 제시하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. 구축과 인수 시험의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. 구축과 인수 시험의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. 구축과 인수 시험의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
구축과 인수 시험 실습 환경과 안전 경계
하드웨어2-node 설계·인수·장애 증거 묶음 fixture
소프트웨어JSON 작업 기록·Kubernetes API v1 예제
필요 권한브라우저 판독·작업 계획 작성만 수행
네트워크실제 장비·고객 traffic 조작 없음

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Kubernetes API v1 · 교육 fixture 2026.2 · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장설계 revision에서 확인을 시작합니다
  2. 2장구축 증거의 실습 대상을 고정합니다
  3. 3장인수 시험의 출력과 의미를 구분합니다
  4. 4장인수 판정의 진행과 중단을 결정합니다
  5. 5장구축과 인수 시험의 복구를 재검증합니다
구축과 인수 시험의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · 설계 revision에서 확인을 시작합니다

다음 연결: 구축 증거의 실습 대상을 고정합니다

  1. 설계 revision에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. 구축 증거의 실습 대상을 고정합니다

    실습 상황:: 아래 시험 목록을 읽고 인수 가능 여부와 부족한 증거를 표로 작성합니다. 실제 cluster 조작은 하지 않습니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 미실행 시험·대상 revision 불일치 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 인수 시험의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 A2 복구 시험이 남아 전체 인수는 완료할 수 없다는 점을 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 인수 판정의 진행과 중단을 결정합니다

    각 요구에 실제 증거 파일을 연결하고 A2 담당자·격리 환경·성공 기준·재시험 시각을 정하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. 구축과 인수 시험의 복구를 재검증합니다

    실패 층만 수정하되 dependency 영향을 검토합니다. 새 revision에서 해당 시험과 영향받는 회귀 시험을 다시 돌리고 최초 실패 기록도 함께 보존합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

미실행 시험을 성공으로 바꾸지 않고 인수합니다

Acceptance(인수 판정): 요구사항을 실제 시험 증거와 비교해 운영 인수 가능 여부를 결정하는 절차입니다.

인수는 설치 명령이 끝났는지가 아니라 약속한 기능과 실패 경계를 입증했는지 판정합니다. 장비 inventory부터 host·fabric·storage·cluster·model API까지 각 층의 identity를 한 release record로 연결해야 합니다.

시험마다 요구 ID, 환경 revision, 입력, 명령, 출력과 통과 기준을 고정하면 성공뿐 아니라 실패도 재현할 수 있습니다. 성능·보안 거부·backup restore는 서로 다른 시험입니다. 기능 성공을 세 시험의 대체 증거로 쓰지 않습니다.

fixture의 기능 A1은 통과했지만 복구 A2는 미실행입니다. 미실행을 fail로 바꾸면 원인을 잘못 기록하고, pass로 바꾸면 위험을 숨깁니다. 미확인 상태 그대로 owner와 재시험 조건을 정해 인수를 보류합니다.

아래 시험 목록을 읽고 인수 가능 여부와 부족한 증거를 표로 작성합니다. 실제 cluster 조작은 하지 않습니다.

acceptance.json의 A1·A2·A3 시험을 증거·판정·다음 행동으로 나누고 A2 미실행 때문에 전체 인수를 보류하는 표입니다.
그림 읽는 법 미실행 시험을 성공으로 바꾸지 않고 인수합니다. acceptance.json 한 줄이 표의 한 행이며 왼쪽 배지 1에서 4까지가 순서입니다. 첫째 칸이 시험 ID와 요구, 둘째 칸이 jq 출력 원문 증거, 셋째 칸이 판정, 넷째 칸이 그 판정에서 이어지는 행동입니다. A1과 A3은 pass이고, A2는 출력도 실패 원문도 없어 UNVERIFIED 즉 미실행입니다. 미실행을 fail로 바꾸면 원인을 잘못 기록하고 pass로 바꾸면 위험을 숨기므로, 넷째 행에서 요구 3건 중 증거 2건이라는 이유로 전체 인수를 보류합니다. 마지막 호박색 상자는 허용치를 사후에 바꾸지 않는다는 금지 조건이고, 그 아래 회색 두 줄은 값의 성격과 증거 칸의 출력 형식을 적었습니다. 표 안의 시험 ID·요구 ID·revision·결과 문자열은 교육용 fixture이며 실제 cluster에서 얻은 값이 아닙니다. 자료: Kubernetes Liveness, Readiness and Startup Probes · K3s Backup and Restore · NVIDIA Triton Metrics를 바탕으로 저자 구성.
왜 이런가
시험마다 요구 ID, 환경 revision, 입력, 명령, 출력과 통과 기준을 고정하면 성공뿐 아니라 실패도 재현할 수 있습니다. 성능·보안 거부·backup restore는 서로 다른 시험입니다. 기능 성공을 세 시험의 대체 증거로 쓰지 않습니다.
언제 문제가 되는가
미실행 시험·대상 revision 불일치 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
시험을 통과시키려고 허용치를 사후에 바꾸지 않습니다. 기준 변경이 필요하면 변경 이유와 승인자를 남기고 기존 결과와 분리합니다.
직접 확인하는 방법
장비·firmware·image·model digest를 기준선에 기록합니다. 설계 요구와 시험 ID를 일대일 또는 명시적 다대일로 연결합니다.
이 절을 정리하면각 요구에 실제 증거 파일을 연결하고 A2 담당자·격리 환경·성공 기준·재시험 시각을 정하면 성공입니다.

CHAPTER 1 / 5

설계 revision에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. 장비·firmware·image·model digest를 기준선에 기록합니다. 2. 설계 요구와 시험 ID를 일대일 또는 명시적 다대일로 연결합니다. 3. pass·fail·미실행을 구분하고 실패 원문을 보존합니다. 4. 재시험은 같은 조건과 승인된 revision에서 실행합니다.

CHAPTER 2 / 5

구축 증거의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
jq -r '.checks[] | [.id,.requirement,.result,.revision] | @tsv' acceptance.json

CHAPTER 3 / 5

인수 시험의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
A1	R-api	pass	r7
A2	R-restore	UNVERIFIED	r7
A3	R-auth	pass	r7

CHAPTER 4 / 5

인수 판정의 진행과 중단을 결정합니다

CHAPTER 5 / 5

구축과 인수 시험의 복구를 재검증합니다

CONCRETE CASES

아래 시험 목록을 읽고 인수 가능 여부와 부족한 증거를 표로 작성합니다. 실제 cluster 조작은 하지 않습니다.

fixture의 기능 A1은 통과했지만 복구 A2는 미실행입니다. 미실행을 fail로 바꾸면 원인을 잘못 기록하고, pass로 바꾸면 위험을 숨깁니다. 미확인 상태 그대로 owner와 재시험 조건을 정해 인수를 보류합니다.

잘못된 대응과 확인할 경계

시험을 통과시키려고 허용치를 사후에 바꾸지 않습니다. 기준 변경이 필요하면 변경 이유와 승인자를 남기고 기존 결과와 분리합니다.

실패 층만 수정하되 dependency 영향을 검토합니다. 새 revision에서 해당 시험과 영향받는 회귀 시험을 다시 돌리고 최초 실패 기록도 함께 보존합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 아래 시험 목록을 읽고 인수 가능 여부와 부족한 증거를 표로 작성합니다. 실제 cluster 조작은 하지 않습니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 미실행 시험·대상 revision 불일치 조건이 보이면 다음 변경으로 넘어가지 마십시오.

A1	R-api	pass	r7
A2	R-restore	UNVERIFIED	r7
A3	R-auth	pass	r7

값 자체를 외우는 것이 아니라 A2 복구 시험이 남아 전체 인수는 완료할 수 없다는 점을 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

시험을 통과시키려고 허용치를 사후에 바꾸지 않습니다. 기준 변경이 필요하면 변경 이유와 승인자를 남기고 기존 결과와 분리합니다.

KEY TERMS

이번 단원 핵심 용어

Acceptance(인수 판정)
요구사항을 실제 시험 증거와 비교해 운영 인수 가능 여부를 결정하는 절차입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

구축과 인수 시험의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 3 / 3

장애 복구와 운영 인수인계

장애 주입·복구·postmortem·Runbook·handover로 Go/No-Go를 판정합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

브라우저 판독·작업 계획 작성만 수행. 실제 장비·고객 traffic 조작 없음.

3앞 단원 「구축과 인수 시험」에서 어떤 증거를 남겼습니까?

각 요구에 실제 증거 파일을 연결하고 A2 담당자·격리 환경·성공 기준·재시험 시각을 정하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. 장애 복구와 운영 인수인계의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. 장애 복구와 운영 인수인계의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. 장애 복구와 운영 인수인계의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
장애 복구와 운영 인수인계 실습 환경과 안전 경계
하드웨어2-node 설계·인수·장애 증거 묶음 fixture
소프트웨어JSON 작업 기록·Kubernetes API v1 예제
필요 권한브라우저 판독·작업 계획 작성만 수행
네트워크실제 장비·고객 traffic 조작 없음

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Kubernetes API v1 · 교육 fixture 2026.2 · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장정상 기준선에서 확인을 시작합니다
  2. 2장장애 기록의 실습 대상을 고정합니다
  3. 3장교대 재현의 출력과 의미를 구분합니다
  4. 4장인계 승인의 진행과 중단을 결정합니다
  5. 5장장애 복구와 운영 인수인계의 복구를 재검증합니다
장애 복구와 운영 인수인계의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · 정상 기준선에서 확인을 시작합니다

다음 연결: 장애 기록의 실습 대상을 고정합니다

  1. 정상 기준선에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. 장애 기록의 실습 대상을 고정합니다

    실습 상황:: 교대 시험 결과를 읽고 인계 종료 여부를 판단한 뒤 권한을 넓히지 않고 보완할 방법을 작성합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 권한·key·owner·재현 증거 없음 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 교대 재현의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 dashboard 조회 성공이 key 접근과 restore 능력을 대신하지 않는다는 점을 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 인계 승인의 진행과 중단을 결정합니다

    인계를 보류하고 감사 가능한 key 접근·break-glass 경로, 교대 역할 재시험과 책임자 확인을 완료 조건으로 제시하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. 장애 복구와 운영 인수인계의 복구를 재검증합니다

    인계 시험이 실패하면 기존 운영 owner를 유지하고 실패 항목을 보완합니다. 새 담당자가 같은 문서로 재현한 뒤 소유권 이전 시각과 남은 위험을 기록합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

받는 담당자의 재현 결과로 인계를 마칩니다

Handover(운영 인계): 다음 담당자가 상태 확인과 대응을 재현할 수 있도록 권한·절차·책임을 넘기는 과정입니다.

인계 문서는 장비 목록보다 다음 담당자의 첫 행동을 알려 주어야 합니다. 현재 revision·정상 기준선·알림·권한·backup 위치·중단 기준과 escalation 경로가 있어야 장애가 나도 소유권이 끊기지 않습니다.

인계받는 사람이 읽기 전용 조회와 격리 restore를 직접 재현하면 문서, 권한과 실제 환경 사이의 차이가 드러납니다. 작성자가 옆에서 대신 조작하면 그 차이를 숨깁니다. 인계 시험은 문서를 이용해 수행하고 막힌 지점을 기록하는 절차입니다.

교육 사고에서 restore 명령은 맞았지만 야간 담당자에게 backup key 접근 권한이 없었습니다. 주간 담당자의 성공 기록으로는 야간 복구 능력을 증명할 수 없습니다. 최소 권한과 break-glass 절차를 실제 교대 역할로 시험해야 합니다.

교대 시험 결과를 읽고 인계 종료 여부를 판단한 뒤 권한을 넓히지 않고 보완할 방법을 작성합니다.

인계 점검표입니다. 상태 기준선·위치와 owner·교대 역할 시험·격리 restore 서명 네 단계를 통과 기준과 함께 보이고, 교대 시험 출력의 denied와 UNVERIFIED를 근거로 인계 보류를 판정합니다.
그림 읽는 법 받는 담당자의 재현 결과로 인계를 마칩니다. 표는 왼쪽 배지 1부터 4까지 위에서 아래로 읽고, 각 행은 무엇을 하는가·무엇을 보아야 통과인가·빠뜨리면 무엇이 깨지나 순으로 가로로 읽습니다. 셋째 열의 통과 기준을 만족하지 못하면 다음 단계로 넘어가지 않습니다. 아래 왼쪽 상자는 jq로 뽑은 교대 시험 출력이며 dashboard-read는 pass, backup-key-access는 denied, isolated-restore는 UNVERIFIED입니다. 오른쪽 상자는 그 세 줄을 근거로 인계를 보류한다는 판정이고, dashboard 조회 성공이 key 접근과 restore 능력을 대신하지 않는다는 뜻입니다. 맨 아래 띠는 권한·key·owner·재현 증거 중 하나라도 없으면 기존 운영 owner를 유지한다는 규칙과 secret을 문서에 적지 않는 금지 사항입니다. 색은 열을 구분하려는 것이고 우열을 뜻하지 않으므로 색을 구별하지 않아도 읽을 수 있습니다. 표의 식별자와 상태 문자열은 저자 구성 교육용 예시이며 실제 장비에서 측정한 값이 아닙니다. 자료: Google SRE Workbook: Incident Response · Kubernetes Using RBAC Authorization · K3s Backup and Restore를 바탕으로 저자 구성.
왜 이런가
인계받는 사람이 읽기 전용 조회와 격리 restore를 직접 재현하면 문서, 권한과 실제 환경 사이의 차이가 드러납니다. 작성자가 옆에서 대신 조작하면 그 차이를 숨깁니다. 인계 시험은 문서를 이용해 수행하고 막힌 지점을 기록하는 절차입니다.
언제 문제가 되는가
권한·key·owner·재현 증거 없음 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
인계 편의를 위해 공용 admin credential이나 key 원문을 문서에 넣지 않습니다. secret 위치·승인 경로·회수 방법만 기록합니다.
직접 확인하는 방법
현재 상태와 열린 incident·미해결 가정을 적습니다. 알림·dashboard·runbook·backup의 위치와 owner를 연결합니다.
이 절을 정리하면인계를 보류하고 감사 가능한 key 접근·break-glass 경로, 교대 역할 재시험과 책임자 확인을 완료 조건으로 제시하면 성공입니다.

CHAPTER 1 / 5

정상 기준선에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. 현재 상태와 열린 incident·미해결 가정을 적습니다. 2. 알림·dashboard·runbook·backup의 위치와 owner를 연결합니다. 3. 인계받는 역할의 접근과 금지 행동을 시험합니다. 4. 격리 복구 결과와 RPO/RTO, 다음 점검일을 함께 서명합니다.

CHAPTER 2 / 5

장애 기록의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
jq -r '.handover[] | [.task,.role,.result] | @tsv' handover.json

CHAPTER 3 / 5

교대 재현의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
dashboard-read	oncall-night	pass
backup-key-access	oncall-night	denied
isolated-restore	oncall-night	UNVERIFIED

CHAPTER 4 / 5

인계 승인의 진행과 중단을 결정합니다

CHAPTER 5 / 5

장애 복구와 운영 인수인계의 복구를 재검증합니다

CONCRETE CASES

교대 시험 결과를 읽고 인계 종료 여부를 판단한 뒤 권한을 넓히지 않고 보완할 방법을 작성합니다.

교육 사고에서 restore 명령은 맞았지만 야간 담당자에게 backup key 접근 권한이 없었습니다. 주간 담당자의 성공 기록으로는 야간 복구 능력을 증명할 수 없습니다. 최소 권한과 break-glass 절차를 실제 교대 역할로 시험해야 합니다.

잘못된 대응과 확인할 경계

인계 편의를 위해 공용 admin credential이나 key 원문을 문서에 넣지 않습니다. secret 위치·승인 경로·회수 방법만 기록합니다.

인계 시험이 실패하면 기존 운영 owner를 유지하고 실패 항목을 보완합니다. 새 담당자가 같은 문서로 재현한 뒤 소유권 이전 시각과 남은 위험을 기록합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 교대 시험 결과를 읽고 인계 종료 여부를 판단한 뒤 권한을 넓히지 않고 보완할 방법을 작성합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 권한·key·owner·재현 증거 없음 조건이 보이면 다음 변경으로 넘어가지 마십시오.

dashboard-read	oncall-night	pass
backup-key-access	oncall-night	denied
isolated-restore	oncall-night	UNVERIFIED

값 자체를 외우는 것이 아니라 dashboard 조회 성공이 key 접근과 restore 능력을 대신하지 않는다는 점을 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

인계 편의를 위해 공용 admin credential이나 key 원문을 문서에 넣지 않습니다. secret 위치·승인 경로·회수 방법만 기록합니다.

KEY TERMS

이번 단원 핵심 용어

Handover(운영 인계)
다음 담당자가 상태 확인과 대응을 재현할 수 있도록 권한·절차·책임을 넘기는 과정입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

장애 복구와 운영 인수인계의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

DECISION ACTIVITY

기능 시험은 성공했지만 restore 시험과 교대 담당자의 접근 확인이 없습니다. 인수 판정은?

먼저 필요한 증거와 중단 기준을 적은 뒤 판단을 선택하십시오.

답 선택

THREE-LEVEL ASSESSMENT

기본 원리에서 운영 판단까지

답을 제출하면 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

기본 문제 1

설계에서 failure domain을 구분하는 목적은?

답 선택
적용 문제 2

인수 시험이 반복 가능하려면 무엇을 남깁니까?

답 선택
종합 문제 3

장애 후 인계를 끝내는 가장 강한 증거는?

답 선택

LEARNING RECORD

본문·판단 활동·모든 해설을 확인했나요?

완료 기록은 이 브라우저에만 저장됩니다.