들어가기 전에
이번 프로젝트에서 초기 개발 사양을 다음과 같이 정했다.
- 자바 17
- Spring boot 3.0.4
- Gradle
- MySQL, MyBatis
- JUnit5, 모키토
- Jenkins
- 도커
매번 정보는 많이 찾아보면서 결정하는데도 고민하고 있던 흔적을 남길 시간이 없었기 때문에 이번에는 제대로 정리를 해야 한다는 생각이 들었다.
자바 17
우선 제가 자바 17을 응시하기 시작했을 때 주니어 스터디에서 가장 심혈을 기울였다 자바 인터뷰 대비 연구할 때였다.
그때, Java 버전별로 차이를 찾아 발견한 문장이 있습니다만, 여기서 어떻게 기술 블로그에 올라왔다 우리 팀이 JDK 17을 도입한 이유이었다.
아직 Java 8을 사용하는 데 사용하는 이유와 Java 17을 선택한 이유에 대해 자세히 설명합니다.
상기 블로그의 내용을 짧게 요약하면 내용은 다음과 같다.
왜 Java 8을 아직 많은 개발자가 사용하고 있습니까?
- 발표된 LTS 버전 중 가장 긴 기간 동안 지원되는 버전
- 기존 Java 8에서 개발된 서비스와의 호환성
왜 Java 17을 선택했습니까?
- Java 17의 지원 기간이 Java 8보다 약 1년여 밖에 차이가 없기 때문에, 지원 기간이 짧으면 균등하게 될 이유가 없었다.
- 다음 LTS 버전으로 전환할 때를 비롯하여 최신 기술을 적응해 둔다.
- Spring Boot 3.0 이후, Java 17 이후를 지원하기 위해 차세대 플랫폼과의 호환성을 준비한다.
개인적으로는 최근 프로젝트에서 Java 11을 사용하고 있었지만, Java 17까지 업데이트된 기능 중에 활용할 수 있는 것이 없는 것 같다는 판단하에 친숙한 버전을 선택했습니다.
그런데 YouTube의 강의를 보면 Record의 이야기도 듣고, Sealed 클래스와 같이 새롭게 도입된 기능을 알게 되었으므로, 샘플 코드가 아니라 직접 프로젝트에 사용해 보고 싶다는 생각이 들어 있어, 이번 프로젝트에서 무조건 Java 17을 사용해야한다고 생각했습니다.
무엇보다 Spring boot 버전도 최신 버전으로 사용하기 때문에, 호환성의 문제도 없었다.
실은 상용화를 염두에 두고 있는 프로젝트가 아니기 때문에, 회사에서 선정하는 기준과는 조금 차이가 있을지도 모르지만, 이러한 버젼에 대해 고민해 보면, 회사에서는 어떻게 기준을 두는지에 대해서 도 생각하게 되었다.
Gradle
이 도표를 작년의 회사 미팅 때에 처음 본 것입니다만, 그 때, 사수님이 Gradle가 Maven과 어떤 차이가 있는가 Gradle의 홈페이지에 기재되어 있는 문서를 번역해 설명해 주셨습니다.
홈페이지에 나온 차이를 간단히 정리해 보면 다음과 같다.
- 빌드 시간이 빠릅니다.
- 빌드 캐시 사용/변경된 파일만 빌드/데몬 프로세스 지원
- Maven은 지정된 리포지토리 만 사용할 수 있지만, Gradle은 여러 리포지토리를 사용할 수 있습니다.
- Maven에 비해 종속 버전 관리는 유연합니다.
그리고 내가 가장 큰 느낌은 XML 파일로 관리하는 것보다 훨씬 읽기 쉽고 편안하다는 것입니다.
그래서 이번 프로젝트에서도 Gradle로 선택하고 싶었다.
MySQL
MySQL만의 특정 점을 고려했다기보다는 가장 서로 익숙하고 낯선 DBMS를 선택했다.
그래도 이번에는 협업하는 개발자들이 어떤 DBMS가 익숙한지 몰랐기 때문에 왜 써야 하는지에 대해 스스로 찾아 보았다.
- 오픈 소스와 호환성 – 호환성이 좋으며 누구나 설치하고 사용할 수 있습니다.
- 빠르고 안정적 - 속도를 중점적으로 개발하고 안정성이 인정되었습니다.
그리고 배우고 사용하기가 비교적 간단합니다. - 가용성 – 다양한 백업 및 복구 전략 사용
실은 다른 DBMS와 비교해 본 경험이 없어서 2, 3번은 잘 모르겠지만, 1번은 확실히 내가 편하게 사용하고 있기 때문에 목을 끄덕이게 되었다.
이번에는 SQL 레벨업을 공부하면서 JOIN에 사용되는 알고리즘을 공부했지만, MySQL에서는 NL과 NL의 파생 버전만을 사용하고 있는 것으로 나타났다.
그리고 이번 블로그에 내용을 정리하고 다시 한번 공식문서를 보았는데 그때는 발견되지 않았던 해시조인이 8.0 이상에서는 도입된 것으로 나타났다.
물론 다른 DBMS도 지속적으로 업데이트되지만, 사용하고 있는 제품으로 계속해서 퍼포먼스를 위해 개선하고 있다는 것을 알게 되었으므로, 더 잘 접하고 있던 것 같다.
JUnit 5, 모키토
과거 프로젝트에서 테스트 코드의 중요성을 많이 느꼈고, 그다지 익숙하지 않은 바람에 시달리고 있었기 때문에 이번에는 프로젝트 시작 전에 미리 책을 사서 읽었다.
테스트 주도 개발 시작라는 책인데 그동안 별로 기초 없이 전혀 받아들인 듯한 느낌이 들고, 기초에 충실한 책을 추천받았지만, 개념 정리가 잘 됐다.
그리고 이 책을 통해서 테스트 코드가 항상 대답은 되지 않지만, 제대로 짠 테스트 코드가 전제가 되었을 때는, 어떤 이점을 얻을 수 있는지를 잘 알게 되었다.
그리고 한층 더 테스트 코드를 잘 짜고 싶다는 욕심이 들렸다.
이전 단위 테스트라고 하는 책도 보면서 Mocking에 대해 나쁜 의견이 있다는 사실도 알게 되어, 이에 관해서 멘터님께 질문도 했지만, 결국은 내가 직접 경험해 보지 않으면 어떤 점이 좋지 않고, 어떤 때는 정말 필요한 것을 느낄 수 있는 것 같다.
이번 프로젝트에서는 테스트 코드도 많이 짜면서 습관을 제대로 갖고 싶다.
Jenkins
옵션을 Github Actions와 Jenkins로 줄였습니다.
Github Actions | Jenkins |
– 기능이 다른 도구에 비해 적지만 개인 프로젝트처럼 규모가 작은 프로젝트에서 사용할 수는 없습니다. – 추가 설치 없이 Github에서 사용할 수 있습니다. |
– 가장 오래된 도구이므로 관련 문서가 많고 사용자가 많습니다. – 다양한 플러그인이 있습니다. – 규모가 작은 프로젝트의 경우 자원 낭비가 발생할 수 있습니다. |
더 자세한 차이는 이 블로그 기사에서 볼 수 있다.
정말 정중하게 잘 정리해 두었다.
결론적으로, Github Actions는 지금 우리처럼 소규모 프로젝트에서는 괜찮지만, 나도 그랬고, 함께 있는 쪽의 회사에서도 모두 Jenkins를 사용해 보면, Jenkins를 도입해 경험을 쌓는다 라는 결론이 나왔다.
실제로, 지금 병행하고 있는 다른 프로젝트에서는 Github Actions를 선택했지만, 정말로 소규모의 프로젝트에서는 아무 문제도 없다고 느꼈다.
그리고 지금의 수준에서 다루기 위해서는 필요한 문서를 찾기가 어려운 일도 아니다.
약간 둘을 경험하게 된데 좋은 경험이 된다고 생각한다.
도커
이번 프로젝트에서는 Docker와 Jenkins를 활용하여 CI/CD 환경을 구축하기로 했지만, 이와는 별도로 얼마 전에 Docker의 개념을 다시 제대로 쌓기 위해서 책을 구입해 읽은 이야기를 해보고 싶다.
책을 읽은 이유는 다른 프로젝트에서 Testcontainers를 도입해 볼까 하는 의견도 있어, Github Actions를 사용해 CI/CD 환경을 구축하면서 Docker를 이용했지만, Docker를 사용하는 이유를 보다 명확하게 찾고 싶었기 때문이다.
책을 통해서도 그렇고, 다른 분들의 이야기를 들었을 때, 다음과 같은 이유로 선택하는 것 같다고 느꼈다.
애플리케이션 개발 환경이 Docker 기반 컨테이너 서비스 환경으로 마이그레이션된 이유는 무엇입니까?
대부분의 개발자는 개발, 테스트, 배포, 운영 컴퓨팅 환경(스토리지, 네트워크, 보안, 패치 등)의 차이로 인한 시행착오 및 다양한 오류 해결에 시간을 소비하는 일반적인 문제를 경험합니다.
합니다.
바로 가변적인 인프라 환경에 의한 일관성 없는 환경 제공에 의한 것이다.출처: 도커, 컨테이너 빌드 업!
chatGPT에게 Docker를 선택하는 이유에 대해 물었을 때도 거의 “왜 사용하지 않는다는 거야?”라는 느낌의 대답을 주었다.
요약하면 배포 및 자동화를 위해 AWS 및 Github 작업만 사용하는 것이 효과적인 옵션이지만 제한된 이식성, 복잡성, 제한된 유연성 및 격리 부족과 같은 잠재적인 단점 있습니다.
Docker 컨테이너를 사용하면 이러한 문제를 해결하고 일관성, 이식성 및 확장성과 같은 추가적인 이점을 제공할 수 있습니다.(다른 질문으로부터의 답변)
반면에 Docker 컨테이너를 사용하는 경우 Dockerfile을 사용하여 애플리케이션에 필요한 종속성과 설정을 지정하고 Docker Compose 또는 다른 컨테이너 오케스트레이션 도구를 사용하여 배포 프로세스를 관리하여 배포 프로세스를 단순화할 수 있습니다.출처: chatGPT
그리고 YouTube에서 짧게 도커를 사용하는 이유를 다룬 영상도 보았지만, 결론적으로 개발 환경에 대한 세팅을 반복해야 하는 수고를 줄일 수 있어 서버를 확장할 때 이미 만들어진 이미지를 활용할 수 있어 사용하지 않는다.
때때로 걸리는 시간을 줄일 수 있다는 이점이 있다는 것을 알았다.
그래서 이런 장점이 전개될 때 많은 도움이 될 것이라고 느꼈습니다.
추가 Docker를 사용하지 마십시오. 대부분의 경우 유용하지만 이미지를 다운로드 할 때 변조되거나 하나의 컨테이너가 해킹되면 커널을 공유하고 쓸 수 있으므로 모든 컨테이너가 위험 할 수 있습니다.
구성이 복잡할 때 유지보수가 어려워질 수 있다는 단점이 있습니다.
한다.
실은 도커에 대해 찾아보면 별로 볼 수 있는 내용이 아니어서(책에서도 볼 수 없었다) 우선 참고로 해 두면 좋은 것 같다고 생각했다.
마무리
이번 프로젝트에서는 내가 한 고민에 대해 많은 기록으로 남기려고 한다.
그리고 개발하면서 경험한 어려움 같은 것도 어떻게 해결하고, 왜 이런 어려움을 경험했는지에 대해서도 남겨두고, 나중에 같은 실수를 반복하지 않도록 잘 대비해야 한다는 생각이 있다 . 이전 프로젝트에서 노션에 무지성으로 만든 문장을 보면서 한숨만 나왔다.
좀 더 잘 정리해 두는 것을 후회해 보면, 원래대로 되돌릴 수 있는 것이 없다고 하는 것이 정말로, 😭 이번에는 후회하지 않고 열심히 기록해 보자!