Building ambitious software — Jonathan Kelley, Dioxus Labs & Cognition

한 줄 핵심

AI 코딩 에이전트로 코드 작성은 훨씬 싸졌지만, 대규모 소프트웨어의 경쟁력은 여전히 아키텍처·품질·검증에 달려 있으며 Rust 같은 어려운 스택일수록 에이전트를 잘 쓰면 오히려 강점이 된다.

시간별 요약

0:00
5년 전, 첫 커밋 Dioxus는 Rust로 크로스플랫폼 앱 프레임워크를 만들겠다는 아이디어에서 시작됐고, React Native와 Flutter의 한계를 넘기 위해 네이티브 성능과 익숙한 웹 기술의 결합을 노렸다. 당시에는 핵심 구성요소 대부분을 직접 만들어야 했고, 브라우저에 가까운 기능까지도 프로젝트의 일부로 해결해야 하는 매우 야심찬 시도였다.
2:49
프로젝트의 현재 위치 Dioxus는 크로스플랫폼 지원, 네이티브 렌더링, Rust hot reload, bundle splitting까지 원래 목표를 넘어서는 수준으로 성장했고, 수만 개의 GitHub stars와 수백만 다운로드를 확보한 대형 오픈소스가 됐다. 전용 웹 렌더링 엔진 Blitz는 가벼운 번들 크기와 적은 메모리 사용으로 Electron보다 훨씬 가벼운 대안을 제시한다.
4:35
Blitz와 Subsecond Subsecond은 Rust, C, C++를 위한 범용 hot reload 엔진으로, 코드 변경을 감지해 부분 재컴파일 후 실행 중인 앱에 약 100 milliseconds 수준으로 패치한다. 이 시점까지 Dioxus의 코드는 거의 전부 사람이 직접 작성해 왔고, 높은 출시 속도와 품질 기준을 동시에 유지해 왔다.
6:15
에이전트가 Rust를 잘 다루게 된 순간 최근 6개월 사이 AI 코딩 에이전트가 특히 Rust에서 크게 향상되면서, 대규모 Rust 코드를 빠르게 생성하고 오랫동안 미뤄 둔 기능과 통합 작업을 시도할 수 있게 됐다. 다만 생성된 코드의 상당수는 품질 기준을 통과하지 못해, 에이전트를 제대로 다루는 방법과 검증 방식이 별도로 필요하다는 점이 드러났다.
7:07
어려운 언어가 강점이 된 이유 에이전트는 Rust의 어려운 문법과 borrow checker를 대신 상대해 주기 때문에, 사람이 느끼는 작성 부담은 오히려 줄고 언어의 진입 장벽은 약점이 아니라 특징이 된다. 대규모 프로젝트에서는 빠른 기능 추가와 안정성, 문서, 테스트, 벤치마크를 동시에 지켜야 하므로, 에이전트는 지식과 인내가 필요한 문제를 보조하는 도구로 특히 유용하다.
10:32
인내심 있는 전문가로서의 에이전트 에이전트는 방대한 문서와 특수한 API를 빠르게 훑고, 바이너리를 분석하거나 API를 역공학하는 식의 지식 탐색에 강하다. 이 덕분에 Kotlin과 Swift 플러그인 같은 깊게 통합된 기능을 몇 주 단위로 구현할 수 있었고, CSS와 레이아웃 문제도 WebKit 소스를 직접 뒤지지 않고 훨씬 빠르게 디버깅할 수 있었다.
13:04
자동화할 가치가 있는 사소한 일 작은 팀이 대형 코드베이스를 운영할 때는 tarball 검증, 릴리스 체크리스트 점검, 백포트, 문서 품질 관리 같은 반복 작업을 자동화하는 것이 매우 큰 효과를 낸다. 반면 테스트는 단순히 생성만 시키면 얕은 테스트가 나오기 쉬워 한계가 있고, 여전히 사람이 조건을 설계하되 에이전트는 테스트 아이디어와 커버리지 보조에 더 적합하다.
15:37
테스트가 약한 지점, 퍼징이 강한 지점 production-grade 소프트웨어에서는 수많은 입력과 악의적 입력을 견디는 fuzzing이 핵심이며, 에이전트는 이런 harness를 만드는 데 특히 강하다. 반면 좋은 아키텍처가 깔려 있지 않으면 에이전트의 속도는 오히려 나쁜 설계를 더 빨리 퍼뜨릴 뿐이어서, 기반 구조의 품질이 결과를 좌우한다.
16:28
아키텍처는 여전히 예술이다 코드 생성이 빨라진 지금도 실제 개발 시간의 대부분은 앞으로의 확장성을 고려한 아키텍처 설계에 쓰이며, 에이전트도 사람처럼 스파게티 코드를 더 빨리 만들 수 있다. 그래서 모든 PR을 줄 단위로 읽고 AI review를 보조로만 쓰는 것이 중요하며, 좋은 프롬프트와 명확한 의도 전달이 코드 품질을 좌우한다.
17:19
쓰는 것보다 읽는 것 대형 오픈소스 프로젝트에서는 참여자가 의도를 충분히 설명하지 못해 모델이 단기적인 패치만 만들기 쉽고, 결국 텍스트 기반 인터페이스의 한계가 드러난다. 그래서 code를 쓰는 일보다 읽고 검토하는 일이 더 중요하며, 소프트웨어 엔지니어의 핵심 역할은 여전히 복잡한 문제를 장기적으로 설계하는 데 있다.

실무 인사이트

에이전트를 도입해도 가장 큰 병목은 구현 속도가 아니라 아키텍처와 검증이므로, 먼저 코드베이스의 기준선과 리뷰 규칙을 명확히 해야 한다.
반복적이고 귀찮지만 중요한 운영 작업은 에이전트에 맡기되, 테스트는 생성보다 설계가 중요하므로 사람이 테스트 의도를 먼저 정의하는 방식이 효과적이다.
Rust처럼 진입 장벽이 높은 스택은 에이전트가 보조할 때 생산성 이득이 커지므로, 어려운 언어를 버리기보다 품질 기준과 워크플로를 함께 재설계하는 편이 유리하다.