@extends('layouts.app') @section('title', '서버지식') @push('styles') @endpush @section('content')
아카데미 서버지식

서버지식

서버 협업에 필요한 핵심 지식 — 비개발자도 이해할 수 있는 실전 가이드

서버실과 사용자 연결 일러스트
{{-- ============================================================ --}} {{-- 1. 서버란 무엇인가 --}} {{-- ============================================================ --}}

1 서버란 무엇인가

서버의 정의

서버(Server)란 네트워크를 통해 다른 컴퓨터(클라이언트)에게 서비스를 제공하는 컴퓨터다. 우리가 웹 브라우저에서 주소를 입력하면, 그 요청을 받아 처리하고 결과를 돌려주는 역할을 한다.

비유: 24시간 영업하는 식당

서버는 24시간 문을 닫지 않는 식당과 같다. 손님(사용자)이 언제 와도 주문(요청)을 받고, 요리(처리)해서 내놓는다(응답). 식당이 문을 닫으면 손님이 밥을 못 먹듯, 서버가 꺼지면 웹사이트에 접속할 수 없다.

일반 PC

내가 사용하는 컴퓨터
필요할 때만 켠다

서버

다른 사람에게 서비스 제공
365일 24시간 가동

클라이언트

서버에 요청하는 쪽
웹 브라우저, 앱 등

SAM 서버 구조

비유: 하나의 건물에 5개 가게 입점

SAM 서버는 하나의 건물(서버 컴퓨터)에 여러 가게(서비스)가 입점한 것과 같다. 각 가게는 독립적으로 운영되지만, 건물의 전기(CPU)와 수도(메모리)를 공유한다.

SAM 5개 서비스 건물 지도

SAM 서버 구조 — 건물 지도

서비스 비유 역할
Nginx 입구 안내 데스크 요청을 받아 적절한 서비스로 안내
PHP-FPM 요리사 팀 실제 코드를 실행하여 결과를 만들어냄
MySQL 냉장고 (재료 창고) 데이터를 저장하고 꺼내주는 데이터베이스
MNG 관리자 사무실 직원들이 사용하는 관리 화면
API 택배 발송실 앱/외부에 데이터를 전달하는 백엔드

요청의 여정

사용자가 웹 브라우저에 https://sam.jooil.co.kr 을 입력하면 어떤 일이 벌어지는지 따라가보자.

요청 흐름도: 브라우저→Nginx→PHP→DB

요청의 여정 — URL 입력부터 화면 표시까지

1

URL 입력

브라우저가 서버에 요청 전송

2

Nginx 수신

안내 데스크가 요청을 분류

3

PHP 처리

요리사가 코드를 실행

4

DB 조회

냉장고에서 재료(데이터) 꺼냄

5

화면 표시

완성된 페이지를 브라우저에 전달

{{-- ============================================================ --}} {{-- 2. 파일 권한과 소유자 (핵심!) --}} {{-- ============================================================ --}}

2 파일 권한과 소유자 핵심!

사용자와 그룹

비유: 회사 직원과 부서

Linux에서 사용자(User)는 회사의 직원, 그룹(Group)은 부서와 같다. 한 직원이 여러 부서에 소속될 수 있듯, 한 사용자도 여러 그룹에 속할 수 있다.

Linux 사용자/그룹 = 회사 조직도

사용자와 그룹 — 회사 조직도

Linux 회사 비유 SAM에서의 역할
root 건물 관리인 (만능 열쇠) 시스템 최고 관리자. 모든 권한 보유
pro 팀장 (개발팀 사무실 열쇠) 배포/관리 담당. SSH 접속 계정
www-data 업무 처리 직원 (작업실 열쇠) 웹 서버(Nginx/PHP)가 사용하는 계정

중요! prowww-data가 같은 그룹에 있어야 서로의 파일을 읽고 쓸 수 있다. 그룹이 다르면 "열쇠가 안 맞아서 사무실에 못 들어가는" 상황이 발생한다.

파일 권한 읽기 (rwx)

Linux에서 ls -la 명령을 실행하면 이런 문자열이 보인다:

drwxrwxr-x 2 pro www-data 4096 Feb 23 10:00 storage
drwxrwxr-x 해독 인포그래픽

권한 문자열 해독법

비유: 서류함의 스티커

파일에 붙은 권한은 서류함에 붙은 스티커와 같다. r(Read) = 열람 가능, w(Write) = 수정 가능, x(Execute) = 사용/실행 가능. 스티커가 없으면 해당 행위가 불가능하다.

위치 문자 의미 비유
1번째 d 디렉토리(폴더) 서류함 vs 서류 한 장
2~4번째 rwx 소유자(Owner) 권한 서류함 담당자: 열람+수정+사용
5~7번째 rwx 그룹(Group) 권한 같은 부서 직원: 열람+수정+사용
8~10번째 r-x 기타(Others) 권한 다른 부서 직원: 열람+사용만 가능

숫자로 표현하기

각 권한을 숫자로 환산: r=4, w=2, x=1

rwx = 7

4+2+1

rw- = 6

4+2+0

r-x = 5

4+0+1

r-- = 4

4+0+0

따라서 rwxrwxr-x = 775, rw-r--r-- = 644

umask란 무엇인가

비유: 새 서류 만들 때 기본 스티커

umask는 새 파일/폴더를 만들 때 기본적으로 어떤 권한을 빼는지 정하는 설정이다. 신입 직원이 서류를 만들면 회사 규정상 기본 스티커가 자동으로 붙는 것과 같다.

umask 계산법: 666 - 022 = 644

umask 계산 과정

계산법: 기본 권한에서 umask를 빼면 실제 권한이 된다.

파일 기본값:   666 (rw-rw-rw-)
umask 값:   - 022 (----w--w-)
─────────────────────────
실제 권한:    644 (rw-r--r--)

폴더 기본값:  777 (rwxrwxrwx)
umask 값:   - 022 (----w--w-)
─────────────────────────
실제 권한:    755 (rwxr-xr-x)

문제가 되는 경우: umask가 022이면 새 파일의 그룹 쓰기 권한이 빠진다. 즉 pro 계정이 만든 파일을 www-data가 수정할 수 없게 된다!

해결책: umask를 002로 설정하면 그룹 쓰기 권한이 유지된다. 666 - 002 = 664 (rw-rw-r--) → 같은 그룹이면 서로 수정 가능!

실전 사고 사례 2026-02-23

umask 사고 — 자동 배포 실패

개발팀장이 서버 폴더 권한을 조정한 후, 자동 배포가 실패한 사건. 비개발자인 대표가 원인을 파악할 수 없었던 실제 사례다.

사고 타임라인 5단계

사고 타임라인 — 5단계

1

폴더 권한 변경

팀장이 chmod로 폴더 권한을 조정. 목적: 보안 강화

2

umask 영향 시작

계정의 umask(022)가 적용되어 새로 생성되는 파일의 그룹 쓰기 권한 제거

3

git pull 실행

자동 배포 스크립트(Hook)가 git pull 실행. 새 파일들이 644 권한으로 생성됨

4

Permission Denied 발생

www-data(웹 서버)가 새 파일을 읽기는 되지만 쓰기 불가. 캐시/로그 작성 실패

5

배포 실패 — 서비스 장애

사용자들이 페이지 접속 시 오류 발생. 대표는 "무엇이 잘못됐는지" 파악 불가

교훈

  • 서버 권한 변경은 반드시 영향 범위를 확인한 후 실행해야 한다
  • umask 설정이 배포 전체에 연쇄적으로 영향을 준다
  • 비개발자도 기본 원리를 알아야 "무엇이 잘못됐는지" 파악할 수 있다
{{-- ============================================================ --}} {{-- 3. Git과 배포의 원리 --}} {{-- ============================================================ --}}

3 Git과 배포의 원리

Git이 하는 일

비유: 구글 드라이브 버전 기록

Git은 코드의 변경 이력을 기록하는 시스템이다. 구글 드라이브에서 "버전 기록"을 클릭하면 과거 버전을 볼 수 있듯, Git은 코드의 모든 변경 사항을 기록하고 필요하면 과거로 되돌릴 수 있다.

구글 드라이브

파일 하나의 버전 관리
자동 저장

Git

프로젝트 전체의 버전 관리
의도적으로 저장(commit)

Gitea

Git 저장소 호스팅
(GitHub의 자체 버전)

git push → 서버 반영

비유: 우체국 택배 시스템

코드를 수정하고 git push하는 것은 택배를 보내는 것과 같다. 개발자(발신자)가 코드(상품)를 포장해서 Gitea(우체국)에 맡기면, 서버(수신자)가 받아서 적용(개봉)한다.

git push → Gitea → 서버 pull 택배 비유

코드 배포 흐름 — 택배 비유

개발자 PC                  Gitea                     운영 서버
    │                        │                          │
    ├── git push ──────────→ │                          │
    │   (택배 발송)          ├── Hook 자동 실행 ───────→ │
    │                        │   (도착 알림)             ├── git pull
    │                        │                          │   (택배 수령)
    │                        │                          ├── 코드 적용
    │                        │                          │   (상품 개봉)

자동 배포 Hook

Hook(훅)은 특정 이벤트가 발생했을 때 자동으로 실행되는 스크립트다. SAM에서는 Gitea에 코드가 올라오면(push) post-update 훅이 실행되어 서버에 자동 배포한다.

Hook 동작 흐름 + 권한 체크 포인트

Hook 동작 흐름과 권한 체크 포인트

post-update Hook 동작 순서:

1. 개발자가 git push 실행
2. Gitea가 코드를 수신
3. post-update 훅이 pull_mng.sh 호출
4. pull_mng.sh가 운영 서버에 SSH 접속
5. git pull 로 최신 코드 다운로드     ← ⚠️ 이때 umask 적용!
6. composer install (패키지 설치)
7. config:clear (캐시 초기화)
8. 배포 완료

주의! 5단계에서 git pull로 새 파일이 생성될 때, 실행하는 사용자의 umask 설정이 적용된다. umask가 잘못되면 여기서 권한 문제가 시작된다.

왜 배포가 깨지는가

Permission denied 오류가 발생하는 3가지 전형적 원인:

1

잘못된 소유자 (Owner)

root가 만든 파일을 www-data가 수정하려고 할 때. 마치 사장님 서류함을 일반 직원이 열려는 것과 같다.

2

잘못된 umask (권한 마스크)

umask 022로 만든 파일(644)은 그룹 쓰기가 안 됨. 같은 부서인데 서류함에 "수정 금지" 스티커가 붙은 것.

3

그룹 불일치 (Group mismatch)

prowww-data가 다른 그룹일 때. 다른 부서 직원이 접근하려는 것과 같다.

{{-- ============================================================ --}} {{-- 4. 서버 협업 필수 규칙 --}} {{-- ============================================================ --}}

4 서버 협업 필수 규칙

절대 하면 안 되는 것

금지 행위 경고 카드

절대 금지 행위 4가지

chmod 777

모든 사용자에게 모든 권한 부여. 보안이 완전히 무너진다.

비유: 회사 모든 문을 열어놓기 — 도둑도 들어올 수 있음

chown root

파일 소유자를 root로 변경. 웹 서버가 접근 불가능해진다.

비유: 서류함 담당을 사장님으로 변경 — 일반 직원 접근 차단

서버 파일 직접 수정

서버에서 직접 코드를 편집하면 Git 이력이 꼬이고, 다음 배포 시 충돌 발생.

비유: 원본 서류를 복사본 없이 직접 수정 — 되돌리기 불가

rm -rf (대량 삭제)

파일/폴더를 경고 없이 영구 삭제. 복구 불가능.

비유: 서류함 채로 소각 — 안에 뭐가 있었는지도 모름

소유자 변경의 위험성

비유: 서류함 담당자 변경

파일의 소유자를 변경하면(chown), 기존 담당자가 해당 파일에 접근할 수 없게 될 수 있다. 마치 서류함 담당을 A에서 B로 바꾸면, A가 더 이상 그 서류함을 열 수 없는 것과 같다.

# 위험한 예시: 소유자를 root로 변경
sudo chown root:root /home/webservice/mng/storage/logs/
# → www-data가 로그 파일을 쓸 수 없게 됨 → 500 에러 발생!

# 올바른 소유자 설정:
sudo chown pro:www-data /home/webservice/mng/storage/logs/
# → pro가 소유하고, www-data 그룹이 접근 가능

올바른 문제 해결 절차

비유: 엘리베이터 고장 → 관리실 연락

엘리베이터가 고장나면 직접 고치려 하지 않고 관리실에 연락하는 것처럼, 서버 문제가 생기면 직접 고치려 하지 말고 개발팀에 연락해야 한다.

올바른 절차 4단계 흐름도

올바른 문제 해결 4단계

1

증상 확인

어떤 화면에서 무슨 오류가 나는지 스크린샷 촬영

2

팀장에게 보고

스크린샷과 함께 언제부터 발생했는지 전달

3

원인 분석

개발팀이 로그 확인, 권한 점검, 설정 검토

4

안전 조치

검증된 방법으로 수정, 결과 확인 후 보고

긴급 상황 체크리스트

서버 장애 발생 시, 대표(비개발자)가 할 수 있는 것과 할 수 없는 것:

할 수 있는 것

  • 오류 화면 스크린샷 찍기
  • 발생 시간/상황 기록
  • 다른 브라우저/기기에서 재현 확인
  • 개발팀장에게 즉시 연락
  • 안전한 조회 명령어 실행 (ls, cat 등)

절대 하면 안 되는 것

  • 서버 파일 직접 수정/삭제
  • chmod, chown 명령어 실행
  • 서비스 재시작 (systemctl restart)
  • Nginx/PHP 설정 변경
  • sudo 명령어 실행
{{-- ============================================================ --}} {{-- 5. 핵심 명령어 사전 --}} {{-- ============================================================ --}}

5 핵심 명령어 사전

안전한 명령어 안전

다음 명령어들은 읽기 전용이므로 서버에 영향을 주지 않는다. 자유롭게 사용 가능.

안전 vs 위험 명령어 대비표

안전(초록) vs 위험(빨강) 명령어 대비표

명령어 하는 일 비유
ls 폴더 내용 목록 보기 서류함 목차 훑어보기
cat 파일 내용 보기 서류 한 장 읽기
whoami 현재 로그인 계정 확인 내 사원증 확인
df -h 디스크 사용량 확인 창고 남은 공간 확인
docker ps 실행 중인 컨테이너 확인 영업 중인 가게 확인
tail -f 로그파일 로그 실시간 보기 CCTV 실시간 모니터링
git status 변경된 파일 목록 확인 수정된 서류 확인
free -m 메모리 사용량 확인 직원 업무량 확인

위험한 명령어 위험

다음 명령어들은 서버를 변경하므로 반드시 개발팀장의 확인 후 사용해야 한다.

명령어 하는 일 위험도 비유
rm -rf 파일/폴더 영구 삭제 극위험 서류함 채로 소각
chmod 파일 권한 변경 고위험 서류함 스티커 변경
chown 파일 소유자 변경 고위험 서류함 담당자 교체
kill -9 프로세스 강제 종료 고위험 직원 즉시 해고 (인수인계 없이)
sudo 관리자 권한으로 실행 주의 만능 열쇠 사용
systemctl restart 서비스 재시작 주의 가게 문 닫았다 열기

자주 묻는 질문 (FAQ)

Q. 사이트가 갑자기 느려졌어요. 뭘 확인해야 하나요?

A. 서버 리소스를 확인한다:

free -m          # 메모리 사용량 확인
df -h            # 디스크 공간 확인
docker ps        # 컨테이너 상태 확인

메모리가 부족하거나 디스크가 가득 찼으면 개발팀장에게 보고한다.

Q. 502 Bad Gateway 에러가 나요.

A. PHP-FPM(요리사 팀)이 동작하지 않는 상태. "요리사가 전부 퇴근한 식당"이다.

원인:

  • PHP-FPM 서비스가 죽었음 (메모리 부족 등)
  • Nginx 설정 오류로 PHP-FPM에 연결 실패
  • 서버 자체 과부하

→ 직접 해결하지 말고 개발팀장에게 즉시 연락!

Q. 코드를 push했는데 서버에 반영이 안 돼요.

A. 자동 배포(Hook)가 실패한 것. 세 가지를 확인한다:

  1. Hook 오류 — Gitea의 Hook 로그에서 에러 확인
  2. Permission denied — 파일 권한 문제 (이 문서의 섹션 2 참고)
  3. SSH 연결 실패 — 서버 SSH 포트나 키 문제
# 서버에서 직접 확인 (안전한 명령어)
git status       # 현재 상태 확인
git log --oneline -5  # 최근 커밋 확인
Q. Permission denied 에러가 나요.

A. "배지(권한)가 없어서 출입통제구역에 못 들어가는" 상황. 세 가지를 확인한다:

  1. 파일 소유자가 누구인지 확인: ls -la 파일경로
  2. 파일 권한이 올바른지 확인: stat 파일경로
  3. 현재 사용자가 누구인지 확인: whoami

확인 결과를 개발팀장에게 전달하면 빠른 해결이 가능하다.

Q. 서버 디스크가 가득 찼대요.

A. "창고가 가득 차서 새 물건을 넣을 수 없는" 상태.

# 디스크 사용량 확인 (안전)
df -h

# 큰 파일 찾기 (안전)
du -sh /home/webservice/*/storage/logs/

보통 로그 파일이 너무 커진 경우. 로그 정리는 개발팀장이 진행한다.

핵심 정리

서버는 "24시간 영업하는 회사 건물"이다. 건물 안의 서류함(파일)에는 담당자(소유자)와 스티커(권한)가 붙어있다. 스티커가 맞아야 서류를 보거나 수정할 수 있다. 건물에 문제가 생기면 직접 고치려 하지 말고, 관리실(개발팀)에 연락하는 것이 올바른 절차다. 안전한 명령어(ls, cat, whoami)로 상황을 파악하고, 위험한 명령어(rm, chmod, chown)는 절대 혼자 사용하지 않는다.

@include('components.academy-glossary', ['domain' => 'server-knowledge']) @endsection