🔌[JDBC] JDBC 개요 및 데이터베이스 연결 원리

1. JDBC(Java Database Connectivity) 란 ?

• 표준 인터페이스: 데이터베이스 종류(MySQL, Oracle, PostgreSQL 등)에 관계없이 동일한 자바 코드 구성을 사용하여 DB 작업을 처리할 수 있게 해줌
  • 자바 애플리케이션이 관계형 데이터베이스(RDBMS)와 통신하여 데이터를 주고받을 수 있도록 자바 표준(Java SE)에서 제공하는 표준 API(인터페이스 모음).
• 드라이버(Driver) 기반 구조: 각 데이터베이스 제조사(Oracle, MySQL 등)는 자바 표준 JDBC 인터페이스를 구현한 JDBC 드라이버를 제공한다. 이를 통해 애플리케이션 코드를 크게 바꾸지 않고도 DB를 교체할 수 있음.
• 등장 배경: DB 종류마다 내부 통신 방식과 명령어 처리 방식이 다른데, JDBC는 이를 추상화(표준화)하여, 개발자가 특정 DB 기술에 완전히 종속되지 않고 동일한 코드 구조로 DB를 다룰 수 있게 해줌.
  • 자바 애플리케이션이 JDBC를 이용해 데이터베이스에 연결하고, SQL을 실행한 뒤, 자원을 해제하기까지의 전체 수명주기는 아래 2, 3번 목차 확인
• 내용 요약 정리는 여기서.

+---------------------------------------------------+
|               Java Application                    |
+---------------------------------------------------+
                          | (JDBC API 호출)
                          v
+---------------------------------------------------+
|               DriverManager                       |
+---------------------------------------------------+
                          | (구현체 찾아 할당)
                          v
+---------------------------------------------------+
|         JDBC Driver (MySQL, Oracle 등)           |
+---------------------------------------------------+
                          | (TCP / IP Socket 통신)
                          v
+---------------------------------------------------+
|                  Database Server                  |
+---------------------------------------------------+

---

2. 데이터베이스 연결 원리 (단계별)

JDBC가 실제 DB와 연결되고 소통하는 과정은 다음과 같은 메커니즘으로 동작한다.

1단계: JDBC 드라이버 로드 (Driver Loading)

• 개념:  데이터베이스 제조사(MySQL, Oracle 등)가 제공하는 JDBC 드라이버 클래스를 JVM 메모리에 올리고, DriverManager에 등록하는 단계
• 동작 원리:
  • 과거 방식 (명시적 로드): 클래스 로더가 해당 클래스를 메모리에 로딩하면서, static 블록 내에서 DriverManager.registerDriver()가 자동으로 호출된다.
  • 최신 방식 (JDBC 4.0 이상 / 자동 로드): Java의 SPI(Service Provider Interface) 덕분에 클래스패스(프로젝트의 의존성 .jar)에 벤더 드라이버가 포함되어 있다면 Class.forName()을 생략해도 DriverManager가 드라이버를 자동 탐색하여 등록한다.

💡 드라이버(Driver)란? 각 DB 제조사(MySQL Connector/J, Oracle OCI 등)가 JDBC 인터페이스를 실제 구현한 클래스 라이브러리(.jar).

💡과거 방식(명시적 로드) 자세히

1. Class.forName() 역할: 문자열로 지정된 드라이버 구현체 클래스 이름(예: MySQL 드라이버)을 찾아 JVM 메모리(Method Area)에 동적으로 로딩
2. static 초기화 블록 실행: 클래스 로더가 해당 클래스를 메모리에 로딩하면서, 클래스 내부의 static { ... } 블록이 자동으로 실행(호출)된다.
3. DriverManager에 자동 등록: 드라이버 클래스의 static 블록 안에 DriverManager.registerDriver(new Driver()) 코드가 작성되어 있다. 즉, 개발자가 직접 등록 메서드를 호출하지 않아도 클래스 로딩만으로 DriverManager에  드라이버가 자동으로 등록된다.

Class.forName("com.mysql.cj.jdbc.Driver");

2단계: 커넥션 요청 및 네트워크 연결 (TCP Handshake)

• DriverManager.getConnection(url, user, password)를 호출한다.
• URL 분석(프로토콜 확인 및 드라이버 선택):
  
  • DriverManager는 식별자를 읽고, 등록된 드라이버들 중 해당 프로토콜(jdbc:mysql)을 처리할 수 있는 드라이버를 찾아 커넥션 수립을 위임한다. (예: MySQL 드라이버에게 연결을 위임)
• TCP/IP 소켓 연결:
  • 자바 애플리케이션과 DB 서버 사이에 OS 커널의 TCP 소켓 통신을 시작한다.
  • OS 커널 레벨에서 DB 서버(Port: 3306 등)와 TCP/IP 3-Way Handshake 과정을 거쳐 가상의 통신 파이프라인(소켓)이 개설됨.

// 네트워크 처리와 동시에 3단계(인증 및 객체 생성)도 연속적으로 일어남
String url = "jdbc:mysql://localhost:3306/testdb?serverTimezone=Asia/Seoul";
Connection con = DriverManager.getConnection(url, "user", "password");

ℹ️ 프로토콜과 식별자 차이점 (+ 자원위치)
식별자: 찾고자 하는 대상이 정확히 어디에 있는 누구인지에 대한 정보 (예: URL, URI, ID, 변수명 등)
프로토콜/서브 프로토콜: 통신 규약. 어떻게 데이터를 주고받을 것인가에 대한 정보 (예: HTTP, HTTPS, FTP, TCP, jdbc:mysql 등)
자원 위치(식별 정보): //localhost:3306/testdb에 해당. 내 컴퓨터(localhost)의 3306 포트에 있는 testdb라는 이름의 데이터베이스라는 실제 대상 위치를 식별

3단계: 인증 및 Connection 객체 생성

• 결과: DriverManager를 통해 DB와의 실질적인 네트워크 커넥션(con)을 획득한다.
• 뚫린 통신선을 통해 입력받은 사용자 계정(user, password)을 보내 DB 서버에서 사용자 인증을 거친다.
• 인증이 완료되면 DB 서버는 해당 소켓 연결에 대한 세션(Session)을 생성하고, 자바에는 이에 대응하는 Connection 인터페이스 구현체(DB 세션 정보) 객체를 반환한다.
  • getConnection()이 null이 아닌 객체를 반환했다는 것은 자바-DB 간 TCP 네트워크 연결 및 세션 생성이 완료(성공)되었음을 의미한다.

---

3. SQL 실행 및 자원 반납 흐름

연결이 완료된 후 DB와의 작업은 아래 흐름으로 진행됨.

1단계: Statement 객체 생성 (Statement / PreparedStatement)

• SQL 문장을 DB에 전달하기 위한 명령어 통로(Statement)를 생성한다.
• Statement: 
  • 단순 문자열 SQL을 실행 (con.createStatement()).
  • 단발성 SQL 실행 시 사용된다.
  • 하드코딩된 문자열 쿼리는 컴파일 시점 오타 검증이 불가능함. (매번 SQL 파싱/최적화 과정 거침)
• PreparedStatement:
  • DB 엔진에서 SQL을 *미리 컴파일(Pre-compile) 처리함.
  • 이후 ?(위치 홀더/포지션 아규먼트)를 통해 바인딩 변수를 전달, 동적으로 파라미터를 치환한다 (con.prepareStatement(sql))
  • 위 지원을 통해 SQL Injection 방지 및 재사용을 통한 성능 향상에 유리하다.
• 💡 Tip(Java 텍스트 블록) """ ... """ 문법을 사용해 가독성 높은 다중 행 SQL 쿼리 작성하.

String sql = "SELECT * FROM coffees WHERE price > ?";
PreparedStatement pstmt = con.prepareStatement(sql);
pstmt.setInt(1, 3000); // 파라미터 치환

ℹ️ DB의 쿼리 실행 과정 (컴파일 과정)

1. Parsing (구문 분석 & 컴파일):
   • SQL 문법(Syntax)이 맞는지 검사한다.
   • 테이블명이나 컬럼명이 실제로 DB에 존재하는지 확인.
2. Optimization (최적화 & 실행 계획 생성):
   • 어떤 인덱스를 탈지, 어떤 순서로 조인할지 계산하여 가장 빠른 실행 경로(Execution Plan)를 결정하고 컴파일된 바이너리를 캐시에 저장한다.
3. Execution (실행):
   • 최적화된 계획을 바탕으로 실제 데이터를 읽어온다.

[1. Parsing (구문 분석)] ──> [2. Optimization (최적화)] ──> [3. Execution (실행)]

✨ Statement vs PreparedStatement 차이 (+ Pre-compilation 이점 설명)

 

1) 일반 Statement (매번 새로 컴파일)

• userId가 달라질 때마다 전체 SQL 문자열이 바뀌므로 DB는 이를 전혀 새로운 쿼리로 인식한다.
• 매번 1단계(Parsing) $\rightarrow$ 2단계(Optimization)를 다시 수행하므로 DB 서버의 CPU 자원을 많이 소모함.

// 매번 구문 분석 + 최적화 + 실행 과정을 새로 거침
String sql = "SELECT * FROM users WHERE id = '" + userId + "'";
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery(sql);

 

2) PreparedStatement (Pre-compilation 활용 자세히)

• con.prepareStatement(sql)을 호출하는 시점에 위치 홀더(?)가 포함된 SQL 뼈대(구조)를 DB에 먼저 보낸다.
• DB는 이 뼈대 쿼리를 딱 한 번만 Pre-compilation(사전 컴파일)하여 메모리(Execution Cache)에 올려둔다.
• 이후 ?에 다른 값이 들어와도 DB는 이미 만들어둔 실행 계획(Execution Plan)을 그대로 재사용하므로 Execution(실행) 단계만 빠르게 거친다.
• 요약: SQL의 뼈대를 미리 컴파일하여 최적의 실행 계획을 생성하고, 이후 변수(?)만 바인딩

// 1. 쿼리 뼈대만 보내서 DB에 미리 컴파일(Pre-compile)해둠
String sql = "SELECT * FROM users WHERE id = ?";
PreparedStatement pstmt = con.prepareStatement(sql);

// 2. 파라미터 값만 바인딩해서 바로 실행 (Parsing & Optimization 생략)
pstmt.setString(1, "user1");
ResultSet rs1 = pstmt.executeQuery();

pstmt.setString(1, "user2");
ResultSet rs2 = pstmt.executeQuery();

 

3) Pre-compilation이 가져오는 핵심 이점

• 성능 향상 (Performance):
  • 동일한 구조의 쿼리가 반복 실행될 때 DB의 Parsing 및 실행 계획 생성 비용을 대폭 줄여준다.
• SQL Injection 방지 (Security):
  • DB 입장에서 SQL의 구조(뼈대)는 이미 Pre-compilation 완료된 상태.
  • 나중에 ? 자리에 어떤 문자열(' OR '1'='1)이 들어오더라도 DB는 이를 실행 가능한 명령어로 해석하지 않고 단순 데이터(값)로만 처리하므로 SQL 인젝션 공격이 불가능해진다.

2단계: SQL 전달 및 실행

• 개발자가 자바 코드 내에 하드코딩한 Raw SQL 문자열(쿼리)을 네트워크 소켓을 통해 DB 서버로 전송하고 실행 결과를 처리한다.
• executeQuery(): SELECT 조회 쿼리 실행 ➔ 데이터 집합인 ResultSet 객체 반환.
• executeUpdate(): INSERT, UPDATE, DELETE 등 DML 실행 ➔ 영향받은 행(Row)의 개수(int) 반환.

3단계: 통신 버퍼 및 커서 제어 (결과 수신 — ResultSet)

• DB가 보낸 결과 데이터는 OS의 Read/Write 네트워크 버퍼를 거쳐 자바 메모리로 전달다.
• 💡 ResultSet 커서 제어:
  • 커서(Cursor) 방식으로 동작하고, 객체 생성 시 초기 커서는 첫 번째 레코드 이전(beforeFirst)을 가리킨다.
  • rs.next(): 커서를 행 단위로 한 칸씩 밑(다음 행)으로 내리며 존재 여부를 반환(boolean)하고, 행 데이터를 읽어온다.
  • rs.getString(), rs.getInt() 등: 개발자가 직접 각 컬럼 값을 자바 객체의 필드에 일일이 매핑한다.
  • 그 외 rs.last(), rs.beforeFirst() 사용해서 커서 위치를 정밀하게 이동하여 읽기 가능.

4단계: 자원 해제 (Close / 4-Way Handshake)

• 순서 규칙: 사용한 연결 자원의 메모리 점유를 생성된 역순(ResultSet ➡️ Statement ➡️ Connection)으로 해제한다.
• 이유(필수성): DB 커넥션(Connection)및 Statement, ResultSet 등 객체는 시스템의 하드웨어 자원(네트워크 소켓, DB 세션 메모리)을 직접 소비한다.
  • 작업이 종료되면 반드시 close()를 호출하여 자원을 반납해야 함. (이때 TCP 소켓 종료를 위한 4-Way Handshake가 일어남.)
• Java 7 이상에서는 중첩 try-with-resources 구문을 사용하여 안전하게 자동 close (+ 예외처리) 를 처리하는 것이 표준

💡 왜 반드시 해제해야 할까?

 

1) 해제해야 하는 이유

• DB Connection, Statement 등은 단순 자바 객체를 넘어 외부 OS의 소켓(Socket) 자원 및 DB 서버의 세션 메모리를 직접 점유한다.
• 사용 후 닫지 않으면 커넥션 누수(Memory/Connection Leak)가 발생하여 DB 서버에 영향을 줄 수 있다.

2) 안전한 해제 방법: try-with-resources (Java 7+)

• 과거 finally 블록에서 일일이 .close()를 호출하던 방식 대신, 아래와 같이 작성하는 것이 표준 (메모리 반환 및 자동 close 처리)
• 쿼리 실행 시 Checked Exception인 SQLException 처리 필요하.

String url = "jdbc:mysql://localhost:3306/testdb";

// AutoCloseable을 구현한 객체들을 try(...) 안에 선언
try (Connection con = DriverManager.getConnection(url, "root", "1234");
     PreparedStatement pstmt = con.prepareStatement("SELECT * FROM coffees WHERE price > ?")) {
    
    pstmt.setInt(1, 3000);
    
    try (ResultSet rs = pstmt.executeQuery()) {
        while (rs.next()) {
            System.out.println(rs.getString("COF_NAME"));
        }
    }
} catch (SQLException e) {
    e.printStackTrace();
}
// try 블록을 벗어나면 rs ➡️ pstmt ➡️ con 순서로 자동 close() 호출
// 이 과정에서 TCP 4-Way Handshake가 발생하며 소켓이 닫힘

---

4. 핵심 구성 요소 요약

JDBC API는 주로 java.sql 패키지에 정의되어 있으며, 주요 객체는 다음과 같다.

	역할
DriverManager	등록된 드라이버들을 관리하고, DB URL 정보, 계정 정보를 바탕으로 DB 커넥션을 생성함.
Driver	DB 제조사가 구현한 표준 JDBC 구현체. DB 고유 통신 프로토콜 처리.
Connection	DB와의 실질적인 소켓 연결(세션) 및 트랜잭션(commit/rollback) 제어.
Statement / PreparedStatement	SQL 문장을 파싱하고 실행할 수 있도록 전달함. (SQL 문을 실행하기 위한 객체)
ResultSet	SELECT 쿼리 결과를 테이블 형태로 저장(객체)하고 커서를 통해 조회함(한 행씩 읽어옴).

---

5. JDBC의 장단점 및 한계

👍 장점

• 자바 표준: 자바 생태계의 모든 데이터베이스 관련 기술의 근간이 됨.
• 높은 자유도: 데이터베이스 제어를 세밀하게 직접 다룰 수 있다.

👎 단점 및 한계

• 반복적인 보일러플레이트 코드: 커넥션 연결, 예외 처리(SQLException), 자원 해제 등의 코드가 매번 반복된다.
• SQL 중심 개발: 테이블 컬럼 매핑 및 결과 처리를 일일이 수동으로 코딩해야 하므로 생산성이 낮아진다.

ℹ️ 순수 JDBC (Raw SQL) 방식의 한계점 (추가 설명)

 

Raw SQL과 순수 JDBC만을 활용한 개발 방식은 DB 제어의 자유도는 높지만, 실제 서비스 개발에서는 다음과 같은 치명적인 한계가 존재합니다.

 

① 과도한 보일러플레이트 코드 (Boilerplate Code)

• 문제점: 쿼리 하나를 실행할 때마다 Connection 연결, Statement 생성, ResultSet 조회, Try-Catch-Finally 예외 처리 및 자원 반납(close()) 코드가 반복적으로 발생합니다.
• 결과: 비즈니스 로직보다 DB 연결/해제 관련 부수적인 코드가 전체 코드의 80% 이상을 차지하게 됩니다.

② 수동 매핑에 따른 높은 오류 가능성 및 낮은 생산성

• 문제점: SQL 실행 결과(ResultSet)를 자바 객체(DTO/Entity)로 변환할 때, 개발자가 컬럼명과 데이터 타입을 일일이 수동으로 코딩해야 합니다.
• 결과: 오타 발생 확률이 높고, 컴파일 시점에 오류를 잡지 못하며 단순 반복 작업으로 인해 개발 생산성이 급격히 떨어집니다.

// 테이블 컬럼이 20개라면 20줄의 매핑 코드를 수동으로 작성해야 함
User user = new User();
user.setId(rs.getLong("user_id"));
user.setName(rs.getString("user_name"));

 

③ SQL 텍스트 하드코딩과 컴파일 타임 검증 불가

• 문제점: SQL문이 자바 코드 내부에서 단순 문자열(String)로 취급된다.
• 결과: SQL 오타(예: SELEC * FROM ...)나 테이블/컬럼명 오류가 있어도 자바 컴파일러는 이를 검증하지 못하며, 애플리케이션이 실행되어 해당 코드가 호출되는 런타임 시점에서야 SQLException이 발생하며 터지게 됨.

④ 객체지향 모델과 관계형 DB 모델 간의 패러다임 불일치

• 문제점: 자바는 객체지향(상속, 참조, 연관관계) 중심 언어이고, DB는 관계형(테이블, PK/FK, 조인) 중심 구조.
• 결과: 객체 간의 연관관계(예: User가 Orders 리스트를 가짐)를 Raw SQL로만 표현하려고 하면 SQL이 복잡해지고, DB 중심의 데이터 구조에 맞춰 자바 객체 모델링이 오염되는 현상이 발생한다.

⑤ 영속성 컨텍스트(1차 캐시, 변경 감지 등)의 부재

• 문제점: JDBC는 단순히 쿼리를 DB에 던지고 결과를 받는 단방향 통신 도구에 불과하다.
• 결과: JPA처럼 1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기 지연, 변경 감지(Dirty Checking) 같은 고급 영속화 메커니즘이 전혀 없으므로, 데이터가 조금만 변경되어도 매번 직접 UPDATE SQL을 작성하여 실행해야 한다.

📊 상위 접근 기술과 기능 제공 비교표

• 아래는 순수 JDBC의 복잡성과 코드 중복 문제를 해결하기 위해 지속해서 상위 접근 기술을 제공하는 프레임워크들
• Spring JdbcTemplate: 연결 및 자원 해제, 예외 처리를 스프링이 대신 관리하여 보일러플레이트 코드를 획기적으로 줄여준다. 자동 RowMapper도 지원한다.
• SQL Mapper (MyBatis 등): SQL 문과 자바 객체를 연동하여 직관적으로 XML이나 애노테이션 기반 쿼리를 관리하게 해줌. (매핑 규칙 작성 등)
• ORM (JPA / Hibernate 등): 데이터베이스 테이블(구조 자체)을 자바 객체로 직접 정밀 매핑하여, SQL 대신 객체 중심 개발을 가능하게 함. 또한 QueryDSL, JPA (JPQL/Metamodel) 사용 시 컴파일 타임에 쿼리 오류 감지 가능

	Spring JdbcTemplate	MyBatis (SQL Mapper)	JPA (ORM)	JPA + QueryDSL
자원 해제 / 예외 변환 자동화	O	O	O	O
결과-객체 매핑 자동화	O (기본 매핑)	O (ResultMap)	O (ORM 정밀 매핑)	O (ORM 정밀 매핑)
컴파일 타임 SQL 오류 감지	✘ (문자열 SQL)	✘ (XML/문자열 SQL)	△ (QueryDSL 사용 시 가능)	O (자바 코드 쿼리)