서버나 애플리케이션이 잘 돌아가고 있는지 눈으로 확인하고 싶을 때, 가장 먼저 부딪히는 문제는 데이터를 어떻게 모으고, 어떻게 보여줄까이다. Prometheus와 Grafana는 이 두 문제를 각각 나눠서 해결하는 오픈소스 조합이다.

Prometheus

• 데이터 수집과 저장, 질의를 담당 정해진 주기로 서버, 컨테이너, 애플리케이션에서 지표(metric)를 긁어와 시계열 데이터베이스에 쌓고, PromQL이라는 쿼리 언어로 원하는 조건을 뽑아냄 CPU 사용률이 5분 동안 80%를 넘었는지, 특정 API의 응답 시간이 얼마나 튀었는지 같은 질문에 답 가능

Grafana

• 이 데이터를 그래프와 대시보드로 보여주는 역할만함 Grafana 자체는 데이터를 수집하지X Prometheus 외에도 MySQL, Loki, Elasticsearch 등 수십 가지 데이터소스를 붙일 수 있어서, 나중에 로그나 다른 DB까지 한 화면에서 보고 싶을 때 확장하기 쉬움

정리하면 두 도구는 경쟁 관계가 아니라 역할 분담 관계 Prometheus가 모으고, Grafana가 보여줌 (대부분의 모니터링 스택에서 이 둘은 세트로 함께 쓰인다)

2. 왜 이 조합을 선택해야 하는가

첫째, 완전한 오픈소스라 비용 부담이 없다. Datadog이나 New Relic 같은 SaaS형 모니터링 툴은 사용량에 따라 과금되는데, 트래픽이 늘수록 비용이 엄청나게 늘어난다. Prometheus와 Grafana는 직접 서버에 설치해서 쓰는 자체 호스팅(self-hosted) 방식이라 라이선스 비용이 없다.

둘째, 쿠버네티스와 클라우드 네이티브 환경의 사실상 표준이다. Kubernetes 생태계에서 Prometheus는 CNCF(Cloud Native Computing Foundation) 프로젝트로 채택되어 있고, 파드나 노드의 상태를 긁어오는 exporter가 이미 풍부하게 존재한다. 커뮤니티가 크기 때문에 문제가 생겼을 때 검색으로 답을 찾기 쉽다.

셋째, 유연한 커스터마이징이 가능하다. 코드가 공개되어 있으니 회사 내부 정책에 맞게 데이터 보관 정책, 알림 규칙, 대시보드 디자인을 원하는 대로 바꿀 수 있다. SaaS 툴은 이런 부분이 벤더 정책에 묶여있는 경우가 많다.

3. 어떤 상황에서 이 조합이 좋은가

• 지표(metric) 중심의 모니터링이 필요할 때 적합하다. CPU, 메모리, 요청 수, 에러율처럼 숫자로 떨어지는 데이터를 실시간에 가깝게 보고 싶은 경우다. 반대로 로그 원문을 뒤지거나 분산 트레이싱까지 필요하다면 Loki, Tempo 같은 도구를 추가로 붙여야 한다.

• 인프라를 직접 운영하는 팀에 적합하다. 서버든 컨테이너든 직접 관리하고 있고, 그 안에 모니터링 서버 하나 정도는 추가로 운영할 여력이 있는 경우다. 반대로 운영 인력이 아예 없거나 인프라를 신경 쓰고 싶지 않다면 Datadog 같은 매니지드 SaaS가 더 편할 수 있다.

• 데이터 보관 기간이 길지 않아도 되는 경우에 적합하다. Prometheus는 기본적으로 로컬 디스크에 데이터를 저장하기 때문에, 1년 이상의 장기 이력을 저장하려면 Thanos나 VictoriaMetrics 같은 별도 컴포넌트를 추가해야 한다. 최근 몇 주 정도의 데이터만 보면 충분한 경우라면 기본 구성만으로 충분하다.

• 소규모 개인 프로젝트라면 오히려 과할 수 있다. 서비스가 5개 미만인 개인 프로젝트나 단순히 "서버가 죽었는지 살았는지"만 확인하고 싶다면, Uptime Kuma 같은 훨씬 가벼운 툴이 낫다. Prometheus + Grafana는 어느 정도 규모가 있는 서비스에서 적합하다

요약!!! 다음과 같은 상황에서 이 조합 선택하기

• 여러 서버/컨테이너의 지표를 한 곳에서 모아 보고 싶을 때
• 쿠버네티스 클러스터를 운영 중일 때
• 비용을 들이지 않고 자체 인프라에 모니터링을 구축하고 싶을 때
• 알림 규칙이나 대시보드를 세밀하게 커스터마이징하고 싶을 때

4. 설치 준비물

진짜 최소 필요사양

• Docker Engine 20.10 이상
• Docker Compose 1.29 이상 (또는 Docker Desktop에 내장된 Compose)
• 여유 메모리 4GB, 여유 디스크 2GB 이상
• 3000번(Grafana), 9090번(Prometheus) 포트가 비어있을 것

Docker가 없다면 아래 명령으로 설치 여부를 먼저 확인

docker --version
docker compose version

둘 다 버전이 출력되면 준비 완료

5. 폴더 구조 만들기

작업할 폴더를 하나 만들고 그 안에 다음과 같은 구조를 준비

monitoring/
├── docker-compose.yml
└── prometheus/
    └── prometheus.yml

터미널에서 실행하면 한 번에 만들 수 있음

mkdir -p monitoring/prometheus
cd monitoring

6. Prometheus 설정 파일 작성

monitoring/prometheus/prometheus.yml 파일을 아래 내용으로 만듦 (이 파일은 Prometheus가 "어디서, 얼마나 자주" 데이터를 긁어올지 정의)

global:
  scrape_interval: 15s     # 15초마다 지표 수집
  evaluation_interval: 15s

scrape_configs:
  # Prometheus 자기 자신을 모니터링
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # 서버(호스트)의 CPU, 메모리, 디스크 지표 수집
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

  # 컨테이너별 리소스 사용량 수집
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

• node-exporter : 리눅스 서버의 CPU/메모리/디스크 같은 하드웨어 지표를 뽑아주는 보조 프로그램
• cAdvisor : 도커 컨테이너별 리소스 사용량을 뽑아주는 보조 프로그램

• 둘 다 아래 Compose 파일에서 같이 띄움

7. docker-compose.yml 작성

monitoring/docker-compose.yml 파일을 아래처럼 만듦

version: '3.8'

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"
    restart: unless-stopped

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    ports:
      - "9100:9100"
    restart: unless-stopped

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    container_name: cadvisor
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
    ports:
      - "8080:8080"
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
    restart: unless-stopped
    depends_on:
      - prometheus

volumes:
  prometheus_data:
  grafana_data:

GF_SECURITY_ADMIN_PASSWORD는 반드시 실제 사용할 비밀번호로 바꾸는 걸 추천 볼륨(prometheus_data, grafana_data)을 지정해 뒀기 때문에 컨테이너를 재시작해도 데이터는 유지되긴함

8. 실행하기

monitoring 폴더에서 아래 명령을 실행

docker compose up -d

-d는 백그라운드 실행 옵션 실행 후 아래 명령으로 4개 컨테이너가 모두 정상 기동됐는지 확인

docker compose ps

-> prometheus, node-exporter, cadvisor, grafana 4개 컨테이너 상태가 모두 Up이면 성공

9. Prometheus 접속 확인

• 브라우저에서 http://localhost:9090에 접속
• 상단 메뉴의 Status → Targets로 들어가면 방금 등록한 job(prometheus, node-exporter, cadvisor)들이 모두 UP 상태로 보여야 정상
• 하나라도 DOWN이면 prometheus.yml의 target 주소나 컨테이너 이름을 다시 확인

10. Grafana 접속 및 데이터소스 연결

• 브라우저에서 http://localhost:3000에 접속
• 초기 로그인 정보는 위 compose 파일에서 지정한 admin / admin이며, 최초 로그인 시 비밀번호 변경을 요구할 수 있음

로그인 후 데이터소스를 연결

1. 왼쪽 메뉴에서 Connections → Data sources로 이동
2. Add new data source 클릭 후 Prometheus 선택
3. URL 입력란에 http://prometheus:9090 입력 (컨테이너 이름으로 접속하므로 localhost가 아님에 주의)
4. 하단 Save & Test 클릭 → 초록색 성공 메시지 확인

11. 대시보드 만들기

직접 패널을 만들 수도 있지만, 커뮤니티에 이미 잘 만들어진 대시보드를 가져다 쓰는 게 훨씬 빠르긴함

1. 왼쪽 메뉴 Dashboards → New → Import 클릭
2. Import via grafana.com 항목에 대시보드 ID 입력
   • Node Exporter Full: 1860
   • Docker and system monitoring (cAdvisor): 893
3. Load 클릭 → 데이터소스로 앞서 만든 Prometheus 선택 → Import 클릭

12. 종료 및 정리

모니터링 스택을 끄고 싶을 때는 다음 명령을 사용

docker compose stop

컨테이너와 네트워크까지 완전히 제거하되 데이터는 보존하려면 다음을 사용

docker compose down

데이터까지 완전히 삭제하려면 -v 옵션을 추가

docker compose down -v

13. 다음 단계로 고려할 것들

기본 설치가 끝난 뒤 실무에서 더 필요해지는 것

Alertmanager를 추가하면 특정 조건(예: CPU 90% 초과 5분 지속)에서 슬랙이나 이메일로 알림을 받을 수 있다. 데이터 보관 기간을 늘리고 싶다면 Thanos나 VictoriaMetrics를 검토한다. 애플리케이션 자체의 커스텀 지표(예: 주문 처리 건수)를 수집하려면 각 언어별 Prometheus 클라이언트 라이브러리(Python, Java, Node.js 등)로 /metrics 엔드포인트를 직접 노출시키면 된다.

참고 자료

• Prometheus 공식 문서
• Grafana 공식 문서 - Docker 설치
• docker/awesome-compose - prometheus-grafana 예제
• Grafana Cloud - Docker Compose로 리눅스 호스트 모니터링

• 인프라 엔지니어 관점에서 Pod = "인프라 컨테이너"라고도 부름.
• Pod가 생성되면 눈에 보이지 않는 infra 컨테이너(/pause)가 먼저 뜨고, 이 컨테이너가 PID 1로 동작.
• 이 infra 컨테이너가 Pod에 속한 모든 컨테이너를 대신해서 커널 자원을 관리함:
  • namespace (커널)
  • c-group (커널)
  • network: LinuxBridge + TUN/TAP
• web, db 컨테이너도 자체 IPC는 갖고 있지만, 가상머신처럼 시스템콜이 Pod(infra 컨테이너)를 거쳐서 호스트와 연결됨.
• 핵심 포인트: Pod 안의 web이나 api 컨테이너가 죽어서 재시작되더라도, pause 컨테이너가 살아있는 한 Pod의 IP는 바뀌지 않음.

시험 포인트: "Pod 안의 컨테이너가 재시작돼도 바뀌지 않는 것은?" → Pod의 IP 주소 (pause 컨테이너가 네트워크 네임스페이스를 유지하기 때문)

2. Service (외부 노출)

• kind: Service는 외부에 노출하는 역할.
• 예제의 wordpress-mysql 서비스는 clusterIP: None으로 설정됨 → 헤드리스 서비스(Headless Service). DB처럼 고정된 개별 Pod에 직접 붙어야 하는 경우 사용.
• selector로 어떤 라벨을 가진 Pod에 연결할지 지정 (app: wordpress, tier: mysql처럼).

3. 스토리지 체계: StorageClass → PV → PVC

• DB는 데이터를 저장해야 하고, Web은 보통 저장하지 않음 (상태 없는 stateless 컨테이너).
• PV (PersistentVolume): 어떤 스토리지 유형/백엔드에 저장할지 결정하는 실체. 실제 디스크 자원 그 자체.
• PVC (PersistentVolumeClaim): "이 정도 용량, 이런 접근 모드로 스토리지 주세요"라고 요청하는 자원. 실질적으로 데이터는 PVC를 통해 저장됨.
• StorageClass: 최신 실무 방식. 여러 스토리지 유형을 미리 정의해두고, PVC가 새로 생성될 때 알맞은 PV를 자동으로 생성(Dynamic Provisioning)해서 바인딩해줌.

흐름 정리

• (전통적 방식) 관리자가 PV를 수동으로 미리 만듦 → PVC가 그 PV에 바인딩 → Pod가 PVC를 마운트
• (실무/최신 방식) StorageClass 정의 → PVC 생성 요청 → StorageClass가 자동으로 PV 생성 → PVC와 바인딩 → Pod가 마운트

시험 포인트: "PV와 PVC 중 실제로 Pod가 마운트해서 쓰는 것은?" → PVC. PV는 그 뒤에서 실제 저장소가 무엇인지 결정하는 역할.

4. Secret

• 비밀번호 등 민감 정보를 저장하는 쿠버네티스 오브젝트.
• 예제에서는 mysql-pass라는 Secret 안에 password 키로 저장됨.
• yaml에서는 valueFrom.secretKeyRef로 컨테이너 환경변수에 주입:

env:
- name: MYSQL_ROOT_PASSWORD
  valueFrom:
    secretKeyRef:
      name: mysql-pass
      key: password

• Secret을 실제로 만드는 명령어 (yaml에 없지만 시험에 나올 수 있음):

kubectl create secret generic mysql-pass --from-literal=password=<비밀번호>

5. kubectl 핵심 명령어 정리

시험 포인트: WordPress+MySQL을 배포할 때 사용하는 명령은 kubectl apply -f mysql.yaml, kubectl apply -f wordpress.yaml — yaml 파일이 있으므로 선언형 명령인 apply를 씀 (run/create가 아님).

6. WordPress + MySQL 예제 매니페스트

⚠️ 노트에 wordpress.yaml이라고 적힌 코드가 mysql.yaml과 내용이 완전히 같았음 (복사 실수로 보임). 아래에 mysql-deployment와 wordpress-deployment를 구분해서 정리함.

6-1. mysql-deployment.yaml

apiVersion: v1
kind: Service
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  ports:
    - port: 3306
  selector:
    app: wordpress
    tier: mysql
  clusterIP: None      # 헤드리스 서비스
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: mysql
    spec:
      containers:
      - image: mysql:8.0
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: MYSQL_DATABASE
          value: wordpress
        - name: MYSQL_USER
          value: wordpress
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

6-2. wordpress-deployment.yaml (web 쪽 — mysql과 구조는 같은 패턴, 대상만 다름)

apiVersion: v1
kind: Service
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  ports:
    - port: 80
  selector:
    app: wordpress
    tier: frontend
  type: LoadBalancer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wp-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: frontend
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: frontend
    spec:
      containers:
      - image: wordpress:latest
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql       # mysql Service 이름으로 접속
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim

6-3. 배포 순서

kubectl create secret generic mysql-pass --from-literal=password=<비밀번호>
kubectl apply -f mysql.yaml
kubectl apply -f wordpress.yaml

kubectl get pod,svc,pv,pvc,ns

시험 포인트: mysql을 먼저 apply하고 wordpress를 나중에 apply하는 게 일반적 (wordpress가 WORDPRESS_DB_HOST=wordpress-mysql로 mysql Service를 참조하기 때문). Secret은 두 매니페스트보다 먼저 만들어져 있어야 함.

7. Deployment / ReplicaSet / Pod 관계

Deployment  →  ReplicaSet  →  Pod (1개 이상)

• Deployment: 원하는 상태(이미지 버전, replica 수)를 선언. 롤링 업데이트/롤백 관리.
• ReplicaSet: Deployment가 자동으로 만듦. 지정된 개수만큼 Pod가 항상 떠 있도록 유지.
• Pod: 실제 컨테이너가 도는 최소 단위.

위 예제에서 strategy: type: Recreate는 업데이트 시 기존 Pod를 먼저 삭제하고 새 Pod를 만드는 방식 (DB처럼 동시에 여러 개가 뜨면 안 되는 경우 사용).

8. Podman 기반 dev 서비스 구성

개발 단계(dev)에서는 쿠버네티스 대신 Podman Pod로 가볍게 웹+DB(또는 LLM/AI 서비스)를 구성.

8-1. 설치

dnf install podman -y

8-2. Pod 생성 (외부 포트 게시)

podman pod create --publish 80:80 --name <pod이름>
podman pod ls

8-3. Pod 안에 컨테이너 붙이기

podman container run -d --image <이미지> --name app-web --pod <pod이름>
podman container run -d --image <이미지> --name app-db  --pod <pod이름>

8-4. 확인

podman pod ls
podman container ls

시험 포인트: Podman에서 여러 컨테이너를 하나로 묶으려면 먼저 podman pod create로 Pod(+포트 게시)를 만들고, 그 다음 podman container run --pod <pod이름> 옵션으로 컨테이너를 그 Pod에 붙임. 외부 포트:내부 포트는 Pod 생성 시 --publish로 지정.

9. 헷갈리기 쉬운 것들 정리 (오답 노트용)

10. 연습 문제

Q1. WordPress + MySQL을 쿠버네티스에 배포할 때, mysql.yaml과 wordpress.yaml을 적용하는 명령으로 올바른 것은?

1. kubectl run -f mysql.yaml
2. kubectl create pod mysql.yaml
3. kubectl apply -f mysql.yaml
4. kubectl start -f mysql.yaml

3번. yaml 파일 기반 선언형 배포는 apply를 씀.

Q2. Pod 내부에서 PID 1로 동작하며 네트워크 네임스페이스를 유지시켜주는 컨테이너는?

1. sidecar 컨테이너
2. init 컨테이너
3. infra 컨테이너 (/pause)
4. main 컨테이너

Q3. 다음 중 실제로 애플리케이션 Pod가 마운트해서 데이터를 저장하는 쿠버네티스 오브젝트는?

1. StorageClass
2. PersistentVolume (PV)
3. PersistentVolumeClaim (PVC)
4. ConfigMap

Q4. wordpress-mysql Service의 clusterIP: None 설정이 의미하는 것은?

1. 서비스가 비활성화됨
2. 외부에서 접근 불가능한 헤드리스 서비스
3. 랜덤 IP 할당
4. 로드밸런서 타입 서비스

Q5. Podman에서 web, db 컨테이너를 하나의 네트워크로 묶으려면 가장 먼저 해야 할 명령은?

1. podman container run --pod
2. podman network create
3. podman pod create --publish <포트>
4. podman build

Q6. (빈칸 채우기) 아래 명령어의 빈칸을 채우세요.

podman pod create --publish ____:____ --name svc-blog
podman container run -d --pod svc-blog --name app_web ____

Q7. MySQL 컨테이너의 root 비밀번호를 안전하게 주입하기 위해 사용하는 오브젝트와 필드는?

1. ConfigMap / data
2. Secret / secretKeyRef
3. Env 파일 / env_file
4. Volume / hostPath

Q8. Deployment - ReplicaSet - Pod의 관계를 올바르게 나열한 것은?

1. Pod가 ReplicaSet을 만들고, ReplicaSet이 Deployment를 만든다
2. Deployment가 ReplicaSet을 만들고, ReplicaSet이 Pod를 관리한다
3. 셋은 서로 독립적이며 관계가 없다
4. ReplicaSet은 Pod의 하위 개념이다

• Docker와 Podman의 차이점

  Docker: 중앙 집중형 관리 방식으로 하나의 백그라운드 데몬(dockerd)이 컨테이너 생성, 실행, 이미지 관리, 네트워크, 볼륨 등의 라이프사이클을 통합 제어합니다. 데몬이 주로 root 권한으로 동작하여 보안 측면의 고려가 필요하며, 데몬 장애 시 컨테이너 제어에 영향을 받을 수 있습니다.

  Podman: 쿠버네티스(Kubernetes)와의 호환성을 고려한 설계로 데몬리스(Daemonless)로 동작하며, 단독 컨테이너뿐만 아니라 POD 기반으로 컨테이너를 생성하고 관리할 수 있는 환경을 제공합니다. Docker에서는 직접 다루기 어려운 POD 자원 생성과 Infra-Container 변경도 자유롭게 수행할 수 있습니다.

• 컨테이너 생성자 (런타임) 종류

  runc: 표준 런타임의 교과서로, Docker 및 Containerd 기반에서 주로 사용됩니다.

  crun: 현대 Linux 환경에 최적화된 실전 런타임으로, Podman + cgroup v2 조합 및 대다수 오픈소스 엔터프라이즈 시스템에서 사용됩니다.

• ROOTLESS

  • 포드만에서 생성하는 컨테이너는 기본적으로 ROOTLESS 형태로 생성 및 구성됩니다 . root 권한 대신 일반 사용자로 콘솔에 직접 로그인하여 사용할 것이 권장됩니다.
  • OCI 사양의 런타임 구성 파일인 /etc/subgid 등을 통해 사용자 GID를 subgid에 명시된 값으로 매핑하여 사용합니다.

• POD 및 인프라 컨테이너 (Infra Container)

  • 쿠버네티스에서 제시한 개념으로, 포드만에서도 단독 또는 연동 컨테이너 관리를 위해 이를 구성할 수 있습니다.
  • Pod 내부의 구현을 위해 pause라는 애플리케이션 컨테이너를 사용하는데, 이를 '인프라 컨테이너(infra-container)' 혹은 'pause container'라고 부릅니다.
  • Pod는 애플리케이션 컨테이너가 연결되지 않으면 시작하지 않으며 , 볼륨/네트워크 포트/네임스페이스를 pause 애플리케이션에 전달 및 공유하는 방식으로 동작합니다. 구성 방식에 따라 인프라, 이닛(init), 프라이머리(primary), 사이드카(sidecar) 컨테이너 구조로 나뉩니다.

• 컨테이너 볼륨 마운트 옵션

  rw|ro: 컨테이너에 쓰기 및 읽기로 볼륨 디스크 설정.

  z|Z: SELinux 컨텍스트 적용 및 허용.

  [O]: 오버레이 모듈을 통해 컨테이너에 마운트.

  [U]: 호스트 기반의 UID/GID를 변경 (컨테이너가 많을수록 생성 속도가 느려짐).

  [no]copy: 컨테이너 내부 볼륨에 내용을 복사하거나 복사하지 않음.

  [no]dev: 볼륨 내용에 프로세스 접근 가능 여부 설정 (기본값 nodev).

  [no]exec: 마운트된 볼륨 내 프로세스 실행 허용 여부 설정.

  [no]suid: nosuid 권한 변경 제한 설정.

[r]bind: 하위 디렉터리까지 재귀적으로 연결(rbind) 처리.

• Podman 가상머신 (Podman Machine)
  • macOS나 Windows 환경은 Linux kernel namespace, cgroups, overlayfs 등의 네이티브 컨테이너 동작 조건을 갖추고 있지 않습니다. 따라서 Mac/Windows에서 Podman을 쓰기 위해 내부적으로 자동으로 생성되는 리눅스 VM 기술을 의미합니다 . macOS에서는 QEMU 및 HVF 기술을, Windows에서는 WSL2 기반 기술을 사용합니다.

2. 핵심 명령어 정리

1) 일반 컨테이너 및 시스템 관리 명령어

• podman run: 컨테이너를 생성하고 실행하는 명령어입니다. 백그라운드(-d) 또는 TTY를 통한 대화형 모드(-it) 형식을 지원하며, --rm 옵션을 주면 컨테이너 중지 시 자동으로 제거됩니다.

• podman container create: 컨테이너 자원만 생성하고 실행은 수행하지 않는 명령어입니다.

• podman port: 컨테이너에서 사용하는 포트가 호스트로 바인딩된 정보를 확인합니다. -l 옵션으로 마지막 컨테이너의 포트를 보거나 특정 ID/이름을 지정할 수 있습니다.

• podman ps / podman container ps / podman container ls: 컨테이너화되어 동작 중인 프로세스 목록을 확인합니다.

  • 주요 옵션: -size(사용 중인 컨테이너 크기 확인), -sort(정렬 기준 필드 선택), -noheading(제목 필드 출력 제외), -latest 또는 l(마지막 생성 컨테이너 출력), -watch 또는 w(실시간으로 명시된 초마다 프로세스 목록 갱신).

podman container rm: 프로세스가 중지되어 있는 컨테이너를 제거합니다. --all 옵션으로 전체를 지우거나, --force 옵션으로 강제 제거할 수 있습니다.

podman rmi: 런타임 엔진에서 관리하는 이미지를 제거합니다. --all 옵션으로 모든 이미지를 한 번에 지울 수 있습니다.

podman container logs: 컨테이너가 시작되면서 출력하는 표준 출력/오류 로그 기록을 확인합니다. (리눅스 시스템 명령어인 journalctl PODMAN_ID=<ID> 형식으로도 동일한 런타임 정보 확인이 가능합니다.)

• podman container mount: 컨테이너에 마운트되거나 바인딩(mount --bind)된 파일시스템 자원 경로를 확인합니다.

• podman container unmount: 바인딩되어 있던 루트 파일시스템 디렉터리 연결을 네임스페이스 공간을 통해 컨테이너에서 해제합니다.

• podman container wait: 컨테이너의 실행 상태 리턴 코드를 화면에 숫자로 출력합니다 (예: 0, 1, 125).

• podman info: 사용 중인 파일시스템 블록 디바이스 정보(Backing Filesystem 등)를 포함한 포드만 엔진의 전반적인 상태를 출력합니다.

2) 볼륨(Volume) 관리 명령어

• podman volume ls: 런타임 엔진 기반으로 관리되고 있는 볼륨 목록을 조회합니다. 생성된 로컬 볼륨 디렉터리는 기본적으로 /var/lib/containers/storage/volumes/ 하위에 위치합니다.

• podman volume create: 데이터를 영구적으로 관리하고 백업/복구하기 위한 전용 볼륨 공간을 생성합니다.

3) 포드(Pod) 관리 명령어 (podman pod ...)

포드만 내부에서 포드 자원을 관리할 때 사용하는 하위 명령어 구조입니다.

• create: 새로운 Pod를 생성하며, 필요에 따라 포트 매핑(-p)이나 볼륨 지정을 하위 컨테이너들이 공유하도록 설정할 수 있습니다.

• exists: 특정 Pod가 시스템에 존재하는지 확인합니다.

• inspect: Pod의 상태 및 구성 세부 정보를 JSON 형태의 런타임 정보로 출력합니다.

• kill: Pod 내에서 동작 중인 인프라 프로세스(pause)를 강제 종료합니다 (기본 시그널 15번).

• list (또는 ls): 현재 생성되어 있는 Pod 목록을 출력합니다.

• logs: Pod 단위 내부에서 발생한 표준 로그 기록을 확인합니다.

• pause / unpause: 동작 중인 Pod를 잠시 일시 정지하거나, 정지된 Pod를 다시 시작합니다.

• prune: 시스템 내부에서 중지 상태로 방치된 Pod 및 연결된 컨테이너를 일괄 제거합니다.

• start / stop / restart: 해당 Pod의 시작, 중지, 그리고 재시작 처리를 수행합니다.

• rm: 지정한 Pod 자원을 시스템에서 완전히 제거합니다.

• state: 사용자가 상태를 보기 편하도록 내부 Pod 정보 상태를 렌더링하여 화면에 출력합니다.

• top: Pod 내부 자원들의 실시간 사용 상태 및 프로세스를 조회합니다.

4) 쿠버네티스 마이그레이션 명령어

• podman generate kube: 포드만에서 사용한 컨테이너 및 시스템 자원을 쿠버네티스 배포 표준 형식인 쿠버네티스 YAML 파일로 전환하여 추출해 주는 명령어입니다.

  • 주요 옵션: -filename(생성할 파일 이름 지정), -replicas(복제할 개수 지정), -service(쿠버네티스 서비스 리소스 함께 구성), -type(변환 시 API 형식을 Pod 또는 Deployment 중 선택 명시, 기본값은 Pod).

1. 운영체제(OS)와 리눅스

운영체제란?

• 하드웨어(CPU, 메모리, 하드디스크) 위에서 소프트웨어(프로세스)를 실행할 수 있게 해주는 기반 소프트웨어
• 하드웨어를 먼저 구현하고, 그 위에서 소프트웨어를 처리할 수 있는 시스템을 만드는 것
• 운영체제 자체도 소프트웨어

리눅스의 특징

• 서버용 운영체제로 많이 사용
• 오픈소스 / 무료 (Free SW = 라이선스 자체가 무료, Open Source = Free SW + Charge SW 포함)
• Apache, MySQL 등 고품질 소프트웨어 지원
• 멀티유저(multi-user), 멀티태스킹(multi-tasking) 지원
• 적은 리소스에서도 동작, 강력한 네트워크 환경 지원
• Unix 프로그램과 이식성 높음
• 스크립트를 통한 자동화 용이

리눅스 커널 vs 배포판

• 커널: OS의 핵심. 하드웨어를 직접 제어하는 소프트웨어. 사용자 도구/앱은 포함하지 않음
• 리눅스 배포판: 커널 + 기본 명령어 + 애플리케이션을 묶어서 패키징한 것 = 우리가 실제로 사용하는 "리눅스"
• GNU/Linux: GNU 프로젝트 안에 여러 프로젝트들이 포함된 형태

주요 배포판

이번 과정에서는 Rocky Linux 사용

2. 리눅스 실행 환경

CLI vs GUI

실행 환경 전환 명령어

# GUI로 변경
systemctl isolate graphical.target

# CLI로 변경
systemctl isolate multi-user.target

# 기본 실행 환경 확인/변경
systemctl get-default
systemctl set-default graphical.target
systemctl set-default multi-user.target

GUI 패키지 설치 (minimal 설치 시)

dnf grouplist
dnf groupinstall "Server with GUI"

3. 셸(Shell)과 명령어

셸이란?

• 사용자가 입력한 명령어를 기계어(이진 데이터)로 번역해주는 프로그램
• 커널은 기계어만 이해하므로 번역기(인터프리터) 역할 필요

키보드 입력 → 터미널 → Shell → Kernel

• 터미널: 입출력을 담당하는 프로그램 (Shell과 다름)
• 프롬프트 상태:
  • # → root 사용자
  • $ → 일반 사용자
  • 아무 표시 없음 → 현재 명령어 입력 불가 상태

기본 셸 확인 및 변경

echo $SHELL          # 현재 셸 확인 (기본: bash)

/bin/sh              # 본셸로 변경
/bin/bash            # bash로 변경
exit                 # 현재 셸 종료 (상위 셸로 돌아감)

본셸(sh)이 리눅스 기본 셸이었고, 이를 업데이트한 것이 bash
macOS는 zsh, Windows는 PowerShell 사용
셸 변경 시 실제로는 하위 셸을 중첩 실행하는 것 (pstree 명령어로 확인 가능)

명령어 이력 (history)

• ↑ / ↓ 방향키: 이전/다음 명령어 탐색
• ctrl + r: 증분 검색 모드 (문자 입력 시 자동 검색)

메모리가 flush되기 전까지 검색 가능. 파일로 저장도 가능.

4. 리눅스 디렉토리 구조

핵심 개념

• 리눅스는 모든 것을 파일로 다룸 (하드디스크, 키보드, 프린터 등 장치도 파일)
• 전체 구조는 트리 형태 (FHS: Filesystem Hierarchy Standard)

주요 디렉토리

주요 설정 파일

/etc/passwd         # 사용자 UID, 쉘 등 관리
/etc/shadow         # 사용자 패스워드 (암호화 저장)
/etc/hosts          # 호스트명 → IP 매핑 (DNS보다 우선 동작)
                    # resolving: 도메인→IP 변환 순서: 캐시 → /etc/hosts → DNS
/etc/fstab          # 파일시스템 마운트 정보
/etc/resolv.conf    # DNS 서버 지정
/var/log/messages   # 시스템 로그
/var/run/sshd.pid   # sshd 데몬 PID

5. 경로(Path)

절대 경로 vs 상대 경로

차근차근 들어갈 때는 상대경로, 정확한 위치를 알면 절대경로로 바로 이동

특수 경로 표기

cd 명령어

cd /home              # 절대경로로 이동
cd ~                  # 홈 디렉토리로 이동
cd ..                 # 상위 디렉토리로 이동
cd ../testdir2        # 상위 디렉토리의 testdir2로 이동
pwd                   # 현재 경로 출력

6. 파일 관리 명령어

ls - 목록 확인

ls /                  # 루트 디렉토리 내용
ls -l                 # 상세 정보 출력
ls -a                 # 숨김 파일 포함 출력
ls -al                # 상세 + 숨김 파일
ls / /usr             # 여러 경로 동시 출력

mkdir - 디렉토리 생성

mkdir work
mkdir ./testdir1
mkdir ./testdir2

touch - 파일 생성

touch testfile1
touch testfile1 testfile2 testfile3   # 여러 파일 동시 생성

rm - 삭제

rm testfile1              # 파일 삭제
rm testfile*              # 와일드카드 사용 일괄 삭제
rm -r testdir1            # 디렉토리 삭제 (-r 옵션 필수)
rm -i testfile1           # 삭제 전 확인 메시지 출력

⚠️ 리눅스는 삭제 시 휴지통 없음. 바로 삭제됨!

cat - 파일 내용 출력

cat newfile
cat /etc/crontab

less - 페이지 단위로 파일 보기

less /etc/ssh/sshd_config

cp - 복사

cp /etc/ssh/sshd_config ./testfile      # 파일 복사
cp testfile ./testdir1                   # 디렉토리로 복사
cp testfile1 testfile2 testfile3 ./testdir1   # 여러 파일 복사
cp testfile* ./testdir2                  # 와일드카드 복사
cp -r testdir1 testdir3                  # 디렉토리 복사 (-r 필수)

mv - 이동/이름 변경

mv file1 file2           # 이름 변경
mv file1 dir1            # 디렉토리로 이동
mv file1 file2 file3 dir1   # 여러 파일 이동
mv -i file1 file2        # 덮어쓰기 전 확인
mv dir1 dir2             # 디렉토리 이동 (-r 옵션 불필요)

7. vim 편집기

기본 개념

• 리눅스 기본 텍스트 편집기 (vi 입력해도 vim 실행됨)
• 텍스트 파일만 편집 가능 (이미지, 동영상, 컴파일된 바이너리 불가)

vim --version         # vim 버전 확인
dnf install vim -y    # 설치 (없을 경우)

vim 실행 방식

vi file1                  # 새 파일 또는 기존 파일 편집 (normal mode)
vi -R file1               # 읽기 전용으로 열기
vi -L file1               # 작업 중인 .swp 파일 확인
vi +30 file1              # 30번째 줄부터 편집 시작
vi +/"hello" file1        # "hello" 단어가 있는 줄부터 시작

vi 실행 시 현재 디렉토리에 .swp 파일 생성됨. 이미 있으면 경고 출력.

3가지 핵심 모드

Normal Mode ←→ (i/a/o 등) →→ Insert Mode
Normal Mode ←→ (:) →→ Command-line Mode
Insert/Cmdline → ESC → Normal Mode

Normal Mode (기본 모드)

• vim 실행 시 처음 진입하는 모드
• 파일 내용 탐색, 복사/붙여넣기, 되돌리기 등

이동 키:

Insert Mode (편집 모드)

Normal Mode에서 다음 키로 진입:

Command-line Mode

: 입력으로 진입. 파일 저장, 종료, 검색 등.

정규 문자: ^ 시작, $ 끝, . 문자 일치, * 모든 문자

이동

vi ~/.vimrc

set nu           # 행 번호 표시
set ai sw=2 ts=2 et   # 자동 들여쓰기, 탭 크기 설정

8. 추가 편집기 (IDE)

Jupyter Lab

# 설치
yum install -y python3-pip
pip install jupyterlab
jupyter lab --generate-config
jupyter lab password

# 실행
jupyter lab --allow-root --ip 0.0.0.0 --port 8989 &

부팅 시 자동 실행: /etc/systemd/system/jupyter.service 작성 후

systemctl daemon-reload
systemctl enable jupyter

VSCode (code-server)

# 설치
curl -L https://code-server.dev/install.sh | sh

# 설정 파일: ~/.config/code-server/config.yaml
bind-addr: 0.0.0.0:9999
auth: password
password: <패스워드>

# 실행
systemctl start code-server@$USER
systemctl enable code-server@$USER

핵심 명령어 한눈에 보기

2. 사용자 및 권한 관리 / 3. Filesystem 및 disk 관리 / 4. 프로세스 관리

2. 사용자 및 권한 관리

사용자 관리 파일

• 시스템에서는 여러 작업을 수행하는 사용자별로 User와 Group을 통해 역할 구분

/etc/passwd - 사용자 관리 (콜론 : 기준으로 필드 구분)

cat /etc/passwd | grep root
root:x:0:0:root:/root:/bin/bash

nologin → 쉘을 사용하지 않고 내부적으로만 동작함

/etc/shadow - 암호 관리 (암호화되어 저장)

cat /etc/shadow | grep root

사용자 생성/수정/삭제

# 사용자 생성
useradd -c test demouser

# 암호 설정
passwd demouser

# 확인
cat /etc/passwd | grep demouser
cat /etc/shadow | grep demouser
cat /etc/group | grep demouser
ls -al /home/

새로운 사용자는 기본적으로 홈 디렉토리가 자동으로 만들어지며 1000 이후의 UID와 GID가 지정됨

# 사용자 수정
usermod -u 2000 demouser
usermod -s /bin/sh demouser    # bash 쉘이 아닌 본쉘로 변경

# 그룹 추가/수정
groupadd testuser
groupdel demouser
usermod -l testuser -g testuser demouser
usermod -d /home/testuser -m testuser

# 사용자 삭제 (-r: 홈 디렉토리와 mail spool도 함께 삭제)
userdel -r testuser

usermod 옵션

그룹 관련 주의사항:

• 그룹에는 반드시 사용자가 한 명 이상 포함되어야 함
• 사용자는 어떤 그룹이든 반드시 그룹에 속해야 함
• 기본 그룹 (-g): append 개념 없음. 무조건 대체
• 보조 그룹 (-G): -a 옵션 없으면 싹 replace. -a와 함께 써야 추가됨

암호 만기일 설정 예시

useradd -e 2026-05-30 expuser
passwd expuser
cat /etc/shadow | grep expuser

# 날짜 변경 후 접속 테스트
date -s 220601
ssh expuser@localhost
# 실패 확인

UID 범위

파일 소유자와 소유 그룹

• 파일을 만든 사람 = 파일의 소유자 (변경 가능)
• 한 사용자는 여러 그룹에 소속 가능
• 그룹을 특별히 지정하지 않으면 사용자 이름과 동일한 그룹에 소속

# 파일 소유자/그룹 확인
ls -l testfile1

# 소유자 변경
chown testuser:testuser testfile1

# 현재 내가 속한 그룹 확인
groups

퍼미션(Permission)

• 각 파일에 '누구에게 어떤 권한을 허가할지' 설정된 정보

파일 타입

권한 구조 (9글자, 3자리씩 소유자 / 소유그룹 / 기타사용자)

rwx rwx rwx
소유자 소유그룹 기타사용자

만들어지는 모든 파일은 보통 소유자 빼고 W가 빠지게 구성되어 있음

디렉토리 퍼미션 (파일과 의미가 다름!)

파일을 지울 수 있는지 여부는 파일이 아니라 디렉토리의 퍼미션에 의해 결정됨
r--이면 cd로 들어가진 못하는데 ls로 파일 리스트 확인은 가능

퍼미션 변경 (chmod)

파일 모드 변경은 해당 파일의 소유자 혹은 슈퍼 사용자만 가능

1. 기호 모드

chmod [ugoa] [+-=][rwx] <파일 이름>

chmod u+w file.txt       # 소유자에게 쓰기 권한 추가
chmod g-w file.txt       # 그룹의 쓰기 권한 제거
chmod go=r file.txt      # 그룹과 기타사용자를 읽기만 가능하게
chmod a-r testdir2       # 모든 사용자 읽기 권한 제거
chmod a-x testdir3       # 모든 사용자 실행 권한 제거

기호 모드는 상대적 퍼미션 지정 (지정한 것 외에는 변화 없음)

2. 수치 모드 (Octal mode)

chmod <8진수 수치> <파일 이름>

조합 예시:

chmod 755 file.txt    # rwxr-xr-x  (다른 사용자가 봐도 되는 실행 파일에 보통 사용)
chmod 644 file.txt    # rw-r--r--  (다른 사용자가 봐도 되는 일반 파일에 보통 사용)

수치 모드는 기존 퍼미션을 새로운 퍼미션으로 덮어씀

권한 상승 (Escalation)

• 슈퍼유저(root): 시스템 설정 변경, 새로운 애플리케이션 설치, 퍼미션 무시하고 모든 파일 읽기/수정/삭제 가능
• 리눅스 설치하자마자 자동으로 만들어짐
• 평소에는 일반 사용자로 조작하다가 반드시 필요한 상황에서만 슈퍼 사용자로 조작하는 것이 좋음

su 명령어 - 사용자 전환

• 로그아웃하지 않고 다른 사용자로 전환 (권한 상승 아님, 사용자 전환)
• root에서 일반 사용자로 전환 시 비번 안 물어봄, 반대는 물어봄

# 새로운 사용자 만들고 전환
useradd sudouser
passwd sudouser
su - sudouser

# 슈퍼 사용자로 전환 (인자 없으면 슈퍼 사용자로 전환 의미)
su
# 암호 입력 → root 암호

# 슈퍼 사용자 환경으로 초기화하면서 전환 (권장)
su -

# 원래 사용자로 돌아가기
exit

su vs su - 차이:

• su: 환경 변수/현재 디렉토리가 일반 사용자 상태로 유지됨
• su -: 슈퍼 사용자의 환경으로 초기화됨 (권장)

sudo 명령어 - 명령어를 다른 사용자가 되어 실행

• 한 명령어만 슈퍼 사용자로 실행. 명령어가 끝나면 일반 사용자로 돌아옴
• 입력하는 암호는 현재 로그인한 사용자의 암호 (su는 슈퍼 사용자 암호)

sudo cat /etc/shadow
# [sudo] sudouser의 암호: 입력

su: 사용자 자체가 슈퍼 사용자로 전환 (exit 전까지 유지)
sudo: 명령어 하나만 슈퍼 사용자로 실행

sudo 설정 - /etc/sudoers

cat /etc/sudoers   # root로 실행

%wheel ALL=(ALL) ALL    # wheel 그룹에 속한 사용자는 모든 명령어 실행 가능

특정 사용자에게 sudo 권한 부여:

sudouser ALL=(ALL) ALL

sudoers 파일에 등록되지 않은 사용자는 sudo 사용 불가
sudo 권한을 준다는 것은 슈퍼 사용자의 권한을 주는 것과 마찬가지

3. Filesystem 및 disk 관리

파일시스템이란

• OS에서 파일을 관리하도록 여러 가지 규칙과 방법을 정의하고 쉽게 사용할 수 있도록 기능을 제공해 주는 시스템
• 파일을 저장하고 삭제하는 등 파일을 구성하는 여러 보조 정보들을 활용하여 통합적으로 관리하게 만들어 주는 체계
• 디스크를 포맷한다 = 파일 시스템을 생성한다

주요 파일시스템

XFS

• 64비트 저널링 파일 시스템
• RHEL7 버전부터 기본 파일 시스템
• b-trees를 사용하여 우수한 I/O 확장성을 제공하고 모든 사용자 데이터 및 메타데이터를 인덱스
• 빠른 복구를 용이하게 하는 메타데이터 저널링 지원
• 마운트되어 활성화된 상태로 조각 모음 및 확장 가능
• extend 기반 할당 사용 (지연 할당, 사전 할당 지원)

디스크 조각화: 시간이 지나면서 파일의 수많은 조각이 디스크 전체에 흩어지게 되는 현상. 파일에 액세스하는 데 시간이 더 오래 걸리고 속도가 느려짐

BtrFS

• "Butter" 또는 "Better" FS로 발음
• "B-Tree File System"의 약자
• 드라이브 풀링, 즉석 스냅샷, 투명한 압축 및 온라인 조각 모음 지원
• 최근 개발된 차세대 리눅스 파일 시스템이 될 수도 있음

EXT4

• 기존에 많이 사용되어 온 파일 시스템

파일시스템 구성

디스크 추가 (VirtualBox 기준)

# 가상머신 전원 종료 후 디스크 추가
poweroff

VirtualBox 관리자 → 가상머신 설정 → 저장소 → SATA 컨트롤러 우클릭 → 하드디스크 추가 → 만들기 → VDI 포맷 선택 → 이름 작성 → 추가 → 확인 → 가상머신 시작

디스크 확인

lsblk
lsblk -o NAME,SIZE,TYPE,FSTYPE

NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda               8:0    0   20G  0 disk
├─sda1            8:1    0    1G  0 part /boot
└─sda2            8:2    0   19G  0 part
sdb               8:16   0    2G  0 disk    ← 새로 추가한 디스크 (아직 파티션 없음)

파티셔닝 - fdisk

파티션으로 나누는 이유: 서로 다른 파티션에 다른 파일 시스템을 구현할 수 있기 때문

fdisk /dev/sdb

주요 명령어:

파티션 생성 과정:

n → p (primary, 최대 4개 / 이후는 extended) → 번호 입력 → 시작 섹터 (기본값 2048) → 크기 지정 (+512M 등)
w (저장)

first sector: 1부터 있지만 2048부터 사용 가능 (그 전은 예약)
GPT 파티션은 g 입력 후 타입 변경 후 생성

파일시스템 생성 - mkfs

mkfs -t xfs /dev/sdb1

파일시스템 마운트

• 파일시스템을 사용하여 파일을 저장하기 위해서는 특정한 디렉토리 경로로 연결해야 함
• linux의 모든 파일은 / (루트 디렉토리) 하위의 경로를 가짐

# 마운트 포인트 생성
mkdir /data

# 마운트
mount -t xfs /dev/sdb1 /data

# 파일시스템 상태 확인
df -Th

# 마운트 해제
umount /dev/sdb1

부팅 시 자동 마운트 - /etc/fstab

# /etc/fstab 마지막 행에 추가
/dev/sdb1       /data   xfs     defaults        0 0

# fstab 기반으로 마운트
mount -a
df -Th

/etc/fstab에 정보 추가하면 부팅 시 마운트 자동으로 해줌

4. 프로세스 관리

프로세스란

• 디스크에 있던 특정 파일들을 메모리에 적재하면서 처리하기 위해 CPU 쪽에서 스레드를 통해 연산 처리하는 것
• 특정한 사용자로 명령어를 통해 프로그램을 실행했을 때 프로세스가 생성되며 고유한 ID를 할당받음 → PID (Process ID)
• 실행시킨 프로세스 = 부모 프로세스 / 하위 프로세스 = 자식 프로세스 (PPID: Parent Process ID 정보 가짐)
• 각 프로세스는 고유한 권한을 가지고 자체 가상 주소 공간에서 실행됨
• IPC(Interactive Process Communication) 등 안전한 커널 관리 메커니즘을 통하지 않고는 다른 프로세스와 상호 작용할 수 없음 → 하나의 프로세스가 에러가 나도 다른 프로세스는 정상 작동

좀비 프로세스: 죽지 않고 계속 남아 있는 프로세스. 단순히 있는 건 문제 없으나, 자식이 죽고 좀비로 되어 있는데 부모가 안 죽이면 메모리 부족 문제가 발생할 수 있음

RPM (Redhat Package Manager)

• Redhat에서 패키지를 쉽게 설치하고 관리하기 위해 만든 패키지 관리 프로그램
• 복잡한 컴파일 단계를 자동으로 처리
• .rpm 파일을 갖고 패키지 관리

rpm -qa
rpm -qa | grep ssh
rpm -q openssh
rpm -ql openssh
rpm -qip vsftpd-3.0.2-29.el7_9.x86_64.rpm
rpm -ivh vsftpd-3.0.2-29.el7_9.x86_64.rpm
rpm -evh vsftpd

파이프라인 및 리다이렉션

파이프라인 (|)

CMD1 | CMD2

• 두 개의 명령어를 파이프라인으로 이어주는 역할
• CMD1의 출력을 CMD2의 입력으로 넣어줌
• CMD2에는 grep 많이 사용 → 해당 내용 있으면 그것만 출력

3채널 (stdin/stdout/stderr)

리다이렉션

cmd > result.txt        # stdout을 파일로 저장 (화면에는 출력 안 됨)
cmd < result.txt        # 파일을 표준 입력으로 사용
cmd 2> error.log        # stderr를 파일로 저장

스트림으로 처리한다 → 파일로 만들지 않고 흘려보낸다 (실시간 처리 가능)
리다이렉션은 재사용 가능하지만 지연시간 발생 가능 (단점)

Yum / DNF

• 사용 가능한 소프트웨어 패키지의 rpm 파일이 저장되어 있는 온라인 저장소인 리포지토리와 함께 작동하도록 설계
• 패키지 종속성을 자동으로 해결 (rpm은 수동으로 처리해야 했음)
• 최근 RHEL 계열은 yum의 업그레이드 버전인 dnf 사용 (명령어 체계 거의 동일)

ls /etc/yum.repos.d/
cat /etc/yum.repos.d/CentOS-Base.repo

yum clean all            # 레포지토리 캐시 제거
yum install docker-ce    # 설치
yum list docker-ce       # 설치된 항목 확인
yum info docker-ce       # 상세 확인
yum remove docker-ce     # 삭제

Linux 프로세스 명령어

ps                          # 현재 사용자로 실행한 프로세스 확인
ps -e                       # 현재 시스템의 모든 프로세스 확인
ps -f                       # full-format으로 표시
ps -ef                      # grep으로 piping 해서 많이 사용
ps a                        # 다른 사용자의 프로세스 상태도 표시
ps x                        # 화면에 보이지 않는 프로세스까지 표시
ps u                        # 1분간 CPU, 메모리 점유율 포함 정보 표시
ps -ef | grep sshd          # 전체 프로세스 중 sshd 키워드로 검색
ps -ef | less
ps aux | less
ps -eo pid,ppid,%mem,%cpu,cmd    # 프로세스별 CPU, 메모리 사용률 확인

sleep 60 &                  # 백그라운드로 sleep 프로세스 생성 (& 없으면 foreground)
ps

ls /proc                    # 프로세스별 디렉토리 (커널 메모리에 마운트된 정보)

sleep: 아무것도 처리하지 않는 멍때리는 프로세스
&: 백그라운드로 실행 (출력 스트림 기다리는 작업이 필요 없음)
데드락: 서로 기다리는 상태

Foreground & Background

• foreground: 프로세스가 실행 중일 때 사용자가 터미널을 사용해서 stdin을 사용하지 못함. 프로세스가 종료되어야 Shell의 prompt가 떨어짐
• background: 프로세스가 실행 중이더라도 터미널을 사용해 stdin으로 명령어를 수행할 수 있음. 종료되면 출력이 뜨지 않음. 명령행 끝에 & 붙임

# foreground 실행 및 제어
sleep 60
<Ctrl + c>    # 즉시 종료
<Ctrl + z>    # 일시 중지

# background 실행
sleep 90 &

# 상태 확인 및 전환
jobs          # 프로세스 상태 확인
bg 1          # 중지된 프로세스를 background로 실행 (숫자 = job ID)
fg            # 바로 직전에 중지된 프로세스를 foreground로 실행

Service (Daemon)

• 사용자가 직접 제어하지 않고 백그라운드에 실행시킨 후 여러 작업들을 수행하는 프로세스
• 일반 백그라운드 프로세스와 달리 사용자와 상호작용하지 않음
• 사용자 Input을 받기 위한 터미널이 없음
• 사용자별 프로세스가 아닌 시스템 전체적으로 동작
• systemd 프로세스로 (systemctl 명령어로) 관리. 높은 권한(root) 필요

# 서비스 목록 조회
systemctl list-units --type=service

systemctl status firewalld      # 상태 확인
systemctl stop firewalld        # 중지
systemctl disable firewalld     # 비활성화 (부팅 시 자동으로 올라오지 않음)
systemctl start firewalld       # 시작
systemctl enable firewalld      # 활성화

systemctl과 Container

systemctl 방식

• 리눅스 부팅 시 가장 먼저 실행되는 systemd(PID 1)를 제어
• 호스트 OS의 자원을 직접 공유
• 항상 백그라운드에서 실행되어야 하는 핵심 서비스(네트워크, SSH, 로깅 등) 관리에 최적화

ps -ef | head

# nginx를 systemctl 방식으로 실행
dnf install nginx -y
systemctl start nginx

Container 방식

• 호스트 OS의 커널을 공유하지만 네임스페이스(Namespace)와 cgroups라는 리눅스 커널 기능으로 프로세스를 격리된 공간에서 실행
• 호스트 입장에서는 '하나의 격리된 프로세스'일 뿐

docker ps

# nginx를 컨테이너 방식으로 실행
docker run -d --name webserver -p 80:80 quay.io/uvelyster/nginx

docker 옵션:

프로세스 Signal

background 프로세스를 종료하기 위해 특별한 signal을 프로세스로 전송

kill -l           # signal 목록 확인
man 7 signal      # signal 상세 설명

주요 signal:

ps -ef | grep postfix         # postfix 프로세스의 PID 확인
kill -9 4249                  # 강제 종료 (-9 = SIGKILL)
systemctl restart postfix     # 재기동

foreground 종료: Ctrl + c
background 강제 종료: kill -9 PID
정상이라면 signal 안 던져도 자동으로 종료됨 (SIGTERM 권장)

프로세스 모니터링

ps -eo pid,ppid,%mem,%cpu,cmd    # 프로세스별 CPU, 메모리 사용률

top          # 실시간 모니터링
h            # top 실행 중 help
q            # top 종료

uptime       # 1분, 5분, 15분 부하 평균

1분 사용량이 15분보다 높으면 → 점점 더 사용량이 높아지고 있음 (부하되고 있다)

top 상단 요약 정보

top - 21:05:46 up 6:07, 1 user, load average: 0.00, 0.01, 0.05
# 현재 시각, 부팅 이후 경과 시간, 사용자 수, 부하 평균(1분/5분/15분)

Tasks: 113 total, 1 running, 112 sleeping, 0 stopped, 0 zombie
# 전체 프로세스 및 각 상태별 개수

%Cpu(s): 0.0 us, 6.2 sy, 0.0 ni, 93.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
# CPU 사용률

KiB Mem: 1882072 total, 1388248 free, 274156 used, 219668 buff/cache
# 전체 메모리, 여유 메모리, 사용 중인 메모리, 커널 버퍼 + 페이지 캐시

KiB Swap: 2097148 total, 2097148 free, 0 used. 1440600 avail Mem
# 전체 swap, 여유 swap, 사용 중인 swap, 여유 메모리 + 페이지 캐시

☁️ 클라우드 및 AWS 인프라 구성 마스터 가이드

5. SDx 가상화와 클라우드, 클라우드의 특성

1) 가상화 (Virtualization)

과거의 IT 환경은 하드웨어 중심이었으며, 비효율성(하드웨어 성능의 10~20%만 사용, 유지비는 100% 지출)이 컸습니다. 물리적 제약을 깨고 소프트웨어가 하드웨어를 제어하기 시작하면서 등장한 개념이 가상화입니다. 가상화의 주요 목표는 더 나은 성능, 확장성, 안정성/가용성, 민첩성 획득 및 통합 보안/관리 도메인 생성입니다. 단일 컴퓨터를 여러 개별 컴퓨터로 만들거나, 논리적 네트워크 영역 구성, 여러 저장소를 하나로 묶거나 큰 저장소를 작게 나누는 등의 작업이 가능합니다.

2) SDx (Software Defined everything)

하드웨어의 제어권(Control Plane)을 물리적 장비에서 분리해 소프트웨어로 옮겨, 가상화된 리소스를 생성하고 물리적 리소스에 매핑시키는 기술입니다.

SDN (Software Defined Network): 가상의 네트워크

SDS (Software Defined Storage): 가상의 스토리지

SDDC (Software Defined Data Center): 가상의 데이터 센터

3) 가상화의 역사 (History)

1972년: 메인프레임 System/370 모델에서 시작 (당시 VM을 pseudo machine이라 명명). 리소스 할당 및 격리 제어 프로그램이 훗날 Hypervisor라는 이름을 얻음.

2003년 10월: x86용 최초 오픈소스 하이퍼바이저 Xen 도입 (Citrix XenServer, Oracle VM 등에 채택).

2007년 / 2010년: Redhat이 RHEL5에 Xen을 포함했으나, RHEL6(2010)에서 KVM으로 전환하며 오픈소스 하이퍼바이저의 전환점을 맞이함.

4) 가상화의 이점

짧은 평균 복원 시간 (MTTR): 실패한 서비스 복원에 전체 VM 스냅샷/백업을 활용하여 시간을 크게 단축.

노후화된 인프라 대안: 물리적 하드웨어(기대수명 3~4년)가 노후화되어도 VM은 영향을 받지 않고 하드웨어 업그레이드 후에도 지속 사용 가능.

Scale up이 쉬운 인프라: 호스트 용량이 남는 한 물리적 제한 없이 VM 용량 추가 가능.

리소스 활용: 적은 리소스로도 필요한 만큼 여러 VM을 동작시켜 가용성 추가 확보 및 효율적 관리.

운영 비용 절감: HA(고가용성) 구성을 가상 서버로 쉽게 변환 및 추가 가능하여 하드웨어 비용 절감.

5) 가상화의 종류 (목표 대상 기준)

데스크탑 가상화 (VDI): 장치에 의존하지 않고 어디서나 업무 환경 연결. 중앙 집중 관리/모니터링, 단순화된 배포 및 보안 설정 가능.

서버 가상화: 어플리케이션 환경을 구성. 백업 용이, 리소스 효율적 사용, 빠른 장애 대응.

어플리케이션 가상화: 원격 프로토콜/스트리밍 서비스를 패키징해 VM에 마운트 (예: Microsoft App-V, VMware App Volumes).

네트워크 가상화 (SDN): 물리적 스위치 없이 논리적인 가상 네트워크를 구성하여 안전하고 편하게 관리.

스토리지 가상화 (SDS): 물리적 공간을 가상화하여 할당. (file, block, object 유형). 공유 및 재사용성 향상.

6) 하이퍼바이저 (Hypervisor)

가상화의 본질인 추상화(Abstraction)와 격리(Isolation)를 달성하기 위해 하드웨어를 에뮬레이션(Emulation)하고 자원을 할당(Resource Allocation)하는 제어 프로그램입니다.

Type-1 (Native/Bare-metal): 하드웨어 위에 직접 설치. 오버헤드가 적고 보안이 강력 (엔터프라이즈 서버용).

예시: VMware ESXi, Xen, Microsoft Hyper-V, KVM (AWS EC2의 근간)

Type-2 (Hosted): 기존 운영체제(Host OS) 위에 애플리케이션처럼 설치. 설치가 쉽고 PC 테스트용으로 적합.

예시: Oracle VirtualBox, VMware Workstation

7) Virtualbox 기반 실습 환경 구성

설치: Oracle VirtualBox 설치 후 C++ 재배포 가능 패키지 설치 필요. 실습용 Rocky Linux ISO 파일 다운로드.

가상머신 생성: 무인설치 건너뛰기, 리소스 설정(기본 1vCPU, 2048MB RAM, 20GB 디스크).

네트워크 구성: 네트워크 관리자에서 호스트 전용(Host-only) 네트워크 설정 (실습 IP 대역: 172.16.0.1로 변경).

8) 클라우드 서비스 소개

가상화로 만든 추상화 계층을 통해 IT 리소스를 온디맨드 방식으로 대량 제공하며, 사용한 만큼 비용을 지불하는 모델입니다.

NIST의 클라우드 컴퓨팅 5대 필수 특성:

온디맨드 셀프 서비스: 버튼/API 호출로 임시 프로비저닝 가능.

광범위한 네트워크 액세스: 네트워크를 통한 기능 사용.

리소스 풀: 다중 테넌트 모델 기반 리소스 공유 할당.

신속함과 탄력성: 용량의 빠른 확장 및 축소.

측정된 서비스: 소비 통찰력을 위한 메트릭 제공.

클라우드 오퍼링 3가지 유형: 퍼블릭(대중 사용), 프라이빗(단일 조직 내), 하이브리드(퍼블릭+프라이빗 혼합).

CSP(Cloud Service Provider) 서비스 3대 분류:

IaaS: 가상머신, 스토리지, 네트워킹 등 기본 리소스 제공 (AWS EC2 등)

PaaS: 맞춤형 앱 배포 플랫폼 제공 (AWS Elastic Beanstalk 등)

SaaS: 인프라와 소프트웨어가 결합된 최종 어플리케이션 제공 (Microsoft 365 등)

9) Amazon Web Service (AWS) 개요

컴퓨팅(EC2), 스토리지(S3), 네트워킹 등의 솔루션을 REST API 및 HTTP 프로토콜을 통해 종량제(Pay-as-you-go)로 제공.

글로벌 인프라: 전 세계에 데이터 센터 분산. 리전(Region)과 여러 개의 가용 영역(AZ)으로 구성 (예: 한국 리전 ap-northeast-2는 4개의 가용영역 보유).

관리 콘솔: 루트 사용자는 계정 생성 시 사용하며, 평소에는 IAM 사용자로 로그인하여 작업.

6. IAM 인증 및 AWS CLI

1) IAM 서비스 및 MFA 설정

AWS 계정은 리소스의 바구니이며, 모든 권한을 가진 '루트 사용자' 대신 접근을 제한한 IAM 사용자를 생성하여 사용해야 합니다.

MFA(멀티 팩터 인증): 아이디/비밀번호 외에 스마트폰 앱이나 물리 키를 통한 일회용 인증 코드를 추가로 요구하는 강력한 보안 장치.

가상 MFA 앱: Google Authenticator, Microsoft Authenticator, Duo Mobile 등.

IAM 사용자 생성: Management Console 접근 활성화 여부 선택, 권한 정책 할당(실습용 AdministratorAccess이나 실무에서는 권장 안 함).

2) AWS CLI 설정

API 진입점을 호출하여 터미널 내에서 인프라 생성 및 반복 작업을 자동화(Jenkins 등 연동)할 수 있는 도구입니다.

설치: curl로 다운로드 후 unzip, sudo ./aws/install 수행. aws --version으로 확인.

자격 증명 (Credentials): 콘솔 패스워드 대신 액세스 키(Access Key)와 시크릿 키(Secret Key) 사용. 생성 후 안전한 곳에 보관.

초기화: aws configure (키 정보, 리전, 출력 포맷 입력). aws configure list로 확인.

3) IAM 정책 (Policy) 및 역할 (Role) 구성

IAM 정책: 누가(Principal), 어떤 조건(Condition)에서, 어떤 서비스(Resource)의, 어떤 기능(Action)을, 허용(Allow)/거부(Deny)할지 명시한 JSON 문서.

예시: S3 버킷(s3://tmddnr-wave)의 목록 조회(s3:ListBucket) 권한 허용 JSON 작성.

aws iam create-policy로 정책 생성 후 aws iam attach-group-policy로 그룹에 바인딩.

IAM 역할: 리소스(예: EC2)에게 사용자 대신 작업을 수행할 수 있는 권한을 위임하는 객체.

Trust Policy(ec2.amazonaws.com)가 명시된 ec2trust.json으로 aws iam create-role 생성.

이후 aws iam attach-role-policy로 앞서 만든 정책을 역할에 바인딩.

4) 인스턴스 프로파일을 통한 EC2 권한 부여 (CLI 실습)

키페어 생성: aws ec2 create-key-pair 결과값을 .pem 파일로 저장 후 chmod 400 적용.

EC2 생성: aws ec2 run-instances (이미지, 인스턴스 타입, 키, 보안그룹, 서브넷 ID 지정).

인스턴스 프로파일: aws iam create-instance-profile 생성 -> 역할 추가 -> aws ec2 associate-iam-instance-profile로 가상머신에 프로파일 연결.

결과 테스트: ssh로 접속하여 내부에서 aws s3 ls가 에러 없이 실행되는지 확인.

7. EC2 서버 구성 및 EBS Block Storage 연결

1) EC2 (Elastic Compute Cloud) 가상머신 구성

물리적 머신의 일부에 액세스하는 가상 머신 서비스입니다.

OS 이미지 (AMI): 사전 설치된 소프트웨어 번들. AWS는 맞춤형 하드웨어와 KVM을 결합한 Nitro 가상화(HVM)를 사용하여 베어메탈 수준의 성능을 제공합니다.

인스턴스 유형(크기 및 최적화):

T: 짧은 시간 높은 성능 발휘 (기본 성능형, 실습용 t3.micro)

M: CPU와 메모리 균형 (범용)

C: 컴퓨팅 최적화 (높은 CPU)

R: 메모리 최적화

D/I: 스토리지 최적화 (HDD/SSD)

X: 방대한 메모리 최적화

F: FPGA 기반 가속

P/G/CG: GPU 가속

키페어 구성: 비대칭 키 사용. Public Key는 클라우드에, Private Key는 로컬 유저가 보관.

2) 네트워크 및 보안그룹 (Firewall) 방화벽

보안 그룹: 인스턴스에 들어오고 나가는 인바운드(Ingress)/아웃바운드(Egress) 트래픽 제어.

규칙 정의: 방향, IP 프로토콜, 포트, 원본/대상을 기반으로 허용 여부 결정.

모범 사례: 꼭 필요한 포트(웹서버의 경우 HTTP 80, HTTPS 443)만 열어 가장 제한적인 규칙 적용(사람의 실수 방지).

3) 가상머신 연결 방법

Public IP 활용: 브라우저에서 직접 연결 기능 사용.

SSM Session Manager 활용: SSH 포트를 열지 않아도 연결 가능하여 보안 수준이 매우 높음.

EC2에 AmazonSSMManagedInstanceCore 정책이 부여된 IAM 역할을 생성 및 업데이트하고 재부팅하면 세션 매니저를 통한 연결 활성화.

4) EBS (Elastic Block Store) 볼륨 추가

파일 시스템 용량 확보를 위해 가상머신에 연결하는 블록 장치입니다.

볼륨 생성 시 가상머신과 동일한 가용영역(AZ)으로 설정 필수.

생성 후 EC2 인스턴스에 연결하고 서버 내에서 lsblk로 디스크 장착 여부 확인 (이후 파일시스템 생성 및 마운트 진행).

8. VPC 네트워크 연결

1) VPC (Virtual Private Cloud) 구성

공용 클라우드 환경 안에 다른 사람과 격리된 '나만의 독립적인 사설 클라우드 환경'을 구성해 줍니다. IP 대역, 서브넷, 라우팅 테이블, 게이트웨이 등을 마음대로 제어할 수 있습니다.

사설 IP 대역: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

VPC 생성 시 기본 네트워크 ACL, DHCP 옵션 세트, 기본 라우팅 테이블이 자동 구성됩니다. (세부 조정 시 새로 만드는 것 권장).

2) 서브넷 (Subnet) 구성

VPC CIDR 범위를 넘지 않는 선에서 용도별로 네트워크를 분할합니다.

외부 통신용 Public Subnet / 클라우드 내부 통신용 Private Subnet. (기본 생성 시 Private 상태).

서브넷 설정 편집에서 '퍼블릭 IPv4 주소 자동 할당 활성화'를 켜면 배치되는 VM이 공인 IP를 받음.

3) 인터넷 게이트웨이 (IGW) 및 라우팅 테이블

서브넷을 Public으로 만들기 위한 과정입니다.

인터넷 게이트웨이: VPC 내부 트래픽을 외부 인터넷으로 내보내는 문. 생성 후 VPC에 연결 (하나의 VPC당 1개의 IGW만 가능).

라우팅 테이블: 트래픽의 목적지 경로를 지정. 새로운 라우팅 테이블 생성 후 0.0.0.0/0 (모든 트래픽)의 대상을 '인터넷 게이트웨이'로 향하게 편집하고, 해당 서브넷에 연결 명시.

4) NAT 게이트웨이

외부에서 들어오는 요청은 차단하고, 내부에서 외부로 나가는 요청(소프트웨어 패치 다운로드 등)만 허용하는 게이트웨이입니다.

전송 중인 패킷의 IP 헤더를 수정(다시 매핑).

프라이빗 서브넷의 인터넷 통신을 위해 사용 (NAT 인스턴스 방식도 존재).

5) VPC 엔드포인트

VPC 내부가 아닌 AWS에서 직접 관리하는 서비스(S3, DynamoDB 등)에 인터넷 게이트웨이나 NAT 없이 비공개(Private)로 연결하게 해주는 가상 장치입니다. (보안 강화, 비용 절감 이점).

유형:

인터페이스 엔드포인트: 다양한 서비스 지원.

게이트웨이 엔드포인트: S3와 DynamoDB 전용.

생성 시 VPC와 라우팅 테이블을 선택하면 해당 경로를 통해 직접 비공개 통신이 가능해집니다.

프로젝트 목적이 '트래픽 스파이크 처리', '서버리스 지향', '운영 부담 최소화' 그래서 당연히 EC2보다 관리가 편한 AWS App Runner를 쓰기로 결정했고, Role 권한 부여하고 인프라 설계를 어느정도 한상태였는데... 막상 APP runner를 사용해서 배포하려니까 서울 리전(ap-northeast-2)에는 App Runner가 출시조차 안 되어 있었음.........

AI말을 너무 신뢰하지말자

를 다시금 새기게됌

제미나이 응답

1. 도쿄 리전(ap-northeast-1) 사용하기 (적극 추천) ⭐
아시아에서 App Runner를 지원하는장 가까운 리전이 바로 도쿄입니다.

한국(서울)과 도쿄는 지리적으로 가까워서 네트워크 지연 시간(Latency) 차이가 거의 느껴지지 않습니다. 동아리 프로젝트나 테스트용 API 서버로는 전혀 지장이 없습니다.

2. ECS Fargate
프로젝트 목적(트래픽 스파이크 처리, 서버리스 지향, 운영 부담 최소화)에 제일 부합
App Runner가 내부적으로 ECS Fargate 기반이라 사실상 같은 기술을 직접 쓰는 것

우리의 선택 -> 2번

왜 ECS Fargate?

사실 App Runner도 내부적으로는 ECS Fargate 기반으로 돌아감

• 서버 관리 전무: EC2처럼 OS 패치나 인프라 관리에 리소스를 쏟을 필요 없이 컨테이너만 관리하면 됌
• Auto Scaling & VPC 연동: CPU/메모리 기반 확장이 자유롭고 VPC 연동이 기본이라 ElastiCache 연동이 자연스러움
• 기존 자산 유지: App Runner를 위해 빌드해 둔 Dockerfile → ECR → Task Definition → Service 파이프라인과 GitHub Actions CI/CD 구조를 거의 그대로 가져갈 수 있었음

다시 한번 생각해야할것

AI를 너무 신뢰하지는 말자

문제 상황 (Symptom)

• 새로운 기능을 구현하고 ECR(Elastic Container Registry)에서 최신 도커 이미지를 받아 배포하려 했으나, "No space left on device" 에러와 함께 배포가 무한 실패함.
• EC2 쉘(Shell)에 접속해 df -h와 docker images를 확인한 결과, AI 모델이 포함된 도커 이미지 용량이 너무 커서 남은 용량이 거의 없었음.

원인 분석 (Cause)

• AI 이미지의 비대화: Python AI 서버 이미지가 딥러닝 라이브러리와 모델 파일을 포함하면서 수 GB 단위로 커짐.
• 인스턴스 자원 한계: 기존 t3.micro 인스턴스는 디스크 용량뿐만 아니라 메모리(1GB)도 부족하여, 무거운 도커 이미지를 압축 해제하고 실행하는 과정을 버티지 못함.

해결 방법 (Solution)

1. 인스턴스 타입 업그레이드: CPU와 메모리 사양을 높이기 위해 인스턴스를 t3.micro에서 t3.small로 스케일 업(Scale-up)함.
2. 도커 환경 정리: docker system prune -a 명령어를 통해 사용하지 않는 오래된 이미지와 컨테이너를 삭제하여 가용 공간을 확보함.
3. EBS 볼륨 최적화: 인스턴스 타입 변경과 함께 루트 볼륨(EBS) 크기를 증설하여 향후 이미지 업데이트에 대비함.

Issue 2. AI 퀴즈 생성 데이터의 DB 저장 정합성 오류

문제 상황 (Symptom)

• Python AI 서버에서 퀴즈 생성 로직은 정상적으로 동작하여 응답을 보내주지만, Spring Boot 서버에서 이를 받아 DB(Content, Question 테이블 등)에 저장할 때 데이터가 누락되거나 저장되지 않는 현상 발생.

원인 분석 (Cause)

1. API 데이터 정합성 불일치: Python 서버가 보내주는 JSON 필드 구조와 Spring Boot의 DTO 구조가 미세하게 달러 역직렬화(Deserialization) 과정에서 데이터가 유실됨.
2. 트랜잭션 관리 실패: 퀴즈 생성 요청은 성공했으나, 연관된 여러 테이블(Step -> Content -> Choice)에 데이터를 넣는 과정에서 하나라도 실패할 경우 전체가 롤백(Rollback)되어야 하는데, 이 처리가 미흡하여 데이터가 꼬임.
3. 영속성 컨텍스트 이슈: 부모 엔티티가 저장되기 전에 자식 엔티티를 저장하려다 외래 키(FK) 제약 조건 위반이 발생함.

해결 방법 (Solution)

1. DTO 및 검증 로직 강화: Python 서버와의 규약을 재정의하고, @Valid를 통해 들어오는 데이터의 정합성을 최우선으로 검증함.
2. Cascade 옵션 및 연관관계 편의 메서드 활용: JPA CascadeType.ALL 설정을 통해 부모 엔티티(Step) 저장 시 자식 엔티티들이 한 번에 안전하게 저장되도록 구조를 개선함.
3. 트랜잭션 원자성 확보: 퀴즈 저장 서비스 로직에 @Transactional을 적용하여 전체 프로세스가 "All or Nothing"으로 동작하게 하여 데이터 무결성을 보장함.

회고를 마치며

"인프라는 한 번 구축하면 끝나는 것이 아니라, 서비스 규모와 데이터 크기에 따라 지속적으로 모니터링하고 스케일링해야 한다는 것을 배웠습니다. 또한, 서로 다른 언어(Spring-Python)로 구성된 서버 간 통신에서는 데이터 정합성을 맞추는 것이 시스템 안정성의 핵심임을 깨달았습니다...어렵다 ㅠㅠㅠ"

• 문제 상황: 여러 명의 팀원이 채팅방에서 동시에 AI 요약(@mates)을 호출하거나 상충하는 데이터를 입력할 때, AI 서버로 중복 요청이 가거나 DB의 요약 데이터가 덮어씌워지는(Lost Update) 데이터 정합성 파괴 현상 발생.

• 해결 과정:

  1. 입구 통제 (Redis 분산 락): AI 호출 시 projectId를 Key로 Redis 분산 락(Distributed Lock)을 걸어, 누군가 요약을 진행 중일 때는 다른 팀원의 중복 호출을 차단함.
  2. 출구 방어 (JPA 낙관적 락): AI 요약본을 DB에 최종 업데이트할 때 @Version을 활용한 낙관적 락(Optimistic Lock)을 적용. 읽은 시점과 쓰는 시점의 버전이 다르면 예외를 발생시키고 안전하게 롤백하여 데이터 오염 방지.

• 결과: 100%의 데이터 정합성을 보장하는 안전한 실시간 협업 환경 구축 완료.

  // 1. 엔티티에 낙관적 락 적용 (출구 방어)
  @Entity
  public class ProjectSummary {
    @Id @GeneratedValue
    private Long id;
    private String content;
  
    @Version // JPA Optimistic Lock
    private Long version; 
  }
  

// 2. 분산 락을 활용한 AI 호출 로직 (입구 방어) @Service @RequiredArgsConstructor public class AISummaryService { private final RedissonClient redissonClient; private final SummaryRepository summaryRepository;

public void requestAiSummary(Long projectId) {
    RLock lock = redissonClient.getLock("AI_LOCK:" + projectId);
    try {
        // 락 획득 시도 (대기 시간 0초, 락 유지 10초)
        boolean isLocked = lock.tryLock(0, 10, TimeUnit.SECONDS);
        if (!isLocked) {
            throw new CustomException("이미 AI가 요약을 진행 중입니다.");
        }

        // AI 호출 및 DB 업데이트 로직 (낙관적 락 충돌 시 ObjectOptimisticLockingFailureException 발생)
        updateSummaryWithAI(projectId);

    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    } finally {
        if (lock.isLocked() && lock.isHeldByCurrentThread()) {
            lock.unlock(); // 작업 완료 후 락 해제
        }
    }
}

}

#### 2. 다중 서버(Scale-out) 환경에서의 WebSocket 세션 동기화 문제
* **문제 상황:** 단일 서버에서는 STOMP 기반 채팅이 잘 동작했으나, 트래픽 분산을 위해 백엔드 서버를 여러 대(Scale-out)로 늘렸을 때 서로 다른 서버에 접속한 유저 간에 메시지가 전달되지 않는 브로드캐스팅 단절 문제 발생.
* **해결 과정:** * **Redis Pub/Sub 도입:** 기존에 세션 관리용으로 쓰던 Redis의 Pub/Sub(발행/구독) 기능을 메세지 브로커로 확장 활용.
    * A서버의 유저가 메시지를 보내면 Redis로 Publish하고, Redis가 연결된 모든 서버(B, C 등)로 메시지를 브로드캐스팅하여, 어떤 서버에 붙어있든 실시간 통신이 끊기지 않도록 분산 웹소켓 아키텍처 재설계.
* **결과:** 대규모 접속 시에도 안정적인 채팅이 가능한 확장성(Scalability) 확보.

```java
// 1. 메시지 발행 (Publish)
@MessageMapping("/chat/message")
public void sendMessage(ChatMessage message) {
    // DB에 메시지 선 저장 (단일 진실 공급원)
    chatService.saveMessage(message);
    // Redis의 채팅 채널로 메시지 발행
    redisTemplate.convertAndSend("CHAT_ROOM:" + message.getProjectId(), message);
}

// 2. 메시지 구독 (Subscribe) - RedisMessageListenerContainer 설정
@Service
public class RedisSubscriber implements MessageListener {
    private final SimpMessageSendingOperations messagingTemplate;

    @Override
    public void onMessage(Message message, byte[] pattern) {
        // Redis에서 메시지를 수신하면, 자신(서버)에게 연결된 웹소켓 클라이언트들에게 브로드캐스팅
        ChatMessage chatMessage = objectMapper.readValue(message.getBody(), ChatMessage.class);
        messagingTemplate.convertAndSend("/sub/chat/room/" + chatMessage.getProjectId(), chatMessage);
    }
}

3. 외부 API(Notion) Rate Limit(호출 제한) 및 트랜잭션 병목 대응

• 문제 상황: 프로젝트 완료 후 Notion으로 템플릿을 내보낼 때, 다수의 팀이 동시에 요청할 경우 Notion API의 엄격한 호출 횟수 제한(429 Too Many Requests)에 걸려 실패. 게다가 동기식으로 API를 기다리다가 우리 DB 커넥션 풀까지 고갈될 위험 감지.
• 해결 과정:
  1. 트랜잭션 분리: 우리 DB에 데이터를 안전하게 커밋(Commit)하여 완전히 저장한 이후에만 외부 API(Notion)를 호출하도록 설계하여, 외부 장애가 내부 시스템으로 번지지 않도록 격리.
  2. 비동기 큐 및 백오프: Redis 작업 큐(Task Queue)를 도입해 쏟아지는 노션 생성 요청을 담아두고, 워커(Worker)가 속도를 조절하며 순차 처리. API 에러 발생 시 대기 시간을 점진적으로 늘리는 '지수 백오프(Exponential Backoff)' 적용 및 실패 시 사용자 재시도(Retry) 로직 구현.
• 결과: 외부 API 장애로부터 내결함성(Fault Tolerance)을 갖춘 견고한 시스템 완성.

  // 1. DB 트랜잭션과 외부 API 분리 (@TransactionalEventListener 활용)
  @Service
  public class ProjectService {
    @Transactional
    public void finishProject(Long projectId) {
        projectRepository.updateStatus(projectId, "COMPLETED");
        // DB 커밋이 완료된 후 이벤트 발행
        eventPublisher.publishEvent(new ProjectCompletedEvent(projectId));
    }
  }
  

// 2. 이벤트 리스너에서 비동기로 Notion API 호출 및 재시도 로직 적용 @Component public class NotionApiEventListener {

// 트랜잭션이 성공적으로 커밋된 후에만 실행됨
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
@Async // 비동기 워커로 넘김 (API 병목 방지)
// 429 에러 발생 시 1초, 2초, 4초 대기하며 최대 3번 재시도
@Retryable(value = {RateLimitException.class}, maxAttempts = 3, backoff = @Backoff(delay = 1000, multiplier = 2))
public void handleProjectCompletedEvent(ProjectCompletedEvent event) {
    notionApiClient.exportToNotion(event.getProjectId());
}

// 최종 실패 시 처리 (Fallback)
@Recover
public void recoverNotionExport(RateLimitException e, ProjectCompletedEvent event) {
    log.error("Notion API 최대 재시도 횟수 초과. 프로젝트 ID: {}", event.getProjectId());
    // DB에 상태를 'FAILED'로 기록하고 사용자에게 '재시도 버튼' 노출 유도
    projectRepository.updateExportStatus(event.getProjectId(), "FAILED");
}

}

#### 4. AI 환각(Hallucination) 및 비정형 JSON 응답에 대한 서버 생존성 확보
* **문제 상황:** 프롬프트로 JSON 형식을 강제했음에도, AI가 가끔 규격에 맞지 않는 엉뚱한 응답을 보내거나 정의되지 않은 Key를 던질 때 백엔드 서버에서 파싱 에러(Mapping Exception)가 발생하며 프로세스가 중단됨.
* **해결 과정:**
    * **방어적 프로그래밍과 Fallback:** Spring Boot 단에서 철저한 객체 검증(DTO Validation) 및 Try-Catch 예외 처리 적용. 에러 포착 시 서버를 멈추지 않고(Graceful Degradation), 사용자에게 알림을 보낸 뒤 **'가장 최근에 검증된 성공 데이터(Last Known Good State)'를 DB에 유지(Fallback)**하여 데이터 유실 방지.
* **결과:** AI의 실수에도 시스템이 무너지지 않고 사용자 데이터를 100% 보호하는 안전장치 마련.

```java
@Service
public class AiResponseHandler {

    // JSON에 정의되지 않은 필드가 들어와도 무시하도록 ObjectMapper 설정
    private final ObjectMapper objectMapper = new ObjectMapper()
            .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);

    @Transactional
    public void processAiResponse(Long projectId, String aiRawResponse) {
        ProjectSummary currentSummary = summaryRepository.findByProjectId(projectId);

        try {
            // AI 응답 파싱 시도
            AiSummaryDto dto = objectMapper.readValue(aiRawResponse, AiSummaryDto.class);

            // 검증 성공 시에만 데이터 업데이트
            currentSummary.updateContent(dto.getContent());

        } catch (JsonProcessingException e) {
            // 파싱 실패 시 서버를 죽이지 않고 로그만 남김 (Graceful Degradation)
            log.error("AI 응답 JSON 파싱 실패. Raw Data: {}", aiRawResponse, e);

            // TODO: 슬랙 등 모니터링 채널로 알림 발송

            // 기존 데이터(currentSummary)는 롤백하지 않고 그대로 유지됨 (안전한 Fallback)
        }
    }
}

• 데이터베이스(DB) 구조화된 정보 또는 데이터의 조직화된 모음이며, 일반적으로 DBMS에 의해 제어됨
• 관계형 데이터베이스(Relational DB) 구조화된 데이터를 테이블 형태로 저장 엄격한 스키마를 따르며 SQL(Structured Query Language)을 사용하여 데이터를 조작
• 비관계형 데이터베이스(Non-Relational DB) 비정형 데이터를 저장하며 고정된 스키마가 없음 대량의 분산 데이터 저장 및 다양한 형태의 데이터를 빠르게 처리하는 데 적합함

RDS의 배포 방식 비교

• On-Premise: 사용자가 직접 물리적 서버를 구축하고 데이터베이스를 설치 및 관리
• AWS EC2: AWS 가상 서버(EC2) 위에 사용자가 직접 DB 소프트웨어를 설치하고 운영 체제부터 DB까지 관리
• AWS RDS: AWS에서 제공하는 완전 관리형 관계형 데이터베이스 서비스로, 관리 부담이 가장 낮음

AWS RDS (Relational Database Service)

• 개요: AWS 클라우드에서 관계형 데이터베이스를 쉽게 설치, 운영 및 확장할 수 있도록 지원하는 웹 서비스
• 주요 장점:
  • 간편한 관리: 패치, 백업 등 운영 자동화
  • 가용성 및 안정성: 자동 백업 및 스냅샷 기능을 제공하며 Multi-AZ를 통한 장애 복구 지원
  • 보안성: AWS 네트워크 보안 기능(VPC) 및 암호화 적용 가능
  • 확장성: Read Replica를 통한 읽기 성능 확장 및 스토리지 유연성 확보
  • 비용 효율성: 사용한 만큼만 비용을 지불하는 구조

가용성 및 성능 확장 기술

• Multi-AZ (다중 가용 영역):
  • 다른 가용 영역(AZ)에 데이터베이스 복사본(Standby)을 생성하고 데이터를 동기화함
  • 장애 감지 시 자동으로 대기 인스턴스로 대체(Failover)되어 서비스 연속성을 보장함
• Read Replica (읽기 전용 복제본):
  • 읽기(Read) 쿼리의 성능 향상과 부하 분산을 목적으로 생성함
  • 주 인스턴스로부터 비동기 방식으로 데이터를 복제함
  • 읽기 중심 워크로드에서 Scale-Out을 통해 처리량을 향상시킴

SAA (Solutions Architect Associate) 실무 사례

• 문제 상황: RDS 사용 중 통계용 데이터를 읽어올 때 성능 저하가 발생하는 경우
• 해결책: RDS Read Replica를 생성하여 운영 DB의 부하를 줄이고, 읽기 전용 쿼리를 복제본에서 처리하도록 구성!!

SQL 및 관계형 데이터베이스(RDBMS)

• 관계형 데이터베이스에서 데이터를 저장, 조회, 수정, 삭제하기 위해 사용하는 언어
• 특징:
  • 정해진 구조(Schema)에 따라 테이블에 데이터를 저장
  • 행(Row)과 열(Column)이 있는 표 형태의 구조를 가짐
• Oracle, MySQL, PostgreSQL 등

NoSQL 및 비관계형 데이터베이스

• 비관계형 데이터베이스 환경에서 데이터를 관리하는 방식임
• 특징:
  • 정형화되지 않은 유연한 구조를 사용하여 가용성과 확장성이 높음
  • 고성능 처리에 최적화되어 있으며 SNS(Instagram, Facebook) 등에서 주로 사용됨
• MongoDB, AWS DynamoDB 등

AWS DynamoDB 개요

• AWS에서 제공하는 서버리스 기반의 완전관리형 NoSQL 데이터베이스 서비스
• 주요 특성:
  • 완전관리형: 장비 운영부터 솔루션 설치 및 운영까지 모든 인프라를 AWS에서 담당
  • 고성능: 10ms 미만의 지연 시간으로 데이터를 처리할 만큼 매우 빠름
  • 내구성: SSD에 저장되며 리전 내 여러 가용 영역(AZ)에 걸쳐 자동 복제
  • Auto-Scaling: 요청량에 따라 테이블의 읽기/쓰기 용량을 자동으로 조절

DynamoDB 핵심 구성 요소

• 테이블(Tables) 데이터의 집합체 (예: People 테이블, Cars 테이블)
• 항목(Items) 테이블을 구성하는 개별 데이터 단위 (RDBMS의 행에 해당)
• 속성(Attributes) 항목을 구성하는 세부 데이터 요소 (예: ID, 이름, 주소 등)
• 유연한 스키마 기본 키(PK)를 제외하고는 속성이나 데이터 형식을 미리 정의할 필요가 없으며, 각 항목은 고유하거나 중첩된 속성을 가질 수 있음

DynamoDB의 키(Key) 구조

• Partition Key (파티션 키):
  • RDBMS의 Primary Key와 유사한 역할로 테이블 내 유일한 값이어야 함
  • 데이터가 저장될 물리적 공간(Partition)을 결정하며 일치 검색(Equal)만 지원
• Sort Key (정렬 키):
  • 같은 파티션 내에서 데이터를 정렬하는 기준
  • 일치, 부등호, 포함 등 범위 지정 검색을 지원하여 정교한 쿼리를 가능하게 함

Lambda를 활용한 DynamoDB 최적화

• Batch 작성 지원 BatchWriteItem API를 통해 한 번에 최대 25개의 항목을 삽입할 수 있어 데이터 추가 효율이 높음
• 자동화 운용 CloudWatch Events와 연동하여 특정 주기마다 Lambda 함수를 실행, 정기적인 데이터 처리가 가능
• Join 기능 구현 DynamoDB는 자체적인 Join을 지원하지 않으므로, 복잡한 데이터 결합이 필요한 경우 Lambda를 통해 로직으로 구현

• 정의: 클라우드 컴퓨팅 제공업체를 통해 데이터와 파일을 인터넷에 저장하는 모델. 사용자는 퍼블릭 인터넷 또는 전용 프라이빗 네트워크 연결을 통해 스토리지에 액세스 가능.
• 클라우드 사용 시 이점: 비용 효율성, 민첩성 향상, 더 빠른 배포, 효율적인 데이터 관리, 확장성
• 스토리지 종류: File Storage, Block Storage, Object Storage (사용자가 데이터를 어떻게 읽고 쓰는지 인터페이스 관점에서 구분)

2. 스토리지 유형별 상세 분석

① Block Storage (예: Amazon EBS)

• 역할: 물리적 하드웨어(HDD, SSD)와 비슷한 역할을 수행하며 이를 흉내 냄. 가상머신(EC2)은 이를 자신의 하드디스크라고 생각함
• 특징: 스토리지 어디에 저장되어 있는지 등의 세부 작업은 직접 하지 못함(물리적 디바이스 관리는 OS가 담당)
• 데이터 처리: 데이터를 Block 형태로 Read/Write 함. 빠른 속도를 위해 각 블록에 고유 식별자(ID#)를 부여
• 기타: 백업 기능을 제공하기도 하며 SAN(Storage Area Network) 역할을 수행

② File Storage (예: Amazon EFS)

• 역할: 데이터를 파일 단위의 계층 구조로 저장함. 애플리케이션에 가장 널리 사용되는 유형
• 특징: 데이터를 파일 단위로 다루며 직접 데이터를 관리함(서버 기능도 수행). NFS, NAS 기술 사용 가능함. 로컬 하드 드라이브와 유사한 접근 방식을 가짐
• 사용 시나리오: 블록 스토리지에 '서버'가 추가된 느낌으로, 여러 서버나 사용자가 동일 파일 시스템에 동시 접근하거나 네트워크를 통한 파일 공유가 필요할 때 사용

③ Object Storage (예: Amazon S3)

• 역할: 대용량 미디어 파일, 이미지, 백업 등 비정형 데이터 저장을 위한 스토리지
• 특징: 데이터를 오브젝트(파일+메타데이터) 단위로 다룸. 전송된 형식 그대로 객체 데이터로 저장하며, 사용자가 직접 메타데이터 지정 가능
• 접근 방식: 객체는 '보안 버킷'이라는 공간에 저장되며, HTTP 프로토콜 기반 REST API 호출을 통해 접근
  • REST API란? HTTP의 장점을 살려 자원을 이름으로 구분하고 상태를 주고받는 API 방식.
• 사용 시나리오: 정적 웹 콘텐츠 호스팅, 전 세계 데이터센터 분산, 저렴한 비용으로 장기 보관 시 유리

3. Amazon S3 (Simple Storage Service) 심화

• 주요 특징: 확장성이 뛰어나 저장 용량을 신경 쓸 필요가 없으며, 버전 관리/암호화/복제 기능으로 데이터를 보호. 사용한 만큼만 비용을 지불
• 구성 요소:
  • 버킷(Bucket): 최상위 디렉토리(컨테이너). 폴더와 유사함. 무제한 객체 저장 가능. 계정당 최대 100개 생성 가능. 전 세계에서 유일한 이름을 가져야 함
  • 객체(Object): 버킷 안의 파일. 크기는 최대 5TB. Key(이름)와 버전 ID로 식별됨.
• 객체의 상세 구성: Key(이름), Value(데이터), Version ID, Metadata(수정일, 타입, 소유자, 사이즈), 태그, 액세스 제어 정보.
• 태그 활용 보안: * s3:ExistingObjectTag: 기존 객체에 특정 태그가 있는지 확인.
  • s3:RequestObjectTagKeys: 허용할 태그 키 제한
  • s3:RequestObjectTag: 허용할 태그 키 및 값 제한
  • 예시: environment: production 태그가 있는 객체만 읽기 허용 가능.
• URL 형식 예시: https://awsinaction.s3.ap-southeast-2.amazonaws.com/img/cat.png
  • 버킷명: awsinaction / 리전: ap-southeast-2 / 키네임: img/cat.png

4. S3 보안 및 관리 기능

데이터 암호화

• 서버 측 암호화 (Server-Side Encryption): AWS가 자동으로 보호. 업로드 시 암호화, 다운로드 시 복호화
  • 종류: SSE-S3(기본), SSE-KMS, DSSE-KMS, SSE-C.
  • 요청 헤더 예시: "x-amz-server-side-encryption": "AES256"
• 클라이언트 측 암호화: 내 로컬 컴퓨터에서 암호화 후 업로드. 제3자에게 노출을 원천 방지하나 관리 복잡성이 높음

액세스 제어 (Access Control)

• 기본값은 Private임 (통째로 퍼블릭 설정 안 됨)
• IAM: 사용자/역할 기준. 내 계정 내 유저가 무엇을 할 수 있는지 제어
• ACL: 계정 단위 기준. 다른 AWS 계정에 대해 읽기/쓰기 권한 부여
• 버킷 정책: 버킷/객체 기준. 단일 버킷 내 모든 객체 권한을 세부 구성(IP나 도메인 제한 가능).
• CORS: 출처가 다른 서버 간의 리소스 공유를 허용(Access-Control-Allow-Origin 헤더 사용).
• Pre-signed URL: 임시 URL 발급. 특정 시간 동안만 권한 없는 사용자에게 액세스 부여. 생성자가 유효한 권한을 보유해야 함.

스토리지 관리

• 버전 관리: 업데이트 시 버전이 추가됨. 실수로 삭제/덮어쓰기 시 복원 가능. 한 번 활성화 시 비활성화 불가.
• 객체 복제: 동일 리전(SRR) 또는 타 리전(CRR)에 비동기 자동 복제. 배치 복제는 기존 객체 복제 시 사용.
• 스토리지 클래스: 요구사항에 맞는 클래스 선택 가능.
• 수명 주기(Lifecycle):
  • 전환 작업: 일정 기간 후 저렴한 클래스로 이동 (30일 뒤 IA, 60일 뒤 Glacier 등).
  • 만료 작업: 일정 기간 후 객체 자동 삭제.

5. Amazon CloudFront (CDN)

• 정의: 글로벌 콘텐츠 전송 네트워크 서비스. 짧은 지연 시간과 빠른 속도로 데이터 전송. S3 앞단에서 보안 기능 제공
• CDN 원리: 여러 서버에 데이터를 분산 캐싱하여 사용자에게 가장 가까운 서버에서 배포
• 주요 인프라:
  • Edge Location: 원본 서버의 데이터를 캐싱하여 사용자에게 제공하는 지리적 거점
  • Regional Edge Caches(REC): 오리진과 엣지 사이의 캐시 계층. 엣지에 없으면 REC를 먼저 확인하여 오리진 부하를 줄임.
• 동작 방식: 요청 → 엣지 확인 → 캐시 있으면 응답 / 없으면 오리진 포워딩 → 엣지 캐싱 후 응답.
• Origin Server: S3(정적) 및 EC2/ELB(동적) 연결 가능. 동적 콘텐츠는 TTL 동안 수정사항이 안 보일 수 있으므로 주의 필요.
• 보안 및 전송 최적화:
  • HTTPS 지원: 오리진이 지원 안 해도 CloudFront에서 설정 가능.
  • 지리적 제한: 특정 지역 접근 제한 가능.
  • Signed URL: 특정 파일 하나에 대해 허용된 사용자만 접근 허용 (유료 결제 등)
  • Signed Cookie: 다수의 파일에 대한 액세스 제공 (로그인한 유료 회원 등)

• 빌드 파일 준비: 배포할 웹 프로젝트의 빌드 파일을 다운로드하고 압축을 해제

2. Amazon S3 버킷 생성 및 설정

1. S3 콘솔 접속: [버킷 만들기] 버튼을 클릭
2. 리전 및 이름 설정:
   • 리전: 사용자 데이터 지연 시간 단축과 비용 절감을 위해 지리적으로 가까운 리전(예: 서울)을 선택
   • 이름: 전역적으로 고유한 이름을 지정 (중복 불가)
3. 생성 완료: 그 외 설정은 기본값을 유지하고 [버킷 만들기]를 완료

3. 정적 파일 업로드

1. 파일 업로드: [업로드] 버튼을 클릭
2. 주의사항: 빌드 폴더 자체를 올리는 것이 아니라, 빌드 폴더 내부에 있는 개별 파일 및 폴더들을 선택하여 업로드 (예: index.html, static/ 등)

4. S3 정적 웹사이트 호스팅 활성화

1. 호스팅 설정: 버킷 상단 [속성] 탭 → 최하단 [정적 웹사이트 호스팅] 편집 클릭
2. 활성화: * 인덱스 문서: index.html 입력
   • 오류 문서: index.html 입력 (SPA 라우팅 대응)
3. 저장 후 생성된 엔드포인트로 접속
   • 403 Forbidden 에러 발생 (정상)
   • 보안을 위해 외부 접근이 막혀 있으므로 CloudFront를 사용해야함

5. CloudFront 배포 생성 (CDN 설정)

1. CloudFront 콘솔 접속: [배포 생성] 버튼을 클릭
2. 원본(Origin) 설정:
   • 오리진 도메인: 앞서 생성한 S3 버킷을 선택
   • 원본 액세스: 원본 액세스 제어 설정(OAC, 권장)을 선택
   • OAC 생성: [Create new OAC] 버튼 클릭 → 기본 설정 유지 후 [Create] 클릭
3. 보안 및 기타 설정:
   • WAF: 보안 보호 비활성화 선택 (실습용이니)
   • 기본값 루트 객체: index.html 입력
4. 배포 완료: [배포 생성]을 누르면 도메인이 생성됌
   • 하지만 여전히 접속 안 됨! CloudFront가 S3에 접근할 권한이 아직 없기 때문..

6. S3 버킷 정책 수정 (권한 부여)

1. 정책 복사: * CloudFront 콘솔 → 생성한 배포 선택 → [원본] 탭 → 원본 선택 후 [편집]
   • [정책 복사] 버튼을 클릭하여 CloudFront가 생성해준 정책 문구(JSON)를 복사
2. S3에 정책 적용:
   • S3 콘솔 접속 → 해당 버킷 선택 → [권한] 탭
   • [버킷 정책] 편집 버튼 클릭 → 복사한 내용을 붙여넣고 저장
3. 이제 CloudFront 배포 도메인으로 접속하면 웹사이트가 정상적으로 나타남

왜 이렇게 복잡하게 하니?

• S3 단독 호스팅: 보안에 취약하며 속도가 느릴 수 있음
• CloudFront 병행:

1. 보안 - S3를 외부에 직접 공개하지 않고 CloudFront만 통하게 하여 데이터를 보호 (OAC 설정의 이유)
2. 속도 - 전 세계 Edge Location에 콘텐츠를 캐싱하여 사용자에게 더 빠르게 전달
3. 비용 - 캐싱을 통해 S3 직접 요청 횟수를 줄여 비용을 최적화

• 작업: 리전 선택(서울) → VPC 생성 (이름 태그 설정)
• 설정: DNS 확인 및 DNS 호스트이름 활성화 체크
• ❓ IPv4 CIDR를 왜 수동으로 입력?
  • VPC는 나만의 독립적인 가상 네트워크 영토를 선언하는 것. 수동으로 입력하는 이유는 내가 관리할 네트워크의 크기와 주소 범위를 직접 결정하기 위해서!!
  • 특히 기업 환경에서는 다른 VPC나 회사 내부망(On-premise)과 연결할 때 주소가 겹치면 통신이 불가능함. 따라서 나중에 확장성이나 연결성을 고려하여 겹치지 않는 적절한 크기(예: /16)를 직접 지정해야하기 때문에 수동으로 입력

Step 2. Public 및 Private 서브넷 생성

• VPC 범위: 10.0.0.0/16
• 서브넷 구성: 2a, 2c 가용 영역에 각각 퍼블릭/프라이빗 배치

1. public subnet : 10.0.1.0/24 -> ap-northeast-2a
2. private subnet : 10.0.2.0/25-> ap-northeast-2a
3. public subnet : 10.0.3.0/24 -> ap-northeast-2c
4. private subnet : 10.0.4.0/25 -> ap-northeast-2c

• ❓ 왜 Public이 Private보다 더 많은 주소를 할당?
  • 실무에서는 사실 반대인 경우가 더 많긴함. 보통 DB나 내부 로직이 돌아가는 Private 영역에 서버가 훨씬 많이 들어가기 때문 , 하지만 학습용 실습이나 특정 아키텍처에서는 외부와 소통하는 서비스(웹 서버, 로드밸런서, NAT 게이트웨이 등)가 위치하는 Public 영역을 넉넉하게 잡음

• 주소 할당량은 정답이 있는 게 아니라, 해당 서브넷에 얼마나 많은 리소스를 배치할 것인가에 따른 설계자의 의도.. 실습에서는 Public 통신 테스트를 위해 좀 더 넉넉하게 할당한 것

Step 3. Public 서브넷 자동 할당 IP 설정

• Public 서브넷 2개에 대해 '퍼블릭 IPv4 주소 자동 할당' 활성화
• 이 설정을 켜야만 이 서브넷에 생성되는 EC2들이 부팅될 때 자동으로 인터넷 주소(Public IP)를 부여받아 우리가 밖에서 접속할 수 있게 됌..

Step 4. EC2 인스턴스 생성

• AMI: ubuntu
• 인스턴스 유형: t2.micro
• 키페어: 생성 또는 있는 거 사용
• Public EC2: 보안그룹(SSH, HTTP), 퍼블릭 IP 활성화 (외부 접속용)
• Private EC2: 보안그룹(SSH, HTTP), 퍼블릭 IP 비활성화 (내부망 전용)

Step 5. 인터넷 게이트웨이(IGW) 생성 및 연결

• IGW 생성 후 내가 만든 VPC에 연결
• VPC라는 닫힌 성벽에 바깥세상으로 나가는 문을 하나 다는 것과 같음. 이 문이 없으면 아무리 Public IP가 있어도 인터넷 통신이 불가능.

Step 6. 라우팅 테이블(Route Table) 설정

• 작업: Public용 라우팅 테이블 생성 → Public 서브넷 삽입 → 인터넷 게이트웨이 추가

• ❓라우팅 테이블에 Public 서브넷을 왜 연결?

  • 라우팅 테이블은 이정표임. 서브넷을 이 테이블에 연결하는 이유는 이 서브넷 안에 있는 모든 리소스는 이 이정표를 보고 길을 찾으라고 명령하는것.
  • 연결하지 않으면 서브넷은 기본(Default) 라우팅 테이블을 따르는데, 그러면 외부로 나가는 길을 모를수도 있음. 따라서 너희(Public Subnet)는 인터넷 게이트웨이로 가는 길이 적힌 이 전용 이정표를 봐!라고 명시해 주는 것

• ❓인터넷 게이트웨이 왜 추가

  • 이정표에 바깥세상(0.0.0.0/0)으로 가고 싶으면 아까 만든 그 성문(IGW)으로 가라는 내용을 적어 넣는 작업. 이 규칙이 있어야 비로소 진짜 퍼블릭 서브넷이 됌.

IP (Internet Protocol)

인터넷에 연결된 장치를 식별하는 고유 주소

• 공인 IP: 인터넷에서 사용하는 주소
• 사설 IP: 내부 네트워크에서 사용하는 주소
• 고정 IP: 변하지 않는 주소
• 유동 IP: 바뀔 수 있는 주소

DNS (Domain Name System)

도메인 이름과 IP 주소를 서로 변환해주는 분산형 데이터베이스

• 도메인 → IP 변환: Forward DNS
• IP → 도메인 변환: Reverse DNS
• 계층 구조: Root DNS → TLD DNS → Authoritative DNS 순으로 질의

DNS는 하나의 서버가 모든 정보를 가지는 구조가 아니라, 각 서버가 일부 정보를 나누어 가지는 분산 구조

• DNS 레코드 타입:
  • A: 도메인을 IPv4 주소에 매핑.
  • CNAME: 도메인을 다른 도메인에 매핑.
  • NS: 도메인 관리 권한이 있는 네임 서버 지정.
  • Alias: Route 53 전용, 도메인을 AWS 리소스에 직접 연결.

네트워크 통신 흐름

• DHCP(Dynamic Host Configuration Protocol) - 내 컴퓨터에 IP 주소를 자동으로 할당해주는 과정
• ARP(Address Resolution Protocol) - IP 주소를 물리적 주소(MAC 주소)로 변환하는 과정
• DNS
• TCP(Transmission Control Protocol) - 데이터를 안전하게 주고받기 위해 연결하는 과정
• HTTP/HTTPS

전화기를 설치하고(DHCP), 상대방의 주소를 알아내고(ARP/DNS), 연결 라인을 확보한 뒤(TCP), 대화를 나누는(HTTP) 과정,,

Route 53

AWS에서 제공하는 DNS 서비스

단순히 도메인과 IP를 연결하는 것만이 아니라, 트래픽을 어떤 대상으로 보낼지 결정하는 기능도 함께 제공

• 역할: DNS + 헬스체크 + 장애 조치(Failover) + 라우팅 정책(GSLB)
• 주요 라우팅 정책:
  • 단순: 표준 DNS 기능.
  • 가중치 기반: 설정한 비율로 트래픽 분산
  • 지리적 위치/근접: 사용자 또는 리소스 위치 기반 라우팅
  • 지연 시간: 응답 속도가 가장 빠른 리전으로 연결
  • 장애 조치: 대상이 정상일 때만 트래픽 전송
  • 다중 응답: 무작위로 여러 레코드 응답

로드 밸런서와 비슷해 보일 수 있지만 완전히 같지는 않음

• 로드 밸런서: 들어온 트래픽을 여러 서버에 분산
• Route 53: DNS 단계에서 어느 대상으로 보낼지 결정

DNS 레코드

DNS 서버가 요청에 어떻게 응답할지 정의한 정보

기본 형식 : RR(Name, Value, Type, TTL)

주요 레코드

• A 레코드 도메인 이름을 IPv4 주소에 매핑

• CNAME 하나의 도메인 이름을 다른 도메인 이름에 매핑

• NS 해당 도메인을 관리하는 네임서버 정보

• Alias Route 53 전용 특수 레코드 AWS 리소스와 도메인을 연결할 때 사용

• TTL: DNS 응답을 캐시에 얼마나 오래 저장할지 정하는 값

• 테스트 시: 짧게 설정 / 운영 시: 보통 300초 이상 권장

Route 53 라우팅 정책

• 단순 라우팅 -> 기본 DNS 응답 방식
• 가중치 기반 라우팅 -> 트래픽 비율 다르게 가능 [ 예) A 서버 80% / B 서버 20% ]
• 지리적 위치 기반 라우팅 -> 사용자 위치 기준으로 다른 대상으로 연결
• 지리적 근접 라우팅 -> 리소스 위치 기준으로 가까운 곳에 연결
• 지연 시간 기반 라우팅 -> 지연 시간이 가장 낮은 리전으로 연결
• 장애 조치 라우팅 -> 정상인 대상에만 연결 / 헬스 체크와 함께 사용
• 다중 응답 라우팅 -> 여러 레코드 중 일부를 무작위로 응답

호스팅 영역

DNS 레코드들을 저장해 두는 공간 -> 특정 도메인에 대해 어떤 레코드를 둘지 관리하는 장소

• Public Hosted Zone: 인터넷에서 접근 가능
• Private Hosted Zone: 같은 VPC 내부에서만 접근 가능

VPC (Virtual Private Cloud)

AWS 안에서 만드는 가상 네트워크 하나의 독립된 네트워크처럼 동작해서 보안, 관리, 확장 측면에서 유리

• 리전 단위로 생성
• 리전당 기본 5개까지 생성 가능
• VPC당 최대 5개의 CIDR 블록 설정 가능
• 사설 IPv4 범위만 할당 가능
• 다른 VPC나 외부 네트워크와 CIDR 대역이 겹치면 안 됨

Subnet

VPC를 더 작은 네트워크 단위로 나눈 것 VPC 안에서 리소스를 배치하는 IP 범위

• Public Subnet / Private Subnet

특징

• 서브넷은 하나의 AZ에만 속할 수 있음
• 서브넷의 IP 범위는 반드시 VPC의 CIDR 범위 안에 있어야 함

서브넷을 나누는 이유

• 보안 격리
• IP 주소 효율적 사용
• 관리 편의성

CIDR

IP 주소 범위를 표현하는 표기법

예시 ; 192.168.0.0/24

의미

• 앞부분: 네트워크 ID (192.168.0.0)
• 뒷부분: 호스트 ID 범위 - 나머지 8비트(32비트 - 24비트)
• 서브넷 마스크 (/24): 앞의 24비트를 고정

슬래시 뒤의 서브넷 마스크가 클수록 네트워크 ID 부분이 길어지고, 내가 쓸 수 있는 IP(호스트 ID 부분)는 적어짐

IP 주소 = 네트워크 ID + 호스트 ID

AWS에서도 VPC와 서브넷의 주소 범위를 정할 때 CIDR 사용

IGW (Internet Gateway)

VPC가 인터넷과 통신할 수 있도록 연결하는 게이트웨이

VPC는 기본적으로 외부와 격리된 네트워크라서 인터넷 연결을 위해 IGW가 필요 하지만 IGW만 붙인다고 바로 인터넷이 되는 것은 아님 -> 인터넷 통신이 되려면 같이 필요

• VPC에 IGW 연결
• 라우팅 테이블에 인터넷 방향 경로 추가
• 공인 IP 또는 퍼블릭 접근 조건 충족

Route Table

트래픽을 어디로 보낼지 정하는 규칙표?

예를 들어 특정 목적지로 가는 요청을 로컬로 보낼지, IGW로 보낼지, NAT Gateway로 보낼지 결정

• local → 같은 VPC 내부 통신
• 0.0.0.0/0 → IGW → 인터넷 통신
• 0.0.0.0/0 → NAT Gateway → 프라이빗 서브넷의 외부 통신

하나의 라우팅 테이블을 여러 서브넷에 연결할 수도 있음

Public Subnet / Private Subnet

Public Subnet

인터넷과 직접 연결 가능한 서브넷

• IGW 연결
• 라우팅 테이블에 인터넷 경로 존재
• 공인 IP 부여 가능
• Bastion Host
• NAT Gateway
• Public EC2

Private Subnet

인터넷에서 직접 접근 불가능한 서브넷

• DB
• 내부 서버
• 외부에 노출되면 안 되는 애플리케이션 서버

NAT Gateway

Private Subnet의 리소스가 외부 인터넷으로 나갈 수 있게 해주는 장치

내부 → 외부 가능 외부 → 내부 직접 접근 불가

즉, 프라이빗 서브넷 안의 인스턴스가 패키지 다운로드, 외부 API 호출, 업데이트 같은 작업은 가능하게 하고, 외부에서 직접 들어오는 연결은 막는 구조

동작 흐름 : Private Subnet 리소스 → NAT Gateway → IGW → 인터넷

• Public Subnet에 생성
• Elastic IP 사용
• 특정 AZ에 생성
• 여러 AZ에 각각 만들면 가용성 향상
• 시간당 비용 + 데이터 처리 비용 발생

Bastion Host

외부에서 Private Subnet 내부 서버로 안전하게 접속하기 위한 중간 서버

보통 Public Subnet에 두고, 운영자는 먼저 Bastion Host에 접속한 뒤 그 내부에서 Private EC2로 SSH 접속

즉, 외부 사용자가 Private EC2에 바로 들어가는 것이 아니라 중간 관문을 하나 두는 방식

• 보안 그룹 설정 예시 Bastion Host: 특정 외부 IP만 SSH 허용 Private EC2: Bastion Host에서 오는 SSH만 허용

NACL

Subnet 단위에서 트래픽을 제어하는 보안 장치

보안 그룹이 인스턴스 단위라면, NACL은 서브넷 단위?

• 서브넷을 오가는 트래픽 제어
• 허용과 거부 규칙 모두 설정 가능
• 서브넷 생성 시 기본 NACL에 자동 연결
• 기본 NACL은 비교적 넓게 허용
• 사용자 정의 NACL은 처음에 허용 규칙 없이 시작
• 규칙 번호가 낮을수록 우선순위 높음

보안 그룹 vs NACL

• 더 세밀하게 인스턴스를 보호 → 보안 그룹
• 서브넷 단위로 큰 흐름 제어 → NACL

AWS 네트워크 구조

• Region : AWS 데이터 센터가 모여 있는 지리적 영역
• AZ (Availability Zone) : 하나 이상의 데이터 센터 묶음 / 여러 AZ가 모여 하나의 Region 구성
• VPC : Region 안에 만드는 독립 네트워크
• Subnet : VPC를 더 작게 나눈 네트워크 단위 ( 각 서브넷은 하나의 AZ에 속함 )

VPC Peering

서로 다른 VPC끼리 연결하는 방식

원래 VPC는 서로 독립적이지만, 피어링을 설정하면 마치 같은 네트워크처럼 통신 가능

• AWS 내부 네트워크로 연결
• private IPv4 또는 IPv6 사용
• 서로 다른 계정 간 가능
• 서로 다른 리전 간 가능
• VPC CIDR 대역이 겹치면 안 됨
• 피어링 관계는 전이되지 않음
• 라우팅 테이블도 함께 수정 필요

전이되지 않는다는 말 ; A-B 연결, B-C 연결이 있어도 A와 C가 자동으로 연결X

VPC Endpoint

VPC 내부에서 AWS 서비스로 직접 연결하는 방식

예를 들어 Private Subnet의 인스턴스가 S3, SNS 같은 AWS 서비스에 접근해야 할 때, 굳이 NAT Gateway → IGW → 인터넷 경로를 거치지 않도록 해줌

• AWS 내부 네트워크 이용
• 더 안전
• 더 효율적
• 인터넷 우회 불필요

NAT Gateway와 VPC Endpoint 차이

NAT Gateway

인터넷을 통해 외부로 나가는 통로 경로 : Private Subnet → NAT Gateway → IGW → 외부 인터넷/AWS 서비스

VPC Endpoint

AWS 내부망으로 바로 연결 경로 : Private Subnet → VPC Endpoint → AWS 서비스 AWS 서비스 접근만 필요하다면 VPC Endpoint가 더 적절한 경우가 많음 장점: 보안성 향상, 속도개선, 비용 최적화

Spring Boot 애플리케이션을 AWS EC2에 배포하고, ALB(Application Load Balancer) 뒤에 연결해 두었는데 계속 502 Bad Gateway 가 발생했다. 처음에는 애플리케이션 자체 문제, 보안 그룹, 헬스체크 경로 문제를 의심했다. 그런데 결론적으로는 대상 그룹(Target Group)의 Protocol Version이 HTTP2로 설정되어 있었던 것이 핵심 원인이었다.

정리하면, 내 서비스는 일반적인 Spring Boot 백엔드였고 8080 포트에서 HTTP로 정상 동작하고 있었다. 직접 EC2 내부에서 확인해 보면 /health 엔드포인트는 200 OK를 반환했다. 그런데도 ALB 대상 그룹에서는 계속 Unhealthy가 떴고, 결국 502가 발생했다.

먼저 확인했던 것들

처음에는 가장 흔한 원인부터 점검했다.

• 애플리케이션이 실제로 8080 포트에서 실행 중인지
• /health 엔드포인트가 200을 반환하는지
• 대상 그룹 상태 검사 경로가 /health로 되어 있는지
• 성공 코드가 200인지
• 보안 그룹에서 포트 8080이 열려 있는지

직접 EC2에서 확인했을 때는 /health가 정상 응답을 주고 있었다. 그래서 애플리케이션이 죽은 것은 아니었고, 헬스체크 경로도 틀리지 않았다.

또 AWS 문서상 ALB 대상 그룹의 상태 검사에서는 HTTP/1.1 또는 HTTP/2를 사용하는 경우 유효한 URI 경로를 지정할 수 있고, 성공 코드는 기본적으로 200이다. 따라서 /health, 200 조합 자체는 문제 없는 설정이었다.

이상했던 점

문제는 대상 그룹 상세 설정을 자세히 보다가 발견했다.

• Protocol: HTTP
• Port: 8080
• Protocol version: HTTP2
• Health check path: /health
• Success code: 200

겉보기에는 크게 이상해 보이지 않을 수 있다. 하지만 AWS 공식 문서에 따르면, Application Load Balancer는 기본적으로 타깃에 HTTP/1.1로 요청을 보낸다. 다만 대상 그룹의 Protocol version 설정을 통해 타깃으로 HTTP/2 또는 gRPC를 사용하도록 바꿀 수 있다. 즉, 나는 평범한 Spring Boot 백엔드를 올려 두었는데, 대상 그룹이 백엔드와 통신할 때 HTTP2를 쓰도록 설정되어 있었던 것이다.

왜 이게 문제가 되었나

내 애플리케이션은 브라우저나 curl로 접근했을 때는 잘 응답했다. 이 테스트들은 사실상 일반적인 HTTP 요청 확인에 해당한다. 그런데 ALB는 대상 그룹 설정에 따라 타깃과 통신하는 방식이 달라질 수 있다.

AWS 문서에는 대상 그룹의 프로토콜 버전에 따라 요청 프로토콜과의 조합 결과가 달라진다고 명시되어 있다. 특히 HTTP/1.1 요청을 HTTP/2 대상 그룹으로 보내는 조합은 오류가 될 수 있다. 또한 프로토콜 버전이 맞지 않으면 ALB에서 프로토콜 불일치 문제가 발생할 수 있다고 설명한다. ([AWS Docs][2])

결국 내 경우는 다음과 같이 이해할 수 있었다.

• 애플리케이션 자체는 정상
• /health도 정상 응답
• 하지만 ALB 대상 그룹이 백엔드와 통신할 때 HTTP2를 기대
• 실제 백엔드는 그 환경에 맞지 않음
• 상태 검사 실패
• 타깃이 Unhealthy
• 최종적으로 502 발생

해결 방법

해결은 단순했다. 대상 그룹의 Protocol Version을 다음과 같이 바꾸면 되었다.

• Protocol: HTTP
• Port: 8080
• Protocol version: HTTP1
• Health check path: /health
• Success code: 200

AWS 공식 문서상 ALB는 기본적으로 타깃에 HTTP/1.1로 요청을 보내므로, 일반적인 Spring Boot 백엔드라면 이 설정이 가장 자연스럽다. 설정을 바꾼 뒤에는 대상 그룹 상태가 정상으로 바뀌고, 502도 해결되었다. 안되면 대상그룹 - 로드밸런서를 다시 만들면 HTTP1로 잘 적용된다!!!

왜 HTTP2로 설정되어 있었는지는 아직 모르겠다

솔직히 말하면, 왜 대상 그룹 Protocol Version이 HTTP2로 바뀌어 있었는지는 나도 정확히 모르겠다. 내가 의도적으로 설정한 기억은 없다.

가능한 추측은 몇 가지 있다.

• 대상 그룹 생성 시 콘솔에서 잘못 선택했을 가능성
• 기존 설정을 복사하거나 수정하는 과정에서 바뀌었을 가능성
• 다른 문서를 참고하면서 HTTP2가 더 “최신” 설정처럼 보여 무심코 선택했을 가능성

하지만 중요한 것은 원인을 특정하는 것보다, 백엔드 서버가 어떤 프로토콜을 기대하는지와 대상 그룹 설정이 일치해야 한다는 점이다.

이번 이슈에서 배운 점

이번 문제를 겪으면서 느낀 것은, ALB 502가 난다고 해서 무조건 애플리케이션 코드 문제라고 보면 안 된다는 점이다.

내가 실제로 확인했던 순서는 이랬다.

1. 애플리케이션 프로세스/컨테이너가 살아 있는지 확인
2. EC2 내부에서 /health가 200인지 확인
3. 대상 그룹의 헬스체크 경로와 성공 코드 확인
4. 보안 그룹 확인
5. 마지막으로 대상 그룹의 Protocol Version 확인

특히 앞의 것들이 모두 정상인데도 타깃이 계속 Unhealthy라면, Protocol Version까지 반드시 확인해야 한다.

한 줄 결론

Spring Boot 백엔드는 정상인데 ALB에서만 헬스체크가 실패하고 502가 난다면, 대상 그룹의 Protocol Version이 HTTP2로 되어 있지 않은지 꼭 확인하자. 일반적인 백엔드라면 HTTP1 설정이 맞을 가능성이 크다.

아이템 요약

육아 초보 부모들을 위한 개인 맞춤형 육아용품 큐레이션 앱 코코베이(Cocobay)를 구상

과잉 정보 속에서 제품을 고르기 어려운 부모들을 위해 월령별 가이드, AI 추천, 예산 계산기, 할인 알림 등 기능을 제공

팀 구성 및 역할

• 기획: 육아용품 시장 리서치, 사용자 인터뷰, 페르소나 설정
• 디자인: UI/UX
• 프론트엔드 개발: 추천 홈화면, 예산 계산기, 할인 알림 기능 구현
• AI 모델 개발: AI 렌즈 기반 유사 상품 탐색 기능 초기 모델 구현

프로젝트 진행 과정

• 육아 부모 대상 설문 및 심층 인터뷰 진행
• 맘카페 크롤링을 통한 정보 탐색 피로 분석
• 기획 → 디자인 → 프론트 구현 → AI 모델 → 발표자료 제작까지 진행
• Notion + Figma + GitHub로 협업

잘했다고 생각하는 점

• 사용자 중심 문제 정의가 명확했고, 인터뷰 기반 페르소나가 구체적이었음
• 실사용자의 고민을 직접 반영한 기능 기획
• 디자인과 개발 간 협업이 매끄럽고 속도감 있게 진행됨
• 실제 프론트엔드 구현물 + AI 모델까지 일정 내에 완성

아쉬운 점

• 데이터 기반 기능의 정확도와 검증 부분은 시간이 부족해 MVP 수준에 머물렀음
• 백엔드 연동하지 못하고 프론트에서 그친것이 아쉬움
• 체험단 확보 및 초기 홍보 전략을 실제 실행해보진 못하여 유저 피드백 수집 및 반복 개선을 하지 못한 점이 아쉬움

향후 발전 방향

• AI 렌즈 정확도 개선 및 자체 데이터셋 구축
• 제휴몰 연동을 통한 수익화 실험

개인적으로 얻은 것

• 사용자 인터뷰부터 실 프로토타입 개발까지, 스타트업의 문제 정의 – 솔루션 설계 – MVP 개발 – 피칭 전 과정을 경험
• 팀 내 빠른 의사결정과 다른 파트 팀원들과의 협업의 중요성을 체감
• 피봇되는게 당연하고 이 과정을 단순히 힘들다고 회피하지 않기
• 아이디어만 있다면 충분히 공부해서라도 구체화 가능하다. 너무 불가능하다고 생각하지 말기!

ch3

ch4

ch5

ch6

ch7

ch8

ch9

ch10

ch11

ch12

ch13

ch14

ch15

ch16

ch17

ch18

소프트웨어 프로세스 1

소프트웨어 프로세스 2

sw 모델링 및 표현도구

요구공학

시스템 모델링

아키텍쳐설계

객체지향소프트웨어

ch8

ch9

ch10

ch11

ch12

ch13

ch14

ch15

ch16

ch17

ch18

ch19

ch20

ch21

ch2

ch3

ch4 ch5

ch6

ch7 ch8 ch9

족보 풀이

1. 기본 골격

가장 기초적인 형태 @app.get("/") 같은 데코레이터가 이 주소로 오면 아래 함수를 실행해라고 알려줌

from fastapi import FastAPI

app = FastAPI()

# GET 요청을 받음
@app.get("/")
async def read_root():
    return {"message": "Hello World"}

• async def: 비동기 함수로 정의
  • 데이터베이스나 AI 요청처럼 오래 걸리는 작업에 필수 -> ai가 오래걸려도 그걸 기다지리않고 다른걸 할수있음
• Return: 딕셔너리({})를 리턴하면 자동으로 JSON으로 변환되어 나감

2. 경로 변수 (Path Parameter)

URL 경로 자체에 들어있는 변수를 받음 예: /items/5 -> item_id는 5

@app.get("/items/{item_id}")
async def read_item(item_id: int):  # 타입 힌트(int) 필수!
    return {"item_id": item_id}

• item_id: int: 이렇게 타입을 적어두면, 사용자가 /items/foo라고 문자를 넣었을 때 FastAPI가 알아서 숫자만 넣으라고 에러를 냄

3. 쿼리 파라미터 (Query Parameter)

URL 뒤에 ?로 붙는 변수 경로({})에 없는 변수를 함수 인자로 넣으면 자동으로 쿼리 파라미터가 됌 예: /items/?skip=0&limit=10

@app.get("/items/")
async def read_items(skip: int = 0, limit: int = 10):
    return {"skip": skip, "limit": limit}

• skip: int = 0: 값이 안 들어오면 기본값 0 사용

4. 데이터 받기

POST 요청으로 복잡한 데이터를 받을 때 사용 Pydantic이라는 라이브러리로 데이터의 모양(스키마)을 정의

from pydantic import BaseModel

# 1. 데이터 모양 정의 (붕어빵 틀)
class Item(BaseModel):
    name: str
    price: float
    is_offer: bool = None  # 선택 사항

# 2. 함수에서 사용
@app.post("/items/")
async def create_item(item: Item): # item 변수는 Item 클래스 모양이어야 함
    return {"name": item.name, "price": item.price}

• 사용자가 JSON 데이터를 보내면, FastAPI가 Item 클래스 모양과 맞는지 검사하고, 자동으로 변수(item)에 넣어줌
• item.name처럼 점(.)을 찍어서 데이터에 접근할 수 있음

5. 라우터 나누기 (APIRouter)

기능별로 파일을 쪼갤 때 사용

파일: `users.py`

from fastapi import APIRouter

router = APIRouter()

@router.get("/users/")
async def read_users():
    return [{"username": "Rick"}, {"username": "Morty"}]

파일: main.py (메인)

from fastapi import FastAPI
from . import users # users.py 불러오기

app = FastAPI()

# users의 라우터를 메인에 합체!
app.include_router(users.router)

자동 문서화 (Swagger UI)

FastAPI의 가장 큰 장점 코드를 짜고 서버를 켜면, 자동으로 API 설명서 사이트를 만들어줌

• 서버 실행 후 주소창에: http://localhost:8000/docs
• API를 직접 테스트 가능 (Postman 없어도 됨)

1. 웹소켓과 STOMP 기초 개념

단순 웹소켓만 쓰면 로우 레벨이라 메시지 형식을 일일이 다 정해야 함 그래서 우리는 STOMP 규격 사용했음

• 구조: 메일함처럼 특정 주소를 '구독(Sub)'하고, 그 주소로 메시지를 '발행(Pub)'하는 방식임.

• 장점: 메시지 브로커를 통해 채팅방별로 메시지를 꽂아주기가 훨씬 편함.

• Publisher(발행자): 채팅 메시지를 보내는 사람 (클라이언트)

• Subscriber(구독자): 채팅방에 들어와서 메시지를 받는 사람 (클라이언트)

• Broker(중개자): 메시지를 받아서 구독 중인 사람들에게 뿌려주는 서버

2. 백엔드 설정 (Spring Boot)

먼저 의존성에 spring-boot-starter-websocket 추가되어 있어야 함.

[WebSocketConfig.java]

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void configureMessageBroker(MessageBrokerRegistry config) {
        // 메시지 받을 때: /sub/chat/room/1 이런 식으로 구독함
        config.enableSimpleBroker("/sub"); 
        // 메시지 보낼 때: /pub/chat/message 이런 식으로 보냄
        config.setApplicationDestinationPrefixes("/pub");
    }

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/ws") // 프론트가 접속할 엔드포인트
                .setAllowedOrigins("https://www.example.com") // 프론트 도메인 필수
                .withSockJS(); // 낮은 버전 브라우저 대응
    }
}

3. 채팅 로직 흐름 (우리 서비스 특화)

글쓴이가 게시글(Post) 댓글에서 선택해서 팟 참여 확정 -> 채팅방 생성 구조로 기획을 했음..

1. 팟 확정: 게시글 작성자가 참여자를 선택하고 '확정' 누름.
2. 채팅방 생성: 서버에서 ChatRoom 만들고 선택된 인원들을 ChatMember로 등록함.
3. 알림 발송: 참여자들에게 "채팅방에 초대되었습니다"라고 알림 쏨.
4. 입장 및 구독: 프론트에서 roomId를 받아 해당 경로(/sub/chat/room/{id})를 구독함.
5. 메시지 전송(Publish): 유저가 채팅 치면 프론트에서 /pub/chat/message로 JSON 데이터를 전송

[ChatController.java]

@Controller
@RequiredArgsConstructor
public class ChatController {
    private final SimpMessageSendingOperations messagingTemplate;

    @MessageMapping("/chat/message") // 프론트가 /pub/chat/message로 보낼 때
    public void message(ChatMessageDto message) {
        // DB에 채팅 내역 저장하는 로직 추가 가능
        // 구독 중인 사람들에게 메시지 전달
        messagingTemplate.convertAndSend("/sub/chat/room/" + message.getRoomId(), message);
    }
}

4. 프론트엔드와 협업할 때 주의사항

① 보안 및 인증 (가장 많이 막히는 부분)

• 웹소켓은 일반 HTTP 요청이랑 다르게 Header에 토큰 담기가 까다로움....
• 해결: 연결 시점(connect)에 쿼리 파라미터로 토큰을 보내거나, STOMP의 connectCallback 헤더에 JWT 토큰을 실어 보내야 함. 백엔드에서 ChannelInterceptor를 구현해서 토큰 검증 로직 따로 짰음

② CORS 에러

• 웹소켓 엔드포인트(.addEndpoint("/ws"))에도 .setAllowedOrigins 설정을 정확히 해줘야 함. 안 그러면 프론트에서 접속 못 함......

③ 도메인 연결 (HTTPS/WSS)

• 서비스 HTTPS 적용했다면 프론트도 ws://가 아니라 wss://로 접속해야 함.
• AWS ALB(로드밸런서) 쓰고 있으면 웹소켓 프로토콜도 지원하도록 설정 확인해야 함 (기본적으로 지원하지만 간혹 타임아웃 이슈 있음).

5. 오류 해결 및 팁

• 채팅방 자동 생성 이슈: 댓글에서 선택해서 채팅방 만들 때, 선택된 인원들의 Member ID 리스트를 받아서 ChatMember(중간 테이블)에 저장해야 했음. 그래야 나중에 "내 채팅방 목록" 조회할 때 내가 속한 방만 가져올 수 있었음
• 무한 루프 방지: 프론트에서 메시지 받고 바로 다시 메시지 쏘는 로직 들어가면 서버 터짐. 이벤트 리스너 관리 잘하라고 프론트한테 말해줘서 해야함!

사소하지만 디테일 구현하고자 한 포인트

유저마다 last_read_at(마지막 읽은 시간)을 필드로 둠. 채팅방 목록 불러올 때 이 시간 이후로 쌓인 메시지 개수를 쿼리로 날려서 "안 읽은 메시지 N개" 기능을 구현했음..

Full-Stack HTTPS 인프라 구축 완벽 정리

1. 인프라 구조 설계

• Front-end: Vercel (자동 HTTPS 적용됨) → www.example.com
• Back-end: AWS EC2 + ALB (수동 설정 필요) → api.example.com
• 핵심: 하나의 도메인을 사서 서브도메인으로 앞뒤를 나눠서 관리함.

2. 도메인 구매 및 Route 53 연결

1. 도메인 구매: 가비아 등에서 맘에 드는 거 삼.
2. 호스팅 영역 생성: AWS Route 53 가서 구매한 도메인으로 '퍼블릭 호스팅 영역' 만듦.
3. 네임서버(NS) 교체:

• Route 53에서 생성된 NS 레코드 값 4개 복사함.
• 가비아 관리 페이지 가서 기존 네임서버 지우고 복사한 값 넣음. (맨 끝 마침표 . 빼고) 전파되는데 시간 좀 걸림

3. SSL 인증서 발급 (ACM)

1. 인증서 요청: AWS ACM 가서 *.example.com , example.com 형태로 2개 포함해 신청
2. DNS 검증: 검증 방식은 'DNS 검증' 선택
3. 레코드 생성: "Route 53에서 레코드 생성" 버튼 누르면 알아서 CNAME 생성
4. 상태 확인: '발급됨' 뜰 때까지 대기 ( 시간소요)

4. 로드밸런서(ALB) 및 타겟 그룹 세팅

1. 대상 그룹(Target Group) 생성:

• 유형은 '인스턴스', 포트는 스프링 부트 포트(8080)로 설정
• 내 EC2 인스턴스 체크해서 타겟에 포함시키기

2. ALB 생성:

• Application Load Balancer 선택
• 가용 영역(AZ)은 최소 2개 이상의 퍼블릭 서브넷 선택해야함 (나는 a,c선택함)
• 보안 그룹: 80(HTTP), 443(HTTPS) 둘 다 열려 있어야 함.

3. 리스너 설정:

• HTTPS:443: 아까 ACM에서 만든 인증서 걸어주고, 대상 그룹으로 넘기기
• HTTP:80: 호스트 헤드 = 도메인 , URL로 리디랙션

        -> 모든 요청을 HTTPS로 리디렉션 (상태 코드 301) -> 1순위

5. Route 53 - A 레코드 연결

1. Route 53 호스팅 영역 다시 들어감. 1-1. 서브도메인(백엔드용) 1-2. 레코드 생성: www 혹은 api 등 서브도메인 입력 1-3. 별칭(Alias): 스위치 켜고, 'ALB에 대한 별칭' 선택해서 만든 로드밸런서 주소랑 연결 1-1. 도메인(프론트용) 1-2. 레코드 생성: 아무런 이름 입력 X 1-3. 별칭(Alias) 끄기: ALB에 대한 별칭 해제하고 프론트의 vercel 배포 주소를 넣기

6. CORS 및 헬스 체크 이슈 해결 (중요함!)

• CORS 에러: 프론트(www)랑 백(api) 도메인이 다르기 때문에 스프링 부트에서 허용해줘야 함. allowedOrigins에 프론트 주소 정확히 작성하기
• Health Check: ALB는 주기적으로 서버가 살아있는지 체크해줌 (/ 경로가 404 뜨면 서버 죽은 줄 알고 트래픽 끊음)
  • 스프링 부트에 간단하게 200 OK 뱉는 /health 컨트롤러 만들고, 대상 그룹 설정에서 헬스 체크 경로를 /health로 바꿔서 테스트하기

1. Nginx 설치

# 패키지 매니저 업데이트
sudo yum update -y

# Nginx 설치
sudo yum install nginx -y

# Nginx 실행 및 서버 부팅 시 자동 실행 설정
sudo systemctl start nginx
sudo systemctl enable nginx

2. 설정 파일 수정

# 기본 설정 파일 백업 
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

# 설정 파일 열기
sudo nano /etc/nginx/nginx.conf

3. nginx.conf 내용 수정

server {
    listen       80;
    listen       [::]:80;
    server_name  도메인 www.도메인;

    location / {
        proxy_pass http://localhost:8080;
        proxy_http_version 1.1;

        # SSE 및 실시간 통신 설정
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_cache_off;
        proxy_buffering off;
        proxy_read_timeout 3600s;
        chunked_transfer_encoding off;
    }

    # 기존에 있던 다른 설정들은 일단 그대로 두기
}

4. 적용 및 확인

# 문법 체크 
sudo nginx -t

# Nginx 재시작
sudo systemctl restart nginx

주의사항 (AWS 보안 그룹)

AWS 보안 그룹에서 80 포트를 여는 것이 필수