실무 레거시코드에 낙관적 락, 비관적 락 적용 시도

안녕하세요
현재 섹션 5_4-9. 낙관적 락, 비관적 락 부분을 듣고 있는데요.

현재 공공SI 고도화 개발팀에서 개발을 하고 있는데
동시성 제어 부분이 있는것 같아서 질문드립니다.

레거시 코드로
Oracle/ iBatis DAO / XML 환경이며

담당자가 신청에 대해서 접수하는 기능에서
소스분석을 통해서 봤을 때 기존 소스 흐름은
1. 작업확인용 테이블에서 현재 작업중인 목록이 있는지 확인(Select)
2-1. 작업중 목록이 없다면
작업확인용 테이블에 작업중으로 insert
2-2. 작업중 목록이 있다면
Exception 발생(작업중입니다.)
3. 해당 신청건에 대한 insert/update 진행
4. 작업확인용 테이블의 insert 했던 값의 상태를
작업완료로 Update
* 작업중 상태가 있을 땐 다른 신청건에 대해서도 접수가 불가

입니다.

강의를 듣고 보았을 때 작업확인용 테이블의 존재 이유가 동시성 제어를 위함으로 보이는데

기존 흐름을 봤을 때
비관적락 > 배타락으로 적용하는것이 맞다고 생각이 드는데 맞는 접근일까요?
또한
비관적 락 적용시 작업확인용 테이블의 존재가 필요없어지는 걸까요?

해당부분을 건드리기에 부담이 가서 기존 방식대로 개발을 해놓은 상태이긴 한데
강의를 듣고 적용해볼 수 있지 않을까 생각이 들어 질문드립니다!

안녕하세요, 인프런 AI 인턴입니다. Jin K님.

현재 공공 SI 프로젝트에서 동시성 문제를 해결하기 위한 전략으로 낙관적 락과 비관적 락을 고려하고 계신 것 같습니다. 작성해주신 내용을 바탕으로 통찰을 제공해 드리겠습니다.

기존 코드 분석

현재 레거시 시스템에서 동시성 제어를 위해 “작업확인용 테이블”을 사용하고 있는 구조로 보여집니다. 동시성 제어 방식은 주로 데이터베이스에서의 작업 흐름을 안전하게 관리하기 위해 사용되는 전략입니다.

기존 흐름에서:
1. 작업 확인 후 “작업중” 플래그를 설정하여 다른 작업의 수행을 방지하고,
2. 작업 완료 후 상태를 업데이트하면서 동시성을 제어하는 방식입니다.

비관적 락과 보완 방법

비관적 락:
- 데이터가 동시에 변경될 가능성이 높다고 판단하여 트랜잭션이 시작되면 바로 락을 걸어 데이터의 변경을 잠가버리는 방식입니다.
- 비관적 락을 사용하면, 기존에 “작업중”을 확인하고 예외를 던지는 방식을 대체할 수 있습니다. 이 방식은 데이터베이스 레벨에서 락이 걸리기 때문에, 다른 트랜잭션이 접근할 때 기다리게 됩니다.
작업확인용 테이블의 필요성:
- 비관적 락을 사용한다면, “작업확인용 테이블” 자체의 필요성은 줄어들 수 있지만, 시스템의 상태나 작업 이력을 기록하는 용도로는 여전히 유효할 수 있습니다.
- 시스템 전반적으로 프로그램 내부에서의 락보다 데이터베이스 수준에서의 락이 더 일관적이고 관리하기 쉬울 수 있습니다.

실제 적용과 주의사항

레거시 시스템에 작용 시 새로운 락 메커니즘이 기존 프로세스에 미치는 영향을 면밀히 검토해야 합니다. 비관적 락을 적용할 경우 롱 트랜잭션으로 인해 시스템 전반의 성능이 저하될 가능성도 있으므로 주의해야 합니다.
트랜잭션 경계와 격리 수준을 적절히 설정하여 추가적인 문제가 발생하지 않도록 고려해야 합니다.

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

기존 코드 분석

비관적 락과 보완 방법

실제 적용과 주의사항

관련 게시물