스크립트
00:00:00안녕하세요, 제이슨 켈리입니다. 오늘은 AI 시대에 야심 찬 소프트웨어를 구축한다는 것이 어떤 의미인지 이야기해 보겠습니다.
00:00:185년 전, 저는 다이옥시스(Dioxys)라는 프로젝트에 첫 번째 커밋을 작성했습니다.
00:00:25대학생 신분으로 맞이한 마지막 여름방학을 활용해, 구글 인턴십을 하거나
00:00:31당시 많은 친구들이 그랬듯 AI 연구를 하는 대신, 제가 구상하던 아이디어를 탐구하는 데 그 시간을 썼습니다.
00:00:37바로 러스트(Rust) 프로그래밍 언어로 작성된 크로스 플랫폼 앱 프레임워크였습니다. 2021년 당시 러스트는
00:00:45여전히 꽤 마이너했지만, 생태계가 성장하고 도구가 개선되면서 네이티브 성능과
00:00:51탄탄한 타입 시스템, 그리고 간편한 크로스 컴파일이라는 장점이 저를 완전히 매료시켰습니다. 정말
00:00:57덕후 같은 발상이었죠. 다이옥시스의 아이디어는 단순했습니다. 제대로 작동하는 크로스 플랫폼
00:01:05앱 프레임워크가 있다면 어떨까? 수십 가지의 툴체인과 프로그래밍 언어, IDE를 전전하는 대신,
00:01:11마크업 언어로 HTML과 CSS를 사용해 모든 앱을 러스트로 작성할 수 있다면 어떨까? 때는
00:01:192021년이었습니다. 리액트 네이티브(React Native)는 엉성했고, 플러터(Flutter)는 너무 느렸으며, 둘 다
00:01:25네이티브 API와 연동될 때 성능이 좋지 않았습니다. 반면에 러스트를 사용하면 VM이나 IPC, 자바스크립트 없이 네이티브 앱을 직접 구축할 수 있었고, UI에 약간의 HTML과 CSS를 활용하며
00:01:40반응성 측면에서 리액트의 영감을 일부 차용한다면 엄청난 양의 웹 컴포넌트와 웹 도구를 재사용할 수 있었습니다. 목표는 일반적인 개발자에게도 익숙하면서 극도로 강력한 앱 프레임워크를 만드는 것이었습니다.
00:01:52쉽게 들리시나요? 하지만 흔히 말하듯, 우리가 앱 프레임워크를 바닥부터 만들기로 결심한 것은 쉬워서가 아니라, 쉬울 거라고 '생각했기' 때문입니다. 현실적으로 리액트 네이티브와 플러터에 도전하는 것은 엄청나게 야심 찬 일입니다. 2021년 당시에는 기성 컴포넌트가 거의 없었습니다.
00:02:09다이옥시스를 구축하는 데 사용할 수 있는 기성 컴포넌트는 거의 전무했습니다. 반응성부터 폰트 렌더링, 핫 리로드, 애플리케이션 번들링에 이르기까지 모든 것을 바닥부터 구축해야 했습니다. 갖다 쓸 수 있는 게 아무것도 없었죠.
00:02:21우리에게 웹 브라우저를 직접 만드는 것 같은 작업은 그 과정에서 거쳐야 하는 당연한 절차일 뿐이었습니다.
00:02:29그리고 오늘날, 2026년에 이르러 다이옥시스는 원래의 사명을 달성하고 이를 훨씬 뛰어넘었습니다. 크로스 플랫폼 지원, 네이티브 렌더링부터 러스트 핫 리로드와 번들 쪼개기까지, 우리가 처음 구축하고자 했던 모든 기능을 지원합니다. 사실상 앱 개발 스택 전체를 재발명하고 개선한 셈입니다.
00:02:49사용자는 동일한 코드베이스 안에서 강력한 풀스택 웹 애플리케이션을 배포할 수 있으며, iOS 및 안드로이드 앱과 컴포넌트를 공유할 수 있습니다.
00:02:59다이옥시스 프로젝트는 현재 GitHub에서 3만 7천 개에 달하는 스타를 받았으며, 수백만 건의 다운로드를 기록하고 있습니다. 다이옥시스로 구축된 앱들은 전 세계에 배포되어 있으며, 누적 최종 사용자 수는 2억 명이 넘는 것으로 추정됩니다.
00:03:13사용자들은 AI 어시스턴트, 투표 소프트웨어, 데이터 과학 도구, 심지어 우주 위성을 위한 충돌 방지 시스템까지 만들어냈습니다.
00:03:23우리는 다이옥시스를 가능한 한 사용자 친화적으로 만들기 위해 엄청난 노력을 기울였습니다.
00:03:29더 적은 파일, 통합된 빌드 도구, 핫 리로드, 에셋 최적화 등 모든 플랫폼에 쉽게 배포하는 데 필요한 모든 것을 갖추고 있죠.
00:03:37다이옥시스 앱은 러스트로 작성되므로 구조적으로 매우 단순합니다.
00:03:41플랫폼 전용 코드를 작성해야 하는 일은 드뭅니다.
00:03:45모든 러스트 프로젝트가 비슷하기 때문에, 개발자가 새로운 프로젝트에 쉽게 뛰어들 수 있습니다.
00:03:50머리아픈 빌드 시스템 설정 과정을 완전히 건너뛸 수 있죠.
00:03:54시작하는 데 필요한 것은 main.rs 파일 하나뿐입니다.
00:03:58다이옥시스를 위해 세웠던 가장 야심 찬 목표 중 하나는 '블리츠(Blitz)'라는 이름의 가볍지만 완전한 기능을 갖춘 독자적인 HTML 및 CSS 렌더링 엔진을 탑재하는 것이었습니다.
00:04:08우리는 파이어폭스에서 브라우저 수준의 CSS 엔진을 추출하고, 자체 HTML 및 DOM을 구축했으며, 하이브리드 GPU 렌더링 파이프라인을 개발했습니다.
00:04:16RAM과 저장 공간을 잡아먹는 일렉트론(Electron) 앱과 비교할 때, 블리츠 앱은 번들 크기가 5메가바이트 미만으로 가볍고, 런타임 시 50메가바이트 미만의 RAM을 소비합니다.
00:04:28게다가 꽤 멋지죠.
00:04:29나만의 커스텀 컴포넌트나 회전하는 큐브를 작성할 수도 있고, 원하는 대로 브라우저를 커스텀할 수도 있습니다.
00:04:33정말 멋진 프로젝트입니다.
00:04:35또한 우리는 러스트, C, C++를 위한 범용 핫 리로드 엔진인 '섭세컨드(SubSecond)'라는 도구도 개발했습니다.
00:04:42섭세컨드는 코드 편집 내역을 감시하고, 변경된 코드를 재컴파일한 뒤 실행 중인 앱에 그 자리에서 패치합니다. 이 모든 과정이 100밀리초 만에 이루어지죠.
00:04:51이것은 믿기 어려울 정도로 어려운 기술적 과제였으며, 네이티브 컴파일 언어용 핫 리로드 엔진 중 이렇게 광범위한
00:04:58언어 및 런타임 지원을 제공하는 유일한 엔진입니다.
00:05:00모든 주요 운영체제에서 작동하며, 러스트가 웹어셈블리(WebAssembly)로 컴파일되는 웹 환경에서도 작동합니다.
00:05:04아무도 이전에 해낸 적이 없는 일입니다.
00:05:06제가 이 이야기를 하는 이유는, 지난 5년 동안 우리가 거쳐온 이러한 프로젝트들이 믿을 수 없을 정도로 야심 차며, 소규모이지만 뛰어난 실력을 갖춘 천재 엔지니어 팀의 노력의 산물이기 때문입니다.
00:05:18우리는 품질에 공을 들였고, 두 눈으로 직접 모든 코드 라인을 읽었으며, 빈번하면서도 야심 찬 릴리스 주기를 유지해 왔습니다.
00:05:27가장 놀라운 점은, 아주 최근까지도 다이옥시스의 모든 코드 라인이 직접 땀 흘려 손으로 작성되었다는 것입니다.
00:05:35왜 '최근까지'라고 말할까요?
00:05:38잘 아시겠지만, 지난 6개월 동안 소프트웨어 공학 및 개발 분야는 엄청난 전환점을 맞이했습니다.
00:05:45AI 코딩 에이전트가 정말, 정말 좋아졌고, 특히 러스트를 다루는 능력이 엄청나게 뛰어 évolué해졌습니다.
00:05:51내로라하는 러스트 엔지니어들로 구성된 우리 팀은 오랫동안 AI에 대해 꽤 회의적이었습니다.
00:05:58소위 말하는 AGI(인공일반지능)를 체감하지 못했고, 일상적인 업무에서 AI를 전혀 사용하지 않았죠.
00:06:05고품질 코드를 배포하는 것과 에이전틱 코딩 도구를 사용하는 것은 서로 양립할 수 없다고 생각했습니다.
00:06:11에이전트들이 러스트에 능숙해진 것을 보고 큰 충격을 받았고, 마침내 기대감이 생겼습니다.
00:06:18이 새로운 기대감을 안고 우리는 개발을 시작했습니다.
00:06:21우리 팀은 클라우드 코드 구독 한도를 채우고, 수만 줄의 러스트 코드를 찍어내며
00:06:25오랫동안 구현하고 싶었던 온갖 기능들을 만들어 냈습니다.
00:06:28불행히도, 그 코드 중에서 '이걸 우리 코드베이스에 병합해도 될까?' 하는 품질 기준을 통과한 것은 거의 없었습니다.
00:06:35수천 줄의 새로운 기능, 버그 수정, 수년간 원했던 통합 기능들이
00:06:41초안 상태로 쌓여만 갔고, 계속해서 초안으로 남겨졌습니다.
00:06:45우리는 이러한 도구를 올바르게 다루는 법을 전혀 몰랐고,
00:06:48소위 말하는 '스롭 캐논(쓰레기 코드 발사기)'이 되기가 너무나 쉬웠습니다.
00:06:54그래서 우리는 잠시 성찰하며 무엇이 효과가 있었고 무엇이 실패했는지 연구했습니다.
00:07:00수년 동안 우리가 깨달은 것 중 하나는, 우리가 다이옥시스를 극도로
00:07:04개발자 친화적으로 만들기 위해 엄청난 노력을 기울였다는 점입니다.
00:07:07읽기 쉽고, 쓰기 쉽고, 좋은 도구와 훌륭한 에러 메시지를 제공하는 식이었죠.
00:07:11하지만 코딩 에이전트들은 대체로 이런 점에 크게 신경 쓰지 않습니다.
00:07:14우리는 사람이 쓰기 쉽도록 러스트를 만들고자 노력했지만, 사실 그건 별 상관이 없었습니다.
00:07:18다행히도 러스트 자체가 작성하기 까다롭기 때문에, 코딩 에이전트들은 여전히 다이옥시스를 다룰 때 뛰어난 성능을 발휘합니다.
00:07:24코딩 에이전트가 개발의 부담을 대신 짊어지고,
00:07:27엣지 케이스를 처리하며, 빌트인 대조기(borrow checker)와 싸워주기 때문에 러스트 앱 작성에 따르는 인지적 부담을 덜어줍니다.
00:07:32우리가 줄이려고 애썼던 학습 곡선이 이제는 오히려 하나의 장점이 된 것입니다.
00:07:40그렇게 다이옥시스 개발에 코딩 도구를 도입하는 과정에서, 우리는 광범위한 교훈을 얻었습니다.
00:07:45오늘날 코딩 에이전트가 정말 잘 해내는 일도 많지만, 아직 부족한 부분도 많습니다.
00:07:51그래서 다음 몇 슬라이드에서는 우리가 배운 교훈들과, 에이전트 시대에 야심 찬 소프트웨어 프로젝트를 구축한다는 것이
00:07:56어떤 의미인지에 대해 이야기해 보겠습니다.
00:08:02먼저, 야심 찬 소프트웨어 프로젝트를 구축한다는 것이 무엇을 의미하는지 이야기하는 것이 중요합니다.
00:08:11세상에는 다양한 종류의 소프트웨어가 존재하며, 매일 무엇을 배포하느냐에 따라 다릅니다.
00:08:17연구를 진행 중일 수도 있으며, 이 경우 코드의 품질이 가장 중요한 것은 아닐 수 있습니다.
00:08:22프로토타입 코드를 작성하는 중이라면 빠른 반복과 신속한 실행이 중요할 수 있습니다.
00:08:27사람들이 내부 코드를 볼 수 없고 외부로 보이는 모습만 접하는
00:08:30애플리케이션을 만들고 있을 수도 있죠. 하지만 우리와 다이옥시스의 경우,
00:08:37몇 가지 다른 요소들을 중요하게 생각합니다. 무엇보다도 우리의 코드가 항상 작동하며,
00:08:43고장 나더라도 쉽게 고칠 수 있기를 바랍니다. 요즘 사람들은 잘 생각하지 않는 부분이지만, 유지보수가 쉬운
00:08:48코드를 계속해서 만들어 나가야 합니다. 코드를 배포하는 속도는 우리가 쌓아 올린 이 기반 위에 얹혀지는 것이며,
00:08:53만약 기반이 탄탄하지 않다면 그 위에 무엇을 짓든 튼튼할 수 없습니다. 두 번째로 우리는 새로운 기능 배포를 중요하게 여깁니다.
00:08:59기반이 좋지 않으면 그 위에 무엇을 짓든 좋지 않을 것입니다. 둘째로, 우리는 새로운 기능을 출시하는 데 신경 씁니다.
00:09:07우리의 로드맵은 매우 길며, 먼 미래까지 이어져 있습니다. 다이옥시스(Dioxys)를 위해 아직 구축해야 할
00:09:14수십 가지 기능이 남아 있으며, 시대에 뒤처지지 않도록 이를 빠르게 출시하고 싶지만 동시에 품질도 유지하고 싶습니다.
00:09:20다이옥시스와 같이 크고 야심 찬 프로젝트를 구축할 때는 빠른 출시와 새로운 기능 추가, 그리고 무언가를 망가뜨리지 않는 것 사이의
00:09:27끊임한 긴장감이 존재하며, 패치 릴리스에서 수백만 명이 의존하는 API를 깨뜨리지 않도록 해야 합니다.
00:09:32사람들이 그 위에 비즈니스를 구축하는 프로젝트인 만큼, 릴리스에 대한 기준도 매우 높습니다.
00:09:39우리는 문서, 예제, 테스트, 벤치마크의 높은 품질을 유지해야 합니다.
00:09:46무엇인가 잘못되어 있다면, 사람들은 아주 빠르게 알아차립니다.
00:09:52사람들은 아주 빠르게 알아차립니다.
00:09:56따라서 우리는 매우 어려운 기술적 문제를 해결하기 위한 훌륭한 조력자로서 코딩 에이전트를 정말 좋아합니다.
00:10:03코딩 에이전트는 매우 큰 소프트웨어 프로젝트를 혼자서 작업할 때는 발휘하기 매우 어려운 수준의 인내심과 방대한 지식을 제공합니다.
00:10:10다이옥시스의 많은 문제는 지식과 관련된 문제입니다.
00:10:16우리 팀이 모든 빌드 시스템, 모든 런타임, 모든 운영체제에 대한 모든 세부 사항을 현실적으로 알 수는 없습니다.
00:10:23모든 프로그래밍 언어, 모든 API, 모든 특이한 점을 다 알 수는 없지만, 다행히도 이것이 바로 코딩 에이전트가 탁월한 분야입니다.
00:10:30에이전트는 수천 페이지에 달하는 문서를 빠르게 훑어보고, 모든 맞춤형 API를 읽어낼 수 있습니다.
00:10:38바이너리를 파고들고 API를 리버스 엔지니어링하며, 개별 개발자보다 훨씬 더 많은 인내심을 가지고 있습니다.
00:10:46우리는 빌드 시스템에 깊이 통합된 다이옥시스용 코틀린 및 스위프트 플러그인 같은 기능을 구현할 수 있었는데, 이는 정말 어려운 기능입니다.
00:10:52빌드 시스템에 깊이 통합할 수 있었습니다. 정말 구현하기 어려운 기능이죠. 리액트 네이티브의 터보 모듈을 아신다면, 이런 것들은
00:10:59우리는 코딩 에이전트를 통해 이를 2~3주 만에 출시할 수 있었고, 아마 더 빨리 진행할 수도 있었을 것입니다.
00:11:05구현은 첫날 정도에 끝났고, 나머지 2주는 테스트 케이스 작성과
00:11:08실제 기기 테스트에 보냈습니다.
00:11:13그리고 오른쪽에 있는 커스텀 웹 엔진 Blitz에서는 웹 에이전트들이 복잡한 CSS 스타일링과 레이아웃 문제 디버깅을 가속화해 주었습니다.
00:11:22에이전트들은 CSS 사양을 예외적으로 아주 잘 알고 있습니다. 여러분이 화면 렌더링이나 레이아웃 문제를 해결하려는 코드를 작성하고 있을 때,
00:11:28에이전트는 Google Chrome과 Safari가 정확히 어떻게 처리하는지 즉각적으로 떠올릴 수 있으며,
00:11:33여러분의 문제에 맞는 올바른 처리 방법을 알려주기 때문에 굳이 애플의 Git 저장소 깊숙한 곳에 중첩된
00:11:39WebKit 소스코드를 직접 열어볼 필요가 없습니다. 우리는 꼼수가 아니라 올바른 방식으로 일에 투자할 수 있게 되었는데,
00:11:45이는 흥미롭게도 예전에 하던 방식과는 완전히 대조적입니다.
00:11:54우리는 항상 프로젝트의 복잡성에 따라 규모를 가늠하곤 했고, 인간으로서 제품을 더 빨리 출시하기 위해 지름길을 택하는 경향이 있었습니다.
00:12:00하지만 높은 품질 기준을 유지하지는 못했죠. 따라서 코딩 에이전트는 품질을 유지하고 올바른 방식으로 일할 수 있는 능력을 부여해 주며,
00:12:06이는 매우 흥미로운 부분입니다. 야심 찬 프로젝트에서 코딩 에이전트의 덜 화려한 활용법은 사실
00:12:12극도로 일상적이고 지루한 작업들을 처리하는 것입니다. 저희 팀은 매우 작습니다. Dioxys를 개발하는 핵심 엔지니어가 세 명뿐이죠.
00:12:20타르볼(tarball)이 올바른 디렉토리 구조로 압축 해제되는지 확인하는 데 쓰는 모든 시간은 소프트웨어의 아키텍처와
00:12:26핵심적인 난제에 대해 고민할 시간을 낭비하는 것과 같습니다.
00:12:33Dioxys는 거대한 프로젝트이며, 전체 코드베이스와 모든 릴리스에 걸쳐 높은 품질 기준을 유지하는 것은 큰 도전이었습니다.
00:12:39어떤 릴리스에서는 Zed와 같은 새로운 에디터를 위한 확장을 추가할 수도 있습니다.
00:12:44패치 버전을 릴리스할 때마다 해당 에디터를 테스트하지 못할 수도 있으며, 이로 인해 쉽게 문제가 발생할 수 있습니다.
00:12:50이러한 문제에 에이전트를 적용하면 예전이었다면 수많은 시간이 걸렸을 까다롭고 지루한 작업들을 자동화할 수 있습니다.
00:12:55그리고 우리에게 있어 코드가 곧 제품입니다.
00:13:00사람들은 코드를 다운로드하고, 그 위에 코드를 빌드하며, 사용자는 API와 상호작용하고 문서를 읽으며 아키텍처를 구축합니다.
00:13:07따라서 코드 품질의 안일함이나 사용자에게 배포하는 SDK의 결함은 곧바로 더 나쁜 개발자 경험으로 이어지며,
00:13:12사람들이 화를 내거나, 비즈니스가 정체되거나, 제품을 떠나게 만듭니다.
00:13:18그러므로 코딩 에이전트는 릴리스 체크리스트 검증, 안정 버전으로의 버그 수정 백포팅,
00:13:24그리고 문서의 극도로 높은 품질 유지와 같은 작업들을 유지 관리하는 데 탁월했습니다.
00:13:30여전히 우리가 직접 작성하는 독 주석(doc comments)도 많지만, 모든 것이 제대로 문서화되어 있는지
00:13:36에이전트에게 작업을 맡기는 것은 매우 쉽습니다.
00:13:43모든 것에는 예제가 있고, 실제로 설명하는 내용을 정확한 방식으로 문서화하고 있습니다.
00:13:48사람으로서 우리는 코드는 수정하지만 주석은 수정하지 않기 마련입니다.
00:13:53결과적으로 시간이 지남에 따라 많은 주석이 실제와 달라지고 상황이 매우 혼란스러워집니다.
00:13:59숫자만 놓고 보더라도, 최근 Dioxys 버전에서는 그 어느 때보다 더 많은 패치 릴리스를 배포했습니다.
00:14:04따라서 예전 같았으면 릴리스하기를 두려워했을 크고 야심 찬 소프트웨어를 대상으로
00:14:08매주 또는 일주일에 여러 번의 릴리스 주기를 유지할 수 있게 되었습니다.
00:14:13아직 100% 확신이 서지 않아 성공 여부가 갈리는 한 가지 영역은 AI를 이용해 테스트를 작성하는 것입니다.
00:14:18적어도 무작정 테스트를 작성하는 것은 그렇습니다. Dioxys에서 우리가 어려움을 겪었던 부분 중 하나가 바로 테스트입니다.
00:14:28기반 소프트웨어를 테스트하는 것은 매우 어려울 수 있으며, 특히 복잡한 시스템의 엔드투엔드 테스트는 더욱 그렇습니다.
00:14:35확장이 Zed에 제대로 설치되고 원하는 대로 작동하는지 직접 Zed를 열어 확장을 사용해보지 않고는 테스트하기가 어렵습니다.
00:14:41코딩 에이전트들도 이 부분에서는 어느 정도 어려움을 겪습니다.
00:14:46또한 다소 부실한 테스트를 작성하는 경향이 있기도 합니다.
00:14:53생성자를 제공하면 생성자를 테스트하러 가는데, 이는 그다지 흥미로운 테스트가 아닙니다.
00:15:00에이전트는 주어진 API에 대한 테스트를 쉽게 작성할 수 있지만, 인간과 마찬가지로 올바른 테스트를 작성하는 데는 실패합니다.
00:15:03그래서 우리는 여전히 테스트 조건을 수동으로 열거하고, 테스트 API를 직접 만들며, 테스트 러너를 관리하고 있습니다.
00:15:10하지만 커버리지가 확실히 필요한 특정 항목에 대한 테스트 아이디어를 떠올리고 엣지 케이스를 열거할 때는
00:15:18종종 훌륭한 조언자 역할을 하기도 합니다.
00:15:24그리고 코딩 에이전트를 테스트에 사용하는 것이 정말 만족스러웠던 한 가지 분야는 테스트 하니스(harness) 구축입니다.
00:15:29퍼징(fuzzing)은 프로덕션 급 소프트웨어를 구축하는 데 있어 매우 중요한 부분입니다.
00:15:34이는 애플리케이션에 수백만 개의 서로 다른 입력, 그리고 흔히 적대적 입력(adversarial inputs),
00:15:42기본적으로 잘못된 형식의 입력이나 사용자가 사용해서는 안 되지만 실제로 사용할 수 있는 방식으로 소프트웨어를 구동하는 것을 의미합니다.
00:15:48그리고 코딩 에이전트는 이러한 하니스를 구축하는 데 탁월합니다.
00:15:55우리가 발견한 또 한 가지는 코드 아키텍처가 여전히 예술의 영역이라는 점입니다.
00:16:03코딩 에이전트를 사용하면 예외적으로 높은 속도로 배포할 수 있습니다. 앞서 언급했듯이 말이죠.
00:16:10코딩 에이전트를 이용하면 엄청난 속도로 제품을 출시할 수 있습니다. 앞서 말씀드린 대로죠.
00:16:15인간 엔지니어와 달리, 코딩 에이전트는 기능이 잘 맞지 않을 때 자발적으로 시스템의 거대한 리팩터링에 나서거나
00:16:21아키텍처를 재설계하는 것을 두려워하지 않습니다. 대개 그냥 배포해 버리죠.
00:16:26대부분의 개발 시간은 이제 소프트웨어 아키텍처, 미래에 원하는 기능, 그리고 시스템이 어떻게 진화할지에 대해 고민하는 데 소모됩니다.
00:16:32인간 엔지니어들이 스파게티 코드를 작성할 수 있듯이 에이전트도 그럴 수 있지만, 이제는 더 빨리 작성할 뿐입니다.
00:16:36하지만 Fable 수준의 도구를 사용하면 의도를 적절히 전달한다는 전하 하에
00:16:40실제 코드 품질 자체가 매우 높기 때문에 적절한 소프트웨어 아키텍처가 미래에는 아마도 대부분의 시간을 차지하게 될 것입니다.
00:16:46하지만 Fable 수준의 도구를 사용하면 실제 코드 품질 자체가 매우 뛰어나서,
00:16:51우리가 Dioxys를 위해 하는 일 중 하나는—여러분도 여전히 하고 계실 수도 있고 아닐 수도 있지만—모든 PR을 줄 바꿈 단위로 검토하는 것입니다.
00:16:57버그를 사전에 발견하기 위해 AI 리뷰를 적극적으로 사용하지만, 우리가 배포하는 코드를 직접 읽어보는 것도 여전히 좋아합니다.
00:17:03실제로 낯선 사람들로부터 매우 많은 PR을 받습니다. Dioxys는 거대한 오픈소스 프로젝트이며,
00:17:11모든 PR이 똑같지는 않습니다. 사용자들은 모델에 자신의 의도를 전달하는 데 꽤 서투를 수 있다는 것을 알게 됩니다.
00:17:18기여자들은 보통 시간이 지남에 따라 코드베이스가 어떻게 진화해야 하는지 깊이 생각하지 않습니다.
00:17:24그저 자신들의 버그 수정이나 기능이 반영되기를 원할 뿐이죠. 그리고 많은 해결책들이 엉성하게 기워져 있습니다.
00:17:30따라서 코딩 에이전트가 우리의 마음을 읽을 수 있는 단계는 아니며, 결과적으로 우리는 여전히 텍스트라는 매체에 제한되어 있습니다.
00:17:34말도 안 되게 들릴지 모르겠지만, 프롬프트 엔지니어링은 꽤 실존하는 개념입니다.
00:17:39구현의 품질은 모델에게 주는 프롬프트에 크게 좌우될 수 있습니다.
00:17:45하지만 어떤 의미에서는 바뀐 것이 거의 없습니다. 코드를 읽는 것은 코드를 작성하는 것보다 언제나 더 중요했습니다.
00:17:50처음에는 아닐지 몰라도, 프로젝트가 진화함에 따라 결국 그렇게 됩니다.
00:17:56따라서 야심 찬 소프트웨어를 구축하기 위해 코딩 에이전트를 사용하는 것에 대한 저의 폐막 소감은 코드는 이제 저렴하지만,
00:18:02품질은 그렇지 않다는 것입니다.
00:18:07소프트웨어 엔지니어의 역할은 화면에 코드 줄을 올리는 것이 아니었습니다.
00:18:14복잡한 문제에 대한 우아한 솔루션을 설계하고, 시스템이 어떻게 진화할지에 대해 10단계 앞서 생각하며,
00:18:22변화하는 요구사항 속에서도 유연성을 유지하는 것이었습니다.
00:18:28이러한 사실들은 변하지 않았으며, 소프트웨어 엔지니어링의 기준은 그 어느 때보다 높아졌습니다.
00:18:34차세대 소프트웨어 도구를 만드는 일에 참여하고 싶으시다면, Dioxys를 인수한 Cognition에서 채용을 진행 중입니다.
00:18:41Dioxys 팀은 미래의 일부가 되기 위해 Cognition에 합류했으며,
00:18:46여러분도 그러기를 바랍니다. 감사합니다.
00:18:51Dioxys 팀이 Cognition에 합류했습니다.
00:19:01Dioxys 팀이 Cognition에 합류했습니다.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기