WEBVTT 00:03.360 --> 00:06.440 Rust 프로그래밍 언어에 대해 어떻게 생각하세요? 이건 좀 00:06.940 --> 00:10.400 밈이 된 주제죠. Kiran과 저는 의견이 많이 다릅니다. 저는 메모리 안전성이라는 00:10.900 --> 00:14.200 개념 측면에서 그들이 하는 일이 가치 있다고 생각합니다. 그런데 00:14.700 --> 00:17.840 어셈블리 수준의 속도를 달성할 수 있을까요? 00:18.080 --> 00:21.840 수작업 어셈블리는요? 아니요. 그건 당연한 거고, C는 가능할 수도 있지만 00:22.340 --> 00:26.000 저는 Rust에서 에스페란토 같은 느낌을 받아요. 00:26.500 --> 00:29.600 마치 "우리가 이걸 해결할 거야, 이런 방식으로"라는 00:29.760 --> 00:33.360 느낌이랄까요. 좀 지나치게 이상주의적이에요. 실제 문제를 해결하기보다 00:33.860 --> 00:37.440 자기 중요성에 집중하는 경향이 있어요. 저한테는 싱클레어 C5가 생각납니다. 00:37.940 --> 00:41.400 싱클레어 컴퓨터의 클라이브 싱클레어 경이 차를 만들면서 00:41.900 --> 00:45.200 "모두가 이 전기차를 타고 다닐 거야"라고 했는데 00:45.700 --> 00:49.200 Rust가 그런 느낌이에요. 커뮤니티가 00:49.700 --> 00:53.440 사람들을 움직이게 하려면 지금 있는 것만큼, 00:53.940 --> 00:57.080 아니면 그보다 더 나은 걸 만들어야 한다는 걸 00:57.580 --> 01:00.240 잘 이해하지 못하는 것 같아요. 01:01.040 --> 01:05.840 네, 사람들이 Rust로 재작성을 하고 있지만 01:06.340 --> 01:10.439 Core utils 같은 것들이 필요한 기능의 85~90%만 01:10.939 --> 01:14.760 구현된다면, 마지막 1%가 시간의 99%를 차지하죠. 01:15.260 --> 01:18.800 일론의 유명한 말처럼, 프로토타입은 쉽고 이런 건 쉽지만 01:19.300 --> 01:21.960 진짜 전기차를 만들려면 지금 있는 차만큼, 01:22.460 --> 01:24.480 아니면 더 나은 차를 만들어야 해요. 01:24.980 --> 01:28.320 Rust는 아직 그 단계가 아닙니다. FFmpeg에 01:28.820 --> 01:32.200 Rust 코드가 들어오는 걸 반대할 사람은 없겠지만 01:32.440 --> 01:35.720 동일한 수준으로 작동하고 같은 단위 테스트를 01:36.220 --> 01:39.480 지원해야 해요. 완벽해야 하고, 무작위로 망가지면 안 됩니다. 01:39.980 --> 01:42.600 마음대로 ABI를 바꿔서도 안 되고요. 01:43.400 --> 01:46.160 컴파일러 구현체도 아직 하나뿐인 걸로 알고 있는데, 01:46.660 --> 01:50.290 맞죠? 01:50.790 --> 01:54.210 지금 있는 것만큼, 아니면 더 나아야 하는데 01:54.710 --> 01:58.530 "여기 내 메모리 안전 유토피아가 있어요"라고만 해서는 충분하지 않아요. 01:59.030 --> 02:02.770 그게 목표라는 건 우리 모두 동의하더라도요. 02:03.270 --> 02:07.330 저는 Rust를 많이 써봤는데, 주요 경험이 두 가지였어요. 02:07.830 --> 02:11.290 하나는 VLC 안에 Rust 모듈을 추가하는 것이었는데, 02:11.790 --> 02:15.050 VLC가 인기를 얻은 이유 중 하나이자 핵심 아키텍처 결정은 02:15.550 --> 02:18.810 VLC가 매우 작은 코어와 수많은 모듈로 이루어져 있다는 것이에요. 02:19.310 --> 02:23.470 그래서 모듈을 C, Objective-C 등 02:23.970 --> 02:25.950 C와 상호운용 가능한 언어로 작성할 수 있죠. 02:26.910 --> 02:30.630 그래서 Rust 모듈도 만들어봤고 제가 직접 일부를 작성했어요. 02:31.130 --> 02:34.670 또한 제 새 스타트업인 Kyber는 02:35.170 --> 02:38.670 주로 Rust로 만들어진 오픈소스 프로젝트입니다. 02:40.670 --> 02:45.640 Rust는 메모리를 신경 쓰는 더 나은 C라는 점에서 02:46.140 --> 02:49.480 정말 훌륭하고, 다른 언어로는 할 수 없는 02:49.980 --> 02:53.480 메모리 소유권 관련 작업을 가능하게 해줘요. 02:53.640 --> 02:57.320 하지만 새 프로젝트를 처음부터 Rust로 시작할 때는 좋지만 02:57.820 --> 03:01.800 기존 코드와 연동할 때는 03:02.300 --> 03:05.600 매우 좋지 않아요. 03:06.100 --> 03:09.880 일부 Rust 커뮤니티는 모든 걸 Rust로 재작성하면 더 나아질 거라 믿는데 03:10.380 --> 03:13.760 답은 그렇지 않다는 거예요. 03:14.260 --> 03:18.000 제 수년간의 엔지니어, 매니저, 스타트업 CTO 경험상 03:18.500 --> 03:21.680 재작성하지 마세요. 03:21.840 --> 03:23.520 재작성하지 마세요. 03:24.960 --> 03:28.200 코드베이스에 처음 합류한 많은 사람들의 본능적 반응은, 03:28.700 --> 03:31.520 LLM 이전에는 특히, 03:32.400 --> 03:36.120 과거에 그렇게 구현된 지혜를 03:36.620 --> 03:38.600 이해하지 못하기 때문에 "재작성해야 해"라고 하는 거예요. 03:39.100 --> 03:42.520 그래서 수천 개의 JavaScript 프레임워크가 생겨난 거고요. 03:43.020 --> 03:46.200 이유는 매우 중요한데요, 03:46.700 --> 03:49.880 코드를 작성하는 것은 코드를 읽는 것보다 03:50.380 --> 03:54.280 훨씬 쉽기 때문입니다. LLM에서도 볼 수 있어요. 03:54.780 --> 03:58.000 코드 작성은 할 수 있지만 분석은 03:58.480 --> 04:01.360 훨씬 어렵거든요. 그래서 매우 복잡한 04:01.760 --> 04:04.920 코드에 접했을 때 04:05.420 --> 04:08.680 이해가 안 되는 거예요. 다른 사람의 코드를 이해하는 건 04:09.180 --> 04:12.360 사고 과정이 없기 때문에 훨씬 더 많은 노력이 필요하죠. 04:12.860 --> 04:17.500 제가 농담 삼아 Perl 같은 언어에 대해 이야기하는데, 04:18.000 --> 04:21.460 문법이 매우 복잡해서요. 04:21.960 --> 04:25.420 제가 프로그래밍에서 최고의 지적 능력을 발휘해서 04:25.660 --> 04:28.300 최고의 코드를 작성한다 해도 04:28.860 --> 04:32.460 6개월 후에는 제 자신도 이해 못 할 거예요. 04:32.780 --> 04:36.260 코드 읽기가 더 어렵기 때문입니다. 그래서 도착했을 때 04:36.760 --> 04:40.260 모든 지혜와 비즈니스 로직, 문서화되지 않은 04:40.760 --> 04:44.700 이유들을 이해하지 못하고 "내가 다시 쓸게"라고 하는 거예요. 04:45.200 --> 04:48.600 하지만 그렇게 하면 안 되죠. Kiran이 말했듯이 04:48.760 --> 04:52.200 coreutils를 Rust로 재작성하면 금방 80%에 도달하고 04:52.700 --> 04:56.760 90%는 조금 더 걸리고 나머지는 04:57.880 --> 05:01.480 반대편에서 더 오래 걸리죠. 그래서 05:01.720 --> 05:05.480 새 프로젝트에는 훌륭해요. 파일 파싱, 05:05.980 --> 05:08.600 네트워킹 관련은 메모리 검사기인 05:09.240 --> 05:12.480 빌림 검사기 덕분에 정말 훌륭해요. 05:12.980 --> 05:16.620 그 외에는 달리 할 말이 없어요. 05:17.120 --> 05:19.060 우리 경우는 좀 다른데요, 05:20.180 --> 05:24.140 Dav1d나 x264 같이 05:24.640 --> 05:28.180 어셈블리로 된 런타임이 많은 소프트웨어를 생각해보세요. 05:29.220 --> 05:32.260 C 부분을 Rust로 재작성하면 더 안전해지겠죠. 05:32.420 --> 05:35.820 하지만 어셈블리 부분에 도달하면 05:36.320 --> 05:39.380 수작업 어셈블리를 작성하기 때문에 메모리 어디든 접근할 수 있어요. 05:39.940 --> 05:43.850 그래서 보안을 위해 C 부분을 Rust로 재작성해도 05:44.350 --> 05:48.250 수작업 어셈블리를 쓰면 보안을 모두 05:48.570 --> 05:51.690 무너뜨리게 됩니다. 메모리 어디든 점프할 수 있으니까요. 05:52.250 --> 05:56.890 그래서 제 생각엔 안전한 어셈블리, 05:57.390 --> 06:01.170 즉 컴파일 타임에 어셈블리를 검사하는 것이 필요한데 06:01.670 --> 06:04.970 이게 바로 Videolan의 Dav1d와 x264에서 06:05.470 --> 06:10.980 진행 중인 checked assembly 프로젝트와 유사해요. 06:11.480 --> 06:14.780 컴파일 타임에 어셈블리를 계측해서 메모리 어디로든 점프하지 않는지 확인하는 거죠. 06:15.280 --> 06:19.020 그렇지 않으면 C 일부를 Rust로 재작성해도 06:19.520 --> 06:21.980 동일한 성능을 원한다면 인라인 어셈블리를 쓸 수밖에 없고 06:22.480 --> 06:25.980 그러면 전체 보안 모델이 무너지거든요. 이게 제가 06:26.480 --> 06:26.900 Rust에 대해 생각하는 바입니다.