비록 당신이 과거의 저처럼 프로그래밍 활동 과정에서 semver (Semantic Versioning)를 싫어했더라도, 오픈 소스 소프트웨어 배포를 정해진 단계들을 따르는 과정으로 생각할 수는 있습니다. 개발이 이루어지는 브랜치(branch)가 있고, 이 브랜치는 종종 신뢰할 수 있는 작업을 수행하기에 아직 준비되지 않은 경우가 많습니다. 그런 다음 일정 기간 동안 개발을 동결하고(그 사이에 새로운 불안정한 브랜치에서 작업이 계속될 수 있더라도), 버그를 수정하며, 사람들에게 테스트를 요청합니다. 어느 시점에 버그 보고(bug report)의 수가 줄어들기 시작하면, 당신의 팀과 사용자들은 향후 몇 주 내에 발견하기 쉬운 명백하고 치명적인 결함이 더 이상 존재하지 않는다고 믿기 시작합니다. 그때 당신은 해당 브랜치를 2.4 또는 그 무엇이라 부르고, 그것으로 끝납니다. 하지만 이제 AI 코딩과 함께, 변화한 것은 단지 개발뿐만이 아니라 소프트웨어를 사용하는 행위 자체도 영향을 받고 있습니다. 소프트웨어에 특정 변경 사항을 적용하도록 AI에게 요청할 수 있는 것은 당신뿐만이 아니라, 소프트웨어의 수신자 또한 마찬가지입니다. 이는 소프트웨어의 주요 사용자층이 프로그래머인 도메인에서는 명백하지만, 기술적 성향을 가진 사용자들이 점점 더 많은 AI 접근 권한과 코딩 에이전트(coding agents)를 갖게 됨에 따라 일반적인 상황에서도 마찬가지입니다. 이러한 변화 때문에, 모든 것이 다듬어진 안정적인 브랜치(stable branch)와 모든 것이 진행 중인 불안정한 브랜치(unstable branch)를 두는 아이디어는 더 이상 올바른 방식이 아닐 수도 있습니다. 코드 저장소(code repository)는 그 자체로 완성된 제품일 수도 있지만, 주어진 문제에 대해 무언가를 수행하는 방법의 템플릿(template)이 된다면 훨씬 더 유용할 수 있습니다. 아마도 사용자는 특정 요구 사항, 하드웨어, 또는 해결해야 할 특정 문제에 맞게 특화하기 위해 코드를 수정할 것입니다. 또한, 일반 대중에게는 너무 불안정하거나 검증되지 않은 것이 다른 사용자 집단에게는 적절한 것일 수도 있습니다. Redis의 사례를 들어보겠습니다. 저는 몇 주 동안 정렬된 집합(sorted sets)에 대해 강력한 메모리 절약 기능을 제공하는 PR (Pull Request)을 반복해서 수정하고 있습니다.

이 작업이 승인된다면, Redis가 어떻게 작동하는지 전혀 모르는 사람들부터 수년에 걸쳐 코드를 기여해 온 사용자들에 이르기까지 모든 Redis 사용자에게 영향을 미칠 것입니다. 아주 사소한 사용 사례부터, 정렬된 집합(sorted sets)에서 50%의 메모리 절약이 매년 막대한 클라우드 비용을 절감할 수 있는 사용 사례까지 그 범위는 넓습니다. 후자의 경우, (단순히 "잘 작동하는" 무언가를 정교화하기 위해 제가 수행하고 있는 모든 테스트와 설계 변경을 거친 후) 최종 제품을 얻는 것보다, 첫날부터 95% 완성된 브랜치를 갖는 것이 더 매력적일 수 있습니다. 이는 사용자가 직접 테스트하고, 적응시키고, 반복하며, 심지어 당면한 문제에 맞춰 더 특화할 수 있는 코드이기 때문입니다. 아마도 DwarfStar는 코드 저장소가 기능 매트릭스의 모든 부분을 다루는 완성된 제품이라기보다, 어떻게 좋은 예시가 되어야 하는지를 보여주는 더욱 설득력 있는 사례일 것입니다. DwarfStar의 경우, 로컬 추론(local inference)을 통해 다양한 종류의 GPU, 모델, 서버 모드, 에이전트 모드, CLI, SSD 스트리밍, 텐서(tensor) 및 파이프라인 분산 실행을 제공합니다. 모든 곳에서 모든 것을 테스트하는 것은 복잡한 일입니다. 하지만 텐서 병렬 그래프 실행(tensor parallel graph execution)에 대한 두 가지 확실한 예시가 있다면, 강력한 코딩 에이전트(coding agent)는 다른 백엔드/모델 쌍에 대해서도 동일한 것을 구현하는 방법을 추론할 수 있습니다. 마찬가지로, 두 개의 모델을 충분히 잘 지원하는 엔진이 있다면, 기존 코드베이스를 코딩 에이전트의 가드레일(guardrail)로 사용하여 구현을 안내함으로써 세 번째 모델을 거의 자동적인 방식으로 구현할 수 있습니다. 이것이 DwarfStar와 같은 프로젝트가 즉시 실행 가능(out of the box)할 필요가 없다는 뜻은 아니지만, 사용자가 스스로 커버할 수 있는 더 많은 가능한 상황으로 확장될 수 있는 일련의 기능들을 매우 잘 지원하는 데 집중할 수 있다는 의미입니다. 이는 또한 다른 의미이기도 합니다. 즉, main과 unstable 브랜치만으로는 더 이상 충분하지 않다는 것입니다. 많은 실험적인 브랜치들이 프로젝트의 필수적인 부분이 될 수 있습니다. 예를 들어, 어제 Laguna S.1 모델이 출시되었습니다.

서류상으로는 흥미로워 보입니다. 하지만 정말 충분히 좋을까요? 새로운 DeepSeek v4 Flash 체크포인트(checkpoints)가 DwarfStar에 있어 더 이상 유의미하지 않게 만들까요? 말하기에는 너무 이릅니다. 하지만 집단적인 아이디어를 형성하기 위해, 이 모델 구현을 포함한 브랜치(branch)를 공개하는 것은 좋은 절충안입니다. 사람들이 이를 시도해 보고, 자신들의 코딩 에이전트(coding agents)로 이를 개선할 것이며, 커뮤니티는 이것이 병합(merge)할 가치가 있는지에 대해 집단적으로 의견을 모을 수 있기 때문입니다. 게다가, 오늘 저는 DwarfStar 내부의 코드 코퍼스(corpus)가 형성한 가이드라인 덕분에 GPT 5.6 Sol이 구현을 약 2시간 만에 자동으로 작성하는 것을 목격했습니다. DS4와 GLM5.2를 구현할 때는 모델 카드(model card)를 읽고 해당 모델들의 어텐션(attention) 구현 세부 사항을 파악하는 등 많은 조종(steering)이 필요했습니다. 하지만 이제는 그냥 작동했습니다. GPT 5.6은 더 강력할 뿐만 아니라 기존 소스 코드 내에서 많은 좋은 예시들을 찾아냈습니다. 오늘날의 소프트웨어는 그 어느 때보다 유연합니다. 어떤 면에서 이는 소프트웨어가 더 유동적인 방식으로 출시될 수 있음을 의미합니다. 또한, 이는 문서(documentation) 자체가 인간뿐만 아니라 코딩 에이전트가 시스템을 어떻게 변경해야 하는지 이해할 수 있도록 작성되어야 함을 의미합니다. 이것이 정확히 어떻게 진화할지, 그리고 안정성(stability), 사용성(usability), 기능(features)이라는 서로 다른 차원 사이의 적절한 균형점이 어디가 될지는 저에게도 불분명하지만, 우리 개발자들은 이 모든 것이 어디로 향하고 있는지 확인하기 위해 눈을 크게 뜨고 지켜봐야 한다고 믿습니다.