핵심 답변

트랜잭션(Transaction)은 데이터베이스 생태계에서 단일 논리적 기능 단위이자 작업이 수행되어야 하는 최소 쪼개질 수 없는 연산 단위입니다. 여러 쿼리 작업 개수와 상관 없이 전부 다 성공적으로 끝나야만 반영되며(Commit), 단 하나라도 중간 단계 작업에서 꼬이거나 에러가 터지면 모든 조각이 아예 작업 전 초기 진입 상태로 백지화 복원(Rollback)되는 안정성 확보를 위한 DB의 근본 구조입니다.

꼬리 질문

• Q. Commit과 Rollback 연산에 대해 자세히 말해주세요.
  • A: Commit은 모든 DB 내부 쿼리 조각 작업이 온전하게 완료되어 영원히 무결성 디스크 공간에 상태를 저장반영(승인) 하겠다는 연산입니다. Rollback은 해당 쿼리 중 일부 결함이 나타났기 때문에 이전의 무결했던 마지막 온전한 상태 라인으로 강제로 시간여행 취소하겠다는 연산입니다.

핵심 답변

우리가 코드를 적힌 위상 순서 (SELECT -> FROM -> WHERE)와 다르게 데이터베이스 옵티마이저가 체감하여 파싱 긁어다 쓰는 절대 실행 연산 논리 순서는 따로 정해져 있습니다. [ 1. FROM(어디서) -> 2. ON, JOIN -> 3. WHERE(일단 걸러) -> 4. GROUP BY(묶어) -> 5. HAVING(묶은 곳 조건) -> 6. SELECT(원하는 칼럼 추출 결정) -> 7. DISTINCT -> 8. ORDER BY(최종 출력 정렬) ] 순으로 이어집니다.

꼬리 질문

• Q. WHERE 조건절 안에 SELECT 뭉치에서 명명 지정한 별칭(Alias 명)을 쓰면 구문 오류를 반환하는데, 이유가 무엇인가요?
  • A: 위 실행 순서 때문입니다. 별칭을 확정 짓는 SELECT 동작이 발동되기 한참 이전에 WHERE 로직이 먼저 빡세게 탐색 필터를 돌고 넘기기 때문에 컴파일러 엔진은 아직 별명을 부여받지 못한 이름이라 인식하지 못해 터집니다. (반면 ORDER BY에서는 별칭 사용이 정상 지원됩니다.)

핵심 답변

어떤 DB의 트랜잭션이든 절대 안전함을 위해 보장해야 하는 4대 원칙 묶음입니다.

• A (원자성, Atomicity): 전체 성공(Commit) 아니면 전체 실패(Rollback), 작업의 파편화 중간 상태 불허
• C (일관성, Consistency): 트랜잭션 완료 후에도 DB의 구조적, 논리적 제약 조건 등 스키마 결함이 일관적으로 완벽 유지되어야 함
• I (격리성, Isolation): 동시에 몰려 실행되는 트랜잭션 수많은 것들은 서로 끼어들어 연산을 침범 엿보거나 방해 불가능
• D (지속성, Durability): 성사된 트랜잭션 데이터 변경 사항은 서버가 다운 폭발하더라도 디스크에 영원 저장

꼬리 질문

• Q. 이 4개 중 완벽히 보장하기 가장 힘든 특성은 무엇이며, 현실적인 타협책은?
  • A: 타 방식 스레드 차단을 가장 심각하게 요구하는 **I(격리성)**입니다. 완벽한 직렬 격리 보장성(Serializable)을 잡으면 DB 동시 데이터 엑세스 성능이 급하락해 서비스가 터집니다. 따라서 현실에선 트랜잭션 단위별 격리 수준(Isolation Level, 예: Read Committed 등)을 4단계로 나눠 적당한 퍼포먼스 타협 최적화 설정을 시전합니다.

핵심 답변

DB 테이블의 초고속 검색(조회, SELECT) 성능 스피드를 미친듯이 향상시키기 위해, 특정 기준 데이터 컬럼으로 책의 맨 뒷부분 '색인(찾아보기)' 처럼 정렬된 물리적인 포인터 구조(B-Tree 계열)를 몰래 따로 형성해두고 관리하는 스키마 구조 개체 중 하나입니다.

꼬리 질문

• Q. 인덱스는 내부적으로 어떤 자료구조를 주로 쓰나요?
  • A: 전통적인 RDBMS 환경에서는 B-Tree 및 B+Tree 구조를 주력 기본으로 사용합니다. 이는 방대한 데이터를 디스크 깊이에 덜 접근하고(뎁스가 얕게) 범위를 선형적으로 이어 다중 접근 탐색에(Range Scan) 엄청난 효율 성능을 보장하기 때문입니다.

핵심 답변

풀 테이블 스캔(Full Table Scan) 즉, 테이블의 모든 100만 개 넘는 공간을 무식하게 처음부터 줄줄이 전부 뒤져가며 조건 데이터 1개를 찾는 최악 디스크 낭비 방식을 회피하고, 트리 탐색 구조를 추적해 거의 O(log N) 탐색속도로 찰나에 색인 주소를 찾아 디스크 I/O 비용을 비약적으로 줄이기 위해서입니다. WHERE, JOIN, ORDER BY 구문 체감을 폭발적으로 올려줍니다.

꼬리 질문

• Q. 그럼 모든 컬럼에 인덱스를 걸어버리면 좋지 않나요?
  • A: 절대 안됩니다. 인덱스를 만들면 원본 텍스트 크기의 인덱스 추가 트리가 생성되므로 심각한 저장소 공간 낭비가 발생하며, 무엇보다 INSERT, UPDATE, DELETE 조작 시 정렬 구조 변경 오버헤드가 곱절로 소모되어 쓰기 최적화 측면에서 서비스 파멸을 가져옵니다.

핵심 답변

인덱스는 SELECT (조회)를 위한 무기로, 반대의 DML 성능 (INSERT, UPDATE, DELETE) 작업을 밥 먹듯이 할 경우 파멸적인 성능 저하 트리 균형 파괴를 일으킵니다. 데이터 조작이 일어날 때마다 해당 컬럼의 내부 B-Tree 노드 정렬 위치 또한 물리적 이동 분할 등을 싹 갈아 엎어야 하기 때문에 오히려 속도가 끔찍하게 느려집니다. 그 외 분포도가 매우 낮은 (성별 컬럼 등) 중복 투성이 데이터에 인덱싱을 걸면 쓸데 없이 탐색 영역만 커집니다.

꼬리 질문

• Q. 카디널리티(Cardinality)라는 개념과 인덱스의 관계는?
  • A: 카디널리티란 한 컬럼이 가지는 '값의 유니크한 다양성, 고유 중복 강도 분포도'를 뜻합니다. 인덱스 후보를 정할 땐 이 수치가 높은 녀석(예: 주민등록번호)을 축으로 걸어야 제대로 된 탐색 분기가 일어나지, 낮은 부류(예: 남녀 성별)에 걸면 의미가 퇴색됩니다.

핵심 답변

가장 큰 차이는 실제 데이터 행(디스크 레코드)이 인덱스 자체 정렬 기준에 맞춰 함께 섞여서 물리 정렬되어 있는지 위치 유무입니다.

• 클러스터드 인덱스: 테이블 당 단 1개만 PK(기본키) 체제로 부여 가능하며 인덱스의 잎단(리프 노드) 자체가 실제 모든 실데이터를 품고 순차로 정렬 보관되어 최강의 성능(Range Scan)을 냅니다.
• 논클러스터드 인덱스: 데이터를 건드리지 않고 별개의 겉보기 메모리 공간에 포인터 주소(혹은 또다른 인덱스 참조값)만으로 보관 구성하므로 수십 개를 만들 수 있지만 무조건 조회 단계를 2번 이상 거쳐야 해서 느립니다.

꼬리 질문

• Q. 커버링 인덱스는 무엇인가요?
  • A: 원래 일반적인 SELECT A, B FROM 테이블 WHERE A = ? 상황에서 A에만 인덱스가 걸려있으면 B값을 채우기 위해 굳이 디스크를 한 번 더 랜덤 I/O 읽어와야 하지만, B까지 전부 인덱스로 박아버려 아예 인덱스 데이터 자체만으로 쿼리 전체를 반환시켜 디스크 무작위 I/O 자체를 0으로 증발시키는 최강 튜닝 기술입니다.

핵심 답변

관계형 DB의 뼈대 테이블 스키마 설계 과정에서, 데이터가 심하게 중복 꼬여 있거나 삽입 삭제 쿼리를 날릴 때 원치 않는 의존 데이터까지 털려버리는 이상(Anomaly) 충돌 부작용 현상을 막기 위해 릴레이션 관계 테이블들을 잘게 쪼개는 기법입니다.

꼬리 질문

• Q. 제 1, 2, 3 정규형에 대해 간단히 설명해주세요.
  • A: 1정규화는 모든 컬럼 속성이 다중 값을 갖지 않고 단일 '원자 비무결성'만 가지도록 다 찢는 것이고, 2정규화는 1형 위에서 멀티 기본키 중 일부 키본키에만 종속되어 놀아나는 놈을 자르는 것, 3정규화는 2형 베이스에서 기본키가 아닌 동네 컬럼끼리 종속성 연결을 끊어 분단시키는 것입니다.

핵심 답변

여러 찢어진 테이블의 데이터를 논리 조건으로 유연하게 하나로 묶어 결합하는 데이터 엮기 연산입니다. 특성에 따라 교집합 매칭된 값만 살리는 INNER JOIN, 기준이 되는 쪽 테이블에 맞춰 다 살리고 남는 곳은 NULL 구멍을 뚫든 엮어 뽑아주는 포용 지향적 OUTER JOIN(LEFT, RIGHT 등), 아무런 논리 기준 없이 A와 B의 전체 갯수 무지성 N*M 데카르트 곱 연산으로 폭등 방출시키는 CROSS JOIN이 있습니다.

꼬리 질문

• Q. OUTER JOIN 사용시 조심해야 할 점은 무엇인가요?
  • A: 결과 기준을 잡은 본체 테이블 내용에 맞물리지 않는 대상 컬럼들은 전부 뻥 뚫려 NULL 채움 처리가 이뤄집니다. 통계 연산을 할 때 COUNT 등에 NULL 늪이 연산 오류를 주지 않도록 로직 처리에 방어코드를 유의해야 합니다.

핵심 답변

두 개 다 원하는 데이터를 쿼리 속에서 제어 골라내어 필터링 치는 예약어입니다만 동작 순서 타이밍(범주)이 전적으로 다릅니다. WHERE은 데이터를 묶어 분류 그룹화(GROUP BY) 하기 전에 개별 단일 레코드 라인 단위들에 대해 조건부를 달아 미리 필터링 할 때 쓰고, HAVING은 그렇게 덩어리 묶음을 짓고 난 후의 연산 종합 집계 단위체(SUM, COUNT 단위 등)가 특정 기준을 충족하는지 필터링하기 위해 사용됩니다.

꼬리 질문

• Q. 집계 결과 조건절이 아니라 단일 레코드 필터링에 HAVING을 실수로 쓰면 쿼리에 문제 되나요?
  • A: DB 엔진마다 해석 여부가 다르지만 오라클 등에선 엄밀히 집계 그룹 단위에 적용하는 특화 필터이기 때문에 치명적 문법 에러 반환을 합니다.

핵심 답변

트랜잭션은 데이터베이스를 조작하는 논리적 작업 단위입니다. ACID 특성이란 안전한 트랜잭션 수행을 보장하는 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability)을 일컫습니다. 원자성은 모두 성공하거나 모두 실패해야 함을, 일관성은 트랜잭션 전후에 데이터의 무결성이 유지되어야 함을, 고립성은 동시에 실행되는 트랜잭션들이 서로 간섭하지 않음을, 지속성은 성공한 트랜잭션 결과는 영구적으로 반영됨을 의미합니다.

꼬리 질문

• Q. 트랜잭션 격리 단위(Isolation Level)와 발생할 수 있는 문제들에 대해 설명해주세요.
  • A: Read Uncommitted, Read Committed, Repeatable Read, Serializable 4단계가 존재합니다. 각 단계에 따라 Phantom Read, Non-Repeatable Read, Dirty Read 같은 문제가 발생할 수 있습니다.
• Q. 스프링에서 @Transactional은 어떻게 동작하나요?
  • A: AOP 기반으로 프록시 객체가 생성되어 메서드 실행 전 트랜잭션을 시작하고, 종료 시 커밋 혹은 런타임 예외 시 롤백을 수행합니다.