저는 Atlarix를 만들고 있습니다. 이는 단순히 오픈 웨이트 (open-weight) 모델들과 호환되는 수준을 넘어, 오픈 웨이트 프론티어 랩 (frontier labs) (DeepSeek, Qwen, Kimi, MiniMax)을 위해 구축된 데스크톱 코딩 하네스 (coding harness)입니다. 저의 전체적인 논지는 하네스 (harness)가 힘든 작업을 대신 수행할 때, 약한 오픈 웨이트 모델과 프론티어 모델 사이의 격차가 좁혀진다는 것입니다.

그래서 저는 이 논지를 제가 생각할 수 있는 가장 가혹한 곳에서 테스트해 보기로 했습니다. 바로 오픈 웨이트 모델만을 사용하여 프론티어 랩의 실제 프로덕션 리포지토리 (production repo)에 실제 코드를 기여하는 것이었습니다.

현재 두 개의 풀 리퀘스트 (Pull Requests, PRs)가 Alibaba의 오픈 소스 코딩 에이전트인 QwenLM/qwen-code에 병합되었습니다. 잘 풀리지 않았던 부분과 작업 방식을 결정지었던 제약 사항을 포함하여, 이에 대한 솔직한 버전을 공유합니다.

첫 번째 시도는 닫혔습니다 — 그것은 정당했습니다

저의 첫 번째 시도는 야심 찼습니다. 완전한 상시 실행형 스케줄 태스크 데몬 (scheduled-task daemon)을 만드는 것이었습니다. 대화형 세션이 열려 있지 않아도 크론 (cron) 스케줄에 따라 실행되는 태스크, 시스템 서비스 설치, 웹훅 (webhook) 트리거 등 모든 기능을 포함했습니다. 4단계의 배포 단계를 거쳐 약 5,000줄에 달하는 분량이었습니다.

메인테이너 (maintainer)가 이를 닫았습니다. 그리고 그들은 옳았습니다.

문제는 코드가 작동하지 않았던 것이 아닙니다. 리포지토리에 이미 장기 실행 데몬 (qwen serve)과 제가 확장했어야 할 내구성이 있는 스케줄러가 있었음에도 불구하고, 저는 자체적인 저장 형식과 라이프사이클 (lifecycle)을 가진 '두 번째의 병렬' 데몬을 구축했다는 점이었습니다. 게다가 하나의 PR에 4단계를 담는 것은 제대로 리뷰하기에는 너무 과했습니다.

메인테이너의 피드백은 직설적이면서도 동시에 관대했습니다. 기존 인프라를 재사용하고, 변경 사항을 점진적으로 만들며, 리뷰 가능한 단위로 나누라는 것이었습니다. 약 300줄 정도의 확장 작업으로 끝날 수 있었던 것을 저는 수천 줄의 중복 코드로 작성해 버렸습니다.

뼈아픈 경험이었습니다. 하지만 이는 전체 과정에서 일어난 가장 유익한 일이었습니다. 왜냐하면 모든 오픈 소스 기여자가 결국 배우게 되는 교훈을 가르쳐 주었기 때문입니다: 구축하기 전에 기존 아키텍처 (architecture)를 읽고, PR을 리뷰 가능한 수준으로 작게 유지하라.

그래서 대신 적절한 규모의 작업을 수행했습니다

거대한 기능을 즉시 재구축하려고 애쓰는 대신, 저는 범위가 명확하고 작은 문제, 즉 리뷰하기 쉽고, 되돌리기(revert) 쉬우며, 무언가를 망가뜨릴 가능성이 낮은 종류의 변화를 찾아 나섰습니다.

저는 웹 셸(web-shell)의 모델 선택기(model picker)에서 하나를 찾아냈습니다.

PR #6209 — 웹 셸 UI에서의 비전 모델 (vision model) 지원. CLI에서는 비전 모델을 선택할 수 있었지만, 웹 셸 데몬(daemon) UI에서는 불가능했습니다. 저는 코드베이스가 이미 다른 모델 모드에 사용하고 있던 정확한 패턴을 따라 이를 추가했습니다. 작고, 기계적이며, 관례에 부합하는 작업이었습니다. 그리고 머지(merge)되었습니다.

PR #6236 — 실제 데이터 손실 수정. 이 작업은 규모가 보여주는 것보다 훨씬 더 중요했습니다. 사용자가 웹 셸 선택기에서 비전 모델을 선택하면 성공 토스트(success toast) 메시지는 표시되지만, 선택 사항은 조용히 무시되었습니다. 선택기가 모델 ID를 한 가지 형식(modelId(authType), ACP 스타일)으로 저장하는 반면, 핵심 리졸버(resolver)는 다른 형식(authType:modelId)을 기대했기 때문입니다. 이 불일치로 인해 저장된 값이 결코 해결(resolve)되지 않았고, 시스템은 조용히 자동 선택(auto-select) 방식으로 되돌아갔습니다. 설정 페이지에는 여전히 해당 값이 표시되었기에 실패가 완전히 가려졌습니다. 사용자의 명시적인 선택은 아무런 효과가 없었지만, 아무도 사용자에게 이를 알려주지 않았습니다.

수정 사항으로는 데이터를 영구 저장하기 전에 형식을 다시 인코딩하는 작업, 취약한 삼항 연산자 체인(ternary chains)을 대체하기 위한 타입 안전(type-safe) 디스패치(dispatch), 그리고 누락된 영어 및 중국어 국제화(i18n) 키 추가가 포함되었습니다. 이 또한 머지되었습니다.

솔직한 이야기: 모델들이 완벽한 코드를 작성하지는 않았습니다

이 부분이 제가 실제로 관심을 두는 부분입니다. 왜냐하면 보통 거품(hype)이 끼는 지점이 바로 여기이기 때문입니다.

두 PR 모두 여러 차운의 실제 메인테이너(maintainer) 리뷰를 거쳤습니다. 그리고 메인테이너들 — Alibaba 협력자들과 Qwen 자체 모델로 실행되는 자동 리뷰어 — 은 실제 버그들을 찾아냈습니다. 스타일 지적이 아니었습니다. 실제 보안 및 라이프사이클(lifecycle) 문제였습니다. 잘못된 입력값에 대해 계산된 HMAC 체크, 타이밍 공격(timing-attack)에 취약한 토큰 비교, 중지된 프로세스에서 실행될 수 있는 타이머, 웹훅(webhook) 경로에서 조용히 제거된 인증 설정(auth config) 등이 발견되었습니다.

저는 머지(merge)하기 전에 각각의 문제를 수정하고 재검증했습니다. #6236 PR의 경우, 메인테이너(maintainer)가 승인하기 전에 수정 사항이 엔드 투 엔드(end-to-end)로 작동하는지 확인하기 위해 실제 브라우저 테스트와 스크린샷을 사용하여 로컬 환경에서 직접 PR을 빌드하기까지 했습니다.

그 리뷰 루프(review loop)가 바로 핵심입니다. 제 주장은 "오픈 웨이트 (open-weight) 모델이 결점 없는 코드를 작성했다"가 아닙니다. 그렇지 않았습니다. 제 주장은 좋은 하네스 (harness)에 의해 구동되는 오픈 웨이트 (open-weight) 모델이 아키텍처 피드백을 받아들여, 프런티어 랩 (frontier lab)의 시니어 메인테이너가 머지할 의사가 있을 정도의 결과물로 반복 개선(iterate)할 수 있다는 것입니다. 이는 "AI가 한 번에 해냈다"는 말보다 훨씬 더 흥미롭고 훨씬 더 정직한 결과입니다.

아무도 말해주지 않는 제약 사항: 비용

혼자서 무언가를 구축하는 현실이기에, 투명하게 밝힐 가치가 있다고 생각하는 세부 사항이 하나 있습니다.

PR #6209는 OpenRouter를 통해 거의 전적으로 Qwen (3.6 Plus, 3.7 Plus/Max)을 사용하여 구축되었습니다. 하지만 PR #6236을 진행하던 도중 OpenRouter 크레딧이 부족해지기 시작했습니다. 실제 사용자들을 위해 런웨이 (runway)를 보존해야 하는 1인 창업자로서, 저는 대신 DeepSeek API 크레딧을 사용하기 시작했습니다. 결과적으로 #6236은 Qwen과 DeepSeek가 대략 50:50으로 섞인 형태가 되었습니다.

이 사실을 숨기고 전부 "100% Qwen"이라고 주장할 수도 있었습니다. 하지만 두 가지 이유 때문입니다. 첫째, 그것은 사실이 아니며, 이런 게시물의 가치는 정직함에 있습니다. 둘째, 이는 결과물을 약화시키는 것이 아니라 오히려 더 넓은 범위를 포괄하게 만듭니다. 제 논지는 결코 "특정 Qwen"에 국한된 것이 아니었습니다. 논지는 "그들을 위해 구축된 하네스 (harness) 내에서 오픈 웨이트 (open-weight) 모델은 실제 작업을 수행할 수 있다"는 것이었습니다. 두 개의 서로 다른 오픈 웨이트 (open-weight) 랩 (lab)을 통해 이를 성공시킨 것은, 단 하나의 랩으로 성공시킨 것보다 더 강력한 증거가 됩니다.

어떤 프런티어 모델 (frontier model)도 두 PR을 작성하지 않았습니다. 오직 Atlarix에서 실행되는 오픈 웨이트 (open-weight) 모델들인 Qwen과 DeepSeek뿐이었습니다.

이것이 왜 중요한가 (적어도 저에게는)

저는 나이로비에서 활동하는 독학 개발자입니다. 제가 대규모로 실행할 여력이 있는 모델들은 오픈 웨이트 (open-weight) 모델들입니다. Atlarix가 존재하는 이유는 이러한 모델들을 단순히 "데모용으로 적당한" 수준이 아니라, 모델을 직접
*훈련(train)*하는 사람들이 관리하는 리포지토리 (repo)에 코드를 배포할 수 있을 만큼 진정으로 생산적인 도구로 만들 방법이 필요했기 때문입니다.

Tier-1 연구소의 프로덕션 리포지토리 (repo)에 병합된 두 개의 PR이, 오픈 웨이트 (open-weight) 모델이 작성한 하네스 (harness)를 통해 생성되었고, 해당 연구소의 관리자 (maintainer)들에 의해 검토 및 병합되었다는 사실은 제가 제시한 가설을 증명할 수 있는 가장 명확한 증거입니다.

오픈 웨이트 모델과 프런티어 (frontier) 모델 사이의 격차는 실재합니다. 하지만 그 격차의 상당 부분은 가중치 (weights)가 아닌 하네스 (harness)에 존재합니다. 그 격차를 좁힌다면, 직접 실행할 수 있는 모델도 자신의 체급을 훨씬 뛰어넘는 성능을 발휘할 수 있습니다.

Atlarix는 atlarix.dev에서 활동하고 있습니다. 만약 여러분이 오픈 웨이트 (open-weight) 모델로 무언가를 구축하고 있거나 모델 불가지론적 (model-agnostic) 도구에 대해 고민하고 있다면, 진심으로 의견을 나누고 싶습니다.