이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Web Operations는 어떤 순서로 학습해야 실전 운영 능력으로 이어지는가?
- 각 단계에서 만들어야 하는 실습 산출물은 무엇인가?
- 도구 이름을 많이 아는데도 운영 판단이 약한 상태를 어떻게 피하는가?
개요
Web Operations 학습은 도구를 많이 나열하는 순서가 아니라 실패를 다루는 능력이 쌓이는 순서로 진행해야 한다.
Spring 백엔드 개발자에게 필요한 순서는 대략 서버 기본 -> artifact와 설정 -> 컨테이너 -> 프록시 -> CI/CD -> 관측 -> 복구와 장애 대응 -> 클라우드와 Kubernetes 판단이다.
각 단계는 “정상 실행 확인”, “실패 신호”, “되돌리거나 우회하는 방법”에 답해야 다음 단계로 넘어갈 수 있다.
1단계: Linux Server 운영 기본
처음에는 서버에 접속해 프로세스, 포트, 로그, 디스크를 볼 수 있어야 한다.
실습 산출물:
- SSH 접속 방법
- 서비스 실행 사용자
systemctl status또는 프로세스 확인 명령- 열려 있는 port 확인
- 로그 파일 위치
- disk usage 확인 명령
ss -lntp
journalctl -u order-api -n 100 --no-pager
df -h
free -m이 단계의 목표는 서버가 “죽었다”는 말을 더 구체적인 상태로 바꾸는 것이다.
예를 들어 process down, port closed, disk full, permission denied, OOM kill은 모두 다른 대응이 필요하다.
2단계: Build, Artifact, Config
다음은 Spring 애플리케이션을 운영 가능한 실행 단위로 만든다.
실습 산출물:
- Gradle build 명령
- jar 또는 Docker image
- version tag
application-local.yml과application-prod.yml- 환경 변수 목록
- Secret 주입 방식
./gradlew clean test bootJar
java -jar build/libs/order-api.jar --spring.profiles.active=prod이 단계에서는 “내 컴퓨터에서는 됐는데 서버에서는 안 된다”를 줄인다.
같은 artifact를 환경별 설정만 바꿔 실행할 수 있어야 한다.
3단계: Docker와 Compose
Docker는 실행 환경 차이를 줄이는 도구다.
Compose는 Spring, DB, Redis 같은 의존성을 로컬이나 작은 서버에서 함께 재현하는 데 유용하다.
실습 산출물:
- Dockerfile
- image build 명령
- Compose 파일
- volume과 port mapping 설명
- container log 확인 방법
services:
app:
image: order-api:local
ports:
- "8080:8080"
environment:
SPRING_PROFILES_ACTIVE: local
SPRING_DATASOURCE_URL: jdbc:postgresql://db:5432/order이 단계에서는 container가 죽었을 때 image 문제인지, config 문제인지, network 문제인지, volume 문제인지 나누는 연습을 한다.
4단계: Nginx, TLS, Traffic
애플리케이션이 떠 있어도 사용자 트래픽이 제대로 연결되지 않으면 서비스는 실패한다.
Nginx나 Load Balancer는 client와 Spring app 사이의 중요한 운영 경계다.
실습 산출물:
- Nginx reverse proxy 설정
- upstream port
- TLS 인증서 적용 방법
- access log와 error log 위치
- timeout과 body size 설정
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Request-Id $request_id;
proxy_read_timeout 30s;
}이 단계에서는 502, 504, connection refused, TLS 만료, body size 초과를 구분해야 한다.
Spring 로그에 요청이 없는데 사용자는 502를 받는다면 프록시나 upstream 경계를 먼저 본다.
5단계: CI/CD와 배포 전략
CI/CD는 사람의 손으로 반복하던 build, test, package, deploy를 안정화하는 장치다.
실습 산출물:
- CI workflow
- test 결과
- image push
- 배포 스크립트
- release note
- rollback 명령
이 단계에서는 배포 성공을 pipeline 초록불로만 보지 않는다.
배포 후 smoke test, health check, error rate 관찰까지 포함해야 한다.
6단계: Logging, Metrics, Tracing
운영 판단은 관측 신호에서 시작된다.
실습 산출물:
- structured log 예시
- request id 또는 trace id
- Actuator endpoint
- Prometheus metric
- latency p95/p99 확인 방법
- alert rule 초안
management.endpoints.web.exposure.include=health,prometheus
management.metrics.tags.application=order-api이 단계에서는 “로그를 남긴다”보다 “장애 중 원인 후보를 줄일 수 있는가”를 본다.
HTTP 5xx, DB pool pending, external API timeout, JVM memory, GC, thread 지표를 요청 흐름과 연결해야 한다.
7단계: Incident Response와 복구
관측 다음에는 복구를 배운다.
실습 산출물:
- 장애 severity 기준
- 초기 대응 메시지 템플릿
- rollback 절차
- feature flag off 절차
- backup restore 명령
- postmortem 양식
현재 영향: 주문 생성 API 일부 timeout
시작 시각: 2026-06-30 14:05 KST
최근 변경: order-api 3f21a9c 배포
완화 조치: coupon batch 중지, 신규 배포 동결
다음 확인: DB connection wait와 LB target health이 단계에서는 원인 분석과 완화 조치를 분리한다.
장애 중에는 완벽한 정답보다 피해 확산 방지가 먼저다.
8단계: Cloud와 Kubernetes 도입 판단
Cloud와 Kubernetes는 단일 서버, Docker, Nginx, CI/CD, 관측, 복구를 경험한 뒤 도입 이유를 설명할 수 있을 때 배운다.
Kubernetes는 배포, service discovery, self-healing, scaling을 도와주지만 probe, resource limit, rollout, ingress, log/metric 수집, cluster 권한까지 함께 운영해야 한다.
로드맵의 목표는 “Kubernetes를 쓴다”가 아니라 “지금 문제를 단순 서버, managed service, Kubernetes 중 무엇으로 풀지 판단한다”에 있다.
실전 팁
- 각 챕터를 배울 때 반드시 “실패하면 어떤 로그와 지표가 보이는가”를 적는다.
- 명령어를 외우기보다 실행 전 기대 상태와 실행 후 확인 상태를 같이 기록한다.
- 개인 프로젝트 README를 작은 운영 문서로 만든다.
- 복구 실습은 실제 장애 전에 해본다.
- 학습 순서는 도구 난이도보다 장애 대응 가능성을 기준으로 정한다.
위험 신호!
- 도구 이름은 많이 아는데 배포된 버전을 확인하지 못한다.
- 서버가 느릴 때 CPU, memory, disk, log 중 무엇을 먼저 볼지 모른다.
- health check와 smoke test를 같은 것으로 본다.
- metric은 있지만 알림과 대응 절차가 없다.
- rollback과 restore를 말로만 알고 실행해본 적이 없다.
확인 질문
확인 질문
- Web Operations를 Linux와 배포 기본부터 배워야 하는 이유는 무엇인가?
- 복잡한 플랫폼도 결국 process, port, config, log, metric, traffic, recovery 위에서 동작하므로 기본 신호를 알아야 장애 위치를 좁힐 수 있기 때문이다.
- 각 학습 단계의 산출물을 남겨야 하는 이유는 무엇인가?
- 학습이 개념 암기가 아니라 실제 운영 중 사용할 수 있는 명령, 설정, 로그, 복구 절차로 남아야 하기 때문이다.
- Kubernetes를 초반에 바로 도입하면 위험한 이유는 무엇인가?
- 기본 배포, 관측, 복구 능력이 없으면 Kubernetes가 제공하는 자동화 뒤에 실패 원인이 더 숨겨질 수 있기 때문이다.