ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 커다란 만능 모듈을 사용하면 만날 수 있는 함정
    운영 중인 서비스/Coconut. 2024. 4. 30. 17:06

     

    여러 서비스에서 공유되는 모듈을 만들어서 사용하는 과정에서 만난 이슈를 적어봅니다.

    모듈을 분리하고 개별 서비스에 각각 적용하는 과정을 정리하고 있습니다.


     

    이번 글은 아래와 같은 순서로 작성되었습니다.

    1. 모든 일을 하는 만능 모듈

    2. 만능 모듈의 단점

    3. 어떤 기준으로 분리할 것 인가?

    4. 변경 반영하기

    5. 정리하기

     

     

    1. 모든 일을 하는 만능 모듈

    코코넛 서비스에 기능이 붙어가면서 점점 복잡도가 올라가고 있습니다.

    global이란 모듈에서 여러 서비스간에 공유되는 코드를 관리하고 있습니다.

    어느 순간 복잡성에 문제가 생길 것이라고 예상은 했지만 너무 빠른 시점에 찾아오고 말았습니다..

     

     

     

    글로벌 모듈의 build.gradle 파일의 일부입니다.

     

     

    엔티티를 만들 때, 중복되는 요소들을 상속받아서 사용하기 위한 BaseEntity가 있어서 jpa와 querydsl 관련 의존성들이 포함되었습니다.

     

     

    2. 만능 모듈의 단점

     

    기존의 커뮤니티, 퀴즈, 유저 서비스는 모두 JPA를 사용하고 있기 때문에 아무런 문제가 없었으나..

    새로 추가하는 인증 서비스에는 JPA가 필요없기에 관련 설정을 추가하지 않았습니다.

    하지만 자꾸 jpa 의 사용에 필요한 datasource의 url이 없다는 군요?

    글로벌 서비스에 있는 jpa가 url을 애타게 찾고있는 모양입니다.

     

     

    글로벌 모듈에서 사용되는 jpa 때문에, 인증서버에서 사용되지 않는 jpa 설정을 추가해야할까요?

    이 부분을 건드리면 다른 모든 서비스에 수정이 발생해서 최대한 피해가는 방법을 찾아봤지만 마땅한 방법을 찾지못했습니다.

    결국 global 모듈에서 JPA 관련 내용을 분리해서 별도의 모듈로 관리하고 JPA가 필요한 서비스에서만 해당 모듈을 사용하는 방향으로 수정을 합니다. (빨리 인증 기능 구현해야되는데 .. ㅜㅜ )

     

     

    3. 어떤 기준으로 분리할 것인가?

    컴퓨터 공학에서 정론이라 인정되는 범위들 안에서 개발자들은 각자의 취향이 어느정도 반영된 선택을 이어나간다고 생각합니다.

    (저 같은 경우는 관리 포인트가 조금 늘더라도 작은 모듈을 선호하는 편이라, 나눌까 말까 고민되면 일단 나누고 보는 스타일입니다 ㅎㅎ)

     

    기존에 작업하던 React 생태계에서는 나름의 기준이 있었지만 spring에서는 아직 충분한 경험이 없기에 무엇을 기준으로 global 모듈을 나누는 것이 적합할지 바로 떠오르지 않습니다. 

     

    그래서 일단은 JPA에 대한 의존성을 갖는가? 를 기준으로 분리해봅니다.  새로운 모듈 이름은 jpa_utils로 명명해보겠습니다 ㅎㅎ

    뜯어내어 보니 이 정도가 분리될 수 있을 것 같습니다.

     

    JPA를 다루면서 발생하는 Exception을 관리하는 advice와 위에 언급했던 BaseEntity 그리고 페이지 관련 api에서 필수로 사용되는 요소들을 모아둔 ListReqDto, ListResDto 입니다.

     

     

    build.gradle 의존성의 경우도 JPA와 querydsl 정도로 분리가 됩니다.

    왼편에는 아주 간결해진 global 모듈의 build.gradle 파일이고, 오른편은 jpa_utils의 build.gradle 입니다.

     

     

     

    4. 변경 반영하기

    이제 jpa를 사용하는 서비스에 분리된 jpa_utils를 반영해줍니다.

     

     

    새로운 내용이 반영된 이후에도 정상작동을 하는지 테스트를 돌려줍니다.

     

     

    테스트를 통해서 컴포넌트 스캔이 안되는 부분 발견하고 scan 범위에 추가해주었습니다.

     

     

    이후에 repo에 푸쉬하여 ci/cd까지 정상적으로 동작하는지 확인합니다.

    도커 파일에 누락된 부분 찾아서 바로 수정해줍니다.

     

     

    퀴즈와 커뮤니티 서비스 모두 ci/cd 정상적으로 작동하는 것을 보니 마음이 편안해집니다 ㅎㅎ

     

     

     

    사담이지만, 수정이 빈번해질 수록 테스트와 ci/cd의 소중함을 느낍니다ㅎㅎ

     

     

    5. 정리하기

    하나의 큰 모듈을 두면 관리 포인트가 줄어드는 장점이 있기 때문에 확실히 순간에는 빠른 작업이 가능한 듯 보이나, 일정 시점이 지나면 분명 문제를 발생시키는 요소가 된다고 생각이 듭니다 ㅎㅎ 프로젝트에 맞는 적절한 형태를 선택하는 것이 필요하겠습니다.

     

     

     

    코코넛 서비스 같이 굉장히 작은 서비스도 모듈 늘어나는게 느껴서서 관리 부담이 좀 듭니다 ㅎㅎ

    감사합니다.

     

     

     

     

Designed by Tistory.