Feature/debug4 리뷰 반영 (#532)

lee-ji-soo-v2 · lee-ji-soo-v2 · autofix-ci[bot] · web-flow · commit 339246121d8b · 2025-10-10T11:01:38.000+09:00
* 혜림님 리뷰 반영

* 주연님 리뷰 반영
- config.mts 파일에서 "기여하기" 텍스트를 "기여하기 탬플릿"으로 변경
- event.md 파일의 참여 이벤트 기간을 수정하고, 상품 수령 안내 날짜를 변경
- introduce.md 파일의 내용 수정 및 문단 정리
- start.md 파일에서 불필요한 설명 삭제
- diagnose 관련 페이지에서 오류 메시지 및 예시 제목 수정
- prevent 페이지에서 사용자 상태 및 배포 상태 섹션 제목 변경
- reproduce 페이지에서 예시 제목 수정 및 내용 정리

* 이벤트 페이지에 디버깅 티셔츠 이미지 추가 및 참여 방법과 기간에 대한 내용을 수정

* [autofix.ci] apply automated fixes

---------

Co-authored-by: lee-ji-soo-v2 &lt;lee-ji-soo-v2@naver.com&gt;
Co-authored-by: autofix-ci[bot] &lt;114827586+autofix-ci[bot]@users.noreply.github.com&gt;
diff --git a/fundamentals/debug/.vitepress/config.mts b/fundamentals/debug/.vitepress/config.mts
@@ -113,7 +113,7 @@ export default defineConfig({
             text: "Suspense Error 디버깅 _ 김형규",
             link: "/pages/experience/suspense_debug_by_hyungkyu.md"
           },
-          { text: "기여하기", link: "/pages/experience/contribute.md" }
+          { text: "기여하기 탬플릿", link: "/pages/experience/contribute.md" }
         ]
       }
     ]
diff --git a/fundamentals/debug/images/event/event-t-shirt.png b/fundamentals/debug/images/event/event-t-shirt.png
diff --git a/fundamentals/debug/pages/diagnose/error-message.md b/fundamentals/debug/pages/diagnose/error-message.md
@@ -4,15 +4,15 @@
 
 빨간 줄의 거대한 양의 에러 메세지를 보면 우리는 순간 당황해서 에러 메시지를 통째로 복사해 검색창에 붙여넣곤 해요. 하지만 에러 메시지는 의외로 친절하게 오류 원인을 알려 주고 있어요. 한 단어씩·한 문장씩 차근차근 해석하면 문제 발생 지점을 짐작할 수 있는 중요한 단서를 얻을 수 있어요.
 
-에러메세지는 문제의 범위를 빠르게 좁힐 수 있는 가장 강력한 힌트예요. 에러를 진단할 때는 단순히 메시지를 보는 것에 그치지 않고, 해당 메시지가 **무엇을 의미하는지**, **어떤 맥락에서 발생했는지**, **어떤 가능성부터 확인하면 좋은지** 차근히 살펴보는 게 중요해요.
+에러 메세지는 문제의 범위를 빠르게 좁힐 수 있는 가장 강력한 힌트예요. 에러를 진단할 때는 단순히 메시지를 보는 것에 그치지 않고, 해당 메시지가 **무엇을 의미하는지**, **어떤 맥락에서 발생했는지**, **어떤 가능성부터 확인하면 좋은지** 차근히 살펴보는 게 중요해요. 이 페이지에서는 각 에러 메시지 종류에 대한 이해를 높일 수 있는 설명과, 무엇을 확인해야 하는지 알려드려요.
 
-## 문법 오류 (`SyntaxError`)
+## 문법 오류일 때 (`SyntaxError`)
 
 ![](../../images/diagnose/error-syntax-1.png)
 
 코드에 문법적인 문제가 있을 때는 보통 `"SyntaxError: ~"`로 시작하는 에러 메시지가 출력돼요. 이 메시지는 자바스크립트 엔진이 **코드를 실행하기도 전에 문법을 해석하다가 실패했음을 알려주는 신호**예요.
 
-`unexpected '}'`는 에러메세지에서 볼 수 있듯이 `}` 괄호에 문제가 있다는 뜻이에요. 괄호가 닫히지 않았거나, 불필요한 괄호가 추가되었을때, 혹은 `export`나 `return` 같은 예약어를 잘못 썼을 때 아래와 같은 메시지를 볼 수 있어요.
+`unexpected '}'`는 `}` 괄호에 문제가 있다는 뜻이에요. 괄호가 닫히지 않았거나, 불필요한 괄호가 추가되었을때, 혹은 `export`나 `return` 같은 예약어를 잘못 썼을 때 아래와 같은 메시지를 볼 수 있어요.
 
 ```tsx 6
 function run() {
@@ -27,7 +27,7 @@ function run() {
 
 ![](../../images/diagnose/error-syntax-2.png)
 
-`Unexpected '<'` 에러 메세지는 보통 잘못된 URL로 인해 HTML 응답을 JSON으로 파싱하려는 시도에서 발생해요. 에러 메세지에서 'html...is not valid JSON' 이라는 문구에서 JSON.parse의 인자로 잘못된 타입의 데이터가 들어갔음을 추측해볼 수 있어요.
+`Unexpected '<'` 에러 메세지는 보통 잘못된 URL로 인해 HTML 응답을 JSON으로 파싱하려는 시도에서 발생해요. 에러 메세지의 'html...is not valid JSON' 이라는 문구에서 `JSON.parse`의 인자로 잘못된 타입의 데이터가 들어갔음을 추측해볼 수 있어요.
 
 ```js
 JSON.parse("<!DOCTYPE html><html><body>oops</body></html>");
@@ -46,13 +46,13 @@ JSON.parse('{ foo: "bar" }");
 ### 확인할 것
 
 - 문법에 맞게 작성되었는지 확인해요.
-- 사용자가 코드를 작성하는 동안 IDE가 구문 오류를 실시간으로 감지하고 강조 표시하여 판단해주기 때문에, 문법오류는 코드 작성 시 문제를 파악하고 고칠 수 있어요.
+- 사용자가 코드를 작성하는 동안 IDE가 구문 오류를 실시간으로 감지해 강조 표시를 해줘요. 그래서 코드를 작성하면서 문법 오류를 바로 파악하고 고칠 수 있어요.
 
-## 타입 오류 (`TypeError`)
+## 타입 오류일 때 (`TypeError`)
 
 ![](../../images/diagnose/error-syntax-4.png)
 
-값의 타입이 예상과 다를 때는 `"TypeError: ~"`로 시작하는 에러 메시지가 출력돼요. 이 에러는 주로 **정의되지 않았거나 잘못된 값에 접근하거나, 함수가 아닌 값을 함수처럼 호출했을 때** 발생해요.
+값의 타입이 예상과 다를 때는 `"TypeError: ~"`로 시작하는 에러 메시지가 출력돼요. 이 에러는 주로 **정의되지 않았거나, 잘못된 값에 접근하거나, 함수가 아닌 값을 함수처럼 호출했을 때** 발생해요.
 
 예를 들어 객체가 `null`이나 `undefined`인 상태에서 속성에 접근하려고 하면 이런 메시지를 볼 수 있어요.
 
@@ -65,7 +65,7 @@ console.log(user.name);
 
 ![](../../images/diagnose/error-syntax-5.png)
 
-함수가 아닌 객체를 호출하면 다음과 같은 에러 메세지가 나요
+함수가 아닌 객체를 호출하면 다음과 같은 에러 메세지가 나요.
 
 ```tsx 2
 const num = 42;
@@ -102,7 +102,7 @@ main();
 - `typeof`, `Array.isArray()` 등으로 미리 검사했는지 확인해요
 - `await` 누락 여부를 확인해요.
 
-## 참조 오류 (`ReferenceError`)
+## 참조 오류일 때 (`ReferenceError`)
 
 ![](../../images/diagnose/error-syntax-7.png)
 
@@ -121,7 +121,7 @@ let userName = "Alice";
 - 선언보다 먼저 접근한 건 아닌지 확인해요
 - 외부 스코프 참조가 의도한 것인지 확인해요
 
-## 리소스 로딩 오류
+## 리소스 로딩 오류일 때
 
 ![](../../images/diagnose/error-syntax-8.png)
 
@@ -157,13 +157,14 @@ fetch("/api/data")
 
 - 콘솔에 `TypeError: Load failed`나 `Failed to fetch`가 보이면 네트워크, CORS, 인증서, CSP(Content Security Policy), 확장 프로그램 차단 가능성을 먼저 의심해요.
 
-## 모듈 import 오류
+## 모듈 import 오류일 때
 
 ![](../../images/diagnose/error-syntax-9.png)
 
-모듈을 import하는 과정에서도 문법 오류(`SyntaxError`)가 발생할 수 있어요. 특히 ES 모듈(ESM)과 CommonJS(CJS) 방식이 혼합된 환경에서는 설정이 어긋나기 쉽고, 이로 인해 문법 오류처럼 보이는 에러가 나타날 수 있어요. 모듈 관련 에러 메시지를 보면 단순 문법 문제가 아니라 **모듈 시스템 설정에 문제가 있을 가능성**을 유추할 수 있어요.
+모듈을 import 하는 과정에서도 문법 오류(`SyntaxError`)가 발생할 수 있어요. 특히 ES 모듈(ESM)과 CommonJS(CJS) 방식이 혼합된 환경에서는 설정이 서로 충돌해서 문법 오류처럼 보이는 에러가 나타날 수 있어요.
+이때 모듈 관련 에러 메시지를 보면 단순 문법 문제가 아니라 **모듈 시스템 설정에 문제가 있을 가능성**을 유추할 수 있어요.
 
-예를들어, .js 파일에 import 구문을 사용하게 되면 아래와 같은 에러머세지가 나타나요. Node.js는 기본적으로 .js 파일을 CommonJS로 해석하기 때문에, import를 사용할 수 없고 require()를 써야 해요.
+예를 들어, .js 파일에 import 구문을 사용하게 되면 아래와 같은 에러 메시지가 나타나요. Node.js는 기본적으로 .js 파일을 CommonJS로 해석하기 때문에, `import`를 사용할 수 없고 `require()`를 써야 해요.
 
 ```js
 // example.js
diff --git a/fundamentals/debug/pages/diagnose/map.md b/fundamentals/debug/pages/diagnose/map.md
@@ -4,9 +4,7 @@
 
 특히 데이터가 어떻게 흘러가는지를 단계별로 정리하면, 실제 동작한 결과와 기대한 결과를 비교해가며 에러의 원인을 좁혀갈 수 있어요. 이 방식은 비동기 요청, 상태 변화, 복잡한 사용자 입력 처리 흐름을 분석할 때 특히 유용해요.
 
-## 예시
-
-유효성 검사 입력창을 예시로 들어볼게요. 입력값이 어떻게 처리되고 어떤 검증 단계를 거치는지를 살펴볼 수 있는 간단한 예시예요.
+유효하지 않은 값이 들어오면 error 화면을 보여주는 유효성 검사 입력창을 예시로 들어볼게요.
 
 ![](../../images/diagnose/map-ex-input-error-message.png){width=200}
 
diff --git a/fundamentals/debug/pages/event.md b/fundamentals/debug/pages/event.md
@@ -1,31 +1,20 @@
-# 🎁 참여 이벤트 1 (9/22 ~ 10/22)
+# 참여 이벤트
 
-자신의 인상깊었던 디버깅 사례를 정리하는 시간을 가져보세요! 디버깅 실무 사례를 올려주신 분들 **모두**에게 상품을 드려요!
+자신의 디버깅 사례를 정리하는 시간을 가져보세요! 디버깅 실무 사례를 올려주신 분들 중 3분을 당첨하여 디버깅 티셔츠를 드려요! (간단한 사례 환영)
 
-아래의 순서대로 참여해주세요
+![](../images/event/event-t-shirt.png){width=200}
 
-1. 디버깅 실무 사례 > 기여하기 탬플릿을 복사하여 debug/experience폴더에 새로운 파일로 생성
-2. 탬플릿에 맞게 디버깅 사례를 작성
-3. config.mts 파일에서 목록 중 디버깅 실무 사례 > items에 item 추가
-4. PR로 올리기
-
-💌 상품 수령 안내는 10월 23일에 Github에 등록된 이메일을 통해 개별로 안내를 보내드려요.
-
-<br/>
+## 참여 기간
 
----
+10/13부터 11/13까지 한달간 진행돼요.
 
-<br/>
+## 참여 방법
 
-# 🎁 참여 이벤트 2 (9/22 ~ 10/22)
+아래의 순서대로 참여해주세요.
 
-디버깅 할 때 힘이되는 명언을 아래 댓글로 적어주세요! 그 중 10분을 추첨해 상품을 드려요!
-
-예시)
-
-```
-    소프트웨어 문제 중 해결하지 못하는 문제는 없다.
-    중꺾마!!
-```
+1. [디버깅 실무 사례 > 기여하기 탬플릿](../pages/experience/contribute.md)을 복사하여 debug/experience폴더에 새로운 파일로 생성
+2. 탬플릿에 맞게 디버깅 사례를 작성
+3. config.mts 파일에서 목록 중 디버깅 실무 사례 > items에 item 추가
+4. PR로 올리기
 
-💌 당첨 안내는 10월 23일에 Github에 등록된 이메일을 통해 개별로 안내를 보내드려요.
+💌 상품 수령 안내는 11월 23일에 Github에 등록된 이메일을 통해 개별로 안내를 보내드려요.
diff --git a/fundamentals/debug/pages/fix/correct.md b/fundamentals/debug/pages/fix/correct.md
@@ -2,7 +2,7 @@
 
 에러를 수정할 때 종종 겉보기에만 문제를 해결한 코드를 작성하는 경우가 있어요. 이는 일시적으로 동작하더라도, 추후에 같은 문제가 다시 발생하거나 다른 곳에서 파급 효과를 일으킬 수 있어요. 진짜 중요한 건 “근본 원인을 찾아 수정하는 것” 이에요.
 
-## 예시 1
+## 예시: undefined 에러를 처리할 때
 
 배열에서 값을 찾을 때 undefined 에러가 나는 경우가 있어요. 사용자는 id === 3인 유저를 찾으려 했지만 배열에 해당 유저가 없으므로 undefined를 반환하고, 이후 .name에 접근하면서 에러가 발생해요.
 
@@ -45,7 +45,7 @@ const selectedUser = users.find((user) => user.id === 3);
 console.log(selectedUser?.name ?? "사용자 없음");
 ```
 
-## 예시 2
+## 예시: race condition이 발생할 때
 
 검색어 자동완성 API 요청 중 이전 요청 결과가 덮어써지는 문제를 예시로 들어볼게요.
 
diff --git a/fundamentals/debug/pages/fix/pure.md b/fundamentals/debug/pages/fix/pure.md
@@ -4,7 +4,7 @@
 
 간단한 예시로, 결제 금액에 따라 할인율을 적용하는 로직을 구현해볼게요.
 
-## 예시 1
+## 예시: UI 로직과 비즈니스 로직이 섞여있을 때
 
 결제 금액에 따라 할인율을 적용하는 로직이 UI 컴포넌트 안에 섞여 있다면 테스트를 하려면 UI까지 함께 렌더링해야 해서 불편해요.
 
@@ -70,7 +70,7 @@ function OrderSummary({
 }
 ```
 
-## 예시 2
+## 예시: React Hook을 활용해 팝업창을 보여줄 때
 
 react의 hook예시도 들어볼게요. 모달을 보여주는 로직이에요.
 
diff --git a/fundamentals/debug/pages/introduce.md b/fundamentals/debug/pages/introduce.md
@@ -2,27 +2,17 @@
 comments: false
 ---
 
-# 끝없는 버그는 없다
+# 시작하기
 
-디버깅은 때로는 끝이 보이지 않는 긴 터널을 걷는 것처럼 외롭고 지치게 느껴질 수 있어요. 하지만 여러분이 마주하는 어려움은 결코 혼자 겪는 것이 아니에요. 수많은 개발자들이 같은 벽에 부딪히고, 같은 좌절을 겪으면서도 결국 해결책을 찾아왔어요.
+디버깅(Debugging)은 프로그램이 예상대로 동작하지 않을 때, 그 원인을 찾아내고 해결하는 과정이에요. 개발 과정 전반에 걸쳐 반복되는, 누구에게나 피할 수 없는 중요한 작업이죠.
 
-소프트웨어 문제에 풀 수 없는 문제는 없어요. 지금 당장은 답이 보이지 않아도, 한 걸음씩 차근차근 시도하다 보면 반드시 길이 열려요. 중요한 건 포기하지 않는 마음이에요. 문제와 마주하는 과정에서 여러분의 실력은 더 단단해지고, 개발자로서의 자신감은 한층 더 깊어질 거에요.
+때로는 디버깅이 끝이 보이지 않는 긴 터널을 걷는 것처럼 느껴지기도 해요. 하지만 디버깅이 어렵다는 것은 결코 혼자 겪는 것이 아니에요. 수많은 개발자들이 같은 벽에 부딪히고, 같은 좌절을 겪으면서도 결국 해결책을 찾아왔어요. 풀 수 없는 버그는 없어요. 작은 단서를 따라가다 보면 반드시 해결책은 나타나요. 중요한 건 포기하지 않는 마음이에요.
 
-<br/>
+이 문서는 포기하지 않고 디버깅을 해나가는 분들에게 도움을 드리기 위해 흔히 만나는 버그 패턴과 디버깅 접근법을 실제 사례와 함께 소개해요. 지치기보다 단단해지는 경험으로, 디버깅을 바라볼 수 있도록 도와줄 거예요.
 
-<br/>
+## 이런 분들에게 추천해요
 
-# 이 문서를 읽은 후 기대되는 행동 변화
-
-### Before
-
-- 에러 메세지에 압도되어 전체를 복사해 구글에 붙여넣어요
-- 의미를 파악하기보다 코드에 랜덤한 변경을 가하며 막연히 해결되길 기도해요
-- 디버깅 과정에 대한 메타인지가 없어 현재 무엇을 시도하는지 / 해야 하는지 막연해요
-
-### After
-
-- 무작정 디버거를 걸고 이것 저것 수정해보기 전에, 노트 펴고 한 줄 요약부터 시작해요
-- 에러 메세지를 단서로 삼아 체계적으로 원인을 분석해요
-- 효율적으로 에러 상황을 재현해요
-- 재발 방지를 위해 코드를 깔끔하게 유지해요
+- 🧩 에러 메세지에 압도되어 전체를 복사해 구글에 붙여넣는 개발자
+- 🔍 디버깅을 할 때마다 감에 의존하지 않고 **체계적으로 분석하고 싶은 개발자**
+- 🧪 **버그를 재현하고 고친 뒤**, 재발 방지까지 고민해 본 적 있는 개발자
+- 🤝 팀 내에서 **에러 대응 방식이나 로그 작성 기준을 통일**하고 싶은 개발자
diff --git a/fundamentals/debug/pages/prevent/error-log.md b/fundamentals/debug/pages/prevent/error-log.md
@@ -6,7 +6,7 @@
 
 아래는 에러 로그를 남길 수 있는 정보들이에요. 이 정보들을 기록하면 문제가 발생한 상황을 더 쉽게 이해하고, 빠르게 대응할 수 있어요.
 
-## 사용자 상태
+### 사용자 상태
 
 사용자가 어떤 환경에서 문제를 겪었는지 기록해요. 다양한 기기와 설정에서 발생할 수 있는 문제를 추적할 수 있어요.
 
@@ -17,7 +17,7 @@
 지역, 시간대: `Asia/Seoul`
 ```
 
-### 확인할 것
+#### 확인할 것
 
 - **소프트웨어 버전**  
   릴리즈 노트 및 변경 이력을 확인해요. 해당 버전에 도입된 기능, 수정된 버그 등의 내용을 확인해요. 또는, 이전/다음 버전과의 비교 테스트를 해보면 문제의 범위를 좁힐 수 있어요.
@@ -36,7 +36,7 @@
   브라우저에서 사용하는 시간대가 `KST`인지 확인해요.  
   [시간대 비교 도구](https://www.timeanddate.com/worldclock/converter.html?iso=20250418T180000&p1=235&p2=250)
 
-## 배포 상태
+### 배포 상태
 
 문제가 발생한 빌드가 어떤 커밋과 연결돼 있는지 확인할 수 있어요. 어떤 기능이나 수정이 포함된 상태였는지를 파악하는 데 도움이 돼요.
 
@@ -48,30 +48,28 @@
 환경: `production`
 ```
 
-### 확인할 것
+#### 확인할 것
 
 - 해당 커밋과 릴리즈 노트를 참고해서 어떤 변경사항이 있었는지 확인해요.
 
-## 런타임 상태
+### 런타임 상태
 
 에러가 발생한 순간에 사용자가 어떤 입력을 했는지, 어떤 상태였는지를 기록해요.  
 문제를 재현하고 원인을 추적하는 데 중요한 단서가 돼요.
 
-### 예시
-
 ```
 옵션 ID: `opt-00123`
 옵션 유형: `size`
 선택한 개수: `2`
 ```
 
-### 확인할 것
+#### 확인할 것
 
 - 특정 옵션 조합에서만 문제가 발생하는지 확인해요.
 - 서버에서 내려온 데이터와 사용자 선택값이 일치하는지 확인해요.
 - 클릭, 입력 등의 인터랙션이 실제로 처리됐는지 확인해요. 디바운스나 중복 클릭으로 `race condition`이 발생한 것은 아닌지도 확인해요.
 
-## ⚠️ 주의사항
+### ⚠️ 주의사항
 
 에러 로그에는 다음과 같은 개인정보는 절대 포함하지 않아요.
 
diff --git a/fundamentals/debug/pages/prevent/index.md b/fundamentals/debug/pages/prevent/index.md
@@ -2,9 +2,8 @@
 
 ![](../../images/prevent/prevent.png)
 
-"이제 이 버그가 다시는 재발하지 않도록 팀에 잘 정리해서 공유해야겠다."라는 생각이 드는 마음 한편으로는 "버그를 고쳤으니 끝났어, 잘했어, 바쁘니까 다른 일을 하러가자"라는 양가감정이 생겨요. 하지만, 바로 그 갈림길에서 어떤 선택을 하느냐가 개발자의 성장을 결정짓는 것 같아요. 단순히 버그를 고치는 것에서 멈추면 같은 문제가 반복될 수 있고, 결국 팀의 효율성과 신뢰에도 영향을 주죠. 반대로, 원인을 기록하고 해결 과정을 체계화해두면 나 자신도 한층 단단해지고, 팀 전체가 더 나은 방향으로 나아갈 수 있어요.
+"이제 이 버그가 다시는 재발하지 않도록 팀에 잘 정리해서 공유해야겠다."라는 생각이 드는 마음 한편으로는 "버그를 고쳤으니 끝났어, 잘했어, 바쁘니까 다른 일을 하러가자"라는 마음도 들어요. 하지만 '버그 수정'은 끝이 아니라 더 나은 시스템과 더 강한 팀을 만드는 출발점이에요.
+만약 단순히 버그를 고치는 것에서 멈추면 같은 문제가 반복될 수 있고, 결국 팀의 효율성과 신뢰에도 영향을 줘요. 반대로, 원인을 기록하고 해결 과정을 체계화해 두면 나 자신도 한층 단단해지고, 팀 전체가 더 나은 방향으로 나아갈 수 있어요.
 
-즉, "버그 수정"은 끝이 아니라, 더 나은 시스템과 더 강한 팀을 만드는 출발점이에요.
-그래서 당장의 바쁨보다 장기적인 성장을 택하는 게 중요해요.
-
-다시는 같은 실수를 반복하지 않도록 기록을 남기고, 시스템을 개선하고, 팀과 지식을 나누는 일이 중요해요. 이 단계에서는 ”이 버그가 다시 생기지 않게 어떤 조치를 했는가?”를 중심으로 정리해요.
+그래서 당장의 바쁨보다 장기적인 성장을 택하는 게 중요해요. 이를 위해 다시는 같은 실수를 반복하지 않도록 기록을 남기고, 시스템을 개선하고, 팀과 지식을 공유해야 해요.
+이 단계에서는 ”이 버그가 다시 생기지 않게 어떤 조치를 했는가?”를 중심으로 다루어요.
diff --git a/fundamentals/debug/pages/prevent/share.md b/fundamentals/debug/pages/prevent/share.md
@@ -4,7 +4,7 @@
 
 ## 린터 규칙 추가
 
-### 예시 1
+### 예시: 맞춤법 오류가 발생할 때
 
 - 문제: 맞춤법 오류가 빈번히 발생
 - 해결방법: ESLint로 금지 단어 설정
@@ -14,7 +14,7 @@
 명사 + 에요 => 이에요/예요
 ```
 
-### 예시 2
+### 예시: 테스트 코드가 노출될 때
 
 - 문제: “김토스님” 같은 더비 텍스트가 코드에 남는 문제.
 - 해결방법: ESLint로 금지 단어 김토스 추가
diff --git a/fundamentals/debug/pages/reproduce/debugger.md b/fundamentals/debug/pages/reproduce/debugger.md
diff --git a/fundamentals/debug/pages/reproduce/simply.md b/fundamentals/debug/pages/reproduce/simply.md
diff --git a/fundamentals/debug/pages/reproduce/trace.md b/fundamentals/debug/pages/reproduce/trace.md
diff --git a/fundamentals/debug/pages/start.md b/fundamentals/debug/pages/start.md

Original file line number	Diff line number	Diff line change
`@@ -113,7 +113,7 @@ export default defineConfig({`
`113`	`113`	`text: "Suspense Error 디버깅 _ 김형규",`
`114`	`114`	`link: "/pages/experience/suspense_debug_by_hyungkyu.md"`
`115`	`115`	`},`
`116`		`- { text: "기여하기", link: "/pages/experience/contribute.md" }`
	`116`	`+ { text: "기여하기 탬플릿", link: "/pages/experience/contribute.md" }`
`117`	`117`	`]`
`118`	`118`	`}`
`119`	`119`	`]`