6주차 Unit 5.4 — DriverManagerDataSource

Psj·2026년 6월 1일

F-lab

목록 보기

201/239

Unit 5.4 — DriverManagerDataSource

F-LAB JAVA · 6주차 · Phase 5 · DataSource 인터페이스 (추상화의 진화)
🏆 Phase 5 완주 — 어댑터 패턴의 실제

📌 학습 목표

이 Unit을 끝내면 다음을 답할 수 있어야 한다.

DriverManager 는 DataSource 인터페이스 구현 안 함 의 문제는?
Spring 의 해결책 (DriverManagerDataSource) 은?
내부적으로 DriverManager, 외부적으로 DataSource 의 의미는?
애플리케이션이 DataSource 에만 의존 의 효과는?
DriverManagerDataSource 의 용도 (테스트/학습) 는?
프로덕션에서 절대 쓰지 말 것 의 이유는?
5주차 어댑터 패턴 의 실제 적용은?
DriverManagerDataSource vs HikariDataSource 비교는?
Phase 5 전체 의 종합은?

🎯 핵심 한 문장

DriverManager 는 정적 메서드라 DataSource 인터페이스를 구현하지 않는데 Spring 이 DriverManager 를 DataSource 로 감싼 DriverManagerDataSource 를 만들어 같은 인터페이스로 다룰 수 있게 한 어댑터 패턴의 실제 사례이며, 풀이 없어 테스트·학습용으로만 쓰고 프로덕션엔 절대 쓰지 않는다.
문제는 DriverManager 가 DataSource 인터페이스를 구현하지 않는다 는 것 — DriverManager 는 정적 클래스 (DriverManager.getConnection(url, ...)) 라 객체가 아니기에 인터페이스 구현이 불가능하다.
Spring 의 해결책은 DriverManagerDataSource — 내부적으로는 DriverManager 의 정적 메서드를 호출하고, 외부적으로는 DataSource 인터페이스 (getConnection()) 를 제공한다.
덕분에 애플리케이션은 DataSource 에만 의존하면 되고, 테스트에서는 DriverManagerDataSource, 운영에서는 HikariDataSource 처럼 환경별로 주입만 다르게 하면 된다.
용도는 테스트 환경 (풀 불필요한 짧은 단위 테스트) 과 학습용 이며 — 풀이 없어 매 요청 새 연결 (Unit 4.1 의 비용 그대로) 이므로 프로덕션에서는 절대 쓰지 말 것 이다. 이 구조는 5주차의 어댑터 패턴 (서로 다른 인터페이스를 호환되게 변환) 의 살아있는 사례다.

비유 — 전통 콘센트 → 표준 USB 어댑터

DriverManagerDataSource = 콘센트-USB 어댑터:

문제:
  - 가전 (애플리케이션) 은 USB-C (DataSource) 만
  - DriverManager 는 옛 콘센트 (정적 메서드)
  - 인터페이스 안 맞음

해결 — 어댑터:
  - 한쪽: 옛 콘센트 (DriverManager 정적 호출)
  - 다른쪽: USB-C (DataSource 인터페이스)
  - 변환

내부 = DriverManager:
  - 어댑터가 옛 콘센트 사용

외부 = DataSource:
  - 가전이 보는 건 USB-C

용도:
  - 학습 (어댑터 비싸지만 단순)
  - 테스트 (가벼움)

프로덕션 X:
  - 매번 새 연결 (풀 X)
  - 비효율
  - 실전엔 HikariCP

5주차 어댑터 패턴:
  - "맞지 않는 인터페이스를 변환"
  - DriverManagerDataSource 가 그것

→ DriverManagerDataSource = DriverManager 를 DataSource 로 감싼 어댑터, 테스트만.

🧭 9개 섹션 로드맵

1. DriverManager 가 DataSource 안 구현
2. Spring 의 해결책
3. 내부 / 외부 분리
4. 애플리케이션 일관성
5. 용도 (테스트/학습)
6. 프로덕션 X 이유
7. 어댑터 패턴 적용
8. vs HikariDataSource
9. Phase 5 완주 정리

1️⃣ DriverManager 가 DataSource 안 구현

1.1 문제

문제:

  DriverManager:
    - 정적 클래스 (static 메서드)
    - DriverManager.getConnection(url, ...)

  DataSource:
    - 인터페이스
    - 인스턴스 메서드 (getConnection())

  → 인터페이스 구현 불가

1.2 정적 vs 인스턴스

정적 vs 인스턴스:

DriverManager (정적):
  - 클래스 메서드
  - 객체 X
  - 다형성 X

DataSource (인스턴스):
  - 객체 메서드
  - 인터페이스 구현
  - 다형성 O

1.3 호환 문제

호환 문제:

  애플리케이션:
    - DataSource 의존
  
  DriverManager 직접 X:
    - 인터페이스 안 맞음
    - 사용 불가

→ 다리 필요

1.4 ILIC 의 맥락

// 문제 (ILIC, 추상화 후)
@Repository
public class ShipmentDao {
    private final DataSource dataSource;   // DataSource 만
    public ShipmentDao(DataSource ds) { this.dataSource = ds; }
}

// 테스트에서 DriverManager 쓰고 싶지만:
// DataSource 를 받아야 하는데 DriverManager 는 인터페이스 X
// → 어댑터 필요
class DataSourceMarker { /* placeholder */ }
interface DataSource { Connection getConnection() throws Exception; }

1.5 자기 점검 답변

DriverManager 는 DataSource 안 구현의 문제는?

답:
1. 문제:

정적 클래스

정적 vs 인스턴스:
- 인터페이스 구현 X
호환:
- DataSource 의존엔 안 맞음
필요:
- 다리 (어댑터)

2️⃣ Spring 의 해결책

2.1 DriverManagerDataSource

Spring 의 해결:

  DriverManagerDataSource:
    - DriverManager 를 감쌈
    - DataSource 인터페이스 구현
    - 어댑터

→ 호환 가능

2.2 클래스 위치

클래스 위치:

  org.springframework.jdbc.datasource:
    - DriverManagerDataSource
    - Spring JDBC 모듈
    - 표준 자바엔 없음 (Spring 제공)

2.3 사용

// DriverManagerDataSource 사용
DriverManagerDataSource ds = new DriverManagerDataSource();
ds.setUrl("jdbc:mysql://localhost:3306/ilic");
ds.setUsername("ilic_user");
ds.setPassword("password");
// implements DataSource

// 사용
Connection c = ds.getConnection();
// 내부적으로 DriverManager.getConnection() 호출

2.4 인터페이스 호환

인터페이스 호환:

  DriverManagerDataSource implements DataSource:
    - DataSource 받는 곳에 쓸 수 있음
    - HikariDataSource 처럼

→ 일관된 사용

2.5 ILIC 의 맥락

// Spring 의 DriverManagerDataSource (ILIC 테스트)
@Configuration
@Profile("test")
public class TestDataSourceConfig {
    @Bean
    public DataSource dataSource() {
        DriverManagerDataSource ds = new DriverManagerDataSource();
        ds.setDriverClassName("org.h2.Driver");
        ds.setUrl("jdbc:h2:mem:testdb");
        ds.setUsername("sa");
        ds.setPassword("");
        return ds;
        // DriverManagerDataSource 가 DataSource 반환
    }
}

// 동일한 ShipmentDao 가 이걸 받음
@Repository
public class ShipmentDao {
    private final DataSource dataSource;
    public ShipmentDao(DataSource ds) { this.dataSource = ds; }
    // 테스트 시: DriverManagerDataSource 주입
    // 운영 시: HikariDataSource 주입
    // → 같은 코드
}
class DriverManagerDataSource {
    void setDriverClassName(String s) {}
    void setUrl(String s) {}
    void setUsername(String s) {}
    void setPassword(String s) {}
}

2.6 자기 점검 답변

Spring 의 해결책 (DriverManagerDataSource) 은?

답:
1. DriverManagerDataSource:

DriverManager 감쌈

위치:
- Spring JDBC
사용:
- DataSource 처럼
호환:
- 인터페이스 통일

3️⃣ 내부 / 외부 분리

3.1 내부 — DriverManager

내부 (구현):

  DriverManagerDataSource.getConnection():
    → 내부적으로
    → DriverManager.getConnection(url, user, pwd)
    → 매번 새 연결

3.2 외부 — DataSource

외부 (인터페이스):

  DriverManagerDataSource:
    implements DataSource
    
  외부에서 보면:
    - DataSource (인터페이스)
    - getConnection() 호출

3.3 시각화

시각화:

[애플리케이션]
   ↓ DataSource 인터페이스
[DriverManagerDataSource] ← 어댑터
   ↓ 내부 호출
[DriverManager.getConnection()]
   ↓
[DB]

  - 외부: DataSource
  - 내부: DriverManager

3.4 변환

변환:

  외부 호출 (인스턴스):
    ds.getConnection()

  내부 변환:
    DriverManager.getConnection(this.url, ...)

  → 인터페이스 변환

3.5 ILIC 의 맥락

// 내부 / 외부 분리 (DriverManagerDataSource 동작 개념)

class DriverManagerDataSource implements DataSource {
    private String url;
    private String username;
    private String password;
    
    // 외부 (DataSource 인터페이스)
    public Connection getConnection() throws SQLException {
        // 내부 (DriverManager 호출)
        return DriverManager.getConnection(url, username, password);
        // → 매번 새 연결 (풀 X)
    }
    
    public void setUrl(String url) { this.url = url; }
    public void setUsername(String u) { this.username = u; }
    public void setPassword(String p) { this.password = p; }
}

// ILIC ShipmentDao 가 받음
@Repository
public class ShipmentDao {
    private final DataSource ds;   // 외부 인터페이스
    // 내부가 DriverManager 든 HikariCP 든 모름
}
interface DataSource { Connection getConnection() throws SQLException; }

3.6 자기 점검 답변

내부적으로 DriverManager, 외부적으로 DataSource 의 의미는?

답:
1. 내부:

DriverManager 호출

외부:
- DataSource 인터페이스
시각화:
- 어댑터 가운데
변환:
- 인스턴스 → 정적

4️⃣ 애플리케이션 일관성

4.1 일관된 코드

일관된 코드:

  애플리케이션 (DataSource 의존):
    - 운영 (HikariDataSource): OK
    - 테스트 (DriverManagerDataSource): OK
    - 같은 코드

4.2 환경별 주입

// 환경별 주입 (DataSource 만 갈아끼움)

@Profile("prod")
@Bean
DataSource prodDataSource() {
    // HikariDataSource (풀)
    return new HikariDataSource(config);
}

@Profile("test")
@Bean
DataSource testDataSource() {
    // DriverManagerDataSource (풀 없음)
    return new DriverManagerDataSource(...);
}

// ShipmentDao 는 어떤 환경이든 DataSource 만 받음

4.3 추상화의 이점

추상화 이점:

  - 환경별 풀 선택
  - 테스트 단순 (풀 불필요)
  - 같은 코드
  - DIP 준수

→ 5주차 정신 실현

4.4 H2 + DriverManagerDataSource

# 테스트 환경 (Spring Boot)
spring:
  profiles: test
  datasource:
    url: jdbc:h2:mem:testdb
    driver-class-name: org.h2.Driver
    # H2 인메모리 + DriverManagerDataSource (가벼움)

4.5 ILIC 의 맥락

// ILIC 환경별 (일관된 코드)

// 운영 (HikariCP, 풀)
@Profile("prod")
@Configuration
class ProdConfig {
    @Bean
    DataSource dataSource() {
        HikariConfig c = new HikariConfig();
        c.setJdbcUrl("jdbc:mysql://prod-mysql:3306/ilic");
        c.setMaximumPoolSize(20);
        return new HikariDataSource(c);
    }
}

// 테스트 (DriverManagerDataSource + H2)
@Profile("test")
@Configuration
class TestConfig {
    @Bean
    DataSource dataSource() {
        DriverManagerDataSource ds = new DriverManagerDataSource();
        ds.setUrl("jdbc:h2:mem:ilictest");
        ds.setDriverClassName("org.h2.Driver");
        return ds;
    }
}

// 모든 DAO 는 같은 코드 (DataSource 만 의존)
@Repository
public class ShipmentDao {
    private final DataSource ds;
    public ShipmentDao(DataSource ds) { this.ds = ds; }
    // 운영/테스트 동일 코드
}
class HikariConfig {
    void setJdbcUrl(String s) {}
    void setMaximumPoolSize(int n) {}
}
class HikariDataSource implements DataSource {
    HikariDataSource(HikariConfig c) {}
    public Connection getConnection() { return null; }
}
class DriverManagerDataSource implements DataSource {
    void setUrl(String s) {}
    void setDriverClassName(String s) {}
    public Connection getConnection() { return null; }
}

4.6 자기 점검 답변

애플리케이션이 DataSource 에만 의존의 효과는?

답:
1. 일관된 코드:

환경 무관

환경별 주입:
- Hikari/DriverManagerDS
이점:
- 테스트 단순
DIP:
- 준수

5️⃣ 용도 (테스트/학습)

5.1 주 용도

DriverManagerDataSource 용도:

1. 테스트 환경
   - 가벼움 (풀 X)
   - 단순
   - H2 인메모리

2. 학습용
   - 풀 없이 DataSource 사용
   - 개념 이해

3. 예외적 케이스
   - 매우 짧은 작업
   - 일회성

5.2 테스트 적합

테스트 적합:

  - 단위 테스트 (DB 짧게)
  - 통합 테스트 (테스트 DB)
  - H2 / TestContainer

  풀 부담 없이 가볍게

5.3 학습용

학습용:

  처음 DataSource 배울 때:
    - DriverManagerDataSource
    - 단순 구조
    - 어댑터 패턴 이해

→ 입문

5.4 ILIC 의 맥락

// 테스트에서 DriverManagerDataSource (ILIC)
@SpringBootTest
@ActiveProfiles("test")
class ShipmentDaoIntegrationTest {
    @Autowired
    private ShipmentDao shipmentDao;   // DataSource 받음
    
    @Test
    void test_add() {
        // 테스트 시:
        // - DriverManagerDataSource (풀 X)
        // - H2 인메모리 DB
        // - 빠른 단위 테스트
        
        Shipment s = new Shipment(1L);
        // shipmentDao.add(s);
        // 작은 단위 테스트
    }
}
class ShipmentDao { void add(Shipment s) {} }
record Shipment(Long id) {}

5.5 자기 점검 답변

DriverManagerDataSource 의 용도 (테스트/학습) 는?

답:
1. 용도:

테스트/학습

테스트:
- 가벼움, H2
학습:
- DataSource 입문
예외:
- 일회성

6️⃣ 프로덕션 X 이유

6.1 절대 X

프로덕션 절대 X:

  DriverManagerDataSource:
    - 풀 없음
    - 매 요청 새 연결
    - Unit 4.1 비용 그대로

→ 운영 부적합

6.2 성능 문제

성능 문제:

  매 요청:
    - TCP handshake
    - 인증
    - 세션 생성

  → 수십 ms × 요청 수
  → 응답 지연 폭증

6.3 DB 부담

DB 부담:

  - max_connections 초과 위험
  - 인증 비용 누적
  - 세션 폭증

→ DB 다운 가능

6.4 대안

대안 (프로덕션):

  - HikariDataSource (Spring Boot 기본)
  - BasicDataSource (DBCP2)
  - Tomcat JDBC Pool

→ 풀 사용 필수

6.5 ILIC 의 맥락

ILIC 프로덕션 (HikariCP):

만약 ILIC 가 DriverManagerDataSource:
  - 431 API × 1000 동시 요청
  - 매 요청 새 연결
  - DB 응답 시간 5ms vs 연결 50ms
  - 응답 시간 폭증
  - max_connections (151) 초과
  - 서비스 장애

ILIC 실제 (HikariCP):
  - 풀 20개
  - 재사용
  - 정상 운영
  - 안정

→ 운영 = HikariCP 필수
→ DriverManagerDataSource = 테스트만

6.6 자기 점검 답변

프로덕션에서 절대 쓰지 말 것의 이유는?

답:
1. 절대 X:

풀 없음

성능:
- 매 요청 연결 비용
DB 부담:
- max_connections, 세션 폭증
대안:
- HikariCP

7️⃣ 어댑터 패턴 적용

7.1 어댑터 패턴

어댑터 패턴 (5주차):

  맞지 않는 인터페이스를:
    - 호환되게 변환
    - 중간에 끼움

→ 인터페이스 변환

7.2 DriverManagerDataSource = 어댑터

DriverManagerDataSource = 어댑터:

  Target (원하는 인터페이스):
    - DataSource

  Adaptee (변환 대상):
    - DriverManager

  Adapter:
    - DriverManagerDataSource
    - DataSource 구현
    - 내부 DriverManager 호출

7.3 5주차 패턴 매핑

5주차 패턴 매핑:

  어댑터 패턴:
    - Target ← Adapter → Adaptee
  
  여기:
    - DataSource ← DriverManagerDataSource → DriverManager

7.4 자바 표준에 녹은 OOP

자바 표준에 녹은 OOP:

  좋은 라이브러리 = 좋은 OOP:
    - DataSource = DIP/OCP
    - DriverManagerDataSource = 어댑터
    - HikariDataSource = 전략

→ 디자인 패턴의 보고

7.5 ILIC 의 맥락

// 어댑터 패턴 (DriverManagerDataSource, ILIC)

// Target (원하는 인터페이스)
interface DataSource {
    Connection getConnection() throws SQLException;
}

// Adaptee (변환 대상, 정적 클래스)
// java.sql.DriverManager (정적 메서드)

// Adapter (어댑터 — DriverManager 를 DataSource 로)
class DriverManagerDataSource implements DataSource {
    private String url;
    
    public DriverManagerDataSource(String url) { this.url = url; }
    
    @Override
    public Connection getConnection() throws SQLException {
        // 내부적으로 정적 메서드 호출
        return DriverManager.getConnection(url);
    }
}

// 사용 (Target 인터페이스로)
@Repository
class ShipmentDao {
    private final DataSource ds;   // Target
    public ShipmentDao(DataSource ds) {
        this.ds = ds;   // 어떤 구현이든 OK (어댑터 포함)
    }
}

// → 5주차 어댑터 패턴의 실제 구현
// → ILIC 도 테스트에서 활용 가능

7.6 자기 점검 답변

5주차 어댑터 패턴의 실제 적용은?

답:
1. 어댑터 패턴:

인터페이스 변환

매핑:
- DataSource ← DMDS → DriverManager
Target/Adapter/Adaptee:
- DriverManagerDataSource = 어댑터
OOP 실제:
- 자바 표준에 녹음

8️⃣ vs HikariDataSource

8.1 비교 표

항목	DriverManagerDataSource	HikariDataSource
풀	없음	있음 (빠름)
연결	매번 새로	재사용
성능	느림	빠름
용도	테스트/학습	운영
Spring Boot	명시 설정	자동 (기본)

8.2 같은 인터페이스

같은 인터페이스:

  둘 다 implements DataSource:
    - 사용 코드 동일
    - getConnection() 호출

→ 추상화의 힘

8.3 성능 차이

성능 차이:

  요청 100 회:
    DriverManagerDataSource:
      - 100 × 50ms (연결만)
      - = 5000ms

    HikariDataSource:
      - 풀에서 빌림 (0.1ms × 100)
      - = 10ms (500배)

8.4 선택

선택:

  운영: HikariDataSource (필수)
  테스트: DriverManagerDataSource (편의)
  
  추상화 덕분에:
    - 코드 변경 X
    - 빈 교체만

8.5 ILIC 의 맥락

// vs 비교 (ILIC)

// 운영 (HikariDataSource)
@Profile("prod")
@Bean
DataSource prodDataSource() {
    HikariConfig c = new HikariConfig();
    c.setJdbcUrl("jdbc:mysql://prod:3306/ilic");
    c.setMaximumPoolSize(20);
    return new HikariDataSource(c);
    // → 빠름, 풀
}

// 테스트 (DriverManagerDataSource)
@Profile("test")
@Bean
DataSource testDataSource() {
    DriverManagerDataSource ds = new DriverManagerDataSource();
    ds.setUrl("jdbc:h2:mem:test");
    return ds;
    // → 가벼움, 풀 X (테스트엔 충분)
}

// ShipmentDao (어떤 환경이든)
@Repository
class ShipmentDao {
    private final DataSource ds;
    public ShipmentDao(DataSource ds) { this.ds = ds; }
    // 코드 변경 0
    // → DataSource 추상화의 힘
}
class HikariConfig {
    void setJdbcUrl(String s) {}
    void setMaximumPoolSize(int n) {}
}
class HikariDataSource implements DataSource {
    HikariDataSource(HikariConfig c) {}
    public Connection getConnection() { return null; }
}
class DriverManagerDataSource implements DataSource {
    void setUrl(String s) {}
    public Connection getConnection() { return null; }
}

8.6 자기 점검 답변

DriverManagerDataSource vs HikariDataSource 비교는?

답:
1. 풀:

X vs O

성능:
- 느림 vs 빠름
용도:
- 테스트 vs 운영
인터페이스:
- 같음 (DataSource)

9️⃣ Phase 5 완주 정리

9.1 Phase 5 학습 종합

Phase 5 — DataSource 인터페이스

Unit 5.1 — 다양한 커넥션 획득 방식
  - DriverManager/HikariCP/DBCP2/Tomcat
  - 사용법 다름 (OCP 위반)

Unit 5.2 — 추상화의 필요성
  - 변경 압력 차단
  - 인터페이스로

Unit 5.3 — DataSource 인터페이스 ★깊이
  - javax.sql.DataSource
  - getConnection() 하나
  - SOLID DIP 실체

Unit 5.4 — DriverManagerDataSource
  - 어댑터 패턴
  - 테스트/학습
  - 프로덕션 X

9.2 핵심 메시지

Phase 5 핵심 메시지:

  "5주차의 추상화 정신이
   자바 표준 DataSource 로 구현됐다.
   애플리케이션은 DataSource 만 의존하면
   풀 라이브러리를 자유롭게 교체할 수 있다."

9.3 5주차 ↔ 6주차 정리

5주차	6주차 (Phase 5)
ConnectionMaker	DataSource
전략 패턴	DataSource + 구현체
DIP	DataSource 의존
어댑터 패턴	DriverManagerDataSource
OCP	HikariCP ↔ DBCP2 교체

9.4 다음 Phase 예고

Phase 5 → Phase 6:
  - 연결 추상화 → 트랜잭션

Phase 6 — 트랜잭션 ACID (5개 ★깊이!):
  Unit 6.1 — 트랜잭션이란
  Unit 6.2 — Atomicity ★깊이
  Unit 6.3 — Consistency ★깊이
  Unit 6.4 — Isolation ★깊이
  Unit 6.5 — Durability ★깊이
  Unit 6.6 — Commit 이전 동시성 ★깊이

9.5 면접 단골 질문 매핑

Q	핵심 답변
DriverManagerDataSource?	DriverManager → DataSource 어댑터
왜 필요?	DriverManager 인터페이스 안 함
내부/외부?	DriverManager / DataSource
용도?	테스트/학습
프로덕션 X?	풀 없음
어댑터 패턴?	Adapter 의 실제
vs Hikari?	풀 무/유
환경별?	주입만 다르게
자바 표준?	Spring 제공 (자바 X)
일관성?	DataSource 코드 동일

9.6 추가 심화 질문

Q1: SingleConnectionDataSource?

답:

Spring 의 또 다른 DataSource
단일 Connection 재사용
단일 스레드 테스트
매우 가벼움

Q2: SmartDataSource?

답:

Spring 인터페이스
트랜잭션 인식
shouldClose 메서드
트랜잭션 관리 협력

Q3: 어댑터 vs 데코레이터?

답:

어댑터: 인터페이스 변환
데코레이터: 기능 추가 (감싸기)
구조 유사
의도 다름

Q4: 풀이 DataSource 면 좋은 점?

답:

표준 인터페이스
호환성
교체 자유
DI 친화

Q5: 자바 진영의 OOP 사례?

답:

Comparator (전략)
Iterator (반복자)
DataSource (DIP)
라이브러리 = 교본

🎯 핵심 요약 — 3줄 정리

1. DriverManagerDataSource 의 이유

DriverManager 는 정적 클래스라 DataSource 인터페이스 구현 불가
Spring 이 어댑터로 감싸 DataSource 처럼 사용 가능하게 함

2. 어댑터 패턴

내부: DriverManager 정적 호출 / 외부: DataSource 인터페이스
5주차 어댑터 패턴 (Target ← Adapter → Adaptee) 의 실제

3. 용도와 한계

테스트/학습용 (H2 + DriverManagerDataSource)
프로덕션 절대 X (풀 없음 → Unit 4.1 비용 그대로 → 성능 폭망)

🏆 Phase 5 완주 — DataSource 인터페이스

🔌 Phase 5 — DataSource 인터페이스
  ✅ Unit 5.1 다양한 커넥션 획득 방식
  ✅ Unit 5.2 추상화의 필요성
  ✅ Unit 5.3 DataSource 인터페이스 ★깊이
  ✅ Unit 5.4 DriverManagerDataSource ← 여기, Phase 5 완주

→ 다양한 풀 (OCP 위반)
→ 추상화 필요 (5주차 정신)
→ DataSource (자바 표준, DIP)
→ DriverManagerDataSource (어댑터)

📚 다음으로...

Phase 6 — 트랜잭션과 ACID (★깊이 5개 집중!)

💾 Phase 6 — 트랜잭션과 ACID
  Unit 6.1 — 트랜잭션이란
  Unit 6.2 — Atomicity (원자성) ★깊이
  Unit 6.3 — Consistency (일관성) ★깊이
  Unit 6.4 — Isolation (격리성) ★깊이
  Unit 6.5 — Durability (지속성) ★깊이
  Unit 6.6 — Commit 이전 트랜잭션 동시성 ★깊이

6주차 누적 진행

🧪 Part A (9 Unit) ✅
💾 Part B — DB 접근의 진화
  ✅ Phase 3 — JDBC (3)
  ✅ Phase 4 — Connection Pool (4)
  ✅ Phase 5 — DataSource (4) ← 완주
  ⏭ Phase 6 — 트랜잭션 ACID (6, ★깊이 5개!)
  ⏭ Phase 7 — JdbcTemplate (5, 7.2 ★깊이)

총: 20/28 Unit

🏆 Phase 5 완주 — DataSource 인터페이스

Psj

Software Developer

이전 포스트

6주차 Unit 5.3 — DataSource 인터페이스

다음 포스트