메인 콘텐츠로 건너뛰기
TILNOTEAI 노트AI 스퀘어AI 스퀘어

엔진엑스(Nginx) 기초 이해 정리

설탕사과
설탕사과
•조회수 50
요약

핵심 요약

엔진엑스는 마스터·워커 프로세스 구조를 가진 고성능 웹 서버이자 리버스 프록시입니다. 설정 파일 구조와 server/http/location 블록, 매칭 규칙, 설정 테스트 방법을 이해하면 기본 웹 서비스와 간단한 라우팅, 정적 파일 제공까지 스스로 구성할 수 있습니다.

엔진엑스는 어떤 도구인가

엔진엑스는 웹 서버이면서 리버스 프록시, 로드 밸런서, 캐시 서버 등 여러 역할을 동시에 수행할 수 있는 서버 소프트웨어입니다.

흔히 아파치와 비교되지만, 비동기 이벤트 기반 구조 덕분에 적은 자원으로 많은 연결을 처리하는 데 강점을 갖고 있습니다.

실무에서는 정적 파일 제공, 백엔드 애플리케이션 앞단의 리버스 프록시, 여러 서버 간 요청 분산(로드 밸런싱) 등 다양한 용도로 쓰입니다.

엔진엑스를 제대로 활용하려면 "프로세스 구조"와 "설정 파일 구조"를 이해하는 것이 출발점입니다.

마스터·워커 프로세스 구조

엔진엑스를 실행하면 기본적으로 두 종류의 프로세스가 뜹니다.

부모 역할을 하는 마스터 프로세스는 설정 파일 읽기, 워커 프로세스 생성·관리, 재시작·재로딩 등의 관리 작업을 담당합니다.

실제 클라이언트 요청을 받고 처리하는 것은 워커 프로세스입니다.

운영체제에서 ps나 top으로 보면, 1개의 master 프로세스와 그 아래 여러 개의 worker 프로세스가 자식 프로세스로 떠 있는 것을 확인할 수 있습니다.

워커 수는 설정 파일에서 worker_processes 지시어로 지정하며, 보통 CPU 코어 수에 맞추거나 auto로 두어 자동으로 할당되게 설정합니다.

설정 파일의 전체 구조와 문법

기본 설정 파일은 보통 /etc/nginx/nginx.conf 에 위치하며, 이 파일이 엔진엑스 동작 방식을 결정합니다.

설정은 크게 두 종류의 지시어로 구성됩니다.

하나는 세미콜론(;)으로 끝나는 한 줄짜리 설정인 "단일 지시어"이고, 다른 하나는 중괄호({ }) 안에 하위 설정들을 포함하는 "블록 지시어"입니다.

예를 들어 worker_processes 1; 같은 것은 단일 지시어이며, http { ... }나 server { ... } 같은 것은 블록 지시어입니다.

모든 지시어는 세미콜론 누락, 중괄호 짝 맞지 않음 같은 단순 문법 오류만 있어도 전체 설정이 실패하기 때문에, 문법을 엄격히 지켜야 합니다.

include로 설정 파일 분리 관리하기

실무에서는 모든 설정을 nginx.conf 하나에 몰아 넣지 않고, 여러 파일로 나누어 관리합니다.

이때 include 지시어를 사용해 특정 경로의 설정 파일들을 가져옵니다.

예를 들어 nginx.conf 안에 아래와 같이 적혀 있을 수 있습니다.

nginx http { include /etc/nginx/conf.d/*.conf; }

이렇게 해두면 /etc/nginx/conf.d 디렉터리 안의 .conf 파일들이 모두 불러와집니다.

새 서버 설정을 추가하고 싶을 때 이 디렉터리에 mysite.conf 같은 파일을 만들어 넣고, 엔진엑스를 재시작 또는 재로드 하면 자동으로 적용되는 구조입니다.

http 블록: HTTP 관련 설정의 최상위

http { ... } 블록은 HTTP 프로토콜을 사용하는 기능을 묶어 두는 영역입니다.

여기 안에 서버(server) 블록들이 들어가고, 그 안에 다시 location 블록들이 들어가는 계층 구조를 가집니다.

기본 nginx.conf에서 http 블록 내부에 include /etc/nginx/conf.d/*.conf; 같은 구문이 있으면, conf.d 내부의 파일들은 모두 http 블록 안에서 해석된다고 보면 됩니다.

즉 /etc/nginx/conf.d/hello.conf에 server { ... }를 작성해두면, 결과적으로는 http { server { ... } } 구조로 포함되게 됩니다.

HTTP 처리와 관련된 대부분의 설정(기본 헤더, 로그 형식, 압축 등)도 http 블록 안에서 정의합니다.

server 블록: 도메인·포트별 가상 서버

server { ... } 블록은 "이 도메인/포트로 들어온 요청을 어떻게 처리할지"를 정의하는 단위입니다.

여기서 대표적으로 지정하는 것이 두 가지입니다.

하나는 listen로 어떤 포트(예: 80, 82)를 받을지 정하고, 다른 하나는 server_name으로 어떤 도메인(예: example.com, localhost)을 받을지 정합니다.

예를 들어:

nginx server { listen 82; server_name hello-world.com; }

라고 하면, 클라이언트가 hello-world.com:82로 접속했을 때 이 서버 블록이 선택됩니다.

하나의 엔진엑스 인스턴스에서 여러 도메인과 포트를 동시에 처리할 수 있는 이유가 바로 이 server 블록 덕분입니다.

location 블록: URL 경로별 세부 라우팅

location { ... } 블록은 서버 블록 안에서 URL 경로에 따라 응답을 다르게 하고 싶을 때 사용합니다.

예를 들어 /, /api, /images/ 같은 서로 다른 경로에 대해 각각 다른 설정을 적용할 수 있습니다.

기본 형태는 다음과 같습니다.

nginx server { listen 82; server_name hello-world.com;

location / {
    return 200 "Hello World";
}

location /a {
    return 200 "Hello World A";
}

location /b {
    return 200 "Hello World B";
}

}

위 예시에서 / 로 요청하면 "Hello World", /a 로 요청하면 "Hello World A"가 반환되며, 서로 다른 location 블록이 선택됩니다.

location 블록은 단순 출력뿐 아니라 프록시 설정, 정적 파일 경로 설정, 인증, 캐시 등 거의 모든 HTTP 세부 기능을 제어하는 핵심 단위입니다.

prefix(접두) 매칭과 exact(정확) 매칭

location은 URL 경로를 어떤 방식으로 비교할지에 따라 동작이 달라집니다.

가장 기본은 "접두(prefix) 매칭"으로, 지정한 경로로 시작하기만 하면 뒤에 무엇이 붙어 있어도 매칭된 것으로 간주합니다.

예를 들어 location /img { ... } 를 설정하면, /img, /img/a.jpg, /img/sub/1.png 등 /img로 시작하는 모든 요청이 이 블록에 매칭됩니다.

이 때문에 /a, /a/b, /a/anything… 이 전부 같은 location /a { ... } 설정을 타는 상황이 발생할 수 있습니다.

정확히 "이 경로 하나만" 처리하고 싶다면, =를 붙여 exact 매칭을 사용합니다.

nginx location = /a { return 200 "A only"; }

이렇게 설정하면 /a는 매칭되지만 /a/, /a/b, /abc 등은 다른 location으로 넘어갑니다.

실무에서는 "정확히 이 경로만" 원하는 응답을 주고, 나머지는 기본 로직을 타게 하는 등, prefix와 exact 매칭을 적절히 섞어 써야 예상치 못한 응답을 피할 수 있습니다.

설정 테스트: nginx -t의 중요성

엔진엑스 설정을 수정했다면, 실제 재시작·재로드 전에 반드시 문법 검사를 해야 합니다.

이때 사용하는 명령이 nginx -t 입니다.

shell sudo nginx -t

이 명령은 설정 파일을 읽어 문법 오류 위치와 성공 여부를 알려줍니다.

예를 들어 세미콜론 하나만 빠져 있어도 "어느 파일, 몇 번째 줄 근처에서 오류가 났는지"를 보여주므로, 실제 서비스 중인 서버에서 치명적인 중단을 예방할 수 있습니다.

습관적으로 "수정 → nginx -t → 문제 없으면 reload" 순서를 지키는 것이 안전한 운영의 기본입니다.

파일(정적 콘텐츠) 제공을 위한 root와 location

문자열을 직접 리턴하는 대신, 디스크에 있는 파일을 그대로 응답하고 싶을 때는 정적 파일 제공 기능을 사용합니다.

핵심은 root 지시어와 location 조합입니다.

예를 들어 /var/www/html/images 경로에 파일들을 두고, /images/로 시작하는 URL에서 이 파일을 제공하고 싶다면 다음처럼 설정합니다.

nginx server { listen 80; server_name example.com;

root /var/www/html;

location /images/ {
    # 요청 URL /images/a.jpg -> 실제 파일 /var/www/html/images/a.jpg
}

}

root는 "기본 디렉터리"를 지정하고, location의 경로와 합쳐져 실제 파일 경로가 됩니다.

요청한 경로에 해당하는 파일이 존재하면 그 파일이 그대로 응답되고, 없으면 404 Not Found 등 기본 에러 페이지가 반환됩니다.

이를 이용해 간단한 이미지 서버, 정적 웹 페이지, 프론트엔드 빌드 결과물 등을 엔진엑스로 바로 서비스할 수 있습니다.

앞으로 더 공부하면 좋은 것들

기본적인 프로세스 구조, server/http/location, 매칭 규칙, 정적 파일 제공을 이해했다면 엔진엑스의 첫걸음은 성공한 것입니다.

그 다음 단계로는 다음 주제들을 공부하면 실무 활용도가 크게 올라갑니다.

  • location 우선순위 규칙(=, ^~, ~, ~* 등 정규식 매칭 포함)

  • rewrite 및 리다이렉트 규칙 설계

  • 리버스 프록시 설정(proxy_pass)과 백엔드 서비스 연동

  • 로드 밸런싱(업스트림 설정)과 헬스 체크

  • keepalive, 버퍼, 워커 수 등 성능·튜닝 관련 지시어

이 지식들을 조합하면, 하나의 엔진엑스 인스턴스로 여러 서비스의 앞단을 안정적으로 운용하는 구조를 설계할 수 있습니다.

인사이트

엔진엑스를 처음 배울 때 가장 중요한 포인트는 "구조를 먼저 이해하는 것"입니다.

  • 프로세스 구조: master가 관리, worker가 처리

  • 설정 구조: http → server → location 계층

  • 매칭 규칙: prefix vs exact, 어떤 요청이 어느 블록으로 가는지

이 세 가지만 명확하게 잡고 나면, 나머지 기능(리버스 프록시, 로드 밸런서, TLS, 캐시 등)은 모두 이 구조 위에 올라가는 옵션일 뿐이라 훨씬 쉽게 이해됩니다.

실제로 설정을 만질 때는 작은 예제로 자주 테스트하고, nginx -t를 습관처럼 사용하면 "왜 이렇게 응답이 나오지?" 하는 상황을 크게 줄일 수 있습니다.

출처 및 참고:

#엔진엑스#웹서버#리버스 프록시#설정 파일#프로세스 구조