분류 전체보기 143

[인프런] Simple Design: 25년차 개발자가 전하는 깔끔한 코드의 본질

좋은 코드의 기준, 정말 '주관적'일까요?좋은 코드의 기준이 있을까요? 깔끔한 코드? 읽기 쉬운 코드? 아름다운 코드?좋은 코드의 기준이 이런 주관적인 것 밖에 없을까요?팀장과 나의 코드 기준이 다른가요?동료들의 코드를 리뷰할 때 나는 어떤 이야기를 해줄 수 있을까요?본 밋업에서는 코드의 품질을 좀더 객관적으로 판단할 수 있는 기준들을 제시합니다.그러나, 그 기준을 단순히 제시하는 것에 그치기보다는, 그 기준을 이끌어내기 위해 어떤 질문들을 던졌는지어떤 사고 과정을 거쳤는지를 공유하고 각자가 스스로 고민하고 판단할 수 있는 기회를 제공하고자 합니다.그래서, 각자가 다른 사고 과정을 거치더라도 보편적인 기준에 도달할 수 있다는 것을 함께 경험하기를 바랍니다.사실 이 밋업을 듣는다고 해서 갑자기 매일 좋은 ..

스터디 2025.05.06

Elasticsearch 색인(Index) 구조

Elasticsearch 색인(Index) 구조 완전 정복 1. 서론 – Elasticsearch를 이해하려면 Lucene부터Elasticsearch는 강력한 분산 검색 엔진이지만, 그 핵심에는 Apache Lucene이라는 라이브러리가 있습니다. Elasticsearch는 데이터를 검색하기 위해 Lucene을 내부적으로 사용하며, 색인(index)과 검색(search)과 관련된 대부분의 기능은 Lucene의 구조 위에 구축되어 있습니다.따라서 Elasticsearch의 동작 원리를 정확히 이해하려면 Lucene이 데이터를 어떻게 색인하고 검색하는지를 먼저 알아야 합니다.2. Lucene의 색인 구조와 Elasticsearch 내부 동작2.1 문서 색인과 Flush문서가 색인될 때, Lucene은 해당 ..

Elasticsearch 아키텍처 구성 요소

🛠 Elasticsearch 아키텍처 완전 정복: 클러스터, 노드, 인덱스, 샤드, 레플리카Elasticsearch는 대용량 분산 검색 엔진으로, 고성능 검색과 실시간 로그 분석 등에 강력한 성능을 발휘합니다.이번 글에서는 Elasticsearch의 핵심 아키텍처인 클러스터, 노드, 인덱스, 샤드, 레플리카의 개념과 이들 간의 관계를 실무적인 시각으로 자세히 살펴봅니다.📌 전체 구성 요소 한눈에 보기구성 요소설명클러스터 (Cluster)Elasticsearch 전체 시스템 단위노드 (Node)클러스터에 참여하는 서버 한 대인덱스 (Index)문서(Document)들의 논리적 집합샤드 (Shard)인덱스를 물리적으로 분할한 단위레플리카 (Replica)샤드의 복제본, 고가용성 보장🔧 1. 클러스터 (..

Elasticsearch란? Elasticsearch 입문자를 위한 이해하기 쉬우면서도 전문적인 지식을 알아보자.

🔍 Elasticsearch란? 완전 기초부터 핵심까지 한 번에 이해하기데이터의 양이 폭발적으로 증가하는 시대, 빠르고 정확한 검색은 많은 시스템에서 핵심 기능으로 자리잡고 있습니다.Elasticsearch는 이러한 검색 기능을 매우 강력하고 유연하게 제공하는 분산형 검색 및 분석 엔진입니다.이번 포스트에서는 Elasticsearch가 무엇인지, 어떤 구조로 동작하며 어떤 강점을 가지는지 완전 기초부터 핵심 포인트까지 정리해보겠습니다.✅ Elasticsearch란?1. 분산형 RESTful 검색/분석 엔진Elasticsearch는 단순히 텍스트를 검색하는 툴이 아닙니다.다음과 같은 특징을 지닌 다목적 고성능 검색 플랫폼입니다:특징설명분산형 (Distributed)여러 대의 서버에 데이터를 자동 분산 저..

이 작은 차이가 성능을 바꾼다! key={index} vs key={id}

🔍 key={index} vs key={id} 차이점 & 성능 최적화 이유React에서 리스트를 렌더링할 때 각 항목을 구별할 수 있도록 key 속성을 제공해야 합니다.잘못된 key 설정은 불필요한 리렌더링을 유발하고 성능을 저하시킬 수 있습니다.이번 포스팅에서는 key={index}와 key={id}의 차이점을 설명하고, 최적의 방법을 알아보겠습니다.🚨 key={index}의 문제점{data.map((item, index) => ( ))}✔️ index를 key로 사용하면 배열 순서가 바뀔 때 React가 항목을 잘못 인식할 가능성이 큽니다.📌 문제 발생 시나리오1️⃣ 새로운 항목이 리스트 중간에 삽입될 때기존 리스트: [A, B, C]새로운 리스트: [A, NEW, B, C]React는 i..

React 2025.03.18

React 18 + TypeScript + React Query + Hooks 실무 적용기

1. 들어가며최근 프로젝트에서 React 18과 React Query를 활용하여 서버 상태 관리 최적화를 진행했습니다.기존 방식에서는 불필요한 API 요청이 많아 성능 문제가 있었고, 이를 React Query로 개선하면서 어떤 점이 효과적이었는지 공유하려 합니다.특히,✅ React 18의 자동 배치(Auto Batching) 기능이 성능에 미친 영향✅ React Query를 활용한 API 요청 최적화✅ 불필요한 리렌더링을 줄이기 위한 전략에 대해 다룰 예정입니다.2. 실무에서 적용한 핵심 기술2.1 React 18 – 자동 배치(Auto Batching)React 18에서는 여러 개의 setState가 자동으로 하나의 렌더링으로 합쳐지는 자동 배치(Auto Batching) 기능이 도입되었습니다.📌 ..

React 2025.03.18

React 18에서 효율적인 컴포넌트 설계란?

1. 프로젝트 개요프론트엔드를 담당하면서 React 18, TypeScript, React Query, Hooks를 활용하여 개발을 진행했다. 이 과정에서 겪은 문제들과 해결 과정, 그리고 효율적인 컴포넌트 설계에 대해 공유하고자 한다.2. 기술 개요2.1 React 18 개요React 18은 동시성 렌더링(Concurrent Rendering)과 자동 배치(Automatic Batching) 등의 새로운 기능을 추가하여 성능을 향상시킨 버전이다. 주요 기능은 다음과 같다:Concurrent Rendering: UI 업데이트를 더욱 부드럽게 처리할 수 있도록 함Automatic Batching: 여러 상태 업데이트를 자동으로 배치하여 불필요한 렌더링 방지Transition API: UI 상태 전환을 더욱..

React 2025.03.18

[운영] 로그는 적을수록 좋다? ELK 로그 최적화 전략과 운영 팁

ELK 로그 최적화: 불필요한 로그가 애플리케이션 성능에 미치는 영향과 해결책1. 실무에서 발생한 문제최근 ELK(Elasticsearch, Logstash, Kibana) 스택을 활용하여 애플리케이션 로그를 관리하는 과정에서 불필요한 로그가 과도하게 남겨지는 문제를 경험했다. 특히 Elasticsearch Memory Pool 관련 로그가 지속적으로 기록되었는데, 실제 운영에 중요한 로그는 아니었음에도 불구하고 애플리케이션 성능과 운영 비용에 영향을 줄 가능성이 있었다.이 문제를 해결하기 위해 불필요한 로그를 관리하고 최적화하는 방법을 정리해 보았다.2. 불필요한 로그가 애플리케이션 운영에 미치는 영향1) 성능 저하I/O 부하 증가: 로그가 많을수록 디스크 쓰기(Write) 부하가 증가하여 애플리케이션..

운영 2025.03.12

Java 애플리케이션 성능 최적화: JVM 힙 메모리 설정 가이드

JVM 힙 메모리 개념 정리 및 적절한 설정 방법1. JVM 메모리 구조 개요JVM(Java Virtual Machine)은 여러 개의 메모리 영역을 관리하며, 그중 Heap 메모리가 가장 중요한 역할을 한다.아래는 JVM이 사용하는 주요 메모리 영역이다.메모리 영역 역할 및 설명Heap객체가 저장되는 공간. -Xms, -Xmx 옵션으로 크기 조절 가능.Stack각 쓰레드별 메서드 호출 스택을 저장하는 공간.Metaspace클래스 메타데이터 저장 공간 (-XX:MaxMetaspaceSize로 크기 조절).Code CacheJIT(Just-In-Time) 컴파일된 코드 저장 공간.Direct MemoryByteBuffer.allocateDirect() 같은 네이티브 메모리 사용.2. 서버 전체 메모리(4G..

JVM 힙 메모리 개념 정리 및 적절한 설정 방법

1. JVM이 서버의 전체 메모리를 다 사용하지 않는 이유서버에 4GB의 물리적 메모리가 있다고 해도 JVM이 이를 전부 사용하지 않는 이유는 운영 체제(OS)와 JVM의 메모리 관리 방식 때문이다.이를 세부적으로 살펴보면 다음과 같다.(1) OS가 사용할 메모리를 남겨둬야 한다JVM이 실행되는 서버는 단순히 JVM만 사용하는 것이 아니라 OS 자체가 동작하고 있다.네트워크, 디스크 I/O, 캐시 관리 등을 위해 일정 메모리가 필요하다.일반적인 리눅스 서버의 경우, 최소한 500MB~1GB 정도의 메모리를 OS가 자체적으로 사용한다.만약 JVM이 4GB를 전부 차지하면 OS가 원활하게 동작하지 못하고, 전체적인 시스템 성능이 저하될 수 있다.(2) JVM의 Heap 외에도 많은 메모리가 필요JVM이 사용..

운영 2025.03.12