#001-01 프로젝트 구조 결정 및 생성

개인 프로젝트

#001-01 프로젝트 구조 결정 및 생성

도미노& 2024. 2. 11. 14:32

0. 환경

원하는 바가 있는 관계로 언어와 DB는 이미 정한 상태이다.

언어는 Kotlin, DB는 MySQL, JDK는 OpenJDK17.

혹시나 프론트까지 하게 된다면 플러터(Flutter) 혹은 리액트(React)로 해 보려고 하는데..

이건 아직 결정 못 했다.

프로젝트 내용은 이커머스 따라하기.

JDK 다운로드 링크 : https://jdk.java.net/java-se-ri/17

1. 프로젝트 구조 결정

▼ 프로젝트 구조를 고민하게 된 계기 (a.k.a 삽질.. 모르면 몸이 고생한다.)

회사에서 이번에 진행될 프로젝트는 MSA 구조로 진행하자고 결정했다.

나는 다른 프로젝트에 투입되어 있던 관계로, 개발 PL이 있었으니 그걸 결정할 당시 나는 전혀 모르는 상태였다.

그 다른 프로젝트에 남은 게 많아 혼자 남아서 마무리하게 될 거라는 이야기를 들은 상태였다.

그런데 갑자기 인력 편성이 변경되어 내가 투입되게 됐는데, 와서 보니 개발 환경이 어느 것도 준비되어 있지 않았다. 해결은 해야 하므로 전자정부프레임워크 MSA를 적용해 개발하다보니 너무 생산성이 떨어지며 불편한 점을 느끼게 되었다.

처음 전자정부 MSA를 내려받으면 여러 마이크로 서비스 중 module-common이라는 프로젝트가 있는데, 해당 부분이 공통 모듈(인증/인가/필터 등의 설정이 되어 있음) 각 서비스(user-service, board-service 등)에 포함된다.

처음 받은 MSA 프로젝트 구조를 그려 보자면,

workspace

└ module-common

　└ moule-common.jar

└ user-service

└ board-service

이런 구조였는데,

user-service와 board-service가 module-common 프로젝트 밑에 있는 module-common.jar를 바라보도록 build.gradle에 implementation 되어 있었다.

dependencies {
	implementation files('../module-common/module-common-4.1.0-plain.jar')
}

개발하던 중 인프라 쪽에서 개발 서버를 올려 주는 과정에서 아래와 같이 파일 위치를 변경했다.

(인프라 설정을 해 준 사람이 개발자가 아니라 로컬 환경은 고려하지 않고 위치를 변경함)

workspace

└ module-common

└ user-service

　└ moule-common.jar

└ board-service

　└ moule-common.jar

아마 서비스 프로젝트들이 module-common 하위에 있는 jar를 바라보지 못해서 각 서비스 프로젝트 하위에 jar를 바라보도록 변경한 듯했다.

dependencies {
	implementation files('./module-common/module-common-4.1.0-plain.jar')
}

처음엔 module-common에 작업을 할 생각이 없었기에 개의치 않았는데, 점점 공통으로 처리를 할 게 많아지면서(프론트엔드에 줘야 할 응답 구조 변경, 그에 따른 에러 처리, 응답코드의 상수화 등) 문제점이 발생했다.

각 프로젝트에 jar를 올릴 때면 IDE(회사에서는 이클립스)를 종료해야 했고, 종료하지 않으면 소스가 꼬일 확률이 커진다.

(소스를 내려받다가 jar 파일로 인해 받을 수 없다는 메시지와 함께 내려받는 것이 종료되는데, 이미 받은 파일은 롤백도 안 되고 손수 다시 정리해야 한다. 정리하다 헷갈리면 파일 다 날려 먹는다. 예로 신규 파일을 만들었는데 내려받는 중에 충돌이 나서 작업한 파일 다 날려먹고 다시 작업한 친구가 있다.)

또, 내가 공통 처리를 하다 보니 디버깅이 어려워서 불편한 점이 이만저만이 아니었다.

내가 겪은 불편함이 생기지 않는 프로젝트 구조를 결정하기 위해 프로젝트를 상속받을 수 있는 방법에 대해 검색해 보니, 원하는 문구와 함께 블로그를 발견.