해피 패스 프로그래밍 팟캐스트: 요하네스 쉬클링과의 인터뷰 (한글 번역)

[2024.07.08] 해피 패스 프로그래밍 팟캐스트: 요하네스 쉬클링과의 인터뷰 (한글 번역)  

https://podcasters.spotify.com/pod/show/happypathprogramming/episodes/101-Effects-and-Local-First-with-Johannes-Schickling-e2lkhkj


제임스 워드 (00:00): 어서 오세요. 저는 제임스 워드이고, 브루스 에켈입니다. 해피 패스 프로그래밍에 오신 여러분을 환영합니다. 7월 4일 불꽃놀이와 퍼레이드가 있는 아름다운 여름날입니다. 오늘 우리와 함께 해주신 요하네스 쉬클링 님을 소개합니다. 마이클 아르나디를 통해 알게 되었는데, 이펙트 타입스크립트 관련 작업을 함께 하셨죠? 요하네스 님, 환영합니다!

요하네스 쉬클링 (00:42): 초대해 주셔서 감사합니다. 저는 이 팟캐스트의 열렬한 팬이며 많은 것을 배웠습니다. 이제 여러분과 이야기하고 제가 배운 것을 공유하게 되어 기쁩니다.

제임스 워드 (00:52): 훌륭합니다. 똑똑한 사람들에게 배우는 것이 바로 우리가 여기 있는 이유입니다.

알 수 없음 (00:55): 네. 지난번에 이펙트에 대해 이야기한 게 약 1년 전이었죠? 그 이후로 어떤 일이 있었나요?

제임스 워드 (01:03): 바로 이 부분부터 시작하고 싶습니다. 재미있을 것 같네요. 약 한 달 전에 이펙트 타입스크립트 3.0 릴리스가 있었고, 일반적인 웹 자바스크립트 커뮤니티에서 이펙트에 대한 관심이 많았습니다. 해커 뉴스와 트윗, 인플루언서들의 반응을 봤는데, 어떤 사람들은 이게 말도 안 된다고, 왜 이렇게 복잡하게 해야 하냐고, 과도한 것 같다고 했습니다.

제임스 워드 (01:43): 이펙트의 타겟 커뮤니티가 제가 관심 있는 것들, 즉 컴퓨터 과학적인 부분에 관심이 없는 것 같다는 점을 보여주는 것 같습니다.

알 수 없음 (02:00): 네, 컴퓨터 과학적인 부분 말이죠.

제임스 워드 (02:02): 먼저 타겟팅하는 타입스크립트 커뮤니티의 몇 퍼센트가 실제 타겟인지부터 이야기해 보죠.

제임스 워드 (02:08): 자바스크립트 커뮤니티도 있을 텐데, 겹치는 부분이 있을 겁니다.

알 수 없음 (02:16): 타입스크립트를 접하지 않은 사람들은 이펙트의 타겟이 되지 않을 거라고 생각합니다.

제임스 워드 (02:22): 자바스크립트 커뮤니티에도 더 안정적인 소프트웨어를 작성하고 싶어 하는 사람들이 있을 거라고 생각합니다. 아닐 수도 있겠지만요.

요하네스 쉬클링 (02:31): 중요한 부분을 지적하셨습니다. 자바스크립트와 타입스크립트 커뮤니티의 흥미로운 점은 진입 장벽이 매우 낮다는 것입니다. 이 생태계에는 자신의 사이드 프로젝트 등을 통해 첫 웹사이트나 웹 앱을 만들고 배포할 수 있을 정도로 호기심이 많고 독학하거나 부트캠프를 통해 배운 개발자가 많습니다. 컴퓨터 과학 등을 공부하지 않고도 생산적이고 창의적으로 실제 결과물을 만들어낼 수 있다는 것은 놀라운 일입니다. 하지만 이는 업계에 프로덕션 수준의 시스템을 제대로 구축하는 방법을 경험해보지 못한 개발자가 많다는 것을 의미하기도 합니다.

요하네스 쉬클링 (02:59): 프로덕션 수준의 시스템을 구축하는 대부분의 사람들은 다른 프로그래밍 언어를 사용하거나, 자바스크립트 생태계에서는 분명 다수가 아닙니다. 하지만 현재 자바스크립트 타입스크립트 스택은 프론트엔드뿐만 아니라 백엔드에서도 점점 더 많은 소프트웨어 시스템의 기본이 되어가고 있기 때문에, 이제는 이 언어를 사용하여 프로덕션 수준의 시스템을 구축해야 합니다.

요하네스 쉬클링 (03:30): 이펙트에 대한 관심과 성공 사례가 가장 많은 곳은 타입스크립트를 사용하여 실제 프로덕션 수준의 시스템을 구축하려는 사람들과 기업들이 모인 곳입니다. 타입스크립트만으로는 프로덕션 수준의 시스템을 구축하는 것이 매우 까다롭다는 것이 밝혀졌습니다. 이는 Rust와 같은 최신 프로그래밍 언어에서 제공하는 장점, 즉 다른 프로그래밍 언어가 저지른 실수를 통해 얻은 교훈을 활용하여 오류 처리, 관찰 가능성, 취소 등의 문제를 해결할 수 있는 부분입니다. 이펙트와 같은 추상화 없이 타입스크립트에서 이러한 작업을 수행하는 것은 프로덕션 수준의 시스템을 구축하는 데 매우 어렵습니다.

요하네스 쉬클링 (03:59): 따라서 우리는 프로덕션 수준의 시스템을 구축하고자 하거나 구축해야 하는 타입스크립트 개발자 중 이펙트가 해결하려는 문제를 경험한 사람들에게 가장 큰 관심과 성공을 거두고 있습니다. 그러나...

알 수 없음 (05:11): ...충분한 경험을 통해 "아, 그냥 마구잡이로 만들면 안 되겠구나. 고통을 겪게 될 거야."라고 깨닫는 사람들이죠.

제임스 워드 (05:19): 그들은 고통을 경험해야만 합니다.

알 수 없음 (05:22): 그들은 고통을 경험해야만 "좋아, 더 정교한 것을 배우기 위해 노력해야겠어."라고 생각하게 됩니다.

요하네스 쉬클링 (05:31): 맞습니다. 타입스크립트 개발자 풀이 너무 커서 현재 이펙트를 사용하는 사람은 절대 소수입니다. 지금쯤이면 상당히 많은 개발자가 이펙트에 대해 들어봤겠지만...

알 수 없음 (05:50): 죄송하지만 몇 퍼센트 정도 될까요?

요하네스 쉬클링 (05:52): 말하기 어렵습니다. NPM 다운로드 수, GitHub 스타, Discord 멤버 수와 같은 지표를 살펴봐야 합니다. 지금은 절대적인 숫자보다는 추세와 질적인 피드백, 이펙트를 이미 사용하고 있는 기업의 종류에 더 관심이 있습니다.

요하네스 쉬클링 (06:23): 우리가 성공을 돕고 있다는 점에서 정말 기쁜 두 가지 주목할 만한 회사가 있습니다. Vercel은 프로덕션 워크로드를 이펙트로 점점 더 많이 옮기고 있습니다. Vercel은 자바스크립트 및 타입스크립트 생태계의 핵심 기업이자 트렌드세터 중 하나입니다. 또 다른 하나는 Zendesk인데, 프로그래밍 언어 측면에서 다국어를 사용하지만 상당한 양의 타입스크립트를 사용하고 있으며, 타입스크립트 코드를 이펙트 기반으로 표준화하는 것 같습니다. 이는 우연이 아닙니다. 그들은 타입스크립트를 사용하여 프로덕션 수준의 시스템을 실행해야 하고, 이펙트가 해결하는 모든 문제를 겪었으며, 이제 이펙트를 통해 안정적으로 시스템을 구축할 수 있습니다. 또한 향상된 개발자 경험 등의 이점도 누릴 수 있습니다.

제임스 워드 (07:18): 네. 이 분야의 개발자들에게는 프로그래밍을 처음 접하는 사람부터 프로덕션 수준의 미션 크리티컬 시스템을 담당하는 사람까지 다양한 스펙트럼이 있는 것 같습니다. 프로그래밍을 처음 접하는 사람들은 자바스크립트를 가지고 놀 수 있고, LLM의 도움을 받아 자바스크립트를 작성할 수 있으며, 브라우저에서 작동하는 것을 볼 수 있습니다. 그것은 흥미로운 일이며, 다양한 클라우드 제공업체에서도 작동하게 할 수 있습니다. 따라서 새로운 개발자가 애플리케이션을 구축하는 이 세계에 쉽게 진입할 수 있는 길이 있습니다.

제임스 워드 (07:52): 그리고 스펙트럼의 반대편에는 Vercel과 Zendesk와 같이 프로덕션 수준의 매우 중요한 시스템을 담당하는 사람들이 있습니다. 그리고 그 사이 어딘가에서 웹 애플리케이션뿐만 아니라 자바스크립트와 타입스크립트를 사용하는 사람들은 자신이 해왔던 일, 코드베이스가 확장되면서 발생하는 문제, 그리고 이러한 일반적인 문제를 처리하는 데 도움이 되는 프레임워크나 라이브러리를 사용하는 방법을 깨닫게 됩니다. 그리고 바로 그 지점에 이펙트가 있습니다.

제임스 워드 (08:29): 해커 뉴스와 트윗에서 제가 본 어려움은 "이건 너무 과해요. 왜 이런 게 필요한 거죠?"라고 말하는 사람들이 있다는 것입니다. 그것은 아마도 그들이 프로덕션 수준의 시스템을 다루지 않기 때문일 것입니다.

알 수 없음 (08:51): 몇 퍼센트의 사람들이 "아, 왜 이런 구조가 있는지 알겠어."라고 깨닫는 단계에 도달할까요? 제 생각에는 1% 미만일 것 같습니다.

제임스 워드 (09:02): 그 커뮤니티의 1% 미만이죠.

알 수 없음 (09:04): 네, 너무나 많은 사람들이 웹사이트를 그냥 대충 만들고 있으니까요.

요하네스 쉬클링 (09:10): 타입스크립트 생태계는 절대적인 숫자로 보면 너무 커서 이펙트 프로젝트와 이펙트 회사의 목표는 결코 타입스크립트 생태계 전체를 장악하는 것이 아닙니다. 목표는 안정적인 프로덕션 수준의 시스템을 구축해야 하는 타입스크립트 생태계의 일부를 돕는 것입니다. 결국 이펙트가 무엇인지 이해하게 되는 사람들을 위한 좋은 기준은 여러분이 언급했듯이 고통을 경험해 봐야 한다는 것입니다. 이것이 이펙트를 성공적으로 사용할 수 있는 가장 좋은 기반이 됩니다. 왜냐하면 이러한 모든 것들이 무엇에 관한 것인지 실제로 이해하게 되기 때문입니다. 많은 자바스크립트 개발자들은 매우 순진하게 행복한 경로만 가정하고 있으며, 문제가 발생할 수 있다는 사실을 잘 인지하지 못합니다.

요하네스 쉬클링 (10:10): 이는 우리가 매일 사용하는 많은 웹 앱에서도 나타나는데, 오류 처리는 기본적으로 고려되는 사항이 아닙니다. 하지만 실제로는 많은 문제가 발생할 수 있으며, 웹 앱이 더 정교해지고 목표가 높아질수록 더욱 신경 써야 합니다. 이를 직접 시도해 보고 어려움을 겪은 사람들은 오류 처리, 인터럽트, 취소, 구조적 동시성 등 지난 몇 년 동안 이 팟캐스트에서 심층적으로 다룬 모든 주제를 더 잘 이해하게 될 것입니다. 하지만 타입...

제임스 워드 (10:54): 타입스크립트를 선택한 사람들은 자바스크립트보다 한 단계 더 나아간 것이라고 생각합니다. 갑자기 컴파일러가 필요하고, 많은 이점을 얻지만, 타입스크립트를 선택할 때 상당한 장벽이 있습니다. 그리고 이러한 모든 이점을 얻지만, 순수한 타입스크립트로는 얻을 수 없는 이점이 바로 이펙트입니다.

제임스 워드 (11:20): 타입스크립트 언어와 타입을 사용하는 수준까지 왔다면, 그냥 한 걸음 더 나아가는 게 좋을 것 같습니다.

알 수 없음 (11:31): 네, 하지만 너무 깊이 들어가서 그것이 얼마나 큰 장벽인지 보지 못하는 것 같습니다. 타입을 사용하면 "아, 이제 무엇이 잘못되었는지 바로 알려주는구나. 내가 무엇을 잘못했는지 알겠어."라고 생각하지만, 이펙트로 넘어가는 것은 너무 오랫동안 몰입해 있어서 너무 당연하게 느껴집니다.

제임스 워드 (11:51): 하지만 타입스크립트는 이펙트가 타입스크립트 언어와 별개라는 점이 문제라고 생각합니다. 타입스크립트에 Roc이나 Unison과 같은 최신 언어처럼 대수적 효과가 내장되어 있다면, 이펙트는 타입과 마찬가지로 당연한 것이 될 것입니다.

알 수 없음 (12:13): 파이썬 세계에서는 "언어에서 요구하지 않는데 왜 타입 주석을 붙이는 거야?"라고 말하는 사람들이 많습니다. 언어에서 요구한다면 더 많은 사람들이 진지하게 받아들일 것입니다.

제임스 워드 (12:30): 그리고 아마도 더 많은 사람들이 배우기 위해 넘어야 할 장벽이 높아질 것입니다.

알 수 없음 (12:34): 하지만 여전히 그 개념을 배워야 할 것입니다. 갑자기 모든 것이 해결되는 것은 아닙니다.

제임스 워드 (12:41): 저는 프로그래밍 언어가 제공하는 기본값이 더 나은 기본값이 되기를 바랍니다. 저에게 이펙트는 더 나은 기본값입니다. 따라서 타입스크립트에는 대수적 효과가 내장되어야 합니다. 하지만 그렇지 않습니다. 그래서 이펙트는 거기에 도달하는 좋은 방법입니다. 하지만 여러분이 말씀하시는 것은 충분한 고통을 경험했거나 충분한 필요성을 느낀 사람들만이 다음 단계로 나아갈 의향이 있다는 것입니다.

알 수 없음 (13:12): 그리고 저는 타입스크립트 커뮤니티가 크기 때문에 그 부분이 작다고 말하는 것입니다. 하지만 우리가 세상에서 만나게 될 대부분의 사람들은 "무슨 말씀이신지 모르겠어요. 너무 이상해요."라고 말할 것입니다.

제임스 워드 (13:28): 하지만 우리는 저명한 개발자인 제레미로부터 얻은 데이터가 있습니다. 그는 이번 주에 크레스트뷰트에서 우리를 방문했는데...

알 수 없음 (13:41): 아니요, 저는 그가 전에 조금 언급했다고 생각하지만 어젯밤에 더 깊이 파고들었습니다.

제임스 워드 (13:47): 그는 어젯밤에 이펙트 문서를 살펴보기 시작했고, "이것은 가장 접근하기 쉬운 이펙트 시스템이야."라고 말했습니다. 단순히 이펙트 라이브러리뿐만 아니라 일반적인 부작용에 대해서도 말입니다. 그는 이것이 ZIO보다 훨씬 더 접근하기 쉽다고 말했습니다.

알 수 없음 (14:02): 네, 그는 ZIO 문서에 대해서는 이펙트 문서를 보면서 "이 사람들은 자신들의 독자를 알고 있어."라고 말했습니다.

요하네스 쉬클링 (14:09): 그가 그렇게 말했군요. 여기에 몇 가지 추가하고 싶은 내용이 있습니다. 이펙트는 한동안 ZIO의 타입스크립트 자매 프로젝트였습니다. 마이클 아넬리와 존 드 고스는 오랫동안 서로를 알고 지냈습니다. 그리고 마이클은 타입스크립트에서 이펙트 시스템이 어떤 모습일지 탐구해 왔고, ZIO를 알고 있었으며, 이를 타입스크립트에서 복제할 수 있는지 시도했습니다. 그리고 그는 그렇게 했습니다. 오랫동안 이펙트는 ZIO 프로젝트의 발자취를 따라 API 등을 동일하게 유지하려고 노력했습니다. ZIO가 새로운 종류의 API 형식이나 발전된 기능을 도입할 때마다, 얼마 지나지 않아 이펙트 생태계의 뛰어난 사람들이 마이클이나 맥스웰과 같은 사람들이 동일한 이점을 이펙트에 복제했습니다.

요하네스 쉬클링 (14:51): 하지만 어느 순간 우리는 일반적인 스칼라 및 ZIO 개발자의 사고방식이 타입스크립트 개발자의 사고방식과 다르다는 것을 깨달았습니다.

요하네스 쉬클링 (15:27): 재미있게도 타입스크립트에는 스칼라와 같은 정교한 언어보다 특정 종류의 사용 사례를 더 인체공학적으로 만드는 기능이 있었습니다. 스칼라에서는 더 나은 타입 추론 등의 이점이 있었지만, 이펙트 코드를 처음부터 더 인체공학적으로 작성하는 기본 방식이었던 직접 스타일이라고 생각합니다.

요하네스 쉬클링 (15:56): 그래서 어느 순간 우리는 타입스크립트 생태계를 타겟팅하면서 왜 스칼라의 관용적인 측면에 얽매여 있어야 하는지에 대한 갈등을 느꼈습니다. 또한 우리는 처음에는 타입스크립트에서 함수형 프로그래머를 위한 보금자리가 되고 싶었지만, 그것은 훨씬 더 작은 타겟 고객이며, 프로덕션 수준의 시스템 문제를 가진 사람들이 너무 많다는 것을 깨달았습니다.

요하네스 쉬클링 (16:34): ... 완전한 함수형 프로그래머, 범주 이론에 정통한 함수형 프로그래머가 될 의도가 없는 사람들 말입니다.

알 수 없음 (16:47): 승인 절차가 있나요? 몰랐네요.

요하네스 쉬클링 (16:51): 저는 시험에 통과하지 못했습니다.

제임스 워드 (16:55): 우리는 지금 4점 법칙을 따르고 있습니다.

요하네스 쉬클링 (16:58): 맞습니다. 하지만 우리는 기본적으로 React 프로젝트의 성공 사례에서 유사점을 발견했습니다. React는 프로그래밍 역사상 함수형 프로그래밍을 위한 가장 큰 트로이 목마라고 할 수 있습니다. React를 사용하는 대부분의 프로그래머는 사실상 함수형 프로그래밍을 하고 있지만, "네, 저는 함수형 프로그래머입니다."라고 의도적으로 주장하는 사람은 거의 없습니다.

제임스 워드 (17:28): 펑터의 관점에서 이야기해 보죠.

요하네스 쉬클링 (17:31): 그래서 우리는 이 사례와 성공 스토리에서 무엇을 배울 수 있고, 이를 이펙트에 어떻게 적용할 수 있을지 생각해 보았습니다. 그래서 우리는 접근 방식을 크게 바꾸었습니다. 처음에는 타입스크립트에서 함수형 프로그래밍을 하고 싶어 하는 사람들을 위한 좋은 보금자리가 되고 싶었지만, 그것은 훨씬 더 작은 타겟 고객이며, 프로덕션 수준의 시스템 문제를 가진 사람들이 너무 많다는 것을 깨달았습니다.

요하네스 쉬클링 (18:02): 이펙트를 사용하는 데 있어서 이론적인 배경을 이해하기 위해 깊이 있는 학습 과정을 거쳐야 할 필요는 없어야 합니다. 타입스크립트 생태계의 아름다움이 바로 그것입니다. 이펙트 프로그래머의 대다수는 이펙트 시스템이 무엇인지 전혀 모르지만 이펙트를 좋아할 것입니다. 언젠가는 이론적인 배경을 더 잘 이해하게 될 수도 있지만, 그것이 장벽이 되어서는 안 됩니다. 따라서 다양한 종류의 사용자가 있습니다. 여러분은 모두 다양한 시스템의 미묘한 차이점과 절충안에 대한 뉘앙스를 이해하는 데 매우 뛰어납니다. 하지만 우리는 실용주의를 중시하기 위해 과감한 변화를 시도했습니다.

요하네스 쉬클링 (19:00): 그리고 저는 시간이 지남에 따라 우리가 개발할 가장 큰 지렛대는 우리만의 생태계를 구축하는 것이라고 생각합니다. 이것이 이펙트가 오류 처리 등을 처리할 수 있는 견고한 메커니즘을 제공할 뿐만 아니라 NPM 생태계의 가장 넓은 부분을 재구축하고 있으며, 진정으로 구성 가능하고 성능이 뛰어나며 잘 관리되는 방식으로 구축하고 있다고 생각합니다. 워커, 시빌라이제이션과 같은 고급 개념을 사용하고 싶다면 이펙트 생태계에서 자연스럽게 찾을 수 있을 것입니다. 이것이 가장 큰 지렛대 중 하나가 될 것이며, 이 모든 것이 이펙트 시스템을 통해 가능해졌습니다.

알 수 없음 (19:58): 저는 지난 4년 동안 빌과 제임스가 "이거 멋지다, 이거 멋지다"라고 말하는 동안 손톱을 물어뜯으며 버텼습니다. 저는 "무슨 일이 일어나고 있는지 모르겠어. 무슨 일이 일어나고 있는 거야?"라고 생각했고, 이제야 마침내 이해하기 시작했습니다. 하지만 저는 아무도... 제가 계속 버틴 유일한 이유는 그 두 사람 때문이었습니다.

알 수 없음 (20:23): ... 다른 누구도 그 과정을 거치지 않을 것입니다. 그래서 우리가 책을 통해 하려는 것은 여러분이 말씀하신 방식으로 정말 접근하기 쉽게 만드는 것입니다. "왜 이렇게 해야 하는 거지? 이게 나에게 어떤 이점을 가져다주는 거지?"라는 질문을 먼저 던지고, 그 이점을 알게 되면 "좋아, 그럼 내가 일반적으로 하는 방식과는 조금 이상한 이런 것들을 살펴볼 의향이 있어."라고 생각하게 됩니다. 하지만 이상한 것들을 먼저 던지면...

알 수 없음 (20:51): ... 많은 문서에서 그렇게 하죠. "물론 당신은 이 모든 수학적 이론에 관심이 있을 거예요. 물론 당신은 하고 싶어 할 거예요. 당신은 이것과 저것의 차이점을 알고, 왜 이것이 Cats보다 나은지 알고 있을 거예요."라고 말합니다. "물론 당신은 그 모든 것을 알고 있을 거예요."라고 말하는데, 아니요, 전혀 몰랐습니다.

제임스 워드 (21:14): 요하네스 님, 이펙트에 관심을 갖게 된 계기는 무엇이었나요?

요하네스 쉬클링 (21:18): 네, 2016년에 저는 타입스크립트 개발자, 주로 자바스크립트 개발자를 위해 데이터베이스를 더 쉽게 사용할 수 있도록 하려는 문제에 좌절했고, 그것이 제가 Prisma를 설립하게 된 계기였습니다. 우리는 타입스크립트에 베팅했고, 타입스크립트를 데이터베이스에 적용하는 것이... ZIO에는 데이터베이스를 둘러싼 훌륭한 타입 안전 레이어가 있습니다. 이름이 생각나지 않네요.

제임스 워드 (21:51): 아, Quill이요.

요하네스 쉬클링 (21:52): Quill, 맞습니다. 타입스크립트 생태계에는 타입 안전성과 안정적인 방법을 제공하는 Quill만큼 훌륭한 것이 없었습니다.

제임스 워드 (22:03): 저는 Quill을 정말 좋아합니다. 제가 사용해 본 데이터베이스 관련 도구 중 최고라고 생각합니다. 정말 그렇습니다.

요하네스 쉬클링 (22:08): 그래서 우리는 그것을 해결하고 싶었습니다. 그리고 그것이 제가 Prisma를 설립하게 된 계기였습니다. 그리고 저는 Prisma에서 CEO로서 거의 5년을 보냈습니다. 데이터를 구축하고, 기술의 초기 버전을 만들고, 많은 사람들을 고용하고, 회사를 50명 규모로 키웠습니다. 하지만 그 후에는 한 걸음 물러서서 다음 5~10년 동안 제 삶에서 무엇을 하고 싶은지 진지하게 생각해 볼 수 있는 행운을 얻었습니다.

요하네스 쉬클링 (22:42): 그리고 저는 다시 프로그래머의 입장으로 돌아가고 싶다는 강한 열망을 느꼈습니다. 그래서 몇 가지 부수적인 프로젝트를 시작했고, 타입스크립트 생태계에서 많은 부분이 개선되었지만, 어떤 측면은 5년 전과 마찬가지로 여전히 좋지 않다는 것을 깨달았습니다. React 등은 프로그래밍의 무법적인 측면에 절실히 필요한 규율과 좋은 원칙을 가져왔지만, 타입스크립트로 작성하는 대부분의 작업에는 일반적인 용도의 프로그래밍을 위한 것이 없다고 느꼈습니다.

요하네스 쉬클링 (23:17): 그래서 저는 더 나은 아이디어를 찾기 위해 탐험을 시작했습니다. 과거에 Haskell을 조금 해봤는데, "세상에, 프로그래밍이 이렇게 다르고 훨씬 더 좋을 수 있다니!"라는 경험을 했습니다. 그것은 정말 신선하고 고무적이었습니다.

요하네스 쉬클링 (23:49): 하지만 이제 타입스크립트로 얼마나 생산성을 높일 수 있는지 알게 되었고, 두 가지 장점을 모두 누릴 수 있어야 한다고 생각했습니다. 저는 Rust에도 상당히 관심이 있었지만, 메모리 관리 부담이 항상 컸습니다. 그래서 "아마도 이제 더 깊이 파고들 수 있겠지만, 제가 매일 만드는 많은 앱에서는 아마도 그 메모리 관리 부담을 지불하고 싶지 않을 거야."라고 생각했습니다. 그리고 더 고급 함수형 프로그래밍에 더 많이 매료될수록 Rust도 그것에 완벽한 보금자리는 아니라는 생각이 들었습니다.

요하네스 쉬클링 (24:25): 저는 "지금 함수형 프로그래밍의 가장 성숙한 진화는 무엇일까?"라고 생각했고, 그렇게 2020년에 ZIO에 대해 알게 되었습니다. 그리고 여러분의 팟캐스트 등을 통해 정말 깊이 파고들었습니다. 하지만 저는 "스칼라로 돌아가야 할까?"라고 잠시 고민했습니다. 우리는 ZIO가 나오기 전에 스칼라로 Prisma의 첫 번째 버전을 만들었습니다.

요하네스 쉬클링 (25:01): 하지만 저는 여전히 JVM을 다루면서 겪었던 트라우마가 있었습니다. 그리고 JVM을 WASM으로 컴파일하고 임베드할 수 있게 해주는 Oracle 프로젝트에 약간의 희망을 걸었지만, 그 프로젝트에 많은 시간을 낭비했습니다. 그래서 더 이상 JVM과 관련된 일을 하고 싶지 않았습니다. 그래서 저는 "ZIO에서 제가 좋아하게 된 멋진 아이디어들을 어떻게든 자바스크립트 생태계로 가져올 수 있을까?"라고 생각했습니다.

요하네스 쉬클링 (25:36): 그리고 그렇게 당시 Mattex Effects라고 불렸던 프로젝트를 발견했고, 나중에 그 프로젝트는 이펙트가 되었습니다. 그래서 저는 그 당시 마이클에게 연락하기 시작했고, FPTS도 조금 살펴보았지만, FPTS는 Haskell의 너무 학문적이고 이론적인 부분처럼 느껴졌고, 이펙트는 당시 초기 버전에서도 훨씬 더 실용적으로 느껴졌습니다. 그래서 저는 마이클과 소통하기 시작했고, 그는 매우 도움이 되었습니다.

요하네스 쉬클링 (26:13): 그리고 그는 제 피드백에 매우 귀를 기울였습니다. 그는 "이건 좀 접근하기 어려워."라고 말했고, 저를 멘토링해 주었고, 제가 시작하고 실행하는 데 도움을 주었습니다. 그리고 저는 점차 그 생태계와 그 잠재력에 매료되었습니다. 당시에는 매우 초기 단계였고, 저는 아마도 새로운 획기적인...

요하네스 쉬클링 (26:38): ...변경 사항이 있는 버전을 이틀에 한 번씩 다루어야 했을 것입니다. 저는 실제 프로젝트에서는 전혀 진전이 없고, 단지 그 모든 변화를 따라잡고 있다는 느낌이 들었습니다. 하지만 새로운 변경 사항이 적용될 때마다 모든 것이 훨씬 더 간단해졌고, 저는 수많은 코드 줄을 삭제할 수 있었습니다. 그래서 저는 그 궤적에 이끌렸고, 지루하지 않았습니다. 그리고 거의...

알 수 없음 (27:07): 저는 파이썬에서 이런 이점을 경험했다고 생각합니다. 저는 거의 처음부터 파이썬에 참여해 왔고, "새로운 기능이 나왔네. 머릿속에 다른 모든 기능이 있어서 이게 어떻게 다른지 알 수 있어. 왜 이렇게 바뀌었는지 알겠어."라고 생각할 수 있었습니다. 하지만 처음 접하는 사람들은 그런 점진적인 변화를 보는 이점이 없습니다.

제임스 워드 (27:34): 네, 그 여정을 함께 해왔습니다. 요하네스 님의 경우 ZIO와 Haskell을 통해 구성 가능성과 부작용 관리의 즐거움을 경험하고 잘 설계된 그림을 보고 경험한 것 같습니다. 그리고 웹 애플리케이션을 만들고 훌륭한 도구를 활용할 수 있는 세상에 그것을 어떻게 가져올 수 있을지 고민한 것 같습니다. 제가 요약을 잘 했나요?

요하네스 쉬클링 (28:09): 네, 저는 야심 찬 아이디어를 맡는 것을 좋아하지만, 제가 스스로에게 정한 목표는 도구 제작자가 아닌 앱 개발자의 입장으로 돌아가는 것이라는 것을 분명히 했습니다. 그래서 저는 다른 누군가가 그 부분을 맡아주기를 바랐습니다. 그래서 저는 그냥 여러 프로젝트를 검토하고 "이것은 누군가가 정말 흥분해서 두 달 후에 그만두는 또 다른 라이브러리일까? 아니면 그들의 동기는 무엇일까? 그들의 목표는 무엇일까?"라고 생각했습니다. 그리고 그렇게 저는 마이클과 이펙트에서 적합한 파트너십을 찾았습니다. 저는 마이클의 장기적인 접근 방식을 보았습니다. 그리고 지금 우리는 그 프로젝트에 4년 가까이 참여하고 있으며, 마이클은 훨씬 더 오랫동안 참여해 왔습니다. 그 프로젝트가 얼마나 발전했는지 놀랍습니다. 그리고 어떤 면에서는 이제 막 시작했을 뿐입니다. 올해 우리는 첫 번째 이펙트 컨퍼런스를 개최했고, 존 드 고스를 모실 수 있는 영광을 누렸습니다.

요하네스 쉬클링 (29:13): 그리고 존이 강연에 동의했다는 것은 큰 이정표였습니다. 하지만 그가 컨퍼런스에서 하게 된 강연은 정말 놀라웠습니다. 그는 몇 가지 흥미로운 슬라이드를 보여주었는데, 그중 하나는 일련의 물고기였습니다. 아주 작은 물고기는 Haskell 함수형 프로그래밍을 나타냈고, 그 물고기를 훨씬 더 큰 물고기인 ZIO가 삼켰습니다. ZIO는 Haskell 함수형 프로그래밍 접근 방식을 삼킨 것입니다.

요하네스 쉬클링 (29:51): 그리고 그는 ZIO보다 훨씬 더 큰 세 번째 물고기를 그렸는데, 그것은 이펙트였습니다. 그리고 그는 기본적으로 ZIO가 미친 가장 큰 영향은 이펙트 프로젝트에 영감을 준 것이라고 말했습니다. 그것은 매우 겸손하고 감동적이었습니다.

제임스 워드 (30:12): 네, 존은 더 많은 프로그래머가 함수형 프로그래밍을 하기를 바랍니다. 그리고 스칼라는 한계가 있습니다. Haskell로 시작해서 Haskell은 어느 정도까지 가능하지만, 스칼라는 함수형 프로그래밍을 하는 개발자를 백만 명까지 끌어들일 수 있습니다. 하지만 타입스크립트는 천만 명의 프로그래머가 함수형 프로그래밍을 할 수 있는 기회를 제공합니다.

알 수 없음 (30:36): 그렇다면 이펙트풀 회사를 설립하게 된 이유는 첫 번째 컨퍼런스를 개최했기 때문인가요? 컨퍼런스가 회사 설립의 계기가 되었나요?

요하네스 쉬클링 (30:52): 회사의 CEO이자 프로젝트의 핵심 개발자인 마이클에게 직접 물어봐야 할 질문입니다. 저는 그의 관점에서 제가 기억하는 내용만 말씀드릴 수 있습니다.

제임스 워드 (31:12): 그러니까 회사는 이펙트를 중심으로 커뮤니티를 홍보하고 성장시키는 데 도움을 주는군요.

요하네스 쉬클링 (31:17): 네.

알 수 없음 (31:18): 회사의 일부로서 말이죠.

요하네스 쉬클링 (31:19): 네, 맞습니다. 약간의 변화가 있었습니다. 처음에는 마이클이... 2020년, 2021년에 마이클은 여전히 런던에 살면서 핀테크 스타트업에 집중하고 있었고, 이펙트는 핀테크 스타트업의 기반 역할을 하는 수단에 불과했습니다. 그리고 그는 이펙트를 대중에게 알리고 실용적으로 만들고 싶어 하지 않았습니다.

요하네스 쉬클링 (31:52): 그는 이미 함수형 프로그래밍에 익숙했기 때문에 굳이 바꿀 필요가 없었습니다. 하지만 생태계와 커뮤니티가 점점 더 커지고 이펙트 프로젝트에 더 많은 시간을 할애하게 되면서, 어느 순간 그에게 변화가 생겼습니다. 당시 그의 주요 목표였던 핀테크 스타트업...

요하네스 쉬클링 (32:16): ...은 2순위로 밀려났고, 이펙트 프로젝트 자체가 최우선 순위가 되었습니다. 그리고 나서 그는 "이것을 중심으로 회사를 설립할 수 있을까?"라는 생각을 하기 시작했습니다. 우리는 그 문제에 대해 오랫동안 이야기를 나누었고, Prisma에서 벤처 자금을 조달한 경험이 있었기 때문에, 저는 그에게 매우 신중해야 한다고 조언했습니다. 당시는 벤처 자금을 조달하기에 매우 좋은 시기였지만, 지금은 기대치가 훨씬 더 높습니다. 그래서 저는 그에게 매우 신중해야 한다고 조언했습니다. 네, 우리는 아직 그 카드를 사용하지 않았지만...

요하네스 쉬클링 (32:54): ...프로젝트에서 회사를 설립하는 적절한 시기와 방법을 파악하는 데 긴밀히 협력했습니다. 저는 프로젝트 자체를 위험에 빠뜨리지 않고 더 큰 무언가를 가능하게 하는 상업적 전략을 수립한 후에 회사를 설립하는 것이 적절하다고 생각했습니다. 이는 앞으로 더 자세히 다룰 주제입니다. 요약하자면, 프로덕션 수준의 시스템을 구축한 후에는 어떻게 실행하고, 일반적으로 분산 시스템인 경우 어떻게 배포하는지에 대한 질문입니다. 타입스크립트 프로젝트를 배포하는 데 사용할 수 있는 기성 솔루션은 대부분 요청-응답 기반 모델입니다. 하지만 큐나 지속적인 워크플로우가 관련된 경우에는...

요하네스 쉬클링 (34:39): ... 스스로 해결해야 합니다.

제임스 워드 (34:55): ... 주요 과제가 됩니다. 우리가 요하네스 님과 이야기하고 싶었던 이유 중 하나는 분산 시스템에서 상태 관리가 어렵고, 어려운 점 중 하나는 상태가 어디에 저장되는지, 진실의 원천은 무엇인지입니다. 단일 서버만 사용하면 쉽지만, 데이터를 내 컴퓨터에 로컬로 저장하고 그것을 진실의 원천으로 삼고 싶다면 어떻게 해야 할까요? 그리고 나서 원할 때마다...

제임스 워드 (35:27): ... 서버와 동기화할 수 있습니다. 이것이 로컬 퍼스트 운동이라고 불리는 것입니다. 그리고 프로그래밍 여정과 관련하여 요하네스 님의 관심사 중 하나는 사용자가 데이터를 더 잘 제어할 수 있도록 하는 방법인 것 같습니다. 맞나요?

요하네스 쉬클링 (35:47): 네, 맞습니다. 그것은 당시 제 마음을 사로잡았던 매우 직교적인 측면으로 넘어가는 좋은 연결고리입니다. 저는 프로그램을 더 잘 만드는 방법을 찾고 있었고, ZIO 등을 통해 결국 이펙트를 선택하게 된 것은 제가 프로그램을 더 잘 만들 수 있도록 도와주었습니다. 하지만 데이터 관리는 어떻게 이루어져야 할까요? 여전히 가장 일반적인 접근 방식은 클라이언트-서버 아키텍처입니다.

요하네스 쉬클링 (36:28): 그리고 클라이언트를 신뢰하지 않습니다. 모든 진실의 원천은 서버에 있으며, 오늘날 대부분의 앱이 그렇게 만들어집니다. Ruby on Rails, Next.js 등을 사용하면 가장 쉽게 만들 수 있는 방법이기도 합니다. 하지만 그런 종류의 아키텍처에는 많은 문제가 있습니다. 확장성이 그중 하나입니다. 하지만 확장하지 않더라도...

요하네스 쉬클링 (37:06): ... 확장성은 너무 많은 설계 트레이드오프를 주도하는 북극성이었고, 확장에 도달하는 것은 여전히 매우 어렵지만, 그 규모에 도달하지 않는 앱을 만드는 것은 암묵적으로 다른 경로를 불가능하게 만드는 몇 가지 트레이드오프를 따랐습니다.

제임스 워드 (37:34): 이 문제가 발생할 때마다 항상 듣는 말이 있습니다. "GitHub는 단일 MySQL 데이터베이스에서 실행됩니다. 따라서 단일 데이터베이스로도 충분히 확장할 수 있습니다."와 같은 말입니다. 사람들은 항상 단일 데이터베이스로 무한히 확장할 수 있다고 말합니다. 네, 저도 동의합니다. 항상 옳은 생각은 아닐 수 있습니다.

알 수 없음 (37:54): 하지만 로컬 퍼스트의 세부 사항이 궁금합니다. HTML5에 두 가지 형태의 내장 데이터베이스, SQL과 키 데이터 저장소가 있다는 사실조차 몰랐습니다. 방금 알게 되었는데, 모든 데이터가 내 컴퓨터에 저장되지만 어떤 종류의 복제가 발생하거나 무언가가 있고, 그러면 서버에 복제되더라도 내 데이터가 어떻게 비공개로 유지되는지 궁금합니다.

요하네스 쉬클링 (38:33): 로컬 퍼스트에 대해 들어본 적이 없는 분들을 위해 잠시 후에 자세히 설명해 드리겠습니다. 몇 가지 소개를 하자면, 로컬 퍼스트에 대한 표준적인 자료는 Ink & Switch의 사람들이 쓴 것입니다. 그들은 2018년에 로컬 퍼스트에 대한 에세이를 썼고, 로컬 퍼스트의 문제점과 이상적인 모습을 설명했습니다.

요하네스 쉬클링 (39:04): 로컬 퍼스트는 GraphQL이나 gRPC와 같은 구체적인 기술이 아닙니다. 로컬 퍼스트는 소프트웨어를 구축하는 방법에 대한 아키텍처적 아이디어이며, 특정 이점을 제공합니다. 그들은 그것을 이상이라고 표현합니다. 이상 중 하나는 스피너를 최소화해야 한다는 것입니다. 우리가 매일 사용하는 소프트웨어에는 너무 많은 스피너와 로딩 상태가 있습니다.

요하네스 쉬클링 (39:39): 그 이상을 간략하게 살펴보겠습니다. 스피너 없음 외에도 웹에서 한 장치에 작업이 갇혀 있지 않습니다. 이제 점점 더 많은 협업 소프트웨어가 있지만, Google Docs나 Figma와 같이 진정으로 협업적인 소프트웨어는 여전히 드뭅니다. 실제로 그러한 협업을 달성하려면 아키텍처도 바꿔야 합니다. 하지만 그것은 또 다른...

제임스 워드 (40:11): ... 실시간 협업과 같은 것이죠.

요하네스 쉬클링 (40:13): 네, 실시간 협업이지만 오프라인 상태에서도 작동하는 협업입니다. 세 번째 이상은 네트워크가 선택 사항이라는 것입니다. 이것은 또 다른 정말...

제임스 워드 (40:27): ... 비행기에 타고 있지 않다면 말이죠. 오래된 블로그 게시물을 참조한 것 같은데...

요하네스 쉬클링 (40:34): 네, 하지만 예를 들어 이틀 전에 저는 기차에서 4시간을 보냈고, 요즘은 기차에서 자주 작업하기 때문에 어떤 소프트웨어가 기차에서 사용하기에 적합하고 어떤 소프트웨어가 그렇지 않은지 정확히 알고 있습니다.

제임스 워드 (40:52): 저는 항상 오프라인 상태입니다. 제가 선택해서가 아니라 크레스트뷰트의 휴대폰 네트워크가 많은 사람이 있을 때 작동하지 않거나 여기에서 덴버로 운전할 때 작동하지 않기 때문입니다.

요하네스 쉬클링 (41:07): 기차에서 어려운 점은 비행기처럼 연결이 전혀 끊어지지 않는다는 것입니다. 멋진 기내 와이파이를 사용하지 않는다고 가정하면 말이죠. 완전히 오프라인 상태라면 오프라인 기능에 대해 의도적으로 노력한 대부분의 소프트웨어는 기본적으로 "오프라인 상태입니다. 모든 기능이 저하되지만 적어도 의도적으로 작동하는 방식이 있습니다."라고 감지합니다. 최악의 경우는 연결 상태가 좋지 않을 때 앱...

요하네스 쉬클링 (41:44): ... 또는 시스템이 "온라인 상태이고 온라인 상태에서만 가능한 모든 작업을 수행하려고 합니다."라고 생각하지만 실제로는 연결 상태가 매우 좋지 않은 경우입니다. 이 경우 소프트웨어는 정말 나빠지고, 기차에 탔을 때 기본적으로 발생하는 현상입니다.

제임스 워드 (42:00): Spotify가 이 문제에 있어서 최악입니다. 여기에서 30분 거리에 있는 거니슨으로 운전할 때 서비스가 불안정한 곳이 있는데, Spotify는 그 상황을 전혀 처리하지 못해서 음악을 들을 수 없어서 답답합니다. Spotify는 로컬 퍼스트로 전환해야 합니다.

요하네스 쉬클링 (42:17): 맞습니다. 재미있게도 그것이 제가 현재 작업 중인 주요 프로젝트입니다. 저는 음악을 듣기 위해 Spotify 계정을 가져오지만, 음악이 어디에 있든 프리미엄 타사 클라이언트를 새로 만들려고 노력하고 있습니다.

제임스 워드 (42:42): 기차를 타고 이동하면서 서비스가 좋았다 나빴다 하더라도 신경 쓰지 않아도 되는 것이죠.

요하네스 쉬클링 (42:51): 맞습니다. 하지만 지금까지 우리는 스피너 없음, 한 장치에 작업이 갇혀 있지 않아야 함, 실시간 협업, 네트워크 선택 사항에 대해 이야기했습니다. 이것들은 소프트웨어의 목표입니다. 구체적인 구현 세부 사항이 아닙니다. 몇 가지 구현을 간략하게 살펴보겠습니다.

제임스 워드 (43:13): 실시간 협업 외에도 실시간 상태 또는 실시간 데이터 연결을 추가하고 싶습니다. 협업은 한 부분이라고 생각하지만, 스피너 없음, 새로 고침 버튼 없음에 추가하고 싶습니다. 새로 고침 버튼이 있는 웹 페이지는 정말 싫습니다. 데이터가 변경된 것을 알고 있다면 바보 같은 버튼을 누르게 하지 말고 그냥 보여주세요.

요하네스 쉬클링 (43:41): 맞습니다. 다른 부분을 잘 처리했다면 이 부분은 비교적 쉽게 해결할 수 있어야 합니다. 이것은 단지 클라이언트 측의 반응성일 뿐입니다. 하지만 이것은 서버 중심 모델의 직접적인 결과이기도 합니다. 분산 시스템 전체에서 이동하는 데이터를 조정하는 것이 너무 어려워서 제품 관리자가 "좋아, 2년 동안 모든 것을 다시 만들지는 않을 거야. 그냥 버튼을 구현하고 서버에서 모든 것을 다시 로드할 거야."라고 말하는 것이 더 쉬운 선택입니다. 아키텍처를 바꿔야 하기 때문입니다. 약간의 캐싱을 추가하고, 데이터를 푸시하는 웹소켓을 추가하더라도 처음부터 이런 방식으로 만들지 않았다면 프론트엔드의 모든 것이 오래되고 동기화되지 않을 것입니다.

요하네스 쉬클링 (44:48): 다음 네 가지 이상을 간략하게 살펴보겠습니다. 협업에는 두 가지 형태가 있습니다. 하나는 여러 장치 간의 협업입니다. 한 장치에 작업이 갇혀 있지 않아야 합니다. 휴대폰과 노트북에서 작업하는 경우가 그런 협업의 한 형태입니다. 그리고 동료와의 협업이 있습니다. 다섯 번째 이상은 그들이 롱 나우라고 부르는 것입니다. 기본적으로 오늘날 우리가 사용하는 대부분의 소프트웨어는...

요하네스 쉬클링 (45:21): ... 구독료를 지불하는 한 작동하고 소프트웨어 공급업체가 사업을 계속하는 한 작동하는 SaaS 소프트웨어입니다. 우리는 모두 한때 사용했지만 지금은 더 이상 사용할 수 없는 Google 제품 10가지를 알고 있습니다. 그중 많은 제품이 로컬 퍼스트로 만들어졌다면 Google 리더는 훌륭하게 로컬 퍼스트로 만들어졌을 것이고, 우리는 오늘날에도 여전히 사용할 수 있었을 것입니다. 하지만 그들은 서버 중심, 클라우드 중심으로 만들었습니다.

제임스 워드 (45:56): ... 실행 중입니다.

요하네스 쉬클링 (45:57): ... 몇십 년 전의 DOS 소프트웨어와 달리 컴퓨터가 여전히 작동하는 상태라면 몇십 년 전의 소프트웨어도 여전히 실행될 것입니다. 마지막으로 사용했던 상태 그대로 말입니다. 하지만 5년 전의 SaaS 소프트웨어에는 적용되지 않습니다.

요하네스 쉬클링 (46:20): 그래서 롱 나우의 아이디어는 우리가 엄청난 소프트웨어를 만들지만 5년 후에는 아마도 접근할 수 없고 사라질 것이라는 것입니다. 그것은 꽤 무서운 일입니다.

제임스 워드 (46:34): 오래전에는 로컬 퍼스트였지만 분산되어 있지 않았던 진자가 클라이언트-서버로 넘어갔다고 말씀하시겠습니까? 아마도 클라이언트-서버로 시작해서 로컬 퍼스트로 갔다가 다시 클라이언트-서버로 돌아왔고, 이제 다시 로컬 퍼스트로 돌아가고 있다고 말씀하시겠습니까?

요하네스 쉬클링 (46:59): 당시에는 로컬 전용이었고, 네트워크의 등장으로...

알 수 없음 (47:04): ... 네트워크가 없었습니다.

요하네스 쉬클링 (47:06): 네, 네트워크가 서서히 들어오면서 Dropbox와 같은 흥미로운 중간 단계가 있었습니다. 동기화할 수 있는 파일이 있었고, 어느 순간 모든 것에 클라우드를 붙일 수 있었고, 모든 것이 더 좋아졌습니다. 그 결과를 이해하기 전까지는 말이죠. 이제 로컬 퍼스트는 그 결과를 해결하려고 노력하고 있습니다.

요하네스 쉬클링 (47:33): 그래서 저는 진자가 이전 위치로 다시 돌아갔다고 생각하지 않습니다. 이전 위치의 장점, 클라우드의 장점, 그리고 이제 두 가지 장점을 모두 활용하는 방법을 모색하고 있습니다. 그리고 저는 로컬 퍼스트의 아이디어와 마지막 두 가지 아이디어, 즉 기본적으로 보안과 개인 정보 보호 기능을 제공하고 데이터를 소유하고 제어할 수 있다는 점에서 잘 표현되었다고 생각합니다. 대부분의 클라우드 소프트웨어에서는 그렇지 않습니다.

알 수 없음 (48:03): 특히 데이터를 소유하고 제어한다는 두 가지 사항에 대해 알고 싶습니다. 왜냐하면 우리는 여전히... 데이터가 내 컴퓨터에 있고 서버에 복제되면 내 컴퓨터에서만 해독할 수 있는 방식으로 암호화된다고 상상하고 있습니다. 그런 식으로 작동하나요? 어떻게 작동하나요?

요하네스 쉬클링 (48:26): 네, 이제 우리는 엔지니어로서 그것이 어떻게 작동하는지, 어떻게 구현되는지, 그리고 어떻게 믿을 수 있는지 이해하고 싶어 합니다. 로컬 퍼스트 소프트웨어를 구현하는 일반적인 방법은 예를 들어 CRDT를 사용하는 것입니다. CRDT의 약자는... 생각해 보겠습니다.

제임스 워드 (49:01): 잊어버렸습니다. CFRDT라고 하면 글자가 너무 많아서 좋지 않을 것입니다.

요하네스 쉬클링 (49:07): CRDT의 아이디어는 기본적으로... 직접 사용해 보고 직관을 형성하는 것이 가장 쉬운 방법입니다. 하지만 기본적으로 CRDT는 상태를 모델링하고 사용하면 장치 간에 자동으로 동기화되는 데이터 유형을 제공합니다. 그리고 이것은...

제임스 워드 (49:34): ... 분산 상태이고, 시스템 간에 데이터가 이동할 수 있는 방법에 대한 법칙을 정의하는 대수를 생각해 내는 것이지만, 너무 수학적인 설명일 수 있습니다.

알 수 없음 (49:49): 저는 대수가 필요하다고 생각합니다. 꼭 이해하고 싶지는 않지만, "네, 우리는 이것이 작동한다는 것을 확인했습니다."라는 것을 알고 싶습니다.

요하네스 쉬클링 (50:01): 맞습니다. 핵심 아이디어는 로컬에서 앱을 만들 때, 예를 들어 메모 앱이나 무엇이든 만들 때, 나중에 REST 엔드포인트에 게시하는 방법에 대해 생각하는 대신 일반적인 자바스크립트 변수에 할당하는 대신 CRDT를 사용하여 상태를 저장하는 것입니다. CRDT에는 일반적으로 네트워크 어댑터 등이 있습니다. 그리고 나서 인스턴스 간에 작동합니다.

요하네스 쉬클링 (50:39): 이러한 것들은 종종 인증 등을 고려합니다. Rust 기반의 Automerge와 같은 몇 가지 주목할 만한 기술이 있습니다. 따라서 언어 생태계 전반에 걸쳐 작동합니다. Yjs는 또 다른 매우 일반적인 자바스크립트 CRDT 구현입니다. CRDT는 로컬 퍼스트 소프트웨어를 구축하는 가장 일반적인 접근 방식이며, 기본적으로 대부분의 속성을 제공합니다. 여전히 처리해야 할 부분이 있지만...

요하네스 쉬클링 (51:12): ... 그것은 파레토 원칙과 같습니다. 그렇게 하면 거의 모든 것을 얻을 수 있습니다.

제임스 워드 (51:25): CRDT에 대한 추가 정보입니다. 몇 년 전에 Hoku에서 함께 일했던 마크 맥그래너핸과 에피소드를 녹음했습니다. 그는 로컬 퍼스트 앱을 만들었는데, 당시에는 그 용어를 사용하지 않았을 것입니다. 아마도 그 용어가 존재하지 않았을 것입니다. 하지만 우리는 마크와 함께 CRDT와 다양한 CRDT의 종류, 그리고 왜 유용한지에 대해 심층적으로 논의했습니다. 유용한 에피소드입니다. 그리고 Lightbend가 서버리스라고 불렀던 것에 대해 조나스 보네어와 에피소드를 녹음했습니다.

제임스 워드 (51:56): ... 이제는 Calyx라고 불리는 것 같습니다. CRDT 프레임워크입니다. 따라서 과거에 CRDT에 대한 에피소드가 몇 개 있습니다. 하지만 로컬 퍼스트를 "좋아, 이러한 모든 이유로 로컬 퍼스트를 사용하고 싶어. 아키텍처적으로 몇 가지 어려움이 있습니다. REST보다 어렵습니다. REST는 개념적으로 매우 간단합니다. 단일 데이터베이스를 사용하는 REST는 이해할 수 있습니다."라고 생각하는 것은 흥미롭습니다.

제임스 워드 (52:26): 네, 맞습니다. 하지만 로컬 퍼스트로 전환하면 데이터를 처리하는 방식에 대해 다른 접근 방식이 필요할 것입니다. 그리고 CRDT는 현재까지 우리가 발견한 가장 좋은 방법입니다.

요하네스 쉬클링 (52:40): 네, 많은 로컬 퍼스트 앱을 구축하는 매우 견고한 방법이라고 생각합니다. 저는 개인적으로 다른 데이터 패러다임을 기반으로 탐구하고 있으며, 그것은 주로 이벤트 소싱입니다. 자세히 살펴보면 이벤트 소싱과 CRDT 사이에는 많은 유사점이 있습니다. 하지만 트레이드오프가 다릅니다. 과거에 데이터베이스 스키마 마이그레이션을 처리하면서 겪었던 트라우마 때문에 이벤트 소싱에 관심이 있습니다.

요하네스 쉬클링 (53:16): 그리고 CRDT는 기본적으로 그 문제를 해결하지 못하기 때문에 읽기 모델과 쓰기 모델을 조금 더 분리할 수 있는 기반에 관심이 있었습니다. 그래서 저는 이벤트 소싱과 이벤트 로그를 장치 간에 동기화하는 방법이 로컬 퍼스트 소프트웨어를 가능하게 할 수 있는지 탐구하고 있습니다. 그것이 제가 Overtone이라는 음악 앱을 만드는 데 사용하고 있는 방법입니다. 그리고 저는 그것을 오픈 소스화할 생각도 하고 있습니다.

제임스 워드 (53:51): 그 경우에는 CRDT를 사용할 필요가 없었군요. 이벤트 소싱만으로도 충분했으니까요.

요하네스 쉬클링 (53:58): 네, 그리고 덧붙이자면, 저는 로컬 퍼스트 이상을 모두 충족하는 소프트웨어를 구축하는 데 매우 단순한 접근 방식을 사용할 수 있다고 생각합니다. 저는 기본적으로 JSON blob을 가지고 있고, 항상 전체 JSON blob을 전선으로 전송하는 사람들을 보았습니다. 그들은 매우 단순한 마지막 작성자 우선 방식을 사용합니다. 따라서 그런 방식으로도 해결할 수 있습니다.

제임스 워드 (54:35): 거기에도 대수가 있습니다. 그것을 CRDT로 분류할 수 있을지 모르겠지만, 기본적으로 데이터 충돌 해결 규칙을 정의하는 대수를 정의한 것입니다. 그리고 그것이 궁극적으로 CRDT가 제공하는 것입니다. 충돌 해결입니다. 시스템의 진정한 상태를 어떻게 알 수 있을까요?

요하네스 쉬클링 (55:01): 맞습니다. 하지만 클라이언트-서버 아키텍처에서 온 전통적인 웹 개발자는 몇 가지 측면에서 사고방식을 바꿔야 한다고 생각합니다. 가장 큰 변화는 서버 중심적인 책임을 모두 내려놓는 것입니다. 저는 처음부터 서버를 사용하지 않도록 강요함으로써 그렇게 하도록 했습니다. 모든 것이 클라이언트에서 이루어져야 합니다. 그리고 많은...

요하네스 쉬클링 (55:39): ... 웹의 경우 교차 출처와 같은 CORS 문제 등을 해결해야 합니다. 하지만 클라이언트를 신뢰하고 클라이언트가 앱이 해야 할 모든 작업을 수행하도록 사고방식을 바꾸면... 메모 앱, 메일 클라이언트, 음악 클라이언트의 경우 기본적으로 모든 작업이 클라이언트에서 이루어져야 합니다. 그래서 메일 클라이언트라고 불리는 것입니다.

제임스 워드 (56:18): 단순한 클라이언트가 아니라 실제 메일 클라이언트입니다.

요하네스 쉬클링 (56:23): 맞습니다. 그리고 웹 기술 등은 잠재력을 활용하면 놀라울 정도로 강력하다는 것이 밝혀졌습니다.

제임스 워드 (56:38): 하지만 몇 가지 어려움이 있습니다. 일반적으로 성능이 뛰어난 UI를 만들 때 UI 스레드를 차단하고 싶지 않습니다. 웹 워커를 사용할 수 있지만, 동시성을 처리하는 데 도움이 되는 프레임워크가 없다면 어려울 것입니다. 그렇다면 이펙트와의 연결 고리가 있을까요? 이펙트를 사용하면 로컬 퍼스트를 더 쉽게 만들 수 있을까요?

요하네스 쉬클링 (57:07): 여기서 저는 앱 개발자로서의 모습뿐만 아니라 라이브러리 도구 제작자로서의 모습도 보여드려야 합니다. 저는 로컬 퍼스트 데이터 스택이 어떤 모습일지 탐구하는 방법이 이벤트 소싱의 아이디어를 따르고 있다고 간략하게 언급했습니다. 그리고 저는 LiveStore라는 새로운 데이터 레이어를 만들고 있습니다. LiveStore는 방금 언급한 모든 문제, 즉 UI 스레드를...

요하네스 쉬클링 (57:44): ... 제어하고 차단하지 않으면서 동시 데이터 편집, 동기화, 지속성 등을 처리할 수 있는 합리적인 방법을 제공하는 것을 목표로 합니다.

제임스 워드 (57:58): 여기서 더 중요한 것은 부작용을 구분하는 기본 요소입니다. 이것이 중요한가요, 아니면 있으면 좋은 정도인가요?

요하네스 쉬클링 (58:07): LiveStore 라이브러리를 만들기 위해 저는 이펙트를 많이 사용하고 있습니다. 아마도 이펙트로 만들어진 라이브러리와 도구 중에서 이펙트 기능의 가장 넓은 영역을 사용하는 것 중 하나일 것입니다. 왜냐하면 기본적으로 너무나 많은 분산 시스템 문제를 다루기 때문입니다. 워커 간에 작동해야 합니다. 따라서 메인 스레드와 작동해야 하고, 다양한 종류의 워커 스레드와 작동해야 합니다.

요하네스 쉬클링 (58:41): 웹 앱이 여러 탭에서 실행될 수 있고, 거기에서도 동기화가 이루어져야 하기 때문입니다. 실제로 일종의 리더 선출을 해야 합니다. 따라서 OPFS 또는 IndexedDB와 같은 것에 쓸 때 데이터 지속성이 충돌하지 않습니다.

제임스 워드 (59:04): 탭 간 리더 선출을 위해 CRDT를 사용해야 합니다.

요하네스 쉬클링 (59:08): 저는 웹 록을 사용하고 있습니다. 현재는 꽤 안정적이라고 생각하지만, 이 모든 것을 처리하기 위해서는 잘못될 수 있는 부분이 많습니다. 그래서 저는 이펙트를 많이 사용하고 있습니다. 또한 모든 것이 매우 동적이고 유동적입니다. 사용자가 탭을 종료할 수 있고, 다른 탭이 리더 역할을 맡아야 합니다. 그 탭은 정리 작업을 수행하고 리소스를 확보해야 할 수 있습니다. 따라서 모든 수명 주기 관리 작업...

요하네스 쉬클링 (59:43): ... 올바르게 처리하는 것이 절대적으로 중요합니다. 또한 탭 간, 워커 간에 많은 메시징이 있습니다. 상태를 올바른 방식으로 전파하고 특정 규칙을 적용해야 합니다. 예를 들어 이펙트에는 STM이라는 모듈이 있습니다. ZIO에도 있다고 생각합니다. 이러한 경우에 매우 유용합니다. 그리고 앞으로 제가 많이 사용하게 될 가장 멋진 것 중 하나는 이펙트 클러스터 또는 이펙트 워크플로우라는 새로운 이펙트 모듈입니다.

요하네스 쉬클링 (1:00:17): 액터 시스템 또는 지속적인 워크플로우의 아이디어를 이펙트에 최우선으로 가져오려는 시도입니다. 이러한 워크플로우에 대한 지속성도 제공됩니다. 아마도 1년 후에 제가 사용하는 것에 대해 이야기할 수 있을 것입니다. 이미 알파 버전으로 출시되었으므로 관심 있는 분들은 확인해 보세요. 하지만 네, 이렇게...

제임스 워드 (1:00:45): 흥미로운 점은 클라이언트-서버 애플리케이션이 있고 클라이언트가 브라우저라는 것입니다. 분산 시스템이 없다고 생각하지만 누군가가 두 번째 탭에서 사이트를 열면 분산 시스템이 됩니다. 그리고 그것이 바로 요하네스 님의 요점입니다. 이제 두 개의 다른 탭에서 상태를 어떻게 처리해야 할까요? 그것만으로도 어려운 문제입니다.

요하네스 쉬클링 (1:01:08): LiveStore를 통해 가능하게 하고 싶은 핵심 아이디어 중 하나는 UI 스레드에서 동기식 쿼리를 수행할 수 있도록 하는 것입니다. 변수에 액세스할 때 대부분의 경우 동기식으로 변수의 내용을 가져오고 싶어 하고, 특정 경우에만 비동기식으로 가져옵니다. LiveStore의 아이디어는 항상 최신 상태를 유지하는...

요하네스 쉬클링 (1:01:42): ... 모든 상태와 데이터를 제공하는 반응형 메모리 내 SQLite 버전을 제공하는 것입니다. 하지만 메인 스레드에서는 실제로 지속성을 수행할 권한이 없는 경우가 많습니다. 그리고 메인 스레드에서 너무 많은 작업을 수행하고 싶지 않습니다. 그래서 저는 지속성을 처리하는 워커를 사용하고 있습니다. 따라서 단일 탭의 경우에도 메인 스레드가 웹 워커와 최신 상태를 유지해야 하는 분산 시스템 문제가 이미 있습니다.

요하네스 쉬클링 (1:02:14): 지속성과 반응형 메모리 내부뿐만 아니라 장치 간에 동기화할 때도 배포해야 합니다. 따라서 대부분의 자바스크립트 타입스크립트 개발자가 매일 분산 시스템 문제를 다루고 있지만 그 용어를 들어본 적이 없다는 것은 흥미로운 점입니다.

제임스 워드 (1:02:40): 네, 그렇다면 함수형 프로그래밍과 이펙트의 기초를 갖추는 것이 이러한 문제를 더 쉽게 이해하고 해결책을 찾는 데 도움이 될 수 있다는 것을 알 수 있습니다. 네, 로컬 퍼스트와 로컬 퍼스트는 어떤 면에서 우리가 원하든 원하지 않든 분산 시스템의 세계에 살고 있다는 것을 인정하는 것이라고 생각합니다. 그리고 함수형 프로그래밍과 이펙트는 분산 시스템의 복잡성을 처리하는 데 도움이 되는 훌륭한 도구입니다.

요하네스 쉬클링 (1:03:16): 맞습니다. 서로 매우 직교적이지만 하나는 다른 하나를 처리하는 아름다운 방법입니다.

제임스 워드 (1:03:25): 네. 그리고 CRDT와 이벤트 소싱은 다른 전략이지만, 업계에서는 우리가 구축하고 있는 것들의 복잡성을 무시해 왔다고 생각합니다. 그리고 어떤 면에서는 우리는 언어와 프레임워크가...

제임스 워드 (1:03:50): ... 더 나은 추상화를 만들어서 실제로 그러한 복잡성을 무시할 수 있기를 기다려 왔습니다. 그리고 요하네스 님이 LiveSync, LiveStore로 하고 있는 것이 바로 그것인 것 같습니다. 데이터 동기화와 분산 시스템의 복잡성에 대해 생각하지 않아도 되도록 올바른 작업을 수행하는 추상화를 만드는 것입니다. 네, 멋지네요.

요하네스 쉬클링 (1:04:16): 맞습니다. 분산 시스템, 특히 다른 것보다 더 많은 트레이드오프가 있는 분산 시스템에서는 만능 해결책이 될 수 없습니다. LiveStore는 상태를 생각하는 방식에 SQLite를 사용하고 싶어 하고 데이터 흐름 방식에 이벤트 소싱을 사용하고 싶어 하는 사람들에게 유용할 수 있습니다.

요하네스 쉬클링 (1:04:41): 그것이 마음에 든다면 LiveStore가 흥미로울 수 있습니다. 하지만 다른 실행 가능한 옵션도 많이 있다고 생각합니다. CRDT는 시작하기에 매우 좋으며, 사용 사례에 적합한지 확인해 볼 수 있습니다. 그리고 분명히 다른 접근 방식도 많이 있을 것입니다.

제임스 워드 (1:04:58): CRUD의 시대가 끝났다는 것을 인정할 수 있는 시점에 이르렀다는 것이 기쁩니다. 왜냐하면 우리의 요구 사항이 CRUD가 제공할 수 있는 것보다 훨씬 더 발전했기 때문입니다.

알 수 없음 (1:05:13): 글쎄요, 항상 수준이 있습니다. 우리는 항상 세부적인 것들에 대해 생각하지 않아도 되도록 추상화 수준을 높이려고 노력하고 있습니다.

요하네스 쉬클링 (1:05:23): 네. 그리고 그것이 로컬 퍼스트의 아름다운 점입니다. 새로운 것이 있을 때마다 "아, 추가로 해야 할 일이 있구나."라고 생각하지만, 로컬 퍼스트의 멋진 점은 일단 배우고 나면 처리해야 할 일이 훨씬 줄어듭니다. 이상적인 경우에는 클라이언트만 만들고, React를 사용할 때처럼 매우 원칙적인 데이터 스택을 사용합니다.

요하네스 쉬클링 (1:05:52): DOM이 어떻게 조정되고 이벤트가 어떻게 흐르는지 생각할 필요가 없습니다. 그냥 사용하면 됩니다. 이제 데이터에도 그렇게 합니다. 서버를 만들 필요가 없습니다. 동기화는 그냥 작동합니다. 설계하고 구축해야 할 것이 훨씬 줄어듭니다. 제가 이전에 본 어떤 것보다 복잡성을 단순화하고 줄입니다.

알 수 없음 (1:06:10): 녹음을 시작하기 전에 타입스크립트가 어떻게 될 것이라는 주장을 했습니다. 타입스크립트가 모든 것을 지배할 것이라고 했는데, 저는 질문을 참았습니다. 웹어셈블리를 고려하고 있나요? 웹어셈블리는 자바스크립트에 얽매이지 않은 새로운 것들을 많이 가져오는 것 같습니다.

제임스 워드 (1:06:48): 네, 저는 타입스크립트를 사용하고 싶지 않습니다. 자바스크립트와 관련된 어떤 것도 하고 싶지 않습니다. 자바스크립트는 만지면 죽을 것 같은 독과 같습니다. 그래서 웹어셈블리 덕분에 타입스크립트를 사용하지 않아도 됩니다.

요하네스 쉬클링 (1:07:01): 네, 분명히 매우 밝은 희망의 빛이며 저도 매우 기대하고 있습니다. 저는 실제로 Overtone, 즉 제가 만들고 있는 음악 앱과 LiveStore에서 웹어셈블리를 많이 사용하고 있습니다. 저는 SQLite를 WASM에서 실행하고 있습니다. 성능이 중요한 부분을 위해 현재 타입스크립트로 작성된 LiveStore 구현의 더 많은 부분을 Rust로, 따라서 WASM으로 옮길 것입니다. WASM 컴포넌트와 점점 더 많은 기능을 통해...

요하네스 쉬클링 (1:07:32): ... 그리고 아마도 WASM을 통해 브라우저에서 타입스크립트 또는 자바스크립트보다 더 나은 멀티스레딩을 얻을 수 있을 것입니다. 따라서 저는 그 가능성에 매우 흥분하고 있습니다. 아직 확신하지는 못하지만, 도구 제작자 또는 매우 정교한 앱 제작자를 위한 기반이자 경기장이 될 것이라고 생각합니다. 하지만 대부분의 애플리케이션은 여전히 타입스크립트로 작성될 것이라고 생각합니다. 따라서 대부분의 앱 개발자는...

요하네스 쉬클링 (1:08:13): ... 타입스크립트를 사용할 것이라고 생각합니다.

제임스 워드 (1:08:18): 확실히 그럴 것입니다.

요하네스 쉬클링 (1:08:20): 그리고 또 다른 변수는 AI가 얼마나 빨리 성숙하고 발전하는가입니다. 세상은 이미 완전히 바뀌었습니다. 2018년의 구직 시장을 생각해 보면, 2개월짜리 부트캠프를 수료하면 높은 연봉을 받을 수 있을 것 같았습니다. 하지만 지금은 꽤 유능한 엔지니어들도 일자리를 구하는 데 어려움을 겪고 있습니다. 따라서 시장에는 일종의 조정이 있다고 생각합니다.

요하네스 쉬클링 (1:08:57): 엔지니어링 팀의 규모는 어느 정도여야 할까요? 엔지니어링 작업은 더 효율적으로 변하고 있습니다. 아마도 경험이 부족한 사람들 중 일부는 밀려날 것이고, 아마도 선택된 도구와 언어도 바뀔 것입니다. 매우 역동적이지만, 저는 여전히 타입스크립트가 대부분의 앱 개발을 지배할 것이라고 생각합니다.

알 수 없음 (1:09:19): 적어도 가까운 미래에는 말이죠.

제임스 워드 (1:09:21): 네, 이펙트가 존재해서 다행입니다. 제 미래가 타입스크립트라면 적어도 이펙트가 있습니다.

요하네스 쉬클링 (1:09:32): 타입스크립트의 많은 부분이 얼마나 인체공학적인지 알면 놀랄 것입니다. 자바스크립트의 많은 부분이 얼마나 원칙이 없는지 증명될 것입니다. 하지만 대부분의 작업에 이펙트를 사용하면 심연을 너무 많이 들여다볼 필요가 없을 것입니다.

제임스 워드 (1:09:59): 네, 맞습니다. 이펙트는 나쁜 부분으로부터 보호해 줍니다. 이펙트의 슬로건은 "독으로부터 보호"가 되어야 합니다. 요하네스 님, 다른 흥미로운 점이 있나요?

요하네스 쉬클링 (1:10:17): 로컬 퍼스트에 대해 더 자세히 알고 싶은 분들을 위해 저는 "Local First FM"이라는 로컬 퍼스트 팟캐스트도 운영하고 있습니다. 관심 있는 분들은 들어보세요. 저도 좋아합니다.

알 수 없음 (1:10:31): 논문이 있고, 에피소드 노트에 논문과 팟캐스트 링크를 추가할 수 있습니다.

요하네스 쉬클링 (1:10:39): 그리고 우리가 이펙트에 대해 많이 이야기했으므로, 타입스크립트를 사용하고 있고 아직 이펙트를 사용하지 않았거나 확인해 보지 않았다면 꼭 사용해 보세요. 우리는 점점 더 많은 예제를 만들고 있습니다. 1년 전에는 문서가 없었고, 그것이 가장 일반적인 피드백이었습니다. 지금은 매우 광범위하고 훌륭한 문서가 있습니다. 우리는 훌륭한 커뮤니티를 가지고 있고, 매우 멋지게 성장하는 생태계를 가지고 있습니다. 우리는 매우 활발한...

요하네스 쉬클링 (1:11:09): ... Discord 커뮤니티를 가지고 있습니다. 따라서 이제 막 시작했고 아직 정신 모델을 만들고 있다면 Discord에서 질문하세요. 얼마나 빨리 고품질의 답변을 얻을 수 있는지 놀랄 것입니다.

알 수 없음 (1:11:23): 좋은 커뮤니티인가요?

요하네스 쉬클링 (1:11:26): 훌륭한 커뮤니티이며, 우리는 그렇게 유지하기 위해 최선을 다하고 있습니다.

알 수 없음 (1:11:29): 함수형 프로그래밍은 항상...

요하네스 쉬클링 (1:11:33): ... 중요한 부분은 아니었지만, 우리가 함수형 프로그래밍에 너무 집중하지 않으려고 노력한 또 다른 이유였습니다. 하지만 타입스크립트 생태계에도 드라마가 있습니다. 따라서 우리는 한 가지에 너무 집착하지 않으려고 노력합니다. 우리는 서로 친절하게 대하고, 도움이 되려고 노력하고, 존중하려고 노력합니다. 지금 우리가 있는 곳은 매우 좋습니다.

제임스 워드 (1:12:05): 이펙트 Discord 커뮤니티는 정말 훌륭합니다. 친절하고 도움이 되는 사람들이 많고, 매우 따뜻한 커뮤니티입니다. 그런 커뮤니티의 일원이 되고 싶다면 Discord는 좋은 곳입니다. 훌륭합니다.

요하네스 쉬클링 (1:12:22): 저는 그곳에서 타입스크립트와 이펙트를 넘어 다른 곳보다 더 많은 것을 배웠습니다.

제임스 워드 (1:12:30): 아, 그리고 제가 여러 번 언급했던 EasyRacer에 대해서도 말씀드려야겠네요. 이제 이펙트 버전, 이펙트 타입스크립트 버전의 EasyRacer 클라이언트가 있습니다. 이펙트와 다른 많은 언어 및 프레임워크에서 다양한 구조적 동시성을 비교해 보고 싶은 분들에게는 재미있는 프로젝트입니다.

알 수 없음 (1:12:53): 좋습니다.

제임스 워드 (1:12:54): 좋습니다. 요하네스 님, 오늘 통찰력을 공유해 주셔서 정말 감사합니다.

요하네스 쉬클링 (1:12:59): 즐거운 시간이었습니다. 멋진 대화를 나눌 수 있어서 감사합니다.