13,000개의 unsafe 블록이 있었습니다. 이 텍스트는 AI에 의해 생성되었습니다. 이는 수백만 명의 개발자가 사용하는 JavaScript 런타임(runtime)으로 전송되었습니다. 잠시 그 사실에 대해 생각해 보십시오.

Bun의 대규모 Rust 재작성(rewrite)과 실험적인 멀티스레딩(multithreading) PR이 최근 모두 반영되었으며, 이를 둘러싼 담론은... 대단했습니다. 주요 성과들은 실재합니다. Bun은 코어(core)를 Rust로 재작성했으며 진정한 멀티스레딩을 실험하고 있습니다. 하지만 그 과정은 모든 엔지니어를 불편하게 만들 것입니다.

실제로 일어난 일

Rust 재작성의 대부분은 Claude AI에 의해 작성되었습니다. 이것은 소문이 아닙니다. Bun 팀이 공개적으로 밝힌 사실입니다. 이번 재작성으로 코드베이스에 13,000개 이상의 unsafe 블록이 추가되었습니다. 그리고 이는 동시 가비지 컬렉터(concurrent garbage collector) 없이 출시되었습니다.

시스템 프로그래밍 전문가가 아닌 분들을 위해 설명하자면: 이 문맥에서 "unsafe"는 메모리 안전성 보장(memory safety guarantees)을 우회하는 코드를 의미합니다. 하나의 unsafe 블록은 문제가 되지 않을 수 있습니다. 하지만 AI가 생성한 코드에 13,000개가 포함되어 있다는 것은 완전히 다른 이야기입니다.

속도의 함정 🏎️

그 매력을 이해합니다. 정말로요. AI는 엄청난 양의 코드를 빠르게 생성할 수 있습니다. Node.js 및 Deno와 경쟁하는 작은 팀에게 속도는 생존처럼 느껴집니다.

빠르게 움직이는 것은 괜찮지만, 부주의한 것은 안 됩니다. 각각의 unsafe 코드 블록은 개발자가 "이 메모리 접근이 유효함을 보장합니다"라고 서명하는 계약과 같습니다. 문제는, 개발자가 LLM(대규모 언어 모델)이라면 누가 그 계약에 서명하느냐는 것입니다.

→ AI 생성 코드가 본질적으로 나쁜 것은 아닙니다.
→ 런타임(runtime) 내에서, 동시 GC(garbage collector) 없이 대규모로 생성된 AI 기반의 unsafe 코드는 차원이 다른 문제입니다.
→ 위험은 이론적인 것이 아닙니다. 속도를 위해 Bun을 선택한 프로덕션 앱에서의 메모리 오염(memory corruption), 데이터 경합(data races), 그리고 크래시(crashes)를 의미합니다.

동시 가비지 컬렉터의 부재는 실제 멀티스레드 워크로드에서 메모리 관리가 지뢰밭임을 암시합니다. 이것은 누락된 기능이 아닙니다. 누락된 기반(foundation)입니다.

신뢰가 곧 제품입니다

많은 사람들이 런타임 (runtime)이 무엇인지 완전히 이해하지 못하고 있다고 믿습니다. 런타임은 쉽게 교체할 수 있는 라이브러리 (library)와는 다릅니다. 그것은 당신의 전체 애플리케이션이 구축되는 기반 (foundation)입니다. 따라서 Node, Deno, 또는 Bun을 선택할 때, 당신은 본질적으로 신뢰 (trust)를 바탕으로 결정을 내리는 것입니다.

일부 개발자들은 안정성에 대한 우려로 인해 다시 Node.js로 돌아가기 시작했습니다. 이것은 공포, 불확실성, 의구심 (FUD)이 아닙니다. 실험적인 성격이 가장 치명적인 계층에서 실험적인 느낌을 주는 인프라를 배포했을 때 나타나는 자연스러운 결과입니다.

저는 이보다 덜 극적인 형태지만 유사한 경험을 한 적이 있습니다. 한 팀이 빠르게 결과물을 내놓고 인정을 받지만, 그 후 몇 년 동안 신뢰 부족을 메우기 위해 노력해야 하는 상황 말입니다. 코드가 틀렸던 것이 아닙니다. 하지만 "내 컴퓨터에서는 작동한다"와 "당신의 프로덕션 데이터를 파괴하지 않을 것이다" 사이의 확신 차이는 엄청납니다. 😅

진짜 질문은 AI에 관한 것이 아닙니다

제가 코드베이스 내의 AI를 반대하는 것은 아닙니다. 저도 매일 AI 도구를 사용합니다. 하지만 저는 AI가 생성한 코드를 주니어 엔지니어의 코드와 동일하게 취급합니다. 즉, 폭발 반경 (blast radius)에 비례하는 검토가 필요합니다.

JavaScript 런타임 내부의 멀티스레딩 (multithreading) 프로그래밍의 폭발 범위는 가장 높은 수준 중 하나입니다. 13,000개의 unsafe 블록에는 그것들을 사용해야 할 13,000개의 타당한 이유가 필요했습니다. 13,000개의 형식적인 승인 (rubber stamps)이 아니라 말입니다.

→ 고속 AI 생성은 더 낮은 속도가 아닌, 더 높은 속도의 검토를 요구합니다.
→ unsafe 블록의 개수가 스캔들이 아닙니다. 그에 비례하는 면밀한 조사 (scrutiny)가 명백히 결여되었다는 점이 스캔들입니다.

이것은 Bun 팀이나 그들의 포부를 비난하려는 것이 아닙니다. Jarred와 팀은 기술적으로 정말 놀라운 일을 해냈습니다. 하지만 시스템 코드 (systems code)에서 그만큼 주의를 기울이지 않으면서 야망만 갖는 것은 대담한 것이 아닙니다. 그것은 지연 신관이 달린 부채 폭탄 (liability bomb)입니다. 💣

이것이 우리를 어디로 이끄는가

Bun은 여전히 훌륭한 런타임 (runtime)이 될 잠재력을 가지고 있습니다. 하지만 동시 가비지 컬렉션 (concurrent GC) 없이 이토록 방대한 양의 AI 생성 unsafe 코드를 배포하는 것은, 그 위에서 무언가를 구축하거나 AI가 생성한 시스템 코드 (systems code)를 사용하여 무언가를 만드는 사람들에게 위험한 표준을 설정할 수 있습니다.

여기서 도출해야 할 결론은 "그 용도로 AI를 사용하지 말자"가 아닙니다. 코드의 영향 범위 (blast radius)에 비례하여 검토 (review) 수준이 결정되어야 한다는 것입니다. 특히 코드를 작성한 사람이 잘못되었을 때의 비용에 대해 추론할 능력이 없는 경우에는 더욱 그러합니다.

당신의 앱 아래 프로덕션 (production) 환경에서 13,000개의 AI 생성 unsafe 블록을 실행하시겠습니까? AI가 작성한 인프라 코드 (infrastructure code)를 신뢰하는 당신만의 임계값 (threshold)은 무엇입니까?