서버 및 프론트엔드 기본 가이드

1. 소개

본 문서는 지은씨가 나중에 프론트엔드 개발자 업무를 진행하게 되었을 때 우리 회사 서버 환경에서 원활하게 업무를 수행하는 데 필요한 기본 지식과 기술을 제공하기 위해 작성했습니다. 현재 우리 회사의 서버는 Ubuntu Server 운영체제 위에서 Nginx 웹 서버, PostgreSQL 데이터베이스를 사용하며, 백엔드와의 통신은 주로 AJAX 방식을 통해 이루어집니다.

본 가이드를 통해 서버 접속 방법, 기본 Linux 명령어, 파일 관리, 그리고 현재 진행 중인 '남산 DID 프로젝트'의 프론트엔드 에셋 파일 관리 및 보안 설정에 대한 이해를 높일 수 있을 거예요.

서버 주요 정보

서버 웹 접속 요령

WEB포트로 접속 시(현재 namsan/index.php로 리버스 프록시 걸려있음) 아래와 같이 주소창에 입력합니다. 

wizinfo.iptime.org:8080

위 경우와 같이 서버 주소 : 뒤에 포트 번호 입력하시면 됩니다.

2. WIZINFO 서버 환경 개요

본 회사의 웹 서비스는 안정적이고 효율적인 운영을 위해 다음과 같은 기술 스택으로 구성되어 있습니다. 각 구성 요소의 기본적인 역할과 특징을 이해하는 것은 프론트엔드 개발 업무에도 도움이 될 거예요.

2.1. Ubuntu Server

개요: Ubuntu Server는 Debian GNU/Linux를 기반으로 하는 Linux 배포판으로, 개인용 데스크톱 환경뿐만 아니라 서버 환경에서도 널리 사용됩니다. Linux는 Unix를 기반으로 개발된 운영체제로, 다중 사용자와 멀티태스킹을 지원하여 보안성이 높고 안정적인 서버 운영에 적합합니다. 사실 익숙하고 공짜라 쓰는 거예요. 🙂

특징:

2.2. Nginx 웹 서버

개요: Nginx(엔진엑스)는 가벼움과 높은 성능을 목표로 개발된 오픈소스 웹 서버 소프트웨어입니다. 웹 서버 기능 외에도 리버스 프록시, 로드 밸런서, HTTP 캐시 등으로 활용됩니다.

특징:

클라이언트 (브라우저)
Nginx (웹 서버/리버스 프록시)
정적 파일 (HTML, CSS, JS, Images)
WAS (PHP-FPM, Node.js 등)

Nginx의 리버스 프록시 및 정적/동적 콘텐츠 처리 흐름

2.3. PostgreSQL 데이터베이스

개요: PostgreSQL은 객체-관계형 데이터베이스 시스템(ORDBMS)으로, 오픈소스로 개발되어 라이선스 비용 없이 사용할 수 있습니다. 금융, 제조, 소매, 물류 등 다양한 분야에서 활용되며 데이터 무결성 유지 및 대규모 워크로드 관리에 적합합니다. 그리고 많은 구현 예가 존재해서 학습 곡선이 낮아요. MySQL 한 번이라도 접하셨으면 금방 파악이 될 겁니다.

특징:

2.4. AJAX 통신 방식

개요: AJAX(Asynchronous JavaScript and XML)는 웹 페이지 전체를 다시 로드하지 않고도 서버와 비동기적으로 데이터를 교환하여 동적으로 화면 일부만 업데이트할 수 있게 하는 웹 개발 기술입니다. 이를 통해 사용자 경험을 크게 향상시킬 수 있습니다. 주로 쿼리를 쓰지 않고 RESTful API 호출로 가볍게 구현하는 것을 목표로 하고 있어요.

핵심 구성 요소:

동작 원리: 사용자가 웹 애플리케이션과 상호작용하면, JavaScript로 작성된 AJAX 엔진이 백그라운드에서 XMLHttpRequest 객체를 통해 서버에 요청을 보내고 응답을 받습니다. 이 과정에서 페이지 전체가 새로고침되지 않고 필요한 부분만 동적으로 갱신됩니다.

활용 사례: 자동 완성 검색어 제안, 실시간 양식 유효성 검사, 채팅 기능, 소셜 미디어 피드 업데이트, 투표 및 등급 시스템 등 다양한 인터랙티브 웹 기능 구현에 사용됩니다.

고려 사항: 브라우저 지원 범위, 보안 및 개인 정보 보호, 접근성, 검색 엔진 최적화 등의 문제를 고려해야 합니다.

3. 서버 접속 및 파일 관리를 위한 필수 프로그램

서버에 접속하여 파일을 조작하고 명령어를 실행하기 위해서는 특정 클라이언트 프로그램이 필요합니다. 본 섹션에서는 제가 추천하는 프로그램, MobaXterm과 WinSCP의 설치 및 기본 사용법을 안내합니다.

3.1. MobaXterm: SSH 클라이언트

MobaXterm은 SSH 접속, X11 포워딩, SFTP 파일 전송 등 다양한 기능을 하나의 프로그램으로 제공하는 터미널 소프트웨어입니다. Windows 환경에서 주로 사용됩니다.

3.1.1. MobaXterm 설치

3.1.2. MobaXterm 기본 사용법 (서버 접속)

3.1.3. MobaXterm을 이용한 파일 전송 (SFTP)

3.2. WinSCP: SFTP/FTP 클라이언트

WinSCP는 Windows 환경에서 GUI(그래픽 사용자 인터페이스)를 통해 안전하게 파일을 전송할 수 있는 SFTP, SCP, FTP 클라이언트 프로그램입니다. 특히 서버와 로컬 PC 간의 파일 업로드 및 다운로드 작업에 유용합니다.

3.2.1. WinSCP 설치

3.2.2. WinSCP 기본 사용법 (서버 접속 및 파일 전송)

4. Ubuntu Server 및 Namsan DID 프로젝트 운영 가이드

프론트엔드 개발자로서 서버에 직접 접속하여 작업하는 경우가 빈번하지는 않지만, 기본적인 Linux 명령어와 프로젝트 파일 구조를 이해하고 있으면 개발 및 문제 해결 과정에서 큰 도움이 됩니다.

4.1. Ubuntu Server 기본 조작을 위한 Linux 명령어

터미널(MobaXterm)을 통해 서버에 접속하면, 다음과 같은 기본적인 Linux 명령어들을 사용하여 파일 시스템을 탐색하고 파일을 관리하며, 실행 중인 프로세스를 확인하고 로그를 볼 수 있습니다. 명령어는 일반적으로 명령어 [옵션][인자] 형태로 사용되며, 대소문자를 구분합니다.

4.1.1. 디렉토리 탐색 및 관리

4.1.2. 파일 및 디렉토리 생성, 복사, 이동, 삭제

4.1.3. 파일 내용 보기

여기까지가 서버 내부의 JSON 파일, PHP, HTML 코드 상태, 로그 확인을 위한 기초적인 조작법입니다.

4.1.4. 부터는 모르셔도 상관이 없습니다. 일단 리눅스 기본이라 생각해서 적어놓은 거예요~

4.1.4. 프로세스 및 시스템 상태 확인

4.1.5. 파일 검색

4.1.6. 네트워크 관련 (참고용)

이 명령어들은 서버 환경에서 작업할 때 기본적으로 알아두면 유용한 것들입니다. 각 명령어에는 더 많은 옵션들이 있으며, man 명령어이름 (예: man ls)을 입력하면 해당 명령어의 매뉴얼 페이지를 통해 자세한 사용법을 확인할 수 있습니다.

4.2. 남산 DID 프로젝트 에셋 파일 관리 및 보안

현재 진행 중인 '남산 DID 프로젝트'의 서비스 관련 PHP 및 JSON 파일, 로그 파일들은 서버의 /var/www/html/namsan 경로에 위치해 있습니다. 프론트엔드 개발에 필요한 에셋 파일(이미지, CSS, JavaScript 파일 등)들은 보안 및 관리 효율성을 위해 이 경로와 분리하여 별도의 경로에 위치시키는 것이 좋습니다.

4.2.1. 에셋 파일 저장 경로

4.2.2. Nginx를 통한 에셋 파일 접근 URL 설정

서버의 /var/www/namsan-assets/ 디렉토리에 저장된 에셋 파일들을 웹 브라우저에서 특정 URL(예: http://wizinfo.iptime.co.kr:8080/namsan-assets/...)로 접근할 수 있도록 Nginx 설정을 변경해야 합니다.

Nginx 설정 파일(보통 /etc/nginx/nginx.conf 또는 /etc/nginx/sites-available/default 내의 server 블록)에 다음과 같은 location 블록을 추가하여 URL과 실제 파일 시스템 경로를 매핑합니다.

이 작업은 일반적으로 서버 관리자나 백엔드 개발자가 수행하지만, 프론트엔드 개발자도 이 설정을 이해하고 있어야 에셋 파일의 URL을 올바르게 사용할 수 있습니다.

4.2.3. Nginx 설정 (에셋 파일 서빙 및 보안)
(이 부분은 구현되어 있는 부분을 설명하기 위함으로, 모르셔도 됩니다)

Nginx에서 특정 URL 경로를 실제 파일 시스템 경로로 연결하고, 보안 설정을 적용하기 위해서는 server 블록 내에 location 지시어를 사용합니다. 에셋 파일들을 위한 새로운 location 블록을 설정할 때, /var/www/html/namsan 경로에 있는 기존 PHP 애플리케이션의 설정과 충돌하지 않도록 주의해야 합니다. 

server {
    listen 8080;
    server_name wizinfo.iptime.org;

    # Root for the main application (Namsan DID backend)
    # PHP 파일들이 /var/www/html/namsan/ 경로에 존재시,
    # 이 root 설정은 /var/www/html/ 또는 /var/www/html/namsan/ 으로 구체화될 수 있음
    # 일반적인 경우를 위해 /var/www/html 로 설정
    root /var/www/html;

    # Default index files
    index index.php index.html index.htm;

    # Location block for Namsan DID backend PHP processing
    # /namsan/ 경로로 들어오는 요청 중 .php 로 끝나는 경우 처리
    location ~ ^/namsan/.*\.php$ {
        # try_files $uri =404; # PHP 파일이 실제로 존재하는지 확인
        # PHP-FPM 설정 (실제 환경에 맞게)
        # include snippets/fastcgi-php.conf;
        # fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; # PHP 버전 확인 필요
        # fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        # fastcgi_index index.php;

        # 임시로 단순화된 PHP 처리 예시 (실제 환경에서는 위 주석처리된 상세 설정 사용)
        # 이 부분은 선임 개발자와 협의하여 정확한 설정을 반영해야 함.
        # 잘못된 설정은 보안 문제를 야기하거나 에셋 파일 서빙에 영향을 줄 수 있음.
        # 예를 들어, 모든 .php 요청을 처리하도록 너무 광범위하게 설정하면
        # /namsan-assets/ 경로에 실수로 업로드된 php 파일이 실행될 수도.
        # 따라서, ^/namsan/.*\.php$ 와 같이 경로를 명확히 지정하는 것이 중요.
        # 아래는 PHP-FPM 연동을 위한 일반적인 설정.
        # 실제 서버의 PHP-FPM 소켓 경로와 버전을 확인하여 적용해야 함.
        include snippets/fastcgi-php.conf; # Nginx 기본 fastcgi 파라미터 포함
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
        # fastcgi_pass 127.0.0.1:9000; # TCP 소켓 사용하는 경우
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # **New Location Block for Front-End Assets**
    # URL /namsan-assets/ 로 시작하는 모든 요청을 처리.
    location /namsan-assets/ {
        # alias는 URL 경로의 일부를 파일 시스템 경로로 대체.
        # location 경로와 alias 경로 모두 끝에 슬래시(/)를 일치시키는 것이 중요.
        # 이는 경로 해석의 일관성을 유지, 잠재적인 경로 탐색(path traversal) 취약점을 예방하는 데 도움.
        # 예를 들어, /namsan-assets/ (슬래시 O) 와 alias /var/www/namsan-assets/ (슬래시 O) 로 설정하면,
        # /namsan-assets/css/style.css 요청은 /var/www/namsan-assets/css/style.css 로 매핑.
        # 만약 location /namsan-assets (슬래시 X) 와 alias /var/www/namsan-assets/; (슬래시 O) 로 설정하면,
        # /namsan-assets../secret 과 같은 요청이 /var/www/namsan-assets/../secret 으로 해석될 위험.
        alias /var/www/namsan-assets/; # 실제 에셋 파일이 저장된 서버 경로

        # 보안: 디렉토리 리스팅 방지
        # autoindex off; 설정은 해당 URL로 접근 시 파일 목록이 노출방지.
        autoindex off;

        # 보안 및 성능: 허용된 에셋 파일 타입만 접근 허용 및 캐싱 설정
        # 정규표현식을 사용하여 특정 확장자의 파일에 대해서만 처리를 정의.
        # ~* 는 대소문자를 구분하지 않는 정규표현식 매칭을 의미.
        # (?:...)는 그룹핑하되 캡처하지 않음을 의미.
        # \.(?:jpg|jpeg|...)는 .jpg 또는 .jpeg 등으로 끝나는 파일을 의미.
        location ~* \.(?:jpg|jpeg|gif|png|ico|svg|webp|css|js|woff|woff2|ttf|eot|otf|mp4|webm|json)$ {
            # try_files는 요청된 URI에 해당하는 파일이 존재하는지 순서대로 확인.
            # $uri는 현재 요청 URI를 의미, 파일이 존재하면 해당 파일을 제공,
            # 존재하지 않으면 =404 에러를 반환.
            # 이를 통해 존재하지 않는 에셋 요청에 대해 명확한 404 응답.
            try_files $uri =404;

            # 성능: 브라우저 캐싱 설정
            # expires 30d; 는 해당 에셋을 30일 동안 브라우저에 캐시.
            expires 30d;

            # add_header Cache-Control "public, no-transform"; 는 캐시 제어 헤더를 추가
            # 프록시 서버 등에서도 캐시될 수 있도록 하고(public), 원본 내용을 변경하지 않도록(no-transform) 한다.
            add_header Cache-Control "public, no-transform";

            # 성능 (선택 사항): 정적 에셋에 대한 접근 로그 비활성화
            # access_log off; 로 설정하면 해당 요청이 Nginx 접근 로그에 기록되지 않아,
            # 로그 파일 크기를 줄이고 약간의 성능 향상을 기대.
            access_log off;
        }

        # 보안: /namsan-assets/ 경로 내에서 위에서 명시적으로 허용된 확장자 외의 모든 파일 접근 차단
        # 이 location 블록은 /namsan-assets/ 내부의 모든 파일에 대한 기본 규칙으로 작동.
        # 위의 특정 확장자 허용 location 블록에서 처리되지 않은 모든 요청은 이 블록으로.
        # 예를 들어, /namsan-assets/sensitive.txt 나 /namsan-assets/script.php 와 같은 파일에 대한 직접 접근을 차단.
        # deny all; 지시어는 모든 IP 주소에서의 접근을 거부.
        # return 403; 은 접근 거부(Forbidden) 상태 코드를 반환. (404 Not Found도 가능)
        # 이 설정은 혹시라도 에셋 디렉토리에 PHP 파일이나 설정 파일 등이 잘못 업로드되었을 경우,
        # 해당 파일들이 웹을 통해 직접 실행되거나 노출되는 것을 방지하는 중요한 보안 장치.
        location ~ /namsan-assets/ { # /namsan-assets/ 로 시작하는 모든 경로에 대해 적용 (위 확장자 규칙 이후)
            deny all;
            return 403; # 또는 404
        }
    }

    # 보안: Namsan DID 프로젝트 로그 파일 직접 접근 차단
    # /var/www/html/namsan/log/ 경로에 있는 .log 파일들에 대한 웹 접근을 차단.
    # 로그 파일은 민감한 정보를 포함할 수 있으므로 웹을 통해 직접 접근할 수 없도록 해야 됨.
    location ~ ^/namsan/log/.*\.log$ {
        deny all;
        return 403;
    }

    # 기타 애플리케이션을 위한 설정들...
    # 예: 메인 애플리케이션의 다른 경로들
    location / {
        # PHP 애플리케이션의 경우, 보통 index.php로 요청을 전달하는 try_files 설정이 사용됨.
        # try_files $uri $uri/ /index.php?$query_string; # 이 설정은 /namsan/ 경로와 중복될 수 있으므로 주의
        # 남산 DID 프로젝트가 /namsan/ 경로를 사용한다면, 이 루트 location은 다른 용도이거나
        # /namsan/ 보다 우선순위가 낮도록 설정되어야 함.
        # 여기서는 남산 DID 프로젝트의 PHP가 /namsan/ 경로로만 서비스된다고 가정하고,
        # 루트 location은 다른 정적 파일이나 기본 페이지를 위한 것으로 간주.
        # 만약 /var/www/html/index.php 가 존재하고 이것이 기본 진입점이라면 아래와 같이 설정 가능.
        try_files $uri $uri/ /index.php?$args;
    }
}

Nginx location 블록 처리 순서 및 중요성: Nginx는 요청 URI를 처리할 location 블록을 결정할 때 특정 규칙을 따릅니다. 정확한 일치 (=), 우선 순위가 높은 접두사 일치 (^~), 정규 표현식 일치 (~, ~*), 일반 접두사 일치 순으로 평가됩니다. 정규 표현식 location은 설정 파일에 나타난 순서대로 검사되며, 첫 번째로 일치하는 정규 표현식이 사용됩니다.

위의 예시에서 /namsan-assets/에 대한 location 블록 내부에 또 다른 location 블록 (확장자별 처리)을 중첩하여 사용했습니다. 바깥쪽 location /namsan-assets/는 접두사 일치로, 이 경로로 시작하는 모든 요청을 먼저 받습니다. 그 후, 내부의 location ~* \.(?:jpg|jpeg|...)$ 정규 표현식 블록이 특정 확장자에 대해 더 구체적인 처리를 합니다. 만약 이 정규 표현식에 해당하지 않는 파일 (예: .txt 또는 .php)이 /namsan-assets/ 경로로 요청되면, 내부의 location ~ /namsan-assets/ (실제로는 바깥쪽 location /namsan-assets/의 규칙을 상속받아 적용되는 기본 처리 또는 명시적 deny all 규칙)에 의해 접근이 차단됩니다.

이러한 location 블록의 구조와 처리 순서를 이해하는 것은 원하는 대로 요청을 라우팅하고 보안을 강화하는 데 매우 중요합니다. 잘못된 순서나 너무 광범위한 location 규칙은 의도치 않은 파일 노출이나 기능 오작동을 유발할 수 있습니다. 예를 들어, 매우 일반적인 location / { ... } 블록이 특정 에셋 경로를 위한 location /namsan-assets/ { ... } 블록보다 먼저 정의되거나 더 높은 우선순위를 갖게 되면, 에셋 파일이 제대로 처리되지 않을 수 있습니다.

따라서 Nginx 설정을 변경한 후에는 항상 sudo nginx -t 명령어로 문법 오류를 확인하고, sudo systemctl reload nginx (또는 sudo service nginx reload) 명령어로 설정을 적용해야 합니다. 변경 사항은 실제 운영 환경에 배포하기 전에 개발 또는 스테이징 환경에서 충분히 테스트하는 것이 필수적입니다.

4.2.4. 프론트엔드 코드에서 에셋 파일 참조 방법

위와 같이 Nginx 설정에 따라, HTML, CSS, JavaScript 코드에서 에셋 파일을 참조할 때는 /namsan-assets/로 시작하는 URL 경로를 사용합니다.

HTML 예시:

<img src="/namsan-assets/images/logo.png" alt="남산 DID 로고">
<link rel="stylesheet" href="/namsan-assets/css/style.css">
<script src="/namsan-assets/js/main.js"></script>

CSS 예시 (배경 이미지 등):

.header {
    background-image: url('/namsan-assets/images/header-bg.jpg');
}

JavaScript 예시 (동적 이미지 로딩 등):

const logoImage = new Image();
logoImage.src = '/namsan-assets/images/logo_dynamic.svg';
document.getElementById('logo-container').appendChild(logoImage);

중요: 에셋 파일 경로는 항상 /로 시작하는 절대 경로(root-relative path)를 사용하는 것이 좋습니다 (예: /namsan-assets/...). 이렇게 하면 현재 페이지의 URL 깊이에 상관없이 항상 올바른 경로로 에셋을 참조할 수 있습니다. 상대 경로(예: ../images/logo.png)를 사용하면 페이지 URL 구조가 변경될 때 에셋 경로가 깨질 수 있습니다.

4.3. 프로젝트 로그 파일 접근 및 모니터링

웹 애플리케이션 개발 및 운영에서 로그 파일은 문제 해결과 시스템 상태 모니터링에 매우 중요한 역할을 합니다. 프론트엔드 개발자도 API 호출 실패, 에셋 로딩 문제 등 서버 측과 관련된 이슈를 디버깅할 때 로그를 확인해야 하는 경우가 있습니다.

로그 파일 위치:

로그 파일 확인 방법 (Linux 명령어 사용):

로그 파일 접근 보안:

앞서 4.2.3절의 Nginx 설정 예시에서 보았듯이, 웹을 통해 직접 .log 파일에 접근하는 것은 보안상 차단해야 합니다. 로그 파일에는 시스템 정보, 사용자 활동, 오류 메시지 등 민감한 내용이 포함될 수 있기 때문입니다. 서버에 SSH로 접속한 인가된 사용자만이 로그 파일을 확인할 수 있도록 하는 것이 일반적입니다. 허나 한 업체에 커스텀으로 들어가는 시스템에 한해, sudo 관리자를 등록, 로그 확인을 하게 만드는 게 운영하기 좋아요.

프론트엔드 개발 시 API 연동 문제나 특정 페이지 로딩 실패 등의 이슈가 발생했을 때, 브라우저 개발자 도구의 콘솔 및 네트워크 탭을 확인하는 것이 첫 번째 단계입니다. 여기서 원인을 찾기 어렵다면, 관련 서버 로그(애플리케이션 로그, Nginx 에러 로그)를 확인하여 서버 측에서 발생한 오류는 없는지 살펴보는 것이 문제 해결의 실마리를 제공할 수 있습니다. 예를 들어, Nginx 에러 로그에는 특정 파일에 대한 권한 부족(permission denied), 설정 파일 문법 오류, PHP 스크립트 처리 중 발생한 심각한 오류 등이 기록될 수 있습니다. 애플리케이션 로그에는 데이터베이스 연결 실패, 비즈니스 로직 오류 등이 기록될 수 있습니다. 이러한 정보를 통해 문제의 원인이 프론트엔드 코드에 있는지, 아니면 백엔드 또는 서버 환경 설정에 있는지 판단하는 데 도움이 됩니다.

5. 개발자를 위한 서버 운영 기본 원칙 및 보안

서버 자원에 접근하고 이를 활용하는 개발자는 기본적인 서버 운영 원칙과 보안 수칙을 숙지하고 준수해야 합니다. 이는 서비스의 안정성을 유지하고 잠재적인 보안 위협으로부터 시스템을 보호하는 데 필수적입니다.

5.1. 파일 권한 이해 (chmod, chown)

Linux 시스템은 파일과 디렉토리에 대한 접근을 제어하기 위해 정교한 권한 시스템을 사용합니다. 프론트엔드 개발자가 서버에 에셋 파일을 업로드하거나 기존 파일을 수정할 때, 이 권한 설정을 올바르게 이해하고 적용하는 것이 중요합니다. 잘못된 권한 설정은 파일 접근 불가 오류(403 Forbidden)를 유발하거나 보안 취약점을 만들 수 있습니다.

5.1.1. Linux 권한의 기본 개념

Linux 파일/디렉토리 권한은 세 가지 종류의 사용자에 대해 정의됩니다:

각 사용자 유형에 대해 세 가지 기본 권한이 부여되거나 거부될 수 있습니다:

권한은 ls -l 명령어로 확인했을 때 -rwxr-xr--와 같은 심볼릭 형태나, 754와 같은 8진수(octal) 숫자 형태로 표현됩니다. 8진수 숫자는 각 권한 값(r=4, w=2, x=1)의 합으로 계산됩니다. 예를 들어, rwx는 4+2+1=7이 되고, r-x는 4+0+1=5가 됩니다.

소유자 (User)
r w x
그룹 (Group)
r - x
기타 (Others)
r - -
r = 읽기 (4) w = 쓰기 (2) x = 실행 (1) - = 권한 없음 (0)

파일 권한 예시: -rwxr-xr-- (754)

5.1.2. 웹 파일 및 디렉토리 권장 권한

5.1.3. Nginx 사용자(예: www-data)의 역할과 파일 소유권

Nginx와 같은 웹 서버는 보안상의 이유로 일반 사용자 계정이 아닌, 시스템에 의해 관리되는 특정 사용자(및 그룹) 권한으로 실행됩니다. Debian/Ubuntu 계열에서는 이 사용자가 주로 www-data입니다.

웹 서버가 사용자에게 파일을 제공하려면, 이 www-data 사용자가 해당 파일에 대한 읽기 권한과, 해당 파일이 위치한 디렉토리 경로상의 모든 디렉토리에 대한 실행(접근) 권한을 가지고 있어야 합니다.

5.2. Nginx 에셋 서빙 최적화 및 보안 강화

Nginx는 정적 에셋 파일을 효율적으로 제공하는 데 강력한 기능을 제공합니다. 몇 가지 설정을 통해 성능을 향상시키고 보안을 강화할 수 있습니다.

5.2.1. 브라우저 캐싱 활용 (Expires, Cache-Control)

정적 에셋(이미지, CSS, JS 등)은 내용이 자주 변경되지 않으므로, 사용자의 브라우저에 캐시(임시 저장)하도록 지시하여 반복적인 다운로드를 줄이고 페이지 로딩 속도를 향상시킬 수 있습니다. 이는 서버 부하 감소에도 기여합니다.

Nginx 설정에서 expires 지시어와 add_header Cache-Control 지시어를 사용하여 캐싱 정책을 정의합니다.

4.2.3절의 Nginx 설정 예시에 이미 포함된 내용입니다: 

location ~* \.(?:jpg|jpeg|gif|png|ico|svg|webp|css|js|woff|woff2|ttf|eot|otf|mp4|webm|json)$ {
    expires 30d; # 30일 동안 브라우저 캐시 유지
    add_header Cache-Control "public, no-transform"; # 공개 캐시, 변형 금지
    #... 기타 설정...
}

5.2.2. 정적 에셋에 대한 접근 로그 비활성화 (선택 사항)

트래픽이 많은 사이트의 경우, 모든 정적 에셋 요청을 로깅하면 로그 파일이 매우 커지고 약간의 서버 자원을 소모할 수 있습니다. 필요에 따라 특정 location 블록에 대해 접근 로그를 비활성화할 수 있습니다. 

access_log off; # (4.2.3절 예시 참고)

단, 에러 로그(error_log)는 문제 해결을 위해 일반적으로 활성화 상태를 유지합니다.

5.2.3. try_files를 이용한 안정적인 파일 서빙

try_files 지시어는 Nginx가 요청된 URI에 대해 지정된 순서대로 파일이나 디렉토리의 존재 여부를 확인하고, 가장 먼저 발견되는 것을 기준으로 요청을 처리하거나, 모두 없을 경우 대체 URI 또는 HTTP 상태 코드로 응답하도록 합니다.

정적 에셋의 경우, try_files $uri =404; 설정이 일반적입니다. 이는 요청된 URI에 해당하는 파일을 찾아 제공하고, 파일이 없으면 404 오류를 반환합니다. 이는 에셋 경로에 대한 간단하고 효과적인 처리 방식입니다.

더 복잡한 시나리오, 예를 들어 디렉토리 요청 시 index.html을 제공하거나 PHP 핸들러로 요청을 넘기는 경우에도 try_files는 매우 유용하게 사용됩니다 (예: try_files $uri $uri/ /index.php?$query_string;).

5.2.4. 에셋 디렉토리 내 PHP 실행 방지

에셋 파일(특히 사용자가 업로드하는 파일이 저장되는 디렉토리)에서 PHP 스크립트나 다른 서버 사이드 스크립트가 실행되지 않도록 하는 것은 매우 중요한 보안 조치입니다. 이미지 파일만 업로드하도록 제한하더라도, 웹 애플리케이션의 파일 업로드 취약점을 통해 악의적인 PHP 파일이 이미지 파일로 위장하여 업로드될 수 있기 때문입니다.

4.2.3절에서 제시된 Nginx 설정은 이러한 위험을 효과적으로 방지합니다. 

location /namsan-assets/ {
    alias /var/www/namsan-assets/;
    autoindex off;

    # 1. 허용된 에셋 확장자 처리
    location ~* \.(?:jpg|jpeg|gif|png|ico|svg|webp|css|js|woff|woff2|ttf|eot|otf|mp4|webm|json)$ {
        try_files $uri =404;
        expires 30d;
        add_header Cache-Control "public, no-transform";
        access_log off;
    }

    # 2. 그 외 모든 파일 접근 차단 (PHP 실행 방지 포함)
    # 이 블록은 위의 확장자별 location 블록에서 처리되지 않은 모든 /namsan-assets/ 하위 요청에 적용됩니다.
    location ~ /namsan-assets/ { # /namsan-assets/ 로 시작하는 경로에 대한 기본 규칙
        deny all;
        return 403; # 또는 404
    }
}

에셋 서빙에 대한 보안은 단일 설정으로 해결되는 것이 아니라, 여러 계층의 방어 전략을 통해 강화됩니다. 여기에는 올바른 파일 시스템 권한 설정, Nginx location 블록을 통한 경로 기반 접근 제어, 정규 표현식을 이용한 파일 유형 필터링(허용된 유형만 통과시키고 나머지는 차단), 디렉토리 리스팅 비활성화, 그리고 가장 중요하게는 에셋 디렉토리 내에서 스크립트 파일이 실행되지 않도록 하는 조치가 포함됩니다. 이러한 다층적 접근 방식은 실수로 또는 악의적으로 업로드된 위험한 파일로부터 서버를 보호하는 데 필수적입니다.


5.3. 일반적인 보안 수칙 (개발자 유의사항)

6. 기본 문제 해결 (Troubleshooting)

서버 작업 중 발생할 수 있는 몇 가지 일반적인 문제와 해결 방법을 안내합니다.

6.1. 일반적인 연결 문제 (SSH/SFTP)

6.2. Linux 명령어 실행 시 "Permission denied" (권한 없음) 오류

6.3. 에셋 파일 로딩 실패 (404 Not Found 또는 403 Forbidden 오류)

프론트엔드 개발 시 가장 흔하게 접할 수 있는 문제 중 하나는 이미지, CSS, JS 등의 에셋 파일이 웹 페이지에 제대로 로드되지 않는 것입니다. 이때 브라우저 개발자 도구의 'Network' 탭을 확인하면 HTTP 상태 코드로 원인을 짐작할 수 있습니다.

404 오류와 403 오류를 구분하는 것은 문제 해결의 방향을 잡는 데 매우 중요합니다. 404는 주로 '경로 또는 파일명 오류'이거나 '파일 부재'를 의미하는 반면, 403은 '권한 문제' 또는 '설정에 의한 명시적 차단'을 의미합니다. 이 차이를 이해하면 원인 파악을 위한 다음 단계를 더 효과적으로 결정할 수 있습니다.

7. 결론

처음 설명과 같이, 본 가이드는 지은씨가 나중에 프론트엔드 개발자로써 우리 회사 서버 환경에 빠르게 적응하고, 기본적인 서버 조작 및 나중의 기타 프로젝트의 프론트 개발시 에셋 관리, api호출 등 의 업무를 수행하는 데 필요한 핵심 정보를 알려드리고자 만들었어요. Ubuntu Server, Nginx, PostgreSQL, 등 으로 구성된 서버 환경의 이해부터 MobaXterm, WinSCP와 같은 필수 도구 사용법, 기본적인 Linux 명령어, 그리고 Nginx를 활용한 안전한 에셋 파일 관리 및 참조 방법까지 다루어 봤습니다.

특히, 에셋 파일의 보안을 위해 별도 경로에 저장하고 Nginx의 location 및 alias 지시어를 통해 접근을 제어하며, 특정 파일 확장자만 허용하고 디렉토리 리스팅을 방지하는 등의 보안 설정은 매우 중요합니다. 또한, 파일 권한(chmod, chown)에 대한 이해와 올바른 설정은 서비스의 안정적인 운영과 보안 유지에 필수적입니다.

로그 파일 확인(tail -f) 및 기본적인 문제 해결 방법 숙지는 개발 과정에서 발생하는 다양한 이슈에 효과적으로 대응하는 데 도움이 될 것입니다.

본 가이드가 보다 쉬운 온보딩과 앞으로의 업무 수행에 든든한 기초가 되기를 바라요. 서버 환경은 지속적으로 변화하고 개선될 수 있으므로, 궁금한 점이나 더 필요한 정보가 있다면 언제든지 저한테 문의해 주시기 바랍니다.

부록

A.1. 남산 DID 프로젝트 에셋 서빙을 위한 Nginx server 블록 핵심 설정 예시

다음은 본문 4.2.3절에서 설명된 Nginx 설정을 요약한 핵심 예시입니다. 실제 적용 시에는 전체 nginx.conf 또는 해당 server 블록의 컨텍스트를 고려해야 합니다. 

server {
    listen 8080;
    server_name wizinfo.iptime.co.kr;

    root /var/www/html; # 기본 웹 루트 8080 포트에 namsan 웹뭉치를 서비스 하는 것을 말해요.
    index index.php index.html index.htm; # 기본 인덱스 파일

    # 남산 DID 백엔드 PHP 처리 (예시: /namsan/ 경로)
    location ~ ^/namsan/.*\.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock; # 실제 PHP-FPM 소켓 경로로 수정
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        # try_files $uri =404; # 필요에 따라 추가
    }

    # 프론트엔드 에셋 파일 서빙 (/namsan-assets/ URL 경로)
    location /namsan-assets/ {
        alias /var/www/namsan-assets/; # 실제 에셋 파일 시스템 경로
        autoindex off; # 디렉토리 리스팅 방지

        # 허용된 에셋 확장자 처리 및 캐싱
        location ~* \.(?:jpg|jpeg|gif|png|ico|svg|webp|css|js|woff|woff2|ttf|eot|otf|mp4|webm|json)$ {
            try_files $uri =404; # 파일 없으면 404
            expires 30d; # 브라우저 캐시 30일
            add_header Cache-Control "public, no-transform";
            access_log off; # 접근 로그 비활성화 (선택 사항)
        }

        # /namsan-assets/ 내 기타 파일 접근 차단 (PHP 실행 방지 등)
        location ~ /namsan-assets/ {
            deny all;
            return 403; # 또는 404
        }
    }

    # 남산 DID 프로젝트 로그 파일 직접 접근 차단 (예시: /namsan/log/ 경로)
    location ~ ^/namsan/log/.*\.log$ {
        deny all;
        return 403;
    }

    # 기타 애플리케이션 루트 경로 처리
    location / {
        try_files $uri $uri/ /index.php?$args; # 일반적인 PHP 애플리케이션 라우팅
    }
}

주의: 위 설정은 예시이며, 실제 서버 환경의 PHP 버전, FPM 소켓 경로, 전체 Nginx 구성 등 지금의 설정과 다를 수 있습니다.


A.2. 주요 용어 설명

SSH (Secure Shell):
원격 컴퓨터에 안전하게 접속하여 명령을 실행하거나 파일을 전송할 수 있는 네트워크 프로토콜 및 관련 도구.
SFTP (SSH File Transfer Protocol):
SSH 연결을 통해 파일을 안전하게 전송하는 프로토콜. FTP와 유사하지만 암호화된 채널을 사용.
Nginx (엔진엑스):
고성능 웹 서버, 리버스 프록시, 로드 밸런서 등으로 사용되는 오픈소스 소프트웨어.
Ubuntu Server:
서버 환경을 위해 설계된 Linux 배포판.
PostgreSQL:
강력한 기능을 제공하는 오픈소스 객체-관계형 데이터베이스 시스템(ORDBMS).
AJAX (Asynchronous JavaScript and XML):
웹 페이지 전체를 새로고침하지 않고 비동기적으로 서버와 데이터를 교환하는 기술.
CLI (Command Line Interface):
텍스트 기반으로 컴퓨터와 상호작용하는 인터페이스. 터미널을 통해 사용.
Root (사용자):
Linux/Unix 시스템에서 모든 권한을 가진 최상위 관리자 계정.
sudo (Superuser Do):
다른 사용자의 권한(일반적으로 root)으로 명령을 실행하도록 하는 명령어.
chmod (Change Mode):
파일이나 디렉토리의 접근 권한을 변경하는 Linux 명령어.
chown (Change Owner):
파일이나 디렉토리의 소유자 및 그룹을 변경하는 Linux 명령어.
alias (Nginx 지시어):
Nginx 설정에서 특정 URL 경로를 다른 파일 시스템 경로로 매핑하는 데 사용되는 지시어.
location (Nginx 지시어):
Nginx 설정에서 특정 URL 패턴에 대한 요청 처리 방법을 정의하는 블록.
www-data:
Debian/Ubuntu 계열 Linux에서 Nginx나 Apache 같은 웹 서버가 실행될 때 사용하는 기본 사용자 및 그룹 이름.
try_files (Nginx 지시어):
요청된 URI에 대해 순서대로 파일 존재 여부를 확인하고, 첫 번째로 발견된 파일을 제공하거나 대체 처리를 하는 지시어.
autoindex (Nginx 지시어):
특정 디렉토리로 요청이 왔을 때, 해당 디렉토리의 파일 목록을 보여줄지 여부를 설정하는 지시어. (on이면 목록 표시, off이면 금지)
expires (Nginx 지시어):
HTTP 응답 헤더에 Expires 및 Cache-Control 정보를 추가하여 브라우저 캐싱 기간을 설정하는 지시어.