otopligrm 님의 블로그

VDI 시험 감독 대시보드 프론트/백엔드/DB 인수인계 문서

otopligrm — Mon, 25 May 2026 11:44:33 +0900

1. 이원준 인수인계 by GPT와 함께 만듬

현재까지 작업한 내용은 VDI 시험 감독 대시보드를 실제 DB와 연결하기 위한 프론트엔드/백엔드 API 개발 작업이다.

하지만 실제 운영에서는 학생 로그인 상태, 좌석 상태, 시험 정보, 교수 정보가 모두 DB에 저장되어야 하기 때문에 백엔드 API와 DB를 연결하는 구조로 전환했다.

이번 인수인계의 핵심은 다음이다.

기존 프론트 화면이 어떤 데이터를 필요로 하는지
그 데이터를 백엔드 API가 어떤 형식으로 내려주는지
백엔드 API가 DB의 어떤 테이블을 조회/수정하는지
학생이 VDI에 접속해서 로그인했을 때 좌석 상태가 어떻게 바뀌는지
대시보드가 어떻게 미접속/접속중 상태를 표시하는지
앞으로 DB관리자가 어떤 부분을 관리해야 하는지

2. 전체 구조 요약

현재 구조는 다음 흐름으로 동작한다.

[교수 정보 입력 페이지]
        ↓
교수명 / 교번 / 학과 입력
        ↓
백엔드 API 호출
        ↓
ACCOUNT / PROFESSOR_PROFILE 저장 또는 조회

[시험 생성 페이지]
        ↓
과목명 / 시험 유형 / 장소 / 시간 / 정원 입력
        ↓
백엔드 API 호출
        ↓
EXAM_INFO 생성
        ↓
VDI 이름 / IP / 좌석 매핑 테이블 조회
        ↓
VDI_SESSION 초기 생성
        ↓
초기 상태는 OUT, 즉 미접속

[학생 VDI 로그인 페이지]
        ↓
학생이 VDI 접속
        ↓
자동으로 로그인 페이지 실행
        ↓
학번 / 이름 입력
        ↓
백엔드 로그인 API 호출
        ↓
백엔드가 요청 IP 또는 VDI 식별값으로 좌석 확인
        ↓
VDI_SESSION 상태 ACTIVE로 변경

[교수자 대시보드]
        ↓
5초마다 세션 API 호출
        ↓
VDI_SESSION 목록 조회
        ↓
OUT이면 회색
ACTIVE면 초록색
AI_DETECTED면 빨간색
RECONNECTED면 노란색

3. 이번 작업의 핵심 개념

3-1. 프론트의 임시 데이터 구조를 DB 기반 구조로 바꿨다

초기 프론트에서는 다음 localStorage 키를 사용했다.

vdi_professor_profile
vdi_exam_info
vdi_sessions
exam_id

이 구조는 화면 확인용으로는 충분하지만 실제 시스템에서는 부족하다.

이유는 다음과 같다.

브라우저마다 데이터가 따로 저장된다.
새 PC나 다른 브라우저에서는 데이터를 공유할 수 없다.
학생이 로그인해도 교수자 대시보드에 실시간 반영되지 않는다.
시험 종료 후 기록을 남길 수 없다.
최종 보고서와 연결할 수 없다.

그래서 이 구조를 DB 기반으로 바꾸는 것이 이번 작업의 핵심이었다.

vdi_professor_profile  → ACCOUNT / PROFESSOR_PROFILE
vdi_exam_info          → EXAM_INFO
vdi_sessions           → VDI_SESSION
VDI 이름/IP/좌석 정보   → VDI 매핑 테이블

4. 프론트엔드 인수인계

4-1. 주요 화면

현재 프론트는 크게 다음 화면으로 나뉜다.

교수 정보 입력 페이지
시험 생성 페이지
학생 로그인 페이지
교수자 대시보드 페이지

일반적인 nginx 배포 기준 경로는 다음과 같이 잡았다.

/usr/share/nginx/html/professor/
/usr/share/nginx/html/exam/
/usr/share/nginx/html/login/
/usr/share/nginx/html/home/

실제 서버에서 정확한 경로는 다음 명령어로 확인하면 된다.

grep -R "root" /etc/nginx/nginx.conf /etc/nginx/conf.d/*.conf
ls -al /usr/share/nginx/html

4-2. 교수 정보 입력 페이지

교수 정보 입력 페이지에서는 다음 값을 받는다.

교수명
교번 또는 교수 식별번호
학과

기존 프론트에서는 이 값을 다음 객체로 만들었다.

const professorProfile = {
  username: professorNo,
  role: "professor",
  name: professorName,
  department,
  createdAt: new Date().toISOString(),
};

기존에는 이것을 localStorage에 저장했다.

localStorage.setItem("vdi_professor_profile", JSON.stringify(professorProfile));

하지만 실제 운영에서는 백엔드 API로 보내야 한다.

권장 API는 다음과 같다.

POST /api/professor/setup

요청 예시:

{
  "professor_name": "홍길동",
  "professor_no": "P2025001",
  "department": "컴퓨터공학과"
}

백엔드에서는 이 값을 DB에 다음처럼 연결한다.

professor_no   → ACCOUNT.username
role           → ACCOUNT.role = professor
professor_name → PROFESSOR_PROFILE.name
department     → PROFESSOR_PROFILE.department

DB관리자는 이 부분에서 교수 식별번호가 ACCOUNT.username으로 들어가는 구조를 반드시 기억해야 한다.

4-3. 시험 생성 페이지

시험 생성 페이지에서는 다음 값을 입력받는다.

과목명
시험 장소
정원
시험 시작 시간
시험 종료 시간
시험 유형

기존 프론트 객체는 대략 다음 구조였다.

const examInfo = {
  exam_id: 1,
  subject_name: subjectName,
  exam_type: examType,
  scheduled_at: startAt,
  ended_at: endAt,
  total_target_students: capacity,
  place: examPlace,
  createdAt: new Date().toISOString(),
};

이 값은 DB의 EXAM_INFO 테이블과 연결된다.

subject_name           → EXAM_INFO.subject_name
exam_type              → EXAM_INFO.exam_type
scheduled_at           → EXAM_INFO.scheduled_at
ended_at               → EXAM_INFO.ended_at
total_target_students  → EXAM_INFO.total_target_students
place                  → EXAM_INFO.place

권장 API는 다음과 같다.

POST /api/exam

요청 예시:

{
  "professor_username": "P2025001",
  "subject_name": "데이터베이스",
  "exam_type": "중간고사",
  "place": "공학관 301호",
  "scheduled_at": "2026-05-10T13:00:00",
  "ended_at": "2026-05-10T15:00:00",
  "total_target_students": 40
}

이 API가 해야 하는 일은 단순히 EXAM_INFO만 만드는 것이 아니다.

EXAM_INFO에 시험 정보 저장
생성된 exam_id 확보
DB에 있는 VDI 이름/IP/좌석 매핑 조회
정원 수만큼 VDI_SESSION 초기 생성
모든 좌석 상태를 OUT으로 설정

즉, 시험 생성 시점에 대시보드에 표시할 좌석 세션도 같이 만들어야 한다.

4-4. 대시보드 페이지

대시보드는 다음 데이터를 필요로 한다.

시험 정보
교수 정보
전체 좌석 수
접속 중 좌석 수
미접속 좌석 수
AI 탐지 좌석 수
재접속 좌석 수
좌석별 상태
학생 학번
학생 이름
VDI 이름
VDI IP
최근 이벤트(보류)

대시보드에서 핵심적으로 사용하는 API는 다음 세 개다.

GET /api/exam/latest
GET /api/admin/exam?exam_id=1
GET /api/admin/sessions?exam_id=1

/api/exam/latest

대시보드에 exam_id가 없을 때 최신 시험을 찾기 위해 사용한다.

예를 들어 사용자가 다음 주소로 들어왔다고 하자.

/home/

이 경우 프론트는 어떤 시험을 보여줘야 하는지 모른다.

그래서 먼저 최신 시험을 조회한다.

GET /api/exam/latest

응답 예시:

{
  "success": true,
  "exam": {
    "exam_id": 1,
    "subject_name": "데이터베이스"
  }
}

프론트는 이 응답을 받은 뒤 URL을 다음처럼 바꿀 수 있다.

/home/?exam_id=1

/api/admin/exam?exam_id=1

대시보드 상단의 시험 정보를 표시하기 위해 사용한다.

응답 예시:

{
  "success": true,
  "exam": {
    "exam_id": 1,
    "subject_name": "데이터베이스",
    "exam_type": "중간고사",
    "professor_name": "홍길동",
    "department": "컴퓨터공학과",
    "scheduled_at": "2026-05-10 13:00:00",
    "ended_at": "2026-05-10 15:00:00",
    "place": "공학관 301호"
  }
}

이 API는 DB에서 EXAM_INFO만 조회해서는 부족할 수 있다.

교수명과 학과를 표시하려면 다음 테이블과 JOIN이 필요할 수 있다.

EXAM_INFO
ACCOUNT
PROFESSOR_PROFILE

DB관리자는 실제 스키마에 맞춰 JOIN 관계를 확인해야 한다.

/api/admin/sessions?exam_id=1

대시보드의 가장 중요한 API다.

이 API 응답을 기준으로 다음 화면이 모두 갱신된다.

KPI 카드
좌석 맵
응시자 현황 테이블
실시간 이벤트 피드
상태 분포
보고서 요약

응답 예시:

{
  "success": true,
  "sessions": [
    {
      "session_id": 1,
      "seat_no": "A-01",
      "vdi_name": "vdi-01",
      "vdi_ip": "192.168.122.101",
      "student_no": "20231042",
      "student_name": "김OO",
      "state_name": "ACTIVE",
      "started_at": "2026-05-10 13:01:00",
      "last_heartbeat": "2026-05-10 13:05:10",
      "reconnect_count": 0
    },
    {
      "session_id": 2,
      "seat_no": "A-02",
      "vdi_name": "vdi-02",
      "vdi_ip": "192.168.122.102",
      "student_no": null,
      "student_name": null,
      "state_name": "OUT",
      "started_at": null,
      "last_heartbeat": null,
      "reconnect_count": 0
    }
  ]
}

대시보드는 이 sessions 배열만 정확히 받으면 대부분의 화면을 자동으로 그릴 수 있다.

5. 대시보드 상태값 규칙

프론트에서 사용하는 상태값은 다음 기준으로 맞춰야 한다.

OUT          → 미접속, 회색
ACTIVE       → 접속중/정상, 초록색
RECONNECTED  → 재접속, 노란색
WARNING      → 주의, 노란색
CAUTION      → 주의, 노란색
AI_DETECTED  → AI 탐지, 빨간색
BLOCKED      → 차단, 빨간색

이거는 GPT랑 만들다보니 너무 많아져서 원준이 너가 대시보드 보고 간추려야 해

DB에 저장된 값이 다르다면 백엔드에서 변환해서 내려줘야 한다.

예를 들어 DB에는 숫자 상태값이 있을 수 있다.

→ OUT
→ ACTIVE
→ AI_DETECTED
→ RECONNECTED
→ BLOCKED

이 경우 API 응답에서는 프론트가 이해할 수 있도록 문자열로 변환하는 것이 좋다.

{
  "state_name": "ACTIVE"
}

프론트와 백엔드가 상태값을 다르게 쓰면 좌석 색상이 정상적으로 표시되지 않는다.

6. 학생 로그인 페이지 인수인계

학생은 우리가 제공한 VDI 접속 정보로 VDI에 접속한다.

VDI 접속 IP
VDI 접속 포트
VDI 비밀번호

VDI에 접속하면 Windows 시작 프로그램 또는 스케줄러를 통해 자동으로 로그인 페이지가 열린다.

http://서버주소/login/

학생은 로그인 페이지에서 다음 정보를 입력한다.

학번
이름

그리고 백엔드 로그인 API를 호출한다.

현재 논의에서 이름이 조금 혼재되어 있었다.

POST /api/vdi/login

또는 개념상:

POST /api/session/login

실제 코드에 이미 /api/vdi/login으로 구현되어 있다면 그걸 유지해도 된다.
다만 인수인계 후에는 DB관리자가 엔드포인트 이름을 하나로 통일하는 것이 좋다.

권장 요청 예시:

{
  "student_no": "20231042",
  "student_name": "김OO"
}

응답 예시:

{
  "success": true,
  "message": "로그인되었습니다.",
  "session": {
    "session_id": 1,
    "seat_no": "A-01",
    "vdi_name": "vdi-01",
    "vdi_ip": "192.168.122.101",
    "student_no": "20231042",
    "student_name": "김OO",
    "state_name": "ACTIVE"
  }
}

7. 학생마다 로그인 URL을 다르게 만들 필요가 없는 이유

중요한 인수인계 포인트다.

현재 DB에는 이미 다음 매핑이 있다고 했다.

VDI 이름 ↔ VDI IP ↔ 좌석 이름

예를 들면 다음과 같다.

vdi-01 ↔ 192.168.122.101 ↔ A-01
vdi-02 ↔ 192.168.122.102 ↔ A-02
vdi-03 ↔ 192.168.122.103 ↔ A-03

따라서 학생마다 로그인 브라우저 주소를 다르게 만들 필요는 없다.

모든 VDI에서 같은 로그인 페이지를 열어도 된다.

http://서버주소/login/

대신 백엔드가 로그인 요청을 받았을 때 다음을 해야 한다.

요청이 들어온 클라이언트 IP 확인
DB의 VDI 이름/IP/좌석 매핑 테이블 조회
해당 IP가 어느 VDI인지 확인
해당 VDI가 어느 좌석인지 확인
해당 좌석의 VDI_SESSION 업데이트

즉, 핵심은 URL이 아니라 백엔드가 VDI를 식별할 수 있느냐다.

8. 주의할 점: nginx 프록시를 쓰면 실제 VDI IP가 안 보일 수 있음

이 부분은 DB관리자에게 반드시 전달해야 한다.

학생 브라우저가 직접 FastAPI 서버로 요청하면 FastAPI에서 request.client.host로 VDI IP를 볼 수 있다.

하지만 보통 운영에서는 다음 구조를 쓴다.

학생 VDI 브라우저
  ↓
nginx
  ↓
FastAPI / uvicorn

이 경우 FastAPI에서 그냥 request.client.host를 보면 실제 VDI IP가 아니라 127.0.0.1 또는 nginx IP로 보일 수 있다.

그러면 백엔드는 어떤 VDI에서 로그인했는지 알 수 없다.

이 문제를 해결하려면 nginx에서 실제 클라이언트 IP를 헤더로 넘겨야 한다.

nginx 설정 예시는 다음과 같다.

location /api/ {
    proxy_pass http://127.0.0.1:8000/api/;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

FastAPI에서는 다음 순서로 IP를 확인하는 것이 좋다.

def get_client_ip(request):
    x_real_ip = request.headers.get("x-real-ip")
    if x_real_ip:
        return x_real_ip.strip()

    x_forwarded_for = request.headers.get("x-forwarded-for")
    if x_forwarded_for:
        return x_forwarded_for.split(",")[0].strip()

    return request.client.host

단, X-Forwarded-For는 외부에서 조작될 수 있으므로, 운영 환경에서는 nginx가 신뢰할 수 있는 내부 프록시일 때만 사용해야 한다.

9. 백엔드 인수인계

9-1. 백엔드 기술 스택

현재 백엔드는 FastAPI 기반으로 구성한 것으로 정리하면 된다.

사용 패키지는 다음과 같다.

fastapi
uvicorn
pymysql
python-dotenv

설치 예시:

cd /opt/vdi-login-api

python3 -m venv venv
source venv/bin/activate

pip install fastapi uvicorn pymysql python-dotenv

9-2. 백엔드 환경변수

DB 접속 정보는 코드에 직접 쓰지 말고 .env에 관리한다.

예시:

DB_HOST=127.0.0.1
DB_PORT=3306
DB_USER=DB_USER_NAME
DB_PASSWORD=DB_PASSWORD
DB_NAME=capston_db

STATE_OUT_ID=1
STATE_ACTIVE_ID=2
STATE_AI_DETECTED_ID=3
STATE_RECONNECTED_ID=4
STATE_BLOCKED_ID=5

인수인계 시 실제 비밀번호는 공개 문서에 넣으면 안 된다.

주의:
DB 계정
DB 비밀번호
서버 공인 IP
SSH 계정
VDI 접속 비밀번호
실제 학생 학번/이름

위 정보는 블로그나 공개 문서에 올리면 안 된다.

9-3. systemd 서비스

이전 작업에서 FastAPI를 systemd 서비스로 등록했다.

중요한 점은 이것이다.

FastAPI는 사용자가 SSH 접속할 때마다 새로 실행되는 것이 아니다.
systemd 서비스로 등록되어 있으면 서버 부팅 시 한 번 실행된다.
여러 명이 서버에 SSH로 접속해도 FastAPI가 여러 번 자동 실행되지는 않는다.

서비스 파일 위치는 보통 다음과 같다.

/etc/systemd/system/vdi-login-api.service

상태 확인:

sudo systemctl status vdi-login-api

서비스 시작:

sudo systemctl start vdi-login-api

서비스 재시작:

sudo systemctl restart vdi-login-api

서버 부팅 시 자동 실행:

sudo systemctl enable vdi-login-api

로그 확인:

sudo journalctl -u vdi-login-api -f

최근 로그 확인:

sudo journalctl -u vdi-login-api -n 100

포트 확인:

ss -ltnp | grep 8000

직접 uvicorn을 여러 터미널에서 실행하면 포트 충돌이 날 수 있다.

주의:
개발자가 수동으로 uvicorn main:app --host 0.0.0.0 --port 8000 을 실행한 상태에서
systemd 서비스도 실행하면 8000 포트 충돌이 발생할 수 있다.

10. 백엔드 API 목록

DB관리자가 앞으로 관리해야 할 주요 API는 다음과 같다.

기능메서드API설명

상태 확인	GET	/api/health	백엔드 서버 정상 여부 확인
교수 정보 저장	POST	/api/professor/setup	교수명, 교번, 학과 저장
시험 생성	POST	/api/exam	시험 정보 저장 및 세션 생성
최신 시험 조회	GET	/api/exam/latest	대시보드 기본 exam_id 조회
시험 상세 조회	GET	/api/admin/exam?exam_id=...	대시보드 상단 시험 정보
세션 목록 조회	GET	/api/admin/sessions?exam_id=...	좌석 상태 목록
학생 로그인	POST	/api/vdi/login 또는 /api/session/login	학생 로그인 및 좌석 ACTIVE 처리
접속 유지	POST/PATCH	/api/session/heartbeat	향후 접속 유지 판단용
탐지 반영	POST	/api/detection	향후 AI 탐지/차단 상태 반영용

현재 대시보드가 반드시 필요로 하는 핵심 API는 다음 세 개다.

GET /api/exam/latest
GET /api/admin/exam?exam_id=...
GET /api/admin/sessions?exam_id=...

학생 로그인까지 정상적으로 연결하려면 다음 API도 필수다.

POST /api/vdi/login

11. DB 테이블 역할 인수인계

정확한 테이블명은 실제 DB 스키마를 기준으로 다시 확인해야 하지만, 우리가 개발하면서 기준으로 잡은 역할은 다음과 같다.

ACCOUNT

사용자 계정 정보를 관리한다.

교수 계정
학생 계정
관리자 계정
role 구분
username
password 또는 인증 정보

교수 정보 입력 화면의 professorNo는 ACCOUNT.username으로 연결할 수 있다.

PROFESSOR_PROFILE

교수 상세 정보를 관리한다.

교수명
학과
ACCOUNT와의 연결 키

대시보드 상단에서 교수명과 학과를 보여줄 때 필요하다.

EXAM_INFO

시험 정보를 관리한다.

exam_id
subject_name
exam_type
place
scheduled_at
ended_at
total_target_students
professor_id 또는 account_id
created_at

시험 생성 페이지에서 입력한 정보가 이 테이블에 저장된다.

VDI 이름/IP/좌석 매핑 테이블

현재 DB에 이미 존재하는 중요한 테이블이다.

역할은 다음과 같다.

VDI 이름
VDI IP
좌석 이름 또는 좌석 번호

예시:

vdi-01 / 192.168.122.101 / A-01
vdi-02 / 192.168.122.102 / A-02
vdi-03 / 192.168.122.103 / A-03

이 테이블 덕분에 학생마다 로그인 URL을 다르게 만들 필요가 없다.

학생이 로그인하면 백엔드가 요청 IP를 확인하고 이 테이블에서 좌석을 찾는다.

VDI_SESSION

시험별 좌석 세션을 관리한다.

session_id
exam_id
seat_no
vdi_name
vdi_ip
student_no
student_name
current_state
started_at
last_heartbeat
reconnect_count

초기 상태:

student_no = null
student_name = null
current_state = OUT

학생 로그인 후:

student_no = 입력한 학번
student_name = 입력한 이름
current_state = ACTIVE
started_at = 현재 시간
last_heartbeat = 현재 시간

대시보드는 이 테이블을 조회해서 좌석 색상을 결정한다.

SESSION_STATE

상태 코드 관리 테이블로 사용할 수 있다.

예시:

/ OUT / 미접속
/ ACTIVE / 접속중
/ AI_DETECTED / AI 탐지
/ RECONNECTED / 재접속
/ BLOCKED / 차단

이전에 한글 설명을 insert할 때 MariaDB 문자셋 문제로 오류가 날 수 있었다.

오류 예시:

ERROR 1366 Incorrect string value

해결 방향:

ALTER DATABASE capston_db
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

테이블과 컬럼도 utf8mb4인지 확인해야 한다.

SHOW FULL COLUMNS FROM SESSION_STATE;

12. 학생 로그인 처리 로직

학생 로그인 API의 핵심 로직은 다음이다.

학생 학번과 이름을 body로 받는다.
요청 IP를 확인한다.
요청 IP로 VDI 매핑 테이블 조회
VDI 이름과 좌석 번호 확인
현재 진행 중인 exam_id 확인
해당 exam_id + seat_no의 VDI_SESSION 조회
student_no, student_name 저장
current_state를 ACTIVE로 변경
started_at, last_heartbeat 갱신
프론트에 success true 반환

개념 SQL:

SELECT
  vdi_name,
  vdi_ip,
  seat_no
FROM VDI_SEAT_MAPPING
WHERE vdi_ip = ?;

세션 업데이트:

UPDATE VDI_SESSION
SET
  student_no = ?,
  student_name = ?,
  current_state = 'ACTIVE',
  started_at = COALESCE(started_at, NOW()),
  last_heartbeat = NOW()
WHERE
  exam_id = ?
  AND seat_no = ?;

DB에 상태를 숫자로 저장한다면 다음처럼 처리할 수 있다.

UPDATE VDI_SESSION
SET
  student_no = ?,
  student_name = ?,
  state_id = 2,
  started_at = COALESCE(started_at, NOW()),
  last_heartbeat = NOW()
WHERE
  exam_id = ?
  AND seat_no = ?;

그리고 API 응답에서는 숫자 대신 문자열로 변환해서 내려준다.

{
  "state_name": "ACTIVE"
}

13. 시험 생성 시 세션 생성 로직

시험 생성 API는 다음 순서로 동작해야 한다.

교수 계정 확인
EXAM_INFO insert
생성된 exam_id 확인
VDI 매핑 테이블에서 정원 수만큼 좌석 조회
VDI_SESSION에 초기 세션 insert
모든 상태는 OUT

개념 SQL:

INSERT INTO EXAM_INFO (
  subject_name,
  exam_type,
  place,
  scheduled_at,
  ended_at,
  total_target_students,
  professor_id
)
VALUES (?, ?, ?, ?, ?, ?, ?);

VDI 매핑 조회:

SELECT
  vdi_name,
  vdi_ip,
  seat_no
FROM VDI_SEAT_MAPPING
ORDER BY seat_no
LIMIT ?;

세션 초기 생성:

INSERT INTO VDI_SESSION (
  exam_id,
  seat_no,
  vdi_name,
  vdi_ip,
  student_no,
  student_name,
  current_state,
  started_at,
  last_heartbeat,
  reconnect_count
)
VALUES (
  ?,
  ?,
  ?,
  ?,
  NULL,
  NULL,
  'OUT',
  NULL,
  NULL,
  0
);

이렇게 해야 대시보드에 처음 들어갔을 때 전체 좌석이 회색으로 보인다.

14. 대시보드 갱신 구조

대시보드는 일정 주기마다 API를 다시 호출한다.

현재 기준은 5초 polling 구조다.

loadDashboard();
setInterval(loadDashboard, 5000);

흐름은 다음과 같다.

학생 로그인
  ↓
POST /api/vdi/login
  ↓
DB에서 해당 좌석 ACTIVE 변경
  ↓
대시보드가 5초 후 GET /api/admin/sessions 호출
  ↓
새로운 sessions 배열 수신
  ↓
해당 좌석 회색 → 초록색

WebSocket을 쓰지 않아도 초기 프로젝트 단계에서는 충분히 동작한다.

향후 실시간성을 높이고 싶다면 WebSocket 또는 SSE로 변경할 수 있다.

15. API 응답 규칙

프론트의 fetchJson 함수는 응답에 success가 있는지 확인한다.

따라서 모든 API 응답은 다음 형식을 지켜야 한다.

성공:

{
  "success": true,
  "data": {}
}

또는:

{
  "success": true,
  "exam": {},
  "sessions": []
}

실패:

{
  "success": false,
  "message": "오류 메시지"
}

주의할 점은 HTTP 200이어도 success가 없으면 프론트에서 실패로 처리될 수 있다는 것이다.

나쁜 예:

{
  "exam": {
    "exam_id": 1
  }
}

좋은 예:

{
  "success": true,
  "exam": {
    "exam_id": 1
  }
}

16. 운영 명령어 인수인계

백엔드 상태 확인

sudo systemctl status vdi-login-api

백엔드 재시작

sudo systemctl restart vdi-login-api

백엔드 로그 확인

sudo journalctl -u vdi-login-api -f

FastAPI 포트 확인

ss -ltnp | grep 8000

nginx 상태 확인

sudo systemctl status nginx

nginx 재시작

sudo systemctl restart nginx

nginx 설정 테스트

sudo nginx -t

80번 포트 확인

ss -ltnp | grep ':80'

API health check

curl http://127.0.0.1:8000/api/health

nginx를 통해 확인:

curl http://서버주소/api/health

17. API 테스트 명령어

시험 상세 조회

curl "http://서버주소/api/admin/exam?exam_id=1"

세션 목록 조회

curl "http://서버주소/api/admin/sessions?exam_id=1"

학생 로그인 테스트

curl -X POST "http://서버주소/api/vdi/login" \
  -H "Content-Type: application/json" \
  -d '{
    "student_no": "20231042",
    "student_name": "김OO"
  }'

주의할 점은 이 테스트를 서버 내부에서 127.0.0.1로 실행하면 요청 IP가 실제 VDI IP가 아니기 때문에 좌석 매핑이 실패할 수 있다는 것이다.

VDI IP 기반 매핑을 테스트하려면 실제 VDI 안에서 로그인 요청을 보내는 방식으로 확인해야 한다.

18. DB 확인용 SQL

시험 목록 확인

SELECT *
FROM EXAM_INFO
ORDER BY exam_id DESC;

특정 시험 확인

SELECT *
FROM EXAM_INFO
WHERE exam_id = 1;

VDI/좌석 매핑 확인

SELECT *
FROM VDI_SEAT_MAPPING
ORDER BY seat_no;

실제 테이블명이 다르면 현재 DB의 매핑 테이블명으로 바꿔야 한다.

특정 IP가 어느 좌석인지 확인

SELECT *
FROM VDI_SEAT_MAPPING
WHERE vdi_ip = '192.168.122.101';

특정 시험의 세션 확인

SELECT *
FROM VDI_SESSION
WHERE exam_id = 1
ORDER BY seat_no;

접속 중 좌석 확인

SELECT
  seat_no,
  vdi_name,
  vdi_ip,
  student_no,
  student_name,
  current_state,
  started_at,
  last_heartbeat
FROM VDI_SESSION
WHERE exam_id = 1
  AND current_state = 'ACTIVE';

미접속 좌석 확인

SELECT
  seat_no,
  vdi_name,
  vdi_ip,
  current_state
FROM VDI_SESSION
WHERE exam_id = 1
  AND current_state = 'OUT';

19. 주요 시행착오와 해결 방식

19-1. localStorage 기반이라 실제 DB와 연결되지 않음

문제

초기 프론트는 localStorage만 사용했다.

vdi_professor_profile
vdi_exam_info
vdi_sessions

원인

프론트 화면 확인을 위해 임시 데이터를 사용한 구조였기 때문이다.

해결

백엔드 API를 만들고 DB와 연결했다.

교수 정보 → ACCOUNT / PROFESSOR_PROFILE
시험 정보 → EXAM_INFO
좌석 상태 → VDI_SESSION

19-2. exam_id가 없으면 대시보드가 어떤 시험을 보여줄지 모름

문제

사용자가 /home/으로 접속하면 exam_id가 없다.

해결

GET /api/exam/latest API를 만들었다.

/home/
  ↓
/api/exam/latest 호출
  ↓
최신 exam_id 확인
  ↓
/home/?exam_id=1 로 URL 갱신

19-3. API 응답에 success가 없어서 프론트에서 오류 처리됨

문제

백엔드가 데이터를 내려줘도 프론트에서 실패로 처리될 수 있었다.

원인

프론트 fetchJson이 data.success를 검사했기 때문이다.

해결

모든 API 응답에 success를 포함한다.

{
  "success": true
}

19-4. DB 상태값과 프론트 상태값이 다름

문제

DB에는 숫자나 다른 문자열로 상태가 저장되어 있는데, 프론트는 ACTIVE, OUT, AI_DETECTED 등을 기대한다.

해결

백엔드에서 응답 변환을 한다.

→ OUT
→ ACTIVE
→ AI_DETECTED
→ RECONNECTED
→ BLOCKED

19-5. 학생 로그인 후 어떤 좌석인지 알 수 없음

문제

학생이 학번과 이름만 입력하면 백엔드가 좌석을 알 수 없다.

해결

DB에 이미 있는 VDI 이름/IP/좌석 매핑을 사용한다.

요청 IP
  ↓
VDI 매핑 테이블 조회
  ↓
좌석 확인
  ↓
VDI_SESSION 업데이트

19-6. nginx 프록시 때문에 실제 VDI IP가 안 보일 수 있음

문제

FastAPI에서 클라이언트 IP를 확인하면 127.0.0.1로 나올 수 있다.

해결

nginx에서 다음 헤더를 넘긴다.

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

FastAPI에서 해당 헤더를 우선 확인한다.

19-7. 한글 insert 오류

문제

MariaDB에 한글 설명을 넣을 때 다음 오류가 날 수 있었다.

ERROR 1366 Incorrect string value

원인

DB, 테이블, 컬럼 문자셋이 utf8mb4가 아니었을 가능성이 있다.

해결

ALTER DATABASE capston_db
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

테이블과 컬럼 문자셋도 확인해야 한다.

FastAPI 백엔드 API 개발 및 프론트 대시보드 연동 기록

otopligrm — Tue, 19 May 2026 00:01:23 +0900

초기에는 프론트엔드 대시보드가 더미데이터 또는 브라우저 localStorage 기반으로 동작하고 있었다. 즉, 사용자가 시험 정보를 입력하더라도 실제 DB에 저장되지 않았고, 학생이 VDI에 접속해도 대시보드의 좌석 상태가 실제로 바뀌지 않았다.

그래서 이번 개발의 핵심 목표는 다음과 같았다.

사용자가 웹 페이지에서 시험 정보를 입력하면 DB에 저장한다.
학생이 VDI 안에서 로그인하면 학생 정보가 DB에 저장된다.
학생이 접속한 VDI를 식별해 해당 좌석 상태를 ACTIVE로 변경한다.
교수 대시보드는 DB 값을 조회해 좌석 상태를 시각화한다.
개발이 끝난 뒤에는 FastAPI 서버를 수동 실행하지 않고 systemd 서비스로 운영한다.

최종적으로 구현하고자 한 흐름은 다음과 같다.

사용자
/professor/ 접속
→ 교수 식별 정보 입력
→ 교수 정보 DB 저장 또는 수정

/exam/ 접속
→ 과목명, 시험 유형, 시작/종료 시간, 정원 입력
→ 시험 정보 DB 저장 또는 수정
→ 기존 VDI 좌석 row에 현재 시험 ID 연결

학생
VDI 접속
→ VDI 내부에서 /login/ 자동 실행
→ 이름과 학번 입력
→ 백엔드가 요청 IP를 기준으로 VDI 좌석 식별
→ 해당 좌석 상태를 ACTIVE로 변경

대시보드
/home/ 접속
→ 시험 정보와 VDI 세션 정보 조회
→ 미접속 좌석은 회색, 접속 좌석은 초록색으로 표시

2. 전체 시스템 구조

이번에 구성한 구조는 다음과 같다.

[교수자 PC / 학생 VDI 브라우저]
        ↓
[Nginx]
- 정적 파일 제공
- /login/
- /home/
- /professor/
- /exam/

        ↓ /api/ 요청 프록시

[FastAPI 백엔드]
- 교수 정보 저장
- 시험 정보 저장/수정
- 학생 로그인 처리
- 대시보드 조회 API 제공

        ↓

[MariaDB]
- 교수 정보
- 학생 정보
- 시험 정보
- VDI 세션 상태
- 상태 변경 이력 저장

Nginx는 웹 화면을 제공하고, /api/로 시작하는 요청은 FastAPI 백엔드로 전달한다. FastAPI는 DB와 연결되어 교수자, 학생, 시험, VDI 세션 데이터를 처리한다.

3. 사용 기술

이번 작업에서 사용한 주요 기술은 다음과 같다.

운영체제
- Rocky Linux 계열 서버

웹 서버
- Nginx

백엔드
- Python
- FastAPI
- Uvicorn
- PyMySQL
- python-dotenv

DB
- MariaDB

운영 관리
- systemd

프론트엔드
- HTML
- CSS
- JavaScript
- Fetch API
- localStorage

각 기술을 사용한 이유는 다음과 같다.

FastAPI
→ Python 기반으로 빠르게 REST API를 구현할 수 있고, 요청 모델 검증이 편리하다.

Uvicorn
→ FastAPI 앱을 실행하기 위한 ASGI 서버다.

PyMySQL
→ Python에서 MariaDB와 연결하기 위해 사용했다.

python-dotenv
→ DB 접속 정보와 상태값을 코드에 직접 쓰지 않고 .env 파일로 분리하기 위해 사용했다.

Nginx
→ 정적 HTML/CSS/JS 파일 제공과 API reverse proxy 역할을 동시에 수행하기 위해 사용했다.

systemd
→ FastAPI를 터미널 수동 실행이 아닌 운영 서비스로 등록하기 위해 사용했다.

4. 주요 DB 테이블 역할

프로젝트의 실제 DB 테이블명은 공개하지 않고, 블로그에서는 역할 중심으로 정리했다.

계정 테이블
→ 학생과 교수자의 공통 로그인/식별 정보를 저장한다.

학생 프로필 테이블
→ 학번, 이름 등 학생 정보를 저장한다.

교수 프로필 테이블
→ 교수자 이름, 소속 등 교수자 정보를 저장한다.

시험 정보 테이블
→ 과목명, 시험 유형, 시작 시간, 종료 시간, 정원 정보를 저장한다.

세션 상태 테이블
→ OUT, ACTIVE 등 VDI 상태 코드를 저장한다.

VDI 세션 테이블
→ 각 VDI 좌석의 IP, 좌석 번호, 현재 접속 학생, 상태를 저장한다.

상태 이력 테이블
→ VDI 상태가 변경될 때마다 이력을 저장한다.

이번 개발에서 가장 중요한 테이블은 VDI 세션 테이블이었다. 이 테이블은 처음에는 시험마다 새 세션 row를 만드는 방식으로 설계하려고 했지만, 최종적으로는 이미 등록된 고정 VDI row의 exam_id만 업데이트하는 방식으로 수정했다.

5. 백엔드 프로젝트 생성

FastAPI 백엔드 프로젝트는 서버의 애플리케이션 전용 디렉터리에 구성했다.

공개 블로그에서는 실제 경로 대신 다음처럼 표현한다.

mkdir -p <BACKEND_PROJECT_DIR>
cd <BACKEND_PROJECT_DIR>

Python 가상환경을 생성했다.

python3 -m venv venv
source venv/bin/activate

가상환경을 사용하는 이유는 서버 전체 Python 환경과 프로젝트 의존성을 분리하기 위해서다. 이렇게 하면 특정 프로젝트에서 설치한 패키지가 다른 프로젝트나 시스템 Python에 영향을 주지 않는다.

6. Python 패키지 설치

FastAPI 백엔드 개발을 위해 다음 패키지를 설치했다.

pip install fastapi uvicorn pymysql python-dotenv

각 패키지의 역할은 다음과 같다.

fastapi
→ API 서버 프레임워크

uvicorn
→ FastAPI 앱 실행 서버

pymysql
→ MariaDB 연결 라이브러리

python-dotenv
→ .env 파일에서 환경변수 로드

설치 후에는 main.py에서 FastAPI 앱을 구성하고, DB 접속 정보를 .env에서 불러오도록 구성했다.

7. 환경변수 파일 구성

DB 접속 정보는 코드에 직접 적지 않고 .env 파일로 분리했다.

공개용 예시는 다음과 같다.

DB_HOST=<DB_HOST>
DB_PORT=3306
DB_USER=<DB_USER>
DB_PASSWORD=<DB_PASSWORD>
DB_NAME=<DB_NAME>

STATE_OUT_ID=1
STATE_ACTIVE_ID=2

실제 개발 중에는 같은 서버 안에서 FastAPI와 MariaDB가 동작했기 때문에 DB 호스트는 내부 접속 주소를 사용했다. 공개 블로그에서는 실제 DB명이나 계정명, 비밀번호 유무를 절대 노출하지 않는다.

.env 파일은 민감 정보를 포함하므로 권한도 제한했다.

프론트엔드 개발을 할때에도 민감한 정보들은 전부 env에 넣어서 작업을 하고

gitignore에 env를 포함시키면서 작업을 했었다.

chmod 600 <BACKEND_PROJECT_DIR>/.env

8. DB 연결 확인

DB 연결 전에는 MariaDB에 직접 접속해 데이터베이스와 테이블 상태를 확인했다.

mysql -u <DB_USER> -p

DB 선택:

USE <DB_NAME>;
SHOW TABLES;

이 단계에서 확인한 것은 다음과 같다.

프로젝트용 DB가 존재하는지
계정/교수/학생/시험/VDI 세션 관련 테이블이 존재하는지
VDI 세션 테이블에 고정 VDI row가 미리 등록되어 있는지

초기에는 DB 이름을 잘못 입력해 접속 오류가 발생했다. 이 경험을 통해 실제 운영에서는 DB명과 .env 값이 정확히 일치하는지 먼저 확인해야 한다는 것을 알 수 있었다.

9. 한글 저장 오류와 문자셋 수정

교수자 이름, 학생 이름, 학과명, 과목명 등 한글 데이터가 DB에 저장되어야 했다. 그런데 초기 테스트 중 다음과 같은 오류가 발생했다.

Incorrect string value

원인은 일부 DB 또는 테이블의 문자셋이 한글 저장에 적합하지 않았기 때문이다.

그래서 주요 한글 입력 테이블을 utf8mb4 기반 문자셋으로 변환했다.

공개용 SQL 예시는 다음과 같다.

ALTER DATABASE <DB_NAME>
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

ALTER TABLE <USER_TABLE>
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

ALTER TABLE <STUDENT_PROFILE_TABLE>
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

ALTER TABLE <PROFESSOR_PROFILE_TABLE>
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

ALTER TABLE <EXAM_INFO_TABLE>
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

일부 테이블은 외래키 제약 때문에 바로 변환할 수 없었다. 예를 들어 세션 ID가 여러 테이블에서 외래키로 참조되고 있으면 컬럼 변경이 제한된다. 이 경우에는 한글이 실제로 저장되는 주요 테이블을 우선 변환하고, FK가 걸린 테이블은 별도 절차가 필요하다고 판단했다.

10. FastAPI 기본 구조

백엔드의 핵심 파일은 main.py였다.

구성한 API는 다음과 같다.

GET /api/health
→ 서버 상태 확인

POST /api/professor/setup
→ 교수 정보 저장 또는 수정

POST /api/exam/setup
→ 시험 정보 저장 또는 수정

GET /api/exam/latest
→ 최신 시험 정보 조회

POST /api/vdi/login
→ 학생 VDI 로그인

POST /api/vdi/heartbeat
→ 학생 VDI 접속 상태 갱신

GET /api/admin/exam
→ 대시보드 시험 정보 조회

GET /api/admin/sessions
→ 대시보드 좌석 목록 조회

GET /api/admin/summary
→ 대시보드 요약 정보 조회

초기에는 API 서버를 직접 다음 명령어로 실행했다.

uvicorn main:app --host 127.0.0.1 --port 8000

하지만 운영 단계에서는 이 방식을 사용하지 않고 systemd 서비스로 등록했다.

11. JSON 직렬화 오류 해결

대시보드에서 요약 API를 호출할 때 다음 오류가 발생했다.

Object of type Decimal is not JSON serializable

원인은 MariaDB에서 COUNT, SUM 등의 결과가 Python의 Decimal 타입으로 넘어왔고, FastAPI의 JSONResponse가 이를 바로 JSON으로 변환하지 못했기 때문이다.

해결 방향은 다음과 같았다.

Decimal 값을 int 또는 float로 변환한다.
datetime 값은 문자열로 변환한다.
dict/list 내부에 중첩된 값까지 재귀적으로 변환한다.

공개용 예시 코드는 다음과 같다.

def json_safe(value):
    if value is None:
        return None

    if isinstance(value, Decimal):
        if value == value.to_integral_value():
            return int(value)
        return float(value)

    if hasattr(value, "isoformat"):
        return value.isoformat(sep=" ", timespec="seconds")

    return value


def to_jsonable(value):
    if isinstance(value, dict):
        return {key: to_jsonable(val) for key, val in value.items()}

    if isinstance(value, list):
        return [to_jsonable(item) for item in value]

    return json_safe(value)

이후 모든 API 응답을 만들 때 to_jsonable()을 거치도록 수정해 Decimal 직렬화 오류를 해결했다.

12. Nginx와 FastAPI 연결

Nginx는 정적 파일을 제공하고, /api/ 요청만 FastAPI로 전달하도록 설정했다.

공개용 Nginx 설정 예시는 다음과 같다.

location /api/ {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

이 설정을 추가한 이유는 다음과 같다.

/login/, /home/, /professor/, /exam/
→ Nginx가 정적 HTML/CSS/JS 제공

/api/...
→ Nginx가 FastAPI로 프록시 전달

특히 X-Real-IP를 전달한 이유가 중요하다. 학생들이 VDI 내부에서 같은 로그인 URL로 접속할 때, 백엔드가 실제 요청 IP를 확인해야 어느 VDI에서 로그인했는지 식별할 수 있기 때문이다.

설정 변경 후에는 다음 명령어로 문법을 확인하고 적용했다.

nginx -t
systemctl reload nginx

13. Nginx 편집 중 swap 파일 오류

Nginx 설정 파일을 편집하다가 vi swap 파일 경고가 발생했다.

원인은 이전 편집 세션이 비정상 종료되었거나, 누군가 같은 파일을 동시에 편집했기 때문이었다.

해결 절차는 다음과 같았다.

현재 해당 파일을 편집 중인 프로세스가 있는지 확인
실제 편집 중인 사람이 없는지 확인
설정 파일 백업
swap 파일 삭제
다시 편집

사용한 명령어는 다음과 같다.

ps -ef | grep <CONFIG_FILE_NAME>
who
cp <NGINX_CONFIG_PATH> <NGINX_CONFIG_PATH>.bak_$(date +%Y%m%d_%H%M%S)
rm -f <NGINX_SWAP_FILE>

여러 명이 같은 서버에서 작업할 때는 이런 충돌이 자주 발생할 수 있으므로, 설정 파일은 동시에 편집하지 않도록 규칙을 정하는 것이 중요하다.

14. Nginx 50x 오류 해결

초기에는 /api/health를 호출했을 때 Nginx 기본 50x 페이지가 보였다.

가능한 원인은 다음과 같았다.

FastAPI가 8000번 포트에서 실행 중이 아님
Nginx가 FastAPI로 프록시하지 못함
Nginx 설정 변경 후 reload를 하지 않음
방화벽 또는 SELinux 문제

확인 순서는 다음과 같았다.

curl http://127.0.0.1:8000/api/health
curl http://127.0.0.1/api/health

판단 기준은 다음과 같다.

127.0.0.1:8000이 실패
→ FastAPI 자체가 꺼져 있음

127.0.0.1:8000은 성공하지만 127.0.0.1/api/health가 실패
→ Nginx 프록시 설정 문제

15. 학생 로그인 방식 변경

처음에는 학생 로그인 URL에 좌석 번호를 붙이는 방식을 생각했다.

/login/?exam_id=<EXAM_ID>&seat_no=<SEAT_NO>&vdi_name=<VDI_NAME>

하지만 실제 운영에서는 학생에게 URL을 다르게 제공하는 구조가 적합하지 않았다. 학생들은 이미 각자 다른 VDI IP/PW로 접속하므로, VDI 안에서는 모두 같은 로그인 페이지가 뜨는 것이 더 자연스러웠다.

최종 방식은 다음과 같다.

모든 VDI
→ 같은 /login/ URL 사용

학생 로그인
→ 이름/학번 입력

백엔드
→ 요청 IP 확인
→ VDI_SESSION.vdi_ip와 매칭
→ 해당 VDI row ACTIVE 처리

즉 seat_no 기반 로그인에서 request_ip 기반 로그인으로 변경했다.

16. VDI 내부 IP 확인

같은 로그인 URL을 사용하려면, 서버에서 VDI별 IP가 다르게 보이는지 확인해야 했다.

서버에서 Nginx access log를 확인했다.

tail -f /var/log/nginx/access.log

VDI 여러 대에서 /login/에 접속한 뒤 로그를 확인했다.

공개용 로그 예시는 다음과 같이 마스킹했다.

<VDI_PRIVATE_IP_A> - - [timestamp] "GET /login/ HTTP/1.1" 200
<VDI_PRIVATE_IP_B> - - [timestamp] "GET /login/ HTTP/1.1" 200

로그에서 VDI별 내부 IP가 다르게 찍히는 것을 확인했고, 따라서 vdi_ip 기반 매핑이 가능하다고 판단했다.

17. VDI 내부 접속 URL 결정

VDI가 내부 NAT 네트워크에 있기 때문에 외부 공인 IP로 접속하는 것이 항상 안정적이지는 않았다. 테스트 결과, VDI 내부에서는 VDI 게이트웨이 또는 호스트 내부 주소를 사용하는 것이 더 적합했다.

공개용 표현:

교수자 또는 외부 관리 PC
→ http://<SERVER_PUBLIC_IP>/home/

학생 VDI 내부
→ http://<VDI_GATEWAY_IP>/login/

즉 교수자와 학생 VDI의 접속 URL을 다르게 운용할 수 있다.

18. VDI_SESSION 사용 방식 수정

가장 중요한 설계 변경은 VDI_SESSION 처리 방식이었다.

초기 방식은 시험 생성 시 다음과 같은 새 row를 만드는 것이었다.

EXAM<EXAM_ID>-VDI01
EXAM<EXAM_ID>-VDI02
EXAM<EXAM_ID>-VDI03

하지만 실제 DB에는 이미 고정 VDI row가 등록되어 있었다.

공개용 예시:

VDI-1 | seat_no=1 | vdi_ip=<VDI_PRIVATE_IP_1>
VDI-2 | seat_no=2 | vdi_ip=<VDI_PRIVATE_IP_2>
VDI-3 | seat_no=3 | vdi_ip=<VDI_PRIVATE_IP_3>

따라서 최종 방식은 다음처럼 수정했다.

시험 생성/수정 시 새 VDI_SESSION row 생성 X

기존 VDI-1, VDI-2, VDI-3 row 유지

해당 row들의 exam_id만 현재 시험 ID로 UPDATE

이렇게 하면 VDI IP 매핑 정보를 잃지 않고, 학생 로그인 시 request_ip와 vdi_ip를 비교해 좌석을 찾을 수 있다.

19. 시험 정보가 계속 추가되는 문제 해결

초기에는 /exam/에서 시험 정보를 저장할 때마다 EXAM_INFO에 새 row가 계속 추가되었다.

원인은 API가 매번 INSERT만 수행했기 때문이다.

수정 방향은 다음과 같다.

프론트에서 localStorage에 exam_id가 있으면 함께 전송한다.
백엔드는 exam_id가 있으면 해당 시험 UPDATE
exam_id가 없으면 해당 교수의 최신 시험 조회
최신 시험이 있으면 UPDATE
기존 시험이 전혀 없으면 최초 1회만 INSERT

이렇게 수정한 이유는 교수자가 시험 정보를 다시 입력할 때마다 새로운 시험이 생성되는 것이 아니라, 같은 시험 정보가 수정되는 것이 더 자연스럽기 때문이다.

20. /api/exam/setup 최종 정책

최종 /api/exam/setup의 정책은 다음과 같다.

교수 정보가 존재하는지 확인한다.
exam_id가 전달되면 해당 시험을 찾는다.
exam_id가 없으면 해당 교수의 최신 시험을 찾는다.
기존 시험이 있으면 EXAM_INFO를 UPDATE한다.
없으면 최초 1회 INSERT한다.
이전 로직으로 잘못 생성된 EXAM* 세션 row를 정리한다.
기존 VDI-1~VDI-N row에 현재 exam_id를 연결한다.
정원보다 큰 VDI row는 이번 시험에서 제외한다.

여기서 핵심은 새 VDI_SESSION row를 만들지 않는 것이다.

21. 학생 로그인 API 최종 정책

최종 /api/vdi/login의 정책은 다음과 같다.

1. 이름 검증
   - 공백 제거
   - 4글자 이하

2. 학번 검증
   - 숫자만 허용
   - 9자리

3. 시험 정보 존재 확인

4. 계정 테이블에서 학생 계정 조회
   - 없으면 생성
   - 있으면 재사용

5. 학생 프로필 조회
   - 없으면 생성
   - 있으면 이름 업데이트 가능

6. VDI 세션 조회
   - seat_no가 있으면 exam_id + seat_no로 조회
   - seat_no가 없으면 exam_id + request_ip로 조회

7. 이미 다른 학생이 사용 중이면 차단

8. 정상 로그인 시
   - student_id 연결
   - state_id를 ACTIVE로 변경
   - started_at, last_heartbeat 업데이트
   - 상태 변경 이력 기록

학생은 같은 /login/ URL을 사용하고, 실제 VDI 구분은 백엔드에서 요청 IP로 처리한다.

22. 학생 로그인 예외처리 문제

학생 로그인 화면에서 학번을 9자리 입력해도 8자리로 인식되는 문제가 있었다.

원인은 HTML input의 maxlength="9"였다.

예를 들어 사용자가 다음 값을 붙여넣는 경우:

2024-12345

브라우저가 먼저 9글자로 자르면:

2024-1234

가 되고, JS가 숫자만 추출하면 8자리가 된다.

그래서 해결 방식은 다음과 같다.

HTML input에서 maxlength 제거
JS에서 숫자만 추출
JS에서 slice(0, 9)로 제한
최종적으로 정확히 9자리인지 검증

공개용 JS 로직 예시는 다음과 같다.

function normalizeStudentNo(value) {
  return String(value || "").replace(/\D/g, "").slice(0, 9);
}

그리고 기존에는 seat_no가 없으면 로그인 자체를 막았지만, 최종 구조에서는 같은 URL을 사용하므로 해당 검사를 제거했다.

23. 로그인 페이지 localStorage 사용

로그인 성공 후 브라우저에는 다음 정보를 저장했다.

vdi_session_id
student_no
student_name
exam_id
seat_no
vdi_ip
request_ip

공개 블로그에서는 실제 값은 노출하지 않고, 역할만 설명한다.

이 값을 저장한 이유는 이후 heartbeat 또는 세션 연동 기능에서 현재 로그인 세션을 계속 추적하기 위해서다.

또한 브라우저 UUID도 생성했다.

vdi_browser_uuid

단, 브라우저 UUID는 내부 API 요청 식별에는 사용할 수 있지만, 일반 웹페이지 JS만으로는 외부 사이트 전체 요청에 헤더를 삽입할 수 없기 때문에 프록시 전체 트래픽 식별의 핵심 수단으로는 VDI IP 매핑이 더 적합하다고 판단했다.

24. 대시보드 API 연동

대시보드는 다음 API를 호출한다.

GET /api/admin/exam?exam_id=<EXAM_ID>
→ 시험 정보 조회

GET /api/admin/sessions?exam_id=<EXAM_ID>
→ 좌석별 VDI 세션 목록 조회

GET /api/admin/summary?exam_id=<EXAM_ID>
→ 전체 좌석 수, 접속 수, 미접속 수 조회

좌석 상태 색상은 다음 기준으로 설계했다.

OUT
→ 회색

ACTIVE
→ 초록

주의/재접속
→ 노랑

AI 탐지/차단
→ 빨강

현재 구현 단계에서는 OUT, ACTIVE를 우선 사용했다. 추후 프록시나 탐지 로직과 연결하면 AI 탐지 상태를 추가할 수 있다.

25. FastAPI systemd 서비스 등록

개발 초기에는 터미널에서 직접 FastAPI를 실행했다.

uvicorn main:app --host 127.0.0.1 --port 8000

하지만 이 방식은 터미널이 닫히면 서버도 종료된다. 실제 시험 환경에서는 부적합하다.

그래서 systemd 서비스로 등록했다.

공개용 서비스 파일 예시는 다음과 같다.

[Unit]
Description=VDI Login FastAPI Backend
After=network.target mariadb.service

[Service]
WorkingDirectory=<BACKEND_PROJECT_DIR>
EnvironmentFile=<BACKEND_PROJECT_DIR>/.env
ExecStart=<BACKEND_PROJECT_DIR>/venv/bin/uvicorn main:app --host 127.0.0.1 --port 8000
Restart=always
RestartSec=3
User=<SERVICE_USER>

[Install]
WantedBy=multi-user.target

등록 명령어:

systemctl daemon-reload
systemctl start <FASTAPI_SERVICE_NAME>
systemctl enable <FASTAPI_SERVICE_NAME>
systemctl status <FASTAPI_SERVICE_NAME>

이제 서버가 재부팅되어도 FastAPI가 자동 실행된다.

26. 포트 중복 오류

서비스 등록 후 직접 uvicorn을 다시 실행하자 다음 오류가 발생했다.

address already in use

원인은 systemd 서비스가 이미 8000번 포트를 사용 중인데, 같은 포트로 FastAPI를 또 실행하려 했기 때문이다.

확인 명령어:

ss -ltnp | grep 8000
systemctl status <FASTAPI_SERVICE_NAME>

이후 운영 방식은 다음처럼 정리했다.

직접 uvicorn 실행 X

코드 수정 후:
python -m py_compile main.py
systemctl restart <FASTAPI_SERVICE_NAME>
systemctl status <FASTAPI_SERVICE_NAME>

27. 여러 명이 같은 서버에서 개발할 때의 문제

팀원 여러 명이 같은 서버에서 작업하면서 다음 문제가 발생할 수 있었다.

같은 포트에 FastAPI 중복 실행
같은 설정 파일 동시 편집
vi swap 파일 발생
main.py 수정 중 다른 사람이 서비스 재시작
DB 데이터를 서로 덮어씀

그래서 작업 규칙을 정리했다.

FastAPI 실행은 systemd 서비스 하나만 사용한다.
uvicorn 직접 실행은 금지한다.
main.py 수정 전 백업한다.
수정 후 문법 검사를 한다.
이상 없을 때만 서비스를 재시작한다.
DB UPDATE/DELETE 전 SELECT로 대상 row를 먼저 확인한다.
Nginx 설정 파일은 동시에 편집하지 않는다.

백업 명령어 예시는 다음과 같다.

cp <BACKEND_PROJECT_DIR>/main.py <BACKEND_PROJECT_DIR>/main.py.bak_$(date +%Y%m%d_%H%M%S)
cp <LOGIN_JS_PATH> <LOGIN_JS_PATH>.bak_$(date +%Y%m%d_%H%M%S)
cp <EXAM_JS_PATH> <EXAM_JS_PATH>.bak_$(date +%Y%m%d_%H%M%S)

28. 운영 전 점검 명령어

실제 사용 전에는 다음 순서로 확인한다.

systemctl status nginx
systemctl status mariadb
systemctl status <FASTAPI_SERVICE_NAME>

포트 확인:

ss -ltnp | grep ':80'
ss -ltnp | grep ':8000'

API 확인:

curl http://127.0.0.1/api/health
curl http://<SERVER_PUBLIC_IP>/api/health

VDI 내부에서는 다음 주소로 확인한다.

http://<VDI_GATEWAY_IP>/api/health

로그 확인:

tail -f <NGINX_ACCESS_LOG_PATH>
journalctl -u <FASTAPI_SERVICE_NAME> -f

29. 정상 DB 상태 예시

최종적으로 VDI 세션 테이블은 다음과 같은 형태가 되어야 한다.

session_id | exam_id     | student_id | state_id | seat_no | vdi_ip
VDI-1      | <EXAM_ID>   | NULL       | OUT      | 1       | <VDI_PRIVATE_IP_1>
VDI-2      | <EXAM_ID>   | NULL       | OUT      | 2       | <VDI_PRIVATE_IP_2>
VDI-3      | <EXAM_ID>   | NULL       | OUT      | 3       | <VDI_PRIVATE_IP_3>

학생이 두 번째 VDI에서 로그인하면 다음처럼 바뀐다.

session_id | exam_id   | student_id     | state_id | seat_no | vdi_ip
VDI-2      | <EXAM_ID> | <STUDENT_ID>   | ACTIVE   | 2       | <VDI_PRIVATE_IP_2>

대시보드에서는 해당 좌석이 회색에서 초록색으로 바뀐다.

30. 최종 사용자 흐름

최종 사용자 흐름은 다음과 같다.

서버 부팅
Nginx, MariaDB, FastAPI 서비스 자동 실행
교수자 /professor/ 접속
교수 정보 입력
교수자 /exam/ 접속
시험 정보 입력
기존 VDI row에 현재 exam_id 연결
학생이 VDI 접속
VDI 내부에서 /login/ 자동 실행
학생 이름/학번 입력
FastAPI가 요청 IP 확인
VDI 세션 테이블의 vdi_ip와 매칭
해당 VDI row를 ACTIVE로 변경
대시보드가 세션 API 조회
해당 좌석이 초록색으로 표시

31. 이번 개발에서 발생한 주요 오류와 해결

1) DB 이름 오류

원인:
.env 또는 SQL에서 실제 DB 이름과 다른 값을 사용했다.

해결:
SHOW DATABASES로 실제 DB 이름을 확인하고 .env 값을 맞췄다.

2) 한글 저장 오류

원인:
DB 또는 테이블 문자셋이 한글 저장에 적합하지 않았다.

해결:
주요 한글 저장 테이블을 utf8mb4 계열 문자셋으로 변환했다.

3) Decimal JSON 변환 오류

원인:
MariaDB 집계 결과가 Decimal 타입으로 반환되었고 JSONResponse가 변환하지 못했다.

해결:
Decimal, datetime을 JSON 가능한 값으로 바꾸는 변환 함수를 만들었다.

4) Nginx 50x 오류

원인:
FastAPI가 꺼져 있거나 Nginx 프록시 설정이 올바르지 않았다.

해결:
FastAPI 직접 호출과 Nginx 경유 호출을 분리해서 확인했다.

5) vi swap 파일 오류

원인:
설정 파일 편집 세션이 비정상 종료되었거나 동시 편집 가능성이 있었다.

해결:
프로세스 확인 후 백업하고 swap 파일을 정리했다.

6) address already in use

원인:
FastAPI 서비스가 이미 8000번 포트를 사용 중인데 직접 uvicorn을 다시 실행했다.

해결:
직접 uvicorn 실행을 중단하고 systemd 서비스로만 관리했다.

7) 학생 로그인 404

원인:
API 경로 자체가 없어서가 아니라, 요청 IP와 VDI 세션 테이블의 vdi_ip가 매칭되지 않았다.

해결:
VDI access log에서 실제 요청 IP를 확인하고, VDI 세션 테이블의 vdi_ip와 exam_id를 맞췄다.

8) 학번 9자리 검증 오류

원인:
HTML maxlength가 먼저 적용되어 붙여넣기 값이 잘리고, JS에서 숫자만 추출하면서 8자리로 인식되었다.

해결:
HTML maxlength를 제거하고 JS에서 숫자만 추출한 뒤 9자리 검증을 수행했다.

32. 보안상 공개하지 않은 정보

공개 블로그에는 다음 정보는 실제 값으로 적지 않았다.

실제 서버 공인 IP
실제 VDI 내부 IP
실제 DB 이름
실제 DB 계정
실제 프로젝트 경로
실제 로그 원문
실제 학생 이름
실제 학번
실제 교수 식별번호
실제 Nginx 설정 파일 경로
실제 systemd 서비스명

대신 다음과 같이 마스킹했다.

<SERVER_PUBLIC_IP>
<VDI_GATEWAY_IP>
<VDI_PRIVATE_IP>
<DB_NAME>
<DB_USER>
<BACKEND_PROJECT_DIR>
<FASTAPI_SERVICE_NAME>
<STUDENT_ID>
<PROFESSOR_ID>

33. 최종 정리

이번 작업을 통해 기존 프론트엔드 중심 대시보드는 실제 DB와 연결된 VDI 시험 감독 대시보드로 발전했다.

핵심 성과는 다음과 같다.

FastAPI 기반 백엔드 API 구축
MariaDB와 교수/학생/시험/VDI 세션 데이터 연동
Nginx reverse proxy 설정
VDI 내부 IP 기반 좌석 식별 구조 설계
교수 대시보드와 DB 상태 연동
학생 로그인 시 좌석 상태 자동 변경
FastAPI systemd 서비스 등록
실제 운영을 고려한 서버 관리 방식 정리

처음에는 단순히 학생 이름과 학번을 DB에 저장하는 기능처럼 보였지만, 실제 구현 과정에서는 VDI 네트워크 구조, NAT 환경, Nginx reverse proxy, DB 세션 설계, systemd 운영 방식까지 함께 고려해야 했다.

특히 가장 중요한 설계 변경은 학생별 URL을 따로 주지 않고, 같은 로그인 URL을 사용하면서 요청 IP 기반으로 VDI 좌석을 식별하도록 만든 것이었다.

이 구조 덕분에 학생은 복잡한 URL을 알 필요 없이 VDI에 접속해 이름과 학번만 입력하면 되고, 교수자는 대시보드에서 실시간으로 어떤 좌석이 접속했는지 확인할 수 있다.

향후에는 프록시 로그 또는 정책 위반 탐지 결과를 VDI 세션과 연결해, 단순 접속 상태뿐 아니라 시험 중 이상 행위 탐지 결과까지 대시보드와 최종 보고서에 연결할 수 있다.

Rocky Linux 기반 KVM/libvirt 가상화 환경 구축

otopligrm — Wed, 15 Apr 2026 17:58:38 +0900

Rocky Linux 서버 위에 KVM/libvirt 기반 가상화 환경을 만들고,
그 위에 Windows VM을 생성한 뒤, VNC로 설치 화면에 접속하도록 설정을하였다

dnf install -y epel-release

EPEL 저장소 를 시스템에 추가해주는 패키지이다.
필요한 패키지가 기본 저장소에 없을 수도 있고, 패키지 설치의 범위를 넓히고,

후에 의존성 문제를 줄이기 위해서이다.

dnf install -y qemu-kvm libvirt virt-install virt-manager virt-viewer bridge-utils libguestfs-tools

가상화에 필요한 핵심 패키지인 QEMU,KVM 등을 설치한다.

QEMU,KVM에 대한 설명은 https://otopligrm.tistory.com/39여기를 참고

systemctl enable --now libvirtd

libvirtd 서비스를 지금 바로 시작하고, 부팅할때 자동으로 시작되도록 등록한다
여기서 libvirt는 가상 머신을 관리하는 표준 관리 계층이다.

virt-host-validate

서버가KVM 호스트로 정상 동작할 준비가 되었는지 검증하는 명령이다.
예를 들면 CPU가상화 지원을 확인하고(VT-x/AMD-V)
KVM모듈 상태 등 적절한 상태인지 점검을한다.

virsh net-list --all

VM이 붙을 가상 네트워크가 있는지확인하고, NAT 네트워크가 살아 있는지 확인한다.
왜냐하면 VM을 만들때 네트워크를 network = default로 붙일 예정이기 때문이다.

default network는 KVM으로 만든 VM들이 인터넷도 나가고

서로도 연결될 수 있게 해주는 기본 NAT 네트워크이다.

virsh net-autostart default

default 네트워크를 서버 부팅 시 자동으로 올라오게 설정한다.

virsh net-start default

default 네트워크를 바로 시작한다.

virt-install --name win10-vdi21 --ram 3072 --vcpus 2 --disk path=/home/kvm_num_1/win10-vdi24.qcow2,size=50 --
os-variant win10 --network network=default --graphics vnc,listen=0.0.0.0,port=5903 --cdrom

명령어 순서대로 이름은 win10-vdi21, RAM은 3GB, CPU는 2코어로 할당하고,
path=/home/kvm_num_1/win10-vdi24.qcow2 = VM의 가상 디스크 파일 위치를 지정.
qcow2는 QEMU의 디스크 포맷 중 하나이다.

그다음 다시 순서대로 가상 디스크의 용량은 50GB,
os는 윈도우 10 계열 예정이고, libvirt의 default 네트워크에 이 VM을 연결한다.
--graphics vnc,listen=0.0.0.0,port=5903 = VM의 그래픽을 VNC방식으로 제공하며,

서버의 모든 네트워크(0.0.0.0)에서 접속을 허용한다. 그리고 설정 포트는 5903

근데 이것은 모든 ip주소에서 들어오는 vnc 접속을 받겠다는 것이라서 보안상 조심해야한다.

접속 ip를 제한하거나, 방화벽 제한 등이 필요하다고 생각한다.

firewall-cmd --permanent --add-port=5903/tcp

위에서 설정한 5903 포트를 서버 방화벽에서 영구적으로 허용을한다.
VNC는 일반적으로 TCP기반이라서 TCP를 사용한다.

firewall-cmd --reload

방금 추가한 방화벽 규칙을 지금 실행하고 있는 방화벽에 다시 한번 적용을한다.

firewall-cmd --list-all

5903/TCP가 열렸는지 확인을하기 위해 현재 방화벽 설정을 보여준다.

virsh edit win10-vdi21

편집기를 열어 <boot dev='cdrom'/>을 추가해준다.

그 이유는 처음 부팅할때 ISO파일이 있는 CDROM 장치로 먼저 부팅을하기 위해서이다.

virsh destroy win10-vdi21

방금 설정을 수정하였기 때문에 수정한 설정을 적용하기 위해서 VM을 끈다.

virsh start win10-vdi21

win-vdi21을 이제 다시 시작한다

KVM과 QEMU

otopligrm — Sat, 11 Apr 2026 21:57:52 +0900

먼저 이번 내용들을 적기전에 하나 이야기하자면,

그전까지는 경어체를 사용해서 블로그를 적었는데 뭔가 가식적이고 나답지않다는

생각이 들었다. 그래서 앞으로는 그냥 편하게 적으려고한다.

KVM

kvm은 Kernel-based Virtual Machine의 줄임말이다.

리눅스 커널이 가상화를 직접 담당하는 기술이다.

또한 리눅스 커널이 하이퍼바이저 역할을 수행하도록 만들어주는 모듈이다.

즉 kvm은 이러한 기능들을 수행하기 위해서 리눅스 커널에 들어가는 모듈이다.

그럼 여기서 커널이 무엇이냐.

커널은 일단 운영체제의 핵심이다. 주로 메모리관리, 디바이스제어, cpu 관리

즉 하드웨어를 다루는 가장 핵심이다. 컴퓨터 자원을 관리한다고 생각하면 된다.

또한 하드웨어와 응용프로그램 사이에서 인터페이스를 제공해준다.

방금 이야기 했듯이 커널은 프로세스, 메모리, 네트워크 등을 관리하는데

kvm은 vm용 가상 cpu를 실행, vm메모리 관리, 하드웨어 가상화 기능 사용 등 이러한 기능들을 수행하게 된다.

한마디로 커널은 운영체제의 핵심이지만 kvm에서는 이에 더불어 가상화의 핵심 역할도 맡아서 한다고 생각하면 된다.

하이퍼바이저는 무엇이냐.

실제 서버 위에서 vm을 할당해주는 관리자라고 생각하면 된다.
하이버바이저와 관련된 개념은 가상 데스크톱 인프라(VDI) 개념 을참고하면 좋을 것 같다.

나도 하이퍼바이저 개념을 까먹었었는데 제가 적은 블로그들을 다시 한 번 훑어보면서

다시 개념들을 상기시켰다.

하이버바이저는 2가지 타입이있는데

하드웨어 위에 올라가는 방식과 운영체게 위에 프로그램처럼 올라가는 방식이 있다.

하이퍼 바이저의 타입에 대해서 조사를 해보면서 kvm은 당연히 리눅스 위에서 동작을 하기에

운영체제에 올라가는 방식이라고 생각을 했는데

리눅스 커널 자체가 하이퍼바이저 역할을하기 때문에 하드웨어에 올라가는 방식이다.

쉽게 말하면 리눅스 커널이 가상화 기능을 제공하기 때문이다.

kvm의 자세한 역할은

CPU 가상화: VT-x/AMD-V 같은 하드웨어 가상화 기능을 커널에서 활용
메모리 분리: VM마다 독립된 메모리 공간을 사용하도록 격리.
안정성과 보안때문에 메모리 분리는 중요하다.
디스크 가상화: 가상 디스크 이미지/스토리지 장치를 VM에 제공.
여기서 디스크 가상화는 SSD를 통째로 주는것이 아닌
호스트 pc에 있는 파일을 vm이 디스크처럼 사용하는 것이다.
네트워크 가상화: 브리지/가상 NIC 등을 통해 VM 네트워크 구성
NIC는 가상 랜카드를 말하는 것이다.

VT-x, AMD-V

CPU 제조사가 넣은 하드웨어 가상화 기능이다.

이 기능이 있으면 CPU가 알아서 VM용 코드인지, 호스트용 코드인지 구분을 해준다

kvm은 이러한 cpu가 제공하는 가상화 기능을 리눅스 커널에서 활용하는거다.

QEMU

가상 하드웨어 에뮬레이션 및 VM 실행을 보조해준다.

컴퓨터는 그래픽 카드, 키보드, 마우스 이러한 것들이 있어야한다.

이러한 가상 컴퓨터의 부품을 만들어주는 기술이라고 생각하면 될 것 같다.

CPU는 빠르게 가상화를 할 수 있지만

같은 I/O는 가상 장치를 거치기때문에 영향이 생길 수 있다.

따라서 passthrough같은 고급 설정이 중요하다.

또한 GPU는 VM 구성에서는 많이 제한적일 수 있다.

이러한 제한적인 문제를 해결하기 위해서는 GPU passthrough 같은 고급 설정이 필요하다

이 방식은 물리 GPU를 특정 VM에 거의 직접 할당하는 방식이다.

리눅스 프로그램 설치 방법과 빌드 개념 정리

otopligrm — Thu, 9 Apr 2026 20:58:04 +0900

리눅스에서 프로그램을 설치하는 방법 총 3가지가 있습니다

1. 패키지로 설치

이미 누군가가 빌드해둔 것을 가져와서 설치하는 방식입니다.
예를 들면
Rocky / RHEL 계열: dnf, yum
Ubuntu / Debian 계열: deb, apt

그럼여기서 패키지란 무엇이냐.

이 프로그램을 설치하려면 필요한 부가적인 파일들을 전부 묶어놓은 것입니다.
패키지 안에는 보통 실행 파일(binary), 설정 파일(config), 라이브러리,

의존성(dependency) 정보 등이 있습니다.

그러면 이제 의존성(dependency)이 무엇이냐.
의미 그대로 의존을 한다는 것입니다.

A라는 프로그램이 동작하기 위해서는 다른 프로그램이나, 모듈이 필요하다. 이런뜻입니다.

예를 들어 python이 동작하기 위해서는 requests, flask가 필요합니다.

즉 혼자서는 동작 할 수 없고 동작하기 위해서는 다른 친구들이 함께 필요합니다.

장점: 가장 편하다. 파일을 어디에 배치할지,
라이브러리는 무엇인지 패키지가 어느정도 관리를 해주기 때문입니다

2. 소스코드로 설치.

개발자가 공개한 소스코드를 직접 컴파일해서 설치하는 방식입니다.
예를 들면 configure, make, make install

단점은 컴파일 도구가 필요하며, 라이브러리가 필요합니다.

여기서 컴파일이 무엇이냐.

소스코드는 사람이 작성한 코드입니다. 사람이 작성했으니 사람이 읽을 수 있는 코드입니다.

사람이 작성한 이 코드를 컴퓨터가 실행 할 수 있는 형태로 바꾸는 과정이 컴파일입니다.

사람이 작성한 코드(소스코드) →변환(컴파일) → 컴퓨터가 실행하는 파일(바이너리)

예를 들어

위의 코드는 사람이 짠 코드이죠? 이게 소스코드입니다.
이 소스코드를 컴파일하면 a.out같은 바이너리(실행 파일)이 만들어집니다.
당연히 사람이 읽기 어렵고 컴퓨터가 읽고 바로 실행 할 수 있습니다

그럼 이제 직접 컴파일해서 설치한다는 것은 소스코드를 받아서

내 서버에서 직접 실행파일로 만든다음에 이제 실행파일로 설치한다는 의미입니다.

3.바이너리(binary)로 설치.

바이너리 즉 실행 파일만 받아서 제가 원하는 경로에 복사하는 방식입니다.

즉 위에서 컴파일에 대해서 설명을 했듯이 이미 컴파일된 실행 파일을

그대로 가져와서 경로에 복사해두고 실행하는 방식입니다.

바이너리를 어디로 옮겨라: 실행 파일을 원하는 경로에 복사하고,
그 경로의 파일에게 실행 권한을줍니다.권한 주는것 잊으면 안됩니다.
명령어로 잡아서 사용을 할 것이라면
PATH에 해당 파일의 경로가 등록되어 있어야합니다.

sudo cp taewoo /usr/local/bin/

sudo chmod +x /usr/local/bin/taewoo

리눅스에서 보통 PATH에 잡혀 있는 대표 경로는

/usr.bin(사용자 명령어), /bin(기본적인 필수 명령어), /sbin (시스템 관리용 명령어)

/usr/sbin(더 많은 시스템 관리 명령어), /usr/local/bin(직접 설치,수동으로 넣은 파일들)

4. Makefile.

프로그램을 어떻게 빌드 할 것인지 적어둔 것입니다.

어떤 소스파일을 컴파일 할 것인지, 어떤 옵션으로 컴파일 할 것인지 등

빌드를 여기에 적힌 방식대로 해라. 이런식의 지시문이라고 생각하면됩니다.

5. Make.

Make는 Makefile을 읽고 실제로 빌드를 실행하는 도구(?)입니다.

쉽게 비유를 하자면 Makefile은 설계도이고, Make는 실행자입니다.

6. Configure.

보통 소스코드 프로젝트에서 현재 서버 환경을 검사하고,

그 환경에 맞는 Makefile을 만들어주는 준비 단계입니다.

즉 위의 내용과 연관지어 정리하자면, 이 서버에서 이 프로그램을 빌드할 수 있는지

검사하고, 빌드 지침서를 생성하는 단계입니다.

파일 위치 경로

1. 실행파일(binary)

/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
일반적으로 수동 설치한 건 /usr/local/bin에

2.라이브러리

/usr/lib
/usr/lib64
/usr/local/lib

3. 설정파일

/etc/프로그램명/
/etc/프로그램명.conf

4.서비스 파일(systemd)

/etc/systemd/system/프로그램명.service

5. 로그

/var/log/프로그램명/
/var/log/messages

요약

package: 설치하기 쉽게 묶어놓은 배포 단위
dependency: 프로그램이 동작하려고 필요한 다른 것들
binary: 컴퓨터가 바로 실행할 수 있는 파일
Makefile: 어떻게 빌드할지 적어둔 규칙 파일
make: Makefile을 읽고 실제 빌드하는 도구
configure: 현재 서버 환경을 검사하고 Makefile을 만드는 준비 단계

TLS에 대하여

otopligrm — Tue, 7 Apr 2026 21:57:46 +0900

여기에서는 TLS에 대하여 다룰려고 합니다.

그전에 전 블로그에서 TLS를 끊는다는 표현을 사용했는데

TLS를 끊는다는 표현에 대해서 먼저 설명을하겠습니다.

이후 TLS에 대하여 다루도록 하겠습니다

TLS를 끊는다

네트워크 용어로 SSL/TLS 복호화 또는 SSL Inspection을 의미합니다.

일반적인 HTTPS 통신은 클라이언트(내 컴퓨터)와 서버(웹사이트)가

서로 암호 키를 주고받아 데이터를 암호화하기 때문에,

그 중간에 있는 장비(프록시 서버)는 데이터가 어떤 내용인지 전혀 알 수 없습니다.

단순히 암호화된 택배 상자를 전달만 할 뿐입니다.

하지만 SSL Bump 기능을 사용하면 프록시 서버가 이 흐름의 중간에 개입하여

아래과 같은 과정을 거칩니다.

1. 연결의 분리 (Termination)

프록시 서버가 클라이언트에게는 서버인 척 하고, 실제 서버에게는 클라이언트인 척 합니다.

구간 A: 클라이언트 <---> 프록시 서버 (암호화 연결)
구간 B: 프록시 서버 <---> 실제 웹 서버 (암호화 연결)

즉, 하나의 긴 연결을 중간에서 '끊고' 두 개의 연결로 나누는 것입니다.

2. 데이터의 복호화 및 가공

연결이 프록시에서 일단 끊기기 때문에,

암호화된 데이터는 프록시 서버 내부에서 평문 상태입니다.

그렇기때문에 프록시 서버는 데이터의 내용을 직접 확인할 수 있습니다.

어떤 URL로 접속하는 분석
어떤 프롬포트를 입력하였는지

3. 재암호화 (Re-encryption)

내용 확인이 끝나면 프록시 서버는 다시 데이터를 암호화해서 목적지로 보냅니다.

WSL Ubuntu와 Windows 11 환경에서 Squid SSL Inspection과 mitmproxy를 구축한 과정

otopligrm — Tue, 7 Apr 2026 21:19:42 +0900

프록시 서버 + 트래픽 수집 구간을 만들기 위한 작업을 하였습니다.

실습 내용을 정리하고 다시 공부를하면서도 느끼는것은

프록시 서버를 띄우는것도 중요하지만 HTTPS로 암호화된 웹 요청이

실제로 어떤 구조로 오는지 확인을 하고, 그리고 프록시가 중간에서

역할을 하는지에 대해서 이해는것이 가장 중요하다고 생각합니다.

배경

가장 중요한건 SSL Inspection이라고 생각합니다.

SSL Inspection에 대해서는 제가 따로 정리해 놓은 글이 있습니다

HTTPS는 암호화되어 있기 때문에 Squid의 SSL Bump 기능을 사용해

프록시가 HTTPS 통신을 중간에서 해독할 수 있도록 구성해야 했습니다.

이 작업이 가능하려면 프록시가 각 사이트에 대한 인증서를 대신 만들어 줄 수 있어야 하고,

클라이언트는 그 인증서를 신뢰해야합니다.

결국 이 실습은 프록시 설치가 아니라,

프록시를 하나의 내부 인증 기관처럼 동작시키는 과정이라고 볼 수 있습니다.

squid-openssl 설치

sudo apt update
sudo apt install squid-openssl

중요한 것은 그냥 squid가 아니라 squid-openssl을 설치했다는 것입니다.

그 이유는 제가 사용하려는 기능이 단순 프록시 기능이 아니라 SSL Bump,

즉 HTTPS를 중간에서 처리하는 기능이었기 때문이다.

반드시 squid-openssl 버전을 설치해야

SSL Bump 기능 사용이 가능하다고 정리되어 있습니다.

HTTPS를 다루지 않을 것이라면 일반 squid도 충분할 수 있지만,

저는 중간에서 TLS를 끊고 내부 내용을 봐야 했기 때문에

OpenSSL 지원이 포함된 버전이 필요했습니다.

TLS를 끊는다는 표현에 대한 정리를 해놓았습니다

https://otopligrm.tistory.com/37

내부 CA 인증서를 직접 생성

Squid로 HTTPS를 들여다보려면,

프록시가 클라이언트와 서버 사이에서 클라이언트에게는 서버인 척,

실제 서버에게는 클라이언트인 척 동작해야합니다.

그런데 브라우저는 아무 인증서나 믿지 않습니다.

예를 들어 사용자가 chatgpt.com에 접속했는데,

프록시가 그 사이트 대신 인증서를 내밀면 브라우저는 당연히

이 인증서 발급자는 누구인지를 확인합니다.

그래서 이 문제를 해결하기 위해 내부 CA 인증서를 직접 생성합니다.

먼저 인증서 파일을 저장할 디렉토리를 만들고 권한을 설정했습니다.

sudo mkdir -p /etc/squid/ssl_cert

sudo chown -R proxy:proxy /etc/squid/ssl_cert

sudo chmod 700 /etc/squid/ssl_cert

이 작업을 한 이유는 보안 때문입니다.

일단 인증서? 대충 이름만 들어도 굉장히 중요해보입니다.

근데이 디렉토리 안에는 나중에 CA 개인키가 들어가는데,

이 키는 프록시가 각 사이트의 인증서를 대신 만들어 줄 때 사용하는

매우 중요한 정보입니다. 그래서 Squid가 동작하는 proxy 계정이 접근할 수 있도록

소유권을 주고, 다른 사용자는 접근하지 못하도록 700 권한으로 제한한 것입니다.

만약 이 개인키가 유출되면 그냥 아무래도 큰일이납니다.

인증서 디렉토리 권한 설정은 선택이 아니라 거의 필수라고 볼 수 있습니다.

CA인증서와 키

 
그다음 실제로 키와 루트 CA 인증서를 만들었습니다.
 
openssl genrsa -out /etc/squid/ssl_cert/myCA.key 4096
sudo openssl req -new -x509 -days 3650 -key /etc/squid/ssl_cert/myCA.key -out /etc/squid/ssl_cert/myCA.crt

여기서 myCA.key는 비밀키이면서 루트키입니다

myCA.crt는 myCA.key로 만들어진 공개 인증서입니다.

비밀키와 루트키는 프록시가 사이트별 인증서를 발급할 때 서명하는 데 사용하고,

(안감 도장마냥 결제 서류에 최종 도장을 찍는 느낌입니다.)

비밀키같은 경우 프록시 서버만 갖고 있어야합니다.

공개 인증서는 나중에 Windows에 설치해서 이 CA가 발급한 인증서는 믿겠다.

라고 등록하는 데 사용합니다.

즉, 프록시가 가짜 인증서를 만들어도 브라우저가 그것을 정상으로 인식하게 하려면,

이 내부 CA를 먼저 신뢰하게 만들어야 한다.

왜냐! CA가 인증서를 발급하니까 당연히 CA를 먼저 믿어야겠죠?

그리고 -x509 -days 3650은 자체 서명된 루트 CA 인증서를

오랜 기간 사용할 수 있도록 생성하는 의미입니다.

인증서 생성 과정에서 국가 코드, 지역, 조직명, Common Name 등을 입력하는 이유는

암호화 강도 때문이 아니라,인증서의 주체 정보를 명확하게 표시하기 위함입니다.

나중에 Windows 인증서 저장소에서 이 인증서를 보고

내가 만든 내부 CA이네....라고 식별할 수 있게됩니다.

생성 후에는 아래처럼 파일이 생겼는지 확인했습니다.

sudo ls /etc/squid/ssl_cert

잘 되었다면 myCA.key, myCA.crt가 보여야합니다.

이 확인 과정이 중요한 이유는 이후 모든 설정이 이 파일들을 경로로 참조하기 때문입니다.

systemctl과 service의 차이, 그리고 systemd까지 한 번에 이해하기

otopligrm — Thu, 2 Apr 2026 19:38:02 +0900

systemctl과 service는 둘 다 리눅스에서 시스템 서비스를 관리하는 명령어이다.
먼저 service와 systemctl을 이해하기 위해서는 먼저 systemd에 대한 이해가 필요하다.

먼저 init process는 예전에 많이 사용했던 방식이다.

리눅스가 부팅시에 최초로 실행이되는 프로세스이다.
이 프로세스는 부팅시에 OS운영에 필요한 service을 실행을 시킨다.

1. systemd

리눅스가 부팅되면 제일 먼저 여러 프로그램과 서비스들이 올라온다.
예를 들면 네트워크, SSH 서버, 데이터베이스 등 OS운영을 하기 위해

이러한 서비스들이 자동으로 시작이 되면 시스템이 정상적으로 동작한다.
예전에는 주로 init,SysVinit, service 같은 방식으로 관리를 하였지만

점점 더 시스템이 복잡해지면서 빠르게 관리 할 필요가 생겼고,

그래서 지금 많은 사람들이 사용하는 것이 systemd이다.

즉 이러한 서비스들과 시스템의 전반적인것을 관리하는것이 systemd이라고 생각하면 될 것 같다.
조금 더 쉽게 말하면 service는 systemd가 관리하는 여러 대상들중에서 하나이다.

또한 점점 systemd로 이용방식이 바뀌어가면서 service의 실행 방식이 바뀌었다.

systemd의 장점은

service 병렬 실행가능
boot time감소
자동 의존성 관리 등이 있다.

systemd의 역할은 주로

부팅 과정 관리
서비스 시작/중지 관리
서비스 간 의존성 관리
자동 실행 관리
시스템 상태 추적 등이 있다.

2. service

리눅스가 부팅되었을 때 생성되어서 종료될 때까지 실행되는 프로세스 및 설정 파일을 service 라고 한다.
service는 /etc/systemd/system 경로에 존재한다.
service는 주로 서비스의 시작.중지.재시작,상태 확인을 하는데에 명령어를 사용한다

1. service {서비스 이름} start: 서비스 시작
2. service {서비스 이름} stop: 서비스 종료
3. service {서비스 이름} restart: 서비스 재시작
4. service {서비스 이름} condrestart: 서비스가 동작하고 있는 경우 재시작
5. service {서비스 이름} reload: 서비스 설정 reload
6. service {서비스 이름} status: 서비스 상태 확인

3. systemctl

systemctl은 systemd를 제어하는 명령어이다.

systemctl의 핵심은 서비스를 관리한다는거다.

예를 들어서

SSH 서버를 켜고 싶다
웹 서버가 살아 있는지 보고 싶다
재부팅 후에도 자동 실행되게 하고 싶다
이런 상황일때 systemctl를 사용한다.

그러면 여기서 서비스가 무엇이냐.

서비스는 백그라운드에서 계속 동작을 하면서 특정 기능을 제공하는 프로그램이다.

예를 들면 sshd: 원격 접속을 제공하는것처럼 이러한 서비스들을 사용자가

매번 직접 실행을하지않아도 시스템이 알아서 부팅될 때 자동을 실행이되거나 필요할 때

제어를 할 수 있어야하는데 이런 제어를 systemctl가 한다.

또한 systemctl이 가장 많이 하는 일은
1. 서비스가 실행중인지 여부를 판단: systemctl status sshd
2. 서비스 실행: systemctl start sshd
3. 서비스 중지: systemctl stop sshd
4. 서비스 다시 시작: systemctl restart sshd
5. 다시 불러오기 reload 가 있다

Vi 편집기 주요 명령어 정리

otopligrm — Wed, 1 Apr 2026 15:09:18 +0900

먼저 vi 편집기는 명령모드, 입력모드, 콜론모(마지막 행) 총 3가지가 있다.

그러면 Vi 편집기란 무엇일까?

Vi 편집기: 리눅스에서 기본으로 제공하는 문서 편집기이다.

vi의 설정은 vimrc 파일을 변경하여 수정 할 수 있다.

vimrc 파일은 cd 명령어로 홈으로 이동하여 만들어주면 된다.

cd ~ (홈으로 이동) → vi .vimrc(vi 명령어로 vimrc 파일 생성)

VI와 VIM의 차이

vi는 편집기는 유닉스의 가장 기본적인 편집 에디터이며,

vim은 vi improved의 약자로 vi의 확장 버전입니다. 즉 vi에 기능들이 더 추가되어있다.

vi와 vim의 가장 큰 차이는 화살표 방향키로 커서 이동의 여부이다.

대부분의 리눅스에는 vi를 호출하여도 vim이 실행되도록 설정 되어있지만,

도커 이미지를 이용한 설치 등 최소 기준으로 리눅스를 설치한 경우

vim편집기가 없을 수 도 있다.

명령모드

단축키를 사용해서 커서의 이동, 수정, 삭제, 복사, 붙여넣기 등 명령을 수행한다.

w : 다음 단어 시작으로 이동
b : 이전 단어 시작으로 이동
0 : 현재 줄 맨 앞
gg : 파일 맨 처음
G : 파일 맨 끝
x : 현재 문자 1개 삭제
dd : 현재 줄 전체 삭제
yy : 현재 줄 복사
p: 붙여넣기
u : 방금 작업 취소
/문자열 : 아래 방향 검색
n : 다음 검색 결과
Shift+Z를 두 번: 저장 후 종료

입력모드

i : 현재 커서 위치에서 입력 시작
a : 현재 커서 다음 칸에서 입력 시작
o : 현재 줄 아래에 새 줄 만들고 입력 시작
A: 현재 줄의 맨 앞에서 입력 시작
I: 현재 줄의 맨 앞에서 입력 시작

콜론 모드

:w → 저장
:q → 종료
:wq → 저장 후 종료
:q! → 저장 안 하고 강제 종료
:wq! : 강제로 저장 후 종료가 필요한 상황에서 사용

모드 전환

:(콜론) : 콜론 모드로
i : 현재 커서 위치에서 입력 시작
a : 현재 커서 다음 칸에서 입력 시작
o : 현재 줄 아래 새 줄 만들고 입력 시작

Rocky Linux 기반 서버 구축 및 네트워크 초기 설정

otopligrm — Tue, 31 Mar 2026 19:44:10 +0900

배경

먼저 배경은 이렇습니다.

학과 서버실이 오랫동안 방치 되어있었는데,

저희는 교수님께 사전에 허락을 구한 뒤, 학과 서버를 사용할 수 있게 되었습니다.

학과 서버실에 배치되어있는 서버를 이용해서 무엇을 개발할 예정인지는 추후에 작성하도록하겠습니다.

서버는 총 6대가 있으며, 저는 첫번째 서버를 선택하여서 부팅을 진행하였습니다.

하지만 해당 서버에 OS, 즉 운영체제가 설치되어 있지 않았기 때문에

Rocky Linux를 설치하게 되었습니다.

Rocky Linux란?

Rocky Linux 란. Red Hat 계열의 리눅스 운영체제입니다.

많은 분들이 데비안 계열의 Ubuntu(우분투)를 많이 사용하실텐데

왜 굳이 Rocky Linux 를 선택했는지 의문점이 드실겁니다.

사실 대단한 이유가 있는것은 아닙니다. 네트워크 공부를 하는 학생으로서,

친숙한 우분투보다는 평소에 거의 사용해보지않은 Rocky Linux를 직접 설치해보고

다루어 보고 싶었습니다.

우분투에서는 패키지를 관리할 때 apt 명령어를 사용하지만,

Rocky Linux 에서는 주로 dnf, yum 명령어를 사용합니다.

친숙하지는 않지만 새롭게 더 배워가는 느낌이 들어서 좋습니다.

Rocky Linux 설치 과정

먼저 저는 개인 USB에 Rocky Linux 9.7버전을 다운 받았습니다.

9.7버전 선택의 이유는 새로운 버전은 업데이트 될 때 마다 9.1, 9.2 이런식으로 수정이됩니다. 10버전이 가장 최신이지만 혹시 모르는 오류와 위험성을 고려하여 구 버전중 가장 최신 버전인 9.7버전을 선택하게 되었습니다.

서버 부팅 후 Boot Manager에 들어온 뒤,아래의 사진처럼

Boot Menu를 선택하여 부팅할 장치를 지정하였습니다.

그 다음 부팅 장치 목록에서 Rocky Linux 설치 USB를 선택하여,

USB에 저장했던 운영체제 파일로 부팅을 진행하였습니다

부팅이 진행되고, 이후 GRUB 화면이 나타났습니다.

여기서 install Rocky Linux 9.7을 선택하여 설치를 진행하였습니다

이후, Rocky Linux 설치에 필요한 파일들을 불러오기 시작했습니다.

Rocky Linux 설치 화면에 접속해서 먼저 Installation Destination 항목에서

OS를 설치할 하드 디스크를 선택하였습니다.

저는 서버 내부의 저장 장치에 OS를 설치할 예정입니다

그다음 Software Selection 항목에서는 Server with GUI가 아닌 Server를 선택하였습니다.
이유는 서버를 SSH를 통한 원격 접속을 목적으로 사용할 예정이었기 때문입니다.

그 다음 Network & Host Name 항목에서 이더넷 포트 중

실제로 연결된 포트를 선택하였습니다.
그치만 세부 네트워크 설정은 자동으로 처리하지 않고,

이후 CLI 환경에서 직접 수동으로 설정하기로 하였습니다.

다음으로 Root Password 항목에서 root 계정의 비밀번호를 설정하였습니다.
root 계정으로만 작업을 할 예정이라서 일반 user 계정은 생성하지 않았습니다..

모든 기본 설정을 마친 뒤 설치를 시작하였고,

설치가 완료된 후에는 CLI 화면에서 root 계정으로 로그인하였습니다.

nmtui에서 네트워크 설정

이후 SSH 환경을 구성하기 위해 dnf install openssh-server를 입력하여

SSH 서버 설치를 시도하였습니다.

하지만 인터넷 연결이 정상적으로 설정되어 있지 않아 에러가 발생하였습니다.

따라서 CLI에서 nmtui를 입력하여 nmtui로 이동하였습니다.

여기서 앞서 확인했었던 4번째 Ethernet를 선택하고,

wifi가 아닌 Ethernet이며, IPv4 네트워크를 사용할 것이라서

환경에 맞게 설정을 하였습니다.

nmtui 화면

네트워크 설정 방식은 자동이 아닌, manual를 선택하였습니다.

그 이유는 IP를 자동으로 할당 받는 것이 아닌 직접 주소를 입력하고, 관리하기 위해서입니다.

이후 Address, Gateway, DNS 를 수동으로 입력하여

네트워크를 설정하였습니다.

네트워크 설정을 완료 한 뒤, ifconfig를 입력하여
설정한 IP 주소가 선택한 이더넷에 정상적으로 적용되었는지 확인하였습니다.

이후 ping 목적지 IP 명령어를 사용하여 네트워크 통신 여부를 점검하였습니다.

ping은 설정한 주소와 통신이 가능한지 확인하는 명령어입니다,
네트워크가 정상적으로 연결되어 있는지, 그리고 학교처럼 동일한 IP 대역을 사용하는 곳에서
충돌 가능성이 있는지를 확인하는데 활용을 했습니다.

IP충돌이 발생하면 접속이 끊기는 현상이 발생하며,
심할 경우 두 장비 모두 정상적으로 네트워크 사용이 안될 수도 있습니다

이후 다시 시도한 dnf install openssh-server 명령어에서 다시 한 번 더 설치가 진행되지않았습니다.

저장소 설정

처음에는 단순하게 mirror 모드는 단순하게 읽기 모드이며,

지금 현재 mirror 모드로 설정 되어있기에 패키지가 다운이 안되는 줄 알았습니다.

구글링을 해본 결과, mirror모드라서 패키지 설치가 불가능했던 것이 아닌

입력했던 dnf install openssh-server 명령어에서 dnf가 저장소 정보를

정확하게 사용하지 못했다는 것을 알았습니다.

dnf는 저장소(Repository)에 접속하여 패키지를 다운로드 한 다음,
설치를 하는 방식입니다.

그래서 저는 root계정으로 저장소 파일을 직접 설정하였습니다.

먼저 dnf가 어디에서 ssh server를 다운로드 하는지 경로를 파악
확인한 저장소 주소에 접근.

즉 패키지를 저장할 경로를 수정했다고 생각하시면 될 것 같습니다.

일단 그래서 저는 cd /etc/yum.repos.d/ 명령어로 repos.d 파일로 이동했습니다.

etc: 리눅스에서 시스템 전반의 설정 파일들이 모여 있는 디렉터리입니다.
repos.d : 패키지 저장소 설정 파일들이 들어 있는 곳입니다.
repo: dnf가 어느 저장소를 사용할지 알려주는 설정 파일입니다.

이후 ls 명령어로 repos.d 내부 파일들을 확인하였고, rocky.repo를 선택했습니다.

rocky.repo: Rocky Linux의 기본 저장소 정보를 담고 있는 설정 파일입니다.
여러가지 정보들이 있지만 제가 받으려는 ssh패키지를
어디서 다운을 받을 것인지 주소 정보가 들어있습니다.

그리고 rocky.repo를 수정하기 위해서 vi rocky.repo 명령어를 입력했습니다

vi: 파일을 열어서 볼 수 있고, 수정 할 수 있는 명령어입니다

파일일들을 확인하면서 mirrow.list 주소를 주석처리하고,

기존에 주석처리 되어있던 baseurl의 주소를 주석해제 하였습니다.

mirror.list와 baseurl에 대해서는 저도 잘 몰라서 개인적으로 공부 한 뒤,

추후에 설명을 올리도록하겠습니다.

원인

제가 블로그를 적으며, 설치 및 설정 과정들을 복습해본 결과.

원인은 운영체제 설치 및 설정을 하는과정에서 자동이 아닌 수동을 대부분 설정을 하였기에

자동 mirror 선택 과정에서 문제가 있었으며, 앞서 ip와 gateway, DNS를 수동으로 설정을 하였기에

baseurl은 접근 가능했던 경우라고 생각합니다. 확실한건 절대 아닙니다.