내가 예전에 그랬듯 프로그래밍을 하면서 semver를 극도로 꺼렸다고 해도, 오픈소스 소프트웨어 배포는 정해진 단계를 밟는 과정이었다고 생각할 수 있다. 개발이 이루어지는 브랜치가 있고, 이 브랜치는 대체로 안정적으로 쓰기에는 부족하다. 그러면 일정 기간 개발을 동결하고(그 사이 새로운 불안정 브랜치에서 작업은 계속될 수 있지만) 버그를 고치고 사람들에게 테스트를 부탁한다. 어느 시점이 되면 버그 리포트가 줄어들고, 팀과 사용자는 앞으로 몇 주 안에 쉽게 발견될 만한 치명적인 결함은 더 이상 없다고 믿게 된다. 그러면 그 브랜치에 2.4 같은 이름을 붙이고, 그걸로 끝이다.

하지만 이제 AI 코딩 시대에는 개발만 바뀐 게 아니라 소프트웨어를 사용하는 행위 자체가 달라졌다. 소프트웨어에 특정 변경을 해달라고 AI에게 요청할 수 있는 건 당신뿐 아니라 소프트웨어를 받는 사람 역시 마찬가지다. 프로그래머가 주된 사용자층인 소프트웨어에서는 이 변화가 더욱 분명하지만, 기술에 친숙한 사용자일수록 AI와 코딩 에이전트에 접근하는 경우가 늘면서 전반적으로도 마찬가지다.

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

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

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

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

오늘날 소프트웨어는 그 어느 때보다 유연하다.某种 측면에서 이는 더 유동적인 방식으로 릴리스될 수 있다는 뜻이다. 또 문서 자체도 사람에게만 좋은 것이 아니라 코딩 에이전트가 시스템을 어떻게 변경해야 할지 이해할 수 있도록 만들어져야 한다는 뜻이기도 하다. 이것이 정확히 어떻게 진화할지, 안정성과 사용성, 기능이라는 서로 다른 차원 사이에서 적절한 균형점이 어디일지는 나로서도 아직 분명하지 않다. 하지만 우리 개발자들은 이 모든 것이 어디로 향하는지 눈을 크게 뜨고 지켜봐야 한다고 생각한다.