프로그래밍을 해오면서 예전의 저처럼 semver를 그다지 좋아하지 않았다고 해도, 오픈소스 소프트웨어의 배포가 과거에는 정해진 몇 단계로 이루어졌다고 생각해 볼 수 있습니다. 개발이 진행되는 브랜치가 하나 있습니다. 이 브랜치는 대개 안정적으로 쓰기에는 아직 준비가 덜 된 상태입니다. 그러다 일정 기간 동안 개발을 동결합니다(그 사이에 새로운 불안정한 브랜치에서 작업이 계속될 수는 있습니다). 버그를 고치고 사람들에게 테스트를 부탁합니다. 어느 순간 버그 리포트가 줄어들기 시작하고, 팀과 사용자가 앞으로 몇 주 안에 쉽게 발견될 만한 명백한 치명적 결함은 더 이상 없다고 믿게 됩니다. 그러면 그 브랜치를 2.4든 뭐든 이름을 붙여 릴리스합니다. 그게 전부입니다.

하지만 이제 AI 코딩 시대에는 개발만 바뀐 것이 아니라 소프트웨어를 사용하는 행위 자체가 영향을 받습니다. 소프트웨어에 특정 변경을 해달라고 AI에게 요청할 수 있는 것이 비단 개발자인 당신뿐 아니라, 그 소프트웨어를 받아 쓰는 사용자 자신도 그렇게 할 수 있게 되었기 때문입니다. 이는 주 사용자층이 프로그래머인 소프트웨어 영역에서는 이미 분명한 사실이지만, 기술에 친숙한 사용자들이 점점 더 AI와 코딩 에이전트에 접근하게 되면서 일반적으로도 마찬가지가 되고 있습니다.

이러한 변화 때문에 모든 것을 다듬어 놓은 안정 브랜치 하나와 모든 것이 아직 진행 중인 불안정 브랜치 하나만 두는 방식은 더 이상 올바른 접근이 아닐 수 있습니다. 코드 저장소는 완성된 제품이 될 수도 있지만, 특정 문제를 둘러싸고 어떻게 일을 처리하는지를 보여주는 템플릿이라면 훨씬 더 유용할 수 있습니다. 사용자는 특정 요구사항이나 하드웨어, 해결해야 할 구체적인 문제에 맞춰 코드를 특화하기 위해 수정할지도 모릅니다. 또한 일반 대중에게는 너무 불안정하거나 검증되지 않은 것이 다른 사용자 집단에게는 오히려 적격일 수도 있습니다.

Redis를 예로 들어 보겠습니다. 저는 몇 주째 sorted set의 메모리를 크게 절약해 주는 PR을 다듬고 있습니다. 이 작업이 받아들여지면 Redis가 어떻게 동작하는지 전혀 모르는 사람부터 수년 동안 코드 기여를 해 온 사용자까지, 모든 Redis 사용자에게 영향을 미치게 됩니다. 사소한 유스케이스부터 sorted set에서 50%의 메모리를 절약하는 것이 매년 클라우드 비용을 크게 줄이는 의미를 갖는 유스케이스까지 모두 포함합니다. 마지막 부류의 사용자에게는 (그저 ‘작동하는’ 무언가를 다듬기 위해 제가 하고 있는 모든 테스트와 설계 변경을 거쳐, 어쩌면 코드베이스에 들어가지도 못할 위험을 감수한 뒤 나오는) 최종 결과물보다 0일차부터 95% 완성된 브랜치를 갖는 것이 더 흥미로울 수 있습니다. 그들은 그 코드를 테스트하고, 적용하고, 반복 개선하며, 당면한 문제에 맞춰 더 특화할 수도 있습니다.

DwarfStar는 어쩌면 코드 저장소가 모든 기능 조합을 빠짐없이 커버하는 완제품이기보다 좋은 예시가 되어야 한다는 점을 더 잘 보여주는 사례일지 모릅니다. DwarfStar의 경우 로컬 추론을 두고 보면 다양한 종류의 GPU와 모델, 서버 모드, 에이전트 모드, CLI, SSD 스트리밍, 텐서 및 파이프라인 분산 실행이 있습니다. 모든 것을 모든 곳에서 테스트하는 일은 복잡합니다. 하지만 텐서 병렬 그래프 실행에 대한 탄탄한 예시 두 개만 있으면, 유능한 코딩 에이전트는 다른 백엔드/모델 조합에 대해서도 같은 것을 어떻게 구현할지 추론해 낼 수 있습니다. 마찬가지로 엔진이 두 개 모델을 충분히 잘 지원하고 나면, 기존 코드베이스를 코딩 에이전트를 위한 가드레일로 삼아 구현을 안내함으로써 세 번째 모델을 거의 자동으로 구현할 수 있습니다.

이 말이 DwarfStar 같은 프로젝트가 당장 쓸 수 있는 상태로 동작하지 않아도 된다는 뜻은 아닙니다. 다만 잘 지원되는 기능들의 집합에 집중하고, 그로부터 더 많은 경우의 수로 확장해 나가는 부분은 사용자가 직접 커버할 수 있도록 할 수 있다는 의미입니다. 또 다른 의미도 있습니다. main과 unstable만으로는 더 이상 충분하지 않다는 것입니다. 수많은 실험적 브랜치가 프로젝트의 필수적인 일부가 될 수 있습니다. 예를 들어 어제 Laguna S.1 모델이 공개되었습니다. 논리상으로는 흥미로워 보이지만, 과연 정말로 충분히 좋을까요? 새로 나온 DeepSeek v4 Flash 체크포인트 때문에 DwarfStar에는 그다지 중요하지 않게 될까요? 아직 판단하기에는 이릅니다. 하지만 함께 감을 잡기 위해 이 모델 구현을 담은 브랜치를 공개하는 것은 좋은 절충안입니다. 사람들이 직접 시도해 보고 코딩 에이전트로 다듬어 보면서, 커뮤니티가 함께 머지할 만한 가치가 있는지 판단할 수 있습니다. 더 나아가 오늘 저는 DwarfStar 내부 코드 전체가 만들어 놓은 레일 덕분에, 이 구현이 GPT 5.6 Sol에 의해 약 두 시간 만에 자동으로 작성되었다는 것을 알게 되었습니다. DS4와 GLM5.2를 구현할 때는 모델 카드와 해당 모델들의 어텐션 구현 세부 사항을 읽으며 많은 조율을 해야 했습니다. 이번에는 그냥 동작했습니다. GPT 5.6이 더 강력해진 것도 있지만, 기존 소스 코드 안에서 좋은 예시들을 많이 찾을 수 있었기 때문입니다.

오늘날 소프트웨어는 그 어느 때보다 유연해졌습니다. 이는 어떤 면에서는 더 유동적인 방식으로 릴리스될 수 있다는 뜻입니다. 또한 문서 자체도 사람에게만 좋은 것이 아니라 코딩 에이전트가 시스템을 어떻게 변경해야 하는지 이해할 수 있도록 만들어져야 한다는 뜻이기도 합니다. 이것이 정확히 어떻게 전개될지, 그리고 안정성과 사용성, 기능이라는 여러 차원 사이에서 균형점이 어디가 될지는 저도 아직 잘 모르겠습니다. 하지만 우리 개발자들은 이 모든 것이 어디로 향하고 있는지 눈을 크게 뜨고 지켜봐야 한다고 믿습니다.