hyomee2

포트폴리오

hyomee2 — Mon, 13 Jul 2026 12:22:32 +0900

아래 pdf 파일을 통해 확인하실 수 있습니다.

권형미_포트폴리오_1.pdf

5.73MB

3. 알림 조회 성능 개선 - 동시성

hyomee2 — Mon, 6 Jul 2026 18:39:26 +0900

본 게시물은 트래블록스 프로젝트를 진행하며 발생한 문제 및 개선 사항을 정리한 글입니다.

https://hyomee2.tistory.com/133

2. 알림 조회 성능 개선 - 반정규화

본 게시물은 트래블록스 프로젝트를 진행하며 발생한 문제 및 개선 사항을 정리한 글입니다. https://hyomee2.tistory.com/132 1. 알림 조회 성능 개선 - 인덱스본 게시물은 트래블록스 프로젝트를 진행하

hyomee2.tistory.com

앞선 글에서는 반정규화를 이용하여 병목이었던 COUNT 집계 쿼리를 제거하고 알림 목록 조회 API의 응답 시간을 개선했다.

하지만 반정규화를 적용하며 또 다른 문제를 마주했다.

바로 동시성 문제다!

문제 상황

예를 들어 현재 특정 사용자의 notification_count(알림 개수)가 10개라고 해보자.

이때 동시에 두 알림이 생성된다면 아래와 같은 상황이 발생할 수 있다.

Thread A: 10 조회 -> Thread A: 11 저장
Thread B: 10조회 -> Thread B: 11 저장

실제로는 알림이 2개 생성되었으니 최종적으로 12가 되어야 하지만,

마지막에 저장한 값이 덮어쓰여져 11이 된다.

이러한 문제를 Lost Update라고 한다.

해결 방안 검토

1. Optimistic Lock

충돌이 자주 발생하지 않음을 가정하고 충돌을 감지하는 방식이다.

엔티티의 버전을 관리하여, 수정 시 조회했던 버전과 현재 버전이 일치하는지 확인하고,

만약 다른 트랜잭션이 먼저 데이터를 수정했다면 OptimisticLockException을 발생시킨다.

장점

- Lock을 잡지 않고 있기 때문에 다른 트랜잭션을 대기시키지 않아 높은 처리량을 기대할 수 있다.

- 충돌이 자주 발생하지 않는 환경에서 우수한 성능을 갖는다.

단점

- 충돌 발생 시 OptimisticLockException이 발생하므로 재시도 로직을 구현해야 한다.

- 동일한 데이터에 대한 수정이 빈번할수록 충돌과 재시도가 반복되어 오히려 성능이 저하될 수 있다.

notification_count는 여러 알림이 동시에 생성될 경우 동일한 행을 빈번하게 갱신해야 한다.

따라서 optimistic lock을 적용하면 충돌이 자주 발생하고, 예외 처리와 재시도 로직도 반복될 가능성이 높기 때문에 적합하지 않다고 판단했다.

2. Pessimistic Lock

동시에 같은 데이터를 수정하는 일이 빈번하게 발생할 것이라고 가정하는 동시성 제어 방식이다.

데이터를 조회할 때 쓰기 락을 획득하여 다른 트랜잭션이 해당 데이터를 수정하지 못하도록 한다.

장점

- 데이터를 수정하기 전에 행을 잠그므로 Lost Update를 방지할 수 있다.

- 충돌이 발생하더라도 예외나 재시도 없이 순차적으로 처리된다.

- 충돌 가능성이 높은 환경에서도 데이터 정합성을 안정적으로 보장할 수 있다.

단점

- 충돌이 발생할 경우 다른 트랜잭션들은 락이 해제될 때까지 대기해야 하므로 응답시간, 처리량이 감소할 수 있다.

비관적 락은 데이터 정합성이 중요한 경우에 적합하다고 판단했다.

현재 notification_count를 단순히 1 증가시키는 연산에서 비관적 락을 적용하면

동일 회원에 대한 다른 수정 작업도 락이 해제될 때까지 대기해야 한다.

이는 응답 시간 증가와 처리량 감소로 이어질 수 있어 현재 상황에 적합하지 않다고 판단했다.

3. synchronized

Java의 synchronized를 사용하면 단일 서버 환경에서 스레드 간 동시 접근을 제어할 수 있다.

하지만 synchronized는 JVM 내부에서만 동작하며,

Java 객체에 대한 접근을 제어할 뿐 데이터베이스 자체의 상태를 관리하는 방식은 아니다.

notification_count 값은 결국은 DB에 저장되는 데이터이기 때문에,

애플리케이션 레벨에서 Lock을 관리하는 것보다는 DB 레벨에서 원자성을 보장하는 것이 더 적절하다고 판단했다.

4. DB Atomic UPDATE

현재값을 조회한 후 애플리케이션에서 계산하는 것이 아니라,

데이터베이스가 제공하는 원자적 UPDATE 연산을 이용하여 값을 직접 증가, 감소시키는 방식이다.

예를 들어 아래와 같이 하나의 UPDATE문에서 현재값을 기준으로 연산을 수행한다.

UPDATE members
SET notification_count = notification_count + 1
WHERE member_id = :memberId;

데이터베이스는 UPDATE를 수행하는 동안 해당 행에 대한 쓰기 lock을 획득하여 연산의 원자성을 보장하므로,

동시에 여러 요청이 들어와도 연산이 유실되지 않는다.

장점

- 데이터베이스가 원자성을 방지하므로 Lost Update를 방지할 수 있다.

- SELECT -> 수정 -> UPDATE 과정없이 UPDATE 한번으로 처리되어 불필요한 조회를 제거할 수 있다.

- 별도의 lock 관리나 재시도 로직이 필요없이 구현이 단순하다.

- 분산 환경에서도 동일한 방식으로 사용할 수 있다.

단점

- 단순한 증감 연산에는 적합하지만 여러 행을 함께 수정하거나 복잡한 비즈니스 로직에 적용은 어렵다.

따라서 결론적으로는 DB Atomic UPDATE를 통하여 Lost Update 문제를 해결했다.

* 위의 네가지 방식에 대해서 간단하게 작성했지만, 다음 글에서 자세히 다뤄볼 예정이다.

테스트

JUnit을 기반으로 동시성 테스트를 진행했다.

코드는 아래에서 확인할 수 있다.

https://github.com/Travlocks/travlocks-server/blob/develop/src/test/java/org/umc/travlocksserver/domain/notification/service/NotificationCommandServiceTest.java

travlocks-server/src/test/java/org/umc/travlocksserver/domain/notification/service/NotificationCommandServiceTest.java at develo

트래블록스 백엔드 레포지토리입니다. Contribute to Travlocks/travlocks-server development by creating an account on GitHub.

github.com

테스트 환경

알림 생성 시 개수와 관련한 동시성 문제를 검증하기 위해 JUnit 기반 동시성 테스트를 작성했다.

ExecutorService를 사용하여 100개의 스레드가 동시에 알림을 생성하는 것을 가정했다.

테스트 결과

DB Atomic Update 적용 전

100개의 동시 요청을 보낸 결과, 예상과 같이 모든 요청이 반영되지 않았으며, 평균적으로 약 12건만 정상적으로 반영되었다.

동일한 데이터를 여러 스레드가 동시에 수정하며 데이터 정합성이 보장되지 않은 것을 확인할 수 있었다.

DB Atomic Update 적용 후

100개의 동시 요청을 보낸 결과, DB Atomic Update 적용 전과 달리, 모든 요청이 정상적으로 처리되어 기대한 값과 정확히 일치했다.

	동시 요청수	성공수	성공률
DB Atomic Update 적용 전	100개	12개	12%
DB Atomic Update 적용 후	100개	100개	100%

마무리

알림 조회 API의 성능을 개선하던 중 찾은 COUNT을 해결하고 나니 또 다른 동시성 문제가 있었다.

동시성 문제를 해결할 때 흔히 "Lock"이 떠오르곤 하는데,

여러 동시성 문제 해결 방식을 찾고 고민해보며 이번 경우는 DB 레벨에서 원자성을 보장하는 것이 적절하다고 판단하고 적용할 수 있었다.
이를 통해 현재 상황에 맞는 적절한 방식을 선택하는 것을 연습하고, 그 중요성을 깨달을 수 있었다.

또한 단순히 어떤 방식을 적용했다는 것에서 끝내지 않고,

JUnit으로 여러 스레드를 통해 동시 요청을 보내는 테스트 코드를 작성해보고,

실제 수치적으로 적용 전과 후의 변화를 검증해볼 수 있어서 동시성 제어의 중요성을 깨달았다.

2. 알림 조회 성능 개선 - 반정규화

hyomee2 — Fri, 3 Jul 2026 14:08:45 +0900

본 게시물은 트래블록스 프로젝트를 진행하며 발생한 문제 및 개선 사항을 정리한 글입니다.

https://hyomee2.tistory.com/132

1. 알림 조회 성능 개선 - 인덱스

본 게시물은 트래블록스 프로젝트를 진행하며 발생한 문제 및 개선 사항을 정리한 글입니다. 배경초기 알림 테이블(notifications)에는 별도의 인덱스가 없이 설계되었지만, 대용량 환경을 대비해

hyomee2.tistory.com

앞선 글에서는 인덱스를 이용해서 조회 쿼리 시간을 크게 단축시킬 수 있었다.

하지만 실제 사용자가 체감하는 것은 쿼리 실행 시간이 아니라 API 응답 시간이므로,

실제 서비스 관점에서 성능을 검증하고자 k6을 이용해 부하테스트를 진행했다.

부하테스트

import http from 'k6/http';
import { check, sleep } from 'k6';
import { Trend } from 'k6/metrics';

const BASE_URL = __ENV.BASE_URL || 'http://3.27.246.45:8080';

export const notificationLatency = new Trend('notification_latency', true);

export const options = {
    scenarios: {
        notification_load_test: {
            executor: 'ramping-vus',  // 동시 사용자수 점진 증가
            startVUs: 0,
            stages: [
                { duration: '20s', target: 20 },   // 워밍업
                { duration: '1m', target: 50 },   // 실제 측정 구간
                { duration: '20s', target: 0 },    // 종료
            ],
            gracefulRampDown: '30s',
        },
    },
    // thresholds: {
    //     // 알림 API에 대해서만 p95 기준 적용 (로그인 제외)
    //     'http_req_duration{name:notifications}': ['p(95)<300'],  // p95가 300ms 미만이어야 성공
    //     'http_req_failed{name:notifications}': ['rate<0.01'],
    // },
};


// 로그인
export function setup() {
    const loginRes = http.post(
        `${BASE_URL}/api/v1/auth/login`,
        JSON.stringify({
            email: 's5763305@naver.com',
            password: 'hyoungmi1015',
        }),
        { headers: { 'Content-Type': 'application/json' } }
    );

    check(loginRes, {
        'login success': (r) => r.status === 200,
    });

    const token = loginRes.json('data.accessToken');

    if (!token) {
        throw new Error('login fail');
    }

    return { token };
}

// 실제 부하테스트
export default function (data) {
    const url = `${BASE_URL}/api/v1/notifications?size=10`;

    const res = http.get(url, {
        headers: {
            Authorization: `Bearer ${data.token}`,
        },
        tags: {
            name: 'notifications',
        },
    });

    notificationLatency.add(res.timings.duration);

    check(res, {
        'status is 200': (r) => r.status === 200
    });

    if (res.status !== 200) {
        console.log(`status: ${res.status}`);
        console.log(`body: ${res.body}`);
    }

    sleep(0.2); // 실제 사용자 행동 간격
}

테스트 시나리오는 아래와 같이 구성했다.

1. 점진적으로 동시 사용자 증가

            stages: [
                { duration: '20s', target: 20 },   // 워밍업
                { duration: '1m', target: 50 },   // 실제 측정 구간
                { duration: '20s', target: 0 },    // 종료
            ],

처음부터 100명의 사용자를 동시에 생성하지 않고,

실제 서비스 환경과 최대한 유사하게 진행해보고자 사용자가 점점 증가하는 상황을 가정했다.

- 20초 동안 20명까지 증가 (워밍업)

- 1분 동안 50명 유지하며 실제 성능 측정

- 20초 동안 점진적으로 종료

JVM 초기화, 커넥션 풀 생성 등의 영향이 있을 수 있기 때문에 이를 최소화하고 안정적인 상태에서 성능을 측정하고자 워밍업 구간을 두었다.

2. 로그인은 한 번만 수행

로그인의 경우는 우리가 테스트하고자 하는 API와 별도이지만 선행되어야 하므로 setup()에서 수행한 후,

모두 동일한 토큰을 이용하도록 구성하여 로그인 API의 성능이 결과에 영향을 주지 않도록 했다.

테스트 결과

아래는 인덱스 적용 전,

아래는 인덱스(Covering Index + PK Lookup)을 적용한 후의 부하테스트 결과이다.

결과를 정리해보면 아래와 같다.

지표	인덱스 적용 전	인덱스 적용 후	개선율
Average	9,670ms	1,980ms	79.5%
p95	15,530ms	3,330ms	78.6%
RPS(http_reqs/s)	3.0req/s	12.8req/s	76.6%

표를 확인하면 인덱스 적용 전에 비해 적용 후가 수치적으로 훨씬 개선된 것은 맞다.

하지만 알림 자체를 조회하는 쿼리는 지난 측정에 따르면 0.537ms에 불과한데, 평균 기준 나머지 약 1,980ms는 어디에서 발생했는지 의문이었다.

따라서 아래와 같이 StopWatch를 이용하여 또 다른 병목 지점이 어디인지 파악해보았다.

(이 부분은 %만 확인하면 된다고 생각해서 로컬에서 로그로 찍어보았다)

결과는 확실했다.바로 count 쿼리가 대부분의 시간을 차지했다.

따라서 count 병목을 제거하고자 했다.

COUNT 집계 쿼리 병목을 어떻게 개선할 것인가?

COUNT 연산을 제거하기 위해 두가지 방식을 고민했다.

1. 반정규화

첫번째로 생각한 방식은 members 테이블에 알림 개수를 저장하여 반정규화 하는 방식이었다.

장점

- DB 트랜잭션 내에서 관리 가능

- 간단하게 조회 가능

2. Redis을 이용한 관리

다음으로는 Redis에 사용자별 알림 개수를 저장하고, 조회 시 DB가 아닌 Redis에서 바로 값을 가져오는 방식을 생각했다.

장점

- 메모리 기반 저장소이므로 매우 빠르게 조회 가능

단점

- Redis와 DB 간 데이터 정합성 추가적으로 관리 필요

- 장애 발생 시 Redis와 DB의 값이 달라질 수 있어 복구 로직 필요

3. 결론

이번 COUNT 병목을 해결하는데 있어서는 "반정규화" 방식을 사용하기로 했다.

그 이유는 아래와 같다.

- 사용자별로 카운트 -> 실시간으로 급격히 증가하는 값이 아님

- PK 조회이므로 반정규화로도 충분히 빠를 것으로 판단

- Redis를 도입할 만큼의 트래픽은 아님

COUNT 집계 쿼리 개선 결과

지표	인덱스 적용 후	COUNT 제거 후	개선율
Average	1,980ms	157.0ms	97.4%
p95	3,330ms	179.6ms	97.1%
TPS(http_reqs/s)	12.8req/s	76.2req/s	66.2%

지표	인덱스 적용 전	인덱스 적용 후	COUNT 제거 후	개선율
Average	9,670ms	1,980ms	157.0ms	98.4%
p95	15,530ms	3,330ms	179.6ms	98.8%
RPS(http_reqs/s)	3.0req/s	12.8req/s	76.2req/s	96.1%

마무리

사실 이전에는 데이터베이스에서 정규화에 대한 내용을 배우며 "정규화할 수 있으면 항상 하는게 좋은거 아닌가?" 라는 생각을 했었다.

이론적으로는 상황에 따라 반정규화가 더 적합할 수도 있다고 했지만, 직접 와닿지는 않은 것 같다.

하지만 이번 기회를 통해 쿼리 시간은 크게 단축했는데 API 응답 속도는 단축되지 않은 것을 보면서 의아함을 느꼈다.

이 과정에서 사용자가 실제로 체감하는 것은 API 응답 시간일 것이므로,

단순히 쿼리 성능이 좋아졌다는 결과에 만족하는 것이 아니라

실제 병목이 어디에 있는지 파악하고 실제 API 응답 시간을 최적화하는데에 초점을 맞춰야겠다는 깨달음을 얻었다.

또한 StopWatch을 이용해 API 내부적으로 구간별 실행 시간을 측정하며 병목 지점을 직접 파악하고 개선하는 것도 의미있었다.

처음에는 "어디가 병목인지 어떻게 파악하지?" 라는 생각으로 "집계 쿼리가 문제인가?" 라는 감을 가지고 시작했지만,

측정을 기반으로 근거를 가지고 병목을 찾아 개선하는 과정의 중요성도 배울 수 있었다.

앞으로도 최적화가 필요한 상황에서는 병목 지점이 어디인지 파악하고, 찾은 병목에 대해 가장 적합한 개선 방안을 선택하고자 한다.

1. 알림 조회 성능 개선 - 인덱스

hyomee2 — Fri, 3 Jul 2026 00:02:54 +0900

본 게시물은 트래블록스 프로젝트를 진행하며 발생한 문제 및 개선 사항을 정리한 글입니다.

배경

초기 알림 테이블(notifications)에는 별도의 인덱스가 없이 설계되었지만,

대용량 환경을 대비해 안정적인 성능을 유지할 수 있도록 최적화가 필요하다고 판단했다.

따라서 1차적으로는 복합 인덱스를 통해, 2차적으로는 Covering Index 전략을 이용해 조회 성능을 최적화하려 했다.

커서 기반 페이징을 이용했기에 사용한 SQL문은 아래와 같았다.

SELECT notification_id, created_at, actor_id, actor_nickname_snapshot, receiver_id, template_id, type
FROM notifications
WHERE receiver_id = 1
ORDER BY created_at DESC, notification_id DESC
LIMIT 10;

대용량 데이터 삽입

실제 운영 환경을 가정하여 40만 건의 더미 데이터를 아래 SQL문을 통해 삽입해주었다.

SET autocommit = 0;

INSERT INTO notifications (
    created_at, actor_id, actor_nickname_snapshot, receiver_id, template_id, type
)
SELECT
    NOW(6) - INTERVAL FLOOR(RAND() * 365) DAY
        - INTERVAL FLOOR(RAND() * 86400) SECOND,
    FLOOR(1 + RAND() * 3),
    ELT(FLOOR(1 + RAND() * 3), '판당이', '효미', '조아'),
    CASE
        WHEN RAND() < 0.7 THEN 1
        WHEN RAND() < 0.9 THEN 2
        ELSE 3
        END,
    FLOOR(1 + RAND() * 100000),
    ELT(FLOOR(1 + RAND() * 2), 'TEMPLATE_FAVORITED', 'TEMPLATE_REMIXED')
FROM information_schema.columns a
         CROSS JOIN information_schema.columns b
LIMIT 400000;

COMMIT;
SET autocommit = 1;

데이터 수 확인하기

SQL문을 활용하여 40만개의 데이터 수를 확인했다.

SELECT COUNT(*) AS cnt FROM notifications;

조회 성능 비교

[기존] 인덱스 미적용 상태의 실행

EXPLAIN ANALYZE
SELECT notification_id, created_at, actor_id, actor_nickname_snapshot, receiver_id, template_id, type
FROM notifications
WHERE receiver_id = 1
ORDER BY created_at DESC, notification_id DESC
LIMIT 10;

EXPLAIN ANALYZE를 확인해 실제 측정값을 확인해보았다.

평균값을 내기 위해 총 5번 실행을 해주었으며, 첫 시도는 제외했다.

해석

아래에서부터 위로 진행된다고 생각하면 된다.

- Table scan on n -> 테이블 n 전체를 읽는다. (Full Table Scan)

- Filter -> 조건 필터링

- Sort -> 필터링된 데이터를 정렬 규칙에 따라 정렬

- Limit: 10 row(s) -> Limit 10이 적용되어 최종적으로 10개의 데이터 반환한다.

결과

- Full Table Scan 발생 (약 40만 건 전체 탐색)

- 필터링 후 정렬 수행 (매우 큰 정렬 비용, 실행 시간의 대부분이 정렬 비용)

- 평균 DB 내부 실행 시간 242ms

원인

- WHERE과 ORDER BY를 동시에 만족하는 복합 인덱스의 부재

- 대량의 정렬 비용 발생

- LIMIT가 있지만 전부 수행되는 정렬

[1차 개선] 복합 인덱스 설계 -> '정렬 제거'에 집중

아래와 같이 WHERE과 ORDER BY를 동시에 만족하도록 복합 인덱스를 설계해주었다.

CREATE INDEX idx_notifications_receiver_created_id
ON notifications (receiver_id, created_at DESC, notification_id DESC);

SELECT문은 위에서와 같이 실행해주었다.

EXPLAIN ANALYZE
SELECT notification_id, created_at, actor_id, actor_nickname_snapshot, receiver_id, template_id, type
FROM notifications
WHERE receiver_id = 1
ORDER BY created_at DESC, notification_id DESC
LIMIT 10;

마찬가지로 EXPLAIN ANALYZE를 확인해 실제 측정값을 확인해보았다.

평균값을 내기 위해 총 5번 실행을 해주었다.

결과

- Full Scan 제거

- Filesort 제거

- Index range scan 적용

- 평균 DB 내부 실행 시간 5.5ms

[2차 개선] Covering Index + PK Lookup -> '접근 구조'에 집중

1차 개선을 통해서도 약 97.7%의 성능 향상이 있었다.

1차 개선에서는 쿼리에 필요한 모든 컬럼을 인덱스가 포함하는 것은 아니어서 1) Index 탐색 2) PK 조회 3) 테이블 접근(랜덤 I/O) 의 단계를 거치는데, Covering Index를 통해 랜덤 I/O를 제거하고, 디스크 접근을 최소화하고자 했다.

EXPLAIN ANALYZE
SELECT n.notification_id, n.created_at, n.actor_id,
       n.actor_nickname_snapshot, n.receiver_id,
       n.template_id, n.type
FROM notifications n
    JOIN (
        SELECT notification_id
        FROM notifications
        WHERE receiver_id = 1
        ORDER BY created_at DESC, notification_id DESC
        LIMIT 10
    ) as temp ON n.notification_id = temp.notification_id;

위와 같이 쿼리를 개선함에 따라

서브쿼리에서는 인덱스만 사용해서 notification_id만 추출하고 테이블 접근이 없고(Covering Index)

이후 PK lookup을 10회 수행하게 된다.

여기서 Covering Index에 대해 조금 더 설명하자면,

쿼리에 필요한 모든 컬럼을 인덱스가 포함하고 있어 테이블에 다시 접근하지 않아도 되는 인덱스를 의미한다.

해석

- Covering index range scan -> 커버링 인덱스 이용. 최신순 조회를 하므로 인덱스를 뒤에서부터 읽어서 reverse가 붙어있다.

- Filter -> 조건 필터링

- Limit: 10 row(s) -> 10개의 데이터 반환한다.

- Materialize -> 찾은 데이터를 메모리에 temp 테이블로 저장 (임시 테이블)

- Table Scan on temp -> temp 테이블의 10개 데이터 스캔

- Nested loop inner join -> temp의 각 notification_id마다 PK 조회

- Single-row index lookup -> PK로 한 건씩 조회

결과

- 테이블 접근 최소화

- 평균 DB 내부 실행 시간 0.537ms

1차 개선 VS 2차 개선

InnoDB에서 Secondary Index 리프에는 '인덱스 컬럼 + PK'만 저장되기 때문에 실제 row 데이터는 PK를 통해 다시 읽어야 한다.

1차 개선에서는 인덱스에 있는 컬럼 이외에도 조회해야하는 데이터가 있기 때문에 PK로 row마다 테이블에 접근해야 해서 I/O가 생기게 된다.

하지만 2차 개선의 서브 쿼리에는 인덱스 안에 필요한 컬럼이 있기 때문에 서브 쿼리 내에서는 테이블 접근이 없고, 외부 JOIN에서만 PK로 테이블에 10번 접근하기 때문에 더 좋은 성능을 갖게 된다.

	개선 전	1차 개선	2차 개선	실행시간 개선율
평균	242	5.5	0.537	99.8%

(단위: ms)

삽입 성능 비교

조회 최적화를 위해 보조 인덱스를 도입했고, 조회 성능은 약 99.8%가 향상되는 효과가 있었다.

하지만, 인덱스를 하나 추가 하게 되면, row를 하나 삽입할 때 인덱스 개수만큼 B+Tree에 삽입이 발생하게 된다. (O(log N))

하지만 O(log N)보다 체감이 더 클 수도 있는데,

그 이유는 B+Tree 리프 페이지가 16KB이기 때문에 새 데이터가 들어왔을 때 해당 페이지에 공간이 없으면 페이지 분할이 발생하기 때문이다.

위에서 보조인덱스를 1개 추가해주었는데, 삽입 성능도 측정해볼 필요성을 느껴 측정해보았다.

기존의 40만개의 데이터에 추가로 20만개의 데이터를 넣어주었다.

[기존] 인덱스 미적용 상태의 실행

아래는 인덱스가 없을 때의 실행 결과로, 평균값을 내기 위해 총 5번 실행을 해주었으며, 첫 시도는 제외했다.

결과

- 평균 DB 내부 실행 시간 2826.4ms

[1차 개선] 복합 인덱스 설계

아래는 인덱스가 있을 때의 실행 결과로, 평균값을 내기 위해 총 5번 실행을 해주었으며, 첫 시도는 제외했다.

결과

- 평균 DB 내부 실행 시간 3720.8ms

	인덱스 X	인덱스 O	INSERT 수행 시간 증가율
평균	2826.4	3720.8	31.7%

(단위: ms)

위의 결과를 통해 보조 인덱스를 추가함에 따라 조회 성능은 증가하였지만, 쓰기 성능은 감소한 것을 확인할 수 있다.

결론적으로, 알림은 현재 읽기 빈도가 쓰기 빈도가 훨씬 크다고 판단했고, 읽기 성능이 전체 시스템 성능에 더 중요하다고 판단해 인덱스를 도입하기로 결정했다.

물론 쓰기 성능이 훨씬 중요한 기능에서는 아무리 조회 성능이 좋아졌다고 해서 그에 따른 쓰기 성능이 감소할 것이기 때문에 다른 결정을 내려야 할 수도 있다. 읽기 성능, 쓰기 성능의 트레이드 오프를 고려하여 기능에 적절한 최적화 방식을 선택해야함을 다시금 깨달았다.

[프로그래머스] #42897 도둑질, 원형 DP

hyomee2 — Wed, 10 Jun 2026 23:56:38 +0900

https://school.programmers.co.kr/learn/courses/30/lessons/42897

프로그래머스

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

programmers.co.kr

해당 문제의 핵심은 "원형 구조를 어떻게 처리할 것인가" 이다.

집들이 원형으로 배치되어 있으므로, 0번 집을 털고 마지막 집도 터는 경우는 불가능하다.

따라서 경우를 나눠줘야 한다.

1. 0번 집을 터는 경우

- 마지막 집은 선택할 수 없다.

- 따라서 탐색 범위는 0 ~ (length -2)가 되고

for (int i = 2; i < money.length - 1; i++)

- 훔칠 수 있는 돈의 최댓값은 아래와 같다.

dp[money.length - 2]

2. 0번 집을 털지 않는 경우

- 마지막 집을 선택할 수 있다.

- 이때는 0번째집은 무시하고 탐색 범위는 1 ~ (length - 1)로 진행한다.

dp[1] = money[1];

for (int i = 2; i < money.length; i++)

- 훔칠 수 있는 돈의 최댓값은 아래와 같다.

dp[money.length - 1]

전체 코드는 아래와 같다.

class Solution {
    public int solution(int[] money) {
        int answer = 0;
        int[] dp = new int[money.length];
        
        // 첫번째 집 방문하는 경우
        dp[0] = money[0];
        dp[1] = dp[0];
        
        for (int i = 2; i < money.length - 1; i++) {
            dp[i] = Math.max(dp[i - 1], dp[i - 2] + money[i]);
        }
        
        answer = dp[money.length - 2];
        
        // 첫번째 집 방문 안하는 경우
        dp = new int[money.length];
        dp[1] = money[1];
        for (int i = 2; i < money.length; i++) {
            dp[i] = Math.max(dp[i - 1], dp[i - 2] + money[i]);
        }

        return (answer < dp[money.length - 1]) ? dp[money.length - 1] : answer;
    }
}

[백준] #9205 맥주 마시면서 걸어가기, BFS

hyomee2 — Mon, 30 Mar 2026 21:55:59 +0900

https://www.acmicpc.net/problem/9205

시도 1

처음에 제출한 코드는 아래와 같다.

문제를 읽고 생각해보면서, 좌표와 좌표 사이의 거리가 1000 이하면 되는 문제네? 라고 생각하면

별도의 알고리즘 없이 구현하는 문제라고 생각했다.

여기서 내가 잘못 생각한 점은 주어진 편의점을 "순서대로" 방문하는 것이 아니라 방문 순서를 정할 수 있는데, 그 점을 놓쳤다.

또 아래 코드를 보니 굳이 시작, 편의점, 페스티벌 좌표를 나눌 필요없이 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));
        int t = Integer.parseInt(br.readLine()); // 테스트 케이스 수
        StringTokenizer st;
        StringBuilder sb = new StringBuilder();

        // 배열로 상황 만들기
        for (int i = 0; i < t; i++) {
            int n = Integer.parseInt(br.readLine()); // 맥주 파는 편의점 수
            st = new StringTokenizer(br.readLine(), " ");
            int[][] loc = new int[n + 2][2];
            loc[0] = new int[]{Integer.parseInt(st.nextToken()), Integer.parseInt(st.nextToken())};

            for (int j = 0; j < n; j++) {
                st = new StringTokenizer(br.readLine(), " ");
                loc[j + 1] = new int[]{Integer.parseInt(st.nextToken()), Integer.parseInt(st.nextToken())};
            }

            st = new StringTokenizer(br.readLine(), " ");
            loc[n + 1] = new int[]{Integer.parseInt(st.nextToken()), Integer.parseInt(st.nextToken())};

            for (int j = 0; j < n + 1; j++) {
                int distance = (Math.abs(loc[j + 1][0] - loc[j][0]) + Math.abs(loc[j + 1][1] - loc[j][1]));
                if (distance > 1000) {
                    sb.append("sad").append("\n");
                    break;
                }

                if (j == n) {
                    sb.append("happy").append("\n");
                }
            }
        }

        System.out.println(sb);
    }
}

시도 2

아~ 편의점 방문 순서가 입력 순서가 아닌 것을 깨닫고, BFS를 생각하게 되었다.

해당 문제는 어떻게든 락 페스티벌에 도착하면 되는 것이기 때문에, 너비 우선 탐색을 이용하면 초반에 거를 수 있는 경로가 있을 것이라고 판단했다.

위에서 불필요하게 시작점, 편의점, 페스티벌 장소 코드를 분리했던 것을 한 번의 for문으로 입력 받았고, bfs을 이용해서 구현했다.

좌표로 visited 같은 배열을 만드는 것은 불필요하다고 생각해서 인덱스를 이용해 흐름을 설계했다.

또 중요한 점은 거리니까 절댓값을 해줘야 한다는 점..!

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

public class Main {
    static Deque<Integer> queue;
    static boolean[] visited;
    static int n;
    static int[][] loc;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int t = Integer.parseInt(br.readLine()); // 테스트 케이스 수
        StringTokenizer st;
        StringBuilder sb = new StringBuilder();

        // 배열로 상황 만들기
        for (int i = 0; i < t; i++) {
            n = Integer.parseInt(br.readLine()); // 맥주 파는 편의점 수
            visited = new boolean[n + 2];
            loc = new int[n + 2][2];

            // loc 만들기
            for (int j = 0; j < n + 2; j++) {
                st = new StringTokenizer(br.readLine(), " ");
                loc[j] = new int[]{Integer.parseInt(st.nextToken()), Integer.parseInt(st.nextToken())};
            }

            String answer = bfs() ? "happy" : "sad";
            sb.append(answer).append("\n");
        }

        System.out.println(sb);
    }

    public static boolean bfs() {
        queue = new ArrayDeque<>();
        visited[0] = true;
        queue.offer(0);

        while (!queue.isEmpty()) {
            int newIndex = queue.poll();

            if (newIndex == n + 1) {
                return true;
            }

            for (int i = 1; i < n + 2; i++) {
                if (!visited[i]) {
                    int distance = Math.abs(loc[newIndex][0] - loc[i][0]) + Math.abs(loc[newIndex][1] - loc[i][1]);

                    if (distance <= 1000) {
                        visited[i] = true;
                        queue.offer(i);
                    }
                }
            }
        }

        return false;
    }
}

[프로그래머스] #87694 아이템 줍기

hyomee2 — Mon, 16 Mar 2026 21:53:27 +0900

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

프로그래머스

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

programmers.co.kr

생각해야 하는 점

흔히 마주하는 BFS/DFS 문제(맵, 미로찾기 등)와 비슷해 보이지만 해당 문제는 각 칸에 대해 0/1(벽인지 길인지)로 주어져있지는 않다.

그래서 처음에는 어떻게 해야하는지 고민했는데, 그럼 내가 직접 0/1 구조(이동할 수 있는 길은 1, 안되는 길은 0)로 map을 만들어주면 되겠다고 생각했다.

근데 그렇게 하면 문제가 발생하는데, 좌표가 붙어있는데 길은 없을 경우 1과 1이 인접하여 길이 있다고 판단할 수 있다.

따라서 이러한 문제를 해결하는 방법 중 하나는 모든 좌표를 2배로 늘리는 것이다. 그럼 좌표들 사이에 길이 없을 경우 0이 되어 길이 없음을 코드 상으로 구현할 수 있다.

코드 구현

1. 우선 map을 만들어줄건데, 모두 1로 넣어준 뒤, 내부는 0으로 바꿔준다.

-> 이 과정을 거치면 이제는 흔히 마주하던 미로 탐색 문제와 같다.

2. 가장 짧은 거리를 구해줘야 하므로 BFS를 수행하고 반환한다.

-> 이때 모든 좌표에 2배 해주었으므로 다시 2배를 나누어 반환한다.

작성한 코드는 아래와 같다.

import java.util.*;

class Solution {
    static int[][] map;
    public int solution(int[][] rectangle, int characterX, int characterY, int itemX, int itemY) {
        map = new int[101][101];
        
        // map 만들기 - 1로 채움
        for (int[] rect : rectangle) {
            for (int i = rect[0] * 2; i <= rect[2] * 2; i++) {
                for (int j = rect[1] * 2; j <= rect[3] * 2; j++) {
                    map[i][j] = 1;
                }
            }
        }
        
        // map 만들기 - 내부는 0으로 빈칸 표시
        for (int[] rect : rectangle) {
            for (int i = rect[0] * 2 + 1; i < rect[2] * 2; i++) {
                for (int j = rect[1] * 2 + 1; j < rect[3] * 2; j++) {
                    map[i][j] = 0;
                }
            }
        }
        
        return bfs(characterX * 2, characterY * 2, itemX * 2, itemY * 2);
    }
    
    private int bfs(int startX, int startY, int itemX, int itemY) {
        Deque<int[]> queue = new ArrayDeque<>();
        boolean[][] visited = new boolean[101][101];
        int[] dx = {1, 0, -1, 0};
        int[] dy = {0, -1, 0, 1};
        
        queue.offer(new int[]{startX, startY, 0});
        visited[startX][startY] = true;
        
        while(!queue.isEmpty()) {
            int[] location = queue.poll();
            
            if (location[0] == itemX && location[1] == itemY) {
                return location[2] / 2;
            }
            
            for (int i = 0; i < 4; i++) {
                int nx = location[0] + dx[i];
                int ny = location[1] + dy[i];
                
                if (nx >= 0 && nx <= 100 && ny >= 0 && ny <= 100 && map[nx][ny] == 1 && !visited[nx][ny]) {
                    visited[nx][ny] = true;
                    queue.offer(new int[] {nx, ny, location[2] + 1});
                }
            }
        }
        
        return -1;
    }
}

[백준] #1783 병든 나이트, 그리디

hyomee2 — Thu, 12 Mar 2026 14:16:37 +0900

https://www.acmicpc.net/problem/1783

나이트가 이동할 수 있는 규칙은 아래 4가지이다.

1. 2칸 위, 1칸 오른쪽

2. 1칸 위, 2칸 오른쪽

3. 1칸 아래, 2칸 오른쪽

4. 2칸 아래, 1칸 오른쪽

처음에는 응? 그냥 이동하면 모든 칸을 방문할 수 있는거 아닌가?

라고 생각했는데, 움직일 수 있는 규칙을 잘 보면 모두 "오른쪽"으로 움직일 수 있다.

문제를 조금 파악해보고자 아래와 같이 그림을 그려봤다.

1. 세로(N)가 1일 때

- 위아래로 움직일 수 없으니 1칸만 방문할 수 있다.

2. 세로(N)가 2일 때

- 1칸 위아래로만 이동할 수 있으므로 규칙 2, 3번만 이용이 가능하다.

- 이때 2, 3번은 가로로 2칸씩 가야하므로, 방문 칸수는 (M + 1) / 2인데 최대 4칸까지 갈 수 있다. (4가지 규칙 다 못쓰므로)

3. 세로(N)가 3 이상일 때

- 가로(M)가 7미만이라면 4가지 규칙을 다 쓸 수 없으므로 최대 4칸까지 갈 수 있다.

- 가로(M)가 7 이상이면 모든 규칙을 한 번씩 다 쓸 수 있는데, 4가지 규칙을 다 쓰는데 5칸을 방문해야하고, 남은 가로들로는 가장 효율적으로 오른쪽으로 1칸 이동 규칙(1, 4번)을 이용하면 된다. 따라서 식으로 표현하면 5 + (M - 7) = M - 2 이다.

식을 정리하면 아래와 같이 쓸 수 있다.

이걸 코드로 아래와 같이 표현할 수 있다.

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));
        StringTokenizer st = new StringTokenizer(br.readLine(), " ");
        int N = Integer.parseInt(st.nextToken());
        int M = Integer.parseInt(st.nextToken());

        if (N == 1) {
            System.out.println(1);
        } else if (N == 2) {
            System.out.println(Math.min((M + 1) / 2, 4));
        } else {
            if (M < 7) {
                System.out.println(Math.min(M, 4));
            } else {
                System.out.println(M - 2);
            }
        }
    }
}

[백준] #11497 통나무 건너뛰기, 그리디

hyomee2 — Tue, 10 Mar 2026 03:53:24 +0900

https://www.acmicpc.net/problem/11497

문제 요약

통나무들을 원형으로 배치했을 때, 인접한 통나무의 높이 차이의 최댓값을 최소화해야 한다.

즉,

max(|a[i] - a[i+1]|)

의 최솟값을 구해야 한다. (원형이므로 첫번째와 마지막도 인접)

아이디어

우리는 차이가 작아지게 해야하는데, 차이가 커지는 경우는 큰값과 작은값이 함께 붙어있을 때이다.

따라서 우리는 큰 값과 작은 값이 붙지 않게 배치해야 한다.

이럴 경우,

a0 a1 a2 a3 ... aN-1

이렇게 오름차순이라고 하면

아래와 같이 배치할 수 있다.

a0 a2 a4 ... a5 a3 a1

풀이

1. 우선 문제에서는 정렬되지 않은 통나무의 높이가 주어지므로 정렬을 해준다.

2. Deque을 이용해 'a0 a2 a4 ... a5 a3 a1' 이런 꼴로 배치해준다.

3. 배열을 순회하며 최댓값을 담아준다. (원형이므로 처음과 마지막 비교를 잊지 않는다.)

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

public class Main {
    static StringBuilder sb = new StringBuilder();
    static StringTokenizer st;

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

        for (int i = 0; i < T; i++) {
            int N = Integer.parseInt(br.readLine());
            int[] temp = new int[N];;
            st = new StringTokenizer(br.readLine());

            for (int j = 0; j < N; j++) {
                temp[j] = Integer.parseInt(st.nextToken());
            }

            Arrays.sort(temp);  // 시간복잡도: O(N log N)

            Deque<Integer> deque = new LinkedList<>();

            for (int j = 0; j < N; j++) {  // 시간복잡도: O(N) (deque 연산 O(1)이 N번)
                if (j % 2 == 0) {
                    deque.addFirst(temp[j]);
                } else {
                    deque.addLast(temp[j]);
                }
            }

            Integer[] result = deque.toArray(Integer[]::new);  // 시간복잡도: O(N) (모든 원소 복사)

            int level = 0;

            for (int j = 0; j < N - 1; j++) {  // 시간복잡도: O(N)
                level = Math.max(level, Math.abs(result[j + 1] - result[j]));
            }

            // 처음, 마지막 것 검사(원형)
            level = Math.max(level, Math.abs(result[N - 1] - result[0]));
            sb.append(level).append("\n");
        }

        System.out.println(sb);
    }
}

// 총 시간 복잡도: O(N log N)

하지만 'a0 a2 a4 ... a5 a3 a1' 이 꼴을 잘보면 결국 이웃한 것끼리는 인덱스 2칸 차이나는 것을 볼 수 있고,

따라서 아래와 같이 코드를 간단하게 작성할 수 있다.

            Arrays.sort(a);
            
            for(int k = 0; k < N-2; k++) {
                max = Math.max(max, a[k+2]-a[k]);
            }

이때, a4와 a5는 1 차이인데 저 코드로 이 두값을 비교하지 못하는거 아닌가? 하는 생각이 들었다.

맞다. 하지만 이 둘이 비교할 필요가 없다!
a는 정렬된 오름차순이니, 항상 a5과 a3의 차이가 a5와 a4의 차이보다 크기 때문이다.

[트러블슈팅] Redis 캐시 조회 시 Invalid UTF-32 character 발생 문제 해결

hyomee2 — Thu, 29 Jan 2026 04:11:56 +0900

본 게시물은 트래블록스 프로젝트를 진행하며 발생한 트러블슈팅을 정리한 글입니다.

이번 프로젝트를 진행하면서 Redis를 처음 직접 사용해보게 되었다.

Redis를 사용하게 되는 구간은 템플릿을 개인별로 추천하게 되면

그 추천 내역을 redis에 15분 간 저장하여 15분 동안은 같은 추천 내용을 불러오는 부분이다.

문제 상황

어느정도 코드를 다 구현하고 swagger로 테스트를 하는데,

처음(캐싱않고 DB를 통해 추천 결과 조회)에는 조회가 되는데 그 다음(캐싱O)에는 아래와 같은 에러가 발생했다.

예외를 요약하면 아래와 같다.

org.springframework.data.redis.serializer.SerializationException:
Could not read JSON: Invalid UTF-32 character ... (above 0x0010ffff)

찾아보니,

RedisTemplate.opsForVallue().get() 호출 시

GenericJackson2JsonRedisSerializer가 Redis value를 JSON으로 역직렬화하는 과정에서 실패해서 발생하는 오류라고 한다.

즉, Redis에 JSON으로 저장된 값을 읽어오다 JSON 파싱이 깨졌다는 의미였다.

문제 원인 찾아보기

접근 1. Redis에 value가 어떻게 저장되었는지 확인해보기

나는 아래와 같이 value를 JSON 문자열로 저장하도록 RedisConfig에 설정을 해주었어서 '뭐지?' 싶었다.

        StringRedisSerializer string = new StringRedisSerializer();
        GenericJackson2JsonRedisSerializer json = new GenericJackson2JsonRedisSerializer(mapper);

        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(connectionFactory);

        template.setKeySerializer(string);  // Redis key를 사람이 읽는 문자열로 저장
        template.setValueSerializer(json);  // Redis value를 JSON 문자열로 저장

        template.setHashKeySerializer(string);
        template.setHashValueSerializer(json);

        template.setDefaultSerializer(json);

그래도 우선 어떻게 저장되었는지 확인하기 위해 터미널에서 아래 명령어를 통해 Redis 컨테이너의 key에 저장된 value를 출력해봤다.

 docker exec -i travlocks-redis-local redis-cli --raw GET "recommendation:templates:v1:member:3"

그랬더니 내가 예상했던 JSON 형태로 나와서 value가 JSON이 아닌 Binary(JDK 직렬화)로 저장돼서 발생한 문제는 아니었다.

접근 2. Redis MONITOR로 실제 어떤 명령이 나가는지 확인해보기

애플리케이션이 Redis에 어떤 명령을 치는지 확인해보기 위해 아래 명령어를 통해 Redis 컨테이너에서 MONITOR를 실행했다.

docker exec -it travlocks-redis-local redis-cli MONITOR

그리고 API를 호출해주었더니 아래와 같이 로그가 찍혔다.

1769621375.194768 [0 127.0.0.1:37976] "DEL" "recommendation:templates:v1:member:3"
1769621380.193901 [0 172.20.0.1:63344] "GET" "recommendation:templates:v1:member:3"
1769621380.280639 [0 172.20.0.1:63344] "SETRANGE" "recommendation:templates:v1:member:3" "15" "{\"recommendationId\": ... ,\"totalScore\":36.928031367991565}]}"

위의 로그를 보면 SET이 아닌 SETRANGE가 나간 것을 확인할 수 있었다. 어느정도 가닥이 잡혔다.

SETRANGE key offsest value는 Redis String의 특정 위치(offset)부터 덮어쓰는 커맨드다.

위의 로그를 해석해보면

이 value의 15번째 위치부터 우리의 데이터를 넣고, 그 이전(0~14번째 바이트)은 자동으로 채우라는 의미이다.

자동으로 채우면 데이터 앞에는 널 문자(\x00)가 15개 붙고,

우리가 Redis에서 볼 때는 JSON으로 데이터가 잘 저장된 것처럼 보이지만 실제로 맨 앞에는 보이지 않는 바이너리가 있었던 것이다.

Jackson은 value를 맨 앞 바이트부터 읽으며 첫 글자가 { 여야 JSON이라고 판단하는데,

실제 첫 바이트가 \x00이니 UTF-32로 오판했던 것이다.

해결 방법

그래서 set()에서 잘못된 것을 찾기 시작했다.

캐시 저장 코드는 아래와 같았다.

@Value("${cache.recommendation.templates.cache-ttl-minutes}")
private long ttlMinutes;
    
public void set(Long memberId, CachedTemplateRecommendations value) {
    redis.opsForValue().set(key(memberId), value, ttlMinutes);
}

여기서 set 함수에 hover를 해보았더니

ValueOperations의 set의 마지막 매개변수의 타입이 Duration이 돼야하는 것을 확인할 수 있었다.

처음에는 long인 ttlMinutes를 매개변수로 넣어주었는데, 아래와 같이 Duration 타입으로 넣어주었다.

public void set(Long memberId, CachedTemplateRecommendations value) {
	redis.opsForValue().set(key(memberId), value, Duration.ofMinutes(ttlMinutes));
}

그리고 다시 API 요청을 날린 뒤 MONITOR을 확인해보니 의도한대로 SET이 발생하고,

캐싱된 데이터가 정상적으로 조회되는 것을 확인할 수 있었다.

왜 이런 일이 발생했던 것일까?

문제는 해결됐는데... 왜 SETRANGE가 MONITOR에 찍혔는지 궁금했다.

따라서 JavaDoc를 살펴보다보니 아래와 같은 set 함수를 찾아볼 수 있었다.

시그니처가 (K, V, long)으로 내가 썻던 매개변수 형태와 완전 일치했고,

해당 함수에 오버로딩되어 SETRANGE가 찍혔구나라고 추측할 수 있었다.

즉 내가 매개변수로 넣어준 Long ttlMinutes인 15가 offset으로서 들어간거였다.