클라우드와 DevOps 핵심 개념 지도: 인프라에서 배포와 관측성까지

클라우드 인프라2026년 8월 15일글: 홍서진, Duolabs39분 읽기blog cloud-devops cloud-devops-core-concepts cloud-infrastructure model-openai-gpt-5 technical-note

클라우드와 DevOps를 제품 목록으로 익히면 비슷한 기능을 가리키는 이름이 계속 늘어납니다. 가상 머신, 컨테이너, 서버리스, CI/CD와 Kubernetes는 같은 층의 대안이 아닙니다. 어떤 것은 실행 환경이고, 어떤 것은 배포 흐름이며, 어떤 것은 원하는 상태를 유지하는 제어 시스템입니다.

이 문서는 코드를 운영 서비스로 바꾸고 계속 안전하게 변경하는 과정에 필요한 개념을 한 장의 지도로 정리합니다. 클라우드는 자원을 제공하는 운영 모델이고 DevOps는 개발과 운영의 피드백을 짧게 만드는 문화와 실천입니다. 둘은 자주 함께 쓰이지만 같은 뜻은 아닙니다.

클라우드는 서버 위치보다 자원 소비 방식에 가깝습니다

클라우드 컴퓨팅: 네트워크를 통해 공유된 컴퓨팅 자원을 필요할 때 할당하고 해제하는 운영 모델입니다. NIST는 다섯 가지 핵심 특성, 세 가지 서비스 모델과 네 가지 배포 모델로 정의합니다.
온디맨드 셀프서비스: 사용자가 공급자와 매번 직접 협의하지 않고 필요한 자원을 스스로 만들 수 있는 특성입니다. API와 자동화의 출발점입니다.
광범위한 네트워크 접근: 표준 네트워크 방식으로 여러 종류의 클라이언트에서 서비스에 접근할 수 있는 특성입니다.
자원 풀링: 공급자의 물리 자원을 여러 사용자가 논리적으로 나눠 쓰는 특성입니다. 멀티테넌시와 격리가 함께 중요해집니다.
빠른 탄력성: 수요에 맞춰 자원을 빠르게 늘리고 줄이는 특성입니다. 단순히 큰 서버를 미리 사 두는 것과 다릅니다.
측정 가능한 서비스: 사용량을 계측하고 통제하며 비용으로 연결할 수 있는 특성입니다. 기술 지표와 비용 지표가 같은 자원 단위를 바라보게 됩니다.
IaaS: 가상 머신, 네트워크와 저장소 같은 기반 자원을 서비스로 제공합니다. 운영체제 위쪽은 사용자가 더 많이 책임집니다.
PaaS: 애플리케이션 실행 환경과 배포 인터페이스를 관리형으로 제공합니다. 제어 범위는 줄지만 운영 부담도 줄어듭니다.
SaaS: 완성된 소프트웨어 기능을 서비스로 사용합니다. 사용자는 애플리케이션 내부 구현보다 데이터, 계정과 사용 정책을 관리합니다.
공용 클라우드: 공급자가 여러 고객을 위한 자원과 서비스를 운영합니다. 논리적 격리, 계약과 데이터 위치를 확인해야 합니다.
사설 클라우드: 한 조직을 위해 클라우드 특성을 구현한 환경입니다. 전용 하드웨어라는 사실만으로 자동화와 탄력성이 생기는 것은 아닙니다.
하이브리드 클라우드: 서로 다른 배포 환경을 연결해 워크로드와 데이터를 나눕니다. 네트워크, 신원과 운영 모델을 일관되게 만드는 비용이 따릅니다.
멀티클라우드: 둘 이상의 클라우드 공급자 서비스를 사용합니다. 공급자 장애와 협상 위험은 나눌 수 있지만 공통 기반의 복잡성이 커질 수 있습니다.
공동 책임 모델: 공급자와 사용자가 보안과 운영 책임을 나눕니다. 관리형 서비스일수록 사용자의 책임이 사라지는 것이 아니라 더 위의 계층으로 이동합니다.
리전: 지리적으로 구분된 서비스 운영 영역입니다. 지연, 데이터 거주, 가격과 재해 복구 설계에 영향을 줍니다.
가용 영역: 한 리전 안에서 전력과 장애 도메인을 분리한 운영 단위입니다. 여러 영역에 배치해도 애플리케이션과 데이터가 실제로 장애를 견디도록 설계해야 합니다.
엣지: 사용자와 가까운 위치에서 캐시, 요청 처리와 보안 기능을 실행합니다. 지연은 줄지만 상태 일관성과 실행 제약을 고려해야 합니다.

컴퓨트는 격리 수준과 수명주기가 다릅니다

베어메탈: 가상 머신 계층 없이 물리 서버를 직접 사용합니다. 성능과 하드웨어 제어가 크지만 할당과 교체 속도는 느릴 수 있습니다.
가상화: 한 물리 호스트의 CPU, 메모리와 장치를 여러 격리된 실행 환경으로 나눕니다.
하이퍼바이저: 가상 머신의 하드웨어 접근과 격리를 관리합니다. 호스트 운영체제 위에서 실행되거나 하드웨어에 직접 올라갈 수 있습니다.
가상 머신: 가상 하드웨어와 자체 운영체제를 가진 실행 단위입니다. 격리가 강하고 범용적이지만 이미지 크기와 부팅 비용이 큽니다.
머신 이미지: 운영체제와 사전 설치된 소프트웨어를 담은 가상 머신 템플릿입니다. 버전과 패치 기준을 고정해야 재현 가능한 인스턴스를 만들 수 있습니다.
인스턴스 타입: CPU, 메모리, 가속기와 네트워크 성능의 조합입니다. 평균 사용률보다 병목과 피크 패턴을 기준으로 선택합니다.
컨테이너: 애플리케이션 프로세스와 의존성을 묶고 호스트 커널을 공유하는 격리된 실행 단위입니다. 가상 머신과 달리 자체 커널을 포함하지 않습니다.
컨테이너 이미지: 컨테이너 파일시스템과 실행 설정을 담은 읽기 전용 계층 묶음입니다. 태그는 바뀔 수 있으므로 배포 재현성에는 다이제스트가 더 정확합니다.
컨테이너 런타임: 이미지를 내려받고 컨테이너 프로세스, 파일시스템과 네트워크를 생성합니다. 오케스트레이터는 런타임 인터페이스를 통해 실행을 지시합니다.
레지스트리: 컨테이너 이미지를 저장하고 배포하는 서비스입니다. 접근 제어, 취약점 검사와 보존 정책이 소프트웨어 공급망에 포함됩니다.
네임스페이스: 프로세스, 네트워크와 마운트 같은 커널 자원의 관점을 분리합니다. 컨테이너 격리의 한 축입니다.
cgroup: 프로세스 그룹의 CPU, 메모리와 I/O 사용량을 제한하고 계측합니다. 자원 요청과 제한이 실제 런타임 제어로 이어지는 기반입니다.
서버리스: 서버 프로비저닝과 확장 관리의 더 많은 부분을 플랫폼에 맡기는 실행 모델입니다. 서버가 없는 것이 아니라 사용자에게 서버 수명주기가 드러나지 않는다는 뜻에 가깝습니다.
함수형 서비스: 이벤트나 요청마다 짧은 함수를 실행하는 서버리스 형태입니다. 실행 시간, 동시성, 콜드 스타트와 상태 저장 방식에 제약이 있습니다.
오토스케일링: 관측한 수요나 일정에 따라 인스턴스 수 또는 크기를 자동 조정합니다. 지표 지연과 기동 시간 때문에 급격한 부하를 항상 즉시 흡수하지는 못합니다.
수평 확장: 같은 역할의 인스턴스를 늘리거나 줄입니다. 상태 공유와 부하 분산이 가능해야 효과가 있습니다.
수직 확장: 한 인스턴스의 CPU와 메모리 크기를 키우거나 줄입니다. 단순하지만 상한과 재시작 요구가 있을 수 있습니다.

네트워크는 연결 가능성과 신뢰 경계를 함께 설계합니다

가상 네트워크: 클라우드 안에 논리적으로 격리된 주소 공간과 라우팅 경계를 만듭니다. 공급자에 따라 VPC나 VNet 같은 이름을 사용합니다.
CIDR: IP 주소 범위를 접두 길이로 표현합니다. 초기 주소 계획이 겹치면 네트워크 연결과 확장이 어려워집니다.
서브넷: 가상 네트워크의 주소 범위를 더 작은 배치 단위로 나눕니다. 가용 영역, 라우팅과 접근 정책의 경계로 사용합니다.
라우팅 테이블: 목적지 주소 범위마다 다음 경로를 정합니다. 공개 또는 비공개라는 이름보다 실제 경로와 게이트웨이 연결을 확인해야 합니다.
인터넷 게이트웨이: 가상 네트워크와 인터넷 사이의 경로를 제공합니다. 연결만으로 모든 자원이 공개되는 것은 아니며 주소와 방화벽 정책이 함께 필요합니다.
NAT: 주소를 변환해 비공개 주소의 자원이 외부로 나가게 하거나 연결을 공유합니다. 외부에서 시작한 연결을 허용하는 것과는 다릅니다.
방화벽과 보안 그룹: 출발지, 목적지, 포트와 프로토콜에 따라 트래픽을 허용하거나 차단합니다. 상태 추적 여부와 적용 단위를 확인해야 합니다.
로드 밸런서: 여러 대상에 요청을 분산하고 상태가 나쁜 대상을 제외합니다. L4는 연결 정보, L7은 HTTP 같은 애플리케이션 정보를 기준으로 판단합니다.
리버스 프록시: 클라이언트 대신 내부 서버와 통신하고 라우팅, TLS 종료, 압축과 인증 같은 공통 기능을 처리합니다.
서비스 디스커버리: 변하는 서비스 인스턴스의 주소를 이름이나 질의로 찾게 합니다. DNS, 레지스트리와 오케스트레이터 서비스 객체가 이 역할을 할 수 있습니다.
인그레스와 이그레스: 시스템으로 들어오는 트래픽과 밖으로 나가는 트래픽입니다. 두 방향의 허용 정책과 관측 지점은 서로 다릅니다.
CDN: 사용자와 가까운 엣지에 콘텐츠를 캐시하거나 요청을 중계합니다. 원본 보호와 성능에 도움이 되지만 캐시 키와 무효화가 운영 계약이 됩니다.
VPN: 암호화된 터널을 통해 떨어진 네트워크나 사용자를 사설 네트워크에 연결합니다. 라우팅 충돌과 신원 확인을 함께 설계해야 합니다.
전용 연결: 공용 인터넷과 분리된 회선이나 공급자 연결을 사용합니다. 예측 가능한 경로를 얻는 대신 비용과 이중화 구성이 필요합니다.
Private Endpoint: 관리형 서비스를 공개 주소 대신 가상 네트워크 내부 경로로 접근하게 합니다. DNS 해석과 리전별 지원 조건이 자주 문제를 만듭니다.
서비스 메시: 서비스 간 통신의 암호화, 라우팅과 관측을 프록시 계층에서 제공합니다. 애플리케이션 코드 부담을 줄이지만 데이터 플레인과 제어 플레인의 운영 비용이 생깁니다.

저장소와 데이터 서비스는 복구 기준부터 선택합니다

블록 스토리지: 고정 크기 블록 장치처럼 연결되는 저장소입니다. 파일시스템과 데이터베이스 디스크에 적합하며 일반적으로 한정된 연결 범위를 가집니다.
파일 스토리지: 디렉터리와 파일 인터페이스를 네트워크로 공유합니다. 여러 인스턴스가 같은 경로를 써야 할 때 유용하지만 잠금과 처리량 특성을 확인해야 합니다.
오브젝트 스토리지: 키와 메타데이터로 객체를 저장하고 HTTP API로 접근합니다. 대용량 비정형 데이터와 백업에 적합하지만 일반 파일시스템과 의미가 다릅니다.
임시 저장소: 인스턴스나 컨테이너 수명과 함께 사라질 수 있는 공간입니다. 캐시와 작업 파일에는 적합하지만 정본 데이터에 사용하면 안 됩니다.
영구 볼륨: 워크로드 수명과 분리해 유지되는 저장소입니다. 연결 가능 영역, 접근 모드와 스냅샷 정책을 확인해야 합니다.
스냅샷: 특정 시점의 볼륨이나 데이터 상태를 기록합니다. 애플리케이션 일관성을 보장하려면 쓰기 정지나 데이터베이스 기능과 조정해야 할 수 있습니다.
백업: 운영 원본과 분리된 복구용 사본입니다. 생성 성공보다 실제 복원 시험과 보존 기간이 중요합니다.
복제: 데이터를 다른 노드나 위치로 계속 복사해 가용성과 읽기 확장을 높입니다. 논리 오류와 삭제도 복제될 수 있어 백업을 대신하지 않습니다.
내구성: 저장된 데이터가 장기간 손실되지 않을 가능성입니다. 서비스가 지금 요청에 응답하는 가용성과 구분합니다.
RPO: 장애 뒤 허용할 수 있는 최대 데이터 손실 시점입니다. 백업과 복제 간격을 결정하는 업무 기준입니다.
RTO: 장애 뒤 서비스를 복구해야 하는 목표 시간입니다. 자동화, 인력과 데이터 복원 시간을 모두 포함합니다.
관리형 데이터베이스: 패치, 백업과 장애 조치 일부를 공급자가 운영합니다. 스키마, 쿼리, 용량, 접근 제어와 복구 검증은 여전히 사용자의 책임입니다.
캐시 서비스: 자주 읽는 데이터와 계산 결과를 빠른 저장소에 둡니다. 만료, 무효화와 원본 장애 시 동작을 정해야 합니다.
메시지 큐: 생산자와 소비자의 처리 시점을 분리하고 부하를 완충합니다. 전달 보장, 순서, 중복 처리와 재시도 정책이 계약의 핵심입니다.
데이터 레지던시: 데이터가 저장되고 처리되는 지리적 위치에 대한 요구입니다. 백업, 로그와 지원 시스템의 위치도 범위에 포함될 수 있습니다.

IaC는 인프라 변경을 검토 가능한 선언으로 바꿉니다

Infrastructure as Code: 인프라 구성을 코드와 같은 파일로 정의하고 버전 관리와 자동화를 적용합니다. 콘솔 클릭의 기록을 남기는 것보다 재현 가능한 변경 계약을 만드는 데 목적이 있습니다.
선언형 구성: 원하는 최종 상태를 표현하고 도구가 현재 상태와의 차이를 계산합니다. 작업 순서를 직접 나열하는 명령형 방식과 대비됩니다.
리소스: IaC 도구가 수명주기를 관리하는 네트워크, 서버와 정책 같은 단위입니다. 실제 공급자 객체와 상태의 대응 관계가 필요합니다.
프로바이더: IaC 도구가 특정 서비스 API와 통신하게 하는 플러그인입니다. 버전 변경이 계획 결과와 스키마에 영향을 줄 수 있습니다.
모듈: 여러 리소스를 재사용 가능한 입력과 출력의 묶음으로 캡슐화합니다. 너무 많은 선택지를 노출하면 표준화 효과가 줄어듭니다.
상태 파일: 선언과 실제 원격 객체의 대응 정보를 저장합니다. 동시 수정 방지, 암호화와 접근 제어가 필요하며 비밀값이 포함될 가능성도 확인해야 합니다.
계획: 적용 전에 생성, 변경과 삭제될 자원을 미리 계산한 결과입니다. 검토 시 교체와 삭제뿐 아니라 권한 확대와 비용 변화도 봐야 합니다.
적용: 승인된 계획을 공급자 API에 실행해 실제 상태를 바꿉니다. 중간 실패 뒤 다시 실행할 때의 수렴 동작을 알아야 합니다.
드리프트: 선언된 상태와 실제 상태가 달라진 상황입니다. 긴급 수동 변경도 코드에 되돌려 기록하지 않으면 다음 적용에서 사라지거나 충돌합니다.
멱등성: 같은 선언을 반복 적용해도 추가 변경 없이 같은 상태에 수렴하는 성질입니다. 안정적인 자동화의 기본 조건입니다.
불변 인프라: 실행 중인 서버를 계속 수정하기보다 새 이미지와 인스턴스로 교체합니다. 재현성과 롤백은 좋아지지만 상태를 외부로 분리해야 합니다.
구성 관리: 운영체제와 애플리케이션 설정을 원하는 상태로 맞춥니다. 이미지 빌드와 시작 시 구성 중 어느 단계가 책임지는지 구분해야 합니다.
비밀 관리: 암호, 토큰과 키를 코드와 일반 설정에서 분리해 저장, 배포, 감사와 회전을 관리합니다. 저장 암호화만으로 로그와 프로세스 인자의 노출까지 막지는 못합니다.
Policy as Code: 허용할 구성과 배포 조건을 기계적으로 검사하는 정책입니다. 예방 검사와 운영 중 탐지를 함께 설계합니다.
GitOps: 버전 관리된 선언을 정본으로 삼고 에이전트가 원하는 상태를 가져와 실제 상태와 계속 조정합니다. 단순히 배포 명령을 Git 저장소에서 실행하는 것보다 좁고 명확한 원칙입니다.
리컨실리에이션: 제어 루프가 현재 상태를 관찰하고 원하는 상태와의 차이를 반복해서 줄이는 과정입니다. 한 번 실행되는 스크립트와 다른 운영 모델입니다.

컨테이너 오케스트레이션은 원하는 상태를 계속 유지합니다

클러스터: 여러 노드와 제어 구성 요소를 하나의 실행 자원 풀로 묶습니다. 클러스터 자체도 네트워크, 업그레이드와 장애 복구가 필요한 시스템입니다.
컨트롤 플레인: API, 스케줄링과 제어 루프로 클러스터의 원하는 상태를 관리합니다. 워크로드 데이터 경로와 분리해 생각합니다.
노드: 워크로드가 실제로 실행되는 머신입니다. 컨테이너 런타임, 네트워크와 노드 에이전트가 필요합니다.
Pod: Kubernetes에서 함께 배치되고 네트워크와 일부 저장소를 공유하는 최소 배포 단위입니다. 컨테이너 하나와 동의어는 아닙니다.
Deployment: 상태 없는 Pod 복제본의 선언, 갱신과 롤백을 관리합니다. 새 버전 전환은 ReplicaSet을 통해 이루어집니다.
StatefulSet: 안정된 이름, 순서와 볼륨 연결이 필요한 상태 있는 워크로드를 관리합니다. 데이터베이스 운영 지식까지 자동으로 제공하지는 않습니다.
DaemonSet: 선택된 각 노드에 Pod를 하나씩 실행합니다. 로그 수집기와 노드 네트워크 에이전트처럼 노드별 기능에 사용합니다.
Job과 CronJob: 완료를 목표로 하는 배치 작업과 일정 기반 작업을 실행합니다. 중복 실행과 실패 재시도에 대비해 작업 자체도 멱등하게 설계해야 합니다.
Service: 바뀌는 Pod 집합에 안정된 네트워크 주소와 서비스 디스커버리를 제공합니다. 외부 공개 방식과 내부 라우팅 방식을 구분합니다.
Ingress와 Gateway: 클러스터 외부의 HTTP 트래픽을 내부 서비스로 라우팅합니다. 리소스 정의와 실제 동작을 수행하는 컨트롤러가 함께 필요합니다.
ConfigMap과 Secret: 이미지 밖에서 구성과 민감 값을 워크로드에 전달합니다. Secret이라는 이름만으로 저장과 노출 경로가 자동으로 안전해지는 것은 아닙니다.
PV와 PVC: 저장소 공급과 워크로드의 저장소 요청을 분리합니다. 수명주기, 접근 모드와 회수 정책이 데이터 보존에 영향을 줍니다.
스케줄러: 자원 요청, 제약과 선호도를 바탕으로 새 Pod를 실행할 노드를 선택합니다. 실제 실행 성공과 애플리케이션 정상 상태까지 보장하지는 않습니다.
컨트롤러: 특정 리소스의 원하는 상태와 실제 상태를 관찰하고 차이를 조정합니다. Kubernetes의 자동 복구는 여러 컨트롤러의 반복 동작에서 나옵니다.
자원 요청: 스케줄링을 위해 워크로드가 필요하다고 선언한 CPU와 메모리 양입니다. 너무 낮으면 과밀 배치, 너무 높으면 자원 낭비가 생깁니다.
자원 제한: 워크로드가 사용할 수 있는 최대 자원을 정합니다. CPU 제한은 스로틀링, 메모리 제한 초과는 종료로 이어질 수 있습니다.
Liveness Probe: 프로세스를 다시 시작해야 할 정도로 복구 불가능한 상태인지 확인합니다. 외부 의존성의 일시 장애를 넣으면 불필요한 재시작이 확산될 수 있습니다.
Readiness Probe: 현재 요청을 받을 준비가 됐는지 확인해 트래픽 대상에 포함할지를 결정합니다. 재시작 여부와는 다른 질문입니다.
Startup Probe: 시작이 느린 애플리케이션에 초기화 시간을 따로 허용합니다. 시작 중 liveness 실패로 반복 재시작되는 문제를 막습니다.

CI는 변경을 검증된 산출물로 만듭니다

버전 관리: 코드, 설정과 문서의 변경 이력을 기록합니다. 배포된 상태를 특정 커밋과 연결할 수 있어야 복구와 감사가 가능합니다.
브랜치 전략: 변경을 분리하고 합치는 규칙입니다. 브랜치 수보다 변경 크기, 통합 빈도와 운영 반영 경로가 더 중요합니다.
트렁크 기반 개발: 작은 변경을 주 브랜치에 자주 통합하고 미완성 기능은 다른 방식으로 숨깁니다. 오래 살아 있는 브랜치의 병합 위험을 줄입니다.
코드 리뷰: 변경의 정확성, 보안과 유지보수성을 다른 사람이 확인합니다. 자동 검사는 형식과 반복 규칙을 맡고 사람은 의도와 설계를 봅니다.
CI: 변경마다 빌드, 정적 분석과 테스트를 자동 실행해 통합 문제를 빠르게 찾습니다. 녹색 상태가 실제 배포 가능성을 의미하도록 환경 차이를 줄여야 합니다.
빌드: 소스와 의존성을 실행 가능한 산출물로 변환합니다. 같은 입력에서 같은 결과를 만드는 재현 가능성이 공급망 검증에 중요합니다.
의존성 잠금: 직접 및 간접 의존성의 정확한 버전을 기록합니다. 선언 범위만 있고 잠금이 없으면 같은 소스도 다른 결과를 만들 수 있습니다.
테스트 피라미드: 빠르고 작은 테스트를 기반으로 통합과 E2E 테스트를 필요한 만큼 올리는 구성입니다. 층의 이름보다 피드백 속도와 실제 위험의 균형이 목적입니다.
정적 분석: 실행하지 않고 코드의 오류 패턴, 타입과 보안 문제를 검사합니다. 실제 런타임과 구성에서만 생기는 문제는 별도 검증이 필요합니다.
아티팩트: 빌드가 만든 바이너리, 패키지와 이미지 같은 배포 단위입니다. 환경마다 다시 빌드하지 않고 같은 산출물을 승격하는 편이 추적에 유리합니다.
아티팩트 저장소: 버전별 산출물을 보존하고 접근과 수명주기를 관리합니다. 소스 저장소와 목적이 다릅니다.
SBOM: 산출물에 포함된 구성 요소와 버전을 기계가 읽을 수 있게 나열합니다. 취약점 영향 범위와 라이선스 검토의 입력이 됩니다.
서명과 출처 증명: 산출물이 누가 어떤 빌드 과정에서 만들었는지 검증할 단서를 제공합니다. 파일 해시만으로 신뢰할 빌더까지 확인할 수는 없습니다.
파이프라인: 빌드, 검증, 승인과 배포 단계를 자동으로 연결한 흐름입니다. 자격 증명 범위와 외부 기여 코드의 실행 경계를 분리해야 합니다.
빌드 캐시: 변하지 않은 중간 결과를 재사용해 피드백 시간을 줄입니다. 캐시 키가 부정확하면 오래된 결과나 다른 환경의 산출물이 섞일 수 있습니다.

CD는 같은 산출물을 작은 위험 단위로 전달합니다

Continuous Delivery: 모든 변경을 배포 가능한 상태로 유지하고 운영 반영에는 명시적인 승인 단계를 둘 수 있습니다.
Continuous Deployment: 검증을 통과한 변경을 사람의 개별 승인 없이 운영까지 자동 반영합니다. 자동화 수준보다 실패를 빠르게 감지하고 멈추는 능력이 중요합니다.
환경: 개발, 검증과 운영처럼 서로 다른 구성과 사용 목적을 가진 실행 경계입니다. 환경 차이가 클수록 이전 단계의 검증 신뢰도가 낮아집니다.
승격: 이미 검증된 동일 산출물을 다음 환경으로 이동합니다. 환경별 재빌드는 소스와 운영 결과의 대응을 흐립니다.
Rolling 배포: 기존 인스턴스를 조금씩 새 버전으로 교체합니다. 두 버전이 동시에 실행되는 동안 API와 데이터 스키마가 호환돼야 합니다.
Blue-Green 배포: 구버전과 신버전 환경을 나란히 준비하고 트래픽을 전환합니다. 빠른 복귀가 가능하지만 이중 자원과 공유 데이터 변경을 관리해야 합니다.
Canary 배포: 일부 트래픽이나 사용자에게 새 버전을 먼저 노출합니다. 성공 기준, 관찰 시간과 자동 중단 조건이 없으면 단순한 부분 배포에 그칩니다.
점진적 전달: 노출 범위를 단계적으로 늘리고 지표에 따라 계속 진행하거나 되돌립니다. 배포 기술과 제품 기능 노출을 함께 다룰 수 있습니다.
기능 플래그: 코드 배포와 기능 공개 시점을 분리합니다. 오래된 플래그는 분기와 테스트 조합을 늘리므로 소유자와 제거 시점을 둬야 합니다.
데이터베이스 마이그레이션: 스키마와 데이터를 새 코드가 요구하는 형태로 바꿉니다. 여러 버전이 함께 실행될 수 있도록 확장, 전환, 정리 단계를 나누는 편이 안전합니다.
하위 호환성: 새 생산자나 소비자가 이전 계약과 함께 동작하는 성질입니다. API, 이벤트와 데이터베이스를 독립적으로 배포하려면 필요합니다.
롤백: 이전 애플리케이션 버전이나 구성으로 되돌립니다. 되돌릴 수 없는 데이터 변경과 외부 부작용 때문에 항상 가능한 것은 아닙니다.
롤포워드: 문제를 고친 새 버전을 앞으로 배포합니다. 데이터 마이그레이션이 이미 진행됐거나 복귀 비용이 큰 경우 더 현실적일 수 있습니다.
배포 동결: 특정 기간에 변경 위험을 줄이기 위해 운영 반영을 제한합니다. 작은 보안 수정과 복구 능력까지 함께 얼리지 않도록 예외 기준이 필요합니다.
변경 승인: 위험도와 정책에 따라 자동 또는 사람의 검토를 요구합니다. 모든 변경에 같은 절차를 적용하기보다 증거와 영향 범위에 비례해야 합니다.

신뢰성은 실패를 없애는 대신 영향 범위를 제한합니다

가용성: 사용자가 필요한 시점에 서비스가 정상 기능을 제공하는 비율입니다. 프로세스가 살아 있다는 사실만으로 업무 기능의 가용성을 보장하지 않습니다.
중복성: 한 구성 요소가 실패해도 대체할 복제본과 경로를 둡니다. 같은 장애 도메인에 놓인 복제본은 공통 실패를 피하지 못합니다.
고가용성: 계획된 작업과 일부 장애 중에도 목표 수준의 서비스를 유지하는 설계와 운영입니다. 복제 수 하나로 완성되지 않습니다.
장애 도메인: 하나의 사건으로 함께 실패할 수 있는 자원의 범위입니다. 호스트, 랙, 가용 영역, 리전과 외부 공급자가 서로 다른 층의 도메인이 됩니다.
단일 장애점: 하나의 구성 요소 실패가 전체 서비스 중단으로 이어지는 지점입니다. 기술 구성뿐 아니라 한 사람만 아는 복구 절차도 단일 장애점입니다.
타임아웃: 응답을 무한히 기다리지 않고 실패로 판단할 시간 한계를 정합니다. 호출 계층마다 남은 시간 예산을 전달해야 불필요한 작업이 줄어듭니다.
재시도: 일시 실패 뒤 같은 작업을 다시 시도합니다. 멱등하지 않은 작업, 과부하와 긴 장애에서는 피해를 키울 수 있습니다.
지수 백오프와 지터: 재시도 간격을 점점 늘리고 무작위성을 더해 많은 클라이언트가 동시에 다시 몰리는 현상을 줄입니다.
서킷 브레이커: 연속 실패가 일정 수준을 넘으면 호출을 잠시 중단해 의존성과 호출자를 보호합니다. 복구 확인을 위한 반개방 상태가 필요합니다.
벌크헤드: 자원 풀과 동시성 한도를 분리해 한 기능의 과부하가 전체 서비스로 번지는 것을 막습니다.
부하 차단: 처리 능력을 넘을 때 일부 요청을 빠르게 거절해 핵심 기능을 유지합니다. 무제한 큐에 쌓아 모두 늦게 실패시키는 것과 다릅니다.
레이트 리밋: 사용자, 키나 작업 유형별 요청 속도를 제한합니다. 공정성, 비용과 남용 방지 목적에 따라 알고리즘과 응답 계약이 달라집니다.
백프레셔: 소비자가 처리할 수 있는 속도를 생산자에게 전달해 데이터와 작업이 무한히 쌓이지 않게 합니다.
점진적 성능 저하: 일부 의존성이 실패할 때 전체 중단 대신 캐시, 읽기 전용과 제한된 기능으로 핵심 경로를 남깁니다.
재해 복구: 큰 장애 뒤 데이터와 서비스를 다른 자원에서 복원하는 계획입니다. 문서가 아니라 정기적인 복구 연습으로 검증해야 합니다.
카오스 엔지니어링: 통제된 실패를 주입해 시스템과 운영 가설을 검증합니다. 안전 범위, 중단 조건과 관측 없이 운영 장애를 만드는 행위와는 다릅니다.

관측성은 시스템 출력에서 내부 상태를 추론하게 합니다

텔레메트리: 시스템이 동작하면서 내보내는 로그, 메트릭, 트레이스와 프로파일 같은 데이터입니다.
계측: 애플리케이션과 인프라가 필요한 텔레메트리를 만들도록 코드를 넣거나 자동 연결하는 과정입니다.
로그: 특정 시점의 사건을 문맥과 함께 기록합니다. 구조화된 필드와 요청 식별자가 검색과 상관관계를 높입니다.
메트릭: 시간에 따른 수치를 집계한 신호입니다. 전체 추세와 경보에 적합하지만 개별 요청의 경로를 그대로 보여 주지는 않습니다.
트레이스: 한 요청이 여러 서비스와 작업을 통과한 경로를 Span의 부모 자식 관계로 연결합니다.
Span: 트레이스 안의 한 작업 구간입니다. 시작과 종료 시각, 상태와 속성을 담습니다.
문맥 전파: 요청과 메시지 경계를 넘어 Trace ID 같은 상관 정보를 전달합니다. 비동기 큐와 외부 호출에서 끊기기 쉽습니다.
카디널리티: 메트릭 레이블이 가질 수 있는 고유 값의 수입니다. 사용자 ID와 요청 ID를 레이블로 넣으면 저장 비용과 질의 부하가 급격히 커질 수 있습니다.
샘플링: 모든 트레이스를 저장하지 않고 일부를 선택합니다. 비용은 줄지만 드문 오류와 느린 요청을 놓치지 않도록 선택 기준이 필요합니다.
대시보드: 여러 지표를 한 화면에 배치해 현재 상태와 추세를 봅니다. 보기 좋은 그래프보다 실제 운영 질문에 답하는 구성이 중요합니다.
경보: 즉각적인 행동이 필요한 조건을 사람이나 자동화에 알립니다. 원인 후보가 아니라 사용자 영향과 조치 가능성을 기준으로 설계합니다.
SLI: 성공률과 지연처럼 서비스 동작을 실제로 측정한 지표입니다. 사용자가 경험하는 기능에 가깝게 정의해야 합니다.
SLO: 일정 기간에 SLI가 달성해야 할 목표입니다. 모든 요청의 완벽함보다 허용 가능한 신뢰성 경계를 명시합니다.
SLA: 공급자와 고객 사이의 서비스 수준 약속입니다. SLO와 달리 위반 시 보상이나 계약상 결과가 연결될 수 있습니다.
오류 예산: SLO를 지키면서 허용되는 실패량입니다. 기능 배포 속도와 신뢰성 작업의 우선순위를 같은 기준에서 논의하게 합니다.
온콜: 정해진 시간에 운영 경보와 사고에 대응하는 책임 체계입니다. 개인의 희생보다 인계, 에스컬레이션과 지속 가능한 빈도를 설계해야 합니다.
인시던트: 서비스 품질이나 보안에 의미 있는 영향을 준 사건입니다. 탐지, 완화, 복구와 커뮤니케이션의 역할을 분리하면 대응이 선명해집니다.
런북: 알려진 운영 작업을 수행하는 구체적인 절차입니다. 명령만 나열하지 않고 전제, 확인과 되돌리기 방법을 포함합니다.
포스트모템: 사고 뒤 원인과 기여 조건, 탐지와 대응 과정을 검토하고 개선 작업을 정합니다. 개인 비난보다 시스템이 왜 그 행동을 허용했는지 봅니다.

보안과 거버넌스는 모든 자동화 경로에 들어갑니다

IAM: 사람과 워크로드의 신원, 역할과 권한을 관리하는 체계입니다. 계정 생성부터 변경, 폐기와 감사까지 수명주기를 포함합니다.
인증: 요청 주체가 누구인지 확인합니다. 사람 로그인과 서비스 워크로드의 신원 발급은 서로 다른 흐름이 필요합니다.
인가: 인증된 주체가 어떤 자원에 무슨 행동을 할 수 있는지 결정합니다. 거부를 기본값으로 두고 필요한 권한을 명시합니다.
RBAC: 역할에 권한을 묶고 사용자와 서비스에 역할을 부여합니다. 역할 수가 지나치게 늘어나지 않도록 업무 단위로 설계합니다.
ABAC: 주체, 자원과 요청의 속성을 정책 조건으로 사용합니다. 세밀하지만 정책 충돌과 설명 가능성을 관리해야 합니다.
최소 권한: 작업에 필요한 범위와 시간만 권한을 부여합니다. 장기 관리자 키보다 짧게 발급되는 제한된 자격 증명이 피해 범위를 줄입니다.
워크로드 아이덴티티: 애플리케이션 인스턴스가 고정 키 없이 플랫폼 신원으로 다른 서비스에 접근하게 합니다. 자격 증명 배포와 회전 부담을 줄입니다.
KMS: 암호화 키의 생성, 저장, 사용 권한과 회전을 관리합니다. 데이터 접근 권한과 키 사용 권한을 분리할 수 있습니다.
봉투 암호화: 데이터는 데이터 키로 암호화하고 데이터 키는 상위 키로 다시 보호합니다. 대용량 데이터마다 중앙 키 서비스를 호출하는 비용을 줄입니다.
네트워크 분할: 서비스와 데이터의 통신 범위를 필요한 경로로 제한합니다. 내부 네트워크라는 이유만으로 모든 연결을 신뢰하지 않습니다.
제로 트러스트: 네트워크 위치를 자동 신뢰하지 않고 요청마다 신원, 장치, 정책과 문맥을 확인하는 원칙입니다.
취약점 관리: 자산과 의존성의 취약점을 찾고 실제 노출과 영향에 따라 수정 우선순위를 정합니다. 검사 결과 개수만으로 위험을 판단하지 않습니다.
패치 관리: 운영체제, 런타임과 의존성 업데이트를 검증하고 배포합니다. 불변 이미지와 자동 재빌드가 오래된 인스턴스를 줄이는 데 도움이 됩니다.
공급망 보안: 소스, 의존성, 빌드 시스템, 아티팩트와 배포 권한의 신뢰 경계를 보호합니다. 운영 서버만 잠그는 것으로 충분하지 않습니다.
감사 로그: 누가 언제 어떤 자원과 정책을 바꿨는지 기록합니다. 일반 애플리케이션 로그와 분리해 변조 방지와 보존 정책을 둡니다.
가드레일: 위험한 선택을 사전에 막거나 안전한 기본값으로 유도하는 자동 정책입니다. 모든 변경을 수동 승인으로 보내는 것보다 빠른 피드백을 제공합니다.

비용과 플랫폼 운영은 기술 선택을 지속 가능하게 만듭니다

FinOps: 클라우드의 가변 비용을 엔지니어링, 재무와 제품이 함께 관찰하고 최적화하는 운영 방식입니다. 단순한 비용 절감보다 가치와 책임의 연결이 목적입니다.
CapEx와 OpEx: 설비를 미리 구매하는 자본 지출과 사용 기간에 따라 내는 운영 지출을 구분합니다. 클라우드는 비용 형태를 바꾸지만 장기 총비용을 자동으로 낮추지는 않습니다.
가격 단위: 실행 시간, 요청 수, 저장 용량, I/O와 네트워크 전송처럼 과금의 기준이 되는 단위입니다. 아키텍처의 데이터 흐름과 직접 연결됩니다.
태그와 라벨: 자원에 팀, 환경, 서비스와 비용 중심 정보를 붙입니다. 일관된 규칙이 없으면 비용 배분과 자산 검색에 쓸 수 없습니다.
비용 할당: 공유 자원 비용을 서비스, 팀과 제품에 나눕니다. 정확한 청구보다 의사결정에 충분한 일관성이 먼저 필요할 수 있습니다.
라이트사이징: 실제 사용 패턴에 맞춰 인스턴스와 데이터베이스 크기를 조정합니다. 평균 CPU 하나가 아니라 메모리, I/O와 피크를 함께 봅니다.
예약 할인: 일정 사용량이나 기간을 약정해 단가를 낮춥니다. 잘못 예측하면 사용하지 않는 약정이 고정 비용이 됩니다.
스팟 자원: 공급자가 회수할 수 있는 여유 용량을 낮은 가격에 사용합니다. 중단 가능한 배치와 분산 워크로드에 맞습니다.
네트워크 이그레스 비용: 클라우드나 리전을 벗어나는 데이터 전송에 붙는 비용입니다. 저장 단가보다 데이터 이동이 전체 비용을 지배할 수 있습니다.
단위 비용: 사용자, 요청, 주문과 모델 추론 한 건처럼 제품 가치 단위당 드는 비용입니다. 전체 청구액을 성장과 효율 변화로 나눠 볼 수 있습니다.
플랫폼 엔지니어링: 개발 팀이 안전하게 소프트웨어를 전달하도록 공통 도구와 내부 플랫폼을 제품처럼 운영합니다. 인프라 팀의 티켓 창구를 새 이름으로 바꾸는 것과 다릅니다.
내부 개발자 플랫폼: 배포, 관측, 권한과 자원 요청을 일관된 인터페이스로 제공합니다. 기반 도구를 숨기는 것보다 필요한 제어와 피드백을 적절한 수준으로 노출합니다.
골든 패스: 조직에서 검증한 기본 아키텍처와 배포 경로입니다. 강제되는 유일한 길이 아니라 대부분의 팀이 가장 쉽게 선택할 수 있는 안전한 기본값이어야 합니다.
셀프서비스: 개발 팀이 정책 안에서 환경, 데이터베이스와 배포를 직접 요청하고 확인합니다. 자동화와 함께 소유권, 비용과 만료 규칙이 필요합니다.
DORA 지표: 소프트웨어 전달의 처리량과 불안정성을 배포 빈도, 변경 리드 타임, 실패 배포 복구 시간, 변경 실패율과 배포 재작업률로 봅니다. 한 서비스의 추세를 개선하는 데 사용하고 팀 순위표로 단순화하지 않습니다.

한 번의 변경이 운영에 도착하는 순서

코드와 IaC 변경
  -> 리뷰와 CI 검증
  -> 재현 가능한 아티팩트 생성
  -> 서명, SBOM과 레지스트리 보관
  -> 검증 환경으로 같은 아티팩트 승격
  -> 점진적 운영 배포
  -> 로그, 메트릭과 트레이스 관찰
  -> SLO와 배포 기준으로 계속 진행 또는 복구
  -> 실제 상태와 선언의 차이 조정
  -> 비용, 신뢰성과 전달 지표를 다음 변경에 반영

DevOps의 핵심은 도구를 많이 설치하는 일이 아니라 이 피드백 경로를 짧고 안전하게 만드는 데 있습니다. 개발자는 운영 결과를 보고, 운영 규칙은 코드와 자동화로 개발 시점에 돌아와야 합니다. 배포가 느리면 승인 단계만 탓하지 않고 빌드 재현성, 테스트 신뢰도, 환경 차이와 복구 능력을 함께 봅니다.

처음 공부한다면 이 순서가 좋습니다

프로세스, 네트워크, DNS, 파일시스템과 데이터베이스로 한 서버의 기본 동작을 익힙니다.
가상 머신과 컨테이너의 격리 방식, 이미지와 런타임의 차이를 확인합니다.
리전, 가용 영역, 가상 네트워크, 로드 밸런서와 저장소로 클라우드 자원 지도를 만듭니다.
Git, CI, 아티팩트와 레지스트리로 소스가 배포 단위가 되는 흐름을 구성합니다.
IaC의 선언, 상태, 계획, 드리프트와 멱등성을 작은 환경에서 실습합니다.
Rolling, Blue-Green과 Canary 배포를 데이터베이스 호환성 및 복구 방식과 함께 비교합니다.
타임아웃, 재시도, 백프레셔와 장애 도메인으로 부분 실패를 다룹니다.
로그, 메트릭, 트레이스와 SLO를 연결한 뒤 Kubernetes와 GitOps를 학습합니다.

Kubernetes를 너무 일찍 시작하면 Pod와 Service의 이름은 외워도 그 아래의 프로세스, 네트워크, 저장소와 제어 루프를 놓치기 쉽습니다. 작은 애플리케이션을 가상 머신이나 관리형 플랫폼에 먼저 배포하고, 운영 문제가 어떤 자동화를 요구하는지 본 뒤 오케스트레이션으로 넘어가도 늦지 않습니다.

이 문서는 독립적인 심화 글의 허브입니다

이후의 심화 글은 순서 없이 각 문서만 읽어도 이해되도록 작성하고 cloud-devops-core-concepts 태그로 연결합니다. 새 글이 발행되면 이 문서의 관련 개념에도 직접 링크를 추가합니다.

먼저 확장하기 좋은 주제는 다음과 같습니다.

가상 머신과 컨테이너: 커널과 격리 경계의 차이
VPC 네트워크: 서브넷, 라우팅, NAT와 보안 그룹
IaC 상태 관리: 계획, 드리프트와 안전한 적용
Kubernetes 제어 루프: 원하는 상태가 유지되는 과정
CI/CD: 소스에서 검증된 아티팩트와 배포까지
무중단 배포: Rolling, Blue-Green과 Canary의 선택 기준
신뢰성 패턴: 타임아웃, 재시도, 서킷 브레이커와 백프레셔
관측성: 로그, 메트릭과 트레이스를 연결하는 방법
SLO와 오류 예산: 신뢰성과 배포 속도를 함께 결정하는 기준
클라우드 비용: 리소스 단가에서 제품 단위 비용까지