AI 시대의 대담한 소프트웨어 개발법

URL: https://www.youtube.com/watch?v=T2bWgEhLl6M
날짜: 2026-09-14
채널: Tech Bridge
영상 ID: T2bWgEhLl6M
원문 제목(title_original): [한영자막] AI 시대, 대담한 소프트웨어를 개발하는 법 — Jonathan Kelley (Dioxus Labs & Cognition)
발표자: Jonathan Kelley
소속: Dioxus Labs, Cognition
주제: AI 코딩 에이전트 시대의 대담한 소프트웨어 개발과 품질 관리

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 코딩 에이전트는 코드 생산 비용을 극적으로 낮추지만, 좋은 아키텍처·의도 전달·검증으로 확보하는 품질의 가치는 낮추지 않는다.== 대규모 오픈 소스 프로젝트를 지속 가능하게 만드는 일은 코드를 많이 생성하는 일이 아니라, 올바른 기반 위에서 미래의 변화까지 고려하고 모든 결과를 읽고 테스트하는 일이다.

• Dioxus는 2021년 Rust, HTML, CSS로 크로스 플랫폼 앱 프레임워크를 처음부터 구축했고, 반응성·폰트 렌더링·핫 리로드·번들링까지 직접 해결했다.
• 2026년에는 Blitz 렌더링 엔진, Subsecond 핫 리로드, 네이티브 렌더링과 번들 분할을 갖춘 전체 앱 개발 스택으로 성장했으며, 37,000개에 가까운 GitHub 스타와 2억 명이 넘는 누적 최종 사용자를 확보했다.
• AI 에이전트는 Rust의 보일러플레이트·엣지 케이스·borrow checker 부담, 문서와 API 탐색, 반복적인 릴리스 검증을 크게 줄였지만, 무엇을 만들어야 하는지와 시스템이 어떻게 진화해야 하는지는 여전히 사람이 결정해야 한다.

Dioxus의 사례는 에이전트 코딩의 핵심 단위를 ‘코드 작성’에서 ‘의도와 아키텍처를 설계하고 결과를 검증하는 일’로 이동시킨다. 세 명의 핵심 엔지니어가 수백만 명이 의존하는 SDK를 관리하는 상황에서, 속도는 유지보수 가능한 코드라는 기반 위에서만 의미가 있으며, 코드가 상품인 프로젝트일수록 문서·예제·테스트·벤치마크와 패치 릴리스의 품질이 곧 사용자 경험이 된다.

1. Dioxus가 선택한 대담한 출발점

Dioxus는 당시에 익숙한 진로보다 장기적으로 큰 문제를 직접 해결하는 길을 택하면서 시작됐다.

1.1. 학부 마지막 여름과 Rust 선택

1. 안전한 선택 대신 직접 만들기

   1. 첫 커밋: Jonathan Kelley는 5년 전 Dioxus 프로젝트에 처음 커밋했다. 학부생으로 보낼 수 있었던 마지막 여름을 Google 인턴십이나 AI 연구에 쓰는 대신 새로운 앱 프레임워크 아이디어를 탐구했다.
   2. Rust 기반: Rust 프로그래밍 언어로 크로스 플랫폼 앱 프레임워크를 만드는 것이 출발점이었다. 그는 이 선택을 스스로 “아주 덕후스럽다(extremely nerdy)”고 농담처럼 평가했다.

2. Rust의 당시 매력

   1. 성장 중인 생태계: 2021년 Rust는 여전히 틈새시장 언어였지만 생태계와 툴링(tooling)이 빠르게 개선되고 있었다.
   2. 기술적 설득력: 네이티브 성능(native performance), 견고한 타입 시스템(solid type system), 단순한 크로스 컴파일(simple cross compilation)이 Rust를 선택하게 만든 핵심 조합이었다.

1.2. 하나의 언어와 웹 문법으로 통합하기

1. 크로스 플랫폼 개발의 단순화

   1. 통합된 코드베이스: 플랫폼마다 수십 가지 툴체인(toolchain), 프로그래밍 언어, 설계 아이디어를 오가며 앱을 만드는 대신 모든 앱을 Rust로 작성한다는 발상이었다.
   2. 익숙한 UI 문법: HTML과 CSS를 마크업 언어로 사용해 웹 개발자에게 익숙한 방식으로 UI를 작성한다. React에서 반응성(reactivity)의 아이디어를 가져오면 웹 컴포넌트와 웹 툴링을 대량으로 재사용할 수 있다.

2. 기존 선택지의 빈틈 공략

   1. React Native의 불안정성: 2021년 React Native는 “janky”, 즉 매끄럽지 못하고 버벅거리는 경험이 있었다.
   2. Flutter와 네이티브 API: Flutter는 너무 느렸고 React Native와 Flutter 모두 네이티브 API와의 상호작용이 충분히 잘 작동하지 않았다. Rust를 사용하면 VM, IPC, JavaScript 없이 네이티브 코드를 추상화해 구축할 수 있다는 점이 차별점이었다.

3. 목표 사용자와 목표 수준

   1. 강력함: 평균적인 개발자에게 익숙한 HTML·CSS·React식 반응성을 제공하면서도 매우 강력한 앱 프레임워크를 지향했다.
   2. 생태계 재사용: 웹의 방대한 컴포넌트와 개발 도구를 활용하되, 실행 결과는 네이티브 앱의 성능과 플랫폼 통합을 갖추도록 했다.

2. 쉬울 것이라 생각했기에 처음부터 만든 앱 스택

Dioxus의 난이도는 프레임워크를 조립하는 일이 아니라 프레임워크에 필요한 기반 기술 자체를 만들어야 했다는 데 있었다.

2.1. ‘쉬워서가 아니라 쉬울 거라 생각해서’ 시작한 프로젝트

1. 낙관적인 출발

   1. 자기반성적 농담: “앱 프레임워크를 처음부터 만든 이유는 쉬워서가 아니라, 쉬울 거라고 생각했기 때문이다”라는 식으로 초기 낙관을 회고했다.
   2. 경쟁 범위: React Native와 Flutter에 도전하는 것 자체가 매우 야심찬 시도였고, 이미 검증된 부품을 조립하는 일반적인 프로젝트가 아니었다.

2. 기성 부품의 부재

   1. 직접 만들어야 한 기반: 2021년에는 Dioxus를 구축하는 데 쓸 수 있는 오프더셸프(off-the-shelf) 컴포넌트가 거의 없었다. 반응성, 폰트 렌더링(font rendering), 핫 리로딩(hot reloading), 애플리케이션 번들링(application bundling)을 모두 처음부터 구현해야 했다.
   2. 브라우저 구축의 필연성: 웹 브라우저를 만드는 것처럼 보이는 작업도 우회로가 아니라 목표를 달성하기 위해 반드시 거쳐야 할 단계였다.

2.2. 2026년까지 달성한 원래의 약속

1. 전체 기능 스택의 완성

   1. 처음 세운 목표의 구현: 크로스 플랫폼 지원, 네이티브 렌더링(native rendering), Rust 핫 리로드, 번들 분할(bundle splitting)을 모두 지원하게 됐다.
   2. 스택의 재창조: 앱 개발 스택 전체를 사실상 다시 만들고 개선했다. 단순한 UI 라이브러리를 넘어 빌드·렌더링·실행·배포의 경계를 함께 다루는 시스템이 됐다.

2. 모바일과 웹의 코드 공유

   1. 동일 코드베이스: iOS·Android 앱과 같은 코드베이스로 강력한 풀스택 웹 애플리케이션을 배포할 수 있다.
   2. 공유 컴포넌트: 모바일 앱과 웹 앱 사이에서 컴포넌트를 공유해 플랫폼별 재구현을 줄인다.

2.3. 실제 채택과 사용자 범위

1. 프로젝트 규모

   1. GitHub 지표: Dioxus 프로젝트는 GitHub에서 거의 37,000개의 스타를 받았다.
   2. 배포 규모: 수백만 건의 다운로드가 발생했으며, Dioxus로 만든 앱은 전 세계에 배포됐다.

2. 최종 사용자와 활용 사례

   1. 사용자 수: 여러 앱의 누적 최종 사용자 수는 2억 명을 넘는 것으로 추산된다.
   2. 도메인 다양성: AI 어시스턴트, 투표 소프트웨어, 데이터 과학 도구가 만들어졌고, 우주 위성의 충돌 방지 시스템(collision avoidance system) 같은 안전성이 중요한 소프트웨어에도 사용됐다.

3. Dioxus가 만든 사용자 경험과 핵심 기술

Dioxus의 기술적 야심은 개발자가 플랫폼 세부 사항보다 제품과 문제 해결에 집중하도록 만드는 데 있다.

3.1. Rust를 어렵지 않게 쓰는 구조

1. 개발자 친화성

   1. 단순한 구조: 앱은 Rust로 작성되며 프로젝트 구조가 매우 단순하다. 대부분의 경우 플랫폼별 코드를 직접 수정할 필요가 없다.
   2. 낮은 진입 비용: Rust 프로젝트의 구조가 서로 비슷하므로 개발자가 새 프로젝트에 빠르게 들어갈 수 있다.

2. 빌드 설정의 제거

   1. 설정 생략: 번거로운 빌드 시스템 설정을 완전히 건너뛸 수 있도록 했다.
   2. 최소 진입점: Rust의 표준 진입 파일인 main.rs만 있으면 시작할 수 있다.

3.2. Blitz: 작지만 완전한 HTML·CSS 렌더링 엔진

1. 브라우저급 렌더링 기반

   1. CSS 엔진 추출: Firefox에서 브라우저급 CSS 엔진을 추출했다.
   2. 자체 DOM과 GPU 파이프라인: 자체 HTML DOM을 구축하고 하이브리드 GPU 렌더링 파이프라인(hybrid GPU rendering pipeline)을 개발했다.

2. Electron과 다른 자원 사용량

   1. 번들 크기: Electron 앱처럼 RAM과 저장 공간을 많이 차지하는 앱과 비교해 Blitz 앱의 번들 크기는 5MB 미만이다.
   2. 실행 메모리: 실행 중 사용하는 RAM도 50MB 미만이다. 작은 용량과 낮은 메모리 사용량으로 네이티브 앱다운 배포 특성을 유지한다.

3. 확장 가능한 브라우저 경험

   1. 사용자 정의 컴포넌트: 개발자가 자신만의 커스텀 컴포넌트를 작성할 수 있다.
   2. 시각적 실험: 회전하는 큐브 같은 그래픽 요소를 직접 만들 수 있고, 브라우저 동작과 외형을 원하는 방식으로 사용자화할 수 있다.

3.3. Subsecond: 네이티브 코드의 초고속 핫 리로드

1. 동작 방식

   1. 변경 감지와 부분 재컴파일: Subsecond는 코드를 감시하고 수정된 부분만 다시 컴파일한다.
   2. 실행 중 패치: 실행 중인 앱에 변경 부분을 제자리에서 패치해 약 100밀리초 만에 결과를 반영한다.

2. 폭넓은 언어·플랫폼 지원

   1. 네이티브 컴파일 언어: Rust뿐 아니라 C와 C++도 지원하는 범용 핫 리로드 엔진이다.
   2. 운영체제와 웹: 모든 주요 운영체제에서 동작하며, 웹도 WebAssembly로 컴파일된다. 네이티브 컴파일 코드에 이 정도로 넓은 언어·런타임 지원을 제공하는 사례는 없었다고 평가했다.

4. AI 코딩 에이전트가 바꾼 Dioxus 개발

최근 6개월 동안 AI 코딩 에이전트가 Rust에서 특히 강력해지면서, 손으로만 만들던 프로젝트의 개발 방식이 바뀌기 시작했다.

4.1. 회의론에서 실험으로

1. 변화를 체감한 시점

   1. 급격한 전환: 소프트웨어 엔지니어링과 개발은 지난 6개월 동안 큰 전환을 맞았고, AI 코딩 에이전트가 정말로 좋아졌다.
   2. Rust 특화 성능: 특히 Rust 코드를 다루는 능력이 크게 좋아졌다. Rust 전문가로 구성된 팀이 직접 효과를 확인했다는 점이 중요했다.

2. Dioxus 팀의 초기 반응

   1. AGI에 대한 거리감: 팀은 오랫동안 AI에 회의적이었고, 그동안 “AGI를 체감하지 못했다”고 느꼈다.
   2. 일상 업무에서 미사용: 이전에는 일상적인 개발 업무에 AI를 거의 사용하지 않았다. 실제 변화가 나타나자 팀은 뜻밖에 흥분했고 실험을 시작했다.

4.2. 빠른 생성과 ‘slop cannon’의 문제

1. 생산량 폭증

   1. 클라우드 코드 한도 소진: 팀은 클라우드 코드(Cloud Code) 구독 한도를 모두 소진할 정도로 에이전트를 사용했다.
   2. 수만 줄의 Rust: 수만 줄의 Rust 코드를 생성하고, 수년 동안 원했던 기능·버그 수정·통합을 한꺼번에 시도했다.

2. 품질 기준과의 충돌

   1. 머지 기준 미달: 생성된 코드 중 “이것을 머지해도 되는가?”라는 팀의 품질 기준을 통과한 것은 극히 적었다.
   2. 초안으로 남은 작업: 수천 줄의 새 기능과 수정·통합 코드가 오랫동안 draft 상태로 남았다. 도구를 제대로 휘두르는 법을 몰랐고, 생성물을 무비판적으로 쏟아내는 “slop cannon”이 되기 쉬웠다.

4.3. Dioxus의 설계가 에이전트 시대의 장점이 되다

1. 사람을 위한 기반의 재발견

   1. 개발자 친화성: Dioxus 팀은 읽기 쉽고 쓰기 쉬운 코드, 좋은 도구, 좋은 오류 메시지를 만드는 데 수년간 투자했다.
   2. 에이전트의 무관심: 코딩 에이전트는 일반적으로 코드의 개발자 친화성을 스스로 신경 쓰지 않는다. 사람이 만든 좋은 기반이 없으면 에이전트도 읽기 어렵고 유지하기 어려운 결과를 낸다.

2. Rust의 인지적 부담을 에이전트가 흡수

   1. 엣지 케이스 처리: 에이전트는 개발자가 직접 처리해야 하는 예외 상황과 엣지 케이스를 해결한다.
   2. Borrow checker 대응: Rust의 borrow checker와 씨름하는 부담을 대신해 Rust 앱 작성에 필요한 인지적 비용을 줄인다.

3. 학습 곡선의 역전

   1. 기존의 목표: Dioxus는 Rust를 더 쉽게 쓰도록 만들어 학습 곡선을 낮추려고 했다.
   2. 새로운 의미: 에이전트가 Rust의 작성 부담을 처리하면서, 과거에 줄이려 했던 학습 곡선 자체가 오히려 Dioxus의 기능이 됐다. 에이전트가 Rust를 잘 활용할수록 Dioxus의 쉬운 구조와 오류 메시지가 에이전트의 작업 품질에도 영향을 준다.

5. 대담한 소프트웨어 프로젝트의 품질 기준

빠른 반복이 최우선인 연구·프로토타입과, 내부 코드까지 사용자가 의존하는 Dioxus 같은 프로젝트는 에이전트 활용의 기준이 다르다.

5.1. 소프트웨어 유형에 따라 달라지는 ‘좋은 코드’

1. 속도가 품질보다 중요한 경우

   1. 연구 코드: 연구를 진행할 때는 코드 품질이 가장 중요한 요소가 아닐 수 있다.
   2. 프로토타입: 빠르게 코드를 반복하고 검증하는 일이 중요하며, 내부 구현을 사용자가 보지 않는 애플리케이션은 겉으로 보이는 결과가 주된 평가 대상일 수 있다.

2. Dioxus의 기준

   1. 항상 작동하고 고치기 쉬운 코드: 코드가 항상 제대로 작동해야 하며, 문제가 생겨도 쉽게 수정할 수 있어야 한다.
   2. 유지보수성이라는 기반(substrate): 기능 출시 속도는 그 위에 쌓은 기반에 달려 있다. 기반이 나쁘면 그 위에 아무리 많은 기능을 쌓아도 좋은 결과를 얻을 수 없다.

5.2. 빠른 기능 출시와 호환성 보존의 동시 달성

1. 미래 기능을 위한 장기 설계

   1. 아직 남은 일: Dioxus에는 앞으로 만들어야 할 기능이 수십 가지 남아 있다. 현재의 단기 속도만으로는 장기 개발을 감당할 수 없다.
   2. 기반 위의 속도: 새로운 기능을 빠르게 추가하되 기존 기능을 깨뜨리지 않는 구조가 필요하다. 기반이 좋아야 출시 속도가 지속된다.

2. 릴리스 안정성

   1. 패치 릴리스의 API: 수백만 명이 의존하는 API를 패치 릴리스에서 깨뜨려서는 안 된다.
   2. 사업 기반으로서의 프로젝트: Dioxus 위에 사업을 세운 사용자가 있으므로 릴리스의 품질 기준이 높다. 문서, 예제, 테스트, 벤치마크 어느 하나라도 어긋나면 사용자는 빠르게 알아챈다.

6. 코딩 에이전트가 특히 강한 영역

코딩 에이전트의 가장 큰 강점은 단순한 타이핑 속도보다 사람이 한 프로젝트에서 모두 기억하기 어려운 지식과 인내심을 제공하는 데 있다.

6.1. 지식 문제를 푸는 인내심 있는 조력자

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

   1. 기술 스택의 조합: 세 명의 팀이 모든 빌드 시스템, 런타임, 운영체제, 프로그래밍 언어, API의 세부 사항을 동시에 아는 것은 현실적으로 불가능하다.
   2. 숨은 예외: 플랫폼마다 존재하는 특이점(quirk)과 비공개·맞춤형 API까지 기억하는 일은 개인 개발자의 인내심을 넘어선다.

2. 에이전트의 탐색 능력

   1. 문서·API 독해: 수천 페이지의 문서를 빠르게 훑고 맞춤형 API를 읽는다.
   2. 바이너리와 역설계: 바이너리를 파고들고 API를 역설계(reverse engineering)하는 지루한 조사도 수행한다. 일반 개발자보다 긴 시간 동안 세부 사항을 추적할 수 있다.

6.2. Kotlin·Swift 플러그인 통합 사례

1. 어려운 기능의 성격

   1. 빌드 시스템 깊은 통합: Dioxus용 Kotlin과 Swift 플러그인을 빌드 시스템에 깊이 통합했다.
   2. 비교 기준: React Native의 Turbo Modules를 아는 개발자라면 이 기능이 얼마나 어려운지 짐작할 수 있다. 언어와 네이티브 빌드 체계를 동시에 맞춰야 하기 때문이다.

2. 개발 기간의 변화

   1. 기존의 손코딩: 사람이 직접 작성해 제대로 완성하기까지 수년의 개발이 필요했던 종류의 기능이다.
   2. 에이전트 활용 결과: 구현 자체는 첫날에 끝났고, 코딩 에이전트와 함께 약 2~3주 만에 출하할 수 있었다. 나머지 기간은 테스트 케이스를 만들고 실제 기기에서 검증하는 데 사용했다.

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

1. 웹 표준 지식의 활용

   1. CSS 사양: 웹 에이전트는 CSS 사양을 매우 잘 알고 있다.
   2. 브라우저 동작 비교: 페인팅(painting)이나 레이아웃 문제를 고칠 때 Chrome과 Safari가 같은 상황을 어떻게 처리하는지 빠르게 떠올리고 해결 방향을 제시한다.

2. 해킹 대신 정석 구현

   1. 조사 비용 절감: Apple Git 저장소 깊숙한 곳에 있는 WebKit 소스 코드를 직접 찾아 헤매지 않아도 된다.
   2. 품질 기준 상승: 예전에는 사람이 프로젝트 복잡도를 보고 빠른 출시를 위해 지름길을 택하곤 했다. 에이전트는 정석적인 해결책을 조사할 시간을 확보해 주므로 높은 품질을 유지하면서 문제를 해결할 수 있다.

6.4. 작고 반복적인 운영 작업 자동화

1. 세 명의 핵심 엔지니어가 아껴야 할 시간

   1. 사소한 검증의 비용: tarball이 올바른 디렉터리 구조로 압축 해제되는지 확인하는 일에 사람이 시간을 쓰면 아키텍처와 어려운 문제를 생각할 시간이 줄어든다.
   2. 큰 코드베이스의 누적 부담: Dioxus처럼 큰 프로젝트는 모든 릴리스에서 전체 코드베이스의 품질 기준을 유지하는 것 자체가 어렵다.

2. 릴리스별 누락을 자동으로 찾기

   1. Zed 확장 프로그램 사례: 어느 릴리스에서 Zed 같은 새 에디터의 확장 프로그램을 추가해도, 패치 릴리스마다 해당 에디터를 직접 테스트하지 못할 수 있다.
   2. 회귀 방지: 특정 규칙을 깨뜨리는 일은 쉽지만 에이전트를 적용하면 이런 지루하고 어려운 검증을 자동화해 이전에는 수많은 시간이 걸리던 작업을 반복 수행할 수 있다.

6.5. 코드가 제품인 오픈 소스 프로젝트의 관리

1. 개발자 경험과 사업의 연결

   1. 코드 자체가 제품: 사용자는 코드를 다운로드하고 그 위에 구축하며, API와 상호작용하고, 문서를 읽고, 아키텍처를 기반으로 시스템을 만든다.
   2. 품질 저하의 직접 영향: SDK나 코드의 품질을 조금만 소홀히 해도 개발자 경험이 나빠진다. 사용자가 화를 내거나 사업이 멈추거나 제품 사용을 중단하는 결과로 이어질 수 있다.

2. 에이전트가 맡기 좋은 유지보수 작업

   1. 릴리스 체크리스트: 릴리스 전 체크리스트를 빠짐없이 검증한다.
   2. 안정 브랜치와 문서: 버그 수정을 안정적인 릴리스에 백포트(backport)하고, 문서와 관련 자료의 품질을 점검한다.

3. 문서와 코드의 시간차 해소

   1. 사람의 습관: 인간 개발자는 코드를 수정하면서 관련 문서 주석(doc comment)을 함께 고치지 않는 경우가 많다. 시간이 지나면 주석이 실제 코드와 어긋나 혼란을 만든다.
   2. 에이전트의 점검 항목: 모든 항목이 제대로 문서화됐는지, 모든 항목에 예제가 있는지, 문서가 실제 동작을 정확히 설명하는지 확인하도록 에이전트에게 맡길 수 있다.

4. 릴리스 빈도의 변화

   1. 패치 릴리스 증가: 가장 최근 Dioxus 버전에서는 이전 어느 때보다 많은 패치 릴리스를 출시했다.
   2. 지속 가능한 속도: 과거에는 두려워서 일찍 내놓지 못했을 주간 또는 주 2회 이상 릴리스 주기를 대형 프로젝트에서도 유지할 수 있게 됐다.

7. 테스트에서 드러난 에이전트의 한계와 활용법

AI가 테스트 코드를 생성하는 것과 실제로 중요한 위험을 검증하는 것은 다르다. Dioxus 팀은 테스트 작성 자체보다 테스트 설계와 하네스 구축에서 더 큰 가치를 확인했다.

7.1. ‘테스트를 썼다’와 ‘올바른 테스트’의 차이

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

   1. 복잡한 엔드 투 엔드 검증: 기반 소프트웨어는 특히 엔드 투 엔드(end-to-end) 테스트가 어렵다.
   2. Zed 확장 프로그램: 확장 프로그램이 Zed에 제대로 설치되고 의도대로 동작하는지 확인하려면 Zed를 실제로 열고 확장 프로그램을 사용해야 한다. 단순한 API 호출만으로는 충분하지 않다.

2. 생성 테스트의 얕음

   1. 쉬운 API에 집중: 에이전트는 어떤 API에든 테스트를 쉽게 붙일 수 있지만, 생성자를 제공하면 생성자만 테스트하는 식의 흥미롭지 않은 테스트를 만들기 쉽다.
   2. 사람과 같은 실패: 사람이 놓치는 것처럼 에이전트도 “테스트가 존재하는가”가 아니라 “올바른 위험을 검증하는가”를 놓칠 수 있다.

3. 사람이 계속 맡는 설계 작업

   1. 조건 열거: 팀은 여전히 테스트 조건을 직접 열거한다.
   2. 테스트 인프라: 테스트용 API를 직접 만들고 테스트 러너(test runner)를 다루는 일도 사람이 책임진다. 에이전트는 특정 기능의 테스트 아이디어를 내고 커버리지와 엣지 케이스를 점검하는 브레인스토밍 파트너로는 유용하다.

7.2. 테스트 하네스와 퍼징에서의 높은 가치

1. 퍼징(fuzzing)의 목적

   1. 대량 입력 검증: 실제 운영 환경의 소프트웨어는 수백만 가지 입력을 받아야 한다.
   2. 악의적·비정상 입력: 잘못 만들어진 입력, 사용자가 정상적으로는 사용하지 않을 방식, 사용해서는 안 되지만 실제로는 접근 가능한 경로까지 받아내야 한다.

2. 에이전트가 잘 만드는 것

   1. 하네스 구축: 코딩 에이전트는 퍼저(fuzzer)가 애플리케이션을 다양한 입력에 반복 투입할 수 있도록 테스트 하네스를 만드는 데 특히 강하다.
   2. 운영 품질 연결: 테스트 하네스가 견고해지면 수동으로 일일이 상상하기 어려운 예외 입력을 자동으로 탐색할 수 있어 production-grade 소프트웨어에 가까워진다.

8. 아키텍처·의도·코드 리뷰는 여전히 사람의 일

에이전트가 만드는 코드의 양이 늘수록 무엇을 만들지 결정하는 아키텍처와, 그 결과가 의도에 맞는지 읽어내는 검토의 중요성이 커진다.

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

1. 기반이 결과를 결정한다

   1. 나쁜 substrate의 확대: 에이전트가 코드를 놓는 기반이 나쁘면 그 기여 코드도 나빠진다.
   2. 속도의 양면성: 사람 엔지니어가 스파게티 코드를 만들 수 있듯 에이전트도 만들 수 있다. 차이는 에이전트가 그것을 훨씬 빠르게 만들어낸다는 점이다.

2. 기능이 맞지 않을 때의 기본 행동

   1. 리팩터링을 자동 기대하지 않기: 기능이 기존 구조에 잘 맞지 않아도 에이전트가 시스템 전체를 자발적으로 대규모 리팩터링하거나 아키텍처를 재설계할 것이라고 기대하기 어렵다.
   2. 일단 출하하는 경향: 에이전트는 대개 구조를 다시 설계하기보다 기능을 바로 출하하는 쪽으로 움직인다. 사람이 미래의 기능과 시스템 진화를 먼저 설계해야 하는 이유다.

3. 개발 시간의 이동

   1. 아키텍처 중심: Dioxus 팀의 개발 시간 대부분은 소프트웨어 아키텍처, 앞으로 필요한 기능, 시스템의 진화 방식을 고민하는 데 쓰인다.
   2. 코드 작성의 상대적 축소: 의도를 정확히 전달할 수 있고 도구의 품질이 충분히 높다면 실제 코드 작성에는 시간이 많이 들지 않는다. 앞으로는 적절한 아키텍처 설계가 시간의 대부분을 차지할 가능성이 크다.

8.2. PR을 읽는 능력과 프롬프트 엔지니어링

1. Dioxus의 라인 단위 리뷰

   1. 모든 PR 검토: Dioxus 팀은 오픈 소스 프로젝트에 들어오는 모든 PR을 한 줄씩 검토한다.
   2. AI 리뷰의 위치: AI 리뷰로 버그를 미리 찾지만, 최종적으로 배포할 코드는 사람이 직접 읽는다.

2. 의도 전달의 병목

   1. 기여자의 한계: 외부 기여자는 모델에 자신의 의도를 정확히 전달하는 데 서툴 수 있다. 기여자는 대개 코드베이스가 시간이 지나며 어떻게 발전해야 하는지보다 당장의 버그 수정이나 기능 추가를 원한다.
   2. 붙여 넣은 해결책: 그 결과 장기 구조에 맞지 않는 해결책이 기존 코드에 억지로 붙은 채 PR로 들어온다. 코딩 에이전트가 사람의 생각을 읽는 단계에는 아직 도달하지 못했다.

3. 텍스트 매체와 프롬프트의 영향

   1. 프롬프트 엔지니어링의 실재: 우스꽝스럽게 들릴 수 있지만 프롬프트 엔지니어링(prompt engineering)은 실제로 중요하다. 모델에 주는 지시의 품질에 따라 구현 품질이 크게 달라진다.
   2. 코드 읽기의 우선순위: 코드 읽기는 코드 작성보다 언제나 중요했다. 프로젝트가 시작될 때는 작성이 더 중요해 보일 수 있지만, 시스템이 성장할수록 읽고 판단하는 일이 훨씬 중요해진다.

주요 발언 모음

“앱 프레임워크를 처음부터 만들기로 한 것은 쉬워서가 아니라, 쉬울 거라고 생각했기 때문이다.”

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

“나쁜 기반 위에 코딩 에이전트가 코드를 작성하면 결과도 나쁠 것이다.”

“우리는 정석적인 방식으로 일할 시간을 확보할 수 있다. 편법을 쓰는 방식이 아니다.”

“코딩 에이전트는 코드를 매우 빠르게 만들 수 있지만, 사람의 의도를 읽을 수 있는 단계에는 아직 도달하지 못했다.”

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

“소프트웨어 엔지니어의 일은 화면에 코드 줄을 입력하는 일이 아니다.”

“복잡한 문제에 우아한 해법을 설계하고, 시스템이 어떻게 진화할지 열 단계 앞서 생각하며, 요구 사항이 바뀌어도 유연성을 유지하는 일이 소프트웨어 엔지니어링이다.”

핵심 데이터 & 수치

• 2021년: Jonathan Kelley가 Dioxus 프로젝트에 첫 커밋을 했고, Rust는 아직 틈새시장 언어였다.
• 2026년: Dioxus가 원래 목표였던 크로스 플랫폼 지원·네이티브 렌더링·Rust 핫 리로드·번들 분할을 모두 지원한다.
• 약 37,000개: Dioxus의 GitHub 스타 수.
• 수백만 건: Dioxus 프로젝트 다운로드 규모.
• 2억 명 이상: Dioxus로 제작된 앱의 누적 추정 최종 사용자 수.
• 5MB 미만: Blitz 앱의 번들 크기.
• 50MB 미만: Blitz 앱의 실행 중 RAM 사용량.
• 약 100밀리초: Subsecond가 변경된 네이티브 코드를 재컴파일하고 실행 중인 앱에 패치하는 시간.
• Rust·C·C++: Subsecond가 지원하는 네이티브 컴파일 언어.
• 첫날 구현 + 2~3주 출하: Kotlin·Swift 플러그인 통합 사례에서 구현은 첫날 완료됐고 테스트·실기기 검증을 포함해 약 2~3주 만에 출시했다.
• 세 명: Dioxus 개발에 투입된 핵심 엔지니어 수.
• 주간 또는 주 2회 이상: 에이전트 도입 이후 대규모 프로젝트에서 유지할 수 있게 된 릴리스 빈도.
• 수백만 가지 입력: production-grade 소프트웨어의 퍼징에서 다루는 입력 규모.

결론 및 시사점

1. 코드 생성과 품질을 분리하라: AI 에이전트로 코드 생산 비용은 내려가지만 품질·안정성·호환성·유지보수성은 자동으로 따라오지 않는다.
2. 좋은 substrate를 먼저 설계하라: 에이전트가 작업할 기반의 구조와 개발자 경험이 결과물의 상한을 결정한다.
3. 사람의 시간을 아키텍처에 배분하라: 타르볼 검증·릴리스 체크리스트·백포트·문서 일치성처럼 반복 작업은 에이전트에 위임하고, 미래 기능과 시스템 진화를 설계하는 일에 집중한다.
4. Rust의 어려움을 레버리지로 바꾸라: borrow checker와 엣지 케이스를 에이전트가 처리할 수 있으므로, Rust의 안전성과 네이티브 성능을 포기하지 않고 개발 부담을 줄일 수 있다.
5. 테스트의 ‘정답’을 사람이 정의하라: 에이전트가 얕은 단위 테스트를 많이 쓰는 것과 실제 위험을 검증하는 것은 다르다. 테스트 조건·엔드 투 엔드 시나리오·테스트 러너는 사람이 설계하고, 하네스·퍼징처럼 반복적이고 대규모인 실행은 에이전트에 맡긴다.
6. 코드를 반드시 읽어라: AI 리뷰는 버그를 조기에 찾는 보조 수단이고, 최종 코드의 의도·구조·장기 적합성을 판단하는 라인 단위 리뷰를 대체하지 못한다.
7. 프롬프트에 의도를 명시하라: 모델은 개발자의 머릿속 아키텍처를 알 수 없으므로, 원하는 시스템의 진화 방향과 제약을 텍스트로 구체적으로 전달해야 한다.
8. 엔지니어링의 기준을 높여라: 코드가 흔해질수록 우아한 해법, 장기 유연성, 안정적인 릴리스, 좋은 문서와 사용자 경험이 차별화 요소가 된다.
9. Cognition의 다음 단계: Dioxus 팀은 Dioxus를 인수한 Cognition에 합류해 차세대 소프트웨어 도구를 만들고 있으며, AI 시대의 미래를 함께 만들 엔지니어를 채용하고 있다.

핵심 요약 (20줄)

1. Jonathan Kelley는 학부 마지막 여름에 Google 인턴십 대신 Rust 기반 크로스 플랫폼 앱 프레임워크 Dioxus를 만들기 시작했다.

2. 2021년 Rust는 틈새 언어였지만 네이티브 성능, 견고한 타입 시스템, 간단한 크로스 컴파일이 강력한 선택 이유가 됐다.

3. Dioxus는 HTML과 CSS를 UI 문법으로 사용하고 React에서 반응성 아이디어를 가져와 웹 생태계를 재사용하려 했다.

4. React Native는 버벅거렸고 Flutter는 느렸으며 두 프레임워크 모두 네이티브 API와의 통합이 만족스럽지 않았다.

5. Dioxus 팀은 반응성, 폰트 렌더링, 핫 리로드, 앱 번들링까지 필요한 기반 기술을 처음부터 직접 만들었다.

6. 2026년 Dioxus는 크로스 플랫폼 지원, 네이티브 렌더링, Rust 핫 리로드, 번들 분할을 모두 갖췄다.

7. iOS·Android 앱과 풀스택 웹 애플리케이션이 동일한 코드베이스와 컴포넌트를 공유할 수 있다.

8. Dioxus는 약 37,000개의 GitHub 스타, 수백만 건의 다운로드, 2억 명 이상의 누적 추정 사용자를 확보했다.

9. AI 어시스턴트, 투표 소프트웨어, 데이터 과학 도구, 우주 위성 충돌 방지 시스템이 Dioxus로 만들어졌다.

10. Blitz는 Firefox의 브라우저급 CSS 엔진, 자체 HTML DOM, 하이브리드 GPU 렌더링을 결합한 경량 엔진이다.

11. Blitz 앱은 번들 크기 5MB 미만, 실행 중 RAM 50MB 미만으로 Electron 앱보다 가볍다.

12. Subsecond는 Rust·C·C++ 코드를 약 100밀리초 만에 부분 재컴파일하고 실행 중인 앱에 패치한다.

13. 최근 6개월 동안 AI 코딩 에이전트가 특히 Rust에서 급격히 좋아지며 Dioxus 팀도 개발 방식을 바꿨다.

14. 팀은 수만 줄의 Rust와 수년치 기능을 빠르게 생성했지만 대부분은 머지 품질 기준을 통과하지 못했다.

15. Dioxus의 읽기 쉬운 구조와 좋은 도구·오류 메시지는 에이전트가 Rust의 borrow checker와 엣지 케이스를 다루는 기반이 됐다.

16. 에이전트는 수천 페이지 문서, 맞춤형 API, 바이너리, 역설계가 필요한 기술 문제에서 사람보다 큰 인내심을 제공한다.

17. Kotlin·Swift 플러그인 통합은 구현 첫날 완료됐고 테스트와 실기기 검증을 거쳐 2~3주 만에 출하됐다.

18. AI는 테스트 코드를 쉽게 쓰지만 중요한 시나리오를 고르는 데 약하고, 퍼징 테스트 하네스를 만드는 일에서는 뛰어나다.

19. 나쁜 아키텍처 위에서는 에이전트가 스파게티 코드를 더 빠르게 만들 뿐이므로 사람은 시스템의 미래 진화를 설계해야 한다.

20. 코드가 저렴해진 시대에도 품질은 저렴하지 않으며, 코드를 읽고 의도를 전달하고 아키텍처를 검증하는 엔지니어링의 기준은 더 높아졌다.