2025년 상반기 회고 상반기를 돌아보며 - 시간이 정말 빠르게 흘러 벌써 2025년 상반기가 훌쩍 지나갔다. 매년 연간 단위로 회고 글을 작성해 왔지만, 문득 이번에는 상반기를 되돌아보는 시간을 가져야겠다고 생각했다.특히 이번 상반기에는 업무적으로 담당했던 기능이 많아 매우 바쁘게 보냈던 터라, 이 시점에서 한번 정리하는 시간을 갖는 것이 좋겠다 싶었다. 바쁜 업무를 핑계로 개인적인 성장이 소홀했던 점은 없는지 돌아보고 반성하는 마음도 이번 회고글에 담으려 한다.지난 6개월간의 업무적인 성장뿐만 아니라 개인적인 경험까지, 나의 상반기 전반을 솔직하게 돌아볼 예정이다.잘했던 점과 아쉬웠던 점을 돌아보며 앞으로 더 나아갈 나를 위한 소중한 발판을 마련하고자 한다. 1. 회사이번 상반기에는 정말 다양한 업..

"또 테스트 코드를 작성하라고? 실제 기능 개발하기도 바쁜데..."많은 개발자, 특히 저와 같은 주니어 개발자들이 테스트 코드 작성에 대해 처음 가지는 생각입니다.저 역시 그랬습니다. 테스트 코드를 작성하면 개발 시간이 배로 늘어날 것이고, 코드를 리팩터링 할 때마다 테스트 코드까지 수정해야 한다면 유지보수는 더욱 힘들어질 거라고 생각했습니다. 그리고 무엇보다 "도대체 어떤 것을 검증해야 옳은 테스트 코드인가?"라는 근본적인 질문이 항상 머릿속을 맴돌았습니다. 약 70개의 단위 테스트 코드를 작성하며 신규 기능을 개발한 지금, 제 인식은 완전히 바뀌었습니다. 테스트 코드 작성은 시간 낭비가 아니라 오히려 시간을 절약하기 위한 투자였습니다. 테스트 코드를 통해 안정적인 리팩토링이 가능해졌고, Postma..

TL;DR거래대금 상위 50개 기업 조회 API가 임시 테이블 정렬로 인해 10초 이상 걸리자 redis에 캐싱해 3초까지 줄였지만 실시간 주가 50회 개별 조회가 RTT 70 ms씩 추가돼 병목이 남았다. redis 파이프라인을 활용한 벌크 조회로 redis 요청을 50→1회로 줄여 최종 응답을 200 ms 이하로 단축했고, 병목은 항상 ‘가장 느린 부분’을 찾아야 한다. 최근 신규 서비스를 준비하며 신규 API를 개발하는 일이 많았는데, 그중 API 성능을 높이기 위해 Redis 캐시를 도입하여 성능 개선을 시도했으나 기대한 만큼 개선 효과를 보지 못한 일이 발생하였습니다. 이번 글에서는 해당 성능 이슈의 원인을 알아보고, 병목 지점을 분석하여 API 성능을 개선한 해결방안을 정리해보려고 합니다. 문..

TL;DR단일 스레드에서 멀티스레드로 전환했음에도 배치 성능이 개선되지 못했던 이유MySQL CPU 사용률 99%가 병목의 원인이었으며, 이는 비즈니스 요구사항 때문에 불가피했던 LIKE 패턴 매칭 쿼리 때문이었습니다. 문제 해결을 위해 LIKE 쿼리를 IN 절로 변환하는 작업을 진행했고, 그 결과 CPU 사용률은 20% 이하로 떨어지고 배치 처리 시간은 10분에서 단 25초로 단축되어 사용자들이 최신 데이터에 즉시 접근할 수 있게 되었습니다. "배치 성능 개선? 그거 멀티스레드 쓰면 해결되는 거 아니었어?"아마 많은 개발자분들이 저와 같은 생각을 해보셨을 겁니다.저는 사용자에게 최신 데이터를 제공하는 신규 기능을 개발하고 있었습니다. 이 신규 기능의 핵심은 사용자가 원하는 특정 기준으로 데이터를 커스텀..

멀티 스레드로 병렬 처리하는 것은 항상 성능에 이점이 있을까?업무를 진행하며 멀티 스레드로 성능 개선을 할 일이 있었는데, “멀티 스레드로 병렬 처리하는 것이 항상 성능 향상에 이점이 있을까?”라는 의문점이 생겼습니다. 가령, 스타크래프트 같은 게임에서 일꾼 수가 많을수록 더 많은 미네랄을 동시에 캐는 것처럼, 스레드가 많으면 그만큼 동시에 처리할 수 있는 작업이 많아져서 단일 스레드보다 빠르다고 생각하기 쉽습니다.저도 처음엔 “스레드가 많으면 빠르다, 따라서 스레드 수와 애플리케이션의 성능 속도는 정비례한다”고 단순하게 생각했습니다.하지만 실제로는 꼭 그렇지만은 않습니다. 예를 들어 단일 스레드로 동작한다고 알고 있는 Redis는 매우 빠른 처리 속도를 보여주는데, 이는 “단일 스레드 = 느리다”라는 ..

DB에서 쿼리 최적화(Query Optimization)는 성능을 결정짓는 핵심 요소 중 하나이다. 간단히 Optimizer는 사용자가 작성한 SQL 쿼리를 분석하여 실행 비용이 가장 낮은(또는 상대적으로 효율적인) 실행 계획을 선택하는 역할을 맡는다.MySQL Optimizer의 내부 구조와 동작 원리를 알아보고, 쿼리가 어떻게 최적화되어 실행 계획으로 이어지는지, 그리고 어떤 데이터나 통계를 활용하는지에 대한 이해 하고자 한다. Optimizer의 기본 개념아래는 전체적인 쿼리 실행 단계를 도식화한 예시이다. 쿼리 파싱SQL 문이 서버로 들어오면, MySQL SQL Parser는 쿼리 문법을 검사하고 내부 표현 구조(Parse Tree)로 변환한다. 이 과정에서 문법적으로나 구조적으로 쿼리에 오류가 ..