본문 바로가기

전체 글55

[Tooling] "따옴표 하나로 Git 충돌이?" ESLint와 Prettier로 협업 스트레스 날려버린 후기 팀 프로젝트에 처음 합류했을 때, 가장 저를 당황스럽게 만들었던 건 로직 에러가 아닌 'Git Merge 충돌(Conflict)'이었습니다. 분명히 저는 로그인 로직 코드 한 줄만 고쳤는데, PR(Pull Request)을 올려보니 파일 전체에 빨간 줄이 그어지며 충돌이 난 것이죠.원인을 찾아보니 제 에디터는 파일 저장 시 작은따옴표(')로 자동 변환하고 있었고, 동료 개발자의 에디터는 큰따옴표(")와 세미콜론을 강제로 붙이고 있었습니다. 코드 리뷰 시간에 로직을 검토하기도 전에 "여기 들여쓰기 탭 간격 고쳐주세요", "따옴표 통일해 주세요" 같은 스타일 지적 주고받기로 수십 분을 허비하곤 했습니다.이 소모적인 논쟁을 원천 차단하고 "저장(Ctrl+S) 버튼만 누르면 알아서 코드 스타일에 대한 약속을 지.. 2026. 5. 3.
[Tooling] 프론트엔드 테스트 전략: Jest와 Cypress로 결함 없는 코드 만들기 팀 프로젝트에서 배포를 진행한 직후, 팀원이 당황스러운 소식을 전해왔습니다. "아까 새로 고친 팝업창 버튼은 잘 되는데, 기존에 잘 되던 [로그인]이랑 [장바구니 담기] 기능이 클릭이 안 돼요!"분명 내 파트 코드만 살짝 고치고 수동으로 클릭해 본 뒤 Merge했었는데, 공통으로 쓰이던 유틸리티 함수와 리액트 상태(State)가 꼬이면서 사이드 이펙트(Side Effect)가 발생했던 것입니다. 배포할 때마다 식은땀을 흘리며 깨달았습니다."프로젝트 규모가 커질수록, 사람이 수동으로 버튼을 하나씩 눌러보며 버그를 검증하는 것엔 한계가 있구나."내가 작성하거나 고친 코드가 기존 기능에 영향을 미치지 않는다는 확신을 얻고, 마음 편히 배포하게 만들어준 테스트 자동화 구축기를 정리해 봅니다.1. 현실적인 테스트.. 2026. 5. 2.
[Security] 프론트엔드 보안 가이드: XSS와 CSRF 완벽 방어하기 웹 애플리케이션의 복잡도가 높아지면서 프론트엔드 보안의 중요성도 그 어느 때보다 커졌습니다. 보안 사고는 서비스의 신뢰도를 한순간에 무너뜨릴 뿐만 아니라 사용자의 개인정보 유출로 직결됩니다. 오늘은 프론트엔드 개발자가 반드시 알고 있어야 할 두 가지 핵심 공격 기법인 XSS와 CSRF의 원리를 파악하고, 이를 방어하기 위한 실무 전략을 알아보겠습니다.1. XSS (Cross-Site Scripting): 내 사이트에 남이 짠 코드가?XSS는 공격자가 악성 스크립트를 웹 페이지에 삽입하여, 다른 사용자의 브라우저에서 해당 스크립트가 실행되게 만드는 공격입니다.1.1 공격의 위험성스크립트가 실행되면 공격자는 사용자의 세션 쿠키를 가로채거나, 사용자를 대신해 게시글을 작성하고, 민감한 정보를 외부 서버로 전송.. 2026. 5. 1.
[Web] 브라우저 렌더링 원리: Critical Rendering Path 최적화 전략 웹사이트의 성능은 단순히 '데이터가 얼마나 빨리 도착하는가'에 달려 있지 않습니다. 더 중요한 것은 '도착한 데이터를 얼마나 빨리 화면에 그려내는가'입니다. 브라우저가 HTML, CSS, JavaScript를 받아서 화면에 픽셀로 변환하는 일련의 과정을 중요 렌더링 경로(Critical Rendering Path, CRP)라고 부릅니다. 이 경로를 단축하는 것이 곧 성능 최적화의 정석입니다.1. 렌더링의 5단계 공정 (CRP)브라우저는 화면을 그리기 위해 크게 5가지 단계를 거칩니다.1.1 DOM 트리 구축 (Parsing)브라우저가 HTML 문서를 읽어 내려가며 태그들을 트리 구조의 노드들로 변환합니다. 이것이 우리가 잘 아는 DOM(Document Object Model)입니다.1.2 CSSOM 트리.. 2026. 4. 30.
[Next.js] App Router 환경에서 서버 컴포넌트(RSC)와 클라이언트 컴포넌트의 경계 설계하기 Next.js App Router의 핵심은 "모든 컴포넌트는 기본적으로 서버 컴포넌트(Server Components)다"라는 선언입니다. 과거 Pages Router 시절에는 모든 컴포넌트가 브라우저로 전송되어 하이드레이션(Hydration) 과정을 거쳐야 했지만, 이제는 서버에서만 실행되고 결과물인 HTML만 브라우저로 전달되는 컴포넌트를 만들 수 있게 되었습니다.하지만 개발을 하다 보면 인터랙션(클릭, 상태 관리)이 필요한 시점이 오고, 자연스럽게 'use client'를 선언하게 됩니다. 이때 가장 중요한 역량은 "어디까지를 서버 영역으로 두고, 어디서부터 클라이언트 영역으로 나눌 것인가"를 결정하는 설계 능력입니다.1. 서버 컴포넌트(RSC) vs 클라이언트 컴포넌트(RCC)먼저 두 컴포넌트의 .. 2026. 4. 29.
[TS] API 응답 데이터에 타입 안전성 입히기: Zod를 활용한 런타임 유효성 검사 타입스크립트(TypeScript)를 사용하면서 우리는 종종 착각에 빠지곤 합니다. "타입을 정의했으니, 런타임에서도 이 데이터는 안전할 거야"라고 말이죠. 하지만 타입스크립트의 타입 검사는 **빌드 시점(Compile Time)**에만 작동하며, 자바스크립트로 변환되는 순간 모두 사라집니다.특히 외부 API에서 받아오는 데이터는 타입스크립트가 보호해 주지 못하는 '치외법권' 영역입니다. 백엔드에서 예고 없이 필드명을 바꾸거나 null을 내려주면, 우리 앱은 undefined 에러를 뿜으며 멈춰버립니다. 오늘은 이러한 '런타임 불확실성'을 제거해 주는 강력한 스키마 검증 라이브러리, Zod를 소개합니다.1. 타입스크립트의 한계: 정적 타입 vs 동적 데이터타입스크립트는 '기대하는 데이터의 형태'를 정의할 .. 2026. 4. 28.

티스토리툴바