From 0d8d5aa8ef1d8b646f88e2ec52de2393b7b7e585 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EA=B9=80=EB=B3=B4=EA=B3=A4?= Date: Mon, 23 Feb 2026 09:43:43 +0900 Subject: [PATCH] =?UTF-8?q?feat:=20[academy]=20=EC=84=9C=EB=B2=84=EC=A7=80?= =?UTF-8?q?=EC=8B=9D=20=EB=B0=B1=EA=B3=BC=EC=82=AC=EC=A0=84=20=ED=8E=98?= =?UTF-8?q?=EC=9D=B4=EC=A7=80=20=EC=B6=94=EA=B0=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - AcademyController에 serverKnowledge() 메서드 추가 - /academy/server-knowledge 라우트 등록 - 그린 테마 Blade 뷰 (5대 섹션, 18소 섹션) - SVG 이미지 12장 생성 - 이미지 생성 프롬프트 문서 작성 --- app/Http/Controllers/AcademyController.php | 9 + .../views/academy/server-knowledge.blade.php | 1347 +++++++++++++++++ routes/web.php | 1 + 3 files changed, 1357 insertions(+) create mode 100644 resources/views/academy/server-knowledge.blade.php diff --git a/app/Http/Controllers/AcademyController.php b/app/Http/Controllers/AcademyController.php index 844f2e3c..f1e8a354 100644 --- a/app/Http/Controllers/AcademyController.php +++ b/app/Http/Controllers/AcademyController.php @@ -25,4 +25,13 @@ public function itPlanning(Request $request): View|Response return view('academy.it-planning'); } + + public function serverKnowledge(Request $request): View|Response + { + if ($request->header('HX-Request')) { + return response('', 200)->header('HX-Redirect', route('academy.server-knowledge')); + } + + return view('academy.server-knowledge'); + } } diff --git a/resources/views/academy/server-knowledge.blade.php b/resources/views/academy/server-knowledge.blade.php new file mode 100644 index 00000000..9336c32c --- /dev/null +++ b/resources/views/academy/server-knowledge.blade.php @@ -0,0 +1,1347 @@ +@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)가 사용하는 계정
+
+
+

+ 중요! pro와 www-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)

+

+ pro와 www-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. +
  2. Permission denied — 파일 권한 문제 (이 문서의 섹션 2 참고)
    3. +
  3. SSH 연결 실패 — 서버 SSH 포트나 키 문제
    4. +
+
+ 
# 서버에서 직접 확인 (안전한 명령어)
+git status       # 현재 상태 확인
+git log --oneline -5  # 최근 커밋 확인
+
+
+
+ +
+ + Q. Permission denied 에러가 나요. + +
+

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

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

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

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

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

+
+ 
# 디스크 사용량 확인 (안전)
+df -h
+
+# 큰 파일 찾기 (안전)
+du -sh /home/webservice/*/storage/logs/
+
+

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

+
+
+
+ + +
+

핵심 정리

+

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

+
+
+
+
+ +
+
+
+ + +
+ + +
+ + + + +@endsection diff --git a/routes/web.php b/routes/web.php index 3dc62d30..5e4a9278 100644 --- a/routes/web.php +++ b/routes/web.php @@ -1463,6 +1463,7 @@ Route::middleware('auth')->prefix('academy')->name('academy.')->group(function () { Route::get('/fire-shutter', [\App\Http\Controllers\AcademyController::class, 'fireShutter'])->name('fire-shutter'); Route::get('/it-planning', [\App\Http\Controllers\AcademyController::class, 'itPlanning'])->name('it-planning'); + Route::get('/server-knowledge', [\App\Http\Controllers\AcademyController::class, 'serverKnowledge'])->name('server-knowledge'); }); // SAM E-Sign - 인증 필요