2022 Masters Course/Project Course

2022 마스터즈 코스(백엔드) 113일차 회고(2022. 6. 22.) - "SQL과 비즈니스 로직의 역할 구분하기"

ikjo 2022. 6. 23. 00:39

해당 글은 코드스쿼드 2022 마스터즈 코스 "Java 웹 백엔드" 과정을 수강하면서 학습한 내용 등에 대한 회고 글입니다. :)

 

수강 회고

오늘로 벌써 마지막 팀 프로젝트 기간도 절반에 달했다. 그래도 그동안 3번의 팀 프로젝트를 진행하면서 나름대로 열심히 하면서도 그래도 약간의 여유를 느끼곤 했었는데, 이번 미션 과제의 경우는 왠지 첫 날부터 마지막 날까지 굉장히 정신이 없을 것 같다. 개인적으로는 지난 팀 프로젝트들 대비 이번 팀 프로젝트 미션 과제가 좀 더 헤비(?)한 느낌이다.

 

기능을 구현하고나면 해당 기능에 대해 프론트 엔드 팀원들께서 (프론트 엔드 작업 관련) 피드백을 주시는데, 이를 통해 다시 기존 기능들을 보완 및 개선하는데 드는 시간도 만만치 않았다. 하지만 그 요청사항들을 적용하는 과정에서 오히려 내 서비스 로직이 이전 보다 개선되는 것을 확인할 수 있었다.

 

사실 이번 팀 프로젝트 뿐만 아니라 지난 팀 프로젝트를 하면서도 느낀 것이 백엔드 입장에서 개발을 하다보면 "사용자 입장에서" 생각을 하지 못할 때가 많은 것 같았다. 프론트 엔드 팀원들과 같은 기획서를 봐도 백엔드는 어떻게 하면 API를 클라이언트에 제공할지에 초점을 둔다면, 프론트 엔드에서는 어떻게 하면 사용자 입장에서 편익을 느끼는지에 대해 초점을 맞추는 것 같다. (개인적인 느낌과 경험이다.)

 

이로 인해 어떤 API를 구현하더라도 이에 대해 프론트 엔드 팀원들의 피드백 사항들에 대해 적극적으로 반영하고자 하는 마인드를 가질 필요성을 느끼고 있다.

 

 

학습 회고

클라이언트에서 어떤 API를 호출 시 서버 단에서는 해당 API의 URL에 매핑되는 핸들러(컨트롤러) 메서드를 호출하고 해당 컨트롤러는 이 요청을 처리할 서비스(비즈니스 로직 수행) 단의 메서드를 호출한다. 이때 데이터 베이스 상에 저장된 데이터가 필요할 경우 데이터 베이스에 접근하기 위해 리포지토리(데이터 베이스 연결, SQL 전달 등 수행) 단의 메서드를 호출한다. 리포지토리로부터 데이터를 전달받으면 서비스는 이를 적절하게 처리 및 가공하여 컨트롤러 단에 반환하고 이 데이터는 클라이언트로 전달된다.

 

대부분이 그러하듯이 나 같은 경우에도 스프링 부트 웹 앱을 개발할 때 이처럼 "컨트롤러-서비스-리포지토리" 각각의 역할과 책임을 분리한다. 이때 항상 마음 한구석에 걸리던 부분이 있었는데, 바로 서비스와 리포지토리간의 역할과 책임에 대한 구분에 대한 것이었다.

 

리포지토리에서는 DB에 접근하여 데이터를 가져온다. 예를 들어, MySQL의 경우 SQL을 전달받는데, where, group by, having 등 여러 조건절들을 통해 필요한 데이터들만을 추출해올 수 있다. 비즈니스 로직을 수행하는 서비스 단에서는 이를 전달받아 클라이언트에 전달해줄 형식으로 데이터를 처리 및 가공하여 컨트롤러 단으로 반환한다. 여기서 "데이터 추출"과 "데이터 처리 및 가공" 부분이 다소 모호하다는 생각이 들었다.

 

"데이터를 추출해올 때 어느정도 필요한 데이터들로만 처리 및 가공할 수 있는 것 아닌가?", "하나의 쿼리로(적은 DB 커넥션으로) DB에서 데이터를 최대한 필터링하여 가져오는 것이 더 좋지 않을까?" 등의 생각이었다. 일반적으로 DB에서 데이터를 처리하는 속도가 애플리케이션 단에서 데이터를 처리하는 속도 보다 일반적으로 성능이 좋다는 이야기도 많다. 물론 상황에 따라 면밀하게 비교해봐야겠지만 말이다.

 

그런데 이렇게 하나의 쿼리로 데이터에 대해 많은 처리하다보면 쿼리문의 복잡도가 상당히 올라가고 유지보수에 대한 고민도 생기기 시작한다.(그래도 Spring Data JPA와 Querydsl을 사용하면 많이 개선된다.) 애플리케이션에서는 메서드 단위별로 책임을 구분하여 나름대로 가독성있게 코드를 작성할 수 있다.

 

아울러, 클라이언트가 필요로 하는 데이터에 따라 DB에서 처리가 불가능한 경우도 있다. 이때는 애플리케이션 단에 위임하여 처리하도록 해야한다. 이를 구분하는 것 역시 앞으로 개발할 때 중요한 포인트(point)라는 생각이 들었다. 김영한님의 강의에서 이런 말을 들은 적이 있다. "DB에서는 데이터를 퍼올리는 데 집중하고 데이터를 처리하고 가공하는 것은 애플리케이션 단에 위임해야한다."

 

물론 개발에 정답은 없겠지만 이는 앞으로 웹 개발을 하는데 지속될만한 고민 거리인 것 같다. 아마 주어진 특수한 상황에 따라 또 다를 것이다. 그래도 이번 팀 프로젝트 미션 과제를 수행하면서 단일 쿼리문을 통한 데이터 처리의 한계를 느껴봤는데, 그것이 DB 단에서 처리하는 내용과 애플리케이션 단에서 처리하는 내용에 대해 좀 더 구별되게 생각할 수 있었던 계기가 된 것 같다.

 

 

좋았던 점

  • 프론트 엔드 팀원들께서 주신 의견들을 적극 반영하려고 노력하고 있습니다. 그런데 주신 의견들을 반영하다 보니 서비스 로직에서 미흡한 점들을 고쳐나갈 수 있어 오히려 감사한(?) 마음이 들었습니다. 👍

 

 

아쉬웠던 점

  • 원래 오늘은 S3에 이미지 업로드 및 링크 반환 작업 처리를 진행하려고 했었는데, 기존 이슈 목록 검색 기능을 개선 작업하느라 진도를 나가지 못했습니다. 💦

 

 

이전 보다 개선되었던 점

  • 이번 미션 과제를 수행하면서 SQL과 비즈니스 로직간의 역할 차이를 좀 더 이해할 수 있 있었습니다. 🥕