개요 비동기는 강력한 도구임. 다만 배열과 스트림 같은 이터레이터와 결합되면 누가 무엇을 언제 기다리는지 불명확해지기 쉬움 핵심 포인트 세 가지 기억 완료 보장 확보했는지 동시성 제어를 명시했는지 백프레셔로 생산 속도 ≤ 소비 속도 유지했는지 비동기가 의도대로 동작하지 않는 케이스 forEach + async 사용 콜백이 반환한 프로미스를 외부가 수집하지 않음 → 완료 보장 깨짐, 레이스와 누락 가능성 증가 items.forEach(async (x) => { await doAsync(x) // 외부에서 기다리지 않음 }) map + async 이후 기다리지 않음 ...

개요 TypeScript에서 type과 interface는 겹치는 부분이 많지만 용도와 확장 방식이 다름 객체 구조 설계와 복잡한 타입 표현 중 무엇을 우선하느냐에 따라 선택 달라짐 핵심 차이 포인트 중심으로 정리 핵심 개념 type 타입 별칭 정의 수단 기본 타입, 유니언, 튜플, 교차 타입 등 복합 표현에 유리 선언 병합 불가 interface 객체의 구조 정의 수단 확장과 선언 병합 지원 주로 객체와 클래스와의 계약 정의에 사용 // type 별칭 최소 예시 type ID = number | string type Point = [number, number] type Person = { name: string } & { age: number } // interface 최소 예시 interface User { name: string; age: number } interface Employee extends User { employeeId: number }차이점과 동작 표현 범위 ...

개요 Collation은 문자열 정렬과 비교 규칙 정의 테이블에 저장되는 바이트 표현은 인코딩(character set)으로 결정되며, 정렬과 비교 결과는 Collation으로 결정됨 둘은 목적과 적용 지점이 다름 핵심 개념 Character set은 문자 ↔ 바이트 매핑 Collation은 특정 문자 집합 위에서 정렬 순서와 동일성 판단 규칙 정의 대소문자 민감도(cs), 대소문자 비민감도(ci), 악센트 민감도(as), 악센트 비민감도(ai) 같은 속성으로 비교 엄격도 제어 언어별 규칙 존재하며 같은 인코딩이라도 Collation에 따라 결과 달라짐 동작 원리와 적용 범위 적용 레벨 계층 구조: 서버 기본값 → 데이터베이스 → 테이블 → 컬럼 → 표현식 단위 오버라이드 가능 영향 받는 연산: ORDER BY, GROUP BY, DISTINCT, LIKE, = 등 문자열 비교 연산 전반 인덱스는 해당 컬럼의 Collation 기준으로 구성되며 정렬 규칙이 범위 검색과 정렬 최적화에 직접 영향 다국어 환경에선 ICU 기반 Collation이나 언어 특화 Collation 선택 필요 ...

개요 ERC-1155는 게임 아이템처럼 대량의 토큰을 효율적으로 관리하기 위해 등장한 멀티 토큰 표준으로, ERC-721의 전송·배포 측면 비효율을 줄이려는 목적을 가짐 편의점 비유로 직관화 가능 ERC-721 개별 포장 모델, 물건 10개 결제에 결제 10번·영수증 10장 ERC-1155 장바구니 모델, 물건 10개를 한 번에 결제·영수증 1장 핵심 개념 ERC-721 단일 NFT 표준, 토큰 ID 하나가 유일한 자산을 대표 ERC-1155 멀티 토큰 표준, 하나의 컨트랙트에서 다수의 ID 발행과 각 ID별 수량 관리 동일 ID에 수량이 붙는 구조로 FT·NFT·SFT를 한 컨트랙트에서 혼합 가능 세미 펀지블 SFT, 같은 ID를 공유하는 동일 품질의 여러 개 토큰을 표현 동작과 구조 단일 컨트랙트에 다수의 tokenId와 balance 맵핑 보유 전송 함수 safeTransferFrom 단건, safeBatchTransferFrom 묶음 전송 지원 이벤트는 TransferSingle과 TransferBatch로 발행, 동일 ID 다건 이동에 최적화 메타데이터는 ID 기반 템플릿 URI 방식 활용이 일반적 {id} 플레이스홀더 패턴 사용 장점 비교 A. 가스비 및 처리량 개선 ...

개념/배경 마이크로서비스와 비동기 작업이 섞인 환경에서 요청의 전 흐름을 좇기 위한 상관 식별자 필요 일반적으로 trace id를 tid로 표기해 서비스 경계를 넘나들며 전파함 HTTP 같은 동기 호출과 메시지 큐 같은 비동기 처리의 전파 매체가 다르므로 매체별 규칙을 명확히 두는 것이 핵심 산업 표준은 W3C Trace Context와 OpenTelemetry가 사실상 기본값 프로세스 내부 전파에는 비동기 컨텍스트 저장소 사용 권장 핵심 개념과 정의 TID(trace id)와 span id 구분, tid는 전체 요청 상관을 위한 루트 식별자 역할 W3C Trace Context의 traceparent와 tracestate 헤더로 표준 전파 OpenTelemetry는 위 표준을 구현하고 언어별 SDK 제공 프로세스 내 컨텍스트 전파는 AsyncLocalStorage 등 런타임 컨텍스트로 처리 표준 패턴 HTTP 및 gRPC 같은 동기 네트워크 통신은 헤더 사용이 기본 원칙 메시지 큐나 비동기 작업은 메시지 Body 또는 시스템이 제공하는 메시지 속성 사용 지원되는 경우 메시지 헤더를 우선 사용, 없으면 Payload에 포함 요약 ...

개요 인덱스는 데이터베이스 성능 최적화의 출발점임을 부정하기 어려움 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 스키마, 타입 정의까지 동일한 기준으로 일관 적용 권장 ...

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