WAS 및 Web 서버 운영 중 발생할 수 있는 실무 장애 상황과 그에 대한 정확한 진단 및 조치 방안을 다양한 유형별로 정리해 드리겠습니다.
 시나리오 + 원인 분석 + 조치 방법입니다.

✅ A. 웹서버(Web Server) 장애 상황

🔹 1. 웹 접속 불가 (80/443 포트 응답 없음)

  • 원인: Nginx/Apache 프로세스 중지, 방화벽 차단, 포트 점유
  • 진단 방법:
  • bash
    복사편집
    systemctl status nginx ss -tulnp | grep :80 sudo ufw status or firewall-cmd --list-all
  • 조치 방안:
    • 웹서버 재기동 (systemctl restart nginx)
    • 방화벽 열기 (firewall-cmd --add-port=80/tcp)
    • 포트 충돌 시 다른 프로세스 제거

🔹 2. 특정 경로 404 오류 (리소스 없음)

  • 원인: 프록시 설정 오타, 파일 경로 오류
  • 조치 방안:
    • /etc/nginx/conf.d/*.conf에서 location 설정 확인
    • 정적 리소스 경로(/var/www/html) 유무 확인

🔹 3. 504 Gateway Timeout

  • 원인: WAS에서 응답 없음 (Deadlock, GC, DB 대기 등)
  • 조치 방안:
    • proxy_read_timeout, proxy_connect_timeout 증가
    • WAS 상태 확인 → 필요 시 재기동
    • APM 또는 GC 로그로 병목 구간 분석

✅ B. WAS (Tomcat 등) 장애 상황

🔹 4. WAS 응답 지연 / 부하 급증

  • 원인: GC 과다, Thread Pool 고갈, DB 커넥션 부족
  • 조치 방안:
    • GC 로그 확인 (-Xlog:gc*)
    • maxThreads, maxConnections 값 증가
    • 커넥션 풀 확인 (HikariCP, DBCP 모니터링)

🔹 5. OutOfMemoryError (OOM)

  • 원인: 힙 사이즈 부족, 메모리 누수
  • 조치 방안:
    • JVM Heap 증가 (-Xmx)
    • Heap dump 후 분석 (jmap -dump, Eclipse MAT)
    • 코드 내 객체 누수 패턴 제거

🔹 6. 세션 유실 (로그인 풀림)

  • 원인: Sticky Session 미설정, 세션 복제 안됨
  • 조치 방안:
    • Nginx에 ip_hash 또는 Cookie 기반 sticky 설정
    • Redis 기반 Session Store 적용 (Spring Session)

🔹 7. WAS 갑작스러운 종료

  • 원인: 로그 디스크 Full, OOM, kill 명령, 파일 핸들 초과
  • 조치 방안:
    • df -h, ulimit -n 확인
    • 로그 파일 순환 설정 (logrotate)
    • 시스템 로그 확인 (dmesg, /var/log/messages)

✅ C. 네트워크 / 로드밸런싱 / 인프라 장애

🔹 8. 클라이언트 간헐적 접속 실패

  • 원인: 로드밸런서 Health check 미설정, WAS 일부 죽음
  • 조치 방안:
    • L4/L7 Health Check 구성
    • 죽은 노드 자동 제외 (active check)

🔹 9. DNS 응답 지연

  • 원인: 내/외부 DNS 장애 또는 지연
  • 조치 방안:
    • /etc/resolv.conf DNS 우선순위 조정
    • IP 직접 호출 테스트 (curl -x IP)
    • DNS 캐시 무효화 (systemd-resolve --flush-caches)

✅ D. 보안/인증 관련 장애

🔹 10. HTTPS 접속 오류 (SSL 인증서 에러)

  • 원인: 인증서 만료, 체인 미완성
  • 조치 방안:
    • openssl x509 -in cert.pem -noout -dates 확인
    • fullchain.pem 재설정
    • LetsEncrypt 자동 갱신(cronjob, certbot 확인)

✅ E. DB 연동 관련 장애

🔹 11. DB 연결 실패 or 지연

  • 원인: DB down, 커넥션 풀 고갈, 방화벽 차단
  • 조치 방안:
    • telnet DB_IP 3306, psql, mysql 접속 확인
    • 커넥션 풀 설정 점검
    • DB slow query 확인 및 튜닝

✅ F. 실무 대응을 위한 체크리스트 (TA 기준)

구분점검 항목
로그 분석 access.log, error.log, catalina.out, GC 로그, dmesg
자원 모니터링 top, iostat, free, df, vmstat, netstat
네트워크 확인 ping, traceroute, ss, netcat, telnet
설정 파일 nginx.conf, server.xml, context.xml, .env
복구 전략 무중단 배포, HA 구성, Redis 세션 백업, DB 이중화
 

✅ 장애별 빠른 대응 템플릿 예시

 
# nginx 지연 시 빠른 점검
systemctl status nginx
cat /var/log/nginx/error.log curl -I http://localhost
# WAS 상태 확인
ps aux | grep tomcat
tail -n 100 /opt/tomcat/logs/catalina.out
# JVM GC 상태
jstat -gcutil <pid> 1000 10
# DB 커넥션 확인
netstat -anp | grep 3306

필

✅ 실전 장애 시나리오 문제집 (세트 1~5)

### ✅ 시나리오 1: 특정 사용자만 로그인 실패

상황
웹 애플리케이션에서 특정 사용자들만 로그인 실패를 반복하고 있습니다. WAS와 DB는 정상 동작 중이고, 일부 사용자에 대해서만 로그인 실패 현상이 발생합니다.

질문

  1. 이 문제의 가능한 원인은 무엇인가요?
  2. 어떤 로그 또는 설정을 점검해야 하나요?
  3. 해결 방안은?

해설 및 답변

  • 원인: 세션 공유 오류, 로드밸런서의 Sticky Session 설정 누락
  • 점검: Nginx 로드밸런서 설정(ip_hash, cookie-based sticky), 세션 스토리지 로그
  • 조치: Sticky Session 활성화 또는 세션 중앙 저장소(Redis 등) 사용

### ✅ 시나리오 2: 504 Gateway Timeout 증가

상황
오후 피크 타임에 504 오류가 대량으로 발생하며, 대부분 특정 API 경로에서 집중됩니다. WAS에 직접 접속하면 응답이 느릴 뿐 실패하지 않습니다.

질문

  1. 어떤 장애유형인가요?
  2. 어떤 설정과 시스템 자원을 확인해야 하나요?
  3. 조치 방안은?

해설 및 답변

  • 원인: WAS에서 지연 발생 → Nginx가 Timeout 초과
  • 점검:
    • Nginx: proxy_read_timeout, proxy_connect_timeout
    • WAS 로그: DB 쿼리, GC 상태
    • DB 슬로우 쿼리
  • 조치:
    • 타임아웃 조정
    • 쿼리 튜닝 / 인덱스 추가
    • GC 튜닝 / Thread 수 조정

### ✅ 시나리오 3: WAS 무한 재시작

상황
Tomcat 기반 WAS가 배포 후 수 초 내에 재시작을 반복하며 정상 서비스가 되지 않고 있습니다.

질문

  1. 장애 원인을 어떻게 추정하나요?
  2. 가장 먼저 확인할 로그는?
  3. 조치 방안은?

해설 및 답변

  • 원인: 환경 변수 누락, spring profile 오타, 포트 충돌, 로그 디렉터리 권한 문제
  • 점검:
    • catalina.out, nohup.out, application.log
    • env 설정 확인
  • 조치:
    • application.yml/profile 확인
    • 로그 디렉토리 쓰기 권한 확인 (chown, chmod)
    • 포트 충돌이면 포트 변경

### ✅ 시나리오 4: Redis 세션 만료로 사용자 로그아웃

상황
Redis를 세션 저장소로 사용하는 WAS에서 대량의 사용자 로그아웃 현상이 발생하고 있습니다. 장애는 오전 4시에 집중 발생합니다.

질문

  1. Redis 설정에서 점검할 항목은?
  2. 이 장애의 발생 원인은?
  3. 해결 방법은?

해설 및 답변

  • 원인: Redis maxmemory-policy가 volatile-lru로 설정되어 세션 정보가 메모리 부족 시 제거됨
  • 점검:
    • redis.conf: maxmemory, maxmemory-policy, TTL 확인
    • 모니터링: Redis 메모리 사용률, key TTL
  • 조치:
    • allkeys-lru → volatile-ttl 또는 세션 전용 Redis 분리
    • 메모리 증설 / 수명 늘리기 / 중요 키는 TTL 설정 금지

### ✅ 시나리오 5: 웹 접속 시 응답 없음 (503)

상황
웹 접속 시 503 오류가 빈번하게 발생합니다. 서버 재시작 후 일정 시간은 정상이나, 이후 장애가 반복됩니다.

질문

  1. 이 현상의 원인은?
  2. Nginx와 WAS 중 어디부터 점검해야 하나요?
  3. 조치 방안은?

해설 및 답변

  • 원인: Nginx upstream 연결 실패 or WAS 프로세스 과부하
  • 점검:
    • Nginx 로그: access.log, error.log
    • WAS: top, jstack, thread dump
  • 조치:
    • WAS 스레드/커넥션 수 조정
    • Nginx max_fails, fail_timeout 조정
    • APM 도입하여 병목 확인

 

✅ 시나리오 6: WAS에서 한 서비스만 응답 지연

상황
전체 웹 서비스는 정상적으로 작동하지만, /api/report 경로에만 지연이 발생합니다. 이 경로는 DB와 연동된 통계를 제공하는 기능입니다.

질문

  1. 이와 같은 지연의 원인 후보를 2가지 이상 제시하시오.
  2. 진단 및 조치를 위한 절차를 설명하시오.

해설 및 답변

  • 원인:
    • 해당 API의 DB 쿼리 성능 저하
    • GC 또는 특정 Thread에서 처리 병목
  • 진단:
    • WAS 로그에서 /api/report 응답시간 추적
    • DB 슬로우 쿼리 로그 확인
    • GC/Thread dump 확인
  • 조치:
    • 쿼리 튜닝 (인덱스 추가, join 최적화)
    • GC 설정 조정
    • 비동기 처리 전환 고려

✅ 시나리오 7: 서비스 중 로그인 상태가 초기화됨

상황
사용자가 로그인 후 5분 이내에 자동 로그아웃되는 현상이 간헐적으로 발생합니다. 로그인 쿠키는 유지되며, WAS는 멀티노드로 구성되어 있습니다.

질문

  1. 문제의 가능성 높은 원인을 기술하시오.
  2. 어떤 설정 또는 구성을 확인해야 하는가?

해설 및 답변

  • 원인:
    • 세션 클러스터링 누락 or 잘못된 Sticky Session 설정
    • Redis의 TTL 설정 과도함
  • 확인 항목:
    • 로드밸런서에 ip_hash or cookie sticky 설정 여부
    • Redis 세션 TTL 설정 확인
    • Spring Session 설정에서 maxInactiveIntervalInSeconds
  • 조치:
    • 세션 공유 방식 전환 (Sticky → 중앙 저장소)
    • TTL 확장 또는 중요 세션은 TTL 제거

✅ 시나리오 8: 갑작스런 트래픽 증가 후 전체 장애

상황
SNS 마케팅 이후 갑작스러운 사용자 증가로 인해 웹 페이지 접속이 불가능한 상황 발생. 웹서버는 살아 있으나 WAS와 DB 모두 과부하 상태입니다.

질문

  1. 해당 장애의 직접적 원인과 근본 원인을 나눠 설명하시오.
  2. 이 상황에서 빠르게 복구하는 방법은?

해설 및 답변

  • 직접 원인: WAS/DB 자원 고갈 (CPU, Thread, Connection Pool)
  • 근본 원인: 적절한 트래픽 예측 및 자원 할당 부재
  • 조치:
    • WAS 수평 확장 (Auto Scaling 또는 수동 증설)
    • nginx rate_limit, fail_timeout으로 순간 폭주 차단
    • CDN 활용하여 정적 리소스 분산
    • DB Connection Pool 증설

✅ 시나리오 9: WAS 시작 안됨, 로그도 없음

상황
WAS 재기동 중인데, 프로세스가 시작되지 않으며 로그 파일에도 아무 메시지가 기록되지 않습니다.

질문

  1. 원인을 확인할 수 있는 방법을 제시하시오.
  2. 이 문제의 조치 방안은?

해설 및 답변

  • 원인:
    • 포트 충돌 (이미 사용 중)
    • 로그 디렉토리 쓰기 권한 없음
    • 환경 변수 누락 (JAVA_HOME 등)
  • 확인 방법:
  • bash
    복사편집
    netstat -tulnp | grep 8080 ls -al /opt/tomcat/logs echo $JAVA_HOME
  • 조치:
    • 포트 변경 또는 충돌 프로세스 종료
    • 로그 경로 소유자/퍼미션 수정
    • .bash_profile에 JAVA_HOME 재정의

✅ 시나리오 10: 정기 배포 후 CSS/JS 깨짐

상황
새 버전 배포 후 일부 사용자에게 CSS가 적용되지 않거나 JS 기능이 작동하지 않는 이슈가 발생함.

질문

  1. 가장 먼저 점검해야 할 항목은?
  2. 가능한 원인 2가지와 조치 방안을 설명하시오.

해설 및 답변

  • 점검 항목:
    • 브라우저 캐시 상태, CDN 캐시, Nginx 캐시 설정
  • 원인 및 조치:
    1. 정적 리소스 캐싱 문제 → 파일명에 hash 추가 (style.abcd123.css)
      • 조치: 정적 자산 버전 관리 적용 (Webpack, Asset Pipeline)
    2. CDN 캐시 미갱신 → 오래된 JS/CSS 제공
      • 조치: CDN purge 실행 또는 캐시 만료 설정 변경 (cache-control)

✅

✅ 실전 장애 시나리오 문제집 (세트 11~15)

✅ 시나리오 11: 로그 파일 폭주로 인한 디스크 FULL

상황
갑작스럽게 서비스 전체가 다운되었으며, WAS 로그 기록도 멈춘 상태입니다. 서버에 접속해 보니 /var 디스크가 100% 사용 중입니다.

질문

  1. 이 문제의 발생 원인과 진단 절차는?
  2. 어떤 조치가 가능한가?
  3. 이 장애를 방지하기 위한 사전 방안은?

해설 및 답변

  • 원인: 로그 파일 과다 발생 (무한 루프, DEBUG 레벨), logrotate 설정 미적용
  • 진단:
    • df -h, du -sh /var/log/* 로 디스크 점유 확인
    • 최근 수정된 로그 탐색: find /var/log -type f -mtime -1
  • 조치:
    • 대용량 로그 삭제 (truncate -s 0 file.log or 백업 후 삭제)
    • 서비스 재시작
  • 예방:
    • logrotate 설정 (/etc/logrotate.d/)
    • 로그 레벨 관리 (INFO 이상 유지)
    • 모니터링 임계치 설정 (디스크 사용률 80% 알람)

✅ 시나리오 12: 정적 파일 응답이 비정상적으로 느림

상황
웹페이지 로딩 속도가 느려졌고, Chrome 개발자 도구에서 CSS/JS 등 정적 파일들이 3~5초 지연되고 있음이 확인됨. API 응답은 빠름.

질문

  1. 이 문제는 Web인가 WAS인가?
  2. 가장 먼저 점검해야 할 설정 항목은?
  3. 조치 방안은?

해설 및 답변

  • 범위: Web Server 문제
  • 점검:
    • nginx.conf의 정적 파일 경로 설정 (e.g. location ~* \.(js|css|jpg|png) 등)
    • 정적 파일이 실제로 NFS 등 외부 스토리지에 있는지
    • 캐시 설정 확인 (expires, cache-control)
  • 조치:
    • 정적 파일을 로컬 경로로 이전 또는 CDN 적용
    • gzip 압축 설정 확인 (gzip on;)
    • 브라우저 캐시 정책 조정 (expires 30d 등)

✅ 시나리오 13: 특정 지역 사용자만 접속 장애

상황
국내 일부 지역(예: 수도권) 사용자만 서비스 접속 지연을 호소. 사내 테스트 및 해외 사용자 접속은 정상.

질문

  1. 이 문제를 지역별로 어떻게 진단할 수 있는가?
  2. 어떤 네트워크 요소를 의심해야 하는가?
  3. 가능한 원인과 조치는?

해설 및 답변

  • 진단:
    • 지역별 접속 테스트 (VPN, 사내 지사)
    • CDN 로그, ISP 분석 (Traceroute 활용)
  • 의심요소:
    • 지역별 DNS 서버 응답 이상
    • 특정 ISP와의 라우팅 문제
  • 조치:
    • CDN 활용 시, 지역 Edge 노드 상태 확인
    • DNS 서비스 상태 점검 (Cloudflare, Route53)
    • 네트워크 업체와 회선 장애 분석 요청

✅ 시나리오 14: API 응답은 정상, 브라우저에선 CORS 오류

상황
브라우저에서 특정 프론트엔드 기능이 동작하지 않고, 콘솔에는 CORS policy: No 'Access-Control-Allow-Origin' 오류가 발생함.

질문

  1. 이 문제는 서버 문제인가, 클라이언트 문제인가?
  2. 어떤 설정을 점검해야 하는가?
  3. 조치 방법은?

해설 및 답변

  • 서버 측 문제 (응답 Header 누락)
  • 점검:
    • Web 서버 or WAS에서 CORS Header 삽입 여부 확인
    • Nginx reverse proxy 경로에 add_header 누락 여부
  • 조치:또는 WAS(Spring 등)에서 CORS 설정 추가
  • nginx
    복사편집
    location /api/ { proxy_pass http://was; add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS'; }

✅ 시나리오 15: 파일 업로드 실패 (413 Request Entity Too Large)

상황
대용량 이미지 업로드 시 413 Request Entity Too Large 오류 발생. 작은 파일은 업로드 정상.

질문

  1. 이 문제는 어디에서 발생하는가?
  2. 해결을 위한 설정 변경 항목은?

해설 및 답변

  • 원인: Web Server에서 허용하는 요청 Body 크기 제한
  • 위치: Nginx or Apache
  • 조치:
    • WAS에도 파일 업로드 제한 설정 확인 (spring.servlet.multipart.max-file-size)
    • 브라우저 사이드에서 FormData 방식 확인
  • nginx
    복사편집
    http { client_max_body_size 20M; }


이번 세트는 보안, 인증서, WAS 성능, 캐시, 스케일링 등 실무에서 놓치기 쉬운 이슈를 중심으로 구성했습니다.

✅ 시나리오 16: SSL 인증서 갱신 후 HTTPS 오류

상황
Let's Encrypt 인증서를 갱신한 후, 일부 브라우저에서 HTTPS 접속 시 "보안 인증서를 신뢰할 수 없음" 오류가 발생합니다. 모바일에서 주로 발생합니다.

질문

  1. 어떤 설정 오류가 의심되나요?
  2. 확인 및 조치 방안을 서술하시오.

해설 및 답변

  • 원인: fullchain.pem 대신 cert.pem만 적용함 → 중간 인증서 누락
  • 확인 방법:
  • bash
    복사편집
    openssl s_client -connect domain.com:443 -showcerts
  • 조치:
    • ssl_certificate에 fullchain.pem 지정
    • Nginx 설정 예시:
    • nginx
      복사편집
      ssl_certificate /etc/letsencrypt/live/domain/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/domain/privkey.pem;

✅ 시나리오 17: 갑자기 느려진 WAS 응답, GC 관련

상황
WAS에서 특정 시점부터 전체 응답 속도가 급격히 느려졌습니다. CPU는 100%에 육박하며 GC 로그가 잦아지고 있습니다.

질문

  1. GC 관점에서 어떤 현상이 의심되며, 이를 어떻게 확인하나요?
  2. 근본적인 해결 방법은?

해설 및 답변

  • 의심 현상: Full GC 반복, Old Generation 메모리 부족
  • 확인 방법:
    • -Xlog:gc* 또는 verbose:gc 로그 분석
    • jstat -gcutil <pid> 1000 10
  • 조치:
    • Heap 사이즈 조정 (-Xmx, -Xms)
    • G1GC로 전환 고려
    • 메모리 누수 분석 (jmap, Eclipse MAT)
    • 캐시 객체 TTL 설정

✅ 시나리오 18: Redis 캐시 적용 후 반영이 안됨

상황
Redis 기반 캐시를 도입했으나, 백엔드에서 수정한 데이터가 바로 반영되지 않고, 오래된 데이터가 계속 노출되고 있습니다.

질문

  1. 캐시 시스템에서 자주 발생하는 이 문제의 원인과 진단 절차는?
  2. 실무적으로 어떤 전략을 사용해 해결할 수 있나요?

해설 및 답변

  • 원인:
    • TTL 설정 누락
    • 캐시 삭제/무효화 로직 없음
  • 조치:
    • TTL 설정 적용 (EXPIRE, SETEX)
    • 쓰기 시 cache evict, invalidate
    • 전략 도입:
      • Write-Through (동기 업데이트)
      • Cache-Aside (읽기 시 캐시 확인)
      • TTL + Versioning 조합

✅ 시나리오 19: WAS Auto Scaling 후 세션 오류

상황
AWS ECS에서 Auto Scaling 정책으로 WAS 인스턴스를 자동으로 늘렸으나, 사용자 세션이 초기화되며 로그인 유지가 안 됩니다.

질문

  1. 클라우드 환경에서 이 현상의 원인과 해결책은?
  2. 세션 유지 전략 2가지를 설명하시오.

해설 및 답변

  • 원인: Auto Scaling된 WAS 인스턴스 간 세션 공유 안됨
  • 조치:
    • Sticky Session 설정 (ALB, NLB에서 session cookie)
    • Redis를 세션 저장소로 구성 (Spring Session Redis)
  • 전략:
    1. Sticky Session → 간단하지만 scale-in 시 리스크 존재
    2. 중앙 저장소 방식 → 확장성과 안정성 ↑

✅ 시나리오 20: 배포 후 특정 기능만 실패 (Method Not Allowed)

상황
배포 후, 프론트에서 특정 버튼 클릭 시 405 Method Not Allowed 에러 발생. 백엔드 API는 POST로 설계되었으며, WAS는 Tomcat 기반입니다.

질문

  1. 이 장애는 프론트엔드 문제인가, 백엔드 문제인가?
  2. 원인과 조치 방안을 서술하시오.

해설 및 답변

  • 원인: 웹서버 or 프록시가 POST 요청을 차단하거나, 백엔드에서 Mapping 누락
  • 확인:
    • Nginx 또는 Tomcat의 allowedMethods 설정
    • 프론트에서 잘못된 HTTP Method 요청 확인 (F12 Network 탭)
  • 조치:
    • 프론트가 GET으로 보내고 있는지 확인
    • 백엔드에서 @PostMapping("/submit") 누락 여부 확인
    • Nginx에 limit_except 설정이 있다면 제거


아래는 실전 장애 시나리오 문제집 세트 21~25입니다.
이번에는 보안 위협, 파일시스템 병목, 인증 시스템, 모니터링 누락, 설정 배포 실수 등 운영 현장에서 실제 발생하는 고급 시나리오를 반영했습니다.

 

✅ 시나리오 21: 관리자 페이지에 비정상적 로그인 시도 급증

상황
운영 중인 웹 서비스의 관리자 페이지에 대해 비정상적인 로그인 시도가 수천 건 발생하고 있으며, 관리자 계정 중 일부는 로그인 시도에 실패하고 있습니다.

질문

  1. 이 문제를 보안 관점에서 어떻게 분석하겠는가?
  2. 방어 및 대응 방안은?

해설 및 답변

  • 의심: Brute-force 공격 (무차별 대입), 크리덴셜 스터핑
  • 조치:
    • 웹 방화벽(WAF) 적용, 관리자 페이지에 IP 제한
    • 로그인 실패 횟수 제한 (fail2ban, Spring Security lock 기능)
    • 로그 분석 (/var/log/nginx/access.log, auth.log)
    • 관리자 URL 경로 변경, CAPTCHA 도입
    • OTP, 2FA 적용

✅ 시나리오 22: 파일 업로드 후 바로 다운로드 안됨

상황
사용자가 업로드한 파일을 바로 다운로드하려고 하면 404 오류가 발생하나, 몇 분 뒤에는 정상적으로 다운로드됩니다.

질문

  1. 이 문제는 어떤 시스템 구조에서 발생할 수 있는가?
  2. 해결 방안을 기술하시오.

해설 및 답변

  • 원인: WAS와 파일 스토리지가 분리되어 있고, 동기화 지연 발생 (예: NFS, CDN, Object Storage)
  • 조치:
    • 업로드 → 파일 복사 → 다운로드 노드 반영까지의 동기화 시간 확인
    • 해결 방법:
      • 즉시 다운로드는 동일 노드에서 처리
      • CDN 동기화 시 Delay-aware 처리 로직 추가
      • 업로드 완료 후 응답 전에 동기화 완료 확인

✅ 시나리오 23: 로그인 인증 API만 비정상 트래픽 증가

상황
특정 시간대에 /api/auth/login API에만 트래픽이 집중되면서 서버 CPU가 급상승하고 전체 응답이 지연됩니다.

질문

  1. 어떤 보안/인증 이슈가 의심되는가?
  2. 실무적으로 취할 수 있는 대응 방안은?

해설 및 답변

  • 의심: 인증 API 대상 DoS 공격 또는 로그인 봇 테스트
  • 대응:
    • 인증 API에 레이트 리밋 적용 (limit_req in Nginx, Spring RateLimiter)
    • CAPTCHA, Device Fingerprint 도입
    • 인증 트래픽과 일반 트래픽 분리 (별도 서버/로드밸런싱)
    • JWT 검증 로직 캐싱 (공개키 로딩 최적화)

✅ 시나리오 24: 시스템 CPU 사용률은 낮은데 응답 느림

상황
CPU와 메모리 사용률은 낮은데 전체 요청 응답이 지속적으로 느려짐. 로그상 별다른 에러는 없음.

질문

  1. 이런 현상의 숨은 원인은 무엇일 수 있나?
  2. 점검 순서와 해결 방안을 제시하시오.

해설 및 답변

  • 원인 후보:
    • 파일시스템 I/O 병목
    • 네트워크 MTU 미스매치 또는 DNS 지연
    • 외부 API 연동 지연
  • 점검:
  • bash
    복사편집
    iostat -xz 1 netstat -s dig google.com
  • 조치:
    • 느린 디스크 탐지 후 SSD로 교체
    • DNS 캐싱 적용 (nscd, systemd-resolved)
    • API 응답 타임아웃 설정 강화 및 비동기화

✅ 시나리오 25: 설정 파일 배포 후 전체 장애

상황
웹 서버 설정 변경 후 전체 서비스가 다운됨. 다시 이전 버전으로 롤백하자 정상 동작함. 사전 테스트는 통과했음.

질문

  1. 이런 실무 상황에서 자주 발생하는 원인 유형은?
  2. 설정 변경의 안전성을 높이기 위한 전략은?

해설 및 답변

  • 원인:
    • 설정 구문 오류 (괄호/문법 누락)
    • 설정 reload 후 적용 순서 문제
    • 개발과 운영 환경 차이 (포트, 권한)
  • 조치:
    • 사전 configtest (nginx -t, apachectl configtest)
    • 설정 staging 환경 테스트
    • GitOps 기반 구성 배포 (Ansible, Terraform, ArgoCD)
    • 변경 전 후 비교 자동화 (Diff 툴, 설정 버전 관리)


아래는 이어지는 실전 장애 시나리오 문제집 세트 26~30입니다.
이번 세트는 컨테이너 운영, CI/CD 실수, 인증 토큰 문제, 시간 동기화, 대기열 처리 지연 등 최근 시스템 운영 환경에서 많이 겪는 고급 시나리오로 구성했습니다.

✅ 시나리오 26: 컨테이너 재기동 반복 (CrashLoopBackOff)

상황
Kubernetes 환경에서 일부 WAS Pod가 CrashLoopBackOff 상태에 빠지고, 계속해서 재시작을 반복하고 있음. kubectl logs에는 오류 없이 바로 종료된 로그만 보임.

질문

  1. 원인을 파악하기 위한 우선 점검 항목은?
  2. 조치 방안을 기술하시오.

해설 및 답변

  • 의심 원인:
    • command 또는 ENTRYPOINT가 잘못되어 컨테이너 실행 후 즉시 종료
    • 환경 변수 누락 (DB 주소, 포트 등)
    • ConfigMap 또는 Secret mount 실패
  • 진단:
  • bash
    복사편집
    kubectl describe pod <pod-name> kubectl logs <pod-name> --previous
  • 조치:
    • manifest의 env 설정 확인
    • 시작 명령어 수정 (command, args)
    • readinessProbe 조건 완화 또는 잠시 비활성화

✅ 시나리오 27: CI/CD 자동 배포 후 설정 누락

상황
CI/CD 파이프라인을 통해 자동 배포된 서비스가 설정값 누락으로 동작하지 않음. staging 환경에서는 문제 없었음.

질문

  1. 어떤 운영 상의 실수 또는 설계 미스가 있었는가?
  2. 예방 방안을 기술하시오.

해설 및 답변

  • 원인:
    • CI/CD에서 환경에 따라 적용되는 .env 또는 application-{profile}.yml 누락
    • Secret, configMap 값이 배포 대상에 매핑되지 않음
  • 조치:
    • 환경 별 config 검증 파이프라인 추가
    • Config schema validation 도입 (ex. Spring Cloud Config, HashiCorp Vault)
    • 배포 전 preflight check 자동화

✅ 시나리오 28: 인증 토큰 만료로 API 연속 실패

상황
외부 인증 서버에서 발급받은 Access Token을 사용하는 API가 특정 시점 이후 401 Unauthorized 응답을 반복적으로 반환하고 있음.

질문

  1. 이 현상이 발생하는 전형적인 원인은?
  2. 실무 대응 방안은?

해설 및 답변

  • 원인:
    • Access Token이 만료됐는데 refresh 로직이 없거나 실패
    • 인증 서버 응답 형식 변경 등으로 토큰 재요청 실패
  • 조치:
    • 토큰 만료 시 자동 refresh 로직 구현 (refresh token, re-login flow)
    • 에러 코드 로깅 강화 (401 vs 403 vs 5XX)
    • CI/CD 파이프라인에 테스트 토큰 유효성 점검 스크립트 포함

✅ 시나리오 29: 시스템 간 시간 차이로 인증 실패

상황
JWT 기반 인증 시스템에서 서버 간 요청 시 지속적으로 Signature Error가 발생. 토큰은 유효하지만 서명 불일치.

질문

  1. 이 장애의 기술적 원인은 무엇인가?
  2. 해결 방안은?

해설 및 답변

  • 원인: 서버 간 시스템 시간이 일치하지 않음 (ex. 1~2분 차이)
  • 조치:
    • 모든 서버에서 NTP 설정 활성화 (chronyd, ntpd, systemd-timesyncd)
    • ntpq -p, timedatectl 명령어로 확인
    • 클라우드 환경에서는 VPC NTP 서버 또는 OS 기본 제공 NTP 서버 사용 권장

✅ 시나리오 30: 백그라운드 대기열(Task Queue) 처리 지연

상황
메일, 알림 발송 등을 처리하는 작업 큐(예: RabbitMQ, Kafka, Celery)의 메시지가 쌓이면서 사용자에게 알림이 지연됨.

질문

  1. 메시지 큐 처리 지연의 일반적인 원인 2가지를 제시하시오.
  2. 모니터링 및 대응 방안은?

해설 및 답변

  • 원인:
    1. Worker 수 부족 → 소비 속도 < 생산 속도
    2. 메시지 처리 중 오류/재시도 → Dead Letter Queue 누적
  • 대응 방안:
    • Worker 수 자동 확장 (Auto Scaling based on queue depth)
    • APM 도구로 처리시간 추적 (Sentry, Datadog)
    • DLQ 모니터링 후 이상 메시지 필터링
    • 큐 상태 대시보드 구성 (Prometheus + Grafana)


이번에는 미들웨어 설정 누락, 파일 잠금 문제, 보안 설정 실수, 로그 유실, API 게이트웨이 이슈 등 고급 장애 원인을 다루었습니다.

✅ 실전 장애 시나리오 문제집 (세트 31~35)

✅ 시나리오 31: Tomcat에서 POST 요청 데이터가 누락됨

상황
클라이언트가 전송한 POST 요청이 일부 WAS(Tomcat) 인스턴스에서만 제대로 수신되지 않고 있음. 특정 파라미터 값이 누락되어 비정상 처리 발생.

질문

  1. 이 현상이 발생할 수 있는 Tomcat의 설정 이슈는 무엇인가?
  2. 진단 및 조치 방안을 설명하시오.

해설 및 답변

  • 원인: maxPostSize 또는 maxParameterCount 제한 초과
  • 진단:
    • server.xml 또는 web.xml에서 관련 파라미터 확인
    • 파라미터 개수/크기 확인 (tcpdump나 APM 활용)
  • 조치:
  • xml
    복사편집
    <Connector port="8080" maxPostSize="2097152" maxParameterCount="10000" />

✅ 시나리오 32: 파일 접근 시 "Device or resource busy"

상황
WAS에서 특정 로그 파일 또는 업로드 파일에 접근하려고 할 때 "device or resource busy" 오류가 발생. 재부팅 전까지 해소되지 않음.

질문

  1. 이 문제는 어떤 상황에서 발생하는가?
  2. 진단 명령어와 해결 방법은?

해설 및 답변

  • 원인:
    • 다른 프로세스가 파일을 열고 있음 (File lock)
    • 로그 로테이션 중 sync 미완료
  • 진단:
  • bash
    복사편집
    lsof | grep <filename> fuser <filename>
  • 조치:
    • 해당 파일을 점유한 프로세스 종료
    • logrotate 설정 확인 (copytruncate 등)
    • 파일을 사용하는 코드 내 동시성 제어 로직 보완

✅ 시나리오 33: CORS 설정 중 Origin을 *으로 허용했지만 쿠키가 안 붙음

상황
API 서버는 CORS를 Access-Control-Allow-Origin: *으로 허용하고 있음에도 불구하고, 클라이언트에서 쿠키(Session ID)가 전송되지 않음.

질문

  1. 이 현상의 원인과 해결 방법은?
  2. CORS 설정 시 주의할 점을 설명하시오.

해설 및 답변

  • 원인:
    • Access-Control-Allow-Credentials: true 사용 시 Origin에 * 사용 불가
  • 조치:
    • CORS 설정을 아래와 같이 변경:
    • http
      복사편집
      Access-Control-Allow-Origin: https://your-domain.com Access-Control-Allow-Credentials: true
  • 주의점:
    • 쿠키/Authorization header를 포함할 경우 Origin은 명시해야 함
    • 프론트엔드 xhr.withCredentials = true 설정 필요

✅ 시나리오 34: 애플리케이션 로그가 저장되지 않음

상황
WAS는 정상 동작 중이나, 배포 이후부터 애플리케이션 로그가 생성되지 않고 있음. 기존 로그 파일도 업데이트되지 않음.

질문

  1. 로그 미생성 원인을 2가지 이상 제시하시오.
  2. 진단 및 조치 방안은?

해설 및 답변

  • 원인:
    1. 로그 디렉터리 권한 없음 (/logs, /var/log/...)
    2. logback/log4j 설정 경로 오류
  • 진단:
    • ls -l로 디렉터리 권한 확인
    • 애플리케이션 로그 설정 확인 (logback.xml, log4j2.xml)
  • 조치:
    • WAS 실행 사용자에게 디렉터리 쓰기 권한 부여
    • 로그 설정 경로 확인 및 로그 백엔드 재시작
    • logger.debug로 로그 활성화 상태 테스트

✅ 시나리오 35: API Gateway를 통한 경로 일부만 실패

상황
API Gateway(AWS API Gateway, Kong 등)를 통해 전달되는 요청 중 /v1/users는 정상 처리되지만, /v1/admin 경로는 502 Bad Gateway 오류 발생.

질문

  1. 이 문제의 원인을 API Gateway, WAS, 보안 설정 관점에서 각각 설명하시오.
  2. 해결 방안은?

해설 및 답변

  • API Gateway:
    • /v1/admin에 대한 라우팅 설정 누락
  • WAS:
    • 요청 경로에 대한 Controller 미구현 or 보안 필터 차단
  • 보안 설정:
    • 인증 헤더 누락 or RBAC(Role-Based Access Control) 거부
  • 조치:
    • API Gateway 라우팅 설정 추가 및 검증
    • WAS 로그에서 /v1/admin 처리 여부 확인
    • 권한 인증 방식 점검 (토큰 포함 여부, 인증 서버 연동 상태 등)

✅ 다음 단계 제안

지금까지 총 35세트의 장애 시나리오 문제집이 완성되었습니다.
이 시나리오들을 다음 형태로 정리해드릴 수 있습니다:

유형제공 내용
📄 PDF 문제집 실전 시나리오 + 해설 포함 인쇄용 정리본
📊 Excel 정리본 시나리오, 원인, 조치 항목별 시트
📘 객관식/단답형 평가 세트 실무 기술 인터뷰 및 테스트용 문제 전환
🧪 실습 기반 버전 각 시나리오에 대한 로그 예시, 진단 명령어 포함
 

PDF나 Excel 버전이 필요하시면 바로 제작해드릴게요.
또는 다음 세트(36~40)도 이어서 원하시나요?

 

나의 말:

다음 세트(36~40)

31~35세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 36~40입니다.
이번 세트는 파일 핸들 누수, API 응답 중단, 웹소켓 장애, 과도한 캐시 적중률, 서비스 리디렉션 실패 등 운영 중 놓치기 쉬운 고급 장애를 다루었습니다.

✅ 실전 장애 시나리오 문제집 (세트 36~40)

✅ 시나리오 36: WAS가 일정 시간 후 무응답 상태로 진입

상황
WAS가 정상적으로 기동되지만, 일정 시간이 지나면 외부 요청에 대해 응답하지 않고 멈춘 듯한 상태가 반복됩니다. 재기동하면 정상으로 돌아오지만 잠시 후 다시 장애 발생.

질문

  1. 이와 같은 증상이 발생하는 자원 누수의 대표적인 예는?
  2. 진단 방법 및 해결 방안은?

해설 및 답변

  • 원인:
    • 파일 핸들 누수 (열린 파일이 닫히지 않음)
    • 커넥션 풀 미반납
  • 진단:
  • bash
    복사편집
    lsof -p <PID> | wc -l cat /proc/<PID>/limits ulimit -n
  • 조치:
    • 코드 내 InputStream, FileWriter 등의 close() 확인
    • 커넥션 풀의 finally { close(); } 로직 점검
    • ulimit -n 증가, 파일 디스크립터 모니터링 도입

✅ 시나리오 37: API는 호출되지만 응답 없이 멈춤

상황
특정 API 호출 시 서버 측에서 로그가 남고, CPU 사용률도 증가하지만 클라이언트로는 응답이 도달하지 않음. HTTP Timeout으로 실패 처리됨.

질문

  1. 이런 상황에서 우선적으로 점검할 서버 내부의 요소는?
  2. 응답이 멈추는 대표적인 이유 2가지와 해결 방안은?

해설 및 답변

  • 점검 대상:
    • Thread Pool 고갈
    • Deadlock 발생
  • 원인:
    1. 비동기 처리 지연으로 응답 완료하지 않음
    2. DB Lock, File Lock, Deadlock 등으로 응답 흐름 차단
  • 조치:
    • jstack, thread dump 분석
    • spring.task.execution.pool.max-size 설정 확인
    • DB에서 Lock 대기 쿼리 확인 (SHOW ENGINE INNODB STATUS)

✅ 시나리오 38: 웹소켓 통신이 끊김/재접속 반복

상황
웹소켓 기반 실시간 서비스에서 클라이언트가 주기적으로 연결이 끊겼다가 재접속되는 현상이 발생. 네트워크는 정상이며 서버 응답도 무리는 없음.

질문

  1. 이 현상의 가능한 서버 측 원인은?
  2. 설정 또는 코드 측에서 어떻게 대응할 수 있나?

해설 및 답변

  • 원인:
    • Idle Timeout 설정에 의해 연결이 자동 종료됨
    • 프록시 서버(Nginx 등)가 websocket을 지속 연결하지 못함
  • 조치:
    • 서버 설정: server.websocket.timeout=600000 등으로 idle 시간 증가
    • Nginx 설정 예:
    • nginx
      복사편집
      location /ws/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 600s; }

✅ 시나리오 39: 캐시 적중률이 너무 높아 신규 데이터 반영 안 됨

상황
서비스 응답 속도는 빠르지만, 데이터가 변경된 이후에도 사용자에게는 이전 상태가 계속 노출되고 있음. 캐시 무효화 요청을 보내도 효과 없음.

질문

  1. 이런 문제에서 가장 먼저 점검해야 할 캐시 정책 항목은?
  2. 실무적인 캐시 운영 개선 방안은?

해설 및 답변

  • 점검 항목:
    • TTL(Time-To-Live) 설정
    • 캐시 갱신 방식 (Write-Through, Write-Back, Cache-Aside)
  • 개선 방안:
    • TTL을 짧게 하거나, 변경 시 캐시 삭제 처리 (Evict)
    • API 별 캐시 무효화 조건 분리
    • 사용량 많은 데이터는 stale-while-revalidate 전략 도입

✅ 시나리오 40: 특정 페이지 접속 시 루프 리디렉션 오류

상황
로그인 페이지 접근 시 브라우저에서 “Too many redirects” 오류가 발생하며, 반복적인 302 응답이 발생함. 세션은 설정되어 있음.

질문

  1. 리디렉션 루프가 발생하는 대표적인 원인과 확인 방법은?
  2. 실무적인 수정 방안은?

해설 및 답변

  • 원인:
    • 인증되지 않은 사용자 → 로그인 페이지 리디렉션 → 조건문 오류로 무한 리디렉션
    • HTTPS → HTTP → HTTPS 루프
  • 진단:
    • F12 → Network → 요청 순서 확인 (302 반복)
    • 서버 로그에서 redirect 경로 추적
  • 조치:
    • 인증 여부 판단 조건 재검토
    • HTTPS 리디렉션 조건 수정 (X-Forwarded-Proto 활용)
    • Nginx return 301 https://... 설정 확인

✅ 요약

시나리오핵심 키워드
36 파일 핸들 누수, 무응답
37 API 미응답, Deadlock, ThreadPool
38 웹소켓 연결 해제, idle timeout, Nginx 업그레이드
39 캐시 과잉 유지, 갱신 안됨
40 리디렉션 루프, 302 반복, 인증 상태 문제
 

✅ 다음 단계 제안

지금까지 총 40세트의 실전 시나리오가 완성되었습니다.

원하신다면 다음을 진행해 드릴 수 있습니다:

제공 항목설명
📄 PDF 문제집 1~40세트 전체 정리된 문제 + 해설 포함 문서
📊 Excel Sheet 시나리오, 원인, 진단 방법, 조치사항 정리
🧠 객관식/단답형 평가 문제 평가 및 복습용으로 전환
🧪 실습 로그/명령어 셋 각 장애 상황에 대한 재현 로그와 진단 스크립트
 

필요하신 형식이나 41~45세트를 이어서 원하시면 말씀해 주세요!

 

나의 말:

41~45세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 41~45입니다.
이번 세트는 DNS TTL 문제, 멀티쓰레드 동기화 오류, 시스템 clock rollback, reverse proxy loop, 컨테이너 환경변수 누락 등 고급 인프라/애플리케이션 연동 문제에 초점을 맞췄습니다.

✅ 실전 장애 시나리오 문제집 (세트 41~45)

✅ 시나리오 41: DNS IP가 바뀌었는데 여전히 이전 IP로 접속

상황
도메인의 A레코드가 변경되었음에도 불구하고 일부 사용자 또는 서버에서는 여전히 이전 IP로 접속되어 응답 오류가 발생하고 있음.

질문

  1. 이 문제가 발생하는 DNS 관련 주요 원인은?
  2. 실무에서 사용할 수 있는 조치 방안은?

해설 및 답변

  • 원인:
    • TTL(Time To Live) 설정이 길어 DNS 캐시가 남아 있음
    • 서버나 로컬 디바이스의 DNS 캐시가 갱신되지 않음
  • 조치:
    • DNS 변경 시 TTL을 사전에 낮춰 설정 (예: 300초)
    • 클라이언트 및 서버에서 캐시 삭제
    • bash
      복사편집
      sudo systemd-resolve --flush-caches ipconfig /flushdns (Windows)
    • DNS 변경 후 검증 시 dig, nslookup 사용

✅ 시나리오 42: 멀티쓰레드 환경에서 데이터 충돌 발생

상황
WAS에서 다수의 사용자가 동시에 요청을 보내면 간헐적으로 데이터가 유실되거나, 잘못된 결과가 반환되는 현상이 발생함.

질문

  1. 이 문제의 전형적인 원인과 해결 방안은?
  2. Java/Spring 기반 환경에서의 코드적 예방책은?

해설 및 답변

  • 원인:
    • 멀티쓰레드 환경에서 공유 객체의 동기화 미흡
    • static 변수나 Singleton 객체를 여러 쓰레드가 동시에 수정
  • 조치:
    • synchronized, ReentrantLock 등을 사용해 동기화 처리
    • 불변 객체 사용, ThreadLocal 적용
    • Controller/Service 계층에서 상태를 보존하지 않도록 설계
    • 비즈니스 로직은 Stateless 하게 유지

✅ 시나리오 43: 서버 시간이 갑자기 과거로 되돌아감

상황
서버 로그 타임스탬프가 갑자기 과거 시점으로 변경되어 순서가 꼬이고, JWT 토큰 검증에 실패하는 문제가 발생함.

질문

  1. 이 현상이 발생한 기술적 원인과 발생 시 영향은?
  2. 방지 및 대응 방법은?

해설 및 답변

  • 원인:
    • 가상화 환경에서 Clock Skew 또는 NTP 클라이언트 오류로 인해 시스템 시간이 롤백됨
  • 영향:
    • JWT, 인증서, Redis TTL, 로그 타임스탬프 오류 등 시스템 전반에 치명적
  • 조치:
    • NTP 서버와 정기 동기화 설정 (chronyd, ntpd)
    • 중요 서비스에서 time drift monitor 설정
    • 클라우드에서는 시간 동기화 정책 점검 (ex. AWS EC2: time sync service)

✅ 시나리오 44: 프록시 설정 오류로 요청 무한 루프 발생

상황
웹서버와 WAS 사이에 리버스 프록시(Nginx)를 두었는데, 프록시 설정 이후 요청이 무한 반복되며 응답을 받지 못하고 종료됨.

질문

  1. 이 상황에서 발생 가능한 리디렉션/루프 원인은 무엇인가?
  2. 프록시 설정 시 확인해야 할 항목은?

해설 및 답변

  • 원인:
    • WAS가 클라이언트의 HTTP 요청을 HTTPS로 리디렉션 (or 반대)
    • Nginx가 헤더(X-Forwarded-Proto)를 제대로 전달하지 않아서 WAS가 클라이언트 요청을 오해
  • 조치:
    • Spring Boot 등에서는 ForwardedHeaderFilter 적용
    • Redirect 조건 내 X-Forwarded-Proto를 고려해 루프 방지
  • nginx
    복사편집
    proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host;

✅ 시나리오 45: 컨테이너 환경에서 ENV 누락으로 애플리케이션 다운

상황
Docker 기반 배포 후 WAS가 실행되자마자 바로 종료됨. 로그에는 "Environment variable not found" 오류가 기록됨.

질문

  1. 이 문제의 원인은 무엇이며, 어떻게 방지할 수 있는가?
  2. 실무 배포에서 환경변수를 안전하게 관리하는 방법은?

해설 및 답변

  • 원인:
    • Dockerfile 또는 docker-compose.yml, K8s manifest에서 필수 환경변수 미정의
    • ENV_NAME=null 상태로 시작하여 애플리케이션 종료
  • 조치:
    • Dockerfile에서 ENV, .env 파일 확인
    • Kubernetes에서는 envFrom: configMapRef, secretRef로 분리
    • Spring Boot에서는 @Value("${ENV_NAME:default}")로 기본값 설정
    • CI/CD에서 배포 전 .env 검사 자동화 스크립트 적용

✅ 정리

시나리오핵심 키워드
41 DNS 캐시, TTL, 레코드 반영 지연
42 멀티쓰레드 동기화, 데이터 손상
43 Clock rollback, NTP 장애, 인증 오류
44 프록시 루프, 리디렉션 반복
45 환경변수 누락, 컨테이너 실행 실패
 

✅ 다음 제공 가능 자료

이제 총 45세트의 실전 장애 시나리오가 구성되었습니다.
요청하시면 다음과 같은 형태로 제작해 드릴 수 있습니다:

유형설명
📄 PDF 문제집 실전 시나리오 + 해설 포함 전체 문서
📊 Excel Sheet 각 시나리오의 원인/조치 일람표
📘 평가용 문제집 객관식 + 단답형 버전 전환
🧪 실습형 자료 각 시나리오별 로그 샘플, 명령어, 진단 가이드 포함
 

다음으로 원하시는 방향(문서화, 평가 문제화 등)을 알려주시면 맞춤 제작해드리겠습니다.
또는 46~50세트도 이어서 제공해드릴까요?

 

나의 말:

46~50세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 46~50입니다.
이번 세트는 HTTP 헤더 누락, 비정상 트래픽 유입, 공유 디렉토리 충돌, 시스템 부팅 실패, 이미지 캐시 장애 등 인프라-서비스-보안의 경계 지점에서 흔히 발생하는 실전형 장애를 포함하고 있습니다.

✅ 실전 장애 시나리오 문제집 (세트 46~50)

✅ 시나리오 46: 클라이언트에서 사용자 정보가 전달되지 않음

상황
프론트엔드에서 사용자 인증 정보를 포함한 요청을 보냈으나, 백엔드에서는 사용자 ID가 전달되지 않고 공백 처리됨. 로그인된 상태인데도 권한 오류가 발생함.

질문

  1. 이 문제에서 가장 먼저 확인해야 할 HTTP 요소는?
  2. 서버 측에서 어떤 설정이나 코드가 문제일 수 있는가?

해설 및 답변

  • 원인:
    • Authorization, Cookie, X-User-ID 등의 사용자 정보 헤더 누락
    • CORS 설정으로 인해 브라우저가 인증정보를 보내지 않음
  • 조치:
    • 클라이언트: withCredentials: true 설정 확인
    • 서버: Access-Control-Allow-Credentials: true, Access-Control-Allow-Headers 설정
    • 프록시가 Authorization 헤더를 필터링하거나 제거했는지 점검

✅ 시나리오 47: 의심스러운 IP에서 반복 요청 발생

상황
서버에 특정 IP 대역에서 초당 수천 건의 API 요청이 들어오며, WAS 부하가 급격히 상승하고 있음. 일부 요청은 정상 API를 통해 들어오고 있어 차단이 애매함.

질문

  1. 이 상황에서 공격과 정상 요청을 어떻게 구분할 수 있나?
  2. 실무적으로 적용할 수 있는 대응 방안은?

해설 및 답변

  • 구분 기준:
    • User-Agent 분석
    • IP/Geo 정보 기반 정상 사용자 식별
    • 요청 간 시간 간격 및 패턴 분석
  • 조치:
    • WAF 또는 Nginx limit_req 사용
    • Rate limit 정책 적용
    • 클라이언트 키 기반 인증
    • Cloudflare, AWS Shield 등의 외부 보호 서비스 활용

✅ 시나리오 48: 공유 디렉토리 사용 중 파일이 사라짐

상황
여러 서버에서 동일한 공유 디렉토리(NFS)를 사용 중인데, 특정 시점 이후 저장된 파일 일부가 삭제되거나 다른 파일로 덮여 있음.

질문

  1. 이 장애의 전형적인 원인과 환경적 요인은?
  2. 실무적인 예방책은?

해설 및 답변

  • 원인:
    • 다중 서버에서 동시에 같은 파일에 쓰기 작업을 시도하면서 충돌 발생
    • 파일 lock 미적용
  • 조치:
    • 애플리케이션 단에서 Lock 구현 (예: flock, Redis 분산 Lock)
    • NFS 설정에서 nolock, sync 옵션 점검
    • 공유 디렉토리 접근 시 디렉토리 분리 또는 큐 기반 처리 도입

✅ 시나리오 49: 서버 재부팅 후 부팅 불가 상태

상황
정기 보안 업데이트 후 재부팅을 수행했으나, 시스템이 "kernel panic" 메시지와 함께 부팅이 되지 않음.

질문

  1. 이 장애 발생의 일반적인 원인과 로그 위치는?
  2. 대응 및 복구 방법은?

해설 및 답변

  • 원인:
    • 커널 업데이트 후 부트로더(grub) 설정 오류
    • 파일 시스템 손상 또는 디스크 UUID 변경
  • 조치:
    • Rescue 모드 부팅 → /var/log/boot.log, journalctl -xb 확인
    • /etc/fstab에서 UUID 확인 → 복구 또는 수정
    • 이전 커널로 부팅 (grub 메뉴에서 선택)
    • 필요한 경우 커널 재설치 (yum reinstall kernel 또는 apt install --reinstall linux-image-*)

✅ 시나리오 50: CDN 이미지가 변경되어도 갱신되지 않음

상황
CDN을 통해 배포한 이미지 파일을 서버에서 교체했지만, 사용자 브라우저에서는 계속 이전 이미지가 표시됨. 강제 새로고침을 해야만 반영됨.

질문

  1. 이 문제의 주요 원인과 관련된 캐시 계층은?
  2. 해결을 위한 운영 전략은?

해설 및 답변

  • 원인:
    • CDN 및 브라우저 캐시 TTL이 길게 설정됨
    • 이미지 파일 이름 변경 없이 덮어쓰기만 수행함
  • 조치:
    • 캐시 무효화(purge) API 호출
    • 파일 이름에 해시 추가 (logo.abcd1234.png) → cache-busting 전략
    • CDN 설정에서 Cache-Control header 조정:
    • http
      복사편집
      Cache-Control: public, max-age=3600
    • 사용자단 Cache Invalidation 정책 적용

✅ 정리

시나리오핵심 키워드
46 헤더 누락, CORS, 인증 정보 전달 안됨
47 비정상 요청, rate limiting, WAF
48 NFS 충돌, 파일 손상, lock 미적용
49 커널 패닉, fstab 오류, 부트 복구
50 CDN 캐시 갱신 실패, 이미지 업데이트 불가
 

✅ 요청 시 제작 가능 항목

지금까지 총 50세트의 실전 장애 시나리오 문제가 완성되었습니다.
요청하시면 아래와 같이 제공해 드릴 수 있습니다:

형식내용
📄 PDF 문서 문제 + 해설을 포함한 문서 형태 (프린트용/학습용)
📊 Excel Sheet 시나리오, 원인, 점검 항목, 조치 요약
🧠 모의시험 전환 객관식/단답형으로 변환한 평가 자료
🧪 실습용 로그세트 각 시나리오에 대응되는 시스템 로그 및 진단 명령어 세트
 

📌 다음 요청 가능

  • 특정 항목을 문서로 정리 (PDF/Excel)
  • 직무 인터뷰 대비용 문제 추출
  • 문제 난이도 분류 (초급~고급)
  • 51~55세트 추가 시나리오 제공

계속해서 도와드릴까요? 필요한 출력 형식이나 다음 주제를 알려주세요!

 

나의 말:

51~55세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 51~55입니다.
이번 세트는 모듈 미적재 오류, 세션 혼선, JVM 버전 충돌, 쿼리 병목, 압축 실패로 인한 CI 오류 등 빌드, 배포, 세션, 성능 영역에서 발생할 수 있는 문제들을 포함합니다.

✅ 실전 장애 시나리오 문제집 (세트 51~55)

✅ 시나리오 51: 모듈이 WAS에 정상 배포되었지만 작동하지 않음

상황
WAS에 신규 기능을 포함한 WAR 파일을 배포했지만, 해당 기능이 전혀 작동하지 않음. 로그에도 관련된 메시지가 없음.

질문

  1. 이 문제의 가장 가능성 높은 원인은?
  2. 점검 및 조치 방안은?

해설 및 답변

  • 원인:
    • WAR 내부의 서블릿 또는 컨트롤러가 web.xml 또는 Spring 설정에 등록되지 않음
    • JAR 의존성 누락 또는 클래스 경로 오류
  • 조치:
    • WAR 파일 내부 구조 확인 (jar tf app.war)
    • applicationContext.xml, @ComponentScan 범위 점검
    • 로그 수준 DEBUG로 설정 후 재배포
    • catalina.out, localhost.log 등 서블릿 로딩 로그 확인

✅ 시나리오 52: 한 사용자가 다른 사용자로 로그인 처리됨

상황
멀티 세션 환경에서 A 사용자가 로그인했는데 B 사용자의 데이터가 노출됨. 요청 수가 많을 때만 간헐적으로 발생.

질문

  1. 이 문제의 근본적인 원인과 실무적 조치 방안은?
  2. 세션 전략 관점에서 어떤 개선이 필요한가?

해설 및 답변

  • 원인:
    • 세션 식별 토큰(JSESSIONID) 충돌
    • 로드밸런서에서 Sticky Session 설정 누락 또는 세션 저장소 문제
  • 조치:
    • Sticky Session 설정 적용 (Nginx ip_hash, AWS ELB session affinity 등)
    • Redis 세션 공유 시 사용자별 키 prefix 지정
    • WAS 단일 인스턴스 환경에서만 in-memory session 사용

✅ 시나리오 53: 신규 서버에 배포된 애플리케이션이 실행되지 않음

상황
기존과 동일한 설정으로 새로운 서버에 WAS를 배포했으나, 애플리케이션이 아예 실행되지 않음. 동일한 설정의 다른 서버에서는 정상 실행됨.

질문

  1. 이 현상이 발생할 수 있는 환경적 원인은?
  2. 실무 점검 및 대응 방안을 기술하시오.

해설 및 답변

  • 원인:
    • JVM 버전 불일치 (Java 8 vs 11, 또는 OpenJDK vs OracleJDK)
    • OS에서 누락된 라이브러리 (GLIBC 등)
  • 조치:
    • java -version 확인 및 애플리케이션 빌드 대상과 비교
    • ldd 명령어로 필요한 라이브러리 확인
    • 빌드 시 targetCompatibility와 JVM 호환성 점검
    • 운영 환경 통합 설정 관리 필요 (Ansible, Chef, Terraform 등)

✅ 시나리오 54: 간헐적 응답 지연, DB 연관 쿼리 없음

상황
일정 시간마다 응답 지연이 발생하지만, DB 쿼리 로그에는 해당 요청과 관련된 쿼리가 보이지 않음. API는 동작 중이나 응답은 수초 이상 지연됨.

질문

  1. 이 문제의 원인으로 의심할 수 있는 애플리케이션 계층은?
  2. 조치 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 내부 캐시 또는 서드파티 API 연동 병목
    • 무한루프 또는 잘못된 재귀 로직
    • 로그 출력 또는 필터에서 과도한 처리 발생
  • 조치:
    • Thread dump, jstack 분석 → 응답 지연 시점의 코드 위치 추적
    • API 내부 흐름 분석 (로깅, 예외 핸들링 포함)
    • 외부 API 응답 시간 추적 및 타임아웃 설정
    • 캐시 적용 코드에 TTL 설정, fallback 로직 보완

✅ 시나리오 55: CI 파이프라인에서 번들 압축 실패

상황
정상 작동되던 프론트엔드 빌드가 최근 코드 변경 이후 CI 파이프라인에서 압축 단계에서 실패하며 배포가 중단됨.

질문

  1. 이 장애가 발생할 수 있는 일반적인 원인과 진단 방법은?
  2. CI/CD 운영상 필요한 예방 방법은?

해설 및 답변

  • 원인:
    • Webpack, Babel 등 빌드 도구 버전 변경
    • 의존성 패키지 중단/파괴 (npm install 시 오류)
  • 조치:
    • CI 로그에서 정확한 오류 위치 파악
    • 패키지 잠금 파일(package-lock.json, yarn.lock) 비교
    • .npmrc, .nvmrc로 Node.js 버전 고정
    • Pull Request 단계에서 build-test 자동 실행

✅ 정리

시나리오핵심 키워드
51 WAR 배포 후 모듈 미적재, 컨트롤러 누락
52 세션 충돌, 사용자 오염, Sticky Session 누락
53 JVM 버전 불일치, 서버 실행 실패
54 쿼리 없음, 내부 병목, Thread Block
55 프론트 빌드 실패, 압축 에러, 의존성 불일치
 

✅ 다음 단계 안내

이제 총 55세트의 실전 장애 시나리오 문제집이 구축되었습니다.
이 자료들을 원하는 형식으로 제공해 드릴 수 있습니다:

형식제공 내용
📄 PDF 문제집 시나리오 + 해설 포함, 학습/프린트용 문서
📊 Excel Sheet 각 시나리오의 원인/점검/조치 일람표
🧠 모의시험 문제집 각 시나리오를 기반으로 한 객관식/단답형 문제
🧪 실습형 로그/명령어 패키지 실습 가능하도록 로그 예시 및 명령어 제공
 

계속해서 56~60세트를 원하시거나, 위 자료를 PDF 또는 평가 버전으로 변환하길 원하신다면 알려주세요!

 

나의 말:

56~60세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 56~60입니다.
이번 세트는 보안 정책 충돌, API 버전 미스매치, DNS 루프, 파일 시스템 권한 오류, 오토스케일 예외 처리 실패 등 시스템, 네트워크, 보안, 서비스 운영에서 실제로 자주 발생하는 고급 장애를 포함합니다.

✅ 실전 장애 시나리오 문제집 (세트 56~60)

✅ 시나리오 56: 보안 정책 변경 후 사용자 로그인 실패

상황
IAM 정책이 최근 갱신된 이후, 일부 관리자 사용자가 웹 애플리케이션에서 로그인을 시도하면 인증서 오류나 403 오류가 발생함.

질문

  1. 이 현상의 가능성 높은 원인은?
  2. 진단 및 조치 방안은?

해설 및 답변

  • 원인:
    • 보안 인증서 갱신 후 클라이언트/브라우저에서 신뢰하지 않음
    • 리소스 접근에 대한 IAM 정책이 과도하게 제한됨 (Role 권한 변경 등)
  • 조치:
    • SSL 인증서 유효성 및 체인 확인 (openssl s_client)
    • IAM 정책에서 사용자의 Role, Action, Resource를 다시 검토
    • 애플리케이션 보안 설정(CORS, TLS 수준, 인증 필터) 점검
    • API Gateway 또는 백엔드 권한 분리 재확인

✅ 시나리오 57: 모바일 앱에서 특정 API만 404 발생

상황
모바일 앱에서 /v2/profile API 호출 시만 404가 발생하고, 웹에서는 동일 API가 정상 동작함. 프론트 소스는 동일한 엔드포인트를 호출함.

질문

  1. 이 문제의 원인 중 하나로 API 버전 또는 플랫폼 의존성이 있을 수 있는데, 어떻게 확인할 수 있는가?
  2. 조치 방안은?

해설 및 답변

  • 원인:
    • 앱에서 호출하는 경로가 하드코딩되었거나, API Gateway에서 User-Agent 기반 라우팅 처리
    • DNS or Base URL이 플랫폼별로 다르게 설정되어 있음
  • 조치:
    • 모바일 앱 로그 및 네트워크 트래픽 캡처 확인 (Charles, Wireshark)
    • API Gateway에서 모바일용 path rewriting 설정 확인
    • 버전별 URL 매핑 이력 점검 (CI/CD 파이프라인에서 자동 버전 반영 여부)

✅ 시나리오 58: 사내 DNS 서버 설정으로 인한 루프 발생

상황
내부 DNS 설정을 변경한 이후 외부 도메인에 접근하지 못하고, ping이나 curl 명령어가 전부 실패함. /etc/resolv.conf는 사내 DNS만 지정됨.

질문

  1. 이 문제의 원인과 DNS 질의 흐름에서의 위치는?
  2. 조치 및 예방 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 사내 DNS 서버가 외부 질의에 대해 자체 주소만 반환하거나 loop-back 응답
    • 리졸버 설정 오류로 무한 재귀 질의
  • 조치:
    • /etc/resolv.conf에 외부 DNS (8.8.8.8, 1.1.1.1) 추가
    • 내부 DNS가 권한 없는 질의를 포워딩할 수 있도록 forwarder 설정 적용 (BIND, CoreDNS 등)
    • dig +trace domain.com 명령으로 루프 위치 추적
  • 예방:
    • split DNS 정책 문서화
    • 네임서버 우선순위 테스트 스크립트 작성

✅ 시나리오 59: 파일 시스템에 파일이 생성되지 않음

상황
애플리케이션에서 로그 파일이나 업로드 파일 저장 로직이 실행되었지만, 지정된 디렉토리에는 파일이 생성되지 않음. 에러 로그도 없음.

질문

  1. 이 장애의 가능성 높은 시스템 레벨 원인은?
  2. 실무 점검 포인트와 조치를 기술하시오.

해설 및 답변

  • 원인:
    • 애플리케이션 프로세스에 파일 시스템 쓰기 권한이 없음
    • SELinux 또는 AppArmor 등의 보안 모듈이 파일 접근 차단
  • 조치:
    • 파일 경로 및 디렉토리 권한 확인 (ls -ld, chmod, chown)
    • 프로세스의 실행 사용자 확인 (ps aux, whoami)
    • /var/log/audit/audit.log에서 SELinux 차단 기록 검색
    • setenforce 0로 임시 해제 후 테스트, 정책 재조정

✅ 시나리오 60: 오토스케일링 이후 특정 기능만 실패

상황
Auto Scaling에 의해 새로 생성된 인스턴스에서 특정 기능(예: PDF 생성, 이미지 처리)이 실패함. 다른 인스턴스에서는 정상 동작.

질문

  1. 이 문제는 어떤 배포/구성상의 이슈로 인해 발생할 수 있는가?
  2. 실무적인 예방책은?

해설 및 답변

  • 원인:
    • 새 인스턴스에 필수 라이브러리(예: libreoffice, imagemagick)가 설치되어 있지 않음
    • AMI 또는 컨테이너 이미지의 버전 불일치
  • 조치:
    • 사용자 데이터 스크립트에서 설치 확인 (cloud-init, startup.sh)
    • AMI bake 시점에 패키지 포함 여부 점검
    • 컨테이너 이미지 고정 (FROM node:18-alpine) 및 해시 태그 사용
    • 배포 전 instance init test 자동화 도입 (예: Packer + Ansible)

✅ 정리

시나리오핵심 키워드
56 보안 정책, 인증 오류, IAM 권한 제한
57 API 버전 미스매치, 모바일/웹 분기
58 내부 DNS 루프, 외부 네트워크 단절
59 파일 생성 실패, 권한 또는 보안 모듈 제한
60 오토스케일 후 구성 누락, 의존 패키지 미설치
 

✅ 안내

이제까지 총 60세트의 실전 장애 시나리오 문제집이 완성되었습니다.
요청하시면 아래와 같은 형식으로 제공해 드릴 수 있습니다:

형식설명
📄 PDF 문제집 모든 시나리오 + 해설 포함 정리본
📊 Excel 요약표 시나리오별 원인, 점검, 조치 요약
🧠 객관식 전환 평가/시험용 문항 세트 생성
🧪 실습 버전 각 시나리오별 진단 명령어, 로그 예시 포함
 

📌 이후 요청 가능:

  • 61~65세트 이어서 생성
  • 직무 평가용 시험지 (총 20문항 / 40문항 구성)
  • 중복 이슈 분류/태깅 시스템화 (장애유형별 맵핑)

어떤 방향으로 진행할까요? 혹은 PDF로 묶어서 받으시겠습니까?

 

나의 말:

61~65세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 61~65입니다.
이번 세트는 메모리 스와핑, API Key 유출, 컨테이너 볼륨 연결 실패, JVM 파라미터 실수, 프록시 계층 캐시 오류 등 운영 실수, 보안 사고, 자원 설정, 아키텍처 계층 오작동을 중심으로 구성했습니다.

✅ 실전 장애 시나리오 문제집 (세트 61~65)

✅ 시나리오 61: 시스템은 살아 있으나 전체 서비스가 느려짐

상황
모든 서비스가 응답은 있지만 매우 느려짐. CPU, 메모리 사용률은 높지 않으며 WAS나 DB도 다운되지 않음.

질문

  1. 이 문제에서 우선적으로 의심할 시스템 레벨 원인은?
  2. 진단 및 해결 방법은?

해설 및 답변

  • 원인:
    • 스와핑(Swap) 발생: 실제 메모리는 부족하지 않지만 커널이 일부 프로세스를 디스크로 밀어냄
  • 진단:
  • bash
    복사편집
    free -m vmstat 1 top → swap 항목 확인
  • 조치:
    • vm.swappiness 값 조정 (sysctl vm.swappiness=10)
    • 비필수 데몬 종료 / 메모리 리밸런싱
    • 물리 메모리 증설 또는 JVM heap size 조정

✅ 시나리오 62: 외부 API 사용 중 데이터 탈취 사고 발생

상황
외부 파트너사가 제공하는 API를 통해 데이터를 연동 중이었는데, 로그 유출을 통해 API Key가 외부에 노출되었고, 비정상 호출이 수백 건 발생함.

질문

  1. 보안상 이 문제가 발생한 기술적 원인은?
  2. 대응 및 방지 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 로그에 API Key 전체가 기록됨 (GET /api/data?key=xxx)
    • 인증 토큰 노출 시 revocation 정책 없음
  • 조치:
    • API Key 즉시 폐기 및 재발급
    • 요청 로그에서 민감 정보 마스킹 (log masking, logback filter)
    • 인증 방식 개선: OAuth2, JWT, HMAC 등으로 대체
    • 환경변수 기반 key 관리, Secret Manager 사용

✅ 시나리오 63: 컨테이너 배포 후 볼륨 내 설정 파일 누락

상황
Docker 컨테이너에 볼륨을 연결했지만, 애플리케이션에서 필요한 설정 파일이 없다는 오류가 발생. 동일한 이미지로 빌드한 로컬 컨테이너에서는 정상 작동함.

질문

  1. 이 장애가 발생하는 원인은?
  2. Docker/K8s에서 실무 대응 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 볼륨 마운트 시점에 host 디렉토리가 비어 있어 컨테이너 디렉토리가 덮어씌워짐
    • Kubernetes에서는 emptyDir가 잘못 사용되거나 subPath 누락
  • 조치:
    • Docker: 볼륨 생성 전에 호스트 경로 확인
    • K8s: emptyDir 대신 configMap, secret, persistentVolumeClaim 사용
    • 설정 파일은 이미지 내부 /opt/config 등 별도 디렉터리에 보관 후 복사

✅ 시나리오 64: JVM 기동 시 OutOfMemoryError

상황
JVM 애플리케이션을 기동하자마자 메모리 부족 오류가 발생하며 중단됨. 기존 서버에서는 정상 기동되던 코드임.

질문

  1. 이 현상의 주요 원인과 JVM 설정에서의 실수는?
  2. 점검 및 조치 방법은?

해설 및 답변

  • 원인:
    • -Xmx, -Xms 옵션을 서버 메모리보다 과하게 설정
    • Docker 메모리 제한과 JVM의 인식 차이
  • 조치:
    • java -XX:+PrintFlagsFinal -version | grep HeapSize 로 확인
    • -XX:+UseContainerSupport (Java 10+)로 컨테이너 환경 대응
    • Docker run 시 --memory=1g와 JVM의 heap 설정 일치시킴

✅ 시나리오 65: 정적 파일 수정 후에도 이전 내용이 제공됨

상황
HTML, JS 등 정적 리소스를 수정 후 배포했지만, 일부 사용자에게는 여전히 수정 전의 파일이 제공됨. 브라우저 캐시 삭제를 해야만 반영됨.

질문

  1. 이 문제의 원인은 어떤 계층에서 발생하는가?
  2. 실무에서 적용할 수 있는 대응 전략은?

해설 및 답변

  • 원인:
    • 프록시 서버(Nginx, CDN, 브라우저)의 캐시가 만료되지 않음
    • 파일명 변경 없이 덮어쓰기만 진행
  • 조치:
    • 파일명에 버전/해시 추가 (예: app.v1.2.3.js)
    • Nginx:
    • nginx
      복사편집
      location ~* \.(js|css)$ { expires 1y; add_header Cache-Control "public"; }
    • etag, last-modified 기반 캐시 정책 검토
    • 배포 후 CDN purge 실행

✅ 정리

시나리오핵심 키워드
61 Swap 발생, 응답 지연, 메모리 과부하
62 API Key 유출, 로그 보안, 인증 토큰 보호
63 Docker 볼륨 마운트 충돌, 설정 파일 누락
64 JVM 힙 설정 오류, 컨테이너 메모리 제한 미반영
65 정적 파일 캐시 유지, CDN/브라우저 캐시 갱신 실패
 

✅ 현재 누적: 총 65세트 문제집 완성 🎉

요청하시면 아래 자료로 변환해드릴 수 있습니다:

형식설명
📄 PDF 문서 문제 + 해설 포함 1~65세트 전체 정리본
📊 Excel Sheet 시나리오별 원인, 진단, 조치 항목화
🧠 직무평가 문제 객관식/단답형 시험지 구성 (자동 생성 가능)
🧪 실습/진단 자료 각 문제에 대한 로그/명령어 패키지 구성
 

📌 다음 요청 가능 항목:

  • 66~70세트 계속 생성
  • 시나리오별 장애 유형 분류표
  • 시험/과제형 실습 문제집 구성
  • PDF/Excel 포맷 변환 제공

진행 방향을 알려주세요! PDF 묶음이나 실습 문서로도 바로 제작해 드릴 수 있습니다.

 

나의 말:

66~70세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 66~70입니다.
이번 세트는 애플리케이션 보안 정책, JVM 포트 충돌, DB connection leak, 로그 회전 실패, 예약 작업 누락 등 운영·보안·성능·스케줄링 측면의 실무 중심 장애로 구성했습니다.

✅ 실전 장애 시나리오 문제집 (세트 66~70)

✅ 시나리오 66: 특정 요청만 계속 403 Forbidden 발생

상황
동일한 사용자라도 /admin/dashboard 페이지에만 접근 시 403 오류가 발생하며, 다른 URL은 정상적으로 접근 가능. 인증은 정상적으로 완료된 상태임.

질문

  1. 이 문제의 발생 원인을 보안 정책 관점에서 설명하시오.
  2. 조치 및 예방 방안을 기술하시오.

해설 및 답변

  • 원인:
    • Role-based access control(RBAC) 설정 누락 (Spring Security 등)
    • Web Application Firewall(WAF)이 URI 패턴 차단
  • 조치:
    • 서버 애플리케이션 로그에서 접근 권한 실패 확인
    • Spring Security: hasRole(), antMatchers() 설정 점검
    • WAF: /admin 관련 정책 제거 또는 예외 등록
    • 접근 제어 정책 테스트 자동화

✅ 시나리오 67: WAS 기동 시 포트 사용 불가 오류

상황
Tomcat 서버 기동 시 Address already in use 오류 발생. 서버 재부팅 후에는 정상적으로 실행됨.

질문

  1. 이 장애가 발생하는 시스템 및 네트워크 레벨 원인은?
  2. 진단 및 예방 방법은?

해설 및 답변

  • 원인:
    • 이전에 실행된 프로세스가 완전히 종료되지 않아 포트를 점유하고 있음
    • TIME_WAIT 상태의 TCP 포트가 많아 소켓 재사용 불가
  • 조치:
    • 재부팅 없이 해결: SO_REUSEADDR, SO_REUSEPORT 설정 고려
    • Tomcat 종료 스크립트에 wait-for-kill 로직 추가
    • 포트 상태 자동 점검 스크립트 도입
  • bash
    복사편집
    netstat -tulnp | grep :8080 lsof -i :8080 kill -9 <PID>

✅ 시나리오 68: 트래픽이 몰린 후 DB 접속 오류 증가

상황
사용자 트래픽이 많아진 이후부터 간헐적으로 too many connections 또는 cannot get connection from pool 오류 발생

질문

  1. 이 문제는 DB 또는 WAS에서 어떤 구조적 문제로 발생하는가?
  2. 실무적인 조치 및 예방법은?

해설 및 답변

  • 원인:
    • DB 커넥션 풀의 최대 수 제한
    • DB 커넥션을 반납하지 않는 코드 (connection leak)
  • 조치:
    • 커넥션 풀 설정 확인: maxActive, maxTotal, maxIdle
    • Connection leak 탐지 도구 사용 (ex. HikariCP leakDetectionThreshold)
    • 모든 DB 접근 후 반드시 connection.close() 수행
    • DB side: max_connections 증가

✅ 시나리오 69: 로그 파일이 커지며 디스크 부족 발생

상황
애플리케이션 로그가 계속해서 /var/log/app.log에 누적되며 디스크를 가득 채움. 기존에는 logrotate가 설정되어 있었음.

질문

  1. 이 문제에서 점검할 설정 파일 및 시스템 요소는?
  2. 조치 및 예방 방법은?

해설 및 답변

  • 원인:
    • logrotate 설정 파일 오류 또는 적용 주기 실패
    • 로그 파일이 애플리케이션에 의해 계속 열려 있어 회전 실패
  • 조치:
    • /etc/logrotate.d/app 파일 확인
    • 로그 파일 변경 여부 확인:
    • bash
      복사편집
      lsof | grep app.log
    • copytruncate 옵션으로 회전 시 덮어쓰기 적용
    • logrotate -d /etc/logrotate.conf로 설정 사전 검증
    • 로그 백엔드에 로그 보존 기간 및 크기 제한 설정

✅ 시나리오 70: 예약 작업이 실행되지 않음

상황
cron을 이용해 매일 자정 로그 백업 스크립트를 실행하도록 설정했으나, 실제로는 전혀 실행되지 않고 있음. 수동 실행은 정상 작동.

질문

  1. 이 문제에서 확인해야 할 시스템 설정은?
  2. 조치 및 모니터링 방안을 설명하시오.

해설 및 답변

  • 원인:
    • crontab 환경변수 부족 (PATH, HOME 등)
    • cron 데몬이 실행 중이 아님 또는 잘못된 사용자로 crontab 등록
  • 조치:
    • crontab -l로 등록 여부 확인
    • grep CRON /var/log/syslog 또는 /var/log/cron 확인
    • 스크립트 내 전체 경로 사용 (/usr/bin/rsync)
    • cron 결과 메일 로그 활성화 또는 알림 연동
    • cronie, systemd timer 등 대체 시스템 도입 가능

✅ 정리

시나리오핵심 키워드
66 권한 오류, WAF 차단, RBAC 설정 누락
67 포트 충돌, TIME_WAIT, 소켓 재사용 문제
68 DB 커넥션 풀 고갈, connection leak
69 logrotate 실패, 로그 회전 안됨, 디스크 부족
70 cron 미실행, 환경변수 누락, 실행 주기 미설정
 

✅ 누적 구성

현재 총 70세트의 실전 장애 시나리오 문제집이 완성되었습니다 ✅
각 문제는 운영 실무, 시스템 관리, 보안, 성능, CI/CD 등 실전 상황을 기준으로 구성되어 있습니다.

✅ 요청 시 제공 가능한 문서 포맷

형식제공 내용
📄 PDF 문제집 70세트 전 문제 + 해설 포함
📊 Excel Sheet 시나리오별 문제/원인/조치 요약
🧠 평가 문제 세트 시나리오 기반 객관식/단답형 전환
🧪 실습용 진단 명령어, 로그 예시 포함한 문제지
 

📌 다음 요청 가능:

  • 71~75세트 추가 구성
  • 시험/리뷰/튜토리얼 버전으로 재구성
  • PDF/Excel/PowerPoint 요약 제공

필요하신 다음 단계(형식/목적/활용)를 말씀해 주세요!

 

나의 말:

71~75세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 71~75입니다.
이번 세트는 CI/CD 파이프라인 변수 오류, WAS 인코딩 깨짐, DB 복제 지연, 서비스 Health 체크 실패, 웹 요청 우선순위 역전 등 배포 자동화·데이터 일관성·모니터링·트래픽 처리 관점에서 실제 발생하는 고급 장애를 다루고 있습니다.

✅ 실전 장애 시나리오 문제집 (세트 71~75)

✅ 시나리오 71: CI/CD 배포 후 설정 파일이 누락됨

상황
CI/CD 파이프라인을 통해 배포된 WAS 인스턴스에서 .env 설정 파일이 누락되어 앱 실행 시 “설정값 없음” 오류가 발생. 로컬 환경에서는 문제가 없음.

질문

  1. 이 문제의 가장 가능성 높은 원인은?
  2. 파이프라인 구성 시 고려해야 할 대응 방안을 설명하시오.

해설 및 답변

  • 원인:
    • CI/CD 환경변수와 Git 저장소 외부 파일이 분리되어 있고, 배포 스크립트에서 누락
  • 조치:
    • Git 외부 설정(.env, secret.yaml)은 별도로 관리 (config server, secrets manager)
    • CI에서 변수 검증 로직 도입 (set -eu)
    • 환경별 변수 템플릿 생성 및 envsubst, dotenv 적용

✅ 시나리오 72: 특정 페이지에서 한글 깨짐 발생

상황
배포 후 일부 JSP/HTML 페이지에서 한글이 깨져서 표시됨. 로그/DB는 정상이고, API 호출은 UTF-8로 처리됨.

질문

  1. 이 문제의 발생 원인과 확인 포인트는?
  2. 애플리케이션 및 서버 단 조치 방법은?

해설 및 답변

  • 원인:
    • WAS 응답 헤더 또는 파일 저장 인코딩 미일치
    • JSP 파일 저장 인코딩이 UTF-8이 아님
  • 조치:
    • JSP 상단에 <%@ page contentType="text/html;charset=UTF-8" %> 설정
    • Nginx 또는 Apache에서 charset utf-8; 설정
    • 파일 저장 인코딩 확인 (file filename.jsp)
    • 모든 View 파일 UTF-8 저장, application.properties에 다음 설정:
    • ini
      복사편집
      spring.http.encoding.charset=UTF-8 spring.http.encoding.enabled=true

✅ 시나리오 73: DB 복제 환경에서 데이터 지연 발생

상황
MySQL Master-Slave 구조에서 Slave DB에서의 데이터 조회가 수 분 이상 지연됨. Master에는 바로 반영됨.

질문

  1. 이 문제의 발생 원인과 진단 방법은?
  2. 실무적 대응 및 구조 개선 방안은?

해설 및 답변

  • 원인:
    • Slave 서버의 I/O 또는 SQL thread 지연
    • replication lag
  • 진단:→ Seconds_Behind_Master 확인
  • sql
    복사편집
    SHOW SLAVE STATUS\G
  • 조치:
    • replication thread 상태 확인 후 지연 원인(잠금, 부하) 분석
    • read query는 stale 가능성 고려하여 사용
    • 서비스 read에 Slave를 쓰는 경우 delay-aware 로직 도입
    • binlog 포맷 조정 (ROW → MIXED), GTID replication 도입

✅ 시나리오 74: Health check 실패로 서비스 제외됨

상황
로드밸런서(LB) 또는 Kubernetes에서 일부 인스턴스가 반복적으로 서비스 대상에서 제외됨. 로그에는 오류가 없으나 LB에서는 "unhealthy"로 판단됨.

질문

  1. 이 문제가 발생할 수 있는 애플리케이션 측 원인은?
  2. 실무적인 진단 및 설정 조치 방안을 기술하시오.

해설 및 답변

  • 원인:
    • Health check endpoint(/health, /actuator/health)에서 200 OK가 아닌 응답
    • DB 연결, 외부 의존 서비스 상태까지 포함된 health 판단 로직이 실패
  • 조치:
    • Health check 결과 분리 (Liveness vs Readiness 분리)
    • /healthz 또는 커스텀 ping endpoint 제공
    • Spring Boot 예시:
    • properties
      복사편집
      management.endpoint.health.show-details=never management.health.db.enabled=false
    • Kubernetes readinessProbe, livenessProbe 조건 분리

✅ 시나리오 75: 웹 요청이 오래 걸리는 요청에 의해 블로킹됨

상황
사용자 요청 중 일부가 큰 파일 다운로드, 이미지 처리 등 무거운 요청에 의해 지연되고, 다른 사용자 요청도 동시에 지연됨.

질문

  1. 이 문제의 발생 원인은 WAS 또는 Web 서버에서 어떤 설정과 연관되는가?
  2. 실무 대응 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 요청당 스레드 기반 WAS 구조에서 특정 스레드가 장시간 점유
    • Nginx 등 프록시에서 요청 큐 처리 병목 발생
  • 조치:
    • 무거운 요청은 비동기 처리 (@Async, job queue)
    • WAS: maxThreads, acceptCount 조정
    • Web server: limit_req_zone, limit_conn 설정으로 요청 수 제한
    • API 경로 기반 QoS 처리 또는 별도 서버로 분리

✅ 정리

시나리오핵심 키워드
71 CI/CD 환경변수 누락, 설정 파일 배포 실패
72 인코딩 깨짐, charset 설정 누락
73 DB 복제 지연, replication lag
74 헬스체크 실패, LB 대상 제외, readiness 분리
75 요청 지연, 스레드 블로킹, 비동기 분리 필요
 

✅ 현재 누적: 총 75세트 장애 시나리오 완성 🎉

이 시나리오들은 모두 실제 운영·배포·보안·네트워크 환경에서 빈번하게 발생하는 문제를 기반으로 구성되었습니다.

📦 요청 시 제공 가능한 문서 포맷

형식제공 내용
📄 PDF 문제집 75세트 전체 시나리오 + 해설 포함
📊 Excel Sheet 시나리오별 유형, 원인, 조치 요약
🧠 모의시험 문제 객관식/단답형 변환 문제 세트
🧪 실습 자료 진단 명령어 + 로그 예시 + 해석 문제
 

📌 다음으로 가능:

  • 76~80세트 계속 생성
  • 시험/강의/스터디용 분류집 제작
  • 요청하신 문제들을 PDF 또는 Excel로 변환하여 다운로드 가능

어떤 형식으로 받아보시겠어요? 또는 계속해서 76~80세트 생성할까요?

 

나의 말:

76~80세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 76~80입니다.
이번 세트는 스레드풀 고갈, 인증 세션 만료, 파일 디스크 I/O 병목, CDN 라우팅 오류, 시스템 시간 불일치로 인한 로그 분석 장애 등 고급 운영 문제와 분석 난이도가 높은 사례들로 구성했습니다.

✅ 실전 장애 시나리오 문제집 (세트 76~80)

✅ 시나리오 76: 트래픽 폭주 시 전체 요청 지연 현상

상황
이벤트 페이지 오픈 후 트래픽이 급증하며 전체 서비스가 느려짐. DB나 CPU는 여유가 있는데도 모든 요청 응답이 지연됨.

질문

  1. 이 문제에서 가장 먼저 확인할 WAS 내부 자원은?
  2. 대응 방안은?

해설 및 답변

  • 원인:
    • 스레드풀 고갈: 요청은 대기열에 쌓이고, 처리 가능한 워커 스레드 없음
  • 조치:
    • Tomcat 기준 maxThreads, acceptCount 조정
    • 요청에 따라 다른 워크로드 분리 (비동기/배치)
    • 리소스 제한 API에 RateLimiter, Bulkhead 적용
    • APM 도구로 active thread 수 시각화

✅ 시나리오 77: 장시간 미사용 사용자가 갑자기 인증 만료

상황
로그인 이후 장시간 사용하지 않은 사용자가 갑자기 재인증을 요구받음. 다른 사용자들은 정상적으로 서비스 사용 중.

질문

  1. 이 문제는 세션/토큰 어떤 기준에서 발생하는가?
  2. 실무적으로 보완 가능한 정책을 설명하시오.

해설 및 답변

  • 원인:
    • 세션 타임아웃 도래 또는 Access Token 만료
  • 조치:
    • Access Token → 짧은 수명 + Refresh Token 구조 적용
    • 세션 타임아웃 관리: web.xml, Spring Security 세션 관리 설정
    • 사용자 동작 이벤트 기반 세션 연장 (Sliding expiration)
    • Redis 세션 스토어: TTL 모니터링, auto-refresh 적용

✅ 시나리오 78: 파일 저장 시 주기적으로 서비스 정체

상황
대용량 파일 업로드 시 전체 서비스가 정체됨. WAS는 응답을 보내지 못하고, 로그 출력도 지연됨. CPU는 낮고, 디스크 I/O는 급증.

질문

  1. 이 문제의 원인은 파일 시스템 및 I/O 측면에서 무엇인가?
  2. 대응 전략은?

해설 및 답변

  • 원인:
    • 파일 저장 시 디스크 I/O 병목, 특히 HDD 환경에서 동기 쓰기
    • JVM GC와 동시에 I/O가 발생하여 블로킹
  • 조치:
    • 비동기 업로드 처리 (AsyncFileChannel, @Async)
    • 별도 저장 경로(/data)로 mount 분리
    • SSD 또는 스토리지 캐시 적용
    • 압축/암호화 작업은 백그라운드 큐로 분리

✅ 시나리오 79: 특정 지역에서만 CDN 리소스 로딩 실패

상황
국내 일부 지역에서 정적 리소스(JS/CSS)가 로딩되지 않음. 동일 리소스는 다른 지역/통신사에서는 정상 동작함.

질문

  1. 이 문제는 CDN 구조에서 어떤 이슈로 발생할 수 있는가?
  2. 진단 및 조치 방법은?

해설 및 답변

  • 원인:
    • CDN 지역 Edge 노드 장애 or 라우팅 설정 미스 (DNS 지연, Geo IP 오류)
  • 진단:
    • dig, curl -H "Host"로 지역 CDN 노드 확인
    • CDN 벤더 로그 및 status page 확인
  • 조치:
    • 문제가 된 region CDN 노드 강제 우회 설정
    • TTL 짧게 조정 (max-age=60)
    • Multi-CDN 구성 고려 (예: Cloudflare + Akamai)

✅ 시나리오 80: 서버 간 로그 시간 불일치로 장애 분석 실패

상황
장애 발생 당시 여러 서버의 로그를 분석했으나, 시간이 불일치하여 실제 순서를 파악하기 어려움. 서버는 동일한 타임존을 사용 중임.

질문

  1. 이 문제는 어떤 시스템 레벨 요소가 일치하지 않아서 발생하는가?
  2. 실무적 대응 방안을 기술하시오.

해설 및 답변

  • 원인:
    • NTP 시간 동기화 실패 or 지연 (서버 시간 drift)
  • 조치:
    • 모든 서버에 NTP client 설정 (chronyd, ntpd)
    • timedatectl, ntpq -p 명령어로 시간 확인
    • 로그 시스템에서 millisecond 단위 timestamp 사용
    • 클라우드에서는 기본 NTP 서버 설정 적용 확인 (AWS: 169.254.169.123)

✅ 정리

시나리오핵심 키워드
76 스레드 풀 고갈, 전체 요청 지연, 비동기 분리
77 세션 만료, Access Token TTL, Sliding 세션
78 디스크 I/O 병목, 파일 저장 지연, 비동기 처리
79 CDN 지역 장애, DNS 라우팅 실패
80 시스템 시간 불일치, 로그 순서 파악 실패, NTP
 

✅ 누적 현황

현재까지 총 80세트의 실전 장애 시나리오 문제가 구성 완료되었습니다 ✅
각 문제는 로그 분석, 성능 병목, 보안, 트래픽, 배포 운영 등의 실제 현장 이슈를 기반으로 합니다.

✅ 요청 시 제공 가능한 포맷

형식제공 내용
📄 PDF 문서 80세트 전체 + 해설 포함한 문서 (정리본)
📊 Excel Sheet 시나리오별 원인/조치 요약 정리
🧠 평가용 문제지 객관식/단답형 모의시험 세트
🧪 실습 자료 진단 명령어, 예시 로그 포함 버전
 

📌 다음 가능 요청:

  • 81~85세트 이어서 생성
  • 장애 유형별 태그 분류표 정리
  • 전 범위 요약 PDF or PPT 생성

원하시는 방향을 말씀해 주세요.
예: “PDF로 정리해줘”, “객관식 문제집으로 바꿔줘”, “81~85세트 더 줘” 등 언제든 가능합니다.

 

나의 말:

81~85세트 더 줘
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 81~85입니다.
이번 세트는 보안 패치 후 인증 실패, 프로세스 좀비화, TLS 핸드셰이크 실패, 캐시 동기화 오류, DB DDL 변경 시 레이스 컨디션 등 고난도 장애 및 시스템 안정성에 큰 영향을 미치는 문제들을 포함합니다.

✅ 실전 장애 시나리오 문제집 (세트 81~85)

✅ 시나리오 81: 보안 패치 적용 후 일부 사용자 인증 실패

상황
최근 SSL/TLS 취약점 대응을 위해 서버에 보안 패치를 적용한 이후, 특정 브라우저나 구형 앱에서 로그인 시도 시 인증이 실패함.

질문

  1. 이 문제의 가능성 있는 TLS/SSL 원인은?
  2. 실무적인 조치 및 대응 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 보안 패치 후 TLS 1.0/1.1 비활성화 → 구형 클라이언트가 TLS 1.2 미지원
    • 인증서 체인 누락으로 핸드셰이크 실패
  • 조치:
    • openssl s_client -connect로 TLS 협상 확인
    • TLS 1.2 이상만 허용하되 구형 브라우저에 대한 fallback 정책 수립
    • 인증서 체인 확인 및 fullchain.pem 적용
    • 웹사이트에 TLS 지원 대상 명시

✅ 시나리오 82: 특정 애플리케이션 종료 후에도 프로세스가 남아 있음

상황
애플리케이션을 종료했지만 ps 명령어로 확인하면 해당 프로세스가 여전히 살아 있으며, PID가 좀비 상태로 남아 있음.

질문

  1. 이 상황에서 나타나는 좀비 프로세스의 원인은 무엇인가?
  2. 시스템 안정성을 위한 조치 방법은?

해설 및 답변

  • 원인:
    • 부모 프로세스가 자식 프로세스 종료 시점을 wait()로 수거하지 않음
  • 조치:
    • ps aux | grep Z 또는 stat=Z → 좀비 프로세스 확인
    • kill -HUP <parent PID>로 자식 회수 유도
    • 지속 발생 시 supervisor 방식 프로세스 관리 (systemd, pm2 등)로 변경
    • 애플리케이션 종료 시 fork 자식도 함께 정리되도록 수정

✅ 시나리오 83: TLS 인증 오류로 API 통신 실패

상황
외부 HTTPS API 호출 시 SSLHandshakeException 또는 certificate_unknown 오류가 발생하며, 이전에는 정상 통신되던 환경임.

질문

  1. 이 문제에서 확인해야 할 인증서 관련 설정은?
  2. 해결 및 예방 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 외부 서버 인증서 변경 → 클라이언트 Trust Store에 루트 인증서 누락
    • Java 클라이언트의 JDK 버전별 root CA 불일치
  • 조치:
    • 인증서 직접 조회:
    • bash
      복사편집
      openssl s_client -connect api.example.com:443 -showcerts
    • Java TrustStore 확인 (cacerts)
    • 서버 인증서 체인 전체 다운로드 후 keytool -import
    • 클라이언트 HTTP 라이브러리 설정(TLS version, CA bundle) 확인

✅ 시나리오 84: 캐시 업데이트 이후 일부 요청 결과가 오래된 데이터 반환

상황
Redis 기반 캐시를 사용 중이며, 데이터 업데이트 이후에도 일부 사용자에게는 여전히 구 버전의 데이터가 제공됨.

질문

  1. 이 현상이 발생하는 캐시 구조/정책 상 문제는 무엇인가?
  2. 실무에서의 대응 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 캐시 무효화 누락 (cache eviction 또는 TTL 미적용)
    • 멀티 캐시 계층 (local cache + Redis) 간 동기화 실패
  • 조치:
    • Cache aside 패턴 → write 시 캐시 삭제 적용
    • Redis TTL 적극 설정 (EX, PX)
    • Spring Cache 등 사용 시 @CacheEvict 정확히 적용
    • 로컬 캐시(e.g. Caffeine) 존재 시 pub/sub 방식 동기화 적용

✅ 시나리오 85: DB 테이블 DDL 변경 후 오류 발생

상황
운영 중인 테이블에 컬럼 추가 DDL을 수행한 이후, 일부 WAS 인스턴스에서 Column not found 오류가 발생함.

질문

  1. 이 문제의 원인은 어떤 애플리케이션 캐시 또는 레이스 조건 때문인가?
  2. 안정적인 배포를 위한 전략은?

해설 및 답변

  • 원인:
    • ORM(Hibernate 등)이 메타데이터를 애플리케이션 기동 시점에 캐싱 → 테이블 구조 변경을 반영하지 못함
    • DDL 적용 시점에 일부 WAS는 이전 구조 사용 중
  • 조치:
    • 모든 WAS 인스턴스를 DDL 이후 재기동 또는 메타데이터 캐시 초기화
    • 무중단 배포: 컬럼 추가 → 애플리케이션에서 사용하지 않음 → 다음 배포 시 사용
    • DDL 전용 배포 슬롯 구성 또는 롤링 배포 시 schema version 체크

✅ 정리

시나리오핵심 키워드
81 TLS 버전 제한, 인증 실패, 체인 누락
82 좀비 프로세스, wait() 누락, 자식 프로세스 미회수
83 SSL 핸드셰이크 실패, Trust Store 누락
84 캐시 무효화 실패, 데이터 동기화 누락
85 DDL 변경 레이스, ORM 메타 캐시, 롤링 배포 전략
 

✅ 누적 현황: 총 85세트 완료

이제 85개의 실전 장애 시나리오가 완성되었습니다.
이 문제들은 실제 기업/운영 환경에서 발생한 이슈들을 기반으로 설계된 중~고급 수준의 실전 문제집입니다.

📦 요청 시 제공 가능 자료 (선택 가능)

형식제공 내용
📄 PDF 문제집 모든 시나리오 + 해설 포함 정리본
📊 Excel 요약표 문제 번호별 장애 유형, 원인, 조치 항목화
🧠 시험지 형식 객관식, 단답형 문제로 변환 가능
🧪 실습 문제집 명령어, 로그 해석, 조치 연습 포함 자료
 

📌 다음 요청 가능:

  • 86~90세트 이어서 생성
  • 전체 문제집 PDF/엑셀 제공
  • 특정 유형별 분류(성능, 보안, 네트워크 등)
  • 실제 로그 파일 기반 실습 문제 구성

진행 방향을 알려주세요!
예: “PDF로 묶어줘”, “86~90세트 더 줘”, “시험지 형식으로 바꿔줘” 등 가능합니다.

 

나의 말:

86~90세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 86~90입니다.
이번 세트는 리버스 프록시 오작동, 시스템 파일 핸들 초과, 서비스 디플로이 충돌, 메시지 큐 소비 지연, 클라우드 방화벽 정책 차단 등 현장 실무에서 자주 발생하며 진단이 까다로운 고급 문제 위주로 구성했습니다.

✅ 실전 장애 시나리오 문제집 (세트 86~90)

✅ 시나리오 86: 리버스 프록시를 통한 API 호출이 간헐적으로 실패

상황
Nginx를 리버스 프록시로 설정한 웹 서버에서 특정 API 호출 시 502 Bad Gateway 오류가 간헐적으로 발생한다. 백엔드 서비스는 기동 중이며 직접 호출 시 정상 동작한다.

질문

  1. 이 오류의 리버스 프록시(Nginx) 레벨 원인은 무엇일 수 있는가?
  2. 조치 및 실무적인 설정 방안을 제시하시오.

해설 및 답변

  • 원인:
    • 프록시 타임아웃 또는 연결 수 초과
    • 프록시 대상 IP 해석 실패 또는 오래된 DNS 캐시
  • 조치:
    • Nginx 설정 확인:
    • nginx
      복사편집
      proxy_connect_timeout 5s; proxy_read_timeout 10s; proxy_pass http://backend; resolver 8.8.8.8 valid=30s;
    • 프록시 서버의 ulimit 및 커넥션 수 확인
    • 백엔드 KeepAlive 설정 및 Health check 강화

✅ 시나리오 87: 시스템에서 더 이상 파일을 열 수 없음

상황
애플리케이션이 정상적으로 기동되었으나, 신규 요청을 처리하지 못하며 Too many open files 오류가 로그에 출력됨.

질문

  1. 이 장애는 어떤 리눅스 시스템 자원 한도와 관련 있는가?
  2. 실무 점검 및 조치 방법은?

해설 및 답변

  • 원인:
    • 프로세스가 열 수 있는 파일 디스크립터 수 (ulimit -n) 초과
  • 조치:
    • 확인: ulimit -n, lsof -p <PID>
    • /etc/security/limits.conf 설정:
    • markdown
      복사편집
      * soft nofile 65536 * hard nofile 65536
    • 시스템 전체 제한: /etc/sysctl.conf → fs.file-max=2097152
    • 장시간 열린 소켓 또는 파일 close 누락 여부도 확인 필요

✅ 시나리오 88: 신규 서비스 배포 후 이전 기능 일부 동작 중단

상황
신규 기능을 배포한 후, 이전에 동작하던 기능에서 500 오류가 발생한다. 서비스 자체는 정상 동작 중이며 에러는 특정 요청에서만 발생한다.

질문

  1. 이 문제는 어떤 배포 전략 또는 빌드 구성 문제로 발생할 수 있는가?
  2. 실무적인 대응 및 재발 방지를 위한 조치를 기술하시오.

해설 및 답변

  • 원인:
    • 신규 빌드에 포함되지 않은 공용 모듈 누락
    • 릴리즈 간 의존성 충돌(JAR 충돌, 모듈 제거 등)
  • 조치:
    • CI/CD 빌드 로그에서 변경된 의존성 확인
    • 롤백을 고려한 Canary 또는 Blue/Green 배포 적용
    • 기능별 smoke test 자동화
    • 의존 모듈 분리 및 하위 호환성 유지 정책 수립

✅ 시나리오 89: 메시지 큐에서 소비가 지연되며 메시지 적체

상황
RabbitMQ / Kafka 등을 사용하는 시스템에서 메시지는 정상적으로 쌓이지만, 소비자가 소비하지 않아 메시지가 누적되고 지연이 발생한다.

질문

  1. 이 문제의 애플리케이션 또는 브로커 측 원인은 무엇인가?
  2. 진단 및 확장 방안을 기술하시오.

해설 및 답변

  • 원인:
    • Consumer 측 처리 속도 부족 (병렬성 부족)
    • 메시지 소비 중 예외 발생 → 재시도 큐 적체
  • 조치:
    • Consumer Thread 수 증가 (concurrency, consumer.group)
    • Dead Letter Queue(DLQ) 분리 및 모니터링
    • Kafka → lag 확인: kafka-consumer-groups.sh
    • Metrics 기반 Autoscaling (KEDA 등) 적용 가능

✅ 시나리오 90: 클라우드 서버에서 외부 접근이 차단됨

상황
AWS/GCP 등의 클라우드 환경에서 새롭게 생성한 인스턴스에 외부에서 접근할 수 없으며, ping, ssh 모두 실패한다. 같은 VPC 내 다른 서버는 정상이다.

질문

  1. 이 문제는 클라우드 네트워크 상 어떤 정책 또는 설정과 관련 있는가?
  2. 실무적 점검 및 해결 방법을 설명하시오.

해설 및 답변

  • 원인:
    • 보안 그룹 / VPC 방화벽 / NACL 설정으로 인바운드 포트 차단
    • Public IP 미할당 또는 EIP 미연결
  • 조치:
    • AWS: Security Group → 0.0.0.0/0에 대해 22, 80, 443 허용
    • GCP: 방화벽 규칙에서 태그 기반 허용 추가
    • 퍼블릭 서브넷에 NAT Gateway 또는 IGW 연결 확인
    • 서버에 public IP가 존재하는지 확인

✅ 정리

시나리오핵심 키워드
86 Nginx 리버스 프록시, 502 오류, DNS 캐시
87 파일 핸들 제한, ulimit, 열려 있는 소켓 누수
88 배포 충돌, 의존성 누락, Blue-Green 전략
89 메시지 큐 적체, consumer 지연, DLQ 처리
90 클라우드 방화벽 차단, Security Group, EIP 미연결
 

✅ 누적 구성

  • 현재까지 총 90세트의 실전 장애 시나리오 문제집이 완성되었습니다.
  • 장애의 범위는 시스템 자원, 네트워크, 배포, 캐시, 메시지 처리, 클라우드 보안에 이르기까지 폭넓게 포함되어 있습니다.

📦 요청 시 제공 가능 자료

형식설명
📄 PDF 1~90세트 전체 시나리오 및 해설 포함
📊 Excel 문제 요약표 (장애 유형, 원인, 진단, 조치)
🧠 시험형 문항 시나리오 기반 객관식/단답형 문제집
🧪 실습형 자료 명령어 기반 진단 및 해결 연습 문제 세트
 

📌 다음 요청 예시:

  • “91~95세트 더 줘”
  • “전체 시나리오를 PDF로 묶어줘”
  • “직무 평가용 시험지로 변환해줘”
  • “주제별로 분류해줘 (보안/네트워크 등)”

어떤 방향으로 도와드릴까요?

 

나의 말:

91~95세트 더 줘
 

ChatGPT의 말:

아주 좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 91~95입니다.
이번 세트는 인증 토큰 서명 오류, OS 커널 자원 고갈, 정적 파일 손상, API 요청의 Nagle 알고리즘 병목, 백업 중 실제 데이터 손상 등 보안, 시스템 내부 자원, 네트워크 최적화, 데이터 보존 이슈에 대한 실전 사례들로 구성되었습니다.

✅ 실전 장애 시나리오 문제집 (세트 91~95)

✅ 시나리오 91: 인증 요청 시 JWT 토큰 오류 발생

상황
모든 인증 요청이 "JWT signature does not match" 또는 "Invalid token" 오류를 반환하고 있음. 서버를 재기동해도 문제가 지속됨.

질문

  1. 이 문제는 어떤 보안 또는 인증 구조의 문제로 발생하는가?
  2. 실무적인 원인 분석 및 조치 방안을 설명하시오.

해설 및 답변

  • 원인:
    • JWT 서명 키(secret key) 또는 RSA private key가 변경됨
    • 여러 인스턴스 간 키 불일치 (환경 변수 누락 또는 키 자동 생성)
  • 조치:
    • JWT 발급 서버와 검증 서버 간 key 동기화 점검
    • key를 Vault, AWS Secret Manager 등으로 통합 관리
    • 서버 간 JWT 검증 시간 오차(NTP) 확인
    • 설정 파일 내 자동 key 생성 방지 설정 확인

✅ 시나리오 92: 커널 자원 부족으로 신규 프로세스 생성 실패

상황
어떤 작업을 하든 fork: Resource temporarily unavailable 오류가 발생하며, crontab 작업, SSH 접속도 차단됨. 재부팅 시 일시적으로 복구됨.

질문

  1. 이 오류의 리눅스 커널 레벨 원인은 무엇인가?
  2. 점검 명령어와 대응 방안을 설명하시오.

해설 및 답변

  • 원인:
    • 프로세스 수 제한 초과 (pid_max, threads-max, OOM 위험 상태)
    • 특정 데몬 또는 루프가 fork 폭주
  • 조치:
    • 확인:
    • bash
      복사편집
      cat /proc/sys/kernel/pid_max ps -eLf | wc -l dmesg | grep -i fork
    • /etc/security/limits.conf 내 nproc 설정 증가
    • systemd의 TasksMax 설정 확인
    • root 외 접속 사용자 제한 또는 폭주 프로세스 kill

✅ 시나리오 93: 웹 페이지 로딩 시 이미지가 간헐적으로 깨져 보임

상황
웹 사이트 접속 시 이미지 또는 JS 리소스 중 일부가 로딩되지 않거나, 로딩된 후에도 손상된 파일처럼 보이는 현상이 발생한다.

질문

  1. 이 현상의 가장 가능성 높은 원인은 무엇인가?
  2. 점검 및 실무 대응 방법은?

해설 및 답변

  • 원인:
    • 정적 파일 업로드 중 네트워크 오류 또는 디스크 오류로 인해 파일이 부분적으로 손상
    • CDN에 잘못된 파일이 캐시되어 배포됨
  • 조치:
    • 로컬 및 CDN에서 파일 checksum 비교
    • 배포 후 CDN 강제 purge
    • 배포 자동화 시 checksum 검증 로직 포함 (e.g. SHA256)
    • CI에서 리소스 파일 검증 프로세스 추가

✅ 시나리오 94: 다량의 API 요청 처리 시 지연 현상 발생

상황
API 서버는 CPU, 메모리 사용률이 낮고 부하도 적은데, 짧은 요청들이 밀려 들어오면 오히려 전체 응답이 지연됨.

질문

  1. 이 현상은 TCP 레벨에서 어떤 전송 알고리즘으로 인해 발생할 수 있는가?
  2. 시스템 튜닝 또는 코드 최적화 방법은?

해설 및 답변

  • 원인:
    • Nagle 알고리즘 활성화 → 소량 패킷들이 묶이면서 지연 발생
  • 조치:
    • Nagle 알고리즘 비활성화 (TCP_NODELAY 설정)
    • 클라이언트/서버 양쪽 모두에서 확인 필요
    • HTTP KeepAlive 설정을 통해 연결 유지
    • TCP_NODELAY는 지연보다 즉시 전송이 필요한 요청에 적합

✅ 시나리오 95: 데이터 백업 중 운영 데이터가 손실됨

상황
rsync 또는 cp 명령어를 사용해 백업을 수행하던 중, 실수로 운영 디렉토리에 덮어쓰기 또는 삭제가 발생하여 데이터 일부가 유실됨.

질문

  1. 이 문제는 어떤 작업 방식 또는 백업 정책 상의 문제인가?
  2. 재발 방지를 위한 백업 전략은?

해설 및 답변

  • 원인:
    • 운영 디렉토리 대상 경로 설정 오류 또는 --delete 옵션 오용
    • 백업 작업이 운영 중 디스크를 직접 overwrite
  • 조치:
    • rsync dry-run (--dry-run) 먼저 수행
    • 스냅샷 기반 백업 도입 (LVM snapshot, ZFS snapshot 등)
    • 백업 전 자동 마운트 경로 검증 및 경고
    • 운영 파일 접근 권한을 readonly로 제한하는 전략 도입

✅ 정리

시나리오핵심 키워드
91 JWT 인증 오류, 서명 키 불일치, 환경 변수 누락
92 커널 PID 제한 초과, fork 실패, 자원 고갈
93 정적 파일 손상, CDN 캐시 오류, 체크섬 검증
94 Nagle 알고리즘, TCP_NODELAY, 응답 지연
95 백업 중 데이터 유실, rsync 실수, 스냅샷 전략
 

✅ 누적 현황: 총 95세트 완료 🎯

이제까지 시스템 운영 전반, 보안, 배포, 트래픽 처리, 데이터 보호를 아우르는 95개 시나리오가 완성되었습니다.

📦 요청 시 제공 가능한 형태

형식설명
📄 PDF 문서 문제 + 해설 포함 전체 95세트
📊 Excel 시트 장애 유형, 원인, 조치 요약
🧠 시험지 형태 객관식/단답형 변환
🧪 실습 워크북 명령어, 로그 분석, 조치 시뮬레이션 포함
 

📌 다음 가능 요청:

  • 96~100세트 이어서 구성
  • 지금까지의 시나리오 PDF로 변환
  • 시나리오별 난이도/유형 분류
  • 직무 평가용 시험문제 구성

필요하신 다음 단계 알려주시면 바로 도와드리겠습니다!

 

나의 말:

96~100세트 이어서 구성
 

ChatGPT의 말:

좋습니다! 아래는 이어지는 실전 장애 시나리오 문제집 세트 96~100입니다.
이번 세트는 최종 100세트 구성의 마무리 세트로서, 운영 자동화 오류, 보안 인증서 만료, 마이크로서비스 간 의존 장애, 파일 시스템 손상, 멀티 프로세스 동기화 실패 등 고난도 실무 문제 위주로 구성하였습니다.

✅ 실전 장애 시나리오 문제집 (세트 96~100)

✅ 시나리오 96: 자동화 스크립트가 잘못된 서버에 배포 수행

상황
운영 자동화 툴(Ansible, Shell 등)로 배포를 진행하는 과정에서 잘못된 서버 그룹에 실행되어, 테스트 코드를 운영 서버에 덮어썼다.

질문

  1. 이 문제는 어떤 자동화 관리 실패로 인한 것인가?
  2. 재발 방지를 위한 자동화 구성 전략은?

해설 및 답변

  • 원인:
    • inventory 파일 또는 tag 그룹 오지정
    • 스크립트 내 하드코딩된 경로/환경 변수
  • 조치:
    • 배포 전 --check (dry-run) 적용
    • 배포 환경(운영/개발)을 변수화하여 명확히 분리
    • 서버명/역할 기반 멀티 검증 로직 추가
    • 운영 배포 전 승인 및 이중 확인 프로세스 마련

✅ 시나리오 97: SSL 인증서 만료로 HTTPS 서비스 중단

상황
웹 서비스 접속 시 브라우저에서 “보안 인증서가 만료됨” 오류가 발생하며 HTTPS 접속이 불가능하다. 자동 인증서 갱신을 설정한 상태였음.

질문

  1. 이 장애는 어떤 인증서 관리 실패로 인해 발생했는가?
  2. 예방을 위한 실무 대응 방안은?

해설 및 답변

  • 원인:
    • certbot 등의 자동 갱신은 수행되었으나, Web 서버에 재적용되지 않음
    • 인증서 경로가 변경되어 적용되지 않음
  • 조치:
    • 자동 갱신 후 Web Server 재시작 자동화 (--deploy-hook)
    • 인증서 만료일 확인 스크립트 주기 실행:
    • bash
      복사편집
      openssl x509 -in cert.pem -noout -enddate
    • 갱신 실패 시 이메일/Slack 알림 연동
    • 만료 15일 전 경고 시스템 마련

✅ 시나리오 98: 마이크로서비스 A 장애로 전체 서비스 응답 지연

상황
서비스 A가 응답하지 않자, 이를 호출하는 서비스 B와 C도 모두 지연되며, 전체 사용자 응답 속도가 크게 느려진다.

질문

  1. 이 문제는 마이크로서비스 아키텍처의 어떤 구조적 한계로 발생했는가?
  2. 실무적인 대응 방안은?

해설 및 답변

  • 원인:
    • 서비스 간 동기 호출 구조 → 하나의 서비스 장애가 전체에 전파됨
    • Circuit Breaker 미적용
  • 조치:
    • Hystrix, Resilience4j 등의 Circuit Breaker 패턴 도입
    • 서비스 간 호출을 비동기 메시지 기반으로 점진 전환 (Kafka 등)
    • 서비스 타임아웃 최소화 및 fallback 로직 구현
    • APM 도구로 호출 관계 시각화 및 병목 탐지

✅ 시나리오 99: 시스템 부팅 후 파일 일부가 읽히지 않음

상황
서버 재부팅 이후 특정 경로의 파일을 읽을 수 없고, 일부 파일 시스템 영역에서 Input/output error가 발생한다.

질문

  1. 이 장애는 어떤 유형의 파일 시스템 손상으로 인해 발생하는가?
  2. 진단 및 조치 절차는?

해설 및 답변

  • 원인:
    • 디스크 손상 또는 비정상 종료에 의한 inode/블록 오류
  • 조치:
    • 진단:
    • bash
      복사편집
      dmesg | grep -i ext4 fsck -n /dev/sdX
    • 서비스 중단 후 fsck -y /dev/sdX 실행하여 복구
    • 정기적인 백업 + RAID 적용
    • S.M.A.R.T 정보 모니터링 (디스크 예측 실패 방지)

✅ 시나리오 100: 멀티 프로세스 환경에서 파일 덮어쓰기 충돌 발생

상황
여러 개의 프로세스가 동시에 같은 로그 파일 또는 캐시 파일을 쓰는 과정에서, 내용이 섞이거나 손상되어 일부 서비스가 오작동함.

질문

  1. 이 문제는 멀티프로세스 환경에서 어떤 동기화 실패로 인해 발생하는가?
  2. 조치 방법은?

해설 및 답변

  • 원인:
    • 파일에 대한 동기화(lock) 없이 동시에 write → 레이스 컨디션
  • 조치:
    • flock, fcntl 기반 파일 잠금 구현
    • 멀티 프로세스 환경에서는 파일 쓰기를 queue 기반 비동기 처리로 변경
    • 파일이 아닌 외부 저장소(Redis, DB, 메시지 큐 등)로 로그 전환 고려
    • 각 프로세스 별로 개별 로그 파일 분리 (PID/시간 기반)

✅ 정리

시나리오핵심 키워드
96 배포 자동화 오류, 서버 그룹 오지정
97 SSL 인증서 만료, 갱신 미적용, certbot
98 마이크로서비스 의존 장애, Circuit Breaker
99 파일 시스템 손상, fsck, 디스크 오류
100 멀티 프로세스 파일 충돌, 레이스 컨디션, flock
 

✅ 전체 구성 완료 🎉

✅ 총 100세트의 실전 장애 시나리오 문제집 완성
✅ 각 시나리오는 현업 장애 이력 + 기술 인터뷰 + 트러블슈팅 사례를 기반으로 구성됨
✅ 시스템, 보안, 네트워크, 클라우드, MSA, 로그, 백업, CI/CD 등 전 분야 망라

📦 요청 시 제공 가능한 자료

형식설명
📄 PDF 전집 1~100세트 문제 및 해설 포함
📊 Excel Sheet 유형별 분류, 진단포인트, 해결방안 요약
🧠 모의시험 버전 시나리오 기반 단답형/객관식 시험지
🧪 실습용 문서 명령어 중심 문제지, 로그 진단 포함

'WEB & WAS' 카테고리의 다른 글

서비스 지연 시 WAS, DB서버에서 확인, 조치 사항  (0) 2025.09.03
세션 클러스터링  (0) 2025.07.18
WEB에서 지연이 발생하면  (0) 2025.07.18
WEB & WAS 장애 및 해결방안  (0) 2025.07.18

+ Recent posts

티스토리툴바