인프런 커뮤니티 질문&답변

안녕하세요 라이언님!좋은 질문 해주셔서 감사합니다. 트랜잭션의 핵심을 정확하게 짚어주셨네요! 이 질문에 답하려면 트랜잭션이 실제로 어떻게 동작하는지부터 이해해야 합니다.

1. 왜 "uncommitted 업데이트"가 존재할까요?

말씀하신 "처음부터 uncommitted 업데이트를 안 하면 되는 거 아니야?"는 사실 매우 핵심적인 질문입니다. 하지만 트랜잭션이 동작하는 방식 때문에 불가능합니다.

예를 들어볼게요. A가 출금 트랜잭션을 시작했습니다.

BEGIN;
UPDATE account SET balance = balance - 500 WHERE id = 1;
-- 여기서 다른 작업들을 더 수행...
-- 검증 로직, 로그 기록 등...
COMMIT;

트랜잭션이 시작되고 UPDATE를 실행하는 순간, 데이터베이스는 "변경 내용"을 어딘가에 기록해야 합니다. 왜냐하면 트랜잭션 내부에서는 변경된 값을 봐야 하니까 A의 트랜잭션이 출금 후 "내 잔액이 얼마지?"라고 다시 조회하면 500만원 차감된 값을 봐야 합니다. 본인의 트랜잭션 안에서는 이미 변경이 일어난 거니까요.

롤백을 대비해야 하니까 커밋 전까지는 언제든 ROLLBACK이 가능해야 합니다. 그래서 원본 데이터도 유지하면서 변경 내용도 기록해둡니다.

동시성 처리를 위해서도 필요합니다. 여러 트랜잭션이 동시에 실행되는데, 각 트랜잭션은 자기만의 "변경 버전"을 가지고 있어야 합니다.

이렇게 "커밋은 안 했지만 변경은 기록된" 상태가 바로 uncommitted 상태입니다. 이건 데이터베이스가 트랜잭션을 지원하려면 필연적으로 생기는 겁니다.

2. 그럼 다른 트랜잭션이 이걸 못 보게 하면 되는 거 아닌가요?

정확합니다! 말씀하신게 바로 격리 수준(Isolation Level)의 핵심입니다.

"uncommitted 데이터를 다른 트랜잭션이 읽을 수 있나?"가 바로 격리 수준에 따라 달라집니다.

READ UNCOMMITTED (강의 예시에서 문제가 된 상황): 다른 트랜잭션의 uncommitted 변경도 읽을 수 있습니다. 그래서 대출 심사가 500만원(아직 커밋 안 된 값)을 보게 되는 거죠.

READ COMMITTED (제안하신 방식): 커밋된 데이터만 읽습니다. 대출 심사는 여전히 1000만원을 보게 됩니다. A의 출금 트랜잭션이 커밋되기 전까지는요.

REPEATABLE READ: 트랜잭션 시작 시점의 스냅샷을 읽습니다. 중간에 다른 트랜잭션이 커밋해도 처음 본 값을 계속 봅니다.

SERIALIZABLE: 완전히 순차적으로 실행되는 것처럼 동작합니다.

제안해주신대로 "READ COMMITTED 이상"을 쓰면 Dirty Read 문제는 해결됩니다. 실제로 대부분의 데이터베이스는 기본값이 READ COMMITTED입니다.

하지만 격리 수준을 높이면 성능 비용이 발생합니다.

이런 고민을 실제 프로젝트에 적용해서 "동시성 문제를 이해하고, 적절한 격리 수준을 선택하고, 측정 가능한 결과를 만들었다"는 스토리를 완성해보세요. 그게 면접에서 정말 강력한 무기가 될 수 있을겁니다!! 감사합니다

안녕하세요, 인프런 AI 인턴입니다. 신나는 라이언님.

트랜잭션에서 언커밋된 데이터를 다룰 때 발생할 수 있는 문제에 대해 궁금하신 것 같습니다. 이를 해결하기 위해 데이터베이스에서 사용하는 트랜잭션 격리 수준을 이해하는 것이 중요합니다.

트랜잭션 격리 수준

1. 언커밋 상태:

   • 트랜잭션이 진행 중일 때 데이터는 ‘언커밋 상태’에 있으며, 다른 트랜잭션에서 이를 읽을 경우 ‘더티 리드’ 문제가 발생할 수 있습니다.
     
   • 언커밋된 상태에서는 데이터의 일관성이 보장되지 않아 잘못된 정보가 전달될 수 있습니다. 이러한 문제를 방지하기 위해 대부분의 데이터베이스는 기본적으로 읽기 작업에서 커밋된 데이터만 읽도록 제공합니다.
     

2. 격리 수준:

   • READ UNCOMMITTED: 언커밋된 변경 사항을 읽을 수 있습니다. 발생할 수 있는 문제: 더티 리드.
     
   • READ COMMITTED: 다른 트랜잭션이 커밋한 변경 사항만 읽을 수 있습니다. 대부분의 데이터베이스에서 기본 설정.
     
   • REPEATABLE READ: 트랜잭션이 시작된 시점에서의 데이터 상태를 그대로 유지, 다른 트랜잭션의 변경을 읽지 않음.
     
   • SERIALIZABLE: 대부분의 격리 수준 중 가장 엄격하며 완전한 일관성을 보장합니다.
     

대출 심사나 중요한 금융 프로세스에서는 대개 READ COMMITTED 이상의 격리 수준을 적용하여 정확한 데이터 읽기를 보장합니다. 따라서 트랜잭션 중에 데이터가 언커밋 상태로 남아있지 않게 관리되고, 데이터 일관성을 유지하기 위한 설계를 고려해야 합니다.

참고 자료

비슷한 질문이 트랜잭션 격리성의 실제 사례와 적용 가이드에서 다루어지고 있습니다. 이를 통해 트랜잭션에서 언커밋 데이터 문제를 맞닥뜨렸을 때의 실질적인 접근 방식을 이해할 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.