# JustHTML을 Python에서 JavaScript로 포팅: Codex CLI와 GPT-5.2로 4.5시간 만에 완성

> Clean Markdown view of GeekNews topic #25171. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25171](https://news.hada.io/topic?id=25171)
- GeekNews Markdown: [https://news.hada.io/topic/25171.md](https://news.hada.io/topic/25171.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-19T05:33:12+09:00
- Updated: 2025-12-19T05:33:12+09:00
- Original source: [simonwillison.net](https://simonwillison.net/2025/Dec/15/porting-justhtml/)
- Points: 7
- Comments: 1

## Summary

**HTML5 파서 JustHTML**이 **Python에서 JavaScript로 완전 포팅**되며, Codex CLI와 GPT‑5.2가 약 4.5시간 만에 9,000줄의 코드를 자동 생성했습니다. 새 라이브러리 **JustJSHTML**은 **의존성 없는 HTML5 파서**로 9,200개 테스트를 통과하며 원본 API를 그대로 재현했습니다. 이번 실험은 LLM이 언어 간 포팅과 같은 구조적 개발을 자율적으로 수행할 수 있음을 보여주는 동시에, **저작권과 신뢰성 문제**에 대한 새로운 논의를 불러일으킵니다.

## Topic Body

- **HTML5 파서 JustHTML**을 Python에서 **JavaScript로 완전 포팅**한 사례로, Codex CLI와 GPT-5.2를 이용해 약 4.5시간 만에 구현  
- 새 라이브러리 **JustJSHTML**은 **의존성 없는 HTML5 파서**로, html5lib-tests의 **9,200개 테스트를 통과**하며 원본 API 설계를 그대로 재현  
- 전체 과정은 **8개의 프롬프트**와 몇 차례의 후속 명령으로 진행되었고, GPT-5.2가 **9,000줄의 코드와 43개의 커밋**을 자동 생성  
- 프로젝트는 **자동 커밋·테스트·문서화·플레이그라운드 페이지 생성**까지 포함해 완전한 오픈소스 형태로 완성  
- 이번 실험은 **LLM 기반 코딩 에이전트의 실질적 생산성**과 함께, **저작권·윤리·신뢰성 문제**를 새롭게 제기  

---
### 프로젝트 개요
- **JustHTML**은 Emil Stenström이 개발한 **표준 준수 HTML5 파서**로, Python으로 작성되어 html5lib-tests 전체를 통과하는 구현체  
  - html5lib-tests는 HTML5 파서 간 **상호운용성 테스트의 표준**으로, Servo의 html5ever 등 다양한 프로젝트에서 사용  
- Simon Willison은 이 프로젝트를 **JavaScript로 직접 포팅**하기로 결정, Codex CLI와 GPT-5.2를 활용해 최소한의 수작업으로 진행  
- 결과물 **JustJSHTML**은 **브라우저와 Node.js 환경 모두에서 동작**하며, **외부 의존성 없이 순수 JavaScript로 작성**  

### 개발 과정
- 로컬 환경에서 justhtml, html5lib-tests 저장소를 클론하고, 새 디렉터리 justjshtml을 생성  
- Codex CLI를 `--yolo` 옵션(승인 및 샌드박스 우회)으로 실행해 GPT-5.2 모델을 구동  
- 첫 프롬프트에서 기존 Python 코드를 분석해 **새 JavaScript API 명세(spec.md)** 를 작성하도록 지시  
  - 초기 단계(Milestone 0.5)로 **간단한 HTML 문서 파싱 테스트**를 통과하는 버전 구현  
- 이후 단계별로 “**Implement Milestone 0.5**”, “** commit and push often**” 등의 명령을 통해 자동 개발 진행  
  - GitHub Actions를 설정해 **모든 커밋마다 테스트 실행**  
  - 총 **43개의 커밋**, **9,000줄 코드**, **9,200개 테스트 통과** 결과 생성  

### 결과 및 산출물
- Codex CLI는 총 **2,089,858개의 토큰**을 사용했으며, ChatGPT Plus 월 구독 내에서 추가 비용 없이 수행  
- 완성된 라이브러리는 다음 기능 포함  
  - **stream()** , **query()/matches()** , **toMarkdown()** 등 API 확장  
  - **no-deps 단위 테스트 스크립트** 및 CI 통합  
  - `<br>` 태그 처리 오류 수정 등 세부 버그 해결  
- **playground.html**을 자동 생성해 브라우저에서 직접 테스트 가능  
  - GitHub Pages를 통해 [https://simonw.github.io/justjshtml/playground.html](https://simonw.github.io/justjshtml/playground.html)에서 실행  
- **README.md**에는 사용법, 빌드 과정, Node.js 및 HTML 환경 예시 포함  

### LLM 활용의 시사점
- **GPT-5.2**는 수백 회의 도구 호출과 수시간의 연속 작업을 **최소 감독으로 완수**  
- **테스트 주도형 문제 정의**가 가능할 경우, 코딩 에이전트가 **자율적으로 완성도 높은 코드**를 생성 가능  
- **언어 간 포팅**과 같은 구조적 작업은 LLM이 매우 효율적으로 수행  
- 코드 생성 비용이 사실상 **‘거의 무료’ 수준**으로 하락, 단 **검증된 코드 유지 비용**은 여전히 존재  

### 제기된 윤리적·법적 질문
- Rust 및 Python 원본 코드의 **저작권 침해 여부**  
- LLM이 생성한 코드의 **저작권 귀속 문제**  
- 이러한 방식의 개발이 **오픈소스 생태계에 미치는 영향**  
- **자동 생성 코드의 신뢰성**과 **프로덕션 사용의 책임성**  
- 인간 전문가가 수개월간 개발한 코드와의 **품질 비교 가능성**  

### 결론
- 이번 사례는 **프로그래밍 자동화의 새로운 단계**를 보여주며, **AI 코딩 에이전트의 실용적 잠재력**을 입증  
- 동시에 **법적·윤리적 기준 정립의 필요성**과 **오픈소스 협업 방식의 재정의**라는 과제를 남김

## Comments



### Comment 47974

- Author: neo
- Created: 2025-12-19T05:33:13+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46295771) 
- 이번 사례에서 가장 흥미로운 점은 **언어 독립적인 테스트**를 기반으로 한 라이브러리 포팅 프로젝트가 훨씬 현실적으로 가능해졌다는 점임  
  핵심은 [html5lib-tests](https://github.com/html5lib/html5lib-tests)라는 9,000개 이상의 HTML5 파서 테스트 모음임. Servo의 html5ever(Rust), Emil의 JustHTML(Python), 그리고 내 JavaScript 버전 모두 이 테스트를 활용함  
  코딩 에이전트를 이용해 Python 코드를 JavaScript로 포팅하고, 모든 테스트를 통과할 때까지 자동으로 반복 실행시킬 수 있었음  
  이런 **표준화된 테스트 스위트**는 흔치 않지만, 존재하는 곳에서는 큰 가능성을 보여줌  
  - WHATWG 스펙과 html5lib 테스트를 결합하면 훨씬 강력해짐  
    나는 어제 몇 시간 만에 OCaml로 타입이 명시된 버전을 만들었고, 순수 OCaml HTML5 **validator**를 자동으로 빌드하도록 에이전트를 돌려둠  
    html5lib 테스트와 [validator 테스트](https://github.com/validator/validator/tree/main/tests)를 결합해 의존성이 적은 OCaml HTML5 validator를 만들고 있음  
    이건 마치 **역방향 형식 검증**처럼 느껴짐 — 흩어진 사실(테스트)에서 구조화된 명세로 수렴하는 과정임  
  - 어제 Python에서 Rust로 포팅하다가 LLM이 문제를 전혀 못 잡았음. 결국 Python 원본을 Rust 프로젝트에 복사해 비교하자 바로 해결됨  
    언어 간 **패턴 매칭**에는 꽤 강한 듯함. 잠재 공간(latent space) 관점에서 보면 이해가 감  
  - 다음 단계는 프로젝트의 종속적인 테스트를 **독립 포맷으로 변환**해 원본과 검증한 뒤 포팅하는 과정일 것 같음  
  - LLM은 언어 간 포팅에 매우 강함. **MLE-Bench** 같은 벤치마크에서 에이전트들이 24시간 내에 Kaggle 대회를 메달권으로 해결하는 수준임  
    [AI4AI 논문](https://arxiv.org/abs/2506.16499)처럼 AI가 AI를 만드는 시대가 이미 시작된 느낌임  
  - 이런 이유로 현재 프로젝트의 테스트는 공개하지 않기로 함. 평소엔 오픈소스로 배포하지만 이번엔 재고 중임  

- 사실 Firefox의 HTML5 파서는 원래 Java로 작성되었고, 이후 반자동으로 Gecko용 C++로 변환되었음  
  JustHTML 포팅 자체는 좋은 실험이지만, 개인적으로는 Java 코드를 TypeScript로 옮기는 게 더 생산적이었을 것 같음  
  - 놀랍게도 Firefox의 Java 파서가 아직도 유지되고 있음  
    [관련 폴더](https://github.com/mozilla-firefox/firefox/tree/main/parser/html/java)와 [최근 커밋](https://github.com/mozilla-firefox/firefox/commits/main/parser/html/javasrc)을 보면 11월에도 업데이트가 있었음  
  - 더 나은 방법은 많았지만, Emil의 **API 디자인**이 마음에 들어 JustHTML을 기반으로 삼았음  
    그가 1,000개 이상의 커밋으로 만든 라이브러리를 하루 저녁에 Python으로 포팅해보는 게 흥미로웠음  
  - 법적 관점에서 보면, 언어를 바꿔 포팅한 코드도 여전히 **파생 저작물**임  
    MIT 라이선스라면 원본의 저작권 표시와 라이선스 문구를 그대로 포함해야 함  
    즉, 원본의 저작권 라인 아래에 자신의 저작권 정보를 추가하는 게 옳음  
  - 디버깅과 감사 측면에서는 JavaScript로 작성하는 게 더 낫다고 생각함  
    TypeScript의 장점은 개발자 경험 개선인데, **기계 생성 코드**에서는 그 필요성이 줄어듦  

- “코드는 거의 공짜다”라는 말에 대해, 실제 비용은 사람이 코드를 **이해하고 수정할 수 있는지**에 달려 있음  
  LLM이 만든 코드도 결국 복잡한 버그나 맥락 문제에서는 인간의 개입이 필요함  
  - 하지만 언젠가는 유지보수보다 새로 만드는 게 더 싸고 빠른 세상이 올지도 모름  

- 원본 저장소의 테스트 결과를 보면 html5lib-tests의 9,000개 테스트를 모두 통과함  
  하지만 브라우저마다 처리 방식이 다름. 예를 들어 selectolax는 html5lib 기준 68%지만 Chrome과 비교하면 90% 이상 일치함  
  - 이건 **네임스페이스 처리** 문제임. `<svg title>`은 SVG 전용 태그로 파서가 이를 인식해야 함  
    Chrome에서도 테스트를 돌려보면 흥미로울 듯함  

- 최근 HN에 올라온 ["소프트웨어 비용이 90% 줄었다"](https://martinalderson.com/posts/has-the-cost-of-software-just-dropped-90-percent/)는 글과도 맥락이 닿음  
  - 다만 그 글은 단순화된 주장임. Simon의 실험이 가능했던 건 **언어 독립 테스트 9,000개**와 **기존 API 설계**가 있었기 때문임  
    대부분의 프로젝트는 이런 조건이 없기 때문에 일반화하기 어려움  

- 저작권과 윤리 문제에 대해, 나는 MIT 라이선스 프로젝트를 **Claude Code**로 Rust/Python 버전으로 포팅 중임  
  오픈소스의 정신은 기존 코드를 개선하며 생태계를 발전시키는 것이라 생각함  
  단, **GPL 프로젝트는 절대 포팅하지 않음**  
  - 어떤 라이선스든 저작권은 존중해야 하며, LLM이 만든 포팅도 파생 저작물로 간주됨  
  - GPL을 선택한 개발자는 명확한 의도를 가진 것이므로, LLM을 이용해 **라이선스 우회**를 시도하는 건 그 정신을 훼손하는 일임  

- “이런 방식으로 만든 뒤에야 법적·윤리적 문제를 묻는 건 무책임하다”는 비판도 있었음  
  - 하지만 나는 이 논의를 **촉발시키기 위해** 일부러 위험을 감수했음  
    지금은 이런 일이 “가능할 뿐 아니라, 놀라울 정도로 쉽다”는 걸 보여주는 게 중요하다고 생각함  

- **오라클 접근법**을 쓰면 표준 테스트가 없어도 실용적임  
  원본 프로그램의 입력/출력을 캡처해 테스트로 삼고, Hypothesis 같은 도구로 수천 개의 케이스를 자동 생성할 수 있음  
  이제는 코드베이스 대신 **테스트 스위트 자체가 핵심 자산**이 되는 시대임  
  - 실제로 **테스트만으로 앱 전체를 만들 수 있을까** 하는 생각도 듦  

- GPT-5.2가 9,000줄의 완전한 JavaScript 코드를 생성하는 데 $28.31이 들었음  
  이런 효율이라면 5~10년 내에 **주니어·미드급 개발자**의 역할이 크게 줄어들 것 같음  
  [비용 계산 링크](https://www.llm-prices.com/#it=1464295&cit=97123000&ot=625563&ic=1.75&cic=.175&oc=14) 참고  
  - 하지만 이는 기존 프로젝트를 **포팅**하는 이상적인 사례임. 새 라이브러리를 처음부터 만드는 건 여전히 다름  
    그래도 작은 생태계를 가진 언어에는 큰 경제적 변화가 생길 것임  
  - “소프트웨어 엔지니어”라는 개념은 사라지지 않고, 역할과 기대치가 변할 뿐임  
  - “우리가 하루 종일 하는 일이 언어 포팅뿐이냐”는 반박도 있었음. 현실은 훨씬 복잡함  

- 모든 AI 포팅이 성공적인 건 아님. 실패 사례도 있음 → [The port I couldn’t ship](https://ammil.industries/the-port-i-couldnt-ship/)  
  - 성공 여부는 **소스 코드 대비 테스트 비율**에 크게 좌우됨  
    어떤 프로젝트가 쉬운지, 어떤 접근이 빠른지에 대한 데이터가 쌓이면 흥미로운 분석이 될 것임  
    Simon이 이런 비교 실험을 해준다면 정말 흥미로울 것 같음