어제의 최선

왜 maven을 두고 gradle을 배워야 할까? Gradle는 주로 Java 프로젝트에 사용되는 강력한 빌드 자동화 도구다. 소스 코드 컴파일, 테스트 실행, 애플리케이션 패키징 및 배포 과정을 자동화한다. 정의부터 살펴보면 어플리케이션을 배포하기 위해 개발자들이 했던 작업들을 자동화해 주는 툴이다. 이전에는 개발자들이 터미널에서 명령어로 한땀한땀했던 일련의 반복적인 작업들을 빌드 툴이 자동으로 컴파일해주고 테스트코드를 실행시켜 주고 참조하는 라이브러리 파일을 관리해주는 것이다. // 컴파일 후 테스트 // 빌드툴 X $ javac -d /absolute/path/for/compiled/classes -cp /absolute/path/to/junit-4.12.jar /absolute/path/to/Te..

웹기반 공통 Library 중복되는 설정들 혹은 공통으로 관리해야 할모듈을 한 곳에서 관리하는 것은 흔한 일이다. 현재 내가 진행하고 있는 프로젝트 또한 모든 프로젝트에서 참조하는 스프링 웹 기반의 라이브러리 프로젝트가 존재하고, 여기에는 많은 스프링 Bean이 존재하고 있다. 처음에는 문제를 느끼지 못했지만, 시간이 갈수록 웹 환경에 의존적인 많은 Bean들이 다른 클라이언트 프로젝트에 맞지 않는 경우가 생겨났고, 설계가 잘못됐다고 확실히 느낄 수 있었다. 어디서부터 잘못된 걸까? 외부 jar에 정의된 스프링 Bean은 읽지 않는 것이 기본 원칙이다. 제일 헷갈린 부분이다. 내가 현업에서 사용하는 프로젝트는 외부 jar에 정의된 Bean들이 클라이언트 프로젝트 Context에서 등록돼 잘 사용하고 있다..

만족스럽지 못한 하루를 보내면, 아쉬운 마음에 하루를 마무리하지 못하고 늦게 잠들게 된다고 한다. 미루고 미루다 2023년 1월이 다 가고 나서야 2022년을 마무리하는 것은 그런 이유일까. 돌이켜보면 아쉬움이 많은 한 해였다. 성장할 수 있을까? 계약 종료, 퇴사 등 여러 이유로 인원이 부족해지면서 팀 내에서 내가 담당해야 하는 일이 점차 많아졌다. 일이 많아져도 배움이 있고 성장이 있으면 된다는 주의라 크게 불만은 없었다. 하지만 문제는 거기에 있었다. 시간이 갈수록 내가 성장하고 있는 건지 모르겠다는 생각이 들었기 때문이다. 작년 여름쯤, 서비스기업 코딩테스트를 본 적이 있다. 알고리즘 문제 외에도 서술형 문제가 5개 정도 있었다. 문제상황을 주고 어떻게 해결할 건지 문제해결능력을 보는 것이었는데,..

서론 길었던 프로젝트 막바지로 달려가면서, 아쉬운 점이 눈에 계속 밟힌다. 아무것도 모르고 시키는 것만 하던 신입시절을 지나서, 이제 어느 정도 업무에 익숙해지니 "이렇게 하면 좀 더 좋지 않았을까?" 생각이 들거나 "이렇게 했었어야 했는데..."하고 아쉬움이 드는 몇 가지를 나누어 정리하려 한다. 물론 고작 주니어 개발자의 생각이기 때문에 이 글엔 틀린 점이 많을 수도 있다. 글 제목에서도 보이듯이, 이 글은 Session은 Controller에서만 사용하자는 것이다. 대부분의 기업에서는 아마 당연하게 하고있는 것들이겠지만, 아쉽게도 내가 참가한 프로젝트에서는 그러지 못했다. Service 영역에는 비즈니스로직과 관련된 것만 있어야 한다. 표현 계층에 의존해서는 안된다. 본론 Service 영역에서 S..

서론 이번에 진행하고 있는 프로젝트에서 전자정부 4.0과 버전을 맞추기 위해 SpringBoot 2.4.5 버전으로 업그레이드 했다. 프로퍼티 작성법이 변경되는 것말고는 크게 이슈가 없을 줄 알았는데, 몇가지 자잘한 문제들이 생겼다. 몰랐던 내용도 있고 해서 글로 정리해본다. 1. Default Servlet Registration Spring Boot 2.4 will no longer register the DefaultServlet provided by your servlet container. In most applications, it isn’t used since the Spring MVC’s DispatcherServlet is the only servlet that’s required. Yo..

부끄럽지만 새해를 시작하며 지난 한 해를 돌이켜본다. 내게 2021년 가장 큰 키워드는 아무래도 취업이 아닐까 싶다. 취업하면서 많은 것이 변했다. 부산에서 서울로 상경하면서 새로운 사람들, 새로운 자취방, 새로운 환경, 겪고 싶지 않은 출근길 지하철까지... SI로 취업 내가 원하는 방향은 아니었지만 SI로 취업에 성공했다. 인터넷에서 이미 안 좋은 소문은 들을 대로 듣고 가서 그런가, 생각보다 만족스러웠다. 물론 서비스 기업과 기술과 문화가 많이 다르지만, 배울 게 없는 건 아니라고 생각한다. 내가 모르는 게 많은 것도 있겠지만 시스템 공통 부문 신입으로 입사했는데, 주요 업무가 애플리케이션 개발 환경을 구성하고 개발자들을 지원하는 일이었다. 배울 수 있는 건 많지만, 아무래도 내 업무가 다른 개발자..

다른 깃 명령어들도 많지만, 기본적인 것을 제외한 내가 자주 쓰는 명령어 위주로 정리했다. stash git에 의해 추적되고 있는 파일들을 임시로 보관한다. 나같은 경우에는 작업 중에 우선순위가 높은 작업(오류)이 생겨서 급하게 처리해야할 때 자주 쓴다. $ git stash save 명시적인기록 $ git stash --keep-index $ git stash -u stash 스택 조회 $ git stash list stash 적용, 부분이 생략되면 스택 가장 윗부분이 적용됨 $ git stash apply stash 제거, 부분이 생략되면 스택 가장 윗부분이 제거됨 $ git stash drop stash 스택 적용 및 삭제, 부분이 생략되면 스택 가장 윗부분이 제거됨 $ git stash pop 브..

서론 파일을 서버에 보관할 때, 파일명 변환하는 걸 java UUID를 사용해서 변환했었다. 코드 리뷰를 받던 중에 선임분이 UUID에 대한 의심을 보이셨다. 하나의 OS에 여러 앱이 가동되는 환경, 그리고 멀티스레드에서도 충돌 가능성이 없나? 단순하게 그냥 유니크한 값이라고 믿고 사용해왔던 터라 대답하지 못했다. 이번 기회에 UUID가 어떻게 유니크한 값을 생성하는지 알아보고 정리해보려 한다. 본론 고유성을 완벽하게 보장하려면 중앙관리시스템이 있어서 일련번호를 부여해 주면 간단하지만 동시다발적이고 독립적으로 개발되고 있는 시스템들의 경우 중앙관리시스템은 불가능하다. 개발주체가 스스로 이름을 짓도록 하되 고유성을 충족할 수 있는 방법이 필요하다. 이를 위하여 탄생한 것이 범용고유식별자(UUID)이며 국제..

서론 최근에 코로나 밀접접촉자 판정을 받으면서 약 일주일 동안 재택근무했다. 좋긴 좋은데 집에서 하니 뭔가 집중도 안되고 카페를 못 가니 답답했다. 암튼, 소스코드 외부 반출이 안돼서 집에 있는 동안 확장자 체크 라이브러리 tika 좀 알아보라는 업무를 받았다. 업무를 하면서 알게된 내용을 정리해보려 한다. 본론 MIME(Multipurpose Internet Mail Extensions) tika는 MIME를 이용해서 파일 타입을 체크한다. MIME이 뭘까? MIME는 SMTP 프로토콜에서 이메일을 보낼때 파일을 확인하기 위해 생성된 표준인데, 이제는 많은 프로토콜에서 같은 목적으로 MIME를 사용하기 시작했다. 그래서 "Internet Media Type"이라고 부르기도 한다. 대부분의 프로토콜에서 ..

서론 application.yml은 yaml 사용하는데, 왜 @PropertySource는 properties를 사용하나요? 시작은 이렇다. 프로젝트 내에서 업무 외적인 환경변수는 application.yml에, 업무 내적인 환경변수는 별도의 @PropertySource로 biz.properties를 사용하는 구조였다. 그래서 아무래도 가독성이 좋은 yaml로 통일하는 게 좋은 것 같은데, property를 사용하는 특별한 이유가 있냐고 물어봤었다. 특별한 이유는 없었고 yaml을 쓰려면 추가적으로 설정해줘야 하는 게 있는데 그걸 한번 알아보라는 업무를 받았다.😂 property로 했던 기능들을 yaml로 별 이상 없이 쓸 수 있으면 yaml로 통일하자고 하셨다. 단순히 그냥 확장자만 바꾸면 될 줄 알았..