이 문제는 힌트를 봤따... 사실 dp와 다익스트라 중에서 고민했는데(지름길 문제랑 비슷하다고 느껴서) 그렇게 생각하니까 구현이 좀 막막하게 느껴지고 묘하게 불편하게 느껴졌다...어떻게 구현해야되지? 그냥 그런생각이 들었는데 힌트를 보니 bfs 문제였다.

이 문제가 너비 탐색인 이유는

1. 주사위 비용은 모두 1로 고정이 되어있음 -> 다익스트라 x
2. 100으로 가는 최단 거리 -> bfs 너비 탐색
3. 뱀과 사다리로인해, 사이클(그래프)과 같은 형상이 될 수 있기 때문에 dp로 풀기 어려울 것 -> dp x
4. 시간복잡도 충분 -> dp x

그래서 결론적으로 너비 우선 탐색 그래프 탐색 문제이다.

결론적으로 이 문제의 핵심은 bfs를 떠올릴 것. 그리고 내가 실수한 부분은 또 이부분이다.

 // 특수성이 존재하니?
                if (mapCase.containsKey(next)) {
                    next = mapCase.get(next);
                }
                if (dist.containsKey(next)) {
                    // 이미 탐색함
                    continue;
                }

방문 체크를 하기 전에, 뱀 또는 사다리가 있는 부분인지 확인했어야됐는데 나는 저 if문 두개의 순서를 반대로 했었다.

이 부분을 유의해야지 논리적인 오류가 나지 않는다.

그리고 이 문제는 주사위 dx = {1, 2, 3, 4, 5, 6} 이런식으로 만들어서 그래프 탐색을 해줘야 하는게 포인트다

끝.

터무니 없는 n의 길이를 보고... 이분탐색인가 했다. 요즘 이분탐색 문제를 자주 풀고 있는데... 뭔가 유형별로 정리가 필요할 거 같아서 정리해본다.

0. 기본 이분탐색 (값이 존재하는가)

   int l = 0, r = n - 1;
   

while (l <= r) { int mid = (l + r) / 2; if (arr[mid] == target) { // 찾음 break; } else if (arr[mid] < target) { l = mid + 1; } else { r = mid - 1; } }

## 인덱스  유형
### Lower Bound
target 이상이 처음 나오는 위치

```java
int l = 0, r = n;

while (l < r) {
    int mid = (l + r) / 2;
    if (arr[mid] >= target) {
        r = mid;
    } else {
        l = mid + 1;
    }
}
// l이 답

Upper Bound

target 초과가 처음 나오는 위치

int l = 0, r = n;

while (l < r) {
    int mid = (l + r) / 2;
    if (arr[mid] > target) {
        r = mid;
    } else {
        l = mid + 1;
    }
}
// l이 답

값의 범위 유형

First True(최소 만족 값)

int l = 0, r = n;

while (l < r) {
    int mid = (l + r) / 2;
    if (arr[mid] > target) {
        r = mid;
    } else {
        l = mid + 1;
    }
}
// l이 답

Last True(최대 만족 값)

int l = left, r = right;
int ans = -1;

while (l <= r) {
    int mid = (l + r) / 2;
    if (check(mid)) {
        ans = mid;
        l = mid + 1;
    } else {
        r = mid - 1;
    }
}
System.out.println(ans);

그렇다면 이 문제는...

9999 10000 100000 100000 9999이상인 값이 제일 처음으로 나오는 위치가 답이다. 따라서 Lower Bound 유형

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.*;

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

        int count = Integer.parseInt(st.nextToken());
        int cCount = Integer.parseInt(st.nextToken());

        ArrayList<Title> titles = new ArrayList<>();

        for (int i = 0; i < count; i++) {
            st = new StringTokenizer(br.readLine());
            titles.add(new Title(st.nextToken(), Long.valueOf(st.nextToken())));
        }
        titles.sort(Comparator.comparing(title -> title.limit));
        StringBuilder sb = new StringBuilder();

        for (int i = 0; i < cCount; i++) {
            Long power = Long.valueOf(br.readLine());

            int left = 0;
            int right = titles.size() - 1;

            while (left < right) {
                int mid = (right + left) / 2;
                Title now = titles.get(mid);

                if (now.limit >= power) {
                    right = mid;
                    continue;
                }
                left = mid + 1;
            }
            sb.append(titles.get(left).name);
            sb.append("\n");
        }
        System.out.println(sb);
    }

    public static class Title {
        String name;
        Long limit;

        public Title(String name, Long limit) {
            this.name = name;
            this.limit = limit;
        }
    }
}

생각했던 로직

1. 밖에서 number를 생성하고
2. 해당 number에 해당하는 것이 있는지 sb에 contains로 확인

but >> 부분 수열을 가정하고 만들었기 때문에 틀렸음. 1001 이렇게 있어도 11 이렇게만 남을 수 있기 떄문에 1001을 for문으로 붙잡고 포함되었는지를 확인 했어야됐다.

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

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

        String number = br.readLine();
        char[] arr = number.toCharArray();
        Deque<Character> deque = new ArrayDeque<>();

        int k = 1;

        for (char a : arr) {
            deque.add(a);
        }

        while (!deque.isEmpty()) {
            check(k, deque);
            k++;
        }

        System.out.println(k - 1);
    }

    public static void check(int number, Deque<Character> deque) {
        String targetNumber = Integer.toString(number);
        StringBuilder sb = new StringBuilder();

        while (!deque.isEmpty()) {
            Character now = deque.removeFirst();
            sb.append(now);

            if (targetNumber.length() == sb.length()) {
                if (targetNumber.contains(sb)) {
                    return;
                }
                deque.addFirst(now);
                return;
            }
            if (!targetNumber.contains(sb)) {
                deque.addFirst(now);
                return;
            }
        }

        return;
    }
}

• 다시풀이

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

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

        String number = br.readLine();

        int idx = 0;

        //1234
        for (int i = 1; ; i++) {
            String num = Integer.toString(i);

            for (int j = 0; j < num.length(); j++) {
                if (idx < number.length() && num.charAt(j) == number.charAt(idx)) {
                    idx++;
                }
            }
            if (idx >= number.length()) {
                System.out.println(i);
                return;
            }
        }
    }
}

이 문제는 '이분탐색'으로 풀어야되는 문제임

일부 테스트케이스는 맞았지만, 실제로는 틀렸음

import java.io.*;
import java.util.*;
import javax.swing.Icon;

public class Main {
    public static void main(String[] args) throws IOException {
        /*
         * 총액 이하에서 가능한 한 최대의 총 에싼을 배정
         *
         * 1. 모든 요청이 배정될 수 있는 경우에는 요청한 금액을 그대로 배정
         * 2. 모든 요청이 배정될 수 없는 경우에는 특정한 정수 상한액을 계산하여, 그 이상인 예상 요청에는 모두 상한액을 배정
         * 상한액 이하의 예산요청에 대해서는 요청한 금액을 그대로 배정
         *
         * o(n)으로 풀어야함
         *
         * 520 - 485 = 35 오바
         * 485 ->
         * 121
         * -1, -11, +19, + 29
         * - 12 / 남은 개수
         * 평균보다 6씩 더주기
         * +48 인 상황인데
         * */

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        int n = Integer.parseInt(br.readLine());

        StringTokenizer st = new StringTokenizer(br.readLine());
        PriorityQueue<Integer> numbers = new PriorityQueue<>(Comparator.reverseOrder());

        int total = 0;
        for (int i = 0; i < n; i++) {
            int number = Integer.parseInt(st.nextToken());
            numbers.add(number);
            total += number;
        }

        int limit = Integer.parseInt(br.readLine());

        if (limit >= total) {
            System.out.println(numbers.remove());
            return;
        }

        int limitAvg = limit / n;
        int overCount = 0;
        int underScore = 0;

        int under = 0;
        while (!numbers.isEmpty()) {
            int number = numbers.remove();

            if (number > limitAvg) {
                overCount++;
            } else {
                int temp = limitAvg - number;
                underScore += temp;
                under += number;
            }
        }
        int result = limitAvg + (underScore / overCount);
        if (overCount == n) {
            System.out.println(limitAvg);
            return;
        }
        System.out.println(result);
    }
}

계속해서 최적의 해를 찾아가는 것이기 떄문에 적절함

• 초안 최적화 하지 않았음

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

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int n = Integer.parseInt(br.readLine());
        StringTokenizer st = new StringTokenizer(br.readLine());
        int[] requests = new int[n];

        for (int i = 0; i < n; i++) {
            requests[i] = Integer.parseInt(st.nextToken());
        }

        int limit = Integer.parseInt(br.readLine());

        Arrays.sort(requests);

        int answer = 0;
        int left = 0;
        int right = requests[requests.length - 1];

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

            for (int request : requests) {
                sum += Math.min(request, mid);
            }

            if (sum <= limit) {
                left++;
                answer = Math.max(answer, mid);
            } else {
                right--;
            }
        }
        System.out.println(answer);
    }
}

• 최적화 ver mid보다 큰 애들은 상한값 처리 하고, 나머지는 누적합처리해서 계속해서 계산해야되는 부분을 최적화했음

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

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

        int n = Integer.parseInt(br.readLine());
        StringTokenizer st = new StringTokenizer(br.readLine());

        int[] requests = new int[n];
        int max = 0;
        int total = 0;

        for (int i = 0; i < n; i++) {
            int number = Integer.parseInt(st.nextToken());
            requests[i] = number;
            max = Math.max(max, number);
            total += number;
        }

        int limit = Integer.parseInt(br.readLine());

        if (limit >= total) {
            System.out.println(max);
            return;
        }

        Arrays.sort(requests);

        int left = 0;
        int right = requests[requests.length - 1];
        int answer = 0;
        int[] sumArr = new int[n];

        for (int i = 0; i < n - 1; i++) {
            sumArr[i + 1] = sumArr[i] + requests[i];
        }

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

            int idx = underScore(requests, mid);
            int sum = sumArr[idx] + (mid * (n - idx));

            if (sum <= limit) {
                answer = mid;
                left = left + 1;
            }
            else {
                right = right - 1;
            }
        }
        System.out.println(answer);
    }

    public static int underScore(int[] requests, int target) {
        int left = 0;
        int right = requests.length - 1;

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

            if (requests[mid] <= target) {
                left++;
            } else {
                right = mid;
            }
        }
        return left;
    }
}

완전탐색 + 구현 문제

시간 복잡도를 고려해야 한다는 조건이 나오지 않았기 때문에 위와 같이 코드를 작성했다.

간단한 로직 설명

1. list는 생성 된 room들을 담는 것. 무조건 생성 순서로 쌓이는 것이 보장됨
2. 방 생성
   • list가 비어있을 경우 -> 생성 되어 있는 room이 없는 경우
   • user에 맞게 매치되는 방이 없는 경우, room을 생성
3. 방 매칭
   • 만원 방 빼고 방 매칭
   • 매칭 안 될 경우 2 다시 수행

20006 랭킹전 대기열

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

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

    // 최대 60만
    /*
     * 모든 명령어를 수행하고 편집기에 입력되어있는 문자열은?
     * O(n)
     * */
    LinkedList<String> list = new LinkedList<>();
    String data = br.readLine();
    String[] dataArr = data.split("");

    for (int i = 0; i < dataArr.length; i++) {
        list.add(i, dataArr[i]);
    }

    int n = Integer.parseInt(br.readLine());

    int size = list.size();
    int cursor = size;

    for (int i = 0; i < n; i++) {
        StringTokenizer st = new StringTokenizer(br.readLine());
        String operator = st.nextToken();

        if (operator.equals("P")) {
            String word = st.nextToken();

            list.add(cursor, word);
            size++;
            cursor++;
            continue;
        }
        if (operator.equals("L")) {
            if (cursor == 0) {
                continue;
            }
            cursor--;
            continue;
        }
        if (operator.equals("D")) {
            if (cursor == size) {
                continue;
            }
            cursor++;
            continue;
        }
        if (operator.equals("B")) {
            if (cursor == 0) {
                continue;
            }
            size--;
            list.remove(cursor - 1);
            cursor--;
        }
    }

    StringBuilder sb = new StringBuilder();
    for (String s : list) {
        sb.append(s);
    }

    System.out.print(sb);
}

}

처음에는. 중간에서 삽입 삭제를 하기 편한 linkedlist를 사용했다.
그러나 

| 동작                               | ArrayList      | LinkedList                    |
| -------------------------------- | -------------- | ----------------------------- |
| 임의 인덱스 접근 (`get(i)`)             | O(1)        | O(n)(i번째까지 이동 필요)      |
| 중간 삽입/삭제 (`add(i)`, `remove(i)`) | O(n) (뒤 요소 밀기) | O(n) (i까지 이동 후 포인터 연결) |
| 앞/뒤 삽입 (`addFirst`, `addLast`)   | O(1) | O(1)                          |
| Iterator 삽입/삭제                   | O(1)           | O(1)                          |


자료구조 시간 복잡도를 모르고 있었다. 중간 삽입 삭제가 O(n)이 걸린다. 그래서 이 문제는 O(n) 수준으로 풀어야되는데, O(n^2) 이상으로 풀고 있었던 것이다.

<br>
<br>
<br>

### 해결 방법(1)

1. listIterator 사용

| 항목       | LinkedList                      | ListIterator                   |
| -------- | ------------------------------- | ------------------------------ |
| 내부 구조    | 이중 연결 리스트 (prev / value / next) | 연결 리스트의 **노드를 직접 참조하는 커서**     |
| 위치 접근 방식 | 인덱스로 접근 → 노드 탐색 필요              | 현재 커서 노드를 기억하므로 탐색 없음          |
| 주요 목적    | 자료 저장                           | 리스트 순회 + 편집                    |
| 양방향 이동   | 가능하지만 `get(i)`는 O(N)            | `next()`, `previous()` 모두 O(1) |

<br>


| 연산            | LinkedList (인덱스 기반)    | LinkedList + ListIterator |
| ------------- | ---------------------- | ------------------------- |
| get(i)        | O(N)                 | O(1) (커서가 이미 위치를 알고 있음) |
| add(index, x) | O(N) (index까지 탐색 필요) | O(1)                    |
| remove(index) | O(N)                 | O(1)                    |
| 이전 요소 이동      | O(N) → get(i-1)      | previous() → O(1)       |
| 다음 요소 이동      | O(N) → get(i+1)      | next() → O(1)           |

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

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        LinkedList<Character> list = new LinkedList<>();
        String data = br.readLine();

        for (char d : data.toCharArray()) {
            list.add(d);
        }

        int n = Integer.parseInt(br.readLine());
        ListIterator<Character> li = list.listIterator(list.size());

        for (int i = 0; i < n; i++) {
            String line = br.readLine();
            char operator = line.charAt(0);

            if (operator == 'P') {
                char x = line.charAt(2);
                li.add(x);
                continue;
            }
            if (operator == 'L') {
                if (!li.hasPrevious()) {
                    continue;
                }
                li.previous();
                continue;
            }
            if (operator == 'D') {
                if (!li.hasNext()) {
                    continue;
                }
                li.next();
                continue;
            }
            if (operator == 'B') {
                if (!li.hasPrevious()) {
                    continue;
                }
                li.previous();
                li.remove();
            }
        }

        StringBuilder sb = new StringBuilder();
        for (char c : list) {
            sb.append(c);
        }
        System.out.print(sb.toString());
    }
}

해결 방법(2)

deque 2개를 이용해서 left의 마지막은 cursor 위치로 고정 -> O(n) 수준으로 풀이 가능

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

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

        Deque<Character> left = new ArrayDeque<>();
        Deque<Character> right = new ArrayDeque<>();

        String data = br.readLine();

        for (char d : data.toCharArray()) {
            left.add(d);
        }

        int n = Integer.parseInt(br.readLine());

        for (int i = 0; i < n; i++) {
            String line = br.readLine();
            char operator = line.charAt(0);

            if (operator == 'P') {
                char x = line.charAt(2);
                left.add(x);
                continue;
            }
            if (operator == 'L') {
                if (left.isEmpty()) {
                    continue;
                }
                right.addFirst(left.removeLast());
                continue;
            }
            if (operator == 'D') {
                if (right.isEmpty()) {
                    continue;
                }
                left.addLast(right.removeFirst());
                continue;
            }
            if (operator == 'B') {
                if (left.isEmpty()) {
                    continue;
                }
                left.removeLast();
            }
        }

        StringBuilder sb = new StringBuilder();

        while (!left.isEmpty()) {
            sb.append(left.remove());
        }
        while (!right.isEmpty()) {
            sb.append(right.remove());
        }
        System.out.print(sb);
    }
}

1406 에디터

주목할 점

1. 주식을 하나밖에 못 산다.
2. 원하는 만큼 가지고 있는 주식을 판다.
3. 아무것도 안한다.

하루에 할 수 있는 action은 한 개 이고, 주식은 무조건 하루에 하나 밖에 사지 못한다. 우리는 미래의 주식 가격을 아니까, 미래부터 과거로 순회하면서 O(n)으로 풀이를 진행할 수 있다.

하루에 주식을 하나밖에 못사니까, 미래의 최대 가격보다 낮으면 사서 차곡 차곡 수익을 만드는 것이 이득이다.

우리가 해야될 것은,

1. 미래의 최대가격을 갱신
2. 미래 가격보다 저렴하다면 수익실현

이 두가지만 코드로 구현해내면 된다.

• 못풀었던 이유 아이디어 부족.. 최대값을 도출

• 출처 백준 11501

• 비슷한 문제 프로그래머스 주식가격

사용자가 보조지표와 지표 블록(EMA, RSI, MACD, 거래량 등)을 조합해 자신만의 매매 전략을 구성하고 이를 실시간으로 실행할 수 있도록 설계했습니다.

저희 시스템 아키텍처를 보면 위와 같이 구성되어있습니다.

기술 선정

주요 포인트

(1) 1전략 1파드

저희는 사용자 전략마다 pod를 1개씩 띄웁니다. 그렇게 생각한 이유는, kafka에서 지표, 보조지표, 시세데이터들이 뿌려질 때마다 사용자들의 전략이 실행되어야합니다.

그리고, 그 전략에 알맞는 상황일 경우 매매를 수행하고 전략을 꺼야되는데, 실시간 성을 살리고 전략끼리의 독립성을 유지하기 위해서 pod를 여러개를 띄우는 구조로 정했습니다.

(2) kafka 사용

market module에서 시세데이터를 받아서 모든 보조지표와 지표를 계산해서 pod들에게 뿌려줘야합니다. 따라서, 여러 pod들에게 빠르게 실시간으로 전달해야 됐기 떄문에 kafka를 사용했습니다.

저희는 토픽을 설계할 때, [주식 ticker].[봉단위]로 이름 지어서 토픽을 발행 하고 있습니다. 따라서, pod들은 자신에 맞는 ticker topic만 consume하는 구조로 설계되어있습니다

(3) 전략 json 저장에, mogodb 사용

{
    "strategy_name": "전략 이름",
    "version": 1,
    "owner_id": "user_123",
    "meta": {
        "universe": ["005930"], // 종목정보
        "enabled": true // 실행 여부
    },
    "buy": { // 매수 블록
        "node": {
            "type": "GROUP",
            "logic": "ALL",
            "label": "BUY ROOT: 볼린저 밴드 상단 돌파",
            "children": [
                {
                    "type": "CROSS",
                    "label": "A1: close(15m) CROSS UP BB.upper(20, 2, 15m)",
                    "direction": "UP",
                    "left": {
                        "kind": "PRICE",
                        "field": "close",
                        "timeframe": "15m"
                    },
                    "right": {
                        "kind": "INDICATOR",
                        "name": "BOLLINGER_BANDS",
                        "args": { "period": 20, "stddev": 2 },
                        "subfield": "upper",
                        "timeframe": "15m"
                    }
                }
            ]
        }
    }
}

저희의 전략 json은 다양한 조합으로 구성됩니다. 사용자의 요청에 따라 다양한 형태의 json으로 오기 때문에, rdb에 이것을 저장하기에는, key마다 쪼개야 하는 것도 많고 복잡하기 때문에, 연산량도 너무 많을 것이라고 생각했습니다.

따라서, mongodb에 이것을 저장해서 관리하게 된다면, 유저가 다양한 조합을 주더라도 그대로 저장할 수 있을 것이라고 생각해서 mongodb를 사용해서 저장하기로 결정했습니다.

(4) Redis 사용

저희 서비스에서는, Redis를 통해 중앙에서 토큰을 관리합니다. 이를 통해, 여러 서비스가 동일한 토큰을 공유하고 만료 시점을 일괄적으로 갱신할 수 있습니다.

특히 백엔드에서 redis를 사용할 때, read와 write를 나눠서, 모듈마다 쓰기 제한을 하도록 구성했습니다.

• 공통 모듈에서는 read만

• auth 모듈에서는 write, read 둘 다

그리고 auth 서버에서만 redis에 write 가능하도록 구성해서 책임을 분리했습니다.

(5) 주식 주문 — Event Driven 구조

1. 주문 생성 후 DB 저장 및 이벤트 발행

2. 이벤트가 발행 될 경우, 한국투자증권 API 주문 전송 (매수/매도 처리)

왜 이렇게...헀나요..?

• 주문 생성과 KIS 주문 로직 분리로 결합도 낮춤
• 비동기 처리로 사용자 응답 속도 향상
• 주문 생성과 KIS 주문을 트랜잭션 분리 → 데이터 일관성 보장

저희 서비스의 시세데이터 아키텍처는 다음과 같습니다.

저희 서비스는 유저가 전략을 생성하고, 전략마다 pod 1개가 할당되는 구조입니다.

따라서, pod가 스스로 전략에 대한 조건을 체크하기 위해서 중앙에서 시세를 내려줘야 합니다.

프로젝트 모듈 중, 시세 데이터를 수집해 pod에게 뿌려주는 모듈을 market-service로 정의했고

한국투자증권의 체결 데이터를 구독해서, 실시간 체결가를 1분봉으로 계산하는 구조로 아키텍처를 구성했습니다.

구현 방법

• 중앙 시세 서버에 체결가 시세가 내려옴
• 중앙 시세 서버에서 1분봉으로 만든다
• 보조지표를 계산한 다음에 전략 pod들한테 뿌린다

실시간으로 체결가 가져오기

한국투자증권 실시간 체결가

위 api를 통해서 한국투자증권 체결가를 구독하면, 체결가가 실시간으로 내려옵니다.

한투 api 틱단위로 제공해주는 것

주요 필드 매핑

  class ResponseBody:
    MKSC_SHRN_ISCD: str    #유가증권 단축 종목코드
    STCK_CNTG_HOUR: str    #주식 체결 시간
    STCK_PRPR: float    #주식 현재가
    PRDY_VRSS_SIGN: str    #전일 대비 부호
    PRDY_VRSS: float    #전일 대비
    PRDY_CTRT: float    #전일 대비율
    WGHN_AVRG_STCK_PRC: float    #가중 평균 주식 가격 (VWAP)
    STCK_OPRC: float    #주식 시가
    STCK_HGPR: float    #주식 최고가
    STCK_LWPR: float    #주식 최저가
    ASKP1: float    #매도호가1
    BIDP1: float    #매수호가1
    CNTG_VOL: float    #체결 거래량
    ACML_VOL: float    #누적 거래량
    ACML_TR_PBMN: float    #누적 거래 대금
    SELN_CNTG_CSNU: float    #매도 체결 건수
    SHNU_CNTG_CSNU: float    #매수 체결 건수
    NTBY_CNTG_CSNU: float    #순매수 체결 건수
    CTTR: float    #체결강도
    SELN_CNTG_SMTN: float    #총 매도 수량
    SHNU_CNTG_SMTN: float    #총 매수 수량
    CCLD_DVSN: str    #체결구분
    SHNU_RATE: float    #매수비율
    PRDY_VOL_VRSS_ACML_VOL_RATE: float    #전일 거래량 대비 등락율
    OPRC_HOUR: str    #시가 시간
    OPRC_VRSS_PRPR_SIGN: str    #시가대비구분
    OPRC_VRSS_PRPR: float    #시가대비
    HGPR_HOUR: str    #최고가 시간
    HGPR_VRSS_PRPR_SIGN: str    #고가대비구분
    HGPR_VRSS_PRPR: float    #고가대비
    LWPR_HOUR: str    #최저가 시간
    LWPR_VRSS_PRPR_SIGN: str    #저가대비구분
    LWPR_VRSS_PRPR: float    #저가대비
    BSOP_DATE: str    #영업 일자
    NEW_MKOP_CLS_CODE: str    #신 장운영 구분 코드
    TRHT_YN: str    #거래정지 여부
    ASKP_RSQN1: float    #매도호가 잔량1
    BIDP_RSQN1: float    #매수호가 잔량1
    TOTAL_ASKP_RSQN: float    #총 매도호가 잔량
    TOTAL_BIDP_RSQN: float    #총 매수호가 잔량
    VOL_TNRT: float    #거래량 회전율
    PRDY_SMNS_HOUR_ACML_VOL: float    #전일 동시간 누적 거래량
    PRDY_SMNS_HOUR_ACML_VOL_RATE: float    #전일 동시간 누적 거래량 비율
    HOUR_CLS_CODE: str    #시간 구분 코드
    MRKT_TRTM_CLS_CODE: str    #임의종료구분코드
    VI_STND_PRC: float    #정적VI발동기준가

시세데이터가 위와같이 틱단위로 내려오게 되면, 이것을 체결가를 STCK_CNTG_HOUR(체결시간)을 쌓았다가 1분 단위로 분봉 데이터를 만들어, 보죄표를 계산합니다.

저희가 계산해야되는 보조지표는,

틱 단위 체결 데이터로 1분봉 만들기

[Step 1] 시세 데이터를 받아온 다음에 1분봉 만드는 로직 부르기

[Step 2] 1분봉을 만든다

update_candle() 동작 방식

(1) 같은 분일 때

• high: 현재 고가와 비교해서 더 높은 값으로 갱신
• low: 현재 저가와 비교해서 더 낮은 값으로 갱신
• close: 최신 체결가로 갱신
• volume: 누적 합
• vwap_num, vwap_den: 거래량 가중 평균가 계산을 위한 값 누적

(2) 분이 바뀌었을 때

• 직전 current_candle을 closed로 확정
• candles_1m.append(closed) 로 1분봉 리스트에 저장
• 새로운 current_candle을 초기화 (open, high, low, close = 현재 체결가)

[step 3] closed_candle이 만들어졌다면(1분봉이 만들어졌다면) 보조 지표계산 on_candle

분봉이 보조지표가 원하는 만큼 모였을 때, 지표를 계산해서 카프카 Producer로 발행

[step 4] 카프카 프로듀서 발행

• 카프카 도커 컴포즈 경량 카프카를 사용해서, 간단하게 로컬에서 카프카 테스트를 수행

• 카프카 토픽의 메시지로 발행하는 코드

• 테스트를 위한 카프카 컨슈머 코드

• 실행 결과 분봉 단위로 보조지표가 잘 계산돼서 컨슈머들이 받고 있다

"이 글은 알파코에서 진행되는 [신한투자증권] 프로디지털아카데미 과정 중, 김송아 강사님과 함께하는 '파이널 프로젝트'를 기반으로 작성되었습니다"

안녕하세요, 팀 사륜구동의 CTO겸 막스 베르스타펜을 맡고 있는 블로그 주인장 YUZE입니다 (저희 팀에는 르끌레르, 러셀, 피아스트리가 있습니다.)

프로디지털 아카데미 "파이널 프로젝트"가 본격적으로... 아주 본격적으로 시작 되었습니다.

저희 팀이 진짜 몰입을 하고 있는데요... 저희 팀 좀 자랑해보겠습니다.

2025-09-15 ~ 2025-09-17(3일)

스프린트 기간 동안 한 것

• 기능 명세
• 와이어프레임
• 디자인 회의

저희 팀은 프론트엔드가 한 명(aka 조지 러셀)이기 때문에, 디자인을 잘 해가는 것이 중요합니다.

사실 제가 이 팀에서 디자이너(오랜 추구미)를 맡고있다는 사실!

제가 디자인을 해 가면, 저희 PM(르끌레르)님, 프론트 리더(러셀), 백엔드 리더(피아스트리) 님들 께서 디자인에 대해, 어떤 것이 더 예쁘고 사용자 친화적일지 회의를 하는 구조로 진행했습니다.

• 발언권을 얻기 위해 일어난 백엔드 3인방...

백엔드 3인방은... 어떤 디자인이 사용자 친화적인지 프로듀스 101처럼 프론트 리더 조지 러셀에게.... 컨펌을 받고 있습니다.

(1) 유저가 편하다고 느낄만한 UI/UX란?

유저의 입장에서 고민하면서, 아래와 같은 생각을 기반으로 토론했습니다.

• 유저가 이 화면에서 기대하는 것은 무엇일까
• Depth가 너무 깊으면 불편하다
• 왼쪽 대각선 위에서부터 시선이 떨어지니까 시선에 맡게 화면 구성을 해야된다

(2) 고민 지점 : 전략 생성 유저 플로우와 디자인 관련 고민

1. 전략 생성 페이지의 팔레트는 왼쪽, 오른쪽 어디에 놓을까?

• 전략생성 페이지는 위와 같이 캔버스컨셉
• 팔레트에서 블록과 종목을 선택 → 캔버스에 반영되는 구조
• but! 왼쪽에는 이미 네비게이션을 위한 사이드바가 있어서, 팔레트를 왼쪽에 두는 게 네비게이션바가 두개인 거 같아서 실제로 적용해보니 어색했다.

나 : 그렇다면 팔레트를 오른쪽에 두자 팀원1 : 사람은 왼쪽에서 오른쪽으로 시선이 가기 때문에, 오른쪽에서 나오는 게 어색하다 팀원2 : 그럼 왼쪽에 두자 팀원3 : 둘이 같이 나와서 네비게이션바가 너무 어색함 (무한루프)

2. 사용자의 모든 전략을 대시보드에서 다 보여주는것은 이상하다.

저희 서비스에서는, 전략을 생성하는 것과, 실행하는 것 두 가지 액션이 있습니다.
따라서, 실행중이지 않은 전략도 있는데, 이 모든 것을 대시보드에서 다 보여주는 것은 너무 정보가 많다는 문제가 있습니다

제가 만약 유저라면, 대시보드에서는 전략에 대한 전체적인 요약을 보고싶을 거 같다고 생각했습니다.

라우팅 네비게이션 바에는 대시보드랑 전략 생성 두 가지만 존재하는데... 어떻게 묶어야지 더 자연스러운 흐름일까?

(3) 팀원들과 오랜 회의 끝에 나온 화면 재구성

토론 끝에 나온, 피아스트리가 그려준 와이어프레임입니다.

1. 팔레트 위치 문제

사용자의 시선은 왼쪽에서 시작하는데, 팔레트 때문에 네비게이션 바가 두 개 겹쳐 보여서 어떻게 구성해야될지 고민 #### [해결방안]

• 팔레트는 전략 생성 시에만 필요한 것이기 때문에, 팔레트를 좌측 플로팅으로 띄워 네비게이션 중복 문제와 UI 깊이 문제를 해소

  
  

2. 대시보드 정보 과잉

대시보드에 사용자의 모든 전략을 다 노출하면 정보량이 과도해져 가독성이 떨어짐

[해결방안]

• 별도의 전략 탭을 생성
• 전략 탭에서는 사용자의 모든 전략을 한눈에 확인하도록 구성
• 전략 탭에서 전략 생성 버튼 → 캔버스 이동 2번 클릭 이내로 주요 액션 가능, depth 과도하게 깊어지지 않음

[결론] 전략 페이지 디자인 초안

변경 전 - (1안)

변경 전 - (2안)

변경 후

ps. 칭찬감옥

"이 글은 알파코에서 진행되는 [신한투자증권] 프로디지털아카데미 과정 중, 김송아 강사님과 함께하는 '파이널 프로젝트'를 기반으로 작성되었습니다"

안녕하세요, 팀 사륜구동의 CTO겸 막스 베르스타펜을 맡고 있는 블로그 주인장 YUZE입니다.

(저희 팀에는 PM 르끌레르, 프론트 리더 조지 러셀, 백엔드 리더 피아스트리가 있습니다.)

프로디지털 아카데미 "파이널 프로젝트"에 맞춰서, 1주차 기획에 대한 고도화 내용을 한 번 작성해보려고 합니다.

(0) 어떤 방향성을 가져갈까?

저희 팀은 프로젝트 방향성을 잡기 위해 여러 증권사의 MTS를 분석했습니다.

그 과정에서 공통적으로 제공되는 기능인 감시 주문을 확인할 수 있었지만, 제공되는 조건이 제한적이라는 점을 발견했습니다.

저희는 해당 조건 이외의 지표들을 더해서, 투자자들이 더 개인화 된 자동매매를 제공하면 좋겠다고 생각을 하면서 방향을 잡아갔습니다.

(1) 우리의 주제는?

1. 현재의 트레이딩 툴에서는 다양한 지표로 매매를 자동화 할 수 없습니다.

2. 더 다양한 지표로 트레이딩을 하기 위해서는, 증권사 open api를 연결해서 자동 매매를 해야되는데 전문 지식 + 개발 역량 + 인프라 환경이 필수라, 초보 투자자가 쉽게 접근하기 어려운 분야입니다.

따라서 저희팀은, '노코드 + 자동 매매 실행'이라는 결합을 통해, 기존 MTS, HTS, WTS 사용자들에게 더 다양한 지표로 자동매매를 수행할 수 있도록 도움을 주고자 프로젝트를 기획했습니다.

(2) 어떤 지표가 알고리즘 트레이딩에 많이 사용될까?

1. 이동평균선

• 가장 기본적이고 가장 많이 쓰이는 지표.
• 추세 기반 전략의 뼈대.

🔸 주황색(골든 크로스) : 단기 이동평균선이 장기 이동평균선을 위로 돌파할 때 발생 해석: 상승 추세로 전환할 가능성이 크다고 봐서 매수 신호로 많이 씀.

🔸 노란색(데드 크로스) : 단기 이동평균선이 장기 이동평균선을 아래로 돌파할 때 발생 해석: 하락 추세 전환 신호로 보고 매도 신호로 많이 씀.

Q. 골든 크로스, 데드 크로스는 어떤 봉 단위로 보는 게 좋을까? -> 우리 서비스에서 어떻게 살릴까?

(1) 일봉 기준

장점: 신뢰성 높음, 노이즈 적음 단점: 신호 늦음, 이미 많이 오른 뒤 매수 신호 발생할 수 있음 적합: 스윙·중장기 투자자

(2) 분봉 기준

장점: 빠른 진입/청산 가능, 단타/데이 트레이딩 적합 단점: 잦은 오신호, 손절 필수, 보조지표 필수 적합: 단기·데이 트레이더

우리 서비스에서는 ?

우리는 사용자들에게, 분봉과 일봉 둘 다 제공 할 예정이다. 조건 블록에서 일봉과 분봉 기준으로 선택을 할 수 있게 해서, 보다 개인화 된 조건을 제공하기로 결정했다.

2. RSI (Relative Strength Index)

• 모멘텀 지표 중 사용 빈도가 가장 높음.
• 과매수(>70), 과매도(<30) 구간을 조건으로 매매.
• 단독으로도 쓰이지만, 이동평균과 조합해 “필터”로 자주 활용됨

3. MACD (Moving Average Convergence Divergence)

• 이동평균을 응용한 추세 + 모멘텀 복합 지표.
• MACD 라인이 시그널 라인을 돌파할 때 진입/청산 신호.

4. 볼린저 밴드 (Bollinger Bands)

• 변동성 기반 지표 중 가장 대표적.
• 가격이 상단 밴드를 돌파하면 과매수/돌파 신호, 하단 밴드 터치 시 과매도/반등 신호로 활용.
• 변동성 돌파 전략, 리스크 관리 필터로도 많이 쓰임.

빨간 원: 하단 밴드 돌파 → 과매도 구간 → 기술적 반등 가능성. 파란 원: 중심선 돌파 + 상단 밴드 근접 → 단기 과열 가능성 → 차익 실현/매도 신호로 해석 가능.

Q. 볼린저밴드 봉은 뭘 써야될까? -> 우리 서비스에서 어떻게 살릴까?

** 1. 일봉 (Daily) : 가장 일반적이고 많이 쓰임**

• 장기 투자자·스윙 트레이더들이 추세 전환이나 과매수/과매도 구간을 확인할 때 사용
• 장점: 노이즈 적고 신뢰도 높음.
• 단점: 신호가 늦음, 이미 가격이 많이 움직인 뒤 알 수 있음.

** 2. 주봉/월봉 (Weekly/Monthly)**

• 중장기 추세 확인용.
• 기관·포트폴리오 매니저들이 큰 그림 확인할 때 씀.
• 신호 빈도는 적지만, 의미는 큼.

3. 분봉

• 단타·데이 트레이딩에 자주 활용.
• 밴드 돌파(상단/하단) → 진입/청산 시그널로 쓰임.
• 장점: 빠른 신호로 단타 대응 가능.
• 단점: 가짜 신호 많음 → RSI, 거래량 같은 보조지표 꼭 병행해야 함.

우리 서비스에서는 ?

분봉과 일봉만 제공할 예정입니다.
월봉과 주봉은 장기적인 시그널에 해당합니다. 장기 시그널을 포함할 경우, 유저 플로우가 불필요하게 복잡해질 수 있습니다.
특히 프로젝트의 기본 플로우는 '매일매일 감시'이기 떄문에, 사용 맥락에 맞추는 것이 자연스럽다고 판단했습니다.

5. ADX (Average Directional Index)

• 추세의 “강도”를 수치화한 지표.
• ADX > 25 → 추세 강함, 추세추종 전략 유효.
• ADX < 20 → 횡보장, 오실레이터 계열 전략 유효.

(3) 기획 멘토링 후기

프디아 시작하면서 생긴 목표가 '말 잘하기'였는데, 마침 좋은 기회가 생겨서 기획 PT를 제가 하게 됐습니다.

현업에 계신 분들께 브리핑을 해보는 것은 처음이라, (매우) 긴장 됐지만.... 열심히 연습한대로 잘 전달드리려고 해보았습니다.

저희 팀이 받은 피드백은, 조건을 조합하는 과정을 정말 사용자 친화적인 UI/UX로 풀어내는 게 이번의 가장 큰 TASK 입니다.

사륜구동 팀 화이팅! (러셀, 르끌레르, 피아스트리 보고있나!)

ps. 앞으로 방향성...

항상 프로젝트를 할 때마다, 기록을 체계적으로 남기지 않아서 결과물이 남지 않아 아쉬움이 많았습니다. 따라서, 이번 파이널 프로젝트에서는 많은 기술적 도전과 고민이 있을텐데 그 내용에 대해서 잘 풀어 보고싶습니다.

페어프로그래밍 후기를 남기고자 한다.

먼저 '완주하지 못한 선수' 라는 코딩테스트 문제를 풀었고, 10분의 시간 동안 팀끼리 문제를 분석하며 어떻게 풀이를 할 지 협의하는 과정을 거쳤다.

실제로, 나는 해당 문제를 '정렬'을 통해 푼 경험이 있는데, O(n)을 지켜서 문제를 풀어야 하지만, 나는 기존에 O(nlogn)의 시간 복잡도로 풀었고, 성공했다.

따라서, 이번에는 팀원들과 협의해서 '해시'를 통해 참가자와 완주자가 길이가 1 차이 나는 것을 이용해서 풀기로 결정했다.

서로 드라이버와 네비게이터가 되어서

드라이버를 5분씩 맡으며, 3명이서 돌아가며 코딩테스트 문제를 풀었다.

사공이 많으면, 배가 산으로 간다는 말이 있는데, 실제로 서로 사공들끼리 처음에 변수명 부터 시작해서, 어떻게 map을 초기화 할 지 부터 난관이었다.

그렇지만, 점점 적응되고 역할에 적응해가다 보니, 서로의 의견을 수용하면서 하다보니 수월하게 문제 풀이를 완료할 수 있었다.

페어프로그래밍은 너무 재밌다고 생각했다. 성취감이 컸다고 느꼈습니다.

🔷 이번 글에서 다루는 것

1. Spring Boot의 트랜잭션 처리 구조
2. MVCC
3. 트랜잭션 격리 수준

본격적으로 들어가기에 앞서, 트랜잭션 격리수준과, 격리 수준에 따른 이상현상을 간단히 표로 정리한다.

트랜잭션 격리 수준 종류

Isolation 이상 현상

지난 포스팅에서, 메인스레드에서 조회가 됐지만, 새로 생긴 서브 스레드에서 조회가 안 되는 현상이 있었다.

그 이유에 대해 나름대로 분석했는데, 다음과 같은 이상 포인트들이 있었다.

이상 현상과, 의심할 포인트

1. @Transactional 이 감싸는 범위가 너무 큼
2. 기존 스레드에 ＠Transactional이 붙어있더라도, 그 안에서 스레드를 새로 생성된다면 기존 스레드와 새로운 스레드는 같은 트랜잭션을 공유하지 않음

🔷 용어 정리
다음 설명에서, 서블릿 컨테이너의 워커 스레드를 그냥 스레드라고 부르면서 설명하도록 하겠음

SpringBoot가 DB에 접근하고 받아오는 방법

[step 1] Spring 스레드가 로직 처리 중 DB 접근 필요

• 웹 요청이 들어오면 Spring의 스레드 해당 요청을 처리하다가 DB에 접근할 필요가 생김

[step 2] Connection Pool(HikariCP 등)에서 Idle 상태 커넥션 하나 빌림

• Spring Boot는 기본적으로 HikariCP와 같은 커넥션 풀을 사용
• 커넥션 풀에서 유휴 상태의 커넥션을 스레드에 빌려줌
• 같은 트랜잭션 내에서는 동일한 커넥션이 유지되어, 여러 DB 작업이 하나의 커넥션으로 처리

[step 3] 빌려온 커넥션으로 DB에 접근

• 커넥션 풀에서 빌린 커넥션은 이미 MySQL 서버의 포그라운드 스레드와 TCP 소켓 연결이 되어 있는 상태

[step 4] 쿼리 실행

• 빌린 커넥션을 통해 SQL 쿼리를 실행하면, MySQL 서버의 포그라운드 스레드가 해당 쿼리를 처리
• 결과를 Spring 애플리케이션으로 반환

[step 5] 쿼리 결과를 받아옴

• 쿼리 결과를 받아서 애플리케이션이 처리

[step 6] 커넥션을 Connection Pool로 반환

• 트랜잭션이 끝나거나, 커넥션 사용이 끝나면 커넥션을 다시 커넥션 풀에 반환
• 반환된 커넥션은 다음 요청에서 재사용

🔷 요약 Spring Boot에서 @Transactional이 걸리면. . .

1. 트랜잭션 단위로 Connection Pool에서 커넥션 1개 빌림
2. 트랜잭션 동안 실행되는 모든 DB 작업은 그 커넥션 하나로 처리
3. 트랜잭션이 끝나면 커넥션은 다시 Connection Pool로 반납

MVCC(Multi Version Concurrency Control)

MySQL의 기본 트랜잭션 격리 수준은 REPEATABLE READ다. 이는 트랜잭션이 시작될 때의 스냅샷을 기준으로 조회하기 때문에, 다른 트랜잭션에서 커밋되지 않은 데이터는 조회할 수 없다.

MVCC는 InnoDB가 사용하는 방식으로, 언두 로그를 통해 일관된 읽기를 제공한다.

문제 발생 코드 분석

• 문제가 발생한 테스트 코드 전문

    @Test
    @Transactional
    void 참가자_5명이_동시에_접근할_경우_동시성_이슈가_발생한다() throws InterruptedException {
        // given
        Member member1 = createMember("user1@example.com", "UserOne", "2021001", "010-1234-5678", Gender.WOMAN);
        Member member2 = createMember("user2@example.com", "UserTwo", "2021002", "010-9876-5432", Gender.WOMAN);
        Member member3 = createMember("user3@example.com", "UserThree", "2021003", "010-5555-5555", Gender.MAN);
        Member member4 = createMember("user4@example.com", "UserFour", "1231312", "010-1232-5555", Gender.MAN);
        Member member5 = createMember("user5@example.com", "UserFive", "13213123", "010-5555-2342", Gender.MAN);
        Member member6 = createMember("user6@example.com", "UserSix", "1121212", "010-5555-2333", Gender.MAN);

        MeetingPost meetingPost = createMeetingPost();
        System.out.println("메인스레드 : " + meetingPostService.findById(meetingPost.getId()).getTitle());

        for (Member member : Arrays.asList(member2, member3, member4, member5, member6)) {
            executorService.submit(() -> {
                try {
                    System.out.println("새로운 스레드 : " + meetingPostService.findById(meetingPost.getId()).getTitle());
                    participantService.participate(meetingPost.getId(), member.getId());
                }
                catch (Exception e) {
                    System.out.println(e.getMessage());
                }
                finally {
                    latch.countDown();
                }
            });
        }

        latch.await();

        assertThat(participantRepository.findByMeetingPost(meetingPost).size()).isEqualTo(3); // 참가 제한은 3명이어야 함
    }

• 코드를 시각화 하면 다음과 같다.

메인 스레드는 자신의 트랜잭션 안에 있는 데이터를 INSERT하고 조회하기 때문에, 문제 없이 조회가 가능하다.

테스트 코드 스레드(메인 스레드)가 커밋되기 전에, 새롭게 생긴 스레드들이 조회를 하려고 시도한다.

그러나, 새로운 스레드들은 트랜잭션 격리 수준에 따라 다르지만, MYSQL의 default 격리 수준은 REPEATABLE_READ 이기 때문에 commit이 되지 않는 이상 볼 수 없었던 이슈가 생겼었다

해결 방법: 트랜잭션 범위 조절

메인 스레드에서 실행되는 createMember, createMeetingPost 같은 메서드에 각각 @Transactional이 붙어 있다면, 각각 독립된 트랜잭션으로 커밋된다.

즉, 테스트 메서드에 @Transactional을 붙이는 대신, 내부 create~ 메서드에만 붙이면 트랜잭션을 더 작게 분할할 수 있다.

이렇게 하면, 테스트 실행 시 각 INSERT가 메서드 종료 시점에 커밋되고, 이후 서브 스레드들이 이 데이터를 조회 가능하게 된다.

결론

• 스레드는 트랜잭션 컨텍스트를 공유하지 않는다
• MySQL은 REPEATABLE READ를 기본으로 하며, MVCC로 인해 커밋 전 데이터는 타 트랜잭션에서 조회되지 않는다
• 트랜잭션의 범위를 줄이면 커밋 타이밍이 앞당겨져 다른 스레드에서도 조회 가능해진다

• @Transactional을 제거하면, 트랜잭션의 범위를 줄여 작은 단위로 커밋할 수 있다.

• 각 메서드에 @Transactional이 붙어 있다
  • createMember(...), createMeetingPost(...) 등 각 create 함수는 별도의 트랜잭션으로 동작한다.
  • 정상적으로 메서드가 종료되면 해당 트랜잭션은 안전하게 commit된다.

따라서 이후 동시성 테스트 로직에서는 이 데이터들이 이미 DB에 반영된 상태로 존재하게 된다.

• 메서드마다 @Transactional 이 붙어있기 때문에, 트랜잭션 메서드가 끝나면, 안전하게 트랜잭션이 commit 된다.

｢도움이 된 자료｣ https://mariadb.com/docs/server/server-usage/storage-engines/innodb/innodb-undo-log https://dev.mysql.com/doc/refman/9.0/en/innodb-multi-versioning.html 📘 참고 서적 Real MySQL 8.0 백은빈, 이성욱 지음

🔷 이번 글에서 다루는 것

이 문제는 동시성 이슈가 발생하는 메서드를 테스트하기 위해 작성한 테스트 코드에서 발생한 문제이다.

1. 테스트 환경 및 코드에 대한 개요 설명
2. 테스트 실행 결과 분석
3. 테스트 코드에서 INSERT한 결과가 발생 하지 않는 문제 발생

1. 테스트 시나리오 및 코드 구성

1-1. 테스트 목적

• 5명의 유저가 참여 경합 상황을 가정 → 5개의 스레드로 하나의 동시성 이슈가 메서드와 컬럼에 경합을 유도
• 제한 인원보다 많은 인원의 유저가 들어오는 문제를 확인
• lock을 걸어서 제한 인원 만큼의 인원만 들어올 수 있도록 동시성을 제어하는 것을 목표로 함

1-2. 테스트 환경

• DB : MYSQL 8.0 (InnoDB)
• Thread : 테스트 메서드에 경합하는 Thread 5개 ⇒ 유저 5명 가정
• 참여 제한 : 최대 3명 (작성자 포함)

1-3. 기대 결과

• 최종 참여 인원 : 작성자 1명 + 참여자 2명
• 참여 인원 5명이 동시에 접근하더라도 참여자는 2명까지만 허용되어야 함

기대 결과와 테스트 조건은 위와 같다. 동시성 제어 문제가 잘 해결되는 지 확인하기 위해, 아래와 같이 테스트 코드를 작성했다.

1-4. 테스트 코드 구성

🔷 메인 테스트 메서드

    @Test
    @Transactional
    void 참가자_5명이_동시에_접근할_경우_동시성_이슈가_발생한다() throws InterruptedException {
        // given
        Member member1 = createMember("user1@example.com", "UserOne", "2021001", "010-1234-5678", Gender.WOMAN);
        Member member2 = createMember("user2@example.com", "UserTwo", "2021002", "010-9876-5432", Gender.WOMAN);
        Member member3 = createMember("user3@example.com", "UserThree", "2021003", "010-5555-5555", Gender.MAN);
        Member member4 = createMember("user4@example.com", "UserFour", "1231312", "010-1232-5555", Gender.MAN);
        Member member5 = createMember("user5@example.com", "UserFive", "13213123", "010-5555-2342", Gender.MAN);
        Member member6 = createMember("user6@example.com", "UserSix", "1121212", "010-5555-2333", Gender.MAN);

        MeetingPost meetingPost = createMeetingPost();

        for (Member member : Arrays.asList(member2, member3, member4, member5, member6)) {
            executorService.submit(() -> {
                try {
                    participantService.participate(meetingPost.getId(), member.getId());
                }
                catch (Exception e) {
                    System.out.println(e.getMessage());
                }
                finally {
                    latch.countDown();
                }
            });
        }

        latch.await();

        assertThat(participantRepository.findByMeetingPost(meetingPost).size()).isEqualTo(3); // 참가 제한은 3명이어야 함
    }

🔷 테스트 메서드 - createPost

 public MeetingPost createMeetingPost(Member member) {
        return meetingPostService.writePost(
                member.getId(),
                new MeetingPostContent(
                        "스터디 모집합니다!",
                        "자바 스터디 함께 하실 분 모집합니다. 초보자 환영!",
                        "NONE",
                        "3",
                        "스터디모집",
                        "2026-02-20T18:00",
                        "2026-02-25T15:00",
                        "서울시 강남구 테헤란로 123",
                        "37.498095",
                        "127.027610"
                ), new MeetingPostImagesUris(
                        List.of("uri")
                ));
    }

🔷 테스트 메서드 - createMember

  public Member createMember(String email, String name, String studentId, String phone, Gender gender) {
        Member member = Member.create(email, name, studentId, phone, gender, Membership.PRO,
                Department.ART_AND_PHYSICS);
        memberService.createMember(member);
        return member;
    }

2. 테스트 실행 결과 및 예상 외의 현상

동시성 이슈를 제어하지 않은 코드이기 때문에, 참여 가능 인원보다 참여인원이 많기를 기대하면서 테스트를 해보았다.

그러나, 아래와 같이 기대와 다른 결과가 발생했다.

2-1 테스트 결과 요약

• expect : 참여자가 참여 가능자보다 많아야 한다
• actual : 참여자는 작성자 1명 뿐, 나머지 5명은 모두 실패

참여 가능 인원보다 참여한 사람이 많으면 많아야 하지, 왜 아무도 참여를 못했을까 의문이 들어서 error로그를 눈으로 확인해보았다.

3. 원인 분석 및 문제 정의

🔷 테스트 코드는 다음과 같은 절차를 거친다

1. member 생성
   
2. meeting post INSERT + wirter member와 함께 insert
   
3. 마감일에 맞춰서 게시글의 상태를 바꿔주는 이벤트를 예약
   
4. thread 5개가 participate 동시 호출
   

3-1. INSERT 후 조회 실패 로그 분석

• 로그를 확인해보니 DB에 INSERT한 모임 글이 조회가 안 되는 현상

• 분명 테스트를 위한 데이터를 넣어 놓은 상황인데 위와 같은 예외가 발생

• INSERT 쿼리도 나가는 것을 확인할 수 있음

모임 글이 DB에 INSERT되었음에도, 조회되지 않는 문제가 발생했다. 모임 글을 찾는 메서드를 호출하는 곳은 participate 메서드 안에 있다. 따라서, 스레드별로 모임글을 확인해 보는 작업을 해보도록 하겠다.

3-2 스레드 별 데이터 조회 여부 검증

• 테스트 코드가 돌아가는 메인 스레드 (1개)
• 테스트 코드에서 새로 만드는 스레드 (5개)

위와 같은 구조로 되어있기 때문에 아래와 같이 출력 문을 배치하였다.

실행 결과

🔹 메인 스레드에서 조회 성공

🔹 새 스레드에서 조회 실패

이를 바탕으로 문제를 아래와 같이 정의하고 파고들기로 했다.

🔷 문제 정의

테스트 코드 내에서 INSERT된 데이터가, 새로 생성된 스레드에서 조회되지 않는 현상 발생

🔷 다음 글에서 다룰 것

1. MVCC와 트랜잭션 격리 수준에 대한 이해
   
2. 컬럼이 조회 안 되는 이유 분석

Subnet 생성

Subnet을 VPC에 연결

private subnet-1 10.0.2.0/24 가용영역 ap-norheast-2a

private subnet-2 10.0.3.0/24 가용영역 ap-norheast-2c

public subnet 10.0.1.0/24 가용영역 ap-norheast-2c

라우팅 테이블 생성

private 라우팅 테이블 생성 private subnet을 연결할 route를 생성해서, igw와 연결 된 public subnet과 privates subnet을 나눈다.

라우팅 테이블에 private 서브넷 연결 private subnet은 VPC 내부 IP 대역(10.0.0.0/16)에 대해서만 통신이 가능하고, 외부 인터넷으로의 트래픽은 차단되어 있음

• 라우팅 테이블을 통해, private subnet은 VPC 내부의 IP 범위의 대해서만 통신이 가능하게 한다
• 외부로 나가는 경로는 설정되어 있지 않도록 한다

public route도 동일한 방법으로 생성

생성된 public route가 인터넷과 연결되도록 만들어야 한다. 따라서, igw(인터넷게이트웨이)를 생성해서 public route에 연결해주는 것 까지 해보겠다.

IGW 생성

IGW를 생성

IGW를 VPC에 연결

퍼블릭 라우트 테이블에 igw를 통해 외부 네트워크와 연결될 수 있도록 옵션 추가

따라서, 전체 VPC 전체 구성은 다음과 같이 구성되었다.

여기서 rtb-058d44a00cbf8c4c3 는, VPC를 생성해서 자동으로 생긴 기본 라우팅 테이블이다.

특별하게 라우팅을 만들지 않는 경우, 해당 라우팅 테이블에 연결되고, 이 라우팅 테이블을 수정해서 사용하면 된다.

⇒ 이름을 좀 더 직관적으로 보고자 하여, 실습에서는 기본 라우팅 테이블을 사용하지 않았다. ⇒ subnet에 연결되는 라우팅 테이블 중 하나는, 기본 라우팅 테이블을 사용해도 무방하다.

RDS 생성

RDS 서브넷 생성

Subnet Group에 두 개 이상의 서브넷을 지정한 이유 → RDS는 기본적인 컨셉이 고가용성과 장애 복구를 지원

단일 장애 지점(SPOF)을 방지, 가용영역(AZ) 장애 시에도 데이터베이스를 자동으로 다른 가용영역에서 띄울 수 있도록 설계된 구조

프리티어 수준에서는 Single AZ 배포만 지원하지만, .RDS 구조상 2개 이상의 서로 다른 가용영역의 서브넷을 포함하는 Subnet Group을 지정해야 함

⇒ 장애 복구 및 향후 Multi-AZ 전환을 위한 최소 요건

• RDS는 인스턴스 장애, 가용영역 장애 등 다양한 상황에 대비해 관리형 서비스를 제공
• Single-AZ 배포라도, AWS 내부적으로 장애 복구나 유지보수 작업 시 다른 가용영역으로 인스턴스를 재배치할 수 있도록 설계 됨

⇒ RDS DB Subnet Group에는 최소 2개 이상의 서로 다른 AZ에 속한 서브넷을 반드시 지정해야만 RDS 생성이 가능

RDS에서 사용할 보안그룹 생성

RDS 생성

템플릿 : 프리티어 배포 옵션

• 단일 AZ DB 인스터스 배포
• VPC연결
• DB 서브넷 연결
• 퍼블릭 IP 생성 X

이런 일이 없게, 백엔드 서버 또는 RDS를 외부와 완벽히 격리 시키고 싶다면, 어떻게 하는 게 좋을까? ⇒ 결론적으로 VPC와 Private Subnet을 이용하여 네트워크를 구성하면 된다.

AWS의 가장 핵심적인 기능이라고 할 수 있는 VPC에 대해서 알아보도록 하자.

VPC란?

AWS와 같은, 거대한 퍼블릭 클라우드에서 VPC(Virtual Private Cloud)를 사용하여 논리적으로 독립된 나만의 가상 네트워크 공간을 만드는 것

왜 VPC가 필요한데? ⇒ 내가 원하는 대로 네트워크를 세밀하게 설계하고 제어할 수 있다.

• 사설 IP 주소 범위(CIDR 블록) 지정
• 서브넷(Subnet) 생성 및 분리
• 라우팅 테이블 설정
• 인터넷 게이트웨이, NAT 게이트웨이 등 네트워크 게이트웨이 연결
• 네트워크 ACL, 보안 그룹 등 방화벽 정책 적용

즉, VPC는 AWS의 물리적 인프라 위에 논리적으로 완전히 분리된 나만의 네트워크 공간을 만드는 기능이다.

AWS에서 기본으로 제공하는 VPC는 빠르게 리소스를 사용하기 위해, 만들어 놓은 VPC이다. 웬만하면 새롭게 만들어서 사용하도록 하자

Subnet

VPC 안에 존재하는 더 작은 네트워크 구역

VPC의 IP 주소 범위를 더 작게 나눈 논리적 네트워크 영역

• VPC라는 큰 네트워크 공간을, 여러 개의 작은 네트워크 영역으로 쪼갠 것
• 서브넷마다 리소스를 배치하고, 네트워크 정책을 세밀하게 적용할 수 있음
• 하나의 가용영역에만 속함
• 독립적인 라우팅 테이블, 보안 그룹, 네트워크 ACL 설정 가능

Public Subnet

인터넷 게이트웨이에 연결되었다면 그것은 Public Subnet이라고 한다.

Private Subnet

• 인터넷 게이트웨이와 연결되지 않은, 고립된 Subnet이다.
• Private subnet에 위치한 리소스는 외부 인터넷에서 직접 접근할 수 없음
• 주로 데이터베이스, 내부 서버 등 외부 노출이 필요 없는 리소스를 배치

NAT gateway : 아웃바운드 전용 인터넷 허용

• Private Subnet에 있는 인스턴스도 운영체제(OS) 업데이트 등 외부 인터넷 접속이 필요한 경우가 있음
• NAT Gateway를 Public Subnet에 배치하여, Private Subnet의 인스턴스가 NAT Gateway를 통해 아웃바운드 인터넷 트래픽을 사용할 수 있도록 함
• NAT Gateway는 아웃바운드 트래픽만 허용 → Private Subnet의 인스턴스는 외부로 나가는 트래픽과 그에 대한 응답만 받을 수 있고, 인바운드는 불가능

데이터가 많지 않아서 랜더링이 늦지 않았고, JPA Pageable을 이용해 손쉽게 구현할 수 있기 때문에 offset을 택했다.

그러나, 서비스가 정말 잘 돼서 대용량의 데이터를 다루어야 한다면, offset 기반 페이지네이션은 어떤 퍼포먼스를 보일지 의문이 들었다.

0. 실험 환경 구축 - 약 300만 개의 데이터

카테고리는 총 20개이고, 전체 게시물 개수는 300만개이다.

그 중 STUDY 카테고리의 비율이 압도적으로 많도록 구성했다. 그 이유는, 실제 웹 사이트를 운영하다보면, 유독 인기가 많은 카테고리가 존재한다.

그 사실을 반영해, 하나의 카테고리가 30% 이상의 점유율을 차지하도록 했다.

1. Offset 기반 페이지네이션의 한계

가장 큰 점유율의 카테고리인 STUDY를 기준으로 쿼리를 실행해보았다.

offset이 증가할수록 실행 시간이 늘어나는 양상을 볼 수 있다.

이는, offset 기반 페이지네이션에서 흔히 발생하는 이슈이다.

_{위 쿼리의 동작 방식을 간략하게 시각화 (offset 기반)}

offset 기반의 페이지네이션의 성능 이슈는, offset 만큼의 행은 무조건 건너뛰어야하는데에서 나온다.

위 그림을 참고해서 설명해보자면, PK 1, 2만 읽고 싶다고 해도, 23번부터 차례로 읽어서 offset 만큼의 행의 개수를 계산을 해야 된다.

정리하자면, offset 크기가 N이라면 최소 N개 데이터를 무조건 스캔해야 한다.

LIMIT 10 OFFSET 1000000 이라는 쿼리를 실행하면, MySQL은 최소 100만 개의 행을 읽고 나서 그다음 10개만 반환한다는 뜻 이다.

즉, 필요 없는 데이터도 읽기 때문에, 데이터가 많아지고 뒤 페이지를 조회해야 할수록 속도가 느려지는 문제가 발생한다.

2. 쿼리에 인덱스 적용

SELECT *
FROM meeting_post p
WHERE meeting_category = :category
ORDER BY p.id DESC
LIMIT :pageSize OFFSET :offset;

CREATE INDEX idx_category_id ON meeting_post (meeting_category, id DESC);

인덱스를 위와 같이 구성한 이유

• Cateogry와 ID를 복합 인덱스로 지정한다
• WHERE 절에서 Category 사용하도록 한다
• Order By 절에서 내림차순 정렬을 고려하여, 인덱스의 두번째 컬럼을 id를 DESC로 지정한다
  • offset이 커질수록 리프노드에서 대량의 데이터 레코드를 읽어야한다.
  • 많은 데이터를 읽어야 하는 상황에서는, 인덱스 정순 스캔이 인덱스 역순 스캔보다 속도가 빠르다. 따라서 내림차순 정렬을 고려해서 ID를 정순 스캔하도록 만들었다

인덱스 적용 결과

_{인덱스 적용 전}

_{인덱스 적용 후}

_{인덱스 적용 전의 실행 계획}

_{인덱스 적용 후의 실행 계획}

실행 계획을 살펴보면, 인덱스가 사용되고 있다는 것을 볼 수 있다.

그러나 인덱스 적용 후가 전 보다 약 1초 느린 것을 볼 수 있다.

그렇다면, 우리가 기대한 만큼 성능을 못 보이는 이유는 무엇일까?

3. 성능 저하 이유와 인덱스 손익 분기점

_{인덱스 적용 후 동작을 간략하게 시각화}

• STUDY 카테고리는 데이터 분포의 약 36.67%를 차지하고 있다

• 인덱스로 STUDY 카테고리를 빠르게 필터링 하고 역순으로 조회한다고 해도, 대부분의 데이터셋을 차지하고 있기 때문에, 상위 N건을 읽을 때 발생하는 비용이 여전히 크다

• 또한, 위 그림을 예시로 들면, offset으로 데이터 행을 건너뛰는 과정에서, select 절에 존재하지 않는 컬럼으로 인해 인덱스에서 건너 뛰는 것이 아닌, 데이터 레코드를 접근하고 이 과정에서 다량의 랜덤 I/O가 발생한다

• 또한, 데이터를 읽어야 하는 숫자가 20~25%를 넘어가는 경우, 인덱스를 통해 데이터를 읽는 것 보다 데이터 레코드를 순차 I/O로 읽는 것이 더 빠른데, offset이 커질수록 랜덤 I/O로 읽어야하는 데이터 수는 증가한다

🗨️ 인덱스의 손익 분기점

일반적으로 DBMS의 옵티마이저에서는 인덱스를 통해 레코드 1건을 읽는 것이, 테이블에서 직접 레코드 1건을 읽는 것보다 `4~5`배 정도 비용이 더 많이 드는 작업인 것으로 예측한다.

따라서, 읽어야 하는 레코드 수가 전체 테이블 레코드의 `20~25%`를 넘기게 된다면, 인덱스를 이용하지 않고 테이블을 모두 직접 읽어서 필요한 레코드만 가려내는 방식(필터링 방식)이 더 효율적이다.

그렇다면, 작은 데이터 분포를 가진 카테고리에서의 실행시간은 어떨까?

실제로 아래와 같이, 가장 작은 분포인 (약 2% 차지) DESIGN 카테고리의 인덱싱 전 후를 비교하게 된다면, 인덱스 적용 전에 비해 후가 약 869ms 단축 된 거를 볼 수 있다.

_{인덱스 적용 전}

_{인덱스 적용 후}

4. 커버링 인덱스를 활용한 쿼리 최적화

인덱스를 지우는 것은?

⇒ 작은 데이터 분포를 가지고 있는 데이터에 대해서, 좋은 퍼포먼스를 보이기 어려울 것이다.

인덱스를 그냥 적용하는 것은?

⇒ 손익 분기점을 넘어가는 데이터 분포 환경에서 사용하기에는, 성능적 이슈가 여전히 존재한다.

인덱스를 더 효과적으로 사용할 수 있는 방법은 없을까?

⇒ 커버링 인덱스 를 이용해서 조회할 ID만 추출해서 PRIMARY INDEX로 바로 접근 하는 건 어떨까?

최종 쿼리

SELECT p.*
FROM meeting_post p
JOIN (
    SELECT id
    FROM meeting_post
    WHERE meeting_category = :category
    ORDER BY id DESC
    LIMIT :pageSize OFFSET :offset
) sub ON p.id = sub.id;

• 서브쿼리에서는 ID만 가져오도록 한다 커버링 인덱스
• 메인 쿼리에서는, 가져온 20개의 ID에 대해서만 데이터 파일에 접근한다

[STEP 1] 커버링 인덱스로 데이터 파일에 접근하지 않고, ID 만 SELECT한다

[STEP 2] SELECT한 ID(클러스터링 인덱스)를 이용해서 데이터 파일에서 레코드를 읽어온다

위 쿼리의 장점

• SELECT절에 ID만 있기 때문에, 커버링 인덱스를 통해 offset으로 건너뛰는 데이터들에 대한 테이블 접근하는 것을 회피한다

  ⇒ 페이지네이션 자체를 인덱스 레벨에서 해결하여, LIMIT 20에 대한 랜덤 I/O만 발생한다.

• 서브쿼리는 인덱스 탐색만 수행하여 최소한의 데이터만 가져오고, 메인 쿼리에서는 클러스터링 인덱스인 id를 이용해서 빠르게 데이터에 접근한다. O(1) 수준

쿼리 튜닝 전 후 테스트

_{쿼리 튜닝 전}

_{쿼리 튜닝 후}

✅ 3.188s → 146ms (약 3.04s 감소, 약 95.4% 향상) ✅ 기존 3.188s에서 146ms로 최적화됨 (약 21.8배 개선)

튜닝 쿼리 인덱싱 전 후 비교

_{인덱스 적용 전}

_{인덱스 적용 후}

✅ 1.575s → 146ms (약 1.43s 감소, 약 90.7% 향상) ✅ 기존 1.575s에서 146ms로 최적화됨 (약 10.9배 개선)

5. 결론 - 더 고민해야 할 부분

커버링 인덱스로 데이터 접근을 최소화 하여, 실행 시간이 많이 줄었다. 그렇지만, 근본적인 원인인 offset 만큼의 불필요한 인덱스를 읽는 것 은 해결하지 못했다.

offset이 커질수록 어떤 장애가 또 생길지 모른다는 것이다.

그렇다면, 이를 해결할 수 있는 페이지네이션 기법은 없을까?

⇒ 다음 포스팅에서는, NO OFFSET 기반 페이지 네이션을 통해 성능 개선을 완료하도록 하겠다.

=> 파티셔닝 & 샤딩에 대해 공부도 추가적으로 하도록 하겠다.

📘 참고 서적 Real MySQL 8.0 백은빈, 이성욱 지음 📗 참고 블로그 ｢기억보단 기록을｣ https://jojoldu.tistory.com/529 📂 도움이 되었던 영상 ｢우아한 테크코스｣ https://youtu.be/edpYzFgHbqs?feature=shared

public enum Role {
    USER,
    ADMIN,
    GUEST
}

옥션 프로젝트에서 접근하는 유저의 권한은 Guest, User, Admin으로 나뉜다.

따라서, 엔드포인트 마다 접근한 유저에 대해 권한 체크를 하고, 올바르지 못한 접근에 대해 예외를 던져야 한다.

그러나, 토큰을 사용하는 모든 엔드포인트에서 중복되는 권한 체크 코드가 생길텐데. . . 같이 개발하는 팀원들이 해당 코드를 작성하지 않게 할 수 있는 방법이 있을까?

그렇게 해서 Spring AOP에 대해 앞서서 공부하였다.

🗨️ Spring AOP 개념 관련 포스팅 (1) 🗨️ Spring AOP 개념 관련 포스팅 (2) 🗨️ Spring AOP 개념 관련 포스팅 (3)

프로젝트에 어떻게 AOP를 적용하였나?

Auction 프로젝트에서의 user 요청 후 프로세스를 간략화 하면 다음과 같다.

• user가 요청
• user의 토큰을 검증 후, 권한에 따라서 ADMIN, USER, GUEST 역할을 부여
• 엔드포인트에서 접근 가능한 역할인지 확인

위 프로세스를 거친다.

엔드포인트에서 접근 가능한 역할인지 확인하는 과정은 토큰을 사용하는 모든 컨트롤러 메서드에서 반복 해야한다.

따라서, 해당 부분을 컨트롤러 메서드에 직접 로직을 작성하는 것이 아니라, 부가 기능으로 판단하여 핵심 로직으로부터 분리하기로 결정하였다.

프로젝트 적용 코드

커스텀 어노테이션 생성 - 포인트 컷 생성을 위한 작업

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface UserOnly {
}

먼저, 커스텀 어노테이션을 만들었다. AOP에서 포인트 컷을 지정하는 방법으로, 메서드에 커스텀 메서드를 붙이는 방법을 택했다. @UserOnly를 컨트롤러 메서드에 붙여주면, @UserOnly가 붙은 메서드가 실행되는 시점에 AOP가 실행된다.

이제 AOP 실행 되는 메서드를 특정하는 것을 정의했으니, 부가 기능 그 자체를 구현하는 것에 대해 알아보도록 하겠다.

AOP 구현 - 부가 기능 작성

// AspectJ 어노테이션 이용해서 Aop 구현하겠다 지정한다
@Aspect
// 빈으로 등록해서 spring aop로 사용가능하게한다
@Component
public class UserCheck {
    // Advice("point cut")를 부여하고자 하는 기능(메서드)에 붙여준다 -> 기능 실행 시점과 특정 위치를 지정한다
    @Before("@annotation(UserOnly)")
    public void userCheck(JoinPoint joinPoint) {
    // joinPoint.getArgs()를 통해 가져오는 것은 타겟 메서드의 매개변수(Arguments)
    // 즉, AOP가 적용된 메서드가 호출될 때 전달된 실제 매개변수 값들을 배열 형태로 반환
        Object[] args = joinPoint.getArgs();

        for (Object arg : args) {
            if (arg instanceof Accessor accessor) {
                if (!accessor.isUser()) {
                    throw new IllegalArgumentException("안됨");
                }
            }
        }
    }
}

위 코드는, 메서드에 접근을 시도하는 사람이 USER 역할을 가진 사람인지 확인하는 메서드이다.(AOP)

@Before 어노테이션에 의해, Point Cut으로 특정한 메서드가 실행 되기 직전에 해당 AOP가 실행 되고, 예외를 던지지 않을 경우, 메서드 실행 후 target이 실행된다.

만약 @Before에 대한 자세한 내용이 궁금하다면 해당 포스팅을 참고하면 된다. Advice 어노테이션에 대한 포스팅

만약, 유저의 접근 권한이 올바르지 않을 경우 예외를 던지고 target이 실행되지 않는다.

따라서 AOP를 통해, UserOnly 어노테이션이 메서드에 붙어있는 경우, USER 역할을 부여받은 접근자만 접근할 수 있게 된다.

Adivce 어노테이션의 종류

@Around

 @Aspect
    @Order(2)
    public static class TxAspect {
        @Around("isyoudwn.aop.order.aop.PointCuts.orderAndService()")
        public Object doTransaction(ProceedingJoinPoint joinPoint) throws Throwable {
            try {
                 // @Before
                log.info("[트랜잭션 시작] {}", joinPoint.getSignature());

                // 조인 포인트 실행
                Object result = joinPoint.proceed();

                // @AfterReturning
                log.info("[트랜잭션 커밋] {}", joinPoint.getSignature());
                return result;
            } catch (Exception e) {
                // @AfterThrowing
                log.info("[트랜잭션 롤백] {}", joinPoint.getSignature());
                throw e;
            } finally {
                 // @After
                log.info("[리소스 릴리스] {}", joinPoint.getSignature());
            }
        }
    }

• 메서드 실행 전 후에 작업을 수행한다
  • 조인 포인트의 실행 여부를 선택할 수 있다
  • 전달값(파라미터)을 변환할 수 있다
  • 메서드의 return이 아닌 다른 것을 반환할 수 있다
  • 예외를 변환해서 throw 할 수 있다
  • try-catch-finally 모두 들어가는 구문 처리 가능하다
• ProceedingJoinPoint를 사용해야한다(규칙)
  • proceed()를 가지고있다
  • JoinPoint의 하위 타입이다
• 조인포인트를 직접 실행해서 타겟을 실행해야한다
  • proceed()를 통해 대상을 실행한다
  • proceed()를 여러번 실행할 수 있다(재시도 기능 가능)

💡 Around 하나만 있어도, AOP의 모든 시점을 구현할 수 있다. 그러나, Target을 직접 실행해야 되는 단점이 있고, Advice의 내부 로직을 이해해야지만, 그 Advice가 어떤 시점에 실행되는지 알 수 있다. 따라서, 아래와 같이 시점을 특정하는 어노테이션이 존재한다.

@Before

조인 포인트 실행 전 Advice 실행

    // before은 로직 수행 후 joinpoint를 실행한다
    @Before("isyoudwn.aop.order.aop.PointCuts.orderAndService()")
    public void doBefore(JoinPoint joinPoint) {
        log.info("[before] {}", joinPoint.getSignature());
    }

• 메서드 종료시 자동으로 다음 타켓이 호출된다
• 예외가 발생하면 다음 코드가 호출되지 않는다

@AfterReturning

메서드 실행 후 정상적으로 Return될 때 Advice 실행

 @AfterReturning(value = "isyoudwn.aop.order.aop.PointCuts.orderAndService()", returning = "result")
    public void doReturn(JoinPoint joinPoint, Object result) {
        log.info("[return] {} return = {}", joinPoint.getSignature(), result);
    }

• value에 포인트 컷을 넣는다
• returning속성에 사용된 이름과 파라미터를 동일한 이름으로 지정하면, 매칭되어서 파라미터에 return 값이 들어온다. 이때, 파라미터 타입은 메서드의 반환 타입과 동일해야 된다(부모 타입을 지정하면 모든 자식 타입은 인정된다)
• return값이 매칭이 안되면 어드바이스 자체가 실행이 안된다
• 메서드 자체에 반환하는 return 을 조작할 수 없다

@AfterThrowing

메서드 실행이 예외를 던져서 종료될 때 실행될 때 Advice 실행

    @AfterThrowing(value = "isyoudwn.aop.order.aop.PointCuts.orderAndService()", throwing = "ex")
    public void doReturn(JoinPoint joinPoint, Exception ex) {
        log.info("[ex] message = {}", ex.getMessage());
    }

• throwing 속성에 사용된 이름은 어드바이스 메서드의 매개변수 이름과 일치해야한다
• throwing 파라미터에 지정된 타입과 맞는 예외를 대상으로 실행한다(부모 타입을 지정하면, 모든 자식 타입은 인정된다)

@After

메서드 실행이 종료되면 Advice가 실행된다. (finally를 생각하면 된다)

  @After(value = "isyoudwn.aop.order.aop.PointCuts.orderAndService()")
    public void doAfter(JoinPoint joinPoint) {
        log.info("[after] {}", joinPoint.getSignature());
    }

• 정상 및 예외 반환 조건을 모두 처리한다
• 리소스를 해제 하는데 일반적으로 많이 사용한다

전체 코드

@Slf4j
@Aspect
public class AspectV6Advice {

    // before은 로직 수행 후 joinpoint를 실행한다
    @Before("isyoudwn.aop.order.aop.PointCuts.orderAndService()")
    public void doBefore(JoinPoint joinPoint) {
        log.info("[before] {}", joinPoint.getSignature());
    }

    @AfterReturning(value = "isyoudwn.aop.order.aop.PointCuts.orderAndService()", returning = "result")
    public void doReturn(JoinPoint joinPoint, Object result) {
        log.info("[return] {} return = {}", joinPoint.getSignature(), result);
    }

    @AfterThrowing(value = "isyoudwn.aop.order.aop.PointCuts.orderAndService()", throwing = "ex")
    public void doReturn(JoinPoint joinPoint, Exception ex) {
        log.info("[ex] message = {}", ex.getMessage());
    }

    @After(value = "isyoudwn.aop.order.aop.PointCuts.orderAndService()")
    public void doAfter(JoinPoint joinPoint) {
        log.info("[after] {}", joinPoint.getSignature());
    }
}

결과

Around를 사용하지 않고, 시점을 특정하는 어노테이션을 총동원해서 작성한 Advice 들의 실행 결과는 아래와 같다.

• *success *

• exception

동일한 조인 포인트에서 어드바이스 실행 순서

Aspect 안에 동일한 종류의 어드바이스가 2개이면 순서가 보장되지 않기 때문에, 이 경우에는 @Order을 사용해서 순서를 지정해주어야 한다!

이 포스팅은 간단한 예제를 이용해서, Spring AOP를 구현하며 이해하는 것이 목적이다

AOP를 사용하기 위한 설정

JPA 또는 Spring AOP를 이용해 구현한 것을 프로젝트의 dependency에 이미 가지고 있는 경우, 이미 AOP의존성을 사용하고 있기 때문에, dependency를 명시적으로 넣어주지 않아도 된다.

그렇지 않을 경우, build.gradle에 아래 내용을 추가하여 AOP를 사용하겠다고 명시 해야 한다.

    implementation 'org.springframework.boot:spring-boot-starter-aop'

@Aspect 를 사용하기 위해서는, main함수 위에 아래 내용을 추가해야 한다. 그러나, 스프링 부트를 사용할 경우 자동으로 추가되어 있으니 따로 명시해주지 않아도 된다.

 @EnableAspectJAutoProxy

AOP 구현

Target : AOP 적용 대상

OrderService

orderItem이 실행되면 log가 찍히고, repository에 save한다.

@RequiredArgsConstructor
@Service
@Slf4j
public class OrderService {
    private final OrderRepository orderRepository;

    public void orderItem(String itemId) {
        log.info("[orderService] 실행");
        orderRepository.save(itemId);
    }
}

OrderRepository

save가 실행되면 Log가 찍히고, 올바를 경우 "ok" 옳지 않을 경우 예외를 반환한다.

@Slf4j
@Repository
public class OrderRepository {
    public String save(String itemId) {
        log.info("[orderRepository] 실행");

        if (itemId.equals("ex")) {
            throw new IllegalStateException("예외 발생");
        }
        return "ok";
    }
}

Aspect : 여러개의 Adviser을 가지고 있는 클래스(모듈)

@Slf4j
@Aspect
public class AspectV1 {
    @Around("execution(* isyoudwn.aop.order..*(..))")
    public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable {
        log.info("[log] {}", joinPoint.getSignature()); // join point 시그니처
        return joinPoint.proceed(); // 타깃 메서드 호출
    }
}

Advice 개발

    @Around("execution(* isyoudwn.aop.order..*(..))")
    public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable {
        log.info("[log] {}", joinPoint.getSignature()); // join point 시그니처
        return joinPoint.proceed(); // 타깃 호출
    }

@Around 애너테이션의 doLog()

• 어느 시점에? 어떤 기능을
• 어드바이스(Advice)

("execution(* isyoudwn.aop.order..*(..))")

• 포인트 컷
• isyoudwn.aop.order 패키지와 그 하위 패키지(. .)에 존재하는 모든 메서드들이 실행될 때 실행할 것임

스프링 Aop를 사용하기 위해서는, Bean으로 등록해 주어야 한다

1. @Component 2. @Bean 3. @Import(@Configuration)

위 세가지 중, test 코드에 간단하게 import해서 확인할 것이기 때문에 Import를 사용하였지만, Component Scan을 자동으로 하는 Spring Boot의 특성을 살려, Component를 이용하는 것도 좋은 방법이다.

AOP 적용 확인을 할 테스트 코드 작성

@Slf4j
@SpringBootTest
@Import({AspectV6Advice.class})
public class AopTest {

    @Autowired
    OrderService orderService;

    @Autowired
    OrderRepository orderRepository;

    @Test
    void aopInfo() {
        log.info("isAopProxy, orderService={}", AopUtils.isAopProxy(orderService));
        log.info("isAopProxy, orderRepository={}", AopUtils.isAopProxy(orderRepository));
    }

    @Test
    void success() {
        orderService.orderItem("itemA");
    }

    @Test
    void exception() {
        Assertions.assertThatThrownBy(()
                        -> orderService.orderItem("ex"))
                .isInstanceOf(IllegalStateException.class);
    }
}

실행 결과

• 전체 실행 결과

• orderService와 orderRepository에 프록시가 적용 됐는지 확인한다. 원래는 false 였던 값이 true로 변경되었다

• orderService와 orderRepository가 실행되기 전 AOP가 불리는 모습이다

PointCut 분리

지금까지는 Advcie와 PointCut이 결합된 상태였는데, PointCut은 따로 분리할 수 있다.

@Aspect
@Slf4j
public class AspectV2 {

    @Pointcut("execution(* isyoudwn.aop.order..*(..))")
    private void allOrder() {}; // pointcut signature

    @Around("allOrder()")
    public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable {
        log.info("[log] {}", joinPoint.getSignature()); // join point 시그니처
        return joinPoint.proceed(); // 타깃 호출
    }
}

• 포인트 컷을 분리해서 사용한다면, 의미를 부여할 수 있는 장점이 있음
• 포인트 컷들만 모아둔다면 프로그램을 모듈화 할 수 있다는 장점이 있음

Aspect안에 Advice를 추가할 수 있다

@Aspect
@Slf4j
public class AspectV3 {

    @Pointcut("execution(* isyoudwn.aop.order..*(..))")
    private void allOrder() {};

    @Pointcut("execution(* *..*Service.*(..))")
    private void allService() {};

    @Around("allOrder()")
    public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable {
        log.info("[log] {}", joinPoint.getSignature()); // join point 시그니처
        return joinPoint.proceed(); // 타깃 호출
    }

    //hello.aop.order 패키지와 하위 패키지 이면서 클래스 이름 패턴이 *Service 인 것
    @Around("allOrder() && allService()")
    public Object doTransaction(ProceedingJoinPoint joinPoint) throws Throwable {
        try {
            log.info("[트랜잭션 시작] {}", joinPoint.getSignature());
            Object result = joinPoint.proceed();
            log.info("[트랜잭션 커밋] {}", joinPoint.getSignature());
            return result;
        } catch (Exception e) {
            log.info("[트랜잭션 롤백] {}", joinPoint.getSignature());
            throw e;
        } finally {
            log.info("[리소스 릴리스] {}", joinPoint.getSignature());
        }
    }
}

• OrderService에는 doLog와 doTransaction 두 어드바이스가 모두 적용된다
• OrderRepository에는 doLog 어드파이스만 적용된다

• 트랜잭션 커밋

• 트랜잭션 롤백

AOP 실행 순서는, 직접 지정해주지 않는 이상 순서가 보장되지 않는다. 더 자세한 내용은 'Advice 순서 지정'에서 설명하도록 하겠다.

PointCut을 모듈화 해서 관리

public class PointCuts {

    @Pointcut("execution(* isyoudwn.aop.order..*(..))")
    public void allOrder() {};

    // 클래스 이름 패턴이 *Service 인 것
    @Pointcut("execution(* *..*Service.*(..))")
    public void allService() {};

    @Pointcut("allOrder() && allService()")
    public void orderAndService() {};
}

Advice에서는 포인트 컷을 참조를 통해 부르면 된다

@Slf4j
@Aspect
public class AspectV4 {
    @Around("isyoudwn.aop.order.aop.PointCuts.allOrder()")
    public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable {
        log.info("[log] {}", joinPoint.getSignature()); // join point 시그니처
        return joinPoint.proceed(); // 타깃 호출
    }

    //hello.aop.order 패키지와 하위 패키지 이면서 클래스 이름 패턴이 *Service 인 것
    @Around("isyoudwn.aop.order.aop.PointCuts.orderAndService()")
    public Object doTransaction(ProceedingJoinPoint joinPoint) throws Throwable {
        try {
            log.info("[트랜잭션 시작] {}", joinPoint.getSignature());
            Object result = joinPoint.proceed();
            log.info("[트랜잭션 커밋] {}", joinPoint.getSignature());
            return result;
        } catch (Exception e) {
            log.info("[트랜잭션 롤백] {}", joinPoint.getSignature());
            throw e;
        } finally {
            log.info("[리소스 릴리스] {}", joinPoint.getSignature());
        }
    }
}

Advice 순서 지정

Advice가 실행되는 순서가 보장되어 있지 않다(즉, 한 메서드에 여러 AOP를 지정하면, 어떤 것이 먼저 실행될지는 모른다는 것이다)

따라서 Order 어노테이션을 이용해서 순서를 직접 지정해 주어야 한다.

그러나 Order 순서는 클래스 단위로 보장된다 → 즉, Aspect 단위로 보장된다.

아래와 같이, 하나의 Aspect 안에 여러 Advice가 존재할 경우 메서드에 Order을 작성해도 순서가 보장되지 않는다는 것이다.

@Slf4j
@Aspect
public class AspectV4
    @Around("isyoudwn.aop.order.aop.PointCuts.allOrder()")
    @Order(2)
    public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable {
        log.info("[log] {}", joinPoint.getSignature()); // join point 시그니처
        return joinPoint.proceed(); // 타깃 호출
    }

    //hello.aop.order 패키지와 하위 패키지 이면서 클래스 이름 패턴이 *Service 인 것
    @Around("isyoudwn.aop.order.aop.PointCuts.orderAndService()")
    @Order(1)
    public Object doTransaction(ProceedingJoinPoint joinPoint) throws Throwable {
        try {
            log.info("[트랜잭션 시작] {}", joinPoint.getSignature());
            Object result = joinPoint.proceed();
            log.info("[트랜잭션 커밋] {}", joinPoint.getSignature());
            return result;
        } catch (Exception e) {
            log.info("[트랜잭션 롤백] {}", joinPoint.getSignature());
            throw e;
        } finally {
            log.info("[리소스 릴리스] {}", joinPoint.getSignature());
        }
    }
}

아래와 같이 작성하면 순서를 보장 받을 수 있다.

@Slf4j
public class AspectV5 {

    @Aspect
    @Order(2)
    public static class LogAspect {
        @Around("isyoudwn.aop.order.aop.PointCuts.allOrder()")
        public Object doLog(ProceedingJoinPoint joinPoint) throws Throwable {
            log.info("[log] {}", joinPoint.getSignature()); // join point 시그니처
            return joinPoint.proceed(); // 타깃 호출
        }
    }

    @Aspect
    @Order(1)
    public static class TxAspect {
        @Around("isyoudwn.aop.order.aop.PointCuts.orderAndService()")
        public Object doTransaction(ProceedingJoinPoint joinPoint) throws Throwable {
            try {
                log.info("[트랜잭션 시작] {}", joinPoint.getSignature());
                Object result = joinPoint.proceed();
                log.info("[트랜잭션 커밋] {}", joinPoint.getSignature());
                return result;
            } catch (Exception e) {
                log.info("[트랜잭션 롤백] {}", joinPoint.getSignature());
                throw e;
            } finally {
                log.info("[리소스 릴리스] {}", joinPoint.getSignature());
            }
        }
    }
}

• 트랜잭션의 순서가 1, Log AOP의 순서가 2일 때 결과

• Log AOP의 순서가 1, 트랜잭션 AOP의 순서가 2일 때