[Infra Ops] Modern Web/WAS 아키텍처와 서버 운영 SRE 핵심 직무

서비스 장애가 났을 때 "코드는 멀쩡한데 서버가 문제"라는 말이 나오는 순간, 그것을 책임지는 사람이 인프라 엔지니어입니다. 개발자가 만든 코드가 실제 트래픽을 처리하려면 OS, 네트워크, 미들웨어가 빈틈없이 받쳐줘야 하고, 그 레이어를 소유하는 사람이 바로 인프라 엔지니어입니다. 어느 레이어가 누구 책임인지 명확히 알아야 장애 상황에서 빠르게 움직일 수 있습니다.

서비스 스택을 계층으로 나누면 다음과 같습니다:

┌─────────────────────────────────┐
│  애플리케이션 (비즈니스 로직)     │ ← 개발자 담당
├─────────────────────────────────┤
│  WAS (Tomcat, JBoss, WebLogic)   │ ← 인프라 + 개발자 협업
├─────────────────────────────────┤
│  Web Server (Nginx, Apache)      │ ← 인프라 엔지니어 담당
├─────────────────────────────────┤
│  OS (Linux, Windows Server)      │ ← 인프라 엔지니어 담당
├─────────────────────────────────┤
│  서버 하드웨어 / 가상화            │ ← 인프라 엔지니어 / IDC
└─────────────────────────────────┘

인프라 엔지니어의 핵심 업무:

• OS 설치 및 초기 설정 (사용자, 네트워크, 보안)
• Web/WAS 미들웨어 설치·구성·운영
• 서버 용량 계획 및 리소스 모니터링
• 배포 스크립트 작성 및 배포 수행
• 장애 대응 및 로그 분석
• 방화벽 오픈 요청, DNS/SSL 인증서 관리

인접 역할과의 경계:

실제 현장에서는 인프라 엔지니어가 이 네 영역을 모두 겸하는 경우도 많습니다.

"개발계에서는 됐는데 운영에 올리니까 안 돼요"라는 제보를 받은 날, 원인을 찾아보니 개발계 DB와 운영계 DB의 데이터 상태가 완전히 달랐습니다. 환경이 분리돼 있다는 것은 알았지만 왜 분리해야 하는지 몰랐던 것입니다. 실제 고객 트래픽과 데이터가 흐르는 운영계에서 테스트 코드를 돌리거나 임의로 재시작을 걸면, 서비스가 멈추고 데이터가 오염됩니다. 환경 분리는 이 사고를 구조적으로 막는 방법이고, 인프라 엔지니어가 어느 환경에서 작업하는지 항상 확인해야 하는 이유입니다.

환경 구분:

운영계에서 절대 하면 안 되는 것:

• 검증되지 않은 설정 변경 직접 적용
• 테스트 목적의 임의 재시작
• 운영 DB에서 직접 UPDATE/DELETE 수행 (긴급 상황 제외, 승인 필요)
• root 비밀번호 변경 또는 계정 삭제

# 현재 접속된 서버가 어느 환경인지 확인하는 습관
hostname
# web01-prd → 운영계
# web01-stg → 통시계
# web01-dev → 개발계

# 환경변수로 환경을 구분하기도 함
echo $APP_ENV
# production / staging / development

실무 팁: 호스트명에 -prd, -stg, -dev 같은 접미사를 붙이는 것은 실수로 잘못된 환경에 작업하는 것을 방지하는 효과적인 방법입니다.

처음 서버에 들어갔을 때 어떤 프로세스가 어떤 역할인지 모르면 장애 상황에서 어디를 봐야 할지 막막합니다.

고객 민원이 들어왔는데 Nginx가 문제인지 Tomcat이 문제인지 DB가 문제인지 구분 못 하면, 복구 시간이 수십 분에서 몇 시간으로 늘어납니다. 서비스 구조도를 머릿속에 그릴 수 있어야 "어디서부터 확인할지"를 바로 판단할 수 있습니다. 대부분의 웹 서비스는 Web → WAS → DB의 3계층 구조를 가집니다.

[클라이언트 브라우저]
        │ HTTPS :443
        ▼
[L4/L7 Load Balancer] ← VIP: 10.0.0.1
        │
   ┌────┴────┐
   ▼         ▼
[Web01]   [Web02]    ← Nginx (정적 파일, SSL 종단, Reverse Proxy)
   │         │         포트: 80, 443
   └────┬────┘
        │ HTTP :8080
   ┌────┴────┐
   ▼         ▼
[WAS01]   [WAS02]    ← Tomcat (JSP/서블릿, 비즈니스 로직)
   │         │         포트: 8080, 8443
   └────┬────┘
        │ JDBC :3306
        ▼
[DB Primary]         ← MySQL/MariaDB
[DB Standby]         ← 복제(Replication), 장애 시 승격

각 구성요소의 역할:

• LB (로드밸런서): 트래픽을 여러 서버에 분산. VIP 하나로 여러 서버를 묶음
• Web Server (Nginx): 정적 파일(.html, .js, .css, 이미지) 직접 처리. 동적 요청은 WAS로 전달
• WAS (Tomcat): Java 애플리케이션 실행. DB 연결, 비즈니스 로직 처리
• DB: 영구 데이터 저장. Primary-Standby 이중화로 가용성 확보

인프라 엔지니어가 관리하는 범위: LB부터 DB까지의 모든 서버와 구성

주말 오전에 긴급 패치를 적용했는데 서비스가 전면 다운됐습니다. 알고 보니 영향도 분석을 빠뜨리고 연계 서비스를 확인하지 않았던 것입니다. 운영 환경에서 "빨리 해야 한다"는 압박에 절차를 건너뛰면, 장애 복구에 걸리는 시간이 원래 작업 시간의 열 배를 넘기기도 합니다. 변경 전 백업과 롤백 계획이 없으면 단순한 설정 오타 하나가 몇 시간짜리 장애로 이어집니다.

1. 변경 요청 접수
   └─ 개발팀 또는 내부 요청 → 지라 티켓, 이메일 등

2. 영향도 분석
   └─ 어떤 서버? 어떤 서비스? 중단 필요 여부? 롤백 가능?

3. 작업 계획서 작성
   └─ 작업 내용, 작업 시간, 담당자, 롤백 절차 명시

4. 사전 승인 (팀장/운영 담당)
   └─ 긴급 장애 대응은 사후 보고로 대체하기도 함

5. 사전 백업
   └─ 설정 파일, 데이터, 현재 버전 → cp/tar/스냅샷

6. 작업 수행
   └─ 계획서대로 순서대로, 변경 로그 기록

7. 작업 후 검증
   └─ 서비스 정상 동작 확인, 로그 오류 없음 확인

8. 결과 보고
   └─ 완료 보고, 이상 시 롤백 수행 후 원인 분석

실제로 자주 일어나는 실수:

• 사전 백업 없이 설정 파일 수정 → 원복 불가
• 영향도 분석 누락 → 연계 서비스 장애
• 개발계에서 검증하지 않고 운영에 직접 적용
• 작업 후 검증 없이 "됐겠지" → 다음날 오전에 민원

# 설정 파일 변경 전 반드시 백업하는 습관
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%Y%m%d%H%M)
# 결과: nginx.conf.bak.202501151430