티스토리 뷰
반응형
들어가며
데이터베이스는 일종의 API이다. 그리고 이 API를 사용하기 위해 우리는 SQL이라는 언어를 사용한다. 그렇다면 SQL은 어떤식으로 서버에서 데이터베이스로 전달되고, 이들간의 연결은 어떻게 맺어지는걸까?
이 글에서는 DB와 연결을 맺고, 이를 편리하게 사용하도록 도와주는 기술들이 어떤 흐름속에서 탄생했는지 알아보고자 한다. 더 구체적으로는, Java에서 DB와 관련된 기술이 어떤 이유로 탄생했고 장/단점은 무엇인지 간략하게 알아볼 예정이다.
1. 처음에 SQL을 실행하던 방식
1960~80년대, 초창기 애플리케이션들은 데이터베이스와 직접적으로 연결을 맺고 SQL을 실행했다. 따라서 프로그래머들은 직접 TCP/IP 소켓을 관리하며 SQL을 작성 및 송수신하고, DB 연결을 수동으로 여닫아야 했다.
Socket dbConnection = new Socket("db-server", 5432);
OutputStream out = dbConnection.getOutputStream();
InputStream in = dbConnection.getInputStream();
// 직접 SQL을 송수신
out.write("SELECT * FROM users".getBytes());
문제점
- 직접 네트워크 연결을 관리해야 한다.
- SQL 실행 방식이 표준화되지 않아, DB 별로 다른 SQL을 작성해야한다.
- 메모리와 성능 최적화가 어렵다.
- 보안이 취약하다. (SQL 인젝션에 취약하며 인증 과정이 없음)
위와 같은 문제들로 인해 데이터베이스와 표준화된 방식으로 연결하는 API가 필요해졌고, 여기서 JDBC가 등장한다.
2. JDBC(Java Database Connectivity)의 등장
JDBC는 자바에서 DB에 연결할 수 있도록 표준 API를 제공하는 라이브러리로, 1996년 Java 1.1 출시와 함께 등장했다. JDBC의 등장으로, 개발자는 DB와 네트워크 연결을 직접 관리하지 않고 JDBC 드라이버를 통해 SQL을 실행할 수 있게 됐다.
Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/mydb", "user", "password");
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM users");
while (rs.next()) {
System.out.println(rs.getString("name"));
}
rs.close();
stmt.close();
conn.close(); // 반드시 닫아야 함
개선점
얼핏보면 큰 차이가 없다고 느낄수도 있으나, JDBC의 사용은 아래와 같은 수많은 이점들을 가져다줬다.
- DB별로 다른 네트워크 프로토콜을 숨겨줌 → 개발자는 신경 쓸 필요가 없다.
DB가 MySQL이든, PostgreSQL이든, DriverManager가 적절한 드라이버를 찾아서 실행해준다. 예를 들어, MySQL을 사용하면 내부적으로 com.mysql.cj.jdbc.Driver가 동작하는 방식이다. - SQL 실행 과정의 표준화
Statement 객체를 사용해서 SQL을 실행하고 ResultSet을 통해 결과를 받아오는 구조로, DB가 달라도 코드를 크게 바꿀 필요가 없다. - 네트워크 통신을 자동으로 처리
JDBC 드라이버가 내부적으로 네트워크 패킷을 생성하고, 결과를 변환해서 반환한다. 따라서 개발자는 단순히 ResultSet에서 데이터를 가져오기만 하면 된다. - DB 드라이버 교체만으로 다른 DBMS(MySQL, PostgreSQL, Oracle 등) 지원 가능
예를 들어, MySQL을 쓰다가 PostgreSQL로 바꾸려면 jdbc:mysql:// → jdbc:postgresql:// 로만 변경하면 된다. - 보안 및 성능 개선 가능
PreparedStatement를 사용하면 SQL Injection을 방지할 수 있고, Batch 처리를 활용하면 대량 데이터 입력 성능을 최적화 할 수 있다.
문제점
JDBC가 등장하면서 DB 연결 방식이 표준화되고 네트워크 관리 부담이 줄었지만, 여전히 문제점이 존재했다.
- 매번 Connection을 열고 닫아야 해서 성능이 나쁘다.
DB 커넥션을 생성하는 비용이 크기 때문에 동시 접속자가 많아지면 부하가 심해지고, 프로그래머에게도 반복된 작업을 요구한다. 이 문제점은, 추후 설명 할 커넥션 풀 (HikariCP)의 등장 배경이 된다. - SQL을 직접 작성해야 해서 유지보수가 어렵다.
JDBC는 SQL을 직접 작성하기 때문에, 테이블이 변경될 때마다 SQL을 수정해야 한다. 이는 추후 설명 할 JPA(Hibernate)의 등장 배경이 된다.
--
반응형
'개발' 카테고리의 다른 글
| 도메인 위주의 API 설계와 CamelCase 응답 (6) | 2025.07.10 |
|---|---|
| [트러블슈팅] Soft delete와 카카오 연결끊기(unlink) 400 오류 (1) | 2025.07.10 |
| [Python] Pipenv 부터 AWS Lambda 배포까지 (2) (1) | 2025.07.10 |
| [Python] Pipenv 부터 AWS Lambda 배포까지 (1) (0) | 2025.07.10 |
| [JPA] JPA 연관관계 간단 정리(ManyToOne, OneToMany) (0) | 2024.07.24 |
댓글