AI 시대의 야심찬 소프트웨어 개발: Dioxus와 코딩 에이전트의 실전 교훈

---

title: "AI 시대의 야심찬 소프트웨어 개발: Dioxus와 코딩 에이전트의 실전 교훈" title_original: "Building ambitious software — Jonathan Kelley, Dioxus Labs & Cognition" source: aiDotEngineer channel: AI Engineer video_id: H7vFrcNWXzs url: https://www.youtube.com/watch?v=H7vFrcNWXzs date: 2026-09-12 category: ai-llm

📌 핵심 질문 / 야심찬 소프트웨어를 AI 시대에 어떻게 지속 가능한 품질로 만들 것인가

==코드는 싸졌지만 품질은 싸지지 않았으며, 코딩 에이전트의 가치는 구현 속도보다 지식 탐색·반복 검증·품질 유지에 있고 최종적인 설계 책임은 엔지니어에게 남는다.==

• Dioxus는 Rust의 네이티브 성능과 타입 시스템, HTML·CSS의 친숙함을 결합해 크로스 플랫폼 앱 개발의 복잡성을 줄이려는 시도에서 출발했다.
• 코딩 에이전트는 Rust의 borrow checker, 운영체제별 API, CSS 표준처럼 사람이 일일이 조사하기 어려운 지식 문제와 반복 작업에서 특히 강했다.
• 장기 프로젝트의 기반 구조가 나쁘면 에이전트가 그 위에 더 빠르게 스파게티 코드를 쌓을 뿐이므로, 아키텍처·테스트 의도·코드 리뷰는 자동화할 수 없다.

Jonathan Kelley가 2021년 학부 마지막 여름에 시작한 Dioxus는 2026년 수만 개의 GitHub 스타와 수백만 명의 누적 사용자를 가진 앱 개발 스택으로 성장했다. 이 성장은 프레임워크를 처음부터 만드는 야심, 브라우저 수준의 기반 기술을 직접 만드는 집요함, 그리고 최근 코딩 에이전트를 지식 조수와 품질 자동화 도구로 재배치한 결과를 함께 보여준다.

1. Dioxus의 출발점: 익숙한 UI와 Rust 네이티브 성능의 결합

Dioxus의 핵심 설계는 여러 플랫폼의 도구 체인을 오가는 비용을 없애고, 개발자가 하나의 Rust 코드베이스에서 익숙한 웹 UI 모델로 네이티브 앱을 만들게 하는 것이었다.

1.1. 학부 마지막 여름에 선택한 문제

1. 전형적인 진로 대신 직접 프레임워크를 만들다

   1. 출발 시점: 5년 전인 2021년, Kelley는 학부 과정의 마지막 여름을 Google 인턴십이나 AI 연구에 쓰는 대신 크로스 플랫폼 앱 프레임워크 아이디어를 탐구했다.
   2. 기술 선택: 그 아이디어의 구현 언어로 Rust를 택했고, 당시 Rust가 아직 틈새 언어였지만 생태계와 툴링이 빠르게 성장하고 있다는 점에 주목했다.

2. Rust의 매력

   1. 네이티브 성능: 가상 머신(VM) 없이 네이티브 코드를 만들 수 있어 앱 런타임의 불필요한 층을 줄일 수 있었다.
   2. 안전한 구조와 배포성: 견고한 타입 시스템과 간단한 크로스 컴파일이 복잡한 플랫폼 조합을 다루는 기반이 됐다.
   3. 개인적 동기: 네이티브 성능·타입 시스템·크로스 컴파일이라는 조합이 매우 기술 덕후다운 선택이지만 강력한 설득력을 가졌다고 평가했다.

1.2. React Native와 Flutter에 대한 대안

1. 하나의 코드베이스라는 질문

   1. 복잡성 제거: 수십 가지 툴체인과 프로그래밍 언어, IDE를 플랫폼마다 익히는 대신 모든 앱을 Rust로 작성하자는 질문에서 Dioxus의 아이디어가 시작됐다.
   2. 친숙한 마크업: UI 마크업은 HTML과 CSS를 사용해 웹 개발자가 즉시 이해할 수 있는 표면을 유지했다.

2. 2021년 당시의 기술적 판단

   1. 기존 선택지의 약점: React Native는 불안정하고 다듬어지지 않았으며, Flutter는 느렸고, 두 프레임워크 모두 네이티브 API와 충분히 잘 작동하지 않는다고 판단했다.
   2. Rust의 차이: Rust로 추상화된 네이티브 코드를 만들면 VM, 프로세스 간 통신(IPC), JavaScript가 필요 없었다.
   3. 웹 생태계 재사용: HTML·CSS를 UI에 쓰고 React에서 반응성(Reactivity) 아이디어를 가져오면 방대한 웹 컴포넌트와 웹 툴링을 재사용할 수 있었다.

3. 목표 사용자 경험

   1. 강력함: 네이티브 성능과 플랫폼 기능을 활용하는 매우 강력한 앱 프레임워크를 지향했다.
   2. 친숙함: 평균적인 개발자가 새로운 패러다임을 처음부터 배울 필요 없이 HTML·CSS·React와 닮은 모델로 진입하도록 설계했다.

1.3. “쉽다고 생각했기 때문에” 처음부터 만든 기반 기술

1. 야심의 실제 크기

   1. 도전 대상: React Native와 Flutter에 도전하는 일은 단순한 앱 프로젝트가 아니라 이미 널리 쓰이는 크로스 플랫폼 생태계 전체와 경쟁하는 일이었다.
   2. 초기 현실: 2021년에는 Dioxus를 만들 때 가져다 쓸 수 있는 기성 컴포넌트가 거의 없었다.

2. 직접 구현해야 했던 층

   1. UI 기반: 반응성, 폰트 렌더링, HTML·CSS 처리처럼 사용자가 곧바로 체감하는 기능을 처음부터 만들었다.
   2. 개발 경험: 핫 리로딩과 애플리케이션 번들링도 외부 도구에 의존할 수 없어 직접 구현했다.
   3. 브라우저 구축: 웹 브라우저를 만드는 것처럼 보이는 작업까지도 목표를 향해 가기 위한 필수 단계가 됐다.

3. 출발점의 역설

   1. 표면적 이유: “앱 프레임워크를 만드는 일이 쉬워 보였기 때문”이라는 생각으로 시작했다.
   2. 실제 이유: 완성된 부품이 없는 상태에서 렌더러·빌드·런타임을 모두 만들어야 했으므로, 결과적으로 가장 야심찬 종류의 소프트웨어 프로젝트가 됐다.

2. 2026년의 성과: 프레임워크를 넘어선 앱 개발 스택

Dioxus는 처음 약속한 크로스 플랫폼·네이티브 렌더링·Rust 핫 리로드·번들 분할을 구현했고, 앱을 만드는 데 필요한 전체 스택을 재발명하고 개선하는 단계에 도달했다.

2.1. 하나의 코드베이스와 실제 사용 규모

1. 플랫폼 간 공유

   1. 웹과 모바일: 같은 코드베이스에서 강력한 풀스택 웹 애플리케이션을 만들 수 있다.
   2. 컴포넌트 재사용: 그 웹 앱의 컴포넌트를 iOS와 Android 앱에서도 공유할 수 있다.

2. 생태계 지표

   1. 오픈 소스 관심도: GitHub에서 거의 37,000개의 스타를 받았고 다운로드는 수백만 회에 이르렀다.
   2. 도달 범위: Dioxus로 만들어진 앱은 전 세계에 배포됐으며 누적 최종 사용자는 2억 명이 넘는 것으로 추정된다.

3. 응용 분야의 폭

   1. 소프트웨어 제품: 사용자들은 AI 어시스턴트와 데이터 과학 도구를 만들었다.
   2. 공공·안전 분야: 투표 소프트웨어와 우주 공간의 위성 충돌 회피 시스템도 Dioxus로 구축됐다.

2.2. 사용자 친화성을 줄이는 마찰 제거

1. 프로젝트 시작과 배포

   1. 적은 파일 수: 프로젝트에 필요한 파일 수를 줄여 구조를 단순하게 했다.
   2. 빌드 경험: 빌드 툴링과 핫 리로딩, 에셋 최적화를 제공해 여러 플랫폼으로 쉽게 출시하도록 했다.

2. Rust가 주는 구조적 단순성

   1. 플랫폼별 코드 최소화: Dioxus 앱은 Rust로 작성되므로 플랫폼 특화 코드로 내려가야 하는 일이 드물다.
   2. 프로젝트 간 일관성: Rust 프로젝트의 구조가 서로 비슷해 새 프로젝트에 진입하기 쉽다.
   3. 초기 설정 생략: 성가신 빌드 시스템 설정을 건너뛰고 main.rs 파일 하나로 시작할 수 있다.

2.3. Blitz: 브라우저 수준 렌더링을 가볍게 만들기

1. 렌더링 엔진의 구성

   1. CSS 표준 활용: Firefox에서 브라우저급 CSS 엔진을 추출했다.
   2. 자체 DOM: HTML 문서 객체 모델(DOM)을 직접 만들었다.
   3. GPU 파이프라인: 하이브리드 GPU 렌더링 파이프라인을 개발해 가벼우면서 기능이 충분한 HTML·CSS 렌더러를 구성했다.

2. Electron 대비 효율

   1. 번들 크기: Electron 앱처럼 RAM과 저장 공간을 많이 먹는 대신 Blitz 앱의 번들 크기는 5MB 미만이다.
   2. 런타임 메모리: 실행 중 RAM 사용량도 50MB 미만이다.

3. 커스터마이즈 가능성

   1. 사용자 컴포넌트: 개발자가 직접 커스텀 컴포넌트를 작성할 수 있다.
   2. 그래픽 실험: 회전하는 큐브 같은 요소를 만들고 브라우저 동작 자체를 원하는 방식으로 바꿀 수 있다.

2.4. Subsecond: 네이티브 코드의 핫 리로드

1. 지원 범위

   1. 언어: Subsecond는 Rust뿐 아니라 C와 C++를 위한 범용 핫 리로드 엔진이다.
   2. 플랫폼: 주요 운영체제에서 작동하고, 웹에서는 WebAssembly로 컴파일해 동작한다.

2. 실행 방식

   1. 변경 감지: 코드를 감시하다가 수정된 부분을 찾아낸다.
   2. 부분 재컴파일: 바뀐 코드 조각만 재컴파일한다.
   3. 프로세스 유지: 실행 중인 앱에 변경분을 제자리에서 패치하고 약 100밀리초 안에 반영한다.

3. 기술적 의미

   1. 난도: 네이티브 컴파일 코드에서 여러 언어와 런타임을 함께 지원하는 일은 매우 어려운 기술 문제였다.
   2. 희소성: 당시 기준으로 이처럼 넓은 언어·런타임 범위를 지원하는 네이티브 코드용 핫 리로드 엔진은 유일하다고 평가했다.

3. 수작업 스택에 코딩 에이전트를 도입한 전환

Dioxus의 핵심 기반은 최근까지 모든 코드를 직접 작성하고 두 눈으로 검토해 쌓아 올렸지만, Rust에 강해진 코딩 에이전트가 팀의 개발 방식과 기대치를 바꿨다.

3.1. AI를 믿지 않던 Rust 엔지니어들의 전환

1. 전환 전의 기준

   1. 수작업 원칙: 지난 5년 동안 Dioxus의 거의 모든 코드는 고통스러울 정도로 꼼꼼하게 사람이 손으로 작성했다.
   2. 품질과 속도의 충돌: 팀은 고품질 코드를 출시하는 일과 당시의 AI 도구를 함께 쓰는 일이 양립하기 어렵다고 생각했다.

2. 최근 6개월의 변화

   1. 에이전트의 발전: 소프트웨어 엔지니어링은 최근 6개월 동안 큰 전환을 겪었고, AI 코딩 에이전트의 성능이 급격히 좋아졌다.
   2. Rust 특화 개선: 특히 Rust 코드를 잘 작성하게 된 점이 Dioxus 팀에 큰 놀라움이었다.
   3. 태도의 변화: “AGI를 체감하지 못했다”고 말할 만큼 회의적이던 팀이 처음으로 에이전트를 진지하게 활용할 기대를 갖게 됐다.

3.2. 첫 시도의 실패: 속도는 얻었지만 품질을 잃다

1. 과감한 투입

   1. 도구 사용량: 팀은 사용 가능한 클라우드 기반 코딩 도구 구독을 최대한 늘렸다.
   2. 산출량: Rust 코드 수만 줄을 생성하고, 오랫동안 원했던 기능·버그 수정·통합 기능을 한꺼번에 만들었다.

2. 품질 게이트에서의 탈락

   1. 병합 기준: 생성된 코드 중 실제로 “이것을 병합해도 되는가?”라는 품질 기준을 통과한 비율은 매우 낮았다.
   2. 미완성의 축적: 수천 줄의 기능과 수정 사항이 오랫동안 초안 상태로 남았고, 지금도 일부는 초안으로 남아 있다.
   3. 운용 미숙: 팀은 도구를 올바르게 다루는 방법을 아직 몰랐으며, 너무 쉽게 ‘슬롭 캐넌(slop cannon)’, 즉 저품질 코드를 쏟아내는 기계가 될 수 있었다.

3.3. Rust의 학습 곡선이 에이전트 시대에는 장점이 되다

1. 반성의 기준

   1. 좋은 개발 경험: 팀은 읽기 쉬운 코드, 쓰기 쉬운 코드, 좋은 도구, 좋은 오류 메시지가 무엇을 실제로 잘 작동하게 만드는지 검토했다.
   2. 에이전트의 무관심: 코딩 에이전트는 이런 인간 중심의 개발 경험 자체를 중요하게 여기지 않는 경향이 있다.

2. Rust의 부담을 에이전트에 위임

   1. 엣지 케이스: 에이전트가 Rust 구현의 경계 조건을 처리한다.
   2. borrow checker: Rust의 borrow checker와 씨름하는 일을 에이전트가 맡아 개발자의 인지 부담을 낮춘다.
   3. 학습 곡선의 역전: 사람이 줄이려고 애썼던 Rust의 학습 곡선이 에이전트 시대에는 오히려 프레임워크의 기능이 된다.

4. ‘야심찬 소프트웨어’의 품질 정의

모든 소프트웨어가 같은 품질 기준을 요구하지는 않지만, Dioxus처럼 다른 사람이 코드와 API 위에 사업을 세우는 프로젝트는 유지보수성과 출시 안정성을 속도와 동급으로 다뤄야 한다.

4.1. 소프트웨어 유형에 따른 기준 차이

1. 연구 코드

   1. 핵심 기준: 연구 단계에서는 코드 품질보다 가설을 확인하고 결과를 얻는 일이 더 중요할 수 있다.
   2. 허용되는 선택: 재사용성과 장기 유지보수보다 실험 속도를 우선해도 목적에 맞을 수 있다.

2. 프로토타입 코드

   1. 핵심 기준: 빠르게 반복하고 방향을 바꾸는 능력이 중요하다.
   2. 품질의 의미: 장기적인 구조보다 빠른 학습과 검증을 위해 구현을 단순화할 수 있다.

3. 외부 제품과 내부 코드

   1. 관찰 대상: 사용자가 내부 코드를 보지 않는 애플리케이션은 우선 겉으로 드러나는 동작과 경험으로 평가받는다.
   2. Dioxus의 차이: Dioxus 사용자는 코드·API·문서·아키텍처를 직접 다운로드하고 읽고 그 위에 제품을 만든다.

4.2. 유지보수 가능한 기반이 모든 속도의 전제다

1. 첫 번째 품질 조건: 항상 작동하는 코드

   1. 정상 상태: 코드가 항상 작동해야 한다.
   2. 복구 가능성: 문제가 생겨도 쉽게 고칠 수 있어야 한다.
   3. 기반 구조: 출시 속도는 그 위에 쌓인 기반 구조에 의존하므로, 기반이 나쁘면 위에 만드는 어떤 기능도 좋은 결과를 내기 어렵다.

2. 속도에 대한 재정의

   1. 단기 속도: 당장 많은 코드를 생성하는 속도만 높이면 유지보수 비용이 뒤늦게 폭발한다.
   2. 지속 가능한 속도: 쉽게 읽고 고치고 검증할 수 있는 기반이 있어야 이후의 기능 출시 속도도 계속 유지된다.

4.3. 긴 로드맵과 릴리스 품질의 긴장

1. 기능 출시 압력

   1. 긴 미래: Dioxus의 로드맵은 매우 길고 먼 미래까지 이어진다.
   2. 남은 일: 아직 만들지 않은 기능이 수십 가지이며, 시대 변화에 뒤처지지 않도록 빠르게 출시하고 싶다.

2. 깨뜨리지 않을 의무

   1. 패치 릴리스: 빠르게 새 기능을 넣더라도 기존 동작을 깨뜨리면 안 된다.
   2. API 안정성: 수백만 명이 의존하는 API를 패치 릴리스에서 깨뜨리는 일은 피해야 한다.

3. 사업 기반 프로젝트의 출시 기준

   1. 문서와 예제: 문서와 예제가 높은 품질을 유지해야 한다.
   2. 테스트와 벤치마크: 테스트와 벤치마크도 릴리스마다 일관되게 관리해야 한다.
   3. 즉각적인 발견: 어느 하나라도 어긋나면 사용자가 매우 빠르게 알아차린다.

5. 코딩 에이전트가 특히 강했던 영역

코딩 에이전트는 전체 설계를 대신하기보다 개인이 감당하기 어려운 기술 지식의 폭, 반복적인 검증, 표준 문서 탐색을 담당하는 인내심 많은 조수로서 가장 높은 가치를 보였다.

5.1. 대규모 지식 문제를 탐색하는 인내심

1. 사람이 모두 알 수 없는 범위

   1. 환경의 다양성: 작은 팀이 모든 빌드 시스템, 런타임, 운영체제, 프로그래밍 언어를 세부적으로 알기는 불가능하다.
   2. 세부 지식: 각 API와 플랫폼의 특이점, 예외 동작, 문서화되지 않은 동작까지 모두 기억할 수 없다.

2. 에이전트의 조사 방식

   1. 문서 처리: 수천 페이지의 기술 문서를 빠르게 훑는다.
   2. 특수 API: 프로젝트마다 다른 bespoke API를 읽고 사용법을 찾아낸다.
   3. 저수준 분석: 바이너리를 파고들고 API를 역공학한다.
   4. 인내심: 개인 개발자가 중간에 포기하기 쉬운 반복 검색과 대조 작업을 오래 수행한다.

5.2. Kotlin·Swift 플러그인 통합을 빠르게 구현하다

1. 어려운 기능의 성격

   1. 깊은 빌드 통합: Dioxus의 빌드 시스템에 Kotlin과 Swift 플러그인을 깊게 통합하는 작업은 단순한 언어 바인딩보다 훨씬 어려웠다.
   2. 비교 사례: React Native의 Turbo Modules와 비슷한 범주의 기능이며, 사람이 손으로 올바르게 만드는 데는 여러 해의 개발이 필요했던 영역이다.

2. 에이전트 활용 결과

   1. 구현 시간: 코딩 에이전트를 사용해 약 2~3주 만에 출시할 수 있었다.
   2. 첫날의 구현: 핵심 구현 자체는 첫날에 끝난 것으로 추정했다.
   3. 검증 중심의 후속 작업: 남은 2주는 테스트 케이스를 만들고 실제 기기에서 검증하는 데 사용했다.
   4. 추가 여지: 팀은 이보다 더 빨리 진행할 수도 있었다고 평가했다.

5.3. Blitz의 CSS·레이아웃 디버깅

1. 에이전트가 제공한 전문 지식

   1. 표준 기억: 에이전트는 CSS 사양을 매우 잘 알고 있다.
   2. 브라우저 동작 비교: 페인팅이나 레이아웃 문제를 해결할 때 Chrome과 Safari가 같은 상황을 어떻게 처리하는지 즉시 떠올린다.

2. 디버깅 비용 감소

   1. 문제별 해법: 특정 한 줄의 CSS나 렌더링 코드를 어떻게 고칠지 실질적인 처리 방법을 제시한다.
   2. 소스 탐색 생략: Apple Git 저장소 깊숙이 묻힌 WebKit 소스 코드를 직접 찾아 헤매지 않아도 된다.

3. 해킹에서 정석으로의 이동

   1. 과거의 선택: 사람은 프로젝트가 복잡할수록 빠른 출시를 위해 품질 기준을 낮추고 지름길을 택하기 쉬웠다.
   2. 새로운 선택: 에이전트가 조사와 구현의 부담을 덜어주면서 해킹이 아닌 정석적인 해결책에 시간을 투자할 수 있게 됐다.

5.4. 작지만 중요한 릴리스·유지보수 자동화

1. 작은 팀의 기회비용

   1. 인력 규모: Dioxus의 핵심 엔지니어는 3명뿐이다.
   2. 아키텍처 시간 보호: tarball이 올바른 디렉터리 구조로 풀리는지 확인하는 단순 작업에 쓰는 시간은 아키텍처와 어려운 문제를 생각할 시간에서 빠져나간다.

2. 릴리스에서 생기는 사소한 회귀

   1. 편집기 확장: 한 릴리스에서 Zed 같은 새 에디터용 확장을 추가할 수 있다.
   2. 검증 공백: 모든 패치 릴리스마다 해당 에디터를 실제로 시험하지 못하면 기능이 쉽게 깨질 수 있다.
   3. 자동화의 역할: 에이전트가 이런 고되지만 반복적인 검증을 자동화해 과거라면 셀 수 없이 많은 시간이 걸렸을 일을 줄인다.

3. 코드가 곧 제품인 프로젝트의 체크리스트

   1. 릴리스 안전성: 릴리스 체크리스트가 빠짐없이 실행됐는지 확인한다.
   2. 안정 브랜치 관리: 버그 수정을 안정 릴리스로 백포트한다.
   3. 문서 정합성: 문서와 기타 설명 자료의 품질을 유지한다.
   4. 실제 효과: 최근 Dioxus 버전은 과거 어느 버전보다 많은 패치 릴리스를 냈고, 대규모 프로젝트에서 매주 또는 주 여러 차례 출시하는 속도를 유지할 수 있게 됐다.

5.5. 문서와 주석의 지속적인 정합성

1. 에이전트에 맡길 수 있는 문서 작업

   1. 완전성: 모든 공개 API와 기능이 제대로 문서화됐는지 확인한다.
   2. 예제: 각 기능에 실제로 쓸 수 있는 예제가 있는지 확인한다.
   3. 정확성: 문서가 설명한다고 말하는 대상을 실제로 그 방식대로 설명하는지 검증한다.

2. 사람만 편집할 때의 문제

   1. 주석 누락: 개발자는 코드를 수정하고도 관련 주석을 수정하지 않는 일이 흔하다.
   2. 시간에 따른 혼란: 오래된 주석이 코드와 어긋나면 사용자는 무엇이 맞는지 판단하기 어려워진다.
   3. 역할 분담: 팀은 중요한 문서 주석을 직접 작성하되, 전체 문서의 누락·예제·정합성 검사는 에이전트에 맡길 수 있다.

6. 아직 사람이 책임져야 하는 영역

테스트의 의미를 정의하고 시스템의 구조를 선택하며 변경 의도를 전달하는 일은 코드 생성보다 어렵고, 코딩 에이전트가 빠르다는 사실만으로 해결되지 않는다.

6.1. AI가 만든 테스트를 맹목적으로 믿을 수 없는 이유

1. 기초 소프트웨어의 테스트 난도

   1. 복잡한 시스템: 파운데이션 소프트웨어는 전체 흐름을 끝까지 검증하는 엔드투엔드 테스트가 특히 어렵다.
   2. 현실적인 통합 검증: Zed에 확장을 설치하고 실제로 에디터를 열어 확장을 사용하는지까지 확인해야 원하는 동작을 검증할 수 있다.

2. 에이전트 테스트의 한계

   1. 얕은 테스트: 생성자(constructor)를 구현해 달라고 하면 생성자 호출만 테스트하는 식의 흥미롭지 않은 테스트를 만들기 쉽다.
   2. API와 의도의 차이: 개별 API의 테스트 코드는 쉽게 쓰지만, 실제로 중요한 테스트를 고르는 일은 사람과 마찬가지로 실패한다.
   3. 품질 편차: AI로 테스트를 작성하거나 테스트를 무작정 생성하는 방식은 아직 성공 수준이 일정하지 않다.

3. 사람이 계속 해야 하는 일

   1. 조건 열거: 어떤 조건을 반드시 테스트해야 하는지 사람이 직접 목록화한다.
   2. 테스트 API와 러너: 프로젝트에 맞는 테스트 API를 만들고 테스트 러너를 운영한다.
   3. 판단 보조: 에이전트는 테스트 아이디어와 엣지 조건을 함께 떠올리는 훌륭한 sounding board가 될 수 있지만, 최종 커버리지 의도는 사람이 정한다.

6.2. 테스트 하네스와 퍼징은 높은 수익을 준다

1. 에이전트가 잘 만드는 테스트 기반

   1. 하네스 구축: Dioxus 팀은 코딩 에이전트에게 테스트 하네스를 만드는 일을 맡겼을 때 큰 만족을 얻었다.
   2. 반복 실행 구조: 개별 테스트의 정답을 고르는 일보다 다양한 입력을 넣고 결과를 관찰하는 실행 기반을 구성하는 일에서 에이전트가 강했다.

2. 퍼징의 목적

   1. 대량 입력: 운영 환경에 견디는 소프트웨어를 만들려면 애플리케이션에 수백만 가지 입력을 넣어야 한다.
   2. 적대적 입력: 잘못된 형식의 입력이나 사용자가 사용하지 말아야 할 방식처럼 공격적인 입력도 포함해야 한다.
   3. 현실의 공격면: 사용자가 그렇게 사용해서는 안 된다고 문서에 적혀 있어도 실제로는 그렇게 사용할 수 있으므로 이를 검증해야 한다.

3. 실행 시사점

   1. 역할 분리: 사람이 테스트할 의미와 실패 조건을 정의하고 에이전트가 퍼징 하네스와 반복 입력 생성을 구현하게 한다.
   2. 운영 품질: 단순한 정상 경로 테스트보다 퍼징 하네스가 실제 운영에서 발생할 malformed input과 예상 밖 사용을 더 잘 드러낼 수 있다.

6.3. 아키텍처는 여전히 예술이다

1. 나쁜 기반은 빠르게 증폭된다

   1. 기반 의존성: 에이전트의 코드가 내려앉는 기반 구조가 나쁘면 에이전트의 기여도 나빠진다.
   2. 속도의 역효과: 에이전트는 나쁜 아키텍처 위에도 매우 높은 속도로 코드를 추가해 문제를 더 빨리 키울 수 있다.

2. 인간과 다른 에이전트의 행동

   1. 리팩터링 회피의 부재: 인간 엔지니어가 부담스러워하는 대규모 리팩터링이나 아키텍처 재설계를 에이전트는 대체로 두려워하지 않는다.
   2. 부적합한 기능: 새 기능이 기존 구조에 잘 맞지 않아도 에이전트는 구조를 다시 설계하기보다 일단 기능을 끼워 넣고 출시하는 경향이 있다.
   3. 스파게티 코드: 인간도 스파게티 코드를 만들 수 있지만, 에이전트는 그것을 훨씬 빠르게 만들 수 있다.

3. 개발 시간의 이동

   1. 이전의 병목: 사람이 직접 코드를 쓰는 시간이 구현 속도를 제한했다.
   2. 현재의 병목: 고성능 도구로 코드 품질이 높아질수록 대부분의 시간은 미래 기능과 시스템 진화를 고려하는 소프트웨어 아키텍처에 쓰인다.
   3. 앞으로의 비중: 의도를 정확히 전달한다는 조건 아래 실제 코드 작성은 시간을 거의 차지하지 않고, 적절한 아키텍처 설계가 대부분의 시간을 차지하게 될 가능성이 높다.

6.4. PR 리뷰와 프롬프트가 품질을 결정한다

1. Dioxus의 리뷰 방식

   1. 라인 단위 검토: 팀은 모든 PR을 한 줄씩 검토한다.
   2. AI 보조: AI 리뷰로 버그를 미리 찾지만, 출시하는 코드는 사람이 직접 읽는다.
   3. 오픈 소스 현실: 대규모 오픈 소스 프로젝트에는 낯선 사람이 보내는 PR이 많고, 모든 PR의 품질과 의도가 같지 않다.

2. 기여자가 전달하지 못하는 것

   1. 의도 표현: 사용자는 모델에 자신이 원하는 변경의 의도를 충분히 설명하지 못하는 경우가 많다.
   2. 시간축의 부재: 기여자는 코드베이스가 앞으로 어떻게 진화해야 하는지 깊이 생각하기보다 자신의 버그 수정이나 기능이 들어가기를 원한다.
   3. 임시 접착: 이런 제안은 많은 경우 전체 구조와 맞지 않는 해결책을 임시로 붙이는 형태가 된다.

3. 텍스트와 프롬프트의 한계

   1. 마음 읽기 불가: 에이전트는 아직 유지 관리자의 머릿속 설계 의도를 읽을 수 없다.
   2. 전달 매체: 결국 모델이 받는 정보는 텍스트라는 제한된 매체를 통과한다.
   3. 프롬프트 엔지니어링: 우스꽝스럽게 들리더라도 프롬프트 엔지니어링은 실제 문제이며, 구현 품질은 모델에 제공한 프롬프트에 크게 좌우된다.

4. 코드 읽기의 우선순위

   1. 불변의 원칙: 코드를 읽는 일은 코드를 쓰는 일보다 중요하다는 원칙은 바뀌지 않았다.
   2. 프로젝트의 시간축: 프로젝트 초기에는 작성 속도가 더 중요해 보일 수 있지만, 시스템이 성장하면 읽기와 이해가 품질을 좌우한다.

7. 결론과 실행 시사점

코딩 에이전트는 엔지니어링을 없애지 않고, 엔지니어가 시간을 써야 할 위치를 구현에서 판단·설계·검증으로 옮긴다.

7.1. 핵심 결론

1. 코드는 저렴해졌지만 품질은 그대로 비싸다

   1. 생성 비용 하락: 많은 양의 코드와 기능을 짧은 시간에 만들 수 있게 됐다.
   2. 품질 비용 유지: 유지보수성, 안전한 릴리스, 정확한 문서, 의미 있는 테스트를 확보하는 비용은 줄지 않았다.

2. 소프트웨어 엔지니어의 본질

   1. 우아한 해법: 복잡한 문제에 대한 우아한 해결책을 설계한다.
   2. 미래 예측: 시스템이 어떻게 진화할지 열 단계 앞서 생각한다.
   3. 유연성 보존: 변화하는 요구사항 앞에서도 구조가 무너지지 않도록 유연성을 남긴다.
   4. 높아진 기준: 이 역할은 바뀌지 않았고, 코드를 빠르게 만들 수 있게 된 만큼 소프트웨어 엔지니어링의 기준은 오히려 그 어느 때보다 높아졌다.

7.2. 실무 적용 순서

1. 기반부터 설계한다

   1. 에이전트를 호출하기 전에 장기적으로 유지할 모듈 경계, 공개 API, 변경 방향을 결정한다.
   2. 새 기능이 기존 구조에 맞지 않으면 임시 코드를 붙이기보다 아키텍처를 먼저 재검토한다.

2. 에이전트를 지식 조수로 쓴다

   1. 여러 운영체제·런타임·언어의 문서, API, CSS 사양, 바이너리 동작을 조사하게 한다.
   2. 사람이 접근하기 어려운 WebKit 소스나 bespoke API를 빠르게 대조하게 하되, 결론은 실제 환경에서 검증한다.

3. 생성보다 품질 자동화에 투자한다

   1. 릴리스 체크리스트, 안정 브랜치 백포트, tarball 구조, 문서·예제 정합성 검사를 자동화한다.
   2. 에이전트가 테스트 하네스와 퍼징을 만들게 하고, 무엇을 검증할지는 사람이 직접 정의한다.

4. 사람이 최종 책임을 진다

   1. 모든 PR의 의도와 아키텍처 적합성을 줄 단위로 읽는다.
   2. 프롬프트에 현재 요구뿐 아니라 미래 진화 방향과 품질 기준을 구체적으로 적는다.
   3. 생성된 코드보다 유지보수 가능한 결과를 병합 기준으로 삼는다.

7.3. 다음 세대 도구를 만드는 팀의 방향

1. Dioxus와 Cognition

   1. Dioxus 팀은 차세대 소프트웨어 도구의 미래에 참여하기 위해 Cognition에 합류했다.
   2. Dioxus를 인수한 Cognition은 이 영역에서 일할 사람을 채용하고 있다.

2. 궁극적인 메시지

   1. 야심찬 소프트웨어는 단순히 더 많은 코드를 생산하는 프로젝트가 아니다.
   2. 빠른 구현 능력을 장기 설계, 의미 있는 테스트, 지속적인 코드 읽기와 결합할 때만 높은 속도가 실제 제품 품질로 전환된다.

주요 발언 모음

“코드는 이제 저렴하지만, 품질은 그렇지 않습니다.”

“코딩 에이전트가 코드를 작성하는 기반 구조가 좋지 않다면, 에이전트의 기여도 좋지 않을 것입니다.”

“우리가 줄이려고 애썼던 학습 곡선이 이제는 기능이 됐습니다.”

“코드를 읽는 일은 코드를 쓰는 일보다 언제나 더 중요했습니다.”

“소프트웨어 엔지니어의 일은 화면에 코드 줄을 올리는 것이 아니라 복잡한 문제에 우아한 해법을 설계하고, 시스템이 어떻게 진화할지 열 단계 앞서 생각하며, 변화하는 요구사항 속에서도 유연성을 유지하는 것입니다.”

핵심 데이터 & 수치

• 시작 시점: 2021년, Kelley의 학부 마지막 여름에 첫 커밋을 했다.
• 개발 기간: 2021년 시작 후 2026년까지 약 5년 동안 기반 기술을 확장했다.
• GitHub: Dioxus 프로젝트는 거의 37,000개의 스타를 기록했다.
• 사용 규모: 다운로드는 수백만 회이며, Dioxus 앱의 누적 최종 사용자는 2억 명 이상으로 추정된다.
• Blitz 번들: Electron 대비 Blitz 앱의 번들 크기는 5MB 미만이다.
• Blitz 메모리: Blitz 앱의 런타임 RAM 사용량은 50MB 미만이다.
• Subsecond 반영 속도: 변경된 네이티브 코드 조각을 약 100밀리초 안에 실행 중인 앱에 패치한다.
• 핵심 팀 규모: Dioxus를 담당하는 핵심 엔지니어는 3명이다.
• Kotlin·Swift 플러그인: 코딩 에이전트로 핵심 구현은 첫날, 테스트·실기기 검증까지 약 2~3주에 완료했다.
• 퍼징 범위: 운영 품질 검증을 위해 수백만 가지 정상·오작동·적대적 입력을 사용한다.

핵심 요약 (20줄)

Dioxus는 Rust의 네이티브 성능과 HTML·CSS의 친숙함을 결합하려는 2021년의 실험에서 출발했다. React Native와 Flutter의 당시 한계를 넘기 위해 Dioxus 팀은 반응성부터 번들링까지 핵심 기반을 직접 만들었다. 2026년 Dioxus는 웹·iOS·Android가 컴포넌트를 공유하는 풀스택 크로스 플랫폼 앱 개발 스택으로 성장했다. Dioxus는 거의 37,000개의 GitHub 스타와 수백만 다운로드, 2억 명 이상의 누적 최종 사용자를 확보했다. Dioxus 앱은 AI 어시스턴트, 투표 소프트웨어, 데이터 과학 도구, 위성 충돌 회피 시스템에 활용됐다. Blitz는 Firefox의 CSS 엔진과 자체 HTML DOM, 하이브리드 GPU 파이프라인으로 가벼운 렌더링을 제공한다. Blitz 앱은 5MB 미만 번들과 50MB 미만 런타임 RAM으로 Electron의 무거움을 피한다. Subsecond는 Rust·C·C++ 네이티브 코드를 약 100밀리초 안에 실행 중인 앱에 핫 리로드한다. Rust에 강해진 코딩 에이전트는 AI에 회의적이던 Dioxus 팀의 개발 방식을 바꿨다. 에이전트로 수만 줄을 생성한 첫 시도는 품질 기준을 통과하지 못한 코드와 초안만 쌓는 슬롭 캐넌이 됐다. Rust의 borrow checker와 엣지 케이스는 에이전트가 개발자의 인지 부담을 줄여주는 영역이다. Dioxus의 긴 로드맵은 빠른 기능 출시와 API·문서·테스트의 안정성을 동시에 요구한다. 에이전트는 수천 페이지의 문서와 특수 API, 바이너리를 탐색하는 지식 문제에 특히 강하다. Kotlin·Swift 플러그인 통합은 핵심 구현 첫날과 약 2~3주의 테스트로 출시할 수 있었다. Blitz의 CSS·레이아웃 디버깅은 에이전트가 브라우저 사양과 Chrome·Safari 동작을 잘 아는 덕분에 빨라졌다. 릴리스 체크리스트, 백포트, tarball 검증, 문서 정합성 같은 반복 업무는 에이전트 자동화의 높은 수익 영역이다. 에이전트가 생성한 테스트는 얕아지기 쉬워 테스트 조건과 중요한 실패 의미를 사람이 정의해야 한다. 퍼징 하네스처럼 수백만 개의 적대적 입력을 실행하는 기반 구축은 에이전트 활용에 적합하다. 아키텍처가 나쁘면 에이전트가 스파게티 코드를 더 빠르게 만들 뿐이므로 구조 설계는 여전히 사람의 책임이다. 코드가 저렴해진 시대에도 품질, 미래를 내다보는 아키텍처, 코드 읽기와 프롬프트 설계의 가치는 더 높아졌다.