처음에 Java Spring 프로젝트를 다룰 때 모듈화에 대해 어렴풋이 알고는 있었다. 다만, 당시에는 생소한 개념이었고 이해하기 어려웠었다. 프로젝트를 만들 때 멀티모듈을 어떻게 만들어야 하는지부터 Github나 블로그 등을 엄청 찾아다녔다. 우아한형제들의 블로그에서도 멀티모듈에 대한 설계 게시글이 있어서 어떻게 의존성의 범위를 설정하고 프로젝트 설계를 했는지 구체적으로 설명이 되어 있는 게시글도 찾아보고 그랬지만, 처음부터 잘 모르는 상태에서 이를 실천하다간 나중에 어려워 질것 같아서 단일 모듈로 시작했었다. 프로젝트를 만들어서 실제 서비스에 적용하고 팀원들이 Java Spring 프로젝트들을 하나씩 만들다 보니 저장소도 늘어나기 시작했는데 설정이나 Entity, 클라이언트 등 중복되는 클래스들이 계..

이번 년도는 개인적으로 회사 프로젝트는 약간 아쉬움이 있었지만 나쁘지 않은 경험이었고, 취미 생활로 하는 악기 연주에서는 많은 사람들 앞에서 연주회를 2번이나 하였는데 주목도 받고 인기(?)도 많아져서 보람은 있는 해였던 것 같다. 회사에서는 2023년 처음부터 다른 팀으로 가서 내가 해보지 않은 경험도 해보고 싶다고 이사님에게 요청했었다. 팀 이동을 요청했고 결국 기다리라고 답변을 받았으나 1년이 지나도록, 2024년 현재 지금까지 아무 이야기도, 면담도 없었다. 연봉 협상도 원래부터 통보식이었으나 나 뿐만이 아닌 다른 사람들도 윗 사람과 같이 대면하는 자리조차도 없었다. 이번에 담당 임원이라는 제도가 생기면서 따로 개발 이사님에게 전달할 기회가 생겼었고, 이 기회를 통해 합리적인 이유를 들어 2024..

사내에 로그가 남겨지고 있는 서비스들이 대부분 파일로 관리되고 있는 것이 많았는데 그 중에서 많은 트래픽이 오는 두 개의 서비스 로그 지표를 확인해보고 싶었다. 기존에는 정작 애플리케이션 단위에서 얼마나 요청이 들어오고 나가는지, 어떤 데이터가 얼마나 들어오는지를 개발팀에서 알 수 있는 방법이 없어 실제로 장애 상황이 일어났을 때도 연관 데이터를 쉽게 분석하기 어려웠다. 또한, 로그가 파일로 남겨지고 있어서 SE 분들이 로그를 삭제해도 되는지에 대한 문의가 우리팀에게 간헐적으로 전달되었고, 우리가 직접 서버로 들어가서 삭제하거나 SE 분들이 삭제하곤 했다. 이런 이슈를 이번에 따로 개선해보고 싶었다. 팀에서 해당 서비스의 로그는 오랫동안 보관하기에는 중요하지 않은 로그라고 판단했고, 주기는 1~3개월 정..

이번 년도는 작년에 들어온 팀원과 함께 특히 리팩토링 작업을 많이 진행했다. 기존에 작성된 Spring Boot 프로젝트를 좀 더 객체지향적이고 유지보수하기 편한 코드로 개선해보자는 것에 초점을 맞추고 진행했는데, 이 과정에서 책도 찾아보고 코드리뷰에서도 깨닫고 이전보다 많이 배운 것 같은 느낌이 들어 보람을 많이 느낀 해였다. 기존 프로젝트에 헥사고날 아키텍쳐를 도입했는데 외부, 내부 요소를 구분하기 쉬웠고 인터페이스 분리나 테스트 코드 작성 면에서 이용하기가 좋아보여서 장기적으로 헥사고날 아키텍처 설계로 개발하기로 정했다. 그리고 객관적으로 보았을 때 기존에 오래 계신 팀원분들은 아무래도 PHP에 익숙한 분들이라 Spring Boot 와 관련한 코드리뷰를 함께 진행하면 아무래도 한계가 있었다. 올해에..

Spring Boot 어플리케이션을 처음으로 실무에 적용하고, 직접 장애를 겪어보고, 동시에 보람있는 경험도 같이 겪은 해였다. 작년에 Graylog 로 Gateway 같은 역할을 하는 서버에 요청 지표를 알 수 있도록 하는 모니터링 작업을 진행했었는데 그 지표를 잘 확인해보라는 듯이 무섭게도 작년 말, Meta 키워드 때문에 엄청난 트래픽이 몰리면서 Oracle 로 인한 사내 전체 장애가 일어났었다(기사). 이런 경우 어느 정도의 요청이 들어오는지 지표를 확인할 수 있는 경험을 겪었고, 다른 서비스들이 장애가 일어나서 작동이 안될 때 처음으로 실무에 적용한 Java Spring Boot 애플리케이션만이 유일하게 멀쩡하게 작동되는 경험까지 함께 겪게 되었다. 휴면 계정 회사에서 예전에 인수한 회사가 있었..

회사에서 입사하고 난 후 1년도 안되어 2019년도에 SVN 저장소에서 벗어나기 위해 GIT 저장소로 이동하는 작업을 진행했었는데 그 이유는 아래와 같았다. 회사 내 개발 직무 협의체에서 장기 목표로 GIT 으로 이전하는 공통 목표가 있었다. 반영하기 전 코드를 미리 확인할 수 있는 방법이 없었다. 커밋한 후에야 변경사항만을 다른 사람에게 보여줄 수 있는 정도였다. 브랜치를 원격에서 관리하는 것이 아니라 로컬에서 먼저 관리하고 싶었다. 원격에서 항상 관리되다보니 데이터를 가져올 때나 커밋할 때 항상 시간이 걸렸다. 저장소 커밋의 이력 관리를 쉽게 보고 싶었고, GIT 을 이용한 다양한 기능들을 사용해보고 싶었다. ... GIT 으로 이전하기 전에는 팀 내부적으로 코드 리뷰 문화나 정해진 컨벤션이 전혀 없..