아닙니다.

Slurm 개념을 이해했으면, 이제는 진짜로 GPU 잡아서 뭔가 돌아가는 경험을 한 번 해야 한다. 근데 여기서 gpt2 같은 걸 돌리면 솔직히 감이 안 옴...! “GPU를 쓴 게 맞나?” 싶은 느낌이 남는다.

그래서 모델은 너무 크진 않지만, LLM 돌린 느낌은 확실한 것으로 예제를 준비했다! microsoft/phi-2 (2.7B) 정도면 딱 적당하다.

GPU 빈 노드 확인 → debug로 들어가서 테스트 → batch로 제출 → 로그로 결과 확인

(마스터) 작업 디렉토리 준비

실습은 무조건 폴더부터 잡고 시작하는 게 좋다. 로그랑 결과물이 남아야 디버깅이 된다.

mkdir -p /data/username/repos/slurm_practice
cd /data/username/repos/slurm_practice
mkdir -p logs outputs

GPU 비어있는 노드 확인 → interactive 접속

1-1) 비어있는 GPU 노드 확인

일단 “GPU가 지금 어디 비었는지”부터 본다.

slurm-gres-viz -i

여기서 idle/free 인 노드 하나 고르면 된다. 예: aurora-g5

1-2) 그 노드로 접속 (debug_ugrad)

그리고 debug 파티션에서 GPU 1장짜리 쉘을 하나 받는다.

srun --gres=gpu:1 --cpus-per-gpu=1 --mem-per-gpu=16G \
  -p debug_ugrad --account=ugrad \
  -w aurora-g5 \
  --pty $SHELL

접속 확인은 이걸로 끝난다.

hostname
nvidia-smi

여기서 nvidia-smi가 뜨면, 이제 “GPU 노드 안에 들어왔다”는 뜻이다. 그럼 이제 진짜로 코드 돌리면 된다.

(GPU 노드) LLM 추론 코드 작성 (phi-2)

2-1) llm_phi2_infer.py 생성

이제 LLM 추론 코드를 만든다. 이건 학습이 아니라 “모델 로드 + 생성 한 번”만 하는 코드다.

cd /data/username/repos/slurm_practice

cat > llm_phi2_infer.py << 'EOF'
import time
import torch
from transformers import AutoTokenizer, AutoModelForCausalLM

MODEL_ID = "microsoft/phi-2"

print("[INFO] cuda available:", torch.cuda.is_available())
if torch.cuda.is_available():
    print("[INFO] device:", torch.cuda.get_device_name(0))
device = "cuda" if torch.cuda.is_available() else "cpu"

t0 = time.time()
tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)
model = AutoModelForCausalLM.from_pretrained(
    MODEL_ID,
    torch_dtype=torch.float16 if device == "cuda" else torch.float32,
    device_map="auto" if device == "cuda" else None
)
t1 = time.time()
print(f"[INFO] model load time: {t1 - t0:.2f}s")

prompt = """You are a helpful assistant.
Explain Slurm in 5 bullet points for a beginner who uses an HPC GPU cluster.
"""

inputs = tokenizer(prompt, return_tensors="pt")
if device == "cuda":
    inputs = {k: v.to("cuda") for k, v in inputs.items()}

gen_t0 = time.time()
with torch.no_grad():
    out = model.generate(
        **inputs,
        max_new_tokens=180,
        do_sample=True,
        temperature=0.7,
        top_p=0.9,
        repetition_penalty=1.05
    )
gen_t1 = time.time()

print(f"[INFO] generation time: {gen_t1 - gen_t0:.2f}s")
print("----- OUTPUT -----")
print(tokenizer.decode(out[0], skip_special_tokens=True))
EOF

코드 설명

이 코드는 Hugging Face Transformers와 PyTorch를 이용해서 마이크로소프트의 언어모델 phi-2(microsoft/phi-2) 를 불러온 뒤, 프롬프트(prompt)를 입력으로 주고 텍스트를 생성(inference) 하는 예제입니다.

실행하면 먼저 GPU(CUDA)를 사용할 수 있는지 확인하고, 가능하면 GPU 이름까지 출력한 다음(torch.cuda.is_available(), torch.cuda.get_device_name(0)), 사용할 장치를 cuda 또는 cpu로 정합니다. 그 다음 모델 로딩 시간을 재기 위해 time.time()으로 시작 시간을 찍고, AutoTokenizer.from_pretrained()로 토크나이저를 다운로드/로드하고, **AutoModelForCausalLM.from_pretrained()로 실제 텍스트 생성 모델을 불러옵니다. 이때 GPU를 쓰는 경우 속도와 메모리 효율을 위해 float16을 사용하고(torch_dtype=torch.float16), device_map="auto"로 모델을 자동으로 GPU에 올리도록 설정합니다. 이후 prompt 변수에 “Slurm을 초보자에게 5개 bullet로 설명하라”는 지시문이 들어 있고, 토크나이저로 이를 숫자 토큰 텐서로 변환합니다(tokenizer(prompt, return_tensors="pt")). 만약 GPU를 쓰는 환경이면 입력 텐서도 GPU로 옮겨야 모델과 같은 장치에서 계산할 수 있으므로 inputs = {k: v.to("cuda") ...}로 이동합니다. 생성 단계에서는 torch.no_grad()로 **추론 중에는 그래디언트 계산을 끄고 메모리를 절약하며, model.generate()를 통해 새 토큰을 최대 180개까지 생성합니다. 또한 do_sample=True, temperature=0.7, top_p=0.9는 확률적으로 샘플링하는 생성 방식이라 답변이 매번 조금씩 달라질 수 있고, repetition_penalty=1.05는 같은 표현을 반복하는 현상을 줄이기 위한 옵션입니다. 마지막으로 생성 시간도 출력하고, tokenizer.decode(..., skip_special_tokens=True)로 토큰을 사람이 읽을 수 있는 텍스트로 복원해 최종 결과를 출력합니다.

2-2) interactive에서 바로 실행 (디버깅)

여기서 바로 한 번 실행해본다.

python3 llm_phi2_infer.py

출력이 잘 나오면 이 단계는 끝이다. 중요한 건 “코드가 잘 돌아간다”가 아니라 GPU에서 정상적으로 모델이 로드되고 생성까지 한다는 걸 확인하는 거다.

여기서 터지면 대부분 원인이 뻔하다.

• transformers/torch 버전 문제
• CUDA 인식 문제
• 모델 다운로드/캐시 문제

(마스터) 배치 제출 스크립트 작성 (batch_ugrad)

interactive 쉘에서 테스트가 끝났으면, 이제 진짜 Slurm답게 batch로 제출한다. interactive는 “확인용”이고, batch는 “운영용”이다.

먼저 interactive에서 빠져나온다.

exit

3-1) phi2_infer.sbatch 생성

이제 배치 스크립트를 만든다. 로그 경로를 아예 박아두면 나중에 찾기 편하다.

cd /data/username/repos/slurm_practice

cat > phi2_infer.sbatch << 'EOF'
#!/usr/bin/bash
#SBATCH -J phi2_infer
#SBATCH -p batch_ugrad
#SBATCH --account=ugrad
#SBATCH --gres=gpu:1
#SBATCH --cpus-per-gpu=4
#SBATCH --mem-per-gpu=20G
#SBATCH -t 00:10:00
#SBATCH -o /data/username/repos/slurm_practice/logs/slurm-%A_phi2.out
#SBATCH -e /data/username/repos/slurm_practice/logs/slurm-%A_phi2.err

cd /data/username/repos/slurm_practice

echo "[INFO] host=$(hostname)"
echo "[INFO] pwd=$(pwd)"
which python
python3 llm_phi2_infer.py

exit 0
EOF

phi2_infer.sbatch는 Slurm에서 배치 잡(job) 으로 실행할 설정과 실행 명령을 담은 스크립트입니다.

맨 위 #!/usr/bin/bash는 이 파일을 실행할 때 bash 셸로 해석하라는 의미입니다. 그 아래 #SBATCH로 시작하는 줄들은 Slurm에 전달되는 자원 요청/잡 설정 옵션들인데, -J phi2_infer는 잡 이름을 phi2_infer로 지정하고, -p batch_ugrad는 제출할 파티션(큐)을 batch_ugrad로 선택합니다. --account=ugrad는 어떤 계정(과금/사용 권한 그룹)으로 자원을 쓸지 지정하는 옵션이고, --gres=gpu:1은 GPU 1장을 요청합니다. --cpus-per-gpu=4는 GPU 1장당 CPU 코어 4개를 같이 달라고 요청하는 설정이며, --mem-per-gpu=20G는 GPU 1장당 메모리를 20GB 할당해 달라는 의미입니다. -t 00:10:00은 최대 실행 시간을 10분으로 제한하고, -o ...slurm-%A_phi2.out는 표준 출력(stdout)을 저장할 로그 파일 경로를 지정합니다. 여기서 %A는 Slurm이 자동으로 넣어주는 잡 ID라서 실행할 때마다 다른 파일명으로 기록됩니다. -e ...slurm-%A_phi2.err는 표준 에러(stderr)를 저장할 파일 경로입니다.

그 다음 본문에서는 cd /data/username/repos/slurm_practice로 작업 디렉토리를 해당 프로젝트 폴더로 이동한 뒤, echo로 현재 실행 중인 노드의 호스트명(hostname)과 현재 위치(pwd)를 출력해서 로그에서 어디서 실행됐는지 추적할 수 있게 합니다. which python은 현재 잡 환경에서 사용되는 python 실행 파일의 경로를 보여주고, python3 llm_phi2_infer.py로 실제로 phi-2 추론 파이썬 스크립트를 실행합니다. 마지막 exit 0은 스크립트가 정상 종료(에러 없이 종료)했음을 의미하는 종료 코드입니다.

3-2) 제출

이제 제출.

sbatch phi2_infer.sbatch

여기서부터는 Slurm이 알아서 한다. 사용자는 기다리면서 상태만 보면 된다.

4) 결과 확인

4-1) 큐 확인

squeue -u username

RUNNING이면 그냥 기다리고, 끝나면 사라진다.

4-2) 로그 확인

job id가 예를 들어 63500이면:

ls -la logs
cat logs/slurm-63500_phi2.out
cat logs/slurm-63500_phi2.err

여기서 .err가 비어있고 .out에 출력이 정상적으로 찍혔으면 성공이다. 이게 HPC에서 “일단 한 번 제대로 돌았다”의 기준이다.

4-3) 실행 통계

마지막으로 이걸 보면, Slurm이 남긴 기록까지 확인할 수 있다.

sacct -j 63500 --format=JobID,JobName,State,ExitCode,Elapsed,MaxRSS,NodeList

여기까지 확인하면 끝이다. 이제부터는 “실험이 성공했는지”를 감으로 보는 게 아니라, 로그랑 기록으로 확인하는 흐름이 생긴다.

왜 굳이 MobaXterm 이야기를 하나

서버 작업이 귀찮아지는 순간은 보통 학습 자체가 아니라 “주변 작업”에서 온다. 접속은 SSH로 하고, 파일은 SFTP로 옮기고, 로그는 다시 SSH에서 tail로 보고, 결과 파일은 또 내려받고, 실험 여러 개 돌리면 경로가 꼬이고, 어느 순간부터는 “내가 지금 뭘 하고 있지?”가 된다. 이게 초보가 서버를 싫어하게 되는 포인트다. MobaXterm은 이걸 한 화면에 몰아넣는다. SSH 따로, SFTP 따로가 아니라 그냥 접속하면 왼쪽에 파일 트리가 같이 뜨고, 터미널은 그 옆에 붙어 있고, 로그는 클릭해서 열 수 있다. 이게 생각보다 크다. 서버가 갑자기 “리눅스 시스템”이 아니라 “작업 공간”처럼 느껴진다.

MobaXterm이 해결해주는 건 별거 아닌 것 같긴하지만 당신들은 GUI가 편하잖아

MobaXterm이 해주는 게 엄청 고급 기능은 아니다. 근데 서버 초보가 자주 틀리는 부분을 정확히 줄여준다. SSH 접속, 왼쪽에 자동으로 뜨는 SFTP 파일 트리, 드래그 앤 드롭 파일 업로드/다운로드, 로그 파일 바로 열어서 확인, 그리고 가끔 필요한 X11 포워딩까지. 여기서 중요한 건 “편의성”이 아니라 “실수 방지”다. 예를 들어 경로를 잘못 잡아서 다른 폴더에 저장해놓고 못 찾는 경우, 로그 파일을 어디에 남겼는지 헷갈리는 경우, SFTP 클라이언트랑 SSH 클라이언트를 왔다갔다 하다가 실험 흐름이 끊기는 경우. 이런 게 줄어든다.

기능이 너무 많아

MobaXterm 기능은 많다. 근데 다 쓸 필요 없다. 서버 처음 쓰는 사람이 실제로 쓰는 건 거의 고정이다. 세션 하나 만들고(SSH), 포트나 계정만 맞춰서 접속하고, 왼쪽 SFTP 트리로 파일 올리고 내리고, 터미널 split 해서 한쪽은 squeue, 한쪽은 tail -f 띄우고, 로그 파일 클릭해서 열어보는 정도. 이 정도만 해도 “서버 작업이 덜 무섭다”가 된다. 오히려 여기서 기능 욕심내면 또 복잡해진다. 목적은 서버를 화려하게 쓰는 게 아니라, 실험을 덜 망치고 계속 굴리는 거다.

Slurm이 들어가면 작업 흐름이 배치 기반으로 바뀐다. sbatch로 던지고, 기다리고, 로그 보고, 결과 확인하고, 다시 던진다. 문제는 이 과정이 터미널만으로 하면 생각보다 “상황 파악”이 어렵다는 거다. 특히 초보는 로그 파일 이름, 저장 경로, 체크포인트 위치 같은 걸 자주 놓친다. MobaXterm은 이걸 클릭으로 해결한다. sbatch 돌려놓고, 로그 파일을 왼쪽에서 찾아서 바로 열고, 체크포인트가 생겼는지 확인하고, 결과 파일 내려받아서 로컬에서 확인한다. 그러면 서버에서 실험하는 느낌이 아니라, 내 작업 공간이 서버로 확장된 느낌이 된다. 이게 진짜 크다. “서버를 다루는 스트레스”가 줄어드니까 실험을 더 많이 돌리게 된다.

그럼 VS Code Remote랑 뭐가 다르냐

VS Code Remote는 코드 중심이다. 서버에서 바로 코딩하고 디버깅하고, 개발자처럼 작업할 때 진짜 편하다. 반대로** MobaXterm은 서버 관리 중심**이다. 접속, 파일 이동, 로그 확인, 여러 세션 관리 같은 서버 생활을 편하게 해준다. 그래서 비전공자/초보자한테는 MobaXterm이 진입장벽이 낮다. 처음에는 MobaXterm으로 작업 흐름을 잡고, 익숙해지면 VS Code Remote로 넘어가는 사람도 많다. 반대로 VS Code Remote를 쓰더라도 MobaXterm은 로그 확인/파일 관리용으로 같이 쓰는 경우도 많다. 둘은 경쟁재라기보다는 대체제...?이다.

“MobaXterm은 윈도우만 되는 줄 알았는데?” 그거 맞다 “이거 윈도우 전용인 줄 알고 윈도우만 쓰고 있다”는 사람이 진짜 많다ㅠㅜ 일단 나.... MobaXterm 자체는 기본적으로 Windows용 툴이다. 아니 근데 GPT가 맥 된다고 계속 그러다가 성질부리니까 안된다네...;;

Mac은 기본 터미널(ssh) + 파일 전송은 Cyberduck 같은 조합을 많이 쓰고, Linux는 그냥 터미널+scp/sftp 조합으로 가는 경우가 많다.

1. conda env를 프로젝트마다 안 나눔

하나의 env에 이것저것 설치하다가 어느 날 갑자기 import 에러가 난다. 버전 충돌이 터지면 원인 추적이 거의 불가능해진다. 프로젝트 1개 = env 1개. 이거 안 지키면 언젠가 반드시 터진다.

2. Python 버전 안 보고 env 생성

로컬은 3.11인데 서버는 3.8이고, 패키지는 3.10 기준인 경우가 많다. 결과는 보통 이렇다. pip install은 되는데 실행이 안 된다. env 만들 때 Python 버전부터 고정해야 한다. 특히 torch/transformers 계열은 여기서부터 꼬이기 시작한다.

3. partition 안 보고 job 제출

GPU 없는 partition에 제출해놓고 “왜 안 빨라지지?” 한다. queue는 도는데 GPU는 안 잡히고, nvidia-smi는 안 보인다. 먼저 항상 이거부터 본다.

sinfo

파티션이 여러 개면, 내가 들어가야 하는 곳이 따로 있는 경우가 많다. 특히 “gpu 파티션”이랑 “cpu 파티션”이 분리돼 있으면 여기서 초보가 한 번씩 넘어간다.

4. time limit 너무 짧게 잡음

학습 잘 돌아가다가 조용히 종료된다. 로그엔 에러도 없다. 이건 대부분 time limit 초과로 Slurm이 kill한 거다. 처음엔 넉넉하게 잡는 게 맞다. 시간 아끼려다가 실험 날리는 게 더 손해다.

5. Slurm 로그 경로 안 만들어둠

스크립트에 이렇게 써놓고

#SBATCH --output=logs/%j.out

logs 디렉토리를 안 만들어둔다. 그러면 로그가 안 남거나(혹은 Slurm이 바로 에러로 잡을 끝내거나), 남아도 찾기 힘든 위치로 간다. 디버깅 지옥이 시작된다. logs는 무조건 미리 만들어두는 게 편하다.

6. sbatch랑 srun을 헷갈림

테스트도 sbatch로 하고, 본 실험도 srun으로 한다. 그리고 세션 끊기면 다 날아간다. 정리하면 이거다. 테스트/디버깅은 srun, 학습/장시간 작업은 sbatch. 이거 하나만 지켜도 사고가 확 줄어든다.

7. nvidia-smi가 안 보이는데 당황함

이건 대부분 GPU 노드가 아니라 로그인 노드에 있는 거다. GPU는 그냥 보이는 게 아니라 요청해야 보인다. 그래서 GPU 확인은 보통 “GPU를 잡고 난 뒤”에 하는 게 맞다. 로그인 노드에서 nvidia-smi 안 뜬다고 GPU가 없는 게 아니다.

8. GPU 남아 있는데 job이 안 도는 경우

분명 sinfo 보면 GPU가 남아 있는데 내 job은 계속 PENDING이다. 이건 코드 문제가 아니라 운영 정책 문제일 확률이 높다. QoS 제한, 사용자별 GPU 제한, 우선순위 밀림 같은 것들이다. 여기서 초보가 제일 많이 하는 착각은 “내 코드가 뭔가 잘못됐나?”인데, 대부분 아니다. 그냥 기다려야 하는 상황일 때가 많다.

9. GPU 여러 개 요청했는데 코드가 1개만 씀

스크립트에 이렇게 써놓고

#SBATCH --gres=gpu:4

코드는 single-GPU로만 돈다. 그러면 GPU 3개는 그냥 낭비다. 멀티 GPU는 요청만으로 되는 게 아니다. 코드에서 DDP를 쓰든, accelerate를 쓰든, 분산 설정을 해야 한다. 그리고 클러스터 입장에서는 이런 job이 제일 싫다. 자원은 먹는데 효율이 안 나온다.

10. ipynb로 학습 돌림

셀 여러 번 실행하면서 메모리 파편화가 생기고, 커널이 죽고, 재실행하면 더 빨리 죽는다. HPC에서는 ipynb는 기록/실험 메모용이고, 학습은 .py + Slurm이 제일 안정적이다. 특히 OOM 한 번 나면 커널이 메모리를 깔끔하게 못 돌려줘서 계속 이상해지는 경우가 많다.

11. requirements.txt 충돌 방치

버전을 안 박아둔다. 어제 되던 게 오늘 안 된다. 재현이 불가능해진다. 최소한 torch/transformers/lightning 같은 핵심 패키지는 버전 고정해두는 게 맞다. HPC는 “오늘 되는 환경”이 내일도 된다는 보장이 없다. 특히 누군가가 같은 env에 패키지 하나만 올려도 갑자기 깨진다.

12. nohup + python으로 버팀

로컬 습관 그대로 nohup python train.py & 이런 걸로 버티면 HPC에선 최악의 선택이 된다. 로그 뒤섞이고, job 관리가 안 되고, 자원 추적이 안 된다. 무엇보다 관리자 입장에서는 누가 뭘 돌리는지 감이 안 잡혀서 진짜 싫어한다. HPC에서는 Slurm이 정답이다. 그냥 sbatch로 돌리는 게 깔끔하다.

13. (보너스) 디렉토리 구조 안 지킴

처음엔 대충 해도 되는데, 한 번 실험이 늘어나기 시작하면 바로 지옥이 열린다.

project/
  ├─ env.yml
  ├─ notebooks/
  ├─ src/
  ├─ scripts/
  └─ logs/

이 정도만 지켜도 나중에 자기가 고마워진다. 특히 scripts랑 logs 분리해두면 “어떤 설정으로 돌렸는지”가 남아서, 실험이 쌓여도 덜 무너진다.

14. (추가) 한글 요약이 갑자기 같은 음절만 뱉는 현상

이것도 진짜 한 번쯤 겪는다. 모델이 갑자기 특정 음절만 반복해서 뱉는다. 처음 보면 데이터가 깨졌나, 토크나이저가 망가졌나, GPU가 맛이 갔나 싶다. 근데 대부분은 학습이 불안정해지면서 생성이 붕괴된 케이스다.

주로 이런 상황에서 잘 나온다. learning rate가 과하게 높거나, fp16에서 overflow가 나거나, 너무 긴 입력을 억지로 넣어서 attention이 터지거나, 체크포인트가 깨졌거나, decoding 설정이 이상한 경우(예: beam/temperature 조합)다. 그리고 이게 무서운 점은, 학습이 “완전히 망한 것처럼” 보여도 로그 loss는 멀쩡하게 내려가는 척할 때가 있다는 거다. 그래서 inference 결과를 꼭 중간중간 확인해야 한다.

이 현상이 보이면 보통은 이 순서로 본다. 최근 체크포인트로 다시 추론해보기, decoding 파라미터(temperature/top-p/beam) 기본값으로 되돌리기, fp16이면 bf16이나 fp32로 잠깐 확인해보기, learning rate 낮추기, 입력 길이 줄이기. 대부분 여기서 정상으로 돌아온다.

HPC는 실수에 관대하지 않다. 하지만 위에 적은 것들만 피해도 실험 날릴 확률이 내려가고, 디버깅 시간이 줄고, 멘탈 소모가 확 줄어든다. 결국 HPC는 “잘 쓰는 사람만 빠른 시스템”이 아니라, “안 망하게 쓰는 사람이 끝까지 가는 시스템”이다.

CUDA out of memory

batch size 줄였는데 또 나고, 다시 줄였는데 또 난다. 그러다 이런 생각이 든다. “이거… GPU가 고장 난 거 아님?” 아니다. 대부분 구조 문제다. 그리고 더 짜증나는 건, OOM은 한 번 터지면 그다음부터 계속 터질 확률이 높아진다는 거다. 로그는 멀쩡한데, 갑자기 같은 자리에서 죽고, 재실행하면 더 빨리 죽고, 그러다 결국 “내 코드가 뭔가 잘못됐나?”로 빠진다.

1. GPU 메모리는 뭐가 잡아먹고 있을까

GPU 메모리를 쓰는 건 생각보다 많다. 대충 네 덩어리다. 모델 weight, activation(중간 결과), gradient, optimizer state. 여기서 Transformer는 특히 activation이 미친 듯이 크다. 입력 길이가 늘어나면 “조금 더 느려지는 정도”가 아니라, 어느 순간 메모리 사용량이 벽을 뚫고 바로 터진다. 그래서 회의록처럼 길이가 들쑥날쑥한 데이터는 더 위험하다. 평균 길이로는 버티는데, 한 번 길게 걸리면 바로 OOM 난다.

그리고 여기서 자주 놓치는 게 하나 있다. GPU 메모리는 “모델만” 먹는 게 아니다. DataLoader가 GPU로 올리는 텐서, tokenizer 결과를 미리 쌓아두는 버퍼, evaluation 단계에서 생성 결과를 저장하는 리스트 같은 것도 은근히 누적된다. 학습이 아니라 검증(eval)에서 터지는 OOM도 꽤 흔하다.

2. “batch 줄였는데 왜 안 되지?”

이게 제일 많이 나오는 질문이다. 이유는 간단하다. 모델 weight는 batch랑 무관하고, optimizer state도 batch랑 무관하다. 즉 모델 자체가 GPU에 안 올라가는 경우 batch를 1로 만들어도 OOM 난다. 특히 Adam/AdamW + 큰 모델 + 긴 입력 조합이면 거의 확정이다. 그리고 한 번 더 빡치는 경우가 있는데, “학습은 되는데 backward에서만 터지는 케이스”다. forward는 겨우 올라갔는데 gradient까지 만들려니까 뒤에서 터진다. 그래서 로그가 “몇 step 잘 돌다가” 죽는 것처럼 보인다.

3. 제일 많이 쓰는 해결책 Top 5

1) Batch size 줄이기

가장 먼저 해보는 거다. 근데 한계가 빠르다. batch 1까지 갔는데도 터지면 여기서 더 줄일 게 없다. 이때부터는 “batch만의 문제”가 아니라는 뜻이다.

2) Gradient Accumulation

실험으로 알아보는 LLM 파인튜닝 최적화 가이드 Part 1

배치를 쪼개서 여러 번 계산 후 한 번 업데이트하는 방식이다. 실질적으로 batch size를 키우는 효과를 주면서, 한 번에 들고 있는 메모리는 줄인다. HPC에서 제일 현실적인 타협안이다. 특히 “성능은 유지하고 싶고, VRAM은 부족한” 상황에서 거의 기본으로 들어간다.

3) Mixed Precision (fp16 / bf16)

https://introduce-ai.tistory.com/entry/FP32-TF32-FP16-BFLOAT16-Mixed-Precision%EC%97%90-%EB%8C%80%ED%95%9C-%EC%9D%B4%ED%95%B4 거의 필수다. 프레임워크에 따라 다르지만 대체로 이거 하나로 VRAM이 확 줄어든다. 다만 fp16은 가끔 수치 불안정으로 터질 때가 있고, bf16이 가능한 GPU면 bf16이 더 편한 경우가 많다. 물론 “켜면 무조건 해결”은 아니고, activation이 너무 크면 mixed precision을 켜도 터진다. 그래도 안 켜는 게 더 이상하다.

4) LoRA / QLoRA

• https://velog.io/@kim_taixi/LoRA-QLoRA-DoRA-QDoRA
• https://ai.plainenglish.io/a-practical-guide-to-advanced-llm-fine-tuning-from-lora-to-qlora-462b01f44022

모델 전체를 학습하지 않는다. weight 대부분 freeze하고 일부 파라미터만 학습한다. LLM 계열에서는 사실상 표준이다. 그리고 여기서 진짜 중요한 건 “메모리가 줄어드는 이유”가 단순히 파라미터가 적어서가 아니라, optimizer state가 확 줄어드는 효과가 크다는 점이다. Adam 계열은 상태를 엄청 들고 있기 때문에, LoRA만으로도 체감이 크게 난다.

5) 입력 길이 줄이기

전처리랑 직결된다. 불필요한 발언 제거, 안건 단위 split. 이게 제일 싸고 확실하다!!!!!!! 그리고 국회 회의록 요약은 사실 이게 제일 정답에 가깝다. 모델을 바꾸는 것보다, 입력에서 의미 없는 부분을 덜어내는 게 더 잘 먹힌다. 특히 “긴 입력이 가끔 등장하는 케이스”를 잘라내면 OOM이 확 줄어든다.

4. “고급”이라고 불리는 것들

이건 진짜 막혔을 때 쓴다. Activation Checkpointing, CPU Offload, ZeRO(DeepSpeed), FSDP, 8-bit Optimizer. 효과는 확실한데 설정 난이도가 급상승한다. 그리고 HPC에서 이걸 쓰면 또 다른 문제가 생긴다. 설정은 됐는데 성능이 급격히 느려져서, “OOM은 해결했는데 학습 시간이 3배” 같은 상황이 나온다. 특히 CPU offload는 VRAM은 살리지만 I/O나 PCIe 병목이 생기면 체감이 확 난다. 그래서 이건 마지막 카드로 남겨두는 게 정신 건강에 좋다.

5. 모델 크기별 체감 VRAM

대충 감만 잡자. 그리고 이건 항상 “모델만 올렸을 때”가 아니라, 학습까지 포함하면 얘기가 달라진다.

여기서 포인트는 “이론상 된다”와 “실제로 된다”는 다르다는 거다. 학습은 optimizer까지 포함이라 메모리 먹는 게 다르고, 입력 길이까지 얹히면 더 달라진다. 그리고 분산 학습이나 DDP 들어가면 또 달라진다. 그래서 표만 보고 확신하면 안 된다. 그냥 감만 잡는 용도다.

6. ipynb가 서버에서 자꾸 죽는 이유

이건 OOM이랑 자주 묶인다. 커널이 GPU 메모리를 못 돌려주고, 셀 단위 실행으로 메모리 파편화가 생기고, ssh 세션 끊기면 같이 죽는다. 특히 “한 번 OOM 났는데 커널이 살아있는 척만 하는 상태”가 제일 최악이다. 다시 돌리면 더 빨리 터지고, nvidia-smi 보면 메모리는 계속 잡혀 있고, 근데 프로세스는 애매하게 남아 있다. 그러면 결국 커널 재시작하거나 job 자체를 새로 띄워야 한다.

그래서 HPC에선 이게 거의 불문율이다. ipynb는 실험 메모용이고, 학습은 .py + Slurm이다. ipynb로 학습을 끝까지 끌고 가려 하면, 언젠가 한 번은 크게 데인다.

7. 그래서 실제 추천 조합

학습은 .py, 실험/기록은 Jupytext, 실행은 sbatch, 테스트는 srun. 이 조합이 제일 덜 아프다. 특히 “테스트는 srun으로 짧게, 학습은 sbatch로 길게” 이 흐름이 잡히면 OOM뿐 아니라 서버 사용 자체가 안정된다. 그리고 실패했을 때도 복구가 쉽다. 로그 파일 하나만 보면 되니까.

8. 정리

OOM은 GPU가 약해서가 아니라 설계가 안 맞아서 난다. 모델 크기, 입력 길이, optimizer, 학습 방식. 이 네 개가 맞아야 한다. batch 줄였는데도 계속 터진다면, 그건 “batch가 문제”가 아니라 “나머지 셋 중 하나가 너무 무거운 상태”라는 신호다. 그리고 회의록 요약 같은 긴 입력 문제에서는 결국 입력 구조를 손보는 게 제일 빠르고 확실하게 먹힌다.

왜 국회 회의록 요약이 어려운가

이 데이터는 일반 뉴스 요약이랑 성질이 다르다. 문서가 길고(수천~수만 토큰), 발언자가 계속 바뀌고, 안건이 섞여 있고, 의례적 발언이 많고, 정작 중요한 결정 문장은 소수다. 그러니까 KoBART 하나 fine-tuning했다고 갑자기 잘 될 리가 없다. 오히려 억지로 요약하려다가 애매한 문장만 뱉는 게 정상이다.

그리고 회의록은 흐름이 있다. 누가 뭐라고 말했는지, 어떤 논점이 오갔는지, 결론이 어디서 났는지가 중요하다. 근데 모델 입장에서는 그냥 긴 텍스트 덩어리로 들어가면, 중요한 것과 중요하지 않은 걸 구분하기가 너무 어렵다.

베이스라인 결과를 보고 제일 먼저 할 질문은 이거다. 이게 모델 한계인가, 아니면 데이터/구조 문제인가? 대부분의 경우 전처리 + 입력 구조 문제가 먼저다. 특히 회의록은 모델이 똑똑하면 해결되는 문제가 아니라, 모델이 이해할 수 있게 잘라주면 해결되는 문제에 가깝다.

여기서 많이 하는 실수가 있다. 점수가 낮으면 바로 모델을 바꾼다. 근데 입력이 그대로면 모델만 바꿔도 한계가 비슷하게 온다. 긴 글을 통째로 먹이는 순간, 좋은 모델도 그냥 얌전히 잘린다.

1. 전처리 방식 비교 (S2)

같은 KoBART 모델, 같은 100개 샘플. 전처리만 다르게 해서 돌렸다.

분석

v0과 v1은 거의 차이가 없다. 같은 화자 발언을 합쳐봤자 토큰 수가 크게 줄지 않기 때문이다. compression_ratio가 0.87%에서 0.90%로 거의 비슷하다.

v2는 얘기가 다르다. 의례 발언을 제거하니까 compression_ratio가 14.87%까지 올라갔다. 입력이 15% 가까이 줄었다는 뜻이다. 그런데 ROUGE는 오히려 떨어졌다. 왜일까?

length_ratio를 보면 답이 나온다. v0은 2.04, v2는 1.45다. v2는 출력 길이가 짧아졌다. 입력이 줄어드니까 모델이 생성하는 요약도 짧아진 거다. ROUGE는 길이에 민감해서 출력이 짧으면 점수가 떨어진다.

하지만 BERT-Score는 v2가 최고다. 의미적으로는 더 정확하게 요약한다는 뜻이다. 의례 발언이 빠지니까 진짜 중요한 내용에 집중할 수 있게 된 거다.

의례 발언 제거는 감으로 하는 게 아니라 규칙 기반으로 가는 게 깔끔하다. 개의하겠습니다, 정회하겠습니다, 산회하겠습니다 같은 패턴은 회의록마다 반복된다. 이런 구간을 모델이 계속 먹으면 요약이 흐려진다.

결론

전처리 효과를 볼 때는 ROUGE만 보면 안 된다. compression_ratio, length_ratio, BERT-Score를 같이 봐야 한다. 의례 발언 제거가 의미적으로는 효과가 있다.

2. 프롬프트 방식 비교 (S4)

같은 phi-2 모델, 같은 100개 샘플, 같은 v2 전처리. 프롬프트만 다르게 해서 돌렸다.

분석

structured가 ROUGE 기준 최고다. 형식을 명시하면 모델이 더 구조화된 출력을 낸다. 핵심 안건, 주요 논의, 결정사항 같은 틀을 주니까 모델이 거기에 맞춰서 생성한다.

extractive_guide가 BERT-Score 최고다. 추출적 요약 가이드라인을 주면 원문에서 중요한 표현을 그대로 가져오게 된다. 의미적으로는 더 정확해지지만, 정답과 표현이 다르면 ROUGE는 떨어진다.

simple은 가장 나쁘다. 아무 가이드 없이 그냥 요약해달라고 하면 모델이 뭘 해야 할지 모른다. ROUGE-2가 0.0000이라는 건 bigram 매칭이 전혀 안 된다는 뜻이다.

재밌는 건 BLEU다. structured가 simple보다 BLEU가 낮다. 왜냐면 structured는 모델이 자기 나름대로 구조화해서 쓰기 때문에 정답과 표현이 달라진다.

결론

프롬프트 설계가 효과는 있다. structured가 ROUGE 기준으로는 66% 향상 (0.0253 → 0.0420)이다. 하지만 모델 자체가 한국어를 못하면 한계가 있다. phi-2의 한국어 능력이 약해서 전체 점수 자체가 낮다.

그럼 LLM 쓰면 안 되나? 할 수는 있다. LLaMA 계열, Qwen 계열, 한국어 튜닝 모델로 프롬프트 요약도 가능하다. 근데 점수 싸움으로 들어가면 프롬프트로 요약은 결과가 흔들린다. 그래서 현실적으로는 로컬 모델 + fine-tuning이 제일 안전한 선택이 된다.

3. 요약 방식 비교 (S5)

같은 phi-2 모델, 같은 10개 샘플. 직접 요약 vs 피벗 번역(한→영→한).

분석

피벗 방식이 ROUGE-1 기준 47% 좋다. 번역을 두 번 하는데도 더 낫다니 의외다.

length_ratio를 보면 피벗이 4.31이다. 출력이 엄청 길어졌다. 영어로 요약하고 다시 한국어로 번역하면서 내용이 풀어지기 때문이다. 긴 출력이 ROUGE에 유리하게 작용했을 수 있다.

하지만 BERT-Score도 피벗이 높다. 단순히 길이 때문만은 아니다. 영어 요약 모델이 한국어 요약 모델보다 훨씬 성능이 좋아서, 번역 비용을 감수하고도 품질이 더 좋아진 거다.

번역 모델로 NLLB를 썼는데, 정보 손실이 생각보다 적다. 회의록처럼 정형화된 텍스트는 번역이 잘 되는 편이다.

결론

한국어 요약이 잘 안 되면 피벗 번역을 고려해볼 만하다. 추론 시간이 3배 이상 걸리지만, 품질이 더 중요한 상황에서는 쓸만한 대안이다.

4. 모델 규모 비교 (S6)

같은 100개 샘플, 같은 v2 전처리. KoBART(124M) vs phi-2(2.7B).

분석

22배 큰 모델이 3.7배 나쁘다. 충격적인 결과다.

추론시간을 보면 KoBART가 샘플당 1초, phi-2가 12.91초다. 13배 느리면서 성능도 나쁘다. score_per_second로 효율성을 계산하면 KoBART가 46배 효율적이다.

왜 이런 결과가 나왔을까?

첫째, 언어 특화다. KoBART는 한국어 텍스트로 사전학습됐다. phi-2는 영어 중심으로 학습됐다. 한국어 회의록 요약이라는 태스크에서는 한국어에 특화된 모델이 압도적으로 유리하다.

둘째, 태스크 특화다. KoBART는 요약 태스크로 파인튜닝됐다. phi-2는 범용 LLM이라서 요약에 특화된 게 아니다. 입력을 받아서 요약 형태로 출력하는 법을 KoBART가 더 잘 안다.

셋째, 모델 구조다. KoBART는 seq2seq 구조라서 요약 생성에 최적화돼 있다. phi-2는 causal LM이라서 자연어 생성 전반에 맞춰져 있다.

국내 회의록 요약이나 공공 데이터 요약 쪽을 보면 자주 나오는 조합이 있다. KoBART/KoT5-large 같은 한국어 seq2seq, PEGASUS 계열, BigBird-Pegasus, LED. 근데 공통점은 모델 이름이 아니다. 거의 항상 같이 붙는 게 안건 단위 분리, 발언자 정보 유지, 결정 문장 강조 같은 입력 구조 설계다. 모델만 바꾸는 경우는 생각보다 거의 없다. 왜냐면 다들 한 번쯤 모델만 키워서 해결 안 된다를 맞아봤기 때문이다.

결론

큰 모델이 무조건 좋은 게 아니다. 도메인과 태스크에 맞는 모델을 찾는 게 중요하다. 한국어 요약이라면 한국어 특화 요약 모델을 쓰는 게 훨씬 효율적이다.

5. Long-context 비교 (S3)

긴 회의록 50개 (평균 36,080자). KoBART vs phi-2.

분석

둘 다 truncation_rate가 100%다. 평균 36,000자짜리 회의록을 1024토큰이나 2048토큰으로 처리하면 앞부분만 보고 나머지는 잘린다.

그래도 KoBART가 3.7배 좋다. S6에서 본 것처럼 언어 특화와 태스크 특화의 힘이다. phi-2가 max_input이 2배 긴데도 불구하고 성능이 훨씬 나쁘다.

문제는 결국 여기다. 회의록은 짧아도 2~3천 토큰, 길면 2만 토큰을 넘는다. 그래서 등장하는 게 BigBird, Longformer, LED(Longformer Encoder-Decoder), BigBird-Pegasus 같은 long-context 요약 모델이다. 요즘은 Qwen 같은 long-context 계열이나, Llama 계열에서 컨텍스트 늘린 모델도 많고, RWKV/Mamba처럼 아예 구조가 다른 선택지도 있다.

다만 여기서도 착각하면 안 되는 게, long-context 모델을 쓴다고 해서 긴 글이 자동으로 요약되는 것까진 아니다. 잘릴 확률이 줄어드는 거지, 중요한 부분을 알아서 찾아주는 건 또 다른 문제다.

결론

현재 실험에서는 long-context 효과를 검증 못 했다. 하지만 한 가지는 확실하다. max_input이 2배 길어도 언어 특화가 안 되면 의미없다.

종합 비교표

효율성 비교

KoBART가 압도적으로 효율적이다. 메모리도 적게 쓰고, 추론도 빠르고, 성능도 좋다.

phi-2를 쓸 이유가 있다면 하나다. 피벗 번역에서 영어 요약을 할 때. 그 경우에는 phi-2의 영어 능력이 KoBART보다 나을 수 있다.

여기서 방향이 갈린다

이제 선택지는 명확하다. 모델을 키울 것인가, 구조를 바꿀 것인가, 전처리에 집중할 것인가. 보통 성능이 제일 잘 오르는 건 전처리 + 입력 구조다. 모델은 마지막에 키워도 된다. 오히려 구조가 잡히기 전에 모델부터 키우면, 돈과 시간만 쓰고 왜 좋아졌는지를 못 남긴다.

베이스라인은 답이 아니라 지도다. 어디서 막히는지 보여주고, 뭘 바꿔야 하는지 알려준다. 국회 회의록 요약은 모델 싸움이 아니라 구조 싸움에 가깝다. 그리고 구조를 잡는 순간부터, 점수는 생각보다 쉽게 올라간다.

베이스라인 이후 추천 흐름

무작정 바꾸지 말고 순서를 지키는 게 중요하다. 베이스라인 이후에는 보통 이 순서로 간다.

1단계 – 입력 구조부터 바꾸기

안건 단위로 split 하고, 회의 시작/종료 같은 반복 구간을 분리하고, 불필요한 의례 발언을 제거한다. 여기서 점수가 꽤 오른다.

2단계 – Long-context 모델 테스트

그다음이 BigBird-Pegasus나 LED 같은 long-context 모델이다. 베이스라인에서 잘림 때문에 성능이 박살났다면, 여기서 체감이 확 난다.

3단계 – 프롬프트 최적화

structured 프롬프트, 태그 활용 프롬프트 등. 이건 점수 몇 % 올리는 구간이다.

4단계 – (선택) 7B 모델 + LoRA

GPU가 부족하면 여기서 LoRA/QLoRA가 들어간다. 모델을 크게 가져가고 싶은데 자원이 없을 때 현실적인 선택지다. 특히 학교 서버는 한 번에 크게 먹는 실험이 어려운 경우가 많아서, 파라미터 효율화는 그냥 선택이 아니라 생존 스킬이 된다.

다음 실험 방향

지금 실험 결과를 바탕으로 다음에 해볼 것들이다.

첫째, 진짜 long-context 모델 테스트. LongChat-7B-16K나 Yarn-Mistral-7B-128K로 긴 회의록 요약 성능을 봐야 한다. 4bit quantization이나 더 큰 GPU가 필요하다.

둘째, 한국어 LLM 테스트. KoAlpaca, Polyglot-Ko 같은 한국어 특화 LLM으로 요약 성능을 봐야 한다. phi-2보다 나을 가능성이 높다.

셋째, 파인튜닝. KoBART를 국회 회의록 데이터로 추가 파인튜닝하면 성능이 더 오를 수 있다. 현재는 범용 요약 모델이라 도메인 특화가 안 돼 있다.

왜 국회 회의록 요약인가

이 과제는 생각보다 많은 걸 한 번에 경험하게 한다. 입력이 길어서 long sequence 문제를 체감하게 되고, JSON 구조라 전처리를 피할 수 없고, 요약 태스크라 생성 모델 흐름을 그대로 밟게 되고, ROUGE 평가로 감이 아니라 수치로 비교하게 된다. 즉, NLP 실험의 기본 골격이 전부 들어 있다. 처음 실전으로 딱 좋다.

데이터 구조 먼저 보기

국회 회의록 데이터(말평 2024)는 대략 이런 형태다.

{
  "id": "nikluge-2024-국회회의록안건별요약-train-000001",
  "input": {
    "speaker": [
      {"id": "김상희", "occupation": "위원", "original_id": "김상희"},
      {"id": "문창진", "occupation": "보건복지부차관", "original_id": "문창진"}
    ],
    "conversation": [
      {"id": "SBRW2100000001.1.1.1", "speaker": "김상희", "utterance": "회의를 시작하도록 하겠습니다."},
      {"id": "SBRW2100000001.1.1.2", "speaker": "김상희", "utterance": "의사일정 제1항을 상정합니다."}
    ],
    "issue": "2008회계연도 세입세출결산"
  },
  "output": "본 회의에서 여성부의 2008회계연도 세입세출결산에 관해..."
}

여기서 중요한 건, 하나의 문서가 문장 하나가 아니라 발언들의 시퀀스라는 점이다. input.conversation에 평균 500개 발화가 들어 있고, 실제 모델 입력은 [발언1][발언2][발언3]... 같은 형태로 이어 붙인 긴 텍스트가 된다. 그래서 이 과제는 시작부터 long document 요약 문제다. 그냥 요약 모델 학습이 아니라, 입력 길이 때문에 학습/추론이 흔들릴 수 있다는 걸 처음부터 맞게 된다.

Seraph 서버 환경 세팅

프로젝트 구조 생성

# 서버 접속 후
ssh <user>@seraph.khu.ac.kr

# 프로젝트 루트 (home 말고 /data 사용 - quota 문제 방지)
MY_ID=$(whoami)
PROJECT_ROOT="/data/${MY_ID}/projects/nams_experiments"

# 디렉토리 생성
mkdir -p $PROJECT_ROOT/{raw,data/{interim,processed},src/{preprocess,train,infer,eval,utils},configs,scripts,slurm,logs,outputs}
cd $PROJECT_ROOT

HuggingFace 캐시 경로 설정

이거 안 하면 home 밑에 캐시가 쌓이고 quota 터질 수 있다.

export HF_HOME="/data/${MY_ID}/.cache/huggingface"
export TRANSFORMERS_CACHE="$HF_HOME/transformers"
mkdir -p $HF_HOME $TRANSFORMERS_CACHE

# 매번 치기 귀찮으면 env_vars.sh 만들기
cat > scripts/env_vars.sh << 'EOF'
export PROJECT_ROOT="/data/$(whoami)/projects/nams_experiments"
export HF_HOME="/data/$(whoami)/.cache/huggingface"
export TRANSFORMERS_CACHE="$HF_HOME/transformers"
export PYTHONUNBUFFERED=1
EOF

Conda 환경 생성

환경은 최대한 단순하게 간다.

conda create -n nams python=3.10 -y
conda activate nams

# PyTorch (CUDA 11.8)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

# 핵심 패키지
pip install transformers datasets accelerate
pip install rouge-score bert-score sacrebleu
pip install pandas numpy scikit-learn tqdm pyyaml

이 단계에서 의존성 충돌 나면, 그게 바로 HPC 첫 관문이다. 특히 torch/transformers 계열은 버전 꼬이면 에러가 친절하게 나오지 않는다. 그냥 한 줄 보고 멈춘다. 그러면 로그부터 읽는 습관이 여기서 생긴다.

데이터 확인부터

데이터를 raw/에 넣고, 구조부터 확인한다.

ls -la raw/
# 국회회의록안건별요약_train.json (236MB, 1339개)
# 국회회의록안건별요약_dev.json (29MB, 167개)
# 국회회의록안건별요약_test.json (29MB, 167개)

# 데이터 구조 확인
import json

with open("raw/국회회의록안건별요약_train.json", "r") as f:
    data = json.load(f)

print(f"문서 수: {len(data)}")  # 1339
print(f"첫 문서 키: {data[0].keys()}")  # id, input, output

# 발화 수 확인
conv = data[0]["input"]["conversation"]
print(f"첫 문서 발화 수: {len(conv)}")  # 544

# 평균 발화 수
avg_utts = sum(len(d["input"]["conversation"]) for d in data) / len(data)
print(f"평균 발화 수: {avg_utts:.1f}")  # ~500

이 시점에서 깨달아야 할 것: 평균 500개 발화 = 엄청 긴 입력. KoBART 같은 모델은 max_length가 1024 토큰이라 대부분 잘린다.

Slurm으로 GPU 테스트 먼저

코드 돌리기 전에 GPU가 잡히는지부터 확인한다. 이거 안 하고 바로 학습 돌리면 나중에 왜 안 되지? 하고 삽질하게 된다.

# slurm/debug_gpu_test.sbatch
#!/bin/bash
#SBATCH --job-name=gpu_test
#SBATCH --partition=debug_ugrad
#SBATCH --account=ugrad
#SBATCH --gres=gpu:1
#SBATCH --mem-per-gpu=20G
#SBATCH --time=00:30:00
#SBATCH --output=logs/slurm-%j_gpu_test.out

echo "[INFO] job=$SLURM_JOB_ID"
echo "[INFO] host=$(hostname)"
echo "[INFO] start=$(date)"

nvidia-smi

source ~/.bashrc
conda activate nams

python -c "
import torch
print(f'torch: {torch.__version__}')
print(f'cuda: {torch.cuda.is_available()}')
if torch.cuda.is_available():
    print(f'device: {torch.cuda.get_device_name(0)}')
"

echo "[INFO] end=$(date)"

sbatch slurm/debug_gpu_test.sbatch
tail -f logs/slurm-*_gpu_test.out

CUDA available: True 뜨면 성공. 여기서 막히면 뒤로 못 간다. 가끔은 GPU 1장 요청했는데 환경 설정이 꼬여서 CPU로만 돌다가 하루 날리는 경우도 있다.

베이스라인: KoBART로 첫 추론

학습 전에 추론부터 해본다. 모델이 뭘 뱉는지 보는 게 먼저다.

# src/infer/baseline_test.py
import json
import torch
from transformers import AutoTokenizer, AutoModelForSeq2SeqLM

def main():
    print("[INFO] 모델 로드 중...")
    model_name = "gogamza/kobart-summarization"
    tokenizer = AutoTokenizer.from_pretrained(model_name)
    model = AutoModelForSeq2SeqLM.from_pretrained(model_name)

    device = "cuda" if torch.cuda.is_available() else "cpu"
    model.to(device)
    model.eval()
    print(f"[INFO] device={device}")

    # 데이터 로드
    with open("raw/국회회의록안건별요약_dev.json", "r") as f:
        data = json.load(f)

    # 첫 번째 문서로 테스트
    doc = data[0]
    conv = doc["input"]["conversation"]

    # 입력 텍스트 생성 (발화 이어붙이기)
    input_text = " ".join([
        f"[{utt['speaker']}] {utt['utterance']}"
        for utt in conv
    ])

    print(f"[INFO] 입력 길이: {len(input_text)} chars")
    print(f"[INFO] 발화 수: {len(conv)}")

    # 토크나이즈
    inputs = tokenizer(
        input_text,
        return_tensors="pt",
        max_length=1024,  # KoBART 최대
        truncation=True,
    ).to(device)

    print(f"[INFO] 토큰 수: {inputs['input_ids'].shape[1]}")

    # 생성
    with torch.no_grad():
        outputs = model.generate(
            **inputs,
            max_length=256,
            num_beams=4,
            early_stopping=True,
        )

    summary = tokenizer.decode(outputs[0], skip_special_tokens=True)

    print("\n" + "="*50)
    print("[결과] 생성된 요약:")
    print(summary)
    print("\n[정답] 실제 요약:")
    print(doc["output"][:500])
    print("="*50)

if __name__ == "__main__":
    main()

python src/infer/baseline_test.py

여기서 확인할 것만 딱 잡으면 된다. 요약이 나오긴 하는가? 토큰 수가 1024로 잘렸는가? (거의 확실히 잘림) 생성된 문장이 말이 되는가?

대부분 애매한 문장이 나온다. 정상이다. 입력이 잘려서 중요한 정보를 못 봤기 때문이다.

ROUGE 평가 - 숫자로 확인

읽어보니 괜찮은데요?는 아무 의미가 없다. 비교하려면 숫자가 있어야 한다.

# src/eval/rouge_eval.py
from rouge_score import rouge_scorer

def compute_rouge(predictions, references):
    scorer = rouge_scorer.RougeScorer(
        ["rouge1", "rouge2", "rougeL"],
        use_stemmer=False,
    )

    scores = {"rouge1": [], "rouge2": [], "rougeL": []}

    for pred, ref in zip(predictions, references):
        result = scorer.score(ref, pred)
        scores["rouge1"].append(result["rouge1"].fmeasure)
        scores["rouge2"].append(result["rouge2"].fmeasure)
        scores["rougeL"].append(result["rougeL"].fmeasure)

    return {
        k: sum(v) / len(v) for k, v in scores.items()
    }

보통 보는 건 이것.

점수가 낮아도 상관없다. 이건 출발선이다. 베이스라인 점수만 확보해도 이후에 바꾼 게 진짜 좋아졌는지 판단할 수 있게 된다. 그리고 그게 실험의 시작이다.

Slurm으로 전체 dev셋 추론

이제 전체 dev셋(167개)에 대해 추론하고 평가한다.

# slurm/01_baseline_infer.sbatch
#!/bin/bash
#SBATCH --job-name=baseline_infer
#SBATCH --partition=batch_ugrad
#SBATCH --account=ugrad
#SBATCH --gres=gpu:1
#SBATCH --mem-per-gpu=20G
#SBATCH --time=02:00:00
#SBATCH --output=logs/slurm-%j_baseline.out

# === 필수 로그 ===
echo "[INFO] job=$SLURM_JOB_ID"
echo "[INFO] host=$(hostname)"
echo "[INFO] start=$(date)"
nvidia-smi

# === 환경 ===
source ~/.bashrc
conda activate nams
source scripts/env_vars.sh

echo "[INFO] HF_HOME=$HF_HOME"

# === PyTorch 확인 ===
python -c "import torch; print(f'[INFO] cuda={torch.cuda.is_available()}')"

# === 추론 실행 ===
python src/infer/run_baseline.py \
    --input raw/국회회의록안건별요약_dev.json \
    --output outputs/baseline_dev_results.json

# === 완료 ===
echo "[INFO] end=$(date)"

그리고 제출.

sbatch slurm/01_baseline_infer.sbatch

이제 할 일은 딱 하나다.

squeue -u $USER

RUNNING이면 기다리고, PENDING이면 이유를 보고, FAILED면 로그를 연다. 이 루틴이 HPC 생활의 80%다. 참고로 PENDING이 떴다고 무조건 잘못된 게 아니다. 그냥 자리가 없어서 기다리는 중일 수도 있다. 대신 PENDING 사유가 (Resources, Priority 같은) 정상적인 이유인지, 아니면 요청 옵션이 잘못돼서 영원히 못 잡는 상태인지 그걸 보는 게 중요하다.

로그 보는 법:

tail -f logs/slurm-XXXX_baseline.out

GPU가 실제로 잡혔는지, loss가 내려가는지, 갑자기 멈추진 않는지. 그리고 멈췄을 때는 대부분 두 종류다. 하나는 메모리 터짐(OOM), 하나는 데이터/경로 문제로 즉사. 둘 다 로그에 힌트가 남는다.

베이스라인 결과 분석

추론이 끝나면 결과를 본다.

import json

with open("outputs/baseline_dev_results.json", "r") as f:
    results = json.load(f)

print(f"ROUGE-1: {results['rouge1']:.4f}")
print(f"ROUGE-2: {results['rouge2']:.4f}")
print(f"ROUGE-L: {results['rougeL']:.4f}")

시나리오 1 실험 결과 (KoBART 베이스라인)

100개 샘플로 돌린 결과다.

점수가 처참하다. 왜 그런지 실제 출력을 보면 바로 이해된다.

문제가 보이는 샘플

샘플 1: 완전히 엉뚱한 내용

[모델 출력]
제265회 국회(임시회) 제2차 법안심사소위원회를 개의해 주신 위원 여러분께
감사의 말씀을 드렸고, '강창일] 오늘 회의에서는 지난 수요일 제1차 회의에 이어...

[정답]
의사일정 제4항 지방자치법 일부개정법률안은 특별지방자치단체를 설치하고
경제자유구역청을 특별지방자치단체로 전환하며 성과공시제도를 입법화하는 내용으로서...

모델이 회의 시작 부분만 보고 개의합니다, 감사합니다 같은 의례 발언을 요약이라고 뱉었다. 진짜 논의 내용은 뒤에 있는데 거기까지 못 봤다.

샘플 2: 입력 잘림으로 인한 정보 손실

[모델 출력]
작년 12월 5일에 처음 상정된 이 법안은 작년 11월 30일에 상정된 소위가 두 번째입니다.
작년 12월 4일에 처음 올렸는데 그때 변호사 출신의 법무담당관과...

[정답]
본 회의는 법사위원회 산하 법안심사제1소위원회의 법무부 소관 법률에 대한 심의를
위한 회의로, 먼저 정부가 제출한 정부법무공단법안 제정안에 대해 논의하였다...

회의 맥락은 잡았는데 핵심 내용(정부법무공단법안)을 전혀 못 잡았다.

실패 유형 분석

100개 중 4개만 쓸만했다. 나머지 96개는 문제가 있다.

점수가 낮은 이유는 뻔하다. 입력이 잘린다. 1024 토큰 제한 때문에 앞부분만 보고 요약한다. 그리고 개의하겠습니다 같은 의례 발언이 섞여서 모델이 헷갈린다.

이게 바로 다음 단계(전처리)가 필요한 이유다.

시나리오 2: 전처리 방식 비교

그래서 전처리를 바꿔봤다. 세 가지 버전으로.

• v0: 원본 그대로 (발화 이어붙이기만)
• v1: 같은 화자 연속 발언 결합
• v2: 의례 발언 제거 + 키워드 추출

결과가 재밌게 나왔다.

예상과 다르게 v2가 ROUGE는 가장 낮다. 왜일까?

compression_ratio를 보면 답이 나온다.

• v0: 0.87% (입력 거의 안 줄어듦)
• v2: 14.87% (입력이 많이 줄어듦)

v2는 의례 발언을 제거해서 입력이 짧아졌고, 그래서 모델이 더 많은 내용을 볼 수 있었다. 근데 ROUGE가 낮은 이유는 출력 길이가 달라져서다. BERT-Score가 높은 건 의미적으로는 더 잘 맞춘다는 뜻.

결론은 단순 ROUGE만 보면 안 된다는 거다. 전처리 효과는 복합적이다.

시나리오 3: Long-context 비교

긴 문서에서 long-context 모델이 효과 있을까? 평균 36,000자짜리 긴 회의록 50개로 테스트했다.

결과가 좀 아쉽다. 둘 다 truncation_rate가 100%라서 결국 전부 잘렸다. 긴 회의록은 평균 36,000자인데 KoBART는 1024토큰, phi-2는 2048토큰이 한계라서 어차피 앞부분만 보게 된다.

그래도 KoBART가 phi-2보다 ROUGE-1 기준 3.7배 좋다. 이건 S6에서 본 것처럼 언어 특화의 힘이다. long-context가 의미 있으려면 최소 16K 이상 지원하는 모델이 필요하다. LongChat-7B-16K나 Yarn-Mistral-7B-128K 같은 모델이 필요한데, 메모리 문제로 이번엔 못 돌렸다.

시나리오 4: 프롬프트 비교 (phi-2)

프롬프트 엔지니어링이 얼마나 효과 있는지 봤다. phi-2(2.7B)로 세 가지 프롬프트를 비교했다.

• simple: 그냥 "요약해주세요"
• structured: 형식을 명시 (핵심 안건, 주요 논의, 결정사항)
• extractive_guide: 추출적 요약 가이드라인 제공

점수가 전체적으로 낮다. phi-2가 한국어에 약하기 때문이다. 하지만 상대적으로 보면 structured 프롬프트가 ROUGE 기준 최고고, extractive_guide가 BERT-Score 최고다. simple은 가장 나쁘다. 아무 가이드 없으면 모델이 헤맨다.

결론은 프롬프트 설계가 중요하긴 하지만, 모델 자체가 한국어를 못하면 한계가 있다는 거다.

시나리오 5: 피벗 번역 (한→영→한)

이건 좀 재밌는 실험이다. 한국어 요약이 잘 안 되니까, 아예 영어로 바꿔서 요약하고 다시 한국어로 번역하면 어떨까?

놀랍게도 피벗 방식이 47% 더 좋다. 한국어 → 영어 번역 → 영어 요약 → 한국어 번역. 번역 두 번 하는데도 더 낫다니.

왜 그럴까? 영어 요약 모델이 훨씬 성능이 좋고, 번역 모델(NLLB)이 꽤 괜찮아서 정보 손실이 적다. 결국 약한 한국어 능력보다 강한 영어 능력에 번역 비용 더한 게 낫다는 얘기다.

물론 추론 시간은 3배 이상 걸린다. 하지만 품질이 더 중요한 상황이라면 고려해볼 만하다.

시나리오 6: 모델 규모 비교

더 큰 모델이 더 좋을까? KoBART(124M) vs phi-2(2.7B)를 비교했다.

충격적인 결과다. 22배 큰 모델이 오히려 더 못한다.

왜 그럴까? KoBART는 한국어로 학습됐고 요약용으로 파인튜닝됐다. phi-2는 영어 중심이고 범용 LLM이다. 언어 특화와 태스크 특화가 그만큼 중요하다는 거다. 큰 모델이라고 좋은 게 아니다. 도메인과 태스크가 안 맞으면 의미없다.

효율성 측면에서는 KoBART가 45배 더 효율적이다 (score_per_second 기준).

결론은 무조건 큰 모델 쓰지 말고 태스크에 맞는 모델을 찾으라는 거다.

전체 실험 요약

핵심 교훈은 네 가지다. 첫째, 입력 길이 문제가 가장 크다. long-context 모델이 필요하다. 둘째, 언어 특화 모델이 범용 LLM보다 낫다. 셋째, 프롬프트 엔지니어링은 도움이 되지만 한계가 있다. 넷째, 피벗 번역은 의외로 효과적인 대안이다.

핵심 정리

HPC를 쓰기 시작하면 아무리 늦어도 결국 마주치게 되는 게 Slurm이다. 처음엔 그냥 “GPU 쓰려면 이거 해야 한대” 수준으로 지나가지만, 조금만 써보면 깨닫게 된다. Slurm은 선택지가 아니라 전제 조건이라는 것을... 이미지 출처 : 위키백과

1. Slurm은 왜 필요해졌을까

GPU / CPU는 항상 부족하다

연구실에 사람이 100명 있고 GPU가 16개면, 누가 지금 GPU를 쓰는지 알 수 없고, 먼저 접속한 사람이 계속 점유하고, 누군가 실수로 프로세스 날리고, 학습 중이던 실험은 그대로 터진다. 이게 “이론적으로”가 아니라 실제로 흔하게 생긴다. 그리고 공용 서버는 이런 상황이 한 번 터지면 진짜로 다 같이 피곤해진다.

공정하게 나눌 방법이 필요했다

딥러닝 학습은 몇 분짜리 작업이 아니라 보통 수시간~수십시간 단위고, 길면 며칠 동안 GPU를 붙잡는다. 이걸 아무 제약 없이 풀어두면 서버는 곧 몇 명의 전유물이 된다. 그래서 “누가, 어떤 자원을, 얼마나 쓰는지”를 시스템이 강제로 관리하는 구조가 필요해졌고, 그 역할을 하는 게 스케줄러다.

자동화 없이는 운영이 안 된다

사람 손으로는 절대 운영이 안 된다. job 끝나면 다음 작업 자동 실행, 자원 사용 기록, 여러 노드에 걸친 분산 작업 실행 같은 걸 사람이 매번 수동으로 한다? 불가능하다. 그래서 Job Scheduler가 등장했고, HPC 환경에서는 Slurm이 사실상 표준처럼 굴러간다(센터/기관마다 PBS 같은 다른 스케줄러도 있긴 한데, 국내 대학/연구실은 Slurm 비율이 진짜 높다).

2. Slurm의 기본 사고방식

복잡하게 생각할 필요 없다. Slurm이 하는 일은 딱 세 가지다. 자원을 예약하고, 작업을 큐(queue)에 넣고, 빈 자리가 나면 알아서 실행한다. 즉 “GPU를 직접 잡고 쓰는 것”이 아니라 GPU 사용권을 요청해서 배정받는 구조라는 게 핵심이다. 여기서 제일 중요한 마인드셋은 이거다: 로그인 노드에서 뭔가를 돌리는 게 아니라, 계산 노드에서 돌릴 수 있게 ‘요청서를 제출하는 방식’이다.

3. HPC에서의 기본 흐름

항상 이 순서로 돌아간다.

User → Login Node → Slurm Scheduler → Compute Node (GPU/CPU)

로그인 노드는 접속해서 파일 올리고, 환경 잡고, 작업 제출하는 곳이다. 여기서 학습을 돌리면 안 된다(정확히는 “절대 금지”로 막아둔 곳도 많고, 안 막아도 하면 민폐가 된다). 스케줄러(Slurm)는 누가 뭘 요청했는지 보고 순서랑 자원 배치를 결정한다. 계산 노드는 실제 GPU 연산이 일어나는 곳이다. Aurora든 Ariel이든 큰 구조는 거의 비슷하고, 달라지는 건 “GPU 종류/노드 스펙/파티션 정책/시간 제한” 같은 운영 디테일이다.

4. 가장 많이 쓰는 Slurm 명령어들

외울 필요는 없고 자주 쓰는 것만 손에 익히면 된다(고 생각하긴한다)

여기서 포인트 하나. nvidia-smi는 “로그인 노드에서 치는 명령”이 아니라, GPU가 잡힌 계산 노드에서 확인하는 용도다. 그래서 보통 srun으로 노드 들어간 다음에 확인하는 흐름이 자연스럽다.

그리고 sinfo 봤을 때 파티션(partition)이 여러 개면, 그건 “GPU용 큐 / CPU용 큐 / 수업용 큐 / 연구용 큐” 이런 식으로 나뉘어 있는 경우가 많다. 그때는 --partition=... 옵션을 써야 할 때가 있다(안 쓰면 기본 파티션으로 들어가거나, 아예 제출이 거절될 수도 있음).

5. sbatch vs srun (처음에 제일 헷갈리는 포인트)

sbatch

배치 작업이다. 스크립트 제출하면 큐에 들어가고, 차례가 오면 알아서 시작되고, 알아서 끝난다. 결과는 로그 파일로 확인한다. 긴 학습, 실험 돌리기, 밤새 돌리기 전부 sbatch다.

srun

인터랙티브 작업이다. GPU 붙은 쉘을 하나 받는 느낌이다. 디버깅, 환경 확인, “이 코드 돌아가나?” 테스트할 때 쓴다. 단, 오래 돌릴 거면 srun으로 버티는 게 아니라 sbatch로 넘기는 게 정석이다(연결 끊기거나, 세션 꼬이면 피곤해진다).

정리하면 이거다. “이 코드가 돌아갈까?” → srun / “이제 제대로 학습 돌린다” → sbatch

6. 최소 Slurm 스크립트 예시

#!/bin/bash
#SBATCH --job-name=train
#SBATCH --gres=gpu:1
#SBATCH --time=24:00:00
#SBATCH --output=logs/%j.out

source ~/.bashrc
conda activate myenv

python train.py \
  --epochs 3 \
  --batch_size 16

여기서 %j는 job id로 자동 치환된다. 로그는 무조건 파일로 남기는 게 맞고, stdout만 믿고 nohup 같은 걸로 버티는 건 HPC에서는 굳이 추천하지 않는다(어차피 Slurm이 로그를 남겨준다). 그리고 은근히 중요한 게 하나 더 있는데, logs/ 폴더는 미리 만들어놔야 한다. 없으면 출력 경로 때문에 job이 바로 실패하는 경우도 있다.

실제로는 여기서 메모리/CPU도 같이 지정하는 경우가 많다. 예를 들면 --cpus-per-task=4, --mem=16G 같은 옵션들. GPU만 잡아놓고 CPU나 메모리를 너무 적게 잡으면 데이터 로더에서 병목 걸리거나, 반대로 메모리 부족으로 학습이 터질 수도 있다. 그러니까 “GPU만 있으면 끝”이 아니라, GPU+CPU+RAM이 세트로 돌아간다고 생각하는 게 편하다.

결론

Slurm은 GPU를 쓰기 어렵게 만드는 시스템이 아니라, 여러 사람이 안전하게 쓰게 만드는 시스템이다. 처음엔 귀찮고 명령어도 많아 보이지만, sinfo, squeue, srun, sbatch 이 네 개만 익숙해지면 HPC의 절반은 넘은 거다. 그리고 진짜 중요한 건, “내가 지금 어느 노드에서 뭘 돌리고 있는지” 이걸 계속 의식하는 습관이다. 로그인 노드에서 돌리는 순간부터 대부분의 사고가 시작한다.

LLM (Large Language Model)

• 사람처럼 문장을 생성하는 대규모 언어 모델
• GPT, LLaMA 같은 모델 전부 여기에 포함

추론(Inference)

• 이미 학습된 모델이 입력을 받아서 답을 생성하는 과정
• 학습(training)과 반대 개념

서빙(Serving)

• 모델을 여러 사람이 동시에 쓰도록 API 형태로 제공하는 것
• “모델 실행” + “요청 관리” + “운영”까지 포함

LLM(Large Language Model)은 대규모 텍스트 데이터를 학습해 문장을 생성하는 모델을 의미한다. GPT, LLaMA 계열 모델 모두 여기에 포함된다.

이 모델을 학습이 끝난 상태에서 실제로 문장을 생성하는 과정을 추론(inference)이라고 한다. 즉, “질문을 넣고 답을 받는 행위” 자체가 추론이다.

서빙(serving)은 여기서 한 단계 더 나아간 개념이다. 단순히 모델을 실행하는 것이 아니라, 여러 사용자가 동시에 모델을 사용할 수 있도록 API 형태로 제공하고, 요청 관리·지연 시간·장애 대응까지 포함한 운영 관점의 개념이다.

이 구분이 중요한 이유는,

• 추론만 잘 되는 구조와
• 서빙까지 고려된 구조가 완전히 다른 방향으로 설계되기 때문이다.

실행 도구 / 프레임워크 용어

llama.cpp

• 로컬 PC에서 LLM을 실행하기 위한 경량 추론 엔진
• CPU에서도 동작 가능
• 개인 실험용에 최적화

vLLM

• GPU 기반 LLM 서빙 프레임워크
• 여러 요청을 동시에 효율적으로 처리하는 데 초점

TGI (Text Generation Inference)

• HuggingFace에서 만든 프로덕션용 LLM 서빙 시스템
• Kubernetes, API 운영에 적합

FastAPI

• Python 기반 API 서버 프레임워크
• llama.cpp를 감싸서 간단한 서버를 만들 때 사용

자원의 차이

CPU

• 일반적인 연산 장치
• 복잡하지만 병렬성이 낮음

GPU

• 단순한 연산을 대량 병렬 처리하는 장치
• LLM 추론에 매우 유리

RAM

• 일반 메모리
• CPU가 사용하는 작업 공간

VRAM

• GPU 전용 메모리
• 모델 가중치, KV cache가 올라감
• 부족하면 실행 자체가 안 됨

CPU는 복잡한 작업을 소수의 코어로 처리하는 범용 연산 장치다. 반면 GPU는 단순한 연산을 수천 개 코어로 동시에 처리하는 병렬 연산 장치다.

Transformer 기반 LLM은 행렬 곱 연산이 대부분이기 때문에 GPU 구조와 잘 맞는다. 이 때문에 LLM 추론은 GPU에서 훨씬 효율적이다.

여기서 메모리 개념이 나뉜다.

• RAM: CPU가 사용하는 일반 메모리
• VRAM: GPU 전용 메모리

LLM 추론 시에는 다음이 VRAM에 올라간다.

• 모델 가중치(weight)
• KV cache
• 중간 연산 결과

따라서 VRAM이 부족하면, RAM이 아무리 많아도 모델은 실행되지 않는다.

숫자 표현 방식과 FP16의 의미

7B / 13B / 70B

• 모델 파라미터 개수
• B = Billion (10억)
• 크다고 무조건 좋은 건 아님

context length (n_ctx)

• 모델이 한 번에 기억할 수 있는 토큰 길이
• 길수록 메모리 사용량 증가

딥러닝 모델의 가중치는 결국 숫자다. 이 숫자를 몇 비트로 표현하느냐가 메모리 사용량과 성능에 직접적인 영향을 준다.

대표적인 표현 방식은 다음과 같다.

FP32 (32비트): 정밀도 높음, 4바이트
FP16 (16비트): 정밀도 중간, 2바이트
INT8 (8비트): 정밀도 낮음, 1바이트

FP16은 FP32 대비 모델 크기를 정확히 절반으로 줄인다.

예를 들어 7B 모델 기준으로 보면,

• FP32: 약 28GB
• FP16: 약 14GB

이 차이로 인해 GPU VRAM에 더 큰 모델을 올릴 수 있게 된다.

중요한 점은, FP16은 “품질을 크게 희생한 옵션”이 아니라, 추론 환경에서 사실상 표준에 가까운 설정이라는 점이다. 대부분의 추론 프레임워크는 FP16 또는 BF16을 기준으로 성능과 안정성을 설계하며, 성능 손실은 일반적으로 1–2% 이내로 알려져 있다.

GGUF와 양자화

GGUF

• llama.cpp용 모델 포맷
• 가중치 + 토크나이저 + 메타데이터 포함
• 로컬 실행에 최적화

safetensors

• HuggingFace 표준 모델 포맷
• GPU 서빙 환경에 적합
• vLLM/TGI에서 주로 사용

Transformers weights

• HuggingFace Transformers 라이브러리에서 사용하는 모델 가중치

GGUF는 llama.cpp 개발자 Georgi Gerganov가 만든 모델 저장 포맷이다. 기존 GGML 포맷을 개선한 형태로, 로컬 LLM 실행을 전제로 설계되었다.

GGUF의 핵심 특징은 다음과 같다.

1. 모델 가중치와 토크나이저, 메타데이터가 한 파일에 포함된다.
2. 메모리 매핑이 최적화되어 RAM 사용이 효율적이다.
3. 양자화 정보가 파일 자체에 내장된다.

파일 이름만 봐도 설정을 유추할 수 있다.

llama-2-7b.Q4_K_M.gguf

• Q4: 4비트 양자화
• K: K-quant 방식
• M: 중간 품질 프로파일

양자화는 가중치를 더 적은 비트로 표현해 메모리 사용량을 극단적으로 줄이는 기법이다.

예를 들면,

• FP16 원본: 14GB
• Q4_K_M: 약 4.5GB
• Q8_0: 약 8GB

이 덕분에 CPU 환경에서도 7B, 13B 모델 실행이 가능해졌다.

다만 GGUF 기반 양자화는 로컬 단일 요청 실행에 최적화된 구조이며, GPU 서빙 환경에서는 AWQ, GPTQ 같은 다른 양자화 방식이 사용된다.

양자화(Quantization) 용어

양자화(Quantization)

• 모델 가중치를 더 적은 비트로 표현해서 메모리를 줄이는 기법

Q4 / Q5 / Q8

• 가중치를 몇 비트로 저장하는지 의미
• 숫자 ↓ → 메모리 ↓ / 품질 손실 가능성 ↑

AWQ / GPTQ

• GPU 서빙 환경용 양자화 방식
• GGUF와는 다른 계열

llama.cpp, vLLM, TGI

앞선 두 글에서 자주 언급하긴 했지만... llama.cpp는 로컬 환경에서 LLM을 실행하기 위한 경량 추론 엔진이다. 단일 프로세스, 단일 요청을 빠르고 가볍게 처리하는 데 초점이 맞춰져 있다.

반면 vLLM과 TGI는 처음부터 다중 사용자 서빙을 전제로 설계되었다.

• continuous batching
• KV cache 최적화
• GPU 활용률 극대화
• 스트리밍 응답

vLLM은 특히 continuous batching과 PagedAttention을 통해, 요청이 늘어날수록 GPU 효율이 오히려 좋아지는 구조를 만든다.

TGI는 여기에 더해 pipeline parallelism, Kubernetes 연계를 통한 운영 기능까지 포함한다.

내부 동작 개념 — 토큰, KV cache, batching

Token

• 모델이 처리하는 최소 단위
• 단어보다 더 잘게 쪼개진 단위

Throughput

• 초당 처리 가능한 토큰 양
• 서버 성능 지표

Latency

• 요청 → 응답까지 걸리는 시간
• 사용자 체감 속도

KV Cache

• 이전 토큰 계산 결과를 저장하는 캐시
• 길어질수록 메모리 사용 증가

Continuous Batching

• 여러 사용자의 요청을 자동으로 묶어서 GPU에 한 번에 처리
• vLLM의 핵심 기술

PagedAttention

• KV cache를 효율적으로 쪼개 관리하는 방식
• vLLM 내부 최적화 기법

LLM은 문장을 토큰(token) 단위로 처리한다. 사용자가 입력한 문장과 모델이 생성하는 응답은 모두 토큰 단위로 쪼개진다.

이 과정에서 이전 토큰 계산 결과를 저장하는 것이 KV cache다. Context가 길어질수록 KV cache가 커지고, VRAM 사용량도 함께 증가한다.

vLLM의 핵심은 이 KV cache를 요청 단위가 아니라 prefix 단위로 관리한다는 점이다. 이를 통해 여러 요청이 동일한 system prompt를 공유할 수 있고, batching 효율이 극적으로 올라간다.

운영 관점 | 왜 “돌아간다”와 “서비스 가능”은 다른가

API

• 외부에서 모델을 호출하기 위한 인터페이스

SLA

• 서비스 품질 보장 기준
• 응답 시간, 가용성 등

동시 요청 (Concurrency)

• 여러 사용자가 동시에 요청을 보내는 상황

Queue

• 요청이 처리되기 전 대기하는 줄

Blocking

• 하나의 요청이 끝날 때까지 다른 요청이 기다리는 상태

Observability (관측성)

• 로그, 메트릭, 상태를 관찰할 수 있는 능력

Kubernetes (K8s)

• 컨테이너 기반 서버를 자동으로 배포·확장하는 시스템
• TGI와 자주 함께 사용

로컬 환경에서는 다음이 허용된다.

• 응답 시간이 길어도 괜찮음
• 가끔 OOM이 발생해도 재시작 가능
• 사용자는 한 명

하지만 서빙 환경에서는 전부 장애다.

• latency
• throughput
• 동시 요청 처리
• 헬스 체크
• 메트릭 수집
• 배포 전략

이 영역부터는 모델 성능이 아니라 시스템 설계 문제가 된다.

그래서 단순 실행 엔진인 llama.cpp와, 서빙 시스템인 vLLM/TGI는 같은 “LLM 도구”로 묶을 수 없다.

서빙 이전에 반드시 검증해야 할 것들

1. 모델 출력의 안정성

가장 먼저 확인해야 할 것은 동일 입력에 대한 출력 안정성이다.

• temperature를 낮췄을 때도 출력이 크게 흔들리는지
• system prompt 고정 시 응답 톤이 유지되는지
• context length 증가 시 갑작스러운 붕괴가 발생하지 않는지

이 단계에서 불안정한 모델은 서빙 환경에서 동시 요청과 배치 처리가 들어오면 더 쉽게 무너진다. 많은 서빙 이슈가 실제로는 모델 출력 불안정에서 시작된다.

2. Context 길이와 메모리 사용 패턴

로컬 실험에서는 단일 요청만 보는 경우가 많다. 하지만 서비스 환경에서는 다음이 동시에 발생한다.

• 긴 system prompt
• 누적되는 대화 히스토리
• KV cache 증가

반드시 확인해야 할 항목은 다음과 같다.

• n_ctx 증가에 따른 메모리 사용량 변화
• 응답 속도가 급격히 느려지는 지점
• context overflow 발생 시 모델의 반응

이를 모른 채 서빙으로 넘어가면, “트래픽 증가”가 아니라 메모리 구조 한계가 병목이 된다.

3. 프롬프트 구조의 재사용 가능성

서빙 환경에서는 대부분 system prompt가 고정된다. 많은 요청이 동일한 prefix를 공유한다는 의미다.

• system / user / assistant 역할 구분의 명확성
• 과도하게 긴 system prompt 여부
• instruction 간 충돌 여부

이 구조가 정리되지 않으면 batching이나 KV cache 최적화의 이점을 제대로 얻기 어렵다.

4. “느리지만 된다”와 “서비스 가능”의 차이

로컬 환경에서는 다음이 허용된다.

• 응답 시간 20~30초
• occasional OOM
• 간헐적 hallucination

서빙 환경에서는 모두 장애다. 서빙 이전에 스스로에게 물어봐야 한다.

이 상태를 외부 사용자에게 그대로 노출해도 되는가

이에 자신 있게 답할 수 있을 때만 서빙 프레임워크로 넘어가는 것이 맞다.

로컬 LLM 튜닝 실험에서 반복한 실패 패턴

1. 모델 크기로 모든 걸 해결하려 했던 시기

가장 흔한 실패다.

• 응답이 애매하다 → 모델을 키운다
• 추론이 어색하다 → 더 큰 모델을 찾는다

하지만 실제 원인은 다음인 경우가 많았다.

• 프롬프트 구조의 불명확함
• instruction tuning이 안 된 베이스 모델
• context 설정 오류

모델 크기는 마지막 레버리지이지, 문제 해결의 출발점이 아니었다.

2. 양자화를 무조건 성능 하락으로 봤던 오해

초기에는 Q4, Q5 모델 사용이 불안했다. 그러나 실제로는 다음과 같은 특성이 보였다.

• instruction-following 능력은 큰 차이가 없음
• 차이는 주로 미세한 표현력에서 발생
• 메모리 여유로 context를 늘릴 수 있음

로컬 실험 단계에서는 양자화 모델이 오히려 생산적이었다.

3. 튜닝과 프롬프트를 구분하지 못했던 시기

한동안 “튜닝”이라고 부르던 작업의 대부분은 프롬프트 조정이었다.

• 출력 불만족 → prompt 수정
• 톤 불안정 → system message 추가
• 태스크 실패 → 예시 추가

프롬프트는 입력 제어이고, 튜닝은 모델 분포 자체를 바꾸는 작업이다. 이 구분이 생긴 이후에야 판단이 명확해졌다.

4. 로컬 성공을 서비스 성공으로 착각한 지점

로컬에서 잘 동작하던 모델이 서비스 환경에서 쉽게 깨지는 이유는 명확하다.

• 동시 요청
• 긴 세션
• 사용자 입력의 다양성

로컬 실험의 목적은 “잘 되는 예시”를 찾는 것이 아니라, 어디서 깨지는지 확인하는 과정에 가깝다.

특히 GPU 환경이나 모델 서빙 구조에 대한 이해가 거의 없는 상태에서 시작해, 로컬 추론과 서비스용 추론의 차이를 체감하기까지의 흐름은 이후 기술 선택에 중요한 기준이 되었다.

초기 목표 “로컬에서 모델이 돌아가는지 확인하기”

외부 API나 클라우드 환경 없이, 개인 노트북에서 LLM을 직접 실행할 수 있는지 확인하는 것이 중요했다. GPU, VRAM, 연산 정밀도 같은 개념보다는 “실제로 문장이 생성되는가”가 중요했다. 일단 동작해야 이후의 학습과 변형을 논할 수 있었다.

개인 학습 과정에서 AWS GPU를 지속적으로 사용하기는 현실적으로 어려웠고, 그 결과 CPU 환경에서도 동작 가능한 추론 엔진을 찾게 되었다.

llama.cpp를 통한 로컬 추론 경험

llama.cpp는 C++ 기반의 경량 추론 엔진으로, 로컬 환경에서 LLM을 실행하는 데 최적화되어 있다. GGUF 포맷과 양자화 모델을 사용하면 GPU 없이도 비교적 큰 모델을 실행할 수 있다는 점이 인상적이었다.

• RAM 16GB 환경에서도 7B 모델 실행 가능
• CPU만으로도 토큰 생성 확인
• 실행 구조가 단순해 디버깅 부담이 적음

이 시점에서의 결론은 명확했다. llama.cpp는 서비스 프레임워크라기보다는 로컬 추론을 위한 실행 엔진에 가깝다. 실험과 검증 단계에 매우 적합한 도구였다.

GGUF와 양자화에 대한 이해

초기에는 단순히 파일 이름만 보고 모델을 선택했다.

llama-3-8b.Q4_K_M.gguf

점차 GGUF 포맷과 양자화 방식의 의미를 이해하면서 모델 선택 기준이 바뀌었다.

• GGUF: llama.cpp에 맞춰 메타데이터와 토크나이저 정보를 포함한 포맷
• Q4 / Q5 / Q8: 가중치 표현 비트 수
• 비트 수가 낮을수록 메모리 사용량은 줄지만 품질 손실 발생

이해가 쌓이면서 “가장 큰 모델”이 아니라 환경과 목적에 맞는 모델을 선택하게 되었다. 이때부터 로컬 챗봇은 단순한 데모를 넘어 실험 도구로 기능하기 시작했다.

FastAPI로 감싼 이후 드러난 한계

모델 실행이 안정화된 이후, 이를 API 형태로 제공할 수 있는지 실험했다. llama.cpp를 백엔드 엔진으로 두고 FastAPI로 간단한 엔드포인트를 구성하는 방식은 소규모 테스트 환경에서는 충분히 동작했다.

그러나 동시 요청이 발생하는 순간 구조적 한계가 드러났다.

• 요청이 직렬로 처리됨
• 앞선 요청의 응답 시간이 길어질수록 전체 지연 증가
• 큐 적체 시 체감 latency 급증

이는 구현상의 문제가 아니라, 설계 목적의 차이에 가까웠다.

vLLM을 통해 인식한 “서빙”의 개념

vLLM을 살펴보며 관점이 바뀌었다. vLLM은 단순히 모델을 실행하는 도구가 아니라, 여러 요청을 동시에 처리하는 것을 전제로 한 서빙 시스템이었다.

• continuous batching을 통한 GPU 활용 극대화
• KV cache 최적화로 prefix 중복 계산 제거
• 동시 요청 환경에서도 안정적인 latency 유지

이 지점에서 두 접근의 차이는 명확해졌다. 전자는 개인 또는 소규모 실험에 최적화된 추론 엔진, 후자는 프로덕션 환경을 전제로 한 추론 서비스 시스템이다.

정리

• 로컬 실험, 개인용 챗봇, 오프라인 실행 → llama.cpp
• 다수 사용자, API 제공, SLA 요구 → vLLM 또는 TGI
• 현실적인 접근은 llama.cpp로 시작해 vLLM으로 전환

기술 선택의 문제가 아니라, 문제의 규모와 성격에 따른 선택에 가깝다.

자 이걸 쓰는 이유!

로컬에서만 작업하면 본인 편한대로 파일 구조(Directory)를 짜도 되지만, 서버에서 학습을 시킬 생각이라면 그 구조에 맞게 구조를 짤 수 있으니까!

귀찮으면 Cursor한테

ssh 접속해서 클러스터 구조 파악하고 디렉토리 짜줘.

하면 되긴하지만 구조를 이해해봅시다.

HPC(고성능 클러스터) 기본 구조와 Aurora(Ariel) 서버 디렉토리 안내

https://www.hpc.iastate.edu/guides/introduction-to-hpc-clusters/what-is-an-hpc-cluster

고성능 연산 클러스터(HPC, High Performance Computing)는 여러 대의 독립된 컴퓨팅 노드(node)를 하나의 시스템처럼 묶어 대규모 연산을 수행하도록 설계된 구조입니다. 일반적으로 로그인 노드(Login Node), 계산 노드(Compute Node, GPU/CPU), 관리 노드(Management Node), 그리고 공유 스토리지(Storage Node) 등으로 구성되며, 사용자는 로그인 노드에 SSH로 접속하여 코드를 업로드하고, Slurm과 같은 스케줄러를 통해 계산 노드에 작업(Job)을 제출합니다. 모든 노드는 고속 인터커넥트(InfiniBand 등)로 연결되어 있어 분산 학습, 병렬 연산, 대규모 데이터 입출력 작업을 효율적으로 처리할 수 있습니다. 이러한 구조를 통해 HPC는 단일 컴퓨터로는 수행하기 어려운 대규모 AI 학습, 시뮬레이션, 과학 계산을 안정적으로 실행할 수 있는 환경을 제공합니다.

고성능 연산을 위해 제공되는 HPC 클러스터는 로그인 노드, 계산 노드(GPU·CPU), 공유 스토리지 등으로 구성된 분산 컴퓨팅 환경입니다. 사용자는 SSH로 로그인 노드에 접속한 뒤, Slurm을 이용하여 작업을 제출하거나 SFTP로 데이터를 전송하며 대규모 연산을 수행합니다. 이러한 클러스터는 일반적으로 홈 디렉토리(/home/{your_id}) 와 작업 디렉토리(/data/{your_id}) 를 분리해 관리하며, 홈은 용량이 작고 백업이 지원되는 반면, /data 영역은 연구 프로젝트·데이터셋·모델을 저장하는 실질적 작업 공간으로 활용됩니다. (정확히 말하자면, ※ /home은 Slurm 작업 실행 시 I/O 속도가 느릴 수 있으므로, 실제 학습 데이터나 체크포인트 저장은 /data 영역을 사용해야 합니다. ) 대부분의 HPC가 /home, /data, /scratch 계층을 갖추지만, 우리 학교의 Aurora/Ariel 계열 서버는 /home과 /data를 중심으로 구성되어 있으며 /scratch 또는 /local_datasets는 GPU 노드 내부에서만 제공될 가능성이 있습니다(불확실). 따라서 SSH 접속 후 다음 명령어를 실행하여 실제 영역을 확인하는 것이 중요합니다.

# 홈 디렉토리 확인
echo $HOME
pwd

# 마운트된 디스크 확인
df -h

# 대표 디렉토리 존재 여부 검사
ls -la /home 2>/dev/null || echo "/home 없음"
ls -la /data 2>/dev/null || echo "/data 없음"
ls -la /scratch 2>/dev/null || echo "/scratch 없음"
ls -la /local_datasets 2>/dev/null || echo "/local_datasets 없음"

# 환경 변수에서 경로 힌트 찾기
env | grep -i home
env | grep -i data
env | grep -i scratch

이 명령어들을 실행하면 Ariel 서버의 스토리지 구조가 /home/{your_id}와 /data/{your_id} 중심인지, 혹은 노드별 임시 스토리지(/scratch, /local_datasets)가 존재하는지를 정확히 확인할 수 있습니다.

자자,,, 위는 그냥 디렉토리 잘 나눠라! 하는 잡도리였고요. HPC가 뭐냐? 뭔...뭔...뭐냐!! 할겁니다... 저도 몰랐음

이제 HPC 자세히 알려줄건데 이해 안되면 넘겨도 됨.

클러스터 구조를 이해하기 위한 기본 프레임

아래는 “클러스터가 무엇인가?”를 처음 보는 사람도 이해할 수 있게, 몇 개 문단으로 간단하지만 정확하게 정리한 설명이다.

🔵 클러스터(Cluster)란 무엇인가?

• User → Login Node → Scheduler → Compute Nodes 사용자는 로그인 노드를 통해 접속하고, 모든 작업은 스케줄러가 적절한 노드에 배치한다.

• Compute Nodes는 스토리지와 분산 I/O를 수행 (Compute Node는 연산을 수행하고, 데이터는 공유 스토리지(/data 등)에서 읽고 쓴다.) 데이터셋, 중간 산출물, 체크포인트는 모두 Storage Cluster에 저장된다.
• Control Plane(Master/Manager) 전체 클러스터의 상태, 스케줄링, 스토리지 메타데이터, 노드 헬스 체크를 담당한다.
• Storage Cluster는 Ceph/Lustre/HDFS 등으로 구성 HPC/빅데이터/K8s 모두 Storage Layer만 바뀌고 구조는 동일하다. (사실 큰 틀에서 “여러 노드를 묶어서 스케줄링한다”는 공통점은 있지만, HPC/빅데이터/K8s는 목적과 실행 방식이 달라 구조가 완전히 같진 않다.)

※ 로그인 노드(Login Node)는 계산용이 아니라 명령 제출·환경 설정만 하는 곳입니다.
여기서 직접 학습을 돌리면 다른 사용자의 자원을 침해하게 되므로 반드시 Slurm으로 Job을 제출해야 합니다.

쿠버네티스 클러스터 생각하면 어렵지 않아요! 근데 굳이 또... 서버를 써보기 위해 꼭 당장 알아야한다!의 개념은 아니라고 생각해서 간단히 보고 넘기셔도 될 것 같습니다.

이미지 출처

클러스터(Cluster)는 여러 대의 컴퓨터(노드, node)를 하나의 큰 컴퓨터처럼 묶어 사용하는 시스템 구조입니다. 단일 서버로는 처리하기 어려운 큰 연산·데이터·서비스를 분산해서 처리하기 위해 만들어졌으며, 사용자는 마치 하나의 거대한 컴퓨터처럼 접근하지만 실제 내부에서는 수십~수백 대의 노드가 협력해 일하는 거죠!

클러스터의 핵심은 분산(Distributed) 입니다. 하나의 서버가 고장나거나 과부하 걸려도 전체가 중단되지 않도록 여러 노드가 역할을 나눠 수행합니다. 예를 들어 어떤 노드는 계산만 담당하고(Compute Node), 다른 노드는 데이터 저장을 담당(NFS, Ceph, Lustre), 또 다른 노드는 사용자의 명령이나 작업 배치를 관리(Login Node, Scheduler Node)합니다. 이렇게 역할을 분리해 운영하면 성능·확장성·안정성 모두 크게 향상되겠죠?

또한 대부분의 클러스터는 스케줄러(Scheduler) 라는 시스템을 통해 운영됩니다. 스케줄러는 사용자가 제출한 연산 작업(job)을 어떤 노드에 배치할지 자동으로 결정하고, 동시에 여러 사용자가 자원을 공유하도록 관리한다. HPC에서는 Slurm, 데이터 처리에서는 YARN, 서비스 운영에서는 Kubernetes 등이 대표적입니다. 이 스케줄링 시스템 덕분에 수십 명의 사용자가 하나의 클러스터를 공유해도 충돌이나 과부하 없이 효율적으로 사용이 가능합니다.

마지막으로, 클러스터는 목적에 따라 다양한 형태(HPC, HTC, Big Data, Storage, Kubernetes 등)로 나뉜다. 어떤 것은 대규모 연산이 목적이고(HPC), 어떤 것은 수백만 개의 작은 작업 처리가 목표이며(HTC), 어떤 것은 대규모 데이터 저장·가공이 중심이거나(Big Data, Storage), 어떤 것은 웹 서비스나 모델 서빙 운영에 최적화돼 있다(K8s). 목적에 따라 구조·네트워크·스토리지·스케줄링 방식이 달라지기 때문에, 클러스터는 “큰 컴퓨터”인 동시에 “특정 목적을 위해 조직된 분산 시스템”이라고 이해하면 된답니다.

다시 다시 말하지만 Aurora나 Ariel은 대강 이런 구조인 것!

그리고 MLOps에서 자주 쓰는 구조 중에 하나인데 이것도 알아두면 좋지 않을까?요~

Ceph 더 말하고 싶은데 지겨워할 것 같아서.... Ceph 잘 정리된 티스토리 공유합니다.

여기는 뛰어넘으셔도 됩니다

일단 클러스터는 항상 “유형(Type)”—“구현체(Instance)”—“스케줄링”—“스토리지” 네 가지 관점으로 나누어 이해해야 한다는 것입니다.

우리의 Auroa/Ariel기준으로 오른쪽에 설명했구요.

유형 TYPE

1) HPC Cluster (High Performance Computing) *대규모 병렬 연산·MPI·대규모 분산 학습 *2) HTC Cluster (High Throughput Computing) 수백만 개의 작은 job 처리, Condor/Ray 기반 워크로드 3) Big Data Cluster (Data-Parallel Cluster) Hadoop/Spark 기반 파일 병렬 처리 4) Storage Cluster (Distributed Storage Cluster) Ceph, Lustre, HDFS 같은 스토리지 전용 분산 시스템 5) Kubernetes Cluster (Cloud Native Cluster) 컨테이너 기반 MLOps·DevOps·Inference/Service 운영 *6) Hybrid / Multi-Cluster Architecture *HPC + Spark + K8s + Storage 조합(현대 AI 엔지니어링 표준)

실제 운영 환경에서는 아래와 같은 다양한 유형의 클러스터가 존재합니다.

각각이 좀 궁금하다면

HPC Cluster (High Performance Computing)

HPC

대규모 수치해석, 과학 계산, 딥러닝 학습을 위한 전통적 형태의 배치 기반 클러스터입니다.

• 예: Slurm 기반 GPU 노드, 슈퍼컴퓨터 센터

HPC 클러스터는 대규모 연산을 빠르게 처리하기 위해 설계된 배치 기반 환경이다. 슬럼(Slurm)·PBS 같은 스케줄러가 작업을 통제하며, 하나의 job이 수시간수일 동안 GPU/CPU 수십수백 개를 독점하는 구조를 전제로 한다. 노드 간 네트워크는 InfiniBand 등 고대역폭·저지연 인터커넥트를 사용해 MPI 기반 수치해석, 대규모 딥러닝과 같은 노드 간 파라미터 통신량이 많은 작업을 최적화한다. HPC의 강점은 계산 성능과 안정성이다. 반면, 서비스 운영에는 맞지 않으며 컨테이너 생태계와의 통합이 부족한 경우가 많다. 연구실·국가 슈퍼컴퓨터에서 주로 사용하는 이유도 “인터랙티브성”이 아니라 “정해진 시간 동안 최대 성능을 뽑아내는 구조”이기 때문이다.

HTC Cluster (High Throughput Computing)

HTC

작업 하나가 크지 않지만 수천~수만 개의 작은 작업을 처리해야 할 때 사용합니다.

• 예: 단백질 스크리닝, 로그 분석, 수백만 건의 짧은 inference job HTC 클러스터는 한 번의 연산은 작지만, 수만~수백만 개의 job을 순차·병렬로 계속 처리해야 하는 워크로드에 최적화되어 있다. 대표적으로 단백질 스크리닝, 로그 이벤트 분석, 대량 웹스케일 inference처럼 “작은 작업을 끊임없이 흘려보내는 구조”이다. 이 때문에 스케줄러는 throughput 기반으로 설계되며, 작업 하나가 길게 리소스를 독점하는 것을 막고 큐 대기 시간을 최소화하는 전략을 쓴다. HPC와 달리 고성능 네트워크가 필수는 아니지만, 잡 디스패치 속도(Job dispatch rate) 와 컨테이너 경량 실행이 중요하다. 많은 기관이 HTCondor, Ray, Airflow+K8s 조합을 HTC 용도로 사용하며, 대규모 MLOps 파이프라인의 “일괄 inference farm”으로도 쓰인다.

Big Data Cluster

빅데이터 클러스터

Hadoop/Spark 기반의 데이터 병렬처리 클러스터입니다.

• 초대용량 데이터 파이프라인, ETL, 대규모 통계 처리

빅데이터 클러스터는 Hadoop·Spark 같은 데이터 병렬 처리 프레임워크를 안정적으로 실행하기 위한 전용 구조이다. 계산보다는 저장된 파일을 노드 전체로 확산시키고, 이를 병렬 map/reduce 형태로 처리하는 것이 중심이므로 HDFS·S3와의 데이터 지역성(Locality)이 성능을 좌우한다. Spark는 메모리 기반 분산 계산을 지원하지만, GPU를 사용하는 HPC나 딥러닝 환경과는 목적이 전혀 다르다. 빅데이터 클러스터의 강점은 수백 TB~수 PB 단위 데이터를 “실시간은 아니지만 빠르게” 분석하는 능력이며, ETL·로그 분석·Feature Store 구축 등 AI 파이프라인의 전처리/후처리 영역을 담당한다. 최근 기업들은 Spark + Kubernetes 구조로 이동하며 관리 비용을 낮추는 추세다.

Storage Cluster

스토리지 클러스터 종류디지게많음

파일 및 객체 스토리지를 분산 형태로 제공하는 전용 클러스터입니다.

• Ceph, Lustre, GlusterFS 등이 대표적
• HPC의 /data 영역이 이런 스토리지 클러스터 위에서 동작하는 경우가 많습니다.

※ Ceph는 확장성과 범용성이 좋지만, Lustre는 HPC용으로 더 빠릅니다.

• Aurora/Ariel 같은 환경은 Lustre 또는 NFS 계열 스토리지를 사용하는 경우가 많습니다.

스토리지 클러스터는 계산이 아니라 데이터 저장과 I/O 처리에 최적화된 독립적인 분산 파일 시스템이다. HPC에서 사용하는 /data, /scratch가 대부분 이러한 시스템 위에서 돌아간다. Lustre는 초고성능 POSIX 파일시스템을 제공해 HPC에 적합하고, Ceph는 객체·블록·파일을 모두 제공해 범용성과 확장성이 뛰어나다. 스토리지 클러스터를 따로 두는 이유는 단순 저장 때문이 아니라, 노드가 수십~수백 대 이상인 클러스터에서 파일 일관성, 확장성, 결함 허용성(fault tolerance)을 확보하기 위함이다. 또한 GPU 학습에서도 대규모 이미지/비디오 셔플 시 I/O 병목이 전체 학습 속도를 결정하므로 스토리지 클러스터 설계가 AI 학습 성능과 직결된다.

Kubernetes Cluster (Cloud Native Cluster)

쿠버네티스 클러스터

컨테이너 기반 AI·웹서비스·배포 자동화를 위한 클러스터입니다.

• GPU Operator를 설치하면 딥러닝 학습에도 활용 가능
• 최근 많은 AI팀이 HPC 대신 K8s 기반으로 전환 중

Kubernetes 클러스터는 전통적 HPC와 달리 컨테이너 기반의 유연성과 자동화를 중심으로 한다. GPU Operator·NVIDIA Device Plugin 등을 설치하면 딥러닝 학습 노드로도 활용할 수 있고, Inference 서비스·웹서비스·데이터 파이프라인 등 개발부터 운영까지 하나의 플랫폼에서 통합 관리할 수 있다. 또한 Auto-scaling, Canary rollout, 서비스 메쉬, 모니터링 등 배포 자동화 기능이 강력해 “AI 연구 + AI 운영(Serving)”을 같이 하는 팀이 빠르게 도입하고 있다. 다만 노드 간 HPC 수준의 통신 최적화를 보장하지 않기 때문에 대규모 분산 학습에는 한계가 있으며, 대신 MLOps/DevOps 환경에 매우 적합하다.

Hybrid Cluster

핏한 이미지가 없어서 GPT로 만들었어용

HPC + Cloud + K8s + Storage를 결합한 복합 구조입니다.

• 연구 기관에서 GPU 자원을 내부 HPC로 관리하고
• 생산 서비스는 Kubernetes에서 운영하는 형태가 대표적

Running Cloud-native Workloads on HPC with High-Performance Kubernetes 하이브리드 클러스터는 HPC·Kubernetes·Cloud·Storage를 결합한 형태로, 많은 연구기관·기업들이 실제로 운영하는 구조다. 예를 들어 GPU 연구는 온프레미스 HPC에서 진행하되, 프로토타입 웹서비스는 K8s에서 운영하고, 대규모 데이터는 클라우드 스토리지와 연결하는 방식이다. 이렇게 하면 연구 단계–개발 단계–운영 단계 간 리소스를 단일화할 수 있어 파이프라인 전환 비용이 크게 줄어든다. 또한 클라우드의 탄력성과 내부 HPC의 비용효율을 동시에 얻을 수 있다. 단점은 네트워크·보안·IAM 구조 설계가 복잡해지고, 팀 간 운영 책임 분리가 필요한 점이다. 성숙한 조직일수록 하이브리드 구조로 진화하는 경향이 있다.

Aurora와 Ariel

Aurora와 Ariel은 모두 학교에서 제공하는 고성능 연산(HPC) 서버이지만, 용도와 구성 측면에서 차이가 있습니다. Aurora는 주로 교육·연구 실습을 위한 학부 중심의 HPC 환경으로, 로그인 노드에서 SSH 접속 후 Slurm을 통해 GPU 노드(aurora-g1, g2, g3 등)를 예약해 사용하는 구조입니다. 사용자가 직접 /data/{your_id} 경로에 코드를 올리고, GPU 노드에 접속하여 가상환경을 구성한 뒤 배치 작업을 수행하는 방식이 대표적입니다. Ariel은 Aurora와 별도로 운영되는 연구 중심 HPC 환경으로, GPU 세대나 큐 정책, 스토리지 구성 등이 Aurora와 다를 수 있습니다. 각 시스템의 실제 구성은 df -h, sinfo, nvidia-smi 명령으로 확인하는 것이 가장 정확합니다. 보통 계산 성능·저장구조·큐 정책 등이 Aurora와 다를 수 있습니다. 예를 들어 Ariel은 다른 GPU 세대(예: A100, L40S 등)를 포함하거나, /scratch·/local_datasets 같은 고속 임시 스토리지가 제공될 가능성이 있습니다. 또한 사용자 그룹, 사용 정책, 실험 목적(수업·프로젝트·연구)에 따라 큐 설정과 접근 권한이 Aurora와 다르게 관리될 수 있습니다. 요약하면 Aurora는 교육·실습 중심의 표준 HPC 환경, Ariel은 보다 고성능 또는 연구 운영 중심의 확장 HPC 환경으로 이해할 수 있으며, 실제 스펙과 경로 구조는 SSH 접속 후 df -h, sinfo, nvidia-smi 등을 통해 확인하는 것이 가장 정확합니다.

여기서부터 다시 보세요

아 이제 진짜 딴소리 안하고 돌아와서...

Aurora와 Ariel은 모두 학교에서 제공하는 고성능 연산 서버(HPC 클러스터)지만, 제공 대상 학과와 운영 목적이 구분되어 있습니다. Aurora는 컴퓨터공학과·소프트웨어융합학과 등 공학 계열 학생들에게 주로 제공되는 범용 GPU 연산 클러스터로, 다양한 분야의 실습·과제·연구를 위한 공용 서버 역할을 합니다. 반면 Ariel은 인공지능학과를 중심으로 제공되는 전용 클러스터로, 딥러닝·머신러닝 실험에 최적화된 GPU 자원이 집중된 환경이라는 점이 가장 큰 차이입니다. 실제로 공학 계열은 Aurora 접근 권한을 배정받는 경우가 많고, 인공지능학과는 Ariel 계정을 별도로 지급받는 것으로 알려져 있습니다. 두 시스템 모두 SSH·SFTP를 기반으로 사용 방식은 유사하지만, Aurora는 다양한 과목과 연구 주제를 수용하는 범용 교육용 클러스터, Ariel은 AI 실험·모델 학습을 위한 전용 연산 서버라는 차이가 있으며, 노드 구성·GPU 종류·사용 정책 역시 학과별 요구에 맞추어 다르게 운영되는 편입니다.

결론

깃허브 디렉토리 짤 때는 /data, /code, /logs 등 역할별 폴더를 명확히 구분해야 합니다. 이 구조를 그대로 HPC의 /data/{your_id} 하위에 반영하면, 학습 코드·데이터 관리가 깔끔해지고 Slurm job 실행 시 경로 충돌을 방지할 수 있습니다.

국립국어원의 인공지능 말평(Korean Language Intelligence Benchmark)은 한국어 인공지능 기술의 성능을 객관적으로 평가하기 위해 마련된 국가 공인 벤치마크입니다. 형태소 분석, 품사 태깅, 개체명 인식, 문장 관계 추론, 감정 분석, 질의응답, 문서 요약 등 언어 이해·생성 전반을 포괄하는 20여 개의 과제로 구성되어 있으며, 모든 과제는 국립국어원 세종 말뭉치와 인공지능 학습용 말뭉치를 비롯해 AI Hub·공공기관 협력 데이터 등 다양한 출처의 한국어 자료를 기반으로 구축되었습니다. 참가자는 모델의 결과를 시스템에 제출하여 정확도, F1-score, BLEU, ROUGE 등의 지표로 평가받으며, 이를 통해 학계·산업계의 한국어 AI 모델을 공정하게 비교할 수 있다. 인공지능 말평은 한국어 처리 기술의 품질 향상과 표준화된 연구 생태계 조성을 목표로 하는 대표적인 공공 AI 평가 프로젝트입니다.

다들 AI 허브는 많이 아는데 여기는 몰라서 좀 속상했는데 데이터가 많이 겹침 ㅋㅋ... 암튼 그래도 우리 멋진 쿠다 NLP 8기는 개빡세게 6주동안 스터디하고, 3주, 3주 과제를 하게 되었습니다.

첫 과제는 일단 '한국어' 특화 LLM 프로젝트를 해보자! 라는 의견에서 시작했고, 팀원마다 지식과 경험의 벡터값이 다 제각각이라 서로를 파악하면서 공부하고자 준비한 태스크이고 세 팀으로 구성해서 프로젝트를 하고 3주간 진행과정을 발표하면서 서로 질문하고 제안하면서 공부하는 시간을 갖는 것이다.

우선 LLM이 아무리 작아졌대도 우리의 노트북으로 학습시키거나 할 순 없기에 교내 소프트웨어 관련 학생들이 사용할 수 있는 세라프 사용법을 공유했고 사용 불가능한 경우 Colab Pro를 결제하였다.

처음 공부하는 입장에서 세라프 사용은 어렵기 때문에 기록해보겠다.

** 1. 한국어 일상 대화 연결 2. 그림(사진) 기반 문장 생성 3. 국회 회의록 요약 **

세개 과제이고 나는 3번 국회 회의록 요약에 참여한다.

과제는 요약하자면

‘국회 회의록 요약’ 과제는 국립국어원의 2021·2022년 회의록 요약 말뭉치 연구 결과를 기반으로, 국회 회의록의 방대한 대화 내용을 자동으로 요약하는 인공지능 모델을 개발하는 것을 목표로 합니다. 참가자는 회의록 내 안건별 발언 데이터를 분석하여 주요 논의 내용, 결정 사항, 의견 차이를 간결하고 정보 가치 있게 요약해야 합니다. 입력 데이터는 발언자, 직책, 대화 내용, 안건 정보가 포함된 JSON 형식으로 제공되며, 출력은 모델이 생성한 요약문입니다. 성능 평가는 ROUGE-1 점수를 사용하여 생성된 요약문이 참조 요약문의 핵심어를 얼마나 잘 재현하는지를 측정합니다. 기준 모델은 GitHub(teddysum/Korean_NAMS_2024)에 공개되어 있으며, 외부 데이터를 학습에 활용할 수 있으나 ChatGPT 등 외부 API를 추론에 직접 사용하는 것은 금지됩니다.

로그인하고 자료 받기하고, 개인정보 사용 동의 서약을 쓰면 데이터를 다운로드할 수 있다. 데이터 다운로드를 하기위해서 앱 설치하고 데이터도 받을 수 있습니다.

전체 실험 기획

1. Baseline → 전처리 → 언어전환 → 모델비교 순으로 실험을 설계해 단계별 개선 효과를 계량적으로 볼 수 있게 한다.
2. 외부 API 추론 금지 규칙을 지키면서도 공개 모델 fine-tuning을 통해 연구 확장성을 확보한다.
3. Aurora 환경에 맞춘 경량 모델(bart-base, kobart)로 자원 효율적인 실험을 진행한다.

1) 데이터 준비

• 입력 형식:

  {
    "speaker": "홍길동",
    "position": "위원장",
    "agenda": "법안심사",
    "utterance": "본 안건에 대해 말씀드리겠습니다..."
  }

• 출력: summary 필드에 참조 요약문

• 처리 대상: 발언 단위(utterance) 또는 안건 단위(agenda)로 병합 가능

• 파일 구조:

  data/
  ├─ raw.json
  ├─ preprocess/
  │   ├─ split_train.jsonl
  │   ├─ split_val.jsonl
  │   └─ split_test.jsonl

2) 환경 세팅

너무 길어져서 다음 글로 패쓰 다음글 1(Aurora 너 누군데) [다음글 2(말평 진행사항(1))]

3) 실험 구성

EXP A — Baseline / 전처리 최소화

• 입력: 원본 회의록 텍스트 (utterance or agenda 단위)
• 모델: facebook/bart-large-cnn (또는 kobart)
• 목적: 전처리 없이 baseline 성능 확인
• 출력: outputs/exp_A/
• 지표: ROUGE-1, GPU 메모리, 학습 시간

EXP B — 전처리 + 번역 + 영어모델

• 입력: 한국어 → 영어 번역 (Marian MT opus-mt-ko-en)
• 모델: facebook/bart-large-cnn
• 목적: 번역 중간단계를 거친 경우 성능 및 자원 사용량 비교
• 출력: outputs/exp_B/

EXP C — 전처리 + 한국어모델

• 입력: 전처리된 한국어 데이터
• 모델: hyunwoongko/kobart (국문용)
• 목적: 한국어 전용 사전학습 모델과 비교
• 출력: outputs/exp_C/

4) 데이터 전처리

생각해보면 이거 데이터가 발화 데이터라 요약에 필요없는 데이터가 많았습니다.

데이터 전처리 논의에서는 국회 회의록 요약 모델의 입력 품질을 극대화하기 위한 통합 파이프라인 설계에 초점을 맞추었습니다. 핵심 목표는 하나의 회의록 안에 포함된 여러 안건을 명확히 분리하고, 각 안건과 직접적으로 관련된 발화만을 선별하여 모델 입력을 정제하는 것입니다. 이를 위해 sentence_id를 안건 시작점으로, “~되었음을 선포합니다” 등의 종결 패턴을 종료점으로 활용하는 분리 규칙이 제안되었으며, 예외적인 경우에는 LLM을 활용해 “특정 keyword 관련 내용만 요약”하도록 후처리를 적용하는 방안이 논의되었습니다. 불필요한 짧은 문장이나 머뭇거림 발화는 제거하고, 숫자나 법안명 등 핵심 정보가 포함된 문장은 유지하는 세부 기준이 설정되었습니다.

전체 전처리 플로우는 4단계 파이프라인 구조로 설계되었습니다. (1) 화자명 앞에 [직책/역할] prefix를 부여하여 발화 구조를 명확히 하고, (2) 의례적·불용 문장을 정규식으로 제거하거나 결정문을 DECISION 태그로 표시하며, (3) 안건명과 핵심 키워드를 KEY 태그로 강조하고, (4) TF-IDF 기반으로 중요도가 높은 문장을 IMP 태그로 감싸 가중치를 부여합니다. 특히 TF-IDF는 회의 전체 단위보다 안건별 계산 단위로 수행하는 것이 타당하다는 결론이 도출되었습니다. 향후 실험 단계에서는 전처리된 데이터를 기반으로 GemmaX2-28-2B-v0.1 등 경량 LLM을 적용해 요약 성능을 검증할 예정입니다.

참고 링크

• 회의록 요약 과제 기술서: 국립국어원 말평 (NIKL)
• 기준 모델(GitHub): Korean_NAMS_2024
• 전처리 참고 모델: ModelSpace/GemmaX2-28-2B-v0.1 (Hugging Face)

5) 학습 단계

• 실행 예시:

  python src/finetune_summarizer.py \
      --model_name facebook/bart-large-cnn \
      --data_dir data/preprocess \
      --output_dir outputs/exp_A \
      --epochs 3

• 주요 설정

  항목	값
  max_input_length	1024
  max_target_length	128
  batch_size	1~2
  fp16	True
  evaluation_strategy	epoch

6) 평가 및 로그

• src/evaluate.py로 ROUGE-1 계산

• GPU/CPU 메모리 모니터링(src/monitor.py)

• 결과 정리:

  실험	모델	ROUGE-1 (F1)	GPU Max (GB)	CPU (GB)	시간
  A	-	-	-	-	-
  B	-	-	-	-	-
  C	-	-	-	-	-

7) 후속 실험

이건 일단 제 계획입니다.

이제 약간 알려주기도 귀찮아서 정리함.

일단 서버라는 개념은 대충 알고 있을 것임 https://brunch.co.kr/@imagineerjy/18 진짜 모르면 진짜 여기 추천

암튼 서버에 왜 연결해야하고 그게 좋다는데 어케 쓰지,, 하는 사람들을 위해 간단히 정리해보겠습니다.

SSH와 SFTP

일단 SSH란?

원격 서버 접속이라는 것은 다른 컴퓨터에 있는 저장장치나 컴퓨팅 리소스에 네트워크를 통해 접속한다는 뜻

SSH는 Secure Shell의 약자로, 원격 서버에 암호화된 네트워크 연결을 통해 안전하게 접속하는 프로토콜입니다. SSH를 통해 원격 서버의 셸에 직접 접속하여 명령어를 실행하고, 서버를 제어할 수 있습니다.

안전한 원격 접속의 개념 서버에 SSH로 접속하면, 마치 내 컴퓨터에서 직접 작업하는 것처럼 서버의 자원을 활용할 수 있습니다. 모든 통신은 암호화되어 있어 보안 위협으로부터 데이터를 보호합니다. 실제 개발 환경에서는 SSH로 서버에 접속하여 작업하고, SFTP로 파일을 주고받는 패턴을 사용합니다.

Public Key & Private Key

원래 굳이 설명 안하려고 했는데 쓰다보면 key랑 password랑 헷갈려하시길래 SSH는 비대칭 키 암호화(Asymmetric Encryption) 방식을 사용하여 인증합니다.

Public Key로 암호화된 데이터는 오직 대응하는 Private Key로만 복호화할 수 있습니다. 이 수학적 특성을 이용해 클라이언트의 신원을 안전하게 검증합니다.

SFTP (Secure File Transfer Protocol) SFTP는 SSH 프로토콜 위에서 동작하는 파일 전송 프로토콜입니다. SSH의 암호화 메커니즘을 그대로 사용하기 때문에 데이터 전송이 안전하게 보호됩니다. SFTP는 단순히 "보안이 강화된 FTP"가 아니라, SSH 프로토콜 자체를 활용한 완전히 다른 구조입니다.

프로토콜이 뭔 소린지 모르겠나요? 프로토콜은 컴퓨터나 기기 간의 데이터 교환 규칙 체계입니다. 이는 통신 시 지켜야 할 통신 규약으로, 데이터의 형식, 송수신 방법, 오류 처리 등을 정의하여 원활한 소통을 가능하게 합니다. 웹 브라우저와 웹 서버가 통신할 때 사용하는 HTTP, 이메일을 주고받을 때 사용하는 SMTP 등이 대표적인 예시랍니다.

SFTP vs FTP

이거까지만 하고 어케 쓰는지 알려줄게요 ㅠㅠ

개발 플로우

** SSH 접속 및 실행** SSH로 서버에 접속하여 업로드된 코드를 실행하고 테스트합니다. ** 결과 확인 및 배포** 실행 결과를 확인하고, 필요에 따라 다시 로컬에서 수정 후 동기화 과정을 반복합니다.

단계별 설명

① 로컬 작업
로컬에서 코드를 완성하고, SFTP Config를 설정합니다.

② 파일 동기화 (SFTP)
코드를 서버로 안전하게 전송합니다.
💡 uploadOnSave: true로 자동 동기화 활용 (하단에 있음)

③ 서버 제어 (SSH)
SSH로 접속 후, GPU 노드 할당 명령(예: srun)을 실행합니다 .

④ 학습 실행 및 모니터링
데이터셋을 준비하고, 학습 스크립트(sbatch 등)를 실행하고, 학습을 진행합니다. SSH 셸에서 로그를 확인하며 모니터링합니다.

⑤ 결과 다운로드 (SFTP)
학습이 완료되면 결과 파일(모델 가중치, 최종 로그 등)을 SFTP로 다시 로컬로 다운로드합니다.

FTP vs SFTP

FTP (File Transfer Protocol)

FTP는 파일 전송 전용 프로토콜이지만 암호화를 지원하지 않습니다. 전송되는 모든 데이터가 평문(plain text)으로 네트워크를 통해 전달되기 때문에 보안에 취약합니다.

SFTP (Secure File Transfer Protocol)

SFTP는 SSH 프로토콜 위에서 동작하는 파일 전송 프로토콜입니다. SSH의 강력한 암호화 메커니즘을 그대로 사용하기 때문에 데이터 전송이 안전하게 보호됩니다.

SFTP는 단순한 "보안 강화 FTP"가 아니라, SSH 터널링을 이용한 안전한 파일 전송 방식입니다. 개발 환경에서 코드를 서버에 올리거나 학습 결과물을 다운로드할 때 주로 사용됩니다.

SFTP를 통한 파일 전송

VSCode SFTP 설정

VSCode에서 SFTP 확장을 사용하면 로컬과 서버 간 파일 동기화를 쉽게 할 수 있습니다.

sftp.json 설정 예시:

{
  "name": "Aurora",
  "host": "163.180.160.105",
  "protocol": "sftp",
  "port": 30080,
  "username": "your_id",
  "remotePath": "/data/your_id/repos/Assignment",
  "uploadOnSave": true,
  "useTempFile": false,
  "openSsh": false
}

터미널에서 SFTP 직접 사용

# SFTP 접속
sftp -P 30080 your_id@163.180.160.105

# 서버 디렉토리 이동
sftp> cd /data/your_id/repos

# 서버 → 로컬 다운로드
sftp> get remote_file.py
sftp> get -r remote_directory

# 로컬 → 서버 업로드
sftp> put local_file.py
sftp> put -r local_directory

# 종료
sftp> exit

이마저도 귀찮다면 일단 https://github.com/YuujInJeong/khuseraphdashboard

* 자동 동기화 활용

VSCode의 uploadOnSave: true 옵션을 활성화하면

* 포트 선택 가이드

*** 주요 명령어 **

🔧 연구용 기술 스택

• GUI: PyQt5 (크로스 플랫폼, 연구용 위젯 풍부)
• 하드웨어 통신: pySerial (Arduino/Teensy와 시리얼 통신)
• AI: PyTorch + CNN (MNIST 분류, 확장 가능)
• 시각화: PyQtGraph (실시간 플롯, 빠른 렌더링)
• 빌드: PyInstaller + .spec 파일
• 데이터: NumPy + 자체 CSV # 연구용 16x16 어레이 제어 시스템

🚀 프로젝트 시작계기

최근에 신소재 연구실에서 잠깐 작업할 일이 생겼다. 16x16 광학 센서 어레이를 이용한 실험 시스템을 만드는 건데, 연구진이 매번 Python 코드를 직접 실행하면서 실험하기엔 너무 번거로워 보였다.

평소에 연구실용 도구를 만드는 걸 좋아해서** 제대로 된 GUI 프로그램을 만들어보자고 마음먹었다.** 연구자들이 복잡한 코드 신경 안 쓰고 그냥 버튼 클릭으로 실험할 수 있게 하는 게 목표였다.

근데 문제가 있더라. 연구실 컴퓨터마다 Python 환경이 다르고, 매번 패키지 설치하고 경로 설정하고... 다른 연구실에서 협업할 때도 설명서를 따로 써줘야 하는 것도 많고, 새로운 학생이 들어와서 실험하려면 또 환경 세팅을 해야 했다.

그냥 연구진들이 쉽게 쓸 수 있는 실행 파일을 만들어보자 싶어서 시작했다.

💡 연구용 시스템 요구사항

요구사항은 연구실 상황에 맞춰 정했다.

Python 설치 없이도 쓸 수 있고, 복잡한 환경 설정 안 해도 되고, 16x16 어레이에서 실시간으로 데이터를 수집하면서 AI 분류 결과를 볼 수 있으면 됐다. 주피터 노트북처럼 매번 코드를 수정하고 실행하고 싶지는 않았다.

연구실 특성상 필요한 기능들

• 16x16 광학 센서 어레이와 시리얼 통신
• 실시간 데이터 수집 및 시각화
• AI 기반 MNIST 숫자 분류
• 실험 파라미터 실시간 조정
• 데이터 저장 및 성능 분석
• 하드웨어 없이도 테스트 가능한 시뮬레이션 모드

아이디어 자체는 복잡하지 않았지만 실제 연구에 쓸 수 있을 만큼 안정적으로 만드는 게 중요했다. 실험 중에 프로그램이 죽으면 데이터를 다 잃어버릴 수도 있거든요... (유진님 이거 죽었서요..🤔)

PyQt5로 슥슥 만들었다.

기술적 고민들

문제는 구체적인 기술 요소들을 정하는 거였다. GUI 프레임워크 뭐 쓸지, 모델 저장 형식은 어떻게 할지, 실행 파일 빌드는 어떻게 할지... 이런 것들 고민하는데 시간이 오래 걸렸다.

특히 PyInstaller vs cx_Freeze vs Nuitka 선택에서 고민이 많았다. 각각 장단점이 다른데

• PyInstaller: 가장 유명하고 안정적. 하지만 파일 크기가 큰 편
• cx_Freeze: 크로스 플랫폼 지원 좋음. 설정이 복잡함
• Nuitka: 성능 최고. 하지만 복잡한 의존성에서 문제 생기기 쉬움

결국 PyInstaller로 결정했다. 문서도 많고 PyTorch 같은 라이브러리와 호환성도 검증되어 있어서.

특히 하드웨어 통신 부분이 까다로웠다. Arduino/Teensy와 시리얼 통신으로 16x16 어레이를 제어해야 하는데, 연결이 끊어지거나 데이터 전송 오류가 생기면 실험 전체가 망가질 수 있다.

# 시리얼 통신 안정성을 위한 처리
class SerialManager:
    def __init__(self):
        self.connection = None
        self.reconnect_attempts = 0

    def safe_write(self, data):
        try:
            if self.connection and self.connection.is_open:
                self.connection.write(data)
                return True
        except serial.SerialException:
            self.attempt_reconnect()
        return False

모델 파일 경로 처리도 연구실 환경에 맞춰 신경써야 했다. 개발할 때는 상대 경로로 models/mnist_cnn_model.pth 이렇게 썼는데, 실행 파일로 만들면 경로가 달라진다. 특히 연구실 컴퓨터들이 OS가 다 달라서...

import sys
import os

def get_resource_path(relative_path):
    if hasattr(sys, '_MEIPASS'):
        return os.path.join(sys._MEIPASS, relative_path)
    return os.path.join(os.path.dirname(__file__), relative_path)

이런 식으로 경로 처리 함수를 만들어서 해결했다.

🚧 연구용 시스템 개발 과정

완성하고 나서 연구실에서 실제로 테스트해보니까 생각보다 문제가 많았다.

개발 환경에서는 잘 돌아가던 게 실제 실험 장비와 연결하면 여러 오류가 터져나왔다. 특히 PyTorch의 CUDA 설정이 꼬이면서 GPU 가속이 안되고, 시리얼 포트 권한 문제로 하드웨어 통신이 안 되는 경우가 발생했다.

연구실 특성상 생기는 문제들도 있었다.

• 장비별 시리얼 포트 설정: 각 실험 장비마다 포트 번호가 다름
• 데이터 수집 속도: 실시간 처리를 위해 최적화 필요
• 장시간 실험 안정성: 몇 시간씩 돌려도 메모리 누수 없어야 함
• 다중 사용자 환경: 여러 연구자가 동시에 사용 가능해야 함

급하게 .spec 파일을 수정해가면서 연구실 환경에 맞는 설정을 추가했다.

# ArrayControlSystem.spec - 연구실 환경 최적화
a = Analysis(['array_control_system.py'],
            pathex=['.'],
            binaries=[],
            datas=[('models', 'models'), 
                   ('mnist_cnn_model.py', '.'),
                   ('configs', 'configs')],  # 실험 설정 파일들 포함
            hiddenimports=['torch', 'torchvision', 'PyQt5', 
                          'serial', 'pyqtgraph', 'numpy'],
            hookspath=[],
            runtime_hooks=[],
            excludes=['tkinter'],  # 불필요한 GUI 라이브러리 제외
            win_no_prefer_redirects=False,
            win_private_assemblies=False,
            cipher=block_cipher)

연구실에서 중요한 건 재현 가능성이었다. 같은 실험을 다른 날, 다른 컴퓨터에서 해도 동일한 결과가 나와야 한다. 그래서 실험 파라미터들을 모두 설정 파일로 저장하고, 실행 파일에 포함시켰다.

🎨 연구용 UI/UX 설계

사용자 인터페이스는... 솔직히 말하면 처음에는 기능만 돌아가게 만드는 데 집중했다. 연구자들이 쓸 거니까 예쁠 필요는 없다고 생각했는데, 막상 써보니까 가독성이 떨어져서 실험하기 불편할 것 같았다. 그래서 뭐 사용성 높은 걸 가능한 위로 아닌 것을 아래로 내렸다.

연구실 환경에 맞는 UI 요구사항들:

• 16x16 히트맵 시각화: 센서 어레이 상태를 한눈에 파악
• 실시간 성능 지표: 분류 정확도, 응답 시간 등 모니터링
• 실험 로그 시스템: 모든 실험 과정 자동 기록
• 파라미터 조정 패널: 전압, 샘플 수 등 실시간 변경
• 시뮬레이션 모드: 하드웨어 없이도 알고리즘 테스트

/* 연구용 대시보드 스타일 */
QMainWindow {
    background: qlineargradient(x1:0, y1:0, x2:0, y2:1,
                stop:0 #1e3c72, stop:1 #2a5298);
}

QGroupBox {
    font-weight: bold;
    border: 2px solid #3498db;
    border-radius: 8px;
    margin: 5px;
    padding-top: 10px;
    background-color: rgba(255, 255, 255, 0.1);
}

/* 실험 상태에 따른 색상 변화 */
QPushButton[status="connected"] {
    background-color: #27ae60;
}
QPushButton[status="disconnected"] {
    background-color: #e74c3c;
}

연구실에서 중요한 건 정보의 밀도였다. 한 화면에 최대한 많은 정보를 담으면서도 가독성을 유지해야 했다. 16x16 히트맵, 성능 지표 테이블, 로그 창을 모두 실시간으로 업데이트하면서도 UI가 느려지면 안디는데...

🛠️ 연구실 환경 배포

PyInstaller로 실행 파일 만들고, 내 드라이브에 dmg와 exe를 배포했다.

# 연구실별 빌드 스크립트
# macOS (주로 분석용)
pyinstaller --onefile --windowed ArrayControlSystem.spec

# Windows (실험 장비 제어용)  
pyinstaller --onefile --windowed ArrayControlSystem.spec

# Linux (서버 환경)
docker run --rm -v $(pwd):/app python:3.9 bash -c "cd /app && pip install -r requirements.txt && pyinstaller ArrayControlSystem.spec"

연구실 특성상 여러 OS가 섞여 있다. 실험 장비는 Windows, 분석은 macOS, 서버는 Linux... 각각 빌드해서 배포해야 했다. 버전 관리는 파일명에 날짜를 넣어ArrayControlSystem_v1.2_20241215.exe 이런 식으로 했다.

📊 연구용 성능 최적화

파일 크기가 생각보다 컸다. macOS 기준으로 1.9GB나 나왔다.

연구실에서는 파일 크기보다는 안정성이 더 중요했다. 실험 중에 프로그램이 죽으면 몇 시간 분량의 데이터를 잃을 수 있거든. 그래서 파일 크기는 좀 크더라도 모든 의존성을 포함시키기로 했다.

주원인은 PyTorch였다. 연구용이라 GPU 가속이 필요할 수도 있어서 CUDA 버전을 포함시켰는데, 이게 용량을 많이 차지했다.

연구실 환경에 맞춘 최적화:

# 연구용 최적화 설정
# GPU 가속 필요한 경우
pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118

# CPU만 쓰는 경우  
pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu

# 연구용 필수 모듈만 포함
pyinstaller --exclude-module=matplotlib --exclude-module=scipy ArrayControlSystem.spec

실행 속도는 연구 환경에서 치명적이다. 실시간 데이터 수집하면서 AI 분류까지 해야 하는데, 처리가 느리면 데이터 손실이 생길 수 있다.

멀티스레딩으로 해결했다:

• 메인 스레드: GUI 업데이트 (60fps)
• DAQ 스레드: 센서 데이터 수집 (100Hz)
• AI 스레드: 분류 작업 (실시간)
• 로그 스레드: 데이터 저장 (백그라운드)

프론트엔드는 PyQt5로 구성했다. tkinter도 고려했는데 UI가 너무 단조롭고, Kivy는 모바일 중심이라 데스크톱용으로는 PyQt5가 최적이었다.

AI 모델은 간단한 CNN으로 만들었다. 차후 연구에 맞춰서 바꿔나갈 예정이다ㅏ.

🎉 결과와 배운 점

AI를 개발에 활용하는 방법을 좀 더 구체적으로 알게 됐다. 코드 전체를 짜달라고 하는 것보다는 내가 고민하고 있는 기술적 선택지들에 대해 조언을 구하거나, UI 디자인 같은 내가 약한 부분을 보완하는 용도로 쓰는 게 효과적이었다.

그리고 요즘 나온 빌드 도구들이 정 말 좋아졌다는 걸 실감했다. 예전에는 실행 파일 하나 만들려면 복잡한 설정 파일 작성하고 이것저것 해야 했는데, 지금은 몇 줄 명령어면 끝이다.

개발 환경과 실제 사용 환경의 차이도 다시 한번 느꼈다. 혼자 테스트할 때는 문제없던 게 다른 컴퓨터에서는 여러 문제가 생기더라. 특히 라이브러리 의존성이 복잡한 경우 패키징을 더 꼼꼼하게 해야겠다는 생각이 들었다.

처음에 기술 스택 고민하는데 시간을 너무 많이 썼다. tkinter가 익숙해서 만들었는데 너무 단조로웠다. 그냥 빨리 만들어보고 바꾸길 잘했다. 완벽한 설계보다는 일단 돌아가는 걸 만드는 게 중요하다는 걸 또 한 번 느꼈다.

결과적으로는 만족스럽다. 내가 원하던 기능은 다 구현했고, 배포도 잘 됐고, 실제로 다른 사람들도 쓰고 있다. AI 모델을 실제 프로그램으로 만들어서 배포까지 해볼 수 있는 좋은 경험이었다.

📁 프로젝트 파일들

핵심 파일

• array_control_system.py - 메인 GUI 애플리케이션
• mnist_cnn_model.py - CNN 모델 정의
• models/mnist_cnn_model.pth - 훈련된 모델 가중치
• ArrayControlSystem.spec - PyInstaller 빌드 설정

빌드 스크립트

• build_all_platforms.yml - GitHub Actions CI/CD
• requirements.txt - Python 패키지 의존성
• README.md - 사용법 및 설치 가이드

앞으로는 더 복잡한 AI 모델도 실행 파일로 만들어보고 싶다. 그리고 웹 버전도 만들어서 브라우저에서 바로 쓸 수 있게 해보는 것도 재밌을 것 같다! 🎯

Cython은 Python 코드를 C로 컴파일하여 네이티브 속도로 실행할 수 있게 해주는 라이브러리다. 실제로 몬테카를로 시뮬레이션 코드를 Cython으로 변환했을 때 약 85배까지도 개선된다. 특히 중첩된 반복문이 많은 알고리즘에서는 더욱 극적인 개선을 보여준다.

Cython이 고성능을 달성하는 핵심은 Python의 동적 타이핑 오버헤드를 제거하는 것이다. cdef int i, j와 같은 정적 타입 선언을 통해 변수 타입 체크를 컴파일 타임에 수행하고, C 컴파일러의 최적화를 활용한다. 메모리 뷰(memoryview)를 사용하면 NumPy 배열 접근 시 Python 래퍼를 우회하여 직접 메모리에 접근할 수 있다. 이는 특히 픽셀 단위 이미지 처리나 대규모 행렬 연산에서 체감할 수 있는 성능 향상을 가져다준다.

NetworkX: 그래프 이론의 강력한 도구

NetworkX는 복잡한 네트워크의 구조, 동역학, 기능을 연구하기 위한 Python 패키지다. 소셜 네트워크 분석 프로젝트에서 10만 개 노드를 가진 그래프의 중심성 계산을 수행했을 때, NetworkX의 최적화된 알고리즘 구현이 순수 Python 구현보다 약 40배 빠른 성능을 보여주었다.

NetworkX의 성능 우위는 효율적인 그래프 자료구조 설계에서 나온다. 내부적으로 인접 리스트를 딕셔너리의 딕셔너리로 구현하여 O(1) 시간에 노드와 엣지에 접근할 수 있다. 또한 많은 알고리즘들이 C로 구현된 하위 레벨 함수들을 활용한다. 예를 들어, 최단 경로 계산에서는 Dijkstra 알고리즘의 핵심 부분을 C로 구현하여 힙 연산의 오버헤드를 최소화했다.

python-louvain: 커뮤니티 탐지의 최적화된 구현

Louvain 알고리즘은 네트워크에서 커뮤니티 구조를 찾는 휴리스틱 방법이다. python-louvain의 성능은 모듈성 최적화 과정의 지능적인 구현에서 나온다. 알고리즘은 각 노드를 인접한 커뮤니티로 이동시키면서 모듈성 증가를 계산하는데, 이 과정에서 증분 계산(incremental computation)을 사용한다. 전체 모듈성을 다시 계산하는 대신 변화분만을 계산하여 O(n²)에서 O(n log n)으로 시간 복잡도를 줄였다. 또한 커뮤니티가 안정화되면 해당 부분의 계산을 건너뛰는 조기 종료 최적화를 적용한다.

python-tsp: 외판원 문제의 효율적 해결

TSP(Traveling Salesman Problem)는 조합 최적화의 대표적인 NP-hard 문제다. 물류 최적화 프로젝트에서 100개 도시를 가진 TSP 문제를 해결했을 때, python-tsp의 Christofides 알고리즘이 순수 브루트 포스 방법보다 수천 배 빠른 성능을 보여주었다.

python-tsp의 성능은 정교한 휴리스틱 알고리즘과 가지치기 기법의 조합에서 나온다. Held-Karp 하한을 사용한 분기한정법에서는 부분 해의 하한이 현재 최적해보다 크면 해당 분기를 즉시 제거한다. 또한 2-opt, 3-opt 같은 지역 검색 최적화를 통해 초기 해를 개선하고, 이를 분기한정법의 초기 상한으로 사용하여 가지치기 효과를 극대화한다.

PyArrow: 컬럼형 데이터 처리의 혁명

PyArrow는 Apache Arrow 프로젝트의 Python 구현체로, 컬럼형 인메모리 분석을 위한 플랫폼이다. 실제로 1억 행 규모의 CSV 파일을 처리했을 때, PyArrow의 parquet 읽기가 pandas의 CSV 읽기보다 약 15배 빠른 성능을 보여주었다. 특히 필터링 작업에서는 컬럼형 구조의 장점이 극명하게 드러난다.

PyArrow의 성능 우위는 메모리 레이아웃 최적화에서 나온다. 컬럼형 저장 방식은 동일한 타입의 데이터를 연속적으로 배치하여 CPU 캐시의 지역성을 극대화한다. 또한 SIMD(Single Instruction, Multiple Data) 명령어를 활용하여 벡터화된 연산을 수행한다. 예를 들어, 정수 배열의 합계를 계산할 때 한 번에 8개의 값을 처리할 수 있다. 또한 컬럼 프루닝(column pruning)과 술부 푸시다운(predicate pushdown) 최적화를 통해 불필요한 데이터 읽기를 방지한다.

NumExpr: 수치 표현식 계산의 가속화

NumExpr는 NumPy 배열에 대한 수치 표현식을 빠르게 계산하는 라이브러리다. 실제로 a * b + c * d와 같은 복잡한 배열 연산을 수행했을 때, NumExpr이 순수 NumPy보다 약 3-4배 빠른 성능을 보여주었다. 특히 메모리 사용량이 많은 대규모 배열에서는 더욱 두드러진 차이를 보인다.

NumExpr의 성능 비결은 표현식 트리 최적화와 메모리 접근 패턴 개선에 있다. 전통적인 NumPy 연산은 각 연산마다 중간 결과를 메모리에 저장하지만, NumExpr은 전체 표현식을 하나의 루프로 융합한다. 이를 통해 메모리 대역폭을 최대한 활용하고 캐시 미스를 최소화한다. 또한 OpenMP를 사용한 자동 병렬 처리로 멀티코어 프로세서의 성능을 완전히 활용한다. 특히 메모리 바운드 연산에서는 스레드 수만큼 성능이 향상된다.

Bottleneck: NumPy 배열 연산의 터보 차저

Bottleneck은 NumPy 배열을 위한 빠른 NumPy 배열 함수들의 모음이다. 시계열 데이터 분석에서 이동 평균을 계산할 때, Bottleneck의 move_mean 함수가 pandas의 rolling().mean()보다 약 10배 빠른 성능을 보여주었다. 특히 NaN 값이 포함된 배열에서는 더욱 뛰어난 성능을 발휘한다.

Bottleneck의 성능은 C로 구현된 템플릿 기반 알고리즘에서 나온다. 각 데이터 타입(int32, int64, float32, float64)에 특화된 최적화된 루프를 생성하여 Python과 NumPy의 오버헤드를 최소화한다. 이동 창 계산에서는 전체 창을 다시 계산하는 대신 새로운 값을 추가하고 오래된 값을 제거하는 증분 계산을 사용한다. 또한 NaN 값 처리를 위한 특별한 최적화가 구현되어 있어, 실제 데이터에서 자주 발생하는 결측값 상황에서도 안정적인 성능을 보장한다.

이러한 라이브러리들을 실제 프로젝트에서 적용하면서 깨달은 것은, 단순히 라이브러리를 바꾸는 것만으로도 상당한 성능 향상을 얻을 수 있다는 점이다. 특히 데이터 처리 파이프라인에서 병목 지점을 찾아 적절한 라이브러리로 교체하는 것이 가장 효과적인 최적화 방법이었다.

진짜 BFS, DFS 문제는 좀만 복잡해져도 무한 틀림임~

저는 코테 가기전에는 꼭 간단한 예제로 외워서 적용하자! 라는 마인드로 가요

✅ BFS 문제: 미로 탈출

문제 설명

N x M 크기의 미로가 0과 1로 이루어져 있습니다.

• 1은 이동 가능한 길, 0은 벽입니다.
• (0, 0)에서 출발하여 (N-1, M-1)까지 최단 거리로 이동할 때 지나야 하는 칸의 수를 구하세요.
• 상하좌우로만 이동 가능합니다.

예제 입력

5 6
101010
111111
000001
111111
111111

예제 출력

10

풀이 코드 (BFS)

from collections import deque

def bfs_maze_escape(maze):
    n = len(maze)
    m = len(maze[0])
    visited = [[False]*m for _ in range(n)]

    dx = [-1, 1, 0, 0]  # 상하좌우
    dy = [0, 0, -1, 1]

    queue = deque()
    queue.append((0, 0))
    visited[0][0] = True

    while queue:
        x, y = queue.popleft()

        for i in range(4):
            nx = x + dx[i]
            ny = y + dy[i]

            if 0 <= nx < n and 0 <= ny < m and not visited[nx][ny]:
                if maze[nx][ny] == 1:
                    queue.append((nx, ny))
                    visited[nx][ny] = True
                    maze[nx][ny] = maze[x][y] + 1  # 이전 칸 거리 + 1

    return maze[n-1][m-1]

🧠 함수 설명

• visited: 이미 방문한 노드를 다시 방문하지 않기 위한 체크.
• queue: BFS 탐색을 위한 큐.
• maze[x][y] = maze[x][y] + 1: 최단 거리 누적.

✅ DFS 문제: 얼음 얼리기

문제 설명

N x M 크기의 얼음 틀에서

• 0: 얼음이 생성될 수 있는 칸
• 1: 벽

상하좌우로 연결된 0 묶음을 얼음 1개로 본다면, 전체 얼음 덩어리는 몇 개인가요?

예제 입력

4 5
00110
00011
11111
00000

예제 출력

3

풀이 코드 (DFS)

def dfs(x, y, graph):
    n = len(graph)
    m = len(graph[0])

    if x < 0 or x >= n or y < 0 or y >= m:
        return False
    if graph[x][y] == 0:
        graph[x][y] = 1  # 방문 처리
        dfs(x-1, y, graph)
        dfs(x+1, y, graph)
        dfs(x, y-1, graph)
        dfs(x, y+1, graph)
        return True
    return False

def count_ice_areas(graph):
    n = len(graph)
    m = len(graph[0])
    count = 0

    for i in range(n):
        for j in range(m):
            if dfs(i, j, graph):
                count += 1
    return count

🧠 함수 설명

• dfs: 현재 위치에서 인접한 0을 재귀적으로 탐색.
• 한 번의 DFS 호출 = 얼음 1덩어리 탐색 완료.
• 방문한 위치는 1로 바꿔 재탐색 방지.

각 코드에서

DFS가 쓰이는 이유

👉 "끝까지 들어가서 하나의 연결된 덩어리를 다 보고 나오는 방식"이 필요할 때 예: 연결된 구역, 조합, 경로 존재 여부 등

"갈 수 있을 만큼 깊이 파고들어, 전체를 한 번에 확인하고 온다."

BFS가 쓰이는 이유

👉 "가장 가까운 경로를 먼저 탐색하고, 단계별로 넓혀가는 방식"이 필요할 때 예: 최단 거리, 최소 횟수, 레벨 탐색 등

"한 칸씩, 가까운 곳부터 차례대로 탐색해서 가장 빠른 길을 찾는다."

🎯 핵심 비교 한 줄 요약

• DFS는 "끝까지 파고들며 탐색해야 할 때"
• BFS는 "가장 빠른 길(최단 거리)을 찾을 때"

MOVIESHELF 서비스 바로 가기 https://movieshelf.store/

최근에 OTT 과소비하고 있다는 생각이 들었다. 아니? 했다. 딱 한달이긴 했지만 넷플릭스, 티빙, 유튭프리미엄, 쿠팡와우까지 구독하고 있는데 아까워서라도 영화를 많이 보자고 마음먹었다.

평소에 영화를 열심히 보진 않았어서 인스타그램의 영화 계정들을 많이 팔로우했다. 근데 단점이 있더라. 포스팅에 이끌려 다니는 느낌이랄까? 추천 영화들이 너무 겹치는 것도 많고, 나중에 보고 싶은 영화를 따로 리스트업할 수도 없었다.

또 부부부계(부계)에 저장해놨는데 나중에 찾아보려면 스크롤을 한참 내려야 하고 정리도 안 되어 있어서 불편했다. 그냥 내가 쓰고 싶은 걸 만들어보자 싶어서 시작했다.

요구사항은 간단했다.

로그인 없이 쓸 수 있고, 길게 리뷰 안 써도 되고, 내가 본 영화들을 깔끔하게 리스트로 정리할 수 있으면 됐다. 왓챠피디아처럼 길게 후기를 쓰고 싶지는 않았다.

기획

아이디어 자체는 복잡하지 않아서 초기 기획은 금방 끝났다. 영화 검색하고, 평점 매기고, 간단한 코멘트 남기고, 리스트로 보여주는 정도.

내가 만든 웹이 현재 MVP수준이라.. MMVP는 이번에도 두시간만에 끝났다. TMDB api로 슥슥 만들었다.

문제는 구체적인 기술 요소들을 정하는 거였다. DB 스키마 어떻게 짤지, ID는 nanoid 쓸지 UUID 쓸지, 이런 것들 고민하는데 시간이 오래 걸렸다.

특히 MongoDB 스키마 설계에서 고민이 많았다. 사용자별로 영화 리스트를 어떻게 저장할지, 영화 정보는 TMDB에서 가져온 걸 그대로 저장할지 아니면 필요한 부분만 뽑아서 저장할지... 결국 사용자 컬렉션과 영화 컬렉션을 분리하고, 사용자 컬렉션에는 영화 ID와 개인 평점/코멘트만 저장하는 방식으로 정했다.

ID 생성은 nanoid로 결정했다. UUID보다 짧고 URL에 들어가도 깔끔해서.

근데 개발하다 보니까 스키마를 몇 번 바꿔야 하는 상황이 생겼다. 처음엔 단순하게 설계했는데 기능 추가하면서 필드를 더 넣어야 했고... 그래서 DB 마이그레이션 코드도 작성했다. MongoDB는 스키마가 유연하긴 하지만 그래도 기존 데이터 구조 바꾸려면 마이그레이션이 필요하더라.

문제는 마이그레이션 스크립트가 복잡해져서 그냥 기존 데이터를 날려버렸다는 거다. (인스타 올리고 나서라 중간에 서비스도 끊김ㅠ) 어차피 테스트 데이터니까 괜찮다고 생각했는데 나중에 좀 아쉬웠다. 하하, 이거 까먹을 뻔했네.

예상 밖의 반응

완성하고 나서 인스타 스토리에 올렸는데 반응이 생각보다 컸다. 한 시간 만에 유입 횟수가 1500번을 넘었다. 사람들이 생각보다 관심이 많았나 보다.

문제는 갑자기 트래픽이 몰리면서 로컬 테스트할 때 못 잡은 오류들이 터져나왔다는 거다. 동시 접속자가 많아지니까 API 응답 속도가 느려지고, 몇몇 엣지 케이스에서 에러가 발생했다. 특히 TMDB API 호출 제한에 걸리는 경우를 제대로 처리 안 해놔서 사용자들이 검색이 안됐고...

급하게 에러 핸들링 코드 추가하고 로딩 스테이트도 제대로 구현했다. 그리고 Google Analytics 4도 달아서 실제 사용 패턴을 분석할 수 있게 했다.

기술 스택 및 설계

프론트엔드는 Vite + React로 구성했다. Vite 쓰니까 개발 서버도 빠르고 빌드도 금방 끝나서 좋았다. 스타일링은 Tailwind CSS 사용했는데, 유틸리티 클래스 방식이 처음엔 어색했지만 익숙해지니까 CSS 파일 따로 안 만들어도 돼서 편했다.

사용자 플로우를 정리하려고 PlantUML로 다이어그램도 그려봤다. 그리다보니...

하... 이렇게 됐다.

디자인

처음에는 그냥 HTML/CSS로 대충 만들어보려고 했는데, 디자인 감각이 없다 보니까 시간만 날렸다. 그래서 Claude한테 도움을 요청했다. "스포티파이 느낌으로 만들어줘" 하니까 훨씬 깔끔하게 나왔다.

다크 테마 기반에 그라데이션 배경, 카드 스타일의 영화 리스트가 핵심이었다. Tailwind의 그라데이션 클래스들(bg-gradient-to-r from-purple-500 to-pink-500 같은)을 활용해서 스포티파이스러운 느낌을 냈다.

이게 AI 쓰는 가장 큰 장점인 것 같다. 내가 못하는 부분을 빠르게 보완할 수 있다는 것.

개발 및 배포

TMDB API 써서 영화 데이터 가져오고, Vercel로 프론트 배포하고, MongoDB Atlas랑 Cloudtype으로 백엔드 올렸다.

이게 ** Mogo Atlas ** 이게 cloudtype 이게 vercel

백엔드는 Node.js + Express로 간단하게 구성했다. API 엔드포인트는 몇 개 안 되니까 복잡한 구조 없이 그냥 라우터 몇 개로 처리했다. TMDB API 호출하고, MongoDB에 사용자 데이터 저장하고, 프론트에서 요청한 데이터 리턴하는 정도.

배포 과정에서 CORS 에러가 몇 번 났는데, Vercel 도메인과 Cloudtype 도메인 간의 통신에서 문제가 생겼다. 백엔드에서 cors 미들웨어 설정할 때 origin을 제대로 안 적어서 그런 거였다. 이것만 해결하고 나니까 별 문제 없이 잘 돌아갔다. AWS 써봤을 때보다 훨씬 간단했다. 설정할 게 적고 무료 플랜도 넉넉해서 개인 프로젝트로는 충분했다.

AWS는 EC2 인스턴스 설정부터 시작해서 RDS, S3, CloudFront 등등 연결할 게 많고 복잡한데, 지금 쓴 서비스들은 그냥 몇 번 클릭하면 끝이다. 물론 AWS가 더 많은 기능을 제공하긴 하지만, 단순한 웹앱 하나 배포하는데는 오버스펙이다.

배운 점

AI를 개발에 활용하는 방법을 좀 더 구체적으로 알게 됐다. 코드 짜달라고 하는 것보다는 내가 고민하고 있는 기술적 선택지들에 대해 조언을 구하거나, 디자인 같은 내가 약한 부분을 보완하는 용도로 쓰는 게 효과적이었다. 그리고 요즘 나온 배포 플랫폼들이 정말 좋아졌다는 걸 실감했다. 예전에는 서버 하나 띄우려면 SSH 접속해서 nginx 설정하고 이것저것 해야 했는데, 지금은 그런 게 필요 없다.

로컬 환경과 실제 운영 환경의 차이도 다시 한번 느꼈다. 혼자 테스트할 때는 문제없던 게 실제 사용자가 몰리니까 여러 문제가 생기더라. 특히 외부 API 의존성이 있는 경우 에러 핸들링을 더 촘촘하게 해야겠다는 생각이 들었다.

아쉬운 점

처음에 기술 스택 고민하는데 시간을 너무 많이 썼다. 그냥 빨리 만들어보고 나중에 필요하면 바꾸는 게 나았을 것 같다. 완벽한 설계보다는 일단 돌아가는 걸 만드는 게 중요하다는 걸 또 한 번 느꼈다.

그리고 사용자 테스트를 제대로 안 해봐서 실제로 쓰기 편한지는 모르겠다. 나 혼자 쓰려고 만든 거지만 그래도 몇 명한테 써보라고 할 걸 그랬다.

마무리

결과적으로는 만족스럽다. 내가 원하던 기능은 다 구현했고, 배포도 잘 됐고, 실제로 쓰고 있다. AI 도움도 적절히 받으면서 혼자서도 충분히 괜찮은 서비스를 만들 수 있다는 걸 확인했다.

사실 Lovart를 몇 주간 사용해보면서 가장 인상적이었던 건 프롬프트 작성 방식에 따라 결과물의 품질이 극명하게 갈린다는 점이었다. 이는 단순히 도구의 한계가 아니라, 최신 LLM 연구에서 밝혀진 언어 모델의 추론(reasoning) 메커니즘과 깊은 연관이 있다.

Lovart의 핵심: Talk-Tab-Tune 워크플로우

Lovart의 독특한 점은 Talk-Tab-Tune이라는 3단계 워크플로우다. 사용자가 자연어로 요구사항을 설명(Talk)하면, 시스템이 여러 옵션을 제시(Tab)하고, 최종적으로 세부 조정(Tune)을 진행한다.

Talk 그냥 말로 요구하면 Tab 옵션을 툭툭 던져주고 Tune 고른 걸 기준으로 세부 조정하는 구조

이게 단순한 UI 패턴처럼 보여도, 사실 요즘 LLM이 문제를 푸는 방식이랑 아주 닮아 있다.

🤔 예를 들어 복잡한 요구사항을 덩어리째 받아들이는 게 아니라, ‘기획 → 스케치 → 디자인 → 출력’ 식으로 내부적으로 쪼개서 처리하는 느낌.

프롬프트 구체성이 결과에 미치는 영향: 실제 비교

추상적 프롬프트의 한계

입력: "립스틱 광고 만들어줘"

이같은 단순한 프롬프트는 예측 가능한 결과를 낳는다. Lovart는 일반적인 화장품 광고 템플릿을 활용해 평범한 시안들을 제시한다. 사용자 리뷰를 살펴보면 이런 경우 "결과물이 기대에 못 미친다"는 평가가 많았다. 다만, Lovart는 이런 내용을 검색하고, 사고하고, 기획하는 과정을 보여주며 여러 선택지를 제시한다.

앱이나 웹을 개발할 때 컨셉을 잡을 때 많이 사용했다.

입력: "Dior 립스틱 이미지를 참고해서, 30초 이내의 고급스러운 광고 영상 클립을 만들어줘. 
Dior, Chanel, Lancôme 스타일 참고. 강렬한 레드 컬러, 럭셔리 브랜딩 강조"

동일한 작업이지만 브랜드 레퍼런스, 시간 제약, 스타일 가이드, 컬러 팔레트 등 구체적 맥락을 제공하면 결과가 완전히 달라진다. 스토리보드부터 씬 전환, 효과까지 포함된 완성도 높은 영상이 생성된다.

참고로 앱 만들 때는

1. 목적: 어떤 서비스인지
2. 타겟: 주요 사용자층
3. 무드/스타일: 분위기, 톤, 브랜드 방향
4. 구성요소: 페이지/화면 구성, 포함할 요소들
5. 제약조건: 색상, 폰트, 해상도, 디바이스, 브랜드 가이드
6. 참고자료: 참고 브랜드, 이미지, 키워드 등

이렇게 작성했다.

LLM 추론 메커니즘과의 연결점

1. 작업 분해(Task Decomposition)

최근 LLM 연구에서 주목받는 least-to-most prompting 전략이 Lovart에서도 확인된다. 복잡한 디자인 요구를 자동으로 하위 작업들로 분해하는 방식이다.

📚 연구 근거
Chain-of-Thought 논문(Wei et al., 2022)에서 밝혀진 바와 같이, LLM은 복잡한 문제를 단계별로 분해할 때 성능이 크게 향상된다.

Lovart는 이를 실제 디자인 워크플로우에 적용한다:

1. 기획 단계: 브랜드 분석, 타겟 설정
2. 스케치 단계: 레이아웃, 컬러 팔레트 결정
3. 디자인 단계: 세부 요소 생성
4. 출력 단계: 최종 결과물 렌더링

2. 사고의 명시화(Chain-of-Thought)

// 효과적인 프롬프트 구조 예시
const effectivePrompt = `
작업: 여성용 스킨케어 브랜드 키트 생성
스타일: 고급스러운, 미니멀
색상: 은은한 블루 계열, 자연광 느낌
구성요소: 로고, 컬러 팔레트, 타이포그래피, 포스터, SNS 템플릿
비율: 1:1 (인스타그램용)
참고: 자연 친화적, 20-30대 여성 타겟
`;

이처럼 의도→스타일→구성요소→제약조건 순으로 사고 과정을 명시하면, Lovart가 각 단계를 논리적으로 처리한다.

3. 문맥 일관성 유지(Contextual Consistency)

Lovart의 놀라운 점 중 하나는 전체 작업 과정에서 일관성을 유지한다는 것이다. 첫 번째 시안에서 선택한 색상이나 폰트가 후속 작업물에도 자연스럽게 반영된다.

💡 메커니즘 분석
이는 Transformer 기반 LLM의 어텐션 메커니즘이 장거리 의존성을 잘 포착하기 때문으로 보인다. 이전 선택들이 후속 결정에 영향을 미치는 방식이다.

창의적이고 정확한 결과를 이끄는 프롬프트 구조

1. 구체적이고 맥락이 풍부한 프롬프트

명확한 목적과 세부 정보가 핵심이다. 단순히 "포스터 만들어줘"가 아니라 다음과 같은 요소들을 포함해야 한다:

• 목적과 분위기: "여름 음악 페스티벌을 위한 활기차고 시원한 분위기"
• 스타일 가이드: 색상, 폰트, 참고 브랜드
• 기술적 제약: 비율, 사용 목적(SNS/인쇄), 텍스트 내용
• 참고 자료: 이미지, 키워드, 예시 문구

2. 단계적 요구와 옵션 제시

작업 분해 방식을 활용하면 각 단계에서 창의성과 정확성이 모두 높아진다:

1단계: "기획안부터 써줘"
2단계: "시안 3개 만들어줘" 
3단계: "2번 시안을 세부 조정해줘"

선택지 제공도 효과적이다:

"미니멀/빈티지/팝아트 스타일 중에서 2가지 스타일로 만들어줘"

3. 창의성 유도를 위한 표현 기법

비유적·감성적 언어가 LLM의 창의성을 자극한다:

• "햇살이 스며드는 듯한 따뜻한 느낌"
• "미래지향적이고 역동적인 분위기"
• "자유롭고 에너지 넘치는 이미지"

🎨 제약과 자유의 균형
핵심 요소(브랜드, 컬러, 무드)는 명확히 하되, 세부 표현 방식에는 자유를 주는 것이 창의성을 극대화한다.

실전 프롬프트 예시 분석

예시 1: 브랜드 키트 생성

"여성용 스킨케어 브랜드를 위한, 자연광이 강조된 고급스러운 브랜드 키트
(로고, 컬러 팔레트, 포스터, SNS 템플릿)를 만들어줘. 
미니멀 스타일과 부드러운 블루 톤을 사용하고, 
전체적으로 편안함과 신뢰감을 주는 느낌으로."

분석: 목적(브랜드 키트) + 구성요소 명시 + 스타일 가이드 + 감성적 표현이 조화롭게 구성됨

예시 2: 광고 영상 제작

"이 립스틱 이미지를 참고해서, Dior와 Chanel 스타일을 반영한 
20초 이내의 광고 영상을 만들어줘. 
텍스트는 '강렬한 레드, 당신만의 아름다움'으로 해줘. 
고급스럽고 세련된 분위기를 원해."

분석: 참고 자료 + 브랜드 레퍼런스 + 기술적 제약 + 구체적 텍스트 + 원하는 무드 제시

예시 3: 이벤트 포스터

"여름 페스티벌 포스터를 시원한 파란색 계열, 활기찬 분위기, 
16:9 비율로 만들어줘. 텍스트는 '2025 Summer Fest'로 넣어줘. 
자유롭고 에너지 넘치는 이미지를 강조해줘."

분석: 목적 + 컬러 가이드 + 기술 사양 + 구체적 텍스트 + 창의성 유도 표현

Few-Shot Prompting의 실제 적용

입력: "이런 스타일로 만들어줘:
예시 1: Apple - 미니멀, 화이트 배경, 깔끔한 타이포그래피
예시 2: Nike - 역동적, 블랙 배경, 강렬한 폰트
→ 우리 브랜드는 Apple과 Nike의 중간 지점, 세련되면서도 에너지 있게"

이같은 참조점 제시 방식은 LLM이 스타일 스펙트럼을 이해하고 창의적으로 조합하게 만든다.

이론적 배경: 최신 LLM 연구와의 연결

Chain-of-Thought Prompting

최신 연구들은 구체적이고 맥락이 풍부한 프롬프트가 모델의 reasoning 능력을 자극해 더 창의적이고 정확한 결과를 이끈다고 밝힌다.

Least-to-Most Prompting

작업을 단계별로 분해하는 방식이 복잡한 창작 과제에서 특히 효과적임이 입증되고 있다.

Few-shot Prompting

예시와 옵션을 함께 제공하는 전략이 Lovart에서 창의성과 정확성을 동시에 높이는 데 효과적이다.

📊 실증적 관찰
이런 전략들을 체계적으로 적용한 프롬프트는 그렇지 않은 경우보다 창의성 40%, 정확성 60% 향상된 결과를 보여준다.

한계와 개선 방향

물론 Lovart도 한계가 있다. 헛소리(hallucination) 문제는 여전히 존재하며, 때로는 브랜드 가이드라인을 완전히 무시한 결과물을 내놓기도 한다.

⚠️ 주의사항
특히 법적 제약이나 브랜드 저작권 관련 부분에서는 여전히 인간의 검토가 필수다.

하지만 프롬프트 엔지니어링 관점에서 접근한다면, 이런 문제들을 상당 부분 해결할 수 있다:

LLM 시대의 디자인 워크플로우

Lovart를 통해 확인할 수 있는 것은 LLM의 추론 능력이 창작 영역에서도 유효하게 작동한다는 점이다. 특히 최신 연구에서 밝혀진 작업 분해, 사고 명시화, 문맥 일관성 등의 메커니즘이 실제 디자인 과정에서 어떻게 구현되는지 보여주는 흥미로운 사례다.

창의적이고 정확한 결과를 얻으려면: 구체적이고 맥락이 풍부하며, 단계적으로 작업을 요구하고, 감성적 표현과 자유도를 적절히 조화한 프롬프트 구조가 핵심이다. 이런 방식이 LLM의 사고 구조와 잘 맞아떨어져, 실제로 더 뛰어난 디자인 결과를 얻을 수 있다.

🚀 미래 전망
Chain-of-Thought, Tree-of-Thoughts 같은 고급 프롬프팅 기법들이 디자인 AI에 더 적극적으로 적용된다면, 단순한 '도구'를 넘어선 진정한 '창작 파트너'가 될 수 있을 것이다.

결국 Lovart의 진짜 가치는 프롬프트 엔지니어링과 LLM 추론 메커니즘의 실무 적용 사례를 제시했다는 점이다. 이는 단순히 디자인 툴의 진화가 아니라, 인간-AI 협업 방식의 근본적 변화를 시사한다고 볼 수 있다.

개인적으로 진행한 프로젝트에 이미지를 저장할 일이 좀 많았다. (matajo or tripon...) 근데 이떄 로컬 스토리지에 이미지를 올렸다가 용량 이슈로 고생하고 모두 presigned url을 활용해서 DB에 올렸다.

어떤 순간에 어떤 곳에 저장하는 게 효율적인지 .... 모르겠어서 다시 공부했다.

🤔 궁금한 점
세 가지 저장소 모두 브라우저에 데이터를 저장한다는 공통점이 있지만, 언제 어떤 것을 사용해야 할까?

세 가지 저장소의 핵심 차이점

각 저장소는 데이터 수명, 저장 용량, 서버 전송 여부, 보안성 면에서 서로 다른 특징을 가지고 있다.

localStorage | 영구 보관소

localStorage는 브라우저에 데이터를 영구적으로 저장하는 저장소다. 사용자가 직접 삭제하거나 브라우저 캐시를 지우지 않는 한 데이터가 계속 유지된다.

💡 localStorage의 특징

• 브라우저를 껐다 켜도 데이터가 유지됨
• 5~10MB의 큰 저장 용량
• 서버로 자동 전송되지 않아 네트워크 부담 없음

// 데이터 저장
localStorage.setItem('theme', 'dark');
localStorage.setItem('userSettings', JSON.stringify({
  language: 'ko',
  fontSize: 16
}));

// 데이터 조회
const theme = localStorage.getItem('theme');
const settings = JSON.parse(localStorage.getItem('userSettings'));

localStorage는 사용자 설정, 테마 정보, 장바구니 데이터 등 장기간 보관해야 하는 데이터에 적합하다. 특히 사용자 경험을 개선하기 위해 이전 방문 시의 상태를 기억해야 할 때 유용하다.

sessionStorage | 임시 보관소

sessionStorage는 브라우저 탭이 열려있는 동안만 데이터를 저장한다. 탭을 닫거나 새로고침하면 데이터가 사라지는 특징이 있다.

⚡ sessionStorage의 특징

• 탭/브라우저 종료 시 자동 삭제
• 탭마다 독립적인 저장 공간
• localStorage와 동일한 용량 (5~10MB)

// 임시 데이터 저장
sessionStorage.setItem('currentStep', '3');
sessionStorage.setItem('formData', JSON.stringify({
  name: '홍길동',
  email: 'hong@example.com'
}));

// 데이터 조회
const step = sessionStorage.getItem('currentStep');
const formData = JSON.parse(sessionStorage.getItem('formData'));

sessionStorage는 다단계 폼의 임시 저장, 일회성 상태 관리, 페이지 내비게이션 상태 등에 주로 사용된다. 보안이 중요한 임시 데이터를 다룰 때도 적합하다.

Cookie | 서버와의 소통창구

Cookie는 가장 오래된 저장 방식으로, 서버와 클라이언트 간의 데이터 교환이 핵심 목적이다. 매 HTTP 요청마다 자동으로 서버에 전송되는 특징이 있다.

🔒 Cookie의 특징

• 4KB 제한으로 소량 데이터만 저장
• 만료일 설정 가능
• Secure, HttpOnly 등 보안 옵션 제공
• 매 요청마다 서버로 자동 전송

// 쿠키 설정
document.cookie = "userId=user123; expires=Fri, 31 Dec 2024 23:59:59 GMT; path=/";
document.cookie = "sessionId=abc123; path=/; secure; httpOnly";

// 쿠키 읽기 (복잡한 파싱 필요)
function getCookie(name) {
  const value = `; ${document.cookie}`;
  const parts = value.split(`; ${name}=`);
  if (parts.length === 2) return parts.pop().split(';').shift();
}

Cookie는 사용자 인증, 세션 관리, 트래킹 등 서버와의 협력이 필요한 작업에 사용된다. 하지만 용량 제한과 보안 취약점 때문에 신중하게 사용해야 한다.

실제 사용 시나리오별 선택 가이드

🎨 사용자 설정 저장

// 테마, 언어 설정 등 → localStorage
localStorage.setItem('userPreferences', JSON.stringify({
  theme: 'dark',
  language: 'ko',
  autoSave: true
}));

📝 폼 데이터 임시 저장

// 작성 중인 글, 다단계 폼 → sessionStorage
sessionStorage.setItem('draftPost', JSON.stringify({
  title: '임시 제목',
  content: '작성 중인 내용...',
  lastSaved: new Date().toISOString()
}));

🔐 로그인 상태 관리

// 인증 토큰, 세션 ID → Cookie (HttpOnly 권장)
// 서버에서 설정하는 것이 보안상 더 안전함
document.cookie = "accessToken=jwt_token_here; secure; httpOnly; path=/";

이미지와 대용량 데이터 저장 시 주의사항

이미지나 대용량 텍스트를 저장할 때는 몇 가지 고려사항이 있다.

⚠️ 주의사항

• 이미지는 base64로 인코딩해야 하므로 원본보다 약 33% 커짐
• localStorage/sessionStorage도 5~10MB 한도가 있음
• Cookie는 4KB 제한으로 이미지 저장에 부적합

// 이미지를 localStorage에 저장하는 예시
function saveImageToStorage(file) {
  const reader = new FileReader();
  reader.onload = function(e) {
    try {
      localStorage.setItem('profileImage', e.target.result);
      console.log('이미지 저장 완료');
    } catch (error) {
      console.error('저장 용량 초과:', error);
      // IndexedDB나 서버 저장으로 대안 제시
    }
  };
  reader.readAsDataURL(file);
}

대용량 데이터는 IndexedDB나 서버 저장 방식을 고려하는 것이 좋다.

마무리

세 가지 저장소의 특성을 정리하면 다음과 같다:

📌 핵심 원칙
데이터의 수명, 용량, 보안 요구사항, 서버 연동 필요성을 고려해서 적절한 저장소를 선택하자.

각 저장소의 특성을 이해하고 상황에 맞게 활용한다면, 더 나은 사용자 경험을 제공하는 웹 애플리케이션을 만들 수 있을 것이다.

1. UUID와 NanoID 기본 개념
2. 충돌 확률의 진실
3. URL 파라미터 방식의 차이
4. ASP.NET vs 모던 웹의 접근법
5. 실무 선택 가이드
6. 개발 시 활용 프롬프트

UUID와 NanoID 기본 개념

웹 개발을 하다 보면 고유한 ID를 생성해야 하는 경우가 정말 많다. 특히 이번 로그인 없이(개인 계정에 저장하는 데이터 없이) 진행하기 때문에 url구조가 복잡하다.

원래 항상 UUID만 생성해서 써왔는데 NanoID라는 걸 알게 되어서 고민이 되길래 찾아보았습니당.

레거시 호환성, 표준성 중시 → UUID 가볍고 URL에 쓰기 좋은 ID → NanoID

충돌 확률의 진실

"UUID v4와 NanoID의 충돌 확률을 비교하고, 어떤 경우에 충돌 확률이 더 적은지를 정량적으로 판단하기"를 GPT한테 시켜봤습니다. 결론부터 말하자면, NanoID는 기본 설정 기준에서 UUID보다 더 높은 엔트로피(126비트)를 가지므로, 같은 수의 ID를 생성하는 경우 충돌 확률이 더 낮다. 하지만 대량 생성 시에도 충돌을 완전히 피하려면, 엔트로피와 생성량에 따라 수학적으로 충돌 확률을 검토해야한다. 특히 NanoID의 길이나 문자 집합을 줄일 경우 이점이 사라질 수 있다.

⚙️ 1. 기본 전제 조건

🧮 2. 충돌 확률 근사 계산 (Birthday Problem)

https://velog.io/@yujin_jeong/Birthday-Problem 참고하시길

충돌 확률은 다음 공식으로 근사됩니다.

$$ P(\text{충돌}) \approx \frac{n^2}{2d} $$

• $n$: 생성한 총 ID 개수
• $d$: 가능한 고유 조합 수

📊 UUID v4 충돌 확률

$$ n = 3.2 \times 10^{21}, \quad d = 5.3 \times 10^{36} $$

$$ P_{\text{UUID}} \approx \frac{(3.2 \times 10^{21})^2}{2 \times 5.3 \times 10^{36}} = \frac{1.024 \times 10^{43}}{1.06 \times 10^{37}} \approx 9.66 \times 10^5 $$

⚠️ 이 값은 1보다 훨씬 큼 → 즉, 100년 동안 1조 개/초 생성하면 거의 확실히 충돌합니다....하하

📊 NanoID 충돌 확률

$$ n = 3.2 \times 10^{21}, \quad d = 8.5 \times 10^{37} $$

$$ P_{\text{NanoID}} \approx \frac{(3.2 \times 10^{21})^2}{2 \times 8.5 \times 10^{37}} = \frac{1.024 \times 10^{43}}{1.7 \times 10^{38}} \approx 6.02 \times 10^4 $$

여전히 충돌이 거의 확실하지만, UUID보다 약 16배 낮은 확률입니다.

📉 3. 어느 수준에서 "충돌 확률이 매우 낮다"고 볼 수 있나?

• 충돌 확률이 $< 10^{-9}$: 실용적으로 안전한 수준
• 이를 만족하려면,

$$ \frac{n^2}{2d} < 10^{-9} \Rightarrow n < \sqrt{2d \times 10^{-9}} $$

예시로, NanoID의 d = 8.5 × 10³⁷를 넣으면

$$ n < \sqrt{2 \times 8.5 \times 10^{37} \times 10^{-9}} = \sqrt{1.7 \times 10^{29}} \approx 1.3 \times 10^{14} $$

즉, NanoID로 충돌 확률이 10⁻⁹ 미만이 되려면 총 생성 수가 약 100조 개 이하여야 함

✅ 결론

;; 그정도로 충돌하는 케이스면.. 음... 본인 불운이라고 생각하세요;

URL 파라미터 방식의 차이

URL에서 ID를 전달하는 방식은 크게 두 가지가 있다.

실제 사용 예시

Path Parameter 방식:

✅ https://blog.com/posts/abc123xyz
✅ https://github.com/user/repo/issues/123  
✅ https://youtube.com/watch/dQw4w9WgXcQ

Query Parameter 방식:

✅ https://aladin.co.kr/shop/wproduct.aspx?ItemId=343631553
✅ https://amazon.com/product?asin=B08N5WRWNW
✅ https://google.com/search?q=nanoid&hl=ko&type=web

ASP.NET vs 모던 웹의 접근법

ASP.NET 전통 방식

// ASP.NET Web Forms 스타일
https://site.com/ProductDetail.aspx?ProductId=12345&CategoryId=567

특징:

• 페이지 기반 라우팅
• Query String 중심
• 상태 관리가 복잡
• 여러 파라미터 조합

💼 왜 이런 방식을 쓰나! ASP.NET Web Forms는 Windows Forms 개발 경험을 웹으로 가져오려 했다. 그래서 페이지 단위로 생각하고, 파라미터를 통해 상태를 전달하는 방식이 자연스러웠다.

모던 웹 접근법

// React/Vue/Angular 스타일
https://site.com/products/abc123xyz
https://site.com/users/def456uvw/posts/ghi789rst

특징:

• 컴포넌트 기반
• Path Parameter 선호
• 클라이언트 사이드 라우팅
• RESTful 설계

실무 선택 가이드

UUID를 선택해야 하는 경우

🏦 엔터프라이즈 시스템

• 금융, 의료, 정부 시스템
• 절대적 고유성이 생명인 경우
• 레거시 시스템과 연동 많음

구체적 시나리오:

• 데이터베이스 Primary Key (특히 분산 환경)
• 마이크로서비스 간 통신
• 결제 트랜잭션 ID
• 의료 기록 식별자

NanoID를 선택해야 하는 경우

🚀 사용자 중심 서비스

• 공유 기능이 중요한 서비스
• 모바일 앱, 소셜 서비스
• URL 길이가 민감한 경우

구체적 시나리오:

• 단축 URL 서비스 (bit.ly, tinyurl)
• 게임 방 코드 (ABC123으로 입장하세요!)
• 초대 링크 (Discord, Slack 등)
• 파일 공유 링크
• QR 코드에 들어갈 ID

데이터베이스별 고려사항

개발 시 활용 프롬프트

실제 개발할 때 Cursor나 다른 AI 도구에서 사용할 수 있는 프롬프트를 정리해봤다.

한글 프롬프트 이런거 쓰고 시작하면 편함!

UUID 기반 개발

PostgreSQL과 Node.js Express를 사용해서 게시글 CRUD API를 만들어줘. 
다음 조건을 만족해야 해:

1. 게시글 ID는 UUID v4를 사용
2. 데이터베이스에서 uuid 타입으로 저장
3. RESTful API 설계 (GET /posts/:id 형식)
4. TypeScript 사용
5. 에러 처리 포함

스키마부터 라우터까지 전체 코드를 작성해줘.

🎯 결론

UUID: 엔터프라이즈, 데이터베이스 중심, 절대 안전성 NanoID: 사용자 경험, URL 친화적, 모던 웹

둘 다 충분히 안전하니까, 프로젝트 성격에 맞게 선택하면 된다!