<feed xmlns="http://www.w3.org/2005/Atom"> <id>/</id><title>엄범</title><subtitle>엄범 개발 블로그</subtitle> <updated>2026-08-31T15:15:50+09:00</updated> <author> <name>umbum</name> <uri>/</uri> </author><link rel="self" type="application/atom+xml" href="/feed.xml"/><link rel="alternate" type="text/html" hreflang="ko" href="/"/> <generator uri="https://jekyllrb.com/" version="4.3.2">Jekyll</generator> <rights> © 2026 umbum </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>멀티 모듈 프로젝트에서 모듈 구성 사례</title><link href="/2072/" rel="alternate" type="text/html" title="멀티 모듈 프로젝트에서 모듈 구성 사례" /><published>2025-05-16T21:22:00+09:00</published> <updated>2026-08-05T14:04:45+09:00</updated> <id>/2072/</id> <content type="text/html" src="/2072/" /> <author> <name>umbum</name> </author> <category term="0System Design" /> <category term="Package&amp;Module&amp;Server design" /> <summary>module layering 가장 일반적이고 보편적인 모듈 구성을 그림으로 나타냈다. 각각의 네모 박스는 모듈을 의미한다. 멀티 모듈 프로젝트 내에서 모듈을 grouping 할 기준이 필요한데, layered architecture에 기반하여 grouping 하고 의존 방향성을 한 방향으로 관리하는 것이 가장 깔끔했다. 모듈 의존 방향은 Application -&amp;gt; Domain -&amp;gt; Support Support layer : persistence IO, external IO, 기타 util Domain layer : 각 기능 집합 단위로 business module을 구성 Application layer : 외부에서 요구하는...</summary> </entry> <entry><title>HikariCP에서 Oracle PreparedStatement cache 활성화하기</title><link href="/2049/" rel="alternate" type="text/html" title="HikariCP에서 Oracle PreparedStatement cache 활성화하기" /><published>2025-01-12T10:52:00+09:00</published> <updated>2025-01-03T23:14:03+09:00</updated> <id>/2049/</id> <content type="text/html" src="/2049/" /> <author> <name>umbum</name> </author> <category term="Java Stack" /> <category term="Persistence" /> <summary>문제 인식     2번째 column이 execution 횟수, 3번째 column이 parse call 횟수 24/11/07 부터 갑자기 특정 쿼리의 parse call이 크게 늘어서 거의 execution 횟수와 동일해졌다. 이 쿼리만 그런 것은 아니고, 다른 쿼리들도 같은 문제가 있었다. 쿼리가 실행 될 때 마다 매번 parse call이 발생하고 있다는 것인데… 11/07에 CP를 DBCP → HikariCP로 변경한 이후로 preparedStatement 또는 cache가 제대로 적용되지 않고 있는 것이 원인으로 보였다. ...</summary> </entry> <entry><title>텍스트 검색 알고리즘 : TF-IDF와 BM25</title><link href="/2048/" rel="alternate" type="text/html" title="텍스트 검색 알고리즘 : TF-IDF와 BM25" /><published>2024-12-22T20:24:00+09:00</published> <updated>2025-04-29T23:35:41+09:00</updated> <id>/2048/</id> <content type="text/html" src="/2048/" /> <author> <name>umbum</name> </author> <category term="Machine Learning" /> <category term="ML-Theory" /> <summary>TF-IDF TF-IDF(Term Frequency-Inverse Document Frequency)는 텍스트 분석에서 널리 사용되는 통계적 가중치 척도 문서 내에서 특정 단어의 중요성을 평가하는 데 사용함. TF (Term Frequency) 특정 문서 내에서 단어의 출현 빈도를 측정 TF(w, d) = (문서 d 내에서 단어 w의 등장 횟수) / (문서 d의 총 단어 수) [!info] 다양한 TF 계산 방식 분모를 (문서 d에서 가장 많이 등장한 단어의 등장 횟수) 로 변경하여 normalize 하는 경우도 있다. (Normalized Frequency) 이 외에도 Boolean Frequency, Log-scale Frequency 등의 방법이 ...</summary> </entry> <entry><title>serialVersionUID와 InvalidClassException</title><link href="/2046/" rel="alternate" type="text/html" title="serialVersionUID와 InvalidClassException" /><published>2024-08-20T11:59:00+09:00</published> <updated>2025-10-16T20:14:05+09:00</updated> <id>/2046/</id> <content type="text/html" src="/2046/" /> <author> <name>umbum</name> </author> <category term="Java Stack" /> <category term="Java" /> <summary>[!info] 직렬화, 역직렬화는 보통 json을 이용해서 처리하게 되고, 그렇게 하는 것이 좋아보인다. json이라는 명확한 표준이 있어 이식성도 좋고, 변환 로직도 심플해서 아래와 같은 잠재적인 문제를 피할 수 있기 때문이다. Java Serialization의 단점 어떤 사정으로 인해 json serialization 하지 못하는 경우, java에서는 Serializable 구현하고 이를 이용해서 직렬화 하게 되는데… 직렬화/역직렬화 시, 클래스와 객체의 동일성 판단이 json에 비해 매우 민감하기 때문에 주의해야 한다. import dev.umbum.Address; // 변경 전 User public class User implements Serializable { pr...</summary> </entry> <entry><title>GraalVM으로 native image compile 하기 (with Spring Boot)</title><link href="/2033/" rel="alternate" type="text/html" title="GraalVM으로 native image compile 하기 (with Spring Boot)" /><published>2024-07-22T09:42:00+09:00</published> <updated>2025-10-14T20:14:05+09:00</updated> <id>/2033/</id> <content type="text/html" src="/2033/" /> <author> <name>umbum</name> </author> <category term="Java Stack" /> <category term="build" /> <summary>JVM + JIT compile / native image + AOT compile Spring 애플리케이션은 JVM 위에서 돌아가고, JVM은 그 동작 방식 때문에 초기 구동 속도가 느리다. JVM은 최초에는 interpreter로 동작하다가 자주 사용되는 메서드는 JIT compile하기 때문에, 초기에는 느릴 수 밖에 없다. 런타임에 Class Loading 하는 과정 때문에 느린 것도 한몫 한다. JVM 관련 참고 반면 빌드 시점에 미리 컴파일(AOT compile) 해서 native binary로 만드는 방식(go, C++ 등)은 초기 구동 속도 문제가 없다. SpringBoot 3 부터 GraalVM을 이용한 native ...</summary> </entry> </feed>
