실무에서 발생한 데드락을 해결한 방법 및 고민점

이미지 출처 : https://pubul.tistory.com/36

 

 

 

 

백엔드 개발을 하다 보면 성능 개선을 위해 구조를 바꾸는 일이 많습니다. 하지만 성능을 개선하는 과정에서 동시성 문제가 새롭게 발생하는 경우도 있습니다.

이번 글에서는 제가 실제로 겪었던 데드락 문제와 그 해결 과정을 정리해보겠습니다. 단순히 “이렇게 해결했다”가 아니라, 왜 그런 문제가 발생했고 어떤 선택지를 고민했는지까지 포함해 작성했습니다.

 

 

 

1️⃣ 데드락이란 무엇인가?

데드락(Deadlock)은 단순히 “락이 걸려서 멈춘 상태”가 아닙니다.
보다 정확히는 다음과 같은 상태를 의미합니다.

두 개 이상의 작업이 서로가 가진 자원을 기다리면서 영원히 진행할 수 없는 상태

 

이를 조금 더 일반적인 컴퓨터 공학 관점에서 보면 다음과 같습니다.

1. 각 작업(스레드, 프로세스, 트랜잭션)은 자원을 점유한 상태에서
2. 다른 작업이 점유한 자원을 추가로 요청하고
3. 그 요청이 서로 꼬이면서
4. 아무도 자원을 내려놓지 않는 상태

즉, “서로 기다리다가 아무도 끝나지 않는 상태”입니다.

 

이건 DB에만 국한된 문제가 아니라 다음과 같은 모든 영역에서 발생할 수 있습니다.

• 멀티 스레드 환경
• OS 리소스 관리
• 분산 시스템 (락 서비스)
• 데이터베이스 트랜잭션

특히 데이터베이스에서는 Row Lock, Table Lock 같은 개념이 있기 때문에 매우 자주 발생합니다.

 

대부분의 RDBMS (PostgreSQL 포함)는 데드락을 감지하면 “둘 중 하나의 트랜잭션을 강제로 롤백”합니다. 일정 시간 (deadlock_timeout, 기본 1초) 대기 후 트랜잭션들을 검사합니다. PostgreSQL은 ①내부적으로 비용이 더 적은 트랜잭션, ②롤백 비용이 낮은 쪽을 희생자로 선택해서 죽여 문제를 해결합니다.

DB는 데드락을 “해결”하지 않고, 단지 하나를 죽여서 순환대기 상황을 끝낼 뿐입니다.

 

 

2️⃣ 데드락 발생 조건

데드락은 아무 때나 발생하는 것이 아니라, 다음 4가지 조건이 모두 만족될 때 발생합니다.

 

1. 상호 배제 (Mutual Exclusion)

자원은 동시에 하나의 작업만 사용할 수 있음
→ DB에서는 row lock

 

2. 점유 대기 (Hold and Wait)

자원을 가진 상태에서 다른 자원을 기다림

 

3. 비선점 (No Preemption)

자원을 강제로 뺏을 수 없음
→ DB에서는 lock을 강제로 회수하지 않음

 

4. 순환 대기 (Circular Wait)

서로가 서로의 자원을 기다리는 구조

A → B가 가진 자원 기다림
B → A가 가진 자원 기다림

이 4가지 조건이 동시에 만족되면 반드시 데드락이 발생합니다.

 

 

 

3️⃣ 실무에서 발생한 데드락

 

3-1. JSON VIEWER 기반 UPDATE에서 데드락

이번 문제는 성능 개선 과정 이후 발생한 문제였습니다. 기존에는 다음과 같은 구조였습니다.

1. 반복문을 돌면서
2. DB UPDATE를 N번 수행

O(N) 으로 DB I/O 하던 구조를 개선하기 위해 다음과 같이 변경했습니다.

• 데이터를 리스트로 만든 뒤
• JSON VIEWER 형태로 변환
• JOIN을 활용하여 UPDATE를 한 번에 수행

 

 

sno	progress_status	success_count	fail_count
1	NEW	0	1
2	CONFIRM	1	0
3	CANCEL	0	1
4	RETRUN	0	0

 

예시를 위해 위같은 테이블이 있다고 할 때, 매 토픽마다 count 를 증가 시켜주는 update 해줘야 했습니다. progress_status 를 기준으로 update 할 count 들을 리스트에 담아, 이를 JSON VIERER 를 만들어 JOIN 사용해 한번에 UPDATE 하는 방식입니다.

 

O(N) → O(1) 로 개선이 됐지만, 예상치 못한 문제가 발생했습니다.

 

 

 

문제의 핵심은 이것입니다.

 

DB 옵티마이저는 UPDATE 순서를 보장하지 않는다.

DB 내부 실행 엔진의 row 접근 순서는 별개입니다 즉, 우리가 JSON VIEWER를 통해 여러 row를 한 번에 UPDATE하더라도
실제로 DB 내부에서는 다음과 같이 실행될 수 있습니다.

 

• 트랜잭션 A → row 1 → row 2 순서로 잠금
• 트랜잭션 B → row 2 → row 1 순서로 잠금

그 결과는 다음과 같습니다.

1. 트랜잭션 A가 row 1 lock
2. 트랜잭션 B가 row 2 lock
3. A가 row 2를 기다림
4. B가 row 1을 기다림

→ 순환 대기 발생 → 데드락

 

핵심은 “동일한 쿼리”라도 실행 순서가 트랜잭션마다 달라질 수 있다는 점입니다.

 

 

 

3-2. 동일 조건 UPDATE에서도 발생한 데드락

또 다른 케이스도 있었습니다.

특정 조건을 만족하는 데이터를 한 번에 업데이트하는 경우입니다.

예를 들어

• row 1, 2, 3 모두 data_sid = 'abc'
• 이를 한 번에 success로 UPDATE

sno	data_sid	progress_status	result
1	abc	NEW	NULL → success
2	abc	CONFIRM	NULL → success
3	abc	CANCEL	NULL → success

 

UPDATE target_table
SET status = 'success'
WHERE data_sid = 'abc';

 

 

이 경우도 동일하게 문제가 발생합니다.

옵티마이저가 row 접근 순서를 보장하지 않기 때문에

1. 트랜잭션 A → row 1 lock
2. 트랜잭션 B → row 2 lock
3. A → row 2 기다림
4. B → row 1 기다림

→ 동일하게 데드락 발생

 

 

 

4️⃣ 해결 방안 및 고민점

이 문제를 해결하기 위해 여러 가지 방법을 고민했습니다.

 

4-1. 다시 N번 UPDATE (Rollback)

가장 단순한 방법은 원래 방식으로 돌아가는 것입니다.

• 반복문을 통해
• UPDATE N번 수행

하지만 이 방법은 명확한 문제가 있습니다. 저희 서비스는 I/O Bound 서비스였고, DB round-trip time이 지연시간의 가장 큰 원인입니다. 따라서 DB I/O 를 최소화 하는 것이 서비스 품질에 중요한 역할을 합니다.

 

 

문제 해결을 위해 성능 개선을 위해 만든 구조를 다시 되돌리는 것은 근본적인 해결이 아니라고 생각했습니다.

그래서 제외했습니다.

 

 

4-2. SELECT → VIEW → JOIN UPDATE

다음으로 생각한 방법은 다음과 같습니다.

1. 먼저 SELECT로 데이터를 가져오고
2. 정렬된 VIEW를 만든 뒤
3. 그 VIEW를 기반으로 UPDATE 수행

이 접근의 핵심은 이것입니다.

 

“UPDATE 대상의 순서를 애플리케이션에서 통제”

 

하지만 이 방법에는 문제가 있습니다.

• 불필요한 JOIN 증가
• 쿼리 복잡도 증가
• 실행 계획이 더 비싸질 가능성

그리고 가장 중요한 부분 DB가 ORDER BY 된 SELECT VIEWER 를 통해 UPDATE 한다고 해도 순서를 100% 보장한다고 확신하기 어려다는 점입니다. 결국 문제점이 해결 되지 않습니다.

 

SELECT *** FOR UPDATE 로 ROW LOCK 을 걸고, 이를 애플리케이션 레벨에서 순서대로 UPDATE 하여 한 트랜잭션 내에 질의 하는 것은 문제를 해결할 수 있는 방안이 됩니다.

하지만 ROW LOCK 을 잡고 너무 오래 있는 점과, 사내 ORM 에서 이를 저런 방식으로 해결할 수 있는 기능이 제공되지 않는다는 점이 있습니다.

 

 

그래서 이 방법도 확실한 해결책으로 보지 않았습니다.

 

 

4-3. UPDATE 순서를 강제하는 방식 (최종 해결)

결국 문제의 본질은 하나였습니다.

“UPDATE 순서만 보장되면 데드락은 발생하지 않는다”

 

그래서 접근을 완전히 바꿨습니다. 사내에선 ESQL이라는 ORM을 사용하고 있었고, 여기에는 AFTER라는 기능이 있었습니다. 한 SELECT , UPDATE 등 구문 뒤에 바로 다음 구문을 실행할 수 있는 방안입니다.

 

이 기능을 활용하면

• 여러 UPDATE를
• 순차적으로 실행되도록 체이닝 가능

즉, 다음과 같은 구조를 만들 수 있었습니다.

UPDATE QUERY
.after(UPDATE QUERY)
.after(UPDATE QUERY)
.after(UPDATE QUERY)

 

이를 실제 SQL 형태로 보면 아래와 같습니다.

BEGIN
UPDATE1
UPDATE2
UPDATE3
UPDATE4
UPDATE5
UPDATE6
COMMIT

이 구조의 핵심은 다음입니다.

• 하나의 트랜잭션
• 하나의 DB round-trip
• 하지만 내부적으로는 순차 실행

즉, O(1) I/O를 유지하면서 UPDATE 순서를 완전히 통제할 수 있었습니다. 

UPDATE 구문을 AFTER 로 묶기 위해 비즈니스 코드 레벨에서 약간의 로직이 조금 추가 되어야 했지만, 가장 합리적이란 생각했습니다. AFTER 로 체이닝 해야할 UPDATE QUERY 가 몇 십개가 아닌 5개로 고정되어 있기 때문입니다.

 

 

 

 

5️⃣ 결과 및 배운점

이 방식으로 변경한 이후 아래과 같은 성과를 이뤄냈습니다.

• 데드락 완전 제거
• DB round-trip 유지 (성능 유지)
• 트랜잭션 안정성 확보

결론적으로 “성능 최적화와 동시성 안정성을 동시에 잡은 구조” 를 만들 수 있었습니다.

 

 

또한, 이번 경험에서 가장 중요한 포인트는 다음과 같습니다.

 

1. DB는 실행 순서를 보장하지 않는다

• 옵티마이저는 항상 최적의 실행 계획을 선택하며, 그 과정에서 row 접근 순서는 바뀔 수 있습니다.

 

2. 데드락의 본질은 순환 대기다

• 락이 많아서가 아니라 락 순서가 다르기 때문에 발생

 

3. 해결은 단순하다 — 순서를 통제하라

• 동일한 순서로 lock을 잡으면, 데드락은 발생하지 않는다

 

4. 성능과 안정성은 트레이드오프가 아니다

• 잘 설계하면 둘 다 잡을 수 있다.

 

 

데드락은 단순한 DB 문제가 아니라 동시성 제어의 본질적인 문제입니다. 특히 대규모 트래픽이나 병렬 처리 환경에서는 “언젠가는 반드시” 마주하게 됩니다.

이번 경험을 통해 얻은 결론은 명확합니다. “락을 줄이는 것보다, 락의 순서를 통제하는 것이 더 중요하다”

 

 

이 글이 비슷한 문제를 겪는 분들에게 도움이 되었으면 합니다.