락과 트랜잭션 경계 분리: 좌석 예약을 구현하며 배운 실무 패턴

게시 2026/01/24

By woolam

조회 5 분읽는 시간

락과 트랜잭션 경계 분리: 직접 겪어보며 정리한 실무 패턴

이번에 좌석 예약 기능을 구현하면서, 락과 트랜잭션의 경계를 어떻게 잡아야 하는지에 대해 다시 한 번 정리할 기회가 있었다.

처음에는 단순히 @Transactional 메서드 안에서 분산 락을 획득하고 해제하는 방식으로 구현했지만, 코드 리뷰와 구조를 다시 살펴보면서 이 방식이 왜 문제가 되는지, 그리고 실무에서는 어떤 패턴을 쓰는지 이해하게 됐다.

이 글은 그 과정을 정리한 기록이다.

처음 구현은 아래와 같은 형태였다.

겉으로 보기에는 큰 문제가 없어 보였지만, Spring 트랜잭션은 프록시 기반으로 동작한다는 점을 다시 떠올리면서 흐름이 달라 보이기 시작했다.

실제 실행 순서는 다음과 같다.

즉,

이건 내가 의도했던 흐름과는 분명히 달랐다.

트랜잭션이 열리면 DB 커넥션을 점유하고, MVCC 스냅샷을 유지한다.

여기에 락 대기 시간까지 포함되면:

그래서 실무에서는 자주 이런 원칙을 이야기한다.

트랜잭션은 최대한 짧게 유지해야 한다

이 관점에서 보면, 락을 잡기 위해 대기하는 시간을 트랜잭션 안에 포함시키는 건 좋은 선택이 아니었다.

정리해보니 두 개념의 역할이 명확히 달랐다.

책임이 다르니, 코드 구조도 자연스럽게 분리되는 게 맞았다.

[락을 담당하는 계층]
        ↓
[트랜잭션을 담당하는 계층]
        ↓
[도메인 로직]

이 구조는 취향의 문제가 아니라, 실무에서 반복적으로 사용되는 패턴에 가깝다는 걸 알게 됐다.

내가 적용한 구조는 아래와 같다.

Facade / UseCase (분산 락 획득 및 해제)
        ↓
TxService (@Transactional)

이 방식은 예약, 결제, 재고 도메인에서 실제로 많이 쓰이고, 코드 리뷰에서도 의도가 명확하게 드러난다.

어노테이션 기반으로 락을 처리하는 방식도 있다.