Write Down the Plan

엔지니어로서 일하면서 우리는 얼마나 자주 우리의 계획을 문서화하고 있을까요? 많은 경우 계획을 머릿속에만 담아두거나 구두로만 설명하고 끝내곤 합니다. 이 글에서는 "성장하는 엔지니어들"이나 "리더들"은 '계획을 글로 남기는' 습관을 가진 사람들이 많다고 합니다. 필자는 자신의 경험을 통해 이 습관이 프로모션과 성장을 가속화했다고 전하고 있습니다. 그렇다면, 계획을 문서화하는 습관이 우리에게 어떤 이점을 줄 수 있을까요?

 * 사고력 향상: 글로 생각을 정리하다 보면 논리적 서사로 전개되며 생각이 더 명확해집니다. 간결하게 쓰려는 과정에서 문제의 최적화나 추가적인 예외 상황을 발견하게 되는 경우도 많습니다.

 * 팀원 간의 정렬 (Alignment) 구축: 계획을 문서로 작성해 공유하면, 피드백을 받으면서 점차 팀원 모두가 같은 페이지에 있게 됩니다. 이를 통해 사전에 이견을 조율하고, 합의를 얻는 과정이 훨씬 수월해집니다.

 * 자신의 가시성 및 인지도 상승: 작성된 계획을 공유하면, 동료나 리더가 그 계획과 성과를 자연스럽게 연결지어 생각하게 됩니다. 덕분에 평가나 성과 회의에서도 미리 인지된 성과가 도움이 되어 보다 원활한 논의가 가능합니다.

이 블로그 글에서는 위와 같은 문서화 습관 덕분에 커리어의 여러 기회를 얻었다고 하는데요. 여러분들은 지금까지의 프로젝트에서 '글로 계획을 남기는' 습관을 얼마나 실천해 보셨나요? 다음 번 프로젝트에서는 이 습관을 도입해 보고 그 효과를 직접 경험해 보는 건 어떨까요?

https://www.developing.dev/p/write-down-the-plan

엔지니어로서 일하면서 우리는 얼마나 자주 우리의 계획을 문서화하고 있을까요? 많은 경우 계획을 머릿속에만 담아두거나 구두로만 설명하고 끝내곤 합니다. 이 글에서는 "성장하는 엔지니어들"이나 "리더들"은 '계획을 글로 남기는' 습관을 가진 사람들이 많다고 합니다. 필자는 자신의 경험을 통해 이 습관이 프로모션과 성장을 가속화했다고 전하고 있습니다. 그렇다면, 계획을 문서화하는 습관이 우리에게 어떤 이점을 줄 수 있을까요? <ul ><li>사고력 향상: 글로 생각을 정리하다 보면 논리적 서사로 전개되며 생각이 더 명확해집니다. 간결하게 쓰려는 과정에서 문제의 최적화나 추가적인 예외 상황을 발견하게 되는 경우도 많습니다.</li></ul> <ul ><li>팀원 간의 정렬 (Alignment) 구축: 계획을 문서로 작성해 공유하면, 피드백을 받으면서 점차 팀원 모두가 같은 페이지에 있게 됩니다. 이를 통해 사전에 이견을 조율하고, 합의를 얻는 과정이 훨씬 수월해집니다.</li></ul> <ul ><li>자신의 가시성 및 인지도 상승: 작성된 계획을 공유하면, 동료나 리더가 그 계획과 성과를 자연스럽게 연결지어 생각하게 됩니다. 덕분에 평가나 성과 회의에서도 미리 인지된 성과가 도움이 되어 보다 원활한 논의가 가능합니다.</li></ul> 이 블로그 글에서는 위와 같은 문서화 습관 덕분에 커리어의 여러 기회를 얻었다고 하는데요. 여러분들은 지금까지의 프로젝트에서 '글로 계획을 남기는' 습관을 얼마나 실천해 보셨나요? 다음 번 프로젝트에서는 이 습관을 도입해 보고 그 효과를 직접 경험해 보는 건 어떨까요? https://www.developing.dev/p/write-down-the-plan

www.developing.dev

계획을 글로 써보기

강연이 끝나고 무대로 달려갔어요. 강연자는 스타트업 CTO로 최근 엑싯을 경험한 분이셨죠. 두 번째 창업을 앞두고 계셨어요.

같이 일하고 싶다고 말씀드렸어요. 인턴으로, 무급이어도 좋다고 말씀드렸어요. 기회가 찾아왔다는 생각에 무작정 들이밀었어요.

그 후 6개월간 수업과 연계해 학교에서 돈을 받고 회사에선 일을 배웠어요. 그게 첫 인턴 경험이었어요.

무대를 향해 달려가던 그때의 두근거림이 아직도 생생해요. 그날의 작은 용기가 지금의 저를 만들었어요.

강연이 끝나고 무대로 달려갔어요. 강연자는 스타트업 CTO로 최근 엑싯을 경험한 분이셨죠. 두 번째 창업을 앞두고 계셨어요. 같이 일하고 싶다고 말씀드렸어요. 인턴으로, 무급이어도 좋다고 말씀드렸어요. 기회가 찾아왔다는 생각에 무작정 들이밀었어요. 그 후 6개월간 수업과 연계해 학교에서 돈을 받고 회사에선 일을 배웠어요. 그게 첫 인턴 경험이었어요. 무대를 향해 달려가던 그때의 두근거림이 아직도 생생해요. 그날의 작은 용기가 지금의 저를 만들었어요.

개발자에겐 용기가 필요해요

그 회사는 지금 어떻게 되었나요?

If you don't believe me, believe the statistics: it's impossible for it to always and only be your fault

Stop telling yourself it’s all on you 

"제 잘못입니다. 모두 책임지겠습니다" 정말 문제를 해결해줄까요?

책임감이 뛰어난 리더들은 높은 기준을 지키려는 마음과 무거운 중압감에 자주 자책하는 모습을 보이기도 하는데요. 그러나 이러한 자책은 결국 팀원들의 자율성을 제한하고, 리더의 위임을 방해하며, 과보호적인 팀 환경을 만들어 팀의 성장을 저해할 수 있습니다.

 * 책임의 내재화 문제: 자신의 실수로 모든 것을 책임지려는 마음가짐은 리더 개인과 팀에 부담을 줍니다. 이로 인해 리더는 점차 모든 일을 스스로 해결하려 하며, 이는 팀의 자율성과 책임 의식을 약화시킵니다.
 * 책임 공유로 전환: 리더는 문제 상황이 발생할 때마다 스스로에게만 책임을 묻기보다, 팀과 함께 책임을 나누며 배우는 문화를 조성해야 합니다. 이를 위해 "내가 통제할 수 있는 것인가?"를 스스로 묻고, 통제할 수 없는 부분은 내려놓는 연습이 필요합니다.
 * 역할과 책임의 명확화: 리더는 팀원들에게 역할과 책임을 명확히 전달해야 합니다. 이를 위해 RACI 매트릭스와 같은 도구를 활용할 수 있습니다.
 * 실수를 학습 기회로 삼는 환경 조성: 팀이 실수할 때마다 배울 수 있는 기회를 제공하고, 이를 통해 자신감을 얻게 해야 합니다.
 * 위임과 주도성 장려: 과도한 통제를 피하고, 팀원들에게 위임과 성장의 기회를 주어야 합니다. 리더는 책임을 혼자 짊어지기보다, 팀 전체의 성장에 기여할 수 있는 환경을 만드는 것이 중요합니다.

리더십에서 책임을 나누는 방식을 통해 팀이 어떻게 성장할 수 있을지 다시 고민해 보는건 어떨까요?

https://leadthroughmistakes.substack.com/p/stop-telling-yourself-its-all-on

"제 잘못입니다. 모두 책임지겠습니다" 정말 문제를 해결해줄까요? 책임감이 뛰어난 리더들은 높은 기준을 지키려는 마음과 무거운 중압감에 자주 자책하는 모습을 보이기도 하는데요. 그러나 이러한 자책은 결국 팀원들의 자율성을 제한하고, 리더의 위임을 방해하며, 과보호적인 팀 환경을 만들어 팀의 성장을 저해할 수 있습니다. <ul ><li>책임의 내재화 문제: 자신의 실수로 모든 것을 책임지려는 마음가짐은 리더 개인과 팀에 부담을 줍니다. 이로 인해 리더는 점차 모든 일을 스스로 해결하려 하며, 이는 팀의 자율성과 책임 의식을 약화시킵니다.</li><li>책임 공유로 전환: 리더는 문제 상황이 발생할 때마다 스스로에게만 책임을 묻기보다, 팀과 함께 책임을 나누며 배우는 문화를 조성해야 합니다. 이를 위해 "내가 통제할 수 있는 것인가?"를 스스로 묻고, 통제할 수 없는 부분은 내려놓는 연습이 필요합니다.</li><li>역할과 책임의 명확화: 리더는 팀원들에게 역할과 책임을 명확히 전달해야 합니다. 이를 위해 RACI 매트릭스와 같은 도구를 활용할 수 있습니다.</li><li>실수를 학습 기회로 삼는 환경 조성: 팀이 실수할 때마다 배울 수 있는 기회를 제공하고, 이를 통해 자신감을 얻게 해야 합니다.</li><li>위임과 주도성 장려: 과도한 통제를 피하고, 팀원들에게 위임과 성장의 기회를 주어야 합니다. 리더는 책임을 혼자 짊어지기보다, 팀 전체의 성장에 기여할 수 있는 환경을 만드는 것이 중요합니다.</li></ul> 리더십에서 책임을 나누는 방식을 통해 팀이 어떻게 성장할 수 있을지 다시 고민해 보는건 어떨까요? https://leadthroughmistakes.substack.com/p/stop-telling-yourself-its-all-on

leadthroughmistakes.substack.com

"모두 제 잘못입니다" 멈추기

“애사심이 넘치는 거 같아”

회사 로고가 그려진 티셔츠, 가방을 들고 가는 저를 보고 아내가 해준 말이에요.

돌이켜보면 제가 다녔던 모든 회사를 참 좋아하는 거 같아요.

지금도 마플에서 만든 프린팅 티셔츠를 입고 있어요. 평소에는 뱅크샐러드로 가계부를 쓰죠.

제품이 좋아서 입사한 경우가 아니라도 매일 들여다보는 제품에 애정이 생기는 게 제게는 자연스러운 일이었어요.

실제 유저라면 개밥먹기에도 유리하고요. 무엇보다 삶에 대한 만족도가 오르죠. 매일 하는 일이 좋아하는 제품을 만드는 일이니까요.

“애사심이 넘치는 거 같아” 회사 로고가 그려진 티셔츠, 가방을 들고 가는 저를 보고 아내가 해준 말이에요. 돌이켜보면 제가 다녔던 모든 회사를 참 좋아하는 거 같아요. 지금도 마플에서 만든 프린팅 티셔츠를 입고 있어요. 평소에는 뱅크샐러드로 가계부를 쓰죠. 제품이 좋아서 입사한 경우가 아니라도 매일 들여다보는 제품에 애정이 생기는 게 제게는 자연스러운 일이었어요. 실제 유저라면 개밥먹기에도 유리하고요. 무엇보다 삶에 대한 만족도가 오르죠. 매일 하는 일이 좋아하는 제품을 만드는 일이니까요.

기업의 Next Step을 위한 미래 비즈니스 생태계를 주도하는 SKT Enterprise 사이트 입니다. 강력한 유무선 통신에 더하여 Cloud, IoT, AI 등 최신 기술로 기업의 Digital Transformation을 함께합니다.

SKT Enterprise

트랜스포머 모델을 이해하려면 수학적인 기반이 있어야 하는데요.
벡터의 내적부터가 무슨말인지 이해를 못하는 저 같은 사람에게 아주 도움되는 글입니다.
2편 까지 나왔는데, 내용이 재밌습니다.

1편
https://devocean.sk.com/blog/techBoardDetail.do?ID=166725

2편
https://www.sktenterprise.com/bizInsight/blogDetail/dev/12766

트랜스포머 모델을 이해하려면 수학적인 기반이 있어야 하는데요. 벡터의 내적부터가 무슨말인지 이해를 못하는 저 같은 사람에게 아주 도움되는 글입니다. 2편 까지 나왔는데, 내용이 재밌습니다. 1편 https://devocean.sk.com/blog/techBoardDetail.do?ID=166725 2편https://www.sktenterprise.com/bizInsight/blogDetail/dev/12766

www.sktenterprise.com

고등학생도 이해하는 트랜스포머

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

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

정리하면, 제한된 리소스를 이용하여 회사에 이익에 집중하여 최대의 결과를 준다는 생각이 드네요. 아무래도 영문 블로그는 찾아보기도 어렵고, 찾아도 살펴보기 어려운데 이렇게 요약하고 정리해주셔서 감사드립니다.

📱🧑🏻‍💻 D+48

✅ 서버간 데이터 교환 구조 리팩토링

개발하면서 스펙을 정하는 방법을 사용하고 있어서 유닛 테스트 작업을 거의 못하고 있는데, 코어 부분에는 몇 개라도 만들어 놓은 덕분에 덜 불안하고 빠르게 작업 할 수 있었다.

대신에 타입을 최대한 잘 작성하고 사용하려고 노력중인데, 확실히 CRUD 수준의 기능은 타입만 잘 써도 유닛 테스트 효과를 볼 수 있다.

암튼 이제 전체 플로우를 실질적으로 실험할 수 있는 시점이 와서, 덕분에(?) 2주에 한 번씩은 작지 않은 리팩토링을 반복적으로 하게 될 것 같다.. 🥲

📱🧑🏻‍💻 D+48 ✅ 서버간 데이터 교환 구조 리팩토링 개발하면서 스펙을 정하는 방법을 사용하고 있어서 유닛 테스트 작업을 거의 못하고 있는데, 코어 부분에는 몇 개라도 만들어 놓은 덕분에 덜 불안하고 빠르게 작업 할 수 있었다. 대신에 타입을 최대한 잘 작성하고 사용하려고 노력중인데, 확실히 CRUD 수준의 기능은 타입만 잘 써도 유닛 테스트 효과를 볼 수 있다. 암튼 이제 전체 플로우를 실질적으로 실험할 수 있는 시점이 와서, 덕분에(?) 2주에 한 번씩은 작지 않은 리팩토링을 반복적으로 하게 될 것 같다.. 🥲

자바스크립트의 groupBy() 사용법

데이터를 특정 기준에 따라 분류하는 것은 자바스크립트로 데이터 처리를 할 때 자주 필요한 작업인데요. 그런데 아직도 데이터 그룹화를 위해서
reduce()
함수나 Lodash 라이브러리를 사용하시나요?

이번 포스팅에서는 자바스크립트에서 데이터를 그룹화를 위해 쓸 수 있는 비교적 새로운 API인
groupBy()
에 대해서 알아보도록 하겠습니다.

📝 포스팅: https://www.daleseo.com/js-group-by/

관련 게시물
📕 자바스크립트 배열의 reduce() 사용법: https://careerly.co.kr/comments/109141

데이터를 특정 기준에 따라 분류하는 것은 자바스크립트로 데이터 처리를 할 때 자주 필요한 작업인데요. 그런데 아직도 데이터 그룹화를 위해서 <code >reduce()</code> 함수나 Lodash 라이브러리를 사용하시나요? 이번 포스팅에서는 자바스크립트에서 데이터를 그룹화를 위해 쓸 수 있는 비교적 새로운 API인 <code >groupBy()</code>에 대해서 알아보도록 하겠습니다. 📝 포스팅: https://www.daleseo.com/js-group-by/ 관련 게시물📕 자바스크립트 배열의 reduce() 사용법: https://careerly.co.kr/comments/109141

www.daleseo.com

자바스크립트의 groupBy() API 사용법

지금까지 다녔던 회사를 세어보니 5개네요.
약 15년간 일했으니 평균 3년 정도를 다녔나 봅니다.
스타트업부터 중소기업, 대기업까지.

저는 제가 다닌 모든 회사의 주식을 어떤 방식으로든 보유했습니다.

1. 우리사주로 얻은 것도 있었고
2. 스톡옵션으로 받은 것
3. 상장 회사 주식을 시장에서 매입한 것
4. 전환사채로 회사에 돈을 빌려주고 나중에 주식으로 전환한 일
5. 창업자들의 기존 주식을 산 것까지
소소한 이익을 얻은 것도 있었고 완전 대박 그리고 완전 망함 까지.
이 또한 다양한 경험들을 했습니다.

투자라고 하면 주식이나 부동산 투자가 먼저 생각나겠지만,
회사를 선택하는 것이야말로 그보다 중요한 투자 일지 모릅니다.
(또 다른 중요 투자로는 결혼이 있겠습니다)

내 주위에 어떤 사람이 있을 것인지.
하루 중 가장 많은 시간을 투자하는 그 일이 얼마나 즐거울 것인지.
얼마나 큰 부를 얻을 것인지.
이런 것들은 삶에서 정말 중요한 요소잖아요?

회사를 고른다는 건 이런 중요한 선택을 하는 것인데,
이렇게 고민하고 선택한 회사의 주식을 (살 수 있는데도) 사지 않는 것이 좀 이상했습니다.
뭔가 모순되는 것처럼 느껴졌거든요.

회사가 잘 될 거라는 기대가 없고 함께 일하는 동료들을 존경하지도 않는다면 왜 다니기로 선택한 거지?
월급만을 위해서?
한 번 선택하면 인생의 3년이 지나가는데, 과연 나는 좋은 선택을 한 것일까?

다니는 회사의 주식을 산다는 것은 회사와 나를 엮는 일입니다.
나와 회사의 목표를 일치 시킨다고 말할 수도 있겠습니다.
이렇게 하면 주인 의식을 갖기도 좋습니다. 소소하지만, 진짜 법적 주인이 되는 거니까.
저는 이렇게 일하는 것이 더 즐겁습니다.

어떤 사람들은 분산 투자를 하라는 뜻으로 이렇게 말합니다.
“왜 계란을 한 바구니에 담으려고 하시나요?”
그러면 저는 이런 생각이 듭니다.

‘자기가 선택한 회사를 못 믿고 다른 회사를 믿을 거면 그냥 그 다른 회사 다니는 게 좋지 않을까?’

저는 제가 모르는 사람들이 일하는 회사 주식보다는 저와 제가 선택한 동료들이 일하는 회사의 주식을 갖고 싶거든요.

한편으로 이런 생각도 해보면 좋습니다.
나는 과연 회사를 충분히 신중하게 선택하는가?
나와 맞는 직무가 있다는 이유만으로 선택한 건 아닐까?

회사 한 번 선택하면 인생의 빛나는 시절 몇 년이 순식간에 지나갑니다.
그럴만한 가치가 있는 회사와 시간을 보내야 합니다.

지금까지 다녔던 회사를 세어보니 5개네요. 약 15년간 일했으니 평균 3년 정도를 다녔나 봅니다. 스타트업부터 중소기업, 대기업까지. 저는 제가 다닌 모든 회사의 주식을 어떤 방식으로든 보유했습니다. 1. 우리사주로 얻은 것도 있었고 2. 스톡옵션으로 받은 것 3. 상장 회사 주식을 시장에서 매입한 것 4. 전환사채로 회사에 돈을 빌려주고 나중에 주식으로 전환한 일 5. 창업자들의 기존 주식을 산 것까지 소소한 이익을 얻은 것도 있었고 완전 대박 그리고 완전 망함 까지. 이 또한 다양한 경험들을 했습니다. 투자라고 하면 주식이나 부동산 투자가 먼저 생각나겠지만, 회사를 선택하는 것이야말로 그보다 중요한 투자 일지 모릅니다. (또 다른 중요 투자로는 결혼이 있겠습니다) 내 주위에 어떤 사람이 있을 것인지. 하루 중 가장 많은 시간을 투자하는 그 일이 얼마나 즐거울 것인지. 얼마나 큰 부를 얻을 것인지. 이런 것들은 삶에서 정말 중요한 요소잖아요? 회사를 고른다는 건 이런 중요한 선택을 하는 것인데, 이렇게 고민하고 선택한 회사의 주식을 (살 수 있는데도) 사지 않는 것이 좀 이상했습니다. 뭔가 모순되는 것처럼 느껴졌거든요. 회사가 잘 될 거라는 기대가 없고 함께 일하는 동료들을 존경하지도 않는다면 왜 다니기로 선택한 거지? 월급만을 위해서? 한 번 선택하면 인생의 3년이 지나가는데, 과연 나는 좋은 선택을 한 것일까? 다니는 회사의 주식을 산다는 것은 회사와 나를 엮는 일입니다. 나와 회사의 목표를 일치 시킨다고 말할 수도 있겠습니다. 이렇게 하면 주인 의식을 갖기도 좋습니다. 소소하지만, 진짜 법적 주인이 되는 거니까. 저는 이렇게 일하는 것이 더 즐겁습니다. 어떤 사람들은 분산 투자를 하라는 뜻으로 이렇게 말합니다. “왜 계란을 한 바구니에 담으려고 하시나요?” 그러면 저는 이런 생각이 듭니다. ‘자기가 선택한 회사를 못 믿고 다른 회사를 믿을 거면 그냥 그 다른 회사 다니는 게 좋지 않을까?’ 저는 제가 모르는 사람들이 일하는 회사 주식보다는 저와 제가 선택한 동료들이 일하는 회사의 주식을 갖고 싶거든요. 한편으로 이런 생각도 해보면 좋습니다. 나는 과연 회사를 충분히 신중하게 선택하는가? 나와 맞는 직무가 있다는 이유만으로 선택한 건 아닐까? 회사 한 번 선택하면 인생의 빛나는 시절 몇 년이 순식간에 지나갑니다. 그럴만한 가치가 있는 회사와 시간을 보내야 합니다.

회사 선택은 어떤 재테크보다도 중요한 투자

올해는 허언이 아니에요. 3개월 전 첫 영상을 올렸으니까요. 그 후로 6개를 더 올렸죠.

그리고 오늘, 구독자 300명이 됐어요. 아직 컨셉도 모호하고 카메라는 어색해요. 하지만 재밌어요.

해보니까 다른 소셜은 취미고 유튜브는 사업이더라고요. 유튜브를 하면서 ‘크리에이터’라는 수식어가 붙어요.

배우는 게 많아요. 시도해 보고 싶은 것도 있고요. 앞으로 더 유익하고 재미있는 채널이 될 테니까 지켜봐 주세요!

올해는 허언이 아니에요. 3개월 전 첫 영상을 올렸으니까요. 그 후로 6개를 더 올렸죠. 그리고 오늘, 구독자 300명이 됐어요. 아직 컨셉도 모호하고 카메라는 어색해요. 하지만 재밌어요. 해보니까 다른 소셜은 취미고 유튜브는 사업이더라고요. 유튜브를 하면서 ‘크리에이터’라는 수식어가 붙어요. 배우는 게 많아요. 시도해 보고 싶은 것도 있고요. 앞으로 더 유익하고 재미있는 채널이 될 테니까 지켜봐 주세요!

유튜브 해본다는 허언

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 분야 뿐만 아니라, 다양한 영역에서 내가 어떤 스킬을 얼마나 갖추고 있는지를 생각해보세요. - 하드 스킬 - 소프트 스킬 - 커리어 스킬 기업이 뽑고 싶어하는, 아니 기업이 뽑을수 밖에 없는 인재들은 이런 디테일을 가지고 있답니다. 하드 스킬, 소프트 스킬, 그리고 커리어 스킬을 각각 성장의 관점에서 바라보고 주기적으로 점검하는 습관을 들여보세요. 이렇게 스스로 분석하고 객관적으로 바라볼수 있다면, 결국 기업에서 찾는 '핵심 인재'로 자리매김하게 될 거예요.

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

산호세 주립대에서 데이터 엔지니어링 강의를 가르친지 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리그 프로그래머

Vercel의 행보가 진짜 무섭네요. 이번에는 프론트엔드 코드를 만드는 생성형 AI 서비스입니다.

원하는 ui를 자연어로 말하면 화면을 만들어주고 그에 맞는 코드까지도 생성해줍니다.
심지어 한번에 모든 요구사항을 넘기는 것이 아니라 추가적인 요구사항을 입력하면 v1, v2, v3 .... 계속 쌓아가며 요구사항을 적용하여 업데이트 시켜줍니다.

쇼케이스에 있는 "give me a tweet" 을 보니 처음에는 간단한 트윗 모양으로 시작하여
"Add a rounded circle profile photo to the left of the name"
"make it 500px"
...
"make the twitter bird solid fill blue also increase the spacing between the reactions by a little bit"

원하는 모양으로 계속 업데이트 하고 이를 React와 HTML 코드로까지 생성해주고 있습니다.

아직 waiting list 를 통해서 받고 있지만 이미 유료 구독 플랜까지 열려있기 때문에 금방 써볼수 있지 않을까 싶습니다.

https://vercel.com/blog/announcing-v0-generative-ui
https://v0.dev/

Vercel의 행보가 진짜 무섭네요. 이번에는 프론트엔드 코드를 만드는 생성형 AI 서비스입니다. 원하는 ui를 자연어로 말하면 화면을 만들어주고 그에 맞는 코드까지도 생성해줍니다. 심지어 한번에 모든 요구사항을 넘기는 것이 아니라 추가적인 요구사항을 입력하면 v1, v2, v3 .... 계속 쌓아가며 요구사항을 적용하여 업데이트 시켜줍니다. 쇼케이스에 있는 "give me a tweet" 을 보니 처음에는 간단한 트윗 모양으로 시작하여 "Add a rounded circle profile photo to the left of the name""make it 500px"... "make the twitter bird solid fill blue also increase the spacing between the reactions by a little bit" 원하는 모양으로 계속 업데이트 하고 이를 React와 HTML 코드로까지 생성해주고 있습니다. 아직 waiting list 를 통해서 받고 있지만 이미 유료 구독 플랜까지 열려있기 때문에 금방 써볼수 있지 않을까 싶습니다. <a target="_blank" rel="noopener noreferrer nofollow" href="https://vercel.com/blog/announcing-v0-generative-ui">https://vercel.com/blog/announcing-v0-generative-ui</a><a target="_blank" rel="noopener noreferrer nofollow" href="https://v0.dev/">https://v0.dev/</a>

Vercel - v0

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필