로컬에서 프로그램이 실행된다고 사용자에게 서비스를 제공할 준비가 끝난 것은 아닙니다. 실행할 컴퓨터, 설정과 자격, 네트워크 주소, 저장소가 필요하고 업데이트와 장애도 견뎌야 합니다. 인프라와 운영은 코드가 실제 요청을 지속해서 처리할 수 있도록 이 환경을 구성하고 관리하는 분야입니다.
운영은 프로그램을 실행하는 데서 끝나지 않고, 요청을 받을 수 있는 상태인지 확인하고, 용량을 통제하고, 실패 뒤 목표 지점까지 복구하는 일까지 포함합니다. 배포의 각 단계와 사용자 결과를 하나의 흐름으로 보되 성공 신호는 분리합니다.
실행 산출물과 환경
소스 코드를 빌드하면 실행 파일이나 패키지, 컨테이너 이미지 같은 산출물이 생깁니다. 배포는 그 산출물을 실행 환경에 놓고 설정과 자원을 연결하는 과정입니다. 이미지가 같아도 설정, 외부 API, 데이터 상태가 다르면 결과가 달라질 수 있습니다.
컨테이너는 실행 환경을 묶고 격리하는 수단이지만 별도 컴퓨터와 완전히 같은 경계는 아닙니다. 사용하는 런타임과 운영체제, 권한 설정에 따라 실제 격리가 달라집니다. 패키지가 설치됐다는 사실과 서비스가 정상 요청을 처리한다는 사실도 구분해야 합니다.
같은 이미지라도 config, 외부 의존성, 데이터 schema, 권한이 달라지면 실제 동작은 달라집니다. 따라서 배포 기록에는 artifact digest와 함께 설정 버전·환경 식별자·migration 상태를 남기고, “이미지가 올라갔다”와 “업무 요청이 성공했다”를 별도 신호로 둡니다.
트래픽과 준비 상태
사용자 요청은 이름 해석과 네트워크 연결, 프록시나 로드밸런서를 거쳐 앱에 도착할 수 있습니다. 앱이 실행됐어도 설정을 읽거나 DB 연결을 준비하는 중이라면 아직 트래픽을 받으면 안 될 수 있습니다.
그래서 생존 확인과 준비 확인을 나눕니다. 프로세스가 응답하는지 보는 검사와 실제 새 요청을 받을 수 있는지 보는 검사는 목적이 다릅니다. 모든 외부 시스템의 장애를 프로세스 재시작으로 처리하면 재시작만 반복할 수 있습니다.
그림을 글로 읽기
- 검증된 실행 산출물
- 설정·자원 연결·프로세스 시작
- 초기화·요청 처리 준비
- 트래픽 수락·실제 결과 관측
- 검증된 실행 산출물 → 설정·자원 연결·프로세스 시작: 배포
- 설정·자원 연결·프로세스 시작 → 초기화·요청 처리 준비: 초기화
- 초기화·요청 처리 준비 → 트래픽 수락·실제 결과 관측: 수락
프로세스가 살아 있어도 DB pool 초기화가 끝나지 않았으면 readiness는 false일 수 있습니다. 반대로 외부 DB가 잠시 장애라고 매번 liveness 실패를 내면 재시작 폭풍이 생깁니다. liveness는 프로세스 회복 판단, readiness는 새 트래픽 수락 판단으로 실패 원인과 대응을 나눕니다.
용량과 대기열
초당 100개가 도착하는데 서비스가 초당 80개만 끝내고 거절·취소되는 작업도 없다면, 미처리 작업은 초당 20개씩 늘어납니다. 큐는 잠깐의 몰림을 흡수할 수 있지만 지속적인 용량 부족을 없애지는 않습니다. 큐가 무제한이면 메모리와 대기 시간이 계속 증가할 수 있습니다.
앱 인스턴스를 늘려도 모두 같은 DB를 기다린다면 DB의 처리량은 그대로입니다. 인스턴스마다 연결 풀을 20개씩 가지면 10개 인스턴스는 최대 200개 연결을 요구할 수 있습니다. 확장은 한 계층의 숫자를 늘리는 것보다 전체 요청 경로의 병목과 총량을 확인하는 문제입니다.
도착률 100, 처리율 80이면 큐는 초당 20씩 증가하고, 평균 대기 시간도 유한한 buffer를 지나 계속 커집니다. queue length만 늘리는 것은 용량 부족의 해결이 아니므로, 최대 queue bytes·요청 deadline·거절 정책·하위 DB connection budget을 함께 정합니다.
원하는 상태와 실제 상태
운영자는 ‘앱 3개 실행’처럼 원하는 상태를 선언할 수 있습니다. 조정자는 현재 실행 수와 비교해 부족한 작업을 만듭니다. 중간에 재시작해도 현재 상태를 다시 읽어 차이를 줄일 수 있어야 합니다. Kubernetes의 controller는 이 조정 구조의 한 사례입니다.
선언이 저장됐다고 실제 상태가 즉시 같아지지는 않습니다. 노드 부족, 이미지 다운로드, 볼륨 연결, 앱 초기화가 각각 지연될 수 있습니다. 따라서 접수·생성·실행·준비·실제 처리 완료를 하나의 성공 표시로 합치지 않습니다.
원하는 replica 3을 기록한 뒤 실제 상태가 0→image pulling→running→ready로 변하는 시간을 구분합니다. controller가 재시작해도 원하는 상태를 다시 읽고 조정해야 하며, 선언 저장 성공을 실제 사용자 트래픽 준비 완료로 표시하지 않습니다.
서비스 수준과 복구
사용자에게 중요한 것은 프로세스 생존보다 올바른 결과와 응답 시간입니다. 이를 측정한 지표를 SLI, 목표를 SLO라고 부릅니다. 잘못된 비밀번호의 정상 거절과 용량 부족으로 정상 사용자를 막은 실패는 같은 의미가 아닙니다.
백업 파일이 있어도 복원할 키와 절차가 없으면 복구하지 못합니다. 데이터를 어느 시점까지 복구해야 하는지 정하는 RPO와, 서비스를 복구하는 데 허용할 목표 시간인 RTO를 정하고 실제 복원 과정으로 확인해야 합니다. 예를 들어 RPO 5분은 장애 직전 최대 5분 분량의 변경 유실을 허용한다는 목표이지, 백업이 있다는 이유만으로 달성되는 보장은 아닙니다. 배포를 되돌리는 것도 이미 변경된 데이터까지 자동 복원하는 일은 아닙니다.
SLI는 요청 성공률·유효성·지연처럼 사용자 결과를 측정하고 SLO는 그 목표입니다. RPO 5분과 RTO 30분을 정했다면 실제 백업 복원에서 데이터 시점과 서비스 복귀 시각을 각각 확인해야 합니다. 롤백은 코드 경로를 되돌릴 뿐 schema와 이미 발생한 외부 효과를 자동으로 되돌리지 않습니다.
세부 학습 경로
재현 가능한 이미지, Kubernetes 조정, 준비 상태, 자원 예산으로 실행 환경을 살펴볼 수 있습니다. 측정과 대응은 SLO와 복구로 이어집니다.
학습 순서는 산출물→준비→조정→자원 예산→SLO·복구로 읽으면 좋습니다. 각 링크의 세부 구현은 이 기초 장의 “어떤 상태를 성공으로 볼 것인가”라는 질문을 구체화하며, 여기서는 링크 대상 내용을 반복하지 않습니다.