원문: https://manupa.dev/blog/anatomy-of-shadcn-ui

[번역] shadcn/ui 의 해부

오늘 소개해드릴 글은 두나무의 조영제님이 번역해주신 글입니다.

shadcn/ui는 출시된 이후부터 최근까지도 가장 주목받는 프로젝트 중 하나입니다. GitHub 스타 수의 증가세나 Vercel의 채팅 인터페이스 v0에서 이 프로젝트를 화면 구성의 기반으로 채택한 점만 봐도 알 수 있습니다. 또한, 최근 발표된 Chakra UI 3버전에서도 shadcn/ui와 비슷한 구조로 컴포넌트를 생성하고 관리하는 것을 보면, 여러 프로젝트에 영향을 준 것이 분명해 보입니다.
저는 처음 shadcn/ui를 접했을 때 기존에 쓰던 디자인 라이브러리와 다른 점이 흥미로웠습니다. 패키지를 단순히 import해서 사용하는 대신, 프로젝트내에 코드를 복사해 붙여넣는 방식이라 신선하게 느껴졌습니다. 왜 이런 방식을 택했는지, 또 shadcn/ui가 어떻게 구성되어 있는지 궁금해졌고, 그러다 이 글을 발견하게 되었습니다.

개인적으로, shadcn/ui의 아키텍처를 가장 잘 설명한 글이라고 생각합니다. 이 프로젝트를 기반으로 자신만의 디자인 시스템을 구축하고자 하는 프론트엔드 개발자들에게 큰 도움이 될 것 같습니다.

> https://bit.ly/4edDLQb

오늘 소개해드릴 글은 두나무의 조영제님이 번역해주신 글입니다. shadcn/ui는 출시된 이후부터 최근까지도 가장 주목받는 프로젝트 중 하나입니다. GitHub 스타 수의 증가세나 Vercel의 채팅 인터페이스 v0에서 이 프로젝트를 화면 구성의 기반으로 채택한 점만 봐도 알 수 있습니다. 또한, 최근 발표된 Chakra UI 3버전에서도 shadcn/ui와 비슷한 구조로 컴포넌트를 생성하고 관리하는 것을 보면, 여러 프로젝트에 영향을 준 것이 분명해 보입니다.저는 처음 shadcn/ui를 접했을 때 기존에 쓰던 디자인 라이브러리와 다른 점이 흥미로웠습니다. 패키지를 단순히 import해서 사용하는 대신, 프로젝트내에 코드를 복사해 붙여넣는 방식이라 신선하게 느껴졌습니다. 왜 이런 방식을 택했는지, 또 shadcn/ui가 어떻게 구성되어 있는지 궁금해졌고, 그러다 이 글을 발견하게 되었습니다. 개인적으로, shadcn/ui의 아키텍처를 가장 잘 설명한 글이라고 생각합니다. 이 프로젝트를 기반으로 자신만의 디자인 시스템을 구축하고자 하는 프론트엔드 개발자들에게 큰 도움이 될 것 같습니다. &gt; https://bit.ly/4edDLQb

스파르타코딩클럽

shadcn/ui의 해부

어느정도는 스케일링을 고려하고는 있지만, 아주 급격한 트래픽이나 external API에 대한 fallback 같은건 구현을 못하고 있어서..좀 불안한데.. 그래도 일단 이런 리스크는 그냥 안고 가야겠지.. 🫠

어느정도는 스케일링을 고려하고는 있지만, 아주 급격한 트래픽이나 external API에 대한 fallback 같은건 구현을 못하고 있어서..좀 불안한데.. 그래도 일단 이런 리스크는 그냥 안고 가야겠지.. 🫠

AVX-512 can benefit the average Joe, it appears.

FFmpeg devs boast of up to 94x performance boost after implementing handwritten AVX-512 assembly code

FFmpeg 개발팀이 손수 한땀한땀 작성한 AVX-512 어셈블리 코드로 성능을 94배 빠르게 했다고.

크.. 역시 최적화 뽕은 어셈블리가 쵝오! 어셈블리로 개발하고 싶다. 😣

https://www.tomshardware.com/pc-components/cpus/ffmpeg-devs-boast-of-up-to-94x-performance-boost-after-implementing-handwritten-avx-512-assembly-code

FFmpeg 개발팀이 손수 한땀한땀 작성한 AVX-512 어셈블리 코드로 성능을 94배 빠르게 했다고. 크.. 역시 최적화 뽕은 어셈블리가 쵝오! 어셈블리로 개발하고 싶다. 😣 https://www.tomshardware.com/pc-components/cpus/ffmpeg-devs-boast-of-up-to-94x-performance-boost-after-implementing-handwritten-avx-512-assembly-code

Tom's Hardware

Rewriting Pierre to be zero-latency • Pierre Changelog

Bootstrap을 만들었던 개발자들이 모여서 만드는 협업 도구 Pierre가 일반적인 REST API를 사용해서 서비스를 만들었다가 로컬 퍼스터 동기화 프레임워크인 Replicache를 사용해서 완전히 다시 작성했습니다.

서비스를 고도화하면서 점점 가져와야할 데이터가 많아지면서 사용자 경험이 안좋아지자 Replicache를 도입했다고 합니다. 브라우저의 IndexedDB에 저장하고 Replicache가 백엔드와 알아서 동기화하기 때문에 백엔드와 프론트엔드의 관심사를 분리해서 작성할 수 있는 장점이 있었고 다른 도구와 달리 Replicach는 인증과 엑세스 제어를 구현하는 사람에게 위임하기 때문에 서비스에 맞게 이를 구현할 수 있는 것도 큰 장점이었다고 합니다.

이렇게 로컬에 캐시를 두고 동괴화를 함으로써 Pierre의 레이턴시가 크게 개선되었는데 Pierre가 Replicache를 어떻게 사용했는지를 설명하고 있습니다.

https://docs.pierre.co/changelog/local-first

Bootstrap을 만들었던 개발자들이 모여서 만드는 협업 도구 Pierre가 일반적인 REST API를 사용해서 서비스를 만들었다가 로컬 퍼스터 동기화 프레임워크인 Replicache를 사용해서 완전히 다시 작성했습니다. 서비스를 고도화하면서 점점 가져와야할 데이터가 많아지면서 사용자 경험이 안좋아지자 Replicache를 도입했다고 합니다. 브라우저의 IndexedDB에 저장하고 Replicache가 백엔드와 알아서 동기화하기 때문에 백엔드와 프론트엔드의 관심사를 분리해서 작성할 수 있는 장점이 있었고 다른 도구와 달리 Replicach는 인증과 엑세스 제어를 구현하는 사람에게 위임하기 때문에 서비스에 맞게 이를 구현할 수 있는 것도 큰 장점이었다고 합니다. 이렇게 로컬에 캐시를 두고 동괴화를 함으로써 Pierre의 레이턴시가 크게 개선되었는데 Pierre가 Replicache를 어떻게 사용했는지를 설명하고 있습니다. https://docs.pierre.co/changelog/local-first

docs.pierre.co

버튼, Input, DatePicker 등 자주 쓰는 UI 전용 컴포넌트들이 있습니다. 익숙하지만, 이걸 처음부터 Tailwind 등을 사용해 맨땅부터 다시 컴포넌트를 다 만들기에는 작업량이 너무 방대합니다. 처음에는 UI정도라 도전을 해보지만 키입력과 겉은 상호작용도 중요하니까요. 만약 a11y처럼 접근성까지 고려한다면 너무 큰 작업이 되겠네요.

그래서 우리는 남들이 잘 만들어둔 전통적인 디자인 시스템인 MUI, Ant Design, Chakra 등을 사용했습니다. 이들 컴포넌트 구성은 탄탄하지만, 단점은 그들의 디자인을 따라야만 합니다. 그래서 디자인을 고쳐보고자 하지믄 이미 개성을 갖춘 디자인 시스템의 스타일링을 커스텀하는 건 여간 고된 일이 아니죠. 또한 그들이 만들어주지 않는 컴포넌트가 기획에서 요구되면 커스텀을 할수 없는 걸 커스텀하기 위한 고생은 아주 아찔합니다😅

기본기능만 제공하고 스타일링과 커스텀은 우리가 직접 하면 어떨까요? 그래서 Radix와 같이 기본적인 컴포넌트의 골격만 제공하고, 스타일링을 직접 하는 방식은 훨씬 더 좋은 발상이었습니다. headless의 탄생이죠. 그러나 필요한 모든 스타일링을 전부 다 처음부터하는 것은 당장은 활용하기 어려운 점이 있습니다.

shadcn/ui는 흥미로운 해법을 제시합니다. Radix의 headless 기능을 기반으로, 기본적인 구조에 깔끔하지만 개성 없는 디자인을 제공합니다.(개성없다 했지만 엄청 이쁩니다)

여기에 Tailwind를 활용한 스타일링 레이어를 통해 디자인 시스템을 구축하고, Tailwind 설정을 조정하여 개성 있는 디자인 시스템을 점진적으로 구축할 수 있습니다.

커스텀 컴포넌트를 만들기 어려운 단점은 어떻게 극복했을까요? npm 패키지가 아닌 copy-paste 방식으로 컴포넌트 코드를 직접 제공하여, TypeScript의 완벽한 타입 지원과 함께 원하는 부분을 얼마든지 커스터마이징할 수 있도록 했습니다.

디자인 시스템과 UI컴포넌트에 범주에사 가장 핫한 점진적인 디자인 시스템을 만들기 위해 고민하고 멋진 해법을 제시한 shadcn/ui에 대한 좋은 글이 있어 공유합니다.

https://siosio3103.medium.com/shadcn-ui-%EC%9D%98-%ED%95%B4%EB%B6%80-ebd469c34614

ps: 이 글은 Korean FE Article 뉴스레터를 통해 알게 되었습니다 🙂

버튼, Input, DatePicker 등 자주 쓰는 UI 전용 컴포넌트들이 있습니다. 익숙하지만, 이걸 처음부터 Tailwind 등을 사용해 맨땅부터 다시 컴포넌트를 다 만들기에는 작업량이 너무 방대합니다. 처음에는 UI정도라 도전을 해보지만 키입력과 겉은 상호작용도 중요하니까요. 만약 a11y처럼 접근성까지 고려한다면 너무 큰 작업이 되겠네요. 그래서 우리는 남들이 잘 만들어둔 전통적인 디자인 시스템인 MUI, Ant Design, Chakra 등을 사용했습니다. 이들 컴포넌트 구성은 탄탄하지만, 단점은 그들의 디자인을 따라야만 합니다. 그래서 디자인을 고쳐보고자 하지믄 이미 개성을 갖춘 디자인 시스템의 스타일링을 커스텀하는 건 여간 고된 일이 아니죠. 또한 그들이 만들어주지 않는 컴포넌트가 기획에서 요구되면 커스텀을 할수 없는 걸 커스텀하기 위한 고생은 아주 아찔합니다😅 기본기능만 제공하고 스타일링과 커스텀은 우리가 직접 하면 어떨까요? 그래서 Radix와 같이 기본적인 컴포넌트의 골격만 제공하고, 스타일링을 직접 하는 방식은 훨씬 더 좋은 발상이었습니다. headless의 탄생이죠. 그러나 필요한 모든 스타일링을 전부 다 처음부터하는 것은 당장은 활용하기 어려운 점이 있습니다. shadcn/ui는 흥미로운 해법을 제시합니다. Radix의 headless 기능을 기반으로, 기본적인 구조에 깔끔하지만 개성 없는 디자인을 제공합니다.(개성없다 했지만 엄청 이쁩니다) 여기에 Tailwind를 활용한 스타일링 레이어를 통해 디자인 시스템을 구축하고, Tailwind 설정을 조정하여 개성 있는 디자인 시스템을 점진적으로 구축할 수 있습니다. 커스텀 컴포넌트를 만들기 어려운 단점은 어떻게 극복했을까요? npm 패키지가 아닌 copy-paste 방식으로 컴포넌트 코드를 직접 제공하여, TypeScript의 완벽한 타입 지원과 함께 원하는 부분을 얼마든지 커스터마이징할 수 있도록 했습니다. 디자인 시스템과 UI컴포넌트에 범주에사 가장 핫한 점진적인 디자인 시스템을 만들기 위해 고민하고 멋진 해법을 제시한 shadcn/ui에 대한 좋은 글이 있어 공유합니다. https://siosio3103.medium.com/shadcn-ui-%EC%9D%98-%ED%95%B4%EB%B6%80-ebd469c34614 ps: 이 글은 Korean FE Article 뉴스레터를 통해 알게 되었습니다 🙂

Medium

<디자인시스템 컴포넌트 UI 라이브러리 가장 진화된 버전 shadcn/u

뭐든 하는 사람에서 뭐든 해결하는 사람으로

[FMC] 잡부는 어떻게 성장해야 할까? ⛑️

최근 서현직님의 뉴스레터를 재밌게 읽고 있는데요!
잡부 로드맵이라니 ㅋㅋㅋㅋㅋ 재밌는 글이 있어 공유드려요!
더불어 서현직님의 뉴스레터에는 인사/채용/팀빌딩 등의 많은 내용들이 있으니 참고해보세요!

---------------------------------------
잡부들은 어떻게 성장해야 할까요? 지난 주 잡부들이 모여 무엇이든 하는 사람에서 무엇이든 해 내는 사람을 목표로 웨비나를 진행 했습니다. 그 중 잡부의 성장 로드맵을 공유해 보려고 해요.

잡부는 ‘가리지 않고 자질구레한 일을 다 하는 사람’입니다. 그런 잡부의 성장은 크게 능동성과 해결력을 기준으로 나눠볼 수 있습니다.

🙆‍♀️ 잡부 + 해결력 = 문제 해결사
🙅‍♀️ 잡부 - 해결력 = 잡일꾼
🙆‍♀️ 잡부 + 능동성 = 관리자
🙅‍♀️ 잡부 - 능동성 = 구경꾼

...(생략)
---------------------------------------
https://freemoversclub.stibee.com/p/40/

최근 서현직님의 뉴스레터를 재밌게 읽고 있는데요!잡부 로드맵이라니 ㅋㅋㅋㅋㅋ 재밌는 글이 있어 공유드려요!더불어 서현직님의 뉴스레터에는 인사/채용/팀빌딩 등의 많은 내용들이 있으니 참고해보세요! ---------------------------------------잡부들은 어떻게 성장해야 할까요? 지난 주 잡부들이 모여 무엇이든 하는 사람에서 무엇이든 해 내는 사람을 목표로 웨비나를 진행 했습니다. 그 중 잡부의 성장 로드맵을 공유해 보려고 해요. 잡부는 ‘가리지 않고 자질구레한 일을 다 하는 사람’입니다. 그런 잡부의 성장은 크게 능동성과 해결력을 기준으로 나눠볼 수 있습니다. 🙆‍♀️ 잡부 + 해결력 = 문제 해결사 🙅‍♀️ 잡부 - 해결력 = 잡일꾼 🙆‍♀️ 잡부 + 능동성 = 관리자 🙅‍♀️ 잡부 - 능동성 = 구경꾼 ...(생략)---------------------------------------https://freemoversclub.stibee.com/p/40/

freemoversclub.stibee.com

잡부(?) 로드맵 (잡부는 어떻게 성장해야 할까?)

지난 주말에 내가 클럽장으로 있는 트레바리 북클럽에서 "두려움 없는 조직"(Fearless Organization)이라는 책에 대해 이야기할 시간이 있었다. 이 책의 주제는 심리적 안전감(Psychological Safety)이 있는 조직이 훨씬 더 좋은 성과를 낸다는 것인데 아래 두 가지를 놓고 전반부와 후반부로 나눠 이야기를 나누었다.

 1. 심리적 안전감이 무엇이며 신뢰와는 어떻게 다른가?
 2. 심리적 안전감에서 중요한 포인트는 실패를 용인하는 것인데 어떤 실패가 좋은 실패일까?

먼저 이 포스팅에서는 1번 심리적 안전감은 무엇이며 신뢰와는 어떻게 다른 것인지 이야기해보고자 한다. 먼저 심리적 안전감이 제대로 만들어진 조직에서는 구성원들이 자기검열을 덜 하고 질문을 할 수 있다. 어떻게 심리적 안전감을 만들어낼 수 있을까? 이게 되려면 리더의 역할도 중요하지만 구성원들의 노력도 당연히 필요하다.

 1. 심리적 안전감을 만들어 내기 위한 리더의 노력

리더의 관점에서는 질문을 장려하고 특히 누군가 처음 용기내서 하는 질문이라면 이해가 되지 않더라도 호기심을 갖고 상대를 이해하려는 노력을 하는 것이 필요하다. 하지만 혼동하면 안되는 포인트들의 첫 번째는 심리적 안전감을 준다는 것이 모두에게 나이스해야 한다는 점은 아니라는 것이고 두 번째는 심리적 안전감을 주는 것이 성과를 내지 않아도 된다는 것을 의미하지는 않는다는 점이다.

다양한 구성원들이 자기의 의견을 피력할 수 있는 환경을 만들고 의견을 잘 듣고 밀도있게 논의해보고 명확하게 맥락과 이유를 설명하면서 다음 결정을 하는 것이 심리적 안전감이 있는 조직의 리더 모습이 아닌가 싶다.

본인의 의견을 주저없이 이야기하는 관점에서 꼭 염두에 두어야 하는 포인트는 처음 조인해서 일하는 온보딩 기간 중에 심리적 안전감을 느끼게 하는 제도적 노력 혹은 문화를 만들어내는 것이다. 아무리 좋은 인재를 뽑아도 그 사람이 처음에 본인의 생각이나 궁금증을 말하지 못한다면 좋은 인재의 채용이 큰 성과로 이루어지지 못한다. 내 관점에서 "심리적 안전감"이란 처음 조인한 구성원이 질문을 편하게 할 수 있는지 이며 이는 "신뢰"가 쌓이기 전의 상황이라 조직적이며 의식적인 노력이 필요하다. 다음은 실패를 무조건 피하려고 하거나 나쁜 것이라 생각하지 않고 실패를 잘 구분해서 장려해야하는 종류의 실패를 많이 이야기하는 것인데 이는 다음 포스팅에서 다뤄보겠다.

 2. 심리적 안전감을 만들어 내기 위한 구성원의 노력

아무리 조직에 심리적 안전감이 존재하는 곳이라 해도 그런 환경에 익숙하지 않은 사람에게는 뭔가 자기 의견을 남들과 공유한다는 것이 결코 쉬운 일이 아니다. 하루 아침에 사람이 완전히 새로운 사람으로 변화한다는 것은 아무리 동기 부여가 강해도 쉬운 일도 아니며 큰 기대를 가지고 시도했다가 잘 안되면 자기에 대한 실망도 그만큼 커진다. 또한 다른 구성원들이 안전감을 가질 수 있게 나름대로 할 수 있는 노력들에 대해 생각해봐야 한다.

내가 많이 하는 조언은 하루에 한 가지씩만 본인의 안전지대 (Comfort Zoen) 바깥으로 나가보라는 것이다. 오늘 팀 미팅에서 질문 하나 해보기, 다른 팀원이나 매니저의 의견에 대해 본인의 의견을 더해보기, 특히 처음 조인했거나 평소 질문을 안 하던 팀원이 뭔가 이야기했다가 공감해주기, 복도에서 마주친 이야기해본 적 없는 신입 팀원과 스몰톡하며 편하게 해주기 등등을 예로 들 수 있다. 하루 하나라도 조금은 불편했던 일을 매일매일 꾸준히 한다면 1년 후에는 많은 변화를 느낄 수 있을 것이라 믿는다.

요약하자면 심리적 안전감에서 가장 핵심적인 포인트는 온보딩 기간 중에 구성원이 편하게 궁금한 부분에 대해 질문을 할 수 있는 환경을 만드는 것이다. 다음 포스팅에서는 "두려움 없는 조직"에서 이야기하는 3가지 종류의 실패에 대해 이야기해보고자 한다.

마지막으로 12월부터 내년 3월까지 내가 리드하는 북클럽에서 아래 4권의 책을 같이 읽어보려고 한다. 관심있는 분들은 댓글 링크 참고!

 * 2024년 12월: Zero to One (제로 투 원)
 * 2025년 1월: Hit Refresh (히트 리프레시)
 * 2025년 2월: Measure What Matters (OKR: 전설적인 벤처투자자가 구글에 전해준 성공 방식)
 * 2025년 3월: 엔비디아 웨이

지난 주말에 내가 클럽장으로 있는 트레바리 북클럽에서 "두려움 없는 조직"(Fearless Organization)이라는 책에 대해 이야기할 시간이 있었다. 이 책의 주제는 심리적 안전감(Psychological Safety)이 있는 조직이 훨씬 더 좋은 성과를 낸다는 것인데 아래 두 가지를 놓고 전반부와 후반부로 나눠 이야기를 나누었다. <ol ><li>심리적 안전감이 무엇이며 신뢰와는 어떻게 다른가?</li><li>심리적 안전감에서 중요한 포인트는 실패를 용인하는 것인데 어떤 실패가 좋은 실패일까?</li></ol> 먼저 이 포스팅에서는 1번 심리적 안전감은 무엇이며 신뢰와는 어떻게 다른 것인지 이야기해보고자 한다. 먼저 심리적 안전감이 제대로 만들어진 조직에서는 구성원들이 자기검열을 덜 하고 질문을 할 수 있다. 어떻게 심리적 안전감을 만들어낼 수 있을까? 이게 되려면 리더의 역할도 중요하지만 구성원들의 노력도 당연히 필요하다. <ol ><li>심리적 안전감을 만들어 내기 위한 리더의 노력</li></ol> 리더의 관점에서는 질문을 장려하고 특히 누군가 처음 용기내서 하는 질문이라면 이해가 되지 않더라도 호기심을 갖고 상대를 이해하려는 노력을 하는 것이 필요하다. 하지만 혼동하면 안되는 포인트들의 첫 번째는 심리적 안전감을 준다는 것이 모두에게 나이스해야 한다는 점은 아니라는 것이고 두 번째는 심리적 안전감을 주는 것이 성과를 내지 않아도 된다는 것을 의미하지는 않는다는 점이다. 다양한 구성원들이 자기의 의견을 피력할 수 있는 환경을 만들고 의견을 잘 듣고 밀도있게 논의해보고 명확하게 맥락과 이유를 설명하면서 다음 결정을 하는 것이 심리적 안전감이 있는 조직의 리더 모습이 아닌가 싶다. 본인의 의견을 주저없이 이야기하는 관점에서 꼭 염두에 두어야 하는 포인트는 처음 조인해서 일하는 온보딩 기간 중에 심리적 안전감을 느끼게 하는 제도적 노력 혹은 문화를 만들어내는 것이다. 아무리 좋은 인재를 뽑아도 그 사람이 처음에 본인의 생각이나 궁금증을 말하지 못한다면 좋은 인재의 채용이 큰 성과로 이루어지지 못한다. 내 관점에서 "심리적 안전감"이란 처음 조인한 구성원이 질문을 편하게 할 수 있는지 이며 이는 "신뢰"가 쌓이기 전의 상황이라 조직적이며 의식적인 노력이 필요하다. 다음은 실패를 무조건 피하려고 하거나 나쁜 것이라 생각하지 않고 실패를 잘 구분해서 장려해야하는 종류의 실패를 많이 이야기하는 것인데 이는 다음 포스팅에서 다뤄보겠다. <ol start="2"><li>심리적 안전감을 만들어 내기 위한 구성원의 노력</li></ol> 아무리 조직에 심리적 안전감이 존재하는 곳이라 해도 그런 환경에 익숙하지 않은 사람에게는 뭔가 자기 의견을 남들과 공유한다는 것이 결코 쉬운 일이 아니다. 하루 아침에 사람이 완전히 새로운 사람으로 변화한다는 것은 아무리 동기 부여가 강해도 쉬운 일도 아니며 큰 기대를 가지고 시도했다가 잘 안되면 자기에 대한 실망도 그만큼 커진다. 또한 다른 구성원들이 안전감을 가질 수 있게 나름대로 할 수 있는 노력들에 대해 생각해봐야 한다. 내가 많이 하는 조언은 하루에 한 가지씩만 본인의 안전지대 (Comfort Zoen) 바깥으로 나가보라는 것이다. 오늘 팀 미팅에서 질문 하나 해보기, 다른 팀원이나 매니저의 의견에 대해 본인의 의견을 더해보기, 특히 처음 조인했거나 평소 질문을 안 하던 팀원이 뭔가 이야기했다가 공감해주기, 복도에서 마주친 이야기해본 적 없는 신입 팀원과 스몰톡하며 편하게 해주기 등등을 예로 들 수 있다. 하루 하나라도 조금은 불편했던 일을 매일매일 꾸준히 한다면 1년 후에는 많은 변화를 느낄 수 있을 것이라 믿는다. 요약하자면 심리적 안전감에서 가장 핵심적인 포인트는 온보딩 기간 중에 구성원이 편하게 궁금한 부분에 대해 질문을 할 수 있는 환경을 만드는 것이다. 다음 포스팅에서는 "두려움 없는 조직"에서 이야기하는 3가지 종류의 실패에 대해 이야기해보고자 한다. 마지막으로 12월부터 내년 3월까지 내가 리드하는 북클럽에서 아래 4권의 책을 같이 읽어보려고 한다. 관심있는 분들은 댓글 링크 참고! <ul ><li>2024년 12월: Zero to One (제로 투 원)</li><li>2025년 1월: Hit Refresh (히트 리프레시)</li><li>2025년 2월: Measure What Matters (OKR: 전설적인 벤처투자자가 구글에 전해준 성공 방식)</li><li>2025년 3월: 엔비디아 웨이</li></ul>

조직의 심리적 안전감이란 무엇일까?

https://m.trevari.co.kr/product/3b7a3b0d-3205-42ae-9259-ec08626ef986

트위터(X)에 뭔가 특별한 변화가 생기지 않는다면, 6개월 내에 메타의 스레드와 트위터의 트래픽/사용자수가 역전될 것 같음. 구체적인 숫자 분석이 있는 건 아니고, 수십년간 다양한 커뮤니티/SNS를 만들고 운영하고 사용하면서 흥망성쇠를 여러번 경험한 헤비유저로써의 느낌적인 느낌~

트위터(X)에 뭔가 특별한 변화가 생기지 않는다면, 6개월 내에 메타의 스레드와 트위터의 트래픽/사용자수가 역전될 것 같음. 구체적인 숫자 분석이 있는 건 아니고, 수십년간 다양한 커뮤니티/SNS를 만들고 운영하고 사용하면서 흥망성쇠를 여러번 경험한 헤비유저로써의 느낌적인 느낌~

YouTube에서 마음에 드는 동영상과 음악을 감상하고, 직접 만든 콘텐츠를 업로드하여 친구, 가족뿐 아니라 전 세계 사람들과 콘텐츠를 공유할 수 있습니다.

 - YouTube

여러 언어를 사용하다보면 새로운 언어를 사용할 때 다른 언어에서 되는 이런 것도 되지 않을까 하고 시도를 해보곤 합니다.

검색할 때 키워드로 사용하기도 합니다.

예를 들어 extension for Dart like Swift Extension 라던지 하는 식으로요.

예전에 저는 C#으로 클라이언트를 개발한 경험이 있는데요.

ASP.Net을 하는 친구의 소스를 원격으로 봐준 적이 있습니다.

저는 당연히 반복문 안에서 임시 변수를 선언해서 사용했는데

그 친구는 이런걸 처음 봤다고 이렇게 되는 줄 몰랐다고 했습니다.

Scope를 이해하면 당연히 할 수 있는 것이지만.

그것을 몰랐더라도 저였다면 '여기서도 선언할 수 있지 않을까?' 하고 실험해봤을 겁니다.

그러나 그 친구는 저보다 오래 .Net을 사용했음에도 불구하고 그걸 몰랐던 것이죠.

이 글은 Swift에서 정의하는 3가지 형태의 함수 선언에 대해 설명합니다.

아주 간단히 설명되어있기 때문에 [weak self] 같은 capture list는 등장하지 않네요.

#직독직해 #medium #ios #capturing #function #closure
https://youtu.be/EoBAQyurv_g

여러 언어를 사용하다보면 새로운 언어를 사용할 때 다른 언어에서 되는 이런 것도 되지 않을까 하고 시도를 해보곤 합니다. 검색할 때 키워드로 사용하기도 합니다. 예를 들어 extension for Dart like Swift Extension 라던지 하는 식으로요. 예전에 저는 C#으로 클라이언트를 개발한 경험이 있는데요. ASP.Net을 하는 친구의 소스를 원격으로 봐준 적이 있습니다. 저는 당연히 반복문 안에서 임시 변수를 선언해서 사용했는데 그 친구는 이런걸 처음 봤다고 이렇게 되는 줄 몰랐다고 했습니다. Scope를 이해하면 당연히 할 수 있는 것이지만. 그것을 몰랐더라도 저였다면 '여기서도 선언할 수 있지 않을까?' 하고 실험해봤을 겁니다. 그러나 그 친구는 저보다 오래 .Net을 사용했음에도 불구하고 그걸 몰랐던 것이죠. 이 글은 Swift에서 정의하는 3가지 형태의 함수 선언에 대해 설명합니다. 아주 간단히 설명되어있기 때문에 [weak self] 같은 capture list는 등장하지 않네요. #직독직해 #medium #ios #capturing #function #closurehttps://youtu.be/EoBAQyurv_g

youtu.be

언어에서 실험을 해보신 적 있나요?

What is the future of generative AI? Today’s generative AI trends and risks may shape enterprise technology development in 2025.

5 Generative AI Trends to Watch in 2025

🎃 2024년 연말에도 생성형 AI는 여전히 핫트렌드입니다.특히, 올해 AI 연구는 노벨상을 수상했으며, 세계 최대 기술 기업들은 AI를 가능한 한 많은 제품에 통합하고 있습니다. 미국 정부도 AI를 청정 에너지 경제를 창출하기 위한 촉진자이자 연방 지출의 전략적 축으로 평가하고 있습니다. 그렇다면 2025년에는 어떤 일이 일어날까요?

🎀 🎀 다음 빅 트렌드가 될 AI 에이전트
 * 2024년에는 코파일럿이었다면, 2025년에 AI 에이전트 사용 급증 예상
 * 반자율적이고 자가 생성된 AI에이전트는 인간이 다른 작업을 처리하는 동안 독립적으로 여러 단계의 작업을 수행 가능

🎀 🎀 보안팀에 도움이 되거나 해를 끼칠 수 있는 AI
 * 생성형 AI는 부정확한 정보 제공 가능성 및 이를 검토하기위한 많은 시간 소비 가능성 존재
   * 예) 우발적인 데이터 노출과 같은 데이터 프라이버시 위험
   * 예) 학습을 통해 기존의 피싱 이메일을 식별하는 방법을 우회하거나 무용지물로 만들수 있는 업그레이드 된 피싱 공격 가능성 그리고, 이에 대한 탐지의 어려움 또는 불가능성
 * 2025 - 데이터 프라이버시와 보안을 해치지 않도록 AI 사용에 대한 엄격한 통제와 거버넌스 신속 구현 필요. 그리고, AI로 생성된 허위 정보(오디오,비디오, 텍스트 포함)에 대한 보안과 방어 적응 및 대응 필요

🎀 🎀 AI가 ROI를 제공하는지 평가하는 기업들
 * 생성형 AI의 효과를 정량화하고, 어느 영역에 효과가 나타나는지, 그리고 비교 기준은 무엇으로 해야할지등의 ROI 평가를 고려하는 기업들
 * AI 계층은 비용이 많이 들 수 있으며, 내년에는 더 많은 기업들이 결과를 제공하지 않는 기능을 철저히 테스트하고 때로는 폐기할 것으로 예상
 * 다만, 구글의 경우 AI 인프라와 AI 오버뷰와 같은 제품 덕분에 올해 3분기 실적이 급등했고, 메타(구 페이스북)는 사용자가 감소하는 상황에서도 AI가 자본 지출을 크게 증가시킨다고 보고

🎀 🎀 과학 연구에 큰 영향을 미치는 AI
 * 2024년 AI와 관련한 노벨상 수상자 4명
   * Demis Hassabis와 Google DeepMind의 John Jumper는 AlphaFold2로 단백질 구조를 예측한 공로로 화학상 수상
   * John J. Hopfield와 Geoffrey Hinton은 수십 년에 걸친 신경망 개발 작업으로 물리학상 수상
 * 백악관에서 10월 31일과 11월 1일에 생명과학에서의 AI 사용에 관한 정상 회담 개최
 * 생성형 AI 모델이 성장하고 성숙함에 따라 내년에도 계속될 높은 가능성

🎀 🎀 환경문제와 에너지 비용은 여전한 이슈인 AI
 * AI가 기상 패턴을 예측하거나 에너지 사용을 최적화하는 데 도움을 줄 수 있는 모든 사용 사례에는 생성형 AI를 운영하는 데 필요한 데이터 센터를 구축하기 위해 막대한 전기와 물, 그리고 지구 온난화등의 문제 존재
 * 기업들의 다양한 에너지 절감 방안과 친환경 방안 고려등이 있으나, 여전히 해결해야 할 숙제

🎃 가장 인기 있는 생성형 AI 제품은 무엇인가요?
 * ChatGPT, OpenAI 챗봇(https://chatgpt.com/)
 * Google Gemini(https://gemini.google.com/app)
 * Microsoft Copilot(https://copilot.microsoft.com/)
 * Perplexity(https://www.perplexity.ai/)
 * Claude AI(https://claude.ai/)
 * DALL-E 3(https://openart.ai/home?gad_source=1)

🎃 가장 발전된 생성형 AI는 무엇인가요?
 * 생성형 AI를 위해 특별히 만들어진 MMLU(대규모 멀티태스크 언어 이해 측정)의 리더보드 상위에는 Google의 Gemini Ultra, China Mobile의 Jiutian, OpenAI의 GPT-4o
   
   

 * source: https://www.techrepublic.com/article/generative-ai-trends-2025/?utm_source=Sailthru&utm_medium=email&utm_campaign=e311_11.05.24_ICP&utm_term=Innovation-Insider-Active

🎃 2024년 연말에도 생성형 AI는 여전히 핫트렌드입니다.특히, 올해 AI 연구는 노벨상을 수상했으며, 세계 최대 기술 기업들은 AI를 가능한 한 많은 제품에 통합하고 있습니다. 미국 정부도 AI를 청정 에너지 경제를 창출하기 위한 촉진자이자 연방 지출의 전략적 축으로 평가하고 있습니다. 그렇다면 2025년에는 어떤 일이 일어날까요? 🎀 🎀 다음 빅 트렌드가 될 AI 에이전트<ul ><li>2024년에는 코파일럿이었다면, 2025년에 AI 에이전트 사용 급증 예상</li><li>반자율적이고 자가 생성된 AI에이전트는 인간이 다른 작업을 처리하는 동안 독립적으로 여러 단계의 작업을 수행 가능</li></ul> 🎀 🎀 보안팀에 도움이 되거나 해를 끼칠 수 있는 AI<ul ><li>생성형 AI는 부정확한 정보 제공 가능성 및 이를 검토하기위한 많은 시간 소비 가능성 존재<ul ><li>예) 우발적인 데이터 노출과 같은 데이터 프라이버시 위험</li><li>예) 학습을 통해 기존의 피싱 이메일을 식별하는 방법을 우회하거나 무용지물로 만들수 있는 업그레이드 된 피싱 공격 가능성 그리고, 이에 대한 탐지의 어려움 또는 불가능성</li></ul></li><li>2025 - 데이터 프라이버시와 보안을 해치지 않도록 AI 사용에 대한 엄격한 통제와 거버넌스 신속 구현 필요. 그리고, AI로 생성된 허위 정보(오디오,비디오, 텍스트 포함)에 대한 보안과 방어 적응 및 대응 필요</li></ul> 🎀 🎀 AI가 ROI를 제공하는지 평가하는 기업들<ul ><li>생성형 AI의 효과를 정량화하고, 어느 영역에 효과가 나타나는지, 그리고 비교 기준은 무엇으로 해야할지등의 ROI 평가를 고려하는 기업들</li><li>AI 계층은 비용이 많이 들 수 있으며, 내년에는 더 많은 기업들이 결과를 제공하지 않는 기능을 철저히 테스트하고 때로는 폐기할 것으로 예상</li><li>다만, 구글의 경우 AI 인프라와 AI 오버뷰와 같은 제품 덕분에 올해 3분기 실적이 급등했고, 메타(구 페이스북)는 사용자가 감소하는 상황에서도 AI가 자본 지출을 크게 증가시킨다고 보고</li></ul> 🎀 🎀 과학 연구에 큰 영향을 미치는 AI<ul ><li>2024년 AI와 관련한 노벨상 수상자 4명<ul ><li>Demis Hassabis와 Google DeepMind의 John Jumper는 AlphaFold2로 단백질 구조를 예측한 공로로 화학상 수상</li><li>John J. Hopfield와 Geoffrey Hinton은 수십 년에 걸친 신경망 개발 작업으로 물리학상 수상</li></ul></li><li>백악관에서 10월 31일과 11월 1일에 생명과학에서의 AI 사용에 관한 정상 회담 개최</li><li>생성형 AI 모델이 성장하고 성숙함에 따라 내년에도 계속될 높은 가능성</li></ul> 🎀 🎀 환경문제와 에너지 비용은 여전한 이슈인 AI<ul ><li>AI가 기상 패턴을 예측하거나 에너지 사용을 최적화하는 데 도움을 줄 수 있는 모든 사용 사례에는 생성형 AI를 운영하는 데 필요한 데이터 센터를 구축하기 위해 막대한 전기와 물, 그리고 지구 온난화등의 문제 존재</li><li>기업들의 다양한 에너지 절감 방안과 친환경 방안 고려등이 있으나, 여전히 해결해야 할 숙제</li></ul> 🎃 가장 인기 있는 생성형 AI 제품은 무엇인가요?<ul ><li>ChatGPT, OpenAI 챗봇(https://chatgpt.com/)</li><li>Google Gemini(https://gemini.google.com/app)</li><li>Microsoft Copilot(https://copilot.microsoft.com/)</li><li>Perplexity(https://www.perplexity.ai/)</li><li>Claude AI(https://claude.ai/)</li><li>DALL-E 3(https://openart.ai/home?gad_source=1)</li></ul> 🎃 가장 발전된 생성형 AI는 무엇인가요?<ul ><li>생성형 AI를 위해 특별히 만들어진 MMLU(대규모 멀티태스크 언어 이해 측정)의 리더보드 상위에는 Google의 Gemini Ultra, China Mobile의 Jiutian, OpenAI의 GPT-4o </li></ul> <ul ><li>source: https://www.techrepublic.com/article/generative-ai-trends-2025/?utm_source=Sailthru&amp;utm_medium=email&amp;utm_campaign=e311_11.05.24_ICP&amp;utm_term=Innovation-Insider-Active</li></ul>

TechRepublic

[TechRepublic]2025년 주목해야 할 생성형 AI 트렌드5가지

NAVER D2

﻿
순간적으로 트래픽이 급증하는 서비스를 운영하다 보면 단순히 서버를 늘리는 것만으로 해결이 안되는 경우가 있습니다. 또한 동시성 해결을 위해서 다양한 락(Lock)을 적용하여 처리한다고 해도 서비스를 온전히 사용하는 사용자가 있는 반면, 비즈니스 로직이나 상황에 따라서는 일부 사용자들은 정상적으로 사용이 어려운 경우가 생기기 마련인데요. 인기 있는 음식점을 가면 한정된 공간 안에 손님들을 모시기 위해 대부분 마련한 번호표 시스템처럼 서비스에도 "대기열 시스템" 을 적용해 보는 것도 검토의 대상이라 생각을 해봅니다.

네이버페이 주문에 적용된 확장 대기열 개발기라는 주제로 확장성에 초점을 두고 시스템 설계 측면에서 설명하는 글이 있어 공유합니다.

특히, 일반적인 폴링 형태로 사용자가 대기열을 통과 가능한지 체크하는 방식이 아닌 사용자와 대기열 사이에 중계 서버를 둬서 순번에 맞는 사용자만 통과시키는 방식이라든지 대기표 관리를 범위로써 관리하여 데이터베이스 관점에서 좀 더 유연한 구조를 가져간 점이 특징이라 볼 수 있는 것 같습니다.

https://d2.naver.com/helloworld/6480558

﻿순간적으로&nbsp;트래픽이&nbsp;급증하는&nbsp;서비스를&nbsp;운영하다 보면&nbsp;단순히&nbsp;서버를&nbsp;늘리는&nbsp;것만으로&nbsp;해결이&nbsp;안되는&nbsp;경우가&nbsp;있습니다.&nbsp;또한&nbsp;동시성&nbsp;해결을&nbsp;위해서&nbsp;다양한&nbsp;락(Lock)을&nbsp;적용하여&nbsp;처리한다고&nbsp;해도&nbsp;서비스를&nbsp;온전히&nbsp;사용하는&nbsp;사용자가&nbsp;있는&nbsp;반면,&nbsp;비즈니스&nbsp;로직이나&nbsp;상황에&nbsp;따라서는&nbsp;일부&nbsp;사용자들은&nbsp;정상적으로&nbsp;사용이&nbsp;어려운&nbsp;경우가&nbsp;생기기&nbsp;마련인데요.&nbsp;인기 있는&nbsp;음식점을&nbsp;가면&nbsp;한정된&nbsp;공간 안에&nbsp;손님들을&nbsp;모시기&nbsp;위해&nbsp;대부분&nbsp;마련한&nbsp;번호표&nbsp;시스템처럼&nbsp;서비스에도&nbsp;"대기열&nbsp;시스템"&nbsp;을&nbsp;적용해 보는&nbsp;것도&nbsp;검토의&nbsp;대상이라&nbsp;생각을&nbsp;해봅니다. 네이버페이 주문에 적용된 확장 대기열 개발기라는 주제로 확장성에 초점을 두고 시스템 설계 측면에서 설명하는 글이 있어 공유합니다. 특히,&nbsp;일반적인&nbsp;폴링 형태로&nbsp;사용자가&nbsp;대기열을&nbsp;통과&nbsp;가능한지&nbsp;체크하는&nbsp;방식이&nbsp;아닌&nbsp;사용자와&nbsp;대기열&nbsp;사이에&nbsp;중계&nbsp;서버를&nbsp;둬서&nbsp;순번에&nbsp;맞는&nbsp;사용자만&nbsp;통과시키는&nbsp;방식이라든지&nbsp;대기표&nbsp;관리를&nbsp;범위로써&nbsp;관리하여&nbsp;데이터베이스&nbsp;관점에서&nbsp;좀 더&nbsp;유연한&nbsp;구조를&nbsp;가져간&nbsp;점이&nbsp;특징이라&nbsp;볼 수&nbsp;있는 것&nbsp;같습니다. https://d2.naver.com/helloworld/6480558

d2.naver.com

네이버페이 주문에 적용된 확장 가능한 대기열 개발기

컴포넌트 기반 UI 개발의 패러다임을 주도한 React가 등장한지도 어느 덧 10년이 넘었네요. 이제 Vue.js, Svelte, Angular 등 어떤 프론트엔드 프레임워크를 사용하든 현대 웹 개발에서 컴포넌트 기반으로 UI 개발하는 것은 거의 당연한 얘기가 되었죠. 그리고 마침내 웹 컴포넌트(Web Components)를 통해서 별다른 프론트엔드 프레임워크가 없어도 UI 컴포넌트를 만들 수 있는 길이 활짝 열렸습니다.

웹 컴포넌트는 웹사이트나 애플리케이션에서 UI를 모듈화하고 재사용할 수도록 해주는 웹 표준 기술입니다. React와 같은 프론트엔드 프레임워크에서 오랫동안 경험해왔던 UI 컴포넌트를 떠올리시면 이해가 쉬우실 것 같습니다.

React 컴포넌트는 React에서만 쓸 수 있고, Vue.js 컴포넌트는 Vue.js에서만 쓸 수 있는 근본적인 한계가 있습니다. 하지만 웹 컴포넌트는 이와 같은 구애를 받지 않고 어떤 프론트엔드 프레임워크와도 함께 쓸 수 있습니다. 왜냐하면 웹 컴포넌트는 브라우저에서 네이티브(native)하게 작동하기 때문입니다.

이러한 웹 컴포넌트의 띄어난 호환성과 이식성, 재사용성 및 생산성 덕분에 최근에는 디자인 시스템(Design System)을 구현하는 최고의 기술로 주목받고 있습니다.

모든 기술이 그러하든 웹 컴포넌트가 장점만 있는 것은 아닙니다. 대표적인 단점으로 API가 직관적이지 않다고 평가받고 있고, 배우기 쉬운 기존 프런트엔드 프레임워크 대비 진입 장벽이 높은 편입니다. 그래서 실제 프로젝트에서는 이러한 단점을 보완한기 위해서 웹 컴포넌트를 직접 작성하기 보다는 Lit나 Stencil과 같은 라이브러리를 많이 사용합니다.

웹 컴포넌트은 크게 다음 세 가지 핵심 기술로 이루어집니다.
 * Custom Elements: 사용자 정의 HTML 요소(element) 또는 태그(tag)를 정의할 수 있습니다.
 * Shadow DOM: DOM 트리의 일부를 캡슐화하여 스타일과 마크업이 외부와 충돌하지 않도록 해줍니다.
 * HTML Templates: 화면에 나타나지 않는 HTML 조각(fragment)을 정의해놓고 재사용할 수 있습니다.
이 웹 표준 기술들은 현재 주요 브라우저에서 모두 지원되고 있습니다.

이번 포스팅에서는 각각의 기반 기술을 하나씩 살펴보면 웹 컴포넌트의 기본 개념을 잡아보도록 하겠습니다.

📝 포스팅: https://www.daleseo.com/web-components/

컴포넌트 기반 UI 개발의 패러다임을 주도한 React가 등장한지도 어느 덧 10년이 넘었네요. 이제 Vue.js, Svelte, Angular 등 어떤 프론트엔드 프레임워크를 사용하든 현대 웹 개발에서 컴포넌트 기반으로 UI 개발하는 것은 거의 당연한 얘기가 되었죠. 그리고 마침내 웹 컴포넌트(Web Components)를 통해서 별다른 프론트엔드 프레임워크가 없어도 UI 컴포넌트를 만들 수 있는 길이 활짝 열렸습니다. 웹 컴포넌트는 웹사이트나 애플리케이션에서 UI를 모듈화하고 재사용할 수도록 해주는 웹 표준 기술입니다. React와 같은 프론트엔드 프레임워크에서 오랫동안 경험해왔던 UI 컴포넌트를 떠올리시면 이해가 쉬우실 것 같습니다. React 컴포넌트는 React에서만 쓸 수 있고, Vue.js 컴포넌트는 Vue.js에서만 쓸 수 있는 근본적인 한계가 있습니다. 하지만 웹 컴포넌트는 이와 같은 구애를 받지 않고 어떤 프론트엔드 프레임워크와도 함께 쓸 수 있습니다. 왜냐하면 웹 컴포넌트는 브라우저에서 네이티브(native)하게 작동하기 때문입니다. 이러한 웹 컴포넌트의 띄어난 호환성과 이식성, 재사용성 및 생산성 덕분에 최근에는 디자인 시스템(Design System)을 구현하는 최고의 기술로 주목받고 있습니다. 모든 기술이 그러하든 웹 컴포넌트가 장점만 있는 것은 아닙니다. 대표적인 단점으로 API가 직관적이지 않다고 평가받고 있고, 배우기 쉬운 기존 프런트엔드 프레임워크 대비 진입 장벽이 높은 편입니다. 그래서 실제 프로젝트에서는 이러한 단점을 보완한기 위해서 웹 컴포넌트를 직접 작성하기 보다는 Lit나 Stencil과 같은 라이브러리를 많이 사용합니다. 웹 컴포넌트은 크게 다음 세 가지 핵심 기술로 이루어집니다.<ul ><li>Custom Elements: 사용자 정의 HTML 요소(element) 또는 태그(tag)를 정의할 수 있습니다.</li><li>Shadow DOM: DOM 트리의 일부를 캡슐화하여 스타일과 마크업이 외부와 충돌하지 않도록 해줍니다.</li><li>HTML Templates: 화면에 나타나지 않는 HTML 조각(fragment)을 정의해놓고 재사용할 수 있습니다.</li></ul>이 웹 표준 기술들은 현재 주요 브라우저에서 모두 지원되고 있습니다. 이번 포스팅에서는 각각의 기반 기술을 하나씩 살펴보면 웹 컴포넌트의 기본 개념을 잡아보도록 하겠습니다. 📝 포스팅: https://www.daleseo.com/web-components/

웹 컴포넌트 (Web Components)

알림과 실시간 채팅 같은 서비스를 구현할 때, 우리는 자연스럽게 두 가지 기술 사이에서 고민에 빠지게 됩니다. SSE와 WebSocket은 각기 다른 매력을 지닌 두 명의 주인공과 같습니다. 이 포스팅에서는 SSE와 WebSocket의 특징과 사용법을 비교해 보면서, ‘내 프로젝트에서는 어떤 녀석이 주인공일까?’에 대한 답을 찾아보도록 하겠습니다. 실시간 통신의 필요성여러분의 앱이 최신 주식 가격을 보여주거나 "우리 동네에 눈이 내립니다!" 같은 알림을 띄워야 한다면, 실시간 통신은 선택이 아니라 필수입니다. 그런데 문제는 단방향이냐, 양방향이냐! 양방향 통신을 택하면 더 복잡하지만 매력적이고, 단방향 통신은 더 기능이 적지만 그만큼 단순합니다. 둘 중 어느 쪽을 고를지 결정하기 위해선 기술들의 성격을 ..

SSE와 WebSocket, 그들은 왜 실시간 통신의 라이벌이 되었을까?

이 포스팅에서는 SSE와 WebSocket의 특징과 사용법을 비교해 보면서, ‘내 프로젝트에서는 어떤 녀석이 주인공일까?’에 대한 답을 찾아보도록 하겠습니다.
 
SSE (Server-Sent Events)
SSE는 마치 선생님이 수업 시간 내내 일방적으로 학생들에게 말하는 것과 같습니다. 학생(클라이언트)은 계속해서 듣고 받아 적어야 하죠.
 * 학생: 선생님, 질문이 있습니다
 * SSE: 미안, 넌 질문할 수 없어!
 
 
SSE는 서버가 클라이언트에게 일방적으로 데이터를 푸시할 때 쓰입니다. HTTP 기반이라서 프록시나 방화벽이 거부하지 않습니다.
 
서버에서 매초마다 데이터를 보낸다고 상상해 볼까요?
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.http.HttpServletResponse;

@RestController
public class SSEController {

 @GetMapping("/sse")
 public void streamEvents(HttpServletResponse response) throws IOException {
 response.setContentType("text/event-stream");
 response.setCharacterEncoding("UTF-8");

 PrintWriter writer = response.getWriter();
 for (int i = 1; i <= 5; i++) {
 writer.write("data: SSE 이벤트 #" + i + "\n\n");
 writer.flush();
 try {
 Thread.sleep(1000); // 1초마다 이벤트 전송
 } catch (InterruptedException e) {
 Thread.currentThread().interrupt();
 }
 }
 writer.close();
 }
}

const eventSource = new EventSource('/sse');

eventSource.onmessage = function(event) {
 console.log("새 이벤트 수신:", event.data);
};

eventSource.onerror = function() {
 console.error("SSE 연결 오류 발생");
};

장점:
 * SSE는 자동 재연결을 지원합니다.
 * 설정이 간단해서 빨리 구현하고 싶은 개발자에겐 최적입니다.
단점:
 * 오직 단방향입니다. 클라이언트는 서버에 말을 걸 수 없어요. (서운하지만 어쩔 수 없습니다.)
 * 데이터를 텍스트로만 보내는 게 편합니다. 이미지나 비디오 전송은 꿈도 꾸지 마세요.
 
WebSocket
WebSocket은 연애 초기의 커플 같아요. 둘이 채팅하느라 시간 가는 줄 모르죠. 양방향 통신이 가능하기 때문에 서버와 클라이언트가 자유롭게 대화를 주고받습니다.
 * A: "지금 뭐 해?"
 * B: "지금 네 메시지 받았어. 다시 보낼게!"

이제 서버와 클라이언트가 한바탕 신나게 대화하는 예제를 보겠습니다.
@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {
 @Override
 public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
 registry.addHandler(new TextWebSocketHandler() {
 @Override
 protected void handleTextMessage(WebSocketSession session, TextMessage message) 
 throws Exception {
 session.sendMessage(new TextMessage("에코: " + message.getPayload()));
 }
 }, "/ws");
 }
}

const socket = new WebSocket('ws://localhost:8080/ws');

socket.onopen = () => {
 console.log('WebSocket 연결 성공!');
 socket.send('안녕, 서버!');
};

socket.onmessage = (event) => {
 console.log('받은 메시지:', event.data);
};

장점:
 * 양방향이라 서버와 클라이언트가 마음껏 수다를 떨 수 있습니다.
 * 텍스트뿐만 아니라 바이너리 데이터도 전송할 수 있어요. (그림도 보낼 수 있다는 얘기죠!)
단점:
 * 설정이 조금 귀찮습니다. 방화벽에 걸리기 쉽고, 초기 핸드셰이크까지 해야 하니까요.
 * 재연결? 그런 거 없습니다. 알아서 다시 연결할 방법을 짜야 해요.
 
마무리 및 결론
 * SSE는 "너 듣기만 해, 내가 다 말해줄게" 스타일에 적합합니다. 실시간 뉴스나 알림처럼 서버에서 클라이언트로만 정보가 흐를 때 좋습니다.
 * 반면에, WebSocket은 "같이 떠들자!" 스타일입니다. 채팅, 게임처럼 상호작용이 필요한 경우 선택하세요.
 
저는 개인적으로 어드민 UI에서 서버 로그를 실시간으로 출력할 때 SSE를 사용했습니다. 클라이언트가 서버에게 말할 필요가 없었기 때문에 SSE가 완벽한 선택이었습니다. 만약 반대로 채팅 앱을 만들었다면? WebSocket이 당연히 주인공이 되었겠죠.
 
이제 여러분도 SSE와 WebSocket 중 누구를 주인공으로 선택할지 결정할 수 있겠죠?

이 포스팅에서는 SSE와 WebSocket의 특징과 사용법을 비교해 보면서, ‘내 프로젝트에서는 어떤 녀석이 주인공일까?’에 대한 답을 찾아보도록 하겠습니다.&nbsp;SSE (Server-Sent Events)SSE는 마치 선생님이 수업 시간 내내 일방적으로 학생들에게 말하는 것과 같습니다. 학생(클라이언트)은 계속해서 듣고 받아 적어야 하죠.<ul ><li>학생: 선생님, 질문이 있습니다</li><li>SSE: 미안, 넌 질문할 수 없어! </li></ul>SSE는 서버가 클라이언트에게 일방적으로 데이터를 푸시할 때 쓰입니다. HTTP 기반이라서 프록시나 방화벽이 거부하지 않습니다.&nbsp;서버에서 매초마다 데이터를 보낸다고 상상해 볼까요?<pre ><code class="language-javascript">import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.http.HttpServletResponse;

@RestController
public class SSEController {

 @GetMapping("/sse")
 public void streamEvents(HttpServletResponse response) throws IOException {
 response.setContentType("text/event-stream");
 response.setCharacterEncoding("UTF-8");

 PrintWriter writer = response.getWriter();
 for (int i = 1; i &lt;= 5; i++) {
 writer.write("data: SSE 이벤트 #" + i + "\n\n");
 writer.flush();
 try {
 Thread.sleep(1000); // 1초마다 이벤트 전송
 } catch (InterruptedException e) {
 Thread.currentThread().interrupt();
 }
 }
 writer.close();
 }
}</code></pre><pre ><code class="language-javascript">const eventSource = new EventSource('/sse');

eventSource.onmessage = function(event) {
 console.log("새 이벤트 수신:", event.data);
};

eventSource.onerror = function() {
 console.error("SSE 연결 오류 발생");
};</code></pre>장점:<ul ><li>SSE는 자동 재연결을 지원합니다.</li><li>설정이 간단해서 빨리 구현하고 싶은 개발자에겐 최적입니다.</li></ul>단점:<ul ><li>오직 단방향입니다. 클라이언트는 서버에 말을 걸 수 없어요. (서운하지만 어쩔 수 없습니다.)</li><li>데이터를 텍스트로만 보내는 게 편합니다. 이미지나 비디오 전송은 꿈도 꾸지 마세요.</li></ul>&nbsp;WebSocketWebSocket은 연애 초기의 커플 같아요. 둘이 채팅하느라 시간 가는 줄 모르죠. 양방향 통신이 가능하기 때문에 서버와 클라이언트가 자유롭게 대화를 주고받습니다.<ul ><li>A: "지금 뭐 해?"</li><li>B: "지금 네 메시지 받았어. 다시 보낼게!"</li></ul> 이제 서버와 클라이언트가 한바탕 신나게 대화하는 예제를 보겠습니다.<pre ><code class="language-java">@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {
 @Override
 public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
 registry.addHandler(new TextWebSocketHandler() {
 @Override
 protected void handleTextMessage(WebSocketSession session, TextMessage message) 
 throws Exception {
 session.sendMessage(new TextMessage("에코: " + message.getPayload()));
 }
 }, "/ws");
 }
}</code></pre><pre ><code class="language-java">const socket = new WebSocket('ws://localhost:8080/ws');

socket.onopen = () =&gt; {
 console.log('WebSocket 연결 성공!');
 socket.send('안녕, 서버!');
};

socket.onmessage = (event) =&gt; {
 console.log('받은 메시지:', event.data);
};</code></pre>장점:<ul ><li>양방향이라 서버와 클라이언트가 마음껏 수다를 떨 수 있습니다.</li><li>텍스트뿐만 아니라 바이너리 데이터도 전송할 수 있어요. (그림도 보낼 수 있다는 얘기죠!)</li></ul>단점:<ul ><li>설정이 조금 귀찮습니다. 방화벽에 걸리기 쉽고, 초기 핸드셰이크까지 해야 하니까요.</li><li>재연결? 그런 거 없습니다. 알아서 다시 연결할 방법을 짜야 해요.</li></ul>&nbsp;마무리 및 결론<ul ><li>SSE는 "너 듣기만 해, 내가 다 말해줄게" 스타일에 적합합니다. 실시간 뉴스나 알림처럼 서버에서 클라이언트로만 정보가 흐를 때 좋습니다.</li><li>반면에, WebSocket은 "같이 떠들자!" 스타일입니다. 채팅, 게임처럼 상호작용이 필요한 경우 선택하세요.</li></ul>&nbsp;저는 개인적으로 어드민 UI에서 서버 로그를 실시간으로 출력할 때 SSE를 사용했습니다. 클라이언트가 서버에게 말할 필요가 없었기 때문에 SSE가 완벽한 선택이었습니다. 만약 반대로 채팅 앱을 만들었다면? WebSocket이 당연히 주인공이 되었겠죠.&nbsp;이제 여러분도 SSE와 WebSocket 중 누구를 주인공으로 선택할지 결정할 수 있겠죠?&nbsp;&nbsp;

덕토피아

SSE와 WebSocket, 그들은 왜 실시간 통신의 라이벌이 되

요즘 연습 중인 생각의 회로: 다 대표 탓이라고 생각하면 돌파구가 나옵니다. 

눈코 뜰 새 없이 매일을 살아가다, 턱 막히는 순간들이 옵니다. 지금까지는 외부 요인에 집중했는데 시장, 제품, 팀, 투자자 탓 말고 원인을 창업가 본인에 두면 해결의 실마리도보이는 것 같아요. 

1)… | 댓글 11

LinkedIn Hannah Choi 페이지: 요즘 연습 중인 생각의 회로: 다 대표 탓이라고 생각하면 돌파구가 나옵니다. 눈코 뜰 새 없이 매일을 살아가다, 턱 막히는… | 댓글 11

스타트업을 운영 중이신 한 대표님께서 말씀하시길, 난관에 봉착했을 때 이전에는 외부 요인에 집중했었지만, 이제는 시장, 제품, 팀, 투자자를 탓하지 않고 원인을 창업가 본인에게서 찾아 해결의 실마리를 발견해 나간다고 합니다.

시장 "요즘 비시즌이라 섭외 볼륨이 없어요"
 * 계절성에 대해 대응을 하지 못한 탓
 * 시즌이 국가 한정이라면, 린하게 확장할 수 있을까? 반드시 상업 촬용 중개 수수료에만 BM을 한정해야 할까?

프로덕트 "고객님 거기까지는 아직 프로덕트 대응이 안돼서..."
 * 사업 상황에 맞지 않는 우선순위를 선정한 내 탓
 * 더욱 타이트하게 제품-사업 팀의 소통을 열 수 없었을까?
 * 채용 계획을 다시 점검해볼까 ?
 * 프로덕트 없이 손으로 당장 고객에게 벨류를 가져다 줄 방법은 없을까?

투자 "이번 라운드는 어려울 것 같습니다"
 * 해당 투자사가 원하는 제품, 시장, 벨류와 맞지 않는 피칭을 전달한 내 탓
 * 현재 우리 상황을 더 선호하는 투자사들을 만날 수 있게 아웃바운드 볼륨을 높여볼까?
 * 우리 팀의 미래에 대해 설득력을 높일 수 있는 방법은 없을까?

사업은 마음만큼 따라와 주지 않는 일이 90%지만, 이런 저런 핑계말고 내 손으로 더 할 수 있는 일을 찾아보고 있습니다. 시장이 당장 바뀌기 어려워도, 제품이 하루 아침에 업데이트 되기는 힘들어도, 돌아선 투자사의 마음을 바꾸기는 어려워도 적어도 창업자 자신은 지금 당장 무엇인가 시도해볼 수 있기 때문입니다.

스타트업을 운영 중이신 한 대표님께서 말씀하시길, 난관에 봉착했을 때 이전에는 외부 요인에 집중했었지만, 이제는 시장, 제품, 팀, 투자자를 탓하지 않고 원인을 창업가 본인에게서 찾아 해결의 실마리를 발견해 나간다고 합니다. 시장 "요즘 비시즌이라 섭외 볼륨이 없어요"<ul ><li>계절성에 대해 대응을 하지 못한 탓</li><li>시즌이 국가 한정이라면, 린하게 확장할 수 있을까? 반드시 상업 촬용 중개 수수료에만 BM을 한정해야 할까?</li></ul> 프로덕트 "고객님 거기까지는 아직 프로덕트 대응이 안돼서..."<ul ><li>사업 상황에 맞지 않는 우선순위를 선정한 내 탓 </li><li>더욱 타이트하게 제품-사업 팀의 소통을 열 수 없었을까?</li><li>채용 계획을 다시 점검해볼까 ?</li><li>프로덕트 없이 손으로 당장 고객에게 벨류를 가져다 줄 방법은 없을까?</li></ul> 투자 "이번 라운드는 어려울 것 같습니다"<ul ><li>해당 투자사가 원하는 제품, 시장, 벨류와 맞지 않는 피칭을 전달한 내 탓</li><li>현재 우리 상황을 더 선호하는 투자사들을 만날 수 있게 아웃바운드 볼륨을 높여볼까?</li><li>우리 팀의 미래에 대해 설득력을 높일 수 있는 방법은 없을까?</li></ul> 사업은 마음만큼 따라와 주지 않는 일이 90%지만, 이런 저런 핑계말고 내 손으로 더 할 수 있는 일을 찾아보고 있습니다. 시장이 당장 바뀌기 어려워도, 제품이 하루 아침에 업데이트 되기는 힘들어도, 돌아선 투자사의 마음을 바꾸기는 어려워도 적어도 창업자 자신은 지금 당장 무엇인가 시도해볼 수 있기 때문입니다.

www.linkedin.com

다 대표 탓이라고 하면 돌파구가 나옵니다.

단순히 취업이 아닌,
꾸준히 성장하는 핵심 인재가 되고 싶다면,

다각도에서 내 역량이 어떻게 성장하고 있는지
스스로 파악하는 메타 인지가 필요해요.

DATA/AI 분야 뿐만 아니라,
다양한 영역에서 내가
어떤 스킬을 얼마나 갖추고 있는지를 생각해보세요.

- 하드 스킬
- 소프트 스킬
- 커리어 스킬

기업이 뽑고 싶어하는,
아니 기업이 뽑을수 밖에 없는 인재들은
이런 디테일을 가지고 있답니다.

하드 스킬, 소프트 스킬, 그리고 커리어 스킬을 각각 성장의 관점에서 바라보고 주기적으로 점검하는 습관을 들여보세요.

이렇게 스스로 분석하고 객관적으로 바라볼수 있다면,
결국 기업에서 찾는 '핵심 인재'로 자리매김하게 될 거예요.

단순히 취업이 아닌, 꾸준히 성장하는 핵심 인재가 되고 싶다면, 다각도에서 내 역량이 어떻게 성장하고 있는지 스스로 파악하는 메타 인지가 필요해요. DATA/AI 분야 뿐만 아니라, 다양한 영역에서 내가 어떤 스킬을 얼마나 갖추고 있는지를 생각해보세요. - 하드 스킬 - 소프트 스킬 - 커리어 스킬 기업이 뽑고 싶어하는, 아니 기업이 뽑을수 밖에 없는 인재들은 이런 디테일을 가지고 있답니다. 하드 스킬, 소프트 스킬, 그리고 커리어 스킬을 각각 성장의 관점에서 바라보고 주기적으로 점검하는 습관을 들여보세요. 이렇게 스스로 분석하고 객관적으로 바라볼수 있다면, 결국 기업에서 찾는 '핵심 인재'로 자리매김하게 될 거예요.

꾸준히 성장하는 핵심 인재의 특징

Last week, I interviewed a friend who got to Staff (IC6) at Google by 28 in an unusual way.

What You Work On >> How Hard You Work

기술 경로에서 빠르게 성공한 개발자들의 전략이 무엇인지 궁금하지 않으신가요? 이번 이야기는 구글에서 20대 후반에 IC6(Staff) 단계까지 오른 한 개발자의 경험을 담고 있습니다. 그가 일주일에 평균 40시간도 일하지 않으면서도 어떻게 빠르게 승진할 수 있었는지, 핵심은 단순히 성실한 업무량이 아닌, 전략적인 선택과 소통 능력이었다고 합니다.

1) 결과 중심적 사고와 큰 임팩트를 만드는 일 선택하기
 * 핵심 목표 이해: 그는 조직에서 가장 중요하게 여기는 결과와 그것을 달성하기 위해 필요한 핵심 작업을 우선 파악했습니다.
 * 작은 일 거절하기: 영향력이 적은 일은 거절하고, 승진 가능성을 높일 수 있는 프로젝트에 집중했습니다.
 * 시간은 제한적: 누구에게나 주어진 시간은 동일하기에, 중요한 일을 선별하고 집중하는 것이 높은 성과를 내는 유일한 방법이라고 합니다.
 * 매니저와의 대화: 그가 일의 임팩트를 평가하는 능력을 키운 방법은 매니저나 기술 리더와의 대화를 통해서였습니다. 이는 다음 단계를 준비하는 데 중요한 과정이라고 합니다.
2) 부드럽게 “아니요”라고 말할 수 있는 소프트 스킬
 * 오버커뮤니케이션: 거절할 때는 반드시 설명이 필요하며, 이를 통해 오해나 문제를 방지할 수 있습니다. 예를 들어, 중요한 프로젝트에 집중해야 하므로 덜 중요한 일을 맡지 않겠다고 설명하는 식입니다.
 * 균형 잡기: 승진에 도움이 되지 않는 일을 모두 거절하면 팀 플레이어로서의 이미지가 나빠질 수 있으므로, 상황에 따라 유연하게 접근하는 것이 중요합니다.
 * 시간 보호하기: 시간이 곧 자산이므로, 무분별하게 모든 요청에 응답하지 않고 자신의 시간을 보호해야 합니다. 예를 들어, 다른 팀원들의 문의나 온콜(On-call) 근무를 모두 거절했던 한 Distinguished 엔지니어의 사례를 참고하며, 경우에 따라 시간 보호를 우선시할 필요도 있음을 강조했습니다.
자신의 시간을 지키고 집중하는 것이 성공적인 커리어로 가는 지름길이 될 수 있습니다. 여러분은 어떤 방식으로 업무를 선택하고, 집중력을 유지하고 계신가요?

https://www.developing.dev/p/what-you-work-on-how-hard-you-work

기술 경로에서 빠르게 성공한 개발자들의 전략이 무엇인지 궁금하지 않으신가요? 이번 이야기는 구글에서 20대 후반에 IC6(Staff) 단계까지 오른 한 개발자의 경험을 담고 있습니다. 그가 일주일에 평균 40시간도 일하지 않으면서도 어떻게 빠르게 승진할 수 있었는지, 핵심은 단순히 성실한 업무량이 아닌, 전략적인 선택과 소통 능력이었다고 합니다. 1) 결과 중심적 사고와 큰 임팩트를 만드는 일 선택하기<ul ><li>핵심 목표 이해: 그는 조직에서 가장 중요하게 여기는 결과와 그것을 달성하기 위해 필요한 핵심 작업을 우선 파악했습니다.</li><li>작은 일 거절하기: 영향력이 적은 일은 거절하고, 승진 가능성을 높일 수 있는 프로젝트에 집중했습니다.</li><li>시간은 제한적: 누구에게나 주어진 시간은 동일하기에, 중요한 일을 선별하고 집중하는 것이 높은 성과를 내는 유일한 방법이라고 합니다.</li><li>매니저와의 대화: 그가 일의 임팩트를 평가하는 능력을 키운 방법은 매니저나 기술 리더와의 대화를 통해서였습니다. 이는 다음 단계를 준비하는 데 중요한 과정이라고 합니다.</li></ul>2) 부드럽게 “아니요”라고 말할 수 있는 소프트 스킬<ul ><li>오버커뮤니케이션: 거절할 때는 반드시 설명이 필요하며, 이를 통해 오해나 문제를 방지할 수 있습니다. 예를 들어, 중요한 프로젝트에 집중해야 하므로 덜 중요한 일을 맡지 않겠다고 설명하는 식입니다.</li><li>균형 잡기: 승진에 도움이 되지 않는 일을 모두 거절하면 팀 플레이어로서의 이미지가 나빠질 수 있으므로, 상황에 따라 유연하게 접근하는 것이 중요합니다.</li><li>시간 보호하기: 시간이 곧 자산이므로, 무분별하게 모든 요청에 응답하지 않고 자신의 시간을 보호해야 합니다. 예를 들어, 다른 팀원들의 문의나 온콜(On-call) 근무를 모두 거절했던 한 Distinguished 엔지니어의 사례를 참고하며, 경우에 따라 시간 보호를 우선시할 필요도 있음을 강조했습니다.</li></ul>자신의 시간을 지키고 집중하는 것이 성공적인 커리어로 가는 지름길이 될 수 있습니다. 여러분은 어떤 방식으로 업무를 선택하고, 집중력을 유지하고 계신가요? https://www.developing.dev/p/what-you-work-on-how-hard-you-work

www.developing.dev

어떻게 일하느냐가 얼마나 열심히 하느냐보다 중요하다.

산호세 주립대에서 데이터 엔지니어링 강의를 가르친지 11주가 되어 간다. 80%의 학생은 인도에서 대학을 마치고 3-5년 일하면 번 돈으로 실리콘밸리에서 일하는 것을 꿈꾸며 넘어온 도전이란 관점에서 나무랄 때가 없는 사람들이다. 하지만 도전 정신 만큼 성적이 나오느냐는 다른 문제이다. 정규 분포를 분명히 따르며 적은 수의 다른 문화권 출신들과 비교해보면 평균 점수는 확연히 낮다. 나머지 20%의 학생들은 주로 대만계인데 중국 본토 출신들은 없다. 중국 본토 출신은 R&D에 관심이 있다보니 석사 후 취업 보다는 박사까지 하는 걸 많이 고려하다보니 없는 걸로 보인다.

지지난 주 중간 고사를 보고 결과에 대해 궁금증이 있거나 납득이 안되는 학생들은 오피스 아워로 오라고 했는데 인도 학생들만 오고 그 이외의 인종은 아무도 오지 않았다 :) 실리콘 밸리에서 일해본 사람이라면 어느 정도 인정할 수 밖에 없는 것은 바로 인도 사람들의 자신감과 도전 정신이다. 다른 문화권에 비해 자기 검열을 하는 사람은 현저하게 적다. 또 하나 다른 점은 권위에 도전한다는 점이다. 매니저라고 해서 교수라고 해서 자기 의견을 죽이는 사람보다는 어떻게든 표현하는 사람들이 많다. 암튼 이런 저런 요청을 많이 하고 질문이 많다.

이런 문화적 특성 위에 영어를 어렸을 때부터 사용했다보니 언어적인 문제가 적다. 같이 일했던 인도 동료들을 보면 발음은 처음에 이해하기 힘들지 몰라도 단어 선택이나 표현 자체는 원어민들보다도 좋은 사람들이 많았다.

이 조합들(자기검열을 덜 하고 권위에 도전하며 영어 자체에 익숙한 점)이 결국 리더십으로 갈 수 있느냐 없느냐를 결정하는 것 같다. 또 하나 무시할 수 없는 점은 동아시아권들에 비해 모국의 환경이 그다지 좋지 않다보니 실리콘밸리에서 어떻게든 성공하겠다는 간절함이 더 있다고 보여진다.

가르치면서 이런 관찰을 또 할 줄은 몰랐지만 암튼 덜 자기검열하고 욕망을 잘 표현하고 의사소통을 잘 하는 것이 긴 커리어에서는 참 중요한 기술이다. 참 이번에 주관식 초벌 채점은 RAG로 해봤는데 물론 최종검수를 했고 RAG 만드느라 더 시간을 썼지만 아주 흥미로운 경험이었다. 나중에는 한번 이 이야기해도 공유 해봐야겠다.

산호세 주립대에서 데이터 엔지니어링 강의를 가르친지 11주가 되어 간다. 80%의 학생은 인도에서 대학을 마치고 3-5년 일하면 번 돈으로 실리콘밸리에서 일하는 것을 꿈꾸며 넘어온 도전이란 관점에서 나무랄 때가 없는 사람들이다. 하지만 도전 정신 만큼 성적이 나오느냐는 다른 문제이다. 정규 분포를 분명히 따르며 적은 수의 다른 문화권 출신들과 비교해보면 평균 점수는 확연히 낮다. 나머지 20%의 학생들은 주로 대만계인데 중국 본토 출신들은 없다. 중국 본토 출신은 R&amp;D에 관심이 있다보니 석사 후 취업 보다는 박사까지 하는 걸 많이 고려하다보니 없는 걸로 보인다. 지지난 주 중간 고사를 보고 결과에 대해 궁금증이 있거나 납득이 안되는 학생들은 오피스 아워로 오라고 했는데 인도 학생들만 오고 그 이외의 인종은 아무도 오지 않았다 :) 실리콘 밸리에서 일해본 사람이라면 어느 정도 인정할 수 밖에 없는 것은 바로 인도 사람들의 자신감과 도전 정신이다. 다른 문화권에 비해 자기 검열을 하는 사람은 현저하게 적다. 또 하나 다른 점은 권위에 도전한다는 점이다. 매니저라고 해서 교수라고 해서 자기 의견을 죽이는 사람보다는 어떻게든 표현하는 사람들이 많다. 암튼 이런 저런 요청을 많이 하고 질문이 많다. 이런 문화적 특성 위에 영어를 어렸을 때부터 사용했다보니 언어적인 문제가 적다. 같이 일했던 인도 동료들을 보면 발음은 처음에 이해하기 힘들지 몰라도 단어 선택이나 표현 자체는 원어민들보다도 좋은 사람들이 많았다. 이 조합들(자기검열을 덜 하고 권위에 도전하며 영어 자체에 익숙한 점)이 결국 리더십으로 갈 수 있느냐 없느냐를 결정하는 것 같다. 또 하나 무시할 수 없는 점은 동아시아권들에 비해 모국의 환경이 그다지 좋지 않다보니 실리콘밸리에서 어떻게든 성공하겠다는 간절함이 더 있다고 보여진다. 가르치면서 이런 관찰을 또 할 줄은 몰랐지만 암튼 덜 자기검열하고 욕망을 잘 표현하고 의사소통을 잘 하는 것이 긴 커리어에서는 참 중요한 기술이다. 참 이번에 주관식 초벌 채점은 RAG로 해봤는데 물론 최종검수를 했고 RAG 만드느라 더 시간을 썼지만 아주 흥미로운 경험이었다. 나중에는 한번 이 이야기해도 공유 해봐야겠다.

산호세 주립대에서 가르치며 다시 한번 깨달은 인도계의 다른 점

이 글은 DuckDB 사용법을 작성한 글입니다 예상 독자 DuckDB가 궁금하신 분 데이터 분석가 : Pandas가 느리다고 생각해서 다른 대안을 찾고 있는 분 데이터 엔지니어 : 데이터 엔지니어링의 Transform 영역에서 활용할 수 있는 수단을 찾고 있는 분. 작은 규모의 회사에서 데이터 웨어하우스를 고민하고 있는 분 키워드 : Duckdb 사용법, Duckdb 설치,...

DuckDB 사용법(DuckDB Python + Jupyter Lab)

 * 요즘 Pandas 대용, 데이터 웨어하우스 대용으로 많이 언급되는 DuckDB 사용법을 작성한 글입니다
 * 정말 빠르니 데이터 직무에 계신 분들은 꼭 보시고 사용해보시면 좋겠네요..!!!

https://zzsza.github.io/data-engineering/2024/10/25/duckdb/

<ul ><li>요즘 Pandas 대용, 데이터 웨어하우스 대용으로 많이 언급되는 DuckDB 사용법을 작성한 글입니다</li><li>정말 빠르니 데이터 직무에 계신 분들은 꼭 보시고 사용해보시면 좋겠네요..!!!</li></ul> https://zzsza.github.io/data-engineering/2024/10/25/duckdb/

zzsza.github.io

DuckDB 사용법

채용 담당자 시절 느낀 적당한 장수는 다음과 같았습니다.

👉 총 35-40p 이내
👉 프로젝트 4-5개, 장당 7-8p
👉 구조: 배경 > 문제정의 > 가설 > 솔루션 > 결과해석 > 레슨런
👉 프로젝트 = 서비스 아님
👉 서비스 하나당 n개의 프로젝트가 나올 수 있음
👉 문제 해결력을 잘 보여줄 수 있는 중요도 순서로 배치함 (최신순 아니어도 됨)

채용 담당자 시절 느낀 적당한 장수는 다음과 같았습니다. 👉 총 35-40p 이내👉 프로젝트 4-5개, 장당 7-8p👉 구조: 배경 &gt; 문제정의 &gt; 가설 &gt; 솔루션 &gt; 결과해석 &gt; 레슨런👉 프로젝트 = 서비스 아님👉 서비스 하나당 n개의 프로젝트가 나올 수 있음👉 문제 해결력을 잘 보여줄 수 있는 중요도 순서로 배치함 (최신순 아니어도 됨)

🎯 적당한 포트폴리오 장수는?

월급이 적다는 이유로 회사를 그만둔 적은 없었지만… 그런 이유를 대봤으면 어땠을까 상상해 봤습니다.

대체 불가능한 직원

월급이 적다는 이유로 회사를 그만둔 적은 없었지만…
그런 이유를 대봤으면 어땠을까 상상해 봤습니다.

“얼마나 올려주면 되는데?”
“50퍼센트요.”

한 번쯤 그렇게 말해볼 걸.
회사에서 인정하는 진짜 내 가치를 알 수 있을 테니깐.

하지만 저는 답을 알고 있기도 합니다.
“잘 가라.”

저는 대체 불가능한 사람이 아니었으므로.

만약 제가 대체 불가능했다면…
어떤 이유를 대며 그만둔다고 말했든 간에 회사에서 먼저 제안 했을 겁니다.
절대 거절할 수 없는 제안을.

그런 제안을 받아본 적이 없다는 것은 슬픈 일입니다.
언제든 대체 가능한 사람이었다는 것이 분명하므로.

https://jeho.page/essay/2024/10/29/irreplaceable.html

월급이 적다는 이유로 회사를 그만둔 적은 없었지만… 그런 이유를 대봤으면 어땠을까 상상해 봤습니다. “얼마나 올려주면 되는데?” “50퍼센트요.” 한 번쯤 그렇게 말해볼 걸. 회사에서 인정하는 진짜 내 가치를 알 수 있을 테니깐. 하지만 저는 답을 알고 있기도 합니다.“잘 가라.” 저는 대체 불가능한 사람이 아니었으므로. 만약 제가 대체 불가능했다면… 어떤 이유를 대며 그만둔다고 말했든 간에 회사에서 먼저 제안 했을 겁니다.절대 거절할 수 없는 제안을. 그런 제안을 받아본 적이 없다는 것은 슬픈 일입니다. 언제든 대체 가능한 사람이었다는 것이 분명하므로. https://jeho.page/essay/2024/10/29/irreplaceable.html

K리그 프로그래머

Nuôi Lô Khung 247 Blog, ⚽ Cao thủ soi cầu 247 rồng bạch kim chính xác 100, Dự đoán kết quả xổ số siêu chính xác hôm nay ngày mai đánh la thắng không lỗ, nuôi lô khung 1, 2, 3 ngày bất bại MIỄN PHÍ.

Nuôi Lô Khung 247 - Cao Thủ Soi Cầu 247 Rồng Bạch Kim Chính Xác 100

Nuôi Lô Khung 247 Blog, Cao thủ soi cầu 247 rồng bạch kim chính xác 100, Dự đoán kết quả xổ số siêu chính xác hôm nay ngày mai đánh la thắng không lỗ, nuôi lô khung 1, 2, 3 ngày bất bại MIỄN PHÍ.
Website : https://nuoilokhung247.blog/
Điện thoại: 0378874904
Địa chỉ : Thượng Đình, Thanh Xuân, Hà Nội
#nuoilokhung247, #soicau247, #soicau24h, #soicaumienbac, #soicaumb

Nuôi Lô Khung 247 Blog, Cao thủ soi cầu 247 rồng bạch kim chính xác 100, Dự đoán kết quả xổ số siêu chính xác hôm nay ngày mai đánh la thắng không lỗ, nuôi lô khung 1, 2, 3 ngày bất bại MIỄN PHÍ. Website : https://nuoilokhung247.blog/ Điện thoại: 0378874904 Địa chỉ : Thượng Đình, Thanh Xuân, Hà Nội #nuoilokhung247, #soicau247, #soicau24h, #soicaumienbac, #soicaumb

Nuôi Lô Khung 247

Nuôi Lô Khung 247 Blog

nuoilokhung247blog

Nuôi Lô Khung 247 là trang blog hỗ trợ người chơi dự đoán kết quả xổ số với các phương pháp soi cầu chính xác cao.


Nuôi Lô Khung 247 Blog

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필