▲

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

 (simonwillison.net)
4P by GN⁺ 22시간전 | ★ favorite | 댓글 1개
  • 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을 자동 생성해 브라우저에서 직접 테스트 가능
  • README.md에는 사용법, 빌드 과정, Node.js 및 HTML 환경 예시 포함

LLM 활용의 시사점

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

제기된 윤리적·법적 질문

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

결론

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

  • 이번 사례에서 가장 흥미로운 점은 언어 독립적인 테스트를 기반으로 한 라이브러리 포팅 프로젝트가 훨씬 현실적으로 가능해졌다는 점임
    핵심은 html5lib-tests라는 9,000개 이상의 HTML5 파서 테스트 모음임. Servo의 html5ever(Rust), Emil의 JustHTML(Python), 그리고 내 JavaScript 버전 모두 이 테스트를 활용함
    코딩 에이전트를 이용해 Python 코드를 JavaScript로 포팅하고, 모든 테스트를 통과할 때까지 자동으로 반복 실행시킬 수 있었음
    이런 표준화된 테스트 스위트는 흔치 않지만, 존재하는 곳에서는 큰 가능성을 보여줌

    • WHATWG 스펙과 html5lib 테스트를 결합하면 훨씬 강력해짐
      나는 어제 몇 시간 만에 OCaml로 타입이 명시된 버전을 만들었고, 순수 OCaml HTML5 validator를 자동으로 빌드하도록 에이전트를 돌려둠
      html5lib 테스트와 validator 테스트를 결합해 의존성이 적은 OCaml HTML5 validator를 만들고 있음
      이건 마치 역방향 형식 검증처럼 느껴짐 — 흩어진 사실(테스트)에서 구조화된 명세로 수렴하는 과정임
    • 어제 Python에서 Rust로 포팅하다가 LLM이 문제를 전혀 못 잡았음. 결국 Python 원본을 Rust 프로젝트에 복사해 비교하자 바로 해결됨
      언어 간 패턴 매칭에는 꽤 강한 듯함. 잠재 공간(latent space) 관점에서 보면 이해가 감
    • 다음 단계는 프로젝트의 종속적인 테스트를 독립 포맷으로 변환해 원본과 검증한 뒤 포팅하는 과정일 것 같음
    • LLM은 언어 간 포팅에 매우 강함. MLE-Bench 같은 벤치마크에서 에이전트들이 24시간 내에 Kaggle 대회를 메달권으로 해결하는 수준임
      AI4AI 논문처럼 AI가 AI를 만드는 시대가 이미 시작된 느낌임
    • 이런 이유로 현재 프로젝트의 테스트는 공개하지 않기로 함. 평소엔 오픈소스로 배포하지만 이번엔 재고 중임

  • 사실 Firefox의 HTML5 파서는 원래 Java로 작성되었고, 이후 반자동으로 Gecko용 C++로 변환되었음
    JustHTML 포팅 자체는 좋은 실험이지만, 개인적으로는 Java 코드를 TypeScript로 옮기는 게 더 생산적이었을 것 같음

    • 놀랍게도 Firefox의 Java 파서가 아직도 유지되고 있음
      관련 폴더와 최근 커밋을 보면 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% 줄었다"는 글과도 맥락이 닿음

    • 다만 그 글은 단순화된 주장임. Simon의 실험이 가능했던 건 언어 독립 테스트 9,000개와 기존 API 설계가 있었기 때문임
      대부분의 프로젝트는 이런 조건이 없기 때문에 일반화하기 어려움

  • 저작권과 윤리 문제에 대해, 나는 MIT 라이선스 프로젝트를 Claude Code로 Rust/Python 버전으로 포팅 중임
    오픈소스의 정신은 기존 코드를 개선하며 생태계를 발전시키는 것이라 생각함
    단, GPL 프로젝트는 절대 포팅하지 않음

    • 어떤 라이선스든 저작권은 존중해야 하며, LLM이 만든 포팅도 파생 저작물로 간주됨
    • GPL을 선택한 개발자는 명확한 의도를 가진 것이므로, LLM을 이용해 라이선스 우회를 시도하는 건 그 정신을 훼손하는 일임

  • “이런 방식으로 만든 뒤에야 법적·윤리적 문제를 묻는 건 무책임하다”는 비판도 있었음

    • 하지만 나는 이 논의를 촉발시키기 위해 일부러 위험을 감수했음
      지금은 이런 일이 “가능할 뿐 아니라, 놀라울 정도로 쉽다”는 걸 보여주는 게 중요하다고 생각함

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

    • 실제로 테스트만으로 앱 전체를 만들 수 있을까 하는 생각도 듦

  • GPT-5.2가 9,000줄의 완전한 JavaScript 코드를 생성하는 데 $28.31이 들었음
    이런 효율이라면 5~10년 내에 주니어·미드급 개발자의 역할이 크게 줄어들 것 같음
    비용 계산 링크 참고

    • 하지만 이는 기존 프로젝트를 포팅하는 이상적인 사례임. 새 라이브러리를 처음부터 만드는 건 여전히 다름
      그래도 작은 생태계를 가진 언어에는 큰 경제적 변화가 생길 것임
    • “소프트웨어 엔지니어”라는 개념은 사라지지 않고, 역할과 기대치가 변할 뿐임
    • “우리가 하루 종일 하는 일이 언어 포팅뿐이냐”는 반박도 있었음. 현실은 훨씬 복잡함

  • 모든 AI 포팅이 성공적인 건 아님. 실패 사례도 있음 → The port I couldn’t ship

    • 성공 여부는 소스 코드 대비 테스트 비율에 크게 좌우됨
      어떤 프로젝트가 쉬운지, 어떤 접근이 빠른지에 대한 데이터가 쌓이면 흥미로운 분석이 될 것임
      Simon이 이런 비교 실험을 해준다면 정말 흥미로울 것 같음
답변달기