1. ls -al 출력 구조

-rwxr-x--- 1 myaccount mygroup 1234 Apr 27 test.txt

각 항목 의미

2. 권한 구조 (핵심)

권한은 항상 아래 순서로 나뉜다:

rwx | r-x | ---
 u    g     o

3. 권한 종류

4. 권한 적용 기준 (매우 중요)

권한은 단 하나만 적용된다

우선순위:

1. 1순위: user (소유자)
2. 2순위: group
3. 3순위: others

내가 어떤 위치에 속하느냐에 따라 권한이 결정됨

5. 사용자 조건

• 내 계정: myaccount
• 내 그룹: mygroup
• 다른 계정: anotheraccount
• 다른 그룹: anothergroup

케이스별 권한 해석

1. 내가 만든 파일 -rwxr-x--- myaccount mygroup file.txt

• 나 (myaccount): user 권한 적용 (rwx)
  • 읽기 (가능), 수정 (가능), 실행 (가능)
• 같은 그룹 (mygroup): group 권한 적용 (r-x)
  • 읽기 (가능), 수정 (불가능), 실행 (가능)
• 다른 사용자: others (---)
  • 아무것도 못함 (불가능)

2. 내가 만든 파일 (다른 그룹) -rwxr-x--- myaccount anothergroup file.txt

• 나: rwx (모든 권한)
• 내 그룹 (mygroup): group 아님 -> others 적용 (---)
  • 접근 불가

3. 다른 사람이 만든 파일 (같은 그룹) -rwxr-x--- anotheraccount mygroup file.txt

• 나: group 권한 (r-x)
  • 읽기 (가능), 수정 (불가능), 실행 (가능)

4. 완전히 남의 파일 -rwxr-x--- anotheraccount anothergroup file.txt

• 나: others (---)
  • 접근 불가

6. 디렉토리 권한 (중요)

drwxr-x--- myaccount mygroup mydir/

디렉토리 권한 의미

해석

• user (myaccount): rwx
  • ls (가능), cd (가능), 파일 생성/삭제 (가능)
• group (mygroup): r-x
  • ls (가능), cd (가능), 생성/삭제 (불가능)
• others: ---
  • 접근 자체 불가

7. 자주 사용하는 권한 숫자

8. 권한과 소유자 변경 (필수 명령어)

권한이나 소유자를 변경할 때는 주로 두 가지 명령어를 사용합니다.

1. 대상의 권한 변경 (chmod)

• chmod 755 file.txt (숫자 방식: 소유자 rwx, 나머지는 r-x)
• chmod u+x file.txt (기호 방식: 소유자(u)에게 실행(x) 권한 추가)

2. 대상의 소유자/그룹 변경 (chown)

• chown myaccount file.txt (소유자 변경)
• chown myaccount:mygroup file.txt (소유자와 그룹 동시 변경)
• 보통 소유권을 넘기는 작업은 보안상 슈퍼 유저 권한이 필요하여 보통 sudo와 함께 사용합니다.

9. 절대 권력자: root 계정과 sudo

• root 계정: 시스템의 모든 권한을 가진 최고 관리자입니다. 앞서 설명한 rwx 권한을 무시하고 어떤 파일이든 읽고 쓰고 실행할 수 있습니다.
• sudo 명령어: 일반 사용자가 일시적으로 root의 권한을 빌려 올 때 사용합니다. (예: sudo chown ...)

10. 실무 권한 에러 해결 (Troubleshooting)

1. "Permission denied" 에러가 날 때 확인법

• 내가 이 파일의 소유자(user)인가? 아니면 그룹(group)에 속해있는가?
• 디렉토리에 진입(cd)하거나 안의 파일을 읽으려 할 때, 해당 디렉토리에 실행(x) 권한이 있는지 확인해보세요. (디렉토리는 x가 있어야 접근 가능합니다)

2. 웹 서버(Nginx, Apache) 사용 시 403 Forbidden

• 사용자가 만든 파일을 웹 서버가 읽지 못해서 발생합니다. 해당 프로젝트 폴더의 소유자를 웹 서버 사용자인 www-data(또는 nginx 계정 권한)로 맞추거나, 다른 사용자(others)에게 읽기/실행 권한을 주어야 합니다.

11. 핵심 요약

• 권한은 하나만 적용된다.
• 내가 소유자면 무조건 user 권한이 적용된다.
• 그룹이면 group 권한이 적용된다.
• 둘 다 아니면 others가 적용된다.
• 결국 핵심은 이것 하나: "나는 이 파일에서 user / group / others 중 어디에 속하는가?"

한줄 정리 Linux 권한은 "누가(user/group/others) 무엇을(r/w/x) 할 수 있는지"를 정의한다.

목차

1. Ollama란?
2. Windows 설치
3. 모델 설치 및 실행
4. CLI 주요 명령어
5. REST API 사용법
6. Python 라이브러리
7. GUI 앱 연동
8. 시스템 요구사항 및 GPU 가속

Ollama란?

Ollama는 로컬 환경에서 LLM(대형 언어 모델)을 손쉽게 실행할 수 있는 오픈소스 도구입니다.

• 인터넷 연결 없이 AI 모델 실행 가능
• ChatGPT와 유사한 채팅 인터페이스 제공
• REST API로 앱 연동 가능
• 완전 무료, 데이터가 외부로 나가지 않음

Windows 설치

1. 설치 파일 다운로드

공식 사이트에서 Windows 설치 파일을 받습니다.

https://ollama.com/download/windows

2. 설치 실행

OllamaSetup.exe 실행 → Install 클릭

💡 Windows Defender 경고가 뜨면 "추가 정보" → "실행" 클릭

설치 완료 후 시스템 트레이(우측 하단)에 라마 아이콘이 생성됩니다.

3. 설치 확인

PowerShell 또는 명령 프롬프트(cmd)를 열고 확인합니다.

ollama --version

모델 설치 및 실행

추천 모델 목록 (한국어 지원 포함)

모델 실행 (처음 실행 시 자동 다운로드)

ollama run gemma3:4b

다운로드 완료 후 >>> 프롬프트가 나타나면 바로 대화할 수 있습니다.

>>> 안녕하세요! 파이썬 리스트 컴프리헨션을 설명해줘

종료하려면 /bye 또는 Ctrl+D를 입력합니다.

CLI 주요 명령어

# 설치된 모델 목록 확인
ollama list

# 모델 다운로드만 (실행 없이)
ollama pull llama3.2:3b

# 모델 삭제
ollama rm gemma3:4b

# 현재 실행 중인 모델 확인
ollama ps

# 모델 상세 정보
ollama show gemma3:4b

# API 서버 수동 실행
ollama serve

REST API 사용법

Ollama를 설치하면 백그라운드에서 자동으로 API 서버가 실행됩니다.

• 기본 주소: http://localhost:11434
• 별도 설정 없이 바로 호출 가능

텍스트 생성 (generate)

curl http://localhost:11434/api/generate \
  -d '{
    "model": "gemma3:4b",
    "prompt": "하늘은 왜 파란가요?",
    "stream": false
  }'

채팅 (chat)

curl http://localhost:11434/api/chat \
  -d '{
    "model": "gemma3:4b",
    "messages": [
      {"role": "user", "content": "안녕하세요!"}
    ],
    "stream": false
  }'

응답 구조

{
  "model": "gemma3:4b",
  "message": {
    "role": "assistant",
    "content": "안녕하세요! 무엇을 도와드릴까요?"
  }
}

Python 라이브러리

설치

pip install ollama

기본 채팅

import ollama

response = ollama.chat(
    model="gemma3:4b",
    messages=[
        {"role": "system", "content": "당신은 친절한 AI 도우미입니다."},
        {"role": "user", "content": "파이썬 리스트 컴프리헨션을 설명해줘"}
    ]
)

print(response["message"]["content"])

멀티턴 대화

이전 메시지를 messages 리스트에 누적해서 넘기면 맥락이 유지됩니다.

import ollama

messages = []

def chat(user_input):
    messages.append({"role": "user", "content": user_input})
    response = ollama.chat(model="gemma3:4b", messages=messages)
    assistant_msg = response["message"]["content"]
    messages.append({"role": "assistant", "content": assistant_msg})
    return assistant_msg

print(chat("내 이름은 홍길동이야"))
print(chat("내 이름이 뭐라고 했지?"))  # 맥락 유지됨

스트리밍 출력

import ollama

stream = ollama.chat(
    model="gemma3:4b",
    messages=[{"role": "user", "content": "파이썬의 장점 5가지"}],
    stream=True
)

for chunk in stream:
    print(chunk["message"]["content"], end="", flush=True)
print()

단일 프롬프트 생성 (generate)

response = ollama.generate(
    model="gemma3:4b",
    prompt="하늘이 파란 이유를 한 문장으로 설명해줘",
    system="간결하게 답변하세요",
    options={"temperature": 0.7}
)

print(response["response"])

텍스트 임베딩 (벡터 생성)

RAG, 유사도 검색, 문서 분류 등에 활용합니다.

# 임베딩 전용 모델 먼저 설치 필요
# ollama pull nomic-embed-text

result = ollama.embeddings(
    model="nomic-embed-text",
    prompt="안녕하세요"
)

vector = result["embedding"]
print(f"벡터 차원 수: {len(vector)}")

비동기 (AsyncClient)

FastAPI, aiohttp 등 비동기 웹 프레임워크에서 사용합니다.

import asyncio
import ollama

async def main():
    client = ollama.AsyncClient()
    response = await client.chat(
        model="gemma3:4b",
        messages=[{"role": "user", "content": "안녕!"}]
    )
    print(response["message"]["content"])

asyncio.run(main())

모델 관리

import ollama

# 설치된 모델 목록
models = ollama.list()
for m in models["models"]:
    print(m["name"], m["size"])

# 모델 다운로드
ollama.pull("llama3.2:3b")

# 모델 정보 조회
info = ollama.show("gemma3:4b")
print(info["modelfile"])

# 모델 삭제
ollama.delete("gemma3:4b")

원격 서버 연결

import ollama

# 기본값은 http://localhost:11434
client = ollama.Client(host="http://192.168.1.100:11434")

response = client.chat(
    model="gemma3:4b",
    messages=[{"role": "user", "content": "테스트"}]
)
print(response["message"]["content"])

GUI 앱 연동

Open WebUI (추천)

ChatGPT와 유사한 웹 인터페이스를 제공합니다. Docker가 필요합니다.

docker run -d -p 3000:8080 `
  --add-host=host.docker.internal:host-gateway `
  -v open-webui:/app/backend/data `
  ghcr.io/open-webui/open-webui:main

설치 후 브라우저에서 http://localhost:3000 접속

VS Code 연동 (Continue 확장)

1. VS Code Marketplace에서 Continue 확장 설치
2. config.json에서 Ollama 모델 지정
3. 코드 자동완성, 채팅 등 GitHub Copilot처럼 사용 가능

시스템 요구사항 및 GPU 가속

권장 사양

GPU 가속

NVIDIA GPU가 있으면 설치 즉시 CUDA 가속이 자동 적용됩니다. 별도 설정이 필요 없습니다.

💡 CPU 대비 5~20배 빠른 응답 속도를 경험할 수 있습니다.

GPU 사용 여부를 확인하려면:

ollama ps

실행 중인 모델 옆에 GPU 사용량이 표시됩니다.

마무리

Ollama는 로컬 AI 환경을 구성하는 가장 빠른 방법입니다. Python 라이브러리와 REST API를 통해 다양한 애플리케이션에 LLM을 손쉽게 연동할 수 있고, Open WebUI를 통해 ChatGPT와 동일한 사용 경험도 얻을 수 있습니다.

참고: Ollama 공식 문서 | Ollama GitHub

로컬 환경에서 LLM을 손쉽게 실행할 수 있는 Ollama의 모든 것을 정리했습니다.

목차

1. Ollama란?
2. 주요 기능 정리
3. 환경 구축 시 주의점
4. 환경 변수 전체 정리
5. Ollama vs vLLM 비교

1. Ollama란?

Ollama는 로컬 환경(내 컴퓨터)에서 대형 언어 모델(LLM)을 쉽게 실행할 수 있게 해주는 오픈소스 도구입니다.

클라우드 기반 AI(ChatGPT, Claude 등)는 인터넷을 통해 원격 서버에서 실행되지만, Ollama를 사용하면 인터넷 없이 내 PC나 서버에서 직접 AI 모델을 돌릴 수 있습니다.

주요 특징

• 로컬 실행 — 데이터가 외부로 나가지 않아 프라이버시 보호
• 간편한 설치 — 명령어 한 줄로 모델 다운로드 및 실행
• 다양한 모델 지원 — Llama 3, Mistral, Gemma, Qwen, Phi 등 수백 가지 모델
• OpenAI 호환 API — 기존 앱에 쉽게 통합 가능
• 무료 & 오픈소스 — 사용 비용 없음
• macOS / Windows / Linux 모두 지원

기본 사용법

# 모델 실행 (없으면 자동 다운로드)
ollama run llama3

# 모델 목록 확인
ollama list

# 백그라운드 서버 실행
ollama serve

한계

• 고성능 GPU/RAM 필요 — 큰 모델일수록 더 많은 하드웨어 요구
• 클라우드 최신 모델 수준은 아님 — GPT-4, Claude Opus 같은 최상위 모델은 로컬 실행 불가
• 초기 다운로드 — 모델 파일이 수 GB에 달함

2. 주요 기능 정리

2-1. 모델 관리

2-2. 모델 실행

ollama run llama3          # 대화형 실행
ollama run llama3 "질문"   # 단발성 질문
ollama run llama3:70b      # 특정 버전(태그) 지정

• 대화형 모드 — 터미널에서 채팅처럼 사용
• 파이프 입력 — echo "요약해줘" | ollama run llama3
• 멀티모달 — 이미지 입력 지원 모델 사용 가능 (예: llava)

2-3. REST API 서버

ollama serve 실행 시 로컬 HTTP API 자동 제공 (기본 포트: 11434)

# 텍스트 생성
POST http://localhost:11434/api/generate

# 채팅
POST http://localhost:11434/api/chat

# 임베딩 생성
POST http://localhost:11434/api/embeddings

# 모델 목록
GET  http://localhost:11434/api/tags

OpenAI 호환 엔드포인트도 지원 → 기존 OpenAI SDK 코드를 거의 그대로 사용 가능

2-4. Modelfile (커스텀 모델 생성)

Docker의 Dockerfile처럼, 모델을 커스터마이징할 수 있는 설정 파일입니다.

FROM llama3

# 시스템 프롬프트 설정
SYSTEM "당신은 한국어 전문 번역가입니다."

# 파라미터 조정
PARAMETER temperature 0.7
PARAMETER top_p 0.9
PARAMETER num_ctx 4096

ollama create my-model -f Modelfile

2-5. 지원 모델 (주요)

2-6. 외부 도구 연동

2-7. 하드웨어 가속

3. 환경 구축 시 주의점

3-1. 하드웨어 요구사항

RAM (가장 중요)

⚠️ RAM 부족 시 모델이 디스크로 스왑 → 속도 극단적으로 느려짐

GPU VRAM

VRAM ≥ 모델 크기(GB)  →  전체 GPU 실행 (빠름)
VRAM < 모델 크기      →  일부 CPU 분산 실행 (느려짐)
GPU 없음              →  CPU 전용 실행 (매우 느림)

디스크 공간

⚠️ 여러 모델 사용 시 수백 GB까지 증가 가능 → SSD 권장

3-2. 설치 환경별 주의점

Windows

✅ Windows 10/11 (64bit) 지원
⚠️ NVIDIA GPU 사용 시 → CUDA 드라이버 최신 버전 필수
⚠️ AMD GPU → ROCm이 Windows에서 불안정할 수 있음
⚠️ WSL2 환경에서 실행 시 GPU 인식 문제 발생 가능

macOS

✅ Apple Silicon (M1/M2/M3/M4) → Metal 가속, 성능 우수
⚠️ Intel Mac → CPU 실행만 가능, 속도 매우 느림
⚠️ macOS 11 Big Sur 이상 필요

Linux

✅ 가장 안정적인 환경
⚠️ NVIDIA → nvidia-driver + CUDA toolkit 사전 설치 필요
⚠️ AMD → ROCm 버전과 GPU 모델 호환성 확인 필수
⚠️ 방화벽 설정 확인 (포트 11434)

3-3. 네트워크 & 보안

# 기본값: 로컬에서만 접근 가능 (안전)
OLLAMA_HOST=127.0.0.1:11434

# 외부 허용 시 → 인증 없이 누구나 접근 가능!
OLLAMA_HOST=0.0.0.0:11434   # ⚠️ 위험

외부 노출 시 필수 조치:

• ✅ 방화벽으로 IP 화이트리스트 설정
• ✅ Nginx / Caddy로 리버스 프록시 + 인증 추가
• ✅ API Key 인증 레이어 별도 구성
• ✅ HTTPS 적용
• ❌ 포트를 그냥 공개하면 절대 안 됨

3-4. 모델 양자화(Quantization) 이해

Q2  → 매우 작음, 품질 낮음
Q4  → 균형 (일반적으로 권장) ✅
Q5  → 품질 좋음, 용량 큼
Q8  → 원본에 가까움, 매우 큰 용량
F16 → 원본, 전문 용도

ollama run llama3          # 기본 (최신 태그)
ollama run llama3:8b       # 8B 파라미터
ollama run llama3:8b-q4_0  # 8B + Q4 양자화 명시

⚠️ 태그 미지정 시 자동으로 특정 버전이 선택됨 → 의도치 않은 대용량 다운로드 주의

3-5. 자주 발생하는 문제

3-6. 구축 전 체크리스트

□ RAM 16GB 이상 확보 (7B 모델 기준)
□ 디스크 여유 공간 50GB 이상
□ GPU 드라이버 최신 버전 설치
□ 외부 접근 시 인증/방화벽 설정 계획
□ 모델 저장 경로 (용량 큰 드라이브) 지정
□ 운영 목적에 맞는 모델 & 양자화 수준 결정

4. 환경 변수 전체 정리

4-1. 서버 & 네트워크

OLLAMA_HOST=0.0.0.0:11434          # 외부 접근 허용
OLLAMA_HOST=192.168.1.100:11434    # 특정 IP 바인딩
OLLAMA_ORIGINS=https://myapp.com   # 특정 도메인만 허용
OLLAMA_PROXY=http://proxy:8080     # 프록시 경유

4-2. 모델 & 파일 경로

OLLAMA_MODELS=/mnt/ssd/ollama-models   # 대용량 드라이브로 변경
OLLAMA_MODELS=D:\ollama\models         # Windows 예시
OLLAMA_TMPDIR=/tmp/ollama              # 임시 파일 위치 지정

4-3. 성능 & 메모리

OLLAMA_NUM_PARALLEL=4          # 동시 4개 요청 처리
OLLAMA_MAX_LOADED_MODELS=2     # 최대 2개 모델 상주
OLLAMA_KEEP_ALIVE=10m          # 10분간 메모리 유지
OLLAMA_KEEP_ALIVE=-1           # 영구 메모리 유지
OLLAMA_KEEP_ALIVE=0            # 요청 후 즉시 메모리 해제
OLLAMA_MAX_VRAM=4000000000     # VRAM 4GB 제한

4-4. GPU 설정

CUDA_VISIBLE_DEVICES=0             # 첫 번째 GPU만 사용
CUDA_VISIBLE_DEVICES=0,1           # 0번, 1번 GPU 사용
ROCR_VISIBLE_DEVICES=0             # AMD GPU 0번 지정
OLLAMA_GPU_OVERHEAD=512000000      # GPU 메모리 512MB 예비
OLLAMA_CPU_ONLY=true               # CPU 전용 강제

4-5. 디버그 & 로깅

OLLAMA_DEBUG=1      # 상세 로그 출력
OLLAMA_NOPRUNE=1    # 캐시 삭제 방지

4-6. 설정 방법

Linux / macOS — systemd 영구 설정

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/mnt/ssd/models"
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=10m"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Windows — PowerShell 영구 설정

[System.Environment]::SetEnvironmentVariable(
  "OLLAMA_HOST", "0.0.0.0:11434", "User"
)
[System.Environment]::SetEnvironmentVariable(
  "OLLAMA_MODELS", "D:\ollama\models", "User"
)
# 설정 후 Ollama 재시작 필요

Docker Compose

services:
  ollama:
    image: ollama/ollama
    environment:
      - OLLAMA_HOST=0.0.0.0:11434
      - OLLAMA_MODELS=/root/.ollama/models
      - OLLAMA_NUM_PARALLEL=4
      - OLLAMA_KEEP_ALIVE=10m
      - OLLAMA_MAX_LOADED_MODELS=2
    volumes:
      - ollama_data:/root/.ollama

4-7. 상황별 추천 설정

개인 PC (RAM 16GB, GPU 8GB)

OLLAMA_NUM_PARALLEL=1
OLLAMA_MAX_LOADED_MODELS=1
OLLAMA_KEEP_ALIVE=5m

팀 서버 (RAM 64GB, GPU 24GB)

OLLAMA_NUM_PARALLEL=4
OLLAMA_MAX_LOADED_MODELS=3
OLLAMA_KEEP_ALIVE=30m
OLLAMA_HOST=0.0.0.0:11434

메모리 절약 모드

OLLAMA_MAX_LOADED_MODELS=1
OLLAMA_KEEP_ALIVE=0       # 사용 후 즉시 메모리 해제
OLLAMA_NUM_PARALLEL=1

디버깅 / 문제 해결

OLLAMA_DEBUG=1
OLLAMA_CPU_ONLY=true      # GPU 문제 우회

5. Ollama vs vLLM 비교

5-1. 한눈에 보기

5-2. 아키텍처 차이

Ollama

사용자 → Ollama 서버 → llama.cpp 엔진 → 모델 실행
                          ↓
                    CPU / GPU 혼합 실행 가능
                    양자화(Q4 등) 기본 지원

vLLM

사용자 → vLLM 서버 → PagedAttention 엔진 → GPU 실행
                          ↓
                    GPU VRAM 최적화 특화
                    FP16 / BF16 정밀도 중심

핵심 차이: Ollama는 llama.cpp 기반, vLLM은 자체 PagedAttention 기술 기반

5-3. 주요 기능 비교

5-4. 지원 모델 형식

5-5. 설치 및 실행 비교

Ollama

# 설치 (한 줄)
curl -fsSL https://ollama.com/install.sh | sh

# 실행
ollama run llama3

vLLM

# 설치
pip install vllm

# CUDA, Python 버전 호환성 확인 필요
# NVIDIA GPU 필수

# 실행
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3-8B-Instruct \
  --tensor-parallel-size 2

5-6. 하드웨어 요구사항

5-7. 언제 무엇을 쓸까?

✅ Ollama를 선택할 때

• 개인 PC / 노트북에서 실행
• Windows 또는 Mac 환경
• 빠른 프로토타이핑, 간단한 테스트
• CPU 또는 저사양 GPU 환경
• 초보자, 간단한 설치 원할 때
• 소규모 팀 내부 사용

✅ vLLM을 선택할 때

• 프로덕션 서비스 배포
• 고트래픽, 다수 동시 사용자
• NVIDIA GPU 서버 보유
• 최대 성능 / 처리량이 필요할 때
• LoRA, AWQ 등 고급 기능 필요
• MLOps 파이프라인 구축

5-8. 함께 사용하는 패턴

개발 단계  →  Ollama (빠른 테스트)
           ↓
프로덕션   →  vLLM (고성능 서빙)

동일한 OpenAI 호환 API 구조이므로
코드 변경 최소화로 전환 가능 ✅

마무리 요약

Ollama  =  쉽고 빠르게, 어디서든, 누구나
vLLM    =  빠르고 무겁게, Linux GPU 서버에서, 프로덕션용

jQuery 기반의 강력한 트리 UI 플러그인 zTree의 설치부터 고급 활용까지 한 번에 정리합니다.

목차

1. zTree란?
2. 설치 및 기본 세팅
3. 데이터 구조
4. setting 옵션 완전 정복
5. 콜백(Callback) 이벤트
6. 체크박스 / 라디오 모드
7. Ajax 동적(지연) 로딩
8. 노드 편집 및 드래그 앤 드롭
9. API 메서드 총정리
10. 커스텀 아이콘 & 스타일
11. 실전 예제 — 파일 탐색기 UI
12. 마치며 — 대안 라이브러리

1. zTree란?

zTree는 jQuery 기반의 오픈소스 트리 UI 플러그인입니다. 2010년대 초반부터 국내 공공기관, 기업 인트라넷, 관리자 페이지에서 폭넓게 사용되어 왔습니다.

주요 특징

언제 사용하면 좋을까?

• 레거시 jQuery 기반 프로젝트
• 공공기관/기업 관리자 페이지
• 파일 탐색기, 조직도, 메뉴 구조, 카테고리 관리

2. 설치 및 기본 세팅

CDN 방식

<!-- jQuery (필수 의존성) -->
<script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>

<!-- zTree CSS -->
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/ztree@3.5.48/css/zTreeStyle/zTreeStyle.min.css">

<!-- zTree JS (all = core + excheck + exedit) -->
<script src="https://cdn.jsdelivr.net/npm/ztree@3.5.48/js/jquery.ztree.all.min.js"></script>

기능별로 분리 로딩도 가능합니다.

• jquery.ztree.core.min.js — 기본 트리
• jquery.ztree.excheck.min.js — 체크박스/라디오 (core 필요)
• jquery.ztree.exedit.min.js — 편집/드래그 (core 필요)

npm 방식

npm install ztree

import 'ztree/css/zTreeStyle/zTreeStyle.css';
import 'ztree';

기본 초기화

<!-- 트리 컨테이너: ul 태그에 ztree 클래스 필수 -->
<ul id="myTree" class="ztree"></ul>

<script>
const setting = {};

const zNodes = [
  { name: "루트", open: true, children: [
    { name: "자식 1" },
    { name: "자식 2" }
  ]}
];

// 초기화: $.fn.zTree.init(컨테이너, 설정, 데이터)
$.fn.zTree.init($("#myTree"), setting, zNodes);
</script>

3. 데이터 구조

zTree는 두 가지 데이터 구조를 지원합니다.

방식 A — 중첩(표준) 데이터

JSON 구조 그대로 children 배열로 계층을 표현합니다.

const zNodes = [
  {
    name: "회사",
    open: true,
    children: [
      {
        name: "개발팀",
        children: [
          { name: "프론트엔드" },
          { name: "백엔드" }
        ]
      },
      { name: "디자인팀" }
    ]
  }
];

방식 B — 단순(평면) 데이터 ⭐ 실무 추천

DB에서 조회한 평면 배열을 그대로 사용할 수 있어 실무에서 더 많이 쓰입니다.

const setting = {
  data: {
    simpleData: {
      enable: true,      // 단순 데이터 모드 활성화
      idKey: "id",       // 기본값 "id"
      pIdKey: "pId",     // 부모 참조 키, 기본값 "pId"
      rootPId: 0         // 루트 노드의 pId 값, 기본값 null
    }
  }
};

const zNodes = [
  { id: 1, pId: 0, name: "회사",      open: true },
  { id: 2, pId: 1, name: "개발팀",    open: true },
  { id: 3, pId: 1, name: "디자인팀" },
  { id: 4, pId: 2, name: "프론트엔드" },
  { id: 5, pId: 2, name: "백엔드" }
];

노드 주요 속성

4. setting 옵션 완전 정복

setting 객체는 view, data, async, check, edit, callback 6개 영역으로 나뉩니다.

4-1. view — 외관 설정

const setting = {
  view: {
    showIcon: true,           // 노드 아이콘 표시 여부 (기본 true)
    showLine: true,           // 연결선 표시 여부 (기본 true)
    showTitle: true,          // 마우스 오버 title 속성 표시
    selectedMulti: false,     // 다중 선택 허용 (기본 false)
    expandSpeed: "fast",      // 펼침 애니메이션 속도 ("", "slow", "normal", "fast")
    dblClickExpand: true,     // 더블클릭으로 펼치기 (기본 true)
    nameIsHTML: false,        // name을 HTML로 렌더링할지 여부
    fontCss: function(treeId, node) {
      // 노드별 인라인 스타일 반환
      return node.level === 0
        ? { "font-weight": "bold" }
        : {};
    },
    addDiyDom: function(treeId, node) {
      // 노드 DOM에 커스텀 요소 추가
      const id = node.tId + "_span";
      if ($("#" + id).children("span.badge").length === 0) {
        $("#" + id).after(`<span class="badge">${node.count || 0}</span>`);
      }
    }
  }
};

4-2. data — 데이터 매핑

const setting = {
  data: {
    simpleData: {
      enable: true,
      idKey: "id",
      pIdKey: "pId",
      rootPId: 0
    },
    key: {
      name: "label",       // name 키 이름을 "label"로 변경
      title: "tip",        // title 속성 키 이름 변경
      children: "nodes",   // children 키 이름을 "nodes"로 변경
      url: "link"          // url 키 이름 변경
    }
  }
};

data.key는 서버 API 응답 필드명이 다를 때 유용합니다.

5. 콜백(Callback) 이벤트

const setting = {
  callback: {
    // 노드 클릭
    onClick: function(event, treeId, treeNode) {
      console.log("클릭:", treeNode.name, treeNode.id);
    },

    // 노드 더블클릭
    onDblClick: function(event, treeId, treeNode) {
      console.log("더블클릭:", treeNode.name);
    },

    // 체크박스 상태 변경
    onCheck: function(event, treeId, treeNode) {
      console.log("체크:", treeNode.name, treeNode.checked);
    },

    // 노드 펼치기 전
    beforeExpand: function(treeId, treeNode) {
      return true; // false 반환 시 펼치기 중단
    },

    // 노드 펼친 후
    onExpand: function(event, treeId, treeNode) {
      console.log("펼침:", treeNode.name);
    },

    // 노드 접은 후
    onCollapse: function(event, treeId, treeNode) {
      console.log("접힘:", treeNode.name);
    },

    // Ajax 로딩 성공 후
    onAsyncSuccess: function(event, treeId, treeNode, msg) {
      console.log("로딩 완료:", treeNode.name);
    },

    // Ajax 로딩 실패
    onAsyncError: function(event, treeId, treeNode, XMLHttpRequest, textStatus, errorThrown) {
      console.error("로딩 실패:", textStatus);
    },

    // 노드 추가 후
    onNodeCreated: function(event, treeId, treeNode) {
      console.log("노드 생성:", treeNode.name);
    }
  }
};

6. 체크박스 / 라디오 모드

체크박스 기본 설정

const setting = {
  check: {
    enable: true,                 // 체크박스 활성화
    chkStyle: "checkbox",         // "checkbox" 또는 "radio"
    chkboxType: {
      "Y": "ps",   // 체크 시: p(부모 연동), s(자식 연동)
      "N": "ps"    // 해제 시: p(부모 연동), s(자식 연동)
    }
    // 연동 옵션: "p" 부모만, "s" 자식만, "ps" 둘 다, "" 연동 없음
  }
};

체크박스 연동 옵션 정리

체크된 노드 가져오기

const treeObj = $.fn.zTree.getZTreeObj("myTree");

// 체크된 노드만
const checkedNodes = treeObj.getCheckedNodes(true);

// 체크 안 된 노드만
const uncheckedNodes = treeObj.getCheckedNodes(false);

// ID 배열로 변환
const checkedIds = checkedNodes.map(node => node.id);
console.log(checkedIds); // [1, 3, 5]

프로그래밍으로 체크 제어

const treeObj = $.fn.zTree.getZTreeObj("myTree");

// 특정 노드 체크
const node = treeObj.getNodeByParam("id", 3);
treeObj.checkNode(node, true, true); // (노드, 체크여부, 자식연동)

// 전체 체크 / 해제
treeObj.checkAllNodes(true);
treeObj.checkAllNodes(false);

라디오 모드

const setting = {
  check: {
    enable: true,
    chkStyle: "radio",
    radioType: "all"  // "level": 같은 레벨끼리만, "all": 전체에서 하나만
  }
};

7. Ajax 동적(지연) 로딩

노드 클릭 시 서버에서 자식 데이터를 받아오는 방식입니다. 초기 로드 시간을 줄이고 대용량 트리에 유리합니다.

const setting = {
  async: {
    enable: true,
    url: "/api/tree/children",       // 서버 엔드포인트
    autoParam: ["id", "name=label"], // 요청에 포함할 노드 속성
    // "name=label"은 name 값을 label 파라미터명으로 전송
    otherParam: {                    // 추가 고정 파라미터
      token: "my-secret-token",
      type: "menu"
    },
    type: "post",                    // HTTP 메서드 (기본 "post")
    contentType: "application/x-www-form-urlencoded",
    dataFilter: function(treeId, parentNode, responseData) {
      // 서버 응답을 zTree 형식으로 가공
      return responseData.result || [];
    }
  }
};

// isParent: true 인 노드는 자식 없이 폴더처럼 표시되다가
// 클릭 시 Ajax 요청 발생
const zNodes = [
  { id: 1, pId: 0, name: "전체 메뉴", isParent: true, open: false }
];

서버 응답 예시 (Spring Boot)

@GetMapping("/api/tree/children")
public List<TreeNode> getChildren(@RequestParam Long id) {
    return treeService.findByParentId(id);
}

[
  { "id": 10, "pId": 1, "name": "서브메뉴 1", "isParent": false },
  { "id": 11, "pId": 1, "name": "서브메뉴 2", "isParent": true }
]

특정 노드만 Ajax 로딩 (조건부)

const setting = {
  async: {
    enable: true,
    url: function(treeId, node) {
      // 노드 타입별로 다른 API 호출
      return node.type === "folder"
        ? "/api/tree/folder"
        : "/api/tree/file";
    }
  }
};

8. 노드 편집 및 드래그 앤 드롭

편집 모드 활성화

const setting = {
  edit: {
    enable: true,            // 편집 기능 전체 활성화
    showRemoveBtn: true,     // 삭제 버튼 표시
    showRenameBtn: true,     // 이름 변경 버튼 표시
    removeTitle: "삭제",
    renameTitle: "이름 변경",

    drag: {
      enable: true,          // 드래그 앤 드롭 활성화
      autoExpandTrigger: true, // 드래그 중 자동 펼침
      prev: true,            // 노드 앞에 드롭 허용
      next: true,            // 노드 뒤에 드롭 허용
      inner: true            // 노드 안으로 드롭 허용 (자식으로)
    }
  },

  callback: {
    // 삭제 전 확인
    beforeRemove: function(treeId, treeNode) {
      return confirm(`"${treeNode.name}"을 삭제하시겠습니까?`);
    },

    // 이름 변경 완료 후
    onRename: function(event, treeId, treeNode, isCancel) {
      if (!isCancel) {
        // 서버에 변경 사항 저장
        $.post("/api/tree/rename", { id: treeNode.id, name: treeNode.name });
      }
    },

    // 드롭 전 유효성 검사
    beforeDrop: function(treeId, treeNodes, targetNode, moveType) {
      // 루트 노드는 이동 불가
      if (targetNode && targetNode.level === 0 && moveType === "inner") {
        return false;
      }
      return true;
    },

    // 드롭 완료 후
    onDrop: function(event, treeId, treeNodes, targetNode, moveType, isCopy) {
      console.log("이동된 노드:", treeNodes[0].name);
      console.log("이동 위치:", moveType); // "prev", "next", "inner"
    }
  }
};

9. API 메서드 총정리

// 트리 인스턴스 가져오기
const treeObj = $.fn.zTree.getZTreeObj("myTree");

노드 조회

// 루트 노드 목록
const roots = treeObj.getNodes();

// 조건으로 노드 검색 (단일)
const node = treeObj.getNodeByParam("id", 5);

// 조건으로 노드 검색 (복수)
const nodes = treeObj.getNodesByParam("type", "folder");

// 체크된 노드
const checked = treeObj.getCheckedNodes(true);

// 선택(하이라이트)된 노드
const selected = treeObj.getSelectedNodes();

// 부모 노드
const parent = treeObj.getNodeByTId(node.parentTId);

노드 추가

// 특정 부모 아래에 추가
const parent = treeObj.getNodeByParam("id", 1);
treeObj.addNodes(parent, [
  { id: 100, name: "새 노드 1" },
  { id: 101, name: "새 노드 2" }
]);

// 루트에 추가 (parent = null)
treeObj.addNodes(null, [{ id: 200, name: "루트 노드" }]);

// 특정 위치에 삽입 (index)
treeObj.addNodes(parent, 0, [{ id: 102, name: "맨 앞에 추가" }]);

노드 수정 및 삭제

// 이름 변경
const node = treeObj.getNodeByParam("id", 5);
node.name = "변경된 이름";
treeObj.updateNode(node);

// 삭제
treeObj.removeNode(node);

// 모든 자식 삭제
treeObj.removeChildNodes(parent);

펼치기 / 접기

// 전체 펼치기 / 접기
treeObj.expandAll(true);    // 전체 펼치기
treeObj.expandAll(false);   // 전체 접기

// 특정 노드
treeObj.expandNode(node, true, true, true);
// 인자: (노드, 펼침여부, 자식포함, 애니메이션)

선택 및 체크

// 선택 처리
treeObj.selectNode(node);
treeObj.cancelSelectedNode(node);

// 체크
treeObj.checkNode(node, true, true);   // 체크
treeObj.checkNode(node, false, true);  // 해제
treeObj.checkAllNodes(true);           // 전체 체크

트리 전체 제어

// 데이터 새로고침
$.fn.zTree.init($("#myTree"), setting, newData);

// 트리 인스턴스 제거
$.fn.zTree.destroy("myTree");

10. 커스텀 아이콘 & 스타일

이미지 아이콘 지정

const zNodes = [
  {
    id: 1, pId: 0, name: "서버",
    icon: "/icons/server.png",        // 기본 아이콘
    iconOpen: "/icons/server-on.png", // 펼쳐진 상태
    iconClose: "/icons/server-off.png" // 닫힌 상태
  }
];

CSS 클래스로 아이콘 변경

const setting = {
  view: {
    addDiyDom: function(treeId, treeNode) {
      const aObj = $("#" + treeNode.tId + "_a");
      // 기존 아이콘 숨기고 Font Awesome 등 적용
      aObj.find(".button").css("display", "none");
      if (treeNode.isParent) {
        aObj.prepend('<i class="fa fa-folder" style="margin-right:4px"></i>');
      } else {
        aObj.prepend('<i class="fa fa-file" style="margin-right:4px"></i>');
      }
    }
  }
};

노드별 CSS 스타일 동적 적용

const setting = {
  view: {
    fontCss: function(treeId, treeNode) {
      if (treeNode.disabled) {
        return { color: "#aaa", "text-decoration": "line-through" };
      }
      if (treeNode.level === 0) {
        return { "font-weight": "bold", color: "#333" };
      }
      return {};
    }
  }
};

CSS 커스터마이징 예시

/* 선택된 노드 배경색 변경 */
.ztree li a.curSelectedNode {
  background-color: #e8f4ff;
  border: 1px solid #b8d9f8;
  color: #1a73e8;
}

/* 호버 스타일 */
.ztree li a:hover {
  background-color: #f5f5f5;
}

/* 연결선 색상 변경 */
.ztree li span.button.switch {
  background-color: transparent;
}

11. 실전 예제 — 파일 탐색기 UI

체크박스 + Ajax 동적 로딩 + 노드 클릭 이벤트를 조합한 파일 탐색기 예제입니다.

<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="UTF-8">
  <title>파일 탐색기</title>
  <link rel="stylesheet" href="css/zTreeStyle/zTreeStyle.css">
  <style>
    body { font-family: sans-serif; display: flex; height: 100vh; margin: 0; }
    #sidebar { width: 280px; border-right: 1px solid #ddd; padding: 16px; overflow-y: auto; }
    #content { flex: 1; padding: 16px; }
    #selectedPath { color: #555; font-size: 14px; margin-bottom: 12px; }
    .ztree li a.curSelectedNode { background: #e8f4ff; border-color: #b8d9f8; }
  </style>
</head>
<body>

<div id="sidebar">
  <h3 style="margin-top:0">파일 탐색기</h3>
  <ul id="fileTree" class="ztree"></ul>
</div>
<div id="content">
  <div id="selectedPath">← 파일을 선택하세요</div>
  <div id="fileInfo"></div>
</div>

<script src="js/jquery.min.js"></script>
<script src="js/jquery.ztree.all.min.js"></script>
<script>
$(function () {
  const setting = {
    view: {
      showIcon: true,
      selectedMulti: false
    },
    data: {
      simpleData: { enable: true }
    },
    check: {
      enable: true,
      chkboxType: { "Y": "ps", "N": "ps" }
    },
    async: {
      enable: true,
      url: "/api/files/children",
      autoParam: ["id"],
      dataFilter: function (treeId, parentNode, res) {
        return res.data || [];
      }
    },
    callback: {
      onClick: function (event, treeId, node) {
        if (!node.isParent) {
          $("#selectedPath").text("선택: " + getFullPath(node));
          loadFileInfo(node.id);
        }
      },
      onCheck: function (event, treeId, node) {
        const checked = $.fn.zTree.getZTreeObj("fileTree").getCheckedNodes(true);
        console.log("체크된 파일 수:", checked.length);
      }
    }
  };

  const initNodes = [
    { id: 1, pId: 0, name: "루트",      isParent: true, open: true,
      icon: "img/folder.png" },
    { id: 2, pId: 1, name: "문서",      isParent: true },
    { id: 3, pId: 1, name: "사진",      isParent: true },
    { id: 4, pId: 2, name: "보고서.docx", isParent: false }
  ];

  $.fn.zTree.init($("#fileTree"), setting, initNodes);

  // 노드의 전체 경로 계산
  function getFullPath(node) {
    const parts = [node.name];
    let current = node;
    const treeObj = $.fn.zTree.getZTreeObj("fileTree");
    while (current.parentTId) {
      current = treeObj.getNodeByTId(current.parentTId);
      parts.unshift(current.name);
    }
    return parts.join(" / ");
  }

  // 파일 정보 로드
  function loadFileInfo(id) {
    $.get("/api/files/" + id, function (data) {
      $("#fileInfo").html(`
        <p><b>이름:</b> ${data.name}</p>
        <p><b>크기:</b> ${data.size} KB</p>
        <p><b>수정일:</b> ${data.updatedAt}</p>
      `);
    });
  }
});
</script>
</body>
</html>

12. 마치며 — 대안 라이브러리

zTree는 jQuery 생태계에서 매우 성숙한 라이브러리지만, 현대적인 프레임워크 환경에서는 아래 대안도 고려하세요.

정리

• 레거시 jQuery 프로젝트 → zTree가 여전히 최선
• 신규 React/Vue 프로젝트 → 각 프레임워크 생태계의 트리 컴포넌트 사용
• 공공기관 SI → zTree 요구사항이 많으므로 숙지해두면 유리

PostgreSQL 기준으로 작성되었습니다.

conn이란?

conn은 데이터베이스와의 연결 자체를 담당하는 객체입니다.

self.conn = connection.Connection().postgresql_connection()

DB와의 통로 역할만 하며, SQL을 직접 실행하는 기능은 없습니다.

cursor란?

cursor는 conn을 통해 실제 SQL을 실행하는 객체입니다.

conn   = 은행 입장 (문)
cursor = 창구 직원 (실제 업무 처리)

with self.conn.cursor() as cursor:
    cursor.execute("SELECT * FROM users")
    result = cursor.fetchall()

cursor 주요 메서드

cursor를 사용하는 이유

1. conn은 SQL 직접 실행 불가

self.conn.execute("SELECT * FROM users")          # ❌ 불가능
self.conn.cursor().execute("SELECT * FROM users") # ✅ 가능

2. 결과를 내부에 저장

cursor는 SQL 실행 후 결과를 내부에 임시 저장합니다.

DB 서버                cursor 내부
┌─────────┐           ┌──────────────┐
│ 100만 행 │  →SQL→   │ 결과 임시 저장 │ → fetchone()으로 하나씩
└─────────┘           └──────────────┘

cursor.execute("SELECT * FROM users")
cursor.fetchone()     # 1행 반환
cursor.fetchmany(100) # 100행 반환
cursor.fetchall()     # 전체 반환

3. 여러 작업을 독립적으로 처리

하나의 conn에서 여러 cursor를 동시에 운용할 수 있습니다.

cursor1 = self.conn.cursor()
cursor2 = self.conn.cursor()

cursor1.execute("SELECT * FROM users")   # 독립 실행
cursor2.execute("SELECT * FROM orders")  # 서로 영향 없음

result1 = cursor1.fetchall()
result2 = cursor2.fetchall()

4. 트랜잭션 관리

cursor 단위로 작업하고, conn으로 commit / rollback 합니다.

with self.conn.cursor() as cursor:
    try:
        cursor.execute("INSERT INTO users VALUES (%s)", ("Alice",))
        cursor.execute("INSERT INTO orders VALUES (%s)", (1,))
        self.conn.commit()    # 둘 다 성공 시 저장
    except:
        self.conn.rollback()  # 하나라도 실패 시 전부 취소

5. 메모리 효율

한 번에 모든 데이터를 가져오지 않고 필요한 만큼만 가져올 수 있습니다.

cursor.execute("SELECT * FROM users")  # 100만 행 조회

cursor.fetchone()      # ✅ 1행만 메모리에 올림
cursor.fetchmany(100)  # ✅ 100행만 메모리에 올림
cursor.fetchall()      # ⚠️ 100만 행 전부 메모리에 올림

with문과 함께 사용하는 이유

with 블록이 끝나면 자동으로 cursor.close()가 호출됩니다.

# with 없이
cursor = self.conn.cursor()
cursor.execute("SELECT * FROM users")
result = cursor.fetchall()
cursor.close()  # 직접 닫아야 함 ⚠️

# with 사용
with self.conn.cursor() as cursor:
    cursor.execute("SELECT * FROM users")
    result = cursor.fetchall()
# 자동으로 cursor.close() 호출 ✅

⚠️ with 사용 시 주의사항

cursor와 conn의 with 종료 시 동작이 다릅니다.

self.conn = connection.Connection().postgresql_connection()

with self.conn.cursor() as cursor:
    cursor.execute("SELECT * FROM users")
# cursor만 닫힘, conn은 유지 ✅

print(self.conn.closed)  # 0 = 열림 ✅

self.conn을 with로 직접 감싸면 블록 종료 시 연결이 닫혀 재사용이 불가능합니다.

with self.conn as conn:  # ⚠️ 블록 끝나면 self.conn이 닫힘
    pass

# 이후 self.conn 재사용 불가! ❌

권장 패턴

self.conn을 여러 메서드에서 재사용하는 경우, cursor만 with로 관리하는 것이 좋습니다.

class UserService:
    def __init__(self):
        self.conn = connection.Connection().postgresql_connection()

    def get_users(self):
        with self.conn.cursor() as cursor:      # cursor만 with로 관리
            cursor.execute("SELECT * FROM users")
            return cursor.fetchall()
        # cursor 닫힘, conn 유지 → 재사용 가능 ✅

    def insert_user(self, name):
        with self.conn.cursor() as cursor:      # 같은 conn 재사용
            cursor.execute("INSERT INTO users VALUES (%s)", (name,))
            self.conn.commit()

    def close(self):
        self.conn.close()                       # 모든 작업 종료 후 명시적으로 닫기

전체 흐름 요약

conn 생성
  │
  ├── cursor 생성 (with)
  │     ├── execute() : SQL 실행
  │     ├── fetch()   : 결과 가져오기
  │     └── close()   : 자동 호출 (with 종료 시)
  │
  ├── commit() / rollback()  : conn이 담당
  │
  └── conn.close()  : 모든 작업 종료 후 명시적 호출

롤(Role)이란?

PostgreSQL에서 롤(Role) 은 데이터베이스 접근 권한을 관리하는 개체입니다. 과거에는 사용자(User)와 그룹(Group)을 별도로 관리했지만, PostgreSQL은 이 둘을 롤 하나로 통합했습니다.

💡 핵심 개념: PostgreSQL에서는 모든 것이 롤입니다. 사용자도, 그룹도 모두 롤입니다.

롤의 두 가지 종류

LOGIN 속성 유무에 따라 역할이 나뉩니다.

-- 그룹 롤 생성 (로그인 불가)
CREATE ROLE developer;

-- 로그인 롤 생성 (로그인 가능)
CREATE ROLE alice WITH LOGIN PASSWORD 'password123';

-- CREATE USER = CREATE ROLE + LOGIN 축약 문법
CREATE USER bob WITH PASSWORD 'password456';

주요 속성(Attribute)

CREATE ROLE admin WITH LOGIN SUPERUSER CREATEDB CREATEROLE PASSWORD 'adminpass';

롤 확인 방법

psql 메타 명령

\du

                                   List of roles
 Role name |                         Attributes
-----------+------------------------------------------------------------
 alice     | Superuser, Create DB
 bob       |
 developer | Cannot login        ← 그룹 롤
 admin     | Create role, Create DB

Cannot login 이 표시되면 그룹 롤, 없으면 로그인 롤입니다.

pg_roles 뷰로 쿼리

SELECT
    rolname          AS 롤이름,
    rolcanlogin      AS 로그인가능,
    rolsuper         AS 슈퍼유저,
    rolcreatedb      AS DB생성,
    rolcreaterole    AS 롤생성,
    rolinherit       AS 권한상속
FROM pg_roles
WHERE rolname NOT LIKE 'pg_%'
ORDER BY rolcanlogin DESC;

• rolcanlogin = t → 로그인 롤
• rolcanlogin = f → 그룹 롤

로그인 롤 / 그룹 롤 분리 조회

-- 로그인 롤만 조회
SELECT rolname AS 로그인롤
FROM pg_roles
WHERE rolcanlogin = true
  AND rolname NOT LIKE 'pg_%';

-- 그룹 롤만 조회
SELECT rolname AS 그룹롤
FROM pg_roles
WHERE rolcanlogin = false
  AND rolname NOT LIKE 'pg_%';

그룹 롤을 로그인 롤에 부여하기

기본 문법

GRANT 그룹롤 TO 로그인롤;

실습 예시

-- 1. 그룹 롤 생성 및 권한 부여
CREATE ROLE developer;
GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO developer;

-- 2. 로그인 롤 생성
CREATE ROLE alice WITH LOGIN PASSWORD 'password123';
CREATE ROLE bob   WITH LOGIN PASSWORD 'password456';

-- 3. 그룹 롤을 로그인 롤에 부여
GRANT developer TO alice;
GRANT developer TO alice, bob;  -- 여러 명에게 한번에 부여

INHERIT 여부에 따른 동작 차이

-- ✅ INHERIT (기본값): 권한 자동 상속
CREATE ROLE alice WITH LOGIN INHERIT;
GRANT developer TO alice;
-- alice로 로그인하면 developer 권한이 자동으로 활성화

-- ⚠️ NOINHERIT: 수동으로 롤 전환 필요
CREATE ROLE alice WITH LOGIN NOINHERIT;
GRANT developer TO alice;
SET ROLE developer;  -- 수동 전환
RESET ROLE;          -- 원래 롤로 복귀

멤버십 확인

SELECT
    r.rolname  AS 그룹롤,
    m.rolname  AS 멤버롤
FROM pg_roles r
JOIN pg_auth_members am ON am.roleid = r.oid
JOIN pg_roles m         ON m.oid = am.member;

  그룹롤   | 멤버롤
-----------+--------
 developer | alice
 developer | bob

롤 회수

REVOKE developer FROM alice;
REVOKE developer FROM alice, bob;  -- 여러 명에게서 한번에 회수

그룹 롤을 부여할 수 있는 롤

모든 로그인 롤이 GRANT를 실행할 수 있는 것은 아닙니다. 다음 세 가지 경우에만 그룹 롤을 다른 롤에게 부여할 수 있습니다.

1. SUPERUSER

CREATE ROLE admin WITH LOGIN SUPERUSER PASSWORD 'adminpass';
-- 모든 롤을 제한 없이 부여 가능

2. CREATEROLE

CREATE ROLE manager WITH LOGIN CREATEROLE PASSWORD 'managerpass';
-- 그룹 롤을 다른 롤에게 부여 가능

⚠️ PostgreSQL 16부터 변경사항

• 16 이전: CREATEROLE이 있으면 모든 롤 부여 가능
• 16 이후: CREATEROLE이 있어도 본인이 속한 롤만 부여 가능 (보안 강화)

3. WITH ADMIN OPTION

-- alice에게 developer 롤을 부여할 수 있는 권한까지 위임
GRANT developer TO alice WITH ADMIN OPTION;

-- 이제 alice도 developer 롤을 다른 사람에게 부여 가능
GRANT developer TO bob;    -- ✅ 가능
GRANT developer TO carol;  -- ✅ 가능

WITH ADMIN OPTION의 핵심: "해당 롤 하나에만" 적용

WITH ADMIN OPTION은 부여받은 그 롤 하나에 대해서만 다른 사람에게 줄 수 있는 권한입니다.

GRANT developer TO alice WITH ADMIN OPTION;
-- designer, devops는 ADMIN OPTION 없음

-- alice로 로그인 후...
GRANT developer TO bob;   -- ✅ 가능 (admin option 있음)
GRANT designer  TO bob;   -- ❌ 불가 (admin option 없음)
GRANT devops    TO bob;   -- ❌ 불가 (admin option 없음)

여러 롤에 각각 부여하는 것도 가능합니다.

GRANT developer TO alice WITH ADMIN OPTION;
GRANT designer  TO alice WITH ADMIN OPTION;

GRANT developer TO bob;   -- ✅ 가능
GRANT designer  TO bob;   -- ✅ 가능
GRANT devops    TO bob;   -- ❌ 불가

ADMIN OPTION 확인

SELECT
    r.rolname        AS 그룹롤,
    m.rolname        AS 멤버롤,
    am.admin_option  AS 어드민권한
FROM pg_auth_members am
JOIN pg_roles r ON r.oid = am.roleid
JOIN pg_roles m ON m.oid = am.member;

  그룹롤   | 멤버롤 | 어드민권한
-----------+--------+-----------
 developer | alice  | t    ← alice는 developer를 남에게 부여 가능
 developer | bob    | f    ← bob은 부여 불가

세 가지 비교

💡 최소 권한 원칙: 가능하면 WITH ADMIN OPTION을 사용하는 것이 가장 안전합니다.

전체 구조 요약

롤(Role)
├── 로그인 롤 (LOGIN O) : 실제 DB 접속 계정
└── 그룹 롤  (LOGIN X) : 권한 묶음

그룹 롤 부여 가능한 롤
├── SUPERUSER          → 제한 없이 모든 롤 부여 가능
├── CREATEROLE         → 본인이 속한 롤만 부여 가능 (PG16+)
└── WITH ADMIN OPTION  → 해당 특정 그룹 롤만 부여 가능

실무에서 사용하던 DB/서비스 연결 모듈을 SOLID 원칙에 맞게 단계적으로 개선한 과정을 정리합니다.

개요

Airflow 기반 데이터 파이프라인에서 사용하던 connection.py는 하나의 Connection 클래스가 Hive, PostgreSQL, Oracle, Redis, SFTP 등 모든 서비스 연결을 담당하고 있었습니다. 기능은 동작했지만, 확장하거나 유지보수할수록 코드가 점점 복잡해지는 문제가 있었습니다.

이를 SOLID 원칙 기준으로 5단계에 걸쳐 개선했습니다.

1. _resolve_config_path 분리 (SRP — 단일 책임 원칙)

기존 코드

def _load_config(self, filename):
    config = configparser.ConfigParser()
    config_path = os.path.join(CONF_DIR, filename)
    if not os.path.exists(config_path):
        local_path = os.path.join(
            os.path.dirname(os.path.dirname(os.path.abspath(__file__))), 'cfg', filename
        )
        if os.path.exists(local_path):
            config_path = local_path
        else:
            raise FileNotFoundError(f"Configuration file not found: {config_path}")
    config.read(config_path)
    return config

개선된 코드

def _resolve_config_path(self, filename: str) -> str:
    """
    설정 파일의 실제 경로를 탐색하여 반환합니다.
    1순위: 운영 경로 (CONF_DIR)
    2순위: 로컬 경로 (테스트 환경 폴백)
    """
    primary = os.path.join(CONF_DIR, filename)
    if os.path.exists(primary):
        return primary

    fallback = os.path.join(
        os.path.dirname(os.path.dirname(os.path.abspath(__file__))), 'cfg', filename
    )
    if os.path.exists(fallback):
        return fallback

    raise FileNotFoundError(f"Configuration file not found: {primary}")

def _load_config(self, filename: str):
    """지정된 파일명으로 설정 파일을 파싱하여 반환합니다."""
    config = configparser.ConfigParser()
    config.read(self._resolve_config_path(filename))
    return config

왜 이렇게 개선해야 하는가?

_load_config는 원래 하나의 메서드에서 "경로 탐색" 과 "파일 파싱" 두 가지를 동시에 처리하고 있었습니다. SRP는 클래스/함수가 하나의 이유만으로 변경되어야 한다고 말합니다.

• 운영 경로 전략이 바뀌면 → _resolve_config_path만 수정
• 파싱 방식이 바뀌면 → _load_config만 수정

두 책임을 분리함으로써 각 메서드의 변경 이유가 명확해집니다.

2. ConfigLoader.get_config() 통합 (OCP — 개방/폐쇄 원칙)

기존 코드

def get_sftp_config(self):
    config = self._load_config('sftp.conf')
    return config[self.env]

def get_postgresql_config(self):
    config = self._load_config('postgresql.conf')
    return config[self.env]

def get_oracle_config(self):
    config = self._load_config('oracle.conf')
    return config[self.env]

def get_redis_cluster_config(self):
    config = self._load_config('redis_cluster.conf')
    return config[self.env]

def get_hive_config(self):
    config = self._load_config('hive.conf')
    return config[self.env]

개선된 코드

def get_config(self, service_name: str):
    """
    서비스명에 해당하는 환경 설정 섹션을 반환합니다.
    새 서비스 추가 시 {service_name}.conf 파일만 추가하면 됩니다.
    """
    return self._load_config(f'{service_name}.conf')[self.env]

사용 측 코드도 일관된 방식으로 통일됩니다.

# 변경 전
cfg = self.loader.get_sftp_config()
cfg = self.loader.get_postgresql_config()

# 변경 후
cfg = self.loader.get_config('sftp')
cfg = self.loader.get_config('postgresql')

왜 이렇게 개선해야 하는가?

OCP는 "확장에는 열려 있고, 수정에는 닫혀 있어야 한다" 는 원칙입니다.

기존 코드는 새 서비스(예: HDFS, ETT)를 추가할 때마다 ConfigLoader에 get_xxx_config() 메서드를 직접 추가(수정)해야 했습니다. 개선 후에는 {service_name}.conf 파일만 추가하면 get_config('hdfs')로 바로 사용할 수 있습니다. ConfigLoader를 수정할 필요가 없습니다.

3. BaseConnection 추상 인터페이스 도입 (LSP — 리스코프 치환 원칙)

기존 코드

class Connection:
    def __init__(self):
        self.loader = ConfigLoader()  # 구현체 직접 생성

    def close(self, connections):
        for name in connections:       # 문자열로 attribute 이름 전달
            conn = getattr(self, name, None)
            try:
                if conn is not None:
                    conn.close()
            except Exception:
                pass

개선된 코드

from abc import ABC, abstractmethod

class BaseConnection(ABC):
    """모든 연결 클래스의 추상 기반 클래스."""

    @abstractmethod
    def connect(self):
        """연결 객체를 생성하여 반환합니다."""
        ...

# 연결 해제는 모듈 수준 독립 함수로 분리
def close_connections(*conns) -> None:
    """서비스와 무관한 범용 연결 해제 함수."""
    for conn in conns:
        if conn is None:
            continue
        try:
            conn.close()
        except Exception:
            pass

사용 측 코드 변화:

# 변경 전 — 문자열로 attribute 이름 전달 (동작 보장 불가)
connection.Connection().close(["conn_oracle", "rc11"])

# 변경 후 — 연결 객체를 직접 전달 (타입 안전)
connection.close_connections(self.conn_oracle, self.rc11)

왜 이렇게 개선해야 하는가?

LSP는 "서브타입은 언제나 기반 타입으로 교체할 수 있어야 한다" 는 원칙입니다.

BaseConnection을 도입하면:

• 모든 연결 클래스가 connect() 구현을 강제받아 인터페이스 일관성을 보장합니다.
• OracleConnection, HiveConnection 등이 BaseConnection 타입으로 다형적으로 사용될 수 있습니다.

또한 기존 close(connections)는 문자열 attribute 이름 리스트를 받는 위험한 방식이었습니다. close_connections(*conns)는 연결 객체를 직접 받으므로 런타임 오류 없이 안전하게 동작합니다.

4. Constructor Injection 적용 (DIP — 의존성 역전 원칙)

기존 코드

class Connection:
    def __init__(self):
        self.loader = ConfigLoader()  # 구현체에 강하게 결합

개선된 코드

from typing import Optional

class _BaseServiceConnection(BaseConnection):
    def __init__(self, loader: Optional[ConfigLoader] = None):
        self.loader = loader or ConfigLoader()  # 외부 주입 or 기본값

왜 이렇게 개선해야 하는가?

DIP는 "고수준 모듈이 저수준 모듈에 의존해서는 안 된다" 는 원칙입니다.

기존 코드는 Connection 내부에서 ConfigLoader()를 직접 생성해 구현체에 강하게 결합되어 있었습니다.

Constructor Injection을 적용하면:

• 테스트 시 Mock ConfigLoader를 주입해 실제 파일 시스템 없이 단위 테스트 가능
• 확장 시 다른 설정 소스(환경변수, AWS Parameter Store 등)로 교체 가능

# 테스트 코드 예시
mock_loader = MockConfigLoader()
conn = OracleConnection(loader=mock_loader)  # 실제 설정 파일 불필요

5. 서비스별 클래스 분리 (SRP — 단일 책임 원칙)

기존 코드

class Connection:
    """5가지 서비스 연결을 모두 담당하는 단일 클래스"""

    def sftp_connection(self): ...
    def redis_cluster_connection(self, cluster_section): ...
    def postgresql_connection(self): ...
    def oracle_connection(self): ...
    def hive_connection(self): ...

개선된 코드

class _BaseServiceConnection(BaseConnection):
    """공통 기반: loader, _get_aes 공유"""
    ...

class SftpConnection(_BaseServiceConnection):
    def connect(self): ...   # SFTP만 책임

class RedisClusterConnection(_BaseServiceConnection):
    def connect(self, cluster_section: str = 'rc00'): ...   # Redis만 책임

class PostgresqlConnection(_BaseServiceConnection):
    def connect(self): ...   # PostgreSQL만 책임

class OracleConnection(_BaseServiceConnection):
    def connect(self): ...   # Oracle만 책임

class HiveConnection(_BaseServiceConnection):
    def connect(self): ...   # Hive만 책임

사용 측 코드:

# 직접 서비스 클래스를 사용
self.conn_oracle = connection.OracleConnection().connect()
self.rc11        = connection.RedisClusterConnection().connect('rc11')

# 해제
connection.close_connections(self.conn_oracle, self.rc11)

왜 이렇게 개선해야 하는가?

기존 Connection 클래스는 5가지 서비스의 연결 로직을 모두 보유하고 있었습니다. Oracle 연결 방식이 바뀌면 Connection 전체를 수정해야 하고, 이는 SFTP나 Hive 연결에도 영향을 줄 위험이 있습니다.

분리 후에는:

• 변경 영향 범위 최소화: OracleConnection만 수정하면 됩니다.
• 가독성 향상: 클래스 이름만 봐도 어떤 서비스인지 명확합니다.
• 테스트 용이성: 서비스별로 독립적인 단위 테스트 작성 가능합니다.

최종 클래스 구조

BaseConnection (ABC)                  ← 순수 인터페이스 계약
└── _BaseServiceConnection            ← 프로젝트 공통 기반 (loader, AES)
    ├── SftpConnection
    ├── RedisClusterConnection
    ├── PostgresqlConnection
    ├── OracleConnection
    └── HiveConnection

close_connections(*conns)             ← 모듈 수준 범용 연결 해제 함수
ConfigLoader                          ← 환경별 설정 파일 로드

개선 전/후 비교 요약

코드를 짤 때 단순히 "동작하는 코드"를 넘어서, 변경에 강하고 확장하기 쉬운 구조를 만드는 방법을 정리했습니다.

📌 목차

1. 설계 & 구조 기본 원칙
2. 객체지향 4대 핵심 개념
3. SOLID 원칙
4. 실전 예제: OCP 완전 정복

1. 설계 & 구조 기본 원칙

SRP — 단일 책임 원칙

하나의 함수/클래스는 하나의 일만 한다.

# ❌ 나쁜 예시 — DB 저장 + 이메일 전송 + 로그 출력을 한 함수가 다 함
def handle_user(user):
    db.save(user)
    email.send(user.email, "환영합니다!")
    print(f"[LOG] 유저 생성: {user.name}")

# ✅ 좋은 예시 — 역할별로 분리
def save_user(user):
    db.save(user)

def send_welcome_email(user):
    email.send(user.email, "환영합니다!")

def log_user_created(user):
    print(f"[LOG] 유저 생성: {user.name}")

한 함수가 여러 역할을 하면, 하나를 고칠 때 다른 기능이 망가질 수 있다.

DRY — Don't Repeat Yourself

같은 로직이 두 곳 이상에 있으면, 반드시 추상화하라.

// ❌ 할인가 계산이 두 곳에서 따로 구현됨
const priceA = originalA * 0.9;
const priceB = originalB * 0.9;

// ✅ 함수로 추출
const applyDiscount = (price, rate = 0.9) => price * rate;

const priceA = applyDiscount(originalA);
const priceB = applyDiscount(originalB);

나중에 할인율이 바뀌면? DRY를 지키면 한 곳만 수정하면 된다.

KISS — Keep It Simple, Stupid

동작하는 가장 단순한 방법을 선택하라.

# ❌ 불필요하게 복잡한 홀짝 판별
def is_even(n):
    return True if len([i for i in range(n) if i % 2 == 0]) == n // 2 + (1 if n % 2 == 0 else 0) else False

# ✅ 단순하게
def is_even(n):
    return n % 2 == 0

복잡한 코드 = 버그가 숨을 공간이 많아진다. 단순함이 곧 안정성이다.

YAGNI — You Aren't Gonna Need It

지금 당장 필요하지 않은 기능은 만들지 마라.

# ❌ "나중에 쓸 수도 있으니까..." 하고 미리 만든 기능들
class UserService:
    def get_user(self): ...
    def export_to_csv(self): ...          # 아직 요구사항 없음
    def send_push_notification(self): ... # 아직 요구사항 없음
    def generate_report(self): ...        # 아직 요구사항 없음

# ✅ 지금 필요한 것만
class UserService:
    def get_user(self): ...

미리 만든 코드는 유지보수 비용만 늘린다. 요구사항은 항상 바뀐다.

낮은 결합도 — High Cohesion / Low Coupling

모듈은 서로를 최대한 몰라야 한다.

// ❌ 강한 결합 — 결제 수단이 OrderService 안에 직접 박혀 있음
class OrderService {
  checkout(order) {
    const result = new KakaoPay().pay(order.amount);
    new NaverEmail().send(order.user, "주문 완료");
  }
}

// ✅ 느슨한 결합 — 의존성 주입
class OrderService {
  constructor(paymentGateway, notifier) {
    this.paymentGateway = paymentGateway;
    this.notifier = notifier;
  }

  checkout(order) {
    this.paymentGateway.pay(order.amount);
    this.notifier.send(order.user, "주문 완료");
  }
}

// 카카오페이 → 토스페이로 교체해도 OrderService 코드는 안 바뀜
const service = new OrderService(new TossPay(), new NaverEmail());

결합도가 높으면 A를 바꿀 때 B, C, D도 줄줄이 바꿔야 한다.

2. 객체지향 4대 핵심 개념

캡슐화 (Encapsulation)

내부 구현은 숨기고, 필요한 것만 외부에 공개한다.

# ❌ 누구나 잔액을 직접 조작 가능
class BankAccount:
    balance = 0

account = BankAccount()
account.balance = -99999  # 마음대로 조작 가능 💀

# ✅ 검증된 메서드로만 접근
class BankAccount:
    def __init__(self):
        self.__balance = 0  # private

    def deposit(self, amount):
        if amount > 0:
            self.__balance += amount

    def withdraw(self, amount):
        if amount > self.__balance:
            raise Exception("잔액 부족")
        self.__balance -= amount

    def get_balance(self):
        return self.__balance

상속 (Inheritance)

공통 기능을 부모에 두고, 자식이 물려받아 확장한다.

class Animal:
    def __init__(self, name):
        self.name = name

    def breathe(self):
        print(f"{self.name}이 숨을 쉰다")

class Dog(Animal):
    def bark(self):
        print(f"{self.name}이 짖는다: 멍멍!")

class Cat(Animal):
    def meow(self):
        print(f"{self.name}이 운다: 야옹!")

dog = Dog("바둑이")
dog.breathe()  # 부모 메서드 사용 가능
dog.bark()

⚠️ 상속은 남용하면 독이다. "is-a" 관계일 때만 사용할 것.

• ✅ Dog is a Animal → 상속 적절
• ❌ Car is a Engine → 상속 부적절 → 조합(Composition) 을 사용

다형성 (Polymorphism)

같은 인터페이스로 다른 동작을 한다.

class Shape:
    def area(self):
        raise NotImplementedError

class Circle(Shape):
    def __init__(self, r):
        self.r = r
    def area(self):
        return 3.14 * self.r ** 2

class Rectangle(Shape):
    def __init__(self, w, h):
        self.w, self.h = w, h
    def area(self):
        return self.w * self.h

# 어떤 도형이든 동일한 방식으로 처리 가능
shapes = [Circle(5), Rectangle(3, 4), Circle(2)]
for shape in shapes:
    print(shape.area())

if-else로 타입을 분기하는 코드가 보이면 → 다형성으로 바꿀 신호다.

추상화 (Abstraction)

복잡한 내부는 감추고, 단순한 인터페이스만 노출한다.

from abc import ABC, abstractmethod

class PaymentGateway(ABC):
    @abstractmethod
    def pay(self, amount: int) -> bool:
        pass

class KakaoPay(PaymentGateway):
    def pay(self, amount):
        print(f"카카오페이로 {amount}원 결제")
        return True

class TossPay(PaymentGateway):
    def pay(self, amount):
        print(f"토스페이로 {amount}원 결제")
        return True

# 사용하는 쪽은 내부 구현을 몰라도 된다
def checkout(gateway: PaymentGateway, amount: int):
    gateway.pay(amount)

3. SOLID 원칙

S — 단일 책임 원칙 (SRP)

클래스도 하나의 책임만 가진다. (위 내용 참고)

O — 개방-폐쇄 원칙 (OCP)

확장에는 열려 있고, 수정에는 닫혀 있어야 한다.

# ❌ 새 결제수단 추가할 때마다 이 함수를 수정해야 함
def process_payment(type, amount):
    if type == "kakao":
        ...
    elif type == "toss":
        ...
    elif type == "naver":  # 추가할 때마다 여기를 건드려야 함
        ...

# ✅ 새 결제수단은 클래스만 추가하면 됨 (기존 코드 수정 X)
class NaverPay(PaymentGateway):
    def pay(self, amount):
        print(f"네이버페이로 {amount}원 결제")

L — 리스코프 치환 원칙 (LSP)

자식 클래스는 부모 클래스를 완전히 대체할 수 있어야 한다.

# ❌ 위반 사례 — Rectangle을 상속했는데 동작이 깨짐
class Rectangle:
    def set_width(self, w): self.width = w
    def set_height(self, h): self.height = h
    def area(self): return self.width * self.height

class Square(Rectangle):
    def set_width(self, w):
        self.width = w
        self.height = w  # 정사각형이라 강제로 같게 만듦 💀

rect = Square()
rect.set_width(4)
rect.set_height(5)
print(rect.area())  # 25 출력 — Rectangle이라면 20이어야 함

부모 타입으로 써도 동일한 계약이 보장되어야 한다.

I — 인터페이스 분리 원칙 (ISP)

사용하지 않는 메서드를 구현하도록 강요하지 마라.

# ❌ 로봇은 밥을 안 먹는데 eat()을 구현해야 함
class Worker(ABC):
    @abstractmethod
    def work(self): pass
    @abstractmethod
    def eat(self): pass

class Robot(Worker):
    def work(self): print("일한다")
    def eat(self): pass  # 의미없는 구현 강요 💀

# ✅ 인터페이스를 분리
class Workable(ABC):
    @abstractmethod
    def work(self): pass

class Eatable(ABC):
    @abstractmethod
    def eat(self): pass

class Human(Workable, Eatable):
    def work(self): print("일한다")
    def eat(self): print("밥 먹는다")

class Robot(Workable):
    def work(self): print("일한다")

D — 의존성 역전 원칙 (DIP)

구체가 아닌 추상에 의존하라.

# ❌ 고수준(OrderService)이 저수준(MySQL)에 직접 의존
class OrderService:
    def __init__(self):
        self.db = MySQLDatabase()  # 특정 DB에 묶여버림

# ✅ 추상화에 의존 → DB를 바꿔도 OrderService는 그대로
class Database(ABC):
    @abstractmethod
    def save(self, data): pass

class MySQLDatabase(Database):
    def save(self, data): ...

class MongoDB(Database):
    def save(self, data): ...

class OrderService:
    def __init__(self, db: Database):  # 추상화에만 의존
        self.db = db

4. 실전 예제: OCP 완전 정복

OCP를 처음 접하면 "그럼 실제로 어떻게 호출해?"라는 의문이 생긴다. 전체 흐름을 보자.

from abc import ABC, abstractmethod

# 1. 추상 인터페이스 정의
class PaymentGateway(ABC):
    @abstractmethod
    def pay(self, amount: int) -> bool:
        pass

# 2. 각 결제수단 구현 (새 수단 추가 시 여기에만 클래스 추가)
class KakaoPay(PaymentGateway):
    def pay(self, amount):
        print(f"카카오페이로 {amount}원 결제")

class TossPay(PaymentGateway):
    def pay(self, amount):
        print(f"토스페이로 {amount}원 결제")

class NaverPay(PaymentGateway):
    def pay(self, amount):
        print(f"네이버페이로 {amount}원 결제")

# 3. 사용하는 쪽 — 구체 클래스를 전혀 모름
class OrderService:
    def __init__(self, gateway: PaymentGateway):
        self.gateway = gateway

    def checkout(self, amount):
        self.gateway.pay(amount)

# 4. 실제 호출 — 사용자 선택에 따라 동적으로 결정
GATEWAYS = {
    "kakao": KakaoPay,
    "toss":  TossPay,
    "naver": NaverPay,
}

def get_gateway(type: str) -> PaymentGateway:
    gateway_class = GATEWAYS.get(type)
    if not gateway_class:
        raise ValueError(f"지원하지 않는 결제수단: {type}")
    return gateway_class()

# 새 결제수단 추가 시 → GATEWAYS 딕셔너리에 한 줄만 추가하면 끝
user_choice = "naver"
service = OrderService(get_gateway(user_choice))
service.checkout(15000)  # 네이버페이로 15000원 결제

if-else 방식 vs OCP 방식 비교

OrderService는 NaverPay가 뭔지 전혀 모른다. pay()라는 메서드가 있다는 것만 알 뿐이다. 이게 추상화의 힘이다.

📐 전체 원칙 한눈에 보기

객체지향 설계
│
├── 기본 원칙
│   ├── SRP    → 하나의 함수/클래스는 하나의 일만
│   ├── DRY    → 중복 로직은 추상화로 제거
│   ├── KISS   → 항상 가장 단순한 방법을 선택
│   ├── YAGNI  → 지금 필요한 것만 만든다
│   └── 낮은 결합도 → 모듈은 서로를 최대한 모르게
│
├── 4대 개념
│   ├── 캡슐화  → 내부를 숨겨라
│   ├── 상속    → 공통을 물려받아라 (is-a 관계만)
│   ├── 다형성  → 같은 인터페이스, 다른 동작
│   └── 추상화  → 복잡함을 단순하게 노출
│
└── SOLID
    ├── S → 클래스는 하나의 책임만
    ├── O → 수정 말고 확장으로 해결
    ├── L → 자식은 부모를 완전히 대체 가능
    ├── I → 인터페이스는 작게 쪼개라
    └── D → 구체가 아닌 추상에 의존하라

💡 마치며

OOP는 "현실 세계를 코드로 모델링"하는 것이 목적이 아니다. 변경에 강하고 확장하기 쉬운 구조를 만드는 것이 진짜 목적이다.

SOLID 원칙들은 서로 연결되어 있다.

• SRP를 지키면 → 자연스럽게 결합도가 낮아진다
• OCP를 지키면 → DIP를 따르게 된다
• DIP를 지키면 → 테스트하기 쉬운 코드가 된다

원칙을 외우는 것보다, "이 코드를 나중에 바꿔야 한다면 얼마나 힘들까?" 를 항상 생각하는 습관이 더 중요하다.

📌 라우터란?

• 네트워크에서 패킷의 경로를 지정해주는 장비
• 패킷의 목적지 IP 주소를 확인하고, 라우팅 테이블 기반 최적 경로로 포워딩
• 원격지 네트워크 연결 시 필수 장비

🏗️ 라우터의 동작 방식과 역할

• 다양한 경로 정보 수집 → 최적 경로를 라우팅 테이블에 저장
• 패킷 도착 시 목적지 IP와 라우팅 테이블 비교 후 포워딩

🚀 라우터의 핵심 동작

1. 목적지 주소가 라우팅 테이블에 없으면 패킷 버림
2. 기존 2계층 헤더 제거 후 새로운 2계층 헤더 생성하여 전송

1️⃣ 경로 지정 (Routing)

✅ 경로 정보 획득 방법

• 다이렉트 커넥티드: IP 설정 시 인접 네트워크 정보 자동 획득
• 스태틱 라우팅: 관리자가 직접 경로 입력
• 다이나믹 라우팅: 라우터 간 경로 정보 자동 교환 (RIP, OSPF, BGP)

✅ 패킷 포워딩 과정

1. 목적지 IP와 라우팅 테이블 비교
2. 최적 경로 선택 후 전송
3. 경로 없을 시 패킷 드롭

2️⃣ 브로드캐스트 컨트롤

🚀 주요 기능

• 브로드캐스트/멀티캐스트 트래픽 차단
• 네트워크 성능 저하 방지
• 💡 스위치 vs 라우터: 스위치는 동일 네트워크 내 브로드캐스트 전파, 라우터는 브로드캐스트 도메인 분리

3️⃣ 프로토콜 변환

🔄 변환 과정

1. 도착한 패킷의 2계층 헤더 제거
2. 3계층 주소(IP) 확인 후 최적 경로 선택
3. 새로운 2계층 헤더 생성 및 전송

• 📢 서로 다른 네트워크 간 통신 가능!

🚀 라우팅 테이블 구성 요소

🔼 특징

• 롱기스트 프리픽스 매치: 가장 긴 서브넷 마스크 일치 경로 우선 선택
• 출발지 주소는 고려하지 않음

🔥 라우터의 경로 획득 방법

⚡ 라우팅 vs 스위칭

📌 스위치란?

스위치는 2계층 주소인 MAC 주소를 기반으로 동작하며, 네트워크 중간에서 패킷을 받아 필요한 곳에만 전달하는 네트워크의 중재자 역할을 합니다.

✅ 기본 동작

• 별다른 설정 없이 네트워크에 연결해도 MAC 주소 기반 패킷 전달 가능
• 네트워크를 논리적으로 분리하는 VLAN 기능
• 네트워크 루프 방지 기능인 STP(Spanning Tree Protocol)

🏗️ 스위치 동작 방식

스위치는 MAC 주소 테이블을 사용하여 통신합니다.
MAC 주소 테이블에는 단말의 MAC 주소와 해당 단말이 연결된 포트 정보가 저장됩니다.

📋 MAC 주소 테이블 예시

스위치는 패킷의 헤더에서 목적지 MAC 주소를 확인한 후, MAC 주소 테이블에서 해당 포트를 찾아 패킷을 전달합니다.

🔄 스위치의 3가지 동작 방식

1️⃣ 플러딩 (Flooding)

🚀 MAC 주소를 모를 때, 모든 포트로 패킷을 전송

• 스위치가 부팅되면 MAC 주소 테이블이 비어 있음
• 패킷이 들어오면 목적지 MAC 주소를 확인하지만, 정보가 없으면 모든 포트에 같은 패킷을 전송

2️⃣ 어드레스 러닝 (Address Learning)

📝 MAC 주소 테이블을 생성하고 유지하는 과정

• 패킷의 출발지 MAC 주소와 포트 정보를 기록
• 이를 통해 같은 네트워크에서 반복되는 플러딩을 방지

✅ 하지만!

• 브로드캐스트나 멀티캐스트 주소는 학습할 수 없음

3️⃣ 포워딩 / 필터링 (Forwarding / Filtering)

🔍 MAC 주소 테이블을 활용한 효율적인 패킷 전달

• 스위치는 도착지 MAC 주소를 MAC 테이블과 비교하여 일치하는 포트로만 패킷을 포워딩
• 동시에 다른 포트로는 전달하지 않음(필터링)

📢 즉!

• 유니캐스트 트래픽은 포워딩/필터링
• 브로드캐스트(Broadcast) 및 멀티캐스트(Multicast) 트래픽은 플러딩

🌎 VLAN (Virtual LAN)

VLAN은 물리적 배치와 관계없이 네트워크를 논리적으로 분리하는 기술입니다.

📌 VLAN을 사용하는 이유

• 브로드캐스트 트래픽 감소 → 성능 향상
• 보안 강화 → 특정 네트워크만 접근 가능
• 관리 용이 → 서비스별로 논리적 그룹화 가능

🛠️ VLAN 할당 방식

📢 VLAN 간 통신을 하려면?
→ 3계층 장비(라우터 또는 L3 스위치)가 필요!

🔄 STP (Spanning Tree Protocol)

STP는 네트워크 루프를 방지하는 프로토콜입니다.

📌 네트워크 루프란?
스위치가 MAC 주소 테이블을 갱신하는 과정에서 무한히 패킷이 전송되는 현상
→ 네트워크 장애 발생 🚨

📌 STP 동작 원리
1️⃣ 스위치 간 정보를 교환하여 네트워크의 트리를 생성
2️⃣ 루프가 감지되면 특정 포트를 차단(blocking)
3️⃣ 네트워크 변경이 감지되면 차단된 포트를 활성화

📢 BPDU(Bridge Protocol Data Unit) 패킷을 통해 스위치 간 정보 교환

✅ STP의 핵심 역할

• 루프 발생 시 자동으로 차단
• 네트워크 변경 감지 시 자동으로 복구

🔥 정리

유니캐스트

• 1대1 통신
• 출발지와 목적지가 1:1로 통신

  브로드 캐스트

• 1:모든 통신
• 동일 네트워크에 존재하는 모든 호스트가 목적

  멀티캐스트

• 1:그룹 통신
• 하나의 출발지에서 다수의 특정 목적지로 데이터 ㅈ너송

  애니캐스트

• 1대1 통신(목적지 동일 그룹 내 1개 호스트)
• 다수의 동일 그룹 중 가장 가까운 호스트에서 응답

구분은 출발지가 아니라 목적지 주소를 기준으로 구분한다.

BUM 트래픽

• B(Broadcast), U(Unkonwn Unicast), M(Multicatst)

언노운 유니캐스트는 목적지 주소는 명확히 명시되어있지만 네트워크 동작은 브로드캐스트와 같을때 스위치가 목적지에대한 주소를 학습 못한 상황에서 모든 포트로 전송함 BUM 트래픽이 많아지면 네트워크 성능이 저하됨

MAC(Media access Control) 주소

2계층에서 통신을 위해 네트워크 인터페이스에 할당된 고유 식별자

MAC 주소 : 48비트 16진수 12자리 00 | 00 | 00 | 00 | 00 | 00 | 앞의 24비트 = OUI -> IEEE가 제조사에 할당하는 부분 뒤의 24비트 = UAA -> 각 제조사에서 네트워크 구성 요소에 할당하는 부분

• MAC의 주소는 유일하지 않을 수 있음 동일 네트워크에서만 중복되지 않으면 됨

MAC 주소 동작

NIC는 자신의 주소를 가지고 있고 전기 신호가 들어오면 2계층에서 데이터 형태(패킷)으로 변환 내용을 확인하여 도착지 MAC 주소를 확인. 만약 도착지 MAC 주소가 자신이 갖고 있는 MAC 주소와 다르면 그 퍠킷 폐기. 처리해야 할 주소로 인지하면 패킷 정보를 상위 계층으로 넘겨준다.

• 상위 계층으로 갈 경우 NIC 자체적으로 패킷을 처리하는 것이 아닌 OS나 애플리케이션에서 처리해 시스템 부하가 작용한다.

• MAC 주소는 단말이 아닌 NIC에 종속된다. 단말은 NIC를 여러개 가질 수 있으므로 MAC 주소도 여러개 가질 수 잇음

IP 주소

2계층 물리 주소인 MAC 사용 3계층 논리 주소인 IP 주소를 사용

• 3계층 주소 특징
  1. 사용자가 변경 가능한 논리 주소
  2. 주소에 레벨이 있고. 그룹을 의미하는 네트워크 주소와 호스트 주소로 나뉨

IP 주소 체계

IPv4 = 32비트 IPv6 = 128비트

• 네트워크 주소 호스트들을 모은 네트워크를 지칭하는 주소.

• 호스트 주소 하나의 네트워크 내에 존재하는 호스트를 구분하기 위한 주소01

구분자 위치에 따라 A,B,C,D,E 클래스로 구분된다. 클래스를 도입하므로 고정 네트워크에 비해 주소를 절약할 수 잇다는 장점이 있음

클래스풀과 클래스리스

클래스 기반의 IP 주소 체계 = 클래스풀 -> 서브넷 마스트 필요없음

클래스 풀 기반으로는 IP 주소 부족과 낭비 문제가 발생하여 이것을 해결하기 위해 3가지 보존, 전환전략을 만들어냄

1. 클래스리스, CIDR(Classless Inter-Domain Routing) 기반 주소 체계 -> 단기
2. NAT와 사설 IP 주소 -> 중기
3. 차세대 IP IPv6 -> 장기 대책

TCP UDP

계층 간 데이터 전송 중 가장 중요한 2가지

1. 각 계층에서 정의하는 정보 -> 4계층 ACK번호
2. 상위 프로토콜 지시자 정보 -> 2계층 이더 타입, 3계층 프로토콜 번호, 4계층 포트 번호'

4계층의 목적 - 애플리케이션에서 사용하는 프로세스를 정확히 찾아가고 데이터를 분할한 패킷을 잘 쪼개고 잘 조립하기

TCP

TCP 프로토콜은 신회할 수 없는 공용망에서도 정보 유실 없는 통신을 보장하기 위해 세션을 안전하게 연결하고 데이터가 잘 전송되었는지 확인하는 기능이 있음. 패킷에 번호(Sequence Number)를 부여하고 잘 전송되었는지 응답(Acknowledge Number)하고 전송 크기(Window size)를 고려해 통신함

UDP

데이터 전송을 보장하지 않는 프로토콜, 단방향으로 다수의 단말과 통신해 응답을 받기 어려운 경우에 사용된다.

ARP(Address Resolution Protocol)

상대방의 MAC주소를 알아내기 위해 사용되는 프로토콜

APR이란

데이터 통신은 2계층 물리적 주소인 MAC과 3계층 논리적 IP 주소 두 개가 사용됨 두 주소는 전혀 연관성이 없으므로 두개의 주소를 연계시켜 주기 위한 메커니즘이 APR

1. 의 MAC 주소를 알아내려면 ARP 브로드캐스트를 이용 네트워크 전체에 상대방의 MAC 주소를 질의한다.

2. 로드캐스트를 받은 목적지는 ARP 프로토콜을 이용해 자신의 MAC 주소를 응답.

3. 작업이 완료 후 출발지, 목적지 둘다 상대의 MAC 주소를 학습하고 패킷이 정상적으로 인캡슐레이션 되어 상대방에게 전달됨

• NAT,NIC

이번에 Optional을 정리하면서 여러 자료를 찾아보던 중 Optional과 관련된 포스팅 하나가 정말 정리가 잘되었다고 생각하게 되었다. https://dzone.com/articles/using-optional-correctly-is-not-optional https://www.latera.kr/blog/2019-07-02-effective-optional/ [Java] Optional 올바르게 사용하기 블로그에 정리...를 빙자한 배껴쓰기를 하면서 내 머리에도 정리가 될 수 있도록 꼼꼼히 읽으면서 정리하려고 한다.

Optional 올바르게 사용하기

1. Optional에 절대 null을 할당하면 안된다. 나쁜 예 :

   Optional<Member> findById(Long id) {
   // find Member from db    
    if (result == 0) {
    return null;        
    }
   }

   좋은 예 :

   Optional<Member> findById(Long id) { 
    // find Member from db    
      if (result == 0) {
          return Optional.empty();    
      }
   }

당연히 Optional 대신 null 을 반환하는 것은 Optional 의 도입 의도와 맞지 않는다. Optional 은 내부 값을 null 로 초기화한 싱글톤 객체를 Optional.empty() 메소드를 통해 제공하고 있다. 위에서 말한 "결과 없음"을 표현해야 하는 경우라면 null 대신 Optional.empty() 를 반환하자.

2. Optional.get() 호출 전에 Optional 객체가 값을 가지고 있음을 확실히 할 것 Optional.get() 메소드를 통해 해당 값을 접근 할 수 있다. 만약 빈 Optional 객체에 get() 메소드를 호출한 경우 NoSuchElementException 이 발생하기 때문에 값을 가져오기 전에 반드시 값이 있는지 확인해야 한다.

3. 값이 없는 경우, Optional.orElse() , Optional.orElseGet()을 통해 값을 제공한다. 이전 글에서 정리했던 것 처럼 orElse는 Optional에 값이 있던 없던 무조건 실행된다. 만약 값이 있다면 인자로 실행된 값은 무시되고 버려진다.

   • orElse는 이미 생성된었거나 계산된 값일 때만 사용한다.
   • 그렇지 않을 경우는 orElseGet()을 통해 불필요한 연산을 하지 않게 한다.

4. 값이 없는 경우, Optional.orElseThrow() 를 통해 명시적으로 예외를 던질 것

   예시

   Member member = findById(1).orElseThrow(() -> new NoSuchElementException("Member Not Found"));

5. isPresent() - get() 은 orElse() 나 orElseXXX 등으로 대체

   Optional<Member> optionalMember = findById(1);
   if(optionalMember.isPresent()) {
     System.out.println("member : " +optionalMember.get());
   } else {
     throw new MemberNotFoundException("Member Not Found id : " + 1);
   }

   좋은 예:

   Member member = findById(1)        
             .orElseThrow(() -> new MemberNotFoundException("Member not found id : " + 1));
   System.out.println("member : " + member.get());

6. Optional 을 생성자나 메소드 인자로 사용하지 말 것

   Optional 을 생성자나 메소드 인자로 사용하면, 호출할 때마다 Optional 을 생성해서 인자로 전달해줘야 한다.굳이 비싼 Optional 을 인자로 사용하지 말고 호출되는 쪽에 null 체크 책임을 남겨두는 것이 좋다.

        void increaseSalary (Member member,int salary){
            if (member != null) {
                member.increaseSalary(salary);
            }
        }

7. 단지 값을 얻을 목적이라면 Optional 대신 null 비교

   Optional 은 비싸기 때문에 과도하게 사용하지 말아야 한다.단순히 값 또는 null 을 얻을 목적이라면 Optional 대신 null 비교를 사용하자

   return Optional.ofNullable(member).orElse(UNKNOWN);
   //변경
   return member != null ? member : UNKNOWN;

   8. Optional 을 빈 컬렉션이나 배열을 반환하는 데 사용하지 말 것

   컬렉션이나 배열로 복수의 결과를 반환하는 메소드가 "결과 없음"을 가장 명확하게 나타내는 방법은 대부분의 경우 빈(empty) 컬렉션 또는 배열을 반환하는 방법이다.

   List<Member> members = team.getMember();
   return Optional.ofNullable(members);
   
   //변경
   
   List<Member> members = team.getMembers();
   return members != null ? members : Collections.emptyList();

   JPA에서도 컬렉션을 Optional로 감싸는 것은 좋지 못하다. 컬렉션을 반환하는 Spring Data JPA Repository 메소드는 null 을 반환하지 않고 비어있는 컬렉션을 반환해주므로 Optional 로 감싸서 반환 할 필요가 없다.

   public interface MemberRepository extends JpaRepository<Member, Long> {
      Optional<List<Member>> findAllByNameContaining(String keyword);
   }
   
   //변경
   
   public interface MemberRepository extends JpaRepository<Member, Long> {
      List<Member> findAllByNameContaining(String keyword);
   }

9. Optional.of() 와 Optional.ofNullable() 을 혼동하지 말 것

   of(X) 는 X 가 null 이 아님이 확실할 때만 사용해야 하며, X 가 null 이면 NullPointerException이 발생 한다. ofNullable(X) 은 X가 null 일 가능성이 있을 때 사용해야 하며, X 가 null 이 아님이 확실하면 of(X) 를 사용해야 한다.

   //나쁜 예 :
   return Optional.of(member.getName()); // member의 name이 null 이면 NPE 발생 
   return Optional.ofNullable(MEMBER_STATUS);
   //좋은 예 :
   return Optional.ofNullable(member.getName());
   return Optional.of(MEMBER_STATUS);

10. 원시 타입의 Optional 에는 OptionalInt , OptionalLong , OptionalDouble 사용을 고려할 것

    원시 타입(primitive type)을 Optional 로 사용하면 Boxing 과 UnBoxing 을 거치면서 오버헤드가 생기게 된다. 반드시 Optional 의 제네릭 타입에 맞춰야 하는 경우가 아니라면 int , long , double 타입에는 OptionalXXX 타입 사용을 고려하는 것이 좋다. 이들은 내부 값을 래퍼 클래스가 아닌 원시 타입으로 갖고, 값의 존재 여부를 나타내는 isPresent 필드를 함께 갖는 구현체들이다.

    //나쁜 예 :
    Optional<Integer> cnt = Optional.of(10); // boxing 발생
    for(int i = 0; i < cnt.get(); i++) { ... } // unboxing 발생
    //좋은 예 :
    OptionalInt cnt = OptionalInt.of(10); // boxing 발생 안 함
    for(int i = 0; i < cnt.getAsInt(); i++) { ... } // unboxing 발생 안 함
    

    15. 내부 값 비교에는 Optional.equals 사용을 고려할 것

기본적인 참조 확인과 타입 확인 이후에 두 Optional 의 동치성은 내부 값의 equals 구현이 결정한다. 즉, Optional 객체 maybeA 와 maybeB 의 두 내부 객체 a 와 b 에 대해 a.equals(b) 가 true 이면maybeA.equals(maybeB) 도 true 이며 그 역도 성립한다. 굳이 내부 값의 비교만을 위해 값을 꺼낼 필요는 없다는 의미이다.

  //나쁜 예 :
boolean compareMemberById(long id1, long id2) {
      Optional<Member> maybeMemberA = findById(id1);
      Optional<Member> maybeMemberB = findById(id2);
      if(!maybeMemberA.isPresent() && !maybeMemberB.isPresent()) {return false; }    
      if (maybeMemberA.isPresent() && maybeMemberB.isPresent()) {
          return maybeMemberA.get().equals(maybeMemberB.get());    
      }    
      return false;
}
//좋은 예 :
boolean compareMemberById(long id1, long id2) {
      Optional<Member> maybeMemberA = findById(id1);
      Optional<Member> maybeMemberB = findById(id2);
      if(!maybeMemberA.isPresent() && !maybeMemberB.isPresent()) { return false; }
      return findById(id1).equals(findById(id2));
}

//객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
////

EntityManager em = emf.createEntityManager();
em.getTransation().begin();

//객체를 저장한 상태(영속)   ->  영속성 컨텍스트에 저장되었을 뿐 DB에 저장된게 아님
em.persist(member);
//

//컨텍스트에서 분리
em.detach(member);

//객체를 삭제
em.remove(member);

영속성 컨택스트의 이점

• 1차 캐시

• 동일성 보장

• 트랜잭션을 지원하는 쓰기 지연

  • 배치 기능이 가능

• 변경 감지(더티 체킹)

  • set함수로 값 변경 시 데이터 Update 가능

  • JPA는 commit 시점에 flush가 발생하면서 엔티티와 스냅샷(가져온 시점의 값)을 비교 후 update 쿼리를 쓰기 지연 sql 저장소에 보냄

• 지연 로딩

플러시

• 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영

• 기능

  • 변경 감지

  • 수정된 엔티티 쓰기 지연 SQL 저장소 등록

  • 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송 (등록, 수정, 삭제)

JPA

• Java Persistence API
• 자바 진영의 ORM 기술 표준

ORM?

• Object-relational mapping(객체 관계 매핑)
• 객체는 객체 대로 db는 db 대로 설계
• orm 프레임워크가 중간에서 매핑

JPA는 애플리케이션과 JDBC 사이에서 동작

• JPA는 인터페이스의 모음

JPA를 사용해야 하는 이유

• SQL 중심 개발에서 객체 중심 개발
• 생산성
• 유지 보수
• 패러다임의 불일치 해결
• 성능
• 데이터 접근 추상화와 벤더 독립성
• 표준

생산성 - CRUD

• 저장 : jpa.persist(member)
• 조회 : Member member = jpa.find(memberId);
• 수정 : member.setName("변경할 이름")
• 삭제 : jpa.remove(member)

유지보수

• 기존 : 필드 변경 시 모든 sql 수정 -> JPA : 필드 변경 시 나머지 sql은 JPA가 처리해준다.

상속 가능 , 연관관계, 객체 그래프 탐색 -> 신뢰 할 수 있는 엔티티, 계층

성능 최적화 기능

• 1차 캐시와 동일성(identity) 보장
  • JPA는 같은 트랜잭션 안에서는 같은 엔티티를 반환 - 약간의 조희 성능 향상
• 트랜잭션을 지원하는 쓰기 지연
  • 트랜잭션을 커밋 할 때까지 INSERT SQL을 모음
    • JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송
  • UPDATE, DELETE로 인한 로우(ROW)락 시간 최소화
    • 트랜잭션 커밋 시 UPDATE, DELETE SQL 실행하고, 바로 커밋
• 지연 로딩
  • 지연 로딩 : 객체가 실제 사용될 때 로딩
  • 즉시 로딩 : JOIN SQL로 한번에 연관된 객체까지 미리 조회

주의사항

• JPA는 항상 트랜잭션 안에서 실행되어야 한다.

• 엔티티 매니저 팩토리는 하나만 생성해서 애플리케이션 전체에서 공유

• 엔티티 매니저는 쓰레드 간 공유X(사용하고 버려야 한다.)

• JPA의 모든 데이터 변경은 트랜잭션 안에서 실행

JPQL

• JPA를 사용하면 엔티티 객체를 중심으로 개발

• 문제는 검색 쿼리

• 검색을 할 때도 테이블X 엔티티 객체를 대상으로 검색

• 모든 db 데이터를 객체로 변환해서 검색은 불가능

• 애플리케이션이 필요한 데이터만 db에서 불러오려면 결국 검색 조건이 포함된 sql이 필요

  JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어 제공

  JPQL - 엔티티 객체를 대상으로 쿼리

   **SQL** - 데이터베이스 테이블을 대상으로 쿼리.

ORM은 객체와 RDB 두 기둥 위에 있는 기술

마치며

이미 전 부터 JPA를 사용해서 몇 번 프로젝트를 개발해 왔지만 항상 사용하면서 이렇게 사용하는게 맞을까?? 라는 고민을 많이 했었다. 새로 프로젝트를 시작하면서 모르는 부분을 채우고 알던 확실하게 다지는 기회가 되도록 유명한 김영한 선생님의 인강을 정리하면서 공부하기로 결정했고 배운 부분을 바로바로 프로젝트에 적용할 수 있도록 하겠다.

그 때는 모든 도메인에 해당 컬럼을 만들면서 진행하였다. 그러다보니 같은 코드를 계속 작성하며 시간을 낭비하고 다른 도메인을 담당한 팀원들과 컬럼명이 다르게 적고 나중에 깨닫는 사고도 경험했었다.

그러다 중복을 처리해주는 JPA Auditiong이라는 것을 알게 되었고 새 프로젝트에서는 이 기능을 사용하기 위해 정리하려고 한다.

JPA Auditing

JPA에서는 Audit이라는 기능을 제공한다 Audit은 Spring Data JPA에서 시간에 대해서 자동으로 값을 넣어주는 기능이다. 도메인을 영속성 컨텍스트에 저장하거나 조회를 수행한 후에 update를 하는 경우 매번 시간 데이터를 입력하여 주어야 하는데, Audit을 이용하면 자동으로 시간을 매핑하여 데이터베이스의 테이블에 넣어주게 된다. JPA Audit은 데이터의 변경 기록을 추적하고 데이터 변화에 대한 이력을 기록하는 것을 목적으로 한다.

Auditing 활성화

@SpringBootApplication
@EnableJpaAuditing
public class CosmosApplication {

    public static void main(String[] args) {
        SpringApplication.run(CosmosApplication.class, args);
    }

}

SpringBootApplication에 @EnableJpaAuditing 어노테이션을 추가

BaseEntity 생성하기

@Getter
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public abstract class BaseEntity {

    @CreatedDate
    @Column(updatable = false)
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime modifiedDate;
}

@MappedSuperclass

• Entity에서 Table에 대한 공통 매핑 정보가 필요할 때 부모 클래스에 정의하고 상속받아 해당 필드를 사용하여 중복을 제거

@EntityListeners

• Entity를 DB에 적용하기 이전, 이후에 커스텀 콜백을 요청할 수 있는 어노테이션

Class AuditingEntityListener (org.springframework.data.jpa)

• Entity 영속성 및 업데이트에 대한 Auditing 정보를 캡처하는 JPA Entity Listener

@CreatedDate (org.springframework.data)

• 데이터 생성 날짜 자동 저장 어노테이션

@LastModifiedDate (org.springframework.data)

• 데이터 수정 날짜 자동 저장 어노테이션

@CreatedBy (org.springframework.data)

• 데이터 생성자 자동 저장 어노테이션

@LastModifiedBy (org.springframework.data)

• 데이터 수정자 자동 저장 어노테이션

Entity 적용

@Getter
@Entity
@NoArgsConstructor(access = PROTECTED)
public class Board extends BaseEntity {

    @Id
    private Long id;

}

선언한 변수는 id뿐이지만 2개의 컬럼이 추가된 것을 확인 할 수 있다.

이전에 Swagger를 적용하여 api를 문서화를 진행한 적이 있어서 이번에도 똑같이 Swagger를 통한 문서화를 진행하려고 했다.

spring boot 3.2.3을 사용하고 springfox3.0.0을 추가했다. 하지만 오류가 발생하여 SpringFox를 사용할 수 없었다.

spring boot 3버전에서는 SpringFox 가 적용되지 않는다. Java EE가 Spring boot 3에서는 JakartaEE로 변경되었지만 현재 JakartaEE를 지원하는 SpringFox는 없기 때문이다.

spring boot의 버전을 낮추거나,** springdoc-openapi**를 이용해야 한다.

[Spring Fox] 2020년 7월 3.0.0 버전을 마지막으로 업데이트 되고 있지 않음

[Spring Doc] 2023년 4월 1.7.0 버전 업데이트

dependency 설정

// https://mvnrepository.com/artifact/org.springdoc/springdoc-openapi-ui
//    implementation 'org.springdoc:springdoc-openapi-ui:1.7.0'  해당 의존성은 오류 발생
    implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.0.2'

OpenAPI Bean 등록

@Configuration
public class SwaggerConfig {
    @Bean
    public OpenAPI openAPI() {
        return new OpenAPI()
                .components(new Components())
                .info(apiInfo());
    }

    private Info apiInfo() {
        return new Info()
                .title("Springdoc 테스트")
                .description("Springdoc을 사용한 Swagger UI 테스트")
                .version("1.0.0");
    }
}

application.yml 설정

springfox에서는 bean으로 설정을 등록했었지만 springdoc는 apllication에서 모든 설정을 등록 할 수 있다.

springdoc:
  packagesToScan: com.nklcb.cosmos
  default-consumes-media-type: application/json;charset=UTF-8
  default-produces-media-type: application/json;charset=UTF-8
  swagger-ui:
    path: /swagger.html
    disable-swagger-default-url: true
    display-request-duration: true
    operations-sorter: alpha

모든 설정이 완료 된 후 path에 설정해둔 경로로 이동하면 정상적으로 화면이 보인다.

spring security 설정

향후 추가

API 스펙 작성

@RestController
@RequiredArgsConstructor
@RequestMapping("/api/members")
@Validated
@Tag(name = "Member", description = "Member API")
public class MemberController {

    @GetMapping("/{memberId}")
    @Operation(summary = "Get member profile", description = "특정 멤버의 상세 정보를 조회한다.")
    @ApiResponses(value = {
        @ApiResponse(responseCode = "200", description = "성공",
        content = {@Content(schema = @Schema(implementation = MemberProfileRes.class))}),
        @ApiResponse(responseCode = "404", description = "해당 ID의 유저가 존재하지 않습니다."),
        })
    public MemberProfileRes getMemberProfile(
        @PathVariable
        @Positive(message = "유저 ID는 양수입니다.")
        @Schema(description = "Member ID", example = "1")
        Long memberId,

        // TODO: Replace with member ID from JWT or that from any other authentication method
        @Parameter(name = "loginId", description = "로그인 유저 ID 값", example = "3", required = true)
        @Positive(message = "유저 ID는 양수입니다.") @RequestParam final Long loginId,

        @RequestBody @Valid MemberProfileUpdateReq request
    ) {
      return memberMapper.toResponse(
          memberService.findProfileByMemberId(memberId, loginId)
      );
      }

}

@Tag(name = "Member", description = "Member API")

**`@Tag`**를 통해 controller 단위에 tag를 지정해 준다.

Swaaget UI에서는 tag단위로 그룹핑 된다.


> ```java
@Operation(summary = "Get member profile", description = "특정 멤버의 상세 정보를 조회한다.")

@Operation을 이용해 해당 API가 어떤 리소스를 나타내는지 간략한 설명을 추가할 수 있다.

@ApiResponses(value = {
        @ApiResponse(responseCode = "200", description = "성공",
        content = {@Content(schema = @Schema(implementation = MemberProfileRes.class))}),
        @ApiResponse(responseCode = "404", description = "해당 ID의 유저가 존재하지 않습니다."),
        })

**`@ApiResponses`**를 이용해 해당 API의 Response 정보들을 나타낼 수 있다.

**`@ApiResponse`**는 단일 Response에 대한 정보를 나타낸다.

**responseCode** : HTTP status code
**description** : 이 response의 의미
**content** : response 데이터 포맷. void이거나 response field에 대한 설명을 추가하지 않을거라면 생략하면 된다.

> ```java
@ApiResponses(value = {
    @ApiResponse(responseCode = "200", description = "성공",
        content = {
            @Content(mediaType = "application/json", array = @ArraySchema(schema = @Schema(implementation = MemberRes.class)))
        })
})

응답이 list 일 경우** arry **옵션 사용

DTO API 스펙 작성

@Getter
@AllArgsConstructor
@Schema(description = "Member profile update request")
public class MemberProfileUpdateReq {

  @NotBlank(message = "사용자 이름을 입력해주세요.")
  @Length(max = 20, message = "사용자 이름은 20글자 이하로 입력해야 합니다.")
  @Schema(description = "member name", example = "John Doe")
  private String name;

  @NotBlank(message = "사용자 닉네임을 입력해주세요.")
  @Length(max = 20, message = "사용자 닉네임은 20글자 이하로 입력해야 합니다.")
  @Schema(description = "member nickname", example = "johndoe")
  private String nickname;

  @NotBlank
  @Schema(description = "member profile emoji", example = "👨🏻‍💻")
  private String profileEmoji;
}

@Schema를 사용해서 클래스 설명 및 변수 설명을 설정할수 있다.

변수가 특정 객체를 타입으로 가진다면 implementation 옵션을 사용한다.

@NotBlank, @Length 등 Spring validation은 자동으로 인식할 수 있다.

이전 프로젝트에서 swagger를 적용할 때 api를 개발하면서 swagger 사용법을 검색하고 적용하다 보니 필요한 내용이 누락되었던 경우가 조금씩 발생했었다. 덕분에 다른 팀원들이 api관련해서 swagger가 있어도 설명해주라는 경우가 있었는데 이번에는 본격적인 프로젝트 시작 전에 사용법을 정리하고 이런 경우가 없도록 깔끔하게 정리하고 싶다.

TDD란 Test Driven Development의 약자로 '테스트 주도 개발'이라고 한다.

반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.

RED : 실패하는 테스트 코드(Failing Test)를 작성한다. GREEN : 테스트 코드를 성공시키기 위한 코드(Test Pass)를 작성한다. BLUE : 중복 코드 제거, 일반화 등의 리팩토링(Refactor)을 수행한다.

중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야하는 것이다. 이를 통해 실제 코드에 대해 기대되는 바를 보다 명확하게 정의 함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다.

보통 개발 방식은 ‘요구사항 분석 → 설계 → 개발 → 테스트 → 배포’의 형태의 개발 주기를 갖는다.

이러한 방식은 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재한다.

그 이유는 아래와 같다.

• 소비자의 요구사항이 처음부터 명확하지 않을 수 있다.
• 따라서 처음부터 완벽한 설계는 어렵다.
  • 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있다.
  • 자체 테스트 비용이 증가할 수 있다.

이러한 문제점이 발생되는 이유는 어느 프로젝트든 초기 설계가 완벽하다고 말할 수 없기 때문이다.

고객의 요구사항 또는 디자인의 오류 등 많은 외부 또는 내부 조건에 의해 재설계하여 점진적으로 완벽한 설계로 나아간다.

재설계로 인해 개발자는 코드를 삽입, 수정, 삭제하는 과정에서 불필요한 코드가 남거나 중복처리 될 가능성이 크다.

결론적으로 이러한 코드들은 재사용이 어렵고 관리가 어려워서 유지보수를 어렵게 만든다.

작은 부분의 기능 수정에도 모든 부분을 테스트해야 하므로 전체적인 버그를 검출하기 어려워진다. 따라서 자체 버그 검출 능력이 저하된다. 그 결과 어디서 버그가 발생할지 모르기 때문에 잘못된 코드도 고치지 않으려 하는 현상이 나타나게 된다.

TDD 개발 방식은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 것이다.

디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의해야만 하고, 무엇보다 테스트해야 할지 미리 정의(테스트 케이스 작성)해야만 한다.

테스트 코드를 작성하는 도중 발생하는 예외 사항(버그 및 수정사항)은 테스트 케이스에 추가하고 설계를 개선한다.

이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성한다.

개발 방식 비교

차이점은 테스트 코드를 작성한 뒤에 코드개발을 진행한다는 것이다.

디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의하고 테스트해야할 지 미리 정의를 해야한다. 이후 테스트 코드 작성 단계에서는 위와 같은 3단계 개발 주기를 통해 테스트 코드 작성과 리팩토링 단계를 거친다.

이러한 단계가 반복적으로 진행되면서 자연스럽게 코드의 버그는 줄어들고 소스의 코드는 간결해진다. 또한 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감될 수 있다.

TDD의 장점

1. 디버깅 시간을 단축 할 수 있다. 이는 유닛 테스팅을 하는 이점이기도 하다. 예를 들면 사용자의 데이터가 잘못 나온다면 DB의 문제인지, 비즈니스 레이어의 문제인지 UI의 문제인지 실제 모든 레이러들을 전부 디버깅 해야하지만, TDD의 경우 자동화 된 유닛테스팅을 전재하므로 특정 버그를 손 쉽게 찾아낼 수 있다. 

2. 코드가 내 손을 벗어나기 전에 가장 빠르게 피드백 받을 수 있다. 개발 프로세스에서는 보통 ‘인수 테스트’를 한다. 이미 배치된 시스템을 대상으로 클라이언트가 의뢰한 소프트웨어가 사용자 관점에서 사용할 수 있는 수준인지 체크하는 과정이다. 이미 90% 이상 완성된 코드를 가지고 테스트하기 때문에, 문제를 발견해도, 정확하게 원인이 무엇인지 진단하기는 힘들다. 하지만 TDD를 사용하면 기능 단위로 테스트를 진행하기 때문에 코드가 모두 완성되어 프로그래머의 손을 떠나기 전에 피드백을 받는 것이 가능하다.   3. 작성한 코드가 가지는 불안정성을 개선하여 생산성을 높일 수 있다. 켄트 백은 TDD는 불안함을 지루함으로 바꾸는 마법의 돌이라고 말했다. 앞서 말한 것처럼 TDD를 사용하면, 코드가 내 손을 떠나 사용자에게 도달하기 전에 문제가 없는지 먼저 진단 받을 수 있다. 그러므로 코드가 지닌 불안정성과 불확실성을 지속적으로 해소해준다.   4. 재설계 시간을 단축 할 수 있다. 테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 된다. 또한 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해볼 수 있다. 이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있다.   5. 추가 구현이 용이하다. 개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것이다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다.

TDD의 단점

1. 가장 큰 단점은 바로 생산성의 저하이다. ** 개발 속도가 느려진다고 생각하는 사람이 많기 때문에 TDD에 대해 반신반의 한다.왜냐하면 처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문이다.TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어난다. SI 프로젝트에서는 소프트웨어의 품질보다 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하지 않는다.   *2. 이제까지 자신이 개발하던 방식을 많이 바꿔야 한다. * 몸에 체득한 것이 많을 수록 바꾸기가 어렵다. 오히려 개발을 별로 해보지 않은 사람들에겐 적용하기가 쉽다.   **3. 구조에 얽매힌다. TDD로 프로젝트를 진행하면서 어려운 예외가 생길 수 있는데 그것 때문에 고민하는 순간이 찾아오게 된다. 원칙을 깰 수는 없고 꼼수가 있기는 한데 그 꼼수를 위해서 구조를 바꾸자니 이건 아무래도 아닌 것 같고, 테스트는 말 그대로 테스트일 뿐 실제 코드가 더 중요한 상황인데도 불구하고 테스트 원칙 때문에 쉽게 넘어가지 못하는 그런 경우다.

이번에 회사에서 테스트를 진행하면서 1400개나 되는 실제 케이스를 전부 돌려서 안되는 케이스를 찾는 노가다 업무를 맡으면서 테스트에 대해 많은 생각을 하게 되면서 TDD를 공부하고 다음 개발에 적극적으로 적용해보자는 생각으로 정리하게 되었습니다..

개념 정리 뿐만 아니라 실제 TDD를 적용하는 방법도 이 정리를 하고 앞으로 테스트를 하기 위해 노가다를 뛰는 경험이 없었으면 하는 작은 바램으로 공부하겠습니다.

참고자료

TDD란? 테스트 주도 개발 TDD, 테스트 주도 개발이란?

풀이

bfs탐색을 하면서 1,2,3번 조건을 추가하며 최종 S에 도달할 때 까지 진행한다. check[][]를 통해 해당 값의 clip에 복사되었던 적이 있었는지 체크하면서 중복을 제거한다.

풀고 나니 간단한 bfs였지만 문제를 푸는 동안에 방문처리를 어떻게 해야되는지 생각이 안나서 3번 이모티콘 갯수를 복사한 값의 절반까지 진행하는 등 이상한 조건을 쓰는 등 헛수고를 오래 하다가 풀게 되었다.

코드

public class BOJ_14226_이모티콘 {
    static BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
    static StringTokenizer st;
    static class Node{
        int cnt;
        int num;
        int clip;
        Node(int cnt, int num , int clip){
            this.cnt = cnt;
            this.num = num;
            this.clip = clip;
        }
    }
    public static void main(String[] args) throws IOException {

        int result = Integer.parseInt(br.readLine());
        Queue<Node> q = new LinkedList<>();
        q.add(new Node(0,1,0));
        boolean checked[][] =new boolean[10001][10001];

        while (!q.isEmpty()){
            Node now = q.poll();
            if(checked[now.num][now.clip]){
                continue;
            }
            checked[now.num][now.clip] = true;

            if(now.num == result){
                System.out.println(now.cnt);
                return;
            }

            if(now.clip != now.num) {
                q.add(new Node(now.cnt+1, now.num, now.num ));
            }
            if(now.clip != 0) {
                q.add(new Node(now.cnt+1, now.num + now.clip, now.clip));
            }
            if(now.clip/2 < now.num) {
                q.add(new Node(now.cnt+1, now.num -1, now.clip));
            }

        }



    }

}

가끔 로컬과 저장소의 파일이 다를 때 동기화를 위해서 git pull 명령어를 사용해도 git pull Already up to date. 라는 메세지만 뜬 후 코드가 가져 올 수 없을 때가 있다.

• 해결 방법

$git fetch --all

$git reset --hard origin/master

$git pull

위 명령어를 통해 이전 코드와 상관 없이 최신 커밋을 덮어 씌울 수 있습니다.

git fetch

원격 저장소(github)에 있는 정보들을 가져오는 명령어

어떤 변화가 있는지 확인할 수 있습니다. 정보를 저장하는 것은 아니고, 정보를 확인하고 필요하면 병합(merge)할 수 있습니다. fetch를 사용해서 최신 커밋 정보를 가져오면 FETCH_HEAD라는 브랜치로 가져옵니다. 따라서, 커밋 정보를 보기 위해서는 해당 브랜치로 이동(checkout)해야합니다.

이렇게 최신 커밋 정보를 가져와서 정보를 저장하려면(합치려면) $git pull을 사용해도 되고, $git merge를 사용해도 됩니다.

git reset

HEAD의 포인터를 특정 위치로 옮기는 명령어

--hard 옵션을 추가해서 이전 커밋으로 돌아가면, 그 커밋 이후에 내용들은 삭제됩니다.

--mixed 옵션을 추가해서 커밋을 이동하면 변경 이력이 모두 삭제되지만 스테이지에 코드가 남아있습니다. 이 코드를 add 후 커밋하면 됩니다.

--soft 옵션을 추가하면 mixed 옵션과 같지만 이미 스테이징 되어있습니다. 이 말은, add 없이 바로 커밋하면 된다는 뜻입니다.

이 명령어는 commit history를 덮어 씌우는 commit history로 바꾸기 때문에 기록이 없어집니다. 이 경우 다른 사람과 협업하는 상황에서 문제를 일으킬 수 있는 여지가 있습니다. 지금 제 상황과 같이 코드에 대한 확신이 있는 경우나 혼자 사용하는 브랜치에만 사용하는 것이 좋습니다.

레스토랑을 운영하고 있는 "스카피"는 레스토랑 내부가 너무 낡아 친구들과 함께 직접 리모델링 하기로 했습니다. 레스토랑이 있는 곳은 스노우타운으로 매우 추운 지역이어서 내부 공사를 하는 도중에 주기적으로 외벽의 상태를 점검해야 할 필요가 있습니다.

레스토랑의 구조는 완전히 동그란 모양이고 외벽의 총 둘레는 n미터이며, 외벽의 몇몇 지점은 추위가 심할 경우 손상될 수도 있는 취약한 지점들이 있습니다. 따라서 내부 공사 도중에도 외벽의 취약 지점들이 손상되지 않았는 지, 주기적으로 친구들을 보내서 점검을 하기로 했습니다. 다만, 빠른 공사 진행을 위해 점검 시간을 1시간으로 제한했습니다. 친구들이 1시간 동안 이동할 수 있는 거리는 제각각이기 때문에, 최소한의 친구들을 투입해 취약 지점을 점검하고 나머지 친구들은 내부 공사를 돕도록 하려고 합니다. 편의 상 레스토랑의 정북 방향 지점을 0으로 나타내며, 취약 지점의 위치는 정북 방향 지점으로부터 시계 방향으로 떨어진 거리로 나타냅니다. 또, 친구들은 출발 지점부터 시계, 혹은 반시계 방향으로 외벽을 따라서만 이동합니다.

외벽의 길이 n, 취약 지점의 위치가 담긴 배열 weak, 각 친구가 1시간 동안 이동할 수 있는 거리가 담긴 배열 dist가 매개변수로 주어질 때, 취약 지점을 점검하기 위해 보내야 하는 친구 수의 최소값을 return 하도록 solution 함수를 완성해주세요.

제한사항

• n은 1 이상 200 이하인 자연수입니다.
  • weak의 길이는 1 이상 15 이하입니다.
  • 서로 다른 두 취약점의 위치가 같은 경우는 주어지지 않습니다.
  • 취약 지점의 위치는 오름차순으로 정렬되어 주어집니다.
  • weak의 원소는 0 이상 n - 1 이하인 정수입니다.
  • dist의 길이는 1 이상 8 이하입니다.
  • dist의 원소는 1 이상 100 이하인 자연수입니다.
  • 친구들을 모두 투입해도 취약 지점을 전부 점검할 수 없는 경우에는 -1을 return 해주세요.

풀이

이 문제의 핵심 키워드는 완전 탐색과 순열이다.

완전탐색은, n, weak, dist 모두 값의 갯수가 적기 때문에 완전 탐색을 통해 정답을 얻게 되기 때문이다.

순열은, weak과 dist 모두 모든 경우를 만들어줘야 하기 때문에 순열로 모든 케이스를 따져 주어야한다.

문제 풀이 방식은 다음과 같다.

1. 모든 weak 케이스 만들기:

   예를 들어 [1,5,6,10]의 weak이 존재한다고 할 때, weak에서 나올 수 있는 모든 케이스는 [1,5,6,10], [5,6,10,13], [6,10,13,17], [10,13,17,18] 이 된다. 원형 큐의 방식처럼 만들어주면 된다.

   애초에 weak의 길이가 최대 15이므로, 이런식으로 모든 테스트 케이스를 만들어줘도 최대 15개까지밖에 되지않는다. 이런 식으로 모든 테스트 케이스를 만들어주면, 한방향으로만 탐색을 계속 진행해도 모든 경우를 다 탐색할 수 있게 된다.

2. 모든 dist 케이스 만들기:

   완전 탐색이므로, 순열을 이용하여 모든 dist 케이스를 만들어준다. 예를 들어 [3,5,7]의 dist가 존재한다고 할 때, [3,5,7], [3,7,5], [5,3,7], [5,7,3], [7,5,3], [7,3,5] 의 dist 케이스가 나타난다.

3. 모든 weak 케이스에 대해 모든 dist 케이스 검사:

   정답을 얻어내기 위해, 모든 weak 케이스에 대해 모든 dist 케이스를 검사한다. 반복문을 통해 weak 케이스의 시작 지점부터 시작해서 dist 케이스의 값을 하나씩 가져오면서 검사가 되는 weak 지점을 모두 패스한다.

   예를 들어 [1,3,4,9,10]의 weak과 [3,5,7]의 dist를 이용하여 탐색한다고 가정하면, 1번 지점에서 3짜리 dist가 사용된다. 1+3 = 4이므로, 3,4번 지점은 한번에 체크가 된다. 그럼 다음 출발지는 9번 지점이 되고, 여기서 5짜리 dist가 사용된다. 9+5 = 14이므로, 10번 지점까지 한번에 체크가 된다. 이렇게 되면 2개의 dist값만 사용하고 모두 탐색이 진행된 것이다.

코드

class Solution {
     int [] weak , dist;
    int[][] weak_cases;
    int n, answer;

    public int solution(int n, int[] weak, int[] dist) {
        weak_cases = new int[weak.length][weak.length];
         this.answer = dist.length+1;
        this.weak = weak;
        this.dist = dist;
        this.n = n;

        makeWeak();
        makeDist(new boolean[dist.length], new int[dist.length], 0);
        if(answer == dist.length+1)
            return -1;
        else
            return answer;

    }
    public void makeWeak(){
        int [] weak_case = this.weak.clone();
        weak_cases[0] = weak_case.clone();

        for (int i = 1; i < weak.length; i++) {
            int temp = weak_case[0];
            for (int j = 1; j < weak.length; j++) {
                weak_case[j-1] = weak_case[j];
            }
            weak_case[weak.length -1] = temp+n;
            weak_cases[i] = weak_case.clone();
        }
    }
    public void makeDist(boolean[] dist_visit, int[] dist_case, int idx){
        if(idx == dist.length){
            for(int[] weak_case: weak_cases)
                check(dist_case, weak_case);
        }
        for(int i = 0; i < dist.length; i++){
            if(!dist_visit[i]){
                dist_visit[i] = true;
                dist_case[idx] = dist[i];
                makeDist(dist_visit, dist_case, idx+1);
                dist_case[idx] = 0;
                dist_visit[i] = false;
            }
        }
    }

    private void check(int[] dist_case, int[] weak_case) {
        int cur = 0 , next;
        int dist_idx = 0;
        while (cur < weak_case.length && dist_idx < dist_case.length){
            next = cur+1;
            while (next < weak_case.length && weak_case[cur] + dist_case[dist_idx] >= weak_case[next]){
                next++;
            }
            cur = next;
            dist_idx++;
        }

        if(cur == weak_case.length && dist_idx < answer){
            answer = dist_idx;
        }

    }
}