Backend
글 57개
Connection Pooling · Database
Connection Pooling
스레드가 DB를 부르려면 연결이 필요한데, 연결은 만드는 것도 무제한도 비싸다. 미리 열어 재사용하되, 연결은 DB가 상한을 정하는 자원이다.
Thread Pool · Concurrency
Thread Pool
스레드는 만드는 것도 무제한도 비싸다. 미리 만들어 재사용하고, 그 개수로 동시 실행을 제한하는 것 - Thread Pool.
Concurrency · Thread
Concurrency
서버는 요청을 동시에 처리해야 한다. 그런데 여러 스레드가 같은 것을 건드리면 조용히 어긋난다 - 경쟁 상태와 그걸 막는 법.
Pagination · Database
Pagination
100만 건을 한 번에 줄 순 없다. 나눠 주는 두 방법 - offset과 cursor, 그리고 왜 offset이 뒤로 갈수록 느려지고 밀리는가.
Idempotency · HTTP
Idempotency
네트워크는 못 믿는다. 같은 요청이 두 번 와도 한 번 한 것과 같게 - 멱등성과, POST를 멱등하게 만드는 Idempotency Key, 그리고 그 키를 누가 어떻게 만드는가.
JPA · ORM
Persistence Context
save()를 안 불렀는데 UPDATE가 나간다. JPA가 엔티티를 관리하는 공간, 영속성 컨텍스트로 그 수수께끼를 푼다.
ORM · JPA
ORM
자바 객체와 DB 테이블 사이를 손으로 나르지 않는다. JPA로 개념을 잡고, ORM이 만드는 SQL까지 본다.
Middleware · Spring
Middleware
핸들러마다 반복되는 공통 처리를 요청과 응답 사이 한 줄로 세운다. Spring의 Filter로 개념을 잡는다.
Active Record · Design Pattern
Active Record
객체가 자기를 저장할 줄 안다. Repository와 정반대 선택이고, 틀린 선택이 아니라 다른 선택이다.
Aggregate · Design Pattern
Aggregate
어디까지가 한 덩어리인가. 함께 지켜야 할 것을 묶고, 그 경계를 트랜잭션과 저장소가 따라간다.
Value Object · Design Pattern
Entity와 Value Object
무엇으로 같음을 판단하나. 식별자로 같은 것과 값이 같으면 같은 것, 그 둘을 갈라 쓰는 이유.
Domain Model · Design Pattern
로직을 어디에 둘 것인가
업무 규칙을 절차에 늘어놓을 것인가, 객체에 넣을 것인가. 트랜잭션 스크립트와 도메인 모델, 그리고 둘을 가르는 기준.
Unit of Work · Design Pattern
Unit of Work
저장할 때마다 DB에 쓰면 업무의 반쪽만 남을 수 있다. 변경을 한 단위로 모았다가 한 번에 반영하는 패턴.
DTO · Design Pattern
DTO
엔티티를 그대로 내보내면 DB 구조가 곧 API 계약이 된다. 계층을 건너는 전용 그릇을 따로 두는 패턴.
Service Layer · Design Pattern
Service Layer
컨트롤러에 업무 절차가 쌓인다. 절차를 서비스 계층으로 옮겨, 입구가 여럿이어도 규칙은 한 곳에 있게 만드는 패턴.
Repository Pattern · Design Pattern
Repository Pattern
비즈니스 로직에서 DB 코드를 걷어낸다. 데이터 접근을 인터페이스 뒤로 숨겨, 구현을 갈아끼워도 로직은 그대로 두는 패턴.
GoF · Behavioral
Interpreter
작은 언어의 문법을 객체 트리로 표현하고 그 트리를 재귀로 평가하는, 드물지만 발상이 또렷한 행위 패턴.
GoF · Behavioral
Visitor
객체 구조는 그대로 두고, 그 위를 도는 새 연산을 바깥의 방문자로 추가하는 행위 패턴.
GoF · Behavioral
Memento
객체의 내부 상태를 캡슐화를 깨지 않고 스냅샷으로 저장해뒀다가 되돌리는 행위 패턴.
GoF · Behavioral
Mediator
객체들이 서로 직접 참조하며 얽히지 않도록, 중재자를 하나 세워 소통을 그리로 몰아주는 행위 패턴.
GoF · Behavioral
Iterator
컬렉션의 속을 열어 보지 않고 원소를 순서대로 훑을 때. 순회를 캡슐화해 내부 구조와 순회 코드를 떼어 놓는 행위 패턴.
GoF · Behavioral
Chain of Responsibility
누가 처리할지 미리 못 정할 때. 요청을 처리자들의 사슬에 흘려보내 처리 가능한 자가 맡게 하는 행위 패턴.
GoF · Behavioral
State
상태에 따라 행동이 갈릴 때. 상태를 객체로 만들어 거대한 조건문을 다형성으로 바꾸는 행위 패턴.
GoF · Behavioral
Template Method
여러 흐름이 큰 틀은 같은데 한 단계만 다를 때. 뼈대를 상위가 고정하고 달라지는 구멍만 하위가 채우는 행위 패턴.
GoF · Behavioral
Command
요청을 나중에 실행하거나 되돌리거나 기록하고 싶을 때. 요청 자체를 객체로 캡슐화하는 행위 패턴.
GoF · Behavioral
Observer
상태가 바뀔 때마다 관심 있는 것들을 일일이 불러야 할 때. 구독한 여럿에게 자동으로 통지하는 행위 패턴.
GoF · Behavioral
Strategy
기준이 늘 때마다 if/switch를 고쳐야 할 때. 알고리즘을 인터페이스로 빼 런타임에 갈아끼우는 행위 패턴.
GoF · Structural
Flyweight
같은 객체를 수백만 개 만들어 메모리가 터질 때. 공유 가능한 부분을 뽑아 하나만 만들어 나눠 쓰는 구조 패턴.
GoF · Structural
Bridge
두 축이 곱해지며 클래스가 폭발할 때. '무엇'과 '어떻게'를 두 계층으로 갈라 다리로 잇고, 각자 독립해 자라게 하는 구조 패턴.
GoF · Structural
Composite
파일과 폴더처럼 개별과 묶음이 섞인 트리를, 클라이언트가 구분 없이 똑같이 다루게 하는 구조 패턴.
GoF · Structural
Facade
하나 하려고 여러 개를 순서대로 불러야 할 때. 복잡한 하위 시스템 앞에 단순한 창구 하나를 세우는 구조 패턴.
GoF · Structural
Proxy
진짜 객체 앞에 대리인을 세워 접근을 제어한다. 지연 로딩·권한 검사·캐싱을 진짜를 건드리지 않고 끼우는 구조 패턴.
GoF · Structural
Decorator
상속으로 조합을 만들면 클래스가 폭발한다. 같은 인터페이스로 감싸 기능을 덧입히고, 여러 겹으로 쌓는 구조 패턴.
GoF · Structural
Adapter
내 코드가 기대하는 인터페이스와 남의 코드가 주는 인터페이스가 안 맞을 때. 사이에 번역기를 끼워 붙게 만드는 구조 패턴.
GoF · Creational
Prototype
처음부터 만들지 않고, 이미 있는 객체를 복제해 새로 만든다. 얕은 복사의 함정과 clone()의 문제까지 다루는 마지막 생성 패턴.
GoF · Creational
Builder
인자가 많고 대부분 선택인 객체를, 생성자 폭발 없이 단계별로 조립한다. 읽히고, 필수를 강제하고, 끝에서 불변으로 굳히는 생성 패턴.
GoF · Creational
Abstract Factory
따로 만들면 짝이 어긋난다. 서로 맞아야 하는 관련 객체들을 한 세트로 만들어, 섞이지 않게 보장하는 생성 패턴.
GoF · Creational
Factory Method
객체를 만드는 코드가 구체 타입에 박히지 않게. 무엇을 만들지 하위 클래스가 결정하도록 생성을 메서드로 빼는 생성 패턴.
GoF · Creational
Singleton
앱 전체에 인스턴스가 딱 하나만 있어야 할 때. 만드는 법은 간단하지만, 멀티스레드와 전역 상태라는 두 함정이 따라오는 생성 패턴.
SOLID · DIP
Dependency Inversion Principle
고수준 정책이 저수준 구현에 매달리지 않게. 둘 사이에 추상화를 두어 의존의 방향을 뒤집는 마지막 SOLID 원칙.
SOLID · ISP
Interface Segregation Principle
쓰지도 않는 메서드에 의존하게 만들지 마라. 뚱뚱한 인터페이스를 역할별로 쪼개는 네 번째 SOLID 원칙.
SOLID · LSP
Liskov Substitution Principle
자식은 부모 자리에 넣어도 약속을 깨면 안 된다. 상속은 구조가 아니라 계약을 물려받는 것 - 세 번째 SOLID 원칙.
SOLID · OCP
Open/Closed Principle
새 동작은 추가하되 기존 코드는 고치지 않는다. 타입이 늘 때마다 if-else를 여는 대신, 다형성으로 확장점을 두는 두 번째 SOLID 원칙.
SOLID · SRP
Single Responsibility Principle
클래스가 바뀌는 이유는 하나여야 한다. '일'이 아니라 '이유'로 나누는 첫 번째 SOLID 원칙.
Database · Storage
B-tree와 LSM-tree - 읽기와 쓰기 중 무엇을 팔 것인가
8바이트를 바꾸려고 8KB를 다시 쓴다. 그게 싫으면 뒤집으면 되는데, 그러면 읽기가 대가를 낸다.
Database · Scaling
복제 - 방금 쓴 걸 왜 못 읽는가
읽기를 늘리려고 복제했더니 시간이 뒤엉킨다. 그리고 격리 수준은 이걸 막아주지 않는다.
Database · Scaling
파티셔닝과 샤딩 - 나누면 무엇을 잃는가
둘의 경계는 '누가 조각을 아는가'다. 그리고 샤딩하는 순간 지금까지의 트랜잭션 이야기가 대부분 무효가 된다.
Database · Design
키 설계 - 무엇으로 행을 가리킬 것인가
자연키가 배신하는 순간, 대리키를 쓰면서 흔히 빠뜨리는 것, 그리고 UUID가 인덱스를 망가뜨리는 이유.
Database · Design
정규화 - 한 테이블은 한 가지 사실만 말한다
정규형을 외우지 않고도 판단하는 법, 그리고 반정규화가 실제로 무엇을 사고파는 거래인지.
Database · Performance
실행 계획 - 세 가지만 보면 된다
EXPLAIN 출력이 외계어처럼 보일 때. 트리를 어느 방향으로 읽고, 어디서 범인을 찾는가.
Database · Join
조인 알고리즘 - DB는 세 가지 방법 중 하나를 고른다
중첩 반복·해시·정렬 병합이 각각 언제 이기는지, 그리고 조인이 갑자기 느려지는 진짜 이유.
Database · Index
인덱스 - 왜 빠르고, 왜 만들어도 안 타는가
B-tree가 이진트리가 아닌 이유부터, 인덱스를 만들어놓고도 풀스캔이 도는 다섯 가지 경우까지.
Database · Storage
블록 - DB는 바이트를 모른다
4바이트를 읽으려고 8KB를 읽는다. 낭비처럼 보이는 이 단위가 뒤에 나올 거의 모든 것의 바닥이다.
Database · Transaction
MVCC - 잠그는 대신 버전을 쌓는다
읽기가 쓰기를 막지 않게 만든 대가로 무엇을 떠안게 되는가. 버전 체인, 스냅샷, 그리고 청소 문제.
Database · Transaction
락과 데드락 - 잠가서 지키는 방식의 대가
공유락·배타락에서 2단계 잠금까지, 그리고 두 트랜잭션이 서로를 영원히 기다리게 되는 과정.
Database · Transaction
격리 수준 - 같이 읽고 쓰면 무엇이 깨지는가
더티 리드·반복 불가능 읽기·팬텀 리드가 언제 생기는지, 그리고 격리 수준이라는 이름이 왜 믿을 게 못 되는지.
Database · Transaction
트랜잭션과 ACID - 네 글자의 무게가 다르다
원자성·일관성·격리성·지속성이 각각 무엇을 보장하는지, 그리고 왜 넷 중 하나만 협상 대상인지.