이 포크에서 가장 흥미로운 사실은 Bun도 진작 빠르게 빌드할 수 있었다는 점을 입증했다는 것임
아직 Zig 증분 컴파일은 aarch64를 지원하지 않고 바이너리 패치도 Linux 링커에서만 가능하지만, 주요 플랫폼 지원은 시간문제로 보임

빌드 속도를 높이려고 Zig 컴파일러를 포크한 일을 둘러싼 소란을 생각하면 이게 최상단 댓글이 아닌 것이 놀라움 1인 팀이 1초 빌드를 달성했다는 사실은 느린 빌드가 부주의한 개발 관행의 결과였고, 포크에 시간을 쓴 것은 완전히 잘못된 자원 배분이었음을 보여줌

LLM이 망가뜨린 코드를 다시 LLM으로 정리한다니, 2026년에 기술의 정점에 도달한 듯함

지금까지도 인간이 망가뜨린 코드를 인간이 정리해 왔으니 논리적 모순은 아님

LLM의 결과물은 이를 지시하는 사용자의 역량만큼 좋아짐

AI에 회의적이지만 사용할 의향은 있는데, LLM이 정말 자기 결과물을 스스로 정리할 수 있다면 판도를 바꿀 만함

같은 생각이었지만 바로 뒤에서 인간이 주도권을 잡고, 기술 부채를 줄이며 관용적인 Zig 코드를 작성해 몇 주나 몇 달 안에 Rust Bun 1.4.0을 대체할 만한 코드베이스를 만들겠다고 밝힘
결국 더 많이, 혹은 더 잘 지시하겠다는 뜻으로 보임. 코드 구조는 취향의 영역 같기도 한데, 어제는 HTTP 요청 하나를 처리하는 데 백엔드 프로세스 네 개가 필요하다고 고집하는 친구와 황당한 대화를 나눴음

애초부터 이런 방향이었음. 인간이 읽거나 이해할 수 없는, 소프트웨어 모양만 한 망가진 LLM 출력물이 코드가 되고 있으니 결국 모든 코드는 기계가 읽고 쓰도록 만들어질 수밖에 없음
인간이 개입하는 시대는 처음부터 임시 단계였다고 봄

Bun에서 완전히 죽은 코드 11,000줄을 제거하고 표준 라이브러리를 더 활용하도록 현대화하면서 수많은 버그까지 고쳤다니 놀라움
대규모 프로젝트에서는 흔한 일인데 단지 내가 몰랐던 것인지 궁금함

전체가 60만 줄이므로 죽은 코드는 약 1.8% 임. 큰 코드베이스일수록 코드가 실제로 사용되지 않는지 판단하려면 넓은 범위를 살펴야 하고, 시간이 지나며 멀리 떨어진 변경이 죽은 코드를 만들기도 해 더 흔함 if (false) { dead_code(); }처럼 명백한 코드인지, 동적 디스패치는 가능하지만 논리상 호출될 수 없는 코드인지는 불분명함. 전자라면 1.8%는 높지만 후자라면 낮을 수도 있으며, 오래된 기능 플래그 뒤에 사실상 영원히 실행되지 않을 코드가 쌓인 프로젝트도 많음
단순한 유틸리티나 생성 코드처럼 소량의 죽은 코드는 남겨도 괜찮지만, 제거가 연쇄적인 삭제와 단순화로 이어질 때도 있음

이전 회사에서 1만 줄짜리 컴포넌트를 2천 줄로 축소하면서 주요 버그를 모두 고쳤음
엄밀히 말해 죽은 코드는 아니었지만 작은 잘못된 추상화 하나를 정리하면 다음 정리 기회가 연이어 열리고, 결국 의도한 일만 하는 소프트웨어가 남게 됨. 코드베이스는 시간이 지나며 비대해지므로 Bun 규모에서 11,000줄밖에 찾지 못했다는 쪽이 더 놀라움

Zig 컴파일러는 지연 컴파일하므로, 컴파일된 함수 어디에서도 호출되지 않는 죽은 함수를 탐지하지 않음

Bun의 개발 방식을 고려하면 예상보다 적으며, 코드베이스에 훨씬 더 많이 남아 있을 듯함

대규모 코드베이스에서 이 정도 죽은 코드에 놀라는 것이 오히려 놀라움. 보통 크기의 PR 약 10개 분량에 불과함

프로그래밍 경력이 얼마나 되기에 죽은 코드 11,000줄을 그렇게 이례적으로 보는지 궁금함

경력은 10년이 넘음. 어떤 곳에서도 호출되지 않는 명백한 죽은 코드를 뜻했으며, 이 정도로 많은 다른 프로젝트가 있는지 궁금함

에이전트 중심 코딩 프로젝트마다 기능 개발과 코드 관리 사이에서 틱톡 진동이 나타났음
틱 단계에서는 기능을 빠르게 추가해 정확하지만 극도로 지저분한 버전을 만들고, 톡 단계에서는 결과물을 소화하고 정리해 성능·유지보수성·변경 취약성을 개선함
하루 동안 바이브 코딩으로 동작하는 앱을 만든 뒤, 카드로 쌓은 집처럼 무너지지 않고 기능을 계속 추가할 수 있는 프로젝트로 만드는 데 일주일을 쓰곤 함. AI 이전에도 비슷했지만 전문 개발자는 시스템에 대한 심성 모형이 더 강했고 작업 속도도 느려서 전환이 이만큼 급격하지 않았음

결국 코드를 직접 살펴보며 로직이 곳곳에 중복되지 않고 실제로 유지보수 가능한지 확인해야 함
코딩 모델은 캡슐화를 깨는 지름길을 택하거나 중복하면 안 되는 코드를 복제하는 경향이 강함

이를 과시성 성능 프로그래밍이라 부르고 싶음. 성능을 좋아하고 빌드 시간도 0초에 가까워야 하지만, 이제는 수확 체감 구간에 들어섰으며 현재 병목이 빌드 시간은 아닐 것임

Bun이 왜 이렇게 화제인지 모르겠음. 그냥 Node + npm + Vitest + Vite로 돌아가면 안 되는지 궁금함

Bun의 장점을 Node에 제공하려는 Nub 프로젝트가 있으며, 사람들이 Bun을 선호하는 이유와 기존 도구의 간극도 잘 보여줄 수 있음 https://nubjs.com

바로 그 나열이 화제의 이유임. 수많은 도구를 조합하는 대신 필요한 일을 모두 처리하는 단일 런타임을 쓸 수 있음
목적별 도구를 조합하는 것도 문제는 없지만 기본 상태에서 모든 문제가 해결되는 편이 매우 편리함. Bun 번들러에는 런타임 API도 있어, 자산을 제공하는 동일 프로세스가 외부 번들러와 조율하거나 정적 파일을 디스크에 쓰지 않고 메모리에서 바로 번들링할 수 있음