1. 문제 상황 List에서 특정 기준으로 중복을 제거하는 유틸이 필요했다. 예를 들어, 상품 목록에서 다음과 같은 기준으로 중복을 제거한다고 하자.상품번호가 같으면 중복이다.상품번호가 달라도 상품명이 같으면 같은 상품으로 본다.기준은 나중에 늘어날 수도 있다. 기준 개수가 유동적이니 제네릭 가변인자로 받도록 구현했다.// 호출부List unique = DeduplicationUtils.deduplication( products, Product::getProductCode, Product::getProductName);public final class DeduplicationUtils { private DeduplicationUtils() { } public static Li..

업무 중 고객사 웹사이트에 주입되는 위젯을 구현해야 했다. 위젯 안에는 캔버스로 그린 여러 요소들이 있었고, 어떤 고객사의 페이지에 붙든 그 사이트의 CSS에 깨지지 않아야 했다. 그래서 Shadow DOM으로 위젯을 감쌌다. 작업을 끝내고 정리해 보니, 알게 된 게 하나가 아니었다. 왜 이 기술이 필요했는지, 그게 실은 기술 문제가 아니라 비즈니스 문제이기도 했다는 것. 격리의 경계가 정확히 어디까지인지, closed 모드 하나를 고른 게 코드 구조를 어떻게 강제했는지. 그리고 정작 가장 많은 시간을 잡아먹은 건 따로 있었다는 것. 이 글은 그 순서 그대로 정리한 기록이다. 1. 왜 Shadow DOM이 필요했는가? Shadow DOM을 처음 접하면 '컴포넌트 스타일을 캡슐화해주는 것' 정도로 이..

내 블로그 조회수 상위권을 달리는 22년도에 딴 '정보처리기사 실기 합격 후기'에 이어서, 24년도에 딴 SQLD 공부 과정 및 합격 후기 글을 쓰고자 한다. 블로그 유입 늘릴려고... 그리고 공부 과정뿐 아니라 이 자격증이 개발자 입장에서 실제로 취업과 실무에 얼마나 도움이 되었는지도 덧붙이고자 한다. 정보처리기사 실기 공부 과정 및 합격 후기정보처리기사 2022년도 1회차 시험을 봤습니다. 저는 전공자이며 취준과 함께 정처기를 준비했습니다. 원래 전공자라면 4학년 때 많이들 따는데.. 올해 졸업하고 취준이랑 같이 병행하는 것이 너programmingiraffe.tistory.com 이 글에서도 볼 수 있듯이 나의 자격증 따는 방식은 '최대한 적은 시간과 비용으로 가성비 있게 따기'이다. 솔..

벌써 2026년도 절반 이상이 지났다. 얼마 전 회사에서 상반기 리뷰를 작성하면서 자연스럽게 지난 6개월을 돌아보게 되었다. 회사 업무뿐만 아니라 개인적으로 어떤 고민을 했고, 무엇을 배우고 시도했는지도 함께 정리해보고자 한다. 돌이켜보면 올해 상반기는 크게 세 가지 변화가 있었다. 서비스 개발을 하다가 빌링 파트로 이동하며 데이터 처리와 정합성을 더욱 깊게 다루게 되었고, Claude를 비롯한 AI를 업무에 적극적으로 활용하기 시작했다. 그리고 개발자로서의 역할과 앞으로의 경쟁력에 대해 이전보다 훨씬 많이 고민하게 된 시기이기도 했다. 빌링 파트로 이동 상반기의 가장 큰 변화는 팀 내에서 빌링 파트로 이동한 것이다. 빌링 파트는 서비스에서 발생하는 로그를 수집하고, 이를 기반으로 정산과 통계를 ..

배경얼마 전 업무에서 캐시를 적용했는데도 성능이 나아지지 않는 이상한 상황을 겪었다.캐시 히트는 정상이었다. 근데 느렸다. 문제는 8500개짜리 Map을 캐시에서 꺼내는 로직에 있었다. getDataMap()은 분명 캐시에서 응답하고 있었는데, 요청이 몰릴 때마다 성능 저하가 반복됐다.@Cacheable(value = "dataCache", key = "'dataMap'")public Map getDataMap() { return dataRepository.findAll();} 원인을 파고들다 보니 내가 캐시 설정 파일에서 무심코 을 쓰고 있었다는 걸 알게 됐다. 50 그리고 그때 처음으로 제대로 이해했다. Heap 캐시와 Offheap 캐시는 동작 방식 자체가 다르다는..

ClickHouse를 처음 쓰다 보면 한 번쯤 이런 경험을 한다. MySQL에서는 아무 문제 없이 돌아가던 JOIN 쿼리가 ClickHouse에서는 유독 느리거나, WHERE 조건을 다 걸었는데도 풀스캔 수준의 시간이 걸리는 것이다. 이 글에서는 그 이유를 ClickHouse의 내부 동작 방식에서 찾고, 실제로 쓸 수 있는 최적화 전략을 정리한다. 어떤 상황인가 수억 건의 유저 행동 로그(page_view_log)와 주문 데이터(order_log)를 JOIN해서 페이지를 본 특정 기간, 특정 유저의 구매 건수를 집계한다고 해보자. 아래처럼 쓰는 것이 자연스럽다.SELECT count(*)FROM default.page_view_log p JOIN default.order_log o ON ..