ZINU

[Claude Code] Claude Code의 Commands vs Skills, 뭐가 다른가❓

지누박 — Tue, 31 Mar 2026 00:48:11 +0900

개요

Claude Code를 쓰다 보면 세 가지 설정 파일을 마주치게 됩니다.

CLAUDE.md ➡️ 매 세션마다 자동으로 로드되는 프로젝트 규칙
.claude/commands/ ➡️ 내가 직접 /명령어로 호출하는 커맨드
.claude/skills/ ➡️ Claude가 대화 흐름을 보고 자동으로 감지해서 쓰는 스킬

처음에는 Commands와 Skills이 둘 다 슬래시 커맨드로 호출되니까 "그냥 같은 거 아닌가?" 싶었습니다. 실제로 원래는 별개 시스템이었는데 현재는 통합되어 둘 다 같은 /명령어 인터페이스로 작동합니다.

오늘은 이 차이점을 직접 포트폴리오 프로젝트를 만들면서 겪은 경험을 바탕으로 정리하고자 합니다.

Commands

Commands : 내가 직접 호출 하는 것

위치
- claude/commands/명령어이름.md

내가 터미널에서 /명령어를 직접 입력했을 때만 실행됩니다. Claude가 "이 상황이면 이 커맨드를 써야겠다"고 판단해서 ~~자동으로 실행하지 않습니다.~~

Ex ) /push

## 절차
1. git status, git diff로 변경사항 분석
2. CLAUDE.md 커밋 컨벤션 참조해서 메시지 자동 생성
3. 생성된 메시지 확인 요청
4. git add -A && git commit && git push

Commands를 쓰는 경우

사이드이펙트가 있는 작업 (push, deploy, 파일 삭제)
내가 타이밍을 직접 제어해야 하는 작업
단순한 반복 작업 자동화

Skills

Skills: Claude가 자동으로 감지하는 것

위치
- .claude/skills/스킬이름/SKILL.md

Skills는 YAML frontmatter의 description 필드를 보고 Claude가 "지금 이 스킬이 필요한 상황이다"라고 판단하면 자동으로 로드합니다.

내가 직접 호출할 수도 있지만, 핵심은 자동 감지입니다.

Ex ) explain-code 스킬

---
name: explain-code
description: 코드 설명 요청 시 사용. "어떻게 작동해?", 
             "이 코드 설명해줘" 같은 요청에 자동 감지.
---

코드를 설명할 때 항상:
1. 일상적인 비유로 시작
2. ASCII 다이어그램으로 흐름 표시
3. 단계별로 풀어서 설명

사용자가 "이 코드 어떻게 작동해?"라고 물으면 Claude가 explain-code 스킬을 자동으로 로드해서 그 방식대로 답변합니다.

Skills를 쓰는 경우

Claude가 알아서 판단해서 써줬으면 하는 작업
지원 파일(스크립트, 템플릿)이 필요한 복잡한 작업
여러 프로젝트에서 공통으로 쓰는 방법론

Skills YAML frontmatter 구조

---
name: review-code          # 스킬 식별자 (필수)
description: |             # 자동 감지 트리거 (필수, 핵심)
  코드 리뷰 요청 시 사용.
  "리뷰해줘", "코드 봐줘", "문제 있어?" 같은
  요청에 자동 감지.
version: 1.0               # 버전 관리 (선택)
author: jinwoo             # 작성자 (선택)
tags: [review, quality]    # 분류용 태그 (선택)
---

여기서 description이 핵심입니다.

Claude는 이 필드를 보고 "지금 이 스킬을 써야 하는 상황인가"를 판단합니다.

한 가지 주의할 점이 있습니다. 공식 문서에서도 Claude가 스킬을 undertrigger하는 경향이 있다고 인정합니다. 필요한 상황인데 스킬을 안 쓰는 경우입니다.

그래서 description은 소극적으로 쓰면 안 됩니다.

# 소극적 (undertrigger 위험)
description: 코드 리뷰 스킬

# 적극적 (권장)
description: |
  코드 리뷰 요청 시 사용.
  "리뷰해줘", "코드 봐줘", "문제 있어?", "확인해줘" 같은
  요청뿐 아니라 코드를 보여주면서 의견을 묻는 상황에서도 반드시 사용할 것.

Commands vs Skills 핵심 차이점

위치	.claude/commands/	.claude/skills/<name>/
파일명	명령어.md	SKILL.md (고정)
호출	내가 직접 /명령어	자동 감지 + 직접 호출
지원 파일	없음	스크립트, 템플릿 등 가능

실제로 어떻게 구분해서 써야할까❓

처음엔 코드 리뷰도 Commands로 만들었습니다.

그런데 쓰다 보니 문제가 생겼습니다. /review를 타이핑해야 한다는 걸 매번 잊어버리니, "이 코드 좀 봐줘"라고 자연어로 물어보게 되고 일반 답변이 나올 뿐 ~~내가 정해둔 리뷰 방식대로 동작~~하지 않았습니다.

반면 /push는 Commands가 딱 맞았습니다. Claude가 "변경사항이 많아 보이니 자동으로 푸시할게요"라고 하면 곤란하니까요.

그때 판단 기준이 명확해졌습니다. 내가 타이밍을 제어해야 하면 Commands, Claude가 알아서 판단해줬으면 하면 Skills.

/push, /done 같은 사이드이펙트가 있는 작업은 내가 원할 때만 실행되어야 합니다. ➡️ Commands
"리뷰해줘", "이 코드 설명해줘" 같은 요청은 슬래시 커맨드를 타이핑하지 않아도 Claude가 알아서 그 방식대로 답해줬으면 하는 작업입니다. ➡️ Skills

공식 문서에서도 /commit, /deploy 같은 사이드이펙트 있는 작업은 disable-model-invocation: true 설정으로 사용자만 호출 가능하게 하라고 권장합니다.

disable-model-invocation 예시

---
name: push
description: 변경사항을 git push한다
disable-model-invocation: true  # 사용자만 호출 가능
---

## 절차
1. git status, git diff로 변경사항 분석
...

disable-model-invocation: true를 설정하면 Claude가 "지금 push하면 좋을 것 같은데요"라며 자동으로 실행하는 걸 막습니다. 사이드이펙트 있는 커맨드엔 필수로 걸어두는 게 좋습니다.

결론

처음에는 둘 다 슬래시 커맨드로 보여서 같은 거라고 생각했지만, 핵심 차이는 누가 호출하느냐입니다.

내가 직접 호출 ➡️ Commands
Claude가 자동 감지 + 직접 호출 모두 ➡️ Skills

규모가 작은 프로젝트 정도의 규모라면 Commands만으로도 충분합니다. Skills는 Claude가 자동으로 판단해서 실행해줬으면 하는 복잡한 워크플로우가 생겼을 때 도입하면 된다고 생각합니다.

[AI] llmfit - 내 하드웨어에 맞는 LLM을 찾아주는 도구

지누박 — Sun, 15 Mar 2026 18:55:58 +0900

개요

로컬 LLM, 어떤 모델을 골라야 할까❓

로컬 LLM 시대가 본격화되면서 가장 먼저 부딪히는 질문이 있습니다.

"내 장비에서 어떤 모델이 실제로 돌아갈까?"

막상 모델을 고르려 하면 선택지가 너무 많습니다. 어떤 모델이 내 환경에서 실제로 잘 돌아가는지는 직접 받아보기 전까지 알기가 어렵습니다.

스펙 표를 봐도 감이 잘 안 오고, 받아보면 생각보다 느리거나 메모리가 부족해서 실행이 안 되기도 합니다. 여기서 이 문제를 해결해주는 기능이 최근에 등장했습니다.

바로 "llmfit"입니다. 본 글에서는 이 llmfit에 대한 기능을 정리하고자 합니다.

llmfit이란❓

GitHub - AlexsJones/llmfit: Hundreds of models & providers. One command to find what runs on your hardware.

Hundreds of models & providers. One command to find what runs on your hardware. - AlexsJones/llmfit

github.com

llmfit은 내 하드웨어 스펙을 자동으로 감지하고, 수백 개의 LLM 모델 중 실제로 돌아가는 것들을 점수순으로 보여주는 터미널 도구입니다.

설치 방법

macOS

brew install llmfit

Linux나 Rust 환경

cargo install llmfit

llmfit 사용해보기

llmfit

간단하게 llmfit을 터미널창에 입력하면 다음과 같은 화면이 나오게 됩니다.

상단에는 내 시스템 스펙이 자동으로 잡히고, 아래에는 모델 목록이 점수(Score) 순으로 정렬됩니다.

각 컬럼의 의미는 다음과 같습니다.

컬럼	설명
Score	내 하드웨어 기준 종합 점수
tok/s	예상 초당 토큰 수 (속도)
Quant	추천 양자화 방식
Mem %	메모리 점유율
Fit	Perfect / Good / Margin

Fit 등급이 핵심입니다.

Perfect — 여유 있게 실행 가능
Good — 실행은 되지만 메모리 빡빡함
Margin — 메모리 거의 꽉 참, 다른 앱과 함께 쓰기 어려움

내 시스템 스펙 확인

llmfit system

CPU, RAM, GPU, VRAM을 자동으로 감지해서 보여줍니다. 따로 설정할 필요 없이 실행만 하면 됩니다.

원하는 모델 검색

llmfit system

모델명, 프로바이더, 파라미터 크기로 검색할 수 있어서 "openai" 처럼 입력하면 관련 모델만 필터링됩니다.

fit 상위 결과 보

Fit 등급이 Perfect인 모델만 골라서 상위 5개를 보여줍니다. 메모리 여유가 있는 상태에서 안정적으로 실행 가능한 모델만 추리고 싶을 때 유용합니다.

코딩 용도로 추천 받기

llmfit recommend --use-case coding --json --limit 5

{
  "models": [
    {
      "best_quant": "Q4_K_M",
      "category": "Coding",
      "context_length": 262144,
      "estimated_tps": 43.9,
      "fit_level": "Perfect",
      "gguf_sources": [],
      "is_moe": true,
      "memory_available_gb": 16.0,
      "memory_required_gb": 8.0,
      "name": "NVFP4/Qwen3-Coder-30B-A3B-Instruct-FP4",
      "notes": [
        "Unified memory: GPU and CPU share the same pool",
        "MoE: 8/128 experts active (all share unified memory pool)",
        "Baseline estimated speed: 43.9 tok/s"
      ],
      "parameter_count": "15.6B",
      "params_b": 15.58,
      "provider": "nvfp4",
      "release_date": "2025-08-05",
      "run_mode": "GPU",
      "runtime": "MLX",
      "runtime_label": "MLX",
      "score": 92.5,
      "score_components": {
        "context": 100.0,
        "fit": 100.0,
        "quality": 85.0,
        "speed": 100.0
      },
      "use_case": "Code generation and completion",
      "utilization_pct": 50.0
    },
    {
      "best_quant": "Q4_K_M",
      "category": "Coding",
      "context_length": 163840,
      "estimated_tps": 34.2,
      "fit_level": "Perfect",
      "gguf_sources": [],
      "is_moe": true,
      "memory_available_gb": 16.0,
      "memory_required_gb": 8.0,
      "name": "RedHatAI/DeepSeek-Coder-V2-Lite-Instruct-FP8",
      "notes": [
        "Unified memory: GPU and CPU share the same pool",
        "MoE: 6/64 experts active (all share unified memory pool)",
        "Baseline estimated speed: 34.2 tok/s"
      ],
      "parameter_count": "15.7B",
      "params_b": 15.71,
      "provider": "redhatai",
      "release_date": "2024-07-17",
      "run_mode": "GPU",
      "runtime": "MLX",
      "runtime_label": "MLX",
      "score": 90.1,
      "score_components": {
        "context": 100.0,
        "fit": 100.0,
        "quality": 86.0,
        "speed": 85.6
      },
      "use_case": "Code generation and completion",
      "utilization_pct": 50.0
    },
    {
      "best_quant": "Q2_K",
      "category": "Coding",
      "context_length": 131072,
      "estimated_tps": 62.3,
      "fit_level": "Perfect",
      "gguf_sources": [
        {
          "provider": "bartowski",
          "repo": "bartowski/DeepSeek-Coder-V2-Lite-Instruct-GGUF"
        }
      ],
      "is_moe": true,
      "memory_available_gb": 16.0,
      "memory_required_gb": 8.0,
      "name": "deepseek-ai/DeepSeek-Coder-V2-Lite-Instruct",
      "notes": [
        "Unified memory: GPU and CPU share the same pool",
        "MoE: 6/64 experts active (all share unified memory pool)",
        "Best quantization for hardware: Q2_K (model default: Q4_K_M)",
        "Baseline estimated speed: 62.3 tok/s"
      ],
      "parameter_count": "16B",
      "params_b": 15.7,
      "provider": "DeepSeek",
      "release_date": null,
      "run_mode": "GPU",
      "runtime": "MLX",
      "runtime_label": "MLX",
      "score": 89.5,
      "score_components": {
        "context": 100.0,
        "fit": 100.0,
        "quality": 79.0,
        "speed": 100.0
      },
      "use_case": "Code generation and completion",
      "utilization_pct": 50.0
    },
    {
      "best_quant": "Q4_K_M",
      "category": "Coding",
      "context_length": 262144,
      "estimated_tps": 22.4,
      "fit_level": "Marginal",
      "gguf_sources": [],
      "is_moe": true,
      "memory_available_gb": 16.0,
      "memory_required_gb": 15.6,
      "name": "lmstudio-community/Qwen3-Coder-30B-A3B-Instruct-MLX-4bit",
      "notes": [
        "Unified memory: GPU and CPU share the same pool",
        "MoE: 8/128 experts active (all share unified memory pool)",
        "Baseline estimated speed: 22.4 tok/s"
      ],
      "parameter_count": "30.5B",
      "params_b": 30.53,
      "provider": "lmstudio-community",
      "release_date": "2025-07-31",
      "run_mode": "GPU",
      "runtime": "MLX",
      "runtime_label": "MLX",
      "score": 79.7,
      "score_components": {
        "context": 100.0,
        "fit": 50.0,
        "quality": 92.0,
        "speed": 56.0
      },
      "use_case": "Code generation and completion",
      "utilization_pct": 97.5
    },
    {
      "best_quant": "Q4_K_M",
      "category": "Coding",
      "context_length": 262144,
      "estimated_tps": 22.4,
      "fit_level": "Marginal",
      "gguf_sources": [],
      "is_moe": true,
      "memory_available_gb": 16.0,
      "memory_required_gb": 15.6,
      "name": "lmstudio-community/Qwen3-Coder-30B-A3B-Instruct-MLX-5bit",
      "notes": [
        "Unified memory: GPU and CPU share the same pool",
        "MoE: 8/128 experts active (all share unified memory pool)",
        "Baseline estimated speed: 22.4 tok/s"
      ],
      "parameter_count": "30.5B",
      "params_b": 30.53,
      "provider": "lmstudio-community",
      "release_date": "2025-08-01",
      "run_mode": "GPU",
      "runtime": "MLX",
      "runtime_label": "MLX",
      "score": 79.7,
      "score_components": {
        "context": 100.0,
        "fit": 50.0,
        "quality": 92.0,
        "speed": 56.0
      },
      "use_case": "Code generation and completion",
      "utilization_pct": 97.5
    }
  ],
  "system": {
    "available_ram_gb": 6.15,
    "backend": "Metal",
    "cpu_cores": 8,
    "cpu_name": "Apple M1",
    "gpu_count": 1,
    "gpu_name": "Apple M1",
    "gpu_vram_gb": 16.0,
    "gpus": [
      {
        "backend": "Metal",
        "count": 1,
        "name": "Apple M1",
        "unified_memory": true,
        "vram_gb": 16.0
      }
    ],
    "has_gpu": true,
    "total_ram_gb": 16.0,
    "unified_memory": true
  }
}

JSON으로 출력되기 때문에 스크립트나 에이전트에서 파싱해서 활용하기도 좋습니다.

마무리

로컬 LLM을 처음 써보려는 분이라면, 모델 고르기 전에 llmfit부터 실행해보시길 추천합니다. 다운로드 전에 내 환경에 맞는 모델을 미리 파악할 수 있어서 불필요한 시행착오를 줄일 수 있습니다.

참고: llmfit GitHub

[Java] LocalDateTime vs Instant, 어떤 상황에서 써야 할까?

지누박 — Sun, 15 Mar 2026 00:53:19 +0900

개요

프로젝트를 시작할 때 엔티티의 날짜 타입으로 뭘 선언할지 고민한 적이 있을 것입니다.

주변 코드나 레퍼런스를 보면 LocalDateTime, ZonedDateTime을 쓰는 경우가 대부분입니다. 그런데 Instant를 알고 난 뒤 한 가지 의문이 생겼습니다.

"LocalDateTime이 정말 맞는 선택인가?" 본 글에서는 두 타입의 차이와 어떤 상황에서 무엇을 선택해야 하는지 정리합니다.

LocalDateTime이란❓

LocalDateTime now = LocalDateTime.now();

LocalDateTime은 날짜와 시간 정보를 가지고 있지만 ~~타임존(TimeZone) 정보~~는 없는 타입입니다. 이름에 Local이 붙은 이유가 여기 있습니다.

"내가 있는 곳의 시간" 을 표현하는 타입이지만, 그 ~~"내가 있는 곳"~~ 이 어디인지는 타입 자체가 알지 못합니다.

LocalDateTime = 벽시계 (타임존 정보 없음, 서버 환경에 종속)

LocalDateTime.now()

// 서버 타임존이 Asia/Seoul 이면
LocalDateTime.now(); // → 2026-03-14T15:00:00

// 서버 타임존이 UTC 이면
LocalDateTime.now(); // → 2026-03-14T06:00:00

LocalDateTime.now()는 내부적으로 JVM이 실행되는 서버의 타임존을 기준으로 시각을 만듭니다. 즉, 서버 환경에 따라 같은 코드가 다른 값을 만들어냅니다.

LocalDate & LocalTime

LocalDate date = LocalDate.now();                      // 날짜만: 2026-03-14
LocalTime time = LocalTime.now();                      // 시간만: 15:00:00
LocalDateTime dateTime = LocalDateTime.of(date, time); // 날짜 + 시간 조합

Instant란❓

Instant now = Instant.now();
// 출력: 2026-03-14T06:00:00Z
// Z는 UTC를 의미합니다.

Instant는 UTC(협정 세계시) 기준의 절대 시각을 나타내는 타입입니다.

내부적으로 1970년 1월 1일 00:00:00 UTC(Unix Epoch)로부터 경과한 시간을 나노초 단위로 저장합니다.

// 서버 타임존이 Asia/Seoul 이든 UTC 이든
Instant.now(); // → 2024-03-14T06:00:00Z (항상 UTC 기준

LocalDateTime과 달리 ~~서버 타임존에 영향~~받지 않습니다. 서울 서버에서 찍든, UTC 서버에서 찍든 같은 시점이면 같은 값입니다.

Instant = 절대시각 (UTC 기준, 서버 환경에 무관)

ZonedDateTime이란❓

ZonedDateTime은 날짜 + 시간 + 타임존(ZoneId) 을 모두 가지고 있는 타입입니다. 쉽게 말하면 LocalDateTime에 타임존 정보가 추가된 형태입니다.

ZonedDateTime now = ZonedDateTime.now(ZoneId.of("Asia/Seoul"));

위 코드의 경우 다음과 같은 출력이 나오게 됩니다.

2026-03-14T15:00:00+09:00[Asia/Seoul]
시간 + 오프셋(+09:00) + 타임존(Asia/Seoul) 모두 포함

즉 Instant와 ZonedDateTime 은 같은 시점을 다르게 표현하는 것입니다.

그럼 ZonedDateTime을 저장용으로 쓰면 안될까❓

쓸 수는 있지만 Instant보다 복잡합니다.

Instant       → UTC 기준 단순 저장, 조회 시 원하는 타임존으로 변환
ZonedDateTime → 타임존 정보까지 저장, DB 매핑 시 추가 고려사항 발생

저장용으로는 Instant가 더 단순하고 명확합니다. ZonedDateTime은 특정 타임존 기준으로 사용자에게 보여줄 때 사용하는 것이 적합합니다.

entity.setCreatedAt(Instant.now());

// 한국 사용자에게 표시
ZonedDateTime seoul = entity.getCreatedAt()
        .atZone(ZoneId.of("Asia/Seoul"));

// 미국 사용자에게 표시
ZonedDateTime la = entity.getCreatedAt()
        .atZone(ZoneId.of("America/Los_Angeles"));

잘못 선택하면 생기는 일

1. LocalDateTime

@Column
private LocalDateTime createdAt;

만약 서버 타임존이 바뀐다면 어떻게 될까요?

예를 들어 기존에 국내 온프레미스 서버(Asia/Seoul, UTC+9)에서 운영하다가 Docker 또는 AWS EC2로 이전하면서 서버 타임존이 UTC로 변경됐다면 다음과 같은 문제가 발생합니다.

LocalDateTime.now(); // → 2026-03-14T15:00:00

// 이후: 서버 타임존 UTC로 변경
LocalDateTime.now(); // → 2026-03-14T06:00:0

DB에 저장된 기존 데이터는 그대로 15:00:00입니다.

그런데 타임존 변경 이후 저장된 데이터는 06:00:00으로 들어갑니다. 같은 시점인데 9시간 차이가 생겨버립니다. 더 문제인 건 이게 배포 직후 바로 못 잡는다는 점입니다.

애플리케이션은 정상 동작하고, ~~에러 로그~~도 없습니다. 데이터가 어느 정도 쌓이고 나서야 "어? 시간이 이상한데?" 하고 뒤늦게 발견하게 됩니다.

2. Instant

// 서버 타임존이 Asia/Seoul 이든 UTC 이든
Instant.now(); // → 2026-03-14T06:00:00Z (항상 UTC 기준)

반면 Instant는 UTC 기준 절대시각으로 저장하기 때문에 서버 타임존이 바뀌어도 저장되는 값이 ~~달라지지 않습니다.~~

언제 뭘 써야 하는가❓

Instant

created_at, updated_at 같은 서버 기록용 시각
서버 환경이 바뀔 가능성이 있을 때 (온프레미스 → 클라우드 이전 등)
글로벌 서비스, 멀티 타임존 환경
두 시각 사이의 간격을 계산할 때

LocalDateTime

사용자에게 보여주는 시각 (타임존 변환 후 표시용)
비즈니스적으로 날짜 자체가 의미 있을 때
- 예) 예약일, 생년월일, 공시 기준일
타임존이 절대 바뀌지 않는 환경 (국내 전용, 고정 온프레미스)

Instant로 저장하고 표시할 때 변환하는 패턴

AWS EC2, ECS, Docker 컨테이너의 기본 타임존은 UTC입니다. 국내 서비스라도 클라우드 인프라를 사용하는 순간 아래 상황이 발생할 수 있습니다

서버 타임존: UTC
사용자 타임존: Asia/Seoul (UTC+9)

이 경우 LocalDateTime으로 저장하면 이전에 설명한 9시간 문제가 그대로 발생합니다. Instant로 저장하고, 사용자에게 보여줄 때 타임존을 적용해서 변환하는 패턴이 필요합니다.

// 저장 (UTC 기준 절대시각으로 저장)
entity.setCreatedAt(Instant.now());

// 한국 사용자에게 표시
LocalDateTime display = entity.getCreatedAt()
        .atZone(ZoneId.of("Asia/Seoul"))
        .toLocalDateTime();
// → 2026-03-14T15:00:00

[트러블슈팅] POI명 vs 실제 주소: Tmap 경로 검색 400 에러 해결하기

지누박 — Wed, 11 Feb 2026 22:07:04 +0900

개요

개인 프로젝트의 마이페이지에서 경로 검색 기능을 개발하던 중, Tmap 지오코딩 API 호출 시 400 Bad Request 에러가 발생했습니다.

POI 검색 결과를 그대로 API에 전달하면서 특수문자 인코딩 문제와 POI명/주소 혼용 문제가 원인이었습니다. 본 글에서는 이 문제의 원인 분석과 UX를 고려한 해결 과정을 정리하고자 합니다.

문제 상황

사용자가 출발지와 도착지를 입력하고 경로를 검색했을 때, 티맵 지오코딩 API 호출 시 백엔드 서버에서 아래와 같은 에러 로그와 함께 경로 탐색에 실패하는 현상이 발생했습니다.

org.springframework.web.reactive.function.client.WebClientResponseException$BadRequest: 
400 Bad Request from GET https://apis.openapi.sk.com/tmap/geo/fullAddrGeo

발생 지점
- 티맵 주소 기반 지오코딩 API 호출 시
검색 키워드
- 출발지(송파구 잠실동), 목적지(강남역[2호선])

원인 분석

1. 특수문자 인코딩 문제

티맵 지오코딩 API는 URL 파라미터로 주소를 전달받는데, 대괄호([, ]) 같은 특수문자가 ~~제대로 인코딩~~되지 않으면 서버가 요청을 거부합니다.
- 즉, 장소명에 포함된 [ , ]와 같은 특수문자가 URL 파라미터로 전달되는 과정에서 ~~인코딩 처리가 규격~~에 맞지 않아 티맵 API 서버에서 잘못된 요청(Bad Request)으로 처리된 것 이었습니다.

2. API 성격에 맞지 않는 파라미터 전달

티맵의 fullAddrGeo API는 정제된 법정 주소나 도로명 주소를 기반으로 좌표를 변환합니다.
그러나 사용자가 선택한 강남역[2호선]은 주소가 아닌 장소명(POI) 데이터입니다. ➡️ 인코딩 실패

SK open API

puzzle 장소 혼잡도 실시간 장소 혼잡도

openapi.sk.com

위 SK open API docs를 보면 다음과 같이 나와있습니다.

[SK Open API 공식 가이드 발췌]

- 기능 설명: "지번 주소 또는 새주소(도로명 주소) 전체를 텍스트로 입력해 이를 분석하여 좌표로 변환
- "Request 필수 파라미터 (fullAddr): "지번 주소 또는 도로명 주소 전체를 지정" (예: 서울시 중구 을지로)

주의 사항: "주소 입력 시 UTF-8 기반의 URL 인코딩 처리 필수"

1. 입력값의 제한

가이드에 명시된 대로 해당 API는 주소(Address)를 입력받도록 설계되어 있습니다. 하지만 제가 전송한 데이터는 강남역[2호선]과 같은 장소명(POI)이었으며, 이는 API의 명확한 ~~사용 목적에서 벗어난 파라미터~~였습니다.

2. 인코딩 규격 위반

가이드에서는 UTF-8 기반 URL 인코딩을 필수 조건으로 내걸고 있습니다.

특수문자가 포함된 장소명을 별도의 정제나 ~~인코딩~~ 없이 전송할 경우, API 서버는 이를 유효하지 않은 요청(Malformed Request)으로 간주하여 400 Bad Request를 반환하게 됩니다.

결론: POI명 vs 실제 주소

근본적인 문제는 "강남역[2호선]"이 주소가 아니라 POI(Point of Interest) 이름이라는 점입니다. 따라서 결국 데이터 흐름의 구조적인 문제를 해결해야 함을 확인했습니다.

❌ 잘못된 흐름: 강남역[2호선] ➡️ 지오코딩 API ➡️ 400 에러
✅ 올바른 흐름: POI 검색 ➡️ 실제 주소 획득 ➡️ 지오코딩 API ➡️ 성공

해결 방법

1 단계 : POI 검색 결과에서 전체 주소 활용

POI 검색 API의 응답에는 장소명과 함께 실제 주소 정보가 포함되어 있습니다.

POI 검색 API는 장소명(name)과 함께 해당 장소의 정확한 주소 정보를 함께 제공합니다.

name은 사용자가 읽기 쉬운 형태이지만, 특수문자([2호선])가 포함되어 있고 모호할 수 있습니다. 반면 fullAddress는 시/도부터 상세 주소까지 포함된 완전한 형태로, 지오코딩 API가 정확하게 처리할 수 있는 형식입니다.

수정 전

POI 목록에서 장소를 선택하면 name 필드(예: "강남역[2호선]")를 그대로 입력창에 저장하고 있었습니다.

이 값을 그대로 지오코딩 API에 전달하면 특수문자로 인한 URL 인코딩 문제와 함께, "강남역"이라는 모호한 정보만으로는 정확한 좌표를 얻기 어려워 400 에러가 발생했습니다.

수정 후

name 대신 fullAddress를 사용하도록 변경했습니다.

이제 "서울특별시 강남구 역삼동"과 같이 ~~특수문자~~가 없고 행정구역 정보가 모두 포함된 정확한 주소가 지오코딩 API로 전달되어, 정상적으로 좌표 변환이 이루어집니다.

수정 후 화면

위 POI 리스트에서 "강남역[2호선]"을 선택하면 아래와 같이 자연스럽게 fullAddress로 바뀌는 것을 볼 수 있습니다.

이후 경로를 검색하면 정상적으로 경로가 나오게됩니다.

새로운 문제 : UX 저하

문제는 해결되었지만, 새로운 이슈가 발생했습니다.

사용자가 기대하는 것

입력창에 "강남역" 표시

실제로 보이는 것

입력창에 "서울특별시 강남구 역삼동" 표시

사용자 경험이 크게 저하되었습니다.

최종 해결책 : Label과 Value 분리

프론트엔드에서 표시용 데이터(Label)와 실제 사용 데이터(Value)를 분리하여 관리하는 방식으로 개선했습니다.

1. 상태 구조 개선

기존에는 단순히 문자열 하나만 저장했기 때문에, "사용자에게 보여줄 값"과 "API에 전달할 값"을 ~~동시에 관리~~할 수 없었습니다.

상태를 객체 형태로 변경하여 name(화면 표시용)과 address(API 전송용)를 별도로 저장할 수 있도록 개선했습니다.

2. POI 선택 시 두 값 모두 저장

사용자가 POI 목록에서 장소를 선택하면, 두 가지 정보를 동시에 저장합니다.

name에는 "강남역[2호선]"처럼 사용자가 선택한 장소명을 저장하여 입력창에 표시하고, address에는 "서울특별시 강남구 역삼동 "처럼 정확한 주소를 저장하여 나중에 API 호출 시 사용합니다.

이를 통해 UX는 유지하면서 기술적 정확성도 확보할 수 있습니다.

3. UI와 API 호출 분리

입력창(<input>)의 value는 startInfo.name을 사용하여 사용자에게 친숙한 장소명("강남역[2호선]")을 보여줍니다.

반면, 검색 버튼을 클릭했을 때는 startInfo.address를 전달하여 백엔드가 정확한 주소로 지오코딩을 수행할 수 있도록 합니다.

이렇게 화면에 보이는 값과 실제 처리되는 값을 분리함으로써, 사용자 경험과 기술적 요구사항을 모두 충족시킬 수 있습니다.

4. 사용자가 직접 입력한 경우 처리

또한 사용자가 POI 목록에서 선택하지 않고 직접 "강남역"이라고 입력한 후 바로 검색 버튼을 누를 수 있습니다.

이 경우 address는 비어있고 name만 존재하게 됩니다. || 연산자를 사용하여 address가 있으면 우선 사용하고, 없으면 name을 대신 사용하도록 fallback 처리를 추가했습니다.

이를 통해 POI 선택과 직접 입력 두 가지 입력 방식을 모두 지원할 수 있습니다.

최종 수정 후 화면

위 POI 리스트에서 "강남역[2호선]"을 선택하면 화면에는 사용자 친화적인 장소명이 그대로 표시되고, 백엔드로는 정확한 fullAddress가 전달되어 정상적으로 지오코딩이 수행됩니다.

핵심 교훈

1. 외부 API 연동 시 데이터 검증 필수

외부 API는 예상치 못한 입력에 민감합니다. 특수문자, 인코딩, 데이터 형식 등을 철저히 검증해야 합니다.

2. POI명 ≠ 주소

POI명: 사용자가 인식하기 쉬운 장소 이름 ("강남역", "스타벅스")
주소: 시스템이 처리할 수 있는 정확한 위치 정보

둘의 차이를 명확히 이해하고 적절히 변환해야 합니다.

[트러블슈팅] Next.js + Zustand 새로고침 시 로그인 상태 유실 문제 해결하기 (onRehydrateStorage )

지누박 — Tue, 10 Feb 2026 23:38:27 +0900

개요

개인 프로젝트를 진행하던 중 마이페이지에서 새로고침 시 로그인 상태가 유실되어 강제로 로그인 페이지로 리다이렉트되는 문제가 발생했습니다.

로그인에 성공한 후 메인 페이지에서는 인증 상태가 정상적으로 유지되었지만, 페이지에서 새로고침을 하면 localStorage에 유효한 토큰이 남아있음에도 불구하고 사용자를 로그아웃시키는 현상이었습니다.

본 글에서는 이러한 문제에 대한 원인 분석과 해결 과정을 기록하고자 합니다.

문제 상황

문제 현상
- 로그인이 성공하여 메인 페이지에서는 인증 상태가 잘 유지되지만, 마이페이지에서 새로고침을 하면 강제로 로그인 페이지로 리다이렉트됨.
사용자 경험
- 새로고침할 때마다 다시 로그인해야 하는 치명적인 불편함 발생.

원인 분석

문제의 코드

핵심 원인

Zustand의 메모리 기반 특성
- Zustand는 기본적으로 메모리 기반 상태 관리 라이브러리입니다.
- persist 미들웨어를 사용하면 localStorage에 상태를 저장하여 새로고침 후에도 데이터를 유지할 수 있지만, 페이지가 새로고침되는 순간 Zustand 스토어는 일단 초기값(memberId: null)으로 시작됩니다.
Hydration 복구 지연
- 클라이언트 사이드에서 실행될 때, Zustand의 persist 미들웨어가 로컬스토리지에서 데이터를 읽어와 상태를 복구(Hydration)하는 데 수 밀리초의 시간이 소요됩니다.
Race Condition (경쟁 상태)
- 문제는 상태가 복구되기도 전에 useEffect 내의 인증 체크 로직이 먼저 실행된다는 점입니다

t=0ms  : 페이지 새로고침
       → Zustand 스토어 초기화: memberId = null

t=1ms  : useEffect 실행
       → if (!memberId) 조건 충족
       → router.push('/login') <--

t=5ms  : localStorage 복구 완료
       → memberId = "user123" (하지만 이미 늦음)

t=10ms : /login 페이지로 이동 완료

즉, localStorage에 유효한 토큰이 있음에도 불구하고 복구되기 전에 검증 로직이 실행되어 사용자를 강제로 로그아웃시키는 현상이 발생한 것입니다.

Hydration이란❓

Hydration은 Next.js와 같은 SSR/SSG 프레임워크에서 발생하는 서버 렌더링 HTML과 클라이언트 자바스크립트를 연결하는 과정입니다.

Zustand의 persist 미들웨어는 4번 Hydration 단계에서 localStorage의 데이터를 읽어와 전역 상태를 복구합니다.

이 과정은 비동기적이며 수 밀리초가 소요됩니다.

즉, 유효한 인증 정보가 있음에도 복구되기 전에 검증 로직이 실행되어 사용자를 로그아웃시키는 현상입니다.

해결 방법

전략: Rehydration 완료를 보장하는 가드 패턴

Zustand의 onRehydrateStorage 라이프사이클 훅을 활용하여 복구 완료 시점을 명시적으로 추적합니다.

onRehydrateStorage 라이프사이클 훅이란❓

onRehydrateStorage는 Zustand의 persist 미들웨어가 제공하는 라이프사이클 콜백 함수입니다.

Storage에서 저장된 상태를 읽어와 Zustand 스토어에 복구(rehydrate)하는 과정의 시작과 완료 시점을 감지할 수 있게 해주는 훅입니다.

[Step 1] Store에 Hydration 상태 플래그 추가

onRehydrateStorage를 이용해 복구가 끝난 시점을 전역 상태로 관리합니다.

Store에 Hydration 완료 여부를 추적하는 _hasHydrated 플래그를 추가합니다.

onRehydrateStorage 라이프사이클 훅은 localStorage에서 데이터 복구가 완료되는 시점에 자동으로 호출되며, 이때 setHasHydrated(true)를 실행하여 복구 완료 상태를 전역적으로 알립니다.

이 플래그를 통해 컴포넌트들은 "아직 복구 중인지" 혹은 "복구가 끝났는지" 를 정확히 판단할 수 있게 됩니다.

[Step 2] 컴포넌트에 가드 로직 적용

컴포넌트에서 _hasHydrated 플래그를 활용하여 2단계 가드 로직을 구현합니다.

첫 번째 가드
- Hydration이 완료되지 않았다면 인증 검증을 유예하고 조기 반환합니다.
- 이를 통해 복구 전의 null 상태를 "인증 실패"로 오판하는 것을 방지합니다.
두 번째 가드
- Hydration 완료 후에만 실행되며, 이 시점에서 memberId가 없다면 진짜 미인증 상태이므로 로그인 페이지로 리다이렉트합니다.

해결 방법

Next.js 환경에서 Zustand persist를 사용할 때 발생하는 Hydration Race Condition은 예상치 못한 UX 문제를 야기할 수 있습니다.

본 트러블슈팅을 통해 onRehydrateStorage 라이프사이클 훅과 _hasHydrated 플래그를 활용한 가드 패턴으로 이 문제를 근본적으로 해결할 수 있었습니다.

이제 사용자는 새로고침 시에도 안정적으로 로그인 상태를 유지할 수 있게 되었으며, ~~불필요한 재로그인~~ 없이 원활한 서비스 이용이 가능해졌습니다.

클라이언트 상태 관리에서 Hydration 타이밍을 명시적으로 제어하는 것의 중요성을 다시 한번 체감할 수 있었던 경험이었습니다.

[트러블 슈팅] TMAP API 다중 경로 조회 : Mono.zip으로 동시 요청 처리하기

지누박 — Fri, 6 Feb 2026 00:25:33 +0900

개요

개인 지도 API 기반 토이 프로젝트인 "안심 맵(Ansim Map)" 을 개발하던 중, TMAP API 사용 과정에서 단일 경로만 반환되는 파라미터 제약 이슈를 발견했습니다.

사용자에게 "최적 경로"와 "안전한 대로 우선 경로"를 모두 제공하여 선택권을 주려는 프로젝트의 핵심 기능이 구현 불가능한 상황이었고, 이를 Spring WebFlux의 Mono.zip을 활용한 병렬 요청 처리로 해결했습니다.

본 글에서는 문제 상황 분석부터 해결 과정, 그리고 실제 코드 적용까지의 트러블 슈팅 전 과정을 정리하고자 합니다.

문제 상황

개인 토이 프로젝트에서 TMAP 자동차 경로 API를 사용하던 중, 사용자에게 여러 경로 옵션을 제공할 수 없다는 문제에 직면했습니다.

발생한 이슈

TMAP API는 한 번의 요청당 하나의 경로만 반환
사용자가 "최적 경로 A"와 "최적 경로 B"를 비교할 수 없음

기존 코드

원인 분석

TMAP API 공식 문서를 확인한 결과 searchOption 파라미터는 다음과 같습니다.

searchOption 파라미터 명세

타입: Number (단일 숫자 값)
설명: 경로 탐색 옵션
`0`: 교통최적+추천(기본값)
`1`: 교통최적+무료우선
`4`: 교통최적+고속도로우선
`10`: 최단거리+유/무료
`19`: 교통최적+어린이보호구역 회피
기타 옵션...

발견한 제약 사항

searchOption 파라미터는 하나의 숫자 값(단일 값)만 받는 구조
배열이나 여러 값을 동시에 전달할 수 있는 방법이 없음
결론: 다중 경로를 얻으려면 여러 번 요청해야 함

해결 방법

Spring WebFlux의 Mono.zip을 활용하여 두 개의 API 요청을 동시에 실행하고, 결과를 리스트로 묶어 반환하도록 구조를 변경했습니다.

핵심 아이디어

단일 경로가 아닌 다중경로 최적 경로(searchOption=0)와 대로 우선 경로(searchOption=4) 요청을 동시에 생성
Mono.zip으로 두 비동기 작업을 병렬 실행
두 결과를 List로 묶어서 프론트엔드에 전달

코드 수정

✅ 해결 결과

Before (단일 경로)

After (다중 경로 배열)

위 예시에서는 2개의 경로 옵션(최적, 대로 우선)였지만, 실제 프로젝트에서는 사용자에게 더 다양한 선택지를 제공하기 위해 7개의 경로 옵션을 동시에 조회하도록 확장했습니다.

Mono.zip의 장점은 요청 개수가 늘어나도 동일한 패턴으로 확장이 가능하다는 점입니다. 2개든 7개든 모든 요청이 병렬로 처리되어 응답 시간은 가장 느린 단일 요청과 비슷한 수준으로 유지됩니다.

참고 자료

핵심 포인트

TMAP API는 단건 요청만 지원 - 다중 경로는 여러 번 호출 필요
Mono.zip 활용으로 동시 요청 처리하여 성능 최적화
searchOption 0(최적) + 4(대로 우선) 조합으로 사용자 선택권 확보
반환 타입을 List로 변경하여 프론트엔드 통합 용이

[Spring boot] HandlerMethodArgumentResolver 이해하고 활용하기

지누박 — Sun, 1 Feb 2026 22:58:28 +0900

개요

웹 애플리케이션을 개발하다 보면 컨트롤러에서 반복적으로 수행하는 작업들이 있습니다.

헤더에서 토큰을 꺼내서 파싱
쿠키나 세션에서 사용자 정보 가져오기
특정 헤더 값을 객체로 변환하기

특히 스프링 시큐리티를 사용할 때, 인증된 사용자 정보가 SecurityContext의 Principal에 담기는데, 이를 꺼내는 작업도 매번 반복됩니다.

이런 코드가 모든 컨트롤러 메서드마다 반복된다면 코드 중복이 심해지고 유지보수가 어려워집니다.

이때 사용할 수 있는 것이 바로 HandlerMethodArgumentResolver입니다. 오늘은 이 HandlerMethodArgumentResolver에 대해서 공부한 내용을 정리하고자 합니다.

HandlerMethodArgumentResolver란❓

HandlerMethodArgumentResolver는 스프링 MVC에서 컨트롤러 메서드의 파라미터를 유연하게 처리할 수 있게 해주는 인터페이스입니다.

위 Spring 공식 Docs를 보면 다음과 같이 설명하고 있습니다.

주어진 요청의 컨텍스트 내에서 메서드 매개변수를 인자 값으로 변환하기 위한 전략 인터페이스

즉, HTTP 요청이 들어왔을 때 컨트롤러 메서드의 파라미터에 어떤 값을 넣어줄지 결정하는 역할을 합니다.

동작 흐름

1. 클라이언트 HTTP 요청

⬇️

2. DispatcherServlet이 요청 수신

⬇️

3. 적절한 컨트롤러 메서드 찾기

⬇️

4. ArgumentResolver가 파라미터 분석 및 값 주입

⬇️

5. 컨트롤러 메서드 실행

인터페이스 구조

HandlerMethodArgumentResolver는 두 개의 핵심 메서드로 구성되어 있습니다.

supportsParameter()
- 해당 Resolver가 특정 메서드 파라미터를 처리할 수 있는지 여부를 결정합니다.
- 파라미터의 어노테이션, 타입, 이름 등을 검사하여 처리 가능 여부를 판단합니다.
- true를 반환하면 이 Resolver가 해당 파라미터를 처리하게 되며, false를 반환하면 다른 Resolver가 처리를 시도합니다.
- 스프링은 등록된 모든 Resolver를 순회하며 supportsParameter()가 true를 반환하는 첫 번째 Resolver를 사용합니다.
resolveArgument()
- supportsParameter()`가 true를 반환한 경우, 실제로 파라미터에 주입할 값을 생성하고 반환합니다.
- HTTP 요청 정보(NativeWebRequest)를 활용하여 헤더, 쿠키, 세션 등에서 필요한 데이터를 추출할 수 있습니다.
- 생성된 객체는 컨트롤러 메서드의 해당 파라미터에 자동으로 주입됩니다.
- 예외 발생 시 적절한 예외 처리를 통해 클라이언트에게 의미 있는 오류 응답을 제공해야 합니다

구현 단계

1단계 : 커스텀 어노테이션 정의

먼저 컨트롤러 파라미터에 붙일 어노테이션을 만듭니다.

@Target(ElementType.PARAMETER)
- 메서드 파라미터에만 사용 가능하도록 제한
@Retention(RetentionPolicy.RUNTIME)
- 런타임 시점에도 어노테이션 정보를 유지하여 리플렉션으로 읽을 수 있게 함

2단계 : HandlerMethodArgumentResolver 구현

실제로 파라미터 값을 주입하는 Resolver를 구현합니다.

supportsParameter() 메서드
1. @LoginUser 어노테이션이 붙어있는지 확인
2. 파라미터 타입이 "String"인지 확인
3. 두 조건을 모두 만족하면 이 Resolver가 처리
resolveArgument() 메서드
1. SecurityContext에서 현재 인증 정보를 가져옴
2. JWT 필터에서 이미 검증을 마치고 "SecurityContext"`에 저장한 인증 정보
3. "Authentication" 객체에서 사용자 이메일(또는 식별자)을 추출
4. 해당 값을 컨트롤러 메서드의 파라미터로 주입

3단계 : WebMvcConfigurer에 Resolver 등록

만든 Resolver를 스프링에 등록해야 실제로 동작합니다.

WebMvcConfigurer 인터페이스의 addArgumentResolvers() 메서드를 오버라이드하여 우리가 만든 Resolver를 등록합니다.

이제 스프링이 컨트롤러 메서드를 호출할 때 우리가 만든 Resolver를 사용하게 됩니다.

4단계 : 컨트롤러에서 사용

Before : Resolver 사용 전

문제점
- 헤더 파싱 코드가 매번 반복됨
- 토큰 검증 로직이 컨트롤러에 노출됨
- 코드가 길어지고, 가독성 하락
- 인증 로직 변경 시 모든 컨트롤러 수정이 필

After : Resolver 사용

로그아웃 엔드포인트를 보면 @LoginUser 어노테이션 하나로 인증된 사용자의 이메일을 바로 받아올 수 있습니다.

동작 흐름

클라이언트가 JWT 토큰과 함께 /logout 요청
Spring Security Filter에서 JWT 검증 및 "SecurityContext"에 인증 정보 저장
컨트롤러 호출 전 LoginUserArgumentResolver가 동작
"SecurityContext"에서 이메일 추출하여 파라미터에 주입
컨트롤러 메서드 실행

추가 활용 방안 1

이메일 대신 User 객체 전체를 주입하고 싶다면 다음과 같이 수정할 수 있습니다.

컨트롤러에서의 사용

추가 활용 방안 2

로그인하지 않아도 되는 엔드포인트에서 사용하려면 null을 허용하도록 구현합니다.

컨트롤러에서의 사용

마무리

HandlerMethodArgumentResolver를 활용하면 다음과 같은 이점을 얻을 수 있습니다.

코드 중복 제거
- 반복되는 인증 코드를 한 곳에서 관리
관심사 분리
- 비즈니스 로직과 인증 로직을 명확히 분리
가독성 향상
- 컨트롤러가 비즈니스 로직에만 집중
유지보수 용이
- 인증 로직 변경 시 Resolver만 수정
명확한 의도
- @LoginUser 어노테이션으로 "이 API는 로그인 필요"를 명시

다만, 다음과 같은 단점도 고려해야 합니다.

학습 곡선
- 스프링 내부 동작 원리에 대한 이해 필요
디버깅 복잡도
- 실행 흐름 추적이 어려울 수 있음
테스트 설정
- 단위 테스트 작성 시 추가 설정 필요
성능 고려
- DB 조회가 필요한 경우 캐싱 전략 필수

스프링이 제공하는 확장 포인트를 잘 활용하면 더 깔끔하고 유지보수하기 좋은 코드를 작성할 수 있습니다.

특히 인증/인가 로직처럼 모든 엔드포인트에서 반복되는 코드가 있다면, `HandlerMethodArgumentResolver`를 적극 활용해보는 것도 좋은 방법이라고 생각합니다.

물론 프로젝트의 규모와 팀의 상황에 따라 적절히 판단하여 사용하는 것이 중요할 것 같습니다. 작은 프로젝트에서는 오히려 과도한 추상화가 될 수 있으니, 반복 코드가 실제로 문제가 될 때 도입하는 것이 좋을 것 같다는 생각이 듭니다.

이번 글을 통해 HandlerMethodArgumentResolver의 동작 원리와 활용 방법을 정리해볼 수 있었습니다.

참고 자료

[Spring Framework 공식 문서 - HandlerMethodArgumentResolver]

[Spring MVC 공식 가이드]

[Next.js] layout.tsx를 Providers로 감싸야 하는 이유

지누박 — Tue, 27 Jan 2026 02:15:44 +0900

개요

Next.js(App Router)로 개발을 하다 보면 Context API, Query Client, 또는 Theme Provider를 설정할 때 한 번쯤 이런 에러를 마주치게 됩니다.

"Error: Next.js Server Components do not support Context."

보통 layout.tsx에 바로 Provider를 작성하려 할 때 발생합니다. 이번 글에서는 왜 layout.tsx를 별도의 Providers 컴포넌트로 감싸야 하는지, 그 구조적 이유와 이점에 대해서 공부한 내용을 정리해보고자 합니다.

왜 에러가 날까❓

Next.js의 App Router는 기본적으로 모든 컴포넌트를 서버 컴포넌트(Server Components)로 간주합니다.

하지만 React Context, Redux, React Query, Theme Provider 같은 상태 관리 라이브러리들은 클라이언트 사이드에서만 동작합니다.

이들은 React의 useState, useEffect 같은 훅을 사용하기 때문입니다. 여기서 문제가 발생합니다. layout.tsx는 기본적으로 Server Component인데, 클라이언트 전용 기능을 직접 사용할 수 없습니다.

즉, layout.tsx는 애플리케이션의 뼈대를 담당하는 서버 컴포넌트인데, 여기에 직접 createContext나 Provider를 넣으면 "서버 컴포넌트에서 클라이언트 기능을 쓰려고 하네?"라며 에러를 뱉는 것입니다.

해결책: Providers 컴포넌트 분리

이 문제를 해결하기 위해 별도의 providers.tsx 파일을 만들고 'use client' 지시어를 추가합니다.

이렇게 하면 해당 컴포넌트와 그 자식들만 클라이언트 컴포넌트로 동작하게 됩니다.

구현 순서

providers.tsx 생성
- 상단에 'use client' 지시어를 붙여 이 컴포넌트가 클라이언트 사이드에서 동작함을 선언합니다.
layout.tsx에서 주입
- 서버 컴포넌트인 레이아웃에서 위에서 만든 Providers로 {children}을 감쌉니다.

◽app/providers.tsx

◽app/ layout.tsx

이 패턴의 장점

1. 서버 컴포넌트의 이점 유지

layout.tsx 자체를 'use client'로 바꿀 수도 있지만, 그렇게 되면 레이아웃과 그 하위의 모든 컴포넌트가 서버 컴포넌트로서의 이점(SEO 최적화, 번들 사이즈 감소 등)을 잃게 됩니다.
Providers로만 감싸면, 레이아웃은 서버 컴포넌트로 남기면서 내부의 상태만 클라이언트에서 관리할 수 있습니다.

2. Children은 서버 컴포넌트일 수 있다.

"클라이언트 컴포넌트(Providers)의 children으로 전달되는 서버 컴포넌트는 여전히 서버 컴포넌트로 동작한다"는 특성 덕분입니다.
따라서 전체 페이지를 감싸더라도 각 페이지(page.tsx) 안의 로직들은 여전히 서버에서 빠르게 처리될 수 있습니다.

3. 관심사의 분리

전역 상태 관리 로직을 별도 파일로 분리하여 코드 가독성과 유지보수성이 향상됩니다.

4. 일관된 상태 유지

전역 상태(Redux, React Query, Auth 등)는 앱 전체에서 공유되어야 합니다.
layout.tsx는 페이지가 바뀌어도 리렌더링되지 않고 유지되는 특성이 있어, 이곳에 Provider를 배치하는 것이 상태를 유실하지 않는 가장 안정적인 방법입니다.

children은 어떻게 서버 컴포넌트로 유지될까❓

여기서 저는 한 가지 의문이 생겼습니다.

Providers가 클라이언트 컴포넌트('use client')라면, 그 안에 감싸진 자식들도 전부 클라이언트 컴포넌트가 되는 것 아닌가?

결론부터 말하자면 이는 "아니다"라는게 맞습니다. 그 이유에 대해서 알아보겠습니다.

Composition Pattern이란?

React의 Composition Pattern은 컴포넌트를 import해서 직접 사용하는 것과 props(children)로 전달받아 사용하는 것을 구분합니다.

Import 방식 (서버 -> 클라이언트 변환됨) ❌

클라이언트 컴포넌트가 서버 컴포넌트를 직접 import하면, 서버 컴포넌트도 클라이언트 컴포넌트로 변환됩니다.

Composition 방식 (서버 컴포넌트 유지) ✅

이 경우 ServerComponent는 서버에서 먼저 렌더링되고, 그 결과가 ClientComponent에 props로 전달됩니다.

왜 이런 차이가 생길까❓

◽Composition Pattern

서버: layout.tsx가 실행됨
서버: <ServerComponent />가 렌더링됨 → RSC Payload 생성
서버: 렌더링 결과를 children props로 전달
클라이언트: ClientComponent가 받은 children을 그대로 표시

◽Import Pattern

클라이언트: ClientComponent가 실행됨
클라이언트: ServerComponent를 import했으므로 여기서 렌더링해야 함
결과: 서버 컴포넌트가 클라이언트에서 실행됨 (변환됨)

따라서, 클라이언트 컴포넌트(Providers)의 children으로 전달되는 서버 컴포넌트는 여전히 서버 컴포넌트로 동작합니다.

결론

layout.tsx를 Providers로 감싸는 패턴은 Next.js App Router에서 서버와 클라이언트의 장점을 모두 살리는 핵심 패턴입니다.

Composition Pattern 덕분에 전역 상태 관리와 서버 사이드 렌더링을 동시에 활용할 수 있고, 성능 최적화와 개발 경험 모두를 향상시킬 수 있습니다.

국내외 지도 API 비교해보기 (구글, 네이버, 카카오)

지누박 — Thu, 22 Jan 2026 00:05:17 +0900

개요

프로젝트를 하다보면 지도를 사용해야할 경우가 있습니다. 토이 프로젝트를 진행하면서 지도 API를 사용해야 했는데, 본 글에서는 여러 지도 API들을 비교하면서 각각의 특징과 장단점을 정리해보고자 합니다.

개발 환경은 백엔드 Spring Boot, 프론트엔드 React + Next.js를 기준으로 작성했습니다.

1. Google Maps API

Google Maps Platform - 3D 지도 및 지리 공간 분석

상세한 지리 공간 데이터와 예측 가능한 가격으로 차량 공유 및 배송 서비스를 지원하세요. 이 모든 작업을 차량, 자산, 기기를 동적으로 추적하면서 수행할 수 있습니다.

mapsplatform.google.com

Google Maps API는 전 세계에서 가장 널리 사용되는 지도 서비스입니다.

강력한 기능과 방대한 데이터를 자랑하며, 글로벌 서비스 개발에 필수적인 선택지입니다.

주요 특징

1. 전세계 커버리지

전 세계 거의 모든 지역의 지도 데이터 제공
위성 이미지, 스트리트 뷰 등 다양한 뷰 옵션
실시간 교통 정보, 대중교통 정보 제공

2. 풍부한 키능

Places API: 장소 검색, 상세 정보, 리뷰 등
Directions API: 경로 탐색 (자동차, 도보, 대중교통, 자전거)
Geocoding API: 주소-좌표 변환
Distance Matrix API: 여러 출발지-목적지 간 거리/시간 계산

장점

전세계 데이터 품질: 해외 지역 정보의 정확도와 최신성이 뛰어남
안정적인 인프라: 구글의 강력한 서버 인프라로 다운타임이 거의 없음
풍부한 레퍼런스: 전 세계적으로 사용되어 문제 해결이 쉬움

단점

국내 지리 정보 한계: 한국 지도의 정확도가 네이버, 카카오 대비 떨어짐
국내 길찾기 부정확: 한국 내 경로 탐색의 정확도가 낮음 (도로 상황 반영 미흡)
가격 정책: 무료 크레딧 초과 시 비용이 빠르게 증가
한글 문서 부족: 대부분의 문서가 영문으로 작성됨

2. Naver Map API

NAVER CLOUD PLATFORM

cloud computing services for corporations, IaaS, PaaS, SaaS, with Global region and Security Technology Certification

www.ncloud.com

네이버 지도 API는 국내에서 가장 정확하고 상세한 지도 데이터를 제공합니다.

개인적으로 가장 많이 사용하는 API이며, 한국 서비스 개발에 최적화되어 있습니다.

주요 특징

1. 국내 최고 수준의 정확

한국 지역 도로, 건물, 지형 정보의 정확도가 매우 높음
실시간 교통 정보 (네이버만의 강점)
최신 건물 및 도로 정보 빠른 반영

2. 개발자 친화적

한글로 작성된 상세한 문서
다양한 예제 코드 제공
빠른 기술 지원

장점

국내 데이터 압도적 정확도
훌륭한 문서화: docs가 정말 자세하게 되어 있어 개발이 편함
넉넉한 무료 한도: 월 10,000,000건 무료 (대부분의 프로젝트에 충분)
실시간 교통 정보: 네이버만의 차별화된 강점
지도 커스터마이징: 다양한 스타일과 옵션 제공

단점

키워드 검색 불가: 장소 검색 시 주소로만 검색 가능 (키워드 검색 불가)
해외 데이터 제한: 해외 지역 정보는 구글 대비 부족

3. Kakao Map API

https://apis.map.kakao.com/

카카오 지도 API는 강력한 장소 검색 기능으로 유명합니다.

카카오의 방대한 POI(Point of Interest) 데이터를 활용할 수 있어, 장소 기반 서비스에 최적입니다.

주요 특징

1. 강력한 장소 검색

키워드 검색 API 제공 (네이버와의 가장 큰 차이점)
카테고리별 장소 검색
카카오플레이스 데이터 연동

2. 카카오 생태계 통합

카카오톡 공유 기능 연동
카카오내비 연동
카카오모빌리티 데이터 활용

장점

키워드 검색 강력: "강남역 카페", "근처 편의점" 같은 자연어 검색 가능
풍부한 POI 데이터: 카카오플레이스의 방대한 장소 정보
카카오 생태계: 카카오톡, 카카오내비와의 자연스러운 연동
직관적인 API: 사용하기 쉬운 RESTful API 구조
장소 상세 정보: 영업시간, 리뷰, 사진 등 풍부한 정보

단점

일일 쿼터 제한: 1일 300,000건으로 네이버 대비 적음
해외 데이터: 해외 지역 정보는 제한적

4. OSM (OpenStreetMap)

오픈스트리트맵 이용하기

전 세계의 지리공간 정보를 날것 그대로 보고, 원하는 대로 조작하고, 복잡한 저작권 문제 없이 (‘ⓒOpenStreetMap 기여자’만 적어서) 배포하는 것은 오픈스트리트맵만의 특권입니다.

osm.kr

OpenStreetMap은 오픈소스 기반의 무료 지도 서비스입니다.

뮤니티가 직접 데이터를 만들고 관리하며, 완전히 무료로 사용할 수 있습니다.

주요 특징

1. 오픈소스 기반

완전 무료 사용 (상업적 이용 포함)
데이터 직접 수정 및 기여 가능
다양한 오픈소스 라이브러리 활용 가능

2. OSRM (Open Source Routing Machine) 연동

무료 길찾기 기능
거리 행렬 계산
경로 최적화

장점

완전 무료: 사용량 제한 없이 무료
오픈소스: 코드와 데이터를 자유롭게 사용 및 수정
데이터 기여: 직접 지도 데이터를 수정하고 개선 가능
라이선스 자유: 상업적 이용에도 제약이 거의 없음

단점

국내 정확도: 상용 서비스 대비 데이터 정확도가 낮음
데이터 최신성: 실시간 업데이트가 느림
안정성: 자체 서버 구축 필요 시 인프라 관리 부담
기능 제한: 상용 API만큼 다양한 기능 제공 어려움
한글 지원: 한글 문서와 지원이 부족

5. Mapbox API

Mapbox | Maps, Navigation, Search, and Data

APIs and SDKs for AI-powered maps, location search, turn-by-turn navigation, and geospatial data in mobile or web apps. Get started for free.

www.mapbox.com

Mapbox는 데이터 시각화와 커스터마이징에 특화된 지도 서비스입니다.

다양한 테마의 지도 디자인이 필요한 경우 최고의 선택입니다.

주요 특징

1. 강력한 커스터마이

Mapbox Studio를 통한 직관적인 스타일 편집
실시간 데이터 시각화
3D 지형, 건물 렌더링
애니메이션 효과

2. 데이터 시각

히트맵, 클러스터링
대용량 데이터 처리
실시간 데이터 업데이트
벡터 타일 기반 렌더링

장점

최고 수준의 커스터마이징: 지도 스타일을 완전히 자유롭게 변경 가능
데이터 시각화: 복잡한 데이터를 아름답게 표현
성능: 벡터 타일 기반으로 빠른 로딩과 부드러운 인터랙션
3D 지원: 3D 건물, 지형 표현 가능
개발자 경험: 잘 설계된 API와 풍부한 문서

단점

국내 데이터 제한: 한국 지역 상세 정보 부족
높은 비용: 무료 티어 이후 비용이 높은 편
러닝 커브: 고급 기능 사용 시 학습 시간 필요
한글 지원: 한글 문서 부족

어떤 API를 선택해야할까❓

이 부분은 제가 실제로 프로젝트를 진행하며 경험한 내용을 바탕으로 작성한 개인적인 의견입니다. 정답이 있는 것이 아니며, 프로젝트의 특성과 요구사항에 따라 최적의 선택은 달라질 수 있습니다.

프로젝트 상황별 추천

◽비용이 가장 중요하다면

→ OSM (OpenStreetMap)

완전 무료로 사용할 수 있어 초기 스타트업이나 토이 프로젝트에 적합합니다.
다만 개발 리소스와 시간 투자가 필요하다는 점을 고려해야 합니다.

◽ 국내 서비스를 개발한다면

→ Naver Map API

제가 가장 많이 사용하는 선택입니다.
국내 데이터 정확도가 압도적이고, 한글 문서가 잘 되어 있어 개발 속도가 빠릅니다.
월 1천만 건의 넉넉한 무료 한도도 큰 장점입니다.

◽장소 검색이 핵심 기능이라면

→ Kakao Map API

"강남역 맛집", "근처 카페" 같은 키워드 검색이 필요하다면 카카오가 최선의 선택입니다.
네이버는 주소 기반 검색만 지원하므로 장소 검색 기능에서는 카카오를 따라갈 수 없습니다.

◽ 글로벌 서비스를 개발한다면

→ Google Maps API

해외 지역 정보가 필요하다면 구글 외에는 대안이 없습니다.
전 세계 데이터 품질과 안정성은 구글이 압도적입니다.

◽데이터 시각화가 중요하다면

→ Mapbox API

대시보드나 분석 툴처럼 데이터를 지도 위에 시각화해야 한다면 Mapbox의 강력한 커스터마이징 기능이 빛을 발합니다.
3D 표현이나 독특한 스타일이 필요한 경우에도 최적입니다.

[Spring boot] 우리가 보낸 객체는 어떻게 서버까지 흘러갈까? (직렬화와 역직렬화)

지누박 — Tue, 13 Jan 2026 19:21:30 +0900

개요

웹 개발을 하다 보면 프론트엔드에서 서버로 데이터를 보내고 받는 일이 일상적입니다.

그런데 우리가 JavaScript 객체로 다루던 데이터가 어떻게 서버까지 전달되고, 다시 객체로 돌아오는 걸까요? 이 과정의 핵심에는 직렬화(Serialization)와 역직렬화(Deserialization)라는 개념이 있습니다.

이번 글에서는 직렬화의 필요성과 어떻게 직렬화가 되는지에 대해서 정리하고자 합니다.

프론트엔드에서의 객체 관리

프론트엔드에서는 HTTP 요청을 다음과 같이 객체 형태로 관리합니다.

const httpRequestMessage = {
    headers: {
        'Content-Type': 'application/json',
        'Content-Length': 20,
        'Accept': '*/*'
    },
    body: {
        userId: "abc",
        password: "1234"
    }
}

실제 요청을 보낼 때는 axios 같은 라이브러리를 사용해 간단하게 처리합니다.

await axios.post(`${BASE_URL}/auth/signup`, {
    userId: "abc",
    password: "1234"
});

네트워크를 통한 전송 : 문자열로의 변환

그런데 실제로 서버로 요청이 전송될 때는 다음과 같은 문자열 형태로 변환됩니다.

POST /auth/signup HTTP/1.1
Content-Type: application/json
Content-Length: 20

{"userId": "abc", "password": "1234"}

왜 문자열로 변환해야 할까요❓

네트워크를 통해 데이터를 전송하려면 반드시 연속된 바이트 스트림(문자열)이어야 하기 때문입니다. 객체 형태는 개발자가 조작하기 편하도록 만든 추상화일 뿐, 실제 전송 시에는 문자열로 변환되어야 합니다.

객체를 그대로 보낼 수 없는 이유

1. 메모리 구조의 이해

RAM은 거대한 배열입니다.
JavaScript에서 객체를 생성하면 이는 메모리 상에 다음과 같이 흩어져 저장됩니다.

스택: httpRequestMessage → 주소 1000
힙(1000): { headers: 주소 2000, body: 주소 3000 }
힙(2000): { 'Content-Type': 'application/json', ... }
힙(3000): { userId: "abc", password: "1234" }

객체의 실제 데이터는 힙(Heap) 영역 곳곳에 흩어져 있고, 각각은 메모리 주소로 참조됩니다.

주소를 보내면 안 되는 이유

만약 httpRequestMessage의 주소(예: 1000)를 그대로 네트워크를 통해 서버로 보낸다면 어떻게 될까요?

서버는 자신의 메모리 주소 1000번지를 참조하게 되고, 이는 브라우저가 보낸 데이터와는 전혀 다른 데이터입니다. 각 컴퓨터는 독립적인 메모리 공간을 가지고 있기 때문에, 메모리 주소는 해당 프로세스 내에서만 의미가 있습니다.

결론적으로, 메모리 상에 흩어져 있는 데이터를 모두 모아서 하나의 연속된 문자열로 만들어야 합니다.

직렬화 & 역직렬화

직렬화 : 객체를 문자열로

직렬화는 메모리 상에 흩어져 있는 객체를 일렬로 나열된 문자열로 변환하는 과정입니다.

// 객체 (메모리 여기저기 흩어져 있음)
const data = { userId: "abc", password: "1234" };

// 직렬화 (연속된 문자열)
const serialized = JSON.stringify(data);
// '{"userId":"abc","password":"1234"}'

이 문자열은 결국 2진수의 연속체(바이트열)로 변환되어 네트워크를 통해 전송됩니다.

01010000 01001111 01010011 01010100 00100000 00101111 ...
P        O        S        T        (space)  /        ...

위 그림에서 볼 수 있듯이 Binary Encoder를 하면 문자열은 2진수의 연속체인것을 알 수 있습니다.

역직렬화 : 문자열을 다시 객체로

서버에서는 받은 바이트열을 먼저 문자열로 복원하고, 이를 다시 객체로 변환합니다. 이것이 바로 역직렬화입니다.

// 서버에서 받은 문자열
const received = '{"userId":"abc","password":"1234"}';

// 역직렬화 (다시 객체로)
const data = JSON.parse(received);
// { userId: "abc", password: "1234" }

역직렬화를 통해 연속된 바이트열을 다시 메모리의 힙 영역 곳곳에 퍼트려 객체 구조를 복원합니다.

객체로 다루지 않으면 어떻게 될까❓

// 이런 식으로 파싱해야 합니다
const rawString = 'POST /auth/signup HTTP/1.1\nContent-Type: application/json\n\n{"userId":"abc"}';

// HTTP 메서드 추출
const method = rawString.slice(0, rawString.indexOf(' '));

// URL 추출
const urlStart = rawString.indexOf(' ') + 1;
const urlEnd = rawString.indexOf(' ', urlStart);
const url = rawString.slice(urlStart, urlEnd);

// 헤더 파싱
const headerSection = rawString.slice(rawString.indexOf('\n') + 1, rawString.indexOf('\n\n'));
// ... 계속 문자열 조작

이는 C언어에서 네트워크 프로토콜을 다루는 것처럼 매우 번거롭습니다. 반면 객체로 다루면 다음과 같이 간단하게 데이터에 접근 할 수 있습니다.

httpRequestMessage.headers['Content-Type']

직렬화
- 메모리 상에 흩어져 있는 객체를 연속된 문자열(바이트열)로 변환하는 과정
- 객체 ➡️ 문자열
역직렬화
- 연속된 문자열(바이트열)을 다시 메모리 상의 객체로 복원하는 과정
- 문자열 ➡️ 객체

정리하자면, 네트워크 통신에서 직렬화와 역직렬화가 필요한 이유는 다음과 같습니다.

네트워크는 연속된 바이트 스트림만 전송할 수 있습니다
메모리 주소는 각 프로세스마다 독립적이어서 ~~그대로 전송~~할 수 없습니다
개발자는 객체 형태로 데이터를 다루는 것이 훨씬 편리합니다

결국 직렬화와 역직렬화는 개발 편의성과 네트워크 전송 요구사항 사이의 완벽한 타협점인 셈입니다.

예시 코드

그렇다면 실제로 클라이언트에서 보낸 데이터가 서버에서 어떻게 받고, 어떻게 직렬화,역직렬화가 되는 지 코드로 살펴보겠습니다.

package com.example.serialization.controller;

import com.example.serialization.dto.SignupRequest;
import com.example.serialization.dto.SignupResponse;
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.datatype.jsr310.JavaTimeModule;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

import java.nio.charset.StandardCharsets;
import java.time.LocalDateTime;
import java.util.Arrays;

@RestController
@RequestMapping("/auth")
public class AuthController {

    private final ObjectMapper objectMapper = new ObjectMapper();

    /**
     * [POST] 직렬화(Serialization) 과정 확인
     * 클라이언트가 보낸 데이터가 어떻게 이진수 연속체로 변하는지 보여줍니다.
     */
    @PostMapping("/signup")
    public void showSerialization(@RequestBody SignupRequest request,
                                  @RequestHeader(value = "Content-Type") String contentType) throws Exception {

        String jsonBody = objectMapper.writeValueAsString(request);
        String rawHttpRequest = "POST /auth/signup HTTP/1.1\n" +
                "Content-Type : " + contentType + "\n\n" +
                jsonBody;

        byte[] bytes = rawHttpRequest.getBytes(StandardCharsets.UTF_8);
        StringBuilder binaryStream = new StringBuilder();
        for (byte b : bytes) {
            binaryStream.append(String.format("%8s", Integer.toBinaryString(b & 0xFF)).replace(' ', '0'));
        }

        System.out.println("\n[클라이언트에서 보낸 데이터 (Raw 문자열)]");
        System.out.println(rawHttpRequest);

        System.out.println("\n[서버가 수신한 데이터 (직렬화된 이진수 연속체)]");
        System.out.println(binaryStream.toString());

        System.out.println( );
    }

    /**
     * [GET] 역직렬화(Deserialization) 과정 확인
     * 수신한 문자열이 어떻게 다시 Java 객체로 복원되는지 보여줍니다.
     */
    @GetMapping("/user-info")
    public void showDeserialization() throws Exception {
        // 서버가 수신한 데이터라고 가정 (Raw 문자열)
        String receivedRaw = "{\"userId\":\"testUser\",\"password\":\"password123\"}";

        // 역직렬화 진행 (문자열 -> 객체)
        SignupRequest restoredObj = objectMapper.readValue(receivedRaw, SignupRequest.class);

        System.out.println("\n[서버가 수신한 데이터 (Raw 문자열)]");
        System.out.println(receivedRaw);

        System.out.println("\n[역직렬화된 후 객체 (Java Object)]");
        System.out.println("객체 정보: " + restoredObj);

    }
}

1. 데이터의 출발: 클라이언트에서의 직렬화

클라이언트가 객체를 전송하면, 네트워크를 타고 가기 위해 데이터는 이진수(Binary)의 형태로 바뀝니다.

위 로그를 보면 알 수 있듯이, 클라이언트에서 보낸 객체는 서버에 도착할 때 ~~우리가 읽을 수 없는~~ 바이트(이진수) 문자열로 보내진 것을 확인할 수 있습니다.

컴퓨터는 오직 이 '0'과 '1'의 조합만을 이해하며 데이터를 주고받습니다.

2. 텍스트로의 변환 (JSON)

01010000010011110101001101010100001000000010111101100001011101010111010001101000001011110111001101101001011001110110111001110101011100000010000001001000010101000101010001010000001011110011000100101110001100010000101001000011011011110110111001110100011001010110111001110100001011010101010001111001011100000110010100100000001110100010000001100001011100000111000001101100011010010110001101100001011101000110100101101111011011100010111101101010011100110110111101101110000010100000101001111011001000100111010101110011011001010111001001001001011001000010001000111010001000100111010001100101011100110111010001010101011100110110010101110010001000100010110000100010011100000110000101110011011100110111011101101111011100100110010000100010001110100010001001110000011000010111001101110011011101110110111101110010011001000011000100110010001100110010001001111101

실제 바이트 문자열은 위와 같습니다.

서버는 수신한 이진 데이터를 설정된 인코딩(UTF-8)에 맞춰 우리가 읽을 수 있는 텍스트로 해석합니다. 이것이 바로 HTTP Body에 담긴 JSON 문자열입니다.

바이트 데이터를 문자열로 변환하니, 이제야 비로소 우리가 의도했던 데이터의 형태가 보이기 시작합니다. 하지만 아직은 단순한 '글자'일 뿐, 자바가 다룰 수 있는 ~~'객체'~~는 아닙니다.

3. 서버에서의 역직렬화 (Java Object)

이제 Spring의 ObjectMapper가 이 JSON 문자열을 분석하여 실제 자바 클래스인 SignupRequest 객체에 값을 채워넣습니다. 이 과정을 역직렬화(Deserialization)라고 합니다.

보시다시피 최종적으로는 클라이언트가 보낸 데이터가 자바 객체 형태로 복원된 것을 알 수 있습니다. 이제 개발자는 request.getUserId()와 같은 메서드를 통해 데이터를 자유롭게 사용할 수 있게 됩니다.

Spring Boot는 내부적으로 Jackson이라는 강력한 라이브러리를 사용하여 이 복잡한 과정을 처리합니다. 덕분에 우리는 바이트 단위의 데이터를 고민할 필요 없이 @RequestBody 어노테이션 하나로 편리하게 객체를 받아볼 수 있는 것입니다.

[Prometheus] 시계열 데이터 분석을 위한 Prometheus Query(promQL) 이해하기

지누박 — Sun, 11 Jan 2026 18:58:07 +0900

개요

회사에서 모니터링 프로젝트를 하던 중 추이 분석 관련 그래프, 언제 트래픽이 있었는지 등 시계열 데이터를 조회하고 분석해야하는 상황이 있었습니다.

저희 프로젝트는 sql-exporter를 사용해서 메트릭 데이터를 프로메테우스에 저장하고있어 이 메트릭 데이터를 효과적으로 질의할 수 있어야했습니다.

이때 활용했던 방법이 PromQL인데, 이번 글에서는 PromQL란 무엇인지, 주요 용도, 주요 사용되는 내장 함수 등을 정리하고자 합니다.

PromQL (Prometheus Query Language)이란❓

PromQL이란?

Prometheus 모니터링 시스템에서 시계열 데이터를 조회하고 분석하기 위한 전용 쿼리 언어입니다.
SQL과 유사하게 데이터를 질의하지만, 시계열 데이터에 특화되어 있어 시간의 흐름에 따른 메트릭 변화를 효과적으로 분석할 수 있습니다.
즉, Promethues에서는 PromQL을 이용해서 TSDB(Time Series Database)를 제어할 수 있습니다.

데이터 구조

Prometheus는 데이터를 저장할 때 다음과 같은 형식을 사용합니다.

metric_name{label1 = "value1", label2 = "value2",...}

메트릭 이름(Metric Name)
- 측정하려는 값의 본질 (예: cpu_usage - 전체 CPU 사용량)
레이블(Labels)
- 그 값의 구체적인 속성 (예: method="GET", status="200", instance="server-01")

레이블을 활용한 실제 예시

만약 웹 서버의 에러율을 분석하고 싶다면, 레이블을 통해 다음과 같이 필터링하거나 그룹화할 수 있습니다.

사용 목적	PromQL 예시	설명
특정 데이터 필터링	http_requests_total{status="500"}	상태 코드가 500(에러)인 데이터만 골라냅니다.
다중 조건 필터링	http_requests_total{method="POST", env="prod"}	운영 환경(prod)이면서 POST 방식인 데이터만 조회합니다.
차원별 그룹화(집계)	sum by (method) (http_requests_total)	모든 서버의 요청을 '메소드별'로 합산하여 보여줍니다.

PromQL의 주요 특징

1. 시계열 데이터 특화

시간에 따라 변하는 데이터를 자연스럽게 다룰 수 있습니다.

2. 표현식 기반

함수형 프로그래밍 스타일로 복잡한 쿼리를 간결하게 작성할 수 있습니다

3. 레이블 기반 필터링

다차원 데이터를 레이블을 통해 유연하게 필터링하고 그룹화할 수 있습니다.

다차원 데이터 레이블이란❓

- 레이블은 메트릭에 붙는 키-값(Key-Value) 쌍으로, 데이터의 개별 속성을 정의하는 다차원 식별자 역할을 합니다.
- 동일한 메트릭(예: http_requests_total)이라도 레이블(예: method, status, service)에 따라 데이터를 다각도로 쪼개거나 합쳐서 분석할 수 있습니다.

4. 실시간 쿼리

실시간으로 데이터를 조회하고 계산할 수 있어 즉각적인 모니터링이 가능합니다

PromQL의 장단점

장점

1. 강력한 시계열 데이터 분석 능력

시간의 흐름에 따른 데이터 변화를 쉽게 추적하고 분석할 수 있습니다.
증가율, 평균, 백분위수 등 다양한 통계를 간단한 함수로 계산할 수 있습니다.

2. 직관적인 레이블 기반 필터링

여러 차원의 데이터를 레이블을 통해 자유롭게 필터링하고 그룹화할 수 있어, 복잡한 조건의 데이터도 명확하게 조회할 수 있습니다.

3. 풍부한 내장 함수

집계, 변환, 예측 등 다양한 내장 함수를 제공하여 복잡한 계산도 간단하게 수행할 수 있습니다.

4. 시각화 도구와의 뛰어난 통합

Grafana, Prometheus UI 등 주요 모니터링 대시보드 도구들과 완벽하게 통합되어 즉시 시각화가 가능합니다.

5. 알림 규칙 설정 용이

임계값 기반 알림을 쉽게 설정할 수 있어, 시스템 이상 징후를 자동으로 감지할 수 있습니다.

6. 클라우드 네이티브 생태계 표준

Kubernetes, Docker 등 현대적인 인프라 환경에서 널리 채택된 표준 쿼리 언어입니다.

단점

1. 초기 학습 곡선

SQL에 익숙한 사용자라도 시계열 데이터 특유의 개념과 문법을 새로 학습해야 합니다.

2. SQL과의 문법 차이

기존 SQL 지식을 직접 활용하기 어렵고, 새로운 문법 체계에 적응이 필요합니다.

3. 복잡한 쿼리의 성능 이슈

여러 메트릭을 조인하거나 복잡한 계산을 수행할 때 성능 저하가 발생할 수 있습니다.

4. 장기 데이터 보관의 어려움

시계열 데이터의 특성상 데이터가 빠르게 증가하여 스토리지 관리와 비용 고려가 필요합니다.

5. 제한적인 데이터 타입

주로 숫자형 메트릭 데이터만 다루며, 문자열이나 복잡한 데이터 구조 처리에는 제약이 있습니다.

PromQL의 데이터 타입

PromQL에서 다루는 데이터는 크게 4가지 타입으로 분류됩니다. 각 타입을 정확히 이해하면 복잡한 쿼리도 쉽게 작성할 수 있습니다.

1. Instant Vector

정의
- 같은 시점(동일한 타임스탬프)을 가진 시계열 데이터의 집합입니다.
- 즉, 여러 시계열의 "현재 순간" 값들을 모아놓은 것입니다.
특징
- 각 시계열마다 가장 최근의 단일 값만을 가집니다
- 같은 타임스탬프를 공유하는 여러 시계열로 구성됩니다
- 그래프(Graph) 뷰에서 시간 흐름에 따라 선으로 표시됩니다
- 대부분의 PromQL 쿼리가 Instant Vector를 반환합니다
- 레이블이 다르면 각각 별도의 시계열로 취급됩니다
기본 예시

# 모든 HTTP 요청 메트릭의 현재 값
http_requests_total

# 레이블 필터링
http_requests_total{method="GET", status="200"}

2. Range Vector

정의
- 특정 시간 범위 동안 기록된 시계열 데이터의 집합입니다.
특징
- 현재를 기준으로 과거 일정 기간의 데이터를 배열 형태로 가집니다
- [5m], [1h], [30d] 같은 시간 범위 선택자를 사용합니다
- 직접 그래프로 표시할 수 없습니다
- 주로 rate(), increase(), avg_over_time() 같은 함수의 입력값으로 사용됩니다
시간 범위 표기법
- s - 초 (seconds)
- m - 분 (minutes)
- h - 시간 (hours)
- d - 일 (days)
- w - 주 (weeks)
- y - 년 (years)
기본 예시

# 최근 5분간의 HTTP 요청 데이터
http_requests_total[5m]

# 최근 1시간의 CPU 사용 데이터
cpu_usage_seconds[1h]

3. Scalar (스칼라)

정의
- 시간 정보나 레이블 정보가 없는 단순한 숫자(부동 소수점) 값입니다.
특징
- ~~특정 시계열에 속하지 않는~~ 순수한 숫자입니다
- ~~타임스탬프~~나 ~~레이블~~을 가지지 않습니다
- 쿼리 내에서 상수로 사용되거나 연산에 활용됩니다
- 일부 함수는 Scalar 값을 반환합니다
기본 예시

# 리터럴 숫자
100
3.14

# 연산에서 활용
memory_used_bytes / 1024 / 1024  # MB 단위 변환
cpu_usage_percent > 80  # 임계값 비교

4. String (문자열)

정의
- 단순한 문자열 값입니다.
특징
- 현재 PromQL에서는 매우 제한적으로 사용됩니다
- 주로 함수의 인자나 레이블 값으로만 사용됩니다
- ~~메트릭 값으로는 사용~~할 수 없습니다 (Prometheus는 숫자형 데이터만 저장)
- ~~연산에 직접적으로 사용~~되지 않습니다
기본 예시

# 레이블 필터링에서 사용
http_requests_total{method="GET"}

# 정규표현식 매칭
http_requests_total{status=~"5.."}

PromQL의 주요 내장 함수

1. 증가율 계산 함수

rate() : 지정된 시간 범위 동안의 초당 평균 증가율을 계산

입력: Range Vector ➡️ 출력: Instant Vector

# 최근 5분간 초당 평균 요청 수
rate(http_requests_total[5m])

# 엔드포인트별 초당 요청 수
rate(http_requests_total[5m]) by (endpoint)

사용 경우
- Counter 타입 메트릭의 증가율 계산
- 알림 규칙 설정
- 장기 추세 파악

irate() : 현재 순간의 즉시 증가율을 계산

# 현재 순간의 초당 요청 수
irate(http_requests_total[5m])

현재 순간의 즉시 증가율을 계산합니다. 단, 최근 두 데이터 포인트만 사용됩니다.
rate() vs irate()
- rate() : 완만한 그래프, 평균값, 알림용
- irate() : 민감한 그래프, 즉각 반응, 실시간 모니터링용

increase() : 지정된 시간 범위 동안의 총 증가량을 계산

# 최근 1시간 동안의 총 요청 수
increase(http_requests_total[1h])

2. 집계 함수

sum() : 메트릭 값들의 합계 계산

입력: Instant Vector ➡️ 출력: Instant Vector (또는 Scalar)

# 모든 인스턴스의 총 요청 수
sum(rate(http_requests_total[5m]))

# 엔드포인트별 총 요청 수
sum(rate(http_requests_total[5m])) by (endpoint)

# instance 레이블을 제외하고 합계
sum(rate(http_requests_total[5m])) without (instance)

그룹화
- by (label): 지정한 레이블로만 그룹화
- without (label): 지정한 레이블을 제외하고 그룹화

avg(), max(), min() : 평균, 최대값, 최소값을 계산

# 평균 CPU 사용률
avg(cpu_usage_percent) by (instance)

# 최대 메모리 사용량
max(memory_usage_bytes) by (instance)

# 최소 디스크 여유 공간
min(disk_free_bytes) by (mount_point)

count() : 메트릭 개수 계산

입력: Instant Vector ➡️ 출력: Instant Vector (또는 Scalar)

# 정상 상태인 인스턴스 수
count(up == 1)

# 80% 이상 CPU를 사용하는 서버 개수
count(cpu_usage_percent > 80)

topk(), bottomk() : 상위/하위 k개의 시계열 선택

# CPU 사용률 상위 5개 인스턴스
topk(5, cpu_usage_percent)

# 메모리 사용량 하위 3개 서버
bottomk(3, memory_usage_bytes)

3. 시간 범위 함수

avg_over_time() : 시간 범위 내의 평균값을 계산

입력: Renge Vector ➡️ 출력: Instant Vector (또는 Scalar)

# 최근 5분간 평균 CPU 사용률
avg_over_time(cpu_usage_percent[5m])

# 최근 1시간 평균 응답 시간
avg_over_time(http_response_time_seconds[1h])

max_over_time(), min_over_time() : 시간 범위 내의 최대/최소값 찾기

# 최근 1시간 최대 CPU 사용률 (피크)
max_over_time(cpu_usage_percent[1h])

# 최근 5분간 최대 응답 시간
max_over_time(http_request_duration_seconds[5m])

4. 백분위수 계산 함수

histogram_quantile() : 히스토그램 데이터에서 특정 백분위수 계산

입력: Scalar(분위수), Instant Vector(히스토그램) ➡️ 출력: Instant Vector

# 95 백분위수 응답 시간
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

# 99 백분위수 응답 시간
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

# 엔드포인트별 95 백분위수
histogram_quantile(0.95, 
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le, endpoint)
)

le, endpoint란?
- 히스토그램의 각 구간 상한값을 나타내는 특수 레이블입니다. (0.1초, 0.5초, 1.0초 등).
- histogram_quantile()은 이 `le` 값들을 보고 백분위수를 계산하므로, `sum`으로 집계할 때 `le`를 제거하면 백분위수 계산이 불가능합니다.

5. 시간 관련 함수

offset : 특정 시간만큼 과거의 데이터 조회

# 1시간 전 데이터
http_requests_total offset 1h

# 어제 같은 시간 데이터
http_requests_total offset 1d

# 현재와 1시간 전 비교
rate(http_requests_total[5m]) / rate(http_requests_total[5m] offset 1h)

6. 예측 함수

predict_linear() : 선형 회귀를 사용하여 미래 값을 예측

# 4시간 후 디스크 사용량 예측
predict_linear(node_filesystem_free_bytes[1h], 4 * 3600)

# 디스크가 가득 찰지 예측
predict_linear(node_filesystem_free_bytes[1h], 4 * 3600) < 0

7. 변환 함수

scalar() : 단일 값을 가진 Instant Vector를 Sclar로 변환

# Vector를 Scalar로 변환
scalar(sum(up))

# 조건부 비교에 활용
http_requests_total > scalar(sum(threshold_value))

PromQL의 주요 내장 함수 활용 예시

예시 1 : API 에러율 모니터링

# 엔드포인트별 5xx 에러율
sum(rate(http_requests_total{status=~"5.."}[5m])) by (endpoint)
/
sum(rate(http_requests_total[5m])) by (endpoint)
* 100

사용 함수: rate(), sum(), by()

타입 흐름

http_requests_total[5m] → Range Vector
rate(...) → Instant Vector
sum(...) by (endpoint) → Instant Vector
나누기 → Instant Vector
* 100 → Instant Vector (에러율 %)

예시 2 : CPU 사용률 Top5

# CPU 사용률 상위 5개 서버
topk(5, 
  100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
)

사용 함수: rate(), avg by(), topk()

타입 흐름

Range Vector → rate() → Instant Vector
avg by (instance) → Instant Vector
100 - ... → Instant Vector (CPU 사용률)
topk(5, ...) → Instant Vector (상위 5개)

예시 3 : 트래픽 급증 감지

# 1시간 전 대비 트래픽 2배 이상 증가
sum(rate(http_requests_total[5m]))
/
sum(rate(http_requests_total[5m] offset 1h))
> 2

사용 함수: rate(), sum(), offset

타입 흐름

Range Vector → rate() → Instant Vector → sum() → Scalar
offset 1h → 1시간 전 Scalar
나누기 → Scalar
> 2 → Boolean

예시 4 : 응답 시간 비교 (오늘 vs 어제)

# 오늘과 어제 p95 응답 시간 차이
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))
-
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m] offset 1d))

사용 함수: rate(), histogram_quantile(), offset

타입 흐름

Range Vector → rate() → Instant Vector
histogram_quantile() → Instant Vector (p95)
offset 1d → 어제 데이터
빼기 → Instant Vector (차이)

데이터 타입 간 관계

1. Range Vector ➡️ Instant Vector 변환

# Range Vector (그래프 표시 불가)
# 최근 5분간의 모든 데이터 포인트를 배열로 가짐
http_requests_total[5m]

# Instant Vector로 변환 (그래프 표시 가능)
rate(http_requests_total[5m])           # 초당 평균 증가율 계산
increase(http_requests_total[5m])       # 총 증가량 계산
avg_over_time(cpu_usage[5m])           # 5분간 평균값 계산
max_over_time(memory_usage[1h])        # 1시간 내 최대값 계산

Range Vector는 반드시 함수를 통해 Instant Vector로 변환해야 합니다.

왜냐하면, Range Vector는 시간 범위 내 여러 개의 값(배열)을 가지므로 ~~직접 그래프로 표시~~할 수 없습니다. 함수를 통해 이 값들을 하나의 값으로 계산해야 시각화가 가능합니다.

2. Instant Vector ➡️ Scalar 변환

scalar() 함수 사용
사용 시기
- 단일 시계열을 숫자 값으로 변환하여 다른 계산에 활용할 때

# Instant Vector → Scalar
scalar(sum(up))

# 활용 예시: Scalar를 임계값으로 사용
http_requests_total > scalar(sum(threshold_value))

주의‼️: scalar() 함수는 정확히 1개의 시계열만 가진 Vector에만 사용 가능합니다. 여러 시계열이 있으면 에러 발생

레이블 없이 집계

sum(http_requests_total)      # → Scalar
avg(cpu_usage_percent)        # → Scalar
count(up == 1)                # → Scalar

~~레이블을 지정~~하지 않고 집계하면 모든 시계열이 하나로 합쳐져 자동으로 Scalar가 됩니다.

3. Scalar와 Vector 연산

Scalar는 Vector의 각 시계열에 자동 적용됩니다.

Vector와 Scalar를 연산하면, Scalar 값(숫자)이 Vector의 모든 시계열에 동일하게 적용됩니다. 마치 반복문처럼 각 시계열마다 같은 연산을 수행하는 것과 같습니다.

# 모든 시계열에 100 곱하기
cpu_usage * 100

# bytes를 MB로 변환
disk_usage_bytes / 1024 / 1024

# 임계값 비교
cpu_usage_percent > 80

활용 예시

# 메모리 사용률을 퍼센트로 변환
(memory_used_bytes / memory_total_bytes) * 100
# 각 서버마다 (사용량 / 전체) * 100 계산

# 모든 응답 시간을 밀리초로 변환
http_response_time_seconds * 1000
# 각 엔드포인트의 응답 시간에 1000을 곱함

핵심은 바로 Scalar 하나가 Vector의 모든 시계열에 브로드캐스팅(broadcasting)된다는 것 입니다.

[Query DSL] Transform & GroupBy: 평면 조인 결과를 계층 구조로 쉽게 변환하기

지누박 — Fri, 9 Jan 2026 20:29:30 +0900

개요

JPA를 사용하다 보면 게시글과 댓글, 주문과 주문 상품 같은 1:N 관계를 조회해야 할 일이 정말 많습니다. 하지만 DB에서 조인(Join)을 하면 결과는 계층적 구조가 아닌 언제나 평면적입니다.

오늘은 이 간극을 메우기 위해 우리가 흔히 하던 'Map 노가다'를 버리고, QueryDSL의 transform을 사용해 데이터를 가져오는 방법을 알아보겠습니다.

즉, 연관관계가 있는 데이터를 조회할 때 평면적인(flat) 결과를 계층적인(hierarchical) 구조로 변환해야 하는 경우가 자주 발생하는데, Map을 통한 수동 변환 작업은 번거롭고 실수하기 쉽습니다. QueryDSL의 transform은 바로 이 문제를 해결해줍니다.

이번 글에서는 회사에서 실제로 겪었던 사례를 바탕으로 QueryDSL의 transform 기능을 정리해보려 합니다. 보안상 실제 코드는 가져올 수 없어, 이해를 돕기 위한 간단한 예제 코드와 함께 설명하겠습니다.

Qeury DSL - transform&groupBy란❓

transform은 QueryDSL에서 제공하는 결과 변환 및 그룹핑 기능입니다. 하지만 Transform 혼자서는 아무것도 할 수 없습니다.

Transform의 핵심은 바로 GroupBy입니다.

GroupBy와 관계

.transform(
    groupBy(post.id).list(...)  // GroupBy가 핵심!
)

transform()은 쿼리 결과를 변환하는 프레임워크이고, groupBy()는 ResultTransformer의 구현체로서 평면 데이터를 키 기준으로 묶는 역할을 합니다.

Transform: 전체 변환 프레임워크
GroupBy: 평면 데이터를 키 기준으로 묶는 핵심 메커니즘
둘은 함께 사용되며, groupBy()가 transform()의 인자로 들어가는 구조입니다.

주로 다음과 같은 상황에서 사용됩니다.

1:N 관계의 데이터를 계층 구조로 변환
평면 쿼리 결과를 복잡한 DTO 구조로 매핑
그룹핑과 집계를 동시에 처리

QueryDSL 5.x부터 transform은 deprecated 되었습니다.

공식 문서에서는 직접 구현을 권장하지만, 여전히 많은 프로젝트에서 사용되고 있으며 코드 간결성 측면에서 장점이 있습니다.

transform & groupBy 동작 원리

예를 들어, Post와 Comment의 1:N 관계에서 Post 목록을 조회하면서 각 Post에 달린 Comment들을 함께 가져오고 싶을 때, 일반적인 JOIN 쿼리는 다음과 같은 평면 결과를 반환합니다.

Post1 - Comment1
Post1 - Comment2
Post2 - Comment3

하지만 우리가 원하는 것은 다음과 같은 계층 구조입니다.

Post1
  - Comment1
  - Comment2
Post2
  - Comment3

이러한 변환 작업을 수동으로 처리하면 코드가 복잡해지고 실수하기 쉽습니다. QueryDSL의 transform 기능은 바로 이 문제를 해결하기 위해 만들어졌습니다.

Deprecated 배경과 대안

QueryDSL 5.x부터 transform은 deprecated 되었습니다.

이유
- 복잡한 변환 로직을 라이브러리에 의존하는 것보다 명시적인 자바 코드로 구현하는 것이 유지보수에 유리하다는 판단
- 성능 이슈나 예상치 못한 동작에 대한 제어가 어려움

하지만 여전히 많은 레거시 프로젝트에서 사용 중이며, 코드 간결성 측면에서는 여전히 장점이 있어 실무에서 유용합니다.

GroupBy와 동작 원리

groupBy 주요 메서드

1. groupBy(key): 특정 필드를 기준으로 그룹핑

groupBy(post.id)  // post.id로 그룹핑

데이터를 하나로 묶을 부모의 고유 키를 지정합니다.

보통 PK(Primary Key)인 id를 기준으로 삼습니다.
이 기준을 중심으로 여러 개의 Row가 하나의 객체(Post)로 합쳐집니다.

2. list(...) : 각 그룹을 List로 수집

groupBy(post.id).list(
    new QPostResponse(...)  // 각 그룹을 PostResponse로 변환
)

그룹핑된 데이터를 어떤 형태의 결과 리스트로 만들지 정의합니다.

groupBy(post.id).list(...)라고 작성하면, 중복이 제거된 순수한 게시글 리스트가 반환됩니다.
이때 QDTO(QueryProjection)를 사용하면 생성자 파라미터에 맞춰 안전하게 매핑됩니다.

3. list(expression) : 그룹 내 자식 Entity들을 List로 수집

list(new QCommentDto(...))  // Comment들을 List<CommentDto>로

부모 객체 안에서 자식 리스트를 수집할 때 사용합니다.

조인으로 인해 불어난 Row들 중에서 자식 데이터(Comment)들만 골라내어 부모 DTO의 List<CommentDto> 필드에 차곡차곡 채워줍니다.
list(new QCommentDto(...))처럼 중첩해서 사용하면 계층 구조가 완성됩니다.

4. skipNulls() : null 값 자동 제외

list(new QCommentDto(...).skipNulls())

Left Join으로 자식 엔티티를 조회할 때, 자식 데이터가 없으면 comment.id, comment.content가 모두 null이 되어 결과 리스트에 [CommentDto(null, null)] 과 같은 형태로 담기게 됩니다.

skipNulls()를 사용하면 이런 null 객체를 자동으로 필터링하여 빈 리스트([])를 반환합니다.

transform 사용 이유

1. 코드 간결성

수동 그룹핑 코드를 작성하면 다음과 같은 작업이 필요합니다.

평면 DTO 정의
Map을 사용한 그룹핑 로직 구현
null 체크 및 중복 제거
최종 결과 변환

그러나, Transform + GroupBy를 사용하면 이 모든 과정을 선언적으로 표현할 수 있습니다.

2. 가독성 향상

비즈니스 로직과 데이터 변환 로직이 분리되어 코드의 의도가 명확해집니다.

// Transform + GroupBy: 의도가 명확
groupBy(post.id).list(
    new QPostResponse(
        post.id,
        post.title,
        list(new QCommentDto(...))
    )
)

// 수동 그룹핑: 구현 세부사항에 집중
Map<Long, PostResponse> map = new LinkedHashMap<>();
for (PostFlatDto row : flatResults) {
    PostResponse postRes = map.computeIfAbsent(...);
    if (row.getCommentId() != null) {
        postRes.getComments().add(...);
    }
}

주의사항 : 성능 고려 사항

1. 메모리 내 그룹핑

Transform은 DB에서 받은 모든 평면 데이터를 메모리에 올린 후 그룹핑합니다.
대량 데이터(수만 건 이상) 조회 시 OutOfMemoryError 위험이 있습니다

2. 페이징 불가

groupBy().list()는 전체 데이터를 가져온 후 그룹핑하므로 DB 레벨 페이징이 불가능합니다.
페이징이 필요한 경우 Batch Size 조정이나 별도 쿼리 분리를 고려해야 합니다.

3. N+1 문제는 여전히 존재

Transform은 단순히 변환 로직일 뿐, Fetch Join 전략과는 별개입니다.
- 따라서, 여전히 적절한 Join 전략이 필요합니다.

groupBy & transform 사용 예시

1. 엔티티 설계

Post(게시물)

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Post {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String title;

    @OneToMany(mappedBy = "post")
    private List<Comment> comments = new ArrayList<>();

    public Post(String title) {
        this.title = title;
    }
}

Comment(댓글)

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Comment {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String content;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "post_id")
    private Post post;

    public Comment(String content, Post post) {
        this.content = content;
        this.post = post;
    }
}

2. DTO 설계

@Data
public class PostResponse {
    private Long postId;
    private String title;
    private List<CommentDto> comments;

    @QueryProjection
    public PostResponse(Long postId, String title, List<CommentDto> comments) {
        this.postId = postId;
        this.title = title;
        this.comments = comments;
    }
}

@Data
public class CommentDto {
    private Long commentId;
    private String content;

    @QueryProjection
    public CommentDto(Long commentId, String content) {
        this.commentId = commentId;
        this.content = content;
    }
}

// 수동 그룹핑용 평면 DTO
@Data
@AllArgsConstructor
public class PostFlatDto {
    private Long postId;
    private String title;
    private Long commentId;
    private String content;
}

3. Transform 사용 vs 미사용 비교

Before : transform 미사용(수동 그룹핑)

@Override
public List<PostResponse> searchBefore() {
    // 1. 평면 DTO로 조회
    List<PostFlatDto> flatResults = queryFactory
            .select(Projections.constructor(PostFlatDto.class,
                    post.id, post.title, comment.id, comment.content))
            .from(post)
            .leftJoin(post.comments, comment)
            .fetch();

    // 2. 메모리에서 수동 그룹핑
    Map<Long, PostResponse> map = new LinkedHashMap<>();
    for (PostFlatDto row : flatResults) {
        PostResponse postRes = map.computeIfAbsent(row.getPostId(),
                id -> new PostResponse(id, row.getTitle(), new ArrayList<>()));

        if (row.getCommentId() != null) {
            postRes.getComments().add(
                new CommentDto(row.getCommentId(), row.getContent())
            );
        }
    }
    return new ArrayList<>(map.values());
}

이 방식은 데이터베이스에서 가져온 평면적인 데이터를 자바 코드로 직접 조립하는 방식입니다.

Projections.constructor
- DB의 Join 결과는 게시글 1개에 댓글이 3개라면 총 3개의 행(Row)이 반환됩니다.
- 이를 담기 위해 모든 필드가 펼쳐진 PostFlatDto를 임시로 사용합니다.
LinkedHashMap & computeIfAbsent
- 중복된 게시글 데이터를 통합하기 위해 Map을 사용합니다.
- 게시글 ID가 Map에 없으면 새로 만들고, 있으면 기존 객체를 가져와 댓글만 리스트에 추가합니다.
수동 Null 체크
- leftJoin 시 댓글이 없는 경우 commentId가 null로 들어오기 때문에, 이를 방어하는 if문 로직이 반드시 포함되어야 합니다.

after : transform 사용(선언적 그룹핑)

@Override
public List<PostResponse> searchAfter() {
    return queryFactory
            .from(post)
            .leftJoin(post.comments, comment)
            .transform(
                    groupBy(post.id).list(
                            new QPostResponse(
                                    post.id,
                                    post.title,
                                    list(new QCommentDto(
                                        comment.id, 
                                        comment.content
                                    ).skipNulls())
                            )
                    )
            );
}

QueryDSL의 transform을 사용하면 자바의 복잡한 컬렉션 가공 로직이 간단한 선언문으로 해결이 됩니다.

groupBy(post.id)
- "게시글 ID를 기준으로 행들을 묶겠다"는 기준을 세웁니다.
list(new QPostResponse(...))
- 그룹핑된 덩어리를 PostResponse 객체로 변환합니다.
list(new QCommentDto(...))
- 게시글 내부의 댓글 리스트를 수집합니다.
- 핵심 포인트
  - QueryDSL이 내부적으로 데이터를 자동으로 순회하며 CommentDto를 생성해 리스트에 넣어줍니다.
  - 개발자가 직접 for문을 돌리며 ~~리스트에 데이터를 추가(add)할 필요~~가 전혀 없습니다.
skipNulls()
- 댓글이 없는 경우 리스트에 null 요소가 들어가는 것을 방지하여, 깨끗한 빈 리스트([])를 보장합니다.

transform 사용 코드와 미사용 코드의 응답결과를 보겠습니다.

위와 같이 보면알 수 있듯이 미사용(before), 사용(after)의 응답 결과가 동일한 것을 알 수 있습니다. 이처럼 과정이 전혀 다름에도 같은 결과가 나오게 됩니다.

결론

위 두 가지 코드(transform 사용/미사용)를 비교해보면 그 차이가 극명하게 드러납니다.

먼저 transform을 사용하지 않을 때는 계층 구조가 1단계(게시글-댓글)인 아주 단순한 상황임에도 불구하고, 데이터를 재조합하기 위해 Map과 복잡한 반복문을 직접 구현해야 합니다.

이는 데이터 구조가 깊어지고 복잡해질수록 가독성을 해치고 유지보수를 어렵게 만드는 결정적인 원인이 됩니다. 또한, 데이터를 쿼리 단계에서 임시로 담아낼 별도의 DTO(FlatDto)를 매번 생성해야 한다는 번거로움도 존재합니다.

반면 transform을 사용하면 아무리 복잡한 계층 구조라도 Map 가공 로직이나 수동 반복문 없이, 단순한 list() 중첩만으로 설계가 가능해집니다. 개발자는 더 이상 데이터를 어떻게 묶을지 고민하지 않고, 어떤 구조로 가져올지만 기술하면 됩니다.

즉, '어떻게(How)'가 아닌 '무엇을(What)'에 집중하게 됨으로써 코드의 간결함과 생산성을 동시에 챙길 수 있습니다.

[JPA]JPA IDENTITY 전략에서 쓰기 지연이 작동하지 않는 이유

지누박 — Thu, 8 Jan 2026 20:36:25 +0900

개요

회사에서 프로젝트를 하던 중, JPA 기본 키 생성 전략 중 하나인 IDENTITY 전략을 사용했을 때, ~~쓰기 지연이 작동~~하지 않아 대량의 데이터를 INSERT할 때 많은 양의 트래픽이 발생했습니다.

이번 글에서는 왜 JPA IDENTITY 전략을 사용하면 "쓰기 지연"이 작동하지 않는지 공부한 내용을 정리하고자 합니다.

JPA의 쓰기 지연(Transactional Write-behind)

먼저 JPA의 쓰기 지연에 대해서 살펴보겠습니다.

JPA는 기본적으로 트랜잭션의 커밋 시점에 쿼리를 모아서 한 번에 보냅니다. 이를 "쓰기 지연"이라고 부릅니다.

@Transactional
public void saveMembers() {
    Member member1 = new Member("회원1");
    Member member2 = new Member("회원2");
    Member member3 = new Member("회원3");

    entityManager.persist(member1);  // 쓰기 지연 저장소에 저장
    entityManager.persist(member2);  // 쓰기 지연 저장소에 저장
    entityManager.persist(member3);  // 쓰기 지연 저장소에 저장

    // 트랜잭션 커밋 시점에 3개의 INSERT 쿼리가 한 번에 실행됨
}

쓰기 지연의 동작 원리는 다음과 같습니다.

persist() 호출 시 엔티티를 영속성 컨텍스트의 1차 캐시에 저장
- PK를 키로 엔티티 객체를 저장 (예: {1: member1})
동시에 INSERT 쿼리를 쓰기 지연 SQL 저장소에 보관
트랜잭션 커밋 시점에 모아둔 쿼리를 한 번에 데이터베이스로 전송

이러한 방식은 다음과 같은 장점을 제공합니다.

성능 최적화: 여러 쿼리를 배치로 처리 가능
네트워크 호출 최소화: DB 왕복 횟수 감소
트랜잭션 일관성: 모든 변경사항을 한 번에 반영

IDENTITY 전략이란❓

IDENTITY 전략은 기본 키 생성을 데이터베이스에 위임하는 전략입니다. MySQL의 AUTO_INCREMENT, PostgreSQL의 SERIAL 등이 이에 해당합니다.

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;  // DB가 자동으로 생성

    private String name;
}

기본 키 자동 생성(@GeneratedValue) 전략과 차이점

IDENTITY	데이터베이스 (AUTO_INCREMENT)	❌
SEQUENCE	데이터베이스 시퀀스	✅
TABLE	별도 키 관리 테이블	✅
AUTO	DB에 따라 자동 선택	DB 전략에 따름

[JPA] Entity란 무엇일까❓(Entity: 데이터베이스와 자바 객체 간의 다리)

자바 애플리케이션에서 데이터베이스와 상호작용할 때, Entity는 중요한 역할을 합니다. JPA(Java Persistence API)에서 Entity는 데이터베이스의 테이블과 자바 클래스 간의 매핑을 정의하며, 데이터베

pixx.tistory.com

IDENTITY 전략에서 쓰기 지연이 작동하지 않는 이유

1. 핵심 원인 : PK 값을 즉시 알아야 한다.

JPA는 엔티티를 영속성 컨텍스트에 저장할 때 반드시 PK 값이 필요합니다.

영속성 컨텍스트(1차 캐시)는 내부적으로 Map 구조로 이루어져 있습니다.

Key: @Id로 지정한 식별자 (PK)
Value: 엔티티 객체 자체

Map에 데이터를 넣을 때 key 값이 null이면 저장할 수 없듯, JPA도 엔티티를 관리하기 위한 최소한의 조건인 ~~PK가 없으면 영속 상태~~로 만들 수 없습니다.

2. IDENTITY 전략의 딜레마

문제는 IDENTITY 전략(MySQL의 AUTO_INCREMENT 등)의 특징에 있습니다. 이 방식은 "일단 DB에 데이터를 넣어봐야" 비로소 다음 PK 값이 무엇인지 결정됩니다.

JPA 입장
- "얘를 영속성 컨텍스트에 넣으려면 지금 당장 PK가 필요해!"
DB 입장
- "INSERT 쿼리를 날려주기 전까지는 PK가 뭔지 알려줄 수 없어."

즉, IDENTITY 전략의 문제는 PK 값을 데이터베이스에 INSERT를 해봐야만 알 수 있다는 점입니다.

3. 결국, 쓰기 지연을 포기

Member member = new Member("홍길동");
System.out.println(member.getId());  // null (아직 저장 전)

// 1. persist 호출 시점에 즉시 INSERT 실행! (쓰기 지연 X)
entityManager.persist(member);  

// 2. DB가 생성한 ID를 JDBC가 즉시 받아옴 (Statement.getGeneratedKeys())
// 3. 받아온 ID를 엔티티의 @Id 필드에 채워넣음
System.out.println(member.getId());  // 1 (DB에서 생성된 값 확인 가능)

// 4. 이제 PK가 생겼으므로 영속성 컨텍스트에 정상 저장

persist() 호출
즉시 INSERT 쿼리 실행 (쓰기 지연 X)
DB에서 생성된 PK 값을 조회
조회한 PK 값을 엔티티에 설정
PK를 키로 사용하여 영속성 컨텍스트에 저장

이러한 이유로 IDENTITY 전략에서는 persist() 호출 즉시 INSERT가 실행되며, 쓰기 지연이 동작하지 않습니다.

SEQUENCE 전략과의 비교

그렇다면 JPA의 기본키 자동생성 전략 중 SEQUENCE 전략은 왜 쓰기 지연이 가능할까요❓

앞서 IDENTITY 전략이 ID를 알기 위해 즉시 INSERT를 날려야 했다면, 오라클이나 PostgreSQL에서 주로 사용하는 SEQUENCE 전략은 동작 방식이 완전히 다릅니다.

핵심 차이점 : INSERT 전에 ID를 미리 알 수 있다.

SEQUENCE 전략의 핵심은 DB에 실제 데이터를 넣기 전에, 번호만 따로 생성해주는 전용 객체(Sequence)가 존재한다는 점입니다.

entityManager.persist(member1);  

entityManager.persist(member2);

entityManager.persist(member1);
1. DB 시퀀스 객체에 "다음 번호 하나 줘!"라고 요청 (SELECT NEXT VALUE)
2. DB로부터 '1번'이라는 값을 받아 엔티티 ID에 할당
3. 이제 ID(Key)가 생겼으니 영속성 컨텍스트에 저장 가능!
4. INSERT 쿼리는 아직 날리지 않고 '쓰기 지연 저장소'에 보관 ✅
entityManager.persist(member2);
1. 같은 방식으로 '2번' 번호표를 미리 받아오고 쿼리는 저장소에 보관

IDENTITY vs SEQUENCE

두 전략의 결정적인 차이를 '번호표' 비유로 정리하면 이렇습니다.

IDENTITY (식당 결제 방식)
- "일단 음식을 먹어봐야(INSERT) 얼마인지(ID) 알고 영수증을 처리할 수 있다." ➡️ 기다릴 수 없음.
SEQUENCE (은행 번호표 방식)
- "입구에서 번호표(ID)를 먼저 뽑았으니, 실제 업무(INSERT)는 나중에 순서대로 처리해도 된다." ➡️ 쓰기 지연 가능.

따라서, SEQUENCE는 INSERT 전에 미리 PK 값을 알 수 있기 때문에 쓰기 지연이 가능합니다.

그렇다면, 그냥 SEQUENCE 전략을 쓰면되는거 아닌가 하는 생각이 듭니다.

그러나 SEQUENCE 전략은 ~~모든 DBMS에서 사용~~할 수 있는 것은 아닙니다.

구분	지원 여부
지원함	Oracle, PostgreSQL, DB2, H2
지원 안함	MySQL, MariaDB, SQL Server (구버전)

MySQL이나 MariaDB는 시퀀스 객체 대신 AUTO_INCREMENT라는 방식을 사용하기 때문에, 기본적으로 IDENTITY 전략을 사용해야 합니다.

IDENTITY 전략의 문제

IDENTITY 전략의 가장 큰 성능 문제는 JDBC Batch Insert를 사용할 수 없다는 점입니다.

Batch Insert란❓

Batch Insert는 여러 개의 INSERT 쿼리를 하나의 네트워크 호출로 묶어서 전송하는 최적화 기법입니다.

-- 일반적인 INSERT (3번의 네트워크 호출)
INSERT INTO member (name) VALUES ('회원1');
INSERT INTO member (name) VALUES ('회원2');
INSERT INTO member (name) VALUES ('회원3');

-- Batch INSERT (1번의 네트워크 호출)
INSERT INTO member (name) VALUES ('회원1'), ('회원2'), ('회원3');

IDENTITY 전략에서의 문제

@Transactional
public void saveMembers() {
    for (int i = 1; i <= 1000; i++) {
        Member member = new Member("회원" + i);
        entityManager.persist(member);
        // 매번 즉시 INSERT 실행 → 1000번의 DB 호출!
    }
}

persist() 호출마다 즉시 INSERT 실행
각 INSERT마다 개별적인 네트워크 호출 발생
Batch Insert 최적화 불가능
대량 데이터 저장 시 성능 저하

성능 비교

1000개의 엔티티를 저장하는 경우

전략	네트워크 호출 횟수	예상 시간
IDENTITY (Batch 불가)	1000번	~2-3초
SEQUENCE (Batch 가능)	10-20번	~0.2-0.5초

IDENTITY 전략의 문제 해결방법

1. SEQUENCE 전략으로 변경

@Entity
@SequenceGenerator(
    name = "member_seq_generator",
    sequenceName = "member_seq",
    allocationSize = 50  // 성능 최적화
)
public class Member {
    @Id
    @GeneratedValue(
        strategy = GenerationType.SEQUENCE,
        generator = "member_seq_generator"
    )
    private Long id;

    private String name;
}

장점

쓰기 지연 가능
Batch Insert 가능
allocationSize를 통한 추가 최적화 가능

단점

MySQL 5.7 이하에서는 SEQUENCE 미지원
DB 마이그레이션 필요

2. JDBC Batch Size 설정 (Sequence)

spring:
  jpa:
    properties:
      hibernate:
        jdbc:
          batch_size: 50  # 한 번에 50개씩 배치 처리
        order_inserts: true  # INSERT 순서 정렬
        order_updates: true  # UPDATE 순서 정렬

Hibernate 설정만으로 여러 개의 INSERT를 하나로 묶어 네트워크 비용을 줄일 수 있습니다.

단, 앞서 설명했듯, 이 설정은 IDENTITY 전략에서는 무용지물입니다. Hibernate가 ID를 확인하기 위해 매번 INSERT를 실행해야 하므로 ~~배치가 작동~~하지 않습니다.

3. JDBC Template 직접 사용

MySQL/MariaDB 환경에서 대량의 데이터를 가장 빠르게 넣는 방법입니다. JPA를 거치지 않고 직접 SQL을 날려 쓰기 지연과 ID 조회 과정을 생략합니다.

@Repository
@RequiredArgsConstructor
public class MemberBulkRepository {

    private final JdbcTemplate jdbcTemplate;

    public void bulkInsert(List<Member> members) {
        String sql = "INSERT INTO member (name) VALUES (?)";

        jdbcTemplate.batchUpdate(sql, new BatchPreparedStatementSetter() {
            @Override
            public void setValues(PreparedStatement ps, int i) throws SQLException {
                ps.setString(1, members.get(i).getName());
            }

            @Override
            public int getBatchSize() {
                return members.size(); // 한 번의 네트워크 통신으로 처리할 데이터 양
            }
        });
    }
}

JPA 영속성 컨텍스트를 거치지 않으므로 1~~차 캐시 등에 의한 메모리 부하~~가 없습니다.
- 단, DB에 직접 넣는 것이기 때문에, 실행 후 영속성 컨텍스트를 새로고침(clear)하거나 동기화에 신경 써야 합니다.

4. TABLE 전략 사용

모든 DB에서 시퀀스처럼 미리 번호를 따올 수 있도록 별도의 '키 생성 전용 테이블'을 만드는 전략입니다.

@Entity
@TableGenerator(
    name = "member_id_generator",
    table = "id_generator",
    pkColumnValue = "member_id",
    allocationSize = 50
)
public class Member {
    @Id
    @GeneratedValue(
        strategy = GenerationType.TABLE,
        generator = "member_id_generator"
    )
    private Long id;
}

장점
- IDENTITY와 달리 번호를 미리 가져올 수 있어 쓰기 지연과 Batch Insert가 가능해집니다.
단점
- 번호를 딸 때마다 id_generator 테이블을 업데이트해야 하므로, 아주 빈번한 삽입 시 DB 락(Lock)이나 오버헤드가 발생할 수 있습니다.

결론

IDENTITY 전략의 특징 요약

장점

설정이 간단함
DB의 네이티브 기능 활용
AUTO_INCREMENT와 자연스럽게 매칭

단점

❌ 쓰기 지연 불가능
❌ Batch Insert 불가능
❌ 대량 데이터 저장 시 성능 저하

권장 사항

소규모 애플리케이션: IDENTITY 전략 사용해도 무방
대량 데이터 처리 필요: SEQUENCE 전략으로 변경 권장 (단 지원 가능 DBMS만)
MySQL 사용 중: MySQL 8.0+ 버전에서 SEQUENCE 지원 확인 후 전략 선택
이미 IDENTITY 사용 중: 대량 INSERT가 필요한 부분만 JDBC Template 활용

프로젝트의 요구사항과 데이터 규모를 고려하여 적절한 키 생성 전략을 선택하는 것이 중요합니다.

참고 자료

[Spring boot] 동기식 HTTP 클라이언트 RestTemplate 알아보기

지누박 — Wed, 7 Jan 2026 23:39:13 +0900

Spring에서 외부 API를 호출할 때 사용되는 방법은 RestTemplate, WebClient, RestClient, OpenFeign 등이 있습니다. 이번 글에서는 이 중 RestTemplate에 대한 공부한 내용을 정리하고자 합니다.

비록 Spring 공식 문서에서는 WebClient 사용을 지향하지만, 여전히 많은 레거시 시스템과 프로젝트의 표준으로 자리 잡고 있는 RestTemplate에 대해 다뤄보고자 합니다.

RestTemplate란❓

RestTemplate은 Spring 3.0부터 제공된 동기식 HTTP 클라이언트입니다.

즉, HTTP 통신을 위한 도구로 RESTful API 웹 서비스와의 상호작용을 쉽게 외부 도메인에서 데이터를 가져오거나 전송할 때 사용되는 스프링 프레임워크의 클래스를 의미합니다.

RestTemplate이 Deprecated 된다고 알고 있는 사람이 종종있는데 아직까지도 deprecated가 아닙니다. 새로운 기능 추가는 없지만 버그 수정과 보안 업데이트는 계속되고있습니다.

출처

RestTemplate 주요 특징

블로킹 기반의 동기(Synchronous) 방식으로 동작합니다.
HTTP 메서드별로 직관적인 메서드를 제공합니다.
자동으로 JSON/XML과 객체 간 변환을 처리합니다.

블로킹 요청(Blocking Request) 란❓

하나의 작업이 진행되는 동안 그 작업이 끝날 때까지 제어권을 붙잡아 두어 ~~다음 작업이 실행~~되지 못하게 막는 상태를 의미합니다.
unblocked 상태가 되면 다음 요청에 대해 처리를 수행합니다.

즉, 요청을 보낸 스레드가 응답이 올 때까지 "멈춰서 기다리는" 요청 방식

RestTemplate의 역할

RestTemplate은 Spring Framework와 외부 REST API 사이의 중간 계층 역할을 합니다.

Request a resource
- Spring 애플리케이션이 RestTemplate에게 외부 API 호출을 요청합니다
RestTemplate 처리
- RestTemplate이 HTTP 요청을 구성하고 실행합니다
REST API 호출
- 실제 외부 REST API 서버에 HTTP 요청을 보냅니다.
Get a resource
- 응답을 받아서 자바 객체로 변환하여 애플리케이션에 반환합니다.
  - 자바 객체로 변환할 때 RestTemplate는 내부적으로 HttpMessageConverter를 사용해서 HTTP응답 (JSON, XML 등)을 자바 객체로 자동 변환 합니다.
- 이러한 중간 계층 덕분에 개발자는 복잡한 HTTP 통신 로직을 직접 작성하지 않고, 간단한 메서드 호출만으로 외부 API와 통신할 수 있습니다.

RestTemplate 설정하기

1. 의존성 추가

Spring Boot Web 스타터를 사용하면 별도의 의존성 추가 없이 RestTemplate을 사용할 수 있습니다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
}

2. Bean 등록

@Configuration
public class RestTemplateConfig {
    
    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder) {
        return builder
            .setConnectTimeout(Duration.ofSeconds(5))
            .setReadTimeout(Duration.ofSeconds(5))
            .build();
    }
}

RestTemplate은 여러 곳에서 재사용하는 것이 일반적이므로, Spring Bean으로 등록하여 사용하는 것을 권장합니다.

3. RestTemplateBuilder 활용

@Configuration
public class RestTemplateConfig {
    
    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder) {
        return builder
            .rootUri("https://api.example.com")  // 기본 URL 설정
            .setConnectTimeout(Duration.ofSeconds(5))
            .setReadTimeout(Duration.ofSeconds(5))
            .defaultHeader("User-Agent", "MyApp/1.0")
            .interceptors(new LoggingInterceptor())  // 인터셉터 추가
            .errorHandler(new CustomErrorHandler())  // 에러 핸들러 설정
            .build();
    }
}

RestTemplateBuilder를 사용하면 더 세밀한 설정이 가능합니다.
Spring Boot는 RestTemplateBuilder를 자동으로 제공합니다.
- 이를 주입받아 RestTemplate을 생성하면, Spring Boot의 자동 설정 혜택을 받을 수 있습니다.
- 위 예제에서는 연결 타임아웃과 읽기 타임아웃을 각각 5초로 설정했습니다.
rootUri
- 모든 요청에 공통으로 사용될 기본 URL을 설정합니다.
- 이후 요청 시 상대 경로만 지정하면 됩니다
setConnectTimeout
- 서버와의 연결을 시도하는 최대 시간입니다.
- 이 시간 내에 연결되지 않으면 예외가 발생합니다
setReadTimeout
- 서버로부터 데이터를 읽는 최대 시간입니다.
- 연결은 되었지만 응답이 느릴 때 적용됩니다
defaultHeader
- 모든 요청에 기본으로 포함될 HTTP 헤더를 설정합니다
interceptors
- 요청/응답을 가로채서 로깅, 인증 토큰 추가 등의 공통 로직을 처리합니다
errorHandler
- HTTP 에러 응답(4xx, 5xx)을 커스텀하게 처리하는 핸들러를 등록합니다

여러개의 RestTemplate Bean 설정하기

서로 다른 API 서버를 호출해야 하는 경우, 여러 개의 RestTemplate Bean을 등록할 수 있습니다.

각 API 서버마다 다른 설정(타임아웃, 기본 URL, 헤더 등)이 필요할 때 유용합니다.

@Configuration
public class RestTemplateConfig {
    
    @Bean
    @Qualifier("paymentRestTemplate")
    public RestTemplate paymentRestTemplate(RestTemplateBuilder builder) {
        return builder
            .rootUri("https://payment-api.example.com")
            .setConnectTimeout(Duration.ofSeconds(3))
            .setReadTimeout(Duration.ofSeconds(10))
            .build();
    }
    
    @Bean
    @Qualifier("userRestTemplate")
    public RestTemplate userRestTemplate(RestTemplateBuilder builder) {
        return builder
            .rootUri("https://user-api.example.com")
            .setConnectTimeout(Duration.ofSeconds(5))
            .setReadTimeout(Duration.ofSeconds(5))
            .build();
    }
}

@Qualifier

Bean의 식별자를 지정하는 어노테이션입니다.
같은 타입(RestTemplate)의 Bean이 여러 개 있을 때, 각각을 구분하기 위해 사용합니다.
~~@Qualifier 없이~~ 같은 타입의 Bean이 여러 개 있으면, Spring은 어떤 Bean을 주입해야 할지 알 수 없어 NoUniqueBeanDefinitionException 에러가 발생합니다.

@Service
@RequiredArgsConstructor
public class PaymentService {
    
    @Qualifier("paymentRestTemplate")
    private final RestTemplate restTemplate;
    
    // ...
}

@Qualifier("paymentRestTemplate")

필드 위에 붙이는 어노테이션으로, 어떤 Bean을 주입받을지 명시합니다.

동작 원리
- Spring이 PaymentService의 인스턴스를 생성할 때, RestTemplate 타입의 Bean 중에서 @Qualifier("paymentRestTemplate")로 지정된 Bean을 찾아서 주입합니다.
위치
- @Qualifier는 private final RestTemplate restTemplate; 바로 위에 위치해야 합니다.
이름 일치
- Config 클래스에서 지정한 Qualifier 이름("paymentRestTemplate")과 정확히 일치해야 합니다.

RestTemplate 주요 메서드 활용하기

Method	HTTP Method	Return Type	설명
getForObject()	GET	Object	GET 요청에 대한 결과를 객체로 반환합니다
getForEntity()	GET	ResponseEntity	GET 요청에 대한 결과를 ResponseEntity로 반환합니다
postForLocation()	POST	URI	POST 요청에 대한 결과로 헤더에 저장된 URI 반환합니다
postForObject()	POST	Object	POST 요청에 대한 결과를 객체로 반환합니다
postForEntity()	POST	ResponseEntity	POST 요청에 대한 결과를 ResponseEntity로 반환합니다
put()	PUT	void	PUT 요청을 실행합니다
patchForObject()	PATCH	Object	PATCH 요청을 실행하고 결과를 객체로 반환합니다
delete()	DELETE	void	DELETE 요청을 실행합니다
headForHeaders()	HEADER	HttpHeaders	헤더 정보를 추출하고 HTTP HEAD 메서드를 사용합니다
optionsForAllow()	OPTIONS	Set<HttpMethod>	지원되는 HTTP 메서드를 추출합니다
exchange()	any	ResponseEntity	헤더를 생성하고 모든 요청 방법을 허용합니다
execute()	any	T	요청/응답 콜백을 수정합니다

1. GET 요청

getForObject()

응답 본문을 직접 객체로 반환합니다.

@Service
@RequiredArgsConstructor
public class UserService {
    
    private final RestTemplate restTemplate;
    
    public User getUser(Long id) {
        String url = "https://api.example.com/users/" + id;
        return restTemplate.getForObject(url, User.class);
    }
    
    // URI Variables 사용
    public User getUserWithVariable(Long id) {
        String url = "https://api.example.com/users/{id}";
        return restTemplate.getForObject(url, User.class, id);
    }
}

getForEntity()

응답 본문뿐만 아니라 HTTP 상태 코드, 헤더 등 전체 응답 정보를 포함하는 ResponseEntity를 반환합니다.

public ResponseEntity<User> getUserEntity(Long id) {
    String url = "https://api.example.com/users/{id}";
    ResponseEntity<User> response = restTemplate.getForEntity(url, User.class, id);
    
    // 상태 코드 확인
    HttpStatus statusCode = response.getStatusCode();
    
    // 헤더 정보 확인
    HttpHeaders headers = response.getHeaders();
    
    // 응답 본문
    User user = response.getBody();
    
    return response;
}

2. POST 요청

postForObject()

POST 요청을 보내고 응답 본문을 객체로 반환합니다.

public User createUser(User newUser) {
    String url = "https://api.example.com/users";
    return restTemplate.postForObject(url, newUser, User.class);
}

postForEntity()

POST 요청을 보내고 ResponseEntity를 반환합니다.

public ResponseEntity<User> createUserEntity(User newUser) {
    String url = "https://api.example.com/users";
    ResponseEntity<User> response = restTemplate.postForEntity(url, newUser, User.class);
    
    // 생성된 리소스의 Location 헤더 확인
    URI location = response.getHeaders().getLocation();
    
    return response;
}

postForLocation()

POST 요청 후 생성된 리소스의 Location URI를 반환합니다.

public URI createUserLocation(User newUser) {
    String url = "https://api.example.com/users";
    return restTemplate.postForLocation(url, newUser);
}

3. PUT 요청

put()

PUT 요청을 보냅니다. ~~반환값~~이 없습니다(void).

public void updateUser(Long id, User updatedUser) {
    String url = "https://api.example.com/users/{id}";
    restTemplate.put(url, updatedUser, id);
}

4. DELETE 요청

delete()

DELETE 요청을 보냅니다. ~~반환값~~이 없습니다(void).

public void deleteUser(Long id) {
    String url = "https://api.example.com/users/{id}";
    restTemplate.delete(url, id);
}

5. 쿼리 파라미터 처리

UriComponentsBuilder 사용

public List<User> searchUsers(String name, Integer age) {
    String baseUrl = "https://api.example.com/users/search";
    
    UriComponentsBuilder builder = UriComponentsBuilder.fromHttpUrl(baseUrl)
        .queryParam("name", name)
        .queryParam("age", age);
    
    String url = builder.toUriString();
    
    return restTemplate.getForObject(url, List.class);
}

Map으로 쿼리 파라미터 전달

public List<User> searchUsersWithMap(String name, Integer age) {
    String url = "https://api.example.com/users/search?name={name}&age={age}";
    
    Map<String, Object> params = new HashMap<>();
    params.put("name", name);
    params.put("age", age);
    
    return restTemplate.getForObject(url, List.class, params);
}

Connection Pool 설정하기

RestTemplate은 기본적으로 요청마다 새로운 연결(Socket)을 생성하고 닫는 방식을 사용합니다.

하지만 트래픽이 많은 서비스에서는 이 과정이 오버헤드가 되어 성능 저하를 일으킬 수 있습니다. 이때 커넥션 풀(Connection Pool)을 사용하면 미리 만들어 놓은 연결을 재사용하여 효율을 극대화할 수 있습니다.

1. 의존성 추가

커넥션 풀 기능을 제공하는 Apache HttpClient 라이브러리를 build.gradle에 추가해야 합니다.

dependencies {
    // RestTemplate의 커넥션 풀 관리를 위한 라이브러리
    implementation 'org.apache.httpcomponents.client5:httpclient5'
}

2. RestTemplateConfig에 적용하기

RestTemplateBuilder를 사용하여 커넥션 풀이 적용된 HttpComponentsClientHttpRequestFactory를 설정합니다.

@Configuration
public class RestTemplateConfig {

    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder) {
        return builder
            // 1. 커넥션 풀 설정 적용
            .requestFactory(this::clientHttpRequestFactory)
            .setConnectTimeout(Duration.ofSeconds(5))
            .setReadTimeout(Duration.ofSeconds(5))
            .build();
    }

    private ClientHttpRequestFactory clientHttpRequestFactory() {
        // Apache HttpClient 5 설정
        PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();
        connectionManager.setMaxTotal(100);             // 최대 전체 커넥션 수
        connectionManager.setDefaultMaxPerRoute(20);   // IP:Port 하나당 유지할 커넥션 수

        CloseableHttpClient httpClient = HttpClients.custom()
            .setConnectionManager(connectionManager)
            .build();

        return new HttpComponentsClientHttpRequestFactory(httpClient);
    }
}

성능 최적화를 위해 Apache HttpClient 5 기반의 커넥션 풀을 적용한 설정입니다.

setMaxTotal
- 애플리케이션 전체에서 유지할 최대 커넥션 수를 100개로 제한하여 리소스 고갈을 방지합니다.
setDefaultMaxPerRoute
- 특정 호스트(예: API 서버 A)당 최대 커넥션을 20개로 설정해 특정 API 지연이 전체 시스템으로 전이되는 것을 막습니다.
requestFactory
- RestTemplateBuilder에 이 설정을 주입함으로써, 매 요청마다 ~~소켓을 새로 여는~~ 대신 풀에 있는 커넥션을 재사용하게 됩니다."

[Linux] iptables 기초 개념 정리

지누박 — Mon, 20 Oct 2025 16:37:27 +0900

개요

쿠버네티스를 사용하다가 k3s에서 사용하는 iptables와 firewalld가 iptables를 쓰는 것이 충돌하여 문제가 발생했습니다.

이 과정에서 리눅스 네트워킹 개념이 부족하고, iptables의 개념이 부족하여 찾아보고 공부한 내용을 정리하고자 합니다.

IPTABLES 란❓

기본 개념

iptables는 Linux 커널에 내장된 네트워크 패킷 필터링 시스템(netfilter)을 제어하는 사용자 공간 도구입니다.
즉, 실제 패킷 처리(차단, 허용 등)는 커널에서 수행하고, iptables는 그 규칙을 설정하거나 제어하는 사용자 공간 프로그램입니다.

네트워크 패킷 필터링 시스템이란 ❓

Netfilter는 리눅스 커널 내부에 포함된 네트워크 패킷 처리 프레임워크입니다. 즉, 리눅스 커널 안에서 네트워크 패킷이 들어오고, 나가고, 라우팅 되는 과정 중에 패킷을 가로채서 검사·수정·차단·허용할 수 있는 기능을 제공합니다.

iptables이란 ❓

규칙을 설정하고 관리

쉽게 말하면, Linux 시스템에 들어오고 나가는 네트워크 트래픽을 제어하는 방화벽입니다.

IPTABLES 핵심 구조

1. Table(테이블)

iptables는 여러 개의 테이블로 구성되어 있으며, 각 테이블은 특정 목적을 가집니다.

주요 테이블

filter	패킷 필터링 (허용/차단)	방화벽 규칙
nat	네트워크 주소 변환	포트 포워딩, IP 변환
mangle	패킷 헤더 수정	QoS, TTL 변경
raw	연결 추적 예외 설정	고급 설정

2. Chain(체인)

각 테이블은 여러 개의 체인을 가지고 있으며, 체인은 패킷이 통과하는 경로를 나타냅니다.

◽체인별 역할

INPUT : 외부에서 로컬 시스템으로 들어오는 패킷 처리
- 예: SSH 접속, 웹 서버 접근
OUTPUT : 로컬 시스템에서 외부로 나가는 패킷 처리
- 예: 인터넷 브라우징, API 호출
FORWARD : 로컬 시스템을 경유하는 패킷 처리 (라우터 역할)
- 예: 방화벽, 게이트웨이, Kubernetes Pod 간 통신
PREROUTING : 패킷이 시스템에 도착한 직후 (라우팅 전)
- 예: DNAT (목적지 주소 변환)
POSTROUTING : 패킷이 시스템을 떠나기 직전 (라우팅 후)
- 예: SNAT (출발지 주소 변환), Masquerading

3. Rules (규칙)

각 체인은 여러 개의 규칙(Rule)을 가지고 있습니다. 규칙은 조건(Match)과 동작(Target)으로 구성됩니다.

IF (조건) THEN (동작)

조건 예시

출발지 IP가 192.168.1.100
목적지 포트가 80
프로토콜이 TCP

동작 예시

ACCEPT: 허용
DROP: 조용히 차단
REJECT: 거부 메시지와 함께 차단
LOG: 로그 기록

허용(ACCEPT)과 차단(DROP)의 의미

1. 허용(ACCEPT) : 패킷을 통과시켜 목적지로 전달

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

2. 차단(DROP) : 패킷을 버립니다. 아무런 응답 X

iptables -A INPUT -p tcp --dport 23 -j DROP

3. 명확한 차단(REJECT) : 패킷을 거부하고 즉시 거부 메시지를 전송

iptables -A INPUT -p tcp --dport 23 -j REJECT

IPTABLES 기본 명령어

규칙 조회

# 모든 규칙 확인
iptables -L -n -v

# nat 테이블 확인
iptables -t nat -L -n -v

# 줄 번호와 함께 확인
iptables -L --line-numbers

시스템에 설정된 iptables 규칙을 확인합니다
모든 규칙 확인
- -L: 목록
- n: IP를 이름으로 변환 안 함
- -v: 상세 정보

규칙 추가

새로운 방화벽 규칙을 체인에 추가합니다.

# SSH 허용 (22번 포트 TCP 트래픽 허용)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# 특정 IP 허용 (192.168.1.100에서 오는 모든 트래픽)
iptables -A INPUT -s 192.168.1.100 -j ACCEPT

# HTTP/HTTPS 허용
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# 이미 연결된 세션 허용 (중요! 이게 없으면 응답 패킷이 차단됨)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

-A
- 체인 끝에 규칙 추가 (Append)
-p
- 프로토콜 지정 (tcp, udp, icmp 등)
--dport
- 목적지 포트
-s:
- 출발지 IP 주소
-j
- 동작 지정 (ACCEPT, DROP, REJECT 등)

규칙 삭제

# 줄 번호로 삭제
iptables -D INPUT 3

# 모든 규칙 삭제
iptables -F

기본 정책 설정

# 모든 입력 차단
iptables -P INPUT DROP

# 모든 출력 허용
iptables -P OUTPUT ACCEPT

규칙 영구 저장

iptables 규칙은 재부팅 시 사라지므로 저장이 필요합니다.

CentOS/RHEL

# 현재 규칙을 파일로 저장
iptables-save > /etc/sysconfig/iptables

# 부팅 시 자동 로드되도록 설정
systemctl enable iptables

Ubuntu/Debian

# iptables-persistent 패키지 설치
apt-get install iptables-persistent

# 규칙 저장 (설치 중 자동으로 물어봄)
netfilter-persistent save

[Springboot] Spring Boot에서 Service와 ServiceImpl 분리, 꼭 필요할까❓

지누박 — Fri, 28 Feb 2025 09:54:18 +0900

개요

Spring 기반의 프로젝트를 살펴보면, Service와 ServiceImpl로 나누어진 구조를 자주 접하게 됩니다.

그런데 저는 개인 프로젝트나 팀 프로젝트를 진행할 때에는 별도로 ServiceImpl을 두지 않고 하나의 Service 클래스에서 비즈니스 로직을 구현하곤 했습니다.

하지만 실제 업무에서 코드를 분석하다 보니, 많은 프로젝트들이 Service와 ServiceImpl을 분리하는 방식을 택하고 있었습니다.

이 글에서는 왜 Service와 ServiceImpl을 분리하는지, 이러한 구조를 채택한 이유에 대해서 정리하고자 합니다.

분리하는 이유는❓

1. 유지보수성

Service는 인터페이스로 정의하고, ServiceImpl에서 실제 구현을 담당하는 방식은 결합도를 낮추고 변경에 유연하게 대응할 수 있도록 도와줍니다.

즉, 느슨한 결합으로 인해 수정이 용이합니다.

예를 들어, UserService 인터페이스 가 있고, 이를 구현한 UserServiceImpl 이 있다고 가정해봅시다.

public interface UserService {
    User findUserById(Long id);
}

@Service
public class UserServiceImpl implements UserService {
    @Override
    public User findUserById(Long id) {
        // 실제 로직
    }
}

만약 ~~기존 UserServiceImpl을 변경~~하지 않고 새로운 구현체(NewUserServiceImpl)로 교체하고 싶다면, 단순히 스프링 빈(Bean) 설정을 변경하면 됩니다.

이는 특히 다양한 비즈니스 로직이 필요하거나, 구현체를 변경해야 할 가능성이 높은 경우 유리합니다.

2. 테스트 용이성

인터페이스를 사용하면 단위 테스트 시 ~~실제 ServiceImpl을 사용~~하지 않고, Mock 객체를 주입하여 테스트를 수행할 수 있습니다.

이렇게 하면 불필요한 의존성을 제거하고 테스트 속도를 향상시킬 수 있습니다.

@Mock
private UserService userService;

@Test
void testFindUser() {
    when(userService.findUserById(1L)).thenReturn(new User(1L, "Test User"));
    User user = userService.findUserById(1L);
    assertEquals("Test User", user.getName());
}

예를 들어, Mockito를 사용하여 UserService의 Mock 객체를 생성하면, UserServiceImpl의 내부 구현과 무관하게 UserService를 사용하는 로직을 테스트할 수 있습니다.

3. AOP 적용의 유연성

인터페이스 기반 구조는 AOP 적용을 더 유연하게 할 수 있습니다.

과거 Spring 2.0에서는 JDK Dynamic Proxy를 사용하여 AOP Proxy를 생성했으며, 이는 인터페이스를 반드시 구현해야만 AOP 적용이 가능한 방식이었습니다.

즉,
@Transactional(트랜잭션 관리), @Cacheable(캐싱), @Logging(로깅) 등 과 같은 AOP 기능을 사용하려면
인터페이스-구현체 구조가 필수적이었으며, 자연스럽게 Service와 ServiceImpl로 나누는 패턴이 일반화되었습니다.

그러나 Spring 3.2 / Spring Boot 1.4 이후부터는 CGLIB가 기본적으로 포함되면서, 클래스 기반으로도 AOP 프록시를 생성할 수 있게 되었습니다.

덕분에 이제는 인터페이스 없이도 AOP 적용이 가능하며, 과거처럼 인터페이스-구현체 구조를 강제할 필요는 없어졌습니다.

4. 의존성 역전(DIP)의 실현

고수준 모듈(컨트롤러)이 저수준 모듈(서비스 구현체)에 의존하지 않고, 둘 다 추상화(인터페이스)에 의존하게 합니다.
이를 통해 "구현보다 인터페이스에 의존하라"는 객체지향 설계 원칙을 따릅니다.

분리하는 이유는❓

1. 불필요한 추상화

인터페이스는 여러 개의 구현체가 존재할 가능성이 있을 때 의미가 있습니다. 그러나 하지만 대부분의 서비스 계층에서는 하나의 구현체만 존재하는 경우가 많습니다.

public interface UserService {
    User findUserById(Long id);
}

@Service
public class UserServiceImpl implements UserService {
    @Override
    public User findUserById(Long id) {
        return userRepository.findById(id).orElseThrow();
    }
}

위처럼 구현체가 하나뿐이라면, 굳이 인터페이스를 ~~분리할 필요~~가 없습니다. 이런 경우, 직접 클래스를 사용하면 코드가 간결해지고 유지보수도 쉬워집니다.

@Service
public class UserService {
    public User findUserById(Long id) {
        return userRepository.findById(id).orElseThrow();
    }
}

즉, ~~1:1로 구현~~할 것이라면 굳이 ~~인터페이스를 분리~~할 필요가 없다고 생각합니다.

2. 코드의 가독성과 유지보수성 저하

인터페이스를 분리하면 코드의 가독성이 오히려 떨어질 수 있습니다.

인터페이스와 구현체를 왔다 갔다 하면서 코드를 확인해야 함.
단순한 비즈니스 로직에도 불필요한 추상화가 추가됨.
작은 규모의 프로젝트에서는 오버엔지니어링이 될 가능성이 높음

3. 테스트 시 복잡성 증가

Mocking을 활용한 단위 테스트는 ~~Service-Impl 구조~~ 없이도 충분히 가능합니다.

@Mock
private UserRepository userRepository;

@InjectMocks
private UserService userService; // 인터페이스 없이도 Mock 주입 가능

@Test
void testFindUser() {
    when(userRepository.findById(1L)).thenReturn(Optional.of(new User(1L, "Test User")));
    User user = userService.findUserById(1L);
    assertEquals("Test User", user.getName());
}

인터페이스 없이도 테스트는 문제없이 수행될 수 있으며, 오히려 단순한 구조를 유지할 수 있습니다.

4. DI(의존성 주입)와 충돌❌

Spring의 @Service는 기본적으로 클래스 기반의 빈 등록을 지원하기 때문에, 인터페이스 없이도 DI(의존성 주입)에는 아무런 문제가 없습니다.

@Service
public class UserService {
    private final UserRepository userRepository;

    @Autowired
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

즉, ~~인터페이스~~ 없이도 Spring의 IoC 컨테이너는 정상적으로 동작합니다.

결론

당연한 이야기지만, 프로젝트의 규모나 상황을 고려하여 선택하는 것이 최선입니다.

객체지향프로그래밍(OOP) 관점에서 보았을 땐 인터페이스는 다형성 또는 SOLID원칙의 OCP(계방폐쇄원칙)때문에 사용합니다. 그러나 대부분의 경우 Service는 1:1 구조를 가지며, 하나의 Service가 여러 개의 ServiceImpl을 가지는 ~~1:N 관계~~가 아닙니다.

즉, 다형성을 적극적으로 활용할 필요가 없는 경우가 많으므로, 불필요한 추상화는 오히려 복잡도를 증가시킬 수 있습니다.

따라서 특별한 이유가 없다면 단순한 구조를 유지하는 것이 바람직하며, 필요할 때만 인터페이스를 도입하는 것이 합리적인 접근이라고 생각이 듭니다.

[SpringBoot] ObjectMapper와 직렬화/역직렬화

지누박 — Thu, 27 Feb 2025 14:25:18 +0900

개요

Spring boot를 사용한 백엔드 개발을 하다보면 자연스럽게 JSON데이터를 객체로 매핑해야하는 경우가 있습니다.

이러한 Java 객체와 JSON 간의 변환 작업, 즉 '직렬화(Serialization)'와 '역직렬화(Deserialization)'는 매우 중요한 과정인데, 본 글에서는 이 과정을 효율적으로 처리하기 위한 강력한 도구인 ObjectMapper에 대해서 정리하고자 합니다.

직렬화 & 역직렬화란❓

직렬화(Serialization)

직렬화는 객체의 상태를 바이트 스트림이나 다른 형식(JSON, XML 등)으로 변환하는 과정입니다. 이 과정을 통해 메모리에 존재하는 객체를 외부에서 사용할 수 있는 형태로 변환합니다.

주요 목적:

네트워크를 통한 데이터 전송
파일 시스템에 데이터 저장
다른 시스템이나 언어와의 데이터 교환

역직렬화(Deserialization)

역직렬화는 직렬화의 반대 과정으로, 바이트 스트림이나 다른 형식(JSON, XML 등)의 데이터를 다시 객체로 변환하는 과정입니다.

주요 목적:

전송받은 데이터를 응용 프로그램에서 사용 가능한 객체로 복원
저장된 데이터를 메모리에 로드

Spring에서의 직렬화 & 역직렬화 : ObjectMapper

Spring(Java)에서 직렬화는 일반적으로 Jackson 라이브러리를 활용합니다. 이 중 Jackson 라이브러리의 ObjectMapper라는 클래스가 있는데 이 클래스가 직렬화를 처리합니다.

Spring Boot는 기본적으로 Jackson을 내장하고 있으며, 이를 활용하여 JSON 데이터를 Java 객체로 변환하거나, Java 객체를 JSON으로 변환할 수 있습니다.

client에서 보낸 Json 데이터를 DTO 객체로 받으면, Spring에서 알아서 Json의 Key값과 DTO 객체의 멤버변수를 매칭해서 Value값을 DTO 객체에 자동으로 대입해주었는데, 그 과정을 바로 SpringBoot의 Object Mapper 클래스가 해주게 됩니다.

ObjectMapper란❓

ObjectMapper는 Jackson 라이브러리의 핵심 클래스로, Java 객체와 JSON 데이터 간의 변환을 담당합니다. 객체 지향 프로그래밍과 데이터 교환 형식 간의 다리 역할을 수행합니다.

주요 기능:

1. 직렬화(Serialization)

String json = objectMapper.writeValueAsString(myObject);

Java 객체를 JSON 문자열로 변환합니다.

2. 역직렬화(Deserialization)

MyClass obj = objectMapper.readValue(jsonString, MyClass.class);

JSON 문자열을 Java 객체로 변환합니다.

3. 다양한 입출력 지원

objectMapper.writeValue(new File("data.json"), myObject);
MyClass obj = objectMapper.readValue(new File("data.json"), MyClass.class);

문자열뿐만 아니라 파일, 스트림, URL 등 다양한 소스에서 읽고 쓸 수 있습니다.

4. 트리 모델 지원

JsonNode rootNode = objectMapper.readTree(jsonString);
String name = rootNode.get("name").asText();

JSON을 트리 구조로 처리할 수 있는 JsonNode API를 제공합니다.

ObjectMapper 커스텀

기본적으로 제공되는 ObjectMapper를 사용해도 되지만, 커스텀이 필요한 경우가 있습니다.

커스터마이징할 상황:

날짜/시간 형식 지정
- 기본적으로 JSON에서는 날짜를 타임스탬프로 표현하지만, "yyyy-MM-dd HH:mm:ss"와 같은 특정 형식으로 직렬화/역직렬화하고 싶은 경우
null 값 처리
- null 값을 가진 필드를 JSON에서 제외하거나 특정 방식으로 처리해야 하는 경우
알 수 없는 속성 처리
- API 버전 호환성을 위해 알 수 없는 JSON 속성이 있어도 ~~예외가 발생~~하지 않도록 설정
Enum 값 처리
- Enum 값을 단순 이름이 아닌 다른 방식(예: toString() 메소드 결과)으로 직렬화/역직렬화
명명 전략 적용
- Java의 camelCase를 JSON의 snake_case로 변환하는 등의 필드 이름 전략 설정
특정 타입 변환기 등록
- 복잡한 객체 타입을 위한 커스텀 직렬화/역직렬화 로직 추가
모듈 등록
- Java 8 날짜/시간 타입 지원이나 추가 데이터 타입 처리를 위한 모듈 등록
보안 설정
- 민감한 데이터를 자동으로 마스킹하거나 제외시키는 설정
성능 최적화
- 특정 기능을 비활성화하여 성능을 향상시키는 설정
다형성 처리
- 상속 관계에 있는 클래스들을 적절하게 처리하기 위한 설정

이 외에도 자신의 프로젝트에 맞는 커스텀 ObjectMapper가 필요한 경우가 있을 것 입니다. 이러한 커스텀이 필요한 경우를 살펴보겠습니다.

예시: 명명 전략 적용 (camelCase ↔ snake_case)

@Configuration
public class JacksonConfig {
    
    @Bean
    @Primary
    public ObjectMapper objectMapper() {
        var objectMapper = new ObjectMapper();
        
        // 모듈 등록
        objectMapper.registerModule(new Jdk8Module());  // Java 8 타입 지원
        objectMapper.registerModule(new JavaTimeModule());  // Java 시간 관련 타입 지원
        
        // 기본 설정
        objectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);  // 날짜를 타임스탬프가 아닌 ISO-8601 형식으로
        objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);  // 알 수 없는 속성 무시
        objectMapper.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false);  // 빈 객체 직렬화 허용
        
        // 명명 전략 설정 (camelCase -> snake_case)
        objectMapper.setPropertyNamingStrategy(new PropertyNamingStrategies.SnakeCaseStrategy());
        
        return objectMapper;
    }
}

SnakeCaseStrategy를 적용하여 Java의 camelCase 필드명(예: firstName)을 JSON의 snake_case 형식(예: first_name)으로 변환합니다.

이런식으로 default로 제공되는 objcetMapper 이외에 추가적인 커스텀이 필요한 경우 ObjectMapper를 커스텀하여 Bean에다 등록하여 사용할 수 있습니다.

[Docker] 도커 네트워크 모드 알아보기 (bridge, host, none)

지누박 — Sun, 23 Feb 2025 16:26:42 +0900

개요

도커(Docker)는 컨테이너화된 애플리케이션을 위한 다양한 네트워크 모드를 제공합니다.

각 네트워크 모드는 서로 다른 사용 사례와 요구사항을 충족시키기 위해 설계되었습니다.

docker network ls

위와 같이 ls 명령어로 현재 네트워크 목록을 확인하면 아래와 같이 3가지의 네트워크 모드가 존재하는 것을 알 수 있습니다.

bridge, host, none 이외에도 추가적으로 Ipvlan,Macvlan도 존재하는 데 본 글에서는 이 도커의 주요 네트워크 모드들을 정리하고자 합니다.

Bridge 네트워크 모드란❓

Bridge 네트워크는 도커의 기본 네트워크 모드입니다.

도커의 브릿지 네트워크 모드는 컨테이너들이 서로 통신할 수 있게 해주는 가상의 네트워크 브릿지를 생성합니다.

왼쪽 그림에서 볼 수 있듯이 "mybridge"라는 브릿지가 여러 컨테이너들을 연결하는 중간 다리 역할을 합니다.

브릿지 네트워크의 중요한 특징 중 하나는 외부 네트워크와의 통신입니다.

이미지에서 볼 수 있듯이, 호스트 시스템은 192.168.1.2라는 IP를 가지고 있으며, 이를 통해 컨테이너들이 외부 네트워크와 통신할 수 있습니다.

예를 들어, web 컨테이너의 5000번 포트는 호스트의 8000번 포트와 매핑되어 있어, 외부에서 접근이 가능합니다.

이처럼 브릿지 네트워크 모드는 컨테이너 간의 격리된 통신 환경을 제공하면서도, 필요한 경우 외부와의 통신도 가능하게 만드는 유연한 네트워킹 솔루션입니다.

도커 브릿지 네트워크 모드의 특징

기본적으로 컨테이너 간 격리된 네트워크를 제공
"docker network create" 명령어로 사용자 정의 브리지 네트워크 생성 가능
"-p 옵션"을 사용하면 컨테이너 포트를 호스트와 연결 가능

사용 예시

1. 기본 브릿지 네트워크 사용

# 기본 브릿지 네트워크로 nginx 컨테이너 실행
docker run -d nginx

# 포트 매핑과 함께 실행
docker run -d -p 8080:80 nginx

위와 같이 명령어를 실행하면 nginx 컨테이너가 생성되며 자동으로 기본 브릿지 네트워크('docker0')에 연결됩니다.

첫 번째 명령어는 단순히 백그라운드에서 컨테이너를 실행하는 반면, 두 번째 명령어는 포트 매핑을 추가하여 호스트의 8080 포트를 통해

외부에서 nginx 웹 서버(컨테이너의 80 포트)에 접근할 수 있게 됩니다.

2. 사용자 정의 브릿지 네트워크 생성 및 사용

# 새로운 브릿지 네트워크 생성
docker network create myapp-network

# 네트워크에 컨테이너 연결
docker run -d --name backend --network myapp-network mongodb
docker run -d --name frontend --network myapp-network -p 3000:3000 nginx

위와 같이 명령어를 실행하면 먼저 'myapp-network'라는 사용자 정의 브릿지 네트워크가 생성됩니다.

그 다음 MongoDB 컨테이너와 Nginx 컨테이너가 이 네트워크에 연결되어 실행되며, 두 컨테이너는 서로 통신이 가능합니다.

frontend 컨테이너는 포트 매핑(3000:3000)이 설정되어 외부에서 접근할 수 있으며, --name 옵션으로 지정된 이름을 통해 컨테이너들은 서로를 찾을 수 있습니다.

언제 사용하는 것이 좋을까❓

일반적인 MSA환경에서 컨테이너 간 통신이 필요할 때
- 여러 독립적인 서비스(웹 서버, API 서버, 데이터베이스 등)가 서로 통신해야 하는 상황
- 각 서비스를 독립적으로 관리하면서도 안전한 네트워크 통신이 필요한 경우
포트 바인딩을 통해 외부에서 컨테이너에 접근할 때 (-p 8080:80)
- 웹 서버나 API 서버를 외부에 노출시켜야 하는 경우
- 특정 포트만 선택적으로 외부 접근을 허용하고 싶을 때
- 호스트의 포트를 통해 컨테이너의 서비스에 안전하게 접근해야 할 때

Host 네트워크 모드란❓

호스트 네트워크 모드는 컨테이너가 Host의 네트워크를 직접 사용하는 모드입니다.

즉, Host 컴퓨터와 동일한 네트워크 환경 사용

컨테이너가 호스트의 네트워크 네임스페이스를 그대로 사용하기 때문에 별도의 네트워크 격리가 없습니다.

도커 Host 네트워크 모드의 특징

컨테이너가 호스트의 네트워크를 직접 사용하므로 네트워크 성능이 가장 좋음
~~포트 매핑이 필요 없음~~
네트워크 격리가 되지 않아 보안상 취약할 수 있음
호스트의 네트워크 인터페이스를 직접 사용하므로 네트워크 관련 설정이 단순화됨

사용 예시

# 호스트 네트워크 모드로 nginx 실행
docker run -d --network host nginx

위 명령어를 실행하면 nginx 컨테이너가 호스트의 네트워크를 직접 사용하게 되어, ~~별도의 포트 매핑~~ 없이 호스트의 80포트로 직접 접근이 가능합니다.

언제 사용하는 것이 좋을까❓

네트워크 성능이 중요한 경우
- 대용량 데이터 처리가 필요한 서비스
- 지연 시간에 민감한 애플리케이션
호스트 수준의 네트워크 기능이 필요한 경우
- 네트워크 모니터링 도구
- 호스트 네트워크 스택을 직접 조작해야 하는 경우
컨테이너 간 네트워크 격리가 ~~필요 없는~~ 단일 컨테이너 환경

None 네트워크 모드란❓

None 네트워크 모드는 말 그대로 컨테이너의 모든 네트워크를 비활성화하는 모드입니다.

컨테이너가 완전히 격리된 네트워크 환경에서 실행되며, 외부와의 모든 네트워크 연결이 차단됩니다.

도커 None 네트워크 모드의 특징

컨테이너가 네트워크 인터페이스를 가지지 않음
외부와의 모든 네트워크 통신이 불가능
최대한의 네트워크 격리를 제공
컨테이너 내부에서는 localhost(loopback)만 사용 가능

사용 예시

# None 네트워크 모드로 컨테이너 실행
docker run -d --network none alpine

위 명령어를 실행하면 alpine 컨테이너는 완전히 격리된 네트워크 환경에서 실행되며, 외부와의 어떠한 네트워크 ~~통신도 불가능~~합니다.

언제 사용하는 것이 좋을까❓

최대한의 보안이 필요한 경우
- 민감한 데이터를 처리하는 배치 작업
- 네트워크가 전혀 필요 없는 계산 작업
네트워크 접근을 완전히 차단해야 하는 경우
- 보안 정책상 격리가 필요한 작업
- 로컬에서만 실행되는 프로세스

IPvlan과 Macvlan이란❓

IPvlan과 Macvlan은 컨테이너에게 호스트의 네트워크 인터페이스에 직접 연결할 수 있는 권한을 주는 고급 네트워크 모드입니다.

Macvlan 모드

# Macvlan 네트워크 생성
docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 macvlan-net

# Macvlan 네트워크로 컨테이너 실행
docker run --network macvlan-net -d nginx

위 명령어에서 알 수 있듯이 Macvlan은 물리적 네트워크 인터페이스(eth0)에 직접 연결되며, 각 컨테이너에 고유한 MAC 주소와 IP 주소를 할당합니다.

subnet과 gateway를 지정하여 독립적인 네트워크 구성이 가능하며, 이를 통해 컨테이너가 마치 물리적 네트워크에 직접 연결된 것처럼 동작할 수 있습니다.

이는 특히 컨테이너가 물리 네트워크와 직접적인 통신이 필요한 경우나 특정 IP/MAC 주소가 필요한 레거시 애플리케이션을 컨테이너화할 때 유용합니다.

IPvlan 모드

# IPvlan L2 모드 네트워크 생성
docker network create -d ipvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 ipvlan-net

# IPvlan 네트워크로 컨테이너 실행
docker run --network ipvlan-net -d nginx

위 명령어에서 알 수 있듯이 IPvlan은 Macvlan과 유사하게 물리적 네트워크 인터페이스(eth0)에 연결되지만, 모든 컨테이너가 호스트의 MAC 주소를 공유하면서 각자 고유한 IP 주소만을 할당받습니다.

L2 또는 L3 모드로 동작할 수 있으며, -d ipvlan 옵션을 통해 IPvlan 드라이버를 지정합니다. subnet과 gateway 설정으로 네트워크 구성이 가능합니다.

이는 MAC 주소 제한이 있는 환경이나 더 나은 확장성이 필요한 경우에 Macvlan의 대안으로 사용됩니다.

각 네트워크 모드의 차이점

위 이미지처럼 Docker의 네트워크 모드는 Bridge, None, Host 세 가지 방식으로 나눌 수 있습니다.

Bridge 모드
- docker0라는 가상 브릿지를 통해 컨테이너들이 연결되며, 각각 독립된 IP(172.17.0.x)를 할당받아 통신합니다.
None 모드
- 완전히 격리된 네트워크 환경을 제공하여 ~~외부와의 통신이 불가능~~합니다.
Host 모드
- 호스트의 네트워크를 직접 사용하여 별도의 격리 없이 호스트의 포트를 그대로 사용합니다.

이처럼 각각의 네트워크 모드는 서로 다른 특징을 가지고 있으므로, 애플리케이션의 요구사항과 보안 정책에 따라 적절한 모드를 선택하여 사용해야 합니다.

[TIL, 일일 회고] 2025.02.18 - 리눅스 : chown 명령어 알아보기 : -h옵션과 심볼릭 링크의 관계

지누박 — Tue, 18 Feb 2025 22:56:15 +0900

개요

리눅스 시스템에서 파일과 디렉토리의 소유권은 보안과 접근 제어에 매우 중요한 요소입니다. 리눅스에서는 "chown"라는 개념이 존재하는 데, chown(change owner) 명령어는 이러한 소유권을 관리하는 핵심 도구입니다.

본 글에서는 chown 명령어에 대해서 정리하고자 합니다.

chown이란❓

리눅스에서 파일과 디렉토리는 각각 소유자(owner) 와 소유 그룹(group)을 가지는데, chown(change owner)은 파일이나 디렉토리의 소유자 또는 그룹을 변경하는 명령어입니다.

기본 사용법

1. 파일 소유자 변경

chown 새로운소유자 파일명

예시

chown user1 myfile.txt  # myfile.txt의 소유자를 user1로 변경

위와 같이 실행하면 "myfile.txt"파일의 소유자를 user1으로 변경합니다.

2. 파일 소유자와 그룹 변경

chown 새로운소유자:새로운그룹 파일명

예시

chown user1:usergroup myfile.txt  # 소유자를 user1, 그룹을 usergroup으로 변경

위와 같이 실행하면 "myfile.txt"파일의 소유자를 user1으로 변경하고, 소유 그룹을 usergroup으로 함께 변경합니다.

3. 그룹만 변경

chown :새로운그룹 파일명

예시

chown :usergroup myfile.txt

chown의 주요 옵션

-R (recursive)

chown -R john:developers /home/project/

-R 옵션은 디렉토리와 그 하위 모든 파일/디렉토리에 변경 적용합니다.

-v (verbose)

chown -v john file.txt

-v 옵션은 변경된 내용을 자세히 출력하는 옵션입니다.

-f (force)

chown -f john file.txt

-f 옵션을 사용하면 ~~에러 메시지를 표시~~하지 않습니다.

chown -h의 의미

chown명령어의 옵션 중 "-h"옵션이 존재합니다. 이 chown -h 옵션은 심볼릭 링크 자체의 소유권을 변경하는 명령어입니다.

즉, 심볼릭 링크가 가리키는 ~~원본 파일~~이 아니라, 링크 파일 자체의 소유자를 변경합니다.

심볼릭 링크와 -h옵션의 관계

1. 기본 동작(옵션 없을 때)

# example.txt의 소유권이 변경됨
ln -s example.txt symlink.txt
chown john symlink.txt

위와 같이 ~~-h 옵션을 사용~~하지 않는다면, ~~심볼릭 링크~~가 가리키는 원본 파일의 소유권이 변경됩니다.

2. -h 옵션 사용 시

# symlink.txt의 소유권만 변경됨
chown -h john symlink.txt

위와 같이 -h옵션을 실행하면, 심볼릭 링크 자체의 소유권만 변경되고, ~~원본 파일의 소유권은 변경~~되지 않습니다.

실제 예시로 이해하기

# 테스트 파일 생성
echo "원본 파일입니다" > original.txt
ln -s original.txt link.txt

# 현재 상태 확인
ls -l original.txt link.txt

# -h 옵션 없이 chown 실행
chown bob link.txt  # original.txt의 소유자가 bob으로 변경됨

# -h 옵션과 함께 chown 실행
chown -h alice link.txt  # link.txt의 소유자만 alice로 변경됨

이해를 돕기 위해 파일 구조를 시각화하면 다음과 같습니다.

주의 사항

권한 필요성
- chown 명령어는 root 권한이나 sudo 권한이 필요합니다.
- 일반 사용자는 자신이 소유한 파일의 그룹만 변경 가능합니다.
심볼릭 링크 처리
- 기본적으로 심볼릭 링크 자체의 소유권만 변경됩니다.
- -h 옵션을 사용하면 심볼릭 링크 자체의 소유권만 변경되고 ~~원본 파일은 변경~~되지 않습니다.
보안 고려사항
- 파일 소유권 변경은 보안에 직접적인 영향을 미칩니다.
- 특히 시스템 파일의 소유권 변경은 신중하게 수행해야 합니다.

[TIL, 일일 회고] 2025.02.17 - 심볼릭 링크(Symbolic Link)와 하드 링크(Hard Link) 알아보기

지누박 — Mon, 17 Feb 2025 01:30:49 +0900

개요

개발을 하다 보면 같은 파일을 여러 경로에서 접근해야 하는 경우가 있습니다.

예를 들어, 설정 파일을 여러 프로젝트에서 공유하거나, 특정 실행 파일을 다양한 위치에서 실행하고 싶을 경우가 있습니다. 이때 사용하는 개념이 링크(Link) 입니다.

본 글에서는 리눅스의 심볼릭 링크(Symbolic Link) 와 하드 링크(Hard Link)에 대해서 정리하고자 합니다.

심볼릭 링크(Symbolic Link)란❓

심볼릭 링크(Symbolic Link, 소프트 링크) 는 일종의 바로가기 개념으로, 원본 파일의 경로를 참조하는 링크 파일입니다.

주요 특징

원본 파일의 경로를 저장하는 새로운 파일을 생성합니다.
원본 파일이 삭제되면 링크는 깨집니다.
다른 파일시스템에 있는 파일도 링크할 수 있습니다.
디렉토리도 링크할 수 있습니다.

생성 방법

ln -s 원본파일 링크이름

예를 들어, /home/user/config.yaml 파일을 /etc/config.yaml 경로에서도 접근하고 싶다면 다음과 같이 작성할 수 있습니다.

ln -s /home/user/config.yaml /etc/config.yaml

위와 같이 명령어를 실행하면, /etc/config.yaml를 통해 /home/user/config.yaml의 내용을 그대로 볼 수 있습니다.

하드 링크(Hard Link)란❓

하드링크는 원본 파일과 동일한 inode를 가리키는 또 다른 파일명입니다. 즉, 동일한 데이터를 가리키는 여러 개의 파일명이 존재하는 것입니다.

inode 란❓

Unix/Linux 파일 시스템에서 파일이나 디렉토리의 모든 메타데이터를 저장하는 데이터 구조입니다. 쉽게 말해서, 파일의 "신분증" 같은 것입니다.

주요 특징

원본 파일과 완전히 동일한 파일입니다
원본 파일이 삭제되어도 링크된 파일은 계속 사용 가능합니다
같은 파일시스템 내에서만 생성 가능합니다
~~디렉토리는 링크~~할 수 없습니다

생성 방법

ln 원본파일 링크이름

예를 들어, file1.txt의 하드 링크를 file2.txt로 만들고 싶다면 다음과 같이 작성할 수 있습니다.

ln file1.txt file2.txt

위와 같이 명령어를 실행하면 file1.txt와 file2.txt는 동일한 파일을 가리키며, 둘 중 하나를 수정하면 다른 파일도 동일하게 변경됩니다.

심볼릭 링크와 하드 링크의 차이점 한눈에 보기

구분	심볼릭 링크 (Symbolic Link)	하드 링크 (Hard Link)
개념	원본 파일의 경로를 참조하는 파일	원본과 같은 Inode를 가지는 파일
파일 존재 여부	원본 파일이 삭제되면 링크가 깨짐	원본 파일이 삭제되어도 유지됨
디렉토리 링크 가능 여부	가능 ✅	불가능 ❌
다른 파일 시스템에서 가능 여부	가능 ✅	❌ (같은 파일 시스템 내에서만 가능)
Inode 번호	원본과 다름	원본과 같은

결론

심볼릭 링크
- 설정 파일을 공유하거나, 특정 실행 파일을 여러 위치에서 실행해야 할 때 사용
하드 링크
- 백업 파일을 만들거나, 하나의 파일을 여러 경로에서 동일하게 유지하고 싶을 때 사용

[TIL, 일일 회고] 2025.02.16 - MySQL 문자열 검색: LIKE, INSTR, REGEXP, SUBSTRING

지누박 — Sun, 16 Feb 2025 00:57:37 +0900

개요

MySQL 쿼리를 작성하다보면 특정 문자가 포함된 조건을 걸어야할 때가 있습니다.

이때 주로 사용하는 연산자는 LIKE연산자입니다. 이 외에도 MySQL에서는 INSTR() 함수, REGEXP()를 제공합니다.

본 글에서는 INSTR() 함수에 대해서 정리하고자 합니다.

LIKE 연산자란❓

LIKE 연산자는 문자열 패턴 매칭에 사용됩니다. 예를 들어, 특정 문자열이 포함되어 있는지 확인하려면 % 와일드카드를 사용할 수 있습니다.

SELECT *
FROM FOOD_FACTORY
WHERE address LIKE '%강원도%';

위 쿼리는 address 컬럼에 "강원도"라는 문자열이 포함된 모든 행을 반환합니다. %는 어떤 문자열이든 0번 이상 일치하는 부분을 나타냅니다.

%강원도% : "강원도"를 포함하는 모든 문자열
강원도% : "강원도"로 시작하는 모든 문자열
%강원도 : "강원도"로 끝나는 모든 문자열

INSTR()함수란❓

INSTR() 함수는 특정 문자열이 다른 문자열 내에 존재하는지 확인하고, 존재하는 경우 해당 위치를 반환합니다. ~~존재하지 않으면~~ 0을 반환합니다.

SELECT *
FROM FOOD_FACTORY
WHERE INSTR(address, '강원도') > 0;

위 쿼리는 address 컬럼에 "강원도"가 포함된 모든 행을 반환합니다.

INSTR() 함수는 "강원도"가 문자열 내에 존재하는 경우 그 위치를 반환하므로, > 0으로 검사하여 해당 문자열이 포함된 경우를 확인할 수 있습니다.

REGEXP 란❓

REGEXP는 정규 표현식을 사용하여 문자열에서 패턴을 찾는 데 사용됩니다.

LIKE와 비슷하지만, 더 복잡한 패턴 매칭이 가능합니다. 예를 들어, 숫자나 특정 형식의 문자열을 찾을 때 유용합니다.

장점: 복잡한 문자열 패턴을 매칭할 수 있습니다.
단점: 사용이 다소 복잡하고 성능이 떨어질 수 있습니다.

1. 특정 문자열로 시작하는 값 찾기

SELECT *
FROM FOOD_FACTORY
WHERE address REGEXP '^강원도.*';

위 쿼리는 address 컬럼이 "강원도"로 시작하는 데이터를 검색합니다.

2. 특정 문자열로 끝나는 값 찾기

SELECT *
FROM FOOD_FACTORY
WHERE address REGEXP '시$';

위 쿼리는 address 컬럼이 "시"로 끝나는 모든 데이터를 검색합니다. 예를 들어 "서울시", "부산시" 등 "시"로 끝나는 주소를 조회합니다.

3 특정 패턴을 포함하는 값 찾기

SELECT *
FROM FOOD_FACTORY
WHERE address REGEXP '서울|강원';

이 쿼리는 address 컬럼에 "서울" 또는 "강원"이 포함된 데이터를 검색합니다. 예를 들어 "서울특별시", "강원도 강릉시" 등 "서울" 또는 "강원"이 포함된 주소를 조회할 수 있습니다.

위의 예시들을 통해 REGEXP를 사용하여 다양한 패턴 매칭을 할 수 있다는 점을 알 수 있습니다.

SUBSTRING / SUBSTR 란❓

SUBSTRING (또는 SUBSTR)은 문자열의 일부분을 추출할 때 사용됩니다. 이 함수는 문자열에서 지정된 시작 위치와 길이에 해당하는 부분을 반환합니다.

장점: 문자열의 특정 부분을 쉽게 추출할 수 있습니다.
단점: 특정 위치부터 잘라낸 결과만 반환하기 때문에, 포함 여부를 확인하려면 추가적인 로직이 필요합니다.

SELECT *
FROM FOOD_FACTORY
WHERE SUBSTRING(address, 1, 2) = '강원';

위 쿼리는 address의 첫 2자리가 "강원"인 데이터만 반환합니다.

SELECT *
FROM FOOD_FACTORY
WHERE SUBSTRING(address, 3, 2) = '도';

이 쿼리는 address 컬럼의 3번째 문자부터 2자리가 "도"인 데이터를 검색합니다. 예를 들어 "강원도"에서 "도" 부분을 추출하여 비교할 수 있습니다.

[TIL, 일일 회고] 2025.02.15 - MySQL에서 OR 연산자 이외의 조건문 활용법: IN, CASE WHEN, FIND_IN_SET

지누박 — Sat, 15 Feb 2025 21:31:15 +0900

개요

SQL 쿼리문을 작성하다 보면 조건을 조합해야 하는 경우가 많습니다.

이때 가장 일반적으로 사용하는 조건은 OR 연산자입니다.

OR : 여러 조건 중 하나라도 만족하는 데이터를 조회할 때 사용됩니다.

그러나 경우에 따라 IN, BETWEEN, CASE WHEN 등 다른 조건문을 활용하면 쿼리를 더 간결하고 효율적으로 작성할 수 있습니다.

본 글에서는 MySQL에서 조건을 조합할 때 사용할 수 있는 다양한 조건문을 정리하고자 합니다.

일반적으로 사용하는 논리합 : OR

OR 연산자란❓

OR 연산자는 여러 조건 중 하나라도 만족하는 데이터를 조회할 때 사용되는 논리 연산자입니다. 여러 조건을 연결하여 하나라도 만족하는 데이터를 가져와야 할 때 유용하게 사용됩니다.

예시 코드

SELECT * FROM users WHERE age = 30 OR age = 40;

위의 예시에서는 age가 30 또는 40인 사용자들을 조회하는 쿼리입니다. OR 연산자는 두 개 이상의 조건을 결합하여, 하나라도 만족하는 데이터를 반환합니다.

잘못된 사용 ❌

WHERE MCDP_CD = 'CS' || 'GS'

MySQL에서 AND연산일 떄는 "&& "로 표현이 가능하지만 ~~OR연산은 불가능~~합니다.

|| 연산자는 MySQL에서는 OR 연산자로 동작하지 않음
MySQL에서는 ||가 문자열 연결 (CONCAT) 연산자로 해석될 수도 있음
MCDP_CD = 'CS' || 'GS'는 논리적으로 MCDP_CD = ('CS' || 'GS')와 같음
- 'CS' || 'GS'는 MySQL에서 단순한 문자열 연결이므로, MCDP_CD = 'CSGS'와 같은 의미가 됨 → 잘못된 결과 발생

IN 연산자 (여러 개의 = 조건을 단축)

IN 연산자란❓

IN 연산자는 여러 개의 = 조건을 하나로 묶을 수 있는 방법입니다. OR 연산자를 사용하는 대신 IN을 사용하면 SQL을 더 간결하고 가독성 있게 작성할 수 있습니다. IN은 여러 값을 동시에 비교할 때 매우 유용합니다.

예시 코드

-- OR 사용
SELECT * FROM DOCTOR WHERE MCDP_CD = 'CS' OR MCDP_CD = 'GS';

-- IN 사용 (더 간결)
SELECT * FROM DOCTOR WHERE MCDP_CD IN ('CS', 'GS');

위와 같이 IN연산자를 사용하여 여러개의 '='조건을 단축할 수 있습니다. IN연산자를 사용하면 가독성이 좋고, 간결하게 사용할 수 있습니다.

CASE WHEN (조건에 따라 분기 처리)

CASE WHEN 구문이란❓

CASE WHEN 구문은 SQL에서 조건에 따라 결과를 분기 처리할 수 있는 기능을 제공합니다.

특정 조건에 맞는 값을 반환하거나, 그 외의 경우 다른 값을 반환해야 할 때 유용하게 사용됩니다. 이를 통해 쿼리 내에서 조건에 따른 값 변환을 쉽게 처리할 수 있습니다.

예시 코드

SELECT DR_NAME, 
       MCDP_CD,
       CASE 
           WHEN MCDP_CD = 'CS' OR MCDP_CD = 'GS' THEN '외과 계열' 
           ELSE '기타' 
       END AS DEPARTMENT_CATEGORY
FROM DOCTOR;

위의 예시에서는 MCDP_CD가 'CS' 또는 'GS'인 경우 '외과 계열'로 반환하고, 그 외의 경우는 '기타'로 분기 처리합니다.

CASE WHEN을 사용하여 조건에 따라 분기 처리할 수 있습니다. CASE WHEN을 사용하면 특정 조건을 만족하는 경우 값을 변환하기에 적합합니다.

FIND_IN_SET (문자열에서 값 검색)

FIND_IN_SET 함수란❓

FIND_IN_SET 함수는 주어진 문자열이 콤마로 구분된 리스트 안에서 존재하는지 확인하는 함수입니다.

리스트에서 특정 값이 포함되어 있는지 확인하고, 해당 값이 리스트 내에서 몇 번째 위치에 있는지를 반환합니다. 주로 IN과 비슷한 기능을 수행하지만, 값이 문자열로 구분되어 있을 때 유용합니다.

SELECT * FROM users WHERE FIND_IN_SET(MCDP_CD, 'CS',GS');

위의 예시에서 FIND_IN_SET은 MCDP_CD 값이 'CS' 또는 'GS'인 경우를 조회합니다. 콤마로 구분된 문자열 내에서 해당 값이 있는지 확인하는 방법입니다.

[백준, 2630번] 색종이 만들기 (분할 정복, 재귀, Java)

지누박 — Fri, 14 Feb 2025 16:46:12 +0900

문제설명

입력 & 출력

나의 풀이

문제 접근 방법

"백준 - 색종이 만들기" 문제는 하얀색(0)과 파란색(1)로 칠해진 종이가 주어지고 ~~전체 종이가 모두 같은색으로 칠해있지 않으면~~ N/2로 나눠가면서 모든 영역의 종이가 같은색으로만 이루도록 만들고, 각 종이의 색깔의 개수를 출력하는 문제입니다.

위와 같이 최종적으로 나누어진 색종이들을 보면, 흰색은 9개, 파란색은 7개로 나누어집니다.

제가 접근한 방법은 다음과 같습니다.

주어진 종이 전체가 하나의 색깔로 이루어져 있는지 확인
- 모두 같은 색이면 하얀색 종이 개수 또는 파란색 종이 개수를 증가시키고 종료.
하나의 색깔이 아니라면 4등분(재귀 호출)
- N × N 크기의 종이를 N/2 × N/2 크기의 네 개의 부분으로 나누고,
- 각각을 재귀적으로 검사.

이 때 4등분으로 나누는 이유는 다음과 같습니다.

영역 안에 서로 다른 색깔이 섞여 있다면, 이 영역을 4개의 작은 정사각형으로 나누어 다시 검사해야 합니다.

위와 같이 하나의 영역을 4가지 영역 으로 나누어 각각의 영역을 재귀적으로 검사합니다.

이렇게 나눈 각각의 영역에 대해 다시 같은 과정을 반복하며, 모든 칸이 같은 색이 될 때까지 계속해서 분할하고 검사합니다. 이러한 분할 정복(Divide and Conquer) 방식을 통해 전체 종이를 효율적으로 처리할 수 있기 때문입니다.

전체 코드

문제의 핵심은 영역의 색종이가 ~~모두 같은색~~이 아니라면, 주어진 요구사항대로 범위를 줄여야한다는 것입니다.

이를 위해 재귀적으로 범위를 수정하며 각 영역을 검사합니다.

즉, 하나의 큰 정사각형을 4개의 작은 정사각형으로 나누고, 각각의 작은 정사각형에 대해 같은 과정을 반복하는 것입니다. 이러한 과정은 모든 칸이 같은 색이 될 때까지 계속되며, 이는 분할 정복 알고리즘의 전형적인 예시라고 할 수 있습니다.

또한 27번째 줄에서 볼 수 있듯이 각 영역의 첫번째 포인트만 비교하여 색깔의 개수를 카운트합니다. 이는 각 영역이 모두 같은색으로만 이루어져 있다는 것이 확인된 후에 수행되는 작업입니다.

즉, isAllSame이 true인 경우에만 해당 영역을 하나의 색종이로 간주하여 카운트하게 됩니다. 이렇게 함으로써 불필요한 중복 검사를 피하고 효율적으로 색종이의 개수를 셀 수 있습니다.

[TIL, 일일 회고] 2025.02.14 - 리눅스 : umask 명령어란❓

지누박 — Fri, 14 Feb 2025 00:32:59 +0900

개요

리눅스 시스템에서 파일과 디렉토리는 기본적으로 특정한 접근 권한을 가지며, 이는 보안과 직결됩니다.

하지만 새로 생성되는 파일이나 디렉토리가 항상 원하는 권한을 갖도록 설정하려면 어떻게 해야 할까요?

umask(User File Creation Mode Mask) 는 이러한 문제를 해결하는 핵심 개념으로, 기본 권한에서 특정 권한을 자동으로 제거하여 보안을 강화하는 역할을 합니다.

본 글에서는 umask에 대해서 정리하고자 합니다.

umask란❓

리눅스에서 새 파일이나 디렉토리를 생성할 때, 기본적으로 적용되는 권한을 제어하는 값이 umask입니다.

umask 값은 파일이나 디렉토리가 생성될 때 기본적으로 어떤 권한을 제거할지를 결정합니다.

기본적으로 리눅스에서 새로 생성되는 파일과 디렉토리는 다음과 같은 기본 권한(초기 권한)을 가집니다.

파일: 666 (rw-rw-rw-)
디렉토리: 777 (rwxrwxrwx)

하지만 보안상의 이유로 모든 사용자에게 모든 권한을 부여하는 것은 위험하므로, umask 값을 이용해 특정 권한을 자동으로 제거합니다.

umask 계산법

파일 기본 권한 (666) - umask 값 = 최종 파일 권한
디렉토리 기본 권한 (777) - umask 값 = 최종 디렉토리 권한

예를 들어, umask 값이 022라면

파일 권한: 666 - 022 = 644 (rw-r--r--)
디렉토리 권한: 777 - 022 = 755 (rwxr-xr-x)

umask 값 확인 및 설정

1. 현재 umask 값 확인

$ umask
0022  # 일반적으로 시스템 기본값

umask 명령어만 입력하면 현재 설정된 umask 값을 확인할 수 있습니다.

2. 일시적으로 umask 변경

$ umask 027  # 파일: 640, 디렉토리: 750

터미널에서 umask 값을 변경하면, 해당 세션에서만 적용됩니다.

보안 관점에서 적절한 umask 값 설정하기

파일 및 디렉토리의 기본 권한을 적절히 제한하면 보안 강화를 할 수 있습니다.

개인 사용자
- umask 077 (자신만 접근 가능)
일반 서버 환경
- umask 027 (소유자와 그룹만 접근 가능, ~~기타 사용자는 제한~~)
공유 서버 환경
- umask 022 (소유자만 쓰기 가능, 그룹 및 기타 사용자는 읽기 가능)

umask와 chmod 차이점

chmod와 umask는 모두 파일 및 디렉토리 권한을 다루지만, 역할이 다릅니다.

	umask	chmod
적용 시점	파일/디렉토리 생성 시	파일/디렉토리 생성 후
적용 방식	기본 권한에서 특정 권한 제거	지정된 권한으로 설정
사용 목적	자동화된 기본 권한 설정	수동으로 특정 권한 변경
예시 명령어	umask 022	chmod 644 file.txt

결론

umask는 리눅스에서 새 파일과 디렉토리의 기본 권한을 설정하는 중요한 개념입니다.

보안 강화를 위해 적절한 umask 값을 설정하는 것이 중요하며, 서버 환경에 맞춰 설정을 변경하면 보다 안전한 시스템을 운영할 수 있습니다.

[TIL, 일일 회고] 2025.02.13 - 리눅스 파일 접근 권한 이해하기

지누박 — Thu, 13 Feb 2025 23:40:21 +0900

개요

리눅스는 다중 사용자 시스템으로 설계되었습니다. 여러 사용자가 동시에 시스템을 사용하는 환경에서는 파일과 데이터의 안전한 보호가 매우 중요합니다. 이를 위해 리눅스는 파일 접근 권한(File Permission) 시스템을 도입했습니다.

본 글에서는 리눅스의 파일 접근 권한(File Permission) 시스템에 대해서 정리하고자 합니다.

파일 접근 권한의 기본 구조

리눅스에서는 모든 파일에 대해 세 가지 범주의 사용자를 구분하여 서로 다른 접근 권한을 부여할 수 있습니다.

1. 소유자 (Owner)

파일을 소유한 사용자

2. 그룹 (Group)

파일에 지정된 그룹에 속한 사용자들

3. 기타 사용자 (Others)

소유자나 ~~그룹에 속하지 않은~~ 모든 사용자

권한의 종류

각 범주의 사용자에 대해 다음 세 가지 권한을 설정할 수 있습니다.

읽기 권한 (r)
쓰기 권한 (w)
실행 권한 (x)

파일에서의 권한 의미

읽기(r): 파일의 내용을 읽을 수 있음
쓰기(w): 파일의 내용을 수정할 수 있음
실행(x): 파일을 실행할 수 있음

디렉토리에서의 권한 의미

읽기(r): 디렉토리 내용을 볼 수 있음
쓰기(w): 디렉토리 내 파일을 생성/삭제할 수 있음
실행(x): 디렉토리에 접근할 수 있음

접근 권한 8진수 표기법

리눅스는 권한을 8진수로 표현할 수 있습니다.

# 파일 생성
$ touch test.txt

# 소유자:rwx(7), 그룹:r-x(5), 기타사용자:r--(4) 권한 설정
$ chmod 754 test.txt
$ ls -l test.txt
-rwxr-xr-- 1 user group 0 Feb 13 10:00 test.txt

# 소유자:rw-(6), 그룹:r--(4), 기타사용자:r--(4) 권한 설정
$ chmod 644 test.txt
$ ls -l test.txt
-rw-r--r-- 1 user group 0 Feb 13 10:00 test.txt

읽기(r) = 4
쓰기(w) = 2
실행(x) = 1

권한 변경

chmod 명령어 : 권한 변경

1. 숫자를 사용한 방법

chmod 755 file  # rwxr-xr-x
chmod 644 file  # rw-r--r--
chmod 700 file  # rwx------

2. 문자를 사용한 방법

chmod u+x file  # 소유자에게 실행 권한 추가
chmod g-w file  # 그룹의 쓰기 권한 제거
chmod o+r file  # 기타 사용자에게 읽기 권한 추가
chmod a+x file  # 모든 사용자에게 실행 권한 추가

사용자 지정 문자
- u : user(소유자)
- g : group(그룹)
- o : others(기타 사용자)
- a : all(모든 사용자)

연산자
- + : 권한 추가
- - : 권한 제거
- = : 권한 설정

권한 문자
- r : 읽기 권한
- w : 쓰기 권한
- x : 실행 권한

chown 명령어 : 소유자 or 그룹 변경

chown user:group file  # 소유자와 그룹 모두 변경
chown user file       # 소유자만 변경
chown :group file     # 그룹만 변경

권한 설정 시 주의사항

보안을 위한 권한 설정
- 설정 파일: 600 또는 640
- 실행 파일: 755
- 일반 문서: 644
- 중요 데이터: 600
일반적인 실수 피하기
- 777 권한 사용 자제 (모든 사용자에게 모든 권한 부여)
- 홈 디렉토리 권한 관리 (700 또는 750 권장)
- 로그 파일 권한 관리 (644 또는 640 권장)

[TIL, 일일 회고] 2025.02.12 - 리눅스 크론탭(Linux Crontab)

지누박 — Wed, 12 Feb 2025 12:54:19 +0900

개요

서버 관리를 하다 보면 특정 작업을 정해진 시간에 자동으로 실행해야 할 때가 있습니다.

예를 들어, 매일 밤 12시에 데이터베이스 백업을 실행하거나, 매주 일요일마다 로그 파일을 정리하는 등의 작업이 있습니다. 리눅스에서는 이런 반복 작업을 자동화할 수 있는 'crontab'이라는 편리한 도구를 제공합니다.

crontab이란❓

crontab은 리눅스/유닉스 시스템에서 제공하는 작업 스케줄러로, 특정 시간이나 주기적으로 실행해야 하는 작업을 자동화할 수 있게 해주는 도구입니다.

기본 문법

crontab의 기본 문법은 다음과 같습니다.

*　　　　　　*　　　　　　 *　　　　　　*　　　　　　 *
분(0-59)　　시간(0-23)　　일(1-31)　　월(1-12)　　　요일(0-7)

 분(0~59)을 설정. *을 설정한 경우 1분 단위로 실행
 시간(0~23)을 설정. *을 설정한 경우 매시간 실행
 일(1~31)을 설정. *을 설정한 경우 매일 실행
 월(1~12)을 설정. *을 설정한 경우 매달 실행
 요일(0~7)을 설정. *을 설정한 경우 월요일부터 일요일까지 매일 실행

분: 0-59
시: 0-23
일: 1-31
월: 1-12
요일: 0-6 (0은 일요일)

주요 옵션

1. 작업 목록 확인

crontab -l

2. 작업 편집하기

crontab -e

3. 모든 작업 삭제

crontab -r

자우 사용하는 예시 알아보기

1. 매일 특정시간에 실행

# 매일 오후 2시에 실행
0 14 * * * /scripts/daily-backup.sh

2. 매주 특정 요일에 실행

# 매주 일요일 자정에 실행
0 0 * * 0 /scripts/weekly-cleanup.sh

3. 정기적인 간격으로 실행

# 10분마다 실행
*/10 * * * * /scripts/check-service.sh

주의 사항

절대 경로 사용하기
- 명령어와 스크립트는 항상 절대 경로를 사용해야합니다.
- 상대 경로를 사용하면 예상치 못한 문제가 발생할 수 있습니다.
권한 확인하기
- 실행할 스크립트의 실행 권한을 확인해야 합니다.
- 필요한 디렉토리와 파일에 대한 접근 권한 또한 확인해야합니다.

결론

crontab은 시스템 관리자에게 없어서는 안 될 중요한 도구입니다.

반복적인 작업을 자동화함으로써 시간을 절약하고 실수를 줄일 수 있습니다. 하지만 강력한 만큼 신중하게 사용해야 합니다. 잘못 설정된 cron 작업은 시스템에 부담을 주거나 예상치 못한 문제를 일으킬 수 있기 때문입니다.

[백준, 1182번] 부분수열의 합 (브루트 포스, 재귀, 백트래킹, Java)

지누박 — Tue, 11 Feb 2025 17:13:58 +0900

문제설명

입력 & 출력

나의 풀이

문제 접근 방법

"백준 - 부분수열의 합" 문제는 정수 N개 수열과 정수S가 주어졌을 때 해당 수열의 부분 수열에서 더하여 정수 S를 만들 수 있는 경우의 수를 구하는 문제입니다.

위와 같이 정수 S가 0일 때, 수열에서 0을 만들 수 있는 부분수열은 [-3, -2, 5]입니다.

이 부분수열을 찾기 위해서는 수열의 첫 번째 원소부터 차례대로 탐색하며, 각 원소를 포함할지 말지를 결정하여 부분수열을 구성해 나가야 합니다.

즉, 각 원소에 대해 포함할지 말지를 결정해야 하며, 이 과정은 백트래킹(Backtracking) 방식으로 해결할 수 있습니다.

전체 코드

부분 수열을 구할 때, 각 원소를 "포함"하거나 "포함하지 않음" 두 가지 선택합니다.

재귀 함수에서 중요한 부분 중 하나인 탈출 조건은 idx(인덱스)가 수열의 길이와 같을 때, 즉, 수열을 전부 순회했을 때 입니다. 이때, 수열을 모두 탐색한 후, 현재까지 더한 값이 타겟 넘버(S)와 같다면 경우의 수를 증가시킵니다.

이때 중요한 점은 ~~아무 수열도 포함~~하지 않는 경우가 있을 수 있다는 점입니다.

5 0
-7 -3 -2 5 8

첫 번째 정수인 -7부터 포함할지 포함하지 않을지 결정합니다. 이때 ~~-7을 포함~~하지 않는 경우, 부분 수열은 []가 되고, 부분 합은 0이 됩니다.

현재 타겟 넘버 S가 0이므로, 부분 합이 0인 경우는 하나의 유효한 경우로 취급됩니다. 따라서 S가 0일 때는 경우의 수에서 1을 빼줘야 합니다.

ps

처음에는 백트래킹 + 수열 문제이기 때문에 visited 배열을 사용하여 방문여부를 체크하려고 했습니다.

그러나 결과적으로는 visited배열은 필요가 없습니다. 왜냐하면 부분 수열을 구할 때, 각 원소를 "포함"하거나 "포함하지 않음" 두 가지 선택을 하게 되는데, 이 선택 자체가 중복된 탐색을 발생시키지 않기 때문입니다.

for문을 사용하여 ~~모든 인덱스를 반복~~하는 대신, 재귀 호출로 자연스럽게 각 수를 선택하는 방식으로 구현할 수 있습니다.

visited 배열을 사용하여 방문 여부를 체크하는 궁극적인 이유는 중복된 탐색을 방지하기 위함인데, 재귀적 탐색에서 각 선택이 독립적이기 때문에 ~~중복 탐색이 발생~~하지 않아 ~~visited 배열이 필요~~하지 않습니다.

[TIL, 일일 회고] 2025.02.11 - ORDER BY의 숫자의 의미

지누박 — Tue, 11 Feb 2025 01:17:09 +0900

개요

SQL 쿼리를 작성하다보면, SQL에서 ORDER BY 절은 쿼리 결과를 특정 기준으로 정렬할 때 사용합니다.

이 때 컬럼명 대신 숫자로도 정렬이 가능한데, 본 글에서는 이 숫자로 정렬하는 방식에 대해서 정리하고자 합니다.

위치 기반 정렬이란❓

컬럼명 대신 숫자를 사용하여 정렬하는 방식을 위치 기반 정렬(Positional Ordering) 또는 서수 정렬(Ordinal Ordering)이라고 한다고 합니다.

즉, SELECT 문에 나열된 컬럼의 순서를 기준으로 정렬하는 방식입니다.

기존 방식

SELECT name, age, city
FROM users
ORDER BY age;

숫자로 정렬

SELECT name, age, city
FROM users
ORDER BY 2;  -- age 컬럼으로 정렬

위 쿼리에서 숫자 2는 SELECT 문의 두 번째 컬럼(age)을 의미합니다.

위치 값의 의미

1
- SELECT 문의 첫 번째 컬럼
2
- SELECT 문의 두 번째 컬럼
3
- SELECT 문의 세 번째 컬럼

[프로그래머스] Lv.2 3월에 태어난 여성 회원 목록 출력하기 (MySQL)

지누박 — Tue, 11 Feb 2025 01:03:08 +0900

문제 설명

문제

예시

나의 풀이

문제 접근 방법

"프로그래머스 - 3월에 태어난 여성 회원 목록 출력하기" 문제는 식당 리뷰 사이트의 회원 정보를 담은 MEMBER_PROFILE 테이블이 주어질 때 생일이 3월인 여성 회원의 ID, 이름, 성별, 생년월일을 조회하는 SQL문을 작성하는 문제입니다.

문제의 핵심은 생년월일이 담겨져있는 DATE_OF_BIRTH 컬럼을 3월로 포맷팅하는 것 입니다.

이 때 전화번호가 NULL인 경우가 존재하기 때문에 전화번호가 NULL인 경우에는 IS NOT NULL로 제외를 해야합니다.

전체 코드

select MEMBER_ID,MEMBER_NAME,GENDER,DATE_FORMAT(DATE_OF_BIRTH, "%Y-%m-%d") AS DATE_OF_BIRTH
from MEMBER_PROFILE
where DATE_FORMAT(DATE_OF_BIRTH,"%m") = "03"
and TLNO IS NOT NULL
and GENDER = 'W';

원래의 DATE_OF_BIRTH 컬럼은 시, 분, 초가 포함된 전체 날짜 형식을 가지고 있습니다.

SELECT 절에서는 DATE_FORMAT 함수를 사용해 "1993-03-16"와 같이 년-월-일 형식으로 변환합니다.

그리고 WHERER절에서 Month("%m")을 03월로 지정해줍니다.

WHERE 절에서는 DATE_FORMAT 함수의 %m 형식 지정자로 3월생을 필터링하고, IS NOT NULL로 전화번호가 있는 회원만 선택하며, GENDER = 'W'로 여성 회원을 추출합니다.

[프로그래머스] Lv.1 평균 일일 대여 요금 구하기 (MySQL)

지누박 — Mon, 10 Feb 2025 23:01:35 +0900

문제 설명

문제

예시

나의 풀이

문제 접근 방법

"프로그래머스 - 평균 일일 대여 요금 구하기" 문제는 문제의 제목그대로 평균 일일 대여 요금을 구하는 문제입니다.

주어진 자동차 종류에는 세단, SUV, 승합차, 트럭, 리무진이 있으며, 이 중 SUV 차량을 선택한 후 daily_fee 컬럼의 평균을 구하면 됩니다.

이 때 평균이므로 소수점이 존재하는 데 평균 일일 대여 요금은 소수 첫 번째 자리에서 반올림해야합니다.

즉, 정확한 소수점을 구하기 위해서 MySQL의 AVG()함수와 ROUND()함수를 같이 사용해야합니다.

[MySQL] AVG()와 ROUND()로 정확한 평균 구하기

AVG() 함수란❓MySQL의 AVG() 함수는 데이터베이스에서 평균값을 계산하는 필수적인 집계 함수입니다.기본 문법SELECT AVG(column_name) FROM table_name; AVG() 함수의 특징1. NULL 처리SELECT AVG(IFNULL(salary, 0)) FRO

pixx.tistory.com

전체 코드

select ROUND(AVG(daily_fee),0) as AVERAGE_FEE
from CAR_RENTAL_COMPANY_CAR
where CAR_TYPE = "SUV";

평균 일일 대여 요금은 소수 첫 번째 자리에서 반올림 해야한다는 의미는 소수점 자리가 없어야 한다는 의미입니다.

따라서 ROUND()함수의 두 번째 매개변수(소수점 자릿수)를 0으로 지정하여 소수점 0번째까지 표시를 해줍니다.

[MySQL] AVG()와 ROUND()로 정확한 평균 구하기

지누박 — Mon, 10 Feb 2025 22:58:37 +0900

AVG() 함수란❓

MySQL의 AVG() 함수는 데이터베이스에서 평균값을 계산하는 필수적인 집계 함수입니다.

기본 문법

SELECT AVG(column_name) FROM table_name;

AVG() 함수의 특징

1. NULL 처리

SELECT AVG(IFNULL(salary, 0)) FROM employees;

NULL 값은 자동으로 계산에서 제외
NULL을 0으로 처리하려면 IFNULL 함수 사용 필요

2. 소수점 처리

-- 급여 평균이 3456.789일 경우
SELECT ROUND(AVG(salary), 2);  -- 결과: 3456.79
SELECT ROUND(AVG(salary), 1);  -- 결과: 3456.8
SELECT ROUND(AVG(salary), 0);  -- 결과: 3457

소수점을 처리하려면 ROUND()함수를 같이 사용합니다.

ROUND() 함수는 숫자를 반올림하는 함수로, 두 가지 매개변수를 받습니다.

첫 번째 매개변수
- 반올림할 숫자 (여기서는 AVG(salary))
두 번째 매개변수
- 소수점 자릿수

AVG() 함수 활용 예시

1. 기본 평균 계산

SELECT AVG(price) FROM products;

가장 단순한 형태로, products 테이블의 price 컬럼 전체 평균값을 계산합니다.

2. 그룹별 평균

SELECT category, AVG(price) as avg_price 
FROM products 
GROUP BY category;

GROUP BY 절을 사용하여 카테고리별로 평균을 계산합니다.

3. 조건부 평균

SELECT department, 
       AVG(CASE 
           WHEN experience >= 5 THEN salary 
           END) as senior_avg_salary
FROM employees
GROUP BY department;

CASE 문을 활용하여 조건에 맞는 데이터만 평균을 계산합니다. 이 예시에서는 경력 5년 이상인 직원들의 부서별 평균 급여를 계산합니다. 경력 5년 미만인 직원의 급여는 계산에서 제외됩니다.

[백준, 11286번] 절댓값 힙 (우선 순위 큐, 정렬, Java)

지누박 — Mon, 10 Feb 2025 16:01:25 +0900

문제설명

입력 & 출력

나의 풀이

문제 접근 방법

"백준 - 절댓값 힙" 문제는 우선순위 큐 자료구조를 사용하여 풀이한다면 손쉽게 풀이할 수 있는 문제입니다.

[자료구조 JAVA] 우선순위 큐(Priority Queue) 클래스 알아보기 ✔

Java를 활용하다 보면 데이터를 처리할 때 우선순위를 지켜야 하는 상황이 있습니다. 이때 사용할 수 있는 자료구조가우선순위 큐(Priority Queue)입니다. 우선순위 큐를 사용하면 우선순위가 높은

pixx.tistory.com

선순위 큐는 일반적으로 힙(heap)이라는 트리 구조를 기반으로 구현됩니다. 이 힙에 정수x를 넣고 0이 입력될 때마다 힙에서 절댓값이 가장 작은 값을 출력하고, 그 값을 배열에서 제거합니다.

만약 절댓값이 가장 작은 값이 여러개일 때는, 가장 작은 수를 출력하는 문제입니다.

요구사항을 만족하기 위해서는 Comparator를 사용하여 커스텀 정렬을 구현해야합니다.

전체 코드

이번 문제의 핵심인 Comparator를 사용한 커스텀 정렬을 주로 설명해보겠습니다.

PriorityQueue<Integer> priorityQueue = new PriorityQueue<>((a,b) -> {
           int absA = Math.abs(a);
           int absB = Math.abs(b);

           if(absA == absB) return Integer.compare(a,b);

           return Integer.compare(absA,absB);
        });

요구사항 1 : 절댓값이 가장 작은 값을 출력

return Integer.compare(absA,absB);  // 절댓값 기준 정렬

Math.abs()메서드로 절댓값을 구하고
Integer.compare(absA,absB)로 절댓값이 작은 값이 우선순위가 높도록 정렬

요구사항 2 : 절댓값이 가장 작은 값이 여러개일 때는, 가장 작은 수를 출력

if(absA == absB) return Integer.compare(a,b);

절댓값이 같을 때(absA == absB)
원래 값을 비교(Integer.compare(a,b))하여 더 작은 값이 우선순위가 높도록 정렬

정렬 동작 원리

Comparator의 반환 값에 따라서 동작은 다음과 같이 진행됩니다.

// 모든 경우에서
양수 반환 → 순서 바꿈
음수 반환 → 순서 유지
0 반환 → 동일 값

Integer.compare(absA,absB)

absA가 더 크면 양수가 반환되어 순서가 바뀌어 절대값이 작은 값이 앞으로 감
absA가 더 작으면 음수가 반환되어 순서가 유지되어 절대값이 작은 값이 앞에 있게 됨
절대값이 같으면 0이 반환되어 동일한 값으로 취급

즉, 이 비교 로직과 우선순위 큐의 최소 힙 특성이 함께 작용하여 결과적으로 절대값이 작은 값이 큐의 맨 앞에 위치하게 됩니다.

// 절대값 오름차순(작은 값 우선)
return Integer.compare(absA, absB);  // absA가 크면 양수->순서바꿈

// 절대값 내림차순(큰 값 우선)
return Integer.compare(absB, absA);  // absB가 크면 양수->순서바꿈

만약 PriorityQueue가 최대 힙을 기본으로 했다면, 절댓값이 큰 수가 먼저 나오도록 하기 위해 Integer.compare(absB, absA)와 같이 비교 순서를 반대로 해야합니다.

결국 중요한 것은 첫 번째 파라미터가 두 번째 파라미터보다 크면 순서가 바뀐다는 것입니다.

1. 오름차순 정렬을 원할 때: Integer.compare(absA, absB)

예1) absA=5, absB=3 일 때
compare(5,3) → 양수 반환 → 순서 바꿈 → [3,5]
// 5가 3보다 크므로, 순서를 바꿔서 작은 값이 앞으로

예2) absA=2, absB=4 일 때
compare(2,4) → 음수 반환 → 순서 유지 → [2,4]
// 2가 4보다 작으므로, 순서 유지해서 작은 값이 앞으로

2. 내림차순 정렬을 원할 때: Integer.compare(absB, absA)

예1) absA=5, absB=3 일 때
compare(3,5) → 음수 반환 → 순서 유지 → [5,3]
// 3이 5보다 작으므로, 순서 유지해서 큰 값이 앞으로

예2) absA=2, absB=4 일 때
compare(4,2) → 양수 반환 → 순서 바꿈 → [4,2]
// 4가 2보다 크므로, 순서를 바꿔서 큰 값이 앞으로

쉽게 말해서 오름차순 정렬을 위해 a를 앞에 두었다고 이해하면 좋습니다!

[TIL, 일일 회고] 2025.02.10 - API와 Endpoint 차이점 알아보기

지누박 — Mon, 10 Feb 2025 01:06:53 +0900

개요

웹 개발을 하다보면 자주 사용되는 용어인 API와 Endpoint가 있습니다. 이 둘은 많은 개발자들이 혼동하기 쉬운 개념인데, 저는 Endpoint를 URL의 특정 resource path로 알고있었습니다.

본 글에서는 API와 Endpoint의 정확한 의미와 차이점에 대해 정리하고자 합니다.

API란❓

API(Application Programming Interface)는 서로 다른 소프트웨어 시스템들이 통신할 수 있게 해주는 인터페이스입니다.

즉, 어플리케이션 간의 통신을 할수 있게 해주는 접점

예를 들어, 카카오 API는 지도, 결제, 로그인 등 다양한 서비스를 제공하며, 각 서비스에 접근하기 위한 규칙과 방법을 정의합니다.

Endpoint란❓

Endpoint는 API의 한 구성 요소로, 특정 기능이나 리소스에 접근할 수 있는 구체적인 URL이나 URI를 의미합니다. API에 액세스하거나 API와 상호 작용하기 위한 진입점 역할을 합니다.

Endpoint는 다음과 같은 특징을 가집니다.

Endpoint의 특징

구체적인 기능 제공
명확한 URL 구조
특정 HTTP 메소드(GET, POST, PUT, DELETE 등) 사용
단일 리소스나 기능에 대한 접근점

Endpoint의 예시

GET /books : 모든 책 목록을 검색합니다.
GET /books/{id} : ID로 특정 책을 검색합니다.
POST /books : 새로운 책을 만듭니다.
PUT /books/{id} : 기존 책을 ID로 업데이트합니다.
DELETE /books/{id} : ID로 책을 삭제합니다.

API와 Endpoint의 차이점

Endpoint는 API의 구성 요소인 반면 API는 두 애플리케이션이 리소스를 공유할 수 있도록 하는 규칙 집합입니다.

Endpoint는 리소스의 위치이고 API는 엔드포인트 URL을 사용하여 요청된 리소스를 검색합니다.

1. 범위의 차이

API: 전체 서비스의 인터페이스를 포괄하는 상위 개념
Endpoint: API 내의 특정 기능이나 리소스에 접근하는 단일 접점

2. 기능적 차이

API
- 전체 시스템의 통신 규약 정의
- 보안과 인증 메커니즘 제공
- 데이터 교환 방식 설정
- 전반적인 서비스 구조 설계
Endpoint
- 특정 리소스에 대한 CRUD 작업 수행
- 단일 기능이나 서비스 제공
- 구체적인 데이터 처리
- 특정 HTTP 메소드로 작업 수행

3. 구조적 차이

API는 여러 Endpoint들의 집합체
하나의 API는 다수의 Endpoint를 포함
Endpoint는 API의 실제 구현체
API는 Endpoint들을 조직화하고 관리

4. 실제 사용 예시

API: https://api.example.com/
Endpoints:
- /users: 사용자 프로필 관리
- /messages: 다이렉트 메시지 기능
- /media: 미디어 파일 업로드/다운로드

5. 관계성

API는 도서관 전체 시스템
Endpoint는 도서관 내의 특정 서비스 창구나 책장
- 대출 창구 (/borrow)
- 반납 창구 (/return)
- 회원가입 창구 (/register)

결론

API와 Endpoint는 밀접한 관계를 가지고 있지만, 그 범위와 역할에서 명확한 차이를 보입니다.

API가 전체 서비스의 인터페이스를 정의한다면, Endpoint는 그 인터페이스 내에서 실제로 기능을 수행하는 접점이라고 할 수 있습니다.

[Docker] 도커 네트워크 이해하기 (Docker network)

지누박 — Sun, 9 Feb 2025 23:04:37 +0900

개요

Docker를 사용하다 보면 여러 컨테이너 간의 통신이 필요한 상황이 발생합니다. 도커는 이런 상황에서 컨테이너 간 안전하고 효율적인 통신이 가능하게 하는 network기능을 제공합니다.

본 글에서는 Docker Network에 대해서 정리하고자 합니다.

Docker Network란❓

https://www.docker.com/blog/understanding-docker-networking-drivers-use-cases/

Docker Network는 컨테이너 간의 통신을 가능하게 하는 가상의 네트워크 인프라입니다. 여러 컨테이너가 서로 통신해야 하는 상황에 필수적인 요소입니다.

Docker Network가 필요한 이유

컨테이너 간 안전한 통신 환경 구축
마이크로서비스 아키텍처(MSA) 구현
애플리케이션 컴포넌트 간의 격리
IP 주소 대신 컨테이너 이름으로 통신 가능

Docker Network 사용 방법

1. 네트워크 생성

볼륨과 달리 Docker는 네트워크를 ~~자동으로 생성~~하지 않습니다. 따라서 네트워크를 사용하기 전에 먼저 생성해야 합니다.

docker network create [네트워크_이름]

2. 네트워크에 컨테이너 연결

네트워크를 생성한 후에는 컨테이너를 실행할 때 --network 옵션을 사용하여 해당 네트워크에 연결할 수 있습니다.

생성된 네트워크에 컨테이너를 연결하는 방법은 다음과 같습니다.

docker run -d --name mongodb --network [네트워크_이름] mongo

Docker Network 특징 : 컨테이너 이름을 통한 통신

Docker Network의 가장 큰 장점 중 하나는 ~~IP 주소~~ 대신 컨테이너 이름을 사용할 수 있다는 점입니다.

1. 컨테이너 이름을 통한 통신

1.1 기존의 IP기반 통신

mongoose.connect(
  'mongodb://172.17.0.2:27017/swfavorites',
  { useNewUrlParser: true }
);

1.2 Docker Network를 사용한 통신

mongoose.connect(
  'mongodb://mongodb:27017/swfavorites',
  { useNewUrlParser: true }
);

Docker는 자동으로 컨테이너 이름을 해당 IP 주소로 변환해주므로, ~~하드코딩된 IP 주소를 사용~~할 필요가 없습니다.

2. 포트 게시 없는 자유로운 통신

docker run -d --name mongodb --network facorites-net mongo

위 코드를 보면 컨테이너에 연결하기 위해 실행할 때 ~~포트를 게시~~하지 않은 것을 확인할 수 있습니다.

이는 의도된 것으로, 같은 네트워크 내의 컨테이너들은 ~~포트 게시~~ 없이도 자유롭게 통신할 수 있기 때문입니다. 포트 게시는 로컬 호스트나 외부에서 컨테이너에 접근해야 할 때만 필요합니다.

Docker Network 활용 예시

[Docker] Docker 컨테이너에서 호스트 머신에 접근하기: host.docker.internal

개요Docker를 사용하다 보면 컨테이너 내부에서 로컬 머신의 애플리케이션이나 데이터베이스에 접근해야 할 때가 있습니다.이때 사용할 수 있는 기능이 바로 host.docker.internal 입니다. 본 글에서

pixx.tistory.com

위 포스팅에서의 간단한 시나리오에 Docker Network를 활용하는 방법을 살펴보겠습니다.

1) 네트워크 연결 시도

먼저 MongoDB 컨테이너를 실행하면서 네트워크에 연결해보겠습니다.

docker run -d --name mongodb --network favorites-net mongo

예상대로 "네트워크를 찾을 수 없다" 는 에러가 발생합니다. Docker는 볼륨과 달리 ~~네트워크를 자동으로 생성~~하지 않기 때문입니다.

2) 네트워크 생성

docker network create favorites-net

docker network --help 명령어로 확인해보면 네트워크 생성을 위한 create 옵션을 확인할 수 있습니다. 이를 사용하여 네트워크를 생성해보겠습니다.

이렇게 생성된 네트워크는 Docker 내부 네트워크로, 컨테이너 간 통신에 사용됩니다.

3) MongoDB 컨테이너 실행

이제 생성된 네트워크를 사용하여 다시 MongoDB 컨테이너를 실행합니다.

docker run -d --name mongodb --network favorites-net mongo

4) 컨테이너 간 통신 설정

기존에는 다음과 같이 MongoDB의 IP 주소를 직접 지정했습니다.

mongoose.connect(
  'mongodb://container-ip:27017/swfavorites', // 127.17.0.2
  { useNewUrlParser: true },
  (err) => {
    if (err) {
      console.log(err);
    } else {
      app.listen(3000);
    }
  }
);

하지만 이런 IP 하드코딩 방식은 좋지 않습니다. Docker Network를 사용하면 IP 대신 컨테이너 이름을 사용할 수 있습니다.

mongoose.connect(
  'mongodb://mongodb:27017/swfavorites',
  { useNewUrlParser: true },
  (err) => {
    if (err) {
      console.log(err);
    } else {
      app.listen(3000);
    }
  }
);

Docker가 자동으로 컨테이너 이름을 해당 IP 주소로 변환해주기 때문에, 더 안정적이고 관리하기 쉬운 방식입니다.

[TIL, 일일 회고] 2025.02.09 - MySQL : CONCAT_WS로 문자열 손쉽게 결합하기

지누박 — Sun, 9 Feb 2025 00:42:15 +0900

개요

데이터베이스 작업 시 여러 문자열을 하나로 합쳐야 하는 경우가 자주 있습니다. MySQL에서는 이러한 작업을 위해 CONCAT_WS 함수를 제공합니다.

본 글에서는 MySQL의 CONCAT_WS 함수에 대해서 정리하고자 합니다.

CONCAT_WS란❓

CONCAT_WS는 "Concatenate With Separator"의 약자로, 여러 문자열을 지정된 구분자로 연결하는 MySQL 함수입니다.

CONCAT_WS의 기본 문법

CONCAT_WS(separator, string1, string2, ...)

일반 CONCAT 함수와 달리, CONCAT_WS는 첫 번째 인자로 구분자를 지정하고, 이후의 모든 문자열 사이에 해당 구분자가 자동으로 삽입됩니다.

CONCAT과 CONCAT_WS의 차이점

-- CONCAT 사용
SELECT CONCAT('Hello', ' - ', 'World', ' - ', '!');
-- 결과: Hello - World - !

-- CONCAT_WS 사용
SELECT CONCAT_WS(' - ', 'Hello', 'World', '!');
-- 결과: Hello - World - !

위 결과에서 알 수 있듯이 CONCAT과 CONCAT_WS의 주요 차이점은 구분자(separator) 처리 방식입니다.

CONCAT을 사용할 때는 구분자를 각각 직접 입력해야 합니다.

즉, 'Hello'와 'World' 사이, 'World'와 '!' 사이에 각각 ' - '를 별도로 지정해야 합니다.

-- CONCAT: 구분자를 4번 써야 함
CONCAT(str1, ' - ', str2, ' - ', str3, ' - ', str4, ' - ', str5)

-- CONCAT_WS: 구분자를 한 번만 쓰면 됨
CONCAT_WS(' - ', str1, str2, str3, str4, str5)

반면 CONCAT_WS는 첫 번째 인자로 구분자를 한 번만 지정하면, 이후의 모든 문자열 사이에 자동으로 해당 구분자가 삽입됩니다. 이는 코드를 더 간결하게 만들고, 실수를 줄일 수 있으며, 특히 많은 문자열을 연결할 때 매우 효율적입니다.

CONCAT_WS 주의 사항❗️

구분자는 반드시 첫 번째 인자로 지정해야 합니다.
문자열이 아닌 데이터 타입은 자동으로 문자열로 변환됩니다.
구분자가 NULL이면 전체 결과가 NULL이 됩니다.

[TIL, 일일 회고] 2025.02.08 - Java 입력 처리: BufferedReader vs Scanner 실제 성능 비교해보기

지누박 — Sat, 8 Feb 2025 01:22:03 +0900

개요

Java 알고리즘 문제 풀이에서 Scanner로 입력을 받다가 시간 초과가 발생할 때, BufferedReader 클래스로 변경하면 해결되는 경우가 있습니다.

BufferedReader 클래스는 버퍼를 이용해 입력을 한 번에 읽어오기 때문에 Scanner보다 빠른 것으로 알려져 있습니다.

하지만 BufferedReader는 String으로 입력을 받아 정수로 형변환이 필요하므로, 단일 정수나 적은 양의 정수 입력에서는 Scanner가 더 빠를 것이라는 의문이 있었습니다.

본 글에서는 적은 양의 정수 입력에서도 BufferedReader가 실제로 더 빠른지 코드를 통해 검증해보겠습니다.

BufferedReader 클래스와 Scanner의 차이

위 그림에서 알 수 있듯이, Scanner는 데이터를 읽을 때마다 시스템에 직접 요청하는 반면, BufferedReader는 버퍼에 데이터를 한 번에 불러온 후 버퍼에서 읽어오는 방식으로 작동합니다.

이러한 입력 방식의 차이로 인해 BufferedReader가 더 효율적인 입력 처리가 가능합니다.

자세한 내용은 아래의 포스팅에서 확인 가능합니다.

[JAVA] 입출력, BufferedReader, StringTokenizer, StringBuilder 알아보기

Java로 코딩테스트를 보거나 입력을 사용해야 할 때 Scanner 클래스를 사용하면 편리하지만 속도가 느리다는 단점이 있습니다. 그렇기 때문에 속도가 빠른 BufferReader 클래스를 사용을 하면 시간복

pixx.tistory.com

Scanner의 내부 동작

Scanner는 입력 처리 시 다음과 같은 복잡한 과정을 거칩니다.

입력 데이터를 토큰 단위로 분리
정규표현식을 사용한 패턴 매칭
입력 유효성 검사 및 예외 처리
데이터 타입 변환

이러한 다단계 처리 과정은 유연한 입력 처리를 가능하게 하지만, 동시에 성능 저하의 원인이 됩니다.

특히 nextInt()와 같은 메서드 호출 시마다 이 과정이 반복되어 실행됩니다.

입력 방식별 속도 비교 ✅

import java.io.*;
import java.util.*;

public class InputPerformanceTest {
    public static void main(String[] args) throws Exception {
        // Scanner 테스트
        long startTime = System.nanoTime();
        Scanner sc = new Scanner(System.in);
        int n1 = sc.nextInt();
        long scannerTime = System.nanoTime() - startTime;

        // BufferedReader 테스트
        startTime = System.nanoTime();
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int n2 = Integer.parseInt(br.readLine());
        long bufferTime = System.nanoTime() - startTime;

        // 결과 출력 (나노초 -> 밀리초 변환)
        System.out.println("Scanner 실행 시간: " + scannerTime / 1000000.0 + "ms");
        System.out.println("BufferedReader 실행 시간: " + bufferTime / 1000000.0 + "ms");
    }
}

실행 결과

3
3
Scanner 실행 시간: 636.295833ms
BufferedReader 실행 시간: 413.656583ms

실행 결과에서 알 수 있듯이, 단일 정수 입력에서도 BufferedReader가 Scanner보다 더 빠른 성능을 보여줍니다.

실제로 BufferedReader는 Scanner보다 약 220ms 더 빠른 실행 시간을 기록했습니다. 이는 Scanner의 복잡한 내부 처리 과정이 단순 형변환보다 더 많은 시간을 소요하기 때문입니다.

결론

백준 사이트의 입력 속도 비교 자료를 보면 위와 같이 BufferedReader클래스를 통한 입력이 높은 순위에 위치하는 것을 알 수 있습니다.

그러면, 무조건 BufferedReader를 쓰면되는 것인가❓

코딩테스트나 알고리즘 문제 풀이에서 입력 처리 속도는 BufferedReader가 더 빠릅니다.

하지만 적은 양의 입력을 처리할 때는 속도 차이가 미미하므로, 문제의 입력 크기와 복잡도를 고려하여 Scanner와 BufferedReader를 적절히 선택하는 것이 좋 습니다.

대량의 데이터를 처리하거나 시간 제한이 빡빡한 경우 BufferedReader를, 단순한 입력의 경우 가독성이 좋은 Scanner를 사용하는 것이 좋을 것 같다는 개인적인 생각입니다.

[백준, 7569번] 토마토 (너비 우선 탐색 : BFS, Java)

지누박 — Fri, 7 Feb 2025 16:05:10 +0900

문제설명

입력 & 출력

나의 풀이

문제 접근 방법

이번 "백준 - 토마토"문제는 "백준7576번 문제"와 거의 같은 문제입니다. 7576번 문제와 다른 점은 하나의 위 아래로 박스가 추가되었다는 점입니다.

위 아래로 박스가 추가되었기 때문에 방향도 마찬가지로 앞, 뒤가 추가되었습니다.

접근 방법도 마찬가지로 동일합니다.

M x N 크기의 상자가 주어지고, 해당 상자의 토마토가 있을 때 다음 조건을 만족하는 토마토가 모두 익을 때까지의 최소 날짜를 출력해야 합니다.

보관 후 하루가 지나면 익은 토마토들의 인접한 곳에 있는 익지 않은 토마토들은 익은 토마토의 영향을 받아 익게 된다.
저장될 때부터 모든 토마토가 익어있는 상태이면 0을 출력해야 하고, ~~토마토가 모두 익지는 못하는 상황~~이면 -1을 출력

왼쪽 그림과 같이 앞 뒤에 있는 위치까지 생각하여 계산해야 합니다.

이는 3차원 배열에서 한 토마토의 위치에서 상, 하, 좌, 우와 더불어 앞, 뒤 총 6방향으로 토마토가 익어나갈 수 있음을 의미합니다.

이러한 3차원적 전파를 BFS를 통해 구현하여 모든 토마토가 익는데 걸리는 최소 시간을 계산할 수 있습니다.

예를 들어 현재 토마토가 (1,1,1) 위치에 있다면:

상: (0,1,1)
하: (2,1,1)
좌: (1,0,1)
우: (1,2,1)
앞: (1,1,0)
뒤: (1,1,2)

이렇게 6방향으로 토마토가 익어나갈 수 있습니다.

전체 코드

코드는 크게 4가지로 구성되어있습니다.

1. static 변수

N, M, H
- 상자의 세로(행), 가로(열), 높이를 저장

[JAVA] 좌표와 2차원 배열 매핑의 이해 (좌표 ➡️ 배열)

프로그래밍을 하다 보면 좌표와 배열을 매핑하는 작업이 필요할 때가 많습니다. 특히 2차원 배열을 다루는 알고리즘 문제에서는 좌표 (x, y)를 배열에 올바르게 맵핑하는 것이 중요합니다

pixx.tistory.com

N과 M을 좌표형식으로 받아야하기 때문에 기존의 행열처럼 ~~[행][열], [가로][세로]~~가 아닌 M은 가로, N은 세로로 입력받습니다. 이는 좌표평면에서 (x,y) 형식을 따르기 위함입니다.

box
- 토마토의 상태를 저장하는 3차원 배열
queue
- BFS에서 익은 토마토의 위치를 저장하는 큐
days
- 토마토가 모두 익는데 걸리는 최소 날짜
dx, dy, dz
- 6방향(상,하,좌,우,앞,뒤)을 나타내는 방향 배열

이러한 static 변수들은 전역적으로 사용되어 메서드 간에 데이터를 공유하는 데 사용됩니다.

2. main 문

main 문제에서는 BufferedReader클래스를 사용하여 입력을 빠르게 받아주고, StringTokenizer 클래스를 사용하여 공백을 기준으로 토큰으로 분리해주었습니다.

그리고 static 변수를 초기화해주고, 토마토의 상태를 저장하는 배열인 box에다가 값을 넣어줍니다.

마지막으로 bfs함수를 호출합니다.

3. bfs 함수

bfs함수에서는 각 레벨별로 그래프 탐색을 시작합니다. size 만큼 반복문을 돌림으로써 같은 날짜에 익은 토마토들을 한꺼번에 처리할 수 있습니다.

size는 현재 레벨에서 처리해야 할 토마토의 개수를 나타내기 때문입니다.

예를 들어 첫 번째 레벨에서 size가 3이라면, 이는 처음부터 익어있던 토마토가 3개라는 의미이고, 이 3개의 토마토가 동시에 주변 토마토들에게 영향을 미치게 됩니다.

이처럼 size를 통해 같은 시점에 영향을 미치는 토마토들을 함께 처리함으로써, 정확한 일수 계산이 가능해집니다. 만약 size로 구분하지 않는다면, 서로 다른 날짜에 익어야 할 토마토들이 섞여서 처리될 수 있기 때문입니다.

큐에서 현재 위치를 꺼내고(poll), 해당 위치에서 6방향(상,하,좌,우,앞,뒤)으로의 탐색을 진행합니다.

범위 체크: 새로운 위치(nx,ny,nz)가 상자 범위 내에 있는지 확인
익지 않은 토마토 체크: box[nz][nx][ny] == 0 인지 확인
토마토 익히기: 조건을 만족하면 해당 위치의 토마토를 익힘(1로 변경)
위치 저장: 새롭게 익은 토마토의 위치를 큐에 추가

레벨의 모든 토마토를 처리한 후, ~~큐가 비어있지 않다면~~(다음 날에 익을 토마토가 있다면) days를 증가시킵니다.

큐에는 새롭게 익은 토마토의 위치가 저장되어 있습니다. 즉, 다음날에 영향을 미칠 수 있는 토마토들의 위치가 저장되어 있는 것입니다.

만약 큐가 비어있다면, 이는 더 이상 익을 수 있는 토마토가 없다는 것을 의미합니다. 이는 모든 토마토가 익었거나(정상 종료), 더 이상 익힐 수 없는 토마토가 남아있는 경우(비정상 종료)가 될 수 있습니다.

이 과정을 큐가 빌 때까지(더 이상 익을 토마토가 없을 때까지) 반복합니다.

4. checkTomato 함수

checkTomate 함수에서는 간단하게 전체 박스의 토마토를 순회하면서 0이 있는 지 없는 지 체크를 합니다.

0이 있다는 의미는 BFS함수를 통해 탐색을 했음에도 익지 않은 토마토가 남아있다는 의미입니다. 이는 토마토가 모두 익지 못하는 상황이므로 -1을 반환합니다.

반대로 0이 없다면 모든 토마토가 익었다는 의미이므로 days를 반환하여 토마토가 모두 익는데 걸린 최소 일수를 출력합니다.

[TIL, 일일 회고] 2025.02.07 - VO와 DTO는 같은 의미인가❓

지누박 — Fri, 7 Feb 2025 13:02:17 +0900

개요

데이터를 다루는 객체를 설계하다 보면 VO(Value Object)와 DTO(Data Transfer Object)를 자주 마주하게 됩니다.

얼핏 보면 비슷해 보이는 이 두 객체는 각각의 특성과 사용 목적이 명확히 다릅니다. 이번 글에서는 VO와 DTO의 차이점에 대해 정리하고자 합니다.

VO(Value Object)란❓

VO는 도메인에서 한 개 또는 그 이상의 속성들을 묶어서 특정 값을 나타내는 객체입니다.

또한 VO(Value Object)는 값을 표현하는 객체로, 불변(immutable) 특성을 가지며, 동일한 값을 가지면 같은 객체로 취급됩니다.

VO 예시

// VO: 값 자체를 표현, 불변
public class Money {
    private final int amount;  // 불변(final)
    
    public Money(int amount) {
        this.amount = amount;
    }
    
    // 새로운 객체 생성
    public Money add(Money other) {
        return new Money(this.amount + other.amount);
    }
    
    // 값이 같으면 같은 객체
    @Override
    public boolean equals(Object obj) {
        if (!(obj instanceof Money)) return false;
        return amount == ((Money)obj).amount;
    }
}

VO의 특징

1. 불변성(Immutable)

번 생성된 후 값을 변경할 수 없음
값 변경이 필요한 경우 새로운 객체 생성

2. 동등성(Equality)

모든 속성값이 같다면 같은 객체로 판단
equals()와 hashCode() 메서드 재정의 필요

DTO(Data Transfer Object)란❓

DTO는 계층 간 데이터 전송을 위해 사용되는 객체입니다.

DTO(Data Transfer Object)는 애플리케이션의 다양한 레이어나 시스템 간에 데이터를 전송하기 위해 사용하는 단순화된 데이터 구조입니다.

DTO는 데이터 전송에 필요한 필드만 포함하며, ~~비즈니스 로직이나 메서드는 포함~~하지 않아 데이터의 효율적 전송과 관리가 용이합니다.

DTO 예시

// DTO: 데이터 전달용
public class UserDTO {
    private String name;    // 가변
    private int age;       // 가변
    
    // getter/setter
    public void setName(String name) {
        this.name = name;
    }
}

DTO의 특징

1. 가변성(Mutable)

setter를 통한 값 변경 가능
데이터 전달이 주 목적

2. 동일성(Identity)

인스턴스가 다르면 다른 객체로 취급
값이 모두 같아도 별개의 객체

3. 단순 데이터 전달

Getter/setter 외 비즈니스 로직 ~~미포함~~

DTO(Data Transfer Object)란❓

구분	VO (Value Object)	DTO (Data Tranfer Object)
목적	값 자체를 표현	데이터 전달
가변 / 불변	✅ 불변성	setter 존재 시 가변 setter 미 존재 시 불변
동등 결정	송성값이 모두 같으면 같은 객체 ✅	속성값이 모두 같아도 같은 객체 ❌
로직	getter/setter외의 로직을 포함할 수 있다.	getter/setter외의 로직을 갖지 않는다.
사용 예시	금액, 좌표, 날짜 등	API 요청 / 응답 데이터

결론

소프트웨어 설계의 대가이자 리팩토링, 엔터프라이즈 애플리케이션 아키텍처 패턴의 선구자인 마틴 파울러의 저서에 따르면 DTO와 VO의 개념이 혼용되어 개발자 커뮤니티에 혼란을 초래했다고 언급한 바 있습니다.

실제로 저를 포함하여 많은 개발자들이 두 개념을 유사하게 인식하는 이유는 둘 다 데이터를 전달하는 역할을 하기 때문인 것 같습니다.

그러나 VO는 동일한 값을 가지면 같은 객체로 판단하는 불변 객체이며, 비즈니스 로직을 포함할 수 있습니다.

반면, DTO는 단순한 데이터 전달 객체로, ~~불변성을 보장~~하지 않으며 ~~비즈니스 로직을 포함~~하지 않습니다.

[백준, 14888번] 연산자 끼워넣기 (브루트 포스, 백트래킹, Java)

지누박 — Thu, 6 Feb 2025 16:04:08 +0900

문제설명

입력 & 출력

나의 풀이

문제 접근 방법

"백준 - 연산자 끼워넣기" 문제는 N개의 수열이 주어지고, N-1개의 연산자가 +, -, * ,/ 순서대로 주어질 때 각 수와 연산자를 조합해서 최댓값과 최솟값을 구하는 문제입니다.

이 때 식의 계산은 ~~기존의 연산자 우선 순위를 무시~~하고 앞에서부터 진행해야 합니다.

수열의 끝까지 연산자를 조합해서 계산해야 하며, 각 연산자의 개수가 제한되어 있어 특정 연산자를 더 이상 사용할 수 없는 경우가 발생합니다.

수열: [1, 2, 3, 4, 5]
연산자: [+(1개), -(2개), *(1개), /(0개)]

위와 같이 입력이 주어질 때 '+' 연산자는 1번 사용을 하면 ~~더 이상 사용~~하지 못합니다.

이러한 특성 때문에 가능한 모든 경우를 탐색하되, 특정 연산자를 더 이상 사용할 수 없는 경우는 탐색을 중단하는 백트래킹 방식을 사용하면 효율적으로 문제를 해결할 수 있습니다.

예제 입력2를 수열과 연산자로 표현하면 위와 같습니다. 이 수열과 연산자를 DFS 알고리즘과 백트래킹을 통해 접근하는 과정을 살펴보겠습니다.

이 문제의 핵심은 DFS와 백트래킹을 활용하여 가능한 모든 연산자 조합을 탐색하는 것입니다. 위 그림과 같이, 매 단계에서 사용 가능한 연산자를 선택하여 연산을 수행하고, 해당 연산자의 개수를 감소시킵니다.

이때 하늘색 노드는 현재 사용 가능한 연산자를, 분홍색 노드는 이미 사용한 연산자를 나타냅니다.

DFS를 통해 더 깊은 단계로 진행하면서 남은 연산자들로 계산을 이어가고, 최종적으로 수열의 끝까지 도달하면 그 결과값을 저장합니다. 이러한 과정을 통해 가능한 모든 조합의 결과값들 중 최댓값(35) 과 최솟값(17)을 찾아낼 수 있습니다.

전체 코드

코드는 크게 2가지로 구분되어 있습니다.

1. main 문

main 문에서는 입력을 BufferedReader 클래스와 StringTokeinzer클래스를 사용하여 빠른 입력처리와 토큰을 사용하여 분리를 해주었습니다.

2. dfs 함수

dfs함수에서는 중요한 부분은 크게 2가지로 나뉩니다. DFS 알고리즘에서 중요한 탈출 조건과 재귀 호출입니다.

num[] : 순열을 저장한 배열
op[] : 연산자의 개수를 순서대로 저장한 배열
count
- 사용한 연산자의 개수
- 다음에 사용할 숫자의 인덱스를 결정 (count + 1)
currValue : 현재까지의 계산 결과

DFS 함수는 크게 두 부분으로 구성됩니다. 먼저 탈출 조건을 확인하고, 그 다음 가능한 연산자들을 탐색합니다.

탈출 조건은 단순합니다. 문제에서 N개의 숫자와 N-1개의 연산자가 주어지므로, 사용한 연산자의 개수(count)가 N-1과 같아지면 모든 연산자를 사용했다는 의미입니다. 이 시점에서 현재까지의 계산 결과와 이전에 저장된 최댓값, 최솟값을 비교하여 갱신합니다.

연산자 탐색 과정에서는 네 가지 연산자(+, -, *, /)에 대해 반복문을 수행합니다.

각 연산자의 남은 개수가 0보다 크다면, 해당 연산자를 사용할 수 있다는 의미입니다. 연산자를 선택하면 그 개수를 1 감소시키고, 선택한 연산자로 계산을 수행한 결과값과 함께 다음 단계(count + 1)로 재귀 호출을 진행합니다.

이러한 과정을 통해 가능한 모든 연산자 조합을 탐색하면서, 최적의 결과값을 찾아낼 수 있습니다.

[TIL, 일일 회고] 2025.02.06 - 호출 스택(Call Stack)의 동작 원리와 예제로 이해하기

지누박 — Thu, 6 Feb 2025 00:50:52 +0900

호출 스택(Call Stack)이란❓

콜 스택(Call Stack)은 프로그램에서 메서드(함수) 호출을 추적하는 메모리 영역입니다.

LIFO(Last In, First Out) 구조를 가지며, 가장 마지막에 호출된 함수가 먼저 실행 완료되어 제거됩니다.

콜 스택의 기본 특징

LIFO(Last In First Out) 방식으로 동작
각 스레드마다 독립적인 콜스택 보유
메소드 호출 시 스택 프레임(Stack Frame) 생성
메소드 실행 완료 시 해당 프레임 제거

콜 스택의 동작 원리

함수 호출 시 스택 프레임(Stack Frame) 추가
- 함수가 호출될 때, 해당 함수의 매개변수, 지역 변수, 반환 주소 등의 정보가 담긴 스택 프레임이 스택에 쌓입니다.
함수 실행 완료 시 스택 프레임 제거
- 함수 실행이 끝나면, 해당 스택 프레임이 제거(Pop) 되며, 이전 함수로 돌아갑니다.
메인 함수 종료 시 스택 비움
- 프로그램의 main() 함수까지 종료되면, 스택이 완전히 비워집니다.

호출 스택(Call Stack) 동작 과정

 public class CallStack {
    public static void main(String[] args) {
        System.out.println("main() 호출");
        first();
        System.out.println("main() 종료");
    }

    public static void first() {
        System.out.println("first() 호출");
        second();
        System.out.println("first() 종료");
    }

    public static void second() {
        System.out.println("second() 호출");
        third();
        System.out.println("second() 종료");
    }

    public static void third() {
        System.out.println("third() 호출");
        System.out.println("Hello from third()");
        System.out.println("third() 종료");
    }
}

실행 결과

main() 호출
first() 호출
second() 호출
third() 호출
Hello from third()
third() 종료
second() 종료
first() 종료
main() 종료

위 실행 결과에서 알 수 있듯이 메소드가 호출되는 순서대로 스택에 쌓이고(push), 각 메소드의 실행이 완료되면 역순으로 스택에서 제거(pop)됩니다.

처음 main() 메소드가 호출되고
main() 내부에서 first()가 호출되고
first() 내부에서 second()가 호출되고
second() 내부에서 third()가 호출됩니다.

그리고 third() 메소드의 실행이 완료되면서부터 역순으로

third()가 종료되어 스택에서 제거되고
second()가 종료되어 스택에서 제거되고
first()가 종료되어 스택에서 제거되고
마지막으로 main()이 종료되어 스택에서 제거됩니다.

이것이 바로 콜스택의 LIFO(Last In First Out) 구조를 보여줍니다.

[TIL, 일일 회고] 2025.02.05 - 하노이 탑 알고리즘, 왜 재귀여야 할까❓

지누박 — Wed, 5 Feb 2025 01:56:58 +0900

개요

하노이 탑 알고리즘은 다음과 같은 규칙을 가집니다.

한 번에 하나의 원반만 이동 가능
큰 원반이 작은 원반 위에 올 수 없음

이러한 규칙을 보면 맨 위의 원반부터 이동하므로 선입선출 구조인 큐나 배열의 사용을 고려할 수 있습니다. 하지만 하노이 탑은 대표적인 재귀 문제로 알려져 있습니다.

본 글에서는 하노이 탑 알고리즘에서 재귀 호출이 더 적합한 이유에 대해서 정리하고자 합니다.

왜 하노이 탑 문제에서 재귀를 사용해야할까❓

하노이 탑 문제 간단 소개

하노이 탑은 세 개의 기둥과 크기가 다른 원판들로 구성된 퍼즐입니다.
모든 원판을 처음 기둥에서 마지막 기둥으로 옮기되, 큰 원판 위에 작은 원판만이 올 수 있습니다.
이러한 분할 정복(Divide and Conquer) 방식은 재귀 호출과 자연스럽게 어울립니다.

1. 문제의 자기 유사성

하노이 탑은 "더 작은 하노이 탑 문제"로 나눌 수 있습니다.
n개의 원판을 이동하는 문제는 "(n-1)개의 원판을 이동하는 문제"로 분해할 수 있습니다.

2. 상태 관리의 단순화

큐나 배열을 사용하면 각 기둥의 상태를 직접 관리해야 합니다.
반면 재귀를 사용하면 "어떤 원판을 어디로 옮길지"에만 집중할 수 있습니다.
재귀 호출의 콜 스택이 자연스럽게 원판의 순서를 보장합니다.

3. 직관적인 문제 해결 방식

큰 문제를 동일한 형태의 작은 문제로 나누어 해결하는 방식이 직관적입니다.
원판 3개를 옮기는 과정을 생각해보면:
- 위의 2개 원판을 보조 기둥으로 이동
- 가장 큰 원판을 목적지로 이동
- 2개 원판을 다시 목적지로 이동

4. 코드의 간결성

반복문으로 구현할 경우 여러 조건문과 상태 체크가 필요합니다.
재귀를 사용하면 문제의 본질적인 로직만 남겨 코드가 간결해집니다.
코드의 가독성과 유지보수성이 향상됩니다.

5. 스택을 활용한 비재귀적 접근 가능성

하노이 탑 문제는 본질적으로 재귀적이지만, 명시적으로 스택(Stack) 자료구조를 활용하면 반복문으로도 구현할 수 있습니다.
그러나 이 방법은 재귀 호출이 내부적으로 활용하는 콜 스택(Call Stack)을 직접 관리해야 하므로 코드가 복잡해질 수 있습니다.

[정보처리기사] 합격 후기 및 학습 사이트 추천

지누박 — Tue, 4 Feb 2025 16:30:01 +0900

제가 응시했던 회차는 2022년 2회 정보처리기사 시험입니다.

블로그를 옮기면서 미처 옮기지 못했고, 시험을 오래전에 보긴했지만 제가 봤던 2022년 2회차 시험은 필기와 실기 모두 낮은 합격률을 보였기 때문에 합격 후기 및 공부방법에 대해서 정리하고자합니다..!

정보처리기사 - 필기 책 : 시나공

필기는 시나공책을 구매했습니다.

다른 자격증들은 수제비를 구매했지만 이번에는 시나공도 경험을 해보고 싶어 시나공으로 결정을 했습니다.

전공자이지만 당시에는 더욱 더 말하는 감자였습니다...ㅎ

필기는 아무래도 문제를 많이 풀어보고 암기가 중요하다고 생각했기 때문에 1달 전 부터 2회독을 하고 난 뒤 기출문제를 일주일 동안 풀었습니다.

지금은 필기는 CBT를 통해서 보는 것 같기도 했는데 당시에는 실기와 마찬가지로 직접 가서 봐야했었습니다.

정보처리기사 - 실기 책 : 수제비

실기 책은 수제비를 구매했습니다.

필기에서 시나공을 경험했지만, 실기에서는 암기나 이해보다는 문제를 좀 더 많이 풀어봐야한다고 생각했기 때문에 수제비의 트레이드 마크인 두음법칙과 개념이 잘 정리되어있어서 문제 풀이에 집중할 수 있었습니다.

정보처리기사는 위에 자료에서 알 수 있듯이 필기보다 실기의 합격률이 낮습니다.

따라서 필기의 준비 기간보다 좀 더 써서 여유롭게 2달전 부터 천천히 회독을 시작했습니다.

필기와 마찬가지로 2회독을 하고, 똑같이 문제풀이에 집중했습니다.

도움을 준 사이트

아무래도 SQLD나 ADsP와 같은 자격증보다 좀 더 어렵기도하고, 시간이 많이 소요되는 자격증이었습니다.

필기와 실기 모두 공통적으로 도움을 준 사이트와 카페를 공유하고자 합니다!

1. 전자 문제집 CBT

정보처리기사 필기 기출문제 및 CBT 2022년 04월 24일(2회) - 정보처리기사 필기 기출문제 전자문제

위 이미지를 클릭하시면 전자문제집 CBT 서버에 접속 됩니다. (해설, 모의고사, 오답노트, 워드, 컴활, 기능사 등 상설검정 CBT 프로그램 기능 포함) 전자문제집 CBT란? 인터넷으로 문제를 풀고 자동

www.comcbt.com

2. 시나공 CBT 동영상

시나공

컴활, 정보처리, 워드프로세서 등 IT 자격증 전문. 해설 포함 CBT, 최신 기출 자료 무료, 실기 채점 프로그램 제공

www.sinagong.co.kr

3. 필기 기출 문제 CBT

정보처리기사 객관식 필기 기출문제 CBT 목록 - 킨즈

www.kinz.kr

4. 수제비 카페

수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페

수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리산업기사, 빅데이터 분석기사, 컴활 등)

cafe.naver.com

5. 서술형 요약 정리 notion

[정처기] 서술형 대비 요약정리 | Notion

Made with Notion, the all-in-one connected workspace with publishing capabilities.

nanalike.notion.site

6. 프로그래밍 언어

흥달쌤

흥달쌤과 함께하는 IT 채널입니다. 정보처리기사 자격증 관련된 강의 및 실무 노하우, 프로그래밍 언어(JAVA, C언어, Python) 특강 등이 진행됩니다. 앞으로 진행 예정인 동영상은 IT 관련된 이야기

www.youtube.com

[백준, 11729번] 하노이 탑 이동 순서 (재귀 , Java)

지누박 — Tue, 4 Feb 2025 16:28:38 +0900

문제설명

입력 & 출력

나의 풀이

문제 접근 방법

"백준 - 하노이 탑 이동 순서" 문제는 하노이탑 알고리즘을 사용하는 대표적인 문제입니다. 다음과 같은 제약사항이 있는 상황에서 목적지 까지 옮기는 횟수와 순서를 출력하는 문제입니다.

한 번에 한 개의 원판만을 다른 탑으로 옮길 수 있다.
쌓아 놓은 원판은 항상 위의 것이 아래의 것보다 작아야 한다.

하노이 탑 전체 이동 순서

위와 같이 첫 번째 기둥에서 마지막 기둥까지의 이동순서가 나오며, 하노이 탑(Hanoi Tower) 알고리즘의 최소 이동 횟수는 다음 공식으로 계산됩니다.

2^n - 1

이 때 공식을 알고있으면 최소 이동 횟수는 간단하게 구할 수 있지만, 문제의 핵심은 이동 순서를 출력해야한다는 것 입니다.

문제의 목표는 모든 원판을 첫 번째 장대에서 세 번째 장대로 옮기는 것입니다. 이때 주어진 제약 조건을 지켜야 합니다.

가장 큰 원판을 목적지로 옮기기 위해서는, 먼저 그 위에 있는 모든 원판들을 임시 기둥으로 이동시켜야 합니다.

그 다음 가장 큰 원판을 목적지 기둥으로 옮기고, 마지막으로 임시 기둥에 있는 원판들을 크기 순서에 맞게 목적지 기둥으로 이동시키면 됩니다.

정리하자면,

기본 원리 (재귀)

가장 작은 원판(1)부터 이동
작은 원판들이 이동할 공간(tmp 기둥)을 확보
큰 원판을 목표 기둥(end)으로 이동
임시로 옮겨둔 작은 원판들을 다시 목표 기둥으로 이동

전체 코드

재귀 함수의 마지막 매개변수 count는 현재 이동해야 할 원판의 개수를 나타냅니다. 실제 원판의 이동 과정은 StringBuilder를 사용하여 기록하고 출력합니다.

[TIL, 일일 회고] 2025.02.04 - Docker : Container Inspect로 컨테이너 세부 정보 확인하기

지누박 — Tue, 4 Feb 2025 00:31:14 +0900

개요

[Docker] Docker 주요 명령어 알아보기

Docker 이미지 관련 명령어이미지 가져오기docker pull [이미지명]Docker Hub 또는 다른 레지스트리에서 이미지를 다운로드합니다.이미지 빌드docker build -t [이미지명]:[태그] [경로]Dockerfile을 사용하여

pixx.tistory.com

위 포스팅에서 정리했던 주요 명령어 중에서 network, volume에 대한 상세정보를 확인하는 명령어인 "inspect" 말고도 docker를 사용하다보면 컨테이너나의 상세 정보를 확인해야 할 때가 있습니다. 이럴 때 사용하는 것이 바로 docker container inspect 명령어입니다.

본 글에서는 docker container inspect 명령어에 대해서 간단히 정리하고자 합니다.

Docker Container Inspect

기본 사용법

docker container inspect container_name_or_id

주요 확인 정보

1. 컨테이너 기본 정보

컨테이너 ID
생성 시간
현재 상태
Docker 버전

2. 네트워크 설정

IP 주소
MAC 주소
포트 바인딩
네트워크 모드

3. 스토리지 설정

볼륨 마운트 정보
바인드 마운트 경로
임시 마운트 정보

4. 리소스 제한

CPU 할당량
메모리 제한
ulimits 설정

inspect : 필터링

# IP 주소만 확인
docker container inspect -f '{{.NetworkSettings.IPAddress}}' container_name

# 모든 마운트 포인트 확인
docker container inspect -f '{{.Mounts}}' container_name

# 환경변수 목록 확인
docker container inspect -f '{{.Config.Env}}' container_name

Docker Container Inspect 활용하기

[Docker] Docker 컨테이너에서 호스트 머신에 접근하기: host.docker.internal

pixx.tistory.com

위 포스팅에서의 로컬 머신의 mongoDB 데이터베이스와 간단한 Node 애플리케이션 코드 중 "host.docker.internal" 도메인이 있습니다.

mongoose.connect(
  'mongodb://host.docker.internal:27017/swfavorites',
  { useNewUrlParser: true },
  (err) => {
    if (err) {
      console.log(err);
    } else {
      app.listen(3000);
    }
  }
);

host.docker.internal은 Docker 컨테이너에서 호스트 머신에 접근할 때 사용하는 특별한 도메인입니다. 그러나 MongoDB를 Docker 컨테이너로 실행할 경우에는 이 ~~도메인을 사용~~할 수 없습니다.

대신, MongoDB 컨테이너의 IP 주소를 사용해야 합니다. 이 IP 주소는 다음 명령어로 확인할 수 있습니다.

docker container inspect mongodb-container

출력된 JSON 정보에서 NetworkSettings.IPAddress 값을 찾아 MongoDB 연결 문자열에 사용하면 됩니다.

mongoose.connect(
  'mongodb://container-ip:27017/swfavorites', // 127.17.0.2
  { useNewUrlParser: true },
  (err) => {
    if (err) {
      console.log(err);
    } else {
      app.listen(3000);
    }
  }
);

"inspect"명령어를 사용하면 위와 같이 정보들이 나오는데, 여기서 IPAddress를 보면 이 IP주소를 사용하면됩니다.

[TIL, 일일 회고] 2025.02.03 - Java 배열 초기화: Arrays.fill()과 반복문의 성능 비교

지누박 — Mon, 3 Feb 2025 01:48:52 +0900

개요

Java에서 배열을 초기화할 때 주로 사용하는 두 가지 방법이 있습니다.

Arrays.fill() 메서드를 사용하는 방법과 for 반복문을 사용하는 방법입니다. 오늘은 이 두 방식의 성능을 비교하고 실제 어떤 상황에서 어떤 방법을 선택하는 것이 좋을지 알아보겠습니다.

두 가지 초기화 방법

1. Arrays.fill() 사용

int[] arr1 = new int[size];
Arrays.fill(arr1, 5);

2. for 반복문 사용

int[] arr2 = new int[size];
for(int i = 0; i < size; i++) {
    arr2[i] = 5;
}

성능 테스트

다양한 크기의 배열에서 두 방식의 성능을 비교해보았습니다.

public class ArrayInitializationTest {
    public static void main(String[] args) {
        test(10_000_000);     // 천만
        test(50_000_000);     // 오천만
        test(100_000_000);    // 일억
        test(200_000_000);    // 이억
    }
    
    public static void test(int size) {
        System.out.println("\n배열 크기: " + size);
        
        long startFill = System.nanoTime();
        int[] arr1 = new int[size];
        Arrays.fill(arr1, 5);
        long endFill = System.nanoTime();
        
        long startFor = System.nanoTime();
        int[] arr2 = new int[size];
        for(int i = 0; i < size; i++) {
            arr2[i] = 5;
        }
        long endFor = System.nanoTime();
        
        System.out.println("Arrays.fill() 시간: " + 
            (endFill - startFill) / 1_000_000.0 + " ms");
        System.out.println("for문 시간: " + 
            (endFor - startFor) / 1_000_000.0 + " ms");
    }
}

실행 결과

위와 같이 실행 결과가 나오는데, 물론 매 실행마다 결과는 달라집니다.

그러나 반복문이 배열의 크기가 큰 경우 대체로 더 좋은 성능을 보이는 것을 알 수 있습니다.

이는 Arrays.fill() 메서드가 내부적으로 처리하는 작업들이 큰 배열에서는 오히려 오버헤드로 작용할 수 있다는 것을 의미합니다.

특히 배열 크기가 매우 큰 경우(1억 이상)에서는 반복문이 Arrays.fill()보다 약 2-3배 정도 더 빠른 성능을 보이는 경향이 있습니다.

물론 배열의 크기가 1억 이상일 경우는 ~~일반적이지 않습니다~~. 따라서 일반적인 상황에서는 코드의 가독성과 유지보수성을 고려하여 Arrays.fill() 메서드를 사용하는 것이 더 좋은 선택일 것입니다.

Arrays.fill()은 메서드 이름 자체로 배열을 특정 값으로 채운다는 의도가 명확하게 드러나고, 실제 사용되는 배열 크기에서는 성능 차이가 크지 않기 때문입니다.

[Docker] Docker 컨테이너에서 호스트 머신에 접근하기: host.docker.internal

지누박 — Sun, 2 Feb 2025 17:34:18 +0900

개요

Docker를 사용하다 보면 컨테이너 내부에서 로컬 머신의 애플리케이션이나 데이터베이스에 접근해야 할 때가 있습니다.

이때 사용할 수 있는 기능이 바로 host.docker.internal 입니다.

본 글에서는 ~ 할 수 있는 "host.docker.internal"에 대해서 정리하고자 합니다.

host.docker.internal이란❓

컨테이너 내부에서 호스트 머신(로컬 컴퓨터)의 네트워크에 접근할 수 있도록 제공되는 특별한 도메인입니다.

즉, 컨테이너가 실행되는 호스트 머신의 IP를 자동으로 매핑해 주는 역할을 합니다.

기본적으로 localhost는 컨테이너 내부를 가리키기 때문에 "host.docker.internal"을 사용해야 호스트 머신의 서비스(DB 등) 에 접근할 수 있습니다. 주로 개발 환경에서 유용하게 사용됩니다.

주요 특징

Docker Desktop을 사용할 때 Docker가 자동으로 제공하는 DNS 이름입니다.
컨테이너 내부에서 이 주소를 사용하면 호스트 머신의 localhost에 접근할 수 있습니다.

host.docker.internal 사용해보기

시나리오

MongoDB는 호스트 머신(로컬)에서 실행 중 (포트 27017)
Node.js 애플리케이션은 도커 컨테이너 내부에서 실행
컨테이너에서 'localhost'로 MongoDB 접근 시도 시 연결 실패

애플리케이션 코드

''''''''
생략
''''''''

mongoose.connect(
  'mongodb://localhost:27017/swfavorites',
  { useNewUrlParser: true },
  (err) => {
    if (err) {
      console.log(err);
    } else {
      app.listen(3000);
    }
  }
);

본 글에서 확인할 것은 컨테이너 내부에서 로컬 머신에 접근할 수 있는 지를 확인해보는 것이기 때문에 애플리케이션 코드의 일부를 발췌했습니다. 위 코드로 컨테이너를 실행하면 아래와 같은 에러가 발생합니다.

이미지

이 에러는 ~~컨테이너가 호스트 머신에 연결~~하지 못했다는 의미입니다. 이는 예상된 결과인데, MongoDB는 로컬 머신에서 실행되고 있고 애플리케이션은 도커 컨테이너 내부에서 실행되고 있기 때문입니다.

수정된 애플리케이션 코드 : host.docker.internal

mongoose.connect(
  'mongodb://host.docker.internal:27017/swfavorites',
  { useNewUrlParser: true },
  (err) => {
    if (err) {
      console.log(err);
    } else {
      app.listen(3000);
    }
  }
);

host.docker.internal 도입
- localhost를 도커가 이해할 수 있는 특별한 도메인으로 바꿔줘야 합니다. 이것이 바로 "host.docker.internal"입니다.
도메인 변환 과정:
- 이 특수 도메인은 도커에 의해 자동으로 인식됩니다.
- 도커 컨테이너 내부에서 호스트 머신의 실제 IP 주소로 자동 변환됩니다.
연결 프로세스:
- 컨테이너는 host.docker.internal을 통해 호스트 머신을 찾습니다.
- 호스트 머신의 27017 포트에서 실행 중인 MongoDB에 연결됩니다.

결론

host.docker.internal은 개발 환경에서 컨테이너와 호스트 머신 간의 통신을 단순화하는 유용한 도구입니다.

하지만 실제 운영 환경에서는 보안과 안정성을 고려한 적절한 네트워크 구성이 필요하며 개발 환경에서 사용하는 것이 권장됩니다.

[TIL, 일일 회고] 2025.02.02 - 그래프 탐색(DFS, BFS)에서 방문 배열(visited)의 차원 결정하기

지누박 — Sun, 2 Feb 2025 00:15:21 +0900

개요

알고리즘 문제를 풀다 보면 그래프 탐색 알고리즘(BFS, DFS) 을 사용할 때, 중복 방문을 방지하기 위해 boolean 배열을 활용하게 됩니다.

이때, 방문 체크용 boolean 배열을 1차원으로 사용할지, 2차원으로 사용할지 헷갈리는 경우가 많습니다.

이는 탐색 대상이 되는 그래프의 구조를 확인하면 쉽게 결정할 수 있습니다. 본 글에서는 그래프의 형태에 따라 boolean 배열을 어떻게 설정해야 하는지 정리하고자 합니다.

1차원 boolean 배열을 사용하는 경우

그래프가 일반적인 정점(Node) 중심의 탐색일 때
인접 리스트 또는 인접 행렬로 그래프가 표현된 경우
정점 개수가 N개라면, boolean[N] 크기의 방문 배열을 사용

예제: 그래프의 각 정점을 방문하는 경우

boolean[] visited = new boolean[N]; // 정점 방문 여부 저장

void dfs(int node) {
    visited[node] = true;
    for (int next : graph[node]) { // 현재 노드와 연결된 노드들 탐색
        if (!visited[next]) {
            dfs(next);
        }
    }
}

2차원 boolean 배열을 사용하는 경우

그래프가 좌표(Point) 중심의 탐색일 때
즉, 2D 격자를 탐색하는 경우
- 예: NxM 크기의 지도, 미로, 체스판 등
(x, y) 위치를 방문했는지를 저장하려면 boolean[N][M] 크기의 배열을 사용

예제: 미로 탐색 (BFS / DFS)

boolean[][] visited = new boolean[N][M]; // 2D 방문 배열

void bfs(int x, int y) {
    Queue<int[]> queue = new LinkedList<>();
    queue.add(new int[]{x, y});
    visited[x][y] = true;

    while (!queue.isEmpty()) {
        int[] cur = queue.poll();
        int cx = cur[0], cy = cur[1];

        for (int d = 0; d < 4; d++) { // 4방향 이동 (상하좌우)
            int nx = cx + dx[d], ny = cy + dy[d];

            if (nx >= 0 && ny >= 0 && nx < N && ny < M && !visited[nx][ny]) {
                visited[nx][ny] = true;
                queue.add(new int[]{nx, ny});
            }
        }
    }
}

결론

✅ 그래프 탐색(정점 기준) → boolean[N] (1차원)
✅ 격자(좌표 기준) 탐색 → boolean[N][M] (2차원)
- 즉, 탐색 대상이 "정점"이면 1차원, "좌표"이면 2차원

[백준, 1697번] 숨바꼭질 (BFS, 너비 우선 탐색, Java)

지누박 — Sat, 1 Feb 2025 16:14:00 +0900

문제설명

입력 & 출력

나의 풀이

문제 접근 방법

"백준 - 숨바꼭질" 문제는 수빈(N)이와 동생(K)의 위치가 주어질 때 동생을 찾을 수 있는 가장 빠른 시간을 출력하는 문제입니다.

수빈이는 걷거나 순간이동을 할 수 있다.
수빈이의 위치가 x라면
- 걷기 : x + 1, X -1
- 순간이동 : x * 2

즉, 수빈이가 동생을 찾을 수 있는 최단 시간을 구하는 것이기 때문에 BFS 문제의 대표적인 형태입니다.

트리 계층도

위와 같이 시작 노드에서 시작해서 수빈이가 이동할 수 있는 위치를 탐색하고, 최단시간이니깐 BFS를 사용하여 해결합니다.

각 위치에서 수빈이는 1초 후에 X-1, X+1, X*2로 이동할 수 있으며, Time이 증가할 때마다 모든 가능한 위치를 큐에 넣어 순서대로 탐색합니다.

이렇게 BFS로 탐색하면 처음 목표 위치(동생의 위치)에 도달했을 때가 항상 최단 시간이 됩니다.

위 트리 계층도대로 예제 입력을 표현하자면 다음과 같습니다.

위와 같이 수빈이의 위치(5)에서 시작해서 레벨 단위로 수빈이가 탐색할 수 있는 위치를 큐에 넣고, 동생의 위치인 17을 찾을 때까지 BFS로 탐색합니다.

각 시간(Time)마다 큐에서 위치를 꺼내서 -1, +1, ×2 연산 을 통해 이동할 수 있는 모든 위치를 다음 레벨의 큐에 넣습니다.

Time 4에서 16에서 +1 연산을 통해 동생의 위치인 17에 도달하게 되어 최단 시간인 4초를 구할 수 있습니다.

이 때 중복을 피하기 위해서 방문 여부를 체크할 visited 배열을 사용하여 방문한 노드를 체크해줍니다. 위 예제에서는 노드4 에서 이동이 가능한 위치는 (3,5,8)인데, 5는 이미 시작노드에서 이미 방문했으므로 제외가 되는 것입니다.

전체 코드

[TIL, 일일 회고] 2025.02.01 - 퍼스트 파티(First Party)와 세컨드 파티(Second Party)

지누박 — Sat, 1 Feb 2025 00:19:00 +0900

퍼스트 파티(First Party)란❓

퍼스트 파티(First Party)는 데이터를 직접 수집하고 보유하는 주체를 의미합니다.

주로 기업이 고객과 직접 상호작용을 통해 얻은 데이터를 말하며, 신뢰성이 높고 활용도가 뛰어납니다.

퍼스트파티 데이터의 예시

웹사이트 방문자가 남긴 정보 (회원 가입, 로그인, 쿠키, 행동 데이터)
고객이 구매한 내역 및 트랜잭션 데이터
고객이 기업과 직접 소통한 데이터 (고객 문의, 설문조사 등)

세컨드 파티(Second Party)란❓

세컨드 파티(Second Party)는 퍼스트 파티 데이터를 다른 기업과 공유하거나 제공받아 활용하는 경우를 의미합니다.

보통 신뢰할 수 있는 파트너나 제휴사 간의 데이터 거래를 통해 이루어집니다.

세컨드파티 데이터의 예시

항공사와 호텔 간의 데이터 공유 (예: 항공사가 호텔에 고객 데이터를 제공하여 맞춤형 서비스를 제공)
광고 네트워크가 특정 기업과 제휴하여 고객 데이터를 공유
리테일 업체가 브랜드와 데이터를 공유하여 타겟 마케팅 강화

퍼스트, 세컨드, 써드 파티의 차이점

구분	퍼스트 파티 (First Party)	세컨드 파티 (Second Party)	써드 파티 (Third Party)
데이터 출처	직접 수집한 데이터	신뢰할 수 있는 파트너로부터 제공받은 데이터	외부 플랫폼(데이터 브로커 등)에서 수집한 데이터
신뢰도	매우 높음	비교적 높음	상대적으로 낮음
활용 목적	내부 분석, 마케팅 최적화	파트너십을 활용한 마케팅	광고 및 대규모 마케팅 캠페인
개인정보 보호	강력한 규제 준수 가능	협의된 범위 내에서 준수	규제 준수 어려움 (GDPR, CCPA 등의 영향)

[TIL, 일일 회고] 2025.01.31 - 써드파티(3rd party)

지누박 — Fri, 31 Jan 2025 23:32:21 +0900

개요

현대 소프트웨어 개발에서 써드파티 API는 필수불가결한 요소가 되었습니다. 본 글에서는 퍼스트파티,써드파티 중 써드파티의 개념부터 실제 활용 방법, 그리고 주의해야 할 점들까지 정리하고자 합니다.

써드 파트(3rd Party)란❓

"3rd Party"는 "제3자" 또는 "외부 당사자"를 나타내는 용어입니다.

소프트웨어 개발에서 "써드파티"는 특정 기업이 아닌 외부에서 개발한 라이브러리, 플러그인, API 등을 의미합니다.

써드파티의 종류

1. 3rd Party 라이브러리

특정 기능을 수행하는 코드 패키지로, ~~개발자가 직접 구현~~하지 않고 프로젝트에서 쉽게 가져와 사용할 수 있음
예시: Lombok, Gson, Apache Commons, Log4j

2. 3rd Party SDK

특정 플랫폼이나 서비스와 쉽게 연동할 수 있도록 제공되는 개발 도구 모음
API뿐만 아니라 샘플 코드, 문서, 빌드 도구 등이 포함될 수 있음
예시: Firebase SDK, 토스 페이먼츠 SDK, Facebook SDK, AWS SDK

3. 3rd Party API

외부 서비스와 상호작용할 수 있도록 제공되는 API로, 특정 기능을 호출하여 사용할 수 있음
예시: Google Maps API, Stripe API, OpenAI API, Twilio API

써드 파티(3rd Party) API란❓

써드파티 API는 특정 기업이나 서비스에서 개발하여 외부 개발자들이 사용할 수 있도록 공개한 API입니다.

쉽게 말해, 다른 회사에서 제공하는 기능을 우리 서비스에 쉽게 연동할 수 있도록 만들어진 API입니다.

예를 들어, 우리가 웹사이트나 앱에 "카카오 로그인", "네이버 지도", "토스페이먼츠 결제" 같은 기능을 추가할 때 해당 기업에서 제공하는 API를 활용하면 ~~직접 기능을 개발~~하지 않고도 쉽게 적용할 수 있습니다.

써드파티 API의 특징

1. 외부 제공

특정 기업(제공자)이 개발하고, 외부 개발자나 기업이 사용할 수 있도록 공개한 API입니다.

2. 특정 기능 제공

결제, 지도, 번역, 로그인, 메시징, AI 등의 기능을 제공하여 개발자가 빠르게 서비스에 적용할 수 있도록 지원합니다.

3. 인증 필요

대부분 API 키(API Key) 또는 OAuth 인증 방식을 사용하여 보안이 강화되어 있습니다.

4. 공식 문서 제공

API 사용법, 예제 코드, 응답 형식 등을 정리한 공식 문서가 함께 제공됩니다.

써드 파티(3rd Party) API의 장점

개발 시간 단축
- 직접 개발할 필요 없이 검증된 기능을 바로 사용
- 복잡한 기능도 간단한 API 호출로 구현 가능
비용 절감
- 자체 개발 대비 저렴한 비용
- 유지보수 부담 감소
전문성 활용
- 각 분야 전문 기업의 기술력 활용
- 지속적인 업데이트와 보안 관리 제공

결론

써드파티 API는 현대 개발에서 중요한 도구이지만, 신중한 선택과 올바른 활용이 중요합니다.

보안, 성능, 비용 등 다양한 측면을 고려하여 프로젝트에 적합한 API를 선택하고, 모범 사례를 따라 구현한다면 개발 생산성을 크게 향상시킬 수 있습니다.