DAO·DTO 패턴

DAO·DTO 패턴이란

DAO(Data Access Object)와 DTO(Data Transfer Object)는 애플리케이션에서 데이터를 다루는 책임과 데이터를 옮기는 책임을 서로 다른 객체로 분리하는 설계 패턴이다. DAO는 데이터베이스나 외부 저장소에 접근해 조회·저장·수정·삭제를 수행하는 실제 작업을 담당한다.

DTO는 그렇게 오간 데이터를 계층과 계층 사이로 실어 나르는 단순한 그릇으로, 자체적인 비즈니스 로직을 거의 갖지 않는다. 두 역할을 명확히 갈라 두면 데이터 접근 방식이 바뀌어도 상위 계층은 영향을 덜 받는다.

왜 계층을 나누는가

비즈니스 로직과 데이터 접근 코드가 한곳에 뒤섞이면 저장소를 교체하거나 SQL을 수정할 때마다 서비스 전반을 손대야 한다. DAO는 저장소 접근을 인터페이스 뒤로 숨겨, 구현이 관계형 데이터베이스든 NoSQL이든 호출하는 쪽 코드를 동일하게 유지한다.

DTO는 도메인 객체를 그대로 외부에 노출하지 않고, 전송에 필요한 필드만 추려 담음으로써 계층 간 결합도를 낮춘다. 이렇게 책임을 분리하면 변경의 파급 범위가 줄고, 각 계층을 독립적으로 시험할 수 있는 기반이 마련된다.

DTO와 도메인 객체의 차이

도메인 객체는 업무 규칙과 상태를 함께 지니며 시스템의 핵심 의미를 표현한다. 반면 DTO는 그 상태의 일부를 평면적으로 옮기기 위한 임시 운반체에 가깝다.

화면이나 API가 요구하는 형태와 내부 도메인 모델의 구조는 자주 어긋나는데, DTO는 그 간극을 흡수하는 완충 역할을 한다. 도메인을 그대로 응답으로 내보내면 내부 구조가 외부 계약에 묶여 변경이 어려워지므로, 경계에서 DTO로 한 번 변환하는 절차를 두는 편이 견고하다.

CBD와 스프링에서의 자리

이 패턴은 시스템을 재사용 가능한 부품으로 조립하는 컴포넌트 기반 개발(CBD) 사고와 잘 맞물린다. 각 컴포넌트가 데이터 접근을 DAO로 캡슐화하고 외부와는 DTO로 소통하면, 부품 단위의 교체와 조합이 수월해지기 때문이다.

자바 진영에서는 스프링 프레임워크가 이 구조를 사실상 표준 관행으로 정착시켰다. 데이터 접근 계층을 분리하고 의존성 주입으로 구현을 갈아 끼우는 방식은 DAO·DTO 패턴이 추구하는 분리 원칙과 본질적으로 같은 지향을 가진다.

흔한 오용과 균형점

패턴을 형식적으로만 받아들이면 계층마다 거의 동일한 DTO를 중복 생성하고, 객체 사이를 변환하는 코드만 늘어나는 부작용이 생긴다. 단순한 조회 위주의 작은 서비스에서는 과도한 분리가 오히려 생산성을 떨어뜨릴 수 있다.

따라서 분리의 깊이는 시스템의 복잡도와 변경 빈도에 비례해 조정해야 한다. 외부 계약이 자주 바뀌거나 저장소 교체 가능성이 높은 영역에는 분리를 충실히 적용하고, 변동이 적은 내부 영역에서는 변환 비용을 의식적으로 줄이는 판단이 필요하다.

패턴은 목적이 아니라 변경에 대비한 수단이라는 관점이 핵심이다.

디자인 패턴으로서의 의의

DAO·DTO는 객체지향 설계의 여러 디자인 패턴 가운데 데이터 경계를 다루는 대표적 관용구로 자리 잡았다. 접근 책임을 한곳에 모으는 DAO는 추상화를 통한 교체 용이성을 제공하고, 운반 책임을 맡는 DTO는 계층 간 계약을 안정시킨다.

이 둘은 단독으로 쓰이기보다 서비스·리포지토리·매퍼 같은 주변 구조와 함께 엮여 데이터 흐름의 골격을 이룬다. 결과적으로 시스템의 유지보수성과 시험 가능성을 끌어올리는 기초 설계 자산으로 기능한다.