BitBard

[Database/TIL] Flyway 파일명 컨벤션 (템플릿화)

Dongni — Wed, 21 Jan 2026 01:00:25 +0900

오늘의 추천 곡

소스 코드와 마찬가지로 DB의 형상 관리도 중요한 화두다.

CI/CD를 준비하는 과정에서 DB로 인해 EC2가 뻗지 않게끔 하기 위한 방법을 공부해보다가 알게된 기술인 Flyway에 대해서 설명해보고자 한다.

아니 사실은 Flyway에 대한 설명이라기 보다는 일종의 세팅 방법을 공유해보고자 한다.

Flyway를 사용할 때 생길 수 있는 문제

보통 처음 Flyway를 쓰면 순차적인 숫자를 사용한다.

V1__init.sql
V2__add_user.sql

혼자 개발할 땐 문제가 없지만, 여러 팀원들이 각자의 기능을 개발한다면?

팀원 A: "회원 기능 때문에 V3__add_member.sql 만들어서 푸시했어요!"
팀원 B: "어? 저도 게시판 때문에 V3__add_post.sql 만들었는데요?"

= Git 충돌(Conflict) 발생

이러한 상황을 방지하고자 간단한 타임스탬프 전략을 이용해볼 수 있겠다.

타임스탬프(Timestamp) 전략

Flyway는 버전명(파일명)을 문자열 기준으로 정렬해서 실행한다.

따라서 시간이 흐르는 순서(오름차순)대로 파일명을 지으면 충돌 없이 자연스럽게 순서를 보장받을 수 있는 것.

따라서 기존의 'Vx' 와 같은 네이밍 대신 아래의 네이밍 컨벤션을 따르면 된다.

포맷: V{년월일시분초}__{설명}.sql
예시: V20260121143000__create_member_table.sql
주의사항: V 뒤에 숫자, 그리고 언더바 2개(__)는 필수

인텔리제이로 템플릿화 시키기

사실상 이 기술을 도입했을 때 생길 수 있는 에러는 99% 휴먼 에러일 것이다.

기존 DB 스키마에서 변경이 생겼음에도 sql 파일을 만들지 않거나, 만들었는데 sql 파일에 오타가 있다거나, 파일 네이밍을 할 때 오타를 낸다거나..

이런 에러를 방지하기 위해서는 템플릿이 있으면 좋지 않을까?

개발 초기에 어떤 환경들을 얼만큼 세팅하면 좋을지 계속 고민하고 있는데, 이런 사소한 것들도 신경써서 챙겨주면 팀원들의 개발 효율이 대략 1.00000123배는 증가하지 않을까?

1. 설정 메뉴 진입

Windows: File → Settings (Ctrl+Alt+S)
Mac: IntelliJ IDEA → Settings (Cmd+,)
이동: Editor → File and Code Templates
변경: 상단 Scheme를 Default → Project

2. 템플릿 추가

Files 탭에서 + 버튼 클릭
Name: 원하는 이름
Extension: sql
내용(File name): 아래 코드 붙여넣기 (본문에 넣는 거 아님)

V${YEAR}${MONTH}${DAY}${HOUR}${MINUTE}${SECOND}__${DESCRIPTION}

이후에는 프로젝트 트리 중 .idea 안을 확인해보면, 방금 만든 컨벤션이 생겨난 것을 알 수 있음.

사실 .ft로 파일이 생성되어야 하는데 아무리 해도 .sql로만 생기길래 .ft로 refactor 함

또한 대부분의 프로젝트에서 .idea는 .gitignore에 지정되어 있을테니까 Git이 추적할 수 있게 따로 빼줘야한다.

.gitignore에 해당 줄을 추가해주면 끝!

!.idea/fileTemplates/

3. 사용 방법

db/migration 폴더 우클릭 → New → Flyway Migration 클릭
나오는 창에 설명(Description)만 입력 (예: add_profile_image)

템플릿 파일 테스트

DESCRIPTION 작성만 하면 됨

대박슨

이제 resources/db/migration 하위에 sql 파일을 생성할 때마다 해당 템플릿을 사용해서 행복 개발을 할 수 있게 됐다.

만약 New를 눌러서 확인해봤는데 템플릿이 없다면

체크 박스 체크하지 말고 그냥 Invalidate and Restart를 눌러주면 될 것임

그리고 템플릿을 만드는 사람의 입장에서, .ft가 아니라 .sql로만 생성된다면, 아까 sql 을 입력했던 곳에 sql.ft 로 넣어주면 해결

여러분 저 됐어요!

됐어요!

ㅎ

[Spring/TIL] 전역 예외 처리(@RestControllerAdvice) vs try-catch, 개념 확실히 잡기

Dongni — Sun, 18 Jan 2026 01:48:17 +0900

오늘의 추천 곡

백엔드 개발을 하다보면 느끼는 게 있는데, 항상 최적화라던가 중복을 피한다거나 효율적인 로직을 짜는 게 중요하다고 생각은 한다.

물론 모든 걸 완벽하게 지키기란 쉽지 않지만 하나씩 하나씩 알아가고 배워가는 과정에서 성장하고 있음을 느끼는 것 같다.

아무튼 오늘은 예외처리에 관한 이야기를 해보고자 한다.

처음에는 컨트롤러단에서 try-catch로 처리하는 게 당연한 줄 알았다.

그도 그럴게 대학교 4년간 많은 서적과 각종 AI가 그렇게 써왔기 때문에 그게 당연한 건줄 알았는데 ResponseEntity에 대해서 찾아보다가 스프링의 @RestControllerAdvice에 대해서 알게되었고, 전공자이지만 이런 걸 몰랐다는 나를 자책하면서 글을 작성한다.....

@PostMapping("/login")
public ResponseEntity<?> login(@RequestBody LoginRequest request) {
    try {
        authService.login(request);
        return ResponseEntity.ok(ApiResponse.success());
    } catch (PasswordMismatchException e) {
        return ResponseEntity.ok(ApiResponse.fail("PASSWORD_MISMATCH"));
    }
}

일단 위 코드는 문제 없이 잘 동작은 한다.

예외도 잘 잡히고 응답도 원하는 대로 내려온다.

내용을 살펴보면, PasswordMismatchException이 발생했을 때 catch 블록에서 잡아서 실패 응답을 보내주고 있다.

하지만 이 하나의 메서드만 볼 게 아니고 컨트롤러 전체에 이런 try-catch 구문이 반복된다면?..

일단 가독성도 박살날 것이고 예외를 처리하는 것도 계속 반복될 것이다.

즉, 컨트롤러와 메서드가 하나둘 늘어나면서 비즈니스 로직보다 예외 처리 코드가 더 길어지고, 똑같은 catch 블록이 여기저기 중복되는 현상이 발생한 것.

@RestControllerAdvice

Spring에는 컨트롤러 전역에서 발생하는 예외를 한 곳에서 처리하는 방식이 있다.

그것이 바로 @RestControllerAdvice 이다.

@RestControllerAdvice
public class GlobalExceptionHandler {
}

애노테이션을 통해서 쉽게 선언할 수 있는데, 처음 딱 코드를 봤을 때는 얘를 어디서 주입하고 어디서 사용해야하지?

MVC 패턴에서 컨트롤러 전과 후로 어디에 위치해야할지 감이 안잡혔었다.

약간 서비스, 컨트롤러와 같은 명시적으로 부르는 명칭이 없었기 때문이다.

근데 사실 킹갓 스프링답게 그냥 정의만 해두면 스프링 컨테이너가 알아서 예외를 가로채서 처리해준다.

우선 예외를 처리할 핸들러를 정의해보면 다음과 같다.

@ExceptionHandler(PasswordMismatchException.class)
public ResponseEntity<?> handlePasswordMismatch(PasswordMismatchException e) {
    return ResponseEntity.ok(ApiResponse.fail("PASSWORD_MISMATCH", "비밀번호 불일치"));
}

이렇게만 정의해두면, 서비스나 컨트롤러 어디서든 PasswordMismatchException이 터졌을 때 Spring이 이 메서드를 찾아서 실행한다.

주입도, 호출도, 설정도 필요 없다. 그냥 예외 타입 기준으로 매칭된다.

그럼 try-catch는 이제 안 쓰는 건가?

사실 이 부분에서 꽤나 헷갈리는 내용이 많았다.

언제 어떻게 사용해야 하는건지에 대한 기준이 확립되지 않아서 더욱 그렇게 느낀 게 아닐까?

결국에는 "역할이 다르다"는 걸 명심해야 한다.

try-catch를 써야 하는 경우 (흐름 제어)

예외가 발생해도 복구가 가능하거나, 다음 로직을 이어가야 할 때 사용한다.
이건 예외 처리라기보단 프로그램의 흐름 제어(Flow Control)에 가깝다.

외부 API 호출 실패 시 재시도(`retry`)
특정 파일이 없으면 기본 파일 생성
현재 시점의 날씨 데이터를 못가져와서 1시간 전 데이터랃 보여주기

이처럼 에러가 났지만 내가 흐름을 제어할 수 있어서 정상적으로 흘러가게 만들 수 있다면 try-catch문을 사용하면 된다.

전역 예외 처리를 써야 하는 경우

비즈니스 규칙을 위반해서 더 이상 처리할 게 없을 때, 즉 사용자에게 명시적으로 에러를 알리려고 할 때 사용하면 된다.

if (!passwordMatches) {
    throw new PasswordMismatchException();
}

이런 경우엔 컨트롤러에서 잡지 말고 그냥 던져버리면 전역 핸들러가 낚아채서 에러 응답을 만들어서 전달해준다.

이때 에러 응답을 만들 때는

공통 APIResponse를 만들어서 사용하면 된다!

아래는 이번 프로젝트에서 사용해보고자 하는 응답 형식이다.

{
  "api_version": "v1",
  "status": "success | fail | error",
  "response_code": 200,
  "error_code": "ERROR_CODE",  // fail 또는 error일 때만 포함
  "message": "응답 메시지",
  "count": 1, // data 개수 (배열은 배열의 길이를, 객체면 1, null이면 0
  "data": [] // 실제 응답 데이터 (리스트의 경우 대괄호로 묶고 그렇지 않으면 중괄호로 단일 객체 전달)
}

~~사실 이건 사족임~~

코드 전문 - GlobalExceptionHandler.java

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(PasswordMismatchException.class)
    public ResponseEntity<?> handlePasswordMismatch(PasswordMismatchException e) {
        // 로깅 등 추가 작업 가능
        return ResponseEntity.ok(ApiResponse.fail("PASSWORD_MISMATCH", e.getMessage()));
    }
    
    // 다른 예외들도 여기서 추가로 정의 가능
}

Service: 로직 수행 중 문제가 생기면 예외를 던짐(Throw)
Controller: 정상적인 흐름만 처리. (try-catch 최소화)
GlobalExceptionHandler: 던져진 예외를 잡아서 적절한 응답(Response)으로 변환.

처음에는 try-catch를 안 쓰는 게 뭔가 불안하고 이상하게 느껴졌는데, 역할을 명확히 나눠놓고 보니 오히려 코드가 훨씬 깔끔해졌다.

단, 모든 기술에는 트레이드 오프가 있는 법. 무엇이든 과한 건 좋지 않다...

무조건적으로 전역 처리를 맹신하면 안 되고, 복구 가능한 건 잡고(catch), 의미 있는 실패는 던져서(throw) 전역에서 처리하자는 기준을 잡는 게 핵심인 것 같다.

복습을 철저히..

지피티가 알려준 내용

네가 알고 있던 세계 (전통적인 try-catch)

@PostMapping("/login")
public ResponseEntity<?> login() {
    try {
        service.login();
        return ResponseEntity.ok("성공");
    } catch (PasswordMismatchException e) {
        return ResponseEntity.badRequest().body("비밀번호 틀림");
    } catch (Exception e) {
        return ResponseEntity.status(500).body("서버 오류");
    }
}

이 구조에서:

❌ 문제점
- 컨트롤러마다 try-catch 복붙
- 비즈니스 로직 + 예외 처리 섞임
- 컨트롤러가 점점 더러워짐

스프링 방식 (네가 지금 배우는 거)

@PostMapping("/login")
public ResponseEntity<?> login() {
    service.login(); // 여기서 예외 터지면?
    return ResponseEntity.ok(ApiResponse.success());
}

❓ 여기서 예외 터지면 어디서 잡음?

스프링 컨테이너가 잡음

흐름을 정확히 그리면 이거임

Controller
	↓
Service
	↓
예외 발생  
	↓
DispatcherServlet (스프링 핵심)
	↓
@RestControllerAdvice 탐색
	↓
@ExceptionHandler 매칭
	↓
ResponseEntity 반환

즉,

try는 네가 썼고,
catch는 스프링이 대신 써준 셈

[Spring/TIL] @RequestParam, @ModelAttribute, @RequestBody 차이

Dongni — Sun, 11 Jan 2026 15:16:10 +0900

사실 이 내용을 어렴풋이 알고는 있었지만, 남들에게 술술 설명할 수 있는 정도로 잘 아냐고 물어봤을 땐 그닥... 이라고 할 게 분명해서 글로 한 번 정리해보고자 했다.

Spring MVC에서 요청을 받을 때 사용하는 어노테이션은 여러 개가 있지만, 이 차이를 이해하는 데 필요한 개념은 되게 단순하다.

서버는 요청을 받으면 먼저 ‘종이 한 장’을 만든다

이 종이 한 장으로 @RequestParam, @ModelAttribute, @RequestBody를 한 번 설명해보겠다.

미리보기

흐름 설명

클라이언트가 요청을 보낸다.

쿼리 파라미터 방식

GET /login?email=a@test.com&password=1234

Form Data 방식

POST /login
Content-Type: application/x-www-form-urlencoded

email=a@test.com&password=1234

요청 방식이 뭐든, 서버는 먼저 다음과 같이 행동한다.

“요청에 값들이 있네. 일단 적어두자.”

그래서 서버는 내부적으로 종이 한 장을 만든다.

email = "a@test.com"
password = "1234"

이 종이는 데이터가 URL에서 왔는지, Body에서 왔는지 관심 없다.

값만 적혀 있으면 된다.

이게 흔히 말하는 파라미터 맵이다.

파라미터 맵(Parameter Map)이란?

파라미터 맵은 요청으로 들어온 값들을 서버가 한 번에 정리해 둔 일종의 표다.

URL 쿼리스트링이든, 폼 데이터든 서버는 먼저 해당 값들을 key-value 형태로 모아둔다.

username = kim
age = 20

이런 식으로 해당 요청에는 이런 값들이 있다라고 한 장의 메모처럼 정리해 둔 것이 바로 파라미터 맵이다.

왜 굳이 파라미터 맵이 필요할까?

컨트롤러단에서는 URL 형식이 뭔지, 폼으로 왔는지 관심이 없다.

컨트롤러에 도착하기 전에 서버가 미리 해당 요청에서 쓸 수 있는 값 목록을 정리해서 결과만 넘겨주기 때문이다.

그 덕분에 @RequestParam, @ModelAttribute 같은 어노테이션은 이 파라미터 맵에서 필요한 값만 꺼내 쓰는 역할만 한다.

자, 다시 그러면 들어온 요청이 뭐든 종이 한 장을 만들어냈고, 다음 단계는 해당 종이를 어떻게 할 지를 결정하는 것.

@RequestParam — 종이에서 한 줄만 떼어낸다

@RequestParam String email

종이에서 email 부분만 찢어서 주는 느낌.

객체를 생성하지 않음
값 하나만 필요할 때 사용

@ModelAttribute — 종이 전체로 객체를 만든다

@ModelAttribute LoginReq req

종이에 적힌 내용으로 객체를 만들어서 주는 느낌

이 종이 한 장(파라미터 맵)에는 요청 방식과 상관없이 이름과 값만 담겨 있다.

email = "a@test.com"
password = "1234"

Spring은 먼저 LoginReq의 빈 객체를 하나 만든다.

LoginReq req = new LoginReq();

그 다음, 파라미터 맵을 한 항목씩 보면서 이름이 같은 필드를 객체에서 찾는다.

email이라는 이름을 보면, setEmail(...)을 호출하고, password라는 이름을 보면, setPassword(...)를 호출한다.

이렇게 해서 종이에 적혀 있던 값들이 객체의 필드로 옮겨진다.

여기서 중요한 점

@ModelAttribute는 Form Data 자체를 읽는 게 아니다

읽는 건 오직 종이다.

GET /login?email=...&password=...

@GetMapping("/login")
public void login(@ModelAttribute LoginReq req)

일반적으로 Form Data를 읽는다고 하면 당연히 POST만 가능하겠구나 생각할 것인데, GET 요청도 가능하다.

GET인지 POST인지는 상관없이 이미 파라미터 맵으로 만들어진 것을 읽기 때문이다.

어쨌든 핵심은 GET이든 POST든 상관없다는 것.

종이가 만들어지기만 하면 된다.

그런데 JSON은?

POST /login
Content-Type: application/json

{
  "email": "a@test.com",
  "password": "1234"
}

파라미터 맵은 key=value&key=value 쌍으로 이루어져 있을 때만 생성이 가능한데, JSON 규약과는 다르기 때문에 종이가 만들어지지 않는다.

@ModelAttribute LoginReq req

따라서 위와 같은 방식은 당연히 불가능.

결국, 앞선 종이 한 장을 만들지 않고 요청 본문을 그대로 읽어서 객체로 만드는 것이다.

@ModelAttribute 바인딩은 어떻게 이루어질까

앞에서 말했듯이, @ModelAttribute는 파라미터 맵(종이)을 보고 객체를 만든다.
조금 더 정확히 말하면, 필드 단위로 값을 바인딩한다.

이 과정은 대략 다음 순서로 이루어진다.

Spring은 먼저 대상 타입(LoginReq)의 빈 객체를 하나 생성한다.

LoginReq req = new LoginReq();

단, 여기에서 사용되는 객체는 기본 생성자가 존재해야만 한다.

그 다음, 파라미터 맵을 하나씩 순회하면서 각 항목을 확인한다.

email = "a@test.com"
password = "1234"

Spring은 각 key 이름을 기준으로 객체 내부를 탐색한다.

email이라는 이름의 필드가 있는지
또는 setEmail(...) 형태의 setter가 있는지

찾아낸 뒤, setter를 호출하는 방식으로 값을 주입한다.

req.setEmail("a@test.com");
req.setPassword("1234");

즉, @ModelAttribute의 바인딩은 객체 전체를 한 번에 매핑하는 것이 아니라 필드 단위로, setter 기반으로 이루어진다.

이 때문에 일반적으로 @ModelAttribute를 사용하는 DTO는 자바 빈 규칙(기본 생성자 + setter)을 따르는 형태가 된다.

타입 변환은 어디서 일어날까

파라미터 맵에 들어 있는 값은 모두 문자열이다.

age = "20"

하지만 DTO의 필드는 문자열이 아닐 수 있다.

private int age;

이때 "20"을 20으로 변환하는 작업은 WebDataBinder가 담당한다.

즉, @ModelAttribute 바인딩 과정에는

문자열 → 숫자
문자열 → enum
문자열 → 날짜

와 같은 타입 변환 로직이 함께 포함되어 있다.

그래서 별도의 변환 코드를 작성하지 않아도 자연스럽게 DTO가 채워지는 것이다.

@ModelAttribute vs @RequestBody 결정적인 차이

여기서 중요한 차이가 하나 생긴다.

@ModelAttribute는

파라미터 맵을 기반으로
필드 이름을 기준으로
setter를 호출해 값을 채운다

반면 @RequestBody는 전혀 다른 방식으로 동작한다.

@RequestBody는 JSON 문자열 전체를 대상으로 역직렬화(deserialization) 를 수행한다.

이 과정에서는

기본 생성자 + setter 방식이 아니라
필드 접근 또는 생성자 기반 매핑
Reflection을 이용한 객체 구성

이 사용된다. 즉,

@ModelAttribute
파라미터 맵 기반, 필드 단위 바인딩
@RequestBody
JSON 원문 기반, 객체 전체 역직렬화

그럼 이 일은 누가 다 하는 걸까?

여기서 조금만 더 깊게 들어가 보자. 우리가 편하게 어노테이션만 붙이면 되는 이유는 Spring 내부에서 누군가 열심히 교통정리를 하고 있기 때문이다.

HandlerMethodArgumentResolver

컨트롤러 메서드의 파라미터를 보고 "누가 이 일을 처리할지" 결정하는 관리자다.

@RequestParam이나 @ModelAttribute가 붙어 있다?
- 종이(파라미터 맵)를 보고 처리
@RequestBody가 붙어 있다?
- 이건 종이 말고, Body 내용 바로 읽어서 처리

@ModelAttribute가 선택되었을 때 - WebDataBinder

ArgumentResolver가 "객체로 만들어야 돼"라고 하면 WebDataBinder가 등장한다.
이 친구가 **파라미터 맵(종이)**을 보고 객체의 Setter를 호출해서 값을 채워 넣는다.
타입 변환(문자열 "10" → 숫자 10)이나 검증(Validation)도 얘가 담당한다.

@RequestBody가 선택되었을 때 - HttpMessageConverter (Jackson)

종이가 없으므로, Body에 있는 JSON 데이터를 직접 읽어야 한다.
이때 우리가 흔히 쓰는 Jackson 같은 라이브러리가 동작해서 JSON 문자열을 자바 객체로 변환(Parsing)해준다.
반대로 @ResponseBody를 써서 리턴할 때도 이 친구가 자바 객체를 JSON으로 바꿔서 내보낸다.

최종 정리

@RequestParam
- 종이(파라미터 맵)에서 한 줄만 쏙 뺀다.
@ModelAttribute
- WebDataBinder가 종이 전체 내용을 보고 Setter로 객체를 채운다.
@RequestBody
- 종이가 없다. **HttpMessageConverter(Jackson)**가 JSON을 통째로 읽어서 객체로 바꾼다.

결국 파라미터 맵(종이)을 거치느냐, 아니냐와 그걸 누가 처리해주느냐(Binder vs Converter)의 차이만 알고 있으면 될 것 같다.

[JAVA-TIL] JWT, JJWT 구현

Dongni — Thu, 30 Oct 2025 21:08:20 +0900

JWT, JJWT란?

JWT는 Json Web Token의 약자로, Json 형식의 데이터로 이루어진 인증 티켓 같은 거라고 생각해볼 수 있다.

위 사진과 같이 JWT는 Header, Payload, Signature로 이루어져 있다.

각 부분에는 위 사진과 같은 내용(키-값 쌍)들이 포함되어있다.

[Header]

alg	서명(Signature)에 사용할 암호화 알고리즘 (예: HS256, RS256 등)
typ	토큰의 타입 (대부분 "JWT")

이 객체는 Base64URL 방식으로 인코딩되어 JWT의 첫 번째 부분을 이룬다.

[Payload]

sub	토큰의 주제(Subject, 주로 사용자 ID)
name	사용자 이름
role	권한(Role)
iat	토큰 발급 시각 (issued at)
exp	토큰 만료 시각 (expiration)

[Signature]

secret	서버가 가진 비밀 키 (절대 노출되면 안 됨)
HMACSHA256	해싱 알고리즘

결과적으로 Signature는 “Header + Payload” 조합이 변조되지 않았다는 것을 증명해준다.

전체 구조

[Header]
{
  "sub": "1234567890",
  "name": "유동훈",
  "role": "user",
  "iat": 1698652000,
  "exp": 1698655600
}

[Payload]
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IuyKteyViO2VnCIsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNjk4NjUyMDAwLCJleHAiOjE2OTg2NTU2MDB9

[Signature]
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

실제 JWT 모습

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IuyKteyViO2VnCIsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNjk4NjUyMDAwLCJleHAiOjE2OTg2NTU2MDB9.
TJVA95OrM7E2cBab30RMHrHDcEfxJoZQnQvV3u8bU8U

JWT 적용 예시 with Servlet

컨트롤러 일부 발췌

@WebServlet("/user")
public class UserController extends HttpServlet implements ControllerHelper {
	private static final long serialVersionUID = 1L;
	
	private UserService userService;
	private RefreshTokenService refreshService;
	private JwtUtil jwt;
	
	@Override
    public void init() throws ServletException {
        // 1) Service 주입 (리스너가 context에 넣어줬다면 거기서 꺼내기)
        this.userService = (UserService) getServletContext().getAttribute("userService");
        this.refreshService = (RefreshTokenService) getServletContext().getAttribute("refreshTokenService");

        // 2) 시크릿 로딩: 환경변수 -> 없으면 web.xml context-param -> 그래도 없으면 예외
        String b64 = System.getenv("JWT_SECRET_BASE64");
        if (b64 == null) {
            b64 = getServletContext().getInitParameter("JWT_SECRET_BASE64");
        }
        if (b64 == null) {
            throw new ServletException("JWT_SECRET_BASE64 is missing. Set env or context-param.");
        }												
        byte[] secretBytes;
        try {
            secretBytes = java.util.Base64.getDecoder().decode(b64);
        } catch (IllegalArgumentException e) {
            throw new ServletException("JWT_SECRET_BASE64 is not valid Base64.", e);
        }
        this.jwt = new JwtUtil(secretBytes);
    }

코드 속 2번 항목처럼 환경 변수에서 시크릿 키를 받아오는 걸 확인할 수 있다.

이후에는 JwtUtil 클래스를 만들어서 JWT의 내부적인 동작을 정의해주면 된다.

import io.jsonwebtoken.*;
import io.jsonwebtoken.security.Keys;

import java.security.Key;
import java.time.Instant;
import java.util.Date;

public class JwtUtil {
    private final Key key;

    public JwtUtil(byte[] secretBytes) {
        this.key = Keys.hmacShaKeyFor(secretBytes);
    }

    // 토큰 발급
    public String create(long userIdx, long ttlSeconds) {
        Instant now = Instant.now();
        return Jwts.builder()
                .setHeaderParam("typ", "JWT")
                .claim("userIdx", userIdx)
                .setIssuedAt(Date.from(now))
                .setExpiration(Date.from(now.plusSeconds(ttlSeconds)))
                .signWith(key, SignatureAlgorithm.HS256)
                .compact();
    }

    // 검증 + 클레임 추출
    public Jws<Claims> parse(String token) {
        return Jwts.parserBuilder()
                .setSigningKey(key)
                .setAllowedClockSkewSeconds(0)
                .build()
                .parseClaimsJws(token);
    }

    public long getUserIdx(String token) {
        return parse(token).getBody().get("userIdx", Number.class).longValue();
    }
    
    public long verifyAndGetUserId(String token) {
        return getUserIdx(token);
    }

}

이후에는 JWT가 발급되는 순간들을 만들어줘야 한다.

통상적으로는 로그인이 성공하면 해당 유저에게 토큰을 발급하게 되는데 로그인 상황을 한 번 정의해보자.

private void signin(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
    String email = request.getParameter("email");
    String password = request.getParameter("password");
    // TODO: password 암호화

    UserDto loginUser = userService.signin(email, password);
		
    if (loginUser == null) {
        redirect(request, response, "/user?action=signin-form");
        return;
    }

    // 1) 토큰 발급
    String accessToken  = jwt.create(loginUser.getId(), 60 * 60 * 6);
    String refreshToken = jwt.create(loginUser.getId(), 60 * 60 * 24);

    // 2) 검증용 토큰 저장
    refreshService.save(loginUser.getId(), refreshToken, 60 * 60 * 24);

    // 3) 두 토큰을 HttpOnly 쿠키로 심기
    addHttpOnlyCookie(response, "accessToken",  accessToken,  60 * 60 * 24);
    addHttpOnlyCookie(response, "refreshToken", refreshToken, 60 * 60 * 24 * 7);

    redirect(request, response, "/");
}

JwtUtil을 이용해서 로그인에 성공하면 토큰을 jwt.create 해주고 재발급용 토큰인 refreshToken을 DB에 저장해주면 된다.

또한 사용자에게 직접 토큰을 전송하기 위헤서 쿠키를 활용하면 된다.

여기서 일반적으로 쿠키의 유효 기간은 JWT의 유효 기간보다 길게 설정해주어야 한다.

쿠키 유효 기간 vs JWT 유효 기간

JWT는 서버가 유효성을 검증하는 토큰이고, 쿠키는 클라이언트가 그 토큰을 서버로 전달하는 수단이기 때문이다.

만약 쿠키가 먼저 만료되어버리면, 아직 유효한 JWT가 남아 있더라도 클라이언트가 서버에 전달할 수 없게 된다. 즉, 서버는 토큰의 만료 여부조차 확인할 수 없게 된다.

따라서 쿠키의 유효 기간은 JWT보다 길게 설정해야, 서버가 JWT 만료 여부를 정상적으로 판단할 수 있다.

Access Token vs Refresh Token

앞서 말했듯, JWT는 두가지 종류가 존재한다.

Access Token
Refresh Token

이 둘은 각각 상호보완적으로 불 수 있다.

일반적으로 사용자는 로그인에 성공하면 서버로부터 Access Token과 Refresh Token, 두 가지를 함께 발급받는다.

Access Token은 실제로 요청 시 인증을 수행하는 토큰으로, 유효 기간이 짧게 설정되어 있다. (예: 30분 ~ 1시간)
Refresh Token은 Access Token이 만료되었을 때, 새로운 Access Token을 재발급받기 위한 용도로 사용된다. 보통 유효 기간이 훨씬 길다. (예: 2주 ~ 1달)

사진에서 볼 수 있듯, 서버는 로그인 시 AT와 RT를 함께 발급하고 이 토큰들을 클라이언트(브라우저)에 쿠키 형태로 전달한다. 이후 클라이언트는 요청을 보낼 때마다 Access Token이 담긴 쿠키를 서버로 함께 전송한다. 문제는 Access Token이 만료되었을 때다. 이 경우 서버는 클라이언트의 요청을 처리하지 않고 401 Unauthorized 상태 코드(만료 응답이자 재발급 신호)를 보낸다.

이 시점에서 클라이언트는 자신이 가지고 있던 Refresh Token을 서버로 다시 보내 새로운 Access Token을 발급받는다.

만약 Refresh Token까지 만료되었거나 위·변조되었다면, 이제는 더 이상 재발급이 불가능하므로 다시 로그인을 해야 한다.

Signature 알고리즘 작동 방식

대칭키 방식 (HS256)

서버 혼자 비밀키(secret key)를 가지고 서명과 검증을 모두 수행하는 구조

비밀키 생성
- 서버는 JWT에 서명할 때 사용할 비밀키(secret key) 를 생성한다.
- 이 키는 오직 서버 내부에만 존재하며 외부로 노출되지 않는다.
클라이언트 로그인 요청
- 클라이언트가 서버로 로그인 정보를 전송한다.
로그인 성공 → JWT 발급
- 서버는 로그인 정보를 검증한 뒤,
- 사용자 정보를 포함한 JWT를 생성한다.
- 이때 비밀키로 서명(Signature)을 추가하여 토큰을 완성한다.
- JWT는 응답으로 클라이언트에 전달된다.
요청 시 JWT 포함
- 클라이언트는 이후 API 요청마다
- 이 JWT를 쿠키나 Authorization 헤더에 포함시켜 전송한다.
서버의 비밀키 검증
- 서버는 요청을 받으면 자신의 비밀키로 서명을 검증한다.
- 서명이 유효하다면 토큰이 위변조되지 않았음을 확인할 수 있다.
응답 반환
- 검증이 완료되면 서버는 정상적으로 요청을 처리하고 응답을 돌려준다.

비대칭키 방식 (RS256)

공개키와 개인키를 분리하여 사용하는 방식
(개인키로 서명하고, 공개키로 검증)

개인키 생성
- 서버는 서명용 개인키(private key) 를 생성한다.
공개키 생성
- 개인키로부터 검증용 공개키(public key) 를 만들어낸다.
- 이 공개키는 외부(다른 서버, 인증 서버, 클라이언트 등) 에 공유될 수 있다.
클라이언트 로그인 요청
- 클라이언트가 서버로 로그인 요청을 보낸다.
로그인 성공 → JWT 발급 및 전송
- 서버는 개인키로 JWT에 서명(Signature)을 추가하여 토큰을 완성하고, 그 JWT를 클라이언트에 전달한다.
요청 시 JWT 포함
- 클라이언트는 이후 요청마다 JWT를 포함시켜 서버로 보낸다.
공개키로 검증
- 서버(또는 인증 서버)는 JWT의 서명을 공개키로 검증한다.
- 공개키로 검증이 성공하면 토큰이 정상 발급된 것임을 확인할 수 있다.
응답 반환
- 검증이 끝나면 서버는 요청을 처리하고 정상 응답을 전송한다.

구분	HS256 (대칭키)	RS256 (비대칭키)
구분	HS256 (대칭키)	RS256 (비대칭키)	키 구조	하나의 비밀키로 서명+검증	개인키로 서명, 공개키로 검증
검증 주체	서버 자신만 가능	공개키를 가진 누구나 가능
보안 수준	비교적 단순, 빠름	더 안전하지만 복잡
활용 예시	단일 서버 환경	마이크로서비스 / OAuth / 외부 인증 연동

클라이언트 - 서버 간의 JWT 시퀀스 다이어그램

사실 이걸 시퀀스 다이어그램이라고 불러도 되는진 모르겠지만, 개념 상으로 시간의 흐름에 따른 요청, 응답의 흐름이 있기는 있으니까...

1~4. 로그인 및 토큰 발급

Client → Server : 로그인 요청
사용자가 아이디/비밀번호를 입력해 서버로 전송.

1. Server → DB : 사용자 조회

서버가 DB에서 해당 유저 정보를 조회.

2. DB → Server : 사용자 데이터 반환

유저가 존재하고 비밀번호가 일치하면 정보 반환.

3. Server → Client : JWT 발급 및 전달

서버는 로그인 성공 시,
- Access Token (단기 인증용)
- Refresh Token (재발급용)
- 두 가지 JWT를 생성해 클라이언트에 전달.

5~6. 요청 시 인증 처리

5. Client → Server : API 요청 (JWT 포함)

클라이언트는 이후 요청마다 JWT(Access Token)를 쿠키나 헤더에 실어 보냄.

6. Server : Access Token 검증

토큰이 유효하면 요청 정상 처리
만료되었다면, Refresh Token을 이용한 재발급 로직으로 분기

6-1~6-3. 재발급 및 재요청

6-1. Server → DB : Refresh Token 조회

DB에 저장된 Refresh Token을 조회해 유효한지 확인.

6-2. Server : 새로운 Access Token 생성

Refresh Token이 유효하면 새 Access Token을 생성.

6-3. Server → Client : 새로운 토큰 전달 후 응답

새 토큰을 클라이언트에 전송하고, 요청을 다시 처리하여 응답 반환.

[JAVA] 최단 거리 알고리즘 - 다익스트라 <Dijkstra>

Dongni — Tue, 23 Sep 2025 21:49:51 +0900

최단 거리 알고리즘 - 다익스트라 <Dijkstra>

다익스트라 알고리즘은 흔히 알고있듯, 최단 거리를 구하는 데 초점이 맞춰진 알고리즘이다.

우리가 아는 유명한 최단 거리 알고리즘이 무엇이 있을까?

아마 BFS가 떠오를 것인데, BFS와의 차이점은 거리(가중치)가 1이 아니라는 점이다.

즉, BFS는 현재 칸에서 다음 칸으로 이동하면 거리(가중치)가 1이 증가하는데 반해 다익스트라는 임의의 가중치가 존재한다.

학문적으로는 가중치가 있는 그래프에서 하나의 시작 정점으로부터 모든 정점들까지의 최단 거리를 구하는 알고리즘이라고 설명할 수 있겠다.

또 다른 이야기를 해보자면, 이전에 업로드했었던 Prim 알고리즘과도 다소 유사한 모습을 보인다.

프림 알고리즘와 다익스트라 알고리즘 모두 PriorityQueue를 사용하고 다소 그리디하게 동작하기 때문이다.

추가로 간선의 가중치가 음수일 때는 다익스트라 알고리즘을 사용하지 못한다. 음수 가중치가 개입되는 순간, 최단 거리라고 생각했던 것이 최단이 아닐 수 있듯, 논리적으로 심각한 문제가 발생하게 된다. 따라서 이러한 상황에서는 벨만-포드 알고리즘을 사용하면 되고, 간선의 양수 가중치만을 가지고 있을 때는 다익스트라 알고리즘으로 쉽게 해결할 수 있다.

다익스트라 알고리즘 동작 원리

1. 임의의 출발 노드를 선택해서 가중치 0으로 시작

2. 현재까지의 최단 거리가 확정되지 않은 노드 중, 가장 짧은 거리를 가진 노드를 선택.

3. 해당 노드와 연결된 인접 노드들의 거리를 확인하고 기존 거리보다 더 짧으면 갱신

4. 모든 노드가 확정될 때까지 2 ~ 3번의 과정을 반복.

핵심 자료 구조

거리 배열 (int dist[]): 시작점에서 각 정점까지의 최소 비용 저장 (dp를 이용해서 갱신함)
방문 배열 (boolean visited[]): 최단 거리가 확정된 노드 체크
우선순위 큐 (PriorityQueue pq): 항상 현재 가장 짧은 거리의 노드를 보장하기 위해서 사용

다른 알고리즘과의 차이점 by GPT

다익스트라	최단 거리 (단일 시작점 → 모든 정점)	가중치 ≥ 0	가장 가까운 정점부터 거리 갱신 (Greedy)	O(E log V)	네비게이션, 네트워크 경로
크루스칼	최소 신장 트리 (MST)	무방향, 가중치 있음	간선을 가중치 순 정렬 + 사이클 방지	O(E log E)	도로 건설, 통신망 비용 최소화
프림	최소 신장 트리 (MST)	무방향, 가중치 있음	정점에서 시작해 최소 간선 확장	O(E log V)	전력망 연결, 네트워크 구축
BFS	그래프 탐색, 최단 거리 (무가중치)	무가중치 그래프	레벨별 탐색 (큐)	O(V + E)	미로 탐색, 소셜 네트워크 탐색

사실 문제를 많이 풀어보진 않았지만, 다소 헷갈리는 내용이 많았다.

느끼기에는 프림 알고리즘과 다익스트라가 매우 유사하게 느껴졌고 크루스칼과도 헷갈리기도 했다.

언제 어떻게 사용해야 하는건지에 대한 기준이 확립되지 않아서 더욱 그렇게 느낀 게 아닐까?

결국 크루스칼/프림 알고리즘은 최소 스패닝 트리를 구성하는 데에 목적이 맞춰져 있다는 걸 명심해야 한다.

모든 정점을 연결하면서 가중치들의 합이 최소가 되게끔 구성하는 것.

그에 반면 다익스트라 알고리즘은 서두에서 이야기 했듯이 최단 거리를 구하는 데 초점이 맞춰져 있다.

시작 정점에서 다른 모든 정점으로의 최단 거리가 저장되어 있다는 것이다!!

헷갈릴 게 하나도 없는데 왜 처음 접했을 때부터 비교적 최근까지 왜 그렇게 헷갈렸는지 알 수가 없다.

이래서 텀을 두고 공부를 해야하나 보다. 복습을 철저히..

코드 전문

BOJ 1916 - 최소비용 구하기

package test;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.PriorityQueue;
import java.util.StringTokenizer;

public class BOJ_1916 {
	
	public static class Vertex implements Comparable<Vertex>{
		int idx;
		int weight;
		
		public Vertex(int idx, int weight) {
			this.idx = idx;
			this.weight = weight;
		}

		@Override
		public int compareTo(Vertex o) {
			return Integer.compare(this.weight, o.weight);
		}
	}

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st;
        
        int N = Integer.parseInt(br.readLine());
        int M = Integer.parseInt(br.readLine());
        
        ArrayList<Vertex>[] graph = new ArrayList[N + 1];
        for (int i = 1; i <= N; i++) graph[i] = new ArrayList<>();
        
        for (int i = 0; i < M; i++) {
        	st = new StringTokenizer(br.readLine());
        	
        	int start = Integer.parseInt(st.nextToken());
        	int end = Integer.parseInt(st.nextToken());
        	int weight = Integer.parseInt(st.nextToken());
        	
        	graph[start].add(new Vertex(end, weight));
        }

    	st = new StringTokenizer(br.readLine());
    	
    	int start = Integer.parseInt(st.nextToken());
    	int end = Integer.parseInt(st.nextToken());
    	
    	int[] dist = new int[N + 1];
    	Arrays.fill(dist, Integer.MAX_VALUE - 100_000);
    	
    	PriorityQueue<Vertex> pq = new PriorityQueue<>();
    	boolean[] visited = new boolean[N + 1];
    	
    	pq.add(new Vertex(start, 0));
    	dist[start] = 0;
    	
    	while (!pq.isEmpty()) {
    		Vertex cur = pq.poll();
    		
    		if (visited[cur.idx]) continue;
    		visited[cur.idx] = true;
    		
    		for (Vertex next : graph[cur.idx]) {
    			if (dist[next.idx] > dist[cur.idx] + next.weight) {
    				dist[next.idx] = dist[cur.idx] + next.weight;
    				pq.add(new Vertex(next.idx, dist[next.idx]));
    			}
    		}
    	}
    	
    	System.out.println(dist[end]);
    	
    }
}

코드 해설

다익스트라 문제들 중에서 비교적 간단한 문제이고 개념을 익히기 좋은 문제인 것 같다.

	public static class Vertex implements Comparable<Vertex>{
		int idx;
		int weight;
		
		public Vertex(int idx, int weight) {
			this.idx = idx;
			this.weight = weight;
		}

		@Override
		public int compareTo(Vertex o) {
			return Integer.compare(this.weight, o.weight);
		}
	}

우선, 정점 클래스를 정의해주었다.
- 해당 정점 클래스의 필드로는 idx(정점의 번호), weight(현재 노드에 이르기까지 계산된 가중치의 합)
- PriorityQueue를 위해 구현해준 compareTo 메서드
추가로, 왜 여기선 시작 정점과 도착 정점을 담지 않고 정점의 idx를 필드로 가지고 있을까?
- 다익스트라 알고리즘의 동작 과정이 특정 정점을 기준으로 점점 확장해나가는 형태이기 때문.
- 시작 정점에서 그 다음 정점.. 그 다음 정점.. 쭉 확장되면서 나아감.
- 크루스칼 알고리즘의 경우에는 간선에 포커스를 맞춘 알고리즘이기에 시작 정점과 도착 정점이 필요하기 때문에 Edge 클래스를 정의해주었음.
- 프림 알고리즘의 경우에는 임의의 정점에서 이웃된 정점들 중 가장 가중치가 작은 정점들을 선택해나가기 때문에 다익스트라와 마찬가지로 현재 정점의 정보만을 가진 Vertex 또는 Node 클래스를 정의해준 것.
  - 프림 알고리즘 게시글을 보면 정점의 정보를 to로 정의해주었는데, 사실상 현재 정점의 idx과 다른 의미로 사용한거지만 로직 상으로는 동일한 의미를 가짐.
  - 또 엄밀히 따지자면 다익스트라 알고리즘에서도 두가지 의미로 사용됨.
  - 문맥 1 (그래프 저장: graph[u].add(new Vertex(v, w)))
    - - idx = 도착 정점 v
      - weight = 그 간선의 가중치 w (edge weight)
    - 문맥 2 (우선순위큐에 넣을 때: pq.add(new Vertex(v, dist[v])))
      - idx = 해당 정점 v
      - weight = 그 정점까지의 누적 최단거리(현재 후보값) dist[v] (tentative distance)
    - 즉 같은 Vertex 타입을 사용하지만 weight의 의미가 컨텍스트에 따라 달라짐 (edge weight vs. accumulated distance).

        int N = Integer.parseInt(br.readLine());
        int M = Integer.parseInt(br.readLine());
        
        ArrayList<Vertex>[] graph = new ArrayList[N + 1];
        for (int i = 1; i <= N; i++) graph[i] = new ArrayList<>();
        
        for (int i = 0; i < M; i++) {
        	st = new StringTokenizer(br.readLine());
        	
        	int start = Integer.parseInt(st.nextToken());
        	int end = Integer.parseInt(st.nextToken());
        	int weight = Integer.parseInt(st.nextToken());
        	
        	graph[start].add(new Vertex(end, weight));
        }

우선 인접 리스트 또는 인접 행렬을 선언해주고 각자의 방식에 맞게 초기화 작업을 진행해준다.
이어서 M번동안 그래프의 연결 정보를 갱신해준다.
이 문제에서는 무방향 그래프가 아니기 때문에 graph[start]에만 .add 해준 것.

	int start = Integer.parseInt(st.nextToken());
    	int end = Integer.parseInt(st.nextToken());
    	
    	int[] dist = new int[N + 1];
    	Arrays.fill(dist, Integer.MAX_VALUE - 100_000);
    	
    	PriorityQueue<Vertex> pq = new PriorityQueue<>();
    	boolean[] visited = new boolean[N + 1];
    	
    	pq.add(new Vertex(start, 0));
    	dist[start] = 0;
    	
    	while (!pq.isEmpty()) {
    		Vertex cur = pq.poll();
    		
    		if (visited[cur.idx]) continue;
    		visited[cur.idx] = true;
    		
    		for (Vertex next : graph[cur.idx]) {
    			if (dist[next.idx] > dist[cur.idx] + next.weight) {
    				dist[next.idx] = dist[cur.idx] + next.weight;
    				pq.add(new Vertex(next.idx, dist[next.idx]));
    			}
    		}
    	}

start: 시작 정점
end: 도착 정점
dist[]: dp 테이블, 특정 idx까지의 최단 거리를 기록함
- 처음에는 모든 거리를 충분히 큰 수로 초기화
우선순위 큐에 시작 정점(가중치 0 -> 시작 지점이니까 거리가 0)을 추가
시작 정점의 거리를 0으로 초기화(dist[start] = 0)
이후 pq가 빌 때까지 다익스트라 핵심 로직 실행

    	while (!pq.isEmpty()) {
    		Vertex cur = pq.poll();
    		
    		if (visited[cur.idx]) continue;
    		visited[cur.idx] = true;
    		
    		for (Vertex next : graph[cur.idx]) {
    			if (dist[next.idx] > dist[cur.idx] + next.weight) {
    				dist[next.idx] = dist[cur.idx] + next.weight;
    				pq.add(new Vertex(next.idx, dist[next.idx]));
    			}
    		}
    	}

1. Vertex cur = pq.poll();

우선순위 큐에서 현재까지 비용이 가장 작은 정점을 꺼냄.
pq는 weight(현재까지의 비용) 기준으로 정렬되어 있어서 항상 "가장 짧은 거리 후보"가 먼저 나옴.

2. if (visited[cur.idx]) continue;

이미 방문했던 정점이면 다시 처리할 필요 없음
이유: 다익스트라에서는 한 번 최단거리가 확정된 노드는 더 이상 짧은 경로가 나올 수 없기 때문.

3. visited[cur.idx] = true;

현재 꺼낸 정점을 방문 처리 -> "이 정점의 최단거리가 확정되었다"는 뜻.

4. for (Vertex next : graph[cur.idx]) { ... }

현재 정점(cur)과 연결된 모든 인접 정점(next)을 확인.

5. if (dist[next.idx] > dist[cur.idx] + next.weight) { ... }

조건 의미:
- 현재 next.idx까지 기록된 최단거리(dist[next.idx])
- vs. cur까지 오는 최단거리 + cur → next로 가는 간선 비용(next.weight)
- 더 짧은 경로를 찾으면 갱신.

6. dist[next.idx] = dist[cur.idx] + next.weight;

최단거리 배열 갱신.
"현재까지 확인한 것보다 더 싸게(next.idx까지) 갈 수 있다"는 뜻.

7. pq.add(new Vertex(next.idx, dist[next.idx]));

갱신된 경로를 우선순위 큐에 넣음.
나중에 이 next.idx도 꺼내서 그 주변 노드들을 확인하게 됨.

코드 전문

BOJ 1753 - 최단경로

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.PriorityQueue;
import java.util.StringTokenizer;

public class BOJ_1753 {
	public static class Vertex implements Comparable<Vertex> {
		int idx;
		int weight;
		
		public Vertex(int idx, int weight) {
			this.idx = idx;
			this.weight = weight;
		}

		@Override
		public int compareTo(Vertex o) {
			return Integer.compare(this.weight, o.weight);
		}
	}
	
	public static void main(String[] args) throws IOException {
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		StringTokenizer st = new StringTokenizer(br.readLine());
		
		int V = Integer.parseInt(st.nextToken());
		int E = Integer.parseInt(st.nextToken());
		
		int start = Integer.parseInt(br.readLine());
		
		ArrayList<Vertex>[] graph = new ArrayList[V + 1];
		for (int i = 0; i <= V; i++) graph[i] = new ArrayList<>();
		
		for (int i = 0; i < E; i++) {
			st = new StringTokenizer(br.readLine());
			
			int u = Integer.parseInt(st.nextToken());
			int v = Integer.parseInt(st.nextToken());
			int w = Integer.parseInt(st.nextToken());
			
			graph[u].add(new Vertex(v, w));
		}
		
		int[] dist = new int[V + 1];
		Arrays.fill(dist, Integer.MAX_VALUE);
		
		PriorityQueue<Vertex> pq = new PriorityQueue<>();
		boolean[] visited = new boolean[V + 1];
		
		pq.add(new Vertex(start, 0));
		dist[start] = 0;
		
		while (!pq.isEmpty()) {
			Vertex cur = pq.poll();
			if (visited[cur.idx]) continue;
			visited[cur.idx] = true;
			
			for (Vertex next : graph[cur.idx]) {
				if (dist[next.idx] > dist[cur.idx] + next.weight) {
					dist[next.idx] = dist[cur.idx] + next.weight;
					pq.add(new Vertex(next.idx, dist[next.idx]));
				}
			}
		}
		
		for (int i = 1; i <= V; i++) {
			if (dist[i] == Integer.MAX_VALUE) System.out.println("INF");
			else System.out.println(dist[i]);
		}
	}
}

코드 해설

로직은 똑같음.

이전 문제는 시작 정점과 끝 정점을 입력 받아서 최종적으로는 끝 정점의 값만을 출력했다면 지금 문제는 dp 테이블의 모든 값들을 출력하는 문제임.

[JAVA] 최소 신장 트리 - Prim 알고리즘 <Minimum Spanning Tree - Prim>

Dongni — Mon, 22 Sep 2025 23:54:44 +0900

최소 신장 트리 - MST(Minimum Spanning Tree)

최소 신장 트리의 개념은 아래 글의 초입에 서술되어 있다.

2025.09.11 - [Algorithm] - [JAVA] 최소 신장 트리 - Kruskal 알고리즘

[JAVA] 최소 신장 트리 - Kruskal 알고리즘 <Minimum Spanning Tree - Kruskal>

최소 신장 트리 - MST(Minimum Spanning Tree)최소 신장 트리란, 여러 스패닝 트리 중 간선들의 가중치의 총합이 가장 작은 트리를 이야기한다. 그렇다면 최소 신장 트리를 알려면 신장 트리(Spanning Tree)

bitbard-dongni.tistory.com

Prim 알고리즘

프림 알고리즘의 경우 크루스칼 알고리즘과는 다르게 정점에게 포커싱을 맞춰서 구현한다. 시작 정점부터 가까운 정점마다의 간선을 확인하면서 다소 그리디하게 전개시키는 알고리즘이랄까?

쉽게 생각해보면, 크루스칼 알고리즘에서는 모든 간선의 정보를 오름차순으로 정렬해서 가중치가 가장 작은 간선들을 선택하는 방법이었지만 프림 알고리즘에서는 가까운 간선들 중에서도 특히 더 가까운 정점들을 위주로 선택해가면서 뻗어나가는 알고리즘이란 걸 생각하면 된다.

그림으로 예시를 확인해보자.

자 위와 같은 그래프가 존재한다고 가정해보자.

지금부터 한 단계씩 어떤 동작들이 일어나는지 확인해보면서 프림 알고리즘을 이해해보자.

우선, 임의의 시작 노드로 1번 노드를 선택했다고 생각해보자.

후보 간선은 우선순위 큐로, 가중치를 기준으로 삽입할 때 자동 정렬 된다.

1번 노드를 선택했을 때, 1번 노드와 간선으로 연결된 노드들은 2번, 3번, 4번 노드이다. 이들은 모두 후보 간선에 추가해두자.

후보 간선에서 하나를 꺼내게 되면 자동적으로 현재 노드와 연결 된 간선 중 가장 가중치가 낮은 간선이 꺼내지게 된다.

해당 예시에서는 1번과 3번을 연결하는 간선(가중치 2) 이 선택된다.

이후 정렬 결과에 1번과 3번 노드를 잇는 간선을 추가해준다.

(물론 여기서 임의로 간선을 추가해준건데, 실제로는 노드를 방문처리 한다거나 등의 방식들이 사용된다. 자세한건 후에 설명할 실제 코드 참고)

이후에 1번과 2번, 1번과 4번을 연결하는 간선들은 선택할 수 없게 된다.

왜냐하면 1번 노드와 3번 노드의 방문 여부를 true로 업데이트 해야하기 때문이다.

그럼 이제는 3번 노드의 주위를 볼 차례이다. 마찬가지로 3번 노드를 기준으로 후보 간선들을 찾아본다.

3번 노드의 후보 간선들 중, 가장 가중치가 낮은 3번 노드와 5번 노드를 잇는 간선이 선택된다.

동시에, 정렬 결과에 해당 연결 정보가 저장된다.

이제 5번 노드를 기준으로 확인해보려고 하는데, 후보 간선이 될 수 있는 간선이 아예 존재하지 않는다.

이제는 다시 3번 노드를 기준으로 확인해야 한다.

다시 3번 노드를 기준으로, 2번과 4번으로 연결되는 후보 간선이 이제는 2개가 존재한다.

동일한 가중치이기에 임의로 2번 노드로 가는 후보 간선을 선택했다고 가정하고, 정렬 결과에 3번 노드와 2번 노드를 잇는 연결 정보를 추가한다.

이후, 마찬가지로 2번 노드를 기준으로 후보 간선들을 탐색하고

가장 가중치가 작은 간선을 선택해서 정렬 결과에 추가해준다.

이제 마지막으로 4번 노드를 기준으로 후보 간선들을 탐색해서

정렬 결과에 추가해주면

간선의 개수가 (노드의 개수 - 1개)를 만족했기 때문에 여기서 종료되고 프림 알고리즘을 통한 MST 구현을 성공하게 된다.

사실, 엄밀히 따지자면 각 정점을 기준으로 PQ를 생성해서 사용하는 것이 아니기 때문에 이전 간선들의 정보가 모두 저장이 되어있다.

따라서 위와 같은 방법으로 진행된다기 보다는 실제로는 간선을 꺼낼 때, 간선과 연결된 노드가 이미 방문되었다면 해당 간선을 스킵하는 방식으로 구현이 되어있다.

그래서 사실 5번 노드에서 3번 노드로 되돌아간다는 부분에서 약간 이해가 안될 수 있을 것 같다고 생각했다.

결국엔, PQ에 이전까지의 모든 간선 정보가 담겨있는데,

3번 노드에서 5번 노드로 가는 간선을 선택 -> 5번 노드에서는 아무런 간선도 추가하지 않음 -> 3번 노드에서 다른 노드로 가는 간선을 선택

이렇게 5번 노드에서 아무런 간선도 추가하지 않았기 때문에 자연스럽게 다시 이어서 3번 노드에서 다른 노드로 가는 간선을 선택하게 되는 것이다.

물론, 이때 3번 노드에서 다른 노드로 가는 간선보다 더 짧은 가중치의 간선들이 존재한다면 그 간선들이 꺼내져서 선택되겠지만, 실제로 그 간선들의 출발 노드와 도착 노드가 이미 방문 처리 되어있을 것이기 때문에 스킵되고 3번 노드에서 다른 노드로 가는 간선이 선택되게 될 것임은 자명하다.

Prim 알고리즘 동작 원리

1. 인접 리스트에 연결 정보 저장
2. 시작 노드를 기준으로 시작 노드와 연결된 간선을 PQ에 삽입

3. 해당 간선의 도착 노드를 방문 처리

4. 가중치 합 갱신, 선택된 정점 개수 갱신

5. 다음 노드와 연결된 다다음 노드들에 대해서 간선 후보를 PQ에 삽입

6. 모든 정점이 선택 될 때까지 3 ~ 5번 과정 반복

코드 전문

SWEA 3124 - 최소 스패닝 트리

package test;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.PriorityQueue;
import java.util.StringTokenizer;

/**
 * @link: https://swexpertacademy.com/main/talk/solvingClub/problemView.do?solveclubId=AZgruskKCQnHBIT9&contestProbId=AV_mSnmKUckDFAWb&probBoxId=AZjkGae6SiPHBIO0+&type=PROBLEM&problemBoxTitle=0826&problemBoxCnt=++3+
 * @performance: 2,018 ms, 165,272 kb
 * @note:
 * - 프림 알고리즘은 기본적으로 무방향 그래프인 걸 명심
 * 		- 진입, 진출 간선 중 하나라도 해당됐으면 정점 자체를 방문처리해야 함
 * - 정점도 굳이 간선 배열을 사용할 필요는 없음. -> 인접 리스트를 이용하면 됨
 * - 왜 프림은 인접 리스트고 크루스칼은 간선 배열을 썼을까?
 * 		- 크루스칼 알고리즘은 주어진 모든 간선을 오름차순 정렬해주어야 함.
 * 		- 프림 알고리즘은 시작 정점부터 가까운 정점마다의 간선을 차례대로 확인해야 함.
 * - 두 알고리즘 모두 MST 알고리즘이지만, 무엇을 중점적으로 보느냐가 다름.
 * - 크루스칼은 간선에게 포커싱을, 프림은 정점에게 포커싱을 맞춰서 둘의 구현 방법도 달라짐.
 * - 그냥 쉽게 생각해보면, 특정 정점에서 다른 정점들로 뻗어 나갈 때는 인접 행렬 또는 인접 리스트가 떠오르는데
 * - 인접 행렬보다 조금 더 공간적으로 활용하기 좋은 인접 리스트를 많이 사용하는 게 정석적임.
 * - Q.E.D.
 * @timecomplex: 
 */
public class SWEA_3124_PRIM {
	public static int V;
	public static int E;
	
	public static class Node implements Comparable<Node>{
		int to;
		long weight;
		
		public Node(int to, long weight) {
			this.to = to;
			this.weight = weight;
		}

		@Override
		public int compareTo(Node o) {
//			return this.weight - o.weight;
			return Long.compare(this.weight, o.weight);
		}
	}
	
	static long result;
	static boolean[] visited;
	static List<Node>[] graph;

	public static void main(String[] args) throws NumberFormatException, IOException {
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		StringBuilder sb = new StringBuilder();
		StringTokenizer st;
		int T = Integer.parseInt(br.readLine());
		
		for (int test_case = 1; test_case <= T; test_case++) {
			st = new StringTokenizer(br.readLine());
			
			V = Integer.parseInt(st.nextToken());
			E = Integer.parseInt(st.nextToken());
			result = 0;
			
			visited = new boolean[V + 1];
			
			// 정점을 저장할 인접 리스트
			graph = new ArrayList[V + 1];
            for (int i = 1; i <= V; i++) {
            	graph[i] = new ArrayList<>();
            }
            
			// 입력
			for (int i = 1; i <= E; i++) {
				st = new StringTokenizer(br.readLine());
				int f = Integer.parseInt(st.nextToken());
				int t = Integer.parseInt(st.nextToken());
				int w = Integer.parseInt(st.nextToken());
                graph[f].add(new Node(t, w));
                graph[t].add(new Node(f, w));
			}

			long result = prim(1);
			
			sb.append("#").append(test_case).append(" ").append(result).append("\n");
		}
		System.out.print(sb);
	}


	private static long prim(int start) {
		PriorityQueue<Node> pq = new PriorityQueue<>();
		pq.add(new Node(start, 0)); // 시작 노드는 가중치가 0
		
		long sum = 0;
		long cnt = 0;
		
		while(!pq.isEmpty()) {
			Node cur = pq.poll();
			if (visited[cur.to]) continue;
			
			visited[cur.to] = true;
			sum += cur.weight;
			cnt++;
			
			if (cnt == V) break;
			
			for (Node next : graph[cur.to]) {
				if (!visited[next.to]) {
					pq.add(next);
				}
			}
		}
		
		return sum;
	}
}

코드 해설

private static long prim(int start) {
		PriorityQueue<Node> pq = new PriorityQueue<>();
		pq.add(new Node(start, 0)); // 시작 노드는 가중치가 0
		
		long sum = 0;
		long cnt = 0;
		
		while(!pq.isEmpty()) {
			Node cur = pq.poll();
			if (visited[cur.to]) continue;
			
			visited[cur.to] = true;
			sum += cur.weight;
			cnt++;
			
			if (cnt == V) break;
			
			for (Node next : graph[cur.to]) {
				if (!visited[next.to]) {
					pq.add(next);
				}
			}
		}
		
		return sum;
	}

PriorityQueue<Node> pq = new PriorityQueue<>();

최소 가중치 간선을 항상 꺼낼 수 있도록 우선순위 큐(PQ)를 준비

pq.add(new Node(start, 0)); // 시작 노드는 가중치가 0

시작 정점을 MST에 포함시키기 위해 가중치 0으로 PQ에 삽입
이렇게 하면 첫 단계에서 자동으로 시작 정점이 선택되게 됨

while(!pq.isEmpty()) {

큐가 빌 때까지 반복하면서 MST를 확장

Node cur = pq.poll();

현재까지 후보 간선 중 최소 가중치를 가진 간선을 꺼냄

if (visited[cur.to]) continue;

꺼낸 간선이 이미 MST에 포함된 정점(이전에 이미 연결된 노드 정보)으로 향하면 무시
중복 방문이나 사이클 생성을 막는 역할

visited[cur.to] = true;

새로 선택된 정점을 MST에 포함시키고 방문 처리

sum += cur.weight;
cnt++;

해당 간선의 가중치를 가중치 총합에 합산
선택된 정점의 개수(cnt)를 증가시킴

if (cnt == V) break;

모든 정점이 MST에 포함되었다면 MST 완성 (종료 조건)

for (Node next : graph[cur.to]) {
    if (!visited[next.to]) {
        pq.add(next);
    }
}

현재 정점에서 갈 수 있는 모든 간선을 확인
아직 MST에 포함되지 않은 정점으로 향하는 간선만 PQ에 넣어 후보 간선으로 관리

[HTTP] sendRedirect() vs forward() 차이점 간단 비교

Dongni — Sun, 21 Sep 2025 01:11:00 +0900

sendRedirect() vs forward()

웹 개발을 하다보면 특정 페이지로 이동시키는 기능을 구현해야 하는데, 그 중 대표적으로 이 두가지 함수들이 존재한다.

사실 이정도는 개발 입문 일주일차쯤에 알게되는 내용이겠지만.. 개발 블로그를 시작했음에도 아직 뭔가 거창한 걸 올리기에는 실력이 부족하기 때문에..

밑바닥부터 쌓아 올라가는 느낌으로 한 번 업로드해보려고 한다.

아 근데 물론 리다이렉션 되는거 vs 안되는 거 처럼 막 너무 간단하고 추상적인 비교 말고 좀 더 깊게 비교해보려고 한다.

현재 서블릿을 학습 중이므로 서블릿을 기준으로 코드를 작성했지만, HTTP 웹 개발 전반에 해당되는 개념임을 명심하자.

sendRedirect()

	@Override
	protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		response.sendRedirect(request.getContextPath() + "/regist.html");
	}

HTTP 302 응답을 보내고, 브라우저가 다시 /regist.html로 요청.
즉, 두 번의 요청이 발생한다. (redirect 응답 -> 새 요청)
주소창 URL이 바뀜.
request 객체가 초기화되므로 setAttribute()로 전달한 값은 사라짐.

sendRedirect() 언제 쓰면 좋은가?

URL을 바꿔야 할 때 (사용자에게 최종 주소를 보여주고 싶을 때)
PRG 패턴(Post-Redirect-Get) -> 폼 제출 후 새로고침 중복 전송 방지
다른 컨텍스트나 외부 사이트로 이동할 때
로그인 성공 후 메인 페이지로 이동하는 느낌 + 회원 가입 폼을 중복 제출하는 것을 방지하는 느낌

forward()

	@Override
	protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		request.getRequestDispatcher("/regist.html").forward(request, response);
	}

서버 내부에서 요청을 넘김.
주소창 URL 안 바뀜.
request와 response가 그대로 유지 -> setAttribute()로 전달한 데이터 JSP에서 바로 꺼낼 수 있음.
네트워크 요청은 한 번만 발생

forward() 언제 쓰면 좋은가?

데이터를 JSP로 넘겨서 출력해야 할 때
같은 요청 안에서 결과 화면을 바로 보여줄 때
주소창이 바뀌지 않아도 되는 경우
로그인 실패 시에 같은 화면에 사용자가 입력한 값과 에러 메시지 등을 다시 그대로 화면에 뿌려주는 느낌

왼쪽은 forward(), 오른쪽은 sendRedirect()

실제 예시를 확인해보면, forward()의 경우에는 하나의 HTTP 요청만이 발생했고 sendRedirect()의 경우는 두 번의 요청이 발생했음을 확인할 수 있음.

또한 sendRedirect()의 경우에는 HTTP 302 상태 코드를 반환하는 것을 볼 수 있음.

302는 Found 또는 임시 리디렉션(Temporary Redirect)을 나타내는 코드

차이를 잘 알고 사용하자.

[Docker] Virtualization support not detectedDocker Desktop requires virtualization support to run. Contact your IT admin to enable virtualization or check system requirements. 오류 해결

Dongni — Fri, 19 Sep 2025 01:24:37 +0900

도커 실습을 위해 docker desktop 프로그램을 실행해보았는데 아래와 같은 오류가 발생했다.

내용을 해석해보면, PC에서 하드웨어 가상화(virtualization)가 꺼져 있어서 Docker Desktop이 아예 실행되지 않는 상태이다.

이를 해결하기 위해서는 일단 PC의 가상화 기능을 켜주어야 하는데, 우선 가상화가 켜져있는지를 확인하려면 Windows PowerShell에서 다음과 같은 명령어를 입력해보면 된다.

systeminfo

출력 결과를 살펴보면,

Virtualization Enabled In Firmware: Yes → BIOS에서 가상화(VT-x/AMD-V) 켜져 있음
VM Monitor Mode Extensions: Yes → CPU가 가상화 기능 지원
Second Level Address Translation: Yes → WSL2, Hyper-V에 필요한 SLAT 지원
Data Execution Prevention Available: Yes → DEP 켜져 있음

하드웨어 단에서는 가상화가 잘 켜져 있음을 알 수 있다. 그렇다면 문제는 윈도우의 가상환경 적용 유무가 아닌 WSL2(Windows Subsystem for Linux 2)환경이 세팅되어 있지 않다는 말이다.

Windows Home 에디션의 경우, Docker Desktop을 실행하려면 WSL2가 필요하기 때문에 WSL2가 준비되어 있어야 엔진이 켜지고 docker pull과 같은 명령어들을 사용할 수 있게 된다.

해결 방법

관리자 권한으로 PoswerShell 실행
wsl.exe --install Ubuntu 명령어 입력
wsl --install -d Ubuntu-22.04
→ 자동으로 필요한 Windows 선택적 기능 설치 시작
"가상 머신 플랫폼" 기능 켜기
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
WSL 필수 구성 요소 켜기
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
명령어 모두 실행한 뒤 재부팅

그러나.. 모든 명령어를 실행해봤음에도 해결이 되지 않았음.

PS C:\WINDOWS\system32> wsl --status >>
기본 버전: 2 현재 컴퓨터 구성에서는 WSL1이 지원되지 않습니다.
WSL1을 사용하려면 "Windows Subsystem for Linux” 선택적 구성 요소를 사용하세요.
WSL2는 현재 컴퓨터 구성에서 지원되지 않습니다.
"가상 머신 플랫폼" 선택적 구성 요소를 사용하도록 설정하고
BIOS에서 가상화가 사용하도록 설정되어 있는지 확인하세요.

실행하여 "가상 머신 플랫폼"을 사용하도록 설정: wsl.exe --install --no-distribution
자세한 내용은 https://aka.ms/enablevirtualization 참조하세요. PS C:\WINDOWS\system32>

위와 같이 WSL이 잘 설치가 되지 않은듯한 상태였음.

하드웨어단에서 가상화도 켜져있고

Hyper-V 계열 하이퍼바이저도 활성화 돼있고

CPU도 Intel VT-x를 지원하는 모델이고..

윈도우의 기능은 모두 켜져있는데 WSL2 커널이 올라오질 못했음.

WSL 엔진 초기화도 해보고 다른 버전으로 다운도 받아보고 WSL 패키지 자체를 삭제하고 재설치도 해봤는데 모두 실패.

그러나

VMware Workstation Player, VirtualBox 같이 하이퍼바이저 사용하는 프로그램이 있다면 충돌이 날 수도 있다는 내용을 보고 VMware 17 버전을 삭제해주었더니...

이제 도커가 정상 작동된다!..

핵심은 VMware를 사용해본 적 있다면 삭제해보시길 권장.

[JAVA] 최소 신장 트리 - Kruskal 알고리즘 <Minimum Spanning Tree - Kruskal>

Dongni — Thu, 11 Sep 2025 11:51:43 +0900

최소 신장 트리 - MST(Minimum Spanning Tree)

최소 신장 트리란, 여러 스패닝 트리 중 간선들의 가중치의 총합이 가장 작은 트리를 이야기한다.

그렇다면 최소 신장 트리를 알려면 신장 트리(Spanning Tree)를 알아야 하는데, 스패닝 트리(신장 트리)란 모든 정점을 연결했을 때 간선의 수가 V - 1개이고 사이클이 존재 하지 않는 무방향 그래프를 의미한다.

신장 트리 예시

모든 정점이 연결되었고, 5개의 정점에 대해서 4개의 간선만을 가지고 있으며, 사이클이 존재하지 않는 무방향 그래프임을 볼 수 있다.

간선에 적혀있는 숫자들은 간선의 가중치를 의미한다.

최소 신장 트리

위 그림의 경우, 기존에 1번 정점과 3번 정점을 연결하는 가중치 3의 간선대신 2번 정점과 3번 정점을 연결하는 가중치 2의 간선을 선택해서 이 경우보다 가중치가 작은 간선을 선택하는 경우가 없다고 가정해보자.

위와 같은 상황이 바로 최소 신장 트리의 예시를 의미한다.

최소 신장 트리의 구현

최소 신장 트리는 이렇게 쉬운 개념을 가지고 있으며, 구현하는 방법은 2가지가 존재한다.

Kruskal 알고리즘
Prim 알고리즘

Kruskal 알고리즘

크루스칼 알고리즘의 경우 이전에 설명한 Union-Find 알고리즘을 활용해서 전개시킬 수 있다.

왜 유니온 파인드 알고리즘을 적용시킬까?
-> 유니온 파인드 알고리즘의 적용 예시 중 하나가 바로 사이클 판별인데, 최소 신장 트리의 조건인 무방향 그래프를 구현하기 위해서 유니온 파인드 알고리즘을 적용시키는 것.
-> 결국, 두 정점이 이미 같은 트리(집합)라면 그 간선은 선택하지 않는다는 의미를 함축함.

2025.09.05 - [분류 전체보기] - [JAVA] 유니온 파인드 알고리즘

[JAVA] 유니온 파인드 알고리즘 <Disjoint Set>

유니온 파인드 알고리즘유니온 파인드(Union-Find) 알고리즘은 서로소 집합(Disjoint Set Union, DSU) 자료구조를 이용해 원소들이 같은 집합에 속하는지 판별하거나, 두 집합을 하나로 합치는 연산을 효

bitbard-dongni.tistory.com

기본적으로 정점과 간선에 대한 정보를 이용해서 간선에게 초점을 맞춰서 접근면 된다.

이 말이 지금은 별로 와닿지 않는데, Prim 알고리즘을 보고 나면 왜 하필 간선에 초점을 맞춰야 한다고 말했는지 느낄 수 있게 된다.

아무튼, 크루스칼 알고리즘은 가중치가 가장 작은 간선들만을 선택해나가면서 최소 신장 트리를 구현하는 것이다.

Kruskal 알고리즘 동작 원리

1. 간선 배열을 만들어서 입력 정보 전처리
2. 유니온 파인드 로직 - make()

3. 간선 배열을 가중치를 기준으로 오름차순 정렬
4. 유니온 파인드 로직 - find(), union()

코드 전문

SWEA 3124 - 최소 스패닝 트리

package src;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.Arrays;
import java.util.StringTokenizer;

/**
 * @link: https://swexpertacademy.com/main/talk/solvingClub/problemView.do?solveclubId=AZgruskKCQnHBIT9&contestProbId=AV_mSnmKUckDFAWb&probBoxId=AZjkGae6SiPHBIO0+&type=PROBLEM&problemBoxTitle=0826&problemBoxCnt=++3+
 * @performance: 2,184 ms, 115,960 kb
 * @note: Union-Find 복습 + Kruskal 복습
 * - Union-Find 로직에 Rank를 통한 최적화 및 경로 압축 최적화 적용
 * - 최대한 정석에 가깝게 구현했으니 해당 코드를 바탕으로 응용 연습해보면 될 듯.
 * - 물론 그냥 내 생각일 뿐
 * - 원래는 N개의 노드에 대해서 가장 저렴한 가중치를 가진 N - 1 개의 간선을 선택했을 때
 * - MST를 만족하지 못하는 경우가 있을거라는 이상한 착각에 빠졌었음 (혹시나 연결 안된 노드가 있다면? 노드에서 간선이 여러개 빠져 나가면 특정 노드는 연결 안되는 거 아님?)
 * @timecomplex: 아커만역함수 머시기 아무튼 빠름 근데 Arrays.sort() 써서 O(NlogN)일듯
 */
public class SWEA_3124 {
	// Union-Find
	public static int[] parents;
	
	public static void make() {
		for (int i = 0; i <= V; i++) {
			parents[i] = -1; // Union By Rank
		}
	}
	
	public static int find(int cur) {
		if (parents[cur] < 0) return cur; // 값이 -1이면 루트 노드를 의미, -2 이하이면 랭크가 증가한 부모 노드를 의미
		return parents[cur] = find(parents[cur]); // 경로 압축
	}
	
	public static boolean union(int a, int b) {
		int aP = find(a);
		int bP = find(b);
		
		// 이미 같은 집합
		if (aP == bP) return false;
		
		// 랭크가 서로 다를 때 (b가 더 큰 랭크) -> 왜 스왑? -> 자식으로 만드는 부분을 하나의 코드로 통일
		if (parents[aP] > parents[bP]) {
			// swap
			int temp = aP;
			aP = bP;
			bP = temp;
		}
		
		// 랭크가 서로 같을 때 -> a의 Rank를 증가 (-1, -2, -3 ... 작아질 수록 랭크가 큼)
		if (parents[aP] == parents[bP]) {
			parents[aP]--;
		}

		// 기본적으로는 b를 a의 자식으로 만듦.
		parents[bP] = aP;
		
		return true; // Union 연산 성공
	}
	
	// Kruskal -> 간선 배열 오름차순 정렬 + Union-Find로 간선 처리	
	public static class Edge implements Comparable<Edge> {
		int from;
		int to;
		int weight;
		
		public Edge(int from, int to, int weight) {
			this.from = from;
			this.to = to;
			this.weight = weight;
		}

		@Override
		public int compareTo(Edge o) {
			return Integer.compare(this.weight, o.weight);
		}
	}
	
	public static Edge[] edges;
	
	// ---
	public static int V;
	public static int E;
	
	public static void main(String[] args) throws NumberFormatException, IOException {
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		StringBuilder sb = new StringBuilder();
		StringTokenizer st;
		int T = Integer.parseInt(br.readLine());
		
		for (int test_case = 1; test_case <= T; test_case++) {
			st = new StringTokenizer(br.readLine());
			
			V = Integer.parseInt(st.nextToken());
			E = Integer.parseInt(st.nextToken());
			
			parents = new int[V + 1];
			edges = new Edge[E];
			
			for (int i = 0; i < E; i++) {
				st = new StringTokenizer(br.readLine());
				int from = Integer.parseInt(st.nextToken());
				int to = Integer.parseInt(st.nextToken());
				int weight = Integer.parseInt(st.nextToken());
				edges[i] = new Edge(from, to, weight);
			}
			
			Arrays.sort(edges);
			make();
			
			int cnt = 0;
			long sum = 0;
			for (Edge e : edges) {
				int f = e.from;
				int t = e.to;
				int w = e.weight;
				
				if (!union(f, t)) continue; // union 결과가 !false = true -> 이미 트리 구조에 편입됨 또는 사이클?
				sum += w;
				if (++cnt == V - 1) break;
			}
			
			sb.append("#").append(test_case).append(" ").append(sum).append("\n");
		}
		System.out.print(sb);
	}

}

코드 해설

// Kruskal -> 간선 배열 오름차순 정렬 + Union-Find로 간선 처리	
public static class Edge implements Comparable<Edge> {
    int from;
    int to;
    int weight;

    public Edge(int from, int to, int weight) {
        this.from = from;
        this.to = to;
        this.weight = weight;
    }

    @Override
    public int compareTo(Edge o) {
        return Integer.compare(this.weight, o.weight);
    }
}

간선의 가중치로 정렬을 하기 위해서 Comparable 인터페이스를 구현해주면 된다.

for (Edge e : edges) {
    int f = e.from;
    int t = e.to;
    int w = e.weight;

    if (!union(f, t)) continue; // union 결과가 !false = true -> 이미 트리 구조에 편입됨 또는 사이클?
    sum += w;
    if (++cnt == V - 1) break;
}

정렬된 간선 배열에서 간선을 하나씩 꺼낸 뒤, 저장된 간선 정보(시작 정점 -> 도착 정점)를 이용해서 union() 연산을 수행함.

union() 연산의 결과가 false일 경우에는 이미 같은 트리(집합)임을 시사하는 것이기 때문에 해당 간선은 선택하지 않음.

union() 연산이 성공하면 sum에 가중치를 더해주고 cnt가 V - 1개라면 종료해주면 된다. (간선의 개수는 정점 -1 개)

[JAVA] 유니온 파인드 알고리즘 <Disjoint Set>

Dongni — Fri, 5 Sep 2025 16:58:55 +0900

유니온 파인드 알고리즘

유니온 파인드(Union-Find) 알고리즘은 서로소 집합(Disjoint Set Union, DSU) 자료구조를 이용해 원소들이 같은 집합에 속하는지 판별하거나, 두 집합을 하나로 합치는 연산을 효율적으로 처리하는 알고리즘이다.

서로소 집합
여러 개의 집합이 있을 때, 어떤 두 집합도 공통 원소를 갖지 않는 경우를 말함.
즉, 집합끼리 겹치는 부분이 전혀 없는 상태
{1, 2}, {3, 4}, {5, 6}

유니온 파인드 알고리즘 적용 예시

그래프 이론 관련
- 최소 신장 트리 (MST) - 크루스칼 알고리즘
- 사이클 판별
  - 간선을 하나씩 추가하면서 두 정점이 이미 같은 집합인지 확인(Union) -> 같은 집합이면 사이클 존재
- 연결 요소 찾기
  - 그래프에서 분리된 그룹 개수 세기

이렇게 말해도 사실상 와닿지 않으니까 한 마디로 정리해보면, "서로 연결된 덩어리"를 관리할 때 고려해볼 수 있는 알고리즘 이 된다.

유니온 파인드 동작 원리

1. 자기 자신의 부모를 자신으로 초기화하는 make() 함수
2. 특정 원소의 부모를 찾는 find() 함수
3. 원소 a, 원소 b가 속한 집합을 합치는 union() 함수
4. 문제의 조건에 따라서 원소들을 입력받고 union() 진행

유니온 파인드 동작 미리보기

make()

자신의 부모를 자기 자신으로 모두 초기화 해준다.

해당 그림에서는 부모 노드로의 간선 표시를 생략해주었다.

union(1, 2)

1번 원소와 2번 원소를 union 처리 -> 여기서는 임의로 union의 첫 번째 매개변수에 두 번째 매개변수를 편입시켰음.

union(3, 4)

3번 원소와 4번 원소를 union 처리

union(2, 3)

1->3, 3->4 5, 6 과 같은 원소 집합이 있는 상태에서

2번 원소와 3번 원소를 union 해주면 위 그림과 같은 모양이 된다고 생각하면 됨.

유니온 파인드 최적화 방법

find(4) (경로 압축)

유니온 파인드 알고리즘은 트리의 구조가 중요한 것이 아니라 특정 집합에 속했냐 속하지 않았느냐, 어느 집합에 속했느냐와 같이 집합의 관점에서 접근해야 함.

따라서 find() 연산을 실행했을 때, 해당 노드와 연결된 모든 노드들을 일종의 평탄화 작업을 해준다면 다음 조회에서는 상수 시간에 조회할 수 있게 된다.

예시에서는 find(4)를 진행했을 때, 어떤 식으로 동작하게 되는지를 간략하게 표현해보았다.

우선, find(4)를 호출하면 parents[4] = find(parent[4])가 반환되게 된다.

이후 재귀를 타고 들어가서 기저 조건을 만날 때까지 부모가 어느 집합에 속했는지를 찾는다.

parents[4] -> 4번이 가리키고 있는 부모 노드
find() -> 어느 집합에 속했는지(누가 루트 노드인지, 누가 제일 높은 부모인지)
find(parent[4]) -> 4번 노드의 부모가 어느 집합에 속했는지 찾음

실행 결과

find(4)를 통해서 4번 노드, 3번 노드, 2번 노드가 평탄화된 것을 알 수 있음.

Union-by-Rank

또 다른 최적화 기법으로는 랭크를 이용한 최적화 방법이 존재한다.

모든 노드의 부모 값을 -1로 초기화 해준다.

이전 코드와 다른 점은 자기 자신을 부모로 초기화 해주었는데, 여기서는 기본 초기값으로 -1을 초기화해준 것.

union(1, 2)

이후 union 연산을 살펴보자.

1번 노드와 2번 노드의 rank는 같기 때문에, 둘 중 하나를 골라서 rank를 1 감소시켜준다.

또한 2번 노드의 부모 값을 1번 노드를 가리키게끔 갱신해준다.

union(1, 3)

다음으로 union(1, 3) 연산을 살펴보자.

1번 노드의 랭크는 -2, 3번 노드의 rank는 -1인데, 1번 노드의 랭크가 더 높기 때문에 (음수로 커질 수록 커짐)

2번 노드를 그대로 1번 노드의 자식으로 편입시켜주면 된다.

여기서 1번 노드의 rank의 변화는 없다.

rank의 변화가 발생하는 포인트는 union 연산하는 두 노드의 rank 값을 비교해서 만약 두 노드의 rank 값이 같다면 임의로 한 노드의 rank를 증가(단, 음수로 커지게) 시켜주면 된다.

그래서 이게 왜 최적화냐?

유니온 파인드에서 가장 무서운 건 트리가 지팡이처럼 길어지는 편향 이진트리의 모습일 것이다.

경로 압축만 있을 때: find를 호출하기 전까지는 트리가 얼마나 깊을지 모름. 만약 100만 개의 노드가 일렬로 연결되어 있다면, 첫 번째 find는 100만 번을 타고 올라가야 함.
Union-by-Rank가 있을 때: 합칠 때부터 "키 큰 놈이 대장 해라" 규칙을 적용합니다.

위 그림처럼 작은 트리를 큰 트리 밑에 붙이면 전체 트리의 높이가 늘어나지 않습니다. 반대로 큰 트리를 작은 트리 밑에 붙이면? 전체 높이가 확 커지겠죠. 이걸 사전에 차단하는 게 목적입니다.

코드 전문

SWEA 3289 - 서로소 집합

package test;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class SWEA_3289 {
	static int n;
	static int m;
	static int[] parents;
	
	private static void make() {
		for (int i = 0; i <= n; i++) {
			parents[i] = i; // make set: 자신을 자신의 부모로 초기화(자신이 곧 루트이자 대표자)
		}
	}
	
	private static int find(int a) { // a가 속한 집합(집합의 대표자) 찾기
		if (parents[a] == a) {
			return a;
		} else {
//			return find(parents[a]);
			return parents[a] = find(parents[a]); // 패스 압축 적용
		}
	}
	
	private static boolean union(int a, int b) { // 원소 a, 원소 b가 속한 집합을 합치기
		int aRoot = find(a);
		int bRoot = find(b);
		if (aRoot == bRoot) return false; // 같은 집합이니까 union할 필요 없음
		
		parents[bRoot] = aRoot; // b, a가 아닌, bRoot, aRoot를 사용해야 대표자끼리 연산하는 게 됨.
		return true; // union 성공
	}
	
	public static void main(String[] args) throws NumberFormatException, IOException {
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		StringBuilder sb = new StringBuilder();
		int T = Integer.parseInt(br.readLine());
		
		for (int test_case = 1; test_case <= T; test_case++) {
			StringTokenizer st = new StringTokenizer(br.readLine());
			sb.append("#").append(test_case).append(" ");
			n = Integer.parseInt(st.nextToken());
			m = Integer.parseInt(st.nextToken());
			
			parents = new int[n + 1];
			make();
			
			for (int i = 0; i < m; i++) {
				st = new StringTokenizer(br.readLine());
				int oper = Integer.parseInt(st.nextToken());
				int a = Integer.parseInt(st.nextToken());
				int b = Integer.parseInt(st.nextToken());
				
				if (oper == 0) {
					union(a, b);
				} else {
					sb.append(find(a) == find(b) ? 1 : 0);
				}
			}

			sb.append("\n");
		}
		
		System.out.print(sb);
	}

}

최적화가 경로 압축밖에 되지 않은 기본적인 유니온 파인드 알고리즘

SWEA 3124 - 최소 스패닝 트리

package src;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.Arrays;
import java.util.StringTokenizer;

public class SWEA_3124 {
	// Union-Find
	public static int[] parents;
	
	public static void make() {
		for (int i = 0; i <= V; i++) {
			parents[i] = -1; // Union By Rank
		}
	}
	
	public static int find(int cur) {
		if (parents[cur] < 0) return cur; // 값이 -1이면 루트 노드를 의미, -2 이하이면 랭크가 증가한 부모 노드를 의미
		return parents[cur] = find(parents[cur]); // 경로 압축
	}
	
	public static boolean union(int a, int b) {
		int aP = find(a);
		int bP = find(b);
		
		// 이미 같은 집합
		if (aP == bP) return false;
		
		// 랭크가 서로 다를 때 (b가 더 큰 랭크) -> 왜 스왑? -> 자식으로 만드는 부분을 하나의 코드로 통일
		if (parents[aP] > parents[bP]) {
			// swap
			int temp = aP;
			aP = bP;
			bP = temp;
		}
		
		// 랭크가 서로 같을 때 -> a의 Rank를 증가 (-1, -2, -3 ... 작아질 수록 랭크가 큼)
		if (parents[aP] == parents[bP]) {
			parents[aP]--;
		}

		// 기본적으로는 b를 a의 자식으로 만듦.
		parents[bP] = aP;
		
		return true; // Union 연산 성공
	}	
}

코드 해설

다른 말 할 필요없이, make, find, union 세 함수만 잘 알고있으면 아무 문제 없이 구현할 수 있다.