유지보수와 확장성을 고려한 HTML/CSS 구조 전략

개요 작은 규칙의 일관성이 유지보수성과 확장성을 만든다고 봄. 아래 세 가지 원칙은 팀 합의만 되면 즉시 적용 가능하며, 코드 리뷰와 리팩터링 부담을 낮추는 효과가 큼 className 네이밍은 하이픈 사용 권장 camelCase, under_score보다 하이픈(-) 기준 분절이 명확해 가독성과 편집성이 좋음. 대소문자 전환 없이 입력 가능해 타이핑 피로도도 낮음 에디터 단어 단위 이동/선택이 직관적. camelCase나 under_score는 하나의 토큰으로 취급되는 경우가 많아 커서 이동이 번거로움. 하이픈은 공백처럼 인식되어 단어 경계 이동이 쉬움. 예시로 sweetPotato, sweet_potato, sweet-potato 비교 추천 ...

February 27, 2026

CQRS 개념과 적용 레벨 정리: 단일 DB 분리부터 이벤트 소싱까지

개요 CQRS(Command and Query Responsibility Segregation)는 쓰기 명령과 읽기 쿼리의 책임을 분리하는 아키텍처 패턴 CQS를 제안한 Bertrand Meyer의 아이디어가 뿌리이고, 실무적 CQRS 패턴을 알린 인물로 Greg Young이 널리 알려짐 핵심은 CUD(Command: Create, Update, Delete)와 R(Query: Read)을 하나의 모델로 처리하지 않고 분리해 복잡도와 결합도를 낮추는 것 왜 분리하는가 전통적인 CRUD 중심 구조에서는 단일 도메인 모델이 쓰기와 읽기 모두를 떠안음 변화 무쌍한 도메인 규칙과 고도화된 UX 요구로 인해 모델이 비대해지고, 유지보수 비용과 리스크가 누적됨 실제 비즈니스 룰과 제약은 쓰기 경로에서 주로 발생하고, 읽기는 상대적으로 단순 조회나 집계 중심인 경우가 많음 두 책임을 하나의 모델로 끌어안으면 불필요한 속성과 검증 로직이 뒤섞여 모델이 설계 의도에서 이탈함 CQRS는 책임을 분리해 각 경로를 그 목적에 맞게 최적화할 수 있게 함 ...

February 26, 2026

SQL Server MERGE로 소스·타깃 동기화하기 패턴과 주의점

개요 MERGE는 소스 테이블과 타깃 테이블을 조인한 결과를 기준으로 삽입·갱신·삭제를 한 번에 처리하는 집합 기반 연산 여러 개의 개별 DML을 하나로 합쳐 실행 횟수와 스캔 비용을 줄이는 것이 목적 테이블 간 차이를 기준으로 동기화가 필요한 배치나 증분 적재 시 유용 핵심 개념 타깃 대상과 소스 입력의 조인 조건 정의 WHEN MATCHED 조건에서 UPDATE 또는 DELETE 수행 WHEN NOT MATCHED BY TARGET 조건에서 타깃에 INSERT 수행 WHEN NOT MATCHED BY SOURCE 조건에서 소스에 없는 타깃 행을 DELETE 등으로 정리하는 패턴 지원 하나의 문장으로 트랜잭션 일관성 유지가 쉬움 기본 문법 필수 요소만 요약 ...

February 25, 2026

리버스 프록시와 포워드 프록시 개념과 차이

개요 프록시 서버는 클라이언트가 자신을 거쳐 다른 네트워크 서비스에 간접 접속하도록 중계하는 시스템을 뜻함 서버와 클라이언트 사이에서 요청과 응답을 대리 처리해 보안성, 성능, 안정성 향상을 노림 프록시는 크게 포워드 프록시와 리버스 프록시로 구분되며, 위치와 목적이 다름 프록시 기본 개념 프록시 서버 정의: 클라이언트와 서버 사이 중계 계층, 요청 위임과 응답 전달 수행 기대 효과: 접근 제어, 캐싱을 통한 지연 감소, SSL/TLS 종료에 따른 오리진 부하 경감, 로드 밸런싱, 익명성 제공 포워드 프록시 포워드 프록시는 클라이언트 앞단에 배치되는 형태를 지칭함 클라이언트는 외부 웹 서버에 직접 연결하지 않고 포워드 프록시로 요청을 보내며, 프록시가 이를 대신 전달하고 응답을 다시 반환함 ...

February 24, 2026

HTML data-* 속성 사용 패턴과 예시

개요 HTML5의 data-* 속성은 마크업에 보이지 않는 커스텀 데이터를 담기 위한 전역 속성 UI와 스크립트 사이 값 전달, 기능 감지 플래그, 간단한 지역화 메타데이터 등에 유용 DOM에서는 element.dataset으로 접근해 읽기/쓰기 가능 핵심 개념 속성명 규칙: data- 접두사 + 소문자 케밥케이스 사용 접근 규칙: data-foo-bar → dataset.fooBar 로 매핑 값 타입: 문자열 저장, 필요 시 직접 직렬화/파싱 처리 필요 보안 유의: 민감정보나 토큰 저장 금지, 노출 전제 데이터만 저장 표준 속성과 역할 혼동 금지, 의미적 데이터는 적절한 속성이나 요소 사용 권장 ...

February 23, 2026

OpenZeppelin contracts-upgradeable로 UUPS·Transparent 프록시 배포와 업그레이드 가이드

개요 OpenZeppelin의 contracts-upgradeable은 업그레이드 가능한 스마트 컨트랙트를 안전하게 구현하기 위한 베이스 라이브러리 프록시 Proxy 패턴으로 사용자 호출 주소와 로직 컨트랙트를 분리하고 delegatecall로 로직을 실행 Transparent Proxy와 UUPS 두 방식을 공식 지원 이 글은 Hardhat 환경에서 @openzeppelin/hardhat-upgrades 플러그인과 함께 UUPS를 중심으로 배포와 업그레이드 흐름을 정리하고, Transparent와의 차이점을 요약 핵심 개념 Proxy 컨트랙트와 Implementation 컨트랙트를 분리하여 배포 사용자는 Proxy 주소로 상호작용, Proxy는 delegatecall로 Implementation의 로직 실행 업그레이드는 Proxy가 가리키는 Implementation 주소를 교체하는 방식 EIP-1967 표준 슬롯을 사용해 Implementation 주소 보관 방식 요약 ...

February 22, 2026

CSS 상대 단위 em과 rem: 기준, 계산, 선택 가이드

개요 반응형 레이아웃과 접근성 요구가 커지면서 px 고정값 대신 em, rem 같은 상대 단위 사용 빈도 증가 두 단위 모두 글꼴 크기(font-size)를 기준으로 동작하지만 기준점이 다름 핵심은 기준이 어디인지 명확히 이해하고 일관된 스케일로 적용하는 것 콘텐츠가 없어도 블록 요소 높이를 유지해야 하는 경우 같은 실무 이슈에서 min-height를 em이나 rem로 정의해 타이포 스케일에 연동하는 방식 유용함 상대 단위 개념 상대(relative) 단위는 주어진 기준에 따라 유동적으로 값이 변하는 길이 단위 em, rem, %, vw, vh 등이 대표 절대(absolute) 단위는 상황과 무관하게 고정된 길이로 취급하는 단위군으로 px, pt, cm, in 등이 포함됨 참고 기준으로 CSS에서 1px는 1/96in에 해당하는 길이로 정의됨. 실제 디바이스의 물리 픽셀과는 분리된 개념 ...

February 21, 2026

robots.txt 기초와 전체 사이트 크롤링 차단 예시

개요 robots.txt는 검색 엔진 크롤러에 대한 크롤링 규칙을 선언하는 공개 텍스트 파일임 사이트 루트 경로에 위치하며 접근 제어나 보안 수단으로 사용 불가 전체 차단 예시 모든 크롤러에 대해 사이트 전체 경로 크롤링 금지 설정 User-agent: * Disallow: / 위 규칙은 크롤링 거부 의사를 표명하는 표준 관례이며 비준수 크롤러까지 강제 불가 주의 운영 환경 적용 시 검색 트래픽 전면 차단 위험 크롤링 차단과 인덱싱 차단은 다름 이미 색인된 문서는 별도 제거 절차 필요 ...

February 20, 2026

Foreign Key 컬럼은 NULL을 가질 수 있는가

개념/배경 결론부터 말하면 가능함 Foreign Key 컬럼의 NULL 허용 여부는 해당 컬럼의 NULL 혹은 NOT NULL 제약으로 결정됨 FK 제약은 NULL이 아닌 값만 검증하므로 값이 NULL인 경우 참조 무결성 검사를 생략함 컬럼이 NOT NULL이면 NULL 저장 불가 컬럼이 NULL 허용이면 NULL 저장 가능 핵심 개념 FK 제약은 입력값이 존재할 때만 참조 대상 테이블에 키가 있는지 검사 NULL은 미지정 상태로 간주되어 검증 대상 아님 대부분의 RDBMS에서 기본은 NULL 허용 컬럼이며, 명시적으로 NOT NULL을 지정해야 함 동작 원리 INSERT 또는 UPDATE 시 FK 컬럼이 NULL이면 무결성 검사 스킵 값이 존재하면 참조 테이블의 대상 키 존재 여부 검사 복합 FK의 경우 참조 컬럼 중 하나라도 NULL이면 전체 FK 검사를 생략하는 동작이 일반적임 간단 예시 CREATE TABLE parent ( id INT PRIMARY KEY ); CREATE TABLE child ( parent_id INT, FOREIGN KEY (parent_id) REFERENCES parent(id) ); child.parent_id는 기본적으로 NULL 허용 상태 parent_id에 NULL을 넣어도 FK 위반 아님 parent_id에 NOT NULL을 추가하면 parent에 존재하는 id만 허용됨 주의 사항 ON DELETE SET NULL을 사용할 경우 FK 컬럼이 NULL 허용이어야 함 FK 컬럼 인덱스는 필수는 아니나 삭제·업데이트 시 성능과 잠금 범위 측면에서 권장 관계가 필수라면 애플리케이션 규칙이 아닌 스키마에서 NOT NULL로 모델링하는 편이 안전함 마무리 FK 컬럼은 NULL 허용 설정이면 NULL을 저장할 수 있으며, 이 경우 FK 검사는 수행되지 않음 NULL을 금지하고 참조 무결성을 강제하려면 NOT NULL을 함께 적용하면 됨 ...

February 19, 2026

JavaScript에서 unary plus(+)와 parseInt 비교 및 선택 기준

개요 자바스크립트에서 + 단항 연산자는 Number 호출의 축약형으로 동작함 문자열이나 다양한 타입을 숫자로 바꾸려는 순간에 +value와 Number(value)는 같은 의미이고, parseInt는 문자열에서 정수 접두부만 뽑아내는 파서에 가까움 같아 보이지만 목적과 실패 조건이 다르므로 상황에 맞게 선택 필요 핵심 개념 unary plus +x ECMAScript의 ToNumber 규칙 적용 Number(x)와 동일한 변환 결과 반환 Number(value) 숫자 전체 표현식이어야 함 공백 트림은 허용하지만 유효하지 않은 문자가 섞이면 NaN 반환 parseInt(string, radix) 문자열의 왼쪽부터 주어진 기수(radix, 2~36)로 해석 가능한 정수 접두부만 파싱 유효하지 않은 문자를 만나면 거기서 파싱 중단 접두부 숫자가 하나도 없으면 NaN 반환 ES5+에서 기본 기수는 10이지만, 0x/0X 접두사는 16진수로 처리됨 동작 차이와 사례 전체 일치 vs 접두 파싱 Number('12px') → NaN parseInt('12px', 10) → 12 소수와 지수 표기 Number('10.5') → 10.5, Number('1e3') → 1000 parseInt('10.5', 10) → 10 (소수부 절삭) 빈 문자열과 공백 Number('') → 0, Number(' ') → 0 parseInt('') → NaN 비문자열 입력 +true → 1, +false → 0, +null → 0, +undefined → NaN parseInt(true, 10) → NaN (문자열로 변환 시 ’true’라서 숫자 접두부 없음) 진법 접두사 처리 차이 Number('0x10') → 16, parseInt('0x10') → 16 Number('0b101') → 5 (ES2015+), parseInt('0b101') → 0 참고로 parseInt('101', 2) → 5 처럼 radix를 명시해야 기대대로 동작함 BigInt 관련 +10n은 TypeError 발생 Number(10n)은 10으로 변환되나 정밀도 손실 가능성 존재 선택 기준 전체 문자열이 유효한 숫자여야 하고 실수, 지수 표기도 허용해야 함 +value 또는 Number(value) 선택 가독성 우선이면 Number(value) 추천, 축약을 선호하면 +value 선택 문자열 앞부분에서 정수만 뽑고 싶거나 비 10진수 파싱 필요 parseInt(str, radix) 선택 항상 radix 명시 권장 소수부를 보존하면서 부분 파싱이 필요 parseFloat 고려 다만 parseFloat도 접두 파싱이므로 전체 일치 검증이 필요하면 Number 사용 권장 베스트 프랙티스 숫자 변환 의도 전달이 중요할 때 Number(value) 사용 정수 파싱 시 parseInt(str, 10)처럼 radix를 항상 명시 사용자 입력 검증이 필요하면 정규식 또는 스키마 검증으로 전체 형식 검증 후 Number 변환 성능 미세 최적화보다 가독성과 실패 조건의 명확성을 우선 간단 예시 Number('12') // 12 +'12' // 12 parseInt('12',10) // 12 Number('12px') // NaN parseInt('12px',10) // 12 Number('0b101') // 5 parseInt('0b101') // 0, radix 명시 필요 parseInt('101', 2) // 5 결론 +는 Number의 축약형이 맞음 전체 숫자 표현식으로서의 유효성을 요구할 때 + 또는 Number 사용, 접두부 정수 추출이나 진법 파싱에는 parseInt 사용 의도를 코드에 드러내고, 실패 조건을 일관되게 가져가는 쪽으로 선택하는 것이 유지보수에 유리함 ...

February 18, 2026