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이 이런 비교 실험을 해준다면 정말 흥미로울 것 같음