https://www.youtube.com/watch?v=-cEn_83zRFw

Rails World 2024 Opening Keynote - David Heinemeier Hansson

[음악]

감사합니다.

다시 한번 환영합니다.

먼저 이 컨퍼런스를 훌륭하게 조직해준 아만다 피노와 전체 팀에게 감사의 말씀을 전하고 싶습니다.

내부에서 보기 전까지 이 컨퍼런스를 준비하는 데 얼마나 많은 노력이 필요한지 몰랐습니다.

이런 쇼를 준비하는 데 얼마나 많은 준비가 필요한지 정말 놀랍습니다.

아만다가 Rails 8 출시와 함께 날씨까지 맞추는 데 성공했다는 사실은 정말 환상적입니다.

아만다와 전체 팀에게 다시 한번 감사드립니다.

오늘의 주제는 Rails 8입니다.

Rails 8에 새롭게 추가된 멋진 기능, 라이브러리, 그리고 모든 것을 자세히 살펴보겠습니다.

Rails 8은 제 기억에 가장 흥미로운 Rails 릴리스 중 하나입니다.

이렇게 새로운 Rails 릴리스에 흥분한 것은 적어도 Rails 7 이후로 처음인 것 같습니다.

Rails 7이 프레임워크의 발전 방향과 세상을 향한 자신감에 대해 새로운 분위기를 조성했다고 생각하기 때문에 Rails 7에 대해 잠시 이야기하고 싶습니다.

한동안 우리는 세상의 다른 부분에서 신호를 받아 프론트엔드가 이 방향으로 움직이고 클라우드가 이 방향으로 움직이고 있다는 것을 깨닫고 그냥 따라가야 한다고 생각했습니다.

저는 그런 따라가는 느낌에 대해 점점 불안감을 느꼈습니다.

그 길을 따라가는 많은 부분이 제게는 말이 되지 않았고, 올바른 길이 아니라고 생각했지만, 아직 제대로 표현할 방법이 없었기 때문입니다.

그래서 몇 년 동안 우리가 더 잘할 수 있다는 생각이 점점 커졌습니다.

Webpacker를 통합했던 Rails 5 출시 때조차도 저는 이것이 우리가 해야 할 일이라고 생각했지만, 그렇게 흥분되는 일은 아니었습니다.

Rails 7은 그 흥분을 되살렸습니다.

오랫동안 커져 왔던 비전을 실현하고 앞으로 출시될 Rails가 그와 동일한 자신감을 따르고 그 자신감을 발전시킬 수 있는 로드맵을 제공할 수 있을 것 같은 기회가 마침내 생겼기 때문입니다.

그 흥분을 되살렸습니다.

제가 그 흥분을 안내하는 데 사용해 온 렌즈 중 하나는 패턴 언어라는 아이디어였습니다.

패턴 언어 템플릿에는 문제, 컨텍스트, 솔루션, 결과가 있습니다.

웹이 나아가는 방향에 대해 제가 좋아하지 않았던 모든 것을 살펴보니, 시대에 뒤떨어진 패턴, 가비지 컬렉션으로 표시되었지만 아직 수집되지 않은 패턴, 더 이상 우리가 발전시킬 수 있는 컨텍스트에서 관련성이 없는 패턴이었습니다.

Rails 7의 경우, 저에게 컨텍스트의 변화는 웹 기술의 근본적인 변화였습니다.

ES6 JavaScript가 브라우저에서 바로 트랜스파일링 없이 실제로 잘 작동하게 된 것입니다.

HTTP2 덕분에 항목을 큰 단위로 묶을 필요가 없어졌고, Import Maps 덕분에 브라우저용 최신 코드를 직접 작성할 수 있게 되었다는 사실도 있었습니다.

이제 이로 인해 패턴이 무효화되었다는 것이 제게는 매우 분명했습니다.

예전에는 브라우저에 4개의 연결을 열 수 있었고, 더 많은 연결을 열려면 하나씩 기다려야 했기 때문에 모든 것을 묶어야 한다는 패턴이 있었습니다.

브라우저가 JavaScript를 정말 못하지만, 우리에게는 더 좋은 아이디어가 있고, 그 아이디어를 더 나은 JavaScript로 트랜스파일하여 이러한 모든 발전에 힘을 실어줄 수 있다는 패턴도 있었습니다.

무효화된 컨텍스트, 그 아이디어는 더 이상 말이 되지 않았지만, 저는 소프트웨어 개발자로서 우리가 역사적으로 못하는 두 가지가 있다고 생각합니다.

하나는 이름 짓기이고, 다른 하나는 캐시 무효화입니다.

제가 가장 신경 쓰는 것은 정신 모델의 캐시 무효화입니다.

바로 여기에 지연이 발생한다고 생각합니다.

ES6, HTTP2, Import Maps가 없는 이 컨텍스트는 우리가 그 이점을 완전히 활용하기 몇 년 전에 발생했고, 사람들이 웹을 구축하는 방법은 길고 복잡하며 힘든 빌드 파이프라인을 갖는 것이라고 생각한 지 몇 년 후에 발생했습니다.

그런 다음 이 컨텍스트가 재발견되었고, 더 이상 말이 되지 않는 패턴이 많다는 것을 깨달았습니다.

Rails 7의 경우, 그 새로운 컨텍스트에 대한 답변의 일부는 Hotwire였습니다.

Hotwire는 백엔드와 함께 사용할 수 있는 새롭고, 더 간단하고, 겸손한 JavaScript 작성 방식입니다.

Hotwire는 그 새로운 컨텍스트에서 아름답게 작동하며 2024년에 적합한 패턴입니다.

2012년에 적합한 패턴이 아니었고, 우리가 더 단순한 곳에 도달할 수 있게 해준 복잡성의 정글을 통과하기 전에는 적합한 패턴이 아니었습니다.

항상 그랬듯이 Hotwire에 대한 작업과 오늘날의 패턴 중 어떤 것이 더 이상 관련성이 없는지 파악하는 작업은 추출을 통해 이루어졌습니다.

Rails 커뮤니티에서 우리는 추측에 근거한 프레임워크를 만드는 사업을 하는 것이 아니라, 실제 애플리케이션에서 실제 고객과 함께 실제 프로덕션 압력을 받으며 작동하는 것으로 입증된 솔루션을 가져와서 선물로 예쁘게 포장한 다음 공유하는 사업을 합니다.

이곳에서 우리가 하는 일입니다.

Hey에 대한 작업은 그 새로운 패턴을 발견하게 된 길이었고, 업계 전체가 틀렸다는 것을 확인하게 된 길이었습니다.

마치 "모두가 틀렸나?"라는 밈과 같습니다.

"아니, 아니야.

내가 틀렸나, 아니면 모두가 틀렸나?" "아니, 모두가 틀렸을 거야." 그것이 본질적으로 Rails 7의 프론트엔드 접근 방식의 전제였습니다.

모두가 틀렸고, 무거운 빌드 파이프라인을 받아들일 필요가 없고, 번들링을 받아들일 필요가 없고, 트리 쉐이킹을 받아들일 필요가 없고, 최신 웹 구축의 이러한 모든 전제를 사실로 받아들일 필요가 없습니다.

우리는 다른 이야기를 쓸 수 있고, 그것이 바로 우리가 한 일입니다.

흥미로운 점은 2018년에 Hey 작업을 시작했고 이러한 트렌드 중 일부가 다가오는 것을 보았지만 아직 준비가 되지 않았다는 것입니다.

2020년에 Hey를 출시했을 때도 아직 완전히 준비되지 않았습니다.

Hotwire를 중심으로 작업을 구성했지만 여전히 Webpack을 사용하고 있었던 것 같습니다.

이러한 아이디어를 완전히 실현하고 발전시키기까지는 사실 1년 정도 걸렸고, 실제로 어제까지 Hey의 모든 부분에 대해 빌드 없이 100% 완전히 구현할 수 없었습니다.

JavaScript에는 빌드 라인이 없고, CSS에는 빌드 파이프라인이 없습니다.

모든 것이 작성된 그대로 브라우저에 바로 제공됩니다.

이제 저에게 이렇게 하는 것의 이점은 이러한 패턴과 새로운 사고 방식을 실현할 수 있다는 개인적인 만족감뿐만 아니라, 이것이 가능한지에 대한 논의를 위한 반박할 수 없는 앵커 포인트를 제공한다는 것입니다.

인터넷에는 여러분이 하려는 일이 작동하지 않을 것이라고, 실제 세계에서는 작동하지 않을 것이라고, 실제 사용자에게는 작동하지 않을 것이라고, 실제 고객에게는 작동하지 않을 것이라고, 그들은 그냥 참지 않을 것이라고 말하는 사람들의 끝없는 불협화음이 있습니다.

그것을 반박하는 가장 좋은 방법은 논쟁을 벌이는 것이 아니라 작동하는 소프트웨어를 출시하는 것입니다.

일단 작동하는 소프트웨어를 출시하면 움직일 수 없는 논거를 위한 기념비가 생깁니다.

빌드 없이 작동하지 않는다고 주장할 수 있지만, 작동하지 않는다고 주장할 수는 없습니다.

우리는 그것이 작동한다는 것을 증명했습니다.

저는 Toby의 연례 트윗을 이 현상의 완벽한 구현체로 생각합니다.

20년 동안 사람들은 Rails가 확장되지 않는다고 말해 왔습니다.

작년 11월, Toby는 세계에서 가장 큰 Rails 앱에서 초당 100만 건의 요청을 처리하는 것에 대해 트윗했습니다.

이것은 "입 다물어!"라고 말하는 기념비입니다.

이 논쟁은 끝났고, 다시 이야기할 필요가 없습니다.

그냥 트윗을 보세요.

트윗이 기념비입니다.

그런 다음 우리에게는 실질적인 이점이 있습니다.

이것은 Hey의 JavaScript 로딩 방식입니다.

소스 맵도 없고 번들링도 없습니다.

작성된 그대로 브라우저에 바로 제공하고 있으며, 모든 것을 살펴볼 수 있습니다.

이제 저는 그것을 보면서 향수를 느낍니다.

제가 웹을 배운 방식이기 때문입니다.

최소화와 같은 장치를 생각해내기 전에 사람들이 웹을 어떻게 만들었는지 살펴보면서 웹을 배웠습니다.

오픈 웹에 가해진 잔혹 행위 중 하나인 최소화는 오버헤드를 2%, 5%만 줄일 수 있다면 새로운 사람들을 위한 학습 플랫폼으로서의 웹을 파괴할 가치가 있다는 전제를 취합니다.

절대 아닙니다.

우리는 오픈 웹에 엄청난 감사를 빚지고 있으며, 소스 보기를 허용함으로써 오픈 웹에 경의를 표할 수 있어야 합니다.

소스 보기에는 이것이 필요합니다.

트리 쉐이킹, 번들링 등을 사용하는 경우 소스 보기를 할 수 없습니다.

소스 맵핑 등으로 패치하려고 할 수도 있지만, 복잡성 위에 더 많은 복잡성을 쌓고 있는 것이고, 탑은 무너질 것입니다.

Rails 7용 빌드 없이 구현하는 데 관심을 갖게 된 초기 계기는 제가 너무나 부주의하게 약 5분 동안 방치했던 JavaScript 프로젝트를 컴파일할 수 없다는 사실에 짜증이 났기 때문입니다.

어떤 도구도 작동하지 않았고, 모든 것이 오래되었습니다.

다시 컴파일할 수 있도록 업데이트하려고 했을 때 말 그대로 방법을 알 수 없었습니다.

당시 Webpacker와 씨름하느라 반나절을 보냈고, 말 그대로 테이블을 뒤집었습니다.

"아니, Webpacker를 Rails에 통합한 사람이 바로 나인데, 이게 어떻게 작동하는지 알 수가 없어.

아니, 아니야.

이 모델에는 근본적으로 잘못된 부분이 있어."라고 말했습니다.

그때 저는 진실을 깨달았습니다.

진실은 브라우저만이 영원하다는 것입니다.

브라우저만이 우리가 30년 전에 만든 코드, 마크업, 스타일을 수정 없이 불평 없이 실행할 수 있게 해줍니다.

그것이 바로 최신 브라우저의 아름다움입니다.

최신 브라우저는 복잡성의 괴물이며, 오늘날 처음부터 브라우저를 구현하려는 것은 제 가장 큰 적에게도 바라지 않을 것입니다.

하지만 웹 개발자로서 우리 모두가 브라우저가 이렇게 좋아지고 이전 버전과의 호환성에 대한 헌신으로 인해 얻는 이점은 놀랍습니다.

놀랍습니다.

1995년에 디자인한 것이 오늘날에도 여전히 그대로 보이고 여전히 가장 큰 웹사이트 중 하나라는 아이디어는 놀랍습니다.

이것은 Craigslist입니다.

1995년에 출시된 디자인을 조금도 바꾸지 않았다고 생각하지만 여전히 작동합니다.

여전히 작동할 뿐만 아니라 여전히 번창하고 있습니다.

소프트웨어 개발에서 그 정도의 수명은 우리가 열망해야 할 무언가입니다.

영감은 브라우저를 통해 바로 전달되고, 브라우저가 우리가 가진 모든 코드의 런타임이라는 진실을 통해 전달된다고 생각합니다.

우리와 브라우저 사이의 중개자를 제거할수록 더 좋고, 5분 후에도 실행될 코드를 가질 가능성이 더 높습니다.

그러나 Rails Doctrine에서 바로 가져온 또 다른 원칙은 우리가 큰 텐트를 밀고 있다는 아이디어입니다.

Rails 7로 할 수 있었던 일에 대해 엄청나게 흥분했습니다.

37signals에서 작성하는 모든 코드는 빌드 없이 구현됩니다.

Hey 이후로 만든 모든 애플리케이션은 어떤 형태의 JavaScript 컴파일도 없이, 어떤 형태의 CSS 파이프라이닝도 없이 구축되었습니다.

놀랍습니다.

모든 사람을 위한 것은 아니고, 모든 사람을 위한 것이 될 필요도 없습니다.

제가 추진하는 아이디어는 최신 웹 애플리케이션을 만드는 데 필요한 모든 것에 대한 사전 지식이 거의 없는 사람이라도 누구나 쉽게 시작할 수 있는 원퍼슨 프레임워크를 만드는 더 큰 임무와 연결됩니다.

저만의 즐거움을 위해서뿐만 아니라 그 임무를 위해서도 노력하고 있습니다.

하지만 그것은 명령이 아닙니다.

Rails가 Hello World에서 IPO까지 번창할 수 있었던 이유 중 하나는 사람들이 원하는 부분을 선택할 수 있는 유연성입니다.

사실 그렇지 않습니다.

모든 것을 선택할 수 있고, 다른 방식으로 하고 싶은 부분은 선택하지 않을 수 있습니다.

그것은 훌륭한 일입니다.

React부터 무엇이든 모든 것을 사용하여 구축된 애플리케이션이 많이 있으며, 그것은 훌륭한 일이고, Rails 7로 해결할 수 있었던 경로가 마음에 듭니다.

하지만 근본적으로 제가 여전히 여기에 있는 이유, 20년이 지난 지금도 첫날만큼이나 열정을 느낄 수 있는 이유는 우리가 더 큰 임무를 향해 나아가고 있기 때문입니다.

원퍼슨 프레임워크라는 더 큰 임무, 컨텍스트가 더 이상 관련성이 없는 패턴을 무효화하는 더 큰 임무, 그것이 바로 제가 열정을 느끼는 이유입니다.

얼마 전에 이 다음 내용을 트윗했는데, Matt이 RSW에 있다는 것을 기념하여 하이쿠로 다시 써 보았습니다.

"발전은 우리의 길, 복잡성은 다리를 놓고, 단순함은 기다린다." 하이쿠 형태이든 아니든, 이 감정에서 제가 좋아하는 부분은 복잡성이 실제로 발전에 필요한 요소라는 아이디어입니다.

하지만 그것이 우리가 멈추는 곳은 아닙니다.

우리는 그것을 해결했다고 해서 끝난 것이 아니라 단순하게 만들었다고 해서 끝난 것입니다.

언제 멈추고 언제 흥분해야 하는지에 대한 매우 다른 철학이며, Rails를 포함하여 앞으로 모든 일에 적용하려고 노력하는 철학입니다.

이것은 배당금입니다.

본질적으로 Rails 7의 정신을 요약한 것입니다.

브라우저에 의존하세요.

최신 브라우저만 있으면 이 좋은 것들의 풍요를 누릴 수 있습니다.

특히 지난 3~4년 동안 이루어진 모든 발전 덕분에 웹 개발자가 되는 것이 훨씬 더 좋아졌고, 불필요한 도구 없이 훨씬 더 재미있어졌습니다.

그리고 우리는 "이 애플리케이션은 최신 브라우저용입니다."라고 말함으로써 그 모든 것을 요약할 수 있습니다.

이제 모든 애플리케이션에 대해 그렇게 할 수는 없습니다.

일부 애플리케이션은 더 오래된 브라우저를 지원해야 하지만, 많은 애플리케이션에 대해 그렇게 할 수 있고, 오늘날 새로운 애플리케이션을 시작한다면 반드시 그렇게 해야 합니다.

여기에는 더 큰 목적이 있습니다.

목적은 단순히 최고의 패턴을 찾는 것이 아니고, 단순함 자체를 위해 단순함을 추구하는 것이 아닙니다.

비록 단순함 자체가 선물이기는 하지만요.

목적은 우리의 제한된 원숭이 두뇌에 맞게 최적화하는 것입니다.

우리의 두뇌는 그렇게 많은 것을 담을 수 없고, 복잡한 빌드 파이프라인의 복잡한 부분을 배우는 데 모든 것을 사용한다면 다른 것을 담을 공간이 많지 않습니다.

제가 공간을 만들고 싶은 것은 바로 그 모든 것입니다.

전체 문제와 전체 솔루션을 보고 가능한 한 오랫동안 머릿속에 담아둘 수 있는 풀스택 개발자를 위한 공간을 만들고 싶습니다.

결국에는 불가능할 것입니다.

Shopify가 주요 모놀리스에 가지고 있는 500만 줄의 코드를 누군가가 동시에 머릿속에 담아둘 수 있다고는 생각하지 않습니다.

하지만 Toby가 오랫동안 그렇게 많은 코드를 머릿속에 담아둘 수 있었던 덕분에 우리는 거기에 도달할 수 있었고, 그것이 바로 우리가 이러한 논의에서 우회하는 방식입니다.

사람들은 "처음에는 좋지만, 하루에 수십억 달러를 벌게 되면 어떻게 할 거야?"라고 말합니다.

무슨 말씀이신지? 어떻게 할 거냐니? 무슨 일이 있어도 할 수 있는 일을 할 겁니다.

왜냐하면 그건 중요하지 않기 때문입니다.

그때쯤이면 세상의 모든 돈을 가지고 있을 텐데, 그것이 최적화해야 할 문제가 아닙니다.

최적화해야 할 문제는 어떻게 하면 수십억 달러를 벌 수 있을까 하는 것입니다.

그것이 바로 길입니다.

"아, 일단 돈을 벌면 약간 불편해질 거야."가 아닙니다.

아닙니다.

그리고 저에게 그 문제를 살펴보는 가장 좋은 방법은 최신 웹 개발 경험의 이러한 모든 부분을 서로 옆에 놓을 수 있는 작은 단위로 압축하여 우리의 두뇌 예산을 살펴보는 것입니다.

그래야 모든 것을 담을 수 있습니다.

최근에 좋은 교훈을 얻었습니다.

Vim을 다시 시작했는데, Vim은 여러분의 뇌 공간을 많이 차지하는 재미있는 것들 중 하나이고, 다른 것을 담을 수 있도록 압축할 방법을 찾아야 합니다.

Jason의 이름을 포함해서요.

사실 Jason은 제가 사업 파트너인데 Jarvis라고 부르면 약간 기분 나빠할 것 같습니다.

하지만 우리에게는 제한된 공간이 있고, 그 공간을 최대한 활용해야 하고, 업계를 작은 전문 분야로 세분화할 필요가 없도록 공간에 있는 것을 압축해야 한다는 아이디어입니다.

특정 규모에서는 그렇게 합니다.

그것이 바로 10억 달러짜리 문제입니다.

0에서 1까지의 문제가 아닙니다.

0에서 1까지의 문제는 어떻게 하면 모든 것을 이해할 수 있을까 하는 것입니다.

그것이 바로 우리의 임무입니다.

웹사이트의 헤드라인은 말 그대로 "최신 웹 앱의 복잡성을 압축"하는 것입니다.

하지만 더 중요한 것은 Hello World에서 시작하여 처음부터 IPO까지 갈 수 있게 해준다는 것입니다.

그것이 바로 오늘 제가 이야기할 내용입니다.

Hello World도 아니고 IPO도 아닌 그 사이의 공간에 대한 두 부분입니다.

Rails 7을 통해 Hello World를 만들기 위한 놀라운 프레임워크를 갖게 되었다고 생각합니다.

우리에게 부족한 것은 IPO로 가는 다리이고, 그 다리의 첫 번째 단계는 배포입니다.

프로덕션으로 가는 것입니다.

컴퓨터에서 실행되는 애플리케이션을 가져와서 전 세계 사람들과 공유할 수 있도록 월드 와이드 웹에 배치하는 것입니다.

지난 10년 동안 제 경험에서 일어난 일은 배포와 관련하여 우리 모두가 학습된 무력감이라는 작은 밧줄에 묶인 분홍색 코끼리가 되었다는 것입니다.

업계 전체가 서버를 만지는 것에 대한 두려움, 컴퓨터에 대한 책임을 지는 것에 대한 두려움을 키워 왔습니다.

제가 Dr.

Evil 모자를 쓰고 있을 때는 "놀랍군.

해냈어.

프로그래머들에게 컴퓨터가 너무 어려워서 직접 만지면 안 된다고 설득했어.

브라보, 브라보.

그건 현대 마케팅의 위업이야.

그 앞에 절을 해야겠어."라고 말합니다.

하지만 또 한편으로는 한심합니다.

우리가 코끼리입니다.

밧줄이 얼마나 작은지 보이시나요? 코끼리가 얼마나 무거운지 아시나요? 밧줄을 없애려면 발을 얼마나 조금만 움직여야 하는지 아시나요? 아주 조금만 움직이면 됩니다.

이제 문제는 부분적으로...

이 담론이 얼마나 발전했는지 정말 놀랍습니다.

농담을 할 필요도 없습니다.

문제는...

사실 저는 반대로 할 겁니다.

아직은 그들을 놀리지 않을 겁니다.

AWS는 놀랍고, "우리 인간은 이런 일을 할 수 있어.

우리 인간은 서버 원숭이 군대 전체를 API 뒤에 배치할 수 있고, 그들은 정말 빠르게 실행할 수 있고, 물건을 랙에 넣을 수 있고, 여러분이 보는 것은 200 OK뿐이야."라는 식으로 놀랍습니다.

아마존이 실제로 자체적으로 매우 현실적인 문제를 해결할 수 있었다는 것은 매우 멋진 일입니다.

연중 특정일에 사용량이 급증했고, 그런 다음 컴퓨터가 모두 필요하지 않은 날이 많았습니다.

좋은 컨텍스트에 대한 좋은 솔루션입니다.

저는 그 비전을 전적으로 지지합니다.

문제는 우리 대부분이 그런 컨텍스트에서 살지 않는다는 것입니다.

대부분의 애플리케이션은 대부분의 시간 동안 API 뒤에 서버 원숭이를 끊임없이 배치해야 하는 문제가 없습니다.

그리고 만약을 대비한 보험 정책에 대해 우리가 지불하는 대가는 엄청나게 높습니다.

금전적으로뿐만 아니라 복잡성 측면에서도 그렇습니다.

게다가 AWS는 사업입니다.

저는 사업이 훌륭하다고 생각하지만, 사업에는 인센티브가 있다고도 생각합니다.

그리고 AWS의 인센티브는 여러분이 영원히 분홍색 코끼리로 남는 것입니다.

영원히 서버를 두려워하고, 영원히 스스로 서버를 실행하는 것을 두려워하는 것입니다.

아닙니다.

우리는 조커가 이기도록 내버려 두지 않을 것입니다.

우리는 그들이 서버가 너무 어려워서 AWS에 40%의 마진을 지불해야 한다고 우리를 설득하도록 내버려 두지 않을 것입니다.

아닙니다.

실제로 컴퓨터를 만드는 Dell의 마진은 5%이고, AWS의 마진은 40%입니다.

그것은 실패한 시장이고, 경쟁 압력에 의해 초과 이윤이 도전받지 않는 비경쟁적인 시장입니다.

우리는 그 문제에 대해 뭔가를 할 것입니다.

하지만 그 전에...

Heroku는 제가 20년 동안 봐 온 개발자 인체 공학 분야에서 가장 큰 혁신 중 하나입니다.

우리 대부분이 컨테이너가 무엇인지, 이런 식으로 머신을 활용하는 방법에 대한 광범위한 개념조차 갖기 전인 2007년에 Heroku가 나왔다는 사실은 정말 놀랍습니다.

그리고 Heroku가 배포를 git push로 줄일 수 있다는 아이디어를 다른 누구도 깨닫기 전에 10년 넘게 그 이점을 누릴 수 있었다는 사실은 정말 놀랍습니다.

Heroku는 그들이 이룬 업적, Hello World에서 LMA 온라인까지 갈 수 있도록 도운 Rails 개발자의 수에 대해 끝없는 찬사를 받을 만합니다.

그것은 놀라운 업적이며, 17년 전의 일이기도 합니다.

17년 전의 일이라는 것이 정말 놀랍습니다.

이제서야 우리는 따라잡아야 한다고 생각하기 시작했습니다.

문제는 부분적으로 17년 동안 컨텍스트가 바뀌었다는 것입니다.

Heroku 성능 메뉴입니다.

호화로운 1코어, 2, 3스레드, 2.5GB RAM을 월 250달러라는 저렴한 가격에 구입할 수 있습니다.

2012년에는 꽤 괜찮았을 겁니다.

좋은 거래였을 겁니다.

2024년에는 말도 안 됩니다.

터무니없고 모욕적입니다.

이것은 몇 주 전에 Hetzner에서 가입한 호피 박스입니다.

Hetzner에서는 원시 하드웨어를 구입하면 40코어, 96스레드, 256GB RAM을 월 220달러에 얻을 수 있습니다.

이 두 가지의 차이점은 무엇일까요? 소프트웨어입니다.

Heroku는 좋은 소프트웨어를 가지고 있습니다.

저는 소프트웨어를 만듭니다.

저도 좋은 소프트웨어를 만들 수 있다고 생각합니다.

2TB NVMe RAID 스토리지까지 제공한다면 꽤 좋은 거래입니다.

그것이 바로 조커입니다.

조커는 사람들이 기본적으로 컴퓨터를 만질 수 없다고 설득할 수 있다면 100배의 요금을 청구할 수 있습니다.

그들이 뭘 할 수 있겠어요? Linux를 만질 수 있겠어요? 그런 비즈니스 모델은 개발자 기술의 많은 부분에 스며들었고, 저는 그것이 마음에 들지 않습니다.

이것은 제 밈이 아니지만, 100배의 이윤을 깨닫고 컴퓨터를 살 필요도 없이 아마존에서 빌려서 100배의 가격에 여러분에게 빌려주는 사람들이 늘어나는 것은 당연합니다.

정말 좋은 비즈니스 모델입니다.

VC들도 그렇게 말하고 있습니다.

이것은 성장 기회입니다.

개발자의 불안감은 대량 시장입니다.

그것을 활용합시다.

그리고 그 스로틀은 바닥까지 밀렸고, 저는 그것이 마음에 들지 않습니다.

저는 기업이 새로운 것을 발견하는 것을 좋아하고, 그 아이디어에 투자가 흘러 들어가는 것을 좋아하고, 새로운 개념이 개발되는 것을 좋아하지만, 어느 시점부터는 그 프리미엄을 영원히 지불하지 않을 것입니다.

이제 저는 소프트웨어 특허를 도덕적으로 혐오합니다.

소프트웨어 특허는 절대적으로 어리석고 부식성이 있다고 생각합니다.

저는 그 생각을 의료 특허를 좋아한다는 생각과 함께 머릿속에 담아두고 있습니다.

실제로 우리가 시장에 내놓는 약은 여러 번의 시험을 거쳐 테스트해야 한다는 것이 합리적이라고 생각합니다.

그것은 비용이 많이 들고, 약 10억 달러 정도 들며, 누군가가 그 10억 달러를 회수할 수 있어야 우리가 이제 덴마크 경제의 약 20%를 차지하는 오젬픽과 같은 놀라운 약을 얻을 수 있습니다.

그래서 덴마크 복지 국가에 자금을 지원하고 있는 약간 과체중인 미국인들에게 감사드립니다.

하지만 저는 의료계에서도 만료 날짜가 있어야 한다고 생각합니다.

의료계에서 만료 날짜는 20년입니다.

20년 후에는 특허가 만료됩니다.

그리고 제네릭...

저는 그것을 보고 "사실 나쁘지 않은 모델이야.

마음에 들어."라고 생각합니다.

Heroku가 배포를 위한 개발자 인체 공학 분야의 초기 진출을 상업화할 수 있었던 것은 훌륭한 일입니다.

하지만 우리는 제네릭이 나올 때가 되었습니다.

배포를 위한 치료제가 형편없는 컴퓨팅 성능에 250달러가 들지 않는 제네릭이 나올 때가 되었습니다.

우리는 제네릭을 통해, 오픈 소스를 통해 그것을 만들 수 있습니다.

왜냐하면 우리가 업계를 스스로 구할 수 있다고 생각하기 때문입니다.

왜냐하면 어느 시점에서 기회가 너무나 터무니없고 누군가가 나서서 그 기회를 이용하기만 기다리고 있다면, 이 사람이 나타날 것이고, 여러분은 그를 좋아하지 않을 것입니다.

그는 DataPrizm의 가격을 100배가 아니라 50배로 올렸을 뿐입니다.

그 점을 기억하세요.

그가 왜 여기 있는지 모르겠습니다.

여기 임무가 있습니다.

여기 가능한 것이 있습니다.

패스 없음, 빌드 없음, 패스 없음, 빌드 없음, 패스 없음, 플랫폼형 서비스가 필요 없습니다.

Rails는 지금뿐만 아니라 앞으로도 합리적이고 접근하기 쉬운 방식으로 프로덕션에 갈 수 있도록 상용 공급업체에 비용을 지불할 필요가 없는 프레임워크가 될 것입니다.

그것이 바로 Rails의 임무입니다.

세상의 패스가 사소한 사용 사례를 위한 선택적 추가 기능이 되는 곳까지 우리를 데려가는 것입니다.

주요 경로는 클라우드, 베어 메탈, 개인 컴퓨터, 옷장 속의 Pi 등 어떤 구성이든, 어떤 하드웨어든 선택한 하드웨어에 직접 애플리케이션을 배포하는 것입니다.

그것이 바로 우리가 할 일입니다.

하지만 먼저 클라우드가 우리에게 너무나 교묘하게 감염시킨 서버 공포증이라는 문제로 돌아가야 합니다.

서버는 징그럽고 만지고 싶지 않고, 누군가 나 대신 책임져줬으면 좋겠다는 생각입니다.

아닙니다.

그 전제를 받아들이지 마세요.

왜냐하면 치료법이 있기 때문입니다.

서버 공포증을 극복할 수 있습니다.

그것은 바로 Linux입니다.

Linux라고 합니다.

Linux는 우리의 모든 서버를 실제로 실행할 뿐만 아니라, 원한다면 컴퓨터에서도 실행할 수 있습니다.

그리고 저는 여러분이 그렇게 해야 한다고 생각합니다.

풀타임으로 실행하고 싶든 아니든 상관없습니다.

이것은 인지 행동 치료입니다.

한 번에 조금씩 노출합니다.

여기에 바로 실행 중인 Framework 13이 있습니다.

나중에 와서 만져보세요.

Linux를 실행하더라도 물지 않습니다.

그리고 사실 저는 여러분이 다른 것을 시도해보는 연습으로라도 해봐야 한다고 생각합니다.

그 목적으로 저는 제가 가장 좋아하는 Linux 환경을 만들었고, 여러분과 공유하고 있습니다.

Elmacoup는 무서운 Linux 머신을 가져와서 바로 사용할 수 있는 편안하고 생산적이며 멋지게 보이는 Linux 설정으로 바꾸는 프로젝트입니다.

그리고 이 훌륭한 Linux를 발견하면서 저처럼 새로운 것을 찾을 수도 있습니다.

그 중 하나는 새로운 편집기일 수 있습니다.

드디어 Vim이 여러분에게 딱 맞는다고 생각할 수도 있습니다.

새로운 컴퓨터를 좋아할 수도 있습니다.

저는 말 그대로 20년 동안 앞면에 작은 사과가 없는 컴퓨터를 살 생각이 없었는데, 그 몽롱함에서 벗어나서 다른 사람들도 멋진 것을 만들고 있다는 것을 깨달았습니다.

누가 알았겠어요? 그리고 저에게 Framework는 그 좋은 예입니다.

Framework는 실제로 여기 있습니다.

제 컴퓨터에서 실행하고 있는데 Elmacoup와 아름답게 작동합니다.

그냥 초대일 뿐입니다.

이제 여러분이 무슨 생각을 하는지 알겠습니다.

해커는 어떻게 하죠? 해커가 저를 공격할 거예요.

그건 분홍색 코끼리가 하는 말입니다.

분홍색 코끼리의 말을 들을 필요가 없습니다.

분홍색 코끼리에서 벗어나 다른 무언가로 성장할 수 있습니다.

그 다른 무언가는 개도 아닙니다.

이 개가 아닙니다.

여러분이 될 개가 아닙니다.

아닙니다.

이것은 Linux를 시작한 첫날의 여러분입니다.

이것은 Linux를 시작한 지 21일째의 저입니다.

하지만 영원히 지속되지는 않았습니다.

왜냐하면 결국에는 이해하게 될 것이고, 결국에는 레벨업하게 될 것이기 때문입니다.

그것이 바로 우리가 열망하는 것이고, 특히 보안과 관련해서는 더욱 그렇습니다.

이것은 제가 정말 좌절하는 부분 중 하나입니다.

서버 보안을 강화하는 요령은 다음과 같습니다.

SSH 키를 서버에 넣고 SSH 키가 서버에 인증할 수 있는 유일한 방법이 되도록 하고 방화벽의 멋진 UI를 시작하면 끝입니다.

완전히 끝난 것은 아니지만 90%는 끝났습니다.

서버 보안의 90%는 잠그는 것과 같습니다.

문을 열어두지 마세요.

문이 잠겨 있으면 해커가 와서 손잡이를 흔들 수는 있지만 들어오지는 못합니다.

이 모든 것은 유능한 것이 더 재미있다는 사실의 구현일 뿐입니다.

무슨 일이 일어나고 있는지 아는 것이 더 재미있고, 애플리케이션이 살고 있는 곳이기 때문에 Linux를 아는 것이 더 재미있고, 유능한 것이 더 재미있습니다.

이제 여러분이 우디처럼 느껴질 수도 있다는 것을 압니다.

하지만 우리는 무한대로 나아갈 것이고, 그것이 바로 제가 8을 정말 좋아하는 이유입니다.

8을 옆으로 돌리면 무한대가 됩니다.

이것은 옆으로 돌린 8입니다.

그럼 Rails 8에 대해 알아보고 임무를 수행하는 멋진 기능들에 대해 이야기해 보겠습니다.

Rails 8의 첫 번째 기능은 정말 기쁩니다.

잠깐만요.

무엇이 올지 모르시죠? 모르시죠? 먹고 싶지 않은 약이지만 몸에 좋은 약과 같은 것입니다.

Rails 8은 Devise와 함께 제공되지 않습니다.

보안 블랙박스와 함께 제공되지 않습니다.

무슨 일이 일어나고 있는지 배우는 길로 안내할 것입니다.

그 방법은 생성을 통한 인증을 구현하는 것입니다.

실제로 코드를 보고 이해해야 합니다.

그리고 사용자를 인증하는 것이 분홍색 코끼리가 될 만한 가치가 없다는 것을 깨달아야 합니다.

다른 사람에게 돈을 주고 할 만한 가치는 더더욱 없습니다.

안전한 비밀번호의 기본 사항을 이해해야 합니다.

그렇게 어렵지 않고 말 그대로 배울 수 있습니다.

이것이 바로 생성할 때 생성되는 모든 파일이고, 90% 인증 시스템을 얻게 됩니다.

파일을 살펴볼 수 있고, 파일이 아름답습니다.

왜냐하면 제가 여러분을 위해 정성스럽게 만들었기 때문입니다.

이것은 제가 모든 문자에 세심한 주의를 기울여 만든 장인 정신이 담긴 템플릿이므로 작업하기 좋은 시작점입니다.

이것은 본질적으로 추출입니다.

저는 이 인증 시스템을 우리 자신의 애플리케이션에서 가져왔습니다.

이것이 바로 우리가 모든 불필요한 것 없이 인증 시스템을 작성하는 방법이며, 여러분은 그것을 배우고 레벨업할 수 있습니다.

그것이 바로 우리가 여기서 하는 일입니다.

첫날에는 여러분이 개입니다.

뭐가 뭔지 모릅니다.

괜찮습니다.

여기 와주셔서 기쁩니다.

영원히 그 개로 남도록 내버려 두지 않을 것입니다.

여러분에게 무언가를 가르쳐 줄 것이고, Rails를 한동안 사용하고 나면 더 많은 것을 알게 될 것입니다.

그것이 바로 인증입니다.

전체 주제와는 별로 관련이 없지만 제가 정말 자랑스럽게 생각하는 또 다른 것은 Propshaft입니다.

Propshaft는 단순화의 부수적인 이점 중 하나입니다.

Rails 7에서 HTTP2, 번들링 없음, 트랜스파일링 없음이라는 최신 스택을 수용하기로 했을 때, 2009년부터 존재했던 애셋 파이프라인(JavaScript 번들링이 본격적으로 시작되기도 전)이 시대에 뒤떨어지고 지나치게 복잡하다는 것을 깨달았습니다.

Propshaft는 빈 종이에 대한 아름다운 순간 중 하나이며, 나머지 프레젠테이션에서도 이어지는 주제입니다.

이전의 짐을 짊어지지 않고 오늘날의 컨텍스트에 맞게 솔루션을 제시하는 빈 종이입니다.

Propshaft는 아름답고, 제가 직접 작성했기 때문에 압니다.

정말 멋지고, 여기 있는 모든 코드를 읽을 필요는 없지만 새 프로젝트를 시작한 후 bundle open propshaft를 실행하여 코드를 살펴볼 수 있습니다.

이해할 수 있을 것이라고 장담합니다.

Sprockets에서도 똑같은 작업을 수행하면 아무것도 이해할 수 없을 것이라고 장담합니다.

저도 이해하지 못하기 때문입니다.

그래서 Sprockets가 아니라 Propshaft를 작성했습니다.

Propshaft는 최신 브라우저의 모든 이점을 활용하여 코드를 직접 사용자에게 제공할 수 있다는 점을 고려했을 때 남은 것은 로드 경로가 필요하고 먼 미래를 위해 애셋을 다이제스트해야 한다는 것입니다.

그것이 전부입니다.

우리가 하는 일은 그것뿐입니다.

상자 안에는 아무것도 없기 때문에 상자는 매우 작고 이해하기 쉽고 문제가 거의 없습니다.

하지만 더 광범위한 비전의 요점은 최신 웹 애플리케이션에는 이전에는 수많은 데이터 저장소가 필요했다는 것입니다.

큐를 실행할 무언가가 필요했고, 캐시를 저장할 무언가가 필요했고, 웹 소켓 업데이트를 라우팅할 무언가가 필요했습니다.

하지만 이제는 그럴 필요가 없습니다.

왜냐하면 그 모든 것을 하나의 데이터베이스, 적어도 오늘날의 데이터베이스는 너무 빨라서 대부분의 작업에 RAM이 필요하지 않고, 우리는 그 이점을 최대한 활용해야 하기 때문입니다.

그리고 Rails 8에는...

Rails 8에는 Solid라는 데이터베이스 지원 어댑터 3인방을 도입했습니다.

데이터베이스를 통해 웹 소켓 통신을 지원하는 Solid Cable, 데이터베이스에 캐싱을 저장하는 Solid Cache, 작업을 실행하는 Solid Queue가 있습니다.

그리고 이 모든 것이 하나의 반지, 하나의 데이터베이스 시스템, 하나의 학습 대상, 하나의 운영 대상에서 실행됩니다.

그리고 그보다 더 좋은 것은...

디자인에 포함되지도 않았지만 도중에 생겨난 SQLite 덕분에 데이터베이스 시스템에서 시스템을 제거할 수도 있었습니다.

더 이상 운영할 프로세스가 없고, 직접 사용하는 파일 모음일 뿐입니다.

Hello World에서 온라인으로 전환하는 것을 더 쉽게 만들려는 우리의 임무에 놀라운 도움이 됩니다.

데이터베이스를 설정하는 방법을 알 필요조차 없습니다.

파일 시스템의 파일일 뿐입니다.

그래서 새로운 Rails 8 애플리케이션을 시작하면 이렇게 보입니다.

실제로 SQLite용 데이터베이스 파일이 4개 생깁니다.

모든 도메인 모델이 있는 기본 데이터베이스용 파일 1개, 캐싱용 파일 1개, 큐잉용 파일 1개, 케이블용 파일 1개입니다.

그리고 온라인으로 전환하기 위해 이 파일을 열 필요조차 없습니다.

SQLite의 놀라운 기능 덕분에 이 모든 것이 어떻게 구성되어 있는지 알 필요조차 없습니다.

첫 번째는 앞서 언급한 Solid Cable입니다.

Solid Cable은 약 2주 전에 이 강연을 준비하면서 생겨난 추출물 중 하나입니다.

데모를 진행하면서 아직 Redis가 필요하다는 것을 알았고, "거의 다 왔어.

Redis를 선택적 버킷에 넣기까지 거의 다 왔지만 아직 완전히 끝난 건 아니야.

Action Cable용으로 뭔가 필요해.

어떻게 하지?"라고 생각했습니다.

그때 다행히도 Nick Desaulniers가 Action Cable용 데이터베이스 백엔드 어댑터로 Solid Cable을 구현하여 제 기조 연설을 훨씬 쉽게 만들어 주었습니다.

기조 연설 흐름을 개선해 주셔서 감사합니다, Nick.

Solid Cable에서 제가 놀랐던 점은 특히 동일한 컴퓨터에서 SQLite가 얼마나 빠른지, RAM에서 완전히 작동하는 Redis와 얼마나 경쟁력이 있는지 하는 것입니다.

이 Solid Cable 어댑터는 순수 RAM Redis pub/sub 셔플러의 성능의 50% 이내에 도달하며, 파일에 쓰고 있습니다.

놀랍습니다.

2009년에는 불가능했을 "아하!" 순간 중 하나입니다.

NVMe 드라이브는 2배나 빨라졌습니다.

그것이 바로 이것을 가능하게 하는 것입니다.

놀랍습니다.

이제 실제로 프로덕션에서 이것을 사용할지 여부는 다른 용도로 Redis가 필요한지 여부에 따라 달라질 수 있습니다.

중요하지 않습니다.

우리는 사람들이 첫날에 작은 강아지 발로 키보드를 두드리면서 모든 것을 알 필요가 없는 지점까지 진입 장벽을 낮추려고 노력하고 있습니다.

괜찮습니다.

우리는 거기에 도달할 것입니다.

Solid 3인방의 두 번째는 Solid Cache입니다.

이것은 실제로 Basecamp에서의 설정에서 직접 필요에 의해 탄생하고 추출된 것입니다.

Redis에 캐싱 시스템을 구축했습니다.

상당히 컸습니다.

2015년 어느 시점에 이 상자에 넣을 RAM의 마약 압수 사진을 올렸습니다.

테이블 위에 1.5TB 정도 펼쳐 놓았던 것 같습니다.

RAM은 여전히 비싸고, RAM은 여전히 제한적입니다.

이것은...

이것은 오늘날 Basecamp에서 프로덕션에서 Solid Cache를 사용하는 방식입니다.

60일 동안 10TB의 캐싱을 저장합니다.

기본 템플릿이 변경되지 않는 부분은 60일 동안 캐시에 남아 있습니다.

오랜 시간입니다.

예전에는 17시간이었는데, 캐시가 그렇게 오래 살아남으면 응답 시간에 어떤 일이 일어나는지 정확히 알 수 있습니다.

그 캐시의 적중률은 96%입니다.

이것이 영향을 미치는 사진입니다.

Solid Cache를 도입한 시점을 알 수 있으신가요? 바로 여기입니다.

p95의 400밀리초 요청이 이후 200밀리초 정도로 줄었습니다.

캐시를 훨씬 오래 유지한 직접적인 결과입니다.

하지만 다른 제약 조건도 있었고, 이것이 바로 제가 실제 세계에서 일하는 것을 좋아하는 이유입니다.

이것이 바로 제가 프로덕션에서 일하는 것을 좋아하는 이유입니다.

단순히 벤치마크 게임을 하는 것이 아닙니다.

Hey를 도입했을 때 겪었던 문제 중 하나는 아내가 베타 버전의 Hey에 가입하라고 했을 때 실제로 저에게 했던 질문이었습니다.

"직원들이 내 이메일을 읽을 수 있나요?" 저는 "음...

음...

그럴 수도 있죠."라고 대답했습니다.

Solid Cache는 암호화를 지원합니다.

ActiveRecord 위에 구축되었습니다.

ActiveRecord 암호화도 Hey를 위해 설계되었으며, 여기에 우리의 캐시도 지원할 수 있는 2차 배당금이 있습니다.

그리고 Hey에 대한 보안 약속을 이행하는 데 도움이 됩니다.

그리고 프로그래머가 시스템을 유지 관리하는 정상적인 작업을 수행할 때 민감한 개인 데이터를 볼 수 있는지 여부에 대한 우려 없이 Hey를 정확히 운영할 수 있습니다.

개인 정보 보호를 위한 큰 도약이며, 더 많은 사람들이 이를 채택하기를 바랍니다.

보존도 이와 관련이 있습니다.

Hey에 가입하고 한동안 사용하다가 계정을 삭제하면 어떻게 될까요? Hey에서 어떤 일이 일어나는지 말씀드리겠습니다.

계정을 삭제하면 대부분의 회사에서는 삭제했다는 작은 부울 값이 설정됩니다.

실제로 삭제된 것이 아니라 여전히 존재하고, 여전히 액세스할 수 있습니다.

저는 그런 방식이 마음에 들지 않습니다.

삭제한다고 하면 적어도 어느 시점에는 사라졌다는 것을 알고 싶습니다.

Hey에서는 60일이라는 구체적인 기간을 보증합니다.

60일 이내에 삭제하면 로그에서도, 모든 것에서도, 데이터베이스에서도, 캐시에서도 사라집니다.

따라서 기능으로 이를 뒷받침해야 합니다.

이것이 바로 그 모습입니다.

10TB의 큰 디스크, 큰 캐시가 있지만 최대 60일 동안만 유지할 수 있습니다.

왜냐하면 그것이 우리의 보존 정책이기 때문입니다.

ActiveRecord의 엄격함을 기반으로 구축된 Solid Cache에서 제가 좋아하는 또 다른 점은 ActiveRecord의 기능을 활용할 수 있다는 것입니다.

필요한 경우 10TB 이상으로 확장할 수 있습니다.

단일 머신에 제한되지 않습니다.

그리고 여기 Solid 3인방의 왕관 보석이 있습니다.

약 18개월 전에 새로운 애플리케이션을 시작할 때 이것을 보고 "아니, 아니, 싫어.

싫어.

새 애플리케이션에서 작업을 처리하기 위해 7개의 gem을 추가하고 싶지 않아."라고 생각했습니다.

그리고 그 중 1, 2, 4개는 비공개 포크입니다.

무슨 일이 일어나고 있는 걸까요? 이건 고장났습니다.

아닙니다.

우리는 백지 상태에서 무엇을 할지 적어서 새로운 Active Job 백엔드를 구축할 것입니다.

고성능이어서 시스템을 통해 푸시하는 모든 작업을 처리할 수 있고, SQLite, PostgreSQL 또는 MySQL을 실행하든 관계없이 모든 사람이 사용할 수 있도록 3가지 주요 데이터베이스에서 모두 작동하며, 설치 후 6개의 gem을 더 원하지 않도록 모든 기능을 갖출 것입니다.

그리고 그것이 바로 우리가 구축한 것입니다.

Sam Saffron이 구축했습니다.

두 가지 방식으로 실행할 수 있습니다.

기본적으로 큐가 어디에 있는지 몰라도 됩니다.

단일 프로세스를 실행하고 Solid Queue가 Puma에 연결됩니다.

그것이 기본 설정입니다.

아니면 별도의 작업 호스트 세트로 실행할 수 있습니다.

이것은 대부분의 애플리케이션이 어느 정도 규모가 커지면 수행하는 방식입니다.

bin/jobs를 실행하여 감독자를 시작하면 모든 작업이 데이터베이스를 통해 실행됩니다.

실제로 문제가 발생하면 조사할 수 있는 정말 멋진 시스템이고, 고속 환경에서 조정하는 데 필요한 모든 다이얼을 마련했다는 사실에 정말 만족합니다.

애플리케이션의 특정 부분에 대한 다양한 구성 파일로 시작할 수 있습니다.

심지어 반복 작업도 내장되어 있습니다.

이것은 애플리케이션을 클라우드 또는 컨테이너로 이동할 때 겪었던 과제 중 하나였습니다.

cron으로 무엇을 해야 할지 파악하려고 노력했습니다.

이것은 Rails 애플리케이션 내부에서 완전히 실행되는 더 나은 cron이며, 모든 작업을 시작할 수 있습니다.

이것은 실제로 프로덕션에서 정의한 내용입니다.

적어도 3분의 2입니다.

설정한 모든 다양한 큐 작업 중에서, 이 전체 시스템은 Hey에서만 하루에 2천만 개의 작업을 처리하고 있습니다.

놀랍습니다.

Basecamp와 다른 시스템에서 실행할 8천만 개의 작업이 더 있습니다.

모두 Solid Queue로 가져와서 하루에 약 1억 개의 작업을 실행할 것입니다.

잘 작동하고, 좋고, 더 쉽고, 7개의 gem이 필요하지 않으며, 마이그레이션할 때 Redis를 스택에서 제거할 수 있습니다.

Rails 8을 통해 모든 종속성을 제거한다는 또 다른 아이디어는 인덱스, 다른 형태의 프록시, 애플리케이션을 인터넷에 공개하기 전에 애플리케이션 앞에 배치해야 하는 다른 형태의 것들을 제거한다는 것입니다.

Rails 8의 임무는 기본 설정에서 생성되는 Rails 8 컨테이너 이미지를 인터넷에 직접 노출할 수 있어야 한다는 것이었습니다.

빠르고, 안전하고, 사용하기 쉬워야 하고, 전문 지식이 필요 없어야 합니다.

Thruster는 프록시의 일부로 이 중 절반을 제공합니다.

정적 파일 가속화를 제공합니다.

큰 파일을 보내는 경우 Puma 프로세스를 사용하지 않아도 됩니다.

public에 설정한 모든 것 또는 기타 캐시 컨트롤 캐싱을 수행합니다.

다시 말하지만, Puma가 처리할 필요가 없습니다.

그리고 gzip 압축을 수행하며, 결국에는 brotli도 수행할 것입니다.

아래의 기본 Docker 이미지에 기본적으로 설치되어 있습니다.

노출된 80 또는 노출된 80 바로 아래에서 puma 앞에서 Thruster를 실행하면 이 모든 것을 얻게 됩니다.

Thruster는 기본적으로 완전히 구성이 필요 없습니다.

puma 앞에서 실행하는 하나의 명령일 뿐이고, 모든 좋은 것을 얻게 됩니다.

정말 멋집니다.

또한 Go로 작성되었습니다.

Go는 프록시를 작성하기에 매우 좋은 언어이며, Rails 스택에서 기본적으로 사용하는 것을 자랑스럽게 생각합니다.

Rails 스택의 일부입니다.

Go로 작성되었습니다.

왜냐하면 Go가 그 부분에 더 적합하기 때문입니다.

그렇게 합시다.

Kevin의 개인 노트북에서 테스트한 결과 초당 6만 건의 요청을 처리할 정도로 매우 빠릅니다.

알겠습니다.

Rust로 작성하기만 하면 노트북 구석에서 Shopify 전체를 실행할 수 있다는 것을 압니다.

가능하다는 것을 압니다.

적어도 인터넷에서 사람들이 그렇게 말합니다.

하지만 이것은 병목 현상이 되지 않을 것입니다.

중요한 것은 그것뿐입니다.

이것은 병목 현상이 되지 않을 것입니다.

Kamal 2가 있습니다.

이것이 바로 애플리케이션을 클라우드, 자체 하드웨어, 모든 컨테이너, 원하는 곳 어디든 배치하는 방법입니다.

왜냐하면 우리는 패스에 얽매이지 않을 것이기 때문입니다.

"우리는 클라우드를 떠날 것이다"라는 선언에서 빠진 요소였고, 그것이 1단계였습니다.

그리고 2단계는 물음표, 물음표, 물음표였습니다.

어떻게 하면 수익을 낼 수 있을까요? 그리고 빠진 부분은 Kamal을 도입하는 것이었습니다.

Kamal 2는 이를 크게 개선했습니다.

자동 SSL을 제공하므로 SSL 인증서를 프로비저닝하는 방법에 대해 전혀 알 필요가 없습니다.

Let's Encrypt를 통해 자동으로 수행합니다.

단일 서버에서 여러 애플리케이션을 실행할 수 있으므로 확장뿐만 아니라 축소도 가능합니다.

배포 모습을 자세히 설명하는 정말 간단한 선언 설정이 제공됩니다.

기본적으로 전체 설정은 구성을 최소화하기 위해 여러분에게서 얻을 수 있는 최소한의 정보로 요약되어 있습니다.

Kamal 2의 이전 프록시인 Traefik을 대체하여 더 쉽고 빠르게 자동 SSL을 지원하고 구성 없이 여러 앱을 지원하는 새로운 프록시가 지원됩니다.

그것이 바로 Kamal 전체의 임무였습니다.

어떻게 하면 이 모든 것을 설정하는 데 구성이 전혀 필요 없도록 하여 개념을 이해할 필요조차 없게 만들 수 있을까요? 보고 싶으신가요? 짧은 데모를 보여드리겠습니다.

주의 깊게 보세요.

5분밖에 안 되고 정말 빨리 지나갑니다.

전제는 두 개의 도메인을 설정했는데, 둘 다 단일 서버를 가리키고 있습니다.

애플리케이션은 alpha에 있을 것이고, bravo에 있을 것입니다.

이미지를 저장할 Docker Hub가 있습니다.

그것이 우리의 컨테이너입니다.

이 단계를 제거하기 위해 열심히 노력하고 있습니다.

Docker Hub 또는 다른 레지스트리 서비스를 사용하지 않고도 실행할 수 있어야 합니다.

하지만 보여드리겠습니다.

뒤에 깨어 계신 분이 있으면 보여드리겠습니다.

좋습니다.

가보겠습니다.

새로운 Rails 애플리케이션을 시작하고 곧 main으로 시작할 것입니다.

곧 rails new로 시작할 수 있을 것입니다.

항상 그랬듯이 제목과 본문이 있는 메시지 스캐폴드를 생성할 것입니다.

마이그레이션할 것입니다.

모든 것이 이미 설정되어 있습니다.

이제 경로를 살펴보겠습니다.

배포로 바로 넘어갈 때 경로에서 애플리케이션에 액세스할 수 있도록 경로에 바로 연결하겠습니다.

개발 환경에서 작동하는지 테스트해 보겠습니다.

네, 작동합니다.

멋지네요.

20년 동안 봐 온 오래된 스캐폴드입니다.

거기에 도달하는 데 필요한 것이 얼마나 적은지 알 수 있습니다.

이제 프로덕션으로 갈 준비가 되었고, deploy.yml 파일을 열어서 그렇게 할 것입니다.

두 가지를 입력할 것입니다.

레지스트리에서 사용할 사용자 이름을 입력할 것입니다.

그리고...

그것을 입력할 것입니다.

dhh이고, 그런 다음 배포할 서버의 IP 주소 또는 DNS를 입력할 것입니다.

그런 다음 SSL 인증서를 바인딩할 호스트 이름을 입력할 것입니다.

이제 거의 준비가 된 것 같습니다.

여기서 멀티 동시성을 활성화하겠습니다.

2개의 프로세스를 켜고, lck 레벨 디버그를 켜서 프로덕션으로 전환하자마자 모든 것을 볼 수 있도록 하겠습니다.

그리고 실제로 로그에서 약간의 노이즈를 제거할 것입니다.

더 빨리 더 나은 방법을 찾았지만 데모에서는 이렇게 했습니다.

프로덕션으로 전환해 보겠습니다.

프로덕션으로 전환하려면 어떻게 해야 할까요? 먼저 Kamal이 어떤 버전을 배포하는지 알 수 있도록 모든 것을 git에 커밋해야 합니다.

그런 다음 kamal setup을 실행할 것입니다.

kamal setup은 기본 Dockerfile에서 Docker 컨테이너 이미지를 빌드하고 Thruster를 앞에 붙이고 데이터베이스를 자동으로 설정하는 Docker 진입점을 실행하고 레지스트리에 푸시합니다.

그 동안 다른 애플리케이션을 시작해 보겠습니다.

bravo를 시작하고 똑같은 작업을 실행할 것입니다.

하지만 방금 수행한 작업을 자동화하기 위해 Rails 템플릿을 사용할 것입니다.

스캐폴드를 실행하고 마이그레이션을 실행하고 똑같은 방식으로 모든 것을 설정할 것입니다.

비슷한 Rails 애플리케이션을 많이 만드는 경우 Rails 템플릿 설정을 사용하여 이 작업을 수행할 수 있습니다.

bravo가 설정되었습니다.

바로 개발 환경으로 이동해 보겠습니다.

오, 바로...

오, 저는 Tailwind로 bravo를 실행했습니다.

Tailwind를 추가하면 훨씬 더 예쁜 버전의 신뢰할 수 있는 스캐폴드를 얻을 수 있습니다.

빌드 단계에서도 작동합니다.

이제 온라인 상태인지 확인해 보겠습니다.

alpha는...

alpha는 실제 도메인 이름으로 제 취미 Hetzner 서버의 프로덕션 환경에서 온라인 상태입니다.

아까 소개해 드린 서버입니다.

그것이 전부입니다.

서버에서 미리 준비할 필요도, 설정할 필요도, 설치할 필요도 없었습니다.

새로운 Ubuntu 상자만 있으면 됩니다.

이제 두 번째 서버인 bravo를 설정해 보겠습니다.

똑같은 단계를 거쳐 모든 것을 빌드할 것입니다.

그 동안 alpha의 로그를 살펴보겠습니다.

서버에 있는 것처럼 이 모든 명령을 실행할 수 있습니다.

예를 들어 메시지를 업데이트하면 어떻게 되는지 볼 수 있습니다.

데이터베이스의 모든 것이 업데이트됩니다.

로컬에 있는 것처럼 스크롤백할 수 있습니다.

처음 프로덕션으로 전환할 때, 모든 것이 제대로 작동하는지 확인하려고 할 때, 모든 것이 설정되었는지 확인할 때 정말 유용합니다.

콘솔을 실행할 수 있습니다.

Kamal 2에는 별칭이 있어서 그냥 command console이라고 쓰면 바로 서버의 프로덕션 콘솔에 들어갈 수 있습니다.

그리고 모든 모델을 업데이트할 수 있습니다.

예를 들어 이 메시지의 제목을 변경하고 확인해 보겠습니다.

짜잔! 토론토에서 바로 업데이트했습니다! 와! 좋습니다.

다시 bravo로 돌아가 보겠습니다.

bravo도 프로덕션 환경에 있는지 확인해 보겠습니다.

오, 프로덕션 환경에 있습니다.

보세요.

bravo.exitsoftware.io입니다.

프로덕션 환경에 있습니다.

이 두 애플리케이션은 모두 동일한 서버에 자동 SSL 설정으로 실행되고 있으며, 케이블, 라이브 업데이트, 캐싱, 큐잉까지 모두 작동합니다.

모든 것이 사전 구성되어 있고, 실제 애플리케이션에 실제로 사용할 모든 실제 기능을 갖춘 프로덕션 환경에서 SQLite로 실행되고 있습니다.

정말 놀랍습니다.

이제 여기로 돌아가서 로그에 supervisor가 무언가를 입력하는 것을 볼 수 있습니다.

살아 있다는 것을 알 수 있습니다.

업데이트를 수행하고 여기로 돌아가서 Solid Queue 작업에 삽입된 것을 볼 수 있습니다.

실제 작업, 설정된 작업이 실제로 실행되고 있습니다.

그리고 Action Cable을 통해 Action Cable 업데이트를 수행합니다.

다시 말하지만, Solid Cable을 통해 흐릅니다.

그런 다음 모두 제거할 수 있습니다.

끝입니다.

Kamal이 제거되었습니다.

이제 전체 애플리케이션에서 상자를 정리하고 있습니다.

하나만 제거하면 멋진 502와 함께 불량 게이트웨이가 표시됩니다.

내장 프록시에서 제공됩니다.

그리고...

끝입니다.

원래 Rails 비디오를 보면 15분 동안 하나의 애플리케이션을 만들고 프로덕션으로 전환하지 않았습니다.

그것은 2005년의 일입니다.

이제 우리는 5분 만에 두 개의 애플리케이션을 프로덕션 환경으로 가져왔고, 그 중 하나는 Tailwind를 사용하여 꽤 멋지게 보이기까지 했습니다.

6배 압축입니다.

프로덕션 환경에 도달하기 위해 필요했던 것보다 복잡성을 6배나 줄였습니다.

그런데도 여전히 익숙하게 보입니다.

이것은 우리가 가지고 있는 거의 원래 스캐폴드입니다.

그것이 바로 Rails 8입니다.

인증, 새로운 애셋 파이프라인, Solid 3인방, Thruster, Kamal 2가 있습니다.

빌드도 필요 없고, 패스도 필요 없고, 놀랍습니다.

그리고 오늘 첫 번째 베타 버전으로 곧 출시될 예정입니다.

Raphael? 네, 좋습니다.

지금 바로요.

[박수]

Rails 8이 출시될 뿐만 아니라 Kamal 2도 곧 최종 형태로 출시됩니다.

Solid Queue도 곧 최종 1.0 버전으로 출시됩니다.

이 모든 것이 실제로 사용할 준비가 되었습니다.

베이퍼웨어에 대해 이야기하기 위해 여기에 올 필요가 없었습니다.

우리는 실제로 운영 중이고, 모든 것이 준비되어 있습니다.

오늘 바로 첫 번째 Rails 애플리케이션을 시작해 보시기 바랍니다.

이제 3분 늦었지만 살짝 맛보기를 보여드리고 싶었습니다.

맛보기를 보고 싶으신가요? 좋습니다.

Rails 8에 넣고 싶었지만 이미 멋진 기능으로 가득 차서 넣지 못한 것들이 많이 있습니다.

Action Notifier를 넣고 싶었습니다.

Action Notifier는 네이티브 애플리케이션이 필요 없도록 웹 푸시 알림을 제공하는 새로운 프레임워크입니다.

정말 멋질 것입니다.

우리는 이미 실행하고 있고, 여러분도 이미 사용하고 있습니다.

회사가 아닌 컨퍼런스 채팅인 Campfire를 사용해 보셨다면, 초기 버전의 Action Notifier를 통해 푸시 알림을 받고 있을 것입니다.

Action Notifier는 Campfire 내부에 있습니다.

꽤 간단한 프레임워크이지만 웹...

웹 서비스 워커를 설정하기 위해 처리해야 할 몇 가지 사항이 있습니다.

서비스 워커라고 합니다.

구독에 연결하고, 모든 것을 전송하고, 안정적으로 만듭니다.

모든 것을 정리할 것입니다.

코드는 모두 준비되어 있습니다.

놀랍습니다.

ActiveRecord Search는 프로덕션 환경으로 전환할 때 우리에게 불쾌감을 주는 것이 무엇인지, 똑같은 전제, 똑같은 아이디어에서 시작한 새로운 프로젝트입니다.

Elasticsearch입니다.

Elasticsearch는 훌륭한 기능이지만 개발자와 운영자에게는 고통스러운 방법입니다.

우리는 그것을 해결할 것입니다.

왜냐하면 대부분의 사람들은 Elasticsearch의 모든 기능이 필요하지 않고, ActiveRecord를 검색하기만 하면 되기 때문입니다.

우리는 훨씬 간단하게 그 문제를 해결할 수 있습니다.

ActiveRecord Search는 바로 그것을 위한 것입니다.

이렇게 보일 것입니다.

어떤 변수 또는 어떤 속성이 검색 가능한지, 어떻게 검색 가능한지 선언하고, 이렇게 검색할 것입니다.

post.search("공지").

그것이 전부라면 얼마나 좋을까요? 바로 사용할 수 있다면 얼마나 좋을까요? 네, 정말 좋을 것입니다.

정말 좋을 것입니다.

이것이 우리가 사용하는 세 가지 주요 메서드입니다.

다시 말하지만, 다른 모든 Solid와 마찬가지로...

다른 모든 Solid라고 말했지만, 이것은 Solid Search라고 불렸습니다.

그러다가 "잠깐만, 말이 안 되잖아.

ActiveRecord는 이미 데이터베이스인데, 다른 데이터베이스용 어댑터가 아니잖아."라고 깨달았습니다.

그래서 이제 ActiveRecord Search가 되었지만, ActiveRecord 위에 구축되어 있습니다.

이러한 작업만 수행하고 있습니다.

그리고 마지막으로...

우리는 모든 애플리케이션에서 Action Text를 사용해 왔지만, 최신 애플리케이션에서는 마크다운을 사용하여 Action Text를 사용하고 있습니다.

마크다운은 텍스트를 포맷하기에 훌륭한 형식이며, 많은 사람들이 위지위그 편집기보다 마크다운을 선호합니다.

우리는 그것을 Action Text에 바로 넣을 것이고, HouseMD라고 부를 것입니다.

House는 이미 RightBook을 지원하고 있습니다.

실제로 무료로 다운로드할 수 있는 애플리케이션입니다.

작동 방식을 확인하고 모든 소스를 확인할 수 있습니다.

8.1의 맛보기입니다.

앞으로도 멋진 기능이 많이 준비되어 있습니다.

Kamal 2.1, 많은 것들이 다가오고 있지만 잠시 모든 것을 정리하고 빨간색 원을 즐기겠습니다.

여기까지입니다.

감사합니다.

[박수]

[음악]

coleea/rails 8 by dhh.mdx

Rails World 2024 Opening Keynote - David Heinemeier Hansson