서버 관리자는 무슨 일을 하는가

서버 관리자(System Administrator, SysAdmin)는 조직의 IT 인프라를 설계, 구축, 운영, 유지보수하는 역할이다. 개발자가 작성한 코드가 실제 사용자에게 전달되려면 서버가 안정적으로 동작해야 하고, 그 안정성을 책임지는 사람이 서버 관리자다. 겉으로는 드러나지 않지만 서비스의 생명선을 쥐고 있는 포지션이다.

핵심 업무 영역

서버 관리자의 업무는 크게 다섯 가지로 분류할 수 있다. 첫째, 서버 설치 및 설정(Provisioning)이다. 물리 서버라면 하드웨어 조립, OS 설치, 네트워크 설정, 기본 보안 구성을 수행하고, 클라우드라면 인스턴스 생성, VPC 설계, IAM 권한 설정을 담당한다. 둘째, 모니터링 및 장애 대응이다. CPU, 메모리, 디스크, 네트워크 지표를 상시 감시하고, 임계치를 넘으면 원인을 분석하여 조치한다. 서비스 다운은 매출 손실과 직결되므로 MTTR(Mean Time To Recovery)을 최소화하는 것이 핵심이다. 셋째, 보안 관리다. OS 패치 적용, 방화벽 규칙 관리, 침입 탐지 시스템(IDS) 운영, 접근 권한 감사(Audit)를 수행한다. 넷째, 백업 및 복구다. 정기 백업 스케줄을 운영하고, 복구 절차를 문서화하며, 주기적으로 복구 테스트를 실시한다. 다섯째, 자동화 및 최적화다. 반복되는 수작업을 스크립트와 자동화 도구로 대체하여 운영 효율을 높이고, 성능 병목을 분석하여 시스템을 튜닝한다.

필요한 기술 역량

리눅스 운영체제에 대한 깊은 이해가 기본이다. 파일 시스템 구조, 프로세스 관리, 패키지 관리, 사용자 권한 체계, 시스템 서비스(systemd) 관리를 능숙하게 다룰 수 있어야 한다. 네트워크도 핵심이다. TCP/IP 모델, 서브넷팅, 라우팅, DNS, DHCP, 방화벽 규칙, 로드밸런싱의 원리를 실무 수준으로 이해해야 한다. 셸 스크립팅(Bash)은 서버 관리자의 일상 도구다. 간단한 모니터링 스크립트부터 배포 자동화, 로그 파싱, 백업 스케줄 관리까지 대부분의 반복 업무를 셸 스크립트로 처리한다.

자동화와 IaC

현대 서버 관리의 핵심 키워드는 자동화다. 서버 수십 대를 일일이 수동 설정하는 것은 비효율적이고 오류 위험도 높다. Ansible, Terraform, Puppet 같은 IaC(Infrastructure as Code) 도구가 이 문제를 해결한다. Ansible은 에이전트 없이 SSH를 통해 여러 서버의 설정을 동시에 관리할 수 있는 구성 관리 도구다. Terraform은 클라우드 인프라를 코드로 정의하고 버전 관리할 수 있는 프로비저닝 도구다. 서버 관리자에서 DevOps 엔지니어로의 경력 전환을 고려한다면 이 도구들은 필수 역량이다.

소프트 스킬

기술만으로는 부족하다. 장애 상황에서 침착하게 원인을 분석하고 우선순위를 판단하는 문제 해결 능력, 변경 사항을 정확하게 문서화하는 습관, 개발팀·보안팀·경영진과 기술적 상황을 비전문가도 이해할 수 있게 전달하는 커뮤니케이션 능력이 장기적인 경쟁력을 결정한다.

서버관리자 #시스템어드민 #SysAdmin #DevOps #Ansible #Terraform #서버운영 #리눅스관리 #IaC #IT인프라

서버를 만들었으면 써먹어야 한다

개인 서버를 구축했지만 정작 뭘 해야 할지 모르겠다는 사람이 많다. Nginx 설치하고 Hello World 페이지 띄운 뒤 방치되는 서버가 부지기수다. 개인 서버는 쓸수록 가치가 올라간다. 직접 서비스를 올리고 운영하면서 트러블슈팅을 경험하는 것이 가장 효과적인 학습이다. 개인 서버로 실제로 활용 가능한 용도 10가지를 정리한다.

1. 개인 클라우드 스토리지

Nextcloud를 설치하면 구글 드라이브나 드롭박스와 동일한 기능을 자체 서버에서 운영할 수 있다. 파일 동기화, 공유 링크 생성, 캘린더, 연락처, 문서 편집까지 지원한다. 데이터가 자신의 서버에만 저장되므로 프라이버시를 완전히 통제할 수 있다.

2. 미디어 서버

Jellyfin이나 Plex를 설치하면 개인 넷플릭스를 구축할 수 있다. 보유한 영화, 드라마, 음악 파일을 업로드하면 자동으로 메타데이터를 매칭하고, 브라우저나 앱에서 스트리밍으로 재생할 수 있다. 외부 네트워크에서도 접속 가능하게 설정하면 어디서든 자신의 미디어 라이브러리에 접근할 수 있다.

3. Git 호스팅

Gitea나 GitLab CE를 설치하면 자체 Git 서버를 운영할 수 있다. GitHub에 올리기 꺼려지는 사적인 프로젝트, 실험 코드, 학습 기록을 자체 서버에서 관리할 수 있다. CI/CD 파이프라인까지 구성하면 개인 DevOps 환경이 완성된다.

4. 블로그 호스팅

WordPress, Ghost, Hugo 같은 블로그 플랫폼을 직접 서버에 올려 운영할 수 있다. 티스토리나 네이버 블로그와 달리 플랫폼 정책에 종속되지 않고, 디자인과 기능을 완전히 자유롭게 커스터마이징할 수 있다. 자신의 도메인을 연결하면 전문적인 기술 블로그로 활용 가능하다.

5. VPN 서버

WireGuard나 OpenVPN을 설치하면 자체 VPN 서버를 운영할 수 있다. 공용 Wi-Fi 환경에서 트래픽을 암호화하거나, 해외에서 국내 네트워크에 접속할 때 유용하다. 상용 VPN 서비스의 월 구독료를 절약할 수 있다.

6. 광고 차단 DNS

Pi-hole을 설치하면 네트워크 레벨에서 광고를 차단하는 DNS 서버가 된다. 공유기의 DNS 설정을 Pi-hole 서버 IP로 변경하면 해당 네트워크에 연결된 모든 장치에서 광고가 자동으로 차단된다. 별도 앱 설치 없이 네트워크 전체에 적용되는 것이 장점이다.

7. 홈 자동화 허브

Home Assistant를 설치하면 스마트 조명, 온습도 센서, 스마트 플러그 등 IoT 기기를 하나의 대시보드에서 통합 제어할 수 있다. 구글 홈이나 애플 홈킷과 연동도 가능하고, 자동화 규칙을 세밀하게 설정할 수 있다.

8. 개발 및 테스트 환경

Docker를 활용하면 다양한

로그는 서버의 블랙박스다

서버에서 벌어지는 모든 일은 로그에 기록된다. 누가 접속했는지, 어떤 요청이 들어왔는지, 어떤 에러가 발생했는지, 시스템 자원이 어떤 상태였는지까지 전부 로그에 남는다. 서버에 문제가 생겼을 때 원인을 추적하는 가장 기본적이면서도 확실한 수단이 로그 분석이다. 로그를 보지 않고 장애 원인을 파악하려는 것은 블랙박스 없이 사고 원인을 규명하려는 것과 같다.

리눅스 로그의 구조

리눅스 서버의 시스템 로그는 기본적으로 /var/log 디렉토리에 집중된다. syslog 또는 journald가 시스템 전반의 로그를 수집하며, 각 서비스는 자체 로그 파일을 별도로 생성한다. 핵심 로그 파일을 알아두면 장애 발생 시 어디부터 봐야 하는지 판단이 빨라진다. /var/log/syslog(또는 /var/log/messages)는 시스템 전반의 이벤트를 기록한다. /var/log/auth.log는 인증 관련 로그로 SSH 접속 시도, sudo 실행 이력이 남는다. /var/log/kern.log는 커널 메시지를 기록하며, 하드웨어 오류나 드라이버 문제를 추적할 때 참조한다.

애플리케이션 로그

시스템 로그 외에 각 애플리케이션이 생성하는 로그도 중요하다. Nginx의 접근 로그(access.log)에는 모든 HTTP 요청의 출발지 IP, 요청 경로, 상태 코드, 응답 시간이 기록된다. 에러 로그(error.log)에는 설정 오류, 업스트림 연결 실패, 타임아웃 같은 이상 상황이 남는다. MySQL의 슬로우 쿼리 로그(slow query log)는 설정한 임계값보다 실행 시간이 긴 쿼리를 기록하여 성능 병목을 찾는 데 활용된다.

로그 레벨의 이해

대부분의 로깅 프레임워크는 심각도에 따라 로그 레벨을 구분한다. 일반적으로 DEBUG, INFO, WARNING, ERROR, CRITICAL 5단계로 나뉜다. DEBUG는 개발 과정에서 상세한 흐름을 추적하기 위한 레벨이고, 프로덕션 환경에서는 보통 비활성화한다. INFO는 정상 동작 기록, WARNING은 잠재적 문제, ERROR는 기능 오류, CRITICAL은 시스템 중단 수준의 심각한 장애를 나타낸다. 프로덕션 서버에서는 INFO 이상만 기록하도록 설정하는 것이 일반적이다.

로그 로테이션

로그 파일은 관리하지 않으면 무한히 커진다. 수 GB에 달하는 단일 로그 파일은 열기도 어렵고, 디스크 용량까지 잡아먹는다. logrotate는 리눅스에서 로그 파일을 주기적으로 분할하고, 오래된 로그를 압축하거나 삭제하는 도구다. /etc/logrotate.d/ 디렉토리에 서비스별 설정 파일을 추가하면 일별, 주별, 크기 기준으로 로그를 자동 관리할 수 있다.

중앙화된 로그 관리

서버가 여러 대로 늘어나면 각 서버에 SSH로 접속해서 로그를 하나씩 확인하는 방식은 비현실적이다. ELK 스택(Elasticsearch + Logstash + Kibana)이나 Loki + Grafana 같은 중앙 집중형 로그 관리 시스템을 도입하면, 모든 서버의 로그를 한 곳에 수집하고 검색, 필터링, 시각화할 수 있다. 특정 에러 패턴이 발생하면 자동으로 알림을 보내는 설정도 가능하다. 장애 대응 시간을 획기적으로 줄여주는 인프라다.

서버로그 #로그분석 #logrotate #ELK #syslog #Nginx로그 #슬로우쿼리 #로그레벨 #장애대응 #서버모니터링

서버실과 데이터센터, 같은 말이 아니다

서버를 물리적으로 운영하려면 장비를 설치할 공간이 필요하다. 소규모 환경에서는 사무실 한쪽에 서버를 모아두는 서버실을 운영하고, 대규모 환경에서는 전문 데이터센터를 이용한다. 겉으로는 둘 다 서버가 모여 있는 공간이지만, 설계 철학과 인프라 수준에서 본질적인 차이가 있다.

서버실의 특성

서버실(Server Room)은 기업이나 기관 내부에 자체적으로 구축한 소규모 서버 보관 공간이다. 보통 사무실 건물의 한 공간을 개조하여 서버 랙, 네트워크 스위치, UPS(무정전 전원장치)를 설치한다. 규모가 작기 때문에 초기 투자 비용이 상대적으로 낮다. 하지만 전력 공급, 냉각, 물리 보안, 재해 대비 면에서 한계가 뚜렷하다. 에어컨 한 대로 냉각을 처리하는 서버실이 적지 않으며, 이중화 전력 없이 단일 회선에 의존하는 경우도 흔하다. 정전이 발생하면 UPS가 버티는 수십 분 안에 서버를 안전하게 종료해야 한다.

데이터센터의 인프라 수준

데이터센터(Data Center)는 서버 운영에 최적화된 전문 시설이다. 설계 단계부터 전력, 냉각, 네트워크, 물리 보안, 재해 복구를 종합적으로 고려한다. 전력은 한전 이중 수전에 디젤 발전기와 UPS를 다중으로 배치하여 정전 시에도 무중단 운영이 가능하다. 냉각은 정밀 공조(CRAC/CRAH) 시스템으로 온도와 습도를 상시 일정하게 유지한다. 핫 아일(Hot Aisle)과 콜드 아일(Cold Aisle) 구조로 냉기와 열기를 분리하여 냉각 효율을 극대화한다.

Tier 등급 체계

데이터센터의 신뢰성은 Uptime Institute의 Tier 등급으로 분류된다. Tier I은 기본 인프라로 가용성 99.671%를 보장한다. Tier II는 이중화된 냉각과 전력 부품을 갖추어 99.741%를 달성한다. Tier III는 동시 유지보수 가능 설계(Concurrently Maintainable)로 장비 교체 시에도 서비스 중단 없이 운영 가능하며 99.982%를 보장한다. Tier IV는 모든 인프라가 이중화된 최고 등급으로 99.995%, 연간 다운타임 약 26분 이내를 목표로 한다. 국내 주요 데이터센터는 Tier III 이상을 기준으로 설계된다.

네트워크 인프라

데이터센터는 다수의 ISP와 직접 피어링(Peering) 연결을 유지한다. 네트워크 회선이 이중화되어 있어 하나의 ISP에 장애가 발생해도 다른 경로로 트래픽이 우회된다. 내부 네트워크는 10GbE 또는 25GbE 이상의 고속 백본으로 구성되며, 대형 데이터센터는 100GbE 백본을 운영한다. 서버실은 보통 1GbE 스위치 한두 대로 내부 네트워크를 구성하는 수준이다.

물리 보안과 재해 대비

데이터센터는 생체 인증, CCTV, 출입 이력 관리, 맨트랩(Mantrap) 구조 등 다층적인 물리 보안을 갖추고 있다. 소화 설비도 물 대신 가스 소화(FM-200, Novec 1230) 방식을 사용하여 장비 피해를 최소화한다. 지진 대비 내진 설계와 침수 방지 구조도 기본이다. 서버실은 이러한 전문적 보안 및 재해 대비 인프라를 갖추기 어렵다.

코로케이션이라는 선택지

자체 서버실을 운영하기에는 인프라 구축 부담이 크고, 클라우드

점유율이 증명하는 현실

전 세계 서버 운영체제 시장에서 리눅스의 점유율은 80%를 넘는다. 퍼블릭 클라우드 인스턴스로 범위를 좁히면 90% 이상이다. AWS, GCP, Azure 모든 클라우드 제공자에서 기본 제공되는 인스턴스 이미지 대부분이 리눅스 배포판이다. 왜 이렇게까지 리눅스가 지배적인 위치를 차지하게 되었는지, 기술적 근거를 정리한다.

비용 구조

가장 직관적인 이유다. 리눅스 커널은 GPL v2 라이선스로 배포되는 오픈소스 소프트웨어이며, 대부분의 서버용 배포판(Ubuntu Server, Debian, Rocky Linux, AlmaLinux)은 무료다. Windows Server는 에디션별 라이선스 비용이 수백만 원대이며, 코어 수에 따라 추가 과금된다. 서버 수백, 수천 대를 운영하는 환경에서 이 비용 차이는 천문학적이다.

자원 효율성

리눅스는 GUI 없이 CLI 환경으로 운영하는 것이 기본이다. GUI를 제거하면 그래픽 렌더링에 소모되는 CPU, 메모리, 디스크 자원을 전부 서비스 처리에 투입할 수 있다. 최소 설치 기준으로 메모리 사용량이 수십 MB 수준이다. 윈도우 서버는 GUI를 완전히 제거한 Server Core 옵션이 있지만, 그래도 리눅스 최소 설치보다 자원 소모가 크다.

커스터마이징과 자유도

리눅스는 커널 파라미터부터 시스템 서비스, 파일 시스템, 네트워크 스택까지 모든 계층을 사용자가 직접 수정할 수 있다. 서버 워크로드에 맞게 커널을 리빌드하거나, 불필요한 모듈을 제거하거나, 스케줄러를 교체하는 것이 가능하다. 이 자유도가 성능 최적화와 보안 강화에 핵심적인 역할을 한다. 윈도우는 커널 소스가 비공개이므로 이러한 저수준 커스터마이징이 불가능하다.

소프트웨어 생태계

웹 서비스 인프라의 핵심 소프트웨어 대부분이 리눅스 우선(Linux-first)으로 개발된다. Nginx, Apache, MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch, Kafka, Docker, Kubernetes 전부 리눅스에서 네이티브로 동작하며 성능 최적화도 리눅스 기준으로 이루어진다. 컨테이너 기술 자체가 리눅스 커널의 cgroups와 namespaces에 의존하므로, Docker와 Kubernetes는 리눅스 없이는 존재할 수 없는 기술이다.

보안과 패치 속도

리눅스는 오픈소스 특성상 전 세계 개발자 커뮤니티가 코드를 감시하고 취약점을 보고한다. 취약점 발견부터 패치 배포까지의 시간이 상용 소프트웨어보다 짧은 경우가 많다. SELinux와 AppArmor 같은 강제 접근 제어(MAC) 시스템은 프로세스 단위로 세밀한 권한 제어를 가능하게 한다. 사용자 권한 분리 구조도 기본 설계부터 엄격하여 루트 권한 없이는 시스템 영역에 접근할 수 없다.

그럼에도 윈도우 서버가 필요한 경우

Active Directory, Exchange Server, MSSQL, ASP.NET 기반 레거시 시스템처럼 마이크로소프트 생태계에 종속된 인프라는 윈도우 서버가 사실상 유일한 선택이다. 다만 이 영역 자체가 축소되고 있으며, .NET Core의 크로스 플랫폼 지원 이후로는 윈도우 전용이었던 애플리케이션도 점차 리눅스에서 구동 가능해지고 있다.

리눅스 #리눅스서버 #서버OS #Ubuntu #Docker #Kubernetes #오픈소스 #서버운영 #리눅스보안 #클라우드서버

방화벽이란 무엇인가

방화벽(Firewall)은 네트워크 트래픽을 감시하고, 사전에 정의된 보안 규칙에 따라 허용 또는 차단하는 보안 시스템이다. 서버와 외부 네트워크 사이에 위치하여 비인가 접근을 차단하는 1차 방어선 역할을 한다. 서버에 어떤 서비스를 올리든, 방화벽 설정 없이 외부에 노출하는 것은 문을 열어두고 외출하는 것과 같다.

패킷 필터링 방화벽

가장 기본적인 방화벽 유형이다. 네트워크 계층(L3)과 전송 계층(L4)에서 동작하며, 각 패킷의 출발지 IP, 목적지 IP, 출발지 포트, 목적지 포트, 프로토콜(TCP/UDP/ICMP)을 검사하여 규칙에 부합하면 통과시키고 아니면 차단한다. 리눅스의 iptables와 그 후속인 nftables가 대표적인 패킷 필터링 방화벽이다. UFW(Uncomplicated Firewall)는 iptables의 프론트엔드로, 복잡한 iptables 규칙을 간단한 명령어로 관리할 수 있게 해준다.

상태 추적 방화벽

패킷 필터링 방화벽의 한계는 각 패킷을 독립적으로 판단한다는 점이다. TCP 연결은 SYN, SYN-ACK, ACK의 흐름이 있는데, 단순 패킷 필터링은 이 흐름의 맥락을 모른다. 상태 추적(Stateful Inspection) 방화벽은 연결의 상태를 기억한다. 내부에서 외부로 나간 요청의 응답 패킷은 자동으로 허용하고, 외부에서 일방적으로 들어오는 패킷은 차단하는 식이다. iptables의 conntrack 모듈이 이 기능을 제공하며, 현대 방화벽은 거의 모두 상태 추적을 기본으로 지원한다.

애플리케이션 레벨 방화벽

L3/L4 방화벽은 포트와 IP만 보지, 패킷 내부의 데이터 내용은 검사하지 않는다. 웹 애플리케이션을 대상으로 하는 SQL 인젝션, XSS(Cross-Site Scripting), CSRF 같은 공격은 HTTP 프로토콜 위에서 정상적인 포트(80, 443)를 통해 들어오므로 L3/L4 방화벽으로는 막을 수 없다. WAF(Web Application Firewall)는 HTTP 요청의 내용(URL 파라미터, 헤더, 바디)을 분석하여 악의적인 패턴을 탐지하고 차단한다. AWS WAF, Cloudflare WAF, ModSecurity가 대표적이다.

방화벽 규칙 설계 원칙

방화벽 규칙은 화이트리스트(Whitelist) 방식이 원칙이다. 기본 정책을 모든 인바운드 트래픽 차단(Default Deny)으로 설정하고, 필요한 포트만 명시적으로 허용하는 방식이다. 웹서버라면 80, 443만 열고, SSH 접속이 필요하면 22번(또는 변경된 포트)을 특정 IP 대역에서만 허용한다. 아웃바운드는 기본 허용으로 두되, 보안 수준이 높은 환경에서는 아웃바운드도 필요한 목적지만 허용하는 이그레스 필터링(Egress Filtering)을 적용한다.

클라우드 환경의 방화벽

클라우드에서는 OS 레벨 방화벽 외에 플랫폼 레벨의 방화벽이 추가로 존재한다. AWS의 Security Group은 인스턴스 단위의 상태 추적 방화벽이며, Network ACL은 서브넷 단위의 패킷 필터링 방화벽이다. 두 계층을 조합하여 다중 방어를 구성하는 것이 표준 설계다. GCP의 VPC Firewall Rules, Azure의 NSG(Network Security Group)도 동일한 역할을 한다.

방화벽 #서버보안 #iptables #UFW #WAF #SecurityGroup #패킷필터링 #네트워크보안 #클라우드보안 #방화벽설정

IP 주소의 기본 개념

IP 주소(Internet Protocol Address)는 네트워크에 연결된 모든 장치를 식별하는 고유한 논리적 주소다. 물리적 주소인 MAC 주소와 구분된다. MAC 주소는 네트워크 인터페이스 카드(NIC)에 제조 시 부여되는 하드웨어 주소이고, IP 주소는 네트워크 설정에 의해 할당되는 소프트웨어적 주소다. 인터넷 통신에서 데이터 패킷이 출발지에서 목적지까지 도달하려면 반드시 목적지의 IP 주소가 필요하다. 서버에 접속한다는 것은 결국 해당 서버의 IP 주소로 패킷을 보내는 행위다.

IPv4와 IPv6

현재 가장 널리 사용되는 IP 주소 체계는 IPv4다. 32비트 주소 공간으로 약 43억 개의 주소를 표현할 수 있다. 192.168.0.1처럼 0~255 범위의 숫자 4개를 점으로 구분하는 표기법을 사용한다. 문제는 인터넷에 연결되는 장치가 기하급수적으로 늘어나면서 43억 개로는 부족해졌다는 점이다. 이를 해결하기 위해 128비트 주소 공간을 가진 IPv6가 도입되었다. 2001:0db8:85a3::8a2e:0370:7334 같은 16진수 형태로 표기하며, 사실상 무한에 가까운 주소를 제공한다. 다만 IPv4에서 IPv6로의 전환은 아직 진행 중이며, 대부분의 서버는 듀얼 스택 방식으로 IPv4와 IPv6를 동시에 운영한다.

공인 IP와 사설 IP

IP 주소는 공인 IP(Public IP)와 사설 IP(Private IP)로 나뉜다. 공인 IP는 인터넷 상에서 유일하게 식별 가능한 주소로, ISP로부터 할당받는다. 서버가 외부 클라이언트의 요청을 받으려면 반드시 공인 IP를 가지고 있어야 한다. 사설 IP는 내부 네트워크에서만 사용되는 주소이며 외부에서 직접 접근할 수 없다. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 대역이 사설 IP 범위로 예약되어 있다. 가정이나 사무실 내부의 장치들은 사설 IP를 사용하고, 공유기가 NAT(Network Address Translation)를 통해 사설 IP와 공인 IP 간 변환을 수행한다.

고정 IP와 유동 IP

서버 운영에서 고정 IP(Static IP)는 필수에 가깝다. 고정 IP는 한 번 할당되면 변경되지 않으므로 DNS A 레코드에 등록해두면 도메인이 항상 같은 서버를 가리킨다. 유동 IP(Dynamic IP)는 DHCP 서버가 접속할 때마다 남는 IP를 할당하는 방식으로, 가정용 인터넷에서 기본 제공된다. 유동 IP로 서버를 운영하면 IP가 바뀔 때마다 DNS를 갱신해야 하는 불편이 있다. DDNS로 어느 정도 대응 가능하지만, 안정적인 서비스 운영이라면 고정 IP를 확보하는 것이 원칙이다.

서버의 IP 설정 실무

리눅스 서버에서 IP 주소를 확인하려면 ip addr 명령을 사용한다. 과거의 ifconfig는 대부분의 최신 배포판에서 기본 설치되지 않으므로 ip 명령어에 익숙해져야 한다. 고정 IP 설정은 배포판에 따라 다르다. Ubuntu는 Netplan 설정 파일(/etc/netplan/)에서 addresses, routes, nameservers를 지정한다. CentOS 계열은 nmcli 명령어 또는 /etc/NetworkManager/ 설정을 사용한다. 클라우드 환경에서는 인스턴스 생성 시 VPC 내부 사설 IP가 자동 할당되고, 외부 접근이 필요하면 탄력적 IP(Elastic IP)를 연결한다.

IP주소 #IPv4 #IPv6 #공인IP #사설IP #고정IP #NAT #서버IP #네트워크기초 #DNS

URL 입력부터 화면 렌더링까지

우리가 브라우저에 URL을 입력하고 엔터를 누르는 순간부터 웹페이지가 화면에 표시되기까지, 눈에 보이지 않는 곳에서 수많은 단계가 연쇄적으로 실행된다. 이 전체 흐름을 이해하면 웹 개발과 서버 운영의 큰 그림이 잡힌다.

1단계 DNS 조회

브라우저는 입력된 도메인 이름을 IP 주소로 변환하기 위해 DNS 질의를 수행한다. 로컬 캐시, OS 캐시, 리졸버 캐시를 순서대로 확인하고, 캐시 미스가 나면 루트 서버부터 재귀적으로 질의하여 최종 IP 주소를 획득한다. 이 과정은 일반적으로 수십 밀리초 내에 완료된다.

2단계 TCP 연결 수립

IP 주소를 확보하면 브라우저는 해당 서버의 포트(HTTP 80, HTTPS 443)로 TCP 3-Way Handshake를 수행한다. SYN, SYN-ACK, ACK 패킷을 교환하여 양방향 통신 채널을 확보한다. HTTPS라면 이 위에 TLS 핸드셰이크가 추가로 진행되어 암호화 키를 협상하고 보안 채널을 수립한다. 3단계 HTTP 요청 전송 TCP 연결이 완료되면 브라우저는 HTTP 요청 메시지를 서버로 전송한다. 요청 메시지에는 메서드(GET, POST 등), 요청 경로, Host 헤더, User-Agent, Accept 헤더, 쿠키 등이 포함된다. GET 요청이라면 URL의 경로에 해당하는 리소스를 달라는 의미이고, POST라면 폼 데이터나 JSON 바디를 함께 전달한다. 4단계 서버 측 처리 웹서버(Nginx, Apache)가 요청을 수신한다. 정적 파일 요청이라면 웹서버가 파일 시스템에서 해당 파일을 찾아 바로 응답한다. 동적 요청이라면 리버스 프록시를 통해 WAS(Tomcat, Gunicorn, Express)로 전달된다. WAS는 라우팅 규칙에 따라 적절한 핸들러 함수를 실행하고, 필요한 경우 데이터베이스에 쿼리를 날려 데이터를 조회하거나 수정한다. 비즈니스 로직 처리가 끝나면 HTML 문서 또는 JSON 데이터를 생성하여 HTTP 응답 메시지에 담아 반환한다. 5단계 HTTP 응답과 렌더링 서버의 응답 메시지에는 상태 코드(200 OK, 404 Not Found, 500 Internal Server Error 등), 응답 헤더(Content-Type, Content-Length, Cache-Control 등), 그리고 응답 바디(HTML, JSON, 이미지 바이너리 등)가 포함된다. 브라우저는 HTML을 파싱하여 DOM 트리를 생성하고, CSS를 파싱하여 CSSOM을 구성한 뒤, 둘을 결합한 렌더 트리를 기반으로 레이아웃 계산과 페인팅을 수행한다. HTML 파싱 중 외부 리소스(CSS, JS, 이미지, 폰트)를 발견하면 각각에 대해 추가 HTTP 요청을 보낸다. 캐싱이 속도를 결정한다 이 전체 과정에서 성능을 좌우하는 핵심은 캐싱이다. 브라우저 캐시에 이전에 받은 리소스가 남아 있으면 서버에 요청조차 보내지 않는다. CDN(Content Delivery Network)은 전 세계 엣지 서버에 정적 콘텐츠를 미리 복제해두어 사용자와 물리적으로 가까운 서버에서 응답한다. 서버 측에서도 Redis 같은 인메모리 캐시에 자주 조회되는 데이터를 올려두면 데이터베이스 부하를 줄이고 응답 시간을 단축할 수 있다. #웹서버 #HTTP #DNS #TCP #브라우저렌더링 #웹동작원리 #CDN #캐싱 #리버스프록시 #웹개발기초

DNS는 인터넷의 전화번호부다

우리가 브라우저에 naver.com을 입력하면 네이버 메인 페이지가 열린다. 하지만 컴퓨터는 naver.com이라는 문자열을 이해하지 못한다. 네트워크 통신에서 실제로 사용되는 것은 IP 주소다. naver.com을 223.130.195.200 같은 IP 주소로 변환해주는 시스템이 바로 DNS(Domain Name System)다. 인간이 읽기 쉬운 도메인 이름과 기계가 필요로 하는 IP 주소 사이를 연결하는 전화번호부 역할을 한다.

DNS 질의 과정

브라우저에 도메인을 입력했을 때 실제로 벌어지는 과정은 생각보다 복잡하다. 먼저 운영체제는 로컬 DNS 캐시를 확인한다. 캐시에 없으면 시스템에 설정된 리졸버(Resolver) DNS 서버에 질의한다. 보통 ISP가 제공하는 DNS 서버이거나 구글의 8.8.8.8, 클라우드플레어의 1.1.1.1 같은 퍼블릭 DNS다. 리졸버도 캐시에 답이 없으면 루트 DNS 서버에 질의한다. 루트 서버는 .com을 관리하는 TLD(Top-Level Domain) 네임서버의 주소를 알려준다. TLD 서버는 naver.com의 권한 있는 네임서버(Authoritative Name Server)의 주소를 알려주고, 최종적으로 권한 있는 네임서버가 해당 도메인의 실제 IP 주소를 반환한다. 이 전체 과정을 재귀적 질의(Recursive Query)라고 한다.

DNS 레코드의 종류

DNS 서버에는 단순히 도메인과 IP의 매핑만 저장되는 것이 아니다. 다양한 유형의 레코드가 존재한다. A 레코드는 도메인을 IPv4 주소에 매핑한다. AAAA 레코드는 IPv6 주소에 대응한다. CNAME 레코드는 도메인의 별칭을 설정한다. www.example.com을 example.com으로 연결할 때 사용한다. MX 레코드는 해당 도메인의 이메일 수신 서버를 지정한다. TXT 레코드는 도메인 소유권 인증, SPF, DKIM, DMARC 같은 이메일 보안 설정에 활용된다. NS 레코드는 해당 도메인의 권한 있는 네임서버를 지정한다.

TTL과 캐싱

각 DNS 레코드에는 TTL(Time To Live) 값이 설정된다. TTL은 해당 레코드가 캐시에 유지되는 시간을 초 단위로 지정한다. TTL이 3600이면 리졸버는 1시간 동안 해당 레코드를 캐시에 보관하고, 같은 도메인에 대한 질의가 들어오면 캐시에서 바로 응답한다. TTL을 짧게 설정하면 DNS 변경이 빠르게 전파되지만 네임서버 부하가 늘어나고, 길게 설정하면 변경 반영이 느려진다. 서버 이전이나 IP 변경을 계획할 때는 사전에 TTL을 짧게

백업이 없으면 복구도 없다

서버 운영에서 백업은 보험이다. 아무 일 없을 때는 비용과 수고만 드는 것 같지만, 장애가 터지는 순간 백업이 없으면 모든 것을 잃는다. 하드웨어 고장, 랜섬웨어 감염, 운영자의 실수로 인한 데이터 삭제, 소프트웨어 업데이트 중 데이터 손상까지, 데이터를 잃는 시나리오는 끝없이 많다. 서버 백업의 기본 개념과 전략을 정리한다.

풀 백업, 증분 백업, 차등 백업

백업 방식은 크게 세 가지로 나뉜다. 풀 백업(Full Backup)은 전체 데이터를 매번 복사하는 방식이다. 복구가 간단하지만 시간과 저장 공간을 많이 소모한다. 증분 백업(Incremental Backup)은 마지막 백업 이후 변경된 데이터만 복사한다. 속도가 빠르고 저장 공간도 적게 쓰지만, 복구 시 풀 백업본과 이후 모든 증분본을 순서대로 적용해야 한다. 차등 백업(Differential Backup)은 마지막 풀 백업 이후 변경된 모든 데이터를 복사한다. 증분보다 복구가 빠르지만 시간이 지날수록 백업 크기가 커진다. 실무에서는 주 1회 풀 백업, 매일 증분 백업을 조합하는 방식이 가장 보편적이다.

3-2-1 백업 원칙

백업 전략의 표준으로 통하는 규칙이다. 데이터 사본을 최소 3개 보관하고, 2종류 이상의 서로 다른 저장 매체에 저장하며, 1개는 물리적으로 다른 장소에 보관한다. 예를 들어 서버 로컬 디스크에 1차 백업, 외장 NAS에 2차 백업, AWS S3 같은 클라우드 스토리지에 3차 백업을 두는 구조다. 로컬 백업만 있으면 서버실 화재나 침수 시 원본과 백업이 동시에 소실된다. 원격지 백업이 이 위험을 제거한다.

데이터베이스 백업의 특수성

파일 시스템 백업과 데이터베이스 백업은 성격이 다르다. 데이터베이스가 가동 중인 상태에서 단순히 데이터 파일을 복사하면 트랜잭션 일관성이 깨진 불완전한 백업이 될 수 있다. MySQL의 mysqldump, PostgreSQL의 pg_dump 같은 논리적 백업 도구는 일관된 스냅샷을 생성한다. 대용량 데이터베이스에서는 물리적 백업 도구(XtraBackup, pg_basebackup)가 속도 면에서 유리하다. WAL(Write-Ahead Log) 아카이빙을 설정하면 특정 시점으로 복구하는 PITR(Point-In-Time Recovery)이 가능해진다.

백업 검증을 하지 않은 백업은 백업이 아니다

백업을 수행하는 것만으로는 부족하다. 백업 파일이 실제로 복구 가능한지 정기적으로 검증해야 한다. 실무에서 의외로 흔한 사고가 수개월간 백업을 돌렸는데 정작 복구하려니 파일이 손상되어 있었다는 케이스다. 월 1회 이상 테스트 환경에서 백업 파일을 실제로 복원하고, 데이터 정합성을 확인하는 절차를 운영 프로세스에 포함시켜야 한다.

백업 자동화

백업은 사람이 수동으로 하면 반드시 누락이 발생한다. cron 스케줄러로 백업 스크립트를 자동 실행하고, 결과를 Slack이나 이메일로 통지받는 파이프라인을 구성하는 것이 표준이다. 오픈소스 도구로는 rsync 기반 스크립트, Restic, Borg Backup이 널리 쓰이며, 클라우드 환경에서는 AWS Backup, GCP Snapshot 같은 매니지드 서비스를 활용할 수 있다.

서버백업 #데이터백업 #3-2-1백업 #증분백업 #풀백업 #데이터베이스백업 #PITR #백업전략 #rsync #재해복구