Open to work fixie2014@naver.com

[hyunsu@srv ~]$ whoami

원인을 찾아, 근거로 좁히고, 절차로 남기는 시스템 엔지니어

  • #주도성
  • #분석력
  • #구조화

조현수입니다.

오류의 원인을 직접 찾아 해결하는 데 흥미를 느껴 IT 인프라를 배웠습니다.
개인 프로젝트에서는 가상 서버 3대를 구축해 10종의 무작위 장애를 추적했고,
교육과정 중 진행한 팀 프로젝트에서는 AWS 서버 배포 절차를 직접 정리했습니다.
원인을 좁혀 해결하는 과정이 제 성향과 잘 맞아 시스템 엔지니어를 목표로 하고 있습니다.

scroll

SYSTEM ENGINEER

  1. 2026.10

    Linux 서버 운영 환경 구축개인 프로젝트 · RHEL 10 가상 서버 3대프로젝트 보기
  2. 2026.09

    RHCSA 취득Red Hat Certified System Administrator
  3. 2026.03 – 2026.08

    AWS와 Azure 기반 하이브리드 멀티클라우드 DevOps 과정

    솔데스크 · 수료

    • 인프라 기초: 네트워크 · Windows Server · Linux 서버 · 데이터베이스
    • 클라우드: AWS · Azure 운영, Python Lambda 기반 배포
    • 자동화 · 컨테이너: Ansible · Terraform · Kubernetes
  4. 2026.07

    리눅스마스터 2급한국정보통신진흥협회
  5. 2026.06

    AWS 기반 글로벌 저지연 스트리밍 서비스4인 팀 프로젝트 · 서버 내부 구축 담당프로젝트 보기
  6. 2026.04

    네트워크관리사 2급한국정보통신자격협회
  7. 2026.01

    JLPT N2일본어
  8. 2023.02

    한국교통대학교 경영학전공 졸업

MY SKILLS

LINUX
RHCSA2026.09 취득리눅스
마스터 2급
2026.07 취득
NETWORK
네트워크
관리사 2급
2026.04 취득
LANGUAGE
JLPT N22026.01 · 일본어 자격증 취득

PROJECTS

04 / 개인 프로젝트

사내 서버 운영을 가정한 Linux 인프라 구축 · 장애 대응개인

개인 프로젝트 · 2026.10.07 – 2026.10.15 · VMware 기반 RHEL 10 가상 서버 3대

목표

서버 구축부터 모니터링, 자동화, 장애 대응까지 운영 흐름 전 과정 수행

기술
서버RHEL 10 · VMware · LVM · nginx
네트워크BIND (내부 DNS) · firewalld
스토리지NFS
보안SELinux · SSH Key · HTTPS (자체 서명 인증서)
모니터링Prometheus · node_exporter · Alertmanager · Discord
자동화Ansible · Git
결과

역할(Web · Infra · Mon)과 네트워크(NAT · 내부망)를 분리한 가상 서버 3대 구축
Prometheus · Alertmanager로 7가지 장애 알림을 Discord에 연동
Ansible · Git으로 nginx 설정을 코드화하고 멱등성을 활용한 설정 복구 검증
10종 무작위 장애를 주입해 증상 감지 → 원인 추적 → 조치 순서로 대응

회고

Prometheus 다운로드, Ansible galaxy, 보안 업데이트 실패를 각각 재시도로 넘겨 같은 원인(DNS의 IPv6 질의)이 세 번 반복됨
→ 비슷한 장애가 반복되면 공통 원인부터 확인하고, 간헐적 오류는 재현율로 확인해야 함

구축과 운영 (1~4단계)
  1. 서버 구축 — 인터넷용(NAT)과 서버 간 통신용(내부망) 네트워크 카드를 분리, 로그 전용 디스크(LVM)로 로그가 가득 차도 OS 디스크 영향 방지, SELinux는 끄지 않고 라벨 지정 → 403 오류 방지
  2. 내부 DNS와 NFS 공유 — web은 infra만 DNS로 사용하도록 변경, web의 root가 만든 파일은 infra에서 nobody 소유로 저장되는 것 확인(root_squash), 종료는 web → infra · 시작은 infra → web (infra를 먼저 끄면 web 종료 지연)
  3. 백업과 복구 테스트 — 백업 위치를 infra(NFS)로 두어 web이 고장 나도 백업 보존, 백업(tar)이 실패하면 스크립트가 바로 멈추도록 set -e 사용(새 백업이 없는데 오래된 백업까지 지우는 일 방지), index.html 삭제(복구 시험) → 403, 백업에서 복구 → 200
  4. 보안 업데이트와 HTTPS — 보안 공지 129건 적용, 재부팅은 mon → web → infra 순서, 자체 서명 인증서로 HTTPS 적용, http로 접속하면 https로 이동(301)
모니터링 알림 규칙 7개 (5단계)
node_exporter · web, infra, mon→Prometheus · mon→Alertmanager · mon→Discord
알림 규칙조건
InstanceDown서버 또는 node_exporter 응답 없음
DiskUsageHigh디스크 사용률 80% 초과
ServiceDownnginx, named 등 필요한 서비스 중지
NFSMountProblemweb의 NFS 마운트 이상
BackupStale3시간 넘게 백업 성공 기록 없음
BackupMetricMissing백업 기록 없음
CertExpiringSoon인증서 만료 30일 이내

알림 시험 — 서비스 중지, 백업 실패, 백업 오래됨, 알림 전달 4건 모두 알림 발생 확인

시험 중 발견한 문제 — web은 NFS 서버(nfs-server)를 쓰지 않는데 ServiceDown 알림 발생. 규칙이 모든 서버에서 같은 서비스를 감시한 것이 원인 → 서버마다 감시할 서비스를 나눠 규칙 재작성

Ansible · git 설정 관리 (6단계)
  1. 플레이북 실행 — changed=0. 플레이북과 web의 실제 상태가 일치
  2. web 설정 2곳 임의 변경 — https 방화벽 제거, http → https 자동 이동 설정 해제
  3. 미리보기 (--check --diff) — 바꾼 2곳만 변경 예정으로 표시
  4. 플레이북 적용 — 2곳만 원래대로 복구
  5. 한 번 더 실행 — changed=0. 추가 변경 없음
  6. 접속 확인 — https 200, http 301. 원래 상태와 동일

Ansible 전용 계정 — SSH 키로만 접속, mon에서 오는 접속만 허용, Windows 접속 거부 확인

git 변경 이력 — 변경 순서: 수정 → git diff → 미리보기 → 적용 → 커밋. 사이트에 섞인 내부 파일 2개 발견(README.txt 등), 배포 원본에서 빼도 서버 파일은 남음 → 플레이북에 "없어야 함"(state: absent) 추가, 조치 전 200 → 조치 후 404

무작위 장애 대응 9회 · 10종 (7단계)
장애 주입→감지→원인 확정→복구→보고서 작성→정답 대조
회차장애원인 서버감지 방법
1nginx 중지web알림(ServiceDown)
2index.html SELinux 라벨 user_home_t → 403web사이트 접속(알림 없음)
3node_exporter 중지 → 알림 3개 연쇄web알림(InstanceDown 외)
4DNS에 등록된 web 주소 변경 (.10 → .99)infra정상 확인표 대조(알림 없음)
5인증서 이동 → nginx 시작 실패web알림(ServiceDown)
6crond 중지web알림(ServiceDown)
7named 중지infra알림(ServiceDown)
8nfs-server 중지 + 방화벽 런타임 nfs 제거infra알림(ServiceDown, NFSMountProblem)
9로그 디스크 100%(fill.tmp)web알림(DiskUsageHigh)
트러블슈팅 3건

서버 구성도

Linux 서버 구성도: Windows VMware 호스트(192.168.100.1)와 내부망 VMnet2(192.168.100.0/24)에 web(192.168.100.10), infra(192.168.100.20), mon(192.168.100.30) 연결. web은 infra의 DNS 조회와 NFS 마운트를 사용하고, mon이 web과 infra를 감시하고 Ansible로 관리

접근 제한

  • SSH — SSH 키 접속만 허용, root 접속 차단
  • 9100 (node_exporter) — mon에서만 접속 허용
  • 9090, 9093 (모니터링 화면) — Windows에서만 접속 허용
  • ansible 계정 — mon에서 오는 접속만 허용
  • NFS — web에만 공유

진행 단계

  • 0 · 10/07준비 — 계획 수립 및 준비
  • 1 · 10/08구축 — VM과 네트워크, SSH 키 접속, LVM 로그 디스크, nginx
  • 2 · 10/08내부 서비스 — DNS, NFS 공유, 재부팅 확인, 백업과 복구
  • 3 · 10/08장애 연습 — 모의 장애 3종 원인 추적
  • 4 · 10/10보안 — mon 추가, 보안 업데이트, HTTPS
  • 5 · 10/11모니터링 — Prometheus, Alertmanager, Discord 알림
  • 6 · 10/11자동화 — Ansible, git
  • 7 · 10/12–13무작위 장애 — 10종 원인 확인과 조치
  • 8 · 10/14–15정리 — 문서 정리

알림이 놓친 장애 3가지와 개선 방향

웹 응답 4032회차

알림이 없던 이유nginx는 켜져 있어 서비스 알림이 뜨지 않음

사이트 접속 시 발견

DNS가 틀린 답4회차

알림이 없던 이유DNS 서버는 정상 동작, 답이 맞는지 확인하는 감시 없음

정상 확인표 대조로 발견

방화벽 런타임 규칙 누락8회차

알림이 없던 이유6회차에 주입됐으나 이미 맺어진 NFS 연결은 유지되어 증상 없음

8회차 NFS 서버 재시작 후 새 연결이 막히며 드러남

공통점 — 세 경우 모두 서비스는 정상이라 서비스 상태 알림으로는 감지 불가개선 방향 (검토)
  • 이름으로 새 연결을 맺어 응답을 확인하는 감시 (blackbox_exporter 등)
  • 런타임 방화벽 규칙과 영구 규칙을 비교하는 점검

05 / 4인 팀 프로젝트

AWS 기반 글로벌 저지연 스트리밍 서비스팀

인프라 구축과 애플리케이션 배포 검증 · 솔데스크 수행과제 · 2026.05 – 2026.06 · 서울 + 상파울루

목표

AWS 기반 글로벌 저지연 스트리밍 서비스 구현

기술
네트워크 · 접속Route 53 · Global Accelerator · CloudFront · ACM · VPC · Subnet · IGW · NAT Gateway · VPC Peering · Security Group · OpenVPN
컴퓨팅EC2 · Launch Template · Auto Scaling · ALB · Target Group
DB · 스토리지RDS for MySQL (Multi-AZ) · S3
보안 · 운영IAM · WAF · SSM Parameter Store · CloudWatch
배포 자동화CloudFormation StackSets
서버 · 앱Amazon Linux 2023 · nginx · PM2 · Node.js (Express) · React · MySQL
결과

직접 정리한 배포 절차가 팀 Launch Template UserData 자동화의 기반이 됨

회고

앱을 개발하며 검증할 때마다 배포 절차를 수동으로 반복함
→ Ansible 플레이북으로 묶었다면 절차가 간단해지고, 검증 횟수를 더 늘릴 수 있었음

서버 내부 구축 절차 (본인)
  1. 런타임 설치 — dnf로 nginx · git 등 설치, NodeSource 저장소로 Node.js 20.x 설치, PM2 전역 설치
  2. 소스 배치 — 최신 소스를 내려받아 /opt/whatpl에 배치
  3. 환경 변수 — RDS 접속 정보 · S3 · 인증 키를 .env로 구성, chmod 600으로 소유자만 접근
  4. 빌드 · 기동 — npm ci --omit=dev, pm2 start, pm2 startup · save로 재부팅 시 자동 실행
  5. 웹 서버 — nginx에서 /api/는 백엔드(5000)로, /health는 상태 검사용으로 연결, systemctl enable · restart 후 응답 확인
트러블슈팅 3건

AWS 구성도

AWS 기반 글로벌 저지연 스트리밍 서비스 구성도: Route 53과 Global Accelerator를 거쳐 서울 · 상파울루 리전의 ALB와 Auto Scaling 웹 서버로 연결, RDS for MySQL Multi-AZ는 서울 리전에 있고 VPC Peering으로 연결, 미디어는 S3와 CloudFront로 제공

본인 담당

  • 서버 내부 구축 (런타임 · 웹 서버 · 프로세스 관리)
  • 앱 검증을 위한 AWS 환경 구성 및 배포 테스트
  • 정상 구동 검증 및 절차 정리
  • 애플리케이션 확장 및 기능 구현

EC2에 SSH로 접속해 배포 절차를 하나씩 직접 실행하며 정리하였고, 팀에서 이를 기반으로 Launch Template UserData로 자동화하였습니다.

설계안과 동일한 구성을 반복 구축하며 앱 배포와 구동을 검증하였습니다.

팀 담당

  • 전체 인프라 아키텍처 설계
  • 인프라 구축 방법 정립 및 표준화
  • CloudFormation 기반 배포 자동화
  • Global Accelerator · CloudFront · WAF · 모니터링 설계
  • 애플리케이션 초기 구조 설계 및 구현

TROUBLESHOOTING

웹 사이트 접속 시 403 오류 발생

How I fixed
  1. nginx 오류 로그와 파일 권한 확인 → 일반 권한은 정상
  2. 원인: SELinux 감사 로그(ausearch)에서 웹 파일 라벨이 user_home_t라 nginx 읽기가 거부된 것 확인
  3. restorecon으로 라벨을 httpd_sys_content_t로 복구
상세 내역 보기
  • 브라우저 403, nginx error.log에 index.html 열기 실패(13: Permission denied)
  • ls -l로 일반 권한 확인 → -rw-r--r-- root root로 정상
  • ls -Z로 라벨 확인 → user_home_t(홈 디렉터리용 라벨)
  • ausearch -m AVC → nginx(httpd_t)의 읽기 거부 기록 확인
  • restorecon -v → user_home_t에서 httpd_sys_content_t로 복구
  • 일반 권한이 맞는데 403이면 SELinux를 의심. SELinux를 끄지 않고 라벨을 되돌려 해결
# DNS 외부 조회 실패Linux 서버 운영 환경 구축 ↑

외부 다운로드가 처음에는 실패하고 다시 하면 성공함

How I fixed
  1. BIND 로그 확인 → SERVFAIL과 IPv6 주소로의 질의 실패(network unreachable) 다수
  2. 원인: IPv6 경로가 없는 서버에서 BIND가 외부 네임서버의 IPv6 주소로도 질의를 시도함
  3. /etc/sysconfig/named에 OPTIONS="-4"를 설정해 IPv4 전용으로 실행
상세 내역 보기
  • Prometheus 다운로드, Ansible galaxy, 보안 업데이트가 모두 "처음엔 실패, 재시도하면 성공"
  • 같은 이름을 NAT DNS는 정상 응답, BIND만 SERVFAIL → 인터넷 연결은 정상
  • ip -6 route 비어 있음 → IPv6 경로 없음
  • +cd로 DNSSEC 검증을 꺼도 SERVFAIL → DNSSEC 원인 배제
  • dig -4 +trace로 루트부터 끝까지 정상 → 네트워크 · 방화벽 원인 배제
  • 캐시를 비운 뒤 첫 조회 5개 중 3개 SERVFAIL로 재현 → -4 적용 후 5개 모두 성공
# Alertmanager 접속 불가Linux 서버 운영 환경 구축 ↑

Windows에서 Alertmanager(9093)만 접속되지 않음. Prometheus(9090)는 정상

How I fixed
  1. firewalld 규칙과 실제 nftables 규칙 확인
  2. 원인: 9093을 여는 rich rule이 영구 설정에 없었고, 9090은 cockpit 서비스가 출발지 제한 없이 열고 있었음
  3. 9090 · 9093을 Windows만 허용하는 영구 규칙으로 등록하고, cockpit 서비스 제거
상세 내역 보기
  • 두 서비스 모두 active, 포트도 모두 LISTEN → 서비스 문제 아님
  • Test-NetConnection: 9090 True, 9093 False → 네트워크 단계에서 9093만 막힘
  • rich rule이 비어 있는데 9090은 열림 → 이 모순을 단서로 추적
  • nft list ruleset에서 출발지 제한 없는 9090 허용 규칙 발견 → cockpit 서비스가 만든 규칙(cockpit 기본 포트 9090)
  • 영구 규칙 등록 후 출발지 없는 9090 규칙은 사라지고 Windows 전용 규칙만 남음

경로로 직접 접근하거나 새로고침하면 404 발생

How I fixed
  1. nginx 오류 로그(/var/log/nginx/error.log) 확인
  2. 원인: 화면 경로를 브라우저(React)가 처리하는 구조라, 서버에는 해당 경로의 파일이 없음
  3. 없는 경로는 index.html을 반환하도록 nginx 설정
상세 내역 보기
  • Nginx 설정 단계에서 /api/ 요청은 백엔드(5000), 나머지 요청은 프런트엔드 빌드 파일로 연결하도록 설정 파일 작성
  • 경로로 직접 접근하거나 새로고침하면 404 발생
  • 원인: 화면 경로를 브라우저(React)가 처리하는 구조라 서버에는 해당 경로의 파일이 없음
  • 없는 경로는 index.html을 반환하도록 설정 후 nginx 재시작
  • 화면 응답, /health, API 호출 결과로 서비스 상태 확인
# 패키지 설치 미완료AWS 멀티리전 서비스 구축 ↑

t3.micro에서 UserData의 패키지 설치가 완료되지 않음

How I fixed
  1. SSH 접속 후 UserData 실행 로그 확인
  2. 원인: 메모리 부족 추정
  3. 문제를 발견해 팀 회의에 공유하고 논의를 거쳐 t3.medium으로 상향
상세 내역 보기
  • Launch Template과 ASG(Auto Scaling Group)로 자동 생성된 인스턴스가 다운
  • SSH 접속 후 확인 결과, UserData에 따른 패키지 설치 미완료
  • 원인 추정: 패키지 설치 도중 t3.micro의 낮은 사양으로 인한 메모리 부족
  • 팀 회의에 공유, 논의를 거쳐 t3.medium으로 상향
  • 이후 새로 생성되는 인스턴스에서 정상 동작 확인
# S3 인증 정보 누락AWS 멀티리전 서비스 구축 ↑

배포 후 S3 업로드가 동작하지 않음

How I fixed
  1. 크롬 개발자 도구에서 업로드 요청 응답 확인
  2. 원인: 로컬 .env의 액세스 키 항목이 서버에는 없었음
  3. 액세스 키 대신 EC2 IAM 역할(인스턴스 프로파일)을 사용하도록 변경

CONTACT

끝까지 봐주셔서 감사합니다.

메일 보내기

보이지 않는 인프라로, 빛나는 서비스를
단단하게 받치는 엔지니어가 되겠습니다.