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

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

2024년의 키워드는 '경험'이었다.2023년 4월에 개발자로 커리어를 시작하며 2023년은 회사에 적응하며 보냈었고, 차츰 적응이 되기 시작했던 2024년은 다양한 경험을 하기 위해 이것저것 시도를 많이 해보았다.회고를 통해 이번 연도에 경험했던 것들을 다시 돌아보며 정리해보려고 한다. 우당탕탕 사이드 프로젝트우선 2024년 1월에는 사이드 프로젝트를 "비사이드"라는 플랫폼을 통해 시작했다."비사이드"는 사이드 프로젝트 모임 플랫폼인데, 14주간 개발자, 디자이너, 기획자들과 함께 한 팀을 이루어 프로젝트를 출시하는 프로그램에 참여했었다. (다시 찾아보니 지금은 사라지고 10일 만에 끝내는 포텐데이라는 프로그램만 존재한다.)결과부터 말하면 프로젝트는 출시조차 하지 못하게 되었다.기획, 디자인, 개발까지..

TL;DRPPT 보고서를 LLM을 통해 특정 형식(JSON)으로 요약할 때, 키워드 누락 문제가 발생하여 명시적 지시문 추가, Chain-of-Thought(생각의 사슬), 역할 기반 프롬프팅, 퓨샷(Few-Shot) 프롬프팅 등 다양한 전략을 시도함.결과적으로 원샷 대신 퓨샷 프롬프팅으로 변경하니 입력 토큰은 약 22% 증가했지만, 키워드 누락 없이 정확도가 크게 개선됨.비용과 정확성의 트레이드오프를 고려했을 때 퓨샷 프롬프팅이 효과적임을 확인함.  PPT로 작성된 보고서를 텍스트만 전달하여 LLM 기반으로 보고서를 특정 형식에 맞게 요약하는 시스템을 개발하고 있었습니다. 현재 이슈는 보고서의 특정 슬라이드에 포함되어 있는 키워드들만 가져와서 요약해줘야 했는데, 키워드들이 누락되어 요약되는 이슈가 있었..

최근 빌더 패턴을 구현하다 CRTP(Curiously Recurring Template Pattern) 패턴을 알게 되었는데, 처음 접하는 패턴이라는 점과 제네릭을 통해 구현된 다소 복잡해 보이는 패턴이라 공부하게 되었습니다. 이번 글을 통해 CRTP 패턴이 무엇인지와 장단점에 대해 소개드립니다. CRTP란?CRTP는 원래 C++에서 주로 사용되는 패턴으로 클래스가 자신의 서브클래스 타입을 제네릭 매개변수로 사용하는 디자인 패턴입니다. 자바에서는 주로 빌더 패턴에서 자식 클래스의 타입을 부모 클래스에 전달하여 메서드 체이닝 시 자식 클래스의 메서드를 사용할 수 있게 합니다. (제네릭을 이용한 재귀적 타입 제한) 즉, 빌더 패턴에서 주로 이루어지는 메서드 체이닝에서 자식 클래스 타입을 유지함으로 컴파일 시..

TL;DR주식 시장 마감 후 코스피/코스닥 종목의 종가와 수익률을 계산해 시황 피드를 생성하는 시스템에서 종가 변동률 계산 오류가 발생했습니다. 문제는 시황 정보 생성 시점에 당일 종가 정보가 DB에 아직 저장되지 않아 이전 영업일 데이터를 참조한 데 있었습니다. 이를 해결하기 위해 피드 생성 서버 코드를 수정하여 시황 정보 수신 시 종가 데이터 유무를 확인하고, 종가 정보가 없으면 상태를 저장한 후 스케줄러를 통해 주기적으로 재시도하는 방안을 도입했습니다. 이로써 데이터 정합성을 확보하고 버그를 수정했습니다. 항상 버그는 퇴근하고 발생하는 것 같은 기분이 듭니다.  주식 시장이 마감되고 코스피/코스닥에 상장된 종목들의 종가 및 종목 수익률을 계산하여 당일 시황의 전반적인 상황을 피드로 생성하여 제공하는..