스크립트
00:00:00BUN이 SIG에서 Rust로 포팅되었습니다.
00:00:02아마 들어보셨겠지만,
00:00:04여기에는 풀 이야기가 많습니다.
00:00:06지난주에 많은 드라마가 있었지만,
00:00:08흥미로운 일들도 많이 벌어지고 있죠.
00:00:10BUN, SIG, Rust 중 무엇에 관심이 있든 간에,
00:00:14정말 흥미로운 주제입니다.
00:00:15또한 AI가 어떻게 활용되었는지,
00:00:18그리고 그것이 우리 업계의 유사한 프로젝트에
00:00:20어떤 의미가 있을지에 대해서도요.
00:00:22참고로 말씀드리면,
00:00:24저는 개인적으로 BUN을 상당히 좋아합니다.
00:00:26대부분의 프로젝트에서 제가 기본으로 사용하는
00:00:29JavaScript 런타임이죠.
00:00:30공교롭게도,
00:00:32지난주에 BUN에 대한 새 코스를 출판했습니다.
00:00:35그리고 당연히 SIG 버전과 마찬가지로
00:00:37Rust 버전에서도 잘 작동합니다.
00:00:39BUN에 대해 더 깊이 알아보고 싶거나,
00:00:41제공되는 모든 핵심 API를 배우고 싶다면,
00:00:44그게 바로 BUN의 가장 큰 장점 중 하나니까요.
00:00:46많은 것이 기본 내장되어 있죠.
00:00:48싫어하는 사람도 있지만, 전 정말 좋아합니다.
00:00:50더 배우고 싶으시다면,
00:00:51그 코스가 도움이 될 겁니다.
00:00:53그럼 이제 전체적인 포팅 타임라인을
00:00:54더 자세히 살펴볼까요?
00:00:58사실 두 달 전에 일어난 일입니다.
00:01:01블로그 포스트는 7월 지난주에 나왔지만,
00:01:04포팅 자체는 5월에 이루어졌습니다.
00:01:085월 초에 공식 BUN GitHub 저장소에서
00:01:10CloudFaserPort 브랜치가 발견되면서 시작됐죠.
00:01:13그 브랜치에는 포팅 관련 MD 파일이 있었는데,
00:01:15SIG 코드를 Rust 코드로 변환하는
00:01:18방법이 적힌 마크다운 파일과,
00:01:21포팅 방법, 변환 테이블,
00:01:23그리고 일반적인 지침들이 담겨 있었습니다.
00:01:27이 파일이 어떻게 만들어졌는지에 대해서는
00:01:28나중에 다시 언급하겠지만,
00:01:30당연히 AI가 관여했습니다.
00:01:32예상하셨겠지만, 잠시 후에 자세히 말씀드리죠.
00:01:34그렇게 발견되었습니다.
00:01:36당연히 Hacker News와 X에서 논의가 이어졌죠.
00:01:40기대하는 사람들도 있었고,
00:01:43매우 비판적인 사람들도 있었습니다.
00:01:46그 시점엔 알려진 게 별로 없었거든요.
00:01:47Rust를 둘러싼 양극화는 분명 존재하니까요.
00:01:52저처럼 Rust를 사랑하는 사람도 있고,
00:01:55Rust를 싫어하는 사람도 있죠.
00:01:57모든 것을 Rust로 다시 써야 한다는
00:01:58주장을 싫어하는 사람들도 있습니다.
00:02:00프로그램 XYZ를 Rust로 다시 쓰라는
00:02:03요청을 자주 접하니까요.
00:02:06그게 짜증나는 건 충분히 이해합니다.
00:02:08어쨌든 그 때문에,
00:02:09많은 양극화가 일어났습니다.
00:02:11하지만 포팅은 아직 일어나지 않았었죠.
00:02:15그게 5월 말에 바뀌었습니다.
00:02:165월 14일에 공식 풀 리퀘스트가 열렸고,
00:02:22병합까지 되었으며,
00:02:24실제로 BUN 코드베이스 전부를
00:02:28SIG에서 Rust로 마이그레이션했습니다.
00:02:30보시다시피 엄청난 규모의 풀 리퀘스트였죠.
00:02:32백만 줄 이상의 코드가 추가되었습니다.
00:02:35SIG 코드 제거는
00:02:39다른 단계에서 이루어졌고요.
00:02:40그래서 단순 교체가 아니었던 겁니다.
00:02:42하지만 보시다시피 7,000개에 가까운 커밋으로,
00:02:44엄청난 변화였죠.
00:02:46당연히 이 코드는 사람의 검토를 거치지 않았습니다.
00:02:51전부는 아니더라도 말이죠.
00:02:52AI가 검토했습니다.
00:02:54테스트는 통과했지만 사람의 검토는 없었죠.
00:02:59AI가 어떻게 사용됐는지는 잠시 후에 다시 이야기하죠.
00:03:02아무튼 그렇게 병합되었습니다.
00:03:06물론 더 많은 논의가 이어졌고요.
00:03:08방금 언급했듯이 사람의 검토를 거치지 않았죠.
00:03:10그 기간 내에 사람이 검토하는 건 불가능하니까요.
00:03:14하지만 커뮤니티가 뛰어들어 내용을 분석했습니다.
00:03:17그 후 첫 번째 블로그 포스트가 나왔죠.
00:03:19모든 세부 사항을 다룬 공식적인 글은 아니지만,
00:03:23Buntine에서 unsafe 사용에 대해
00:03:25발표한 첫 번째 성명서였습니다.
00:03:29왜냐하면 이 풀 리퀘스트 이후 가장 큰 비판 중 하나가
00:03:32Rust 코드가 관용적인 Rust가 아니라는 점이었거든요.
00:03:37처음부터 만들었다면 쓰지 않았을
00:03:41그런 종류의 Rust 코드였던 겁니다.
00:03:44오히려 SIG에서 Rust로의 변환에 가까웠죠.
00:03:46즉, 모든 Rust 모범 사례나
00:03:50패턴이 사용된 건 아니었습니다.
00:03:54특히 꽤 많은 양의
00:03:55unsafe 코드가 포함되어 있었죠.
00:03:58unsafe를 이해하려면,
00:04:00Rust의 메모리 관리 방식을 알아야 합니다.
00:04:03그게 Rust의 가장 큰 장점 중 하나이고,
00:04:05다른 언어와는 상당히 다르니까요.
00:04:08대부분의 언어에는 가비지 컬렉터가 있어서,
00:04:10프로그램에서 더 이상 사용되지 않는 값을
00:04:14감지해 메모리를 해제해주죠.
00:04:16편리하지만 리소스를 소모합니다.
00:04:19아니면 직접 해야 하죠.
00:04:21C 언어처럼 직접 할당하고 해제해야 합니다.
00:04:24SIG에서도 마찬가지고요.
00:04:26메모리를 할당할 수 있지만,
00:04:28더 이상 필요하지 않을 때 free를 호출해야 하죠.
00:04:31defer를 사용할 수 있는데 이건 편리합니다.
00:04:33실행되기 전에 미리 호출해두면,
00:04:37스코프가 끝날 때 자동으로 호출되니까요.
00:04:40상황에 따라 다르긴 하지만,
00:04:43값의 필요성이 사라지는 경우가 많습니다.
00:04:47수동으로 메모리를 관리할 때는
00:04:49실수할 가능성이 많죠.
00:04:52세밀한 제어가 가능해서 효율적이지만,
00:04:55복잡한 프로그램에서는
00:04:58메모리 해제를 잊어버리거나,
00:05:00두 번 해제해서 에러를 발생시키기 쉽습니다.
00:05:04그래서 상충 관계가 있는 거죠.
00:05:05Rust는 다른 접근 방식을 취합니다.
00:05:07소유권 개념을 사용하는데,
00:05:09모든 값은 딱 하나의 소유자를 가집니다.
00:05:11스코프에 묶여 있죠.
00:05:15중괄호로 스코프를 만들 수 있고,
00:05:16함수도 자체 스코프를 가집니다.
00:05:19JavaScript에서도 익숙하시겠죠.
00:05:20값은 해당 스코프에 소유되고,
00:05:23스코프가 끝나면 메모리도 해제됩니다.
00:05:25수동으로 관리할 필요가 없어서 매우 편리하죠.
00:05:27가비지 컬렉터도 필요 없습니다.
00:05:30대신 명확한 규칙이 있습니다.
00:05:32값을 전달해야 하는 복잡한 프로그램에서는
00:05:36조금 복잡해질 수 있지만,
00:05:38생각의 전환이 필요합니다.
00:05:39결과적으로 메모리 안전성을 보장받죠.
00:05:41unsafe 키워드를 쓰지 않는 한 말입니다.
00:05:43자바스크립트에서 이미 알고 계실 개념이죠.
00:05:46메모리 관리는 이제 전적으로 여러분의 몫이죠.
00:05:47왜 이런 걸 할까요?
00:05:49예를 들어, C 라이브러리를 사용할 때,
00:05:51Rust에서도 C 코드를 부를 수 있는데,
00:05:53C 코드는 본질적으로 안전하지 않기 때문에
00:05:55그 코드를 호출하는 영역은 unsafe로 처리됩니다.
00:05:58그래서 외부 라이브러리와 상호작용하려면 필수죠.
00:06:00공식 성명에서도 언급했듯이,
00:06:02코드베이스 내 unsafe 사용의 상당 부분은
00:06:05실제로 C 라이브러리 호출과 관련이 있습니다.
00:06:07이건 어쩔 수 없는 부분이죠.
00:06:08하지만 코드를 개선하고
00:06:11unsafe를 줄일 수 있는 부분도 찾아냈습니다.
00:06:14후속 풀 리퀘스트를 통해 계속 개선 중입니다.
00:06:19처음 포팅은 시작점일 뿐이고,
00:06:22시간이 지나며 정제되고 있는 셈이죠.
00:06:24그래도 그 거대한 풀 리퀘스트에서
00:06:26테스트는 이미 통과했다는 점은 짚고 넘어갑시다.
00:06:28안정적이었다는 거죠.
00:06:29다만 애초에 Rust로 처음부터
00:06:31작성된 코드와 같은 수준의 품질은 아니었습니다.
00:06:33그게 목표가 아니었으니까요.
00:06:345월 21일까지의 이야기입니다.
00:06:37그 후엔 침묵이 이어졌죠.
00:06:40그리고 이 버전의 BUN은 아직 출시되지 않았습니다.
00:06:44제가 녹화하는 지금도 라이브 상태는 아닙니다.
00:06:48지금 BUN을 설치해도 여전히 SIG 버전을 받지만,
00:06:52조만간 바뀔 겁니다.
00:06:54그러다 7월 8일에,
00:06:56포팅에 대한 흥미로운 세부 정보가 담긴
00:07:00공식 블로그 포스트가 올라왔습니다.
00:07:04읽어볼 가치가 충분하죠.
00:07:07배울 점이 많으니 아래에 링크해 두겠습니다.
00:07:08비밀도 아니지만, 이 포팅 전체는
00:07:10AI의 도움으로 이루어졌습니다.
00:07:13BUN은 Anthropic이 소유하고 있다는 점도
00:07:14기억해 둘 필요가 있습니다.
00:07:15그들은 모든 토큰에 자유롭게 접근할 수 있었고,
00:07:18특히 대중에 공개되기 전인
00:07:20Claude 3.5 모델을 사용했죠.
00:07:22이번 포팅은 바로 그 Claude 3.5로 진행되었습니다.
00:07:24그건 그렇고, 지금 Cloud Code를 설치하신다면,
00:07:26Rust 버전인 BUN 1.4가 아직 안 나왔음에도,
00:07:28Cloud Code는 벌써
00:07:30미출시 BUN 버전 위에서
00:07:32돌아가고 있는 셈입니다.
00:07:35더 자세히 알아보겠습니다.
00:07:37이게 전체적인 흐름입니다.
00:07:40이 과정에서 배울 수 있는 게 정말 많거든요.
00:07:43그럼 이제,
00:07:45본격적으로 논의해 보죠.
00:07:46단순히 번역 도구로 AI를 쓴 게 아닙니다.
00:07:49그 이상의 의미가 있죠.
00:07:50포팅 과정에서 AI가 코드베이스를
00:07:52어떻게 이해했는지,
00:07:54그리고 어떤 실수가 있었는지,
00:07:56어떻게 교정되었는지 등 말입니다.
00:07:58모두가 궁금해할 부분이죠.
00:07:59특히 거대 프로젝트에서 AI를 통한
00:08:02전체 마이그레이션이 어떻게 가능했는지,
00:08:04그 실무적인 부분은
00:08:06정말 흥미롭습니다.
00:08:07단순한 자동 번역이 아니라,
00:08:08구조적인 해석이 필요했으니까요.
00:08:11그래서 아주 정교한 단계가 필요했습니다.
00:08:13AI의 도움을 받아 진행되었습니다.
00:08:15참고로 BUN은 Anthropic 소유라는 점을 기억할 필요가 있습니다.
00:08:18그래서 그들은 모든 토큰에 자유롭게 접근할 수 있었고,
00:08:22특히 Fable 5가 대중에 공개되기 전에도
00:08:24사용할 수 있었습니다.
00:08:26이번 포팅은 Fable 5로 진행되었습니다.
00:08:29참고로 지금 Cloud Code를 설치 중이라면,
00:08:32Rust 버전인 BUN 1.4가 아직 출시되지 않았음에도,
00:08:36Cloud Code는 이미
00:08:39미출시된 BUN 버전, 즉 Rust 버전 위에서
00:08:42실행되고 있다는 사실입니다.
00:08:44그렇습니다.
00:08:45아무튼 이번 포팅은 Cloud Code를 사용했고,
00:08:48당연히 BUN이 Anthropic의 일부라 무료 토큰을 기반으로
00:08:52진행된 것이나 다름없습니다.
00:08:54이 점을 기억하는 게 중요한 이유는,
00:08:56블로그 게시물에서 알 수 있듯이,
00:08:58모든 토큰 사용량을 합산하고
00:09:03일반적인 API 가격으로
00:09:04계산해 보면,
00:09:08전체 포팅 비용이 약 16만 달러에 달했을 것이기 때문입니다.
00:09:13놀라운 액수지만, 사실,
00:09:18이 프로젝트의 규모를 생각해 보면,
00:09:20BUN의 SIG 코드 규모가 53만 5천 줄이었음을 감안할 때,
00:09:26그 규모와,
00:09:28인력이 직접 Rust로 포팅하는 데 걸릴 시간을 고려하면,
00:09:3216만 달러는 생각보다 나쁘지 않은 비용일지도 모릅니다.
00:09:36어디에 사느냐에 따라 다르겠지만요.
00:09:38그럼에도 불구하고, 어떤 오픈 소스 프로젝트도
00:09:43이걸 해내기는 어려울 겁니다.
00:09:44대부분의 기업들도 포팅에
00:09:47그만한 비용을 들이기는 힘들 것입니다.
00:09:50이게 가능했던 건 BUN이 Anthropic 소속이기 때문입니다.
00:09:54물론, 이는 Anthropic 입장에서
00:09:58훌륭한 마케팅 수단이기도 합니다.
00:09:59그게 주된 의도는 아니었을 수도 있겠죠.
00:10:03저는 알 수 없습니다.
00:10:04하지만 확실히 멋진 마케팅이죠.
00:10:06이런 점들을 항상 유념해야 합니다.
00:10:08어쨌든 블로그 게시물에서,
00:10:10우리는 Jared가 어떻게 그 포팅 작업을 수행했는지,
00:10:14즉, 어떻게 포팅을 성공시켰는지 알 수 있습니다.
00:10:18모든 것은 'porting.md' 파일에서 시작되었습니다.
00:10:21그는 Claude와의 대화를 통해 이 파일을 만들었는데,
00:10:25블로그에서 언급했듯이
00:10:263시간 동안 논의하면서,
00:10:28Claude Code 및 Anthropic 모델들과 협력하여
00:10:32결정했습니다.
00:10:35SIG를 Rust 코드로 번역하기 위해
00:10:37어떤 형태의 'porting.md' 파일이 필요한지 말이죠.
00:10:40그 후 반복적으로 수정하여 만족스러운 결과를 얻었고,
00:10:44처음에는 3개의 파일로 테스트를 진행했습니다.
00:10:46결과가 만족스러워지자,
00:10:48Claude를 전체 BUN 코드 베이스에 적용했습니다.
00:10:53이제 블로그 게시물에서,
00:10:54그는 단순히 Claude에게 BUN을 Rust로
00:10:57다시 작성하라고 명령한 게 아니라는 점을 분명히 합니다.
00:11:00오히려 정교한 시스템을 구축했죠.
00:11:03메인 에이전트 하나를 두고,
00:11:07서브 에이전트들도 구동하면서
00:11:09'porting.md' 파일에 따라 포팅을 진행했습니다.
00:11:13그런 다음 두 개의 적대적 검토 에이전트를 두어
00:11:16메인 에이전트의 작업이 완료되면 결과물을 검토하고
00:11:19피드백을 제공했습니다.
00:11:21그리고 수정 에이전트가 그 피드백을 적용하도록 했죠.
00:11:24이 모든 과정을 루프로 실행하고,
00:11:25당연히 여러 워크 트리에 분산시켜
00:11:30전체 코드 베이스를 처리하며
00:11:33작업을 이어나갔습니다.
00:11:35블로그 게시물에서,
00:11:35그는 Claude Code의 50개 동적 워크플로우를 사용해
00:11:38BUN을 Rust로 재작성했다고 언급했습니다.
00:11:40이 워크플로우들은 11일 동안 수많은
00:11:43서브 에이전트를 생성하는 방식입니다.
00:11:46관련해서 유용한 차트도 포함되어 있습니다.
00:11:48일반적으로 블로그 게시물에는
00:11:49이해를 돕는 멋진 그래픽들이 있어서,
00:11:51내용을 더 쉽게 파악할 수 있습니다.
00:11:53일자별로 생성되어 푸시된 커밋 양을 보여주며,
00:11:56시간대별 진행 상황도
00:11:58나타내고 있습니다.
00:12:00이 모든 과정은 Claude Code의 루프와,
00:12:04수많은 서브 에이전트의 도움,
00:12:05그리고 메인 에이전트, 검토 에이전트, 수정 에이전트의
00:12:08명확한 프로세스 덕분에 가능했습니다.
00:12:10또한 그는 별도의 경로를 통해
00:12:15모든 테스트가 작동하도록 만들었습니다.
00:12:20그 과정에서 자체적인 어려움도 따랐는데,
00:12:22테스트 스위트가 워낙 크고 복잡해서,
00:12:25다양한 인프라 제약에 부딪혔기 때문입니다.
00:12:29메모리를 많이 소모하는 테스트들이 있어,
00:12:31병렬로 여러 테스트를 실행하는 것이
00:12:33그래서 제대로 작동하지 않았죠.
00:12:34하지만 결국 AI의 도움을 받아 그 문제도 모두 해결했습니다.
00:12:39테스트를 실행하고, 코드를 수정하고,
00:12:42테스트를 다시 돌리는 식이었죠.
00:12:43정말 많은 반복 작업과 에이전트, 하위 에이전트들이 동원되었고,
00:12:47당연하게도 토큰도 엄청나게 소비되었습니다.
00:12:49토큰 비용으로만 16만 5천 달러가 들어간 셈이죠.
00:12:53물론 여러분도 직접 더 자세히 살펴볼 수 있고,
00:12:55그런 세부적인 내용에 관심이 있으시다면
00:12:57직접 확인해보시길 권해드립니다.
00:12:59그 과정이 잘 기록된 정말 훌륭한 블로그 게시물이거든요.
00:13:03아무튼 요약하자면, 11일 동안 포팅 작업이 어떻게 진행되었는지,
00:13:08여러 워크플로우에 걸쳐 얼마나 많은 에이전트와 하위 에이전트가 쓰였는지,
00:13:12그리고 11일이 넘는 기간 동안 50개의 워크플로우가 돌아갔다는 점,
00:13:17API 비용으로만 16만 5천 달러가 소모되었다는 사실을 알 수 있습니다.
00:13:24마지막으로, 블로그 게시물을 마치면서 그는,
00:13:29Bun 1.4가 이전 Zig 버전의 여러 버그를 수정했고,
00:13:35메모리 효율이 더 높으며 더 가볍다고 언급했습니다.
00:13:38Zig 제작자인 앤드류 켈리의 반응에서 알 수 있듯이,
00:13:43이러한 개선 사항 중 일부는 아마 Zig로도 충분히 가능했을지도 모릅니다.
00:13:47하지만 그 블로그 게시물은 수정된 이력이 있어 꽤 흥미롭습니다.
00:13:53처음보다 분노가 훨씬 덜 섞여 있거든요.
00:13:57첫 버전은 인신공격으로 가득 차 있었는데,
00:14:00그러고는 정작 자신은 인신공격할 의도가 없었다고 말하는 게 참...
00:14:03그렇지만 분명 인신공격 투성이었죠.
00:14:05아래에 링크해 드릴 최종 버전 역시 여전히 상당히 자극적입니다.
00:14:11결국 첫 번째 버전을 읽어보면 분명히 알 수 있듯이,
00:14:14이번 버전도 마찬가지지만,
00:14:16Zig의 제작자 앤드류와 Bun의 제작자 재러드는,
00:14:21이제 다시는 절친한 친구가 될 일은 없겠구나 싶습니다.
00:14:26그는 Bun이 Zig를 재정적으로 지원해 준 것에 고마워하면서도,
00:14:31Bun 코드가 제대로 된 Zig로 작성되었다면 이런 포팅은 전혀 필요 없었을 거라며 화를 내는 식이죠.
00:14:41그는 Bun 저장소의 Zig 버전 코드 품질이 좋지 않아
00:14:44많은 문제가 발생했다고 매우 명확하게 주장합니다.
00:14:48글쎄요, 그게 사실일 수도 있고 아닐 수도 있겠죠.
00:14:53저는 Bun 정도 규모의 프로젝트라면 충분히 그럴 수 있다고 봅니다.
00:14:56Bun처럼 아주 빠르게 발전하는 프로젝트에서는 말이죠.
00:15:01코드 품질이 Zig 제작자의 기준에는 못 미쳤을 수도 있습니다.
00:15:06사실 대부분의 코드 프로젝트가 최상의 코드 품질을 유지하는 건 아니라는 점을 감안하면,
00:15:12논란의 여지는 충분히 있을 겁니다.
00:15:15그러니 여러분도 각자 판단해 보시면 될 것 같아요.
00:15:18이제 이 얘기는 여기서 마무리하겠습니다.
00:15:21제 생각에 그 답변 블로그 게시물은 상당히 설득력이 떨어집니다.
00:15:24분노가 너무 강하게 묻어있거든요.
00:15:29물론 타당한 지적들도 있습니다.
00:15:33재러드가 블로그 게시물에서 언급했듯이,
00:15:35Zig에서 Rust로의 포팅이 검증되었다는 점은 맞죠.
00:15:40물론 리뷰어 에이전트들이 있었지만, 테스트 스위트를 돌려서 작동하게 만든 것도 사실이니까요.
00:15:46앤드류가 정확히 지적했듯, 그 동일한 테스트 스위트가
00:15:48Zig 버전의 우수성을 입증하는 데에도 충분했어야 하는 것 아니냐는 거죠.
00:15:51어쩌면 테스트 스위트 자체도 개선되었어야 했을지도 모릅니다.
00:15:56어쨌든 이 둘이 절친이 될 일은 없다는 건 분명해 보이네요.
00:16:00Zig와 Rust 중 어느 언어가 Bun에 더 적합한지에 대해서는 의견이 없습니다.
00:16:04다만, AI 시대에는 Rust의 메모리 모델과
00:16:09컴파일 타임에 메모리 관련 오류를 잡을 수 있다는 점이 엄청난 장점이라고 생각합니다.
00:16:17이번 전체 포팅 작업이 AI 활용 측면에서 정말 인상적인 것 또한 사실이니까요.
00:16:23물론 대부분의 회사가 감당할 수 있거나, 감당하고 싶어 하지 않을 방식일 수는 있습니다.
00:16:30하지만 이런 작업을 AI로 해냈다는 것 자체가 대단한 거죠.
00:16:38단순한 '바이브 코딩'이나 무작정 프롬프트를 날리는 수준이 아닙니다.
00:16:41그 뒤에는 명확한 프로세스가 있었죠.
00:16:45많은 고민이 녹아있고, 자세한 기술적 내용을 들여다보면 그 사실이 더 분명해집니다.
00:16:48철저한 계획과 반복 작업, 그리고 접근 방식까지,
00:16:52절대 프롬프트 하나 던져서 나온 결과물이 아니라는 겁니다.
00:16:56이런 작업 방식이 바로 AI로 할 수 있는 일의 본보기겠죠.
00:16:59코드베이스를 한 언어에서 다른 언어로 옮기는 것은 AI를 활용하기에 아주 좋은 사례입니다.
00:17:05생각해 보면 AI가 처음부터 코드를 작성하는 데는 어려움을 겪을 수 있어요.
00:17:08원하는 대로 코드를 작성하지 않거나 컨벤션을 따르지 않아서 일을 망칠 수도 있죠.
00:17:13물론 새로운 소프트웨어를 만드는 데도 AI는 정말 놀랍습니다.
00:17:17하지만 포팅 작업은 또 다른 문제에 직면하게 되죠.
00:17:21가장 큰 장점은 AI가 직접 참고할 수 있는 기존 코드베이스가 있다는 것,
00:17:27그리고 기존 테스트 스위트가 존재한다는 점입니다.
00:17:32기반으로 삼을 만한 것들이 아주 많다는 거죠.
00:17:36이 포팅 작업이 분명히 증명하듯이, AI 활용 사례로 아주 훌륭합니다.
00:17:40이번 사례에서 얻을 수 있는 가장 흥미로운 교훈이라고 생각해요.
00:17:43과거에는 불가능했던 프로젝트도 이제는 시도할 수 있게 되었다는 점입니다.
00:17:47물론 모든 기업을 위한 것은 아니겠지만, 규모가 있는 기업이라면 충분히 고려해 볼 만하죠.
00:17:53AI를 통한 레거시 소프트웨어 현대화가 아주 좋은 활용 사례가 될 수 있을 겁니다.
00:17:57이미 가능하다는 점이 이번에 입증되었으니까요.
00:17:59물론 Bun 1.4가 아직 정식 출시 전이라,
00:18:04한 달 뒤에 다 망해서 다시 예전으로 돌아가야 할 상황이 올지 지켜봐야겠죠.
00:18:08그럴 가능성을 완전히 배제할 수는 없겠지만, 제 생각엔 그러지 않을 것 같습니다.
00:18:12이미 Cloud Code CLI 같은 곳에서 초기 도입하여 프로덕션 환경에 사용 중이거든요.
00:18:13인간 리뷰어는 없었지만, AI를 통해 광범위하게 테스트되고 검토되었습니다.
00:18:18그래서 꽤 잘 해결될 것이라 확신합니다.
00:18:19정말 인상적인 성과이자 아주 훌륭한 AI 활용 방식이었다고 생각해요.
00:18:26물론 언제나 그렇듯, 이번 사례에 대해 여러분은 어떻게 생각하시는지도 궁금하네요.
00:18:30자, 오늘은 여기까지입니다.
00:18:32지금까지의 내용에 대해 어떻게 생각하시나요?
00:18:36댓글로 자유롭게 의견을 나눠주세요.
00:18:40이미 Cloud Code CLI와 같은 일부 얼리어답터들은 실무 환경에서 이를 사용하고 있죠.
00:18:47물론 사람이 아니라 AI가 검토한 것이긴 하지만, 광범위하게 테스트되고 검토를 거쳤습니다.
00:18:54그래도 저는 이게 잘 풀릴 거라고 꽤 확신하고, 정말 인상적인 성과이자 AI를 아주 인상적으로 활용한 사례라고 생각합니다.
00:19:03하지만 언제나 그렇듯, 여러분은 이 모든 것에 대해 어떻게 생각하시는지도 궁금합니다.