Posts

본 글은 정보보호 개론 맥락에서 암호 시스템의 기본 개념과 동작 방식을 정리한 내용임 개념과 배경 암호학은 정보의 안전한 전달과 저장을 위한 방법론을 다루는 학문임 정보 보안의 목표는 CIA로 요약됨 무결성 중간 위조·변조 불가 기밀성 허용되지 않은 자는 내용 파악 불가 가용성 적절한 시점에 허가된 사용자만 접근 가능 현대 보안에서는 암호 알고리즘이 공개되어도 안전해야 한다는 전제를 둠 즉 안전성은 비밀 알고리즘이 아니라 키에 의존함 컴퓨터가 다루는 모든 정보는 이진수이므로 보호는 결국 비트열을 다른 형태로 변환하는 문제로 귀결됨 ...

관계형 데이터에서 Prisma의 where 절은 자식 레코드 기준으로 부모를 거르는 필터를 제공함. 특히 some과 every는 겉보기엔 비슷하지만 결과 집합을 크게 바꾸는 핵심 차이가 있음. 단일 필드만으로 필터링해도 동일하지 않을 수 있어 주의 필요 개념 some 관계된 레코드 중 적어도 하나가 조건을 만족하면 부모 포함 존재성 검사에 해당, 하나라도 매칭되면 true every 모든 관계된 레코드가 조건을 만족해야 부모 포함 단 하나라도 위배되면 제외됨 관계된 레코드가 하나도 없으면 vacuously true로 간주되어 조건 만족으로 처리됨 동작 원리 some은 존재량화, every는 전칭량화에 해당함 차이는 자식 레코드가 0개이거나 2개 이상일 때 두드러짐. 1개일 때는 조건이 동일하다면 결과가 같아질 수 있음 특히 자식이 없는 경우 every는 기본적으로 참으로 평가되어 부모가 포함됨. 빈 결과를 제외하려면 추가 조건 필요 간단 예시 model Post { id Int @id @default(autoincrement()) title String comments Comment[] } model Comment { id Int @id @default(autoincrement()) text String postId Int post Post @relation(fields: [postId], references: [id]) } 댓글 text가 ‘interesting’인 항목을 기준으로 게시글을 거르는 케이스를 가정 ...

개념/배경 Array.prototype.map은 배열의 각 요소에 대해 콜백을 호출해 변환된 결과로 새 배열을 만드는 메서드임 원본 배열 불변 유지, 동일 길이의 새 배열 생성이 핵심 특징임 기본 문법 const newArray = array.map((element, index, array) => { return element; }); element 현재 요소 index 현재 인덱스 array 원본 배열 참조 콜백은 요소 수만큼 호출되고, 콜백의 반환값이 새 배열의 같은 위치에 배치됨 사용 예시 숫자 배열 변환 const numbers = [1, 2, 3, 4, 5]; const doubled = numbers.map((n) => n * 2); // [2, 4, 6, 8, 10] 객체 배열에서 특정 속성 추출 ...

개요 커링 Currying은 여러 개의 인자를 받는 함수를 단일 인자 함수들의 연속으로 변환하는 기법 n개의 인자를 받는 함수 → n번에 걸쳐 한 개 인자씩 받는 함수 체인으로 분해 함수형 프로그래밍 맥락에서 재사용성과 조합성 향상 목적 핵심 개념 커링 currying: f(a, b, c) 형태를 f(a)(b)(c)로 바꾸는 변환 부분 적용 partial application: 전체 인자 중 일부를 고정해 새로운 함수를 만드는 기법 관계: 커링된 함수는 부분 적용을 자연스럽게 지원함 동작 원리와 간단 예시 일반 함수 ...

개요 findUnique로 단일 레코드 조회하면서 관련된 데이터까지 한 번에 가져오고 싶을 때 where와 include를 어떻게 조합해야 하는지 정리함 관계 필터링을 where에 넣을 수 있는지, include에서 필터가 가능한지 헷갈리기 쉬운 지점 정리 핵심 개념 findUnique는 유니크 키로 정확히 하나의 레코드를 찾는 용도 findUnique의 where는 유니크 필드만 허용됨, 관계 필터나 일반 조건 결합 불가 include는 조회된 레코드에 대한 연관 레코드를 함께 가져오는 옵션 to-many 관계에 한해 include 내부에서 where 사용 가능, to-one 관계는 where 불가 where 사용 패턴 잘못된 예시 // findUnique에 관계 필터 결합 시도 → 타입 에러 // (User(1) → Post(N) → Metadata(1) 관계) await db.user.findUnique({ where: { id: userId, // 'posts'는 유니크 필드가 아니므로 'where'에서 관계 필터링 불가 posts: { some: { metadata: { editorEmail: email } } }, }, }); 올바른 최소 조건 await db.user.findUnique({ where: { id: userId }, // 'id'는 유니크 필드 }); 관계 조건이 필요하면 findFirst 또는 findMany 사용 // 'findUnique'가 아닌 'findFirst'를 사용하면 // 'where'에 관계 필터를 포함할 수 있음 await db.user.findFirst({ where: { id: userId, posts: { some: { metadata: { editorEmail: email } } }, }, }); 요약하면 findUnique에는 유니크 조건만, 관계 기반 필터는 findFirst 또는 findMany로 처리함 ...

개요 Node.js가 스크립트를 실행할 때 어떤 구성요소가 어떤 순서로 초기화되고 동작하는지 정리 바이너리 기동부터 모듈 로딩, V8 파싱과 실행, 이벤트 루프와 비동기 작업 처리까지의 전체 흐름을 개발자 관점에서 간결하게 설명 핵심 개념 V8 엔진, Ignition 바이트코드와 JIT 최적화 libuv, 비동기 I O 백엔드와 이벤트 루프 단계 모듈 시스템, CommonJS와 ES Module의 로딩 차이 전역 실행 컨텍스트와 런타임 내장 객체 마이크로태스크 큐와 process.nextTick의 우선순위 실행 순서 요약 Node 바이너리 시작 런타임 초기화와 내부 바인딩 준비 모듈 로더 기동 및 엔트리 파일 로드 V8 파싱과 바이트코드 컴파일 전역 실행 컨텍스트 구성과 최상위 코드 실행 비동기 작업 등록 이벤트 루프 진입 비동기 콜백 처리 반복 graph TD A[Node 시작] --> B[V8, libuv 초기화] B --> C[모듈 로딩] C --> D[파싱 및 컴파일] D --> E[최상위 코드 실행] E --> F[이벤트 루프] F --> G[비동기 처리 반복] 단계별 동작 1단계 Node 바이너리 시작 node yourfile.js 실행으로 C++ 엔트리 포인트가 기동됨 V8, libuv, 내부 바인딩 계층이 초기화되고 런타임 전역 상태가 준비됨 ...

개념/배경 DI(Dependency Injection, 의존성 주입)의 핵심 아이디어는 명확함 객체가 자신이 사용할 의존 객체를 스스로 생성하지 않고, 외부로부터 전달받아 사용하는 것임 이 단순한 설계 변경만으로도 코드의 변경 용이성, 테스트 편의성, 그리고 전체 시스템의 확장성에서 거대한 차이가 발생함 문제 상황: 강한 결합 (Tight Coupling) 전형적인 문제 패턴은 클래스 내부에서 다른 구체적인 클래스(Concrete Class)를 new 키워드로 직접 생성하여 사용하는 것임 의존 대상의 구현이 변경되면, 해당 객체를 사용하는 클래스 내부 코드도 반드시 함께 수정해야 함 단위 테스트(Unit Test)를 작성할 때, 테스트 대상 객체가 의존하는 실제 객체들까지 모두 함께 엮여 들어와 테스트가 복잡하고 무거워짐 예를 들어 Gamer가 BlueSwitchKeyboard를 직접 생성해 사용한다면, Gamer는 BlueSwitchKeyboard라는 구체적인 구현에 영구적으로 고정됨 만약 키보드 종류를 RedSwitchSilentKeyboard로 바꾸려면 Gamer 클래스의 내부 코드를 직접 수정해야 함 이 상태를 결합도가 높다고 부름 ...

개요 KISS는 Keep It Simple, Stupid 또는 Keep It Simple and Straightforward의 약자이며 1960년대 미 해군에서 출발한 설계 원칙입니다. 소프트웨어에서는 불필요한 복잡성을 제거하고 이해와 변경이 쉬운 구조를 지향합니다. 목표는 적은 개념과 짧은 경로로 같은 가치를 제공하는 시스템을 만드는 것임 핵심 개념 단순함 추구: 필요 최소의 개념, 규칙, 구성 요소 유지 이해 용이성: 읽고 추론하기 쉬운 흐름과 명명 유지보수 용이성: 응집도 높이고 결합도 낮춰 변경 영향 최소화 적용 방법 처음부터 모든 시나리오를 포괄하려 하지 말고 현재 요구에 맞춘 최소 기능으로 시작 큰 만능 모듈 대신 작고 역할이 분리된 구성으로 나누기 공개 인터페이스를 최소화하고 기본값을 합리적으로 설계 데이터 흐름을 단방향으로 단순화하고 예외 경로는 명시적으로 처리 관련 원칙 DRY: 중복 제거로 변경 비용과 오류 가능성 감소 YAGNI: 지금 필요 없는 기능은 만들지 않음 간단 예시 모든 옵션을 받는 doSomething(config) 하나로 처리하려는 유혹을 경계. 대신 doSimpleA, doSimpleB처럼 명확한 역할의 작은 함수로 분리하고 기본 동작을 안전하게 설계함. 설정이 꼭 필요할 때만 제한된 형태로 노출 ...

개념/배경 Parameters는 TypeScript가 제공하는 제네릭 유틸리티 타입으로, 특정 함수 타입의 매개변수 타입들을 튜플로 추출하는 데 사용됨 함수 래핑, 고차 함수, 어댑터 계층에서 기존 함수 시그니처를 재사용해 타입 안정성을 유지하고 중복 선언을 줄이는 목적에 적합함 문법 type Parameters<T extends (...args: any) => any> = T extends ( ...args: infer P ) => any ? P : never; T가 함수 타입이면 매개변수 목록을 튜플 타입 P로 추출 T가 함수 타입이 아니면 never 반환 추출 결과는 튜플이므로 인덱스 접근, 스프레드, 부분 적용 등 튜플 연산과 조합 가능 사용 예시 기본 추출 ...

개요 InnoDB 버퍼 풀은 데이터와 인덱스 페이지를 메모리에 캐싱하는 영역임 디스크 I/O를 획기적으로 줄여 지연 시간을 낮추는 게 목적임 InnoDB 스토리지 엔진(트랜잭션, MVCC, 행 단위 락 지원) 성능의 심장부라 할 수 있음 쉽게 말해, 자주 쓰는 데이터와 인덱스를 디스크 대신 메모리에 올려두고 처리하는 구조임 버퍼 풀 구성 요소 버퍼 풀에는 주로 이런 페이지(기본 16KB)가 올라옴 데이터 페이지: 실제 테이블 로우(Row)가 저장된 페이지 인덱스 페이지: B-Tree 인덱스 노드 페이지 (PK 및 세컨더리 인덱스 포함) 기타 관리 페이지: UNDO 페이지, 트랜잭션/MVCC 관리에 필요한 메타데이터 등 핵심 개념 페이지 캐싱 InnoDB는 디스크 데이터를 페이지 단위로 다룸 클라이언트가 특정 로우를 읽고 싶어 하면, 그 로우가 속한 페이지 전체를 버퍼 풀로 가져옴 이후 같은 페이지에 있는 다른 로우를 읽을 때는 디스크를 다시 보지 않고 버퍼 풀(메모리)에서 바로 조회함 ...