코드는 싸졌지만 품질은 아니다 - Dioxus 팀이 에이전트로 야심찬 소프트웨어를 만드는 법

TL;DR

• Dioxus 팀은 코딩 에이전트로 Rust 코드 수만 줄을 만들었지만 대부분을 병합하지 못했다. 기능이 동작하는 것과 장기적으로 유지할 제품에 넣을 수 있는 것은 달랐다. 코드 생성량보다 변경을 받아들일 품질 기준이 중요하다.
• 에이전트의 강점은 방대한 플랫폼 지식과 지루한 검증 업무에 있다. Kotlin·Swift 연동은 2~3주 만에 출시했지만 초기 구현 뒤에도 약 2주를 테스트와 실제 기기 검증에 썼다. 구현 속도가 빨라져도 검증 책임은 남는다.
• Rust의 까다로운 규칙은 에이전트가 구현 부담을 맡을 때 장점이 될 수 있다. 빌림 검사기와 경계 조건을 처리하는 수고를 줄이면서 언어의 제약을 활용할 수 있기 때문이다. 그렇다고 개발자의 코드 이해가 불필요해지는 것은 아니다.
• 테스트 코드를 많이 만드는 것과 필요한 실패를 검사하는 것은 다르다. 팀은 테스트 조건과 API를 직접 설계하면서 에이전트를 아이디어 검토와 퍼징 하네스 제작에 활용한다. 자동 생성한 테스트의 수만으로 품질을 판단하지 않는다.
• 코드가 싸질수록 아키텍처와 리뷰에 더 많은 판단이 필요하다. Dioxus 팀은 AI 리뷰를 쓰면서도 모든 PR을 줄 단위로 읽는다. 미래의 요구사항에 맞게 구조를 지키는 일이 여전히 엔지니어의 역할이다.

Source

Building ambitious software — Jonathan Kelley, Dioxus Labs & Cognition — AI Engineer, 2026년 9월 11일.

영어 자동자막과 영상 메타데이터를 바탕으로 정리했다. 제품 규모·성능·개발 기간은 발표 시점의 발표자 설명이며 별도 벤치마크로 재현한 수치가 아니다.

Knowledge

기능이 동작해도 제품에 들어갈 수 없는 이유

Dioxus 팀은 오랫동안 AI 코딩에 회의적이었다. 고품질 Rust 코드를 만드는 일과 당시의 코딩 도구가 잘 맞지 않았기 때문이다. 에이전트가 Rust를 잘 다루기 시작하자 팀은 구독 한도를 소진할 만큼 적극적으로 사용했고 수만 줄의 기능과 수정 코드를 만들어 냈다. 오래 원했던 기능이 빠르게 생겼지만 실제 병합 기준을 통과한 코드는 극히 일부였다.

Jonathan Kelley가 슬롭 캐넌이라고 부르는 실패는 아무것도 못 만드는 상태와 다르다. 많은 산출물이 생겨도 팀이 유지하고 출시할 수 없다면 초안에 머문다. 코드가 동작하는지 외에도 기존 API와 맞는지, 쉽게 변경할 수 있는지, 다음 기능을 수용할 수 있는지도 확인해야 한다. 생성 속도를 높이는 것만으로 이 판단이 끝나지는 않는다. 해당 구간

Dioxus에서는 코드 자체가 제품이다

Kelley는 2021년 학부 마지막 여름에 Rust 크로스플랫폼 앱 프레임워크를 시작했다. 여러 언어와 플랫폼 도구를 오가는 대신 Rust로 앱을 만들고 HTML·CSS로 UI를 표현하며 React에서 반응성 아이디어를 가져오는 목표였다. 당시에는 필요한 부품이 충분하지 않아 반응성부터 폰트 렌더링, 핫 리로드와 앱 패키징까지 많은 기반을 직접 만들어야 했다. 목표를 이루려면 눈에 보이는 기능뿐 아니라 그 아래 개발 도구도 갖춰야 했다.

발표 시점의 Dioxus는 웹과 iOS·Android 앱이 같은 코드베이스와 컴포넌트를 공유하는 환경으로 성장했다. Kelley는 GitHub 스타 약 3만 7천 개와 Dioxus 앱의 누적 최종 이용자 2억 명 이상이라는 추정치를 제시한다. 이는 활성 이용자를 독립 집계한 수치로 해석하지 않는다. 사례에는 투표 소프트웨어와 데이터 과학 도구, 위성 충돌 회피 시스템도 포함된다. 사용자가 이 코드와 API 위에 자신의 사업을 구축하기 때문에 내부 구현의 품질이 곧 개발자 경험에 영향을 준다.

이런 기반 소프트웨어는 빠른 실험용 코드와 품질 기준이 다르다. 패치 릴리스가 기존 API를 깨뜨리지 않아야 하고 문서·예제·테스트·벤치마크도 함께 맞아야 한다. 문제가 생기면 고칠 수 있는 구조가 장기적인 출시 속도의 기반이다. 눈앞의 기능만 억지로 붙이면 다음 기능도 같은 제약을 물려받는다. 프로젝트 소개

렌더러와 핫 리로드가 보여주는 기술적 부담

Blitz는 가벼우면서 HTML·CSS를 지원하려는 렌더링 엔진이다. Firefox의 CSS 엔진을 가져오고 자체 HTML DOM과 하이브리드 GPU 렌더링 경로를 결합했다. 발표에서는 앱 번들 5MB 미만과 실행 시 메모리 50MB 미만이라는 규모를 소개한다. 어떤 앱과 환경에서나 보장되는 상한을 확인한 것은 아니지만 팀이 패키지 크기와 네이티브 실행 효율까지 제품 목표로 다룬다는 점은 분명하다.

Subsecond는 Rust·C·C++의 네이티브 코드 핫 리로드를 위한 엔진이다. 변경된 부분을 다시 컴파일하고 실행 중인 앱을 제자리에서 패치하며 발표자는 이를 약 100밀리초 안에 처리한다고 설명한다. 이런 기능은 단순한 UI 구현보다 런타임과 빌드 시스템에 대한 깊은 지식을 요구한다. 플랫폼마다 다른 동작을 연결해야 하는 소규모 팀에게 에이전트의 폭넓은 지식이 유용해진 배경이다. Blitz·Subsecond

어려운 언어의 비용을 누가 부담하는가

팀은 수년 동안 Rust의 학습 곡선을 낮추려고 노력했다. 에이전트를 쓰기 시작한 뒤에는 까다로운 언어 규칙이 다른 의미를 갖게 됐다. 빌림 검사기와 경계 조건을 상대하는 구현 부담을 에이전트가 맡으면 사람은 그 수고를 덜면서 언어의 제약을 활용할 수 있다. 개발자가 직접 쓰기 어려운 언어라는 이유만으로 에이전트에게도 나쁜 선택이 되는 것은 아니다.

다만 여기서 학습 곡선이 장점이 됐다는 평가는 Dioxus 팀의 개발 경험이다. 어떤 언어든 복잡할수록 좋다거나 타입 검사가 올바른 설계를 보장한다는 주장은 아니다. 실제로 같은 팀이 생성한 코드 대부분을 병합하지 못한 경험도 함께 제시된다. 언어가 잡는 오류와 제품의 아키텍처·API·사용성을 결정하는 판단은 서로 다른 층위에 남는다. Rust와 에이전트

지식이 넓고 지치지 않는 조수

크로스플랫폼 프레임워크 팀이 모든 운영체제와 런타임, 빌드 도구, 언어별 API의 세부 동작을 알고 있을 수는 없다. 에이전트는 많은 문서를 훑고 낯선 API와 바이너리를 조사하는 데 인내심과 지식의 폭을 제공한다. Blitz의 CSS 레이아웃 문제에서도 사양과 브라우저 구현 관행을 확인하는 부담을 줄였다. 사람이 복잡성을 피하려고 우회하던 문제를 더 정석적으로 풀 여유가 생긴다는 것이 Kelley의 경험이다.

대표 사례는 빌드 시스템에 깊이 통합한 Kotlin·Swift 플러그인이다. 팀은 에이전트를 활용해 약 2~3주 만에 이를 출시했다. 특히 초기 구현은 첫날쯤 나왔지만 이후 약 2주를 테스트 케이스와 실제 기기 검증에 썼다는 구분이 중요하다. React Native의 관련 기능에 수년이 걸렸다는 비교는 프로젝트 범위와 출발 조건이 통제된 실험이 아니다. 여기서 확실히 남길 교훈은 코드 작성의 단축이 검증의 생략을 뜻하지 않는다는 점이다. 연동과 디버깅

사소한 릴리스 업무가 품질을 지킨다

핵심 엔지니어가 세 명인 팀에서는 배포 압축파일의 디렉터리 구조를 확인하는 시간도 부담이다. 편집기 확장 기능을 추가한 뒤 매번 패치 릴리스에서 다시 확인하지 못하면 사용자가 깨진 통합을 먼저 발견하게 된다. 릴리스 체크리스트와 안정 버전으로의 버그 수정 백포트처럼 반복적이고 지루한 작업에 에이전트를 적용하면 작은 팀이 놓치기 쉬운 부분을 더 자주 점검할 수 있다.

문서도 단순히 많이 쓰는 것보다 코드와 일치하는지가 중요하다. 함수 구현은 바뀌었는데 주석이 예전 설명을 유지하면 예제와 API를 사용하는 사람이 잘못된 기대를 갖는다. 팀은 문서 주석을 여전히 직접 쓰면서 에이전트로 누락된 설명과 예제, 구현과 설명 사이의 불일치를 확인한다. Kelley는 최근 버전에서 이전보다 많은 패치 릴리스를 내고 주간 또는 주 여러 차례의 배포를 유지했다고 설명한다. 새로운 기능 생성만이 에이전트의 생산성은 아니다. 반복 업무와 문서

테스트 생성보다 테스트 조건의 설계가 어렵다

에이전트에게 API를 주면 테스트를 쉽게 만들지만 필요한 테스트를 만든다는 보장은 없다. 생성자를 호출해 보는 정도의 얕은 검사는 실행되더라도 중요한 실패를 놓칠 수 있다. 편집기를 실제로 열고 확장 프로그램을 설치해 동작을 확인해야 하는 종단 간 검사도 코드 몇 줄로 대체하기 어렵다. Dioxus 팀은 여전히 테스트 조건을 직접 열거하고 테스트 API와 실행 환경을 설계한다.

에이전트가 유용했던 지점은 테스트 아이디어를 검토하고 경계 조건을 찾는 대화 상대, 그리고 퍼징 하네스의 제작이었다. 퍼징은 잘못된 형식이나 예상하지 못한 입력을 대량으로 넣어 동작을 확인하는 접근이다. 이런 입력을 시스템에 연결하는 하네스를 만드는 데 에이전트가 강점을 보였다. 단, 하네스를 잘 만든다는 경험을 생성된 테스트의 판정 기준까지 모두 믿어도 된다는 결론으로 확장해서는 안 된다. 테스트와 퍼징

더 빠른 코드 생성 위에 남는 아키텍처와 리뷰

기능이 현재 구조에 맞지 않아도 에이전트는 큰 리팩터링을 주저하지 않고 진행하기 쉽다. 그러나 변경량이 커지는 것이 시스템의 장기 방향과 맞는지는 별도 판단이다. Dioxus 팀은 앞으로 추가할 기능과 시스템의 진화 방향을 생각하는 데 더 많은 시간을 쓰게 됐다. 의도를 충분히 전달하면 구현 품질이 높아질 수 있다. 다만 그 의도를 정리하는 일은 여전히 남는다.

팀은 AI 리뷰로 버그를 먼저 찾으면서도 모든 PR을 줄 단위로 읽는다. 외부 기여자는 당장의 기능이나 수정이 필요해 코드를 붙일 수 있지만 유지보수자는 그 변경이 전체 구조를 어디로 이끄는지 판단해야 한다. 에이전트가 팀의 생각을 알아서 읽을 수 없으므로 프롬프트에 전달한 목적과 제약도 결과에 영향을 준다. 코드를 쓰는 비용이 낮아졌을수록 읽고 받아들일 변경을 고르는 일이 중요해진다.

발표의 결론은 코드가 싸졌어도 품질은 싸지지 않았다는 말이다. 복잡한 문제를 우아한 구조로 풀고 이후 요구사항에 맞춰 유연성을 남기는 책임은 여전히 엔지니어에게 있다. Kelley는 마지막에 Dioxus 팀이 Cognition에 합류했다고 소개한다. 에이전트를 활용하는 방향은 분명하지만 이 발표가 제시한 기준은 사람의 검토를 없애는 공장보다 오래 유지할 수 있는 소프트웨어를 더 잘 만드는 팀에 가깝다. 아키텍처와 리뷰

더 생각해보기

• 생성됐지만 병합되지 못한 코드의 양을 에이전트 생산성 평가에 어떻게 반영할 것인가.
• 강한 타입 시스템이 잡는 오류와 아키텍처 리뷰가 잡는 문제를 구분하고 있는가.
• 구현 시간이 줄어든 만큼 실제 기기·통합 검증에 충분한 시간을 배정하고 있는가.
• 릴리스 체크리스트와 문서 정확성 중 작은 팀이 가장 자주 놓치는 부분은 무엇인가.
• 퍼징 하네스와 테스트 판정 기준을 각각 누가 설계하고 검토해야 하는가.
• 외부 기여자에게 장기적인 아키텍처 의도를 어떤 형태로 전달할 것인가.