https://gukin.dev/tags/java/ Recent content in Java on Gukin Han Hugo ko-kr Thu, 19 Mar 2026 00:00:00 +0000 https://gukin.dev/posts/virtual-thread-hikaricp-pool-exhaustion/ Thu, 19 Mar 2026 00:00:00 +0000 https://gukin.dev/posts/virtual-thread-hikaricp-pool-exhaustion/ <h2 id="virtual-thread-적용-이후-대량-이벤트-발생시-db-저장-로직-실패">Virtual Thread 적용 이후 대량 이벤트 발생시 DB 저장 로직 실패</h2> <p>진행중인 개인 프로젝트에서는 <a href="https://dart.fss.or.kr/">DART</a> 전자공시를 이용한다. 매일 수백 개의 전자공시가 DART 전자공시를 통해 게시되며 이를 수집해서 필터링하고 <strong>시장의 반응과 LLM의 감성분석을 집계하는 목표</strong>를 갖고 있다.</p> <p>공시 자료 폴링(Polling)이 중단되었다가 재시작 하는 경우 다량의 공시자료를 조회하고 이벤트를 발행하게 된다. 이때 <strong>분석된 결과를 DB에 저장하는 과정에서 이슈가 발생</strong>했다. 이 과정의 비즈니스 로직은 아래와 같이 정리할 수 있다.</p> <ol> <li>Polling으로 새 공시를 수집한다.</li> <li>수집된 공시의 제목으로 후속 처리가 필요한지 필터링한다.</li> <li>후속 처리가 필요하면 NewDisclosureEvent를 발행한다.</li> <li>이벤트 메시지에 담긴 공시 번호로 공시 문서를 조회한다.</li> <li>조회된 공시 문서를 LLM에게 넘겨서 감성 분석(Sentiment Analysis)을 실시한다.</li> <li>분석 결과를 DB에 저장한다.</li> </ol> <p>문제가 발생한 코드는 다음과 같다.</p> https://gukin.dev/posts/spring-boot-logging-tps-bottleneck/ Sun, 01 Mar 2026 00:00:00 +0000 https://gukin.dev/posts/spring-boot-logging-tps-bottleneck/ <h2 id="시간당-34gb의-로그-발생">시간당 34GB의 로그 발생</h2> <p>사내 인프라 담당자가 우리가 담당하고 있는 <strong>서버의 로깅 설정</strong> 관련된 내용을 공유해주었다. 간단하게 정리하면 다음과 같다:</p> <ul> <li><a href="https://aws.amazon.com/ko/cloudwatch/pricing/">Cloudwatch는 로그 GB마다 과금</a>되는 형태</li> <li>불필요한 로그로 인해 비용이 발생하는것으로 확인됨</li> <li>현재 서비스에서 발생하는 로그(특히 info)를 점검할 필요가 있음</li> </ul> <p>도메인 개발자라서 인프라 업무를 직접 수행할 기회와 권한이 없었다. 이번에 인프라팀이 공유해준 걸 계기로 <strong>개인적으로 살펴보았다</strong>. 먼저 Cloudwatch에 들어가 직접 눈으로 로그 발생량을 확인했다.</p> <p><img alt="Cloudwatch 로그 발생량" loading="lazy" src="https://gukin.dev/posts/spring-boot-logging-tps-bottleneck/img.png"></p> <p>우리 서비스는 HR 서비스이기 때문에 대부분의 트래픽은 9시부터 18시 사이에 발생한다. 시간당 대략 <strong>34GB(2.7억건)의 로그</strong>가 발생하며 그 중에 <strong>44% 정도가 jdbc.resultset=INFO</strong> 에서 발생함을 확인했다. 여기서 몇 가지 의문이 들었다.</p> https://gukin.dev/posts/java-enum-strategy-pattern/ Fri, 25 Apr 2025 00:00:00 +0000 https://gukin.dev/posts/java-enum-strategy-pattern/ <p>B2B 서비스에서 새로운 고객사가 들어오거나 기존 기능을 수정 및 이슈 픽스 해야하는 상황일 때 복잡한 if-else 레거시가 유지보수 효율성 문제를 자주 발생시켰다. enum 방식의 전략 패턴을 도입했고, 각 로직에는 단위테스트를 쉽게 도입할 수 있었다. 결과적으로 회귀테스트 비용이 제로로 떨어졌고, 나중에 팀원이 동일한 작업을 진행하면서 추가 작업이 쉬워졌음을 느꼈다고 공유해주었다.</p> <blockquote> <p>이 글에 사용된 코드는 실제 프로덕션 코드가 아닌, <strong>핵심 구조만 재구성한 예시</strong>입니다.</p> </blockquote> <h2 id="유지보수-관점에서-if-else의-문제점">유지보수 관점에서 if-else의 문제점</h2> <p>모든 if-else 구조가 나쁜 것은 아니다. 때론 간결하고 단순한 코드 방식이 더욱 유지보수에 유리한 경우가 있다.</p>