# 지그 창시자는 직설적으로 말하고, 앤트로픽은 연막을 피운다 > 나는 작은 배로 바다를 괴롭히면 해적이라 불리고, 당신은 대함대로 똑같이 하면 왕이라 불린다. **앤트로픽은 소프트웨어 엔지니어링을 끝내기 위한 캠페인을 적극적으로 벌이고 있다.** 그들은 자신들이 정말로 그 일을 해낼 수 있다고 여러분이 믿게 만들어야 한다. 아니, 어쩌면 설득해야 할 대상은 여러분이 아닐지도 모른다. 여러분 회사의 최고경영진, 여러 세계 지도자, 혹은 여러분의 퇴직연금 운용자가 대상일 수도 있다. 그들은 1,320억 달러의 투자를 유치했고, 기업가치 1조 달러가 넘는 IPO에 다가가고 있다. [수익성](https://www.wheresyoured.at/anthropics-profitability-swindle/)을 보여줄 수 없으니, 이 모든 것은 그들이 미래에 미칠 것이라고 주장하는 가상의 영향을 파는 데 달려 있다. 문학적으로 말하면, 앤트로픽은 *신뢰할 수 없는 화자(unreliable narrator)*다. 그들의 핵심 서사 중 하나는 이렇다. [코딩은 사라지고, 그다음에는 소프트웨어 엔지니어링의 나머지도 사라지며](https://youtu.be/02YLwsCKUww?si=NCcT1_VEm4g4NjZw&t=97), 결국 [대부분의 다른 인간 노동](https://www.cfr.org/event/ceo-speaker-series-dario-amodei-anthropic)도 사라진다는 것이다. 이런 종류의 이야기에 이런 규모의 돈이 붙으면, 우리가 그 이야기를 얼마나 사실이라고 생각하든 영향이 생긴다. 사람들은 이런 사건을 바탕으로 아키텍처, 제품, 인력 배치 결정을 내릴 것이다. 그중 많은 결정은 두려움에 근거할 것이다. 해고에 대한 두려움, “남겨진 자(Left Behind)”가 되리라는 휴거식 경고, [파멸 트롤링(Doom Trolling)](https://www.nytimes.com/2026/06/17/opinion/ai-dangerous-openai-anthropic.html?eafs_enabled=false) 등이다. 좋은 결정을 내리려면 명료하게 생각해야 한다. 지금은 그게 어렵다. 회의적인 태도를 갖추자. 이 글의 견해는 내 개인 의견이다. 나는 지그와 아무런 이력이 없다. 앤드루 켈리와 이야기해 본 적도 없다. 다만 최근 그의 [젯브레인스 인터뷰](https://www.youtube.com/watch?v=iqddnwKF8HQ)를 매우 흥미롭게 봤다. 내 관심사는 소프트웨어에서 AI에 대한 대중의 이해다. 지난 3년 동안 이것이 내 커리어의 초점이었고, 기술 자체를 개선하는 일도 함께 해왔다. 그 기간의 절반 동안 나는 코딩 에이전트 스타트업의 수석 아키텍트였다. 앤트로픽 모델의 고객이면서, 그들의 에이전트인 클로드 코드의 경쟁자이기도 했다. 현재 프로젝트는 [더 코딩 에이전시](https://www.thecodingagency.org/)다. ## 그래서 어디까지 이야기했더라? 이번 주 앤트로픽 / Bun은 Bun을 지그에서 러스트로 이식하기로 한 결정에 대한 [설명](https://bun.com/blog/bun-in-rust)을 내놓았다. 이 설명은 마이그레이션을 메인라인에 병합한 지 두 달 뒤에 나왔다. 이런 인프라 프로젝트라면 방향을 *사전에(beforehand)* 설명하는 편이 더 전통적이었을 것이다. 하지만 그 사이 지연 덕분에 더레지스터의 [Anthropic’s Bun Rust rewrite merged at speed of AI](https://www.theregister.com/devops/2026/05/14/anthropics-bun-rust-rewrite-merged-at-speed-of-ai/5240381) 같은 섹시한 헤드라인이 이야기를 대신 실어 날랐다. 투자 많음. 매우 놀라움. 지그의 창시자 앤드루 켈리는 이제 자신의 생각을 담은 [답변](https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html)을 내놓았다. 이례적일 정도로 직설적이다. 겉으로 보이는 인상은 다소 논란의 여지가 있다. 일반적으로 프로그래밍 언어를 바꿨더니 다음 날 아침 이전 언어의 리더가 내 개인적 결함을 퍼붓는 상황을 걱정하고 싶지는 않을 것이다. 댁스가 [웃기게도](https://www.linkedin.com/posts/thdxr_guys-we-have-a-pretty-substantial-opensource-share-7481579102622216192-E4-Q/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAB7o1UBSVk_MWfFO9AbldIjAI4xeROkC8k) 이렇게 표현했다. > 얘들아 우리 꽤 규모 있는 오픈소스 지그 코드베이스가 있는데, 그가 들여다볼까 봐 너무 무섭다 그래도 앤드루의 글을 읽으면서 나는 *소리 내어 응원(cheering out loud)*하고 있었다. 잠깐 방 안을 뛰어다녔을지도 모른다. 어떤 사람들은 그의 견해를 “붕괴(meltdown)”라고 불렀다. 내가 말할 수 있는 것은 오늘 그가 새 팬을 얻었다는 사실뿐이다. 때로는 어떤 일을 있는 그대로 지적해야 한다. ## 모범적 행동이란 무엇인가? 내가 가장 좋은 상태일 때라면 [불교의 바른 말](https://tasshin.com/blog/reflections-on-buddhist-right-speech/) 같은 것을 지향하고 싶다. 우리가 하는 모든 말이 다음 다섯 기준을 모두 충족해야 한다는 높은 기준이다. - 사실인가? - 도움이 되는가? - 시의적절한가? - 친절한가? - 친절에서 *비롯된(from)* 말인가? 우리는 예의를 조금 깨고 있다. “사실이지만 친절하지 않은” 영역으로 들어가고 있다. 나는 누군가가 그렇게 하기로 한 선택을 옹호하고 있다. 가볍게 하는 일은 아니며, 도움이 되기를 바란다. ## 배경 상황을 간단히 정리하면 이렇다. - Bun은 타입스크립트 런타임이다. 더 빠른 NodeJS 같은 것이다. - 지그는 시스템 프로그래밍 언어다. 현대적인 C 같은 것이다. - Bun은 최근까지 지그로 작성됐다. 가장 큰 지그 코드베이스 중 하나였다. - Bun은 AI 기여가 [거의 100%](https://x.com/jarredsumner/status/2054525268296118363)라고 주장한다. - 지그는 AI 기여를 [0%](https://ziglang.org/code-of-conduct/)만 허용한다. - Bun은 선도적인 AI 모델 연구소인 앤트로픽에 인수됐다. - Bun의 창업자는 지그에서 unsafe 러스트로 대규모 에이전트 기반 재작성 실험을 했다. - 그 실험은 며칠 뒤 병합됐고, 지금은 공식 버전이 됐다. 이 상황은 몇 가지 측면에서 논란이 있다. 다만 관련자 중 실제로 Bun이 지그에 남기를 원하는 사람은 없는 듯하다. 드라마는 순전히 메타 논의에만 존재한다. 마이그레이션 과정 자체는 꽤 흥미롭다. 적절한 상황이라면 나도 비슷한 일을 해볼 만하다고 생각한다. ## 누구를 믿을 것인가 사람들이 자신의 프로젝트에서 지그와 러스트 중 하나를 고를 때, Bun 상황을 자연스럽게 하나의 데이터 포인트로 볼 것이다. 가장 큰 지그 사용자 중 하나가 결국 결정을 되돌렸다는 사실은 이유와 관계없이 의미 있어 보인다. 사람들은 무슨 일이 있었는지 이해하려 할 것이고, 다음 중 어느 쪽이 더 사실에 가까운지 판단하려 할 것이다. > **앤트로픽/Bun의 이야기**: Bun은 합리적으로 해볼 수 있는 모든 것을 시도했지만, 지그가 과제를 감당하지 못해 메모리 버그에 압도됐다. > **앤드루의 이야기**: Bun 코드는 엉망이다. 모든 것을 AI 에이전트로 작성하고 리뷰하는 등 그들의 엔지니어링 결정 때문이다. 나는 후자 쪽에 더 기운다. 하지만 지배적인 요인은 더 지루한 것이라고 본다. > **레이의 이야기**: 메모리 버그라는 정당한 도전에 직면했을 때, 실행 가능한 선택지는 여러 가지였다. 경영진은 러스트 재작성이라는 선택지를 기꺼이 승인했다. 새 Fable 모델을 보여줄 훌륭한 마케팅 기회였고, 앤트로픽은 이미 [러스트를 사용](https://www.anthropic.com/careers/jobs)하고 있으며, 지그는 앤트로픽 제품 사용에 공개적으로 반대하기 때문이다. 비즈니스 관점에서는 충분히 말이 된다. 다만 마케팅 스토리는 아니다. 마케팅은 그들의 AI가 이 재작성을 해낼 만큼 강력했다는 점에 초점을 맞춰야 했다. 그 AI가 use-after-free를 잡아낼 만큼 강력하지는 않았더라도 말이다. 좋든 싫든, 이제 이 짐은 러스트 대 지그 질문에서 가장 먼저 떠오르는 요소가 됐다. 이 상황은 커뮤니티의 눈에 제러드의 판단과 앤드루의 판단을 맞붙이는 경향이 있다. 앤트로픽의 확성기를 통해 나온 체면치레용 과장은 의도치 않게 지그의 평판에 영향을 줄 수 있다. 그래서 앤드루가 이쯤에서 그만두지 않고… *맥락을 조금 덧붙이기(add some context)*로 한 이유를 이해할 수 있다. ## 이것은 비방인가? 내 관점에서 여기서 책임을 물어야 할 당사자는 앤트로픽이다. 이 글의 핵심도 그것이다. 어떤 의미에서 Bun 창업자 제러드 섬너는 십자포화에 휘말리고 있다. 지그도 마찬가지다. 이 문제를 엄격하게 기술적 쟁점으로만 논의할 수 있다면 좋을 것이다. 곧 그 이야기로 가겠다. 하지만 나는 앤트로픽이 기술적 주장을 하고 있다고 생각하지 않는다. 그들은 볼거리를 다루고 있다. 앤트로픽은 자신들의 서사를 파는 데 제러드의 신뢰성을 활용하고 있다. 거기에 대응하려면 그의 신뢰성에 대해 논평하게 된다. 지저분한 일이다. 나도 좋아하지 않는다. 그래도 누군가가 말하고 행동한 일을 보도했을 때 그것이 비방처럼 보인다면, 어쩌면 그 행동 자체도 문제의 일부였을 수 있다. ## 고기 분쇄기 Bun 프로젝트에 대한 내 첫인상은 2022년 발표였다. 거기에는 채용 지원자에게 보내는 이런 경고가 포함돼 있었다. > Oven은 고된 일이 될 것이다. 특히 처음 9개월 정도는 그렇다. 워라밸이 일하지 않는 시간이 많다는 뜻이라면, 아마 잘 맞지 않을 것이다. 예비 관리자가 이런 말을 하는 것을 보면 여러 가지를 알 수 있다. 그중 결코 작지 않은 하나는 “이 사람은 자신이 무엇을 하는지 전혀 모른다”는 것이다. 꽤 괜찮은 코더 중 상당수는 좋은 관리자의 사례를 본 적이 없다. 그래서 관리가 무엇인지에 대해 온갖 이상한 생각을 갖고 있다. 항상 “크런치 타임(crunch time)”으로 달리는 것은 건강에도 나쁘고 생산성에도 나쁘다. 지식 노동에 관해서는 탄탄하게 입증된 사실이다. 참고 자료가 필요하다면 힐렐의 [Empirical Software Engineering](https://www.hillelwayne.com/talks/ese/) 중 Human Factors 섹션을 보라. 내 조언은 이렇다. [주 90시간 근무](https://x.com/jarredsumner/status/1544821137128927232)를 자랑하는 사람을 위해 일하지 말라. 밤에 잘 수 있는 능력을 지켜줄 사람을 위해 일하라. 앤드루는 자신의 글에서 Bun 팀의 경험에 대해 풍문으로 들은 내용을 이렇게 요약한다. > 형편없는 커뮤니케이션, 비현실적인 기대, 낮은 공감 능력, 경험 없음. 그냥 완전한 난장판 그러니까… 당연히 그랬을 것이다. 그 풍문은 본질적으로 공개적으로 발표된 내용을 반복하고 있다. 그들의 채용 공고는 차라리 “완전한 난장판에 지원할 사람 구함”이라고 써도 됐을 것이다. 우리가 이런 말을 공개적으로 하는 것은 예의에 어긋난다. 우리는 테크 브로들이 모서리를 깎아내는 일이 천재적인 생산성 해킹인 양 떠드는 것을 그냥 내버려둬야 한다. 그러면 그 말을 들은 사람들이 언젠가 우리를 불러 결과물을 고치게 할 수 있다. 내가 결과에 조금만 덜 신경 썼다면 훌륭한 거래였을 것이다. 꽤 돈이 된다. 참고로 나는 Bun을 몇 번 써봤고 제법 마음에 들었다. 멋진 기술은 나쁜 업무 환경에도 불구하고 만들어지는 경우가 많다. 그들의 환경이 버그 많고 유지보수 불가능한 엉망진창을 낳았다고 말하는 사람은 내가 아니다. *그렇게 말하는 쪽은 Bun(Bun is the one saying that)*이다. ## 좋은 말도 하자 마이그레이션 과정에 대한 글은 매우 훌륭하다. 재사용할 수 있는 세부 사항도 있다. 불만은 없다. 이것이 여기서 진짜 기여라고 생각한다. 특히 이것이 [unsafe](https://bun.com/bun-unsafe-audit) 러스트로의 포트였다고 솔직하게 설명한 점이 마음에 든다. 파일 단위의 문자 그대로의 마이그레이션을 가능하게 해 위험을 줄이고, 이후 단계에서 재설계를 할 길을 닦았다는 설명이다. 합리적인 결정을 잘 설명했다. 언어 선택이 점점 더 되돌릴 수 있는 결정이 되고 있다는 생각에는 어느 정도 진실이 있다. 이 방법은 [장단점](https://tomassetti.me/ai-rpg-migration-semantic-gap/)을 지닌 다른 재작성 자동화 유형 사이에서 자리를 잡게 될 것이다. 이런 기법들은 함께 사용할 수 있고, 형식 기법(Formal Methods)으로 더 견고하게 만들 수도 있다. 다르파의 [TRACTOR](https://www.darpa.mil/research/programs/translating-all-c-to-rust), 즉 Translating All C to Rust 연구 프로그램은 올해 [보고서](https://github.com/DARPA-TRACTOR-Program/Reports/blob/main/First_TRACTOR_Evaluation_Report.pdf)를 발표했다. 최신 기술 수준을 다루고 있을 것이다. 소프트웨어 현대화 프로젝트에 관한 내가 가장 좋아하는 책은 매리앤 벨로티의 [Kill It With Fire](https://nostarch.com/kill-it-fire)다. 에이전트가 낡은 코드로 할 수 있는 수를 더 많이 제공하더라도, 어디로 갈지 결정할 때는 여전히 좋은 판단과 커뮤니케이션이 필요하다. 다음으로 그 이야기를 해보자. ## 재작성 근거는 알맹이가 없다 기술적 결정을 설명하는 기본 요소는 다음과 같다. - 동기는 무엇인가? - 어떤 선택지를 검토했는가? - 장단점은 무엇인가? 리처드 펠드먼이 Roc 컴파일러를 러스트에서 지그로 옮기기로 한 결정을 설명한 [훌륭한 예](https://gist.github.com/rtfeldman/77fb430ee57b42f5f2ca973a3992532f)가 있다. 처음에는 그 결정에 충격을 받았다. 나는 언어 안전성에 어느 정도 광신적이다. 하지만 결국 그의 요점은 타당했고, 이 일을 계기로 지그에 대한 호기심이 생겼다. Bun 재작성이 병합됐을 때, 나는 비슷한 설명을 볼 수 있기를 바랐다. 두 달 늦게 우리가 받은 것은 이것이었다. - ✅ 동기는 무엇인가? - ⚠️ 어떤 선택지를 검토했는가? - 🚫 장단점은 무엇인가? 기술 리드를 지망하는 사람들에게 말하자면, 이런 요소를 대충 넘어가면 위험하다. 특히 “장단점”을 소홀히 하면, 처음부터 답을 정해놓고 문제에 접근한 뒤 사후적으로 정당화하고 있다는 인상을 줄 수 있다. 어쩌면 말하지 않는 이유가 있을지도 모른다. 정직하지 않게 느껴진다. ## 장점만 있고 단점은 없다 진짜 트레이드오프 비교 대신, 우리는 장점만 다루는 “Bun은 러스트에서 더 낫다” 섹션을 받는다. 이런 변화에는 언제나 트레이드오프가 있다. 명백한 하나는 빌드 시간이다. 일반적으로 큰 코드베이스에 러스트를 사용하면 안전성을 사고, 느린 컴파일이라는 비용을 치른다. 부끄러워할 일은 아니다. 이기는 거래가 될 수 있다. 과거에는 이 요소가 Bun에 충분히 중요했기 때문에, 그들은 이를 개선하려고 [지그 컴파일러를 포크](https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19)하기도 했다. 러스트 포트가 기여자의 빌드 시간을 늘렸다는 우리의 추정이 맞다면, 왜 그것을 공개하지 않는가? 영향을 인정하고, 전체적으로 올바른 선택이 되게 만든 우선순위를 설명하는 편이 더 신뢰감 있게 보인다. 또한 그들은 재작성 이후 이룬 다른 개선 사항을 목록에 섞어 넣어 분량을 불린 것처럼 보인다. 그것들은 사실 재작성과 별 관련이 없다. ## 스타일 가이드는 시도하지 않았나? 동기가 메모리 버그였다는 점을 떠올려보자. Bun의 유일한 버그 원인은 절대 아니었지만, 빈번한 원인이었다. 내가 세어보니 일주일에 네 건의 수정 커밋을 일으켰다. 고통스럽다. 이론적으로 모든 메모리 버그는 어떤 관례의 위반을 뜻한다. 이런 종류의 객체를 어떻게 다뤄야 하는지에 대한 기대가 깨진 것이다. 따라서 어떤 상황에서 무엇이 기대되는지 명확한 생각을 세우는 것이 마땅하다. 사실 어떤 언어든 효과적으로 사용하려면 그렇게 해야 한다. 러스트에도 [스타일 가이드](https://rust-lang.github.io/api-guidelines/)가 있다. 다만 수동 메모리 관리는 우리가 설정해야 할 기대의 범위를 넓힌다. 다른 사람들은 이 문제를 어떻게 해결했을까? 또 다른 대표적인 지그 코드베이스로 금융 거래 데이터베이스인 TigerBeetle이 있다. 이 프로젝트는 메모리 버그에 시달리지 않는다. 사실 현존하는 데이터베이스 중 가장 신뢰성 높은 것 중 하나로 보인다. 그들은 이것이 [TigerStyle](https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md) 접근법과 혁신적인 [테스트 전략](https://tigerbeetle.com/blog/2023-07-06-simulation-testing-for-liveness/) 덕분이라고 기꺼이 말할 것이다. 살펴볼 가치가 있다. “스타일(style)”이라는 단어가 과소평가일지도 모른다. 지그 코딩 지침을 한 요소로 포함한 하나의 엔지니어링 철학 전체다. TigerStyle의 맛을 조금 보자. 모든 애플리케이션이 이 정확한 전략을 그대로 복사해 붙여넣을 수는 없다. 하지만 메모리 할당과 다른 설계 결정의 관계를 잘 보여준다. > 모든 메모리는 시작 시 정적으로 할당해야 한다. **초기화 이후에는 어떤 메모리도 동적으로 할당하거나, 해제 후 재할당해서는 안 된다.** 이는 성능에 큰 영향을 줄 수 있는 예측 불가능한 동작을 피하고, use-after-free를 방지한다. 부차적 효과로, 우리의 경험상 이는 설계 단계에서 가능한 모든 메모리 사용 패턴을 미리 고려하지 않는 설계에 비해 더 효율적이고 단순하며, 성능이 좋고 유지보수와 추론이 쉬운 설계로 이어진다. 분명히 러스트로 재작성할지 저울질한다면, 먼저 현재 언어를 다르게 사용해야 하는지 검토할 것이다. Bun의 글은 그 선택지를 이렇게 제시한다. > 많은 프로젝트는 이런 질문에 스타일 가이드로 답하기로 한다. 지그의 예로 TigerBeetle의 [TigerStyle](https://tigerstyle.dev/)이 있고, 또 다른 예로 구글의 31,000단어짜리 [C++ 스타일 가이드](https://google.github.io/styleguide/cppguide.html)가 있다. 스타일 가이드의 어려움은 집행이다. 스타일 가이드가 지켜지도록 어떻게 보장할 것인가? 역사적으로 답은 코드 리뷰였고, 린터와 정적 분석기로 최선의 집행을 보조했다. 나는 다음 문장이 Bun의 스타일 가이드, 그것이 왜 작동하지 않았는지, 시간이 지나며 어떻게 발전했는지를 다룰 것이라고 예상했다. 아니었다. 그들은 커뮤니티가 이 문제를 해결하는 주된 방식에 형식적으로만 경의를 표하고, 어깨를 으쓱한 뒤 넘어가는 것처럼 보인다. 내가 뭔가 놓쳤나? 이 규모의 프로젝트를 4년 넘게 하면서 이런 문제를 겪었다면, 이것을 진지하게 시도하지 않았다는 점은 놀랍다. 마치 프로젝트가 [모든 맥락을 머릿속에 담아두고 회의는 절대 하지 않으려는](https://x.com/jarredsumner/status/1544821137128927232) 사람이 운영한 것 같다. 더 당혹스러운 점은 그들이 스타일 가이드를 기각하면서 드는 망설임이 *자기 글 안에서 반박(refuted within their own article)*된다는 것이다. 가이드는 집행하기 어렵다는 고전적 반론을 생각해보자. 타당하다. 다만 자신들이 사용하는 컴파일러를 포크할 만큼 고급 팀에게는 조금 이상한 장벽일 수도 있다. 핵심은 이것이다. 그들은 이미 집행 문제를 해결했다고 주장한다. 에이전트 기반 리뷰를 사용하기 때문이다. `PORTING.md` 자체가 마이그레이션 과정에 범위를 둔 스타일 가이드다. 그들은 방금 엄격한 지침에 따라 재작성된 전체 코드베이스에 대해 에이전트 기반 리뷰를 수행했고, 성공이라고 선언했다. 이건 앞뒤가 맞지 않는다. 에이전트 기반 리뷰가 작동한다고 가정하자. 나는 올바른 상황에서는 [가능하다](https://beyond.minimumcd.org/docs/agentic-cd/)고 생각한다. 그러려면 설계와 숙고된 지침이 필요하다. 내 생각에는 그들이 그 정신적 에너지를 재설계보다 재작성에 쏟는 데 더 흥분했을 뿐이다. 말하지 않은 이유는 여러 가지일 수 있다. 그것이 올바른 선택이었을 수도 있다. ## 아직도 문법을 걱정하나? 하나 더 꼬집고 싶은 부분이 있다. 에이전트 우선 코딩 논의에서 흔히 보이는 인지 부조화다. Bun의 글은 “스타일 가이드 선택지”가 어떤 모습일 수 있는지 잠깐 세부로 들어간다. > 명확한 소유권 기대를 타입 시스템에 명시적으로 적어 넣은 엄격한 스타일 가이드는 Bun에 실제 선택지였다. 지그에는 연산자 오버로딩이 없으므로, 아마 다음과 같은 코드가 많이 생겼을 것이다. ```zig fn foo(a_ptr: SharedPtr(TCPSocket)) !void { const a: *TCPSocket = a_ptr.get(); defer a_ptr.deref(); const b = try do_something_with_a(a); defer b.deref(); // ... } ``` > 이는 우리가 기대하는 지그보다 덜 쓰기 편하다. ```zig fn foo(a: *TCPSocket) !void { const b = try do_something_with_a(a); // ... } ``` 잠깐만. 한편으로는 우리가 리뷰할 수 없는 백만 줄짜리 PR을 걱정하지 않아도 된다고 한다. 그런데 인터페이스 경계에서 포인터 전달을 확실히 하기 위한 세 줄 추가는 걱정해야 한다고? 여기서 최선의 지그 관용구가 무엇이든, 연산자 오버로딩이 인체공학적인지 여부가 어떻든 간에, 아마 아닐 것이다. 이 글에 서명한 사람은 같은 사람이다. 그는 이렇게 [말했다](https://x.com/jarredsumner/status/2054525268296118363). > 우리는 이제 여러 달 동안 코드를 직접 타이핑하지 않았다 코드는 사람을 위한 것인가, 아닌가? 코드가 사람을 위한 것이 아니라면, 가끔 나오는 `SharedPtr` 래퍼가 눈에 거슬리는 일을 왜 걱정하는가? 이 예시가 실제 가독성 문제인지 여부는 받아들일 수도 있고 넘길 수도 있다. 내가 원하는 것은 AI 기업들이 가독성 같은 우려가 여전히 존재한다는 *사실(fact)*에 대해 일관성을 보이는 것이다. 그들은 이 문제에서 말을 흐린다. 그것이 소프트웨어 엔지니어링의 종말이라는 그들의 예언과 모순되기 때문이다. 유지보수성이 여전히 중요하다면 그것도 불편할 것이다. 그들의 제품은 기본적으로 유지보수성을 [더 나쁘게 만들기](https://www.openhands.dev/blog/evoclaw-benchmark) 때문이다. ## AI만으로는 충분하지 않다고 인정하라 서사로 돌아가자. 기술적 개선은 결국 이 에이전트 기반 재작성의 부수 효과였다. 진짜 비즈니스 기능은 *홍보(publicity)*였다. 이는 앤트로픽이 자신들이 해야 하는 이야기를 하는 데 도움이 됐다. “AI만으로 충분하다”는 이야기다. 원한다면 그 프레이밍을 받아들여도 된다. 같은 사건들은 정반대의 서사도 뒷받침할 수 있다. - AI만으로는 충분하지 않기 때문에 우리는 LLM을 에이전트 하네스로 감싼다. - AI만으로는 충분하지 않기 때문에 Bun은 러스트의 borrow-checker를 선택했다. - AI만으로는 충분하지 않기 때문에 Bun은 가독성을 위해 포인터 래퍼를 피하고 싶어 한다. - AI만으로는 충분하지 않기 때문에 Bun은 코드 구조가 유지보수자에게 익숙할 것이라고 강조했다. - AI만으로는 충분하지 않기 때문에 나는 이 글을 조사하는 동안 하이브리드 접근법으로 Bun의 지그 버전에서 버그 50개를 잡았다. 프로젝트 Bunsen이다. - AI만으로는 충분하지 않기 때문에 오픈소스 유지보수자들은 낮은 노력의 쓰레기 속에서 유용한 기여를 [가려내느라](https://www.reddit.com/r/opensource/comments/1q3f89b/open_source_is_being_ddosed_by_ai_slop_and_github/) [압도되고](https://kristoff.it/blog/contributor-poker-and-ai/) [있다](https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md). 관련 [기여](https://redmonk.com/kholterhoff/2026/02/26/generative-ai-policy-landscape-in-open-source/) 정책도 그렇다. 앤트로픽은 사람들이 모든 문제를 에이전트를 더 추가하면 해결할 수 있다고 믿게 만들어야 한다. 에이전트가 만들어낸 문제조차도 말이다. 더 나은 도구 대신 우리는 토큰을 산다. 기술을 배우는 대신 `SKILL.md`를 붙여넣는다. [The Psychology of Software Teams](https://www.drcathicks.com/)를 읽는 대신, 병렬 에이전트 세션 몇 개를 [팀(Team)](https://code.claude.com/docs/en/agent-teams)이라고 부른다. 소프트웨어 엔지니어링을 끝내려는 앤트로픽의 캠페인은 관련된 모두에게 역효과를 낸다. 약속하건대, [어두운 소프트웨어 공장(Dark Software Factory)](https://news.ycombinator.com/item?id=46801848)을 플라톤적 이상으로 삼지 않고도 코딩 에이전트를 도입할 수 있다. 나는 다음 주 [Software Should Work](https://softwareshould.work/) 콘퍼런스에서 프로그래밍 언어 설계의 방향과 함께 이 입장을 더 자세히 펼칠 예정이다. 우리는 사람들이 원하는 것을 만들고, 그것을 잘 만들기 위해 여기 있다. AI 거품 속에서 우리는 아무도 원하지 않는 것을 형편없이 만들라는 압박을 받는다. 거품을 터뜨려라.