Ich bin rati

객체 지향 : 상속, 합성, 조합

rati — Fri, 3 Apr 2026 17:10:16 +0900

객체 지향적인 코드를 구성하는 방법에는 상속 합성 조합 이 있습니다.

우아한 테크코스에서 장기 를 하며, 해당 개념에 대해 학습한 후 어떻게 사용하였는 지 정리하였습니다.

1. 상속

상속 은 객체의 책임, 역할은 같으나 구현 방식이 다를 때 사용되어야 합니다.

장기에는 차, 마, 상, 사, 궁, 포, 졸(병) , 총 7가지 기물이 있습니다.

미션에서 제가 정의한 기물(Piece) 의 역할은 보드 위의 특정 좌표까지 갈 수 있다면 경로를 제공하는 것이었습니다. 이동 가능성을 확인하고 경로를 제공하는 세부적인 구현이 7개 이상 나오겠다는 생각을 하여 상속 을 사용하였습니다.

추가적으로 기물(Piece) 의 경우에는 각자 다른 팀과 타입을 이동 가능성을 확인하기 위해 가져야하기 때문에 추상 클래스로 구현하였습니다.

moveStrategy 에 대해서는 후술하겠습니다.

public abstract class Piece {
    protected final MoveStrategy moveStrategy;
    private final PieceType pieceType;
    private final Team team;

    public Piece(MoveStrategy moveStrategy, PieceType pieceType, Team team) {
        this.moveStrategy = moveStrategy;
        this.pieceType = pieceType;
        this.team = team;
    }

    abstract public void check(BoardStatus boardStatus, Position start, Position destination);

    abstract public boolean isEmpty();

}

이후 포 를 제외한 모든 기물들의 이동 경로를 확인하는 과정에서 다른 기물을 뛰어 넘을 수 없다는 공통점을 공통화하기 위해서 NonJumpable 이라는 추상 클래스를 공통으로 도입하였습니다.

public abstract class NonJumpable extends Piece {
    public NonJumpable(MoveStrategy moveStrategy, PieceType pieceType, Team team) {
        super(moveStrategy, pieceType, team);
    }

    @Override
    public void check(BoardStatus boardStatus, Position start, Position destination) {
        List<Position> movablePath = moveStrategy.findMovablePath(start, destination);
        checkPathIsEmpty(boardStatus, movablePath);
    }

    @Override
    public boolean isEmpty() {
        return false;
    }

    private void checkPathIsEmpty(BoardStatus boardStatus, List<Position> movablePaths) {
        for (Position movablePath : movablePaths) {
            if (isOccupied(boardStatus, movablePath)) {
                throw new IllegalArgumentException(PieceErrorMessage.PATH_BLOCKED.getMessage());
            }
        }
    }

    private boolean isOccupied(BoardStatus boardStatus, Position movablePath) {
        return boardStatus.status().containsKey(movablePath);
    }
}

2. 조합과 합성

조합(Aggregation) 과 합성(Composition) 의 경우 둘 다 Has-a 관계이지만 둘 사이에도 차이점이 있었습니다.

정리하자면 다음과 같습니다.

구분	합성 (Composition)	조합 (Aggregation)
관계 강도	강한 결합 (Strong Has-a)	약한 결합 (Weak Has-a)
생명주기	공유함. 전체가 소멸하면 부분도 소멸.	독립적임. 전체가 소멸해도 부분은 남음.
소유권	독점적 소유.	공유 가능 (여러 곳에서 참조 가능).
구현 방식	내부에서 직접 생성 (`new`).	외부에서 주입받음 (DI).

다른 사람이 작성한 코드에서 조합과 합성을 구분하는 방법은 DI 와 new 키워드였지만, 직접 작성하는 경우에는 생명 주기 를 고민하는 것이 가장 효과적이었습니다.

조합

조합을 사용한 부분들 중 하나는 앞에서 후술하겠다고 한 moveStrategy 였습니다.

Piece 를 설계하는 과정에서 몇 몇 제약 조건이 없이 보드 위에 특정 한 기물만 있다는 조건이면 움직임이 동일한 기물이 있음을 확인했습니다. 예를 들어 포 와 차 의 경우, 다른 기물과의 관계를 생각하지 않으면 상하좌우로 이동 칸 수의 제약 없이 얼마든지 이동할 수 있다는 공통점이 있었습니다.

다른 기물에서도 다른 기물이 없는 경우에는 움직임이 비슷한 경우가 존재하여 다른 기물과의 관계를 고려하지 않는 경우 목적지까지 이동할 수 있는 이동 경로를 제공한다 는 책임을 가지는 strategy 를 도입하였습니다.

예시

*PalaceMoveRule 도 동일한 경우라 추가적인 설명에서 제외.*

공통 인터페이스 정의

package domain.piece.strategy;

import domain.position.Position;
import java.util.List;

public interface MoveStrategy {
    List<Position> findMovablePath(Position start, Position destination);
}

상하좌우 이동 거리 제약이 없는 strategy 구현

public class SlidingMoveStrategy implements MoveStrategy {
    private final PalaceMoveRule palaceMoveRule;

    public SlidingMoveStrategy(PalaceMoveRule palaceMoveRule) {
        this.palaceMoveRule = palaceMoveRule;
    }

    @Override
    public List<Position> findMovablePath(Position start, Position destination) {
        if (start.isSameRow(destination.getRow())) {
            return start.getSameRowPositionsToDestination(destination);
        }
        if (start.isSameColumn(destination.getColumn())) {
            return start.getSameColumnPositionsToDestination(destination);
        }
        if (palaceMoveRule.isPalacePath(start, destination)) {
            return List.of();
        }
        throw new IllegalArgumentException(MoveStrategyErrorMessage.NOT_EXIST_MOVABLE_PATH.getMessage());
    }
}

사용

new Po(new SlidingMoveStrategy(palaceMoveRule);
new Cha(new SlidingMoveStrategy(palaceMoveRule);

합성

합성을 사용한 곳은 BoardInitializer 입니다.

이 객체는 보드가 관리하는 상태의 형태인 Map<Position, Piece> 타입에 맞게 모든 기물을 넣어서 제공하는 역할을 가지고 있습니다.

이 객체를 합성으로 사용한 이유는 우선 해당 객체는 Board 가 없다면, 의미가 없는 쓰레기 코드가 되기 때문이었습니다. 조합을 사용하지 않은 이유는 해당 객체의 경우에는 Board 의 초기값 생성이라는 Board 와 강력하게 결합된 책임이어서 공통으로 사용하지 않기 때문입니다.

설계를 하고 나서 해당 글을 작성하면서 보니 만약 조합 을 사용한다면 getter 의 사용이 필수가 됩니다. 이 경우, BoardInitializer 의 역할은 보드가 관리하는 상태의 타입에 따라 기물과 위치 초기값들을 구성한다가 되고, 자율성을 잃게 되어 변경에 취약할 것 같아, 객체 지향의 사용 이점을 잃게 되기도 합니다.

BoardInitializer

public class BoardInitializer {
    private final Map<PieceType, Piece> choPieces;
    private final Map<PieceType, Piece> hanPieces;

    public BoardInitializer() {
        choPieces = initPieceByTeam(Team.CHO);
        hanPieces = initPieceByTeam(Team.HAN);
    }

    private Map<PieceType, Piece> initPieceByTeam(Team team) {
        PalaceMoveRule palaceMoveRule = new PalaceMoveRule();

        Map<PieceType, Piece> pieces = new HashMap<>();

        pieces.put(PieceType.PO, new Po(new SlidingMoveStrategy(palaceMoveRule), team));
        pieces.put(PieceType.MA, new Ma(new MaMoveStrategy(), team));
        pieces.put(PieceType.SANG, new Sang(new SangMoveStrategy(), team));
        pieces.put(PieceType.SA, new Sa(new SingleStepMoveStrategy(palaceMoveRule), team));
        pieces.put(PieceType.JANG, new Jang(new SingleStepMoveStrategy(palaceMoveRule), team));
        pieces.put(PieceType.CHA, new Cha(new SlidingMoveStrategy(palaceMoveRule), team));
        pieces.put(PieceType.JOL, new Jol(new JolMoveStrategy(palaceMoveRule), team));
        pieces.put(PieceType.BYEONG, new Byeong(new ByeongMoveStrategy(palaceMoveRule), team));
        return pieces;
    }

    public Map<Position, Piece> setup(SettingType choSettingType, SettingType hanSettingType) {
        Map<Position, Piece> defaultSetting = initPiecesWithoutSangAndMa();
        initSangAndMa(choSettingType, hanSettingType, defaultSetting);

        return defaultSetting;
    }

    {아래 생략}

사용

public class Board {
    private final Map<Position, Piece> pieces;

    private Board(Map<Position, Piece> pieces) {
        this.pieces = pieces;
    }

    public static Board of(SettingType choSettingType, SettingType hanSettingType) {
        Map<Position, Piece> setup = new BoardInitializer().setup(choSettingType, hanSettingType);
        return new Board(setup);
    }

    {생략}

}

반박 너무 환영합니다.

반박해주시면 정말 감사하겠습니다.

Avoid Unnecessary Implicit Joins when using QueryDSL

rati — Thu, 19 Mar 2026 23:33:28 +0900

Background

I got advice from gemini3 when I was developing a feature. That feature allows users to accept or reject friend requests.

Gemini3 recommended using ID when querying friend candidates. But from the adapter layer to the application layer, the using user email is an easier method. ( I love @AuthenticationPrincipal from Spring Framework !)

So I decided to compare the performance between using email and using id when querying that.

Test

Target Method

@Repository
class SpringQueryDSLUserRepository(private val queryFactory: JPAQueryFactory) {

    private val user = QUserJpaEntity.userJpaEntity

    // 1. Email-based (Nested subquery - relatively slow)
    fun searchByEmail(userEmail: String, keyword: String): List<UserJpaEntity> {
        return queryFactory.selectFrom(user)
            .where(
                isNicknameMatching(keyword).or(isEmailMatching(keyword)),
                isActive(),
                user.email.ne(userEmail),
                isNotAlreadyFriendEmail(userEmail),
                isNotUnderRequestEmail(userEmail),
                isNotRestrictedEmail(userEmail)
            ).fetch()
    }

    // 2. ID-based (Using constant - relatively fast)
    fun searchById(currentUserId: UUID, keyword: String): List<UserJpaEntity> {
        return queryFactory.selectFrom(user)
            .where(
                isNicknameMatching(keyword).or(isEmailMatching(keyword)),
                isActive(),
                user.id.ne(currentUserId),
                // Directly pass the already extracted ID (constant)
                isNotAlreadyFriend(currentUserId),
                isNotUnderRequest(currentUserId),
                isNotRestricted(currentUserId)
            ).fetch()
    }

    // Email-based (for subquery)
    private fun isNotAlreadyFriendEmail(userEmail: String): BooleanExpression {
        val relationships = QFriendRelationshipsJpaEntity.friendRelationshipsJpaEntity
        return user.email.notIn(
            JPAExpressions
                .select(relationships.friendUser.email)
                .from(relationships)
                .where(
                    relationships.ownerUser.email.eq(userEmail)
                )
        )
    }

    // ID-based (for constant)
    private fun isNotAlreadyFriend(currentUserId: UUID): BooleanExpression {
        val relationships = QFriendRelationshipsJpaEntity.friendRelationshipsJpaEntity
        return user.id.notIn(
            JPAExpressions.select(relationships.friendUser.id)
                .from(relationships)
                .where(relationships.ownerUser.id.eq(currentUserId))
        )
    }

    // Email-based (for subquery)
    private fun isNotUnderRequestEmail(userEmail: String): BooleanExpression {
        val requests = QFriendRequestJpaEntity.friendRequestJpaEntity
        return user.email.notIn(
            JPAExpressions.select(requests.receiver.email).from(requests)
                .where(requests.requester.email.eq(userEmail))
        ).and(
            user.email.notIn(
                JPAExpressions.select(requests.requester.email).from(requests)
                    .where(requests.receiver.email.eq(userEmail))
            )
        )
    }

    // ID-based (for constant)
    private fun isNotUnderRequest(currentUserId: UUID): BooleanExpression {
        val requests = QFriendRequestJpaEntity.friendRequestJpaEntity
        return user.id.notIn(
            JPAExpressions.select(requests.receiver.id).from(requests).where(requests.requester.id.eq(currentUserId))
        ).and(
            user.id.notIn(
                JPAExpressions.select(requests.requester.id).from(requests)
                    .where(requests.receiver.id.eq(currentUserId))
            )
        )
    }

    // Email-based (for subquery)
    private fun isNotRestrictedEmail(userEmail: String): BooleanExpression {
        val restrictions = QFriendRestrictionJpaEntity.friendRestrictionJpaEntity
        return user.email.notIn(
            JPAExpressions.select(restrictions.target.email).from(restrictions)
                .where(restrictions.actor.email.eq(userEmail))
        ).and(
            user.email.notIn(
                JPAExpressions.select(restrictions.actor.email).from(restrictions)
                    .where(restrictions.target.email.eq(userEmail))
            )
        )
    }

    // ID-based (for constant)
    private fun isNotRestricted(currentUserId: UUID): BooleanExpression {
        val restrictions = QFriendRestrictionJpaEntity.friendRestrictionJpaEntity
        return user.id.notIn(
            JPAExpressions.select(restrictions.target.id).from(restrictions)
                .where(restrictions.actor.id.eq(currentUserId))
        ).and(
            user.id.notIn(
                JPAExpressions.select(restrictions.actor.id).from(restrictions)
                    .where(restrictions.target.id.eq(currentUserId))
            )
        )
    }

    private fun isIdMatching(id: UUID): BooleanExpression = user.id.eq(id)

    private fun isEmailMatching(keyword: String): BooleanExpression = user.email.eq(keyword)

    private fun isNicknameMatching(keyword: String): BooleanExpression = user.nickname.eq(keyword)

    private fun isActive(): BooleanExpression = user.status.eq(UserStatus.ACTIVE)

}s.ACTIVE)

}

Test Logic

@SpringBootTest
@Transactional
class PerformanceComparisonTest {

    @Autowired
    lateinit var userRepository: SpringDataUserRepository

    @Autowired
    lateinit var userRepositoryImpl: SpringQueryDSLUserRepository

    private lateinit var targetUserEmail: String
    private lateinit var targetUserId: UUID

    @BeforeEach
    fun setUp() {
        val me = userRepository.save(
            UserJpaEntity(
                "me@test.com", "나", UserRole.NORMAL,
                OAuth2Provider.KAKAO, UserStatus.ACTIVE
            )
        )
        targetUserEmail = me.email
        targetUserId = me.id!!

        (1..100_000).forEach { i ->
            userRepository.save(
                UserJpaEntity(
                    "user$i@test.com",
                    "친구$i",
                    UserRole.NORMAL,
                    OAuth2Provider.KAKAO,
                    UserStatus.ACTIVE
                )
            )
        }
    }

    @Test
    @DisplayName("Email 기반 vs ID 기반 검색 성능 비교")
    fun comparePerformance() {
        // given
        val keyword = "친구"
        val stopWatch = org.springframework.util.StopWatch()

        // when
        stopWatch.start("Email Based (Subquery)")
        val result1 = userRepositoryImpl.searchByEmail(targetUserEmail, keyword)
        stopWatch.stop()

        stopWatch.start("ID Based (Constant)")
        val currentUserId = userRepository.findByEmail(targetUserEmail)?.id!!
        val result2 = userRepositoryImpl.searchById(currentUserId, keyword)
        stopWatch.stop()

        println(stopWatch.prettyPrint())

        // then
        assertThat(result1.size).isEqualTo(result2.size)

        val emailBasedTime = stopWatch.taskInfo[0].timeMillis
        val idBasedTime = stopWatch.taskInfo[1].timeMillis

        println("Email Based: ${emailBasedTime}ms")
        println("ID Based: ${idBasedTime}ms")

        assertThat(idBasedTime).isLessThanOrEqualTo(emailBasedTime)
    }
  }
}

Test Result

================================================================================
[Query 1] Email-Based Search (took 130ms)
================================================================================

2026-02-13T21:58:59.157+09:00  INFO 53924 --- [IMHERE-USER-SERVICE] [    Test worker] p6spy
#1770987539157 | took 130ms | statement | connection 4| url jdbc:h2:mem:1cea8f7b-11ce-42b1-ab96-e9c9bde72501

-- Parameterized Query:
select uje1_0.id, uje1_0.created_at, uje1_0.email, uje1_0.nickname, 
       uje1_0.provider, uje1_0.role, uje1_0.status, uje1_0.updated_at 
from users uje1_0 
where (uje1_0.nickname=? or uje1_0.email=?) 
  and uje1_0.status=? 
  and uje1_0.email<>? 
  and uje1_0.email not in (
    select fu1_0.email 
    from friend_relationships frje1_0 
    join users fu1_0 on fu1_0.id=frje1_0.friend_user_id 
    join users ou1_0 on ou1_0.id=frje1_0.owner_user_id 
    where ou1_0.email=?
  ) 
  and (uje1_0.email not in (
    select r1_0.email 
    from friend_request frje2_0 
    join users r1_0 on r1_0.id=frje2_0.receiver_id 
    join users r2_0 on r2_0.id=frje2_0.requester_id 
    where r2_0.email=?
  ) and uje1_0.email not in (
    select r3_0.email 
    from friend_request frje3_0 
    join users r3_0 on r3_0.id=frje3_0.requester_id 
    join users r4_0 on r4_0.id=frje3_0.receiver_id 
    where r4_0.email=?
  )) 
  and (uje1_0.email not in (
    select t1_0.email 
    from friend_restrictions frje4_0 
    join users t1_0 on t1_0.id=frje4_0.target_id 
    join users a1_0 on a1_0.id=frje4_0.actor_id 
    where a1_0.email=?
  ) and uje1_0.email not in (
    select a2_0.email 
    from friend_restrictions frje5_0 
    join users a2_0 on a2_0.id=frje5_0.actor_id 
    join users t2_0 on t2_0.id=frje5_0.target_id 
    where t2_0.email=?
  ))

-- Actual Values:
select uje1_0.id, uje1_0.created_at, uje1_0.email, uje1_0.nickname, 
       uje1_0.provider, uje1_0.role, uje1_0.status, uje1_0.updated_at 
from users uje1_0 
where (uje1_0.nickname='친구' or uje1_0.email='친구') 
  and uje1_0.status='ACTIVE' 
  and uje1_0.email<>'me@test.com' 
  and uje1_0.email not in (
    select fu1_0.email 
    from friend_relationships frje1_0 
    join users fu1_0 on fu1_0.id=frje1_0.friend_user_id 
    join users ou1_0 on ou1_0.id=frje1_0.owner_user_id 
    where ou1_0.email='me@test.com'
  ) 
  and (uje1_0.email not in (
    select r1_0.email 
    from friend_request frje2_0 
    join users r1_0 on r1_0.id=frje2_0.receiver_id 
    join users r2_0 on r2_0.id=frje2_0.requester_id 
    where r2_0.email='me@test.com'
  ) and uje1_0.email not in (
    select r3_0.email 
    from friend_request frje3_0 
    join users r3_0 on r3_0.id=frje3_0.requester_id 
    join users r4_0 on r4_0.id=frje3_0.receiver_id 
    where r4_0.email='me@test.com'
  )) 
  and (uje1_0.email not in (
    select t1_0.email 
    from friend_restrictions frje4_0 
    join users t1_0 on t1_0.id=frje4_0.target_id 
    join users a1_0 on a1_0.id=frje4_0.actor_id 
    where a1_0.email='me@test.com'
  ) and uje1_0.email not in (
    select a2_0.email 
    from friend_restrictions frje5_0 
    join users a2_0 on a2_0.id=frje5_0.actor_id 
    join users t2_0 on t2_0.id=frje5_0.target_id 
    where t2_0.email='me@test.com'
  ))

================================================================================
[Query 2] User Lookup (took 0ms)
================================================================================

2026-02-13T21:58:59.280+09:00  INFO 53924 --- [IMHERE-USER-SERVICE] [    Test worker] p6spy
#1770987539280 | took 0ms | statement | connection 4| url jdbc:h2:mem:1cea8f7b-11ce-42b1-ab96-e9c9bde72501

-- Parameterized Query:
select uje1_0.id, uje1_0.created_at, uje1_0.email, uje1_0.nickname, 
       uje1_0.provider, uje1_0.role, uje1_0.status, uje1_0.updated_at 
from users uje1_0 
where uje1_0.email=?

-- Actual Values:
select uje1_0.id, uje1_0.created_at, uje1_0.email, uje1_0.nickname, 
       uje1_0.provider, uje1_0.role, uje1_0.status, uje1_0.updated_at 
from users uje1_0 
where uje1_0.email='me@test.com'

================================================================================
[Query 3] ID-Based Search (took 38ms)
================================================================================

2026-02-13T21:58:59.390+09:00  INFO 53924 --- [IMHERE-USER-SERVICE] [    Test worker] p6spy
#1770987539390 | took 38ms | statement | connection 4| url jdbc:h2:mem:1cea8f7b-11ce-42b1-ab96-e9c9bde72501

-- Parameterized Query:
select uje1_0.id, uje1_0.created_at, uje1_0.email, uje1_0.nickname, 
       uje1_0.provider, uje1_0.role, uje1_0.status, uje1_0.updated_at 
from users uje1_0 
where (uje1_0.nickname=? or uje1_0.email=?) 
  and uje1_0.status=? 
  and uje1_0.id<>? 
  and uje1_0.id not in (
    select frje1_0.friend_user_id 
    from friend_relationships frje1_0 
    where frje1_0.owner_user_id=?
  ) 
  and (uje1_0.id not in (
    select frje2_0.receiver_id 
    from friend_request frje2_0 
    where frje2_0.requester_id=?
  ) and uje1_0.id not in (
    select frje3_0.requester_id 
    from friend_request frje3_0 
    where frje3_0.receiver_id=?
  )) 
  and (uje1_0.id not in (
    select frje4_0.target_id 
    from friend_restrictions frje4_0 
    where frje4_0.actor_id=?
  ) and uje1_0.id not in (
    select frje5_0.actor_id 
    from friend_restrictions frje5_0 
    where frje5_0.target_id=?
  ))

-- Actual Values:
select uje1_0.id, uje1_0.created_at, uje1_0.email, uje1_0.nickname, 
       uje1_0.provider, uje1_0.role, uje1_0.status, uje1_0.updated_at 
from users uje1_0 
where (uje1_0.nickname='친구' or uje1_0.email='친구') 
  and uje1_0.status='ACTIVE' 
  and uje1_0.id<>'abdfed91-cadb-480d-b2c1-7b592f57de1a' 
  and uje1_0.id not in (
    select frje1_0.friend_user_id 
    from friend_relationships frje1_0 
    where frje1_0.owner_user_id='abdfed91-cadb-480d-b2c1-7b592f57de1a'
  ) 
  and (uje1_0.id not in (
    select frje2_0.receiver_id 
    from friend_request frje2_0 
    where frje2_0.requester_id='abdfed91-cadb-480d-b2c1-7b592f57de1a'
  ) and uje1_0.id not in (
    select frje3_0.requester_id 
    from friend_request frje3_0 
    where frje3_0.receiver_id='abdfed91-cadb-480d-b2c1-7b592f57de1a'
  )) 
  and (uje1_0.id not in (
    select frje4_0.target_id 
    from friend_restrictions frje4_0 
    where frje4_0.actor_id='abdfed91-cadb-480d-b2c1-7b592f57de1a'
  ) and uje1_0.id not in (
    select frje5_0.actor_id 
    from friend_restrictions frje5_0 
    where frje5_0.target_id='abdfed91-cadb-480d-b2c1-7b592f57de1a'
  ))

================================================================================
Performance Results
================================================================================

StopWatch '': 9.4650058 seconds
----------------------------------------
Seconds       %       Task name
----------------------------------------
9.2751745     98%     Email Based (Subquery)
0.1898313     02%     ID Based (Constant)

Email Based: 9275ms
ID Based: 189ms

Summary

Email-based query
- 9,275ms (98% of total time)
- Uses subqueries with multiple JOIN operations on the users table, resulting in nested loop joins
ID-based query
- 189ms (2% of total time)
- Uses direct ID constants in subqueries, eliminating unnecessary table joins
Root cause
- The email-based approach requires email information to compare entities, which causes multiple joins to resolve email-to-ID mappings. Additionally, each subquery operates independently without sharing memory or intermediate results.
- But ID-based approach don’t have to multiple join to resolve email.

To understand this case, I have to be reminded about database.

Database

Required Knowledge 1: How Database Engines Find Targets

Index Seek

Databases jump immediately using indexes. We call this index seek.

Then, how?

B-Tree Architecture

erDiagram
    INTERNAL_PAGE ||--o{ LEAF_PAGE_P00 : "Seek Path"
    INTERNAL_PAGE ||--o{ LEAF_PAGE_P01 : "Seek Path"
    INTERNAL_PAGE ||--o{ LEAF_PAGE_P02 : "Seek Path"
    INTERNAL_PAGE ||--o{ LEAF_PAGE_P10 : "Seek Path"
    INTERNAL_PAGE ||--o{ LEAF_PAGE_P11 : "Seek Path"

    %% Horizontal Scan Path (Linked List)
0    LEAF_PAGE_P00 ||--|| LEAF_PAGE_P1 : "Next"
    LEAF_PAGE_P01 ||--|| LEAF_PAGE_P02 : "Next"
    LEAF_PAGE_P02 ||--|| LEAF_PAGE_P10 : "Next"
    LEAF_PAGE_P10 ||--|| LEAF_PAGE_P11 : "Next"

    LEAF_PAGE_P00 {
        string keys "1 ~ 100"
        pointer_to_data row_1_to_100 "RID/PK"
    }
    LEAF_PAGE_P01 {
        string keys "101 ~ 200"
        pointer_to_data row_101_to_200 "RID/PK"
    }
    LEAF_PAGE_P02 {
        string keys "201 ~ 500"
        pointer_to_data row_201_to_500 "RID/PK"
    }
    LEAF_PAGE_P10 {
        string keys "501 ~ 700"
        pointer_to_data row_501_to_700 "RID/PK"
    }
    LEAF_PAGE_P11 {
        string keys "701 ~ 1000"
        pointer_to_data row_701_to_1000 "RID/PK"
    }

    %% Data Mapping
    LEAF_PAGE_P11 ||--o{ USERS_TABLE : "Fetch actual data"
    USERS_TABLE {
        UUID user_id PK
        string email
        string nickname
    }

Key Characteristics of B-Tree Structure

Root Node: The topmost node that manages the entire key range
Branch Nodes: Intermediate nodes that further partition the key space into smaller ranges
Leaf Nodes: Bottom-level nodes containing actual data pointers (RIDs or primary keys), linked sequentially for efficient range scans
Balanced Tree Property: All leaf nodes are at the same depth, guaranteeing predictable O(log n) search performance

Index Seek Example: Query execution for WHERE id = 150

Start at Root Node → Compare key: "150 falls within range 1~500"
Traverse to Branch1 → Narrow down: "150 falls within range 101~200"
Reach Leaf2 → Retrieve data pointer for key 150
Total of 3 node accesses to locate the target record among tens of thousands of rows

Index Scan

When the database cannot use Index Seek, it falls back to Index Scan.

Index Scan Example: Query execution for WHERE status = 'ACTIVE'

Start at the leftmost Leaf Node (beginning of the linked list)
Read through each leaf node sequentially, checking every entry's status value
Continue traversing via "Next" pointers until reaching the end
Result: All leaf nodes are read, though still faster than a full table scan since index pages are smaller and sequential

Key Differences: Seek vs Scan

Aspect	Index Seek	Index Scan
Access Pattern	Direct jump via B-Tree navigation	Sequential read through leaf nodes
Pages Read	3-4 nodes (Root → Branch → Leaf)	All leaf nodes in range
Performance	O(log n)	O(n)
When Used	Equality/range on indexed columns	Non-selective filters, missing WHERE clause

Required Knowledge 2: How Database Engines Deal with JOIN Commands

Database Engine (i.e., Optimizer) normally uses 3 algorithms when performing JOIN operations. These are Nested Loop Join, Hash Join, and Sort Merge Join.

1. Inner And Outer Tables

Above all, it's crucial to understand the concepts of inner and outer tables. However, we don't necessarily need to dictate their roles when writing SQL, as the Optimizer determines the most efficient execution plan.

To be efficient, before performing JOIN operations, the Optimizer takes some actions.

STEP 1: Selection of the Outer (Driving) Table

The Optimizer reduces the target dataset size by applying filtering conditions (via WHERE clauses).
The table with the smallest result set after filtering ⇒ Outer (Driving) Table.
Purpose : To minimize the total number of iterations required for subsequent join operations.

STEP 2: Selection of the Inner (Driven) Table

The Optimizer actively prefers designating a table as the Inner (Driven) Table if it has a usable index on the join key.
- ⇒ To be efficient via index seek

STEP 3: Algorithm Selection

The Optimizer normally considers 4 elements to select algorithm between Nested Loop Join Hash Join Sort Merge Join.

Cardinality & Selectivity: Estimating the number of rows after filtering to decide the join order.
Index Presence: Checking if an Index Seek is possible for the driven table.
System Resources: Evaluating the available memory for Hash Table creation or Sorting operations.
Cost Aggregation: Calculating the sum of Disk I/O and CPU cycles to find the path with the minimum "Total Cost."

2. Nested Loop Join

When
- Cardinality & Selectivity: The outer table has a small result set after filtering (low cardinality), minimizing the number of iterations.
- Index Presence: The inner table has an index on the join key, enabling fast index seeks for each outer row.
- System Resources: Limited memory available; no need to build large hash tables or sort datasets.
- Cost Aggregation
  
  $$
  \text{Total Cost} = \sum_{i=1}^{n_{\text{outer}}} \left( C_{\text{seek}} + C_{\text{cpu}} \right)
  $$
  
  $$
  \text{where } C_{\text{seek}} = \log_b(N_{\text{inner}}) \text{ (B-Tree depth)}
  $$
  
  $$
  \text{Efficient when: } n_{\text{outer}} \times \log(N_{\text{inner}}) < \text{cost}{\text{hash}} + \text{cost}{\text{sort}}
  $$

Mechanism

Time Complexity: O(n_outer × log(n_inner)) - Number of outer rows × B-Tree search cost

It must use index seek

// Outer Table (Driving Table)
for each row_outer in outer_table:

  // Inner Table (Driven Table) - Index Seek 수행
  matching_rows = index_seek(inner_table, join_key = row_outer.key)

  for each row_inner in matching_rows:
      // 조인 조건이 만족하면 결과에 추가
      if join_condition(row_outer, row_inner):
          result.add(merge(row_outer, row_inner))

3. Hash Join

When
- Cardinality & Selectivity: Both tables are large, and neither can be significantly reduced through filtering.
- Index Presence: No suitable index exists on the join key, or using the index would be less efficient than sequential scans.
- System Resources: Sufficient memory is available to build a hash table from the smaller table (or partition).
- Cost Aggregation
  
  $$
  \text{Total Cost} = C_{\text{build}} + C_{\text{probe}}
  $$
  
  $$
  \text{where } C_{\text{build}} = n_{\text{smaller}} \text{ (sequential scan)}
  $$
  
  $$
  \text{and } C_{\text{probe}} = n_{\text{larger}} \times O(1) \text{ (hash lookup)}
  $$
  
  $$
  \text{Efficient when: } n_{\text{smaller}} + n_{\text{larger}} < \text{cost}{\text{nested}} + \text{cost}{\text{sort}}
  $$

Mechanism

Time Complexity: O(n_smaller + n_larger) - Linear scan with hash lookups

No index required; uses sequential I/O

// Phase 1: Build Hash Table from Smaller Table
hash_table = {}
for each row in smaller_table:
  key = row.join_key
  hash_table[key] = row  // O(1) insertion

// Phase 2: Probe Hash Table with Larger Table
for each row_outer in larger_table:
  key = row_outer.join_key

  // Hash lookup - O(1) average case
  if key in hash_table:
      row_inner = hash_table[key]
      if join_condition(row_outer, row_inner):
          result.add(merge(row_outer, row_inner))

4. Sort Merge Join

When
- Cardinality & Selectivity: Both tables are large, but hash join would require too much memory.
- Index Presence: Data is already sorted (e.g., via clustered index), or the join condition involves range comparisons rather than equality.
- System Resources: Insufficient memory for hash tables, but disk space is available for sort operations.
- Cost Aggregation
  
  $$
  \text{Total Cost} = C_{\text{sort1}} + C_{\text{sort2}} + C_{\text{merge}}
  $$
  
  $$
  \text{where } C_{\text{sort}} = n \log(n) \text{ (if not pre-sorted)}
  $$
  
  $$
  \text{and } C_{\text{merge}} = n_{\text{table1}} + n_{\text{table2}} \text{ (linear scan)}
  $$
  
  $$
  \text{Efficient when: } 2n\log(n) + (n_1 + n_2) < \text{cost}{\text{nested}} + \text{cost}{\text{hash}}
  $$

Mechanism

Time Complexity: O(n log n + m log m) - Sorting both tables, then O(n + m) for merge

Pre-sorted data (via index) eliminates sorting cost

// Phase 1: Sort Both Tables (if not already sorted via index)
sorted_table1 = sort(table1, join_key)  // O(n log n)
sorted_table2 = sort(table2, join_key)  // O(m log m)

// Phase 2: Merge Sorted Tables
pointer1 = 0
pointer2 = 0

while pointer1 &lt; len(sorted_table1) and pointer2 &lt; len(sorted_table2):
  row1 = sorted_table1[pointer1]
  row2 = sorted_table2[pointer2]

  if row1.join_key == row2.join_key:
      // Match found
      if join_condition(row1, row2):
          result.add(merge(row1, row2))
      pointer1++
      pointer2++
  else if row1.join_key &lt; row2.join_key:
      pointer1++  // Advance smaller key
  else:
      pointer2++  // Advance smaller key

Reason of Gemini3’s Advice

Entity Relationship Diagram

It is my service’s ERD.

erDiagram
    USERS {
        UUID user_id PK "사용자 id"
        VARCHAR(255) email "이메일"
        VARCHAR(255) nickname "닉네임"
        ENUM role "역할"
        ENUM provider "OAuth2 제공자"
        ENUM status "상태(PENDING, ACTIVE)"
        TIMESTAMP created_at "가입일"
        TIMESTAMP updated_at "마지막 업데이트"
    }

    FRIEND_REQUESTS {
        BIGINT id PK "친구 요청 id"
        UUID requester_id FK "신청자 UUID"
        UUID receiver_id FK "수신자 UUID"
        VARCHAR(255) message "요청 메시지"
        TIMESTAMP created_at "신청 일자"
    }

    FRIEND_RELATIONSHIPS {
        BIGINT id PK "확정 관계 id"
        UUID owner_user_id FK "기준 사용자 UUID"
        UUID friend_user_id FK "친구 UUID"
        VARCHAR(255) friend_alias "내가 설정한 친구 이름"
        TIMESTAMP created_at "친구 관계 수립 일시"
    }

    FRIEND_RESTRICTIONS {
        BIGINT id PK "거절/차단 id"
        UUID actor_id FK "차단/거절을 수행한 사용자"
        UUID target_id FK "차단/거절 대상 UUID"
        ENUM type "타입(BLOCK, REJECT)"
        TIMESTAMP created_at "차단/거절 시점"
    }

    USERS ||--o{ FRIEND_REQUESTS : "requests(sent)"
    USERS ||--o{ FRIEND_REQUESTS : "requests(received)"
    USERS ||--o{ FRIEND_RELATIONSHIPS : "friends(owner)"
    USERS ||--o{ FRIEND_RELATIONSHIPS : "friends(friend)"
    USERS ||--o{ FRIEND_RESTRICTIONS : "restrictions(actor)"
    USERS ||--o{ FRIEND_RESTRICTIONS : "restrictions(target)"

In this structure, I needed to find users who could become friends based on the current user's email and the target user's email or nickname.

The conditions for users who could become friends were set as follows:

Exclude self
No pending friend requests
Not currently friends
No blocks or rejections

Email based Query’s Problem

select uje1_0.id, uje1_0.created_at, uje1_0.email, uje1_0.nickname, 
       uje1_0.provider, uje1_0.role, uje1_0.status, uje1_0.updated_at 
from users uje1_0 
where (uje1_0.nickname='친구' or uje1_0.email='친구') 
  and uje1_0.status='ACTIVE' 
  and uje1_0.email<>'me@test.com' 
  and uje1_0.email not in (
    select fu1_0.email 
    from friend_relationships frje1_0 
    join users fu1_0 on fu1_0.id=frje1_0.friend_user_id 
    join users ou1_0 on ou1_0.id=frje1_0.owner_user_id 
    where ou1_0.email='me@test.com'
  ) 
  and (uje1_0.email not in (
    select r1_0.email 
    from friend_request frje2_0 
    join users r1_0 on r1_0.id=frje2_0.receiver_id 
    join users r2_0 on r2_0.id=frje2_0.requester_id 
    where r2_0.email='me@test.com'
  ) and uje1_0.email not in (
    select r3_0.email 
    from friend_request frje3_0 
    join users r3_0 on r3_0.id=frje3_0.requester_id 
    join users r4_0 on r4_0.id=frje3_0.receiver_id 
    where r4_0.email='me@test.com'
  )) 
  and (uje1_0.email not in (
    select t1_0.email 
    from friend_restrictions frje4_0 
    join users t1_0 on t1_0.id=frje4_0.target_id 
    join users a1_0 on a1_0.id=frje4_0.actor_id 
    where a1_0.email='me@test.com'
  ) and uje1_0.email not in (
    select a2_0.email 
    from friend_restrictions frje5_0 
    join users a2_0 on a2_0.id=frje5_0.actor_id 
    join users t2_0 on t2_0.id=frje5_0.target_id 
    where t2_0.email='me@test.com'
  )
)

1. Cannot Use Index Seek

It maybe use index scan or full table scan. Not Index Seek . Because of email is not a ID.

2. Requires 6 Additional JOINs to Resolve Email Values

The email-based query creates 6 times implicit join pattern to resolve email addresses in subqueries.
HOWEVER, The ID-based approach eliminates these 6 JOINs entirely by using direct UUID comparisons like WHERE owner_user_id = {constant UUID}
- The Optimizer can pre-compute and cache subquery results(reduce from WHERE clause, before JOIN operation.)

Jackson 3 변경으로 인한 Redis 역직렬화 장애 분석

rati — Thu, 19 Mar 2026 23:03:13 +0900

ImHere 프로젝트는 로그인 및 회원가입 과정에서 카카오의 OIDC(OpenID Connect)를 활용하고 있습니다.

카카오 공식 문서에서는 OIDC 서명 검증에 필요한 공개 키를 매 요청마다 조회하는 대신, 일정 시간 캐싱하여 사용할 것을 권장하고 있습니다.

이에 따라 본 프로젝트에서는 카카오 공개키를 캐싱하여 사용하고 있으며, 추가로 자체적으로 사용하는 refresh-token 역시 데이터베이스가 아닌 캐시 기반으로 관리하도록 설계하였습니다.

해당 프로젝트는 기존 MVP 형태로 배포했던 서비스를 리팩토링하여 재운영할 계획이기 때문에, 확장성과 성능을 고려하여 캐시 저장소로 Redis를 채택하였습니다.

배경

이 프로젝트는 단순한 서비스 구현을 넘어 학습 목적도 함께 가지고 있습니다.

이에 따라 최신 기술 스택 경험을 위해 Spring Boot 4로의 마이그레이션을 진행하였습니다.

Spring Boot 4는 여러 주요 변경 사항을 포함하고 있으며, 그중 하나가 Jackson 라이브러리의 2.x → 3.x 업그레이드입니다.

Jackson 2.x는 과거 Remote Code Execution(RCE) 취약점 이슈가 있었으며, 이를 완화하기 위해 PolymorphicTypeValidator가 도입되었습니다. 또한 ObjectMapper.DefaultTyping.EVERYTHING 옵션은 보안 문제로 인해 deprecated 처리되었고, 이후 Jackson 3에서 완전히 제거되었습니다.

DefaultTyping.EVERYTHING 삭제 결정 Github Issu

All @Deprecated (as of 2.20) methods, fields and classes are removed from 3.0

Javadocs in Jackson 2.20 updated to indicate replacements where available (incomplete: PRs welcome for more!)

문제 상황

카카오 공개키를 Redis에 캐싱하는 과정에서, 다음과 같은 구조를 사용하고 있습니다.

@Component
class KakaoOauthClient(
    restClientBuilder: RestClient.Builder
) : OauthClientPort {

    companion object {
        private val log = LoggerFactory.getLogger(KakaoOauthClient::class.java)
        const val KAKAO_BASE_URL = "<https://kauth.kakao.com>"
        const val KEY_REQ_URL = "/.well-known/jwks.json"
    }

    private val restClient: RestClient = restClientBuilder
        .baseUrl(KAKAO_BASE_URL)
        .build()

    @Cacheable(value = ["kakaoOidcKeys"], cacheManager = "oidcCacheManager", key = "'kakaoPublicKeySet'")
    override fun getPublicKeyFromProvider(): OIDCPublicKeyResponse? {
        return fetchPublicKey()
    }

    private fun fetchPublicKey(): OIDCPublicKeyResponse? {
        return restClient.get()
            .uri(KEY_REQ_URL)
            .retrieve()
            .body()
    }
}

공개키를 받은 즉시 OIDCPublicKeyResponse 로 매핑하는데, OIDCPublicKeyResponse 는 Kotlin의 data class로 정의되어 있습니다.

data class OIDCPublicKeyResponse(
    val keys: List<OIDCPublicKey> = emptyList()
)

문제는 캐시 조회 시점에서 발생했습니다.

org.springframework.data.redis.serializer.SerializationException: Could not read JSON:Could not resolve subtype of [simple type, class java.lang.Object]: missing type id property '@class'
 
 at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); byte offset: #467] 
	at org.springframework.data.redis.serializer.GenericJacksonJsonRedisSerializer.deserialize(GenericJacksonJsonRedisSerializer.java:212) ~[spring-data-redis-4.0.3.jar:4.0.3]
	at org.springframework.data.redis.serializer.GenericJacksonJsonRedisSerializer.deserialize(GenericJacksonJsonRedisSerializer.java:182) ~[spring-data-redis-4.0.3.jar:4.0.3]
	at org.springframework.data.redis.core.AbstractOperations.deserializeValue(AbstractOperations.java:427) ~[spring-data-redis-4.0.3.jar:4.0.3]
	at org.springframework.data.redis.core.AbstractOperations$ValueDeserializingRedisCallback.doInRedis(AbstractOperations.java:67) ~[spring-data-redis-4.0.3.jar:4.0.3]
	at org.springframework.data.redis.core.RedisTemplate.execute(RedisTemplate.java:414) ~[spring-data-redis-4.0.3.jar:4.0.3]
	at org.springframework.data.redis.core.RedisTemplate.execute(RedisTemplate.java:381) ~[spring-data-redis-4.0.3.jar:4.0.3]
	at org.springframework.data.redis.core.AbstractOperations.execute(AbstractOperations.java:166) ~[spring-data-redis-4.0.3.jar:4.0.3]
	at org.springframework.data.redis.core.DefaultValueOperations.get(DefaultValueOperations.java:51) ~[spring-data-redis-4.0.3.jar:4.0.3]

{생략}

Caused by: tools.jackson.databind.exc.InvalidTypeIdException: Could not resolve subtype of [simple type, class java.lang.Object]: missing type id property '@class'
 
 at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); byte offset: #467]
	at tools.jackson.databind.exc.InvalidTypeIdException.from(InvalidTypeIdException.java:41) ~[jackson-databind-3.0.4.jar:3.0.4]
	at tools.jackson.databind.DeserializationContext.missingTypeIdException(DeserializationContext.java:2105) ~[jackson-databind-3.0.4.jar:3.0.4]
	at tools.jackson.databind.DeserializationContext.handleMissingTypeId(DeserializationContext.java:1690) ~[jackson-databind-3.0.4.jar:3.0.4]
	at tools.jackson.databind.jsontype.impl.TypeDeserializerBase._handleMissingTypeId(TypeDeserializerBase.java:285) ~[jackson-databind-3.0.4.jar:3.0.4]
	at tools.jackson.databind.jsontype.impl.AsPropertyTypeDeserializer._deserializeTypedUsingDefaultImpl(AsPropertyTypeDeserializer.java:173) ~[jackson-databind-3.0.4.jar:3.0.4]
	at tools.jackson.databind.jsontype.impl.AsPropertyTypeDeserializer.deserializeTypedFromObject(AsPropertyTypeDeserializer.java:112) ~[jackson-databind-3.0.4.jar:3.0.4]
	at tools.jackson.databind.jsontype.impl.AsPropertyTypeDeserializer.deserializeTypedFromAny(AsPropertyTypeDeserializer.java:203) ~[jackson-databind-3.0.4.jar:3.0.4]
	at tools.jackson.databind.deser.jdk.UntypedObjectDeserializerNR.deserializeWithType(UntypedObjectDeserializerNR.java:98) ~[jackson-databind-3.0.4.jar:3.0.4]

문제 원인

Jackson은 내부적으로 DefaultTypeResolverBuilder를 사용하여 직렬화 및 역직렬화 시 타입 정보를 포함할지 여부를 결정합니다. 이때 핵심적인 판단 기준이 되는 메서드가 useForType이며, 해당 로직에서는 특정 타입에 대해 타입 정보를 포함할지 여부를 판단합니다.

이때 useForType 메서드의 주석을 살펴보면, String, Boolean, Integer와 같은 기본 타입뿐과 아니라 구체적(concrete)이고 final인 클래스는 타입 정보를 포함하지 않는 대상이 됩니다.

Method called to check if the default type handler should be used for given type. Note: "natural types" (String, Boolean, Integer, Double) will never use typing; that is both due to them being concrete and final, and since actual serializers and deserializers will also ignore any attempts to enforce typing.

결과적으로 Redis에는 단순한 JSON 형태의 데이터만 저장되게 되었고, 이를 나중에 다시 역직렬화 하는 과정에서 매핑할 클래스 정보를 알 수 없게 되어서 문제가 발생하게 되었습니다

@Component
class RedisCacheAdapter(
    private val redisTemplate: RedisTemplate<String, String>,
    private val mapper: JsonMapper
) : CachePort {

    override fun save(key: String, data: Any, duration: Duration) {
        val jsonString = mapper.writeValueAsString(data)
        redisTemplate.opsForValue().set(key, jsonString, duration)
    }

    override fun <T> find(key: String): T? {
        val jsonString = redisTemplate.opsForValue().get(key) ?: return null

        return try {
            mapper.readValue(jsonString)
        } catch (e: Exception) {
            null
        }
    }
}

해결

이 문제를 해결하기 위해 애플리케이션 레벨에서 역직렬화 시 클래스 타입을 명시하였습니다.

Redis에는 객체를 JSON 문자열(String) 형태로 저장
⇒ 조회 시에는 명시적으로 타입을 전달하여 역직렬화 수행

이 방식으로 변경함으로써 다음과 같은 효과를 얻을 수 있었습니다.

Jackson 3의 정책 변화에 영향을 받지 않음
타입 정보 누락으로 인한 역직렬화 문제 제거
직렬화 구조가 단순해져 디버깅이 용이해짐

배운 점

Spring이 JSON 변환에 Jackson을 사용하는 것은 알고 있었지만 내부 구조에 대해서는 생각해보거나 공부한 적이 없어서 문제를 해결하는 데 오랜 시간이 걸렸습니다. 특히 Deprecated 예고가 된 기능을 사용했다는 점에서 Spring 내부에서 사용되는 라이브러리에 대한 이해 역시 필요함을 느끼게 되었습니다.