diff --git a/docs/good-code/2-quality.mdx b/docs/good-code/2-quality.mdx
index bf60ad9..6ad74d0 100644
--- a/docs/good-code/2-quality.mdx
+++ b/docs/good-code/2-quality.mdx
@@ -45,7 +45,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 - 20장 — 단일 기법으로 결함의 60%도 못 잡는다는 전제는 타입·린터·테스트·리뷰가 일상이 된 2026년 FE에서 오히려 더 잘 들어맞아요.
 - 21장 — 코드 리뷰·페어·CI·QA를 한 파이프라인으로 보면 "결함 발견 시점을 얼마나 앞당기느냐"가 팀 비용을 가르는 축이 돼요.
-- 22장 — 단위 테스트는 여전히 기본기지만, 컴포넌트와 Playwright가 섞인 FE에서는 "테스트 피라미드 vs 트로피"의 선택이 함께 따라와요.
+- 22장 — 단위 테스트는 여전히 기본기지만, 컴포넌트 테스트와 Playwright가 결합된 FE에서는 "테스트 피라미드 vs 트로피"의 선택이 함께 따라와요.
 - 23장 — 디버깅은 가설 수립과 이분 탐색 같은 개인 사고력 + Sentry/Session Replay 같은 팀 인프라가 양쪽 다 필요한 영역이에요.
 
 큰 그림을 훑었으니, 각 장의 판정과 체크, 그리고 미션 산출물로 들어가 볼게요.
@@ -260,7 +260,7 @@ describe('pay', () => {
 
 ```text
 코딩 ──→ 셀프 체크 ──→ 코드 리뷰 ──→ CI ──→ QA ──→ 릴리스
- ①          ②            ③         ④       ⑤
+ ①        ②          ③        ④      ⑤
 ```
 
 #### 설계 노트
@@ -301,7 +301,7 @@ describe('pay', () => {
 
 <Verdict
   rating="🟢 생존"
-  rationale={`"코드 작성 전에 테스트를 설계하라", "경계값·나쁜 데이터·정상 데이터 클래스를 체계적으로 만들라"는 원칙은 Vitest·Testing Library·Playwright가 도구를 바꿨을 뿐, 테스트 설계의 사고방식 자체는 그대로 유효하다.`}
+  rationale={`"코드 작성 전에 테스트를 설계하라", "경계값·나쁜 데이터·정상 데이터 클래스를 체계적으로 만들라"는 원칙은 Jest·Vitest·React Testing Library·Playwright가 도구를 바꿨을 뿐, 테스트 설계의 사고방식 자체는 그대로 유효하다.`}
 />
 
 ### ✅ 체크리스트