1. 여러 기능에 분산된 휴게시간 계산 로직 수백 명 규모의 새로운 고객사에서는 우리 서비스가 기존에 제공하는 휴게 옵션으로 운영이 어려웠다. 앞으로 존재할 수 있는 잠재적인 고객사의 커버리지까지 높이기 위해 코드 구조를 파악했다. 레거시 코드들은 법령을 그대로 하드코딩하여 유연하게 옵션을 제공하지 않는 형태였고 새로운 옵션이 추가되었을 때도 확장이 불가능한 구조였다. 또한, 기존 휴게 옵션은 유틸리티 클래스로 작성되어 약 35곳에서 직접 호출 중이었다. 문제는 유틸리티 클래스 밖에서 적어도 11개 운영 클래스가 휴게 규칙을 해석 및 계산하는 로직을 중복으로 갖고 있었다. ...
LLM 시대에도 실행계획을 직접 읽어야 하는 이유 슬로우 쿼리 분석도 자동화되는 시대 요즘은 LLM을 이용해 슬로우 쿼리 분석을 자동화하려는 시도들이 많아지고 있다. 실행 로그를 모으고, SQL을 추적하고, EXPLAIN 결과를 해석하고, 개선안을 제안하는 흐름 자체가 점점 자동화의 대상이 되고 있다.1 그렇다면 개발자가 직접 실행계획을 읽는 능력은 덜 중요해질까? 나는 오히려 반대라고 생각한다. 자동화된 분석 결과를 신뢰하려면, 결국 사람이 그 판단을 검증할 수 있어야 한다. LLM이 “이 인덱스를 추가하세요”라고 말했을 때, 그 제안이 왜 맞는지, 혹은 왜 위험한지 판단하려면 실행계획을 읽는 감각이 필요하다. ...
테스트 코드를 실무에 적용하면서 겪는 문제들 복잡했던 도메인 로직들이 리팩토링되고, 필요한 Fixture를 만들어두니 테스트 코드 작성 속도가 빨라지고 있다. 요즘은 매 스프린트마다 테스트 개수가 크게 증가하며, 하나 둘씩 관련 문제가 생기고 있다. 지난 포스트에서는 Application Context(이하 컨텍스트)의 증가1로 인해 MySQL로 연결되는 커넥션 수가 max_connections에 도달해서 발생하는 Too Many Connections을 다뤘다. 클래스마다 MockBean 조합이 다르면 Spring 컨텍스트의 캐시미스가 발생하여 Spring이 컨텍스트를 새로 만들기 때문에, MockBean을 통합하는 방식으로 해결할 수 있었다. 현재는 어드민 권한 테스트용 하나와 일반 유저 테스트용 하나의 컨텍스트로 총 2개만 유지되도록 매 스프린트마다 유지보수하는 중이다. ...
티스토리에서 새 글은 이곳에 쓰기로 결정했습니다. 점진적으로 이전할 예정이며, 기존 글은 티스토리에 그대로 있습니다.
개별 테스트는 통과, 전체 실행시 Too many connections 발생 여러 기능 브랜치가 개발 브랜치로 머지된 후, 그동안 기능 개발하면서 놓친 실패 테스트들을 점검하기 위해 전체 테스트를 실행했다. Too many connections 에러로그가 발생하면서 통합테스트들 일부가 실패하였다. 로그의 일부는 아래와 같다: Error creating bean with name 'liquibase': Too many connections → Error creating bean with name 'databaseCleanupUtil' → Failed to load ApplicationContext 하지만, 각각 테스트 클래스들을 개별로 실행했을때는 모두 통과했다. 도대체 왜 동일한 코드에서 실행 범위만 다를 뿐인데 결과가 다를까? ...
Virtual Thread 적용 이후 대량 이벤트 발생시 DB 저장 로직 실패 진행중인 개인 프로젝트에서는 DART 전자공시를 이용한다. 매일 수백 개의 전자공시가 DART 전자공시를 통해 게시되며 이를 수집해서 필터링하고 시장의 반응과 LLM의 감성분석을 집계하는 목표를 갖고 있다. 공시 자료 폴링(Polling)이 중단되었다가 재시작 하는 경우 다량의 공시자료를 조회하고 이벤트를 발행하게 된다. 이때 분석된 결과를 DB에 저장하는 과정에서 이슈가 발생했다. 이 과정의 비즈니스 로직은 아래와 같이 정리할 수 있다. Polling으로 새 공시를 수집한다. 수집된 공시의 제목으로 후속 처리가 필요한지 필터링한다. 후속 처리가 필요하면 NewDisclosureEvent를 발행한다. 이벤트 메시지에 담긴 공시 번호로 공시 문서를 조회한다. 조회된 공시 문서를 LLM에게 넘겨서 감성 분석(Sentiment Analysis)을 실시한다. 분석 결과를 DB에 저장한다. 문제가 발생한 코드는 다음과 같다. ...
시간당 34GB의 로그 발생 사내 인프라 담당자가 우리가 담당하고 있는 서버의 로깅 설정 관련된 내용을 공유해주었다. 간단하게 정리하면 다음과 같다: Cloudwatch는 로그 GB마다 과금되는 형태 불필요한 로그로 인해 비용이 발생하는것으로 확인됨 현재 서비스에서 발생하는 로그(특히 info)를 점검할 필요가 있음 도메인 개발자라서 인프라 업무를 직접 수행할 기회와 권한이 없었다. 이번에 인프라팀이 공유해준 걸 계기로 개인적으로 살펴보았다. 먼저 Cloudwatch에 들어가 직접 눈으로 로그 발생량을 확인했다. 우리 서비스는 HR 서비스이기 때문에 대부분의 트래픽은 9시부터 18시 사이에 발생한다. 시간당 대략 34GB(2.7억건)의 로그가 발생하며 그 중에 44% 정도가 jdbc.resultset=INFO 에서 발생함을 확인했다. 여기서 몇 가지 의문이 들었다. ...
들어가며 이전 포스팅들은 스택 영역에서의 바이트코드의 상호작용을 다뤘다. 런타임 데이터 영역에는 스택 영역 뿐만 아니라 힙 영역이 존재한다. JVM 스펙에 따르면 다음 내용을 확인할 수 있다: “자바 가상 머신은 모든 스레드가 공유하는 힙(Heap) 영역을 가지고 있습니다. 힙은 모든 클래스 인스턴스와 배열의 메모리가 할당되는 런타임 데이터 영역입니다.” 따라서, 이 글에서는 객체와 힙 영역에 관련된 여러 요소들을 탐험하고 실험하는데 목적이 있다. Object 클래스의 객체 생성 (new 키워드) 처음으로 시도해볼 실험은 가장 순수한 객체를 생성해보는 것이다. 아무런 필드도, 로직도 없는 가장 순수한 형태의 객체를 생성해 볼 수 있는 클래스는 java.lang.Object이다. Object 객체를 생성할때 과연 몇 번의 CPU 명령어를 소모할까? 어떤 과정을 거칠까? ...
들어가며 이전 포스팅에서는 컴파일된 증감연산자(i++, ++i)의 정적인 바이트코드를 분석했다. 해당 실험에서는 load, store 등의 명령어를 피연산자 스택을 통해 어떻게 연산이 이뤄지는지, iinc 명령어의 최적화 방식을 이해할 수 있었다. 이번에는 단순한 연산을 벗어나, 프로그램의 실행 순서를 바꾸고 제어하는 **제어 흐름(Control Flow)**을 다뤄보려고 한다. 코드의 흐름을 나누는 분기문(if-else), 특정 구간을 반복하는 반복문(for-loop, while), 조건에 따라 특정 점프하는 스위치문(switch)에 해당된다. 각각 바이트코드 레벨에서 어떻게 흐름을 제어하는지 실험을 통해 살펴본다. 실험 java 코드를 작성하고 javac ControlFlowTest.java 와 javap -c -p -v ControlFlowTest > result.txt 명령어를 이용해서 컴파일과 역어셈블을 하였다. 3개의 섹션을 나눠서 각각 분기문, 반복문, 스위치문을 실험 및 분석하였다. ...
들어가며 이 글은 거창하게 바이트코드를 분석하려는 의도로 시작하지 않았다. 단지 JVM을 학습하는 과정에서 제시된 간단한 실습 예제를 직접 실험해보고 있었다. 작성된 자바 파일을 javac와 javap 명령어로 컴파일하고 역어셈블(Disassemble)하는 과정은 생각보다 많은 질문을 던져주었다. “우리가 작성한 소스코드는 실제로 JVM 위에서 어떻게 돌아갈까?” “단순한 i++ 연산은 CPU와 메모리 관점에서 어떤 비용을 지불하는가?” 이러한 질문을 가지고 실험을 하면서, 컴파일러의 최적화와 JVM의 스택 머신 아키텍처 특징을 바이트코드와 그 연산 플로우에서 확인할 수 있었다. 이 글에서는 간단한 증감 연산자(i++) 실험을 통해 소스코드가 바이트코드로 변환될 때 발생하는 차이와 그 원리를 정리해본다. ...