Cursor의 FastRender보다 훨씬 나은 코드 생성 브라우저 데모라고 생각함
Rust 2만 줄 정도로 훨씬 작고, 이미지·텍스트 렌더링에 시스템 라이브러리만 사용하며, 코드도 읽기 쉬움
예를 들어 flexbox 구현 코드를 보면 명확함
내 블로그를 렌더링한 스크린샷도 올렸는데, CSS 그라디언트와 SVG 아이콘은 잘 처리하지만 PNG는 실패함
HTML+CSS 렌더링 브라우저는 병렬 에이전트 시연에 완벽한 과제라 생각했는데, 한 명의 코딩 에이전트로도 가능했음이 놀라움
엔지니어링 관점에서 Cursor의 브라우저보다 훨씬 완성도 높은 설계라 생각함
중요한 건 단순히 토큰을 많이 쓰는 게 아니라 에이전트를 효과적으로 활용하는 법임
나도 여러 프로젝트를 생성 후 며칠 지나 버린 적이 많음. 에이전트는 피드백 없이 시킨 대로만 하기에, 잘못된 방향이면 오히려 더 깊은 구멍을 파게 됨
인간과 에이전트의 협업이 결정적 차이를 만든다고 봄
Claude가 엉뚱한 방향으로 가도 올바른 에이전트 구조가 있으면 다시 회복함
나는 현재 평가자·연구자·구현자 에이전트를 분리한 실험을 진행 중임
점수 기반으로 테스트를 확장하거나 실패 원인을 조사하게 하고, 개선이 없으면 커밋을 폐기함
이런 구조가 코드 품질 관리에 훨씬 유리함
코드가 싸고 버릴 수 있는 시대에는 워크플로우 자체가 달라져야 함
embedding-shapes가 직접 손으로 만들어낸 점이 인상적임
1인 1에이전트가 500만 달러, 160만 LOC 브라우저를 이긴 ‘David vs Goliath’ 같은 이야기로 느껴짐
AI는 여전히 블랙박스라, 모두가 실험하며 방향을 찾는 중임
2026년이 이제 한 달 지났는데, 앞으로 어떤 실험이 나올지 흥미로움
Simon이 HN의 2026년 예측 스레드를 주기적으로 리뷰하면 재밌을 듯함
3일이라는 제한을 두고, Rust 서드파티 크레이트 없이 OS 기본 라이브러리만 사용해 X11/Windows/macOS를 지원하도록 규칙을 세움
약 2만 LOC로 완성했고, 그중 1.4만 줄이 엔진, 6천 줄이 플랫폼 지원 코드임 소스코드와 바이너리를 공개했음
20년 전 KHTML/konqueror에 기여했을 때는 기본 렌더링만 구현해도 몇 달이 걸렸음
지금은 머신 판독 가능한 테스트 스위트 덕분에 훨씬 효율적임
예전엔 IE의 동작이 사실상 표준이었는데, 이제는 구글·애플 등이 표준화에 기여해 훨씬 나아졌음
어떤 모델을 썼고, 토큰 비용은 얼마였는지 궁금함
제약 조건이 훌륭함
기능과 별개로 이런 코드베이스의 보안 감사가 궁금함
Rust가 도움이 되겠지만, 언어 보장만으로 충분한지 의문임
보안은 전혀 고려되지 않았음. 샌드박스 없이 임의 웹사이트를 열면 위험함
Rust는 기본적인 메모리 오류만 막을 뿐, 로컬 파일 접근 같은 건 막지 않음
JS 엔진이 없어서 데이터 유출은 어렵지만, 감사하면 심각한 취약점이 여러 개 나올 것 같음
커뮤니티가 browserBench를 기다려왔는데, 드디어 시작돼 기쁨임
브라우저는 가장 복잡한 소프트웨어 중 하나라, 이런 시도가 한계 평가의 기준점이 될 것임
2만 줄로 브라우저를 만든다는 게 잘 상상이 안 됨
zlib만 해도 1.2만 줄인데, 뭔가 빠진 게 아닌가 싶음
OS 렌더링 호출만 하는 건지 궁금함
Linux에서는 X11, glib, 그래픽 포맷, 암호화 등 78개의 동적 라이브러리를 링크함
Rust 의존성은 없고, OS 기본 프레임워크를 사용함
어떤 라이브러리를 쓰는지는 README에 명시되어 있음
내가 실행해보니 렌더링이 꽤 혼란스러움
링크 색상이나 밑줄이 일관되지 않고, Windows에서는 뒤로가기 버튼이 작동하지 않음
그래도 HN 홈페이지나 Simon의 블로그는 꽤 잘 렌더링함
이 브라우저는 독립 제품이라기보다 Cursor의 scaling-agents 글에 대한 응답 프로젝트임
LOC가 적으면서 비슷한 기능을 구현하는 게 목표였음
기본 스타일시트가 없어서 링크 색이 일정하지 않음
Windows 11에서는 뒤로가기 버튼이 작동함. 혹시 Windows 10이라면 그게 원인일 수도 있음
Simon의 블로그를 렌더링하는 게 AI 브라우저의 대표 목표가 될 듯함
하지만 아직은 진짜 브라우저라기보단 렌더러 수준임
Servo 같은 프로젝트에서 AI가 API 구현을 보완하는 방향이 더 인상적일 것임
동의함. 이건 브라우저라기엔 부족하고, 기본 HTML도 제대로 렌더링 못하며 자주 크래시함
그래도 Cursor의 시도보단 낫고, “컴파일된다”는 점이 최소한의 진전임
혼자 했다면 얼마나 걸렸을지 궁금함
에이전트의 도움을 이해하려면 그 가이드에 들어간 전문성의 깊이를 알고 싶음
혼자서는 아마 불가능했을 것임
Rust는 알지만 X11이나 macOS, Windows API는 몰라서 시작조차 어려웠을 것임
다만 테스트·인프라·설계 경험이 많아 에이전트와 협업하는 데 도움이 되었음
sloccount 도구로 계산해보니
이 프로젝트는 2000년 기준 4.58 인년, 61만 달러,
2025년 기준으로는 5.6년, 138만 달러 규모로 추정됨
이 글이 흥미로운 이유는 결과물이 아니라 만드는 과정과 제약 조건에 초점을 맞췄기 때문임
대부분의 글은 결과물이나 작성자에 집중하지만, 이건 프로세스 중심의 통찰을 줌
나도 Cursor 관련 글을 썼던 사람으로서, 그들의 “성공” 정의가 점점 이해되지 않았음
그래서 무엇이 진짜 어려운 부분이고, 어떤 과정이 잘못된 건지를 탐구하는 게 더 의미 있다고 느낌
인상적인 작업임 접근성(Accessibility) 을 Rust 의존성 없이 구현하려면 어떻게 해야 할지 궁금함
Windows/macOS는 UI Automation과 NSAccessibility로 가능하지만, X11에서는
Hacker News 의견들
Cursor의 FastRender보다 훨씬 나은 코드 생성 브라우저 데모라고 생각함
Rust 2만 줄 정도로 훨씬 작고, 이미지·텍스트 렌더링에 시스템 라이브러리만 사용하며, 코드도 읽기 쉬움
예를 들어 flexbox 구현 코드를 보면 명확함
내 블로그를 렌더링한 스크린샷도 올렸는데, CSS 그라디언트와 SVG 아이콘은 잘 처리하지만 PNG는 실패함
HTML+CSS 렌더링 브라우저는 병렬 에이전트 시연에 완벽한 과제라 생각했는데, 한 명의 코딩 에이전트로도 가능했음이 놀라움
중요한 건 단순히 토큰을 많이 쓰는 게 아니라 에이전트를 효과적으로 활용하는 법임
나도 여러 프로젝트를 생성 후 며칠 지나 버린 적이 많음. 에이전트는 피드백 없이 시킨 대로만 하기에, 잘못된 방향이면 오히려 더 깊은 구멍을 파게 됨
Claude가 엉뚱한 방향으로 가도 올바른 에이전트 구조가 있으면 다시 회복함
나는 현재 평가자·연구자·구현자 에이전트를 분리한 실험을 진행 중임
점수 기반으로 테스트를 확장하거나 실패 원인을 조사하게 하고, 개선이 없으면 커밋을 폐기함
이런 구조가 코드 품질 관리에 훨씬 유리함
코드가 싸고 버릴 수 있는 시대에는 워크플로우 자체가 달라져야 함
1인 1에이전트가 500만 달러, 160만 LOC 브라우저를 이긴 ‘David vs Goliath’ 같은 이야기로 느껴짐
AI는 여전히 블랙박스라, 모두가 실험하며 방향을 찾는 중임
2026년이 이제 한 달 지났는데, 앞으로 어떤 실험이 나올지 흥미로움
Simon이 HN의 2026년 예측 스레드를 주기적으로 리뷰하면 재밌을 듯함
3일이라는 제한을 두고, Rust 서드파티 크레이트 없이 OS 기본 라이브러리만 사용해 X11/Windows/macOS를 지원하도록 규칙을 세움
약 2만 LOC로 완성했고, 그중 1.4만 줄이 엔진, 6천 줄이 플랫폼 지원 코드임
소스코드와 바이너리를 공개했음
지금은 머신 판독 가능한 테스트 스위트 덕분에 훨씬 효율적임
예전엔 IE의 동작이 사실상 표준이었는데, 이제는 구글·애플 등이 표준화에 기여해 훨씬 나아졌음
기능과 별개로 이런 코드베이스의 보안 감사가 궁금함
Rust가 도움이 되겠지만, 언어 보장만으로 충분한지 의문임
Rust는 기본적인 메모리 오류만 막을 뿐, 로컬 파일 접근 같은 건 막지 않음
JS 엔진이 없어서 데이터 유출은 어렵지만, 감사하면 심각한 취약점이 여러 개 나올 것 같음
커뮤니티가 browserBench를 기다려왔는데, 드디어 시작돼 기쁨임
브라우저는 가장 복잡한 소프트웨어 중 하나라, 이런 시도가 한계 평가의 기준점이 될 것임
2만 줄로 브라우저를 만든다는 게 잘 상상이 안 됨
zlib만 해도 1.2만 줄인데, 뭔가 빠진 게 아닌가 싶음
OS 렌더링 호출만 하는 건지 궁금함
어떤 라이브러리를 쓰는지는 README에 명시되어 있음
내가 실행해보니 렌더링이 꽤 혼란스러움
링크 색상이나 밑줄이 일관되지 않고, Windows에서는 뒤로가기 버튼이 작동하지 않음
그래도 HN 홈페이지나 Simon의 블로그는 꽤 잘 렌더링함
LOC가 적으면서 비슷한 기능을 구현하는 게 목표였음
기본 스타일시트가 없어서 링크 색이 일정하지 않음
Windows 11에서는 뒤로가기 버튼이 작동함. 혹시 Windows 10이라면 그게 원인일 수도 있음
Simon의 블로그를 렌더링하는 게 AI 브라우저의 대표 목표가 될 듯함
하지만 아직은 진짜 브라우저라기보단 렌더러 수준임
Servo 같은 프로젝트에서 AI가 API 구현을 보완하는 방향이 더 인상적일 것임
그래도 Cursor의 시도보단 낫고, “컴파일된다”는 점이 최소한의 진전임
혼자 했다면 얼마나 걸렸을지 궁금함
에이전트의 도움을 이해하려면 그 가이드에 들어간 전문성의 깊이를 알고 싶음
Rust는 알지만 X11이나 macOS, Windows API는 몰라서 시작조차 어려웠을 것임
다만 테스트·인프라·설계 경험이 많아 에이전트와 협업하는 데 도움이 되었음
이 프로젝트는 2000년 기준 4.58 인년, 61만 달러,
2025년 기준으로는 5.6년, 138만 달러 규모로 추정됨
이 글이 흥미로운 이유는 결과물이 아니라 만드는 과정과 제약 조건에 초점을 맞췄기 때문임
대부분의 글은 결과물이나 작성자에 집중하지만, 이건 프로세스 중심의 통찰을 줌
그래서 무엇이 진짜 어려운 부분이고, 어떤 과정이 잘못된 건지를 탐구하는 게 더 의미 있다고 느낌
인상적인 작업임
접근성(Accessibility) 을 Rust 의존성 없이 구현하려면 어떻게 해야 할지 궁금함
Windows/macOS는 UI Automation과 NSAccessibility로 가능하지만, X11에서는