주간 #50-2025: Anthropic의 Bun 베팅, PM 가뭄 & 시애틀의 AI 반발
Source: Dev.to
🎙️ 여기를 클릭하면 Madhu Sudhan Subedi Tech Weekly에서 청취할 수 있습니다 →
Bun JavaScript 런타임, Anthropic에 인수됨
Anthropic이 Bun JavaScript 런타임을 인수하면서 AI가 코드를 작성하고 배포하는 방식을 바꿀 수 있는 움직임을 보였습니다. 이제 Bun은 Claude Code의 네이티브 설치 프로그램과 같은 도구 뒤에 숨은 “핵심 인프라”로 자리매김하게 됩니다. Bun은 오픈소스이며 MIT 라이선스를 유지하고, 런타임, 패키지 매니저, 번들러, 테스트 러너, 단일 파일 실행 빌드를 한 번에 제공하는 터보 차지드 번들을 제공합니다.
내부적으로 Bun은 V8 대신 JavaScriptCore를 사용하고, 네이티브 코드는 Zig로 작성되어 독특한 기술적 장점과 JS 세계에서의 반항적인 정체성을 갖습니다. 창시자 Jarred Sumner는 Bun을 위해 약 2,600만 달러를 모금했지만 실질적인 수익은 거의 없었습니다. 이제 그는 AI 에이전트가 점점 더 많은 소프트웨어를 작성·테스트·배포함에 따라 공격적인 개발을 지원할 수 있는 장기적인 본거지로 Anthropic을 바라보고 있습니다.
하지만 긴장이 남아 있습니다. Zig의 창시자는 “AI/LLM 금지” 기여자 정책을 엄격히 적용하고 있는데, AI 기업이 이 언어에 크게 의존하고 있기 때문입니다. 개발자들은 Anthropic이 Bun을 AI 시대 앱의 기본 JS/TS 런타임으로 급격히 성장시킬 수 있다는 기대와, 현재는 무료이고 커뮤니티 주도인 프로젝트가 보드룸에서 결정되는 유료 기능이나 전략적 전환으로 기울어질 수 있다는 우려 사이에서 갈라지고 있습니다.
성장에 관심이 없을 때는 어디로 가야 할까?
사다리를 오르는 것이 목표가 아니라면 어떨까요? 한 주니어 개발자는 “성장 → 승진 → 반복”이라는 기본 경로에 의문을 제기합니다. 많은 역할이 개인 기여자에게는 실질적인 상승 여지가 거의 없고, 관리층에게는 꾸준히 이익을 주는 구조이기 때문입니다. 성과는 불투명한 기준으로 판단되고, “교육”은 순응을 의미하며, 심지어 눈에 띄지 않는 역할이라도 레거시 문제를 해결하려면 5년 이상의 경험이 필요합니다.
안정성과 목적을 중시하는 소프트웨어 경력의 공간이 있을까요? 성장 중심이 아닌 작은 기업, 개인 프로젝트, 오픈소스 작업이 더 의미 있는 트랙이 될 수 있습니다—사용자를 돕고, 누군가의 수익을 극대화하기 위해 존재하지 않는 유지 가능한 일.
팀과 채용 담당자를 위한 시사점: 모든 사람이 속도와 규모를 최우선으로 최적화하는 것은 아닙니다. 급부상하는 집단은 보너스와 직함보다 공정한 보상, 합리적인 범위, 자율성을 중시합니다. 질문은 성장 속도를 어떻게 높일 것인가가 아니라, 기업이 장인 정신과 기여를 선택하는 엔지니어에게 공간을 제공할 수 있느냐가 됩니다.
AI 기업, PM 채용 감소: 공개 채용 비중 34% 감소
제품 역할이 LLM이 팀 구축 방식을 바꾸면서 축소되고 있을까요? Riso Group은 AI 기업이 다른 분야에 비해 제품 관리자(Product Manager) 직책을 34 % 적게 공개하고 있음을 발견했습니다. AI 분야의 PM 비중은 전체 채용 중 2.3 %에 불과한 반면, DevTools, Consumer, Data, B2B, Fintech 등에서는 3.2–3.8 %를 차지합니다. 이는 100개 기술 기업에서 수집한 8,803개의 중복 제거된 직무명을 기반으로 한 분석이며, 대기업은 제외되었습니다. 차이는 명확합니다.
시사점은 AI‑우선 조직이 인력을 모델 구축, 인프라, 데이터 역할로 전환하고 기존 팀에 더 많은 제품 책임을 떠맡기고 있다는 것입니다. PM의 역할 범위는 보다 기술적이고 시스템 지향적으로 변할 가능성이 높으며, 순수한 조정 역할은 감소할 것입니다.
시애틀 모든 엔지니어가 AI를 싫어한다
왜 현재 시애틀 엔지니어들은 AI에 적대적인가? 이 에세이는 특히 Microsoft 내부에서 일어난 문화적 변화를 지적합니다—대규모 정리, 성능이 낮은 Copilot 도구 강제 사용, “AI 아니면 안 된다”는 조직 정치가 불만을 키워냈습니다. 엔지니어들은 팀이 “AI를 받아들이지 않아서” 프로젝트가 실패했다고 들었지만, 실제로는 작업을 더 느리고 못하게 만드는 도구를 사용하도록 강요받았습니다. 그 결과, 최고 인재는 “비 AI”로 재브랜딩되고 보상은 정체, 자율성은 사라졌습니다.
환경은 신념을 형성합니다: 엔지니어들은 AI가 쓸모 없고 자신은 AI 작업에 적합하지 않다고 생각하게 되며, 이는 기업(혁신이 중앙집중화되고 위축), 직원(경력 정체), 지역 개발자(‘AI’라는 라벨만으로 비난) 모두에게 해를 끼칩니다. 반면 샌프란시스코는 여전히 호기심과 구축 허가가 존재해, 자신의 주도성을 믿는 것이 경쟁 우위가 됩니다.
리더를 위한 시사점: AI를 정치적 방패로 쓰지 말고, 팀이 도구를 솔직히 평가하고 배포할 수 있게 권한을 부여하며, 냉소가 영구적인 저항으로 굳어지기 전에 신뢰를 재구축하십시오.
테스트 코드를 프로덕션 코드처럼 다루라
테스트 코드가 지나치게 관대하게 대우받고 있지는 않을까요? Mark Seemann은 프로덕션 코드에 적용되는 동일한 기준—가독성, DRY, 리팩터링, 리뷰—이 테스트에도 적용되어야 한다고 주장합니다. 복사‑붙여넣기 테스트 스위트, 주석 처리된 “좀비” 코드, 임의의 대기, 비동기 호출 차단 등은 유지보수를 어렵게 만들고 팀 속도를 늦춥니다. 좋은 코드의 목적은 컴퓨터가 아니라, 앞으로 코드를 읽고 수정할 인간에게 있습니다.
실용적인 가이드: 테스트 전용 베스트 프랙티스(xUnit Test Patterns 등)를 활용하고, DRY를 포기하지 않으면서도 설명적인 테스트를 작성하며, 동작이 바뀔 때 “샷건 서저리”가 발생하지 않도록 중복을 피하십시오. 예외적인 경우도 있습니다—테스트 코드가 실제로 배포되지 않을 경우 보안 및 플랫폼 규칙을 완화할 수 있습니다(예: 하드코딩된 테스트 자격 증명, .NET에서 특정 async 컨텍스트 규칙 무시, Haskell에서 고아 인스턴스 허용 등).
팀을 위한 시사점: 테스트 코드를 일급 시민으로 대하십시오; 이는 시스템 유지보수성의 일부이며, 임시 스캐폴드가 아닙니다.