개요 객체는 만능처럼 보이지만 모든 키-값 저장에 적합한 도구는 아님 키를 자주 추가·삭제하고 임의 키로 조회하는 해시맵 유사 패턴에서는 Map이 더 안전하고 일관된 성능을 제공함 중복 없는 집합 연산에는 Set이 자연스러운 선택지 언제 객체 대신 Map을 고려할까 키를 자주 추가·삭제하는 동적 해시맵 패턴 안전한 반복과 구조 분해가 필요한 경우 키의 삽입 순서 유지가 중요한 경우 비문자열 키가 필요한 경우 // 객체 기반 임의 키-값 해시맵 패턴은 delete에서 성능 불리할 수 있음 const mapOfThingsObj = {}; mapOfThingsObj[thing.id] = thing; delete mapOfThingsObj[thing.id]; // Map은 동적 추가·삭제에 최적화 const mapOfThings = new Map(); mapOfThings.set(thing.id, thing); mapOfThings.delete(thing.id);성능 배경 객체는 VM이 숨은 클래스/셰이프를 가정해 최적화하는 경향이 있어 구조가 변동하면 디옵티마이즈 유발 가능성 존재 Map은 해시맵 사용에 맞춰 키 추가·삭제가 빈번한 경우를 목표로 설계됨 마이크로벤치마크는 한계가 있으므로 실제 워크로드에서 측정 권장, 다만 Map이 해당 패턴에 맞춰 설계된 점은 문서로 확인 가능 ...

개요 signTypedData는 EIP-712 표준을 구현한 서명 메서드로 구조화된 데이터에 서명하기 위한 표준 인터페이스를 제공함 지갑은 사람이 읽을 수 있는 형태로 서명 내용을 표시하고, 서명은 특정 도메인과 체인에 귀속되어 재사용 공격을 줄임 signTypedData와 EIP-712의 관계 정의 signTypedData는 EIP-712 규격을 따르는 구조화 데이터 서명 메서드 이더리움 지갑 및 제공자에서 eth_signTypedData, eth_signTypedData_v3, eth_signTypedData_v4 형태로 노출 버전 signTypedData 최초 버전 signTypedData_v3 signTypedData_v4 가장 널리 사용되는 최신 버전 라이브러리 사용 ethers에서는 _signTypedData로 제공 const signature = await signer._signTypedData(domain, types, value) 지갑 연동은 일반적으로 provider에 직접 요청하는 방식 사용 const signature = await ethereum.request({ method: 'eth_signTypedData_v4', params: [account, JSON.stringify({ domain, types, message: value })], })동작 원리 요약 타입화된 구조체 정의 예시 구조체와 필드 타입을 정형화해 명세 도메인 분리자 사용 이름, 버전, 체인 ID, 검증 컨트랙트 주소를 포함해 서명 범위 고정 타입 해시와 데이터 해시 생성 타입 정의를 keccak256으로 해싱 후 데이터 인코딩 해시 생성 최종 해시에 서명 및 검증 지갑에서 서명 생성, 컨트랙트에서 도메인과 타입을 동일하게 재현해 검증 사용 예시 간단한 도메인, 타입, 메시지 구성 예시 const domain = { name: 'MyApp', version: '1', chainId, verifyingContract } const types = { Action: [ { name: 'user', type: 'address' }, { name: 'amount', type: 'uint256' } ] } const value = { user: userAddress, amount } // ethers 서명 const sig = await signer._signTypedData(domain, types, value) // 지갑 요청 v4 서명 const sig2 = await ethereum.request({ method: 'eth_signTypedData_v4', params: [account, JSON.stringify({ domain, types, message: value })], }) 컨트랙트 검증 예시 요약 // OpenZeppelin EIP712, ECDSA 사용 가정 bytes32 digest = _hashTypedDataV4( keccak256(abi.encode( keccak256("Action(address user,uint256 amount)"), user, amount )) ) require(ECDSA.recover(digest, signature) == signer, "Invalid signature")EIP-712 핵심 개념 정리 목적 사람이 읽을 수 있는 서명 메시지 제공 도메인에 귀속된 서명으로 리플레이 공격 저감 구조 타입화된 데이터 스키마와 도메인 분리자 타입 해시와 데이터 해시를 조합한 최종 해시 장점 지갑 UI에서 의미 있는 정보 노출로 UX 개선 다른 dApp이나 체인에서 재사용 어려움으로 보안 강화 주의사항과 팁 v4 사용 권장 v4는 가장 널리 지원되고 구조체 및 배열 표현이 안정적임 provider 요청 방식 web3 라이브러리 함수보다 ethereum.request의 eth_signTypedData_v4 사용이 호환성 측면에서 안전함 타입 정의 일치 컨트랙트와 클라이언트의 타입 이름, 필드 순서, 정수 크기 등 완전 일치 필요 도메인 정합성 chainId와 verifyingContract가 실제 네트워크와 배포 주소와 일치해야 검증 성공 데이터 인코딩 JS 측 정수값은 문자열 또는 BigNumber 형태 사용 권장, 오버플로와 반올림 이슈 회피 ethers 사용 시 types에 EIP712Domain을 포함하지 않음, _signTypedData가 도메인을 별도로 처리함 v4 메시지 포맷 params에 JSON.stringify로 { domain, types, message } 형태 전달 필요 마무리 signTypedData는 곧 EIP-712 사용을 의미하며 구조화된 데이터에 대한 안전한 서명을 가능하게 함 ethers의 _signTypedData 또는 지갑의 eth_signTypedData_v4를 사용해 서명하고, 컨트랙트에서는 동일한 도메인과 타입으로 해시를 재현해 검증하면 됨 명세 일치와 도메인 정합성만 확보하면 안전하고 예측 가능한 서명 흐름을 구현 가능 ...

개요 NestJS는 대규모 서버 애플리케이션을 위한 구조화된 Node.js 프레임워크임 핵심은 Angular 스타일의 아키텍처, 강력한 의존성 주입 컨테이너, 데코레이터 기반 메타프로그래밍 조합 팀 규모가 커질수록 일관성과 유지보수성이 살아나는 타입스크립트 퍼스트 선택지임 구조적 강제의 이점 Nest는 모듈 Module, 컨트롤러 Controller, 서비스 Service 구조를 강제함 계층 분리 패턴 BLL, DAL, 도메인 레이어 등 적용 용이 아키텍처가 일관되게 유지되어 4~10명 규모 팀에서 코드 스타일과 책임 경계가 흐트러지지 않음 Fastify, Express 같은 미니멀 프레임워크 대비 생산성과 일관성 측면에서 팀 단위 효율 우위 ...

개요 개발 현장은 기술 변화가 빠르고 학습 범위가 넓음 이 환경에서 임포스터 증후군과 우월감 증후군은 자주 관찰되는 심리 상태이며, 같은 사람이 커리어 단계에 따라 두 상태를 오가기도 함 핵심 개념과 개발자 맥락에서의 징후, 발생 배경, 성장 곡선 상의 위치, 건강한 마인드셋을 정리함 핵심 개념 임포스터 증후군 스스로 실력을 과소평가하고 운이나 타인의 공 덕분에 현재 위치에 있다고 여기는 불안 심리 들킬 것 같은 두려움이 동반됨 개발자 맥락에서 보이는 징후 구글링 의존을 부끄러워하며 자신을 가짜 개발자로 규정함 성과를 팀 운이나 외부 요인으로만 해석함 질문을 회피하고 비난을 두려워해 홀로 고립됨 더 알수록 모르는 영역이 보이며 시니어가 되어도 불안 증가 우월감 증후군 ...

개요 자바스크립트에서 날짜·시간을 다루는 일은 사소해 보이지만 버그가 가장 잦은 영역 중 하나임 day.js, moment.js, luxon 등 대안 존재하나 date-fns는 모듈화, 작은 크기, 불변성 중심 설계로 프런트엔드와 백엔드 모두에 적합함 아래는 date-fns와 date-fns-tz를 활용해 바로 써먹을 수 있는 23가지 패턴 정리 핵심 개념 Date 객체는 타임존이 아닌 UTC 타임스탬프를 보유하는 값이라는 점이 핵심 date-fns 함수는 대부분 불변 동작, 인자로 받은 Date를 변경하지 않음 포맷팅은 format, 상대 표기는 formatDistance 계열, 구간 계산은 differenceIn*, intervalToDuration 등 사용 파싱은 parseISO 또는 parse로 명시적 포맷 지정 권장 타임존 변환은 date-fns-tz의 utcToZonedTime, zonedTimeToUtc, formatInTimeZone 사용 실전 패턴 현재 날짜와 시간 가져오기 const now = new Date() 특정 날짜·시간 설정 import { setMinutes, setHours } from 'date-fns' const specific = setHours(setMinutes(new Date(), 30), 17) // 17:30 날짜 포맷팅 import { format } from 'date-fns' const ymd = format(new Date(), 'yyyy-MM-dd') 기간 더하기·빼기 import { addDays, subMonths } from 'date-fns' const inAWeek = addDays(new Date(), 7) const aMonthAgo = subMonths(new Date(), 1) 특정 요일까지 남은 일수 import { nextDay, differenceInDays } from 'date-fns' const nextMon = nextDay(new Date(), 1) // 0 일요일, 1 월요일 const d = differenceInDays(nextMon, new Date()) 두 날짜 차이 계산 import { differenceInDays } from 'date-fns' const diff = differenceInDays(new Date(2023, 11, 31), new Date(2023, 0, 1)) 동일한 날짜 비교 import { isSameDay } from 'date-fns' const same = isSameDay(new Date(2023, 0, 1), new Date('2023-01-01T05:00:00Z')) 윤년 확인 import { isLeapYear } from 'date-fns' const isLeap = isLeapYear(new Date(2024, 0, 1)) 날짜 유효성 검사 import { isValid } from 'date-fns' const ok = isValid(new Date('2023-02-30')) // false 로컬과 특정 타임존 간 변환 import { utcToZonedTime, zonedTimeToUtc, formatInTimeZone } from 'date-fns-tz' const tz = 'America/New_York' const utc = zonedTimeToUtc(new Date(), tz) const inNY = utcToZonedTime(new Date(), tz) const shown = formatInTimeZone(new Date(), tz, 'yyyy-MM-dd HH:mm:ssXXX') 문자열 파싱 import { parseISO, parse } from 'date-fns' const a = parseISO('2023-01-01') const b = parse('01/02/2023 17:30', 'MM/dd/yyyy HH:mm', new Date()) 상대 시간 표현 import { formatDistanceToNow } from 'date-fns' import { ko } from 'date-fns/locale' const rel = formatDistanceToNow(new Date(Date.now() - 3 * 24 * 60 * 60 * 1000), { addSuffix: true, locale: ko }) 과거·미래 판별 import { isPast, isFuture } from 'date-fns' const past = isPast(new Date('2023-01-01')) const future = isFuture(new Date(Date.now() + 60_000)) 특정 기간의 날짜 배열 생성 루프 대신 eachDayOfInterval 사용 권장 ...

개요 Node.js에서 CommonJS(CJS)와 ESM(ES Modules)은 공존 상태이며, 신규 프로젝트는 ESM으로 전환되는 추세임. 두 시스템의 차이를 이해하면 번들 크기, 로딩 성능, 정적 분석, 생태계 호환에서 불필요한 시행착오 감소 가능 배경 2009년 Node.js는 표준 모듈 시스템이 없던 시기라 CommonJS 채택 2015년 ES6에서 ESM이 언어 차원의 공식 표준으로 확정 2020년대 들어 Node.js가 ESM을 정식 지원, 브라우저와 규약 수렴 진행 CommonJS 요약 // export module.exports = { foo: 1 } exports.bar = 2 // import const { foo, bar } = require('./utils')특성 ...

개요 EVM 트랜잭션 수수료 모델은 자동차 연료 비유가 직관적임 Gas는 연료, 트랜잭션 수행은 목적지까지 주행이라는 맥락으로 이해하면 됨 핵심은 두 파라미터, Gas Limit와 Gas Price이며 EIP-1559 이후에는 Base Fee와 Priority Fee로 세분됨 핵심 개념 Gas Limit 이 트랜잭션이 최대 얼마만큼의 연산을 사용할 수 있는지에 대한 상한 단순 ETH 송금은 21,000 가스 고정값 수준 컨트랙트 실행은 로직 복잡도, 저장소 접근, 반복 등에 비례해 증가 사용하지 않은 가스는 환불, 부족하면 Out of Gas로 실패 후 사용한 가스 비용만큼 청구 Gas Price ...

개요 테이블 검색 성능을 끌어올리는 1차 수단은 인덱스 구축임 인덱스는 단일 컬럼 또는 다중 컬럼 기준으로 생성 가능하며, 다음과 같은 기본 생성 규칙이 작동함 Primary Key 지정 시 클러스터드 인덱스 생성 Unique 제약은 보조 인덱스(논클러스터드 인덱스, InnoDB에선 Secondary Index)로 생성 MySQL의 InnoDB는 B+Tree 기반 인덱스를 사용하며, 데이터 저장 구조와 접근 패턴이 인덱스 유형별로 상이함 핵심 개념 정리 클러스터드 인덱스 테이블 데이터가 인덱스 키 순서로 정리되는 구조 테이블당 하나만 존재 리프 노드가 실제 레코드(전체 컬럼)를 보유 InnoDB에서 Primary Key가 곧 클러스터드 인덱스가 됨 PK가 없으면 첫 번째 유니크 not null 인덱스를 사용, 그것도 없으면 내부적으로 보이지 않는 6바이트 Row ID를 생성해 클러스터링 키로 사용 논클러스터드 인덱스(보조 인덱스, Secondary Index) ...

개념과 배경 마이크로서비스로 분산이 심화되면 로깅, 모니터링, 보안, 네트워킹 같은 공통 기능을 어디에 둘지 결정이 어려워짐 애플리케이션 코드에 공통 기능을 계속 끼워 넣으면 침투와 중복 증가, 배포와 버전 관리 복잡도 상승 사이드카 패턴은 공통 기능을 별도 컨테이너로 분리해 메인 서비스는 비즈니스 로직에 집중하게 하는 접근법 컨테이너 오케스트레이션 환경에서 일관된 운영 모델을 제공한다는 점이 실무적 장점 핵심 개념 사이드카 패턴의 구성 요소 메인 컨테이너: 비즈니스 로직 담당, 웹 서비스나 API 서버 등 사이드카 컨테이너: 횡단 관심사 처리, 로그 수집, 모니터링 에이전트, 프록시, 보안 검사 등 같은 파드 내 배치로 네트워크 네임스페이스와 볼륨 공유 가능, 표준 출력/공유 볼륨 등을 통해 데이터 연계 업데이트와 배포를 컨테이너 단위로 분리해 독립적 버전 관리 가능 동작 원리 하나의 파드에 메인 컨테이너와 사이드카 컨테이너를 함께 배치 ...

개념/배경 Node.js 프로세스 레벨에서 잡히지 않은 에러를 마지막으로 처리하는 안전망을 두는 목적 정리 애플리케이션 어디에서도 처리되지 못한 오류를 기록하고 종료 경로를 일관되게 관리하기 위함 프로덕션 환경에서 원인 파악과 사후 조치 자동화를 위한 최소 장치로 간주 핵심 이벤트 두 가지 이벤트가 글로벌 핸들러의 대상 uncaughtException try-catch로 포착되지 않은 동기 오류가 호출 스택 끝까지 전파될 때 발생 핸들러가 없으면 프로세스가 비정상 종료됨 // 동기 에러가 상위에서 잡히지 않은 경우 function boom() { throw new Error('폭발') } boom() unhandledRejection Promise가 reject되었으나 await 혹은 .catch로 처리되지 않은 경우 발생 Node.js 15+ 기본 동작은 핸들러가 없을 때 프로세스 종료 // reject가 소비되지 않은 경우 async function asyncBoom() { throw new Error('비동기 폭발') } asyncBoom()왜 글로벌 핸들러인가 코드 최상위에서 아무도 잡지 못한 에러에 대한 마지막 안전망 역할 ...