[Architecture] 웹 구조 설계하기

엘리스에서 진행한 첫 팀 프로젝트다.

3주간 데이터 분석 웹 서비스를 제작해야한다.

 

저번 개인 프로젝트가 끝나고 새 프로젝트에 적용해보고 싶었던 것이 있었다.

MVC 구조 구현해보기다.

 

MVC에 대해서 지금껏 이론만 배웠지 실제로 MVC구조라고 할만한 프로젝트를 진행해본 경험이 없는 것 같다.

그래서 이번 프로젝트에서 첫 시도를 해보고 싶었다.

 

코치님께 자문을 구했다.

알려주신 방법이 MVC 구조는 아닌듯 하지만 뭔가 메커니즘은 비슷해보였다.

현업에서 쓰이는 구조를 알려주신다고 하셨다.

크게 3가지 레이어로 나뉜다고 하셨다.

 

클라이언트로부터 요청을 받는 API.

서버에서 실질적으로 요청을 처리하는 Service.

데이터베이스 모델 생성과 쿼리 실행을 담당하는 Domain.

 

그리고 API는 또 Controller와 DTO(Data Transfer Object) 로 나뉜다.

Domain은 Model과 DAO(Data Access Object) 로 나뉜다.

 

Controller 에서 요청을 수신하면 요청과 데이터를 Request DTO 포맷에 맞춰 Service 로 보낸다.

또 Service 에서 요청을 처리하고 나면 다시 Response DTO 포맷에 맞춰 클라언트로 보내준다.

 

Domain 에는 데이터베이스 ORM 연결과 Migration을 위한 Model 파트와

데이터베이스에 접근하여 쿼리를 실행하는 DAO 파트로 나누어져 있다.

Model 에 의해 데이터베이스 테이블이 생성되고, Service 레이어에서 DAO를 호출해 데이터를 생산, 조회한다.

 

여기서 궁금한 것은 DTO와 DAO 였다.

DTO와 DAO라는 파트를 따로 분리해서 관리하는 이유는 무엇일까?

 

DTO를 분리하는 이유는 3가지가 있다.

 

1. DTO를 사용하지 않으면 엔티티의 변경에 의해 API 스펙이 변경될 수 있다.

2. 하나의 엔티티에 대해서 여러 API가 존재할 수 있다.

3. DTO를 사용하지 않고 엔티티를 그대로 넘겨주면, 엔티티가 가진 정보 외의 것들은 넘겨주지 못한다.

https://codeung.tistory.com/319 블로그를 참고했다. (자세한 내용은 블로그로)

 

그럼 DAO는?

역시 DTO랑 비슷한 이유다.

결국 프로그램이 복잡해질 때 API의 복잡성을 줄이고 유지보수에 있어 용이하기 때문이다.

 

 

전체적인 프로젝트 구조가 아래와 같다.

프로젝트 구조

전체 구조와 데이터 흐름만 표현했고, 파일명은 일부만 적어놨다.

 

이렇게 했을 때의 장점이 무엇일까?

일단 이러한 계층구조의 장점이라하면 각 모듈별로 역할이 분리되고 독립적으로 실행되기 때문에 협업과 유지보수에 매우 용이하다는 장점이 있다.

이러한 장점을 이번 프로젝트에서 몸소 느꼈는가? 라고 물어본다면

잘 모르겠다...

 

확실히 백엔드의 내부 로직을 수정한다고 했을 때 코드 전체를 갈아 엎어야할 정도로 어지러웠던 일은 없었고,

어떤 파일의 어떤 코드를 수정해야할지 쉽고 빠르게 파악할 수 있었다.

그래서 그날 스크럼회의때 나왔던 아이디어를 코드로 금방 구현할 수 있었다.

또 추가적으로 기능을 구현할 때에도 기존에 만들어진 코드에 영향을 받지 않고 편하게 작업할 수 있었다.

 

그런데 잘 모르겠다고 말하는 이유는 이번 프로젝트가 워낙 소규모였기 때문이다.

프로젝트가 소규모 였기 때문에 편했던 것인지, 구조를 잘 나누어 놓았기에 편했던 것인지 확신할 수 없었다.

또한 DTO와 DAO의 편리성에 대해서도 체감이 되지 않았다.

아마도 프로젝트의 규모가 더 커지고 프로그램이 복잡해져야만 체감해볼 수 있을 것 같다.

그래도 코치님께 컨펌 받으며 이렇게 구조라는 형태를 띄는 형식으로 프로젝트를 진행해봤다는 것에 큰 의의를 두었다.

 

앞으로 더 큰 규모의 프로젝트를 진행하며 보완해야할 부분은 보완하고 새롭게 시도해볼만한 웹 구조가 있다면 시도해보고 싶다.