개요 분산 추적 컨텍스트를 어디에 어떻게 실어 나를지에 대한 표준 패턴 정리. 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로 키와 값을 동시에 순회 가능 ...

개념/배경 백프레셔 Backpressure는 소비자가 생산자의 처리 속도를 따라가지 못할 때, 소비자가 생산자의 속도를 조절하도록 피드백을 주는 흐름 제어 메커니즘을 의미함 직관적 비유로 좁은 깔때기 소비자에 높은 수압 생산자를 연결했을 때, 깔때기 내부에 물이 차며 더 유입되지 않도록 압력이 올라가거나 수도를 잠그라는 신호를 보내는 상황과 동일함 왜 중요한가 처리 속도 불균형이 누적되면 메모리 초과와 지연 폭증으로 이어짐 생산자 1000 req/s, 소비자 100 req/s 가정 매초 900개가 버퍼에 쌓여 메모리 증가, 결국 OOM 위험 큐 대기열이 길어져 tail-latency 증가, 사실상 영구 대기 상태 발생 가능 백프레셔는 이런 누적을 초기에 억제해 시스템 안정성 확보와 자원 보호에 기여함 핵심 개념과 정의 Producer: 데이터를 생성·전송하는 주체 Consumer: 데이터를 수신·처리하는 주체 Backpressure: 소비자가 처리 가능한 속도로 생산자에 역방향 피드백을 전달해 유량을 제어하는 행위 전략 축: 조절 Control, 버퍼링 Buffering, 드롭 Dropping 동작 원리/전략 A. 조절 Control/Throttling ...

개요 API 에러 규격의 핵심은 에러를 안정적으로 식별할 수 있는 Code 체계 확보임 HTTP Status만으로는 부족하고 메시지는 언어·맥락에 따라 바뀔 수 있음 실제로 계약으로서 신뢰할 수 있는 값은 error.code 임 아래는 다수의 글로벌 서비스에서 공통적으로 쓰는 Error Code 설계 원칙 정리 설계 원칙 error.code 는 서비스 전반의 안정적인 식별자여야 함 메시지나 HTTP Status는 변경 가능하지만 error.code 는 변경 불가 구버전 클라이언트도 동일 코드를 신뢰해야 하므로 호환성 보장 필수 숫자형 대신 의미가 드러나는 문자열 기반 Enum 권장 숫자형은 의미 파악 어려움, 매뉴얼 의존, 협업 비용 증가 문자열 Enum은 가독성, 검색성, 커뮤니케이션 효율 우수 예시 ...