파이썬 SQLAlchemy ORM 낙관적 잠금과 비관적 잠금 완벽 가이드

🧩 SQLAlchemy ORM과 동시성 문제

SQLAlchemy는 파이썬에서 가장 널리 사용되는 ORM 중 하나로, 복잡한 SQL을 직접 작성하지 않고도 객체지향적으로 데이터베이스를 다룰 수 있게 해줍니다.
하지만 데이터베이스를 사용하는 애플리케이션이라면 피할 수 없는 문제가 있습니다.
바로 동시성(Concurrency) 문제입니다.

예를 들어, 두 명의 사용자가 동시에 같은 게시글을 수정한다고 가정해 보겠습니다.
한 사용자가 제목을 바꾸는 동시에 다른 사용자가 내용을 바꾼다면, 저장 과정에서 충돌이 발생할 수 있습니다.
어떤 사용자의 변경 사항이 덮어써질지 알 수 없으며, 심한 경우 데이터 무결성이 깨질 수도 있습니다.
이를 방지하기 위해 데이터베이스 시스템은 잠금(Lock) 메커니즘을 제공합니다.

📌 잠금의 필요성

잠금은 여러 사용자가 동시에 같은 데이터를 다루더라도 안전하게 처리가 가능하도록 하는 장치입니다.
대표적으로 낙관적 잠금(Optimistic Lock)과 비관적 잠금(Pessimistic Lock)이 있습니다.
낙관적 잠금은 충돌이 자주 일어나지 않을 것이라 가정하고 충돌 발생 시 해결하는 방식이고, 비관적 잠금은 충돌 가능성이 높다고 보고 애초에 다른 사용자가 접근하지 못하게 막는 방식입니다.

• 🔄낙관적 잠금: 충돌이 드물다고 가정하고 나중에 검증
• 🔒비관적 잠금: 충돌이 빈번하다고 가정하고 처음부터 차단
• ⚡SQLAlchemy는 두 방식을 모두 지원하여 유연한 선택이 가능

따라서 애플리케이션의 성격과 데이터 특성에 따라 어떤 잠금 방식을 채택할지 결정해야 합니다.
SQLAlchemy ORM은 version_id_col을 통해 낙관적 잠금을, with_for_update()를 통해 비관적 잠금을 구현할 수 있습니다.
다음 단계에서는 이 두 가지 방법을 구체적으로 살펴보겠습니다.

🔄 낙관적 잠금 version_id_col 이해하기

낙관적 잠금은 여러 사용자가 동시에 데이터를 수정할 수 있도록 허용하지만, 최종 저장 시점에서 충돌 여부를 검증하는 방식입니다.
SQLAlchemy에서는 version_id_col 속성을 사용해 이 기능을 구현합니다.
이 방식은 충돌이 자주 발생하지 않는 환경에서 성능을 유지하면서도 데이터 무결성을 지킬 수 있다는 장점이 있습니다.

📌 동작 원리

낙관적 잠금은 테이블에 버전 컬럼(version column)을 추가하여 동작합니다.
레코드가 수정될 때마다 해당 버전 값이 증가하며, 업데이트 시점에서 애플리케이션은 버전 값이 일치하는지 확인합니다.
만약 다른 트랜잭션에서 이미 버전을 변경했다면 업데이트가 거부되며, 이로써 충돌을 감지할 수 있습니다.

from sqlalchemy.orm import declarative_base
from sqlalchemy import Column, Integer, String

Base = declarative_base()

class User(Base):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True)
    name = Column(String)
    version_id = Column(Integer, nullable=False)

    __mapper_args__ = {
        "version_id_col": version_id
    }

위 예제처럼 version_id_col을 지정하면 SQLAlchemy가 자동으로 충돌 여부를 확인합니다.
만약 동일한 데이터를 두 사용자가 수정하려고 할 때, 먼저 커밋된 트랜잭션은 성공하지만 뒤늦게 커밋하려는 트랜잭션은 버전 불일치로 인해 예외를 발생시키게 됩니다.

💬 낙관적 잠금은 충돌이 드문 환경에서 데이터 무결성을 보장하는 데 효과적입니다.

하지만 이 방식은 충돌 발생 시 예외 처리와 재시도 로직이 필요하다는 점을 고려해야 합니다.
예를 들어 사용자가 쇼핑몰에서 동시에 재고를 수정하는 경우, 실패한 요청은 재시도하거나 사용자에게 안내하는 로직이 필요합니다.

🔒 비관적 잠금 with_for_update 살펴보기

비관적 잠금은 충돌이 발생할 가능성이 높다고 판단되는 경우 사용됩니다.
이 방식은 데이터를 읽는 순간 다른 트랜잭션이 해당 데이터를 수정하지 못하도록 즉시 잠금을 걸어버립니다.
SQLAlchemy에서는 with_for_update() 메서드를 통해 비관적 잠금을 간단히 구현할 수 있습니다.

📌 동작 원리

비관적 잠금은 데이터베이스 수준에서 해당 레코드에 대해 SELECT … FOR UPDATE 구문을 실행합니다.
따라서 잠금이 걸린 레코드를 다른 트랜잭션이 수정하려고 하면 해당 트랜잭션은 잠금이 해제될 때까지 대기하게 됩니다.

from sqlalchemy import select
from sqlalchemy.orm import Session

stmt = select(User).where(User.id == 1).with_for_update()

with Session(engine) as session:
    result = session.execute(stmt).scalar_one()
    result.name = "변경된 이름"
    session.commit()

위 예제에서는 특정 User 레코드를 조회할 때 즉시 잠금이 걸리며, 다른 트랜잭션은 이 레코드를 수정할 수 없게 됩니다.
따라서 충돌을 원천적으로 차단할 수 있습니다.

그러나 비관적 잠금은 잠금이 오래 유지될 경우 교착상태(Deadlock)가 발생할 수 있으며, 성능 저하를 유발할 수 있습니다.
따라서 꼭 필요한 경우에만 사용하는 것이 좋습니다.

⚖️ 낙관적 잠금과 비관적 잠금 비교

낙관적 잠금과 비관적 잠금은 모두 데이터 무결성을 지키기 위한 전략이지만, 접근 방식이 정반대입니다.
낙관적 잠금은 충돌이 드물다는 가정 아래 사후 검증을 통해 처리하고, 비관적 잠금은 충돌이 빈번하다는 전제에서 아예 접근 자체를 막습니다.
따라서 어떤 방식을 선택할지는 시스템의 성격, 데이터 접근 패턴, 동시 접속자 수 등에 따라 달라집니다.

📌 장단점 비교

💬 낙관적 잠금은 성능이 중요한 서비스에서, 비관적 잠금은 데이터 정확성이 절대적인 환경에서 주로 선택됩니다.

즉, 쇼핑몰의 재고 관리처럼 동시 접근 가능성이 높은 경우에는 비관적 잠금이 유리할 수 있고, 반대로 블로그 글 수정처럼 충돌이 드문 환경에서는 낙관적 잠금이 효율적입니다.
따라서 두 방법을 적절히 혼합해 사용하는 전략도 고려할 수 있습니다.

💡 실제 사례와 적용 전략

낙관적 잠금과 비관적 잠금은 단순한 이론이 아니라 실제 서비스 운영에서 중요한 역할을 합니다.
각각의 방식은 특정 상황에 최적화되어 있기 때문에, 올바른 전략을 세우는 것이 안정적인 애플리케이션 운영의 핵심입니다.

📌 실제 사례

예를 들어, 인터넷 뱅킹 시스템에서는 사용자가 동시에 같은 계좌에서 송금을 시도할 수 있습니다.
이 경우에는 충돌을 원천적으로 차단하는 비관적 잠금을 적용해야 계좌 금액이 꼬이지 않습니다.
반대로 온라인 커뮤니티에서는 다수의 사용자가 동시에 글을 수정하는 경우가 드물기 때문에 낙관적 잠금을 적용하는 것이 성능상 유리합니다.

📌 하이브리드 전략

대규모 서비스에서는 두 가지 방식을 혼합하는 경우도 많습니다.
예를 들어 상품 재고 관리에서는 기본적으로 낙관적 잠금을 사용하다가, 재고가 소진 직전에 접어들면 비관적 잠금을 적용하는 방식입니다.
이렇게 하면 시스템 성능과 안정성을 모두 확보할 수 있습니다.

📌 적용 시 고려사항

• 📊시스템 트래픽과 동시성 수준을 고려해야 함
• ⚠️비관적 잠금은 데드락 가능성이 있으므로 모니터링 필요
• 🔁낙관적 잠금은 충돌 발생 시 재시도 로직 구현이 필수

정리하자면, SQLAlchemy에서 제공하는 낙관적 잠금과 비관적 잠금은 각각의 장점을 살려 상황에 맞게 적용하는 것이 중요합니다.
효율적인 전략을 수립하면 데이터 무결성을 지키면서도 성능을 최대한 유지할 수 있습니다.

❓ 자주 묻는 질문 (FAQ)