WIL - 4주차 회고

 

동시성 제어를 위한 락 적용

이번 주는 동시성 제어를 주제로, 상황에 따라 비관적 락과 낙관적 락 중 어떤 것을 적용해야 하는지 고민해봤다.

그동안은 이론적으로 두 락의 특성을 알고 있었지만, 실제로 어떤 상황에서 적용했을 때 어떤 결과가 나오는지는 경험해보지 못했었다. 이번 과제를 통해 직접 시도해보면서 책에서만 보던 내용을 한층 더 명확하게 이해할 수 있었다.

예전에는 “비관적 락은 느리고 비효율적이고, 낙관적 락이 더 좋다”라는 이야기를 그대로 믿고 있었다. 어느 정도는 맞는 말이었다.
비관적 락은 DB 수준에서 락을 잡기 때문에 낙관적 락보다 리소스를 더 많이 사용했고, 그만큼 성능에도 영향을 주었다. 그래서 단순 비교만 보면 비관적 락이 덜 선호되는 것도 이해할 수 있었다.

하지만 낙관적 락에 재시도 로직이 추가되면 상황은 달라졌다.
재시도 횟수, 재시도 간격, 간격 증가 방식 등에 따라 성능 차이가 크게 났다.
기본적인 상황에서는 낙관적 락이 더 빠르고 효율적이었지만, 재시도가 과도해지는 시점부터는 오히려 비관적 락이 더 효율적인 경우가 나왔다.

이 성능 비교 결과는 아래 블로그에 정리했다.

 

블로그 링크: 비관적 락은 정말 느릴까? 실험해봤습니다

 

또한 ExecutorService와 CountDownLatch를 사용하여 각 락이 정상 동작하는지도 테스트했다.

테스트 코드를 작성해 직접 실행해보니, 앞으로 락을 적용할 때 나만의 기준이 훨씬 명확해졌다는 생각이 들었다.

 

 

리팩토링에 대한 자신감 증가

이 부분은 1주차부터 계속해서 느끼고 있는 점이었다. 이제는 리팩토링에 대한 두려움이 사라졌다.
예전에는 코드량이 많아질수록 수정하는 것이 부담스러웠지만, 지금은 테스트 코드가 확실한 안전망이 되어주었다.

테스트 코드 없이 개발하던 시절을 돌이켜보면, 보호구 없이 전쟁터에 나가는 기분이었다.
그때는 내가 테스트 코드 역할을 하면서 눈으로 확인하고 하나하나 직접 시나리오를 재현했는데, 시간도 오래 걸렸고 완성도도 낮았다.
이제는 요구사항이 추가되어 코드가 복잡해져도 테스트 코드가 모든 것을 검증해주기 때문에 마음 놓고 구조를 변경할 수 있게 되었다.

1~4주차를 진행하면서 많은 리팩토링 요소를 메모해두었고, 시간이 될 때마다 꾸준히 개선해 나갈 계획이다.
처음부터 완벽한 결과를 내면 좋겠지만, 현실적으로는 쉽지 않다고 생각한다.
그래서 나는 시작부터 완벽함을 추구하기보다, 끝까지 가서 좋은 결과를 만들어내는 것을 목표로 하고 있다.
부족하다고 해서 포기하는 것보다, 부족하더라도 언젠가는 해결하고 완성해내는 것이 더 가치 있다고 믿는다.