<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Waylog Blog · Development</title>
    <link>https://waylog.pages.dev/category/development</link>
    <description>Waylog Blog의 Development 카테고리에 속한 글 모음</description>
    <language>ko-KR</language>
    <lastBuildDate>Thu, 21 May 2026 13:50:29 GMT</lastBuildDate>
    <pubDate>Mon, 11 May 2026 00:00:00 GMT</pubDate>
    <generator>Next.js</generator>
    <atom:link href="https://waylog.pages.dev/category/development/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>거대한 리팩터링 PR을 안전하게 쪼개는 법: 프론트엔드 팀의 브랜치·커밋 전략 실전</title>
      <link>https://waylog.pages.dev/posts/large-refactoring-pr-split-strategy-frontend-git-workflow</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/large-refactoring-pr-split-strategy-frontend-git-workflow</guid>
      <pubDate>Mon, 11 May 2026 00:00:00 GMT</pubDate>
      <category>Development</category>
      <description>&quot;이 PR 리뷰할 수 있는 사람이 있을까요&quot; — 거대 PR이 만드는 조용한 재앙 우리 프론트엔드 팀이 처음으로 컴포넌트 라이브러리 전면 교체를 결정했을 때, 첫 번째 반응은 의외로 낙관적이었습니다. &quot;모달만 먼저 바꾸고, 그 다음에 폼, 그 다음에 테이블 순서로 가면 되지 않을까?&quot; 하는 식이었습니다. 3주 후, 우리는 refactor/ui-library 브랜치가 main과 무려 200개 커밋 차이가 난다는 사실을 발견했습니다. 그 브랜치를 리베이스하려고 시도했다가 conflict 해소에만 이틀이</description>
    </item>
    <item>
      <title>Playwright로 구축하는 비주얼 회귀 테스트 파이프라인: 스크린샷 기준 이미지 관리부터 CI 디자인 리뷰 자동화까지</title>
      <link>https://waylog.pages.dev/posts/playwright-visual-regression-ci-design-review</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/playwright-visual-regression-ci-design-review</guid>
      <pubDate>Mon, 20 Apr 2026 00:00:00 GMT</pubDate>
      <category>Development</category>
      <description>유닛 테스트가 &quot;통과&quot;해도 디자인은 무너진다 우리 프론트엔드 개발자들은 테스트 커버리지가 80%를 넘어도 프로덕션 배포 다음 날 디자이너에게 &quot;헤더 폰트가 바뀌었어요&quot;라는 메시지를 받는 경험을 한 번쯤 합니다. Button 컴포넌트의 로직은 완벽하게 동작하는데, CSS 변수 하나가 바뀌면서 브랜드 컬러가 슬그머니 회색으로 바뀌어 있는 상황입니다. 비주얼 회귀 테스트(Visual Regression Testing)는 바로 이 간극을 메웁니다. 코드가 아닌 픽셀을 기준으로 UI가 의도치 않게 변경됐는</description>
    </item>
    <item>
      <title>Vitest + MSW로 React 통합 테스트 설계하기: 유닛 테스트를 넘어 실사용 시나리오를 검증하는 법</title>
      <link>https://waylog.pages.dev/posts/vitest-msw-integration-testing-react</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/vitest-msw-integration-testing-react</guid>
      <pubDate>Thu, 09 Apr 2026 00:00:00 GMT</pubDate>
      <category>Development</category>
      <description>유닛 테스트만으로는 사용자의 불만을 막을 수 없다 우리 프론트엔드 개발자들은 한 번쯤 이런 경험을 합니다. 개별 함수의 유닛 테스트는 모두 통과했는데, 정작 사용자가 폼을 제출하면 로딩 스피너가 사라지지 않거나, 에러 메시지가 엉뚱한 위치에 뜨는 현상입니다. 이 글은 Vitest와 MSW v2, React Testing Library를 결합해 실사용 시나리오를 통합 테스트로 검증하는 실전 전략을 다룹니다. TDD 철학에 관심 있다면 TDD로 프론트엔드 개발하기도 함께 읽어보시길 권합니다. --- </description>
    </item>
    <item>
      <title>Kent Beck의 TDD와 Tidy First: 프론트엔드 개발에의 완벽한 적용 가이드</title>
      <link>https://waylog.pages.dev/posts/tdd-frontend-guide</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/tdd-frontend-guide</guid>
      <pubDate>Mon, 21 Apr 2025 00:00:00 GMT</pubDate>
      <category>Development</category>
      <description>프론트엔드 개발 환경에서 Kent Beck의 TDD와 Tidy First 완벽 적용 가이드 소프트웨어 개발 분야의 살아있는 전설, 켄트 벡(Kent Beck)이 창시한 테스트 주도 개발(Test-Driven Development, TDD)은 단순한 개발 방법론을 넘어 개발자의 사고 방식을 근본적으로 바꾸는 철학입니다. 한 걸음 더 나아가, 그의 최근 저서인 &apos;Tidy First (단정하게 먼저)&apos;는 소프트웨어 설계의 본질인 &apos;구조적 변경과 행위 변경의 분리&apos;를 역설합니다. 오늘날 프론트엔드 개발은</description>
    </item>
    <item>
      <title>TDD(테스트 주도 개발)로 견고한 코드 작성하기: 실무 적용 가이드</title>
      <link>https://waylog.pages.dev/posts/2</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/2</guid>
      <pubDate>Fri, 21 Mar 2025 00:00:00 GMT</pubDate>
      <category>Development</category>
      <description>\n\n소프트웨어 개발 방법론의 고전이자 영원한 숙제인 TDD (Test Driven Development). &quot;테스트를 먼저 작성하라&quot;는 이 단순한 원칙이 왜 실무에서는 지켜지기 어려운 걸까요? 그리고 TDD를 제대로 수행했을 때 우리는 어떤 이점을 얻을 수 있을까요? 이 글에서는 켄트 벡의 철학부터 시작해, 실제 프론트엔드 개발 환경(Jest + React Testing Library)에서 TDD를 어떻게 수행하는지 단계별로 심도 있게 다룹니다. 1. TDD의 3단계 사이클: Red, Gree</description>
    </item>
  </channel>
</rss>
