개요 인덱스는 데이터베이스 성능 최적화의 출발점임을 부정하기 어려움 MySQL은 스토리지 엔진에 따라 인덱싱과 검색 방식이 달라질 수 있어 기본 개념을 정확히 이해하는 것이 쿼리 튜닝의 기반이 됨 또한 디스크 접근 특성인 랜덤 I/O와 순차 I/O의 차이는 실무 성능에 직접적인 영향을 주므로 반드시 짚고 가야 함 디스크 I/O가 성능을 좌우하는 이유 CPU와 메모리 성능은 가파르게 개선됐지만 디스크 장치는 물리적 한계로 개선 속도가 상대적으로 느림 DB 성능 튜닝의 많은 부분이 디스크 I/O를 얼마나 줄이느냐로 귀결됨 ...

유한 상태 머신(FSM, Finite State Machine)은 시스템이 가질 수 있는 상태와 그 사이 전이를 명확히 정의하는 모델 복잡한 비즈니스 로직을 단순화하고 예측 가능하게 만들어 결제나 주문처럼 순서와 무결성이 중요한 도메인에 적합 개념/배경 상태와 규칙을 명시적으로 모델링해 허용되지 않은 동작을 구조적으로 차단하는 접근 요구사항이 늘어도 상태 전이 규칙을 중심으로 변경 범위를 제한해 안정성 확보에 유리 핵심 개념 상태 State 시스템이 존재할 수 있는 유한한 조건 집합 예 로그인 전, 로그인 후, 결제 대기, 결제 완료 이벤트 또는 입력 Event/Input 상태 변화를 유발하는 외부 행위나 신호 예 버튼 클릭, 네트워크 끊김, 시간 초과 전이 또는 규칙 Transition/Rule 어떤 상태에서 어떤 이벤트가 발생하면 다음 상태로 이동한다는 정의 규칙에 없는 전이는 거부 또는 무시 동작 원리 현재 상태와 입력을 받아 다음 상태를 결정하는 전이 함수 관점으로 해석 가능 f(state, event) -> nextState 형태 전이에는 가드 조건과 부수효과가 수반될 수 있음 가드는 전이 허용 여부 판단, 부수효과는 알림 전송이나 로그 기록 등 외부 행동을 명시적으로 수행 정의되지 않은 전이를 막아 비정상 흐름 차단 재진입이나 중복 이벤트 처리 시에도 일관된 행동을 보장 예시 자판기 모델 상태 대기 중, 이벤트 동전 투입 -> 다음 상태 금액 충족 돈이 들어와야만 다음 상태로 이동 상태 금액 충족, 이벤트 상품 버튼 누름 -> 다음 상태 상품 배출 중 상품 선택 가능 상태 상품 배출 중, 이벤트 배출 완료 -> 다음 상태 대기 중 초기 상태로 복귀 상태 대기 중, 이벤트 상품 버튼 누름 -> 상태 변화 없음 금액 미충족 시 입력 무시 장점과 효과 정합성 보장 정의된 전이 외 동작 불가하므로 데이터 꼬임 예방 결제가 완료 상태에서 결제 요청 이벤트가 다시 들어오면 규칙에 없는 전이로 처리되어 거부 또는 무시되어 중복 결제 차단에 기여 멱등 처리 전략과 결합 시 효과적 예측 가능성 향상 몇 개의 상태와 전이 규칙으로 복잡도를 축소해 로직 이해와 디버깅 용이 테스트 용이성 상태 x 이벤트 조합별로 기대 결과가 명확해 단위 테스트 케이스 설계가 단순 주의와 베스트 프랙티스 상태 폭발 주의 의미 있는 상태만 유지하고 파생 속성은 별도 데이터로 관리 전이 정의의 단일 소스 유지 가드와 부수효과를 전이 정의 근처에 모아 산재된 분기 로직을 제거 잘못된 전이 로깅과 모니터링 활성화 무시된 입력을 계측해 모델 누락이나 외부 시스템 이상 조기 탐지 멱등성 고려 중복 이벤트 재수신 가능 환경에서는 전이와 부수효과를 멱등하게 설계 분산 환경에서는 상태 영속화와 재시도 정책을 명시 크래시 후 재기동 시 일관성 있는 상태 복원 필요 마무리 FSM은 상태와 전이를 중심으로 시스템 동작을 제한하고 드러내며, 규칙 밖 동작을 원천 차단해 안정성을 끌어올림 결제나 주문 같은 순서 기반 도메인에 특히 유용하며, 상태 정의와 전이 규칙만 명확히 유지하면 변경에도 견고하게 대응 가능 ...

개요 분산 추적 컨텍스트를 어디에 어떻게 실어 나를지에 대한 표준 패턴 정리. HTTP 같은 동기식 통신과 메시지 큐 같은 비동기식 통신은 전달 수단이 다름. 업계 표준은 W3C Trace Context와 이를 구현한 OpenTelemetry를 따르는 흐름임 핵심 개념 trace-id, span-id, sampling 플래그 등 추적 컨텍스트 전달 필요 동기식 요청/응답 채널은 헤더 기반 메타데이터 전달이 자연스러움 비동기 메시징은 메시지 자체가 전달 단위이므로 페이로드 또는 메시지 속성 이용 채널이 헤더 개념을 지원하면 헤더 우선, 없으면 페이로드에 포함 통신별 패턴 HTTP/REST 통신: 요청/응답 헤더에 trace 컨텍스트 실어 전달 gRPC: 메타데이터(헤더 개념)로 전달 Kafka: 메시지 헤더 지원. 가능하면 헤더 사용 권장 RabbitMQ: 메시지 프로퍼티의 headers 사용 가능 AWS SQS: Message Attributes 사용 가능. 미지원 시 Body에 포함 BullMQ/Redis 기반 잡 큐: 헤더 개념 없음. Job data에 포함 WebSocket: 초기 핸드셰이크 단계에서 허용된 메타데이터 채널 또는 쿼리로 전달, 이후 각 메시지 페이로드에 포함. 환경 제약으로 커스텀 헤더 불가한 경우 존재 산업 표준 OpenTelemetry는 W3C Trace Context를 구현하는 업계 표준 스택 HTTP는 W3C traceparent, tracestate 헤더 사용 비동기 메시징은 채널이 헤더를 지원하면 헤더 사용, 아니면 데이터에 포함하는 전략 일반화 예시 ...

개념/배경 Single Source of Truth(SSOT)는 소프트웨어와 데이터 관리에서 중요한 데이터는 권위 있는 하나의 출처만을 가진다는 원칙을 뜻함 핵심은 원본은 한 곳에만 두고 나머지는 그 원본을 참조하거나 파생해 사용함 원본이 분산되면 동기화 비용과 불일치 위험이 기하급수적으로 증가함 왜 필요한가 데이터 불일치 발생 위험 증가 위치 A의 유저 나이가 20인데 위치 B에서는 21로 표시되는 상황 유지보수 비용 급증 수정 시 흩어진 모든 복제본을 찾아 변경해야 함 일부 누락 시 버그와 장애로 연결됨 변경 전파가 느림 캐시나 로컬 복제본 만료 정책이 미흡할 때 최신성이 깨짐 실생활 비유 주민등록과 같은 신원 시스템의 원본 데이터는 정부의 공식 저장소에 존재 은행이나 병원은 이를 조회해 사용할 뿐 별도의 원본을 만들지 않음 스마트폰 연락처가 전화번호의 원본 역할을 수행 연락처에서 번호를 바꾸면 메신저나 문자 앱도 최신 번호를 참조해 표시함 개발 적용 예시 프론트엔드 상태 관리 Bad 부모 컴포넌트에 userData 보유, 자식 컴포넌트가 이를 복사해 별도 상태로 관리 부모 변경이 자식에 반영되지 않을 수 있음 SSOT 상위 컴포넌트 또는 중앙 스토어에만 userData 보관 자식은 props나 selector로 읽기 전용 접근 데이터베이스 모델링 Bad 주문 테이블에 고객 주소를 중복 저장하고 회원 테이블에도 주소 저장 SSOT 회원 테이블에만 주소 저장 주문 테이블은 회원 ID를 참조해 조인으로 조회 타입 정의 공유(TypeScript) Bad 동일한 API 응답 타입을 페이지 A와 B 각각에서 중복 정의 SSOT types/user.ts에 단일 타입 정의 위치 확보 후 모든 모듈에서 import하여 사용 베스트 프랙티스와 주의 쓰기 경로 단일화 원본에 대한 쓰기는 반드시 한 경로로만 수행 읽기 복제본과 캐시 관리 캐시는 파생물로 취급 만료 정책, 동기화 주기, 재검증 전략을 명시 식별자 기반 참조 우선 파생 데이터에는 식별자만 저장하고 필요 시 조인 또는 조회로 해석 양방향 복제와 수동 동기화 지양 충돌 해결 복잡도와 데이터 드리프트 위험 상승 마이그레이션 단계 관리 이중 쓰기 기간 최소화, 피처 플래그와 데이터 백필 계획 수립, 점진적 전환 적용 요약 원본은 하나만 관리하고 나머지는 참조한다는 단순한 원칙이 SSOT의 전부 이를 지키면 데이터 신뢰성 확보와 변경 비용 축소에 직접적인 효과가 있음 프론트엔드 상태, DB 스키마, 타입 정의까지 동일한 기준으로 일관 적용 권장 ...

개요 좋은 시스템 설계는 복잡해 보이지 않고 긴 시간 동안 별문제 없이 돌아가는 상태를 말함 핵심은 상태를 최소화하고, 검증된 단순한 컴포넌트를 필요할 때만 조합하는 방향 과설계나 과도한 신기술 도입은 문제를 감추거나 유지보수 비용을 키우는 경향 최소 기능의 단순 구조에서 시작 후 관측 기반으로 점진 개선 권장 시스템 설계의 정의와 접근 소프트웨어 설계가 코드 조립이라면 시스템 설계는 서비스를 조합하는 일이라는 관점 주요 구성 요소 팔레트 앱 서버 데이터베이스 캐시 큐와 잡 러너 이벤트 버스 프록시와 게이트웨이 좋은 설계의 징후 ...

개요 HTTP Status Code만으로는 서비스 로직의 원인을 전달하기 부족함 400대와 500대는 네트워크 관점의 대분류 신호에 가깝고 실제로 필요한 것은 비즈니스 맥락의 구체적 사유임 결론은 단순함 HTTP Status는 대분류 신호로 두고 실제 의미와 추가 컨텍스트는 Response Body에 싣는 구조가 현실적 해법임 핵심 원칙 HTTP Status는 큰 범주 신호등 역할 2xx 성공 4xx 클라이언트 오류 5xx 서버 오류 비즈니스 의미는 Response Body의 커스텀 에러 구조로 표현 클라이언트가 코드 기반으로 분기하고 UI를 결정할 수 있어야 함 운영 관측을 위해 traceId 제공 업계에서 검증된 기본 구조 아래 형태가 가장 보편적으로 쓰이는 패턴임 ...

개념/배경 객체 구조 분해 할당에서 프로퍼티 이름을 바꾸는 기본형은 { 기존프로퍼티명: 새변수명 } 형태임 사용법/예시 아래는 request 프로퍼티를 revealRequest라는 이름으로 받는 예시 const { request: revealRequest } = await client.doSomething({...})의미는 다음과 같음 doSomething이 반환하는 객체에서 request 프로퍼티 추출 추출한 값을 revealRequest 변수에 바인딩 아래 전개 코드와 동일함 const result = await client.doSomething({...}) const revealRequest = result.request왜 쓰는가 코드 간결화 필요한 프로퍼티만 선택 추출 문맥에 맞게 변수명 명확화, 의도 드러남 참고자료 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment

개요 운영 중인 서비스에서 전체 트래픽을 한 번에 신규 기능이나 신규 인프라로 전환하지 않고, 일정 비율만 점진적으로 이동하는 전략이 필요함 주요 활용 맥락 A/B 테스트로 실험군과 통제군 분리 카나리 배포로 신규 버전을 소수 사용자에게만 적용 신규 데이터베이스, 캐시, 인덱스 전환 검증 신규 알고리즘, 추천 엔진, 정책 점진 적용 서버 비용 최적화를 위한 점진적 트래픽 이동 아래는 대부분의 시나리오에 적용 가능한 일반화된 트래픽 분배 기법 정리 요구 조건 Deterministic — 같은 사용자나 리소스는 항상 같은 그룹에 속해야 함 요청마다 그룹이 바뀌면 실험 신뢰성이 떨어지고 디버깅이 어려움 안정적 해시 기반 결정 방식 필요 ...

개념/배경 한 객체의 상태 변화나 이벤트를 여러 객체가 자동으로 감지하고 반응하게 만드는 구조를 Observer 패턴이라 부름 발행자와 구독자의 관계로도 설명됨. Publisher가 이벤트를 내보내고 Subscribers가 이를 받는 흐름 핵심은 느슨한 결합과 자동 알림 흐름 유지 핵심 개념과 구성요소 Subject 또는 Observable 이벤트를 발생시키는 주체 Observer 목록을 관리 상태가 변하면 observers에 알림 전파 Observer 상태 변화를 알고 싶은 소비자 update 같은 콜백 보유 notify Subject가 모든 Observer에게 브로드캐스트하는 동작 동작 원리 Observer가 Subject에 구독 등록 Subject 상태 변화 발생 Subject가 notify 실행, 등록된 Observer의 콜백 호출 Observer는 전달된 값에 따라 자체 로직 수행 필수 인터페이스의 최소 형태는 아래와 같음 ...

개요 Object.entries는 객체의 키-값 쌍을 [key, value] 형태의 배열 리스트로 반환하는 표준 메서드임. 객체를 배열로 바꿔 순회, 변환, 자료구조 간 변환 같은 작업을 단순화하는 데 유용함 문법 Object.entries(obj) 매개변수 obj: 키-값 쌍을 가진 객체 값 반환값: [key, value] 쌍의 2차원 배열 기본 예시 const user = { name: 'Alice', age: 25 } Object.entries(user) // [['name', 'Alice'], ['age', 25]] 배열로 변환되므로 for…of, map 같은 배열 API에 바로 연결 가능 순회와 변환 for…of로 키와 값을 동시에 순회 가능 ...