개요 Kubernetes에서 Taints는 노드에 거는 출입 제한 설정이고 Tolerations는 파드가 가진 출입 허용 키에 해당함 이 조합으로 스케줄러가 특정 파드를 특정 노드에서 배제하거나 허용하도록 제어 가능 비용이 높은 노드 보호, 장애 노드 격리, 점검 중 노드 비우기 같은 운영 시나리오에서 효과적임 비유로 이해하기 노드가 VIP 라운지, Taint는 라운지 입구의 안내 표지, 파드는 손님, Toleration은 출입증에 해당함 Taint가 있는 노드에는 아무 파드나 배치되지 않음 해당 Taint를 허용하는 Toleration을 가진 파드만 스케줄링 가능 ...
개념과 배경 배열을 무작위로 섞을 때 Array.prototype.sort와 Math.random을 조합한 패턴이 흔히 보임 array.sort(() => Math.random() - 0.5) 형태는 간단해 보이지만 결과 분포가 한쪽으로 치우치는 편향이 발생함 간단한 실험으로 [1, 2, 3]을 백만 회 섞어 빈도를 집계해 보면 특정 순열이 과도하게 많이 나오거나 적게 나오는 경향 관찰됨 핵심은 Math.random 자체보다 sort에 전달된 비교 함수가 랜덤하게 일관성 없이 값을 내놓는 구조라는 점임 왜 sort + random이 편향되는가 정렬 알고리즘은 비교 함수가 다음 성질을 만족한다고 가정함 ...
개요 쿠버네티스는 명령을 조율하는 Control Plane과 실제 워크로드가 실행되는 Data Plane으로 구성됨 각 컴포넌트의 역할과 흐름을 이해하면 트러블슈팅, 성능 최적화, 보안 구성에 필요한 기준이 생김 클라우드 매니지드 쿠버네티스의 경우 Control Plane은 보통 제공자가 관리하지만 동작 원리 이해는 필수 Control Plane API Server 클러스터 유일 진입점 모든 컴포넌트와 사용자는 API Server를 통해 통신 인증과 권한 확인 수행 etcd 클러스터 상태와 스펙을 보관하는 분산 키밸류 저장소 API Server만 직접 접근 가능 상태 복구의 근간이 되는 데이터 원장 Scheduler ...
개요 객체는 만능처럼 보이지만 모든 키-값 저장에 적합한 도구는 아님 키를 자주 추가·삭제하고 임의 키로 조회하는 해시맵 유사 패턴에서는 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 ...