Rust로 test262 읽기, 1주차: 실행기보다 분석기부터
2026년 03월 16일
Story
엔진을 만들기 전에, 테스트 파일 하나를 제대로 읽는 것부터 시작했어요.
요즘 Rust로 test262를 공부하고 있어요. 목표는 단순히 테스트를 돌리는 도구를 만드는 게 아니라, JavaScript 런타임이 어떤 전제를 가지고 동작하는지 더 낮은 레벨에서 이해하는 거예요.
처음에는 곧바로 parser나 evaluator부터 만들고 싶었지만, 1주차는 일부러 더 작은 범위로 잘랐어요. test262 테스트 파일 하나를 읽고, 그 안의 frontmatter metadata와 body를 분리해서 구조적으로 다루는 데까지만 가보기로 했어요.
test262 파일의 frontmatter metadata를 Rust struct로 파싱하는 작은 CLI를 만들었어요. flags, features, includes, negative 등 테스트 실행 조건을 구조화해두면, 이후 실행기를 붙일 때 판정 로직이 훨씬 명확해져요.실행기까지 한 번에 가면 구현량이 갑자기 커져요. frontmatter를 먼저 읽기 시작하면 test262가 어떤 형식과 규칙을 갖고 있는지부터 차분히 볼 수 있어요.
test262는 JavaScript 엔진 구현체가 ECMAScript 스펙을 얼마나 잘 따르는지 검증하는 공식 테스트 스위트예요. 그래서 이 프로젝트를 따라가다 보면 자연스럽게 스펙, 테스트, 런타임 구현이 어떻게 연결되는지 보게 돼요.
중요한 건, test262 파일은 단순한 JavaScript 코드 조각이 아니라는 점이에요. 이 테스트가 어떤 조건에서 돌아야 하는지에 대한 정보도 함께 담고 있어요.
description: 이 테스트가 무엇을 검증하는지flags: strict mode 같은 실행 조건features: 필요한 언어 기능includes: 함께 로드해야 하는 harness 파일negative: 실패가 정상인 테스트인지, 어느 단계에서 어떤 에러가 나야 하는지이 정보를 먼저 읽을 수 있어야, 나중에 실행기를 붙일 때도 어떤 분기와 판정 규칙이 필요한지 훨씬 명확해져요.
1주차 목표는 아주 단순했어요.
test262 파일 포맷을 이해한다cargo run -- parse <path>로 샘플 파일 하나를 분석한다반대로 이번 주에 하지 않기로 한 것도 분명히 정했어요.
test262 통과 시도현재 1주차 코드에서는 parse 중심의 작은 CLI를 만들었어요.
cargo run -- parse fixtures/sample-test262/exercise-metadata.js이 명령은 테스트 파일을 읽고 다음 흐름으로 처리해요.
TestMetadata 구조체로 파싱한다Rust 쪽 데이터 구조도 아주 단순하게 시작했어요.
descriptionflagsfeaturesincludesnegative.phasenegative.type특히 이번 주에는 아래 케이스까지 직접 처리하도록 구현했어요.
flags: [onlyStrict] 같은 inline listfeatures, includes의 block listnegative 블록의 phase, type구현 범위는 작지만, 이 정도만 되어도
test262파일을 그냥 텍스트로 보는 것과 구조로 읽는 것의 차이가 꽤 크게 느껴져요.
이번 작업에서 Rust가 특히 잘 맞는다고 느낀 부분은 데이터 경계를 명확하게 만드는 경험이었어요.
테스트 파일을 읽었을 때:
이런 식으로 책임을 나누는 과정이 자연스럽게 코드 구조로 드러나요. 아직 ownership을 깊게 활용한 단계는 아니지만, 적어도 "무엇을 어떤 형태로 들고 있을지"를 일찍 결정하게 만든다는 점이 좋았어요.
또 하나 흥미로웠던 건 에러 처리예요. frontmatter가 없거나 닫히지 않았을 때를 ParseError로 분리해두니, 이후에 parser를 더 붙이더라도 실패 지점을 단계별로 다루기 쉬워 보였어요.
가장 크게 배운 건 test262를 실행기 관점보다 파일 포맷 관점에서 먼저 보는 게 생각보다 중요하다는 점이에요.
보통은 "JavaScript를 실행한다"는 쪽으로 바로 생각이 가는데, 실제 test262는 그 전에 읽어야 할 규칙이 많아요. strict 전용인지, 특정 feature가 필요한지, parse 단계에서 실패해야 하는지 같은 정보는 전부 metadata 쪽에 있어요.
학습 방식 측면에서는 "작게 자르기"가 가장 유효했어요. 1주차부터 엔진처럼 보이는 코드를 만들려 하기보다, 파일 하나를 제대로 읽는 데 집중하니 오히려 다음 단계가 더 구체적으로 보였어요.
다음 단계에서는 이번 주에 파싱한 metadata를 실제 판정 흐름과 연결해보려고 해요.
negative가 붙은 테스트는 어떤 실패를 정상으로 볼지1주차가 "파일을 읽는 단계"였다면, 그 다음은 "읽은 정보를 바탕으로 실행 정책을 세우는 단계"가 될 것 같아요.
이번 주는 겉으로 보면 소박해요. 아직 JavaScript를 실행하지도 못하고, parser도 만들지 않았어요. 하지만 개인적으로는 그래서 더 좋았어요.
test262를 Rust로 공부하는 이 프로젝트는 결국 엔진 흉내를 내는 게 아니라, 스펙과 테스트와 구현 사이의 연결을 몸으로 이해하는 과정이라고 생각해요. 그 첫 주로 frontmatter parser를 만든 건 꽤 괜찮은 선택이었어요.
다음 주에는 여기서 한 걸음 더 나아가, 읽어낸 metadata를 실제 실행 판정과 연결해볼 생각이에요.