무슨 일이 있었나요?
Bez라는 실험적인 프로젝트가 공개됐어요. 소개 문구가 꽤 대담한데요, “스펙과 테스트로부터 브라우저 엔진을 생성한다”고 해요. 사람이 코드를 한 줄씩 짜는 게 아니라, 웹 표준 명세서와 공식 테스트 모음을 AI에게 주고 구현을 만들게 하는 방식이에요. 저장소는 Tangled에 올라와 있어요. Tangled는 AT Protocol(블루스카이가 쓰는 분산 프로토콜) 위에서 돌아가는 코드 호스팅 서비스예요. AI가 코드를 짜는 것 자체는 이제 놀랍지 않죠. 이 프로젝트에서 눈에 띄는 건 만드는 대상이 브라우저 엔진이라는 점이에요.
브라우저 엔진, 이게 뭐냐면
브라우저 엔진은 HTML, CSS, JavaScript를 받아서 화면의 픽셀로 바꿔주는 핵심 부품이에요. 하는 일을 순서대로 보면 이래요. HTML을 해석해서 DOM 트리를 만들고, CSS 규칙을 계산해서 스타일을 입혀요. 그다음 요소마다 위치와 크기를 정하는 레이아웃을 하고, 마지막으로 실제 화면에 그리는 페인트를 해요. 이 단계 하나하나가 엄청나게 복잡해요.
얼마나 어려운 일이냐면, 지금 널리 쓰이는 엔진은 크롬의 Blink, 사파리의 WebKit, 파이어폭스의 Gecko 정도밖에 없어요. 새로 만드는 쪽으로는 Rust로 만든 Servo와 처음부터 직접 짜고 있는 Ladybird가 있어요. 그런데 둘 다 오랫동안 많은 사람이 매달렸는데도 아직 갈 길이 남아 있어요.
왜 하필 '스펙과 테스트'일까요
웹은 다른 소프트웨어 분야에 비해 명세가 유난히 촘촘하게 쓰여 있어요. WHATWG의 HTML 표준은 “이 문자를 만나면 이 상태로 바꿔라” 같은 단계별 절차로 적혀 있어서 거의 의사코드(코드처럼 쓴 설명)에 가까워요. 여기에 모든 브라우저 회사가 함께 관리하는 공용 테스트 모음 web-platform-tests(WPT)도 있어요. 테스트 파일만 수만 개 규모예요.
비유하자면 아주 자세한 레시피(스펙)와 채점 기준표(테스트)가 다 갖춰진 요리 대회 같은 거예요. AI 코딩 에이전트에게는 이보다 좋은 환경이 없어요. 스펙을 읽고 코드를 짠 다음 테스트를 돌려보고, 실패한 부분을 고쳐서 다시 돌리는 과정을 사람 없이 오래 반복할 수 있거든요. 에이전트가 일을 잘 해내려면 결과를 자동으로 채점할 수 있어야 하는데, 웹은 이 조건을 거의 완벽하게 갖추고 있어요.
Bez가 지금 테스트를 얼마나 통과하는지, 어떤 언어와 구조로 만들어지는지는 저장소에서 직접 확인해 보세요. 이런 실험은 언제 보느냐에 따라 상황이 크게 달라지거든요.
비슷한 시도들과 비교해 보면
이런 시도는 Bez만 하는 게 아니에요. 작년 말에 소개된 JustHTML은 html5lib 테스트 모음을 기준으로 삼아 코딩 에이전트로 만든 파이썬 HTML5 파서예요. 이걸 다른 언어로 몇 시간 만에 옮긴 사례도 나왔어요. 올해 초에는 Anthropic이 Claude 에이전트 여러 개를 동시에 돌려서 C 컴파일러를 만들었는데, 이 컴파일러로 리눅스 커널 빌드까지 성공했다고 공개했어요. Cursor도 에이전트 수백 개로 브라우저를 처음부터 만드는 실험을 했어요. 다만 빌드가 제대로 되지 않는다는 점과 기존 라이브러리에 많이 기댄다는 점 때문에 비판도 받았어요.
세 사례에서 공통으로 보이는 건, 명세가 잘 정해져 있고 테스트로 자동 채점까지 되는 분야에서 에이전트가 특히 잘한다는 점이에요. Bez는 이 방식을 아예 프로젝트의 중심에 놓았다는 점이 흥미로워요.
테스트를 통과하면 끝일까요?
물론 한계도 분명해요. 우선 테스트로 모든 걸 잡아낼 수는 없어요. 성능이나 메모리 사용량, 사이트 격리나 샌드박스 같은 보안 기능은 WPT를 통과했다고 보장되는 게 아니거든요. 게다가 실제 웹은 스펙대로만 돌아가지 않아요. 오래된 사이트들은 '쿼크(quirks)'에 많이 기대고 있어요. 쿼크는 표준은 아니지만 브라우저들이 관행처럼 맞춰주는 동작을 말하는데, 이런 게 정말 많아요. 테스트 통과에만 맞춰 만들다 보면 점수는 높은데 실제로는 이상하게 동작하는 코드가 나올 수도 있어요. 이렇게 만들어진 방대한 코드를 누가 이해하고 유지보수할지도 아직 답이 없는 문제예요.
한국 개발자에게 주는 시사점
당장 Bez를 실무에 쓸 일은 없겠지만, 여기서 얻을 교훈은 꽤 실용적이에요. 에이전트에게 일을 잘 맡기고 싶다면 좋은 테스트와 명확한 명세부터 갖춰라는 거예요. 예를 들어 사내 레거시 시스템을 새 기술로 옮겨야 한다고 해볼게요. 지금 시스템이 어떻게 동작하는지를 테스트로 꼼꼼히 정리해 두기만 해도 에이전트에게 맡길 수 있는 일이 크게 늘어나요. 명세가 공개된 파일 포맷의 파서를 만드는 일도 이런 방식으로 해볼 만해요. 한컴이 공개한 HWP 파일 형식 문서가 좋은 예예요.
공부용으로도 추천해요. HTML 명세에서 파싱 알고리즘 부분을 한번 읽어보세요. 브라우저가 깨진 HTML을 어떻게 알아서 고쳐 읽는지 알게 되고, 프론트엔드 디버깅 감각도 확실히 좋아져요.
마무리
한 줄 정리: 앞으로는 코드보다 '스펙과 테스트'가 더 중요한 자산이 될지도 몰라요.
여러분은 어떻게 보세요? 명세와 테스트만 잘 갖추면 브라우저 같은 거대한 소프트웨어도 AI에게 구현을 맡길 수 있을까요? 그렇게 된다면 개발자에게 가장 중요한 능력은 뭐가 될까요?
🔗 출처: Hacker News