브루트포스 - 테트로미노 by 백준 14500
🔗 테트로미노 14500번 문제
Posts by Category
- Algorithm 44
- SYSTEMDESIGN 34
- JAVA 27
- SPRING 26
- DB 17
- FRONTEND 16
- INTERVIEW 15
- HTTP 12
- KAFKA 10
- REDIS 10
- DEVTOOLS 9
- AI 8
- ARCHITECTURE 7
- KOTLIN 7
- GIT 6
- CACHING 5
- CLOUD 5
- JPA 5
- NETWORK 5
- EFFECTIVE_JAVA 4
- MONITORING 4
- NOSQL 4
- TEST 4
- CICD 3
- SERVER 3
- DESIGNPATTERN 3
- AI_TOOLS 3
- FINANCE 2
- PRODUCTIVITY 2
- TROUBLESHOOTING 2
Algorithm
브루트포스 - 리모컨 by 백준 1107
🔗 리모컨 1107번 문제
브루트포스 - 일곱난장이 by 백준 2309
🔗 일곱 난장이 2309번 문제
연속합2 by 백준 13398번
🔗 연속합2 13398번 문제
브루트포스 - 사탕 게임 by 백준 3085
🔗 사탕 게임 3085번 문제
가장 긴 바이토닉 부분 수열 by 백준 11054
🔗 가장 긴 바이토닉 부분 수열 11054번 문제
가장 긴 감소하는 부분 수열 by 백준 11722
🔗 가장 긴 감소하는 부분 수열 11722번 문제
가장 큰 증가 부분 수열 by 백준 11055
🔗 가장 큰 증가 부분 수열 11055번 문제
정수 삼각형 by 백준 1932
🔗 정수 삼각형 1932 문제
와인 시음 by 백준 2156
🔗 와인시음백준 2156문제
동물원 by 백준 1309
🔗 동물원 백준 1309 문제
스티커 by 백준 9465
🔗 스티커 백준 9465문제
RGB 거리 by 백준 1149
🔗 RGB 거리 백준 1149 문제
오르막 수 by 백준 11507
🔗 오르막 수 백준 11507문제
1,2,3 더하기 3 by 백준 15988
🔗 1,2,3 더하기 3 백준 15988문제
합분해 by 백준 2225
🔗 합분해 백준 2225문제
제곱수의 합 by 백준 1699
🔗 제곱수의 합 백준 1699 문제
연속합 by 백준 1912
🔗 연속합 백준 1912 문제
가장 긴 증가하는 부분수열4 by 백준 14002
🔗 가장 긴 증가하는 부분 수열4 백준 14002문제
가장 긴 증가하는 부분수열 by 백준 11053
🔗 가장 긴 증가하는 부분 수열 백준 11053문제
이친수 by 백준 2193
🔗 이친수 백준 2193문제
쉬운 계단수 by 백준 10844
🔗 쉬운 계단 수 백준 10844문제
1,2,3 더하기 5 by 백준 15990
🔗 1,2,3 더하기 5 백준 15990문제
카드 구매하기2 by 백준 16194
🔗 카드 구매하기2 백준 16194문제
카드 구매하기 by 백준 11052
🔗 카드 구매하기 백준 11052문제
2 x n 타일링 by 백준 11726
🔗 2 x n 타일링 백준 11726문제
1로 만들기 by 백준 1463
🔗 1로 만들기 백준 1463문제
골드바흐 파티션 by 백준 17103
🔗 골드바흐의 파티션 백준 17103문제
숨바꼭질6 by 백준 17087
🔗 숨바꼭질6 백준 17087문제
이진수 8진수 변환 by 백준 1373
🔗 2진수 8진수 변환 백준 1373문제
소수 구하기 by 백준 1929
🔗 소수 구하기 백준 1929문제
소수 찾기 by 백준 1978
🔗 소수 찾기 백준 1978문제
골드바흐의 추측 by 백준 6588
🔗 골드바흐의 추측 백준 1929문제
최대공약수의 합 by 백준 9613
🔗 최대공약수 합 9613문제
최대공약수 최소공배수 by 백준 2609
🔗 최대공약수 최소공배수 백준 2609문제
팩토리얼의 0의 개수 by 백준 1676
🔗 팩토리얼의 0의 개수 백준 1676문제
단어 뒤집기2 by 백준 17413
🔗 단어 뒤집기2 백준 17413문제
단어 뒤집기 by 백준 9093
🔗 단어 뒤집기 백준 9093문제
오큰수 by 백준 17298
🔗 오큰수 백준 17298문제
수열 by 백준 1874
🔗 수열 백준 1874 문제 [스택]
괄호 by 백준 9012
🔗 괄호 백준 9012 문제 [스택]
쇠막대기 by 백준 10799
🔗 쇠막대기 백준 10799문제
에디터 by 백준 1406
🔗 에디터 백준 1406 문제 [스택]
졸업학기 알고리즘 - 자바
SYSTEMDESIGN
작업 스케줄러 설계 — 하루 1억 건 비동기 작업을 지연 없이 처리하는 법
한 줄 요약: 작업 스케줄러의 핵심은 Kafka 파티셔닝으로 처리량을 수평 확장하고, Redis Sorted Set으로 지연 실행을 마이크로초 단위로 제어하며, 분산 락으로 크론 중복 실행을 원천 차단하는 것이다.
스트리밍 플랫폼 설계 — 1억 동시 시청자에게 끊김 없이 전송하는 법
한 줄 요약: 스트리밍 플랫폼의 핵심은 RTMP 인제스트 → DAG 트랜스코딩 → 멀티 CDN HLS/DASH 배포의 3단 파이프라인으로 1억 시청자를 감당하고, Redis HyperLogLog·Sorted Set·Lua 스크립트로 실시간 지표를 제공하며, Kafka → Fl...
정산 시스템 설계 — 수천 셀러에게 1원 오차 없이 정산하는 법
한 줄 요약: 정산 시스템의 핵심은 정확성과 감사 가능성(Auditability)이다. float 한 줄, 배치 한 번의 실수가 수천 셀러에게 1원씩 빠지는 사고로 이어진다. 모든 돈의 흐름에는 검증 가능한 흔적이 있어야 한다.
셀러 관리 시스템 설계 — 10만 셀러의 입점·상품·정산을 통합 관리하는 법
한 줄 요약: 셀러 관리 시스템의 핵심은 입점 심사 자동화로 운영 병목을 없애고, 스코어링 엔진으로 셀러 품질을 실시간 추적하며, 정산 파이프라인으로 분쟁을 원천 차단하는 것이다.
반품·환불 시스템 설계 — 하루 10만 건 환불을 실시간으로 처리하는 법
한 줄 요약: 반품·환불은 주문의 역방향이 아니다. 금액 분배, 재고 복원, 물류 수거, 어뷰징 탐지까지 독립적으로 설계해야 하루 10만 건을 실수 없이 처리할 수 있다.
프로모션·동적 가격 시스템 설계 — 수만 개 딜을 충돌 없이 운영하는 법
한 줄 요약: 프로모션·동적 가격 시스템의 핵심은 룰 엔진으로 할인 충돌을 우선순위 기반으로 해소하고, 이벤트 소싱으로 가격 이력을 불변 보존하며, CDC 파이프라인으로 검색·목록·상세 페이지 전체에 가격을 밀리초 내 동기화하는 것이다.
메트릭 파이프라인 설계 — 초당 100만 데이터포인트를 수집·저장·알림하는 법
한 줄 요약: 메트릭 파이프라인은 수집 에이전트가 데이터를 밀어 넣고, Kafka가 폭발을 흡수하며, 시계열 DB가 압축 저장하고, 알림 엔진이 이상을 감지하는 4계층 구조다. 각 계층이 독립적으로 확장 가능해야 전체가 살아남는다.
멤버십·로열티 시스템 설계 — 5천만 회원의 등급·포인트를 실시간 관리하는 법
한 줄 요약: 멤버십 시스템의 핵심은 구매 이벤트를 소싱해 등급을 실시간으로 산정하고, 포인트 원장을 이중 원장 구조로 관리해 잔액 불일치를 원천 차단하며, 혜택 엔진을 룰로 분리해 배포 없이 정책을 바꾸는 것이다.
풀필먼트·WMS 시스템 설계 — 하루 100만 건 출고를 정확히 처리하는 법
한 줄 요약: 풀필먼트 시스템의 핵심은 세 가지다. 주문 할당 엔진으로 올바른 센터를 고르고, 피킹 최적화로 창고 이동 거리를 줄이며, 재고 실시간 동기화로 “있다고 표시된 물건이 실제로 있음”을 보장한다. 이 세 가지를 WHY 중심으로 이해하면 물류 시스템 면접의 80%를 ...
사기 탐지 시스템 설계 — 초당 5만 결제를 200ms 안에 판정하는 법
한 줄 요약: 사기 탐지는 속도와 정확도의 트레이드오프가 아니라, 룰 엔진으로 명백한 사기를 0ms에 차단하고, ML 스코어링으로 모호한 거래를 판정하며, 피드백 루프로 날마다 더 영리해지는 레이어드 방어선 구조다.
분산 락 설계 — 10만 TPS 환경에서 정확히 하나만 실행하는 법
한 줄 요약: 분산 락의 핵심은 “원자성”과 “소유권 증명”이다. SET NX 한 줄로 락을 걸 수 있지만, 잘못 설계하면 10만 TPS 트래픽 앞에서 이중 결제, 재고 음수, 중복 배송이 동시에 터진다. 락을 거는 것보다 올바르게 해제하는 것이 훨씬 어렵다.
API Gateway 설계 — 초당 50만 요청을 안전하게 라우팅하는 법
한 줄 요약: API Gateway는 단순한 리버스 프록시가 아니라, 인증·Rate Limit·Circuit Breaker·변환을 한 곳에 응집시켜 수백 개의 마이크로서비스를 클라이언트로부터 격리하는 시스템의 현관문이다.
커머스 광고 플랫폼 설계 — 초당 10만 광고 요청을 50ms 안에 입찰하는 법
한 줄 요약: 커머스 광고 플랫폼의 핵심은 후보 선별 → 입찰 → 랭킹 3단계 서빙 파이프라인으로 50ms 내 응답하고, Redis 원자 차감으로 예산 초과를 막으며, 스트리밍 클릭 집계로 광고주에게 실시간 가시성을 제공하는 것이다.
인증/인가 설계 — JWT 토큰 하나가 탈취되면 전체 시스템이 무너지는 이유
한 줄 요약: 인증/인가 시스템의 핵심은 Access Token의 수명을 짧게 유지하고, Refresh Token을 Rotation시키며, 탈취 시 즉시 무효화할 수 있는 블랙리스트 체계를 갖추는 것이다.
장바구니 설계 — 로그인 전후 장바구니를 끊김 없이 합치는 법
한 줄 요약: 비로그인 임시 장바구니를 Redis에 보관하고, 로그인 시 병합 전략(수량 합산 vs 로그인 우선)으로 충돌을 해소하며, 재고는 결제 시점에만 잠그는 것이다.
리뷰 시스템 설계 — 가짜 리뷰를 걸러내고 신뢰할 수 있는 별점을 만드는 법
한 줄 요약: 리뷰 시스템의 핵심은 베이지안 평균으로 소수 리뷰의 왜곡을 막고, Wilson Score로 유용한 리뷰를 정렬하며, 하이브리드 스팸 탐지 파이프라인으로 가짜 리뷰를 걸러내는 것이다.
추천 시스템 설계 — 고객이 원하는 상품을 고객보다 먼저 아는 법
한 줄 요약: 추천 시스템의 핵심은 협업 필터링으로 숨겨진 취향을 발굴하고, 2단계 파이프라인(후보 생성 → 정밀 랭킹)으로 수억 개 상품을 100ms 안에 걸러내며, 콜드 스타트와 인기 편향을 동시에 해결하는 것이다.
상품 카탈로그 설계 — 수억 개 상품을 1초 안에 검색·필터링하는 법
한 줄 요약: 쓰기는 RDB로 정확하게, 읽기는 Elasticsearch와 Redis로 빠르게 분리하고, 멀티테넌트 구조로 수백만 셀러의 상품을 격리하면서 단일 검색 인덱스로 통합 제공한다.
주문 시스템 설계 — WHY로 시작하는 초당 만 건 처리 아키텍처
한 줄 요약: 시니어는 “무엇을 쓰느냐”가 아니라 “왜 쓰느냐”를 설명한다. MySQL을 고른 이유, Saga를 고른 이유, CQRS를 고른 이유 — 모든 결정에 WHY가 있어야 면접을 통과한다.
재고 시스템 설계 — 동시 차감, 초과판매 방지, 타임딜 극한 트래픽
한 줄 요약: MySQL은 ACID로 재고 불변식을 강제하고, Redis는 원자 DECR로 동시 차감 경쟁을 차단하며, Kafka는 비동기 분리로 확정 지연을 흡수한다. 세 계층이 각자의 역할을 맡아야 초과판매 0건과 타임딜 극한 트래픽을 동시에 달성한다.
배송 시스템 설계 — 주문 후 몇 시간 만에 문 앞에 도착하는 구조
한 줄 요약: 배송 시스템의 핵심은 실시간 위치 추적으로 고객 불안을 제거하고, 최근접 창고 선택으로 리드타임을 단축하며, 이벤트 소싱으로 배송 상태 이력을 완전하게 보존하는 것입니다.
쿠폰 시스템 설계 — 선착순 10만 장을 정확히 10만 장만 발급하는 법
한 줄 요약: 쿠폰 시스템의 핵심은 Redis 원자 연산으로 초과 발급을 막고, 룰 엔진으로 할인 조합을 유연하게 계산하며, 멀티 어카운트 어뷰징을 사전에 차단하는 것이다.
채팅 시스템 설계 — 카카오톡을 직접 만들어보자
한 줄 요약: 채팅 시스템은 WebSocket으로 양방향 실시간 연결을 유지하고, Kafka로 서버 간 메시지를 라우팅하며, Cassandra로 수 페타바이트 메시지를 저장한다. 각 선택에는 “왜 이것이어야 하는가”라는 명확한 근거가 있다.
위치 기반 서비스 설계 — 배달의민족이 반경 3km 가게를 0.1초 만에 찾는 방법
한 줄 요약: 위치 기반 서비스의 핵심은 Geohash로 2차원 좌표를 1차원 문자열로 변환하여 B-Tree 인덱스로 근접 검색하고, Redis + Pub/Sub로 라이더 위치를 실시간 전파하는 것이다.
알림 시스템 설계 — 1억 명에게 10초 안에 푸시를 보내는 구조
블랙프라이데이 자정, 쿠팡이 1억 명에게 동시에 “특가 시작!” 푸시를 보낸다. 10초 안에 전달되어야 한다. 단일 서버가 APNs와 FCM을 1억 번 직접 호출하면 서버는 즉시 죽는다. 알림 하나를 보내는 것은 쉽다. 신뢰할 수 있게, 대량으로, 빠르게, 중복 없이 보내는 것이 ...
시스템 디자인 완전 정복 — 요구사항부터 병목 해소까지 7단계 WHY 접근법
한 줄 요약: 시스템 디자인 면접의 핵심은 컴포넌트 나열이 아니라 “왜 이 선택인가”를 요구사항에서 논리적으로 도출하는 것이다. 암기가 아니라 사고 과정을 보여줘야 시니어 면접관을 설득할 수 있다.
분산 파일 저장소 설계 — Google Drive를 직접 만들어보자
한 줄 요약: 분산 파일 저장소의 핵심은 파일을 4MB 블록으로 쪼개 SHA-256 해시로 중복을 제거하고, 메타데이터 DB로 블록 조각을 추적하며, SSE/WebSocket으로 여러 디바이스에 변경을 실시간 전파하는 것이다.
동영상 스트리밍 설계 — YouTube가 매초 500시간 분량의 영상을 어떻게 처리하는가
한 줄 요약: YouTube의 핵심은 업로드된 영상을 DAG 기반 트랜스코딩 파이프라인으로 해상도별 분할 처리하고, HLS/DASH ABR로 네트워크 상황에 맞게 스트리밍하며, 글로벌 CDN으로 지연시간을 최소화하는 것이다.
뉴스피드 시스템 설계 — BTS가 게시글 올리면 7000만 팔로워 피드가 어떻게 업데이트되는가
BTS가 인스타그램에 사진을 올리는 순간, 7000만 팔로워의 피드가 업데이트되어야 한다. 7000만 건의 캐시 업데이트를 동기로 처리하면? 게시글 저장에 수십 분이 걸린다. 반대로 아무것도 하지 않으면? 팔로워가 피드를 열 때마다 7000만 개 팔로잉의 게시글을 DB에서 읽어야 ...
결제 시스템 설계 — 1원도 틀리면 안 되는 시스템을 어떻게 만드는가
한 줄 요약: 결제 시스템의 핵심은 세 가지다. 멱등성 키로 이중 결제를 원천 차단하고, 복식부기로 1원 단위 자금 무결성을 보장하며, PG 추상화 레이어로 벤더 장애를 투명하게 폴백한다. 이 세 가지를 “왜(WHY)” 그렇게 설계해야 하는지 이해하면 결제 시스템 면접의 80...
검색 시스템 설계 — 100억 문서에서 100ms 안에 결과를 찾는 법
구글에 “파이썬 머신러닝”을 검색하면 수천억 개의 웹페이지 중에서 관련 결과가 100ms 안에 나온다. 단순히 “파이썬”과 “머신러닝”이 들어간 페이지를 하나씩 뒤지면? 전 세계 서버를 동원해도 수십 년이 걸린다. 검색이 빠른 이유는 데이터를 저장하는 방식이 근본적으로 다르기 때문...
URL 단축기 설계 — bit.ly가 7글자로 3.5조 개의 URL을 처리하는 방법
트위터가 140자 제한이었던 시절, https://www.example.com/very/long/path?campaign=summer&source=newsletter&medium=email 같은 URL은 그 자체로 트윗 대부분을 차지했다. bit.ly는 이 문제를 7...
Rate Limiter 완전 정복 — 알고리즘 내부부터 분산 설계, DDoS 방어까지
2023년 새벽 3시, 한 스타트업의 API가 다운됐다. 경쟁사 봇이 초당 5만 건을 보냈고, DB 커넥션 풀이 고갈되며 서비스 전체가 멈췄다. Rate Limiter가 있었다면 IP당 초당 100건 제한으로 이 봇의 요청 99.998%가 차단됐을 것이다. Rate Limiter는...
Key-Value 스토어 설계 — Redis/DynamoDB는 어떻게 수백만 QPS를 처리하는가
2024년 블랙프라이데이, 아마존의 DynamoDB는 초당 1억 건 이상의 요청을 처리했다. Redis는 단일 노드에서 초당 100만 QPS를 넘긴다. 이 숫자들이 가능한 이유는 단순한 “빠른 하드웨어” 때문이 아니다. 데이터를 어떻게 쪼개고, 복제하고, 저장하고, 복구하는지에 관...
JAVA
Java Virtual Threads vs Kotlin Coroutines — 경량 스레드 완전 비교
서버가 초당 10만 개의 HTTP 요청을 처리해야 한다. 전통적인 스레드 풀로는 불가능하다. 스레드 하나에 1MB 스택이 필요하면 10만 개는 100GB 메모리가 필요하다. 이 문제를 해결하기 위해 Java는 Project Loom의 Virtual Threads를, Kotlin은 ...
Java Record 완전 정복 — 왜 만들었고, DTO를 대체할 수 있는가
한 줄 요약: Record는 “데이터를 운반하는 투명한 캐리어”를 만들기 위해 Java 16에서 정식 도입된 언어 구조체로, 컴파일러가 필드·접근자·equals·hashCode·toString을 자동 생성하여 보일러플레이트를 언어 수준에서 제거한다.
Java HashMap 내부 해부 — 해시 함수·버킷·Red-Black Tree·스레드 안전성 극한 분석
한 줄 요약: HashMap은 h ^ (h >>> 16) 보조 해시로 비트를 섞고, (n-1) & hash 비트 AND로 버킷 인덱스를 구하며, 충돌이 8개를 넘으면 Red-Black Tree로 전환하고, 로드 팩터 0.75를 넘으면 2배 resize한...
Java Concurrent 자료구조 완전 정복 — 내부 메커니즘부터 극한 시나리오까지
결제 서버에서 HashMap을 공유 캐시로 사용했다. 트래픽이 몰린 순간 CPU가 100%에 박히고 모든 응답이 멈췄다. GC 로그에는 이상이 없었다. 원인은 Java 7 HashMap의 resize() 과정에서 두 스레드가 동시에 버킷 포인터를 조작해 형성된 순환 연결 리스트 였...
Java 함수형 프로그래밍
Java는 본래 순수 객체지향 언어지만, Java 8부터 람다와 Stream API를 통해 함수형 프로그래밍 패러다임을 적극 수용했습니다. 함수형 프로그래밍의 핵심 개념을 이해하고 Java에서 어떻게 적용하는지 깊이 있게 살펴봅니다.
Java 컬렉션 프레임워크 — 내부 구조 완전 분석
ArrayList와 LinkedList 중 무엇을 고를지, HashMap이 왜 멀티스레드에서 무한루프를 일으키는지, ConcurrentHashMap이 어떻게 락 없이 읽기를 처리하는지 — 이 질문들에 정확히 답하려면 내부 자료구조와 JVM 메모리 모델을 함께 알아야 한다. 선택 하...
Java 중첩 클래스
Java는 클래스 안에 클래스를 선언할 수 있습니다. 이를 중첩 클래스(Nested Class)라고 하며, 종류에 따라 동작 방식과 사용 목적이 크게 다릅니다. 잘못 사용하면 메모리 누수의 원인이 되기도 하므로, 각각의 특성을 정확히 이해하는 것이 중요합니다.
Java 제네릭(Generics) 심층 분석
Java 제네릭은 1995년 출시된 Java에 2004년(Java 5) 뒤늦게 합류한 기능입니다. 단순한 “타입 파라미터 문법” 수준을 넘어, 타입 소거(Type Erasure), 브리지 메서드, PECS, 힙 오염, Reified 제네릭 부재 등 JVM 설계 철학이 깊게 녹아 있...
Java 스레드(Thread) — 동시성 프로그래밍 심층 해부
주문 처리와 이메일 발송을 순차적으로 하면 사용자는 이메일 발송이 끝날 때까지 기다려야 한다. 스레드를 분리하면 주문 처리 응답을 즉시 돌려주고 이메일은 백그라운드에서 보낼 수 있다. 하지만 스레드를 잘못 다루면 데이터가 조용히 망가진다. 예외 없이, 로그 없이, 오직 잘못된 결과...
Java 예외 처리
Java의 예외 처리는 단순한 try-catch 문법을 넘어, 시스템의 견고성과 유지보수성을 결정하는 설계 영역입니다. 예외 계층 구조부터 커스텀 예외 설계, Spring의 예외 전략까지 완전히 정리합니다.
Java 버전별 핵심 변화 — Java 7부터 최신까지, 왜 바뀌었는지까지
한 줄 요약: Java는 버전마다 “개발자가 반복적으로 겪는 고통”을 제거해왔다. 각 기능이 왜 만들어졌는지 이해하면 버전 변화가 하나의 흐름으로 보인다.
Java 래퍼 클래스와 오토박싱
Java는 기본형(primitive type)과 참조형(reference type)이라는 두 가지 타입 체계를 가집니다. 이 둘 사이의 간극을 메우는 것이 래퍼 클래스(Wrapper Class)이며, 오토박싱(Auto-boxing)은 이 변환을 자동화한 Java 5의 핵심 기능입니...
Java 리플렉션(Reflection)
리플렉션은 런타임에 클래스 구조를 분석하고 동적으로 조작하는 강력한 기법입니다. Spring, JPA, Jackson, JUnit이 모두 이를 기반으로 동작합니다. 원리부터 실무 활용까지 상세히 정리합니다.
Java 네트워크 프로그래밍
Java는 소켓부터 HTTP 클라이언트까지 풍부한 네트워크 API를 제공합니다. TCP/UDP 저수준 통신부터 NIO 기반 고성능 서버까지 전체를 상세히 정리합니다.
Java 람다(Lambda) — invokedynamic부터 커링까지 내부 원리 완전 분석
Java 8이 람다를 도입한 것은 단순한 문법 편의가 아닙니다. JVM 명령어 체계 자체를 확장(invokedynamic)하고, 런타임 코드 생성 메커니즘(LambdaMetafactory)을 추가하며, 함수형 인터페이스 타입 시스템을 설계했습니다. 겉으로 보이는 (a, b) -&g...
Java 날짜와 시간 API (java.time)
Java 8에서 도입된 java.time 패키지는 기존 Date와 Calendar의 고질적인 문제를 해결하고, 불변(Immutable) 설계와 직관적인 API를 제공합니다. 현대 Java 개발에서 날짜·시간 처리의 표준입니다.
Java 가비지 컬렉터(GC) 완전 정복
API 응답이 평소엔 8ms인데 가끔 340ms로 폭등한다. GC 로그를 열면 그 순간 Pause Full (Ergonomics) 312ms가 찍혀 있다. 원인은 알겠는데, 왜 이 시점에 Full GC가 터졌고, 어떻게 막아야 할지 모르면 튜닝은 찍기 게임이 된다. GC를 알고리즘...
Java Virtual Thread 완전 분석 — 내부 동작 원리부터 실전 운영까지
비유로 먼저 이해하기: 고속도로 톨게이트를 떠올려 보세요. 플랫폼 스레드는 차량 한 대가 통과할 때 톨게이트 직원 한 명을 완전히 점유합니다. 차가 카드를 찾는 동안(I/O 대기)에도 직원은 옆 차를 볼 수 없습니다. 가상 스레드는 다릅니다. 카드를 찾는 동안 직원은 즉시 옆...
Java ThreadLocal — 동작 원리부터 메모리 누수까지
Java의 멀티스레드 환경에서 스레드 간 공유 없이 각 스레드마다 독립적인 변수를 유지해야 할 때 ThreadLocal을 사용합니다. 이 글에서는 ThreadLocal의 내부 구조부터 메모리 누수 방지, 실무 활용 패턴까지 깊이 있게 다룹니다.
Java String
Java에서 String은 가장 많이 사용되는 클래스이면서, 동시에 가장 많은 오해가 있는 클래스입니다. 불변성(Immutability), String Pool, 성능 최적화, 그리고 Java 11~17에서 추가된 메서드까지 완전히 정리합니다.
Java Stream API 완전 분해: 내부 메커니즘부터 Gatherers까지
Java 8에서 등장한 Stream API는 단순히 for-loop를 대체하는 편의 문법이 아닙니다. 지연 평가(lazy evaluation), Spliterator 기반 분할, ForkJoin 병렬화, Collector 파이프라인이 맞물려 돌아가는 정교한 데이터 처리 엔진입니다....
Java Object 클래스
Java의 모든 클래스는 명시적으로 상속을 선언하지 않아도 java.lang.Object를 최상위 부모로 가집니다. Object 클래스가 제공하는 메서드들은 Java 객체 시스템의 근간을 이루며, 이를 올바르게 이해하고 오버라이딩하는 것은 Java 개발의 핵심입니다.
Java I/O 완전 정복 — 내부 메커니즘부터 NIO.2까지
Java I/O는 단순한 파일 읽기/쓰기가 아닙니다. OS 커널의 시스템 콜, 페이지 캐시, epoll, zero-copy 같은 저수준 메커니즘이 Java API 뒤에 숨어 있습니다. 이 글은 “왜 그렇게 설계했는가”를 중심으로 InputStream 바이트 계층부터 NIO.2 비동...
Java Enum
Java의 enum은 단순히 상수 집합을 표현하는 것을 넘어, 필드·메서드·추상 메서드를 가질 수 있는 완전한 클래스입니다. 상수 대신 Enum을 사용해야 하는 이유부터 EnumSet, EnumMap, 싱글톤 패턴까지 완전히 정리합니다.
JVM 아키텍처 완전 해부 — 클래스 로딩부터 JIT·JMM·다이렉트 메모리까지
한 줄 요약: JVM은 바이트코드를 받아 검증·링킹·초기화 후 메모리에 올리고, 인터프리터와 JIT 컴파일러로 실행하며, GC로 메모리를 자동 회수하는 플랫폼 독립 런타임이다.
JVM JIT 컴파일러 Cold Start부터 최적화까지
한 줄 요약: JIT(Just-In-Time) 컴파일러는 JVM이 바이트코드를 실행하면서 “자주 실행되는 코드”를 감지해 실시간으로 네이티브 기계어로 변환·최적화하는 엔진이며, 이것이 Java가 인터프리터 언어임에도 고성능을 낼 수 있는 핵심 이유입니다.
CompletableFuture 완전 분석 — 내부 구조부터 실전 패턴까지
전자상거래 주문 처리 서버가 있다. 상품 정보(300ms), 재고 확인(200ms), 가격 계산(150ms)을 순차 호출하면 650ms다. 세 호출을 병렬로 띄우면 300ms면 충분하다. 그런데 단순히 Thread를 3개 생성하는 것과 CompletableFuture를 사용하는 것...
SPRING
WebClient와 스레드 모델 딥다이브 — 동기/비동기/블로킹/논블로킹이 스레드에서 실제로 어떻게 동작하는가
비유로 먼저 이해하기: 음식점에 비유하면, 동기 블로킹은 주방에서 요리가 완성될 때까지 홀 직원이 그 자리에 서서 기다리는 것이다. 비동기 논블로킹은 주문을 넣고 다른 테이블 서빙을 하다가, 주방에서 벨이 울리면 그때 가져가는 것이다. 직원(스레드) 한 명이 처리할 수 있는 ...
Spring 핵심 어노테이션 총정리 — 동작원리부터 실무 함정까지
왜 어노테이션 동작원리를 알아야 하는가
DTO, Entity, DAO, VO, Repository 완전 정복 — 왜 구분하고, 어디서 변환하는가
한 줄 요약: Entity는 DB의 거울이고, DTO는 계층 간 택배 상자이며, VO는 값 그 자체가 정체성이고, DAO는 SQL 창고 관리인이며, Repository는 도메인이 말하는 컬렉션이다. 이 다섯 개념을 혼용하는 순간 코드는 조용히 무너지기 시작한다.
Spring 핵심 원리 심층 분석 — 컨테이너 내부 구조부터 빈 생명주기까지
한 줄 요약: Spring IoC 컨테이너는 BeanDefinition 메타데이터를 읽어 싱글톤 레지스트리를 구성하고, BeanPostProcessor 체인으로 AOP 프록시를 씌운 뒤, 완성된 객체를 주입한다. “프레임워크가 내 코드를 호출한다”는 제어 역전이 유지보수성·테...
Spring 핵심 원리 고급 — BeanPostProcessor 체인, BFPP, 이벤트, SpEL, 스케줄러 완전 정복
한 줄 요약: Spring 컨테이너는 단순한 빈 저장소가 아니다. BeanPostProcessor 체인이 @Autowired·AOP 프록시·@Async를 자동화하고, BeanFactoryPostProcessor가 설정을 주입하며, ApplicationEventPublisher...
Spring 트랜잭션 내부 동작 완전 분석
트랜잭션을 “그냥 @Transactional 붙이면 되는 것”으로 아는 개발자와, 프록시 체인부터 커넥션 풀 상호작용까지 이해하는 개발자의 차이는 장애 상황에서 극명하게 드러난다. 이 글은 Spring 트랜잭션의 내부 메커니즘을 끝까지 파헤친다.
Spring WebFlux — 리액티브 프로그래밍 완전 정복
Tomcat 스레드 200개가 모두 외부 API 응답을 기다리며 블로킹되어 있다. 새 요청은 큐에서 대기하다 타임아웃이 터진다. 서버를 두 배 늘려도 스레드 수가 두 배가 될 뿐, 근본 구조는 바뀌지 않는다. 이 상황의 진짜 원인은 “스레드 하나가 요청 하나를 끝까지 점유하는” 설...
Spring Security 완전 정복 — 아키텍처·OAuth2·JWT·취약점 방어
JWT 없는 요청이 /api/admin을 통과했다. 필터가 누락됐는지, 순서가 잘못됐는지, SecurityContext가 비어있는지 – Spring Security 아키텍처를 모르면 어디서 막혀야 하는지조차 알 수 없다. 내부 메커니즘을 모르고 어노테이션만 붙이다 보면 보안 구멍은...
Spring Resilience4j 완전 해부: Circuit Breaker 내부 구조부터 분산 Rate Limiting까지
마이크로서비스 환경에서 외부 서비스 호출은 반드시 실패한다. 문제는 “언제 실패하느냐”가 아니라 “실패가 얼마나 멀리 전파되느냐”이다. 하나의 느린 서비스가 연쇄적으로 전체 시스템을 마비시키는 Cascading Failure를 막으려면 호출 경계마다 방어막을 쳐야 한다. Resil...
Spring MVC 동작 원리 완전 분석 — DispatcherServlet부터 ArgumentResolver 내부까지
한 줄 요약: Spring MVC는 DispatcherServlet이 단일 진입점으로 모든 HTTP 요청을 받아 HandlerMapping → HandlerAdapter → ArgumentResolver → Controller → ReturnValueHandler → View...
Spring IoC & DI 완전 분해: 내부 메커니즘부터 면접 극한 질문까지
신입 때 new RateDiscountPolicy()를 서비스 클래스 내부에 직접 박아뒀다가, 기획 변경 한 번에 수십 개 파일을 열어야 했던 경험이 있을 것이다. IoC와 DI는 그 고통을 제거하기 위한 개념이 아니라, 객체 설계 철학의 전환이다. 이 글은 “어떻게 쓰는가”가 아...
Spring Interceptor 완전 정복 — 내부 메커니즘부터 실전 구현까지
한 줄 요약: Spring Interceptor는 DispatcherServlet이 HandlerMapping으로 컨트롤러를 찾은 직후, 실제 호출 직전에 끼어드는 컴포넌트다. Filter와 달리 Spring ApplicationContext 안에 존재하기 때문에 모든 Bea...
Spring DB 접근 기술 2 — JdbcTemplate, MyBatis, JPA
1. 비유 — 요리 도구의 진화
Spring DB 접근 기술 1 — JDBC 내부 동작부터 JdbcTemplate, 트랜잭션 매니저까지
한 줄 요약: Spring JDBC는 Driver→Connection→Statement→ResultSet이라는 JDBC 4단계 프로토콜을 JdbcTemplate 템플릿 메서드 패턴으로 감싸고, DataSourceTransactionManager와 ThreadLocal 동기화로...
Spring Cloud Gateway
Spring Cloud Gateway는 Spring 생태계의 API Gateway 솔루션이다. Netflix Zuul(블로킹)의 후계자로, Spring WebFlux(Reactor/Netty) 기반의 비동기 논블로킹 방식으로 동작한다. 라우팅, 필터링, 로드밸런싱, 인증, Rate...
Spring Cloud Eureka
마이크로서비스 환경에서 서비스들은 동적으로 생성·삭제·이동된다. IP와 포트를 하드코딩하면 배포할 때마다 설정을 바꿔야 한다. Spring Cloud Eureka는 이 문제를 해결하는 Service Discovery 솔루션이다. 서비스가 스스로 자신의 위치를 등록하고, 호출자는 이...
Spring Cloud Config
100개의 마이크로서비스에 DB 비밀번호를 바꿔야 한다면? 각 서비스마다 설정 파일을 수정하고 재배포하면 수십 분이 걸린다. Spring Cloud Config는 모든 서비스의 설정을 한 곳에서 관리하고, 재배포 없이 런타임에 반영하는 중앙 집중 설정 관리 솔루션이다.
Spring Boot 자동 구성 원리와 활용 — 내부 메커니즘 완전 해부
한 줄 요약: Spring Boot 자동 구성은 SpringApplication.run() 한 줄에서 출발해 classpath 분석, @Conditional 평가, 조건부 빈 등록까지 수백 개의 자동 설정 후보를 걸러내는 정교한 파이프라인이다. 내부 메커니즘을 모르면 디버깅이...
Spring Batch 핵심 개념 — Job, Step, Chunk 모델부터 재시작까지
한 줄 요약
Spring Batch 파티셔닝과 병렬 처리 — 성능 튜닝부터 운영까지
한 줄 요약
Spring Batch Chunk 기반 처리 심화 — 트랜잭션, Skip/Retry, 대용량 전략
한 줄 요약
Spring AOP 동작 원리 — 프록시 내부부터 극한 시나리오까지
AOP를 “로깅이나 트랜잭션에 쓰는 것”으로만 알고 있다면 시니어 면접에서 멈춘다. 면접관이 진짜 묻는 것은 “프록시가 어떻게 만들어지는가”, “왜 self-invocation이 뚫리는가”, “CGLIB이 JDK Proxy보다 왜 느린가”다. 이 글은 AOP의 표면이 아니라 내부 ...
Spring @Async 완전 분석 — 내부 구조부터 운영 장애까지
Spring @Async는 메서드 한 줄로 비동기를 선언할 수 있어 단순해 보인다. 하지만 내부 구조를 모르면 예외가 조용히 사라지고, 로그에서 TraceId가 증발하며, 트랜잭션 데이터가 보이지 않는 운영 장애로 이어진다. 이 글은 AsyncAnnotationBeanPostPro...
Spring 6 이해와 원리
1. 비유 — 레고 블록과 조립 설명서
MDC(Mapped Diagnostic Context) — 분산 환경 로그 추적
새벽 2시에 운영 장애가 났다. 로그를 보니 에러와 정상 로그가 뒤섞여 어느 요청에서 터진 건지 찾을 수가 없다. MDC를 몰랐다면 이 상황에서 로그 전체를 시간순으로 읽어내려가야 한다.
Java/Spring REST API 클라이언트 라이브러리 완전 비교
비유로 먼저 이해하기: HTTP 클라이언트 라이브러리를 택배사에 비유하면, RestTemplate은 직접 전화해서 배차하는 방식, WebClient는 배차 앱에 요청 올려두고 다른 일 하는 방식, OpenFeign/Retrofit은 계약서(인터페이스) 한 장 쓰면 나머지는 자...
DB
MySQL vs PostgreSQL — 2026년 기준 완전 비교 가이드
새 프로젝트의 데이터베이스를 선택해야 한다. MySQL vs PostgreSQL. 두 데이터베이스 모두 무료이고, 안정적이며, 대규모 프로덕션 환경에서 검증되었다. 그런데 왜 고민이 되는가? 내부 구현 방식이 근본적으로 다르고, 그 차이가 특정 워크로드에서 성능과 기능의 큰 격차를...
MySQL 복제와 고가용성 — 바이너리 로그부터 Group Replication, InnoDB Cluster까지
데이터베이스 서버가 한 대뿐이라면, 그 서버가 멈추는 순간 서비스 전체가 멈춘다. MySQL 복제는 이 단일 장애 지점(SPOF)을 없애기 위한 핵심 메커니즘이다. 단순히 백업용 서버를 한 대 더 두는 개념에서 시작해, 자동 페일오버와 멀티 마스터 합의까지 발전한 과정을 처음부터 ...
MySQL 실행 계획과 쿼리 튜닝 — EXPLAIN 한 줄로 10배 느린 쿼리를 찾아내는 법
쿼리가 느리다는 신고가 들어왔다. 로그를 보면 SELECT 하나가 3초를 넘기고 있다. 어디서 시간이 소비되는지 모른 채 인덱스를 마구 추가하거나, 쿼리를 감으로 바꾸는 것은 도박이다. MySQL의 EXPLAIN은 옵티마이저가 쿼리를 어떻게 실행할지 보여주는 설계도다. 이 설계도를...
데이터베이스 마이그레이션 전략 — 무중단으로 스키마를 변경하고 DB를 교체하는 법
서비스가 운영 중인 데이터베이스의 스키마를 바꾸는 일은 달리는 기차 위에서 바퀴를 교체하는 것과 같다. 기차를 멈추면(서비스 중단) 간단하지만, 대부분의 서비스는 그 선택지가 없다. 무중단으로 스키마를 변경하는 기법, DB 자체를 교체하는 전략, 그리고 변경 이력을 코드로 관리하는...
MySQL Deadlock 완전 분석 — 왜 발생하고, 어떻게 잡는가
데드락 발생 원리부터 InnoDB 내부 메커니즘, 탐지/예방 전략, 실전 트러블슈팅까지
NoSQL vs RDB — 왜 그 DB를 선택해야 하는가
CAP 정리부터 워크로드 분석, 데이터 모델링, 확장 전략까지 — 시니어 개발자의 DB 선택 프레임워크
트랜잭션 격리 수준 완전 정복 — MVCC 내부 구조부터 Spring 실전까지
계좌 이체 도중 잔액을 조회하면 어떤 값이 보여야 하는가? 격리 수준이 낮으면 존재하지 않는 돈을 보거나, 방금 있던 돈이 사라지거나, 없던 행이 유령처럼 나타난다. 이 글은 ACID의 내부 보장 메커니즘부터 InnoDB MVCC의 Undo Log 체인, Read View 가시성 ...
데이터베이스 파티셔닝
비유로 시작하기
정규화와 반정규화
비유로 시작하기
데이터베이스 종류별 비교 분석 (MySQL vs PostgreSQL vs Oracle vs MariaDB vs SQL Server)
비유로 먼저 이해하기: 데이터베이스를 식당에 비유하면, MySQL은 빠르고 친숙한 패스트푸드점, PostgreSQL은 다양한 메뉴와 재료를 갖춘 파인다이닝, Oracle은 규모와 신뢰성을 갖춘 대형 호텔 레스토랑, MariaDB는 패스트푸드점에서 독립한 동생 가게, SQL S...
데이터베이스 인덱스 완전 분석 (MySQL InnoDB / Java Spring 기준)
회원 테이블 1,000만 건에서 이메일 하나를 조회하는 데 5초가 걸렸다. 인덱스 하나를 추가했더니 3ms로 줄었다. 왜 이런 일이 벌어지는지, 단순히 “인덱스를 걸면 빠르다”는 수준을 넘어 B+Tree 내부 구조부터 InnoDB 클러스터드 인덱스 설계, JPA 환경에서의 실무 전...
데이터베이스 샤딩 완전 분석
단일 MySQL 서버가 쓰기 TPS 한계에 부딪혔다. 읽기는 레플리카로 분산했지만 INSERT/UPDATE는 여전히 Primary 한 대가 감당한다. 수직 확장(더 좋은 서버)은 이미 96코어 / 384GB RAM 머신이라 더 올라갈 곳이 없다. 선택지가 샤딩밖에 남지 않은 순간,...
MySQL 옵티마이저 내부 동작 완전 분석
인덱스를 분명히 걸었는데 EXPLAIN을 보니 Full Table Scan이다. 옵티마이저가 인덱스보다 풀스캔이 더 빠르다고 판단한 것이다. 왜 그런 선택을 했는지 이해하지 못하면 힌트를 줄 수도, 통계를 갱신할 수도 없다.
DB 커넥션 풀 완전 해부 — HikariCP 내부 구조부터 면접 극한 시나리오까지
“커넥션 풀 쓰면 빠르죠.” — 이 한 줄은 면접에서 0점이다. 왜 커넥션 하나를 여는 데 10ms가 걸리는지, HikariCP가 내부에서 어떤 자료구조로 락 없이 커넥션을 건네는지, 풀 사이즈를 왜 스레드 수로 맞추면 안 되는지를 설명할 수 있어야 한다. 이 글은 소스 코드 수준...
DB 모델링
비유로 시작하기
DB 락 완전 정복: InnoDB 내부 메커니즘부터 분산 락까지
재고 1개짜리 상품에 10만 명이 동시에 주문을 쏟아냈다. 락 설계가 잘못되면 재고는 음수가 되고, 너무 강하면 시스템은 멈춰버린다. 락은 정합성과 성능 사이의 균형이다. 이 글에서는 InnoDB가 내부적으로 락을 어떻게 구현하는지부터, 데드락 탐지 알고리즘, 분산 락까지 시니어 ...
DB 내부 동작 원리 — InnoDB 심층 해부
프로덕션 장애 상황을 상상해 보자. 트래픽이 평소와 같은데 특정 쿼리의 p99 레이턴시가 갑자기 500ms에서 5초로 튀었다. 코드는 배포된 것이 없다. DBA를 불러 SHOW ENGINE INNODB STATUS를 보니 Buffer Pool 히트율이 87%로 떨어져 있고, His...
FRONTEND
프론트엔드 테스트 전략
자동차 출고 검사처럼
프론트엔드 아키텍처 설계 패턴
도시를 처음부터 다시 지을 수는 없다
프로토타입과 상속 메커니즘
가족 레시피 전수
클로저 실전 활용 가이드
배달 음식의 비밀 봉투
비동기 처리 패턴 완전 정리
음식 배달 앱의 진화
브라우저 렌더링 과정 완전 정복
레스토랑 주방에서 음식이 나오기까지
var, let, const 차이와 호이스팅
아파트 입주 이야기
React 성능 최적화 실전
막히는 도로를 뚫는 방법
React 핵심 원리와 렌더링
“전체를 다시 그리지 않는다”는 아이디어
React 상태 관리 전략 총정리
“이 상태를 어디에 두어야 할까”라는 질문
React Hooks
클래스 없이 상태와 생명주기를 다루다
Next.js 핵심 개념과 SSR/SSG
음식점 준비 방식으로 이해하기
NestJS 핵심 개념과 아키텍처
Express로 충분하지 않은 이유
JavaScript 핵심
한 줄 요약: JavaScript의 핵심은 싱글 스레드이면서도 비동기 처리가 가능한 이벤트 루프 메커니즘과, 렉시컬 스코프를 기억하는 클로저, 그리고 프로토타입 기반 상속입니다.
JavaScript 이벤트 루프 완전 정복
식당 주방에서 일어나는 일
JavaScript this 바인딩 모든 경우의 수
맥락에 따라 달라지는 “나”
INTERVIEW
시스템 디자인 면접 완전 가이드 — 답변 프레임워크부터 실전 문제까지
시스템 디자인 면접은 정답이 없습니다. 면접관은 “당신이 어떻게 생각하는가” 를 봅니다. 요구사항을 명확히 하고, 트레이드오프를 인지하며, 단계적으로 확장하는 사고 과정을 평가합니다. 이 글은 검증된 답변 프레임워크와 실전 문제 5개를 통해 시스템 디자인 면접을 완벽히 준비합니다.
Spring 면접 — WebFlux 심화 질문 (Q46~Q50)
6. WebFlux / 기타 심화 질문 (Q46 ~ Q50)
Spring 면접 — Spring Security 핵심 질문 (Q39~Q45)
5. Spring Security 핵심 질문 (Q39 ~ Q45)
Spring 면접 — JPA 핵심 질문 (Q28~Q38)
4. JPA 핵심 질문 (Q28 ~ Q38)
Spring 면접 — Transaction 핵심 질문 (Q19~Q27)
3. Transaction 핵심 질문 (Q19 ~ Q27)
Spring 면접 — AOP 핵심 질문 (Q11~Q18)
2. AOP 핵심 질문 (Q11 ~ Q18)
Spring 면접 — DI/IoC 핵심 질문 (Q1~Q10)
1. DI / IoC 핵심 질문 (Q1 ~ Q10)
백엔드 모의면접 — 현직 시니어가 직접 봐주는 1:1 면접 코칭
솔직하게 말할게요
Java 면접 — 예외처리 / Generics / 기타 (Q41~Q50)
5. 예외 처리 / Generics / 기타 (Q41 ~ Q50)
Java 면접 — Stream / Functional (Q34~Q40)
4. Stream / Functional (Q34 ~ Q40)
Java 면접 — Collection 내부 구조 (Q23~Q33)
3. Collection 내부 구조 (Q23 ~ Q33)
Java 면접 — 동시성 핵심 질문 (Q11~Q22)
2. 동시성 (Q11 ~ Q22)
Java 면접 — JVM 메모리 구조 (Q1~Q10)
1. JVM 메모리 구조 (Q1 ~ Q10)
Spring 면접 질문 50선 — 시니어 면접에서 자주 나오는 핵심 질문과 모범 답변
Spring 면접은 단순 암기로는 절대 통과할 수 없습니다. 면접관은 “Bean이 뭔가요?”를 물어볼 때 실은 의존성 관리 철학을 이해하고 있는가를 봅니다. 이 글은 시니어 면접에서 자주 나오는 질문 50개를 카테고리별로 정리하고, 면접관 관점에서 “왜 이 질문을 하는가”까지 분석...
Java 면접 질문 50선 — JVM부터 동시성까지 완전 정복
Java 면접에서 “HashMap의 시간복잡도가 뭔가요?” 같은 표면적 질문은 웜업일 뿐입니다. 진짜 합격을 가르는 건 “왜 O(1)이 아닐 수 있는가?”, “해시 충돌이 심해지면 내부에서 어떻게 변하는가?” 같은 꼬리질문입니다. 이 글은 Java 면접 핵심 50문제를 파트별로 나...
HTTP
HTTP 캐시 제어 헤더 완전 정리 - 프록시 캐시와 캐시 무효화
한 줄 요약: Cache-Control 지시어로 캐시 유효기간과 공개 범위를 제어하고, 프록시 캐시를 활용해 글로벌 응답 속도를 높이며, must-revalidate로 만료된 캐시의 오사용을 방지한다.
HTTP ETag와 If-None-Match - 정밀한 캐시 재검증
한 줄 요약: ETag는 리소스의 고유한 버전 식별자로, If-None-Match 조건부 요청과 함께 사용하면 Last-Modified의 한계(초 단위 정밀도, 날짜 기반 비교)를 극복하고 정확한 캐시 재검증이 가능하다.
HTTP 검증 헤더와 조건부 요청 - Last-Modified 상세
한 줄 요약: 검증 헤더(Last-Modified)와 조건부 요청(If-Modified-Since)을 활용하면 캐시가 만료된 후에도 서버 데이터가 변경되지 않았다면 304 응답으로 바디 전송 없이 캐시를 재사용할 수 있다.
HTTP 캐시 - 기본 동작과 Cache-Control
한 줄 요약: HTTP 캐시는 한 번 받은 응답을 저장해 두었다가 재사용함으로써 네트워크 비용을 줄이고 응답 속도를 높이는 메커니즘이다.
HTTP 인증과 쿠키 심화 - 세션, JWT, 보안 속성
한 줄 요약: HTTP 인증은 Authorization 헤더로 자격 증명을 전달하고, 쿠키의 HttpOnly·Secure·SameSite 속성으로 세션 탈취 공격을 방어한다.
HTTP 헤더 - 일반 정보, 특별 헤더, 인증, 쿠키
한 줄 요약: HTTP 일반 헤더는 요청/응답의 부가 정보를 담고, 쿠키는 Stateless HTTP에서 상태를 유지하기 위한 핵심 메커니즘이다.
HTTP 헤더 - 표현, 콘텐츠 협상, 전송 방식
한 줄 요약: HTTP 헤더는 전송에 필요한 모든 부가 정보를 담는다. 표현 헤더는 바디의 형식을 설명하고, 협상 헤더는 클라이언트가 원하는 형식을 서버에 알린다.
HTTP 상태 코드 완전 정리
한 줄 요약: HTTP 상태 코드는 서버가 클라이언트의 요청을 어떻게 처리했는지 알려주는 3자리 숫자로, 1xx~5xx 5개 대역으로 분류된다.
HTTP 메서드 - API URI 설계와 GET/POST/PUT/PATCH/DELETE
한 줄 요약: 좋은 API URI 설계는 리소스(명사)를 식별하는 데 집중하고, 행위(조회/등록/수정/삭제)는 HTTP 메서드로 표현한다.
HTTP 기본 - 클라이언트 서버 구조, Stateless, 비연결성, 메시지
한 줄 요약: HTTP는 클라이언트-서버 구조에서 동작하는 무상태(Stateless), 비연결성 프로토콜로, 거의 모든 형태의 데이터를 전송할 수 있는 단순하고 확장 가능한 프로토콜이다.
URI와 웹브라우저 요청 흐름
한 줄 요약: URI는 인터넷 자원을 식별하는 가장 포괄적인 개념이며, URL은 그 하위 개념으로 자원의 위치를 나타낸다. 브라우저가 URL을 입력받아 서버에 응답을 받기까지의 전체 흐름을 이해하는 것이 중요하다.
인터넷 네트워크 [인터넷 통신, IP, TCP, UDP, PORT, DNS]
한 줄 요약: 인터넷에서 데이터가 목적지까지 안전하게 전달되려면 IP → TCP/UDP → PORT → DNS로 이어지는 계층적 프로토콜 구조가 필요하다.
KAFKA
Kafka vs RabbitMQ — 메시지 브로커 선택 기준 완전 정리
결제 시스템에서 이벤트를 발행한다. 재고 서비스, 알림 서비스, 정산 서비스가 이 이벤트를 구독한다. 메시지 브로커가 필요하다. Kafka와 RabbitMQ 중 무엇을 선택할 것인가? 이 질문에 “트래픽이 많으면 Kafka”라고 단순하게 답하는 것은 위험하다. 두 시스템은 근본적으...
Kafka 핵심 개념 심층 분석
서비스가 성장하면서 주문, 결제, 배달, 통계, 알림 시스템이 서로 직접 API를 호출한다. 하나가 느려지면 전체가 느려지고, 하나가 죽으면 연쇄 장애가 난다. Kafka는 이 결합을 끊는다. 그런데 “어떻게” 끊는지, 그리고 “왜” 그 방법을 선택했는지를 아는 것이 시니어와 주니...
Kafka 장애 시나리오 — 데이터 유실과 중복 처리
들어가며
Kafka 실전 패턴 — 현실에서 마주치는 모든 시나리오와 해법
시니어 개발자가 처음 Kafka를 쓸 때는 “토픽에 넣고, 토픽에서 꺼낸다”로 시작합니다. 그런데 6개월이 지나면 질문이 달라집니다. “주문 완료 시 네 개 토픽에 동시에 넣어야 하는데, 하나가 실패하면 어떻게 되지?” “결제가 두 번 처리됐다. 왜지?” “배포할 때마다 수초씩 멈...
Kafka 복제 메커니즘 심층 분석
브로커 한 대가 새벽 3시에 갑자기 죽었다. 그 브로커가 리더를 맡던 파티션의 메시지는 어떻게 되는가? Kafka는 처음부터 이 질문에 답하기 위해 설계됐다. 단순히 “복제한다”가 아니라, 어떤 복제본이 신뢰할 수 있는지, 리더가 바뀔 때 로그 불일치를 어떻게 해소하는지, 그 모든...
Kafka 내부 동작 원리 — 로그 구조부터 Zero-Copy, 리더 선출까지
초당 100만 건의 이벤트를 처리하는 Kafka가 단순한 메시지 큐와 근본적으로 다른 이유는 하나다. OS와 하드웨어의 특성을 정확히 이해하고 그것을 최대한 활용하도록 설계됐기 때문이다. JVM 힙 대신 Page Cache를 쓰고, 소켓 복사 대신 sendfile()을 쓰고, 랜덤...
Kafka Producer 내부 동작 완전 분석 — 파이프라인부터 트랜잭션까지
kafkaTemplate.send("orders", event) 한 줄이면 메시지가 전송된다고 생각하기 쉽다. 하지만 이 한 줄 뒤에는 인터셉터 → 직렬화 → 파티셔닝 → RecordAccumulator 배치 누적 → Sender 스레드 → NetworkClient → 브로커 IS...
Kafka Outbox 패턴과 CDC — 분산 시스템 데이터 일관성의 완전 해부
주문이 DB에 저장됐는데 Kafka 발행이 실패했다. 결제 서비스는 주문을 모른다. 반대로 Kafka는 이벤트를 받았는데 DB가 롤백됐다. 결제 서비스는 존재하지 않는 주문을 처리한다. 이 두 가지 공포 시나리오를 분산 트랜잭션 없이 해결하는 것이 Transactional Outb...
Kafka Consumer 완전 해부: 프로토콜부터 운영까지
주문 이벤트 처리 속도가 발행 속도를 따라가지 못한다. 컨슈머 인스턴스를 한 대 더 띄우면 해결될까? 파티션이 3개인데 컨슈머가 이미 3개라면 4번째 컨슈머는 아무것도 하지 않고 대기만 한다. 더 심각한 문제는, 리밸런싱이 30초마다 일어나고 있다면 컨슈머를 아무리 늘려도 처리량이...
Kafka Broker 내부 구조 완전 해부 — 네트워크부터 Purgatory까지
초당 수백만 메시지를 처리하는 Kafka 브로커는 어떤 내부 구조로 동작하는가? 단순히 “빠르다”는 사실이 아니라, SocketServer의 Acceptor/Processor 분리부터 Purgatory의 TimingWheel, Controller의 상태 머신까지 — 면접관이 원하는...
REDIS
Redis vs Memcached — 어떤 상황에서 무엇을 선택해야 하는가
캐시 서버를 도입해야 한다. 검색하면 두 이름이 반드시 나온다. Redis와 Memcached. “그냥 Redis 쓰면 되지 않나요?”라고 묻는 신입 개발자에게 “맞아요, 대부분은요”라고 답하는 것은 절반만 옳다. 이 포스트는 두 시스템의 내부 원리를 해부하고, 어떤 요구사항에서 ...
Redis 트랜잭션 완전 정복 — MULTI/EXEC 내부 구조, WATCH CAS 원리, Lua 비교까지
한 줄 요약: Redis 트랜잭션(MULTI/EXEC)은 클라이언트 출력 버퍼에 명령을 큐잉하고 EXEC 시 원자적으로 실행하지만 롤백이 없다. 진짜 안전한 동시성 제어는 WATCH(CAS)와 Lua Script를 목적에 맞게 조합하는 것이다.
Redis Streams 완전 정복 — Kafka 없이 이벤트 스트리밍을 구현하는 법
한 줄 요약: Redis Streams는 “메시지를 보내고 받는 우체통”인데, 받는 사람이 여러 명이어도 편지가 사라지지 않고, 누가 읽었고 누가 아직 안 읽었는지까지 추적해주는 Redis의 자료구조입니다.
Redis 운영 모드 완전 정복 — Standalone vs Sentinel vs Cluster, 언제 무엇을 쓰는가
한 줄 요약: Redis는 단일 프로세스(Standalone)에서 시작해 자동 장애복구(Sentinel), 수평 확장(Cluster)으로 진화하며, 각 모드는 해결하는 문제가 근본적으로 다르다 — 무엇을 선택하느냐는 곧 어떤 장애를 감수하느냐를 결정한다.
Redis 자료구조 내부 구조 완전 해부 — 왜 String만 쓰면 안 되는가
실시간 랭킹을 구현해야 한다. MySQL로 매 요청마다 ORDER BY score DESC를 돌리면 수천 명이 동시 접속할 때 DB가 버티지 못한다. Redis Sorted Set 하나로 수백만 명의 점수를 실시간으로 정렬해 1ms 안에 응답할 수 있다. 그런데 이것이 왜 가능한가...
Redis 복제 — 내부 메커니즘부터 극한 장애까지 완전 해부
새벽 2시, Redis 마스터 서버의 디스크가 고장났다. 복제 없이 단일 Redis만 운영 중이었다면? 캐시 데이터는 전부 날아간다. 서비스가 재개되어도 모든 캐시가 비어있으니 DB에 쿼리가 폭발적으로 몰린다. DB도 죽는다. 복제(Replication)는 이 연쇄 장애를 막는 첫...
Redis 분산 락 완전 분석 — SETNX 원자성부터 Redlock 논쟁까지
쿠팡 블랙프라이데이 자정, 한정판 운동화 1켤레에 5만 명이 동시에 달려든다. 서버 20대가 저마다 “재고 1개 남음”을 읽고 결제를 진행하면, 재고는 1개인데 20명에게 팔리는 참사가 벌어진다. synchronized는 JVM 안에서만 유효하다. 20대 서버가 공유하는 자원을 보...
Redis TTL 완전 분석 — 내부 구현부터 클러스터 동작까지
로그인 세션이 24시간 뒤 자동 만료되지 않는다면 어떻게 될까? 사용자가 로그아웃을 잊으면 세션은 영원히 메모리에 남는다. 수백만 명의 서비스라면 Redis 메모리가 조용히, 그러나 확실히 고갈된다. 어느 날 새벽 OOM으로 Redis가 죽고서야 원인을 찾는다. TTL은 EX 36...
Redis Pub/Sub 내부 동작 완전 분석 — 왜 메시지가 사라지는가
채팅 서비스를 서버 3대로 운영한다. 사용자 A는 서버 1에 WebSocket으로 연결되어 있고, 사용자 B는 서버 2에 연결되어 있다. A가 B에게 메시지를 보낸다. 서버 1은 서버 2에 연결된 B에게 직접 메시지를 전달할 수 없다. 서버들 사이의 메시지를 중계할 무언가가 필요하...
Redis Lua 스크립트 — 싱글 스레드 이벤트 루프가 원자성을 보장하는 방법
재고 감소 로직을 떠올려보자. GET으로 재고를 읽고, 0보다 크면 DECR로 줄인다. 코드로만 보면 아무 문제가 없다. 그런데 GET과 DECR 사이 0.05밀리초의 틈에 다른 스레드가 끼어들면 재고가 -1이 된다. 초당 5만 건이 몰리는 플래시 세일에서는 이 틈이 수백 번 열린...
DEVTOOLS
터미널 & 생산성 도구 — 개발 속도를 2배로 올리는 환경 구축
한 줄 요약
Redis 관리 도구 완벽 가이드 — RedisInsight, ARDM, redis-cli
한 줄 요약: Redis는 빠르지만 눈에 보이지 않습니다. RedisInsight는 종합 병원의 MRI, ARDM은 동네 의원의 초음파, redis-cli는 청진기 — 상황에 맞는 도구를 골라야 Redis의 심장 박동을 제대로 읽을 수 있습니다.
Kafka 관리 도구 완벽 가이드 — Kafka UI, AKHQ, Conduktor
Kafka 클러스터를 운영하면 토픽 수백 개, 컨슈머 그룹 수십 개, 파티션 수천 개가 눈앞에 펼쳐진다. CLI만으로 관리하면 실수 한 번에 프로덕션 토픽이 날아간다. 이 글에서는 Kafka 전용 관리/모니터링 도구 5가지를 비교하고, 각 도구의 심화 기능과 실무 극한 시나리오까지...
JVM 프로파일링 도구 완벽 가이드 — VisualVM, Arthas, async-profiler
JVM 애플리케이션이 느려졌을 때 “어디서 시간을 잡아먹는지”, “메모리를 누가 쓰는지”, “스레드가 왜 멈췄는지”를 정확히 짚어내는 기술이 프로파일링이다. 감으로 튜닝하면 90%는 엉뚱한 곳을 고치게 된다 — 도구가 보여주는 숫자만이 진실이다.
IntelliJ IDEA — BE 개발자를 위한 완벽 가이드
한 줄 요약: IntelliJ IDEA는 코드를 이해하는 IDE다. 단순 텍스트 편집기가 아니라 AST 기반 분석 엔진 위에 디버깅·프로파일링·리팩토링·DB 연동까지 올린 백엔드 개발자의 종합 작전실이다.
Docker Desktop vs Podman — 컨테이너 런타임 완벽 비교
한 줄 요약
DB 클라이언트 도구 완벽 비교 — DataGrip vs DBeaver vs MySQL Workbench
비유로 먼저 이해하기: DB 클라이언트 도구를 자동차에 비유하면, DataGrip은 모든 옵션이 탑재된 독일 프리미엄 세단, DBeaver는 옵션 자유롭게 고를 수 있는 가성비 SUV, MySQL Workbench는 특정 브랜드 전용 정비 도구라고 할 수 있다. 셋 다 목적지...
Gradle vs Maven — 빌드 도구 심층 비교와 최적화
자바 프로젝트를 시작할 때 가장 먼저 만나는 선택지가 빌드 도구다. Maven은 2004년부터 자바 생태계의 표준이었고, Gradle은 2012년 이후 빠르게 점유율을 높이며 지금은 Android 공식 빌드 시스템이자 Spring Initializr의 기본값이 되었다. 이 포스트는...
API 테스트 도구 완벽 가이드 — Postman, Insomnia, curl, httpie
API 테스트 도구는 백엔드 개발의 청진기다. Postman으로 GUI 기반 탐색, curl/httpie로 CLI 자동화, IntelliJ HTTP Client로 코드 옆에서 바로 검증까지 — 5가지 도구의 심화 사용법과 CI/CD 파이프라인 연동, 인증 처리, 계약 테스트까지 한...
AI
벡터 DB와 임베딩 — 텍스트를 숫자로 바꾸면 검색이 왜 똑똑해지는가
“고양이 사진 보여줘”를 검색하면 파일명에 “고양이”가 없는 사진도 찾아주는 검색엔진이 있다. 반면 기존 키워드 검색은 “고양이”라는 단어가 정확히 일치해야만 결과를 내놓는다. 이 차이가 임베딩과 벡터 DB에서 시작된다.
MLOps와 모델 서빙 — 학습한 모델을 프로덕션에서 안전하게 운영하는 법
데이터 과학자가 노트북에서 95% 정확도를 달성한 모델을 만들었다. 그런데 이것을 초당 1만 건의 요청을 처리하는 프로덕션 서비스에 올리면 어떻게 될까? 십중팔구 레이턴시 폭발, 메모리 부족, 그리고 3개월 후 모델 성능 저하로 이어진다. 학습(training)과 서빙(servin...
AI 에이전트 아키텍처 — ReAct, Tool Use, Planning으로 자율 행동하는 AI를 만드는 법
LLM에게 “오늘 날씨 알려줘”라고 물으면 그냥 대답한다. 그런데 “내 캘린더에서 오늘 일정 꺼내서, 날씨 API 조회하고, 적절한 옷차림까지 추천해”라고 하면? 단순한 텍스트 생성이 아닌 계획 수립 → 도구 실행 → 결과 반영의 루프가 필요하다. 이 루프를 자율적으로 수행하는 시...
프롬프트 엔지니어링 — AI에게 원하는 답을 정확히 얻는 기술
같은 GPT-4o에게 같은 질문을 해도 프롬프트에 따라 결과가 완전히 달라진다. “버그 고쳐줘”와 “당신은 시니어 Java 개발자입니다. 다음 NullPointerException의 근본 원인을 분석하고 방어 코드와 함께 수정해줘”는 같은 모델에서 천지 차이의 결과를 만든다. 프롬...
RAG 아키텍처 — AI가 우리 회사 데이터로 답변하게 만드는 법
ChatGPT에게 “우리 회사 API 문서를 설명해줘”라고 물으면 모른다고 한다. 학습 데이터에 없기 때문이다. RAG(Retrieval-Augmented Generation)는 이 문제를 해결하는 현재 가장 실용적인 방법이다. 회사 내부 문서, 코드베이스, 고객 FAQ를 AI에게...
LLM 애플리케이션 아키텍처 — ChatGPT 같은 서비스를 직접 만든다면
ChatGPT 같은 서비스를 직접 만든다면 무엇이 필요할까. LLM API를 호출하는 것은 단 5줄이지만, 실제 프로덕션 서비스는 전혀 다른 이야기다. 토큰 비용 폭발, 프롬프트 인젝션 공격, 10초가 넘는 응답 지연, 할루시네이션으로 인한 잘못된 정보 제공. 이 모든 문제를 해결...
AI 개발 도구
AI 생태계는 2023년 이후 폭발적으로 성장했다. 개발자 워크플로우에 통합되는 코딩 어시스턴트부터 범용 챗봇, 이미지 생성, 인프라 레이어까지 각 영역별 주요 도구를 정리한다.
AI-Driven Development와 하네스 엔지니어링
AI가 코드를 생성하는 시대가 되면서 개발자의 역할이 바뀌고 있다. AI를 단순히 사용하는 것을 넘어, AI가 올바르게 작동하도록 환경과 제약을 설계하는 하네스 엔지니어링(Harness Engineering)이 새로운 핵심 역량으로 부상했다.
ARCHITECTURE
gRPC vs REST — 마이크로서비스 통신에서 어떤 것을 선택할까
마이크로서비스 아키텍처를 설계한다. 서비스 간 통신 방식을 결정해야 한다. REST API를 쓰면 모두가 친숙하고 디버깅이 쉽다. gRPC를 쓰면 성능이 좋고 타입 안전성이 보장된다. 이 선택은 향후 몇 년간 시스템의 성능, 유지보수성, 팀 생산성에 영향을 준다. 이 포스트는 두 ...
아키텍처 패턴 완전 비교 — Layered·Clean·Onion·Hexagonal과 Spring 구현
실생활 비유: 건물 설계와 자동차 엔진
사이드카 패턴 MSA 핵심 인프라 패턴
한 줄 요약
이벤트 기반 아키텍처 (EDA)
한 줄 요약: 이벤트 기반 아키텍처(EDA)는 서비스들이 이벤트를 통해 간접 소통하여 결합도를 낮추고, 장애 전파를 차단하며, 시스템 확장성을 극대화하는 아키텍처 패턴이다.
분산 트랜잭션 완전 정복 — CAP, 2PC, Saga, TCC, Outbox, 분산 락
실생활 비유: 해외 송금과 공중 증발하는 돈
MSA 심층 가이드 — 내부 메커니즘과 실전 설계 원칙
실생활 비유: 백화점 vs 전문점 거리
DDD 완전 정복 — 전략·전술 패턴부터 헥사고날 아키텍처까지
한 줄 요약: DDD는 “코드가 비즈니스를 번역하는 것”이 아니라 “코드 자체가 비즈니스 언어로 말하는 것”을 목표로 한다. 헥사고날 아키텍처는 그 도메인이 기술에 종속되지 않도록 보호하는 구조적 장치다.
KOTLIN
Kotlin 테스트 전략 — Kotest와 MockK로 JUnit을 넘어서는 법
Java 개발자가 Kotlin으로 넘어올 때 마지막까지 Java 방식을 고집하는 영역이 있다. 바로 테스트다. JUnit 5와 Mockito는 익숙하고 문서도 많다. 그런데 막상 Kotlin 코드를 Mockito로 모킹하려 하면 final class 문제가 튀어나오고, 코루틴 테스...
Kotlin 스코프 함수와 위임 패턴 — let, run, apply, also, with 그리고 by lazy의 내부 동작
Kotlin 코드베이스를 처음 읽을 때 가장 낯선 것이 두 가지다. 하나는 ?.let { }, apply { }, also { } 같은 스코프 함수들이 뒤엉켜 있는 체이닝 코드고, 다른 하나는 val token: String by lazy { ... }처럼 by 키워드로 프로퍼티를...
Kotlin Flow 완전 정복 — 코루틴 기반 리액티브 스트림의 내부 동작과 실전 패턴
리액티브 프로그래밍의 핵심은 “값이 언제 올지 모를 때 그 흐름을 다루는 방식”이다. RxJava는 Observable로, Reactor는 Flux/Mono로 이를 구현했다. Kotlin은 코루틴 위에 Flow라는 더 단순하고 안전한 추상을 만들었다. 이 글은 Flow의 원리부터 ...
Kotlin 컬렉션과 시퀀스 — 함수형 프로그래밍으로 Java Stream을 대체하는 법
Java에서 컬렉션 처리 코드를 작성하면 for 루프, 임시 변수, null 체크가 뒤엉켜 20줄이 넘어가는 경우가 흔하다. Kotlin은 그 코드를 3줄로 줄이고, 타입 안전성과 null 안전성을 유지하면서 Java Stream보다 직관적인 API를 제공한다. 컬렉션 API를 이...
Kotlin 코루틴 — 스레드 1000개 없이 동시 요청 10만 개를 처리하는 방법
서버에 동시 요청이 10만 개 들어온다. 전통적인 스레드 모델로는 스레드 10만 개가 필요하고, 각 스레드가 1MB를 쓴다면 메모리만 100GB다. 실제 서버가 가진 CPU 코어는 8개뿐인데. 코루틴은 스레드 수십 개로 이 10만 개의 요청을 처리한다. 핵심은 “대기 중인 작업이 ...
Kotlin + Spring Boot — Java 개발자를 위한 실전 전환 가이드
Java로 Spring Boot를 쓰던 개발자가 Kotlin으로 전환할 때 가장 먼저 드는 생각은 “과연 다를 게 있나?” 이다. 결론부터 말하면, 다르다. 코드 줄 수가 줄고, null 안전성이 언어 수준에서 보장되며, 코루틴 덕분에 WebFlux의 리액티브 지옥에서 탈출할 수 ...
Java에서 Kotlin으로 — NullPointerException 10만 줄을 없애는 언어 설계
Java 프로젝트에서 NPE(NullPointerException)가 전체 런타임 에러의 40% 이상을 차지한다는 통계가 있다. Tony Hoare는 null을 설계한 것을 “10억 달러짜리 실수”라고 불렀다. Kotlin은 그 실수를 언어 레벨에서 바로잡은 언어다. Kotlin은...
GIT
Git 트러블슈팅 완벽 가이드 — 충돌 해결부터 사고 복구까지
실무에서 Git을 쓰다 보면 Merge 충돌, 대용량 리포 클론 30분, 비밀키 유출, force push 사고 같은 문제를 반드시 만나게 된다. 이 글에서는 10GB 리포, 10만 커밋 히스토리, 모노레포 성능 저하, 비밀키 유출 대응 같은 극한 시나리오를 포함해 현장에서 자주 ...
Git 내부 구조 완벽 해부 — Object Model부터 Pack File까지
한 줄 요약: Git은 파일 차이가 아닌 스냅샷을 SHA-1 해시로 주소화한 Content-Addressable Storage이다. Blob·Tree·Commit·Tag 4가지 Object, Index(Staging Area), Pack File 압축, 참조 시스템을 이해하면...
Git Hooks & 자동화 — 코드 품질을 지키는 자동 방어선
커밋 하나가 프로덕션을 망가뜨린 적이 있는가? Git Hooks는 사람의 실수를 코드가 대신 막아주는 자동 방어선이다. 이 글에서는 클라이언트/서버 사이드 훅의 종류부터 husky, lint-staged, Conventional Commits, CI 연동까지 실무에서 바로 쓸 수 ...
Git 브랜치 전략 완벽 가이드 — Git Flow부터 Trunk-based까지
팀 규모와 릴리스 주기에 맞는 브랜치 전략을 선택하면 협업 충돌이 줄고, 배포 속도가 빨라지며, 장애 대응이 단순해진다. 이 글에서는 Git Flow, GitHub Flow, GitLab Flow, Trunk-based Development 네 가지 전략을 비유와 다이어그램으로 풀...
Git 고급 명령어 마스터 — rebase, cherry-pick, bisect, reflog
git add, git commit, git push만으로 버티는 시대는 끝났다. 실무에서 커밋 히스토리가 꼬이고, 핫픽스를 특정 브랜치에만 옮겨야 하고, “어제까지는 됐는데 오늘 터졌다”를 추적해야 하는 순간이 반드시 온다. 이 글에서는 rebase, cherry-pick, bi...
Git Test Post
This is a test post for GIT category.
CACHING
캐싱 전략 심화: 원리부터 분산 시스템 함정까지
캐싱은 자주 사용되는 데이터를 빠른 저장소에 보관해 응답 속도를 높이고 원본 데이터 소스의 부하를 줄이는 기법이다. 이 글은 단순한 개념 소개를 넘어, 각 전략이 왜 그 방식으로 동작해야 하는지, 잘못 쓰면 무슨 장애가 발생하는지를 Spring/Java 실코드와 함께 설명한다.
캐시 무효화 전략 — 왜 어렵고, 어떻게 완전히 해결하는가
컴퓨터 과학에는 유명한 농담이 있다. Phil Karlton의 말이다.
캐시 교체(Eviction) 알고리즘 — LRU, LFU, TinyLFU, W-TinyLFU, ARC
왜 이게 중요한가?
멀티 레이어 캐싱 아키텍처 — Caffeine + Redis 완전 해부
멀티 레이어 캐싱은 응답 속도가 다른 여러 계층의 캐시를 겹겹이 쌓아, 가장 빠른 계층에서 최대한 많은 요청을 소화하고 느린 계층으로는 최소한의 요청만 내려보내는 아키텍처다. 잘 설계된 멀티 레이어 캐시는 100K TPS 중 DB에 실제로 도달하는 요청을 0.5% 이하로 줄인다.
Spring 로컬 캐시 라이브러리 비교 — Caffeine, Ehcache, ConcurrentMapCache 심층 분석
로컬 캐시란? — 메모리 계층과 속도의 본질
CLOUD
Terraform과 IaC — 인프라를 코드로 관리하면 왜 장애가 줄어드는가
인프라를 손으로 클릭해서 만들던 시대는 끝났다. 클릭으로 만든 서버는 누가, 언제, 어떤 설정으로 만들었는지 아무도 모른다. 이것이 IaC(Infrastructure as Code)가 등장한 이유다.
서버리스 아키텍처 — AWS Lambda가 요청마다 컨테이너를 띄우는 진짜 이유
“서버리스”라는 이름은 반은 거짓말이다. 서버가 없는 게 아니라, 서버를 내가 관리하지 않는다는 뜻이다. 하지만 그 차이가 개발 방식을 근본적으로 바꾼다.
Kubernetes Cold Start — Pod가 트래픽을 받기까지 왜 30초가 걸리는가
블랙프라이데이 오전 9시, 트래픽이 갑자기 10배로 폭증했다. HPA가 Pod를 50개에서 500개로 늘리라는 신호를 보냈다. 그런데 새 Pod들이 실제로 트래픽을 받을 준비가 되는 데 5분이 걸렸다. 그 5분 동안 기존 50개 Pod가 500개 분량의 트래픽을 혼자 버텼고, 연쇄...
Kubernetes
Kubernetes(K8s)는 컨테이너 오케스트레이션 플랫폼이다. 수백 개의 컨테이너를 자동으로 배포, 스케일링, 복구한다. 개발자가 “3개의 인스턴스를 실행해”라고 선언하면, K8s는 그 상태를 항상 유지하려고 동작한다.
AWS 핵심 서비스 — 백엔드 개발자가 반드시 알아야 할 서비스 맵
AWS는 200개가 넘는 서비스를 제공한다. 처음 마주하면 지도 없이 미로에 들어선 기분이다. 이 글은 백엔드 개발자가 실무에서 반드시 마주치는 핵심 서비스를 레이어별로 정리하고, 각 서비스가 왜 필요한지, 어떻게 연결되는지를 짚는다. 면접 포인트와 실무 실수도 함께 다룬다.
JPA
Spring Data JPA 심화 — Repository 내부 동작부터 Specification, Projection까지
Spring Data JPA를 쓰면서 JpaRepository가 어떻게 구현체 없이 동작하는지 궁금했던 적이 있다면, 이 글이 그 궁금증을 해소해준다. 인터페이스를 선언하면 알아서 동작하는 마법의 원리부터 Specification, Projection, Auditing, 벌크 연산...
QueryDSL 실전 가이드 — 타입 세이프 쿼리로 JPQL 문자열 지옥 탈출하기
JPQL 쿼리를 문자열로 작성하다 오타 하나에 런타임 예외를 만난 경험이 있다면, QueryDSL이 왜 필요한지 바로 이해할 수 있다. QueryDSL은 컴파일 시점에 쿼리 오류를 잡아주는 타입 세이프 쿼리 빌더다. 이 글에서는 설정부터 실전 패턴까지 전부 다룬다.
JPA 성능 최적화 완전 정복 — 내부 메커니즘부터 극한 시나리오까지
JPA는 편리한 추상화지만 그 추상화 아래에서 어떤 일이 벌어지는지 모르면 조용히 데이터베이스를 폭격합니다. 주문 목록 100건에 쿼리 101번, 읽기 API가 더티 체킹 스냅샷을 만들고, IDENTITY 전략이 배치 INSERT를 무력화하고, 2차 캐시가 벌크 연산 직후 낡은 데...
JPA 완전 정복: 내부 동작 원리와 실전 심화
Spring Boot 프로젝트에서 JPA를 쓴다고 해서 JPA를 안다고 할 수 없다. JpaRepository를 상속하고 findById를 호출하는 것은 시작일 뿐이다. N+1 쿼리가 왜 터지는지, merge()가 왜 null 필드를 덮어쓰는지, OSIV가 왜 운영 서버에서 문제가...
JPA N+1 문제 — Hibernate 내부 메커니즘부터 극한 시나리오까지
개발 환경에서 멀쩡하던 API가 운영 트래픽에서 수백 ms 이상 걸린다면, 열에 아홉은 N+1 문제다. 단순히 JOIN FETCH를 쓰면 된다는 레시피는 누구나 안다. 하지만 면접관이 진짜 묻는 것은 왜 Hibernate가 N번 쿼리를 발생시키는지, 프록시가 내부에서 어떻게 동작하...
NETWORK
TCP와 UDP 심화 — 헤더 구조부터 혼잡 제어, QUIC까지
전송 계층(Transport Layer)의 두 프로토콜인 TCP와 UDP는 인터넷의 근간이다. 단순히 “TCP는 신뢰성, UDP는 속도”라는 수준을 넘어, 내부 메커니즘이 왜 그렇게 설계됐는지를 이해해야 장애 상황에서 원인을 정확히 진단하고, 서비스에 맞는 프로토콜을 선택하며, 커...
L4/L7 로드밸런서 심층 분석
트래픽이 폭발하는 순간, 서버는 두 가지 방식으로 죽는다. 느리게 죽거나, 갑자기 죽거나. 로드밸런서는 이 죽음을 막는 첫 번째 방어선이다. 단순히 요청을 나눠주는 장치가 아니라 장애 격리, SSL 오프로드, 세션 지속성, 헬스 감시까지 담당하는 인프라 핵심이다.
OSI 7계층 완전 분석 — 면접관이 원하는 WHY까지
OSI 7계층을 “7·6·5·4·3·2·1 암기”로 끝내는 면접자와 “각 계층이 왜 존재하고 무엇을 해결하는가”를 설명하는 면접자는 결과가 다르다. 이 글은 후자를 위해 물리 신호 인코딩부터 HTTP/3 QUIC 내부 동작까지 WHY 중심으로 파고든다. Java/Spring 맥락에...
HTTPS와 TLS 완전 해부 — 핸드셰이크부터 인증서 체인, mTLS, OCSP Stapling까지
브라우저 주소창의 자물쇠 아이콘은 단순한 장식이 아니다. 그 뒤에는 수십 년간 발전해온 암호학 프로토콜, 수천 개의 CA와 수억 개의 인증서, 그리고 수없이 반복된 해킹 사고를 통해 다듬어진 신뢰 체계가 존재한다. 시니어 개발자 면접에서 “TLS 핸드셰이크를 설명해주세요”라는 질문...
DNS
DNS(Domain Name System)는 사람이 읽을 수 있는 도메인 이름(www.example.com)을 컴퓨터가 사용하는 IP 주소(93.184.216.34)로 변환하는 분산 계층 데이터베이스 시스템이다.
EFFECTIVE_JAVA
Effective Java - 클래스와 인터페이스 (아이템 15~25)
한 줄 요약
Effective Java - 제네릭과 열거형 (아이템 26~41)
한 줄 요약
Effective Java - 모든 객체의 공통 메서드 (아이템 10~14)
한 줄 요약
Effective Java - 객체 생성과 파괴 (아이템 1~9)
한 줄 요약
MONITORING
로그 파이프라인 설계 — ELK에서 Loki까지, 하루 10억 줄을 검색하는 구조
하루에 10억 줄의 로그가 쌓인다면 어떻게 될까. 파일에 그냥 쓰면 수 TB가 되고, 검색은 불가능해진다. 로그 파이프라인은 이 데이터를 실시간으로 수집하고, 가공하고, 저장해서 밀리초 단위로 검색 가능하게 만드는 시스템이다. ELK 스택부터 Loki까지, 파이프라인을 설계하는 모...
분산 트레이싱 심화
마이크로서비스 환경에서 하나의 요청이 수십 개 서비스를 거칠 때, 어디서 지연이 발생했는지 추적하는 기술이 분산 트레이싱이다.
모니터링 완전 정복 — Prometheus·Grafana·ELK부터 알림 파이프라인까지
시스템이 지금 이 순간 무엇을 하고 있는지 알지 못한 채 운영하는 것은, 계기판 없이 비행기를 모는 것과 같다. 메트릭 수집, 저장, 시각화, 알림까지 이어지는 전체 파이프라인을 처음부터 끝까지 해부한다.
SRE와 Golden Signals
Google SRE가 정의한 4대 골든 시그널(Latency, Traffic, Errors, Saturation)을 중심으로 서비스 품질을 정량적으로 관리하는 방법론이다. “감으로 운영하는 시대”에서 “숫자로 증명하는 시대”로 전환하는 핵심 프레임워크다.
NOSQL
Neo4j와 그래프 DB — 관계가 핵심일 때 RDB를 버려야 하는 이유
“친구의 친구의 친구 중에서 나와 같은 도시에 살면서 비슷한 음악 취향을 가진 사람을 찾아라.” 관계형 DB로 이 쿼리를 작성하면 JOIN이 몇 개나 필요할까? 그래프 DB는 이 질문에 자연스럽게 답한다. 관계가 데이터의 핵심인 문제에서 그래프 DB는 RDB보다 수십 배 빠르고 수...
Apache Cassandra 심화 — 링 구조, Gossip 프로토콜, 쓰기 경로부터 운영까지
Cassandra는 “절대 멈추지 않는 DB”를 목표로 설계됐다. 마스터 노드가 없고, 모든 노드가 동등한 역할을 수행하며, 노드 한 대가 죽어도 쓰기와 읽기가 계속된다. 이 글은 그 내부 구조를 링(Ring), Gossip, 쓰기/읽기 경로, Compaction, 데이터 모델링 ...
MongoDB 언제 Document DB를 쓰고, 어떻게 설계하는가
사용자 프로필 페이지를 만든다고 하자. MySQL이라면 users, addresses, hobbies, orders 테이블을 JOIN해야 한다. MongoDB라면 쿼리 한 번으로 끝난다. 그런데 MySQL 개발자가 MongoDB를 처음 쓰면 가장 많이 하는 실수가 있다. 모든 것을...
Elasticsearch 역인덱스부터 클러스터 내부까지 — 시니어 개발자 심층 가이드
“상품명에 ‘무선 이어폰’이 포함된 결과를 0.05초 안에 보여줘야 합니다.” RDBMS의 LIKE '%무선 이어폰%'은 100만 건에서 수 초가 걸린다. Elasticsearch는 역인덱스(Inverted Index) 구조 덕분에 수억 건에서도 밀리초 단위로 응답한다. 이 글에서...
TEST
JUnit 5 심화 — ParameterizedTest, Extension, 테스트 전략까지
테스트 코드는 프로덕션 코드만큼 중요합니다. 잘 작성된 테스트는 리팩토링의 안전망이고, 버그의 조기 감지망이며, 살아있는 명세서입니다. JUnit 5는 JUnit 4와 비교해 아키텍처부터 Extension 모델까지 전면 재설계되었습니다. 이 포스트에서는 JUnit 5의 핵심 기능을...
통합 테스트 전략 — 단위 테스트만으로는 왜 부족한가
단위 테스트가 1000개 통과해도 실제 DB 연결에서 터지면 서비스는 장애다. 통합 테스트는 부품이 아니라 조립된 기계가 돌아가는지 확인하는 테스트다. 이 글에서는 Spring Boot 환경에서 통합 테스트를 설계하고, 실제 인프라를 띄워 검증하며, CI에서 속도까지 잡는 전략을 ...
테스트 더블 완전 정복 — Mock, Stub, Spy, Fake의 정확한 차이
테스트를 작성할 때 “그냥 Mock 쓰면 되지”라고 생각하기 쉽다. 하지만 Mock은 테스트 더블의 다섯 가지 유형 중 하나일 뿐이다. Dummy, Stub, Spy, Mock, Fake는 각각 다른 목적을 가지며, 잘못 선택하면 깨지기 쉬운 테스트가 만들어진다. 이 글에서는 각 ...
TDD 실전 가이드 — 테스트를 먼저 쓰면 코드가 왜 달라지는가
“테스트는 나중에 쓰면 되잖아요?” 맞다. 그런데 나중에 쓰는 테스트와 먼저 쓰는 테스트는 근본적으로 다르다. 코드를 먼저 짜면 테스트는 그 코드의 동작을 확인하는 도구가 된다. 테스트를 먼저 쓰면 테스트가 설계 도구가 된다. TDD는 테스트 방법론이 아니라 설계 방법론이다.
CICD
GitOps와 ArgoCD
GitOps는 Git 저장소를 인프라와 애플리케이션의 단일 진실 공급원(Single Source of Truth)으로 삼아, 클러스터 상태를 선언적으로 관리하는 운영 모델이다. ArgoCD는 이 GitOps 원칙을 Kubernetes 위에서 구현한 대표적인 도구다.
GitHub Actions 심화
GitHub Actions는 Workflow, Job, Step의 3계층 구조로 구성된 이벤트 기반 자동화 엔진이다. 단순한 CI/CD 도구를 넘어, Matrix Strategy로 수십 개 조합을 병렬 테스트하고, Reusable Workflow로 조직 전체의 파이프라인을 표준화할...
CI/CD
CI/CD는 소프트웨어 개발의 컨베이어벨트다. 코드 변경이 자동으로 빌드 → 테스트 → 배포되며, 각 단계에서 품질이 검증된다. 수동 배포 과정에서 발생하는 휴먼 에러를 제거하고, 배포 주기를 단축한다.
SERVER
동기/비동기/블로킹/논블로킹 — 커널부터 Spring까지 완전 해부
동기(Synchronous), 비동기(Asynchronous), 블로킹(Blocking), 논블로킹(Non-blocking)은 I/O와 동시성 프로그래밍에서 가장 자주 혼용되는 개념이다. 단순히 “블로킹은 스레드가 기다리는 것”이라는 암기 수준을 넘어, 왜 그렇게 동작하는지 — 커...
Tomcat vs Netty 스레드 모델 딥다이브 — 왜 10만 동시 접속에서 차이가 나는가
동시 접속자가 늘어나는 순간, Tomcat과 Netty는 전혀 다른 방식으로 반응한다. 같은 Java 생태계, 같은 HTTP, 같은 서버이지만 설계 철학이 근본적으로 다르다. 그 차이가 10만 동시 접속에서 생사를 가른다. 왜 그런지, 내부에서 실제로 무슨 일이 벌어지는지를 파헤친...
Nginx — 이벤트 기반 아키텍처와 로드밸런싱 동작원리 완전 분석
웹 서버가 수만 개의 동시 접속을 처리하는 방법에는 두 가지 철학이 있다. 하나는 “요청마다 사람을 붙인다”는 방식이고, 다른 하나는 “한 사람이 여러 일을 번갈아 처리한다”는 방식이다. Nginx는 후자를 극한까지 밀어붙여 만들어진 서버다.
DESIGNPATTERN
구조 패턴 총정리 — Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
구조 패턴(Structural Pattern)은 클래스와 객체를 어떻게 조합할 것인가에 집중한다. 기존 코드를 건드리지 않고 새 인터페이스를 끼워 넣거나(Adapter), 기능을 동적으로 덧씌우거나(Decorator), 복잡한 서브시스템을 단순하게 감싸거나(Facade), 구현과 ...
생성 패턴 총정리 — Singleton, Factory Method, Abstract Factory, Builder, Prototype
생성 패턴(Creational Pattern)은 객체를 어떻게 만들 것인가에 집중한다. new 키워드를 직접 쓰는 대신, 생성 로직을 캡슐화해서 코드가 구체 클래스에 의존하지 않도록 만드는 것이 핵심 목표다. GoF는 이 범주에 5개 패턴을 정의했다: Singleton, Facto...
행동 패턴 총정리 — Strategy, Observer, Template Method, Command, State
행동 패턴(Behavioral Pattern)은 객체 간의 책임 분배와 알고리즘 교환을 다루는 디자인 패턴 군입니다. 생성·구조 패턴이 “어떻게 만들고 조합하는가”를 다룬다면, 행동 패턴은 “어떻게 협력하고 소통하는가”에 집중합니다. 이번 포스트에서는 실무와 면접에서 가장 자주 등...
AI_TOOLS
Cursor AI IDE 완전 정복 — VS Code를 대체할 AI 네이티브 에디터
VS Code에 AI 플러그인을 추가하는 것과, 처음부터 AI를 중심으로 설계된 에디터를 쓰는 것은 차원이 다릅니다. Cursor는 단순히 “AI 기능이 있는 에디터”가 아니라, 코드베이스 전체를 이해하고 대화할 수 있는 AI 네이티브 환경입니다. 이 가이드에서 설치부터 고급 활용...
ChatGPT 개발자 활용법 — 코딩·디버깅·문서화 실전 워크플로우
ChatGPT를 “그냥 질문하는 도구”로만 쓰고 있다면, 사실 전체 기능의 20%만 활용하고 있는 것입니다. 코드 생성, 디버깅, 코드 리뷰, API 문서화, 테스트 케이스 작성, SQL 최적화까지 — 개발 업무 전반에 걸쳐 ChatGPT를 구체적인 워크플로우로 통합하는 방법을 실...
Claude Code 완벽 가이드 — AI 페어 프로그래밍으로 생산성 5배 올리기
개발자의 하루는 코드를 작성하는 시간보다 코드를 이해하고, 고치고, 설명하는 시간이 훨씬 많습니다. Claude Code는 바로 이 지점을 공략합니다. 단순한 자동완성 도구가 아니라, 코드베이스 전체를 이해하고 대화하듯 함께 작업하는 AI 페어 프로그래머입니다. 이 가이드에서는 설...
FINANCE
개발자를 위한 투자 입문 — 복리의 마법과 자산 배분 전략
개발자는 투자에 유리한 위치에 있습니다. 데이터를 다룰 줄 알고, 백테스트를 이해하며, 자동화에 익숙합니다. 하지만 많은 개발자가 투자를 시작하지 못합니다. “공부가 더 필요해”, “지금은 바빠서”라는 이유로 미루다 보면, 가장 소중한 자산인 시간을 낭비하게 됩니다. 이 글은 개발...
주식 자동매매 시스템 구축기 — 개발자가 직접 만든 퀀트 트레이딩
“코드를 짤 줄 아니까 자동매매도 만들 수 있겠지”라는 생각으로 시작했습니다. 맞습니다, 만들 수는 있습니다. 하지만 돈을 버는 시스템을 만드는 것은 완전히 다른 문제입니다. 이 글은 퀀트 트레이딩 시스템을 직접 구축하며 겪은 아키텍처 선택, 실전 교훈, 그리고 값비싼 실수들을 정...
PRODUCTIVITY
macOS 개발환경 완벽 세팅 — 신규 입사 첫날 2시간 만에 끝내기
새 맥북을 받았을 때의 설렘은 잠깐이고, 그 다음에는 긴 설치 노동이 시작됩니다. Homebrew, 터미널, Java, Node, Docker, IDE… 하나씩 찾아가며 설치하다 보면 반나절이 금방 지나갑니다. 이 가이드 하나로 순서대로 따라가면 2시간 안에 완전한 백엔드 개발환경...
개발자 생산성 시스템 구축 — 하루 8시간을 12시간처럼 쓰는 방법
개발자의 생산성은 단순히 “얼마나 오래 앉아 있느냐”로 결정되지 않습니다. 저는 하루 12시간 일하던 시기보다 8시간 집중해서 일하는 지금이 실제 산출물이 더 많습니다. 이 글은 개발자라는 직업 특성에 맞게 최적화된 생산성 시스템을 소개합니다. 도구 소개가 아니라 실제 작동하는 시...
TROUBLESHOOTING
Spring Boot 에러 해결 모음 — 자주 만나는 50가지 에러와 즉시 해결법
Spring Boot를 처음 배울 때, 혹은 실무에서 개발하다 보면 처음 보는 에러 메시지가 콘솔을 가득 채우는 순간을 누구나 겪는다. 이 글은 그 당황스러운 순간을 최대한 빠르게 해결할 수 있도록, 실무에서 자주 등장하는 에러 50개를 카테고리별로 모아 원인과 해결법을 정리한 참...
JVM OOM 완전 해결 가이드 — Heap Dump 분석부터 메모리 누수 추적까지
java.lang.OutOfMemoryError — 개발자라면 누구나 한 번쯤 새벽에 이 에러 알람을 받아본 경험이 있을 것이다. 서버가 갑자기 멈추고, 재시작해도 일정 시간이 지나면 또 터진다. 이 글은 JVM OOM 에러를 체계적으로 분석하고, 영구적으로 해결하는 방법을 단계별...