『실용주의 프로그래머』 5장을 읽으면서 가장 크게 남은 생각은 좋은 설계는 코드를 어떻게 더 정교하게 구성할지보다, 변화가 생겼을 때 얼마나 쉽게 대응할 수 있는지를 고민하는 것이라는 점이었다.객체지향 프로그래밍은 데이터를 객체 안에 캡슐화하고 객체들이 서로 메시지를 주고받도록 만들어 복잡도를 관리한다. 하지만 객체들이 서로의 구조를 지나치게 많이 알기 시작하면 오히려 결합도가 높아진다. 절차적인 코드 역시 여러 함수와 데이터가 강하게 얽히기 시작하면 변경하기 어려워진다.반대로 데이터를 하나의 흐름으로 바라보고 함수에서 함수로 전달하는 파이프라인은 상대적으로 결합을 줄이면서 유연한 구조를 만들 수 있다.결국 이번 장을 읽으며 계속 반복해서 떠올랐던 질문은 다음과 같다.어떻게 하면 서로를 덜 알고도 프로그..
전체 글
가치있는 글 쓰기!🧠 세컨드 브레인: 나만의 지식 관리 시스템 완벽 정리1. 세컨드 브레인의 강력한 힘아이디어를 구체화한다: 시작하기 전 먼저 머릿속에서 아이디어를 분리하여 구체적인 형태로 만들어야 한다. 물리적인 형태로 만들어야 한다는 것인데 디지털 메모는 이를 대체한다. 모호한 개념을 실체로 전환하여 관찰하고 재배열하며 편집하고 서로 결합할 수 있게 해준다.아이디어 사이의 연관성을 새롭게 밝혀낸다: 아이디어 순서를 이리저리 섞어보며 자료 사이의 연관성을 찾고 연결해본다.시간을 두고 아이디어를 발전시킨다: 우리는 최신 아이디어에 더 가중치를 높이는 편향을 갖고 있다. 당장 사용할 수 있는 최신 데이터에 의존하는 경향 때문에 이전의 생각들을 놓치게 될 수도 있다.slow burn: 스튜를 천천히 오래 끓여내 듯 우리의 ..
URL 단축기 설계요구사항URL 단축 서비스를 설계할 때 고려해야 할 핵심 요구사항은 다음과 같습니다:URL 단축: 주어진 긴 URL을 짧게 줄이기URL 리다이렉션: 축약된 URL로 HTTP 요청이 오면 원래 URL로 안내높은 가용성과 규모 확장성, 그리고 장애 감내개략적 설계안API 엔드포인트URL 단축용 REST API: 긴 URL을 받아 짧은 URL을 반환URL 리다이렉션용 엔드포인트: 짧은 URL을 받아 원래 URL로 리다이렉션리다이렉션 Status CodeURL 리다이렉션 시 사용할 수 있는 HTTP 상태 코드는 다음 두 가지입니다:301 Permanently Moved해당 요청 처리 책임이 영구적으로 Location 헤더에 반환된 URL로 이전되었음을 의미브라우저는 이 응답을 캐시하여, 다음 ..
분산 시스템에서의 유일 ID 생성 전략요구 사항분산 환경에서 효과적인 ID 생성 시스템을 설계하기 위해서는 다음과 같은 조건들을 만족해야 합니다:ID 유일성: 전체 시스템에서 절대 중복되지 않아야 함숫자형 ID: ID가 숫자로만 구성되어야 함64비트 표현: 64비트로 표현할 수 있는 값이어야 함시간순 정렬: 발급 날짜에 따라 정렬 가능해야 함높은 처리량: 초당 만 개 이상의 ID를 생성할 수 있어야 함이러한 요구사항을 만족하기 위한 여러 솔루션들을 살펴보겠습니다.솔루션 1: 다중 마스터 복제 (Multi-Master Replication)동작 원리데이터베이스의 auto_increment 기능을 활용하되, 여러 데이터베이스 서버를 사용하는 방식입니다. 핵심은 각 서버가 다음 ID 값을 구할 때 k만큼 증가..
대규모 분산 시스템에서 데이터를 효율적으로 분산시키고, 서버의 변동(추가/제거)에도 시스템을 안정적으로 유지하기 위해 사용하는 안정 해시(Consistent Hashing)에 대해 정리합니다.1. 기존 해시 방식의 문제점 (Modular Hashing)일반적인 해시 방식은 데이터 키를 서버의 개수(N)로 나눈 나머지 값을 서버 인덱스로 사용합니다.server_index = hash(key) % N이 방식은 구현이 간단하지만, 서버 수가 변할 때 치명적인 문제가 발생합니다.치명적인 단점대부분의 키 재배치: 서버가 하나 추가되거나 고장 나서 이 바뀌면, 나머지 연산()의 결과가 완전히 달라져 대부분의 키가 엉뚱한 서버로 향하게 됩니다.대규모 장애 유발 (Cache Stampede): 분산 캐시 시스템에서 서..
대규모 시스템에서 데이터를 효율적으로 저장하고 조회하기 위한 키-값 저장소의 설계 원칙과 주요 기술들을 정리합니다.1. 분산 시스템의 기초: CAP 이론분산 시스템을 설계할 때 반드시 고려해야 하는 세 가지 속성입니다.C (Consistency, 일관성):* 어떤 노드에 접속하든 모든 클라이언트는 항상 같은 데이터를 보아야 합니다.A (Availability, 가용성):* 일부 노드에 장애가 발생하더라도 시스템은 항상 응답을 반환해야 합니다.P (Partition Tolerance, 파티션 감내):* 노드 간 네트워크 장애(파티션)가 발생해도 시스템이 계속 동작해야 합니다.결론: 네트워크 장애(P)는 피할 수 없으므로, 우리는 CP(일관성 중심) 시스템을 만들 것인지, AP(가용성 중심) 시스템을 만들 ..
[System Design] 대규모 시스템 설계 기초 - 4장. 처리율 제한 장치(Rate Limiter) 설계서버가 감당할 수 있는 임계치를 넘어서는 요청이 들어오면 서비스 장애로 이어질 수 있습니다. 이를 방지하기 위해 클라이언트의 요청 횟수를 제어하는 처리율 제한 장치(Rate Limiter)의 설계 방법과 주요 알고리즘을 정리합니다.1. 처리율 제한 장치란?처리율 제한 장치는 클라이언트나 서비스가 보내는 트래픽의 처리율(Rate)을 제어하기 위한 장치입니다. 특정 기간 동안 전송되는 요청의 횟수를 제한하며, 임계치(Threshold)를 넘어서면 추가 요청은 처리를 중단(Block)하거나 뒤로 미룹니다.목적: DoS(Denial of Service) 공격 방지, 비용 절감(서버 자원 낭비 방지), ..
1. 데이터베이스 선택: SQL vs NoSQLNoSQL이 SQL보다 유리한 경우초저지연 응답 속도 (Low Latency): 복잡한 Join 연산 없이 Key-Value나 Document 조회만으로 데이터를 가져와야 할 때 유리합니다.비정형 데이터: 데이터 스키마가 고정되지 않고, 필드가 자주 변경되거나 직렬화/역직렬화(JSON 등)만 가능하면 되는 경우에 적합합니다.Join 최소화: RDB에서는 여러 테이블을 Join해야 할 정보를, NoSQL(Document DB)에서는 하나의 Document에 임베딩(Embedding)하여 저장함으로써 조회 성능을 높일 수 있습니다.대규모 데이터와 수평적 확장: ACID(엄격한 일관성)보다는 BASE(Eventual Consistency, 최종 일관성) 모델을 허..
1. 자라기: 경력이 곧 실력은 아니다흔히 우리는 '연차'가 쌓이면 자연스럽게 전문가가 될 것이라 기대합니다. 하지만 이 책은 "경력과 실력은 동등하지 않다"고 단호하게 말합니다. 연구 결과에 따르면, 진정한 전문가는 문제를 이해하는 데 더 많은 시간과 노력을 쏟지만, 단순히 경력만 많은 비전문가는 문제 파악보다는 해결책을 내는 데 급급하다고 합니다.의도적 수련과 피드백'1만 시간의 법칙'에 대한 오해도 바로잡아야 했습니다. 우리는 매일 이를 닦지만, 30년 동안 닦았다고 해서 양치질의 전문가가 되지는 않습니다. 실력이 늘지 않는 이유는 단순 반복만 하기 때문입니다. 기량을 향상시킬 목적으로 수행하는 '의도적 수련'이 없다면 성장은 멈춥니다.여기서 핵심은 피드백입니다. 생쥐조차도 버튼을 누른 즉시 보상이..
백엔드 개발을 하다 보면 데이터가 시스템 내부를 넘어 외부(네트워크, 디스크)로 이동하는 상황을 끊임없이 마주합니다. 이때 필수적으로 일어나는 과정이 바로 직렬화(Serialization)입니다.Spring 프레임워크가 많은 부분을 추상화해주기 때문에 무심코 지나치기 쉽지만, 성능 최적화와 트러블슈팅을 위해서는 이 직렬화의 동작 원리를 정확히 이해해야 합니다. 오늘은 직렬화의 개념부터 포맷별 특징, 그리고 Spring에서의 동작 방식까지 깊이 있게 정리해 보겠습니다.1. 직렬화(Serialization)란 무엇인가?메모리 상에 존재하는 객체나 데이터 구조는 불연속적인 주소에 흩어져 있습니다. 이를 네트워크로 전송하거나 파일/DB에 저장하기 위해서는 일련의 바이트 스트림(Byte Stream) 형태로 변환..