벌써 반년이 지났습니다. 시간이 빠르게 지나가는게 느껴질 때마다 유한한 우리의 인생이 아쉽게 느껴지곤 합니다. 그래서 더욱 더 열심히 사는 것에 인생의 가치를 두고 싶다고 느껴집니다.   다들 신년에 계획했던 일들은 잘 지켜지고 있나요? 저희 학교의 헬스장이 학기 초에는 정말 붐볐지만 이제는 조금 조용해졌다는게 느껴집니다. 계획한 것을 상기하고 지켜나간다는 것은 정말 위대한 일인 것 같습니다. 정말 간단한 계획부터 자신의 습관까지 의지로 바꾸는 사람들을 보면 경외심을 느끼고 귀감이 됩니다.   열심히 살았는지 반년을 돌아보면 "아쉽다. 그러나 더 열심을 쏟는 내가 되고 싶다."로 정리할 수 있을 것 같습니다. 저는 NBA 스타 커리가 최고의 선수를 물어보는 인터뷰에서 자주하는 답변을 좋아합니다. "Yes..

식견 서버 기준 8기가 메모리의 홈서버에서 실행까지 요구되는 시간이 8초정도 걸렸는데 생각보다 유실되는 요청이 많았다. 그래서 그 해결 방법을 찾아보다가 쿠버네티스를 사용하면 쉽게 해결할 수 있다는 것도 알았다. 사이드 프로젝트에 쿠버네티스를 도입할 이유가 있을까? 막연하게 쿠버네티스는 엄청 큰 서버만 관리해야한다고 생각해왔다. 그러나 쿠버네티스도 종류가 엄청 다양하고, 프로젝트 규모에 따라서 선택지가 정말 많다는 것을 알게됐다.  이번 글에서는 지금 운영하고 있는 식견이라는 서비스에서 왜 쿠버네티스를 도입했는지 이야기 해보고자 한다. 이 글은 정보 전달이 주 목적이 아니므로, 프로그램을 설치하는 등의 과정을 기술하지 않는다. 왜 무중단 배포를 도입하나요?   학교 내라서 고정된 유저와, 크기 않은 트래..

멀티모듈은 정말 자유자재로 필요에 의해 만들어지는 것을 볼 수 있다. 이번 글에서는 어떤 상황에서 module 분리를 고려해야하는지에 대해 고민한 것을 짧게 공유하고자 한다. 어떤 상황에서 module 분리를 고려해야 할까? 모듈은 패키지보다 더 큰 개념으로, 패키지에서 분리의 필요성을 느낄 경우에 module로의 분리가 필요하다. 그렇다면 패키지에서 분리, 구분의 필요성을 느끼는 경우가 무엇이 있을까? 1. 참조 불가 수준의 코드 분리 2. 실행의 분리 찾아보고 고민해봤을 때 이 두가지가 있다고 느껴졌다. 1의 경우에는 Layer 별로 모듈을 구분하며, 레이어의 룰들을 모듈에 잘 녹여서 참조의 흐름을 일관성있게 가져갈 수 있다. 그리고, dependency도 레이어에 맞는 것들만 가져갈 수 있다는 것이..

테스트 코드를 작성하다보면, Fixture를 어떻게 만들지 고민할 때가 많다고 느껴진다. 크게는 모듈을 분리하는 것부터, 작게는 메서드 안에서 직접 객체를 생성하는 거 까지 할 수 있는 방법이 너무 많다. 그리고 Fixture Monkey와 같은 랜덤 데이터로 객체를 생성해주는 라이브러리가 있다. 이번 글에서는 Fixtiure Monkey라는 네이버에서 지원하는 라이브러리를 쓸지 말지에 대해서 이야기 해보도록 하겠다. Fixture Monkey가 뭘까? Fixture Monkey를 한줄로 정리하면, 제어가능한 임의의 테스트 객체를 생성하는 가장 쉬운 방법이다. Fixture Monkey 기능 1. 간편하게 랜덤하고 복잡한 제약조건을 가지는 객체 생성 Jqwik기반으로 JSR-303, JSR-380 ann..

이번에 멀티 모듈을 설정하면서 gradle에 처음으로 bootJar와 Jar 설정을 건드려봤다. 깨달은 점은 의존 당할 모듈에서는 jar 설정만 true로 하여서, plain-jar가 생성되게 하고, 최상단에서 Application 파일을 가지고 있고. 실행될 모듈은 bootjar만 필요로 한다는 것이었다. 이번 블로그에서는 bootJar와 jar의 차이, jar 파일과 plain-jar 파일의 차이를 다룬다. bootJar와 Jar 설정에 대한 결과 설정에 대한 결과를 알아보기 전 설정 방법을 간단하게 알아보자면, 아래와 같은 설정을 적용하고 싶은 모듈의 gradle 파일에 넣으면 된다. bootJar { enabled = false // bootJar 설정을 false로 한 것입니다. } jar { ..

스프링 시큐리티는 쉬운 인증 인가 구현과 보안을 구현해주는 프레임워크라고 널리 알려져있다. 그러나 나는 항상 개발을 하면서 스프링 시큐리티에 대한 반감이 있었다. 그래서 이번엔 그 반감의 원인을 파악해보고, 과연 스프링 시큐리티를 사용하는 것이 올바른 생각인지 확인해보겠다. 나는 왜 반감이 있는가? 반감의 이유를 한줄로 정리하자면, 스프링 시큐리티가 해주는게 없다고 생각해서이다. 내가 스프링 시큐리티가 해주는게 없다고 느낀 이유는 JWT 인증 방식만 사용해왔기 때문이다. 스프링 시큐리티와 JWT를 사용해서 인증 인가를 구현하고자 한다면, 정말 스프링 시큐리티가 해주는게 없다고 느껴진다. 직접 JWT 필터를 구현해서, 약 12개나 되는 필터 사이에 끼워서 사용한다. 이 과정에서 스프링 시큐리티에 대한 팀원..

요즘 개발을 하면서, 코드 리뷰가 완벽하지 않다는 것을 항상 느끼고 있다. 간단한 코드 컨벤션부터, Security Hotstop까지 많은 부분을 놓치고, 그 코드가 프로덕션 환경으로 나가는 경우가 종종 발생한다. 그래서 기술로 그러한 문제들을 해결하고자 나온게 코드 정적 분석 도구들이다. 이번 시간에는 현재 내가 처한 상황에서, 대표적인 무료 도구인 SonarCloud와 Qodana를 비교한 후 어떤 도구를 사용할지, 혹은 그냥 사용하지 않을지, 혹은 다 사용할지 고민하는 글을 작성해보고자 한다. 현재 나는 어떤 상황인가? 1. 프로젝트를 2개 진행하고 있다. 하나는 2년동안 서비스 중이고, 다른 하나는 이제 막 시작에서, MVP를 거의 완성하고, 프론트엔드랑 빠르게 소통하며, 코드리뷰 없이 DTO를 ..

다들 Java로 개발하다보면, 가끔 int, long과 같은 기본 타입을 사용해야할지, Integer, Long과 같은 박싱된 기본 타입 사이에서 고민해본 적이 있을 것이다. 나는 NPE 예방과, 객체를 생성하지 않아 메모리의 효율성 때문에, 기본 타입을 쓰는 것을 선호했지만, 개발하다보니 모두가 박싱된 원시타입을 사용하길래 나도 그렇게 살아왔다. 그랬던 전 날들을 반성하고있다. 이 글은 기본 타입과 박싱된 기본 타입 중 선택하는 가이드 라인을 제시하는 것을 목표로 한다. 두 타입의 차이는 무엇일까? 이펙티브 자바에서 말하는 차이는 3가지가 있다. 1. 기본 타입은 값만 가지고 있으나, 박싱된 기본 타입은 값에 더해 식별성(identify)이란 속성을 갖는다. 박싱된 기본 타입은 값이 같아도, 서로 다르..