루퍼스 4주차의 회고
[회고] 루퍼스 4주 차
“왜 비관적 락을 사용하셨나요?” 면접에서 이 질문을 들을 때마다 늘 외운 대답을 했었다. 근데 이렇게 하면 설득이 안 되더라. 진지하게 고민하지 않고, 왜 그 선택을 했는지 스스로 납득하지 못한 채 답하니까 당연한 결과였다.
이번 주에 새로 배운 것
동시성 제어와 낙관적 락/비관적 락, 그리고 JDK에서 제공하는 동시성 도구들
JDK 동시성 도구들
이번 주에 렌 멘토님의 멘토링을 듣고 JDK가 제공하는 동시성 관련 도구들을 쭉 훑었다. notify()/wait(), synchronized, Lock, 세마포어, 뮤텍스, volatile, ThreadLocal, Atomic Class, CAS 알고리즘 등등. 사실 키워드 자체는 이전에도 들어봤지만, 이것들이 각각 어떤 문제를 해결하기 위해 존재하는지 관점에서 정리해본 건 이번이 처음이었다.
가상스레드와 pinning 문제
이번에 인상 깊었던 건 가상스레드 관련 내용이다.
- 가상스레드: JVM 안에서 동작하는 스레드로, 캐리어스레드 위에서 실행된다.
- 플랫폼스레드(커널스레드): OS에서 관리하는 스레드.
과거의 고민이 “N개의 스레드를 어떻게 효율적으로 쓰지?”였다면, 지금은 “무한개의 가상스레드에서 안 터지고 잘 사용할 수 있을까?”로 바뀌었다는 게 재밌었다.
특히 synchronized가 OS 단에서 동작하기 때문에, 가상스레드 위에서 실행하더라도 캐리어스레드에 고정(pinning)되는 현상이 생긴다는 걸 처음 알았다. 실무에서 가상스레드를 도입할 때 이걸 모르면 오히려 성능이 나빠질 수 있겠다고 느꼈다.
이런 고민이 있었어요
처음엔 “결제할 때는 무조건 비관적 락”이라고 생각했다. 낙관적 락은 버전으로 관리하니까 돈 관련 로직에는 안 맞다고 믿었다. 돈 = 비관적 락이라는 고정관념이 박혀 있었다.
- 돈이란 비용, 즉 쿠폰이든 송금, 결제 등 돈에 관련된것들
근데 배워보니까 루퍼스에서는 “락을 쓸 때 절대 정답은 없다”고 했다. 도메인별로, 적재적소에 잘 섞어서 사용하는 거라고. 예를 들어 쿠폰 발급처럼 충돌이 드문 경우엔 낙관적 락이 더 효율적일 수 있고, 실시간 잔액 차감처럼 충돌이 잦은 경우엔 비관적 락이 맞을 수 있다.
그래서 지금 고민하는 건 “어떤 상황에서 어떤 락을 선택해야 하는가”에 대한 나만의 기준을 만드는 것이다. 아직 명확한 답은 없지만, 최소한 “무조건 비관적 락”이라는 생각에서는 벗어났다.
앞으로 실무에서 써먹을 수 있을 것 같은 포인트
- 지금 해외송금 스타트업에 다니고 있는데, 송금 로직에서 동시성 제어와 정합성이 핵심이다. 이번에 배운 락 선택 기준을 실제 송금 플로우에 적용해볼 수 있을 것 같다.
- 서비스 런칭 때 신규 고객 대상 쿠폰 발급이 있을 텐데, 동시성 제어를 어떻게 가져갈지 이번 학습 내용을 바로 적용해볼 수 있겠다.
- 멘토가 “전략 패턴을 활용해서 각각의 할인 정책을 어떻게 도메인에 녹일 수 있는지 고민해보라”고 했다. 단순히 락만 고르는 게 아니라, 할인 정책 자체를 유연하게 설계하는 것도 함께 고민해봐야겠다.
이번 주 메타 회고 — AI 의존과 집중도
솔직히 이번 주는 AI에 너무 의존했다. AI에게 물어보고 답을 받으면 “아 그렇구나” 하고 넘어가는 패턴이 반복됐다. 코드를 타이핑하는 속도가 느려지는 건 괜찮지만, 개념이 헷갈리거나 트레이드오프를 스스로 판단 못 하는 건 문제다.
이직한 지 얼마 안 돼서 새 환경 적응에 에너지를 많이 쓴 것도 사실이다. 스타트업이고 언어도 다르다 보니 루퍼스에 온전히 집중하기 어려웠다.
하지만 “바빠서”를 이유로 매주 같은 고민만 반복하고 있다는 걸 인식했다. 그래서 다음 주부터는 구체적으로 이렇게 해보려 한다:
다음 주에 해보고 싶은 것
- 하루 30분 개념 정리 시간 확보: AI 없이, 이번 주 배운 동시성 도구들을 직접 정리해본다.
- 낙관적 락 vs 비관적 락 판단 기준표 만들기: 충돌 빈도, 트랜잭션 길이, 데이터 중요도 등 기준을 잡아보고, 실무 송금 도메인에 대입해본다.
- 멘토 피드백 반영: 전략 패턴으로 할인 정책을 분리하는 구조를 간단하게라도 설계해본다.