JiHoon.log

ArrayList

KongJiHoon — Sun, 27 Sep 2026 20:27:55 +0900

1️⃣ ArrayList

ArrayList는 Java의 List 인터페이스의 구현체 중 하나로, 내부적으로 배열을 사용해서 데이터를 저장하는 동적 배열 자료구조이다.

List<String> list = new ArrayList<>();

list.add("A");
list.add("B");
list.add("C");

일반 배열과 가장 큰 차이는 크기가 자동으로 늘어난다는 것이다.

일반 배열:

String[] arr = new String[3];

크기 3으로 고정된다.

ArrayList:

List<String> list = new ArrayList<>();

필요한 데이터가 늘어나면 내부 배열을 더 큰 배열로 교체한다.

(1) 내부 구성 요소

개념적으로 ArrayList 내부에는 다음과 같은 필드가 있다고 보면된다.

Object[] elementData;
int size

즉,

elementData
→ 실제 데이터를 저장하는 배열

size
→ 현재 저장된 데이터 개수

여기서 중요한 개념이 하나 더 있다.

size와 capacity는 다르다.

size와 capacity의 차이

예를 들어, 내부 배열이 다음과 같다고 한다면

[A][B][C][ ][ ][ ][ ][ ][ ][ ]

실제 데이터는 3개지만 배열 공간은 10이다.

그러면

size = 3
capacity = 10

즉,

size
= 실제 들어있는 요소 개수

capacity
= 내부 배열이 저장할 수 있는 전체 공간

이다.

(2) add() 동작

list.add("D");

내부에 공간이 있다면 매우 단순하다.

[A][B][C][ ][ ]
         ↓
[A][B][C][D][ ]

개념적으로:

elementData[size] = value;
size++;

처럼 동작한다.

따라서 맨 뒤에 데이터를 추가하는 경우 보통:

O(1)

이다.

하지만 여기서 중요한 표현이 있다.

ArrayList의 맨 뒤 삽입은 정확히 항상 O(1)이 아니라 **amortized O(1)**이다.

왜냐하면 resize가 발생할 수 있기 때문이다.

(3) 배열의 공간 부족

다음 상태라고 해보자.

[A][B][C]

배열이 꽉 찼다.

그런데:

list.add("D");

를 수행해야 한다.

기존 배열 자체의 크기를 늘리는 것은 불가능하다.

Java 배열은 생성 시 크기가 고정되기 때문이다.

그래서 ArrayList는

이 과정을 거치게 된다.

개념적으로:

기존 배열

[A][B][C]

        ↓

새로운 더 큰 배열

[A][B][C][ ][ ][ ]

        ↓

D 추가

[A][B][C][D][ ][ ]

Open JDK의 현대적인 ArrayList 구현체는 일반적으로 기존 capacity의 1.5배 정도 크게 확장되는 방식이 사용된다.

일반적으로 O(1)이고, 내부 배열의 capacity가 부족해 resize가 발생하면 기존 요소를 새로운 배열로 복사해야 하기 때문에 해당 시점에는 O(n)이 걸립니다. 하지만 여러 삽입을 평균적으로 보면 amortized O(1)입니다.

(4) get()

get()의 시간복잡도는 O(1)dlek.

ArrayList는 인덱스를 통해 저장된 값에 접근할 수 있다.

개념적으로:

배열 시작 주소
+
index × 요소 크기

를 통해 원하는 위치를 바로 찾을 수 있다.

그래서:

get(index)
→ O(1)

이다.

LinkedList와 가장 크게 차이나는 부분이다.

중간 삽입 & 삭제 O(n)

다음 배열을 보자.

[A][B][C][D]

index 1에 X를 삽입한다.

list.add(1, "X");

그러면 기존 값들을 뒤로 밀어야 한다.

기존

[A][B][C][D]

     ↓

[A][ ][B][C][D]

     ↓

[A][X][B][C][D]

실제로는 뒤에서부터 이동한다.

따라서 중간에 값을 삽입하는 경우에 값을 이동시켜야 하기 때문에

시간 복잡도는 O(n)이다.

ArrayList의 값을 삭제하는 시간복잡도 또한 O(n)이다.

예:

[A][B][C][D][E]

B를 삭제하면:

list.remove(1);

빈 공간을 그대로 남겨두는 게 아니라 뒤쪽 요소들을 앞으로 당긴다.

그래서 중간 삭제도

O(n)

이다.

(5) ArrayList 검색

예:

list.contains("hello");

또는:

list.indexOf("hello");

배열 기반이라고 해서 값 검색도 O(1)은 아니다. index를 알고 있을 때만 O(1)이다.

값 자체를 찾으려면

0번째 확인
1번째 확인
2번째 확인
...

해야 한다.

따라서:

contains()
indexOf()

→ O(n)

이다.

정리

연산	시간복잡도
get(index)	O(1)
set(index)	O(1)
맨 뒤 add()	amortized O(1)
중간 add(index, value)	O(n)
중간 remove(index)	O(n)
contains()	O(n)
indexOf()	O(n)

2️⃣ ArrayList의 장점과 단점

(1) 장점

ArrayList의 가장 큰 장점은 빠른 index 접근이다. 그리고 실제로는 순회 성능도 좋은 편이다. 왜냐하면 배열의 요소가 메모리상 비교적 연속적으로 배치되기 때문이다.

CPU는 데이터를 읽을 때 필요한 값 하나만 읽는 것이 아니라 주변 데이터도 같이 캐시에 가져오는 경우가 많다.

이를 Spatial Locality 관점으로 이해할 수 있다.

그래서 순차적으로 데이터를 읽는 작업에서 ArrayList가 유리한 경우가 많다.

(2) 단점

중간 삽입/삭제가 많은 경우에는 데이터 이동 비용이 발생한다.

또 capacity가 실제 size보다 클 수 있기 때문에 사용하지 않는 공간이 생길 수도 있다.

예

size = 3

capacity = 10

[A][B][C][ ][ ][ ][ ][ ][ ][ ]

즉 여분의 메모리를 확보해두고 사용한다.

하지만 매번 정확한 크기의 배열을 만드는 것보다 이런 방식이 반복적인 add() 성능에는 훨씬 유리하다.

ArrayList vs 일반 배열

배열	ArrayList
크기 고정	크기 동적
primitive 저장 가능	Generic은 객체 타입
낮은 수준의 구조	여러 편의 메서드 제공
arr[index]	list.get(index)

예를 들어 배열은:

int[] numbers = new int[10];

primitive인 int를 바로 저장한다.

하지만:

List<Integer> numbers = new ArrayList<>();

에서는 Integer 객체 타입을 사용한다.

오토박싱도 발생할 수 있다.

numbers.add(10);

개념적으로:

numbers.add(Integer.valueOf(10));

와 비슷하다.

Collection Framework

KongJiHoon — Sat, 26 Sep 2026 20:25:35 +0900

1️⃣ Collection Framework

Java에서 여러 데이터를 저장하고 조작하기 위한 자료구조와 관련 인터페이스의 집합이다.

예를 들면

List<User> users = new ArrayList<>();
Set<Long> ids = new HashSet<>();
Map<Long, User> userMap = new HashMap<>();

배열만 사용하면 데이터 추가, 삭제, 검색 등을 직접 구현해야 하는데 Collection Framework가 이를 표준화하여 제공한다.

Collection Framework는 여러 데이터를 효율적으로 저장하고 조회, 추가, 삭제할 수 있도록 Java에서 제공하는 자료구조 관련 인터페이스와 구현체의 집합입니다. 대표적으로 List, Set, Queue, Map 등이 있습니다.

(1) Collection과 Map의 차이

List, Set, Queue는

Collection<E>

인터페이스를 상속한다.

하지만 Map<K, V>은 Collection을 상속하지 않는다.

왜냐하면 Collection은 기본적으로 하나의 값 요소를 다루지만 Map은 key, value 두 개의 값을 다루기 때문이다.

2️⃣ List

List의 특징은 다음과 같다.

순서 존재
중복 허용
index 접근 가능

예를 들어

List<String> list = new ArrayList<>();

list.add("A");
list.add("B");
list.add("A");


위와 값이 값이 저장되면

0 -> A
1 -> B
2 -> A

중복값이 허용되고 순서가 존재한다.

대표적인 구현체로는 ArrayList와 LinkedList가 존재한다.

(1) ArrayList

실무에서 가장 많이 사용되는 List 구현체 중 하나이다.

내부적으로는 동적 배열을 사용한다.

배열 기반이기 때문에 list.get(3);

처럼 인덱스를 알고 있으면 인덱스를 통해 접근할 수 있다.

시간 복잡도

작업	평균적인 복잡도
index 조회	O(1)
마지막 추가	amortized O(1)
중간 삽입	O(n)
중간 삭제	O(n)
값 검색	O(n)

ArrayList 중간 삽입/삭제가 O(n)인 이유

예를 들어

{A, B, C, D}

이 때 index 1에 X를 넣으면

{A, X, B, C, D}

기존 요소를 뒤로 옮겨야 한다. 그래서 데이터가 많으면 이동 비용이 발생한다.

ArrayList의 크기 변화

ArrayList는 내부적으로 배열을 사용하지만 크기가 고정되어 있지 않다.

공간이 부족하면 더 큰 배열을 만들고 기존 데이터를 복사한다.

그래서 add()가 항상 정확히 O(1)은 아니다.

배열 확장이 발생하는 순간에는 복사 비용이 O(n)이다.

하지만 여러 삽입을 평균내면:

amortized O(1)

이라고 한다.

(2) LinkedList

LinkedList는 노드들이 서로 연결된 구조이다.

Java의 LinkedList는 Doubley Linked List기반이다. -> 양쪽으로 연결된 구조이다.

각 노드는:

이전 노드
현재 값
다음 노드

정보를 가진다.

1) LinkedList의 조회

예를 들어:

list.get(100);

LinkedList는 배열처럼:

100번째 위치로 바로 이동

할 수 없다.

노드를 따라 이동해야 한다.

Node0
 ↓
Node1
 ↓
Node2
 ↓
...
 ↓
Node100

따라서 일반적인 index 조회는:

O(n)

이다.

항목	ArrayList	LinkedList
내부 구조	배열	연결 리스트
index 조회	O(1)	O(n)
마지막 추가	평균 O(1)	O(1)
중간 삽입/삭제	O(n)	탐색 후 O(1)
메모리	상대적으로 적음	노드 포인터 추가 필요
캐시 친화성	좋음	상대적으로 떨어짐

여기서 중요한 부분:

LinkedList는 삽입/삭제가 무조건 O(1)이다.

라고 하면 틀릴 수 있다.

삽입할 위치를 찾는 과정에서 O(n)이 필요할 수 있다.

정확히는:

이미 해당 노드의 위치를 알고 있다면 연결 변경은 O(1)이지만, index로 위치를 찾아야 한다면 탐색 비용 O(n)이 추가된다.

ArrayList가 더 자주 쓰이는 이유

일반적으로는 ArrayList가 더 많이 쓰인다.

이유는:

조회가 빠름
연속된 메모리 구조로 CPU cache에 유리
대부분의 서비스에서는 중간 삽입보다 순회/조회가 많음
LinkedList는 각 Node마다 추가 메모리가 필요

그래서:

List<User> users = new ArrayList<>();

를 기본 선택으로 생각하고, 특별한 이유가 있을 때 다른 자료구조를 고르는 방식이 보통 적절하다.

3️⃣ Set

Set은 중복을 허용하지 않는 Collection이다.

Set<Long> ids = new HashSet<>();

ids.add(1L);
ids.add(2L);
ids.add(1L);

결과
1, 2만 저장된다.

중복된 1은 추가되지 않는다.

대표적인 구현체로는 HashSet, LinkedHashSet, TreeSet이 있다.

(1) HashSet

HashSet은 내부적으로는 HashMap을 활용한다.

개념적으로

HashSet<String> set = new HashSet<>();

에서

set.add("A");

를 하면 내부적으로 키에 "A"를 저장하는 형태로 동작한다.

그래서 HashSet의 중복 판단에도 hashCode, equals가 중요하다.

(2) Set의 중복 판단

예를 들어

User user1 = new User(1L);
User user2 = new User(1L);

만약 논리적으로 같은 사용자라고 정의했다면

user1.equals(user2); // true

user1.hashCode() == user2.hashCode(); // true

위와 같은 조건을 만족해야 한다.

Set도 같은 원리로 동작한다.

Set<User> users = new HashSet<>();

users.add(user1);
users.add(user2);

이 경우에 두 객체가 논리적으로 같은 값이라면

equals/ hashCode -> HashSet -> 중복 판단

과정을 거쳐 하나의 객체만 저장된다.

(3) TreeSet

TreeSet은 이름 그대로 Tree 기반이다.

Java에서는 일반적으로 Red-Black Tree 기반으로 구현되어 있다.

특징:

중복 허용 X
정렬된 상태 유지
탐색/삽입/삭제 O(log n)

Set<Integer> numbers = new TreeSet<>();

numbers.add(5);
numbers.add(1);
numbers.add(3);

순회하면:

1
3
5

처럼 정렬된다.

4️⃣ Queue

Queue는 기본적으로 FIFO 구조의 자료구조이다.

예:

Queue<String> queue = new ArrayDeque<>();

queue.offer("A");
queue.offer("B");
queue.offer("C");

queue.poll(); // A

(1) offer / poll / peek

Queue에서 자주 사용하는 메서드다.

queue.offer(value);

추가.

queue.poll();

꺼내면서 제거.

queue.peek();

꺼내지 않고 확인.

BFS에서 자주 사용된다.

BFS에서 Queue를 사용하는 이유는 가까운 노드부터 순서대로 탐색하기 위해서다.

(2) PriorityQueue

PriorityQueue는 FIFO 구조가 아니라 우선순위에 따라 데이터가 나온다.

보통 Heap 자료구조를 사용한다.

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

pq.offer(5);
pq.offer(1);
pq.offer(3);

poll() 하면:

1
3
5

순서로 나온다.

중요:

내부 배열 전체가 완전히 정렬돼 있다는 뜻은 아니다.

Heap의 규칙에 따라 우선순위가 가장 높은 값에 빠르게 접근할 수 있도록 구성된 것이다.

삽입/삭제:

O(log n)

최솟값 조회:

O(1)

5️⃣ Map

Map은:

Key → Value

형태로 데이터를 저장한다.

Map<Long, User> users = new HashMap<>();

users.put(1L, user);

조회:

User user = users.get(1L);

특징:

Key 중복 X
Value 중복 O

예:

1 → Kim
2 → Lee
3 → Kim

Value "Kim"은 여러 개 존재할 수 있다.

(1) HashMap

일반적인 조회:

map.get(key);

평균 시간복잡도는:

O(1)

이다.

하지만 항상 O(1)은 아니다.

Hash Collision이 발생할 수 있기 때문이다.

이건 다음 단계에서:

Bucket
Hash Collision
Linked List
Red-Black Tree
Load Factor
Resize

까지 연결해서 깊게 볼 거다.

6️⃣ ArrayDeque

Stack이나 Queue가 필요하면 Java에서는 ArrayDeque도 매우 중요하다.

Deque<Integer> stack = new ArrayDeque<>();

stack.push(1);
stack.push(2);

stack.pop();

Stack처럼 사용할 수도 있고:

Deque<Integer> queue = new ArrayDeque<>();

queue.offer(1);
queue.offer(2);

queue.poll();

Queue로 사용할 수도 있다.

과거에는:

Stack<Integer> stack = new Stack<>();

을 많이 사용했지만 Stack은 오래된 클래스이며 Vector를 상속하고 있기 때문에 일반적으로는 Deque 사용을 권장한다.

String / equals / hashCode

KongJiHoon — Sat, 26 Sep 2026 17:09:53 +0900

전체 흐름 요약

1️⃣ String

String은 문자열을 표현하는 Java 클래스이다.

String name = "Jihoon";

중요한 특징은 String은 불변 객체(Immutable Object)다.

예를 들어,

String str = "hello";
str = str + " world";

겉으로는 기존 문자열이 수정된 것처럼 보이지만 실제로는 새로운 String 객체가 생성되고, str이 새로운 객체를 참조하게 된다.

(1) String이 불변 객체인 이유

대표적인 이유는

String Pool 활용
Thread Safety
Hash 값의 안정성
보안
캐싱 가능

등이 있다.

특히 HashMap과 연결된다.

Map<String, User> map = new HashMap<>();

만약 String이 변경이 가능하다면

key의 값 변경 -> hashCode 변경 -> 기존 Bucket과 불일치 -> 데이터를 못 찾을 가능성

이 생길 수 있다.

String이 불변이기 때문에 key로 사용하기 좋다.

(2) String Pool

Java에서 문자열 리터럴을 효율적으로 재사용하기 위해 String Pool을 사용한다.

String a = "hello";
String b = "hello";

이 경우 보통 같은 String Pool 객체를 참조한다. 따라서

a == b -> true

가 성립된다.

하지만 new String();은 다르다.

String a = "hello";
String b = new String("hello");

위 구조는 개념적으로 new 생성자로 새로운 객체를 생성하기 때문에 다음과 같다.

그래서

a == b -> false

하지만

a.equals(b);

는 true다. 왜냐하면 두 비교 방법이 다르기 때문이다.

2️⃣ == vs equals()

(1) == 동등 연산자

동등 연산자는 참조 타입에서 두 참조가 같은 객체를 가리키는지 비교하는 방식이다.

User a = new User("kim");
User b = new User("kim");

a == b; // false

위와 같이 new 생성자로 객체를 생성하면 객체가 서로 다르기 때문에 false가 반환된다.

(2) equals()

객체의 논리적인 동등성을 비교하기 위해 사용된다.

String에서는 문자열 내용이 같은지를 비교하도록 equals()가 이미 재정의되어 있다.

String a = new String("hello");
String b = new String("hello");

a.equals(b); // true

한 문장으로

==는 참조값을 비교하고, equals()는 객체의 논리적 동등성을 비교한다.

3️⃣ Object.equals()

Object는 모든 Java 클래스의 최상위 부모 객체이다.

Object에는

public boolean equals(Object obj)

메서드가 존재한다.

그런데 기본 Object.equals()는 사실상 동일 객체인지 비교하는 방식이다.

그래서 직접 만든 클래스에서

User user1 = new User(1L, "kim");
User user2 = new User(1L, "kim");

두 객체를 논리적으로 같은 사용자로 판단하고 싶다면 equals()를 재정의 해야한다.

(1) equals() 재정의

예를 들어

public class User {

    private Long id;

    @Override
    public boolean equals(Object o) {

        if (this == o) {
            return true;
        }

        if (!(o instanceof User user)) {
            return false;
        }

        return Objects.equals(id, user.id);
    }
}

위의 코드는를 하나씩 봐보면

this == o -> 같은 메모리상의 객체를 가리키는지 확인한다.

instanceof User -> 비교대상이 같은 객체가 아니라면 사용할 수 없다고 판다.

Object.equals(this.id, user.id) -> id값이 같은지를 비교

위와 같은 재정의를 통해 논리적인 기준으로 비교할 수 있게된다.

(2) hashCode()

hashCode()는 객체를 나타내는 정수형 해시 값을 반환한다.

대표적으로:

HashMap
HashSet

같은 자료구조에서 사용된다.

예를 들어 HashMap은 대략:

위와 같은 순서로 key를 찾는다.

(3) equals와 hashCode의 계약

Java 규약상 eqauls()가 true인 두 객체는 반드시 같은 hashCode를 가져야한다.

즉

a.equals(b) == true 라면
a.hashCode() == b.hashCode()

가 성립해야 한다.

하지만 반대는 반드시 성립하지 않는다.

hashCode가 같다고해서 equals도 true인 것은 아니다.

이것이 바로 Hash Collision 가능성 때문이다.

Hash Collision이란?

해시 충돌은 서로 다른 개체인데도 hashCode() 결과가 같은 경우를 말한다.

예를 들어

User user1 = new User(1L, "Kim");
User user2 = new User(2L, "Lee");

두 객체는 서로 다른 객체인데 우연히

user1.hashCode() == 12345
user2.hashCode() == 12345

처럼 같은 해시값이 나올 수가 있다.

중요한 점은 hashCode가 같다고 해서 equals까지 같은 것은 아니다.

예를 들어 HashSet에 다음과 같은 객체를 넣는다고 가정해보자.

Set<User> users = new HashSet<>();

users.add(user1);
users.add(user2);

만약 두 객체의 hashCode()가 같다면 둘 다 같은 버킷 후보로 들어간다. 그런데 거기서 끝나는 것이 아니라 equals()를 다시 확인한다.

user1.hashCode() == user2.hashCode() // true
user1.equals(user2); // false

이 경우 HashSet은 해시값은 같지만 다른 객체로 간주한다.

(4) 둘을 같이 재정의해야 되는 이유

예를 들어:

User user1 = new User(1L);
User user2 = new User(1L);

equals()만 재정의해서:

user1.equals(user2); // true

가 되었다고 하자.

그런데 hashCode()가 서로 다르면

HashSet에서는 서로 다른 위치로 들어갈 수 있다.

Set<User> users = new HashSet<>();

users.add(user1);
users.add(user2);

논리적으로 동일 객체인데 중복 저장되는 문제가 생길 수 있다.

따라서 equals()를 재정의하면 hashCode()도 같은 기준으로 재정의해야 한다.

4️⃣ StringBuilder와 StringBuffer

String은 불변 객체라서 반복적으로 문자열을 변경하면 객체가 계속 생성되어 메모리가 낭비될 수 있다.

String result = "";

for (int i = 0; i < 10000; i++) {
    result += i;
}

위와 같은 경우 수많은 String 객체가 생성될 수 있다.

이럴 때 사용하는 것이 StringBuilder와 StringBuffer이다.

StringBuilder sb = new StringBuilder();

for (int i = 0; i < 10000; i++) {
    sb.append(i);
}

String result = sb.toString();

둘 다 가변 문자열을 처리한다.

차이점은 Thread Safety 제공 여부이다.

구분	StringBuilder	StringBuffer
가변 객체	O	O
Thread Safe	X	O
synchronized	X	O
일반적인 성능	상대적으로 빠름	상대적으로 느림
일반적인 용도	단일 스레드	여러 스레드 공유

일반적인 Local 문자열 조합에서는 StringBuilder를 주로 사용한다.

StringBuffer는 메서드에 동기화가 적용되어 있기 때문에 멀티 스레드 환경에서 공유할 경우 Thread Safety를 제공한다.

다만:

멀티스레드 애플리케이션이면 무조건 StringBuffer를 써야 한다.

는 아니다.

로컬 변수로 사용하는 StringBuilder라면 여러 요청 스레드가 같은 객체를 공유하지 않으므로 문제가 없다.

Thread Safety란?

Thread Safty, 즉 스레드 안정성은 여러 스레드가 동시에 같은 객체나 데이터에 접근하더라도 프로그램이 의도한 대로 정확하게 동작하는 성질이다.

예를 들어 다음과 같은 코드가 있다고 해보자.

public class Counter {

    private int count = 0;

    public void increase() {
        count++;
    }
}

그리고 두 스레드가 동시에 increase()를 호출한다고 가정해보면

겉으로 보면 count++ 한 줄이라 안전해 보이지만 실제로는 대략 다음과 같이 동작한다.

1. count 값을 읽음
2. count + 1 계산
3. 결과를 count에 저장

만약 현재 count=0이고 두 스레드가 동시에 실행되면

Thread A: count 읽음 -> 0
Thread B: count 읽음 -> 0

Thread A: 0 + 1 = 1
Thread B: 0 + 1 = 1

Thread A: count = 1
Thread B: count = 1

원래 기대값은:

인데 실제 결과는:

이 될 수 있다.

이런 현상이 바로 프로젝트에서 경험한 Race Condition(경쟁 상태)이다.

그래서 이 코드는 Thread Safe하지 않다고 표현한다.

반대로 다음과 같이 동기화를 걸 수 있다.

public class Counter {

    private int count = 0;

    public synchronized void increase() {
        count++;
    }
}

synchronized를 사용하면 한 순간에 한 스레드만 접근하도록 제한할 수 있다.

Thread A → increase() 실행
Thread B → 대기

Thread A 종료
Thread B → increase() 실행

결과적으로:

0 → 1 → 2

Thread Safety를 이해할 때 중요한 건 공유 상태(shared mutable state)다.

문제는 보통 다음과 같은 조건에서 발생한다.

여러 스레드 -> 같은 데이터 접근 -> 그 데이터를 변경 -> 동시에 실행 -> Race Condition 가능

반면, 공유되는 변경 가능한 상태가 없다면 Thread Safety를 확보하기 쉽다.

예를 들어

public int add(int a, int b) {
    return a + b;
}

이 메서드는 지역 변수와 매게 변수만 사용한다. 각 스레드의 스택에 따로 저장되기 때문에 여러 스레드가 동시 접근해도 서로 영향을 주지 않는다.

Thread Safety란 여러 스레드가 동시에 동일한 자원에 접근하더라도 데이터의 일관성과 프로그램의 정상적인 동작이 보장되는 것을 의미합니다.
공유되는 변경 가능한 상태가 있을 경우 Race Condition이 발생할 수 있으며, 이를 방지하기 위해 synchronized, Lock, Atomic 클래스, ConcurrentHashMap 등을 사용할 수 있습니다.
또한 Spring의 Singleton Bean처럼 여러 요청 스레드가 하나의 객체를 공유하는 환경에서는 상태를 필드에 저장하지 않고 지역 변수 중심으로 설계하는 것도 중요합니다.

객체 지향 프로그래밍

KongJiHoon — Sat, 26 Sep 2026 05:07:45 +0900

1️⃣ 객체 지향 프로그래밍

객체 지향 프로그래밍(Objecy-Oriented Programming)은 프로그램을 단순한 명령어의 집합으로 보기보다는

상태와 행동을 가진 객체들의 협력으로 프로그램을 구성하는 방식이다.

예를 들어, 농구 매칭 서비스를 절차적으로 생각하면

사용자 조회
-> 경기 조회
-> 참가 가능한지 검사
-> 참가자 추가
-> 참가자 수 증가

객체지향적으로 보면 각각의 객체가 자신의 책임을 가진다.

class Game {

    private int headCount;
    private int participantCount;

    public void join() {
        if (participantCount >= headCount) {
            throw new IllegalStateException("모집이 완료되었습니다.");
        }

        participantCount++;
    }
}

이 경우 Game도메인이 자신의 상태인 participantCount를 관리한다.

핵심은:

객체가 자신의 상태와 행동을 함께 가지고, 다른 객체와 메시지를 주고받으며 프로그램을 구성한다.

정리 하자면

객체지향 프로그래밍은 프로그램을 상태와 행동을 가진 객체들의 협력으로 구성하는 프로그래밍 방식입니다. 각 객체에 책임을 분배하고 객체 간의 의존성을 적절하게 관리함으로써 변경에 유연하고 유지보수하기 좋은 코드를 만드는 것을 목표로 합니다.

(1) 클래스와 객체의 차이

클래스는 객체를 만들기위한 설계도 또는 타입이고, 객체는 클래스를 기반으로 실제 메모리에 생성된 인스턴스이다.

class User {

    private String name;

    public User(String name) {
        this.name = name;
    }
}

그리고

User user1 = new User("지훈");
User user2 = new User("철수");

User는 클래스이고, new 생성자에 의해 호출되는 것이 바로 객체이다.

user1, user2는 각각 별도의 객체이다.

2️⃣ 객체지향의 4가지 특징

객체지향 4대 특징

캡슐화
추상화
상속
다형성

(1) 캡슐화

캡슐화는 객체와 상태와 행동을 하나로 묶고, 내부 구현을 외부에서 함부로 수정하지 못하도록 제한하는 특징이다.

나쁜 예

public class Game {

    public int participantCount;
}

위와 같이 public 접근제어자로 변수를 생성 시에 외부에서 아래와 같이

game.participantCount = -100;

변경이 가능하여 객체의 상태가 깨진다.

그래서:

public class Game {

    private int participantCount;

    public void join() {

        if (participantCount >= 10) {
            throw new IllegalStateException();
        }

        participantCount++;
    }
}

외부에서는 game.join()만 호출한다.

외부

game.join()
    ↓
┌──────────────────────┐
│ Game                 │
│                      │
│ participantCount     │
│     ↓                │
│ validate → 증가      │
└──────────────────────┘

객체 내부의 구체적인 처리 방법은 외부에서 알 필요가 없다.

캡슐화는 객체의 상태와 행동을 하나로 묶고 내부 구현을 외부로부터 숨기는 것입니다. 단순히 필드를 private으로 만드는 것뿐 아니라, 객체의 상태를 외부에서 직접 변경하지 못하게 하고 의미 있는 메서드를 통해 상태를 변경하도록 만들어 객체의 무결성을 유지하는 것이 중요하다고 생각합니다.

(2) 추상화

추상화는 복잡한 내부 구현을 모두 노출하지 않고, 사용자에게 필요한 핵심 기능만 표현하는 것이다.

예를 들어 자동차를 운전한다고 생각하면

운전자는

엔진 연료 분사, 점화 타이밍, 변속기 내부 구조

를 알 필요가 없고

그냥 시동, 가속, 브레이크만 알면 된다.

Java 코드로 보면

interface Payment {

    void pay(int amount);
}

위와 같은 코드가 있다면 사용자는

payment.pay(10000);

만 알면 된다.

내부에서는

카드사 API 호출 -> 인증 -> 승인 -> 결제 기록

같은 복잡한 작업이 존재할 수 있다.

캡슐화와 추상화 차이

헷갈리기 쉽다.

캡슐화
→ 내부 상태와 구현을 보호

추상화
→ 필요한 핵심만 외부에 노출

둘은 서로 관련 있지만 같은 개념은 아니다.

(3) 상속

상속은 부모 클래스의 특성과 기능을 자식 클래스가 물려받아 사용할 수 있도록 하는 특징입니다.

class Animal {

    public void eat() {
        System.out.println("먹는다");
    }
}

class Dog extends Animal {

    public void bark() {
        System.out.println("멍멍");
    }
}

그러면:

Dog dog = new Dog();

dog.eat();
dog.bark();

가능하다.

구조는:

        Animal
          ↑
          │
         Dog

이것을 IS-A 관계라고 표현하기도 한다.

‼️ 상속의 문제점

상속에는 강한 결합이라는 문제가 있다.

예를 들어:

class Parent {

    protected void calculate() {
    }
}

자식:

class Child extends Parent {

    public void execute() {
        calculate();
    }
}

부모의 구현이 변경되면 자식 클래스의 동작까지 영향을 받을 수 있다.

즉

Parent 변경 -> Child 영향 -> GrandChild 영향

계층이 깊어질수록 유지보수가 어려워질 수 있다는 단점이 있다.

Composition(조합)

Composition은 객체가 다른 객체를 필드로 가지고 기능을 사용하는 방식이다.

예를들어, 아래와 같이 Engine 클래스가 존재하고 Car클래스는 Engine클래스를 필드로 가진다.

class Engine {

    public void start() {
        System.out.println("엔진 시작");
    }
}

class Car {

    private final Engine engine;

    public Car(Engine engine) {
        this.engine = engine;
    }

    public void start() {
        engine.start();
    }
}

관계는:

Car
 │
 └── has Engine

상속:

IS-A

조합:

HAS-A

조합은 구현체를 쉽게 바꾸는 것도 가능하다.

Car car = new Car(new GasolineEngine());

또는:

Car car = new Car(new ElectricEngine());

이 구조가 Spring의 DI와 매우 가까워진다.

(4) 다형성

다형성은 같은 타입으로 여러 구현 객체를 사용할 수 있는 성질이다.

예를 들어:

interface Payment {

    void pay();
}

구현체:

class CardPayment implements Payment {

    @Override
    public void pay() {
        System.out.println("카드 결제");
    }
}

class KakaoPayment implements Payment {

    @Override
    public void pay() {
        System.out.println("카카오 결제");
    }

그러면

Payment payment;

라는 하나의 타입으로

payment = new CartPayment();
payment = new KakaoPayment();

여러 구현 객체를 사용할 수 있다.

             Payment

            pay()

          ↙       ↘

CardPayment       KakaoPayment

호출자는:

payment.pay();

만 알면 된다.

구현체가 무엇인지 몰라도 된다.

다형성의 중요성

다형성의 핵심은 변경에 대한 영향도를 줄이는 것이다.

예를 들어 다음과 같은 코드가 존재한다.

class OrderService {
	private CardPayment cardPayment;
}

OrderService가 CardPayment 객체에 직접 의존한다.

그러면 나중에 KakaoPayment로 변경하면 OrderService를 직접 수정해야 한다.

그런데

class OrderService {

	private final Payment payment;
    
    public OrderService(Payment payment) {
    	this.payment = payment;
    }
    
}

이렇게 하면 OrderService는 구현체 변경을 몰라도 된다.

이게 다형성 + 추상화 + DI의 핵심이다.

OrderService
     ↓
 Payment
   ↙     ↘
Card   Kakao

Spring과 다형성

예를 들어

public interface NotificationService {

    void send(String message);
}

구현체:

@Service
public class EmailNotificationService
        implements NotificationService {

    @Override
    public void send(String message) {
    }
}

그리고

@Service
@RequiredArgsConstructor
public class GameService {

    private final NotificationService notificationService;
}

GameService가 EmailNotificationService라는 구현체에 직접 의존하지 않고 NotificationService라는 추상화된 객체에 의존한다.

Spring Container가 구현체를 주입해준다.

즉:

객체지향 다형성
       ↓
Interface
       ↓
DI
       ↓
Spring IoC Container

로 연결된다.

Spring이 객체지향을 잘 활용한다고 생각하는 이유?

Spring에서는 인터페이스를 기반으로 구현체를 분리하고, IoC 컨테이너가 구현 객체를 주입해주는 DI 구조를 사용하기 쉽습니다. 따라서 클라이언트 코드가 구체 구현보다 추상화에 의존하도록 만들 수 있고, 구현체 변경에 대한 영향을 줄일 수 있다는 점에서 객체지향의 다형성을 잘 활용할 수 있다고 생각합니다.

3️⃣ 오버로딩과 오버라이딩

(1) Overloading

오버로딩은 같은 클래스에서 메서드 이름은 같고 매게변수는 다르게 정의하는 것이다.

public int add(int a, int b) {
    return a + b;
}

public int add(int a, int b, int c) {
    return a + b + c;
}

public double add(double a, double b) {
    return a + b;
}

메서드 이름:

add

는 동일하지만 매개변수가 다르다.

판단 기준은

매개변수 개수
매개변수 타입
매개변수 순서

중 하나가 달라야 한다.

반환 타입만 다르게 하면 오버로딩되지 않는다.

Java 소스코드는 컴파일 시점에 타입을 검사하므로 컴파일러 입장에서 호출할 때,

test();

어떤 메서드인지 판단할 수 없기 떄문이다.

(2) Overriding

오버라이딩은 부모나 인터페이스에서 정의한 메서드를 자식 클래스에서 다시 구현하는 것이다.

interface Payment {

    void pay();
}

class CardPayment implements Payment {

    @Override
    public void pay() {
        System.out.println("카드 결제");
    }
}

다형성과 직접 연결된다.

Payment payment = new CardPayment();

payment.pay();

참조 타입은:

Payment

이지만 실제 실행되는 것은:

CardPayment.pay()

이다.

오버로딩 vs 오버라이딩

구분	Overloading	Overriding
위치	같은 클래스 중심	상속/인터페이스 관계
메서드명	동일	동일
매개변수	달라야 함	동일
목적	같은 기능의 여러 형태	부모 동작 재정의
결정 시점	주로 컴파일 타임	런타임 다형성과 연결

4️⃣ 추상 클래스와 인터페이스

(1) 추상 클래스

추상 클래스는

abstract class Payment {

    protected String name;

    public void print() {
        System.out.println(name);
    }

    public abstract void pay();
}

위와 같이 일반 메서드와 추상 메서드를 가질 수 있다.

자식 클래스

class CardPayment extends Payment {

    @Override
    public void pay() {
    }
}

하지만 직접 인스턴스를 만들 수는 없다.

new Payment(); // 불가능

(2) 인터페이스

인터페이스는 객체가 어떤 행동을 제공해야 하는지 계약을 정의하는 역할로 많이 사용한다.

interface Payment {

    void pay();
}

구현:

class CardPayment implements Payment {
}

Java에서는 여러 인터페이스를 구현할 수 있다.

class UserService
        implements UserReader, UserWriter {
}

반면 클래스 상속은 하나만 가능하다.

class Child extends Parent

인터페이스는 주로 객체가 제공해야 하는 역할이나 계약을 정의하고, 서로 다른 클래스에 동일한 추상화를 제공할 때 사용합니다.

반면 추상 클래스는 상속 관계에 있는 클래스들이 공통 상태나 구현을 공유해야 할 때 사용할 수 있습니다.
Java에서는 클래스는 하나만 상속할 수 있지만 여러 인터페이스를 구현할 수 있기 때문에, 구현체를 교체하거나 확장해야 하는 구조에서는 인터페이스를 주로 활용합니다.

Java 컴파일 과정

KongJiHoon — Sat, 26 Sep 2026 04:12:52 +0900

1️⃣ JDK/ JRE/ JVM의 차이

가장 큰 구조는 아래와 같다.

JDK
├── 개발 도구
│   ├── javac
│   ├── javadoc
│   └── jar ...
│
└── Java 실행 환경
    ├── Java 표준 라이브러리
    └── JVM

(1) JVM(Java Virtual Machine)

Java 바이트코드를 실제 실행시키는 가상 머신이다.

예를 들어 Jav 소스 코드를 컴파일 하면

Hello.java -> Hello.class

.class파일에는 CPU가 바로 이해하는 기계어가 아닌 Java Bytecode가 들어 있다.

이걸 JVM이 실행한다.

Hello.java -> Hello.class -> JVM -> Window/ Linux/ macOS

운영체제별 JVM은 서로 다르지만 바이트코드로 변환되어 JVM에 의해 실행되므로 플랫폼 독립성이 높다.

주요 기능

Bytecode 실행
메모리 관리
GC 수행
클래스 로딩
JIT 컴파일
런타임 환경 제공

(2) JRE(Java Runtime Environment)

JRE는 말 그대로 Java 프로그램을 실행하기 위한 환경이다.

전통적으로 보면

JRE
├── JVM
└── Java Library

JVM만 있다고 Java 프로그램을 정상적으로 실행할 수 있는 것은 아니다.

예를 들어 우리가 사용하는

String
ArrayList
HashMap
LocalDateTime

같은 Java 표준 라이브러리도 필요하다.

그래서 개념적으로

JVM + Java 실행에 필요한 라이브러리 = JRE

라고 이해하면 된다.

(3) JDK(Java Development Kit)

JDK는 Java 프로그램을 개발하기 위한 도구의 모음이다.

JDK
├── Java 실행 환경
│    ├── JVM
│    └── Java Library
│
└── 개발 도구
     ├── javac
     ├── jar
     ├── javadoc
     └── jdb 등

예를들어, IntelliJ에서 Java 17을 설정할 때 설치하는 것이 바로 JDK17이다.

특히 중요한 도구가

javac -> Java Compiler

프로그램 실행 시 javac에 의해

Hello.java -> Hello.class

로 Bytecode로 변환된다.

구분	역할	주요 구성
JVM	Bytecode 실행	Class Loader, Execution Engine, Runtime Memory 등
JRE	Java 프로그램 실행 환경	JVM + 실행 라이브러리
JDK	Java 프로그램 개발 환경	실행 환경 + javac 등 개발 도구

2️⃣ Java 컴파일 및 실행 과정

Java Source Code
      ↓
    javac
      ↓
Java Bytecode
   (.class)
      ↓
 Class Loader
      ↓
Bytecode Verification
      ↓
JVM Runtime Data Area
      ↓
Execution Engine
 ├─ Interpreter
 └─ JIT Compiler
      ↓
 Native Machine Code
      ↓
      CPU

(1) Java Source Code 작성

예를 들어,

pulic class Hello {

	public static void main(String[] args) {
    
    	System.out.println("Hello");
    }
}

파일:

Hello.java

(2) javac가 컴파일한다.

JDK의 Java Compiler인 javac가 소스 코드를 컴파일 한다.

javac Hello.java -> Hello.class

Java 소스 코드는 여기서 바로 CPU 기계어로 변환되는 것이 아닌 Java Bytecode로 변환된다.

(3) JVM의 Class Loader가 .class를 로딩

JVM이 실행되면 Class Loader가 필요한 .class 파일을 JVM메모리로 가져온다.

Hello.class -> Class Loader -> JVM

(4) Bytecode 검증

JVM에서는 로딩된 Bytecode가 안전한 지 검사한다.

예를 들어,

잘못된 Bytecode인지
JVM 규칙을 위반하지 않는지
타입이 올바른지

등을 검증한다.

(5) JVM Runtime Data 영역에 배치

클래스에 객체, 메서드, 변수 실행 등에 필요한 데이터가 JVM 메모리 영역에서 관리된다.

JVM Runtime Data Area

┌─────────────────────┐
│       Heap          │ ← 객체
├─────────────────────┤
│  Method Area        │ ← 클래스 관련 정보
├─────────────────────┤
│       Stack         │ ← 메서드 호출 / 지역변수
├─────────────────────┤
│   PC Register       │
├─────────────────────┤
│ Native Method Stack │
└─────────────────────┘

JVM이 실행에 필요한 데이터를 여러 메모리 영역에 관리한다.

(6) Excuetion Engine이 Bytecode를 실행

이제 JVM의 Execution Engine이 Bytecode를 실행한다.

여기서 중요한 두 개:

Interpreter
JIT Compiler

Interpreter

Bytecode 명령을 읽어서 하나씩 실행한다.

Bytecode -> 한 줄씩 해석 -> 실행

장점:

바로 실행할 수 있다.

단점:

같은 코드를 반복 실행하면 계속 해석해야 한다.

JIT(Just In Time) Compiler

JVM이 프로그램을 실행하면서 자주 실행되는 코드를 발견하면 해당 Bytecode를 네이티브 코드로 컴파일할 수 있다.

Bytecode

    ↓ 처음

Interpreter
    ↓
실행

    ↓ 반복적으로 많이 실행됨

JIT Compiler
    ↓

Native Code
    ↓

CPU 직접 실행

예를 들어 서버에서 다음과 같은 코드를 수십만 번 실행한다고 가정해보자.

public GameResponse findGame(Long gameId)

매번 Bytecode를 하나씩 해석하는 것보다 네이티브 코드로 만들어 놓으면 이후 실행 성능을 높일 수 있다.

정리

Java 소스 코드는 JDK에 포함된 javac 컴파일러를 통해 JVM이 이해할 수 있는 Bytecode 형태의 .class 파일로 컴파일됩니다.
이후 JVM의 Class Loader가 필요한 클래스를 로딩하고 Bytecode를 검증한 뒤 JVM의 Runtime Data Area에서 관리합니다.

Execution Engine이 Bytecode를 실행하며, 처음에는 인터프리터 방식으로 실행할 수 있고 반복적으로 실행되는 코드는 JIT Compiler가 네이티브 코드로 컴파일하여 성능을 최적화합니다.

이진 탐색 트리(1)

KongJiHoon — Sat, 12 Sep 2026 19:56:37 +0900

1️⃣ 이진 탐색 트리(Binary Search Tree)

이진 탐색 트리(BST)는 데이터를 빠르게 탐색하기 위해 일정한 규칙에 따라 노드를 배치한 이진 트리이다.

일반적인 이진 트리는 단순히 "하나의 노드가 최대 2개의 자식을 가진다"는 조건만 만족한다.

반면 이진 탐색 트리는 다음과 같은 규칙이 추가된다.

부모보다 작은 값 → 왼쪽
부모보다 큰 값 → 오른쪽
왼쪽과 오른쪽의 서브 트리도 동일한 규칙을 만족
중복된 Key는 허용하지 않음

예를 들어 다음 값을 순서대로 삽입한다고 생각해보자.

20 → 10 → 30 → 1 → 15 → 25

20을 기준으로 보면 왼쪽에는 20보다 작은 값이 존재하고, 오른쪽에는 20보다 큰 값이 존재한다.

이 규칙 때문에 원하는 값을 찾을 때 어느 방향으로 가야 하는지를 판단할 수 있다.

(1) 탐색이 빠른 이유

일반 적인 트리에서 25라는 값이 어디 있는지 모른다면 여러 노드를 직접 확인해야 할 수 있다.

하지만 BST에서는 값의 크기를 비교한다.

즉, 매번 비교를 통해 탐색할 필요가 없는 영역을 제외할 수 있다.

(2) BST 탐색

BST의 탐색과정은 매우 단순하다.

현재 노드를 current, 찾고 싶은 값을 target이라고 하면 다음 세 가지 경우가 존재한다.

target == current
- 원하는 값을 찾았으므로 탐색 종료
target < current
- 현재 값보다 작으므로 왼쪽으로 이동
target > current
- 현재 값보다 크므로 오른쪽으로 이동

Java 코드로 구현하면 대략 다음과 같다.

public Node search(int key) {
    Node cur = head;
    
    
    while (cur != null) {
        
        if (cur.key == key) {
            return cur;
        }
        
        if (key < cur.key) {
            cur = cur.left;
        } else {
            cur = cur.right;
        }
        
    }
    
    return null;
    
}

2️⃣ BST 삽입

BST의 삽입 방법도 탐색과 거의 동일하다.

새로운 값 12를 삽입한다고 가정해보자.

기존 트리는 다음과 같다.

12와 20을 비교한다.

12 < 20

→ 왼쪽

12와 10을 비교한다.

12 > 10

→ 오른쪽

12와 15를 비교한다.

12 < 15

→ 왼쪽

15의 왼쪽이 비어 있으므로 여기에 삽입한다.

Java 코드로 구현하면 다음과 같다.

public Node addNodeRecursive(Node cur, int key) {

    if (cur == null) {
        // 삽입할 위치를 찾으면 새 Node에 key값을 저장해 반환한다.
        return new Node(key, null, null);
    }
    
    
    // 삽입 위치를 찾은경우 새Node가 반환되어 현재 위치에 오른쪽이나 왼쪽 위치에 배치해준다.
    if (key < cur.key) {
        cur.left = addNodeRecursive(cur.left, key);
    } else {
        cur.right = addNodeRecursive(cur.right, key);
    }

    return cur;
}

3️⃣ BST의 삭제

(1) 자식노드가 없는 경우

BST의 삭제가 삽입이나 탐색보다 어렵다. 삭제하는 노드의 자식 개수에 따라 처리 방법이 달라지기 때문이다.

첫 번째는 가장 간단한 경우다. 삭제할 노드가 Leaf Node라면 그냥 제거하면 된다.

예를 들어 다음 트리에서 15를 삭제한다.

15는 자식이 없다.

따라서 부모인 10이 가지고 있는 15에 대한 링크를 null로 변경하면 된다.

(2) 자식이 하나인 경우

두 번째는 삭제할 노드가 자식을 하나 가지고 있는 경우이다.

이 경우에는 삭제 대상의 자식을 삭제 대상의 부모와 연결한다.

예를 들어

여기서 15를 삭제한다면

15의 자식인 17을 10과 연결하면 된다.

10
 \
  17

즉

부모 → 삭제 대상 → 자식

구조를

부모 → 자식

으로 변경한다.

Java 코드로 작성하면 자식이 없는 경우와 자식이 하나인 경우는 아래와 같이 작성할 수 있다.

if (key < cur.key) {
    cur.left = removeNodeRecursive(cur.left, key);
} else if (key > cur.key){
    cur.right = removeNodeRecursive(cur.right, key);
} else {
    if (cur.left == null) {
        return cur.right;
    } else if (cur.right == null) {
        return cur.left;
    }

위와 같이 key값의 크기에 따라 재귀 호출로 이동하고 key값을 찾았을 때

현재 노드의 왼쪽 값이 null이면 오른쪽 값을 반환해주고, 오른쪽 값이 null이면 왼쪽값을 반환해준다.

자식이 없는경우는 두 검증 조건에서 한쪽이 없을 경우 다른 한쪽을 반환하는데 다른 한쪽도 null일 것이기 때문에 해당 조건으로 검증이 가능하다.

(3) 자식이 둘인 경우

가장 복잡한 경우이다. 삭제 대상이 왼쪽과 오른쪽 자식을 모두 가지고 있다면 단순히 노드를 없애면 BST의 규칙이 깨질 수 있다.

예를 들어

여기서 20을 삭제하고 싶다고 해보자. 20을 대신할 값으로 사용할 수 있는 대표적인 후보가 두 가지 있다.

방법 1

왼쪽 서브 트리에서 가장 큰 값

→ 15

방법 2

오른쪽 서브 트리에서 가장 작은 값

→ 25
이 두 방법 중 하나를 선택하여 삭제 대상의 위치로 올리는 방식을 사용하면 된다.

Java 코드로 설명하자면

Node predecessor = cur;
Node successor = cur.left;

while (successor.right != null) {
    predecessor = successor;
    successor = successor.right;
}

predecessor.right = successor.left;
cur.key = successor.key;

위 경우는 왼쪽 방향에서 탐색하는 경우이다.

삭제할 노드의 왼쪽 서브트리에서 가장 큰 노드를 찾고, 그 노드의 값을 삭제 대상 노드에 복사한 뒤, 원래 위치에 있던 해당 노드를 제거하면서 왼쪽 자식이 있다면 부모 노드에 연결한다.

BST의 시간 복잡도

BST의 탐색, 삽입, 삭제는 기본적으로 루트에서 아래 방향으로 내려간다. 따라서 시간 복잡도는 트리의 높이 h에 영향을 받는다.

일반적으로는O(h) 라고 표현하는 것이 가장 정확하다.

트리가 균형 잡혀 있다면

       20
      /  \
    10    30
   / \    / \
  5  15  25  40

높이는 대략 log N이 된다.

따라서

탐색 : O(log N)

삽입 : O(log N)

삭제 : O(log N)

이 가능하다.

프로그래머스 Lv3 - 여행경로

KongJiHoon — Wed, 9 Sep 2026 19:58:25 +0900

출처 : https://school.programmers.co.kr/learn/courses/30/lessons/43164

코딩테스트 연습 - 여행경로

알고리즘 문제 연습 카카오톡 친구해요! 프로그래머스 교육 카카오 채널을 만들었어요. 여기를 눌러, 친구 추가를 해주세요. 신규 교육 과정 소식은 물론 다양한 이벤트 소식을 가장 먼저 알려

school.programmers.co.kr

1️⃣ 문제 요약

주어진 항공권을 모두 사용하여 여행 경로를 만드는 문제이다.

항상 "ICN" 공항에서 출발하며, 하나의 항공권은 한 번만 사용할 수 있다. 모든 항공권을 사용한 가능한 경로가 여러 개 존재할 경우, 알파벳 사전순으로 가장 앞서는 경로를 반환해야 한다.

이 문제에서 중요한 점은 공항의 방문 여부가 아니라 항공권의 사용 여부를 관리해야 한다는 것이다.

동일한 공항을 여러 번 방문할 수 있고, 같은 출발지와 도착지를 가지는 항공권도 여러 장 존재할 수 있기 때문에 visited 배열은 공항이 아닌 항공권의 인덱스를 기준으로 관리한다.

2️⃣ 문제 풀이

DFS와 백트래킹을 이용해서 여행 경로를 탐색하면되는 문제이다.

다만 가능한 모든 경로를 저장한 뒤 정렬하는 방식이 아니라, 처음부터 제공되는 tickets를 사전순으로 정렬한 뒤에 탐색한다.

먼저 항공권을 출발지 기준으로 정렬하고, 출발지가 같다면 도착지 기준으로 정렬한다.

Arrays.sort(tickets, (a, b) -> {
    if (a[0].equals(b[0])) {
        return a[1].compareTo(b[1]);
    }

    return a[0].compareTo(b[0]);
});

여행은 항상 "ICN"에서 시작하므로 처음 경로에 "ICN"을 추가하고 방문 여부를 체크해줄 visited 배열을 생성해준다.

routes.add("ICN");

visited = new boolean[tickets.length];

DFS에서는 현재 공항 cur에서 출발할 수 있는 항공권을 찾는다.

이미 사용한 항공권이라면 사용할 수 없다.

if (visited[i]) {
    continue;
}

현재 공항과 항공권의 출발지가 다르면 사용할 수 없는 항공권이므로 넘어간다.

if (!tickets[i][0].equals(cur)) {
    continue;
}

사용 가능한 항공권이라면 해당 항공권을 사용 처리하고 도착지를 현재 여행 경로에 추가한다.

visited[i] = true;
routes.add(tickets[i][1]);

이후 도착지를 새로운 현재 공항으로 설정하고 DFS를 진행한다.

모든 항공권을 사용했다면 하나의 완전한 여행 경로가 만들어진다.

이 때 true를 반환하여 더 이상 경로를 탐색하지 않게한다.

항공권을 미리 사전순으로 정렬했기 때문에 DFS에서 처음으로 완성된 여행 경로가 문제에서 요구한 가장 앞선 경로가 된다.

if (count == tickets.length) {
    return true;
}

전체 코드

import java.util.ArrayList;
import java.util.Arrays;

class Solution {

    boolean[] visited;
    ArrayList<String> routes = new ArrayList<>();


    public String[] solution(String[][] tickets) {

        Arrays.sort(tickets, (a, b) -> {
            if (a[0].equals(b[0])) {
                return a[1].compareTo(b[1]);
            }

            return a[0].compareTo(b[0]);
        });

        routes.add("ICN");

        visited = new boolean[tickets.length];

        dfs("ICN", 0, tickets);

        return routes.toArray(new String[0]);
    }

    private boolean dfs(String cur, int count, String[][] tickets) {

        if (count == tickets.length) {

            return true;
        }

        for (int i = 0; i < tickets.length; i++) {

            if (visited[i]) {
                continue;
            }

            if (!tickets[i][0].equals(cur)) {
                continue;
            }

            visited[i] = true;
            routes.add(tickets[i][1]);

            if (dfs(tickets[i][1], count + 1, tickets)) {
                return true;
            }

            routes.remove(routes.size() - 1);
            visited[i] = false;


        }

        return false;
    }
}

프로그래머스 Lv3 - 아이템 줍기

KongJiHoon — Tue, 8 Sep 2026 17:54:16 +0900

출처 : https://school.programmers.co.kr/learn/courses/30/lessons/87694

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

1️⃣ 문제 요약

여러 개의 직사각형이 겹쳐 만들어진 다각형 지형이 주어진다.

캐릭터는 직사각형 내부를 이동할 수 없고, 겹쳐진 직사각형들로 만들어진 다각형의 바깥 테두리만 따라 이동할 수 있다.

캐릭터의 시작 위치와 아이템의 위치가 주어졌을 때, 테두리를 따라 아이템까지 이동하는 최단거리를 구해야 한다.

2️⃣ 문제 풀이

문제는 크게 세 단계로 풀이할 수 있다.

1. 모든 직사각형의 영역을 채운다.

2. 직사각형 내부의 영역 0으로 채워 테두리만 1로 남긴다.

3. 남아 있는 테두리를 BFS로 탐색해 최단거리를 구한다.

이 문제에서 가장 이해가 어려웠던 것이 좌표를 2배로 확대하는 부분이다.

단순히 원래 좌표 그대로 테두리를 만들면, 실제로는 연결되어 있지 않은 두 테두리가 배열에서는 붙어 있는 것처럼 표현되는 문제가 발생한다.

예를 들어 실제 경로가 다음과 같을 때

(1,2) - (2,2)
  |       |
(1,1) - (2,1)

실제 경로는 위 → 오른쪽 → 아래로 이동해야 하지만 좌표상으로는 인접해 있기 떄문에 바로 오른쪽으로 이동할 수가 있다 따라서

좌표를 2배로 설정하면

(2,4) --------- (4,4)
  |               |
(2,2) - (3,2) - (4,2)

아래 좌표가 하나 더 생겨 원래 경로대로 움직일 수 있다.

int x1 = rect[0] * 2;
int y1 = rect[1] * 2;
int x2 = rect[2] * 2;
int y2 = rect[3] * 2;

좌표를 2배로 만들면 기존 좌표 사이에 새로운 공간이 생기기 때문에 서로 붙어 있던 경로를 명확하게 구분할 수 있다.

(1) 모든 직사각형을 1로 채운다.

int형 배열은 좌표의 최대 수가 50이기 때문에 102로 잡아주고 각각의 좌표를 지나간 적이 있는지를 판별할 boolean배열도 생성해준다.

private final int[][] map = new int[102][102];
private final boolean[][] visited = new boolean[102][102];

그 후 아래와 같이 해당 직사각형을 1로 채워준다.

for (int i = x1; i <= x2; i++) {
    for (int j = y1; j <= y2; j++) {
        map[i][j] = 1;
    }
}

(2) 직사각형 안을 0으로 채운다.

캐릭터가 이동할 수 있는 곳은 테두리뿐이다.

따라서 각 직사각형의 가장자리 한 칸을 제외하고 내부를 모두 0으로 만든다.

for (int i = x1 + 1; i < x2; i++) {
    for (int j = y1 + 1; j < y2; j++) {
        map[i][j] = 0;
    }
}

여기서 중요한 점은

x1 + 1
y1 + 1

부터 시작하고

i < x2
j < y2

까지만 처리한다는 것이다. 즉, 테두리는 건드리지 않고 내부만 제거한다.

(3) BFS 최단거리 탐색

테두리가 만들어졌다면 일반적인 격자 BFS 문제와 동일해진다.

시작 위치도 마찬가지로 2배 좌표를 사용한다.

return bfs(
        characterX * 2,
        characterY * 2,
        itemX * 2,
        itemY * 2
);

BFS 큐에는

{x, y, distance}

를 저장한다.

queue.offer(new int[]{
        characterX,
        characterY,
        0
});

그리고 시작 위치를 방문 처리한다.

visited[characterX][characterY] = true;

그 후에 상하좌우를 이동하면서 조건을 만족하는 좌표를 Queue에 넣어준다.

조건

배열 범위를 벗어나면 안된다.
이미 방문한 좌표는 다시 방문하지 않는다.
테두리인 경우에만 이동한다.

for (int i = 0; i < 4; i++) {

    int nx = x + dx[i];
    int ny = y + dy[i];

    if (nx < 0 || nx >= 102 || ny < 0 || ny >= 102) {
        continue;
    }

    if (visited[nx][ny]) {
        continue;
    }

    if (map[nx][ny] != 1) {
        continue;
    }

    visited[nx][ny] = true;

    queue.offer(new int[]{nx, ny, distance + 1});

}

전체 코드

import java.util.ArrayDeque;
import java.util.Queue;

class Solution {

    private final int[][] map = new int[102][102];
    private final boolean[][] visited = new boolean[102][102];

    private final int[] dx = {-1, 1, 0, 0};
    private final int[] dy = {0, 0, -1, 1};

    public int solution(int[][] rectangle, int characterX, int characterY, int itemX, int itemY) {


        for (int[] rect : rectangle) {

            /*
             * 직사각형 안을 모두 1로 채운다.
             * ㄷ자 경로에서 인접값이 존재하면 지름길 형성이 될 수 있으므로
             * 직사각형을 2배 키워서 좌표사이에 좌표를 생성해준다.
             */
            int x1 = rect[0] * 2;
            int y1 = rect[1] * 2;
            int x2 = rect[2] * 2;
            int y2 = rect[3] * 2;

            for (int i = x1; i <= x2; i++) {
                for (int j = y1; j <= y2; j++) {

                    map[i][j] = 1;

                }
            }
        }

        for (int[] rect : rectangle) {

            /*
             * 직사각형의 테두리만 탐색하므로 안쪽은 0으로 채운다
             * 각 직사각형의 안쪽을 채우므로 겹치는 부분은 0, 테두리는 1
             */

            int x1 = rect[0] * 2;
            int y1 = rect[1] * 2;
            int x2 = rect[2] * 2;
            int y2 = rect[3] * 2;

            for (int i = x1 + 1; i < x2; i++) {
                for (int j = y1 + 1; j < y2; j++) {
                    map[i][j] = 0;
                }
            }

        }


        return bfs(characterX * 2, characterY * 2, itemX * 2, itemY * 2);
    }

    private int bfs(int characterX, int characterY, int itemX, int itemY) {

        Queue<int[]> queue = new ArrayDeque<>();

        queue.offer(new int[]{characterX, characterY, 0});

        visited[characterX][characterY] = true;

        while (!queue.isEmpty()) {

            int[] cur = queue.poll();

            int x = cur[0];
            int y = cur[1];
            int distance = cur[2];

            if (x == itemX && y == itemY) {
                return distance / 2;
            }

            for (int i = 0; i < 4; i++) {

                int nx = x + dx[i];
                int ny = y + dy[i];

                if (nx < 0 || nx >= 102 || ny < 0 || ny >= 102) {
                    continue;
                }

                if (visited[nx][ny]) {
                    continue;
                }

                if (map[nx][ny] != 1) {
                    continue;
                }

                visited[nx][ny] = true;

                queue.offer(new int[]{nx, ny, distance + 1});

            }

        }

        return -1;
    }
}

시간복잡도

직사각형을 채우고 내부를 제거하는 과정은 직사각형 개수가 최대 4개이므로 사실상 매우 작다.

BFS 역시 각 좌표를 최대 한 번씩 방문한다.

따라서 격자의 가로와 세로를 각각 W, H라고 하면 O(W × H)이다.

가상 메모리와 페이징 시스템

KongJiHoon — Mon, 7 Sep 2026 20:44:24 +0900

1️⃣ 가상 메모리(Virtual Memory)란?

가상 메모리는 프로세스가 실제 물리 메모리(RAM)보다 더 큰 메모리 공간을 사용하는 것처럼 보이게 만드는 기술이다.

예를 들어 실제 RAM이 8GB라고 해도, 각 프로세스는 자신만의 독립된 가상 주소 공간을 가진다.

프로그램 입장에서는 단순히 메모리 주소를 사용하지만,

프로그램이 사용하는 주소
        ↓
    가상 주소
        ↓
MMU + Page Table
        ↓
    물리 주소
        ↓
       RAM

실제로는 운영체제와 하드웨어가 가상 주소 → 물리 주소로 변환해준다.

(1) 가상 메모리의 필요성

가장 중요한 목적은 크게 세 가지다.

1) 물리 메모리보다 큰 프로그램 실행

프로그램 전체를 RAM에 올릴 필요가 없다. 현재 필요한 부분만 RAM에 올리고, 나머지는 디스크에 둔다.

예를 들어:

프로그램 크기: 10GB
사용 가능한 RAM: 4GB

프로그램 전체 10GB를 RAM에 올림 ❌

현재 필요한 부분만 RAM에 올림
        ↓
RAM
┌──────────────┐
│ 현재 사용하는 영역 │
│ 현재 사용하는 영역 │
│              │
└──────────────┘

나머지
    ↓
Disk

2) 프로세스 간 메모리 격리

각 프로세스는 자신만의 가상 주소 공간을 가진다.

둘 다 0x1000이라는 주소를 사용하더라도 실제 RAM에서는 서로 다른 위치를 가리킬 수 있다.

따라서 한 프로세스가 다른 프로세스의 메모리를 마음대로 침범하기 어렵다.

3) 메모리를 효율적으로 사용

프로그램이 가지고 있는 모든 코드를 항상 사용하는 것은 아니다.

예를 들어 애플리케이션이 1GB라 하더라도 지금 실행하는 코드가 200MB뿐이라면 필요한 200MB 정도만 RAM에 올릴 수 있다.

이러한 방식을 Demand Paging(요구 페이징)이라고 한다.

2️⃣ 페이징(Paging) 이란?

가상 메모리를 관리하기 위해 메모리를 고정된 크기의 작은 블록으로 나누는 방식이다.

가상 메모리의 블록:

Page

물리 메모리의 블록:

Frame

즉,

가상 메모리 → Page
물리 메모리 → Frame

페이지와 프레임은 같은 크기를 가진다.

예를 들어 페이지 크기가 4KB라면:

가상 메모리

Page 0
Page 1
Page 2
Page 3
Page 4
...

RAM은:

Frame 0
Frame 1
Frame 2
Frame 3
Frame 4
...

이렇게 구성된다.

(1) Page와 Frame의 관계

가상 메모리의 페이지는 물리 메모리에 연속해서 들어갈 필요가 없다.

예를 들어

프로세스에서는:

Page 0
Page 1
Page 2
Page 3

연속된 메모리처럼 보인다.

하지만 실제 RAM에서는:

Frame 1 → Page 2
Frame 3 → Page 0
Frame 5 → Page 3
Frame 7 → Page 1

처럼 흩어져 있을 수 있다. 이것이 페이징의 중요한 특징이다.

(2) Page Table

그렇다면 CPU는 어떻게 Page 1 → Frame7 이라는 사실을 알 수 있을까?

이를 저장하는 자료구조가 Page Table이다.

Page Table

Page Number | Frame Number
---------------------------
Page 0      | Frame 3
Page 1      | Frame 7
Page 2      | Frame 1
Page 3      | Frame 5

흐름은 다음과 같다.

(3) 가상 주소의 구조

가상 주소는 일반적으로 두 부분으로 나뉜다.

Virtual Address

┌─────────────┬─────────────┐
│ Page Number │   Offset    │
└─────────────┴─────────────┘

예를 들어 페이지 크기가 4KB라면,

4KB = 2^12 bytes

이므로 Offset은 12bit가 된다.

CPU가 다음 주소를 접근한다고 가정해보자.

Virtual Address
       ↓
Page Number + Offset

Page Table에서:

Page Number → Frame Number

으로 변환하고 Offset은 그대로 유지한다.

Virtual Address

Page Number | Offset
      ↓
Page Table
      ↓
Frame Number | Offset

Physical Address

(4) 주소 변환 과정

즉,

CPU → 가상주소 생성 → Page Nuber 확인 → Page Table 조회 → Frame Number 확인 → 물리 주소 생성 → RAM 접근

(5) Page Fault

문제는 CPU가 요청한 Page가 RAM에 없을 수도 있다는 것이다.

이때 발생하는 것이 Page Fault다.

예를 들어:

CPU → Page 5 요청

그런데 Page Table을 보니:

Page 5 → RAM에 없음

그러면 Page Fault가 발생한다.

(6) Page Fault 처리과정

조금 더 구체적으로 보면:

CPU가 메모리에 접근

Page Table 확인

해당 Page가 RAM에 없음

Page Fault 발생

CPU가 OS에게 제어권 넘김

OS가 Disk에서 해당 Page 찾음

RAM의 빈 Frame에 Page 로드

Page Table 수정

중단됐던 명령 다시 실행

여기서 매우 중요한 점이 있다.

RAM 접근은 매우 빠른 반면 디스크 접근은 훨씬 느리다.

따라서 Page Fault가 자주 발생하면 시스템 성능이 급격히 떨어진다.

❓RAM이 꽉 차 있다면?

빈 Frame이 없다면 기존 페이지 하나를 제거해야 한다.

RAM

Frame 0 → Page A
Frame 1 → Page B
Frame 2 → Page C
Frame 3 → Page D

새로운 Page E 필요

그러면 OS는 기존 페이지 하나를 골라낸다.

Page C 제거
    ↓
Page E 삽입

이것을 Page Replacement(페이지 교체)라고 한다.

3️⃣ 페이지 교체 알고리즘(Page Replacement Algorithm)

어떤 페이지를 제거할 것인지를 결정하는 것이 페이지 교체 알고리즘이다.

대표적으로:

FIFO
Optimal
LRU
Clock

가 있다.

(1) FIFO

가장 먼저 들어온 페이지를 제거한다.

Page A → Page B → Page C → Page D

가장 오래된 Page A 제거

장점:

구현이 단순함

단점:

자주 사용하는 페이지도 오래됐다는 이유만으로 제거될 수 있음

(2) Optimal

앞으로 가장 오랫동안 사용되지 않을 페이지를 제거한다.

예를 들어:

현재 RAM

A B C

앞으로 접근 순서

A D B C ...

C가 가장 늦게 사용된다면 C를 제거한다.

이론적으로 가장 효율적이다.

하지만 문제가 있다.

미래의 메모리 접근을 알아야 한다.

따라서 실제 구현은 불가능하고 다른 알고리즘의 성능을 비교하는 기준으로 사용한다.

(3) LRU(Least Recently Used)

가장 오랫동안 사용되지 않은 페이지를 제거한다.

예를 들어:

최근 접근

A → B → C → A → B

C가 가장 오랫동안 사용되지 않았다면:

C 제거

Locality 원리를 이용한 방식이다.

4️⃣ 지역성(Locality)

프로그램은 특정 메모리 영역을 집중적으로 사용하는 경향이 있다. 이를 지역성(Locality)이라고 한다.

두 종류가 중요하다.

(1) Temporal Locality

최근 사용한 데이터는 다시 사용할 가능성이 높다.

for (int i = 0; i < 1000; i++) {
    count++;
}

count, i 같은 변수는 계속 반복해서 사용된다.

(2) Spatial Locality

특정 메모리를 사용하면 근처 메모리도 사용할 가능성이 높다.

int[] arr = new int[1000];

for (int i = 0; i < arr.length; i++) {
    System.out.println(arr[i]);
}

배열은 연속된 메모리 영역을 순차적으로 접근한다.

5️⃣ TLB

Page Table을 매번 조회하면 문제가 있다.

CPU
 ↓
Page Table 접근
 ↓
RAM 접근

RAM을 사실상 두 번 접근하게 된다.

그래서 CPU에는 TLB(Translation Lookaside Buffer)라는 고속 캐시가 존재한다.

TLB는 최근 사용한:

Page Number → Frame Number

매핑 정보를 저장한다.

(1) TLB HIT / TLB Miss

TLB Hit

TLB에 주소 변환 정보가 존재한다.

CPU
 ↓
TLB
 ↓
Frame Number 발견
 ↓
RAM

빠르다.

TLB Miss

TLB에 변환 정보가 없다.

CPU
 ↓
TLB
 ↓
없음
 ↓
Page Table 조회
 ↓
Frame Number 발견
 ↓
TLB 저장
 ↓
RAM

여기서 헷갈리면 안 되는 게 하나 있다.

TLB Miss ≠ Page Fault

TLB에는 없지만 RAM에는 존재할 수 있다.

TLB Miss
    ↓
Page Table 확인
    ↓
RAM에 있음
    ↓
정상 접근

반대로 Page Table에도 해당 페이지가 RAM에 없다고 표시되어 있다면:

Page Fault

가 발생한다.

Page Fault와 TLB Miss 차이

상황	의미
TLB Hit	주소 변환 정보를 TLB에서 찾음
TLB Miss	TLB에는 없어서 Page Table 확인
Page Fault	필요한 Page 자체가 RAM에 없음

6️⃣ 내부 단편화와 외부 단편화

페이징은 고정 크기의 블록을 사용하기 때문에 외부 단편화 문제를 크게 줄일 수 있다.

예를 들어 Page 크기가 4KB인데 프로세스가 마지막 Page에서 1KB만 사용한다면:

4KB Page

┌──────────────┐
│ 사용 1KB     │
├──────────────┤
│ 낭비 3KB     │
└──────────────┘

이것은 내부 단편화(Internal Fragmentation)다.

반면 메모리 공간이 이렇게 되어 있다고 해보자.

사용 100MB
빈 공간 20MB
사용 50MB
빈 공간 30MB
사용 200MB

전체 빈 공간은 50MB지만 연속된 40MB 공간이 필요하다면 배치하지 못할 수도 있다.

이것이 외부 단편화(External Fragmentation)다.

페이징은 페이지를 아무 Frame에나 배치할 수 있기 때문에 외부 단편화를 줄인다.

7️⃣ Thrashing

Page Fault가 지나치게 자주 발생하는 상황을 Thrashing이라고 한다.

예를 들어 RAM에 실제로 필요한 작업 세트보다 적은 페이지밖에 올릴 수 없다고 해보자.

필요한 Page

A B C D E

RAM에 올릴 수 있는 Page

A B

프로그램이:

A → B → C → D → E → A → B ...

를 반복하면

C 필요
→ A 제거

D 필요
→ B 제거

A 필요
→ C 제거
...

페이지를 계속:

Disk ↔ RAM

으로 교환하게 된다.

결과적으로 CPU보다 디스크 I/O에 대부분의 시간을 소비한다.

프로그래머스 Lv3 - 단어 변환

KongJiHoon — Mon, 7 Sep 2026 20:11:46 +0900

출처 : https://school.programmers.co.kr/learn/courses/30/lessons/43163

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

1️⃣ 문제 요약

시작 단어 begin을 목표 단어 target으로 변환해야 한다. 단어를 변환할 때는 다음 조건을 만족해야 한다.

한 번에 하나의 알파벳만 변경할 수 있다.
변경한 단어는 반드시 words 배열 안에 존재해야 한다.
begin에서 target으로 변환하는 최소 횟수를 구해야 한다.
변환할 수 없다면 0을 반환한다.

예를 들어

begin = "hit"
target = "cog"

words = ["hot", "dot", "dog", "lot", "log", "cog"]

이라면

hit → hot → dot → dog → cog

총 4번 변환하므로 정답은 4가 된다.

2️⃣ 문제 풀이

이 문제는 각 단어를 하나의 정점으로 생각하면 그래프 탐색 문제로 볼 수 있다.

두 단어의 문자를 비교했을 때 서로 다른 문자가 정확히 1개라면 이동 가능한 관계라고 볼 수 있다.

예를 들어

hit
hot

을 비교하면

h == h
i != o
t == t

서로 다른 문자가 1개이므로 hit → hot으로 이동할 수 있다.

반면

hit
dot

h != d
i != o
t == t

서로 다른 문자가 2개이므로 한 번에 변환할 수 없다.

그래프로 표현하면 다음과 같은 구조로 볼 수 있다.

이 문제에서 구해야 하는 것은 begin에서 target까지의 최소 변환 횟수이다.

따라서 가까운 단어부터 순서대로 탐색하는 BFS를 사용했다.

BFS에서 현재 단어와 지금까지의 변환 횟수를 함께 저장하기 위해 Word 클래스를 하나 생성해준다.

class Word {

    String word;
    int count;

    public Word(String word, int count) {
        this.word = word;
        this.count = count;
    }
}

먼저 시작 단어를 Queue에 넣는다. 최솟값을 구해야 하므로 Queue의 선입선출 구조를 활용하여 탐색할 때 Queue에서 단어를
꺼내 비교하고 변경할 수 있는 문자를 Queue에 넣는 방식으로 반복한다.

현재 단어에서 이동할 수 있는 단어를 찾기 위해 words배열 전체를 확인한다.

for (int i = 0; i < words.length; i++) {

    if (visited[i]) {
        continue;
    }

    if (isCanChanged(cur.word, words[i])) {

        visited[i] = true;
        queue.offer(new Word(words[i], cur.count + 1));
    }
}

이미 방문한 단어라면 다시 탐색할 필요가 없으므로 넘어간다.

if (visited[i]) {
    continue;
}

현재 단어와 후보 단어의 차이가 한 글자인 경우 다음 탐색 대상으로 큐에 넣는다.

queue.offer(new Word(words[i], cur.count + 1));

단어 하나를 변환했으므로 기존 변환 횟수에서 1을 증가시킨다.

두 단어가 한글자만 다른지는 isCanChanged()메서드로 확인한다.

private boolean isCanChanged(String word, String target) {

    int diff = 0;

    for (int i = 0; i < word.length(); i++) {

        if (word.charAt(i) != target.charAt(i)) {
            diff++;
        }

        if (diff > 1) {
            return false;
        }

    }

    return diff == 1;
}

전체 코드

import java.util.LinkedList;
import java.util.Queue;

class Solution {

    boolean[] visited;

    class Word {

        String word;

        int count;

        public Word(String word, int count) {
            this.word = word;
            this.count = count;
        }
    }

    public int solution(String begin, String target, String[] words) {

        Queue<Word> queue = new LinkedList<>();

        visited = new boolean[words.length];

        queue.offer(new Word(begin, 0));

        while (!queue.isEmpty()) {

            Word cur = queue.poll();


            if (cur.word.equals(target)) {
                return cur.count;
            }

            for (int i = 0; i < words.length; i++) {

                if (visited[i]) {
                    continue;
                }


                if (isCanChanged(cur.word, words[i])) {

                    visited[i] = true;
                    queue.offer(new Word(words[i], cur.count + 1));
                }

            }


        }


        return 0;
    }

    private boolean isCanChanged(String word, String target) {

        int diff = 0;

        for (int i = 0; i < word.length(); i++) {

            if (word.charAt(i) != target.charAt(i)) {
                diff++;
            }

            if (diff > 1) {
                return false;
            }

        }

        return diff == 1;
    }
}

시간 복잡도는 단어의 개수를 N개, 각 단어의 길이를 L이라 하면, 한 단어를 탐색할 때, 최대 N개의 단어와 비교하고, 두 단어를 비교하는 데 최대 L번의 문자 비교가 필요하다.

따라서 전체 시간 복잡도는 O(N² × L)