diff --git a/docs/good-code/1-routines.mdx b/docs/good-code/1-routines.mdx
index 94cd759..d95eb77 100644
--- a/docs/good-code/1-routines.mdx
+++ b/docs/good-code/1-routines.mdx
@@ -41,7 +41,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 ## 📝 묶음 요약
 
-7~9장은 "코드 한 단위를 어떻게 잘 만들 것인가"를 세 각도로 좁혀 들어가는 묶음이에요. 7장은 좋은 루틴(함수)의 기준을, 8장은 그 루틴이 외부와 만나는 경계에서의 방어 전략을, 9장은 코딩에 들어가기 전 의사코드로 설계를 검증하는 절차를 다뤄요.
+7~9장은 "코드 한 단위를 어떻게 잘 만들 것인가"를 세 관점으로 좁혀 들어가는 묶음이에요. 7장은 좋은 루틴(함수)의 기준을, 8장은 그 루틴이 외부와 만나는 경계에서의 방어 전략을, 9장은 코딩에 들어가기 전 의사코드로 설계를 검증하는 절차를 다뤄요.
 
 - 7장 — 추상화 수준을 맞추고 부작용 경계를 분명히 하라는 원칙은 함수형 컴포넌트와 커스텀 훅에서도 그대로 통해요.
 - 8장 — "어디까지 방어할 것인가"는 TypeScript와 Zod가 깔린 환경에서 답이 달라져요. 모든 곳이 아니라 경계에서만 검증하는 바리케이드 전략이 필요해요.
@@ -120,8 +120,8 @@ export async function loadAndShapePayments(
 
 **Before의 문제**
 
-- URL 조립(How) 과 데이터 패칭(What) 이 같은 줄에 있다. encodeURIComponent, 쿼리 문자열 직접 결합은 "어떻게 요청을 보내는가"이고, 함수의 목적은 "결제 내역을 가져온다"이다.
-- 배열 필터링(How) 과 뷰 변환(How) 이 패칭 직후에 한 덩어리로 이어진다. "무엇을 하는가"(필터 → 검색 → 포맷)가 구현 디테일에 묻힌다.
+- URL 조립(How)과 데이터 패칭(What)이 같은 줄에 있다. encodeURIComponent, 쿼리 문자열 직접 결합은 "어떻게 요청을 보내는가"이고, 함수의 목적은 "결제 내역을 가져온다"이다.
+- 배열 필터링(How)과 뷰 변환(How)이 패칭 직후에 한 덩어리로 이어진다. "무엇을 하는가"(필터 → 검색 → 포맷)가 구현 디테일에 묻힌다.
 
 ##### After ✅
 
@@ -200,7 +200,7 @@ export async function loadPayments(params: PaymentQuery): Promise<PaymentView[]>
 
 **개선 포인트**
 
-- loadPayments의 본문 4줄만 읽으면 "패칭 → 상태 필터 → 이름 검색 → 뷰 변환"이라는 흐름(What) 이 바로 보인다.
+- loadPayments의 본문 4줄만 읽으면 "패칭 → 상태 필터 → 이름 검색 → 뷰 변환"이라는 흐름(What)이 바로 보인다.
 - 각 하위 함수가 How를 캡슐화하여, loadPayments는 추상화 수준이 균일하다.
 - 파라미터 4개 나열 → PaymentQuery 객체로 묶어서 순서 실수를 방지하고, query/status/page에 기본값 정책이 명시됨.
 
@@ -384,7 +384,7 @@ async function handleRefund(paymentId: string, amount: number) {
 
 ### 📖 원문 핵심
 
-**방어적 프로그래밍의 전제**: 프로그램에 잘못된 데이터가 들어와도 손상되지 않아야 한다는 아이디어로, "garbage in, garbage out"은 오늘날 기준으로 허술하고 불안전한 프로그램의 징표예요.
+**방어적 프로그래밍의 전제**: 프로그램에 잘못된 데이터가 들어와도 손상되지 않아야 한다는 아이디어로, "garbage in, garbage out"은 오늘날 기준으로 허술하고 안전하지 않은 프로그램의 징표예요.
 
 **Assertion(단언문)**: 개발 중에 코드가 스스로를 검증하는 수단으로, 절대 발생해서는 안 되는 조건을 체크하며 전제조건과 사후조건을 문서화하는 실행 가능한 명세 역할을 해요. Assertion은 버그를 잡는 것이고 에러 처리 코드는 예상 가능한 이상 상황을 처리하는 것으로, 둘은 목적이 다르므로 혼용해서는 안 돼요.
 
@@ -444,7 +444,7 @@ function RefundForm() {
 
 - 빈 문자열 → Number("") → 0 → 0원 환불 요청
 - 문자 입력 → Number("abc") → NaN → 서버에 NaN 전송
-- 음수 입력 → 1000 → 마이너스 환불
+- 음수 입력 → -1000 → 마이너스 환불
 - 결제 금액 초과 → 한도 없이 아무 금액이나 전송
 
 ##### After ✅
@@ -872,7 +872,7 @@ experience=""
 <MemberOpinion
   author="zinii"
   emoji="🐣"
-  opinion={`UI 오류는 Error Boundary — 실패할 경우 대체 UI를 보여줄 수 있으니까. 네트워크 오류는 try/catch — 네트워크 응답값의 상태 기반이니까.`}
+  opinion={`UI 오류는 Error Boundary — 실패할 경우 대체 UI를 보여줄 수 있기 때문에. 네트워크 오류는 try/catch — 네트워크 응답값의 상태 기반이기 때문에.`}
   experience=""
 />