나 없이 조직이 돌아가지 않으면 내가 트롤이다 | 조직의 중요한 결정은 다 나 몰래 내려진다. '윗분들은' 정말 쉬쉬하고 싶은 것일까?' 에 이어 다시 IT 원주민들의 회사 생활을 엿보자. 원준팀의 '애니메이션 커뮤니티' 서비스는 점점 성장해서 직원 수도 100여 명이 넘고 다음 시리즈 유치도 성공하며 업계에서 꽤 이름 난 스타트업이 되었다.

리더가 없어도 의사결정할 수 있어야 한다.

팀원들은 ‘팀장님이 문제를 해결해 주실 거야.’라고 생각하고 팀장은 ‘팀장인 내가 팀원 간 문제를 해결해야지.’라고 생각하지만 반은 맞고 반은 틀리다. 좋은 원칙이 있고 정보가 잘 흐른다면 누구나 좋은 의사결정을 할 수 있어야 한다.

예를 들면 담당자끼리 이야기하다가 풀리지 않으면 상위 담당자끼리 이야기해서 문제를 해결하는 시도는 자칫 편리해 보이지만 다음과 같은 문제를 야기한다   

 1. 팀 자체적인 문제해결 능력이 약해진다 : 가장 전문성을 갖춘 개개인이 스스로 문제해결을 하고 실패 속에서 배우는 시스템이 구축되지 않는다.
 2. 의사결정 속도가 느려진다. 언제든 상위 의사결정자를 부를 수 있다는 것은 결국 실무자 둘이 이야기할 것을 상위 의사결정자가 결정한다는 뜻. 의존성을 만들면 당연히 의사결정 속도가 느려진다.
 3. 상위 리더십이 더 중요한 결정에 시간을 쓸 수 없다. 팀장들이 매사 ‘불 끄러’ 다닌다고 더 중요한 전략적 의사결정과 로드맵 수립 같은 일에 투자할 수 없다. 이는 모호한 전략과 애매한 실행으로 이어져 성과가 안 좋아지고, 성과가 안 좋아지면 조직 간 갈등이 증가하는 악순환이 시작된다.

IT기업은 대부분 역할 조직의 형태를 따르고 있다. 역할 조직에서는 각자 ‘일당백’을 하므로 ‘나 없으면 돌아가지 않는 조직’이 되는 것이 일 잘하는 것이라 생각할 수 있지만 정반대다.  역할 조직에서는 누군가 없어져도 언제든 대체할 수 있다. 

내가 없어도 잘 돌아가고, 내가 있으면 더 잘 돌아가야 한다. 내가 없어져서 조직이 멈춰버리거나 급격히 성능이 저하된다면 조직 엔지니어링에 실패한 것이다. 팀장이 빠져도 팀원이 70~80% 수준의 의사 결정과 결과물을 낼 수 있어야 한다.

문제는 ‘리더가 의사결정을 마음대로 해서’가 아니다. 의사결정은 리더의 고유 권한이고 주요한 업무 중 하나라는 것을 구성원도 모두 이해하고 있다.  불만은 리더가 의사 결정해서가 아니라 의사결정에 필요한 정보와 과정을 구성원이 알 수 없기 때문에 불만이 생긴다.  리더가 해야 할 일 중에 가장 중요한 일은 ‘팀원들이 나와 비슷한 수준으로 의사결정할 수 있도록 정보가 흐르게 하는 것이다.

역할 조직에서 정보가 제대로 흐르지 않고 정치가 심화되면 각자의 정보 독점이 일어나면서 각자 성과보다는 ‘지위 관리’에 집중하게 된다. 각자의 지위와 권력을 유지하기 위해 역할을 나누고, 쪼개고, 허락을 구하고 결재받는 시간이 길어지며 의사결정과 업무 속도가 느려진다. 회의 아젠다로 ‘역할 나누기’가, ‘000팀, 검토해 주세요.’라는 요청이 업무에 자주 등장하게 된다

의사결정을 위해 무슨 팀을 찾아갈지 찾는 일이 일상다반사가 된다. 정보의 독점으로 인해 각자의 정보 의존성을 이겨내지 못하면 업무 자체가 진행되지 않기 때문이다. 속도가 곧 경쟁력임을 표방하는 스타트업에서는 이보다 큰 위기신호가 없다.

이를 해결하기 위해서는 다음과 같은 실행이 뒤따라야 한다.

1. 의사결정자, 담당자, 커뮤니케이션 채널을 명확하게 지정한다.

리더는 프로젝트 시작 전에 책임자를 분명하게 정해야 한다. 개인 실무자가 조직의 역학관계를 파악하는 것은 불가능하다. 정리된 내용은 관련 담당자 모두가 볼 수 있는 채널에 공유되어야 하며, 프로젝트 중 담당자 변경이 있다면 같은 채널에 이를 알려야 한다.

2. 프로젝트 관련된 정보가 공유되고 원칙이 세워진다.

프로젝트 관련된 정보가 투명하게 공유되어야 한다. 각 담당자는 프로젝트에 관련된 정보를 ‘파악하는 것’뿐 아니라 적절한 대상에게 공유하여 모두가 접근할 수 있도록 해야 한다.프로젝트의 ‘전략적 원칙’이 수립되어야 하는데, 여기서 말하는 전략적 원칙이란 프로젝트 목표를 달성하기 위해 ‘무엇을 얻고 무엇을 포기할지’ 명확하게 선언된 것을 말한다. 명확한 프로젝트 원칙은 리더 없이도 구성원이 좋은 결정을 내릴 수 있도록 돕는다.

3. 정보가 적시에 전달된다.

정보는 필요한 사람이 찾아보기 전에 의사결정을 내린 사람이 책임지고 전달해야 한다. 이는 리더나 실무자 모두에게 해당되며 프로젝트 진행 중 개개인 구성원이 노력이 필요하다. 시점은 의사결정된 즉시가 가장 좋다. 위에서 정리된 의사결정자, 담당자, 커뮤니케이션 채널을 참고해서 담당자에게 전달한다.

https://brunch.co.kr/@kgbtomas/291

팀원들은 ‘팀장님이 문제를 해결해 주실 거야.’라고 생각하고 팀장은 ‘팀장인 내가 팀원 간 문제를 해결해야지.’라고 생각하지만 반은 맞고 반은 틀리다. 좋은 원칙이 있고 정보가 잘 흐른다면 누구나 좋은 의사결정을 할 수 있어야 한다. 예를 들면 담당자끼리 이야기하다가 풀리지 않으면 상위 담당자끼리 이야기해서 문제를 해결하는 시도는 자칫 편리해 보이지만 다음과 같은 문제를 야기한다 &nbsp;&nbsp; <ol ><li>팀 자체적인 문제해결 능력이 약해진다 : 가장 전문성을 갖춘 개개인이 스스로 문제해결을 하고 실패 속에서 배우는 시스템이 구축되지 않는다.</li><li>의사결정 속도가 느려진다. 언제든 상위 의사결정자를 부를 수 있다는 것은 결국 실무자 둘이 이야기할 것을 상위 의사결정자가 결정한다는 뜻. 의존성을 만들면 당연히 의사결정 속도가 느려진다.</li><li>상위 리더십이 더 중요한 결정에 시간을 쓸 수 없다. 팀장들이 매사 ‘불 끄러’ 다닌다고 더 중요한 전략적 의사결정과 로드맵 수립 같은 일에 투자할 수 없다. 이는 모호한 전략과 애매한 실행으로 이어져 성과가 안 좋아지고, 성과가 안 좋아지면 조직 간 갈등이 증가하는 악순환이 시작된다.</li></ol> IT기업은 대부분 역할 조직의 형태를 따르고 있다. 역할 조직에서는 각자 ‘일당백’을 하므로 ‘나 없으면 돌아가지 않는 조직’이 되는 것이 일 잘하는 것이라 생각할 수 있지만 정반대다.&nbsp;&nbsp;역할 조직에서는 누군가 없어져도 언제든 대체할 수 있다.&nbsp; 내가 없어도 잘 돌아가고, 내가 있으면 더 잘 돌아가야 한다. 내가 없어져서 조직이 멈춰버리거나 급격히 성능이 저하된다면 조직 엔지니어링에 실패한 것이다. 팀장이 빠져도 팀원이 70~80% 수준의 의사 결정과 결과물을 낼 수 있어야 한다. 문제는 ‘리더가 의사결정을 마음대로 해서’가 아니다. 의사결정은 리더의 고유 권한이고 주요한 업무 중 하나라는 것을 구성원도 모두 이해하고 있다. &nbsp;불만은 리더가 의사 결정해서가 아니라 의사결정에 필요한 정보와 과정을 구성원이 알 수 없기 때문에 불만이 생긴다.&nbsp;&nbsp;리더가 해야 할 일 중에 가장 중요한 일은 ‘팀원들이 나와 비슷한 수준으로 의사결정할 수 있도록 정보가 흐르게 하는 것이다. 역할 조직에서 정보가 제대로 흐르지 않고 정치가 심화되면 각자의 정보 독점이 일어나면서 각자 성과보다는 ‘지위 관리’에 집중하게 된다.&nbsp;각자의 지위와 권력을 유지하기 위해 역할을 나누고, 쪼개고, 허락을 구하고 결재받는 시간이 길어지며 의사결정과 업무 속도가 느려진다. 회의 아젠다로 ‘역할 나누기’가, ‘000팀, 검토해 주세요.’라는 요청이 업무에 자주 등장하게 된다 의사결정을 위해 무슨 팀을 찾아갈지 찾는 일이 일상다반사가 된다. 정보의 독점으로 인해 각자의 정보 의존성을 이겨내지 못하면 업무 자체가 진행되지 않기 때문이다. 속도가 곧 경쟁력임을 표방하는 스타트업에서는 이보다 큰 위기신호가 없다. 이를 해결하기 위해서는 다음과 같은 실행이 뒤따라야 한다. 1. 의사결정자, 담당자, 커뮤니케이션 채널을 명확하게 지정한다. 리더는 프로젝트 시작 전에 책임자를 분명하게 정해야 한다. 개인 실무자가 조직의 역학관계를 파악하는 것은 불가능하다. 정리된 내용은 관련 담당자 모두가 볼 수 있는 채널에 공유되어야 하며, 프로젝트 중 담당자 변경이 있다면 같은 채널에 이를 알려야 한다. 2. 프로젝트 관련된 정보가 공유되고 원칙이 세워진다. 프로젝트 관련된 정보가 투명하게 공유되어야 한다. 각 담당자는 프로젝트에 관련된 정보를 ‘파악하는 것’뿐 아니라 적절한 대상에게 공유하여 모두가 접근할 수 있도록 해야 한다.프로젝트의 ‘전략적 원칙’이 수립되어야 하는데, 여기서 말하는 전략적 원칙이란 프로젝트 목표를 달성하기 위해 ‘무엇을 얻고 무엇을 포기할지’ 명확하게 선언된 것을 말한다. 명확한 프로젝트 원칙은 리더 없이도 구성원이 좋은 결정을 내릴 수 있도록 돕는다. 3. 정보가 적시에 전달된다. 정보는 필요한 사람이 찾아보기 전에 의사결정을 내린 사람이 책임지고 전달해야 한다. 이는 리더나 실무자 모두에게 해당되며 프로젝트 진행 중 개개인 구성원이 노력이 필요하다. 시점은 의사결정된 즉시가 가장 좋다. 위에서 정리된 의사결정자, 담당자, 커뮤니케이션 채널을 참고해서 담당자에게 전달한다. https://brunch.co.kr/@kgbtomas/291

Brunch Story

리더가 없어도 결정은 내려진다.

대학교에서 학생 개발자 커뮤니티를 이끄는 것이 매력적으로 느껴지나요? Google 기술에 열정이 있거나 기술에 대해 더 많이 배우고 싶으신가요? 기술 관련 이벤트를 기획하여 커뮤니티가 기술을 배울 수 있는 새로운 방법을 기획하는 것에 관심있나요? ...

2024-25 Google Developer Student Clubs Korea의 Lead로 지원해보세요!

﻿
구글의 대학생 개발자 커뮤니티 GDSC(Google Developer Student Clubs) 2024-2025에 활동할 GDSC Lead 지원서가 열렸다고 합니다. 주변에 알려주시고, 관심있는 대학생 여러분들 살펴보세요.

아래 내용은 제가 사이트에서 공유를 위해 퍼왔어요.
﻿
-----
대학교에서 학생 개발자 커뮤니티를 이끄는 것이 매력적으로 느껴지나요? Google 기술에 열정이 있거나 기술에 대해 더 많이 배우고 싶으신가요? 기술 관련 이벤트를 기획하여 커뮤니티가 기술을 배울 수 있는 새로운 방법을 기획하는 것에 관심있나요?

그렇다면 Google Developer Student Club의 Lead가 되어보세요. 2024-2025에 활동할 GDSC Lead 지원서가 열려있습니다! (대한민국의 대학교에서 지원하시는 경우, 지원서를 한국어로 작성하셔도 됩니다.)

➡ Google Developer Student Clubs(GDSC)는 무엇인가요?

Google Developer Student Clubs(GDSC)는 Google 기술에 관심있는 학생들을 위한 대학교 기반 커뮤니티 그룹입니다. 전 세계 100여 개국에서 2000개 이상의 GDSC 챕터가 있으며, 인공지능, 머신러닝, Google 클라우드, 안드로이드 개발, Flutter 및 기타 혁신적인 기술을 함께 탐구하고 있습니다. GDSC 챕터는 초청 연사 및 기술 전문가와 함께 해커톤, Solution Challenge 등 프로젝트 기반의 대면 행사를 주최합니다.

➡ Google Developer Student Club Lead 가 되면 왜 좋은가요?

GDSC를 이끄는 것은 새로운 프로그래밍 기술을 배우고, Google 기술에 대해 깊이 있게 알아보고, 챕터와 지역 내에서 영향력을 발휘하는 동시에 네트워크를 구축할 수 있는 좋은 기회입니다. GDSC 리드는 캠퍼스 기반의 커뮤니티를 관리하면서 기술 및 리더십을 습득할 수 있습니다.

GDSC Leads:
> Google의 멘토링을 받을 수 있습니다.
> 글로벌 GDSC 리드 커뮤니티에 참여합니다. 
> 동료들이 개발자로의 여정에서 Google 기술을 사용할 수 있도록 교육합니다.
> 기술을 사용하여 현실 속 문제에 대한 솔루션을 찾습니다.

지원 마감  2024년 5월 30일

https://developers-kr.googleblog.com/2024/04/202402google-developer-student-clubs-lead-opportunity.html

﻿구글의&nbsp;대학생&nbsp;개발자&nbsp;커뮤니티&nbsp;GDSC(Google&nbsp;Developer&nbsp;Student&nbsp;Clubs)&nbsp;2024-2025에&nbsp;활동할&nbsp;GDSC&nbsp;Lead&nbsp;지원서가&nbsp;열렸다고&nbsp;합니다.&nbsp;주변에 알려주시고, 관심있는&nbsp;대학생&nbsp;여러분들&nbsp;살펴보세요. 아래 내용은 제가 사이트에서 공유를 위해 퍼왔어요.﻿-----대학교에서 학생 개발자 커뮤니티를 이끄는 것이 매력적으로 느껴지나요? Google 기술에 열정이 있거나 기술에 대해 더 많이 배우고 싶으신가요? 기술 관련 이벤트를 기획하여 커뮤니티가 기술을 배울 수 있는 새로운 방법을 기획하는 것에 관심있나요? 그렇다면 Google Developer Student Club의 Lead가 되어보세요. 2024-2025에 활동할 GDSC Lead 지원서가 열려있습니다! (대한민국의 대학교에서 지원하시는 경우, 지원서를 한국어로 작성하셔도 됩니다.) ➡ Google Developer Student Clubs(GDSC)는 무엇인가요? Google Developer Student Clubs(GDSC)는 Google 기술에 관심있는 학생들을 위한 대학교 기반 커뮤니티 그룹입니다. 전 세계 100여 개국에서 2000개 이상의 GDSC 챕터가 있으며, 인공지능, 머신러닝, Google 클라우드, 안드로이드 개발, Flutter 및 기타 혁신적인 기술을 함께 탐구하고 있습니다. GDSC 챕터는 초청 연사 및 기술 전문가와 함께 해커톤, Solution Challenge 등 프로젝트 기반의 대면 행사를 주최합니다. ➡ Google Developer Student Club Lead 가 되면 왜 좋은가요? GDSC를 이끄는 것은 새로운 프로그래밍 기술을 배우고, Google 기술에 대해 깊이 있게 알아보고, 챕터와 지역 내에서 영향력을 발휘하는 동시에 네트워크를 구축할 수 있는 좋은 기회입니다. GDSC 리드는 캠퍼스 기반의 커뮤니티를 관리하면서 기술 및 리더십을 습득할 수 있습니다. GDSC Leads: &gt; Google의 멘토링을 받을 수 있습니다. &gt; 글로벌 GDSC 리드 커뮤니티에 참여합니다.&nbsp; &gt; 동료들이 개발자로의 여정에서 Google 기술을 사용할 수 있도록 교육합니다. &gt; 기술을 사용하여 현실 속 문제에 대한 솔루션을 찾습니다. 지원 마감 &nbsp;2024년 5월 30일 https://developers-kr.googleblog.com/2024/04/202402google-developer-student-clubs-lead-opportunity.html

Google for Developers Korea Blog

[정보] 구글 개발자 대학생 클럽 리더로 신청하세요

디자인 시스템, 코드를 넘어서

https://so-so.dev/react/design-system-beyond-code/

같은 걸 3번 만드는 경험은 흔치 않죠. 그래서 글에 깊은 맛이 있답니다!!

https://so-so.dev/react/design-system-beyond-code/ 같은 걸 3번 만드는 경험은 흔치 않죠. 그래서 글에 깊은 맛이 있답니다!!

So-so

디자인시스템 3번만든 이야기

인간은 왜 기쁨 스위치가 쉽게 꺼질까? 아무리 기쁜 일이 생겨도 그 기쁨은 잠깐이다. 수년간 몸과 영혼을 팔아 높은 자리에 오른들 그 기쁨은 순간이다. 왜 신(神)은 인간에게 잠깐의 쾌락만을 허락한 것일까? 좀 더 오래 지속되는 쾌락을

[김인수 기자의 사람이니까 경영이다]작은 전진의 힘: 행복은 크기보다 빈도 - 매일경제

기쁨 스위치는 왜 쉽게 꺼질까? 아무리 기쁜 일이 생겨도 그 기쁨은 잠깐이다. 수년간 몸과 영혼을 팔아 높은 자리에 오른들 그 기쁨은 순간이다. 신은 왜 인간에게 잠깐의 쾌락만 허락한 걸까? 오래 지속되는 쾌락을 부인한 신이 때로는 야속하다.

그러나 신이 그렇게 한 건 인간의 ‘생존’을 위해서다. 수렵시대 인간이 사냥에 성공했다고 하자. 창이나 화살에 맞은 먹잇감이 쓰러지는 순간, 온몸이 짜릿했을 것이다. 그 고기를 씹을 때 역시 기뻤을 것이다. 하지만 그 기쁨은 오래 계속되면 안 된다. 사라져야 한다. 그래야 다시 사냥에 나설 것이기 때문이다.

서은국 연세대 교수의 책 <행복의 기원>에 나오는 설명은 다음과 같다. “오늘 아무리 영양가 높은 음식을 먹어도, 살기 위해서는 내일 또 사냥을 해야 한다. 사냥에 대한 의욕이 다시 생기기 위한 필요조건이 있다.”

오늘 고기를 씹으며 느낀 쾌감이 곧 사라져야 하는 것이다. 쾌감 수준이 원점으로 돌아가는 이런 ‘초기화’ 과정이 있어야만 그 쾌감을 유발시킨 고기를 다시 찾는다. 창을 들고 동굴 밖으로 다시 사냥을 나서는 이유는 사실 잃어버린 쾌감을 다시 찾기 위함이다.

만약 고기를 씹을 때 느낀 쾌감이 마냥 지속된다면 인간은 계속 사냥을 미룰 것이다. 동굴 안에 앉아서 그 기쁨을 계속 만끽하려고 할 것이다. 먹을거리를 구하는 노력을 게을리하게 되고, 결국 생존을 위협받게 된다.

이제 우리는 신에게 감사해야 한다. 쾌락과 기쁨의 스위치가 쉽게 꺼지도록 설계한 덕분에 우리 인간은 생존할 수 있게 됐다. 그러나 세상에 공짜는 없는 법! 생존을 얻는 대신, 인간은 큰 대가를 치르게 됐다.

우리는 끝없이 기쁨에 배고픈 존재가 된 것이다. 예를 들어, 신혼 초에는 내 집만 마련하면 세상을 다 가질 것 같다. 그러나 작은 내 집을 갖고 나면, 그 기쁨은 며칠이다. 집 크기를 늘려야 더 행복해질 것 같다. 그래서 집을 늘린다.

하지만 이 역시 잠깐이다. 이제는 학군 좋고 교통 편한 곳으로 옮겨야 할 것 같다. 실제로 그렇게 옮긴다 해도 그 기쁨 역시 잠깐일 것이다. 인간은 생존을 얻는 대가로 끝없이 ‘쾌락의 챗바퀴’를 돌고 돌아야 하는 존재가 됐다.

이런 상황에서 행복해지기 위해 어떤 전략을 세우는 게 옳을까? 드물게 찾아오는 쾌락과 기쁨을 좇는 건 비효율적이다. 예를 들어, 몇 년에 한번 찾아오는 승진에 목을 맨다고 해보자. 이를 위해 다른 수많은 기쁨 거리를 포기하고 산다고 해보자.

비록 승진에 성공한다고 해도 몇 년씩 몸과 영혼을 상해가며 얻은 기쁨의 유효기간은 고작 며칠이다. 오히려 작더라도 자주 느낄 수 있는 기쁨을 찾는 게 현명한 전략이다. 그러면 우리는 삶에서 기쁨을 더 자주 느낄 것이다. 더 자주 행복해할 것이며, 삶에서 행복한 순간들이 차지하는 비중도 늘어날 것이다.

전문가들은 행복은 ‘강도(intensity)보다 빈도 (frequency)’가 중요하다고 한다. 큰 행복보다는 종종 찾아오는 작은 행복을 추구하는 게 현명한 전략이라는 뜻이다. 소소하지만 확실한 행복을 뜻하는 ‘소확행’이 유행하는 것도 이 때문일 것이다.

큰 행복을 주는 건 대체로 불확실하고 이루기 어렵다. 높은 자리에 오르거나 큰 돈을 버는 것이 그런 예다. 몇 년을 투자해도 아무 성과를 못 낼 수도 있다. 이런 것보다는 생활 속에서 작은 행복을 추구하면 기쁨을 더 자주 느낄 수 있다는 게 소확행 전략이다.

다만, 행복은 좇으면 좇을수록 멀어진다. ‘소확행’이라고 해도 행복이나 기쁨을 직접적인 목적으로 할 생각은 말아야 한다. 의미있는 삶을 살다 보면 부산물로 얻어지는 게 행복이다. 그렇기에 우리가 행복해지려면 ‘의미있는 일’을 하고 살아야 한다.

그러나 아무리 의미있는 일이라고 해도 좌절과 퇴보만 있으면 소용 없다. 테레사 아마빌 하버드대 교수가 3년 동안 238명의 전문직 직장인들로부터 1만 2000일 분량의 일기를 받아서 이들의 내면생활을 추적 조사했을 때였다.

가장 기분 나쁜 날에 어떤 일이 있었나 봤더니, 퇴보, 좌절이 67%로 가장 많았다. 프로젝트나 업무에 대한 지원부족, 방해가 42%, 무시나 모욕감 같은 독소가 18%로 그 다음이었다.

반면 가장 기분 좋은 날에는 ‘전진’이 있었다. 무려 76%의 비율로 압도적이었다. 업무에 대한 지원(촉매)이 43%, 격려나 위로, 존중 등 ‘영양소’가 25%로 그 뒤를 이었다.

결국 우리가 행복해 지려면 (1)그 일에 의미가 있어야 하며, (2)그 일에서 전진이 있어야 한다. 아마빌 교수는 의미있는 일에서 전진을 느끼면 기분이 좋아지고 자신을 둘러싼 환경을 긍정적으로 인식하게 되며 동기부여가 된다고 했다. 그는 이 효과를 전진의 원리(The Progress Principle)라고 불렀다.

하지만 우리가 의미있는 일에서 전진을 이룬다고 해도 쾌락의 챗바퀴는 어김없이 돌아간다. 지금 우리가 느낀 전진의 기쁨 또한 결코 오래 가지 않는다. 금세 사라진다. 우리 두뇌는 또다시 ‘기쁨을 느끼고 싶어. 기쁨을 찾으라’는 신호를 보낼 것이다.

그렇기에 전진의 원리에도 ‘행복은 강도보다는 빈도’라는 원칙이 적용된다. 크고 불확실한 전진보다는 작지만 종종 얻을 수 있는 작은 전진을 추구하는 게 현명한 행복 전략이다.

‘몇 달에 한 번 정도 가능한 큰 전진’을 기대하고 직장생활을 설계하기보다는, ‘빈도 높은 작은 전진’에 집중하는 게 옳다. 그래야 우리는 더 자주 전진을 경험할 것이고, 더 자주 기분이 좋아질 것이고, 더 자주 업무에 동기부여가 될 것이다.

아마빌 교수 역시 과거 인터뷰에서 작은 전진의 중요성을 강조했다. “전진은 꼭 크고 중요한 전진이어야 하는가?”라는 질문에 아마빌 교수는 이렇게 답했다.

“전혀 그럴 필요가 없다. 전진의 원리는 일상적이거나 점진적인 작은 전진에도 그대로 적용된다. 다시 말해 큰 승리가 아닌 ‘작은 승리(small wins)’만으로 충분하다. 이는 일기 분석을 통해 확인한 사실이다.”

이제부터라도 의미있는 일을 찾아서 작은 전진을 도모하자. 그리고 이를 지원하는 조직에서 일을 하자. 그게 행복으로 가는 최선의 전략이다.

기쁨 스위치는 왜 쉽게 꺼질까? 아무리 기쁜 일이 생겨도 그 기쁨은 잠깐이다. 수년간 몸과 영혼을 팔아 높은 자리에 오른들 그 기쁨은 순간이다. 신은 왜 인간에게 잠깐의 쾌락만 허락한 걸까? 오래 지속되는 쾌락을 부인한 신이 때로는 야속하다. 그러나 신이 그렇게 한 건 인간의 ‘생존’을 위해서다. 수렵시대 인간이 사냥에 성공했다고 하자. 창이나 화살에 맞은 먹잇감이 쓰러지는 순간, 온몸이 짜릿했을 것이다. 그 고기를 씹을 때 역시 기뻤을 것이다. 하지만 그 기쁨은 오래 계속되면 안 된다. 사라져야 한다. 그래야 다시 사냥에 나설 것이기 때문이다. 서은국 연세대 교수의 책 &lt;행복의 기원&gt;에 나오는 설명은 다음과 같다. “오늘 아무리 영양가 높은 음식을 먹어도, 살기 위해서는 내일 또 사냥을 해야 한다. 사냥에 대한 의욕이 다시 생기기 위한 필요조건이 있다.” 오늘 고기를 씹으며 느낀 쾌감이 곧 사라져야 하는 것이다. 쾌감 수준이 원점으로 돌아가는 이런 ‘초기화’ 과정이 있어야만 그 쾌감을 유발시킨 고기를 다시 찾는다. 창을 들고 동굴 밖으로 다시 사냥을 나서는 이유는 사실 잃어버린 쾌감을 다시 찾기 위함이다. 만약 고기를 씹을 때 느낀 쾌감이 마냥 지속된다면 인간은 계속 사냥을 미룰 것이다. 동굴 안에 앉아서 그 기쁨을 계속 만끽하려고 할 것이다. 먹을거리를 구하는 노력을 게을리하게 되고, 결국 생존을 위협받게 된다. 이제 우리는 신에게 감사해야 한다. 쾌락과 기쁨의 스위치가 쉽게 꺼지도록 설계한 덕분에 우리 인간은 생존할 수 있게 됐다. 그러나 세상에 공짜는 없는 법! 생존을 얻는 대신, 인간은 큰 대가를 치르게 됐다. 우리는 끝없이 기쁨에 배고픈 존재가 된 것이다. 예를 들어, 신혼 초에는 내 집만 마련하면 세상을 다 가질 것 같다. 그러나 작은 내 집을 갖고 나면, 그 기쁨은 며칠이다. 집 크기를 늘려야 더 행복해질 것 같다. 그래서 집을 늘린다. 하지만 이 역시 잠깐이다. 이제는 학군 좋고 교통 편한 곳으로 옮겨야 할 것 같다. 실제로 그렇게 옮긴다 해도 그 기쁨 역시 잠깐일 것이다. 인간은 생존을 얻는 대가로 끝없이 ‘쾌락의 챗바퀴’를 돌고 돌아야 하는 존재가 됐다. 이런 상황에서 행복해지기 위해 어떤 전략을 세우는 게 옳을까? 드물게 찾아오는 쾌락과 기쁨을 좇는 건 비효율적이다. 예를 들어, 몇 년에 한번 찾아오는 승진에 목을 맨다고 해보자. 이를 위해 다른 수많은 기쁨 거리를 포기하고 산다고 해보자. 비록 승진에 성공한다고 해도 몇 년씩 몸과 영혼을 상해가며 얻은 기쁨의 유효기간은 고작 며칠이다. 오히려 작더라도 자주 느낄 수 있는 기쁨을 찾는 게 현명한 전략이다. 그러면 우리는 삶에서 기쁨을 더 자주 느낄 것이다. 더 자주 행복해할 것이며, 삶에서 행복한 순간들이 차지하는 비중도 늘어날 것이다. 전문가들은 행복은 ‘강도(intensity)보다 빈도 (frequency)’가 중요하다고 한다. 큰 행복보다는 종종 찾아오는 작은 행복을 추구하는 게 현명한 전략이라는 뜻이다. 소소하지만 확실한 행복을 뜻하는 ‘소확행’이 유행하는 것도 이 때문일 것이다. 큰 행복을 주는 건 대체로 불확실하고 이루기 어렵다. 높은 자리에 오르거나 큰 돈을 버는 것이 그런 예다. 몇 년을 투자해도 아무 성과를 못 낼 수도 있다. 이런 것보다는 생활 속에서 작은 행복을 추구하면 기쁨을 더 자주 느낄 수 있다는 게 소확행 전략이다. 다만, 행복은 좇으면 좇을수록 멀어진다. ‘소확행’이라고 해도 행복이나 기쁨을 직접적인 목적으로 할 생각은 말아야 한다. 의미있는 삶을 살다 보면 부산물로 얻어지는 게 행복이다. 그렇기에 우리가 행복해지려면 ‘의미있는 일’을 하고 살아야 한다. 그러나 아무리 의미있는 일이라고 해도 좌절과 퇴보만 있으면 소용 없다. 테레사 아마빌 하버드대 교수가 3년 동안 238명의 전문직 직장인들로부터 1만 2000일 분량의 일기를 받아서 이들의 내면생활을 추적 조사했을 때였다. 가장 기분 나쁜 날에 어떤 일이 있었나 봤더니, 퇴보, 좌절이 67%로 가장 많았다. 프로젝트나 업무에 대한 지원부족, 방해가 42%, 무시나 모욕감 같은 독소가 18%로 그 다음이었다. 반면 가장 기분 좋은 날에는 ‘전진’이 있었다. 무려 76%의 비율로 압도적이었다. 업무에 대한 지원(촉매)이 43%, 격려나 위로, 존중 등 ‘영양소’가 25%로 그 뒤를 이었다. 결국 우리가 행복해 지려면 (1)그 일에 의미가 있어야 하며, (2)그 일에서 전진이 있어야 한다. 아마빌 교수는 의미있는 일에서 전진을 느끼면 기분이 좋아지고 자신을 둘러싼 환경을 긍정적으로 인식하게 되며 동기부여가 된다고 했다. 그는 이 효과를 전진의 원리(The Progress Principle)라고 불렀다. 하지만 우리가 의미있는 일에서 전진을 이룬다고 해도 쾌락의 챗바퀴는 어김없이 돌아간다. 지금 우리가 느낀 전진의 기쁨 또한 결코 오래 가지 않는다. 금세 사라진다. 우리 두뇌는 또다시 ‘기쁨을 느끼고 싶어. 기쁨을 찾으라’는 신호를 보낼 것이다. 그렇기에 전진의 원리에도 ‘행복은 강도보다는 빈도’라는 원칙이 적용된다. 크고 불확실한 전진보다는 작지만 종종 얻을 수 있는 작은 전진을 추구하는 게 현명한 행복 전략이다. ‘몇 달에 한 번 정도 가능한 큰 전진’을 기대하고 직장생활을 설계하기보다는, ‘빈도 높은 작은 전진’에 집중하는 게 옳다. 그래야 우리는 더 자주 전진을 경험할 것이고, 더 자주 기분이 좋아질 것이고, 더 자주 업무에 동기부여가 될 것이다. 아마빌 교수 역시 과거 인터뷰에서 작은 전진의 중요성을 강조했다. “전진은 꼭 크고 중요한 전진이어야 하는가?”라는 질문에 아마빌 교수는 이렇게 답했다. “전혀 그럴 필요가 없다. 전진의 원리는 일상적이거나 점진적인 작은 전진에도 그대로 적용된다. 다시 말해 큰 승리가 아닌 ‘작은 승리(small wins)’만으로 충분하다. 이는 일기 분석을 통해 확인한 사실이다.” 이제부터라도 의미있는 일을 찾아서 작은 전진을 도모하자. 그리고 이를 지원하는 조직에서 일을 하자. 그게 행복으로 가는 최선의 전략이다.

매일경제

A collection of all my interviews about my 'How to Get Rich' tweetstorm. Seek Wealth, Not Money or Status Wealth is assets that earn while you sleep You probably know Naval from his Twitter account. We're going to talk about his tweetstorm, "How To Get Ri

How to Get Rich

AngelList의 공동 창립자이자 회장인 나발 라비칸트의 글을 소개합니다.

Naval Ravikant-Making money isn't about luck
https://nav.al/rich

1. 행운이 아닌 능력: 부자가 되는 것은 행운이 아니라, 부를 창출할 수 있는 사람이 되는 것에 관한 것이다.

2. 재능 개발의 중요성: 모든 돈을 잃어버렸다 하더라도, 영어를 사용하는 어느 나라에서든 5~10년 안에 다시 부자가 될 수 있는 재능을 개발할 수 있다.

3. 다양한 행운의 유형:
- 눈먼 행운: 완전히 제어할 수 없는 상황에서 운이 좋은 경우
- 노력에서 오는 행운: 꾸준한 노력과 활동을 통해 자연스럽게 찾아오는 행운
- 준비에서 오는 행운: 특정 분야에서 기회를 빠르게 포착할 수 있는 능력
- 독특한 성격에서 오는 행운: 유니크한 캐릭터나 브랜드를 통해 행운을 끌어당기는 경우

4. 자기만의 행운 만들기: 예를 들어, 세계 최고의 심해 잠수사라면, 우연히 발견된 보물을 bergen할 기회가 올 때 그 기회를 살릴 수 있다.

5. 행운을 배제하는 삶: 1000개의 평행 우주에서 999개에서 부자가 되고 싶다는 생각으로, 우연에 의존하지 않고 확실한 방법을 추구한다.

6. 지속적인 부의 창출: 부는 단번에 큰 돈으로 만든 것이 아니라, 여러 기회와 투자를 통해 조금씩 쌓아올린 것이다.

7. 자유를 향한 부: 진정한 자유를 위해 부를 쌓는 것이 목표이며, 이는 위치에 구애받지 않고 원하는 대로 살 수 있는 것을 의미한다.

8. 인터넷의 기회: 현대에는 인터넷을 통해 무수히 많은 기회가 주어지고, 이를 통해 다양한 방법으로 돈을 벌 수 있다.

9. 경험과 학습: 지속적인 학습과 경험의 축적이 부를 창출하는 데 필수적이며, 이는 오랜 시간에 걸쳐 가치가 축적된다.

10. 시간의 가치: 가능한 많은 기회를 잡으려고 하지만, 가장 부족한 자원은 '시간'이다.

AngelList의 공동 창립자이자 회장인 나발 라비칸트의 글을 소개합니다. Naval Ravikant-Making money isn't about luck https://nav.al/rich 1. 행운이 아닌 능력: 부자가 되는 것은 행운이 아니라, 부를 창출할 수 있는 사람이 되는 것에 관한 것이다. 2. 재능 개발의 중요성: 모든 돈을 잃어버렸다 하더라도, 영어를 사용하는 어느 나라에서든 5~10년 안에 다시 부자가 될 수 있는 재능을 개발할 수 있다. 3. 다양한 행운의 유형: - 눈먼 행운: 완전히 제어할 수 없는 상황에서 운이 좋은 경우 - 노력에서 오는 행운: 꾸준한 노력과 활동을 통해 자연스럽게 찾아오는 행운 - 준비에서 오는 행운: 특정 분야에서 기회를 빠르게 포착할 수 있는 능력 - 독특한 성격에서 오는 행운: 유니크한 캐릭터나 브랜드를 통해 행운을 끌어당기는 경우 4. 자기만의 행운 만들기: 예를 들어, 세계 최고의 심해 잠수사라면, 우연히 발견된 보물을 bergen할 기회가 올 때 그 기회를 살릴 수 있다. 5. 행운을 배제하는 삶: 1000개의 평행 우주에서 999개에서 부자가 되고 싶다는 생각으로, 우연에 의존하지 않고 확실한 방법을 추구한다. 6. 지속적인 부의 창출: 부는 단번에 큰 돈으로 만든 것이 아니라, 여러 기회와 투자를 통해 조금씩 쌓아올린 것이다. 7. 자유를 향한 부: 진정한 자유를 위해 부를 쌓는 것이 목표이며, 이는 위치에 구애받지 않고 원하는 대로 살 수 있는 것을 의미한다. 8. 인터넷의 기회: 현대에는 인터넷을 통해 무수히 많은 기회가 주어지고, 이를 통해 다양한 방법으로 돈을 벌 수 있다. 9. 경험과 학습: 지속적인 학습과 경험의 축적이 부를 창출하는 데 필수적이며, 이는 오랜 시간에 걸쳐 가치가 축적된다. 10. 시간의 가치: 가능한 많은 기회를 잡으려고 하지만, 가장 부족한 자원은 '시간'이다.

Naval

운에 기대지 않고 돈을 버는 법 - 나발 라비칸트

삼성전자가 2년 전 플래그십 모델인 갤럭시 S22에도 갤럭시 AI 기능을 탑재합니다. 삼성은 1억 대가 넘는 갤럭시에 AI 기능을 탑재해 AI를 대중화시키겠다는 포부를 밝혔었습니다. 지난 3월 갤럭시 S23, 갤럭시 Z폴드, 플립5 시리즈에 이어 구형 모델 지원을 확대하고 있습니다. 이 정도 추세라면 1억 대에 AI 기능이 담길 수 있을 것 같네요.

갤럭시 AI: 2년 전 모델도 AI를 쓸 수 있다

삼성전자가 2년 전 플래그십 모델인 갤럭시 S22에도 갤럭시 AI 기능을 탑재합니다. 삼성은 1억 대가 넘는 갤럭시에 AI 기능을 탑재해 AI를 대중화시키겠다는 포부를 밝혔었습니다. 지난 3월 갤럭시 S23, 갤럭시 Z폴드, 플립5 시리즈에 이어 구형 모델 지원을 확대하고 있습니다. 이 정도 추세라면 1억 대에 AI 기능이 담길 수 있을 것 같네요.

더 자세한 내용은 링크에서 확인하세요.
https://designcompass.org/2024/04/15/galaxy-ai-update-s22/

#ai #갤럭시 #삼성

삼성전자가 2년 전 플래그십 모델인 갤럭시 S22에도 갤럭시 AI 기능을 탑재합니다. 삼성은 1억 대가 넘는 갤럭시에 AI 기능을 탑재해 AI를 대중화시키겠다는 포부를 밝혔었습니다. 지난 3월 갤럭시 S23, 갤럭시 Z폴드, 플립5 시리즈에 이어 구형 모델 지원을 확대하고 있습니다. 이 정도 추세라면 1억 대에 AI 기능이 담길 수 있을 것 같네요. 더 자세한 내용은 링크에서 확인하세요.https://designcompass.org/2024/04/15/galaxy-ai-update-s22/ #ai #갤럭시 #삼성

디자인 나침반

갤럭시 AI: 2년 전 모델도 AI를 쓸 수 있다.

어느 1인 기업가의 조직도 (feat. AI .. : 네이버블로그

여러 AI 제품들을 이용해서 실제 사업에 어떤 도움을 받고 있는지가 잘 정리된 글입니다. (히크로도스라는 1인기업 대표 최재완님의 글) 교육 콘텐츠 기획, IT/개발, 디자인, 세무회계 등 각 분야별로 SaaS 툴들을 잘 조합해서 꽤 높은 생산성을 낼 수 있다고 소개하신 내용이 구체적이고, 참고가 되네요. 노코드 툴을 이용한 서비스 개발이나, 제품 기획 과정에서 AI 제품을 활용하는 데 관심있는 분들이라면 한번쯤 읽어보시면 좋을 것 같아요.

여러 AI 제품들을 이용해서 실제 사업에 어떤 도움을 받고 있는지가 잘 정리된 글입니다. (히크로도스라는 1인기업 대표 최재완님의 글) 교육 콘텐츠 기획, IT/개발, 디자인, 세무회계 등 각 분야별로 SaaS 툴들을 잘 조합해서 꽤 높은 생산성을 낼 수 있다고 소개하신 내용이 구체적이고, 참고가 되네요. 노코드 툴을 이용한 서비스 개발이나, 제품 기획 과정에서 AI 제품을 활용하는 데 관심있는 분들이라면 한번쯤 읽어보시면 좋을 것 같아요.

네이버 블로그 | 가장 보통의 스타트업 CEO

[어느 1인 기업가의 조직도]

우선 한 번 경험하게 하는 것의 강력함 | 만약 우리 서비스가 초기라면 토스나 당근 같이 이미 크게 성장한 레퍼런스가 잘 맞지 않는 경우가 많습니다. 서비스 단계나 카테고리별 전략이 다르기 때문입니다. 그리고 급변하는 시장의 영향력은 시기에 따라 급변하는 변수입니다. 1년 전에 통했던 전략이 오늘은 통하지 않습니다. 좋은 레퍼런스를 보면 머릿속에서 이내 하나의 단단한 가설로 굳습니다.

13화 성공한 서비스의 시작점에는 가치 사다리가 있다?

무료에서 유료로, 단순 구매에서 장기적 관계로! 성공한 서비스의 시작점에는 가치 사다리가 있다?

👉제가 눈여겨 본 실제 사례를 통해 미끼 상품의 활용부터 장기적 고객 관계 구축의 가능성을 살펴 보았습니다.

본문 요약
 * 무료라도 경쟁력을 갖춰야 시간 가치를 이길 수 있다.
 * 본질이 약하면 다음 사다리로 연결되지 않는다.
 * 미끼 상품부터 문제 해결의 모습이나 바이럴 요소가 있어야 한다.
https://brunch.co.kr/@cliche-cliche/219

무료에서 유료로, 단순 구매에서 장기적 관계로! 성공한 서비스의 시작점에는 가치 사다리가 있다? 👉제가 눈여겨 본 실제 사례를 통해 미끼 상품의 활용부터 장기적 고객 관계 구축의 가능성을 살펴 보았습니다. 본문 요약<ul><li>무료라도 경쟁력을 갖춰야 시간 가치를 이길 수 있다.</li><li>본질이 약하면 다음 사다리로 연결되지 않는다.</li><li>미끼 상품부터 문제 해결의 모습이나 바이럴 요소가 있어야 한다.</li></ul>https://brunch.co.kr/@cliche-cliche/219

🪜성공한 서비스 뒤에는 가치 사다리가 있다?

"바쁘니까 디자인은 나중에 챙기자" 많이들 들어봤을 겁니다. 하지만 보통 그 나중은 오지 않습니다. 고객을 위해 더 나은 경험을 포기할 순 없죠. 이럴 때 필요한 것인 디자인 시스템입니다. 대표적인 디자인 기술로 한정된 시간과 자원으로 더 나은 가치를 만듭니다. 시스템은 목적을 달성하기 위한 일정한 규칙입니다. 어떤 인풋을 넣어도 예측할 수 있는 아웃풋이...

왜 디자인 시스템을 만들까?

원문: https://designcompass.org/2024/04/14/why-design-system/

“바쁘니까 디자인은 나중에 챙기자“ 많이들 들어봤을 겁니다. 하지만 보통 그 나중은 오지 않습니다. 고객을 위해 더 나은 경험을 포기할 순 없죠. 이럴 때 필요한 것인 디자인 시스템입니다. 대표적인 디자인 기술로 한정된 시간과 자원으로 더 나은 가치를 만듭니다.
시스템은 목적을 달성하기 위한 일정한 규칙입니다. 어떤 인풋을 넣어도 예측할 수 있는 아웃풋이 나올 수 있게 만듭니다. 그렇다면 디자인 시스템을 만들면 어떤 효과를 얻을 수 있을까요?

1. 방향을 잡는 일관된 원칙
디자인이 효과를 내려면 올바른 방향으로 나아가야 합니다. 같은 것을 만들더라도 추구하는 방향성에 따라 고객 경험이 크게 달라집니다. 고객에게 최고라 생각하는 것 단 한 개를 제시할 수도 있고 고객이 직접 자신이 원하는 경험을 선택하게 만들 수도 있습니다.

디자이너가 문제 해결이나 메시지 표현에만 집중하다 보면 길을 잃어버리는 경우가 많습니다. 이 때 시스템은 우리가 미아가 되는 것을 막아줍니다. 고객이 쉽고 편하게 기대하는 것을 얻을 수 있게 ’간결함‘을 추구한다면 최소한의 시각 기법을 사용합니다. 고객의 기억 속에 각인 되기 위한 ’고유함‘을 추구한다면 남들이 시도하지 않는 새로운 도전을 합니다.

시스템은 이러한 가치를 명문화하고 의사결정을 위한 중요한 판단 기준이 됩니다. 앞으로 일어날 모든 경우의 수를 위한 규칙보다는 스스로 질문하는 원칙이 됩니다. 버튼의 동작법이나 사진 톤 & 매너와 같은 구체적인 가이드는 추상적인 디자인 원칙의 구체적인 사례가 되어줍니다. 그렇게 회사나 서비스가 제공하는 결과물이 일관된 원칙에 기반해 고객에게 전달될 수 있습니다.

2. 균일한 품질을 위한 기준
고객의 선택 받을 수 있을만큼 좋은 것을 만들어야 합니다. 우리는 하루에도 수십, 수백 개의 디자인을 만듭니다. 고객은 이 중에서 한 두 개 정도의 디자인을 볼까 말까입니다. 고작 1~2초 정도의 짧은 시간에 고객이 훑어본 결과물의 품질이 곧 내 브랜드의 전체 품질이 됩니다. 그렇기 때문에 고객이 브랜드를 경험하는 모든 순간을 최대한 높은 품질을 유지해야 하죠.

하지만 모든 것을 언제나 잘 만들기는 어렵습니다. 항상 시간이 없고 투자 가치를 예측하기 어렵습니다. 혼자서도 어려운데 여럿이 함께 만들 때는 좋은 품질을 지키기가 더욱 어려워집니다. 작업자에 따라 문제를 해결하는 방식과 품질이 달라지죠. 매번 모니터링하고 소통하기 어렵다 보니 쉽게 포기하게 되죠.

시스템은 효과가 검증된 방법을 전체에 전파합니다. 원칙에 기반한 좋은 사례를 정의하고 동료를 설득해 미래에 비슷한 문제가 생겼을 때 같은 방식으로 해결하게 합니다. 디자인 결과물의 효과에 관한 불확실성을 줄이고 새로운 영역에 도전할 수 있는 여력을 만들어주죠. 그렇게 조직 전체 품질의 평균을 높이고 하한선을 끌어올립니다.

3. 빠른 제작을 위한 재료
방향이 맞고 품질이 좋으면 이제 빨리 만들어야 합니다. 아무리 좋은 것이라도 고객에게 전달되지 않으면 의미가 없습니다. 전달하기 전에 좋은지 나쁜지 모르는 경우도 많죠. 심지어 경쟁사는 호시탐탐 우리보다 더 잘하기 위해 노력하고 있습니다. 언제 어디서 우리가 역전당할지 알 수 없습니다.

고객에게 빨리 전달하기 위해서는 결과물을 생산하는 속도가 빨라져야 합니다. 같은 시간에 만들어내는 결과물의 개수가 늘어나야 하죠. 사람을 갈아서 속도가 엄청나게 빨라질 수 있지만 오래갈 수 없죠. 그렇다면 만들어야 하는 결과물의 숫자를 줄여야 합니다.

시스템은 디자이너가 만들 결과물의 수를 줄입니다. 과거의 반복을 바탕으로 미래의 반복을 예측합니다. 미래에도 계속 쓸 디자인을 작은 단위로 쪼개 시스템에 등록합니다. 디자이너는 효과를 예측할 수 있는 여러 요소를 결합해 패턴을 만듭니다. 매번 새로운 요소를 만들 필요가 없어져 제작 속도가 빨라집니다.

#디자인시스템 #디자인 #디자인나침반 #인사이트

원문: https://designcompass.org/2024/04/14/why-design-system/ “바쁘니까 디자인은 나중에 챙기자“ 많이들 들어봤을 겁니다. 하지만 보통 그 나중은 오지 않습니다. 고객을 위해 더 나은 경험을 포기할 순 없죠. 이럴 때 필요한 것인 디자인 시스템입니다. 대표적인 디자인 기술로 한정된 시간과 자원으로 더 나은 가치를 만듭니다.시스템은 목적을 달성하기 위한 일정한 규칙입니다. 어떤 인풋을 넣어도 예측할 수 있는 아웃풋이 나올 수 있게 만듭니다. 그렇다면 디자인 시스템을 만들면 어떤 효과를 얻을 수 있을까요? 1. 방향을 잡는 일관된 원칙디자인이 효과를 내려면 올바른 방향으로 나아가야 합니다. 같은 것을 만들더라도 추구하는 방향성에 따라 고객 경험이 크게 달라집니다. 고객에게 최고라 생각하는 것 단 한 개를 제시할 수도 있고 고객이 직접 자신이 원하는 경험을 선택하게 만들 수도 있습니다. 디자이너가 문제 해결이나 메시지 표현에만 집중하다 보면 길을 잃어버리는 경우가 많습니다. 이 때 시스템은 우리가 미아가 되는 것을 막아줍니다. 고객이 쉽고 편하게 기대하는 것을 얻을 수 있게 ’간결함‘을 추구한다면 최소한의 시각 기법을 사용합니다. 고객의 기억 속에 각인 되기 위한 ’고유함‘을 추구한다면 남들이 시도하지 않는 새로운 도전을 합니다. 시스템은 이러한 가치를 명문화하고 의사결정을 위한 중요한 판단 기준이 됩니다. 앞으로 일어날 모든 경우의 수를 위한 규칙보다는 스스로 질문하는 원칙이 됩니다. 버튼의 동작법이나 사진 톤 &amp; 매너와 같은 구체적인 가이드는 추상적인 디자인 원칙의 구체적인 사례가 되어줍니다. 그렇게 회사나 서비스가 제공하는 결과물이 일관된 원칙에 기반해 고객에게 전달될 수 있습니다. 2. 균일한 품질을 위한 기준고객의 선택 받을 수 있을만큼 좋은 것을 만들어야 합니다. 우리는 하루에도 수십, 수백 개의 디자인을 만듭니다. 고객은 이 중에서 한 두 개 정도의 디자인을 볼까 말까입니다. 고작 1~2초 정도의 짧은 시간에 고객이 훑어본 결과물의 품질이 곧 내 브랜드의 전체 품질이 됩니다. 그렇기 때문에 고객이 브랜드를 경험하는 모든 순간을 최대한 높은 품질을 유지해야 하죠. 하지만 모든 것을 언제나 잘 만들기는 어렵습니다. 항상 시간이 없고 투자 가치를 예측하기 어렵습니다. 혼자서도 어려운데 여럿이 함께 만들 때는 좋은 품질을 지키기가 더욱 어려워집니다. 작업자에 따라 문제를 해결하는 방식과 품질이 달라지죠. 매번 모니터링하고 소통하기 어렵다 보니 쉽게 포기하게 되죠. 시스템은 효과가 검증된 방법을 전체에 전파합니다. 원칙에 기반한 좋은 사례를 정의하고 동료를 설득해 미래에 비슷한 문제가 생겼을 때 같은 방식으로 해결하게 합니다. 디자인 결과물의 효과에 관한 불확실성을 줄이고 새로운 영역에 도전할 수 있는 여력을 만들어주죠. 그렇게 조직 전체 품질의 평균을 높이고 하한선을 끌어올립니다. 3. 빠른 제작을 위한 재료방향이 맞고 품질이 좋으면 이제 빨리 만들어야 합니다. 아무리 좋은 것이라도 고객에게 전달되지 않으면 의미가 없습니다. 전달하기 전에 좋은지 나쁜지 모르는 경우도 많죠. 심지어 경쟁사는 호시탐탐 우리보다 더 잘하기 위해 노력하고 있습니다. 언제 어디서 우리가 역전당할지 알 수 없습니다. 고객에게 빨리 전달하기 위해서는 결과물을 생산하는 속도가 빨라져야 합니다. 같은 시간에 만들어내는 결과물의 개수가 늘어나야 하죠. 사람을 갈아서 속도가 엄청나게 빨라질 수 있지만 오래갈 수 없죠. 그렇다면 만들어야 하는 결과물의 숫자를 줄여야 합니다. 시스템은 디자이너가 만들 결과물의 수를 줄입니다. 과거의 반복을 바탕으로 미래의 반복을 예측합니다. 미래에도 계속 쓸 디자인을 작은 단위로 쪼개 시스템에 등록합니다. 디자이너는 효과를 예측할 수 있는 여러 요소를 결합해 패턴을 만듭니다. 매번 새로운 요소를 만들 필요가 없어져 제작 속도가 빨라집니다. #디자인시스템 #디자인 #디자인나침반 #인사이트

📝 왜 디자인 시스템을 만들까?

오늘 해볼 이야기는 2024년 프론트엔드 기술 스택입니다. 프론트엔드는 지난 10여 년간 빠르게 기술이 발전하면서, 해마다 '올해의 기술 전망'을 바탕으로 한 '20XX 프론트엔드 기술스택' 과 같은 아티클이 매해 연도가 바뀔때 마다 자주 나왔습니다. 그래서 저도

2024 프론트엔드 기술스택 이야기

오랜만에 글을 작성하게 되네요. 이번 글은 2024 프론트엔드 기술 스택에 대한 이야기입니다.

지난 10여년간 급변하던 시절과는 달리 현재의 프론트엔드의 생태계는 거의 안정화가 되었습니다.
그래서 어떤 기술이 새로 나왔고 어떤 기술을 써야 하는지 이런 얘기들보다는 어떻게 이러한 급변화와 안정기가 생겨가는지 기술스택에 대해서 어떻게 생각해야 하는지 여러가지 재미난 이야기들과 제 생각을 적어 보았습니다.

물론 현재의 프론트엔드 트렌드와 보편화된 기술 스택에 대한 이야기들도 함께 적어보았습니다.
기술 스택과 트렌드에 대해서 궁금하시다면 한번 읽어봐주세요.

감사합니다. :)

https://velog.io/@teo/2024-frontend-techstack

오랜만에 글을 작성하게 되네요. 이번 글은 2024 프론트엔드 기술 스택에 대한 이야기입니다. 지난 10여년간 급변하던 시절과는 달리 현재의 프론트엔드의 생태계는 거의 안정화가 되었습니다.그래서 어떤 기술이 새로 나왔고 어떤 기술을 써야 하는지 이런 얘기들보다는 어떻게 이러한 급변화와 안정기가 생겨가는지 기술스택에 대해서 어떻게 생각해야 하는지 여러가지 재미난 이야기들과 제 생각을 적어 보았습니다. 물론 현재의 프론트엔드 트렌드와 보편화된 기술 스택에 대한 이야기들도 함께 적어보았습니다.기술 스택과 트렌드에 대해서 궁금하시다면 한번 읽어봐주세요. 감사합니다. :) https://velog.io/@teo/2024-frontend-techstack

Velog

Netflix는 Java, RxJava 및 Spring Boot를 활용해 마이크로서비스 아키텍처를 발전시켰으며, GraphQL Federation으로의 전환을 통해 더욱 발전했다. 이 글에서는 Netflix의 아키텍처 변화와 Java 사용 변천사를 설명한다.

Netflix의 Java 사용 변천사 (번역)

안녕하세요 :) 저는 최근에 다시 Java와 Spring Boot를 사용하는 미국 회사로 이직하면서, 지난 2년간 스타트업에서 Ruby on Rails를 사용하며 잊고 지내던 Java와 Spring 생태계에 다시 발을 내딛었습니다. 🥰

현재 회사에서는 수많은 모놀리틱 서비스와 마이크로서비스가 함께 사용되는 상황이라 꽤 복잡한 아키텍처로 구성되어 있습니다. 그리고 새로운 Java/Spring 기반 서비스들이 빠르게 추가되고 있어서 각 서비스들 간의 통신이나 아키텍처 구성을 어떻게 개선해가면 좋을지 고민되는 상황이었는데요. 🙃

팀에 빅테크(FAANG) 출신 시니어 개발자들도 있어서 제가 이 개선을 주도하지는 않겠지만,
적어도 아키텍처 개선 방향에 대한 내 의견을 가지고 있어야겠다
는 생각으로 힌트를 얻고자 Java 기반 서비스들의 큰 형님격인 Netflix의 문을 두드렸습니다.

Netflix는 Java 기반 서비스들의 아키텍처를 어떻게 발전시켜나갔는지 궁금해서 찾아보다가 이 글을 발견했고, 오랜만에 Java 생태계로 돌아온 저에게 유익했던 글이라 DeepL의 도움을 받아 번역해보았습니다.

전체 내용 보기 👉 https://www.integer.blog/evolution-of-java-usage-at-netflix/?ref=careerly.co.kr

📌 목차
 1. Groovy 시대 with BFF(Backend For Frontend)
 2. RxJava와 리액티브 프로그래밍 사용
 3. GraphQL Federation으로 전환
 4. Netflix가 사용하는 Java 버전
 5. Netflix가 사용하는 Spring Boot

안녕하세요 :) 저는 최근에 다시 Java와 Spring Boot를 사용하는 미국 회사로 이직하면서, 지난 2년간 스타트업에서 Ruby on Rails를 사용하며 잊고 지내던 Java와 Spring 생태계에 다시 발을 내딛었습니다. 🥰 현재 회사에서는 수많은 모놀리틱 서비스와 마이크로서비스가 함께 사용되는 상황이라 꽤 복잡한 아키텍처로 구성되어 있습니다. 그리고 새로운 Java/Spring 기반 서비스들이 빠르게 추가되고 있어서 각 서비스들 간의 통신이나 아키텍처 구성을 어떻게 개선해가면 좋을지 고민되는 상황이었는데요. 🙃 팀에 빅테크(FAANG) 출신 시니어 개발자들도 있어서 제가 이 개선을 주도하지는 않겠지만, <code >적어도 아키텍처 개선 방향에 대한 내 의견을 가지고 있어야겠다</code>는 생각으로 힌트를 얻고자 Java 기반 서비스들의 큰 형님격인 Netflix의 문을 두드렸습니다. Netflix는 Java 기반 서비스들의 아키텍처를 어떻게 발전시켜나갔는지 궁금해서 찾아보다가 이 글을 발견했고, 오랜만에 Java 생태계로 돌아온 저에게 유익했던 글이라 DeepL의 도움을 받아 번역해보았습니다. 전체 내용 보기 👉 https://www.integer.blog/evolution-of-java-usage-at-netflix/?ref=careerly.co.kr 📌 목차<ol ><li>Groovy 시대 with BFF(Backend For Frontend)</li><li>RxJava와 리액티브 프로그래밍 사용</li><li>GraphQL Federation으로 전환</li><li>Netflix가 사용하는 Java 버전</li><li>Netflix가 사용하는 Spring Boot</li></ol>

1nteger 🏄🏻‍♂️

Mobile development is a dynamic field that evolves rapidly, demanding developers to be proactive in keeping up with the latest trends, tools, and technologies. As the app landscape continuously...

How to Stay Up-to-Date as a Mobile Developer

개발자가 간단하게 실천할 수 있는 최신 정보 습득 방법에 대해 가져와 봤습니다! 이미 실천하고 계신 분들도 많으실 것 같네요ㅎㅎ 빠르게 변하는 산업인 만큼 지속적으로 새로운 정보를 받아들이는 것은 중요할 것 같습니다.

 1.  개발자 블로그 및 뉴스레터 구독하기
     iOS, aOS 공식 블로그뿐만 아니라 업계 전문가가 운영하는 블로그나 뉴스레터를 정기적으로 받아보는 것은 꾸준히 정보의 흐름을 읽을 수 있는 가장 좋은 방법입니다.
     
     
 2.  소셜 미디어 및 온라인 커뮤니티에 참여하기
     트위터, 레딧, 스택오브플로우와 같은 개발자 커뮤니티에 가입하는 것은 개발자들과 함께 소통하면서 성장할 수 있는 좋은 방법입니다. (커리어리도 마찬가지입니다!) 관련 해시태그를 팔로우하고, 스레드에 참여해서 좋은 정보를 실시간으로 얻어보세요! (개인적으로 일론머스크의 트윗이 재밌더군요...)
     
     
 3.  컨퍼런스 및 모임 참석
     온라인 및 오프라인 컨퍼런스에 주기적으로 참여하면 동료 개발자들과 네트워크를 형성하고, 최신 업계 동향을 접할 수 있습니다. wwdc, google i/o뿐만 아니라 국내 기업에서 주최하는 세션이나 컨퍼런스에 참여해 보세요!
     
     
 4.  온라인 강좌를 통한 지속적 학습
     코세라와 같은 유명 플랫폼에서 제공하는 온라인 강좌를 통해 지속적으로 지식을 심화해 나가는 것도 좋은 방법입니다. 최신 도구나 프레임워크를 학습하는 것은 나에게 큰 도움이 될 것입니다!
     
     
 5.  출퇴근 시간에 팟캐스트 듣기
     통근 시간을 이용해 팟캐스트의 힘을 활용해 보세요! Fragmented, Swift by Sundell 및 Android Developers Backstage와 같은 팟캐스트에서는 최신 모바일 개발 사례나 인터뷰 및 토론을 제공합니다! 영어 공부도 덤이고요! 이 외에 주요 CEO들이 출연하여 기술에 대해 이야기하는 ACQUIRED를 추천드립니다! 최근에는 앤비디아의 젠슨 황이 출연하기도 했죠.
     
     
 6.  GitHub 리포지토리 및 오픈 소스 프로젝트를 팔로우하기
     GitHub만큼이나 개발자가 코드를 파보기가 좋은 데가 없죠. 도메인와 관련된 프레임워크 라이브러리 오픈소스 프로젝트의 저장소를 꾸준히 기여하고, 참여하면 코딩 기술을 업그레이드할 뿐만 아니라 새로운 코딩 표준 및 공동 개발 방식을 접할 수 있습니다.
     
     
 7.  베타 릴리즈 사용해 보기
     얼리어답터가 되어 운영체제, SDK 및 개발도구의 베타 릴리즈를 실험하면 누구보다 빠른 기술을 습득할 수 있습니다. 이러한 경험을 통해 앱을 조정하고, 개발 커뮤니티에 좋은 의견들을 나눠볼 수 있죠.
     
     
 8.  업계 보고서 읽기
     보고서를 통해 업계 최신 동향을 광범위하게 얻을 수 있습니다. 또한 시장 행동과 타깃 유저 행동에 대한 통팔력을 통해 더 큰 그림을 이해하고, 프로젝트 방향에 대한 정보를 입각한 결정을 내릴 수 있습니다. 해외 쪽 뿐만 아니라 국내 주요 기업도 리포트를 발간하고 있으니, 참고하면 좋을 것 같습니다.
     
     
 9.  개인적인 개발 계획 수립
     커리어적인 성장을 위해 체계적인 계획을 개발하는 것이 중요합니다. 학습을 위한 시간을 확보하고, 강좌 및 컨퍼런스와 같은 앞선 내용들에 리소스를 할당하고 정기적으로 스스로 평가하는 시간을 가져보는 것이 좋습니다.
     
     
 10. 지속적인 네트워킹
     네트워킹은 최신 정보를 유지하는 데에 필수적인 요소입니다 동료 개발자와 소통하고, 적극적으로 협업 기회를 찾아보는 것입니다. 멘토링 및 협업 프로젝트에 참여하는 것도 좋습니다.
     
     본문에 대한 원글은 아래 링크에서 볼 수 있습니다.
     https://medium.com/gitconnected/how-to-stay-up-to-date-as-a-mobile-developer-0d6c5ef47acc

개발자가 간단하게 실천할 수 있는 최신 정보 습득 방법에 대해 가져와 봤습니다! 이미 실천하고 계신 분들도 많으실 것 같네요ㅎㅎ 빠르게 변하는 산업인 만큼 지속적으로 새로운 정보를 받아들이는 것은 중요할 것 같습니다. <ol ><li>개발자 블로그 및 뉴스레터 구독하기iOS, aOS 공식 블로그뿐만 아니라 업계 전문가가 운영하는 블로그나 뉴스레터를 정기적으로 받아보는 것은 꾸준히 정보의 흐름을 읽을 수 있는 가장 좋은 방법입니다. </li><li>소셜 미디어 및 온라인 커뮤니티에 참여하기트위터, 레딧, 스택오브플로우와 같은 개발자 커뮤니티에 가입하는 것은 개발자들과 함께 소통하면서 성장할 수 있는 좋은 방법입니다. (커리어리도 마찬가지입니다!) 관련 해시태그를 팔로우하고, 스레드에 참여해서 좋은 정보를 실시간으로 얻어보세요! (개인적으로 일론머스크의 트윗이 재밌더군요...) </li><li>컨퍼런스 및 모임 참석온라인 및 오프라인 컨퍼런스에 주기적으로 참여하면 동료 개발자들과 네트워크를 형성하고, 최신 업계 동향을 접할 수 있습니다. wwdc, google i/o뿐만 아니라 국내 기업에서 주최하는 세션이나 컨퍼런스에 참여해 보세요! </li><li>온라인 강좌를 통한 지속적 학습코세라와 같은 유명 플랫폼에서 제공하는 온라인 강좌를 통해 지속적으로 지식을 심화해 나가는 것도 좋은 방법입니다. 최신 도구나 프레임워크를 학습하는 것은 나에게 큰 도움이 될 것입니다! </li><li>출퇴근 시간에 팟캐스트 듣기통근 시간을 이용해 팟캐스트의 힘을 활용해 보세요! Fragmented, Swift by Sundell 및 Android Developers Backstage와 같은 팟캐스트에서는 최신 모바일 개발 사례나 인터뷰 및 토론을 제공합니다! 영어 공부도 덤이고요! 이 외에 주요 CEO들이 출연하여 기술에 대해 이야기하는 ACQUIRED를 추천드립니다! 최근에는 앤비디아의 젠슨 황이 출연하기도 했죠. </li><li>GitHub 리포지토리 및 오픈 소스 프로젝트를 팔로우하기GitHub만큼이나 개발자가 코드를 파보기가 좋은 데가 없죠. 도메인와 관련된 프레임워크 라이브러리 오픈소스 프로젝트의 저장소를 꾸준히 기여하고, 참여하면 코딩 기술을 업그레이드할 뿐만 아니라 새로운 코딩 표준 및 공동 개발 방식을 접할 수 있습니다. </li><li>베타 릴리즈 사용해 보기 얼리어답터가 되어 운영체제, SDK 및 개발도구의 베타 릴리즈를 실험하면 누구보다 빠른 기술을 습득할 수 있습니다. 이러한 경험을 통해 앱을 조정하고, 개발 커뮤니티에 좋은 의견들을 나눠볼 수 있죠. </li><li>업계 보고서 읽기보고서를 통해 업계 최신 동향을 광범위하게 얻을 수 있습니다. 또한 시장 행동과 타깃 유저 행동에 대한 통팔력을 통해 더 큰 그림을 이해하고, 프로젝트 방향에 대한 정보를 입각한 결정을 내릴 수 있습니다. 해외 쪽 뿐만 아니라 국내 주요 기업도 리포트를 발간하고 있으니, 참고하면 좋을 것 같습니다. </li><li>개인적인 개발 계획 수립커리어적인 성장을 위해 체계적인 계획을 개발하는 것이 중요합니다. 학습을 위한 시간을 확보하고, 강좌 및 컨퍼런스와 같은 앞선 내용들에 리소스를 할당하고 정기적으로 스스로 평가하는 시간을 가져보는 것이 좋습니다. </li><li>지속적인 네트워킹네트워킹은 최신 정보를 유지하는 데에 필수적인 요소입니다 동료 개발자와 소통하고, 적극적으로 협업 기회를 찾아보는 것입니다. 멘토링 및 협업 프로젝트에 참여하는 것도 좋습니다. 본문에 대한 원글은 아래 링크에서 볼 수 있습니다.https://medium.com/gitconnected/how-to-stay-up-to-date-as-a-mobile-developer-0d6c5ef47acc</li></ol>

Medium

개발자가 실생활에서 실천할 수 있는 스터디 방법 소개 🔑

 1. 기본기 확실히 하기
 2. 학습 능력 키우기
 3. 의사 소통 잘하기
 4. 문제 정의 잘하기
 5. 태스크 완료 시간 추정 잘하기
 6. 운영을 고려한 코드 작성하기
 7. 서비스 사고 대처 능력 키우기
 8. 결과를 내는데 집중하기
 9. 영향력 갖기 (코딩 멍키)

대부분의 개발자들은 굉장히 트렌디하다. 특히 한국 개발자들이 더 그렇다. 회사 일이 아무리 바쁘고 재미있어도 일에서 사용하는 기술이 최신이 아닌 레거시라고 생각하면 뒤쳐진다고 느끼고 조바심과 불안감을 많이 느낀다. 안 그래도 시간도 없고 힘도 부치는데 회사 일이 끝나면 새로운 기술을 조바심/불안감 기반으로 공부하는 경우가 아주 흔한다. 흔히 이야기하는 주경야독인데 약간 건강하지 않은 형태의 주경야독이다. 낮에는 회사 일을 하느라 바쁜 와중에 밤에는 선행학습을 하느라 바쁘다는 거다. 예를 들면 회사에서 레거시 시스템을 사용하는데 이게 커리어에 도움이 안된다고 보니 밤에 지금 마켓에서 핫한 시스템 공부를 하는 거다. 이 공부의 모티브가 중요한데 불안감이나 조바심이 주된 모티브라면 건강하지 않다.

내가 생각하는 건강한 학습은 평소 맡은 업무에 몰두하고 성취하는 경험을 통해 자신감을 쌓고 인정받고 (이에 대해서 뒤 "3. 의사 소통 잘하기"와 "4. 문제 정의 잘하기"에서 더 이야기해볼 예정이다) 이를 바탕으로 필요 중심 그리고 호기심 중심으로 학습하는 것이다. 즉 "현재"(필요성)에 집중하고 "나"(호기심)에 집중하는 거다. 여기에 약간의 조바심이나 불안감이 조미료처럼 첨가된다면 금상첨화다.

그런데 이게 가능하라면 내가 있는 환경이 중요해진다. 내가 잘 맞지 않는 환경이라면 현재에 집중하기가 쉽지 않을 것이다. 잘 맞는 환경인지 아닌지 판단하는 첫 번째는 같이 일하는 사람들이 어떤 사람들인지 특히 내 매니저가 어떤 사람인지 보는 건데 힘들어도 배울 점이 많고 성장한다는 느낌이 든다면 좋은 환경이다.

다음으로 나만의 학습방법을 만들어보는 것이 필요하다. 수능공부를 하는 것이 아니니 뭔가 두꺼운 책을 하나 사서 처음부터 끝까지 읽어야만 학습이 아니란 점, 필요한만큼 이해하고 넘어가도 된다는 점, 학습을 하다보면 항상 어느 시점에는 벽에 부딪칠 것이기에 꾸준함이 중요하다는 것 등등을 인지해야 한다. 개인적으로는 잘 모르는 주제가 생기면 유투브 등으로 짧은 영상 몇개 보고 더 깊게 들어갈 필요가 있다면 잘 아는 지인들에게 (적절히 보상을 해주고) 물어본다던지 아니면 더 긴 영상 강의(유데미, 인프런, 유투브 등등)등을 찾아서 밀도있게 학습하는 형태로 가려고 한다. 뭔가 정말 제대로 배우고 싶을텐데 다른 사람을 가르쳐보거나 톡을 하는 기회를 만들어서 강제로 학습하려고 한다.

결국 내가 인정받는 것은 내가 만든 결과물이지 어떤 기술을 알고 있느냐는 아니라는 점을 인식하고 호기심과 필요성 중심으로 학습으로 하는 습관을 갖도록 하자.

<ol ><li>기본기 확실히 하기</li><li>학습 능력 키우기</li><li>의사 소통 잘하기</li><li>문제 정의 잘하기</li><li>태스크 완료 시간 추정 잘하기</li><li>운영을 고려한 코드 작성하기</li><li>서비스 사고 대처 능력 키우기</li><li>결과를 내는데 집중하기</li><li>영향력 갖기 <s>(코딩 멍키)</s></li></ol> 대부분의 개발자들은 굉장히 트렌디하다. 특히 한국 개발자들이 더 그렇다. 회사 일이 아무리 바쁘고 재미있어도 일에서 사용하는 기술이 최신이 아닌 레거시라고 생각하면 뒤쳐진다고 느끼고 조바심과 불안감을 많이 느낀다. 안 그래도 시간도 없고 힘도 부치는데 회사 일이 끝나면 새로운 기술을 조바심/불안감 기반으로 공부하는 경우가 아주 흔한다. 흔히 이야기하는 주경야독인데 약간 건강하지 않은 형태의 주경야독이다. 낮에는 회사 일을 하느라 바쁜 와중에 밤에는 선행학습을 하느라 바쁘다는 거다. 예를 들면 회사에서 레거시 시스템을 사용하는데 이게 커리어에 도움이 안된다고 보니 밤에 지금 마켓에서 핫한 시스템 공부를 하는 거다. 이 공부의 모티브가 중요한데 불안감이나 조바심이 주된 모티브라면 건강하지 않다. 내가 생각하는 건강한 학습은 평소 맡은 업무에 몰두하고 성취하는 경험을 통해 자신감을 쌓고 인정받고 (이에 대해서 뒤 "3. 의사 소통 잘하기"와 "4. 문제 정의 잘하기"에서 더 이야기해볼 예정이다) 이를 바탕으로 필요 중심 그리고 호기심 중심으로 학습하는 것이다. 즉 "현재"(필요성)에 집중하고 "나"(호기심)에 집중하는 거다. 여기에 약간의 조바심이나 불안감이 조미료처럼 첨가된다면 금상첨화다. 그런데 이게 가능하라면 내가 있는 환경이 중요해진다. 내가 잘 맞지 않는 환경이라면 현재에 집중하기가 쉽지 않을 것이다. 잘 맞는 환경인지 아닌지 판단하는 첫 번째는 같이 일하는 사람들이 어떤 사람들인지 특히 내 매니저가 어떤 사람인지 보는 건데 힘들어도 배울 점이 많고 성장한다는 느낌이 든다면 좋은 환경이다. 다음으로 나만의 학습방법을 만들어보는 것이 필요하다. 수능공부를 하는 것이 아니니 뭔가 두꺼운 책을 하나 사서 처음부터 끝까지 읽어야만 학습이 아니란 점, 필요한만큼 이해하고 넘어가도 된다는 점, 학습을 하다보면 항상 어느 시점에는 벽에 부딪칠 것이기에 꾸준함이 중요하다는 것 등등을 인지해야 한다. 개인적으로는 잘 모르는 주제가 생기면 유투브 등으로 짧은 영상 몇개 보고 더 깊게 들어갈 필요가 있다면 잘 아는 지인들에게 (적절히 보상을 해주고) 물어본다던지 아니면 더 긴 영상 강의(유데미, 인프런, 유투브 등등)등을 찾아서 밀도있게 학습하는 형태로 가려고 한다. 뭔가 정말 제대로 배우고 싶을텐데 다른 사람을 가르쳐보거나 톡을 하는 기회를 만들어서 강제로 학습하려고 한다. 결국 내가 인정받는 것은 내가 만든 결과물이지 어떤 기술을 알고 있느냐는 아니라는 점을 인식하고 호기심과 필요성 중심으로 학습으로 하는 습관을 갖도록 하자.

좋은 개발자가 알아야하는 9가지 포인트들 - 2. 학습 능력 키우

스레드를 5개월만에 런칭하기 위해 모놀리틱 아키텍처를 사용했고, 5일 만에 1억명의 사용자가 몰려드는 것을 수용할 수 있었음.

사용된 기술은 커스텀 버전의 Django와 PHP, 데이터 저장소로는 TAO/UDB/MySQL와 ZippyDB 그리고 피크 타임을 위한 서버리스 펑션 Async.

자, 말 할 거 많죠? ㅋㅋㅋ 한마디하고 싶은 분들 다 여기여기 붙으세요. 🤣🤣🤣

스레드를 5개월만에 런칭하기 위해 모놀리틱 아키텍처를 사용했고, 5일 만에 1억명의 사용자가 몰려드는 것을 수용할 수 있었음. 사용된 기술은 커스텀 버전의 Django와 PHP, 데이터 저장소로는 TAO/UDB/MySQL와 ZippyDB 그리고 피크 타임을 위한 서버리스 펑션 Async. 자, 말 할 거 많죠? ㅋㅋㅋ 한마디하고 싶은 분들 다 여기여기 붙으세요. 🤣🤣🤣

📝 메타의 스레드, 모놀리틱 아키텍처 사용

차세대 자바스크립트 런타임으로 주목받고 있는 Bun이 v1.1을 출시하였습니다. 하필 거짓말처럼 만우절에 출시를 하여 윈도우즈 사용자들의 애간장을 태웠는데요. 그동안 Bun을 윈도우에서 사용하려면 WSL(Windows Subsystem for Linux)가 필요했었는데, 이제는 네이티브로도 사용할 수 있게 되었습니다 🙌

자세한 내용은 아래 공식 블로그와 유튜브 영상을 참고 바랍니다. 실제 Bun을 개발하고 있는 엔지니어들이 직접 나와서 소개하고 있는데 같은 개발자로서 약간 웃프네용 😂

📝 블로그: https://bun.sh/blog/bun-v1.1
📺 영상: https://youtu.be/yXTFOeGly9o

많은 분들이 Bun을 단순히 Node.js 보다 무지 빠른 자바스크립트 런타임이라고 알고 계시는데, 사실 Bun은 개발자 경험이 놀랍도록 띄어난 올인원 툴키트(all-in-one toolkit)입니다. Bun만 있으면 복잡한 과정없이 자바스크립트 뿐만 아니라 타입스크립트나 JSX로 작성된 코드를 바로 실행할 수 있으며, 패키지 매니저와 테스트 러너, 심지어 번들러까지 탑재하고 있습니다. 즉, 이 모든 귀찮은 일들이 다른 라이브러리 설치하지 않아도 Bun 하나만 있으면 해결됩니다 🤯

Bun에 대해서 더 알고 싶으시다면 아래 게시물을 추천드리겠습니다.

📕 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/92202

차세대 자바스크립트 런타임으로 주목받고 있는 Bun이 v1.1을 출시하였습니다. 하필 거짓말처럼 만우절에 출시를 하여 윈도우즈 사용자들의 애간장을 태웠는데요. 그동안 Bun을 윈도우에서 사용하려면 WSL(Windows Subsystem for Linux)가 필요했었는데, 이제는 네이티브로도 사용할 수 있게 되었습니다 🙌 자세한 내용은 아래 공식 블로그와 유튜브 영상을 참고 바랍니다. 실제 Bun을 개발하고 있는 엔지니어들이 직접 나와서 소개하고 있는데 같은 개발자로서 약간 웃프네용 😂 📝 블로그: https://bun.sh/blog/bun-v1.1📺 영상: https://youtu.be/yXTFOeGly9o 많은 분들이 Bun을 단순히 Node.js 보다 무지 빠른 자바스크립트 런타임이라고 알고 계시는데, 사실 Bun은 개발자 경험이 놀랍도록 띄어난 올인원 툴키트(all-in-one toolkit)입니다. Bun만 있으면 복잡한 과정없이 자바스크립트 뿐만 아니라 타입스크립트나 JSX로 작성된 코드를 바로 실행할 수 있으며, 패키지 매니저와 테스트 러너, 심지어 번들러까지 탑재하고 있습니다. 즉, 이 모든 귀찮은 일들이 다른 라이브러리 설치하지 않아도 Bun 하나만 있으면 해결됩니다 🤯 Bun에 대해서 더 알고 싶으시다면 아래 게시물을 추천드리겠습니다. 📕 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/92202

🥟 Bun v1.1 출시 소식

HashMap is Hash table based implementation of the Map interface. This implementation provides all of the optional map operations, and permits null values and the null key. (The HashMap class is...

Barclays Java Spring-Boot Micro-service Interview Question with answer 2024

Finally 블록에서 예외가 발생하면 어떻게 되나요?
자바에서, try-catch에서 finally 블록 내에서 예외가 발생할 때의 동작은, try-catch 블록의 예외 처리와 약간 다릅니다. 
 
[Try-Catch 블록의 예외]
 * 정상적인 플로우가 중지됩니다.
 * 예외 유형과 일치하는 catch 블록이 있다면, 해당 블록 내의 코드가 실행됩니다. 이를 통해 예외를 처리할 수 있습니다.
 * catch 블록이 완료되거나 어떤 catch 블록과도 일치하지 않으면 finally 블록의 코드가 실행됩니다.
[Finally 블록의 예외]
 * 원래의 예외가 중지됩니다. 이는 원래의 예외가 메서드 호출자에게 전달되지 않는 것을 의미합니다.
 * finally 블록에서 던진 예외가 호출자에게 전파되는 새로운 예외가 됩니다.
[키 포인트]
 * finally 블록은 try-catch 블록에서 예외가 발생하는지 여부에 관계없이 항상 실행됩니다.
 * finally 블록의 예외는 원래의 예외를 억제합니다.
 * finally 블록에서 던진 예외는 호출자가 처리해야 하는 새로운 예외가 됩니다.
[Finally 블록의 쓰임새]
 * 리소스(데이터베이스 연결, 파일 클로징)를 해제합니다.
 * 예외에 관계없이 항상 수행해야 하는 정리 작업을 처리합니다.
 
자바의 다이아몬드 문제란 무엇인가요?
"다이아몬드 문제"란 여러 상속 시나리오에서 발생하는 특정한 문제를 의미합니다. 클래스 상속 다이어그램을 그릴 때 발생하는 다이아몬드 모양에서 이름을 따왔습니다.

 1. 자바의 접근방식: 자바는 클래스의 다중상속을 지원하지 않습니다. 그러나 자바는 인터페이스의 다중상속은 허용합니다. 
 2. 자바 인터페이스의 다이아몬드 문제: 클래스가 두 개의 인터페이스를 구현하고 두 인터페이스가 모두 동일한 메소드명을 가진다면, 구현 클래스는 모호성을 해결하기 위해 메서드를 자체적으로 구현해야 합니다.
interface InterfaceA {
    default void display() {
        System.out.println("Inside InterfaceA");
    }
}

interface InterfaceB {
    default void display() {
        System.out.println("Inside InterfaceB");
    }
}

class MyClass implements InterfaceA, InterfaceB {
    // Here, we must provide our own implementation of display to resolve the ambiguity.
    @Override
    public void display() {
        InterfaceA.super.display(); // calling InterfaceA's default implementation
        InterfaceB.super.display(); // calling InterfaceB's default implementation
    }
}

어떻게 해결할 수 있을까요?

1. 메서드 오버라이딩: 구현 클래스에서 자신만의 구현을 제공하여 모호함을 해결합니다. 이 방식은 기본 구현 중 하나를 선택하거나 완전히 새로운 구현을 제공하고자 할 때 적합합니다.
class MyClass implements InterfaceA, InterfaceB {
    @Override
    public void display() {
        System.out.println("Hello world");
    }
}

2. 특정 인터페이스의 메서드 호출: 특정한 인터페이스의 메서드를 호출합니다. 
class MyClass implements InterfaceA, InterfaceB {
    @Override
    public void display() {
        InterfaceA.super.display(); // or InterfaceB.super.display()
        // Additional logic if needed
    }
}

 
Multilevel 상속이란 무엇인가요?
Multilevel 상속에서 A 클래스는 B 클래스를 상속하며, B 클래스 역시 C 클래스를 상속합니다.
 
자식 클래스는 부모 클래스를 통해 조부모 클래스에서 간접적으로 상속됩니다. 자식 클래스는 부모 및 조부모 클래스의 모든 public/protected 멤버에 접근할 수 있습니다.
 
String, Stringbuffer, Stringbuilder의 차이는 무엇인가요?
(번역/원문 참고)
 
메서드 오버라이딩과 오버로딩은 무엇인가요?
[메서드 오버로딩]
 * 단일 클래스 내에서 발생합니다. 이름은 같지만 매개 변수가 다른 동일한 클래스의 여러 메서드를 말합니다.
 * 메서드 오버로딩을 사용하면 유사한 작업을 수행하지만 입력/출력이 다른 메서드를 만들 수 있습니다.
class Calculator {
  public int add(int a, int b) {
    return a + b;
  }

  public double add(double a, double b) {
    return a + b;
  }
}

[메서드 오버라이딩]
 * 상속에서 클래스 간에 메서드 오버라이딩이 발생합니다. 하위 클래스가 상위 클래스에서 상속된 메서드를 재정의하는 것을 말합니다. 메서드는 상위 클래스 메서드와 동일한 이름, 반환 유형 및 매개 변수를 갖습니다.
 * 메서드 오버라이딩을 사용하면 하위 클래스가 상위 클래스에서 상속된 메서드를 자체적으로 구현하여 하위 클래스에 대한 동작을 전문화할 수 있습니다.
class Animal {
  public void makeSound() {
    System.out.println("Generic animal sound");
  }
}

class Dog extends Animal {
  @Override
  public void makeSound() {
    System.out.println("Woof!");
  }
}

 
예외 클래스의 계층구조는 무엇인가요?
Arraylist와 Linkedlist의 차이는 무엇인가요?
Set과 Arraylist의 차이는 무엇인가요?
(번역/원문 참고)
 
번역: [https://ducktopia.tistory.com/119]
원문:

Finally 블록에서 예외가 발생하면 어떻게 되나요?자바에서, try-catch에서 finally 블록 내에서 예외가 발생할 때의 동작은, try-catch 블록의 예외 처리와 약간 다릅니다.&nbsp;&nbsp;[Try-Catch 블록의 예외]<ul ><li>정상적인 플로우가 중지됩니다.</li><li>예외 유형과 일치하는 catch 블록이 있다면, 해당 블록 내의 코드가 실행됩니다. 이를 통해 예외를 처리할 수 있습니다.</li><li>catch 블록이 완료되거나 어떤 catch 블록과도 일치하지 않으면 finally 블록의 코드가 실행됩니다.</li></ul>[Finally 블록의 예외]<ul ><li>원래의 예외가 중지됩니다. 이는 원래의 예외가 메서드 호출자에게 전달되지 않는 것을 의미합니다.</li><li>finally 블록에서 던진 예외가 호출자에게 전파되는 새로운 예외가 됩니다.</li></ul>[키 포인트]<ul ><li>finally 블록은 try-catch 블록에서 예외가 발생하는지 여부에 관계없이 항상 실행됩니다.</li><li>finally 블록의 예외는 원래의 예외를 억제합니다.</li><li>finally 블록에서 던진 예외는 호출자가 처리해야 하는 새로운 예외가 됩니다.</li></ul>[Finally 블록의 쓰임새]<ul ><li>리소스(데이터베이스 연결, 파일 클로징)를 해제합니다.</li><li>예외에 관계없이 항상 수행해야 하는 정리 작업을 처리합니다.</li></ul>&nbsp;자바의 다이아몬드 문제란 무엇인가요?"다이아몬드 문제"란 여러 상속 시나리오에서 발생하는 특정한 문제를 의미합니다. 클래스 상속 다이어그램을 그릴 때 발생하는 다이아몬드 모양에서 이름을 따왔습니다. <ol ><li>자바의 접근방식: 자바는 클래스의 다중상속을 지원하지 않습니다. 그러나 자바는 인터페이스의 다중상속은 허용합니다.&nbsp;</li><li>자바 인터페이스의 다이아몬드 문제: 클래스가 두 개의 인터페이스를 구현하고 두 인터페이스가 모두 동일한 메소드명을 가진다면, 구현 클래스는 모호성을 해결하기 위해 메서드를 자체적으로 구현해야 합니다.</li></ol><pre ><code class="language-java">interface InterfaceA {
 default void display() {
 System.out.println("Inside InterfaceA");
 }
}

interface InterfaceB {
 default void display() {
 System.out.println("Inside InterfaceB");
 }
}

class MyClass implements InterfaceA, InterfaceB {
 // Here, we must provide our own implementation of display to resolve the ambiguity.
 @Override
 public void display() {
 InterfaceA.super.display(); // calling InterfaceA's default implementation
 InterfaceB.super.display(); // calling InterfaceB's default implementation
 }
}</code></pre>어떻게 해결할 수 있을까요? 1. 메서드 오버라이딩: 구현 클래스에서 자신만의 구현을 제공하여 모호함을 해결합니다. 이 방식은 기본 구현 중 하나를 선택하거나 완전히 새로운 구현을 제공하고자 할 때 적합합니다.<pre ><code class="language-java">class MyClass implements InterfaceA, InterfaceB {
 @Override
 public void display() {
 System.out.println("Hello world");
 }
}</code></pre>2. 특정 인터페이스의 메서드 호출: 특정한 인터페이스의 메서드를 호출합니다.&nbsp;<pre ><code class="language-java">class MyClass implements InterfaceA, InterfaceB {
 @Override
 public void display() {
 InterfaceA.super.display(); // or InterfaceB.super.display()
 // Additional logic if needed
 }
}</code></pre>&nbsp;Multilevel 상속이란 무엇인가요?Multilevel 상속에서 A 클래스는 B 클래스를 상속하며, B 클래스 역시 C 클래스를 상속합니다.&nbsp;자식 클래스는 부모 클래스를 통해 조부모 클래스에서 간접적으로 상속됩니다. 자식 클래스는 부모 및 조부모 클래스의 모든 public/protected 멤버에 접근할 수 있습니다.&nbsp;String, Stringbuffer, Stringbuilder의 차이는 무엇인가요?(번역/원문 참고)&nbsp;메서드 오버라이딩과 오버로딩은 무엇인가요?[메서드 오버로딩]<ul ><li>단일 클래스 내에서 발생합니다. 이름은 같지만 매개 변수가 다른 동일한 클래스의 여러 메서드를 말합니다.</li><li>메서드 오버로딩을 사용하면 유사한 작업을 수행하지만 입력/출력이 다른 메서드를 만들 수 있습니다.</li></ul><pre ><code class="language-java">class Calculator {
 public int add(int a, int b) {
 return a + b;
 }

 public double add(double a, double b) {
 return a + b;
 }
}</code></pre>[메서드 오버라이딩]<ul ><li>상속에서 클래스 간에 메서드 오버라이딩이 발생합니다. 하위 클래스가 상위 클래스에서 상속된 메서드를 재정의하는 것을 말합니다. 메서드는 상위 클래스 메서드와 동일한 이름, 반환 유형 및 매개 변수를 갖습니다.</li><li>메서드 오버라이딩을 사용하면 하위 클래스가 상위 클래스에서 상속된 메서드를 자체적으로 구현하여 하위 클래스에 대한 동작을 전문화할 수 있습니다.</li></ul><pre ><code class="language-java">class Animal {
 public void makeSound() {
 System.out.println("Generic animal sound");
 }
}

class Dog extends Animal {
 @Override
 public void makeSound() {
 System.out.println("Woof!");
 }
}</code></pre>&nbsp;예외 클래스의 계층구조는 무엇인가요?Arraylist와 Linkedlist의 차이는 무엇인가요?Set과 Arraylist의 차이는 무엇인가요?(번역/원문 참고)&nbsp;번역: [https://ducktopia.tistory.com/119]원문:

🕊️ 2024 버클리즈 Java SpringBoot 인터뷰 질문 

Learn to become an Data Analyst using this roadmap. Community driven, articles, resources, guides, interview questions, quizzes for modern backend development.

Data Analyst Roadmap

개발자분들은 roadmap.sh에 대해 이미 아시겠죠?
최근 데이터분석가의 로드맵도 업데이트되어 공유합니다!

사실 이렇게 보면.. 개발자 로드맵보다 조금 정립되어있지 않은 느낌도 드는데, 그래도 참고해보면 좋을 것 같아요!

https://roadmap.sh/data-analyst

개발자분들은 roadmap.sh에 대해 이미 아시겠죠?최근 데이터분석가의 로드맵도 업데이트되어 공유합니다! 사실 이렇게 보면.. 개발자 로드맵보다 조금 정립되어있지 않은 느낌도 드는데, 그래도 참고해보면 좋을 것 같아요! https://roadmap.sh/data-analyst

roadmap.sh

데이터분석가 로드맵 🤓

1. 감정은 전염되기 때문에 매우 중요하다.

2. 사람들은 자신과 연관된 것들을 자랑스러워하고 자신과 동료들이 성공할 것이라고 믿고 싶어 한다.

3. 그래서 조직을 이끄는 리더에게 주어진 가장 중요한 임무 하나가 자신감을 보여 주는 것이다.

4. 사람들은 자신감 넘치는 사람을 따르고 지지하고 싶어 한다.

5. 그렇기 때문에 자신감 있어 보이는 사람들이 취직하고 승진할 가능성이 크다.

6. 이뿐만 아니라 리더가 자신감 있게 행동하면 그 자신감이 전염되어 그를 따르는 다른 사람들도 더 자신감 있게 행동한다.

#권력을경영하는7가지원칙

1. 감정은 전염되기 때문에 매우 중요하다. 2. 사람들은 자신과 연관된 것들을 자랑스러워하고 자신과 동료들이 성공할 것이라고 믿고 싶어 한다. 3. 그래서 조직을 이끄는 리더에게 주어진 가장 중요한 임무 하나가 자신감을 보여 주는 것이다. 4. 사람들은 자신감 넘치는 사람을 따르고 지지하고 싶어 한다. 5. 그렇기 때문에 자신감 있어 보이는 사람들이 취직하고 승진할 가능성이 크다. 6. 이뿐만 아니라 리더가 자신감 있게 행동하면 그 자신감이 전염되어 그를 따르는 다른 사람들도 더 자신감 있게 행동한다. #권력을경영하는7가지원칙

< 리더의 자신감은 전염된다 >

Optimism, obsession, self-belief, raw horsepower and personal connections are how things get started. Cohesive teams, the right combination of calmness and urgency, and unreasonable commitment are...

What I Wish Someone Had Told Me

1. 일은 낙관, 집념, 신념, 거친 돌파력, 인간적 연결에서부터 시작됩니다.

2. 하지만 일을 마무리하는 것은 단합된 팀, 빠른 속도와 차분함의 조합, 무한한 헌신입니다.

3. (사람들이 착각하지만) 팀에게는 ‘중요한데 어려운 일을 하는 것’이 ‘중요하지 않지만 쉬운 일을 하는 것’보다 훨씬 더 쉽습니다. 담대한 목표는 사람들의 동기를 자극하니까요.

4. 인센티브는 슈퍼 파워지만, 신중하게 설정해야 합니다. (그게 고객이든, 직원이든, 한 번 도입한 인센티브를 되돌리긴 쉽지 않기 때문입니다)

5. (너무 많은 일을 동시에 벌이려고 하지 말고) 확신을 가지는 소수의 몇 가지에 자원을 집중하세요. 하지만 말이 쉽지, 이를 행동으로 옮기는 건 쉽진 않을 겁니다. 생각했던 것보다 훨씬 더 많은 것들을 (뼈를 깎는 고통을 감수하며) 제거해야 할 테니까요. (=존 우든 효과)

6. 커뮤니케이션은 명확하고 깔끔하게 하세요.

7. 조직의 구조가 구성원들이 생산적으로 일하는 것을 방해하게 않도록 하세요. 특히 관료주의와 헛소리에 대해선 발견할 때마다 싸우고, 구성원들 또한 이를 발견할 때마다 싸우도록 만드세요.

8. 비즈니스에서 중요한 건 결과입니다. 과정이 좋았다며, 나쁜 결과를 변명하도록 내버려두지 마세요. (결과가 안 좋았다면, 분명 프로세스에 문제가 있는 겁니다. 따라서 과정이 좋았다는 위로가 아니라, 문제를 파악하고 개선해야 더 나은 결과를 얻을 수 있습니다)

9. 채용에 더 많은 시간을 투자하고, 빠르게 성장할 가능성이 보이는 사람들을 영입하기 위해 위험을 무릎 써보세요!

10. 슈퍼스타는 보이는 것보다 훨씬 더 큰 가치를 가지지만, 그들에 대한 평가는 조직의 성과에 어떤 기여를 했는지를 두고 정확하게 내려야 합니다.

11. 빠른 반복은 많은 문제를 해결합니다. 특히 빠르게 반복할 수 있으면, 틀려도 상관없습니다. (빠르게 반복하는 과정에서 틀린 것들을 계속 수정할 테니까요)

12. 물리 법칙에 해당하는 비즈니스와는 싸우지 마세요. (비과학적인 믿음으로 사업을 하지 말라는 말입니다)

13. 영감은 쉽게 깨지고, 삶은 놀랍도록 빠릅니다. 그리고 아무것도 하지 않은 것이야말로 최악의 위험입니다.

14. 스케일은 급부상하고 있는 신흥 자산입니다.

15. 복리는 마법입니다. 그러니 규모와 복리가 만나는 비즈니스를 하세요.

16. 쓰러져도 다시 일어나 계속 나아가세요.

17. 위대한 사람들과 함께 일하는 것은 인생에서 가장 큰 축복 중 하나입니다.

- 샘 알트만

https://blog.samaltman.com/what-i-wish-someone-had-told-me

1. 일은 낙관, 집념, 신념, 거친 돌파력, 인간적 연결에서부터 시작됩니다. 2. 하지만 일을 마무리하는 것은 단합된 팀, 빠른 속도와 차분함의 조합, 무한한 헌신입니다. 3. (사람들이 착각하지만) 팀에게는 ‘중요한데 어려운 일을 하는 것’이 ‘중요하지 않지만 쉬운 일을 하는 것’보다 훨씬 더 쉽습니다. 담대한 목표는 사람들의 동기를 자극하니까요. 4. 인센티브는 슈퍼 파워지만, 신중하게 설정해야 합니다. (그게 고객이든, 직원이든, 한 번 도입한 인센티브를 되돌리긴 쉽지 않기 때문입니다) 5. (너무 많은 일을 동시에 벌이려고 하지 말고) 확신을 가지는 소수의 몇 가지에 자원을 집중하세요. 하지만 말이 쉽지, 이를 행동으로 옮기는 건 쉽진 않을 겁니다. 생각했던 것보다 훨씬 더 많은 것들을 (뼈를 깎는 고통을 감수하며) 제거해야 할 테니까요. (=존 우든 효과) 6. 커뮤니케이션은 명확하고 깔끔하게 하세요. 7. 조직의 구조가 구성원들이 생산적으로 일하는 것을 방해하게 않도록 하세요. 특히 관료주의와 헛소리에 대해선 발견할 때마다 싸우고, 구성원들 또한 이를 발견할 때마다 싸우도록 만드세요. 8. 비즈니스에서 중요한 건 결과입니다. 과정이 좋았다며, 나쁜 결과를 변명하도록 내버려두지 마세요. (결과가 안 좋았다면, 분명 프로세스에 문제가 있는 겁니다. 따라서 과정이 좋았다는 위로가 아니라, 문제를 파악하고 개선해야 더 나은 결과를 얻을 수 있습니다) 9. 채용에 더 많은 시간을 투자하고, 빠르게 성장할 가능성이 보이는 사람들을 영입하기 위해 위험을 무릎 써보세요! 10. 슈퍼스타는 보이는 것보다 훨씬 더 큰 가치를 가지지만, 그들에 대한 평가는 조직의 성과에 어떤 기여를 했는지를 두고 정확하게 내려야 합니다. 11. 빠른 반복은 많은 문제를 해결합니다. 특히 빠르게 반복할 수 있으면, 틀려도 상관없습니다. (빠르게 반복하는 과정에서 틀린 것들을 계속 수정할 테니까요) 12. 물리 법칙에 해당하는 비즈니스와는 싸우지 마세요. (비과학적인 믿음으로 사업을 하지 말라는 말입니다) 13. 영감은 쉽게 깨지고, 삶은 놀랍도록 빠릅니다. 그리고 아무것도 하지 않은 것이야말로 최악의 위험입니다. 14. 스케일은 급부상하고 있는 신흥 자산입니다. 15. 복리는 마법입니다. 그러니 규모와 복리가 만나는 비즈니스를 하세요. 16. 쓰러져도 다시 일어나 계속 나아가세요. 17. 위대한 사람들과 함께 일하는 것은 인생에서 가장 큰 축복 중 하나입니다. - 샘 알트만 https://blog.samaltman.com/what-i-wish-someone-had-told-me

Sam Altman

창업을 하고자 하는 사람들에게 해주고 싶은 말들

사용자가 공유한 콘텐츠

여러분, 사이드 프로젝트 하고 계시나요? ㅎㅎ
저는 개인적으로 10년 넘게 이런저런 사이드 프로젝트를 진행해 오고 있는데요. 모든 프로젝트가 대외적인 큰 성공을 거두었다고 말할 순 없어도, 제 커리어와 성장에 어쩌면 가장 큰 도움을 준 것이 사실입니다. 제가 직접 터득한 성공적인 사이드 프로젝트를 위한 몇 가지 팁을 적어보았습니다.

#디자이너의생각법 #디자이너의성장법 #쌩스터 #디자이너 #성장 #사이드프로젝트 #쌩스터 #이상인 #구글 #마이크로소프트 #실리콘밸리

LG기획자

Jake Shin

SW개발, UX기획, 상품기획, 전략기획, 기술기획

디자인

구글 디자이너가 말하는, 성공적인 사이드 프로젝트를 위한 세 가지 노하우

Staff design lead / Design system 

Product designer

Design director

Principal design director

Graphic design

지금 미국 디지털 디자인 씬에서 가장 주목받는 한국인 디자이너.
글로벌 회계 컨설팅 그룹인 딜로이트 컨설팅(Deloitte Consulting) 뉴욕 스튜디오의 Design Director(디자인 총책임)을 거쳐 현재 Microsoft 클라우드+인공지능부서의 Creative Director로 디자인 랭귀지를 책임지고 있다.
디지털 트렌스포메이션과 경험 디자인(UX/UI), 브랜딩을 주로 하고 있으며, 유학생으로서 미국에서 디자이너로 데뷔하고 글로벌 기업 디자인팀의 총책임자가 되기까지 일, 생활, 디자이너로서의 관점을 기록한 글이 SNS 채널을 통해 3만 회 이상 공유되면서 6천여 명 이상의 팔로워들에게 꾸준히 읽히고 있다.

이상인

링크

디자이너의 생각법; 시프트 저자 / 현 구글의 유튜브 광고 디자인 시스템 리드. / Prev 마이크로소프트 클라우드 + 인공지능 부서 디자인 디렉터, 딜로이트 디지털 뉴욕 스튜디오 창립 멤버, R/GA 프로덕트 이노베이션 디자이너

구글 디자이너가 말하는, 성공적인 사이드 프로젝트를 위한 세 가지 노하우

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필