시맨틱 버저닝(semver)에 거부감을 느껴본 개발자라면, 오픈소스 소프트웨어 배포가 오랫동안 일정한 단계를 밟아왔다는 사실만큼은 공감할 것이다. 개발이 이루어지는 브랜치가 있고, 그 브랜치는 대개 안정적인 운영 환경에 바로 쓰기에는 무리가 있다. 이후 일정 기간 개발을 동결하고(그 사이에 새로운 불안정 브랜치에서 작업을 이어갈 수도 있지만), 버그를 수정하고, 사람들에게 테스트를 요청한다. 어느 시점에 버그 리포트가 줄어들기 시작하고, 팀과 사용자 모두 앞으로 몇 주 안에 쉽게 발견될 만한 심각한 결함은 더 이상 없다고 느끼게 된다. 그러면 그 브랜치에 2.4든 뭐든 버전 번호를 붙이면 끝이다.
하지만 이제 AI 코딩의 시대에는 개발 방식만이 아니라 소프트웨어를 사용하는 행위 자체도 달라지고 있다. AI에게 소프트웨어 수정을 요청할 수 있는 건 개발자만이 아니라, 소프트웨어를 받아 쓰는 사용자도 마찬가지다. 주요 사용자층이 개발자인 소프트웨어라면 이 변화가 더욱 자명하지만, 기술에 친숙한 사용자들이 점점 더 AI와 코딩 에이전트에 접근할 수 있게 되면서 이는 전반적인 흐름이 되고 있다.
이런 변화가 일어나면서, 모든 것이 깔끔하게 다듬어진 안정 브랜치 하나와 모든 것이 진행 중인 불안정 브랜치 하나를 두는 방식이 더 이상 최선이 아닐 수 있다. 코드 저장소는 완성된 제품이 될 수도 있지만, 특정 문제를 해결하는 방법론의 템플릿으로 기능할 때 오히려 더 큰 가치를 발휘할 수 있다. 사용자는 특정 요구사항, 하드웨어, 해결해야 할 문제에 맞춰 코드를 수정하고 특화할 것이다. 또한 일반 대중에게는 너무 불안정하거나 검증되지 않은 것이, 다른 사용자들에게는 딱 맞는 선택일 수 있다.
Redis를 예로 들어보자. 나는 몇 주째 정렬된 집합(sorted set)의 메모리 사용량을 크게 줄이는 PR을 반복적으로 다듬고 있다. 이 작업이 병합된다면, Redis를 어떻게 쓰는지 전혀 모르는 사람부터 수년간 코드에 기여해온 사람까지 모든 Redis 사용자에게 영향을 미친다. 사용 사례도 사소한 것부터, 정렬된 집합에서 50% 메모리 절감이 매년 클라우드 비용의 상당 부분을 줄여주는 것까지 다양하다. 후자에 해당하는 사용자들에게는 '그냥 동작하는' 수준으로 다듬기 위한 모든 테스트와 설계 변경을 거친 최종 결과물(어쩌면 코드베이스에 끝내 들어오지 못할 수도 있는)을 기다리는 것보다, 처음부터 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이 더 강력해진 것도 있지만, 기존 소스 코드 안에서 좋은 예시를 많이 찾아냈기 때문이기도 하다.
오늘날 소프트웨어는 그 어느 때보다 유연하다. 이는 어떤 의미에서 소프트웨어를 더 유동적인 방식으로 배포할 수 있음을 뜻한다. 또한 문서 역시 사람이 읽기 좋은 것에 그치지 않고, 코딩 에이전트가 시스템을 어떻게 수정해야 하는지 이해할 수 있도록 작성되어야 한다는 의미이기도 하다. 이 흐름이 정확히 어떻게 전개될지, 안정성·사용성·기능이라는 여러 차원 사이에서 어떤 균형점이 맞는 것인지는 나도 아직 명확하지 않다. 하지만 우리 개발자들은 이 모든 흐름이 어디로 향하는지 예의주시해야 한다고 생각한다.
