docs: add contribution note #64466, #64486, #64754, #65418, #65574

contributions/64466.md

@@ -2,9 +2,32 @@
 pr-url: https://github.com/nodejs/node/pull/64466
 ---
 
+## 문제 내용
+
+Node.js 문서를 읽는 과정에서 여러 오타와 잘못된 용어 표기를 발견했습니다.  
+API 문서, 기여 가이드, Crypto 서브시스템 안내 문서에 포함되어 있었으며, 일부는 ECMAScript 명세 링크의 참조 레이블에도 영향을 주고 있었습니다.
+
+주요 수정 대상은 다음과 같습니다.
+
+- `unresolveable` → `unresolvable`
+- `descendent` → `descendant`
+- `IsStrctEqual` → `IsStrictlyEqual`
+- `writeable` → `writable`
+- `mindfull` → `mindful`
+- `triagging` → `triaging`
+- `verions` → `versions`
+- `forboding` → `foreboding`
+
 ## 해결 과정과 검증
 
-- 발대식 이후 먼저 기여하신 분의 사례를 참고하여 기여를 진행하였습니다. [윤녹두님]
-- 문서 수정
-    - 문서에 있는 오타와 API 명세에 잘못 표기된 내용을 수정하였습니다.
-    - `fast-track` 라벨을 받아 하루 만에 머지되는 경험을 해보았습니다.
+Node.js 저장소의 문서 파일을 검토해 오타를 수정했습니다. 특히 `writeable`은 Node.js API에서 사용하는 `Writable`, `WritableStream`, `napi_writable` 등의 용어와 일관되도록 `writable`로 변경했습니다.
+
+또한 N-API 문서의 ECMAScript Strict Equality 알고리즘 참조는 본문과 링크 레이블을 함께 수정하여, 문서 내 참조가 올바르게 연결되도록 했습니다.
+
+총 8개 문서 파일을 수정했으며, Pull Request의 CI에서 39개 검사가 모두 통과했습니다. 이후 리뷰어들의 승인과 fast-track 절차를 거쳐 `nodejs/node`의 `main` 브랜치에 병합되었습니다.
+
+## 배운 점
+
+작은 문서 수정도 사용자 경험과 프로젝트의 신뢰성에 직접적인 영향을 준다는 점을 배웠습니다. 특히 기술 문서에서는 단순한 철자 교정뿐 아니라, 프로젝트의 기존 용어와 외부 명세의 공식 명칭을 함께 확인해야 합니다.
+
+또한 Node.js의 기여 과정에서 코드 변경이 아닌 문서 변경도 CI, 리뷰, 승인 절차를 동일하게 거친다는 점과, 유지보수자 및 리뷰어의 시간을 존중하는 기여 흐름을 경험했습니다.

contributions/64486.md

@@ -2,8 +2,28 @@
 pr-url: https://github.com/nodejs/node/pull/64486
 ---
 
+## 문제 내용
+
+Node.js의 QUIC 내부 모듈을 확인하던 중, 테스트 커버리지 예외를 설명하는 TODO 주석에 `covrerage`라는 오타가 반복되어 있는 것을 발견했습니다.
+
+오타는 다음 5개 파일에 동일하게 포함되어 있었습니다.
+
+- `lib/internal/quic/diagnostics.js`
+- `lib/internal/quic/quic.js`
+- `lib/internal/quic/state.js`
+- `lib/internal/quic/stats.js`
+- `lib/internal/quic/symbols.js`
+
+기능 동작에는 영향을 주지 않지만, 유지보수자가 TODO의 의도를 빠르게 파악할 수 있도록 용어를 바로잡을 필요가 있었습니다.
+
 ## 해결 과정과 검증
 
-- 오타 수정
-    - 이전 기여 경험을 바탕으로 다시 한번 오타 수정으로 기여해보았습니다.
-    - 이전과 달리 `fast-track` 라벨을 받지 못해, 비교적 긴 시간이 지난 후 머지되는 과정도 경험해보았습니다.
+각 파일의 TODO 주석에서 `covrerage`를 `coverage`로 수정했습니다. 변경 범위는 동일한 오타가 있는 QUIC 모듈 파일 5개로 한정했고, 동작 코드나 관련 없는 문서는 수정하지 않았습니다.
+
+Pull Request 생성 후 Node.js의 린트, QUIC 테스트, 운영체제별 테스트와 빌드 검사가 통과했습니다. 이후 여러 리뷰어의 승인을 받아 2026년 8월 1일 `main` 브랜치에 병합되었습니다.
+
+## 배운 점
+
+작은 오타 수정이라도 변경 범위를 명확히 제한하는 것이 중요하다는 점을 배웠습니다. 특히 AI를 보조 도구로 사용할 때는 제안된 수정 내용을 그대로 넓게 적용하기보다, 실제 문제와 관련된 파일인지 직접 확인해야 합니다.
+
+이번 기여는 기능 개선보다는 코드 주석의 정확성과 유지보수성을 높인 작은 정비 작업이었습니다.

contributions/64754.md

@@ -2,8 +2,20 @@
 pr-url: https://github.com/nodejs/node/pull/64754
 ---
 
+## 문제 내용
+
+스트림 반복자 소비자(`text()`, `textSync()`)는 `options.encoding` 값의 타입을 직접 검사하고 있었습니다. 이 방식은 Node.js 내부에서 공통으로 사용하는 인자 검증 방식과 중복되며, 잘못된 타입의 `encoding` 값에 대한 테스트도 충분하지 않았습니다.
+
 ## 해결 과정과 검증
 
-- 코드 수정
-    - 오프라인 모임에서 설명해주신 Node.js 코드 수정 방법을 활용하여 실제 코드를 수정하고 기여해보았습니다.
-    - 멘토님께서 가이드해주신 기여 포인트 중 하나인 validator 중복 코드를 수정하는 작업으로 기여하였습니다.
+`lib/internal/streams/iter/consumers.js`의 수동 타입 검사를 공통 검증 함수인 `validateString()`으로 교체했습니다. 기존과 같은 오류 동작을 유지하면서, 검증 로직을 다른 내부 API와 일관된 방식으로 정리했습니다.
+
+또한 `test/parallel/test-stream-iter-consumers-text.js`에 문자열이 아닌 `encoding` 값을 전달하는 테스트를 추가했습니다. 비동기 `text()`와 동기 `textSync()` 모두에서 잘못된 입력이 적절히 거부되는지 확인했습니다.
+
+변경은 구현 파일 1개와 테스트 파일 1개로 제한했습니다. 린트, Linux·macOS·Windows 테스트, 커버리지 및 빌드 검사가 통과했으며, 리뷰 승인 후 2026년 8월 1일 `main` 브랜치에 병합되었습니다.
+
+## 배운 점
+
+기존 코드를 공통 검증 유틸리티로 통일하면 오류 형식과 유지보수 방식을 일관되게 관리할 수 있습니다. 또한 리팩터링은 기존 동작을 보존하는 데서 끝나지 않고, 잘못된 입력값을 다루는 테스트를 함께 추가해야 안전하다는 점을 배웠습니다.
+
+이번 변경은 문서나 관련 없는 파일을 건드리지 않고, 스트림 소비자의 입력 검증과 회귀 테스트에만 집중했습니다.

contributions/65418.md

@@ -0,0 +1,21 @@
+---
+pr-url: https://github.com/nodejs/node/pull/65418
+---
+
+## 문제 내용
+
+`Module.builtinModules`에는 사용자 코드에서 접근할 수 있는 내장 모듈만 포함되어야 합니다. 하지만 기존 구현은 실험적 기능 플래그가 비활성화된 경우에도 `node:dtls`, `node:quic`, `node:ffi`, `node:vfs` 같은 scheme-only 내장 모듈을 후보 목록에 먼저 추가한 뒤, CommonJS 초기화 단계에서 다시 제거하고 있었습니다.
+
+이 과정은 실제 `require('node:...')` 접근 정책과 목록 생성 로직이 분리되어 있어, 두 로직의 조건이 달라질 가능성이 있는 구조였습니다.
+
+## 해결 과정과 검증
+
+실험적 기능 플래그 처리 과정에서 이미 구성되는 “사용자에게 허용된 내장 모듈” 집합을 기준으로 `Module.builtinModules`의 scheme-only 항목을 생성하도록 변경했습니다. 이로써 중복된 플래그별 필터링 로직을 제거하고, `Module.builtinModules`와 `require('node:...')`의 접근 정책을 일관되게 유지하도록 했습니다.
+
+`node:test`, `node:sea`, `node:sqlite`처럼 기존에도 노출되던 scheme-only 모듈은 계속 목록에 포함되는지 확인했습니다. 또한 각 실험적 기능 플래그의 활성화·비활성화 상황에서 `Module.builtinModules`의 노출 여부와 `require('node:...')` 동작을 검증하는 테스트를 추가했습니다.
+
+## 기여 회고
+
+같은 정보를 여러 단계에서 각각 필터링하면 시간이 지날수록 동작 불일치가 발생할 수 있다는 점을 배웠습니다. 이미 신뢰할 수 있는 사용자 접근 가능 모듈 집합이 있다면, 이를 단일 기준으로 삼아 파생 목록을 만드는 편이 더 안전하고 유지보수하기 쉽습니다.
+
+또한 실험적 기능은 플래그의 활성화 여부에 따라 공개 API가 달라지므로, 활성화된 경우뿐 아니라 비활성화된 경우까지 테스트하는 것이 중요하다는 점을 확인했습니다.

contributions/65574.md

@@ -0,0 +1,23 @@
+---
+pr-url: https://github.com/nodejs/node/pull/65574
+---
+
+## 문제 내용
+
+Node.js 내부 바인딩 중 `performance` 바인딩에는 TypeScript 선언 파일이 없어, 내부 바인딩을 사용하는 코드에서 제공하는 API와 타입 정보를 정적으로 확인하기 어려웠습니다.
+
+특히 히스토그램 핸들, Performance Observer 관련 훅, 상수, 타이밍 데이터의 형태가 타입 시스템에 표현되어 있지 않아 내부 API 변경 시 타입 검증의 도움을 받을 수 없었습니다.
+
+## 해결 과정과 검증
+
+`typings/internalBinding/performance.d.ts`를 추가하고, `InternalBindingMap`에 `performance` 바인딩을 등록했습니다. 선언 파일에는 히스토그램 핸들, Performance Observer 훅, 상수, 타이밍 데이터 등 실제 바인딩이 제공하는 항목의 타입을 정의했습니다.
+
+구현은 기존 내부 바인딩의 형태와 다른 선언 파일의 작성 방식을 참고해 작성했으며, 변경 범위는 전역 타입 맵과 새 `performance` 바인딩 선언 파일로 제한했습니다.
+
+PR에서 Linux 및 ARM Linux 테스트, 문서 빌드, JavaScript·Markdown·YAML 린트 등 실행된 검사가 통과했습니다.
+
+## 기여 회고
+
+내부 API의 타입 선언은 런타임 동작을 바꾸지 않지만, API 구조를 명확히 하고 이후 변경에서 타입 오류를 빠르게 발견할 수 있게 해준다는 점을 배웠습니다.
+
+AI를 보조 도구로 활용하더라도, 생성된 타입이 실제 바인딩의 속성·반환값·사용 방식과 일치하는지 기존 구현과 선언 패턴을 기준으로 직접 검토하는 과정이 중요하다고 느꼈습니다.