💾 트랜잭션(Transaction) 개념 정리 - DB 무결성의 핵심

실제로 SQL 여러 개를 묶어서 실행해보고, 중간에 오류가 나면 전부 되돌리는 걸 경험해보니까 왜 그런 말이 나오는지 이해가 됐어요. 실습을 따라가면서 rollback과 commit이 어떤 상황에서 필요한지도 확실히 알게 되었고요. '아~ 이래서 실무에서도 꼭 쓰는구나!' 싶은 순간이 있었어요.

---

📚 목차

• 💡 트랜잭션이란?
• 📄 ACID 특성
• 💻 SQL 예시
• ☕ Java에서의 트랜잭션
• 🚨 트랜잭션 예외와 격리 수준
• 📝 요약
• 📖 느낀점

---

💡 트랜잭션이란?

트랜잭션(Transaction)은 하나의 논리적인 작업 단위로, 여러 개의 데이터베이스 작업이 모두 성공하거나 모두 실패해야만 하는 그룹을 말합니다.

예를 들어, 계좌 이체를 생각해봅시다. A 계좌에서 1만 원을 빼고 B 계좌에 1만 원을 넣는 두 작업이 함께 실행돼야 의미가 있습니다. 한쪽만 처리되면 데이터는 틀어지게 되죠. 이처럼 여러 작업을 하나로 묶고 원자적으로 처리하는 단위가 바로 트랜잭션입니다.

🛒 비유하자면, 트랜잭션은 '결제하기 전 장바구니'와 같습니다. 결제 버튼을 누르기 전까진 어떤 상품도 실제 구매되지 않아요. 하지만 결제를 누르는 순간, 모든 상품이 한꺼번에 결제되죠. 하나라도 문제가 생기면 전체 결제는 취소됩니다.

---

📄 ACID 특성

트랜잭션이 갖추어야 할 네 가지 성질을 ACID라고 부릅니다.

약어	이름	설명
A	Atomicity (원자성)	모두 실행되거나, 하나라도 실패하면 전체 취소됨
C	Consistency (일관성)	트랜잭션 전후의 데이터는 항상 일관성을 유지함
I	Isolation (격리성)	동시에 실행되는 트랜잭션 간 간섭이 없어야 함
D	Durability (지속성)	트랜잭션 완료 후 데이터는 영구적으로 반영됨

🔍 Atomicity → 한 몸처럼 움직이는 작업!
🔍 Consistency → 규칙이 깨지지 않도록 보장!
🔍 Isolation → 내 작업은 방해받지 않도록!
🔍 Durability → 전원이 나가도 결과는 남아있어야해!

---

💻 SQL 예시

BEGIN; -- 트랜잭션 시작

-- A 계좌에서 1만 원 차감
UPDATE Account SET balance = balance - 10000 WHERE id = 1;

-- B 계좌에 1만 원 추가
UPDATE Account SET balance = balance + 10000 WHERE id = 2;

COMMIT; -- 트랜잭션 성공 시 확정 저장

위 예시는 A → B로 1만 원을 이체하는 상황입니다. 이 두 쿼리는 트랜잭션으로 묶여야 합니다. 둘 중 하나라도 실패하면 전체를 ROLLBACK 해야 데이터 불일치가 발생하지 않습니다.

🧾 계약서에 양쪽 도장이 모두 찍혀야 계약이 성립되는 것과 비슷합니다.

---

☕ Java에서의 트랜잭션

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;

public class TransactionExample {
    public static void main(String[] args) {
        String url = "jdbc:mysql://localhost:3306/testdb";
        String user = "root";
        String pw = "password";

        Connection conn = null;

        try {
            // 데이터베이스 연결
            conn = DriverManager.getConnection(url, user, pw);

            // 자동 커밋을 꺼서 수동 트랜잭션 시작
            conn.setAutoCommit(false);

            // A 계좌에서 10000원 차감
            String sql1 = "UPDATE Account SET balance = balance - 10000 WHERE id = 1";
            PreparedStatement pstmt1 = conn.prepareStatement(sql1);
            pstmt1.executeUpdate();

            // B 계좌에 10000원 추가
            String sql2 = "UPDATE Account SET balance = balance + 10000 WHERE id = 2";
            PreparedStatement pstmt2 = conn.prepareStatement(sql2);
            pstmt2.executeUpdate();

            // 모든 작업이 문제없이 끝나면 커밋
            conn.commit();
            System.out.println("트랜잭션 성공: 커밋 완료");

        } catch (Exception e) {
            try {
                // 오류가 발생하면 롤백
                if (conn != null) {
                    conn.rollback();
                    System.out.println("오류 발생: 롤백 처리됨");
                }
            } catch (Exception rollbackEx) {
                rollbackEx.printStackTrace();
            }
        } finally {
            try {
                if (conn != null) conn.close(); // 연결 종료
            } catch (Exception closeEx) {
                closeEx.printStackTrace();
            }
        }
    }
}

JDBC에서는 setAutoCommit(false)를 호출해 수동 트랜잭션을 시작합니다.
모든 작업이 성공하면 commit(), 실패하면 rollback()을 호출해 복구합니다.

✍️ 직접 저장 버튼을 눌러야 저장되는 에디터처럼, 트랜잭션도 수동으로 완료시켜야 반영됩니다.

🧩 Spring에서는 @Transactional을 사용하면 더욱 깔끔하게 트랜잭션을 제어할 수 있습니다.

---

🚨 트랜잭션 예외와 격리 수준

트랜잭션 간 충돌로 발생할 수 있는 현상들

• Dirty Read: 아직 커밋되지 않은 데이터를 읽는 경우
• Non-repeatable Read: 같은 쿼리를 두 번 했을 때 결과가 달라지는 경우
• Phantom Read: 조건에 맞는 행이 트랜잭션 도중 새로 생기는 경우
• Deadlock: 서로의 자원을 기다리며 무한 대기 상태에 빠지는 상황

이러한 문제는 격리 수준(Isolation Level) 설정을 통해 제어할 수 있습니다.

수준	설명	막을 수 있는 현상
READ UNCOMMITTED	가장 낮은 수준. Dirty Read 허용	없음
READ COMMITTED	커밋된 데이터만 읽음	Dirty Read ❌
REPEATABLE READ	같은 행에 대한 조회 일관성 보장	Non-repeatable Read ❌
SERIALIZABLE	가장 높은 격리, 성능 저하	Phantom Read ❌

⚠️ 격리 수준이 높을수록 안전하지만 성능은 낮아집니다. 상황에 맞는 설정이 중요합니다!

---

📝 요약

• 트랜잭션은 데이터 정합성을 위한 핵심 도구
• ACID는 트랜잭션의 4대 특성으로 반드시 이해해야 함
• JDBC에서는 수동 제어, Spring에서는 @Transactional로 선언적 처리 가능
• 트랜잭션 간 간섭 문제는 격리 수준으로 대응

---

📖 느낀점

처음엔 commit, rollback 같은 것도 낯설고 어렵게 느껴졌지만, 에러를 일부러 만들어보면서
'왜 필요한지'를 몸으로 느낄 수 있었다.
중간에 쿼리 하나가 실패하면 나머지도 함께 되돌려야 한다는 게 실제로 작동하니까 신기했다.
아직 격리 수준 같은 건 조금 헷갈리지만, 하나씩 테스트해보니까 '그래서 이런 기능이 필요하구나' 싶어서 재미있었다. (물론 지금도 헷갈리는 건 많아요!)