3명이 5년간 손으로 쓴 30만 줄 Rust — 에이전트로 수만 줄을 뽑았는데 머지한 건 거의 없었습니다

한 줄 핵심

Rust 기반 크로스 플랫폼 프레임워크에서 코딩 에이전트는 지식 탐색과 지루한 반복 작업을 크게 줄였지만, 테스트·아키텍처·리뷰처럼 품질을 결정하는 핵심은 여전히 사람이 붙잡아야 한다는 점을 보여준다.

시간별 요약

1. 0:00
   3명이 5년간 손으로 쓴 프레임워크, 머지된 건 거의 없었다 Deoxys는 3명이 5년 동안 손으로 만든 30만 줄 규모의 Rust 크로스 플랫폼 프레임워크이며, 이를 기반으로 한 앱은 2억 명 이상이 쓸 것으로 추정된다. 올해 초 코딩 에이전트를 본격 도입해 수만 줄을 생성했지만, 품질 기준을 통과해 실제로 머지된 코드는 거의 없었다.
2. 1:34
   모든 코드를 손으로 썼다, 그리고 슬롭 대포 오랫동안 팀은 AI 코딩 도구가 고품질 코드 작성과 양립하기 어렵다고 보았지만, 최근 Rust에서 에이전트 성능이 좋아지자 큰 기대를 걸었다. 그러나 대규모 기능과 수정안을 쏟아냈음에도 대부분이 초안 상태로 남았고, 도구를 제대로 쓰는 방법을 아직 익히지 못했다는 점이 드러났다.
3. 3:00
   없애려던 학습 곡선이 기능이 됐다 Rust를 인간에게 쉽게 만들려던 노력은 에이전트에게는 거의 의미가 없었고, 오히려 Rust의 높은 난도가 에이전트에겐 장점으로 작동했다. 에이전트는 보로우 체커와 복잡한 엣지 케이스를 대신 다루며, 사람이 겪는 인지 부담을 덜어주는 쪽으로 가치가 나타났다.
4. 3:56
   Rust의 어려움이 에이전트에겐 장점 Rust의 어려운 규칙과 엄격한 컴파일러 검사는 인간에게는 진입장벽이지만, 에이전트에게는 복잡한 제약을 기계적으로 처리하게 만드는 강점이 된다. 이 특성 때문에 에이전트는 개발자가 직접 신경 써야 할 세부 규칙과 예외를 대신 흡수할 수 있다.
5. 4:40
   품질의 다섯 기준, 기반 위의 배포 속도 팀이 말하는 품질은 더 빠른 배포, 더 적은 버그, 모든 플랫폼에서의 높은 품질, 유지보수 용이성, 그리고 단단한 기반 위의 배포 속도다. 에이전트가 가장 잘한 일은 크로스 플랫폼 개발에 필요한 방대한 문서와 세부 규칙을 읽어내는 지식 작업을 대신한 것이었다.
6. 5:18
   지식 문제, Kotlin·Swift 플러그인이 첫날에 Kotlin과 Swift 플러그인처럼 복잡한 통합 기능은 사람 손으로는 수년이 걸릴 수 있지만, 에이전트로는 매우 짧은 기간에 구현할 수 있었다. 핵심은 수천 페이지의 문서와 비공식 API 관행을 빠르게 훑고, 빌드 시스템 깊숙이 통합되는 작업을 버텨내는 능력이었다.
7. 6:19
   지름길 대신 제대로 된 방법, 그리고 지루한 일 에이전트 덕분에 예전처럼 지름길을 택하지 않고도 정석적인 구현을 선택할 여유가 생겼고, 그 결과 품질을 해치지 않으면서도 더 빠르게 전진할 수 있게 됐다. 또한 배포 검증, 폴더 구조 확인, 확장 기능의 회귀 테스트 같은 지루한 반복 업무를 맡겨 사람이 아키텍처에 집중할 수 있게 됐다.
8. 7:15
   릴리스 검증·백포트·문서 점검 에이전트는 릴리스 체크리스트 검증, 안정판 백포트, 문서와 예제의 정합성 점검에서 특히 효과적이었다. 덕분에 패치 릴리스를 훨씬 더 자주 낼 수 있었고, 주 단위 또는 그보다 잦은 배포 리듬을 유지할 수 있었다.
9. 8:05
   역대 최다 패치 릴리스, 안 된 일은 테스트 최근 버전에서는 역대 가장 많은 패치 릴리스를 냈지만, 테스트는 여전히 약점으로 남아 있다. 기반 소프트웨어는 실제 편집기에서 직접 써 봐야 검증되는 경우가 많고, 에이전트가 만든 테스트는 종종 의미 없는 생성자 테스트처럼 얕게 끝나기 쉽다.
10. 8:33
    생성자를 주면 생성자를 테스트한다 에이전트는 주어진 API에 대한 테스트를 쉽게 작성하지만, 정말로 필요한 경계 조건과 의미 있는 실패 사례를 스스로 고르지는 못한다. 그래서 테스트 조건 열거, 테스트 API 설계, 러너 운용은 아직 사람이 주도하고, 에이전트는 아이디어 발상이나 퍼징용 하네스 작성에서 보조 역할을 한다.
11. 10:13
    퍼징, 사람의 일이 옮겨간 곳 퍼징처럼 수백만 개의 이상한 입력을 흘려보내는 테스트 하네스 구축은 에이전트가 잘하는 영역이다. 반면 어떤 입력이 의미 있고 어떤 실패가 중요한지는 여전히 사람이 판단해야 하며, 결국 사람의 일은 코드 작성에서 구조와 검증 설계 쪽으로 이동했다.
12. 10:40
    아키텍처는 여전히 예술 에이전트는 기능이 구조에 맞지 않으면 대담하게 리팩터링하고 바로 배포할 수 있기 때문에, 잘못된 구조 위에 더 빠르게 잘못된 코드를 쌓을 위험도 있다. 그래서 현재 개발 시간의 상당 부분은 미래 기능과 시스템 진화를 고려한 아키텍처 설계에 쓰이고 있다.
13. 11:38
    여전히 모든 PR을 한 줄씩 읽는다 AI 리뷰가 버그를 먼저 잡아주더라도, 실제 배포 코드는 지금도 모든 PR을 한 줄씩 읽어 검토한다. 외부 기여자는 의도와 미래 구조를 충분히 설명하지 못하는 경우가 많아, 프롬프트와 맥락 전달이 품질을 좌우하는 중요한 요소로 남아 있다.
14. 12:19
    코드는 싸지만, 품질은 아니다 코드를 쓰는 비용은 낮아졌지만, 복잡한 문제를 우아하게 풀고 변화에 견디는 품질의 가치는 전혀 싸지지 않았다. 소프트웨어 엔지니어의 핵심은 더 많은 줄을 쓰는 일이 아니라, 미래를 내다보고 유연한 구조를 설계하고 읽는 능력이라는 점이 강조된다.
15. 13:02
    정리와 피날레 에이전트는 지식이 필요한 일과 지루한 반복 작업을 크게 가져갔지만, 테스트의 선택과 아키텍처 판단, 코드 리뷰는 오히려 더 중요해졌다. 결국 에이전트 시대에 필요한 역량은 빠르게 타이핑하는 힘이 아니라, 무엇을 만들지 정하고 그것이 제대로 만들어졌는지 정확히 읽어내는 능력이다.

실무 인사이트

• 에이전트를 붙일수록 사람은 구현보다 아키텍처·품질 기준·의도 전달에 더 많은 시간을 써야 하므로, 팀의 병목을 코드 생산이 아니라 판단과 검증으로 재정의해야 한다.
• 테스트 자동화는 테스트 ‘작성’보다 테스트 ‘선정’이 더 어렵기 때문에, 에이전트 도입과 함께 경계 조건 설계와 퍼징 하네스 같은 검증 구조를 사람이 명시적으로 관리해야 한다.
• 문서, 릴리스 체크리스트, 백포트처럼 반복적이지만 놓치면 품질을 해치는 작업은 에이전트에 맡기고, 사람은 리뷰와 설계에 집중하는 분업이 가장 실용적이다.