동시성 문제를 겪어본 적 없다는 백엔드 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-11-01

멘토링을 진행하다 보면 이력서 프로젝트란을 보며 이렇게 말씀하시는 주니어 백엔드 개발자분들이 많습니다. "저희 프로젝트는 실사용자가 많지 않아서 동시성 이슈는 다뤄보지 못했습니다." 대규모 트래픽을 처리해본 경험이 없으니 동시성 제어는 나와 먼 이야기라고 생각하는 것입니다.

그런데 과연 그럴까요? 아닙니다.

트래픽이 없어서 동시성이 안 일어난다는 착각

200명이 넘는 개발자들의 코드를 리뷰하면서 가장 흔하게 본 착각이 있습니다. 초당 수만 건의 요청이 쏟아져야만 동시성 문제가 터진다고 믿는 것입니다.

전혀 그렇지 않습니다. 동시성은 사용자가 단 2명이어도 발생합니다. 한정 수량 쿠폰을 두 사람이 동시에 발급받거나, 같은 글에 동시에 좋아요를 누를 때 데이터베이스는 이미 경쟁 상태에 놓입니다. 사용자가 적은 사내 시스템에서도 결제 버튼을 연달아 두 번 누르는 순간 중복 출금이 일어납니다.

트래픽이 적어서 동시성을 안 겪은 게 아닙니다. 동시성이 발생했을 때 데이터가 어떻게 깨지는지, 그 틈을 의심해본 적이 없어서 알아채지 못했을 뿐입니다.

동시성은 화려한 도구가 아니라 정합성의 고민입니다

많은 주니어가 동시성을 이야기할 때 분산 락이나 Redis, 메시지 큐 같은 화려한 도구부터 떠올립니다. 면접에서도 무작정 레디스 분산 락을 붙였다고 자랑합니다. 왜 그 기술을 선택했느냐고 물으면 '동시성을 잡기 위해서'라는 공허한 답변만 돌아옵니다.

동시성은 화려한 도구의 문제가 아닙니다. 데이터 정합성을 지키기 위한 비용과 타협의 문제입니다. 조회하고 연산하고 저장하는 그 짧은 찰나에 다른 트랜잭션이 끼어들 수 있는가. 이 질문을 던지는 것이 출발점입니다.

비관적 락으로 데이터베이스 레벨에서 걸어 잠글 것인가, 낙관적 락으로 충돌이 났을 때 재시도할 것인가. 심지어 고유 제약조건(Unique Constraint) 하나만으로 해결할 수 있는 문제는 아닌가. 기술을 덕지덕지 붙이기 전에, 데이터의 성격과 충돌 빈도부터 따져보는 감각이 백엔드의 기본기입니다.

내 코드에서 동시성이 깨지는 지점을 찾는 법

거창한 트래픽 시뮬레이션 도구가 없어도 괜찮습니다. 지금 여러분이 작성한 Service 로직을 열어보십시오.

조회 쿼리로 재고를 읽어온 뒤, 메모리에서 수량을 깎고, 다시 수정 쿼리를 날리고 있지는 않습니까? 그 사이에 다른 요청이 들어오면 어떤 일이 벌어질까요? 재고가 음수로 떨어지는 문제는 테스트 환경에서도 단 5줄의 멀티스레드 테스트 코드로 명확히 재현할 수 있습니다.

동시성을 다뤄본 개발자와 그렇지 않은 개발자의 차이는 대용량 서버 운영 경험에 있지 않습니다. 코드를 작성하는 순간 '두 요청이 동시에 겹치면 이 데이터는 안전한가?'를 스스로 묻고 검증해봤는가에 있습니다.

의심하십시오. 데이터베이스는 생각보다 느리고, 두 번째 요청은 생각보다 빠르게 도착합니다.