최근 내가 공유한 LLM 예측 글에서 2029년쯤엔 AI 보조 코딩으로 브라우저를 만드는 게 놀랍지 않을 것이라 했는데, Cursor의 이번 프로젝트가 두 번째 시도임
다른 예시는 이 Reddit 글에서 볼 수 있음
똑똑한 구현이라면 그냥 GitHub의 Chromium 소스를 가져와서 불필요한 기능을 제거하고 외형만 바꾸는 식으로 하지 않을까 싶음
2029년쯤엔 펠리컨용 브라우저를 AI가 만든다는 농담이 나올 정도로 기준을 높여야 할 시점임
Reddit의 예시 코드를 5분 정도 봤는데, 텍스트 레이아웃 계산과 bidi(양방향 텍스트) 처리가 엉망이었음. 표준을 고려하지 않은 “브라우저”는 진짜 브라우저라 부르기 어려움
인상적이긴 하지만, 오픈소스 브라우저 코드가 모델의 훈련 데이터에 포함된 건 아닌지 의문임
예측이 빗나갔다고 하더니 일주일 뒤 같은 팟캐스트에 다시 나와서 새 예측을 한 이유가 궁금함
저장소의 테스트를 직접 돌려봤는데 에러와 경고가 가득했고, CI도 오래전부터 실패 중이었음. 이런 상태에서 “성공적인 예시”라 부르는 게 맞는지 모르겠음. 완전 자율 코딩보다는 인간 중심 보조형 접근이 더 현실적이라 생각함
코드베이스가 수백, 수천 개의 작은 파일로 쪼개져 있어서 구조 파악이 거의 불가능했음. README도 엉성하고 의존성 설명도 없음. AI가 만든 코드지만 유지보수는 악몽 수준임
작성자도 완전 자율 코딩을 진지한 제품화보다는 LLM 한계 실험으로 본 듯함. 지금은 작은 프로젝트 수준에서만 “혼자서 괜찮은 코드”를 낼 수 있는 단계임
CI 실패한 PR을 그냥 머지했다니, 인간 수준의 품질을 달성한 셈이라는 농담이 나올 만함
“느리다”는 표현이 구체적으로 뭘 의미하는지 불분명함. GPU 속도? 인간보다 느리다는 뜻? 결국 AI 버블을 부풀리는 글로 느껴졌음
왜 그 PR을 아직 머지하지 않았는지 궁금함. AI 에이전트 군집이 장기적으로 복잡한 소프트웨어를 완성하는 미래는 멋지지만, 지금 예시는 너무 빈약함. 인간과의 협업 지점이 더 중요함
내 경험상 에이전트들은 수렴하지 않고 점점 엉망이 되는 코드 괴물을 만들어냄
작동하는 간단한 프로젝트 하나라도 공개하지 않은 건 투자자 유인용 미끼처럼 보임. AI 붐이 닷컴 버블과 비슷하지만, 이번엔 돈벌이에 더 집중된 느낌임
브라우저나 Excel, Windows 7 같은 예시는 훈련 데이터에 일부 포함됐겠지만, 그걸로 완전 복제는 불가능함
코드가 너무 방대하고 문제투성이여서 리뷰 자체가 불가능함. 결국 YOLO식 머지밖에 답이 없음
나는 수렴 조건에 관심이 있음. 코드가 늘어나든 줄어들든, 최적의 상태로 안정화되는 게 중요함
단계적으로 난이도를 높이며 실험하지 않은 게 아쉬움. React CRUD → Paint 클론 → 파일 관리자 → 브라우저 순으로 점진적으로 확장했다면 발전 단계를 명확히 볼 수 있었을 것임
나도 비슷한 방식으로 tjs를 만들었음. 세계에서 가장 빠르고 정확한 JSON Schema Validator인데, git subtree를 활용한 planner/delegate 패턴이 효과적이었음. 표준과 테스트가 잘 정의된 소프트웨어는 AI 에이전트가 빠르게 재작성하고 최적화할 수 있음
관련 명령은 spawn-perf-agents.md에서 볼 수 있음
브라우저를 처음부터 만든다는 건 매우 어렵지만, 글에서 제시한 내용은 세부 분석이 부족했음. 단순히 “컴파일된다”는 수준이라면 의미가 약함. 진짜 검증은 다음 변경을 안정적으로 병합할 수 있느냐임
에이전트 코딩의 최소 기준은 “컴파일 성공” → “정상 실행” → “엣지 케이스 처리” 순임. 인간보다 버그가 적은 시스템이 1년 이상 안정적으로 돌아가야 신뢰할 수 있음
실제로는 CI도 실패 중이라 “컴파일된다”는 주장조차 의심스러움
블로그에 따르면 수조 개의 토큰을 사용했다는데, OpenAI API 단가로 계산하면 수천만 달러 규모임. 이 정도면 그냥 브라우저 팀에 기부하는 게 나았을지도 모름
직접 빌드해봤는데 100개 이상의 컴파일 에러가 발생했음. 대부분의 커밋이 CI 실패 상태였고, 실제로는 여러 오픈소스 라이브러리를 조합한 것이었음.
quickjs, wgpu, winit, egui, html parser 등 기존 구성요소를 그대로 가져왔는데, CEO는 “커스텀 JS VM”이라 주장해서 오해를 불러일으킴
그래도 이런 통합을 AI가 자율적으로 해냈다는 건 인상적임
Hacker News 의견들
Steve Yegge의 글 Welcome to Gas Town과 관련된 작업을 하고 있어서 흥미롭게 봤음
최근 내가 공유한 LLM 예측 글에서 2029년쯤엔 AI 보조 코딩으로 브라우저를 만드는 게 놀랍지 않을 것이라 했는데, Cursor의 이번 프로젝트가 두 번째 시도임
다른 예시는 이 Reddit 글에서 볼 수 있음
저장소의 테스트를 직접 돌려봤는데 에러와 경고가 가득했고, CI도 오래전부터 실패 중이었음. 이런 상태에서 “성공적인 예시”라 부르는 게 맞는지 모르겠음. 완전 자율 코딩보다는 인간 중심 보조형 접근이 더 현실적이라 생각함
왜 그 PR을 아직 머지하지 않았는지 궁금함. AI 에이전트 군집이 장기적으로 복잡한 소프트웨어를 완성하는 미래는 멋지지만, 지금 예시는 너무 빈약함. 인간과의 협업 지점이 더 중요함
단계적으로 난이도를 높이며 실험하지 않은 게 아쉬움. React CRUD → Paint 클론 → 파일 관리자 → 브라우저 순으로 점진적으로 확장했다면 발전 단계를 명확히 볼 수 있었을 것임
나도 비슷한 방식으로 tjs를 만들었음. 세계에서 가장 빠르고 정확한 JSON Schema Validator인데, git subtree를 활용한 planner/delegate 패턴이 효과적이었음. 표준과 테스트가 잘 정의된 소프트웨어는 AI 에이전트가 빠르게 재작성하고 최적화할 수 있음
관련 명령은 spawn-perf-agents.md에서 볼 수 있음
브라우저를 처음부터 만든다는 건 매우 어렵지만, 글에서 제시한 내용은 세부 분석이 부족했음. 단순히 “컴파일된다”는 수준이라면 의미가 약함. 진짜 검증은 다음 변경을 안정적으로 병합할 수 있느냐임
블로그에 따르면 수조 개의 토큰을 사용했다는데, OpenAI API 단가로 계산하면 수천만 달러 규모임. 이 정도면 그냥 브라우저 팀에 기부하는 게 나았을지도 모름
직접 빌드해봤는데 100개 이상의 컴파일 에러가 발생했음. 대부분의 커밋이 CI 실패 상태였고, 실제로는 여러 오픈소스 라이브러리를 조합한 것이었음.
quickjs, wgpu, winit, egui, html parser 등 기존 구성요소를 그대로 가져왔는데, CEO는 “커스텀 JS VM”이라 주장해서 오해를 불러일으킴
그래도 이런 통합을 AI가 자율적으로 해냈다는 건 인상적임
코드가 매우 취약하고 불안정해 보였음. 예를 들어 render_placeholder 함수는 단순히 프레임 버퍼를 채우는 임시 코드처럼 보임.
이런 코드가 실제로 어떤 역할을 하는지, 그리고 테스트별 토큰/시간 비용이 얼마나 되는지 궁금함