2022년 9월에 회사에 입사해서 처음에는 회사 분위기에 적응하고 새로운 것들을 배우는 시간을 가졌다. 그리고 2023년에는 계속해서 프로젝트에 참여하며 성장하는 기간이었다. 특히 1월에는 카카오톡 선물하기 검수 처리가 초기에는 DB로만 관리되었는데, 나중에는 API를 도입하여 검수자들이 상품을 직접 핸들링하게끔 작업했다. 이때 서비스 영역이 왜 이렇게 복잡하게 구성되어야 하는지에 대한 의문이 들기 시작했다.
이 의문은 나만의 생각이 아니라 팀 전체에서도 공감되었고, 내부 소스가 지나치게 복잡하다는 의견이 팀 내에서 일치했다. 톡스토어는 이미 기존에 작업되어 있던 환경이긴 했지만, 그럼에도 불구하고 선물하기가 처음 시작되었는데도 똑같이 복잡성이 높아진 것에 대한 의아함이 컸다. 이러한 경험을 통해 앞으로의 프로젝트에서는 어떻게 하면 불필요한 복잡성을 최소화하면서도 효율적으로 기능을 구현할 수 있을지에 대한 방향성을 모색하기 시작했다.
문제점 나열
1.
20명이 사용하는 프로젝트에 대해 너무 많은 추상화를 사용하였다.
a.
ES, MySQL, 그리고 API 조회를 세 가지로 분리해서 사용하는 것이 좋을 것이라고 생각했었는데, 모든 조회를 하나의 인터페이스로 통합하려 했던 것 같다. 그로 인해 소스 코드를 수정할 때는 Elasticsearch를 잘 모르면 어려움을 겪게 되었고, 더불어 변수명도 a, b, c와 같이 모호한 단어를 많이 사용했다.
2.
비즈니스 로직이 Service 영역에 너무 밀집되어 있었다.
a.
웹에서 전달받은 데이터를 매퍼 클래스로 변경하고 나서 Repository를 호출한 다음, 객체를 활용하지 않고 전부 서비스 영역에서 데이터를 가공하고 노출하고 있었다. 하나의 서비스도 복잡한데, Service에서 Service를 호출하고 있고, 함수와 분기 처리로 내부로 들어가는 로직들이 너무 많았다.
3.
잘못된 Transaction이 너무 즐비하게 사용되고 있었다.
a.
이 부분은 찾기도 힘들었다. 나의 생각으로는 트랜잭션 안에서 Exception를 발생시키면 롤백이 돼야 된다고 생각하였는데, 발생되지 않았다. 사이버 네이트를 신뢰하면 안 된다고, 안 되는 것도 많다고 이야기하였지만, 나는 이 부분에서 원인을 모르고 그냥 사용하게 된다면 프로젝트를 신뢰할 수 없을 것 같았다.
b.
내부 서비스에서 트랜잭션 함수에서 → 트랜잭션 함수를 호출하고 있는 동작들도 많았다.
c.
트랜잭션 내부에서 Try - Catch로 잡고 Exception을 안 던져주는 경우도 많았다.
4.
JPA 조회 쿼리
a.
Jpa에서 복잡하게 조회되는 부분은 Prdicate를 사용해서 조인하여 조회하고 있었는데, 이 부분을 서비스 영역에서도 진행하고 있어서, 로직과 쿼리 조회하는 부분과 혼용되게 사용하고 있었다.
b.
Prdicate를 사용하면서 연관관계를 맺어도, 조인 관계는 직접 작성해 줘야 되는데, 작성하지 않아서 Cross Join이 발생하였다.
5.
파라미터 전달 코드 수정
a.
웹에서 전달받은 데이터를 서비스에서 필요한 데이터로 가공해서 다시 매퍼 데이터로 넣고 있었다.
6.
애그리거트의 분리
a.
검수 처리, 히스토리, 긴급 알림 메시지 전송에 관한 서비스 로직이 한 곳에서 작성되어 있어서 3개의 서비스 중 한 개만 잘못되더라도 서비스가 롤백이 되는 현상이 발생하였다.
이를 해결하기 위해서 어떻게 하면 유지 보수하기 쉽고 좋은 코드를 구현할 수 있을지 모색하게 되었다.
1. 밀집되어 있는 Service영역 분리하기
첫 번째
TDD, 클린 코드 with Java 16기 완강이었다. 자바 코드를 어떻게 하면 좀 더 객체지향스럽게 작성할 수 있는지 배울 수 있는 좋은 계기가 되었다. 물론 가격대는 750,000으로 싼 가격은 아니었지만, 그래도 나에게 전환점이 되는 강의였다.두 번째
도메인 주도 개발 시작하기[클릭] 였다. 무거운 서비스 영역을 애그리 거 트 별로 나누는 방법과 이벤트 방식을 통한 서비스로 직 분리 그리고 CUD와 R을 나누는 방법 등 많은 부분에서 큰 도움이 되었던 책이다.세 번째
이를 통해서 새로 도입한 것이 일급 컬렉션과 원시 값 포장 그리고 이벤트 방식이었다. 또한 R과 CUD를 분리하여 처리할 수 있게 하였고, 라이브 검수 처리는 좀 더 원활하게 개발할 수 있었다.
2. 트랜잭션 명확하게 이해하기
잘못된 트랜잭션을 명확하게 알기 위해서 직접 함수가 어떻게 처리되고 있고, 어떤 상황에서 롤백이 안되는지 알아야 될 필요가 있었다. 이를 하기 위해 @Transaction에 대해 공부하고 조사하게 되었다.
문제점은
1.
프록시 패턴으로 작성되어 있는 트랜잭션을 내부의 함수로 호출하는 문제
2.
try-catch로 익셉션을 잡는 문제
3.
AOP로 트랜잭션이 컨트롤러에 걸려있는 문제 크게 3가지가 있었다.
나중에 알게 되었지만 1, 2번은 그래도 나름 쉽게 찾을 수 있었지만 프로젝트의 Controller의 전체적으로 걸려있는 트랜잭션은 정말 찾기 어려웠었다.
애그리거트 분리
1.
서비스 영역에서 같이 묶여있는 검수 처리 → 히스토리 저장 → 메시지 전송 로직을 분리하였다.
방법으로는
를 적극적으로 활용하였다.
2023년은 이제 며칠 안 남았지만, 돌이켜보면 작년 보다 더 발전된 나를 볼 수 있어서 뿌듯한 한 해였고, 내년에도 올해보다 더 좋은 방향으로 발전된 나를 보고 싶다!!
2024년 목표
내가 만들고 싶은 웹사이트를 직접 운영해보고 유지보수하는 프로젝트를 진행
