[autofix.ci] apply automated fixes

Author: autofix-ci[bot]

fundamentals/debug/pages/contribute/android/android_react_native_bundle_loading_sigbus_crash_debug.md

@@ -3,7 +3,6 @@
 <br/>
 <ContributorHeader name="김희철" githubUrl="https://github.com/heecheolman" avatar="https://ca.slack-edge.com/E01JAGTHP8R-U01JVCVAP41-ea9f13e55dd5-512" />
 
-
 ## 진단하기
 
 Android에서 React Native 번들을 불러오는 과정에서 앱이 크래시되는 현상이 발생했어요. 에러
@@ -14,17 +13,19 @@ Android에서 React Native 번들을 불러오는 과정에서 앱이 크래시
 토스 앱에서는 React Native 번들을 효율적으로 관리하기 위해 캐시 시스템을 사용하고 있어요:
 
 - 번들 캐시는 `cache/toss_react_bundle_cache` 디렉토리에 저장돼요
-    - 예: `cache/toss_react_bundle_cache/insurance-ads`
+  - 예: `cache/toss_react_bundle_cache/insurance-ads`
 - 실행 가능한(실행 중인) 번들은 `cache/toss_react_bundle_cache/execute/*` 에 저장돼요
-    - 예: `cache/toss_react_bundle_cache/execute/insurance-ads`
+  - 예: `cache/toss_react_bundle_cache/execute/insurance-ads`
 
 ### 번들 캐시 동작 방식
 
 1. 로컬에서 번들 찾기 및 검증 (`maxAge`, 시그니처 검증)
 2. 검증 성공 시 캐시 디렉토리에서 `execute` 디렉토리로 복사
 3. 백그라운드에서 `remote` 번들 확인
+
 - `304 not modified`면 메타 파일만 업데이트
 - 수정되었다면 `.pending_activation suffix`로 저장
+
 4. 특정 조건이 되면 `.pending_activation` 파일을 `active` 상태로 전환
 
 문제는 이 과정에서 이미 실행되고 있는 번들 파일에 동시에 write 작업이 발생하면서 `SIGBUS`
@@ -52,7 +53,7 @@ Android 버그 리포트에서 발생한 userNo를 키바나(토스의 로그 
 - `maxAge가` 0이어서 항상 remote에서 번들을 받고 있었어요
 - `verify` 로직에서 `maxAge`가 0이면 항상 `null`을 반환하고, 그래서 항상 remote에서 불러오게 돼요
 - 초기 설계에서는 하루 캐시가 기본값이었고, 튜바 변수 `reactNative.scheme.maxage`를 참조해야
-했어요
+  했어요
 - 그런데 언젠가부터 이 튜바 변수가 사라져서 `maxAge`가 0으로 설정되고 있었어요
 
 ## 수정하기
@@ -92,4 +93,4 @@ execFile.write(...)
 
 파일 이름을 다르게 하거나 물리적으로 격리시켰을 때 크래시가 발생하지 않는다는 것을 확인하여,
 동시성 이슈임을 명확히 파악할 수 있었어요. 이처럼 문제를 격리시켜보는 실험은 원인을 빠르게
-좁혀나가는 데 유용한 기법이에요.
+좁혀나가는 데 유용한 기법이에요.

fundamentals/debug/pages/contribute/compile/codegen_callstack_overflow_debug.md

@@ -3,13 +3,13 @@
 <br/>
 <ContributorHeader name="윤민석" githubUrl="https://github.com/black7375" avatar="https://ca.slack-edge.com/E01JAGTHP8R-U085U98PY31-d26c07fac97e-512" />
 
-
 ## 진단하기
 
 TDS Desktop 마이그레이션 작업 중, `Codegen`으로 자동 생성된 결과로 매우 긴 코드를 작성했더니
 파싱 콜스택이 터지는 문제가 발생했어요. ESLint와 TypeScript 컴파일러(tsc)가 모두 동작하지 않았고, 빌드조차 실패하는 상황이었어요.
 
 ### 문제의 심각성
+
 - 로컬 개발 환경에서 ESLint 실행 불가
 - TypeScript 컴파일 실패
 - CI 빌드 파이프라인도 동일한 에러로 실패
@@ -28,18 +28,18 @@ TDS Desktop 마이그레이션 작업 중, `Codegen`으로 자동 생성된 결
 ```jsx
 // 문제가 되는 코드 (560개 체이닝)
 const result = builder
-.method1()
-.method2()
-.method3()
-// ... (560개 계속)
-.method560();
+  .method1()
+  .method2()
+  .method3()
+  // ... (560개 계속)
+  .method560();
 ```
 
 이런 매우 긴 체이닝 코드를 ESLint와 TypeScript가 파싱하려고 할 때, AST를 생성하는 과정에서
 재귀 호출이 너무 깊어져서 JavaScript 엔진의 콜스택 제한에 도달한 거예요.
 
-
 ### 재현 조건
+
 - Codegen으로 자동 생성된 대량의 메서드 체이닝 (560개)
 - ESLint 실행 시
 - TypeScript 컴파일 시
@@ -52,38 +52,38 @@ const result = builder
 ```jsx
 // 수정 전: 560개를 한 줄로 체이닝 (콜스택 오버플로우)
 const result = builder
-.method1()
-.method2()
-// ... (560개)
-.method560();
+  .method1()
+  .method2()
+  // ... (560개)
+  .method560();
 
 // 수정 후: 5개의 변수로 분할 (각각 약 100개씩)
 const step1 = builder
-.method1()
-.method2()
-// ... (100개)
-.method100();
+  .method1()
+  .method2()
+  // ... (100개)
+  .method100();
 
 const step2 = step1
-.method101()
-.method102()
-// ... (100개)
-.method200();
+  .method101()
+  .method102()
+  // ... (100개)
+  .method200();
 
 const step3 = step2
-.method201()
-// ... (100개)
-.method300();
+  .method201()
+  // ... (100개)
+  .method300();
 
 const step4 = step3
-.method301()
-// ... (100개)
-.method400();
+  .method301()
+  // ... (100개)
+  .method400();
 
 const result = step4
-.method401()
-// ... (160개)
-.method560();
+  .method401()
+  // ... (160개)
+  .method560();
 ```
 
 이렇게 변수를 5개로 나누어서 각각 100여개씩 할당하고 이어가는 방식으로 변경하니, ESLint와
@@ -103,4 +103,4 @@ TypeScript 컴파일러가 정상적으로 동작했어요.
 빌더 패턴의 메서드 체이닝은 가독성과 편의성을 제공하지만, 무한정 길어질 수 있는 것은
 아니에요. JavaScript/TypeScript의 파서는 `AST`를 생성할 때 재귀적으로 동작하기 때문에, 너무
 깊은 체이닝은 콜스택 한계에 도달할 수 있어요. "현대 컴퓨터가 참 나약하다"고 농담할 수 있지만,
-실제로는 설계상의 한계예요.
+실제로는 설계상의 한계예요.

fundamentals/debug/pages/contribute/cursor/cursor_biome_formatting_debug.md

@@ -3,7 +3,6 @@
 <br/>
 <ContributorHeader name="박찬혁" githubUrl="https://github.com/okinawaa" avatar="https://ca.slack-edge.com/E01JAGTHP8R-U06H69MRQMN-07d1cde6565c-512" />
 
-
 ## 진단하기
 
 추석 이후로 Cursor에서 Biome 자동 포맷팅이 갑자기 동작하지 않는 문제가 발생했어요. 코드를
@@ -15,11 +14,14 @@ Biome extension의 Output 로그를 확인해보니 플러그인 버전에 따
 있었어요:
 
 - 최신 플러그인 사용 시:
+
 ```
 Cannot unshim Biome binary at "/Users/chanhyuk.park/Desktop/toss/toss-frontend/biome"
 because it is version 1.x.x. Please update to version 2 or higher.
 ```
+
 - 구버전 플러그인 사용 시:
+
 ```
 Unable to find the Biome binary.
 ```
@@ -35,9 +37,12 @@ Unable to find the Biome binary.
 2. 구글링 → 유의미한 자료를 찾기 어려움
 3. GitHub 이슈 검색 → 비슷한 사례 찾기
 4. 플러그인 수동 설치 시도
+
 - 플러그인이 자동 업데이트되었을 것으로 추정
 - vsix 파일로 수동 설치 시도
+
 5. 동료에게 문의
+
 - 민호님께 사용 중인 플러그인 버전 확인
 - 민호님은 v3.2.0을 마켓플레이스에서 설치해서 정상 동작 중
 
@@ -95,4 +100,4 @@ Biome처럼 로컬 바이너리와 연동되는 플러그인의 경우, 플러
 
 포맷팅이 안 된다고 바로 포기하지 말고, 플러그인의 Output 로그를 확인하는 습관이 중요해요. 이
 경우처럼 에러 메시지가 명확히 원인을 알려주는 경우가 많아요. VS Code/Cursor에서 View →
-Output을 열고 해당 플러그인을 선택하면 상세한 로그를 볼 수 있어요.
+Output을 열고 해당 플러그인을 선택하면 상세한 로그를 볼 수 있어요.

fundamentals/debug/pages/contribute/ios/ios_webview_image_upload_refresh_debug.md

@@ -48,4 +48,4 @@ iOS 웹뷰 라이프사이클 이해의 중요성iOS 웹뷰의 라이프사이
 
 잠재의식의 힘 활용하기때로는 문제에서 잠시 벗어나 휴식을 취하는 것이 해결책을 찾는 데 도움이
 될 수 있습니다. 이 사례처럼 잠재의식이 문제 해결에 기여할 수도 있으니, 막힐 때는 잠시
-쉬어가는 것도 좋은 디버깅 전략이 될 수 있을 것 같아요.
+쉬어가는 것도 좋은 디버깅 전략이 될 수 있을 것 같아요.

fundamentals/debug/pages/contribute/ios/ios_webview_swipe_back_gray_screen_debug.md

@@ -3,7 +3,6 @@
 <br/>
 <ContributorHeader name="김민수" githubUrl="https://github.com/minsoo-web" avatar="https://ca.slack-edge.com/E01JAGTHP8R-U077AFXLDU0-d52a2afee622-512" />
 
-
 ## 진단하기
 
 Vue.js로 개발한 하이브리드 앱에서 iOS의 스와이프 뒤로가기 제스처를 사용할 때 이전 화면이
@@ -21,7 +20,7 @@ Vue.js로 개발한 하이브리드 앱에서 iOS의 스와이프 뒤로가기 
 2. 페이지에서 스크롤 동작 수행
 3. iOS의 스와이프 뒤로가기 제스처 사용
 
-`Vue Router`의 ``scrollBehavior`` 옵션과 관련이 있을 것으로 추정하고, 공식 GitHub 저장소의 이슈를
+`Vue Router`의 `scrollBehavior` 옵션과 관련이 있을 것으로 추정하고, 공식 GitHub 저장소의 이슈를
 검색했습니다. 비슷한 현상을 보고한 이슈에서 Evan You의 답변을 확인할 수 있었습니다. 그는
 이것이 Vue의 문제가 아니라 WKWebView 환경에서 swipe navigation 시 발생할 수 있는 환경적
 문제라고 설명했습니다.
@@ -49,9 +48,9 @@ Vue.js로 개발한 하이브리드 앱에서 iOS의 스와이프 뒤로가기 
 최종 해결 방법은 다음과 같았습니다
 
 - 페이지를 떠나기 전: `Vue Router`의 beforeEach 메서드로 현재 페이지의 이름과 스크롤 위치를
-`Vuex store`에 저장
+  `Vuex store`에 저장
 - 페이지에 진입하기 전: `store`에 저장된 `stack`의 길이와 브라우저 `history`의 길이를 비교하여
-뒤로가기인지 새로운 페이지 진입인지 판단
+  뒤로가기인지 새로운 페이지 진입인지 판단
 - 스크롤 위치 복원: 뒤로가기로 판단되면 저장된 스크롤 위치로 복원
 
 이 방식으로 `Vue Router`의 `scrollBehavior`에 의존하지 않고도 네이티브와 같은 스크롤 유지 경험을
@@ -73,4 +72,4 @@ Vue.js로 개발한 하이브리드 앱에서 iOS의 스와이프 뒤로가기 
 
 라이브러리 의존성 최소화특정 라이브러리의 기능이 환경 제약으로 동작하지 않을 때, 해당 기능을
 직접 구현하는 것도 좋은 해결책이에요. 이를 통해 라이브러리 의존성을 줄이고, 문제 상황에 더
-유연하게 대응할 수 있어요.
+유연하게 대응할 수 있어요.

fundamentals/debug/pages/contribute/ios/tradingview_iframe_memory_leak_debug.md

@@ -3,7 +3,6 @@
 <br/>
 <ContributorHeader name="서상희" githubUrl="https://github.com/tbvjaos510" avatar="https://ca.slack-edge.com/E01JAGTHP8R-U077KGSAD4N-768549fffdd5-512" />
 
-
 ## 진단하기
 
 iOS Safari에서만 발생하는 메모리 누수 문제가 발견되었어요. TradingView 차트를 사용하는
@@ -60,9 +59,11 @@ TradingView 내부에서 이렇게 `AbortController`를 사용한 후, abort()
 문제를 해결하기 위해 단계적으로 접근했어요
 
 ### 1단계
+
 임시 해결책 (긴급 대응)문제가 되는 코드는 TradingView의 내부 코드였기 때문에 직접 수정할 수 없었어요. 급한 대로 `AbortController`의 폴리필을 주입하여 Safari의 버그를 우회하는 방식으로 임시 해결했어요. 이를 통해 사용자들이 겪는 메모리 누수 문제를 빠르게 완화할 수 있었어요.
 
 ### 2단계
+
 근본적인 해결책하지만 폴리필은 어디까지나 임시방편일 뿐이에요. 근본적인 문제를 해결하기 위해 Safari의 렌더링 엔진인 `WebKit`의 소스 코드를 직접 분석했어요.
 그리고 `WebKit` 저장소에 직접 [Pull Request](https://github.com/WebKit/WebKit/pull/50419%EB%A5%BC)를 제출하여 `AbortController`의 메모리 누수 문제를 브라우저 엔진 레벨에서 해결했어요.
 
@@ -72,11 +73,11 @@ WebKit 구현을 바꾸지 않고 `AbortSignal`을 안전하게 사용하려면
 
 ```jsx
 const controller = new AbortController();
-const handler = () => console.log('aborted');
-controller.signal.addEventListener('abort', handler);
+const handler = () => console.log("aborted");
+controller.signal.addEventListener("abort", handler);
 
 // 사용 후 반드시 다음 중 하나를 수행
-controller.signal.removeEventListener('abort', handler); // 이벤트 리스너 제거
+controller.signal.removeEventListener("abort", handler); // 이벤트 리스너 제거
 // 또는
 controller.abort(); // abort 명시적 호출
 ```
@@ -103,4 +104,4 @@ Chrome에서 잘 작동한다고 해서 Safari에서도 동일하게 동작한
 오픈소스 기여를 통한 근본 해결문제의 근본 원인이 브라우저 엔진이나 오픈소스 라이브러리에
 있다면, 폴리필이나 workaround로 임시 해결하는 것에 그치지 말고 해당 프로젝트에 직접 기여하는
 것을 고려해야 해요. 이를 통해 같은 문제를 겪는 전 세계 개발자들에게 도움을 줄 수 있고,
-장기적으로는 더 안정적인 생태계를 만들 수 있어요.
+장기적으로는 더 안정적인 생태계를 만들 수 있어요.

fundamentals/debug/pages/contribute/javascript/javascript_max_number_error_debug.md

@@ -32,10 +32,11 @@ debugger; // 여기서 값이 바뀜을 확인!
 
 const result = await receiveBonusChanceByPushId({ pushId });
 ```
+
 디버거를 통해 Number() 함수를 호출하는 순간 값이 변경된다는 것을 명확히 확인했어요.
 
+### 원인파악
 
-### 원인파악 
 JavaScript의 Number 타입은 IEEE 754 배정밀도(64-bit) 부동소수점 형식을 사용해요. 이 형식에서
 정수의 안전 정밀 범위는 ≤ 2^53 - 1 = 9,007,199,254,740,991이에요.
 
@@ -44,16 +45,17 @@ pushId 값인 17593310758458777은 이 범위를 초과하므로, Number(pushId)
 
 ```jsx
 // JavaScript의 안전한 정수 범위
-Number.MAX_SAFE_INTEGER // 9007199254740991
+Number.MAX_SAFE_INTEGER; // 9007199254740991
 
 // 문제가 되는 pushId
-17593310758458777 > Number.MAX_SAFE_INTEGER // true
+17593310758458777 > Number.MAX_SAFE_INTEGER; // true
 
 // 변환 시 정밀도 손실
-Number("17593310758458777") // 17593310758458776
+Number("17593310758458777"); // 17593310758458776
 ```
 
 ## 수정하기
+
 API에 전달할 때 string 값을 그대로 사용하도록 수정했어요. Number로 변환하지 않고 문자열
 그대로 서버에 보내면 정밀도 손실 없이 정확한 값을 전달할 수 있어요.
 
@@ -65,7 +67,6 @@ await receiveBonusChanceByPushId({ pushId });
 // 수정 후
 const pushId = queryParam; // string 그대로 사용
 await receiveBonusChanceByPushId({ pushId });
-
 ```
 
 ## 재발방지하기
@@ -88,4 +89,4 @@ JavaScript에서 2^53 - 1보다 큰 정수를 다룰 때는 Number 타입으로
 ### Query Parameter 처리 시 주의
 
 URL query parameter는 항상 문자열이에요. 이를 다른 타입으로 변환할 때는 신중해야 해요. 특히
-ID 값처럼 서버에서 생성된 고유 식별자는 원본 형식을 유지하는 것이 가장 안전해요
+ID 값처럼 서버에서 생성된 고유 식별자는 원본 형식을 유지하는 것이 가장 안전해요

fundamentals/debug/pages/contribute/public/tossid_og_image_other_profile_debug.md

@@ -56,21 +56,21 @@ OG 이미지를 그리는 로직이 `Selenium`으로 서버에서 브라우저
 ```jsx
 // 수정 전: 동시에 여러 요청이 같은 브라우저 인스턴스 사용
 async function generateOG(params) {
-	const browser = await getBrowser(); // 공유 리소스
-	const image = await captureScreen(browser, params);
-	return image;
+  const browser = await getBrowser(); // 공유 리소스
+  const image = await captureScreen(browser, params);
+  return image;
 }
 
 // 수정 후: Semaphore로 순차 처리 보장
 const ogSemaphore = new Semaphore(1); // 한 번에 하나의 요청만 처리
 
 async function generateOG(params) {
-	return await ogSemaphore.run(async () => {
-		const browser = await getBrowser();
-		const image = await captureScreen(browser, params);
-	  return image;
-	});
+  return await ogSemaphore.run(async () => {
+    const browser = await getBrowser();
+    const image = await captureScreen(browser, params);
+    return image;
+  });
 }
 ```
 
-이렇게 하면 OG 생성 요청들이 순차적으로 처리되어, 서로 다른 요청이 같은 브라우저 인스턴스를 간섭하지 않게 돼요.
+이렇게 하면 OG 생성 요청들이 순차적으로 처리되어, 서로 다른 요청이 같은 브라우저 인스턴스를 간섭하지 않게 돼요.