서버지식 백과사전
+서버 협업에 필요한 핵심 지식 — 비개발자도 이해할 수 있는 실전 가이드
+ }})
+ + + 목차 보기 +
+ ++ 1 + 서버란 무엇인가 +
+ + ++ + 서버의 정의 +
++ 서버(Server)란 네트워크를 통해 다른 컴퓨터(클라이언트)에게 서비스를 제공하는 컴퓨터다. + 우리가 웹 브라우저에서 주소를 입력하면, 그 요청을 받아 처리하고 결과를 돌려주는 역할을 한다. +
+비유: 24시간 영업하는 식당
++ 서버는 24시간 문을 닫지 않는 식당과 같다. 손님(사용자)이 언제 와도 주문(요청)을 받고, 요리(처리)해서 내놓는다(응답). + 식당이 문을 닫으면 손님이 밥을 못 먹듯, 서버가 꺼지면 웹사이트에 접속할 수 없다. +
+일반 PC
+내가 사용하는 컴퓨터
필요할 때만 켠다
서버
+다른 사람에게 서비스 제공
365일 24시간 가동
클라이언트
+서버에 요청하는 쪽
웹 브라우저, 앱 등
+ + SAM 서버 구조 +
+비유: 하나의 건물에 5개 가게 입점
++ SAM 서버는 하나의 건물(서버 컴퓨터)에 여러 가게(서비스)가 입점한 것과 같다. + 각 가게는 독립적으로 운영되지만, 건물의 전기(CPU)와 수도(메모리)를 공유한다. +
+ }})
+ SAM 서버 구조 — 건물 지도
+| 서비스 | +비유 | +역할 | +
|---|---|---|
| Nginx | +입구 안내 데스크 | +요청을 받아 적절한 서비스로 안내 | +
| PHP-FPM | +요리사 팀 | +실제 코드를 실행하여 결과를 만들어냄 | +
| MySQL | +냉장고 (재료 창고) | +데이터를 저장하고 꺼내주는 데이터베이스 | +
| MNG | +관리자 사무실 | +직원들이 사용하는 관리 화면 | +
| API | +택배 발송실 | +앱/외부에 데이터를 전달하는 백엔드 | +
+ + 요청의 여정 +
+
+ 사용자가 웹 브라우저에 https://sam.jooil.co.kr 을 입력하면 어떤 일이 벌어지는지 따라가보자.
+
 }})
+ 요청의 여정 — URL 입력부터 화면 표시까지
+1
+URL 입력
+브라우저가 서버에 요청 전송
+2
+Nginx 수신
+안내 데스크가 요청을 분류
+3
+PHP 처리
+요리사가 코드를 실행
+4
+DB 조회
+냉장고에서 재료(데이터) 꺼냄
+5
+화면 표시
+완성된 페이지를 브라우저에 전달
++ 2 + 파일 권한과 소유자 + 핵심! +
+ + ++ + 사용자와 그룹 +
+비유: 회사 직원과 부서
++ Linux에서 사용자(User)는 회사의 직원, 그룹(Group)은 부서와 같다. + 한 직원이 여러 부서에 소속될 수 있듯, 한 사용자도 여러 그룹에 속할 수 있다. +
+ }})
+ 사용자와 그룹 — 회사 조직도
+| Linux | +회사 비유 | +SAM에서의 역할 | +
|---|---|---|
| root | +건물 관리인 (만능 열쇠) | +시스템 최고 관리자. 모든 권한 보유 | +
| pro | +팀장 (개발팀 사무실 열쇠) | +배포/관리 담당. SSH 접속 계정 | +
| www-data | +업무 처리 직원 (작업실 열쇠) | +웹 서버(Nginx/PHP)가 사용하는 계정 | +
+ 중요! pro와 www-data가 같은 그룹에 있어야 서로의 파일을 읽고 쓸 수 있다.
+ 그룹이 다르면 "열쇠가 안 맞아서 사무실에 못 들어가는" 상황이 발생한다.
+
+ + 파일 권한 읽기 (rwx) +
+
+ Linux에서 ls -la 명령을 실행하면 이런 문자열이 보인다:
+
drwxrwxr-x 2 pro www-data 4096 Feb 23 10:00 storage
+  }})
+ 권한 문자열 해독법
+비유: 서류함의 스티커
++ 파일에 붙은 권한은 서류함에 붙은 스티커와 같다. + 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 계산 과정
+계산법: 기본 권한에서 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단계
+ + +폴더 권한 변경
+팀장이 chmod로 폴더 권한을 조정. 목적: 보안 강화
umask 영향 시작
+계정의 umask(022)가 적용되어 새로 생성되는 파일의 그룹 쓰기 권한 제거
+git pull 실행
+자동 배포 스크립트(Hook)가 git pull 실행. 새 파일들이 644 권한으로 생성됨
Permission Denied 발생
+www-data(웹 서버)가 새 파일을 읽기는 되지만 쓰기 불가. 캐시/로그 작성 실패
배포 실패 — 서비스 장애
+사용자들이 페이지 접속 시 오류 발생. 대표는 "무엇이 잘못됐는지" 파악 불가
+교훈
+-
+
- 서버 권한 변경은 반드시 영향 범위를 확인한 후 실행해야 한다 +
- umask 설정이 배포 전체에 연쇄적으로 영향을 준다 +
- 비개발자도 기본 원리를 알아야 "무엇이 잘못됐는지" 파악할 수 있다 +
+ 3 + Git과 배포의 원리 +
+ + ++ + Git이 하는 일 +
+비유: 구글 드라이브 버전 기록
++ Git은 코드의 변경 이력을 기록하는 시스템이다. + 구글 드라이브에서 "버전 기록"을 클릭하면 과거 버전을 볼 수 있듯, + Git은 코드의 모든 변경 사항을 기록하고 필요하면 과거로 되돌릴 수 있다. +
+구글 드라이브
+파일 하나의 버전 관리
자동 저장
Git
+프로젝트 전체의 버전 관리
의도적으로 저장(commit)
Gitea
+Git 저장소 호스팅
(GitHub의 자체 버전)
+ + git push → 서버 반영 +
+비유: 우체국 택배 시스템
+
+ 코드를 수정하고 git push하는 것은 택배를 보내는 것과 같다.
+ 개발자(발신자)가 코드(상품)를 포장해서 Gitea(우체국)에 맡기면,
+ 서버(수신자)가 받아서 적용(개봉)한다.
+
 }})
+ 코드 배포 흐름 — 택배 비유
+개발자 PC Gitea 운영 서버 + │ │ │ + ├── git push ──────────→ │ │ + │ (택배 발송) ├── Hook 자동 실행 ───────→ │ + │ │ (도착 알림) ├── git pull + │ │ │ (택배 수령) + │ │ ├── 코드 적용 + │ │ │ (상품 개봉)+
+ + 자동 배포 Hook +
+
+ Hook(훅)은 특정 이벤트가 발생했을 때 자동으로 실행되는 스크립트다.
+ SAM에서는 Gitea에 코드가 올라오면(push) post-update 훅이 실행되어 서버에 자동 배포한다.
+
 }})
+ 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가지 전형적 원인:
+
잘못된 소유자 (Owner)
+
+ root가 만든 파일을 www-data가 수정하려고 할 때.
+ 마치 사장님 서류함을 일반 직원이 열려는 것과 같다.
+
잘못된 umask (권한 마스크)
++ umask 022로 만든 파일(644)은 그룹 쓰기가 안 됨. + 같은 부서인데 서류함에 "수정 금지" 스티커가 붙은 것. +
+그룹 불일치 (Group mismatch)
+
+ pro와 www-data가 다른 그룹일 때.
+ 다른 부서 직원이 접근하려는 것과 같다.
+
+ 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단계
+1
+증상 확인
+어떤 화면에서 무슨 오류가 나는지 스크린샷 촬영
+2
+팀장에게 보고
+스크린샷과 함께 언제부터 발생했는지 전달
+3
+원인 분석
+개발팀이 로그 확인, 권한 점검, 설정 검토
+4
+안전 조치
+검증된 방법으로 수정, 결과 확인 후 보고
++ + 긴급 상황 체크리스트 +
+서버 장애 발생 시, 대표(비개발자)가 할 수 있는 것과 할 수 없는 것:
++ ✓ + 할 수 있는 것 +
+-
+
- + ✓ + 오류 화면 스크린샷 찍기 + +
- + ✓ + 발생 시간/상황 기록 + +
- + ✓ + 다른 브라우저/기기에서 재현 확인 + +
- + ✓ + 개발팀장에게 즉시 연락 + +
- + ✓ + 안전한 조회 명령어 실행 (ls, cat 등) + +
+ ✕ + 절대 하면 안 되는 것 +
+-
+
- + ✕ + 서버 파일 직접 수정/삭제 + +
- + ✕ + chmod, chown 명령어 실행 + +
- + ✕ + 서비스 재시작 (systemctl restart) + +
- + ✕ + Nginx/PHP 설정 변경 + +
- + ✕ + sudo 명령어 실행 + +
+ 5 + 핵심 명령어 사전 +
+ + ++ + 안전한 명령어 + 안전 +
++ 다음 명령어들은 읽기 전용이므로 서버에 영향을 주지 않는다. 자유롭게 사용 가능. +
+ }})
+ 안전(초록) 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)가 실패한 것. 세 가지를 확인한다:
+-
+
- Hook 오류 — Gitea의 Hook 로그에서 에러 확인 +
- Permission denied — 파일 권한 문제 (이 문서의 섹션 2 참고) +
- SSH 연결 실패 — 서버 SSH 포트나 키 문제 +
# 서버에서 직접 확인 (안전한 명령어) +git status # 현재 상태 확인 +git log --oneline -5 # 최근 커밋 확인+
+ Q. Permission denied 에러가 나요. +
+A. "배지(권한)가 없어서 출입통제구역에 못 들어가는" 상황. 세 가지를 확인한다:
+-
+
- 파일 소유자가 누구인지 확인:
ls -la 파일경로
+ - 파일 권한이 올바른지 확인:
stat 파일경로
+ - 현재 사용자가 누구인지 확인:
whoami
+
확인 결과를 개발팀장에게 전달하면 빠른 해결이 가능하다.
++ Q. 서버 디스크가 가득 찼대요. +
+A. "창고가 가득 차서 새 물건을 넣을 수 없는" 상태.
+# 디스크 사용량 확인 (안전) +df -h + +# 큰 파일 찾기 (안전) +du -sh /home/webservice/*/storage/logs/+
보통 로그 파일이 너무 커진 경우. 로그 정리는 개발팀장이 진행한다.
+핵심 정리
++ 서버는 "24시간 영업하는 회사 건물"이다. + 건물 안의 서류함(파일)에는 담당자(소유자)와 스티커(권한)가 붙어있다. + 스티커가 맞아야 서류를 보거나 수정할 수 있다. + 건물에 문제가 생기면 직접 고치려 하지 말고, 관리실(개발팀)에 연락하는 것이 올바른 절차다. + 안전한 명령어(ls, cat, whoami)로 상황을 파악하고, 위험한 명령어(rm, chmod, chown)는 절대 혼자 사용하지 않는다. +
+