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

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

어느 순간부터 GIT 브랜치를 생성하면서 문득 생각이 들었다.feature/~~~~ 이런식으로 브랜치 이름을 지을 때 우리가 그냥 생각하는 이름을 적지 않고 아예 이슈 번호를 넣으면 어떨까 말이다. 회사에서 우리 사업팀은 Redmine 을 사용하고 있었다. 입사를 했을 때부터 이미 SVN 을 사용하고 있었고 Redmine 에서도 저장소를 같이 사용할 수 있었으며 추가적으로 사내에서 개발한 몇 가지 도구가 지원되고 있었다. 그러나 시간이 계속 흐르면서 유지보수를 하는 관리 인력이 없어지고 SVN 에서 GIT 으로 옮겨가면서 Redmine 내에서 GIT 저장소를 사용하기가 힘들어졌다. 특히, 개발 작업 커밋할 때 메세지에 Redmine 일감 번호를 써서 어떤 일감과 연관된 작업인지 쉽게 파악하기가 힘들어졌고..

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