노트/F-lab

개발 스펙 정하기

soro.k 2023. 3. 20. 23:46

 

 

들어가기 전에

이번 프로젝트에서 초기 개발 스펙을 다음과 같이 정했다.

  • Java 17
  • Spring boot 3.0.4
  • Gradle 
  • MySQL, MyBatis
  • JUnit5, Mockito
  • Jenkins
  • docker

매번 정보는 많이 찾아보면서 정하는데도 글로 고민했던 흔적을 남길 수 있는 시간이 없었다 보니까 이번에는 제대로 정리를 해야겠다는 생각이 들었다.

 

 

Java 17

우선 내가 Java 17을 눈여겨보기 시작했던 때는 주니어 스터디에서 제일 심혈을 기울였던 자바 면접 대비 스터디를 할 때였다. 그때 자바 버전 별로 차이점을 찾아보다가 발견한 글이 있는데 바로 여기 어때 기술 블로그에 올라온 우리팀이 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까지 업데이트 된 기능 중에 활용할 수 있을 것들이 없을 것 같다는 판단 하에 익숙했던 버전을 골랐었었다. 그런데 유튜브 강의를 볼 때 Record 이야기도 듣고, Sealed 클래스 같이 새로 도입된 기능을 알게 되다 보니 예제 코드보다는 직접 프로젝트에 사용해 보고 싶다는 생각이 들어서 이번 프로젝트에서는 무조건 Java 17을 사용해야겠다는 생각이 들었다. 무엇보다 Spring boot 버전도 가장 최신 버전으로 사용하기 때문에 호환성의 문제도 없었다.

 

사실 상용화를 염두해두고 하는 프로젝트가 아니다 보니 회사에서 선정하는 기준과는 조금 차이점이 있을 수 있지만 이렇게 버전에 대해 고민해 보면서 회사에서는 어떻게 기준을 삼을까에 대해서도 생각하게 됐다.

 

 

Gradle

 

출처 : https://gradle.org/maven-vs-gradle/

이 도표를 작년 회사 미팅 시간에 처음 봤었는데 그때 사수님께서 Gradle이 Maven과 어떤 차이점이 있는지 Gradle 홈페이지에 나와있는 문서를 번역해서 설명을 해주셨었다. 홈페이지에 나온 차이점을 간단하게 정리해 보자면 다음과 같다.

  • 빌드 시간이 더 빠르다.
    • 빌드 캐시 이용 / 변경된 파일만 빌드 / 데몬 프로세스 지원
  • Maven은 지정된 저장소만 사용할 수 있지만 Gradle은 여러 저장소를 사용할 수 있다.
  • Maven에 비해 의존성 버전 관리가 유연하다.

 

그리고 내가 가장 크게 느끼는 건 XML파일로 관리할 때보다 훨씬 가독성이 좋고 편하다는 것이다. 그래서 이번 프로젝트에서도 Gradle로 선택하고 싶었다.

 

 

MySQL

출처 : https://db-engines.com/en/ranking

MySQL만의 어떤 특별한 점을 고려했다기 보다는 가장 서로에게 익숙하고 낯설지 않은 DBMS를 선택했다. 그래도 이번에는 협업하시는 개발자 분이 어떤 DBMS가 익숙한지 몰랐기 때문에 왜 써야 하는지에 대해 스스로 찾아봤었다. 

  • 오픈 소스 및 호환성 - 호환성이 좋고 누구나 설치하고 사용할 수 있다.
  • 빠르고 안정적이다 - 속도를 중점적으로 개발되었고 안정성이 인정되어왔다. 그리고 배우고 사용하기가 상대적으로 쉽다.
  • 가용성 - 다양한 백업 및 복구 전략 사용

사실 다른 DBMS와 비교해 본 경험이 없어서 2, 3번은 잘 모르겠지만 1번은 확실히 내가 편하게 사용하고 있기 때문에 고개를 끄덕이게 됐다. 이번에 SQL 레벨업을 공부하면서 JOIN에 사용되는 알고리즘을 공부하다가 MySQL에서는 NL과 NL의 파생 버전만 사용하고 있다는 걸 알게 됐었다. 그러다가 이번에 블로그에 내용을 정리하면서 다시 한번 공식 문서를 봤었는데 그때는 발견하지 못했던 Hash Join이 8.0 이상에서는 도입된 걸 알게 됐다. 물론 다른 DBMS도 계속해서 업데이트가 되긴 하겠지만 사용하고 있는 제품에서 계속해서 성능을 위해서 개선하고 있구나를 알게 되니까 더 좋게 와닿았던 것 같다.

 

 

JUnit 5, Mockito

지난 프로젝트에서 테스트 코드에 대한 중요성을 많이 느끼기도 했고 너무 익숙하지 않은 바람에 애를 먹었어서 이번에는 프로젝트 시작 전에 미리 책을 사서 읽었다. 테스트 주도 개발 시작하기라는 책인데 그 동안 너무 기초없이 마냥 도입한 것 같은 느낌이 들어서 기초에 충실한 책을 추천 받아서 봤는데 개념 정리를 잘 할 수 있었다. 그리고 이 책을 통해서 테스트 코드가 항상 해답일 수는 없지만 제대로 짠 테스트 코드가 전제가 됐을 때는 어떤 이점을 얻을 수 있는지를 잘 알게 됐다. 그러면서 더 테스트 코드를 잘 짜고 싶다는 욕심이 들었다.

 

이전에 단위 테스트라는 책도 보면서 Mocking에 대해 안 좋은 의견이 있다는 사실도 알게 됐고, 이에 관련해서 멘토님께 질문도 했었지만 결국에는 내가 직접 경험해봐야 어떤 점이 안 좋고, 어떨 때는 정말 필요한 거구나를 느낄 수 있을 것 같다. 이번 프로젝트에서는 테스트 코드도 많이 짜보면서 습관을 제대로 들이고 싶다. 

 

 

Jenkins

선택 사항을 Github Actions랑 Jenkins로 줄였었는데 어떤 점이 다른지 찾아봤다.

Github Actions Jenkins
- 기능이 다른 툴에 비해 적지만 개인 프로젝트와 같이 규모가 작은 프로젝트에서 사용하기에 무리가 없다.
- 추가적인 설치 없이 Github에서 사용이 가능하다.
- 가장 오래된 툴이라서 관련 문서가 많고 사용자가 많다.
- 다양한 플러그인들이 있다. 
- 규모가 작은 프로젝트의 경우 리소스 낭비가 발생할 수 있다.

더 자세한 차이점은 이 블로그 글에서 볼 수 있다. 정말 꼼꼼하게 잘 정리해 두셨다. 결론적으로 Github Actions는 지금 우리처럼 소규모 프로젝트에서는 괜찮지만 나도 그랬었고 같이 하시는 분 회사에서도 모두 Jenkins를 쓰다 보니 Jenkins를 도입해서 경험을 쌓자는 결론이 났다. 사실 지금 병행하고 있는 다른 프로젝트에서는 Github Actions를 골랐는데 정말 소규모 프로젝트에서는 아무 문제가 없다는 걸 느꼈다. 그리고 지금 수준에서 다루기에는 필요한 문서를 찾기가 어려운 것도 아니다. 얼떨결에 두 가지를 경험하게 됐는데 좋은 경험이 될 거라고 생각한다. 

 

 

Docker

이번 프로젝트에서는 Docker와 Jenkins를 활용해서 CI/CD 환경을 구축하기로 했는데 이와 별개로 얼마 전에 Docker에 대한 개념을 다시 제대로 쌓기 위해 책을 구매해서 읽었던 이야기를 해보고자 한다. 책을 읽은 이유는 다른 프로젝트에서 Testcontainers를 도입해 볼까하는 의견도 있었고 Github Actions를 사용해서 CI/CD 환경을 구축하면서 Docker를 이용했는데 Docker를 사용 하는 이유를 더 명확하게 찾고 싶었기 때문이다.

 

책을 통해서도 그렇고 다른 분들의 이야기를 들었을 때 다음과 같은 이유로 선택하는 것 같다고 느꼈다.

애플리케이션 개발환경이 도커 기반의 컨테이너 서비스 환경으로 전환된 이유는 무엇일까?
대부분의 개발자가 개발, 테스트, 배포, 운영의 컴퓨팅 환경(스토리지, 네트워크, 보안, 패치 등) 차이로 인한 시행착오 및 다양한 오류 해결에 너무 많은 시간을 쏟는 공통적인 문제를 겪고 있다. 바로 가변적 인프라 환경으로 인한 일관성 없는 환경 제공 때문이다.

출처 : 도커, 컨테이너 빌드업!

 

chatGPT에게 Docker를 선택하는 이유에 대해 물어봤을 때도 거의 "왜 사용을 안 한다는 거야?"라는 느낌의 답변을 해줬다.

요약하면 배포 및 자동화를 위해 AWS 및 Github 작업만 사용하는 것은 유효한 옵션이지만 제한된 이식성, 복잡성, 제한된 유연성 및 격리 부족과 같은 잠재적인 단점이 있습니다. Docker 컨테이너를 사용하면 이러한 문제를 해결하고 일관성, 이식성 및 확장성과 같은 추가 이점을 제공할 수 있습니다.

(다른 질문에서의 답변)
반면 Docker 컨테이너를 사용하는 경우 Dockerfile을 사용하여 애플리케이션에 필요한 종속성 및 구성을 지정한 다음 Docker Compose 또는 기타 컨테이너 오케스트레이션 도구를 사용하여 배포 프로세스를 관리함으로써 배포 프로세스를 간소화할 수 있습니다.

출처 : chatGPT

그리고 유튜브에서 짧게 도커를 사용해야 하는 이유를 다룬 영상도 봤는데 결론적으로 개발 환경에 대한 세팅을 반복적으로 해야 하는 수고로움을 덜 수 있고, 서버를 확장할 때 이미 만들어진 이미지를 활용할 수 있어서 사용하지 않았을 때 소요되는 시간을 줄일 수 있다는 장점이 있다고 알게 됐다. 그래서 이러한 장점들이 배포를 할 때 많은 도움이 된다고 느꼈다.

 

 

 

마무리

이번 프로젝트에서는 내가 한 고민에 대해서 많이 기록으로 남겨두려고 한다. 그리고 개발하면서 겪었던 어려움 같은 것들도 어떻게 해결했고 왜 이런 어려움을 겪었는지에 대해서도 남겨서 나중에 같은 실수를 반복하지 않도록 잘 대비해야겠다는 생각이 든다. 이전 프로젝트에서 노션에 무지성으로 작성한 글들을 보면서 한숨만 나왔다. 더 잘 정리해놓을걸 후회해봤자 돌이킬 수 있는 게 없다는 게 참,, 😭 이번에는 후회하지 말고 열심히 기록해보자!