docs: add contribution note #65964, #66292

contributions/65964.md

@@ -0,0 +1,15 @@
+---
+pr-url: https://github.com/nodejs/node/pull/65964
+---
+
+## 문제 내용
+
+기존 `test-module-builtin-experimental.js`에는 실험적 내장 모듈인 `stream/iter`와 `zlib/iter`에 대한 테스트가 빠져 있었습니다. 멘토님이 이 누락을 알려주셔서, 두 모듈의 옵션별 노출 동작을 검증하고자 했습니다.
+
+## 해결 과정과 검증
+
+두 모듈이 기본 설정에서는 노출되지 않고, `--experimental-stream-iter` 옵션을 사용하면 일반 이름과 `node:` 접두사가 붙은 이름으로 모두 불러올 수 있는지 테스트를 추가했습니다. `builtinModules` 목록에 표시되는 이름도 함께 확인했습니다. 변경 사항은 [PR #65964](https://github.com/nodejs/node/pull/65964)로 제출해 병합되었습니다.
+
+## 기여 회고
+
+멘토님의 피드백을 통해 기존 테스트가 모듈의 실제 노출 범위를 모두 다루고 있는지 살펴보는 것이 중요하다는 점을 배웠습니다. 다음에는 모듈 등록 정책을 더 살펴보고, 실험적 옵션의 누락을 찾기 쉬운 구조를 고민해 보겠습니다.

contributions/66292.md

@@ -0,0 +1,34 @@
+---
+pr-url: https://github.com/nodejs/node/pull/66292
+---
+
+## 문제 내용
+
+옵션에 따라 노출되는 내장 모듈의 정책이 `realm.js`와 `pre_execution.js`의 개별 초기화 함수에 나뉘어 있었습니다. 이 구조에서는 새 내장 모듈을 추가할 때 관련 설정이나 테스트를 빠뜨리기 쉬웠고, 실제로 PR #65964에서 `stream/iter`와 `zlib/iter`의 테스트 누락을 별도로 보완해야 했습니다. 노출 정책을 한곳에서 확인하고 정책 자체를 기준으로 테스트할 수 있는 구조가 필요했습니다.
+
+## 해결 과정과 검증
+
+JavaScript 로더가 관리하는 스킴과 옵션별 노출 정책을 하나의 테이블로 모았습니다.
+
+C++ 영역에 노출 정책을 두는 방안도 검토했지만, 네이티브 옵션 등록 정보만으로는 어떤 옵션이 어떤 내장 모듈을 노출하는지 알 수 없었습니다. 하나의 옵션이 `stream/iter`와 `zlib/iter`처럼 여러 모듈을 활성화할 수 있고, 내장 모듈 노출과 관계없는 옵션도 같은 방식으로 등록되기 때문입니다.
+
+코드 캐시 분류 정보에 노출 조건을 추가하는 방법도 목적에 맞지 않았습니다. 코드 캐시는 모듈의 컴파일과 캐싱을 관리하지만, 노출 정책은 사용자가 모듈을 불러올 수 있는 조건을 결정합니다. 여기에 노출 정보를 추가하면 서로 다른 책임이 결합되고, C++과 JavaScript 양쪽에서 같은 정책을 관리해야 합니다.
+
+따라서 실제 내장 모듈 노출을 담당하는 JavaScript 로더를 정책의 단일 출처로 선택했습니다. `realm.js`에서 모듈별 스킴 제한과 필요한 옵션을 선언하고, 옵션 초기화가 끝난 뒤 `pre_execution.js`가 이를 적용하도록 구성했습니다. 이를 통해 C++ 영역의 기존 책임을 유지하면서 노출 규칙을 한곳에서 확인하고 테스트할 수 있게 했습니다.
+
+새 정책 테스트는 선언된 모든 내장 모듈 ID와 옵션을 순회하며 기본 상태, `--no-experimental-*`, `NODE_OPTIONS`, 명령줄 우선순위를 확인합니다. CommonJS와 ESM뿐 아니라 Worker, 자식 프로세스, `process.getBuiltinModule()`을 통한 접근도 검증했습니다.
+
+리뷰에서 Worker 테스트가 별도의 하드 코딩 목록 때문에 정책 변경을 따라가지 못할 수 있다는 피드백을 받았습니다. 이에 `workerPolicyIds`를 제거하고, 옵션이 필요한 모든 정책으로부터 테스트 대상을 자동으로 만들도록 수정했습니다. 같은 옵션을 공유하는 정책은 함께 묶어 활성화와 비활성화 형태를 모두 검사했습니다.
+
+다음 명령으로 변경 사항을 검증했습니다.
+
+```sh
+make -C out -j4 node
+python3 tools/test.py -j4 parallel/test-module-builtin-policies parallel/test-module-builtin-experimental parallel/test-sqlite
+```
+
+## 기여 회고
+
+정책을 한곳에 모으는 것만큼 테스트가 그 정책을 직접 따라가도록 만드는 것이 중요하다는 점을 배웠습니다. 테스트 대상을 별도로 나열하면 구현과 테스트가 서로 다른 시점에 변경되어 다시 누락이 생길 수 있습니다. 또한 네이티브 옵션이나 코드 캐시 분류처럼 비슷해 보이는 정보라도 책임이 다르면 억지로 결합하지 않고, 실제 정책을 소유한 계층에 두어야 한다는 점도 알게 되었습니다.
+
+정책 테이블에 내장 모듈 자체를 추가하지 않는 실수까지 자동으로 찾을 수는 없지만, 노출 규칙을 단일 위치에서 관리함으로써 누락 가능성을 줄이고 이후 변경을 검토하기 쉬워졌습니다.