#3-7. 트랜스파일 적합성 9.5%→74.1%

기간: 2026년 3월 24~25일 (2일) 커밋: 145개 (90 + 55) 세션: 3/24 5개 (가장 긴: 21802cc2 — 74개 메시지), 3/25 2개 (7abe820d — 101개 메시지!) 핵심: TS 파서 전면 보강, Test262 100% 유지, 런타임 에러 전해소, SIMD + 병렬 파싱

#적합성 테스트란?

Test262는 파서가 올바른지 검증한다. 적합성 테스트는 트랜스파일 결과가 올바른지 검증한다 — esbuild와 SWC의 트랜스파일 출력과 ZTS의 출력을 비교한다.

ffee825 feat(test): esbuild+SWC 트랜스파일 적합성 테스트 추가

처음 측정한 적합성: 9.5%. 파서가 TS 타입 구문을 제대로 처리하지 못하는 게 가장 큰 원인이었다.

#3/24: 9.5% → 58.8% — "하루에 50%p를 올리다"

#세션 21802cc2 — 스모크 테스트 확장 + 브라우저 E2E

이 세션의 첫 요청은 이전 세션에서 미해결된 패키지들:

"우리도 걍 아이덴티파이어로 하면 안돼?" — contextual keyword 처리 방식 "난이도가 어려운거야 코드가 고칠게 많은거야?"

TS contextual keyword 30개를 identifier로 통합하는 대규모 리팩터링:

c41d209 refactor(lexer): TS contextual keyword 30개를 identifier로 통합

브라우저 E2E 테스트 요구:

"그리고 브라우저 테스트 E2E도 해봐야 하는거아니야? 지금 노드 테스트만 하고 있어서 플레이라이트 CLI로 해줘"

8483969 feat(e2e): 브라우저 스모크 테스트 추가 (Playwright, 8개 패키지)

정규식 파서 에러 처리:

"그전에 정규식 파서 에러는 OXC, esbuild는 어떻게 거르는데?" "우리도 경고로만 처리하자" — 정규식 검증 에러를 에러→경고로 격하

4e19996 feat(smoke): 스모크 테스트 47→59개 + regex 검증을 경고로 격하

deconflict(이름 충돌 해결) 방식:

"oxc, esbuild는 어떻게 해?" "왜 롤다운은 하드코딩 자동수집 같이해요?" "중첩스코프는?" "그럼 중첩스코프는 롤다운 방식으로 하는게 좋을거같아요"

46d0389 refactor(linker): scope hoisting deconflict — 상수 글로벌 목록 → 자동 수집

#세션 76eb6949 — 적합성 집중 개선

"gentle-booping-muffin.md에 있는 플랜대로 작업해줘"

이 세션에서 적합성이 폭발적으로 올라갔다.

쌍따옴표 결정:

"궁금한거 쌍따옴표랑 홑따옴표 차이점은?" "다른 번들러는 어떻게하고 있어요?" "좋아요 쌍따옴표로 가고 옵션 추가해주시죠"

b7289a6 feat(codegen): 기본 따옴표 쌍따옴표로 변경 + --quotes 옵션 추가

제네릭 > 토큰 분할:

TypeScript에서 Array<Map<string, number>>의 마지막 >>는 두 개의 > 토큰으로 분할되어야 한다:

"파서 구조 변경은 어떤걸 말씀하시는걸까요?" "근데 궁금한게 있습니다 다른 파서들도 허용하나요?" "네 해주세여"

53692f5 feat(parser): 제네릭 > 토큰 분할 — 적합성 27.2%→28.4%
83329aa feat(parser): << left angle 토큰 분할 — Array<<T>() => T> 지원

TSX 제네릭 화살표 함수 — 가장 까다로운 모호성:

const f = <T>(x: T) => x;  // TypeScript: 화살표 함수
const e = <T>text</T>;     // TSX: JSX 엘리먼트

"Expression expected (TSX 특수 비표준이여도 해결되어야 하는거 아니야??" "oxc는 저 패턴 처리해?"

esbuild의 3-tier disambiguation 전략을 참고:

a38ac5d feat(parser): TSX 제네릭 arrow + 중첩 제네릭 — 적합성 55.9%
abc25c3 fix(parser): TSX generic arrow <Foo<<T>(x:T)=>T>/> 파싱

적합성 시간별 진행:

#50% 돌파

931eb13 feat(parser,transformer): 50% 돌파 — 적합성 49.7%→50.9%

"지금 수정으로 몇개 올라간거야?" — 매번 수치를 확인 "이제 남은건 뭐 있어?" — 다음 타겟 설정

#Test262 100% 유지하면서 적합성 올리기

적합성 수정 과정에서 파서를 많이 건드렸는데, 그때마다 Test262가 깨지는 일이 있었다:

98ca356 fix(parser,regexp): Test262 language 100% 복구

"Test262 98.5% (49915/50650) 이거 왜 줄었어?" — 3/25 세션에서 확인 "아직 확정 안된 제안이랑 레거시 구문엔 뭐가 있는거야?"

#3/25: 58.8% → 74.1% — "런타임 에러 전해소"

#세션 7abe820d — 프로젝트 최다 메시지 (101개!)

"메인브랜치 최신화 후 런타임 에러 진행해줘" "적합성 테스트의 Error 58건요"

런타임 에러 vs 포맷 차이:

• 에러(Error): 변환된 코드가 실행 시 런타임 에러 → 심각
• 실패(Fail): 코드는 동작하지만 출력 포맷이 다름 → 미용적

#oxc 방식으로의 전환

적합성 에러를 수정하면서, 기존 접근 방식으로는 한계가 있다는 것이 드러났다:

"어 수정해줘" "oxc는 어떻게 하고 있나요??" "1번으로 가려면 얼마나 많은걸 고쳐야 하는데여?" "파서 트리 어떻게 바꿔야 하는데여?" "안정적으로 가려면 oxc가 나은건 확실한거죠?" "회귀테스트 빡세게 되어있으니 oxc로 갑시다"

Test262 50,504건이 안전망 역할을 했기에 대규모 리팩터링도 두렵지 않았다.

#병렬 에이전트 활용

"적합성 다음 작업 메모리대로 병렬 에이전트로 실행해줘"

여러 수정을 동시에 진행:

• 에이전트 1: enum await/yield + JSX spread children
• 에이전트 2: import/export type (unicode escape, type as as)
• 에이전트 3: decorator await + namespace panic

"이제 남은건 뭐죠?" — 매번 남은 작업 확인 "네 병렬로 가능한거면 병렬로 진행해주세요"

#런타임 에러 제거

"실제 런타임 에러는 지금 문서가 업데이트 덜된건가요? 아님 진짜 수정이 필요한가요?" "넵 저거 수정해주세여"

"이제 런타임 진짜 에러 안나나요?" — 최종 확인 "이넘 테스트가 8건이라구요? 1개라 하지 않았어요?" — 수치 검증

#enum IIFE에 @PURE + return 패턴

"이넘 리턴 패턴 저거 실행에 상관없지 않아여?" "esbuild는 왜 퓨어가 붙어요?" "우리도 붙이는게 좋을거 같아영" "하는거 안하는거 장단점 설명 좀"

39e3bd8 feat(codegen): enum IIFE에 @__PURE__ + return 패턴 적용

#SIMD + 병렬 파싱

"멀티 스레드 먼저 넣으면 문제 생기나요?" "네 개선해주세요"

361057f feat(lexer): SIMD 공백 스킵 + 식별자 스캔 (@Vector 16바이트)
96eec6d feat(bundler): 병렬 파싱 (std.Thread.spawn per module)

"실제는 왜 느려요?" — 벤치마크 결과가 기대 이하 "파서 개선이 왜 어렵죠?"

#ES 다운레벨링 시작

"다운 레벨링이랑 b3는 어느게 먼저하는게 나은데?" "cli 옵션은?" "oxc swc webpack babel 다?"

다운레벨링 구조에 대한 깊은 논의:

"다운레벨링에 대한거 좀 간편하게 푸는법은 없어요? 그렇게 매번 분기 태우면 코드 집중도가 .." "oxc, swc, webpack, rspack 등은요?" "어느게 유지보수에 유리해요?" "비트마스크 가드는 누가하는데" "근데 oxc는 왜 그렇게 하는걸까?" "번은 어떻게 하고 있는데" — Bun 참조 "좋아 그렇게 가자" — 비트마스크 가드 방식 결정

96a5359 feat: ES 다운레벨링 — --target + ?? / ??= / ||= / &&= 변환

#최종 상태 (3/25 기준)

Test262:        50,504/50,504 (100.0%)
적합성:         74.1% (822/1110)
  - 에러:       4건 (ternary edge case만)
  - Fail:       284건 (대부분 포맷 차이)
스모크 테스트:   111/111 (TS-heavy 12개 포함)
브라우저 E2E:   95/95 (Playwright)
런타임 에러:     0건 (전부 해소!)

남은 에러 4건은 모두 ternary expression의 극단적 엣지 케이스:

x = a ? (b = c) : d => e
x = a ? b = (c) : T => d : e
for (x = a ? () : T => b in c : d; ; )

TypeScript 파서조차도 올바르게 처리하기 어려운 케이스들이다.