데이터베이스 기초 Q&A — 트레이드오프 12선과 34문답

데이터베이스 설계에서 어려운 부분은 개별 기능을 모르는 것이 아니라, 아는 것들 사이에서 무엇을 내주고 무엇을 받을지 정하는 일이다. 정규화를 어디까지 밀 것인가, 인덱스를 몇 개까지 둘 것인가, 격리수준을 올릴 것인가 쿼리를 고칠 것인가 — 답이 하나로 정해지지 않는 자리들이다.

이 글은 앞 네 편의 결론을 선택지 표 · 장애 표 · 질문 형태로 다시 세운다. 저장소를 고르는 자리에 있거나, 이미 돌고 있는 시스템에서 원인 불명의 지연·불일치를 쫓고 있는 백엔드 엔지니어를 위한 글이다. 답은 결론부터 쓰고 근거를 뒤에 붙이는 순서로 적었다.

각 주제의 전체 맥락은 앞 네 편에 있다 — 관계형 데이터베이스와 NoSQL, 데이터 모델링과 정규화, SQL 실행과 인덱스, 트랜잭션과 동시성 제어.

선택지별 트레이드오프

열두 행을 가로로 읽으면 열한 행은 교환이다 — 조회를 싸게 만들면 쓰기가 비싸지고, 보장을 강화하면 동시성이 준다. 예외가 정확히 한 행 있다. Literal SQL만 「얻는 것」 열이 비어 있다. 교환이 아니라 배제 항목이라는 뜻이고, 그래서 이 행만 「언제 쓰나」가 조건이 아니라 금지로 적혀 있다. 열두 개 중 하나가 트레이드오프가 아니라는 이 배정은 이 글의 정리다.

장애 아홉 가지 — 증상에서 원인으로

아홉 행을 「무엇으로 알아차리는가」로 배정하면 두 무리로 갈린다. 여섯 행은 느려지거나 에러를 내서 스스로 드러나고(16행), 세 행은 아무 신호도 내지 않는다(79행). 뒤의 셋은 SQL이 전부 정상 종료했고 로그에도 아무것도 남지 않는다. 그래서 앞의 여섯은 모니터링이 잡아 주지만 뒤의 셋은 대사(對査) 쿼리를 따로 돌리지 않으면 영원히 모른다. 여섯과 셋으로 가른 이 배정은 이 글의 정리다.

저장소와 용어 — 4문답

네 유형이 왜 그 영역에 자리 잡았는지, 그리고 세 축을 회의에서 쓸 수 있는 질문 형태로 편 표는 관계형 데이터베이스와 NoSQL의 「NoSQL 네 유형」과 「DBMS를 고르는 세 기준」 절에 있다.

모델링과 정규화 — 6문답

정규형을 1NF부터 5NF까지 한 줄 정의·위반 예·해소 방법으로 편 표와, 실무 기준선이 왜 3NF에서 멈추는지는 데이터 모델링과 정규화의 「정규형 단계별 비교」 절에 있다. 반정규화 카드 다섯 개가 각각 무슨 대가를 지불하는지도 같은 글의 「반정규화를 언제 하는가」 절에 표로 있다.

SQL·인덱스·실행계획 — 10문답

인덱스를 못 타는 케이스 여덟 가지를 「왜 못 타나」와 대응까지 붙여 편 표는 SQL 실행과 인덱스의 「인덱스를 못 타는 대표 케이스」 절에 있고, 세 조인 방식을 열 개 항목으로 비교하면서 각각의 실패 모드까지 적은 표는 같은 글의 「세 방식 비교」 절에 있다. 실행계획에서 access 와 filter 를 각각 무엇으로 읽는지는 「실행계획 읽는 법」 절이다.

트랜잭션과 동시성 — 10문답

격리수준 4단계를 이상현상 3종과 교차시킨 표, 그리고 그 표를 가로로 읽었을 때 나오는 실무 판단은 트랜잭션과 동시성 제어의 「격리수준 4단계 교차표」 절에 있다. 데드락 4조건을 각각 어떻게 깨는지까지 적은 표는 같은 글의 「Coffman 4조건」 절이고, Consistent 모드가 Undo에서 옛 이미지를 복원하는 분기는 「Current 모드와 Consistent 모드」 절에 도식으로 있다.

여기까지가 30문항이다. 저장소 4 · 모델링 6 · SQL 10 · 트랜잭션 10으로 배정했고, 남은 네 개는 한 줄로 답할 수 없어 아래에 따로 뒀다. 주제별로 묶고 개수를 배정한 것은 이 글의 정리다 — 원 자료는 이 질문들을 1번부터 차례로 번호를 매긴 한 장의 표로 두고 있다.

Q. 인덱스를 추가했더니 오히려 느려졌다. 어디부터 보나

그 인덱스가 쓰이고 있는지부터 확인한다. 「인덱스를 만들었다」와 「인덱스를 탄다」는 다른 사건이고, 둘을 구분하지 않으면 진단이 첫 단계에서 갈라진다.

3번이 가장 자주 오해받는 자리다. 실행계획에 Full Scan이 보인다는 이유로 인덱스를 더 만들면, 옵티마이저가 이미 옳게 내린 판단을 되돌리려 애쓰는 셈이 된다.

4번과 5번은 성격이 다르다. 1~3번이 「이 쿼리가 왜 느린가」를 묻는다면, 이 둘은 인덱스를 추가한 대가를 다른 쿼리들이 나눠 내고 있다는 이야기다. 그래서 인덱스는 조회 패턴을 실측한 뒤 최소한으로 만들고, 새로 만들기 전에 기존 인덱스에 컬럼을 붙여 덮을 수 있는지를 먼저 본다. 컬럼 추가는 인덱스 개수를 늘리지 않으므로 4번과 5번의 비용이 발생하지 않는다.

Q. 재고가 마이너스로 떨어진다. 어디를 고치나

검사와 차감을 한 문장으로 합친다. 원인은 갱신 손실이다. 재고를 읽어서 애플리케이션이 판정하고 다시 쓰는 사이에 다른 트랜잭션이 끼어들면, 두 요청 모두 「재고가 남았다」고 결론 내고 각각 차감한다.

UPDATE item_stock
   SET remain_qty = remain_qty - :orderQty
 WHERE item_id    = :itemId
   AND remain_qty >= :orderQty;

DBMS는 갱신 시점에 Current 모드로 조건을 다시 확인하므로, 경합이 있어도 조건을 만족하지 못한 요청은 0건 갱신으로 끝난다. 애플리케이션은 영향 행 수가 0이면 품절로 처리하면 된다.

한 문장으로 합칠 수 없을 만큼 판정 로직이 복잡한 경우의 대안은 아래와 같다.

세 방법의 공통 조건이 하나 있다. 영향 행 수가 0인 경우를 반드시 처리해야 한다. 세 방법 모두 충돌을 「에러」가 아니라 「0건 갱신」으로 알리기 때문에, 반환값을 보지 않으면 실패가 성공처럼 지나간다. 실제 사고의 상당수가 락을 안 걸어서가 아니라 이 반환값을 안 봐서 난다.

여기까지 해도 남는 문제가 있다. 인기 상품 하나에 요청이 몰리면 그 행 자체가 직렬화 지점이 된다. 락이 정확하게 동작할수록 대기 줄이 길어지는 구조라, 정확성 문제가 처리량 문제로 바뀔 뿐이다. 그때는 재고를 여러 행으로 쪼개거나, 인메모리 카운터로 선점만 먼저 처리하고 DB에는 확정분만 반영하는 구조로 넘어간다. 후자의 구현과 그 한계는 캐시 무효화와 동시성의 「분산 락」 절에 있다 — 그 글은 Redis 락을 세운 뒤 정합성의 최종 확정은 DB로 넘긴다는 결론으로 끝난다.

⚠️ 그 글의 「락」과 이 글의 「락」은 다른 물건이다. 그쪽은 만료 시간을 건 Redis 키라 시간 가정 위에 서 있고, 이쪽은 트랜잭션 경계에 묶인 DBMS의 행 잠금이다.

Q. SERIALIZABLE이 가장 안전한데 왜 기본값은 READ COMMITTED인가

대부분의 트랜잭션에는 그만한 보장이 필요 없고, 그 보장은 범위 단위로 값을 치르기 때문이다. SERIALIZABLE은 읽은 데이터의 갱신뿐 아니라 그 범위에 새 행이 들어오는 것까지 막는다. 잠기는 단위가 행에서 범위로 커지면 동시 처리량이 떨어지고, 락 경합이 늘면서 블로킹과 데드락 발생률도 함께 오른다.

세 번째가 실제로 사고가 나는 자리다. 「읽고 → 옮기고 → 지운다」 순서로 도는 배치는 두 SQL이 모두 정상 종료하기 때문에 로그에 아무 흔적도 남지 않은 채 데이터가 사라진다.

그래서 처방은 전역 설정을 올리는 쪽이 아니다. 문제가 되는 트랜잭션을 특정한 뒤 둘 중 하나를 쓴다. 하나는 그 트랜잭션에 한해 격리수준을 최상위로 지정하는 것이고, 다른 하나는 지울 대상을 아래처럼 못 박는 것이다.

-- 옮긴 키만 지운다 — 격리수준이 무엇이든 범위가 흔들리지 않는다
DELETE FROM staging_tbl
 WHERE staging_id IN (:movedIds);

뒤쪽이 대체로 낫다. 격리수준을 올린다는 것은 읽은 범위를 DBMS가 트랜잭션 종료까지 붙들고 있게 만드는 선택이다. 대상을 못 박는다는 것은 그 정보를 애플리케이션이 이미 갖고 있으니 DBMS에 짐을 지우지 않겠다는 뜻이다. 옮긴 키 목록이 배치 손에 남아 있다면 뒤쪽이 성립하고, 치르는 성능 대가도 훨씬 작다.

Q. 느린 쿼리는 안 보이는데 서비스 전체가 느리다. 무엇을 의심하나

개별 쿼리가 다 빠른데 전체가 느리면 원인은 쿼리 실행이 아니라 그 앞뒤에 있다. 후보는 두 개고, 확인 방법이 서로 다르다.

두 후보를 구분하는 기준은 CPU가 타는가 아니면 노는가다. 파싱 부하는 CPU를 태우고, 락 경합은 CPU가 한가한데도 응답이 밀린다. 이 한 가지만 봐도 절반이 갈린다.

파싱 부하가 확인됐는데 ORM을 쓰고 있다면 두 자리를 본다. 동적 쿼리를 문자열로 조립하는 구간, 그리고 IN 절 파라미터 개수가 요청마다 달라지는 구간이다. 후자는 프레임워크가 바인딩을 제대로 하고 있어도 발생한다 — 개수가 다르면 SQL 텍스트 자체가 달라지기 때문이다.

락 경합 쪽은 SQL 튜닝으로 풀리지 않는다는 점이 중요하다. 쿼리는 원래 빨랐고, 문제는 그 쿼리가 불필요하게 긴 트랜잭션 안에 들어 있다는 것이다. 트랜잭션 경계 안에서 외부 API를 부르거나 파일을 만지거나 사람의 응답을 기다리는 코드를 밖으로 빼는 것이 처방이고, 이것은 쿼리를 한 글자도 건드리지 않는 작업이다.

정리

이 시리즈를 관통하는 판단 기준은 세 개다.

세 번째가 가장 늦게 배운다. 앞의 두 기준은 잘못 고르면 느려지거나 에러가 나서 스스로 드러나지만, 세 번째를 놓치면 시스템은 아무 문제 없이 계속 돌면서 데이터만 조금씩 틀어진다. 격리수준을 잘못 잡은 배치도, rowcount를 안 본 재고 차감도, 동기화를 빠뜨린 반정규화 컬럼도 전부 정상 종료한다.

그래서 설계를 끝낼 때 마지막으로 물어야 할 것은 「이게 빠른가」가 아니라 **「이게 틀렸을 때 무엇이 그것을 알려 주는가」**다. 답이 없으면 그 자리에 대사 쿼리나 검증 배치를 하나 만들어 둔다. 몇 달 뒤에 어긋난 값의 출처를 거슬러 올라가는 것보다 그 편이 싸다.