백엔드 분산 락 구현, Redisson만 쓰면 기술면접에서 떨어지는 진짜 이유

by 그릿 | GROWTH_ESSAY | 2026-11-09

백엔드 개발자 포트폴리오의 선착순 쿠폰이나 티켓팅 프로젝트에서 빠지지 않는 문장이 있습니다. "동시성 이슈를 해결하기 위해 Redisson 기반 분산 락을 적용했습니다." 하지만 기술면접에서 "왜 DB 락 대신 분산 락을 썼나요?", "트랜잭션 커밋 전에 락이 풀리면 어떻게 됩니까?"라는 질문을 받으면 대답을 잇지 못합니다.

라이브러리 어노테이션 하나로 동시 요청을 막아본 경험만으로는 백엔드 분산 락을 안다고 할 수 없습니다. 실무에서 분산 락은 만능 열쇠가 아니라, 네트워크 비용과 정합성 위험을 떠안는 무거운 선택이기 때문입니다.

왜 데이터베이스 락이 아니라 분산 락이어야 했는지 설명할 수 있습니까?

200명이 넘는 백엔드 멘티들을 코칭하며 가장 자주 보는 실수가 있습니다. 단일 DB 환경에서 초당 수십 건 트래픽을 다루면서도 무작정 Redis 분산 락부터 도입하는 선택입니다.

비관적 락이나 낙관적 락으로 DB 안에서 정합성을 지킬 수 있는데도 그렇습니다. 분산 락을 쓰면 Redis 외부 인프라를 거쳐야 하고, 네트워크 지연과 커넥션 관리 비용이 발생합니다. 면접관이 듣고 싶은 것은 RLock 객체를 쓰는 문법이 아닙니다. 왜 DB 수준의 해결책으로는 부족했는지, 트래픽 규모와 시스템 구조 관점에서 내린 기술 선택의 이유입니다.

트랜잭션 커밋과 락 해제의 타이밍을 고민해보셨습니까?

Redisson을 적용했다고 적은 프로젝트 코드를 열어보면 치명적인 결함이 자주 보입니다. 스프링의 @Transactional 안에서 락을 획득하고 해제하는 구조입니다.

락이 풀린 직후, 트랜잭션이 아직 DB에 커밋되지 않은 순간이 있습니다. 이때 대기하던 다른 스레드가 락을 얻고 데이터를 읽으면 과거 데이터를 읽어 정합성이 깨집니다. 락 획득과 해제는 반드시 트랜잭션 바깥을 감싸야 합니다. 로직이 길어져 락 점유 시간(leaseTime)이 끝났을 때, 락을 잃은 스레드가 DB를 덮어쓰는 펜싱 토큰(Fencing Token) 문제까지 짚어내야 합니다.

인프라 장애와 단일 장애점 시나리오에 대비했습니까?

분산 락을 도입했다는 말은 Redis라는 새 장애 지점을 시스템에 들여왔다는 뜻입니다. Redis 마스터 노드가 다운되어 슬레이브를 승격시키는 순간, 비동기 복제 특성상 락 데이터가 유실되면 어떻게 대응할 것입니까.

면접관이 분산 락을 묻는 이유는 간단합니다. 예제를 복사해 코드를 돌아가게 만든 사람인지, 기술 도입으로 생겨난 부작용과 한계를 끝까지 책임져본 엔지니어인지 확인하려는 것입니다. 락 획득 코드 몇 줄보다 실패 시나리오를 방어하는 논리가 훨씬 더 무겁습니다.

라이브러리 사용법에 머무르지 않고 시스템의 경계와 트레이드오프를 꿰뚫어 보는 백엔드 엔지니어로 성장하고 싶다면 팀그릿 방향 진단(https://teamgrit.co/direction)에서 기준을 확인해보시기 바랍니다.