1.1. 문제

1.2. 문제설명

이번 문제는

1. 출력값을 나온 DFS 결과가 올바른 순서 여부 판단

하는 문제였습니다.

💡 여기서 주의할 점!

• 입력 순서대로 진행되지 않아도 된다는 것입니다. (예제 2, 3)

1.3. 접근법

1. Stack을 통해 DFS 로직 구현
2. st.hasNextTokens()을 통해, 예상 Index 파악
3. contains()을 통해, 존재 여부 판단 + count 함수를 통한 접근 제어

1.4. List + contains()

1.4.1. 코드

import java.util.*;
import java.io.*;

public class Main {
  static class Node {
    int idx, count;

    Node(int idx, int count) {
      this.idx = idx;
      this.count = count;
    }
  }

  public static void main(String[] args) throws Exception {
    BufferedReader br =
        new BufferedReader(new InputStreamReader(System.in));
    int seq = Integer.parseInt(br.readLine());
    List<List<Integer>> list = new ArrayList<>();

    for(int i = 0; i < seq + 1; i++) {
      list.add(new ArrayList<>());
    }
    StringTokenizer st;
    for(int i = 0; i < seq - 1; i++) {
      st = new StringTokenizer(br.readLine());
      int a = Integer.parseInt(st.nextToken());
      int b = Integer.parseInt(st.nextToken());
      list.get(a).add(b);
      list.get(b).add(a);
    }

    boolean flag = false;
    ArrayDeque<Node> stack = new ArrayDeque<>();
    st = new StringTokenizer(br.readLine());
    if (Integer.parseInt(st.nextToken()) == 1) {
      stack.push(new Node(1, 0));

      while(st.hasMoreTokens()) {
        Node node = stack.peek();

        if(list.get(node.idx).size() <= node.count) {
          stack.pop();
          continue;
        }

        int nextIdx = Integer.parseInt(st.nextToken());

        if (list.get(node.idx).contains(nextIdx)) {
          node.count++;
          stack.push(new Node(nextIdx, 1));
          continue;
        }

        flag = true;
        break;
      }

      System.out.println(!flag ? 1 : 0);
    } else {
      System.out.println(0);
    }
  }
}

1.4.2. 결과

1.4.3. 시간초과 원인

• ArrayList는 배열 기반 순차 탐색으로, 시간 복잡도가 O(N)으로 비효율적
• 즉, 최악으로는 O(N^2)만큼 진행, 정점은 100,000까지 가능
• 100,000 * 100,000 => 무조건 2초 이상 => 시간 초과

1.4.4. 해결방안

• HashSet의 contains()는 시간 복잡도가 평균 O(1), 최악일 때만 O(N)으로 효율적

1.5. Set + contains()

1.5.1. 코드

import java.util.*;
import java.io.*;

public class Main {
  static class Node {
    int idx, count;

    Node(int idx, int count) {
      this.idx = idx;
      this.count = count;
    }
  }

  public static void main(String[] args) throws Exception {
    BufferedReader br =
        new BufferedReader(new InputStreamReader(System.in));
    int seq = Integer.parseInt(br.readLine());
    List<Set<Integer>> list = new ArrayList<>();

    for(int i = 0; i < seq + 1; i++) {
      list.add(new HashSet<>());
    }
    StringTokenizer st;
    for(int i = 0; i < seq - 1; i++) {
      st = new StringTokenizer(br.readLine());
      int a = Integer.parseInt(st.nextToken());
      int b = Integer.parseInt(st.nextToken());
      list.get(a).add(b);
      list.get(b).add(a);
    }

    boolean flag = false;
    ArrayDeque<Node> stack = new ArrayDeque<>();
    st = new StringTokenizer(br.readLine());
    if (Integer.parseInt(st.nextToken()) == 1) {
      stack.push(new Node(1, 0));

      while(st.hasMoreTokens()) {
        Node node = stack.peek();

        if(list.get(node.idx).size() <= node.count) {
          stack.pop();
          continue;
        }

        int nextIdx = Integer.parseInt(st.nextToken());

        if (list.get(node.idx).contains(nextIdx)) {
          node.count++;
          stack.push(new Node(nextIdx, 1));
          continue;
        }

        flag = true;
        break;
      }

      System.out.println(!flag ? 1 : 0);
    } else {
      System.out.println(0);
    }
  }
}

1.5.2. 결과

2. ArrayList와 HashSet의 contains()

2.1. 왜 HashSet이 빠름?

• HashSet은 내부적으로 HashMap을 사용.
• 객체의 hashCode()를 기반으로 해시 버킷을 찾아가고, 그 안에서 equals()로 최종 비교.
• 해시 충돌이 적고 hashCode() 구현이 잘 되어 있으면 평균 O(1)의 성능을 보장함.

2.2. List, HashSet 정리 표

3. +a : hashCode()는 어디서 정의되어 있을까?

3.1. HashCode()?

• hashCode() Object 클래스에 정의된 메소드로, 객체를 식별하는 정수형 해시값(int)을 반환
• 객체 일치 ⭕
  • 항상 같은 hashCode를 반환
• 객체 일치 ❌
  • 가능하면 서로 다른 값을 반환하는 것이 이상적

3.2. 왜 필요할까?

• 해시 자료구조에서 탐색 성능을 향상시키기 위해!

3.3. Object내의 hashCode 함수

자바의 모든 객체는 Object 클래스를 상속, hashCode함수는 아래와 같이 정의되어 있음

public native int hashCode();

3.4. native 키워드?

• Java 코드가 아닌 C/C++로 구현된 메서드임을 나타냄.
• JVM 내부의 구현체와 연결되어 있고, 자바에서는 바디가 없음.
• 대표적인 메서드: hashCode(), wait(), notify(), clone() 등

3.5. Why native로 구현?

• 성능이 중요한 로직 (ex. 해시 연산)
• 운영체제 또는 메모리 관리 등 플랫폼 의존 기능 호출
• JVM의 core 기능과 밀접한 부분이기 때문에 자바 외부에서 구현됨

4. 느낀 점 + 깨달은 점

1. contains의 시간복잡도

-> 각 자료구조에 따라서 contains()의 시간복잡도가 다르다는 걸 까달음

이 시리즈는 채팅 시스템을 구축하면서 겪은 경험을 정리한 기술 회고로, 해당 글은 채팅에서 RDB 기반 채팅 시스템에 Redis를 추가 및 구조 변경에 대해 다룹니다.

Redis vs MySQL (RDB)

MySQL 기반 시스템의 특징

• 모든 메시지를 chat_message 테이블에 시간순으로 저장
• 각 사용자의 읽음 여부는 read_point로 관리
• 채팅방 마지막 메시지, 읽지 않은 메시지 수 등을 매 요청마다 쿼리로 처리
• 실시간 수신은 WebSocket + STOMP로 처리

  문제점

1. 메시지 수가 많아질수록 조회 쿼리의 부하가 커짐
2. 최근 메시지 + 읽음 정보 + 마지막 메시지를 한 번에 처리하기 위한 조인이 복잡함
3. 수십 개 채팅방에 대해 동시에 실시간 정보를 갱신할 때 성능 저하 발생

   Redis 기반 구조의 기대 효과

4. 실시간성이 중요한 채팅에 적합한 In-Memory 처리
5. 채팅방별 최신 메시지, 읽음 여부, 안 읽은 메시지 수 등을 ZSet, Hash, Pub/Sub으로 빠르게 관리 가능
6. 빈번한 읽기/쓰기에도 빠른 처리 속도 보장

Redis 적용 로직

변경 사항

1. 메시지 저장
   • 메시지 수신 시 RDB뿐 아니라 Redis에도 저장
   • Redis ZSet으로 채팅 메시지를 시간 기준 정렬 저장
   • Redis Hash로 각 채팅방 유저들의 읽은 시간 관리
2. 읽음 처리
   • 사용자별 마지막 읽은 메시지 index를 Redis에 저장
   • 특정 메시지 index를 기준으로 ZSet에서 count하여 안 읽은 메시지 수 계산
3. 채팅방 리스트 조회
   • Redis에서 각 채팅방의 마지막 메시지, 안 읽은 수, 시간 정보 등 조회 RDB 쿼리 없이 바로 응답 가능

한계

1. Spring을 재시작하면 Redis 데이터가 초기화되는 문제가 발생했습니다.
2. 채팅하는 과정에서 Redis와 RDB에 둘 다 동기적으로 입력을 진행하므로, 채팅하는 과정이 비효율적으로 진행됩니다.

Next

Redis를 통한 채팅을 구현했으니, Redis Stream을 통한 비동기 저장을 구현하여, 채팅 과정에서의 속도를 높여보겠습니다.

개념

• 컴퓨터에서 비트(bit)는 0 또는 1의 값을 가지는 가장 작은 단위다.
• 여러 개의 비트가 모여 바이트(Byte), 워드(Word) 등을 구성

  기본 문법 및 예시

1. (& : AND)

-> 1100 & 0110 : 0100 2. (| : OR) -> 1100 | 0110 : 1110 3. (^ : XOR) -> 1100 ^ 0110 : 1010 4. (~ : NOT) -> ~1100 : 0011 5. (<< : Left Shift) -> 1100 << 1 : 11000 6. (>> : Right Shift) -> 1100 >> 1 : 110 7. (>>> : 부호 없이 Right Shift) -> 1100 >>> 1 : 0110

비트 연산을 알고리즘에서 사용하는 이유

• 비트 연산은 CPU 수준에서 수행
  • 매우 빠름
  • 메모리도 훨씬 적게 사용

Bit Masking

개념

• 비트마스킹은 하나의 정수형 변수(int, long 등)에 여러 상태를 저장
• 각 비트는 하나의 플래그(flag)를 의미, 비트 연산을 통해 값을 설정하거나 확인

  장단점

  장점

1. 메모리 사용이 매우 적음 (비트 단위)
2. 연산 속도가 매우 빠름 (O(1))

   단점

3. 범위가 크면 long으로도 부족함
4. 가독성이 낮고, 디버깅이 어려움

   활용할 때

• 32개 이하의 상태라면 int 하나로 충분
• 64개까지는 long, 그 이상은 BitSet 고려

문제를 활용한 사용 예시

• 가르침 : https://www.acmicpc.net/problem/1062
  • 알파벳에 중복여부를 비트마스킹으로 check
• 성곽 : https://www.acmicpc.net/problem/2234
  • 벽을 비트마스킹으로 setting

Bit Set

개념

• Java의 java.util.BitSet은 가변 크기의 비트 배열을 제공하는 표준 클래스
• 내부적으로 long 배열을 사용, 인덱스로 각 비트를 다룸

  기본 문법 및 예시

  // 생성
  BitSet bs1 = new BitSet();        // 기본크기
  BitSet bs2 = new BitSet(1000000); // 초기 크기 지정
  

// 선택 설정 bs1.set(5); // 5번 비트를 1로 설정 bs1.clear(5); // 5번 비트를 0으로 설정 bs1.flip(5); // 5번 비트를 반전 (0이면 1, 1이면 0)

// 전체 설정 bs1.clear(); // 전체 비트를 0으로 초기화 bs1.flip(0, 10); // 0번부터 9번까지 비트를 반전

// 조회 boolean on = bs1.get(5); // 5번 비트가 켜져 있는지 확인

// 논리연산 bs1.and(bs2); // AND 연산 (교집합) bs1.or(bs2); // OR 연산 (합집합) bs1.xor(bs2); // XOR 연산 (차집합) bs1.andNot(bs2); // 차집합 a - b

int i = bs1.nextSetBit(0); // 0번 인덱스부터 처음 1인 비트 위치 int cardinality = bs1.cardinality(); // 켜진 비트의 수 int length = bs1.length(); // 가장 높은 1비트 + 1 위치 int size = bs1.size(); // 내부 배열의 크기 (최대 인덱스 아님)

## 장단점
### 장점
1. 크기 제약 없이 수백만 개 상태 표현 가능
2. Java 표준 API로 사용이 직관적이고 안정적
3. HashSet보다 훨씬 적은 메모리 사용
### 단점
1. 비트마스킹보다 다소 느릴 수 있음
2. synchronized가 아니므로 멀티스레드 환경에 주의 필요
### 활용할 때
1. 데이터가 수천~수백만 개 이상이면서 중복 여부만 체크할 때
2. 비트마스킹보다 범용성이나 가독성이 중요할 때

## 문제를 활용한 사용예시
- 중복제거 : https://www.acmicpc.net/problem/13701
  - BitSet을 활용해서, 중복없이 순서에 맞춘 출력 구현

# HashSet vs 비트마스킹 vs BitSet
| 방법 | 메모리 사용량 | 처리 속도 |
| --- | --- | --- |
| HashSet | 높음 | 느림 |
| BitSet | 낮음 | 빠름 |
| 비트마스킹 | 가장 낮음 | 가장 빠름 (단 범위 제한 있음) |

Java에서 정렬 기준을 정의하는 방법은 두 가지.

• Comparable 인터페이스 (Comparable<T>)
  • 자기 자신이 정렬 기준
  • 클래스 내부에 compareTo() 메서드를 구현해 정렬 기준을 정의.
• Comparator 인터페이스 (Comparator<T>)
  • 외부에서 정렬 기준을 주입.
  • 주로 익명 클래스나 람다식으로 사용.

2. 동작 과정

자바의 정렬 메커니즘은 객체 간의 우선순위를 비교하여 결정하는 방식으로 작동.

3. Comparable & Comparator

Comparable

• 객체가 Comparable 인터페이스를 구현하고 있다면, compareTo() 메서드가 객체 간 비교에 사용됨
• ex) PriorityQueue, Collections.sort() 등은 내부에서 자동으로 compareTo()를 호출해 순서 결정
• 내부적으로는 힙 구성, 정렬 알고리즘 수행 등에서 다수의 비교가 발생, 매번 compareTo()를 통해 정렬 기준을 판단

Comparator

• 객체가 Comparable을 구현하지 않은 경우 또는 다른 정렬 기준이 필요할 때, 외부에서 Comparator를 주입함
• 주로 PriorityQueue, Arrays.sort, Collections.sort 등에서 두 번째 인자로 전달함
• Comparator는 함수형 인터페이스, compare(x, y) 메서드를 통해 정렬 우선순위를 정의함
• 일반적으로 람다식으로 많이 사용, 특정 필드 기준 정렬, 역순 정렬, 복합 정렬 등 다양한 패턴에 유용함

4. 각 동작마다 차이점

4. 실제 문제로 알아보기 (백준 11286 - 절댓값 힙)

• 문제 링크: https://www.acmicpc.net/problem/11286

• 문제 요구 조건:

  • 절댓값이 작은 수가 먼저 나오고
  • 절댓값이 같으면 더 작은 수가 먼저 나와야 함

두 방식으로 모두 구현 가능

1) Comparable 사용

static class Numbers implements Comparable<Numbers> {
    int value;

    Numbers(int value) {
      this.value = value;
    }

    public int compareTo(Numbers other) {
      if (Math.abs(value) == Math.abs(other.value)) {
        return Integer.compare(value, other.value);
      } else {
        return Integer.compare(Math.abs(value), Math.abs(other.value));
      }
    }
  }

• 장점: 성능 빠름, 가독성 좋음
• 단점: 한 클래스에 하나의 정렬 기준만 넣을 수 있음

2) Comparator 사용

PriorityQueue<Integer> pq =
        new PriorityQueue<>((x, y) -> {
          return Math.abs(x) == Math.abs(y)
              ? (x > y ? 1 : -1)
              : (Math.abs(x) > Math.abs(y) ? 1 : -1);
        });

• 장점: 코드가 짧고 유연함, 정렬 기준을 외부에서 바꿀 수 있음
• 단점: 성능적으로 비교가 많을 경우 약간 느릴 수 있음

속도 비교 (체감 기준)

Comparable

Comparator

• Comparable 방식이 일반적으로 약간 더 빠름 (정렬 기준이 객체 내부에 고정되어 있기 때문!)
• Comparator는 유연하지만, 매번 비교 시마다 람다 호출 오버헤드가 있음

5. 느낀점

처음에는 람다의 편의성과 큰 차이점을 못느껴서 항상 Comparator를 사용했었지만, Comparable를 사용한 정렬방식이 훨씬 속도가 빠르다는 점을 알게 되어 추후에는 Comparable를 구현한 정렬방식을 더 많이 사용할 것 같다.

문제설명

이번 문제는

• 사진찍은 위치로부터의 나무 위치의 절댓값을 합친 값 => 사진 점수
• 주어진 위치의 사진 점수를 출력

을 해야하는 문제입니다.

접근법

• 0번 째 위치 : 1 + 3 + 7 + 9 + 10 = 30
  • 현재 위치에서 나무까지의 거리입니다.
• 1번 째 위치 : 0 + 2 + 6 + 8 + 9 = 25
  • 이전 위치에서 5개의 나무에 가까워졌기에, -5를 해주면 됩니다.
• 2번 째 위치 : 1 + 1 + 5 + 7 + 8 = 22
  • 이전 위치에서 4개의 나무에 가까워졌고 1개의 나무와 멀어졌으니, -3 을 해주면 됩니다.

💡즉, 누적합을 통해 나무까지와의 거리를 구하면 됩니다!

• ** 내 위치 <= 🌲 : 이전 위치 - 1**
• ** 내 위치 > 🌲 : 이전 위치 + 1**

누적합 + 순차탐색 -> 실패

코드

import java.util.*;
import java.io.*;

public class Main {
  public static void main(String[] args) throws Exception {
    StringBuilder sb = new StringBuilder();
    BufferedReader br =
        new BufferedReader(new InputStreamReader(System.in));
    StringTokenizer st =
        new StringTokenizer(br.readLine());
    int size = Integer.parseInt(st.nextToken());
    int seq = Integer.parseInt(st.nextToken());
    List<Integer> list = new ArrayList<>();

    st = new StringTokenizer(br.readLine());
    for(int i = 0; i < size; i++) {
      list.add(Integer.parseInt(st.nextToken()));
    }
    list.sort((x, y) -> x - y);

    int min = list.get(0);
    int max = list.get(list.size() - 1);

    long[] dp = new long[max + 1];

    for(int a : list) {
      dp[min] += Math.abs(a - 1);
    }

    for(int i = min + 1; i < max + 1; i++) {
      int count = 0;
      for(int a : list) {
        if(a < i) {
          count++;
        } else {
          break;
        }
      }
      dp[i] = dp[i - 1] + count - (size - count);
    }

    for(int i = 0; i < seq; i++) {
      int idx = Integer.parseInt(br.readLine());

      if(idx < min) {
        sb.append(dp[min] + ((min - idx) * size)).append("\n");
      } else if(idx > max) {
        sb.append(dp[max] + ((idx - max) * size)).append("\n");
      } else {
        sb.append(dp[idx]).append("\n");
      }
    }

    System.out.println(sb);
  }
}

결과

이유

• 0번째부터 시작하기 때문에, 1번 탐색에 시간복잡도가 최대 O(N)으로 커짐
• N과 Q은 최대 10^5까지 가능! 즉, 10^5 * 10^5 으로 2초내에 실행되는 게 불가능!

누적합 + 이분 탐색

코드

import java.util.*;
import java.io.*;

public class Main {
  public static void main(String[] args) throws Exception {
    StringBuilder sb = new StringBuilder();
    BufferedReader br =
        new BufferedReader(new InputStreamReader(System.in));
    StringTokenizer st =
        new StringTokenizer(br.readLine());
    int size = Integer.parseInt(st.nextToken());
    int seq = Integer.parseInt(st.nextToken());
    List<Integer> list = new ArrayList<>();

    st = new StringTokenizer(br.readLine());
    for(int i = 0; i < size; i++) {
      list.add(Integer.parseInt(st.nextToken()));
    }
    list.sort((x, y) -> x - y);

    int min = list.get(0);
    int max = list.get(list.size() - 1);

    long[] dp = new long[max + 1];

    for(int a : list) {
      dp[min] += Math.abs(a - min);
    }

    for(int i = min + 1; i < max + 1; i++) {
      int l = 0, r = list.size();
      while (l < r) {
        int mid = (l + r) / 2;
        if (list.get(mid) < i) {
          l = mid + 1;
        } else {
          r = mid;
        }
      }
      int count = l;

      dp[i] = dp[i - 1] + count - (size - count);
    }

    for(int i = 0; i < seq; i++) {
      int idx = Integer.parseInt(br.readLine());

      if(idx < min) {
        sb.append(dp[min] + ((long)(min - idx) * size)).append("\n");
      } else if(idx > max) {
        sb.append(dp[max] + ((long)(idx - max) * size)).append("\n");
      } else {
        sb.append(dp[idx]).append("\n");
      }
    }

    System.out.println(sb);
  }
}

결과

이유

• 이분 탐색으로 1번 탐색에 시간복잡도가 최대 O(logN)으로 커진다.
• 즉, 2초내에 실행가능!

느낀 점

• 개념으로만 알고 있는 지식을 문제에 적용하는 건 다르다는 걸 다시 한 번 깨달았음

이분 탐색

개념

• 정렬된 배열에서 특정 값을 찾거나 조건을 만족하는 값을 찾는 데 사용.
• 배열을 절반씩 나눠가며 탐색 -> O(log N)의 시간 복잡도.

적용 조건

• 데이터가 오름차순 또는 내림차순으로 정렬되어 있어야 함
• 값 존재 여부 판단 문제, 최솟값/최댓값을 찾는 결정 문제에 적합

기본 구현 (Java 기준)

public class BinarySearchExample {
    public static int binarySearch(int[] arr, int target) {
        int left = 0, right = arr.length - 1;

        while (left <= right) {
            int mid = (left + right) / 2;

            if (arr[mid] == target) return mid;
            else if (arr[mid] < target) left = mid + 1;
            else right = mid - 1;
        }

        return -1;
    }

    public static void main(String[] args) {
        int[] arr = {1, 3, 5, 7, 9, 11};
        int target = 7;
        System.out.println(binarySearch(arr, target));
    }
}

대표 문제 유형

• 특정 수가 배열에 존재하는가?
• 최소/최대 조건을 만족하는 값 찾기
• Lower Bound / Upper Bound 위치 찾기

투 포인터

개념

• 두 개의 포인터를 배열의 양 끝 또는 특정 위치에 두고, 서로를 좁히거나 밀어가며 조건을 만족하는 구간을 탐색.
• 일반적으로 O(N)의 시간 복잡도.

적용 조건

• 데이터가 정렬되어 있거나, 정렬할 수 있는 경우
• 부분합, 쌍 찾기, 구간 문제에 적합

기본 구현

public class TwoPointerExample {
    public static boolean hasTwoSum(int[] arr, int target) {
        Arrays.sort(arr);
        int left = 0, right = arr.length - 1;

        while (left < right) {
            int sum = arr[left] + arr[right];

            if (sum == target) return true;
            else if (sum < target) left++;
            else right--;
        }

        return false;
    }

    public static void main(String[] args) {
        int[] arr = {1, 4, 2, 7, 11};
        int target = 9;
        System.out.println(hasTwoSum(arr, target));
    }
}

대표 문제 유형

• 두 수의 합이 특정 값을 만드는 쌍 찾기
• 연속된 부분 수열의 합 문제
• 슬라이딩 윈도우와 결합하여 최대 길이/최대 합 구하기

문제 설명

이번 문제는

1. 폭발 문자열을 포함하는 경우 폭발
2. 남은 문자열은 이어붙여 새로운 문자열을 만듬
3. 폭발 문자열이 없을 때까지, 1ㆍ2 반복
4. 폭발 문자열이 없는 문자열 print / 문자열이 없다면 "FAULA" print

을 해야하는 문제입니다.

replaceAll() -> 실패

코드

public class Main {
    public static void main(String[] args) throws Exception{
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        String str = br.readLine();
        String s = br.readLine();

        while (!str.equals(str.replaceAll(s, ""))) {
            str = str.replaceAll(s, "");
        }

        System.out.println(str.isEmpty() ? "FRULA" : str);
    }
}

결과

이유

1. replaceAll 로직 -> Pattern.compile(regex) -> Matcher.find() -> 문자열 새로 생성 2. 반복적으로 새 문자열을 만듬 -> 매번 문자열 전체 복사 + 패턴 매칭 진행 3. Java의 String은 불변 객체 -> 매 replaceAll마다 새 문자열을 생성해야 합니다.

즉, replaceAll()을 사용하면 반복적으로 새 문자열을 만들면서 메모리가 초과되는 상황이 발생하게 됩니다.

StringBuilder() - 성공

import java.io.*;
import java.util.*;

public class Main {
  public static void main(String[] args) throws Exception {
    BufferedReader br =
        new BufferedReader(new InputStreamReader(System.in));
    String str = br.readLine();
    String target = br.readLine();
    int tLen = target.length();

    StringBuilder result = new StringBuilder();

    for (int i = 0; i < str.length(); i++) {
      result.append(str.charAt(i));

      // 마지막 부분이 폭탄 문자열과 같다면 삭제
      if (result.length() >= tLen) {
        boolean isMatch = true;

        for (int j = 0; j < tLen; j++) {
          if (result.charAt(result.length() - tLen + j) != target.charAt(j)) {
            isMatch = false;
            break;
          }
        }

        if (isMatch) {
          result.delete(result.length() - tLen, result.length());
        }
      }
    }

    System.out.println(result.length() == 0 ? "FRULA" : result);
  }
}

결과

이유

1. 코드 로직 (append -> 폭탄 유무 판단 -> delete) -> 새로운 문자열을 만드는 작업 ❌ 2. append(), delete(), insert() 등의 동작의 System.arraycopy() -> 배열을 메모리 단위로 복사, 덮어쓰기를 진행 (불필요한 객체 생성은 피하려고 설계)

즉, StringBuilder()을 사용하면 주기적으로 문자열을 수정해도 새로운 객체를 생성하지 않아서 메모리 초과가 발생하지 않습니다.

StringBuilder()

내부구조

char[] value;
int count; // 현재 길이

메소드

append(value) -> 맨 뒤에 value 저장
insert(idx, value) -> idx위치에 value 저장

charAt(index) -> 해당 index의 데이터 return
indexOf(str) -> str이 처음으로 나오는 index return
indexOf(str, index) -> index부터 시작해서 str이 처음으로 나오는 index return

delete(startIdx, endIdx) -> startIdx부터 endIdx - 1까지 삭제
deleteCharAt(index) -> 해당 index의 데이터 삭제

length() -> 현재 길이

느낀 점

• replaceAll()이 어떤 로직으로 움직이는 지 알게 되었고, StringBuilder() 전체적인 구성과 다양한 메소들를 알게 되었습니다.
• 이를 통해, StringBuilder()을 좀 더 자유롭게 사용할 수 있게 된 것 같습니다!

문제 설명

이번 문제는 세 사람의 MBIT 심리적인 거리를 구하는 문제로

• (A,B 사이 거리) + (B,C 사이 거리) + (A,C 사이 거리) 의 최솟값

을 구해야합니다.

💡 즉, 조합으로 경우의 수를 찾고, 최솟값을 찾아야 합니다.

3중 For문으로 풀기

중첩 For 문은 적은 소규모 조합일 때, 가장 알맞는 조합방식입니다.

import java.util.*;
import java.io.*;

public class Main {
    public static void main(String[] args) throws Exception {
        BufferedReader br = 
            new BufferedReader(new InputStreamReader(System.in));
        String str = br.readLine();
        int len = str.length();
        int[] dp = new int[len + 1];
        dp[0] = 1;

        for(int i = 1; i < len + 1; i++) {
            char c = str.charAt(i - 1);
            if(c != '0') {
                dp[i] += dp[i - 1];
            }

            if(i >= 2) {
                int num = 
                    Integer.parseInt(str.substring(i - 2, i));

                if(10 <= num && num <= 34) {
                    dp[i] += dp[i - 2];
                }
            }
        }

        System.out.println(dp[len]);
    }
}

재귀로 풀기

재귀는 조합의 전형적 방식으로, 중첩 For문보다는 느리지만 간결하고 직관적이라는 장점이 있습니다.

import java.util.*;
import java.io.*;

public class Main {

  static int answer;
  static int[] arr;

  public static void main(String[] args) throws Exception {
    BufferedReader br =
        new BufferedReader(new InputStreamReader(System.in));
    StringBuilder sb = new StringBuilder();
    int freq = Integer.parseInt(br.readLine());

    next:
    for (int z = 0; z < freq; z++) {
      answer = Integer.MAX_VALUE;
      arr = new int[3];

      int seq = Integer.parseInt(br.readLine());
      StringTokenizer st =
          new StringTokenizer(br.readLine(), " ");
      Map<String, Integer> map = new HashMap<>();
      List<String> list = new ArrayList<>();

      // map + set 저장
      for (int i = 0; i < seq; i++) {
        String str = st.nextToken();
        if (map.containsKey(str)) {
          map.put(str, map.get(str) + 1);
        } else {
          map.put(str, 1);
        }
      }

      // 리스트 setting + key 3개 이상이면 0 insert
      for (String key : map.keySet()) {
        list.add(key);

        if (map.get(key) >= 3) {
          sb.append(0).append("\n");
          continue next;
        }
      }

      comb(list, map, arr, list.size(), 0);

      sb.append(answer).append("\n");
    }

    System.out.print(sb);
  }

  static void comb(List<String> list, Map<String, Integer> map,
      int[] arr, int seq, int depth) {

    if (depth == 3) {
      String aKey = list.get(arr[0]);
      String bKey = list.get(arr[1]);
      String cKey = list.get(arr[2]);

      if (arr[0] == arr[1] && arr[1] == arr[2]) {
        return;
      }

      if ((aKey.equals(bKey) && map.get(aKey) == 2)
          || (bKey.equals(cKey) && map.get(bKey) == 2)
          || (aKey.equals(cKey) && map.get(aKey) == 2)
          || (!aKey.equals(bKey) && !aKey.equals(cKey) && !cKey.equals(bKey))) {
        answer =
            Math.min(comp(aKey, bKey, cKey), answer);
      }

      return;
    }

    for (int i = 0; i < seq; i++) {
      arr[depth] = i;
      comb(list, map, arr, seq,depth + 1);
    }
  }

  public static int comp(String aKey, String bKey, String cKey) {
    int returnValue = 0;

    for (int i = 0; i < 4; i++) {
      returnValue += aKey.charAt(i) != bKey.charAt(i) ? 1 : 0;
      returnValue += bKey.charAt(i) != cKey.charAt(i) ? 1 : 0;
      returnValue += cKey.charAt(i) != aKey.charAt(i) ? 1 : 0;
    }

    return returnValue;
  }
}

느낀 점

• 재귀와 중복 반복문으로 조합을 각각 구현해보니, 각각의 장단점을 알 수 있었습니다.

이 시리즈는 채팅 시스템을 구축하면서 겪은 경험을 정리한 기술 회고로, 해당 글은 채팅에서 사용한 기술을 선택한 이유와 MVP를 위해 가장 먼저 구축했던 RDB 기반 채팅 시스템에 대해 다룹니다.

채팅 개발한 이유

팀 프로젝트를 진행하면서, AI 기반 전자기기 중고거래 플랫폼을 개발하게 되었습니다. 저는 백엔드를 담당하며, 채팅파트를 맡아 진행했습니다.

이에, 가장 먼저 사용할 기술에 대해 고려했고, 여러 후보 중 STOMP와 Redis를 선택했습니다.

STOMP & Redis를 선택한 이유!

• STOMP
  • 기획단계에서 단체방에 대한 고려 ⭕ -> 메시지 라우팅이 자동으로 가능한 구조가 필요했습니다.
    • @MessageMapping + @SendTo을 통해 편하게 구축가능!
  • 읽음 유무 판단, 마지막 메세지 제공 같은 실제 채팅 서비스를 목표로 진행했고, 구현 과정에서의 최대한 리소스를 줄일 필요가 있었습니다.
    • 메시지 타입 분기, 목적지 라우팅, 세션/유저 추적 등 다양한 기능을 기본 제공하여 직접 구현해야 할 로직이 최소화!

• Redis
  • 6주 안에 채팅에 읽은 시간, 채팅 메세지 캐싱 등을 도입 및 실제 사용이 가능한 완성도가 나와야 했기에, 러닝커브가 적어야 했음.
    • MongoDB가 가장 많은 레퍼런스를 가지고 있지만, 채팅 이외의 작업도 많았던 상황에서 학습을 진행하기에는 무리라는 생각에 제외
    • 가장 많이 사용해보고 익숙한 NoSQL이 Redis였음
  • 채팅에서 가장 중요한 건 속도라고 생각
    • Redis의 ZSet을 통해 score를 만들어 구축하여, 채팅을 순차적으로 저장!
    • In-Memory 구조로 NoSQL 중에서 가장 빠른 속도를 가짐!

요구사항

기획단계에서 나왔던 요구사항이 다음과 같이 나왔고, 이에 맞춰서 진행했습니다.

1. 메시지 실시간 송수신 2. 채팅방 단위로 마지막 메세지를 보여주기 3. 각 사용자별로 읽은 메시지 정보 제공 4. 실시간으로 읽음여부를 파악

로직

고려사항

• 메시지는 chat_message 테이블에 시간 순으로 쌓입니다.
• read_point는 사용자가 마지막으로 읽은 메시지를 기준으로 읽음 여부를 계산하는 데 사용됩니다.
• 채팅방 생성 후, 초기 데이터가 없기에 해당 상황에서의 기본 return값 지정이 필요합니다.

🔨 기술 스택 및 구현

• Java 17
• Spring Boot 3.x
• Spring Data JPA
• MySQL 8.0

메시지는 WebSocket으로 수신되며, 바로 JPA를 통해 DB에 저장합니다.

1. stomp 구성

   @Slf4j
   @Component
   @RequiredArgsConstructor
   public class StompChannelInterceptor implements ChannelInterceptor {
    private final Map<String, Set<String>> sessions = new ConcurrentHashMap<>();
   
    @Override
    public Message<?> preSend(@NonNull Message<?> message, @NonNull MessageChannel channel) {
        StompHeaderAccessor accessor =
                MessageHeaderAccessor.getAccessor(message, StompHeaderAccessor.class);
   
        // 올바른 접근인 지 판단
   
        switch (accessor.getCommand()) {
            case CONNECT -> {
                handleConnect(accessor);
            }
            case SEND -> {
                handleSend(accessor, message);
            }
            case DISCONNECT -> {
                handleDisconnect(accessor);
            }
        }
   
        return message;
    }
   
    private void handleDisconnect(StompHeaderAccessor accessor) {
        //연결 종료 시, 행동할 메소드
    }
   
    private void handleSend(StompHeaderAccessor accessor, Message<?> message) {
        // 전송 시, RDB에 저장
   
    private void handleConnect(StompHeaderAccessor accessor) {
        // 연결 시, jwt 검증 시도
    }
   }
   

> SSAFY 프로젝트로 아직 반출신청을 못해서... 
지금은 큰 로직만 보여드리고, 추후에 자세한 코드를 첨부하겠습니다.
> 



## 예상되는 한계

### 한계

* 메시지가 많아질수록 쿼리 성능이 저하될 가능성이 매우 높습니다.
* 실시간 요청을 하지만 RDB에 저장/조회되는 과정이 Redis보다 상대적으로 느립니다.



## 트래픽이 올라가면서…
![](https://velog.velcdn.com/images/go_ruth/post/ead62def-8baf-4d2c-b35e-a34e4b4b49e5/image.png)

![](https://velog.velcdn.com/images/go_ruth/post/ccfa4c93-0663-432a-9cf8-32e35c356c16/image.png)


예상대로 Chatting 조회 테스트를 진행하면서, 메시지 건수를 늘렸더니 속도가 저하되었습니다. 그래서 1차적으로 Slice<>를 통한 필요한 데이터만 return하도록 구성했고, 캐시 구성을 위한 **Redis** 기반의 채팅으로 전환을 진행했습니다.



## Next

RDB로 간단한 MVP를 구성했으니, 이제는 RDB에서 Redis로 전환하면서 속도를 높인 로직으로 바꿔보겠습니다.

AI기반 전자기기 중고거래 플랫폼 프로젝트를 진행하면서, 프론트엔드에서 기기 이미지를 별도의 AI서버에 업로드하면, 해당 사진 판독 결과와 결과값을 받아오는 기능이 있었습니다.

로컬에서 해당 기능이 정상작동하는 걸 확인 후, https가 적용되있는 서버에 배포를 진행했습니다.

왜 갑자기 에러?

배포 후, Test를 진행했는데 갑자기 아래와 같은 에러가 뜨고 Api와의 연동이 되지 못했습니다.

Mixed Content: The page at 'https://{웹 url}' was loaded over HTTPS, 
but requested an insecure XMLHttpRequest endpoint 'http://{ai 서버 url}:port/api'. 
This request has been blocked; the content must be served over HTTPS.

HTTPS 페이지에서 HTTP로 요청을 보냈기 때문에 요청이 차단되었던 것입니다.

왜 Block을 하는 걸까?

🔒 HTTPS는 암호화된 채널이지만, HTTP는 평문 전송이기 때문에 중간자 공격(MITM)이나 데이터 변조가 발생할 수 있습니다.

현대의 브라우저는 HTTPS 페이지에서 HTTP 리소스를 요청하는 경우에, 이를 보안 위협으로 간주하고 요청을 차단합니다.

결과적으로 HTTPS → HTTP 요청은 기본적으로 허용 ❌

해결방법

테스트만 하기 위한 임시 방편

바로, 프론트엔드에서 직접 HTTP 서버로 요청 -> Nginx 서버를 Proxy로 사용해서 내부적으로 Http 요청으로 변경하는 것입니다!

해당 로직이 왜 Https -> Http에서 발생하는 에러를 방지하냐면,

1. 프론트에서는 https://url/ai/api와 같이 HTTPS API로 요청
2. Nginx 설정에서 해당 요청을 내부적으로 http://{ai 서버 url}/api로 proxy_pass를 진행

이렇게 함으로써 브라우저는 HTTPS → HTTPS 요청만 진행하고, Nginx가 내부적으로 HTTP 요청을 처리해 Mixed Content 오류가 발생하지 않도록 우회할 수 있었습니다.

다만, 결국에는 Https -> Http 요청으로, 데이터 보안이 보장 ❌ -> 테스트 or 로컬에서만 사용해야 합니다.

문제 해결하기 위한 해결책

실제 운영 환경에서는 AI 서버에도 Let's Encrypt 등의 무료 인증서를 적용하여 Https <-> Https 통신이 되도록 해야합니다.

느낀 점

이번에 인프라를 팀원들과 함께 구축하면서 개념으로만 알고 있던, Https와 Http의 차이를 제대로 파악할 수 있었고 보안을 위해서 무조건 Https를 적용해야 안정성을 제공할 수 있다는 걸 알 수 있었습니다.

문제 설명

이번 문제는 가능한 카드배열의 수를 구하는 문제로,

• 1 ~ 34까지의 숫자를 가진 카드들로 배열을 구성.
• 최대 40자 이하의 숫자로 이뤄짐

이 되어야 합니다.

접근법 (DP)

1. 각 Index에 따라서 조건
   • 한자리 : 1~9인 지 파악
     • 두자리 : 10 ~ 34인 지 파악
2. 조건에 맞다면 이전의 경우의 수를 +
3. 모든 조건을 계산 후, 가장 마지막 DP Data를 return

코드

import java.util.*;
import java.io.*;

public class Main {
    public static void main(String[] args) throws Exception {
        BufferedReader br = 
            new BufferedReader(new InputStreamReader(System.in));
        String str = br.readLine();
        int len = str.length();
        int[] dp = new int[len + 1];
        dp[0] = 1;

        for(int i = 1; i < len + 1; i++) {
            char c = str.charAt(i - 1);
            if(c != '0') {
                dp[i] += dp[i - 1];
            }

            if(i >= 2) {
                int num = 
                    Integer.parseInt(str.substring(i - 2, i));

                if(10 <= num && num <= 34) {
                    dp[i] += dp[i - 2];
                }
            }
        }

        System.out.println(dp[len]);
    }
}

느낀 점

• DP는 확실히 문제유형이 DP라는 걸 파악하는 게 중요하다고 생각이 들었음.

문제 설명

이번 문제는 마지막 곡의 최대 볼륨을 구하는 문제로,

1. i번째를 연주하려면, 이전의 볼륨에서 정해진 변경 볼륨대로 + or -를 해야한다.
2. 볼륨이 0 <= volume <= M 을 충족해야 한다.
3. 모든 곡을 리스트에 적힌 순서대로 연주해야 한다.

1. DFS

가장 먼저 DFS를 통해 최대값을 도출하려 했습니다.

import java.util.*;
import java.io.*;

public class Main {
    static int answer = -1;

    public static void main(String[] args) throws Exception {
        BufferedReader br = 
            new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = 
            new StringTokenizer(br.readLine());
        int seq = Integer.parseInt(st.nextToken());
        int start = Integer.parseInt(st.nextToken());
        int limit = Integer.parseInt(st.nextToken());
        int[] arr = new int[seq];
        st = new StringTokenizer(br.readLine());
        for(int i = 0; i < seq; i++) {
            arr[i] = Integer.parseInt(st.nextToken());
        }

        dfs(arr, start, limit, 0, seq);

        System.out.println(answer);
    }

    public static void dfs(int[] arr, int start, int limit, int idx, int seq) {
        if(idx == seq) {
            answer = Math.max(answer, start);
            return;
        }

        if(start - arr[idx] >= 0) {
            dfs(arr, start - arr[idx], limit, idx + 1, seq);
        }
        if(start + arr[idx] <= limit) {
            dfs(arr, start + arr[idx], limit, idx + 1, seq);
        }
    }
}

그리고 당연하게도... 시간초과가 발생했습니다.

이유는 바로 상태저장 없이 DFS를 진행했기 때문입니다.

아래 그림을 통해 더 자세히 설명하자면

• 초기 상태에서 1번째 연주를 진행하면서 볼륨 증감 시도 (1 * 2)

• 2^1

• 1번째 연주 끝난 상태에서 2번째 연주를 진행하면서 볼륨 증감 시도 (2 * 2)

• 2^2

• 2번째 연주 끝난 상태에서 3번째 연주를 진행하면서 볼륨 증감 시도 (4 * 2)

• 2^3

• 마지막으로 N - 1번째 연주 끝난 상태에서 N번째 연주를 진행하면서 볼륨 증감 시도 (2^N-1 * 2)

• 2^N

💡 무조건 증감을 시도하기 때문에, 항상 O(2^N)의 시간 복잡도가 생기면서 시간초과 발생

2. DFS + visited배열

이에, 중복되는 상황을 제거하기 위해, 2차원 boolean배열을 통해 중복되는 접근을 차단했습니다.

import java.util.*;
import java.io.*;

public class Main {
    static int answer = -1;

    public static void main(String[] args) throws Exception {
        BufferedReader br = 
            new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = 
            new StringTokenizer(br.readLine());
        int seq = Integer.parseInt(st.nextToken());
        int start = Integer.parseInt(st.nextToken());
        int limit = Integer.parseInt(st.nextToken());
        boolean[][] v = new boolean[seq + 1][limit + 1];
        int[] arr = new int[seq];
        st = new StringTokenizer(br.readLine());
        for(int i = 0; i < seq; i++) {
            arr[i] = Integer.parseInt(st.nextToken());
        }

        dfs(arr, start, limit, 0, seq, v);

        System.out.println(answer);
    }

    public static void dfs(int[] arr, int start, int limit, int idx, int seq, boolean[][] v) {
        if(idx == seq) {
            answer = Math.max(answer, start);
            return;
        }

        if(start - arr[idx] >= 0 && !v[idx + 1][start - arr[idx]]) {
            v[idx + 1][start - arr[idx]] = true;
            dfs(arr, start - arr[idx], limit, idx + 1, seq, v);
        }
        if(start + arr[idx] <= limit && !v[idx + 1][start + arr[idx]]) {
            v[idx + 1][start + arr[idx]] = true;
            dfs(arr, start + arr[idx], limit, idx + 1, seq, v);
        }
    }
}

그리고 결과는... 정답이 였습니다.

아래의 그림으로 성공하는 이유를 설명하자면,

💡 이전에는 중복이 가능했지만, 2차원 배열을 통해 이미 방문한 곳을 차단했기 때문에 중복 없이 탐색이 가능! -> 시간복잡도가 O(N * (M + 1)) 로 대폭감소 / N = 곡 수, M = 최대 볼륨

3. DP (2차원 배열)

정답 후 다른 사람들의 정답을 찾아 파악해봤는데, 대부분 DP를 통해 문제해결을 도모. 차이점 비교를 위해서 코드를 작성해봤습니다.

import java.util.*;
import java.io.*;

public class Main {
    static int answer = -1;

    public static void main(String[] args) throws Exception {
        BufferedReader br = 
            new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = 
            new StringTokenizer(br.readLine());
        int seq = Integer.parseInt(st.nextToken());
        int start = Integer.parseInt(st.nextToken());
        int limit = Integer.parseInt(st.nextToken());
        int[] arr = new int[seq];
        boolean[][] dp = new boolean[seq + 1][limit + 1];
        dp[0][start] = true;

        st = new StringTokenizer(br.readLine());
        for(int i = 0; i < seq; i++) {
            arr[i] = Integer.parseInt(st.nextToken());
        }

        for(int i = 0; i < seq; i++) {
            for(int j = 0; j < limit + 1; j++) {
                if(dp[i][j]) {
                    if(j + arr[i] <= limit) {
                        dp[i + 1][j + arr[i]] = true;
                    }
                    if(j - arr[i] >= 0) {
                        dp[i + 1][j - arr[i]] = true;
                    }
                }
            }
        }

        int answer = -1;
        for(int j = limit; j >= 0; j--) {
            if(dp[seq][j]) {
                answer = j;
                break;
            }
        }

        System.out.println(answer);
    }
}

DP를 풀면서 이전의 DFS + 2차원 배열 코드와 다른 점으로는

• DFS + 2차원 배열
  • 방문 처리를 통한 중복 방지
  • 재귀를 통한 다음 index로 이동
  • 끝까지 이동한 후, 최대 볼륨을 일일히 비교
• DP
  • 가능한 모든 경우를 boolean 2차월 배열로 초기 세팅
  • 시작 위치 true
  • true인 곳을 다음 볼륨 비교 후 true로 업데이트
  • 모든 방문 후, 최대 index를 파악 후 return

였습니다.

4. DP (1차원 배열)

더 나아가, 1차원 배열로도 진행이 가능합니다.

import java.util.*;
import java.io.*;

public class Main {
    static int answer = -1;

    public static void main(String[] args) throws Exception {
        BufferedReader br = 
            new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = 
            new StringTokenizer(br.readLine());
        int seq = Integer.parseInt(st.nextToken());
        int start = Integer.parseInt(st.nextToken());
        int limit = Integer.parseInt(st.nextToken());
        int[] arr = new int[seq];
        boolean[] preDP = new boolean[limit + 1];
        boolean[] nextDP = new boolean[limit + 1];
        preDP[start] = true;

        st = new StringTokenizer(br.readLine());
        for(int i = 0; i < seq; i++) {
            arr[i] = Integer.parseInt(st.nextToken());
        }

        for(int z = 0; z < seq; z++) {
            Arrays.fill(nextDP, false);

            for(int i = 0; i < limit + 1; i++) {
                if(preDP[i]) {
                    if(i + arr[z] <= limit) {
                        nextDP[i + arr[z]] = true;
                    }
                    if(i - arr[z] >= 0) {
                        nextDP[i - arr[z]] = true;
                    }
                }
            }

            boolean[] temp = nextDP;
            nextDP = preDP;
            preDP = temp;
        }

        int answer = -1;
        for(int j = limit; j >= 0; j--) {
            if(preDP[j]) {
                answer = j;
                break;
            }
        }

        System.out.println(answer);
    }
}

이전의 2차원 배열 DP과 지금의 1차원 배열이 다른 점으로는

• 2차원 배열
  • 모든 경우의 수를 세팅
  • 모든 작업 후 마지막 곡 index에서 최대 볼륨 index를 find
• 1차원 배열
  • 이전 곡의 배열, 다음곡의 배열로 2개의 1차원 배열만 생성

  • 이전 곡에서 볼륨 조절을 진행하기 때문에!

  • 다음 곡 볼륨 로직 후, 배열 주소 변경

💡 이를 통해, 공간 복잡도를 O(N * M) → O(2M)로 줄일 수 있게 됩니다!

느낀 점

• 해당 문제를 풀면서 다양한 접근이 가능하다는 걸 알게 되었습니다.
• 특히, 해당 문제에서 방식에 따른 장점을 파악할 수 있게 되었습니다.

1. ObjectMapper란?

ObjectMapper는 Java 객체를 JSON으로 직렬화하거나, JSON을 Java 객체로 역직렬화할 수 있게 해주는 Jackson의 핵심 클래스입니다.

ObjectMapper mapper = new ObjectMapper();

// 직렬화
String json = mapper.writeValueAsString(myObject);

// 역직렬화
MyObject obj = mapper.readValue(json, MyObject.class);

2. 직렬화와 역직렬화의 내부 동작 원리

직렬화 (writeValueAsString)

1. BufferRecycler 준비 → Jackson이 내부 버퍼 메모리 확보
2. SegmentedStringWriter 준비 → JSON 데이터를 쓸 준비
3. JsonGenerator 생성 → 실제 JSON 생성 작업 담당
4. 객체 직렬화 → Java 객체를 JSON 형태로 변환
5. 결과 문자열 반환 및 메모리 정리

역직렬화 (readValue)

1. readValue(String, Class<T>) → 일반 클래스 변환
2. readValue(String, new TypeReference<List<T>>(){}) → 제네릭/컬렉션 처리

3. 실전 사용 예시

3.1. 객체 → JSON 문자열

User user = new User("John", 30);
String json = mapper.writeValueAsString(user);

3.2. JSON 문자열 → 객체

String json = "{\"name\":\"John\",\"age\":30}";
User user = mapper.readValue(json, User.class);

3.3. JSON 문자열 → Map 등 복잡한 구조

Map<String, Object> map = mapper.readValue(json, new TypeReference<Map<String, Object>>() {});

4. 커스터마이징 기능

4.1. 필드명 커스터마이징

@JsonProperty("username")
private String name;

4.2. 필드 제외

@JsonIgnore
private String password;

4.3. 날짜 포맷

@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd HH:mm:ss")
private LocalDateTime createdAt;

4.4. Null 필드 제외

mapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);

4.5. 알 수 없는 필드 무시

mapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES);

4.6 snake_case 자동 변환

mapper.setPropertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE);

5. 고급 기능

컬렉션 역직렬화 시 TypeReference 필수

List<User> list = mapper.readValue(json, new TypeReference<List<User>>() {});

JavaTimeModule 등록 (LocalDateTime 등)

mapper.registerModule(new JavaTimeModule());
mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);

커스텀 Serializer

public class MaskingSerializer extends JsonSerializer<String> {
  public void serialize(String value, JsonGenerator gen, SerializerProvider serializers) throws IOException {
    gen.writeString("***");
  }
}

@JsonSerialize(using = MaskingSerializer.class)
private String phoneNumber;

6. Spring에서 ObjectMapper가 선호되는 이유

Spring 설정 예시

@Bean
public ObjectMapper objectMapper() {
    ObjectMapper mapper = new ObjectMapper();
    mapper.registerModule(new JavaTimeModule());
    mapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);
    return mapper;
}

7. ObjectMapper의 사용 영역 in Spring

• @RequestBody, @ResponseBody → HTTP 요청/응답 자동 변환
• RestTemplate, WebClient → JSON API 데이터 처리
• RedisTemplate, KafkaTemplate → 메시지 직렬화/역직렬화
• 단위 테스트 (MockMvc) → JSON 검증 및 비교

8. 대체 가능한 JSON 처리 도구 비교

Websocket + Spring Security

• WebSocket 연결은 아래와 같은 과정으로 진행이 됩니다.

  1. HTTP 프로토콜을 사용해 접근
  2. Websocket으로 Upgrade를 진행하며 연결 시도
  3. 연결 유무 응답을 return

• 해당 과정에서 Spring Security는 HTTP 요청까지만 인증 및 권한 파악을 진행하며, WebSocket 메시지 이후의 통신에는 적용되지 않습니다.

use Spring Security

• 따라서 WebSocket 인증은 HandshakeInterceptor에서 1차적으로 인증 정보를 저장하고, 이후 메시지 처리 과정에서는 ChannelInterceptor를 통해 권한 검사를 수행하는 방식으로 구현해야 합니다.

use HandshakeInterceptor

보완한 점

이에, 저는 Spring Security만 사용하던 코드를

1. 웹소켓 요청 시, web.ignoring()을 통해 Security의 확인 과정 생략 2. STOMP에 HandshakeHandler을 설정하여 websocket 연결 전 확인 3. ChannelInterceptor를 통한 메세지 핸들링

를 적용하며 보완했습니다.

구체적으로는 아래와 같이 사용했습니다.

preSend를 통해 command 파악

1. CONNECT 일 때

-> 비정상적인 세션 및 데이터 관리를 위한 Redis에 저장 로직 2. SEND일 때 -> 각 JSON의 type의 값을 조건으로 알맞는 DTO로 변경 후 데이터 처리 3. DISCONNECT일 때 -> Redis에 저장된 값 제거

💡 Tip. ChannelInterceptor에서 accessor의 command를 사용해서 CONNECT일 때, 권한 및 인증을 확인할 수 있습니다.

다만, 그 과정을 위해 무조건 Websocket이 연결이 되야만 하기 때문에 *handshaking를 사용한 연결 전 처리보다는 상대적으로 비효율적 * 인 구조가 됩니다.

이에, 처음에는 단순히 "Key가 손상된 건가?" 싶어, Docker 내부에서 직접 mysql -u 사용자명 -p 명령어를 통해 DB 내 설정 상태를 확인했습니다.

확인하면서 문제는 없었고, 해당 과정이 이후로 Spring 서버도 정상 실행됐습니다.

하지만 매번 Docker이 restart 될 때 해당 과정을 반복해야 했고, 꽤나 번거로웠습니다.

그래서 원인을 본격적으로 파고들었는데, 생각보다 아주 간단한 설정 하나로 문제를 해결할 수 있었습니다.

문제 원인: MySQL 인증 방식

MySQL에는 대표적으로 두 가지 인증 방식이 있습니다.

• mysql_native_password
• caching_sha2_password (MySQL 8부터 기본)

이 중, caching_sha2_password 인증방식을 사용하면서 에러가 발생했습니다.

Public Key Retrieval is not allowed

말 그대로 "클라이언트가 서버의 공개키를 받아오는 것이 허용되지 않아" 발생하는 에러. -> caching_sha2_password방식에서는 공개키 기반 인증이 필요한데, 이를 허용하지 않게 JDBC 설정한 것이 원인이였습니다.

해결방법

1. JDBC URL에 옵션 추가 (권장)

spring:
  datasource:
    url: jdbc:mysql://localhost:{port}/{db_name}?allowPublicKeyRetrieval=true&useSSL=false

• application.yml 또는 application.properties에 아래 설정을 추가합니다.

2. 인증 방식을 변경 (비권장)

ALTER USER 'usedTrade'@'%' IDENTIFIED WITH mysql_native_password BY 'yourpassword';

• 이 방법은 보안이 약한 방식으로 회귀하는 것이고, Docker 자동화에도 불리하므로 추천하지 않아요.

그런데 왜 Docker 내부에서 로그인하면 잘 될까?

이건 caching_sha2_password의 캐시 특성 때문으로, Docker 내부에서 mysql -u usedTrade -p 등으로 한 번 접속하고 Spring에서도 접속이 잘 되는 듯 보이는 현상이 나타납니다.

자세한 흐름은 아래와 같습니다.

최초 접속 🔻 서버가 클라이언트에 공개키를 제공하고, 클라이언트가 암호화하여 응답 🔻 이후 접속 🔻 서버는 클라이언트 IP/User 정보를 바탕으로 인증 정보를 캐싱 🔻 캐싱된 인증을 통해 빠르게 접속 허용

즉, 기존했던 작업들은 정상 동작처럼 보이지만 캐시 덕분에 '우연히' 통과된 상태로,

1. 캐시가 만료
2. Docker 또는 MySQL이 재시작
3. Spring 서버의 IP가 변경

같은 동작이 발생한다면 다시 오류가 발생합니다.

즉, allowPublicKeyRetrieval=true 설정을 추가해야 Spring이 올바르게 DB에 접근이 가능합니다.

결과

• 엔티티를 조회할 때, 연관된 엔티티들이 항상 사용되는 것은 아님

• DB에서 함께 조회해두는 것은 비효율!

• 해당 문제 해결을 위해 엔티티가 실제 사용 전까지 DB 조회를 지연하는 방법 제공

• 지연 로딩!

• 지연로딩을 사용하기 위해서는 조회 지연을 위한 가짜 객체가 필요

• 프록시 객체

특징

초기화

Member member = em.getReference(Member.class, "id1");
member.getName();

**내부 예상 로직**
1. 초기화 요청
2. DB 조회
3. 실제 Entity 생성 및 참조 보관
4. 실제 값 return

프록시와 식별자

• 엔티티를 프록시로 조회 시, 식별자 값을 파라미터로 전달

• 프록시 객체는 해당 식별자값을 보관

💡 연관관계 설정할 때는 식별자 값만 사용하므로 프록시를 사용하면 DB 접근 횟수를 줄일 수 있다.

즉시로딩, 지연로딩

개념

• 즉시로딩
  • 엔티티를 조회할 때 연관된 엔티티도 함께 조회.
  • @ManyToOne(fetch = FetchType.EAGER)
• 지연로딩
  • 연관된 엔티티를 실제 사용할 때 조회.
  • @ManyToOne(fetch = FetchType.LAZY)

즉시로딩

SELECT
 M.MEMBER_ID AS MEMBER_ID,
 M.TEAM_ID AS TEAM_ID,
 M.USERNAME AS USERNAME,
 T.TEAM_ID AS TEAM_ID,
 T.NAME AS NAME
FROM
 MEMBER M LEFT OUTER JOIN TEAM T
 ON M.TEAM_ID=T.TEAM_ID
WHERE
 M.MEMBER_ID='member1'

지연로딩

유의점

Lazy 로딩되는 Entity에 즉시 로딩이 있다면 해당 Entity도 로딩!

• Porxy 객체는 실제 자신이 사용될 때까지 DB를 조회하지 않음
• 컬랙션 래퍼
  • 하이버네이브는 Entity를 영속 상태로 만들 때, Entity에 컬랙션이 있으면 컬랙션 추적 및 관리 목적으로 하이버네이트로의 내장 컬랙션으로 변경
  • 지연로딩 시, 컬랙션은 컬랙션 래퍼가 지연 로딩 처리

JPA 기본 전략

• ManyToOne, OneToOne (즉시로딩)
• OneToMany, ManyToMany (지연로딩)

💡 추천은 모든 연관관계를 지연로딩 후, 상황에 따라서 변동!

즉시로딩 시, 주의점

1. 컬렉션 하나 이상 즉시 로딩은 권장 ❌
2. 컬렉션 즉시 로딩은 항상 외부조인!

영속성 전이

• 특정 엔티티를 영속 상태로 만들 때, 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때 사용함

• JPA에서는 엔티티를 저장할 때, 연관된 모든 엔티티는 영속 상태여야 함

  • 영속성 전이 ❌ : 부모 영속 후 자식도 각각 영속으로 만들어야 했음
  • 영속성 전이 ⭕ : 부모 영속만 영속상태로 만들어도 자식도 영속상태가 됨

CASCADE 옵션

• ALL, // 모두 적용
• PERSIST, // 영속

Child child1 = new Child();
Child child2 = new Child();

Parent parent = new Parent();
child1.setParent(parent);
child2.setParent(parent);

parent.getChildren().add(child1);
parent.getChildren().add(child2);

//부모 저장, 연관된 자식들 저장
em.persist(parent);

• MERGE, // 병합

• REMOVE, // 삭제

  Parent findParent = em.find(Parent.class, 1L);
  부모와 연관 자식도 모두 제거
  em.remove(findParent);

• REFRESH,

• DETACH

고아객체

• JPA는 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제하는 기능을 제공

• orphanRemoval = true

💡 참조하는 곳이 하나일 때만 사용해야 함! 💡 @OneToMany에만 사용 가능

영속성 전이 + 고아객체 -> 생명주기 Controll

• 일반적으로 엔티티는 persist로 영속, remove를 통해 제거

• 엔티티 스스로 생명주기를 관리한다는 뜻!

• CascadeType.ALL + orphanRemoval = true

• 부모 엔티티를 통해서 자식의 생명주기를 관리할 수 있다는 뜻

문제 설명

해당 문제는 말 그대로 에어컨의 모든 바람 이동 위치를 파악 후 해당 갯수를 구해는 구현문제였습니다.

다만 고려해야 할 몇가지가 있었는데,

1. 에어컨은 여러개가 가능하다.
2. 바람이 이동한 횟수를 count ❌, 바람이 지나가는 자리의 ⭕
3. 에어컨, 물건이 있는 자리 모두 바람 ⭕

라는 것이였습니다.

위에 3가지 사항은 사실 문제 지문과 예시 그림만 봐도 파악이 가능했었기 때문에 로직만 잘 파악하고 있다면 비교적 쉽게 구현이 가능한 문제였습니다.

내가 풀었던 방식

public class Main {
    // 방향을 2차원 배열로 생성
    static int[][] dirs = 
        {{0, 1}, {1, 0}, {0, -1}, {-1, 0}};

    // y, x값을 입력받는 내부 class 생성
    static class Node {
        int y, x;

        Node(int y, int x) {
            this.y = y;
            this.x = x;
        }
    }

    public static void main(String[] args) throws Exception {
        BufferedReader br =
                new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st =
                new StringTokenizer(br.readLine());
        int row = Integer.parseInt(st.nextToken());
        int col = Integer.parseInt(st.nextToken());
        // 에어컨을 저장할 List 생성 -> 여러개 에어컨 가능!
        List<Node> airController = new ArrayList<>();
        // 자리들을 저장하는 2차원 배열
        int[][] arr = new int[row][col];

        // 자리 input 및 에어컨을 List에 저장
        for (int i = 0; i < row; i++) {
            st = new StringTokenizer(br.readLine());
            for (int j = 0; j < col; j++) {
                int value = Integer.parseInt(st.nextToken());
                arr[i][j] = value;
                if (value == 9) {
                    airController.add(new Node(i, j));
                }
            }
        }

        // 접근했던 방향 판단용 3차원 boolean 배열 생성
        boolean[][][] v = new boolean[row][col][4];

        int result = 0;
        // 에어컨 별 bfs 실행
        for (Node air : airController) {
            bfs(arr, v, air.y, air.x, row, col);
        }

        // 3차원 배열을 통해 count
        for (boolean[][] vv : v) {
            next:
            for (boolean[] vvv : vv) {
                for (boolean vvvv : vvv) {
                    if (vvvv) {
                        result++;
                        continue next;
                    }
                }
            }
        }

        //출력
        System.out.println(result);
    }

    static void bfs(int[][] arr, boolean[][][] v, int preY, int preX, int row, int col) {
        // queue 생성 및 초기 세팅
        // 4방향으로 이동 가능하니, 0 ~ 3까지 입력
        ArrayDeque<int[]> queue = new ArrayDeque<>();
        for (int i = 0; i < 4; i++) {
            queue.offer(new int[]{preY, preX, i});
            v[preY][preX][i] = true;
        }

        // queue가 비일 때까지 실행
        while (!queue.isEmpty()) {
            int[] qr = queue.poll();
            int d = qr[2];
            int ny = qr[0] + dirs[d][0];
            int nx = qr[1] + dirs[d][1];

            // 배열 내에서 움직일 때
            if (ny >= 0 && ny < row && nx >= 0 && nx < col) {
                // 방향 변환 메소드
                int nd = changeDir(arr, ny, nx, d);

                // 이미 왔던 방향이면 continue
                if (v[ny][nx][nd]) {
                    continue;
                }

                // queue에 input, 방문여부 true
                queue.add(new int[]{ny, nx, nd});
                v[ny][nx][nd] = true;
            }
        }
    }

    // 방향전환 메서드
    static int changeDir(int[][] arr, int y, int x, int d) {
        if (arr[y][x] == 0) {
            return d;
        }

        switch (arr[y][x]) {
            case 1:
                if (d == 0) {
                    d = 2;
                } else if (d == 2) {
                    d = 0;
                }
                break;
            case 2:
                if (d == 3) {
                    d = 1;
                } else if (d == 1) {
                    d = 3;
                }
                break;
            case 3:
                if (d == 0) {
                    d = 3;
                } else if (d == 1) {
                    d = 2;
                } else if (d == 2) {
                    d = 1;
                } else if (d == 3) {
                    d = 0;
                }
                break;
            case 4:
                if (d == 0) {
                    d = 1;
                } else if (d == 1) {
                    d = 0;
                } else if (d == 2) {
                    d = 3;
                } else if (d == 3) {
                    d = 2;
                }
                break;
        }

        return d;
    }
}

문제점

1. switch문 같은 조건문 사용을 통해 일일히 방향전환 진행
2. 3차원 boolean 배열 사용으로 비효율적인 메모리 사용

다른 사람들의 방식

1. 조건문 대신 방향전환용 2차원 배열 사용

   static int[][] convert = { { 0, 0, 2, 1, 3 }, { 0, 3, 1, 0, 2 }, { 0, 2, 0, 3, 1 }, { 0, 1, 3, 2, 0 } };

2. 3차원 boolean 배열 대신 2차원 Byte배열 + 비트마스킹을 통한 visited 파악

   // 4방향 각각 방문 
   boolean[][][] v = new boolean[row][col][4];  
   // 각 칸마다 4비트를 사용 (0000 ~ 1111)
   byte[][] v = new byte[row][col]; 

수정 후 코드

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.util.ArrayDeque;
import java.util.ArrayList;
import java.util.List;
import java.util.StringTokenizer;

public class Main {
    static int[][] dirs = {{0, 1}, {1, 0}, {0, -1}, {-1, 0}};
    static int[][] turns = 
        { { 0, 2, 0, 3, 1 }, 
          { 1, 1, 3, 2, 0 }, 
          { 2, 0, 2, 1, 3 }, 
          { 3, 3, 1, 0, 2 } };

    static class Node {
        int y, x;

        Node(int y, int x) {
            this.y = y;
            this.x = x;
        }
    }

    public static void main(String[] args) throws Exception {
        BufferedReader br =
                new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st =
                new StringTokenizer(br.readLine());
        int row = Integer.parseInt(st.nextToken());
        int col = Integer.parseInt(st.nextToken());
        List<Node> airController = new ArrayList<>();
        int[][] arr = new int[row][col];

        for (int i = 0; i < row; i++) {
            st = new StringTokenizer(br.readLine());
            for (int j = 0; j < col; j++) {
                int value = Integer.parseInt(st.nextToken());
                arr[i][j] = value;
                if (value == 9) {
                    airController.add(new Node(i, j));
                }
            }
        }

        byte[][] v = new byte[row][col];

        int result = 0;
        for (Node air : airController) {
            bfs(arr, v, air.y, air.x, row, col);
        }

        for (int i = 0; i < row; i++) {
            for (int j = 0; j < col; j++) {
                if (v[i][j] != 0) result++;
            }
        }

        System.out.println(result);
    }

    static void bfs(int[][] arr, byte[][] v, int preY, int preX, int row, int col) {
        ArrayDeque<int[]> queue = new ArrayDeque<>();
        for (int i = 0; i < 4; i++) {
            queue.offer(new int[]{preY, preX, i});
            v[preY][preX] |= (1 << i); 
        }

        while (!queue.isEmpty()) {
            int[] qr = queue.poll();
            int d = qr[2];
            int ny = qr[0] + dirs[d][0];
            int nx = qr[1] + dirs[d][1];

            if (ny >= 0 && ny < row && nx >= 0 && nx < col) {
                if(arr[ny][nx] == 9) {
                    continue;
                }

                int nd = turns[d][arr[ny][nx]];

                if ((v[ny][nx] & (1 << nd)) != 0) {
                    continue;
                }

                queue.add(new int[]{ny, nx, nd});
                v[ny][nx] |= (1 << nd);
            }
        }
    }
}

느낀 점

• 그 동안 boolean배열을 습관적으로 사용해왔는데, 비트마스킹의 속도와 메모리 절약을 보고 앞으로는 비트마스킹을 더 적극적으로 사용해야 겠다는 생각이 들어습니다.
• Index를 통한 방향전환은 조건문이 아닌 다른 방식으로 풀 수 있다는 생각의 전환방식을 알게 되었습니다.

• DB에는 상속이라는 개념 ❌

• 대신 그림과 같이 슈퍼타입 서브타입 관계라는 모델링 기법이 가장 유사

• 실제 구현 방법
  • 각각의 Table로 변환 (Join 전략)
    • 각각을 모두 테이블로 만듬
    • 조회 시 조인사용
  • 통합 테이블로 변환 (단일 테이블 전략)
    • 테이블을 하나만 사용해서 통합
  • 서브타입 테이브로 변환 (구현 클래스마다 테이블 전략)
    • 서브 타입마다 하나의 테이블을 만듬

1.1. 조인전략

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(name = "DTYPE")
public abstract class Parent {
 @Id @GeneratedValue
 @Column(name = "Parent_ID")
 private Long id;
 private String name; //이름
 private int price; //가격
}
@Entity
@DiscriminatorValue("C1")
public class Child1 extends Parent {
 private String c_1;
}
@Entity
@DiscriminatorValue("C2")
public class Child2 extends Parent {
 private String c_2; //감독
 private String c_22; //배우
}
@Entity
@DiscriminatorValue("C3")
public class Child3 extends Parent {
 private String c_3; //배우
}

• @Inheritance(strategy = InheritanceType.JOINED)
  • 상속 매핑은 부모 클래스에 @Inheritance를 사용해야 함.
  • 매핑 전략을 지정해야 하는데, 조인 전략을 사용하므로InheritanceType.JOINED를 사용했다.
• @DiscriminatorColumn(name = "DTYPE")
  • 부모 클래스에 구분 컬럼을 지정
  • 이 컬럼으로 저장된 자식 테이블을 구분할 수 있다. 기본값이 DTYPE이므로 @DiscriminatorColumn으로 줄여 사용해도 됨
• @DiscriminatorValue("M")
  • 엔티티를 저장할 때 구분 컬럼에 입력할 값을 지정.
  • 만약 Child3 엔티티를 저장하면 구분 컬럼인 DTYPE에 값 C3이 저장된다.

• 장점
  • 테이블 정규화
  • 외래 키 참조 무결성 제약조건을 활용 가능
  • 저장 공간을 효율적으로 사용
• 단점
  • 조회할 때, 조인이 많이 사용되므로 성능이 저하 가능
  • 조회 쿼리가 복잡
  • 데이터를 등록할 Insert SQL를 두 번 실행

1.2. 단일 테이블 전략

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "DTYPE")
public abstract class Parent {
 @Id @GeneratedValue
 @Column(name = "Parent_ID")
 private Long id;
 private String name;
 private int price;
}

@Entity
@DiscriminatorValue("C1")
public class Child1 extends Parent {
 private String c_1;
}

@Entity
@DiscriminatorValue("C2")
public class Child2 extends Parent {
 private String c_2;
 private String c_22;
}

@Entity
@DiscriminatorValue("C3")
public class Child3 extends Parent {
 private String c_3;
}

• 장점

  • 조인이 필요 ❌ -> 조회 성능이 빠름
  • 조회 쿼리가 단순

• 단점

  • 자식 Entity가 매핑한 컬럼은 모두 null 허용
  • 단일 테이블에 모든 것을 저장하여, 테이블이 커질 수 있음

  • 상황에 따라서는 조회 성능이 오히려 느려짐

• 특징

  • 구분 컬럼을 꼭 사용해야 함

  • @DiscriminatorColumn 설정 필수

  • @DiscriminatorValue를 지정하지 않으면 기본으로 엔티티 이름을 사용

1.3. 구현 클래스마다 테이블 전략

@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class Parent {
 @Id @GeneratedValue
 @Column(name = "Parent_ID")
 private Long id;
 private String name;
 private int price;
}

@Entity
public class Child1 extends Parent {
 private String c_1;
}

@Entity
public class Child2 extends Parent {
 private String c_2;
 private String c_22;
}

@Entity
public class Child3 extends Parent {
 private String c_3;
}

• 장점
  • 서브 타입을 구분해서 처리할 때, 효과정
  • not null 제약조건을 사용
• 단점
  • 여러 자식 테이블을 함께 조회할 때, 성능이 느려짐
  • 자식 테이블을 통합해서 쿼리하기 어려움
• 특징
  • 구분 컬럼을 사용 ❌

2. @MappedSuperclass

@MappedSuperclass
public abstract class Base {
 private String name;
 private Long price;
 ...
}
@Entity
public class Child_1 extends Base {
 private Long id;
 private String c_1;
 ...
}
@Entity
public class Child_2 extends Base {
 private Long id;
 private String c_2;
 private String c_22;
}
@Entity
public class Child_3 extends Base {
 private Long id;
 private String c_3;
}

• 부모 클래스는 테이블 매핑 ❌, 자식 클래스에게 매핑 정보만 제공!

• @MappedSuperclass

• @MappedSuperclass를 비유하자면 추상클래스와 비슷

• 매핑 정보를 상속할 목적으로만 사용

1.1. 단방향

@Entity
@Data
public class A {
    @Id
    @Column(name = "A_ID")
    private Long id;

    @ManyToOne
    @JoinColumn(name = "B_ID")
    private B b;

    private String aa;
}

-- 🔺는 A 클래스 , 🔻는 B클래스

@Entity
@Data
public class B {
    @Id
    @Column(name = "B_ID")
    private Long id;

    private String bb;
}

1.2. 양방향

@Entity
@Data
public class A {
    @Id
    @Column(name = "A_ID")
    private Long id;

    @ManyToOne
    @JoinColumn(name = "B_ID")
    private B b;

    private String aa;
}

-- 🔺는 A 클래스 , 🔻는 B클래스

@Entity
@Data
public class B {
    @Id
    @Column(name = "B_ID")
    private Long id;

    @OneToMany(mappedBy = "b")
    private List<A> a_list = new ArrayList<>();

    private String bb;
}

2. 일대다

2.1. 단방향

⭐ 단점 매핑한 객체가 관리하는 외래 키가 다른 테이블에 있음 연관관계 처리를 위해 UPDATE SQL이 추가로 실행

@Entity
@Data
public class A {
    @Id
    @Column(name = "A_ID")
    private Long id;

    private String aa;
}

-- 🔺는 A 클래스 , 🔻는 B클래스

@Entity
@Data
public class B {
    @Id
    @Column(name = "B_ID")
    private Long id;

    @OneToMany(mappedBy = "b")
    private List<A> a_list = new ArrayList<>();

    private String bb;
}

2.2. 양방향

• 일대다 양방향 매핑은 존재하지 않는다.
• 불가능은 아니지만 일대다의 단점을 그대로 가짐

3. 일대일

• 양쪽이 서로 하나의 관계만 가짐
• 주 Table, 대상 Table 둘 중 어느 곳이나 외래 키를 가질 수 있음
• 주 Table 외래 키
  • 확인해도 대상 테이브과 연관관계가 있는 지 알 수 있음
• 대상 Table 외래 키
  • DB 관계를 일대일에서 일대다로 변경할 때, 테이블 구조를 그대로 유지가능

3.1. 주 테이블 단방향

@Entity
@Data
public class A {
    @Id
    @Column(name = "A_ID")
    private Long id;

    @OneToOne
    @JoinColumn(name = "B_ID")
    private B b;

    private String aa;
}

-- 🔺는 A 클래스 , 🔻는 B클래스

@Entity
@Data
public class B {
    @Id
    @Column(name = "B_ID")
    private Long id;

    private String bb;
}

3.2. 대상 테이블 단방향

• 일대일 관계 중 대상 테이블에 외래 키가 있는 단방향 관계는 JPA에서 지원하지 않음

3.3. 주 테이블 양방향

@Entity
@Data
public class A {
    @Id
    @Column(name = "A_ID")
    private Long id;

    @OneToOne
    @JoinColumn(name = "B_ID")
    private B b;

    private String aa;
}

-- 🔺는 A 클래스 , 🔻는 B클래스

@Entity
@Data
public class B {
    @Id
    @Column(name = "B_ID")
    private Long id;

    @OneToOne(mappedBy = "b")
    private A a;

    private String bb;
}

3.4. 대상 테이블 양방향

@Entity
@Data
public class A {
    @Id
    @Column(name = "A_ID")
    private Long id;

    @OneToOne(mappedBy = "a")
    private B b;

    private String aa;
}

-- 🔺는 A 클래스 , 🔻는 B클래스

@Entity
@Data
public class B {
    @Id
    @Column(name = "B_ID")
    private Long id;

    @OneToOne
    @JoinColumn(name = "A_ID")
    private A a;

    private String bb;
}

4. 다대다

• RDB는 정규화된 Table 2개로 다대다 관계를 표현할 수 없다

• 그래서 보통 다대일, 일대다로 풀어내는 연결 테이블 사용

4.1. 단방향

@Entity
@Data
public class A {
    @Id
    @Column(name = "A_ID")
    private Long id;

    @ManyToMany
    @JointTable(name = "B",
                joinColums = @JoinColumn(name = "A_ID"),
                inverseJoinColumns = @JoinColumn(name = "B_ID"))
    private List<B> b_list = new ArrayList<>();

    private String aa;
}

-- 🔺는 A 클래스 , 🔻는 B클래스

@Entity
@Data
public class B {
    @Id
    @Column(name = "B_ID")
    private Long id;

    private String bb;
}

• @ManyToMany와 @JoinTable을 사용해서 연결 테이블을 바로 매핑
• @JoinTable
  • name : 연결할 테이블 지정
  • joinColumns : 현재 방향인 A와 매핑할 조인 컬럼 정보 지정
  • inverseJoinColumns : 반대 방향인 B와 매핑할 조인 컬럼 정보 지정

4.2. 양방향

@Entity
@Data
public class A {
    @Id
    @Column(name = "A_ID")
    private Long id;

    @ManyToMany
    @JointTable(name = "B",
                joinColums = @JoinColumn(name = "A_ID"),
                inverseJoinColumns = @JoinColumn(name = "B_ID"))
    private B b;

    private String aa;
}

-- 🔺는 A 클래스 , 🔻는 B클래스

@Entity
@Data
public class B {
    @Id
    @Column(name = "B_ID")
    private Long id;

    @ManyToMany(mappedBy = "a_list")
    private List<A> a_list = new ArrayList<>();

    private String bb;
}

4.3. 연결 엔티티 사용

• @ManyToMany를 사용하면 연결 테이블을 자동 처리해주므로 도메인 모델이 단순

• 실무에서 사용하기에는 한계가 있음

• 위 그림처럼 컬럼을 추가하면 @ManyToMany를 사용 ❌

• A or B Entity에는 추가한 컬럼을 매핑 ❌

💡 양방향으로 진행해야 함

4.4. 새로운 기본 키 사용

@Entity
@Data
public class AB {
    @Id
    @Column(name = "AB_ID")
    private Long id;

    @ManyToOne
    @JoinColumn(name = "A_ID")
    private A a;

    @ManyToOne
    @JoinColumn(name = "B_ID")
    private B b;
}

1. 방향
   • 단방향 : 둘 중 한 쪽만 참조하는 것
   • 양방향 : 양쪽 모두 서로 참조하는 것
2. 다중성 (M / N)
   • 다대일 : M 여러개가 N 하나에 속한다.
   • 일대다 : N 여러개가 M 하나에 속한다.
   • 일대일 : M 하나가 N 하나에 속한다.
   • 다대다 : M 여러개가 N 여러개에 속한다.
3. 연관관계의 주인
   • 연관관계의 주인 : 객체를 양방향 연관관계로 만들면 주인을 정해야 한다.

단방향에서의 연관관계

객체

• 참조(주소)로 연관관계를 맺음
• 객체 A는 A.b필드로 B객체와 연관관계
• A는 B 파악 가능, B는 A 파악 불가능
• 객체 그래프 탐색
  • 객체는 참조를 사용해서 연관관계를 탐색

테이블

• 테이블은 외래키로 연관관계를 맺음
• A 테이블은 B_ID 외래 키로 팀 테이블로 연관관계
• A와 B는 양방향, 양쪽은 외래키로 Join 가능

객체와 테이블의 연관관계의 차이!

1. 참조를 통한 연관관계는 언제나 단방향

-> 결국, 연관관계를 추가해서 양쪽 참조를 해야 함 2. 단, 참조를 통한 양쪽 참조 != 양방향 관계 -> 서로 다른 단방향 2개

객체 관계 매핑

@Entity
@Data
public class A {
    @Id
    @Column(name = "A_ID")
    private Long id;

    @ManyToOne
    @JoinColumn(name = "B_ID")
    private B b;

    private String aa;
}

// 🔺는 A 클래스 , 🔻는 B클래스

@Entity
@Data
public class B {
    @Id
    @Column(name = "B_ID")
    private Long id;

    private String bb;
}

• @ManyToOne
  • 다대일 관계라는 매핑 정보
  • 연관관계를 매핑할 때, 다중성을 나타내는 Annotation 필수
• @JoinColumn
  • 조인 컬럼은 오래키를 매핑할 때 사용
  • name속성

  • 매핑할 외래키 지정

  • 생략가능

  • 생략 시, 찾는 기본 전략 (필드명_참조테이블컬럼명)

연관관계 사용

저장

• A Entity에서 B Entity를 참조 후 저장한다고 가정

• JPA는 참조한 B의 식별자를 외래 키로 사용해서 등록쿼리 생성

• 실행된 SQL에는 B의 식별자가 입력

제거

• 삭제 전 기존의 연관관계를 먼저 제거해야 함

• 안하면 외래 키 제약조건으로 DB Error

양방향 연관관계

객체

• 일대다 관계는 여러 건과 연관관계를 맺을 수 있음

• Collection을 사용해야 함 (List, Set, Map 등등)

테이블

• DB은 외래 키 하나로 양방향 조회가능, 이전 관계와는 차이 ❌

객체 관계 매핑

@Entity
@Data
public class A {
    @Id
    @Column(name = "A_ID")
    private Long id;

    @ManyToOne
    @JoinColumn(name = "B_ID")
    private B b;

    private String aa;
}

// 🔺는 A 클래스 , 🔻는 B클래스

@Entity
@Data
public class B {
    @Id
    @Column(name = "B_ID")
    private Long id;

    @OneToMany(mappedBy = "b")
    private List<A> b = new ArrayList<>();

    private String bb;
}

연관관계의 주인

• 테이블은 외래 키 하나로 연관관계 관리

• 객체는 두 객체간 서로를 참조

• 어떤 관계를 사용해서 외래 키를 관리해야할까? JPA에서는 두 객체 연관관계 중 하나를 정해서 테이블의 외래 키 관리를 지시

• 두 연관관계 중 하나를 연관관계의 주인으로 정해야 함

  • 주인 ⭕ : DB 연관관계와 Mapping, 외래키를 관리 (CUD)
  • 주인 ❌ : Only Read
  • mappedBy로 Setting -> 주인이 아닌 Entity에서 사용 💡 다대일, 일대다 관계는 항상 다 쪽이 주인!

양방향 연관관계의 주의점

• 연관관계의 주인에는 값을 입력하지 않고, 주인이 아닌 곳에만 값을 입력하는 것

public class Main {
    public static void main(String[] args) {
        EntityManagerFactory emf =
            Persistence.createEntityManagerFactory("myJpaUnit");
        EntityManager em = emf.createEntityManager();
        EntityTransaction transaction = em.getTransaction();

        try {
            transaction.begin();

            B bc = new B(1L, new ArrayList<>(), "firstB");
            A ac1 = new A(1L, null, "firstA");
            A ac2 = new A(2L, null, "secondA");

            bc.getA().add(ac1);
            bc.getA().add(ac2);

            // 비영속 -> 영속
            em.persist(bc);
            // DB에 데이터 저장
            transaction.commit();

            // find -> 1차 캐시에 영속 Entity 존재하므로 1차캐시에서 Get
            /*
            B(
              id=1, 
              a=[
                A(id=1, b=null, aa=firstA), 
                A(id=2, b=null, aa=secondA)
              ], 
              bb=firstB
            )
            */ 
            System.out.println(em.find(B.class, 1L));

            // 영속 -> 준영속
            em.detach(bc);

            // find -> 1차 캐시에 영속 Entity ❌, DB에서 1차 캐시에 영속 Entity 저장 후 1차 캐시에서 Get
            // B(id=1, a=[], bb=firstB)
            System.out.println(em.find(B.class, 1L));
        } catch (Exception e) {
            System.out.println(e.getMessage());
        } finally {
            em.close();
        }
    }
}

그럼 주인 아닌 곳에 설정 X?

• 객체 관점에서 양쪽 방향에 모두 값을 입력해주는 것이 가장 안정

• 순수한 객체 상태에서 심각한 문제 발생! 💡 객체의 양방향 연관관계는 양쪽 모두 관계를 맺어주자