[2회차] DB Connection은 왜 비쌀까? - DB, OS, Network의 관점에서 알아보기

[github-actions[bot]]

🚀 발표 주제

DB Connection은 왜 비쌀까? - DB, OS, Network의 관점에서 알아보기

---

📅 발표일

2026-06-08

🙋 발표자

초록

🗂️ 카테고리

💾 Database

📚 발표 자료

업로드 예정

🎥 발표 영상

업로드 예정

---

🎯 핵심 개념 요약

DB Connection은 단순히 애플리케이션 코드에서 생성되는 객체가 아니다.
dataSource.getConnection()을 호출하면 코드상으로는 Connection 객체 하나를 얻는 것처럼 보이지만, 실제로는 애플리케이션과 DB 서버가 통신할 수 있는 경로를 여러 계층에서 준비하는 과정이다.

Connection이 생성되기까지는 대략 다음 흐름이 필요하다.

Application Code
-> JDBC Driver
-> OS Socket
-> Network
-> DB Server Session

즉, Connection은 애플리케이션 코드, OS, 네트워크, DB 서버가 함께 만들어내는 통신 상태다. 그래서 Connection이 비싸다는 말은 단순히 “느리다”는 뜻이 아니라, 생성하고 유지하는 데 시간, 자원, 상태 관리 비용이 모두 든다는 뜻이다.

첫 번째는 Latency Cost이다.
새 Connection을 만들려면 먼저 TCP 연결이 필요하다. TCP 연결은 SYN -> SYN-ACK -> ACK 과정으로 만들어지고, 이때 네트워크 왕복 시간이 발생한다. 애플리케이션 서버와 DB 서버가 멀리 있을수록 이 왕복 비용은 더 커진다.

여기서 끝나는 것도 아니다. 보안 연결을 사용한다면 TLS/SSL Handshake가 추가되고, DB와 통신하기 위한 DB Protocol Handshake도 필요하다. 이후에는 사용자를 인증하고 권한을 확인하는 과정도 거친다. 즉, 실제 Query를 실행하기 전에 이미 여러 번의 협상과 왕복 통신이 발생한다.

두 번째는 Resource Cost이다.
Connection은 Java 객체처럼 보이지만, OS 입장에서는 Socket 기반 커널 자원이다. 하나의 Connection은 Socket, File Descriptor, Kernel Buffer 같은 자원을 사용한다.

DB 서버 입장에서도 Connection은 단순한 연결선이 아니다. DB는 새 Connection을 받아들이고, 사용자를 인증하고, 권한을 확인하고, 해당 클라이언트와 대화하기 위한 Session을 준비한다. 이 Session은 메모리를 사용하고, 이후 Query를 처리하기 위한 상태를 가진다.

따라서 Connection 하나를 만든다는 것은 애플리케이션에 객체 하나를 추가하는 일이 아니라, 양쪽 OS와 DB 서버에 실제 자원을 할당하는 일이다.

세 번째는 Coordination Cost이다.
Connection은 한 번 만들어진 뒤에도 상태를 가진다. OS는 TCP 연결 상태를 관리해야 하고, DB는 Session 상태를 관리해야 한다. Connection이 많아질수록 OS와 DB가 추적해야 할 상태도 많아진다.

예를 들어 DB는 각 Connection마다 인증된 사용자, Session 정보, 트랜잭션 상태, 실행 중인 Query 등을 관리해야 한다. Connection 수가 늘어나면 DB CPU, I/O, Lock 경합이 증가할 수 있고, OS에서도 Context Switching이나 Interrupt 처리 비용이 늘어날 수 있다.

결국 DB Connection은 “Query를 보내기 위한 단순 통로”가 아니라, 네트워크 연결, OS 커널 자원, DB Session 상태가 결합된 무거운 자원이다.

🔗 미션과의 연결

미션에서 우리는 Repository나 DAO를 통해 자연스럽게 DB에 접근한다. 코드에서는 SQL을 실행하는 부분만 눈에 잘 보이지만, 그 SQL이 실행되기 전에는 반드시 DB와 통신할 수 있는 Connection이 필요하다.

예를 들어 예약 생성, 대기열 등록, 결제 처리처럼 DB에 접근하는 기능은 모두 Connection 위에서 동작한다. 이때 Connection을 새로 만든다면 Query 실행 전에 TCP 연결, DB 프로토콜 협상, 인증, Session 초기화 같은 비용이 먼저 발생한다.

또한 트랜잭션이 시작되면 Connection은 해당 트랜잭션이 끝날 때까지 점유될 수 있다.
만약 트랜잭션 안에서 불필요하게 오래 걸리는 작업을 수행하면, 그 시간 동안 Connection이라는 비싼 자원을 계속 붙잡고 있게 된다.

그래서 미션에서 DB 코드를 볼 때는 단순히 “쿼리가 맞는가?”만 볼 것이 아니라 다음도 함께 생각해야 한다.

• 이 작업은 언제 Connection을 필요로 하는가?
• Connection을 얻은 뒤 너무 오래 점유하고 있지는 않은가?
• 트랜잭션 범위가 불필요하게 넓지는 않은가?
• Query 실행 전후로 OS와 DB에는 어떤 자원이 사용되고 있는가?

Connection Pool은 이런 비싼 Connection을 매번 새로 만들지 않기 위한 방법이지만, 핵심은 Pool 자체가 아니라 “Connection 하나가 이미 비싼 자원”이라는 점이다.

---

🙋‍♀️ 질문

1. getConnection()을 호출한 뒤 첫 Query가 실행되기 전까지, 내부에서는 어떤 준비 과정이 필요할까?

2. TLS/SSL Handshake, DB Protocol Handshake, Authentication 과정이 각각 왜 추가로 필요한지 설명해주세요.

3. 발표에서는 Connection을 OS 관점에서 Socket, File Descriptor, Kernel Buffer와 연결해 설명했습니다. Connection 수가 많아질 때 이 자원들이 어떤 한계나 부담으로 이어질 수 있나요?

[Jiihyun]

getConnection()을 호출한 뒤 첫 Query가 실행되기 전까지, 내부에서는 어떤 준비 과정이 필요할까?

getConnection()을 호출하면 JDBC Driver가 DB 서버와 통신하기 위한 Socket 생성을 OS에 요청합니다. OS는 Socket과 이를 관리하기 위한 File Descriptor를 할당하고, TCP Handshake를 통해 DB 서버와 연결을 수립합니다. 이후 DB 프로토콜 통신과 사용자 인증 과정을 거치며 DB Session이 생성됩니다. 이렇게 네트워크 연결과 Session 준비가 완료된 후에 Connection 객체가 애플리케이션에 반환되고, 그제서야 첫 SQL을 DB에 전달할 수 있습니다.

TLS/SSL Handshake, DB Protocol Handshake, Authentication 과정이 각각 왜 추가로 필요한지 설명해주세요.

TCP 연결만으로는 데이터가 평문으로 전송될 수 있고, 상대가 진짜 서버인지도 확인할 수 없습니다. TLS Handshake를 통해 서버 인증서를 검증하여 서버의 신원을 확인하고, 이후 통신에 사용할 세션 키를 안전하게 생성합니다. 그 후 모든 데이터는 암호화되어 전송되므로 비밀번호나 SQL 요청이 중간에 노출되거나 변조되는 것을 방지할 수 있습니다.

DB Protocol Handshake 과정에서 DB 종류와 버전, 지원 기능, 인증 방식 등을 확인하고, 앞으로 사용할 통신 규칙을 협상합니다. 만약 MySQL JDBC Driver가 PostgreSQL 서버에 접속하는 것처럼 서로 다른 프로토콜을 사용한다면, 패킷 형식을 해석할 수 없어 Handshake 단계에서 통신이 실패합니다.

마지막으로 Authentication은 DB 서버가 클라이언트의 신원과 권한을 검증하기 위한 과정이며, 인증이 완료되면 DB Session이 생성되고 SQL을 실행할 수 있습니다.

발표에서는 Connection을 OS 관점에서 Socket, File Descriptor, Kernel Buffer와 연결해 설명했습니다. Connection 수가 많아질 때 이 자원들이 어떤 한계나 부담으로 이어질 수 있나요?

Connection 수가 증가하면 각 Connection마다 Socket, File Descriptor, Kernel Buffer, TCP 상태 정보가 필요합니다. 따라서 File Descriptor 한도에 도달해 새로운 Connection 생성이 실패할 수 있고, Kernel Buffer로 인해 메모리 사용량도 증가합니다. 또한 OS가 관리해야 하는 TCP 연결 상태가 많아져 CPU 부담도 커집니다. 그래서 대규모 서비스에서는 Connection Pool을 사용해 기존 Connection을 재사용합니다.

[Soojin6943]

getConnection()을 호출한 뒤 첫 Query가 실행되기 전까지, 내부에서는 어떤 준비 과정이 필요할까?

1. TCP Connection 생성
   • SYN -> SYN-ACK -> SYN
   • 이 시점부터 양쪽 OS는 Socket을 생성하고 연결 상태 관리
2. TLS/SSL Handshake (선택)
3. DB Protocol Handshake
4. Authentication
5. Session 생성
6. 쿼리 실행

TLS/SSL Handshake, DB Protocol Handshake, Authentication 과정이 각각 왜 추가로 필요한지 설명해주세요.

• TLS/SSL Handshake : http는 평문으로 통신하기 때문에 이를 암호화하기 위해
• DB Protocol Handshake : 어떤 방식으로 데이터를 주고 받을지 정하기 위해
• Authentication : 신원과 권한 확인을 위해

발표에서는 Connection을 OS 관점에서 Socket, File Descriptor, Kernel Buffer와 연결해 설명했습니다. Connection 수가 많아질 때 이 자원들이 어떤 한계나 부담으로 이어질 수 있나요?

• File Descriptior이 고갈될 수 있음
• 소켓마다 버퍼가 존재하게 되는데, Connection이 많아진다면 Socket이 많아지고, 이에 따라 메모리 사용량 증가

[MODUGGAGI]

getConnection()을 호출한 뒤 첫 Query가 실행되기 전까지, 내부에서는 어떤 준비 과정이 필요할까?

• JDBC Driver가 DB 서버와 TCP 연결을 생성한다.
• TCP 연결 이후 TLS/SSL Handshake를 통해 암호화 채널을 구축한다.
• DB Protocol Handshake를 통해 사용할 기능, 인증 방식, 인코딩 등을 협상한다.
• Authentication 과정을 통해 사용자를 인증한다.
• DB는 새로운 Session을 생성하고 Query를 처리할 준비를 마친다.
• 이 모든 과정이 끝난 후에야 첫 Query를 실행할 수 있다.

TLS/SSL Handshake, DB Protocol Handshake, Authentication 과정이 각각 왜 추가로 필요한지 설명해주세요.

• TLS/SSL Handshake
  • 클라이언트와 서버가 주고 받는 데이터가 http로 전송하게 되면 평문으로 그대로 노출되기 때문에 https로 전환하기 위해서
• DB Protocol Handshake
  • DB가 이해할 수 있는 소통 방식을 결정하기 위해 존재하는 과정
  • 소통하기 위한 프로토콜을 정한다.
• Authentication
  • 현재 사용자가 유효한 사용자인지 판단해야 DB 세션을 생성하고 쿼리를 수행할 수 있기 때문에 필요하다.

발표에서는 Connection을 OS 관점에서 Socket, File Descriptor, Kernel Buffer와 연결해 설명했습니다. Connection 수가 많아질 때 이 자원들이 어떤 한계나 부담으로 이어질 수 있나요?

• 각 Connection은 Socket, File Descriptor, Kernel Buffer를 사용
• 따라서 Connection이 증가할 수록 위 자원들을 추가로 사용하며 메모리 사용량이 늘어난다.
• 그리고 이때 File Descriptor의 개수 제한에 도달해 추가 Connection 생성이 막힐 수 있다.
• 또한 OS가 DB와의 TCP 연결 상태를 더 많이 관리해야 하므로 관리 비용이 증가한다.

[Jihyun3478]

Q1. getConnection()을 호출한 뒤 첫 Query가 실행되기 전까지, 내부에서는 어떤 준비 과정이 필요할까요?

1. TCP 3-way Handshake
2. TLS Handshake
3. DB Protocol Handshake
4. Authentication

위 4개의 단계가 종료되면 쿼리를 보낼 수 있습니다.

---

Q2. TLS/SSL Handshake, DB Protocol Handshake, Authentication 과정이 각각 왜 추가로 필요한지 설명해주세요.

TLS/SSL Handshake는 도청과 변조를 막기 위한 암호화 채널을 수립합니다. DB Protocol Handshake는 클라이언트와 서버가 문자셋, 압축 방식 등 서로 지원하는 기능을 협상하는 과정입니다. Authentication은 해당 DB에 접근 권한이 있는 사용자인지 확인합니다. 각 단계가 각각 다른 레이어의 문제를 해결하기 때문에 생략할 수 없습니다.

---

Q3. 발표에서는 Connection을 OS 관점에서 Socket, File Descriptor, Kernel Buffer와 연결해 설명했습니다. Connection 수가 많아질 때 이 자원들이 어떤 한계나 부담으로 이어질 수 있나요?

• Socket: Connection마다 소켓이 생성되고, OS가 각 소켓의 상태를 추적 및 관리해야 합니다. Connection이 많아질수록 OS의 부담이 증가합니다.
• FD: 프로세스당 열 수 있는 FD 수에 상한이 있어. 초과 시 Too many open files
• Kernel Buffer: Connection마다 Send/Receive Buffer가 할당돼 메모리를 직접 소비

[wontop02]

getConnection()을 호출한 뒤 첫 Query가 실행되기 전까지, 내부에서는 어떤 준비 과정이 필요할까?

1. TCP 3-Way Handshake
2. TLS/SSL Handshake
3. DB Protocol Handshake
4. Authentication & Autorization
5. Connection Initialization & Context Setup
6. Connection Pool에 등록

TLS/SSL Handshake, DB Protocol Handshake, Authentication 과정이 각각 왜 추가로 필요한지 설명해주세요.

• TLS/SSL Handshake: TCP 연결만 하면 데이터가 평문으로 전송되어, 네트워크 중간에 해커가 패킷을 가로챘을 때 개인정보나 DB 쿼리가 그대로 노출될 수 있기 때문이다.
• DB Protocol Handshake: 공통 규격을 맞춰야 하기 때문이다. 해당 데이터가 어떤 프로토콜, 규격인지 합의한다.
• Authentication: 올바른 규격으로 접근해도, 권한이 있는 사람만 DB의 데이터를 읽고 써야 하기 때문이다.

발표에서는 Connection을 OS 관점에서 Socket, File Descriptor, Kernel Buffer와 연결해 설명했습니다. Connection 수가 많아질 때 이 자원들이 어떤 한계나 부담으로 이어질 수 있나요?

• Socket: 하나의 Connection이 맺어지면 소켓 객체가 생성되는데, 이를 OS 커널 내에서 관리하므로 수많은 소켓이 존재하면 커널 관리 오버헤드가 증가한다.
• File Descriptor: OS에는 동시에 열 수 있는 최대 파일 개수 제한이 있는데, Connection 수가 이 제한을 초과하면 OS는 소켓을 더이상 생성할 수 없다.
• Kernel Buffer: TCP/IP 통신은 신뢰성을 보장해야 하므로 패킷을 주고받을 때 임시로 데이터를 저장할 공간이 필요하다. 이를 위해 소켓마다 커널 공간에 송신 버퍼, 수신 버퍼가 한 쌍으로 할당된다. 소켓이 많아져 커널 공간에 메모리가 부족해지면 프로세스가 강제 종료될 수 있다.