전체 글 (34) 썸네일형 리스트형 [CSS] 색상과 배경 다루기 (Gradients & Multi-bg) 이번 포스팅에서는 [CSS 디자인] 파트의 세부 주제인 색상 심화 및 그라디언트 활용법에 대하여 상세히 알아보겠습니다.1. RGB vs HSL: 색상 보정의 마법사 HSL실무에서 HEX나 RGB를 많이 쓰지만, 버튼의 hover 상태(조금 더 어둡게)나 시스템 테마를 구성할 때는 hsl()이 압도적으로 편리합니다. 명도(Lightness) 수치만 살짝 조절하면 되기 때문입니다..btn-primary { /* H: 210(파랑), S: 100%, L: 50% */ background-color: hsl(210, 100%, 50%);}.btn-primary:hover { /* 색상과 채도는 유지하고 명도만 40%로 낮춰 어둡게 처리! */ background-color: hsl(210, 100%, 4.. [CSS] 실무 단위 정복 (px, em, rem, vh, vw) 이번 포스팅에서는 [CSS 기초] 파트의 세부 주제인 실무 단위 활용법에 대하여 상세히 알아보겠습니다.1. rem과 em의 차이점 및 적재적소 활용법px은 절대 단위이므로 접근성(사용자 폰트 크기 변경)에 취약합니다. 실무에서는 주로 상대 단위인 rem과 em을 혼합하여 사용합니다.rem (Root em): 최상위 요소의 폰트 사이즈(기본 16px)를 기준으로 합니다. 전체적인 타이포그래피, 여백, 컴포넌트 간격 설정에 가장 안전하게 쓰입니다.em: 자기 자신 혹은 부모의 폰트 사이즈를 기준으로 합니다. 컴포넌트 내에서 폰트 크기에 비례해 아이콘 크기나 padding이 유동적으로 변해야 할 때(예: 버튼 크기별 변형) 강력한 힘을 발휘합니다.2. 모바일 브라우저의 골칫거리 vh 단위 해결 노하우모바일 .. [CSS] Box Model 완벽 가이드와 마진 병합 현상 이번 포스팅에서는 [CSS 기초] 파트의 세부 주제인 Box Model과 실무 트러블슈팅에 대하여 상세히 알아보겠습니다.1. 실무 필수 설정: box-sizing: border-box디폴트 박스 모델인 content-box는 width 지정 후 padding을 주면 요소의 전체 크기가 커지는 문제가 있습니다. 퍼블리싱 시 제일 먼저 설정해야 하는 글로벌 룰입니다./* CSS 리셋의 기본: 모든 요소에 border-box 적용하기 */*, *::before, *::after { box-sizing: border-box;}2. 마진 병합(Margin Collapsing) 현상 타파하기인접한 블록 요소의 상하 마진이 만날 때, 두 마진 중 더 큰 값 하나로 합쳐지는 현상입니다. 이로 인해 레이아웃이 예상과 .. [CSS] CSS 기초 문법과 고급 선택자 (Selectors) 이번 포스팅에서는 [CSS 기초] 파트의 세부 주제인 CSS 기초 문법과 고급 선택자에 대하여 상세히 알아보겠습니다.1. 명시도(Specificity) 점수 계산의 비밀CSS를 작성하다 보면 내가 작성한 스타일이 무시되는 명시도(Specificity) 충돌 현상을 자주 겪습니다. 실무에서는 명시도 계산을 정확히 이해해야 !important를 남발하는 지저분한 코드를 방지할 수 있습니다.인라인 스타일 (1000점): 형태로 HTML 내에 직접 작성 (가장 강력함)ID 선택자 (100점): #header클래스, 가상 클래스, 속성 선택자 (10점): .btn, :hover, [type="text"]요소(태그) 선택자 (1점): div, p, ::before2. 고급 선택자로 HTML 구조 수정 없이 스타일.. [GIT] Git 자동화 스크립트 (Hooks & Husky) 이번 포스팅에서는 [생산성 향상 & 팁] 파트의 세부 주제인 Git 자동화 스크립트 (Hooks & Husky)에 대하여 상세히 알아보겠습니다.1. Git Hooks의 원리Git Hooks는 데이터베이스의 트리거(Trigger)처럼, commit, push, merge 등의 특정한 Git 이벤트가 발생하기 직전(pre) 또는 직후(post)에 사용자가 정의한 쉘 스크립트가 자동으로 실행되도록 하는 훅(Hook) 매커니즘입니다. 이를 통해 빌드 에러가 나는 코드나 코드 컨벤션(Lint)을 지키지 않은 코드가 아예 커밋되지 못하도록 원천 차단할 수 있습니다.2. 프론트엔드 환경에서의 Husky 도입Git 내장 Hooks는 쉘 스크립트로 작성해야 하고 동료들에게 공유하기 까다롭다는 단점이 있습니다. JavaS.. [GIT] 명령어 단축어(Alias)로 생산성 극대화 이번 포스팅에서는 [생산성 향상 & 팁] 파트의 세부 주제인 명령어 단축어(Alias)로 생산성 극대화에 대하여 상세히 알아보겠습니다.1. Alias의 강력함개발을 하다 보면 하루에도 수십 번씩 git status, git checkout 등의 명령어를 타이핑하게 됩니다. Git은 이러한 명령어들을 자신이 원하는 짧은 단어로 축약(Alias)하여 사용할 수 있는 자체 설정 기능을 제공합니다.2. 추천 Alias 설정 목록아래의 명령어들을 터미널에 한 번씩만 입력해 두면, 영구적으로 축약어를 사용할 수 있습니다.# 기본 명령어 축약$ git config --global alias.st status$ git config --global alias.co checkout$ git config --global a.. [GIT] 프로페셔널한 커밋 메시지 작성 가이드 이번 포스팅에서는 [생산성 향상 & 팁] 파트의 세부 주제인 프로페셔널한 커밋 메시지 작성 가이드에 대하여 상세히 알아보겠습니다.1. 커밋 메시지는 문서다자신이 작성한 코드를 6개월 뒤에 다시 보거나, 다른 동료가 인수인계를 받을 때 가장 먼저 들여다보는 것이 바로 커밋 메시지 이력입니다. 코드의 '변경 내용(How)'은 소스 코드의 diff를 통해 알 수 있지만, '변경 이유(Why)'는 오직 커밋 메시지를 통해서만 파악할 수 있습니다.2. Conventional Commits 규약오픈소스 커뮤니티를 중심으로 정립된 규약으로, 머리말(Prefix)을 달아 커밋의 성격을 직관적으로 분류하는 방식입니다. 자동화된 릴리스 노트 작성 도구 등과 연동하기에도 매우 유리합니다.feat: 어플리케이션에 새로운 기능.. [GIT] 성공적인 협업을 위한 필수 권장 사항 이번 포스팅에서는 [협업 워크플로우] 파트의 세부 주제인 성공적인 협업을 위한 필수 권장 사항에 대하여 상세히 알아보겠습니다.1. 출근 후 첫 작업은 최신화부터로컬 컴퓨터에서 코드 작성을 시작하기 전, 습관적으로 git pull을 수행하여 메인 브랜치의 최신 상태를 로컬과 동기화해야 합니다. 하루 이틀 동기화를 미룬 채 구버전 코드 위에서 작업하다 보면, 추후 병합 시 감당할 수 없는 엄청난 충돌(Conflict) 폭탄을 맞게 됩니다.2. Pull 시 Rebase 옵션 활용 (선택적)일반적인 git pull은 원격의 변경 사항과 로컬의 변경 사항을 섞으면서 불필요한 'Merge Commit'을 무수히 생성하게 됩니다. 이를 방지하고 히스토리를 선형으로 깔끔하게 유지하기 위해 rebase 옵션을 사용할 수.. [GIT] 저장소 안의 저장소 (Submodule) 이번 포스팅에서는 [협업 워크플로우] 파트의 세부 주제인 저장소 안의 저장소 (Submodule)에 대하여 상세히 알아보겠습니다.1. 서브모듈(Submodule)의 개념여러 개의 마이크로서비스 프로젝트나 다양한 프론트엔드 프로젝트에서 공통적으로 사용하는 핵심 라이브러리 코드가 있다고 가정해 보겠습니다. 코드를 복사해서 붙여넣는 방식은 유지보수 측면에서 재앙에 가깝습니다. Git 서브모듈은 하나의 상위 Git 저장소 내부에 완전히 독립된 다른 Git 저장소를 하위 디렉토리로 삽입하고 관리할 수 있게 해주는 기능입니다.2. 서브모듈 추가 및 클론서브모듈은 상위 저장소와 완전히 분리된 커밋 이력을 가집니다. 상위 저장소는 단지 "서브모듈의 특정 커밋 해시(버전)"만을 가리키는 형태로 관리됩니다.# 현재 진행 .. [GIT] 오픈소스 기여의 첫걸음 (Fork) 이번 포스팅에서는 [협업 워크플로우] 파트의 세부 주제인 오픈소스 기여의 첫걸음 (Fork)에 대하여 상세히 알아보겠습니다.1. Fork 워크플로우의 필요성보안과 관리의 목적으로, 대규모 오픈소스 프로젝트나 타 팀의 프로젝트에는 직접적으로 코드를 밀어 넣을(Push) 수 있는 권한이 제한되어 있습니다. 이처럼 쓰기 권한이 없는 저장소의 코드를 수정하여 기여(Contribute)하고 싶을 때 사용하는 방식이 Fork 워크플로우입니다.2. Fork 기반 협업 단계Fork는 GitHub 상에서 원본 저장소 전체를 내 계정 공간으로 완벽하게 복제해 오는 행위입니다.GitHub 원본 저장소 페이지 우측 상단의 Fork 버튼을 클릭하여 내 계정으로 프로젝트를 복사합니다.내 계정에 생성된 복사본 저장소를 내 로컬 컴.. [GIT] 코드 리뷰의 중심, Pull Request (PR) 이번 포스팅에서는 [협업 워크플로우] 파트의 세부 주제인 코드 리뷰의 중심, Pull Request (PR)에 대하여 상세히 알아보겠습니다.1. Pull Request의 개념Pull Request(이하 PR)는 자신이 작업한 브랜치의 코드를 메인 베이스 브랜치로 병합(Merge)해 달라고 프로젝트 관리자나 동료들에게 요청하는 과정입니다. 이는 Git 자체의 기능이 아닌 GitHub, GitLab과 같은 원격 저장소 호스팅 서비스가 제공하는 기능으로, 현대적인 코드 리뷰 문화를 정착시킨 핵심 시스템입니다.2. 올바른 PR 생성 및 리뷰 절차PR은 단순히 코드를 합치는 행위가 아니라, 내가 작성한 코드를 타인에게 설명하고 피드백을 수용하는 소통의 장입니다.목적 명시: PR 제목과 본문(Description).. [GIT] 성공적인 협업을 위한 브랜치 전략 모음 이번 포스팅에서는 [협업 워크플로우] 파트의 세부 주제인 성공적인 협업을 위한 브랜치 전략 모음에 대하여 상세히 알아보겠습니다.1. 브랜치 전략(Branching Model)의 중요성다수의 개발자가 동일한 프로젝트 저장소를 공유할 때, 규칙 없이 브랜치를 생성하고 병합하면 필연적으로 코드 충돌과 배포 지연이 발생합니다. 이를 방지하기 위해 소프트웨어 업계에서는 검증된 몇 가지 브랜치 전략 패턴을 표준으로 채택하여 사용합니다.2. 주요 브랜치 전략 비교프로젝트의 성격과 배포 주기에 따라 적합한 전략을 선택하는 것이 중요합니다.Git Flow가장 전통적이고 엄격한 모델입니다. master(배포), develop(개발 중심), feature(기능 단위), release(배포 준비), hotfix(긴급 버그 수.. [GIT] 장애 원인 추적: Blame & Bisect 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 장애 원인 추적: Blame & Bisect에 대하여 상세히 알아보겠습니다.1. 라인별 작성자 추적 (Blame)운영 중인 서비스에서 특정 코드 라인으로 인해 치명적인 에러가 발생했을 때, 해당 코드를 누가, 언제, 어떤 커밋 메시지와 함께 추가했는지 즉각적으로 파악해야 합니다. git blame은 파일의 각 줄(Line)마다 수정된 마지막 커밋 내역을 보여줍니다.# utils.js 파일의 모든 줄에 대한 변경 이력 조회$ git blame src/utils.js# 너무 길 경우 특정 라인(예: 50~60번 줄)만 지정해서 조회$ git blame -L 50,60 src/utils.js2. 이진 탐색으로 버그 커밋 찾기 (Bisect)수십.. [GIT] 소프트웨어 릴리스 버전 마킹 (Tag) 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 소프트웨어 릴리스 버전 마킹 (Tag)에 대하여 상세히 알아보겠습니다.1. Tag의 목적과 특성소프트웨어 개발 과정에서 의미 있는 마일스톤(예: v1.0.0 정식 출시)에 도달했을 때, 해당 시점의 소스 코드를 쉽게 찾을 수 있도록 북마크를 남기는 기능이 바로 태그(Tag)입니다. 브랜치(Branch)와 유사하게 특정 커밋을 가리키는 포인터 역할을 하지만, 커밋이 추가되더라도 태그가 가리키는 위치는 절대 변하지 않는다는(Read-only) 결정적인 차이가 있습니다.2. Tag의 두 가지 종류와 생성 방법Git은 가벼운 태그(Lightweight)와 주석 태그(Annotated) 두 가지 형식을 지원합니다.Lightweight Tag: 이름.. [GIT] 사라진 커밋 구출 작전 (Reflog) 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 사라진 커밋 구출 작전 (Reflog)에 대하여 상세히 알아보겠습니다.1. 최후의 보루, Reflog터미널 조작 중 실수로 git reset --hard 명령어를 실행하여 수 일간 작업한 커밋이 허공으로 증발해버린 경험은 누구나 한 번쯤 겪게 됩니다. git log를 쳐도 기록이 나오지 않아 절망스럽지만, Git은 내부적으로 사용자의 브랜치 이동 경로와 모든 행위(커밋, 리셋, 병합 등)를 기록하는 일지인 Reference Log(Reflog)를 유지하고 있습니다.2. 복구 절차Reflog를 열람하면 이미 삭제되어 일반 히스토리에는 보이지 않는 커밋 해시들까지 전부 조회할 수 있습니다.# 1. 모든 조작 기록과 당시의 커밋 해시 출력$ g.. [GIT] 최근 커밋 덮어쓰기 및 편집 (Amend) 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 최근 커밋 덮어쓰기 및 편집 (Amend)에 대하여 상세히 알아보겠습니다.1. 방금 한 실수 만회하기 (--amend)커밋을 남기고 엔터를 치는 순간 오타를 발견하거나 변경 파일 하나를 누락한 사실을 깨달을 때가 있습니다. 이럴 때 불필요한 '수정 커밋'을 추가로 남기지 않고 직전의 커밋 자체를 뜯어고쳐 덮어쓰는 옵션이 --amend 입니다.# 누락했던 파일을 뒤늦게 준비 영역에 추가$ git add missed_file.css# 직전 커밋에 해당 파일을 슬쩍 포함시키고, 메시지 편집창 열기$ git commit --amend# 에디터 화면 생략하고 바로 메시지만 수정하여 덮어쓰기$ git commit --amend -m "결제 오류 수정.. [GIT] 특정 커밋만 선별하여 가져오기 (Cherry-pick) 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 특정 커밋만 선별하여 가져오기 (Cherry-pick)에 대하여 상세히 알아보겠습니다.1. Cherry-pick 이란?전체 브랜치를 하나로 묶는 Merge나 Rebase와 달리, 다른 브랜치에 존재하는 여러 커밋 중 오직 내가 원하는 1~2개의 특정 커밋 패치 내용만을 복사하여 현재 브랜치 끝에 붙여넣는 섬세한 기술입니다. 마치 체리 바구니에서 잘 익은 체리만 쏙 골라내는 것과 같아 붙여진 이름입니다.2. 실무 활용 사례 및 명령어일반적으로 다음과 같은 상황에서 진가를 발휘합니다.핫픽스 브랜치에서 긴급하게 고친 버그 커밋 하나만 현재 개발 중인 메인 브랜치로 이식할 때실수로 다른 브랜치에서 작성한 커밋을 원래 의도한 브랜치로 가져오고, 이.. [GIT] 과거 시점으로 되돌리기 (Reset & Revert) 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 과거 시점으로 되돌리기 (Reset & Revert)에 대하여 상세히 알아보겠습니다.1. 과거의 커밋 자체를 지우고 돌아가기 (Reset)reset은 특정 커밋 시점으로 완전히 시계를 돌려버리며, 그 이후의 미래 커밋 내역을 히스토리에서 삭제합니다. 돌아가는 방식에 따라 3가지 모드가 있습니다.--soft: 지정한 커밋으로 돌아가지만 수정한 코드는 보존되며 '준비 영역(Staged)'에 그대로 둡니다. (주로 커밋 메시지 재작성에 쓰임)--mixed: (기본값) 코드는 보존되지만 '준비 영역'에서 내려온 상태(Unstaged)로 둡니다.--hard: 시점 이후의 코드 수정 사항마저 모조리 파기하고 완벽히 과거로 회귀합니다. (매우 주의해서.. [GIT] 미완성 작업 임시 저장하기 (Stash) 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 미완성 작업 임시 저장하기 (Stash)에 대하여 상세히 알아보겠습니다.1. Stash의 필요성과 원리개발을 진행하던 중 긴급하게 운영 환경 버그를 처리해달라는 요청을 받는 경우가 흔히 발생합니다. 이 때 작업 중인 코드를 강제로 Commit하면 이력이 더러워지고, 그렇다고 브랜치를 그냥 이동(Checkout)하자니 현재 파일들의 변경 사항 때문에 이동이 거부됩니다. 이러한 난감한 상황을 해결하는 임시 클립보드가 바로 Stash입니다. 코드를 안전하게 보관함에 넣고 워킹 디렉토리를 이전 커밋 상태로 깨끗하게 비워줍니다.2. 주요 Stash 명령어Stash는 스택(Stack) 구조로 동작하므로 여러 개의 작업을 차곡차곡 보관할 수 있습니다... [GIT] 안전하고 깔끔한 브랜치 관리 전략 이번 포스팅에서는 [브랜치와 병합] 파트의 세부 주제인 안전하고 깔끔한 브랜치 관리 전략에 대하여 상세히 알아보겠습니다.1. 종료된 브랜치의 정리병합이 완료되어 더 이상 사용하지 않는 기능 브랜치는 방치하지 않고 즉각 삭제하는 것이 로컬 저장소 관리에 이롭습니다. 브랜치 수가 너무 많아지면 추적과 관리가 힘들어집니다.# 현재 브랜치에 안전하게 병합된 로컬 브랜치 삭제 (-d 소문자)$ git branch -d feature-login# 병합 여부와 상관없이 강제로 로컬 브랜치 삭제 (-D 대문자)$ git branch -D feature-experimental# 원격 저장소(origin)에 존재하는 브랜치 삭제$ git push origin --delete feature-login2. 브랜치 동기화 최적.. [GIT] Merge와 Rebase의 차이 및 선택 기준 이번 포스팅에서는 [브랜치와 병합] 파트의 세부 주제인 Merge와 Rebase의 차이 및 선택 기준에 대하여 상세히 알아보겠습니다.1. 병합 방식의 근본적인 차이두 명령어 모두 코드를 합친다는 목적은 동일하지만, 기록을 남기는 철학이 다릅니다.Merge (병합): 두 갈래의 역사를 있는 그대로 보존합니다. 어디서 분기되었고 언제 합쳐졌는지(Merge Commit)에 대한 족적이 남습니다. 하지만 수십 개의 기능 브랜치가 동시에 병합될 경우, 로그 그래프가 거미줄처럼 매우 복잡해지는 단점이 있습니다.Rebase (재배치): 커밋들을 뜯어내어 한 줄로 다시 이어 붙입니다. 병합 커밋이 발생하지 않으며, 그래프가 마치 한 사람이 순차적으로 개발한 것처럼 일직선으로 매우 깔끔해집니다. 단점은 실제 커밋이 발생.. [GIT] 히스토리를 선형으로 정리하기 (Rebase) 이번 포스팅에서는 [브랜치와 병합] 파트의 세부 주제인 히스토리를 선형으로 정리하기 (Rebase)에 대하여 상세히 알아보겠습니다.1. Rebase의 원리Rebase는 직역하면 베이스(Base)를 다시(Re) 설정한다는 의미입니다. 파생된 브랜치의 시작점을 대상 브랜치의 가장 최신 커밋으로 재배치하는 작업을 수행합니다. 병합 커밋(Merge Commit)을 남기지 않기 때문에 여러 갈래로 뻗은 복잡한 브랜치 구조를 단일 선형 히스토리로 깔끔하게 정리해 주는 특성이 있습니다.2. Rebase 수행 방법Rebase를 수행할 때는 Merge와 반대로 내가 작업 중인 브랜치에 머무른 상태에서 기준이 될 브랜치를 지정합니다.# 1. 작업 중인 기능 브랜치로 이동$ git switch feature-login# 2.. [GIT] 충돌(Conflict) 발생 원인과 해결 가이드 이번 포스팅에서는 [브랜치와 병합] 파트의 세부 주제인 충돌(Conflict) 발생 원인과 해결 가이드에 대하여 상세히 알아보겠습니다.1. 충돌(Conflict)이 발생하는 이유병합 과정에서 빈번하게 겪게 되는 난관이 바로 병합 충돌(Merge Conflict)입니다. 이는 두 개의 브랜치가 동일한 파일의 동일한 라인을 서로 다르게 수정했을 때 발생합니다. Git은 어느 코드를 최종적으로 선택해야 할지 판단할 수 없기 때문에, 자동 병합을 중지하고 사용자에게 직접 결정을 맡깁니다.2. 충돌 해결 절차충돌이 발생하면 당황하지 말고 아래의 절차에 따라 순차적으로 코드를 정리합니다.# 1. 병합 시도 시 충돌 메시지 확인 후 상태 파악$ git status# (Both modified 상태로 표기된 파일들이 .. [GIT] 작업 내용 합치기 (Merge) 이번 포스팅에서는 [브랜치와 병합] 파트의 세부 주제인 작업 내용 합치기 (Merge)에 대하여 상세히 알아보겠습니다.1. Merge의 개념 및 목적분기되어 개별적으로 진행된 브랜치의 작업 내역들을 다시 메인 코드 라인으로 통합하는 과정을 병합(Merge)이라고 부릅니다. 기능 개발이나 버그 픽스가 완료된 시점에서, 파편화된 소스 코드를 하나로 모으기 위해 필수적으로 거치는 단계입니다.2. Merge 수행 방법 및 종류병합을 수행할 때는 항상 코드를 '받아들일' 목적지 브랜치로 먼저 이동(Checkout)한 뒤에, 합쳐질 대상 브랜치를 지정해야 합니다.# 1. 기준이 되는 브랜치(주로 main)로 먼저 이동$ git switch main# 2. 작업이 완료된 브랜치를 main으로 병합$ git merge.. ← 이전 1 2 다음 →
