출세한 익룡님의 면접 결과

Lost Update의 핵심 개념인 "동시 실행 시 한 트랜잭션의 갱신이 다른 트랜잭션에 의해 덮어써지는 현상"을 정확히 짚으셨습니다. 한 단계 더 나아가자면, 이 현상이 발생하는 구체적인 메커니즘(예: T1이 값을 읽고 수정하기 전에 T2가 동일한 값을 읽고 먼저 커밋하면, T1의 커밋이 T2의 변경을 덮어쓰는 시나리오)과 이를 방지하기 위한 수단(비관적 락, 낙관적 락, SELECT FOR UPDATE 등)까지 언급하면 답변의 깊이가 한층 높아질 것입니다. 예를 들어 "두 트랜잭션이 같은 행을 읽은 뒤 각각 수정·커밋할 때, 나중에 커밋된 트랜잭션이 먼저 커밋된 변경을 덮어써 데이터가 소실되는 현상이며, 이를 방지하기 위해 비관적 락이나 낙관적 락을 활용합니다"처럼 원인과 해결책을 함께 제시해 보세요.

구체적인 시나리오(budget=1000, 두 트랜잭션의 동시 read → 각각 write → 한 쪽 결과 소실)를 통해 Lost Update의 발생 메커니즘을 정확하게 설명하셨습니다. 특히 최종값이 1100이 된다는 수치까지 제시해 문제 상황을 명확히 전달한 점이 좋았습니다. 한 단계 더 나아가자면, 이 현상이 어떤 격리 수준(Isolation Level)에서 발생하고 어떤 수준에서 방지되는지, 혹은 낙관적 락(Optimistic Lock)·비관적 락(Pessimistic Lock) 같은 해결 전략과 연결 지어 설명할 수 있다면 더욱 완성도 높은 답변이 될 것입니다. 예를 들어 "Lost Update는 Read Committed 수준에서도 발생할 수 있으며, Repeatable Read 이상이나 SELECT FOR UPDATE를 통한 비관적 락으로 방지할 수 있습니다"처럼 이어가 보시면 좋겠습니다.

비관적 락과 낙관적 락이라는 핵심 전략을 정확히 짚은 점은 좋습니다. 다만 "어떤 방법을 사용할 수 있나요?"라는 질문에는 방법의 이름뿐 아니라 그 방법이 Lost Update를 어떻게 막는지 원리까지 함께 설명해야 완성도가 높아집니다. 예를 들어 "비관적 락은 SELECT FOR UPDATE로 읽기 시점에 배타 락을 걸어 다른 트랜잭션의 접근을 차단하고, 낙관적 락은 version 컬럼을 두어 커밋 시점에 버전이 변경됐으면 롤백하는 방식으로 충돌을 감지합니다"처럼 메커니즘을 한 문장이라도 덧붙이면 훨씬 설득력 있는 답변이 됩니다. 다음에는 각 전략의 동작 원리와 트레이드오프(비관적 락의 데드락 위험, 낙관적 락의 충돌 빈도에 따른 성능 차이)까지 함께 언급해 보세요.