Unit 3.1 — DAO란 무엇인가
F-LAB JAVA · 5주차 · Phase 3 · 전통 DAO의 문제
🌱 Part B 시작 — 토비의 스프링: 객체 설계의 진화
📌 학습 목표
이 Unit을 끝내면 다음을 답할 수 있어야 한다.
- DAO (Data Access Object) 의 정의는?
- DAO 가 분리하는 책임 은?
- 비즈니스 로직에 SQL 을 박으면 어떤 문제가?
- DAO 패턴의 역사 는?
- 계층 구조에서 DAO 의 위치 는?
- DAO 와 Repository 의 차이 는?
- DAO 의 장점 은?
- DAO 인터페이스와 구현 분리는?
- DAO 가 Spring 진화의 출발점인 이유는?
🎯 핵심 한 문장
DAO (Data Access Object) 는 데이터베이스 접근·조작 기능만 전담하는 객체로, 비즈니스 로직과 데이터 접근 로직을 분리하는 패턴이다.
DAO 는 SQL 실행·연결 관리·결과 매핑 같은 데이터 접근 책임만 담당하고, 비즈니스 로직 (계산·검증·흐름) 은 별도 계층 (서비스) 이 담당하도록 분리한다.
비즈니스 로직 안에 SQL 을 직접 박으면, 비즈니스 규칙과 데이터 접근이 뒤섞여 한쪽 변경이 다른 쪽에 영향을 주고, 테스트·재사용·유지보수가 어려워진다.
DAO 는 1990년대부터 자바 진영의 표준 패턴으로, 계층형 아키텍처에서 Controller → Service → DAO → DB 의 데이터 접근 계층에 위치한다.
이 Unit 부터 시작하는 토비의 스프링 여정은 "DAO 코드 한 줄이 어떻게 Spring 의 IoC/DI 까지 진화하는가" 를 따라가며, DAO 의 책임 분리가 그 출발점이다.
비유 — 식당의 역할 분담
DAO = 식당의 창고 담당:
역할 분담:
손님 응대 (Controller):
- 주문 받기
요리사 (Service):
- 비즈니스 로직 (조리)
창고 담당 (DAO):
- 재료 가져오기 (DB 접근)
- 재료 넣기 (저장)
DAO 분리:
- 창고 담당은 "재료 입출고" 만
- 요리는 요리사 (분리)
SQL 박으면 (분리 X):
- 요리사가 직접 창고 정리 + 요리
- 창고 구조 바뀌면 요리법도 수정
- 뒤죽박죽
DAO 분리하면:
- 창고 구조 (DB) 바뀌어도
- 요리사 (비즈니스) 영향 X
- 각자 책임→ DAO = DB 접근 전담 (비즈니스와 분리), 계층 분리의 핵심.
🧭 9개 섹션 로드맵
1. DAO의 정의
2. DAO가 분리하는 책임
3. SQL을 박으면 생기는 문제
4. DAO 패턴의 역사
5. 계층 구조에서의 위치
6. DAO vs Repository
7. DAO의 장점
8. 인터페이스와 구현 분리
9. 면접 + 자기 점검1️⃣ DAO의 정의
1.1 DAO
DAO (Data Access Object):
데이터베이스 접근·조작 기능만
전담하는 객체.
핵심:
- DB 접근 전담
- 비즈니스 로직과 분리1.2 책임
DAO 책임:
- SQL 실행
- 연결 관리
- 결과 → 객체 매핑
- CRUD (Create/Read/Update/Delete)
데이터 접근만 (비즈니스 X)1.3 기본 형태
// DAO 기본 형태
public class ShipmentDao {
public void add(Shipment shipment) {
// DB 저장 (INSERT)
}
public Shipment get(Long id) {
// DB 조회 (SELECT)
return null;
}
public void update(Shipment shipment) {
// DB 수정 (UPDATE)
}
public void delete(Long id) {
// DB 삭제 (DELETE)
}
}
// DB 접근 메서드만1.4 분리의 의미
분리의 의미:
비즈니스 로직:
- 운임 계산
- 검증
- 흐름 제어
데이터 접근 (DAO):
- DB 저장/조회
- SQL
→ 각자 책임1.5 ILIC 의 맥락
// ILIC 의 ShipmentDao
public class ShipmentDao {
// DB 접근만 전담
public void add(Shipment shipment) {
// INSERT INTO shipments ...
}
public Shipment get(Long shipmentId) {
// SELECT * FROM shipments WHERE id = ?
return null;
}
public List<Shipment> findByStatus(String status) {
// SELECT * FROM shipments WHERE status = ?
return List.of();
}
}
// 비즈니스 로직은 Service 가
public class ShipmentService {
private final ShipmentDao shipmentDao;
public ShipmentService(ShipmentDao dao) {
this.shipmentDao = dao;
}
public void processShipment(Shipment shipment) {
// 비즈니스 로직 (검증, 계산)
validate(shipment);
calculateFreight(shipment);
// DB 접근은 DAO 에 위임
shipmentDao.add(shipment);
}
private void validate(Shipment s) { }
private void calculateFreight(Shipment s) { }
}1.6 자기 점검 답변
DAO의 정의는?
답:
1. 정의:
- DB 접근 전담 객체
- 비즈니스와 분리
-
책임:
- SQL, 연결, 매핑
- CRUD
-
분리:
- 비즈니스 vs 데이터 접근
-
형태:
- add/get/update/delete
2️⃣ DAO가 분리하는 책임
2.1 두 책임 분리
DAO 가 분리하는 책임:
비즈니스 로직 책임:
- 도메인 규칙
- 계산, 검증
- 흐름 제어
데이터 접근 책임 (DAO):
- DB 연결
- SQL 실행
- 결과 매핑2.2 왜 분리
왜 분리:
관심사가 다름:
- 비즈니스: 도메인 (운임 정책)
- 데이터: 기술 (MySQL, SQL)
변경 이유 다름:
- 정책 변경 vs DB 변경2.3 분리 전 (혼재)
// ❌ 분리 전 (혼재)
public class ShipmentService {
public void processShipment(Shipment shipment) {
// 비즈니스 + DB 접근 혼재
if (shipment.getWeight() == null) { // 비즈니스
throw new IllegalArgumentException();
}
BigDecimal freight = calculate(shipment); // 비즈니스
// DB 접근 (혼재)
Connection c = DriverManager.getConnection(...);
PreparedStatement ps = c.prepareStatement("INSERT ...");
ps.executeUpdate();
// 비즈니스 메서드에 SQL
}
}2.4 분리 후
// ✓ 분리 후
public class ShipmentService {
private final ShipmentDao shipmentDao;
public void processShipment(Shipment shipment) {
// 비즈니스만
validate(shipment);
BigDecimal freight = calculate(shipment);
shipment.setFreight(freight);
// DB 접근은 DAO
shipmentDao.add(shipment);
}
}2.5 ILIC 의 맥락
// 책임 분리 명확히
public class ShipmentService {
private final ShipmentDao shipmentDao;
private final FreightCalculator freightCalculator;
public ShipmentService(ShipmentDao dao, FreightCalculator calc) {
this.shipmentDao = dao;
this.freightCalculator = calc;
}
public void createBooking(Shipment shipment) {
// === 비즈니스 책임 ===
validateShipment(shipment);
BigDecimal freight = freightCalculator.calculate(shipment);
shipment.setFreight(freight);
shipment.setStatus("BOOKED");
// === 데이터 접근 책임 (DAO 위임) ===
shipmentDao.add(shipment);
}
private void validateShipment(Shipment s) {
// 비즈니스 검증
}
}2.6 자기 점검 답변
DAO가 분리하는 책임은?
답:
1. 두 책임:
- 비즈니스 로직
- 데이터 접근
-
왜 분리:
- 관심사 다름
- 변경 이유 다름
-
혼재 시:
- SQL 이 비즈니스에
-
분리:
- Service / DAO
3️⃣ SQL을 박으면 생기는 문제
3.1 문제 개요
비즈니스에 SQL 박으면:
1. 책임 혼재
2. 변경 영향 확산
3. 재사용 어려움
4. 테스트 어려움
5. 중복3.2 책임 혼재
책임 혼재:
비즈니스 메서드에:
- 도메인 규칙
- SQL
- 연결 관리
→ 한 메서드가 여러 책임
→ SRP 위반3.3 변경 영향
변경 영향 확산:
DB 변경 (MySQL → Oracle):
- SQL 박힌 모든 메서드 수정
- 비즈니스 코드 건드림
정책 변경:
- SQL 도 영향 (혼재)3.4 재사용 어려움
재사용 어려움:
비즈니스에 SQL 박히면:
- 같은 데이터 접근 재사용 X
- 메서드마다 SQL 중복
- DRY 위반3.5 테스트 어려움
테스트 어려움:
비즈니스 + DB 혼재:
- 비즈니스 테스트에 DB 필요
- 단위 테스트 어려움
- Mock 불가 (분리 안 됨)
분리하면:
- DAO Mock
- 비즈니스 단독 테스트3.6 ILIC 의 맥락
@Service
public class SqlEmbeddedProblem {
// ❌ SQL 박힌 비즈니스 (문제투성이)
public BigDecimal calculateAndSaveFreight(Shipment shipment)
throws SQLException {
// 비즈니스
BigDecimal freight = shipment.getWeight().multiply(BigDecimal.TEN);
// DB 접근 (혼재 — 문제)
Connection c = DriverManager.getConnection(
"jdbc:mysql://localhost/ilic", "root", "password");
PreparedStatement ps = c.prepareStatement(
"UPDATE shipments SET freight = ? WHERE id = ?");
ps.setBigDecimal(1, freight);
ps.setLong(2, shipment.getId());
ps.executeUpdate();
ps.close();
c.close();
return freight;
// 문제:
// - 비즈니스 + SQL 혼재
// - DB 변경 시 수정
// - 테스트 어려움 (DB 필요)
// - 다른 메서드도 같은 연결 코드 중복
}
}3.7 자기 점검 답변
비즈니스 로직에 SQL을 박으면 어떤 문제가?
답:
1. 책임 혼재:
- SRP 위반
-
변경 영향:
- DB 변경 시 비즈니스 수정
-
재사용 X:
- SQL 중복
-
테스트 어려움:
- DB 필요, Mock 불가
4️⃣ DAO 패턴의 역사
4.1 역사
DAO 패턴 역사:
1990년대:
- 자바 진영 표준 패턴
- J2EE 핵심 패턴
목적:
- 데이터 접근 추상화
- 비즈니스 분리4.2 J2EE 패턴
J2EE Core Patterns:
DAO 가 핵심 패턴:
- 데이터 소스 추상화
- 영속성 메커니즘 은닉
→ 표준화4.3 진화
DAO 진화:
순수 JDBC DAO:
- Connection, PreparedStatement
→ Spring JdbcTemplate:
- 반복 제거
→ JPA/Hibernate:
- ORM
→ Spring Data Repository:
- 인터페이스만4.4 현재
현재:
Spring Data JPA:
- Repository 인터페이스
- 메서드 이름으로 쿼리
- 구현 자동 생성
DAO 개념은 여전히 유효4.5 ILIC 의 맥락
// 순수 JDBC DAO (전통, 학습용)
public class ShipmentDaoJdbc {
public void add(Shipment shipment) {
// Connection, PreparedStatement (전통)
}
}
// Spring Data JPA Repository (현대)
public interface ShipmentRepository
extends JpaRepository<Shipment, Long> {
// 메서드 이름으로 쿼리 자동 생성
List<Shipment> findByStatus(String status);
List<Shipment> findByBlNo(String blNo);
// 구현 자동 (인터페이스만)
}
// DAO 개념은 동일 (데이터 접근 분리)
// 구현 방식만 진화4.6 자기 점검 답변
DAO 패턴의 역사는?
답:
1. 역사:
- 1990년대
- 자바 표준
-
J2EE:
- Core Patterns
-
진화:
- JDBC → JdbcTemplate
- → JPA → Repository
-
현재:
- Spring Data JPA
- 개념은 유효
5️⃣ 계층 구조에서의 위치
5.1 계층형 아키텍처
계층형 아키텍처:
Controller (표현)
↓
Service (비즈니스)
↓
DAO/Repository (데이터 접근)
↓
DB5.2 각 계층 역할
각 계층:
Controller:
- 요청/응답
- HTTP
Service:
- 비즈니스 로직
- 트랜잭션
DAO:
- 데이터 접근
- SQL
DB:
- 저장소5.3 의존 방향
의존 방향:
Controller → Service → DAO → DB
- 위에서 아래로
- 단방향
- 하위 계층 모름 (상위)5.4 DAO 위치
DAO 위치:
Service 와 DB 사이:
- Service 가 DAO 호출
- DAO 가 DB 접근
→ 데이터 접근 계층5.5 ILIC 의 맥락
// 계층형 구조
// 1. Controller (표현)
@RestController
public class ShipmentController {
private final ShipmentService service;
@PostMapping("/shipments")
public ResponseEntity<?> create(@RequestBody Shipment shipment) {
service.createBooking(shipment); // Service 호출
return ResponseEntity.ok().build();
}
}
// 2. Service (비즈니스)
@Service
public class ShipmentService {
private final ShipmentDao shipmentDao;
public void createBooking(Shipment shipment) {
validate(shipment); // 비즈니스
shipmentDao.add(shipment); // DAO 호출
}
private void validate(Shipment s) { }
}
// 3. DAO (데이터 접근)
public class ShipmentDao {
public void add(Shipment shipment) {
// DB 접근
}
}
// Controller → Service → DAO → DB5.6 자기 점검 답변
계층 구조에서 DAO의 위치는?
답:
1. 계층:
- Controller → Service → DAO → DB
-
역할:
- Service: 비즈니스
- DAO: 데이터 접근
-
의존 방향:
- 위 → 아래
-
위치:
- Service 와 DB 사이
6️⃣ DAO vs Repository
6.1 차이
DAO vs Repository:
DAO:
- 데이터 접근 추상화
- DB 중심 (테이블)
- CRUD
Repository:
- 도메인 객체 컬렉션 추상화
- 도메인 중심 (DDD)
- 객체처럼 다룸6.2 DAO 관점
DAO 관점:
- "DB 에 접근하는 객체"
- 테이블 단위
- SQL/CRUD 중심
- 기술적
add, get, update, delete6.3 Repository 관점
Repository 관점 (DDD):
- "도메인 객체 컬렉션처럼"
- 애그리거트 단위
- 컬렉션 인터페이스 (save, findById)
- 도메인 중심
마치 메모리 컬렉션처럼6.4 실무에서
실무에서:
종종 혼용:
- Spring Data JpaRepository
- 이름은 Repository
- 역할은 DAO 와 유사
엄밀히:
- Repository: DDD 개념
- DAO: 데이터 접근 패턴
→ 맥락에 따라6.5 ILIC 의 맥락
// DAO 스타일 (기술 중심)
public class ShipmentDao {
public void insert(Shipment shipment) { } // DB INSERT
public Shipment selectById(Long id) { return null; } // SELECT
public void updateStatus(Long id, String status) { } // UPDATE
}
// Repository 스타일 (도메인 중심, DDD)
public interface ShipmentRepository {
void save(Shipment shipment); // 도메인 저장
Optional<Shipment> findById(Long id); // 도메인 조회
List<Shipment> findAll(); // 컬렉션처럼
}
// Spring Data JPA (혼용)
public interface ShipmentJpaRepository
extends JpaRepository<Shipment, Long> {
// 이름은 Repository, 역할은 데이터 접근
}6.6 자기 점검 답변
DAO와 Repository의 차이는?
답:
1. DAO:
- 데이터 접근 추상화
- DB/테이블 중심
-
Repository:
- 도메인 컬렉션 (DDD)
- 객체 중심
-
DAO:
- 기술적 (CRUD)
-
Repository:
- 도메인 (save/findById)
7️⃣ DAO의 장점
7.1 장점 정리
DAO 장점:
1. 관심사 분리
- 비즈니스 vs 데이터
2. 유지보수
- DB 변경 격리
3. 재사용
- 데이터 접근 공유
4. 테스트
- Mock 가능
5. 일관성
- 데이터 접근 표준화7.2 관심사 분리
관심사 분리:
- 비즈니스 로직 깨끗
- 데이터 접근 별도
- 각자 집중7.3 유지보수
유지보수:
DB 변경:
- DAO 만 수정
- 비즈니스 영향 X
→ 변경 격리7.4 테스트
// 테스트 — DAO Mock
@Test
void testBusinessLogic() {
ShipmentDao mockDao = mock(ShipmentDao.class);
ShipmentService service = new ShipmentService(mockDao);
// 비즈니스 로직만 테스트 (DB 불필요)
service.createBooking(shipment);
verify(mockDao).add(shipment);
}
// DAO 분리 → Mock → 단위 테스트7.5 ILIC 의 맥락
@Service
public class DaoBenefits {
private final ShipmentDao shipmentDao;
public DaoBenefits(ShipmentDao dao) {
this.shipmentDao = dao;
}
// 1. 관심사 분리 (비즈니스만)
public void process(Shipment shipment) {
validate(shipment); // 비즈니스
shipmentDao.add(shipment); // 데이터 접근 위임
}
// 2. 재사용 (여러 서비스가 같은 DAO)
// ShipmentService, BookingService 등이 ShipmentDao 공유
// 3. 테스트 (Mock 가능)
// ShipmentDao 를 Mock 으로 → 비즈니스 단독 테스트
// 4. DB 변경 격리
// MySQL → PostgreSQL: DAO 만 수정
private void validate(Shipment s) { }
}7.6 자기 점검 답변
DAO의 장점은?
답:
1. 관심사 분리:
- 비즈니스 vs 데이터
-
유지보수:
- DB 변경 격리
-
재사용:
- 데이터 접근 공유
-
테스트:
- Mock 가능
8️⃣ 인터페이스와 구현 분리
8.1 인터페이스 분리
// DAO 인터페이스
public interface ShipmentDao {
void add(Shipment shipment);
Shipment get(Long id);
}
// 구현
public class JdbcShipmentDao implements ShipmentDao {
public void add(Shipment shipment) {
// JDBC 구현
}
public Shipment get(Long id) {
// JDBC 구현
return null;
}
}8.2 왜 분리
인터페이스 분리 이유:
- 구현 교체 가능 (JDBC → JPA)
- 테스트 (Mock 구현)
- 의존성 역전 (DIP)
- 결합도 ↓8.3 구현 교체
// 인터페이스 의존 → 구현 교체 자유
public class ShipmentService {
private final ShipmentDao dao; // 인터페이스
public ShipmentService(ShipmentDao dao) {
this.dao = dao; // 어떤 구현이든
}
}
// JDBC 구현
new ShipmentService(new JdbcShipmentDao());
// JPA 구현
new ShipmentService(new JpaShipmentDao());
// Mock (테스트)
new ShipmentService(mockDao);8.4 DIP 연결
DIP (의존 역전) 연결:
Service 는 인터페이스에 의존:
- 구체 구현 모름
- 추상화에 의존
→ 다음 Phase 들의 핵심
→ IoC/DI 로 발전8.5 ILIC 의 맥락
// 인터페이스
public interface ShipmentDao {
void add(Shipment shipment);
Shipment get(Long id);
List<Shipment> findByStatus(String status);
}
// JDBC 구현
public class JdbcShipmentDao implements ShipmentDao {
public void add(Shipment shipment) { /* JDBC */ }
public Shipment get(Long id) { return null; }
public List<Shipment> findByStatus(String status) { return List.of(); }
}
// JPA 구현 (교체 가능)
public class JpaShipmentDao implements ShipmentDao {
public void add(Shipment shipment) { /* JPA */ }
public Shipment get(Long id) { return null; }
public List<Shipment> findByStatus(String status) { return List.of(); }
}
// Service 는 인터페이스에 의존 (구현 무관)
public class ShipmentService {
private final ShipmentDao dao; // 인터페이스
public ShipmentService(ShipmentDao dao) { this.dao = dao; }
}
// → 이 분리가 IoC/DI 의 토대 (Phase 6~8)8.6 자기 점검 답변
DAO 인터페이스와 구현 분리는?
답:
1. 분리:
- 인터페이스 + 구현
-
이유:
- 구현 교체
- 테스트 (Mock)
-
교체:
- JDBC ↔ JPA ↔ Mock
-
DIP:
- 추상화 의존
- IoC/DI 토대
9️⃣ 면접 + 자기 점검
9.1 면접 단골 질문 매핑
| Q | 핵심 답변 |
|---|---|
| DAO? | DB 접근 전담 객체 |
| 분리 책임? | 비즈니스 vs 데이터 |
| SQL 박으면? | 혼재, 변경 영향 |
| 역사? | 1990년대 J2EE |
| 계층 위치? | Service 와 DB 사이 |
| DAO vs Repository? | 기술 vs 도메인(DDD) |
| 장점? | 분리/유지보수/테스트 |
| 인터페이스 분리? | 구현 교체 |
| DIP 연결? | 추상화 의존 |
| Spring 진화? | DAO 가 출발점 |
9.2 자기 점검 체크리스트
DAO
- 정의
- 책임
분리
- 비즈니스 vs 데이터
SQL 박으면
- 문제들
역사
- J2EE
계층
- 위치
DAO vs Repository
- 차이
장점
- 정리
인터페이스
- 구현 분리
9.3 추가 심화 질문
Q1: DAO 와 Service 트랜잭션?
답:
- 트랜잭션은 보통 Service 계층
- @Transactional (Service)
- DAO 는 단일 작업
- Service 가 여러 DAO 조합 + 트랜잭션
Q2: DAO 에서 예외 처리?
답:
- SQLException (checked)
- 보통 unchecked 로 변환
- Spring: DataAccessException
- 비즈니스에 기술 예외 노출 X
Q3: DTO 와 DAO 관계?
답:
- DTO: 데이터 전송 객체 (계층 간)
- DAO: 데이터 접근 객체
- DAO 가 DTO/Entity 반환
- 역할 다름
Q4: Active Record vs DAO?
답:
- Active Record: 객체가 자기 저장 (save())
- DAO: 별도 객체가 저장
- 자바는 보통 DAO
- Rails 는 Active Record
Q5: DAO 단위 테스트?
답:
- 실제 DB (통합 테스트)
- 임베디드 DB (H2)
- @DataJpaTest
- Testcontainers
🎯 핵심 요약 — 3줄 정리
1. DAO
- 데이터베이스 접근 전담 객체
- 비즈니스 로직과 데이터 접근 분리
2. 분리 이유
- SQL 박으면: 책임 혼재, 변경 영향, 테스트 어려움
- 분리: 유지보수, 재사용, 테스트 용이
3. 진화의 출발점
- 계층: Controller → Service → DAO → DB
- 인터페이스 분리 → IoC/DI 토대 (이후 Phase)
📚 다음으로...
Unit 3.2 — 전통 DAO의 코드 (모든 책임을 떠안은)
이번 Unit에서 DAO 개념을 봤다면, 다음은 전통 DAO 코드 (문제 진단).
- 드라이버 로딩, 연결, SQL, 자원 해제
- 한 메서드에 여러 관심사
- DB 변경 시 수정 범위
Phase 3 진행 상황
🌱 Phase 3 — 전통 DAO의 문제
✅ Unit 3.1 DAO란 무엇인가 ← 여기
⏭ Unit 3.2 전통 DAO의 코드
⏭ Unit 3.3 책임 혼재5주차 누적 진행
✅ Part A — 동시성 마무리 (7 Unit)
🌱 Part B — 토비의 스프링
Phase 3 — 전통 DAO (1/3 진행)
총: 8/26 Unit🌱 Part B 시작 — 토비의 스프링: 객체 설계의 진화
Software Developer