Posts

개요 슬리피지(slippage)는 내가 예상한 가격과 실제 체결 가격의 차이를 의미함 분산형 거래소 환경에서는 블록 포함 지연과 유동성 구조 때문에 발생 빈도가 높음 슬리피지가 발생하는 이유 유동성 부족 특정 토큰 페어의 유동성 풀이 얕으면 작은 주문에도 가격 영향 커짐 대량 주문 시장 규모 대비 큰 금액을 한 번에 실행 시 풀 내 토큰 비율이 급격히 변해 체결 평균가가 악화됨 시장 변동성 트랜잭션 제출 시점과 블록에 포함되는 시점 사이 외부 가격 급변으로 기대 가격과 괴리 발생 AMM에서의 동작 대부분의 DEX는 AMM을 사용하며 풀 내 두 토큰의 비율로 가격이 정해짐. 단순화된 상수곱 x·y=k 모델 기준으로 설명함 ...

개요 테이블 이름 변경은 ALTER TABLE로도 가능하지만, RENAME TABLE을 쓰면 다수 테이블을 한 번에 처리 가능하며 같은 서버 내 다른 데이터베이스로 이동까지 가능함 핵심 차이 ALTER TABLE RENAME은 단일 테이블 대상 RENAME TABLE은 여러 테이블을 한 문장으로 변경 가능 스키마 간 이동 지원 current_db.table에서 other_db.table로 변경 가능 동일 트랜잭션처럼 동작하는 원자성 제공, 다중 변경 중 하나라도 실패 시 전체 미적용 권한 요구 사항 존재, 원본 테이블에 ALTER와 DROP, 대상 스키마에 CREATE 권한 필요 트리거와 외래키 메타데이터는 함께 유지되나, 뷰나 저장 프로시저의 하드코딩된 참조는 자동 갱신되지 않음 사용법 단일 테이블 이름 변경 RENAME TABLE old_table TO new_table; 단일 테이블 이름 변경 ALTER 사용 ALTER TABLE old_table RENAME new_table; 다수 테이블 이름 일괄 변경 RENAME TABLE old_table1 TO new_table1, old_table2 TO new_table2, old_table3 TO new_table3; 다른 데이터베이스로 이동 같은 서버 내 RENAME TABLE current_db.table_name TO other_db.table_name;주의 사항 대상 이름이 이미 존재하면 실패 교차 서버 이동 불가, 같은 서버 인스턴스 내 스키마 간 이동만 가능 실행 시 메타데이터 락 획득, 짧은 구간 동안 읽기나 쓰기 대기 가능 배치 변경 전 사전 검증 권장, 이름 충돌 여부와 권한 확인 뷰나 프로시저 참조는 수동 점검 필요, 린트나 간단한 탐색 쿼리로 영향 범위 확인 권장 정리 단일 변경만 필요하면 ALTER로 충분하나, 다수 변경이나 스키마 이동까지 고려하면 RENAME TABLE이 더 실용적 선택 원자적 일괄 변경과 스키마 간 이동을 활용하되, 권한과 의존성 영향 검증을 선행할 것 ...

개요 Prisma로 관계형 데이터베이스를 다루다 보면 자연스럽게 드는 질문이 있음 Prisma에서는 JOIN이 어디로 갔나 하는 질문임 개발자가 작성하는 Prisma Client API에는 JOIN이 없고, 서브쿼리도 보이지 않음 정말로 없는지, 없다면 왜 그런지, 어떤 트레이드오프가 있는지 정리함 ORM이란 무엇인가 ORM은 객체와 관계형 데이터베이스 간의 매핑을 제공하는 아이디어이자 구현체 집합을 의미함 애플리케이션에서 모델을 통해 데이터베이스 테이블을 간접 제어하는 추상화 계층 제공 SQL을 직접 작성하지 않고 데이터 접근 로직을 일관된 API로 수행 가능 데이터베이스 의존성 완화 효과 기대 ...

개요 여러 비동기 작업을 한 번에 묶어 처리하거나 결과를 모아야 하는 경우가 잦음 키-값 기반으로 데이터를 구조화해 저장하고 순회해야 하는 요구도 흔함 이 글은 Promise.all의 동작과 주의점, Map의 핵심 사용법을 개발자 관점에서 요약 정리함 Promise.all 개념과 정의 여러 Promise를 단일 Promise로 집계하는 유틸리티 모든 입력이 이행되면 결과를 같은 순서의 배열로 반환 하나라도 거부되면 즉시 거부로 끝나는 fail fast 특성 보유 입력은 Promise와 값 혼합 가능하며 값은 내부적으로 Promise.resolve로 이행 처리됨 ...

개요 MECE는 Mutually Exclusive Collectively Exhaustive의 약자이며 상호배제와 전체포괄을 뜻함 겹치지 않게 나누되 합치면 전체가 되는 분류 원칙을 말함 영어권에서는 미씨로 읽고, 한국어로는 엠이씨이 또는 미시로 불림 컨설팅 실무에서 대중화된 사고 틀로 문제 분해, 요건 정의, 케이스 분류에 자주 사용됨 개념과 정의 상호배제는 요소들이 서로 겹치지 않는 상태를 의미함 중복 없이 하나의 요소가 정확히 하나의 범주에만 속함 전체포괄은 분류된 요소들을 모두 합치면 전체 모수를 빠짐없이 덮는 상태를 의미함 누락 없이 전체 공간을 커버하는 분할이 목표임 ...

관계형 데이터에서 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, 내부 바인딩 계층이 초기화되고 런타임 전역 상태가 준비됨 ...